Anais XII Workshop de Computação em Clouds e Aplicações WCGA 2014

Transcrição

1 Anais XII Workshop de Computação em Clouds e Aplicações WCGA 2014

2 XXXII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 5 a 9 de Maio de 2014 Florianópolis - SC Anais XII Workshop de Computação em Clouds e Aplicações (WCGA 2014) Editora Sociedade Brasileira de Computação (SBC) Organizadores Bruno Schulze (LNCC) Danielo G. Gomes (UFC) Luiz Bittencourt (UNICAMP) Carlos André Guimarães Ferraz (UFPE) Joni da Silva Fraga (UFSC) Frank Siqueira (UFSC) Realização Universidade Federal de Santa Catarina (UFSC) Promoção Sociedade Brasileira de Computação (SBC) Laboratório Nacional de Redes de Computadores (LARC)

3 Copyright 2014 da Sociedade Brasileira de Computação Todos os direitos reservados Capa: Vanessa Umbelino (PostMix) Produção Editorial: Roberto Willrich (UFSC) Cópias Adicionais: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, Setor 4 - Prédio Sala 219 Bairro Agronomia - CEP Porto Alegre- RS Fone: (51) sbc@sbc.org.br SC) Workshop de Computação em Clouds e Aplicações (12: 2014: Florianópolis, Anais / XII Workshop de Computação em Clouds e Aplicações; organizado por Bruno Schulze... [et al.] - Porto Alegre: SBC, c p. WCGA 2014 Realização: Universidade Federal de Santa Catarina ISSN: X 1. Redes de Computadores - Congressos. 2. Sistemas Distribuídos Congressos. I. Schulze, Bruno. II. Sociedade Brasileira de Computação. III. Título. i

4 Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente Paulo Roberto Freire Cunha (UFPE) Vice-Presidente Lisandro Zambenedetti Granville (UFRGS) Diretora Administrativa Renata de Matos Galante (UFRGS) Diretor de Finanças Carlos André Guimarães Ferraz (UFPE) Diretor de Eventos e Comissões Especiais Altigran Soares da Silva (UFAM) Diretora de Educação Mirella Moura Moro (UFMG) Diretor de Publicações José Viterbo Filho (UFF) Diretora de Planejamento e Programas Especiais Claudia Lage Rebello da Motta (UFRJ) Diretor de Secretarias Regionais Marcelo Duduchi Feitosa (CEETEPS) Diretor de Divulgação e Marketing Edson Norberto Caceres (UFMS) Diretor de Relações Profissionais Roberto da Silva Bigonha (UFMG) Diretor de Competições Científicas Ricardo de Oliveira Anido (UNICAMP) Diretor de Cooperação com Sociedades Científicas Raimundo José de Araujo Macêdo (UFBA) Diretor de Articulação de Empresas Avelino Francisco Zorzo (PUC-RS) ii

5 Promoção Sociedade Brasileira de Computação (SBC) Conselho Mandato Alfredo Goldman (IME/USP) José Palazzo Moreira de Oliveira (UFRGS) Maria Cristina Ferreira de Oliveira (ICMC/USP) Thais Vasconcelos Batista (UFRN) Wagner Meira Junior (UFMG) Mandato Ariadne Carvalho (UNICAMP) Carlos Eduardo Ferreira (IME - USP) Jose Carlos Maldonado (ICMC - USP) Luiz Fernando Gomes Soares (PUC-Rio) Marcelo Walter (UFRGS) Suplentes Alessandro Fabrício Garcia (PUC-Rio) Aline Maria Santos Andrade (UFBA) Daltro José Nunes (UFRGS) Karin Koogan Breitman (PUC-Rio) Rodolfo Jardim de Azevedo (UNICAMP-IC) iii

6 Promoção Laboratório Nacional de Redes de Computadores (LARC) Diretoria Diretor do Conselho Técnico-Científico Elias P. Duarte Jr. (UFPR) Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Vice-Diretora do Conselho Técnico-Científico Rossana Maria de C. Andrade (UFC) Vice-Diretor Executivo Paulo André da Silva Gonçalves (UFPE) Membros Institucionais SESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG (ex-ufpb Campus Campina Grande), UFRJ, USP, PUC-Rio, UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF, UFSCar, CEFET-CE, UFRN, UFES, UFBA, UNIFACS, UECE, UFPR, UFPA, UFAM, UFABC, PUCPR, UFMS, UnB, PUC-RS, UNIRIO, UFS e UFU. iv

7 Realização Comitê de Organização Coordenação Geral Joni da Silva Fraga (UFSC) Frank Augusto Siqueira (UFSC) Coordenação do WCGA Bruno Schulze (LNCC) Danielo G. Gomes (UFC) Luiz Bittencourt (UNICAMP) Coordenação de Workshops Carlos André Guimarães Ferraz (UFPE) v

8 Realização Organização Local Carlos Barros Montez (UFSC) Edison Tadeu Lopes Melo (UFSC) Guilherme Eliseu Rhoden (PoP-SC) Leandro Becker (UFSC) Mário A. R. Dantas (UFSC) Michelle Wangham (Univali) Ricardo Felipe Custódio (UFSC) Roberto Willrich (UFSC) Rodrigo Pescador (PoP-SC) Rômulo Silva de Oliveira (UFSC) Secretaria do SBRC 2014 Juliana Clasen (UFSC) Jade Zart (UFSC) vi

9 Mensagem do Coordenador de Workshops do SBRC 2014 Confirmando a consolidação nos últimos anos, este ano o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de workshops, visando a discussão de temas novos e/ou específicos, como Internet do Futuro e Tolerância a Falhas. Os workshops envolvem comunidades focadas e oferecem oportunidades para discussões mais profundas e ampliação de conhecimentos, envolvendo pesquisadores e muitos estudantes em fase de desenvolvimento de seus trabalhos em andamento. Neste ano tivemos novas submissões, além dos workshops já considerados tradicionais parceiros do SBRC, o que representa o dinamismo da comunidade de Redes de Computadores e Sistemas Distribuídos no Brasil. Infelizmente, estas novas submissões não puderam ainda ser acomodadas, mas certamente serão consideradas para próximas edições do SBRC. Neste SBRC 2014, temos a realização de workshops já consolidados no circuito nacional de divulgação científica nas várias subáreas de Redes de Computadores e Sistemas Distribuídos, como o WGRS (Workshop de Gerência e Operação de Redes e Serviços), o WTF (Workshop de Testes e Tolerância a Falhas), o WCGA (Workshop de Computação em Clouds e Aplicações), o WP2P+ (Workshop de Redes P2P, Dinâmicas, Sociais e Orientadas a Conteúdo), o WRA (Workshop de Redes de Acesso em Banda Larga), o WoCCES (Workshop of Communication in Critical Embedded Systems), o WoSiDA (Workshop on Autonomic Distributed Systems) e o WPEIF (Workshop de Pesquisa Experimental da Internet do Futuro). Há que se mencionar a importante parceria com o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que em sua 15a edição, cumpre o importante papel de fazer a ponte entre as comunidades técnica e científica da área. Não tenho dúvida que a qualidade técnica e científica dos workshops se manterá em alta compatível com o SBRC. Agradeço aos Coordenadores Gerais, Joni da Silva Fraga e Frank Siqueira (UFSC), pelo convite para coordenar os workshops do SBRC 2014 e por todo o apoio recebido. Desejo muito sucesso e excelente participação nos Workshops do SBRC 2014! Carlos André Guimarães Ferraz (UFPE) Coordenador de Workshops do SBRC 2014 vii

10 Mensagem dos Coordenadores do WCGA 2014 Sejam bem-vindos ao XII Workshop de Computação em Clouds e Aplicações (WCGA 2014), evento realizado em Florianópolis-SC em conjunto com o 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2014). O WCGA tem se consolidado como um workshop que agrega um conjunto interessante de trabalhos envolvendo os mais diversos temas dentro da computação em nuvem e, historicamente, em grade. Como resultado, este fórum apresenta-se como um ambiente para discussões de técnicas de pesquisas em andamento e atividades relevantes nas áreas de infraestrutura real e virtualizada, serviços e diversas aplicações em nuvens computacionais, congregando pesquisadores e profissionais que atuam ativamente nestas áreas. O workshop também procura estabelecer redes colaborativas multiinstitucionais e grupos de competência técnico-científica, bem como fomentar a discussão de tópicos incipientes ainda sem rumos definidos dentro do escopo do WCGA. O workshop iniciou a evolução de grades computacionais para clouds em 2010, e tem dessa forma atraído submissões de grupos de pesquisa em todas as regiões do Brasil. Com essa evolução, o WCGA consolidou-se como um importante workshop em redes e sistemas distribuídos no país, alcançando em 2014 sua décima segunda edição. As primeiras edições do WCGA ( ) foram realizadas no LNCC, em Petrópolis-RJ. As edições de 2006, 2007, 2008, 2009, 2010, 2011, 2012 e 2013 foram realizadas em conjunto com o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC em Curitiba (PR), Belém (PA), Rio de Janeiro (RJ), Recife (PE), Gramado (RS), Campo Grande (MS), Ouro Preto (MG) e Brasília-DF. Os anais destas edições anteriores do WCGA apresentam ampla combinação de diferentes áreas de computação em grades e nuvens, como infraestrutura, middleware e aplicações, com apresentações técnicas fomentando discussões em vários tópicos relevantes. Nesta décima segunda edição do WCGA, de um total de 17 artigos submetidos, 8 artigos completos foram aceitos para publicação e apresentação no evento. Os tópicos abordados nos artigos aceitos têm acompanhado a evolução da pesquisa em clouds, e neste ano não é diferente: trabalhos envolvendo áreas importantes como elasticidade e análise de desempenho, além de gerência e alocação de recursos, consolidam-se como tópicos de interesse da comunidade de pesquisa em nuvem. Além disso, virtualização e escalabilidade também aparecem como temas fortes no contexto do workshop. Por último, mas não menos importante, arquiteturas para provisão de serviço em diferentes níveis, incluindo questões de acessibilidade, são propostas e discutidas no workshop. viii

11 Mensagem dos Coordenadores do WCGA 2014 A coordenação do WCGA agradece aos autores de todas as submissões recebidas e aos autores de artigos aceitos pela apresentação do trabalho e contribuições para evolução da pesquisa em computação em nuvem. Agradecemos especialmente a todos os revisores e aos membros do comitê de programa pelo compromisso de realizar um excelente trabalho de revisão dos artigos. Destacamos aqui, também, o apoio dos coordenadores gerais do SBRC 2014, Joni da Silva Fraga (UFSC) e Frank Siqueira (UFSC), do coordenador de workshops do SBRC 2014, Carlos André Guimarães Ferraz (UFPE) e do comitê de organização local na pessoa de Roberto Willrich (INE/UFSC), agradecendo seu trabalho e colaboração. Por fim, agradecemos as entidades que acolhem e apoiam os organizadores do WCGA e SBRC: Unicamp, UFC, LNCC, UFSC e SBC. Luiz Fernando Bittencourt, co-coordenador e co-editor Instituto de Computação Universidade Estadual de Campinas - Unicamp Danielo Gonçalves Gomes, co-coordenador e co-editor Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat) Universidade Federal do Ceará - UFC Bruno Schulze, co-coordenador e co-editor ComCiDis Computação Científica Distribuída, Laboratório Nacional de Computação Científica - LNCC ix

12 Comitê de Programa do WCGA 2014 Alba Melo (UnB) Antônio Tadeu Azevedo Gomes (LNCC) Antonio Mury (LNCC) Artur Ziviani (LNCC) Carlos Ferraz (UFPE) Cesar De Rose (PUCRS) Claudio Geyer (UFRGS) Cristina Boeres (UFF) Daniel Batista (USP) Daniel de Oliveira (UFF) Edmundo Madeira (UNICAMP) Fabio Costa (UFG) Fabricio da Silva (CETEX) Fernando Koch (IBM Research) Hélio Guardia (UFSCar) Hermes Senger (UFSCAR) José Neuman de Souza (UFC) Luis Carlos de Bona (UFPR) Luis Veiga (INESC-ID, PT) Marco Netto (IBM Research) Marcos Assunção (IBM Research) Nabor Mendonça (Unifor) Nelson Fonseca (UNICAMP) Noemi Rodrigues (PUC-Rio) Paulo Ferreira (INESC-ID, PT) Philippe Navaux (UFRGS) Raphael Camargo (UFABC) Rossana Andrade (UFC) Wagner Meira Jr. (UFMG) Walfredo Cirne (Google) x

13 Sumário Sessão Técnica 1 Desempenho... 1 Análise do Desempenho de Sistemas Operacionais Hospedeiros de Clusters Virtualizados com o VirtualBox David W. S. C. Beserra (UFRPB), Rubens K. P. da Silva, Kádna Camboim, Alexandre W. T. Borba, Jean C. T. de Araujo, Alberto E. P. de Araujo... 3 Análise de Escalabilidade de Aplicações Hadoop/MapReduce por meio de Simulação Fabiano da G. Rocha (UFSCar) e Hermes Senger Análise de Desempenho do Virtualizador KVM com o HPCC em Aplicações de CAD Rubens K. P. da Silva (UPE), David Willians S. C. Beserra, Patricia T. Endo e Sergio Galdino Sessão Técnica 2 Elasticidade Uma Proposta de Framework Conceitual para Análise de Desempenho da Elasticidade em Nuvens Computacionais Emanuel F. Coutinho (UFC), Danielo G. Gomes e José Neuman de Souza Métricas para Avaliação da Elasticidade em Computação em Nuvem Baseada em Conceitos da Física Emanuel F. Coutinho (UFC), Paulo A. L. Rego, Danielo G. Gomes e José Neuman de Souza Gerenciamento de Elasticidade em Nuvens Privadas e Híbridas Rhodney Simões (UFAL) e Carlos A. Kamienski Sessão Técnica 3 Arquitetura e Gerência Alocação de Máquinas Virtuais em Ambientes de Computação em Nuvem Considerando o Compartilhamento de Memória Fernando J. Muchalski (UTFPR), Carlos A. Maziero xi

14 Sumário Deaf Accessibility as a Service: uma Arquitetura Elástica e Tolerante a Falhas para o Sistema de Tradução VLIBRAS Eduardo L. Falcão (UFPB), Tiago Maritan e Alexandre N. Duarte Índice por Autor xii

15 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XII Workshop de Computação em Clouds e Aplicações (WCGA) Sessão Técnica 1 Desempenho

16

17 Análise do Desempenho de Sistemas Operacionais Hospedeiros de Clusters Virtualizados com o VirtualBox David Beserra 1, Rubens Karman 2, Kádna Camboim 1, Jean Araujo 1, Alexandre Borba 1, Alberto Araújo 1 1 Unidade Acadêmica de Garanhuns Universidade Federal Rural de Pernambuco (UFRPE) Garanhuns PE Brasil 2 Departamento de Computação Inteligente Universidade de Pernambuco (UPE) Recife PE Brasil dw.beserra@gmail.com, rkps@ecomp.poli.br, {kadna, jean, alexandre, aepa}@uag.ufrpe.br Abstract. The Cloud Computing has applications in High Performance Computing (HPC) and the virtualization is its basic technology, being necessary analyze its overheads on performance of HPC applications. In this work, was analyzed the performance of virtualized clusters with VirtualBox for HPC applications in function of the Operating System (OS) chosen for host. Linux presented best scalability performance and better resource distribution between Virtual Machines (VMs) that share the same host, being more suitable as OS host for virtualized clusters. Resumo. A Computação em Nuvem tem aplicações em Computação de Alto Desempenho (CAD) e a virtualização é sua tecnologia básica, sendo necessário determinar suas sobrecargas no desempenho de aplicações de CAD. Neste trabalho foi analisado o desempenho de clusters virtualizados com o VirtualBox em aplicações CAD em função do Sistema Operacional (SO) adotado como hospedeiro. O Linux apresentou maior escalabilidade de desempenho e melhor distribuição de recursos entre Máquinas Virtuais (VMs) que compartilham o mesmo hospedeiro, sendo mais adequado como SO hospedeiro de clusters virtualizados. 1. Introdução Atualmente, de acordo com [Younge et al. 2011], a Computação em Nuvem é o paradigma dominante em sistemas distribuídos e a virtualização é sua tecnologia básica mais destacada. A virtualização é um mecanismo que provê abstração de recursos de um SO hospedeiro a um SO convidado, permitindo que mais de um SO convidado seja instalado em VMs, executando concorrentemente sobre um SO hospedeiro [Ye et al. 2010]. Se a virtualização modifica o SO hospedeiro diz-se paravirtualização (PV), caso contrário, virtualização total (VT). Os virtualizadores são as ferramentas que implementam e gerenciam VMs e estão uma camada abaixo das ferramentas que implementam nuvens [Younge et al. 2011]. 3

18 A Computação em Nuvem oferece benefícios para CAD, como alta disponibilidade, customização de SO e redução de custos com manutenção [Ye et al. 2010] [Napper e Bientinesi. 2009] A Computação em Nuvem obteve destaque em CAD com o advento de nuvens científicas [Keahey et al. 2008] e aglomerados de computadores (Clusters Beowulf) virtualizados [Foster et al. 2006]. Como os virtualizadores são a tecnologia básica da computação em nuvem, é necessário avaliar seu desempenho para aplicações CAD, das quais as mais tradicionais são as aplicações que fazem uso da Interface de Passagem de Mensagens (MPI) executando em Clusters Beowulf [Ye et al. 2010][Mello et al. 2010]. Neste trabalho, foi analisado o desempenho do virtualizador VirtualBox para aplicações de CAD e como a escolha do SO hospedeiro influi no desempenho de um ambiente virtualizado para CAD. Em continuação a este trabalho, a Seção 2 introduz o VirtualBox no contexto de CAD. A Seção 3 descreve os objetivos a serem alcançados e os procedimentos metodológicos adotados. A Seção 4 apresenta os resultados obtidos e a Seção 5 encerra o trabalho com os resultados e as considerações finais. 2. A Computação de Alto Desempenho, os Virtualizadores e o VirtualBox Alguns requisitos devem ser atendidos ao empregar virtualização em CAD: A sobrecarga da virtualização não deve ter impactos significativos no desempenho do sistema, deve melhorar a administração do ambiente, permitindo a criação e destruição rápida de VMs e distribuição flexível de recursos de hardware. Também deve isolar aplicações em VMs e prover migração automática de VMs de um servidor a outro quando necessário, para aumentar a confiabilidade e a segurança do ambiente [Ye et al 2010]. Alguns trabalhos já abordaram o uso do VirtualBox para CAD, como o de [Younge et al. 2011], que analisou a viabilidade da virtualização para CAD. Foram analisados os virtualizadores de código aberto Xen, KVM e VirtualBox e elaborada uma tabela-resumo de suas características principais, sendo a Tabela 1 uma versão atualizada. Em relação a original verifica-se o aumento na capacidade de endereçamento de memória do VirtualBox de 16 GB para 1 TB. O desempenho dos virtualizadores foi medido com o High Performance Computing Benchmark (HPCC) e o Standard Performance Evaluation Corporation (SPEC) aplicado em clusters virtuais. A partir dos resultados obtidos foi elaborada uma classificação de virtualizadores para CAD, concluindo que KVM e VirtualBox são os melhores em desempenho global e facilidade de gerenciamento. Dentre os virtualizadores analisados em [Younge et al. 2011], apenas o VirtualBox suporta um SO não unix-like como hospedeiro. Sabe-se que o desempenho da rede de comunicação afeta o desempenho de processamento do cluster quando o mesmo aumenta de tamanho [Ye et al. 2010]. Todavia, não foram realizados testes de escalabilidade, onde em larga escala o melhor desempenho de rede do VirtualBox pode implicar que o mesmo também supere o KVM em processamento. Em [Mello et al. 2010] foi avaliado o desempenho de distribuições Linux de 32 e 64 bits como hospedeiros de clusters virtualizados com o VirtualBox, concluindo que distribuições de 32 bits tem melhor desempenho. Foram avaliados também os efeitos do compartilhamento de recursos em um mesmo hospedeiro, que foi incapaz de distribuir 4

19 igualmente os recursos entre as VMs. O trabalho é limitado por não avaliar o desempenho do VirtualBox nos dois SOs hospedeiros possíveis. Avalia apenas o desempenho de processamento e de rede, quando outros atributos, como taxa de leitura e escrita em memória principal também são importantes [Johnson et al 2011][Ye et al. 2010]. A escalabilidade do ambiente também não foi avaliada. [Beserra et al. 2012] avalia o desempenho de virtualizadores (VMWare Workstation, Virtual PC e VirtualBox) para implementação de clusters virtualizados em hospedeiros Windows. O VirtualBox obteve o melhor desempenho global. Tem as mesmas limitações do trabalho de [Mello et al. 2010], além de utilizar apenas um núcleo de processamento de quatro disponíveis. Tabela 1. Resumo das características dos virtualizadores de código aberto. Ultima versão 4.3 Xen KVM VirtualBox Embutido no Kernel Linux mais recente Para-virtualization Sim Não Sim Full virtualization Sim Sim Sim CPU hospedeira x86, x86-64, IA-64 x86, x86-64, IA-64, PPC x86, x86-64 CPU convidada x86, x86-64, IA-64 x86, x86-64, IA-64, PPC x86, x86-64 Windows, Linux, SO hospedeiro Linux, Unix Linux OS X, Solaris, Unix SO convidado Linux, Windows, NetBSD Windows, Linux, Unix Windows, Linux, Unix, Solaris VT-x / AMD-v Opcional Requerido Opcional Núcleos suportados Memória suportada 5TB 4TB 1TB Aceleração 3d Xen-GL VMGL Open-GL, Direct3D Live Migration Sim Sim Sim Licença GPL GPL GPL/Proprietária Diferentemente dos trabalhos citados, este verifica o desempenho do VirtualBox para aplicações de CAD em ambos os SOs suportados para hospedeiro. Também verifica o efeito das instruções de para-virtualização de rede e avaliam a escalabilidade do desempenho. O objetivo desse trabalho foi determinar qual SO hospedeiro tem melhor desempenho para CAD virtualizada com o VirtualBox. Por ser multiplataforma, o VirtualBox pode ser utilizado para a criação de nuvens baseadas tanto em Linux quanto em Windows, sendo necessário verificar a adequabilidade dos SOs hospedeiros em cada contexto de aplicação. 3. Mensurando o Desempenho do VirtualBox para CAD Esta seção trata da metodologia da pesquisa. Descreve o ambiente de provas, as ferramentas de avaliação de desempenho empregadas e os testes executados. Todos os testes foram executados dez vezes. Para cada teste foram descartados o maior e o menor valor obtidos e calculadas a média e o desvio padrão dos demais, similarmente a [Ye et al. 2010]. Obter o desvio padrão é importante, uma vez que, em um ambiente de nuvem 5

20 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014 o serviço ofertado deve ser estável, confiável. Grandes oscilações de desempenho não são bem vindas pelos clientes [Younge et al. 2011] [Napper e Bientinesi. 2009] Ambiente de Testes Os experimentos foram executados em oito computadores HP Compaq 6005, equipados com processadores AMD Athlon II X2 220 operando em frequência de 2.8 GHz. Esse processador tem um conjunto de instruções específicas para virtualização, o AMD-v. Os computadores tem 8 GB de memória principal, do tipo DDR 3 com frequência de operação de 1066 MHz. A interconexão entre os computadores foi realizada com adaptadores de rede Realtek RTL 8169 e um comutador de rede Intelbras SG Ambos funcionando em conformidade com o padrão Gigabit Ethernet 10/100/1000. A ferramenta de virtualização utilizada para a criação de todas as VMs usadas no experimento foi o VirtualBox Para a construção dos clusters foi utilizado o SO Rocks Clusters bit. O Rocks Clusters é um SO baseado em Linux desenvolvido para simplificar o processo de criação de clusters de alto desempenho [Papadopoulos, Katz e Bruno. 2003]. Os hospedeiros de VMs utilizaram o Microsoft Windows 7 e o Kubuntu como SO, ambos 64bit Ferramentas de Avaliação de Desempenho Para comparar o desempenho dos diferentes ambientes testados foi utilizado o HPCC [Luszczek et al. 2006]. O HPCC é o conjunto de testes padrão da comunidade de pesquisa em CAD [Ye et al. 2010]. O HPCC avalia o desempenho do processador, da memória, da comunicação inter-processos e da rede de comunicação. É constituído pelos seguintes testes: HPL O High Performance Linpack mede a quantidade de operações de ponto flutuante por segundo (FLOPS) realizadas por um sistema computacional durante a resolução de um sistema de equações lineares. É o teste mais importante para CAD [Young et al. 2011]; DGEMM Mede a quantidade de FLOPS durante uma multiplicação de matrizes de números reais de ponto flutuante de precisão dupla; STREAM Mede a largura de banda de memória principal (em GB/s). PTRANS O Parallel matrix transpose mede a capacidade de comunicação de uma rede. Ele testa as comunicações onde pares de processadores comunicam-se entre si simultaneamente transferindo vetores de dados da memória; RandomAccess Mede a taxa de atualizações aleatórias na mémoria (GUPs). FFT O Fast Fourier Transform mede a quantidade de operações com números complexos de precisão dupla em GFlops durante a execução de uma Transformada Rápida de Fourier unidimensional. Communication Latency/Bandwidth Mede a largura de banda (em MB/s) e a latência da rede durante a comunicação inter-processos MPI utilizando padrões de comunicação não simultânea (ping-pong) e simultânea (Anel de processos Aleatoriamente Ordenados (ROR) e Anel Naturalmente Ordenado (NOR)). 6

21 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014 O HPCC possui três modos de execução: single, star e mpi. O modo single executa o HPCC em um único processador. No modo star todos os processadores executam cópias separadas do HPCC, sem comunicação inter-processo. No modo mpi todos os processadores executam o HPCC em paralelo, empregando comunicação explícita de dados [Ye et al. 2010]. O HPCC requer a instalação de uma versão do MPI e do Basic Linear Algebra System (BLAS). Para a realização dos experimentos deste trabalho foram utilizados o OpenMPI (OMPI 1.4.1) e o AMD Core Math Library (ACML 4.4.0) Método Experimental O objetivo geral deste trabalho é determinar qual SO hospedeiro tem melhor desempenho em ambientes de cluster virtualizados com o VirtualBox. Portanto, todos os testes foram executados para ambos os SOs hospedeiros admitidos pelo VirtualBox, de forma a verificar como o desempenho varia em função da escolha do SO hospedeiro. Os seguintes objetivos específicos foram utilizados na estruturação dos testes realizados: 1. Determinar a sobrecarga provocada pela virtualização no desempenho de uma única VM; 2. Determinar a sobrecarga provocada pela virtualização no desempenho de um cluster virtual, em função da quantidade de nós do cluster (medição de escalabilidade); a. Verificar se o desempenho do cluster melhora ou piora ao usar as instruções de paravirtualização de rede do VirtualBox. 3. Determinar os efeitos no desempenho de clusters virtuais durante o uso concorrente de recursos de um mesmo hospedeiro físico por esses clusters Sobrecarga em uma única VM Para alcançar o objetivo específico 1 o HPCC foi executado em dois ambientes virtualizados, cada um com um SO hospedeiro diferente e com uma única VM por hospedeiro físico. Cada VM com duas v-cpus e 4GB alocados para uso como memória principal e 4GB para uso exclusivo do SO hospedeiro. Seus desempenhos foram comparados ao obtido pelo ambiente sem uso de virtualização (hardware nativo). Para igualar os recursos entre todos os ambientes, o ambiente sem virtualização também estava com 4GB de memória principal durante a execução dos testes Desempenho em Ambiente de Cluster Para alcançar o objetivo específico 2 foram testados ambientes de cluster virtualizados, nomeados EVA-01 e EVA-02. O ambiente EVA-01 tem como SO hospedeiro o Kubuntu e o EVA-02 o Windows. Ambos os clusters foram configurados com uma VM por hospedeiro físico, com configurações idênticas as descritas na subseção anterior. Os clusters virtuais foram comparados a um ambiente de cluster instalado em hardware nativo, nomeado EVA-00. Para igualar os recursos entre todos os ambientes, foi adotada medida similar a descrita na subseção anterior. 7

22 Para verificar a escalabilidade dos clusters em aplicações MPI, o HPCC foi executado em quantidade variável de elementos de processamento (nodos), com o parâmetro N do HPCC (tamanho do sistema linear a ser resolvido pelo HPL) ajustado a cada quantidade, conforme Tabela 2. Após a execução desses testes, as instruções de paravirtualização de rede foram desabilitadas e os testes reexecutados; para verificar o efeito de tais instruções no desempenho de clusters virtualizados com o VirtualBox. Em [Ye et al. 2010] é realizado um teste similar em um cluster virtualizado com o Xen, e o uso de tais instruções refletiu em melhora do desempenho de rede e global do cluster. Tabela 2. Valores utilizados para o parâmetro N do HPCC. Nós N Efeitos do Compartilhamento de Recursos. Foram instanciados dois clusters virtuais em um mesmo servidor para verificar como o compartilhamento de recursos afeta o desempenho individual de cada cluster (objetivo específico 3). Cada cluster foi configurado com dois nós e cada nó com uma vcpu e 1,5 GB de memória principal, de forma a não esgotar os recursos de processamento e memória do sistema. O desempenho de ambos foi aferido simultaneamente com o HPCC, com N = Os testes foram conduzidos em ambos os SOs suportados como hospedeiro pelo VirtualBox. É importante garantir que dois usuários que contratam um determinado serviço o recebam com desempenho similar. Se o serviço, neste caso instâncias de VMs, é fornecido em um mesmo hospedeiro, o SO do hospedeiro tem que distribuir os recursos igualmente entre as VMs. Se isto não ocorre, então não se provê uma boa qualidade de serviço, o que implica em impactos negativos para os usuários [Younge et al. 2011]. 4. Resultados Obtidos Esta seção apresenta os resultados obtidos dos testes e o que foi verificado em cada um Sobrecarga de uma única VM As médias e desvios padrão dos resultados obtidos em cada teste são apresentados como uma fração dos obtidos pelo sistema nativo. A Figura 1 apresenta o desempenho médio das amostras obtidas pelo HPCC no modo mpi, exceto para os testes DGEMM e STREAM, que não dispõe deste modo, sendo então apresentados seus resultados para o modo star. Como em alguns testes os valores obtidos para o desvio padrão são muito elevadas, não foi possível inclui-los na Figura 1, sendo exibidos a parte na Figura 2. A capacidade de computação dos sistemas virtualizados, medida com HPL, DGEMM e o FFT, é similar, embora para hospedeiros Linux seja 21% menor que a do sistema nativo para o HPL, 30% para o DGEMM e 9,5% para o FFT. A diferença do Windows para o Linux é de aproximadamente 1% para os três testes. Estes resultados indicam que aplicações computacionais são sensíveis a virtualização em graus distintos. A variação no desempenho de processamento dos ambientes virtualizados é pequena quando comparada ao nativo. A capacidade de leitura e escrita em memória principal dos ambientes virtualizados também é similar entre si. 8

23 Por não estar conectado a uma rede, todos os processos executam localmente e o desempenho dos testes em modo mpi não reflete o desempenho de rede e sim o da comunicação inter-processo local. Neste item, ambos os ambientes virtualizados apresentam desempenho similar em largura de banda. Entretanto, percebe-se grande diferenciação em latência de comunicação, a qual é muito maior no ambiente hospedado sob o Windows, sendo 4x superior a do ambiente nativo e 2x a do ambiente hospedado sob Linux, para todos os padrões de comunicação testados. Figura 1. Desempenho médio Figura 2. Variação do desempenho O desempenho da largura de banda de comunicação dos ambientes virtualizados varia pouco entre si. Varia menos que o ambiente nativo para padrões de comunicação em anel e mais para a comunicação ping-pong. A latência da comunicação, por outro lado, apresenta grande variação em relação a si próprio e a variação do ambiente nativo, com o Windows variando mais em padrões de comunicação do tipo anel que o Linux e menos em comunicação ping-pong. 9

