Memória: O ponto mais crítico para virtualização

by  Fabio_hara@Hotmail.Com  on  10 DE JULHO DE 2012 - 13 COMMENTS

De todos os 4 principais aspectos de hardware para virtualização (processador, disco, rede e

memória) é de comum acordo entre todos os virtualizadores de que gerenciar memória é a

parte mais crítica. O custo da memória e sua limitação de expansão em muitos servidores

são fatores que tornam muito difícil agregar muitas maquinas virtuais em um único

hardware. Os fabricantes de virtualizadores implementam varias técnicas para conseguir

agregar mais maquinas virtuais por servidor, e neste aspecto sempre há um ponto a se

pagar pelo aumento de capacidade. Neste artigo vamos analisar algumas das principais

técnicas, e focar as vantagens, benefícios e desvantagens.

NINGUEM QUER DIMENSIONAR A MEMÓRIA

Em projetos de virtualização temos de ter o maior cuidado ao dimensionar corretamente a

quantidade de memória necessária, baseado na demanda das maquinas virtuais. Muitos

servidores possuem maquinas virtuais com demandas excessivas de memória em

determinados períodos, como por exemplo, fechamentos fiscais, indexação de bases, etc.

Isto significa que apenas em um determinado período será necessário redimensionar a

memória da maquina virtual de forma a atender a demanda, do contrário ocorrerá desde

paginação dentro da maquina virtual ou até mesmo falha de execução ou outros erros.

Na grande parte dos casos ao dimensionar a memória de uma maquina virtual a escolha é

baseada na utilização média de memória da mesma, porém muitos costumam configurar a

VM com X GB de memória e, se a mesma demandar mais, vão adicionando 1GB de RAM até

chegar ao ponto de estabilidade. Se a aplicação da maquina virtual não possui nenhuma

documentação técnica com dimensionamento de hardware então é muito difícil dimensionar

da forma correta.

Outro erro comum é o dimensionamento errado de acordo com o tipo de função a ser

executada pela maquina virtual. É de comum acordo que servidores de correio eletrônico ou

banco de dados consumam muita memória, porém o mesmo não é válido para outras

funções / serviços. Muitos profissionais de infraestrutura acreditam que servidores de

impressão (por exemplo) não precisam de muita memória, apenas disco(s) rápido(s).

Serviços de impressão de fato demandam discos rápidos devido ao serviço de Spool (alta

taxa de escrita e leitura para criar os Jobs de impressão), porém para melhor manipular os

Jobs é necessário memória, e neste ponto colocar pouca memória será impactante.

Outro papel importante são servidores de arquivo. Muitos também acreditam que para um

servidor de arquivos apenas uma boa controladora de disco e discos rápidos são mais do

que suficiente. O processo de cópia tem algumas particularidades interessantes, e isto ajuda

a compreender melhor as necessidades de outros itens de hardware. Uma das tecnologias

inseridas no Windows Server 2008 R2 é o RSS (Receive Side Scaling) que permite acelerar o

processo de cópia. Até as versões anteriores de sistema operacional de servidor todo o

processamento de cópia era feito no primeiro núcleo de processador (Proc 0), de forma que

o gargalo era alto, por mais que o servidor tivesse vários núcleos. Com o RSS o processo de

cópia é distribuído entre os núcleos, aumentando o desempenho para gerenciar a cópia. Isto

faz sentido, pois nas versões anteriores não eram comuns cenários com terabytes de dados

trafegados pela rede. Outro ponto importante é que, para acelerar o processo de cópia entre

máquinas pela rede é muito mais rápido copiar os dados primeiro para memória, para

depois gravar para o disco. Neste caso ao copiar uma grande quantidade de dados pela rede

o Windows fará primeiramente um processo de cópia para a memória (não dá para

comparar o tempo de acesso para a memória – nano segundos – em relação ao tempo e

acesso a disco – milissegundos). Em outras palavras, quanto maior a quantidade de

