1 Wysoka dostępność

Omówienie

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

Zabbix oferuje natywne rozwiązanie wysokiej dostępności, które jest łatwe w konfiguracji i nie wymaga wcześniejszego doświadczenia z HA. Natywna HA Zabbixa może być przydatna jako dodatkowa warstwa ochrony przed awariami oprogramowania/sprzętu serwera Zabbix lub w celu skrócenia przestojów związanych z konserwacją.

W trybie wysokiej dostępności Zabbixa 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, przygotowane do przejęcia działania w razie potrzeby.

Przejście na HA Zabbixa nie jest wiążące. W dowolnym momencie można wró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), pod którym serwer będzie identyfikowany w konfiguracjach agenta i proxy. Jeśli nie określisz HANodeName, serwer zostanie uruchomiony w trybie autonomicznym.

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

Parametr NodeAddress (address: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 status serwerów można zobaczyć w Raporty > Informacje o systemie, a także po uruchomieniu:

zabbix_server -R ha_status

To polecenie wykonywane w czasie działania zapisze bieżący status klastra HA do logu serwera Zabbix (oraz na stdout):

Przygotowanie frontend

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

Frontend Zabbix automatycznie wykryje aktywny węzeł, odczytując ustawienia z tabeli nodes w bazie danych Zabbix. Adres węzła aktywnego będzie używany 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ć wymienione w parametrze Server parameter proxy, rozdzielone przecinkiem.

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

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

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

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

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

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

Aby włączyć aktywne sprawdzenia, nazwy węzłów muszą być wymienione w parametrze ServerActive parameter. Należy pamiętać, że w przypadku aktywnych sprawdzeń węzły muszą być oddzielone przecinkiem od 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ł rezerwowy

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

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 zamknięty i zdoła zgłosić swój status jako "stopped", inny węzeł przejmie działanie w ciągu 5 sekund.
  • Jeśli aktywny węzeł zostanie zamknięty / stanie się niedostępny bez możliwości aktualizacji swojego statusu, węzły rezerwowe będą czekać opóźnienie przełączenia awaryjnego + 5 sekund przed przejęciem działania.

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żesz 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 runtime control:

  • ha_status - zapisuje status klastra HA w logu serwera Zabbix (oraz na stdout);
  • ha_remove_node=target - usuwa węzeł HA zidentyfikowany przez jego <target> - nazwę lub ID węzła (nazwę/ID można uzyskać z wyniku działania ha_status), np.:
zabbix_server -R ha_remove_node=zabbix-node-02

Należy pamiętać, że aktywne/w trybie standby 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ła można monitorować:

  • W Reports > System information.
  • W widżecie pulpitu System information.
  • Za pomocą opcji runtime control ha_status serwera (patrz wyżej).

Do wykrywania węzłów można użyć wewnętrznej pozycji zabbix[cluster,discovery,nodes], ponieważ zwraca ona JSON z informacjami o węzłach wysokiej dostępności.

Wyłączanie klastra HA

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

  1. Utwórz kopie zapasowe plików konfiguracyjnych.
  2. Zatrzymaj węzły rezerwowe.
  3. Usuń parametr HANodeName z aktywnego serwera głównego.
  4. Uruchom ponownie serwer główny (zostanie uruchomiony w trybie autonomicznym).

Aktualizacja klastra HA

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

  1. Zatrzymaj wszystkie węzły.
  2. Utwórz pełną kopię zapasową bazy danych.
  3. Jeśli baza danych używa replikacji, upewnij się, że wszystkie węzły są zsynchronizowane i nie występują żadne problemy. Nie wykonuj aktualizacji, jeśli replikacja jest uszkodzona.
  4. Wybierz jeden węzeł, który wykona aktualizację bazy danych, zmień jego konfigurację na tryb standalone, komentując HANodeName, i zaktualizuj go.
  5. Upewnij się, że aktualizacja bazy danych została w pełni zakończona (System information powinno wyświetlać, że serwer Zabbix działa).
  6. Uruchom ponownie węzeł w trybie HA.
  7. Zaktualizuj i uruchom pozostałe węzły (nie ma potrzeby przełączania ich do trybu standalone, ponieważ baza danych jest już w tym momencie zaktualizowana).

W przypadku aktualizacji do wersji minor wystarczy zaktualizować pierwszy węzeł, upewnić się, że został zaktualizowany i działa, a następnie rozpocząć aktualizację następnego 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ń dotyczących baz danych rozpoznawanych przez Zabbix. Użytkownicy mogą korzystać z natywnego rozwiązania HA Zabbix albo 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 lub węzłów zabbix_server. Każdy węzeł:

  • Jest konfigurowany oddzielnie.
  • Korzysta z tej samej bazy danych.
  • Może mieć kilka trybów: active, standby, unavailable, stopped.

Tylko jeden węzeł może być aktywny (working) w danym momencie. Węzeł standby uruchamia tylko jeden proces - menedżer HA. Węzeł standby nie wykonuje zbierania danych, przetwarzania ani innych standardowych 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ą swój czas ostatniego dostępu co 5 sekund. Każdy węzeł standby monitoruje czas ostatniego dostępu węzła active. Jeśli czas ostatniego dostępu węzła active przekroczy liczbę sekund 'failover delay', węzeł standby sam przełącza się na węzeł active i przypisuje status unavailable wcześniej aktywnemu węzłowi.

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

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