24 4.2. Sobrecargas em ambiente de cluster As Figuras 3, 4 e 5 apresentam respectivamente a escalabilidade do desempenho médio de computação, de memória e de capacidade de comunicação dos ambientes testados. As barras sobre os pontos representam o desvio padrão obtido sobre as médias. Na Figura 3 verifica-se que o desempenho do ambiente EVA-01 para o HPL aumenta em escala, embora degrade em relação ao ambiente EVA-00. O ambiente EVA-02 não consegue aumentar o desempenho em escala. O uso de instruções de paravirtualização de rede implicou em melhor desempenho de processamento para todos os ambientes virtualizados. O desempenho no DGEMM, por não usar de comunicação inter-processos, variou pouco em todos os ambientes e manteve-se similar ao obtido em uma única VM. O desempenho com o FFT escala bem em EVA-00; pouco em EVA-01 e não escala em EVA-02. As instruções de para-virtualização pouco acrescentaram ao desempenho com o FFT. A variação no desempenho foi pequena para todos os ambientes em todos os testes de computação. Figura 3. Escalabilidade da capacidade de computação Na Figura 4 observa-se que o desempenho dos ambientes virtualizados no acesso a memória é bastante inferior ao nativo, tanto em nível local (STREAM), quanto global (RandomAccess). O desempenho obtido com o STREAM oscila muito nos ambientes EVA-01 e EVA-02, enquanto o obtido com o RandomAcess apresenta poucas oscilações. Para o teste RandomAcess verifica-se que o ambiente nativo apresenta boa escalabilidade, ao contrario dos virtualizados, mesmo quando empregam instruções de paravirtualização de rede. Problema similar foi verificado em [Ye et al. 2010] ao medir a escalabilidade deste teste em um ambiente de cluster virtualizado com o Xen. A justificativa apontada em [Ye et al. 2010] foi que o RandomAcess requer mais comunicação entre processos que os outros testes, o que degrada o desempenho. Figura 4. Escalabilidade do desempenho de memória 10

25 Da parte superior da Figura 5 percebe-se que a largura de banda de comunicação de todos os ambientes apresenta escalabilidade similar ao ambiente nativo para todos os padrões de comunicação testados. A queda de desempenho ao passar de 1 para 2 nodos é devida ao emprego de recursos de rede em lugar de apenas barramentos locais aos servidores. Da parte central da Figura 5 percebe-se que a latência de rede do ambiente EVA-01 escala similarmente a de EVA-00, enquanto a do ambiente EVA-02 é muito maior que a dos outros ambientes, além de apresentar maior variação de desempenho. Essa grande latência na comunicação observada explica porque o ambiente EVA-02 apresenta desempenho muito inferior em quase todos os testes. Excetuando-se os testes DGEMM e STREAM, que operam em modo star, todos os demais testes fazem uso intensivo da rede de comunicação. Logo, tem-se que a latência de rede é o grande gargalo para a escalabilidade do desempenho do ambiente EVA-02 em todos os aspectos que dela demandem. A parte inferior da Figura 5 apresenta os resultados obtidos para o teste PTRANS. A variação nos resultados foi pequena em todos os ambientes. O ambiente EVA-01 escala e o EVA-02 não. As instruções de paravirtualização não melhoraram consideravelmente o desempenho de nenhum dos ambientes virtualizados. Todavia, o ambiente EVA-00 apresenta estouro de capacidade para este teste em 8 VMs quando não usa as instruções de paravirtualização de rede. Figura 5. Escalabilidade da capacidade de comunicação 11

26 4.3. Efeitos do compartilhamento de recursos As Figuras 6 e 7 apresentam o desempenho obtido por dois clusters, nomeados Cluster A e Cluster B, executando concorrentemente em um mesmo servidor hospedeiro, tendo como SOs hospedeiros Linux (Figura 6) e Windows (Figura 7). A Tabela 3 exibe o desvio padrão obtido em todos os testes, para todos os ambientes. Na Figura 6 observa-se que o Linux foi capaz de prover boa distribuição dos recursos de computação e memória local. Ambos os clusters virtuais apresentaram desempenho similar, exceto para o teste FFT, que sofre queda brusca de desempenho no Cluster B. Os recursos da rede de comunicação, por outro lado, são mal divididos, com a largura de banda e a latência variando muito do Cluster A para o B. Figura 6. Desempenho de clusters que compartilham hospedeiro Kubuntu É provável que o mau desempenho na divisão dos recursos de rede de comunicação ocorra devido as VMs de ambos os clusters utilizarem a mesma interface de rede física. Enquanto que, os recursos de processamento e memória são distintamente alocados pelo SO e estão dentro da capacidade do servidor hospedeiro (4 CPUs físicas 4 vcpus; 8 GB RAM total instalados no servidor 6 GB RAM alocados as VMs). Como o FFT é bastante afetado pelo desempenho da rede, é possível que esta seja a causa de seu mau desempenho no Cluster B, que apresenta desempenho de rede muito inferior ao Cluster A. Na figura 7 nota-se que o Windows é incapaz de distribuir equivalentemente os recursos compartilhados de rede entre os dois clusters, provendo distribuição de recursos menos proporcional que o Linux. Por não utilizarem recursos de rede, o DGEMM e o STREAM apresentaram desempenho mais compatível entre si, o que indica que os recursos locais de processamento e memória são bem divididos pelo Windows, embora não obtenha o mesmo desempenho do Linux. A variação no desempenho individual de cada cluster é maior nos testes que demandam pela rede de comunicação, em ambos os ambientes. De uma maneira geral o desempenho do Cluster A sofre mais variação do que o do Cluster B em hospedeiros Windows, para todos os testes. 12

27 Figura 7. Desempenho de clusters que compartilham hospedeiro Windows Tabela 3. Desvio padrão do desempenho em ambiente compartilhado. Linux A Linux B Windows A Windows B HPL 0,00 0,00 0,01 0,00 DGEMM 0,08 0,10 2,75 0,51 PTRANS 0,00 0,01 0,12 0,01 RandomAccess 0,00 0,00 0,00 0,00 STREAM 0,47 0,60 0,90 0,14 MPIFFT 0,99 0,02 0,26 0,01 ROR_Latency 248,36 317, ,29 14,89 NOR_Bandwidth 0,00 0,00 0,03 0,00 ROR_Bandwidth 0,00 0,00 0,03 0,00 PingPongLatency 1398, , ,02 681,67 PingPongBandwidth 0,01 0,01 0,06 0,02 NOR_Latency 448,98 540, ,89 27,47 5. Considerações Finais Buscando determinar qual SO é mais adequado para ser utilizado como SO hospedeiro em clusters de alto desempenho virtualizados com o VirtualBox, uma série de testes foram executados em cenários passíveis de ocorrerem em ambientes de CAD hospedados em nuvens computacionais. Foi observado que a sobrecarga de virtualização afeta o desempenho de uma única VM similarmente para ambos os SOs hospedeiros testados, exceto para a latência da rede, que é maior no Windows. A escalabilidade do desempenho apresentada foi distinta em função do SO hospedeiro, tendo o Windows apresentado desempenho inferior ao Kubuntu em todos os aspectos dependentes da rede de comunicação, devido à elevada latência de rede apresentada pelo Windows, que aumenta em escala, enquanto a do Linux estaciona. O Windows escala mal e varia mais, além de prover pior divisão de recursos, não sendo adequado como hospedeiro de clusters virtuais, embora seja possível seu emprego em aplicações que exijam pouca comunicação inter-processos. O Linux, em 13

28 contrapartida, apresenta desempenho escalável, com poucas oscilações e melhor distribuição de recursos, sendo mais adequado para aplicações de CAD. Temos que, por maioria de casos vencedores e pela importância dos mesmos em CAD, o Linux apresenta maior adequação para a implementação de clusters virtualizados com o VirtualBox direcionados a CAD. Como trabalho futuro, verificar-se-ão os efeitos da adição de uma segunda interface de rede no desempenho de clusters virtualizados que compartilham o mesmo hospedeiro. Referências Beserra, D.W.S.C., Borba, A., Souto, S.C.R.A., de Andrade, M.J.P, e de Araújo, A.E.P. (2012) "Desempenho de Ferramentas de Virtualização na Implementação de Clusters Beowulf Virtualizados em Hospedeiros Windows." Em: X Workshop em Clouds, Grids e Aplicações-SBRC SBC, Ouro Preto, pp Foster, I., Freeman, T., Keahy, K. Scheftner, D., Sotomayor, B. e Zhang, X. (2006) Virtual clusters for grid communities, International Symposium on Cluster Computing and the Grid, IEEE, vol. 0, pp Johnson, E., Garrity, P., Yates, T., e Brown, R. (2011) Performance of a Virtual Cluster in a General-purpose Teaching Laboratory, In: 2011 IEEE International Conference on Cluster Computing. Pp IEEE. Keahey, K., Figueiredo, R., Fortes, J., Freeman, T. e Tsugawa, M. (2008) Science clouds: Early experiences in cloud computing for scientific applications, Cloud Computing and Applications. Kejiang, Y., Jiang, X., Chen, S., Huang, D. e Wang, B. (2010) "Analyzing and modeling the performance in xen-based virtual cluster environment." High Performance Computing and Communications (HPCC), th IEEE International Conference on. IEEE. Luszczek, P. R., Bailey, D. H., Dongarra, J. J., Kepner, J., Lucas, R. F., Rabenseifner, R., & Takahashi, D. (2006). The HPC Challenge (HPCC) benchmark suite. In Proceedings of the 2006 ACM/IEEE conference on Supercomputing pp ACM. Mello, T. C. Schulze, B. Pinto, R. C. G. e Mury, A. R. (2010) Uma análise de recursos virtualizados em ambiente de HPC, Em: Anais VIII Workshop em Clouds, Grids e Aplicações, XXVIII SBRC/ VIII WCGA, SBC, Gramado, pp Napper, J. e Bientinesi, P. (2009) Can cloud computing reach the TOP500?, Em: Proc. Combined Workshops on UnConventional High Performance Computing Workshop Plus Memory Access Workshop, UCHPC-MAW '09,, pp Papadopoulos, P. M., Katz, M. J., e Bruno, G. (2003). NPACI Rocks: Tools and techniques for easily deploying manageable linux clusters. Concurrency and Computation: Practice and Experience, 15(7 8), Ye, K., Jiang, X., Chen, S., Huang, D., e Wang, B. "Analyzing and modeling the performance in xen-based virtual cluster environment." High Performance Computing and Communications (HPCC), th IEEE International Conference on. IEEE,

29 Younge, A. J., Henschel, R., Brown, J. T., von Laszewski, G., Qiu, J., Fox, G. C., (2011) "Analysis of virtualization technologies for high performance computing environments." 2011 IEEE International Conference on Cloud Computing (CLOUD). IEEE. 15

30 ANÁLISE DE ESCALABILIDADE DE APLICAÇÕES HADOOP/MAPREDUCE POR MEIO DE SIMULAÇÃO Fabiano da Guia Rocha 1,2, Hermes Senger 2 1 Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso Campus Cáceres Mato Grosso, Brasil 2 Programa de Pós-Graduação em Ciência da Computação Universidade Federal de São Carlos (UFSCAR) hermes@dc.ufscar.br, fabiano.rocha@cas.ifmt.edu.br Abstract. MapReduce is a programming model for the execution of applications that manipulate large data volumes in machines composed of several (potentially hundreds or thousands) of processors/cores. Currently, Hadoop is the most widely adopted free implementation of MapReduce. In this work we study the scalability of MapReduce applications running on Hadoop adopted a combined approach involving both experimentation and simulation. The experimentation has been carried out in a local cluster of 32 nodes, and for the simulation we employed MRSG (MapReduce over SimGrid). As main contributions, we present a scalability analysis method that allows us to identify main performance bottlenecks and to improve the scalability of MapReduce applications on larger clusters with thousands of nodes. Resumo. MapReduce é um modelo de programação para a execução de aplicações que manipulam grandes volumes de dados em máquinas compostas por até centenas ou milhares de processadores ou núcleos. Atualmente Hadoop é o framework MapReduce mais largamente adotado. Este trabalho descreve um estudo sobre a escalabilidade de aplicações MapReduce executadas na plataforma Hadoop utilizando um método que combina experimentação e simulação. A experimentação foi realizada em um cluster local de 32 nós e para a simulação foi empregado o simulador MRSG (MapReduce over SimGrid). Como principais contribuições, este artigo mostra como a abordagem combinada pode ser empregada para identificar os principais gargalos em termos de escalabilidade de aplicações reais em diferentes cenários, melhorando significativamente a sua escalabilidade em plataformas com milhares de nós. 1. Introdução MapReduce é um modelo de programação e um framework desenvolvido para processamento paralelo de grandes volumes de dados em clusters com milhares de processadores [Dean and Ghemawat 2004]. O modelo tem sido amplamente utilizado por diversas empresas e mais recentemente pela comunidade de pesquisa em diversas áreas como bioinformática, processamento de linguagem natural, aprendizagem de máquina, análise de imagens e diversos outros segmentos. No modelo MapReduce as tarefas de processamento são distribuídas entre os nós implementando uma arquitetura mestre-escravo, na qual existe um único nó mestre gerenciando um determinado número de nós escravos. A execução das tarefas ocorre em duas etapas denominadas map e reduce. O nó mestre escalona as tarefas aos nós escravos, determinando se o nó deve realizar uma tarefa map ou uma tarefa reduce. Sempre que um nó escravo completar a execução de uma tarefa, ele sinaliza ao nó 16

31 mestre, para que esse possa escalonar uma nova tarefa ao escravo que está disponível. A fase map manipula os dados na forma de lista de pares chave-valor, produzindo dados intermediários que passam pela fase shuffle, são recombinados e posteriormente consumidos e processados pela fase reduce [White 2009, Dean and Ghemawat 2004]. Hadoop é uma das mais conhecidas e difundidas implementações de MapReduce. Foi desenvolvida pela Apache Software Foundation para executar aplicações em clusters com milhares de nós, utiliza um sistema de arquivos distribuído denominado HDFS (Hadoop Distributed File System) e conta com a implementação de mecanismos de tolerância a falhas, balanceamento de cargas e distribuição de dados. Em ambientes distribuídos, a plataforma Hadoop é capaz de gerenciar a arquitetura distribuída, realizando, de forma automática, atividades como o escalonamento de tarefas, a interação com o sistema de arquivos distribuídos e a troca de mensagens entre os nós permitindo que o usuário se preocupe apenas com a lógica da aplicação [White 2009, Dean and Ghemawat 2004]. Há relatos do uso do Hadoop/MapReduce na execução de aplicações em um mesmo cluster com até processadores, 40 mil tarefas concorrentes, manipulando um total de até 20 petabytes [O Maley 2011]. No Hadoop MapReduce, os dados de entrada são inicialmente divididos em N partes (chunks), sendo N o número de tarefas map. Esses chunks são distribuídos e replicados aos nós da arquitetura e representam os dados de entrada para as tarefas map. O nó mestre aloca as tarefas map que efetuam o processamento dos dados de entrada e o resultado intermediário é enviado às tarefas reduce. A função reduce efetua a computação dos dados intermediários recebidos e grava os dados de saída no HDFS. No ambiente de execução, uma tarefa reduce somente inicia após o término de todas as tarefas map [White 2009]. SimGrid é um projeto de código aberto (open source) implementado em linguagem C e utiliza arquivos XML (Extensible Markup Language) como entrada. Nesses arquivos são definidas as características da simulação, tais como a topologia de rede e as características e responsabilidades dos nós. No simulador, as aplicações são modeladas pela manipulação de tarefas que são divididas em tarefas de computação, que utilizam os recursos de processamento (CPU), ou tarefas de transmissão, que utilizam o canal de comunicação [Casanova et al. 2008]. O MRSG (MapReduce Over SimGrid) foi desenvolvido sobre o SimGrid para simular o ambiente e o comportamento do MapReduce em diferentes plataformas. Por meio de uma descrição simplificada dos dados de entrada, tais como o tamanho e o custo das tarefas, o MRSG consegue de maneira determinística simular o gerenciamento, o escalonamento e a execução de tarefas de uma aplicação MapReduce, enquanto que a computação dos nós e a simulação do ambiente são realizadas pelo SimGrid [Kolberg et al. 2013]. Este artigo trata da análise de escalabilidade de aplicações MapReduce em clusters com centenas ou muitos milhares de nós. Devido ao número limitado de processadores disponíveis, nossa abordagem combina experimentação e simulação. A experimentação permite uma primeira análise e a coleta de informações sobre o desempenho de uma aplicação real, e a calibração do simulador torna possível a reprodução do comportamento da aplicação real. 17

32 Uma vez calibrado e validado, o simulador permite extrapolar a análise para diversos cenários onde tanto o problema quanto a plataforma podem escalar significativamente. Dessa forma, é possível identificar gargalos que irão aparecer em tais cenários, e a criação de estratégias que podem auxiliar na melhoria tanto das aplicações quanto da plataforma na busca por maior escalabilidade. Os experimentos foram realizados em um cluster local de 32 nós e o simulador utilizado foi o MRSG. Os experimentos mostram como seria possível elevar o limite de escalabilidade de uma aplicação, de algumas centenas para até 10 mil nós com speedups quase lineares. O artigo está assim organizado: a seção 2 apresenta os experimentos e resultados obtidos na execução da plataforma real; a seção 3 descreve os testes de escalabilidade com o simulador calibrado e os experimentos realizados com objetivo de minimizar os gargalos identificados; na seção 4 expõe as conclusões do trabalho seguido pelo referencial bibliográfico utilizado. 2. Análise de Escalabilidade de Aplicações MapReduce Para estudar a escalabilidade de sistemas computacionais é necessário realizar experimentos de larga escala, na ordem de muitos milhares de processadores, o que se torna inviável em plataformas reais/experimentais devido à limitação de recursos, tempo e dificuldades na reprodutibilidade dos experimentos. Neste trabalho buscamos contornar a limitação em termos de recursos computacionais disponíveis e, para isso, fez-se uso da combinação de experimentação real e de simulação. A metodologia utilizada pode ser útil para prever a escalabilidade de aplicações sem depender da disponibilidade de uma plataforma real, podendo avaliar uma grande variedade de cenários com diferentes parâmetros e que não seria possível via experimentação real. Para a experimentação em ambiente real, utilizou-se uma aplicação de índices reversos, bastante eficiente e otimizada, conhecida por Per-Posting list [McCreadie et al. 2011]. Esse método de construção de índices reversos está presente no sistema de recuperação de informações denominado Terrier 1. Tal aplicação foi executada em um ambiente real composto de 32 nós (cluster DC-UFSCar), que possibilitou a coleta de dados necessários para calibrar do simulador. A calibração foi necessária para que o simulador pudesse reproduzir com maior acurácia o comportamento da aplicação escolhida para a plataforma de 32 nós disponível. Uma vez calibrado, o simulador permite extrapolar o número de nós da plataforma e avaliar a escalabilidade da aplicação-alvo para plataformas de grande porte, da ordem de milhares de nós. Com a simulação das diferentes plataformas, é possível identificar, ainda que de maneira aproximada, qual seria o comportamento esperado em termos de escalabilidade da aplicação nessas plataformas. 2.1 Primeiro Experimento Inicialmente, foram executados experimentos em um cluster do Departamento de Computação (DC-UFSCar), composto por 32 nós conectados por um switch Gigabit Ethernet. Cada nó de processamento possui 2 processadores AMD Opteron 246,

33 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014 Gigabytes de memória RAM, 4 discos de 250 Gigabytes cada e sistema operacional Linux CentOS. O desempenho de cada nó foi de Gflops, medido através do benchmark Linpack [Dongarra et al. 2003]. A velocidade de transmissão da interface de rede entre nós no mesmo switch foi medida através do software Iperf que indicou largura de banda de 392 Mbps e latência de 1e-4 segundos. No cluster está instalado o Hadoop versão 1.0.4, com 4 slots para a execução concorrente de tarefas map e reduce. O valor padrão para o tamanho do chunks de dados foi de 64 Megabytes, fator de replicação igual a 3 e o intervalo entre os heartbeats gerados por cada nó escravo foi de 3 segundos. A aplicação utilizada nos testes foi a ferramenta de recuperação de informações Terrier¹, que implementa a indexação Per-Posting list. Trata-se de um sistema desenvolvido em Java voltado ao processamento de documentos em larga escala. Para a composição de índices invertidos, o Terrier analisa um corpus de texto de forma sequencial ou paralela, gerando um job, submetido para execução no cluster com Hadoop. Por fim, o Terrier produz como resultado índices invertidos contendo dados estatísticos sobre a incidência de cada termo encontrado nos documentos da coleção. Os testes de indexação distribuída foram realizados utilizando-se a base de dados da coleção Clueweb09_English_1 que é um subconjunto do corpus ClueWeb09 composto por mais de 50 milhões de documentos. Esse conjunto de dados já foi largamente estudado e otimizado, sendo utilizado em diversas trilhas na TREC 2009 [McCreadie et al. 2011]. A base de dados vem originalmente gravada compactada (formato tar.gz) de forma a minimizar o tempo de E/S (entrada e saída). O Hadoop possui classes nativas que lêem dados compactados nesse formato. A base de dados foi gerada replicando-se dois arquivos até gerar 192 arquivos, totalizando aproximadamente 34 Gigabytes no HDFS sendo composta por: Número de Documentos: ; Número de Tokens: ; Número de Termos: ; Total de bytes lidos do HDFS: bytes (aprox. 34 GB). Por se tratar de uma base de dados voltada à recuperação de informações da língua natural, os experimentos foram conduzidos com número fixo de 26 tarefas reduce em que cada tarefa reduce trata de uma letra do alfabeto. Em todos os experimentos foi fixado o número de 192 tarefas map, correspondente aos 192 arquivos de entrada. 2.2 Resultados do Primeiro Experimento (Makespan) Cada experimento foi replicado duas vezes para plataformas com 32, 28, 24, 20, 16, 12, 8, 4 e 1 nó. Na Tabela 1 são descritos os tempos médios (em segundos) de execução das fases map, reduce e o makespan (tempo total de execução da aplicação). Com base nos tempos de execução das fases map, reduce e makespan calculamos o speedup representado na Tabela 1, e ilustrado na forma gráfica na Figura 1. Analisando o gráfico de speedup (Figura 1), observa-se que no caso do map há um comportamento sublinear, ou seja, linear a menos de uma constante. O speedup sublinear encontrado pode ser justificado pelos atrasos gerados pela sobrecarga do 19

34 sistema na criação, comunicação, sincronização e finalização das tarefas e espera por operações de entrada e saída em disco. Tabela 1. Primeiro teste de escalabilidade da aplicação no cluster até 32 nós. Número de nós Fase Map (segundos) Fase Reduce (segundos) Makespan (segundos) Speedup Fase Map Speedup Fase Reduce Speedup Total ,78 3,84 3, ,22 6,87 6, ,64 9,66 9, ,78 11,80 10, ,16 13,70 12, ,91 15,50 13, ,58 17,94 15, ,62 18,26 16,02 Vale destacar o comportamento do speedup da plataforma com 28 nós, ilustrado na Figura 1. Considerando que, na plataforma com 28 nós são executadas 56 tarefas de maneira concorrente (duas em cada nó), e que no total devem ser executadas 192 tarefas map, restam 24 tarefas a serem executando na última rodada. Portanto, tem-se na última rodada uma ociosidade de 16 nós (57%). Esta ociosidade causa o cotovelo que pode ser observado na Figura 1. Figura 1. Gráfico de Speedup da Fase Map, Fase Reduce e Total. O speedup da fase reduce também apresenta um comportamento parecido. Nas execuções acima de 16 nós o speedup começa a cair, pois a aplicação possui apenas 26 tarefas reduce. Convém destacar que, apesar de haver apenas 26 tarefas reduce (o que causa ociosidade além de 13 nós), o speedup continua aumentando. Este comportamento é justificado pelas otimizações realizadas na versão utilizada do Hadoop. A fase reduce tem início logo após o término das primeiras tarefas map. Em geral, isso reduz o tempo total de execução do job, mas aumenta a duração da fase reduce que deve aguardar pela execução de todas as tarefas da fase map. Uma evidência dessa otimização é verificada pela soma da duração das duas fases que é maior que o makespan. 20

35 Com a execução real do Terrier na plataforma Hadoop e a base de dados de entrada ClueWeb foi possível extrair os tempos de execução bem como os demais parâmetros necessários para a etapa de calibração do simulador. 3. Calibração do Simulador MRSG Para reproduzir adequadamente o comportamento de um sistema real, é necessário que diversos parâmetros do simulador sejam configurados e calibrados, ou seja, deve ser realizado o ajuste correto dos custos e demais parâmetros de aplicação permitindo que o simulador reproduza o comportamento real da aplicação. Uma vez calibrado, pode-se realizar simulações e verificar a acurácia do simulador validando a simulação com êxito. Neste trabalho, o processo de calibração consiste em procurar valores de custo das tarefas map e reduce (map_cost e reduce_cost) do simulador, para que a diferença entre o tempo total simulado e o tempo total real seja minimizada. O custo de computação por byte lido na fase map e na fase reduce está relacionado à quantidade de trabalho que a tarefa deverá executar, possibilitando ao simulador estimar o tempo de duração dessas tarefas. Diversas execuções foram realizadas, até ajustar o custo das tarefas e calibrar o simulador. A cada execução manual da plataforma simulada foram realizados ajustes (aumentar ou diminuir o valor de custo) no parâmetro map_cost e reduce_cost de maneira que o tempo de simulação corresponda o mais próximo possível do tempo real. O erro percentual médio da fase map simulada ficou em torno de 2,43% em relação aos testes reais e, na fase reduce o erro percentual médio foi de aproximadamente 2,06% em relação à execução real. Com o objetivo de obter uma maior acurácia entre o makespan simulado e o real, buscamos ajustar os custos de map e reduce para execuções paralelas utilizando o valor do custo médio obtido da experimentação real (1 a 24 nós) descontando-se os outliers (valor mínimo e o máximo) e o custo para um nó (execução sequencial). Uma vez calculado o custo médio de map e reduce, repetimos os testes no MRSG de 01 a 24 nós conforme ilustrado na Tabela 2. Analisando o makespan obtido nos testes, observa-se que o percentual de erro calculado entre o makespan real e o makespan da simulação foi inferior a 1% com o erro percentual médio de aproximadamente 0,41%. Tabela 2. Comparação entre o Makespan Real e o Makespan da Simulação. Número de Makespan Real Makespan Simulado Erro (%) nós (segundos) (segundos) , , , , , , ,07 Para validar o modelo de calibração ora executado, modelamos no MRSG um cenário com 28 e 32 utilizando o custo médio de map e reduce calculado. O makespan obtido da simulação foi comparado com o makespan extraído da execução real de 28 e 21

36 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA nós executada no cluster DC-UFSCar e calculado o percentual de erro inferior a 1% em relação aos testes reais que pode ser observado na Tabela 3. Tabela 3. Comparação entre o Makespan Real e o Makespan da Simulação. Número de nós Makespan Real (seg) Makespan Simulado (seg) Erro (%) 0,91 0,33 Comparando a Tabela 2 com a Tabela 3, observa-se que o comportamento de ambos os experimentos se assemelham e que a margem de erro foi relativamente baixa. Assim, pode-se considerar que o simulador apresenta boa acurácia, podendo representar com certo grau de confiabilidade o ambiente real desta aplicação específica em uma plataforma pequena. Convém ressaltar que, para todos os experimentos, na simulação da plataforma sequencial (um nó) utilizou-se o valor de custo obtido nos experimentos de execução real. 3.1 Segundo Experimento: Teste de Escalabilidade com o Simulador Calibrado Com o simulador calibrado, foi possível realizar diversos experimentos com plataformas compostas por milhares de nós com o objetivo de avaliar a escalabilidade da aplicação. Na realização dos testes de escalabilidade, modelamos plataformas com 1, 2, 5, 10, 20, 50, 100, 200, 500, 1.000, 2.000, e nós. Eis alguns parâmetros que foram medidos na execução real e utilizados na configuração do simulador: Map output gerado por cada tarefa map: bytes; Map cost: E+12 (número de operações a serem executadas, por byte de entrada da função map); Reduce cost: E+12 (número de operações a serem executadas, por byte de entrada da função reduce); Número de tarefas reduce: 26; Chunk Size: 178 MB; Input Chunks (tarefas map): ; Dfs réplicas: 3; Map Slots e Reduce Slots: 2; Tabela 4. Resultado Simulado das Fases Map, Reduce e do Makespan. Número de nós Fase Map Fase Reduce Makespan Speedup Total 1,000 1,791 4,481 8,999 18,490 46,158 92, , , , , , ,292 Eficiência 1,000 0,895 0,896 0,900 0,924 0,923 0,921 0,915 0,587 0,305 0,155 0,063 0,031

37 Na Tabela 4 estão descritos, para cada experimento, os tempos de duração da fase map, da fase reduce e o makespan. Com base nesses valores, foi calculado o speedup e a eficiência do experimento conforme abaixo. O gráfico da Figura 2 ilustra o makespan obtido na simulação para plataformas de 1 a nós. Figura 2. Gráfico de Makespan com 26 tarefas reduce e 100 mil tarefas map. Como se pode observar, a partir de 200 nós os ganhos foram pouco significativos e a partir de 500 nós o ganho é praticamente nulo. Isso ocorre devido ao baixo grau de paralelismo da fase reduce, que possui apenas 26 tarefas. A fase reduce se tornou um gargalo, porém, que pode ser facilmente melhorado aumentando-se o grau de concorrência nesta fase. Com a curva de speedup ilustrada no gráfico da Figura 3, percebe-se que a aplicação não escala conforme o esperado a partir de 500 nós, ou seja, nota-se que a escalabilidade aumenta sublinearmente até 500 nós, quando, então se estabiliza. Figura 3. Gráfico de Speedup com 26 tarefas reduce e 100 mil tarefas map. A eficiência da aplicação para a plataforma e as configurações ora simuladas mantiveram constantes até 200 nós e, após esse valor, observa-se uma queda na eficiência conforme ilustra a Figura 4. Com esses experimentos, é possível observar que a fase map escala quase linearmente, desde que a quantidade de tarefas map seja suficientemente grande para manter os nós ocupados. Alguns fatores podem contribuir para que a fase map escale abaixo do linear, tais como a geração de uma grande quantidade de tarefas não locais e o consequente aumento do tráfego de rede. Tais tarefas 23

