Windows Server 2008 R2 SP1 e Dynamic Memory

Cito abaixo o excelênte texto do Nelson Sakai, explicando com detalhes e comparações com a concorrência sobre o recurso de memória dinâmica que é o grande esperado do SP1 do Windows 2008 R2.

=================================

Que atire a primeira pedra quem nunca esteve tranquilamente sentado no aeroporto, esperando seu avião, quando surge aquela voz metálica dizendo: – “Senhores passageiros do voo xx123, estamos oferecendo um voucher no valor de US$ 1000,00, mais alimentação e estadia, para quem se dispuser a desistir de embarcar, para viajar amanhã, no voo das 9 horas…”.
Pior, quem nunca perdeu o voo, planejado com décadas de antecedência, simplesmente porque não havia lugar no avião?
Chato, não?
E por que acontece este tipo de coisa? Fácil, a empresa aérea vende mais passagens do que o número de assentos no avião, apostando que algumas pessoas irão desistir de voar.

Memory Overcommitment
Bem, como funciona o famoso “Memory Overcommitment” de nosso concorrente, no âmbito da virtualização? Exatamente igual!!
Ou seja, é prometida mais memória para as máquinas virtuais do que a somatória de memória real da da máquina física. As máquinas virtuais podem alocar mais memória do que a máquina física é capaz de entregar.
E os mesmos caras que xingaram até a oitava geração da atendente da companhia aérea, quando perderam o voo por “overcommitment” de avião, acham esta feature “cool”. Que mundo estranho, não?
Bem, deixando a ironia um pouco de lado, e também os detalhes mais técnicos, o que realmente acontece quando “todos os passageiros tentam embarcar ao mesmo tempo”, ou seja, quando as máquinas virtuais requerem mais memória do que a máquina física (ou o hypervisor, como queira) é capaz de entregar, é que devem existir mecanismos que controlem “quais passageiros vão deixar de embarcar”.
Primeiramente, o hypervisor usa mecanismos para para tentar evitar que o transbordamento de memória ocorra: page sharing e balooning.

Page Sharing e Ballooning
Page sharing, é a eliminação de páginas de memória com o conteúdo duplicado, através do compartilhamento da mesma página, ou seja, páginas com conteúdo idêntico possuem somente somente uma imagem única na memória. Se o conteúdo é o mesmo, por que não compartilhá-lo? Seria excelente, excepcional mesmo, eu diria, se não fosse um pequeno detalhe: a identificação das páginas duplicadas é um processo custoso, trabalhoso e pode levar um tempo enorme. Além disso, page sharing não é um processo lá muito dinâmico, o que torna o processo bastante questionável, do ponto de vista de eficiência.
Já o ballooning (sei lá como traduzir isto para o português), é o processo através do qual o hypervisor retoma memória de uma máquina virtual. É como se houvesse uma sala (máquina virtual) com um balão gigante dentro dela. Se alguém inflar o balão, obviamente vai sobrar menos espaço (memória) dentro da sala. É mais ou menos esta a analogia. Esta memória, resgatada pelo hypervisor, pode ser  alocada em uma outra máquina virtual que precise (tirar o ar de um balão para encher um outro). É importante notar que, do ponto de vista de nosso concorrente, este mecanismo é implementado pela instalação de uma espécie de driver específico no sistema operacional da máquina hospedada.
Estes mecanismos, dentro da analogia do avião, são similares ao voucher que a companhia aérea oferece para você desistir do vôo.
Bem, dado que ninguém desistiu de voar, ou seja, no momento em que o page sharing e o ballooning não forem mais eficientes, vai ter mais gente do que assento no avião.

