terça-feira, 7 de dezembro de 2010
Aumentando a performance das VM’s
sábado, 30 de outubro de 2010
Estrutura de Logs no ESXi
“Because the in-memory file system does not persist when the power is shut down, log files do not survive a reboot. ESXi has the ability to configure a remote syslog server, enabling you to save all log information on an external system.“
Pesquisando sobre o assunto, encontrei dois posts interessantes no blog do Simon Long, um deles explicando a estrutura de logs do ESXi, mostrando a diferença que existe para os logs do ESX e explicando pra que cada um dos logs pode ser utilizado.
No outro post, é mostrado uma forma de configurar um vMA (vSphere Management Assistant) como um servidor de syslog para os hosts ESXi, importante para armazenar os logs por mais tempo.
Vale à pena dar uma conferida nos dois:
http://www.simonlong.co.uk/blog/2010/06/03/vmware-esxi-4-log-files/
http://www.simonlong.co.uk/blog/2010/05/28/using-vma-as-your-esxi-syslog-server/
terça-feira, 5 de outubro de 2010
Como funciona o gerenciamento de memória no ESX? – Parte 2
Um ambiente virtual é composto de diversas máquinas virtuais, umas trabalhando a todo vapor, consumindo todos os recursos que lhe foram oferecidos e outras nem tanto. E é aí que as técnicas de recuperação de memória entram, para recuperar memória física do host que está alocada para uma VM, mas que não está sendo usada, e disponibilizá-la para que outra máquina virtual possa usá-la.
As seguintes técnicas de recuperação de memória estão presentes no ESX:
1. TPS – Transparent Page Sharing
2. Ballooning
3. Memory Compression (disponível a partir do lançamento da versão 4.1)
4. Swapping
Vamos às explicações sobre como cada uma delas funciona.
Transparente Page Sharing (TPS)
Primeiramente vamos à tradução do nome, que é Compartilhamento Transparente de Páginas, com isso já temos uma idéia do que pode ser essa técnica, não é mesmo?
Bem, quando temos várias máquinas virtuais rodando num mesmo host, é bem provável que muitas delas possuam algumas coisas em comum, como por exemplo, o mesmo sistema operacional. Com a utilização da técnica do TPS, é possível que as máquinas virtuais que possuem páginas de memória idênticas compartilhem essas páginas, permitindo que o ESX armazene apenas uma cópia desta página em sua memória física.
Mas como o ESX identifica que uma VM possui uma página de memória idêntica à de outra VM? Através do seu conteúdo. De tempos em tempos, o ESX varre o conteúdo de toda a memória física de uma máquina virtual (Guest Physical Memory) em busca de páginas que possam ser compartilhadas. Para cada página que é vasculhada pelo ESX, um valor de ‘hash’ é gerado, em seguida este valor é comparado com valores existentes em uma tabela com o ‘hash’ de várias páginas que estão compartilhadas e suas respectivas localizações na memória física do host.
Caso o ESX encontre alguma entrada na tabela que se assemelhe ao valor de ‘hash’ da página de memória da VM, então uma comparação mais detalhada é feita entra as duas páginas para confirmar que as duas são mesmo idênticas. Depois de confirmado que as páginas são idênticas, o mapeamento que existe para aquela página de memória da memória física da máquina virtual (Guest Physical Memory) para a memória física do host (Machine Physical Memory) é alterado e passa a apontar para página de memória que já está compartilhada na memória física do host (a página toda vermelha na imagem acima). A outra página (a listrada de vermelho na imagem acima) é então recuperada e fica disponível para que outra máquina virtual possa utilizá-la.
Mas... se duas ou mais VM’s compartilham a mesma página de memória, quando uma delas fizer alguma alteração nesta página, isso não irá afetar às demais?? Não! Estas páginas compartilhadas são somente leitura (Read-Only), portanto quando uma das máquinas virtuais tenta alterar o conteúdo desta pagina, acontece um ‘Page Fault’ e o ESX faz uma cópia daquela página em uma outra página da sua memória física, permitindo que aquela VM altere o conteúdo da página sem interferir nas demais máquinas virtuais que acessam àquela página compartilhada.
É importante lembrar que a técnica de TPS está sempre ativa, independente se o host possui memória livre suficiente ou não.
É possível ver informações sobre o funcionamento do TPS através da ferramenta ‘esxtop’ na console do ESX. Veja a imagem abaixo:
O contador a ser observado é o “PSHARE”. O valor ‘shared’ é a quantidade total de memória física das máquinas virtuais que está sendo compartilhada. O valor ‘common’ é a quantidade de memória física do host sendo utilizada para compartilhar a memória física das VM’s. O ‘saving’ é a quantidade de memória que está sendo economizada no host através da utilização do TPS.
Ballooning
O ‘ballooning’ é uma técnica de recuperação de memória completamente diferente da técnica de TPS. A começar pela sua utilização, diferentemente da técnica de TPS que já está ativa por padão, a técnica de ballooning só entra em cena quando o host encontra-se realmente com pouca memória livre disponível ou se a VM possui o parâmetro de configuração ‘Limit’ setado.
A técnica consiste em um driver de balloon (vmmemctl) que é carregado no sistema operacional da máquina virtual através do VMTools. Quando um host precisa recuperar alguma memória da máquina virtual ele informa para o driver de balloon a quantidade de memória que ele precisa, em seguida o driver de balloon começa a inflar dentro do sistema operacional, fazendo que o mesmo utilize suas próprias técnicas de gerenciamento de memória para oferecer a memória necessária ao driver de balloon. Ou seja, caso haja memória livre suficiente dentro dá máquina virtual, serão oferecidas ao driver de balloon as páginas de memória contidas na lista de páginas livre da VM, caso a VM não possua aquela quantidade de memória suficiente, a VM irá fazer paginação das páginas de memória menos utilizadas para liberar memória para o driver de balloon.
Depois de inflado, o driver de balloon avisa ao hypervisor quais foram as páginas de memória física da VM que foram alocadas, então o host ESX encontra a página de memória correspondente na memória física do host e em seguida recupera aquela página para ser utilizada por outra VM.
Como já foi dito anteriormente o driver de ballon é instalado juntamente com o VMTools, portanto para que o mesmo funcione corretamente é necessário que o VMTools esteja instalado na máquina virtual. Além disso, é necessário que dentro do S.O da máquina virtual exista espaço suficiente para a paginação de memória.
Memory Compression
A técnica de Memory Compression é bastante simples. Introduzida a partir do lançamento da versão 4.1 do VSphere, a técnica de Memory Compression entra em cena quando o host está sob pressão e mesmo com a ajuda das técnicas de TPS e Ballooning, não foi possível recuperar memória suficiente, então, ao invés de fazer swap para disco das páginas físicas que serão recuperadas de uma VM, o ESX irá comprimir estas páginas e armazena-las em um cache de compreensão.
Para que uma página comprimida seja armazenada no cache, é necessário que a taxa de compreensão tenha sido de no mínimo 50%, ou seja, uma página de 4KB quando comprimida, será armazenada no cache ocupando um espaço de 2KB.
É importante observar que apenas as páginas selecionadas para o ‘swap’ podem ser comprimidas, ou seja, o ESX não age pró-ativamente, comprimindo as páginas de memória de uma VM, isso só ocorre quando o host necessita fazer swap.
Suponhamos que um host ESX necessite recuperar duas páginas de memória, com 4KB cada, de uma determinada máquina virtual. Foram selecionadas as páginas A e B (figura a). Se existisse apenas a técnica de swap, essas duas páginas seriam transferidas diretamente para o disco e o host recuperaria aquela quantidade de memória (figura b). Com a técnica de Memory Compression, cada uma das paginas selecionadas para o swap, seria comprimida e armazenado no cache de compreensão daquela VM, ocupando um espaço de 2KB, metade do seu tamanho original (figura c). Veja que a compreensão de memória é muito mais rápida do que a operação de swap, já que não necessita executar I/O em disco.
Quando uma dessas páginas comprimidas for acessada pela VM, ela será então descomprimida e devolvida à memória física da máquina virtual. Em seguida a página é removida do cache de compreensão.
Cada máquina virtual possui o seu próprio cache de compreensão, ou seja, nenhuma memória adicional do host é necessária durante a utilização do Memory Compression. Por padrão este cache pode ocupar até 10% da memória física da VM. Este valor pode ser alterado nas configurações avançadas no Vsphere Client através do parâmetro Mem.MemZipMaxPct.
Swapping
Quando nenhuma das técnicas de recuperação de memória é suficiente, o ESX utiliza como um último recurso para recuperar memória a técnica de ‘swap’.
Durante a inicialização de uma máquina virtual é criado um arquivo ‘.vswp’ no disco, que é utilizado durante o processo de swapping. Quando o host sente a necessidade de fazer o swapping, ele transfere páginas da memória física da VM para este arquivo, liberando essas páginas na memória física do host para serem utilizadas por outras máquinas virtuais.
Como este processo é feito sem nenhum envolvimento do S.O da máquina virtual, pode ocorrer de páginas que estão ativas serem transferidas para o arquivo de swap.
Devido às necessidades de acesso a disco que esta técnica implica, a performance de uma VM que está fazendo swap é drasticamente afetadda.
Fontes:
http://www.van-lieshout.com/2009/05/esx-memory-management-%E2%80%93-part-3/
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf
http://www.vmware.com/files/pdf/perf-vsphere-memory_management.pdf
sábado, 7 de agosto de 2010
Como funciona o gerenciamento de memória no ESX? – Parte 1
Host Physical Memory: é a memória física instalada no host ESX e gerenciada pelo kernel do ESX.
Guest Physical Memory: é a memória alocada para a VM. O sistema operacional da VM enxerga essa memória como sendo sua memória física (afinal de contas, ele não sabe que está rodando numa máquina virtual). Essa memória é gerenciada pelo sistema operacional da VM.
Guest Virtual Memory: é a memória vista pelas aplicações que rodam no S.O da VM.
O que é a memória virtual?
A memória virtual é uma técnica presente na maioria dos sistemas operacionais e suportada por quase todos os processadores existentes hoje em dia. O que ela faz é criar um espaço contínuo de endereços virtuais, fazendo que uma aplicação acredite que todo aquele espaço pertence a ela. A tradução de endereços entre o espaço de endereçamento virtual e o espaço de endereçamento físico é feita pelo sistema operacional e pelo hardware. Esta técnica não só simplifica o trabalho do programador, mas também se adapta ao ambiente de execução para suportar grandes espaços de endereço, protege os endereços utilizados por um determinado processo e permite o uso de arquivos de mapeamento e swap.
Mas como é feito o gerenciamento da memória virtual?
Bem, antes de qualquer coisa, para que seja possível trabalhar com memória virtual, é necessário que o hardware utilizado ofereça o que chamamos de ‘Unidade de Gerenciamento de Memória (MMU - Memory Management Unit). Normalmente a MMU está integrada ao processador e sua principal função é manter uma tabela que relaciona os endereços da memória virtual aos endereços da memória física. Essa tabela é conhecida como Translation Lookaside Buffer (TLB). Às vezes acontece de uma página de memória virtual não poder ser acessada porque não havia uma entrada correspondente na TLB, este tipo de situação causa o que chamamos de Page Fault.
Portanto, no caso de uma máquina virtual, além de virtualizar a memória, o VMM (Virtual Machine Monitor) também deve virtualizar a MMU, de forma que o S.O da VM também possa trabalhar com memória virtual.
Agora vamos entender como a memória é alocada para a VM.
Em ambientes que não são virtuais o sistema operacional é que assume toda a memória física da máquina. Dessa forma, sempre que uma aplicação necessita de memória para armazenar algum dado ela faz uma chamada ao sistema operacional. Este por sua vez conhece todas as páginas de memória que estão sendo usadas e todas as páginas que estão livres. É como se existissem duas listas, a lista de páginas livres e a lista de páginas usadas. Então quando uma aplicação faz uma chamada, o sistema operacional verifica a lista das páginas livres e disponibiliza uma página para a aplicação e em seguida move a página alocada para a lista de páginas usadas.
Como uma máquina virtual possui um sistema operacional e diversas aplicações, é necessário combinar as características de gerenciamento de memória do sistema operacional e também do gerenciamento da memória virtual utilizada pelas aplicações.
No ESX, a alocação de memória acontece sob demanda, ou seja, quando uma VM acessa à sua memória física (Guest Physical Memory) pela primeira vez, o hypervisor disponibiliza uma página de memória do host (Host Physical Memory) para aquela VM. Para cada máquina virtual o hypervisor mantém registrado em uma tabela qual página de memória está em uso e qual a sua localidade na memória física do host. Conforme mostrado na imagem abaixo:
Esta tabela é mantida pelo hypervisor internamente numa estrutura de dados chamada de PMAP (Physical Machine Mapping). Mas além desta tabela, o ESX também mantém um mapeamento das páginas de memória virtual (Guest Virtual Memory) para as páginas de memória física do host (Host Physical Memory). Este mapeamento é feito através de interceptações realizadas pelo hypervisor aos acessos que são feitos ao TLB da VM e pode ser realizado de duas formas, via Software ou via Hardware, isso vai depender do processador que está sendo utilizado no host e também do modo de execução escolhido pelo VMM, mas isso são assuntos para outros posts!
Agora já sabemos como ocorre a alocação de memória, mas e quando uma aplicação não precisa mais daquela página de memória, o que acontece? Bem, neste caso a aplicação fará uma nova chamada ao sistema operacional que em seguida moverá a página de memória em questão da sua lista de páginas usadas de volta para a lista de páginas livres, porém, como o S.O não tem o conhecimento de que ele está em uma máquina virtual, não ocorre nenhuma interação com o hypervisor, que por sua vez continua com aquela página de memória alocada para aquela VM.
Nesse ponto você pode estar se perguntando, mas como o ESX sabe a hora que ele precisa alocar uma página, mas não sabe a hora de liberar? Quando uma máquina virtual acessa pela primeira vez a memória física do host (Host Physical Memory) isso causa um “Page Fault”, que pode ser facilmente capturado pelo hypervisor. Já no caso da liberação da memória, fica difícil paro o hypervisor monitorar quando uma página foi liberada porque geralmente a lista de páginas livres no sistema operacional não é publicamente acessível.
Baseado nisso, foram criadas técnicas de recuperação de memória (Memory Reclamation) no ESX para melhor utilização da memória física instalada no host. Na parte 2 desse post pretendo explicar cada uma dessas técnicas detalhadamente.
Fontes:
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf
http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf
http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf
http://www.van-lieshout.com/2009/04/esx-memory-management-part-1/
http://en.wikipedia.org/wiki/Memory_management_unit
terça-feira, 27 de julho de 2010
Novidades no lançamento do VSphere 4.1
Recentemente (há cerca de duas semanas), a VMware oficializou o lançamento do VSphere 4.1, um ano após o lançamento do Vsphere 4.0. O VSphere 4.1 apresenta uma imensa quantidade de novidades e melhorias, o que justifica o fato de ter sido lançado como uma nova versão ao invés de um ‘Update’.
Entre as novidades que foram anunciadas, uma que deve “pegar” alguns desavisados de surpresa, foi a confirmação de que este será o último ‘release’ do ESX, a partir do próximo lançamento do VSphere teremos apenas o ESXi, portanto se você ainda não migrou o seu ambiente, essa é uma boa hora!
Segue uma lista de algumas das novidades/alterações que podem ser conferidas no VSphere 4.1:
- O número de migrações concorrentes via vMotion subiu para 4 num link de 1 Gbps e para 8 num link de 10Gbps.
- A velocidade do processo de migração via vMotion aumentou consideravelmente, tornando o processo de evacuação de um host muito mais rápido.
- Integração do ESX/ESXi com o Active Directory.
- Novas regras no DRS que permitem definir afinidade entre uma VM e um ou mais hosts.
- Adicionada uma nova técnica no gerenciamento de memória, Memory Compression, proporcionando um uso mais eficiente da memória do host. Essa é uma técnica que está entre o ‘Ballooning’ e o ‘Host Swapping’, ou seja, quando o host não consegue recuperar memória através do ‘ballooning’ ele irá usar a técnica de Memory Compression, para só então, no caso de ainda estar apresentando falta de memória, partir para o swap em disco. (Estou preparando um post para explicar como funciona o gerenciamento de memória no ESX)
- Storage I/O Control – fornece a opção de ‘limits’ e ‘shares’ para acesso a disco, ou seja, permite que você garanta para uma VM um determinado nível de acesso ao storage,mesmo quando o mesmo encontra-se sobrecarregado.
- Network I/O Control – permite gerenciar e particionar a banda de rede numa placa física entre diferentes tipos de trafego (VMs, vMotion, FT, ...).
- Load-Based Team – balanceamento automático de carga num grupo de placas de rede físicas configuradas em um vNetwork Distributed Switch.
Link: http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html
Link: http://www.vmware.com/files/pdf/VMware-Whats-New-in-vSphere-41-ds-en.pdf
segunda-feira, 24 de maio de 2010
Novo Programa de Certificações da VMware
VCP4
VCAP4-DCA
VCAP4-DCD
VCDX4
fonte: http://mylearn.vmware.com/mgrreg/index.cfm?redirect=off
sexta-feira, 2 de abril de 2010
Administering VMware Site Recovery Manager 4.0
quarta-feira, 3 de março de 2010
Identificando um disco do Windows nas propriedades da VM
Por exemplo, uma máquina virtual possui dois discos, um está na SCSI Controller 0 e SCSI Target ID 0 (Hard Disk 1), e o outro na SCSI Controller 1 e SCSI Target ID 0 (Hard Disk2), como mostrado abaixo.
No Gerenciamento de Disco, eles são exibidos corretamente, na ordem em que foram adicionados.
Só que o que acontece se adicionarmos um novo disco na SCSI Controller 0??
Adicionei um novo disco na máquina virtual utilizando a SCSI Controller 0, SCSI Target 5 (Hard Disk 3). Agora veja como o Windows reconheceu esse disco.
Aparentemente está tudo certo, correto? Calma! Vamos dar um boot na máquina para confirmar.
Veja que após o boot os discos 1 e 2 foram invertidos. Neste caso foi fácil saber qual era qual por causa do tamanho. Mas e se os dois tivessem o mesmo tamanho? Talvez nem teríamos percebido que os discos haviam trocado de posição. Isso aconteceu porque o último disco (Hard Disk 3) foi adicionado numa posição anterior ao Hard Disk 2.
Portanto, quando quiser remover um disco de uma máquina Windows, confirme antes qual é mesmo o seu ‘vmdk’ correspondente. Uma maneira de descobrir o SCSI Port e o SCSI Target ID de um disco é através da ferramenta ‘msinfo32.exe’.
sexta-feira, 5 de fevereiro de 2010
Forçando o desligamento de uma VM travada
Método 1 – Utilizando o vmware-cmd pela Service Console
• Logue no ESX pela Service Console
• O comando vmware-cmd usa o arquivo de configuração .vmx da VM para especificar em qual máquina virtual será executada a operação. Você pode executar ‘vmware-cmd –l ‘para listar todas as VMs no host, juntamente com o caminho e o nome do arquivo de configuração. Se você não quiser digitar todo o caminho quando for executar o ‘vmware-cmd’, você pode mudar para o diretório da VM e executar o comando a partir de lá, sem a necessidade de colocar o caminho.
• Você pode checar o estado da VM executando:
vmware-cmd (virtual_machine).vmx getstate
• Para forçar o desligamento da maquina virtual, execute:
vmware-cmd (virtual_machine).vmx stop hard
• Cheque novamente o estado da VM para verificar se funcionou, se tiver funcionado o estado será ‘off’.
Método 2 – Usando o comando vm-support para desligar a VM
• Logue no ESX pela Service Console
• O comando vm-support é um comando com vários propósitos, usado principalmente para resolver problemas com hosts e VMs. Você pode usar o paramêtro -X para forçar o desligamento da VM e também produzir um arquivo com informações para debug. Este comando irá gerar um arquivo .tgz no diretório de onde você executou o comando. Este comando não pode ser executado a partir de um diretório de um volume VMFS, o recomendado é executá-lo a partir do diretório /tmp. Primeiramente execute vm-support –x para listar o virtual machine ID (VMID) de todas as VMs que estão rodando.
• Para forçar o shutdown e gerar os core dumps e os arquivos de log, execute:
vm-support -X (vmid). Será perguntado se você deseja tirar um screenshot da VM. Um screenshot pode ser útil para ver se existe alguma mensagem de erro. Também será perguntado se você deseja envia um NMI e um ABORT para a VM, o qual pode ajudar no debug. Você deve dizer YES para a pergunta do ABORT para que a VM seja forçada a parar. Depois que o processo completar, que pode levar de 10-15 minutos, um arquivo .tgz será criado no diretório de onde o comando foi executado, que pode ser usado na solução de problemas.
Método 3 – Utilizando o comando KILL
• Logue no ESX pela Service Console
• O comando 'ps' no linux exibe os processos rodando atualmente num servidor e o comando 'grep' encontra um texto específico na saída do comando 'ps'.
Execute: ps auxfww | grep (virtualmachinename) para conseguir o ID do processo (PID) da VM. Você terá dois resultados, um será do próprio comando 'ps'. O resultado mais longo é o processo da VM que está rodando. Este resultado termina com o nome do arquivo de configuração da VM e o número na segunda coluna do resultado é o PID da maquina virtual.
• O comando 'kill' no linux envia um sinal para terminar um processo usando o seu número de ID. O paramêtro -9 termina imediatamente com o processo e não pode ser ignorado.
Execute kill -9 (pid) que irá forçar o término do processo para a VM específicada.
fonte: http://itknowledgeexchange.techtarget.com/virtualization-pro/killing-a-frozen-vm-on-a-vsphere-esx-host/
segunda-feira, 25 de janeiro de 2010
Windows 2008 R2 e Windows 7 travando no VSphere Client
Se acessada via Remote Desktop a máquina funciona normalmente.
Este já um problema conhecido, que inclusive já foi documentado no site da própria vmware: VMware KB 1011709.
Ainda de acordo com a VMware, este problema seria solucionado após a atualização para o VSphere 4 Update 1, porém mesmo após ter feito todas as atualizações, algumas máquinas voltaram a travar por este mesmo motivo.
Para solucionar o problema tive de desinstalar o driver de video que estava sendo utilizado (VMware SVGA II) e utilizar o drive padrão da microsoft (Standard VGA Graphics Adapter).
terça-feira, 19 de janeiro de 2010
10 blogs excelentes sobre Virtualização
http://blog.scottlowe.org/
http://www.boche.net/blog/
http://deinoscloud.wordpress.com/
http://www.yellow-bricks.com/
http://www.virtu-al.net/
http://vsphere-land.com/
http://virtualgeek.typepad.com/virtual_geek/
http://blogs.vmware.com/vmtn/
http://www.simonlong.co.uk/blog/
http://vpivot.com/
segunda-feira, 18 de janeiro de 2010
Bem-Vindos!
Assinar:
Postagens (Atom)