Alta disponibilidade e continuidade

HA do Server não torna toda a plataforma altamente disponível

O Zabbix possui solução nativa de alta disponibilidade para o Server, mas banco, frontend, rede, storage, DNS, balanceadores e integrações continuam precisando de desenho próprio. O objetivo é analisar a cadeia completa e não apenas duplicar o daemon principal.

O cluster nativo trabalha com um nó ativo

Em um cluster HA do Zabbix Server, somente um nó fica ativo por vez. Os demais permanecem em standby e acompanham o estado no banco compartilhado. Quando o nó ativo deixa de atualizar seu heartbeat além do período permitido, um standby pode assumir.

Cada nó precisa de identidade única

A configuração HA exige um nome de nó único. Esse identificador permite que os membros sejam registrados e acompanhados no cluster. Nome duplicado ou desenho inconsistente cria ambiguidade operacional e deve ser evitado.

O endereço do nó faz parte da comunicação HA

Cada nó pode anunciar endereço e porta usados para comunicação com componentes que precisam alcançar o Server ativo. O valor deve ser roteável e coerente com DNS, firewall e segmentação do ambiente.

Failover rápido demais pode criar instabilidade

O parâmetro de atraso de failover controla quanto tempo o cluster tolera ausência do nó ativo antes de promover outro membro. Valores agressivos reduzem RTO, mas podem aumentar risco de failover durante falhas transitórias ou pausas operacionais.

A decisão de failover depende de evidência temporal

HA não deve interpretar qualquer pacote perdido como morte do Server. O heartbeat cria uma janela para distinguir indisponibilidade real de atraso momentâneo. Por isso, latência e confiabilidade entre os nós e o banco importam diretamente.

O banco é a fonte de estado do cluster

Os nós do Server HA usam o mesmo banco Zabbix. Se esse banco estiver indisponível, adicionar nós de Server não resolve o problema. Banco sem redundância pode continuar sendo o maior single point of failure da arquitetura.

A tecnologia depende da engine escolhida

PostgreSQL e MySQL/MariaDB possuem ecossistemas próprios de replicação, failover e proxies de conexão. O Zabbix não substitui essa camada. Escolha uma arquitetura suportada pela engine e teste consistência, promoção e reconexão do Zabbix.

Dois primários de banco podem ser pior que uma parada

Arquiteturas de HA precisam impedir escrita concorrente inconsistente. Quorum, fencing e mecanismos da solução de banco devem ser entendidos. Um failover automático que preserva disponibilidade mas corrompe estado não é alta disponibilidade.

Frontend pode escalar separadamente

O frontend é uma aplicação PHP e pode ser executado em múltiplas instâncias atrás de balanceador quando a arquitetura de sessão, configuração e acesso ao banco estiver coerente. O desenho deve considerar também a comunicação com o Server ativo.

Quanto menos estado local, mais simples o failover

Configurações locais divergentes entre frontends criam comportamento imprevisível. Padronize arquivos, PHP, módulos, timezone, certificados e parâmetros. Automação de configuração reduz drift entre nós.

Balanceador também pode virar SPOF

Dois frontends atrás de um único load balancer sem redundância continuam dependentes de um ponto único. Analise VIP, DNS, health checks e HA do próprio balanceamento conforme criticidade.

Proxy oferece continuidade de coleta distribuída

Quando perde comunicação com o Server, o Proxy pode continuar coletando dados e armazená-los localmente para envio posterior, dentro da capacidade e política configuradas. Isso desacopla temporariamente coleta remota da disponibilidade do centro.

Buffer precisa sobreviver ao pior outage plausível

Dimensione armazenamento e retenção do Proxy para a taxa real de coleta e a duração máxima de isolamento esperada. Um Proxy capaz de guardar apenas duas horas não protege uma filial que pode ficar um dia sem WAN.

Bufferização e failover resolvem problemas diferentes

Proxy reduz impacto de falha de comunicação e distribui coleta. Server HA reduz indisponibilidade do processo central. Um não substitui o outro; arquiteturas robustas frequentemente utilizam ambos.

Distribuição pode adicionar resiliência operacional

Proxy groups permitem distribuir hosts entre proxies de um grupo e suportar redistribuição conforme disponibilidade e configuração. Isso é útil em desenhos onde múltiplos proxies conseguem alcançar o mesmo conjunto de alvos.

Failover de Proxy só funciona se a rede permitir

Dois proxies não criam redundância se apenas um possui rota, ACL ou credencial para os dispositivos. Antes de confiar na redistribuição, valide conectividade e identidade a partir de cada membro elegível.

Agentes ativos precisam alcançar destino alternativo conforme desenho

Quando hosts usam active checks, a estratégia de Server/Proxy precisa considerar como eles descobrem ou alcançam o endpoint disponível. DNS, listas de servidores e arquitetura de Proxy devem ser planejados para evitar dependência oculta de um único endereço.

Coleta disponível sem alerting disponível ainda é falha

