Podstawowe koncepcje wysokiej dostępności (HA)

HA wiąże się z projektowaniem infrastruktury IT w taki sposób, aby uniknąć pojedynczych punktów awarii (Single Points of Failure, SPOF) oraz zapewnić szybką reakcję na ewentualne problemy. Klaster HA wykrywa błędy sprzętowe/programowe i natychmiast uruchamia aplikację w innym węźle bez konieczności interwencji administratora. Proces ten jest znany jako mechanizm failover. Przy projektowaniu klastra HA należy uwzględnić wiele aspektów związanych z redundancją poszczególnych warstw naszego rozwiązania, ale przede wszystkim zrozumieć kilka podstawowych koncepcji.

Table of Contents

Podstawowe koncepcje HA w Linuxie:

1. Cluster Messaging Layer

„Cluster Messaging Layer” (Warstwa Komunikacji Klastra) to kluczowy element w koncepcji Wysokiej Dostępności (HA) w systemach klastrów. Odpowiada za zapewnienie efektywnej i niezawodnej komunikacji między węzłami klastra, umożliwiając im współpracę, wykrywanie awarii oraz synchronizację działań. Jest to istotne, aby w razie awarii jednego węzła klastra inne węzły mogły odpowiednio zareagować i utrzymać ciągłość działania usług.

Przykładem zastosowania „Cluster Messaging Layer” jest Corosync – popularne narzędzie do komunikacji między węzłami w klastrze. Zapewnia wydajną, niezawodną komunikację opartą na protokole multicast lub unicast. Corosync pozwala na wykrywanie awarii węzłów, synchronizację stanów i przekazywanie informacji o dostępności zasobów. Jest często stosowany w połączeniu z narzędziem Pacemaker do zarządzania klastrami i dostarczania usług HA. Corosync jest wykorzystywany w takich projektach jak: Red Hat Cluster Suite, OpenStack, Proxmox, DRBD.

2. Cluster Resource Manager

„Cluster Resource Manager” (CRM) to kolejny kluczowy komponent w koncepcji Wysokiej Dostępności (HA) w systemach klastrów. Jego głównym zadaniem jest zarządzanie zasobami klastra oraz monitorowanie ich dostępności i stanu. CRM jest odpowiedzialny za podejmowanie decyzji dotyczących przełączania usług między węzłami klastra w przypadku awarii lub zmiany stanu systemu.

CRM jest zazwyczaj zintegrowane z innymi narzędziami HA, takimi jak „Cluster Messaging Layer” (warstwa komunikacji klastra), które umożliwiają komunikację między węzłami klastra i przekazywanie informacji o stanie zasobów. Dzięki temu CRM może skutecznie monitorować i zarządzać usługami w klastrze.

Przykładowe produkty i narzędzia, które wykorzystują „Cluster Resource Manager” w kontekście Wysokiej Dostępności:

Pacemaker: Pacemaker to zaawansowane narzędzie do zarządzania klastrami i dostarczania usług HA. Współpracuje z „Cluster Messaging Layer” (na przykład Corosync lub Heartbeat), aby monitorować stan węzłów i zasobów w klastrze. Pacemaker podejmuje decyzje dotyczące przełączania usług między węzłami, aby utrzymać ciągłość działania.
Keepalived: Keepalived to prostsze narzędzie do HA, które często jest używane do równoważenia obciążenia oraz monitorowania dostępności serwerów. Może być używane w połączeniu z CRM, aby przekazywać informacje o zmianach w dostępności serwerów.
Corosync + Pacemaker: W połączeniu Corosync i Pacemaker stanowią potężne rozwiązanie HA. Corosync pełni rolę „Cluster Messaging Layer”, a Pacemaker działa jako „Cluster Resource Manager”, zarządzając zasobami klastra i podejmując decyzje dotyczące awarii i przełączania usług.

3. Quorum

