Cuca Fresca IT

No artigo anterior sobre arquitetura distribuída e continuidade, detalhamos como o gargalo de I/O do ambiente legado foi resolvido através do armazenamento distribuído. Com o AOS assumindo o controle direto dos discos e a resiliência dos dados, o foco de otimização naturalmente se voltou para a camada de computação. Para reduzir a latência, unificar o caminho de comunicação e remover a dependência de softwares intermediários, desenvolver um hipervisor próprio tornou-se o próximo passo lógico da Nutanix.

A Nutanix não decidiu compilar um hipervisor do zero apenas para competir no mercado. Houve um processo de maturidade técnica. No início da operação, o foco era resolver o gargalo do storage tradicional. O AOS nasceu gerenciando os discos operando em conjunto com o VMware vSphere. A arquitetura foi validada no campo e o suporte foi estendido para o XenServer (atual Citrix Hypervisor) e para o Microsoft Hyper-V.

Essa fase multi-hipervisor trouxe lições práticas. A equipe de engenharia mapeou como cada kernel do mercado lidava com o roteamento de I/O, as falhas das stacks de rede e as ineficiências na gestão de armazenamento. Com a consolidação das tecnologias, manter o suporte a todas as plataformas gerou um overhead de desenvolvimento. O XenServer foi descontinuado do suporte oficial e a compatibilidade com o Hyper-V foi encerrada na versão 7.0 do AOS.

O AHV nasceu dessa base de conhecimento. Ficou evidente que, para extrair a latência mínima do hardware e do protocolo NVMe, depender de um kernel de terceiros era um gargalo estrutural. A Nutanix precisava controlar todo o caminho do I/O, da máquina virtual até a gravação física no SSD.

A Arquitetura Interna do AHV

Para garantir esse controle direto, a arquitetura do AHV funciona sobre os seguintes fundamentos técnicos:

• Base KVM e Hardening Nativo: O AHV é um fork corporativo construído sobre o KVM (Kernel-based Virtual Machine). Ele possui uma superfície de ataque reduzida, aplicando diretrizes de segurança (STIG) de forma automática. Pacotes e serviços não essenciais são removidos do kernel, garantindo que os ciclos de CPU sejam dedicados à execução das máquinas virtuais e ao tráfego do Open vSwitch.
• Plano de Controle Distribuído (Master/Worker): O cluster não utiliza um servidor central de gerência. O serviço Acropolis roda de forma nativa e distribuída em todas as CVMs (Controller VMs). O cluster elege um Node Master responsável por coordenar o agendamento de tarefas, provisionamento e coleta de estatísticas, enquanto os demais atuam como Workers. Se o Node Master sofre uma falha de hardware, o algoritmo de consenso do cluster elege um novo Master automaticamente, mantendo o plano de controle operacional sem exigir restauração de banco de dados ou intervenção humana.
• Caminho do I/O e CVM Autopathing: A máquina virtual processa requisições de disco utilizando os drivers paravirtualizados VirtIO. O fluxo de I/O sai da máquina virtual, passa pelo switch virtual interno (virbr0) e atinge o IP link-local fixo 192.168.5.2, caindo diretamente no processo Stargate da CVM local. O recurso de CVM Autopathing atua no tratamento de falhas. Se a CVM local precisa ser reiniciada ou falhar, o tráfego de I/O é redirecionado automaticamente para a CVM de um Node vizinho, mantendo o serviço online.
• Rede Virtual, OVS e Balanceamento de Uplinks: O controle do tráfego leste-oeste e a comutação de pacotes são executados pelo OVS (Open vSwitch), que roda no kernel space do AHV para otimizar o processamento. Cada Node gerencia sua própria bridge (br0). Na integração com a infraestrutura física, o OVS abstrai as placas de rede do Node agrupando as portas em bonds lógicos. A agregação de banda e a tolerância a falhas são controladas nativamente por algoritmos de balanceamento de uplinks, permitindo configurar a saída de tráfego via Active Backup, Balance SLB (Source Load Balancing) ou Balance TCP (exigindo LACP no switch físico). O hipervisor gerencia a resiliência da conexão sem exigir configuração adicional dentro do sistema operacional convidado.
• Serviço de IPAM e DHCP Distribuído: O Acropolis incorpora nativamente a função de IP Address Management (IPAM). A própria plataforma atua como um servidor DHCP distribuído. A infraestrutura intercepta as requisições de rede na porta do switch virtual e entrega os endereços IP designados para as máquinas virtuais. O controle de sub-redes, pools de endereços e reservas passa a ser gerenciado na mesma interface de alocação de armazenamento, simplificando a automação.
• Alta Disponibilidade e Agendamento (HA e ADS): O monitoramento da saúde do cluster ocorre por heartbeats de rede e de armazenamento. Em caso de kernel panic ou isolamento de rede de um Node físico, os Nodes sobreviventes quebram o lock dos discos virtuais afetados e reiniciam os workloads obedecendo a uma ordem de prioridade definida no Prism. Paralelamente, o ADS (Acropolis Dynamic Scheduling) monitora a latência e o controlador de storage. Se uma máquina virtual gerar um gargalo de processamento de disco, o ADS migra o workload a quente para outro Node, equilibrando a carga do armazenamento distribuído.