Second Level Paging
Só nos resta botar os passageiros para voar em  pé. Neste caso, será acionado o processo conhecido como “Second Level Paging”. Ou seja, o hypervisor inicia o processo de paginação, migra páginas da memória física para disco, mecanismo clássico, desde o tempo dos mainframes.
Alguns problemas aqui. Primeiro, a já conhecida diferença de velocidade de I/O entre memória física e disco. Paginação sempre gera algum grau de degradação de performance.
Segundo, e mais grave,  o termo “segundo nível” está lá porque já existe uma paginação de primeiro nível, a realizada pelo próprio sistema operacional hospedado. Corre-se o risco de dupla paginação (não confundir com outra coisa). O hypervisor pagina um segmento de memória, e o sistema operacional resolve paginar o mesmo segmento, com as consequências já imagináveis sobre o tempo de resposta.
Terceiro, mais grave ainda, o hypervisor não é o sistema operacional hospedado, e consequentemente, não tem a informação exata de quais páginas de memória são essenciais, dentro do mesmo. Ao iniciar o processo de paginação, digamos, aleatória, corre-se o risco de se fazer swap, por exemplo, de segmentos do kernel do sistema hospedado. É como se, retomando o exemplo do avião, colocássemos os cadeirantes para viajar em pé.
Resumindo, Memory Overcommitment NÃO é uma idéia recomendável para grandes ambientes de produção de missão crítica. O próprio concorrente cita isto em sua documentação.

Dynamic Memory
Diriam alguns, melhor isto do que nada. É pior não ter um mecanismo que consiga flexibilizar a utilização de memória pelas máquinas virtuais, de forma a se fazer melhor uso da memória física. Bem, têm razão.
O Hyper-v, da Microsoft não possuia este tipo de mecanismo, o que obrigava a se dimensionar a memória atribuida às máquinas virtuais pelo pico, ou então gerava-se problema de performance na mesma. Pode-se ter, no mesmo servidor físico, máquinas virtuais com memória sobrando e outras fazendo swap de memória loucamente, por falta de memória física.
Tudo isto se traduz numa baixa eficiência de uso de um recurso caro, memória e, consequentemente, numa baixa taxa de consolidação de servidores, que no final das contas, é o objetivo da virtualização.
Mas não seria melhor um mecanismo que, ao mesmo tempo em que permitisse a flexibilização do uso de memória, não permitisse o overcommitment do recurso físico, com as consequências descritas acima?
Foi exatamente nisso que a Microsoft pensou, quando arquitetou o recurso de Dynamic Memory, presente no SP1 do Windows Server 2008 R2.
O Hyper-v permite que memória com baixa utilização pelas máquinas virtuais seja desalocada, através do recurso de ballooning, já descrito anteriormente, mas não permite que mais memória física seja distribuída às máquinas virtuais do que o total de memória existente no servidor, evitando a chamada dupla paginação.
A alocação/desalocação de memória, utiliza recursos do próprio sistema operacional dos guests hospedados, portanto, estes devem possuir suporte para este recurso. Atualmente, Windows Server 2003, 2008, 2008 R2, Windows Vista e Windows 7.

Mínimo, máximo, priorização
Como o mecanismo foi implementado? Foram introduzidos 3 novos parâmetros na definição da máquina virtual. O primeiro é a memória alocada no startup da mesma (default, 500MB); o segundo, é a quantidade máxima alocada (default 64GB); e o terceiro, é a prioridade da máquina virtual, ou seja, em caso de falta de memória, que máquina virtual será priorizada. Esta prioridade varia de 0 a 10000, sendo o default 5000.
Ah, além disso, existe um quarto parâmetro, que é a quantidade de memória que o Hyper-v tentará reservar, para fins de “bufferização”.

É importante dizer que, em nenhum caso, o Hyper-v irá liberar mais memória do que a quantidade de memória física do servidor.

Conclusão
Desta forma, estamos unindo o melhor dos dois mundos: alocação flexível de memória, mas sem os problemas causados pelo overcommitment e, ainda, gerando um mínimo overhead no hypervisor.
Assim, podemos ter uma maior nível de consolidação de servidores, sem riscos de problemas de performance, num ambiente adequado e recomendado para workloads de produção críticos.
E nada de ficar sofrendo no aeroporto de novo…
Nelson I. Sakai
Technology Solution Professional – Datacenter

=======================================

Segue também o video com a demonstrãção feita para o EDGE Technet por Vijay Tewari.