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

[WiliRGasparetto]

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:

1. o time coleta logs no contexto errado (MDS vs Domain), e

2. 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)

1. 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

2. Entre no Domain suspeito:

mdsenv <DomainName>
echo $FWDIR

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

3. 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

1. Coletar evidência mínima (logs + mdsstat)

2. 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