Como funciona o Azure – O Hypervisor

Olá pessoal, tudo certin?

Windows Azure representa uma alternativa bastante viável para desenvolvimento para Cloud. Se você ainda não sabe nada sobre o assunto, não perca tempo!

Hoje, trato de internals do Windows Azure. Isso significa que não pretendo demonstrar como escrever código para ele.

Este post deverá ser apenas o primeiro de muitos que pretendo escrever sobre este tema. Especificamente hoje, quero falar sobre um dos elementos mais importantes da arquitetura do Windows Azure: o Hypervisor.

Por onde eu comecei e o caminho que percorri…

O Windows Azure é uma tecnologia inteiramente nova. Consequentemente, poucas pessoas fora da Microsoft possuem conhecimento sólido de seu funcionamento. Definitivamente não estou entre elas! Sou um estudante e como tal utilizo diversos recursos para a prender. Dentre os recursos que recomendo estão:

• Blogs
  • Há vários, mas gostaria de recomendar como ponto de partida o do Otávio Pecego.
• Site do Azure: www.azure.com
• Livros
  • Pro Azure Services Platform
  • Developing Applications for the Cloud
  • Programming Windows Azure
  • Windows Azure Platform
  • Building applications in the Cloud: Concepts, Patterns and Projects

Boa parte do que você vai ler aqui vêm dessas fontes. Obviamente, adiciono minhas considerações (e é nesses pontos que devem estar os prováveis desvios que você encontrará aqui).

Por que considero importante saber como o Azure Funciona?

Sempre que me deparo com uma nova tecnologia, considero importante separar seu estudo em três partes. Observe:

 

´

Há, obviamente, o estudo de como escrever código usando a nova tecnologia. Com realação ao Windows Azure, há um grande número de fontes que podem mostrar como isso funciona. Em um outro extremo, estão as informações sobre como a tecnologia funciona, os internals.

Penso que usar uma tecnologia sem entender como ela funciona é como lutar sem conhecer o campo de batalha. Se você quer construir uma aplicação com performance superior ou deseja entender um comportamento estranho, compreender como as coisas funcionam por baixo do capô pode ser a diferença entre vencer ou perder a batalha.

Penso que mesmo que não tenha uso direto para uma tecnologia, ter algum conhecimento sobre como as coisas funcionam pode ser divertido. Para um bom arquiteto, pode representar insights interessantes.

O que há para ser visto?

Windows Azure é uma plataforma complexa e multicamadas. É uma combinação de hardware e software, separados em diversas camadas lógicas, instalados fisicamente em data centers presentes em diferentes localidades.

Passei a entender melhor o Windows Azure a partir de uma representação proposta no livro Programming Windows Azure. Observe:

Nessa representação, as camadas mais externas são aquelas com as quais temos mais contato quando codificamos. Já as mais internas são aquelas mantidas sob controle mais rígido da Microsoft. Com mais detalhes, percebemos que:

• O hardware, no centro da representação acima, é mantido pela Microsoft em diversos data centers espalhados em todo o mundo. Alguns desses data centers “rodam” o Azure;
• Cada máquina do datacenter executa um hypervisor otimizado e ajustado para seu datacenter, bem como para o hardware que formam essas máquinas. O hypervisor não tem um nome oficial (até onde eu saiba). Entretanto, é provável que você o veja com o nome Windows Azure Hypervisor. A coisa mais importante para lembrar aqui é que não se trata do Hyper-V.
• O agrupamento das máquinas nos data centers para o Azure é gerenciado por uma aplicação massivamente distribuida chamada “Fabric”. O Fabric gerencia o hardware, os sistemas operacionais nos computadores e as aplicações rodando nessas máquinas. Essas aplicações, por sua vez, podem utilizar todoos os serviços que o Windows Azure oferece;
• Há muitos desses Fabrics rodando em diferentes localizações geograficas. Quando distribuímos uma aplicação, ou quando criamos uma conta de armazenamento, escolhemos qual dessas localizações desejamos que seja a hospedeira.

Como já foi dito, meu foco principal hojé é o Windows Azure Hypervisor.

Afinal, o Windows Azure é um sistema operacional?

Ouvi dezenas de vezes a afirmação de que o Windows Azure é o sistema operacional para nuvem da Microsoft.  Essa analogia é útil para explicar a coisa para pessoas não técnicas. Entretanto, confunde desenvolvedores que imaginam que há um novo sistema operacioal espalhando nos datacenters da Microsoft executando seus aplicativos.

É importante destacar que essa analogia é um pouco forçada. Se nós conceituarmos um sistema operacional, veremos que uma de suas tarefas mais importantes é gerar alguma abstração do hardware para os aplicativos que executa. Ou seja, no lugar do desenvolvedor ficar preocupado com especificades do hardware, pode escrever código para uma API genérica e deixar o sistema cuidar dos detalhes. Nesse sentido, o Azure é um sistema operacional, pois ele abstrai o hardware do datacenter.

