War Stories #05: O Assassino Silencioso do Upgrade para o Cisco ACI 6.x

Quem opera Data Centers sabe que uma Gemud de atualização do Cisco ACI nunca é apenas um “Next, Next, Finish”. O Fabric é um ecossistema vivo, e saltar de uma versão 5.x para a família 6.x exige uma validação arquitetural profunda.

Geralmente, nós preparamos o terreno com os Pre-Upgrade Checks clássicos. Mas o que acontece quando a sua infraestrutura está perfeitamente saudável, os pré-requisitos oficiais passam, e o seu APIC 1 sofre um Hard Fail no meio da madrugada?

Hoje, vamos descer ao nível do shell do APIC e analisar um mecanismo de autodefesa da versão 6.1(5) que não aparece de forma clara no painel gráfico, mas que pode destruir a sua janela de manutenção.

---

Passo 1: O “Feijão com Arroz” do Pre-Upgrade Check

Antes de falarmos do problema oculto, não podemos ignorar a base. A maioria das atualizações falha por negligência no Day-2 Operations. Antes de subir qualquer binário para o repositório, o seu checklist deve garantir:

1. A Base Física (CIMC/UCS): Nunca esqueça que os APICs são servidores UCS C-Series. Validar a compatibilidade da versão do firmware do CIMC com a versão alvo do ACI é obrigatório. Um mismatch aqui pode causar perda de comunicação com os discos físicos durante o reboot.
2. Saúde dos SSDs (Leafs/Spines): Os switches da família Nexus 9K gravam logs intensamente. Antes do upgrade, valide o Flash Endurance e o Wear Indicator de todos os nós para garantir que nenhum SSD de boot vai morrer durante a gravação da nova imagem de 64-bits.
3. Espaço em Disco no APIC: O erro clássico. A descompactação do .bin exige espaço massivo. Verifique sempre com um df -h se as partições / e /firmware possuem folga (idealmente > 15GB livres). Se a partição estiver cheia, o processo de extração aborta silenciosamente e o APIC volta para o final da fila de instalação.

Se você validou tudo isso, o seu ambiente está, em teoria, pronto. Foi o que eu pensei até iniciar o processo para a versão 6.1(5e).

---

Passo 2: O Falso Loop e a Ilusão da Interface Gráfica

Durante a execução, o painel do APIC mostrava os nós 2 e 3 em "Installing (50%)", enquanto o APIC 1 ficou travado em "Installation Queue". No motor interno do ACI, os 50% significam extração da imagem, e a fila existe para respeitar o Quorum do cluster (evitando um split-brain).

Porém, o APIC 1 demorou além do normal e, eventualmente, apresentou uma falha. A interface gráfica apenas reportou que a instalação abortou, sem dar detalhes.

Na engenharia, quando a interface gráfica esconde o problema, nós vamos buscar a verdade nos logs.

Ao analisar o log do orquestrador (/var/log/dme/log/svc_ifc_appliance_director.bin.log e o insieme_4x_installer.log), verifiquei que o espaço em disco estava perfeito e o cluster se comunicava. O Director passou a bola para o motor de extração em Python, o atomix_installer.py. E foi aí que o processo morreu.

---

Passo 3: A Caixa Negra (atom_installer.log)

Para entender a falha de I/O ou corrupção, precisamos ler o log isolado do motor de extração. E foi lá que o “assassino silencioso” confessou.

Executando: tail -n 100 /firmware/logs/<sessão>/atom_installer.log

Encontramos a seguinte sequência:

Plaintext

2026-04-17 13:22:28 | INFO | Running upgrade hook for capability pki_encryption_check: pki_encryption_check.py 5.3.2f 6.1.5e
The source version is 5.3.2f
The target version is 6.1.5e
{'totalCount': '1', 'imdata': [{'pkiExportEncryptionKey': {'attributes': {'clearEncryptionKey': 'no', 'cryptedPassphrase': '', 'keyConfigured': 'no', 'strongEncryptionEnabled': 'no'}}}]}
Please enable Global AES Encryption before upgrading to 6.1.5e

O Diagnóstico

O script de pre-upgrade bateu na base de dados (MIT) do APIC e verificou que a flag strongEncryptionEnabled estava como no. Em milissegundos, o APIC abortou a extração para se proteger.

Mas por que isso acontece nas versões 6.x?

---

A Arquitetura por trás do “Global AES Encryption”

Até as versões 5.x, a criptografia profunda de configurações era opcional. Se você gerasse um Configuration Export (Backup), senhas do vCenter, chaves do BGP/OSPF e Shared Secrets de TACACS poderiam ser extraídas em texto plano ou hashes reversíveis.

Por pressão de compliance e normas de segurança globais (como o FIPS), a Cisco mudou a arquitetura. A partir da versão 6.x, o Global AES Encryption é obrigatório. O APIC se recusa a instalar o binário novo se você não transformar a sua MIT em um “cofre” AES-256.

Como destravar a sua Gemud e o Risco Operacional

Para resolver o problema na hora:

1. Acesse System > System Settings > Global AES Encryption.
2. Habilite a função e crie uma Passphrase forte.
3. Limpe a falha no painel e mande o APIC tentar novamente (Retry). A instalação vai fluir perfeitamente.

⚠️ O Alerta de Arquiteto (A Regra do Golden Backup): Ao habilitar isso, todos os seus backups futuros usarão essa Passphrase. Se o seu Data Center pegar fogo e você for restaurar a configuração em APICs novos, o sistema exigirá essa senha exata. Se você a perder, o backup sobe, mas nenhuma senha de integração (vCenter, BGP, TACACS) será restaurada, causando um pesadelo operacional.

Sempre que habilitar ou rotacionar essa chave, atualize o cofre de senhas da sua equipe e dispare imediatamente um backup manual completo para garantir um “Golden Backup” atrelado à nova chave.

A interface gráfica tenta nos manter numa zona de conforto, mas é conhecendo a física da caixa e lendo os contadores do hardware que assumimos o controle da arquitetura.