Pacemaker i Corosync: HA dla usług AI OS

Pacemaker i Corosync mogą przełączyć usługę AI po awarii węzła, lecz HA wymaga także spójnych danych, sieci i procedury odcięcia uszkodzonej maszyny. Dwa serwery bez tych elementów nie tworzą bezpiecznego klastra.

Dwa różne zadania

Pacemaker jest menedżerem zasobów wysokiej dostępności: decyduje, gdzie działa usługa i kiedy ją przenieść. Corosync zapewnia komunikację i członkostwo klastra. W lokalnym AI OS mogą obsłużyć wirtualny adres bramy API, broker komunikatów lub usługę metadanych, gdy jej architektura dopuszcza aktywność na jednym węźle.

Nie każdą aplikację warto opakować w active/passive. Bazy z własną replikacją, Kubernetes i rozproszone magazyny mają odrębne mechanizmy. Dodanie Pacemakera bez zrozumienia ich semantyki może spowodować podwójny zapis. Konieczne są quorum i fencing, który odcina węzeł uznany za niesprawny, zanim usługa zostanie uruchomiona gdzie indziej.

Suwerenność i test awarii

Otwarty stos można uruchomić na własnym sprzęcie i utrzymywać bez zależności od chmury. To jednak nie zwalnia z testów: odłącz sieć klastra, wyłącz zasilanie jednego hosta i sprawdź, czy usługa jest dostępna, a dane pozostają spójne. Mierz RTO i RPO zamiast deklarować „zero przestoju”. Kopia zapasowa jest osobnym mechanizmem — HA nie chroni przed błędnym zapisem agenta ani przed ransomware.

Alternatywą jest HA w Proxmox VE, mechanizmy orchestratora K3s lub replikacja na poziomie aplikacji. Pacemaker z Corosync wybierz dla usług, które potrzebują jawnego zarządzania zasobem i przewidywalnego przełączenia. Przed produkcją spisz topologię, źródło prawdy dla danych i procedurę ręcznego odzyskania klastra.