Memoria Hyper-V - Virtualização de Máquinas
-
Upload
luiz-antonio -
Category
Documents
-
view
45 -
download
1
description
Transcript of Memoria Hyper-V - Virtualização de Máquinas
Memória: O ponto mais crítico para virtualização
by [email protected] 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.