Avaliação de estratégias de composição de nuvem computacional

Avaliação de estratégias de composição de nuvem computacional Bruno T. Caetano, Carlos A. Kamienski Universidade Federal do ABC (UFACB) Avenida dos Estados 5001 09.210-580 Santo André SP Brasil {bruno.caetano, cak}@ufabc.edu.br Abstract. Cloud computing has become popular in recent years for providing on-demand resources. Despite the cloud services promise high availability, recent studies indicate that the only way to achieve it is by using different cloud platforms, which is not always easy since they are not unified. This work extends and evaluates the E2ECloud middleware focusing two composition models, network and cloud, in different cloud controllers. The results showed that different strategies for composition may influence the performance of the controller and the application which it is running. It was also developed and evaluated a middleware for clouds composition. Resumo. A computação em nuvem tem se tornado popular nos últimos anos por prover recursos on-demand. Apesar de os serviços de nuvem prometerem alta disponibilidade, trabalhos recentes indicam que a única maneira de consegui-la é através da utilização de diferentes plataformas, o que nem sempre é fácil tendo sabendo que tais plataformas não são unificadas. Neste trabalho estendeu-se e avaliou-se o middleware E2ECloud focando em dois modelos de composição: rede e nuvem, em diferentes controladores. Os resultados mostraram que diferentes estratégias de composição podem influenciar tanto o desempenho do controlador quanto da aplicação. Também foi desenvolvido e avaliado um middleware de composição de nuvens. 1. Introdução O processamento de aplicações distribuídas em grande escala e com alto volume de dados e usuários era feito através de mainframes, contudo, o surgimento dos computadores pessoais e a sua posterior interligação em rede possibilitou o desenvolvimento de outras aplicações para os sistemas distribuídos [Abnader e Lins, 2006]. A computação em nuvem surge como um paradigma mais recente da computação distribuída, pois embora por um lado ela não possa ser considerada exatamente como um conceito novo ao utilizar abordagens e práticas que já foram previamente estabelecidas, por outro ela inova ao permitir inventar, desenvolver, implantar, escalar, atualizar, manter e pagar por aplicações e pela infraestrutura em que elas são executadas [Sun 2009]. Apesar das plataformas de computação em nuvem prometerem alta disponibilidade, Armbrust et al. (2010) afirmam que a única solução plausível para prover essa disponibilidade é o uso de múltiplos provedores. As plataformas atuais não possuem padrões unificados, cada uma tem suas próprias APIs, camadas de

virtualização, diferentes serviços, etc., o que dificulta aos usuários a realização de tarefas que integrem informações ou serviços de diferentes plataformas, prendendo-os a um único provedor de nuvem. A composição de serviços se mostra como uma solução em potencial para o problema da falta de padrões de comunicação entre nuvens computacionais. Através dos conceitos de orquestração e coreografia há a possibilidade de que diferentes provedores se comuniquem de maneira simples e eficiente. O projeto AltoStratus teve como objetivo apresentar soluções de middleware para a composição, execução e gerenciamento de serviços em nuvens híbridas e heterogêneas. O paradigma de serviços aborda as ações de publicar, descobrir e compor serviços, enquanto que o paradigma de nuvem foca na execução de serviços virtuais, ou seja, independência de localização e plataforma computacional específica. Um dos subprodutos desse projeto é o E2ECloud, um protótipo para a criação e composição de serviços em ambientes de nuvem. Sua implementação foi realizada em diferentes provedores, como o OpenNebula 1, Xen 2 e o Amazon EC2 3. O objetivo desse trabalho é realizar a portabilidade do E2ECloud para que haja suporte para o controlador de nuvem OpenStack 4 e KVM 5 e estudar e implementar estratégias do modelo integrado de composição em nuvem computacional nessas plataformas. Também é avaliada uma estratégia de composição de redes utilizando VPN. Os resultados mostram que diferentes estratégias de composição podem impactar tanto a aplicação que está em execução na nuvem quanto de seus controladores. Além disso, foi proposto, desenvolvido e avaliado um middleware de composição de nuvens computacionais que pode ser executado sobre diferentes controladores. Observou-se que seu desempenho aproxima-se à média do desempenho de cada controlador que o compõe. Por fim, estudou-se uma estratégia de migração de máquinas virtuais entre dois controladores, nela observou-se que a transferência do snapshot da máquina virtual pode ser um gargalo desse processo. Este trabalho se organiza da seguinte forma: A seção 2 apresenta o referencial teórico necessário para entendimento do trabalho; A seção 3 apresenta os trabalhos relacionados a este e seus diferenciais; A seção 4 apresenta a metodologia adotada nos experimentos realizados; A seção 5 apresenta os resultados obtidos e, por fim, a seção 6 apresenta as conclusões. 2. Referencial Teórico A expressão computação em nuvem popularizou-se recentemente junto à comunidade de computação distribuída. Muitos enxergam o seu surgimento como algo que pode revolucionar a área de Tecnologia da Informação. Segundo Dilon et al. (2010) o 1 http://opennebula.org 2 http://www.xenproject.org/ 3 http://aws.amazon.com/ec2/ 4 http://www.openstack.org/ 5 http://www.linux-kvm.org/page/main_page

