Proxmox VE i macierz iSCSI: jak sprawdzić odporność połączeń

Nowe serwery mogą nadal korzystać z posiadanej macierzy. Przed modernizacją trzeba sprawdzić, czy po utracie kabla, portu lub przełącznika maszyny zachowają dostęp do dysków — i czy pozostałe ścieżki udźwigną ich obciążenie. W środowisku Proxmox Virtual Environment taka ocena obejmuje sesje iSCSI, multipath, LVM oraz działanie aplikacji. Błędna konfiguracja multipath potrafi ujawnić się dopiero przy utracie ścieżki i zatrzymać I/O.

Najpierw określ zakres awarii

Wymaganie „SAN ma być redundantny” trzeba zamienić na listę konkretnych zdarzeń. Utrata portu hosta, wyłączenie całego przełącznika i awaria kontrolera macierzy obejmują różne części infrastruktury. Przy każdej pozycji zapisz, które ścieżki znikną i którędy ma dalej płynąć ruch.

Właściciel aplikacji powinien wskazać operację potwierdzającą jej działanie: na przykład zapis rekordu, zatwierdzenie transakcji i ponowny odczyt. Limity przerwy i wydajności zapisz w części „Przed” protokołu. Failover kontrolera wykonuje się po stronie macierzy, zgodnie z procedurą jej producenta; odłączenie kabla przy hoście go nie zastępuje. Jeśli przełączenie kontrolera nie będzie badane, wpisz je na listę scenariuszy poza zakresem odbioru.

Trzy warstwy: iSCSI → multipath → LVM

W omawianym układzie iSCSI udostępnia LUN, DM Multipath łączy jego ścieżki w jedno urządzenie, a LVM dzieli przestrzeń na wolumeny dla dysków VM. LVM powinien korzystać z urządzenia multipath, zwykle widocznego pod /dev/mapper/, zamiast z pojedynczego /dev/sdX reprezentującego jedną ścieżkę.

Współdzielony LVM wymaga dostępu węzłów do tego samego LUN-u oraz oznaczenia storage jako współdzielonego w Proxmox VE. Samo zaznaczenie „Shared” nie udostępnia danych pozostałym hostom. Backend LVM-thin jest lokalny — nie nadaje się do równoczesnego współdzielenia puli przez węzły.

Wpis iSCSI w /etc/pve/storage.cfg zawiera portal do wykrywania targetu. Backend Proxmox VE obsługuje logowanie do wielu ogłoszonych portali. Administrator odpowiada za ich dostępność i konfigurację DM Multipath na każdym hoście. Pakiet multipath-tools nie jest instalowany domyślnie — sprawdź jego obecność przed konfiguracją. Pliki /etc/multipath.conf oraz /etc/multipath/ należą do konkretnego węzła; Proxmox VE nie replikuje ich razem ze współdzielonym storage.cfg. Ustawienia i działanie ścieżek sprawdź osobno na każdym węźle.

Przy portalach w osobnych, bezpośrednio podłączonych podsieciach routing zwykle wybiera interfejs prowadzący do danej sieci. Sprawdź to poleceniem ip route get <IP_PORTALU> i porównaj pola dev oraz src z projektem. Gdy trzeba wymusić konkretną kartę — np. przy kilku interfejsach w tej samej podsieci — open-iscsi udostępnia obiekty iface, zarządzane przez iscsiadm -m iface, oraz parametr iface.net_ifacename. Samo utworzenie iface nie zmienia istniejących sesji: konfigurację trzeba powiązać z rekordami targetu i użyć przy logowaniu. Nie dopisuj drugiego storage dla tego samego LUN-u tylko po to, by „dodać drugi kabel”.

Czy dwa kable zapewniają niezależne ścieżki?

O niezależności decyduje przebieg połączeń. Dwa kable do jednego przełącznika pozostawiają wspólny punkt awarii. Rozrysuj dla każdej ścieżki port hosta, adres źródłowy, podsieć/VLAN, przełącznik, portal oraz kontroler macierzy.

Dla iSCSI z MPIO typowym układem są osobne interfejsy i podsieci przez różne przełączniki. Bonding (w tym LACP) działa na poziomie sieci Ethernet, a multipath łączy ścieżki do urządzenia blokowego. Bond może zwiększać odporność sieci, ale dwa jego porty nie tworzą automatycznie dwóch niezależnych ścieżek iSCSI. W dokumentacji macierzy sprawdź, ile podsieci i które porty kontrolerów ma obejmować każda ścieżka.

