Główne systemy plików Xen DomU stają się tylko do odczytu podczas przełączania awaryjnego wirtualnego IP iSCSI

9

Moje serwery Xen to openSUSE 11.1 z open-iscsi do naszego klastra SAN iSCSI. Moduły SAN znajdują się w grupie przełączania awaryjnego IP za wirtualnym adresem IP, z którym łączą się inicjatorzy.

W przypadku awarii podstawowego serwera SAN serwer pomocniczy przejmuje rolę służącą jako cel. Wszystko to jest obsługiwane przez oprogramowanie LeftHand SAN / iQ i działa dobrze w większości sytuacji.

Problem, który mam, polega na tym, że czasami niektóre z moich Xen DomU będą miały swój główny system plików tylko do odczytu po przełączeniu awaryjnym IP. Nie jest spójny i zdarza się w innym podzbiorze za każdym razem, gdy nastąpi przełączenie awaryjne. Wszystkie działają na tym samym obrazie oprogramowania openSUSE 11.1.

Główne systemy plików dla każdego DomU są montowane przez open-iscsi w Dom0, a następnie Xen używa standardowego sterownika urządzenia blokowego, aby udostępnić go DomU.

Dokładnym objawem jest to, że jako root podczas działania touch /testzwraca błąd „system plików tylko do odczytu”. Jednak wynik mountpokazuje, że jest montowany jako odczyt-zapis. Oczywiście, wszystkie inne wejścia / wyjścia w domU również zawodzą w tym czasie, więc maszyna mocno się psuje. Ponowne uruchomienie z xmpoziomu Dom0 bez ponownego połączenia sesji iSCSI sprawia, że ​​wszystko działa ponownie.

Po stronie Dom0 komunikaty syslog podczas przełączania awaryjnego są następujące:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Trudno mi ustalić, na jakiej warstwie debugować ten problem, czy jest to coś w jądrze DomU? lub na poziomie Dom0 lub Xen? Myślę, że prawdopodobnie istnieje jakiś parametr, który wymaga modyfikacji, aby zwiększyć limit czasu, ale nie jestem pewien, gdzie szukać.

Naprawdę nie sądzę, że jest to problem z open-iscsi po prostu dlatego, że podłączone urządzenie blokowe jest nadal możliwe do odczytu i zapisu z Dom0.

Kamil Kisiel
źródło

Odpowiedzi:

6

W końcu rozwiązałem ten problem, korzystając z następujących porad i ustawień z dokumentacji open-iscsi:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

Po skonfigurowaniu połączenia z każdą jednostką LUN, jak opisano powyżej, przełączanie awaryjne działa jak urok, nawet jeśli zajmie to kilka minut.

Kamil Kisiel
źródło
1
Miałem ten sam problem z mysql prod db siedzącym na woluminie iscsi, z tymi samymi błędami w / var / log / messages i systemie plików w trybie tylko do odczytu. Ta wskazówka rozwiązała problem.
RainDoctor,
2

Brzmi to jak problem z inicjatorem iSCSI działającym na dom0. Inicjator nie powinien tak szybko wysyłać awarii SCSI do stosu. Prawdopodobnie będziesz chciał ustawić ConnFailTimeout w iscsi.conf jest to ustawienie, które określa, ile czasu potrwa zanim błąd połączenia zostanie uznany za błąd i wyśle ​​ten błąd do stosu SCSI.

Zastanowiłbym się również, jak długo zajmuje to przełączenie awaryjne, może potrwać dłużej, niż się spodziewasz. Jeśli tak, może przełączanie awaryjne VIP trwa zbyt długo z powodu problemów związanych z ARP.

Scott Dodson
źródło
Myślę, że właśnie tego potrzebuję.
Kamil Kisiel,
0

