Zabbix Native High Availability Solution

Há muito, os administradores Zabbix têm sentido a necessidade de se trabalhar uma solução de monitoramento com alta disponibilidade. Mas por quê? Simples… um ambiente de TIC cresce exponencialmente a cada dia com novos hosts, de novos clientes, em diversos locais do país e do mundo, é um círculo virtuoso de desenvolvimento. Mas, perceba, crescimento, sem desenvolvimento, não é saudável!  

Bom, felizmente, o Zabbix tem evoluído, ganhando muita maturidade com o passar de suas versões e enfim, o fornecedor do produto disponibilizou uma solução de High Availability (H.A.) nativa. Pois bem, vamos explorá-la um pouco! 

Contexto

Sabemos que uma solução de monitoramento com Zabbix possui, por natureza, escalabilidade horizontal, com uso de proxies, por exemplo, o que chamamos de “Monitoramento Distribuído”. Os proxies são muito úteis. Eles permitem, por exemplo, que hosts e/ou grupos de hosts inteiros sejam monitorados em ambientes remotos, agindo essencialmente em nome do Zabbix Server. Mas… quando um cliente, um grupo de clientes ou qualquer host (ou proxy) perde a conectividade com o Zabbix Server, não havia, até agora, uma solução que permitisse que ele continuasse a ser monitorado. Bom, vamos avançar um pouco mais nessa análise, pois é aí que entra o “Zabbix Cluster”! 

Load Balance

Precisa ser dito. O Zabbix não tem. 

Isso mesmo. Alinhando as expectativas sobre a nova versão do produto, o Zabbix Server não possui uma solução que faça um balanceamento de carga recebida (dados coletados, métricas). O que a nova versão ganha é a funcionalidade de se criar clusters de Zabbix Servers par desempenhar o que se conhecer por “Failover”. Vamos falar sobre ele… 

Failover

Failover é algo como contingência. Ou seja, o Zabbix Server agora possui uma estrutura de clusters do tipo “Ativo x Stand by”. Isso quer dizer que, essencialmente, existirá uma espécie de “Zabbix Server Master” (este conceito não está definido na ferramenta ou em sua documentação) e, quando este vem a deixar de responder, por exemplo, por queda do serviço, assume um Cluster. É tolerância à falha, mas não é Loadbalance.  

Calma… fizemos um troubleshooting da solução e em laboratório, comprovamos que os dados continuarão sendo coletados e entregues, com o timestamp correto, mesmo que se mude o “Zabbix Server Master”, ou seja, não haverá flaps e buracos nos gráficos, felizmente.

Como configurar

Basicamente, o banco de dados deverá ter permissão para que os vários servers possam ler e escrever na mesma instância. 

Por exemplo, considere:

zabbix-server = 192.168.100.10 

zabbix-frontend = 192.168.100.50 

zabbix-db = 192.168.100.30 

Algo assim: 

Temos uma instalação Multi-Node clássica. Cada componente em um servidor dedicado. 

Acrescentando o Zabbix-server2, temos: 

 zabbix-server = 192.168.100.10 

zabbix-server2 = 192.168.100.11 

zabbix-frontend = 192.168.100.50 

zabbix-db = 192.168.100.30 

 Agora, temos algo assim: 

Note que estamos trabalhando hipoteticamente com apenas uma solução de 2 servidores Zabbix em cluster.  Ao final de cada arquivo de configuração zabbix_server.conf, nesse caso, acrescentamos: 

HANodeName=Cluster A 

NodeAddress=zabbix-server:10051 

Para o zabbix-server2, teríamos: 

HANodeName=Cluster B 

NodeAddress=zabbix-server2:10051 

Quem for inicializado primeiro, será o Zabbix Server Master (Active). O(s) outro(s), serão executados em modo “Stand by”. 

# No zabbix-server (Cluster A) 

534:20211210:232246.459 starting HA manager 

534:20211210:232246.472 HA manager started in active mode 

# No Zabbix-server2 (Cluster B) 

534:20211210:232334.130 starting HA manager 

534:20211210:232334.140 HA manager started in standby mode 

533:20211210:232334.229 “Cluster B” node started in “standby” mode 

533:20211211:002334.132 “Cluster B” node is working in “standby” mode 

No frontend, temos algo assim: 

Em um troubleshooting básico, teríamos: 

