High Availability (HA) no FortiGate garante continuidade de serviço quando um firewall falha.
Sem HA, se o FortiGate principal cair, toda a rede perde acesso à internet e a qualquer serviço que passa pelo firewall. Com HA, um segundo FortiGate assume em segundos, sem intervenção manual.
FGCP: o protocolo de HA da Fortinet
O FortiGate Clustering Protocol (FGCP) é o protocolo proprietário Fortinet que gerencia o cluster de HA.
O FGCP usa interfaces de heartbeat para comunicação entre os membros do cluster. Essas interfaces trocam informações de saúde a cada segundo. Se o membro primário para de responder, o secundário assume.
Dois requisitos para o cluster funcionar:
Os dois FortiGates precisam ser do mesmo modelo e ter o mesmo FortiOS. Hardware diferente ou versões diferentes não formam cluster.
Active-Passive: o modo mais comum
No modo active-passive, um FortiGate é o primário e processa todo o tráfego. O outro fica em standby, sincronizado com o primário mas sem processar tráfego.
Quando o primário falha, o secundário assume em 1 a 3 segundos. O FGCP altera os endereços MAC das interfaces para corresponder ao primário. Dispositivos na rede não percebem a mudança porque o MAC e o IP ficam os mesmos.
Sessões existentes: no active-passive com session synchronization habilitada, as sessões TCP ativas são sincronizadas para o secundário. Após o failover, as sessões continuam sem interrupção.
Active-Active: com load balancing
No modo active-active, os dois FortiGates processam tráfego simultaneamente. O primário distribui as sessões entre os membros usando um algoritmo de load balancing.
Vantagem: maior throughput total. Ambos os dispositivos são utilizados.
Desvantagem: mais complexo. O tráfego de entrada e saída de uma sessão pode passar por membros diferentes, exigindo sincronização contínua.
Na prática, o active-passive é mais usado em ambientes corporativos porque é mais simples de gerenciar e o failover é mais previsível.
Configuração de HA active-passive
Pré-requisitos:
- Dois FortiGates do mesmo modelo e mesma versão FortiOS
- Pelo menos dois cabos de heartbeat conectando os dois dispositivos
- Configuração idêntica nos dois, exceto pelo device priority
Em FG1 (primário):
config system ha
set mode a-p
set group-id 1
set group-name "Cluster-Corporativo"
set password MinhasenhaHA
set hbdev "ha1" 10 "ha2" 20
set session-pickup enable
set device-priority 200
end
Em FG2 (secundário):
config system ha
set mode a-p
set group-id 1
set group-name "Cluster-Corporativo"
set password MinhasenhaHA
set hbdev "ha1" 10 "ha2" 20
set session-pickup enable
set device-priority 100
end
O device-priority mais alto vence a eleição para primário. O session-pickup enable ativa a sincronização de sessões. O password precisa ser idêntico nos dois lados.
Interfaces de heartbeat
O heartbeat é a comunicação entre os membros do cluster. Recomendações:
Usar pelo menos duas interfaces de heartbeat para redundância. Se uma falhar, o cluster continua via a outra.
As interfaces de heartbeat devem ter conexão direta entre os FortiGates, não passar por switches.
No hbdev, o número após o nome da interface é a prioridade. Interface com menor número tem maior prioridade de heartbeat.
Verificação do cluster
FG1 # get system ha status
HA Health Status: OK
Model: FortiGate-100F
Mode: HA A-P
Group: 1
Debug: 0
ses_pickup: Enabled
ses_pickup_delay: Disabled
Group ID: 1
Group Name: Cluster-Corporativo
Overal HA status: Enable
Primary Unit Name: FG1
Primary Unit Status: Active
Secondary Unit Name: FG2
Secondary Unit Status: Standby
FG1 # diagnose sys ha checksum cluster
Esse comando verifica se a configuração dos dois membros está sincronizada. Se mostrar diferenças, algo foi configurado em um membro mas não no outro.
Testar o failover
Para testar sem desligar o hardware:
FG1 # diagnose sys ha reset-uptime
Esse comando força o failover manual para o secundário. Use em janela de manutenção.
Para verificar que o failover funcionou, o secundário deve aparecer como Active e o primário como Standby após o comando.
O que o NSE4 cobra sobre HA
HA é um dos temas mais cobrados no NSE4, especialmente no domínio de Infrastructure. Os pontos mais frequentes:
Diferença entre active-passive e active-active. O que é FGCP e as interfaces de heartbeat. Por que os dois FortiGates precisam ser do mesmo modelo. O que é device priority e como afeta a eleição. O que é session-pickup e por que importa para failover transparente. Verificação com get system ha status.
FAQ
O FortiGate secundário precisa de licença separada? Sim. Cada FortiGate no cluster precisa de suas próprias licenças de hardware e serviços FortiGuard. O cluster não compartilha licenças.
Posso gerenciar cada membro do cluster separadamente? Sim, via interface de gerenciamento fora do cluster. Mas toda configuração feita via CLI ou GUI no primário é automaticamente sincronizada para o secundário. Configurar diretamente no secundário pode criar inconsistências.
O que é override e quando usar? Override determina se o membro com maior device-priority retoma o papel de primário quando volta após uma falha. Com override habilitado: retoma automaticamente. Com override desabilitado (padrão): o secundário continua como primário mesmo após o retorno do original.
▌ High Availability é tema obrigatório no NSE4. O simulado do PacketPass tem questões calibradas para o exame FCP_FGT_AD-7.6 atual.
Informações baseadas no blueprint NSE4 FortiOS 7.6, documentação oficial da Fortinet (FortiOS 7.6.4) e CertLand Study Guide (março 2026).