38 têm impacto direto na aplicação, pois exigem a transmissão dos chunks antes da execução. Figura 4. Gráfico de Eficiência com 26 tarefas reduce e 100 mil tarefas map. A implementação da aplicação faz com que a fase reduce não escale além de 26 núcleos (13 nós) devido à característica da aplicação que implementa 26 tarefas reduce, em que cada tarefa é responsável por uma letra do alfabeto. Vale observar que a fase reduce escala até 500 nós conforme a representação gráfica do speedup ilustrada na Figura 3. Isso ocorre devido a uma otimização realizada no Hadoop, que antecipa o início da fase reduce, logo que as primeiras tarefas map são finalizadas. Na análise dos experimentos, observa-se que a fase reduce se mostrou um dos principais limitantes da escalabilidade da aplicação (makespan). Isso ocorre, pois a fase reduce atrasa a duração do job. Outro fator que pode ter influenciado o comportamento observado da fase reduce é o gargalo ocasionado devido ao aumento dos tempos de heartbeat. O simulador MRSG considera, por padrão, o intervalo de heartbeat como 3 segundos. Porém, se esse intervalo for muito longo os avanços na computação levarão mais tempo para serem reportados, enquanto que intervalos muito curtos sobrecarregam o nó mestre e a rede, o que pode também limitar a escalabilidade da aplicação. Com objetivo de melhor adequar o valor do heartbeat ao tamanho da plataforma, o MRSG ajusta o intervalo de heartbeat pela divisão do número de nós por 100. Caso esse valor seja inferior a 3, utiliza-se o valor padrão, caso contrário, otimiza-se esse intervalo. Nos experimentos realizados, o heartbeat foi de 3 segundos para plataformas de 1 a 200 nós, de 5 segundos para 500 nós, de 20 segundos para nós, de 50 segundos para nós e de 100 segundos para nós. Esse fato faz com que o nó mestre (nó que executa o processo JobTracker) somente tenha ciência que a tarefa terminou alguns instantes após e, consequentemente, o nó escravo (nó que executa o processo TaskTracker) já estaria ocioso. 3.2 Terceiro Experimento: Redução do gargalo da fase Reduce Uma possível estratégia para aumentar a escalabilidade da aplicação consiste em modificar o seu código a fim de produzir um número maior de tarefas reduce, aumentando o seu grau de paralelismo. Por exemplo, os dois primeiros caracteres de cada termo poderiam ser verificados ao invés de apenas um (que resulta em apenas 26 24

39 tarefas reduce, uma para cada letra do alfabeto). Nesse caso, seria possível ter 26 2 tarefas reduce, de modo a utilizar mais processadores durante o processamento da fase. No próximo cenário, são considerados os mesmos parâmetros de plataforma e de configuração utilizadas na seção 3.1, exceto o número de tarefas reduce que foi fixado em 676 tarefas, de modo a ocupar todos os processadores durante a fase reduce. Com o aumento do número de tarefas reduce, observa-se que o speedup da fase escala sublinearmente até 500 nós, conforme descrito na Tabela 5. Tabela 5. Makespan, Speedup e Eficiência com 676 tarefas reduce e 100 mil tarefas map. Número de nós Makespan (s) Speedup Total Eficiência ,000 1, ,881 0, ,084 0, ,482 0, ,364 0, ,165 0, ,834 0, ,842 0, ,626 0, ,300 0, ,783 0, ,182 0, ,943 0,062 Essa alteração na configuração possibilitou melhora na escalabilidade, permitindo que a aplicação escalasse com razoável eficiência até uma quantidade entre 500 e 1000 nós, conforme ilustra a Figura 5. Figura 5. Gráfico de Speedup com 676 tarefas reduce e 100 mil tarefas map. Analisando-se os resultados obtidos, uma hipótese foi lançada sobre o próximo gargalo a ser atacado: congestionamento da rede de comunicação entre os nós. 3.3 Quarto Experimento: Trocando a comunicação entre os nós Como alternativa para melhoria de speedup, buscamos investigar o comportamento da aplicação considerando o aumento da largura de banda da rede que interconecta os nós 25

40 de modo a atender à demanda do tráfego de dados gerado principalmente na fase intermediária. O ambiente experimental utilizado se baseia em gigabit ethernet, contudo em clusters de melhor qualidade faz-se uso de outras tecnologias, tais como Infiniband. Neste experimento modelamos um cenário com uma rede Infiniband EDR (Enhanced Data Rate) com taxa de largura de banda de 300Gb/s (37,5 GBps) e latência de 100 nanosegundos. Considerando o experimento com 10 mil nós e 676 tarefas reduce, o speedup (vide Tabela 6) obtido foi de 5.739, conforme ilustra a Figura 6. Tabela 6. Makespan, Speedup e Eficiência com 676 tarefas reduce e switch infiniband. Número de nós Makespan (s) Speedup Total Eficiência ,000 1, ,77 0, ,38 0, ,75 0, ,43 0, ,44 0, ,87 0, ,32 0, ,22 0, ,08 0, ,16 0, ,443 0, ,027 0,574 Observa-se que com o aumento do grau de paralelismo da fase reduce houve um significativo ganho na escalabilidade da aplicação. A representação gráfica do speedup ilustra o comportamento sublinear da fase map e reduce. Na plataforma de 10 mil, o makespan resultante foi 18 vezes menor que o observado no experimento da seção 3.2. Figura 6. Makespan, Speedup e Eficiência com 676 tarefas reduce e switch infiniband. 4. Conclusões Neste trabalho, utilizamos o simulador MRSG para reproduzir o comportamento de aplicações MapReduce sobre o ambiente de simulação SimGrid, com o objetivo de avaliar a escalabilidade de aplicações. Foram realizados experimentos com uma aplicação bem conhecida e relevante na área de processamento de informações, que é o Terrier, indexando um corpus retirado do ClueWeb. Com os primeiros experimentos, 26

41 verificou-se que o simulador MRSG precisa ser calibrado para que reproduza com maior acurácia o comportamento da aplicação cuja escalabilidade se quer avaliar. Uma vez calibrado, o MRSG se mostra uma poderosa ferramenta que permite avaliar os gargalos de escalabilidade de aplicações MapReduce em diversos cenários. Dessa forma, usuários podem avaliar antecipadamente possíveis gargalos no caso de aumento da base de dados e/ou da plataforma, e avaliar possíveis medidas e estratégias a serem adotadas para se atingir o grau de escalabilidade desejado. Como o MRSG é construído sobre o ambiente SimGrid, que por sua vez é altamente escalável, é possível avaliar a escalabilidade de aplicações em grandes plataformas de até 10 mil nós ou mais. Além de auxiliar no estudo sobre os limites de escalabilidade, o simulador calibrado pode auxiliar a responder no futuro próximo uma questão relevante, que é encontrar os limites assintóticos de escalabilidade de aplicações MapReduce. Agradecimentos Os autores agradecem à CAPES pela concessão de bolsa de mestrado. Hermes Senger agradece à FAPESP (contrato # 2014/ ) e ao CNPq pelo apoio recebido. Referência Casanova, H., Legrand, A., and Quinson, M. (2008). SimGrid: a Generic Framework for Large-Scale Distributed Experiments. In 10th IEEE International Conference on Computer Modeling and Simulation. Dean, J. and Ghemawat, S. (2004). Mapreduce: Simplifed data processing on large clusters. In 6th Symposium on Operating Systems Design and Implementation (OSDI), pages Dongarra, J. J., Luszczek, P., and Petitet, A. (2003). The linpack benchmark: Past,present, and future. Concurrency and computation: Practice and experience. Concurrency and Computation: Practice and Experience, 15:2003. Kolberg, W., de Marcos, P. B., dos Anjos, J. C. S., Miyazaki, A. K., Geyer, C. R., and Arantes, L. B. (2013). MRSG a MapReduce Simulator over Simgrid. Parallel Computing, 39. McCreadie, R., Macdonald, C., and Ounis, I. (2011). Mapreduce indexing strategies: Studying scalability and efficiency. Information Processing and Management, (In Press). O Maley, O (2011). In Next Generation of Apache Hadoop MapReduce. White, T. (2009). Hadoop: the Definitive Guide. O Reily. 27

42 Análise de Desempenho do Virtualizador KVM com o HPCC em Aplicações de CAD Rubens Karman 1, David Beserra 2, Patrícia Endo 3, Sergio Galdino 1 1 Departamento de Computação Inteligente Universidade de Pernambuco (UPE) Recife PE Brasil 2 Unidade Acadêmica de Garanhuns Universidade Federal Rural de Pernambuco (UFRPE) Garanhuns PE Brasil 3 Grupo de Estudos Avançados em Tecnologia da Informação e Comunicação Universidade de Pernambuco (UPE), Caruaru, Brasil rkps@ecomp.poli.br, dw.beserra@gmail.com, sergio.galdino@ieee.org Abstract. Cloud Computing can support High Performance Computing (HPC) applications, and the virtualization is its basic technology. Despite benefits from virtualization, it is crucial to determine its overload on HPC applications performance. This work analyzes the virtualized clusters performance over KVM hypervisor for HPC applications, with the HPCC benchmark suite. We also analyze the virtualized clusters performance when their virtual machines are hosted in the same physical host, in order to realize the resource sharing impact on the performance. Resumo. A Computação em Nuvem pode oferecer suporte a aplicações de Computação de Alto Desempenho (CAD) e a virtualização é sua tecnologia básica. Apesar dos benefícios oriundos da virtualização, é de fundamental importância determinar suas sobrecargas no desempenho de aplicações de CAD. Este trabalho analisa o desempenho de clusters virtualizados com o KVM executando aplicações de CAD, com a aplicação do conjunto de testes HPCC. Também será avaliado o desempenho de clusters virtualizados quando suas máquinas virtuais estão hospedadas em um mesmo servidor físico, para determinar os efeitos do compartilhamento de recursos no desempenho. 1. Introdução A Computação em Nuvem é considerada atualmente um dos paradigmas dominantes em sistemas distribuídos [Younge et al. 2011]. Entre as diversas aplicações que podem ser implementados na Nuvem, destaca-se a Computação de Alto Desempenho (CAD), que necessita de clusters virtuais para execução de aplicações que utilizam Message Passing Interface (MPI) ([Mello et al. 2010] e [Beserra et al. 2012]). Uma tecnologia que permeia a infraestrutura de uma Nuvem é a virtualização, já bastante conhecida na área de computação, e frequentemente identificada como uma forma de abstração de recursos físicos com diferentes propósitos. De acordo com [Ye et al. 2010], a virtualização proporciona benefícios como administração flexível e confiabilidade de sistemas. 28

43 Todavia, apesar dos benefícios, ainda não são conhecidos em sua totalidade os impactos da virtualização no desempenho de clusters virtualizados para CAD [Ye et al. 2010]. O objetivo principal deste trabalho é analisar o desempenho de um cluster virtualizado com o virtualizador KVM ao executar aplicações de CAD. O intuito da análise é determinar como a virtualização sobrecarrega o desempenho deste tipo de estrutura computacional. O presente artigo está estruturado da seguinte forma: a Seção 2 introduz o virtualizador KVM no contexto de CAD; a Seção 3 descreve os objetivos a serem alcançados e os procedimentos metodológicos adotados; a Seção 4 apresenta os resultados obtidos; e por fim, a Seção 5 conclui o trabalho com as considerações finais e trabalhos futuros. 2. Trabalhos Relacionados Alguns requisitos fundamentais devem ser atendidos ao se empregar virtualização em CAD, por exemplo, a sobrecarga da virtualização não deve ter impactos significativos no desempenho do sistema, deve-se melhorar a administração do ambiente, permitindo a criação e destruição rápida de VMs, e deve-se obter uma distribuição flexível de recursos de hardware. Outro requisito importante é o isolamento das aplicações em VMs e a migração automática de VMs de um servidor a outro quando necessário, para aumentar a confiabilidade e a segurança do ambiente [Ye et al 2010]. Alguns trabalhos já abordaram o uso do KVM para CAD, como o de [Younge et al. 2011], que analisou a viabilidade da virtualização para CAD. Foram analisados os virtualizadores de código aberto Xen, KVM e VirtualBox e elaborada uma tabelaresumo de suas características principais, sendo a Tabela 1 uma versão atualizada. O desempenho dos virtualizadores foi medido com o High Performance Computing Benchmark (HPCC) e o Standard Performance Evaluation Corporation (SPEC) aplicado em clusters virtuais. A partir dos resultados obtidos foi elaborada uma classificação de virtualizadores para CAD, concluindo que KVM e VirtualBox são os melhores em desempenho global e facilidade de gerenciamento, com o KVM sobressaindo-se em capacidade de computação e de expansibilidade de memória. [Younge et al. 2011] também observou que, ao contrario do Xen, o KVM apresenta poucas oscilações no desempenho, característica que é considerada um componente chave em ambientes de Nuvem. Em um ambiente de Nuvem computacional o serviço ofertado deve ser estável e confiável. Grandes oscilações de desempenho não são bem vindas pelos clientes [Younge et al. 2011] [Napper e Bientinesi. 2009]. Em [Mello et al. 2010] foram avaliados os efeitos do compartilhamento de recursos de um mesmo hospedeiro por múltiplos clusters virtualizados com VirtualBox. O SO do servidor hospedeiro foi incapaz de distribuir igualmente os recursos entre clusters virtualizados com o VirtualBox. Isto não é bem vindo, por não garantir que clientes que paguem igualmente por um serviço de instancia de VMs com configurações iguais obtenham desempenhos diferentes. Em um ambiente de cluster, o desempenho de toda a estrutura em uma aplicação com carga de trabalho homogeneamente distribuída, com barreiras de sincronização ativadas, é limitado pelo elemento computacional de menor desempenho. Logo, é importante garantir distribuição justa de recursos entre VMs hospedadas em um mesmo servidor hospedeiro. 29

44 [Johnson et al. 2011] analisa o desempenho do KVM para aplicações de CAD, todavia de cunho educacional, visando implementar um cluster virtualizado para prover infraestrutura de ensino de programação paralela com MPI e o treinamento no uso de sistemas de arquivos paralelos Hadoop. Todavia, não foram verificados os efeitos do compartilhamento de recursos de um mesmo hospedeiro por múltiplas VMs no desempenho dos clusters virtuais, e nem se o SO hospedeiro distribui os recursos de maneira equipotente entre as VMs. Este trabalho tem por objetivo verificar a ocorrência de sobrecargas no desempenho de clusters virtualizados com o KVM e qual o efeito do compartilhamento de recursos de um mesmo hospedeiro por clusters virtualizados com o KVM em seu desempenho. Este trabalho está inserido no contexto de uma pesquisa, em nível de mestrado, que estuda a aplicabilidade do paradigma da computação em nuvem em aplicações cientificas biomédicas. Tabela 1. Resumo das características dos virtualizadores de código aberto. Ultima versão 4.3 Xen KVM VirtualBox Embutido no Kernel Linux mais recente Para-virtualização Sim Não Sim Virtualização total Sim Sim Sim CPU hospedeira x86, x86-64, IA-64 x86, x86-64, IA-64, PPC x86, x86-64 CPU convidada x86, x86-64, IA-64 x86, x86-64, IA-64, PPC x86, x86-64 Windows, Linux, SO hospedeiro Linux, Unix Linux OS X, Solaris, Unix SO convidado Linux, Windows, NetBSD Windows, Linux, Unix Windows, Linux, Unix, Solaris VT-x / AMD-v Opcional Requerido Opcional Núcleos suportados Memória suportada 5TB 4TB 1TB Aceleração 3d Xen-GL VMGL Open-GL, Direct3D Live Migration Sim Sim Sim Licença GPL GPL GPL/Proprietária 3. Mensurando o Desempenho do KVM para CAD Esta seção aborda a metodologia de pesquisa utilizada, descrevendo o ambiente de provas, as ferramentas de avaliação de desempenho empregadas e os testes executados. Todos os testes foram executados trinta vezes. Para cada teste foram descartadas as amostras obtidas de maior e o menor valor e calculada a média das demais. Esta medida foi adotada devido aos valores obtidos nestas amostras em particular estarem muito afastadas da média das demais Ambiente de Testes Os experimentos foram executados em quatro computadores equipados com processadores Intel Core 2 Quad Q8200 operando em frequência de 2.8 GHz. Esse 30

45 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014 processador tem um conjunto de instruções específicas para virtualização. Os computadores tem 4 GB de memória principal, do tipo DDR 2 com frequência de operação de 800 MHz. A interconexão entre os computadores foi realizada com adaptadores e comutador de rede operando em conformidade com o padrão Gigabit Ethernet 10/100/1000. A ferramenta de virtualização utilizada para a criação de todas as VMs usadas nos experimentos foi o KVM. A escolha do KVM como ferramenta de virtualização deste estudo em relação a outros virtualizadores de código aberto é motivada por o mesmo ser suportado por algumas das principais ferramentas para implementação de nuvens computacionais, como Eucalyptus e Nimbus [Endo et al 2010]. Para a construção dos clusters foi utilizado o SO Rocks Clusters bit. O Rocks Clusters é um SO baseado em Linux desenvolvido para simplificar o processo de criação de clusters para CAD [Papadopoulos, Katz e Bruno. 2003]. Os hospedeiros de VMs utilizaram o CentOS bit como SO Ferramentas de Avaliação de Desempenho Para comparar o desempenho global dos diferentes ambientes testados foi utilizado o HPCC [Luszczek et al. 2006]. O HPCC é o conjunto de testes padrão da comunidade de pesquisa em CAD [Ye et al. 2010]. O HPCC avalia o desempenho do processador, da memória, da comunicação inter-processos e da rede de comunicação. É constituído pelos seguintes testes: HPL O High Performance Linpack mede a quantidade de operações de ponto flutuante por segundo (FLOPS) realizadas por um sistema computacional durante a resolução de um sistema de equações lineares. É o teste mais importante para CAD [Younge et al. 2011]; DGEMM Mede a quantidade de FLOPS durante uma multiplicação de matrizes de números reais de ponto flutuante de precisão dupla; STREAM Mede a largura de banda de memória principal (em GB/s). PTRANS O Parallel matrix transpose mede a capacidade de comunicação de uma rede. Ele testa as comunicações onde pares de processadores comunicam-se entre si simultaneamente transferindo vetores de dados da memória; RandomAccess Mede a taxa de atualizações aleatórias na mémoria (GUPs). FFT O Fast Fourier Transform mede a quantidade de operações com números complexos de precisão dupla em GFlops durante a execução de uma Transformada Rápida de Fourier unidimensional. Communication Latency/Bandwidth Mede a largura de banda (em MB/s) e a latência da rede durante a comunicação inter-processos MPI utilizando padrões de comunicação não simultânea (ping-pong) e simultânea (Anel de processos Aleatoriamente Ordenados (ROR) e Anel Naturalmente Ordenado (NOR)). O HPCC possui três modos de execução: single, star e mpi. O modo single executa o HPCC em um único processador. No modo star todos os processadores executam cópias separadas do HPCC, sem comunicação inter-processo. No modo mpi todos os processadores executam o HPCC em paralelo, empregando comunicação 31

46 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014 explícita de dados [Ye et al. 2010]. O HPCC requer a instalação de uma versão do MPI e do Basic Linear Algebra System (BLAS). Para a realização dos experimentos deste trabalho foram utilizados o OpenMPI (OMPI 1.4.1) e o ATLAS (ATLAS 3.8.0). Os componentes do HPCC são classificados e agrupados pelo padrão em que acessam a memória [Luszczek et al. 2006], conforme mostrado na Tabela 2. Outra forma de classificar estes componentes leva em conta o tipo de recurso de hardware mais requisitado [Zhao et al. 2010] (Tabela 3). Tabela 2. Classificação de [Luszczek et al. 2006]. Local Global DGEMM HPL STREAM PTRANS RandomAccess (modo star) RandomAccess (modo mpi) FFT (modo star) FFT (modo mpi) Tabela 3. Classificação de [Zhao et al. 2010]. Computação Acesso a Memória Rede de Comunicação HPL RandomAccess PingPongLatency DGEMM STREAM PingPongBandwidth FFT PTRANS HPL STREAM PTRANS PTRANS Para este trabalho é proposta uma nova classificação, que leva em conta as duas anteriores, sendo exibida na Tabela 4. Tal classificação é necessária, pois as anteriores, quando utilizadas isoladamente, não cobrem todos os casos de aplicação desses testes. Por exemplo, ao executar-se os testes PingPongBandwidth e PingPongLatency em um único servidor, não se está medindo o desempenho da rede de comunicação e sim o desempenho da comunicação inter-processos local ao servidor, aplicação não coberta pelas classificações anteriores. O mesmo raciocínio pode ser aplicado a medidas de acesso a memória com o RandomAccess em modo mpi. Como o STREAM e o DGEMM apenas executam em modo star, podem obter apenas medidas de capacidade local. Tabela 4. Nova Classificação Proposta. Comp. Local DGEMM HPL FFT Comp. Global HPL FFT Acesso a Mem. Local Acesso a Mem. Global STREAM RandomAccess RandomAccess 32 Comunicação Inter-processos Local PingPongLatency PingPongBandwidth ROR Latency ROR Bandwidth NOR_Latency NOR_Bandwidth PTRANS Rede de Comunicação PingPongLatency PingPongBandwidth ROR Latency ROR Bandwidth NOR_Latency NOR_Bandwidth PTRANS

47 Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA Método Experimental O objetivo geral deste trabalho é verificar a adequabilidade do KVM para CAD. Os seguintes objetivos específicos foram utilizados na estruturação dos testes realizados: 1. Determinar a sobrecarga provocada pela virtualização no desempenho de um cluster virtual; 2. Determinar os efeitos no desempenho de clusters virtuais durante o uso concorrente de recursos de um mesmo hospedeiro físico por esses clusters Desempenho em ambiente de cluster Para alcançar o objetivo específico 1 foram testados e comparados os desempenhos de dois clusters, nomeados Gilgamesh e Arthuria, com o HPCC. O cluster Gilgamesh foi instalado em hardware nativo (sem uso de virtualização), com quatro CPUs disponíveis por nó e quatro nós ao total. Para prover igualdade de condições com o cluster Arthuria, um dos pentes de memória de 2GB foi removido de cada computador, ficando os nós de Gilgamesh com 2 GB de capacidade de memória instalada. O cluster Arthuria, por sua vez, é composto por VMs implementadas com o KVM, hospedadas em servidores físicos e distribuição de uma VM por servidor hospedeiro. Cada VM do cluster Arthuria conta com quatro v-cpus e 2GB alocados para uso como memória principal. Os outros 2 GB de memória restantes nos servidores hospedeiros são destinados para o uso exclusivo de seu SO Efeitos do compartilhamento de recursos. Foram instanciados dois clusters virtuais (cluster A e cluster B) em um mesmo servidor para verificar como o compartilhamento de recursos afeta o desempenho individual de cada cluster (objetivo específico 2). Cada cluster foi configurado com dois nós escravos e cada nó escravo com uma vcpu e 1 GB de memória principal, de forma a não esgotar os recursos de processamento e memória do sistema. Os controladores centrais desses clusters são computadores físicos. Esta medida é justificada para que seja necessário que as VMs utilizem a rede de comunicação. Se assim não fosse, os testes de rede não mediriam o desempenho da capacidade de comunicação em rede e sim a comunicação inter-processos local, conforme exposto em subseção anteriormente. Inicialmente foi medido o desempenho de um desses clusters virtuais com o HPCC, o cluster A. Em seguida o desempenho de ambos foi aferido simultaneamente com o HPCC e foram entre si, para verificar se o SO do hospedeiro é capaz de dividir igualmente os recursos entre as VMs. O desempenho do cluster A executado em isolado foi comparado ao desempenho do cluster A executado em uma situação de competição, para determinar como a competição degenera o desempenho. É importante garantir que dois usuários que contratam um determinado serviço o recebam com desempenho similar. Se o serviço, neste caso instâncias de VMs, é fornecido em um mesmo hospedeiro, o SO do hospedeiro tem que distribuir os recursos igualmente entre as VMs. Se isto não ocorre, então não se provê uma boa qualidade de serviço, o que implica em impactos negativos para os usuários [Younge et al. 2011]. 33

48 4. Resultados Obtidos Esta seção apresenta os resultados obtidos dos testes e o que foi verificado em cada um Sobrecargas da virtualização em ambiente de cluster As médias dos resultados obtidos em cada teste são apresentadas como uma fração dos obtidos pelo sistema nativo. A Figura 1 apresenta o desempenho médio das amostras obtidas pelo HPCC no modo mpi, exceto para os testes DGEMM e STREAM, que não dispõe deste modo, sendo então apresentados seus resultados para o modo star. A capacidade de computação dos clusters Arthuria e Gilgamesh foi medida com os testes HPL, DGEMM e FFT. Para o teste FFT, o cluster Arthuria tem desempenho 39% menor que o cluster Gilgamesh. O cluster Arthuria apresenta também desempenho 20% menor para o HPL e 22% para o DGEMM. Estes resultados indicam que aplicações computacionais são sensíveis a virtualização em graus distintos. A capacidade de leitura e escrita (E/S) em memória principal, em âmbito global (RandomAccess), é bastante reduzida no cluster Arthuria, estando abaixo da metade da obtida pelo Gilgamesh. A capacidade de E/S em memória, a nível local ao servidor, é surpreendentemente favorável ao cluster virtualizado, o que, dado o resultado dos outros testes e a condição de o acesso à memória principal do servidor pela VM sempre necessitar passar pelo gerenciador de VMs antes, o que torna impossível de um sistema virtual ser mais rápido que o nativo, indica uma possível falha do HPCC. O motivo dessa anormalidade não é conhecido e volta a ocorrer nos demais testes. Figura 1. Desempenho dos ambientes de cluster no HPCC. Observando a Figura 1 percebe-se que a largura de banda de comunicação cluster Arthuria é similar a apresentada pelo cluster Gilgamesh para o padrão de comunicação PingPong e muito inferior para os padrões de comunicação inter-processo NOR e ROR. Também pode-se observar na Figura 1 que a latência de rede do cluster Arthuria é muito maior que a cluster Gilgamesh, para todos os padrões de comunicação testados. Essa grande latência observada na comunicação pode explicar porque o cluster 34

49 Arthuria apresenta desempenho inferior em quase todos os testes. Excetuando-se os testes DGEMM e STREAM, que operam em modo star, todos os demais testes fazem uso intensivo da rede de comunicação. Logo, tem-se que a latência de rede é o grande gargalo de desempenho do cluster Arthuria em todos os aspectos que dela demandem. O desempenho obtido no teste PTRANS foi similar para ambos os clusters. É possível que ao aumentar a escala dos clusters, os clusters virtualizados com o KVM apresentem uma diferenciação de desempenho ainda maior em relação a clusters instalados em hardware nativo, para as aplicações que façam uso intensivo da rede de comunicação, assim como ocorre com clusters virtualizados com o Xen [Ye et al. 2010] Efeitos do compartilhamento de recursos A Figura 2 apresenta os resultados obtidos durante a execução de dois clusters virtuais em um mesmo hospedeiro. Foi observado que a capacidade de computação de ambos os clusters é bastante similar, o que indica boa distribuição dos recursos locais de processamento entre as VMs pelo SO hospedeiro. A capacidade da rede de comunicação obteve desempenho demasiadamente variável, possivelmente devido à existência de uma única interface de rede no servidor hospedeiro. A largura de banda de comunicação obtida pelo cluster B foi maior que a do cluster A, assim como a latência. Isso refletiu na variação de desempenho entre os clusters em alguns dos testes que dependem da rede comunicação, como o FTT, o RandomAccess e o PTRANS. Nos testes que demandam mais por largura de banda, o cluster B foi superior, nos que demandam mais por menor latência, apresentou-se inferior. Figura 2. Desempenho de clusters virtuais que compartilham mesmo hospedeiro. A Figura 3 Apresenta os resultados para os testes do HPCC no cluster A antes de concorrer por recursos com o cluster B, e também durante a concorrência. Observa-se claramente que o desempenho do cluster A cai durante o período que competiu por recursos com o cluster B. A queda é maior nos testes de capacidade de comunicação, por ter aumentado a quantidade de VMs que concorreram pela interface de rede, o que refletiu na redução do desempenho dos testes que demandaram da rede. 35

50 Figura 3. Comparativo do desempenho do cluster A isolado com o desempenho obtido pelo cluster A em situação de competição por recursos. Em paralelo a execução do HPCC nos clusters virtuais foi verificado o percentual de utilização da CPU hospedeira por cada VM. Em uma situação ideal todas as VMs utilizam um percentual igual de CPU durante toda a execução do HPCC, chegando a um máximo de 25% de utilização por VM (um único núcleo de processamento do servidor). A Figura 4 apresenta o consumo de CPU do hospedeiro pelas VMs do cluster A, quando executado isoladamente. Cada PID na Figura 4 referese a um identificador do processo que representa uma VM no SO hospedeiro. Observase na Figura 4 que a utilização de CPU por ambas as VMs é similar durante a maioria do tempo de execução do HPCC, sem extrapolar o limite de 25% dos recursos totais por VM e 50% dos recursos globais para o cluster. Figura 4. Utilização da CPU hospedeira pelo cluster A isolado. 36

51 O mesmo não pode ser dito durante a execução de dois clusters em paralelo no mesmo hospedeiro. A Figura 5 apresenta o consumo de CPU do hospedeiro pelas VMs dos clusters A (PIDs e 3238) e B (PIDs 3621 e 3998). Observa-se uma maior oscilação na porcentagem de utilização de CPU pelas VMs dos clusters, onde todas reduzem a frequência com que utilizam 100% dos recursos designados e com as do cluster B oscilando mais que as do cluster A, que foram instanciadas antes. É possível que tais oscilações no uso da CPU ocorram com mais frequência no período de tempo em que o HPCC esta executando os testes que demandam de maior capacidade da rede, o que poderia ser explicado pelo aumento da quantidade de VMs compartilhando a mesma interface de rede. As menores oscilações estariam no período de tempo em que o HPCC esta executando os testes que envolvem mais computação do que comunicação. Curiosamente, mesmo que o cluster B tenha apresentado menor utilização global de CPU, apresentou desempenho de computação similar ao cluster A em nível local e superior em âmbito global. Isto ocorreu provavelmente pelo cluster B ter sido favorecido na distribuição dos recursos de rede. Testes como o HPL e FFT demandam tanto da capacidade de comunicação quanto da largura de banda de comunicação. Figura 5. Utilização da CPU hospedeira pelos clusters A e B compartilhados. 5. Considerações Finais Buscando verificar a adequabilidade do KVM para aplicações CAD, testes com o HPCC foram executados para determinar a sobrecarga de virtualização em um ambiente de cluster e o efeito do compartilhamento de recursos de clusters diferentes em um mesmo hospedeiro. Diante da percepção da não adequabilidade das classificações atuais dos testes do HPCC, que não cobrem todos os casos de aplicação dos mesmos, uma nova, mas abrangente, foi proposta. 37

52 Foi observado que a virtualização provoca sobrecarga de desempenho, e que a mesma é mais sentida em aplicações que demandem da rede de comunicação de que das que demandam pelos recursos de computação locais. Além disso, também foi observado que o compartilhamento de recursos nos hospedeiros degrada o desempenho de ambos os ambientes que concorrem por tais recursos, e que maior é a degradação quando mais VMs disputam os recursos. Isso ocorre devido a incapacidade do SO hospedeiro de dividir seus recursos entres os hospedeiros. De uma maneira geral, o KVM proporciona desempenho adequado a aplicações de CAD que demandem pouca comunicação inter-processo e desempenho inadequado para aplicações que demandem de maior quantidade de comunicação inter-processo. Como trabalho futuro pretende-se adicionar mais interfaces de rede aos servidores hospedeiros, em slots do tipo PCI Express, e reexecutados os testes com compartilhamento de recursos. Isto será feito para verificar se, ao fornecer interfaces de rede exclusivas para cada VM, seus desempenhos globais tornam-se mais similares. Referências Beserra, D.W.S.C., Borba, A., Souto, S.C.R.A., de Andrade, M.J.P, e de Araújo, A.E.P. (2012) "Desempenho de Ferramentas de Virtualização na Implementação de Clusters Beowulf Virtualizados em Hospedeiros Windows." Em: X Workshop em Clouds, Grids e Aplicações-SBRC SBC, Ouro Preto, pp Endo, P. T., Gonçalves, G. E., Kelner, J., e Sadok, D. (2010) A Survey on Open-source Cloud Computing Solutions. Em: Anais do VIII Workshop em Clouds, Grids e Aplicações, pp Johnson, E., Garrity, P., Yates, T., e Brown, R. (2011) Performance of a Virtual Cluster in a General-purpose Teaching Laboratory, In: 2011 IEEE International Conference on Cluster Computing. Pp IEEE. Kejiang, Y., Jiang, X., Chen, S., Huang, D. e Wang, B. (2010) "Analyzing and modeling the performance in xen-based virtual cluster environment." Em: 12th IEEE International Conference on High Performance Computing and Communications (HPCC). IEEE. Luszczek, P. R., Bailey, D. H., Dongarra, J. J., Kepner, J., Lucas, R. F., Rabenseifner, R., & Takahashi, D. (2006). The HPC Challenge (HPCC) benchmark suite. In Proceedings of the 2006 ACM/IEEE conference on Supercomputing pp ACM. Mello, T. C. Schulze, B. Pinto, R. C. G. e Mury, A. R. (2010) Uma análise de recursos virtualizados em ambiente de HPC, Em: Anais VIII Workshop em Clouds, Grids e Aplicações, XXVIII SBRC/ VIII WCGA, SBC, Gramado, pp Napper, J. e Bientinesi, P. (2009) Can cloud computing reach the TOP500?, Em: Proc. Combined Workshops on UnConventional High Performance Computing Workshop Plus Memory Access Workshop, UCHPC-MAW '09, pp Papadopoulos, P. M., Katz, M. J., e Bruno, G. (2003). NPACI Rocks: Tools and techniques for easily deploying manageable linux clusters. Concurrency and Computation: Practice and Experience, 15(7 8),

53 Ye, K., Jiang, X., Chen, S., Huang, D., e Wang, B. (2010) "Analyzing and modeling the performance in xen-based virtual cluster environment." High Performance Computing and Communications (HPCC), th IEEE International Conference on. IEEE. Younge, A. J., Henschel, R., Brown, J. T., von Laszewski, G., Qiu, J., Fox, G. C., (2011) "Analysis of virtualization technologies for high performance computing environments." 2011 IEEE International Conference on Cloud Computing (CLOUD). IEEE. 39

54

55 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XII Workshop de Computação em Clouds e Aplicações (WCGA) Sessão Técnica 2 Elasticidade

56

57 Uma Proposta de Framework Conceitual para Análise de Desempenho da Elasticidade em Nuvens Computacionais Emanuel F. Coutinho 1,2,4, Danielo G. Gomes 1,3, José Neuman de Souza 1,2 1 Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat) 2 Mestrado e Doutorado em Ciência da Computação (MDCC) 3 Departamento de Engenharia em Teleinformática (DETI) 4 Instituto UFC Virtual Universidade Federal do Ceará Fortaleza CE Brasil emanuel@virtual.ufc.br, {danielo,neuman}@ufc.br Abstract. Elasticity can be understood as how a computational cloud adapts to variations in their workload by provisioning and de-provisioning resources. This article proposes a conceptual framework for conducting elasticity performance analysis in cloud computing in a systematic and reproducible way. For verification and validation of the proposal, we performed a case study in the Cloud UFC, a private cloud installed on Campus do Pici, Federal University of Ceará. As a result, two experiments were designed using microbenchmarks and a classic scientific application. Through these experiments, the framework was validated in their activities, allowing systematization of an analysis of the elasticity through mechanisms of autonomic computing and a set of allocation time and allocated resources oriented metrics. Resumo. Elasticidade pode ser entendida como o quão uma nuvem computacional se adapta a variações na sua carga de trabalho através do provisionamento e desprovisionamento de recursos. Este artigo propõe um framework conceitual para a realização de análise de desempenho da elasticidade em nuvens computacionais de maneira sistemática e reproduzível. Para verificação e validação da proposta, realizou-se um estudo de caso na Cloud UFC, uma nuvem privada instalada no Campus do Pici da Universidade Federal do Ceará. Como resultado, dois experimentos foram projetados utilizando microbenchmarks e uma aplicação científica clássica. Através destes experimentos, o framework foi validado em suas atividades, permitindo a sistematização de uma análise da elasticidade por meio de mecanismos de computação autonômica e um conjunto de métricas orientadas a tempos de alocação e recursos alocados. 1. Introdução Com o aumento de acesso aos ambientes computacionais em nuvem e sua facilidade de utilização, baseada no modelo de pagamento por uso, é natural que a quantidade de usuários e as respectivas cargas de trabalho também cresçam. Como consequência, os provedores devem ampliar seus recursos e manter o nível de qualidade acordado com os clientes, sob pena de quebras do Service Level Agreement (SLA) e decorrentes multas. O monitoramento de recursos computacionais, como CPU, memória e banda, se torna essencial tanto para os provedores, os quais disponibilizam os serviços, quanto 43