memória RAM, mais rápido é o processo de cópia, portanto servidores de arquivo com pouca

memória sofrem danos em desempenho.

AS TECNICAS

Muitos fabricantes implementam mais de uma técnica para gerenciar memória para as

maquinas virtuais. Todas possuem características de utilização específicas e não competem

entre si, pois cada uma tem características distintas.

 

Transparent Page Sharing (TPS)

Nesta técnica o hypervisor (ou virtualizador) faz uma varredura na memória alocada para as

maquinas virtuais atrás de trechos idênticos. Estes trechos são de 4K e, caso seja

encontrado em duas ou mais máquinas virtuais, então é mantido uma tabela de Hash para

controle dos endereços e apenas um dos trechos de 4K é mantido. Os demais trechos

possuem apenas um apontamento que é gerenciado pela tabela de Hash. Para gerenciar a

escrita nestes trechos de páginas compartilhadas é utilizada uma técnica de Copy-on-Write,

de forma que uma cópia é mantida para cada maquina virtual que realiza uma escrita.

Esta analise por trechos de 4K não é feita de forma dinâmica, pois o overhead de

processamento seria muito alto. Desta forma nos virtualizadores que implementam este

técnica possuem configurações de tempo de varredura (em minutos).

A forma como é feito o Scan é bem interessante do jeito que é feita. Vamos supor o cenário

de 3 maquinas virtuais em um servidor físico que implementa TPS. No caso de sistemas

operacionais Windows anteriores ao Windows Vista e Windows Server 2008 cada arquivo do

sistema operacional é carregado sempre no mesmo endereçamento de memória

(normalmente estes endereços são representados como 00000… etc). Neste cenário o TPS

começa a analisar estes endereços alocados de todas as maquinas virtuais, em blocos de

4K, e começa a compará-los entre si. Caso seja verificado que o Hash seja o mesmo então

apenas 1 das alocações é mantida na memória, e as demais são liberadas e gerenciadas

pela tabela de Hash.

Este técnica possui bastante efetividade quando são utilizadas maquinas virtuais com

mesmo sistema operacional, mesmos aplicativos e mesmos dados. O motivo é que a

probabilidade de encontrar estes trechos redundantes é muito maior do que se for

considerar o cenário com maquinas virtuais com sistemas operacionais distintos, diferentes

aplicativos e dados.

Nos novos servidores baseados em processadores com Intel EPT (Extended Page Table) e

AMD RVI (Rapid Virtualization Index) as alocações de páginas físicas do Host são feitas em

blocos de 2MB na memória, ao invés de 4K. Isto é um problema, pois a probabilidade de

encontrar páginas idênticas em blocos de 2MB é muito menor se comparado a páginas de

4KB. Isto significa que o TPS terá um overhead maior, pois ele precisará gerar hashes de 4K

mesmo nas páginas de 2MB.

BALLOONING

O termo Ballooning é uma técnica comum, pois a grande maioria dos virtualizadores

implementa este mecanismo. O Ballooning na grade parte dos casos é implementado

através de um driver de dispositivo. Este driver comunica-se com o virtualizador (ou

hypervisor) e informa quando está sob pressão (demandando memória) para obter mais

memória. Quando o driver de ballooning é “inflado” cabe ao sistema operacional da

maquina virtual decidir quais páginas serão desalocadas da memória ara satisfazer as

requisições do Ballooning.

MEMORY COMPRESSION

Esta técnica não é nova, pois há muito tempo atrás para o sistema operacional DOS já

existiam fabricantes que ofereciam softwares que “duplicavam” a memória RAM (ex: QEMM

da Quarterdeck ou Double-RAM). Neste cenário em particular as páginas que vão para swap

(paginação) podem ser comprimidas e armazenadas em um cache de compressão,

localizado na memória principal do Host ou servidor de virtualização. Quando uma página

que está em swap é acessada novamente então a pagina é descompactada e acessada.