„Quorum” to istotne pojęcie odnoszące się do decyzyjnej zdolności klastra do działania w sytuacji, gdy część węzłów klastra staje się niedostępna.

Pomyśl o klastrze jak o drużynie trzech przyjaciół, którzy pracują razem na swoich komputerach. „Quorum” to taka sytuacja, kiedy większość z tych trzech przyjaciół jest nadal dostępna i może razem podjąć ważne decyzje.

Wyobraź sobie, że macie trzy komputery i pracujecie razem, aby obsłużyć pewne zadania. Teraz wyobraź sobie, że jeden z tych komputerów przestaje działać, na przykład nagle się wyłącza. W takiej sytuacji, dwa pozostałe komputery mogą zdecydować, że jedno z nich powinno przejąć zadania tego trzeciego komputera, który przestał działać.

Quorum odnosi się do minimalnej liczby węzłów w klastrze, które muszą być aktywne i dostępne, aby klastr był w stanie kontynuować pracę. W przypadku, gdy ilość aktywnych węzłów jest mniejsza niż wymagana minimalna liczba (quorum), klaster może przejść w tryb pasywny, aby uniknąć niejednoznacznych decyzji i potencjalnych konfliktów w zarządzaniu zasobami.

W klastrze trzy-węzłowym, gdy węzeł 1 zostaje odłączony, pozostałe dwa węzły mogą zadecydować o przejęciu usług węzła 1. Jeśli CRM jest poprawnie skonfigurowany, węzeł 1 powinien zauważyć, że stracił quorum i zakończyć swoje podstawowe role, aby uniknąć sytuacji, w której na przykład dwie kopie bazy danych zawierają różne zmiany wprowadzone przez różnych klientów. Posiadanie Quorum w klastrze dwu-węzłowym jest możliwe tylko wtedy, gdy oba węzły są w pełni funkcjonalne. W praktyce zalecane jest zawsze posiadanie nieparzystej ilości węzłów w klastrze.

4. STONITH

„STONITH” to taki dziwny skrót, który oznacza „Shoot The Other Node In The Head”, czyli „Wystrzel Drugi Węzeł w Głowę”. Ale spokojnie, to nie jest dosłowne strzelanie! To jest taki sposób, aby zapewnić bezpieczeństwo w klastrze komputerowym.

Wyobraź sobie, że masz dwa komputery, które pracują razem w klastrze. Jeśli jeden z nich przestaje działać lub zaczyna się źle zachowywać, to może wprowadzić zamieszanie w twoim systemie. Właśnie tu wchodzi do akcji.”STONITH” mówi: „Ok, jest problem. Zresetujmy go, żeby wrócił do normy.” To tak, jakbyś miał magiczny przycisk, który pomaga wyczyszczać sytuacje, gdy coś idzie nie tak.

Podsumowując, „STONITH” to taka metoda, która pomaga utrzymać porządek w klastrze komputerowym. Kiedy jeden z komputerów zaczyna robić kłopoty, „STONITH” może pomóc mu zresetować się i wrócić do normalnej pracy, żeby nie wprowadzać zamieszania w całym systemie.

5. Resource Agents

„Resource Agents” to usługa która jest odpowiedzialna za opiekowanie się jedną konkretną rzeczą, na przykład bazą danych, czy serwerem poczty.

Myśl o tym jak o grupie ludzi, gdzie każdy ma swoje zadanie. Jeden człowiek może być ekspertem od bazy danych, inny od stron internetowych, a jeszcze inny od serwerów poczty. W przypadku „Resource Agents”, to są tacy „eksperci”, którzy wiedzą, jak zająć się konkretnym zadaniem w klastrze.

Gdy coś się dzieje z jednym z zasobów, na przykład baza danych przestaje działać, „Resource Agent” odpowiedzialny za bazę danych podejmuje działania, żeby to naprawić np może przenieść bazę danych na inny server w klastrze.

