Wysoka dostępność usług
 
Celem klastrów wysokiej dostępności (High Availability) jest podtrzymanie działających w nich usług tak długo, jak to tylko możliwe. Najczęściej węzły tworzące taki klaster monitorują się wzajemnie i w razie awarii czy dysfunkcji któregoś z nich zajmują się jego wyizolowaniem, a następnie przejęciem czy migracją usług na zdrowy węzeł.
 

Wyróżnia się klastry wysokiej dostępności, które działają w architekturze:
  • Active/Active, gdzie usługi działają na wielu węzłach równocześnie.
  • Active/Passive, gdzie usługi działają tylko na jednym z węzłów w danym czasie.
Cały klaster aplikacyjny może być też na tyle złożony, że tworzące go komponenty poszczególnych usług mogą działać w różnych architekturach. Na wybór danej architektury dla danej usługi ma wpływ wiele czynników, jak m.in. lokalizacja węzłów, opóźnienia i przepustowość sieci pomiędzy węzłami czy architektura klastrowanej usługi/aplikacji.
 
Wiele z usług i baz danych posiada wbudowane mechanizmy do tworzenia klastrów. Przykładem jest m.in. MariaDB Galera, DAG (Database Availability Groups) w Microsoft Exchange, Dovecot (POP3/IMAP/LMTP) w GNU/Linux, zasoby plikowe Red Hat Gluster Storage czy działające w architekturze master/slave lub master/master usługi DNS i LDAP. Oczywiście usługi te także można klastrować dedykowanymi do tego celu rozwiązaniami, jak Red Hat High Availability, Red Hat Resilient Storage czy LINBIT High Availability. Niemniej, nie zawsze ma to sens.

Dla wielu aplikacji i usług wystarczy poziom niezawodności, jaki może zapewnić nam platforma do wirtualizacji. Niemniej, usługi wewnątrz platform do wirtualizacji także mogą być i często są tworzone w formie klastrów, składających się z wielu maszyn wirtualnych o konkretnym zastosowaniu.

Najczęściej klastry wysokiej dostępności buduje się dla baz danych, jak MariaDB/MySQL, PostgreSQL, Oracle DB i Redis, serwerów plików z obsługą NFS, Samba, AFP (Apple File protocol) i FTP, rozwiązań pamięci masowej (ang. storage) z obsługą iSCSI, FC i FCoE oraz całych stosów aplikacyjnych jak SAP HANA, usługi webowe, serwery pocztowe czy platforma usług chmury prywatnej Nextcloud.

Zaintersowanych budową klastrów wysokiej dostępności zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it.! Jako, że do każdej z usług i aplikacji warto podejść indywidualnie, zachęcamy do kontaktu jeszcze przed wyborem docelowej architektury.

Przed uruchomieniem usług na innym węźle klastra trzeba się upewnić, że nie doprowadzi to do uszkodzenia danych. Podobnie, kiedy w klastrze jeden z węzłów przestanie prawidłowo się zachowywać lub całkiem odpowiadać. W zasadzie, to nie możemy zakładać, że węzeł który przestał odpowiadać jest faktycznie prawidłowo wyłączony.
Stąd przy budowie klastrów wysokiej dostępności stosuje się Fencing. Dba on o to, aby taki dysfunkcyjny węzeł został zgaszony i wyizolowany, czyli wyłączony na poziomie sprzętu, środowiska do wirtualizacji, systemu UPS czy zarządzanej listwy zasilającej oraz odłączony od pamięci masowej, gdzie znajdują się dane.

Aby Fencing mógł zadziałać prawidłowo, działające prawidłowo węzły klastra muszą mieć dostęp do pewnych elementów infrastruktury węzła dysfunkcyjnego, jak m.in. interfejs zarządzania serwerem CIMC/iLO/DRAC/IPMI, środowiska do wirtualizacji, systemu podtrzymania napięcia czy dostęp do przełącznika FC (Fiber Channel) lub storage (SCSI reservations w iSCSI/FC/FCoE lub VM leases). Najlepiej, aby taki dostęp nie był tracony wraz z utratą połączenia do dysfunkcyjnego czy wyizolowanego węzła.
 
Jest to bardzo istotna rzecz i niestety często się o niej zapomina, ryzykując utratę czy uszkodzenie danych.

O tym, który węzeł powinien zostać wykluczony z klastra decyduje większość tworząca kworum (łac. quorum). Do spełnienia kworum potrzebne jest minimum 51% głosów, a każdy z węzłów zwykle posiada 1-głos. Dla klastrów z dwoma węzłami istnieją specjalne konfiguracje i wyjątki. Kworum jest także potrzebne do uruchomienia usług w klastrze. Zanim się to stanie, realizowany jest Fencing w kierunku wszystkich węzłów, które nie oddały głosu. W ten sposób mamy pewność, że dysfunkcyjne węzły nie mają dostępu do danych i nie dojdzie do ich uszkodzenia.

