Uma das grandes promessas da virtualização é a capacidade de recuperar grandes quantidades de recursos que antes eram inativos em servidores físicos. É uma meta alcançável, mas infelizmente uma grande quantidade de administradores de sistemas não veem os resultados esperados. Isso porque eles estão provisionando de maneira errada. Virtualização, especificamente de hardware usando um hypervisor, requer uma mudança em como se vê a alocação de recursos.
As três áreas onde vejo os maiores erros são alocação de vCPU, alocação de memória e templates. Vamos discutir cada uma delas e como elas afetam o dimensionamento de máquinas virtuais – nesse caso, no vSphere, da VMware.
Dimensionar vCPUs
Arriscaria dizer que ao menos 80% das máquinas virtuais que tive contato nunca usam mais de 10% de sua vCPU provisionada. Ainda, vejo muito mais máquinas virtuais com duas vCPUs provisionadas em vez de uma. Por causa da maneira com a qual o horário de trabalho funciona, isso geralmente não é um problema. Contudo, quando a contenção é necessária, uma vCPU superprovisionada pode causar um pico no %ReadyTime (o tempo que uma vCPU tem para esperar pela CPU física) e acabar com a performance.
Adicionar vCPUs desnecessárias também pode prejudicar sua taxa de consolidação. Na média, você deve ver de quatro a seus vCPU por core físico. Se cada máquina virtual tem uma vCPU a mais do que realmente precisa, você apenas está com duas a três vCPUs por core.
Para dimensionar apropriadamente uma vCPU para uma máquina virtual, olhe para as métricas de performance do workload. Se a aplicação não está com múltiplas threads e o pico de CPU é abaixo de 3000MHz, provisione uma única vCPU.
Provisionar memória
Dimensionar a memória requer equilíbrio: muito ou pouco pode forçar conteção. Devido à natureza semi persistente da memória, é mais complicado fazer isso do que dimensionar CPUs.
Ao provisionar a memória, é importante entender memória ativa x memória alocada, comportamento do tempo de boot do sistema operacional e o paging.
A memória ativa é a memória que o sistema operacional do usuário e da aplicação realmente usa. A memória alocada é a quantidade física de RAM que o usuário requereu do vSphere. A ideia é ter o delta nesses dois números ser o menor possível durante o pico de uso. É melhor errar do lado da cautela e ter muito mais do que muito pouco, mas tentar chegar o mais próximo possível.
Quando um servidor Windows faz o primeiro boot, ele toca toda a memória “endereçável” . Isso “afirma” a memória do vSphere, se estiver disponível. Se ele não estiver disponível, o pedido pode causar a recuperação de memória e obrigar contenção. É por isso que é importante provisionar apenas a memória realmente necessária. Sistemas operacionais Linux não têm esse mesmo problema; eles tratam de memória somente quando necessário.
Provisionamento preciso de memória também é importante a fim de evitar hypervisor paging. À medida que o hypervisor não está ciente das aplicações rodando em cada workload, ele pegará memórias aleatoriamente para paginar ao disco se necessário. Se é memória ativa, pode devastar a performance da aplicação.
Um ponto importante é que quanto menos memória uma máquina virtual tiver, mais rápido pela vai completar um evento vMotion.
Usar templates
Um erro comum é: quando novas máquinas virtuais são desenvolvidas de um template, elas não são customizadas. Ao clonar um template, tenha um tempo para ajustar os recursos provisionais para o que eles serão realmente utilizados pela máquina virtual, ou então os recursos serão desperdiçados. Esse esforço extra irá estender a vida do seu cluster por um bom tempo.
A coisa mais importante que você, administrador vSphere, pode fazer é entender as necessidades reais das cargas de trabalho que você está hospedando. Quando os proprietários de aplicativos pedir novas máquinas virtuais, faça-os provar que precisam mesmo dos recursos que estão solicitando (se possível).
Só porque recursos virtuais podem ser excessivamente demandados, não significa que são intermináveis. Pelo provisionamento adequado, você terá um melhor desempenho, os usuários ficarão mais felizes e você terá menos chamadas de suporte às 2 da manhã. Ninguém gosta dessas chamadas.