Porównaj MTU hosta, portów przełączników i portalu macierzy. Dla IPv4 i MTU 9000, bez dodatkowych opcji IP, przykład testu z hosta wygląda tak; podstaw adresy właściwe dla badanej ścieżki:

ping -4 -c 5 -M do -s 8972 -I <IP_ŹRÓDŁOWY> <IP_PORTALU>

8972 bajty danych wraz z nagłówkami IPv4 i ICMP dają 9000 bajtów. Sprawdź, czy odpowiedzi wracają bez komunikatu o wymaganej fragmentacji. Brak odpowiedzi wymaga również wykluczenia blokady ICMP; sam nie dowodzi błędnego MTU. Powtórz test dla każdej ścieżki.

W klastrze HA nanieś na ten sam schemat połączenia corosync. Wyłączenie przełącznika SAN nie powinno przypadkiem odcinać całej komunikacji klastra. Utrata quorum na węźle obsługującym zasoby HA może doprowadzić do jego samoczynnego restartu przez watchdog. Przed próbą ustal wpływ awarii na quorum i dostęp administracyjny; w jej trakcie obserwuj także stan klastra.

Jak sprawdzić, z czego naprawdę korzysta LVM?

Na każdym hoście Proxmox VE, z uprawnieniami administratora i zainstalowanymi narzędziami, wykonaj polecenia diagnostyczne:

iscsiadm -m session -P 3
multipath -ll
pvs -o pv_name,pv_uuid,vg_name
pvesm status

Sesje porównaj z mapą portali. W multipath -ll znajdź WWID badanego LUN-u i wszystkie przypisane do niego ścieżki. Ten sam LUN powinien mieć ten sam WWID na każdym węźle; nazwy /dev/sdX mogą być inne.

W wyniku pvs odszukaj grupę wolumenów wskazaną jako vgname w konfiguracji storage. Sprawdź, czy jej PV wskazuje urządzenie multipath dla badanego WWID. Alias lub dowiązanie rozwiąż do faktycznego urządzenia, zamiast oceniać samą nazwę. Ostrzeżenia o zduplikowanym PV albo wybór pojedynczego /dev/sdX są powodem do sprawdzenia wykrywania urządzeń przez LVM przed testem awarii. Nie usuwaj wtedy PV ani jego sygnatur.

W pvesm status sprawdź, czy odpowiedni storage LVM ma stan active na każdym węźle, który ma z niego korzystać. Ten odczyt potwierdza dostępność storage z perspektywy Proxmox VE; powiązanie z urządzeniem multipath wynika z poprzednich kontroli.

Zachowaj wyniki z nazwą hosta i czasem odczytu. Liczbę ścieżek porównuj z projektem konkretnej macierzy, a priorytety — z trybem pracy jej kontrolerów.

Co oznaczają ready, ghost i faulty?

Stan ready oznacza ścieżkę gotową do pracy, a faulty wskazuje problem. Stan ghost bywa prawidłowy dla ścieżki standby w układzie active/passive, zależnie od macierzy i używanego checkera. Nie należy utożsamiać go z każdą nieoptymalną ścieżką ALUA: ścieżka active/non-optimized może nadal pokazywać ready, z innym priorytetem.

Poniżej syntetyczny przykład wyjścia multipath -ll dla urządzenia ALUA ze ścieżką standby. WWID w nawiasie, alias, model, rozmiar i numery urządzeń są fikcyjne. Priorytety 50 i 1 ilustrują ten układ, nie stanowią wzorca dla każdej macierzy:

san_demo (360000000000000000000000000000001) dm-8 DEMO,ARRAY
size=100G features='0' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 3:0:0:1 sdc 8:32 active ghost running

Status grupy active wskazuje grupę używaną, a enabled — dostępną do wyboru. W wierszu urządzenia trzy końcowe pola opisują kolejno stan DM, wynik checkera i stan urządzenia w systemie. Dlatego active ghost running nie oznacza tego samego co uszkodzona ścieżka. Przy odbiorze porównaj wynik z dokumentacją macierzy i stanem zapisanym przed próbą, zamiast wymagać ready we wszystkich wierszach.

Wyjęcie kabla i cicha awaria to różne próby