Dzięki „Resource Agents” w klastrze HA, można szybko reagować na problemy i awarie, aby utrzymać usługi działające bez przerw. Każdy „Resource Agent” wie, jak działać, żeby zadbać o swoją usługę, co pomaga utrzymać cały klaster w dobrej kondycji.

6. SDS

Software-Defined Storage (SDS) to koncept przechowywania danych oparty na budowaniu magazynu danych (Storage) w sposób programowy, a nie sprzętowy. W przeciwieństwie do tradycyjnych rozwiązań, w których sprzętowa infrastruktura determinuje konfigurację i dostępność przechowywanych danych, SDS pozwala na tworzenie magazynów danych z wykorzystaniem różnych urządzeń i nośników, niezależnie od dostawcy czy technologii. To daje elastyczność w wyborze komponentów i ułatwia modyfikacje infrastruktury w przyszłości. Większość rozwiązań SDS opiera się na standardach otwartych, co pozwala na uniknięcie lock-inu w stosunku do konkretnego dostawcy.

„Piękno software-defined storage polega na tym, że jest niezależne od infrastruktury. Nie jesteś już ograniczony do rozwiązania sprzętowego jednego konkretnego dostawcy.”

Przykłady oprogramowania wykorzystywanego do budowy Software-Defined Storage:

Ceph: To popularne rozwiązanie SDS, które dostarcza skalowalny i wydajny magazyn danych. Ceph pozwala na tworzenie klastrów przechowywania, w których dane są automatycznie replikowane i równomiernie rozproszone między węzłami klastra. Dzięki temu Ceph zapewnia nie tylko wysoką dostępność, ale także odporność na awarie.
GlusterFS: Jest to rozproszony system plików, który umożliwia łączenie dysków twardych wielu maszyn w jeden wirtualny magazyn danych. GlusterFS oferuje skalowalność i elastyczność, a także umożliwia tworzenie replikacji i migawek.
LizardFS: Jest to system plików oparty na rozproszonym modelu, który pozwala na tworzenie wirtualnego magazynu danych z dysków twardych różnych maszyn. LizardFS dostarcza mechanizmy replikacji i wyważania obciążenia, co przyczynia się do wysokiej dostępności.

7. Failover

Failover to proces automatycznego przełączania na redundantny lub zapasowy serwer, system, komponent sprzętowy lub sieć w przypadku awarii lub nieprawidłowego zakończenia działania wcześniej aktywnej aplikacji, serwera, systemu, komponentu sprzętowego lub sieci komputerowej.

8. Redundancja i Replikacja

Redundancja to nadmiarowość w stosunku do tego, co konieczne. W kontekście HA, redundancja odnosi się do powielania danych, elementów systemu oraz fizycznych składowych infrastruktury technicznej (serwerów, switchy) w celu zabezpieczenia na wypadek awarii lub uszkodzenia części systemu. Redundancja jest stosowana w celu zwiększenia niezawodności i ciągłości działania klastrów i systemów HA np. w przypadku awarii switcha następuje automatyczne przełączenie na switch zapasowy.

Replikacja to proces powielania, którego celem jest uzyskanie co najmniej jednej kopii danego obiektu. W praktyce replikacja polega na utworzeniu kopii danych zawartych w podstawowym serwerze i umieszczeniu ich w serwerze/serwerach zapasowych lub na utworzeniu kopii danych z podstawowego centrum danych i umieszczeniu ich w zapasowym centrum danych, aby utrzymać możliwość dostępu do danych w przypadku zniszczenia lub awarii podstawowego repozytorium danych.

Tworzenie rozwiązania HA (High Availability) jest procesem skomplikowanym, który wymaga zrozumienia wielu aspektów technicznych. W kolejnych artykułach opiszę po kolei etapy tworzenia takiego rozwiązania, skupiając się na praktycznych aspektach związanych z budową klastra HA. Natomiast jeśli już na tym etapie masz jakiś pytanie, zapraszam do kontaktu.