Como está no Compression Cache do host (localizado na memória) então seu acesso é mais

rápido do que se estivesse armazenada em disco. Se as páginas não podem ser

comprimidas então a compressão vai falhar, e as paginas executam um SWAP. Importante

observar que o Compression Cache é finito em tamanho e utiliza uma política de reposição

baseada em idade/tempo.

HYPERVISOR SWAPPING

Esta técnica é a mais simples de todas, pois basicamente até agora o que vimos das

principais técnicas é que todas possuem em comum um único objetivo: obter mais espaço

na memória para alocar mais máquinas virtuais. Entretanto pode chegar um ponto no

servidor de virtualização em que todas as técnicas anteriores tenham feito o máximo

possível e não há mais memória RAM disponível, tanto para as maquinas virtuais quanto

para o host de virtualização. Neste cenário a memória extra solicitada pela maquina virtual

é redirecionada para paginação em disco. 

O cenário ideal de utilização do Hypervisor Swapping ocorre quando são utilizados discos

SSD (Solid State Drive) ou storages de alto desempenho. Entretanto dependendo da

quantidade de maquinas virtuais é necessário manter um RAID ou várias controladores de

disco, todos com discos SSD ou equivalentes. 

A técnica do Hypervisor Swapping é utilizada como ultima alternativa. Isto significa que se

todas as outras técnicas de memória já esgotaram seus recursos então será utilizado como

ultima alternativa o swapping:

TPS é baseado na taxa de Scan de páginas e oportunidades de compartilhamento de

memória (mesmo Sistema Operacional, mesma versão, mesma línguagem, etc)

Balloning depende do tempo de resposta do Sistema Operacional da maquina virtual

 

GERENCIAMENTO DE MEMÓRIA

Para ajudar a entender todas as implicações no gerenciamento de memória em ambientes

virtualizados é interessante ver como máquinas virtuais baseadas em Windows gerenciam a

memória. Quando analisamos, por exemplo, o Windows 7 / Windows Server 2008 R2

podemos verificar que a memória é dividida em 4 partes:

Em Uso

Páginas que estão em uso no momento

Modificado

Páginas de memória que ainda não foram utilizadas durante algum tempo, mas precisam

ser gravadas no disco antes que possam ser reutilizados.

Standby

Páginas que não estão sendo usadas e foram escritas para o disco. Elas podem ser

devolvidas a um processo se este precisar, mas também estão disponíveis para uso por

outro processo.

Free

Páginas de memória que não estão em uso, mas ainda não foram “zeradas”

 

DYNAMIC MEMORY

Quando analisamos as técnicas de memória fica claro que gerenciar memória para as

maquinas virtuais vai requerer processamento extra do hypervisor, o que significa que seu

uso tem cenários ou situações específicas.

O Dynamic Memory surgiu no Service Pack 1 do Windows Server 2008 R2 e exige que o

servidor de virtualização esteja com o SP1 instalado e que as maquinas virtuais estejam com

o Integration Components na versão 7601. O Dynamic Memory permite que a memória do

Host possa ser “vendida” para uma maquina virtual, porém será entregue apenas no limite

físico. A memória da VM é gerenciada de forma dinâmica, baseado na demanda:

Monitoração de “Committed Bytes” dentro da VM

Utiliza técnica de “hot add” para adicionar memória

Utiliza técnica de “memory ballooning” para remover a memória

Além disso, possui um Buffer configurável para as necessidades de memória de cache para

as máquinas virtuais, além de que cada uma delas possa ter priorização de memória.

Os pré-requisitos para utilizar o Dynamic Memory são:

Para os Hosts:

Windows Server 2008 R2 SP1

Microsoft Hyper-V Server 2008 R2 SP1

Para os Guests:

Windows Server 2003, 2008 & 2008 R2

Edições Enterprise e Datacenter somente

32-bit & 64-bit

Windows Vista e Windows 7

Edições Enterprise e Ultimate somente

