W środowiskach brzegowych (edge) często mamy do dyspozycji tylko dwie maszyny w danej lokalizacji: ograniczenia kosztowe, energetyczne, miejsce w szafie, wymagania mobilne albo brak łączności pozwalającej na sensowne dostawienie trzeciego węzła.
Jednocześnie oczekiwania względem wysokiej dostępności (HA) pozostają podobne jak w centrum danych: automatyczny failover, odporność na awarie sprzętu i/lub oprogramowania, kontrola split‑brain, szybki powrót do pracy.
Problem polega na tym, że większość popularnych technologii HA (klastry, systemy rozproszone, bazy danych) jest projektowana pod (co najmniej) 3 węzły, aby osiągnąć kworum i bezpiecznie podejmować decyzje w sytuacjach niejednoznacznych (np. przy awarii sieci).
W tym artykule zbieram praktyczne opcje dla klastra 2‑węzłowego: od klasycznych klastrów zasobów (Pacemaker), przez wirtualizację (Proxmox/Hyper‑V/VMware), po storage oraz bazy danych.
Skupiam się na tym, co realnie działa, jakie są warunki brzegowe i gdzie czają się pułapki.
Założenia: dwa węzły (Node A i Node B) w jednej lokalizacji, wymagany automatyczny failover, a aplikacje mogą działać jako usługa systemowa, VM lub kontenery.
Dlaczego 2 węzły są trudne: split‑brain i kworum
W klastrze dwuwęzłowym kluczowym problemem jest split‑brain: sytuacja, w której oba węzły uznają, że „ten drugi nie żyje” i jednocześnie próbują przejąć zasoby (IP, wolumen, rolę lidera, zapis do tej samej bazy itp.).
W klastrach opartych o konsensus (Raft/Paxos) i w wielu produktach enterprise, wymaganie nieparzystej liczby głosów eliminuje część niejednoznaczności.
Dwa węzły nie potrafią same rozstrzygnąć, „kto ma rację”, gdy komunikacja się urywa.
Typowe strategie obejścia
- Świadek (witness / tie‑breaker / quorum device) – Dodajemy trzeci „głos”, ale nie jako pełny węzeł obliczeniowy. – Świadek może być:
- małą VM (np. w chmurze),
- urządzeniem w tej samej sieci (np. NAS),
- usługą arbitrażu (qdevice),
- komponentem storage (np. dysk świadek).
- Fencing (STONITH) + zasady preferencji – Jeśli węzły tracą kontakt, klaster musi umieć wyłączyć drugi węzeł lub odciąć mu dostęp do zasobów (zasilanie/IPMI, iDRAC/iLO, PDU, BMC, watchdog). – W edge bywa to problematyczne (brak zarządzalnego PDU, różny sprzęt).
- Active/Passive zamiast Active/Active – Upraszczamy architekturę: jeden węzeł aktywny, drugi w gotowości. – Często łatwiej o poprawność, kosztem mniejszej elastyczności.
- Asymetria / priorytety / „jeden węzeł zawsze wygrywa” – Możliwe, ale ryzykowne, jeśli nie ma twardego mechanizmu odcięcia dostępu do współdzielonych zasobów.
Wymagania projektowe dla edge (praktyczne)
Zanim wybierzesz technologię, warto sprecyzować kilka odpowiedzi:
- Czy aplikacja toleruje chwilową niedostępność (sekundy/minuty)?
- Czy dane są współdzielone (jeden wolumen), czy replikowane (kopie na obu węzłach)?
- Czy możliwy jest świadek poza lokalizacją (np. mała instancja w chmurze, VPS)?
- Czy masz fencing (IPMI/iLO/iDRAC, PDU) lub przynajmniej watchdog?
- Czy HA dotyczy:
- usług systemowych,
- kontenerów,
- maszyn wirtualnych,
- storage,
- bazy danych,
- czy wszystkiego naraz?
Podejście 1: klasyczny klaster zasobów (Pacemaker/Corosync)
Open source: Pacemaker + Corosync (+ SBD/qdevice)
To jeden z najbardziej dojrzałych i elastycznych stosów HA na Linuksie.
Najczęstszy wzorzec w 2‑węzłowym układzie to:
- Corosync jako warstwa komunikacji klastra,
- Pacemaker jako manager zasobów (IP, usługi, promotable resources),
- fencing/STONITH oraz/lub SBD (Storage Based Death) lub qdevice jako tie‑breaker.
Dokumentacja i referencje: – Pacemaker: https://clusterlabs.org/pacemaker/ – Corosync: https://corosync.github.io/corosync/ –
Dokumentacja „ClusterLabs”: https://clusterlabs.org/ – SBD (stosowane m.in. przez SUSE): https://github.com/ClusterLabs/sbd –
corosync-qdevice (quorum device dla 2 węzłów): https://github.com/corosync/corosync-qdevice
Zalety
- Bardzo elastyczne: możesz „opakować” praktycznie dowolną usługę,
- Działa świetnie w modelu active/passive,
- W ekosystemie enterprise jest dobrze znane (SUSE, RHEL‑like),
Wyzwania dla 2 węzłów
- Musisz świadomie rozwiązać kworum (qdevice) albo zaimplementować fencing,
- Bez fencingu łatwo o split‑brain, zwłaszcza przy wspólnym storage,
Komercyjne / enterprise dystrybucje tego podejścia
- SUSE Linux Enterprise High Availability Extension: https://www.suse.com/products/highavailability/
- Red Hat High Availability Add‑On: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/high-availability
W praktyce te rozwiązania nadal opierają się o Pacemaker/Corosync, ale dostajesz narzędzia, wsparcie i „utwardzone” scenariusze.
Podejście 2: HA na poziomie wirtualizacji (2 hosty + witness)
Jeśli Twoje aplikacje działają jako VM lub w kontenerze, często najprościej zapewnić HA na warstwie hypervisora.
Proxmox VE (open source)
Proxmox bazuje na klastrze corosync i do pełnego kworum standardowo preferuje minimum 3 głosy.
Dla 2 węzłów typowym podejściem jest QDevice jako świadek.
- Proxmox VE: https://www.proxmox.com/en/proxmox-virtual-environment/overview
- Proxmox – dokumentacja klastra/Corosync/QDevice (szukaj: pvecm qdevice): https://pve.proxmox.com/pve-docs/
Zaleta: zyskujesz HA poprzez start VM na drugim hoście
Wada: nadal potrzebujesz trzeciego głosu (nawet jako mały świadek).
VMware vSphere (komercyjne)
VMware HA/DRS jest popularnym wyborem w data center.
Często spotyka się konfiguracje 2‑hostowe (z różnymi kompromisami) oraz mechanizmy tie‑break (np. świadek dla storage / vSAN witness w scenariuszach ROBO).
- vSphere High Availability: https://docs.vmware.com/en/VMware-vSphere/index.html
- vSAN 2‑Node + Witness (koncepcja): https://core.vmware.com/vsan-2-node-cluster-guide
Microsoft Hyper‑V Failover Cluster (komercyjne)
Windows Server Failover Clustering potrafi działać w układach 2‑węzłowych ze świadkiem: File Share Witness lub Cloud Witness.
- Failover Clustering: https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview
- Cloud Witness: https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness
W edge to bywa bardzo praktyczne: „trzeci głos” może być w chmurze i jest lekki.
Podejście 3: replikacja danych + failover aplikacji (bez wspólnego storage)
W edge często lepsze jest podejście „każdy ma swoje dyski”, a dane są replikowane.
Wtedy split‑brain jest nadal groźny (dwa master’y), ale przestajesz mieć pojedynczy współdzielony wolumen, który łatwo uszkodzić.
DRBD + Pacemaker (open source)
DRBD replikuje blokowo dane pomiędzy węzłami i typowo pracuje jako active/passive (primary/secondary).
Często łączy się go z Pacemakerem.
- DRBD: https://linbit.com/drbd/
- LINBIT (vendor, model open source + komercyjny): https://linbit.com/
Dla 2 węzłów DRBD jest sprawdzonym wzorcem, ale trzeba dopilnować:
- fencingu i/lub mechanizmów zapobiegających dual‑primary,
- polityki promocji zasobu,
- testów awarii łącza
Replikacja na poziomie bazy danych
Jeśli problem dotyczy głównie bazy danych, czasem lepiej zrobić HA w obrębie DB niż na poziomie całego serwera.
Przykłady:
- PostgreSQL: streaming replication + (np.) Patroni (częściej 3+), ale w 2 węzłach zwykle i tak potrzebujesz świadka lub zewnętrznego DCS.
- Patroni: https://patroni.readthedocs.io/
- MySQL / MariaDB: asynchroniczna replikacja, Group Replication (zwykle 3+), Galera (zwykle 3+).
- MariaDB Galera Cluster: https://mariadb.com/kb/en/galera-cluster/
Podejście 4: Kubernetes na 2 węzłach (i co z control‑plane?)
Kubernetes z definicji (etcd) przewiduje nieparzystą liczbę członków quorum.
Dwuwęzłowy klaster „produkcyjny” jest możliwy, ale wymaga świadomego obejścia:
- control‑plane może być pojedynczy (co obniża HA),
- albo dwa control‑plane + zewnętrzny trzeci członek etcd (świadek) / zewnętrzny etcd,
- albo zarządzany control‑plane poza lokalizacją (czasem nieakceptowalne w edge).
Referencje: – etcd – quorum: https://etcd.io/docs/ – Kubernetes HA considerations (oficjalne docs): https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
Podejście 5: aktywne/aktywne na poziomie aplikacji (bez twardego failover)
Czasem najlepsza opcja w 2‑węzłowym edge to… nie robić klasycznego klastra.
Zamiast tego:
- uruchamiasz aplikację aktywnie na obu węzłach,
- a ruch rozkładasz przez load balancer lub DNS,
- dane trzymasz w modelu „eventually consistent” lub z mechanizmem konfliktów.
To podejście wymaga uwzględnienia na poziomie samej aplikacji, ale potrafi być bardziej odporne na problemy sieciowe, bo nie wymaga „jednego lidera” w każdej sytuacji.
Dobre praktyki dla 2 węzłów (niezależnie od technologii)
- Zawsze projektuj scenariusz awarii łącza (network partition), nie tylko awarii węzła
- Zadbaj o tie‑breaker: qdevice / cloud witness / file witness / witness VM.
- Jeśli masz wspólny storage, fencing jest obowiązkowy.
- Automatyzuj testy HA:
- odcięcie sieci,
- reset węzła,
- utrata storage,
- powrót węzła do klastra.
- Zbieraj metryki i logi klastra w jednym miejscu (w edge często offline‑friendly).
Podsumowanie
Dwuwęzłowy klaster HA jest jak „most wiszący na dwóch punktach” – da się, ale wymaga dodatkowego mechanizmu rozstrzygania (świadek) i/lub twardego odcięcia (fencing).
Najbardziej praktyczne, powtarzalne wzorce w edge to:
- 2 węzły + witness (cloud/VM/qdevice) – najczystsze podejście do kworum,
- Pacemaker/Corosync + fencing/SBD dla usług linuksowych,
- HA hypervisora dla środowisk opartych o VM,
- DRBD dla replikacji danych bez współdzielonego storage.
W 2‑węzłowych klastrach trzeba dodać trzeci element, który pomoże rozstrzygnąć, który węzeł powinien pozostać aktywny, nawet jeśli to będzie człowiek, administrator 🙂
W kolejnych artykułach postaram się przybliżyć rozwiązanie opracowane przez nasz zespół specjalnie dla serwerów brzegowych
Rozwiązanie Systegrate HA cluster łączy kilka z powyższych podejść w spójną całość, pozwalając: – trzymać stan w key=value store, – przełączać klaster HA – zapewniać sposoby radzenia sobie w sytuacjach awaryjnych
—
Bibliografia i dalsza lektura
[1] https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview
[2] https://clusterlabs.org/pacemaker/
[3] https://etcd.io/docs/
[4] https://clusterlabs.org/
[5] https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
[6] https://clusterlabs.org/pacemaker/doc/
[7] https://corosync.github.io/corosync/
[8] https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness
[9] https://pve.proxmox.com/pve-docs/
[10] https://github.com/corosync/corosync-qdevice
[11] https://core.vmware.com/vsan-2-node-cluster-guide
[12] https://linbit.com/drbd/
[13] https://patroni.readthedocs.io/
[14] https://github.com/ClusterLabs/sbd
[15] https://www.suse.com/products/highavailability/
[16] https://mariadb.com/kb/en/galera-cluster/
[17] https://www.cs.cornell.edu/home/rvr/papers/OSDI04.pdf
[18] https://medium.com/@johanesmistrialdo/simple-2-node-kubernetes-deployment-with-kubeadm-bb9b3385b950
UWAGA: Powyższy artykuł został opracowany z wykorzystaniem narzędzi AI w celu wsparcia procesu pisania i redakcji treści.