Proxmox HA i klaster. Kiedy wysoka dostępność
ma sens, a kiedy tylko komplikuje środowisko?

Trzy serwery. Ceph. Redundantne switche. Kilka sieci. Corosync. HA. Brzmi profesjonalnie. Tylko czy firma rzeczywiście tego potrzebuje?

Proxmox VE oferuje bardzo dobre mechanizmy klastrowania i wysokiej dostępności. Można automatycznie uruchamiać maszyny wirtualne na innym węźle po awarii hosta, wykonywać migracje podczas prac serwisowych i budować środowiska odporne na awarie pojedynczych elementów. Proxmox rekomenduje co najmniej trzy węzły, jeżeli klaster ma zapewniać niezawodne quorum.

Problem zaczyna się wtedy, gdy HA staje się celem samym w sobie. Widzieliśmy środowiska, w których prosty i dobrze zabezpieczony serwer został zastąpiony znacznie bardziej skomplikowanym klastrem tylko dlatego, że "tak powinno się robić".

Efekt?

Dlatego zanim zapytasz "jak zbudować HA na Proxmoxie?", warto odpowiedzieć na znacznie ważniejsze pytanie:

Ile kosztuje firmę awaria pojedynczego hosta i jak szybko naprawdę musimy po niej wrócić do pracy?

Klaster Proxmox i HA to nie to samo

Te pojęcia bardzo często są używane zamiennie, a oznaczają coś innego.

Klaster Proxmox VE

Klaster łączy kilka węzłów Proxmox VE w jedno zarządzane środowisko. Pozwala między innymi:

Sam fakt posiadania klastra nie oznacza jeszcze, że maszyny automatycznie uruchomią się na innym hoście po awarii.

Proxmox HA

HA Manager jest dodatkową warstwą odpowiedzialną za monitorowanie określonych zasobów i ich odzyskiwanie w razie awarii węzła. Dopiero maszyna lub kontener dodany do konfiguracji HA podlega automatycznym mechanizmom odzyskiwania.

Możesz więc mieć klaster bez HA albo klaster z HA tylko dla wybranych usług. I bardzo często właśnie to drugie podejście jest najbardziej rozsądne.

Co właściwie daje Proxmox HA?

Najważniejszą korzyścią jest ograniczenie skutków awarii fizycznego hosta. Załóżmy, że na serwerze PVE01 działa system ERP, serwer aplikacyjny, kontroler domeny i kilka innych maszyn. PVE01 ulega awarii.

W środowisku bez HA administrator musi:

1. 1 Wykryć awarię.
2. 2 Sprawdzić przyczynę.
3. 3 Zdecydować o uruchomieniu usług gdzie indziej.
4. 4 Odtworzyć lub uruchomić VM na innym serwerze.
5. 5 Zweryfikować działanie aplikacji.

W środowisku HA część tego procesu może zostać wykonana automatycznie. Klaster wykrywa utratę węzła, zabezpiecza sytuację przed jednoczesnym uruchomieniem tego samego zasobu w dwóch miejscach i uruchamia chronione maszyny na innym hoście. To bardzo wartościowa funkcja.

Live Migration to zupełnie inny scenariusz

Live Migration jest bardzo przydatna podczas planowanych prac. Przykład: musimy zaktualizować host PVE02.

1. 1 Przenosimy działające maszyny na PVE01 i PVE03.
2. 2 Aktualizujemy PVE02.
3. 3 Restartujemy.
4. 4 Przenosimy maszyny z powrotem.

Użytkownicy mogą nawet nie zauważyć prac serwisowych. To jeden z największych praktycznych atutów klastra, nawet jeżeli nie korzystamy z automatycznego HA. Dlatego czasami warto mieć klaster bez pełnego HA.

Quorum, czyli dlaczego trzy węzły mają znaczenie

Jednym z fundamentów klastra Proxmox jest quorum. W uproszczeniu klaster musi wiedzieć, która część środowiska ma prawo podejmować decyzje.

Wyobraź sobie dwa serwery, PVE01 i PVE02. Przestaje działać komunikacja między nimi.