32-bit & 64-bit

O motivo de não haver suporte para as edições Standard do Windows Server refere-se ao

fato de que o mesmo não suporta recursos de Hot-Add, essencial para o Dynamic Memory.

Já existem distribuições Linux suportando Dynamic Memory, portanto verifique se a Distro

que você pretende virtualizar já possui suporte.

COMO FUNCIONA

O processo de funcionamento do Dynamic Memory é muito parecido com o processo de

compra de passagens aéreas. Quando compramos uma passagem para um determinado

voo a companhia pode vender, por exemplo, 200 passagens. Entretanto a companhia sabe

que para este voo será utilizada uma aeronave que possui apenas 180 lugares, mas venderá

assim mesmo uma quantidade maior do que realmente possui fisicamente (nós conhecemos

este processo como Over Booking). Por mais que os 200 ingressos sejam vendidos apenas

180 pessoas poderão voar. Em nenhum momento 200 pessoas vão voar acomodados em

corredores, dividindo assentos, etc.

Este exemplo ilustra bem o funcionamento do mecanismo do Dynamic Memory. Um servidor

possui uma quantidade X de memória, porém informará para as maquinas virtuais que

utilizam Dynamic Memory de que elas podem ter mais memória se precisarem. Entretanto

se o limite físico de memória do Host for atingido não haverá compressão de memória ou

page sharing: um bloco de memória é ocupado APENAS por uma maquina virtual.

Quando configuramos o Dynamic Memory (parâmetro é individual, por maquina virtual)

definimos a memória inicial, máximo de memória e percentual de buffer. A memória inicial é

o startup de memória que a maquina virtual utiliza até que todo o Kernel da mesma esteja

inicializado. Após a inicialização completa de todo o Kernel daí sim a maquina virtual pode

incrementar de memória RAM baseado na demanda, da seguinte forma: Vamos imaginar

uma maquina virtual com 1GB de RAM de memória inicial, e configuramos o máximo para

8GB de RAM e o Buffer configurado em 20%.

Neste exemplo quando a maquina virtual for ligada e até o termino do carregamento do

Kernel ela irá ocupar 1024MB de memória. Ao abrir o Task Manager da maquina virtual

verificamos que ela ocupou (por exemplo) 512MB de RAM. Caso a maquina virtual sofra uma

pressão de um aplicativo X demandando mais memória então o Hypervisor receberá esta

informação através do Dynamic Memory VSP (Virtual Service Parent), e irá fazer o

incremento de memória para a máquina virtual em 20%, baseado na utilização atual de

memória (neste exemplo a memória atual é 1024MB e recebendo um incremento de 20%

passará a 1228MB). Se a aplicação ainda continuar a demandar mais memória então

novamente o host vai adicionar mais 20% de memória extra para a máquina virtual (como o

cálculo é feito baseado na utilização atual – 1228MB – então agora ela passará a ter

1473MB). Estes incrementos de memória RAM na maquina virtual vão ocorrer até atingir o

limite máximo definido para a maquina virtual (no caso seriam 8192MB).

Mas o que acontece se o Task Manager estiver aberto justamente na hora que a maquina

virtual sofrer incremento de memória pelo Dynamic Memory? Simplesmente nada, o Task

Manager e nas propriedades do sistema refletem automaticamente a quantidade atual de

memória alocada.

 

ADICIONANDO MEMÓRIA: O LADO BOM

Nas técnicas convencionais para adicionar a memória para as maquinas virtuais verificamos

que não há impactos para as mesmas: o sistema automaticamente reflete a adição de

memória sem a necessidade de reiniciar ou desligar a maquina virtual. Entretanto existem

aplicações que, ao serem executadas, verificam a memória RAM atual para prosseguir com

a instalação. Neste caso é importante que a aplicação vá detectar apenas a memória atual

da máquina, e mesmo o sistema operacional da maquina virtual também enxerga apenas a

memória atual (e não a memória máxima que a maquina virtual pode atingir).

