Faculdade de Engenharia Elétrica e de Computação
Departamento de Computação e Automação Industrial
Introdução à Computação em Nuvem
Lucio Agostinho Rocha
Campinas, SP Junho, 2013
Atualmente é comum que muitas aplicações sejam acessadas pela Internet e mantidas em
datacen-ters. Essas aplicações são oferecidas de forma transparente para seus usuários, ou seja, com pouca
(ou nenhuma) referência à infraestrutura física que as mantêm. A Computação em Nuvem (Cloud
Computing) surge como um modelo de computação para acessar serviços oferecidos sob demanda,
com transparência de localidade e provisão dinâmica de recursos (servidores, armazenamento, apli-cações e quaisquer outros serviços) [1] [2]. Vaquero et al. [3] definem a Computação em Nuvem como:
“Um conjunto de recursos virtuais facilmente usáveis e acessíveis tais como hard-ware, plataformas de desenvolvimento e serviços. Estes recursos podem ser dina-micamente reconfigurados para se ajustarem a uma carga variável, permitindo a otimização do uso dos recursos. Este conjunto de recursos é tipicamente explorado através de um modelo pay-per-use com garantias oferecidas pelo provedor através de SLAs.”(Tradução do autor)
A Computação em Nuvem ganhou mais destaque quando passou a ser utilizada como um modelo empresarial. Existe uma grande diversidade de aplicações que podem executar na nuvem, cada uma delas com os mais diferentes requisitos. Em função disso, existe o desafio por parte dos provedores de serviços em atender aos requisitos desse conjunto diverso de aplicações. Nesse modelo, uma fatia do poder computacional da rede é oferecida, reduzindo os custos para fornecer uma infraestrutura interna para prover os serviços. Esse modelo também baseia-se na alocação de recursos apenas pelo período de utilização dos serviços contratados. Isso permite que as empresas façam cotações dinâ-micas sobre os períodos de melhor custo x benefício para uso de tais serviços. Como exemplo, pode ser economicamente mais vantajosa a transferência de uma grande quantidade dados quando menos usuários utilizarem a rede do provedor de serviços.
O NIST (National Institute of Standards and Technology) [4] é uma agência governamental do Departamento de Comércio dos Estados Unidos, que tem o objetivo de promover padrões de TIC com o objetivo de ampliar a segurança da informação. De acordo com a especificação do NIST [5], as seguintes características podem ser enumeradas:
1. Oferta de serviços sob demanda: alocação dinâmica dos serviços requisitados (resource
poo-ling), sem interação humana com o provedor dos serviços;
2. Amplo acesso aos recursos computacionais: por meio de diversos protocolos padronizados, para uma grande variedade de dispositivos como computadores pessoais, laptops, dispositivos móveis, tablets, entre outros;
3. Resource Pooling: por meio de um modelo multi-locatário, recursos computacionais são recidos para múltiplos clientes. Existe uma abstração da localidade onde os serviços são ofe-recidos, com relação aos servidores, datacenters, ou mesmo região geográfica. Os recursos oferecidos incluem processamento de alto desempenho, armazenagem, largura de banda, me-mória, entre outros.
4. Elasticidade: os serviços devem ser alocados e desalocados rapidamente, apenas no decorrer da requisição do usuário. Para este, tem-se a ilusão de uma gama infinita de recursos disponíveis;
5. Medição: a infraestrutura deve oferecer mecanismos para dinamicamente otimizar a disponi-bilidade de recursos com o uso de mecanismos de medição, gerência e controle do uso dos recursos computacionais oferecidos.
Outras características comuns de ambientes que utilizam Computação em Nuvem [2] são:
• Escalabilidade: o aumento do número de usuários não implica em redução do desempenho da nuvem, ou seja, mais recursos são alocados internamente, ou de domínios parceiros para su-prir a demanda e manter o desempenho. A oferta de recursos sob demanda viabiliza a oferta de serviços para um número maior de usuários. Os recursos serão alocados apenas pelo pe-ríodo contratado, reduzindo a subutilização da rede de serviços. Essa característica implica na elasticidade da oferta de recursos para muitos usuários concorrentes;
• Modelo pay-per-use: cobrança proporcional ao uso dos recursos. A Computação em Nuvem é um exemplo de utility computing (computação vista como uma utilidade) porque a oferta desses serviços é similar a outros tradicionais, onde o usuário paga pelo fornecimento de eletricidade, água, gás natural ou redes de telefonia;
• Virtualização: O usuário tem a ilusão de que interage com os recursos de um host real quando, na verdade, utiliza um ambiente abstrato que simula o acesso físico do host no qual estão hospedados.
Na Computação em Nuvem um provedor de serviços pode participar de um ou mais modelos para a oferta de serviços em nuvem. Ainda assim, a administração do domínio é responsável por controlar a infraestrutura, sistema operacional, servidores, operações de persistência, e demais requisitos para a oferta de serviços para uma grande quantidade de usuários concorrentes. Os modelos para prestação de serviços em nuvem são os seguintes [6] [4]:
• IaaS (Infrastructure as a Service): destaca a importância da infraestrutura na provisão de ser-viços. O provedor é capaz de oferecer uma infraestrutura de armazenagem, processamento e demais recursos de hardware e software de maneira transparente para o usuário. O aluguel de máquinas virtuais de acordo com os requisitos do usuário quanto a CPU, memória, espaço em disco e largura de banda, é um exemplo de serviço do tipo IaaS. Exemplo de provedores: Amazon EC2 [7] e FlexiScale [8];
• PaaS (Platform as a Service): destaca a importância do framework para o desenvolvimento de aplicações na nuvem. O usuário é capaz de desenvolver suas próprias aplicações, respei-tando o modelo de desenvolvimento, comunicação, armazenagem, linguagens de programação e demais serviços oferecidos pelo framework da nuvem. Exemplo de provedores: Ning [9], BungeeLabs [10] e Microsoft Windows Azure Platform [11];
• SaaS (Software as a Service): O provedor de serviços habilita a execução de aplicações para uso exclusivo do cliente, ou aplicações para uso do cliente fornecidas pelo próprio provedor ou terceiros, tais como aplicativos de e-mail empresariais, grupos de discussão, ferramentas para edição de sites e demais aplicações que são compartilhadas por um grande número de usuários, tais como formulários Web, ferramentas de suporte (Help Desk), workflows empresariais, entre outros. Exemplo de provedores: Zoho [12], Salesforce [13], Google Apps [14] e Facebook [15].
• Nuvem Privada: centrada no domínio de uma organização. A motivação é não expôr publi-camente interfaces para interação com serviços privados do domínio, mas sim fornecer acesso apenas para usuários e administradores que façam parte do domínio em questão;
• Nuvem Pública: disponível para uso público em geral, com interfaces públicas acessíveis pela Internet;
• Nuvem Comunitária: ambientes onde os participantes de uma comunidade específica compar-tilham de uma infraestrutura com aspectos comuns (por exemplo, relativo à segurança, padrões de comunicação, interfaces, etc.). Essa infraestrutura possui uma escala menor do que a nuvem pública, porém maior do que uma nuvem privada;
• Nuvem Híbrida: uma combinação de infraestruturas com modelos distintos (pública, privada, comunitária), onde cada infraestrutura se mantém independente das demais, porém comparti-lham serviços entre si, e têm a preocupação quanto à portabilidade das aplicações que executam nos diferentes domínios.
A infraestrutura de rede é fundamental para aplicações que executam na nuvem. Na Computação em Nuvem cria-se um ambiente para suportar o desenvolvimento e a disponibilização de aplicações na Internet. Do ponto de visto do usuário, prioriza-se o esforço para a criação e uso de aplicações, mais do que a configuração e a atualização da infraestrutura física ou do conjunto de frameworks de suporte ao desenvolvimento.
2
Virtualização
Em essência, a virtualização consiste em imitar um comportamento, seja por extensão ou subs-tituição de um recurso por outro [16]. A virtualização também é definida como um sistema ou um método de dividir os recursos computacionais em múltiplos ambientes isolados [17]. O conceito de virtualização remonta à virtualização de recursos em sistemas operacionais. Como exemplo, solu-ções de alto nível como interfaces gráficas, bibliotecas e APIs são exemplos de recursos de software que tornam transparente para o usuário o acesso aos recursos de hardware, em especial, o acesso aos periféricos de entrada e saída, ou seja, cria-se a ilusão no sistema operacional de que se tem a intera-ção direta com os recursos de hardware. Diz-se também que a virtualizaintera-ção é uma metodologia para dividir os recursos de um computador em múltiplos ambientes de execução conhecidos como máqui-nas virtuais, aplicando conceitos de particionamento, time-sharing, simulação completa ou parcial de máquina, emulação, QoS, entre outros [16].
Portanto, a virtualização é uma técnica para ocultar características físicas de recursos computaci-onais, da forma na qual os sistemas, aplicações e end users interagem com esses recursos.
A virtualização remonta às décadas de 60 e 70, com a introdução da linguagem de programação Java e o uso comum de mainframes na época [16]. Com o uso de máquinas virtuais era possível executar e migrar aplicações legadas entre plataformas distintas, desde que houvesse uma versão da
máquina virtual para a plataforma alvo. A principal motivação era ampliar e melhorar a utilização e o compartilhamento de recursos nos mainframes.
Com a redução do custo do hardware em meados da década de 80, ocorreu uma mudança do foco de processamento centralizado em mainframes para o processamento distribuído em microcom-putadores. O modelo cliente-servidor foi estabelecido para a computação distribuída, reduzindo a necessidade da virtualização para a integração de recursos computacionais. A redução do custo de aquisição do hardware e do compartilhamento de informações fizeram a virtualização entrar em hi-bernação por alguns anos [18].
Apenas em meados da década de 90, com o aumento do poder de processamento do hardware e dos computadores pessoais (PCs), a virtualização voltou a ganhar destaque com produtos como o VMware [19], UML (User Mode Linux) [20], Xen [21], KVM (Kernel-based Virtual Machine) [22] e VirtualBox [23]. De certa forma, esses produtos trazem o conceito de virtualização como uma alternativa para executar diversos sistemas operacionais sem a necessidade de se aumentar proporci-onalmente o número de hosts físicos que os mantêm. Isso implica em redução dos custos relativos à aquisição de hardware, infraestrutura física, consumo de energia, refrigeração, suporte e manutenção de vários hosts.
A virtualização é recomendada para consolidar múltiplos servidores em um mesmo host, isolar diferentes aplicações de usuários em um mesmo host, executar/depurar softwares e sistemas operaci-onais construídos para uma arquitetura em outra, além de simplificar a instalação de infraestruturas de software em diferentes domínios, e testar aplicativos em hardwares não existentes.
O sistema operacional que executa o software de virtualização é conhecido como Host. O sistema operacional virtualizado é conhecido como Guest. Múltiplos Guests podem executar no mesmo Host, sem interferência entre eles. O kernel do Host fornece a API para suportar múltiplos espaços do usuário, conhecidos como Virtual Environments, na VM Guest. Cada Guest possui a virtualização de arquivos, bibliotecas de sistema, usuários e grupos, árvore de processos (com PIDS virtualizados), rede virtualizada (Guests possuem seus próprios IP, tabelas de roteamento, e demais atributos de rede próprios).
Com o crescente avanço da virtualização e do poder de processamento do hardware, fabricantes de processadores como a AMD [24] e a Intel [25] passaram a incluir no hardware de suas CPUs o suporte para a virtualização, com a finalidade de aumentar o desempenho das aplicações virtualizadas. A extensão nos processadores Intel recebe o nome de Intel VT (ou Vanderpool Technology). A AMD, por sua vez, desenvolveu a extensão AMD-V (ou Pacifica), também conhecida como AMD SVM (Secure Virtual Machine). O desempenho das aplicações virtualizadas é limitado pelo hardware que mantêm as máquinas virtuais, pela rede de comunicação e pelos mecanismos de emulação utilizados pelo software que gerencia essas aplicações. Os tipos de implementação mais comuns são [26]:
• Máquina virtual de processo: esse tipo de máquina virtual é um programa que executa em modo usuário (user mode) do sistema operacional. Em arquitetura de computadores [16] o conjunto de instruções geralmente é dividido em pelo menos duas categorias: instruções privilegiadas e não-privilegiadas. As instruções privilegiadas são reservadas para que programas com alto privilégio, como o sistema operacional, por exemplo, executem a manipulação de recursos de hardware (processador, memória principal, dispositivos de armazenamento, registradores de propósito especial, entre outros), entrada/saída e interrupções. Por outro lado, os programas de baixo privilégio podem executar apenas instruções de máquina não-privilegiadas. A arquitetura
supervisor (supervisor mode) em ambientes não virtualizados.
O ambiente da máquina virtual fornece instruções abstratas que precisam ser interpretadas para executar as instruções de máquina não-privilegiadas. No processo de interpretação ocorre a busca, decodificação e análise de instrução por instrução, antes de cada uma delas ser execu-tada no sistema hospedeiro. Como exemplo, a JVM (Java Virtual Machine) é um exemplo de máquina virtual de processo.
A Microsoft CLI (Common Language Infrastructure) [27], base do framework .NET, é um outro exemplo de implementação de virtualização que possibilita o uso de diferentes linguagens de alto nível sem a necessidades de serem reescritas para a plataforma em que executam. O código compilado não corresponde a nenhuma arquitetura real específica, mas sim a uma máquina virtual definida de acordo com um ambiente que utiliza seu compilador e uma linguagem de alto nível. No entanto, é necessário que exista uma implementação da máquina virtual para cada arquitetura real sob a qual essa máquina executa.
• Virtual Appliance: são máquinas virtuais que possuem um conjunto de softwares (sistema ope-racional, base de dados, aplicativos, configuração de rede, entre outros) pré-configurados e prontos para o uso;
• Hypervisor 1 , Monitor de Máquina Virtual (VMM (Virtual Machine Monitor)) ou Máquina
Virtual de Sistema: uma camada de software entre o hardware e o sistema operacional da má-quina virtual. Nessa abordagem o acesso aos recursos de hardware é protegido pela camada de software que mantém uma ou mais máquinas virtuais. Em razão disso, o hypervisor deve ser instanciado sempre que a máquina virtual for inicializada. O sistema operacional que executa nessas máquinas virtuais utiliza as instruções não-privilegiadas oferecidas pelo hypervisor. O
hypervisor fornece os recursos de software para compartilhar a CPU com múltiplos sistemas
operacionais [28]. Portanto, o hypervisor executa em supervisor mode e controla o acesso aos recursos compartilhados pelas máquinas virtuais. O escalonamento de recursos é feito de forma similar ao escalonamento de processos pelo sistema operacional, com a alocação de ci-clos do processador para cada VM. Como uma VM executa em user mode, caso seja disparada uma intrução privilegiada na VM, o comportamento esperado pelo sistema operacional seria o de disparar uma interrupção, para um posterior tratamento por uma rotina de manipulação da interrupção, rotina essa que faz parte do sistema operacional. No entanto, o hypervisor pre-cisa manipular essa interrupção, emulando a execução da instrução privilegiada. Hypervisors que executam diretamente sobre o hardware são conhecidos como tipo 1 (por exemplo, Xen);
Hypervisors que precisam executar sobre um sistema operacional são chamados tipo 2 (por
exemplo, VirtualBox). O hypervisor também é responsável por gerenciar a emulação de dis-positivos, tais como processador, memória RAM, disco rígido, interfaces de entrada/saída tais como drive de CD/DVD, mouse, teclado, vídeo (quantida de bytes para a memória de vídeo), interfaces de rede, entre outros.
1Nota: foi mantida a escrita original da palavra em inglês, por ser a mais usual. O plural também foi mantido de
As CPUs modernas suportam múltiplos níveis de privilégios de código, conhecidos como ring
levels [29]. Apenas o código executando no nível de privilégio mais alto pode executar instruções
privilegiadas. Os processadores Intel possuem 4 ring levels:
• 0 para o modo supervisor, utilizado pelo kernel do sistema operacional; • 1 e 2 não são, a priori, utilizados pelo sistema operacional;
• 3 para aplicações (por exemplo, processos e threads) executadas no nível de usuário.
Geralmente, o hypervisor executa no ring level 0, e o sistema operacional do Guest executa no ring level 1 (isso porque apenas as instruções que executam no nivel 0 podem executar instruções privilegiadas. Como as VMs geram instruções que não estão nesse nível, o ’truque’ é encaminhá-las para o hypervisor, que se encontra no nível 0 com mais alta prioridade). A execução de todo o sistema operacional Guest em um ring maior do que o 0 é conhecido como ring de-privileging. Essa técnica implica em algumas particularidades para o correto tratamento de instruções, com maiores detalhes em [30].
Como qualquer outra tecnologia, a virtualização possui uma nomenclatura própria para distinguir os seus componentes:
• Máquina Virtual: é uma camada de software que simula um computador real (físico) e que é capaz de executar instruções como se fosse a máquina física. De acordo com [31], existem dois tipos para essa VM: 1) Máquina virtual de sistema: possui uma plataforma completa de sistema que suporta a execução de um sistema operacional. 2) Máquina virtual de processo: fornece abstrações e recursos para executar um único processo.
• Computador Host (Hospedeiro): é aquele que utiliza a virtualização de software para executar máquinas virtuais;
• Sistema Operacional Hóspede (Guest Operating System) é um sistema operacional que executa em uma máquina virtual.
A conexão em rede entre máquinas virtuais é baseada em interfaces virtuais de rede, com a associ-ação de um endereço MAC (Medium Access Control) específico para cada uma delas. Por outro lado, a solução tipicamente utilizada para a comunicação em rede entre o host hospedeiro e as máquinas virtuais é a configuração da interface de rede física do hospedeiro em modo promíscuo, criando-se uma bridge para multiplexar o criando-seu uso entre as diversas máquinas virtuais que criando-se conectam a ela. Uma bridge atua na camada 2 do modelo OSI, correspondendo à camada de enlace do modelo TCP/IP (Transmission Control Protocol/Internet Protocol). Com uma configuração de bridge não são feitas considerações relativas ao endereço de rede na qual a interface está configurada. Para o encaminha-mento de pacotes são utilizadas técnicas de flooding e de verificação do endereço MAC. Quando o dispositivo destino é localizado seu endereço MAC é guardado em uma tabela de MAC associada à
bridge, para posterior roteamento.
Em sistemas operacionais, um processo é definido como a instância de um programa (software) em execução [32]. Cada processo, quando instanciado, executa sobre um processador lógico (vir-tual). O sistema operacional utiliza escalonadores para alternar entre os processadores lógicos sobre
síntese, a região de dados armazena as variáveis globais; a região de texto armazena as instruções de execução; a região de heap realiza a alocação dinâmica de memória; finalmente, a região de pilha mantém o endereço de retorno de chamadas de função, mantém as variáveis locais das funções, além de servir para a passagem de parâmetros. Os registradores Program Counter(PC) e Stack Pointer(SP) são utilizados para a execução de um processo. O primeiro informa a próxima instrução a ser exe-cutada enquanto que, o segundo, realiza funções de pilha, ou seja, mantém o endereço de retorno da função executada, além de suas variáveis locais e parâmetros. No chaveamento de contexto esses registradores participam, junto com todos os outros registradores da CPU, do escalonamento de pro-cessos, criando-se a ilusão de que vários processos são executados ao mesmo tempo. Nesse âmbito, um processo pode ser visto como uma máquina virtual de baixo nível que reúne todo um conjunto de
software e hardware para a sua execução [16].
A abordagem da virtualização é bem mais ampla do que a simples execução de múltiplas ins-tâncias de sistemas operacionais em máquinas virtuais. Na virtualização da infraestrutura da rede as interfaces de rede virtuais possuem endereços MAC e IP específicos, com suporte aos meios de en-caminhamento de pacotes para interfaces reais, tais como broadcast, unicast e multicast, este último sendo importante para aplicações do tipo P2P e difusão de áudio e vídeo. Dessa forma é possível prover a interconexão das interfaces virtuais com a interface física do host hospedeiro e com ou-tros dispositivos físicos tais como roteadores e switches, além do tratamento de QoS no tráfego dos pacotes oriundos desses dispositivos virtuais na rede.
A base para a comunicação em redes virtuais é baseada nos drivers TUN (network tunnel) para o roteamento de pacotes e no driver TAP (network tap) para a criação de bridges [33]. Os drivers TAP emulam a camada 2 (envio/recepção de Ethernet frames na camada de enlace), e os drivers TUN emulam a camada 3 (envio/recepção de pacotes IP na camada de rede) da pilha de protocolos TCP/IP, gerenciando a recepção e a transmissão dos pacotes entre os dispositivos virtuais e os dispositivos físicos na rede. Por outro lado, os dispositivos de interconexão, tais como roteadores e switches são emulados no processo de virtualização.
Para administradores de rede é comum pensar em alternativas para aumentar a taxa de utilização de seus servidores, mantendo diversas máquinas virtuais em uma mesma máquina física. Essa alter-nativa é conhecida como consolidação de servidores e tem o objetivo de aumentar a utilização do hardware com a consequente redução da gerência de diversos hosts (ou seja, redução dos custos ope-racionais), redução do consumo de energia, redução de espaço físico, além da criação de ambientes mais flexíveis com a oferta de serviços para diversos sistemas operacionais.
A seguir são enumeradas as principais técnicas de virtualização para a criação de máquinas virtu-ais. A descrição dessas técnicas no modelos em camadas tem o objetivo de destacar o nível relativo ao ring no qual a VM se encontra, e as setas duplas as interfaces adicionais necessárias e que devem ser fornecidas pela solução de virtualização que implementa o modelo.
• Virtualização total (ou completa)[29]: uma camada de software fornece uma abstração genérica do hardware, sem necessidade de modificar o sistema operacional que executa na máquina virtual. O controle de acesso aos recursos físicos do sistema é gerenciado pelo hypervisor, bem como a conversão para o sistema físico dos diferentes mecanismos de acesso à disco, memória, periféricos, entre outros, realizados pelo sistema operacional virtual. A Fig. 1 mostra o modelo
em camadas desse tipo de virtualização.
Fig. 1: Modelo em Rings da Virtualização Completa.
• Paravirtualização: De acordo com [34] a paravirtualização busca remover todas as caracte-rísticas da arquitetura de suporte (como a x86, por exemplo) que sejam difíceis de virtualizar, e substitui-las com operações que se comunicam diretamente com a camada de virtualização. Segundo [29], esse modelo de virtualização envolve modificar o núcleo do sistema operacional
Guest para que ele se comunique diretamente com o hypervisor, sem a tradução binária de
to-das as instruções, como normalmente ocorre na virtualização completa. O hypervisor, por sua vez, também fornece interfaces para outras operações críticas do núcleo do sistema operacional, tais como tratamento de interrupções e gerenciamento de memória. Segundo [35], o sistema operacional Guest recebe modificações para interagir diretamente com os drivers do hypervisor na execução de instruções de máquina privilegiadas, ou seja, instruções que possam alterar o estado do sistema. Outro ponto é que os dispositivos de hardware são acessado por drivers da própria VM, sem o uso de drivers genéricos que inibam a capacidade total do dispositivo. Com os atuais avanços no suporte à virtualização em hardware por parte dos fabricantes de CPUs (principalmente Intel e AMD) a paravirtualização tem-se mostrado tão eficiente quanto a virtu-alização total [16]. A paravirtuvirtu-alização também abrange de forma mais adequada os recursos disponíveis no hardware, ao invés da abstração genérica oferecida pela virtualização total. O exemplo mais comum é o do Xen, que é um exemplo de virtualização do tipo 1 (ou vir-tualização nativa) [34]. O hypervisor Xen executa no topo de um sistema operacional Host. As VMs em Xen são conhecidas como domínios. Quando o sistema inicia, o hypervisor Xen inicia o domínio 0 (zero), que tem acesso aos dispositivos de forma privilegiada. As máquinas
Fig. 2: Modelo de Paravirtualização com Xen (baseado em [34].
Fig. 3: Modelo em Rings da Paravirtualização.
virtuais de níveis de domínio superiores a zero acessam os dispositivos por meio da máquina virtual do domínio 0. Em termos práticos, Xen é configurado como um patch ao kernel de distribuições Linux convencionais. Cada VM se torna um processo do sistema operacional. O sistema operacional é responsável por controlar e gerenciar as funções que o domínio 0 realiza. As versões mais recentes do Xen possuem drivers de dispositivos nativos que foram retirados do hypervisor e mantidos no domínio 0, de forma a se ter o acesso mais próximo do hardware, como mostra a Fig. 2. UML é outro exemplo de sistema que utiliza a paravirtualização. A Fig. 3 mostra o modelo em camadas desse tipo de virtualização.
• Suporte à virtualização de hardware (Virtualização Assistida por Hardware) [29]: o hardware fornece recursos voltados especificamente para virtualização. As tecnologias AMD-V e Intel
VT suportam a virtualização assistida por hardware para os processadores da arquitetura x86. O hypervisor encontra-se no ring level 0, mas no modo root mode (nas arquiteturas Intel, vmx root). O kernel do sistema operacional virtualizado das VMs também se encontra no ring level 0, mas no modo non-root mode (nas arquiteturas Intel, vmx non-root). O resultado é um ganho de desempenho, pois o software do hypervisor tem controle mais próximo ao hardware da CPU [36]. A Fig. 4 mostra o modelo em camadas desse tipo de virtualização. Essa virtualização reduz a necessidade de utilizar sistemas paravirtualizados para prover sistemas operacionais proprietários.
Fig. 4: Modelo em Rings da Virtualização Assistida por Hardware.
• Virtualização no nível do sistema operacional (Containers) [37]2: execução de múltiplos
am-bientes de execução isolados e que compartilham um mesmo núcleo de sistema operacional. Obtém-se um desempenho próximo ao nativo e características de gerência dinâmica de recur-sos são oferecidas como vantagens mas, por outro lado, não permite que diferentes núcleos sejam executados por diferentes sistema operacionais ao mesmo tempo. Exemplo: FreeBSD Jail [38], Solaris Zones/Containers [39], Linux-VServer [40], OpenVZ [17] e Virtuozzo [41]. A Fig. 5 mostra o modelo em camadas desse tipo de virtualização.
Fig. 5: Modelo em Rings da Virtualização em Containers.
Em síntese, a emulação utiliza software para simular o hardware para o sistema operacional Guest que executa no software. Como se pode notar, essa alternativa possui limitações para a tradução dinâmica de código, além de oferecer um baixo desempenho. Por outro lado, a virtualização nativa, ou virtualização completa, é quando um hypervisor tipo 2 é utilizado para permitir o acesso parcial ao hardware, ou para simular um subconjunto de recursos do hardware, com a finalidade de permitir a execução completa de um sistema operacional. Na paravirtualização, o sistema operacional executa no hypervisor, o que confere maior desempenho. Microsoft Hyper-V e VMware ESX Server também são exemplos de sistemas que utilizam a paravirtualização [42] [43].
Apesar de não haver uma definição consensual [44], no contexto da virtualização é importante aprofundar a distinção entre termos emulação, simulação e virtualização. De acordo com [45] [42], esses termos são definidos como segue:
• Emulação: é a reprodução do comportamento de um sistema em outro. Além disso, é um termo utilizado para descrever a operação de um software desenvolvido para simular um determinado hardware, como por exemplo um processador, disco rígido, interfaces de rede, entre outros, di-ferentes dos que estão executando o emulador [46]. Como exemplo, o software DOSBox [47] é capaz de emular o sistema operacional DOS (Disk Operating System) em sistemas operacionais Linux, permitindo a execução de programas nativos de um sistema operacional em outro. Ou-tro exemplo é o emulador QEMU (Open Source Processor Emulator) [48]. Quando executado como emulador ele pode executar programas e sistemas operacionais feitos para uma
arquite-tura (por exemplo, ARM) em outra (por exemplo, PC). Isso é feito com a tradução dinâmica de código.3 Outro exemplo de emulador é o Bochs [49] que emula todas as instruções de pro-cessadores x86, incluindo dispositivos de entrada/saída e memória. Portanto, um emulador é capaz de executar os mesmos programas como se eles executassem no sistema original, produ-zindo as mesmas saídas para as mesmas entradas geradas em ambos os sistemas. A emulação torna possível executar qualquer sistema operacional não-modificado, desde que o sistema de emulação suporte o sistema a ser emulado. A principal desvantagem da emulação é o seu baixo desempenho comparado com a execução nativa do sistema operacional em hardware próprio. • Simulação: é uma imitação de algum sistema real. Também pode ser informalmente definido
como um tipo de emulação mais precisa. Segundo [16], “um simulador é um programa que implementa um modelo de sistema recebendo parâmetros de entrada e condições iniciais de contorno e serve para auxiliar na predição e análise do comportamento do sistema simulado”. Os simuladores MobileSim [50] e Stage [51] são exemplos de programas que imitam o compor-tamento de robôs móveis, reproduzindo com precisão as ações de deslocamento no ambiente, leitura de sensores tais como sonares e laser, além de oferecerem um ambiente adequado para testes e análise de programas criados para interagir com robôs reais;
• Virtualização: em termos de computação, é a emulação de hardware em uma plataforma de
software. Com a emulação de hardware ocorre a simulação de hardware via software. No
entanto, ao contrário da emulação, as instruções são executadas no hardware real da máquina física, ao contrário do que ocorre na emulação onde as instruções são executadas em um proces-sador emulado [46]. Como exemplo, diversos sistemas operacionais podem ser virtualizados em um mesmo host físico. Existem muitos tipos de virtualização para diferentes propósitos:
– Software: seja para manter múliplos ambientes virtualizados no mesmo host físico com
máquinas virtuais, e/ou para reservar virtual environments distintos apenas para a execu-ção de aplicações [52].
– Mobile: permite executar sismultaneamente múltiplos sistemas operacionais, ou máquinas
virtuais, em dispositivos móveis. Esse tipo de virtualização é mais exigente quanto à capacidade de processamento e quanto aos requisitos de hardware do dispositivo móvel. Como exemplo, o iPhone [53] suporta esse tipo de virtualização.
– Desktop: exibição de desktops remotos, seja de forma textual (por exemplo, Web SSH)
ou gráfica [54] [55].
– Network: combinação de recursos de software e hardware de rede em uma entidade
co-nhecida como rede virtual. São admitidos espaços de endereçamento de rede virtualiza-dos, com regras de firewall, tabelas de roteamento, endereçamento IP, entre outros requi-sitos de rede associados às interfaces de rede virtualizadas. A infraestruturas de interco-nexão da rede também pode ser virtualizada com software especializado, aproveitamento as características de software para a configuração lógica de dispositivos (por exemplo, VLANs em switchs).
3Nota: ARM é uma arquitetura com um conjunto reduzido de instruções de 32-bits RISC (Reduced Instruction Set Computer) desenvolvida pela ARM Holdings.
possuir diferentes versões do mesmo programa instalados na mesma máquina. Como exemplo pode ser citado o software Cameyo [52], que é um produto para virtualização de aplicações para platafor-mas Microsoft Windows.
3
Considerações sobre virtualização
A seguir são enumeradas algumas considerações quanto ao uso da virtualização:
• Segurança: as máquinas virtuais são isoladas entre si, o que garante que a falha de um serviço em uma delas não comprometa as demais. No entanto, o uso do hypervisor é um ponto crítico pois uma falha nesse setor pode comprometer todas as instâncias de máquinas virtuais ativas. Por outro lado, o uso de softwares atualizados auxiliado pela gerência rigorosa dessa camada de software propicia a oferta de um ambiente tão seguro e confiável quanto se cada sistema operacional e/ou serviço fosse executada exclusivamente em um único host servidor;
• Flexibilidade: a consolidação de servidores traz como vantagem direta a oferta de serviços para diversos sistemas operacionais. Diversas ferramentas open source e comerciais adicionam elementos para suporte à migração de máquinas virtuais, estatísticas e contabilidade de uso, gerência do sistema, balanceamento de carga, controle de acesso, entre outros; Outra caracte-rística interessante é a opção de salvar um snapshot do estado atual da máquina, para posterior reinício do ambiente.
• Custo: De acordo com [18], a redução dos custos de TI pode variar de 29% a 64% no que se refere à economia de espaço físico, energia, estrutura de refrigeração, a gerência de múlti-plas máquinas virtuais Com relação à paravirtualização não se torna prático modificar sistemas operacionais proprietários ou mesmo antigos. Nesses casos, o hypervisor deve confiar na vir-tualização de hardware. Em ambientes onde existe a necessidade de manter diversos sistemas operacionais, o uso de hypervisors é considerado uma alternativa viável, porém é necessário manter um controle do ciclo de vida de cada recurso virtual ativo [56].
• Desempenho: A virtualização é uma alternativa para suprir grandes demandas por recursos computacionais. Por outro lado, o uso de hypervisors adiciona uma camada extra de software o que gera um custo maior de processamento em relação a soluções não-virtualizadas. Outro fator limitante para o desempenho é a qualidade do serviço de interconexão oferecido para os ser-viços virtualizados. Aplicações mais exigentes quanto a operações de E/S são potencialmente mais propensas a terem um menor desempenho em ambientes virtualizados.
• Redes virtuais: Uma possibilidade inerente é o uso do hardware computacional virtualizado. Nesse contexto, as redes virtuais são baseadas na emulação das interfaces de rede junto ao
hypervisor. Ao invés de tratar a comunicação de rede entre máquinas virtuais no nível da
inter-face física do host que as mantém, pode-se virtualizar a própria infraestrutura de rede das VMs. Nesse sentido, o tráfego de rede utiliza um comutador virtual (ou vSwitch). Esse comutador se comporta como um switch físico convencional, mas é virtualizado pelo hypervisor. Uma
solução em software open source é o Open vSwitch [57], que é um switch virtual multicamadas (licença Apache 2.0). Além de ser utilizado como switch para redes virtuais, ele também pode ser utilizado em conjunto com redes físicas. Está disponibilizado a partir do kernel 2.6.15 do Linux, e suporta várias soluções de virtualização tais como Xen, KVM, Proxmox VE e Vir-tualBox. Essa solução também tem sido integrada em diversas plataformas de nuvem, como OpenStack, OpenQRM e OpenNebula.
4
Open Virtualization Format
Para manter a portabilidade na distribuição e especificação de VMs a indústria de virtualização (em especial as empresas Dell, HP, IBM, Microsoft, VMware e Citrix) definiu o formato OVF (Open Virtualization Format) [58].
A especificação OVF é aberta e neutra em termos de plataforma de virtualização e descreve um formato para empacotamento e distribuição do software a ser executado em VMs [58]. No entanto, VMs também podem ser importadas e exportadas utilizando o formato OVF. Essa especificação tem o objetivo de garantir portabilidade na distribuição de VMs e suas aplicações, entre múltiplas plata-formas de virtualização. As seguintes vantagens podem ser enumeradas [58]:
• VMs podem ser instaladas nos hosts apenas se o hardware especificado em OVF estiver dispo-nível;
• Inclusão de licenças de uso especificadas em documentos de metadados junto ao pacote da distribuição;
• Especificação da compressão de dados para transferências de grandes imagens virtuais;
• Verificação de integridade de imagens baseada em infraestruturas de chave-pública, com um esquema para a gerência de licenças de software;
• Descrição padronizada dos recursos virtuais disponíveis nas VMs. Um pacote OVF deve conter os seguintes arquivos [58]:
• Um arquivo descritor do tipo metadados: contém a descrição, em formato XML, dos recursos virtuais de uma VM, tais como interfaces de rede, discos virtuais, tipo de sistema operacional instalado, requisitos de hardware virtual (CPU, memória RAM, drive de CD-ROM, entre ou-tros), configurações de CPU, ordem de boot, endereços MAC virtuais, configurações de áudio e vídeo, entre outros;
• Nenhum ou um arquivo de manifest: contém a descrição do algoritmo utilizado para criptogra-far os dados do pacote. O algoritmo SHA-1 (Secure Hash Algorithm version 1) é adotado por padrão;
• Nenhum ou um arquivo de certificado: As informações do arquivo manifest podem ser assina-das e mantiassina-das em um arquivo de certificado X.509 codificado em base 64;
sobre como interpretar o formato da imagem virtual. Múltiplos formatos de disco virtual são suportados, mas é recomendado o uso de imagens em formato VMDK (Virtual Machine Disk Format). Como exemplo, o VirtualBox cria dois arquivos VMDK: um que contém informações adicionais da VM (nome da VM, tamanho em bytes, versão do VMware), e outro com a própria imagem virtual.
• Nenhum, um ou mais arquivos de recursos adicionais: por exemplo, arquivo de imagem ISO a partir do qual o sistema operacional foi instalado na VM.
5
Soluções para Virtualização
A seguir é feita uma descrição sucinta das principais soluções de virtualização gratuitas disponí-veis para usuários não-comerciais.
5.1
VMware
Os produtos da empresa VMware [19] utilizam uma combinação de técnicas de execução direta de instruções em hardware e técnicas de tradução binária para oferecer o suporte à virtualização em seus produtos. A empresa disponibiliza vários produtos, gratuitos e comerciais, para o suporte à virtualização e à computação em nuvem. Dentre eles, destacam-se [59]:
5.1.1 Desktop Editions
VMware Workstation: suporte para a criação de múltiplas VMs em um mesmo host cliente. Possui
suporte para a geração de snapshots. Um snapshot é uma cópia em memória do estado corrente da VM, de forma que uma VM possa ser iniciada a partir desse estado. Com um snapshot o usuário possui um gerenciador de snapshots, a partir do qual se tem a opção de alternar entre diferentes estados de uma mesma VM, o que torna o produto VMWare Workstation ideal para ambientes de teste e desenvolvimento de softwares. As VMs criadas com essa versão de software da VMWare podem ser transportadas para os produtos servidores, tais como o VMWare Server. No entanto, o produto VMWare Workstation não é recomendado para ser usado em servidores por questões de desempenho.
VMware Fusion: Ambiente virtual para a execução de sistema operacional Windows em
platafor-mas Macintoch.
VMware Player: É um software para a criação e execução de múltiplas VMs em um mesmo host
cliente. No entanto, não há suporte para a gerência de múltiplos snapshots ou clonagem de VMs.
5.1.2 Server Editions
VMware ESX Server é um produto comercial para aplicações empresariais que suporta a execução
forma a obter um melhor desempenho para a execução das VMs, sem a necessidade de se ter outro sistema operacional instalado no host servidor.
VMWare Server é um produto de virtualização gratuito para pequenos e médios servidores, e que
depende de um sistema operacional Linux ou Windows instalado no host servidor.
Além dos produtos citados, destacam-se outros como: VirtualCenter que é destinado para a ge-rência centralizada de servidores VMWare; VMotion que é utilizado para a migração ’in live’ de servidores virtuais para servidores físicos, sem a interrupção dos serviços; e VMware Converter que é utilizado para converter sistemas operacionais que executam em hosts físicos em máquinas virtuais.
5.2
Xen
Xen [21] é um hypervisor ou Virtual Machine Monitor (VMM), que é uma camada de software que encaminha instruções privilegiadas de VMs diretamente no hardware do computador. Xen ofe-rece virtualização por meio da paravirtualização e suporta diversos tipos de arquiteturas de processa-dores: x86, x86-64, Itanium, Power PC e ARM. O projeto Xen é open source e foi desenvolvido pelo
Systems Research Group da University of Cambridge Computer Laboratory. De acordo com [60],
mais do que emular os dispositivos de hardware existentes, como é realizado com a virtualização completa, Xen expõe um conjunto de abstrações de dispositivos de E/S. A transferência de dados é feita via Xen, utilizando técnicas de memória compartilhada e bufferização assícrona.
O software Xen é um hypervisor que é instanciado logo após o bootloader do sistema operaci-onal. Uma VM Linux conhecida como Domain 0 (ou Dom 0) fornece recursos virtualizados para domínios de usuários (ou Dom U) no Host. Existe suporte para um amplo conjunto de sistemas operacionais, entre os quais: Linux, Windows, NetBSD, Solares, entre outros. Xen é utilizado em diversos ambientes de nuvem como na Amazon EC2, Nimbus e Eucalyptus.
5.3
KVM
KVM (Kernel-based Virtual Machine) [22] é uma solução open source, sob licença GPL, para vir-tualização completa em Linux, para arquiteturas de processadores x86 e x64. A virvir-tualização com o KVM utiliza um driver no kernel do Linux. Por meio de um módulo carregado junto ao kernel (2.6.17 e superiores) do sistema operacional, o kvm.ko, é fornecida uma infraestrutura de virtualização para os processadores Intel e AMD. Cada máquina virtual instanciada possui seus próprios recursos de hardware virtualizados. KVM exige exige o suporte à virtualização por hardware na CPU, e utiliza o escalonador e o gerenciamento de memória regulares do Linux. KVM não suporta paravirtualização para CPU, mas sim para dispositivos de entrada/saída, como disco e interface de rede, utilizando a in-terface VirtIO, sem a necessidade de simular todo o kernel do sistema operacional para realizar essas funções. A proposta do KVM têm despertado atenção porque interage diretamente com o kernel do sistema operacional e pode se comunicar diretamente com o hardware. Como consequência, tende a oferecer um desempenho melhor do que as tecnologias de virtualização no nível de aplicação. KVM utiliza uma versão modificada do software QEMU para a emulação de dispositivos como processos separados no espaço do usuário [28].
Fig. 6: Interface Gráfica de Gerência do Virsh para o KVM.
5.4
QEMU
QEMU (Open Source Processor Emulator) [48] [61] é um virtualizador e emulador open source genérico. Ele oferece suporte para a execução completa de sistemas operacionais, fornecendo uma camada de abstração de software na qual o sistema operacional pode executar como se estivesse aces-sando diretamente o processador legado e/ou periféricos. Uma grande diversidade de processadores e sistemas operacionais é suportada. QEMU também suporta a emulação em user mode na qual progra-mas compilados em uma arquitetura de CPU podem ser executados em outra. Por exemplo, QEMU pode ser utilizado para executar os emuladores Wine e Dosemu.
Quando utilizado em conjunto com o KVM, por meio da habilitação do módulo kqemu no kernel do sistema operacional, obtém-se um ganho maior de desempenho. QEMU não precisa de exten-sões de módulos no kernel do sistema operacional, nem de extenexten-sões para o suporte à virtualização na CPU, e nem de uma camada de software de um hypervisor. A emulação de disco em formato QCOW permite a captura de snapshots de execução de VMs, e migração em tempo de execução (live
5.5
VirtualBox
VirtualBox é um hypervisor, open source e gratuito para usuários não-comerciais, que suporta VMs com sistemas operacionais de diversas distribuições. O software VirtualBox é multi-plataforma e pode ser instalado em sistemas Linux, Windows, Mac e Solaris [23]. O hypervisor do VirtualBox precisa de um sistema operacional base para executar (hypervisor tipo 2).
Fig. 7: Hypervisor do VirtualBox e máquina virtual instanciada.
5.6
Virsh
Virsh [62] é uma interface de linha de comando open source, que encapsula as funcionalidades da API Libvirt para o gerenciamento (principalmente para operações de iniciar, finalizar, pausar, sus-pender, resumir e listar o status) de máquinas virtuais QEMU, KVM e Xen. Mais especificamente é um toolkit em linguagem C que executa em modo assíncrono, uma vez que o tempo para a re-alização de operações de gerência não é imediato (por exemplo, início e finre-alização de uma VM).
Toolkits adicionais includem o virt-viewer, para a visualização gráfica das VMs, acessível por meio
de um protocolo VNC; e virt-manager, que também é um programa com interface gráfica, escrito em linguagem Python, para a gerência de VMs, como mostra a Fig 6.
Libvirt [62] é uma API open source para a gerência de VMs, que possui interfaces para os prin-cipais sistemas de virtualização: Xen, QEMU, KVM, LXC, OpenVZ, hypervisors VMware ESX e GSX, hypervisors VMware workstation e Player, User Mode Linux e VirtualBox. Libvirt utiliza o serviço libvirtd para intermediar a comunicação com o sistema de virtualização, e arquivos XML para definir o hardware virtualizado. Além do suporte convencional para a gerência de VMs, essa
Fig. 8 ilustra alguns exemplos de interação oferecidas pela API. Trata-se portanto de um “canivete suiço” para as mais populares soluções de virtualização.
libvirt libvirt libvirt libvirt libvirtd Guest Guest QEMU Guest Guest Kernel Guest Guest DomU Dom0
virsh virt−viewer virt−manager Userspace Tools Xen Hypervisor QEMU QEMU KVM Module Kernel KVM QEMU
Fig. 8: Ilustração das diversas formas de uso da biblioteca Libvirt [44].
5.7
OpenVZ
OpenVZ [17] é um sistema open source de virtualização, sob a licença GPL, baseado em
contai-ners para sistemas operacionais Linux. OpenVZ cria múltiplos contaicontai-ners isolados conhecidos como Virtual Environments (VE) para consolidação de servidores. Esse sistema de virtualização é a base
do Parallels Virtuozzo Containers, que é uma solução comercial [41].
O OpenVZ segue o conceito de ambientes virtuais no qual o ambiente de execução de programas é isolado dos demais. Esse ambiente mantém os sistema operacional Linux Guests isolados uns dos outros, ou seja, vários Linux Guests podem coexistir no mesmo servidor físico, mas todos eles devem executar sob um mesmo kernel. Para isso, o OpenVZ utiliza uma versão modificada do kernel do Linux convencional para adicionar as funções de virtualização, isolamento dos Guests, gerência de recursos e checkpoints (ou seja, gerar snapshots das VMs, onde o estado da VM é congelado e armazenado em disco). Também é suportada a migração de VMs. Para otimizar a instalação e uso de novos Guests, o OpenVZ também suporta templates de imagens de sistemas operacionais. Cada template contém um conjunto de pacotes pré-configurados.
5.8
LXC
Linux Containers (LXC) [63] [64] é um método de virtualização no nível do sistema operacio-nal, similar ao OpenVZ, mas sem a necessidade de se adicionar um patch ao kernel das distribuições Linux mais recentes (motivo pelo qual ele vem sendo adotado como alternativa ao OpenVZ). Múlti-plos ambientes virtuais (Virtual Environments - VE) conhecidos como containers podem executar no
mesmo host de forma similar ao comando chroot, que muda o diretório root do processo corrente e de seus processos filhos. Containers particionam os recursos oferecidos pelo sistema operacional em grupos isolados. O sistema operacional utiliza a técnica de time sharing para compartilhar os recursos entre todos os containers, utilizando o mesmo kernel [65]. Como vantagens, essa alternativa gera um baixo overhead de memória RAM e CPU, a execução de programas tem um desempenho próximo ao nativo, e se tem economia de espaço em disco. Por outro lado, a limitação de se utilizar um único
kernel entre todos os containers impede o uso de outros sistema operacional que não suportem o
mesmo kernel da máquina Host. Além disso, existem limitações para a migração de containers entre outros hosts, e problemas no kernel do Host são mais prejudiciais do que outras soluções de virtua-lização. LXC utiliza o software debootstrap, que é uma ferramenta que instala um conjunto mínimo de arquivos de um sistema operacional, realizando o acesso remoto aos repositórios da distribuição. Esse aplicativo instala apenas os arquivos principais que tornam o container funcional.
5.9
Linux-VServer
Trata-se de uma virtualização baseada em containers que adiciona um patch ao kernel atual da máquina Host [40].
A motivação para o uso de ambientes virtuais compartilhados em containers no mesmo host se deve ao fato de que grande parte das aplicações não requerem acesso ao hardware ou acesso em nível de super-usuário ao kernel do sistema operacional. Por conta disso, torna-se uma alternativa inte-ressante a execução de múltiplos espaços virtuais sobre um mesmo kernel, desde que esses espaços virtuais sejam separados uns dos outros, independentes entre si e seguros quanto ao acesso. Outra motivação é que o aumento de recursos da máquina host (adição de mais memória, dispositivos de E/S, interfaces de rede, entre outros) são disponibilizados para os containers com pouca ou nenhuma necessidade de configuração. Da mesma forma, um mesmo conjunto de aplicações pode ser atuali-zado e distribuídos para os containers de forma transparente. No entanto, existem as desvantagens de não se conseguir migrar o container para fora da máquina host, e de se ter que utilizar o mesmo
kernel em todos os containers.
O conceito do Linux-VServer baseia-se na criação de unidades de espaço do usuário conhecidas como Virtual Private Servers (VPS) com o uso de um mesmo kernel compartilhado.
5.10
User Mode Linux
O User Mode Linux (UML) é uma implementação do kernel do Linux que suporta arquiteturas de outros kernels de Linux. No entanto, versões mais recentes de kernel precisam ser modificadas para que possam ser agregadas ao kernel Linux que os suporta. São admitidos múltiplos sistema operacional Linux Guests sobre um mesmo kernel Linux, cada um deles isolado dos demais. Cada sistema operacional Guest comporta-se como um processo que executa no espaço do usuário, com seu próprio sistema de arquivos, árvore de diretórios, configurações de rede, e outros. Ao contrário de soluções de virtualização baseada em containers, não é necessário que as imagens possuam o mesmo
kernel do sistema operacional Host. Nas versões mais recentes kernel do Linux (2.6.x e posteriores)
o UML vem integrado à árvore principal dos fontes. Cada sistema operacional Guest é mantido por máquinas virtuais designadas para processadores de arquiteturas de 32 e 64 bits.
Xen Paravirtualização Não Sim
KVM Completa/Para/Assistida Não Sim
QEMU Completa Sim Não
VirtualBox Completa/Assistida Sim Sim
OpenVZ Containers Não Sim
LXC Containers Não Não
Linux-VServer Containers Não Não
UML Baseado em containers Não Não
Tab. 1: Tabela Comparativa com as Principais Ferramentas Gratuitas de Virtualização.
6
Soluções para Computação em Nuvem
O uso da virtualização não é um requisito para se ter um ambiente de nuvem, mas o seu uso traz muitas vantagens, desde ser uma alternativa para se preparar infraestruturas escaláveis com múltiplas VMs, até o suporte à migração de VMs com o objetivo de promover o balanceamento de carga de forma a ampliar a escalabilidade e a redução do consumo de energia. O modelo de uma infraestrutura com suporte à virtualização pode ser representado como ilustrado na Fig. 9. Em uma nuvem com suporte à virtualização, cada nó da rede é modelado como ilustrado nessa figura. Nesse modelo, o
hypervisor atua como uma camada de software entre o hardware (máquina física) e o sistema
ope-racional. Além de gerenciar a instanciação de múltiplas VMs, ele também oferece suporte para a
emulação de dispositivos, tais como processador, memória RAM, disco rígido, interfaces de E/S tais
como drive de CD/DVD, mouse, teclado, vídeo (quantida de bytes para a memória de vídeo), interfa-ces de rede, entre outros. O suporte à rede virtual (virtual networking) ocorre por meio da emulação de interfaces de rede, através da qual as VMs têm acesso à rede IP convencional. O hypervisor tam-bém oferece uma interface de gerência básica para o controle dos recursos virtuais que ele mantêm. No entanto, funcionalidades adicionais geralmente são desenvolvidas em outra camada de abstração. Em muitos casos, isso ocorre porque não se tem acesso ao código-fonte do hypervisor, ou porque a modificação do seu código-fonte original exige grande esforço.
Emulação de Dispositivo das VMs Gerenciamento VMn VM1 ... Virtual networking Máquina Física Hypervisor
No entanto, uma nuvem comporta centenas, e até milhares de nós que precisam ser gerenciados, seja para o balanceamento de carga das operações realizadas por usuários de domínios públicos/pri-vados, ou operações de cache e filtragem de pacotes de rede, por exemplo. A Fig. 10 ilustra o modelo genérico de uma infraestrutura de nuvem com suporte à virtualização, baseada em [28]. Nesse mo-delo, uma Infraestrutura Virtual de Gerência tem acesso a todos os nós do domínio privado da nuvem. O modelo não define quais níveis de gerência devem ser contemplados nessa camada, porém a maio-ria das soluções de virtualização em nuvem utiliza os seguintes serviços: cmaio-riação/remoção/atualização de recursos virtuais (CPU, memória, RAM, espaço em disco, entre outros) fornecidos para cada VM, suport para o controle do ciclo de vida de VMs, e alteração de parâmetros dos recursos virtuais. Di-versas interfaces de gerência tamem oferecem suporte para a configuração lógica dos servidores que hospedam as VMs. A Infraestrutura de Balanceamento de Carga é citada para oferecer suporte para a migração de VMs, cache em disco para serviços Web, e controle de acesso de usuários. Observa-se nesse modelo que as duas infraestruturas anteriores são independentes, ou seja, camadas adicionais de gerência podem ser agregadas sem intervenção nas anteriores. No entanto, esse modelo não define como deve ocorrer o reaproveitamento de recursos já oferecidos por uma camada, ou como novos serviços que interagem com a nuvem podem ser criados sem interferir nas funcionalidades das cama-das anteriores. A infraestrutura de rede física e de armazenagem é a base desse modelo, e garante a conectividade de rede dos servidores que mantém os recursos virtuais. Além disso, essa camada oferece o suporte para a armazenagem física de dados.
Gerência de VMs VM1 ... VMn VMM VNet MF ED Gerência de VMs VM1 ... VMn VMM VNet MF ED Gerência de VMs VM1 ... VMn VMM VNet MF ED Gerência de VMs VM1 ... VMn VMM VNet MF ED Gerência de VMs VM1 ... VMn VMM VNet MF ED Gerência de VMs VM1 ... VMn VMM VNet MF ED ... ... ...
Infraestrutura Virtual de Gerência
Infraestrutura de Rede Física e de Armazenagem de Dados Infraestrutura de Balanceamento de Carga
Fig. 10: Modelo Genérico de uma Infraestrutura de Nuvem.
Uma característica que normalmente ocorre em infraestruturas para nuvem é o uso de servidores dedicados para a virtualização. Dentre os principais quesitos que precisam ser considerados em uma infraestrutura de suporte à computação em nuvem podem ser listados:
2. suporte a múltiplos sistemas operacionais (R2); 3. tecnologias de virtualização suportadas (R3); 4. suporte à migração de VMs (R4);
5. suporte a interface OCCI (R5);
Solução R1 R2 R3 R4 R5
Amazon EC2 Sim Sim Xen Sim Sim
Eucalyptus Não Sim Xen, KVM Sim Sim
XCP Não Sim (parcial) Xen Sim Não
Nimbus Não Sim Xen, KVM Sim Sim
OpenNebula Sim Sim Xen, KVM, VMware Sim Sim
Proxmox Não Sim KVM, OpenVZ Sim Não
Abiquo Sim Sim diversos Sim Sim
Tab. 2: Comparação das Soluções de Nuvem quanto aos Requisitos Funcionais.
A Tab. 2 ilustra como esses quesitos são considerados junto às principais soluções de virtualização de código-fonte aberto disponíveis. Observa-se que o suporte à gerência de usuários (R1) é suportado na maioria delas e, quando não presente, encontra-se disponível nas versões comerciais; o quesito R2 depende do tipo de sistema operacional base, mas aparece bem resolvido nas soluções apresentadas. No entanto, a configuração nos sistemas Eucalyptus e XCP ainda exige a configuração manual, o que pode dificultar a gerência em ambientes de produção; o quesito R3 depende do sistema operacional base, e das funcionalidades que a infraestrutura da nuvem pretende oferecer. O uso da biblioteca
libvirt para Linux é uma solução aceitável para a gerência de VMs em múltiplas tecnologias de
virtualização. O quesito R4 aparece em todas as soluções. Quando se trata de uma rede interna, a solução adotada para a migração tem sido utilizar um sistema de arquivos de rede do tipo Network File System (NFS) e/ou similares. O quesito R5 diz respeito à interoperabilidade e também está presente, ou em estágio de desenvolvimento (Nimbus e OpenNebula), na maioria das soluções. XCP e Proxmox ainda não têm suporte a essa funcionalidade.
6.1
Amazon AWS
A Amazon [7] é uma das empresas pioneiras na oferta de serviços de computação em nuvem, e ainda se mantém presente para a oferta desses serviços tanto para usuários comerciais quanto para não-comerciais. Os serviços da Amazon Web Services (AWS) reúnem um conjunto de tecnologias baseadas na Web para interação com os serviços de nuvem da Amazon.
AWS é baseada em uma IaaS, com os serviços da Elastic Compute Cloud (EC2) e Simple Storage Service (S3), que utilizam interfaces baseadas em Serviços Web.
6.1.1 Amazon Elastic Cloud Compute (EC2)
Segundo o site da Amazon, a Amazon Elastic Compute Cloud (Amazon EC2) é um serviço web que fornece capacidade de computação redimensionável na nuvem.
Amazon EC2 fornece uma API de serviços web para gerenciar servidores virtuais na IaaS da Amazon. Os principais datacenters da Amazon EC2 estão localizados nos Estados Unidos e na Eu-ropa. Como característica, o usuário que possui uma conta em um datacenter não pode utilizar os serviços de outro. O sistema de virtualização padrão adotado pela Amazon é o Xen, com suporte à paravirtualização. O ambiente Xen permite a provisão/desprovisão dinâmica de recursos e isolamento dos ambientes dos servidores Guest dos usuários.
As imagens de servidores são iniciadas a partir de templates pré-configurados com o sistema ope-racional escolhido pelo usuário e alguns softwares adicionais. Essas imagens são conhecidas como
Amazon Machine Images (AMIs). O ambiente também possibilita criar imagens AMI
personaliza-das que podem ser posteriormente instanciapersonaliza-das. A administração dessas imagens é feita com o uso de serviços Web, mas existem extensões para browsers, como o Elasticfox, que pode ser usado para gerenciar AMIs a partir do Firefox.
Dois tipos de armazenagem estão disponíveis no ambiente EC2. O primeiro é um armazenamento temporário (ephemeral storage), e um armazenamento persistente em blocos, que atua como uma rede de armazenamento de dados de alta velocidade.
A estratégia para atribuição de endereços IPs é feita de forma controlada, uma vez que a quanti-dade de IPs públicos roteáveis é escassa. Todas as contas Amazon estão limitadas a 5 endereços IP públicos IPv4 roteáveis na Internet (chamados de Elastic IPs), por região [66]. Além disso, a Amazon AWS realiza tarifação quando esse endereço IP não estiver associado a uma instância em execução. Por padrão, cada VM é instanciada com um endereço IP privado e um endereço IP público. Tanto o endereço IP privado quanto o endereço IP público são exclusivos por instância.
6.1.2 Amazon S3
Amazon S3 é um serviço de nuvem para armazenagem de dados. Esse serviço é acessível em tempo real por meio da API de serviços Web da IaaS. A ideia é a de se ter um imenso diretório remoto para armazenamento de uma grande quantidade dados acessíveis por meio de uma URL única por usuário.
6.1.3 Amazon Simple Queue Service (SQS)
Amazon SQS é uma solução da Amazon para a computação em grades. O sistema é baseado no envio de mensagens de processamento que são enfileiradas pelo sistema e distribuídas para um conjunto de servidores. O processamento é assíncrono e o receptor aguarda o processamento da requisição. Além dos serviços apresentados, muitos outros têm sido desenvolvidos, com suporte às mais diversas linguagens de programação.
6.2
Eucalyptus
Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs to Useful
outros softwares open source, como solução de cloud para o Ubuntu Server Edition. Essa solução ficou conhecida como Ubuntu Enterprise Cloud (UEC). Em Fevereiro de 2011, a empresa Canonical oficialmente se juntou à iniciativa de outra plataforma para computação em nuvem conhecida como OpenStack [68] [69].
Eucalyptus suporta o uso dos hypervisors Xen, KVM, e VMware, porém a versão UEC suporta apenas o uso do KVM.
A arquitetura do Eucalyptus é ilustrada na Fig. 11. Os seus componentes são descritos a seguir: • Cloud Controller (CLC): é o front-end da infraestrutura. É responsável por processar
requisi-ções e decidir onde instanciar as VMs (decisões de placement). O acesso às funcionalidades do CLC pode ser feito por meio de interfaces HTTP, SOAP e REST. O CLC possui interfaces para Web Services compatíveis com os serviços da Amazon EC2/S3, para garantir interoperabili-dade com os serviços da Amazon fora da nuvem privada. Também é responsável por monitorar a disponibilidade de recursos e monitorar as instâncias de VMs em execução. Diversas ima-gens pré-configuradas do Ubuntu, conhecidas como Amazon Machine Images (AMI), podem ser utilizadas para instanciar novos servidores;
• Walrus Storage Controller (W): é o serviço de armazenamento de dados compatível com os serviços da Amazon S3. Os templates de imagens do Walrus (ou templates na Amazon S3) são fornecidos para o NC quando se deseja instanciar uma nova VM. Walrus também é responsável por armazenar snapshots, armazenar e servir arquivos com a S3 API.
• Node Controller (NC): um NC gerencia o ciclo de vida das VMs em um dado servidor;
• Cluster Controller (CC): cada CC gerencia um grupo de NCs, ou seja, adquire informações, escalona as requisições para cada NC, além de gerenciar a rede virtual das VMs;
• Storage Controler (SC): é o componente que fornece funcionalidades de persitência para as VMs instanciadas no cluster, além de interfaces compatíveis com o serviço de armazenagem da Amazon Elastic Block Storage (EBS), ou seja, recursos de armazenagem podem ser dinamica-mente atribuídos às VMs. Volumes de dados da Amazon EBS persistem independentedinamica-mente da vida de uma instância. Além disso, os dados podem ser recuperados e atribuídos às VMs como um dispositivo de armazenagem remoto.
6.3
XCP
A empresa Xen disponibiliza a plataforma XCP (Xen Cloud Platform) [21] como alternativa open source para prover ambientes de Cloud. A plataforma inclui o agrupamento e o isolamento de recursos de hardware e rede, provisionamento de sistemas, APIs para expôr os recursos e compatibilidade com um grande número de sistemas operacionais [70]. O XCP herda características do ambientes de virtualização paravirtualizados dos produtos Xen. Em vista disso, o administrador do domínio precisa adquirir templates de imagens paravirtualizadas de sistemas operacionais compatíveis com o XCP. Para ambientes de data-center essa alternativa não chega a ser um empecilho. Todavia, existe
Fig. 11: Arquitetura do Eucalyptus.
a desvantagem de se ter as imagens apenas dentro do ambiente da nuvem, o que pode dificultar a migração entre ambientes de nuvem não compatíveis com o XCP.
Na arquitetura XCP (Fig. 12) as VMs são disponibilizadas em hosts físicos (XCP host) separados do host de gerência (Master XCP), e agregadas em um XCP resource pool. A gerência de máquinas virtuais ocorre com o uso de uma interface no Master XCP host, que deve ser um host dedicado para esse fim. A distribuição atual (versão 1.0) não inclui uma interface gráfica para gerência do ambiente (apenas CLI), mas existem projetos open source que fornecem interfaces gráficas de gerência remota (tanto para a instalação de templates, como para a configuração de interfaces de rede, inicialização/-finalização de VMs, entre outras funcionalidades) como o XenCenter e o OpenXenManager [71]. Todas as VMs são registradas em um Shared Storage de forma que a Management Interface seja capaz de gerenciar todas as VMs na nuvem.
Fig. 12: Arquitetura do XCP.
6.4
Nimbus
O projeto Nimbus [72] é definido como um toolkit open source para oferecer um ambiente de cluster como uma IaaS. Esse toolkit oferece interfaces WSDL para a Amazon EC2, Amazon EC2 Query API, e WSRF para aplicações em Grades. Também são oferecidas interfaces REST para o acesso à base de dados de recursos e escalonamento de VMs por meio de uma interface de gerência
• Workspace Service: é um serviço que utiliza a infraestrutura GSI para a comunicação segura com serviços de Grades. Além disso, possui interfaces WSDL para aplicações Amazon EC2 e WSRF para aplicações em Grades. O Workspace client é o componente no lado cliente que se comunica com a nuvem Nimbus;
• Workspace resource manager: é um componente utilizado para a gerência de VMs de outras tecnologias (a atual distribuição do Nimbus também gerencia VMs do projeto OpenNebula); • Workspace control: é o componente responsável pela gerência de VMs (iniciar, finalizar,
con-sultar status, atribuir endereços IP e MAC, entre outros). Para essa gerência pode ser utilizado tanto o Xen hypervisor quanto o KVM, juntamente com as bibliotecas libvirt;
• Workspace pilot: é o componente responsável por realocar memória para a execução de múlti-plas VMs, para obter uma melhor distribuição da memória na nuvem.
Fig. 13: Arquitetura do Nimbus.
6.5
OpenNebula
O projeto OpenNebula [73] é um toolkit open source para a provisão de nuvens públicas, privadas e híbridas. A infraestrutura do sistema oferece recursos sob demanda para usuários finais, e foi designada para ser integrada com outras soluções de armazenagem e rede. As VMs são utilizadas em um pool de recursos e toda a alocação de recursos é baseada em políticas. O ambiente virtualizado é acessível por meio de interfaces Open Cloud Computing Interface (OCCI) do Open Grid Forum4.
Além disso, OpenNebula também oferece interfaces para a EC2 Query API da Amazon, através da interface Web OpenNebula Sunstone, e um subconjunto de chamadas da vCloud API da VMware. A infraestrutura tem suporte para Xen, KVM/Linux, e VMware.
A arquitetura do OpenNebula foi desenvolvida em um modelo de camadas, como mostra a Fig. 14. Ela assume um modelo clássico de cluster, com um nó mestre para manter os serviços de gerência e diversos nós escravos para manter as VMs. Os nós escravos são supervisionados pelo hypervisor do nó servidor, o que exige que todos os nós estejam conectados por pelo menos uma rede física.
A camada Tools contém os módulos utilizados por administradores e desenvolvedores para a interação, seja por interfaces do módulo Command Line Interface (CLI), ou outros Cloud Services
