Cichy zabójca wydajności baz danych — błędna konfiguracja MPIO i NPIV w środowiskach IBM VIOS

Problem

Błędna konfiguracja MPIO NPIV VIOS to scenariusz, który widziałem wielokrotnie: firma kupuje nową macierz SAN, bo „baza działa wolno”. Migracja przebiega poprawnie, a wydajność… nie zmienia się wcale. Do tego przy każdym przełączeniu ścieżek (failover) — na przykład podczas aktualizacji firmware kontrolera — aplikacja zawiesza się na 60 sekund, co przy systemie transakcyjnym oznacza realne straty.

Sprzęt jest nowy i szybki. Problem siedzi warstwę niżej — w konfiguracji ścieżek między LPAR-em a macierzą.

Przyczyna

W środowisku z VIOS i NPIV ścieżka I/O przechodzi przez kilka warstw: adapter wirtualny w LPAR, mapowanie NPIV na VIOS, fizyczne HBA, fabric SAN, kontrolery macierzy. Wystarczy jeden słaby punkt:

• Algorytm MPIO ustawiony na fail_over zamiast round_robin / shortest_queue — cały ruch idzie jedną ścieżką, pozostałe stoją bezczynnie. Macierz może być najszybsza na rynku; LPAR i tak korzysta z ułamka jej możliwości.
• Domyślne queue_depth na hdiskach i HBA — dziesiątki równoległych żądań bazy ustawiają się w kolejkę do urządzenia, które przyjmuje ich kilka naraz.
• Timeouty pozostawione na wartościach fabrycznych (rw_timeout, fc_err_recov) — stąd właśnie 60-sekundowe „zamrożenie” przy failoverze: system grzecznie czeka pełny timeout, zanim porzuci martwą ścieżkę. Po zmianie fc_err_recov=fast_fail i włączeniu dyntrk przełączenie trwa sekundy.
• Niesymetryczne mapowania NPIV — np. wszystkie wirtualne adaptery FC zmapowane przez jeden fizyczny port VIOS; drugi port „dla równowagi” istnieje tylko na schemacie.

Inżynieryjne rozwiązanie

Przegląd całej ścieżki I/O, od LPAR po kontroler macierzy, zawsze w tej kolejności:

1. Inwentaryzacja ścieżek — lspath, lsmap -all -npiv na VIOS: czy każda ścieżka logiczna ma pokrycie w niezależnej ścieżce fizycznej (osobne HBA, osobne fabric)?
2. Algorytm i atrybuty MPIO — round_robin/shortest_queue tam, gdzie macierz to wspiera (aktywne wszystkie ścieżki), poprawne ODM-owe atrybuty dla danego typu macierzy.
3. Dostrojenie kolejek — queue_depth na hdiskach i num_cmd_elems na adapterach dobrane do charakterystyki obciążenia i możliwości macierzy — po pomiarze, nie „na oko”.
4. Szybkie wykrywanie awarii ścieżki — fc_err_recov=fast_fail, dyntrk=yes na adapterach FC; test kontrolowanego failoveru w oknie serwisowym z pomiarem czasu przełączenia.
5. Pomiar przed i po — iostat, fcstat, statystyki kolejek: różnicę widać w liczbach, nie w odczuciach.

Wniosek biznesowy

W żadnym z takich przypadków rozwiązaniem nie był nowy sprzęt. Poprawna konfiguracja MPIO/NPIV potrafi zwielokrotnić realną przepustowość I/O istniejącej infrastruktury i skrócić failover z minuty do sekund — kosztem kilku godzin pracy inżyniera i jednego okna serwisowego. Zanim zaplanujesz zakup macierzy, warto zmierzyć, ile wydajności zostawiasz w konfiguracji.

Środowisko IBM Power działa wolniej, niż powinno? Zamów audyt ścieżki I/O.

Najczęstsze pytania o MPIO NPIV VIOS

Czy zmiana algorytmu MPIO wymaga restartu LPAR-a?
Zwykle nie — zmianę atrybutu algorithm na hdisku wykonuje się poleceniem chdev i w większości przypadków wystarczy, że dysk nie jest w danym momencie aktywnie używany przez zapisujący proces. Pełny restart LPAR-a bywa potrzebny tylko przy zmianach na poziomie samego adaptera wirtualnego, nie samego MPIO.

Skąd wiadomo, że problem jest w MPIO, a nie w samej macierzy?
Prosty test: sprawdź w iostat lub fcstat, czy obciążenie faktycznie rozkłada się na wszystkie zmapowane ścieżki, czy tylko na jedną. Jeśli jedna ścieżka przenosi niemal cały ruch, a pozostałe stoją bezczynnie mimo aktywnej konfiguracji round_robin — to prawie zawsze konfiguracja MPIO, nie ograniczenie samej macierzy.

Czy to samo dotyczy dysków wirtualnych (VSCSI), nie tylko NPIV?
Nie — to ważne rozróżnienie. Przy klasycznym VSCSI, gdzie VIOS prezentuje LPAR-owi wirtualny dysk SCSI, dostępny jest tylko jeden algorytm MPIO: fail_over. Nie ma tam możliwości balansowania ruchu między ścieżkami, niezależnie od konfiguracji. Opisana tu optymalizacja dotyczy wyłącznie NPIV, gdzie LPAR dostaje bezpośredni dostęp do LUN-ów przez własny wirtualny WWPN i korzysta z pełnego multipath drivera właściwego dla danej macierzy — dopiero wtedy round_robin czy shortest_queue są w ogóle opcją.

Czy zmiana na round_robin jest bezpieczna na każdej wersji AIX/VIOS?
Nie zawsze bezrefleksyjnie. IBM opisuje w APAR IV54907 przypadki błędów I/O przy algorytmach round_robin i shortest_queue na konkretnych poziomach — m.in. AIX 6.1 TL9, AIX 7.1 TL3 i VIOS 2.2.3.x — jeśli brakuje odpowiedniej poprawki. Zanim zmienisz algorytm na produkcji, sprawdź poziom Technology Level i najnowsze biuletyny IBM dla swojej wersji, a samą zmianę przetestuj najpierw na LPAR-ze nieprodukcyjnym z kontrolowanym failoverem.