Czy w dom0 są jakieś komunikaty wskazujące na błędy odczytu / zapisu lub błędy SCSI w czasie przełączania awaryjnego? Jeśli tak, wygląda na to, że ten błąd zapisu jest przekazywany do domU. DomU nie „wie”, że jest urządzeniem iSCSI, więc zachowuje się tak, jakby dysk znajdujący się pod nim zniknął i ponownie instaluje system plików tylko do odczytu (patrz instrukcja montowania (1) - errors=continue / errors=remount-ro / errors=panic)

Z punktu widzenia dom0 nie zmieni się na tylko do odczytu - to zachowanie tylko do odczytu jest semantyczne dla systemu plików, a nie semantyczne dla urządzenia blokowego.

Wspominasz, że „wszystkie inne we / wy zawodzą” - masz na myśli domU czy dom0?

Zwykle podczas konfigurowania rozwiązania HA iSCSI korzystam z wielu ścieżek zamiast wirtualnego przejmowania adresów IP - pozwala to na lepszą widoczność hosta i nie masz sesji iSCSI nagle znika, a następnie trzeba ją zrestartować - zawsze tam jest, są tylko dwie z nich . Czy jest to opcja w tym środowisku?

MikeyB
źródło
Zaktualizowałem oryginalny opis z odpowiedziami na twoje pytania. Przypuszczam, że mógłbym zamiast tego zająć się wieloma ścieżkami, ale system jest bardziej nastawiony na przełączanie awaryjne wirtualnego adresu IP w obecnej formie. Nie jestem pewien, w jaki sposób replikacja na poziomie bloków miałaby działać w trybie wielościeżkowym, zwłaszcza że jedna z jednostek SAN musi zostać wyznaczona jako master. Dzięki za wskazanie mi części o systemie plików. Myślę, że to właściwie wyjaśnia. Przypuszczam, że mógłbym spróbować przełączyć go w tryb „kontynuuj”, a może spojrzeć na zmianę systemu plików na coś bardziej odpornego, jak XFS.
Kamil Kisiel
1
W ext3 nie ma nic złego - będziesz mieć podobne problemy z XFS. I nie polecałbym używania onerror = kontynuuj - system uwierzy, że blok jest nieczytelny i stracisz dane. Wielościeżkowość nie jest kopią lustrzaną - nie musisz się martwić o replikację na hoście. Po prostu połączysz się przez iSCSI zarówno z głównym, jak i drugorzędnym celem, a host będzie wiedział, że jeśli master nie powiedzie się, nie przekaże błędu na stosie, ale spróbuje wykonać to samo polecenie skierowane do drugiego celu.
MikeyB
Mój komentarz dotyczący replikacji dotyczył faktu, że dwa serwery SAN muszą zsynchronizować swoje dane. Wewnętrznie myślę, że system działa podobnie do drbd, przy czym jedna z jednostek (ta, która obecnie ma VIP) jest mistrzem. Może działać z wieloma ścieżkami, ale naprawdę chciałbym rozwiązać ten problem bez odchodzenia od obecnej architektury. Powinien istnieć sposób, aby to działało inaczej, moje systemy, które bezpośrednio montują woluminy iSCSI, nigdy nie mają problemu z tym, że wolumin staje się tylko do odczytu.
Kamil Kisiel
-1

Um ... Częścią problemu jest również to, że nie pracujesz / jako RO. Najlepsze praktyki bezpieczeństwa pod względem bezpieczeństwa powinieneś mieć zamontowany ro / "i że każdy system plików, który potrzebuje rw powinien być zamontowany osobno (tj. / Var i / tmp). Jeśli istnieją katalogi w / etc, które wymagają zapisu, należy je przenieść do / var / etc / path i dowiązać symbolicznie do / etc.

„/” należy montować RW tylko w trybie pojedynczego użytkownika.

Konfiguracja w ten sposób może zapobiec segfaultowi w powyższej sytuacji w połączeniu z innymi sugestiami.

Miguel
źródło
2
Czy na pewno odpowiadasz na właściwe pytanie?
Kamil Kisiel