Multi-Domain (MDS/DMS) — HA, Sync e Troubleshooting Avançado (Runbook de Campo)

WiliRGasparetto — Fri, 27 Mar 2026 20:07:25 GMT

Multi-Domain (MDS/DMS) — HA, Sync e Troubleshooting Avançado (Runbook de Campo)

Escopo: troubleshooting operacional e arquitetura de Multi-Domain Security Management (MDS/DMS), com foco em HA, sincronização, coleta de evidências e ações seguras.

Tese operacional

Em Multi-Domain, a maioria dos incidentes “parece” SmartConsole/publish/sync — mas o MTTR explode por dois motivos clássicos:

o time coleta logs no contexto errado (MDS vs Domain), e
executa ações disruptivas (restart/failover) antes de evidência mínima.

1) Modelo mental de arquitetura (o que importa na prática)

1.1 MDS vs DMS (conceitos-chave)

MDS (Multi-Domain Server): hospeda a camada multi-domain e os Domains (DMS).
DMS (Domain Management Server): management de um domínio específico (objetos/políticas/gateways daquele Domain).

1.2 HA — onde muita gente erra

HA de Domain (DMS HA): por Domain, tipicamente 1 Active + 1..N Standby.
- A operação de “troca” (promoção) é operacional/manual (não assuma failover mágico).
HA de MDS: HA entre servidores do Multi-Domain; em muitos ambientes existe MDS primário/secundário e distribuição de carga por Domains ativos (depende do design).

Regra TAC: MDS “UP” não garante Domain “UP”. Sempre valide por Domain.

2) Regra nº1: Contexto correto (mdsenv) — sem isso você está “cego”

2.1 Listar Domains / estado geral

✅ Para listar Domains e estado de processos, use:

mdsstat

2.2 O que `mdsenv` faz (correção importante)

mdsenv sem argumentos não lista Domains. Ele serve para mostrar/ajustar o contexto atual.
Para trocar contexto para um Domain específico:

mdsenv <DomainName>

2.3 Verificar se você está no Domain certo (validação TAC)

Após mdsenv <DomainName>, valide imediatamente:

echo $FWDIR
echo $MDS_FWDIR

Interpretação prática

echo $FWDIR deve apontar para o diretório do contexto atual (se você entrou no Domain correto, vai refletir isso).
Se você não valida o contexto, corre o risco de coletar logs do lugar errado e perder tempo.

3) Runbook rápido “15 minutos” (triagem com evidência)

3.1 Baseline de saúde (MDS-level)

No MDS:

mdsstat

Procure:

Domains com status anormal
processos críticos “down”
flapping (sobe/desce)

Importante: não reinicie nada ainda. Primeiro identifique qual Domain e qual camada.

3.2 Entrar no Domain afetado

Entre no Domain suspeito:

mdsenv <DomainName>
echo $FWDIR

3.3 Logs em tempo real (durante reprodução)

Acompanhe logs principais (no contexto correto):

tail -F $FWDIR/log/fwd.elg
tail -F $CPDIR/log/cpd.elg

Correção (cpm.elg / asm.elg)

O arquivo $FWDIR/log/cpm.elg pode não existir em todas as versões/implementações.
Em alguns casos, o troubleshooting de management envolve outros logs (ex.: asm.elg).

✅ Regra TAC: verifique o que existe antes:

ls -lh $FWDIR/log | egrep "cpm|asm"

Depois faça o tail no arquivo presente:

tail -F $FWDIR/log/<arquivo_encontrado>.elg

4) Parar/Subir um Domain (ação cirúrgica e correta)

Correção importante (nome vs IP)

Os comandos corretos e recomendados são:

mdsstop_customer <DMS_Name>
mdsstart_customer <DMS_Name>

📌 Preferir sempre o nome conforme aparece no mdsstat.
O uso de IP não é a prática recomendada e pode não ser suportado dependendo do ambiente/versão.

Sequência TAC recomendada

Coletar evidência mínima (logs + mdsstat)
Executar ação controlada:

mdsstop_customer <DMS_Name>
mdsstart_customer <DMS_Name>
mdsstat

5) Sincronização / inconsistência entre peers (quando suspeitar)

Sintomas típicos:

objetos/policies “diferentes” entre peers
policy install funciona em um lado e falha no outro sem motivo claro
comportamento divergente após mudança/upgrade

TAC approach

Sempre compare logs e estado nos dois peers
Primeiro confirme que houve Publish (mudança não publicada não replica)

Se o problema for realmente drift de HA, a correção costuma ser pelo fluxo de HA/SYNC do SmartConsole (sincronização do peer), não “restart aleatório”.

6) Backup/Restore em HA (o que não pode faltar)

6.1 Execução

Backups em HA devem ser tratados como operação coordenada
Evite mudanças durante backup

Comandos:

mds_backup
mds_restore

6.2 Pós-restore (correção obrigatória)

Após mds_restore, sempre valide saúde antes de liberar:

mdsstat

E para Domains críticos:

mdsenv <DomainName>
echo $FWDIR
# checar logs e processos relevantes

7) Debug de kernel (avançado) — nunca sem filtro

Correção do seu item

Não recomende debug amplo em produção. Sempre use:

fw ctl debug -m <module> <flags>

Exemplo (genérico) para quedas/drops (com cautela)

Use janela curta e foco no módulo relevante.
Evite “all” e evite deixar debug ligado.

Sequência segura (exemplo):

fw ctl debug -m fw + drop
fw ctl kdebug -f
# reproduza por 30–60s
fw ctl debug 0

TAC rule: debug de kernel sem filtro e sem janela controlada = risco de degradação/perda de evidência útil.

8) Armadilhas comuns (incidentes recorrentes)

Rodar tail sem mdsenv <Domain> → logs “do lugar errado”
Assumir que mdsenv lista Domains → quem lista é mdsstat
Reiniciar Domain sem evidência mínima → mascara causa raiz (disco/locks/conectividade)
Restore sem validar mdsstat → ambiente “volta” parcialmente e vira incidente em cascata
Debug kernel amplo em produção → degradação + ruído + RCA impossível

topic Multi-Domain (MDS/DMS) — HA, Sync e Troubleshooting Avançado (Runbook de Campo) in Brazil

Multi-Domain (MDS/DMS) — HA, Sync e Troubleshooting Avançado (Runbook de Campo)