Odtworzenie serwera AIX od zera w 15 minut — NIM, mksysb i disaster recovery, które naprawdę działa
Problem
Disaster recovery AIX zaczyna się od pytania: awaria dysków rootvg albo nieudana aktualizacja systemu — i serwer AIX nie wstaje. W wielu organizacjach scenariusz na taki dzień wygląda tak: szukanie nośnika instalacyjnego w odpowiedniej wersji, ręczna instalacja systemu, odtwarzanie konfiguracji z notatek (jeśli istnieją) i pamięci administratora (jeśli jeszcze pracuje). Realny czas przywrócenia: dzień, dwa. Koszt: cały ten czas pomnożony przez wartość stojących procesów.
Tymczasem AIX ma wbudowany mechanizm, który sprowadza ten scenariusz do kilkunastu minut — pod warunkiem, że został wdrożony przed awarią.
Przyczyna
Trzy zaniedbania składają się na wielogodzinne odtwarzanie:
- mksysb robiony „czasem” — obraz systemu sprzed roku odtwarza system sprzed roku, z ówczesnymi poprawkami i konfiguracją.
- mksysb nigdy nie testowany — obraz może być uszkodzony albo niekompletny (wykluczenia w
/etc/exclude.rootvg, o których wszyscy zapomnieli); dowiadujesz się o tym w najgorszym momencie. - Brak infrastruktury do odtworzenia — sam obraz nie wystarczy; potrzebny jest sposób, żeby uruchomić z niego instalację na (potencjalnie nowym) sprzęcie bez szukania płyt i pendrive’ów.
Inżynieryjne rozwiązanie
Architektura oparta o centralny serwer NIM (Network Installation Management):
- Automatyczne obrazy mksysb — każdy LPAR cyklicznie (np. co tydzień i przed każdą zmianą) wysyła obraz systemu na serwer NIM. Harmonogram, rotacja i kontrola rozmiaru — bez ręcznej roboty.
- Weryfikacja obrazów — obraz jest automatycznie sprawdzany (spójność archiwum, kompletność), a okresowo testowo odtwarzany na wydzielony LPAR. Dopiero wtedy wiadomo, że DR działa — i ile trwa.
- Odtwarzanie sieciowe (Bare Metal Recovery) — przy awarii: definiujemy maszynę w NIM, bootujemy LPAR z sieci i instalujemy zweryfikowany mksysb. Bez nośników, bez ręcznej konfiguracji, na dowolnym zgodnym sprzęcie. Czas dla typowego systemu: kilkanaście minut plus ewentualne odtworzenie danych aplikacyjnych z osobnego backupu.
- Dokumentacja i runbook — procedura opisana krok po kroku, przetestowana przez osobę, która jej nie pisała. W kryzysie nikt nie improwizuje.
Dla środowisk mieszanych warto dodać, że po stronie Linuksa analogiczną rolę pełni ReaR (Relax-and-Recover) — koncepcja ta sama: bootowalny obraz odtwarzania + regularny test.
Wniosek biznesowy
Różnica między „mamy mksysb” a działającą architekturą DR to różnica między RTO liczonym w dniach a RTO liczonym w minutach. Wdrożenie serwera NIM z automatyzacją i testami to projekt na kilka dni pracy — jednorazowo — a jego wartość weryfikuje się w najgorszym dniu roku, kiedy zamiast paniki jest procedura.
Chcesz wiedzieć, ile naprawdę trwałoby odtworzenie Waszego najważniejszego systemu? Porozmawiajmy.
Najczęstsze pytania
Czy SPOT zbudowany automatycznie z mksysb nadaje się do instalacji innych klientów?
Nie. SPOT wygenerowany automatycznie razem z obrazem mksysb jest jednorazowy — przypisany do tego konkretnego obrazu i usuwany po odtworzeniu. Do obsługi wielu klientów NIM (typowa sytuacja u konsultanta obsługującego kilka środowisk) potrzebny jest osobny, ogólny zasób SPOT zbudowany z nośników instalacyjnych AIX (Base Media), który można wykorzystywać wielokrotnie — pod warunkiem, że obsługiwane LPAR-y mają tę samą wersję AIX (VRMF). Przy mieszanych wersjach systemu trzeba utrzymywać kilka takich SPOT-ów równolegle.
Jak wygląda samo polecenie odtworzenia po stronie serwera NIM?
Całą operację uruchamia jedna komenda: nim -o bos_inst -a source=mksysb -a lpp_source=<lpp_source> -a spot=<SPOT> -a mksysb=<mksysb> -a image_data=mksysb_image_data -a accept_licenses=yes <klient>. Jeden szczegół, o którym łatwo zapomnieć: lpp_source powinien odpowiadać poziomowi Technology Level obrazu mksysb. Jeśli lpp_source jest nowszy, AIX zostanie przy okazji zaktualizowany do wyższego TL — czasem to pożądane, ale bez świadomej decyzji potrafi zaskoczyć zespół w środku odtwarzania po awarii.
Czy odtworzenie z mksysb przez NIM da się przetestować bez ryzyka dla produkcji?
Tak, i to jest właśnie sens regularnego testu, o którym mowa wyżej. Odtworzenie robi się na wolnym LPAR-ze (fizycznej albo tymczasowo dostawionej na innym serwerze Power), a nie na produkcyjnym systemie — proces bos_inst z zasobami mksysb i SPOT działa identycznie niezależnie od tego, czy celem jest maszyna zapasowa, czy prawdziwy incydent. Dzięki temu test w pełni sprawdza cały łańcuch: obraz, SPOT, lpp_source i samą procedurę, a produkcja przez cały czas pracuje bez przerwy. To odróżnia realny test disaster recovery od samego sprawdzenia integralności pliku mksysb.