Wysoka dostępność serwerów

Wysoka dostępność (HA) oznacza, że awaria jednego elementu nie zatrzymuje usługi na godziny. W praktyce małej firmy to zwykle drugi serwer, wspólny albo zreplikowany storage i mechanizm, który przenosi maszyny wirtualne albo rolę na zdrowy węzeł. Na stronie o serwerach dla firm HA pojawia się tam, gdzie godzina postoju jest droższa niż drugi host, a nie jako domyślny dodatek do każdego pudełka.

HA nie jest backupem. Klaster potrafi utrzymać pracę przy padniętej płycie głównej. Nie cofnie skasowanego katalogu ani stanu sprzed ransomware. Do historii wstecz potrzeba kopii. HA i backup to para: jedno skraca przerwę sprzętową, drugie chroni przed błędem człowieka i atakiem. W środowisku opartym o Proxmox oba tematy ustawia się osobno, mimo że często stoją na tych samych hostach.

Bez testu przełączenia HA jest teorią. Raz na kwartał warto zaplanowanie wyłączyć jeden węzeł w oknie serwisowym i sprawdzić, czy usługi wstają, czy licencje się aktywują i czy użytkownicy wiedzą, że „coś mrugnęło”. Test, którego nikt nie robił od wdrożenia, w dniu prawdziwej awarii odkrywa brak sterownika albo złą bramę sieciową.

Częsty błąd to jeden shared storage bez drugiej ścieżki: oba węzły żyją, a macierz pada i HA nie ma dokąd uciec. Drugi błąd to HA na papierze przy jednej szafie, jednym UPS i jednym switchu. Trzeci błąd to obietnica „pięć dziewiątek” bez pomiaru rzeczywistych przerw z ostatnich dwunastu miesięcy.

Koszt HA liczmy uczciwie: drugi host, licencje (przy VMware po Broadcom od minimum 16 rdzeni na procesor), łącza, czas na testy. Czasem tańsze jest świadome RTO kilku godzin z dobrą kopią niż klaster, którego nikt nie umie obsłużyć. Decyzja należy do właściciela procesu, nie do katalogu sprzętu.

W dokumentacji zapisujemy, co automatycznie failoveruje, a co wymaga ręcznej decyzji. Niektóre bazy i programy branżowe źle znoszą twarde przełączenie bez przygotowania. Lista „auto / ręcznie” oszczędza chaos w nocy. Po każdej realnej awarii dopisujemy, ile minut zajęło przełączenie i co poszło nie tak. Te liczby są lepszym argumentem przy kolejnym budżecie niż hasło „mamy HA”. Jeśli po roku okaże się, że ręczne kroki trwają dłużej niż odtworzenie z kopii, architektura wymaga zmiany, a nie grubszego opisu w ofercie.

Monitoring HA musi odróżniać „węzeł padł” od „usługa nie odpowiada, choć węzeł żyje”. Sam ping hosta nie wystarczy. Sprawdzamy endpoint aplikacji albo login do programu. Alert idzie do dyżuru z jasną instrukcją: czy czekać na auto-failover, czy przełączać ręcznie. Bez instrukcji dyżur boi się ruszyć klaster i czeka zbyt długo. Raz na pół roku warto też przećwiczyć aktualizację jednego węzła przy żywym drugim, bo to najczęstsza planowana praca na klastrze. Jeśli aktualizacja wymaga wyłączenia obu naraz, to nie jest HA w praktyce, tylko dwa serwery w jednej szafie. Nazwijmy to uczciwie w ofercie i w dokumentacji, zanim ktoś kupi obietnicę, której architektura nie dowozi przy patch Tuesday.