mundo da computação está se transformando rapidamente no sentido de desenvolver softwares para milhões de usuários utilizá-los como um serviço, ao invés de executá-los em seus computadores individuais. Esta seção apresentará conceitos de computação em nuvem necessários para a compreensão deste trabalho. Além disso, serão apresentados conceitos de composição em nuvem computacional através do modelo de composição integrada para colaboração na nuvem, originado do projeto AltoStratus e, por fim, é apresentado o projeto AltoStratus em si. 2.1 Computação em Nuvem Computação em nuvem é o paradigma que tem como ideia prover recursos dinamicamente escaláveis e geralmente virtualizados a usuários. Dessa forma, os serviços de tecnologia da informação podem ser oferecidos sob demanda sobre a internet [Armbrust et al. 2010]. Assim, empresas que necessitem de serviços computacionais de alto desempenho podem obtê-lo de acordo com a necessidade de escalabilidade de seus programas. Através da computação em nuvem, utilizar mil servidores por uma hora não custa mais do que utilizar um servidor por mil horas. De acordo com o National Institute of Standards and Technology [Nist 2013], a computação em nuvem é um modelo ubíquo, conveniente, sob demanda e de acesso a recursos computacionais configuráveis como redes, servidores, armazenamento, aplicações e serviços que podem ser provisionados e liberados rapidamente com o mínimo esforço de gerenciamento ou interação. Algumas das características da computação em nuvem são: Serviço Sob Demanda: Os serviços devem ser capazes de provisionar recursos computacionais unilateralmente conforme solicitações de usuários. Acesso de Rede: Alta disponibilidade de acesso através da rede por mecanismos conhecidos, como terminais, celulares e tablets. Resource Pooling: Os recursos computacionais devem ser agrupados de forma a atender vários usuários através de um modelo multi-tenant com diferentes recursos físicos e virtuais que devem ser atribuídos e distribuídos de acordo com suas demandas. Rápida Elasticidade: Os recursos devem ser provisionados e liberados rapidamente conforme a necessidade dos consumidores. Serviço de Medição: Deve existir a possibilidade de se medir, controlar e monitorar os recursos que estão sendo fornecidos. 2.2 Modelo de Composição Integrada para Colaboração na Nuvem O trabalho de Kamienski et al. (2012) apresenta um modelo de composição integrada para colaboração em nuvem. Esse trabalho propõe a composição em cinco classes gerais: serviços, informação, recursos, rede e nuvem. Ele apresenta uma arquitetura que combina tais classes através de modelos de serviço de nuvem i.e. SaaS, PaaS e IaaS por um middleware de integração e colaboração. A composição de serviços é uma agregação coordenada de serviços que são montados para prover alguma funcionalidade requerida para automatizar um processo ou tarefa específicos de um negócio [Erl 2007]. Segundo o SOA, qualquer serviço deve

ser capaz de participar de uma composição e para isso são utilizadas basicamente duas técnicas: orquestração e coreografia. A composição da informação é um mecanismo onde se agrega informação de diferentes entidades transparentes e com visibilidade e acesso unificado para os usuários. Tais informações independem de sua localização. Essa ideia baseia-se no alto acoplamento dentre provedores de informação, contrapondo o modelo tradicional baseado em protocolos com troca de mensagens. A composição de recursos consiste em agregar recursos computacionais distribuídos de forma que os mesmo sejam visíveis às entidades externas como um único recurso computacional. Esse conceito parte da generalização do conceito de máquinas virtuais e pode ser usado em vários ambientes de nuvem. Tal composição pode ser dada de diferentes maneiras: composição de máquina, composição de processador, composição de memória, composição de armazenamento e composição de redes. Todas consistem de componentes menores que agregados são capazes de realizar tarefas de maneira mais eficiente e transparente ao usuário. A composição de nuvem consiste em agregar duas ou mais entidades de valor computacional para que seja permitido processamento distribuído e acesso remoto com transparência, flexibilidade, agilidade, elasticidade e escalabilidade. A composição em nuvem computacional pode ser aplicada de acordo com a Figura 1. Este modelo baseia-se em middlewares em níveis específicos da nuvem. Nele todos os serviços da nuvem são expostos aos usuários através de uma interface de serviços. Middleware de Nuvem - AltoStratus SaaS PaaS IaaS SaaS Middleware SaaS PaaS Composição de Serviços Middleware PaaS IaaS Composição de Informação Middleware IaaS Composição de Recursos Composição de Redes Composição de Nuvem Figura 1 - Modelo Integrado para composição em nuvem [Kamienski et al. 2014]

2.3 Projeto AltoStratus O AltoStratus foi um projeto composto por oito instituições brasileiras que tinha por objetivo especificar, implantar e avaliar técnicas e mecanismos de middleware para composição, execução e gerenciamento de serviços em ambiente de nuvens computacionais híbridas e heterogêneas. Para maior agilidade e autonomia, dividiu-se o projeto em quatro núcleos encarregados de executar e gerenciar o desenvolvimento de seu próprio conjunto de produtos e serviços. Tais núcleos ficaram responsáveis pelos seguintes temas: Composição e interoperabilidade de serviços e tolerância a falhas; Escalonamento e segurança; Composição de serviços; Implantação e gerenciamento de aplicações. Um de seus resultados foi a construção de um middleware de composição de serviços em nuvem computacional chamado E2ECloud [Kamienski et al., 2014]. Esse serviço é capaz de compor serviços e alocá-los em máquinas virtuais em um provedor de nuvem. O middleware E2ECloud é composto basicamente por 4 módulos computacionais que se comunicam através de web services. A saber: uma ferramenta da criação de serviços, um middleware de posicionamento e elasticidade, um gerador de carga de trabalho e uma infraestrutura de nuvem e código de serviço. Esse modelo pode ser visto a partir da Figura 2. O E2ECloud a princípio foi desenvolvido para ser executado em dois controladores de nuvem: OpenNebula e Amazon EC2 e um hypervisor, Xen. Figura 2 - Arquitetura do middleware E2ECloud 3. Trabalhos Relacionados Há um grande número de trabalhos sobre avalição de desempenho de computação em nuvem. Em Voras et al. (2011) os autores elaboraram um conjunto de critérios que podem ser utilizados para a avalição e comparação de soluções IaaS de software livre para computação em nuvem, dentre elas estão segurança, armazenamento, virtualização,