Odłączenie kabla przy hoście zwykle wywołuje link-down. Wyłączenie portu na przełączniku trzeba opisać razem z jego położeniem: port od strony macierzy może zniknąć, chociaż interfejs hosta nadal ma link. Wyłączenie całego przełącznika obejmuje wszystkie prowadzące przez niego ścieżki.

Osobnym scenariuszem jest cicha utrata ruchu: link pozostaje aktywny, lecz pakiety nie docierają. W izolowanym laboratorium można odrzucić wychodzący TCP/3260 dla jednej pary adresów host–portal. Poniższy przykład nftables uruchamia się na hoście, nie w VM. Adresy 192.0.2.10 i 192.0.2.20 są przykładowe; podstaw sprawdzoną parę, port i interfejs. Reguła obejmie wszystkie sesje spełniające warunek, także dostęp do innych LUN-ów przez ten portal. Wymagane są niezależna konsola, sprawne pozostałe ścieżki i brak istniejącej tabeli symbit_san_test.

nft add table inet symbit_san_test
nft 'add chain inet symbit_san_test output { type filter hook output priority -10; policy accept; }'
nft add rule inet symbit_san_test output oifname "eno2" ip saddr 192.0.2.10 ip daddr 192.0.2.20 tcp dport 3260 counter drop

Stan reguły i licznik sprawdzisz poleceniem nft list table inet symbit_san_test. Licznik powinien rosnąć przy próbach ruchu badaną ścieżką. Wycofanie całego tego przykładu:

nft delete table inet symbit_san_test

Nie używaj flush ruleset. Test odwzorowuje jednostronne, ciche odrzucanie ruchu dla wybranego portalu; nie jest próbą awarii całego przełącznika. Przy sprzętowym offloadzie iSCSI filtr hosta może nie obejmować ruchu — wtedy potrzebna jest próba na przełączniku.

Czas reakcji obejmuje wykrycie braku odpowiedzi, odzyskiwanie sesji i obsługę błędów SCSI. Dla ścieżek iSCSI zarządzanych przez DM Multipath dodatnia wartość fast_io_fail_tmo może ustawić efektywny recovery_tmo sesji, z pierwszeństwem przed replacement_timeout z open-iscsi. multipathd ponownie stosuje to ustawienie przy przeładowaniu. Dlatego samo skrócenie replacement_timeout w iscsid.conf może nie zmienić zachowania działającej ścieżki. Dla takiego urządzenia punktem kontroli jest efektywny timeout sesji oraz pasujące ustawienia multipath, a nie domyślne 120 sekund z pliku Open-iSCSI.

Na każdym hoście wykonaj:

iscsiadm -m session -P 3
multipathd show config

W pierwszym wyniku dopasuj target i portal, a w sekcji Timeouts odczytaj Recovery Timeout. W drugim znajdź fast_io_fail_tmo oraz no_path_retry w ustawieniach pasujących do urządzenia; uwzględnij defaults, devices, overrides i wpis konkretnego WWID. Gdy potrzebujesz odczytu z kernela, użyj cat /sys/class/iscsi_session/session<N>/recovery_tmo, podstawiając identyfikator sesji z diagnostyki. Zapisz wartości w sekundach przed próbą. Zmiany dobieraj według instrukcji macierzy i sprawdzaj ponownie po ich zastosowaniu.

Po utracie wszystkich ścieżek no_path_retry=fail wyłącza kolejkowanie, liczba dodatnia ogranicza liczbę ponowień, a queue pozwala kolejkować bezterminowo. Liczba ponowień nie jest liczbą sekund. Funkcja queue_if_no_path również włącza kolejkowanie przy braku ścieżek; no_path_retry steruje jego polityką. W takim stanie aplikacja może zawisnąć bez błędu I/O. Kryterium przerwania musi obejmować brak postępu mierzony zewnętrznym zegarem oraz stan ścieżek, nie tylko pojawienie się komunikatu o błędzie.

Test, którego nie oszuka cache

Zwykła pętla zapisu i odczytu tego samego pliku potrafi obsługiwać dane z pamięci podręcznej gościa. Operacja testowa powinna obejmować potwierdzenie zapisu — fsync albo trwały commit aplikacji — oraz sprawdzenie odczytanych danych.

Do próby syntetycznej użyj wydzielonej VM z dyskiem na badanym storage. /mnt/san-test musi być punktem montowania tego dysku i mieć co najmniej 1 GiB wolnego miejsca. Plik san-proba.bin zostanie nadpisany. /var/tmp przeznaczone na logi umieść na dysku niezależnym od badanego SAN; dla każdego przebiegu zmień prefiks logów. Nie podstawiaj urządzenia /dev/sdX ani produkcyjnego wolumenu.

