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.

Assine a nossa Newsletter!

Quer saber de próximos treinamentos, notícias, publicações, webinars e também sobre eventos da Unirede? Assine a nossa Newsletter e fique por dentro de todas as novidades.

Você pode gostar também…

Zabbix como ferramenta de apoio na descoberta de vulnerabilidades

Zabbix como ferramenta de apoio na descoberta de vulnerabilidades

çãA utilização da ferramenta opensource Zabbix no dia-a-dia de profissionais de TI é fundamental para garantir a estabilidade de ambientes, obtendo dados de sinais vitais e outras opções. Dentre essas outras opções, conforme necessidade e contexto, é possível...

Dicas para usar o Geomaps Widget do Zabbix 6.0

Dicas para usar o Geomaps Widget do Zabbix 6.0

A versão 6.0 do Zabbix conta com um widget para geolocalização dos hosts, exibindo-os em um Dashboard, conforme filtros que podemos aplicar. Acontece que, apesar de parecer simples (e é!), versões anteriores precisavam de integrações e alterações em código para...

Monitoramento de Certificados Digitais de Websites com Zabbix Agent2

Monitoramento de Certificados Digitais de Websites com Zabbix Agent2

Introdução O Zabbix Agent2 tem sido um divisor de águas nas questões de monitoramento com a ferramenta Zabbix. Se o Zabbix Agent tradicional (escrito em C) já era bom, o novo agente, escrito em “Go” veio para suprir muitas necessidades de monitoramento e anseios por...

1 Comentário

  1. Flavio

    Boa análise.
    Porém vejo que há uma falta de redundância do Banco de Dados, correto?

    Como seria a melhor opção para esse cenário em que um zabbix-db não responde?

    Responder

Enviar um comentário

O seu endereço de e-mail não será publicado.

Pin It on Pinterest