Nuvem Pública versus Privada: Variações no Desempenho de Infraestrutura para Elasticidade

Transcrição

1 110 Anais Nuvem Pública versus Privada: Variações no Desempenho de Infraestrutura para Elasticidade Ernani Azevedo, Cyrus Dias, Rhodney Simões, Ramide Dantas, Djamel Sadok, Stenio Fernandes, Carlos Kamienski Centro de Informática Universidade Federal de Pernambuco (UFPE) Universidade Federal do ABC (UFABC) Resumo. A computação em nuvem oferece a possibilidade de alocação e desalocação de recursos computacionais sob demanda através da elasticidade. Apesar de várias opções de nuvem pública e privada estarem disponíveis, os usuários ainda carecem de informações específicas sobre o desempenho dessas operações. Esse artigo compara a nuvem pública Amazon EC2 com uma nuvem privada controlada pelo OpenNebula e o uso direto do hypervisor Xen para ações como criação/destruição e suspensão/recuperação de máquinas virtuais. Os resultados mostram que elasticidade pode ser provida pelas três categorias de serviços em tempos de resposta aceitáveis para várias aplicações, de modo que a escolha do usuário depende de uma combinação de critérios técnicos e estratégicos. Abstract. Cloud computing provides on demand allocation and deallocation of resources via the key feature of elasticity. Although there are some choices for public and private clouds available, users lack particular details on the performance of these operations. This paper presents a comparison of Amazon EC2 public cloud service with a private cloud controlled by OpenNebula and the direct use of the Xen hypervisor for operations on virtual machines such as creation/teardown and suspend/resume. Our results show that elasticity may provided by the three categories of clouds services with acceptable response times, so that the user choice depends on a combination of technical and strategic criteria. 1. Introdução O objetivo de prover serviços computacionais como utilidade está se tornando realidade com a disseminação de datacentres públicos e privados na rede. Da mesma forma que energia elétrica, água e gás, um serviço de nuvem permite alocar e desalocar sob demanda variados tipos de recursos computacionais. A característica distintiva da elasticidade permite que recursos, como máquinas virtuais e armazenamento, sejam rapidamente adicionados para atender a demandas instantâneas das aplicações e removidos quando não forem mais necessários [Armbrust et al. 2009]. A compreensão dos benefícios obtidos por uma organização pela escolha da nuvem para hospedar seus serviços envolve uma cuidadosa avaliação dos critérios técnicos, assim como financeiros e estratégicos. E apesar de vários serviços de nuvem pública e plataformas de nuvem privada estarem disponíveis, atualmente existe uma carência de informações específicas para subsidiar os usuários sobre o desempenho do ambientes nas tarefas de alocação e desalocação de recursos. Em outras palavras, é

2 X Workshop em Clouds e Aplicações 111 necessário saber qual nível de elasticidade é permitida pelo serviço de nuvem com qual tempo de resposta, para auxiliar a compreensão global dos desafios envolvidos com o provimento de elasticidade em nuvens públicas e privadas. Esse artigo compara o desempenho do serviço de nuvem pública Amazon EC2 [EC2 2012], com uma nuvem privada gerenciada pelo controlador de nuvem OpenNebula [OpenNebula 2012], alinhando essa avaliação com os resultados do hypervisor Xen [Barham et al. 2003] para as tarefas de criação/destruição, suspensão/recuperação e reinício de máquinas virtuais. Uma vez que Amazon EC2 e OpenNebula usam o Xen internamente, a comparação entre nuvem pública e privada acompanhada do desempenho do gerenciador de máquinas virtuais isola os efeitos dos serviços de nuvem e de virtualização. O artigo mostra resultados de vários experimentos controlados executados no nível de Infrastructure as a Service (IaaS). Uma vez que a comparação envolve nuvem pública e privada, os níveis de controle exercidos pelo usuário também são diferentes. Por exemplo, o EC2 possui autonomia para criar as máquinas virtuais (chamadas de instâncias) em quaisquer servidores físicos que estiverem disponíveis, de acordo com os critérios de disponibilidade utilizados pela Amazon. No caso do OpenNebula, o administrador de nuvem pode exercer controle sobre os servidores que estão disponíveis para realização dos testes com as máquinas virtuais. Os resultados mostram que elasticidade pode ser provida pelas três categorias de plataformas avaliadas em tempos hábeis, de modo que a escolha do usuário depende de uma combinação de decisões técnicas, financeiras e estratégicas. No geral, o uso do Xen diretamente sem uma camada de abstração oferece o melhor desempenho ao custo adicional de maior complexidade de administração. O OpenNebula oferece facilidade e flexibilidade no uso de recursos em uma nuvem privada, contudo se observa um desempenho (as vezes significativamente) menor. O Amazon EC2 é uma opção confortável para usuários com demandas sazonais, mas oferece maior instabilidade de desempenho e menor controle sobre os recursos físicos. O usuário deve escolher a plataforma que mais se adapta à solução pretendida. Por exemplo, caso o usuário não tenha orçamento suplementar disponível, mas disponha de servidores físicos e tempo para executar o processamento, a melhor escolha pode ser o OpenNebula. Nesse caso, o controlador realiza várias operações automaticamente, que deveriam ser executadas pelo administrador de nuvem, se o hypervisor for usado diretamente. Caso maior controle sobre o hardware for requerido ou o tempo de resposta para elasticidade for crítico, pode valer a pena usar o Xen diretamente sobre o hardware sem um controlador de nuvem. Ainda, se o conhecimento técnico do usuário não for elevado para instalar, configurar e manter um controlador privado, ou o usuário não dispuser de servidores físicos, mas tiver orçamento para cobrir custos ocasionais de processamento, o Amazon EC2 pode ser a melhor escolha. O restante do artigo é estruturado como adiante. A seção 2 apresenta conceitos importantes ao entendimento da proposta e trabalhos relacionados cujo conteúdo inspirou e deu suporte a nosso estudo. A seção 3 explicita os ambientes de avaliação utilizados como foco do estudo enquanto a seção 4 detalha a metodologia desenvolvida para a realização da avaliação e da comparação entre as propostas. Na seção 5 são mostrados os resultados encontrados e a discussão relacionada. Por fim, as conclusões do estudo e ideias de continuidade são apresentadas, na seção 6 e um reconhecimento aos incentivos que fomentaram a pesquisa são apresentados na seção 7.

