O gerenciamento de memória do vSphere é bastante decente, embora os termos usados geralmente causem muita confusão.
Em geral, o over-commit de memória deve ser evitado, pois cria exatamente esse tipo de problema. No entanto, há momentos em que isso não pode ser evitado, por isso, é preciso avisar antecipadamente!
What are the downsides of overcommitting and over-configuring resources (specifically RAM) in vSphere environments?
A maior desvantagem de recursos excessivamente comprometidos é que, se você tiver contenção, seus hosts serão forçados a fazer um balão, trocar ou planejar de forma inteligente / duplicar os bastidores para fornecer a cada VM a RAM necessária.
Para o balão, o vSphere inflará um "balão" de RAM dentro de uma VM escolhida e, em seguida, fornecerá essa RAM com balão ao convidado que precisar dela. Isso não é realmente "ruim" - as VMs estão roubando a memória uns dos outros, então não há troca de disco acontecendo - mas isso poderia levar a alertas errados e métricas distorcidas se eles dependessem da análise do uso de RAM da VM, já que a RAM venceu pode ser marcado como "balão", apenas que está "em uso" pelo SO.
O outro recurso que o vSphere pode usar é o Transparent Page Sharing (TPS) - que é essencialmente a duplicação de RAM. O vSphere verificará periodicamente toda a RAM alocada, procurando por páginas duplicadas. Quando encontrado, ele irá duplicar e liberar as páginas duplicadas.
Dê uma olhada no whitepaper sobre gerenciamento de memória do vSphere (PDF) - especificamente "Reclamação de memória no ESXi" (página 8) - se você precisar de uma explicação mais detalhada.
Assuming that the VMs can run in less RAM, is it fair to say that there's overhead to configuring virtual machines with more RAM than they need?
Não há sobrecarga visível - você pode alocar 100 GB de RAM em um host com 16 GB (no entanto, isso não significa que você deva , pelos motivos acima).
A memória total em uso por todas as suas VMs é a curva "Ativo" mostrada em seus gráficos. É claro, você nunca deve confiar apenas nesse número ao calcular quanto gostaria de supercompromissar, mas se tiver métricas históricas como você, poderá analisá-lo e resolvê-lo com base no uso real.
A diferença entre RAM "Ativo" e "Consumido" é discutida neste tópico da Comunidade VMware .
What is the counter-argument to: "if a VM has 16GB of RAM allocated, but only uses 4GB, what's the problem??"? E.g. do customers need to be educated?
A resposta curta para isso é yes - os clientes devem sempre ser informados sobre as melhores práticas, independentemente das ferramentas à sua disposição.
Os clientes devem ser educados para dimensionar suas VMs de acordo com o que eles usam , em vez do que eles querem . Na maior parte do tempo, as pessoas especificam em excesso suas VMs apenas porque elas podem precisam de 16 GB de RAM, mesmo que estejam historicamente se atrapalhando com 2 GB dia após dia. Como administrador do vSphere, você tem o conhecimento, as métricas e o poder para desafiá-los e perguntar se eles realmente precisam da RAM que alocaram.
Dito isso, se você combinar o gerenciamento de memória do vSphere com os limites de supercomprometimento cuidadosamente controlados, raramente deve haver um problema na prática; a probabilidade de ficar sem RAM por um período prolongado é relativamente remota.
Além disso, o vMotion automatizado (chamado Programação de recursos distribuídos pela VMware) é essencialmente um balanceador de carga para suas VMs - se uma única VM estiver se tornando um recurso hog, o DRS deve migrar as VMs para aproveitar ao máximo os recursos do cluster.
What specific metric should be used to meter RAM usage. Tracking the peaks of "Active" versus time?
Principalmente abordado acima - sua principal preocupação deve ser o uso de RAM "ativa", embora você deva definir cuidadosamente os limites de supercomprometimento para que, se atingir uma determinada proporção ( este é um exemplo decente , embora possa estar um pouco desatualizado). Normalmente, eu certamente ficaria dentro de 120% da RAM total do cluster, mas cabe a você decidir com qual proporção você está confortável.
Alguns bons artigos / discussões sobre over-commit de memória: