Tecnologias

Windows Server 2008 Standard

Windows Server 2008 Enterprise

Windows Server 2008 Datacenter

Sumário

Este artigo abordará a arquitetura do Hyper-V e seus componentes, além de sua história, comparativos com o Virtual Server, VMware e XenServer e informações mais avançadas.

Conteúdo

Introdução

Arquitetura do Hypervisor

   História da virtualização na Microsoft

   Virtual Machine Monitor (VMM)

   Estrutura do Hypervisor

   Virtualização de Hardware

   Virtualization Stack

   Hyper-V, XenServer ou VMware ESX?

Conclusão

Referencias

Sobre o autor

Introdução

Hoje em dia, não é difícil ter uma empresa que utilize algum tipo de virtualização. Esta solução está cada vez mais presente no nosso cotidiano pelos recursos oferecidos e o baixo custo. A Microsoft entrou na briga com dois outros gigantes deste mercado emergente: VMWare ESX e o XenServer (Citrix), agora os três disputam nossa preferência com unhas e dentes. Com sua ótima arquitetura, onde é possível usufruir do hardware com máxima eficiência, só que com alguns recursos adicionais como gerenciamento, administração facilitada e uma integração mais abrangente com outros serviços que serão abordados durante o artigo, vocês verão o porque do sucesso da Microsoft com o Hyper-V.

Arquitetura do Hypervisor

História da virtualização na Microsoft

Tudo começou em fevereiro de 2003, quando a Microsoft adquiriu uma empresa que já estava no mercado desde 1988  chamada Connectix. Empresa esta que tinha uma solução que conseguia virtualizar sistemas operacionais. Para quem não conhecia era de espantar, pois era possível fazer vários testes de funcionalidades do sistema operacional (SO), mas de uma forma virtual dentro de um SO já existente. O interessante é que toda essa tecnologia de virtualização não é uma novidade. Para falar a verdade, já existiam ambientes virtuais nos grandes Main Frames da década de 60 que conseguia simular, num ambiente virtual também, várias máquinas virtuais como o modelo IBM I44. Tento como base algumas referências dos produtos da Connectix, em setembro de 2004 a Microsoft lançou o Virtual Server 2005, um servidor com suporte a máquinas virtuais (VM), porém esse tinha algumas limitações de hardware, os sistemas virtuais só podiam utilizar um processador x86 e no máximo 3.6 GB de memória por VM. Correndo paralelamente com essas soluções virtuais a Intel e a AMD lançavam seus processadores com suporte a virtualização de Hardware, batizados de Intel-VT e AMD-V. O Virtual Server 2005 R2 SP1 foi lançado e já dava suporte às novas tecnologias de processadores, disponibilizando um melhor desempenho, no entanto toda chamada de hardware feito pelas VMs era enviada ao Virtual Machine Monitor (VMM), ele por sua vez, encaminhava essas chamadas para o Sistema Operacional host e depois para o Kernel do Windows. Apenas depois disso a VM acessava o Hardware fazendo, desta forma, um chaveamento do processador entre a máquina física e a virtual. Era por esse motivo que o Virtual Server 2005 não utilizava 100% do poder proporcionado pela virtualização de hardware da Intel e AMD.

No Windows 2008 a Microsoft lançou o Hyper-V e o Hyper-V Server. Este último seria uma versão gratuita do sistema operacional somente com a função do Hyper-V habilitada. O Hyper-V oferece suporte a VM x86 e x64, além de 64 GB de memória e até 4 processadores por máquina virtual, usando toda a capacidade de virtualização de hardware. Na tabela abaixo fica aparente a diferença entre as soluções:

Tabela 1 – Diferenças entre Virtual Server, Hyper-V e Hyper-V Server

Comparando com seu antecessor Virtual Server 2005, o diferencial do Hyper-V associado à virtualização de hardware são VMs com mais suporte a memória e processadores, tendo como resultado a velocidade e segurança.

Virtual Machine Monitor (VMM)

Para explicar de uma forma mais técnica e avançada a diferença entre os tipos de virtualização usada pelo Virtual Server e Hyper-V é importante entendermos um pouco do VMM.

Ele é responsável pela criação, preservação, acesso aos recursos de sistema e gerenciamento das VM. Existem três tipos de implementação do VMM: VMM Tipo 2, VMM Híbrida e VMM Tipo 1.

VMM Tipo 2                             VMM Híbrida                                 VMM Tipo 1

Figura 1 – Tipos de VMM