3 112 Anais 2. Conceitos e trabalhos relacionados Computação em nuvem é o recente paradigma de serviços relacionados à Internet que prega a provisão de recursos dinamicamente escaláveis, e normalmente virtualizados através de serviços web. Na cobrança pelo serviço, é aplicada a mesma lógica utilizada na taxação de serviços básicos como água, luz e telefone. Este modelo possibilita que serviços de TI sejam oferecidos aos usuários sob demanda, onde estes pagam apenas pelo que utilizam do serviço. Um perfil de usuário particularmente favorecido pela computação em nuvem é o de desenvolvedores com ideias inovadoras de serviços na Internet, que não precisam mais investir muito capital em hardware e em recursos humanos para manter o serviço em operação. A Figura 1 compara a oferta tradicional de serviços de Internet com a oferta usando computação em nuvem. Ao passo em que na Figura 1(a) é necessário criar e manter uma estrutura, com hardware, hospedagens, conectividade, escalabilidade e etc. individualmente, a nuvem na Figura 1(b) provê uma abstração, facilitando a implantação e a gerência de serviços web. Figura 1: Ilustração comparando a oferta de serviços tradicional (a) e através de fatias da nuvem sendo alocadas para os serviços (b). Existem três categorias distintas de nuvem as, públicas, privadas e as híbridas [Armbrust et al. 2009]. Empresas que oferecem serviços de algum nível de computação em nuvem para os seus clientes são classificadas como nuvens públicas. Já nuvens privadas são construídas pelas organizações para atender necessidades específicas de sua empresa, sendo necessário gerenciar a infraestrutura física para suprir tais necessidades. Já a nuvens híbridas surgem da composição tanto de nuvens publicas quanto privadas, tal divisão geralmente ocorre com intuito de delegar as empresas que proveem serviços parte das tarefas que poderiam ser executados em um ambiente externo ao das empresas. A Figura 2 ilustra uma representação destas categorias de nuvem. Figura 2: Ilustração dos três tipos de computação em nuvem. Alguns trabalhos realizam analise qualitativa dos diversos controladores de nuvem privada. No entanto não foi encontrado nenhum que fizesse uma comparação entre plataformas de níveis diferentes, ou seja, um hypervisor, um controlador de nuvem privada e uma nuvem pública. Existem algumas comparações, contudo, de plataformas