gerenciamento, rede e suporte. Através delas elaborou-se um ranking para a escolha do produto mais adequado para determinada aplicação. Em Peng et al. (2009) e Sempolinski e Thain (2010), foram analisadas e comparadas diferentes plataformas de computação em nuvem levando em conta suas características, arquiteturas, vantagens e desvantagens. Dessa maneira um usuário seria capaz de entender e escolher de maneira mais eficiente a plataforma indicada para o que lhe convém. Garg et al. (2013) realizou uma avaliação de desempenho e comparação de diferentes fornecedores de nuvem na qual foram propostas métricas para comparação entre as plataformas. Azevedo et al. (2012) avaliaram o desempenho de nuvens públicas e privadas visando operações básicas sobre máquinas virtuais. Seus resultados mostraram que a utilização de um controlador de nuvem sobre um hypervisor influencia diretamente sobre seu desempenho, principalmente devido ao tempo de cópia de imagem do sistema. Além disso, observou-se que a escolha do usuário dentre diferentes controladores de nuvem depende de uma combinação de critérios técnicos e estratégicos. Os trabalhos citados estão relacionados à avaliação de desempenho de provedores de nuvem e/ou comparações entre esses provedores. Diferente deste trabalho, que apresenta uma comparação de diferentes provedores utilizando um middleware desenvolvido especificamente para aplicar o modelo de composição em nuvem computacional. Além disso, a maioria dos trabalhos encontrados trata apenas da composição de serviços computacionais, sendo que a composição de nuvens computacionais ainda se apresenta como uma lacuna que deve ser estudada e avaliada. Alguns trabalhos como o de Grozev e Buyya (2012) e Toosi et al (2014) apresentam o Inter-cloud, uma nuvem de nuvens, discutindo possíveis obstáculos que poderiam ser encontrados em sua concepção e posterior desenvolvimento, assim como estratégias para contorná-los. 4. Metodologia Visando estudar estratégias de composição em nuvem, inicialmente o middlware E2ECloud foi portado e estendido para que fosse executado sobre o hypervisor KVM baremetal e os controladores de nuvem OpenStack e OpenNebula, ambos utilizando KVM. Optou-se por esses controladores por serem os mais populares atualmente. O hypervisor KVM foi utilizado devido à facilidade de implantação nos controladores citados anteriormente. Inicialmente tratou-se a composição de redes utilizando a abordagem de aplicar uma VPN em diferentes pontos de comunicação na nuvem. Posteriormente desenvolveu-se e avaliou-se um middleware de composição de nuvens. A composição de serviços não será tratada neste trabalho, uma vez que já foi estudada por Kamienski et al. (2014). Nos experimentos de composição de rede configuraram-se os controladores de nuvem a partir de uma arquitetura de dois pontos: 1. Nó, responsável por executar máquinas virtuais; 2. Controlador, responsável por gerenciar e criar máquinas virtuais no nó. As imagens de máquinas virtuais ficam armazenadas no controlador e são transferidas para o nó. No caso do KVM aplicado baremetal utilizou-se apenas um servidor contendo o hypervisor, logo, não há o processo de transferência de imagem, uma vez que ela já está armazenada no próprio servidor que o executa.

A Figura 3a apresenta uma configuração em LAN da arquitetura utilizada nos experimentos. Esta configuração é a utilizada por padrão nos controladores em teste, a transferência da imagem de máquina virtual é realizada do controlador para o nó por LAN por ssh e as máquinas virtuais se comunicam por LAN. Cenário 0: C0 (a) Cenário 1: C1 (b) Cenário 2: C2 (c) Figura 3 - Arquiteturas dos experimentos O middleware E2ECloud utiliza uma composição de quatro serviços relacionados à tradução de músicas (Lyrics, Translate, Email e Billing) que são executados por um servidor de aplicações, a saber, Tomcat. Tais serviços são desenvolvidos em Java e comunicam-se através da biblioteca de orquestração Apache ODE. Neste experimento cria-se uma máquina virtual para cada serviço e observam-se as seguintes métricas: 1. Tempo de cópia da imagem: Tempo em segundos para que a imagem de uma máquina virtual seja transferida entre controlador e nó. 2. Tempo de inicialização: Tempo em segundos de inicialização de uma máquina virtual e responda a comandos do usuário. 3. Tempo de inicialização do Tomcat: Tempo em segundos para que o servidor de aplicações Tomcat seja iniciado na máquina virtual. 4. Tempo de cópia do serviço: Tempo necessário para que o serviço seja transferido à máquina virtual. 5. Tempo de resposta do serviço: Tempo necessário para que o serviço responda às requisições do usuário. Para avaliar a composição de redes aplicou-se uma VPN, a saber, o Hamachi 6, em dois pontos da arquitetura proposta. Inicialmente utiliza-se a VPN na comunicação entre as máquinas virtuais de um nó, conforme a Figura 3b. Neste experimento a 6 https://secure.logmein.com/br/products/hamachi/