Outro aspecto importante refere-se ao fato de que nem todos os cenários deve-se utilizar o

Dynamic Memory. Aplicações que tenham muita oscilação de memória e/ou uso intensivo da

mesma preferencialmente devem ter a memória fixa. O motivo é que oscilações de alocação

dinâmica de memória causam penalidades de processamento devido a este gerenciamento,

podendo tornar em muitos casos lento a maquina virtual.

Quando ocorre a demanda de memória aumenta então o VSC (Virtualization Service Client,

localizado dentro da maquina virtual) requisita memória adicional via VSP (Virtualization

Service Parent, localizado no servidor de virtualização). Desta forma o VSC apresenta

memória adicionada para o gerenciador de memória da máquina virtual, habilitando

automaticamente o novo incremento de memória. O Dynamic Memory não utiliza a técnica

tradicional de HotAdd, porém utiliza no lugar o “HotAdd Enlightenments”, existente apenas

nas versões suportadas pelo Dynamic Memory.

 

REMOVENDO MEMÓRIA: O LADO ESCURO

Remover a memória da maquina virtual não é um processo simples. No caso do Dynamic

Mempory é utilizado uma técnica de Ballooning para “inflar” o driver do espaço de

endereçamento virtual não-paginado. Desta forma o Sistema Operacional da maquina

virtual ainda acredita que a memória esteja lá, porém o espaço de endereçamento é

designado para o Kernel driver. A memória virtual então é liberada e/ou despaginada, e

colocada em uma lista livre (free/zero). Por fim o VSC chama a função do Gerenciador de

Memória para alocar a memória fora da lista livre (free/zero).

Para gerenciar tanto a adição de memória quanto a remoção é importante entender como

funciona a política de funcionamento das mesmas:

Política de adição de memória ativa

Memória é adicionada imediatamente quando a VM necessitar

Política de reclamação (remoção) de memória passiva

Memória não é removida quando não há necessidade imediata de memória

Memória inutilizada é coletada a cada 5 minutos

Isto significa que, para remover a memória da maquina virtual, o hypervisor não pode

simplesmente “tomar” a memória da maquina virtual. O hypervisor não tem como saber se

a maquina virtual de fato está usando ou não a memória, pois caso pudesse “ler” o que esta

na memoria da maquina virtual seria uma falha de segurança (uma invasão no servidor de

virtualização permitira “ler” os dados na memoria da maquina virtual e então obter ou fazer

qualquer ataque para a mesma). Desta forma no caso do Hyper-V a cada 5 minutos ele faz

uma varredura em todas as maquinas virtuais verificando se as mesmas liberaram a

memória.

Existem outros fatores que tornam mais difícil a remoção da memoria adicionada nas

maquinas virtuais. O Windows possui um mecanismo chamado de Super-Fetching, que

possui como função primária acelerar o tempo de acesso para as aplicações mais

acessadas. Quando o sistema operacional é inicializado são carregados na memória os

aplicativos mais acessados e estes ficam já alocados na memória. Desta forma se você

possui uma maquina virtual com vários serviços e aplicativos acessados então o sistema

operacional tentará mantê-los carregados previamente na memória para acelerar o tempo

de resposta. Isto torna mais difícil para qualquer virtualizador remover a memória

previamente alocada.

 

POR QUE A MICROSOFT NÃO IMPLEMENTA MEMORY COMPRESSION

Compressão de memória requer processamento extra, assim como todas as técnicas

listadas anteriormente. Comprimir dados da memória implica em aumentar a carga de

processamento, além de não possuir eficiência para todas as situações.

 

POR QUE A MICROSOFT NÃO IMPLEMENTA TRANSPARENT PAGE SHARING

O Transparent Page Sharing funciona bem com páginas de 4K, porém eficiência é muito

baixa com Large Memory Pages (2MB). O motivo é que na técnica de TPS é muito mais fácil

