Áú»¢¶Ä²©

1 Cluster de alta disponibilidade

Vis?o geral

O modo de alta disponibilidade oferece prote??o contra falhas de software/hardware para o Áú»¢¶Ä²© Server e permite minimizar o tempo de parada durante manuten??es de software/hardware.

O cluster de alta disponibilidade (HA) ¨¦ uma solu??o opcional (opt-in) e ¨¦ suportada para Áú»¢¶Ä²© Server. A solu??o de HA nativa ¨¦ projetada para ser simples de usar, funcionar¨¢ entre sites e n?o possui requisitos espec¨ªficos para os bancos de dados que o Áú»¢¶Ä²© reconhece. Os usu¨¢rios s?o livres para utilizar a solu??o de HA nativa do Áú»¢¶Ä²©, ou uma solu??o de HA de terceiros, dependendo do que melhor atende as necessidades de alta disponibilidade em seus ambientes.

A solu??o consiste de m¨²ltiplas inst?ncias ou n¨®s do zabbix_server. Cada n¨®:

• ¨¦ configurado separadamente (arquivo de configura??o, scripts, criptografia, exporta??o de dados)
• usa o mesmo banco de dados
• possui v¨¢rios modos: ativo, em espera, indispon¨ªvel, parado

Apenas um n¨® pode estar ativo (trabalhando) por vez. Os n¨®s em espera n?o fazem coleta de dados, processamento ou outras atividades regulares do Server; eles n?o esperam por comunica??o nas portas; eles t¨ºm conex?es m¨ªnimas com o banco de dados.

Ambos os n¨®s ativos e em espera atualizam seus hor¨¢rios de ¨²ltimo acesso a cada 5 segundos. Cada n¨® em espera monitora o hor¨¢rio do ¨²ltimo acesso do n¨® ativo. Se hor¨¢rio do ¨²ltimo acesso do n¨® ativo estiver acima de 'atraso de recupera??o de falha' segundos, o n¨® em espera torna a si o n¨® ativo e associa o estado de 'indispon¨ªvel' ao n¨® anteriormente ativo.

O n¨® ativo monitora sua pr¨®pria conectividade de banco de dados - se for perdida por mais do que atraso de recupera??o de falha - 5 segundos, ele deve parar todo o processamento e alterar para o modo de espera. O n¨® ativo tamb¨¦m monitora o estado dos n¨®s em espera - se o hor¨¢rio do ¨²ltimo acesso de um n¨® em espera for maior do que 'atraso de recupera??o de falha' segundos, o n¨® em espera recebe o estado de 'indispon¨ªvel'.

O atraso de recupera??o de falha ¨¦ configur¨¢vel, com o valor m¨ªnimo sendo de 10 segundos.

Os n¨®s s?o projetados para serem compat¨ªveis entre vers?es secund¨¢rias (minor) do Áú»¢¶Ä²©.

Habilitando cluster HA

Configura??es do Server

Para transformar qualquer Áú»¢¶Ä²© Server de um servidor isolado (standalone) em um n¨® de cluster HA, especifique o par?metro HANodeName (nome do n¨®) na configura??o do Server.

O par?metro de endere?o do n¨® NodeAddress (endere?o:porta), se configurado, deve ser usado pelo Frontend do n¨® ativo, sobrescrevendo o valor presente no zabbix.conf.php.

Preparing frontend

Make sure that Áú»¢¶Ä²© server address:port is not defined in the frontend configuration.

Áú»¢¶Ä²© frontend will autodetect the active node by reading settings from the nodes table in Áú»¢¶Ä²© database. Node address of the active node will be used as the Áú»¢¶Ä²© server address.

Configura??o do Proxy

Para habilitar conex?es ¨¤ m¨²ltiplos Servers em um ambiente de alta disponibilidade, liste os endere?os de n¨® de HA no par?metro Server do Proxy, separados por ponto-e-v¨ªrgula.

Configura??es do Agent

Para habilitar conex?es ¨¤ m¨²ltiplos Servers em um ambiente de alta disponibilidade, liste os endere?os de n¨® de HA no par?metro ServerActive do agente, separados por ponto-e-v¨ªrgula.

Failover to standby node