58 para seus clientes. Uma maneira de monitorar aplicações em nuvem de modo mais efetivo é utilizar mecanismos de computação autonômica, através dos quais recursos são adicionados e removidos do ambiente conforme limiares de uso pré-estabelecidos [Kephart e Chess 2003]. Esse tipo de estratégia de monitoramento está diretamente associado a uma das principais características da Computação em Nuvem: a elasticidade. Elasticidade pode ser definida como o quão um sistema computacional é capaz de se adaptar a variações na carga de trabalho pelo provisionamento e desprovisionamento de seus recursos de maneira autonômica, de modo que em cada instante no tempo os recursos disponíveis atendam da melhor maneira possível à demanda da carga de trabalho [Herbst et al. 2013]. Um estudo sobre elasticidade em nuvem foi realizado em [Coutinho et al. 2013b], com destaque para diversos aspectos como: definições, estado da arte da elasticidade, análise de desempenho, métricas, estratégicas elásticas, benchmarks, desafios e tendências na construção de soluções elásticas. Diversas arquiteturas para soluções de provisionamento e manutenção de SLA utilizando recursos de computação autonômica tem sido propostas [Rego et al. 2011, Tordsson et al. 2012]. Porém, devido à pouca disponibilidade de informação acerca de sua instalação e configuração corretas, do ponto de vista experimental em geral não é trivial implementar tais arquiteturas, muito menos aplicá-las em ambientes de nuvem. Além disso, nota-se uma carência de trabalhos na literatura que avaliem o desempenho destes ambientes de forma metodológica e sistematizada. Na tentativa de diminuir esta lacuna, propomos um framework conceitual para a resolução de um problema específico de análise de desempenho da elasticidade no domínio das nuvens computacionais. O objetivo geral deste artigo é analisar o desempenho da elasticidade em um ambiente de nuvem de maneira sistemática. Para alcançá-lo, traçamos três objetivos específicos: (i) propor um framework conceitual com foco em elasticidade; (ii) realizar experimentos para validação do framework utilizando métricas orientadas a velocidade (tempo de resposta) e utilização de recursos; e (iii) implementar ferramentas para suporte à análise de desempenho proposta (microbenchmarks, cargas de trabalho e visualização). Para a validação da proposta, realizamos um estudo de caso na Cloud UFC 1, uma nuvem privada instalada no Campus do Pici da Universidade Federal do Ceará. 2. Proposta de um Framework Conceitual Um framework ou arcabouço conceitual é um conjunto de conceitos utilizados para a resolução de um problema de um domínio específico, sendo que existem dois tipos: frameworks verticais (ou especialistas, confeccionados através da experiência obtida em um determinado domínio específico ou de um especialista, tentando resolver problemas de um determinado domínio de aplicação), e frameworks horizontais (podem ser utilizados em diferentes domínios) [Cruz 2013]. Sendo assim, o framework conceitual proposto neste trabalho é vertical. Nele propomos um conjunto de atividades para a execução de uma análise de desempenho da elasticidade em nuvem computacional de maneira sistematizada. As atividades relacionadas ao planejamento da elasticidade foram elaboradas com base em princípios de computação autonômica, na arquitetura definida em [Kephart e Chess 2003]. Basicamente, o fra- 1 CloudUFC - cloud/ 44

59 Figura 1. Fluxo de atividades do framework conceitual proposto mework possui três macroatividades, relacionadas ao planejamento, inicialização de serviços e execução, e suas respectivas atividades. A Figura 1 ilustra o framework de maneira integrada e com a ideia de fluxo de operação. A sequência de atividades representada pela linha cheia possibilita a análise de desempenho de maneira genérica. A linha pontilhada representa sua extensão para um estudo de caso de elasticidade. A ideia de ciclo de vida ou fases pode ser aplicada nesta abordagem devido à natureza cíclica da análise de desempenho proposta. Após a atividade Executar Ações é possível retornar para um replanejamento, ou repetir a macroatividade Executar Análise de Desempenho. 3. Materiais e Métodos Para a validação do framework, dois experimentos foram projetados e executados em um mesmo ambiente de nuvem. O OpenNebula 3.8 foi utilizado para a criação de uma 45

60 nuvem privada. Não foram utilizados neste trabalho nuvens públicas comerciais. Todas as máquinas físicas são do tipo Ci5 e Ci7, 24 GB de memória, sistema operacional Ubuntu Server bits e hipervisor KVM. Foram utilizadas quatro máquinas virtuais nos experimentos, todas com 1 VCPU, 1 GB de memória e sistema operacional Ubuntu Server bits. Foi utilizado como servidor web o Apache Tomcat, balanceador de carga o NGINX, e gerador de cargas de trabalho o HTTPERF. A instanciação do framework foi desenvolvida em Java e shell script. A representação do testbed está descrita na Figura 2. Figura 2. Arquitetura e ambiente experimental 3.1. Projeto dos Experimentos O objetivo dos experimentos é avaliar o comportamento de aplicações web diante de cargas de trabalho dinâmicas, e como se comportam de maneira autonômica para adaptação a variações de demanda e manutenção do SLA. Para isso, o framework será utilizado, e assim suas atividades serão instanciadas para o ambiente e para o projeto de experimentos. Dessa maneira, as atividades serão validadas, não implementando soluções ótimas. As ferramentas foram definidas na infraestrutura. Para a macroatividade Planejar Suporte, arquivos texto registram o log das operações de coleta das máquinas virtuais. O log gerado para cada máquina virtual em arquivo texto contém a data da coleta, valores de utilização de CPU, memória, disco e rede. Também foi gerado um arquivo de log para a média de utilização de CPU e alocação de recursos, permitindo sua leitura em uma ferramenta construída especificamente para a visualização gráfica de todas as métricas de maneira individual (métricas coletadas de cada máquina virtual) e em conjunto (métricas coletadas de todas as máquinas virtuais ao mesmo tempo). A consolidação dos dados se dá por meio da leitura dos arquivos de log, onde a partir desses dados decisões são tomadas. O dados coletados são apresentados sob a forma de gráficos de linha, disponibilizados através de uma aplicação de visualização. O intervalo de coletas definido foi de 1 segundo adicionado do custo da coleta e análise dos resultados. Para a avaliação da elasticidade, utilizamos um conjunto de métricas proposto em [Coutinho et al. 2013a], divididas em dois grupos: tempo de execução de operações e 46

61 utilização de recursos. As métricas relacionadas a tempo são: Tempo de Alocação Sobreprovisionado (TASo), correspondente ao tempo utilizado em operações de remoção de recursos; Tempo de Alocação Subprovisionada (TASu), utilizado para medir o tempo de operações de adição de recursos; Tempo de Alocação Estabilizada (TAE), tempo no qual não há adição ou remoção de recursos; e Tempo de Alocação Transitória (TAT), correspondente ao tempo em que os efeitos da adição ou remoção de recursos ainda não impactaram no ambiente. As métricas relacionadas a recursos são: Total de Recursos Alocados Subprovisionados (TRASu), correspondente à quantidade de recursos alocados em um estado subprovisionado, mas não estabilizado; Total de Recursos Alocados Sobreprovisionados (TRASo), indicando a quantidade de recursos alocados em um estado sobreprovisionado, mas não estabilizado; e o Total de Recursos Alocados Estabilizados (TRAE), que corresponde à quantidade de recursos em um estado estabilizado. As métricas Elasticidade de Scaling UP e Elasticidade de Scaling Down, propostas por [Herbst et al. 2013], serão utilizadas como análise complementar. Estas métricas avaliam a velocidade na qual um ambiente realiza essas operações. Demais métricas estão descritas na Tabela 1. Cargas de trabalho foram utilizadas diretamente na máquina virtual do balanceador de carga, originadas de navegadores web e HTTPERF, distribuídas entre as demais máquinas virtuais. Adicionalmente, utilizou-se cargas de trabalho diretamente nas máquinas virtuais. A ideia é possibilitar a emulação da concorrência pelos recursos em diferentes maneiras de se utilizar um ambiente de Computação em Nuvem. Para a macroatividade Planejar Elasticidade, um mecanismo baseado na arquitetura de Computação Autonômica definida em [Kephart e Chess 2003] foi construído utilizando aspectos de auto-configuração. Uma estratégia de elasticidade horizontal foi utilizada, através da qual à medida que recursos são necessários, novas instâncias de máquinas virtuais são adicionadas, por meio de um balanceador de carga, e retiradas caso não sejam mais necessárias. A métrica utilizada para disparar ações de elasticidade foi a média do percentual de utilização de CPU das máquinas virtuais. Os limiares utilizados para a execução de ações de elasticidade no ambiente foram: acima de 90% (aloca uma nova máquina virtual), abaixo de 80% (desaloca uma máquina virtual), e entre 80% e 90% (mantém alocação). Esses valores foram definidos considerando a premissa que a situação ideal de consumo de CPU das máquinas virtuais do ambiente deveria ser quase em sua totalidade, maximizando a utilização da capacidade de processamento. Esse valor foi calculado como a média das 10 últimas coletas de utilização de CPU nas máquinas virtuais. Como mecanismo de predição foi utilizado regressão multilinear sobre valores de utilização de CPU, memória, disco e rede, coletados em experimentos prévios, com cargas de trabalho semelhantes. Esse cálculo é realizado para decidir se uma ação de alocação ou desalocação deve ser executada, antes mesmo do cálculo da média. Para o provisionamento dos recursos, a estratégia de um balanceamento de carga foi utilizada, onde máquinas virtuais são adicionadas conforme a necessidade. Um conjunto de scripts foi desenvolvido para promover ações e estratégias de análise. As macroatividades Inicializar Serviços da Análise de Desempenho e Executar Análise de Desempenho foram implementadas através de scripts que inicializam os serviços de coleta, análise, geração das cargas de trabalho (operações manuais com o HTTPERF), e consolidação dos dados, além de analisar e disparar ações. A Tabela 1 47

62 Tabela 1. Projeto de experimentos Características Descrição Sistema Ambiente privado de Computação em Nuvem (OpenNebula) Métricas Tempo de resposta das aplicações, percentual de utilização de CPU, percentual de utilização de memória, pacotes recebidos e enviados em KB, KB lidos e escritos em disco; TASo, TASu, TAE, TAT, TRASu, TRASo, TRAE [Coutinho et al. 2013a]; Elasticidade de Scaling UP e Elasticidade de Scaling Down [Herbst et al. 2013] Parâmetros Fixos CPU, memória, quantidade de máquinas virtuais Fatores Configuráveis Configuração do benchmark (repetições e tamanho da matriz), configuração do BLAST (tamanho do arquivo, tamanho da consulta), configuração do HTT- PERF (quantidade de requisições, taxa de requisições, tempo) Técnica de Avaliação Medição Carga de Trabalho Experimento 1: Executar multiplicações de matrizes (dimensão 200x200x200) através de um microbenchmark construído na linguagem de programação Java, sob a forma de pequenas aplicações web, com requisições disparadas através do HTTPERF, com taxas variando de 1 a 5 requisições por segundo e quantidade de conexões variando em 10, 30 e 50; Experimento 2: Executar uma aplicação científica, o BLAST, através de um microbenchmark construído na linguagem de programação Java, sob a forma de pequenas aplicações web, com requisições disparadas através do HTTPERF, com taxas variando de 1 a 3 requisições por segundo e quantidade de conexões variando em 3, 6 e 9 detalha itens do projeto experimental, tais como métricas e cargas de trabalho Experimento 1 - Microbenchmark Neste experimento projetamos uma carga de trabalho sintética orientada a CPU e memória para multiplicação de matrizes. A duração deste experimento foi de 12min58s. A Figura 3 ilustra a utilização média de CPU, alocação das máquinas virtuais, e o tempo de resposta das requisições. Conforme observado na Figura 3, muitas variações no consumo de CPU ocorreram, e à medida em que a primeira máquina virtual executa requisições, a utilização de CPU aumenta ao longo do tempo. Ao violar o SLA estabelecido, novas instâncias são alocadas. Para memória o comportamento foi quase constante, estando em todas as máquinas virtuais quase sempre em 100% de utilização. O tempo de resposta do servidor teve grandes picos na máquina virtual 1. Estes picos se devem ao fato de que muitas requisições estavam represadas no servidor da máquina virtual 1, e demoraram muito a serem finalizadas. Nas demais máquinas virtuais o comportamento foi mais constante, o que implica em uma distribuição de requisições conforme a necessidade. A média de utilização de CPU e alocação das máquinas virtuais, métricas diretamente associadas à elasticidade, coincidiram quando o SLA estabelecido era violado. Quando a carga de utilização da CPU era inferior ao limite estabelecido, havia uma desalocação de máquinas virtuais Experimento 2 - BLAST A carga de trabalho neste experimento foi projetada para executar uma aplicação científica, o BLAST, orientada a CPU, memória e disco. O BLAST é uma ferramenta de similaridade muito utilizada para sequências de proteínas. A duração do experimento 48

63 Figura 3. Utilização média de CPU, alocação de máquinas virtuais, e tempo de resposta das requisições para o experimento 1 foi de 19 minutos. A Figura 4 ilustra a utilização média CPU, a quantidade de máquinas virtuais alocadas, e o tempo de resposta das requisições. Figura 4. Utilização média de CPU, alocação de máquinas virtuais, e tempo de resposta das requisições para o experimento 2 O BLAST é uma aplicação de computação científica, e seu consumo de CPU é alto, constatado na Figura 4. Logo que a primeira máquina virtual executava requisições, sua utilização de CPU aumentava, e ao superar o SLA estabelecido, novas instâncias 49

64 foram alocadas. Para memória e acesso a disco o comportamento foi quase constante, porém a memória em todas as máquinas virtuais permaneceu quase sempre em 100%, semelhante ao experimento anterior. Espera-se que em aplicações melhores estruturadas com o BLAST, a leitura em disco seja maior devido a pesquisas em arquivos. O tempo de resposta do servidor foi maior na máquina virtual 1, com aproximadamente picos no início, na metade, e no final do experimento. Nas demais máquinas virtuais foi quase constante. Este pico se deve ao fato de que muitas requisições ficaram presas no servidor da máquina virtual 1, demorando mais tempo a finalizarem. Em picos de utilização de CPU as 3 máquinas virtuais foram alocadas, e em geral há uma desalocação logo após. Isso se explica devido à carga de trabalho empregada, que parava de enviar requisições por um intervalo de tempo, período em que as requisições alocadas eram finalizadas Discussão dos Resultados O objetivo dos experimentos foi validar o framework. Todas as atividades definidas na Seção 2 foram executadas e atendidas. De maneira geral, o framework permitiu a realização de análise de desempenho em um ambiente de Computação em Nuvem, com foco em elasticidade. Percebeu-se nos dois experimentos que em alguns momentos a média de utilização da CPU ficou acima do limite. Caso existissem máquinas virtuais adicionais alocadas ao balanceador de carga, seria provável que tais violações não ocorressem tanto. Isso é um aspecto direto da atividade de mecanismos de provisionamento. Nesse caso, o ideal é que instâncias de máquinas virtuais fossem geradas dinamicamente sempre que necessário, e finalizadas quando não mais necessário. Entretanto, este já é um ponto de ajuste a ser realizado sobre o ambiente, alertado pela utilização do framework. O tempo de resposta em geral é alto, mesmo quando novas máquinas virtuais são criadas. Muitos deles devido à latência das operações, e o ideal é que fosse evitada. Para minizar esses altos valores, possivelmente uma escolha de limiares diferentes seria suficiente para manter a latência sempre dentro de um limite aceitável, além da inclusão de uma regra que contemplasse o tempo de resposta como critério para ações de elasticidade. A Tabela 2 contém as métricas calculadas para os dois experimentos. Em ambos experimentos, TAE ocupa a maioria do tempo de alocação, conforme esperado. Isto se deve ao fato que grande parte dos experimentos a alocação dos recursos é estável, variando apenas quando há incremento ou redução de recursos, refletidos nos tempos TASu, TASo e TAT. Apesar de experimentos com características diferentes de cargas de trabalho, Tabela 2. Métricas coletadas para os experimentos 1 e 2 Métrica Experimento 1 Experimento 2 Tempo Total do Experimento (minutos) 12:58 19:00 Tempo de Alocação Estabilizada (TAE) 11:01 16:51 Tempo de Alocação Subprovisionada (TASu) 00:26 00:37 Tempo de Alocação Sobreprovisionada (TASo) 00:27 00:31 Tempo de Alocação Transitória (TAT) 01:03 00:59 Total de Recursos Alocados (máquinas virtuais) Total de Recursos Alocados Estabilizado (TRAE) Total de Recursos Alocados Subprovisionados (TRASu) Total de Recursos Alocados Sobreprovisionados (TRASo)

65 todas as métricas de tempo possuíram valores percentuais em relação ao tempo total do experimento próximos para os dois experimentos: 84% e 88% (TAE), 3% e 2% (TASu), 2% e 2% (TASo), e 8% e 5% (TAT). Isto indica uma similaridade nos experimentos. Estabilidade não necessariamente implica em atendimento do SLA. Um valor alto para TAE deve ser analisado em conjunto com outros aspectos. O limite superior definido para SLA foi 90%, e ocorreram algumas violações. Isto indica que a capacidade de recursos atingiu o limite. Se houvessem mais recursos, os gráficos de alocação teriam mais degraus, correspondendo à alocações e desalocações de máquinas virtuais. As métricas TRASu e TRASo aumentariam e TRAE diminuiria. Consequentemente TASu e TASo provavelmente seriam maiores. Diferente da métrica TAE, cujo valor é maior que TASu, TASo e TAT, a métrica TRAE mostra que um ambiente pode ter grandes intervalos com alocação estável com poucos recursos. Quanto maior a variação na média de consumo de CPU, maior a adição ou remoção de recursos no ambiente. Apesar que no experimento 1 foram alocados mais recursos às operações de scaling up e scaling down, na média os valores foram bem próximos. O ideal é que quanto maior a quantidade de intervalos em estado de alocação subprovisionada e sobreprovisionada, maior a capacidade do ambiente em se adaptar às demandas impostas. Os valores médios para TRASu, TRASo e TRAE foram bem próximos nos dois experimentos, indicando similaridade nos comportamentos. Para uma avaliação mais completa, as métricas Elasticidade de Scaling UP e Elasticidade de Scaling Down, propostas por [Herbst et al. 2013] foram calculadas. Estas métricas avaliam a velocidade na qual um ambiente realiza essas operações. Os dois experimentos obtiveram valores bem semelhantes. A velocidade de Scaling Up para os dois experimentos foi de 0,03 e 0,01 respectivamente, e de Scaling Down 0,04 e 0,02. O experimento 1 é um pouco mais veloz que experimento 2, sendo um pouco mais eficiente. Porém na prática a diferença é numericamente quase insignificante. Observando os gráficos de alocação percebe-se que os momentos em que ocorrem alocação de recursos são bem parecidos em termos de duração e utilização de recursos. A análise de desempenho muitas vezes depende da carga de trabalho utilizada na aplicação, tendo impacto direto sobre o ambiente. Um desafio para ambientes experimentais é projetar uma carga de trabalho que represente a realidade de um provedor, devido à característica dinâmica de cargas de trabalhos reais. Um estudo do comportamento das cargas de trabalho, através de métodos estatísticos, predição, natureza das aplicações e usuários pode auxiliar no projeto. Como os dois experimentos utilizaram o mesmo ambiente, a carga de trabalho foi o principal elemento a provocar a diferença nos resultados. 4. Trabalhos Relacionados Alguns trabalhos na literatura desenvolveram aplicações e frameworks para operação em ambientes de Computação em Nuvem. Outros propuseram abordagens e metodologias para a realização de análise de desempenho em Computação em Nuvem. Esta seção discute alguns trabalhos correlatos ao framework proposto. Aqui eles estão organizados em (i) frameworks, (ii) benchmarks, e (iii) metodologias para avaliação de desempenho em nuvens computacionais. No que concerne os frameworks e aplicativos para desempenho em nuvens, destacamos o C-METER [Yigitbasi et al. 2009], um framework portável, extensível, com geração e submissão de cargas de trabalho sintéticas. Seguindo um princípio de ciclo de 51

66 vida autoadaptável com gerenciamento autonômico, outro framework que merece destaque é o LoM2HiS [Emeakaroha et al. 2010], cujo objetivo é mapear métricas de infraestrutura (IaaS) para métricas de usuário (SaaS), visando detecção de quebras de SLA. Dentre o conjunto de trabalhos sobre benchmarks, [Sobel et al. 2008] propuseram CloudStone, um benchmark de aplicações web 2.0 para medir o custo monetário usuário/mês. O CloudGauge foi apresentado por [El-Refaey e Rizkaa 2010] para virtualização em Nuvens com o objetivo de medir cargas de trabalho dinâmicas, enquanto o MalStone é voltado para desempenho em aplicações orientadas à CPU [Bennett et al. 2010]. [Li et al. 2010] compararam o desempenho entre provedores de nuvem mediante o benchmark CloudCMP, considerando aspectos de elasticidade, rede, custo e armazenamento, avaliados de maneira sistemática. Critérios a serem utilizados na avaliação da elasticidade são descritos em [Herbst et al. 2013], tais como: processos de adaptação para escalabilidade autonômica; recursos escaláveis para o processo de adaptação; variação da quantidade de recursos alocados; e limite superior da quantidade de recursos que podem ser alocado. Além disso, métricas foram propostas para a medição da elasticidade baseadas em velocidade e precisão. É um trabalho motivacional, não havendo experimentos, porém propõe as métricas Elasticidade de Scaling UP e Elasticidade de Scaling Down, específicas para elasticidade, baseadas em tempos de operações e recursos. Algumas propostas para quantificar elasticidade são discutidas em [Islam et al. 2012], considerando SLA e penalidades em caso de não antendimento do serviço, através de modelos matemáticos. Uma abordagem para a medição da elasticidade de uma nuvem é proposta em [Shawky e Ali 2012], baseada no conceito de stress da nuvem (taxa de recursos requerida pela quantidade de recursos alocados), e tensão da nuvem (variação nos recursos antes e depois de operações de escalonamento). Um modelo matemático foi proposto em [Costa et al. 2011] para representar um provedor de IaaS, e seus experimentos simularam aplicações Bag of Tasks (BoT) em relação aos limites impostos por provedores na execução deste tipo de aplicação. Em geral, o projeto de experimentos não é claro. Muitos trabalhos não informam detalhes dos experimentos, que auxiliam em sua replicação, assim como detalhes da instalação e configuração dos frameworks e benchmarks disponibilizados. Outra deficiência comum em trabalhos é que não é disponibilizada uma metodologia para a Tabela 3. Comparação entre trabalhos relacionados e técnica do experimento utilizada (T): medição (M), simulação (S) e modelagem analítica (MA) Trabalho Objetivo T CloudStone [Sobel et al. 2008] Benchmark para aplicações web 2.0 M C-METER [Yigitbasi et al. 2009] Framework para análise de desempenho em nuvem M CloudGauge Benchmark para virtualização em nuvem e medição M [El-Refaey e Rizkaa 2010] de cargas de trabalho dinâmicas LoM2HiS [Emeakaroha et al. 2010] Framework para mapear métricas de nível mais baixo S para SLA para detecção de violações MalStone [Bennett et al. 2010] Benchmark para medir desempenho de computação intensiva de dados M/S CloudCMP [Li et al. 2010] Comparar desempenho entre provedores de M Computação em Nuvem 52

67 utilização das ferramentas para experimentos. Muitas vezes existem poucos detalhes ou não há uma abordagem sistemática para sua utilização, dificultando a análise de desempenho. A Tabela 3 descreve alguns trabalhos com diferentes níveis de detalhamento do projeto de experimento, o que não quer dizer que não seguem uma metodologia ou não há projeto de experimentos, sendo em geral muito bem escritos. O framework proposto procura estabelecer uma metodologia para a realização de análise de desempenho em ambientes de Computação em Nuvem de maneira sistemática, com foco em elasticidade. Ele destaca o projeto dos experimentos, das cargas de trabalho, coletas e medições. Não define uma arquitetura, mas sugere fortemente aspectos ferramentais que influenciam diretamente em seus componentes. Por ser um framework conceitual, ele é genérico e independente de tecnologia. Como em alguns trabalhos relacionados, a ideia é ser extensível e adaptável, porém projetando a avaliação de maneira flexível e reutilizável. 5. Conclusão Este trabalho teve como objetivo avaliar a elasticidade em ambientes de Computação em Nuvem de maneira metodológica através de um framework conceitual. De maneira geral, o framework permitiu a realização de análise de desempenho em uma nuvem computacional satisafatóriamente através de dois experimentos, atendendo aos objetivos. A contribuição central deste artigo é possibilitar, que uma nuvem sob análise tenha sua elasticidade avaliada de maneira sistematizada, considerando métricas de desempenho. Como contribuições secundárias, propomos um conjunto de microbenchmarks para geração de cargas de trabalho sintéticas e uma ferramenta de visualização gráfica de métricas coletadas de uma nuvem computacional. Mesmo não sendo avaliado o real ganho proporcionado pela utilização do framework, entende-se que a organização e estrutura proporcionados são úteis na avaliação de desempenho. Ainda é necessário o detalhamento de cada atividade do framework, para que seja mais intuitivo o objetivo e a importância de cada atividade. A repetição de sua utilização permitirá um refinamento das atividades, e consequentemente melhoria na sua execução. Como trabalhos futuros, pretendemos utilizar outros mecanismos de elasticidade (horizontal e vertical), outras métricas e estratégias de computação autonômica, expandir a ferramenta de visualização e os microbenchmarks. Também pretende-se realizar um projeto da carga de trabalho que se aproxime de situações reais, e estender a validação do framework em aplicações e ambientes com aplicações reais (e-science, web, aplicações biomédicas), assim como provedores comerciais (por exemplo Amazon Web Services e HP Cloud), e nuvens computacionais híbridas. Referências Bennett, C., Grossman, R. L., Locke, D., Seidman, J., and Vejcik, S. (2010). Malstone: towards a benchmark for analytics on large data clouds. In Proceedings of the 16th ACM SIGKDD international conference on Knowledge discovery and data mining, KDD 10, pages , New York, NY, USA. ACM. Costa, R., Brasileiro, F., Lemos, G., and Mariz, D. (2011). Sobre a amplitude da elasticidade dos provedores atuais de computação na nuvem. In XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2011). 53

68 Coutinho, E., Gomes, D. G., and Souza, J. D. (2013a). An analysis of elasticity in cloud computing environments based on allocation time and resources. In LATINCLOUD 2013, Maceió, Brazil. Coutinho, E., Sousa, F. R. C., Gomes, D. G., and Souza, J. D. (2013b). Elasticidade em computação na nuvem: Uma abordagem sistemática. In XXXI Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2013) - Minicursos. Cruz, F. (2013). Scrum e PMBOK unidos no Gerenciamento de Projetos. Brasport Livros e Multimídia Ltda. El-Refaey, M. and Rizkaa, M. (2010). Cloudgauge: A dynamic cloud and virtualization benchmarking suite. In Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE), th IEEE International Workshop on, pages Emeakaroha, V., Brandic, I., Maurer, M., and Dustdar, S. (2010). Low level metrics to high level slas - lom2his framework: Bridging the gap between monitored metrics and sla parameters in cloud environments. In High Performance Computing and Simulation (HPCS), 2010 International Conference on, pages Herbst, N. R., Kounev, S., and Reussner, R. (2013). Elasticity in cloud computing: What it is, and what it is not. In Proceedings of the 10th International Conference on Autonomic Computing(ICAC 2013), San Jose, CA, pages USENIX. Islam, S., Lee, K., Fekete, A., and Liu, A. (2012). How a consumer can measure elasticity for cloud platforms. In Proceedings of the 3rd ACM/SPEC International Conference on Performance Engineering, ICPE 12, pages 85 96, New York, NY, USA. ACM. Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. Computer, 36(1): Li, A., Yang, X., Kandula, S., and Zhang, M. (2010). Cloudcmp: comparing public cloud providers. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, IMC 10, pages 1 14, New York, NY, USA. ACM. Rego, P., Coutinho, E., Gomes, D., and De Souza, J. (2011). Faircpu: Architecture for allocation of virtual machines using processing features. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International Conference on, pages Shawky, D. M. and Ali, A. F. (2012). Defining a measure of cloud computing elasticity. In Systems and Computer Science (ICSCS), st International Conference on. Sobel, W., Subramanyam, S., Sucharitakul, A., Nguyen, J., Wong, H., Klepchukov, A., Patil, S., Fox, O., and Patterson, D. (2008). Cloudstone: Multi-platform, multilanguage benchmark and measurement tools for web 2.0. Tordsson, J., Montero, R. S., Moreno-Vozmediano, R., and Llorente, I. M. (2012). Cloud brokering mechanisms for optimized placement of virtual machines across multiple providers. Future Generation Computer Systems, 28(2): Yigitbasi, N., Iosup, A., Epema, D., and Ostermann, S. (2009). C-meter: A framework for performance analysis of computing clouds. In Cluster Computing and the Grid, CCGRID 09. 9th IEEE/ACM International Symposium on, pages