transferência de serviços entre as máquinas ocorre através da VPN enquanto a comunicação entre controlador e nó ocorre por LAN. Deu-se o nome de Cenário 1 a essa configuração. O segundo cenário (Cenário 2) proposto liga controlador e nó através da VPN, sendo esta responsável pela transferência de imagem e comandos entre as duas partes, tal cenário pode ser observado na Figura 3c. Utilizou-se a VPN como estratégia de composição devido à sua facilidade de configuração e aplicação no ambiente. Para obter relevância estatística utilizou-se o teorema central do limite onde se repetiu ao experimento 30 vezes, calculou-se a média e intervalo de confiança de 99%. Para a análise da composição de nuvem computacional desenvolveu-se um experimento em duas etapas. Na primeira desenvolveu-se um middleware capaz de realizar manipulações básicas de máquinas virtuais em diferentes controladores de nuvem através de uma linguagem comum. Com isso, as chamadas aos controladores são realizadas de maneira transparente ao usuário. A Figura 4 apresenta um esquema simplificado do middleware proposto para a implementação de composição em nuvem computacional. Nela é possível verificar em uma arquitetura em três camadas, na central (2) o middleware é responsável por realizar uma interface entre os controladores de nuvem (3) e chamadas do usuário (1). O núcleo do middleware é apresentado em (2). Nele há o gerenciamento dos diferentes controladores de nuvem a partir de uma interface Java para os comandos básicos de manipulação de máquinas virtuais descritos em 1. Cada comando é traduzido para o controlador selecionado, o qual é responsável por realizar a manipulação da máquina virtual em si. Para a seleção de qual controlador criará a máquina virtual utilizou-se o algoritmo de Round Robin. Para analisar o desempenho do middleware proposto utilizou-se o E2ECloud, o qual foi portado para o mesmo, que faz o papel de controlador de máquinas virtuais. Neste experimento utilizaram-se as mesmas métricas descritas anteriormente, porém optou-se por utilizar uma arquitetura onde os controladores e o middleware encontramse no mesmo servidor, portanto descartou-se a métrica de cópia de imagem (1). Figura 4 - Middleware proposto para composição de nuvem computacional A segunda etapa do experimento consistiu em transferir uma máquina virtual em execução entre dois controladores distintos. Nela utilizou-se o controlador OpenStack em modo standalone, ou seja, com todos seus módulos são executados por uma mesma