Który z nich ma rację? Jeżeli oba uznałyby siebie za właściwy klaster i uruchomiły te same zasoby, mogłoby dojść do bardzo poważnych problemów. Dlatego wykorzystywany jest mechanizm głosowania.

Proxmox wskazuje, że dla niezawodnego quorum przy HA powinny być dostępne co najmniej trzy węzły. W typowym układzie:

Większość wynosi 2. Utrata jednego serwera nie powoduje utraty quorum.

Czy klaster dwuwęzłowy jest błędem?

Nie. Ale wymaga większej świadomości projektu. W małych środowiskach często stosuje się dwa węzły z zewnętrznym QDevice zapewniającym dodatkowy głos. Może to być sensowna architektura tam, gdzie zakup trzeciego pełnego hosta nie ma uzasadnienia.

Nie traktowałbym jednak dwóch węzłów jako automatycznego zamiennika klasycznego klastra trzywęzłowego. Jeżeli środowisko ma być krytyczne biznesowo, projekt quorum powinien zostać bardzo dokładnie przemyślany.

Czy HA wymaga shared storage?

Nie zawsze. I to jeden z najczęściej powtarzanych mitów dotyczących Proxmoxa. Najprostszy model HA rzeczywiście wykorzystuje storage dostępny z kilku hostów, na przykład Ceph, NFS, iSCSI lub inne współdzielone rozwiązania storage.

Proxmox pozwala jednak również replikować dyski maszyn znajdujące się na lokalnym ZFS pomiędzy węzłami. Storage Replication zapewnia redundancję danych gościa i może skrócić czas migracji. To oznacza, że istnieją scenariusze HA wykorzystujące lokalny storage.

Trzeba tylko rozumieć kompromis. Replikacja odbywa się okresowo. Jeżeli ostatnia synchronizacja odbyła się kilka minut przed awarią hosta, zmiany wykonane później mogą nie znajdować się na drugim serwerze. Dlatego architekturę storage trzeba dobrać do wymaganego RPO.

Ceph czy ZFS?

To jedno z najczęstszych pytań przy projektowaniu Proxmoxa. Odpowiedź brzmi: to zależy od skali i wymagań.

Ceph nie jest "dodatkiem do Proxmoxa" - to osobna, rozproszona warstwa infrastruktury wymagająca odpowiedniej liczby serwerów i dysków, wydajnej sieci, monitoringu oraz wiedzy administracyjnej. Dla klastra hyper-converged Proxmox rekomenduje co najmniej trzy serwery, a dla ruchu Ceph zaleca dedykowaną sieć o przepustowości przynajmniej 10 Gbps.

Postawienie Cepha na trzech słabych serwerach połączonych jednym switchem 1 Gbps nie sprawia, że infrastruktura staje się enterprise.

Wadą ZFS jest brak tego samego modelu współdzielonego storage co w Ceph, ale w wielu małych i średnich środowiskach ten kompromis jest bardzo rozsądny.

Kiedy HA naprawdę ma sens?

1. Awaria systemu oznacza realne straty

To najważniejsze kryterium. Jeżeli niedostępność ERP zatrzymuje:

każda godzina może kosztować firmę dużo więcej niż koszt infrastruktury HA. Wtedy automatyczne odzyskanie maszyny na drugim hoście ma realną wartość biznesową.

2. Firma pracuje przez całą dobę

Jeżeli środowisko działa 24/7, trudno znaleźć bezpieczne okno serwisowe. Klaster pozwala migrować maszyny podczas aktualizacji hostów, wymiany komponentów, diagnostyki i modernizacji.

3. Wymagane RTO jest krótkie

Jeżeli biznes deklaruje "po awarii serwera musimy wrócić do pracy w kilka minut", pojedynczy host z backupem może nie spełnić tego wymagania. Jeżeli natomiast akceptowalne RTO wynosi 4 godziny, sytuacja wygląda zupełnie inaczej.

4. Firma posiada kilka krytycznych systemów

Na przykład:

Wtedy koszt HA rozkłada się na wiele usług.

5. Środowisko ma kto utrzymywać

To warunek równie ważny jak sprzęt. Klaster powinien być monitorowany, dokumentowany, regularnie aktualizowany, testowany i utrzymywany przez osoby rozumiejące jego działanie.

