Nachdem ich jetzt seit 3 Wochen nebenher mit Fibrechannel und multipath teste, geht mir langsam die Lust/Geduld aus. Zumindest mit linux... Grund ist dm-multipath. Das ist so ziemlich die unzuverlässigste Software die mir in den letzten Jahren untergekommen ist... Mittlerweile wundert es mich nicht mehr, dass kein Mensch Linux auf ernsthaften storage-systemen einsetzt...
Kurzer Überblick:
Am storageserver werden zvols per SCST als LUN exportiert, am initiator korrekt erkannt und jede LUN als 2 verschiedene device-nodes (sdX) angelegt. Das funktioniert absolut zuverlässig, solange ich jede LUN immer und nur über einen Pfad anfasse kann ich damit alles anstellen. Sinn macht das so aber nicht...
Jetzt kommt also multipath ins Spiel:
Ein "multipath -v2" erkennt erstmal _keines_ der multipath-devices, pfuscht dafür aber mit _sämtlichen_ lokalen Geräten herum und legt dafür bindings und wwnids an. Erst wenn man multipath explizit mit blacklisten und blacklist_exceptions dazu zwingt, schaut es sich die SCST-Geräte an.
Hat man "property "(ID_SCSI_VPD|ID_WWN|ID_SERIAL)"" in den exceptions nicht gesetzt kann man aber blacklisten und excepten so viel man will, die devnodes werden ignoriert. Diese regression durch einen Patch aus 2014 (!!!) findet man aber auch nur nach langem suchen in einem (ungelösten) Thema einer Mailinglist...
Hat sich multipath dann endlich zwingen lassen die richtigen devices zu mappen läuft es erstmal - bis man den Client neu startet, schief anschaut oder der Wind sich dreht...
Dann sind nämlich plötzlich die multipath-devnodes weg und es passiert nur noch folgendes:
Code: Alles auswählen
# multipath -d -v2
create: mpathb (26665663230363031) undef SCST_BIO,steam-fc
size=100G features='0' hwhandler='0' wp=undef
`-+- policy='queue-length' prio=1 status=undef
|- 8:0:0:0 sdc 8:32 undef ready running
`- 9:0:0:0 sde 8:64 undef ready running
create: mpathc (26566363634346334) undef SCST_BIO,test8
size=20G features='0' hwhandler='0' wp=undef
`-+- policy='queue-length' prio=1 status=undef
|- 8:0:0:1 sdd 8:48 undef ready running
`- 9:0:0:1 sdf 8:80 undef ready running
Code: Alles auswählen
# multipath -v2
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map
Ausschnitt von "multipath -v5":
Code: Alles auswählen
Mar 23 19:18:08 | mpathc: assembled map [0 0 1 1 queue-length 2 1 8:48 1 8:80 1]
Mar 23 19:18:08 | mpathc: set ACT_CREATE (map does not exist)
Mar 23 19:18:08 | mpathc: addmap [0 41943040 multipath 0 0 1 1 queue-length 2 1 8:48 1 8:80 1]
Mar 23 19:18:08 | libdevmapper: ioctl/libdm-iface.c(1786): device-mapper: reload ioctl on mpathc failed: Invalid argument
Mar 23 19:18:08 | mpathc: domap (0) failure for create/reload map
Mar 23 19:18:08 | mpathc: ignoring map
Mar 23 19:18:08 | mpathc: remove multipath map
Code: Alles auswählen
# multipathd show paths
hcil dev dev_t pri dm_st chk_st dev_st next_check
8:0:0:0 sdc 8:32 1 undef ready running orphan
8:0:0:1 sdd 8:48 1 undef ready running orphan
9:0:0:0 sde 8:64 1 undef ready running orphan
9:0:0:1 sdf 8:80 1 undef ready running orphan
Selbst neu exportieren der LUNs mit neuer WWN, damit multipath neue Geräte konfigurieren könnte, bringt nichts - scheinbar lädt multipath irgendwelchen Müll auf den LUNs ab, kann/will aber nichts mehr damit anfangen und kann seinen Dreck auch nicht zusammenkehren...
Das einzige was funktioniert: zvol direkt am Server mounten, Daten auf ein neues zvol kopieren und als neue LUN exportieren. Bis sich dm-multipath bei der nächstbesten Gelegenheit wieder zerlegt...
Hat sich hier noch jemand mit multipath befasst und ne Idee dazu? Oder Ist dm-multipath wirklich schlichtweg kaputt und verwaist (letzte Bewegung im Repository 2014...)? Ist dm-multipath die einzige Option und "status quo" für Linux und multipath?
Mal als Vergleich: mit FreeBSD erzeugt man mit "gmultipath label fooBar /dev/daX" ein Label auf jedem Device - fertig. Daran werden automatisch die einzelnen LUNs und Pfade erkannt und es läuft - völlig egal was man mit den LUNs anstellt, wie oft man neu startet und wieviele LUNs dazukommen oder entfernt werden. Da ist ja schon die Grundkonfiguration von dm-multipath mit den fehlerhaften/unvollständigen manpages ne Katastrophe dagegen...