A Analogia: O Plano de Saúde com Coparticipação vs. Completo

Vamos tirar o tecniquês da sala e pensar na infraestrutura de TI como o plano de saúde da sua família.

Rodar o Nutanix com um hipervisor de terceiros é ter um plano de saúde com coparticipação. O dia a dia no consultório funciona, mas o problema aparece na madrugada quando alguém da família passa mal e precisa de uma cirurgia de emergência. Você chega no hospital (a infraestrutura física) e eles avisam que a sala de cirurgia está pronta, mas a equipe de cirurgiões (o hipervisor) é de uma clínica terceirizada. Com o paciente passando mal na recepção, o hospital diz que a culpa é da equipe médica que atrasou, enquanto a equipe médica alega que o hospital não liberou os equipamentos. Você, o cliente que assina o cheque, vira garoto de recados entre duas empresas diferentes no meio de uma crise. A responsabilidade é dividida e o seu problema demora o dobro do tempo para ser resolvido.

Já rodar o Nutanix completo com o hipervisor nativo (AHV) é ter o plano de saúde completo. O hospital, a sala de cirurgia, o maquinário e o médico pertencem exatamente à mesma empresa e respondem pelo mesmo CNPJ. Se der uma emergência na madrugada, o médico não vai jogar a culpa na infraestrutura do hospital porque ele faz parte dela de forma nativa. Ambos olham a mesma ficha médica em tempo real (o Prism). A triagem e a solução acontecem lá dentro, sem você precisar intervir e mediar conflitos. Você liga para um único número de telefone e eles resolvem de ponta a ponta, eliminando o jogo de empurra.

Essa diferença de modelo de negócio fica ainda mais óbvia na hora da expansão. Imagine que a família cresceu e você precisa incluir um novo dependente no plano, o que em TI significa precisar de mais performance e adicionar um Node físico no cluster. No modelo terceirizado, você paga a mensalidade do dependente novo comprando o hardware, mas descobre que para usar o hospital precisa pagar uma taxa de liberação extra para a clínica dos médicos terceirizados. Você paga o pedágio do software só para ter o direito de usar a máquina que acabou de comprar. No plano completo com AHV, a expansão é direta e limpa. Você inclui o dependente provisionando o Node no rack, e a equipe médica com toda a estrutura já estão inclusas no pacote, sem taxa surpresa de licenciamento para liberar o atendimento.

Tudo isso expõe um custo prático na operação: no modelo fragmentado, a conta final não chega apenas na fatura de renovação da licença, ela é cobrada no tempo que o seu negócio passa fora do ar ou operando com lentidão extrema.

Cenário: O Jogo de Empurra na Madrugada

