Włączyłem wysoką dostępność, a maszyna i tak stanęła: co naprawdę obiecuje HA

Włączyłeś wysoką dostępność. Węzeł padł i twoja maszyna naprawdę wstała na drugim węźle. Ale przez kilka minut w międzyczasie niczego nie obsługiwała, a ty myślałeś, że przerwy nie będzie.

Oto nieporozumienie: wysoka dostępność nie obiecuje pracy bez przerwy, tylko automatyczne uruchomienie od nowa.

Dwie różne rzeczy

Migracja w trakcie działania to praca planowana. Uruchamiasz ją, maszyna przenosi się na drugi węzeł razem ze swoją pamięcią i prawie w ogóle się nie zatrzymuje. To narzędzie nocy serwisowych.

Wysoka dostępność jest na awarię nieplanowaną. Gdy węzeł się zawali, to, co było w jego pamięci, odeszło razem z nim; nie zostaje nic do skopiowania. Jedyne, co da się zrobić, to uruchomić maszynę od zera na innym węźle. Czyli wstaje tak, jak wstaje twój serwer po zaniku zasilania.

Miarą HA nie powinno więc być, czy była przerwa, tylko jak długo trwała przerwa.

Trzy rzeczy ustalające czas trwania

Zauważenie. Klaster nie decyduje od razu, że węzeł naprawdę umarł. Wzięcie chwilowego zachwiania sieci za śmierć i przeniesienie maszyn jest gorsze niż niezauważenie śmierci. Jest więc czekanie.

Uciszenie starego węzła. Ten krok jest najbardziej niezrozumiany i jest sercem tego wpisu: zanim maszyna wstanie na nowym węźle, trzeba mieć pewność, że stary naprawdę stanął. Jeśli nie da się tego ustalić, klaster wymusza restart tamtego węzła.

Brzmi to surowo, ale alternatywą jest katastrofa: jeśli stary węzeł faktycznie stoi, a odcięta jest tylko jego sieć, ta sama maszyna działa w dwóch miejscach i pisze na ten sam dysk z obu stron. Dane zostają uszkodzone nieodwracalnie. Dlatego klaster woli wyłączyć węzeł, którego nie jest pewien.

Uruchamianie. Maszyna startuje na nowym węźle od początku. System operacyjny rusza, usługi wstają, baza danych, jeśli jest, sama się odzyskuje. Ten czas to normalny czas startu twojej maszyny; klaster nie ma jak go skrócić.

Suma w większości układów jest rzędu minut. Nie jest zerowa i nie będzie.

Trzy warunki, żeby HA w ogóle działała

Większość. HA zależy od tego, czy klaster jest w stanie zdecydować. Bez większości nic się nie rusza. Włączenie HA w klastrze dwuwęzłowym oznacza zbudowanie siatki bezpieczeństwa, która zawodzi dokładnie w chwili, gdy potrzebujesz jej najbardziej.

Widoczność dysku z drugiego węzła. Jeśli maszyna ma wstać na nowym węźle, musi sięgnąć do swojego dysku. Maszyna siedząca wyłącznie na pamięci lokalnej nie może pójść nigdzie.

Zapas mocy. Pozostałe węzły muszą unieść też obciążenie tego, który padł. Jeśli oba węzły są zapełnione w osiemdziesięciu procentach, HA cię nie uratuje, tylko położy również drugi węzeł.

Nie włączaj HA dla każdej maszyny

Każda maszyna z włączoną HA staje się czymś, co klaster stale obserwuje i uruchamia albo zatrzymuje z własnej decyzji, gdy uzna to za stosowne. Nie zawsze tego chcesz.

Sprawdzian jest prosty: gdyby ta maszyna sama wstała o trzeciej w nocy na innym węźle, dowiedzenie się o tym rano uspokoiłoby mnie czy zaniepokoiło? Jeśli uspokaja, włącz HA. Jeśli niepokoi, nie włączaj; decyzje o tej maszynie podejmuj sam.

Co robi Atlas

Atlas oznacza osobno maszyny oddane pod zarząd wysokiej dostępności. Najbardziej pomaga to przy pracach serwisowych: gdy przed aktualizacją wypisywane są maszyny na węźle, widać oddzielnie, które zależą od twojej decyzji, a które od decyzji klastra. Przeniesienie ręczne i oddanie pod zarząd to różne rzeczy, a mylenie ich jest drogie.

Drobne, ale znaczące zachowanie: jeśli wysokiej dostępności nigdy w tej instalacji nie skonfigurowano, Atlas widzi, że odpowiednich plików konfiguracyjnych nie ma, i w ogóle nie zadaje tego pytania, zwracając pustą odpowiedź. W układzie nieużywającym HA produkt nie zajmuje więc ani ciebie, ani systemu szukaniem czegoś, czego nie ma.

I jedno ograniczenie zasługuje na jasne powiedzenie: Atlas nie podejmuje ani nie zmienia decyzji HA klastra. To, czy maszyna jest oddana pod HA, jest twoją sprawą i sprawą Proxmoksa; Atlas czyni to widocznym, a nie decyduje za ciebie.