Najpierw wykonaj przebieg bez awarii i zmierz czas. Dobierz size lub dodaj --loops=N tak, aby przebieg objął pomiar bazowy, awarię i odtworzenie połączenia. Jeśli fio skończy się przed zdarzeniem, powtórz próbę. Zablokowane w kernelu I/O nie zakończy się samo, więc czas okna kontroluj niezależnym zegarem.

fio --name=san-proba --filename=/mnt/san-test/san-proba.bin --size=1G --rw=write --bs=4k --ioengine=psync --iodepth=1 --direct=1 --sync=1 --verify=crc32c --verify_backlog=1 --verify_backlog_batch=1 --verify_fatal=1 --write_lat_log=/var/tmp/san-proba --log_avg_msec=0 --log_unix_epoch=1 --lat_percentiles=1 --percentile_list=95:99 --group_reporting

direct=1 omija page cache gościa, sync=1 żąda synchronicznego zapisu, a verify_backlog=1 przeplata zapis bloku z odczytem weryfikującym. To nie są równoległe operacje. write_lat_log zapisuje pomiary pojedynczych I/O; log_avg_msec=0 wyłącza uśrednianie. Sprawdź kod zakończenia i wynik weryfikacji. Przerwany przebieg pozostaje nieukończony.

Trwałość zapisów nadal zależy od respektowania żądań flush/synchronizacji przez cały stos VM–host–macierz. Ten test nie zastępuje próby zaniku zasilania. Jest też prostym sprawdzeniem I/O, a nie profilem szczytowego obciążenia aplikacji.

Protokół próby: ciągłość, dane i wydajność po awarii

Próby zacznij w środowisku testowym. Dla produkcji potrzebne są okno serwisowe, sprawdzony backup, niezależny dostęp administracyjny i plan przywrócenia połączeń. Przygotuj osobny przebieg dla każdego scenariusza; przed kolejnym przywróć pełny stan środowiska.

Przed próbą

Zapisz host, VM, storage, WWID, wersje oprogramowania oraz ścieżki. Wskaż element wyłączany i sposób wywołania awarii: kabel, administracyjne wyłączenie konkretnego portu, cały przełącznik albo ciche odrzucanie ruchu. Określ czas obserwacji, limit przerwy w sekundach, dopuszczalne p95/p99 opóźnień w ms i minimum IOPS lub MiB/s. Przygotuj osobę odpowiedzialną za odtworzenie połączenia oraz warunki przerwania próby.

Pomiar bazowy

W VM uruchom operację aplikacyjną z potwierdzonym zapisem i kontrolą odczytu; zapisuj początek, koniec i wynik każdej transakcji. Jako ruch syntetyczny użyj powyższego fio: równolegle z operacją aplikacyjną albo w osobnym przebiegu. W pliku /var/tmp/san-proba_lat.1.log pierwsza kolumna to czas wpisu przy zakończeniu I/O w ms od epoki Unix, druga — opóźnienie w ns, trzecia — kierunek (0: odczyt, 1: zapis). Początek I/O oszacujesz jako czas zakończenia minus opóźnienie po przeliczeniu jednostek. Zapisz chwilę awarii według zsynchronizowanego zegara. Log opóźnień nie zawiera wyniku transakcji aplikacyjnej — porównuj go z raportem błędów fio, a transakcje oceniaj z logu aplikacji.

Osobny pomiar wydajności wykonaj np. fio z profilem mieszanym rw=randrw i rwmixread dobranym z monitoringu, na osobnym pliku testowym. Zachowaj rozmiary bloków, współbieżność, sposób synchronizacji zapisów i czas pomiaru odpowiadające obciążeniu aplikacji. Powtórz identyczny profil po awarii; prosty test psync z głębokością 1 służy kontroli I/O, nie pomiarowi maksymalnej wydajności macierzy.

W trakcie próby

Wywołaj jedno zapisane zdarzenie i odnotuj jego czas. Obserwuj sesje, multipath, postęp I/O, logi hosta oraz quorum i HA. Przerwij próbę i przywróć połączenie po błędzie integralności, utracie wszystkich ścieżek, nieplanowanej utracie quorum albo przekroczeniu limitu bez postępu. Przy kolejkowaniu nie czekaj na błąd aplikacji ani zakończenie fio — odtwórz ścieżkę przez niezależną konsolę. Zatrzymanie próby zapisz jako wynik negatywny lub nieukończony, wraz z przyczyną.