4 X Workshop em Clouds e Aplicações 113 IaaS realizadas pela comunidade científica, focando aspectos como a interface do serviço, a arquitetura da rede interna, o relacionamento com virtualização. Em [Sempolinski e Thain 2011] é mostrada uma comparação entre o Eucalyptus, OpenNebula e Nimbus, focando a estrutura interna dessas plataformas, e como a maneira em que elas foram modeladas se reflete nas funcionalidades oferecidas. Os autores em [Endo et al. 2010] mostram uma comparação entre o XCP, Eucalyptus e OpenNebula, inclusive refinando a comparação com alguns cenários onde certas soluções se encaixam melhor que as outras. Em [Peng et al. 2009] é feita uma analise qualitativa dos controladores de nuvem Abicloud, Eucalyptus, Nimbus e OpenNebula. São listados seus recursos e suas funcionalidades além de uma descrição das suas arquiteturas internas e aspectos nos quais umas plataformas se sobressaem em relação às outras, porém não são realizados testes de desempenho. Da mesma forma, em [Cerbelaud et al. 2009] também é realiza uma observação qualitativa de alguns controladores de nuvem (Enomaly ECP, Eucalyptus, OpenNebula e ovirt). O foco deste artigo, no entanto, diz respeito ao detalhamento de como são executadas as funções básicas dos controladores como manipulação das imagens, gerenciamento de cotas, clusters e rede. Ao final é descrito os pontos fortes de cada controlador. Os autores de [Dejun et al. 2009] realizaram avaliações quantitativas da infraestrutura da Amazon. Foram utilizadas diversas instâncias do tipo pequeno (small) para os testes. O primeiro experimento feito foi o de estabilidade de desempenho, onde as instâncias estão sobre intensa carga de trabalho, seja ela de processamento ou de I/O. O segundo experimento se baseia na homogeneidade do desempenho das instâncias. Para tal tarefa as instâncias foram avaliadas por 6 horas seguidas sobre uma carga de trabalho de I/O. No último experimento os autores estabelecem uma correlação entre desempenho de CPU e I/O. Todavia, não foi realizada a comparação dos resultados com outra plataforma de nuvem seja ela pública ou privada por meio dos controladores de código livre. Os benchmarks efetuados em [Lenk et al. 2011] visam apenas analisar se os serviços oferecidos pelas nuvens públicas da Amazon EC2, Flexiscale e Rackspace correspondem ao que é efetivamente alocado ao cliente. Para realização dos experimentos foi utilizada à ferramenta Phoronix Test Suite, que possui em sua implementação testes como Sudok, OpenSSL, OVSP, dentre outros. O objetivo deste trabalho era analisar apenas a alocação de recursos de processamento, desprezando outros parâmetros como armazenamento e rede. A avaliação de desempenho em [Ueda e Nakatani 2012] mostra uma comparação quantitativa entre as soluções OpenNebula, Eucalyptus e Amazon EC2. Nesse trabalho foi analisado o tempo de aquisição de máquinas virtuais usando cada plataforma, no entanto o objetivo principal era achar a melhor configuração da camada de armazenamento do OpenNebula que otimizasse o processamento de arquivos de lote e também a vazão em aplicações web. Nossa pesquisa não avaliou o impacto de diferentes configurações no OpenNebula, mas sim o efeito que a camada de nuvem imprime nas atividades de gerenciamento de máquinas virtuais, como criação e desligamento.

5 114 Anais 3. Ferramentas Para a realização da avaliação, duas categorias de ferramentas foram usadas: as relacionadas ao ambiente, usadas para suportar a execução das plataformas de nuvem e sua avaliação, e as plataformas em si Ambiente O hardware utilizado para avaliação das plataformas privadas corresponde a uma configuração mediana para provisão de máquinas virtuais e serviços web. Nos experimentos, tivemos à disposição quatro servidores com as mesmas especificações: Processador Intel Core i7 3.2GHz, 12GB de memória RAM, 1TB de armazenamento em disco, duas placas de rede Gigabit Ethernet, uma para conexão em rede interna com o outro servidor e uma para conexão com a internet. Os servidores estão geograficamente divididos, estando dois ligados à Rede Nacional de Pesquisa em Recife (PE) e os outros dois ligados à RNP em Santo André (SP), ambas as conexões possuindo largura de banda de 10Gbps. Visto que todas as plataformas avaliadas funcionam sobre plataforma Linux, os quatro servidores possuem a distribuição Debian Squeeze 64bits instalada. A escolha por esta distribuição foi impulsionada pela estabilidade comumente associada aos sistemas Debian Ferramentas avaliadas Três tipos de plataformas de nuvem foram selecionados para a realização da avaliação. Entre si, as ferramentas diferem no que diz respeito ao nível de interação com recursos de hardware, com os clientes ou usuários das plataformas de nuvem e a forma com a qual usam as capacidades de rede disponíveis. O hypervisor, ou monitor de máquinas virtuais, é a ferramenta de nuvem mais básica, e permite que os recursos de hardware de um servidor sejam fatiados e compartilhados entre servidores virtuais que farão parte da nuvem. Os hypervisors implementam a biblioteca libvirt 1, projetada para facilitar a criação e a manipulação de máquinas virtuais [Sempolinski e Thain 2011]. Já os controladores de nuvem se encontram num nível acima dos hypervisors, e representam uma abstração entre os comandos passados via front-end e os componentes abaixo deste (como o hypervisor em si, infraestruturas de rede, armazenamento e repositórios de imagens), fazendo com que uma instrução seja convertida em instruções que efetivam uma virtualização [Sempolinski e Thain 2011]. Em adição a isso, os controladores podem agrupar em clusters vários servidores, cada qual com seu monitor de máquina virtual, agregando a gerência de muitos servidores de nuvem em um ponto. As plataformas públicas de nuvem possuem infraestruturas próprias, com controladores e servidores potentes munidos de hypervisors, e oferecem sua estrutura de virtualização como um serviço a terceiros, geralmente na forma de web services, mediante a cobrança de taxas. A seguir são apresentadas as plataformas equivalentes às três categorias utilizadas para avaliação, e os motivos que levaram a suas escolhas. 1 Disponível em

