Troubleshooting Comum no Hypervisor Nutanix

Introdução ao Troubleshooting no Hypervisor Nutanix (AHV)

O ambiente de virtualização baseado em Nutanix, que utiliza o Hypervisor AHV (Acropolis Hypervisor) nativo, oferece uma arquitetura simplificada em relação às soluções tradicionais. No entanto, como qualquer sistema complexo de infraestrutura, falhas podem ocorrer e exigem um diagnóstico sistemático. Este guia técnico aborda os cenários de troubleshooting mais comuns enfrentados por sysadmins e engenheiros de infraestrutura ao gerenciar clusters AHV.

O objetivo deste tutorial é fornecer um fluxo lógico de investigação, focado na coleta de evidências via linha de comando (CLI) do CVM (Controller VM) e no uso da interface Prism Element. Ao final, você terá comandos prontos para identificar gargalos de CPU, problemas de rede, instabilidade de storage e falhas de comunicação entre os hypervisors.

1. Verificação do Status Geral do Cluster

O primeiro passo em qualquer incidente é avaliar a saúde macroscópica do cluster. Antes de mergulhar em logs específicos, confirme se o controlador do Nutanix (Prism Element) está operando e se os serviços essenciais estão ativos.

1.1. Acesso ao CVM

Todos os comandos de diagnóstico abaixo devem ser executados via SSH no Controller VM (CVM). Utilize as credenciais administrativas padrão do ambiente Nutanix.

ssh root@cvm_ip_address

1.2. Verificação da Saúde do Cluster via CLI

O comando nutanix_cbs_status ou a API REST subjacente podem ser usados, mas a ferramenta mais robusta para visão geral é o acli (Acropolis Command Line Interface) ou os scripts de diagnóstico embutidos.

# Verifica se todos os nós do cluster estão Online
cluster get_health --json

Procure por instâncias com status diferente de HEALTHY. Se houver alertas, anote o ID do nó afetado para investigações posteriores.

1.3. Uso do Script de Diagnóstico Automático

O Nutanix fornece um script automatizado que coleta logs, configurações e métricas de desempenho. Este é frequentemente o primeiro passo solicitado pelo suporte técnico oficial.

/usr/local/falcon/bin/acropolis_dump.sh --output /home/admin/

Após a execução, o arquivo gerado estará disponível para download via SFTP no diretório especificado. Certifique-se de que há espaço em disco suficiente antes da execução.

2. Troubleshooting de Desempenho e I/O

Fragilidade na performance de I/O é uma das queixas mais frequentes. Antes de culpar o storage, verifique a contenda no hypervisor.

2.1. Monitoramento de CPU e Memória do Hypervisor

O AHV roda sobre Linux Kernel (KVM). Comandos padrão do Linux são válidos para verificar a carga do host físico.

# Verifica uso de CPU por core
top -bn1 | grep "Cpu(s)"

# Verifica se há swap sendo utilizado (sinal crítico de falta de memória)
free -h

Se o swap estiver ativo, as VMs sofrerão severamente. No AHV, a alocação de memória deve ser cuidadosa para evitar overcommit excessivo que exija troca com o disco.

2.2. Latência de Disco no Storage Pool

O Nutanix usa um storage distribuído (AOS). Para verificar se há latência anormal nas operações de leitura/escrita:

# Verifica estatísticas de I/O do CVM
iostat -x 1 5

Observe a coluna %util. Se estiver consistentemente acima de 80-90% em todos os nós simultaneamente, pode haver um problema de balanceamento ou falha física no disco. Verifique também o await; valores altos indicam que as requisições estão ficando presas na fila.

2.3. Identificação de VMs "Noisy Neighbor"

Às vezes, uma única VM está consumindo recursos desproporcionalmente. Use o acli para listar VMs e seus recursos:

acli vm.list

Para métricas específicas de uma VM (substituindo VM_NAME):

acli vm.get_metric VM_NAME cpu_usage_percent
acli vm.get_metric VM_NAME disk_read_iops
acli vm.get_metric VM_NAME disk_write_iops

Se uma VM específica estiver saturando a CPU ou I/O, considere aplicar quotas de recursos (CPU/Memória) via Prism Element para isolar o problema.

3. Diagnóstico de Problemas de Rede no AHV

A rede é o componente que mais causa falhas silenciosas no Nutanix. O AHV utiliza uma ponte lógica chamada br0 (geralmente) para gerenciar o tráfego entre VMs e o mundo físico.

3.1. Verificação da Interface de Rede do Hypervisor

Confirme se a interface de gerenciamento do CVM e as interfaces de uplink estão ativas.

# Lista interfaces de rede
ip addr show

Verifique o estado das portas físicas (NICs) no switch. No lado do host, use:

ethtool eth0 | grep "Link detected"

O resultado deve ser yes. Se for no, há um problema físico ou de configuração do switch (VLANs incorretas, port-channel desativado).

3.2. Teste de Conectividade entre CVMs