máquina, em dois servidores ligados por uma rede gigabit e realizaram-se os seguintes passos 7 : 1. Exportar a máquina virtual para um arquivo através do serviço de snapshot fornecido pelo OpenStack. 2. Transferir por scp o arquivo criado do Controlador 1 para o Controlador 2; 3. Recriar e iniciar a máquina virtual no Controlador 2; 4. Reconfigurar a composição de serviços em execução para utilizá-la. Neste caso também se utilizou o serviço de composição de testes do AltoStratus descrito nos experimentos anteriores. 5. Destruir a máquina virtual do Controlador 1. A Figura 5 apresenta um esquema simplificado do experimento. Em 1 nota-se que as máquinas virtuais estão em execução no Controlador 1, onde ocorre o processo de snapshot e a máquina é transferida para o Controlador 2. Posteriormente em (2) a máquina é colocada em execução no Controlador 2 e destruída no Controlador 1. A transferência ocorre por scp onde os controladores estão ligados em uma rede gigabit em LAN. Em ambos os experimentos de composição de nuvem aplicou-se o teorema central do limite, os replicando 30 vezes e calculando intervalo de confiança de 99%. Figura 5 - Experimentos de composição de nuvem Em todos os experimentos utilizam-se máquinas virtuais idênticas com a seguinte configuração: CPU single core, 512 MB de memória RAM, disco virtual de 5GB. 5. Resultados Esta seção apresentará os resultados dos experimentos propostos. Inicialmente apresentam-se os resultados referentes à composição de redes na seção 5.1 através da 7 Metodologia obtida a partir da documentação do OpenStack disponível em: http://docs.openstack.org/user-guide/content/cli_migrate_instances.html

análise de desempenho do middleware AltoStratus nos três cenários estudados. Posteriormente na seção 5.2 apresentam-se os resultados referentes à composição de nuvens computacionais. A princípio apresentam-se os resultados da análise de desempenho do middleware de composição de nuvem proposto neste trabalho e, por fim, apresentam-se os resultados referentes à transferência de máquinas virtuais entre dois controladores OpenStack. Para a apresentação dos resultados utilizam-se as seguintes siglas: ON: OpenStack; ON: OpenNebula; MW: Middleware de composição de nuvens proposto. 5.1 Composição de redes A Figura 6a apresenta o tempo de cópia da imagem de máquina virtual entre o controlador e seu nó, nela verifica-se que a existência da VPN influencia diretamente o tempo de cópia de imagem. Isso está principalmente relacionado à rota realizada pela imagem para que se chegue ao nó. Em uma ligação direta entre controlador e nó, como em LAN C0 e VPN C1, a imagem é transferida por rede local e em alta velocidade. Ao utilizar a VPN na comunicação entre controlador e nó, como em C2, há uma série de passos realizados: por ser uma rede segura, a imagem transferida deve ser criptografada, transmitida aos servidores do Hamachi pela Internet e posteriormente ao nó. (a) Tempo de cópia da imagem (b) Tempo de boot da VM (c) Tempo de inicialização do Tomcat (d) Tempo de cópia do serviço

(e) Tempo de resposta do serviço Legenda Figura 6 - Resultados do Middleware Altostratus - Composição de redes Analisando em conjunto as Figura 6b, 6c e 6e, é possível verificar que não há grande influência da composição de rede nessas operações. Explica-se esse comportamento, pois quem executa essas operações são as máquinas virtuais. Além disso, são operações independentes de comunicação com controlador e/ou máquinas virtuais, dessa forma, apresentam poucas variações de tempo de execução. A Figura 6d apresenta o tempo de cópia do serviço entre as máquinas virtuais. Nela é nota-se que a VPN C1, apresenta valores maiores para essa métrica. O motivo desse comportamento está relacionado à natureza da VPN. Nela, quando um serviço é distribuído para uma máquina virtual, ocorre o mesmo processo de transferência descrito no tempo de cópia de imagem apresentado anteriormente. 5.2 Composição de nuvens computacionais A Figura 7 apresenta a comparação de desempenho entre o middleware de composição de nuvem proposto neste trabalho e os resultados individuais de controladores de nuvem que o compõe. A Figura 7a apresenta a comparação do tempo médio de boot das máquinas virtuais, nela nota-se que o desempenho do middleware desenvolvido é semelhante à média de desempenho de cada um de seus controladores. Esse comportamento está relacionado à estratégia utilizada na criação de máquinas virtuais. Por se tratar basicamente de uma fila circular, as máquinas virtuais são criadas aproximadamente na mesma quantidade de vezes nos três controladores, dessa forma, seu tempo de criação é próximo da média de tempo dos três controladores. As Figura 7b, 7c e 7d mostram respectivamente o tempo médio de inicialização do Tomcat, o tempo de cópia do serviço e o tempo de inicialização do serviço. Nota-se que nas três figuras a média do tempo de execução do middleware está próximo à média de tempo de execução de cada controlador isolado. Isso está relacionado à configuração de hardware das máquinas virtuais serem as mesmas no OpenStack, OpenNebula e KVM. Outro ponto que contribui a esse comportamento é o fato dos controladores utilizarem o mesmo hypervisor, desta forma, a virtualização das máquinas ocorre da mesma forma, indepentemente do controlador utilizado para criá-la. O intervalo de confiança apresentou-se mínimo, portanto foi omitido do gráfico.

