1 Wysoka dostępność

Przegląd

Wysoka dostępność (HA) jest zwykle wymagana w infrastrukturach krytycznych, które mogą sobie pozwolić praktycznie na zerowy czas przestoju. Dlatego dla każdej usługi, która może ulec awarii, musi istnieć opcja przełączenia awaryjnego, aby przejąć jej działanie w przypadku awarii aktualnie działającej usługi.

Zabbix oferuje natywne rozwiązanie wysokiej dostępności, które jest łatwe w konfiguracji i nie wymaga wcześniejszej wiedzy specjalistycznej z zakresu HA. Natywne HA w Zabbix może być przydatne jako dodatkowa warstwa ochrony przed awariami oprogramowania/sprzętu serwer Zabbix lub w celu ograniczenia przestojów związanych z konserwacją.

W trybie wysokiej dostępności Zabbix wiele serwerów Zabbix działa jako węzły w klastrze. Gdy jeden serwer Zabbix w klastrze jest aktywny, pozostałe pozostają w trybie gotowości, gotowe do przejęcia jego roli w razie potrzeby.

Przejście na HA w Zabbix nie jest zobowiązujące. W dowolnym momencie można powrócić do pracy w trybie samodzielnym.

Zobacz także: Szczegóły implementacji

Włączanie wysokiej dostępności

Uruchamianie serwera Zabbix jako węzła klastra

Do uruchomienia serwera Zabbix jako węzła klastra wymagane są dwa parametry w konfiguracji serwera:

  • Parametr HANodeName musi być określony dla każdego serwera Zabbix, który będzie węzłem klastra HA.

Jest to unikalny identyfikator węzła (np. zabbix-node-01), do którego serwer będzie się odwoływał w konfiguracjach agent i proxy. Jeśli nie określisz HANodeName, serwer zostanie uruchomiony w trybie samodzielnym.

  • Parametr NodeAddress musi być określony dla każdego węzła.

Parametr NodeAddress (adres:port) będzie używany przez frontend Zabbix do łączenia się z aktywnym węzłem serwera. NodeAddress musi odpowiadać adresowi IP lub nazwie FQDN odpowiedniego serwera Zabbix.

Po wprowadzeniu zmian w plikach konfiguracyjnych uruchom ponownie wszystkie serwery Zabbix. Zostaną one teraz uruchomione jako węzły klastra. Nowy stan serwerów można zobaczyć w sekcji Raporty → Informacje o systemie, a także po uruchomieniu:

zabbix_server -R ha_status

To polecenie runtime zapisze bieżący stan klastra HA w logu serwera Zabbix (oraz na stdout):

Przygotowanie frontend

Upewnij się, że adres:port serwera Zabbix nie jest zdefiniowany w konfiguracji frontendu (znajdującej się w conf/zabbix.conf.php w katalogu plików frontendu).

Frontend Zabbix automatycznie wykryje aktywny węzeł, odczytując ustawienia z tabeli nodes w bazie danych Zabbix. Adres węzła aktywnego zostanie użyty jako adres serwera Zabbix.

Konfiguracja proxy

Węzły klastra HA (serwery) muszą być wymienione w konfiguracji pasywnego lub aktywnego proxy Zabbix.

W przypadku pasywnego proxy nazwy węzłów muszą być podane w parametrze Server parameter proxy, oddzielone przecinkiem.

Server=zabbix-node-01,zabbix-node-02

W przypadku aktywnego proxy nazwy węzłów muszą być podane w parametrze Server parameter proxy, oddzielone średnikiem.

Server=zabbix-node-01;zabbix-node-02
Konfiguracja agenta

Węzły klastra HA (serwery) muszą być wymienione w konfiguracji Zabbix agent lub Zabbix agent 2.

Aby włączyć sprawdzenia pasywne, nazwy węzłów muszą być wymienione w parametrze Server parameter, oddzielone przecinkiem.

Server=zabbix-node-01,zabbix-node-02

Aby włączyć sprawdzenia aktywne, nazwy węzłów muszą być wymienione w parametrze ServerActive parameter. Należy pamiętać, że w przypadku sprawdzeń aktywnych węzły muszą być oddzielone przecinkiem od wszelkich innych serwerów, natomiast same węzły muszą być oddzielone średnikiem, np.:

ServerActive=zabbix-node-01;zabbix-node-02

Przełączenie awaryjne na węzeł zapasowy

Zabbix automatycznie przełączy się awaryjnie na inny węzeł, jeśli aktywny węzeł przestanie działać. Aby przełączenie awaryjne mogło nastąpić, co najmniej jeden węzeł musi mieć status standby.

Jak szybko nastąpi przełączenie awaryjne? Wszystkie węzły aktualizują czas ostatniego dostępu (oraz status, jeśli uległ zmianie) co 5 sekund. Zatem:

  • Jeśli aktywny węzeł zostanie wyłączony i zdoła zgłosić swój status jako "stopped", inny węzeł przejmie jego rolę w ciągu 5 sekund.

  • Jeśli aktywny węzeł zostanie wyłączony lub stanie się niedostępny bez możliwości zaktualizowania swojego statusu, węzły standby będą czekać opóźnienie przełączenia awaryjnego + 5 sekund, zanim przejmą jego rolę

