Mycket spännande! Clariion med Flare 26 eller högre (på cx500 är 26 det högsta som kan installeras!) så finns det stöd för ALUA, med andra ord så kan även den inaktiva pathen till ett LUN användas för access.
Till skillnad från aktiv / passiv där all access via ”fel” path refuseras så omdirigeras alla accesser till ”rätt” inom cx500-an om man använder ALUA. Naturligtvis kostar det prestanda att accessa via fel path, och är man inte uppmärksam så sker en trespass vilket kan få kostsamma följder för andra LUN på samma anslutning eller i värsta fall att LUN:et ping-pongas mellan SP:er beroende på vilken server som accessar LUN:et mest.
Jag har vänt ut-och-in på Internet i min jakt på den optimala konfigureringen av multipath för ALUA, och det verkar som om man i princip inte behöver ändra speciellt mycket i konfigurationsfilen /etc/multipath.conf. En intressant åsikt om ALUA är att man inte ska låta den få styra helt, så därför så ser min multipath.conf ut såhär:
defaults {
user_friendly_names yes
}blacklist {
devnode ”^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*”
devnode ”^(hd|xvd|vd)[a-z]*”
}# Make sure our multipath devices are enabled.
blacklist_exceptions {
wwid ”*”
}devices {
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
path_checker tur
no_path_retry queue
prio_callout ”/sbin/mpath_prio_alua /dev/%n”
failback immediate
features ”1 queue_if_no_path”
hardware_handler ”1 emc”
}
}multipaths {
multipath {
wwid 3600xxxxxxxxxxxxxxxxxxxxxxxxxde11
alias boot
}
multipath {
wwid 3600xxxxxxxxxxxxxxxxxxxxxxxxxdf11
alias OVS
}
}
Det inställningar som skiljer är ”path_checker” som istället för ”alua” har ”tur” samt att ”hardware_handler” har ”1 emc” istället för ”1 alua”. Av någon outgrundlig anledning så finns inte ”1 alua” i OVM så det får helt enkelt stå kvar vid ”1 emc” för alternativet är att det blir ”0” och hur jag än letat så fann jag ingen information om vad detta innebär.
Värt att notera är att aliasen som finns utpekade i konfig-filen funkar, men inte för ”boot” LUN:et. Den listas fortfarande som /dev/mpath/mpath0 till skillnad för aliaset för OVS LUN:et som förväntat listas som /dev/mpath/OVS. Knepigt värre, men huvudsaken är att det funkar 🙂
Vill man se om / ifall inställningarna ”tagit” så kan man starta ett kommandoskal för multipath:
# multipathd -k
Här visar kommandot ”show config” huruvida och vilka inställningar som gäller.
Lite matnyttig info från EMC:
- Prior to the installation on a CLARiiON LUN, the Linux host must have been manually registered on the array and assigned to a Storage Group. At least one LUN must be bound to the host’s Storage Group and owned by the SP connected to the HBA being used for the fabric boot. The lowest-numbered path to the boot LUN must be the active path.
- Booting from the SAN requires the use a Navisphere Management station with the Navisphere Manager or NaviCLI. The station must be separate from the boot server, but networked to the CLARiiON array in order to manually register the boot server.
- It is recommended that the boot LUN be assigned Host LUN ID 0. During the installation procedure, it is recommended that only one LUN be assigned to the Storage Group for ease of use. Once the installation has completed, additional LUNs may be added to the Storage Group.
- Path follow-over functionality is not available in MPIO. In certain scenarios, this may result in repeated trespasses when connected to CLARiiON arrays resulting in lower performance. In the CLARiiON Storage Group, change the default owner of the LUN to a Storage Processor accessible by all hosts attached to the storage group.
- On CLARiiON devices, running the multipath command at any time will result in an attempt to restore the device to its default owners. This does not impact availability of the device.
- The CLARiiON Layered Application SnapView snapshot and the admsnap host utility are supported in Linux native multipathing environments when performed with EMC CLARiiON Release 29 FLARE and layered applications. Support in Linux native multipathing environments is also available for MirrorView, SAN Copy, and SnapView clones.
- Unfractured SnapView clones are not supported in active storage groups in the Linux native multipathing environment. During a host reboot having unfractured SnapViewclones in a host’s storage group may cause the host to hang. EMC is currently working with the DM-MPIO development community to resolve this problem. Until this can be resolved the workaround is to fracture or remove any unfractured cloned LUNS from the host storage group before that host is rebooted.
Krokodox's Blog 