O VMM de tipo 2 é executado acima do sistema operacional host, como softwares que necessitam de virtualização, mas que estão sendo executados no sistema operacional. O tipo híbrido é executado paralelamente ao Sistema Host, tipo este usado pelo Virtual Server 2005 R2, que já usava a tecnologia dos processadores AMD-V e Intel-VT, porém sem o hypervisor. O terceiro, tipo 1, é uma solução baseada no Hypervisor, usada pelo Hyper-V, proporcionando mais performance e com uma série de componentes para comunicação das VMs ao hardware.

Estrutura do Hypervisor

O Windows Server 2008 com Hyper-V oferece uma estrutura para a virtualização baseada no Hypervisor da Microsoft (VMM tipo 1), creio que isso não deva ser novidade para ninguém uma vez que é normal lermos ou ouvirmos isto em quase todo lugar onde o assunto é o Hyper-V. Ao instalar o Windows Server 2008, o Hyper-V não é instalado automaticamente. O SO sem o Hyper-V tem acesso direto ao hardware e não existe estrutura do Hypervisor, conforme figura 2.

Após a instalação do sistema operacional é preciso adicionar a função do Hyper-V no Server Manager (lembrando que esta função só está disponível no Windows Server 2008 x64).

Figura 2 – Windows 2008 sem o Hyper-V

Depois da instalação do Hyper-V e reinicialização da máquina, o SO sofre várias alterações. O arquivo responsável pelo boot do Windows (winload.exe) carrega o driver hvboot.sys. Este driver verifica qual processador está sendo executado e se ele dá suporte à virtualização. Após este processo, é carregado o arquivo da imagem do hypervisor (Hvix64.exe para Intel-VT ou Hvax64.exe para AMD-V). Só depois disto o sistema é inicializado, assim criando uma única partição padrão chamada Parent Partition, onde é feita a primeira virtualização e nela é executado o Windows 2008. Soa estranho, mas é isto mesmo, o sistema operacional que você sobe depois que o Hyper-V foi instalado também é virtual. As máquinas virtuais que são adicionadas depois pelo Hyper-V são criadas em partições chamadas de Child Partitions. É o Hypervisor que gerencia essas partições e as isolam, além de controlar o acesso delas ao hardware.

Virtualização de Hardware

Outro assunto interessante abordarmos é a virtualização de hardware. Sem este hardware específico existem somente 4 anéis de processador, chamados de Rings, que definem o nível de privilégio de acesso ao processador. O de maior privilégio é o Ring 0, usado pelo Kernel do Windows e o Ring 3 que é usado normalmente no nivel User, que somam um total de 4: Ring 0, 1, 2 e 3.

Ao instalarmos o Hyper-V é criado um anél que é executado em um modo chamado privilegiado, ou Ring -1. Este anel faz com que o hypervisor rode em um privilégio maior que o do Kernel do Windows possibilitando qualquer sistema operacional de continuar a ser usado no Ring 0 e as aplicações dos usuários no Ring 3. Na figura 2 é possível analizarmos as partições Parent e Child, além dos anéis de processamento.

Figura 3 – Hypervisor, Rings e partições

O Hypervisor do Windows é executado diretamente neste anel, o Rind -1, conseguindo desta forma um isolamento de acesso somente para o serviço específico.

Virtualization Stack

Toda criação e gerenciamento das máquinas virtuais do Hyper-V são feitas por uma série de dispositivos virtuais e componentes de softwares que trabalham em conjunto chamados de Virtualization Stack usados tanto na partição Parent quanto nas Child. Alguns deles são: Virtualization Service Provider (VSP), Virtualization Service Client (VSC) Virtualization Infrastructure Driver (VID) e Virtual Machine Bus (VMBus). Esta série de softwares e componentes trabalham com o console de gerenciamento do Hyper-V em conjunto com o hypervisor. O VSP é um componente de software que se encontra na partição Parent e que controla as solicitações de I/O em nome das máquinas virtuais. Já o VMBus é responsável pela transferência de dados e a entrega de serviços entre as partições Parent e Child por um canal dedicado disponibilizado entre os VSCs e os VSPs. O VSC usa o VMBus para a comunicação das partições Child até os VSP para o funcionamento dos drivers sintéticos que são executados nas partiçoes Child.

O VID usa algumas APIs para a comunicação entre a partição Parent até o Hypervisor. Os acessos e as instruções das APIs da partição Parent ao Hypervisor são chamadas de Hypercalls. O VID é aplicado em dois nívels: em nível de kernel pelo arquivo VID.sys no Ring 0 e no nível User pelo arquivo VID.dll no Ring 3.

