Como a memória é alocada no servidor ESXi?


17

Temos um servidor ESXi 4.1 com 48 GB de RAM.

Para cada VM, estamos alocando 4 GB de memória. Como o servidor terá 13 máquinas virtuais, meu gerente acha que isso está errado.

Vou explicar a eles que o ESXi realmente gerencia a memória em si, mas eles me perguntaram quanta memória eu aloquei para o próprio servidor ESXi.

Eu não aloquei nenhum (nem sequer ouvi falar de uma opção para alocar memória para o próprio servidor ESXi).

Como a memória é alocada para o servidor ESXi? Como ele superaloca / distribui RAM entre máquinas virtuais sem problemas?

Respostas:


26

Há muito mais do que apenas o ESXi em questão aqui,

  1. Cada VM consumirá até 4 GBs + "overhead", documentados aqui . Isso depende das vCPUs, + memória alocada. No mínimo, cada VM usará 4261,98 MBs (4096 + 165,98)
  2. A sobrecarga de memória do ESXi é dependente de hardware. A opção mais fácil é observar o uso da memória do sistema no cliente vSphere. De memória, lembro que está em torno da marca de 1,3 GB, mas como afirmado, isso depende muito do hardware.

Alocação de memória e comprometimento excessivo explicados

Observe que o hipervisor não alocará toda essa memória antecipadamente , depende do uso da VM. No entanto, vale a pena entender o que acontecerá se as VMs tentarem alocar e usar toda a memória alocada para elas.

O máximo que seu host VM + tentará usar será de aproximadamente, a milhagem de 55 GBs pode variar

  • 1,3 GBs usados ​​pelo ESXi
  • 4261,98 MBs * 13 usados ​​pelas VMs

Há outro aspecto a ser levado em consideração: os limites de memória. Por padrão, o VMware tentará ter 6% livre (alto limite de memória). Portanto, os 55 GB de memória usada precisam ser reduzidos para ~ 45 GB

Isso significa que o host terá aproximadamente 10.500 MB de memória necessário para recuperar de algum lugar, caso as VMs usem a memória que foram alocadas. Há três coisas que o ESX faz para encontrar 10,5 GBs adicionais.

Métodos de recuperação de memória

  1. Compartilhamento de página transparente
  2. Balão de memória
  3. Troca de hipervisor

Você deve ler e entender Noções básicas sobre gerenciamento de recursos de memória no VMware® ESX ™ Server .

Dependendo de um grande número de fatores, uma combinação dos três ocorrerá / poderá ocorrer em um host comprometido demais. Você precisa testar seu ambiente e monitorar essas métricas para entender o impacto do comprometimento excessivo.

Vale a pena conhecer algumas regras grosseiras (todas no artigo acima e em outras fontes).

  1. O compartilhamento de página transparente não ocorre para VMs que usam páginas de 2/4 MB. Como você alocou 4096 MBs para as VMs do Windows, eles usarão as páginas de 2/4 MB por padrão (dependendo do PAE). Somente sob pressão de memória o VMware divide as páginas grandes em páginas de 4 KB que podem ser compartilhadas. O TPS depende do uso de ciclos ociosos da CPU e da digitalização de páginas da memória a uma determinada taxa. Retorna a memória de forma relativamente lenta (pense uma hora em vez de minutos). Portanto, uma tempestade de inicialização significa que o TPS não o ajudará. Dos três, isso tem o menor impacto no desempenho. Mais do documento,

Nos sistemas de virtualização de memória assistida por hardware (por exemplo, Intel EPT Hardware Assist e AMD RVI Hardware Assist [6]), o ESX faz backup automaticamente de páginas físicas convidadas com grandes páginas físicas de host (2 MB de região contígua de memória em vez de 4KB para páginas regulares) para melhor desempenho devido a menos perdas de TLB. Nesses sistemas, o ESX não compartilha essas páginas grandes porque: 1) a probabilidade de encontrar duas páginas grandes com conteúdo idêntico é baixa e 2) a sobrecarga de fazer uma comparação bit a bit para uma página de 2 MB é muito maior que para uma página de 4KB. No entanto, o ESX ainda gera hashes para as páginas de 4KB em cada página grande. Como o ESX não trocará páginas grandes, durante a troca de host, a página grande será dividida em páginas pequenas, para que esses hashes pré-gerados possam ser usados ​​para compartilhar as páginas pequenas antes de serem trocadas. Em resumo, não podemos observar nenhum compartilhamento de página para sistemas de virtualização de memória assistida por hardware até que a memória do host seja supercomprometida.

  1. O balão começa em seguida (os limites são configuráveis; por padrão, é quando o host possui menos de 6% de memória livre (entre alta e software)). Certifique-se de instalar o driver e atente para Java e aplicativos gerenciados em geral. O sistema operacional não tem informações sobre o que o coletor de lixo fará a seguir e acabará atingindo as páginas que foram trocadas para o disco. Não é uma prática incomum para servidores que executam aplicativos java exclusivamente desativar o swap totalmente para garantir que isso não aconteça. Dê uma olhada na página 17 do vSphere Memory Management, SPECjbb

  2. A troca de hipervisor , dos três métodos, é a única que garante que a "memória" esteja disponível para o hipervisor em um tempo definido. Isso será usado se 1 e 2 não fornecerem memória suficiente para permanecer abaixo do limite rígido (padrão de 2% de memória livre). Quando você ler as métricas de desempenho (faça você mesmo), perceberá que esse é o pior desempenho dos três. Procure evitá-lo a todo custo, pois o impacto no desempenho será muito visível em quase todos os aplicativos, porcentagem de dois dígitos

  3. Há mais um estado para estar ciente de baixo (por padrão, 1%). No manual, isso pode reduzir drasticamente seu desempenho,

