SLES12 i multipath

Przy projektowaniu systemów o wysokiej dostępności (wysokiej odporności na awarie) często stosuje się macierze dyskowe wyposażone w dwa nadmiarowe kontrolery. Uszkodzenie jednego z nich nie powoduje utraty dostępu do danych. Dane są dalej dostępne za pośrednictwem drugiego kontrolera.

Takie rozwiązanie zmienia prostą sytuację typu:

a) jedna karta FC w serwerze – jeden kontroler FC macierzy – dyski logiczne

na:

b) dwie karty FC w serwerze – dwa kontrolery FC macierzy – dyski logiczne

lub jeszcze bardzie złożone:

c) dwie karty FC w serwerze – przełączniki optyczne – dwa kontrolery FC macierzy – dyski logiczne

W miarę komplikacji środowiska dyski widziane przez system zaczynają się mnożyć. Ten sam dysk logiczny jest widziany przez jedną i drugą kartę FC serwera.

Dwukrotnie w przypadku b) i nawet czterokrotnie w c). Taka sytuacja może być wykorzystana do zwiększenia szybkości transferu danych, gdy wykorzystujemy oba kanały transmisji, ale rodzi też ona negatywne konsekwencje wynikające z istnienia różnych dróg do tych samych danych – ten sam dysk macierzy jest „widziany” na różne sposoby.

Linux przypisuje do każdego „zobaczonego” dysku kolejne urządzenie blokowe. W konfiguracji b) może to wygladać np. tak

dlk1:~ # lsscsi
[0:0:0:0] cd/dvd TEAC DVD-ROM DV28SV D.0E /dev/sr0
[3:2:0:0] disk DELL PERC 6/i Adapter 1.21 /dev/sda
[5:0:0:0] disk DGC VRAID 0430 /dev/sdb
[5:0:0:1] disk DGC VRAID 0430 /dev/sdc
[5:0:0:2] disk DGC VRAID 0430 /dev/sdd
[5:0:0:3] disk DGC RAID 10 0430 /dev/sdh
[5:0:0:4] disk DGC RAID 10 0430 /dev/sdi
[5:0:0:5] disk DGC RAID 10 0430 /dev/sdj
[7:0:0:0] disk DGC VRAID 0430 /dev/sde
[7:0:0:1] disk DGC VRAID 0430 /dev/sdf
[7:0:0:2] disk DGC VRAID 0430 /dev/sdg
[7:0:0:3] disk DGC RAID 10 0430 /dev/sdk
[7:0:0:4] disk DGC RAID 10 0430 /dev/sdl
[7:0:0:5] disk DGC RAID 10 0430 /dev/sdm

Dwa pierwsze wiersze dotyczą lokalnych napędów serwera. Pozostałe pokazują zasoby dyskowe pochodzące z macierzy. Liczby w nawiasach kwadratowych określają kolejno:

Host:Channel:Target:Lun

Z tych informacji nie wynika jednak, że /dev/sdf i /dev/sdc to ten sam dysk macierzy. Możemy oczywiście używać /dev/sdc jako urządzenia blokowego, ale w przypadku awarii dysk /dev/sdc może zniknąć i uniemożliwić dalszą pracę chociaż /dev/sdf, dane na nim zapisane, będzie dalej dostępny. Należałoby zmienić konfigurację serwera, tak by sdc zastąpić przez sdf. Jest to oczywiscie mało praktyczne i dość kłopotliwe w realizacji.

W takiej sytuacji z pomocą przychodzi multipath. Jest to program, który sięga głęboko do wnętrza systemu i potrafi rozpoznać, że w rzeczywistości /dev/sdc i /dev/sdf to to samo i utworzyć nowe urządzenie blokowe, które będzie wspólną nazwą dla obu dysków. Działa jak rodzaj inteligentnego przełacznika, który sprawdza czy każde z możliwich połączeń z macierzą jest aktywne i komunikuje sie z macierzą zgodnie z jej możliwościami