(a) Tempo de boot da máquina virtual (b) Tempo de inicialização do Tomcat (c) Tempo de cópia do serviço (d) Tempo de inicialização do serviço Figura 7 - Resultados do middleware de composição de nuvem A Figura 8 apresenta o tempo médio do processo de migração de máquina virtual entre dois controladores OpenStack. Nela nota-se que a etapa que demanda mais tempo durante a migração é a transferência do snapshot entre os dois servidores, porém observa-se que sua média é próxima à transferência de imagens entre host e nó no OpenStack, provavelmente por utilizar a mesma tecnologia de transferência. Pode-se observar que neste caso a transferência do snapshot pode se tornar um gargalo para a migração de máquinas virtuais. Nos gráficos apresentados o intervalo de confiança apresentou-se mínimo, então foi omitido. Figura 8 - Resultados de migração de máquina virtual Os tempos de inicialização e reconfiguração do serviço da máquina virtual são quantitativamente semelhantes aos tempos apresentados pelo controlador quando não há o processo de migração, ou seja, em seu funcionamento normal. Isso ocorre devido ao snapshot gerado pelo OpenStack corresponder a um arquivo de imagem utilizado na criação de máquinas virtuais, portanto o tempo de inicialização é próximo à inicialização de uma máquina virtual criada e gerenciada pelo controlador. Em um

ambiente onde as nuvens computacionais estejam em redes diferentes e que suas máquinas virtuais utilizam ip privados, por exemplo, há a possibilidade de aplicar estratégias de composição de rede. 6. Conclusões Esse trabalho apresentou resultados da avaliação de estratégias de composição em nuvem computacional. Inicialmente analisou-se a utilização de VPN como estratégia de composição de rede em pontos específicos da nuvem. Notou-se que sua utilização pode interferir negativamente tanto no desempenho do controlador de nuvem quanto no da aplicação em execução. Nos experimentos executados, ao aplicá-la em qualquer ponto, adiciona-se um passo que deve ser realizado durante a comunicação: a transferência de informação através da internet, que é notavelmente mais lenta do que em rede local. A alta disponibilidade está diretamente relacionada à utilização de diferentes provedores de nuvem e uma estratégia que pode ser utilizada nesse sentido é a composição de nuvens computacionais. Para validar e verificar estratégias de composição de nuvem foi proposto um middleware de composição. Sua análise mostra que seu desempenho depende diretamente dos diferentes controladores de nuvem que estão sendo acessados pelo middleware. Posteriormente verificou-se a possibilidade da migração de máquinas virtuais entre diferentes nuvens, o que se mostrou semelhante à criação de uma nova máquina virtual em um controlador, com um novo passo: o snapshot. Em trabalhos futuros é importante considerar como diferentes hypervisores podem influenciar o desempenho dos controladores de nuvem nos diferentes cenários propostos por esse trabalho. Atualmente novos controladores estão sendo inseridos no mercado, então seria importante também os avaliar. Considerando a utilização de VPN para a composição de redes, podem-se discutir novas estratégias, utilizando outras tecnologias ou outros produtos. Além disso, é necessário estudar composições não cobertas nesse trabalho, como a composição de recursos e informação buscando a mais eficiente e a que melhor se adapta a diferentes cenários. Dessa forma será possível analisar o modelo completo de composição integrada para colaboração na nuvem. Por fim, há a possibilidade de aperfeiçoar o middleware proposto para a composição de nuvens computacionais. Alguns pontos que podem ser mais bem estudados estão relacionados ao algoritmo de distribuição de máquinas virtuais entre os controladores, onde se pode considerar, por exemplo, algum tipo de balanceamento de carga; aumentar o suporte a controladores de nuvem, incluindo novos controladores e/ou diferentes hypervisores; e propor uma arquitetura distribuída, onde cada controlador ficaria alocado em um servidor. Também há a necessidade de realizar testes com migração de máquinas virtuais para nuvens públicas, como a Amazon EC2. Referências Abinader, J.A., Lins, R.D., Web Services em Java, São Paulo: Brasport, 2006 Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, M., A View of Cloud Computing, Communications of the ACM, 53(4), p. 50-58, 2010