W stanie zdegradowanym

Po przełączeniu powtórz pomiar obciążeniowy przy dostępnej tylko pozostałej ścieżce lub grupie ścieżek. Osobno zapisz fazę samego przełączenia i ustabilizowanej pracy. Porównaj IOPS, MiB/s oraz p95/p99 opóźnień odczytu i zapisu z pomiarem bazowym i progami odbioru. Percentyle odczytaj z próbek pojedynczych operacji w tej samej warstwie, np. w gościu; nie wyliczaj ich ze średnich minutowych macierzy. Jeśli usługa działa, lecz opóźnienia przekraczają limit pod wymaganym obciążeniem, kryterium wydajności nie zostało spełnione.

Po próbie

Przywróć element, odczytaj sesje i multipath, porównaj WWID, liczbę ścieżek i ich stany z punktem odniesienia. Uwzględnij zasady failback macierzy — powrót do pierwotnej grupy nie zawsze jest natychmiastowy. Sprawdź dostępność LVM, wynik weryfikacji danych oraz wykonanie transakcji aplikacyjnej.

Wynik

Dla aplikacji policz najdłuższy odstęp między poprawnie zakończonymi transakcjami. Dla bezbłędnie ukończonego przebiegu fio różnicę kolejnych znaczników czasu w tym samym pliku logu podziel przez 1000, uzyskując sekundy; zachowaj kolejność obu kierunków I/O. Raportuj też największe opóźnienie operacji: ns / 1 000 000 daje ms. Porównaj odstępy z pomiarem bazowym. Pauzy programu i weryfikacja też wpływają na wynik, więc jest to pomiar postępu z perspektywy gościa, a nie samego sterownika. Brak zakończonych operacji przez cały okres awarii zapisz jako co najmniej zaobserwowany czas zastoju. Dołącz logi, wynik integralności, wydajność zdegradowaną i stan po przywróceniu.

Akceptacja

Próbę uznaj za zaliczoną, gdy spełnione są wszystkie progi dla badanego scenariusza. W protokole wymień także scenariusze pominięte. Po teście kabla odporność na cichą utratę ruchu albo awarię całego przełącznika pozostaje niezweryfikowana, jeśli tych zdarzeń osobno nie sprawdzono.

Czy obecną macierz warto zachować?

Tak, jeśli jej wsparcie obejmuje planowany okres użytkowania, producent wspiera docelową konfigurację hosta, a próby potwierdzają ciągłość i wymaganą wydajność również po awarii ścieżki.

Zacznij od macierzy kompatybilności producenta: sprawdź model i firmware macierzy, system hosta, wersję Proxmox VE lub Debiana oraz wymagane sterowniki i ustawienia multipath. Wpis „Linux” albo sama obsługa iSCSI nie potwierdzają wsparcia dowolnej konfiguracji. Jeśli dokument wymienia Debiana, ustal z producentem, czy obejmuje również używaną wersję Proxmox VE i jej kernel.

Sprawdź datę końca wsparcia, możliwość aktualizacji firmware, stan dysków i dostępność części. Zestaw wolną pojemność z prognozowanym przyrostem danych, a wyniki pracy zdegradowanej z obciążeniem planowanych VM. Brak wsparcia, części lub wydajności po utracie ścieżki to konkretne powody do wymiany albo ograniczenia roli macierzy.

Zakres prac przy SAN i wirtualizacji opisujemy na stronie usług Symbit.

Dokumentacja i źródła

Proxmox: Open-iSCSI initiator, LVM Backend oraz Multipath (wiki Proxmox VE).

Open-iSCSI: README — sekcja „Advanced Configuration” (timeouty przy dm-multipath); sekcja o iface opisuje wiązanie sesji.

Debian: multipath.conf(5), multipath(8), iscsiadm(8), pvs(8) — ustawienia i odczyty diagnostyczne.

Red Hat: „DM Multipath overrides of the device timeout” (RHEL 9) — pierwszeństwo timeoutów iSCSI i multipath.

fio: dokumentacja opcji direct, sync, verify i write_lat_log — warunki próby I/O i logi opóźnień.

Proxmox: Cluster Manager i High Availability — corosync, quorum i watchdog.