Você está tentando entender o problema do ponto mais difícil, os recursos da CPU. Aproxime-se da memória em vez disso e é um pouco mais fácil de entender.
O host tem x quantidade de memória, e o host reserva uma quantidade de memória para seus propósitos nefastos (que, a propósito, segue a fórmula um MB inicialmente e o b MB para cada VM que está ligada). Se você não permitir a assinatura / alocação excessiva, atribua um total de x-y às suas VMs, e cada VM sempre poderá obter a memória alocada. No entanto, isso é muito ineficiente, então, geralmente, você aloca excessivamente a memória em suas máquinas. Se a sua política declara que 3: 1 é ok, então você pode atribuir 3 * (x-y) às suas VMs (ou praticamente 3x como a quantidade que o VMware ESXi precisa não é nada comparado à memória total).
Se o host ficar sem memória, ele primeiro tentará o ballooning (que começa com 95% de utilização), onde o VMtools começa a solicitar memória ao sistema operacional convidado e, em seguida, exclui todas as páginas que recebe (como qualquer sistema operacional dá o driver de balão não está sendo usado atualmente pelo sistema operacional, por isso é seguro para excluir). Se isso não ajudar, o ESXi faz o que qualquer outro sistema operacional faz quando fica sem memória, ele começa a trocar a memória para o disco. O ESXi faz isso por VM (já que tem que levar em conta ações, reservas e limites).
As vCPUs funcionam de forma um pouco diferente, já que tecnicamente não é um recurso da maneira como a memória e o disco são (ou seja, uma CPU de 20 GHz de 2 GHz não é a mesma de 1 GHz de 40 GHz). Em primeiro lugar, o Hyperthreading não oferece o dobro da quantidade de núcleos. Os números oficiais da VMware são que o HT oferece um ganho de desempenho de 10 a 30%. Em segundo lugar, as vCPUs são multiplexadas, portanto, o planejador fornece intervalos de tempo nas pCPUs para as diferentes vCPUs. Portanto, se você tiver uma CPU de 8 núcleos em seu host, ela poderá executar 8 VMs de 1-vCPU no mesmo ciclo de clock ou 1 8-vCPU. Isso dá a você um problema de que, em um host altamente carregado, você pode ver quedas de desempenho atribuindo mais núcleos a uma VM, pois o planejador tem dificuldade em localizar um intervalo de tempo suficientemente grande para executar a VM maior.Compartilhamentos, reservas e limites são uma maneira de contornar isso.
Reservas são uma garantia, também conhecida como. Se você der a uma VM uma reserva de 500 MHz, o hipervisor fornecerá 500 MHz, independentemente do que estiver acontecendo no host. Se a reserva não estiver sendo usada no momento, ela fornecerá os recursos para outra VM por enquanto (para que você nunca perca recursos configurando reservas).
Por outro lado,Limits definem um "teto" ou limite para um recurso. Isso é útil se você quiser que uma VM acredite que ela tenha mais recursos do que realmente pode obter. Isso realmente não tem uso prático (foi usado em versões anteriores do ESXi como uma maneira de obter mais memória do que remover o limite) hoje, além de enganar os fornecedores de software, e também não é muito útil nisso. Os limites são impostos impiedosamente, portanto, se você atribuir um limite de 1 GB de memória a uma máquina com 4 GB configurados, essa máquina nunca receberá mais de 1 GB de memória física.
Compartilhamentos são um pouco diferentes, eles permitem que você "pondere" a "importância" de uma determinada VM quando se trata de recursos diferentes. No ESXi, cada VM é igual e, ao competir por recursos, 2 VMs com 1000 compartilhamentos receberão o recurso em 50% do tempo. Ao alterar as ações para dizer 3000 vs 1000, você pode alterar a divisão para 75% / 25%. Os compartilhamentos são usados apenas quando as VMs estão competindo por recursos.
Portanto, para realmente responder à sua pergunta, a superalocação significa atribuir 32 vCPUs (2 GHZ cada) às suas VMs em um host que tenha uma CPU de 16 núcleos sem HT. Sua CPU tem 32 GHZ "disponíveis", mas você atribuiu 64 GHz às suas VMs. Isso é 2 para 1 over-allocation / subscription. Mas se você sabe alguma coisa sobre servidores, eles estão ociosos a maior parte do tempo, portanto, seu host pode não ver mais de 16 GHz de carga. Mas, teoricamente, essa configuração poderia produzir uma demanda de 64 GHz, o que sobrecarregaria seu host. O HT não é muito útil para estes cálculos, mas você poderia adicionar 25% sobre o valor do seu "não-HT" GHz para ter uma idéia de seus benefícios.