Co istotne, nie należy mylić mechanizmów HA (High Availability) i DR (Disaster Recovery). Każde z nich ma swoje miejsce i zastosowanie. Mechanizmy High Availability mają zapewnić działanie usług w przypadku mniejszych i bardziej lokalnych awarii. Natomiast w przypadku większej czy bardziej globalnej awarii warto dodatkowo pomyśleć o takich rozwiązaniach, jak VMware SRM, LINBIT Disaster Recovery czy Red Hat Disaster Recovery.

Zainteresowanych zakupem rozwiązań do budowy klasterów wysokiej dostępności i rozkładu obciążenia, zapraszamy do This email address is being protected from spambots. You need JavaScript enabled to view it.. Jako, że przy budowie klasterów do każdej z usług i aplikacji warto podejść indywidualnie, zachęcamy do kontaktu jeszcze przed wyborem docelowej architektury.

Inną cechą klastrów wysokiej dostępności jest rozkład obciążenia (ang. Load Balancing) i kierowanie ruchu tylko do działających czy nieobciążonych węzłów klastra. Do takich celów polecamy m.in. rozwiązania firmy F5, Red Hat Load Balancer czy MariaDB MaxScale. Wybór konkretnych rozwiązań jest tutaj bardzo zależny od typu aplikacji czy ruchu, jaki ma podlegać obsłudze. W niektórych przypadkach, jak serwery głosowe SIP (Session Initiation Protocol) wystarczy do tego celu sama usługa DNS (Domain Name System).
 
Znaczenie ma też poziom zrozumienia obsługiwanych protokołów przez load balancer. Dla przykładu, o ile ruch do baz danych można rozkładać na poziomie TCP, to jeżeli potrzebujemy różne zapytania SQL kierować do różnych węzłów klastra, to potrzebny jest już specjalny load Balancer SQL, jak MariaDB MaxScale. Przykładem może być potrzeba wysyłania samych zapytań SELECT do węzłów Slave, a zapytań UPDATE/INSERT/DELETE do węzła Master.

Klastry wysokiej dostępności budowane są w celu zapewnienia stosownego SLA (Service Level Agreement), które zwykle wynosi od 99% do 99,99%. To, ile jest to mniej więcej w skali miesiąca, tygodnia czy roku (365-dni), zostało przedstawione w poniższej tabeli (wartości zaokrąglone w dół).
Dostępność SLA     Niedostępność tygodniowa     Niedostępność miesięczna     Niedostępność roczna    
90% 16h:45m 72h:00m 36d:12h (876h)
95% 08h:20m 36h:00m 8d:6h (438h)
98% 03h:20m 14h:20m 7d:7h (175h)
99% 01h:40m 07h:10m 87h:30m
99,5% 00h:50m 03h:30m 43h:45m
99,8% 00h:20m 01h:20m 17h:30m
99,9% 00h:10m 00h:40m 08h:45m
99,95% 00h:05m 00h:20m 04h:20m
99,98% 00h:02m 00h:08m 01h:45m
99,99% 00h:01m 00h:04m 00h:52m

Należy pamiętać o tym, że im większe wymagania co do SLA, tym na większej ilości poziomach wymagane jest zapewnienie redundancji i stosownych mechanizmów wysokiej dostępności. Dotyczy to nie tylko usług samej aplikacji. Warto pamiętać też o sieci, zasilaniu, chłodzeniu, łączach do sieci Internet oraz pamięci masowej.

Przy wyborze pamięci masowej warto rozważyć wykorzystanie rozwiązań SDS (Software-Defined Storage), jak m.in. LINBIT SDS, Red Hat Ceph Storage, Red Hat Gluster Storage, Cisco HyperFlex czy VMware vSAN lub replikacji blokowej pomiędzy dyskami serwerów fizycznych lub wirtualnych, tak aby wszystkie dane były zawsze dostępne na węźle zapasowym. Da się ją zrealizować dzięki LINBIT High Availability. W przypadku klasterów Active/Active dodatkowo warto wykorzystać klastrowy system plików, który umożliwia jednoczesny dostęp do dysku przez wiele systemów. Jest on dostępny w ramach Red Hat Resilient Storage.

Jeżeli aplikacja ma być także wysoko dostępna z publicznej sieci Internet, to trzeba dodatkowo rozważyć wykorzystanie adresów PI (Provider Independent) dla IPv4/IPv6 lub serwerów DNS, które są w stanie szybko przełączyć nasze domeny na adresy IP innego operatora.

Wysoka dostępność nie tylko wymaga pewnej redundancji na poziomie sprzętu. Powiązana jest też z dużą ilością różnych mechanizmów i protokołów, jakie trzeba skonfigurować na poziomie urządzeń sieciowych, pamięci masowej (ang. storage), środowisk do wirtualizacji czy w systemach operacyjnych.
 
Jest ich naprawdę sporo i nie raz spotkaliśmy już z próbą użycia niewłaściwych. Dlatego naprawdę zachęcamy do kontaktu w tym obszarze jeszcze przed wyborem docelowej architektury.

Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.