69 Métricas para Avaliação da Elasticidade em Computação em Nuvem Baseadas em Conceitos da Física Emanuel F. Coutinho 1,2,4, Paulo A. L. Rego 1,2, Danielo G. Gomes 1,3, José N. de Souza 1,2 1 Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat) 2 Mestrado e Doutorado em Ciência da Computação (MDCC) 3 Departamento de Engenharia em Teleinformática (DETI) 4 Instituto UFC Virtual Universidade Federal do Ceará Fortaleza CE Brasil emanuel@virtual.ufc.br, {pauloalr,danielo,neuman}@ufc.br Abstract. Currently many customers and providers are using resources of cloud computing environments, such as processing and storage, for their applications and services. With the increase in use of resources, a key feature of cloud computing has become quite attractive: elasticity. The elasticity can be defined as how the cloud adapts to variations in their workload by provisioning and deprovisioning resources. This work aims to propose metrics for measuring Cloud Computing elasticity based on Physics concepts, such as stress and tension. For validating the metrics, two experiments were designed in a private cloud, using workloads generated by microbenchmarks to evaluate the elasticity. Resumo. Atualmente muitos clientes e provedores estão utilizando recursos de ambientes de Computação em Nuvem, tais como processamento e armazenamento, para suas aplicações e serviços. Com o aumento na utilização dos recursos, uma das características principais da Computação em Nuvem tem se tornado bastante atrativa: a elasticidade. A elasticidade pode ser definida como o quanto uma nuvem computacional se adapta a variações na sua carga de trabalho através do provisionamento e desprovisionamento de recursos. Este trabalho tem como objetivo propor métricas para a medição da elasticidade em Computação em Nuvem baseada em conceitos da Física, como estresse e tensão. Para a validação das métricas, dois experimentos foram projetados em uma nuvem computacional privada, utilizando cargas de trabalho geradas por microbenchmarks para a avaliação da elasticidade. 1. Introdução Atualmente muitos clientes e provedores estão utilizando recursos de ambientes de Computação em Nuvem, tais como processamento e armazenamento, para a execução de suas aplicações de disponibilização de serviços. Com o aumento na utilização dos recursos, uma das características principais da Computação em Nuvem tem se tornado bastante atrativa: a elasticiade. A elasticidade é uma característica essencial da Computação em Nuvem. Conforme o National Institute of Standards and Technology (NIST), a elasticidade é a ha- 55

70 bilidade de rápido provisionamento e desprovisionamento, com capacidade de recursos virtuais praticamente infinita e quantidade adquirível sem restrição a qualquer momento [Mell e Grance 2009]. Uma definição de elasticidade mais recente proposta por [Herbst et al. 2013] consiste no quanto um sistema é capaz de se adaptar a variações na carga de trabalho pelo provisionamento e desprovisionamento de recursos de maneira autonômica, de modo que em cada ponto no tempo os recursos disponíveis combinem com a demanda da carga de trabalho o mais próximo possível. Considerando que a elasticidade está se tornando uma necessidade cada vez maior em ambientes de nuvens devido à característica dinâmica das diversas cargas de trabalho impostas, diversos provedores estão disponibilizando serviços de monitoramento de recursos e provimento da elasticidade. Diversas estratégias para a avaliação da elasticidade foram propostas na literatura [Islam et al. 2012, Shawky e Ali 2012, Herbst et al. 2013, Coutinho et al. 2013]. Porém, a maneira de se medir a elasticidade é bastante variada, não havendo ainda uma padronização para tal tarefa. Um aspecto comum é a utilização de recursos do ambiente, como CPU e memória, para indiretamente se avaliar a elasticidade, mesmo sem ter uma métrica específica para a elasticidade. O conceito de elasticidade é comum em algumas áreas de atuação diferentes da Computação, tais como a Física, Biologia e Microeconomia. [Gambi et al. 2013] e [Shawky e Ali 2012] descrevem algumas analogias da elasticidade de outras áreas em comparação à elasticidade em Computação em Nuvem. Este artigo tem como objetivo geral permitir que um usuário ou provedor possa medir e avaliar a elasticidade de uma nuvem computacional. Para seu atendimento, três objetivos específicos foram traçados: (i) identificação de métricas na literatura para medição da elasticidade em Computação em Nuvem; (ii) definição de um conjunto de métricas para a medição da elasticidade; e (iii) realização de experimentos para a validação das métricas. As principais contribuições deste artigo são: métricas para a avaliação da elasticidade em Computação em Nuvem baseadas nos conceitos de tensão e estresse da Física; e um estudo de caso com experimentos realizados em uma nuvem computacional para avaliação da elasticidade, utilizando cargas de trabalho geradas por meio de microbenchmarks. O trabalho está organizado da seguinte forma, além desta introdução: a Seção 2 apresenta os trabalhos relacionados; a Seção 3 descreve as métricas propostas; na Seção 4 são descritas a metodologia de avaliação, os experimentos, e discussão do resultados; finalmente, a conclusão e trabalhos futuros são apresentados na Seção Trabalhos Relacionados Diversos trabalhos consideram múltiplos aspectos do ambiente para alocação de recursos, baseando-se nesses parâmetros para a tomada de decisão. A maioria dos trabalhos executa a coleta de informações dos ambientes e os utilizam para decidir a alocação dos recursos. Em [Zhang et al. 2010], uma abordagem para o gerenciamento de recursos da infraestrutura utilizando um loop de controle adaptativo foi proposta. Dois loops de controle foram utilizados, um para alocar os recursos e outro para otimizar o consumo. Seus experimentos utilizaram o Xen e trabalharam no nível de PaaS (Platform as a Service). Este trabalho é genérico para se adequar a qualquer aspecto, como CPU e memória, porque ele monitora métricas de desempenho e pode modificá-las sempre que necessário. Maneiras de quantificar elasticidade são discutidas em [Islam et al. 2012], con- 56

71 siderando aspectos de qualidade e penalidades em caso de não antendimento do serviço. Um modelo matemático baseado em penalidades, recursos e demandas foi descrito. Além disso, experimentos foram realizados na Amazon EC2 com o benchmark TPC-W e o aplicativo JMeter para geração de cargas de trabalho. No trabalho proposto, a diferença é que cargas de trabalho foram geradas através de microbenchmarks projetados, e como gerador de carga foi utilizado o HTTPERF. Uma abordagem para a medição da elasticidade de uma nuvem foi proposta por [Shawky e Ali 2012], baseada nos princípios da elasticidade definida na Física. Nesta definição é abordado o conceito de estresse da nuvem, definido como a taxa de recursos requerida pela quantidade de recursos alocados, e o de tensão da nuvem, definido como a variação nos recursos antes e depois de operações de escalonamento. A diferença entre esse trabalho e o proposto é que as métricas utilizadas são calculadas de maneiras diferentes, apesar de seguir o mesmo princípio. Para o cálculo do estresse, [Shawky e Ali 2012] utilizaram o conceito de capacidade de computação, que é estimada pela quantidade total de dados processados em Gigabytes, enquanto que utilizamos apenas a quantidade de recursos manipulada. O foco de [Shawky e Ali 2012] para o cálculo da tensão foi em largura de banda, e nosso trabalho utilizou apenas o tempo. Um conjunto de métricas para elasticidade é proposto em [Herbst et al. 2013], com a ideia de velocidade e precisão. É um trabalho motivacional, não havendo experimentos, porém propõe uma métrica específica para elasticidade baseada em tempos de operações e recursos. As métricas Elasticidade de Scaling Up e Elasticidade de Scaling Down foram propostas, e levam em consideração a quantidade de recursos alocadas e o período de tempo dispendido durante períodos de subprovisionamento e sobreprovisionamento, e serão utilizadas nos experimentos como análise complementar. No trabalho de [Rego et al. 2013], uma solução foi apresentada para alocação dinâmica e autonômica de recursos em um ambiente de Computação em Nuvem. Este trabalho descreve estratégias, baseadas na criação de máquinas virtuais e alocação dinâmica de recursos, para atender os requisitos de qualidade e garantir a qualidade de serviço das aplicações em um ambiente híbrido de Computação em Nuvem. A solução aproveita a arquitetura FairCPU [Rego et al. 2011] para ajustar dinamicamente a quantidade de CPU conforme limites pré-estabelecidos pelo usuário. Além disso, experimentos foram conduzidos para comparar três estratégias de alocação de recursos. No trabalho proposto não serão utilizadas nuvens públicas ou híbridas. Em [Coutinho et al. 2013], o comportamento da elasticidade foi analisado em um ambiente de Computação em Nuvem, baseado em métricas relacionadas a tempo de resposta e recursos utilizados. Um conjunto de métricas foi apresentado e um experimento utilizando medição para a validação da proposta foi executado, concluindo-se que é possível avaliar a elasticidade baseado em tempos de alocação de recursos. As métricas definidas neste trabalho serão utilizadas como análise complementar nos experimentos. Novas ideias relacionadas ao teste de sistemas computacionais elásticos foram introduzidas por [Gambi et al. 2013], onde foram identificados alguns desafios de pesquisa e tendências futuras. Neste mesmo trabalho foi sugerida uma analogia com conceitos de elasticidade definidos na Física (Elasticidade de Materiais) com sistemas computacionais elásticos, tais como: deformação, recuperação, plasticidade e tensão. Também foi elabo- 57

72 rada uma analogia com testes mecânicos para a definição de testes adequados a sistemas computacionais. Porém neste trabalho não foram discutidas métricas, apenas a metáfora entre as áreas. Também não foram realizados experimentos. 3. Métricas para a Medição da Elasticidade em Computação em Nuvem O conceito de elasticidade é comum em áreas de atuação diferentes da Computação, tais como Física (Física de Materiais, Pneumática, Hidráulica), Biologia, Teoria do Controle e Microeconomia. Na Física, segundo [Timoshenko e Goodier 1970], todo material possui uma extensão da propriedade denominada elasticidade. Se forças externas aplicadas ao material produzirem uma deformação na estrutura, não excedendo um determinado limite, a deformação desaparece com a remoção das forças. A ideia deste trabalho é definir métricas para avaliação da elasticidade em nuvens computacionais baseadas em conceitos da Física. Para isso, as métricas estresse e tensão foram identificadas, e suas respectivas versões computacionais foram propostas. A Tabela 1 descreve as variáveis relacionadas às métricas propostas, assim como a nomenclatura a ser utilizada. As métricas associadas a recursos são valores coletados do ambiente, como utilização de CPU e quantidade de máquinas virtuais alocadas. A variável t corresponde ao número de iterações que são coletados os diferentes parâmetros utilizados, definido pelo intervalo de coleta. Variável R D R A t R D Atu R D Ant R A Atu R A Ant RD RA S QN T RD T RA E RDi E RAi E R Descrição Tabela 1. Lista de variáveis e nomenclatura Recursos Demandados: recursos necessários para o atendimento do SLA Recursos Alocados: recursos alocados ao ambiente Total de iterações (intervalos de coleta) Recursos Demandados Atuais: recursos demandados pelo ambiente no momento da coleta para atendimento do SLA Recursos Demandados Anteriores: recursos demandados pelo ambiente em momentos de coleta anteriores Recursos Alocados Atuais: recursos alocados ao ambiente no momento da coleta Recursos Alocados Anteriores: recursos alocados ao ambiente em momentos de coleta anteriores R D Atu R D Ant R A Atu R A Ant Estresse da Qualidade na Nuvem: taxa na qual os recursos são demandados em relação aos recursos alocados Tensão dos Recursos Demandados: taxa que mede a variação dos recursos demandados entre intervalos de coleta ( RD ) e os recursos demandados ao ambiente no momento da coleta Tensão dos Recursos Alocados: taxa que mede a variação dos recursos alocados entre intervalos de coleta ( RA ) e os recursos alocados ao ambiente no momento da coleta Elasticidade dos Recursos Demandados: relação entre S QN e T RD Elasticidade dos Recursos Alocados: relação entre S QN e T RA Elasticidade Média dos Recursos: média aritmética de todas as elasticidades calculadas em cada um dos intervalos de coleta t Na Física, o estresse mede o quão forte é um material. Ele é definido como a quantidade de pressão que o material pode suportar, sem sofrer algum tipo de alteração física [Timoshenko e Goodier 1970, Shawky e Ali 2012]. Considerando que o estresse na 58

