Rede e Telecomunicações: Topologia Interdatacenter e Continuidade do ADMS¶
Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-Rede-Telecom — "Assessment Integração ADMS - RedeTelecom (Consultoria Syntropy)" (VTT, 29/07/2026, 10h01–10h29, ~28min) + screenshot "topologia-rede-telecom-adms.png" (desenho de Thiago Xavier) + Ata 13 (Assessment_Consolidado) Status: Rascunho para validação Elaborado por: Consultoria Syntropy
Por que este artefato existe¶
Esta foi a sessão mais curta do ciclo de levantamento — 28 minutos — e, segundo a própria Ata, uma das mais úteis para delimitar o risco. Participaram Norberto (contextualização), Nelson (redes), Armando (infraestrutura) e Karina Alves Pinheiro (equipe de operação e infraestrutura), com Castellani conduzindo a análise sobre latência, posicionamento do conector de captura e maturidade da recuperação de desastre.
O valor desta sessão não está em descobrir um problema novo de rede — a área não relatou dor operacional relevante e a capacidade dos enlaces aparenta ser suficiente. O valor está em descartar uma hipótese que atravessava as Atas anteriores (a de que a rede pudesse ser o gargalo das integrações sob o G1) e confirmar, com número concreto, o que de fato incide sobre elas: a distância física entre os data centers, combinada com uma assimetria de arquitetura entre o ADMS e os sistemas corporativos.
Diagrama 1 — Topologia interdatacenter: enlaces compartilhados e segmentação por VLAN¶
O ambiente é interligado por dois enlaces de camada 3 de 10 Gbit/s entre os switches de Cataguases (Minas Gerais, data center principal do grupo) e João Pessoa (Paraíba, ambiente de recuperação de desastre). O firewall em cada ponta atende o ADMS, mas não é dedicado a ele: toda a replicação do ambiente — incluindo os bancos discutidos na sessão de DBA do dia anterior — atravessa essa mesma infraestrutura compartilhada. A segmentação entre as redes de TI e de OT hoje é lógica, apoiada em identificador de VLAN sobre o mesmo enlace; um projeto de Data Center Interconnect está em fase de assinatura de contrato, com infraestrutura prevista para 2026 e migrações até março de 2027 — prazo que é posterior às entradas em produção do G1 e do G2, o que significa que essas implantações ocorrerão sobre a topologia atual, não sobre a futura.
Um esclarecimento importante registrado na sessão: um terceiro enlace já está em implantação, mas melhora resiliência e capacidade — não reduz a latência, porque o fator dominante é a distância física entre os sites, superior a três mil quilômetros.
Diagrama 2 — A assimetria arquitetural sob o G1: cada evento atravessa 3000 km¶
Este é o achado que a própria Ata 13 trata como síntese do assessment desta sessão. O ADMS opera em modelo ativo-ativo entre os dois data centers — mas os sistemas corporativos com os quais ele se integra rodam exclusivamente em Minas Gerais. Enquanto o G3 opera inteiramente dentro de Minas Gerais (sem atravessar o enlace), o G1 coloca o OMS no data center da Paraíba se comunicando com sistemas corporativos que permanecem em Minas Gerais. Nessa configuração, a latência de 60 a 70 milissegundos passa a incidir sobre cada chamada síncrona e sobre cada evento capturado — e isso não é uma situação excepcional de contingência, é a configuração normal de operação sob o G1.
Some-se a isso o posicionamento do conector de captura (já detalhado na Ata 12, da sessão de DBA): ele roda no OpenShift corporativo, junto ao Confluent Kafka, distante do banco de origem no ambiente operacional. A consultoria levantou que, em desenho ideal, esse componente deveria estar próximo do banco — a coordenação confirmou já ter considerado essa alternativa e levado à equipe de OpenShift, mas a decisão esbarra em uma objeção legítima: a observabilidade e a operação estão centralizadas no ambiente corporativo, e o ambiente operacional não possui infraestrutura de orquestração de contêineres para hospedar o conector localmente. O encaminhamento acordado foi aguardar as evidências de homologação do primeiro OMS, hoje em teste, para decidir com dados reais em vez de hipótese.
Diagrama 3 — Dois modelos distintos de continuidade¶
O ADMS é testado com regularidade: a equipe realiza manobras periódicas ("server suíte") que desativam a instância de uma distribuidora em Minas Gerais e a operam por um período a partir da Paraíba. Como os bancos acompanham os servidores de aplicação, essa operação não introduz latência interna significativa — a prática foi avaliada como tranquila.
Os sistemas corporativos seguem um modelo completamente diferente: rodam apenas em Minas Gerais, replicados via Data Guard para a Paraíba (modalidade — se permite leitura no secundário ou não — não confirmada; modo de proteção síncrono ou assíncrono também não confirmado). Os testes de continuidade existentes ocorrem em ambiente isolado: escolhe-se um sistema, define-se um fim de semana, e uma "bolha" segregada é levantada na Paraíba com os bancos, o diretório de identidade e as demais dependências daquele sistema especificamente. A afirmação registrada foi categórica: nunca foi decretado desastre real, nunca houve chaveamento integral do ambiente corporativo — trata-se de uma operação de grande porte que simplesmente nunca foi exercitada de ponta a ponta.
O ponto que a Ata eleva a achado crítico: um teste em bolha valida que os componentes sobem isoladamente, mas não exercita as dependências reais de produção — resolução de nomes, rotas, autenticação, certificados, filas, APIs, integrações externas. Como o ADMS é ativo-ativo e o corporativo não, um desastre real testaria exatamente a camada que os testes atuais não cobrem: a integração entre os dois domínios, que é justamente onde a assimetria do G1 se manifesta.
Achados de fidelidade¶
1. "Karina" identificada — Karina Alves Pinheiro. No encerramento da sessão (25:57 do VTT), a coordenação agradece nominalmente "Gustavo, Marcelo, Nelson, Armando, Karina" — mas a tabela de participantes da Ata 13 não a lista em nenhum lugar, nem entre os confirmados nem entre os citados sem participação direta. Trata-se de Karina Alves Pinheiro, da equipe de operação e infraestrutura — a mesma citada, sem participação direta, na Ata 11 (Monitoramento e Observabilidade). Diferente do padrão "Castellani-ASR-variante" (Castelão/Castelano/cassilani/Cassiane/"Cássia Lenin", este último também presente nesta mesma sessão aos 14:26), este é um caso limpo de omissão de participante real no registro formal — vale sinalizar ao time de consolidação de Atas.
2. "Daniel" e "Campo Grande" sem base no VTT. A Ata lista "Gustavo, Marcelo e Daniel" como participantes técnicos e descreve que "um participante" estava em Campo Grande. Busquei essas duas informações em todo o VTT (1414 linhas) e não encontrei nenhuma ocorrência de "Daniel" nem de "Campo Grande". É possível que venham do relatório técnico complementar usado na consolidação da Ata, ao qual não temos acesso direto — não é necessariamente uma fabricação, mas não é verificável a partir da transcrição isoladamente.
3. Hedge possivelmente excessivo sobre o fornecedor da proposta de latência. A Ata trata o "fornecedor de telecomunicações" da proposta com garantia de latência inferior a 50ms como item a confirmar (Anexo B). O VTT, no entanto, registra com razoável clareza: "fiz uma avaliação técnica de uma proposta de LPU da Claro" (11:57) — nomeando a Claro diretamente. Diferente dos achados de sub-hedge vistos em sessões anteriores (fabricação sem base), aqui é o oposto: a Ata foi mais cautelosa do que o áudio parece exigir. Não é um erro, mas vale registrar como padrão interessante de calibração.
4. Números e cronologia conferem integralmente. Dois enlaces de 10 Gbit/s, latência de 60 a 70ms compatível com >3000km, ocupação divergente entre <50% (média, segundo redes) e 60-70% (mencionado pela consultoria) — a própria Ata trata essa divergência corretamente como diferença de critério (média vs. pico), não como erro. Datas do OMS (1º/9 e 1º/10/2026) e prazo do projeto DCI (março/2027) também consistentes entre VTT e Ata. A contagem de "cerca de treze reuniões já realizadas" bate com a progressão natural desde as ~10-11 mencionadas nas sessões de Monitoramento (27/07) e DBA (28/07) — boa corroboração cruzada de que o cronograma do engajamento está sendo relatado de forma consistente sessão a sessão.
5. Convergência explícita e correta com a Ata 12. A própria Ata 13 declara a convergência com o gargalo de vazão relatado pela equipe de banco (atraso de 10-20 min por leitura sequencial e compartilhamento de infraestrutura entre cargas de criticidade distinta) como "um fator adicional a considerar no mesmo diagnóstico, e não uma explicação concorrente" — a distância entre o conector e o banco de origem some-se, não substitui, a causa já identificada. Essa é uma boa prática de síntese entre sessões que vale reconhecer.
Próximo passo¶
Extrair as séries históricas de 30 a 90 dias dos enlaces (média, pico, percentis, perda, variação de atraso e latência por direção) antes da entrada em produção do OMS em 1º de setembro, e confirmar com a administração de banco Oracle a modalidade exata do Data Guard (com ou sem leitura no secundário) e seu modo de proteção — ambos os itens já encaminhados pela própria Ata como pendências para a sessão específica de continuidade, ainda a agendar.