O cluster Nutanix depende de comunicação baixa latência entre os CVMs para replicação de dados e consenso. Se um nó não consegue pingar outro, o cluster pode entrar em modo de degradação.

# Ping inter-nó (exemplo entre dois CVMs)
ping -c 4

Se o ping falhar, verifique as regras de firewall no switch ou no próprio host Linux. No AHV, as portas padrão são críticas para a comunicação do cluster.

3.3. Verificação da Bridge (br0) e VLANs

O br0 é responsável por encapsular o tráfego das VMs. Se uma VM perde conectividade de rede:

# Verifica a configuração da bridge
brctl show br0

Confirme se as interfaces físicas (ex: eth1, eth2) estão anexadas à bridge. Se estiverem, verifique a configuração de VLAN:

ip link show eth1

Erros comuns incluem configurações incorretas de MTU (deve ser 9000 para jumbo frames se suportado pelo switch) ou erros de tagging VLAN.

4. Troubleshooting de Storage e Sincronização de Dados

O AOS (Acropolis Operating System) distribui dados em blocos across todos os discos do cluster. Problemas aqui são críticos.

4.1. Verificação do Estado dos Discos Locais

Falhas de disco podem levar à perda de disponibilidade se não houver réplicas suficientes configuradas.

# Lista discos e seus estados
lsblk

No Nutanix, é preferível usar a API ou o acli para visão lógica:

acli storage_pool.get_health

Procure por discos com status DEGRADED ou FAILED. Se houver falhas, o sistema deve estar reconstruindo (rebuilding) automaticamente. Monitore a velocidade dessa reconstrução.

4.2. Sincronização de VMs (VM Sync)

O Nutanix replica metadados e dados das VMs. Se houver um atraso grande na sincronização:

# Verifica o estado de replicação
nutanix_cbs_status --sync

Se o status indicar SYNC_ERROR, verifique a integridade do banco de dados local no CVM. Em casos raros, reiniciar o serviço de storage pode ajudar:

cvm_restart_stargate

4.3. Verificação de Espaço em Disco no CVM

O CVM armazena metadados e logs. Se o disco do sistema operacional do CVM encher, o cluster para.

# Verifica uso de disco
df -h

Foque na partição /home/admin ou /. Se estiver cheia, limpe logs antigos manualmente (com cautela) ou aumente a capacidade do CVM via Prism Element.

5. Análise de Logs e Coleta de Evidências

Quando os comandos acima não revelam a causa raiz, a análise de logs é necessária.

5.1. Localização dos Logs Principais

No CVM, os logs do AHV estão localizados em:

/var/log/ahv/
/var/log/lighttpd/  # Logs do servidor web Prism
/var/log/metadata_server.log

5.2. Busca por Erros Críticos

Use grep para filtrar mensagens de erro recentes:

# Busca por erros críticos no log do AHV
grep -i "error\|critical\|fatal" /var/log/ahv/ahvd.log | tail -n 20

Procure por falhas de conexão com o Prism Controller ou erros de inicialização de VMs.

5.3. Coleta de Logs via Prism Element

A interface gráfica facilita a geração de pacotes de logs:

Acesse o Prism Element.
Navegue até Cluster > Settings.
Vá para a aba Support.
Clique em Create Support Bundle.
Selecione os nós afetados e clique em Download.

O arquivo baixado contém todos os logs do cluster, pronto para análise por especialistas.

6. Boas Práticas e Prevenção

Além de corrigir erros, a manutenção preventiva é essencial em ambientes Nutanix.

Mantenha o AOS Atualizado: Versões mais recentes incluem correções de bugs críticos e melhorias de desempenho. Verifique a matriz de compatibilidade antes de atualizar.
Monitore a Saúde do Cluster: Configure alertas no Prism para uso de CPU, memória e espaço de storage. Não espere o sistema parar para agir.
Documente Alterações: Mantenha um registro de mudanças na configuração de rede e storage. Muitos problemas são causados por atualizações recentes não documentadas.
Verifique Backups: Certifique-se de que as VMs críticas estão sendo protegidas por snapshots ou ferramentas externas (como Veeam, se integrado).

Conclusão

O troubleshooting no Hypervisor Nutanix AHV requer uma abordagem metódica: comece pela saúde geral do cluster, isole o componente afetado (CPU, Rede, Storage), colete dados específicos e, se necessário, envolhe o suporte técnico com os bundles de logs coletados.

A maioria dos problemas comuns pode ser resolvida verificando a conectividade de rede entre CVMs, o estado dos discos locais e o uso de recursos pelos hypervisors. Lembre-se: a coleta correta de evidências acelera drasticamente a resolução do incidente.

Para casos complexos que não se resolvem com os passos acima, abra um ticket no suporte técnico do Nutanix, anexando o arquivo gerado pelo comando acropolis_dump.sh. Isso garantirá que os engenheiros de nível 2 ou 3 tenham todas as informações necessárias para diagnosticar falhas profundas no kernel ou no sistema de storage distribuído.