Email, SMS, chat, webhook e plataformas de incidentes podem falhar independentemente do Server. Monitore o caminho de notificação e tenha mecanismos de teste. O NOC não se beneficia de um evento corretamente detectado que nunca chega ao operador.

Dependência externa precisa aparecer no desenho

Se todos os alertas dependem de um único SaaS, gateway ou SMTP, ele se torna parte da cadeia de disponibilidade. Considere canal alternativo para incidentes críticos quando o risco justificar.

Nomes usados no failover também são infraestrutura crítica

Se VIPs, frontends, proxies ou integrações dependem de DNS, monitore resolução e TTL. Mudanças de DNS não são instantâneas para todos os clientes e podem aumentar RTO real.

Tempo inconsistente destrói diagnóstico

Server, Proxy, banco e hosts precisam de relógios coerentes. Divergência temporal dificulta correlação de eventos, logs e failover. Monitore sincronização e trate NTP como dependência operacional.

Recovery Time Objective é tempo aceitável de interrupção

RTO deve ser definido para monitoramento central, coleta remota, frontend e alerting. Um objetivo de 60 segundos exige arquitetura e automação diferentes de um objetivo de 30 minutos. Sem RTO, “alta disponibilidade” não possui critério mensurável.

Recovery Point Objective define perda de dados aceitável

Para o banco, RPO indica quanto histórico/configuração pode ser perdido após desastre. Para Proxy, buffer influencia perda de amostras durante isolamento. RPO zero ou próximo de zero aumenta complexidade e custo e precisa de justificativa.

HA não substitui backup

Replicação copia alterações boas e ruins. Exclusão acidental, corrupção lógica ou credencial comprometida pode se propagar para réplicas. Backup independente e testado continua necessário mesmo em arquitetura altamente disponível.

Backup só existe de verdade depois do teste de restauração

Documente sequência para recuperar banco, configuração, certificados, frontend e integrações. Meça tempo real de restauração. RTO baseado apenas no tempo de copiar um arquivo ignora validação, DNS, permissões e reconexão dos componentes.

Arquivos locais precisam fazer parte do DR

Além do banco, preserve zabbix_server.conf, proxy configs, web server, PHP, certificados, PSKs quando aplicável, scripts externos, alert scripts e customizações. Banco restaurado sem esses elementos pode não reproduzir o ambiente funcional.

Reconstrução previsível reduz RTO

Automação com Ansible, Puppet, Salt, scripts ou imagens padronizadas permite recriar nós de forma consistente. O objetivo não é apenas instalar pacotes, mas reconstruir versões, parâmetros, certificados, serviços e observabilidade do próprio Zabbix.

O sobrevivente precisa suportar a carga

Em qualquer arquitetura N+1, remova mentalmente um nó e calcule novamente. Se dois componentes trabalham a 70% cada e um precisa assumir toda a carga, o failover pode apenas trocar uma falha por saturação.

HA permite manutenção, mas exige procedimento

Atualizações, reboot e patches podem ser feitos com menor indisponibilidade quando o failover é conhecido. Porém manutenção sem confirmar estado do cluster, banco e standby pode remover justamente o único nó saudável.

Compatibilidade entre nós precisa seguir documentação

Não trate cluster HA como mecanismo para manter versões incompatíveis indefinidamente. Siga procedimento oficial de upgrade e compatibilidade de schema. O banco compartilhado torna mudanças de versão especialmente sensíveis.

O cluster precisa monitorar a si próprio

Colete estado HA, disponibilidade dos nós, banco, proxies, filas, caches e canais de alerta. Exiba em dashboard independente. O primeiro sinal de degradação do monitoramento não deveria vir de um usuário dizendo que “pararam de chegar alertas”.

Alguma verificação deve existir fora do Zabbix

Um teste externo simples pode confirmar frontend, API ou entrega de alerta. Se toda a saúde do Zabbix é monitorada exclusivamente pelo próprio Zabbix, uma falha completa pode silenciar a evidência.

Distribua componentes entre domínios de falha reais

Dois Servers na mesma VM host, mesmo storage e mesmo switch não protegem contra falha desses elementos. Pense em host físico, rack, energia, rede, storage, zona e datacenter conforme o nível de disponibilidade requerido.

HA local e disaster recovery são camadas diferentes

HA pode resolver falha de processo ou host dentro do mesmo site. DR trata perda de site, storage ou região. Um segundo datacenter exige replicação, conectividade, DNS, secrets, runbook e decisão de promoção.

Automação não elimina decisão operacional

Alguns desastres exigem escolher entre consistência e disponibilidade. Defina quem autoriza promoção de banco, ativação de site DR e retorno ao primário. Runbook deve eliminar improviso durante incidentes graves.

Voltar ao primário também é mudança crítica

Depois do failover, não faça failback apenas porque o host original voltou. Confirme sincronização, causa raiz e janela. Failback apressado pode provocar segunda interrupção e destruir evidências.