73 Física é uma força que age sobre a área da secção transversal do material, fazendo a analogia com uma nuvem computacional, onde R D são os recursos demandados impostos pelas cargas de trabalho e R A são os recursos alocados na atual configuração da infraestrutra, temos que o Estresse da Qualidade da Nuvem (S QN ) pode ser medido pela Equação 1: S QN = { 0, se R A = 0 R D R A, caso contrário (1) Algumas situações específicas devem ser tratadas. No caso em que os recursos demandados e recursos alocados são zero, considera-se que o estresse é zero. No caso em que recursos demandados são diferentes de zero e os recursos alocados são iguais a zero, o estresse tende a infinito. Esta situação semanticamente significa que há uma demanda onde não há recursos alocados e nada que foi demandado será atendido, e para fim de interpretação, esta situação também implicará no estresse igual a zero. A tensão conforme a definição na Física é o quanto um objeto está sendo estendido ou distorcido [Timoshenko e Goodier 1970, Shawky e Ali 2012], e pode ser medida através da divisão entre a extensão de um material e seu comprimento após a distorção provocada pela aplicação de forças externas. Fazendo a analogia com a nuvem computacional, a Tensão dos Recursos Demandados (T RD ) pode ser medida pela Equação 2 e a Tensão dos Recursos Alocados (T RA ) pode ser medida pela Equação 3: T RD = { 0, se RD = 0 RD, caso contrário (2) R D Atu { 0, se RA = 0 T RA = RA, caso contrário (3) R A Atu Conforme a Lei de Hook, a elasticidade pode ser medida pela divisão entre o estresse e a tensão [Timoshenko e Goodier 1970, Shawky e Ali 2012]. A elasticidade dos recursos em um determinado ponto i pode ser calculada de duas maneiras diferentes, dependendo da fórmula de tensão utilizada (T RD ou T RA ). A Equação 4 considera os recursos alocados, enquanto que a Equação 5 considera os recursos demandados. E RDi = E RAi = { 0, se T RDi = 0 S QNi caso contrário T RDi, { 0, se T RAi = 0 S QNi T RAi, caso contrário (4) (5) Por fim, a elasticidade média dos recursos E R pode ser calculada tanto para os recursos alocados quanto para demandados por meio da Equação 6. E R = t i=0 E i t (6) 59

74 4. Experimentos Para a validação das métricas propostas, dois experimentos foram projetados. Diferentes métricas podem ser utilizadas para analisar o desempenho de um ambiente, dependendo do aspecto considerado. Essas métricas, geralmente associadas a recursos do ambiente, como percentual de utilização de CPU e memória, tempo de resposta ou throughput, influenciam diretamente no desempenho da aplicação. A carga de trabalho empregada também possui um papel importante nos resultados, e deve ser cuidadosamente projetada. Para o experimento, uma suposição considerada é que sempre haverá recursos alocados inicialmente e não há momentos sem recursos alocados. Em um ambiente computacional é plenamente possível que situações sem recursos alocados ou sem recursos disponíveis ocorram, como em uma situação inicial onde os recursos ainda não foram alocados, ou quando o ambiente está sendo inicializado, mas já existe demanda, ou ainda em uma situação ao longo do tempo em que os recursos por algum motivo estão indisponíveis, por exemplo, provocado por uma queda de energia, mas a demanda continua Infraestrutura Uma nuvem computacional privada foi construída sobre o OpenNebula 3.8. Todas as máquinas físicas envolvidas possuem processadores com 4 e 6 núcleos, 24 GB de memória RAM e sistema operacional Ubuntu Server Quatro máquinas virtuais foram utilizadas nos experimentos, todas com 1 VCPU, 1 GB de memória RAM e sistema operacional Ubuntu Server Para a geração de cargas de trabalho foi utilizada a ferramenta HTTPERF, que gerava uma quantidade de requisições, sob uma determinada taxa, para pequenas aplicações web (servlets) gerenciadas no container Apache Tomcat. Para a adaptação dos recursos às cargas de trabalho geradas, uma estratégia de elasticidade horizontal foi utilizada através de uma balanceador de carga, o NGINX. A Figura 1 descreve a infraestrutura projetada para o experimento. Figura 1. Infraestrutura dos experimentos 60

75 4.2. Projeto dos Experimentos Em ambos os experimentos, o objetivo é avaliar o desempenho da elasticidade (o quanto o sistema é elástico) do ambiente de Computação em Nuvem diante de uma carga de trabalho variada composta por aplicações web. Foi utilizado como estratégia de elasticidade balanceadores de carga (elasticidade horizontal), onde novos recursos são adicionados quando necessário ao balanceador de carga, e removidos quando a carga de trabalho diminui. A métrica utilizada para acionar ações de elasticidade foi o percentual de utilização de CPU de cada máquina virtual utilizada no experimento. Os limites utilizados como referência foram: acima de 90% (aloca uma nova máquina virtual), abaixo de 80% (desaloca uma máquina virtual), e entre 80% e 90% (mantém a infraestrutura atual). Esse valor foi obtido através do cálculo da média das 10 últimas amostras de utilização de CPU das máquinas virtuais, armazenadas em arquivos de log gerados a cada iteração. Para o cálculo da elasticidade, foi utilizado apenas a Tensão dos Recursos Alocados (T RA ), e consequentemente calculada a Elasticidade dos Recursos Alocados (E RAi ). A Tabela 2 descreve aspectos relacionados ao projeto de experimentos. Características Sistema Métricas Parâmetros Fatores Configuráveis Carga de Trabalho Análise Dados dos Tabela 2. Projeto de experimentos Descrição Ambiente privado de Computação em Nuvem (OpenNebula) Tempo de resposta das aplicações, percentual de utilização de CPU; TASo, TASu, TAE, TAT, TRASu, TRASo, TRAE [Coutinho et al. 2013], Elasticidade de Scaling UP e Elasticidade de Scaling Down [Herbst et al. 2013], S QN, T RA, E RAi, E R CPU, memória, sistema operacional, quantidade de máquinas virtuais Configuração do benchmark (repetições e tamanho da matriz), configuração do BLAST (tamanho do arquivo, tamanho da consulta), configuração do HTTPERF (quantidade de requisições, taxa de requisições, tempo) Experimento 1: Executar multiplicações de matrizes (dimensão 200x200x200) através de um microbenchmark construído na linguagem de programação Java, sob a forma de pequenas aplicações web, com requisições disparadas através do HTTPERF, com taxas variando de 1 a 5 requisições por segundo e quantidade de conexões variando em 10, 30 e 50; Experimento 2: Executar uma aplicação científica, o BLAST, através de um microbenchmark construído na linguagem de programação Java, sob a forma de pequenas aplicações web, com requisições disparadas através do HTTPERF, com taxas variando de 1 a 3 requisições por segundo e quantidade de conexões variando em 3, 6 e 9 Interpretação dos resultados descritos nos gráficos de média do percentual de CPU, gráficos de alocação das máquinas virtuais, e tabelas com métricas coletadas 4.3. Carga de Trabalho Destaca-se a geração de cargas de trabalho diretamente na máquina virtual do balanceador de carga, oriundas de navegadores web e do HTTPERF, que são distribuídas entre as demais máquinas virtuais, e também cargas de trabalho executadas diretamente nas máquinas virtuais utilizadas pelas aplicações. A ideia é emular a concorrência pelos recursos em diferentes maneiras de se utilizar um ambiente de Computação em Nuvem. A Tabela 2 detalha itens do projeto experimental, tais como métricas e cargas de trabalho. A Figura 2 ilustra a carga de trabalho empregada nos dois experimentos sobre a infraestrutura construída. 61

76 Figura 2. Projeto da carga de trabalho aplicada aos experimentos 4.4. Experimentos - Microbenchmark e Aplicação Científica A carga de trabalho para os dois experimentos foi descrita na Tabela 2. Os gráficos apresentados nas Figuras 3 e 4 descrevem o comportamento do experimento no tempo, conforme as requisições eram disparadas, através do consumo médio de CPU em todas as máquinas virtuais envolvidas no experimento, e suas respectivas alocações. Devido à característica do microbenchmark empregado no experimento 1, é de se esperar muitas variações no consumo de CPU. A carga de trabalho utilizada no experimento 2 foi projetada para executar uma aplicação científica, BLAST, com foco em CPU, memória e acesso a disco. O BLAST é uma ferramenta de similaridade muito utilizada para sequências de proteínas [NCBI 2013]. Quando os limites estabelecidos eram superados, novas máquinas virtuais eram alocadas. Os gráficos de utilização média de CPU e alocação de máquinas virtuais descrevem métricas diretamente relacionadas a eventos de elasticidade. Pode-se visualizar nos gráficos de consumo médio de CPU e alocação, descritos nas Figuras 3 e 4, que quando os limiares estabelecidos são superados, novas máquinas virtuais são adicionadas ao balancedor de carga, e quando a utilização de CPU é menor que o limite inferior, há então uma desalocação de máquinas virtuais Discussão dos Resultados Para uma melhor comparação dos resultados, os gráficos de utilização de CPU, alocação de máquinas virtuais, tensão, estresse e elasticidade estão dispostos na mesma imagem e na mesma escala, conforme as Figuras 3 e 4. O estresse respeita a carga de trabalho aplicada ao ambiente no sentido que variações na carga que impliquem em um consumo de CPU próximas ao SLA estabelecido influenciam no estresse. Há a tendência de aumentar seu valor se a carga de trabalho imposta aumentar. Momentos curtos de variação na carga de trabalho e no consumo de CPU não impactam tanto no estresse, implicando em um estresse menor e mais constante. O estresse para o contexto definido sempre será maior ou igual a 1 devido à suposição de sempre haver pelo menos uma máquina virtual alocada. A tensão também não é muito 62

77 Figura 3. Consumo médio de CPU, alocação de máquinas virtuais, Estresse da Qualidade na Nuvem (S QN ), Tensão dos Recursos Alocados (T RA ) e Elasticidade dos Recursos Alocados (E RAi ) para o experimento 1 influenciada pelas variações de carga de trabalho, pois mantêm os valores próximos uns dos outros, mas acompanha as variações. A elasticidade de recursos alocados para o experimento 1 possuiu 12 picos grandes de variação, indo da faixa de -5 a 5, variando em 10 unidades entre valores mínimos e máximos. Para o experimento 2, a variação foi menor, de -4 a 4, e possuindo apenas 8 picos, variando em 8 unidades entre valores mínimos e máximos. Esse comportamento se deve ao fato que a carga de trabalho do experimento 1 era composta por pequenas aplicações (menores e mais rápidas), porém maior em quantidade, enquanto que no experimento 2 as aplicações eram maiores e mais demoradas, e em quantidades menores. Essa variação entre os valores máximos e mínimos (10 e 8) indica que se utiliza muitos recursos ou a necessidade por mais recursos. Por fim, a elasticidade média dos recursos foi calculada, e teve como resultado 0.07 para o experimento 1 e 0.00 para o experimento 2. Esse valor 0.00 para o experimento 2 destacou-se, porém foi calculado da mesma maneira, reforçando que na média o experimento 1 é mais elástico que o experimento 2. Outros autores na literatura propuseram diferentes formas de se medir e avaliar a elasticidade. Para uma comparação e análise mais completa, algumas métricas foram coletadas sobre os experimentos e dispostas na Tabela 3. Utilizando as métricas propostas por [Herbst et al. 2013], concluiu-se que o expe- 63

78 Figura 4. Consumo médio de CPU, alocação de máquinas virtuais, Estresse da Qualidade na Nuvem (S QN ), Tensão dos Recursos Alocados (T RA ) e Elasticidade dos Recursos Alocados (E RAi ) para o experimento 2 rimento 1 é um pouco mais veloz que o experimento 2, obtendo 0.03 e 0.01 na elasticidade de Scaling Up respectivamente. Esse valor indica a velocidade na qual são alocados recursos de estados subprovisionados para estados ótimos (estados com alocação igual à demanda) ou sobreprovisionados. Na elasticidade de Scaling Down ocorre o mesmo comportamento em termos de velocidade (0.04 e 0.02), sendo o experimento 1 também mais veloz. Esse valor indica a velocidade na qual são desalocados recursos de estados sobreprovisionados para estados ótimos ou subprovisionados. Comparando com E R, cujos valores foram 0.07 e 0.00 respectivamente para os dois experimentos, reforça-se que o experimento 1 é mais elástico, em termos de utilização de CPU e operações com máquinas virtuais. Para outra avaliação da elasticidade, um conjunto de métricas proposto em [Coutinho et al. 2013] foi utilizado, divididas em dois grupos: tempo de execução de operações e utilização de recursos. As métricas relacionadas a tempo são: Tempo de Alocação Sobreprovisionado (TASo), correspondente ao tempo utilizado em operações 64

79 Tabela 3. Métricas coletadas para os experimentos 1 e 2 Métricas Experimento 1 Experimento 2 Tempo Total do Experimento (minutos) 12:58 19:00 Tempo de Alocação Estabilizada (TAE) 11:01 16:51 Tempo de Alocação Subprovisionada (TASu) 00:26 00:37 Tempo de Alocação Sobreprovisionada (TASo) 00:27 00:31 Tempo de Alocação Transitória (TAT) 01:03 00:59 Total de Recursos Alocados Estabilizado (TRAE) Total de Recursos Alocados Subprovisionados (TRASu) Total de Recursos Alocados Sobreprovisionados (TRASo) Elasticidade de Scaling UP 0,03 0,01 Elasticidade de Scaling DOWN 0,04 0,02 Elasticidade Média dos Recursos (E R ) 0,07 0,00 de remoção de recursos; Tempo de Alocação Subprovisionada (TASu), utilizado para medir o tempo de operações de adição de recursos; Tempo de Alocação Estabilizada (TAE), tempo no qual não há adição ou remoção de recursos; e Tempo de Alocação Transitória (TAT), correspondente ao tempo em que os efeitos da adição ou remoção de recursos ainda não impactaram no ambiente. As métricas relacionadas a recursos são: Total de Recursos Alocados Subprovisionados (TRASu), correspondente à quantidade de recursos alocados em um estado subprovisionado, mas não estabilizado; Total de Recursos Alocados Sobreprovisionados (TRASo), indicando a quantidade de recursos alocados em um estado sobreprovisionado, mas não estabilizado; e o Total de Recursos Alocados Estabilizados (TRAE), que corresponde à quantidade de recursos em um estado estabilizado. Em relação a TAT, os valores foram muito próximos nos dois experimentos, reforçando operações de elasticidade executadas com comportamento e duração semelhantes. Ambos experimentos possuíram TAE bem longos em relação às demais métricas, ocupando grande parte do tempo total dos experimentos. Esse momento de alocação estabilizada significa que, de certa forma, as alocações e desalocações estavam estabilizadas ou paradas em termos de operações de elasticidade. Percebeu-se que TASu e TASo para o experimento 2 foram maiores que o experimento 1. Porém a duração dos experimentos e a quantidade de mudanças nos estados influencia na análise. Não se pode afirmar com certeza que o experimento 2 foi pior que o experimento 1, ou menos elástico, pois em termos de duração foi aproximadamente 6 minutos mais longo. Porém, TASu e TASo tiveram valores próximos, o que pode implicar em capacidades elásticas próximas. TRAE, TRASu e TRASo, ao contrário da maioria das métricas de tempo, foram maiores para o experimento 1, implicando uma maior utilização de recursos durante ações de alocação e desalocação (máquinas virtuais). É de se esperar que quanto maior seu valor, maior seja TAT. Essas métricas analisam indiretamente a elasticidade do ambiente. Se analisarmos os gráficos de elasticidade das Figuras 3 e 4, verificamos que as variações coincidem com as alocações, consequentemente com os momentos onde são mais utilizados recursos, podendo ser empregados como análise complementar para a elasticidade. O experimento 1 teve em alguns pontos E RAi atingindo 5, e nesses momentos a alocação estava no máximo, necessitanto talvez de mais recursos, que o ambiente não possuía. O mesmo ocorreu para o experimento 2, mas com um pico menor, com E RAi igual a 4. O equivalente ocorreu para E RAi negativos, indicando desalocações. 65

80 5. Conclusão e Trabalhos Futuros Este trabalho propôs métricas para a medição da elasticidade em Computação em Nuvem baseadas em conceitos da Física (estresse e tensão). Dois experimentos foram executados para a avaliação das métricas e da elasticidade em uma nuvem computacional privada. A utilização das métricas propostas neste trabalho permitirá que outros pesquisadores possam aplicá-las em seus experimentos, possibilitando a comparação e refinamento de experimentos e soluções elásticas. A intenção de sua utilização é ser mais simples e mais fácil de se aplicar na avaliação da elasticidade de ambientes de nuvens computacionais. Como trabalhos futuros, pretende-se realizar experimentos em ambientes de Computação em Nuvem diversificados, com a utilização de nuvens públicas e híbridas, com diferentes provedores de acesso, benchmarks e cargas de trabalho. Também pretende-se desenvolver um mecanismo de escalonamento utilizando as métricas propostas. Por fim, para a validação de alguns trabalhos futuros, é interessante a utilização de simuladores para os experimentos, e avaliar a elasticidade em grande escala. Referências Coutinho, E., Gomes, D. G., e Souza, J. D. (2013). An analysis of elasticity in cloud computing environments based on allocation time and resources. In LATINCLOUD 2013, Maceió, Brazil. Gambi, A., Hummer, W., Truong, H.-L., e Dustdar, S. (2013). Testing elastic computing systems. Internet Computing, IEEE, 17(6): Herbst, N. R., Kounev, S., e Reussner, R. (2013). Elasticity in cloud computing: What it is, and what it is not. In Proceedings of the 10th International Conference on Autonomic Computing(ICAC 2013), San Jose, CA, pages USENIX. Islam, S., Lee, K., Fekete, A., e Liu, A. (2012). How a consumer can measure elasticity for cloud platforms. In Proceedings of the 3rd ACM/SPEC International Conference on Performance Engineering, ICPE 12, pages 85 96, New York, NY, USA. ACM. Mell, P. e Grance, T. (2009). The nist definition of cloud computing. National Institute of Standards and Technology, 53(6):50. NCBI (2013). Blast. National Center for Biotechnology Information (NCBI). Rego, P., Coutinho, E., Gomes, D., e De Souza, J. (2011). Faircpu: Architecture for allocation of virtual machines using processing features. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International Conference on, pages Rego, P., Coutinho, E., e Souza, J. D. (2013). Estratégias para alocação dinâmica de recursos em um ambiente híbrido de computação em nuvem. In XII Workshop em Clouds e Aplicações (WCGA2013). Shawky, D. M. e Ali, A. F. (2012). Defining a measure of cloud computing elasticity. In Systems and Computer Science (ICSCS), st International Conference on. Timoshenko, S. P. e Goodier, J. (1970). Theory of Elasticity. McGraw-Hill Education, 3rd edition. Zhang, Y., Huang, G., Liu, X., e Mei, H. (2010). Integrating resource consumption and allocation for infrastructure resources on-demand. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages

81 Gerenciamento de Elasticidade em Nuvens Privadas e Híbridas Rhodney Simões, Carlos Kamienski Universidade Federal de Alagoas (UFAL) rhodney.simoes@nti.ufal.br Universidade Federal do ABC (UFABC) cak@ufabc.edu.br Resumo. Computação em nuvem requer o gerenciamento da elasticidade para que recursos computacionais sejam alocados e liberados dinamicamente. Embora a adoção de serviços de nuvem esteja aumentando, o conhecimento disponível ainda não é suficiente para orientar o gerenciamento da elasticidade. Este artigo faz uma avaliação de elasticidade em nuvem privada e híbrida, usando o ambiente de laboratório, o PlanetLab e o serviço Amazon EC2. Os resultados mostram que a escolha de métricas e limiares é fundamental na manutenção da qualidade aliada ao controle de custos e que cloudburst pode ser usado para implementar uma nuvem híbrida mas a escolha do tipo de máquina virtual no provedor tem impacto significativo. Abstract. Cloud computing requires elasticity management for dynamically allocating and releasing computational resources. However, even though the adoption of cloud services has been growing, the available knowledge is not enough for guiding users when they need to manage elasticity. This paper analyzes elasticity in private and hybrid clouds, using a university lab, PlanetLab and Amazon EC2. Results show that the choice of metrics and thresholds plays a key role for keeping quality levels and controlling costs and that cloudburst can be effectively used for implementing a hybrid cloud but the choice of the type of virtual machine in the provider has a significant impact. 1. Introdução Computação em nuvem oferece a visão de computação como utilidade [Armbrust 2010], onde recursos computacionais são alocados e liberados dinamicamente e o usuário paga somente o que usar. Essa característica é provida através da elasticidade, que pode ser positiva, quando um novo recurso é criado para atender a um aumento de demanda, ou negativa, quando um recurso é liberado por estar ocioso. Computação em nuvem apresenta características únicas, além da elasticidade, como autosserviço sob demanda, amplo acesso via rede, recursos disponíveis e medição de uso de serviço [Mell & Grance, 2011]. Em geral as nuvens são classificadas em quatro categorias [Mell & Grance 2011]: públicas, privadas, híbridas e as comunitárias. 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 As nuvens híbridas surgem da composição de nuvens privadas e públicas, algo que geralmente ocorre quando uma empresa compra capacidade adicional num provedor de nuvem pública para atender picos de demanda na sua nuvem privada. Nuvens comunitárias são aquelas que permitem uso compartilhado

82 por usuários que colaboram para obter um ambiente computacional de maior capacidade. Este artigo faz uso das quatro categorias. Embora existam vários provedores de nuvem pública que oferecem serviços pela Internet e a adoção de nuvem privada seja crescente nas organizações, há pouca informação disponível para orientar o gerenciamento da elasticidade de um ponto de vista prático. A principal questão é como e quando criar novos recursos computacionais para atender a demanda e liberá-los quando não mais são necessários para que o usuário não pague mais do que necessita. É necessária a definição de métricas e configuração de limiares para tomada de ações de elasticidade. No caso de IaaS o próprio usuário deve administrar o uso dos seus recursos computacionais, como máquinas virtuais. Provedores de nuvens públicas oferecem serviços adicionais para controlar a elasticidade, mas não há informações detalhadas sobre essas ações, inclusive pela dependência que existe de aplicações específicas. Por exemplo, pode-se usar métricas de nível de sistema operacional que são gerenciadas diretamente pelo provedor como uso de CPU e memória, ou então capturar métricas de aplicação e usá-las no gerenciamento da elasticidade. Por outro lado, também existe pouca informação e compreensão do funcionamento de nuvens híbridas, onde nuvens privadas direcionam parte da sua demanda para nuvens públicas através de cloudburst [Kim, H. et. al. 2009]. Este artigo apresenta resultados de avaliação de desempenho de elasticidade em nuvem privada e híbrida, usando o PlanetLab 1 para geração de carga de trabalho dos clientes e o serviço Amazon EC2 2 de nuvem pública. Como cenário e motivação foi implementado um sistema que gerencia Smart Grid [Ipakchi, A., Albuyeh, F. 2009] na nuvem. Os resultados mostram que métricas e limiares devem ser cuidadosamente utilizados para obter o efeito desejado de manutenção da qualidade do serviço ao mesmo tempo que se controla os custos. Particularmente, descobrimos que as métricas de utilização de memória e CPU geram instabilidade na criação e liberação de máquinas virtuais e por isso passamos a usar uma métrica de aplicação, número de requisições, que gerou resultados estáveis. Os resultados evidenciam que a qualidade para o cliente e o custo são muito sensíveis aos limiares, ficando evidente que existem certos limites onde não vale a pena economizar ou gastar mais recursos computacionais. Além disso, a técnica de cloudburst pode ser usada para equalizar os recursos disponíveis com a demanda, mas a escolha do tipo de máquina virtual no provedor tem papel decisivo na obtenção de uma relação custo/benefício satisfatória. A principal contribuição desse artigo é apresentar resultados reais de experimentos executados em ambiente distribuído que podem efetivamente orientar administradores de ambientes de nuvem a melhor gerenciar os seus recursos. Na sequência do artigo, a seção 2 trata do gerenciamento da elasticidade e apresenta trabalhos relacionais. A seção 3 apresenta a metodologia de avaliação e a seção 4 apresenta os resultados. A seção 5 discute os principais resultados e finalmente a seção 6 apresenta conclusões e trabalhos futuros. 2. Gerenciamento de Elasticidade em Nuvem O conceito de elasticidade em nuvem [Mell & Grance, 2011] [Leymann 2009] emprega a liberdade do cliente de alocar e liberar recursos diante da sua necessidade, sem que

83 seja necessária a intervenção do provedor de serviço. Recursos de computação e de armazenamento são os que mais comumente podem ser alocados e liberados dinamicamente em um datacenter. Embora não seja uma condição essencial para caracterizar a computação em nuvem, já tornou-se padrão que os recursos de computação sejam oferecidos através de máquinas virtuais (VM). Provedores comerciais de nuvens públicas oferecem serviços de elasticidade, como é o caso da Amazon AWS 3, por meio do serviço CloudWatch 4. O CloudWatch tem como principal funcionalidade monitorar métricas como a utilização de CPU e memória e quantidade de requisições que são efetuadas para uma determinada máquina virtual. Diante dessas métricas o usuário pode configurar limiares para que uma nova VM seja criada ou liberada para atender demandas flutuantes. Infelizmente este recurso não é oferecido diretamente por controladores de nuvem privada como OpenNebula 5 e OpenStack 6 e o administrador de nuvem privada quiser usufruir de tal funcionalidade ele terá de implementá-lo. A utilização de nuvem híbrida pode fornecer um ambiente robusto o suficiente para suportar picos de demanda. Uma organização pode fazer um investimento em infraestrutura para suportar determinada demanda e tudo o que exceder a sua capacidade pode ser comprado da nuvem pública. A técnica de criar VMs em uma nuvem pública para atender a demandas que excedem a capacidade de uma nuvem privada é conhecida como cloudburst 7 [Kim, H. et. al. 2009]. Cloudburst permite a redução do custo com infraestrutura sem ter a redução da qualidade do serviço, pois somente serão criadas novas máquinas virtuais na nuvem pública quando os recursos existentes na nuvem privada já tiverem sido exauridos. Desta forma, não haverá o uso da nuvem pública a menos que seja realmente necessária a sua utilização. Existem trabalhos na literatura que tratam do gerenciamento da elasticidade, porém não com a abordagem desse artigo, que oferece informações úteis para configurar efetivamente os mecanismos de elasticidade. Muitos artigos apresentam resultados de simulação ou modelos matemáticos e outros focam em predição, mas não apresentam informações para auxiliar a configuração da elasticidade. Em [Morais et. al 2013] é apresentado um arcabouço para provisionamento automático de recursos em nuvem usando métricas que não dependem da aplicação (como CPU e memória) e são apresentados resultados de simulação. Neste artigo, com base em experimentos reais em ambiente distribuído, defendemos o uso de métricas de aplicação, por estarem mais próximas do usuário e portanto facilitarem a configuração efetiva dos níveis adequados para atender as demandas de SLA e fazer uso eficiente dos recursos. Em um ambiente real é possível perceber o comportamento efetivo de mecanismos que em um ambiente simulado podem ter um comportamento idealizado, devido às simplificações necessárias. CloudFlex (Seoung et al. 2011) é uma proposta para gerenciar os recursos na nuvem para atender demandas acima da capacidade instalada, mas que não se dedica a estudar especificamente os mecanismos de elasticidade. DEPAS (Calcavecchia et. al 2012) é um algoritmo decentralizado e probabilístico para elasticidade (chamado aqui de auto scaling) e que se integra um uma rede P2P. O artigo avalia o mecanismo por A tradução de cloudburst em português é aguaceiro. Dada a ausência de um termo adequado, usamos o original em inglês.

84 simulação e experimentação, mas os resultados não focam na escolha das métricas e dos limiares. Por último o trabalho apresentado em [Galante, G.; de Bona, L.C.E. 2012] categorizou a elasticidade em computação em nuvem. Este artigo foca na avaliação e no efeito dos limiares, baseados na métrica de número de requisições simultâneas, que apresenta maior confiabilidade para evitar a ação da elasticidade de forma desnecessária. 3. Metodologia de avaliação 3.1. Ferramenta O cenário de avaliação da elasticidade ocorre no contexto de Smart Grid, a rede elétrica inteligente, para o qual foi desenvolvido o Smart Grid Autonomic Management System (SGAMS). O SGAMS possui três módulos (geração, distribuição e clientes), responsáveis por tarefas distintas, mas que se completam para compor o ambiente de redes inteligentes de energia elétrica. O módulo de geração simula a quantidade de carga elétrica a ser produzida para a rede pelas concessionárias e pelos consumidores, sendo este último apenas para aqueles que possuem meios para gerar tal carga. O módulo de distribuição é responsável por alocar e liberar automaticamente as máquinas virtuais diante do aumento e redução do número de requisições dos consumidores Ambiente O módulo de geração foi implementado utilizando a infraestrutura da nuvem privada da universidade com a linguagem Java. O módulo de distribuição também foi implantado na infraestrutura de nuvem privada usando o controlador de nuvem OpenNebula, para prover os recursos autonômicos necessários para o módulo de distribuição, como: elasticidade integrada com balanceamento de carga e o monitoramento tanto das máquinas virtuais existentes quanto das aplicações sendo executadas nestas máquinas. Foram utilizados recursos do próprio sistema operacional (Linux Debian) para evitar que o Tomcat fique indisponível. Por último foi utilizado o PlanetLab como um exemplo similar a nuvem comunitária para o módulo cliente, onde cada máquina representa um conjunto de consumidores de energia. A avaliação de cloudburst em nuvem híbrida foi implementada usando o Amazon Elastic Compute Cloud (EC2), que oferece alguns padrões de instâncias (máquinas virtuais, na terminologia da Amazon) a serem alocadas para o cliente. Neste trabalho foram utilizadas três tipos de instâncias com capacidades de processamento crescente (small, medium e large), com o intuito de analisar o impacto dos diferentes tipos na realização de elasticidade Cenário Um dos principais objetivos do trabalho é identificar os melhores valores para os limiares positivos e negativos para alocar e liberar VMs para oferecer um tempo de resposta adequado para os clientes do módulo de distribuição. Foram executados experimentos preliminares com intuito de definir qual seria o tempo de resposta mínimo (TRm), além de determinar o número máximo de requisições simultâneas que uma VM

85 pode suportar antes que o tempo de resposta ultrapasse um limite máximo, que para a aplicação de Smart Grid foi definido como 10 segundos 8. Dois experimentos preliminares foram realizados. O primeiro teve como foco determinar o TRm e para isto foram alocados 100 clientes do PlanetLab um após o outro sem que houvesse mais que um cliente gerando requisições simultaneamente. Este experimento foi utilizado também para identificar quais clientes do PlanetLab apresentavam tempos de resposta inferiores a 10 segundo, porque alguns demonstravam possuir recursos de rede insuficientes para a realização dos experimentos, resultando assim em valores excessivamente altos (outliers). O segundo experimento teve como foco determinar a quantidade máxima de requisições que uma VM consegue atender antes do TR superar o limite de 10 segundos. Para isso 100 clientes do PlanetLab foram alocados a cada 10 segundos gerando requisições simultâneas. Para analisar o comportamento do tempo de resposta utilizando a técnica de cloudburst, foi usado o SGAMS com a arquitetura que emprega o uso da nuvem pública da Amazon quando os recursos da nuvem privada foram exauridos (Figura 1). Este experimento tem como objetivo estudar a viabilidade de uso de diferentes tipos de nuvem para compor um ambiente híbrido para atender as requisições existentes em Smart Grid. Nesta avaliação foram utilizados diferentes tipos de instâncias na Amazon a fim de identificar qual apresenta melhor custo benefício, tendo em vista que o uso de recursos da nuvem pública reflete no aumento do investimento na infraestrutura computacional para atender as requisições Métricas Figura 1 Arquitetura do SGAMS com cloudburst Para análise do comportamento dos tempos de resposta dos clientes que geram carga a partir do PlanetLab, foram definidas métricas a serem utilizadas. Tempo de resposta (TR): intervalo de tempo entre o cliente emitir uma requisição e receber a resposta do servidor. São calculadas três estatísticas (média, mediana e percentil 90) de todos os tempos de resposta a cada intervalo de 10 segundos. 8 Não existe bibliografia sobre o assunto e em se tratando de algo que ainda não existe definimos um limite de tempo (que poderia ser um valor ligeiramente diferente) para fins de avaliação do mecanismo de elasticidade.

86 Recursos computacionais: comprometimento de recursos computacionais pelo provedor de nuvem, medido através do número de máquinas virtuais alocadas para o usuário. Carga de trabalho: número de requisições simultâneas existente na VM controladora que realiza o balanceamento de carga. Nós do PlanetLab: número de nós do PlanetLab alocados para gerar a carga de trabalho, onde cada nós no PlanetLab é usado para modelar o comportamento de um determinado número de clientes do Smart Grid. Por exemplo, cada nó envia uma requisição ao servidor a cada 3 segundos. Se considerarmos um ambiente onde cada cliente envia uma requisição a cada 2 minutos, então temos uma relação de 1:40, ou seja, um nó PlanetLab representa 40 clientes. Utilização de CPU: média de utilização de CPU de todas as máquinas virtuais alocadas, calculada a cada 30 segundos. Utilização da memória: média de utilização de memória de todas as máquinas virtuais alocadas, calculada a cada 30 segundos. Tais métricas juntas viabilizam uma análise minuciosa do comportamento do TR no decorrer do experimento. O cálculo da média, mediana e percentil 90, proporciona a identificação de outliers, de modo a possibilitar a identificação de alguma instabilidade nos clientes alocados para a realização do experimento A partir da quantidade de clientes e a quantidade de requisições simultâneas existentes para a geração de carga é possível comprovar a necessidade ou não da realização da elasticidade. É importante notar que a elasticidade deveria ser idealmente realizada a partir de uma métrica de qualidade da experiência para o usuário, que nesse caso é o tempo de resposta. No entanto, em um ambiente real os valores das métricas dos usuários não necessariamente estão disponíveis para o provedor e nesse caso uma métrica disponível no provedor foi utilizada (requisições simultâneas), fazendo-se a comparação com os resultados do tempo de resposta para os clientes. A métrica usada para efetuar a elasticidade positiva (criar VM) e negativa (liberar VM) é o número de requisições simultâneas, que foi dividida pelo número de máquinas virtuais existentes para elasticidade, resultando no número de requisições por VM. Tal métrica foi escolhida diante da comparação com a utilização de CPU e memória em uma série de experimentos preliminares. A taxa de utilização de CPU mostrou-se uma métrica muito sensível a pequenas oscilações na quantidade de requisições. Por outro lado, a taxa de utilização de memória apresentou diversos problemas, como excessiva lentidão na liberação de memória pela aplicação, que causava uma falsa impressão de falta de memória. A principal questão que levou à escolha do número de requisições como métrica para a elasticidade é a facilidade de compreensão para o desenvolvedor da aplicação e administrador de sistemas. Uma vez que se conhece o número de requisições simultâneas que determinada VM pode tratar com a qualidade desejada para o usuário, a configuração dos limiares da elasticidade se torna mais simples e direta. 4. Resultados Os resultados apresentados nessa seção consideram que cada cliente realiza uma requisição seguindo uma distribuição Exponencial com média de 3 segundos. Foram efetuadas 10 replicações de cada experimento e intervalos de confiança com nível de 99% foram calculados, sendo que em vários casos são apresentadas séries temporais dos

87 valores das métricas usando uma replicação que representa a média das demais. Valores médios também são apresentados, juntamente com os intervalos de confiança. Para a avaliar a elasticidade sob diferentes condições foram utilizados 5 limiares para elasticidade positiva (250, 300, 350, 400 e 600) e 3 limiares para elasticidade negativa (100, 125 e 150). Nos gráficos das séries temporais apenas os resultados para os valores 350 e 150 são mostrados, devido a restrições de espaço. Esses resultados apresentam relação adequada com o tempo de resposta demonstrando um bom tradeoff para criação e liberação de máquinas virtuais. Além disso, o os limiares 150 e 350 apresentaram resultados semelhantes nos experimentos sem e com cloudburst. É importante notar que os valores atribuídos a limiares são específicos de cada aplicação. Cada experimento apresenta um tempo médio de aproximadamente 45 minutos, com 15 minutos adicionais para fazer o download dos logs em todos os nós do PlanetLab. Ao todo foram executas 230 horas de experimentos. Cem nós do PlanetLab foram alocados em cada experimento, mas para que isso fosse possível, centenas foram avaliados e vários nós tiveram que ser eliminados durante os experimentos devido a problemas internos Elasticidade sem Cloudburst Observando a Figura 2(a) que apresenta a média, mediana e o percentil 90 do tempo de resposta, podemos constatar que o resultado obtido neste experimento está abaixo do tempo máximo aceito de 10 segundos. Sendo assim podemos afirmar que para o ambiente analisado os limiares de 350 e 150 para elasticidade positiva e negativa, respectivamente, é satisfatório. 9 Média Mediana Percentil 90 6 Segundos 3 0 Número de requisições Minutos (a) Tempo de Resposta Minutos (b) Carga de trabalho Número de máquinas virtuais Número de nós Minutos (c) Recursos Computacionais (VMs) Minutos (d) Número de nós do PlanetLab Figura 2 Elasticidade com limiares 350 (positivo) e 150 (negativo) e sem cloudburst Analisando a métrica de número de VMs (Figura 2(c)), podemos observar que foram cridas menos de 12 máquinas virtuais para atender as quase requisições (Figura 2(b)) no ápice do experimento. Essas requisições são compatíveis com o número de nós

88 alocados no PlanetLab para representar os clientes (Figura 2(d)). A utilização de memória e CPU não apresentou resultados significativos e por esse motivo essas métricas não são apresentadas. Os valores das métricas de carga de trabalho e número de nós no PlanetLab também não serão mais apresentados porque os valores são semelhantes aos da Figura Elasticidade com Cloudburst Com o intuito de verificar a diferença entre utilizar ou não a técnica de cloudburst para suprir a necessidade de recursos computacionais oriundas dos picos de consumo, foram realizados experimentos variando o tipo de instância no serviço EC2 da Amazon. Desta forma foi possível identificar o impacto da utilização da nuvem da pública para a realização da elasticidade. Nos experimentos com instâncias do tipo small, como pode ser observado na Figura 3(a), fica evidente a instabilidade gerada nos tempos de resposta quando o cloudburst é iniciado. Tal comportamento permanece até o momento em que estas VMs da nuvem pública são liberadas. Sendo assim podemos afirmar que para a nossa aplicação realizar cloudburst com instâncias do tipo small não apresenta resultados satisfatórios, devido à instabilidade de desempenho no atendimento das requisições. Ao observamos Figura 3(b) e compararmos com a Figura 2(b) podemos afirmar que o número de máquinas virtuais criadas para elasticidade também não foi o motivo pela qual gerou a instabilidade. Desta forma é perceptível a razão pela qual ocorreu tal oscilação no tempo de resposta, ou seja, os recursos computacionais das instâncias small da Amazon não foram suficientes para suportar a carga gerada Segundos Média Mediana Percentil 90 Minutos Número de VMs Minutos Amazon WS Nuvem Privada (a) Tempo de Resposta (b) Recursos Computacionais (VMs) Figura 3 Experimento com limiares positivo e negativo 350, 150 respectivamente e com cloudburst utilizando instâncias do tipo small. Nos experimentos com instâncias do tipo medium foi possível observar uma notável diferença no comportamento dos tempos de resposta (Figura 4(a)) em comparação com a Figura 3(a). Fica evidente que o incremento de recursos computacionais para cloudburst reflete diretamente nos tempos de resposta para os clientes. Utilizando instâncias do tipo medium ao invés de small o custo com a infraestrutura de nuvem para disponibilizar os serviços dobra de valor, mas o resultado é visivelmente melhor. Durante todo o tempo de duração do experimento os tempos de respostas permaneceram estáveis e na média não ultrapassaram o tempo de 4 segundos independentemente da quantidade de requisições existentes (Figura 4(b)).

89 Ao observar a Figura 4(b) em comparação com Figura 3(b) fica evidente que a grande diferença entre os recursos computacionais de cada um dos tipos de instâncias influenciou no tempo de resposta. No experimento com instâncias do tipo small foram criadas três VMs na Amazon e mesmo assim houve grande oscilação na nuvem pública, enquanto que no experimento utilizando instâncias do tipo medium foram criadas apenas duas VMs e os tempos de resposta permaneceram dentro do limite estabelecido. 6 4 Segundos 2 0 Minutos Média Mediana Percentil Número de VMs Minutos Amazon AWS Nuvem Privada (a) Tempo de Resposta (b) Recursos Computacionais (VMs) Figura 4 Experimento com limiares positivo e negativo 350, 150 respectivamente e com cloudburst utilizando instâncias do tipo medium. Instâncias do tipo large possuem inerente vantagem em termos de desempenho, mas a para a aplicação avaliada não proporcionaram ganhos significativos. Ao observarmos a Figura 5(a) em relação à Figura 4(a) fica evidente que o ganho com desempenho dos tempos de resposta é pequeno, em torno de 0,047 segundos na média. Tal ganho não justifica dobrar o investimento em recursos computacionais de nuvem pública. Em outras palavras, algo que deve ser levado em consideração é a relação custo/benefício, que no caso significa o investimento em recursos computacionais em relação à diminuição e estabilidade dos tempos de resposta. Verificando o número de máquinas virtuais criadas para a elasticidade na Figura 5(b) é possível constatar que não houve oscilação em relação ao experimento com instâncias do tipo medium Segundos Média Mediana Percentil Número de VMs Amazon AWS Minutos (a) Tempo de Resposta Minutos (b) Recursos Computacionais (VMs) Figura 5 Experimento com limiares positivo e negativo 350, 150 respectivamente e com cloudburst utilizando instâncias do tipo large Os gráficos da Figura 6 mostram as médias das 10 replicações para todos os experimentos realizados, incluindo todos os limiares e com e sem cloudburst. A Figura 6(a) apresenta os tempos de respostas para vários limiares sem cloudburst. É possível ver que embora a variação entre os limiares positivos até 400 não é significativa. No entanto, para o liminar 600 houve um aumento considerável nos tempos de resposta, porque a criação de uma nova VM é postergada até um ponto onde a qualidade para o

90 usuário é afetada de maneira irreversível. Existe também variação de 50% no uso de recursos computacionais, de 8 a 12 VMs. Com o liminar positivo de 600 o custo é o menor possível, mas gerando perda de desempenho. Como pode ser observado na Figura 6(c) comparando o comportamento do tempo de resposta na nuvem privada da UFABC com o da nuvem pública da Amazon, os resultados utilizando máquinas virtuais mais robustas são similares aos de sem cloudburst. No entanto, ao usar a infraestrutura da Amazon houve oscilação nos TRs refletindo no aumento do intervalo de confiança. Contudo as VMs com maior poder computacional demonstram ser mais estáveis que as demais. Na Figura 6(d) podemos constatar que mesmo sem utilizar a técnica de cloudburst o número de máquinas virtuais criadas para os experimentos com limiar positivo de 350 requisições simultâneas é próximo com os resultados usando a nuvem pública da Amazon. Segundos Número de VMs a) Tempo de resposta (vários limiares, sem cloudburst) b) VMs (vários limiares, sem cloudburst) Segundos Número de VMs c) Tempo de resposta (com e sem cloudburst) d) VMs (com e sem cloudburst) Figura 6 Média do tempo de resposta e número de máquinas virtuais (sem e com cloudburst) 4.3. Custo vs. Benefício Com intuito de identificar relações de custo/benefício adequadas entre os diversos limiares utilizados nos experimentos, foi criada uma métrica que multiplica a média do número de máquinas virtuais de cada experimento pela média do tempo de resposta do mesmo experimento. Essa métrica não apresenta valores com significado específico, mas um valor que representa o custo/benefício dos diferentes experimentos realizados. Quanto menor o valor da métrica, mais adequada é a configuração usada. Embora em teoria seria possível um valor muito alto para custo em troca de um valor muito baixo para o benefício fica claro que os tempos de resposta tem tempos mínimos que não podem ser diminuídos mesmo com grandes investimentos.

91 A Figura 7(a) apresenta os resultados da métrica custo/benefício para os vários experimentos sem cloudburst. No geral, pequenas variações para baixo ou para cima no número de VMs (custo) são compensadas por variações na direção contrária do tempo de resposta (benefício). A exceção é o liminar positivo 600, mostrando que economizar a partir de um determinado ponto cobra um alto preço na redução da qualidade. Nos experimentos com cloudburst mostrados na Figura 7(b) em comparação a sem cloudburst com limiares 350 e 150, pode-se observar que o uso da nuvem híbrida é adequada para instâncias do tipo medium, mas não para instâncias small. No caso de instâncias large, embora o valor da métrica seja adequado, ela não computa o custo de aluguel cobrado pelo provedor. Isso torna as instâncias large inadequadas para o ambiente avaliado. Relação custo/benefício Relação custo/benefício a) Custo/benefício sem cloudburst e vários limiares b) Custo/benefício com e sem cloudburst 5. Discussão Figura 7 Relação custo/benefício Nesse artigo alguns pontos a respeito da elasticidade foram discutidos e chegou-se a quatro pontos fundamentais: escolha da métrica, escolha dos limiares, viabilidade de uso de cloudburst e escolha da instância no provedor de nuvem pública. Embora provedores nuvem pública ofereçam serviços com elasticidade e métricas para o seu gerenciamento, não há conhecimento gerado e informações disponíveis sobre como escolher métricas e configurar limiares. Estes aspectos desempenham um papel importante no desempenho e no custo da computação em nuvem. O serviço CloudWatch da Amazon oferece utilização de memória e CPU como métricas principais mas também oferece a possibilidade de capturar métricas de aplicação. Seguindo essa linha, este trabalho foi iniciado fazendo elasticidade com memória e com CPU, mas os resultados foram muito insatisfatórios porque muito instabilidade era gerada. Uma métrica de aplicação, o número de requisições, apresenta resultados positivos e com boa relação com tempo de resposta (métrica relevante para o usuário). Após a escolha da métrica, devem ser escolhidos valores de limiares positivos e negativos para aumentar ou diminuir os recursos alocados. Os resultados evidenciam que a qualidade para o cliente e o custo são muito sensíveis aos limiares. Fica evidente que economizar utilizando limiares positivos e negativos altos esbarram num limite onde passa a não mais valer a pena. A análise da métrica de busto/benefício mostra claramente essa questão. A avaliação da técnica de cloudburst mostra que é possível utilizá-la como complemento para recursos da rede privada, que pode não possuir níveis médios de ociosidade de recursos compatíveis com as demandas de todos os seus usuários. Quando

92 se utiliza cloudburst, a escolha do tipo da instância na nuvem pública tem grande impacto na manutenção da qualidade e redução de custos. Por exemplo, a avaliação mostrou que o uso de instâncias small da Amazon prejudica muito o desempenho da aplicação avaliada. Por outro lado, instâncias large agregam pouco ao desempenho das instâncias médium mas com um custo significativamente maior. Ressalta-se que essa relação de desempenho de instâncias small, medium e large pode ser diferente para aplicações com características diferentes. 6. Conclusão O gerenciamento correto da elasticidade é fundamental para que usuários obtenham o benefício da computação como utilidade num ambiente de nuvem. Pela pouca discussão que existe na literatura, fica claro que os usuários não tem informações precisas para lhes orientar na configuração de métricas e limiares para criar novos recursos para atender a demanda e liberá-los quando não mais são necessários. Os resultados mostram que a escolha de métricas e limiares é fundamental na manutenção da qualidade aliada ao controle de custos. Foi usada uma métrica de aplicação, o número de requisições, que trouxe estabilidade no gerenciamento da elasticidade. Ficou claro também que o uso de limiares muito altos ou baixos distorce a relação custo/benefício. Além disso, cloudburst pode ser usado para implementar uma nuvem híbrida mas a escolha do tipo de máquina virtual tem impacto significativo. Como trabalhos futuros, serão realizados novos experimentos com padrões diferentes de envio de requisições pelos clientes. Serão também realizados estudos sobre o uso de técnicas estatísticas ou histerese para gerenciar o momento da realização da elasticidade positiva ou negativa. Referências Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, M., (2010). A View of Cloud Computing, Communications of the ACM, 53(4), p , Abril de Calcavecchia, N., Caprarescu, B., Di Nitto, E., Dubois, D., and Petcu, D. (2012). DEPAS: a decentralized probabilistic algorithm for auto-scaling. Computing, 94: Galante, G.; de Bona, L.C.E., (2012). "A Survey on Cloud Computing Elasticity," Utility and Cloud Computing (UCC), 2012 IEEE Fifth International Conference on, vol., no., pp.263,270, 5-8 Novembro de Ipakchi, A., Albuyeh, F. (2009), Grid of the Future: Are We Ready to Transition to a Smart Grid?, IEEE Power & Energy Magazine, 7(2), p , Março Leymann, F. (2009). Cloud Computing: The Next Revolution in IT, in Proc. 52th Photogrammetric Week. W. Verlag,, pp Setembro de Morais, F. et. al (2013). Um Arcabouço para Provisionamento Automático de Recursos em Provedores de IaaS Independente do Tipo de Aplicação, SBRC 2013, Maio. Mell, P. and Grance, T. (2011). The NIST Definition of Cloud Computing, US Nat l Inst. of Science and Technology, Seung, Y., Lam, T., Li, L. E., Woo, T. (2011). Cloudflex: Seamless scaling of enterprise applications into the cloud. INFOCOM, páginas

93 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XII Workshop de Computação em Clouds e Aplicações (WCGA) Sessão Técnica 3 Arquitetura e Gerência

94