Áú»¢¶Ä²© will fail over to another node automatically if the active node stops. There must be at least one node in standby status for the failover to happen.

How fast will the failover be? All nodes update their last access time (and status, if it is changed) every 5 seconds. So:

• If the active node shuts down and manages to report its status as "shut down", another node will take over within 5 seconds.

• If the active node shuts down/becomes unavailable without being able to update its status, standby nodes will wait for the failover delay + 5 seconds to take over

The failover delay is configurable, with the supported range between 10 seconds and 15 minutes (one minute by default). To change the failover delay, you may run:

zabbix_server -R ha_set_failover_delay=5m

Gerenciando um cluster HA

O estado atual do cluster HA pode ser gerenciado usando as op??es de controle em tempo de execu??o dedicadas:

• ha_status - registra o estado do cluster HA no log do Áú»¢¶Ä²© Server;
• ha_remove_node=alvo - remove um n¨® HA identificado por seu <alvo> - n¨²mero do n¨® na lista (o n¨²mero pode ser obtido do resultado da execu??o de ha_status). Note que n¨®s ativos/em espera n?o podem ser removidos.
• ha_set_failover_delay=atraso - configure o atraso de recupera??o de falha de HA (sufixos de tempo s?o suportados, p.e. 10s, 1m)

O estado de um n¨® pode ser monitorado:

• em ¸é±ð±ô²¹³Ù¨®°ù¾±´Çs ¡ú Informa??o do sistema
• no widget de dashboard Informa??o de sistema
• usando a op??o de controle em tempo de execu??o ha_status do Server (veja acima).

O item interno zabbix[cluster,discovery,nodes] pode ser usado para descoberta de n¨®, pois ele retorna um JSON com informa??es de n¨®s de alta disponibilidade.

Desabilitando um cluster HA

Para desabilitar um cluster de alta disponibilidade:

• fa?a c¨®pia de backup dos arquivos de configura??o
• pare os n¨®s em espera
• remova o par?metro HANodeName do servidor prim¨¢rio ativo
• reinicie o servidor prim¨¢rio (ele iniciar¨¢ em modo isolado (standalone))

Upgrading HA cluster

To perform a major version upgrade for the HA nodes:

• stop all nodes;
• create a full database backup;
• if the database uses replication make sure that all nodes are in sync and have no issues. Do not upgrade if replication is broken.
• select a single node that will perform database upgrade, change its configuration to standalone mode by commenting out HANodeName and upgrade it;
• make sure that database upgrade is fully completed (System information should display that Áú»¢¶Ä²© server is running);
• restart the node in HA mode;
• upgrade and start the rest of nodes (it is not required to change them to standalone mode as the database is already upgraded at this point).

In a minor version upgrade it is sufficient to upgrade the first node, make sure it has upgraded and running, and then start upgrade on the next node.

Implementation details

The high availability (HA) cluster is an opt-in solution and it is supported for Áú»¢¶Ä²© server. The native HA solution is designed to be simple in use, it will work across sites and does not have specific requirements for the databases that Áú»¢¶Ä²© recognizes. Users are free to use the native Áú»¢¶Ä²© HA solution, or a third party HA solution, depending on what best suits the high availability requirements in their environment.

The solution consists of multiple zabbix_server instances or nodes. Every node:

• is configured separately (configuration file, scripts, encryption, data export)
• uses the same database
• has several modes: active, standby, unavailable, stopped

Only one node can be active (working) at a time. The standby nodes do no data collection, processing or other regular server activities; they do not listen on ports; they have minimum database connections.

Both active and standby nodes update their last access time every 5 seconds. Each standby node monitors the last access time of the active node. If the last access time of the active node is over 'failover delay' seconds, the standby node switches itself to be the active node and assigns 'unavailable' status to the previously active node.

The active node monitors its own database connectivity - if it is lost for more than failover delay-5 seconds, it must stop all processing and switch to standby mode. The active node also monitors the status of the standby nodes - if the last access time of a standby node is over 'failover delay' seconds, the standby node is assigned the 'unavailable' status.

The failover delay is configurable, with the minimum being 10 seconds.

The nodes are designed to be compatible across minor Áú»¢¶Ä²© versions.