Em um caso raro em que a memória livre do host fica abaixo do limite baixo, o hipervisor continua a recuperar a memória por meio de trocas e compactação de memória, além de bloquear a execução de todas as máquinas virtuais que consomem mais memória do que suas alocações de memória de destino.

Sumário

O ponto principal a enfatizar é que é impossível prever nos white papers como o seu ambiente se comportará.

  1. Quanto o TPS pode lhe dar? (Depende da similaridade das suas VMs com o SO, o Service Pack e os aplicativos em execução)
  2. Com que rapidez suas VMs alocam sua memória? Quanto mais rápido eles forem, maior a probabilidade de você pular para o próximo limite antes que o esquema de recuperação de memória menos impactante consiga manter você no seu limite atual.
  3. Dependendo da aplicação, cada esquema de recuperação de memória terá um impacto muito variado.

Teste seus cenários médios, seu cenário de percentil 95% e, finalmente, o máximo para entender como o ambiente será executado.


Editar 1

Vale acrescentar que, com o vSphere 4 (ou 4.1 não consegue se lembrar), agora é possível colocar a troca de hipervisor no disco local, mas ainda vmotion a VM. Se você estiver usando armazenamento compartilhado, recomendo que você mova o arquivo de troca do hipervisor para estar no disco local por padrão. Isso garante que, quando um host está sob forte pressão de memória, ele não afeta todos os outros hosts / VMs do vSphere no mesmo armazenamento compartilhado.

Editar 2

Com base nos comentários, o ESX não aloca a memória antecipadamente em negrito ...

Editar 3

Explicou um pouco mais sobre os limites de memória.


1
O VMware não atribui memória que não é usada; a verdadeira razão pela qual a confirmação excessiva funciona é porque a VM receberá apenas a quantidade máxima de memória quando solicitada . Depois que tudo é alocado, os pedidos de memória extra vêm do swap.
adaptr

1
Você viu esse bit antes de adicionar esse comentário? "Observe que o hipervisor não alocará toda essa memória antecipadamente, depende do uso da VM. No entanto, vale a pena entender o que acontecerá se as VMs tentarem alocar e usar toda a memória alocada para elas"
M Afifi

Como essa era uma das principais preocupações dos OPs (como o vmware evoca a memória que NÃO POSSO?), Ela deveria aparecer no topo da lista, não como uma reflexão tardia. Você está explicando o uso da memória de trás para frente, explicando a recuperação. Por quê ?
adaptr 23/08/2012

Como é ao contrário? A resposta diz: esta é a quantidade de memória que você alocou. Não o alocará antecipadamente. Se isso acontecer (com base no uso da memória da VM), esse será o impacto. Não posso realmente dizer a alguém que não se preocupe. Se você comprometer demais a memória, deve saber o impacto.
M Afifi

4

O VMware (e outras tecnologias de virtualização) compartilham recursos (memória, tempo do processador, E / S de vários tipos) entre VMs de acordo com vários algoritmos.

É possível comprometer demais os recursos, porque nem todas as VMs estarão usando todo o processamento, memória ou E / S de que precisam o tempo todo. O guia de gerenciamento de recursos da VMware é provavelmente o melhor lugar para ler sobre o que é possível no ESXi.

Você também pode gerenciar o efeito dos algoritmos ponderando VMs diferentes para recursos diferentes - por exemplo, você pode atribuir a uma VM do servidor de aplicativos uma ponderação mais alta por processador do que uma VM do servidor de arquivos. No entanto, as configurações prontas para uso tratam muito bem da maioria dos requisitos. Em alguns casos, fazer algumas configurações aqui é suficiente para apaziguar os gerentes que não conseguem, mas é claro que tenha cuidado e leia os documentos da sua versão do VMware e entenda o que está fazendo. Se o seu gerente não precisar de mais veiculações, use os padrões.

Observe que o comprometimento excessivo nem sempre é uma boa ideia, principalmente se você virtualizou em um único servidor. Você deve monitorar o uso de recursos em seu ESXi estate e, se necessário, adicionar hosts / recursos adicionais se estiver consumindo com frequência todos ou quaisquer recursos.


2

Deixe sua instalação do VMWare ESXi lidar com isso. Você pode comprometer demais os recursos de RAM nos sistemas VMWare devido ao uso de técnicas de balão de memória, compactação e deduplicação .

Se as máquinas virtuais estão usando um sistema operacional semelhante, há algumas economias lá. Certifique-se de ativar as ferramentas VMWare dentro das VMs convidadas para fazer uso total desses recursos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.