Opóźnienie przełączenia awaryjnego jest konfigurowalne, a obsługiwany zakres wynosi od 10 sekund do 15 minut (domyślnie jedna minuta). Aby zmienić opóźnienie przełączenia awaryjnego, można uruchomić:

zabbix_server -R ha_set_failover_delay=5m

Zarządzanie klastrem HA

Bieżący stan klastra HA można zarządzać za pomocą dedykowanych opcji kontroli w czasie działania:

  • ha_status — zapisuje stan klastra HA w logu serwera Zabbix (oraz na stdout)
  • ha_remove_node=target — usuwa węzeł HA zidentyfikowany przez <target> — nazwę lub ID węzła (nazwę/ID można uzyskać z danych wyjściowych polecenia ha_status), np.:
zabbix_server -R ha_remove_node=zabbix-node-02

Należy pamiętać, że aktywne/zapasowe węzły nie mogą zostać usunięte.

  • ha_set_failover_delay=delay — ustawia opóźnienie przełączenia awaryjnego HA (od 10 sekund do 15 minut; obsługiwane są sufiksy czasu, np. 10s, 1m)

Stan węzłów można monitorować:

  • w Raporty → Informacje o systemie
  • w widżecie pulpitu Informacje o systemie
  • za pomocą opcji kontroli w czasie działania ha_status serwera (zobacz powyżej).

Wewnętrzna pozycja zabbix[cluster,discovery,nodes] może być używana do wykrywania węzłów, ponieważ zwraca JSON z informacjami o węzłach wysokiej dostępności.

Wyłączanie klastra HA

Aby wyłączyć klaster wysokiej dostępności:

  • wykonaj kopie zapasowe plików konfiguracyjnych
  • zatrzymaj węzły zapasowe
  • usuń parametr HANodeName z aktywnego głównego serwera
  • uruchom ponownie główny serwer (zostanie uruchomiony w trybie samodzielnym)

Aktualizacja klastra HA

Aby przeprowadzić aktualizację głównej wersji dla węzłów HA:

  • zatrzymaj wszystkie węzły;
  • utwórz pełną kopię zapasową bazy danych;
  • jeśli baza danych używa replikacji, upewnij się, że wszystkie węzły są zsynchronizowane i nie występują żadne problemy. Nie przeprowadzaj aktualizacji, jeśli replikacja jest uszkodzona.
  • wybierz jeden węzeł, który przeprowadzi aktualizację bazy danych, zmień jego konfigurację na tryb standalone, komentując parametr HANodeName, i zaktualizuj go;
  • upewnij się, że aktualizacja bazy danych została w pełni zakończona (Informacje o systemie powinny wskazywać, że serwer Zabbix jest uruchomiony);
  • uruchom ponownie węzeł w trybie HA;
  • zaktualizuj i uruchom pozostałe węzły (nie ma potrzeby przełączania ich do trybu standalone, ponieważ na tym etapie baza danych jest już zaktualizowana).

W przypadku aktualizacji wersji pobocznej wystarczy zaktualizować pierwszy węzeł, upewnić się, że został zaktualizowany i działa, a następnie rozpocząć aktualizację kolejnego węzła.

Szczegóły implementacji

Klaster wysokiej dostępności (HA) jest rozwiązaniem opcjonalnym i jest obsługiwany dla serwera Zabbix. Natywne rozwiązanie HA zostało zaprojektowane tak, aby było proste w użyciu, działało między lokalizacjami i nie miało szczególnych wymagań wobec baz danych obsługiwanych przez Zabbix. Użytkownicy mogą korzystać z natywnego rozwiązania Zabbix HA lub z rozwiązania HA innej firmy, w zależności od tego, co najlepiej odpowiada wymaganiom wysokiej dostępności w ich środowisku.

Rozwiązanie składa się z wielu instancji zabbix_server lub węzłów. Każdy węzeł:

  • jest konfigurowany oddzielnie
  • używa tej samej bazy danych
  • może działać w kilku trybach: active, standby, unavailable, stopped

W danym momencie aktywny (działający) może być tylko jeden węzeł. Węzeł standby uruchamia tylko jeden proces — menedżera HA. Węzeł standby nie zbiera danych, nie przetwarza ich ani nie wykonuje innych regularnych działań serwera; nie nasłuchuje na portach; ma minimalną liczbę połączeń z bazą danych.

Zarówno węzły active, jak i standby aktualizują czas ostatniego dostępu co 5 sekund. Każdy węzeł standby monitoruje czas ostatniego dostępu aktywnego węzła. Jeśli czas ostatniego dostępu aktywnego węzła przekroczy wartość 'failover delay' sekund, węzeł standby przełącza się na aktywny i przypisuje status 'unavailable' wcześniej aktywnemu węzłowi.

Aktywny węzeł monitoruje własną łączność z bazą danych — jeśli zostanie ona utracona na dłużej niż failover delay-5 sekund, musi zatrzymać całe przetwarzanie i przełączyć się w tryb standby. Aktywny węzeł monitoruje również status węzłów standby — jeśli czas ostatniego dostępu węzła standby przekroczy wartość 'failover delay' sekund, temu węzłowi standby zostaje przypisany status 'unavailable'.

Węzły zostały zaprojektowane tak, aby były kompatybilne między pomniejszymi wersjami Zabbix.