Curso Completo de Preparação para Certificação Fortinet FCP Network Security Text Lesson

Módulo 8 — Alta Disponibilidade (HA)

Preparação FCP FortiGate 7.6: aulas + 10 labs práticos + exame final, com nota no certificado.

Módulo 8 — Alta Disponibilidade (HA)

Objetivos de aprendizagem

Distinguir os modos FGCP active-passive e active-active e saber quando aplicar cada um.

Explicar o processo de eleição de mestre e a ordem dos critérios (override, priority, age, serial number).

Configurar heartbeat interfaces, session synchronization e session pickup.

Usar monitor interfaces (link monitoring) para acionar failover.

Compreender virtual clusters para repartir VDOMs entre membros.

Verificar o estado do cluster e operar um failover controlado na CLI FortiOS 7.6.

O que é FGCP

O FortiGate Clustering Protocol (FGCP) é o mecanismo nativo de HA do FortiOS. Dois ou mais FortiGate idênticos (mesmo modelo, mesma versão de firmware, mesmo conjunto de licenças e o mesmo número de interfaces) formam um cluster que se apresenta à rede como um único dispositivo lógico. Os membros partilham um HA group ID (que determina os endereços MAC virtuais) e um group name. Se um membro falhar, outro assume sem intervenção manual, preservando — quando configurado — as sessões em curso.

Requisito de uniformidade: o FGCP exige hardware e firmware iguais entre membros. Modelos diferentes ou versões de FortiOS distintas impedem a formação do cluster. Verifica sempre com get system status em cada unidade antes de juntar ao cluster.

Active-passive vs. active-active

No modo active-passive (A-P) existe um único membro primary (mestre) que processa todo o tráfego; os restantes ficam em standby, prontos a assumir num failover. É o modo mais simples, previsível e o recomendado para a maioria dos cenários (firewall, IPsec, routing).

No modo active-active (A-A) o primary continua a tomar todas as decisões de sessão, mas distribui o processamento de inspeção de conteúdo (proxy-based: antivírus, web filter, etc.) pelos membros secundários, aumentando o débito de inspeção. O tráfego de firewall puro continua a ser tratado pelo primary. A-A acrescenta complexidade e raramente é necessário com NGFW moderno — A-P é o ponto de partida habitual.

config system ha

    set group-name "ONDAKA-HA"

    set group-id 7

    set mode a-p

    set password <HA-SECRET>

    set hbdev "port3" 50 "port4" 100

    set session-pickup enable

    set override disable

    set priority 200

end

Eleição de mestre

Quando o cluster forma (ou re-forma após um failover), o FGCP elege o primary comparando os membros pela seguinte ordem de critérios:

1. Override + Priority — se override estiver enable, o membro com maior priority ganha. A priority (0–255, predefinição 128) é o primeiro fator decisivo quando o override está ligado.

2. Connected monitored interfaces — o membro com mais interfaces monitorizadas up tem prioridade (uma interface caída desqualifica o membro).

3. Age (uptime do membro no cluster) — vence quem está estável há mais tempo. Cada falha de link reinicia o relógio de age desse membro.

4. Serial number — critério de desempate final: o serial mais alto ganha.

override disable (predefinição): com override desligado, o age domina sobre a priority. Isto evita failovers desnecessários: depois de um failover, o novo primary mantém-se mesmo que a unidade original volte com priority superior. Liga override enable apenas quando queres forçar que um membro específico (o de maior priority) seja sempre o primary — ao custo de um failover extra quando ele regressa.

Heartbeat interfaces

As heartbeat interfaces (hbdev) transportam o tráfego de controlo do FGCP: eleição, sincronização de config e de sessões, e deteção de falhas. Cada interface tem uma prioridade de heartbeat (maior = preferida). Boas práticas:

Usa pelo menos duas interfaces de heartbeat para redundância — se a única ligação cair, o cluster entra em split-brain (dois primaries).

Liga as heartbeat diretamente entre os FortiGate (cabo back-to-back) ou por um switch dedicado. Não as partilhes com tráfego de dados.

As interfaces de heartbeat não levam endereço IP atribuído manualmente — o FGCP usa um espaço de endereçamento próprio.