6 X Workshop em Clouds e Aplicações Xen O Xen [Barham et al. 2003] é uma solução de código aberto para virtualização de infraestrutura que provê uma camada de abstração entre o hardware e o sistema operacional e com isso, permite a execução de vários sistemas operacionais em paralelo numa mesma máquina física. O Xen é um hypervisor que possui suporte a paravirtualização [Barham et al. 2003], onde o sistema operacional da máquina virtual tem a ilusão de estar executando diretamente sobre o hardware. Isso causa uma melhoria considerável no desempenho das máquinas virtuais, se comparado com a estratégia de virtualização total. Apesar de ser uma solução aberta, muitas plataformas comerciais usam o Xen (e versões adaptadas deste) para oferecer seus serviços, como por exemplo, o Amazon EC2 (seção 3.2.3) OpenNebula O controlador de nuvem OpenNebula [OpenNebula 2012] possui um alto nível de centralização, flexibilidade e customização, é uma plataforma adaptável para a construção de nuvens privadas e híbridas num datacentre pré existente. Devido à sua flexibilidade, a arquitetura do OpenNebula pode ser configurada de diferentes formas, facilitando a portabilidade e a interoperabilidade entre vários datacentres. Sua interface e seus módulos de código aberto possibilitam a extensão necessária para a integração com softwares de armazenamento já existentes, porém, devido ao alto grau de customização a escolha da arquitetura e a configuração dos componentes do OpenNebula é fundamental para que a nuvem esteja adequada em relação à carga. O OpenNebula possui características de abstração e personalização típicas de um controlador de nuvem. Isso demonstra a princípio que esse tipo de plataforma é voltado para aqueles que possuem bom conhecimento técnico, e consequentemente podem obter vantagens da variedade de funcionalidades disponíveis. Por esta possibilidade de grande interação com o funcionamento do controlador e por ser o mais indicado para usuários que desejam alterar sua forma padrão de funcionamento [Sempolinski e Thain 2011], o OpenNebula foi a plataforma escolhida para fazer parte da nossa avaliação. A arquitetura do OpenNebula, como pode ser vista na Figura 3 é baseada em três tecnologias para permitir a provisão de serviços em nuvem: virtualização, armazenamento e rede. Por ser de uma camada superior na hierarquia de virtualização, o OpenNebula pode controlar o uso de diferentes hypervisors. Para o ambiente aqui descrito, o hypervisor Xen foi usado para dar este suporte. Figura 3: Arquitetura do OpenNebula contextualizada em computação em nuvem [OpenNebula 2012].