Entretanto, a anlogia acaba aqui. Windows Azure não é um sistema operacional de verdade. O Sistema operacional que roda nossos códigos no nuvem (diretamente) é o Windows Server 2008 (ou melhor, algo bem parecido).

Importante: Sim, a infraestrutura do Azure orquestra a execução de aplicativos (Azure não é apenas armazenamento). As roles funcionam como agentes operativos que permitem a execução de atividades complexas de forma paralela resultando em grande poder computacional. Ainda assim, penso que a analogia com SO seja um pouco forçada.

Uma palavra sobre os data centers

Os datacenters são os “palcos” onde toda a ação Azure acontece. Windows Azure é executado em diversos datacenters da Microsoft ao redor do mundo. Como qualquer outra grande companhia que mantém datacenters, a Microsoft mantém certo mistério sobre eles.

O primeiro Datacenter da Microsoft foi montado em setembro de 1989. Localizado no campus da Microsoft, em Redmond, está muito abaixo dos datacenters que rodam os serviços online da Microsoft hoje em dia.

A Microsoft não revela o número exato de datacenters que possuí (brincam dizendo algo em torno de 10 e 100). Além disso, a Microsoft não dala sobre a localização exata desses datacenters.

Até onde se sabe, esses datacenters atendem a uma diversidade de propósitos e não somente rodar o Azure.

Cada um dos datacenters é escalável, mas, ao mesmo tempo, são montados para serem ecologicamente corretos. Quase toda energia consumida provem de hidroelétricas o cooling quase sempre ocorre com água reciclável.

Por que um Hypervisor?

Sabendo sobre os data centers que fazem a mágica do Azure acontecer, a próxima questão obviamente recai sobre como os sistemas operacionais executam nas máquinas…

Uma análise mais simples poderia conduzir a idéia de instalar uma instância do Windows Server 2008 diretamente em cada computador. A propósito, esta é a forma como muitas empresas executam aplicativos em seus data centers hoje em dia. Entretanto, há pelo menos dois problemas com essa abordagem:

1. Compartilhamento de recursos;
2. Migração de cargas de trabalho.

Executar sistemas operacionais diretamente sobre o hardware implica em esse ter o controle total da máquina. Em outras palavras, para cada aplicação rodando no datacenter, um computador. Isso faz bem pouco sentido se pensarmos que poderemos estar dedicando máquinas potentes com muitos gigabytes de RAM para websites com quase nenhum acesso.

Outra implicação é a impossibilidade de mover aplicações e cargas de trabalho facilmente. Se um Website A estivesse com baixa demanda e um Website B estivesse sob stress, não seria fácil, nem rápido, dar parte do poder computacional da máquina que está hospedando o Website A para o Website B.

A solução que vem sendo repetidamente apontada para esses problemas é a virtualização. Ou seja, a capacidade de manter diversos sistemas operacionais convidados rodando simultaneamente em um mesmo computador, sob o controle de um sistema operacional hospedeiro. Cada sistema operacional convidado vê uma máquina inteira (chamada máquina virtual), e é completamente desinformado quanto a existência de outros sistemas operacionais. Estas máquinas virtuais compartilham os recursos da máquina real.

Para criar e manter diversas maquinas virtuais em uma única máquina física, um pequeno software chamado hypervisor é usado. Esse software é responsável pela alocação justa de recursos entre as máquinas virtuais. É o hypervisor que agenda o tempo da CPU e as requisições de I/O, além de prover isolamento entre as diversas máquinas virtuais.

Na representação acima, o Hypervisor opera como uma balança que equilibra os recursos entre diveras máquinas virtuais.

Como programas Hypervisor interferem na execução dos sistemas operacionais convidados

Para executar suas atividades de forma eficiente, o hypervisor precisa contar com o suporte do hardware.

Um processador x86/x64  oferece quatro níveis de previlégio chamados Rings, sendo o Ring 0 o mais poderoso e o Ring 3 o mais restrito.

Todos os sistemas operacionais modernos utilizam esse conceito rodando o kernel (coração do sistema operacional) em Ring 0, e todos os demais aplicativos no Ring 3. Por exemplo, no Windows, o ntoskrnl.exe (o “Sistema” no TaskManager) executa no Ring 0 junto com todos os drivers. Quando um código executando em Ring 3 precisa executar uma operação com alto previlégio, precisa executar uma transição para o Ring 0.

Os Rings 1 e 2 geralmente não são utilizados.

Todo o cenário que descrevi ocorre na execução de sistemas operacionais que rodam diretamente na máquina. Agora, onde executaria o hypervisor se o Ring 0 já está comprometido com o sistema operacional? Este problema foi resolvido pela Intel e pela AMD pela inclusão de um nível de previlégio inteiramente novo chamado de “Root mode”, ou Ring –1. Assim, todos os sistemas operacionais podem operar de forma normal entre os Rings 0 e 3.