HA bez kompetencji administracyjnych daje często tylko pozorne bezpieczeństwo.

Kiedy HA może być przerostem formy nad treścią?

Jeden prosty serwer i kilka niekrytycznych VM

Jeżeli firma posiada 5 maszyn, kilkunastu użytkowników, aplikacje wykorzystywane wyłącznie w godzinach biurowych oraz możliwość kilku godzin przestoju, zakup trzech serwerów, redundantnych switchy i storage może być trudny do ekonomicznego uzasadnienia. Czasami znacznie lepszym rozwiązaniem jest:

Środowiska testowe

Jeżeli VM można odtworzyć w godzinę, a nikt nie traci przez to pieniędzy, automatyczne HA może nie przynosić istotnej wartości. Nie wszystko musi mieć najwyższą możliwą dostępność.

Firma nie posiada odpowiedniej sieci

To bardzo częsty przypadek. Kupiono trzy dobre serwery. Ale pomiędzy nimi znajduje się jeden switch, jedno zasilanie, jedna sieć. W przypadku Ceph dodatkowo ograniczona przepustowość.

W takim układzie mamy trzy hosty, ale nadal istnieje wiele pojedynczych punktów awarii. HA nie polega na policzeniu serwerów - trzeba analizować cały łańcuch infrastruktury.

Brak miejsca na failover

To wyjątkowo niedoceniany błąd. Załóżmy, że mamy trzy hosty, każdy wykorzystany w 85 procentach. Pada jeden serwer. Na dwóch pozostałych trzeba uruchomić jego maszyny. Tylko gdzie?

Klaster HA powinien posiadać wystarczający zapas zasobów, żeby po utracie węzła przejąć krytyczne workloady. Jeżeli wszystkie hosty pracują stale na granicy możliwości, mechanizm HA może istnieć tylko na papierze.

HA nie naprawia zepsutej aplikacji

Załóżmy, że SQL Server ma problem. Przeniesienie maszyny na drugi host nie naprawi SQL Servera. Jeżeli:

HA może bardzo sprawnie uruchomić na drugim hoście dokładnie ten sam zepsuty system.

HA nie jest backupem. I backup nie jest HA.

HA nie zastępuje backupu

To powinno być bardzo wyraźnie zaznaczone. Klaster może posiadać 3 hosty, Ceph, redundantne switche i automatyczny failover. A firma nadal może stracić wszystkie dane.

Do odzyskania potrzebny jest backup. Dlatego niezależnie od HA nadal potrzebujemy:

O tym, gdzie trzymać niezależną kopię danych, piszemy w artykule backup off-site - gdzie trzymać drugą kopię danych firmy.

HA nie zastępuje Disaster Recovery

To kolejny poziom. HA pomaga po awarii elementu wewnątrz środowiska. Disaster Recovery odpowiada na pytanie: co zrobimy, jeżeli stracimy całe środowisko - przez pożar, zalanie, ransomware, kompromitację administracyjną albo awarię całego Data Center?

Dojrzała infrastruktura powinna więc rozróżniać:

To trzy różne problemy. Więcej o samym DR piszemy w artykule jak przygotować Disaster Recovery dla małej firmy.

Sieć klastrowa ma ogromne znaczenie

Corosync odpowiada za komunikację pomiędzy węzłami klastra. Ta komunikacja musi być stabilna. Problemy z siecią mogą prowadzić do utraty quorum, błędnej oceny stanu węzłów, problemów z HA oraz niedostępności części operacji klastra.

Dlatego sieć klastrowa nie powinna być projektowana jako przypadkowy VLAN w już przeciążonej infrastrukturze. Warto przewidzieć:

Przy Ceph wymagania rosną jeszcze bardziej ze względu na intensywny ruch storage. Oficjalna dokumentacja Proxmox zaleca dla Ceph sieć przynajmniej 10 Gbps, najlepiej przeznaczoną dla tego ruchu.

Redundancja switchy

Trzy hosty podłączone do jednego switcha nadal mają jeden punkt awarii. Dlatego w środowisku, które naprawdę ma zapewniać HA, warto przeanalizować również:

Nie zawsze wszystko trzeba dublować. Ale trzeba świadomie wiedzieć, które elementy nadal są pojedynczym punktem awarii.

Fencing to nie szczegół techniczny

W środowisku HA trzeba mieć pewność, że maszyna nie zostanie jednocześnie uruchomiona na dwóch hostach, jeżeli stan jednego z nich jest niepewny. Dlatego mechanizmy HA muszą odpowiednio izolować problematyczny węzeł przed uruchomieniem zasobów gdzie indziej.

To jedna z kluczowych różnic.

Czy każda VM powinna być objęta HA?

Zdecydowanie nie. To jeden z najważniejszych sposobów ograniczenia niepotrzebnej złożoności. Podzielmy maszyny na kilka kategorii.

Nie wszystkie maszyny mają taki sam wpływ na biznes.

Najpierw RTO i RPO, później architektura

Zamiast zaczynać od "chcemy Proxmox HA", zaczynamy od dwóch pytań: RTO - jak długo system może być niedostępny? RPO - ile danych możemy utracić?

Technologia powinna być wynikiem wymagań biznesowych. Nie odwrotnie.

Ile kosztuje HA?

Nie istnieje jedna cena, bo wszystko zależy od skali środowiska. Trzeba jednak policzyć więcej niż trzy serwery. Koszt obejmuje:

Dopiero wtedy można porównać koszt HA z kosztem przestoju. Jeżeli infrastruktura kosztuje dodatkowe 60 000 zł, ale jedna ośmiogodzinna awaria ERP kosztuje firmę 100 000 zł, rachunek wygląda inaczej niż w firmie, w której cztery godziny przestoju oznaczają tylko niewygodę.

Trzy typowe warianty Proxmox

Test HA jest ważniejszy niż status "green"

Klaster może przez rok wyglądać idealnie. Wszystkie hosty online. Ceph HEALTH_OK. Brak błędów. Ale najważniejsze pytanie brzmi: kiedy ostatnio rzeczywiście wyłączyliśmy host i sprawdziliśmy, co się stanie? Test powinien odpowiedzieć na kilka pytań:

HA, którego nigdy nie testowano, nadal jest założeniem.

Najczęstsze błędy przy Proxmox HA

Podczas projektowania lub audytowania takich środowisk zwrócilibyśmy szczególną uwagę na:

Ostatni punkt jest bardzo wymowny. Jeżeli infrastruktura została zaprojektowana jako HA, ale nikt nie ma odwagi sprawdzić, czy rzeczywiście przetrwa awarię węzła, trudno mówić o zweryfikowanej wysokiej dostępności.

Jak projektujemy klastry Proxmox w PRO-Admin?

Nie zaczynamy od liczby węzłów. Zaczynamy od biznesu. Sprawdzamy:

Dopiero wtedy odpowiadamy na pytanie, czy HA rzeczywiście jest potrzebne. Czasami odpowiedzią jest:

Nie mamy interesu w dokładaniu klientowi trzech serwerów tylko po to, żeby infrastruktura wyglądała bardziej profesjonalnie. Ma być niezawodna, przewidywalna i ekonomicznie uzasadniona. Jeżeli szukasz systemu backupu dopasowanego do środowiska Proxmox, sprawdź też artykuł Proxmox Backup Server - czy naprawdę warto wdrożyć PBS.

FAQ - Proxmox HA i klaster

Podsumowanie

Proxmox HA jest bardzo dobrym rozwiązaniem. Ale tylko wtedy, gdy rozwiązuje rzeczywisty problem.

Jeżeli każda godzina niedostępności ERP, systemu produkcyjnego czy usług klientów generuje realne straty, dobrze zaprojektowany klaster może być jedną z najlepszych inwestycji w infrastrukturę. Jeżeli natomiast firma posiada kilka niekrytycznych maszyn, akceptuje kilka godzin przestoju i nie dysponuje odpowiednią siecią ani zespołem do utrzymania klastra, HA może przynieść więcej złożoności niż korzyści.

Dopiero to drugie pytanie pozwala zaprojektować właściwą architekturę.