Azevêdo, E ; Dias, C ; Dantas, R ; Sadok, D ; Fernandes, S ; Simoes, R. ; Kamienski, C. Profiling core operations for elasticity in cloud environments. In: 2012 IEEE Latin America Conference on Cloud Computing and Communications (LatinCloud), 2012, Porto Alegre. 2012 IEEE Latin America Conference on Cloud Computing and Communications (LatinCloud). v. 1. p. 43-6 Dillon, T., Wu, Che., Chang, E., Cloud Computing: Issues and Challenges Aina, pp.27-33,24th IEEE International Conference on Advanced Information Networking and Applications, 2010 Erl, T., SOA Principles of Service Design, Prentice Hall PTR, 2007 Garg, S.K., Versteeg, S., Buyya. R. A framework for ranking of cloud computing services future Gener Comput Syst, 29 (4) (2013), pp. 1012 1023 Grozev, N., Buyya, R., Inter-cloud architectures and application brokering: Taxonomy and suvey. Software: Practice and Experience, 2012 Kamienski, C., Simoes, R., Azevedo, E., Dantas, R., Dias, C., Sadok, D., Fernandes, S., An Integrated Composition Model for Collaboration in the Cloud, Proceedings of the LatinCloud 2012-2012 IEEE Latin America Conference on Cloud Computing and Communications, Porto Alegre, RS, Brazil. Piscataway, NJ, USA: IEEE Computer Society, pp. 19-24 Kamienski, C., Simoes, R., Azevedo, E., Dantas, R., Dias, C., Sadok, D., Fernandes, S., E2ECloud: Composition and execution of end-to-end services in the cloud, Proceedings of the 19 th IEEE Symposium on Computers and Communications. USA: IEEE, 2014. pp. 1-6 Peng J, Zhang X, Lei Z, Zhang B, Zhang W, Li Q. Comparison of Several Cloud Computing Platforms. IN: 2ND International Symposium on Information Science and Engineering. Shanghai, Hong Kong; December 26 28, 2009. PP. 23 7 Sempolinski P, Thain D. A Comparison and Critique of Eucalyptus, Opennebula and Nimbus. IN: 2ND Ieee International Conference on Cloud Computing Technology and Science, Indianapolis, Usa; November 30, 2010 To December 3, 2010. P. 417 6 SUN MICROSYSTEMS, INC. Introduction to Cloud Computing Architecture. White Paper, 1a edição, junho 2009a. Disponível em: https://java.net/jira/secure/attachment/29265/cloudcomputing.pdf. Acessado em junho de 2013 The Nist definition of cloud computing. Disponível em http://csrc.nist.gov/publications/nistpubs/800-145/sp800-145.pdf. Acessado em maio de 2013 Toosi, A., Calheiros, R., Buyya, R., Interconnected Cloud Computing Environments: Challenges, Taxonomy, and Survey, ACM Computing Surveys, v47 p1-47, 2014 Voras I, Mihaljevic B, Orlic M. Criteria for evaluation of open source cloud computing solutions. In: 33rd International Conference on Information Technology Interfaces, Dubrovnik, Croatia, June 27 30, 2011. P. 137 42