ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

By

Arquitetura do Hyper-V

Olá Pessoal,

Este post faz parte de uma série de post que eu e o Fabio Hara (www.fabiohara.com.br) estamos fazendo com conteúdo que apresentamos nos ITCamps. Para entender melhor, confira este post do Blog do Fabio Hara.

Hoje, vou falar um pouco sobre a arquitetura do Hyper-V:
Para começar, vamos entender alguns dos pré-requisitos para se instalar o Hyper-V. Quando falamos de requisitos, o primeiro que todos se lembram é que o processador tem que suportar Virtualização. Isso acontece pois o Hyper-V utiliza um anel de processamento exclusivo. Todos os processadores possuem os chamados anéis de processamento, como por exemplo o Ring 1 onde é executado o Kernel do Sistema Operacional, e o Ring 3 onde as aplicações são executadas. Quando habilitamos o suporte a virtualização na BIOS, estamos habilitando, na verdade, a utilização deste anel de processamento. Este anel de processamento também é conhecido como Ring -1 ou Ring Decompression. Todas as instruções do Hypervisor serão executadas neste anel exclusivo garantindo a performance do Hyper-V.

Porém, há algumas outras coisas a se verificar. Por exemplo, temos o Data Execution Prevention (DEP) que, por padrão já vem habilitado na BIOS e no Windows. O DEP é responsável, entre outras coisas, por garantir que uma partição não tenha acesso a outra partição. Explicaremos o que são partições em breve, mas basicamente, é onde o Sistema Operacional convidado (Guest) é instalado. Isso garante que uma máquina virtual não terá acesso a outra máquina virtual.

