Como conservar memória e executar mais vms no vSphere 5.0 com vCenter 5.0?

Question

O servidor tem 16 gig de memória. Queremos executar o máximo de VMs possíveis neste servidor. Eles são usados como "escravos" de testes automatizados em uma VM Jenkins que distribui tarefas de teste.

As VMs atualmente totalizam 10,6 Gig de memória usada no vSphere.

Mas os relatórios do vSphere 12,1 Gig de 16 Gig são usados. Isso implica que o próprio vSphere está usando 1,5 Gig.

Portanto, há apenas 4 Gig restantes no servidor.

Observe que o vCenter informa que cada VM abaixo está usando menos que a memória cheia.

1. O vCenter Server Appliance leva 4 Gig. 10% usado.
2. Jenkins Appliance leva 500 Meg. 14% usado.
3. O Windows 7 x64 leva 2 GB. 15% usado.
4. O Windows 7 x64 leva 2 GB. 15% usado.
5. O Windows 7 x64 leva 2 GB. 9% usado.

Perguntas: 1. O 4 Gig restante significa que só podemos executar mais 2 desses 2 gig Windows vms?

2. O% usado nos permite "over commit"? As máquinas raramente usam mais memória, a menos que ocorra um vazamento de memória no software em teste.

3. O que acontece se "nos comprometermos" e uma máquina precisar de mais memória?

4. Se não podemos confiar demais, não faz sentido desligar o vCenter Server? Parece que, como só temos um servidor vSphere, o vCenter é excessivo. Nós só precisamos disso para "clonar", já que o cliente vSphere não suporta clonagem. Então, talvez desligar a maior parte do tempo seja melhor.

5. Quaisquer outras ideias ou sugestões para permitir a execução de muito mais VMs?

Answer 1

1: Sim, você pode comprometer demais. Veja 2,3 para detalhes

2: Se a memória física ficar cheia, o ESX (i) inicia seus recursos Memory Ballooning , Transparent Page Sharing e Memory Compression . Quando a memória fica cheia enquanto esses recursos são usados, o Host irá trocar.

Balões de Memória

Quando um administrador instala o VMware Tools, o driver memctl (também conhecido como ballooning driver) é instalado no sistema operacional convidado. Este driver cria uma bolha ou "balão" de memória consumido dentro do convidado para que o sistema operacional o veja como sendo usado por um aplicativo. o hypervisor, em seguida, leva a RAM física liberada inflando este balão e aloca-lo para outras VMs que exigem isso. Balão de memória introduz uma pequena quantidade de sobrecarga de processamento e, se forçar OS convidado para começar a paginação para o disco, isso pode diminuir significativamente a (s) aplicação (ões) em a VM. Se a VM não estiver usando a memória, o balão em si não é sério problema de desempenho, mas é uma indicação de que a memória física no host está se tornando escasso. Uma das maiores vantagens do ballooning de memória sobre outros métodos de manipulação super-compromisso de memória é que o driver de balão de memória permite que o convidado sistema operacional para escolher quais páginas são liberadas para o hypervisor para VMs. Dessa forma, as páginas que não estão em uso ativo podem ser liberadas com segurança, causando quase sem impacto no desempenho da perspectiva do hóspede.

Compartilhamento de página transparente

O compartilhamento transparente de páginas é a “desduplicação” de memória que permite a virtualidade idêntica páginas de memória a serem recolhidas em uma única página dentro da RAM física do host, liberando memória para outros usos. Por exemplo, se várias máquinas virtuais em um host estão executando o mesmo sistema operacional e aplicativo, o hypervisor comparar páginas de memória através de hashing para localizar páginas idênticas que podem ser liberadas através da sua consolidação. Compartilhamento de página transparente e com balões de ar funcionam juntos para garantir que a memória super comprometida não cause problemas de desempenho aplicativos nas máquinas virtuais convidadas.

Compressão de memória

Compressão de memória e troca de disco pelo hipervisor são os últimos esforços por ESX / ESXi para impedir que o hipervisor caia quando houver recursos de memória no host são esticados até o ponto de ruptura. A compactação de páginas de memória pelo o hipervisor também causa sobrecarga de processamento adicional; no entanto, essa sobrecarga é pequena em comparação com o abrandamento causado pela troca de páginas para um dispositivo de armazenamento. Os usuários do vSphere 4.1 e superior poderão aproveitar esse recurso para reduzir a quantidade de troca ocorrendo quando os recursos da memória física estão próximos de estando exausto.

Roubado de Considerações de dimensionamento da memória VM (vRAM)

3: Se você desligar, você não pode mais usá-lo, então nenhuma estatística é gravada, etc. Eu não sei o que acontece com HA e outras coisas. Eu não desligaria. Se a VM estiver inativa, o ESX saberá e lidará com ela. Observe que, os recursos de memória listados são usados quando necessário (veja descrição), então a memória aumentará menos quanto mais memória for usada. Tente desperdiçar drasticamente a memória para ver como sua VM do vCenter é reduzida. Eu não acho que vai perder muita memória em idle

4: Veja o livro branco vinculado para obter informações sobre como obter a resposta