7 116 Anais Amazon EC2 A nuvem pública escolhida para ser avaliada foi a da Amazon Web Service (AWS) [AWS 2012], por ser uma das maiores empresas provedoras de infraestrutura como serviço (Infrastructure-as-a-Service - IaaS) no mundo, possuir um grau de confiabilidade satisfatório 2, por deter um datacentre geograficamente próximo, e desta forma, ser apto a hospedar mais adequadamente a avaliação. Especificamente, foi avaliado o serviço Amazon Elastic Compute Cloud (Amazon EC2) [EC2 2012], que é um serviço de IaaS que possibilita a utilização da grande infraestrutura computacional da Amazon pelos clientes. Esse serviço é chamado de elástico porque permite que os clientes aumentem ou diminuam sua utilização dinamicamente através da criação ou remoção de instâncias de máquinas virtuais. A Amazon EC2 oferece alguns padrões de instâncias virtuais a serem alocadas para o cliente como pode ser contemplado na Tabela 1. Além dos padrões de instâncias apresentado na tabela, existem outras instâncias de alto desempenho que estão disponíveis apenas para algumas centrais de servidores disponibilizados pela Amazon. É utilizado o conceito de unidades de processamento EC2 ECU, que é correspondente a capacidade de um processador Opteron 2007 ou Xeon 2007 de GHz. Tipo de Instância Tabela 1 - Tipos de instâncias Amazon EC2 Memória Armazenamento Unidades de Processamento Plataforma Micro 613 MB Variável Até 2 ECUs 32 bits / 64 bits Preço/Hora $0,080 - $0,115 Pequeno 1,7 GB 160 GB 1 ECU 32 bits $0,160 - $0,230 Grande 7,5 GB 850 GB 4 ECUs 64 bits $0,320 - $0,460 Extragrande 15 GB GB 8 ECUs 64 bits $0,640 - $0, Metodologia da avaliação Para avaliar o desempenho das plataformas no tocante à forma como estas estão predispostas a oferecer elasticidade aos servidores virtuais, foram selecionadas algumas funções básicas da virtualização. A Tabela 2 lista as funções selecionadas para medição, juntamente com uma descrição que justifica a escolha das funções correspondentes. Visando ter uma aproximação mais realista do tempo de execução das funções selecionadas para avaliação, 30 iterações foram executadas para cada experimento, e dos dados obtidos foram extraídos as médias e os intervalos de confiança. Entretanto, estes intervalos só são apresentados nos resultados quando são representativos perante os tempos obtidos. 2 De acordo com Cloud Harmony ( o datacenter Amazon EC2 de São Paulo, utilizado nos experimentos, apresenta disponibilidade de 100%.

8 X Workshop em Clouds e Aplicações 117 Tabela 2: Funções de virtualização selecionadas para avaliação e suas descrições. Função Criação Destruição Suspensão Recuperação Reinício Descrição Dispara a construção de uma máquina virtual, com especificações de hardware virtual descritas num arquivo de configuração. A partir deste momento a máquina passa a emular o funcionamento de um servidor. Deixa o servidor virtual indisponível, bem como seus arquivos e serviços em execução. O desligamento encerra a vida útil da máquina virtual e libera os recursos de hardware que estavam sendo alocados. Temporariamente libera os recursos de hardware usados para certo servidor virtual. Entretanto, os dados e serviços não são perdidos, uma vez que um backup do disco virtual é feito para posterior recuperação. Recupera uma máquina virtual que estava suspensa, contendo os mesmos dados, serviços e especificações descritas no momento de sua criação. Desaloja e realoca os recursos reservados para uma máquina virtual numa máquina física. Esta função é particularmente útil para prevenir a deterioração provocada pelo uso prolongado dos softwares. Com o objetivo de atingir uma gama maior de possibilidades testadas, e com isso, dar um embasamento técnico maior aos resultados obtidos, foram avaliadas quatro possíveis configurações de máquina virtual, em todos os ambientes selecionados. Como base para a escolha, selecionamos configurações disponíveis no serviço Amazon EC2 (seção 3.2.3) que pudessem ser instanciadas nos servidores físicos de forma adequada (isto é, não saturassem a configuração do hospedeiro dos servidores virtuais). As imagens de disco usadas, também imprescindíveis para a virtualização de máquinas, foram obtidas do próprio serviço da Amazon, com o intuito de aproximar os cenários nas três ferramentas avaliadas, e constam na Tabela 3, juntamente com as outras configurações. Tabela 3: Configurações de máquina virtual usadas para avaliação. Configuração Processador Memória Sistema Operacional micro32 2 ECUs 613 MB Ubuntu Server x86 micro64 1ECU 613 MB Ubuntu Server x64 small32 1 ECU 1,7 GB Ubuntu Server x86 large64 4 ECUs 7,5 GB Ubuntu Server x64 Ainda em se tratando de avaliar variações dos cenários, as configurações mencionadas foram executadas com o servidor físico sem nenhuma carga de trabalho inicial e com os recursos físicos próximos da exaustão. Esta variação foi feita com o intuito de testar o comportamento de ferramentas de nuvem quando não há exclusividade de recursos para servidores virtuais. Uma vez que não é possível ter conhecimento da estrutura física do serviço Amazon EC2 a ponto de se realizar esta avaliação, apenas as plataformas Xen e OpenNebula foram testadas. Estas ferramentas foram testadas limpas, isto é, com os recursos totalmente dedicados à avaliação, e com os recursos no limite de serem exauridos no cenário mais custoso. Para se chegar a este ponto, máquinas virtuais foram instanciadas antes do começo da avaliação. Uma ilustração do que se pretendeu pode ser vista na Figura 4.

9 118 Anais Figura 4: Máquina hospedeira de servidores virtuais com pouco uso de disco, memória e núcleos de processador (a) e a situação quase esgotada (b). O script utilizado para medição e coleta de tempo de cada função seguiu a estrutura demonstrada na Figura 5. A seção de código genérico foi descrita em linguagem de terminal do Linux e executada em sequência para cada configuração descrita para cada cenário acima. As peculiaridades e modificações necessárias para cada código de avaliação serão descritas nas seções 4.3, 4.2 e 4.1 adiante. Figura 5: Pseudo-código genérico usado para avaliar o desempenho das funções Xen Quando uma função do Xen é invocada, as alterações que esta causa no ambiente são refletidas imediatamente na lista de máquinas virtualizadas, contemplada com a chamada da função xm list. Como as chamadas a funções do Xen são executadas em plano de fundo, impossibilitando uma medição mais direta, o script utilizado na avaliação observa, em paralelo, a tabela mencionada, e quando as alterações esperadas são refletidas nesta tabela, o script realiza a marcação do tempo decorrido desde a invocação até a execução da função Para avaliar o desempenho das funções do Xen mesmo com alguma carga inicial de máquinas virtuais alocada, foram usadas seis configurações de servidor com 1 ECU, 500MB de memória RAM e sistema operacional Ubuntu Server x86. Chegamos a este número porque, além de cada processador virtual ocupar um núcleo do processador físico, na configuração mais exigente testada, a memória física chega a ser quase totalmente utilizada. As imagens de máquina virtual utilizadas para realizar as medições no Xen, tanto as imagens geradoras de carga extra quanto as imagens usadas para criar a máquina virtual avaliada, foram dispostas diretamente no disco rígido das máquinas testadas. As funções do Xen que equivalem às de Criação, Desligamento, Suspensão, Restauração e Reinício são, respectivamente: xm create, xm shutdown, xm save, xm restore e xm reboot.

10 X Workshop em Clouds e Aplicações OpenNebula Apesar de possuir alguns front-ends gráficos que aumentam o poder de abstração do OpenNebula (tal qual o Sunstone 3 ), para a avaliação foi necessário usar a interface em linha de comando da plataforma. Suas chamadas de funções disparam uma série de processos subjacentes, alguns pertencentes à própria plataforma, e outros pertencentes ao Xen. Desta maneira, a forma mais adequada de cronometrar o tempo levado pelas chamadas é observando a tabela de status dos servidores, encontrada a partir do comando onevm list. Esta adaptação precisou ser feita ao script mencionado acima para medir com mais precisão o tempo de resposta das funções do OpenNebula. Para fazer o sistema formado pelo OpenNebula atingir um estado de utilização semelhante ao do Xen, os dois servidores que formam a rede, e possuem o Xen como hypervisor, tiveram seis máquinas virtuais semelhantes às mencionadas no tópico acima instanciadas em cada servidor físico. Desta forma, coube ao controlador gerenciar o uso dos recursos remanescentes. As imagens de máquina virtual utilizadas nas medições do OpenNebula foram armazenadas no disco rígido de uma das máquinas do sistema, e o componente agendador do controlador ficou responsável por manipulá-las de acordo com as políticas da própria plataforma. As funções do OpenNebula que equivalem às de Criação, Desligamento, Suspensão, Restauração e Reinício são, respectivamente: onevm create, onevm shutdown, onevm suspend, onevm resume e a invocação consecutiva de onevm suspend + onevm resume Amazon EC2 Para realizar os testes com maior precisão, o ambiente disponível na UFABC, campus Santo André (SP), foi utilizado nas medições do serviço EC2. Isso porque o datacentre usado na nossa avaliação se situa geograficamente próximo ao campus (São Paulo SP). Para refinar a precisão dos resultados, enquanto um dos servidores executava o script acima obtendo as medições, outro servidor fazia medições de RTT de pacotes entre as duas localidades. Subtraindo-se do tempo total da invocação dos web services do serviço EC2 a média dos tempos de ida e volta dos pacotes pela rede, esperamos ter o tempo usado apenas para que as funções tenham seus comportamentos efetivados. As funções do OpenNebula que equivalem às de Criação, Desligamento, Suspensão, Restauração e Reinício são, respectivamente: ec2-start-instances, ec2- terminate-instances, ec2-stop-instances, ec2-run-instances e ec2-reboot-instances. 5. Resultados Os resultados na Figura 6(a) mostram que a adição do controlador de nuvem sobre o Xen imprime uma diferença significativa no desempenho da criação de máquinas virtuais. Isso se deve ao fato do OpenNebula manter as imagens num repositório a parte e cloná-la a cada operação, o que apesar de ser uma abordagem mais consistente, atrasa o processamento das funções. Os valores obtidos pelos experimentos com o Xen revelam que o hypervisor é bastante estável, conseguindo tempos de criação praticamente constantes. Os requisitos de CPU e memória da máquina virtual também Apenas versões mais recentes do OpenNebula implementam a função reboot, prevista na libvirt.

11 120 Anais influenciaram o tempo de criação, que pode ser percebido especialmente no teste do cenário large64. Além disso, ficou evidente na Figura 6(b) que no caso da avaliação da destruição de maquinas virtuais na plataforma EC2 foi percebida uma alta variação de valores. Mais pesquisas chegaram à conclusão que esse resultado não foi caracterizado por oscilações na conexão com o serviço, mas que é algo característico da utilização do mesmo. Também foi notado que no EC2, os piores tempos de criação e destruição pertenceram às instâncias micro32 e micro64. Uma possível justificativa é o fato que são as instâncias com menor custo, e por este motivo, possivelmente recebem prioridade de alocação menor em comparação a instâncias mais caras. 1,5 1,2 1,3 1,2 3,8 3,6 4,1 5,1 27,6 27,5 40,3 78,4 AMAZON XEN OPENNEBULA 3,5 5,9 3,4 2,3 5,8 3,7 2,3 5,8 5,0 2,3 5,8 12,8 AMAZON XEN OPENNEBULA (a) Figura 6: Tempo, em segundos, da criação (a) e destruição (b) de VMs. Como pode ser observado na Figura 7(a), a Amazon EC2 e o Xen apresentaram regularidade ao restaurar as máquinas virtuais. Nestas plataformas a configuração da máquina virtual não impactou nos seus desempenhos. Já o controlador OpenNebula demonstrou ser sensível a robustez da máquina virtual, pois apresentou aumento contínuo do tempo diante do aumento da robustez da mesma. Observando a Figura 7(b) é possível identificar que tanto o OpenNebula quanto o Xen são sensíveis a robustez da máquina virtual para a tarefa de suspensão. Tal fato é comprovado pelo aumento deste tempo diante da variação das configurações das máquinas virtuais. O mesmo não se aplica à Amazon EC2, pois não houve oscilação expressiva nos tempos para esta tarefa perante a variação das configurações das VMs. (b) 1,4 3,7 75,6 3,7 77,6 96,4 1,3 1,3 3,5 3,5 7,1 17,0 AMAZON XEN OPENNEBULA 3,5 3,5 7,8 9,2 19,2 23,4 AMAZON XEN OPENNEBULA 1,3 4,5 7,1 4,6 8,2 9, (a) Figura 7: Tempo, em segundos, das operações de restauração (a) e suspensão (b) de máquinas virtuais. (b)

12 X Workshop em Clouds e Aplicações 121 A Figura 8 comprova que o OpenNebula possui desempenho pior que as demais plataformas analisadas perante a tarefa de reinício das máquinas virtuais. O desempenho desta plataforma se agrava quando aumentamos a robustez das máquinas virtuais. Esse agravante não se repete na Amazon EC2 e no Xen, onde os tempos de reinício permanecem regulares. 3,5 5,9 167,7 3,5 4,2 3,4 4,2 15,2 37,8 AMAZON XEN OPENNEBULA 3,6 4,2 15, Figura 8: Tempo, em segundos, do reinício das das máquinas virtuais. Outros resultados encontrados dizem respeito à avaliação de plataformas contendo carga de trabalho inicial, isto é, com alguns servidores virtuais alocados na máquina física, em oposição a esta dispor de todos seus recursos de hardware. Os testes foram feitos segundo o que está descrito nas seções 4.1 e 4.2. Com os resultados obtidos, pudemos observar que as plataformas estudadas estão preparadas para lidar com situações em que os recursos de hardware estão perto de se exaurir, pois fazem um uso otimizado dos mesmos. Na Figura 9, podem ser vistos casos nos quais houve perda de desempenho em todos os cenários, contudo as perdas não são significativas a ponto de se chegar a resultados conclusivos. É percebido também que, quanto mais exigente o cenário se torna (processamento, memória e disco), mais sensível a operação da plataforma fica à carga de trabalho da máquina física. Nas figuras abaixo, a legenda i=0 indica que o experimento foi executado sem carga inicial, e i=6 indica que foi executado com a carga inicial de 6 máquinas virtuais já mencionadas na seção 4. 99,703 77,576 7,057 5,918 20,661 19,219 8,831 7,766 XEN (i=6) XEN (i=0) 5,860 5,832 5,890 5,834 ONE (i=6) ONE (i=0) 8,842 8,239 5,857 5, (a) Figura 9: Comparação do desempenho da suspensão de VMs do Xen (a) e da destruição de VMs do OpenNebula (b) com diferentes cargas de trabalho iniciais. A Figura 10 mostra casos em que os desempenhos das operações oscilam, de forma que não fica coerente apontar que os servidores virtuais existentes comprometem o tempo de (b)

13 122 Anais execução das operações. Com estes dados, podemos confirmar que cargas iniciais mais exigentes devem ser aplicadas nas medições, de forma a testar com mais eficiência o quanto as plataformas podem suportar. 1,303 1,363 70,349 75,606 1,346 1,251 1,303 1,252 XEN (i=6) XEN (i=0) 17,092 17,022 7,042 7,096 ONE (i=6) ONE (i=0) 1,379 1,257 7,090 7, (a) Figura 10: Oscilação no desempenho da função recuperação do Xen (a) e do OpenNebula (b), com diferentes cargas de trabalho iniciais. 6. Conclusão e trabalhos futuros Elasticidade é uma característica primordial de computação em nuvem, ao permitir que variações dinâmicas de demanda por aplicações sejam atendidas com a adição de novos recursos sob demanda e a consequente liberação dos recursos quando eles não mais necessários forem. Esse artigo oferece informações para a realização de escolhas corretas ao usar os vários serviços e estratégias possíveis de nuvens públicas e privadas, ao comparar o desempenho de Amazon EC2 com OpenNebula e Xen. Os resultados mostram que elasticidade pode ser provida pelas três categorias de plataformas avaliadas em tempos razoáveis, que dependendo da aplicações e das condições técnicas e financeiras do usuário, podem levar a escolhas diferentes de plataformas. Uma vez que pesquisas nessa linha são importantes para a tomada consciente de decisões, esse trabalho abre caminho para uma grande variedade de possíveis trabalhos futuros. Os principais são a avaliação de outras plataformas de nuvem, a avaliação da elasticidade efetiva com aplicações rodando em tempo real e a possibilidade de recursos serem alocados elasticamente de uma nuvem, pública ou privada, para outra nuvem (também chamado de cloud burst). 7. Agradecimentos Para a realização deste trabalho, além dos esforços individuais da equipe, contamos com o financiamento do Projeto Altostratus, que nos permitiu a aquisição dos servidores, o suporte e a infraestrutura de rede da RNP, oferecidos pela Universidade Federal de Pernambuco e pela Universidade Federal do ABC, e a cessão de contas para teste por parte da Amazon. Referências Armbrust, M., Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, M. (2009) "Above the Clouds: A (b)

14 X Workshop em Clouds e Aplicações 123 Berkeley View of Cloud computing", Relatório técnico No. UCB/EECS , Universidade da California, Fevereiro de AWS (2012). Amazon Web Services. Disponível em Barham P., Dragovic B., Fraser K., Hand S., Harris T., Ho A. (2003) Neugubauer R., Pratt I., Warfiled A., Xen and the art of virtualization, SOSP '03 19th ACM symposium on Operating systems principles, Dezembro de Cerbelaud, D., Garg, S., Huylebroeck, J. (2009) Opening the clouds: qualitative overview of the state-of-the-art open source VM-based cloud management platforms, 10th ACM/IFIP/USENIX International Conference on Middleware, Dezembro de Citrix Systems (2010) Xen Hypervisor, Dejun J., Pierre, G., Chi, C. (2009) EC2 Performance Analysis for Resource Provisioning of Service-Oriented Applications, NFPSLAM-SOC, Novembro de EC2 (2012). Amazon Elastic Compute Cloud. Endo, P., Gonçalves, G., Kelner, J., Sadok, D. (2010) A Survey on Open Source Cloud Computing Solutions, VIII Workshop em Clouds, Grids e Aplicações (WCGA), pp.3-16, Maio de Lenk, A., Menzel, M., Lipsky, J., Tai, S., Offermann, P. (2011) "What Are You Paying For? Performance Benchmarking for Infrastructure-as-a-Service Offerings," IEEE Cloud Computing (CLOUD), pp , Julho de OpenNebula (2012). OpenNebula Project. The Open Source Toolkit for Cloud Computing, Disponível em Peng, J., Zhang, X., Lei, Z., Zhang, B., Zhang, W., Li, Q. (2009) "Comparison of Several Cloud Computing Platforms", 2nd Intl. Symposium on Information Science and Engineering (ISISE), 2009, pp.23-28, Dezembro de Sempolinski, P., Thain, D. (2011) "A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus", 2nd IEEE Cloud Computing Technology and Science (CloudCom), 2010, pp , Fevereiro de Ueda, Y., Nakatani, T. (2010) "Performance variations of two open-source cloud platforms", Workload Characterization (IISWC), 2010 IEEE International Symposium on, pp.1-10, Dezembro de 2010.