RE: Round Robin vs Active/Passive

[Domenico Viggiani <dviggiani@tiscali.it>]

* Tore Anderson
>
> The AMS200 is indeed an active/passive array, but it's "fakes"
> active/active behaviour - if the passive controller receives 
> an I/O operation it will redirect it internally to the active 
> one which will process it and return it back to the passive 
> controller, which in turn returns it back to the initiator, 
> which have no idea that this happens at all.
> 
> So you can use it as a true active/active array, but I'd 
> recommend against it for two reasons;  first, there might be 
> a slight processing overhead to route I/O through the passive 
> controller (as well as a slight increase in latency), second, 
> you might risk saturating the interconnect between the 
> controllers with re-routed I/O if you have lots of volumes 
> using the array in this way (this might or might not be a 
> real problem depending on how the hardware is built).
> 
> So what you should do is to distinguish between paths to the 
> active controller and run round-robin on all of these, while 
> having fail-over to the set of paths to the passive 
> controller.  An example on how this
> looks:
> 
> mysql (36006016034301f0004582492ab21dd11)
> [size=40 GB][features=1 queue_if_no_path][hwhandler=0] \_ 
> round-robin 0 [prio=2][active]  \_ 4:0:2:0 sds 65:32 
> [active][ready]  \_ 3:0:2:0 sdu 65:64 [active][ready] \_ 
> round-robin 0 [prio=0][enabled]  \_ 4:0:3:0 sdr 65:16 
> [active][ready]  \_ 3:0:3:0 sdt 65:48 [active][ready]
> 
> I/O is here balanced between sds and sdu, which have the 
> highest priority.  sdr and sdt will only be used should both 
> sds and sdu fail.
> This is accomplished by the following two configuration settings:
> 
> path_grouping_policy group_by_prio
> prio_callout "/sbin/mpath_prio_emc_silent /dev/%n"
> 
> (This is an EMC array.)
> 
> You should be able to do the same using 
> mpath_prio_hdc_modular as the prio_callout.  Last I checked 
> this callout wasn't actually able to determine which 
> controller is the preferred for a given volume (one of the 
> reasons I bought an EMC instead), but did a simplistic check 
> which was something along the lines of "controller 0 is 
> preferred for all volumes with an even LUN;  controller 1 for 
> all volumes with an odd LUN".  So even though this probably 
> won't match reality unless you take care to configure the AMS 
> accordingly, you will get the desired effect - round robin 
> between the paths to one controller, failover to the paths to 
> the other.  The AMS is also clever enough to understand that 
> if you're only sending I/O to the passive controller it will 
> automatically change the ownership of the volume to the 
> controller actually receiving I/O, so you won't have the 
> problem of I/O being re-routed between controllers.
> 
> The downside is that you can't decide which controller is the 
> preferred one for a given volume, so if you have two highly 
> active volumes with odd LUNs and two mostly idle one with 
> even LUNs you won't be able to split the load equally between 
> the controllers.

Sorry for question: is this how new ALUA mode works for EMC Clariion CX
arrays?
Are default settings suitable for this new failover mode?

I just upgraded my CX700 to FLARE26 with ALUA mode...

Thanks
--
Domenico Viggiani