Na pierwszy rzut oka nie wygląda to skomplikowanie. W rzeczywistości jednak istnieje mnóstwo drobiazgów, które niewłaściwie skonfigurowane mogą spowodować, że działanie systemu będzie dlaekie od optymalnego. Z tego powodu należy dokładnie przeczytać i zastosować zalecenia producenta macierzy dyskowej, której będziemy używać. Trzeba również poprawnie skonfigurować same kontrolery macierzy.

W naszym przypadku podłączamy macierz CX-4 480 firmy EMC. Yast ma przygotowaną konfigurację dla macierzy EMC i wystarczy w konfiguracji zmienić w configuration defaults „user_friendly_names” na „yes” i uruchomić multipath.

Zapytany o listę multipath zwraca listę pogrupowanych urządzeń blokowych wraz z user_friendly_names.

dlk1:~ # multipath -l
mpathe (3600601601a20240026badab7cac7e411) dm-7 DGC,RAID 10
size=1.2T features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 5:0:0:3 sdh 8:112 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 7:0:0:3 sdk 8:160 active undef running
mpathc (36006016036212200368d5acce9b0e411) dm-2 DGC,VRAID
size=1023G features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 5:0:0:2 sdd 8:48 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 7:0:0:2 sdg 8:96 active undef running
mpathb (36006016036212200388d5acce9b0e411) dm-1 DGC,VRAID
size=1023G features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 7:0:0:1 sdf 8:80 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 5:0:0:1 sdc 8:32 active undef running
mpatha (36006016036212200348d5acce9b0e411) dm-0 DGC,VRAID
size=1023G features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 7:0:0:0 sde 8:64 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 5:0:0:0 sdb 8:16 active undef running
mpathg (3600601601a20240028badab7cac7e411) dm-9 DGC,RAID 10
size=1.2T features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 5:0:0:5 sdj 8:144 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 7:0:0:5 sdm 8:192 active undef running
mpathf (3600601601a20240027badab7cac7e411) dm-8 DGC,RAID 10
size=1.2T features=’1 queue_if_no_path’ hwhandler=’1 emc’ wp=rw
|-+- policy=’service-time 0′ prio=0 status=active
| `- 5:0:0:4 sdi 8:128 active undef running
`-+- policy=’service-time 0′ prio=0 status=enabled
`- 7:0:0:4 sdl 8:176 active undef running

Widać, że nasze dyski sdf i sdc zostały zgrupowane pod nazwą mpathb co odpowiada urządzeniu dm-1 o uuid 36006016036212200388d5acce9b0e411. Znacznie łatwiej posługiwać się przyjazną nazwą /dev/mapper/mpathb niż /dev/disk/by-id/wwn-0x6006016036212200388d5acce9b0e411.

Pozornie wszystko działa, do restartu serwera. Po restarcie SLES12 marudzi o partycję / i ostatecznie wchodzi w tryb emergency shell. Wyłączenie usługi multipath poleceniem systemctl disable multipathd.service pozwala na prawidłowe uruchomienie serwera. Po starcie włączenie multipath poleceniem systemctl start multipathd.service powoduje prawidłowe utworzenie urządzeń blokowych mpath. Jeżeli pozwolimy jednak na automatyczne uruchamianie multipathd to po każdym restarcie znajdziemy się w emergency shell.

„Wina” leży po stronie systemd, który w tym przypadku zachowuje się jak tępy i uparty urzędnik. Jeżeli jest włączony multipathd, to KAŻDY dysk ma być widoczny podwójnie, a jak nie to dla dobra użytkownika nie uruchomię systemu. Jedyny sposób to usunięcie mu z pola widzenia lokalnych dysków przez dopisanie ich do czarnej listy w konfiguracji multipath. Po analizie odpowiedzi lsscsi okazało się, że najprostsze będzie wyłączenie z konfiguracji multipath wszystkich urządzeń dla których dostawcą jest DELL. Po takiej zmianie serwer uruchamia się normalnie.