1. Parar o serviço do zabbix-server (Cluster A)
   a. systemctl stop zabbix-server.service
2. Observando o log do zabbix-server2 (Cluster B)
   a. 533:20211211:003221.140 “Cluster B” node switched to “active” mode 
3. A visão no frontend seria: 

System information

4. Mas, e os hosts que entregavam métricas para o zabbix-server (Cluster A) apenas?

Pois bem… ao se criar uma estrutura de Zabbix Servers Active x Stand by, é necessário apontar os Zabbix Agents + Zabbix Proxies para entregarem as métricas para ambos os servers, caso contrário, teremos uma solução de Failover que não estará apta a receber nenhum dado, caso o “Master” venha a falhar. 

Zabbix Agent2 – Exemplo de configuração 

Se estivermos coletando dados por um Zabbix Agent2 e entregando diretamente ao server, devemos fazer algo assim no arquivo zabbix_agent2.conf: 

Server=zabbix-server,zabbix-server2 

ServerActive=zabbix-server,zabbix-server2 

Zabbix Proxy – Exemplo de configuração 

Caso estejamos entregando nossas métricas a um Zabbix Proxy, temos que fazer assim: 

# Note que, se estivermos referenciados 2 ha_nodes, a separação é por “;” e não por “,”. 

Server=zabbix-server;zabbix-server2 

Assim, caso um Zabbix Proxy não encontre o servidor “Master”, ele entregará ao próximo “Active” da lista, por assim dizer. 

Conclusão (parcial) 

Este bog post foi escrito na versão 6.0 alpha7. Até a versão LTS 6.0.0, é necessário observar possíveis alterações e realizar mais testes e troubleshootings em ambientes mais complexos. 

O fornecedor da solução deixa em aberto o uso da alta disponibilidade nativa para o critério do administrador zabbix; este, por sua vez, pode entender que o H.A. por solução de virtualização seja outro caminho e assim por diante. 

Os testes realizados na versão alpha7 demonstraram que não há perda de métricas quando da indisponibilidade de apenas 1 cluster, seja por coleta direta do Server, seja por entrega via Proxy. 

Os testes não foram exaustivos, mas suficientes para comprovar a eficácia da solução de H.A. 

Considere outra questão: ainda há um ponto de falha no HTTP Server. Este, mesmo que em servidor dedicado, aponta automaticamente para o Server Active, porém, se o próprio falhar (HTTP Server) e não houver uma estrutura de HTTP Server Failover, haverá coleta, mas não a visualização dos dados coletados. 

O gerenciamento de configuração é altamente necessário caso o ambiente a ser monitorado precise referenciar mais de 1 cluster. Imagine um parque de >100 hosts, todos tendo que ter seu arquivo de configuração apontando para um novo zabbix-server, ou ainda proxies com a mesma necessidade. Vamos facilitar, se possível… hehe 

Cuidado com o falso-positivo ao se user um Zabbix Proxy mal configurado. Mesmo que não esteja apontando para o Active correto, ele pode entender que está na hora de “reter os dados até que a conexão seja restabelecida”. Isso não ocorrerá se o Proxy estiver apontando para os clusters corretamente. 

Esperamos que a leitura seja agradável, embora técnica. 

Mas também imaginamos o quanto esta solução agregará em projetos e o quanto brilhará em apresentações para os executivos do setor de Tecnologia da Informação! Ainda, mais, nas reuniões que decidem o Plano Diretor de Tecnologia da Informação ou ainda, o Plano de Diretor de Segurança da Informação (PDTI e PDSI, respectivamente). 

Se conecte! Informe-se! Capacite seu time conosco!  

Unirede Treinamentos

O mercado de TI é extremamente competitivo e no mundo dos negócios, quanto mais conhecimento você possui, mais valioso para o mercado você é. Investir na sua vida profissional é um passo importante para te deixar cada vez mais perto do sucesso. A Unirede Treinamentos está há mais de 14 anos no mercado de TI, com instrutores especializados no assunto e com didática e certificações oficiais. A Unirede Treinamentos é parceira Premium da Zabbix Oficial, Parceiro Silver Quest e parceiro Exin. Possui treinamentos em ferramentas opensource como Zabbix, Grafana, Kace, LGPD, DPO, ISMP, entre outros. Obtenha mais informações no site.