L'alta disponibilità (HA) è in genere richiesta nelle infrastrutture critiche che possono permettersi virtualmente nessun tempo di inattività. Pertanto, per qualsiasi servizio che possa guastarsi, deve essere prevista un'opzione di failover che subentri nel caso in cui il servizio corrente fallisca.

Zabbix offre una soluzione di alta disponibilità nativa facile da configurare e che non richiede alcuna precedente esperienza con l'HA. L'HA nativa di Zabbix può essere utile come ulteriore livello di protezione contro guasti software/hardware del server Zabbix o per ridurre i tempi di inattività dovuti alla manutenzione.

Nella modalità di alta disponibilità di Zabbix, più server Zabbix vengono eseguiti come nodi in un cluster. Mentre un server Zabbix nel cluster è attivo, gli altri sono in standby, pronti a subentrare se necessario.

Il passaggio a Zabbix HA non è vincolante. È possibile tornare al funzionamento standalone in qualsiasi momento.

Vedi anche: Dettagli di implementazione

Abilitazione dell'alta disponibilità

Avvio di Zabbix server come nodo del cluster

Per avviare un server Zabbix come nodo del cluster sono richiesti due parametri nella configurazione del server:

HANodeName deve essere specificato per ogni server Zabbix che sarà un nodo del cluster HA.

Si tratta di un identificatore univoco del nodo (ad esempio zabbix-node-01) con cui il server sarà indicato nelle configurazioni di agent e proxy. Se non si specifica HANodeName, il server verrà avviato in modalità standalone.

NodeAddress deve essere specificato per ogni nodo.

Il parametro NodeAddress (indirizzo:porta) verrà utilizzato dal frontend di Zabbix per connettersi al nodo server attivo. NodeAddress deve corrispondere all'IP o al nome FQDN del rispettivo server Zabbix.

Riavviare tutti i server Zabbix dopo aver apportato modifiche ai file di configurazione. A questo punto verranno avviati come nodi del cluster. Il nuovo stato dei server può essere visualizzato in Report → Informazioni di sistema e anche eseguendo:

zabbix_server -R ha_status

Questo comando runtime registrerà lo stato corrente del cluster HA nel log di Zabbix server (e nello stdout):

Preparazione del frontend

Assicurarsi che l'indirizzo:porta del server Zabbix non sia definito nella configurazione del frontend (presente in conf/zabbix.conf.php nella directory dei file del frontend).

Il frontend di Zabbix rileverà automaticamente il nodo attivo leggendo le impostazioni dalla tabella nodes nel database di Zabbix. L'indirizzo del nodo attivo verrà utilizzato come indirizzo del server Zabbix.

Configurazione del proxy

I nodi del cluster HA (server) devono essere elencati nella configurazione di un proxy Zabbix passivo o attivo.

Per un proxy passivo, i nomi dei nodi devono essere elencati nel parameter Server del proxy, separati da una virgola.

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

Per un proxy attivo, i nomi dei nodi devono essere elencati nel parameter Server del proxy, separati da un punto e virgola.

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

Configurazione dell'agent

I nodi del cluster HA (server) devono essere elencati nella configurazione di Zabbix agent o Zabbix agent 2.

Per abilitare i controlli passivi, i nomi dei nodi devono essere elencati nel parametro Server, separati da una virgola.

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

Per abilitare i controlli attivi, i nomi dei nodi devono essere elencati nel parametro ServerActive. Si noti che per i controlli attivi i nodi devono essere separati da una virgola da eventuali altri server, mentre i nodi stessi devono essere separati da un punto e virgola, ad esempio:

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

Failover al nodo di standby

Zabbix eseguirà automaticamente il failover a un altro nodo se il nodo attivo si arresta. Deve esserci almeno un nodo nello stato standby affinché il failover possa avvenire.

Quanto sarà rapido il failover? Tutti i nodi aggiornano l'ora dell'ultimo accesso (e lo stato, se viene modificato) ogni 5 secondi. Quindi:

Se il nodo attivo si arresta e riesce a segnalare il proprio stato come "stopped", un altro nodo subentrerà entro 5 secondi.
Se il nodo attivo si arresta/diventa non disponibile senza poter aggiornare il proprio stato, i nodi standby attenderanno il ritardo di failover + 5 secondi prima di subentrare

Il ritardo di failover è configurabile, con un intervallo supportato compreso tra 10 secondi e 15 minuti (un minuto per impostazione predefinita). Per modificare il ritardo di failover, è possibile eseguire:

zabbix_server -R ha_set_failover_delay=5m

Gestione del cluster HA

Lo stato attuale del cluster HA può essere gestito utilizzando le opzioni dedicate di runtime control:

ha_status - registra lo stato del cluster HA nel log del server Zabbix (e su stdout)
ha_remove_node=target - rimuove un nodo HA identificato dal suo <target> - nome o ID del nodo (nome/ID possono essere ottenuti dall'output dell'esecuzione di ha_status), ad esempio:

zabbix_server -R ha_remove_node=zabbix-node-02

Si noti che i nodi attivi/in standby non possono essere rimossi.

ha_set_failover_delay=delay - imposta il ritardo di failover HA (tra 10 secondi e 15 minuti; i suffissi temporali sono supportati, ad esempio 10s, 1m)

Lo stato del nodo può essere monitorato:

in Report → Informazioni di sistema
nel widget della dashboard Informazioni di sistema
utilizzando l'opzione di runtime control ha_status del server (vedere sopra).

L'item interno zabbix[cluster,discovery,nodes] può essere utilizzato per il rilevamento dei nodi, poiché restituisce un JSON con le informazioni sui nodi ad alta disponibilità.

Disabilitazione del cluster HA

Per disabilitare un cluster ad alta disponibilità:

creare copie di backup dei file di configurazione
arrestare i nodi standby
rimuovere il parametro HANodeName dal server primario attivo
riavviare il server primario (si avvierà in modalità standalone)

Aggiornamento del cluster HA

Per eseguire un aggiornamento di versione principale dei nodi HA:

arrestare tutti i nodi;
creare un backup completo del database;
se il database utilizza la replica, assicurarsi che tutti i nodi siano sincronizzati e non presentino problemi. Non eseguire l'aggiornamento se la replica è interrotta.
selezionare un singolo nodo che eseguirà l'aggiornamento del database, modificarne la configurazione in modalità standalone commentando HANodeName ed eseguire l'aggiornamento;
assicurarsi che l'aggiornamento del database sia stato completato interamente (Informazioni di sistema dovrebbe indicare che Zabbix server è in esecuzione);
riavviare il nodo in modalità HA;
aggiornare e avviare il resto dei nodi (non è necessario modificarli in modalità standalone, poiché a questo punto il database è già stato aggiornato).

Per un aggiornamento di versione secondaria è sufficiente aggiornare il primo nodo, assicurarsi che sia stato aggiornato e sia in esecuzione, quindi avviare l'aggiornamento del nodo successivo.

Dettagli di implementazione

Il cluster ad alta disponibilità (HA) è una soluzione opzionale ed è supportato per Zabbix server. La soluzione HA nativa è progettata per essere semplice da usare, funziona tra siti diversi e non ha requisiti specifici per i database riconosciuti da Zabbix. Gli utenti sono liberi di utilizzare la soluzione HA nativa di Zabbix oppure una soluzione HA di terze parti, a seconda di quale si adatti meglio ai requisiti di alta disponibilità del loro ambiente.

La soluzione è composta da più istanze o nodi di zabbix_server. Ogni nodo:

è configurato separatamente
utilizza lo stesso database
può avere diverse modalità: active, standby, unavailable, stopped

Solo un nodo può essere active (in funzione) alla volta. Un nodo standby esegue un solo processo: l'HA manager. Un nodo standby non esegue raccolta dati, elaborazione o altre normali attività del server; non resta in ascolto sulle porte; ha un numero minimo di connessioni al database.

Sia i nodi active che quelli standby aggiornano il proprio ultimo orario di accesso ogni 5 secondi. Ogni nodo standby monitora l'ultimo orario di accesso del nodo active. Se l'ultimo orario di accesso del nodo active supera i secondi di 'failover delay', il nodo standby passa automaticamente a nodo active e assegna lo stato 'unavailable' al nodo precedentemente active.

Il nodo active monitora la propria connettività al database: se viene persa per più di failover delay-5 secondi, deve interrompere tutta l'elaborazione e passare alla modalità standby. Il nodo active monitora anche lo stato dei nodi standby: se l'ultimo orario di accesso di un nodo standby supera i secondi di 'failover delay', al nodo standby viene assegnato lo stato 'unavailable'.

I nodi sono progettati per essere compatibili tra versioni secondarie di Zabbix.

What’s next?

2 Agent

Docs

1 Alta disponibilità

Panoramica