95 Alocação de Máquinas Virtuais em Ambientes de Computação em Nuvem Considerando o Compartilhamento de Memória Fernando José Muchalski 1, Carlos Alberto Maziero 1 1 Universidade Tecnológica Federal do Paraná (UTFPR) Curitiba PR Brazil muchalski@gmail.com, maziero@utfpr.edu.br Resumo. Nos ambientes de computação em nuvem, é importante manter sob controle a alocação de máquinas virtuais nos servidores físicos. Uma alocação adequada implica na redução de custos com hardware, energia e refrigeração, além da melhora da qualidade de serviço. Hipervisores recentes implementam mecanismos para reduzir o consumo de memória RAM através do compartilhamento de páginas idênticas entre máquinas virtuais. Este artigo apresenta um novo algoritmo de alocação de máquinas virtuais que busca o equilíbrio no uso dos recursos de CPU, memória, disco e rede e, sobretudo, considera o potencial de compartilhamento de memória entre máquinas virtuais. Através de simulações em três cenários distintos, verificou-se que o algoritmo é superior à abordagem padrão na questão do uso equilibrado de recursos e que, considerando o compartilhamento de memória, houve um ganho significativo na disponibilidade deste recurso ao final das alocações. Abstract. In cloud computing environments it is important to keep under control the allocation of virtual machines in physical servers. A good allocation brings benefits such as reduction costs in hardware, power, and cooling, also improving the quality of service. Recent hypervisors implement mechanisms to reduce RAM consumption by sharing identical pages between virtual machines. This paper presents a new algorithm for virtual machines allocation that seeks the balanced use of CPU, memory, disk, and network. In addition, it considers the potential for sharing memory among virtual machines. Simulations on three distinct scenarios demonstrate that it is superior to the standard approach when considering the balanced use of resources. Considering shared memory, there was an appreciable gain in availability of resources. 1. Introdução A tecnologia de virtualização emergiu como uma das tecnologias-chave para a computação em nuvem, pois permite a um datacenter servir múltiplos usuários de forma segura, flexível e eficiente, principalmente devido à sua capacidade de isolamento, consolidação e migração de cargas de trabalho na forma de máquinas virtuais (VMs). Essas características possibilitam a criação de políticas para o gerenciamento da infraestrutura computacional, visando garantir a qualidade de serviço (QoS) e economia de recursos através do melhor uso da capacidade computacional disponível. A alocação de máquinas virtuais (VMs) consiste em escolher o servidor físico (host) onde alocar cada VM, buscando otimizar alguma métrica como balanceamento 81

96 de carga, consumo de energia, etc. Para tal, deve-se conhecer a demanda de recursos de cada VM, o ambiente de execução e as políticas específicas do datacenter para possíveis conflitos [Hyser et al. 2007]. De modo geral, a alocação de uma VM é dividida em duas etapas: inicialmente é estimada a demanda de recursos da máquina virtual; em seguida, escolhe-se o servidor onde essa máquina virtual será alocada [Mishra and Sahoo 2011]. A demanda de recursos de uma VM pode ser difícil de estimar, pois as necessidades de recursos podem variar durante sua execução. Uma abordagem comum é de realizar a estimativa com base no histórico de utilização de recursos da VM. Este artigo considera que as necessidades de recursos de uma VM são previamente conhecidas. A alocação em si usa uma estratégia para definir onde alocar a VM de modo a alcançar um nível eficiente de utilização de recursos de um servidor físico. Tal estratégia pode utilizar representações matemáticas ou métricas que representam o grau de utilização dos recursos pelas diversas VMs e servidores físicos. Essas métricas devem levar em consideração as várias dimensões de consumo de recursos, como as capacidades de processador, memória, disco e banda de rede [Hyser et al. 2007], bem como recursos não envolvidos diretamente com as necessidades da máquina virtual, mas que afetam o datacenter, como o consumo de energia decorrente da alocação [Buyya et al. 2010]. Nesse artigo é apresentado um algoritmo para alocação de máquinas virtuais, onde são avaliados os recursos de CPU, memória, disco e banda de rede, que busca equilibrar o uso dos recursos nos servidores físicos. Como diferencial, o algoritmo proposto faz uso da capacidade de compartilhamento de páginas de memória presente em alguns hipervisores [Wood et al. 2009, Barker et al. 2012], buscando explorar o potencial de compartilhamento de memória que uma VM terá quando alocada em determinado servidor. As seções 2 e 3 apresentam os fundamentos necessários à compreensão deste trabalho, a seção 4 apresenta o algoritmo de alocação e suas característica de funcionamento, a seção 5 apresenta o ambiente de simulação utilizado, os cenários testados e os resultados atingidos, e por fim a seção 6 apresenta as considerações finais do trabalho. 2. Máquinas virtuais A virtualização, técnica surgida na década de 60 no IBM S/370 [Creasy 1981], permite dividir os recursos computacionais de um computador físico em partições autônomas e isoladas chamadas máquinas virtuais (VM). Uma máquina virtual funciona como uma cópia exata de uma máquina real, incluindo seus recursos de hardware. A virtualização é construída através de um hipervisor, uma camada de software de baixo nível que provê o suporte de execução necessário às máquinas virtuais. O hipervisor abstrai parcialmente os recursos de hardware subjacentes, tornando possível a execução simultânea de várias máquinas virtuais autônomas e isoladas sobre um mesmo computador. Uma das principais funcionalidades do hipervisor consiste em abstrair os recursos da máquina real e oferecê-los às máquinas virtuais. Assim, cada máquina virtual enxerga sua própria interface de rede, seus discos rígidos, seus processadores e suas áreas de memória RAM. Esses recursos virtuais usados pelas máquinas virtuais são mapeados pelo hipervisor nos recursos reais presentes no hardware subjacente, de forma eficiente e controlada. Pode-se afirmar que o hipervisor constitui um sistema operacional para sistemas operacionais, pela flexibilidade que introduz na gestão dos recursos de hardware. A possibilidade de instanciar máquinas virtuais sob demanda e a relativa independência 82

97 do hardware são essenciais para os ambientes de computação em nuvem. A abstração de recursos construída pelo hipervisor abre a possibilidade de transferir uma máquina virtual em execução de um servidor físico para outro, mantendo seu estado interno. Esse procedimento, denominado migração de máquinas virtuais, deu muita flexibilidade à gerência de datacenters [Grit et al. 2006]. Migrar máquinas virtuais entre servidores físicos permite balancear a carga de trabalho entre eles ou mesmo concentrar as VMs em poucos servidores, hibernando os restantes e assim diminuindo o consumo de energia, de refrigeração e o ruído no ambiente [Buyya et al. 2010, Lago et al. 2011]. Recentemente, alguns hipervisores têm explorado a possibilidade de reduzir o consumo de memória RAM pelas máquinas virtuais através do compartilhamento de páginas de memória idênticas, como CBPS - Content-Based Page Sharing, disponível em hipervisores como VMWare ESX, Xen, e KSM - Kernel Samepage Merging, disponível no KVM [Barker et al. 2012]. Nessas técnicas, o hipervisor identifica páginas de memória com conteúdo idêntico e as compartilha usando a estratégia copy-on-write, de forma transparente para as máquinas virtuais: caso uma das máquinas virtuais tente alterar o conteúdo de uma página compartilhada, o compartilhamento é desfeito pelo hipervisor e uma cópia da página é alocada à máquina virtual solicitante. Essencialmente, existem duas categorias de compartilhamento: o auto-compartilhamento, quando as páginas duplicadas estão dentro da própria VM e o compartilhamento inter-vm, que ocorre entre máquinas virtuais distintas [Sindelar et al. 2011]. O compartilhamento de memória entre máquinas virtuais permite diminuir o consumo de memória RAM do servidor host, influenciando positivamente no desempenho do sistema. 3. Alocação de máquinas virtuais Considerando um conjunto de servidores físicos em um datacenter, a alocação de VMs consiste em, dada uma VM, encontrar um servidor que seja adequado para instanciá-la. O servidor deve possuir recursos suficientes para garantir a execução da VM sem afetar os acordos de nível de serviço. Esse problema representa um desafio algorítmico por sua característica combinatória, onde um conjunto de n máquinas virtuais com requisitos distintos de processamento, memória e outros recursos deve ser alocado em m servidores com diferentes disponibilidades de recursos. De forma geral, o problema de alocação de VMs pode ser visto como uma generalização do problema de múltiplas mochilas (multiple knapsack problem - MKP), onde cada mochila representa um servidor físico, sua capacidade corresponde aos recursos disponíveis no servidor e os itens são as VMs a serem alocadas. Cada VM tem um peso, representado pela quantidade de recursos necessários e um preço, que pode significar o custo que essa alocação representará no ambiente. Esse custo pode ser computacional, energético ou monetário. O objetivo é encontrar a melhor alocação das VMs em cada servidor, de modo a minimizar o custo [Grit et al. 2006]. Os algoritmos de alocação de VMs também podem se apresentar como variações do problema Bin Packing: dado um conjunto de n itens, onde cada item possui um peso w associado, e um conjunto de m recipientes (bins), cada um com uma capacidade c, encontrar o número mínimo de recipientes necessários para armazenar os itens tal que a soma dos itens em cada recipiente não ultrapasse sua capacidade. Comparando-se com o problema de alocação de VMs, tem-se os recipientes como sendo os servidores físicos, sua capacidade como os recursos 83

98 disponíveis no servidor e os itens seriam as VMs a alocar. Na literatura há vários trabalhos relacionados à alocação de recursos virtuais em servidores físicos. Por se tratar de um problema combinacional do tipo NP-difícil, o assunto desperta o interesse de pesquisadores em busca de estratégias algorítmicas eficientes para solução desse tipo de problema [Singh et al. 2008]. O artigo [Grit et al. 2006] propôs estratégias para a chamada orquestração autônoma, onde o datacenter se auto-gerencia, independente de interferência humana. Nesse trabalho, os autores estabeleceram que a estratégia para alocação de máquinas virtuais pode estar presente nos processos de provisionamento de VMs, colocação de VMs nos servidores físicos e migração de VMs entre os servidores para consolidação e balanceamento de carga. Para [Hyser et al. 2007] uma boa colocação inicial não é suficiente, já que as cargas de trabalho das máquinas virtuais mudam com o passar do tempo. Consideram então ser necessário alterar dinamicamente a localização das máquinas virtuais de acordo com as condições do datacenter. Seu algoritmo considera os recursos de memória, processador, banda de rede e banda de disco disk bandwidth para estabelecer as máquinas virtuais que deverão ser migradas e realocadas para estabilizar o ambiente. Em outro trabalho, [Yen Van et al. 2009] criaram um módulo de decisão global para garantir a eficiência do sistema em termos de qualidade de serviço e gerenciamento dos custos dos recursos, desacoplando os processos de provisionamento e de alocação de VMs. Seus algoritmos levam em consideração as capacidades de recursos de processamento e de memória. Dentro do contexto da computação em nuvem verde [Buyya et al. 2010] tratou do problema de alocação de máquinas virtuais objetivando o uso eficiente de recursos, de modo que a dimensão analisada como critério para alocação se baseia na análise do potencial consumo de energia do servidor físico após a alocação. O trabalho de [Chen et al. 2011] trata especificamente da consolidação de servidores, onde se objetiva liberar os servidores físicos que estejam subutilizados, migrando as máquinas virtuais e estabelecendo uma nova alocação. Sua abordagem, chamada effective sizing consiste em determinar as novas alocações através do menor número possível de migrações. O trabalho [Wood et al. 2009] foi o primeiro a abordar o mecanismo de compartilhamento de páginas de memória entre máquinas virtuais, existente em alguns hipervisores, para estabelecer uma estratégia para alocação de máquinas virtuais. Sua solução baseia-se no cálculo de uma impressão digital para cada máquina virtual do sistema e através da comparação com a impressão digital gerada para a nova máquina virtual é estabelecido uma probabilidade de compartilhamento de páginas de memórias entre elas. O compartilhamento de páginas de memórias também é abordado no trabalho de [Sindelar et al. 2011], mas sua proposta baseia-se em dois modelos, que buscam estabelecer as maiores probabilidades de compartilhamento de memória de acordo com as características das máquinas virtuais. Essa nova abordagem torna mais eficiente o processo de alocação, tendo em vista que não são necessários o cálculo contínuo das impressões digitais de todas as VMs do sistema. No entanto, tais algoritmos consideram apenas a probabilidade de compartilhamento como fator de decisão para alocação, ignorando os demais recursos como processamento, memória, disco e banda de rede. 84

99 4. O Algoritmo VectorAlloc Este trabalho propõe um algoritmo para a alocação online de máquinas virtuais nos servidores de um datacenter, considerando as demandas de recursos das máquinas virtuais, os recursos disponíveis nos servidores e o compartilhamento de memória entre as máquinas virtuais alocadas em um mesmo servidor. Nosso algoritmo, denominado VectorAlloc, foi inspirado no VectorDot [Singh et al. 2008], um algoritmo de balanceamento de carga (VMs) que busca minimizar o grau de desequilíbrio de carga dos servidores físicos, levando em conta os vários tipos de recursos em uma representação vetorial. No algoritmo VectorDot, os servidores que estão acima de um certo limite de carga são considerados em desequilíbrio ; calcula-se então o IBScore (Imbalance Score) de cada servidor e um IBScoreTotal, para determinar o nível de desequilíbrio global do sistema. O algoritmo então busca outros servidores para alocar as máquinas virtuais dos servidores sobrecarregados. O produto escalar entre a carga do servidor e as necessidades da máquina virtual determina a atratividade de um servidor. Além disso os vetores são ajustados para refletir os custos de migração das VMs. Nosso algoritmo também expressa a utilização de recursos de cada servidor e as demandas das VMs como vetores, nos quais cada elemento corresponde a um tipo de recurso (memória, CPU, disco e rede) e seu valor corresponde ao grau de utilização do recurso em relação à sua capacidade total. Contudo, enquanto o VectorDot visa o balanceamento de carga, nosso algoritmo trata de alocações online, ou seja, sem um préconhecimento do conjunto de máquinas virtuais; a alocação ocorre à medida em que estas chegam. Além disso, nosso algoritmo considera a possibilidade de compartilhamento de memória entre máquinas virtuais. O algoritmo VectorAlloc usa quatro vetores: Resource Utilization Vector RUV(u), grau de utilização dos recursos de um servidor físico u; Resource Requirement Vector RRV(u, v), recursos requeridos por uma VM v em relação a um servidor físico u; Resource Threshold Vectors RT Vmin e RT Vmax, definem os limites mínimos e máximos de uso de cada um dos recursos em um servidor, em percentagem (notação adaptada de [Mishra and Sahoo 2011]). Esses vetores são expressos por: [ MemUse(u) MemS hared(u) RUV(u) =, CPUUse(u) MemCap(u) CPUCap(u), DiskUse(u) DiskCap(u), NetUse(u) ] NetCap(u) [ RRV(u, v) = (1 α(v, u)) MemReq(v) MemCap(u), CPUReq(v) CPUCap(u), DiskReq(v) DiskCap(u), NetReq(v) ] NetCap(u) RT Vmin = [MemT min, CPUT min, DiskT min, NetT min] RT Vmax = [MemT max, CPUT max, DiskT max, NetT max] Cada elemento do vetor representa um tipo de recurso e possui um valor real no intervalo [0, 1]. Pela ordem, os recursos analisados são: memória, CPU, disco e rede. O elemento memória tem um tratamento diferenciado dos demais, pois deve considerar o compartilhamento de páginas entre máquinas virtuais. RUV(u) é calculado realizando-se o quociente entre os valores do recurso já alocado pela capacidade total do recurso. O elemento memória considera a quantidade de memória compartilhada entre as VMs. Por exemplo, um servidor físico que hospede duas máquinas virtuais vm 1 e vm 2, onde vm 1 demanda 100 MB de memória e vm 2 demanda

100 MB, utilizaria 300 MB de memória. Todavia, se 50 MB de memória estiverem compartilhados entre vm 1 e vm 2, o total de memória realmente utilizada será de 250 MB. O vetor RRV(u, v) representa a razão entre a demanda de recursos de uma VM v e os recursos disponíveis em um servidor físico u. O cálculo do recurso memória usa um fator de compartilhamento α(v, u). Este fator representa o potencial de compartilhamento de memória que uma VM v possui em relação ao servidor u. Por exemplo, uma VM que tenha um fator de compartilhamento de 20%, precisará alocar somente 80% de sua demanda de memória. O cálculo de α será discutido na próxima seção. Os vetores RTVmin e RTVmax indicam os limites mínimos e máximos de uso dos recursos em cada servidor. Seu objetivo é garantir que a alocação de uma nova VM não desequilibre o uso de recursos, sobrecarregando ou subutilizando algum servidor. Assim, uma VM v só poderá ser alocada no servidor u se o uso de seus recursos se mantiver entre os limites inferior e superior, ou seja, se RT Vmin RUV(u) + RRV(u, v) RT Vmax. Considerando o conjunto de servidores U do datacenter e uma máquina virtual v a ser alocada em um servidor u U, determina-se o conjunto D(v, γ, δ) de servidores disponíveis para alocar v como: D(v, γ, δ) = {u U γ RUV(u) + RRV(u, v) δ} Com γ = RTVmin e δ = RTVmax, D(v, γ, δ) contém os servidores de U onde a alocação de v respeita os limites RTVmin e RTVmax. Caso D(v, γ, δ) =, calculase D(v, 0, δ); caso este seja vazio, calcula-se D(v, 0, 1); caso este também seja vazio, a alocação não é possível. Do conjunto D(v) escolhe-se um servidor u a que satisfaça: u a = arg min u D(v) (RUV(u) RRV(u, v)) Em outras palavras, a máquina virtual v será alocada no servidor u a D(v) com o menor produto escalar entre RUV(u) e RRV(u, v), buscando respeitar os limites de alocação. A ideia subjacente é alocar a VM em um servidor para o qual RRV seja complementar a RUV, resultando em um produto escalar mínimo, o que induz um uso balanceado dos recursos. Por exemplo, uma VM com baixa demanda de CPU e alta demanda de memória será alocada em um servidor com alto uso de CPU mas baixo uso de memória O Fator de Compartilhamento α(v, u) O fator de compartilhamento α(v, u) é usado pelo algoritmo proposto para estabelecer o potencial de compartilhamento de memória que uma VM v possui em relação a um servidor u. É um valor que varia entre 0 e 1, sendo 0 quando não há nenhuma chance de v compartilhar memória com as demais VMs presentes em u, e 1 caso toda a memória de v possa ser compartilhada. O valor de α corresponde a uma estimativa, já que a memória efetivamente compartilhada só poderá ser determinada após a alocação da VM. Este trabalho não se aprofunda no cálculo preciso de α, pois foge do seu escopo. Aqui, inclusive, abre-se uma possibilidade de pesquisa para o estabelecimento de métodos para o cálculo de α, que poderiam fazer uso do histórico de alocações para determinar índices mais próximos da realidade. Alguns trabalhos como [Wood et al. 2009] e [Sindelar et al. 2011] apresentaram formas de 86

101 Figura 1. Modelo hierárquico em árvore [Sindelar et al. 2011] capturar a memória compartilhada entre as máquinas virtuais e utilizaram tal informação para criação de algoritmos de alocação, otimização e balanceamento de carga. Neste trabalho, o fator de compartilhamento é calculado usando uma representação hierárquica de máquinas virtuais, similar à apresentada em [Sindelar et al. 2011]. Cada servidor referencia as máquinas virtuais nele alocadas usando uma árvore similar à apresentada na Figura 1. Nessa árvore, cada nível representa um novo grau de especialização das informações das VMs. Partindo da raiz, o próximo nível representa o sistema operacional (SO), em seguida vem a versão do SO e então a arquitetura do SO (32 ou 64 bits). As folhas da árvore representam as máquinas virtuais alocadas no servidor. [Sindelar et al. 2011] utiliza essa árvore para capturar as páginas de memória das VMs alocadas. Em seu modelo, a raiz da árvore contém todas as páginas de memória compartilhadas entre as VMs, os nós no nível do SO contêm as páginas compartilhadas pelo mesmo SO e o mesmo ocorre nos nós para a versão do SO e para a arquitetura do SO. As folhas contêm as páginas de memória que não são compartilhadas, ou seja, são exclusivas de cada VM. Nosso trabalho adotou uma interpretação diversa: cada nível indica o potencial de compartilhamento para uma dada VM. Conforme aumenta o grau de similaridade entre as VMs, também aumenta a probabilidade dessas VMs compartilharem páginas de memória comuns entre si. Dessa forma, ao realizar-se uma busca na árvore por VMs semelhantes a uma dada VM, quanto maior a profundidade alcançada, maior será a probabilidade de compartilhamento de memória. A Figura 2(a) ilustra um exemplo da árvore de alocação em um servidor físico u. Nesse exemplo existem quatro VMs alocadas: vm 1 é uma máquina Windows 7 32 bits, vm 2 é Windows 8 32 bits e vm 3 e vm 4 são Windows 8 64 bits. Supondo que uma VM Linux Ubuntu 13.10, 64 bits (vm 5 ) deva ser alocada em u. Como vm 5 não é similar a nenhum nó da árvore, α(vm 5, u) = 0. Se mesmo assim vm 5 for alocada em u, uma nova ramificação será criada na árvore (Figura 2(b)). Caso a vm 5 fosse Windows 7 64 bits, seriam encontrados dois níveis de similaridade (SO e versão), portanto α(vm 5, u) > 0. Caso vm 5 seja alocada em u, sua árvore ficaria conforme a Figura 2(c). Para a realização da simulação, foram estabelecidos pesos fixos de 0,1 para cada nível hierárquico da árvore. O fator α é calculado somando-se esse peso até o último nível comum entre as VMs. Assim, uma VM que tenha dois níveis de similaridade com outras terá α = 0, 2. O valor de 0,1 por nível foi escolhido de forma empírica, apenas para avaliar o algoritmo proposto; em servidores reais o compartilhamento de memória é muito variável, sofrendo oscilações durante o ciclo de vida das VMs. 87

102 (a) Cenário original (b) Alocação de uma VM Ubuntu bits (c) Alocação de uma VM Windows 7 64 bits 5. Experimentos Realizados Figura 2. Exemplo de árvore de alocação em um servidor Para a validação do algoritmo proposto optou-se pela realização de experimentos em um ambiente de simulação. Alguns fatores que contribuíram para essa escolha incluem a dificuldade de acesso a um ambiente de larga escala real, a dificuldade em generalizar resultados de testes em ambientes de pequena escala para ambientes maiores, a dificuldade de reprodução de testes em ambientes reais decorrente do caráter dinâmico do problema e, não menos importante, a existência de muitos trabalhos de pesquisa que usam o mesmo simulador, atestando a qualidade de seus resultados e os benefícios de sua utilização. Esta seção apresenta o ambiente de simulação utilizado para os experimentos, os ajustes necessários para adaptá-lo ao algoritmo proposto, os experimentos e cenários testados e os resultados obtidos Ambiente de Simulação Para a avaliação do algoritmo foi usado o simulador CloudSim [Calheiros et al. 2011], um framework extensível feito em Java que permite a modelagem e simulação de um ambiente de computação em nuvem. O CloudSim foi desenvolvido pelo The Cloud Computing and Distributed Systems (CLOUDS) Laboratory da Universidade de Melbourne, Austrália. Com o CloudSim é possível modelar vários aspectos do funcionamento de uma nuvem, como a configuração de um datacenter, nuvens federadas, cargas de trabalho dinâmicas, consumo de energia e políticas de alocação de máquinas virtuais. O CloudSim apresenta uma arquitetura multi-camadas: na base fica a camada de simulação, que oferece suporte para modelagem e simulação de ambientes virtualizados, inclui interfaces para gerenciamento de máquinas virtuais, memória, armazenamento e largura de banda. Dispõe de recursos para o gerenciamento de aplicações e monitoramento dinâmico do estado da nuvem. Nessa camada são estabelecidas as políticas de provisionamento e alocação de VMs. A camada do topo representa o código do usuário, que expõe as entidades básicas para definição dos hosts (número de máquinas e suas especificações), aplicações (número de tarefas e seus requisitos), máquinas virtuais, número de usuários e políticas de escalonamento. É nessa camada que são construídos os cenários de simulação e onde os experimentos são realizados. Para que o CloudSim atendesse os requisitos do algoritmo proposto, foram necessárias algumas modificações no framework. A Figura 3 apresenta parte do diagrama de 88

103 classes do framework, sendo visíveis apenas as classes de maior relevância; as classes em fundo cinza foram incluídas ao framework neste trabalho, para dar suporte à simulação do compartilhamento de memória. Figura 3. Diagrama simplificado de classes do CloudSim, com modificações As classes Host e Vm, que modelam, respectivamente, as características de um servidor físico e as características de uma máquina virtual, foram estendidas para SharedHost e SharedVm, incluindo as informações necessárias para o tratamento da memória compartilhada. Foi criada uma nova classe chamada SharedTree, que modela a árvore de alocações de VMs em um SharedHost. Através dessa estrutura é possível calcular o fator de compartilhamento α para cada servidor físico. Por fim, a classe VmAllocationPolicyVectorAlloc foi estendida de VmAllocationPolicy; ela contém a política de alocação e distribuição das máquinas virtuais nos servidores físicos. Ao iniciar a simulação, essa classe é a responsável por receber cada VM e encontrar o melhor servidor para alocá-la Experimentos Para a realização dos experimentos foram criados três cenários distintos, simulando ambientes de datacenter de diferentes portes (inpirado de [Lago et al. 2011]). O datacenter de pequeno porte contém 10 servidores onde devem ser alocadas 30 máquinas virtuais. De médio porte contém 100 servidores para alocação de 300 máquinas virtuais e o datacenter de grande porte com 1000 servidores para 3000 máquinas virtuais. As configurações de CPU, banda de rede e armazenamento nos servidores foram fixadas em MIPS, 1 Gbps e 1 TB. Para a memória adotou-se uma distribuição circular do conjunto {12, 16, 20 e 24 GB}, simulando servidores com diferentes capacidades. Para as máquinas virtuais, as configurações de banda de rede e de armazenamento ficaram fixas em 100 Mbps e 5 GB, com distribuição circular para a CPU em {1.000, 1.500, e MIPS e para a memória em 512 MB, 1, 2, 4 e 8 GB. O sistema operacional de cada VM pode ser Windows 7, Windows 8, Ubuntu 10.4 ou Ubuntu 12.4, todos podendo assumir a plataforma de 32 ou 64 bits. Adotou-se RTVmin = 0, 1 e RTVmax = 0, 9. Para cada cenário foram executados três algoritmos de alocação: a) um algoritmo de alocação usando a técnica First-Fit, onde uma VM é simplesmente alocada no primeiro servidor que tiver recursos suficientes disponíveis; b) o algoritmo VectorAlloc sem o compartilhamento de memória, ou seja, com α = 0; e c) o algoritmo VectorAlloc considerando o compartilhamento de memória. A alocação das VMs ocorre de forma online, ou seja, não há um pré-conhecimento do conjunto a ser instanciado. As VMs são alocadas em sequência, à medida que entram na fila de alocação. Isto se torna interessante para garantir a eficiência de alocação em sistemas onde os usuários chegam continuamente [Zaman and Grosu 2012]. 89

104 5.3. Resultados Para medir a eficiência do algoritmo foi coletada uma série de dados das simulações realizadas. Os dados apresentam o estado dos recursos físicos de cada servidor após a realização das alocações. A partir desses dados foi possível realizar algumas análises: pelo grau de utilização dos recursos, foi observado se a alocação pelo algoritmo resulta em uma melhor distribuição do uso dos recursos físicos dos servidores, ou seja, se as VMs foram distribuídas de modo a não criarem uma situação de excesso de carga ou de subutilização de recursos. O gap 1 entre o uso de memória e de CPU permite avaliar se esses recursos estão sendo alocados de forma equilibrada, não sobrecarregando um recurso do servidor enquanto o outro estaria subutilizado; um gap elevado pode fazer com que servidores com grande disponibilidade de um recurso não possam alocar uma nova VM devido à limitação de outro recurso. Finalmente, a Memória economizada permite avaliar quanta memória pode ser poupada pelo algoritmo proposto e se essa economia impactou no uso dos outros recursos, em especial a CPU. A Figura 4 apresenta o grau de utilização da memória após a execução de cada algoritmo nos três cenários. O eixo X apresenta os intervalos do percentual de utilização do recurso e o eixo Y a frequência com que o intervalo ocorre Padrão (first-fit) vectoralloc vectoralloc + sharing Número de servidores (%) cenário 1 cenário 2 cenário % 61-80% 41-60% 21-40% 0-20% % 61-80% 41-60% 21-40% 0-20% % 61-80% 41-60% 21-40% 0-20% Uso da RAM (%) Figura 4. Grau de utilização da memória após alocações É possível perceber que no algoritmo padrão o uso da memória está desequilibrado, atingindo inclusive extremos de uso: cerca de 10% dos servidores tiveram um uso de memória abaixo de 20%, enquanto outros 20% tiveram seu uso de memória entre 81% e 100%. No VectorAlloc tal situação não ocorre e o uso do recurso está equilibrado. Na execução sem compartilhamento de memória, todos os cenários apontaram que 60% dos servidores tiveram um grau de utilização entre 40% e 60%. O restante ficou dividido entre os intervalos vizinhos. Não houveram casos de utilização abaixo de 20% nem acima de 80%. Na execução com compartilhamento de memória os servidores em geral tiveram a utilização dos recursos reduzida. Os cenários apresentaram uma redução dos intervalos mais altos e aumento dos intervalos mais baixos, inclusive com utilização de memória abaixo de 20%, mas sem casos de utilização de recursos acima de 80%. Em relação ao gap existente entre a utilização de recursos de memória e de CPU, novamente o algoritmo VectorAlloc mostra-se mais equilibrado. A Figura 5 ilustra essa 1 Define-se como gap o módulo da diferença entre os níveis de uso de dois recursos. 90

105 situação. No algoritmo padrão, entre 70% e 80% das alocações criaram um gap de até 40%, mas nos ambientes de médio e grande porte, quase 10% dos servidores atingiram uma diferença entre 61% e 80%. Percebe-se que nessas situações um recurso está sendo muito sobrecarregado em relação ao outro. O VectorAlloc sem compartilhamento reduziu muito essa diferença, deixando em torno de 90% dos servidores com um gap inferior a 20%, o que indica uso equilibrado dos recursos. Com o compartilhamento de memória esse gap volta a ter um aumento, mas isso é explicado pelo fato do uso de CPU se manter o mesmo, enquanto o uso de memória foi reduzido pela possibilidade de compartilhamento Padrão (first-fit) vectoralloc vectoralloc + sharing Número de servidores (%) cenário 1 cenário 2 cenário % 61-80% 41-60% 21-40% 0-20% % 61-80% 41-60% 21-40% 0-20% % 61-80% 41-60% 21-40% 0-20% Gap entre CPU e RAM (%) Figura 5. Gap entre uso da memória e de CPU Os últimos resultados obtidos aparecem na Tabela 1 e mostram o uso médio de memória nos servidores, para cada algoritmo executado. Dos três algoritmos, o VectorAlloc com compartilhamento de memória gerou os melhores resultados, resultando numa média de utilização de memória em torno de 38%, cerca de 15% menor que o algoritmo padrão e 12,5% menor que o VectorAlloc sem compartilhamento de memória (coluna ganho). Tabela 1. Média e desvio padrão de uso da memória dos servidores cenário First-Fit VectorAlloc VectorAlloc + mem sharing média desvio média desvio ganho média desvio ganho 1 58,7% 27,9% 53,5% 12,0% 5.2% 43,9% 12,9% 14.8% 2 53,5% 27,2% 50,7% 12,6% 2.8% 38,2% 13,3% 15.3% 3 53,6% 27,1% 50,8% 12,4% 2.8% 38,0% 13,3% 15.6% 6. Conclusão Este artigo apresentou o algoritmo VectorAlloc para alocação online de máquinas virtuais em ambientes de computação em nuvem. O algoritmo faz uso de uma representação vetorial para a análise dos múltiplos recursos físicos e leva em consideração o compartilhamento de memória entre máquinas virtuais. Comparado a uma abordagem padrão de alocação, os resultados dos testes comprovaram que o algoritmo faz um melhor uso dos recursos físicos dos servidores, distribuindo as máquinas virtuais de uma modo mais equilibrado, eliminando cenários de sobrecarga ou subutilização. Nos testes considerando a possibilidade de compartilhamento de memória, o consumo médio de memória dos servidores foi reduzido em cerca de 15% em relação à abordagem padrão. 91