Failover não testado é apenas uma hipótese

Execute exercícios controlados: parar Server ativo, isolar banco, interromper WAN de Proxy, indisponibilizar frontend e bloquear canal de alerta. Registre tempos, comportamento e lacunas. A documentação deve nascer desses testes.

Falhas planejadas revelam dependências invisíveis

Um game day pode simular perda de nó ou região em janela segura. O objetivo não é provar que a arquitetura é perfeita, mas descobrir onde ela quebra antes de um incidente real.

Meça o que aconteceu durante o teste

Registre tempo até detecção, promoção, retomada de coleta, normalização de queue, entrega do primeiro alerta e recuperação do frontend. Esses tempos mostram o RTO real de cada camada.

Reconexão pode gerar pico pós-outage

Quando proxies voltam a enviar backlog, o Server e banco recebem carga adicional além da coleta corrente. Capacity planning deve considerar esse catch-up. Um ambiente estável em regime normal pode saturar justamente na recuperação.

Retorno de conectividade pode liberar muitos eventos

Após isolamento, mudanças de estado e eventos acumulados podem gerar tempestade de notificações. Dependências, correlação, escalonamento e desenho de triggers ajudam a evitar que recuperação de infraestrutura sobrecarregue a equipe.

Cada falha crítica precisa de procedimento executável

Runbook deve conter sintomas, validação, comando/ação, critério de promoção, rollback, owner e evidência esperada. “Reiniciar o servidor se der problema” não é procedimento de continuidade.

Topologia atualizada acelera recuperação

Inventário de IPs, nomes, versões, dependências, certificados, banco e owners reduz tempo de decisão. Informação de DR mantida apenas na memória de uma pessoa é outro ponto único de falha.

Site secundário precisa do mesmo nível de proteção

DR desligado ou pouco usado não pode ser uma porta lateral. Patches, secrets, ACLs, certificados e RBAC precisam permanecer alinhados. Um ambiente secundário vulnerável pode comprometer o primário antes mesmo de ser necessário para recuperação.

Resiliência é capacidade de continuar entregando função

A meta não é manter todos os componentes sempre verdes. Durante falha, pode ser aceitável perder frontend temporariamente enquanto coleta e alerting continuam. Priorize funções por impacto e desenhe degradação controlada.

Remova SPOFs por camada

                USUÁRIOS / NOC
                      │
                VIP / DNS / LB
                 ┌────┴────┐
                 │         │
             FRONTEND A FRONTEND B
                 │         │
                 └────┬────┘
                      │
             ZABBIX SERVER HA
              ┌───────┴───────┐
              │               │
           NODE A          NODE B
              └───────┬───────┘
                      │
               DATABASE HA
              primary / replica
                      │
       ┌──────────────┼──────────────┐
       │              │              │
   PROXY RJ       PROXY SP       PROXY MG
   buffer local   buffer local   buffer local
       │              │              │
     hosts           hosts           hosts

Fora da cadeia:
→ backup independente
→ monitor externo
→ canal alternativo de alerta
→ site/estratégia de DR

“Dois nós” só vale se não morrerem juntos

Defina objetivos por função

Valores acima são exemplos de engenharia. RPO/RTO reais devem vir do impacto e da criticidade da operação.

Quanto o Proxy precisa sobreviver isolado?

Exemplo conceitual:

Proxy:
2.000 valores/segundo

Isolamento máximo projetado:
12 horas

Valores acumulados:
2.000 × 43.200
= 86.400.000 valores

Planejar:
- banco/storage local
- retenção do buffer
- I/O
- crescimento
- pico de envio após reconexão
- capacidade do Server/DB para catch-up

O que deve acontecer quando cada componente cai?

Procedimento deve caber em uma crise real

1. Confirmar falha
2. Identificar domínio afetado
3. Confirmar estado do standby
4. Confirmar saúde do banco
5. Verificar promoção automática/manual
6. Validar nó ativo
7. Validar coleta
8. Validar queue
9. Validar alerting
10. Validar frontend/API
11. Registrar horário e impacto
12. NÃO executar failback imediatamente
13. Corrigir causa raiz
14. Planejar retorno
15. Atualizar runbook com o que falhou

Teste resiliência com falhas controladas

Redundância aparente

Antes de chamar o Zabbix de altamente disponível

Base factual

Conteúdo estruturado sobre os recursos de alta disponibilidade do Zabbix 7.4, Zabbix Server HA, proxies, proxy groups, buffering e arquitetura distribuída. As camadas de banco, RPO/RTO, disaster recovery, failure domains, game days, runbooks, capacity N+1 e continuidade operacional são síntese de práticas de engenharia de confiabilidade aplicadas ao ecossistema Zabbix.

Linha Zabbix 7.4

HA nativo do Zabbix Server não torna banco, frontend, storage ou rede automaticamente redundantes. Modele RPO/RTO e teste falha real, retorno e consistência de alerting.