[comment]: # (tags: HA, high-availability)

[comment]: # ({486cd6dc-fb8f0d5a})
# 1 Wysoka dostępność

[comment]: # ({/486cd6dc-fb8f0d5a})

[comment]: # ({f0a123dd-ea8bc3db})
### 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.

![](../../../../assets/en/manual/config/zabbix_ha.png)

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](#implementation-details)

[comment]: # ({/f0a123dd-ea8bc3db})

[comment]: # ({c6caa06e-567d3671})
### Włączanie wysokiej dostępności

[comment]: # ({/c6caa06e-567d3671})

[comment]: # ({5a71328e-23e81771})
##### Uruchamianie serwera Zabbix jako węzła klastra

Do uruchomienia serwera Zabbix jako węzła klastra wymagane są dwa parametry w [konfiguracji](/manual/appendix/config/zabbix_server) 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](/manual/web_interface/frontend_sections/reports/status_of_zabbix#high-availability-nodes)*, 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):

![](../../../../assets/en/manual/config/runtime_ha_status.png){width="600"}

[comment]: # ({/5a71328e-23e81771})

[comment]: # ({3c7b24e0-3e9035e5})
##### 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).

![](../../../../assets/en/manual/config/frontend_conf_server_port.png){width="600"}

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.

[comment]: # ({/3c7b24e0-3e9035e5})

[comment]: # ({892555c1-d47b6ef3})
##### 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](/manual/appendix/config/zabbix_proxy) 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](/manual/appendix/config/zabbix_proxy) proxy, rozdzielone **średnikiem**.
```
Server=zabbix-node-01;zabbix-node-02
```

[comment]: # ({/892555c1-d47b6ef3})

[comment]: # ({c15c2c86-f2fc0e77})
##### Konfiguracja agent

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

![](../../../../assets/en/manual/config/zabbix_ha_agent.png)

Aby włączyć pasywne sprawdzenia, nazwy węzłów muszą być wymienione w parametrze Server [parameter](/manual/appendix/config/zabbix_agentd), 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](/manual/appendix/config/zabbix_agentd).
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
```

[comment]: # ({/c15c2c86-f2fc0e77})

[comment]: # ({e3a57230-311341fc})
### 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
```

[comment]: # ({/e3a57230-311341fc})

[comment]: # ({7be5c016-593144b8})
### Zarządzanie klastrem HA

Bieżący stan klastra HA można zarządzać za pomocą dedykowanych opcji [runtime control](/manual/concepts/server#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](/manual/web_interface/frontend_sections/reports/status_of_zabbix#high-availability-nodes)*.
-   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.

[comment]: # ({/7be5c016-593144b8})

[comment]: # ({7cfdcc75-82cd7e56})
### 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).

[comment]: # ({/7cfdcc75-82cd7e56})

[comment]: # ({48f303fd-7d944a36})
### 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](/manual/installation/upgrade) 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.

[comment]: # ({/48f303fd-7d944a36})

[comment]: # ({de56f189-f4d3143a})
### 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.

[comment]: # ({/de56f189-f4d3143a})