Sincronização de config e de sessões

O primary sincroniza automaticamente quase toda a configuração para os secundários através das heartbeat interfaces. Alguns parâmetros ficam de fora (ex.: hostname, e o próprio priority de HA), o que é intencional. A sincronização de sessões é separada e controlada por session-pickup.

Com session pickup desativado (predefinição), num failover as sessões TCP estabelecidas quebram e têm de ser reabertas pelos clientes. Com session-pickup enable, o primary replica a tabela de sessões para os secundários, permitindo que o tráfego prossiga sem interrupção após o failover. Tem custo de CPU/memória; para reduzir esse custo só às sessões que importam usa session-pickup-connectionless e a opção de delay:

config system ha

    set session-pickup enable

    set session-pickup-connectionless enable

    set session-pickup-delay enable

    set session-sync-dev "port5"

end

Monitor interfaces (link monitoring)

As monitor interfaces são interfaces de dados vigiadas pelo FGCP. Se uma delas perder o link no primary, o cluster considera o primary degradado e desencadeia um failover para o secundário (que tem essa interface up). Sem monitorização, uma falha de cabo/porta de dados no primary não provoca failover — o tráfego ficaria preso.

config system ha

    set monitor "port1" "port2"

end

Virtual clusters

Quando os VDOMs estão ativos, podes usar virtual clusters (virtual cluster 1 e 2) para fazer load sharing ativo-ativo entre membros sem A-A: cada virtual cluster tem o seu primary. Atribuindo metade dos VDOMs ao virtual cluster 1 e a outra metade ao virtual cluster 2, com prioridades invertidas, o FortiGate A é primary para um conjunto de VDOMs e o FortiGate B para o outro. Ambos processam tráfego em simultâneo e cada um é standby do outro.

config system ha

    set vdom "root" "vdom-clientes"

    config secondary-vcluster

        set vdom "vdom-clientes"

        set priority 200

    end

end

Failover e verificação

Confirma o estado do cluster com os comandos de monitorização. get system ha status mostra o estado geral (membros, primary, sincronização); diagnose sys ha status dá detalhe de baixo nível (heartbeat, vcluster, estatísticas).

# Estado geral do cluster

get system ha status



# Detalhe de baixo nível (heartbeat, vcluster, sync)

diagnose sys ha status



# Estado de sincronização da config (checksums)

diagnose sys ha checksum cluster



# Aceder à CLI de um membro secundário (índice 1)

execute ha manage 1 admin



# Forçar failover: baixar a prioridade do primary atual (com override)

config system ha

    set override enable

    set priority 50

end

Para um failover controlado em laboratório, podes também reiniciar o primary (execute reboot) ou desligar uma monitor interface e observar a transição com get system ha status — o campo de "Master" deve passar para o outro serial.

Erros comuns

Heartbeat sem ligação dedicada — usar uma só interface de heartbeat, ou partilhá-la com tráfego de dados. Se essa ligação cair, surge split-brain (dois primaries com o mesmo MAC virtual) e a rede fica instável. Usa sempre 2+ heartbeat em ligação dedicada/back-to-back.

Confundir override com a regra de age — esperar que o membro de maior priority seja sempre o primary com override disable. Sem override, o age domina e o primary atual mantém-se.

Esquecer session-pickup — assumir que as sessões sobrevivem ao failover por defeito. Está desativado de origem; sem ele, as sessões TCP quebram.

Não configurar monitor interfaces — uma falha de porta de dados no primary não dispara failover se a interface não estiver monitorizada.

Hardware/firmware diferente — modelos ou versões de FortiOS distintos impedem a formação do cluster FGCP.

group-id em conflito — dois clusters FGCP no mesmo domínio L2 com o mesmo group-id geram colisão de MAC virtuais. Usa IDs distintos por cluster.

Lab associado

Aplica estes conceitos na prática — formar um cluster FGCP active-passive, configurar heartbeat, session pickup e monitor interfaces, e provocar/verificar um failover:

🧪 Abrir este Lab na plataforma LAB
Abre com sessão automática (SSO). Incluído no curso — sem custo de créditos.

Módulo 8 — Alta Disponibilidade (HA)