106 Referências Barker, S., Wood, T., Shenoy, P., and Sitaraman, R. (2012). An empirical study of memory sharing in virtual machines. In Usenix Annual Technical Conference. Buyya, R., Beloglazov, A., and Abawajy, J. (2010). Energy-efficient management of data center resources for cloud computing: A vision, architectural elements, and open challenges. arxiv preprint arxiv: , pages Calheiros, R., Ranjan, R., Beloglazov, A., De Rose, C., and Buyya, R. (2011). CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software: Practice and Experience, 41(1): Chen, M., Zhang, H., Su, Y.-Y., Wang, X., Jiang, G., and Yoshihira, K. (2011). Effective VM sizing in virtualized data centers. In IFIP/IEEE International Symposium on Integrated Network Management, pages Creasy, R. J. (1981). The origin of the VM/370 time-sharing system. IBM Journal of Research and Development, 25(5): Grit, L., Irwin, D., Yumerefendi, A., and Chase, J. (2006). Virtual machine hosting for networked clusters: Building the foundations for autonomic orchestration. In 1st International Workshop on Virtualization Technology in Distributed Computing. IEEE. Hyser, C., Mckee, B., Gardner, R., and Watson, B. (2007). Autonomic virtual machine placement in the data center. Technical Report HPL , HP Labs, Palo Alto CA. Lago, D., Madeira, E., and Bittencourt, L. (2011). Power-aware virtual machine scheduling on clouds using active cooling control and DVFS. In 9th International Workshop on Middleware for Grids, Clouds and e-science, New York USA. ACM Press. Mishra, M. and Sahoo, A. (2011). On theory of VM placement: Anomalies in existing methodologies and their mitigation using a novel vector based approach. In IEEE 4th International Conference on Cloud Computing, pages IEEE. Sindelar, M., Sitaraman, R. K., and Shenoy, P. (2011). Sharing-aware algorithms for virtual machine colocation. In 23rd ACM Symposium on Parallelism in Algorithms and Architectures, page 367, New York USA. ACM Press. Singh, A., Korupolu, M., and Mohapatra, D. (2008). Server-storage virtualization: Integration and load balancing in data centers. In ACM/IEEE Conference on Supercomputing, pages IEEE Press. Wood, T., Tarasuk-Levin, G., Shenoy, P., Desnoyers, P., Cecchet, E., and Corner, M. D. (2009). Memory buddies: Exploiting page sharing for smart colocation in virtualized data centers. Operating Systems Review, 43(3): Yen Van, H., Dang Tran, F., and Menaud, J.-M. (2009). Autonomic virtual resource management for service hosting platforms. In ICSE Workshop on Software Engineering Challenges of Cloud Computing, pages 1 8, Washington DC. IEEE Computer Society. Zaman, S. and Grosu, D. (2012). An online mechanism for dynamic VM provisioning and allocation in clouds. In 5th IEEE International Conference on Cloud Computing, pages IEEE. 92

107 Deaf Accessibility as a Service: uma Arquitetura Elástica e Tolerante a Falhas para o Sistema de Tradução VLIBRAS Eduardo Falcão, Tiago Maritan e Alexandre Duarte 1 Digital Video Applications Lab - LAVID Federal University of Paraiba - UFPB João Pessoa, Paraíba, Brazil {eduardolf, tiagomaritan, alexandre}@lavid.ufpb.br Abstract. When designed, Information and Communication Technologies rarely take into account the barriers that deaf people face. Currently, there are tools for automatic translation from spoken languages to sign languages, but, unfortunately, they are not available to third parties. To reduce these problems, it would be interesting if any automatic translation service could be publicly available. This is the general goal of this work: use a preconceived machine translation from portuguese language to Brazilian Sign Language (LIBRAS), named VLIBRAS, and provide Deaf Accessibility as a Service publicly. The idea is to abstract inherent problems in the translation process between the portuguese language and LIBRAS by providing a service that performs the automatic translation of multimedia content to LIBRAS. VLIBRAS was primarily deployed as a centralized system, and this conventional architecture has some disadvantages when compared to distributed architectures. In this paper we propose a distributed architecture in order to provide an elastic service and achieve fault tolerance. 1. Introdução A língua que um indivíduo usa para se comunicar depende de sua natureza além do grupo de indivíduos com o qual ele convive. Os ouvintes, por exemplo, comunicam-se por intermédio de línguas oralizadas. Já os surdos, por outro lado, encontram na linguagem gestual-corporal um meio eficaz de comunicação como alternativa à falta de capacidade auditiva. Portanto, a língua na qual o surdo consegue perceber e produzir de maneira natural é a língua de sinais (LS), ao passo que as línguas orais, utilizadas cotidianamente pela maioria das pessoas, representam apenas uma segunda língua [de Góes 1996]. Segundo o censo demográfico realizado em 2010 pelo Instituto Brasileiro de Geografia e Estatística (IBGE), 5,1% da população brasileira possui deficiência auditiva. Deste total, 1,7 milhões têm grande dificuldade para ouvir e 344,2 mil são surdos [Instituto Brasileiro de Geografia e Estatística 2010]. Normalmente, nos diferentes contextos da sociedade atual brasileira, a informação é transmitida através da língua portuguesa. Mas o nível de proficiência dos surdos na língua portuguesa pode tornar a leitura uma tarefa árdua e limitada [Gomes and Góes 2011], fazendo deste fator uma barreira a mais na inclusão digital. A LIBRAS é dotada de uma gramática própria, diferente da gramática da língua portuguesa. Com relação à ordem das palavras, por exemplo, existem diferenças entre as duas línguas [de Araújo 2012]. Na maioria dos casos, a língua portuguesa utiliza 93

108 sentenças no formato sujeito-verbo-objeto (SVO), enquanto que a LIBRAS geralmente utiliza sentenças no formato tópico-comentário [Brito 1995]. Araújo (2012) utilizou os seguintes exemplos para explicar esta diferença: O urso (S) matou (V) o leão (O). Eu (S) não vi (V) o acidente na rua (O). As sentenças supracitadas seriam representadas em LIBRAS da seguinte forma: URSO (Tópico), LEÃO MATAR (Comentário). RUA ACIDENTE (Tópico) NÃO ENXERGAR (Comentário). É de extrema importância a existência da tradução de LIBRAS para a língua portuguesa, com objetivo de reorganizar as frases alterando a ordem das palavras, as palavras em si (e.g., verbos em LIBRAS são sempre no infinitivo) e eliminando partes desnecessárias (e.g., artigos). Caso contrário, a sinalização realizada resultaria apenas em português sinalizado, de dificuldade ainda elevada por não constituir a LIBRAS. A acessibilidade para surdos requer primordialmente a tradução para LIBRAS. Esta tradução é de extrema importância mas traz consigo alguns problemas: 1. Alto custo do serviço: segundo SINTRA (2010), a tradução de 60 minutos de um áudio em língua portuguesa para a LIBRAS custa 585 reais; 2. Grande dinamismo de conteúdos nas tecnologias de informação e comunicação (TICs). Para sistemas de Video on Demand - VoD, prover acessibilidade para surdos também é uma tarefa complicada. Ao analisar o Youtube, por exemplo, é possível notar a inviabilidade da tradução de seus vídeos por intérpretes, devido aos milhões de usuários do serviço, e à grande quantidade de vídeos que são enviadas ao sistema. Uma das soluções para sistemas de VoD seria a utilização de um serviço de tradução automática da língua portuguesa para a LIBRAS. Para tanto, este trabalho utiliza o sistema VLIBRAS [de Araújo 2012] para oferecer este serviço. Atualmente, o VLIBRAS é implantado em uma arquitetura centralizada, e, portanto, pode ser aprimorado utilizando uma arquitetura distribuída. Para uma noção inicial da performance do VLIBRAS implantado em uma arquitetura centralizada 1, foi medido o tempo de processamento para 1, 10, 20, e 40 requisições simultâneas, apresentado na Tabela 1. Tais requisições foram compostas por textos com 324 palavras. Tabela 1. Média de tempo de processamento para requisições concorrentes N o de requisições Tempo médio Pior tempo Desvio padrão Falhas s s s s s s s Instância da Amazon c3.large, Ubuntu bits, 2 vcpu (CPUs virtuais) e 7 ECUs (unidade de processamento elástico), 3.75GB RAM 94

109 Com esses testes, foi possível constatar que o sistema falha ao atender um número de requisições igual ou superior a 40. Deste modo, fica mais claro entender a necessidade de uma arquitetura distribuída e dinâmica. Como o serviço será disponibilizado de forma pública, em momentos de pico o sistema poderá receber cargas muito superiores a 40 requisições, porém, em momentos de baixa demanda, também poderá receber um número de requisições inferior a 40. Uma das principais características da arquitetura distribuída proposta é a capacidade de provisionamento dinâmico de recursos. Com ela é possível economizar financeiramente em momentos de baixa demanda, mas também prover um serviço de qualidade mesmo quando submetidos a grandes cargas de requisições. Uma vez demonstrada a problemática que os surdos enfrentam nas TICs, este trabalho tem como objetivo geral a oferta de Deaf Accessibility as a Service (DAaaS) - um serviço de acessibilidade para surdos. Para tanto, será disponibilizado publicamente um serviço automatizado de tradução de conteúdos multimídia para a LIBRAS. Essa oferta pública demanda do VLIBRAS elasticidade para atender grandes cargas de requisições. Portanto, o principal objetivo deste trabalho é projetar um arquitetura distribuída, elástica e tolerante a falhas. A ideia é utilizar a nuvem para prover o DAaaS à terceiros de forma transparente, e utilizar os recursos de modo eficiente. Apesar deste trabalho utilizar um sistema de tradução previamente concebido, avaliar o nível de acerto na tradução realizada pelo sistema não entra no escopo dos objetivos. 2. Acessibilidade para Surdos Brasileiros nas TICs Para conceber o DAaaS foi preciso analisar as ferramentas de tradução automática mais abrangente, considerando variedade de entradas e plataformas de disponibilização. Diante dos sistemas de tradução português -> LIBRAS pesquisados, foram comparadas as principais características dos mesmos, com objetivo de justificar a escolha do VLIBRAS como núcleo da API DAaaS. As características avaliadas são: 1. formatos de entrada aceitos: texto, áudio, vídeo, legenda; 2. plataformas de execução: PC, Web, mobile, televisão digital; 3. forma de tradução: se a representação visual dos sinais é feita utilizando português sinalizado, ou utilizando a glosa (representação textual em LIBRAS); 4. Dicionário expansível: se o projeto disponibiliza alguma ferramenta que permita a expansão do dicionário de sinais por especialistas em LIBRAS. A tabela 2 lista os trabalhos com suas respectivas características. A característica mais importante a ser avaliada é a forma de tradução. Os trabalhos que convertem o texto em língua portuguesa para a glosa devem ser priorizados, uma vez que o português sinalizado é insuficiente para a compreensão completa por parte dos surdos. Normalmente, o dicionário de sinais é expandido por uma equipe de especialistas em LIBRAS e TI pertencentes ao projeto, porém, sabe-se que a quantidade de sinais a ser confeccionados é muito grande. Desse modo, pode-se perceber o quanto a funcionalidade de Dicionário expansível é importante, pois permite que pessoas externas ao projeto possam contribuir com a criação de novos sinais. Por fim, quanto mais opções de formatos de entrada e plataformas de execução o projeto oferecer, mais formatos de 2 T = texto, A = áudio, V = vídeo, L = legenda 3 W = Web, M = mobile 95

110 Tabela 2. Sistemas de Tradução Automática Português -> LIBRAS. Adaptado de: [Pivetta et al. 2011] Tradutor Entradas 2 Plataformas 3 Tradução Código Dic. expansível T A V L PC W M TV F-LIBRAS X X glosa fechado X FALIBRAS X X X X X glosa fechado POLI-LIBRAS X X X glosa aberto X ProDeaf X X X X glosa fechado Rybená X X X X port. sinalizado fechado TLIBRAS X X X X glosa fechado VLIBRAS X X X X X X X glosa fechado X VE-LIBRAS X X X port. sinalizado fechado entrada e plataforma de execução o serviço DAaaS poderá oferecer. Portanto, a partir das informações colhidas e projetadas na tabela 2, foi concluído que para o presente trabalho a melhor opção é o sistema de tradução automática VLIBRAS. Nesse sentido, o código do VLIBRAS foi disponibilizado para a concepção do DAaaS. 3. Deaf Accessibility as a Service Sistemas centralizados apresentam várias desvantagens quando comparados a sistemas distribuídos. A solução atual para o sistema de tradução automática VLIBRAS é baseada em um sistema centralizado, e, portanto, possui capacidade de tolerância a falhas limitada além de não ter capacidade de provisionamento dinâmico de recursos. Adicionalmente, a nuvem permite pagamento de recursos exclusivamente perante uso, não havendo necessidade de manter máquinas ociosas, e fácil implantação e configuração do serviço em diferentes lugares do mundo, não impondo a necessidade de espaço físico, energia, refrigeração, e manutenção da infraestrutura. A capacidade de provisionamento dinâmico permitirá o sistema alocar recursos para atender grandes cargas de requisição e readaptar-se quando a demanda diminuir, economizando recursos [Radhakrishnan 2012]. Essa elasticidade automática é uma das características que atenua a probabilidade de ocorrência de falhas, através da alta disponibilidade dos recursos [Bala and Chana 2012]. Além disso, o trabalho utiliza uma técnica de tolerância a falhas reativa (resubmissão de tarefas) e uma proativa (self-healing) Arquitetura Distribuída Proposta A arquitetura proposta para o DAaaS foi projetada para ser implantada em uma infraestrutura de nuvem. O objetivo desta arquitetura é incorporar as seguintes funcionalidades: Descentralização do fluxo de rede: a existência de vários nós de processamento implica em vários fluxos de rede entre os clientes e as instâncias de processamento; 96

111 Provisionamento dinâmico de recursos: quando em momentos de sobrecarga, a escalabilidade sob demanda permite que o DAaaS tenha recursos disponíveis para processar as requisições através da inclusão de novas instâncias de processamento; Tolerância a falhas: Alta disponibilidade dos recursos: os recursos são sempre disponibilizados com redundância e em diferentes zonas de disponibilidade; Em nível de software: tolerância a falhas reativa por resubmissão de tarefas, e proativa por meio de self-healing; Para tal, pretende-se utilizar o Broker e a Fila de Requisições. O Broker funciona como um gerenciador de requisições, adicionando as novas requisições na Fila de Requisições, e notificando os nós de processamento. Como será explicado na seção 3.2, a Fila de Requisições tem como principal objetivo a recuperação de falhas utilizando um mecanismo de resubmissão. Na arquitetura centralizada existe um único canal para fluxo de rede para que os conteúdos de entrada (vídeo, legenda, ou texto) e de saída (vídeo de tradução) trafeguem. Tal fato converge para elevar a probabilidade de haver um gargalo de rede, aumentando o tempo de resposta para as requisições. A arquitetura proposta (Figura 1) busca diminuir o gargalo de rede uma vez que existirá um canal de rede para cada instância de processamento, e, portanto, vários canais de tráfego de vídeos para o sistema como um todo. Ao invés do sistema de VoD, por exemplo, enviar primariamente o arquivo de vídeo para tradução (como acontece na arquitetura centralizada), envia apenas uma requisição (arquivo XML/JSON) que contém o endereço daquele vídeo, e então a instância de processamento estabelece uma conexão direta para realizar o download do vídeo. Esta característica do sistema evita a sobrecarga no canal de rede em que se insere o Broker, uma vez que os arquivos XML/JSON possuem carga extremamente inferior a arquivos de vídeo. Na Figura 1, é ilustrado o funcionamento da arquitetura proposta. Para explicar o funcionamento desta arquitetura será utilizado o exemplo em que o sistema de VoD é o cliente do DAaaS. O processo completo para que um sistema de VoD requisite a tradução de algum conteúdo obedece a sequência de passos ordenada e identificada pelos números na Figura O usuário escolhe um vídeo do sistema de VoD para assistir e requisita a opção de acessibilidade; 2. O sistema de VoD envia uma requisição (arquivo JSON ou XML em conformidade com a API do DAaaS) de tradução ao Broker do sistema DAaaS; 3. O Broker adiciona essa requisição a uma fila de requisições, e notifica as instâncias de processamento para que elas saibam que existe uma nova requisição na fila; 4. As instâncias que possuírem recursos livres, irão competir para processar as requisições na fila. Cada requisição é alocada de forma atômica por uma única instância, nesse caso, a instância B; 5. A instância B realiza o download do vídeo e dá início à tradução automática; 6. Uma vez que a tradução para LIBRAS seja concluída, o vídeo de tradução é transferido para o serviço de armazenamento de arquivos escalável; 7. A instância envia um sinal para a Fila de Requisições remover aquela requisição específica, uma vez que tenha sido processada com sucesso; 8. Uma mensagem contendo o endereço do vídeo de tradução em LIBRAS é enviado para o Broker; 97

112 Figura 1. DAaaS - Arquitetura Distribuída Proposta 9. Essa mensagem é enviada para o sistema de VoD; 10. O sistema de VoD realiza o download do vídeo de tradução em LIBRAS e exibe para o usuário final de maneira sincronizada com o vídeo original. A seguir, serão demonstradas as estratégias de tolerância a falhas (3.2) e provisionamento dinâmico de recursos (3.3), que visa prover resiliência e elasticidade ao DAaaS Tolerância a Falhas Alta Disponibilidade dos Recursos A existência de redundância de recursos em localizações geográficas diferentes provê tolerância a falhas por meio de alta disponibilidade. De acordo com a Figura 1, as instâncias de processamento estão situadas em diferentes locais físicos. É possível configurar o provisionamento dinâmico para criar novas instâncias em diferentes localizações geográficas, visando equilibrar a quantidade de instância nestes locais (e.g., 2 instâncias no local A, 2 instâncias no local B, e 2 instância no local C ). Se porventura alguma unidade de processamento falhar, o DAaaS não ficará indisponível, uma vez que outros nós de processamento podem assumir a carga do nó defeituoso até que o problema seja resolvido. Deste modo, evita-se que problemas com rede ou energia em determinada localização, ou até mesmo falhas de hardware, interfiram na disponibilidade do DAaaS. 98

113 Em Nível de Software Na antiga arquitetura centralizada, as falhas eram irreversíveis, ou seja, se ocorressem não eram passíveis de recuperação. A tolerância a falhas em nível de software permite a recuperação de uma falha ocorrida, além de sua prevenção por antecipação. Os componentes responsáveis pela tolerância a falha em nível de software são o Broker e a Fila de Requisições. Com relação a tolerância a falha, as principais atividades do Broker são: Gerenciamento de requisições: toda requisição chega primeiro ao Broker, que é encarregado de enviá-la para a Fila de Requisições. Se não houvesse o gerenciamento as requisições seriam escalonadas automaticamente para um nó de processamento, tornando a recuperação de uma eventual requisição falha restrita àquela instância de processamento; Notificação: assim que o Broker adiciona uma nova requisição à Fila de Requisições, seu próximo passo é notificar todos os nós de processamento para que eles saibam o momento correto de consumir a Fila de Requisições; Provisionamento dinâmico de recursos: baseado na quantidade de requisições na Fila de Requisições, o Broker adiciona ou remove novos nós de processamento. O Broker também faz checagens periódicas para garantir que todos os nós de processamento estejam em pleno funcionamento, removendo os defeituosos e adicionando novos quando necessário. O serviço DAaaS usa uma técnica de tolerância a falha reativa por resubmissão de tarefas. A técnica reativa proposta consiste em resubmeter as requisições que falharem à Fila de Requisições. Para tal, todas as requisições desta Fila de Requisições são marcadas com uma tag visível ou invisível. Todas as requisições inseridas nesta fila são marcadas por padrão como visível, para que todas as instâncias possam acessá-las. Quando o Broker adiciona novas requisições a essa Fila de Requisições, sua próxima tarefa é notificar as instâncias de processamento para avisar que a fila possui novos itens a serem consumidos. Assim que uma instância começa a processar uma requisição da fila, a mesma é marcada como invisível até que essa instância termine seu processamento e explicitamente a remova da fila. Testes preliminares devem ser realizados para definir quantas requisições simultâneas cada instância consegue processar com sucesso, e qual o pior tempo para processamento em situações de. Consideramos como falha o caso em que uma instância não conseguir processar a requisição dentro desse pior tempo estipulado. Este pior tempo é utilizado como tempo de invisibilidade padrão, ou seja, se o processamento de alguma requisição for maior do que o pior tempo pré-calculado a requisição será automaticamente marcada como visível e será reprocessada por outra instância ou até pela mesma. Portanto, há a possibilidade de acontecer a falha real, onde o processamento da requisição realmente falhou, mas também há a possibilidade da falha falsa, quando uma instância demorar mais tempo para processar uma requisição do que o pior tempo estipulado. Quando ocorrer a falha falsa a requisição será processada duas ou mais vezes, onde o primeiro processamento pode até ser concluído com sucesso, mas por demorar muito é desconsiderado pelo DAaaS, e o último processamento terminará antes do pior tempo. Quando uma requisição falhar e tornar-se visível novamente, não haverá mais nen- 99

114 huma notificação exclusiva do Broker às instâncias avisando que aquela requisição específica está mais uma vez visível. Contudo, as instâncias podem consumir a requisição que falhou através de outras notificações do Broker para outras requisições, ou através de um laço de checagem de requisições (15 segundos) que as instâncias de processamento implementam para consumir novas requisições independente da notificação do Broker. O modelo de processo de negócios para tolerância a falhas reativa por meio de resubmissão de tarefas é detalho na Figura 2, através de um diagrama BPMN (Business Process Modeling Notation). Figura 2. Modelo de Processos de Negócios para Tolerância a Falhas Reativa A técnica proativa também é implementada no Broker, através do provisionador dinâmico de recursos, que é encarregado de alocar ou desalocar recursos diante das métricas especificadas. Uma das funções deste provisionador é verificar se alguma das instâncias não está mais em funcionamento, através de requisições HTTP às máquinas supostamente ativas, e as repor caso elas aparentem estar defeituosas Provisionamento Dinâmico de Recursos A estratégia utilizada para provisionamento dinâmico de recursos baseia-se na Fila de Requisições. Deste modo, testes preliminares devem ser realizados para definir quantas requisições simultâneas cada tipo de instância utilizada consegue processar, e qual 100

115 o pior tempo para processamento em situações de sobrecarga. Baseado na quantidade máxima de requisições simultâneas, no tamanho da Fila de Requisições, e na quantidade de instâncias de processamento ativas, é possível calcular se o DAaaS está sobrecarregado ou subutilizado, para criar novas instâncias ou remover algumas. A tendência é que as instâncias de processamento estejam sempre sobrecarregadas (caso haja requisições na Fila), uma vez que o Broker sempre notifica todas as instâncias quando novas requisições são inseridas na fila, além da existência do laço de checagem de novas requisições nas instâncias de processamento, que independe do Broker. Portanto, as instâncias de processamento estarão sempre absorvendo a Fila de Requisições se tiverem recursos disponíveis, ou seja, sempre que não estiverem processando a quantidade máxima de requisições delimitadas. O diagrama ilustrado na Figura 3, detalha os passos do algoritmo de provisionamento dinâmico para criar ou terminar as instâncias de processamento VLIBRAS. Seguindo esse modelo de processo de negócios, é possível simular o que aconteceria se, por exemplo, a Fila de Requisições possuísse 1435 requisições, a instância pudesse processar no máximo 15 requisições, e o pior tempo para processamento em situações de sobrecarga fosse 30 minutos. Lembrando que o DAaaS inicia com 2 instâncias de processamento, que é a quantidade mínima, o algoritmo de escalonamento executaria os seguintes passos: 1. O DAaaS possui menos instâncias de processamento do que a quantidade mínima delimitada? Não, o DAaaS tem 2 instâncias disponíveis. 2. O DAaaS possui a quantidade de instâncias necessárias para processar a Fila de Requisições? Não, o DAaaS possui apenas 2 instâncias, que não têm capacidade para atender todas as requisições em tempo hábil. 3. O DAaaS cria N instâncias até atingir a quantidade necessária para processar a Fila de Requisições. Abaixo vamos calcular N a partir do código do DAaaS: (a) int instancesrequired = (int) Math.ceil(requestsOnQueue/maxRequestsPerInstance); (b) int instancesrequired = (int) Math.ceil(1435/15); (c) int instancesrequired = (int) Math.ceil(95.66); (d) int instancesrequired = 96; 4. Sabendo que uma instância leva de 90 a 120 segundos para iniciar, 3 minutos é um tempo com folga para que a instância inicie e absorva a quantidade máxima de requisições, nesse caso, O DAaaS possui menos instâncias de processamento do que a quantidade mínima delimitada? Não, o DAaaS tem 96 instâncias disponíveis. 6. Quando o algoritmo de escalonamento chegar neste ponto, O DAaaS possui a quantidade de instâncias necessárias para processar a Fila de Requisições?, a resposta será SIM, já que as 96 instâncias (94 recém criadas) absorveram toda a Fila de Requisições. A menos que nesse meio tempo novas requisições tenham chegado na fila, e que as instâncias ativas não as tenham processado. Para redução da quantidade de instâncias, o chamado scaling in, o DAaaS esperaria o pior tempo para processamento em situações de sobrecarga. No caso do exemplo anterior, o DAaaS esperaria 50 minutos para calcular quantas instâncias deveriam ser eliminadas a partir do número de requisições na Fila, e da quantidade de instâncias ativas. Já que o pagamento na AWS é por hora, não faz sentido terminar instâncias já pagas por 101

116 um tempo distante de 60 minutos. Quando o Broker notifica uma instância para ser removida ela não é imediatamente excluída, porém, a partir desta notificação ela se prepara pra encerrar, ignorando as novas requisições na Fila de Requisições notificadas pelo Broker ou pelo laço de checagem. Uma thread é ativada para checar continuamente se as requisições em andamento já finalizaram, e em caso positivo, a thread encerra a instância atual. Um detalhe que pode ser melhorado nesse algoritmo é o monitoramento exato de quantas requisições cada instância ativa possui, para ao notificar a remoção de algumas instâncias, fazê-lo de forma crescente, notificando primeiramente as instâncias com menor número de requisições. Figura 3. Modelo de Processos de Negócios para Provisionamento Dinâmico de Recursos 4. Cenários de Uso A API está sendo disponibilizada na AWS, recebendo requisições na url O DAaaS está implantado utilizando instâncias do tipo m1.small e é financiado por meio de créditos da AWS para pesquisas científicas. Atualmente, a API possui dois usuários: 1 - sítio do SENAPES; 2 - aplicativo VLIBRAS mobile. O SENAPES é um evento que será aberto ao público e tem como objetivo principal a apresentação e discussão de experiências no desenvolvimento e implantação de tecnologias assistivas para promoção da acessibilidade para pessoas surdas nas TICs. Portanto, haverá grande acesso de pessoas surdas ao sítio e o mesmo será acessível a elas por meio do DAaaS. 102

117 Para obter a tradução de um texto no sítio do SENAPES o usuário deve selecionar o texto, e clicar no botão Traduzir. Então uma janela de carregamento aparecerá, e quando a tradução estiver disponível será prontamente exibida ao usuário, como pode ser observado na 4. O plugin de tradução para o sítio SENAPES foi desenvolvido pelo LAVID utilizando a API DAaaS. Figura 4. Avatar traduzindo o texto selecionado O aplicativo VLIBRAS mobile é disponibilizado para plataforma android, o que comprova que o DAaaS pode ser utilizado de forma heterogênea em diferentes meios de disponibilização. O aplicativo permite tradução a partir de texto, legenda, e também a partir do áudio, aplicando um passo adicional de conversão para texto. As Figuras 5 e 6 ilustram o processo de tradução do VLIBRAS mobile. 5. Considerações Finais O presente trabalho propõe a disponibilização de um serviço de tradução automática, o DAaaS, a ser implantada em uma arquitetura distribuída, elástica e tolerante a falhas. Para este fim, utilizamos o paradigma de computação em nuvem e implantamos a arquitetura no provedor de infraestrutura AWS. Figura 5. Opções Figura 6. Avatar realizando tradução 103

118 Trabalhos futuros envolvem a validação da arquitetura proposta quanto à capacidade de provisionamento dinâmico de recursos e de tolerância a falhas com um projeto de experimentos. Também é necessário a implementação de um mecanismo de autenticação para o serviço. Atualmente, o DAaaS possui dois clientes como estudo de caso, o sítio do SENAPES e o aplicativo VLIBRAS mobile. O serviço ainda apresenta um ponto crítico passível de falhas que futuramente deve ser corrigido, o Broker. Se, porventura, o Broker falhar, o DAaaS para de funcionar. Um modo rápido e fácil de consertar essa vulnerabilidade no provedor de IaaS AWS, é utilizar o AutoScaling aliado ao Elastic Load Balancing. Para tal, basta configurar o AutoScaling com um gatilho para detectar sempre que não houver instância com a Amazon Machine Image - AMI do Broker ativa, e configurar uma política de escalonamento para criar uma nova instância com a AMI do Broker cada vez que o gatilho for disparado. O ELB seria utilizado para redirecionar as requisições para a instância recém criada. Outra forma de utilização seria utilizar o AutoScaling e o ELB para manter sempre as duas instâncias do Broker ativas, o que aumentaria a disponibilidade do Broker mas também elevaria os gastos. Por fim, agradecemos à Amazon Web Services pelos créditos para pesquisa que possibilitaram a realização deste trabalho. 6. Referências References Bala, A. and Chana, I. (2012). Fault tolerance-challenges, techniques and implementation in cloud computing. International Journal of Computer Science Issues, 9(1): Brito, L. (1995). Por uma gramática de línguas de sinais. Tempo Brasileiro, Rio de Janeiro, Brasil. de Araújo, T. M. U. (2012). Uma Solução para Geração Automática de Trilhas em Língua Brasileira de Sinais em Conteúdos Multimídia. PhD thesis, Universidade Federal do Rio Grande do Norte, Natal, Brasil. de Góes, M. (1996). Linguagem, surdez e educação. Coleção Educação contemporânea. Autores Associados. Gomes, R. C. and Góes, A. R. S. (2011). E-acessibilidade para Surdos. Revista Brasileira de Tradução Visual, 7(7). Instituto Brasileiro de Geografia e Estatística (2010). Censo demográfico 2010: Características gerais da população, religião e pessoas com deficiência. Technical report. Pivetta, E. M., Ulbricht, V., and Savi, R. (2011). Tradutores automáticos da linguagem português oral e escrita para uma linguagem visual-espacial da língua brasileira de sinais. V CONAHPA - Congresso Nacional de Ambientes Hipermídia para Aprendizagem. Radhakrishnan, G. (2012). Adaptive application scaling for improving fault-tolerance and availability in the cloud. Bell Labs Technical Journal, 17(2):5 14. Sindicato Nacional dos Tradutores (2013). Valores de Referência Praticados a Partir de Janeiro de

119 Índice por Autor A Araujo, A.E.P....3 Araujo, J.C.T....3 B Beserra, D.W.S.C....3, 28 Borba, A.W.T....3 C Camboim, K....3 Coutinho, E.F....43, 55 E Endo, P.T G Galdino, S Gomes, D.G....43, 55 K Kamienski, C.A M Maziero, C.A Muchalski, F.J R Rego, P.A.L Rocha, F.G S Senger, H Silva, R.K.P....3, 28 Simões, R Souza, J.N....43,

120