Hyper-V, XenServer ou VMware ESX?

Nas comunidades e todo círculo onde o assunto é virtualização sempre é feita a pergunta: Qual é a melhor solução, Hyper-V, VMware ou XenServer? Para tentar mostrar a eficiência desta arquitetura do Hyper-V e respondê-la, levei em consideração este teste a seguir feito por um grupo da comunidade. O teste foi realizado por  especialistas do site Virtualization Review (www.virtualizationreview.com). Foram três ambientes de testes montados que tentaram estressar as três soluções com algumas VMs utilizando um servidor de SQL 2005. O primeiro teste foi com seis máquinas virtuais executadas em um servidor host usando uma carga pesada de processamento e memória. O segundo foram com doze máquinas virtuais em um único servidor host usando também uma carga pesada de processamento e memória. Já o terceiro ambiente foram doze máquinas virtuais em um único servidor host, mas usando uma sobrecarga menor de processamento e memória.

Os resultados destes testes estão descritos nas três tabelas abaixo:

Tabela 2 – Resultado do ambiente teste entre Hyper-V, XenServer e Vmware ESX

Para os profissionais envolvidos no teste, o Hyper-V superou as expectativas. Eles não esperavam que o sistema da Microsoft saísse tão bem comparado com as soluções existentes. Percebam pelos resultados que em alguns casos ele usa menos recursos de hardware (como no teste 1 e no teste 3) do que seus concorrentes. Mesmo nos casos em que existam diferenças no uso do hardware, a resposta do Job do SQL nas VMs foi muito mais rápida que dos seus concorrentes, ou seja, ele pode usar uma carga maior de hardware em certas circunstâncias, mas a resposta do serviço que utilize este hardware é proporcional a esta utilização.

Mesmo assim, a resposta obtida pelo resultado final à nossa pergunta (qual é a melhor solução) foi... Depende!

Depende de quantas máquinas virtuais você irá utilizar e a sobrecarga de cada uma delas. Segundo Rick Vanover, responsável pelos testes, o Hyper-V é indicado em ambientes que você tenha VMs com aplicações que precisem de muito processamento e memória, tirando o máximo proveito desses recursos, já o VMware seria interessante em grandes ambientes com baixa sobrecarga de uso, no caso de um único servidor com várias máquinas virtuais.

É possível afirmar que o Hyper-V saia à frente dos seus concorrentes nos dois cenários citados levando em consideração a interoperabilidade, o gerenciamento avançado e administração centralizada que são oferecidos quando usamos outras soluções da Microsoft, como o System Center Virtual Machine Manager (VMM Server), o System Center Operations Manager (SCOM) o System Center Configuration Manager (SCCM) e o System Center Data Protection Manager (DPM). Imaginem alguns servidores com Hyper-V, Hyper-V Server, Virtual Server 2005 e VMware ESX sendo administrados centralmente em uma única console com o VMM Server, onde é possível mover uma máquina virtual de uma solução à outra, além de criar modelos de VMs que sirva tanto para o Hyper-V quanto para o VMware. Agora pensem nas atualizações do SO (tanto host quanto virtual) com inventário de hardware e software de todo esse ambiente acima sendo feito pelo SCCM, com possibilidades como monitoramento da máquina física, da virtual e da aplicação que é executada na máquina virtual com ótimos relatórios pelo SCOM. Movimentação automática de uma VM em um servidor host para outro que esteja com o hardware mais livre numa eventual super utilização de hardware da VM ou simplesmente na criação de um Network Load Balance (NLB) entre duas máquinas virtuais quando você só tem uma para minimizar a utilização (a outra é criada e configurada automaticamente pelo serviço PRO Tips do SCVMM em conjunto do SCOM) num servidor Web totalmente sobrecarregado. Não esquecendo o backup, restore e o Disaster Recovery das VMs feito pelo DPM.

Estes foram alguns exemplos do que é possível fazer com o Hyper-V e outras ferramentas integradas mostrando sua eficiência e as possibilidades que podemos ter, facilitando nosso dia-a-dia na administração do ambiente virtual.

Conclusão

Com este artigo você pôde entender a arquitetura e alguns diferenciais que fazem do Hyper-V uma das melhores soluções de virtualização de servidores que existe no mercado.

Referências

http://virtualizationreview.com/articles/2009/03/02/lab-experiment-hypervisors.aspx

Livro Windows Server 2008 Hyper-V Resource Kit (ISBN: 978-0-7356-2517-4)