Virtualização Aninhada para a Nuvem da Última Geração

Uma introdução ao aninhamento com KVM

A computação em nuvem é uma realidade que alterou os modelos de negócio e desenvolvimento para negócios online. Mas os modelos de nuvem IaaS atuais impõem uma restrição significativa sobre os desenvolvedores de software,— definindo qual hypervisor deve ser usado. O requisito das imagens de máquina virtual elimina o poder de escolha dos usuários da nuvem e, para alguns, é um obstáculo para começar a usar a nuvem. Porém, uma inovação da pesquisa da IBM irá alterar esse modelo. A tecnologia, denominada virtualização aninhada, permite uma pilha mais funda na solução, em que máquinas virtuais guests são armazenadas em um hypervisor convidado, que opera no hypervisor escolhido da nuvem. Neste artigo, exploramos as ideias por trás da virtualização aninhada e de que maneira elas irão aprimorar a nuvem.

M. Tim Jones, Independent Author, .

M. Tim JonesTim é arquiteto de firmware embarcado e autor de Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming (atualmente em sua segunda edição), AI Application Programming (em sua segunda edição) e Sockets Programming from a Multilanguage Perspective. Seu conhecimento em engenharia varia do desenvolvimento de kernels para naves espaciais geossíncronas até a arquitetura de sistemas embarcados e o desenvolvimento de protocolos de rede. Tim é arquiteto de software e autor em Longmont, Colorado.


nível de autor Contribuidor do
        developerWorks

17/Set/2012

Há dez anos, quando o tema "nuvem" estava sendo apresentado, seu foco era em serviços simples dentro de uma infraestrutura pública. Mas, como sempre ocorre em tecnologia, esses serviços evoluíram com seus modelos de uso. De maneira semelhante, a introdução da virtualização em hardware do produto também focou nos modelos de uso mais simples, e evoluiu à medida que o potencial foi mais bem compreendido.

À medida que os provedores de hardware observaram o crescimento da virtualização e da nuvem, também evoluíram suas ofertas, para fornecer suporte às necessidades de maneira mais eficiente. Os primeiros processadores x86 não eram ideais para a virtualização, mas os desenvolvedores dos componentes internos do processador focaram nesses novos modelos de uso e criaram um ambiente mais eficiente para a virtualização de plataforma.

Vamos começar com uma breve apresentação às arquiteturas em nuvem e a algumas de suas limitações.

Arquiteturas de nuvem pública

As nuvens públicas, ou infraestruturas virtualizadas disponíveis publicamente, focam na alocação simples de servidores virtuais, de maneira particionada por um hypervisor para uso por vários proprietários. O hypervisor atua como um multiplexador, tornando uma plataforma física compartilhável entre diversos usuários. Várias ofertas estão disponíveis para hypervisors, desde Kernel Virtual Machine (KVM) até o hypervisor Xen, entre outros.

Paravirtualização versus virtualização integral

Há diversas formas de hypervisors, desde hypervisors de virtualização integral transparente até hypervisors de paravirtualização semitransparentes. Embora o debate ainda prossiga sobre qual é o melhor, é interessante observar que a maioria dos hypervisors possui suporte para paravirtualização por meio da adição de ferramentas guests. Ferramentas guests são instaladas dentro do sistema operacional guest para melhorar a eficiência das operações de E/S. Dessa maneira, essa distinção tem se tornado menos importante, visto que a maioria dos hypervisors irá fornecer recursos de ambos os tipos.

Uma limitação das infraestruturas virtualizadas é sua dependência a determinados ambientes virtuais. A Amazon Elastic Compute Cloud (Amazon EC2), por exemplo, depende da virtualização Xen. A Amazon EC2 assume que quaisquer convidados que executem em sua infraestrutura sejam empacotados de maneira específica, denominada formato Amazon Machine Image (AMI). O formato AMI é a unidade fundamental de implementação na Amazon EC2 e pode ser um entre diversos tipos pré-configurados (com base no sistema operacional e conjunto de aplicativos) ou uma criação personalizada com esforços adicionais.

Esse formato de máquina virtual (VM) (que consiste em metadados e um formato de disco virtual) pode ser um obstáculo aos usuários da nuvem. A habilidade de migrar VMs da infraestrutura privada para a infraestrutura pública, ou entre infraestruturas de nuvem pública, é impedida por esse formato e pela dependência da escolha do hypervisor de destino.

Portanto, o suporte para virtualização aninhada cria uma nova abstração para os usuários da nuvem. Se as nuvens possuem suporte para a habilidade de virtualizar um hypervisor sobre outro hypervisor, o formato de VM se torna irrelevante à nuvem. A única dependência é o formato do hypervisor guest em si. Essa mudança evolui de nuvens da primeira geração, com propostas padronizadas, para infraestruturas virtualizadas altamente flexíveis com maior liberdade para seus usuários. A Figura 1 ilustra a nova abstração no contexto de plataformas virtuais para hypervisors, e não apenas VMs. Observe, nessa figura, a nomenclatura para os níveis de virtualização: L0 representa o hypervisor puro, L1 representa os hypervisors guests e L2 representa as VMs convidadas.

Figura 1. Ilustração simples de hypervisors tradicionais versus hypervisors de aninhamento
Ilustração simples de hypervisors tradicionais versus hypervisors de aninhamento

Essa alteração cria a capacidade de, além de empacotar VMs para novas infraestruturas, empacotar conjuntos de VMs com seu hypervisor, simplificando a habilidade dos usuários de infraestruturas de nuvem privada de migrar funcionalidades (seja de maneira estática ou dinâmica) para infraestruturas de nuvem pública. Essa alteração é exibida na Figura 2, com a conversão do hypervisor privado para o hypervisor guest na nuvem aninhada.

Figura 2. Hypervisor guest e hypervisors host na nuvem aninhada
Hypervisor guest e hypervisors host na nuvem aninhada

Nuvens da próxima geração: apresentando a virtualização aninhada

A virtualização aninhada não é um conceito novo, mas algo que foi implementado há tempos no hypervisor IBM ® z/VM® . O sistema operacional IBM System z ® é, em si, um hypervisor que virtualiza não apenas processadores e memória, mas também armazenamento, ajudas de hardware de rede e outros recursos. O hypervisor z/VM representa a primeira implementação de virtualização aninhada prática com ajuda de hardware para desempenho. Além disso, o hypervisor z/VM oferece suporte a qualquer profundidade de aninhamento de VMs (com gasto adicional, evidentemente). Mais recentemente, as plataformas x86 foram orientadas em direção à ajuda de virtualização com base nos modelos de uso crescentes para a técnica.

O primeiro hypervisor para hardware do produto a implementar a virtualização aninhada foi o KVM. Essa adição ao KVM foi realizada no projeto Turtles da IBM e permitiu a execução de diversos hypervisors não modificados sobre o KVM - ele próprio sendo um hypervisor, como um ajuste do kernel do Linux® . O projeto Turtles foi motivado, em parte, pelo desejo de usar hardware do produto de um modo que a IBM fosse pioneira para os sistemas operacionais IBM System p ® e System z. Nesse modelo, o servidor executa como um hypervisor integrado e permite ao usuário executar o hypervisor de sua escolha sobre ele. A abordagem chamou a atenção da comunidade de virtualização, uma vez que as capacidades (modificações ao KVM) agora fazem parte do kernel principal Linux.


Arquitetura para virtualização aninhada

A virtualização aninhada apresenta problemas exclusivos, nunca vistos antes. Iremos explorar alguns desses problemas e de que maneira foram solucionados no KVM.

Virtualização de processador

Uma desvantagem ao suporte à virtualização atual nas arquiteturas de processador é o foco em uma virtualização de dois níveis (VMs empilhadas em um único hypervisor). O projeto Turtles estende esse suporte, por meio do processo simples de multiplexação. Lembre-se da Figura 1 , na qual há três níveis (L0 como o hypervisor host, L1 como o hypervisor guest e L2 como a VM convidada). Com os processadores atuais, L0 e L1 são manipulados de maneira eficiente, mas a eficiência é perdida em L2. Em vez de manter essa pilha rígida, o projeto Turtles multiplexa entidades em L1 e, essencialmente, permite ao hypervisor host multiplexar o hypervisor e as VMs guests em L1. Portanto, em vez de virtualizar as instruções de virtualização, as ajudas de hardware disponíveis no processador são usadas de maneira eficiente para fornecer suporte às três camadas (consulte a Figura 3).

Figura 3. Multiplexando convidados no hypervisor host (L0)
Multiplexando convidados no hypervisor host (L0)

Porém, explorar os ativos de virtualização do processador não foi o único obstáculo. Iremos explorar alguns dos outros problemas e suas soluções no KVM.

A virtualização aninhada apresenta alguns problemas interessantes nesse espaço. Observe que a virtualização tradicional aborda parcialmente o conjunto de instruções, executando diretamente determinadas instruções no processador e emulando outras por meio de traps. Na virtualização aninhada, outro nível é apresentado, no qual certas instruções continuam a executar diretamente no hardware e outras são capturadas em trap, mas gerenciadas em uma camada ou outra (com a sobrecarga de realizar a transição entre as camadas).

Essa configuração expôs os pontos fortes e fracos nas implementações de virtualização do processador, como foi descoberto no projeto Turtles. Uma dessas áreas foi o gerenciamento de estruturas de controle de VM (VMCSs). Na implementação da Intel, ler e gravar essas estruturas envolve instruções privilegiadas que requerem diversas saídas e entradas através das camadas da pilha aninhada. Essas transições aumentam a sobrecarga, que se manifesta como perda de desempenho. A implementação da AMD gerencia VMCS por meio de leituras e gravações de memória regulares, o que significa que, quando um hypervisor guest (L1) modifica um VMCS da VM guest (L2), o hypervisor host (L0) não precisa intervir.

Sem suporte do processador para aninhamento, a abordagem do Turtles à multiplexação também minimiza transições entre camadas. As transições em virtualização ocorrem por meio de instruções especiais para entrar ou sair de VMs (VMexit e VMentry) e são de alto custo. Determinadas saídas requerem que o hypervisor L1 seja envolvido, mas outras condições (como interrupções externas) são manipuladas unicamente por L0. Minimizar algumas das transições de L2 a L0 a L1 resulta em um melhor desempenho.

MMU e virtualização de memória

Antes da ajuda de tabela de página em processadores modernos, os hypervisors emulavam o comportamento da unidade de gerenciamento de memória (MMU). As VMs guests criavam tabelas da página guest para fornecer suporte à sua conversão de endereços virtuais do guest em endereços físicos do guest. O hypervisor mantinha tabelas de página de sombra para converter endereços físicos do guest em endereços físicos do host. Isso exigiu mudanças de trap para as tabelas de página, para que o hypervisor fosse capaz de gerenciar as tabelas físicas na CPU.

A Intel e a AMD solucionaram esse problema por meio da adição de tabelas de página bidimensionais, chamadas tabelas de página estendida (EPTs) pela Intel e tabelas de página aninhada (NPTs) pela AMD. Essas ajudas permitem que as tabelas de página secundárias convertam endereços físicos do guest em endereços físicos do host (enquanto as tabelas de página tradicionais continuam a fornecer suporte à conversão de guest virtual a físico).

O projeto Turtles apresentou três modelos para lidar com o aninhamento. O primeiro, e menos eficiente, é o uso de tabelas de página de sombra sobre tabelas de página de sombra. Essa opção é usada quando o hypervisor guest e o hypervisor host mantêm as tabelas de sombra, e somente se as ajudas de hardware não estiverem disponíveis. O segundo método usa tabelas de sombra sobre as tabelas de página bidimensionais, que são gerenciadas por L0. Embora mais eficiente, as falhas de página na VM guest resultam em diversas saídas de L1 e sobrecarga. O método final virtualiza as duas tabelas de página bidimensionais para o hypervisor L1. Emulando as tabelas de página secundárias em L1 (em que L0 usa EPT/NPT físicas), há menos saídas de L1 e menos sobrecarga. Essa inovação do projeto Turtles foi chamada de paginação multidimensional.

Virtualização de dispositivo de E/S

Virtualizar dispositivos de E/S pode ser um dos aspectos de maior custo da virtualização. A emulação (conforme fornecido por QEMU) é o aspecto de menor custo, em que abordagens como paravirtualização (que tornam o guest ciente e coordenam a E/S com o hypervisor) podem melhorar o desempenho geral. O esquema mais eficiente usa ajudas de hardware, como AMD I/O MMU (IOMMU) para fornecer a conversão transparente dos endereços físicos do guest em endereços físicos do host (para operações como acesso direto à memória [DMA]).

O projeto Turtles melhorou o desempenho, fornecendo ao guest L2 o acesso direto aos dispositivos físicos disponíveis para L0. O hypervisor do host L0 emula um IOMMU para o hypervisor guest L1. Essa abordagem minimiza as saídas do guest, resultando em sobrecarga reduzida e melhor desempenho.


Desempenho aninhado

O aninhamento no KVM foi considerado sobrecarga insignificante, dependendo do modelo de uso. As cargas de trabalho que conduzem saídas da VM (como processamento de interrupção externa) tendem a ser os piores transgressores, mas as otimizações na KVM resultam em uma sobrecarga de 6% a 14%. Essa sobrecarga é razoável, dadas as novas capacidades fornecidas pela virtualização aninhada. É provável que os avanços nas arquiteturas do processador aprimorem isso ainda mais.


Onde é possível pode encontrar virtualização aninhada?

Atualmente, diversos hypervisors possuem suporte para virtualização aninhada, embora não seja tão eficiente como poderia ser. A Linux KVM possui suporte para aninhamento em processadores habilitados para virtualização recente. O hypervisor Xen também foi modificado para fornecer suporte à virtualização aninhada. Por esse motivo, a comunidade de software livre se modificou rapidamente para adotar essa capacidade e seus modelos de uso em potencial.

Do ponto de vista da produção, é seguro dizer que essa capacidade está nos estágios iniciais do desenvolvimento. Além disso, a virtualização de ajuste de escala com aninhamento implica em um carregamento mais pesado no host físico e, portanto, deve usar servidores com processadores mais eficientes.

Observe, também, que é impossível realizar a virtualização aninhada em outros contextos. Em um artigo OpenStack recente, o aninhamento foi demonstrado usando VirtualBox como o hypervisor host e QEMU (fornecendo emulação) como guest. Embora essa não seja a configuração mais eficiente, o artigo demonstra a capacidade básica em um hardware mais simples. Consulte os Recursos para obter detalhes adicionais.


Outros aplicativos

Um hypervisor como parte padrão em um firmware em um desktop ou servidor poderá ser habitual no futuro. Esse modelo de uso implica que o hypervisor integrado possa oferecer suporte a um sistema operacional (como uma VM) ou outro hypervisor da escolha do usuário.

O usuário desse tipo de hypervisor também possui suporte para novos modelos de segurança (pois o hypervisor existe sob o código do usuário e do hacker). Esse conceito foi usado originalmente para fins mal-intencionados. O rootkit "Blue Pill" foi uma façanha de Joanna Rutkowska, que inseriu um hypervisor thin sob uma instância em execução de um sistema operacional. Rutkowska também desenvolveu uma técnica chamada Red Pill que podia ser usada para detectar quando um "Blue Pill" era inserido sob um sistema operacional em execução.


Avançando um pouco mais

O projeto Turtles comprovou que a virtualização aninhada de hypervisors não era apenas possível, mas também eficiente sob diversas condições, usando o hypervisor KVM na área de teste. O trabalho continuou com KVM e, atualmente, é um modelo para a implementação de aninhamento em um hypervisor, com suporte para a execução de diversos hypervisors guests ao mesmo tempo. À medida que as arquiteturas de processador atingem esses novos requisitos, a virtualização aninhada pode ser um modelo de uso comum no futuro, não apenas em servidores empresariais em ofertas de nuvem da próxima geração, mas também em desktops e servidores do produto.

Recursos

Aprender

  • The Turtles Project: Design and Implementation of Nested Virtualization é uma leitura útil sobre como o IBM Research Haifa e o IBM Linux Technology Center modificaram e otimizaram a KVM para fornecer suporte à virtualização aninhada. Além disso, a Apresentação de OSDI sobre Turtles também é interessante.
  • O artigo Architecture of Virtual Machines , de R. P. Goldberg, foi uma das primeiras definições de VMs recursivas. Essa transcrição é bastante antiga (de 1973), mas vale a pena ler.
  • Blue Pill e Red Pill foram apresentados por Joanna Rutkowska em 2006. Blue Pill era uma abordagem de malware à inserção de um hypervisor thin sob um sistema operacional em execução, como um rootkit. O código de origem para Blue Pill nunca foi divulgado publicamente.
  • A Linux KVM foi o primeiro hypervisor a ser tornado a linha principal para o kernel Linux. A KVM é um hypervisor eficiente com qualidade de produção, amplamente usado na comunidade de virtualização. É possível saber mais sobre KVM em Discover the Linux Kernel Virtual Machine (M. Tim Jones, developerWorks, abril de 2007).
  • Como outra demonstração da flexibilidade do kernel Linux, as modificações para KVM convertem Linux de um kernel de servidor e desktop em um hypervisor com recursos completos. Saiba mais em Anatomia de um Hypervisor Linux (M. Tim Jones, developerWorks, maio de 2009).
  • O OpenStack é uma oferta de nuvem de Infraestrutura como Serviço que faz uso da virtualização aninhada. No artigo Computação em Nuvem e Armazenamento com OpenStack , é possível visualizar uma demonstração da virtualização aninhada com emulação (executando QEMU em VirtualBox).
  • Nos recursos de desenvolvedor da nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão criando os seus projetos de implementação de nuvem.
  • Siga o developerWorks no Twitter. Também é possível seguir este autor no Twitter em M. Tim Jones.
  • Acompanhe Demos do developerWorks variando de demonstrações de instalação e configuração de produto para iniciantes até funcionalidades avançadas para desenvolvedores experientes.

Obter produtos e tecnologias

  • Consulte as imagens do produto disponíveis para o IBM SmartCloud Enterprise.
  • Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.

Discutir

  • Participe da Comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing
ArticleID=834664
ArticleTitle=Virtualização Aninhada para a Nuvem da Última Geração
publish-date=09172012