Computação em nuvem: Classes de virtualização
Existem várias abordagens diferentes para a — ou classes de — virtualização, cada uma delas adequada para suas próprias situações específicas.
Kai Hwang, Jack Dongarra, Geoffrey Fox
Adaptado de "Distributed and Cloud Computing: From Parallel Processing to the Internet of Things” (Syngress, uma publicação da Elsevier)
Em termos gerais, existem três classes típicas de arquitetura de VM (máquina virtual): o hipervisor, a virtualização baseada em host e a paravirtualização, que são diferenciadas pela posição da camada de virtualização. O hipervisor também é conhecido como VMM (Virtual Machine Monitor).
Arquitetura do hipervisor
O hipervisor dá suporte à virtualização no nível do hardware em dispositivos bare-metal, como CPU, memória, disco e interfaces de rede. O software do hipervisor situa-se exatamente entre o hardware físico e o SO. Essa camada de virtualização é conhecida como VMM ou hipervisor.
O hipervisor fornece hiperchamadas para os SOs e aplicativos convidados. Um hipervisor pode assumir uma arquitetura de microkernel, como o Microsoft Hyper-V. Ele também pode assumir uma arquitetura de hipervisor monolítica como o VMware ESX para a virtualização de servidores.
Um hipervisor de microkernel inclui apenas as funções básicas e inalteráveis (como gerenciamento da memória física e agendamento do processador). Os drivers de dispositivos e outros componentes alteráveis ficam fora do hipervisor. Um hipervisor monolítico implementa todas as funções acima, incluindo as dos drivers de dispositivos.
Portanto, o tamanho do código de um hipervisor de microkernel é menor que o de um hipervisor monolítico. Essencialmente, um hipervisor deve ser capaz de converter dispositivos físicos em recursos virtuais dedicados ao uso pela VM implantada.
A arquitetura do Xen
O Xen é um programa hipervisor de software livre desenvolvido pela Universidade de Cambridge. Os componentes básicos de um sistema Xen são o hipervisor, o kernel e os aplicativos. A organização dos três componentes é importante.
O Xen é um hipervisor de microkernel, que separa a política do mecanismo. O hipervisor Xen implementa todos os mecanismos, deixando a política para ser tratada pelo Domínio 0. Ele não inclui nenhum driver de dispositivo nativamente. Ele fornece apenas um mecanismo pelo qual um SO convidado pode ter acesso direto aos dispositivos físicos.
Como resultado, o tamanho do hipervisor Xen é mantido razoavelmente pequeno. O Xen fornece um ambiente virtual localizado entre o hardware e o SO. Vários fornecedores estão no processo de desenvolvimento de hipervisores Xen comerciais; entre eles, estão o Citrix XenServer e o Oracle VM.
Assim como outros sistemas de virtualização, muitos SOs convidados podem ser executados sobre o hipervisor. No entanto, nem todos os SOs convidados são criados de forma igual, e um em particular controla os outros. O SO convidado, que tem a capacidade de controle, é chamado de Domínio 0, e os outros são chamados de Domínio U. O Domínio 0 é um SO convidado privilegiado do Xen. Ele é carregado pela primeira vez quando o Xen é inicializado sem quaisquer drivers de sistema de arquivos disponíveis. O Domínio 0 é projetado para acessar o hardware diretamente e gerenciar os dispositivos. Portanto, uma das responsabilidades do Domínio 0 é alocar e mapear recursos de hardware para os domínios convidados (os domínios do Domínio U).
Por exemplo, o Xen é baseado no Linux e seu nível de segurança é C2. Sua VM de gerenciamento se chama Domínio 0, que tem o privilégio de gerenciar outras VMs implementadas no mesmo host. Se o Domínio 0 for comprometido, o hacker pode controlar todo o sistema.
Portanto, no sistema de VM, você precisa de políticas de segurança para aumentar a segurança do Domínio 0. O Domínio 0, comportando-se como uma VMM, permite que os usuários criem, copiem, salvem, leiam, modifiquem, compartilhem, migrem e revertam VMs tão facilmente quanto ao manipular um arquivo. Infelizmente, isso também adiciona problemas de segurança durante o ciclo de vida do software e o tempo de vida dos dados.
Tradicionalmente, você pode enxergar o tempo de vida de uma máquina como uma linha reta. O estado atual da máquina é um ponto que progride de forma monótona à medida que o software é executado. Durante esse tempo, você faz alterações de configuração, instala software e aplica patches.
Em tal ambiente, o estado da VM é semelhante a uma árvore: a qualquer ponto, a execução pode ir para N ramificações diferentes, nas quais várias instâncias de uma VM podem existir em qualquer ponto dessa árvore a qualquer momento. As VMs têm permissão para reverter para estados anteriores em sua execução (por exemplo, para corrigir erros de configuração) ou para reiniciar a execução a partir do mesmo ponto muitas vezes (por exemplo, como um meio de distribuição de conteúdo dinâmico ou circulação de uma imagem de sistema “ao vivo”).
Conversão binária com virtualização total
Dependendo das tecnologias de implementação, a virtualização de hardware pode ser classificada em duas categorias: virtualização total e virtualização baseada em host.
A virtualização total não precisa modificar o SO do host. Ela depende da conversão binária para interceptar e virtualizar a execução de certas instruções sensíveis e não virtualizáveis. Os SOs convidados e seus aplicativos consistem em instruções não críticas e críticas.
Em um sistema baseado em host, são usados um SO de host e um SO convidado. Uma camada de software de virtualização é criada entre o SO de host e o convidado.
Virtualização total
Com a virtualização total, as instruções não críticas são executadas diretamente no hardware, enquanto as instruções críticas são descobertas e substituídas por interceptações no VMM para emulação pelo software. Ambas as abordagens, de hipervisor e VMM, são consideradas virtualização total.
Por que apenas as instruções críticas são interceptadas no VMM? Isso ocorre porque a conversão binária pode significar uma grande sobrecarga de desempenho. As instruções não críticas não controlam o hardware nem ameaçam a segurança do sistema, mas as críticas, sim. Portanto, a execução de instruções não críticas no hardware podem não só promover a eficiência, como também garantir a segurança do sistema.
Essa abordagem foi implementada pela VMware e por muitas outras empresas de software. O VMM examina o fluxo de instruções e identifica as instruções privilegiadas e sensíveis a controle e comportamento. Quando essas instruções são identificadas, elas são interceptadas no VMM, que emula o comportamento das instruções. O método usado nessa emulação se chama conversão binária.
Portanto, a virtualização total combina a conversão binária e a execução direta. O SO convidado é totalmente separado do hardware subjacente. Consequentemente, o SO convidado não sabe que está sendo virtualizado.
O desempenho da virtualização total pode não ser ideal, porque envolve a conversão binária, o que é razoavelmente demorado. A virtualização total de aplicativos com E/S intensiva é um desafio. A conversão binária emprega um cache de código para armazenar instruções ativas convertidas a fim de aumentar o desempenho, mas isso aumenta o custo da utilização de memória. O desempenho da virtualização total na arquitetura x86 geralmente representa de 80% a 97% do da máquina host.
Virtualização baseada em host
Uma arquitetura de VM alternativa é instalar uma camada de virtualização por cima do SO do host. Esse SO ainda é responsável por gerenciar o hardware. Os SOs convidados são instalados e executados sobre a camada de virtualização. Os aplicativos dedicados podem ser executados nas VMs. Alguns outros aplicativos também podem ser executados diretamente com o SO do host.
Essa arquitetura baseada em host tem algumas vantagens diferenciadas. Primeiro, o usuário pode instalar essa arquitetura de VM sem modificar o SO do host. O software de virtualização pode usar o SO do host para fornecer drivers de dispositivo e outros serviços de nível baixo. Isso simplifica o design da VM e facilita sua implantação.
Em segundo lugar, a abordagem baseada em host é atraente para muitas configurações de máquina de host. Em comparação com a arquitetura de hipervisor/VMM, o desempenho da arquitetura baseada em host também pode ser baixo. Quando um aplicativo solicita acesso ao hardware, isso envolve quatro camadas de mapeamento, o que reduz o desempenho consideravelmente. Quando o ISA (Internet Security and Acceleration) de um SO convidado é diferente do ISA do hardware subjacente, a conversão binária deve ser adotada. Embora a arquitetura baseada em host tenha flexibilidade, o desempenho é muito baixo para ser útil na prática.
Paravirtualização
A paravirtualização precisa modificar o SO convidado. Uma VM paravirtualizada fornece APIs especiais que exigem modificações substanciais no SO em aplicativos de usuário. A redução do desempenho é uma questão crítica de um sistema virtualizado. Ninguém quer usar uma VM se ela for muito mais lenta do que uma máquina física.
Você pode inserir a camada de virtualização em posições diferentes de uma pilha de software da máquina. No entanto, a paravirtualização tenta reduzir a sobrecarga da virtualização, e assim aumenta o desempenho modificando apenas o kernel do SO convidado. Quando os SOs convidados são paravirtualizados, eles têm a assistência de um compilador inteligente para substituir as instruções de SO não virtualizáveis por hiperchamadas.
O processador x86 tradicional oferece quatro anéis de execução de instruções: os anéis 0, 1, 2 e 3. Quanto menor o número do anel, mais alto o privilégio da instrução sendo executada. O SO é responsável por gerenciar o hardware e as instruções privilegiadas a serem executadas no Anel 0, ao passo que os aplicativos do nível do usuário são executados no Anel 3. O melhor exemplo de paravirtualização é a VM baseada em kernel (KVM).
Quando o processador x86 é virtualizado, uma camada de virtualização é inserida entre o hardware e o SO. De acordo com a definição de anéis do x86, a camada de virtualização também deveria ser instalada no Anel 0. Instruções diferentes no Anel 0 podem causar alguns problemas. No entanto, quando o kernel do SO convidado é modificado para virtualização, ele não pode mais ser executado diretamente no hardware.
Embora a paravirtualização reduza a sobrecarga, ela gera outros problemas. Primeiro, sua compatibilidade e portabilidade podem ser duvidosas, porque ela precisa dar suporte também ao SO não modificado. Em segundo lugar, o custo da manutenção de SOs paravirtualizados é alto, porque eles podem exigir profundas modificações no kernel do SO.
Finalmente, a vantagem de desempenho da paravirtualização varia muito, devido às diferenças das cargas de trabalho. Comparada com a virtualização total, a paravirtualização é relativamente simples e mais prática. O principal problema da virtualização total é seu desempenho fraco na conversão binária. Acelerar a conversão binária é difícil. Portanto, muitos produtos de virtualização empregam a arquitetura de paravirtualização. O popular Xen, o KVM e o VMware ESX são bons exemplos disso.
O KVM é uma ferramenta de paravirtualização assistida por hardware que aprimora o desempenho e dá suporte a SOs convidados não modificados, como Windows, Linux, Solaris e outras variantes do Unix.
Esse é um sistema de paravirtualização do Linux, parte do kernel do Linux versão 2.6.20. O kernel do Linux existente realiza o gerenciamento da memória e as atividades de agendamento. O KVM faz o restante, o que o torna mais simples do que o hipervisor, que controla toda a máquina.
Ao contrário da arquitetura de virtualização total, que intercepta e emula instruções privilegiadas e sensíveis em tempo de execução, a paravirtualização lida com essas instruções no momento da compilação. O kernel do SO convidado é modificado para substituir as instruções privilegiadas e sensíveis por hiperchamadas para o hipervisor ou o VMM. O Xen é um exemplo dessa arquitetura de paravirtualização.
As instruções privilegiadas são implementadas por hiperchamadas ao hipervisor. Depois de substituir as instruções por hiperchamadas, o SO convidado modificado emula o comportamento do SO convidado original. Em um sistema Unix, uma chamada ao sistema envolve uma rotina de serviço ou interrupção. As hiperchamadas aplicam uma rotina de serviço dedicada no Xen.
Esses vários tipos diferentes de arquitetura de virtualização têm diferentes pontos fortes e fracos. Examine cada um deles e você poderá aplicar a arquitetura mais adequada ao seu ambiente.
.jpg)
Kai Hwang é professor de engenharia de computação da Universidade do Sul da Califórnia e professor emérito visitante da Universidade de Tsinghua, na China. Ele é doutor em EECS pela Universidade da Califórnia de Berkeley. Ele tem várias publicações nas áreas de arquitetura de computador, aritmética digital, processamento paralelo, sistemas distribuídos, segurança da Internet e computação em nuvem.
.jpg)
Jack Dongarra é um renomado professor universitário de engenharia elétrica e ciência da computação da Universidade do Tennessee, membro da equipe de pesquisa do Oak Ridge National Laboratory e membro da Universidade de Manchester. Dongarra foi um dos pioneiros das áreas de benchmark para supercomputadores, análise numérica, solvers de álgebra linear e computação de alto desempenho e tem muitas publicações nessas áreas.
.jpg)
Geoffrey Fox é professor de informática, computação e física e reitor associado de estudo graduado e pesquisa da faculdade de informática e computação da Universidade de Indiana. Ele concluiu seu doutorado na Universidade de Cambridge, no Reino Unido. Fox é muito conhecido por seu trabalho abrangente e suas muitas publicações em arquitetura paralela, programação distribuída, computação de grade, serviços Web e aplicativos de Internet.
©2011 Elsevier Inc. Todos os direitos reservados. Impresso com permissão da Syngress, uma publicação da Elsevier. Copyright 2011. “Distributed and Cloud Computing: From Parallel Processing to the Internet of Things” de Kai Hwang, Jack Dongarra e Geoffrey Fox. Para obter mais informações sobre esse título e outros livros similares, visite elsevierdirect.com.