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.
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.
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.
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.
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.
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.
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:
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:
Páginas que estão em uso no momento
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.
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.
Páginas de memória que não estão em uso, mas ainda não foram “zeradas”
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:
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:
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.
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.
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.
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:
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.
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.
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.
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 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.
Um dos primeiros MVPs (Most Valuable Professional) de infraestrutura do Brasil, além de MCTS, MCITP, MCSA, MCSE, MCITP e MCT, com mais de 14 anos de experiência no mercado de infraestrutura de redes Microsoft. Atuou em muitos cases da Microsoft e hoje ocupa a posição de Especialista em Infraestrutura e Virtualização no time de Comunidades Técnicas da Microsoft Brasil. Sua missão é contribuir com os profissionais e comunidades de IT Pros a explorar as funcionalidades e recursos da plataforma Microsoft. Bom, este é o mini-cv formal do Fabio Hara. O mini-cv “informal” do Hara-san (como é mais conhecido) seria: Hara-san costuma jogar partidas lendárias de Gears of War, Call of Duty MW2, Halo:Reach, etc, nas horas de folga com seus amigos. Além disso curte bastante jogar tênis (apesar de jogar mal) e escutar um bom rock anos 80/90. Grande apreciador do Home-brewing, graças aos conhecimentos que foram aprendidos com o Dalai Lama dos Portais Colaborativos Sagrados(Roberval Ranches – mesa). Tambem gosta de treinar Aikidô, e sempre que possível costuma treinar regularmente. Certa vez me perguntaram: “Hara, o que você faz na Microsoft?”. Na epoca eu disse que divulgava novas tecnologias, produtos, etc. Hoje eu posso dizer que não é bem isso. Minha resposta hoje é: “Eu ajudo você com informações e conteúdos que te ajudem a ganhar dinheiro, ser reconhecido e voltar mais cedo para casa para ficar com a sua familia” Site: http://www.fabiohara.com.br/ Twitter: http://Twitter.com/fabiohara Bom, o Hara tambem fez uns videos bacanas no Youtube. Segue alguns deles: Fabio Hara usando Surface – parte 1 Fabio Hara usando o Surface – parte 2 Fabio Hara usando o Surface – parte 3 Fabio Hara usando o Surface – parte 4 final Container do Azure – via Fabio Hara / parte 1 Container do Azure – via Fabio Hara / parte 2
You must be logged in to post a comment.
1:07:26 pm
Fábio Hara,
Parabéns pelo excelente artigo!!
A memória sempre será o calcanhar de aquiles dos hipervisors.
Quais livros vc indica com detalhes dessas tecnologias acima?
Obrigado!