Quando o processador reconhece que uma instrução executada em uma máquina virtual precisa de um previlégio maior para executar transfere a execução para o Hypervisor. Uma vez que o hypervisor tem conhecimento de todas as máquinas virtuais (e seus respectivos sistemas operacionais) consegue garantir que essas operações sejam executadas de forma “justa e equilibrada”.

Conversando com o Hypervisor: Hypercalls e Enlightenments

Sabemos como um sistema operacional normal roda sob o hypervisor. Entretanto, digamos que os criadores de sistemas operacionais soubessem dessa condição antes de funcionar….

Sistemas operacionais convidados podem se comunicar com o hypervisor onde estão sendo executados através de um mecanismo chamado hypercall. A relação entre o sistema operacional convidado e o hypervisor é bem semelhante ao que ocorre entre código em user-mode e kernel. Da mesma forma que um processo pode chamar uma API para conseguir acesso direto para algum recurso, o kernel de um sistema operacional convidado pode invocar um “hypercall” que resultará em alguma execução no Hypervisor.

Um enlightened kernel é aquele que usa hypercalls para se comunicar como o Hypervisor de forma a obter algum ganho de performance.  Esses kernels conseguem desepenho superior a outros que não contam com esse recurso.

O Hypervisor do Windows Azure

O que foi tido até aqui é verdadeiro para todos os hypervisors presentes no mercado hoje. O hypervisor do Windows Azure foi projetado por Dave Cutler (um dos pais do Windows NT). O hypervisor do Azure foi projetado com três princípios em mente: Ser rápido, pequeno e fortemente integrado com o kernel.

Projetado para ser o mais eficiente possível, foi desenvolvido de forma otimizada primando por execução em hardware sempre que possível. Por estar rodando em ambientes controlados, é otimizado para o hardware presente nos datacenters da Microsoft.

No Windows Azure, o kernel dos sitemas operacionais convidados são claramente otimizados para o hypervisor. Isso significa que eles contem dezenas de enlightenments.

Windows Azure Hypervisor e o Hyper-V não são a mesma coisa

A Microsoft lançou um Hypervisor, chamado Hyper-V, com o Windows Server 2008. Há, frequentemente, confusão sobre as diferenças do Hyper-V e o Windows Azure Hypervisor, sendo que alguns artigos assumem que eles sejam o mesmo.

Na verdade, ambos foram construídos com propósitos bem diferentes.  Hyper-V é distribuído como parte do Windows, por isso, precisa ser suportado por uma ampla variedade de hardware e necessidades. O Windows Azure Hypervisor executam somente nos data centers da Microsoft e são otimizados especificamente para o hardware onde o Windows Azure funciona.

Como esperado, dois produtos similares de uma mesma companhia compartilham código e design. Acredito que no futuro novas funcionalidades incluídas no Windows Azure Hypervisor serão implementadas no Hyper-V, e vice-versa.

Como o Windows Azure Hypervisor funciona?

O Hypervisor divide o sistema em multiplas máquinas virtuais ou partições. Aplicações executam sempre em partições, cada uma delas executando uma instância independente de um sistema operacional. Uma partição tem visibilidade apenas sobre um espaço de endereçamento, mas não possui acesso direto para o hardware.

Quando o sistema inicia uma partição especial é iniciada, a host partition. Esta partição é especial de diversas formas. É ela que tem acesso completo a operações de I/O, memória física, e todo o hardware. Ela executa operações criticas e é usada para executar todos os acessos a dispositivos usando drivers padrões do Windows.

No Windows Azure Hypervisor todos os dispostivos tratados pelas partições são interceptados pelo hypervisor e encaminhados para a host partition. Em grande parte, é assim para que não seja necessário nenhuma escrita de driver especial para o Hypervisor.

O “routing” das chamadas de I/O ocorrem através da Virtual Machine Bus (VMBus). Um sistema operacional convidado, sem enlightenments, poderia ingenuamente executar diversas operações de acesso a hardware para execução de uma única operação lógica. Isso envolveria muitas transições entre o convidado e o hyperviso e, finalmente a partição host. Para evitar esse problema, cada sistema operacional convidado no Windows Azure tem uma pilha, que pega algumas operações dos device drivers nos guest e encaminha pela VMBus para o sistema operacional host. Isso garante ganho de performance.

Qual sistema operacional executa nosso código no Windows Azure?

Mesmo com toda esa discussão sobre sistemas operacionais com enlightenments e integração com o Hypervisor, muitos desenvolvedores estão apenas interessados em saber sobre qual é o sistema operacional onde seu código executará. A resposta é simples. Aplicações rodam no Windows Server 2008 x64 Enterprise Edition ….

Bem, quase isso…

A Microsoft chama de “Windows Server 2008-compatible”, pois esse sistema é Windows Server em quase todos os sentidos, exceto pelo fato de que ocorreram alterações de baixo nível para otimizar o funcionamento com o Hypervisor. Entretanto, aplicações não conseguem perceber isso.

 

Por hoje, era isso!