Há também alguns requisitos opcionais, mas que farão diferença na performance se estiverem presentes. Um exemplo é o recurso Second Level Address Translation (SLAT) (http://www.fabiohara.com.br/2012/06/16/second-level-address-translation-no-hyper-v/).

Se você trabalha com VMWare, não se preocupe com os outros drivers do seu servidor. Explicaremos isso mais a frente, mas no caso do Hyper-V, diferente do ESX/ESXi, não há uma Hardware Compatibility List (HCL) específica para Hyper-V. Se o hardware foi desenhado para Windows Server, então o driver irá funcionar com Hyper-V. Muito mais simples, certo? Isso acontece por conta da forma como a arquitetura do Hyper-V foi concebida. Veja, primeiro, a arquitetura do ESX/ESXi:

image

Nesta arquitetura, os drivers ficam dentro do Hypervisor, fazendo com que o hardware onde se instala o ESX/ESXi, tenha sido feito para ESX/ESXi. Basicamente, você só poderá instalar o ESX/ESXi em um hardware que foi homologado para esse Hypervisor. Já com Hyper-V é diferente. Veja a imagem:

Picture1

Neste modelo, os drivers ficam dentro da instalação do SO da máquina física, que após a instalação do Hyper-V, passa a se chamar Partição Pai (ou Parent Partition). Como o Windows Server já possui uma HCL (HCL gigantesca, diga-se de passagem) não faz sentido criar uma HCL para o Hyper-V. Basicamente, o que estamos dizendo aqui, é que se o Driver funciona no Windows Server, irá funcionar com o Hyper-V. Simples assim… É por isso que conseguimos fazer o Hyper-V funcionar mesmo em um notebook.

Para explicar melhor essa arquitetura, veja a imagem abaixo:

image_thumb2

Como você pode ver na imagem acima, o partição pai é a partição onde você instalou o Windows Server no Host. Quando você habilita o Hyper-V, basicamente o Windows muda sua arquitetura para que esse SO passe a se comportar como se fosse uma máquina virtual. As máquinas virtuais que você cria, são criadas nas chamadas partições filho (ou Child Partition). Alguns componentes são importantes de serem mencionados aqui:

- VSP: O Virtual Service Provider é responsável por receber as chamadas feitas pelas partições filho na partição pai. É ele que é responsável por fazer com que as partições filho tenham acesso correto ao hardware, utilizando os drivers corretamente. Repare que ele opera em modo Kernel na partição pai, isso garante a performance.

- VMBus: O VMBus é um barramento de alta velocidade (opera em modo kernel) que faz as passagens entre as partições. Ele é o canal de comunicação entre o VSC e o VSP.

- VSC: O Virtual Service Client é o componente dentro do Sistema Operacional convidado que intercepta o acesso ao Hardware e faz a solicitação, via VMBus, ao VSP na partição pai. Ele também opera em modo Kernel, mas isso só acontece se você instalar o Integration Components (IC) na partição convidada. (Servidores Windows Server a partir do Windows Server 2008 já possuem IC instalado)

Para facilitar o entendimento, basicamente, o que acontece é que se você está rodando uma máquina virtual Windows Server com o IC instalado, quando uma aplicação faz uma chamada para o hardware, o VSC irá interceptar esta chamada e fazer o acesso via VMBus para o VSP na partição pai. O ponto mais importante aqui é entender que todo este processo ocorre em Kernel Mode. Ou seja, em teoria, a VM terá a mesma performance que uma máquina física neste operação.

No caso de um SO Guest onde você não consegue instalar o IC, esse processo acima não ocorre. Neste caso, o que acontece é que quando uma aplicação faz a chamada ao Hardware, o SO guest vai abrir um processo em modo usuário na partição pai. Como o processo foi levado ao modo usuário, há degradação na performance neste caso.

É importante frisar uma coisa aqui: Um Windows NT pode rodar em Hyper-V e provavelmente com performance melhor do que se estivesse rodando em um servidor antigo, da época do Windows NT. Porém, esse Windows NT nunca terá a mesma performance que um outro SO que você consegue instalar o IC corretamente.

Para entender o que acontece no SO Guest quando você tem o IC instalado ou não, veja a imagem abaixo:

image_thumb3

Quando o IC está instalado (imagem a direita) o dispositivo é listado no Device Manager como Microsoft VMBus. Isso comprova que o IC foi instalado e o dispositivo está sendo reconhecido.

Você deve estar se perguntando agora, e Linux? Para Linux também há o Integration Services. O IS para Linux é o paralelo ao Integration Components para Windows. Quando uma aplicação dentro do SO Guest Linux faz uma chamada para o hardware, também há um VSC para Linux que faz o mesmo papel do VSC em um SO Guest Windows. E assim como em um Guest Windows, no Guest Linux tudo isso ocorre em modo Kernel. Na verdade, isso significa que o SO Guest Linux terá a mesma performance que um SO Guest Windows.

Espero que as informações acima tenham ajudado a entender melhor a arquitetura do Hyper-V. Até mais!

By

Technet TV com Roberto Prado, vale a pena assistir…

Olá Pessoal,

Segunda-feira passada tivemos o Technet TV Episódio 15. O convidado desta vez foi o diretor de Competitividade Nacional da Microsoft Brasil, Roberto Prado. Não tenho nem palavras para descrever como foi legal o papo com ele e como é importante o trabalho que ele vem fazendo. Recomendo que assistam:



Video streaming by Ustream

Espero que gostem da conversa.
Abraços!

By

Drops 2012 #03 – Novidades do AD no Windows Server 2012

Espero que gostem! Desculpem a demora no vídeo #03!
Aguardem que em breve tem mais!

By

Windows Server 2012 Virtual Labs

Olá Pessoal,

Se você quer testar o Windows Server 2012, conhecer as novidades, mas não tem onde instalar, seus problemas acabaram! Já está disponível o Virtual Lab de Windows Server 2012.

Com o Virtual Lab, você é guiado a um laboratório para fazer exercícios e ver como utilizar o produto. Para o Windows Server 2012, temos diversos Labs:

- Active Directory Deployment and Management Enhancements
- Configuring a Highly Available iSCSI Target
- Configuring Hyper-V over Highly Available SMB Storage
- Implementing Storage Pools and Storage Spaces
- Introduction to Windows PowerShell Fundamentals
- What’s New in Windows PowerShell 3.0
- Managing Branch Offices
- Managing Network Infrastructure
- Managing Your Network Infrastructure with IP Address Management
- Managing Windows Server 2012 with Server Manager and Windows PowerShell 3.0
- Online Backup Service
- Using Dynamic Access Control to Automatically and Centrally Secure Data

Para acessar o Virtual Lab: http://technet.microsoft.com/en-us/windowsserver/hh968267.aspx

Até mais!