Sexta-feira de fechamento fiscal. O banco de dados SQL Server que processa o faturamento da empresa começa a acusar latência de escrita batendo 100ms constantes. No ambiente 3-tier tradicional começa o clássico ping-pong de suporte.

Você abre o chamado nível 3 no fornecedor do hipervisor. O analista exige a exportação de gigabytes de log e afirma que o Node está esperando o disco responder. Você abre um ticket paralelo no fabricante do storage. A equipe de storage analisa os logs da controladora e devolve dizendo que a LUN está respondendo em 2ms e que a falha só pode estar no switch Fibre Channel, no conector ou em um driver desatualizado na placa HBA do Node. O negócio segue degradado, enquanto engenheiros de três empresas diferentes trocam e-mails tentando provar quem não é o culpado.

No ambiente Nutanix rodando AHV, o cenário muda. O AHV e o AOS compartilham exatamente a mesma base de telemetria. Você abre o Prism Element e a trilha de I/O é transparente, cobrindo o caminho desde a máquina virtual até o bloco físico no SSD NVMe. O suporte corporativo é acionado com um ticket único. O engenheiro do outro lado da linha tem acesso ao log do hipervisor (AHV), do controlador de rede (OVS) e do motor de storage (Stargate). O isolamento do gargalo ocorre na mesma interface. Descobre-se rapidamente que um SSD NVMe específico entrou em estado de degradação silenciosa. A CVM marca o disco como inativo, o sistema redireciona a carga para os discos saudáveis e o cluster volta ao tempo de resposta de 1ms. O problema cai de horas de investigação isolada para minutos de análise unificada.

Conclusão

Datacenters tradicionais forçam a equipe de TI a atuar como integradora de sistemas, consumindo esforços para garantir que o armazenamento de um fabricante converse com a camada de computação de outro. Essa fragmentação onera a operação e altera o cálculo do TCO. O modelo legado impacta os custos em dois pontos. O primeiro é o CAPEX, com a necessidade de licenças de virtualização isoladas do hardware. O segundo, crítico para o longo prazo, é o OPEX. A sustentação consome horas da equipe de TI gerenciando painéis isolados, validando matrizes de compatibilidade e executando ciclos de atualização desconectados.

Com o motor de virtualização, o AHV operando como um recurso nativo junto ao sistema de arquivos distribuídos AOS, a equipe de TI elimina a gestão de camadas. O agendamento de recursos dos workloads, a rede e o armazenamento dos dados em disco respondem ao mesmo plano de controle. O ROI da Nutanix como plataforma é justificado na eficiência do Dia 2. A operação se estabiliza porque a equipe de TI deixa de olhar para janelas de manutenção fragmentadas e para o troubleshooting cruzado entre fornecedores.

No fim das contas, a maturidade da infraestrutura se consolida quando o ambiente deixa de exigir intervenções contínuas. É tirar o foco da microgerência de componentes para focar na entrega de recursos para as aplicações, operando um datacenter unificado e previsível.

Reflexão

1. Quando o desempenho do seu ambiente degrada, quantas frentes de suporte sua equipe precisa acionar simultaneamente para achar a causa raiz?
2. Qual é a porcentagem que o licenciamento do hipervisor consome do seu orçamento de TI?
3. Quanto custa para a sua empresa cada hora que o negócio opera com lentidão ou inatividade, enquanto fabricantes diferentes discutem de quem é a culpa técnica?

No nosso próximo artigo, iremos explorar a camada de gerência abordando o Prism Central e Prism Element. Vamos mapear a diferença técnica entre operar um cluster único na trincheira e administrar uma visão multi-cluster unificada, detalhando as funções exclusivas de arquitetura. Do ponto de vista de negócio, o foco será a gestão de custos e riscos. Mostraremos como essa visibilidade global evita o provisionamento fantasma, corta o desperdício de recursos em ambientes complexos e otimiza a produtividade da equipe de TI.

Fontes

https://www.nutanixbible.com/5a-book-of-ahv-architecture.html