encontrar blocos de 4KB co hashes idênticos do que encontrar blocos de 2M com hashes

idênticos. Páginas de 4K não conseguem usar com eficiência o Translation Lookaside Buffer

(TLB) com Large Memory Pages. Além disso, em servidores com SLAT, usar paginas de 4K ao

invés de Large Memory Pages reduz a performance de servidores em ~20%, pois você está

na prática forçando o processador SLAT a trabalhar em um modo ao qual não foi otimizado.

Por padrão sistemas operacionais que trabalham com Large Memory Pages (como Windows

Vista e Windows Server 2008 em diante) não tem eficiência com sistemas que utilizam TPS.

Outro mecanismo que reduz a eficiência do TPS é o SuperFetch. Por característica o

SuperFetch popula trechos de memória com aplicações que sejam frequentemente

carregadas, melhorando tempo de resposta. Entretanto este carregamento prévio Reduz

quantidade de “Zero Pages” reduzindo eficiência do Page Sharing. Este mecanismo existe

desde o Windows XP e também em sistemas open-source (conhecido como Preload no

Linux).

Por fim o ultimo mecanismo que invalida o TPS é um recurso de segurança implantado a

partir do Windows Vista, chamado de Address Space Layout Randomization (ASLR). Este

mecanismo faz com que DLL`s de sistema e executáveis sejam carregados em áreas

diferentes da memória toda vez que o Sistema Operacional seja inicializado. O propósito do

ASLR é bem interessante, pois muitos malwares atacam determinados endereços

específicos da memória, e com o ASLR ao menos arquivos críticos do sistema operacional

nunca estarão sempre nos mesmos endereços de memória. Quando o TPS é executado ele

começa a inspecionar os blocos de 4K nos mesmos endereços de cada máquina virtual. Se

por exemplo em um endereço 0000000fff de uma maquina virtual existe um arquivo X

carregado na memória e em outra máquina virtual o mesmo endereço 0000000fff possui

outro arquivo carregado (por causa do ASLR) então não há como os hashes tornarem-se

idênticos, o que invalida o TPS neste bloco específico. Partindo deste princípio se o servidor

de virtualização tiver várias maquinas virtuais com mesmo sistema operacional e mesma

versão/língua então há possibilidades do TPS funcionar e ter eficiência. Entretanto em

servidores com sistemas operacionais diversos não haverá eficiência de uso.

POR QUE A MICROSOFT NÃO IMPLEMENTA SECOND LEVEL PAGING (HYPERVISOR SWAP)

Se o Hypervisor não conseguir identificar quais páginas da maquina virtual devem ir para

swap pode ocorrer interações desnecessárias com as políticas de gerenciamento da

memória nativa na maquina virtual (Ex: O sistema operacional da VM nunca vai fazer

paginação das paginas do Kernel. O Hypervisor não consegue identificar quais são as

paginas do Kernel e vai fazer swap).

Além disso, existe a possibilidade da dupla-paginação. Imagine por exemplo uma maquina

virtual com toda a memória disponível já esgotada (em uso) e por coincidência o servidor de

virtualização já não possui mais memória disponível para as maquinas virtuais, fazendo

outro swap.

Para tornar eficiente o uso do Hypervisor Swap é necessário o uso de discos SSD (Solid-State

Drives) para conseguir chegar a um tempo de resposta próximo ao da memória RAM.

Entretanto pode ser necessário mais de um disco ou até mesmo um array de SSD para

conseguir ter uma taxa sustentável. Não há como comparar o tempo de acesso do disco

com o tempo de acesso a memória.

 

O QUE É RECOMENDADO

O melhor cenário, e todos os fornecedores de virtualização concordam com isso, é

preferencialmente manter a memória das maquinas virtuais como fixa, principalmente para

servidores que tem uso intensivo de memória. Para demais maquinas virtuais que tem

demanda de memória apenas em determinados períodos então recursos de alocação

dinâmica de memória podem ser interessantes.