IX Workshop em Clouds, Grids e Aplicações (WCGA)

Tamanho: px
Começar a partir da página:

Download "IX Workshop em Clouds, Grids e Aplicações (WCGA)"

Transcrição

1 ANAIS

2 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 30 de maio a 3 de junho de 2011 Campo Grande, MS IX Workshop em Clouds, Grids e Aplicações (WCGA) Editora Sociedade Brasileira de Computação (SBC) Organizadores Bruno Schulze (LNCC) Fábio Porto (LNCC) Fábio Moreira Costa (UFG) Ronaldo Alves Ferreira (UFMS) Realização Faculdade de Computação Universidade Federal de Mato Grosso do Sul (UFMS) Promoção Sociedade Brasileira de Computação (SBC) Laboratório Nacional de Redes de Computadores (LARC)

3 ii Anais Copyright 2011 da Sociedade Brasileira de Computação Todos os direitos reservados Capa: Venise Melo Produção Editorial: Lucilene Vilela Gonçalves, Ronaldo Alves Ferreira Cópias Adicionais: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, 9500 Setor 4 Prédio Sala 219 Bairro Agronomia CEP Porto Alegre RS Fone: (51) Dados Internacionais de Catalogação na Publicação (CIP) Workshop em Clouds, Grids e Aplicações (9.: 2011 : Campo Grande, MS). Anais / IX Workshop em Clouds, Grids e Aplicações; organizadores Bruno Schulze... et al. Porto Alegre : SBC, c p. ISSN X 1. Redes de computadores. 2. Sistemas distribuídos. I. Schulze, Bruno. II. Título.

4 IX Workshop em Clouds, Grids e Aplicações iii Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente José Carlos Maldonado (USP) Vice-Presidente Marcelo Walter (UFRGS) Diretor Administrativo Luciano Paschoal Gaspary (UFRGS) Diretor de Finanças Paulo Cesar Masiero (USP) Diretor de Eventos e Comissões Especiais Lisandro Zambenedetti Granville (UFRGS) Diretora de Educação Mirella Moura Moro (UFMG) Diretora de Publicações Karin Breitman (PUC-Rio) Diretora de Planejamento e Programas Especiais Ana Carolina Salgado (UFPE) Diretora de Secretarias Regionais Thais Vasconcelos Batista (UFRN) Diretor de Divulgação e Marketing Altigran Soares da Silva (UFAM) Diretor de Regulamentação da Profissão Ricardo de Oliveira Anido (UNICAMP) Diretor de Eventos Especiais Carlos Eduardo Ferreira (USP) Diretor de Cooperação com Sociedades Científicas Marcelo Walter (UFRGS)

5 iv Anais Promoção Conselho Mandato Virgílio Almeida (UFMG) Flávio Rech Wagner (UFRGS) Silvio Romero de Lemos Meira (UFPE) Itana Maria de Souza Gimenes (UEM) Jacques Wainer (UNICAMP) Mandato Cláudia Maria Bauzer Medeiros (UNICAMP) Roberto da Silva Bigonha (UFMG) Cláudio Leonardo Lucchesi (UFMS) Daltro José Nunes (UFRGS) André Ponce de Leon F. de Carvalho (USP) Suplentes Mandato Geraldo B. Xexeo (UFRJ) Taisy Silva Weber (UFRGS) Marta Lima de Queiroz Mattoso (UFRJ) Raul Sidnei Wazlawick (PUCRS) Renata Vieira (PUCRS) Laboratório Nacional de Redes de Computadores (LARC) Diretoria Diretor do Conselho Técnico-Científico Artur Ziviani (LNCC) Diretor Executivo Célio Vinicius Neves de Albuquerque (UFF) Vice-Diretora do Conselho Técnico-Científico Flávia Coimbra Delicato (UFRN) Vice-Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Membros Institucionais CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC, UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS, UFPA, UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP, UNIFACS, USP

6 IX Workshop em Clouds, Grids e Aplicações v Realização Comitê de Organização Coordenação Geral Ronaldo Alves Ferreira (UFMS) Coordenação do Comitê de Programa Artur Ziviani (LNCC) Bruno Schulze (LNCC) Coordenação de Palestras e Tutoriais Nelson Luis Saldanha da Fonseca (UNICAMP) Coordenação de Painéis e Debates José Augusto Suruagy Monteiro (UNIFACS) Coordenação de Minicursos Fabíola Gonçalves Pereira Greve (UFBA) Coordenação de Workshops Fábio Moreira Costa (UFG) Coordenação do Salão de Ferramentas Luis Carlos Erpen De Bona (UFPR) Comitê Consultivo Antônio Jorge Gomes Abelém (UFPA) Carlos André Guimarães Ferraz (UFPE) Francisco Vilar Brasileiro (UFCG) Lisandro Zambenedetti Granville (UFRGS) Luci Pirmez (UFRJ) Luciano Paschoal Gaspary (UFRGS) Marinho Pilla Barcellos (UFRGS) Paulo André da Silva Gonçalves (UFPE) Thais Vasconcelos Batista (UFRN)

7 vi Anais Realização Organização Local Brivaldo Alves da Silva Jr. (UFMS) Edson Norberto Cáceres (UFMS) Eduardo Carlos Souza Martins (UFMS/POP-MS) Hana Karina Sales Rubinstejn (UFMS) Irineu Sotoma (UFMS) Kátia Mara França (UFMS) Luciano Gonda (UFMS) Lucilene Vilela Gonçalves (POP-MS) Márcio Aparecido Inácio da Silva (UFMS) Marcos Paulo Moro (UFGD) Massashi Emilson Oshiro (POP-MS) Nalvo Franco de Almeida Jr. (UFMS) Péricles Christian Moraes Lopes (UFMS) Renato Porfírio Ishii (UFMS)

8 IX Workshop em Clouds, Grids e Aplicações vii Mensagem do Coordenador Geral Sejam bem-vindos ao XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2011) em Campo Grande, MS. É um prazer e uma distinção organizar um simpósio de tamanha relevância para a Computação no Brasil, mais ainda por ser a primeira vez que a Região Centro-Oeste tem o privilégio de sediá-lo. O SBRC é um evento anual promovido pela Sociedade Brasileira de Computação (SBC) e pelo Laboratório Nacional de Redes de Computadores (LARC). Ao longo dos seus quase trinta anos, o SBRC tornou-se o mais importante evento científico nacional em Redes de Computadores e Sistemas Distribuídos e um dos maiores da área de Informática no país. O SBRC 2011 está com uma programação bastante rica, de qualidade diferenciada e que consiste em: 18 sessões técnicas de artigos completos que abordam o que há de mais novo nas áreas de redes de computadores e sistemas distribuídos; três sessões técnicas para apresentação de ferramentas selecionadas para o Salão de Ferramentas; cinco minicursos, com quatro horas de duração, sobre temas atuais; três palestras e três tutoriais com pesquisadores de alto prestígio internacional; e três painéis sobre assuntos de interesse da comunidade. Além dessas já tradicionais atividades do simpósio, ocorrerão em paralelo oito workshops: XVI Workshop de Gerência e Operação de Redes e Serviços (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa (WRNP), XII Workshop de Testes e Tolerância a Falhas (WTF), IX Workshop em Clouds, Grids e Aplicações (WCGA), VII Workshop de Redes Dinâmicas e Sistemas P2P (WP2P), II Workshop de Pesquisa Experimental da Internet do Futuro (WPEIF), I Workshop on A utonomic Distributed Systems (WoSIDA) e I Workshop de Redes de Acesso em Banda Larga (WRA). O desafio de organizar um evento como o SBRC só pode ser cumprido com a ajuda de um grupo especial. Eu tive a f elicidade de contar com a co laboração de inúmeras pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos Comitês de Organização Geral e Local por realizarem um trabalho de excelente qualidade e com muita eficiência, a qualidade da programação deste simpósio é fruto do trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computação da UFMS por ter sido uma facilitadora ao longo de todo o pr ocesso de organização, desde a nossa proposta inicial até o fechamento da programação. Gostaria de agradecer, também, ao Comitê Gestor da Internet no Brasil (CGI.br), às agências governamentais de fomento e aos patrocinadores por reconhecerem a importância do S BRC e investirem recursos financeiros fundamentais para a realização do evento. Com o apoio financeiro recebido, foi possível manter os custos de inscrição baixos e oferecer um programa social de alta qualidade. Em nome do Comitê Organizador, agradeço a todos os participantes pela presença em mais esta edição do SBRC e d esejo uma semana produtiva, agradável e com estabelecimento de novas parcerias e amizades. Ronaldo Alves Ferreira Coordenador Geral do SBRC 2011

9 viii Anais Mensagem do Coordenador de Workshops do SBRC 2011 Os workshops são uma parte tradicional do que hoje faz do SBRC o principal evento da área no país, sendo responsáveis por atrair uma parcela cada vez mais expressiva de participantes para o S impósio todos os anos. O SBRC 2011 pr ocurou manter essa tradição, com a realização de workshops já considerados parte do circuito nacional de divulgação científica nas várias subáreas de Redes de Computadores e S istemas Distribuídos, como o WTF (Workshop de Testes e Tolerância a F alhas), o WCGA (Workshop em Clouds, Grids e Aplicações), o WGRS ( Workshop de Gerência e Operação de Redes e Serviços) e o WP2P (Workshop de Redes Dinâmicas e Sistemas P2P). Incluímos também nesta lista de iniciativas bem sucedidas o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que cumpre o importantíssimo papel de fazer a ponte entre as comunidades técnica e científica da área. Como novidade em 2011, e reconhecendo o s urgimento e o fortalecimento de novas linhas de pesquisa de expressiva importância dentro da comunidade brasileira de Redes e Sistemas Distribuídos, procuramos incentivar a criação de novos workshops dentro do Simpósio. Foi com esse intuito que introduzimos pela primeira vez no SBRC a chamada aberta de workshops, por meio da qual membros da comunidade foram convidados a submeter propostas de workshops inéditos para realização em conjunto com o S BRC Em resposta à chamada, recebemos nove propostas de alta qualidade, das quais oito foram aceitas e seus respectivos proponentes convidados a organizarem os workshops no SBRC em Campo Grande. Das oito propostas aceitas, cinco tratavam dos workshops já tradicionais acima mencionados, e uma referia-se à segunda edição de um workshop mais recentemente criado, mas que teve sua primeira edição realizada de forma muito bem sucedida no S BRC 2010, o WPEIF (Workshop de Pesquisa Experimental da Internet do Futuro). As outras duas propostas foram resultado direto da chamada aberta de workshops e resultaram na adição de dois novos eventos ao leque do SBRC, o WRA (Workshop de Redes de Acesso em Banda Larga) e o W osida (Workshop on Autonomic Distributed Systems), ambos com ótima aceitação pela comunidade, a julgar pelos números de submissões de trabalhos recebidos. Esperamos que 2011 s eja mais um ano de sucesso para os workshops do S BRC, em particular para aqueles criados nesta edição do Simpósio, e para que eles continuem contribuindo como importantes fatores de agregação para os avanços promovidos pela comunidade científica da área de Redes e Sistemas Distribuídos no Brasil. Aproveitamos para agradecer o i nestimável apoio recebido de diversos membros da comunidade e, em particular, da Organização Geral do SBRC A todos, um excelente SBRC em Campo Grande! Fábio M. Costa Coordenador de Workshops do SBRC 2011

10 IX Workshop em Clouds, Grids e Aplicações ix Mensagem dos Coordenadores do WCGA O IX Workshop em Clouds, Grids e Aplicações (WCGA 11) em conjunto com o 29º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2011), em Campo Grande, MS, tem por objetivo atuar como um fórum para apresentações técnicas de pesquisas em andamento e atividades relevantes nas áreas de infra-estrutura real e virtualizada, serviços e aplicações em áreas diversas, congregando pesquisadores e profissionais que atuam ativamente nessas áreas. O workshop também procura estabelecer redes colaborativas multi-institucionais e grupos de competência técnicocientífica, bem como fortalecer atividades em andamento. As primeiras edições do WCGA ( ) foram realizadas no LNCC, em Petrópolis-RJ. As edições de 2006, 2007, 200 8, 2009 e 2010 f oram 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) e Gramado (RS). Estas edições anteriores do WCGA receberam uma combinação interessante de diferentes áreas de computação em grids e clouds, como infra-estrutura, middleware, e aplicações, com apresentações técnicas fomentando discussões em vários tópicos interessantes. Estas edições geraram um interesse crescente na comunidade e nos baseamos nesta tradição para esta edição de A nona edição do W CGA teve treze (13) artigos aceitos vinte e três (23) trabalhos submetidos. Os autores apontaram problemas e soluções em um ou mais temas dentre aqueles identificados para o workshop. Finalmente, a coordenação do w orkshop gostaria de agradecer a todos os autores e participantes pela apresentação dos trabalhos e contribuições de pesquisa em clouds, grids e aplicações, agradecer a todos os revisores e membros dos comitês de programa e de organização pelo apoio na elaboração do programa do workshop e nas atividades, e adicionalmente agradecer os apoios de LNCC, UFMS e SBC. Bruno Schulze Fabio Porto Coordenadores do WCGA 2011

11 x Anais Comitê de Programa do WCGA Alexandre Lima (UFRJ) Alfredo Goldman (USP) Antônio Roberto Mury (LNCC) Antônio Tadeu A Gomes (LNCC) Artur Ziviani (LNCC) Celso Mendes (UIUC) Cesar De Rose (PUCRS) Claudio Geyer (UFRGS) Cristina Boeres - UFF Edmundo Madeira (UNICAMP) Esther Pacitti (INRIA & LIRMM) Fabio Costa (UFG) Fabíola Greve (UFBA) Fabricio Alves Barbosa da Silva (CETEX) Francisco Brasileiro (UFCG) Francisco José da Silva e Silva (UFMA) Helio Guardia (UFSCar) Jose Maria Monteiro (UFC) Jose Neuma de Souza (UFC) Karin Breitman (PUC-Rio) Leonel Sousa (TU Lisboa, PT) Lucia Drummond (UFF) Luis Carlos De Bona (UFPR) Marcelo Pasin (TU Lisboa, PT) Markus Endler (PUC-Rio) Marta Mattoso (UFRJ) Philippe Navaux (UFRGS) Raphael Camargo (UFABC) Rossana M. de Castro Andrade (UFC) Vinod Rebello (UFF) Wagner Meira, Jr. (UFMG) Walfredo Cirne (Google)

12 IX Workshop em Clouds, Grids e Aplicações xi Revisores do WCGA Alexandre Gonçalves (UFF) Alexandre Lima (UFRJ) Alfredo Goldman (USP) Andre Lage (IRISA) Antônio Roberto Mury (LNCC) Antônio Tadeu A Gomes (LNCC) Artur Ziviani (LNCC) Carlos Senna (UNICAMP) Celso Mendes (UIUC) Cesar De Rose (PUCRS) Claudio Geyer (UFRGS) Cristina Boeres - UFF Daniel de Oliveira (UFRJ) Edmundo Madeira (UNICAMP) Emanuel Coutinho (UFC) Esther Pacitti (INRIA & LIRMM) Fabio Costa (UFG) Fabíola Greve (UFBA) Fabricio Alves Barbosa da Silva (CETEX) Francisco Brasileiro (UFCG) Francisco José da Silva e Silva (UFMA) Gustavo Baptista (PUC-Rio) Helio Guardia (UFSCar) Javam Machado (UFC) Jonas Dias (UFRJ) Jose Antonio Macedo (UFC) Jose Maria Monteiro (UFC) Jose Neuma de Souza (UFC) Juliana Nascente Silva (UFF) Karin Breitman (PUC-Rio) Leonel Sousa (TU Lisboa, PT) Lucia Drummond (UFF) Luis Carlos De Bona (UFPR) Luiz Fernando Bittencourt (UNICAMP) Marcelo Pasin (TU Lisboa, PT) Marcelo Neves (PUCRS) Markus Endler (PUC-Rio) Marta Mattoso (UFRJ) Nicolas Maillard (UFRGS) Philippe Navaux (UFRGS) Raphael Camargo (UFABC) Rossana M. de Castro Andrade (UFC) Rostand Costa (UFPB) Vinod Rebello (UFF) Wagner Meira, Jr. (UFMG) Walfredo Cirne (Google)

13 xii Anais

14 IX Workshop em Clouds, Grids e Aplicações xiii Sumário Sessão Técnica 1 Infraestrutura Virtualizada... 1 Comparativo de Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional em Condições Similares David Willians S. C. Beserra, Samuel Carlos Romeiro Azevedo Souto, Mariel José Pimentel de Andrade e Alberto Einstein Pereira de Araujo (UFRPE)... 3 Uma Arquitetura para Gerência de Identidades em Nuvens Híbridas Guilherme Feliciano, Lucio Agostinho, Leonardo Olivi (UNICAMP), Eliane G. Guimarães (Centro de Tecnologia da Informação Renato Archer) e Eleri Cardozo (UNICAMP) Virtual Machine Networking for Distributed Systems Emulation Mauro Storch (Instituto de Pesquisas Eldorado), Rodrigo N. Calheiros (Universidade de Melbourne) e César A. F. de Rose (PUCRS) Sessão Técnica 2 Infraestrutura em Aplicações Modelagem Conceitual de um Integrador para Simulação Hemodinâmica em Grid Ramon G. Costa, Paulo G. P. Ziemer, Antônio Tadeu A. Gomes, Bruno Schulze, Pablo J. Blanco e Raúl A. Feijóo (LNCC) Construindo Infraestruturas Computacionais Distribuídas e Seguras Baseadas em Receptores de TV Digital Rostand Costa, Giuliano Maia, Guido Lemos de Souza Filho, Dênio Mariz Sousa (UFPB) e Francisco Brasileiro (UFCG) Avaliação do Custo por Usuário de uma Aplicação de Rede Social na Amazon EC2 Matheus Cunha, Nabor Mendonça e Américo Sampaio (UNIFOR) Sessão Técnica 3 Desempenho, Ferramentas e Modelos Improving Performance of Information Quality Applications: A Scale-Out Approach Gustavo Frainer, Luiz Carlos Ribeiro Junior, Mauro Storch (Acxiom Brasil) e Rodrigo Fernandes de Mello (USP) CloudReports: Uma Ferramenta Gráfica para a Simulação de Ambientes Computacionais em Nuvem Baseada no Framework CloudSim Thiago Teixeira Sá, José Marques Soares e Danielo G. Gomes (UFC) Estimando o Valor de uma Grade Entre Pares para a Execução de Aplicações do Tipo Saco de Tarefas Edigley Fraga, Francisco Brasileiro e Dalton Serey (UFCG)

15 xiv Anais Sessão Técnica 4 Gerência e QoS Sistemas de Armazenamento Compartilhado com Qualidade de Serviço e Alto Desempenho Pedro Eugênio Rocha e Luis Carlos Erpen de Bona (UFPR) Performance Evaluation of Distributed Data Access Optimization Approaches: Experiments versus Simulations Vinicius de Freitas Reis e Rodrigo Fernandes de Mello (USP) Proposta de Workflow para Alocação de Máquinas Virtuais Utilizando Características de Processamento Paulo Antônio Leal Rego, Emanuel Ferreira Coutinho e José Neuman de Souza (UFC) Aplicação de Algoritmos de Provisionamento Baseados em Contratos de Nível de Serviço para Computação em Nuvem Fernando Schubert, Carlos Oberdan Rolim (URI) e Carlos Becker Westphall (UFSC) Índice por Autor

16 IX Workshop em Clouds, Grids e Aplicações Sessão Técnica 1 Infraestrutura Virtualizada

17

18 IX Workshop em Clouds, Grids e Aplicações 3 Comparativo de desempenho de um cluster virtualizado em relação a um cluster convencional sob condições equipotentes David Willians S.C Beserra 1, Samuel Carlos Romeiro Azevedo Souto 1, Mariel José Pimentel de Andrade 1, Alberto Einstein Pereira de Araujo 1 1 Unidade Acadêmica de Garanhuns Universidade Federal Rural de Pernambuco (UFRPE) Garanhuns PE Brazil Abstract. In this work we presents a comparative study of the performance of a cluster of real machines relative to a cluster of virtual machines. Both structures have theoretical equality in your hardware and software configurations. The work was accomplished to evaluate if the structures present similar performance in similar conditions. Our goal is verify the possibility of implement a Beowulf cluster through virtual structures in work stations which are underused, using the maximum of its capacity of processing. Resumo. Neste trabalho nós apresentamos um estudo que compara um cluster de máquinas reais com um cluster de máquinas virtuais. Ambas as estruturas têm igualdade teórica em configurações de hardware e de software. O trabalho foi realizado para avaliar se as estruturas apresentam desempenho semelhante em condições semelhantes. Nossa meta é verificar a possibilidade do uso de um cluster Beowulf por estruturas virtuais em estações de trabalho que são subutilizadas, usando o máximo de sua capacidade de processamento. 1. Introdução e Trabalhos Relacionados Na atualidade, diversos setores da atividade humana têm demandado por elevado poder de processamento e armazenamento de dados. Embora setores econômicos e governamentais demandem cada vez mais por tais recursos, ainda é na ciência em que esse tipo de demanda se concentra. Os Supercomputadores foram à primeira iniciativa para prover alto poder de computação, todavia são onerosos e pouco escalonáveis. Como alternativa aos Supercomputadores convencionais surgiu o Cluster Beowulf, que provê computação de alto desempenho (HPC) a baixo custo já que utiliza commodities como componentes [Sterling et al. 1995]. Um C luster Beowulf é constituído por um agrupamento de máquinas (nodos) interligadas por uma rede, tendo um nodo a função de gerente do ambiente (frontend) e os demais sendo apenas escravos que executam instruções provenientes do frontend. Alem da necessidade da concepção de arquiteturas de computadores direcionadas para HPC, existe à necessidade de se aproveitar melhor os recursos físicos já disponíveis. Uma maneira encontrada para se prover essa otimização surgiu com o advento da virtualização, que é uma tecnologia que permite executar mais de um

19 4 Anais Sistema Operacional (SO) em um mesmo hardware [National Instruments 2010]. Existem basicamente duas formas de realizar a virtualização: A Virtualização Total e a Paravirtualização. Atualmente em alguns ambientes como laboratórios de informática com fins educacionais ou mesmo ambientes de escritórios, a capacidade de processamento de máquinas atuais é subaproveitada, surge então um questionamento a respeito da sua utilização em HPC através da virtualização. Na Virtualização Total, o SO convidado não sabe que está sendo executado em um ambiente virtualizado, o que também é denotado por Máquina Assistida por Hardware Virtual (HVM). A virtualização completa exige que o Gerenciador de Máquinas Virtuais (VMM) intercepte muitas operações que um SO costuma executar diretamente no hardware. A vantagem desse método é a garantia de que o convidado não interferirá no sistema hospedeiro, lendo ou modificando a memória alocada para ele, nem desligando a CPU que está utilizando [Zhao et al. 2009]. Na Paravirtualização, um SO convidado esta ciente da camada de virtualização e modifica-se para apoiá-la, resultando em maior desempenho do sistema virtual. O SO convidado paravirtualizado é portado para rodar em cima do VMM, usando rede virtual, disco e dispositivos de console. Ele deve trabalhar colaborativamente com a camada do VMM. Domínios do cliente podem ser parcialmente ou totalmente virtualizados, e um sistema pode ter os dois tipos de execução simultaneamente [Zhao et al. 2009]. Logo, uma alternativa para economia de custos e amplificação de desempenho para HPC é a virtualização de Clusters Beowulf, que podem conviver dentro de outras infraestruturas de computação, inclusive na nuvem, tendo a implementação de um destes descrita por [Ivica et al. 2009]. Todavia, segundo [Mello et al. 2010] uma questão importante que não pode ser ignorada é o impacto da virtualização sobre o ambiente de HPC. Uma forma de medir o desempenho de um Cluster Beowulf é mediante o uso de ferramentas de benchmarking [Silva et al. 2009], que podem ser também aplicadas em seus correspondentes virtuais e são de grande auxilio no estudo dos impactos da virtualização no desempenho. Em [Huang et al. 2006] temos um benchmarking de um cluster virtual realizado com enfoque no desempenho de rede e de bibliotecas de paralelização de código, onde o SO nativo e o virtualizado concorrem por todos os recursos disponíveis, obtendo bom desempenho, mas com perdas devido ao compartilhamento de recursos de rede, já [Ranadive et al. 2008] verifica os efeitos da partilha de recursos sobre o desempenho de aplicações de HPC. Especificamente, para várias máquinas virtuais (VMs) em execução em plataformas multicore, foi avaliada a extensão em que suas comunicações são afetadas pelo fato de que eles compartilham um único recurso de comunicação, utilizando uma interconexão Infiniband como o exemplo concreto de tal recurso. Os resultados experimentais apresentados demonstram que um alto nível de compartilhamento, ou seja, um número significativo de máquinas virtuais implantadas para cada nó é viável sem degradação de desempenho notável. Também foram realizados estudos para verificar se um sistema para HPC virtualizado e tendo como infraestrutura hospedeira à nuvem poderia fazer parte do ranking dos 500 mais poderosos sistemas computacionais existentes, o TOP 500 [Napper and Bientinesiy 2009]. Eles indicaram que ainda não existe maturidade suficiente na tecnologia de nuvem que permita que ela seja usada em aplicações HPC

20 IX Workshop em Clouds, Grids e Aplicações 5 com boa relação custo-beneficio (RCB), sendo muito ineficientes em relação a sistemas HPC tradicionais, mas que, com o avanço das tecnologias de interconexão de computadores, este cenário pode ser alterado e em um futuro próximo poderão ser ofertados serviços HPC na infraestrutura da nuvem com qualidade comparável aos tradicionais e com RCB aceitável [Napper and Bientinesiy 2009]. A proposta deste trabalho é verificar a viabilidade da implementação de um Cluster Beowulf dentro de outra infraestrutura, observando a ocorrência de impactos no desempenho da infraestrutura hospedeira e se existem diferenças notáveis de desempenho entre um cluster real e um virtual sobre condições equiparáveis. O restante do trabalho está subdividido pela convenção a seguir: Na próxima seção são expostos os objetivos e a metodologia de analise. Na seção subseqüente tem-se a exposição e analise dos resultados e na seção 4 são dispostas as conclusões e os trabalhos futuros. 2. Objetivos e Metodologia de Analise Os testes realizados tentam determinar valores de desempenho de processamento sustentado em termos de Bilhões de Operações de Ponto Flutuante por Segundo (GFLOPS) e vazão média em Mega Bits por Segundo (Mbps), bem como a vazão média em função do tamanho do pacote de dados utilizado, com tamanho especificado em Bytes. Para a realização dos testes de desempenho de processamento sustentado foi o High Performance Linpack (HPL), já para os testes de capacidade de comunicação foi empregado o NetPIPE (Network Protocol Independent Performance Evaluator) Objetivos Os testes realizados foram estruturados de acordo com os seguintes objetivos: 1. Verificar a diferença de desempenho de um cluster de máquinas virtuais em relação a um cluster de máquinas reais com configurações de hardware e software similares. 2. Verificar o impacto da execução de uma máquina virtual em capacidade máxima sobre o desempenho do SO da máquina hospedeira, observando a percentagem de uso de CPU pelo hospedeiro no momento da execução da VM Infraestrutura de Equipamentos e Opções Arquiteturais Neste experimento foram empregados 7 computadores padrão IBM-PC, com arquitetura de processador do tipo x86, sendo 3 destes equipados com processador Q8200 e 4 com processador E6550. Mais detalhes sobre a configuração individual de cada computador são apresentados na Tabela 1. Processador Tabela 1. Configuração dos computadores utilizados Qtde. núcleos Frequência Memória Frequência E GHz 1 GB 667 MHz Q GHz 2 GB 667 MHz

21 6 Anais Cluster de Máquinas Reais Nodos computacionais O cluster com máquinas reais foi implementado com o uso de quatro computadores, todos com processador E6550 e com a quantidade de 1 GB para a memória principal Rede de interconexão Para a interconexão entre o frontend e os nos escravos foi utilizada uma rede Fast Ethernet, de alta latência e baixo custo, com banda de 100 Mbps. Todos os nós possuem uma placa de rede com chip RTL8139 e estão interconectados por um roteador Intelbras WRG 240 E Cluster de Máquinas Virtuais Nodos Computacionais Neste cluster, o frontend também é um computador real com processador E6550. Já os escravos são máquinas virtuais instaladas em 3 computadores reais equipados com o processador Q8200, pertencentes a um laboratório de ensino. Cada máquina real utilizada (máquina hospedeira) tem como SO nativo o Windows Vista Ultimate de 32 bits. Em cada máquina hospedeira foi instalada uma máquina virtual configurada com duas vcpus (processadores virtuais) e 1 GB de memória principal alocada para si. Observe que cada máquina virtual possui configuração teórica similar as máquinas constituintes do cluster real, possuindo a mesma quantidade de núcleos de processamento e memória principal, onde cada núcleo e a memória possuem também a mesma frequência que a do cluster real. Os núcleos e a memória restante ficam para o SO das máquinas hospedeiras e seus aplicativos e, embora o SO do hospedeiro continue a enxergar os núcleos alocados para a VM, não os utiliza (o escopo de visualização dos núcleos nas máquinas hospedeiras é apresentado graficamente na Figura 1). Todavia, se uma máquina virtual estiver ociosa, os recursos alocados a ela podem ser gradativamente liberados para o uso pelo SO nativo da máquina real. Figura 1. Escopo de visualização dos núcleos do processador

22 IX Workshop em Clouds, Grids e Aplicações Rede de interconexão Para assegurar a igualdade de condições entre os dois clusters, os mesmos padrões e equipamentos de rede utilizados no cluster real foram empregados no cluster de máquinas virtuais. Vale salientar que, como as máquinas hospedeiras possuem apenas uma placa de rede, o seu SO nativo e a máquina virtual, (também através de seu SO), acabam concorrendo pelos recursos de rede. Para evitar que isso ocorra e continuar mantendo a igualdade teórica de configurações entre as duas plataformas de cluster, não foi configurada uma rede local Windows entre as máquinas hospedeiras, existindo apenas a rede do cluster virtual, que não é enxergada pelo SO nativo dos hospedeiros Ferramenta de Cluster e Monitoração O sistema operacional Rocks Cluster 5.4 [NSF 2011], em sua versão de 32 bits, foi o escolhido para a implementação de ambos os clusters. Sua principal meta é auxiliar na implementação rápida de Clusters Beowulf, possuindo assim um processo de instalação simplificado para frontend e escravos. Uma vez instalado o frontend, os escravos podem ser adicionados mediante um simples comando de terminal. A instalação do frontend é feita com o DVD do Rocks e a dos escravos via PXE (boot remoto via rede). Ao contrario de outras ferramentas de cluster, como o PelicanHPC [Creel 2011], o Rocks necessita que as máquinas hospedeiras do sistema possuam disco rígido, o que, embora consuma mais espaço, torna o sistema mais seguro e estável, em contrapartida a sistemas RAMDISK (que tratam a memória alocada para seu funcionamento como um disco), que são mais instáveis, tendo como exemplo o supracitado PelicanHPC. Para o gerenciamento de carga de processamento dos nós, fluxo de rede e outras atribuições importantes, foi utilizado o visualizador gráfico de recursos de cluster Ganglia, disponível no Rocks como um de seus Rolls (pacotes do Rocks). Ele é automaticamente instalado quando selecionado no processo de instalação do frontend Ferramenta de Virtualização Para a configuração e criação das máquinas virtuais empregadas no experimento foi utilizado o virtualizador proprietário VMware Workstation [VMware 2011]. Sua escolha foi motivada pelo fato de outros virtualizadores disponíveis (notadamente o VirtualBox e o Virtual PC) para plataforma Windows não permitirem a criação de máquinas virtuais multicore, exceto se o hardware dispor de instruções especificas para virtualização. O VMware Workstation é um sistema de Virtualização Total, muito embora disponibilize como opção a habilitação de um conjunto de instruções de Paravirtualização, que não foram empregadas Ferramentas de Benchmarking Desempenho de transmissão de dados O NetPIPE é um avaliador de desempenho para uma rede local e possui total independência do tipo de protocolo empregado na rede, permitindo monitorar a sobrecarga (overhead) proveniente de camadas protocolares superiores. Ele permite

23 8 Anais medir o desempenho com maior profundidade de diversas tecnologias de rede, transferindo tamanhos de blocos que podem ser posteriormente analisados com maior detalhamento [Pitanga 2008]. Como pode ser utilizado com diferentes protocolos, basta especificar o protocolo durante o processo de compilação. Neste trabalho, o protocolo escolhido foi o MPI (Interface de Passagem de Mensagens). Em sua execução, o NetPIPE gera por padrão um arquivo nomeado np.out que armazena os resultados obtidos. O arquivo contem 3 colunas: o numero de bytes por pacote, a vazão (throughput) em Mbps e o tempo de ida e volta das mensagens de teste dividido por 2. As duas primeiras colunas são empregadas para a obtenção de um gráfico da vazão pelo tamanho do pacote e a segunda para se obter a vazão media da rede. [Yowa University 2011] Desempenho de processamento sustentado Para a obtenção do desempenho de processamento sustentado de ambos os clusters foi utilizado o pacote HPL, que é a ferramenta padrão para a realização de medições de desempenho de processamento de supercomputadores utilizada pelo projeto TOP 500 [TOP ] Funcionamento, Configuração e Execução do HPL O HPL [Silva et al. 2009] resolve um sistema de equações lineares do tipo A.x=b, onde A é a matriz dos coeficientes que é gerada estocasticamente pelo programa e possui tamanho N x N. x e b possuem dimensão N. O primeiro passo para a resolução do sistema a ser aplicado pelo HPL é a fatoração da matriz A como sendo o produto A=L.U, onde L e U representam respectivamente as matrizes triangulares inferior e superior. A fatoração é realizada mediante pivotamento parcial de linha, por ser um método mais estável. Por fim, o algoritmo encontra a solução x através da aplicação sucessiva de passos de solução triangular, L.z=b e por fim U.x=z. A matriz A, componente do sistema em questão, tem seus elementos distribuídos por uma grade bidimensional de processos P x Q de maneira cíclica. Por sua vez, a matriz de coeficientes (dimensão N x N+1) é particionada em blocos de tamanho NB x NB, também distribuídos ciclicamente na grade de processos supracitada. Na Figura 2 é possível ver essa distribuição para 6 processos, que foi a quantidade utilizada nos testes. Cada elemento Aij corresponde a uma submatriz de dimensão NB x NB. Esse procedimento é executado em todas as dimensões da matriz para assegurar principalmente a escalabilidade algorítmica e um bom balanceamento de carga. Figura 2. Distribuição dos blocos lógicos da matriz na grade de processos

24 IX Workshop em Clouds, Grids e Aplicações 9 O HPL deve ser configurado em função da arquitetura dos processadores utilizados nos nodos do cluster (daí é extremamente importante todos os nós possuírem o mesmo tipo de processador). Essa configuração é feita em um arquivo a parte com o nome da arquitetura, seguindo padrões estabelecidos pelo HPL. Neste experimento, para ambos os clusters, o HPL foi compilado através do arquivo ia32.arch. Para a correta execução do HPL do ponto de vista de avaliação é necessário configurar um arquivo nomeado HPL.dat, que fica localizado no diretório onde foi compilado o HPL para o cluster em questão. Neste arquivo devem ser descritos o valor da ordem N da matriz, o valor de P e Q, que devem ser dois números cujo produto resulte na quantidade total de processadores, e o valor de NB, entre outros parâmetros. [Advanced Clustering 2011] oferece um mecanismo em uma pagina web que gera automaticamente um arquivo HPL.dat adequado para qualquer cluster. As informações necessárias, que devem ser passadas como parâmetro na página web, são a quantidade de nodos, o número de cores por nodo e a quantidade de memória principal por nodo. Na configuração do HPL para este experimento foram considerados apenas os nós escravos, ficando o frontend responsável unicamente pelo gerenciamento e monitoramento do cluster. Uma visualização do arquivo HPL.dat utilizado é fornecida na Figura Testes e Medidas Realizados Figura 3. Arquivo HPL.dat utilizado Nessa análise foram realizadas 30 medições por teste. Sendo apresentados o cômputo da média e o intervalo de confiança para os testes de desempenho de processamento sustentado e de desempenho de transmissão de dados. 1. Teste 1 Teve como objetivo obter a medida de desempenho sustentado de processamento do cluster implementado unicamente com máquinas físicas. Os resultados desse foram empregados como comparação aos resultados do teste Teste 2 Esse teste teve como objetivo medir o desempenho de processamento do cluster de máquinas virtuais.

25 10 Anais 3. Teste 3 - Teve como objetivo medir a capacidade de transmissão de dados no cluster real. Os resultados deste teste serão comparados com os do teste Teste 4 O objetivo é medir a capacidade de transmissão de dados no cluster virtual. 3. Analise dos Resultados As medidas de desempenho médio de processamento sustentado realizadas com o HPL para os testes 1 e 2 são apresentadas na Figura 4, com um intervalo de confiança de 95%. Para o cluster de máquinas virtuais foi obtido um desempenho de processamento sustentado médio de 13,02 GFLOPS, ficando 1,53% superior ao cluster de máquinas reais de configuração análoga, que obteve um desempenho médio de 12,81 GFLOPS. Já as medidas relacionadas à capacidade de comunicação relativas aos testes 3 e 4 são apresentadas nas figuras 5,6 e 7, também com intervalo de confiança de 95%. Foram analisadas a vazão média (Figura 5) e a vazão média em função do tamanho do pacote de dados utilizado, sendo apresentados os resultados individuais para cada cluster na Figura 6 e um comparativo entre os desempenhos de ambas as estruturas na Figura 7. Na vazão média foi observada uma diferença de 21% em favor do cluster real. No quesito vazão média em função do tamanho do pacote de dados, o cluster real apresenta um crescimento mais elevado da capacidade média de vazão em relação ao seu correspondente virtual (Figura 7), tendo melhor desempenho para pequenas quantidades de dados. Todavia, à medida que a quantidade de dados dos pacotes aumenta, seus desempenhos vão se aproximando, de forma que, com uma grande quantidade de dados, se equiparam. Quanto ao fato da diferença entre os dois clusters ser levemente a favor do cluster de máquinas virtuais, quando em vários outros experimentos, como nos realizados por [Zhao et al. 2009] e [Mello et al. 2010] serem bruscamente menores devido ao uso de Virtualização Total, pode ser atribuído ao fato de neste experimento o cluster virtual ser executado utilizando apenas 50% da capacidade do hospedeiro, sem necessitar competir por recursos com o mesmo e, ocasionalmente, como o hospedeiro não estava executando aplicativos extras, como antivírus, suítes de escritório e ferramentas de desenvolvimento, apenas seu próprio SO e a máquina virtual, é possível que o SO do hospedeiro tenha alocado mais recursos para o processamento das instruções da máquina virtual, ampliando levemente seu desempenho. As pequenas divergências verificadas no desempenho de rede para os pacotes pequenos são ocasionadas pelo compartilhamento de uma única interface de rede entre o hospedeiro e o sistema convidado, mesmo que o hospedeiro não esteja conectado a outra rede. Porém, de uma maneira geral, como a diferença de desempenho não foi muito significativa, é conveniente afirmar que os dois clusters obtiveram desempenho real equivalente sobre as mesmas configurações, apresentando na prática o que era esperado em teoria.

26 IX Workshop em Clouds, Grids e Aplicações 11 Figura 4. Desempenho de processamento sustentado Figura 5. Vazão média da rede Figura 6. Vazão média x tamanho do pacote de dados Figura 7. Comparativo da vazão média x tamanho do pacote de dados entre os clusters real e virtual Durante a execução do HPL no cluster virtual foi observado através do Ganglia que todos os nodos faziam uso médio de 95% de suas CPUs, como indicado na Figura 8. Durante a execução do experimento foi visualizada, mediante o gerenciador de

27 12 Anais tarefas do Windows, em todas máquinas hospedeiras dos nodos do cluster virtual a percentagem de uso de CPU, sendo constatado que de fato, o SO do hospedeiro sempre se encontrava fazendo uso de aproximadamente 50% dos recursos de CPU, oscilando um pouco entre 49-52%, tal como era esperado, já que praticamente não haviam softwares aplicativos extras em execução no hospedeiro, tendo apenas o nodo virtual em execução justamente para ser observado o seu impacto no uso de CPU. Figura 8. Uso de CPU pelo cluster virtual Foi observado também que a carga de processamento não se concentrou nos dois núcleos teoricamente reservados a VM, sendo distribuído entre todas as CPUs de maneira aproximadamente equivalente, com cada uma apresentando um uso próximo dos 25% (vide Figura 9). Esse particionamento também pode ter colaborado para o leve superavit de performance a favor do cluster de máquinas virtuais. 4. Conclusões e Trabalhos Futuros Figura 9. Uso de CPU no host hospedeiro A pesquisa acima descrita levantou um conjunto de questionamentos relacionados ao uso de ambientes virtualizados para HPC e, de uma maneira mais especifica, sobre os impactos da virtualização no desempenho quando ambas as estruturas possuem configurações similares. Foi mostrado nesse estudo que, para as condições acima descritas é possível implementar um ambiente de cluster dentro de uma infraestrutura com propósito original diferenciado que não seja o uso para um ambiente HPC, cluster esse que mantém um desempenho similar ao de seu correspondente real. Isso faz com que possa ser aproveitada a capacidade ociosa das máquinas ou que ambas as estruturas possam coexistir em uso simultâneo, uma vez que, conforme observado, o cluster virtual só

28 IX Workshop em Clouds, Grids e Aplicações 13 utiliza os recursos que lhe foram alocados, podendo o restante dos recursos serem utilizados livremente. As principais vantagens obtidas no emprego de múltiplas infraestruturas nos mesmos equipamentos físicos são a economia espacial obtida com a redução da quantidade de máquinas necessárias e a economia de recursos financeiros, uma vez que o custo proporcional por núcleo é reduzido em função do aumento da quantidade de núcleos por máquina. Como trabalhos futuros a serem realizados serão realizados testes para verificar o impacto do virtualizador empregado no desempenho de processamento sustentado e no desempenho de rede de um cluster virtual, bem como em relação a clusters reais equivalentes. Outro estudo em pauta é o do impacto do uso de outros SOs nas máquinas hospedeiras, como o Linux, no desempenho de processamento do cluster virtual. Permutações dessas variáveis também serão realizadas com o propósito de se descobrir qual a melhor combinação possível de SO e virtualizador para a implementação desse modelo de cluster. Serão observados os efeitos do emprego do uso das instruções de Paravirtualização no desempenho e, em todos esses casos, pretende-se observar também o efeito do uso simultâneo das duas estruturas sobre o mesmo hardware para observar a ocorrência, ou não, de impactos no desempenho da execução das aplicações dos hospedeiros ou de impactos no desempenho dos nodos virtuais, para determinar mais precisamente o grau de viabilidade da adoção de clusters virtuais como forma de aproveitar o desempenho ocioso das grandes estruturas computacionais disponíveis nos ambientes corporativos e acadêmicos. Os autores agradecem o apoio financeiro das agências de fomento: Fundação da Amparo a Ciência e Tecnologia de Pernambuco FACEPE, ao CNPq e a UAG/UFRPE pelo uso do laboratório de informática. Referencias Advanced Clustering. (2011) How Tune my HPL.dat file?, March. Becker, D. J., Sterling, T., Savarese, D., Dorband, J. E., Ranawak, U. A., Packer, C. V. (1995) Beowulf: A parallel Workstation for Scientific Computation, In: Proceedings of the 1995 International Conference on Parallel Processing, August 14-18, 1995, Urbana-Champain, Illinois, USA. Volume I: Architecture. pp CRC Press, ISBN X Creel, M. (2011) PelicanHPC tutorial, January. Huang, W., Liu, J., Abali, B., Panda, D.K. (2006) A case for high performance computing with virtual machines, In: Proceedings of the International Conference on Supercomputing, pp Iowa State University. (2011) NetPIPE README February.

29 14 Anais Ivica, C., Riley, J.T., Shubert, C. (2009) StarHPC - Teaching parallel programming within elastic compute cloud, In: Proceedings of the International Conference on Information Technology Interfaces, ITI, pp Mello, T. C., Schulze, B., Pinto, R. C. G., Mury, A. R. (2010) Uma análise de recursos virtualizados em ambiente de HPC, In: Anais do VIII Workshop em Clouds, Grids e Aplicações, em conjunto com o XXVIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, pp Napper, J., Bientinesiy, P. (2009) Can cloud computing reach the TOP500?, In: Proc. Combined Workshops on UnConventional High Performance Computing Workshop Plus Memory Access Workshop, UCHPC-MAW '09, Co-located with the 2009 ACM Int. Conf. on Computing Frontiers, CF'09, pp National Instruments. (2011) Introdução à Virtualização, ftp://ftp.ni.com/pub/devzone/pdf/tut_9897.pdf, February. NSF. (2011) Base Roll: Users Guide, January. Alves, M., J., P. (2008) Construindo Supercomputadores com Linux, 3 Edição, Brasport, pp Ranadive, A., Kesavan, M., Gavrilovska, A., Schwan, K. (2008) Performance implications of virtualizing multicore cluster machines, In: 2nd Workshop on System-level Virtualization for High Performance Computing, HPCVirt 2008, held in conjunction with EuroSys 2008, pp. 1-8 Silva, V., Bentes, C., Guedes, S., Silva, G. P. (2009) Arquitetura e Avaliação do Cluster de Alto Desempenho Netuno, In: Anais do WSCAD-SSC 2009 X Simpósio em Sistemas Computacionais, em conjunto com o Simpósio Brasileiro de Arquiteturas Computacionais e Processamento de Alto Desempenho 2009, pp TOP500. (2011) The Linpack Benchmark, March. VMware. (2011). Guest Operating System Installation Guide, February. Zhao, T., Ding, Y., March, V., Dong, S., See, S. (2009) Research on the performance of xvm virtual machine based on HPCC, In: 4th ChinaGrid Annual Conference, ChinaGrid 2009, pp

30 IX Workshop em Clouds, Grids e Aplicações 15 Uma Arquitetura para Gerência de Identidades em Nuvens Híbridas Guilherme Feliciano 1, Lucio Agostinho 1, Leonardo Olivi 1, Eliane G. Guimarães 2, Eleri Cardozo 1 1 Faculdade de Engenharia Elétrica e de Computação Universidade Estadual de Campinas - UNICAMP 2 Centro de Tecnologia da Informação Renato Archer Campinas - SP Abstract. Cloud computing offers a new paradigm to bring higher flexibility, higher reliability, and lower costs regarding the usage of computing resources. Although this approach leads to new business opportunities, the issue of security (specifically access control and identity management) is still an open and difficult to solve problem. This paper presents an architecture that provides federated identity management for hybrid clouds. The main contribution of this paper is a layered architecture for federated access control, where each layer is distributed in virtual machines. The OpenAM middleware was extended to include new services within the internal cloud network. Resumo. A computação em nuvem oferece um novo paradigma para trazer maior flexibilidade, maior confiabilidade e menores custos com relação ao uso de recursos computacionais. Apesar desta abordagem levar a novas oportunidades de negócios, a questão da segurança (especificamente controle de acesso e gerência de identidades) ainda é um problema em aberto e de difícil solução. Este artigo apresenta uma arquitetura que contempla a gerência de identidades federadas em uma nuvem híbrida. A principal contribuição do trabalho é o controle de acesso federado, onde cada camada da arquitetura está distribuída em máquinas virtuais. O middleware OpenAM foi estendido para incluir novos serviços junto à rede interna da nuvem. 1. Introdução Na Internet de hoje é comum que os usuários tenham várias contas (identidades), que se traduzem em várias regras e diferentes permissões de acesso em cada um dos sites que visitam. Esta realidade acaba prejudicando a experiência de navegação do usuário, uma vez que o mesmo necessitará de várias contas nos diferentes sites. Com o surgimento da computação em nuvem os administradores de sistemas, por outro lado, têm agora que gerenciar estas contas sendo que, muitas vezes, estão replicadas para cada aplicação oferecida como serviço [Olden 2011]. Outro desafio é a natureza colaborativa que as aplicações em nuvem oferecem. Isto traz também problemas de segurança, uma vez que a nuvem precisa tratar questões como autenticação e autorização de identidades muitas vezes vindas de aplicações parceiras.

31 16 Anais No setor acadêmico, ambientes de nuvem geralmente pertencem a domínios privados mantidos por centros de pesquisa nas universidades. Muitas vezes, nestes domínios, estão recursos cujo acesso pode ser realizado via Internet. Neste caso, é essencial que existam mecanismos para prover a autenticação e a autorização de usuários no acesso aos recursos, tanto para usuários vindos do próprio domínio, quanto de outras localidades. Esta questão possibilta uma interoperabilidade de recursos provindos de domínios distintos, habilitando então a cooperação entre centros de pesquisa parceiros. Para que a cooperação seja realizada com êxito, as entidades parceiras devem definir políticas para o compartilhamento de recursos junto aos domínios federados. Esse processo envolve mecanismos de SSO (Single Sign-On) para que, uma vez que o usuário esteja autenticado em seu domínio de origem, ele possa acessar recursos em quaisquer outros domínios federados, desde que esse usuário esteja inserido no contexto de autorização do domínio em questão. Em domínios não-federados, o mesmo usuário precisaria ter credenciais em ambos os domínios para ter permissões de acesso aos recursos distribuídos [Cao and Yang 2010]. Este artigo apresenta como principal contribuição uma arquitetura para gerência de identidades distribuída com autenticação federada de identidades, autorização e SSO. Essa arquitetura é voltada para ambientes de computação em nuvem híbrida, notadamente para a integração de domínios privados e distintos que provêem acesso a recursos robóticos. O objetivo é apresentar um modelo para realizar o controle de acesso de domínios em nuvem, mas que estão inseridos em diferentes níveis de acesso: público e privado. Esse modelo é validado na plataforma REALcloud [Rocha et al. 2011] para promover SSO entre os diferentes sites de gerência nesta nuvem híbrida. O ambiente também oferece mecanismos para o acesso aos recursos da rede privada por meio de uma nuvem pública. O artigo está organizado da seguinte forma: a seção 2 aborda os principais conceitos relacionados a gerência de identidades. A seção 3 apresenta a plataforma REALcloud, onde a arquitetura proposta está inserida. Na seção 4 é apresentado um estudo de caso no domínio da robótica em rede. Nas seções 5 e 6 apresenta-se os trabalhos relacionados, as conclusões e trabalhos futuros, respectivamente. 2. Conceitos sobre Gerência de Identidades Nesta seção são apresentados os principais conceitos relacionados a gerência de identidades. Os conceitos de usuário, identidade e credenciais relacionam-se com o sujeito e sua identificação em um dado contexto. Os conceitos de autenticação e autorização relacionase com mecanismos para aplicar o controle de acesso. Federação refere-se a mecanismos para criação de parcerias com o objetivo de promover o compartilhamento de recursos. O SSO refere-se à maneira como o usuário de um serviço compartilhado pode se autenticar sem ter que utilizar inúmeras credenciais. A gerência de identidades trata então de oferecer um controle de acesso (autenticação e autorização) federado, oferecendo ao usuário uma experiência de SSO e ao administrador a provisão de contas (distribuídas entre diversas bases do domínio) e auditoria do sistema [Olden 2011] Usuário, Identidade e Credenciais Um usuário pode ser caracterizado como um cliente ou entidade (host/aplicação) que quer obter algum serviço de um provedor. O usuário pode ser uma pessoa utilizando um agente

32 IX Workshop em Clouds, Grids e Aplicações 17 de interface (por exemplo, navegador Web) ou um sistema computacional (por exemplo, web services). Um requisito necessário para que o usuário possa obter um recurso de um provedor é possuir uma identidade que o represente. O conceito de identidade, segundo [Cao and Yang 2010], é difícil de precisar, uma vez que a definição de identidade está relacionada ao ambiente onde é empregada, a contextos semânticos e a casos de uso. Como uma definição mais geral, podemos dizer que uma identidade é uma representação de uma entidade em um contexto particular [El Maliki and Seigneur 2007]. Uma identidade consiste de identificadores e credenciais de usuários. Uma credencial é um atestado de qualificação, competência ou autoridade, expedida a um indivíduo por terceiros com autoridade relevante ou competência para tal ato. Na computação, exemplos de credenciais incluem certificados digitais X.509 assinados por uma autoridade certificadora (CA), usuário e senha, one time password (OTP), tokens, entre outros Controle de Acesso (Autenticação e Autorização) O processo de verificar a existência de uma identidade é chamado de autenticação. Para que tal processo se inicie é necessário que o usuário forneça uma credencial válida para o método de autenticação utilizado pela entidade autenticadora. De posse da credencial válida, a entidade autenticadora poderá verificar em sua base de identidades se há alguma identidade cuja credencial seja a fornecida pelo usuário. Caso a entidade autenticadora encontre alguma entrada referente a credencial, o usuário é autenticado. Com isso entende-se que o usuário provou ser quem ele informou ser. Uma vez realizada a autenticação do usuário, a entidade autenticadora poderá verificar qual ou quais são as permissões de acesso ao recurso originalmente requisitado. A este processo de verificar as permissões de acesso a um determinado recurso chamamos de autorização Federação e SSO (Single Sign-On) Uma federação respresenta um conjunto de organizações que cooperam entre si de acordo com regras de confiança pré-estabelecidas para a autenticação de usuários e compartilhamento de recursos [SWITCH 2011]. Uma solução de federação é considerada desejável quando organizações crescem com a aquisição de novos sites, para a manutenção distribuída de repositórios e para simplificar a autenticação e autorização de usuários a recursos e aplicações entre domínios parceiros [Ping Identity 2010]. As entidades a seguir são normalmente encontradas em uma federação: Service Provider (SP): É a entidade mais próxima ao recurso do domínio em questão. É responsável por verificar a validade dos cookies de sessão e das permissões de acesso aos recursos por usuários autenticados. Como exemplo, o SP poderia ser um provedor, que oferece serviços de nuvem para seus clientes; Identity Provider (IdP): É um provedor de serviços de identidades. Sua responsabilidade é de manter a base de dados de usuários do domínio e validar as credenciais de usuários. Como exemplo, pode ser uma empresa que gerencia contas para um grande número de usuários que precisam de acesso seguro a transações bancárias. Por meio dessa entidade os usuários fornecem as suas credenciais para acessarem os recursos federados;

33 18 Anais Identity Provider proxy (IdPproxy) ou WAYF (Where Are You From): É a entidade responsável por interrogar o usuário a respeito de seu domínio de origem. O domínio de origem é o local onde o usuário possui uma identidade em um IdP. Geralmente o IdPproxy apresenta uma lista de IdPs para o usuário selecionar o mais apropriado. As duas primeiras entidades são geralmente encontradas em federações onde os participantes estão localizados em um mesmo domínio administrativo. Neste caso dizemos que a federação é intra-domínio e ocorre entre as diferentes aplicações do domínio. Em federações cujos elementos estão dispostos em domínios administrativos distintos, dizemos que a federação é entre domínios. Neste caso, e dependendo da arquitetura adotada, pode existir a última entidade acima Gerência de Identidades em Nuvem É interessante notar que o uso de uma gerência de identidades depende do tipo de modelo de nuvem: para SaaS (Software-as-a-Service), apenas o controle de acesso às aplicações é necessário; para PaaS (Platform-as-a-Service) e IaaS (Infrastructureas-a-Service), é necessário o controle de acesso integrado tanto das aplicações quanto do sistema de software e demais recursos (software e hardware) acessíveis na plataforma [Celesti et al. 2010]. O modelo tradicional de se manter uma base de dados compartilhada de identidades para aplicações Web não é adequado para ambientes de nuvem. Isso porque o usuário pode ter conteúdo e permissões de acesso compartilhados em diversos sites, e em diferentes aplicações Web. Em virtude disso, o mapeamento de identidades para usuários torna-se inviável em decorrência da alta replicação de dados. Em razão disso, os modelos de controle de acesso centrado no usuário são mais adequados para ambientes de nuvem: as requisições aos SPs são tratadas de acordo com a identidade do usuário e suas credenciais. O controle de acesso centrado no usuário precisa conter informações que definam unicamente um usuário no domínio. Isso implica em manter um contexto de informação por usuário, de forma a prover SSO. Uma vez que o usuário pode ter múltiplas identidades, cada uma delas deve estar mapeada para o mesmo usuário, ou seja, uma identidade federada. 3. Plataforma REALcloud A plataforma REALcloud suporta o acesso seguro e federado a máquinas virtuais (VMs) em uma nuvem híbrida possibilitando oferecimento de serviços de infraestrutura (IaaS) e de plataforma (PaaS). No caso de IaaS a plataforma oferece o acesso seguro a VMs configuradas com recursos computacionais de propósito geral, tais como sistemas operacionais, ambientes de desenvolvimento, servidores, etc. No caso de PaaS a plataforma REALcloud permite proteger os recursos da plataforma sendo oferecida como serviço. A plataforma REALcloud utiliza serviços de firewall para garantir que somente usuários autenticados e autorizados tenham acesso aos recursos sob controle da plataforma Padrão Arquitetural Proposto A arquitetura proposta é uma arquitetura em camadas. Arquiteturas em camadas são interessantes quando uma das camadas possui um conjunto de serviços e estes podem ser

34 IX Workshop em Clouds, Grids e Aplicações 19 utilizados por uma camada de nível mais geral [Buschmann et al. 1996]. A Fig. 1 mostra a arquitetura em camadas proposta. Fig. 1. Padrão arquitetural para gerência de identidades. A arquitetura proposta está subdividida em 3 camadas a saber: Controle de Acesso, Federação e Persistência de Identidades/Credenciais. A camada de Controle de Acesso é responsável por proteger os recursos pertencentes aos provedores de serviços (SPs) e aplicar decisões referentes a autorização do usuário. Fazem parte desta camada os componentes de autorização PIP (Policy Information Point), PDP (Policy Decision Point), PAP (Policy Administration Point) e PEP (Policy Enforcement Point). O PEP é responsável por interceptar requisições a recursos do SP e aplicar a decisão de autorização vinda do PDP. O PDP é responsável por avaliar as políticas aplicáveis e devolver ao PEP uma decisão de autorização. O PAP é responsável pela criação das políticas. O PIP é responsável por obter informações/atributos adicionais e encaminhá-los ao PDP. A camada de Federação, por sua vez, é responsável por prover serviços para localização de provedores de identidade (IdPs) e mecanismo de estabelecimento de sessão de federação. O componente que oferece o serviço de localização é o IdPproxy e o que trata do mecanismo de sessão de federação é o CDS (Common Domain Services). A camada de Persistência de Identidades/Credenciais é responsável pela provisão (criação, deleção e edição) de identidades e credenciais. Esta camada é responsável pela manipulação das respectivas bases de dados. O componente IdP é responsável por estes serviços Arquitetura da Plataforma REALcloud A plataforma REALcloud utiliza o padrão arquitetural apresentado na Fig. 1. A Fig. 2 apresenta uma visão geral da plataforma REALcloud. Nesta figura, cada nuvem possui os elementos necessários da arquitetura de gerência de identidades e cada elemento atua dentro do próprio domínio. O SP é responsável, juntamente com o elemento CAuth, por realizar o controle de acesso de recursos fornecidos em seu domínio. O CAuth que aparece em cada domínio, reúne os elementos PIP, PAP, PEP e PDP, com as funcionalidades descritas anteriormente. O IdPproxy é responsável por oferecer um serviço de descoberta de provedores de identidades, e com isso, permitir que usuários de uma nuvem privada possa acessar

35 20 Anais recursos (por exemplo, sua VM) da nuvem pública. O CDS é responsável por setar um cookie no navegador Web do usuário, representando que o mesmo já foi autenticado por um provedor de identidade participante da federação. O IdP, por possuir bases de dados de identidades, é responsável por fazer a autenticação dos usuários. É importante ressaltar que cada IdP possui uma base de dados de apenas usuários de seu domínio. Outro fato importante é que os elementos SP, IDPproxy e IDP estão distribuídos, em cada domínio, em VMs separadas para cada tipo de serviço. O elemento CAuth está distribuído na mesma VM junto ao SP e o elemento CDS está distribuído juntamente com a VM do IDPproxy. Fig. 2. Arquitetura da plataforma REALcloud. A Fig. 3 mostra a distribuição dos componentes da plataforma REALcloud em máquinas virtuais. Nuvem Pública Nuvem Privada VM1 <<Controle de Acesso>> VM7 VM4 <<Controle de Acesso>> VM8 CAuth SP <<protege>> Front End CAuth SP <<protege>> Front End VM2 <<Federação>> VM9 VM5 <<Federação>> VM10 IdPproxy CDS Componentes REALcloud IdPproxy CDS Componentes REALcloud VM3 «Persistência>> Virtualizador VM6 «Persistência>> Embarcado IdP IdP Fig. 3. Distribuição da arquitetura em camadas na plataforma REALcloud. A distribuição dos componentes da arquitetura na nuvem pública ocorre com os

36 IX Workshop em Clouds, Grids e Aplicações 21 componentes SP, IdP e IdPproxy sendo distribuídos em máquinas virtuais. Cada máquina realiza uma camada da arquitetura proposta. Com isto obtemos uma forma não-invasiva de proteção dos recursos existentes na nuvem. O componente Front-End implementa o serviço de gerência de VMs. O componente Virtualizador implementa a tecnologia de virtualização utilizada pelos componentes da plataforma REALcloud. Na nuvem privada, o componente Front-End2 exibe a interface para a interação com os recursos robóticos. O componente Embarcado implementa microservidores HTTP para interação remota na rede interna da nuvem. Os componentes REALabs interagem com os recursos robóticos por meio do componente Embarcado. Para que um usuário consiga se identificar na plataforma REALcloud, o componente IdPproxy da nuvem pública contém informações referentes ao componente IdP da nuvem privada Aspectos da Implementação A implementação da arquitetura utilizou como base a infraestrutura oferecida pelo middleware OpenAM. O OpenAM é responsável por prover serviços de controle de acesso (autenticação e autorização) federado, SSO e uma simples gerência de usuários. Os serviços de controle de acesso, verificação de tokens, logging e provisão de identidades, oferecidos pelo OpenAM, podem ser acessados tanto via serviços Web, via HTTP, ou por meio de um agente, podendo ser visto como um modelo SaaS de serviços de controle de acesso e identidade [ForgeRock 2010]. Para realizar a autenticação dos usuários, o OpenAM também oferece a possibilidade de instalação de um agente. O agente funciona como um filtro e pode ser instalado em diversos servidores de aplicação (Apache, Tomcat, Glassfish, etc.). O agente atua como um PEP e a filtragem ocorre na requisição de um recurso hospedado no servidor. Na nuvem pública foi utilizado um agente no Tomcat para interceptar requisições a página de gerência de VMs do REALcloud. Na nuvem privada, onde está localizado o REALabs, foi instalado um agente no Apache para proteger páginas de gerência do laboratório (reserva de horário, provisão de experimentos e etc.). Neste servidor Apache também está instalado o módulo mod proxy. Com este módulo instalado, obtemos uma maior proteção na utilização dos recursos uma vez que podemos atribuir endereços de rede privados aos recursos. Desta forma, uma máquina virtual localizada na núvem pública, não conseguirá interagir diretamente com estes recursos. como segurança adicional, neste mesmo proxy e nos IdPs de cada domínio, foi congurado uma conexão HTTPS. O estabelecimento do círculo de confiança (CoT) da federação se deu através da configuração de um perfil (SP, IdP ou IdPproxy) em cada OpenAM. Para tal, foi necessário a criação de um metadata no padrão SAMLv2. Além de conter informações sobre o perfil, este metadata, utilizado na comunicação entre as entidades, possui um certificado X.509 assinado por uma entidade certificadora. Os metadatas criados nas entidades IdP e SP foram exportados para a entidade IdPproxy. Na entidade SP, foi importado o metadata referente ao perfil IdP da entidade IdPproxy. Na entidade IdP, foi importado o metadata referente ao perfil SP da entidade IdPproxy. Assim, o IdPproxy atuará, sob o ponto de vista do SP, como um IdP e do ponto de vista de um IdP, como um SP. Isto foi importante para permitir a agregação de múltiplos IdPs (de domínios diferentes) para fazer parte da federação. O acesso às VMs é realizado por meio de um IP público e porta de conexão (port forwarding). Para que as VMs tenham acesso à Internet, é utilizado NAT (Network

37 22 Anais Address Translation) para prover a conversão de endereços IP privados em endereços públicos. A plataforma REALcloud utiliza o módulo iptables disponível nas plataformas Linux para prover NAT e port forwarding. 4. Estudo de Caso A platforma REALcloud está sendo utilizada no suporte à realização de experimentos robóticos em nuvens computacionais. Neste caso, a plataforma REALcloud oferece a plataforma REALabs como serviço. A plataforma REALabs, por sua vez, é uma plataforma de robótica onde os seus recursos físicos podem ser controlados via rede. Dentre os componentes desta plataforma estão interfaces Web de gerência para a configuração de experimentos e reserva de horário. Os recursos físicos desta plataforma são câmeras, sonares, lasers, garra robótica, dentre outros. Estes recursos podem ser acoplados a um robô móvel para a realização de experimentos, por exemplo, experimentos de localização e navegação. O middleware OpenAM foi estendido com a implementação de um mecanismo de autorização básica para o acesso aos recursos robóticos. Este mecanismo consiste em invocar um servlet Java de autorização após uma autenticação bem-sucedida. Este servlet insere um conjunto de regras iptables para liberação do uso de recursos da rede interna da nuvem. As regras se referem ao IP de origem da VM do usuário e ao IP de destino do recurso. Ao final de cada experimento, ou no final de uma sessão de acesso, o serviço de controle de acesso localizado na nuvem privada atua e bloqueia o acesso da VM à rede de recursos. No entanto, o usuário ainda tem o acesso à sua VM Acesso aos Recursos Para validar a plataforma REALcloud foi realizado um estudo de caso que consiste em utilizar a plataforma REALcloud para realizar um experimento robótico de tracking visual. Este experimento tem como objetivo fazer um robô perseguir outro robô utilizando sua câmera de bordo. O primeiro passo é o usuário fazer um agendamento de horário. Para tal o usuário acessa o serviço de reserva de horários da plataforma REALabs e seleciona um horário disponível. É importante ressaltar que para o usuário acessar o serviço de reservas, antes será realizado um redirecionamento pelo PEP para que ele se autentique. A Fig. 4 apresenta uma visão geral do processo de estabelecimento da autenticação federada na plataforma REALcloud e autorização para realização do experimento. Por razões de simplificação, neste diagrama de sequência, os componentes PEP, PIP, PAP e PDP se encontram dentro do componente SP. No passo 1, a partir do navegador Web (browser) o usuário solicita o acesso ao serviço de reserva de horários. Neste momento, o PEP localizado no servidor de aplicação onde o serviço está disponível, intercepta a requisição, verifica que o usuário não está autenticado (isto é, não possui um cookie) e redireciona ao SP do OpenAM. O redirecionamento é uma mensagem do tipo HTTP 302 Redirect, informando que o recurso solicitado moveu-se para outra URL. O SP inicia o processo de autenticação federada, criando uma requisição SAML (AuthnRequest). Esta requisição é encapsulada na resposta de redirecionamento, que contém o endereço do IdPproxy para a autenticação. No passo 2, o navegador Web do usuário é redirecionado para o IdPproxy. Neste passo, o IdPproxy apresenta uma lista para que o usuário escolha em qual domínio deseja ser autenticado, conforme apresentado pela Fig. 5, e também, uma nova

38 IX Workshop em Clouds, Grids e Aplicações 23 Browser <<PublicCloud>> IdPproxy <<PrivateCloud>> CDS <<PrivateCloud>> SP IdP Firewall 1. Serv_Reserva() <AuthnRequest1> 2. Autenticar_IdP(AuthnRequest1) <Lista_IdPs, AuthnRequest2> 3. Autenticar_IdP(AuthnRequest2,Credenciais) <AuthnResponse1, Assertion> 4. Estab_Cookie_Fed(IdP) <_saml_idp> 5. Validar_Assercao(AuthnResponse1, Assertion) <AuthnResponse2, Assertion> 6. Validar_Assercao(AuthnResponse2, Assertion) OK 7. Gerenciar_VM() <AuthnRequest3> 8. Autenticar_IdP(AuthRequest3) <AuthnResponse3, Assertion> 9. Validar_Assercao(AuthnResponse3, Assertion) OK 9.1. Aplicar_Regras() Fig. 4. Estabelecimento da autenticação federada e autorização na nuvem. requisição SAML (AuthnRequest2) é gerada pelo IdPproxy. O usuário escolhe se autenticar em um IdP da nuvem privada e o navegador Web é, então, redirecionado para a autenticação neste IdP escolhido. O passo 3 demonstra o usuário sendo redirecionado para o IdP escolhido, bem como o navegador Web fornecendo a requisição SAML e o usuário fornecendo suas credenciais (no caso, usuário e senha). De posse das credenciais, o IdP verifica se ela é valida e após isto o usuário está autenticado. O IdP irá então emitir uma resposta SAML à requisição feita e irá redirecionar o navegador Web para o CDS (passo 4) a fim de inserir o cookie de federação ( saml idp) no navegador Web do usuário. É importante ressaltar que este passo é importante porque garante que nos próximos acessos a URLs de outros domínios federados, não será necessário informar novamente suas credenciais. Neste passo também contém uma informação referente ao redirecionamento para o IdPproxy prévio e a asserção expedida pelo IdP. No passo 5, o navegador Web é redirecionado para o IdPproxy, onde é informado a asserção SAML prévia. O IdPproxy valida esta asserção e gera uma nova resposta (AuthnResponse2) que deverá ser enviada ao SP. Neste passo uma informação de redirecionamento ao SP é adicionada. Assim, no passo 6, o navegador Web é redirecionado para o SP, com a asserção contida em AuthnResponse2 e o cookie de federação. O PEP do SP irá novamente interceptar esta requisição, porém, desta vez, ele verificará a presença da asserção e do cookie de federação. O PEP verificará junto ao SP que a asserção é de uma entidade pertencente ao CoT e irá, por sua vez, assumir que o usuário está autenticado. Com isso, será enviado ao navegador Web do usuário a página do serviço de reserva. É importante ressaltar que esta autenticação na plataforma é federada e realiza o SSO entre todos os provedores de serviço existentes em todas as nuvens.

39 24 Anais Após o passo 6, o usuário deverá inicializar a sua máquina virtual, que está localizada junto a rede física do robô. Para inicializar a sua máquina virtual, o usuário deverá acessar o serviço de gerência de VMs. O passo 7 se inicia com a tentiva do usuário em acessar este serviço. Novamente o PEP do SP irá interceptar esta requisição e irá encaminhar ao SP para gerar uma requisição SAML (AuthnRequest3), juntamente com um redirecionamento pra o IdPproxy conhecido por este SP. No passo 8 o navegador Web do usuário envia ao IdPproxy a requisição SAML prévia e este verificará a presença do cookie de federação contendo um valor referente a um IdP pertencente ao CoT conhecido. Assim, o IdPproxy irá expedir uma reposta SAML (AuthnResponse3) contendo uma asserção e enviará como resposta ao navegador Web do usuário, juntamente com uma informação de redirecionamento ao SP detentor da página de gerência de VMs. Esta resposta SAML será enviada, no passo 9, ao SP em questão. O PEP do SP irá novamente interceptar esta requisição, porém, desta vez, ele verificará a presença da asserção e do cookie de federação. O PEP verificará junto ao SP que a asserção é de uma entidade pertencente ao CoT e irá, por sua vez, assumir que o usuário está autenticado. Com isso, será enviado pelo SP uma mensagem ao firewall da nuvem privada onde os recursos em questão estão, contendo regras do iptables para liberar o uso desta rede privada ao usuário. Na sequência, será enviado ao navegador Web do usuário a página do serviço de gerência de VMs. Por fim, o usuário poderá realizar seus experimentos a partir de sua máquina virtual. Fig. 5. Serviço de escolha de IdPs na plataforma REALcloud Execução do Experimento O experimento de tracking visual utiliza um controlador baseado em regras de decisão fuzzy. O controlador utiliza informações extraídas da câmera fixada em um dos robôs. O objetivo do controlador é manter uma distância constante entre os robôs. Para isto, um algoritmo de visão computacional extrai as entradas a serem utilizado pelo controlador da imagem. Estas entradas são o centróide de uma área de interesse e a porcentagem que esta área de interesse ocupa na imagem.

40 IX Workshop em Clouds, Grids e Aplicações 25 No algoritmo de visão, a área de interesse corresponde aos pixels que possuem a cor do robô que se deseja perseguir. Para o robô utilizado, esta cor corresponde ao vermelho. Para isolar a cor de interesse na imagem, primeiramente o algoritmo de visão emprega técnicas de isolamento de cor no sistema de cores HSV. Em seguida, utiliza operadores morfológicos largamente utilizados na literatura como os de abertura e fechamento. O operador de abertura possui uma estrutura retangular de 4 2 pixels e o de fechamento, um disco de raio igual a 5 pixels. Desta forma é possível determinar o centróide e a porcentagem ocupada pela área de interesse, requisitos do controlador. O controlador fuzzy, por sua vez, possui duplo objetivo. O primeiro é o de centralizar o centróide na imagem, fato que implica em alinhar o robô com o objeto perseguido, neste caso, outro robô. O segundo é o de manter a porcentagem da área ocupada pela cor do robô constante na imagem. Este segundo objetivo implica que a distância entre os robôs permanecerá constante. Com duas entradas, centróide e porcentagem de área ocupada, e duas saídas, velocidades dos motores esquerdo e direito, este controlador emprega o método de inferência de Mamdani, com operadores MAX-MIN e centróide como operador de defuzzyficação. A título de comparação, o mesmo experimento foi realizado utilizando um computador conectado na rede Internet executando o experimento de tracking visual. O atraso da rede causa uma degradação de desempenho do controle, o que faz com que a trajetória do robô que persegue o alvo seja irregular. Isto é ilustrado na Fig. 6(a) onde a frequência de atuação do controle foi de 4,55 atuações por segundo com desvio padrão de 1,301. Nesta figura, a linha pontilhada é a trajetória do robô alvo e a linha cheia a trajetória do robô perseguidor. A Fig. 6(b) ilustra o mesmo experimento executado em uma máquina virtual da plataforma REALcloud. Neste caso, o atraso é bastante reduzido quando comparado com o atraso experimentado na Internet. Como consequência, o robô desenvolve uma trajetória homogênea, praticamente idêntica à trajetória do robô alvo. Neste caso, a frequência média do controle foi de 12,49 atuações por segundo com desvio padrão de 1,007. Além de propiciar acesso seguro, a plataforma REALcloud propicia que a execução dos experimentos ocorra em servidores localizados a apenas um hop da rede (privada) onde os recursos se encontram (a) (b) Fig. 6. Experimentos realizados: (a) execução via Internet, (b) execução na plataforma REALcloud.

41 26 Anais 5. Trabalhos Relacionados O trabalho descrito em [Emig et al. 2007], apresenta uma arquitetura em camadas semelhante à arquitetura proposta neste artigo. Em relação à arquitetura proposta, utilizamos o perfil de SSO chamado SP-Initiated SSO ao invés do IdP-Initiated SSO, proposto pelo outro autor. O modelo SP-Initiated é mais interessante do ponto de vista da experiência do usuário, dado que a solicitação de credenciais ocorrerá após a tentativa de acesso a um recurso. Este modelo de SSO foi definido com a especificação do SAML versão 2.0 [OASIS 2008], que atualizou a antiga versão 1.0. Outra questão interessante foi que os autores do trabalho não dividiram sua arquitetura em componentes responsáveis por prover os recursos (SP) e por fazer a autenticação (IdP). Assim como descrito em [Celesti et al. 2010], acreditamos que este isolamento na arquitetura é importante, especialmente para ambientes em nuvem, pois permite realizar a autenticação em um domínio diferente do domínio do recurso solicitado. Os problemas referentes à gerência de identidade surgiram em meados da década de 80, destacando-se o sistema Rec. X.500 para serviços de diretórios do tipo Directory Access Protocol(DAP). Na década de 90, o IETF padronizou o Light Directory Access Protocol (LDAP), muito utilizado nos primeiros navegadores Web, como o Netscape Navigator. Na época, a Microsoft propôs um padrão similar conhecido como Active Directory, e serviços como o Passport [El Maliki and Seigneur 2007]. Atualmente destacam-se paradigmas orientados ao usuário, o que é conhecido como Identity Management (IDM) 2.0. A seguir citamos algumas propostas nesta linha. Para a representação universal e abstrata de identificadores, conveniente para sistemas com SSO, a OASIS propõe o uso do protocolo XRI [OASIS 2011]. Esse protocolo pode ser utilizado para identificar recursos independente do domínio, sejam eles hosts, softwares ou pessoas. O Identity Web Services Framework (ID-WSF) da Liberty Alliance [Liberty Alliance 2011] surgiu como um framework para estabelecer o uso de padrões abertos para a identidades federadas. Além de adotar o modelo de CoT para estabelecer o SSO entre SPs e IdPs, o framework se preocupou com a segurança das mensagens trafegadas entre os domínios, sugerindo o uso de especificações como o WS- Security, WS-Policy, WS-Trust e WS-Federation, juntamente com asserções SAML. O framework também especifica como mensagens de autorização e autenticação em SOAP (Simple Object Access Protocol) podem trafegar em domínios federados com integridade e confidencialidade. O Shibboleth [Internet2 2011] foi uma das primeiras iniciativas de código aberto para a integração de recursos Web em universidades. Ele é um middleware para Web SSO federado desenvolvido pelos grupos Internet2 e Middleware Architecture Committee for Education (MACE). Shibboleth utiliza asserções SAML e os conceitos de provedores de serviços (SP), provedores de identidades (IdP) e serviços de listagem de domínios parceiros (Discovery Service ou WAYF). O projeto Higgins [Eclipse Project 2011] é um framework de código aberto para a integração de identidades, perfis e informação distribuída. Um Active Client integrado ao navegador Web do usuário mantém cartões com informações de contexto e credenciais. Nesses cartões (I-Cards) há informação suficiente para acessar Web sites sem a necessidade de informar a senha, ou de preencher formulários para cadastro. Plugins para a IDE Eclipse também estão disponíveis para o desenvolvimento de aplicações Web integradas.

42 IX Workshop em Clouds, Grids e Aplicações 27 Outros trabalhos na literatura [El Maliki and Seigneur 2007] descrevem que a sociedade da Internet tende a se preocupar cada vez mais com a privacidade dos usuários, e com a administração de suas identidades digitais. Isso implica na necessidade de plataformas escaláveis para prover gerência de identidade. Este fato justifica a necessidade em nosso trabalho de uma solução capaz de tratar questões como a integração de diferentes mecanismos de autenticação, integração de diferentes tecnologias de bases de dados e a possibilidade de oferecer um ambiente de gerência de identidades como serviço, oferecendo às diversas aplicações interfaces de acesso aos serviços de identidade (por exemplo, web services, interfaces HTTP, entre outros). Com o uso do middleware OpenAM, conseguimos equacionar adequadamente estas questões. Ressaltamos também, que a arquitetura proposta é independente de tecnologia de middlewares para controle de acesso federado. Por estar em camadas, a arquitetura proposta prevê interoperabilidade entre seus componentes, utilizando diferentes middlewares, desde que eles tenham protocolos compatíveis (por exemplo, SAMLv2). Como exemplo, poderíamos ter o componente SP como uma instância do SP Shibboleth, comunicando-se com um IDP, como uma instância do IDP OpenAM. Também, os componentes da arquitetura podem ser substituídos sem causar prejuízos na disponibilidade do serviço de identidade da nuvem, pois estes estão instanciados em VMs. 6. Conclusões e Trabalhos Futuros Neste artigo apresentamos uma arquitetura para realizar a gerência de identidades em nuvens híbridas. Esta arquitetura permite que outras nuvens privadas se associem à nuvem pública da plataforma REALcloud. A implementação desta arquitetura utilizou como base a infraestrutura oferecida pelo middleware OpenAM. Na distribuição dos componentes da arquitetura foram configuradas máquinas virtuais com este middleware e configuradas para prover a gerência de identidades na plataforma. O uso da virtualização é uma alternativa para prover maior disponibilidade dos serviços de proteção de recursos na nuvem, além de simplificar a implantação de sistemas federados. O middleware OpenAM foi estendido para comportar serviços de autorização à rede interna de recursos. Para isto foi desenvolvido um servlet que insere regras de firewall na tabela de roteamento da nuvem privada da plataforma. Com relação a federação, do ponto de vista do administrador, sistemas federados simplificam a administração de contas de usuários dos diversos domínios existentes. Do ponto de vista do usuário, domínios federados reduzem a quantidade de autenticações necessárias para interagir com os serviços ofertados. Um sistema para gerência de identidade, portanto, deve integrar o uso de diversas formas de autenticação e autorização entre as diversas bases de dados de usuários, distribuídas em diversos domínios federados e oferecer ao usuário uma experiência de SSO. A plataforma REALcloud implementa um modelo virtualizado em camadas para a gerência de identidades em nuvems híbradas. Apresentamos um estudo de caso que demonstra a aplicação da proposta para realização de experimentos de robótica em rede. Pretendemos, como trabalho futuro, estender o mecanismo de autorização para contemplar políticas de acesso de granularidade fina (entitlements) e aplicar no acesso de todos os recursos existentes na plataforma REALcloud. Um caminho a ser seguido seria no uso de ontologias para descrever os recursos da plataforma e suas possíveis composições. E, a partir destas ontologias, aplicar as políticas de autorização.

43 28 Anais Referências Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., and Stal, M. (1996). Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Wiley. Cao, Y. and Yang, L. (2010). A Survey of Identity Management Technology. IEEE International Conference on Information Theory and Information Security (ICITIS). Celesti, A., Tusa, F., Villari, M., and Puliafito, A. (2010). How to Enhance Cloud Architectures to Enable Cross-Federation. IEEE 3rd International Conference on Cloud Computing. Eclipse Project (2011). Higgins - Open Source Identity Framework. Disponível em: El Maliki, T. and Seigneur, J.-M. (2007). A Survey of User-centric Identity Management Technologies. In Proceedings of the The International Conference on Emerging Security Information, Systems, and Technologies, SECUREWARE 07, pages 12 17, Washington, DC, USA. IEEE Computer Society. Emig, C., Brandt, F., Kreuzer, S., and Abeck, S. (2007). Identity as a Service - Towards a Service-Oriented Identity Management Architecture. Springer-Verlag. ForgeRock (2010). OpenAM. Disponível em: Internet2 (2011). Shibboleth - A Project of the Internet2 Middleware Initiative. Disponível em: Liberty Alliance (2011). Disponível em: center/specifications. OASIS (2008). Security Assertion Markup Language (SAML) V2.0 Technical Overview. Technical report. Disponível em: OASIS (2011). Disponível em: Olden, E. (2011). Architecting a Cloud-Scale Identity Fabric. volume 44, pages Journal Computer - IEEE Computer Society. Ping Identity (2010). About Identity Federation and SSO. Disponível em: Rocha, L. A., Olivi, L., Paolieri, F., Feliciano, G., Souza, R. S., Pinho, F., Teixeira, F., Rodrigues, D., Guimaraes, E., and Cardozo, E. (2011). Computer Communications and Networks - Advances in Educational Robotics in Cloud with Qualitative Scheduling in Workflows. Springer, University of Derby. SWITCH (2011). SWITCH - Serving Swiss Universities. Disponível em:

44 IX Workshop em Clouds, Grids e Aplicações 29 Virtual Machines Networking for Distributed Systems Emulation Mauro Storch 1, Rodrigo N. Calheiros 2, César A. F. De Rose 3 1 Instituto de Pesquisas Eldorado Porto Alegre, Brazil 2 Department of Computer Science and Software Engineering The University of Melbourne, Australia 3 Pontifical Catholic University of Rio Grande do Sul Porto Alegre, Brazil Abstract. Distributed systems are the dominant platform for any application, both in academic and industry. However, testing of applications in such a platform is hard, due to the complexity of the elements that compose these systems. Emulation is an alternative way to improve software quality for distributed applications, allowing analysis of the application behavior in a given environment before its deployment. To emulate distributed systems, virtualization can be applied, as it allows creation of a large-scale controlled environment with few physical resources. Such an approach, however, requires application of network management of virtual machines. This paper presents approaches for network virtualization and a description of how it can be used to create a network of virtual machines for emulation of different distributed systems configurations. This work is part of a system designed for creating a virtual environment, based on virtualization technology, to evaluate distributed applications. 1. Introduction Virtualization is an outstanding technology which allows rich control of physical resources, enabling full exploitation of machines capacity at a negligible overhead cost. Current virtual machine monitors [Devine et al. 1998, Barham et al. 2003] offer a high degree of control over the sharing of physical resources, such as CPU and memory. It is easy, using such tools, to deploy several isolated virtual machines (VMs) in a single host, possibly running different operating systems. The next step on application of virtualization technology is the control of network connectivity of virtual machines. Some projects [Smith and Nair 2005,Keahey et al. 2004, Emeneker et al. 2006]apply virtualization to create a virtual local area network containing resources that are physically far from each other, belonging to different administrative domains. It is also possible, by using virtualization, to achieve the opposite approach, namely creation of a large-scale controlled environment with few local physical resources.

45 30 Anais In this case, network management techniques might be applied to configure not only the virtual environment itself but also real network characteristics. A set of virtual machines can be configured to compose subnets communicating with each other through controlled routes and links. In this work, SNMP agents are used to configure network components, and TBF/NetEm [Evans and Filsfils 2007,Hemminger 2007] is used to supply bandwidth control. In order to improve network management of the virtual environment, a module is responsible for the reception of both the real environment description and the desired virtual network configuration, described in XML language. The module applies the desired configuration in a running set of virtual machines. At the end of the process, the nodes belonging to the virtual environment are ready to communicate according to the specified rules. Experiments were conducted in order to evaluate the efficiency of our approach in setting virtual network parameters as well as to check the communication configuration made in the virtual machines that compose the virtual environment. This work complements previous results [Calheiros et al. 2010, Calheiros et al. 2008], where tests were executed in a broader context with the use of network management mechanisms described in this paper. This paper is organized as follows. Section 2 presents basic virtualization concepts. Section 3 presents the motivation for this work and the context where it is placed. Section 4 presents development of the virtual network manager. Section 5 presents the evaluation of the network manager and Section 6 concludes the paper. 2. System Virtualization System virtualization is applied not only in many production systems, but also in research from several computer science areas. Nevertheless, it is not a new concept: the first virtual machines were developed in the sixties in order to improve efficient in the usage of computers available by that time [Creasy 1981]. This technology allows simultaneous access to the virtualized hardware by several users, which does not realize that the physical machine is not exclusively available for their use. In this context, virtualization can be understood as a technology that abstracts the hardware, allowing execution of several instances of an operating system in the same physical machine [Smith and Nair 2005]. Virtual machine is a software layer that duplicates a real machine, acting between the hardware and the operating system. It is worth noting that every virtual machine located on a certain real machine is isolated from the others. Thus, the processes executing in a specific virtual machine are independent from the others, and cannot interfere in the processes running on other virtual machines. This characteristic allows for increasing the computer system reliability. Control and creation of virtual machines are performed by the software known as Virtual Machine Monitor (VMM) or hypervisor. The VMM purpose is to make a specific interface available to each virtual machine, providing a virtual environment similar to a real machine. Paravirtualization is a technique where the VMM does not completely virtualize the underneath hardware. Thus, the operating systems running on virtual machines have to be adapted, in order to become aware of the presence of the hypervisor. On the other hand,

46 IX Workshop em Clouds, Grids e Aplicações 31 hardware virtualization is common in many hardware components allowing a controlled direct access to the hardware by VM s operating systems [Neiger et al. 2006, van Doorn 2006]. An example of a paravirtualizator is the Xen Virtual Machine Monitor [Barham et al. 2003], which is used in this work, and is presented in the following section Xen VMM Xen VMM is an open source project developed by researchers of University of Cambridge. Xen supports x86 platform, making use of the paravirtualization concept. Following the model of the x86 platform protection levels, Xen has direct access to the hardware and executes in the mode of higher privilege. In the level below, the monitor executes a virtual machine (VM) called dom0. This special machine is in charge of starting and closing the other virtual machines, called domu. It must be highlighted that the domu virtual machines have no privileges accessing or using system components, such as I/O devices, memory, and CPU time Xen Network Architecture Xen network architecture presents a set of real and virtual components. Xen dom0 is responsible not only for managing these components but also for supporting network communication among VMs. Virtual switches are used to interconnect both real and virtual interfaces. A virtual machine can have one or more virtual interfaces interconnected by one or more virtual switches. They are managed by the firewall software that intercepts network packages and handles it. These virtual switches can run in one of three modes: bridge, router, or NAT [Xen Source Inc 2007]. Bridged mode is used in this work. In this mode, iptables [Welte 2006] rules are used to redirect network packages between real and virtual interfaces. These components can be managed through the dom0 on each Xen host. This machine natively supports execution of all management softwares. Management tools such as iptables and xm (for management of Xen virtual machines) support creation of network environments using virtual machines on a easier way. From this standpoint we can see that VMs can be used as normal hosts in order to, for example, emulate distributed systems. Next section presents a proposal of a virtual environment, based on virtualization techniques, to emulate distributed systems. 3. Automated Emulation Framework This work is part of a project aimed at implementing a virtualization-based emulation framework (Automated Emulation Framework AEF) on which a user performs experiments in a virtual distributed system [Calheiros et al. 2010, Calheiros et al. 2008]. The system organization is presented in Figure 1. In the bottom level of the architecture there is a cluster of computers running a Virtual Machine Monitor. Cluster machines run the emulator software, which uses VMM capacities to build the emulated distributed system that runs user s experiments. The system input is an XML description of system resources (both virtual and physical) and the distributed experiment (e.g., a grid experiment, a P2P protocol test, an enterprise application, among others). Description of the virtual system includes one or

47 32 Anais Figure 1. AEF architecture. more networks, hosts belonging to each network, its configuration, and network characteristics. Description of physical system includes information about the real environment: network, specification of each machine, version of the virtualization software in use, as well as amount of physical resources in use by the VMM on each machine. Once the required environment is specified, AEF performs a mapping of the virtual resources to real ones, deploys the equivalent virtual system, and configures the network environment in order to supply user demands. Afterward, the user application is automatically triggered in the virtual system and managed by the testbed. Application output is stored according to the user specification. In this paper, we focus on the aspects related to network management of AEF. In the next section, a description of the network manager implementation is presented, and the experiments and achieved results are presented in Section Virtual Machines Networking This section presents issues related to network management and configuration used by AEF, as presented in Section 3. Firstly, information about network components of our virtual environment and how they can be managed will be presented. Following, network management aspects applied in this work are presented. Afterward, a software module structure for network management and how this module performs configuration over network components to create a desired virtual distributed environment will be discussed.

48 IX Workshop em Clouds, Grids e Aplicações 33 Figure 2. Network of Virtual Machines Network issues System virtualization technology supports VM network communication by a set of real components and a set of virtual components. As presented in Section 2, each VM has one or more virtual network interfaces (vifs). These vifs are connect in a virtual switch hosted in a privileged virtual machine (in Xen, this VM is called dom0). This virtual switch is managed by firewall software that rules all network traffic in the same way that in non-virtualized systems. On this virtual switch, real interfaces are also connected, allowing remote communication. Xen s dom0 uses iptables [Welte 2006] to manage network connections among local and remote VMs. In this work all network rules act on OSI s network layer [Day and Zimmerman 1983]. Bandwidth control is made by a Token Bucket Filter (TBF) [Evans and Filsfils 2007] and latency configuration is performed with the NetEm [Hemminger 2007]. Another bandwidth control algorithms like CBQ [Floyd and Jacobson 1995] and HTB [aka devik ] were evaluated, but TBF was used because it provides all the tools required by this work. At VM start up, IP address and default network routes are set to each vif. Such a definition enables network communication among VMs. However, other network parameters such as bandwidth and latency are set in the firewall software running in dom0 after VMs start up. The virtual switch transmits all network packages on demand to VMs located at the same host, using token ring algorithm and memory reallocation [Xen Source Inc 2007]. Package transmission between VMs placed in different hosts is done by a real network interface in the same way that in non-virtualized network communications. Figure 2 illustrates network components architecture in a virtualized environment with more than one host. Almost all network configuration parameters, such as vif s IP address and routes, traffics rules, and bandwidth control can be changed on the fly. A good way to configure a large-scale environment based on these technologies is through a network manager approach. In this work, Simple Network Manager Protocol (SNMP) is used for manage both real and virtual network components. It is presented in the next section.

49 34 Anais 4.2. Network Management Network management is used in different systems to configure different kind of resources. SNMP (Simple Network Management Protocol) was originally developed for network management. However, due to its flexibility, it is also used for others management types, such as software management. The structure of this protocol is based on managers and agents, where the agents are spread on the resources and the management operations are performed through direct solicitation from managers to agents. The objects that can be managed are described in the MIB (Management Information Base) [Stallings 1999]. In this work, we apply this approach to configure a environment based on virtual machines. Once manageable components are defined, the environment configuration is performed by a SNMP manager. Network configuration in this work consists basically in making changes on virtual machines network configuration, defining traffic rules on dom0 (responsible for VMs communication), and setting both bandwidth and latency to any network link among virtual machines. Both bandwidth and latency configurations are essential to create a virtual communication environment as close as possible of network connections in real worlds. Common agents are used to configure network components like network traffic rules, bandwidth, and latency. On the other hand, specific agents to make changes on virtual machine network components were developed to support basics configurations. These agents were described in a previous work [da Cunha Rodrigues 2008]. As presented in Section 3, the proposed Virtual Environment is created in an automatic way. Thus, the network management needs to be automatized to allow easy environment creation. To improve the network management, a module was defined using features presented in this section. This module configures the network communication among VMs and it is described below Network Manager Module The Network Manager Module was contextualized in Section 3 and it will be described in this section. It was developed as an independent module, and can be used out of the presented context, e.g., configuring network issues of a set of virtual machines described on the input XML files. The Network Manager Module is an object-oriented program developed to manage network components through the SNMP protocol. It is used to perform configuration in an environment based in virtualization technology. Figure 3 illustrates the Network Manager Module. It receives two XML files as input. One of them describes the real network which contains description of routers, physical network links, on-line virtual machines, and network information of real machines. The second XML file describes the desired virtual environment and contains information regarding subnetworks of virtual machines, bandwidth and latency among VMs, network routes and rules, and so on. It is worth noting that this information is a subset of the information supplied by the user of AEF. The files are mapped in an object-oriented structure by the Network Manager Module. Real network description file is the first file loaded by the Network Manager Module. After all information is read, the module loads the virtual environment file description. All information is used to perform objects creation. To each kind of component

50 IX Workshop em Clouds, Grids e Aplicações 35 Figure 3. The Network manager module. loaded from the file, a related object is created with the information needed to perform future configurations in the environment. The module has a method called apply that, when invoked, reads the objects configuration and apply it to the real component which corresponds to the given object. These configurations are made through SNMP protocol as pointed before. The Network Manager Module can run in any machine at the same network of Xen host machines. Each machine needs to run SNMP agents and support remote access to allow module management. SNMP agents are installed on each Xen host, allowing both configuration and monitoring of VMs using Xen API. These agents are invoked by the Network Manager Module to configure the environment based on the merge between the real and the desired environment description. SNMP agents are responsible for configuring networking of VMs and making changes in dom0 firewall software where configuration in bandwidth, latency, and traffic rules is made, as shown in Section 2. After configuration file loading, the module makes changes on vifs of each VM and configures the virtual switches where configuration like network isolation, bandwidth limitation, and other traffics rules are defined. At the same time, agents offer monitoring capabilities through SNMP get command. Agents, located on all Xen hosts, collect information that can be read by a SNMP manager. Network status, bandwidth, and latency are some of information that can be monitored. Network management using SNMP was considered a good way to manage virtual network components because SNMP is a consolidated and well-accepted management protocol. 5. Evaluation In order to investigate the capabilities of our approach for VM networking, an experimental testbed using Xen VMM [Barham et al. 2003] was built. In such an experiment,

51 36 Anais a grid infrastructure encompassing 3 isolated sites was set and emulated in a cluster of workstations, as described below. The tests presented in this section are qualitative and used to demonstrate network management capabilities of our proposed Network Manager Module Physical environment The physical infrastructure hosting the virtual environment is a cluster composed of 4 machines. Each machine is a Pentium 4 2.8GHz with 1MB of cache and 2.5GB of RAM memory. The machines in the cluster are connected by a dedicated switch and a Fast Ethernet network. Machines have Xen VMM 3.1, and the Xen s Dom0 uses 328 MB of the available RAM memory. The VM images are stored in the hard disks of each host. Each physical machine hosts more 8 VMs, each one using 256MB of RAM memory and sharing the same amount of CPU time. Only the network traffic generated by this experiment was present in the physical environment during the tests Virtual environment The virtual environment built to our tests is composed of three subnetworks (sites), each one containing a proxy which is connected to the other proxies. Each subnetwork has a different number of hosts. Physically, the VMs that belong to these subnetworks are distributed among the 4 real machines, as shown in Table 1. In such a table, each line represents a physical machine, and each column represents a site. Thus, a given name in a table cell means that the hosts belongs to the site related to its column and is physically located in the host represented by its line. Figure 4. Virtual grid environment built for the tests.

52 IX Workshop em Clouds, Grids e Aplicações 37 Table 1. Distribution of virtual machines among physical hosts and virtual sites. virtual site 1 virtual site 2 virtual site 3 total host 1 host 2 host 3 host 4 vmgrid108, vmgrid109 vmgrid101- vmgrid107, vmgridpeer1 vmgrid201- vmgrid205, vmgridpeer2 vmgrid206- vmgrid212 8 vmgrid308 8 vmgrid301- vmgrid307, vmgridpeer3 total Table 2. Time in milliseconds for task file transmit. Bandwidth scenario Sending Receiving 1Mbit/s Mbit/s As shown in Table 1, each machine hosts 8 VMs, belonging to one or more virtual sites. Even though, no direct access was possible among VMs hosted in the same machine but belonging to different sites, because Xen offer isolated virtual machines [Barham et al. 2003] and no routes are set among different subnets. This configuration shows that it is possible to build isolated virtual domains using Xen. The machines labeled vmgridpeerx on each virtual site acts as proxies, having access to the other proxies through the network routes table. Each VM belonging to a site has access to the other VMs belonging to the same site, even though being located at different physical hosts. Figure 4 shows the virtual Grid environment and presents site isolation and proxies communication Network validation The Grid jobs that ran in our evaluation copies one 1MB file to a grid node twenty times. To evaluate and show network traffic control effectiveness, two bandwidth scenarios were considered: limited in 1Mbit/s among grid proxies and unlimited (using all network capability, 100Mbit/s). Table 2 shows times needed by the grid scheduler to send and receive the file from the grid resource. Each job has twenty tasks and each task copies the file to the node, runs instructions, and copies the file back. The job was initialized in the user machines, shown in Figure 4, and configured to execute on nodes in remote sites. In this environment only communication among grid schedulers was limited. Although an analysis of the transfers shows a disparity between the two bandwidth scenarios, it is important to consider effects of Ethernet collisions caused by communication between the grid scheduler and the grid resources. Furthermore, in a virtualized environment there is an overhead to transmit

53 38 Anais Figure 5. Limited network bandwidth between local and remote VMs. network packages among distributed virtual machines. In order to evaluate the effectiveness of our network bandwidth control, a sequence of tests were made. In these tests, we considered both communication between VMs hosted at the same host and communication between remote VMs (i.e., VMs hosted in different machines). Bandwidth control was made by the TBF (Token Bucket Filter) using tc (Traffic Control Linux tool). The configuration was performed in the virtual interface (on Xen dom0) related to each VM network interface. In our tests 300MB file was transmitted in each case (local and remote VMs), and the bandwidth between sender and receiver varied on each test. Secure Copy Protocol [Barrett and Silverman 2001] was used to transmit the file among the nodes. Figure 5 shows the result of these tests. The straight line represents configured values for the bandwidth, while the dotted lines represent the values obtained in the measurements. The proportionality between the configured value and the measured value increases as the desired bandwidth increases, both in local and remote communication. In a distributed environment, low values of bandwidth are more common than high values, so in the most experiments this approach for bandwidth control will produce satisfactory results. In order to evaluate the effectiveness of latency control we also varied the latency between sender and receiver in a different test. Latency control was made by the NetEm (Network Emulation) using tc (Traffic Control Linux tool). The configuration was performed in the virtual interface (on Xen dom0) related to each VM s network interface. ICMP echo/request packages were transferred between both local and remote VMs. Figure 6 shows the configured latency (straight line) and the obtained latency (dotted lines). It is possible to see that obtained low latency values have a higher deviation from the configured value, and the proportionality decreases as the latency value increases. In distributed environments, high values of latency are more common than low values, so in most cases this approach also produces satisfactory results.

54 IX Workshop em Clouds, Grids e Aplicações 39 Figure 6. Limited network latency between local and remote VMs. In virtualized emulation environment, control of bandwidth and latency is an important element to enable simulation of distributed systems. Thus, results obtained in the experiments show that the use of common network tools combined with paravirtualization technology allows a reliable emulation of a distributed system, including network links among nodes. 6. Conclusion and Future Work Among many possible applications for system virtualization which emerged in the last few years, emulation of distributed environments is a topic that can be further investigated by researchers. When using virtualization in this context, network management is the most important issue to be considered. In this work, we investigated the use of virtualization to support reliable network configuration of a virtual controlled environment based on virtualization technology. To automate such a process, characteristics of the components were studied and a network management module was implemented. This module receives descriptions of the real environment and the desired virtual network. By using available network tools, such as TBF/NetEm and iptables, combined with VM management tools such as xm, it was possible to create isolated subnetworks with controlled bandwidth and latency between their links. To validate our approach, quantitative tests were performed and resulted in similar results between configured and obtained values in two cases: communication among nodes in the same host and communication among nodes in remote hosts. Therefore, we believe that the use of virtualization technology is an interesting alternative for distributed systems emulation, allowing easy configuration of a controlled environment at low cost using few machines to emulate a large distributed system. In future work, we expect to increase accuracy and reliability of the emulation environment by applying newer versions not only from the Xen VMM itself but also from other deployed tools. We are also investigating network control in other virtual machine monitors, such as VMware [Devine et al. 1998] and KVM [Harper et al. 2007].

55 40 Anais References aka devik, M. D. Hierachical token bucket. devik/ qos/htb/. Barham, P. et al. (2003). Xen and the art of virtualization. In Proceedings of the ACM Symposium on Operating Systems Principles. Barrett, D. J. and Silverman, R. (2001). SSH, The Secure Shell: The Definitive Guide. O Reilly & Associates, Inc. Calheiros, R. N., Buyya, R., and De Rose, C. A. F. (2010). Building an automated and self-configurable emulation testbed for grid applications. Softw. Pract. Exper., 40: Calheiros, R. N., Storch, M., Alexandre, E., Rose, C. A. F. D., and Breda, M. (2008). Applying virtualization and system management in a cluster to implement an automated emulation testbed for grid applications. In Proceedings of the th International Symposium on Computer Architecture and High Performance Computing, pages , Washington, DC, USA. IEEE Computer Society. Creasy, R. J. (1981). The origin of the VM/370 time-sharing system. IBM Journal of Research and Development, 25(5): da Cunha Rodrigues, G. (2008). vmib : uma MIB genérica para gerenciamento de recursos virtuais. Master s thesis, PUCRS, Fac. de Informática. Day, J. D. and Zimmerman, H. (1983). The OSI Reference Model. In Proceedings of the IEEE, volume 71, pages Devine, S., Bugnion, E., and Rosenblum, M. (1998). Virtualization system including a virtual machine monitor for a computer with a segmented architecture. US Patent. Emeneker, W., Jackson, D., Butikofer, J., and Stanzione, D. (2006). Dynamic virtual clustering with Xen and Moab. In Frontiers of High Performance Computing and Networking ISPA 2006 Workshops, volume 4331 of Lecture Notes in Computer Science, pages , Sorrento. Springer. Evans, J. W. and Filsfils, C. (2007). Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice. Morgan Kaufmann. Floyd, S. and Jacobson, V. (1995). Link-sharing and resource management models for packet networks. IEEE/ACM Transactions on Networking, 3(4): Harper, R. A., Day, M. D., and Liguori, A. N. (2007). Using KVM to run Xen guests without Xen. In Proceedings of the Linux Symposium, pages , Ottawa. Linux Symposium Inc. Hemminger, S. (2007). NetEm. Keahey, K., Doering, K., and Foster, I. (2004). From sandbox to playground: Dynamic virtual environments in the grid. In Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, pages 34 42, Pittsburgh. IEEE Computer Society. Neiger, G., Santoni, A., Leung, F., Rodgers, D., and Uhlig, R. (2006). Intel Virtualization Technology: Hardware support for efficient processor virtualization. j-intel-tech- J, 10(3):

56 IX Workshop em Clouds, Grids e Aplicações 41 Smith, J. E. and Nair, R. (2005). Virtual Machines: Versatile platforms for systems and processes. Morgan Kauffmann, San Francisco. Stallings, W. (1999). SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Addison Wesley, Reading, 3 edition. van Doorn, L. (2006). Hardware virtualization trends. In VEE 2006: proceedings of the Second International Conference on Virtual Execution Environments, pages Welte, H. (2006). What is netfilter/iptables? Xen Source Inc (2007). Xen interface manual. research/srg/netos/xen/readmes/interface/interface.html.

57 42 Anais

58 IX Workshop em Clouds, Grids e Aplicações Sessão Técnica 2 Infraestrutura em Aplicações

59

60 IX Workshop em Clouds, Grids e Aplicações 45 Modelagem conceitual de um integrador para simulação hemodinâmica em Grid Ramon G. Costa, Paulo G. P. Ziemer, A. T. A. Gomes, Bruno Schulze, Pablo J. Blanco, Raúl A. Feijóo {ramongc, ziemer, atagomes, schulze, pjblanco, 1 Laboratório Nacional de Computação Científica - LNCC Quitandinha, Petrópolis - RJ, Brazil Resumo. Avanços recentes têm mostrado que a pesquisa médica pode se beneficiar de maneira intensa através do uso de ferramentas computacionais orientadas à modelagem e simulação computacional do sistema cardiovascular humano. Isto não só atinge o entendimento da gênese e desenvolvimento de doenças cardiovasculares, mas também a avaliação de procedimentos cirúrgicos e até mesmo o treinamento de recursos humanos nas áreas médicas. Para isto é preciso superar diversas barreiras associadas à construção do modelo computacional do sistema cardiovascular. Em particular, um dos pontos de maior demanda em termos de custo computacional corresponde ao cálculo numérico aproximado do escoamento do sangue em distritos arteriais de interesse. Assim, para diminuir o tempo de computação, o software resolvedor de modelos utiliza o paradigma MPI para compartilhar a carga entre processadores diferentes. Este trabalho apresenta a modelagem conceitual do sistema integrador, que permite ao software de simulação hemodinâmica, produzir o resultado da simulação em ambiente de Grid. Este trabalho contempla o projeto arquitetural, além do projeto detalhado do sistema de software usando a UML, tais como: diagramas de classe e sequência. 1. Introdução Doenças relacionadas com o sistema cardiovascular humano, tais como doenças cardíacas coronarianas, são as principais causas de morte no mundo [Mackay et al. 2004]. O uso de simulação computacional pode fornecer informações exclusivas e detalhadas sobre o comportamento do fluxo de sangue para médicos e pesquisadores, dando-lhes novas perspectivas sobre os tratamentos de patologias [Blanco et al. 2009a]. O projeto HeMoLab [HeMoLab ] foi criado com o objetivo de desenvolver ferramentas de simulação computacional que possam fomentar e facilitar a utilização de ferramentas de modelagem. Com isso em mente, foi desenvolvido o software, chamado HeMoLab, como uma extensão do software de visualização Kitware Paraview [Moreland 2009]. As principais funcionalidades do HeMoLab permitem a criação e personalização de modelos simplificados (modelos 1D), modelos com maior nível de detalhes (3D), e modelos acoplados (1D-3D). Os modelos produzidos pelo HeMoLab são salvos em um formato de arquivos especial e usados como entrada para o software que faz o cálculo da simulação, chamado SolverGP. A experiência obtida com a simulação computacional de modelos 3D têm mostrado que o tempo de processamento exigido é da ordem de semanas ou mesmo meses

61 46 Anais em modelos mais complexos. Desta forma, o uso de técnicas de computação de alto desempenho, como a computação em Grid é vital para o sucesso da adoção do software HeMoLab pela comunidade médica. Neste contexto, este trabalho descreve a modelagem conceitual do sistema integrador que permite com que um sistema de simulação hemodinâmica possa ser processado em uma Grid Computacional. A saber, serão especificados os requisitos, a arquitetura e a correspondência entre os elementos descritos em ambas as especificações. A especificação de requisitos será expressa em linguagem natural, além do diagrama UML de caso de uso. A especificação arquitetural contempla os três principais tipos de visões arquiteturais: execução, módulo e implantação. A especificação dos módulos do subsistema integrador é expressa por meio de diagramas UML de classes e de sequência. Além dos diagramas de classe, cada classe é detalhada em linguagem natural. O trabalho contempla ainda a implementação de um protótipo do sistema integrador. 2. O projeto HeMoLab 2.1. Modelagem do Sistema Cardiovascular Humano A simulação do sistema cardiovascular humano é realizada utilizando dois tipos de modelos: unidimensional (1D) e tridimensionais (3D). O modelo 1D representa o sistema cardiovascular de uma forma simplificada, onde as principais artérias do corpo humano são modeladas como um conjunto de linhas retas (segmentos) e pontos (terminais). Os modelos 3D são utilizados para obter um maior nível de detalhe do comportamento do fluxo de sangue dentro da artéria para uma estrutura especificada. A geometria de um modelo 3D é obtida através da análise e processamento de imagens médicas, tais como tomografia computadorizada, ressonância magnética, ultra-som intravascular, etc. Os modelos 3D podem ser utilizados de forma independente ou integrados aos modelos 1D. Os modelos 1D-3D quando integrados são chamados de modelos acoplados [Blanco et al. 2009b]. Desta forma, os dados resultantes da simulação do modelo 1D são usados como condição de contorno para o modelo 3D. Se um modelo 3D é usado de forma autônoma, as condições de contorno devem ser configuradas em fase avançada. A simulação computacional de um modelo é feita através da resolução (usando Método dos Elementos Finitos - FEM) de um sistema de equações de Navier Stokes que descreve o movimento dos fluidos, como: sangue dentro de uma artéria. A fim de iniciar a simulação computacional de algum modelo, o SolverGP lê o conjunto de arquivos que descrevem os parâmetros do modelo, como geometria, mecânica e parâmetros de simulação. Cada período de simulação (geralmente um período refere-se a uma batida do coração) é sub-dividido em passos de tempo (um valor típico é 640) e para cada passo de tempo, o SolverGP atualiza o arquivo que armazena os resultados da simulação (Dataout.txt ) com os valores de deslocamento, velocidade e pressão em cada ponto do volume. Ele utiliza MPICH2 [Gropp et al. 2009] como a implementação MPI padrão. A simulação computacional de modelos 1D não demanda uma potência computacional de alta performance. Esses modelos simplificados são comumente resolvido usando uma versão do SolverGP sequencial, em computadores desktop comuns, com tempo de resolução de aproximadamente 15 a 30 minutos. No entanto, modelos mais complexos, tais como os modelos 3D ou acoplados, podem exigir um alto poder computacional na realização das simulações. Por exemplo, o modelo de computador de uma

62 IX Workshop em Clouds, Grids e Aplicações 47 aorta, a maior artéria do corpo humano, necessita de aproximadamente pontos para representar a geometria das artérias e, em seguida, dá origem a um sistema de equações com incógnitas. A computação de apenas um batimento cardíaco, em tal modelo, leva aproximadamente 35 dias (com 640 passos de tempo) quando usados oito processadores em uma máquina com configuração: 2X Quad-Core Xeon 3GHz / 64GB RAM. Após a fase de simulação computacional, técnicas de computação gráfica podem ser aplicadas aos dados produzidos, a fim de facilitar o processo de obtenção conhecimento sobre os dados. Na Figura 1, é possível ver um exemplo desse processo sobre os resultados da simulação de uma artéria que contém um aneurisma. As linhas de corrente indicam a trajetória instantânea das partículas de sangue e a magnitude da velocidade. Figura 1. Exemplo de um modelo de aneurisma com resultados de simulação 3. Conceitos e Tecnologia A fim de obter menores tempos de computação, o sistema HeMoLab usa MPI (Message Passing Interface) [Forum 1994] para a paralelização de simulações computacionais do sistema cardiovascular humano. Durante o processo de gridificação do HeMoLab, várias ferramentas foram usadas para apoiar a criação e configuração de serviços em Grid, tais como: glite Middleware [Burke et al. 2009], Secure-Store [Scardaci and Scuderi 2007] e Watchdog [Bruno et al. 2009]. O glite é um middleware para Grids Computacionais que fornece um framework para a construção de aplicações que aproveitam o poder da computação distribuída e recursos de armazenamento através da Internet. Secure-Store [Scardaci and Scuderi 2007] é uma ferramenta usada pelo glite para fornecer aos usuários as ferramentas adequadas e simples para armazenar dados confidenciais em elementos de armazenamento de uma forma transparente e segura. Seu uso no projeto HeMoLab tem grande importância, pois os dados do paciente trafegam por vários nós antes da execução.

63 48 Anais Muitas vezes, jobs que demandam longo processamento exigem monitoramento e controle durante a sua execução. No HeMoLab, existem várias simulações que necessitam de horas de processamento. Usando o Watchdog [Bruno et al. 2009], é possível realizar o controle e monitoramento das tarefas usando os serviços da Grid de forma menos invasiva. 4. Projeto do Sistema Integador Os principais desafios da portabilidade de um sistema de cluster local que usa MPI para um ambiente de Grid inclui a adaptação do trabalho de um sistema homogêneo para um ambiente heterogêneo, a criação de camadas de software que atuam como interface entre a aplicação e a infra-estrutura de Grid e o tráfego dos dados através de domínios usando o certificado de autoridade. Além disso, pesquisas são necessárias para encontrar o melhor número de processadores para a simulação hemodinâmica, paralelização de métodos matemáticos para as simulações numéricas e a segurança da informação. O projeto do software é uma fase fundamental para se ter um bom sistema, pois a partir dele tem-se uma visão completa sobre o que se deve fazer, aplicando estratégias que melhor possam atender às necessidades do software. Através dele, é possivel transformar os resultados de análise de requisitos em documentos que podem ser interpretados pelos desenvolvedores do sistema. 5. Requisitos e os Casos de Uso O modelo de caso de uso consiste em atores e casos de uso. Os Atores representam algo que interagem com o sistema, humano ou não. Um caso de uso é uma sequência de ações oferecidas pelo sistema, os quais interagem com um ator em particular. Em outras palavras, um caso de uso é o modo como o ator utiliza o sistema [Jacobson and Bylund 2000]. A figura 2 mostra o diagrama de caso de uso para os requisitos definidos anteriormente, logo após, são descritos os atores e os casos de uso do sistema responsável por fazer com que o HeMoLab possa utilizar uma Grid computacional para o cálculo das simulações Atores Seguem os Atores que fazem parte do diagrama de Casos de Uso: HeMoLab: software para simulação hemodinâmica que interage com o sistema integrador, a fim de executar o resolvedor de simulações de forma paralela em Grid. Cluster remoto: máquinas pertencentes a um site que irão, efetivamente, executar o resolvedor numérico de forma paralela. Estas máquinas fazem interface com a Grid através de uma máquina denominada Computer Element (CE), que é o Front-end do cluster remoto Casos de Uso A seguir, são descritos os Casos de Uso - ações oferecidas pelo sistema, os quais se interagem com os atores: Configurar JDL: para cada job a ser submetido, um arquivo com extensão jdl deve ser configurado. Esta funcionalidade é responsável por definir como será feita a interação com o ambiente de Grid.

64 IX Workshop em Clouds, Grids e Aplicações 49 Receber resultado da simulação <include> Executar script remoto <include> HeMoLab Submeter jobs <include> Configurar jdl Cluster Remoto Monitorar execução Figura 2. Diagrama de Casos de uso para o sistema Cenário - definir forma de envio de arquivos: i) são informados quais arquivos devem ser enviados para as máquinas da Grid que têm como única função o armazenamento de arquivos; ii) são informados quais arquivos devem ser enviados diretamente ao CE. Submeter jobs: funcionalidade responsável por enviar o job para o cálculo das simulações, além de enviar os arquivos de entrada para a execução do resolvedor numérico. Cenário - submeter job e arquivos de entrada: i) arquivos de entrada são empacotados; ii) arquivos de entrada são criptografados; iii) os recursos computacionais são selecionados; iv) arquivos referentes ao modelo são enviados; v) job é submetido. Executar script remoto: funcionalidade responsável por iniciar a execução do script remoto e mover os arquivos do SE para o CE para início da resolução da simulação numérica. Cenário - executar arquivo remoto e iniciar execução do SolverGP: i) fazer download dos arquivos enviados ao SE; ii) enviar arquivos para os WorkerNodes; iii) receber arquivos de Saída. Receber resultados da simulação: funcionalidade responsável por monitorar o estado de um job e fazer o download dos dados de saída, caso o job tenha terminado sua execução. Cenário - recuperar dados de saída: i) monitorar estado do job: enviado, na fila, em execução, terminado ou falha; ii) fazer download dos arquivos de saída armazenados em um SE; iii) decriptografar arquivos de saída. Monitorar execução: funcionalidade responsável por permitir ao usuário do He- MoLab, observar a convergência da simulação através da leitura do arquivo de log, gerado durante a execução do resolvedor numérico. Cenário - observar saída produzida no arquivo de log: i) verificar se o job está em execução; ii) iniciar monitoramento de job.

65 50 Anais 6. Visões Arquiteturais Segundo [Clements et al. 2002], uma arquitetura estabelece restrições ou um baixo fluxo de atividades, e estas atividades devem produzir artefatos que são inerentes à arquitetura, mas a arquitetura não define a implementação A Visão de Componentes e Implantação Ainda segundo [Clements et al. 2002], uma visão de implantação mapeia processos para elementos de hardware: nós de processamento, canais de comunicação, memória e armazenamento. Os processos são os elementos de software geralmente utilizados neste tipo de visão. A visão de implantação mostra quais processos são alocados para cada elemento de hardware. Uma camada de serviços foi criada entre os SolverGP e os serviços fornecidos pelo GLite Middleware. A figura 3 mostra o diagrama de componentes e implantação deste sistema: Servidor HeMoLab HeMoLab <<canal direto>> <<internet>> User Interface 1 Integrador 3 Servidor de Arquivos Storage Element 2 <<internet>> <<internet>> Front-end Computer Element <<canal direto>> Nó 1 Worker Node Nó N WMS 4 5 Worker Node Legenda: 1 - Interface HeMoLab-Grid: Envio de arquivos pelo HeMoLab / resultado da simulação; 2 - Interface LFC: Download/Upload de arquivos de entrada; 3 - Interface Configuração de Jobs: Definição dos arquivos que devem ser enviados/processados remotamente; 4 - Interface Submissão/Retorno: Submissão de job para um site determinado. 5 - Interface Execução: Seleção de nós para processamento Figura 3. Diagrama de componentes e implantação O SolverGP usa o paradigma de programação MPI, permitindo executar uma tarefa de forma paralela em máquinas pertencentes a um cluster. O componente Integrador, (instalado na User Interface), é responsável por pegar o programa executável SolverGP e designar um site da Grid para a execução. O Nó alocado, chamado Computer Element (CE), é responsável por fornecer acesso ao cluster remoto e distribuir as tarefas para as várias máquinas pertencentes a este cluster. O componente Integrador é o componente responsável pela interface com o CE, que usa um script remoto para configurar as máquinas do cluster (Worker Nodes), a fim de executar as tarefas de forma paralela. O Workload Management System (WMS) é um conjunto de componentes de middleware Grid responsável pela distribuição e gestão de tarefas através de recursos da Grid. O

66 IX Workshop em Clouds, Grids e Aplicações 51 Storage Element (SE) e LFC File Catalog (LFC) são responsáveis por: gerenciar o armazenamento (fornecendo espaço de armazenamento para arquivos) e serviços de transferência de arquivos grandes, e facilitar a disponibilidade e localização de arquivos de dados exigidos pelos jobs dos usuários, respectivamente. Os arquivos localizados no SE são acessível por usuários e aplicativos de qualquer lugar da Grid, várias réplicas de um arquivo podem ser armazenadas em diferentes locais e não podem ser alteradas (apenas removidas ou substituídas). Resumindo, o componente Integrador é responsável por: i) criar uma interface entre o HeMoLab e o CE, a fim de iniciar o script remoto para a execução do SolverGP; ii) criptografar os arquivos de entrada e descriptografar os dados de saída através de uma chave privada usando o certificado digital do usuário; iii) acionar os recursos para monitoramento de jobs, exigidos pelo HeMoLab para acompanhar a simulação, a fim de saber se o problema está convergindo. iv) receber os arquivos de saída gerados remotamente, e enviá-los para exibição no HeMoLab A Visão de Módulos do Sistema A visão de módulos do sistema mostra como a funcionalidade é mapeada para a implementação, identificando as diferentes unidades de código e como elas se interagem. A camada de Integração faz interface com a Grid através do framework disponibilizado pelo middleware glite, que permite o uso do WMS (Interface do glite com a Grid computacional). O módulo Executor remoto e o Resolvedor numérico, são escritos em linguagens Shellscript e Fortran, respectivamente. A Figura 4 mostra o diagrama de módulos para o sistema descrito. <<sistema>> HeMoLab <<camada>> Integração Grid <<middleware>> glite <<módulo>> Executor remoto <<módulo>> Resolvedor numérico Figura 4. Diagrama de módulos do sistema

67 52 Anais Vale a pena ressaltar aqui, que os módulos Executor remoto e Resolvedor numérico não estão inicialmente instalados em um nó remoto. Estes módulos são enviados através da interface que a camada de integração faz com o glite. Apenas após determinar o site onde a simulação será executada, estes módulos são enviados. O executor remoto é o módulo capaz de disparar o Resolvedor numérico nas máquinas do cluster remoto A Visão de Execução A visão de execução visa descrever os elementos de hardware e os processos do sistema associados ao hardware. Para o diagrama utilizado nesta visão, será mostrado o fluxo de execução de forma mais resumida. Para cada interface, será feita uma descrição mais detalhada. A Figura 5 mostra o diagrama de execução com o fluxo de execução da simulação numérica do HeMoLab e sua interação com o ambiente de Grid. O WMS é um conjunto de componentes de middleware Grid responsáveis pela distribuição e gestão de tarefas através de recursos da Grid. O LFC faz o mapeamento da estrutura fisica dos SE para nomes virtuais. Interface com HeMoLab 5 LFC 1 4 LFC 3 User Interface Storage Element Computer Element WMS 2 Interface com os Worker Nodes Figura 5. O fluxo de execução de uma submissão de Job A User Interface (UI), considerada parte do WMS, é uma máquina de submissões, o ponto de entrada para a Grid. O componente Integrador está instalado na UI e contém o arquivo JDL, responsável por definir como será feita a interação com o ambiente de Grid. De acordo com a numeração no diagrama de execução (Figura 5), segue a explicação para o fluxo de execução: 1. Antes de submeter um job para processamento remoto, três arquivos devem ser armazenados no SE: i) inputfiles - arquivos que foram gerados pelo HeMoLab, exigidos para o resolvedor numérico; ii) solvergp - o executável do solvergp, responsável pela simulação numérica, iii) libs - bibliotecas do MPI e do HeMoLab, necessários para implementar as simulações numéricas. Os arquivos de entrada enviados para o SE são criptografados na interface do usuário, usando o Secure-store e a chave privada do usuário responsável pela submissão do job. 2. Um arquivo JDL é configurado para definir quais arquivos serão enviados para o CE através do WMS. Usando os parâmetros inputsandbox e outputsandbox, é possível definir quais arquivos serão enviados e recebidos pela UI. Três arquivos são enviados

68 IX Workshop em Clouds, Grids e Aplicações 53 para o CE através do WMS: i) solver.sh - script responsável por fazer o download dos arquivos armazenados no SE e iniciar a execução do SolverGP, descrito anteriormente; ii) watchdog - arquivos usados para permitir o acompanhamento on-line das etapas de execução da simulação; iii) Secure-Store - bibliotecas necessárias para decriptografar os arquivos de entrada. 3. O script remoto é executado, os arquivos são movidos do SE para o CE, a simulação numérica é iniciada e, finalmente, os dados de saída são gerados. No momento em que os dados de saída são gerados, podemos monitorar a convergência do processo de simulação, abrindo uma sessão Watchdog para acompanhar, em tempo real, os problemas que podem ter ocorrido na simulação numérica, ou verificar os arquivos de saída para análise imediata. 4. Os arquivos de saída são enviados para o SE e os arquivos de log são retornados para a UI através do WMS. 5. Os arquivos de saída são movidos do SE para a UI, para que sejam enviadas para exibição no HeMoLab. 7. Projeto Detalhado do Sistema A especificação detalhada dos módulos será expressa por meio dos diagramas UML de classes e de sequência. Não será abordado o diagrama UML de pacotes, por se achar inadequado para a simplicidade que este diagrama seria Diagrama de Classes Um diagrama de Classes descreve os tipos de objetos presentes no sistema e os vários tipos de relacionamentos estáticos existentes entre eles, mostram as propriedades e as operações de uma classe e as restrições que se aplicam à maneira como os objetos estão conectados [Fowler 2004]. Para o diagrama de classes, serão descritos: o propósito de cada classe, uma breve narrativa do funcionamento de cada classe, uma definição detalhada da interface de cada classe e suas dependências/restrições com outras classes. A Figura 6 mostra o diagrama de classes para o sistema proposto: Classe Jdl: classe que provê um mecanismo para armazenamentos das informações sobre o job que será submetido: i) inputfiles: caminho para os arquivos de entrada necessários para a resolução da simulação; ii) outputfiles: caminho para o arquivo onde deve ser escrito o resultado da simulação; iii) blacklist: endereço de sites que não devem ser escolhidos para executar o resolvedor numérico; iv) numberofcores: número de núcleos necessários para executar o resolvedor numérico; v) jobtype: tipo do job; vi) filter: requisitos para execução do resolvedor numérico; vii) filetoexec: nome do arquivo que deve ser executado remotamente. Para cada atributo da classe, existem os métodos get e set associados. Estes, são utilizados para armazenar e recuperar os valores dos atributos, descritos anteriormente. Um método, chamado createjdl(), é responsável por escrever os dados de cada atributo em um arquivo com extensão jdl. Classe Glite: classe responsável por fazer interface com o framework do glite, desta forma, é possível tratar os resultados antes do processamento no Integrador.

69 54 Anais Figura 6. Diagrama de classes Classe Integrator: classe responsável pela comunicação entre o glite e as outras classes pertencentes ao sistema: i) dataout: atributo que armazena o caminho no qual os arquivos recuperados da Grid estão armazenados. Atributos get e set estão associados a este atributo; ii) encrypt() e decrypt(): métodos responsáveis por criptografar e decriptografar arquivos de entrada e saída; iii) pack() e unpack() métodos responsáveis por empacotar e desempacotar arquivos; iv) filetose(): responsável por fazer o tráfego de dados para a Grid; v) filesfromse: responsável por recuperar dados armazenados em nós da Grid. Classe Submiter: classe responsável pela submissão de jobs e identificação dos jobs enviados ao glite: i) id: atributo que armazena a identificação de um job submetido à Grid. Métodos get e set são associados a este atributo; ii) submitjob(): a partir de um arquivo jdl configurado, o método submete o job associado. Classe Monitor: classe responsável por iniciar a sessão para analisar a saída de jobs que estejam em execução: i) startslogmonitor(): a partir de um job em execução (running), este método permite que uma sessão seja aberta, a fim de verificar o arquivo

70 IX Workshop em Clouds, Grids e Aplicações 55 de log gerado pela simulação que está sendo processada; ii) status(): responsável por verificar o estado de um job submetido ao glite Diagrama de Sequência O diagrama de sequências é uma representação comportamental, que indica como eventos provocam transições de objetos para objetos. Em suma, o diagrama de sequência é uma versão abreviada do caso de uso, uma representação de como os eventos causam fluxo de um objeto para outro como função do tempo [Pressman 2004]. A Figura 7 mostra o diagrama de sequências para o sistema abordado: Figura 7. Diagrama de sequência 8. Implementação Pretende-se implementar o integrador junto ao software HeMoLab, implementado com base no Paraview III [Moreland 2009]. Este, além de utilizar diversas classes próprias, utiliza a bilbioteca VTK e C++ como linguagem de programação principal. Como biblioteca de interface gráfica será utilizado Qt [Nokia ]. Para acessar as funções do glite diretamente da aplicação, pretende-se utilizar a API C++ disponibilizada por este. Desta forma, pretende-se facilitar os processos de busca de recursos computacionais (que satisfaçam os requisitos da aplicação), submissão dos jobs, acompanhamento da simulação e, por fim,

71 56 Anais busca de resultados. Uma vantagem do uso da API é que, os estágios acima citados, podem ser processados com um menor nível de controle interativo do usuário da aplicação, provendo assim um ambiente mais amigável e, ao mesmo tempo, que utiliza os recursos em Grid na etapa de computação de alto desempenho. A Figura 8, mostra o botão que, ao ser acionado, levará o fluxo de execução para o software integrador, reponsável por fazer com que o resolvedor numérico seja processado em uma Grid Computacional usando o glite Middleware. Figura 8. Tela do HeMoLab com o botão Run, que irá acionar o integrador 9. Conclusões e Trabalhos Futuros Doenças relacionadas com o sistema cardiovascular humano, tais como doenças cardíacas coronarianas, são as principais causas de morte no mundo. Desta forma, modelar o comportamento deste sistema é vital para melhor compreendê-lo e pode ajudar na criação de novas terapias. O processo de modelagem pode fazer uso de modelos simplificados (1D), modelos com maior nível de detalhes (3D), e modelos acoplados (1D-3D). Esses tipos de modelos permitirão a realização de estudos de patologias cardiovasculares relacionadas, por exemplo, ao processo de envelhecimento da artéria aorta, aneurismas e estenoses, e simulação de procedimentos cirúrgicos, como a inserção do stent, a criação de revascularização, etc. No entanto, a simulação numérica de modelos 3D ou modelos acoplados têm mostrado que o tempo de processamento exigido é da ordem de semanas ou mesmo meses em modelos mais complexos. Desta forma, o uso de técnicas de computação de alto desempenho, como a computação em Grid é vital para o sucesso da adoção da ferramenta pela comunidade médica.

72 IX Workshop em Clouds, Grids e Aplicações 57 Este trabalho apresentou a modelagem conceitual do sistema integrador que permite com que um sistema de simulação hemodinâmica possa ser processado em uma Grid Computacional. Foram especificados os requisitos, a arquitetura e a correspondência entre os elementos descritos em ambas as especificações. A especificação de requisitos foi expressa em linguagem natural, além do diagrama UML de caso de uso. A especificação arquitetural contemplou os três principais tipos de visões arquiteturais: execução, módulo e implantação. Foi apresentado um projeto detalhado do sistema integrador, através de diagramas UML de pacotes, de classes, e de sequência, além de incluir um plano de testes descrevendo casos de teste unitário e de integração. Como trabalho futuro, espera-se a realização de simulações computacionais mais intensas para utilização de um número maior de processadores. Um aspecto muito importante é que o uso da computação em Grid pode ajudar a especificação do número ideal de processadores usados na resolução de um modelo, ou seja, fazer um estudo mais profundo da curva de speedup do SolverGP. Isso permitirá saber com antecedência a quantidade aproximada de núcleos que resolvem um modelo com um número específico de pontos em melhor tempo. Também será utilizada a API do glite para a construção de um portal Web para acompanhamento dos jobs executados na Grid. Durante este trabalho, várias lições foram aprendidas, entre elas podemos destacar: i) a necessidade de um projeto bem definido para tornar o software robusto; ii) o uso de ferramentas de projeto para ajudar na melhor visualização do produto final, afim de tornar cada vez menor o uso de refatoração. Dentre as principais contribuições, podemos destacar a possibilidade de simular múltiplos jobs de forma paralela, um em cada cluster remoto, utilizando de forma gráfica a configuração para que isto seja possível. Finalmente, espera-se que o uso do aplicativo possa ajudar na difuzão do uso da ferramenta HeMoLab entre a comunidade de pesquisa médica brasileira, pois mais simulações podem ser feitas ao mesmo tempo. Espera-se que estas simulações também possam ser resolvidas em um tempo menor que o praticado atualmente. Referências Para mais detalhes sobre o projeto HeMoLab, veja [HeMoLab ]. Blanco, P. J., Pivello, M. R., Urquiza, S. A., and Feijóo, R. A. (2009a). Building coupled 3d 1d 0d models in computational hemodynamics. In 1st International Conference on Mathematical and Computational Biomedical Engineering - CMBE2009, Swansea, UK. Blanco, P. J., Pivello, M. R., Urquiza, S. A., and Feijóo, R. A. (2009b). On the potentialities of 3d-1d coupled models in hemodynamics simulations. Journal of Biomechanics, 42(7): Bruno, R., Barbera, R., and Ingra, E. (2009). Watchdog: A job monitoring solution inside the eela-2 infrastructure. In Proceedings of the Second EELA-2 Conference, Choroni, VE. Burke, S., Campana, S., and et. al. (2009). glite User Guide. cern.ch/glite/.

73 58 Anais Clements, P., Bachaman, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., and Stafford, J. (2002). Documenting Software Architecture Views and Beyond. Addison- Wesley. Forum, M. P. (1994). Mpi: A message-passing interface standard. Technical report, Knoxville, TN, USA. Fowler, M. (2004). UML distilled: a brief guide to the standard object modeling language. Pearson Education, Inc, 3rd edition. Gropp, W., Lusk, E., and et. al. (2009). MPICH2 - Message-Passing Interface (MPI) Implementation Users Guide. Argonne National Laboratory, US. mcs.anl.gov/research/projects/mpich2/. HeMoLab. Hemodynamics modeling laboratory. Jacobson, I. and Bylund, S. (2000). The road to the unified software development process. Cambridge University Press. Mackay, J., Mensah, G. A., Organization, W. H., for Disease Control, C., and Prevention (2004). The atlas of heart disease and stroke - deaths from coronary heart disease. World Health Organization, Geneva, page 112. Moreland, K. (2009). The ParaView Tutorial - A Parallel Visualization Application. Sandia National Laboratories. Nokia. Qt - cross-platform application and ui framework. products/. Pressman, R. S. (2004). Software Engineering Software Engineering: A Practitioner s Approach, 6th Ed. McGraw Hill, 6th edition. Scardaci, D. and Scuderi, G. (2007). A secure storage service for the glite middleware. International Symposium on Information Assurance and Security.

74 IX Workshop em Clouds, Grids e Aplicações 59 Construindo Infraestruturas Computacionais Distribuídas e Seguras Baseadas em Receptores de TV Digital Rostand Costa 1, 2, Giuliano Maia 1, Guido Lemos de Souza Filho 1, Dênio Mariz Sousa 1, Francisco Vilar Brasileiro 2 1 Laboratório de Aplicações em Vídeo Digital LAVID Universidade Federal da Paraíba (UFPB) - João Pessoa, PB Brasil 2 Laboratório de Sistemas Distribuídos LSD Universidade Federal de Campina Grande (UFCG) - Campina Grande, PB - Brasil {rostand, {guido, Abstract. Building a large scale, distributed computational infrastructure based on Digital Television (DTV) receivers enables a potential for expressive processing power for the execution of Many Task Computing (MTC) applications. Since the DTV receivers are non dedicated public resources and also inherently volatile and not reliable there are several challenges involved in the operation of such systems and the establishment of a secure, robust and efficient communication mechanism. This work presents a security model for providing processing services atop of a DTV system infrastructure, identifying the main threats to the communication between its components and discussing the appropriate countermeasures. Resumo. A construção de uma infraestrutura computacional distribuída de larga escala baseada em receptores de TV Digital gera um potencial de processamento expressivo para a execução de aplicações MTC Many Task Computing. Entretanto como se tratam de recursos públicos não dedicados e inerentemente voláteis e não confiáveis há diversos desafios envolvidos na operação de tais sistemas e no estabelecimento de um mecanismo de comunicação seguro, robusto e eficaz. Este trabalho apresenta um modelo de segurança para a oferta de serviços de computação sobre uma infraestrutura distribuída baseada em receptores de TV Digital, identificando as principais ameaças à segurança da comunicação entre seus componentes e apresentando as correspondentes contramedidas aplicáveis. 1. Introdução A crescente popularidade da Internet a fez extrapolar ambientes acadêmicos, científicos e empresariais e ocupar as residências e o cotidiano das pessoas de uma forma quase que onipresente. Este fenômeno tem trazido a reboque uma série de avanços que estão mudando a forma como computadores são usados hoje em dia. A disponibilidade de acesso a redes de alta velocidade combinada com a crescente oferta de computadores com alta capacidade de processamento, agora cada vez mais acessíveis às camadas da população de mais baixa renda, é um fenômeno em escala mundial. Visando o aproveitamento do poder computacional que este enorme contingente de recursos distribuídos mundialmente representa, abrem-se novas oportunidades técnicas, principalmente com a possibilidade de uso desses recursos para resolver problemas de grande escala nas áreas da ciência, engenharia, medicina, física etc. Os principais atrativos desta idéia são a possibilidade de alocar uma enorme quantidade de recursos para o processamento distribuído de uma aplicação paralela (centenas de milhares de

75 60 Anais computadores conectados via Internet, por exemplo) e fazê-lo a um custo muito menor do que alternativas tradicionais, baseadas em supercomputadores paralelos. O cenário tecnológico atual é fortemente orientado para a convergência e marcado pelo surgimento de serviços e dispositivos que combinam tecnologias que surgiram inicialmente em contextos distintos. Desde celulares com capacidade de captura de imagens e vídeo ao provimento de serviços agregados de telefonia, internet e televisão, dos modems móveis para acesso à Internet aos celulares de terceira geração com grande memória e processadores poderosos, praticamente tudo que é digital é potencialmente convergente. Um exemplo clássico de dispositivos com poder computacional relevante são os receptores de TV Digital (TVD) [MORRIS 2005], cuja presença nas residências é uma tendência com a digitalização da televisão, a mais popular das mídias de massa. A TV Digital oferece recursos que vão desde a melhoria da qualidade da imagem à capacidade de interação com o conteúdo. Com a TVD o telespectador tem a possibilidade de exercer um papel mais ativo, interagindo com os programas de televisão, que além de áudio e vídeo, passam também a incorporar software de forma sincronizada. Para tanto, o receptor de TV Digital conta com características típicas de um computador: possui memória, processador, sistema operacional e capacidade de se conectar em rede. Esta miríade de dispositivos digitais recentes ou tradicionais, computacionalmente capazes, virtualmente conectados e eventualmente ociosos, se devidamente coordenados e agrupados, podem representar um potencial de processamento sem precedentes para a construção de infraestruturas computacionais distribuídas de larga escala. Many Task Computing (MTC) [RAICU 2008] é um paradigma de computação que explora a idéia de usar muitos recursos computacionais, eventualmente distribuídos, para processar tarefas menores em paralelo, em oposição à idéia de processar uma única tarefa grande em um único recurso computacional de maior capacidade. Há uma categoria de aplicações paralelas cujas tarefas são totalmente independentes umas das outras, definidas na literatura como aplicações Embarassingly Parallel Applications ou Bag-of-task Applications (BoT) [CIRNE 2003]. A vazão obtida quando se executa aplicações MTC, em geral, e BoT, em particular, sobre uma infraestrutura computacional distribuída depende diretamente da escala que a mesma permite. O tamanho do pool de processamento, definido como o número de processadores alocados, é o principal promotor de desempenho, enquanto que o esforço de coordenação envolvido é o principal fator de limitação. Para atingir uma vazão extremamente alta é necessário operar eficientemente em escala extremamente alta, assumindo que a distribuição de tarefas para os processadores disponíveis e o fornecimento de qualquer dado de entrada necessário ou coleta dos resultados gerados não sejam um gargalo. O uso eficiente da infra-estrutura por aplicações MTC com tarefas de curta duração (short-lived) requer a capacidade de instanciar um grande pool de recursos para uma aplicação a qualquer tempo e somente enquanto durar a execução da aplicação. Estes recursos podem ser depois realocados para aplicações diferentes. Além disso, para permitir a execução de um número ilimitado de aplicações de tipos distintos, é essencial que a configuração da infraestrutura, inclusive a instalação de qualquer componente de software específico da aplicação, possa ser realizada de forma leve em termos de complexidade e ágil em termos de tempo. Tal premissa deve continuar válida até mesmo considerando-se que a escala desejada esteja na ordem de centenas de milhões de nós de processamento. Em outras palavras, o usuário deve ser capaz de facilmente e rapidamente personalizar a infraestrutura de processamento inteira de acordo com as suas necessidades. Em resumo, para prover computação de vazão extremamente alta a um número grande de aplicações MTC, uma

76 IX Workshop em Clouds, Grids e Aplicações 61 infraestrutura de computação distribuída precisa oferecer: a) escalabilidade extremamente alta, controlando de centenas a milhões de nós de processamento indistintamente; b) instanciação sob demanda, possuindo mecanismos para descoberta, montagem e coordenação dos recursos dinamicamente; e c) configuração eficiente das aplicações, sem exigir nenhuma intervenção individual ou especializada. Infelizmente, as tecnologias atuais possuem limitações fundamentais que têm impactos ou na sua escala ou no seu alcance. Os sistemas para voluntary computing [ANDERSON 2002][ANDERSON 2004] provaram que é possível construir plataformas computacionais com milhões de nós para suportar a execução de aplicações MTC. Estes sistemas, entretanto, não possuem a flexibilidade das infraestruturas de desktop grids [LITZOW 1988][CIRNE 2006][ OLIVEIRA 2002][ ANDRADE 2007][ THAIN 2006], sendo uma solução válida somente para um subconjunto muito pequeno de aplicações que podem se beneficiar da vazão extremamente alta que eles podem entregar. A abordagem de computação voluntária (VC) tem sido bem sucedida apenas nos casos onde a aplicação possui um apelo que motive os usuários a participarem do projeto e doarem os seus projetos. Os casos de sucesso mais relevantes envolvem a busca pela cura de doenças e busca por vida extraterrestre. Por outro lado, as infraestruturas flexíveis atualmente disponíveis, como as baseadas no paradigma de cloud computing [WANG 2008], embora sejam, em tese, virtualmente inesgotáveis, estão limitadas tanto pela capacidade física dos provedores atuais quanto pelos modelos de negócios vigentes, que restringem a alocação de uma quantidade muito alta de nós de processamento [AMAZON 2010]. Em um trabalho anterior, os autores apresentaram uma proposta de uma arquitetura nova para computação distribuída que é ao mesmo tempo flexível e altamente escalável. Esta abordagem, chamada de OddCI On-Demand Distributed Computing Infrastructure [COSTA 2009], é suportada pela existência de milhões de dispositivos que podem, simultaneamente e sob demanda, ser acessados através de uma rede com suporte à transmissão em broadcast. Aferindo a viabilidade da arquitetura proposta, etapas anteriores da pesquisa demonstraram como ela pode ser modelada e implementada sobre um sistema de televisão digital. Como o estado real de uma rede de broadcast, em termos de quantidade e perfil dos recursos conectados, é desconhecido e os recursos potencialmente acessíveis são públicos, não dedicados e, inerentemente voláteis e não confiáveis, há diversos desafios envolvidos na operação segura de sistemas OddCI. Neste trabalho, é feita uma analise dos aspectos de segurança relacionados ao funcionamento de sistemas OddCI que, por suas singularidades, são submetidos de forma concomitante as falhas, ameaças e vulnerabilidades presentes em outros contextos apenas de forma isolada. Desta forma, os sistemas OddCI precisam lidar com aspectos de autenticação de fontes de mensagens, como os controles de segurança multicast [CANETTI 1999], ao mesmo tempo que precisam tratar da volatilidade de entrada e saída de nós, como fazem os sistemas distribuídos dinâmicos [LIMA 2009] enquanto precisam, simultaneamente, oferecer mecanismos de tolerância à sabotagem, como os presentes em computação voluntária [SARMENTA 2001]. O restante do texto está organizado como segue. Na Seção 2, será apresentada e discutida a arquitetura de sistemas OddCI. Na Seção 3, será detalhado o fluxo de operação de um sistema OddCI para identificação dos requisitos e definição dos objetivos de segurança que devem ser atendidos para conciliar as expectativas de cada um dos atores envolvidos. Na Seção 4, um Modelo de Segurança para Sistemas OddCI é proposto através da apresentação de primitivas básicas de segurança e do detalhamento do protocolo de uso

77 62 Anais das contramedidas selecionadas considerando o fluxo de operação descrito na Seção 2. A Seção 5 contém um estudo de caso que aponta a viabilidade de se implementar o modelo de segurança proposto em uma redes de TV Digital. A Seção 6 traz as considerações finais. 2. Arquitetura OddCI Na arquitetura OddCI, uma rede de broadcast padrão é aumentada com três componentes, um Provider, um Controller e um Backend; além disso, é assumido que os dispositivos acessíveis pela rede de broadcast também podem se comunicar com o Controller e o Backend através de um canal de comunicação individual (ponto-a-ponto e full-duplex), chamado canal de interação (Fig. 1). O Provider interage com os clientes e recebe os pedidos por instâncias OddCI, repassando-as, quando exequíveis, para que o Controller possa providenciar a sua instanciação. O Controller é o encarregado de montar e manter a infraestrutura computacional sob demanda propriamente dita, enquanto que o Backend é responsável pelas atividades de administração específicas de cada aplicação executada. Estas atividades podem incluir escalonamento, provisão de dados de entrada, como também o recolhimento e, eventualmente, o pós-processamento dos resultados gerados pela aplicação distribuída. Uma característica notável desta arquitetura é que, diferentemente de qualquer alternativa para computação distribuída, não são, necessariamente, requeridos identificação prévia ou procedimentos de registro para os recursos existentes. Simplesmente, a infraestrutura não existe até que seja solicitada e ativada através do canal de broadcast. Por causa desta singularidade, a arquitetura é chamada de OddCI (On-Demand Distributed Computing Infrastructure) e o processo de ativação de uma instância OddCI através do envio de mensagens de controle (wakeup messages) através do canal de broadcast é chamado de wakeup process. Os dispositivos que executarão o processing node agent (PNA) são descobertos e inicializados através de uma wakeup message (WM) enviada via broadcast, que contém o executável do PNA. No caso de TV Digital, por exemplo, este processo é nativo e executado sempre que uma transmissão contém uma aplicação com o flag autostart setado. Alguns mecanismos do Controller regulam a quantidade de PNA efetivamente ativados, posto que todos os dispositivos conectados na rede de broadcast serão atingidos pela WM. Client Provider Backend Controller Return Channel Broadcast Channel Processing Node Agents PNA 1... PNA N Figura 1. A arquitetura geral de um sistema OddCI A camada de software que suporta a criação de sistemas OddCI está estruturada nos quatro componentes descritos abaixo: O Client (cliente) é responsável por definir a imagem (código executável a ser processado pelos PNA) e os dados de entrada que eventualmente serão necessários. O cliente então submete um pedido de criação de uma instância OddCI ao Provider e aguarda o recebimento dos resultados produzidos, os quais são repassados através do Backend. O Client é uma aplicação manuseada por um usuário que interage com um Provider para obtenção dos serviços de computação de tarefas. O Provider (provedor) é responsável por criar, manter e destruir as instâncias OddCI de acordo com as solicitações dos clientes. O Provider envia as instruções adequadas de tal

78 IX Workshop em Clouds, Grids e Aplicações 63 forma que cada instância OddCI solicitada possa ser dinamicamente provisionada ou liberada pelo Controller. O Controller (controlador) é encarregado de configurar a infra-estrutura distribuída, conforme instruído pelo Provider, através da formatação e envio, via o canal de broadcast, de mensagens de controle, incluindo imagens de software, necessárias para construir e manter as instâncias OddCI. Ele recebe informações dos nós de processamento ativos sobre o seu estado e configuração, consolida-as e as repassa para o Provider. Backend (retaguarda) é responsável pela comunicação direta com o software específico da aplicação sendo executado em cada nó de processamento; mensagens são enviadas dos nós de processamento para o Backend para solicitar o envio de novas tarefas (dados e/ou programas) e para transferir de volta os resultados de cada tarefa. O Backend deve ser configurado e adequadamente provisionado para cada aplicação específica sendo executada. Processing Node Agents (PNA) (agentes processadores) são os componentes responsáveis pelo gerenciamento e carga de novas imagens de aplicações na memória do dispositivo e pela execução da imagem carregada. O PNA é carregado pelo dispositivo em resposta a uma wakeup message e se comunica regularmente com o Controller através do canal de interação para sinalizar o seu estado corrente. O modelo básico de funcionamento de Sistemas OddCI (criação e operação) pode ser ilustrado através dos fluxos de troca de mensagens possíveis entre os diversos componentes, conforme ilustrado na Figura 2. Client Provider Controller PNA Application Backend Pedido de Instância Instância Rejeitada Verifica Viabilidade Instância Inviável Pedido de Instância Instância Aceita Verifica Viabilidade Instância Viável Comando p/criação Wakeup Process Avisa PNA Disponível Descarta PNA Fim de execução. Laço: O Controller dispara comandos via broadcast para regenerar o tamanho da instância sempre que o número de PNA ativos cai para um determinado patamar. Aceita PNA Avisa PNA Ativo Laço: para cada intervalo de sonda Criação ambiente seguro Carrega aplicação Obtém nova tarefa Envia Resultados Laço: até acabarem as tarefas Figura 2. Sequência de operação básica de um sistema OddCI Inicialmente, o Client solicita ao Provider a criação de uma instância OddCI, fornecendo a imagem da aplicação a ser executada em cada processador. O Provider valida o cliente e a imagem da aplicação e, baseado no histórico e em estimativas dos recursos disponíveis no momento, acata (ou não) o pedido. Em seguida, o Provider formata e encaminha uma mensagem de controle para que esta seja transmitida pelo Controller.

79 64 Anais O Controller, após validar o Provider e a mensagem de controle, providencia sua transmissão, via broadcast, para todos os dispositivos conectados. O dispositivo, ao receber a mensagem de controle contendo o código do PNA e a imagem da aplicação cliente, inicia o seu tratamento, carregando o PNA. A primeira providência do PNA ao ser carregado é usar o canal de interação para sinalizar ao Controller a sua disponibilidade e, caso seja aceito, cria um ambiente seguro, carrega a aplicação cliente e inicia a sua execução. A aplicação cliente também usa o canal de interação para obter tarefas e enviar resultados para o Backend diretamente. Enquanto a aplicação cliente está sendo executada, o PNA, em um determinado intervalo, envia mensagens para o Controller através do canal de interação para sinalizar que continua ativo. Consolidando as mensagens recebidas de todos os PNAs integrantes da instância, o Controller pode monitorar o seu tamanho e disparar novas mensagens de controle via broadcast para cooptar novos dispositivos sempre que necessário. Opcionalmente, o Backend pode repassar ao Client informações sobre a vazão sendo fornecida pela instância OddCI. O Client, neste caso, pode solicitar ao Provider que aumente ou diminua o tamanho da instância, reiniciando o ciclo. Em tal cenário, relevantes questões de segurança estão envolvidas: Como garantir o sigilo e a integridade dos dados e resultados dos clientes durante o seu tráfego no sistema OddCI? Como garantir a legitimidade de cada nova aplicação dinamicamente carregada em um PNA? Como estabelecer canais de comunicação seguros envolvendo partes voláteis e não identificadas previamente? Como conciliar as necessidades de segurança de cada um dos atores envolvidos? 3. Requisitos de Segurança Do ponto de vista de segurança, cada ator de um Sistema OddCI possui as suas próprias expectativas e interesses. O Client espera que os dados das suas aplicações estejam protegidos durante todo o ciclo de vida da instância OddCI, tanto de adversários quanto dos outros atores. O Provider precisa autenticar os clientes e garantir que os recursos disponíveis sejam usados apenas por instâncias legítimas. O Controller precisa validar as mensagens de controle a serem transmitidas para evitar interrupção ou falhas no seu serviço. O Backend precisa autenticar os PNA que enviam resultados e os clientes que o acessam para recuperar tais resultados. Finalmente, os proprietários dos equipamentos que executarão o PNA e as aplicações estão interessados, principalmente, em que a execução das aplicações não interfira no funcionamento dos seus dispositivos. Além das preocupações específicas de cada ator, todos estão sujeitos às repercussões e impactos causados por tentativas de sabotagem ou falhas localizadas em componentes, intencionais ou não. Os requisitos de segurança que precisam ser atendidos em nosso contexto podem ser consolidados a partir da observação da sua dinâmica de interações. A Figura 3 traz as interações básicas entre os participantes de um Sistema OddCI. 6 Cliente 1 Backend 5 PNA 4 3 Provider 2 Controller Figura 3. Interações Básicas entre Participantes de um Sistema OddCI

80 IX Workshop em Clouds, Grids e Aplicações 65 O fluxo (1) requer a autenticação do cliente pelo Provider e a confidencialidade na comunicação entre eles como forma de proteger a imagem (código a ser executado) e os dados enviados para o Provider. No fluxo (2), o Controller também precisa autenticar o Provider e garantir confidencialidade na troca de mensagens de controle. No fluxo (3), que ocorre entre o PNA e o Controller, o PNA precisa receber e enviar mensagens de forma confidencial, além de autenticar a origem da mensagem de controle recebida via broadcast visando garantir que elas são realmente oriundas do Controller. Entretanto, o canal de broadcast estabelece uma comunicação de um-para-muitos entre o Controller e os equipamentos conectados, o que requer mecanismos de autenticação e confidencialidade distintos dos usados nos fluxos (1) e (2). Nos fluxos (4) e (5), o PNA e a aplicação cliente precisam de confidencialidade para estabelecer comunicações seguras com o Controller e o Backend, respectivamente. Isto pode ser obtido com facilidade se as partes envolvidas puderem ser devidamente identificadas. Como o receptor é um componente volátil e não conhecido previamente, a sua autenticação precisa ser tratada de forma especial, não sendo aplicável o uso das formas de autenticação mais tradicionais já descritas. O uso de chaves embutidas (usando os conceitos de embedded keys [BOESGAARD 2007] e ofuscamento de programas [D ANNA 2003], por exemplo) dentro do código do PNA e da aplicação cliente é uma alternativa de associar uma identidade para estes processos que executam nas partes não controladas do sistema, tornando-as passíveis de serem autenticadas pelos processos de retaguarda equivalentes no Controller e no Backend. O uso das técnicas de chaves embutidas e de ofuscamento, além de eficiente, ganha uma vantagem adicional no contexto OddCI no qual as instâncias são formadas dinamicamente. Como o código do PNA e da aplicação fornecida pelo cliente são enviados em cada wakeup message, as chaves embutidas e a técnica de ofuscamento podem ser alteradas frequentemente para ficarem obsoletas com rapidez. Isto reduz o tempo de exposição de tais mecanismos e diminui a eficácia de ataques destinados a obter tais chaves e interferir na comunicação entre o Controller e o PNA e entre a aplicação e a sua retaguarda. A confidencialidade da imagem da aplicação precisa ser garantida até a sua efetiva execução, sendo transversal para os fluxos (1), (2) e (3). Confidencialidade transversal, neste caso, significa que a mensagem seja enviada, sequencialmente, da parte 1 para a parte N, mas que só possa ser aberta pelo destino final (Princípio da Não Interferência Intransitiva [SCHELLHORN 2000]). Por exemplo, os dados da aplicação enviados pelo cliente e retransmitidos pelo Provider e pelo Controller, só devem ser abertos pela aplicação cliente quando a mesma for iniciada pelo PNA. Adicionalmente, o Backend precisa validar a integridade dos resultados recebidos para se proteger de falhas bizantinas [LIMA 2009] ou tentativas de sabotagem [SARMENTA 2001], o que pode exigir controles específicos que consideram a semântica e a sintaxe adotada em cada aplicação. O fluxo (6) é opcional e envolve uma comunicação particular e controlada entre o cliente e a sua estrutura de retaguarda que não será abordada diretamente aqui. Entretanto, pelas suas características, o mesmo tratamento aplicado nos fluxos (1) e (2) também pode ser utilizado. De forma consolidada, a Tabela 1 traz os objetivos de segurança extraídos dos requisitos levantados.

81 66 Anais Tabela 1. Objetivos de Segurança OS OBJETIVO DE SEGURANÇA O1 Autenticação mútua de partes previamente identificadas nos fluxos (1) e (2) O2 Autenticação unilateral de partes previamente identificadas no fluxo (3) O3 Autenticação unilateral de partes voláteis e não identificadas nos fluxos (4) e (5) O4 Comunicação síncrona segura para os fluxos (1), (2), (4) e (5) O5 Comunicação assíncrona segura para o fluxo (3) O6 Comunicação transversal segura para os fluxos (1), (2) e (3) O7 Controle semântico fim-a-fim no fluxo (5) O8 Confidencialidade e integridade em todos os fluxos 4. Modelo de Segurança No modelo de segurança descrito neste trabalho, propõe-se um conjunto de primitivas e um protocolo de uso que permitam endereçar os requisitos de segurança 1 envolvidos no fluxo operacional de um sistema OddCI Primitivas PRIMITIVA H = Hash( m ) Y = Crypt( m, k ) X = DeCrypt( m, k ) Tabela 2. Primitivas Básicas DESCRIÇÃO Calcula um hash não inversível para a mensagem m Cifra a mensagem m usando a chave k Decifra a mensagem m usando a chave k K = KeyGen( id 1, id 2 ) Gera uma chave para uso em sessão de comunicação entre as identidades id 1 e id 2 C = SecureChannel( d ) SecureSend( c, m ) M = SecureReceive( c, m ) P id =PublicKey( id ) S = Sign( m, k ) Verify( m, id ) Auth( id ) Challenge( m ) Validate( m ) I = FormatImage( e, d, a) O = CreateInstance( c ) Broadcast( c, m ) ProcessID( p, id ) Estabelece um canal de comunicação seguro C com o destino d. O canal poderá ser usado para envio de mensagens subseqüentes. O estabelecimento do canal seguro présupõe a autenticação mútua dos parceiros envolvidos Envia uma mensagem m usando o canal seguro c Recebe uma mensagem M usando o canal seguro c Retorna P id, a chave pública associada à identidade id Assina a mensagem m usando a chave privada k Verifica a autenticidade e integridade da mensagem assinada m pelo autor id e retorna TRUE caso a assinatura seja autêntica e integra ou FALSE caso contrário Verifica a autenticidade da identidade id mediante algum protocolo síncrono de autenticação baseado em troca de certificados ou um protocolo de desafios Prepara a mensagem m para atuar como um desafio em um controle fim-a-fim entre aplicações. Seguindo algum protocolo ou frequência, mensagens normais serão substituídas por mensagens especiais com a finalidade única de validar o lado cliente Valida a mensagem m recebida em um regime de controle fim-a-fim entre aplicações. A comparação da resposta recebida com a resposta correta esperada servirá para validar o lado cliente, inibindo a ação de sabotadores e falhas não intencionais Cria uma imagem I a partir do executável e, dos dados d e da aplicação a Solicita a criação de uma instância OddCI O através do canal seguro c. Assume-se que o canal seguro é estabelecido com um elemento do tipo Provider Envia pelo canal de broadcast c a mensagem m Vincula um processo p à identidade id através de algum mecanismo que permita a inserção de tokens embutidos no código fonte de um processo 1 Não está contemplado no modelo proposto o tratamento de ameaças físicas de nenhuma natureza nem ameaças em nível de corrupção de hardware ou software básico, reuso de memória ou acesso direto a registradores internos, não sendo possível garantir total isolamento e privacidade em cenários onde há a possibilidade de comprometimento dos dispositivos envolvidos.

82 IX Workshop em Clouds, Grids e Aplicações 67 As primitivas de segurança necessárias para o atendimento dos objetivos de segurança identificados na seção anterior estão relacionadas na Tabela 2. Neste documento foi assumido que tais primitivas representam apenas conceitos e não funções atômicas, mas que são plenamente suportadas computacionalmente pelos recursos existentes em cada componente de um Sistema OddCI Protocolo de Uso Fundamentalmente, o modelo de segurança que estamos propondo é baseado em camadas de envelopes criptográficos e técnicas de controle fim-a-fim que permitem ativar autenticação, confidencialidade e também proteção contra falhas e sabotagens. Mesmo considerando que uma cadeia de confiança [SANTIN 2002] possa ser estabelecida entre os atores, a privacidade de comunicação em cada um dos fluxos identificados na Fig. 4 também deve ser garantida. A seguir, iremos detalhar o protocolo de utilização do modelo de segurança proposto em um Sistema OddCI. Seja I={c, p, o, b, P} uma instância OddCI onde c é o cliente, p é o provedor, o é o controlador, b é a retaguarda e P é o conjunto de agentes processadores (receptores). No nosso modelo, o cliente solicita ao provedor a criação de uma instância OddCI. Assumindo que obteve sucesso, o provedor retorna um envelope contendo um identificador único da instância criada (OddCI_ID). O cliente arbitra uma chave a ser usada na comunicação com a retaguarda para acesso as tarefas e resultados (BackendKey) e embute esta chave no executável da sua aplicação que rodará nos agentes em P. O cliente acrescenta nos dados da aplicação informações sobre os endereços dos hosts que compõem a infraestrutura de retaguarda. A infraestrutura de retaguarda usará a mesma chave para autenticar os dispositivos que em breve se conectarão para estabelecer um canal seguro de comunicação para recepção de eventuais resultados e envio de novas tarefas. Em seguida, um envelope é criado pelo cliente para conter os dados da sua aplicação, o qual é enviado para o provedor p. Salienta-se que o estabelecimento do canal seguro pré-supõe a autenticação mútua dos parceiros, como apresentado na Tabela 1. A sequência de primitivas abaixo representa o que foi discutido. sc_provider = SecureChannel( p ) OddCI_ID = createinstance( sc_provider ) executável = ProcessID( executável, BackendKey ) AppImage = FormatImage( executável, Crypt( dados, BackendKey ), OddCI_ID, BackendInfo ) SecureSend( sc_provider, AppImage ) Do lado do provedor p, a mensagem do cliente c é recebida de forma confidencial, da seguinte forma: sc_client = SecureChannel( c ) AppImage = SecureReceive( sc_client ) O passo seguinte para o provedor p é repassar para o controlador o uma mensagem de controle contendo a AppImage e instruções sobre o tipo de instância a ser criada. ControlMessage = Formata( AppImage, params, OddCI_ID ) sc_controller = SecureChannel( o ) SecureSend( sc_controller, ControlMessage ) O controlador c, no fluxo (2), recupera a mensagem de controle, gera uma chave randômica exclusiva (InstanceKey) para a instância OddCI_ID e a embute no código do PNA. Na prática essas informações servirão de credenciais para autenticar cada PNA, de maneira que o controlador apenas aceitará como participante da instância o PNA que apresentar a InstanceKey correta como credencial. Em seguida, o controlador formata, cifra

83 68 Anais e depois assina a aplicação recebida do provedor e a propaga através do canal de radiodifusão para todos os receptores conectados ao serviço. sc_provider = SecureChannel( p ) ControlMessage = SecureReceive( sc_provider ) InstanceKey = Random( OddCI_ID ) PNA = ProcessID( PNA, InstanceKey ) ControlMessage = Formata( ControlMessage, PNA ) M = Crypt( Sign( ControlMessage, Kpriv c ) SignControlMessage = Sign( M, Kpriv c ) Broadcast( BroadcastChannel, SignControlMessage ) Todos os dispositivos conectados ao canal de broadcast recebem a mensagem que contém a aplicação assinada. Conforme o modelo OddCI [COSTA 2009], o dispositivo fará a validação da mensagem usando a chave pública da controlador que está autenticada por uma autoridade certificadora bem conhecida. Validada a mensagem pelo dispositivo, o PNA é carregado e faz a comunicação com o Controller usando o identificador InstanceKey, que traz embutido, como chave para garantir a autenticação e o sigilo no fluxo (4). O passo seguinte do PNA, caso seja aceito pelo Controller, é iniciar a aplicação cliente propriamente dita, que de posse da chave BackendKey, pode finalmente abrir o primeiro envelope criado pelo Client e recuperar os dados da aplicação. Esta mesma chave é usada como identificador para estabelecer um canal seguro com a retaguarda através do fluxo (5). Por sua vez, o fluxo (6), entre o Backend e o Client, é bem específico e pode usar mecanismos próprios. As chaves embutidas na aplicação cliente (BackendKey) e no PNA (InstanceKey), criadas de forma exclusiva e independente pelo Client para cada aplicação e pelo Controller para cada instância OddCI representam uma adaptação do conceito de trusted process proposto por Bell/LaPadula [BELL 1976][ LUNT 1998] e permitem que os elementos voláteis do sistema possam ser validados, neste caso duplamente. Embora estas chaves específicas tenham um ciclo de vida curto e estejam embutidos nos respectivos executáveis, ainda representam uma fragilidade. Estas são as únicas chaves potencialmente acessíveis a partir de nós remotos que poderiam ser obtidas via engenharia reversa dos executáveis ou varredura de memória em dispositivos comprometidos. Entretanto, técnicas como a apresentada em [BOESGAARD 2007] podem ser utilizadas para tornar muito mais improvável que ataques deste tipo sejam bem sucedidos. Além destes mecanismos, nos fluxos (4) e (5) são aplicados o tratamento de falhas bizantinas [LIMA 2009] e técnicas de controle de sabotagem [SARMENTA 2001] encapsuladas em controles semânticos fim-a-fim. Usando controles deste tipo, o Backend pode enviar tarefas especiais e conferir os resultados recebidos para validar cada PNA ou criar certa quantidade r de réplicas das tarefas e enviar para serem processadas por mais de um PNA. Somente quando um número r-n de resultados convergirem, a tarefa é considerada completa. Os valores de r e n podem ser manipulados para se adaptarem a contextos com maior ou menor grau de suscetibilidade a ataques de adversários. E o PNA que devolver algum resultado espúrio será descartado. A estratégia de controle fim-a-fim adotada, independentemente da sua forma de implementação, deverá ficar localizada na distribuição de tarefas e recolhimento de resultados pelo Backend específico de cada aplicação cliente através do uso das primitivas Challenge e Validate Proteções Complementares Além das proteções já implementadas nativamente pelo dispositivo hospedeiro (ex. middleware de um receptor de TV digital), mecanismos de isolamento da execução tanto do PNA quanto da aplicação cliente são implementados usando o conceito de Dynamic

84 IX Workshop em Clouds, Grids e Aplicações 69 Virtual Environments (DVE) [KEAHEY 2004]. Estes ambientes disponibilizam uma quantidade controlada de recursos para a aplicação em execução, garantindo dessa forma, a manutenção dos principais serviços dos dispositivos hospedeiros e preservando a plataforma de possíveis ataques de alocação de recursos. As ameaças de Denial of Service (DoS) [CHAMPAGNE 2006] podem estar presentes em sistemas OddCI através de ataques externos disparados contra o Controller e o Backend. Isso pode ser minimizado pela divulgação de endereços IP apenas através das mensagens de controle. Esta é uma prerrogativa que os sistemas OddCI possuem ao possibilitar a montagem sob demanda e de caráter volátil de infraestruturas computacionais de grande porte. 5. Estudo de Caso: Um sistema OddCI sobre uma rede de TV Digital Para instanciar a arquitetura OddCI sobre uma rede de televisão digital, OddCI-DTV, é necessário implementar os quatro componentes de software discutidos, isto é: o Provider, o Controller, o Backend e o PNA. O papel do provedor pode ser exercido pela emissora de TV digital que detém a concessão do canal de TV ou um parceiro. O papel do controlador deve ser exercido pela emissora de TV digital que detém a concessão do canal de TV, uma vez que ela deve enviar as aplicações (imagens dos cientes) para os receptores através de um fluxo elementar junto com sua programação. A retaguarda pode ser montada como um conjunto de computadores distribuídos sob controle do cliente ou de um terceiro. Os agentes processadores são os receptores de TV digital, cujos canais de retorno usados para interatividade possibilitam o envio e recebimento de dados com o Backend e o Controller. Na Fig. 4, são identificadas as tecnologias atualmente disponíveis para o segmento de TV Digital que podem ser usadas e como elas estão associadas com os elementos da arquitetura OddCI genérica. O processo de distribuição de execução de aplicações interativas, descritos no padrão Brasileiro de TV Digital, ocorre da seguinte forma: inicialmente o conteúdo da aplicação é serializado na forma de um carrossel de objetos no padrão DSM-CC (Digital Storage Media Command and Control) [ISO 1995], onde os arquivos e pastas da aplicação são codificados em sessões e encapsulados em um fluxo (stream) MPEG2-TS [ITU 2000]. Após a codificação dos dados, propriedades da aplicação como nome, tipo, classe principal e outras características são definidas e estruturadas na forma da tabela AIT (Application Information Table) e encapsulados em pacotes TS. Terminada a preparação dos dados, ocorre a configuração da tabela PMT (Program Map Table) com o PID utilizado pelo TS de dados (Object Carousel) e o PID da AIT, além da adição dos descritores necessários para identificar a existência de um fluxo de dados para um determinado programa ou serviço. Por fim, o stream é multiplexado com outros fluxos de áudio, vídeo e dados para então ser transmitido em broadcast pela emissora de TV. DTV Receiver PNA Communication Application Xlet PNA Xlet Middleware Processing Nodes Interaction Channel Backend DTV Return path Internet DTV Broadcast Transmission DSM-CC Broadcast Channel Controller Provider ControllerIntegration Gateway MPEG-2 Transport Stream Carousel Generator Figura 4. Tecnologias atuais de TV Digital para suporte a sistemas OddCI-DTV

85 70 Anais Ao sintonizar a frequência da emissora, o receptor de TV verifica a existência do stream de dados, e executa uma rotina de processamento desses dados, que é responsável por verificar a integridade do conteúdo recebido através do CRC de cada informação. Os dados são gravados obedecendo à estrutura de pastas e arquivos configurados na AIT. Ao término do processamento, o middleware é notificado da existência de uma nova aplicação passando informações sobre o nome, o tipo e o modo de execução da aplicação para o gerenciador de aplicações que seleciona o módulo de apresentação (engine) adequado ao tipo de aplicação: NCL/Lua [ABNT 2009-A] ou Java DTV [ABNT 2009-B]. O esforço em identificar e decompor as vulnerabilidades presentes e mapeá-las em primitivas básicas permite aplicar as mesmas técnicas já validadas em outros contextos. Com tal estratégia, foi possível relacionar as primitivas necessárias com as primitivas esperadas para os sistemas de TV Digital que atendam as normas estabelecidas. Desta forma, foi possível constatar que as primitivas necessárias para o funcionamento seguro de um sistema OddCI podem ser implementadas em um sistema de TV Digital, ou porque já fazem parte das bibliotecas padrão ou porque podem ser construídas sobre estas. A validação foi baseada no middleware Ginga [ABNT 2009-C], que define as linguagens que podem ser utilizadas para codificação das aplicações e as interfaces de programação (APIs Application Program Interfaces) disponíveis. Parte das primitivas de segurança descritas no modelo de segurança aqui definidos foram implementadas nas linguagens NCL/Lua [ABNT 2009-A] e Java DTV [ABNT 2009-B] ou mapeadas para recursos nativos destes ambientes. Tomando por exemplo uma aplicação Java DTV, uma API de segurança complementar é especificada no pacote com.sun.dtv.security que estende a API java.security. De forma similar, as aplicações implementadas em NCL/Lua, é possível fazer uso da biblioteca aberta Lua MD5 [KEPLER 2010], que já contempla uma implementação dos algoritmos MD5 e des56. Conforme a norma, o middleware que está instalado nos receptores também fará automaticamente a validação da cada aplicação recebida usando a chave pública da emissora que está assinada por uma autoridade certificadora bem conhecida. Além disso, os recursos nativos que estão previstos para proteger os recursos e o funcionamento do middleware de aplicações de comportamento indevido, intencional ou não, foram mapeados para obter o mecanismo de DVE previsto. Também foram implementadas algumas das primitivas para uso em aplicações instaladas diretamente nos receptores, denominadas aplicações residentes. Neste caso, foram usadas rotinas de segurança disponibilizadas pelo sistema operacional do próprio receptor de TV e também pelas funcionalidades acessíveis através do middleware. No nosso estudo de caso, utilizamos uma versão de kernel Linux desenvolvido para processadores MIPS + busybox. Na Tabela 3, é ilustrado como algumas das primitivas de segurança foram mapeadas para uso em aplicações Java, NCL/Lua e Residente. Tabela 3. Exemplo de primitivas básicas em Java, Lua e Aplicações Residentes Primitiva Java NCL/Lua Residente (C++) Hash(msg) public byte[] gethash( byte[] m); Crypt(m, k) public byte[] crypt(byte[] m, String k); DeCrypt(m,k) public byte[] decrypt(byte[] m, String k); Sign(msg,id) public byte[] sign(byte[] m, int id); GenKey(id 1 id 2) public String getkey(int id1, int id2); security:gethash(m: string) hash: string security:crypt(m:string) m_crypt: string security:decrypt(m:string) m_decrypt: string security:sign(m:string) m_sign: string Security:getKey(id1,id2: number) key: string char * gethash(char * m); char * crypt(char * m, char * key); char * decrypt(char * m, char * key); char * sign(char * m, int id); char * getkey(int id1, int id2);

86 IX Workshop em Clouds, Grids e Aplicações Conclusão O presente trabalho propõe um modelo de segurança para que sistemas OddCI, em geral, e sistemas OddCI-DTV, em particular, possam ser usadas de forma segura para processar aplicações MTC. Os diversos desafios envolvidos na operação de tais sistemas baseados em recursos públicos e não dedicados foram discutidos. Foi definido um mecanismo de comunicação seguro para a oferta de serviços de computação sobre uma infraestrutura distribuída volátil e demonstrada a viabilidade de sua implementação em uma rede de receptores de TV Digital. Os próximos passos da pesquisa incluem uma generalização da proposta com objetivo de tornar possível o uso de diferentes tipos de dispositivos para montagem de um Sistema OddCI (e.g. dispositivos móveis), a realização de simulações das operações dos fluxos de comunicação juntamente com a condução de experimentos reais para avaliar o desempenho do protocolo proposto e das primitivas usadas, bem como o esforço de coordenação necessário para controlar e usar potencialmente milhões de dispositivos simultaneamente. Uma análise mais sólida dos aspectos de segurança aqui introduzidos também está prevista, com a definição dos modelos de atacantes aos quais o sistema está exposto e a aferição da eficiência das contramedidas previstas. O uso dos recursos de processamento do receptor de TV para executar as tarefas dos clientes pode ser negociado nos contratos de leasing em sistemas de TV por assinatura. No caso de sistemas de TV abertos entende-se que ao sintonizar um canal, o proprietário do receptor cede o uso de seus recursos processador, memória, display etc. ao emissor de TV que, em troca, permite o acesso gratuito ao conteúdo por ele produzido ou adquirido. Uma discussão detalhada sobre possíveis modelos de negócio e modelos de incentivo que estimulem a participação de usuários e emissoras em sistemas OddCI também será tema de trabalho futuro. 7. Referências ABNT (2009-A) NBR Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital Parte 2. ABNT (2009-B) NBR Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital Parte 4. ABNT (2009-C) NBR Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital Parte 1. Amazon (2010) Amazon Elastic Compute Cloud - Amazon EC2. Disponível em Anderson, D. P. (2004) BOINC: A System for Public-Resource Computing and Storage. Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (GRID'04), pp Anderson, D. P. et al. (2002) An Experiment in Public-Resource Computing. Communications of the ACM Archive, vol. 45(11), pp Andrade, N., Brasileiro, F., Cirne, W. and Mowbray, M. (2007) Automatic grid assembly by promoting collaboration in peer-to-peer grids. In Journal of Parallel and Distributed Computing. vol. 67(8). Bell, D. E. and LaPadula, L. J. (1976) Secure Computer Sytems: Unified Exposition and Multics Interpretation. Technical Report ESD TR , MITRE Co. Hanscom, MA. Boesgaard, M. and Zenner, E. (2007) Protecting Online Transactions with Unique Embedded Key Generators. In Second International Conference on Availability, Reliability and Security (ARES'07).

87 72 Anais Canetti, R., Garay, J., Itkis, G., Micciancio, D., Naor, M. and Pinkas, B. (1999) Multicast Security: A Taxonomy and Some Efficient Constructions In Infocom 99. Champagne, D. and Lee, R. B. (2006) Scope of DDoS Countermeasures: Taxonomy of Proposed Solutions and Design Goals for Real-World Deployment. In 8th ISSIS (SSI'2006). Cirne, W., Paranhos, D., Costa, L. et al (2003) Running Bag-of-Tasks Applications on Computational Grids: The MyGrid Approach. In Proceedings of the ICCP' International Conference on Parallel Processing. Cirne, W., Brasileiro, F., Andrade, N., Costa, L., Andrade, A., Novaes, R. and Mowbray, M. (2006) Labs of the world, unite!!!. Journal of Grid Computing. vol. 4(3) ), pp Costa, R., Brasileiro, F., Filho, G. L., and Sousa, D. M. (2009) OddCI: on-demand distributed computing infrastructure. In Proceedings of the 2nd Workshop on Many-Task Computing on Grids and Supercomputers (Portland, Oregon). MTAGS '09. ACM. D Anna, L., Matt, B., Reisse, A., Van Vleck, T., Schwab, S. and LeBlanc, P. (2003) Selfprotecting mobile agents obfuscation report. Technical Report #03-015, Network Associates Labs, June ISO/IEC (, 1995) : Digital Storage Media Command and Control. ITU-T (2000) Recommendation H.222. Information Technology. Generic coding of moving pictures and associated audio information: Systems. Keahey, K., Doering, K. and Foster, I. (2004) From Sandbox to Playground: Dynamic Virtual Environments in the Grid. In 5th International Workshop in Grid Computing. Kepler Project (2006) MD5 Cryptographic Library for Lua. Disponível em Lima, M. S. and Greve, F. G. P. (2009) Detectando Falhas Bizantinas em Sistemas Distribuídos Dinâmicos. Litzkow, M. Livny, M. and Mutka, M. (1988) Condor - a hunter of idle workstations. Proc. 8th Int'l Conf. Dist. Computing Systems. Lunt, T. F., Neumann, P. G., Denning, D. et al. (1998) Secure distributed data views vol.1: Security policy and policy interpretation for a class A1 multilevel secure. Technical Report SRI-CSL-88-8, SRI International, Menlo Park, CA. Morris, S. and Smith-Chaigneau, A. (2005) Interactive TV Standards A Guide to MHP, OCAP and JavaTV. ISBN Focal Press, Elsevier. Oliveira, L., Lopes, L., and Silva, F. (2002) P3 (Parallel Peer to Peer): An Internet Parallel Programming Environment. Web Engineering and Peer-to-Peer Computing Workshop. Lecture Notes in Computer Science. vol. 2790, pp Pisa, Italy, Springer. Raicu, I. and Foster, I. (2008) Many-Task Computing for Grids and Supercomputers. IEEE Workshop on Many-Task Computing on Grids and Supercomputers (MTAGS08). Santin, A., Fraga, J. et al (2002) Modelo de Autorização e Autenticação Baseado em Redes de Confiança para Sistemas Distribuídos de Larga Escala. In SSI 02. S. J. Campos - SP. Sarmenta, L. (2001) Sabotage-Tolerance Mechanisms For Volunteer Computing Systems. In Cluster Computing And Grid. Brisbane, Australia, 2001 Schellhorn, G., Reif, W., Schairer, A., Karger, P. et al. (2000) Verification of a Formal Security Model for Multiapplicative Smart Cards. Computer Security - ESORICS. Pg Thain, D., Tannenbaum, T. and Livny, M. (2006) How to Measure a Large Open Source Distributed System, Concurrency and Computation: Practice and Experience. vol. 8(15). Wang, L., Von Laszewski, G., Kunze, M. and Tao, J. (2008) Cloud computing: A Perspective Study. Proceedings of the Grid Computing Environments (GCE) workshop. Austin, Texas.

88 IX Workshop em Clouds, Grids e Aplicações 73 Avaliação do Custo por Usuário de uma Aplicação de Rede Social na Amazon EC2 Matheus Cunha 1,2, Nabor Mendonça 1, Américo Sampaio 1 1 Mestrado em Informática Aplicada (MIA) Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321, Edson Queiroz, CEP Fortaleza, CE 2 Secretaria da Fazenda do Estado do Ceará (SEFAZ) Av. Pessoa Anta, 274, Centro, CEP Fortaleza, CE Resumo. Um dos principais desafios enfrentados pelos atuais clientes de nuvem que oferecem infraestrutura como serviço (IaaS) são as dificuldades para dimensionar os recursos da nuvem (tais como computação, armazenamento e rede) necessários para suas aplicações. Ainda é comum que clientes de nuvens provisionem os recursos da aplicação para mais (overprovisioning) ou para menos (underprovisioning), resultando, em ambos os casos, em prejuízos financeiros. Apesar do fato das plataformas de nuvem serem elásticas e proverem formas rápidas de adquirir ou liberar recursos, é importante entender a melhor maneira de fazer isto considerando a existência de vários provedores de nuvem oferecendo muitos serviços com preços diferentes. Este trabalho mostra alguns resultados bem interessantes de experimentos conduzidos em um benchmark popular de nuvem baseado em uma aplicação de rede social que executa na Amazon EC2. Nossos experimentos visam encontrar formas econômicas de escolher diferentes instâncias da EC2 baseado na demanda imposta na aplicação (medida pela quantidade de usuários concorrentes) e como escolher a instância que dá o melhor retorno em termos do seu custo por usuário. Abstract. One of the main challenges faced by current users of infrastructureas-a-service (IaaS) clouds are the difficulties to estimate cloud resources (such as computation, storage, and networking) according to their application needs. It is common that cloud users still overprovision or undeprovision (i.e. get more or less resources than needed, respectively), resulting, in both cases, in financial loss. Even though cloud platforms are elastic and provide fast ways to acquire or release resources it is important to understand the best ways to do that considering a vast amount of providers with many different service prices. This work shows some very interesting results from experiments conducted on a popular cloud benchmark based on a social network application running on top of the Amazon EC2 cloud. Ours experiments aim at finding cost-effective ways to select the different EC2 instance types based on the demand imposed to the application (measured in number of simultaneous users) and the instance that gives the best return in terms of its cost per user.

89 74 Anais 1. Introdução A computação em nuvem vem crescendo em popularidade nos últimos anos por fornecer um novo e atrativo modelo de negócios que se baseia em oferecer recursos computacionais (ex.: computação, armazenamento, aplicações, plataformas) como serviços que são pagos conforme sua utilização [Armbrust et al. 2009, Foster et al. 2009]. Diversas soluções para oferecer serviços de nuvem já existem, variando desde softwares open source que permitem configurar e gerenciar uma nuvem privada dentro de uma organização [Eucalyptus 2009, OpenNebula 2010] até os populares provedores comerciais de serviços de nuvem [Azure 2010, EC2 2010, Force 2010, AppEngine 2010, Rackspace 2009]. Alguns destes provedores, também conhecidos como nuvens de infra-estrutura (IaaS clouds) [EC2 2010, Rackspace 2009], oferecem recursos computacionais como servidores virtuais (máquinas virtuais contendo uma certa capacidade de CPU, memória e disco) e espaço de armazenamento na forma de serviços acessíveis via interfaces de programação (APIs). O principal objetivo é facilitar a aquisição de infraestrutura computacional para o cliente da nuvem (aquele que disponibiliza sua aplicação na nuvem) de modo que ele tenha que se preocupar cada vez menos com detalhes de gerenciamento de infraestrutura para se focar no seu negócio e no desenvolvimento da sua aplicação. No entanto, para a maioria dos clientes, a grande oferta de provedores de nuvem traz um novo desafio que é o de escolher aquele que é o mais vantajoso considerando as características da sua aplicação. Por exemplo, caso a Amazon EC2 seja a nuvem escolhida, o usuário terá um conjunto de mais de 10 tipos de instância (máquina virtual) para hospedar a sua aplicação com preços bastante variados. Cada instância possui sua própria configuração de em termos de memória (podendo variar, por exemplo, de 613 MB a 68,4 GB de RAM), processamento, armazenamento e performance de entrada e saída. Essas configurações muito distintas podem ser utilizadas para atender variados perfis de aplicação. Assim, para conseguir escolher a melhor configuração para uma determinada aplicação é importante que se conheça bem as características de cada tipo de instância oferecido pela plataforma de nuvem, bem como as necessidades específicas da aplicação, como, por exemplo, a potencial demanda (carga) imposta pelos usuários. Dependendo do tipo da aplicação, a demanda pode ser bastante variável. Por exemplo, uma aplicação de comércio eletrônico pode ter vários picos de uso, como em momentos de períodos festivos (ex.: natal, dia das mães), e também oscilar ao longo do dia. Apesar das plataformas de nuvem serem elásticas e seus clientes poderem ajustar mais facilmente os recursos necessários para atender a demanda da aplicação, a tarefa de dimensionar corretamente as instâncias ainda é complicada. Por isso, o risco de implantar aplicações com recursos além do necessário (overprovisioning) ou recursos aquém do necessário (underprovisioning) é muito alto. Ambos os casos implicam em perdas financeiras, só que por motivos distintos. No primeiro, o usuário pagará por recursos que não está utilizando; já no segundo, o usuário terá menos recursos do que necessita, o que poderá aumentar o tempo de resposta da sua aplicação e consequentemente a insatisfação de seus usuários. Os problemas de overprovisioning ou underprovisioning não estão restritos ao momento de implantação da aplicação, e também podem ocorrer durante a sua operação no ambiente de nuvem. Portanto, é importante ter mecanismos que permitam entender a melhor maneira de ajustar os recursos da nuvem elasticamente para atender a possíveis flutuações na demanda da aplicação. Algumas questões que merecem ser investigadas neste sentido são:

90 IX Workshop em Clouds, Grids e Aplicações 75 Qual o melhor tipo de instância (do ponto de vista de custo) que atende a uma demanda específica (por exemplo, até X usuários concorrentes)? Caso ocorra uma situação de baixíssima demanda, qual a melhor opção de instância? Qual a melhor estratégia: concentrar a carga em uma única instância de tamanho grande, ou distribuí-la em várias instâncias de tamanho menor? Este trabalho procura descobrir respostas para questões como essas, que são bastante comuns no dia-a-dia dos clientes de nuvens na atualidade. Para isto, um benchmark de nuvem proposto recentemente [Sobel et al. 2008] foi utilizado para investigar a relação entre a demanda imposta a uma aplicação de rede social (tipo de aplicação bastante comum em nuvens) no ambiente de nuvem Amazon EC2 (escolhido devido a sua alta popularidade). A avaliação demonstra como o custo por usuário varia de acordo com a demanda da aplicação e como a escolha correta do tipo de instância reflete diretamente no custo pago pelo uso da nuvem. Este estudo inicial conseguiu apontar resultados bastante interessantes e encorajadores no sentido de entender a melhor configuração possível para uma determinada demanda (baseada no número de usuários simultâneos da aplicação). Por exemplo, foi possível perceber que quando se tem uma demanda muito baixa (menor que 50 usuários simultâneos), a instância mais barata da EC2 pode ser suficiente, a um custo baixíssimo de 0,02 dólares por hora. Além disso, caso o usuário opte por utilizar 3 instâncias de tamanho médio ele consegue atender satisfatoriamente até 600 usuários simultâneos, economizando 25% em relação ao custo de 1 instância de tamanho extra grande. O restante do artigo é organizado da seguinte forma. A seção 2 descreve outros benchmarks para ambientes de nuvem e suas limitações. Já a seção 3 apresenta as ferramentas utilizadas para a execução do benchmark e da aplicação de rede social utilizados neste trabalho. A seção 4 apresenta os experimentos que foram realizados e a seção 5 discute os resultados que foram observados. Finalmente, a seção 6 conclui o artigo e sugere trabalhos futuros. 2. Trabalhos Relacionados Para realizar os experimentos deste trabalho foram estudadas diversas opções de benchmark de sistemas distribuídos disponíveis. Uma característica relevante é o fato da ferramenta de benchmark ser preparada para simular variações de carga (demanda) dado que os ambientes de computação em nuvem são baseados no modelo de pagar pelo uso. Além disso, é importante que o benchmark se baseie em aplicações comumente implantadas na nuvem para que as descobertas encontradas estejam próximas do perfil de aplicações reais. Existem diversas ferramentas populares para avaliação de performance de sistemas distribuídos, como o SPECvirt [SPECvirt 2010]. O SPECvirt avalia a performance do hardware, da plataforma de virtualização, do sistema operacional convidado e de aplicações hospedadas (web, JEE e ) nesses sistemas operacionais convidados. Porém, a ferramenta fixa um conjunto específico de serviços virtualizados e a carga, quando variada, é aplicada em todos os componentes de software. Portanto, não é possível escalar apenas um determinado tipo de serviço ou desabilitar algum componente. Esta falta de flexibilidade na configuração do SPECvirt inviabilizou a escolha desta ferramenta para nossos experimentos.

91 76 Anais Existem também algumas iniciativas de benchmarks específicos para computação em nuvem. Uma delas é a ferramenta implementado pela CloudSleuth [CloudSleuth 2011], que monitora diversos serviços disponibilizados em nuvens de infraestrutra, por exemplo, serviços de pagamento, mapas, propagandas e estatísticas de acesso. Sua metodologia consiste em disponibilizar uma aplicação simples de referência hospedada na Amazon EC2 que testa as funcionalidades de mapas, pagamento e outras descritas acima. A ferramenta permite a execução de testes de acesso que são disparados de mais de 168 países para analisar e comparar as variações de tempo de resposta. Embora interessante, essa ferramenta não permite variação na arquitetura da aplicação, o que é importante para nossos testes. Outro projeto voltado para realizar benchmarks em serviços hospedados na nuvem é o bitcurrent 1, que apenas disponibiliza um relatório com o resultado de diversos testes que executou em provedores de nuvem. De forma similar, o CloudHarmony [CloudHarmony 2009], cujo objetivo é tornar-se a principal fonte independente, imparcial e útil de métricas de desempenho dos provedores de nuvem, agrega dados de testes de performance realizados desde 2009 em mais de 60 provedores de nuvem. O projeto também oferece uma ferramenta para iniciar testes de performance a qualquer momento, denominada Cloud Speed Test. O projeto CloudCmp [Li et al. 2010] visa realizar uma comparação da performance e do custo de diversos provedores de nuvem públicas, analisando a elasticidade, os mecanismos de persistência de dados e os serviços de rede oferecidos pelos provedores de nuvem. Para isso, desenvolveram uma ferramenta, a CloudCmp, e realizaram testes específicos para cada uma das três funcionalidades citadas anteriormente. O trabalho aponta que não há nenhum provedor que se destaque com relação aos demais e que os resultados obtidos apenas refletem o momento em que foram testados, uma vez que a estrutura utilizada para hospedar os serviços sofre modificações e a demanda nos recursos computacionais é bastante variável. Esta abordagem poderia ser adequada para realizar os experimentos deste trabalho, mas, como não está publicamente disponível, optamos por escolher o benchmark descrito na seção seguinte. 3. Cloudstone O projeto Cloudstone [Sobel et al. 2008] disponibiliza um conjunto de ferramentas que permitem a execução de testes de performance com diferentes pilhas de software. Estas ferramentas incluem a aplicação Web 2.0, Olio, que implementa uma rede social, e a ferramenta responsável pela geração de carga e medição de performance da aplicação, Faban. Como a arquitetura da aplicação é facilmente configurável (ex.: pode-se variar facilmente o número de servidores de aplicação), já tendo sido testada com sucesso em nuvens como a EC2, optamos por utilizá-la para nossos experimentos Aplicação Olio A aplicação Olio 2 é um projeto de código aberto que implementa uma rede social de calendário de eventos. Alguns exemplos de funcionalidade da aplicação são: 1 2

92 IX Workshop em Clouds, Grids e Aplicações 77 Cadastro de usuários. Os usuários realizam seu cadastro para poder cadastrar eventos. Cadastro de eventos. Usuários registrados podem cadastrar eventos fornecendo informações como endereço e fotos sobre o local do evento. Os usuários também podem postar comentários acerca de um evento. Quanto as tecnologias utilizadas, a ferramenta está disponível nas plataformas Ruby on Rails e PHP. A camada de apresentação utiliza AJAX e a a camada de dados pode ser configurada com os banco de dados MySQL ou PostgreSQL. A figura 1 mostra a arquitetura da aplicação Olio organizada em três camadas: servidor web, servidor de aplicação e banco de dados. O conteúdo estático pode ficar hospedado em um servidor Apache ou Nginx 3 e esses dois ficam como proxy reverso e balanceador de carga para as intâncias do PHP ou Thin 4 para a versão Ruby on Rails. O uso dessa arquitetura torna possível a separação das camadas em diferentes máquinas virtuais, o que possibilita a investigação de diversos cenários e configurações, além de permitir um alto grau de elasticidade para atender às variações de demanda. Figura 1. Arquitetura do Olio 3.2. Gerador de Carga Faban Para realizar os testes de carga, o Cloudstone faz uso do Faban 5, que tem código aberto e é dividido em duas partes: Faban Driver Framework é responsável pelo controle do ciclo de vida do benchmark e possui componentes para executar testes de aplicações implantadas em diversos servidores como Apache, Nginx, Thin, memcached, mysql e outros. Utiliza um modelo estocástico para simular a ação dos usuários. Faban Harness é a ferramenta que automatiza a execução dos benchmarks. Cada benchmark implantado nessa ferramenta tem a sua execução acompanhada e configurada através de uma interface web que também disponibiliza os resultados das execuções Disponível no endereço o Thin é um servidor web para aplicações Ruby 5

93 78 Anais Através da utilização do Faban é possível definir fluxos de trabalho completos, como cadastrar usuário ou cadastrar evento, que podem ser compostos por diversas requisições HTTP que configuram uma tarefa no sistema. Buscando se aproximar mais do comportamento de um usuário, a sequência de execução desses fluxos de trabalho é estocástica. Outra possibilidade que o Faban oferece é a dos testes partirem de diferentes máquinas, todas coordenadas por um mesmo agente, permitindo uma grande quantidade de execuções em paralelo. Também a quantidade de usuários em cada execução é parametrizável e realizada através da interface web do Faban Harness. Durante uma execução, o Faban grava os tempos de resposta de cada requisição realizada pelo gerador de carga, do momento em que foi disparado até a hora da chegada do último byte da resposta. De posse dessas métricas, o Faban considera um teste bem sucedido aquele em que no mínimo noventa porcento das respostas tenham chegado dentro do tempo de resposta préestabelecido. Essa informação é bastante relevante pois a utilizamos como base do critério de sucesso para nossos experimentos. 4. Experimentos Uma vez definida a aplicação alvo dos experimentos e o gerador de cargas para submetêla a diferentes níveis de demanda, é preciso escolher a plataforma de nuvem onde os testes serão realizados. Para os nossos experimentos foi escolhida a Amazon EC2, região East, localizada no estado americano da Virgínia. Essa escolha se deu pela Amazon EC2 ser uma referência no modelo de infraestrutura como serviço, e pelo fato dos preços dos recursos oferecidos nessa região serem os mais baixos cobrados pela Amazon. Porém, a Amazon EC2 oferece diversos tipos de instância, com variações no custo, na quantidade de memória, no número de processadores, dentre outros recursos. Além disso, a opção por um determinado tipo de instância depende também da demanda esperada para a aplicação, que para uma aplicação nova é difícil de determinar. Portanto, os nossos experimentos tiveram como objetivo facilitar o entendimento de como esses diferentes tipos de instância se comportariam sendo expostos a variações na demanda pela aplicação. Dessa forma, seria possível identificar o tipo de instância mais adequado para hospedar a aplicação levando-se em consideração diferentes níveis de demanda. Para os experimentos foram definidos duas faixas de demanda: demanda baixa (com o número de usuários concorrentes variando entre 25 e 150) e demanda moderada (com o número de usuários concorrentes variando entre 200 e 700). Sendo assim, a aplicação Olio foi hospedada em cada um dos diferentes tipos de instância da Amazon EC2 avaliados, a qual foi então submetida aos diferentes níveis de demanda descritos acima. A mesma quantidade de usuários era executada três vezes durante os experimentos. Cada execução durava cerca de 800 segundos e era considerada realizada com sucesso quando noventa porcento dos tempos de resposta medidos estivessem dentro do tempo de resposta esperado. É importante deixar claro que os valores que serão reportados nas subseções seguintes apenas refletem o momento em que foram gerados, uma vez que o desempenho de uma instância da nuvem pode sofrer influência de outras instâncias hospedada no mesmo servidor físico.

94 IX Workshop em Clouds, Grids e Aplicações 79 Tipo de Preço Diferença p/ Diferença p/ instância (US$ p/hora) anterior (%) menor (%) t1.micro 0,02 m1.small 0, c1.medium 0, m1.large 0, m2.xlarge 0, c1.xlarge 0, m1.xlarge 0, m2.4xlarge 2, Tabela 1. Preço absoluto (em dolar por hora de uso) e relativo (em percentual) dos diferentes tipos de instância oferecidos pela Amazon EC2 East. Representação Significado # execuções com sucesso l Não atendeu à demanda 0 d Atendeu à demanda esporadicamente 1 e Atendeu à demanda parcialmente 2 Atendeu à demanda plenamente 3 Tabela 2. Representação utilizada na análise do desempenho da aplicação Experimento 1: configuração com um único servidor de aplicação Neste experimento foram utilizadas três instâncias. Na primeira era executado o gerador de carga (Faban), na segunda o banco de dados MySQL e na terceira o servidor de aplicação THIN e o balanceador de carga NGINX, necessários para a execução da aplicação Olio. Como o objetivo era conhecer como as instâncias se comportam sendo expostas a variações na demanda e qual o impacto de uma má escolha no custo da solução, foram fixadas as máquinas virtuais, do gerador de carga e do banco de dados, em instâncias do tipo c1.xlarge. Essa escolha foi baseada nos informações disponibilizadas pelo projeto Cloudstone. Já a aplicação Olio foi hospedada nos diversos tipos de instância oferecidos pela Amazon EC2 (ver tabela 1), e submetida aos dois níveis de demanda descritos anteriormente. Para facilitar o entendimento dos resultados, as tabelas subsequentes ilustram o desempenho da aplicação observado para cada instância e nível de demanda avaliados seguindo a representação visual descrita na tabela 2. A tabela 3 mostra o desempenho da aplicação Olio, configurada com uma única instância hospedando o servidor de aplicação THIN, para a primeira faixa de demanda. Observando essa tabela é possível constatar que para o nível mais baixo de demanda, com até 25 usuários simultâneos, a aplicação Olio poderia ficar hospedada na menor instância disponibilizada pela Amazon EC2, do tipo t1.micro, ao custo de módico de US$ 0,02 por hora de uso. Porém, nesse tipo de instância, a aplicação só atendeu à demanda uma única vez, o que demonstra a instabilidade dos serviços da Amazon para instâncias com poucos recursos. Nesse sentido, a instância do tipo m1.small dá uma maior segurança, a um custo ligeiramente maior. Seguindo para 50 usuários e indo até 150, todos os tipos

95 80 Anais Tipo de Demanda (# usuários) instância t1.micro d l l l l l m1.small l l l l l c1.medium m1.large d m2.xlarge c1.xlarge m1.xlarge m2.4xlarge Tabela 3. Desempenho da aplicação na nuvem sob demanda baixa (configuração com um único servidor de aplicação). Tipo de Demanda (# usuários) instância c1.medium l l l l l l m1.large l l l l l l m2.xlarge e l l l l l c1.xlarge e l l l m1.xlarge l l l l l m2.4xlarge d l l l Tabela 4. Desempenho da aplicação na nuvem sob demanda moderada (configuração com um único servidor de aplicação). de instância avaliados satisfizeram o nível de serviço esperado, com exceção da instância m1.large, que não logrou êxito em todas as execuções com 150 usuários. Em vista da grande diferença de preço entre as instâncias, fica claro que uma escolha inadequada nessa faixa de demanda pode implicar em um custo até 1000% maior que o necessário. A instância que se destaca com o melhor custo/benefício é a c1.medium, que dentro dessa faixa de usuários passou em todos os testes. A tabela 4 mostra os resultados do experimento para a faixa de demanda moderada. Nessa faixa, o custo inicial para hospedar a aplicação Olio sobe para US$ 0,5 por hora, com uma instância do tipo m2.xlarge. Porém, esse tipo de instância apresentou falha em um dos testes. Portanto, para maior estabilidade, as instâncias do tipo c1.xlarge são recomendadas. É possível notar que instâncias de tipos diferentes e com o mesmo preço, como é o caso das instâncias c1.xlarge e m1.xlarge, apresentam desempenhos bem diferentes. A razão é que esses tipos de instâncias são específicas para um determinado perfil de aplicação (por exemplo, com maior necessidade de memória ou processamento). Assim, pelos resultados obtidos, vê-se que a aplicação Olio apresenta um perfil que se beneficia de instâncias com maior poder de processamento. Também fica claro que pagar mais por uma instância com maior capacidade não implica necessariamente em um melhor serviço. Isso pode ser visto com as instâncias do tipo m2.4xlarge, que custam US$ 2,0 por hora de uso (a mais cara entre as instâncias avaliadas) e têm desempenho inferior às do tipo c1.xlarge, que custam quase três vezes menos.

96 IX Workshop em Clouds, Grids e Aplicações 81 Figura 2. Custo por usuário da aplicação na nuvem sob demanda baixa (configuração com um único servidor de aplicação). Uma vez conhecida a relação entre os tipos de instância e os níveis de demanda que eles conseguem suportar, é possível realizar uma análise da utilização desses recursos do ponto de vista econômico. Dessa forma, fica mais fácil entender o impacto da escolha de uma determinada instância no custo de operação da aplicação. Para isso, foi calculado o custo por usuário da aplicação, que é a relação entre o preço por hora de uso do tipo de instância escolhido e a quantidade de usuários atendidos por esse tipo. Para entender melhor o cálculo desse custo, considere o custo por usuário da aplicação Olio para instâncias do tipo m1.small. Como nos testes essa instância executou com sucesso apenas para demandas de até 25 usuários, o valor do custo por usuário para esse tipo é calculado dividindo-se US$ 0,085 por 25, o que dá um custo de US$ 0,0034 por usuário. O gráfico da figura 2 mostra os custos por usuário calculados para a aplicação Olio sob a faixa de demanda baixa. Através dele é possível observar que para 25 usuários, que simboliza o nível mais baixo de demanda considerado nos experimentos, a diferença dos preços é bastante expressiva. Variando de US$ 0,0008 (instância do tipo t1.micro) a US$ 0,08 (instância do tipo m2.4xlarge) por usuário, ou seja, a instância mais barata tem o custo 100 vezes menor que a instância mais cara. Essa diferença vai caindo à medida em que o número de usuários cresce. Com 150 usuários a instância mais cara é 11,76 vezes o valor da instância mais barata. Entre 50 e 150 usuários a instância c1.medium é a que oferece o melhor custo por usuário. Já para a faixa de demanda moderada, cujos resultados são exibidos no gráfico da figura 3, fica claro o destaque das instâncias c1.xlarge, que oferecem uma melhor relação de custo quando a demanda passa dos 200 usuários. Com exatos 200 usuários, a instância

97 82 Anais Figura 3. Custo por usuário da aplicação na nuvem sob demanda moderada (configuração com um único servidor de aplicação). mais vantajosa é a m2.xlarge. Observe também que como as instâncias c1.xlarge e a m1.xlarge têm o mesmo preço, os seus custos para 200 usuários são os mesmos. A partir de 300 usuários a m1.xlarge some do gráfico, que é quando essa instância começa a não mais atender à demanda. A instância m2.4xlarge, por sua vez, consegue atender total ou parcialmente até 400 usuários, mas em nenhum momento é a opção mais vantajosa, uma vez que seus valores de custo por usuário são os maiores entre as instâncias avaliadas Experimento 2: configuração com múltiplos servidores de aplicação Sendo conhecidos os limites de cada uma das instâncias, era preciso saber se mais de uma máquina virtual hospedando a aplicação Olio poderia resultar em uma melhor relação custo por usuário, particularmente sob níveis de demanda mais elevados. Portanto, mais uma vez foram fixadas as instâncias das máquinas virtuais do gerador de carga e do banco de dados nas instâncias do tipo c1.xlarge. E foram submetidos testes de desempenho variando-se o número de instâncias do servidor de aplicação. Os testes foram feitos com o servidor de aplicação THIN organizado em grupos de duas e três instâncias do tipo c1.medium. A tabela 5 mostra os resultados para esse cenário. Nela pode ser observado que duas instâncias c1.medium, a um custo de US$ 0,34 por hora de uso, suportam o tráfego de até 300 usuários simultâneos. A partir dessa demanda só três c1.medium ou uma c1.xlarge conseguem atender no tempo de resposta acordado. Porém, acontece que a c1.xlarge custa US$ 0,68 por hora de uso e só executa com sucesso até 400 usuários, enquanto que três instâncias c1.medium custam US$ 0,51 por hora e atendem até 600 usuários. O gráfico da figura 4 mostra os valores do custo por usuário para este experimento. Através dele é possível destacar que o paralelismo na camada de aplicação permitiu que

98 IX Workshop em Clouds, Grids e Aplicações 83 Tipo de Demanda (# usuários) instância m2.xlarge e l l l l l c1.xlarge e l l l m1.xlarge l l l l l m2.4xlarge d l l l c1.medium (x2) l l l l c1.medium (x3) l Tabela 5. Desempenho da aplicação na nuvem sob demanda moderada (configuração com múltiplos servidores de aplicação). Figura 4. Custo por usuário da aplicação na nuvem sob demanda moderada (configuração com múltiplos servidores de aplicação). uma demanda maior fosse atendida. Com 200 usuários a melhor instância tinha sido a m2.xlarge, mas com a utilização de duas c1.medium foi possível atender a essa mesma demanda a um menor custo, sendo possível atender até 300 usuários com esse grupo de instâncias. Já a c1.xlarge, que se destacou no experimento anterior, possui valores de custo por usuário superiores aos das outras configurações nos três níveis de demanda aos quais conseguiu atender. A partir de 400 usuários apenas duas instâncias c1.medium não são mais suficientes, e uma nova instância c1.medium se faz necessária. Esta nova configuração consegue atender até 600 usuários, com o custo das três instâncias somadas ainda sendo 25% inferior ao da instância c1.xlarge, a mais barata entre as instâncias com o melhor desempenho individual nessa faixa de demanda.

99 84 Anais 5. Discussão Durante a realização dos experimentos, percebeu-se que o provedor de nuvem utilizado, Amazon EC2, apresentava uma grande flutuação na qualidade dos serviços oferecidos. Daí a necessidade de executar mais de uma vez os testes com a mesma quantidade de usuários. Em alguns casos, os mesmos testes executados com diferença de algumas horas, envolvendo os mesmos tipos de instância, produziam resultados bastantes diferentes. Esse comportamento, que também ocorre com outros provedores de nuvem, já foi documentando em outros trabalhos, como [Wang and Ng 2010] e [Li et al. 2010]. Em todo caso, os experimentos realizados neste trabalho fornecem dados que servem para entender melhor a relação entre a carga de uma aplicação e os tipos de instância que melhor atendem a um determinado nível demanda sob o ponto de vista de custos. Além disso, uma vez que o benchmark escolhido representa um perfil de aplicação que é bastante utilizado atualmente em plataformas de nuvem, esses dados podem auxiliar na implantação de novas aplicações que estão sendo disponibilizadas, ajudando, assim, a evitar o excesso ou mesmo a falta de provisionamento de recursos computacionais. Tanto o excesso quanto a falta de provisionamento implicam em perdas financeiras, sendo que por motivos diferentes. No primeiro caso, provisionamento acima da demanda, uma aplicação pode estar sendo executada a um custo de US$ 5956,8/ano, em uma instância c1.xlarge, quando na verdade sua demanda poderia ser atendida por uma instância muito mais barata, por exemplo, do tipo t1.micro, o que faria o custo despencar para US$ 175,20/ano. Já no segundo caso, o custo com os serviços da nuvem será baixo mas o tempo de resposta da aplicação não atenderá a expectativa do usuário, o que pode fazer com o mesmo passe a não mais utilizar a aplicação e possivelmente fazer propaganda negativa do serviço prestado. Portanto, a escolha correta da instância reflete diretamente em melhores tempos de resposta para os usuários e em uma grande economia nos custos. Um outro exemplo disso pode ser tirado dos experimentos, onde três instâncias do tipo c1.medium puderam atender até 600 usuários, enquanto que uma instância do tipo c1.xlarge conseguiu atender apenas 400 usuário. Acontece que as três instâncias c1.medium, juntas, são 25% mais baratas que uma instância c1.xlarge sozinha. Ou seja, gastando-se 25% menos é possível atender 33% mais usuários. 6. Conclusão Como foi descrito nas seções anteriores, a escolha correta dos recursos computacionais necessários para hospedar uma aplicação na nuvem implica diretamente em menores custos com infraestrutura. Investir em uma instância sem conhecer o seu potencial de desempenho e o das demais pode significar um proviosionamento inadequado de recursos, o que também vai se refletir em perdas financeiras. Portanto, antes de uma aplicação ser implantada na nuvem, é preciso entender qual a configuração que melhor a atende, qual o tipo de instância que se adequa à sua necessidade computacional e como sua configuração pode ser adaptada para conseguir atender flutuações na demanda. Essa definitivamente não é uma tarefa simples para o cliente da nuvem, que muitas vezes precisa escalar rapidamente a sua aplicação. Espera-se que o resultados apresentados neste trabalho possam servir de base para auxiliar o dimensionamento dos recursos computacionais de outras aplicações de perfis si-

100 IX Workshop em Clouds, Grids e Aplicações 85 milares ao da aplicação Olio, que poderão ser implantadas na nuvem da Amazon de forma mais criteriosa, conhecendo um pouco melhor a relação entre os custos das instâncias e seu potencial de desempenho. Nesse sentido, há a necessidade de realização de mais testes com perfis diferentes de aplicação e de utilização de recursos computacionais. Também pretende-se executar mais experimentos envolvendo outros provedores de nuvem, onde vai ser possível verificar se as relações entre o custo e capacidade computacional das instâncias observadas na nuvem da Amazon também ocorrem nessas outras plataformas. Agradecimentos Este trabalho é parcialmente financiado pela Fundação Edson Queiroz, Universidade de Fortaleza, através do Projeto OW2. Referências AppEngine (2010). Google app engine. appengine/. Armbrust, M., Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., et al. (2009). Above the clouds: A berkeley view of cloud computing. EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS Azure (2010). Windows azure platform. windowsazure. CloudHarmony (2009). Cloudharmony. CloudSleuth (2011). Cloudsleuth. https://www.cloudsleuth.net/web/ guest/home/. EC2 (2010). Amazon elastic compute cloud. Eucalyptus (2009). Eucalyptus the open source cloud plataform. eucalyptus.com/. Force, S. (2010). Sales force. Foster, I., Zhao, Y., Raicu, I., and Lu, S. (2009). Cloud computing and grid computing 360-degree compared. In Grid Computing Environments Workshop, GCE 08, pages Ieee. Li, A., Yang, X., Kandula, S., and Zhang, M. (2010). CloudCmp: Comparing Public Cloud Providers. In Internet Measurement Conference. OpenNebula (2010). Open source tookit for cloud computing. opennebula.org. Rackspace (2009). The rackspace cloud. Sobel, W., Subramanyam, S., Sucharitakul, A., Nguyen, J., Wong, H., Patil, S., Fox, A., and Patterson, D. (2008). Cloudstone: Multi-platform, multi-language benchmark and measurement tools for web 2.0. In Proc. of CCA. Citeseer. SPECvirt (2010). Specvirt. Wang, G. and Ng, T. (2010). The impact of virtualization on network performance of amazon ec2 data center. In INFOCOM, 2010 Proceedings IEEE, pages 1 9. IEEE.

101 86 Anais

102 IX Workshop em Clouds, Grids e Aplicações Sessão Técnica 3 Desempenho, Ferramentas e Modelos

103

104 IX Workshop em Clouds, Grids e Aplicações 89 Improving Performance of Information Quality Applications: A Scale-Out Approach Gustavo Frainer 1, Luiz Carlos Ribeiro Junior 1, Mauro Storch 1, Rodrigo F. de Mello 2 1 Acxiom Brasil 2 Departmento de Ciências da Computação Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo Abstract. Throughout the years, information quality has become an essential tool for marketing decisions and to support other business scenarios and operations. That happens due to the fast pace of increase in both the amount of data to be qualified and the complexity of qualification process. This has motivated the adoption of High Performance Computing (HPC) using scale-out environments. In that sense, this paper presents a suite of Information Quality application running over a scale-out environment using GoStorm, a middleware which was designed to transparently support the execution of Java applications over scale-out environments through application threads and data distribution. The experiments were conducted to evaluate the performance of those applications to qualify a large dataset over two scale-out environments (Cloud and Cluster). 1. Introduction Information Quality (IQ) is the area concerned with assessing the quality of system information. IQ levels ensure the confidence we have on a particular information to meet a context requirement. IQ has been currently playing an important role in business development, where it provides relevant information to maintain and grow companies operations [Eckerson 2002]. In that sense, information accuracy is a very important metric to IQ applications. However there are other elements to be considered such as the information deadline. Currently, companies require strategic and even operational information on demand and under given time constraints. That motivated the use of high performance computing (HPC) techniques to improve application performance through both application and data distribution. In that sense, companies such as IBM [The BlueGene/L Team 2002] and Cray [Smith et al. 1990] designed multiprocessor machines with large-capacity integrated memory modules (shared memory). Those computers have well defined scalability limits and execute a single operating system image, which simplifies the management and portability of applications. This approach, named scale-up [Michael et al. 2007], was mainly adopted by specific application domains due to high investments and scalability issues. At the same time, microprocessors, memory modules, network interface cards and other

105 90 Anais devices started being produced in a greater scale, which reduced their costs and made them accessible. The accessibility to commodity hardware motivated the design of clusters of computers (or simply clusters), which were rapidly adopted to obtain high performance computing at lower costs. Clusters consider a different approach to provide scalability. In that architecture, computer nodes are interconnected through a network and communicate with each other by message passing protocols. This strategy, named scale-out [Michael et al. 2007], provides a priori unlimited scalability and requires every node to run a different operating system image, which tends to cause consistency issues and makes the management and administration more complex. During the 1990 s, researchers started connecting clusters and composing larger environments. Other researchers also attempted to interconnect unusual resources to that architecture, such as laboratory instruments, visualization devices and expensive equipments which could be remotely shared. The grid computing concept is derived from those environments. Grids connect heterogeneous and geographically dispersed resources which cooperate to solve a computational problem [Foster et al. 2001]. After the term grid, other sectors introduced the term Cloud Computing [Buyya et al. 2008]. This latter is focused on providing software modules or components via Web services. Thus, when software needs to execute an operation, it makes a request to a service which is responsible for processing it and returning results. In summary, the scale-up approach is easier to administer due to there only being one central operating system image, which also avoids consistency problems. Multithreaded applications can also take advantage of this approach without any source code modification. Fault tolerance is also addressed by scale-up machines. On the other hand, those computers are very expensive. In that sense, investment reasons have been motivating the adoption of scale-out approaches. Besides being much cheaper, this latter considers many operating system images, which make managing tasks such as the system update and administration more complex. The multiple copies also bring up consistency issues (data copies may be in different versions). In addition, the scale-out approach also requires applications to be rewritten. Despite all those problems, the scale-out approach has no prior scalability limit. Besides all those points, scale-up approaches require a big investment at the beginning and, as long as the application is in the production environment, the cost is paid [Gillett 2008]. On the other hand, scale-out allows the addition of new computers to the environment as long as more resources are needed. In that way, investments are made only when necessary and they accompany the return (cash in) provided by the application execution. The availability of computing resources, investment and scalability issues have motivated improvements on communication systems, application adaptability, management of dispersed resources, security, process and data scheduling. All those issues make clear that scale-up is simpler and easier to use, however it is too costly. The scale-out approach is more complex to manage and administer and it requires application adaptation (an extensive source code modification), however it is cheaper, which motivates its adoption in several application domains. This trade off motivated us to design and implement a high performance computing platform called GoStorm

106 IX Workshop em Clouds, Grids e Aplicações 91 which provides transparent support for end-user applications and automatically manages distributed hardware resources and applications on scale-out environments. GoStorm is composed of a set of tools which provide autonomic computing features for executing and monitoring applications. Besides that, GoStorm innovates in application execution due to it being capable of distributing any Java application without source code modification and user interference. GoStorm also has the advantage (as described in [Ferreira et al. 2003]) of providing a virtual environment to applications, in which users do not need to worry about where the application is running. In that sense, all distributed resources are transparent and the user sees the system as a virtual supercomputer. The main objective of GoStorm is to take advantage of the lower investments required when designing scale-out environments and, at the same time, bring the easiness of use, administration and management of scale-up architectures to scale-out environments. Therefore, GoStorm aims at reducing the cost-performance ratio of applications. Besides all high performance theoretical and practical technological advances, our main objective is to address Information Quality applications on top of this platform. Consequently, we conducted several experiments to confirm its performance, robustness and availability when executing IQ processes. Results confirm that GoStorm improves the cost-performance ratio of IQ applications. Tests were conducted over two kinds of scaleout environments: Cloud and Cluster. This paper is organized as follows: first an overview of the company s IQ applications that makes use of GoStorm is presented. Then the GoStorm middleware is described. After that, the process of submitting applications to be run by GoStorm is explained. A section containing several experiments follows. Finally, conclusions and possible future works are presented. 2. Information Qualification Tool: Our Scenario Our interest in distributing Information Quality applications over scale-out architectures arose from the needs of some tools developed by our company. We will now discuss two of those tools: Address Validator (AV) and Person/Company Validator (PCV), which were the two first applications to execute on GoStorm. AV and PCV are both Java applications which process large datasets in order to enhance the quality of contained information. They do that by evaluating data records, generating candidate records and choosing the most appropriate one (original including) to replace the original. For example, there are several records with a wrong company name. A large list of candidate records is generated for each original record and PCV decides which of them contain the correct information. Afterwards, PCV updates the whole dataset, guaranteeing accuracy. AV works in the same manner, although it tends to be more computationally intensive due to the techniques used to calculate the similarity between the candidates and the original record. Both enrich the dataset, looking for complementary information on addresses, companies and people. All that supports marketing actions. Both AV and PCV have no dependency when processing data records, so datasets can be divided to balance the workload of concurrent executions on top of scale-out envi-

107 92 Anais ronments. This parallelism model is especially simple to apply in this context. However, some team efforts have been considered to design other parallelism levels for information quality applications. AV and PCV can also be connected to an information qualification flow by using the Information Quality tool developed by our company. The Information Quality tool is responsible for designing such flows which run over an ETL engine. Flows are composed of the input, output, join, handler, and qualifier nodes. Every flow is designed as a pipeline starting with an input node, which reads records from a dataset (i.e., files, databases), and ending with an output node, that writes information into the dataset. In between these two nodes, we can create sequences with join, handler and qualifier nodes. AV and PCV are associated to a qualifier node. For example, consider a flow composed of an input node connected to an AV node that is linked to an output node. This flow represents a simple Address Validator qualification process. AV and PCV nodes were specifically developed to support Brazilian data qualification, on the other hand, both join and handler nodes are generic components. The join is used to receive data from two or more nodes simultaneously. The handler is used to change record data according to user-defined rules, for example word capitalization. Unlike join and handler nodes, qualifier nodes are capable of splitting data into parallel threads. As threads finish, the qualified information is submitted to the next flow node. In addition to providing accuracy in data qualification process, these tools should be as fast as possible since they have to support the qualification of large data volumes. This has been a constant struggle, since there is often a tradeoff between accuracy and speed of processing. Despite our best efforts, processing very large dataset still takes a lot of processing power. In next section, the scaling handling of those processes are presented. 3. Scaling Out with GoStorm Both importance and amount of information have been increasing in the current global business scenario. Combining data from different business data sources enriches the information, but it also increases the amount of data that must be dealt with. Moreover, the complexity to analyze such information and qualify it has also become a major challenge. In order to deal with this complexity and with the constantly increasing amount of data and still obtain qualified data in a timely manner the processing power has to increase as well. In scaling computational power there are two approaches to be considered: (i) invest in scale-up environments; (ii) invest in scale-out environments. In this manner, scale-up pays for itself only after time, while scale-out accompanies the business needs and, therefore, its pay off is instantaneous. Consequently, we consider the latter approach as the best as it allows us to keep qualification accuracy and it also supports gradual investments over time. However, the scale-out approach has one important drawback: generally the application needs be modified before it can be used over a scale-out environment. This was the main motivation to start the GoStorm project: offering tools that allow Java applications to be transparently distributed over scale-out environments. In summary, GoStorm takes advantage of scale-out concepts to provide four main

108 IX Workshop em Clouds, Grids e Aplicações 93 contributions: (i) reduce the time and cost to port applications to run over scale-out environments; (ii) reduce the need for great investments at once, thus, companies can increase their processing capacity as the business evolves; (iii) improve the computing performance of information quality processes; (iv) allow the qualification of very large datasets. The GoStorm project provides the following main functionalities: communication, security, high availability, application adaptability, process and data scheduling and high-level configuration policies. All those functionalities are implemented in software modules which interact to structure and manage scale-out computing environments. Those modules, organized in a layered manner, compose the GoStorm architecture presented in Figure 1. Communication GoStorm provides a peer-to-peer protocol to manage inter-node communication. This protocol builds up an overlay network to connect nodes. Every node is represented by a node identifier which is used to send and receive messages. The protocol was designed to support synchronous and asynchronous messages, as well as any transport and network protocols. Currently, it is implemented using TCP (Transmission Control Protocol) over IP (Internet Protocol); Cryptography Communication operations can occur with or without encryption. This module adds an extra overhead to encrypt and decrypt messages, however it makes communication reliable and confidential; Checkpoint GoStorm runs single and multithreaded applications. Those threads are distributed over the scale-out environment and execute on different computers. In order to avoid the waste processing time and make migration possible, the checkpoint module saves thread states into files. In case of thread failure, it can be resumed from the point it was saved. Those states are also copied to other computers and, in case of a node failure, it is resumed in another node. Besides that, the state can also be used to migrate a thread to other nodes and, afterwards, resume it; File Manager This module divides files into data chunks and distributes them over a set of computers called chunk servers. Chunks are replicated on different chunk servers which increases the system availability. In that manner, if a chunk server goes down, another one can fulfill application requests. Besides chunk servers, there are still the meta-data servers that work as indices to chunk servers. A meta-data server references chunks in chunk servers. Meta-data are replicated among servers and when eventually a meta-data server goes down, another one can meet the applications needs. A catalog service lists all the meta-data servers. When an application needs to access files, it requests a meta-data server to the catalog. From then on, GoStorm manages the interaction in between the application and the meta-data server as well as chunk servers. Data is kept consistent among chunk servers and meta-data servers; Memory Manager As previously mentioned, multithreaded applications are executed on top of GoStorm. Those threads are translated into GoStorm Threads and distributed over the environment. Threads traditionally communicate with one another by using the local shared memory. GoStorm simulates this shared memory in the Memory Manager module. The module provides a distributed shared memory layer on top of the communication module. In that way, threads need no modification to execute on GoStorm. They access the memory in the same way

109 94 Anais they do locally; Benchmark Every computer available in the scale-out environment has particular capacities. This benchmark module is responsible for extracting the CPU, memory, hard disk and network capacities of nodes. It obtains the maximum number of instructions that are executed by the processor, the memory and hard disk availability and performance, and the network interface card bandwidth. All that information is obtained when GoStorm is installed or whenever the administrator launches the module. After obtaining the information, it is kept in a local file for future use; Monitors Two monitors are available in GoStorm. The first is the system monitor which obtains the processor, memory, hard disk and network usage for every node. This information, in conjunction with the benchmark, makes it possible to evaluate the percentage of free and occupied resources. The second is the application monitor which intercepts thread system calls, generating time series on resource occupation. Therefore, those series contain the history of every thread. By composing histories, we know the full application behavior; Predictor The historical behavior of thread occupation (CPU, memory, hard disk and network) is saved into databases. When a new application is launched, its historical behavior is evaluated and, then, GoStorm gets a big picture about how resources will be used by threads. This resource occupation is sent to the Submitter in order to support process allocation. Besides this historical predictor, GoStorm was also designed to support an online time-series predictor which is under development. This predictor analyses time series observations and makes predictions on when a specific resource will be required and which process will need it. Using that information, the scheduler can predefine allocation and migration of workloads; Scheduler All node capacity information (obtained using the benchmark module) and usage (system and application monitors) are submitted to the process scheduler which also considers historical predictions on thread occupation to take scheduling decisions. Based on all that information, the scheduler runs a policy to optimize application needs according to resource availability; Dispatcher The dispatcher module launches applications on GoStorm. It basically receives the user command and parameters and starts the allocation operation. It communicates with the scheduler and requests the execution; Translator Thread system calls are intercepted and saved by the application monitor, the checkpoint saves thread states and makes resuming possible, the distributed shared memory works transparently with applications. All this is possible due to the translator which is responsible for transparently adapting applications and preparing them to run on GoStorm; Policy Configuration This module is responsible for modeling high-level management policies. It defines how long a computer will be available to GoStorm applications, when they will be and which applications can execute on those nodes. It also defines security policies such as available communication ports, supported protocols and users; Access Control This defines a database of users and their respective rights. When a user is authenticated, a token is created and sent to every application launched by the user. The token informs the user rights to the available resources;

110 IX Workshop em Clouds, Grids e Aplicações 95 Figure 1. GoStorm architecture The previously addressed modules are used to compose GoStorm entities. Those entities run on nodes to compose the scale-out environment. The entities are: Worker This entity is responsible for executing user applications. It receives threads, executes them and generates results; Broker Brokers communicate with each other to compose the overlay communication infrastructure. They are all registered into a catalog and, therefore, one Broker can find others. After finding each other, they usually connect to the nearby Brokers to make the peer-to-peer network available. Then, Workers connect to Brokers to provide resources; Submitter Many submitters can be started in the scale-out environment. Every submitter connects to one or more Brokers. It also receives the request to launch user applications and, then, spreads a search over the overlay network, requesting historical information on that application. This request is sent to Brokers which spread it to Workers. Workers evaluate their local historical database looking for that application. Finding information on that application, the Worker summarizes it using a nearest neighbor approach and sends it back to the submitter [Senger et al. 2007]. Either they find information or not, Workers send their respective capacity and current workloads to the scheduler. After receiving all that information, the scheduler composes them all and executes an optimizer which is responsible for taking decisions about which resource every thread will be placed on. Communicating threads will preferably be allocated on nearby nodes. Independent threads can be allocated on any available and capable resource. By communicating threads, we mean the ones that access the distributed shared memory or the

111 96 Anais distributed file system, since they can read and write data on both; Distributed File System (DFS) The distributed file system entity is responsible for managing the meta-data and chunk servers of files. It is installed in multiple computers. It keeps data available, replicates and allows the parallel access of chunks. For example, consider one chunk c. The DFS entity replicates it to several chunk servers and, in case of writing operations, the DFS maintains all copies consistent. Having multiple copies of the same chunk c on different chunk servers, an application can request it in parallel and read parts of it from different servers. That makes reading operations faster. The same can be used to write data on chunk servers and keep it consistent; Distributed Shared Memory (DSM) The distributed shared memory entity creates a layer on top of the peer-to-peer overlay network and provides memory to applications. This layer is transparent to applications. This means that applications do not need modifications to access the shared memory, consequently, they behave in the same way they do on local shared memory computers. Technical details about the implementation of GoStorm can be found in [Mantini et al. 2009]. The next section details the steps to execute an application on GoStorm. 4. Application Submission The submission of applications to scale-out environments is a very important issue, since available platforms (for clusters, grids and clouds) require a broad range of adaptations. However, there are several factors that preclude this adaptation, for example: the software can be developed by third parties and the user may not have full source-code access; source-code modifications consume financial resources and time; the modified source code hardly ever performs in the traditional environment, thus requiring two different versions. Moreover, different versions of the code make the maintenance more difficult as any update requires changes in both versions. Aiming at addressing this problem, GoStorm delivers an innovative and transparent mechanism to automatically execute any Java application without source-code adaptations. Therefore, the user does not need to have the source code available nor make any kind of adjustment in the original application, i.e. the same Java code is executed on the distributed environment. For this purpose, GoStorm provides a submission tool, which is responsible for making just-in-time changes at the byte-code level. As a first step, the submission tool receives the application classes, parameters and required dependencies (through the Java Classpath) in the same way the Java Virtual Machine does (via command line). On a second step, GoStorm sends the original application classes to the DFS, which makes them available to the whole environment (using the GoStorm Distributed File System). At last, the information of the main application thread is encapsulated in a GoStorm Job Object, which is submitted to the Scheduler. Once the application is submitted to GoStorm, proper scheduling policies are applied and the Job is allocated on a Worker entity, where it will execute. Before executing, the Job needs to be prepared for execution on the distributed environment. The bytecode is swept and all file access calls are replaced by proxy calls, which redirect them to the DFS. The calls responsible for launching threads are transparently replaced by

112 IX Workshop em Clouds, Grids e Aplicações 97 Figure 2. Application Mapping GoStorm thread distribution calls. At last, an object-shared discovery algorithm identifies which objects should be managed by the DSM module. Byte-code instructions that access these objects are replaced by instructions that access the DSM. All such interceptions are performed on-the-fly, by modifying the compiled byte-code of the classes, using the third-party library ASM [ Eric Bruneton et al. 2002] (this is conducted during the class loading). After such modifications, the application will access the DFS as storage (when reading or writing files) and have all threads distributed without human intervention. Threads launched by the application (Figure 2) are encapsulated in new Jobs, subsequently sent to the Scheduler (responsible to take scheduling decisions). All steps are repeated for every Job. When a thread finishes, its results (i.e. the final thread object) are reintegrated to the job that launched it. This approach guarantees a transparent execution to end users, suppressing the need of modifying application source codes. Therefore, every application thread is automatically and gracefully distributed, simplifying the scalability of virtually any Java application. 5. Experiments In order to evaluate GoStorm, we considered two types of scale-out environments: one cloud and one cluster computing environment. The cloud environment was composed of seven dual-core at 2.2Ghz, 2GB RAM and 100GB HDD connected through a 100Mb/s switch, thus, this environment provides 14 cores. The cluster computing environment was formed by three dual-core at 2.3GHz, 2GB RAM and 100GB HDD, forming a 6-core environment. In both environments, we deployed the following GoStorm components: one Catalog service, one Broker, and as many Workers as the number of cores available. Each component was launched on an isolated JVM (Java Virtual Machine) and Workers was configured to use up to 2GB main memory in the cloud scenario and 1.5GB in the cluster environment. Each Worker was able to run simultaneously a job by each core. Figure 3 illustrates how GoStorm components were deployed on top of both environments. In the cloud environment, we executed a simple AV flow with an input node, used to read data from a file, an Address Validator node, which qualifies information, and an output node to write information back to a file. This flow was executed over a 1.5M dataset with incomplete People, Company and Address information. It is important to

113 98 Anais Figure 3. Scale-Out Environment mention that only AV threads were distributed. The speedup results for this first experiment are presented in Figure 4. The flow was executed using from 1 to 14 cores. The execution was performed 20 times and the average was computed. The dotted lines show the ideal speedup while solid ones represent the speedup obtained. Although the speedup does not fit in the ideal linear curve (the ideal curve represent that performance increases in the same rate as computing elements are introduced in the environment), we observe a significant performance improvement as nodes are added (including more cores) to the environment. This experiment confirms that GoStorm provides scalability for the qualification of large datasets under distributed environments. In the cluster computing scenario, three different flows were considered in order to compare their speedup behavior: (i) a simple AV flow, (ii) a simple PCV flow and (iii) a flow with an AV and a PCV (in this sequence). Every flow started with an input node (reading from file) and finished with an output node (writing qualified records back to a file). Results are presented in Figure 5. Each flow was performed 20 times and the average was used to draw the speedup line. The line identified as AV is related to the simple AV flow. The line identified as PCV is related to the simple PCV flow. At last, the line identified as AV and PCV is related to the flow that contains an AV node followed by a PCV node (the ideal line represent that performance increases in the same rate as computing elements are introduced in the environment). This set of experiments was created to demonstrate the speedup behavior in both isolated qualification nodes and in concatenated qualification nodes. The results show that the simple AV flow has a lower speedup when compared to the flow composed of an AV node and a PCV node. In the same way, the flow composed of an AV node and a PCV node obtained lower speedup than the simple PCV flow. This confirms that the lower speedup of the AV is limiting the total performance of the concatenated flow. This was expected since, as shown in Table 1, the AV consumes more processing time than PCV. Furthermore, in the concatenated flow the AV adds to each record a number of fields related to the qualification, which forces the PCV to deal with a larger volume of data than in the simple PCV flow increasing communication overhead. Despite that, the concatenated flow still managed to achieve a speedup that was

114 IX Workshop em Clouds, Grids e Aplicações 99 between the speedups obtained by the components on simple flows. This indicates that GoStorm obtains a significative speedup even when dealing with more complex flows, as long as the individual components can be successfully distributed. Flow/Cores AV PCV AV/PCV Table 1. Time series in seconds. Figure 4. AV speedup in cloud environment 6. Conclusion and Future Works This paper presents a transparent and automatic middleware, named GoStorm, to distribute IQ applications on top of scale-out environments. GoStorm currently addresses a suite of Information Quality applications. Experiments were conducted to evaluate the performance provided by GoStorm to IQ flows on a cluster and a cloud computing environment. Results confirm a considerable speedup provided by the proposed middleware. As future work, we will conduct further experiments considering larger environments. We also intend to support transparent access to distributed database systems [Bernstein et al. 1981] like NoSql. This will be important to continue dealing with large datasets for two reasons: (i) it will allow large datasets to be spread over several machines, eliminating the need for one big and reliable machine capable of storing the whole dataset; (ii) it leads to faster access to the data through the distribution of the queries, which will be important to achieve good speedups. We are also considering conduct experiments with other Information Quality tools like data merge solutions [De Mello et al. 2010] and swarm optimization strategies [De Abreu et al. 2010]. Those applications test the shared memory module to find out the best candidate records, improving application accuracy.

115 100 Anais Figure 5. AV and CPV speedup in cluster environment 7. Acknowledgments This paper is based upon work supported by FINEP 1 (Financiadora de Estudo e Projetos), Brazil. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of FINEP. References Bernstein, P. A., Goodman, N., Wong, E., Reeve, C. L., and Rothnie, J. B. (1981). Query processing in a system for distributed databases (SDD-1). ACM Transactions on Database Systems, 6: Buyya, R., Yeo, C. S., and Venugopal, S. (2008). Market-oriented cloud computing: Vision, hype, and reality for delivering it services as computing utilities. CoRR, abs/ De Abreu, S. C., De Almeida, T. O., Junior, L. C. R., and de Mello, M. T., editors (2010). A New Cycle of Improvement for Information Quality Services, Little Rock, US. The Donaghey College of Engineering and Information Technology, University of Arkansas, HPI/MIT. De Mello, M. T., Frainer, G. C., De Souza, J. G. C., and Junior, L. C. R., editors (2010). Towards a High Performance Merge Solution for Large-Scale Datasets, Little Rock, US. The Donaghey College of Engineering and Information Technology, University of Arkansas, HPI/MIT. Eckerson, W. W. (2002). Data quality and the bottom line: Achieving business success through a commitment to high quality data. In The Data Warehousing Institute., pages Communications, Chatsworth, Calif. 1

116 IX Workshop em Clouds, Grids e Aplicações 101 Eric Bruneton, Lenglet, R., and Coupaye, T. (2002). ASM: a code manipulation tool to implement adaptable systems. In Proceedings of the ASF (ACM SIGOPS France) Journ ees Composants 2002 : Syst emes a composants adaptables et extensibles (Adaptable and extensible component systems). Ferreira, L., Berstis, V., Armstrong, J., Kendzierski, M., Neukoetter, A., MasanobuTakagi, Bing, R., Amir, A., Murakawa, R., Hernandez, O., Magowan, J., and Bieberstein, N. (2003). Introduction to grid computing with globus. Technical report, IBM Corp., Riverton, NJ, USA. Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. Int. J. High Perform. Comput. Appl., 15: Gillett, F. E. (2008). Technology industry webinar: An overview of cloud computing for marketers. Technical report, Forrester Research. Mantini, A., Frainer, G., Rios, R., Jr., L. P., Storch, M., Geiss, M., and Mello, R. F. (2009). Gostorm: A new platform driven to scale-out environments. In The 3rd International Workshop on Latin American Grid, volume 1, pages 1 6. IEEE Computer. Michael, M. M., Moreira, J. E., Shiloach, D., and Wisniewski, R. W. (2007). Scale-up x scale-out: A case study using nutch/lucene. In IPDPS, pages 1 8. IEEE. Senger, L. J., Mello, R. F., Santana, M. J., and Santana, R. H. C. (2007). Aprendizado baseado em instâncias aplicado a predicao de características de execucao de aplicacoes paralelas. In Revista de Informática Teórica e Aplicada, volume 14, pages Smith, J. E., Hsu, W.-C., and Hsiung, C. (1990). Future general purpose supercomputer architectures. In Proceedings of the 1990 ACM/IEEE conference on Supercomputing, Supercomputing 90, pages , Los Alamitos, CA, USA. IEEE Computer Society Press. The BlueGene/L Team (2002). An overview of the bluegene/l supercomputer. In Proceedings of the 2002 ACM/IEEE conference on Supercomputing, Supercomputing 02, pages 1 22, Los Alamitos, CA, USA. IEEE Computer Society Press.

117 102 Anais

118 IX Workshop em Clouds, Grids e Aplicações 103 CloudReports: uma ferramenta gráfica para a simulação de ambientes computacionais em nuvem baseada no framework CloudSim Thiago Teixeira Sá 1,2, José Marques Soares 2,3, Danielo G. Gomes 1,2,3 1 Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat) 2 Programa de Pós-Graduação em Engenharia de Teleinformática (PPGETI) 3 Departamento de Engenharia de Teleinformática (DETI) Universidade Federal do Ceará (UFC) Campus do Pici, Fortaleza CE Brasil Abstract. This paper describes the development of a set of extensions for the CloudSim simulation framework towards the creation of a graphic simulator for distributed computing environments based on the Cloud Computing paradigm. It is designed so that users with no programming skills can create a virtually unlimited number of environments through an easy-to-use graphic user interface and perform simulations by using the features provided by the Cloud- Sim framework. The tool, entitled CloudReports, provides flexibility to create datacenters, hosts and virtual machines with different and entirely customizable configurations. Moreover, the reports generation feature makes it easier to understand the simulation results by displaying charts and lists of the simulated environments characteristics. The simluation experiments with CloudReports indicate very satisfactory results, facilitating the CloudSim framework use without abdicating extensibility or customizability. Resumo. Este artigo descreve a criação de um conjunto de extensões para o framework de simulação CloudSim, visando a concepção de um simulador gráfico para ambientes computacionais distribuídos baseados no paradigma da Computação em Nuvem. Através desta nova ferramenta, usuários sem experiência em programação podem criar um número virtualmente ilimitado de cenários de simulação por meio de uma interface gráfica de fácil utilização e realizar simulações através dos recursos oferecidos pelo framework CloudSim. A ferramenta, denominada CloudReports, oferece flexibilidade para a criação de datacenters, hosts e máquinas virtuais com configurações distintas e inteiramente customizáveis. Ademais, a funcionalidade de geração de relatórios facilita a compreensão dos resultados de simulação por meio de gráficos e listagens de características dos ambientes simulados. Os experimentos de simulação realizados com o CloudReports mostram resultados bastante satisfatórios, facilitando o emprego do framework CloudSim sem abdicar de características como extensibilidade e capacidade de personalização. 0 * Bolsista da Fundação Cearense de Apoio ao Desenvolvimento Científico e Tecnológico (processo FUNCAP BMD /11) 0 Laboratório associado ao INCT-MACC (processo CNPq /2008-2).

119 104 Anais 1. Introdução A Computação em Nuvem propõe a integração de modelos tecnológicos para o provimento de infraestrutura de hardware, plataformas de desenvolvimento e aplicações na forma de serviços disponíveis remotamente e em escala global. Neste novo paradigma de utilização de recursos computacionais, clientes abrem mão da administração de uma infraestrutura própria e dispõem de serviços oferecidos por terceiros, delegando responsabilidades e assumindo custos estritamente proporcionais à quantidade de recursos que utilizam. Dado o elevado potencial e complexidade deste cenário, e tendo em vista a crescente adoção de serviços em nuvem observada no mercado e a intensa atividade de pesquisa acadêmica nesta área, torna-se evidente a necessidade de ferramentas que viabilizem uma análise detalhada do funcionamento destes ambientes e provejam meios para o desenvolvimento de técnicas que aperfeiçoem o emprego dos recursos computacionais envolvidos. Como a utilização de testbeds reais limita a realização de experimentos do ponto de vista da escalabilidade e torna difícil a reprodução dos resultados obtidos [CloudSim 2010], faz-se necessária a existência de alternativas para a simulação de ambientes computacionais em nuvem através das quais a validação de novas técnicas seja realizada de forma escalável e facilmente reproduzível. O emprego de ferramentas de simulação elimina ainda a necessidade de uma infraestrutura real atrelada aos experimentos e todos os custos relacionados à utilização da mesma. Neste trabalho, propomos o CloudReports, uma ferramenta gráfica de simulação de ambientes computacionais em nuvem baseada em extensões do framework Cloud- Sim. Sua principal contribuição consiste em prover meios para que usuários sem experiência em programação possam criar um número virtualmente ilimitado de cenários de simulação por meio de uma interface gráfica de fácil utilização. A ferramenta oferece ainda recursos para a geração de relatórios, que descrevem com alto grau de detalhamento as informações referentes ao processo de simulação. O CloudReports é composto por cinco módulos distintos, independentes e extensíveis. Estes módulos são responsáveis pela criação de novas políticas de escalonamento, comunicação com o motor de simulação, criação do cenário simulado, geração de relatórios e composição da interface gráfica de usuário. Na configuração dos experimentos realizados, foi simulado um cenário composto por 4 clientes (com perfis de utilização distintos) e 4 datacenters. Obteve-se, assim, informações relativas à utilização de cada datacenter, a saber : (i) quantidade de máquinas virtuais alocadas; (ii) número de tarefas (cloudlets) executadas; (iii) custos gerados e (iv) quantidade de recursos utilizados. Sob o ponto de vista da utilização de máquinas virtuais, foram fornecidas informações tais como: (i) quantidade de cloudlets executadas; (ii) quantidade de recursos utilizados e (iii) tempo de execução de cloudlets. 2. Trabalhos relacionados Uma alternativa para a simulação de ambientes de computação distribuída é apontada em [Legrand et al. 2003], que trata do framework de simulação de grades computacionais SimGrid. Em [Sulistio et al. 2008], uma extensão à ferramenta GridSim é apresentada. Também voltado para a simulação de grades computacionais, o GridSim é o precursor do framework de simulação empregado neste trabalho, denominado CloudSim e com sua mais recente versão apresentada em [Calheiros et al. 2010].

120 IX Workshop em Clouds, Grids e Aplicações 105 Por fim, as oportunidades e desafios que surgem com o advento da simulação de ambientes computacionais em nuvem são discutidos em [Buyya et al. 2009], e alguns dos resultados já obtidos através do uso destas ferramentas são mostrados em [Beloglazov and Buyya 2010], [Calheiros et al. 2010] e [Kim et al. 2009]. Um modelador gráfico de ambientes computacionais em nuvem igualmente baseado no framework CloudSim e chamado CloudAnalyst é tratado em [Wickremasinghe et al. 2010]. 3. CloudSim O framework CloudSim [Calheiros et al. 2010] visa oferecer os recursos necessários para a simulação de ambientes computacionais em nuvem. Desenvolvido inteiramente em Java e licenciado pela General Public License (GPL), o framework é extensível, facilmente adaptável e permite a criação de simulações em grande escala com alto grau de customização [Calheiros et al. 2009]. A Figura 1 ilustra as camadas que compõem a arquitetura do CloudSim. No nível mais inferior, observa-se o motor de simulação, responsável pelas operações de criação, gerenciamento e exclusão das entidades simuladas. A camada seguinte ilustra as principais classes que compõem o framework e é composta por diferentes módulos. No módulo de rede, são realizados o mapeamento de enlaces entre datacenters e clientes e o cálculo de atraso das mensagens trocadas entre os mesmos. O módulo de recursos da nuvem realiza a manipulação e coordenação dos eventos da simulação, além de gerenciar os dados relativos à infraestrutura oferecida por meio dos datacenters simulados. Em seguida, o módulo de serviços da nuvem ilustra as ações de provimento de máquinas virtuais e alocação de recursos como memória de sistema, processamento, armazenamento de dados e largura de banda de comunicação. Observa-se então o módulo de serviços das máquinas virtuais, onde são realizadas a gerência das mesmas e a execução das tarefas enviadas pelos clientes, denominadas cloudlets. Por fim, a comunicação das entidades que compõem a nuvem com os clientes que utilizam seus recursos é feita por meio do módulo de interface, no qual máquinas virtuais e cloudlets podem ser manipuladas. Figura 1. A arquitetura do framework CloudSim. A última camada da Figura 1 representa o código que o usuário do framework deve implementar para a criação dos ambientes de simulação. O módulo de política de escalonamento indica a criação das políticas de decisão e escalonadores que nortearão os processos de simulação. Além dos mecanismos de decisão denominados políticas de broker, o CloudSim permite a implementação de políticas de alocação de máquinas virtuais entre os hosts de um mesmo datacenter, escalonadores de máquinas virtuais em

121 106 Anais hosts e escalonadores de cloudlets em máquinas virtuais. Estes escalonadores podem lançar mão do compartilhamento de recursos no domínio do espaço ou do tempo. 4. CloudReports O objetivo principal deste trabalho concentra-se na construção de um conjunto de extensões para o framework CloudSim, visando a concepção de uma ferramenta de simulação para sistemas distribuídos cujas arquiteturas seguem o modelo hoje denominado Computação em Nuvem. Embora sua aplicação possua ampla disseminação comercial e o estudo de suas tecnologias gere um interesse crescente do meio acadêmico, esse novo paradigma de provisão e utilização de recursos computacionais ainda carece de alternativas para a criação de ambientes em âmbito de simulação. As atividades de pesquisa e desenvolvimento da área ainda se restringem à utilização de testbeds reais, o que naturalmente limita o poder de escala dos experimentos e os tornam de difícil reprodução [CloudSim 2010]. Empregando-se a plataforma de desenvolvimento Java e o framework de simulação CloudSim, além de ferramentas adicionais, criou-se o CloudReports, uma ferramenta gráfica de simulação que busca tornar a criação de simulações de ambientes computacionais em nuvem uma atividade prática e objetiva, embora mantendo características fundamentais como escalabilidade, alto grau de customização e extensibilidade. O CloudReports permite que usuários não familiarizados com a linguagem Java realizem simulações através de uma interface gráfica simples e intuitiva (Figura 2). Os ambientes construídos podem ser salvos e armazenados em disco para a reprodução posterior dos resultados obtidos, e detalhes das simulações são registrados através de um recurso de geração automática de logs. Figura 2. Interface gráfica do CloudReports. A interface gráfica oferece flexibilidade para a criação de datacenters com quantidade variável de recursos, incluindo, ainda, a customização individual dos hosts que o compõem. Esse aspecto flexível também é aplicado à criação de clientes, dado que os

122 IX Workshop em Clouds, Grids e Aplicações 107 mesmos podem dispor de máquinas virtuais com configurações distintas e inteiramente customizáveis. Após o término da simulação, é realizada uma compilação de informações relevantes para a compreensão dos dados gerados. Grande parte dessas informações é exibida na forma de gráficos explanatórios, que podem ser manipulados pelo usuário e armazenados em disco no formato de imagens Ambiente de simulação O ambiente de simulação do CloudReports reproduz a interação entre um provedor de Infraestrutura como Serviço (IaaS) e seus clientes. O provedor possui de um a muitos datacenters, que podem ser modelados de acordo com seu sistema operacional, arquitetura dos processadores, hipervisor empregado, banda disponível, custos de utilização, política de alocação de máquinas virtuais e opções de consumo de energia. Há ainda atributos relativos às redes de comunicação que interligam as entidades simuladas. Os hosts que compõem um datacenter podem ser configurados atribuindo-se valores de memória de sistema, banda, armazenamento, poder de processamento e opções de escalonadores de máquinas virtuais e modelos de utilização energética. A criação de datacenters heterogêneos torna-se simples por meio da adição de diferentes perfis de configuração de hosts. Os clientes, por sua vez, são modelados por meio de um perfil de utilização de recursos e configurações relativas às máquinas virtuais que serão executadas através da infraestrutura oferecida pelo provedor. O perfil de utilização consiste em uma descrição das tarefas, denominadas cloudlets, que serão processadas pelas máquinas virtuais e pela indicação de uma política de escolha de datacenters representada pela entidade broker. As cloudlets são descritas através de características como quantidade de núcleos necessária para o processamento, dimensão em milhões de instruções por segundo (MIPS) e tamanho dos arquivos de entrada e saída que serão transferidos entre clientes e datacenters. Há ainda modelos distintos de utilização de CPU, memória e banda de comunicação. Por fim, o tipo de broker determina de que forma serão escolhidos os datacenters que alocarão as máquinas virtuais e, por conseguinte, executarão as cloudlets. O CloudReports oferece quatro tipos distintos de brokers, que selecionam datacenters de acordo com critérios de custo, poder de processamento e latência de rede. A quarta opção consiste na ausência desses critérios, empregando-se um algoritmo round robin para a seleção dos datacenters Arquitetura O CloudReports é composto por cinco módulos distintos, formando a estrutura observada na Figura 3. Os módulos mostrados em azul foram criados por meio deste trabalho e são partes integrantes do CloudReports, enquanto os mostrados em vermelho representam componentes de terceiros utilizados pela aplicação. Na base dessa arquitetura, observa-se a Máquina Virtual Java (JVM), responsável pela interpretação dos bytecodes e pelo gerenciamento dos recursos utilizados junto ao sistema operacional. O CloudSim, framework utilizado como motor de simulação, encontrase entre a JVM e os módulos do CloudReports responsáveis pela tradução do ambiente criado através da interface gráfica para geração das entidades a serem simuladas.

123 108 Anais Figura 3. Estrutura em módulos do CloudReports Extensões O módulo de extensões é composto por classes que herdam características diretamente de elementos do CloudSim. Os brokers constituem o principal exemplo, pois são classes filhas do componente DatacenterBroker e buscam tornar seu comportamento mais específico, atendendo diretamente às necessidades da aplicação. Para que políticas de decisão fossem codificadas, criou-se quatro implementações da classe abstrata Broker, a saber: CheapestDatacenterBroker, FastestDatacenterBroker, LowestLatencyDatacenterBroker e RoundRobinDatacenterBroker. A classe Broker, por sua vez, é uma extensão da classe DatacenterBroker, pertencente ao framework CloudSim e responsável pela escolha de datacenters para a alocação de máquinas virtuais. Também foram implementadas extensões para as classes PowerDatacenter e DatacenterCharacteristics. Nestes casos, os objetivos consistem em melhorar as formas como cloudlets são executadas nos datacenters e facilitar a extração de dados para a composição dos relatórios finais Gerência de simulação O módulo de gerência de simulação é responsável pela obtenção de dados junto aos registros de entidades e pela tradução e transmissão dos mesmos à camada inferior. Após o termino da simulação, este módulo também é encarregado de enviar os dados resultantes para a camada de geração de relatórios, que, por sua vez, realiza o tratamento de todas as informações e as apresenta à interface gráfica. Grande parte desse tratamento é realizado com a utilização de recursos oferecidos pelo framework JFreeChart para a geração automática de gráficos Registro de entidades No módulo de registro de entidades, são armazenadas informações sobre a modelagem do cenário de simulação que é realizada através da interface gráfica. Posteriormente, essas informações são traduzidas pelo módulo de gerência de simulação para a criação de

124 IX Workshop em Clouds, Grids e Aplicações 109 entidades do CloudSim. As principais classes pertencentes a esse módulo são a DatacenterRegistry e a CustomerRegistry, que armazenam informações de datacenters e clientes respectivamente. Há uma relação de dependência entre as classes DatacenterRegistry, HostRegistry, SanStorageRegistry e a enumeração AllocationPolicy. Observa-se que um registro de datacenter possui uma lista de registros de hosts e áreas de armazenamento em rede, além de uma política de alocação de máquinas virtuais. Similarmente, há relações de dependência entre as classes CustomerRegistry, UtilizationProfile e VirtualMachineRegistry. Os clientes simulados possuem um um número arbitrário de máquinas virtuais e um perfil de utilização de recursos, que armazena informações sobre as cloudlets e está vinculado a uma política de broker Geração de relatórios O módulo de geração de relatórios comunica-se diretamente com a gerência de simulação para a obtenção dos dados que compõem os relatórios finais. As informações são obtidas tanto em tempo de simulação quanto após o término da mesma. Em seguida, os resultados são processados e transmitidos à camada superior, onde serão exibidos por meio da interface gráfica Interface Gráfica de Usuário A camada superior da estrutura consiste na interface gráfica (GUI). O usuário a utiliza diretamente para criar ambientes, dar início às simulações e visualizar os relatórios finais. Por ser responsável pelo armazenamento das características que definem os ambientes, o módulo de registros de entidades comunica-se constantemente com a camada superior e também transmite informações de forma direta para a geração de relatórios Entidades funcionais As simulações realizadas por meio do CloudReports possuem dois tipos de entidades funcionais: os registros e os serviços de informação. Os primeiros representam elementos que compõem um ambiente real, como datacenters e clientes. São eles: CustomerRegistry, DatacenterRegistry, HostRegistry, SanStorageRegistry e VirtualMachineRegistry. Instâncias dessas entidades são geradas automaticamente à medida que o usuário modela um ambiente de simulação através da interface gráfica da aplicação. Os serviços de informação são entidades através das quais diferentes módulos da aplicação têm acesso aos registros existentes. O DatacenterInformationService fornece informações sobre datacenters e, por conseguinte, seus hosts e áreas de armazenamento em rede (SAN). Através do CustomerInformationService, pode-se obter dados relativos aos clientes e suas máquinas virtuais. Há ainda o NetworkInformationService, que disponibiliza informações sobre os links de comunicação entre registros de datacenters e clientes. 5. Cenário simulado As simulações realizadas por meio do CloudReports são compostas por dois tipos principais de agentes: um provedor de IaaS, que possui de um a muitos datacenters, e um

125 110 Anais conjunto de clientes que dispõem desse serviço. Os clientes utilizam os recursos oferecidos pelo provedor para o envio e a alocação de máquinas virtuais que, por sua vez, executam um conjunto de tarefas, aqui denominadas cloudlets. A dinâmica de escolha de datacenters para o envio e alocação de máquinas virtuais e a posterior execução de cloudlets é ditada pelo perfil de utilização dos clientes e pelos recursos oferecidos pelo provedor. O cenário aqui simulado é formado por um provedor de IaaS e quatro clientes, descritos a seguir Provedor A infraestrutura do provedor a ser simulado é composta por quatro datacenters identificados pelos nomes das cidades onde se encontram, a saber: Fortaleza, São Paulo, Rio de Janeiro e Brasília. Cada datacenter possui uma quantidade de recursos distinta. A arquitetura de processamento, o sistema operacional, o hipervisor utilizado e os custos de utilização são atributos únicos de um datacenter, sendo automaticamente aplicados a todos os seus nós. Por outro lado, o poder de processamento, a quantidade de memória de sistema e a capacidade de armazenamento são características de hosts, que podem ser customizados individualmente, criando-se datacenters com recursos heterogêneos. Há de se ressaltar, porém, que todos os datacenters aqui simulados são compostos por nós homogêneos, ou seja, todos os hosts possuem a mesma configuração. Os atributos dos hosts exercem grande influência no fluxo de eventos da simulação, pois, para que uma máquina virtual seja efetivamente alocada, é necessário que ao menos um host do provedor seja capaz de atender simultaneamente a seus requisitos de recursos e ao perfil de utilização do cliente. O processo de simulação também conta com uma reprodução simples dos enlaces de comunicação existentes entre datacenters e clientes. Essas conexões são representadas através de valores de largura de banda e latência de rede Clientes A composição do cenário simulado é constituída por quatro clientes, aqui denominados Cliente 1, Cliente 2, Cliente 3 e Cliente 4. Suas máquinas virtuais devem ser enviadas e alocadas em hosts que atendam aos requisitos mínimos de recursos das mesmas. Ademais, os hosts escolhidos devem pertencer a um datacenter que siga o perfil de utilização do cliente. Posteriormente, os clientes enviam as cloudlets que serão executadas por essas máquinas virtuais e enviadas de volta após a execução. No cenário simulado, todos os clientes possuem máquinas virtuais com configurações idênticas. Esta abordagem foi adotada com o intuito de simplificar a análise dos dados. Contudo, ressalta-se que o CloudReports permite a criação de múltiplas configurações de máquinas virtuais para cada cliente simulado. Cada cliente emprega uma das políticas de broker oferecidas pelo simulador para que se verifique a influência das mesmas nos resultados obtidos, a saber: o Cliente 1 emprega a política Round Robin, o Cliente 2 opta pelos datacenters mais baratos, o Cliente 3 seleciona os datacenters com maior capacidade de processamento e o Cliente 4 opta por menores valores de latência de comunicação.

126 IX Workshop em Clouds, Grids e Aplicações Resultados Os dados obtidos após o processo de simulação são representados por meio de várias modalidades de gráficos e listas de informações. Adicionalmente, um log é produzido com descrições detalhadas do fluxo de eventos da simulação. Nas seções subsequentes, são analisados cada um dos gráficos que compõem o relatório produzido pelo CloudReports Máquinas virtuais alocadas por datacenter O gráfico de máquinas virtuais alocadas por datacenter é mostrado na Figura 4. Por conta da política de broker Round Robin, o Cliente 1 executa parte de suas máquinas virtuais em cada um dos datacenters disponíveis. O Cliente 2, por sua vez, emprega a política Cheapest Datacenter, que seleciona os menores custos de utilização. Como os datacenters localizados em São Paulo e Fortaleza possuem os menores preços, ambos alocam as máquinas virtuais do Cliente 2. A política Fastest Datacenter faz com que o Cliente 3 opte por alocar todas suas máquinas virtuais no datacenter de São Paulo, pois este possui a maior capacidade de processamento. Por fim, o datacenter com menor latência de comunicação com o Cliente 4, que emprega a política Lowest Latency, está localizado em Brasília e aloca todas as sete máquinas virtuais desse cliente. Figura 4. Máquinas virtuais alocadas por datacenter Cloudlets executadas por datacenter O gráfico de cloudlets executadas por datacenter tem um formato semelhante ao da Figura 4, visto que as cloudlets enviadas por cada cliente são executadas por suas respectivas máquinas virtuais. Dessa forma, o número de máquinas virtuais alocadas por cada datacenter é aproximadamente proporcional ao número de cloudlets executadas pelos mesmos, como mostrado na Figura Custos por datacenter Os custos produzidos por cada cliente em um determinado datacenter levam em consideração seu preço de utilização e a quantidade de recursos alocada para as máquinas virtuais. A Figura 6 mostra os custos gerados pelos quatro clientes simulados. Devido a sua política de broker Round Robin, o Cliente 1 gera custos em todos os datacenters. A política Cheapest Datacenter garante, como esperado, os menores custos de utilização ao Cliente 2. Já os clientes 3 e 4 geram custos apenas nos datacenters selecionados por suas políticas de broker para a alocação de suas máquinas virtuais.

127 112 Anais Figura 5. Cloudlets executadas por datacenter. Figura 6. Custos produzidos nos datacenters simulados Recursos utilizados por datacenter A quantidade de recursos utilizados nos datacenters de São Paulo e Rio de Janeiro é representada na Figura 7. São mostrados os valores relativos à utilização de CPU (em MIPS), memória de sistema e banda de comunicação durante todo o período de simulação. O método de distribuição de recursos utilizado nos datacenters estabelece que, uma vez alocada, uma máquina virtual sempre utiliza todos os recursos referentes à sua configuração. Em conformidade com esta característica, os gráficos da Figura 7 apresentam curvas semelhantes para os três tipos de recursos representados Cloudlets executadas por máquina virtual Os gráficos da Figura 8 mostram a quantidade de cloudlets que cada máquina virtual de um cliente executou durante o processo de simulação. A política de broker do Cliente 1 faz com que máquinas virtuais presentes em todos os datacenters simulados executem suas cloudlets, como já havia sido observado na Figura 5. O Cliente 2 tem duas máquinas virtuais alocadas em Fortaleza e três alocadas em São Paulo, cada uma delas executando

128 IX Workshop em Clouds, Grids e Aplicações 113 (a) (b) Figura 7. Janeiro. Recursos utilizados nos datacenters de (a) São Paulo e (b) Rio de precisamente trinta cloudlets. No caso do Cliente 3, de acordo com a política de broker Fastest Datacenter, quatro máquinas virtuais são alocadas em São Paulo e executam pouco mais de sessenta cloudlets. O Cliente 4 tem trezentas e cinqüenta cloudlets distribuídas igualmente entre suas sete máquinas virtuais alocadas no datacenter de Brasília Recursos utilizados por máquina virtual As máquinas virtuais simuladas sempre utilizam a quantidade total de recursos especificada em suas configurações. Desta forma, uma vez alocada, a máquina virtual mantém sua taxa de utilização de recursos constante, assim como mostrado nos gráficos da Figura 9 para duas máquinas virtuais do Cliente 3. Como todas as máquinas virtuais possuem a mesma configuração, percebe-se que a diferença entre os gráficos gerados reside apenas no momento em que cada uma delas é alocada. Devido à semelhança entre os gráficos e visando a simplificação na exibição dos dados, as taxas de utilização de recursos das máquinas virtuais dos demais clientes serão omitidas Tempo de execução por cloudlet Esta modalidade de gráfico mostra o tempo de partida e o tempo de chegada de todas as cloudlets de um dado cliente, resultando em uma representação visual do tempo de execução das mesmas. Ademais, duas linhas horizontais exibem as médias aritméticas desses valores, e a distância que as separa representa o tempo médio de execução das cloudlets. De acordo com o algoritmo Round Robin empregado pelo simulador, o vínculo entre N cloudlets e K máquinas virtuais de um dado cliente é estabelecido de acordo com a expressão VM k C (i+k), com 0 n < N e 0 k < K. Esta relação explica o efeito rampa observado na Figura 10 para os tempos de partida das cloudlets do Cliente 1. Além disso, o fato do escalonador das máquinas virtuais deste cliente compartilhar a execução de cloudlets no tempo é parcialmente responsável pelos vales existentes na curva dos tempos de chegada. Como algumas máquinas virtuais recebem um menor número de cloudlets, seu tempo total de execução é reduzido, o que dá origem ao fenômeno.

129 114 Anais (a) (b) (c) (d) Figura 8. Cloudlets executadas pelas máquinas virtuais do (a) Cliente 1, (b) Cliente 2, (c) Cliente 3 e (d) Cliente 4. As curvas de tempo de execução para os Clientes 2 e 3 se assemelham devido aos escalonadores de suas máquinas virtuais compartilharem a execução de cloudlets no espaço, obtendo-se assim os gráficos no formato de escada mostrados na Figura 11. Contudo, as linhas que compõem o gráfico do Cliente 2 têm um aspecto mais irregular devido ao fato de suas cloudlets serem executadas em dois datacenters distintos. A variação dos valores de latência de rede influencia diretamente o tempo de chegada das cloudlets, gerando a irregularidade observada. Por fim, as máquinas virtuais do Cliente 4 são executadas em um mesmo datacenter, recebem quantidades iguais de cloudlets e possuem escalonadores que compartilham a execução das mesmas no tempo. Neste caso, todas as cloudlets são enviadas simultaneamente aos datacenters, compartilham o tempo de CPU das máquinas virtuais durante sua execução e, ao fim do processo, são enviadas de volta ao cliente também simultaneamente, gerando um gráfico cujos tempos de partida e chegada de cloudlets são representados por duas linhas horizontais coincidentes com as linhas de tempo médio obervadas nos gráficos anteriores. 7. Conclusão A principal contribuição deste trabalho consiste na criação de uma ferramenta de software, intitulada CloudReports, cuja função é o provimento de uma interface gráfica e

130 IX Workshop em Clouds, Grids e Aplicações 115 (a) (b) Figura 9. Recursos utilizados pelas máquinas virtuais (a) VM0 e (b) VM1 do Cliente 3. Figura 10. Tempos de execução de cloudlets do Cliente 1. funcionalidades para geração de relatórios que, em conjunto com os recursos oferecidos pelo framework CloudSim, constituem um meio prático e flexível para a simulação de ambientes computacionais em nuvem. Essa ferramenta dispõe de recursos que possibilitam a configuração de uma quantidade virtualmente ilimitada de cenários de simulação compostos pela representação de um provedor de Infraestrutura como Serviço (IaaS) e de seus clientes, que lançam mão desse serviço para a alocação de máquinas virtuais. Ademais, o simulador oferece ao usuário uma interface gráfica de fácil utilização e que, atrelada ao recurso de geração de relatórios, exibe uma compilação dos resultados das simulações por meio de gráficos e listagens de características do ambiente. Algumas melhorias e correções estão programadas para tornar o CloudReports um simulador mais robusto e com resultados mais precisos e consistentes. A criação de políticas de broker e escalonadores mais sofisticados com a aplicação de técnicas de inteligência computacional representará um significativo acréscimo de qualidade nos resultados observados. Por fim, a implementação de novos modelos de provimento e utilização de recursos e o rebuscamento do modelo de representação dos enlaces de comunicação aproximarão os resultados simulados aos obtidos em um cenário real.

131 116 Anais (a) (b) Figura 11. Tempos de execução de cloudlets do (a) Cliente 2 e (b) Cliente 3. Referências Beloglazov, A. and Buyya, R. (2010). Energy efficient allocation of virtual machines in cloud data centers. Proceedings of the 10th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing. Buyya, R., Ranjan, R., and Calheiros, R. N. (2009). Modeling and simulation of scalable cloud computing environments and the cloudsim toolkit: Challenges and opportunities. Proceedings of the 7th High Performance Computing and Simulation (HPCS 2009) Conference. Calheiros, R. N., Buyya, R., Rose, C. A. F., and T.T. (2009). Cloudsim: A novel framework for modeling and simulation of cloud computing infrastructures and services. International Conference on Parallel Processing. Calheiros, R. N., Ranjan, R., Beloglazov, A., Rose, C. A. F., and Buyya, R. (2010). Cloudsim: A toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. International Journal of Software: Practice and Experience. CloudSim (2010). Cloudsim: A framework for modeling and simulation of cloud computing infrastructures and services. Disponível em Kim, K. H., Beloglazov, A., and Buyya, R. (2009). Power-aware provisioning of cloud resources for real-time services. Proceedings of the 7th International Workshop on Middleware for Grids, Clouds and e-science. Legrand, A., Marchal, L., and Casanova, H. (2003). Scheduling distributed applications: the simgrid simulation framework. Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid. Sulistio, A., Cibej, U., Venugopal, S., Robic, B., and Buyya, R. (2008). A toolkit for modelling and simulating data grids: an extension to gridsim. Wiley InterScience. Wickremasinghe, B., Calheiros, R. N., and Buyya, R. (2010). Cloudanalyst: A cloudsimbased visual modeller for analysing cloud computing environments and applications.

132 IX Workshop em Clouds, Grids e Aplicações 117 Estimando o Valor de uma Grade Entre Pares para a Execução de Aplicações do Tipo Saco de Tarefas Edigley Fraga, Francisco Brasileiro, Dalton Serey Universidade Federal de Campina Grande Departamento de Sistemas e Computação Laboratório de Sistemas Distribuídos Av. Aprígio Veloso, s/n, Bloco CO, Bodocongó , Campina Grande, PB Abstract. Desktop grids have been used as a low cost solution to execute highly parallel applications that require low QoS from the execution infrastructure (as known as Bag-of-Tasks or BoT). More recently Infrastructure as a Service (IaaS) Cloud Computing has emerged as an attractive alternative for the execution of BoT that offers both low cost and improved QoS control. In this work, we compare the performance and the value yielded by both types of infrastructure for the execution of typical e-sience BoT. Our results indicate that in typical scenarios in which there is not high contention, desktop grids can yield services of the same quality level as IaaS providers at much lower costs. In fact, to beat grids in such scenarios, IaaS prices should be reduced about 50% to 70%. Resumo. Grades de desktops têm sido usadas como solução de baixo custo para a execução de aplicações massivamente paralelas (BoT) desde os anos 90. Recentemente, a computação na nuvem, por meio da provisão de Infraestrutura como Serviço (IaaS), emergiu como alternativa atraente para a execução de aplicações BoT. Neste trabalho, comparamos, via simulação, os desempenhos obtidos nas duas infraestruturas ao serem utilizadas para a execução de aplicações BoT típicas de e-science. Os resultados indicam que, em cenários de baixa e média contenção, grades eferecem, a um custo inferior, serviços com desempenho similar ao obtido na IaaS. De fato, para superar as grades, os preços praticados em IaaS deveriam sofrer uma redução entre 50% e 70%. 1. Introdução O acesso a grandes quantidades de recursos computacionais tem impactado a forma como a ciência é conduzida em diversos campos de conhecimento. O uso intenso da computação para gerar e processar dados científicos, denominado de e-science, é possível porque boa parte das aplicações pode ser facilmente executada de forma paralela em diversos recursos computacionais, acelerando processos iterativos de geração e análise de dados. Aplicações dessa natureza são conhecidas como sacos de tarefas (ou BoT - do inglês bag-of-tasks) [Iosup and Epema 2011] em função de serem constituídas por uma grande quantidade de tarefas que podem ser executadas de forma independente, facilitando consideravelmente as atividades de escalonamento e tolerância a falhas. A característica mais importante dessas aplicações é a não-exigência de uma rígida garantia de

133 118 Anais qualidade de serviço por parte da plataforma de execução. Em teoria, qualquer equipamento dotado de um microprocessador é capaz de executar tarefas de uma aplicação BoT. Desde a década de 90, grades de desktops têm sido amplamente utilizadas para a execução de aplicações BoT. Em particular, se consolidaram como as plataformas mais populares para a execução de aplicações de e-science [UCB 2011a]. Tais infraestruturas se baseiam no aproveitamento oportunista de recursos, utilizando ciclos ociosos de máquinas desktops não dedicadas. Um dos primeiros representantes de grades dessa natureza foi o projeto Condor [Fields 1993]. Inspirados pelo sucesso das primeiras grades de desktops, plataformas de computação voluntária conseguiram agregar milhões de desktops de usuários domésticos espalhados por todos os continentes [UCB 2011b]. Mais recentemente, grades entre pares também têm sido implantadas e utilizadas para a execução de uma variedade de aplicações BoT [Araujo et al. 2005, Anglano et al. 2008]. Em meados da década passada, a computação na nuvem, na forma de provisão de Infraestrutura como Serviço (IaaS), emergiu como uma alternativa para a execução de aplicações BoT. Uma característica notável presente no paradigma da computação na nuvem é a elasticidade: capacidade de ser virtualmente e quase que instantaneamente expandida ou reduzida, sob demanda e controle direto do cliente [Armbrust et al. 2009]. Aliada ao baixo custo, tal propriedade o torna atraente para a execução de aplicações BoT. Até o presente momento tem sido difícil estimar o valor que uma grade de desktops oferece aos usuários de aplicações BoT. Em particular, a tarefa é especialmente difícil se quisermos usar métricas de negócio (valor monetário), visto que a receita financeira resultante da execução de aplicações de e-science é comumente indefinida. Neste trabalho, para atingir este objetivo, usamos uma abordagem comparativa entre os serviços providos por uma grade de desktops e uma plataforma de computação na nuvem. A ideia fundamental é usar os custos de execução na plataforma de computação na nuvem como a referência para estimar o valor proporcionado pela grade de desktops. A metodologia é baseada na simulação das duas plataformas de execução, sendo ambas submetidas a um mesmo workload (carga de aplicações BoT). Para cada plataforma simulada é realizada a medição do makespan (tempo entre a submissão e a conclusão) de cada aplicação executada. Para estimar o custo da execução, usamos o método de precificação e os preços praticados pelo Amazon Web Services, um dos principais provedores de IaaS do mercado. Também estimamos os limites do custo operacional extra em que incorrem os mantenedores de uma grade de desktops, de modo a verificar em que situações essa plataforma é mais vantajosa que a contratação de um provedor de IaaS. Os resultados mostram que, para a maior parte das configurações avaliadas, a grade de desktops se apresenta como a alternativa mais vantajosa. Em especial, quando a contenção não é muito alta, os preços praticados pelos provedores de IaaS teriam que cair entre 50% e 70% para que a grade de desktops deixasse de ser a melhor alternativa. 2. Contextualização Grade Entre Pares A participação em comunidades de grades entre pares permite às instituições e aos laboratórios participantes reduzir o chamado Custo Total de Propriedade. Em vez de adquirir novos recursos dedicados para satisfazer suas demandas computacionais, os laboratórios usam desktops já adquiridos para outros usos. Como o sistema se beneficia apenas de ciclos ociosos, o uso dos desktops se dá de forma não in-

134 IX Workshop em Clouds, Grids e Aplicações 119 trusiva, sem prejudicar os usuários locais. Além disto, por ser par da comunidade, o laboratório pode dispor dos ciclos ociosos dos demais pares. Isto implica a disponibilidade de um número de recursos computacionais muito maior do que seria possível obter individualmente. Em troca, o laboratório também disponibiliza seus ciclos ociosos para os demais pares da comunidade. Exemplos de middlewares bem sucedidos no suporte a grades oportunistas em larga escala incluem o projeto Condor [Epema et al. 1996] e o OurGrid 1 [Cirne et al. 2006], descrito brevemente a seguir. Na terminologia OurGrid, denomina-se de comunidade o conjunto de laboratórios participantes também chamados de sites ou peers, quando se quer enfatizar a natureza P2P (do inglês peer-to-peer) da plataforma. O OurGrid é baseado em uma política de livre-entrada, em que os laboratórios são estimulados a compartilhar seus recursos de maneira independente e no momento em que o desejarem, sem a necessidade de estabelecer acordos e/ou termos de compromisso prévios com a comunidade. Para desencorajar um comportamento egoísta por parte dos peers, a plataforma OurGrid prioriza o atendimento aos usuários de acordo com o histórico de doações. Esse mecanismo de incentivo é chamado de Rede-de-Favores (NoF, do inglês Network-of-Favors) [Andrade et al. 2007] e age de maneira autônoma, baseando-se unicamente na reciprocidade entre os pares. Amazon Elastic Compute Cloud O Amazon Elastic Compute Cloud (Amazon EC2) [EC2 2010] é um serviço web que provê um ambiente virtual de computação na nuvem. Suas principais características incluem elasticidade (possibilidade de aumento e redução da capacidade sob demanda), total controle das instâncias alocadas, flexibilidade (tipos variados de instâncias e sistemas operacionais), confiabilidade e segurança. Pelo modelo de negócio adotado, os usuários são cobrados apenas pelos recursos que efetivamente consomem, de forma semelhante a um mercado de computação utilitária [Ivanov 2009]. Atualmente, são praticados 3 modelos de precificação no Amazon EC2, denominados ondemand, reserved e spot. No primeiro, os usuários pagam pela hora de computação sem nenhum compromisso de longo prazo. No segundo, o usuário reserva os recursos computacionais por um prazo mais longo, mas paga um valor menor por hora, em comparação com o primeiro modelo. O terceiro modelo, denominado spot, é o que oferece os menores preços e consiste em uma espécie de leilão dos recursos computacionais que não foram negociados nos outros dois modelos. Por oferecer os menores preços sem comprometimento antecipado, o modelo spot foi o adotado para a comparação com a grade. Ao solicitar o serviço spot, o usuário especifica o tipo e a quantidade de instâncias que deseja alocar, bem como o preço máximo (lance), por hora, que está disposto a pagar. A Amazon mantém continuamente o valor mínimo (spot-price) de cada tipo de instância spot. Assim, se o lance for maior ou igual ao spot-price, a solicitação será atendida. As instâncias alocadas ficarão disponíveis para o usuário até que este termine seu uso ou até que o spot-price supere o lance (o que acontecer primeiro). É importante esclarecer que o preço cobrado pelas instâncias alocadas é o spot-price e não o valor do lance. Logo, o valor pago será sempre menor ou igual ao valor do lance. O valor spot-price é definido pelo Amazon EC2 e flutua periodicamente como função da oferta e da demanda de instâncias spot. Assim como nos outros dois modelos, horas parciais são cobradas como horas inteiras, a menos que ocorra uma preempção como decorrência do spot-price ter superado o valor do lance. Neste caso, não haverá cobrança por fração de hora de uso. 1 OurGrid,

135 120 Anais Tabela 1. Tipos de Instâncias Amazon EC2 Tipo 1 Mem 2 CPU 3 Núcleos CPU/Núcleo 3 Preço ($) 4 Spot Reserved OD 5 m1.small m1.large m1.xlarge c1.medium , c1.xlarge , m2.xlarge , m2.2xlarge , m2.4xlarge , Prefixos: m1 (Stantard), m2 (High-Memory) e c1 (High-CPU) Instances 2 Em Gigabytes 3 Em número de ECU - EC2 Computing Unit (aprox. 1,0 1,2 GHz) 4 Em Dólar Americano (USD), referente a dezembro de On-Demand Algumas restrições, contudo, existem. Cada usuário está limitado a 20 instâncias dos modelos on-demand e reserved e a um limite de 100 instâncias para o modelo spot. Para usar um número maior de instâncias, o usuário deve solicitar formalmente, explicando seu caso de uso, e o pedido poderá, ou não, ser aprovado 2. Há seis famílias de instâncias: Standard, Micro, High-Memory, High-CPU, Cluster Compute e Cluster GPU. Neste trabalho, focamos nosso interesse em três famílias: Standard (m1), High-Memory (m2), e High-CPU (c1). Instâncias m2 são indicadas para serviços com alto consumo de memória e instâncias c1 são indicadas para computação de alto desempenho. Detalhes de cada família são apresentados na Tabela 1. Na tabela, o acrônimo ECU (EC2 Computing Unit) representa uma unidade virtual de computação definida pelo EC2 que equivale a aproximadamente um processador de 1,0 1,2 GHz Modelo de Sistema Grade Entre Pares: Formalmente, definimos uma grade entre pares G como um conjunto de sites S i : G = {S 1, S 2,..., S n }, n > 1. Por sua vez, um site consiste em um conjunto de máquinas M i : S = {M 1, M 2,..., M n }, n > 0. Em um ambiente federado como o considerado neste estudo, há outros recursos compartilhados, tais como espaço de armazenamento, largura de banda e outros serviços de alto nível. No entanto, devido ao tipo de workload utilizado (BoT), a modelagem considerando apenas recursos computacionais já é satisfatória. Já as máquinas são modeladas como n-tuplas de processadores P i : M = (P 1, P 2,..., P n ), n > 0. Por fim, um processador é uma 1-tupla com o seu elemento unitário representando a capacidade computacional ν do processador: P = (ν), ν N +. Os conjuntos de recursos dos sites são disjuntos ( i,j, i j, S i S j = ). Como os recursos são utilizados de forma oportunista, as máquinas efetivamente disponíveis para a grade ao longo tempo representam um subconjunto do conjunto de máquinas dos sites. Nuvem de Instâncias Spot A plataforma de computação na nuvem C, ou nuvem de instâncias, é modelada por um conjunto de máquinas M e um limite L > 0 que indica o número de instâncias que podem ser alocadas por um 2 3 Amazon EC2 Computing Unit (ECU),

136 IX Workshop em Clouds, Grids e Aplicações 121 usuário. Um spot-price Π é modelado por um par instante de tempo e preço: Π = (t, π), t N, π R +. A oscilação O do spot-price é expressa como uma série de spot-prices: O = (Π 1, Π 2,..., Π n ), n 0 i,j, i < j, Π i1 < Π j1. Há, por fim, a necessidade de considerar os usuários do sistema, dado que o limite de elasticidade L é aplicado por usuário. O conjunto de usuários é Υ = (υ 1, υ 2,..., υ n ), n > Modelo de Workload Para formalizar o workload de aplicações BoT, adaptou-se a notação introduzida em [Iosup et al. 2007]. Nessa notação, um workload W é uma sequência de jobs 4, ordenada pelo tempo de submissão: W = {J 1, J 2,..., J n }, n > 0. Um job, por sua vez, consiste em um conjunto não vazio de tarefas: J = {T 1, T 2,..., T n }, n > 0, representando, cada uma, uma demanda computacional de τ unidades de tempo: T = (τ), τ N +. Utilizaremos, ainda, a seguinte notação para nos referirmos a propriedades de um job J: user(j), peer(j), makespan G (J), makespan C (J) e cost(j, i). As funções se referem, respectivamente, ao usuário que submeteu o job, ao peer ao qual o usuário pertence, aos makespans na grade e na nuvem e ao custo de execução, na nuvem, da i-ésima tarefa do job J. Com base nas funções definidas acima, definimos as seguintes macros para facilitar a referência a subconjuntos do workload W com base nos usuários: W u = {J J W user(j) = u}, W u 0; e peers de origem: W s = {J J W peer(j) = s}, W s Modelo de Simulação Para avaliar os modelos anteriormente apresentados, optou-se pelo uso de simulação baseada em eventos, implementada no OurSim 5, um simulador de grades entre pares implementado na linguagem Java e que também oferece suporte à simulação de grades oportunistas. Além disto, o OurSim também provê alguns ganchos, o que o tornou adequado para simular o modelo simplificado da nuvem de instâncias spot. Conforme apresentado na Seção 3, nas simulações não foram considerados fatores como rede (tráfego, latência, etc.) nem armazenamento (memória ou disco), visto que o foco são aplicações de computação intensiva. Cada simulação ocorre desde a submissão do primeiro job até o término do último, ínterim em que são gerados alternadamente intervalos de indisponibilidade e disponibilidade para cada máquina da grade. Grade Entre Pares: Foram utilizados componentes representando peers, que agregam, cada um, uma coleção de máquinas heterogêneas, não-dedicadas e voláteis. Em conjunto, os peers formam uma grade e a interação entre eles é contabilizada em um componente Rede-de-Favores. Há um componente JobScheduler, responsável por despachar tarefas para as máquinas e gerenciar uma fila de tarefas em cenários de contenção. A estratégia de escalonamento prioriza a alocação em máquinas locais. Caso os recursos locais não sejam suficientes, as demais tarefas serão submetidas para escalonamento remoto. Se, durante a tentativa de alocação dos recursos locais, houver alguma tarefa remota executando localmente e não houver mais recursos locais disponíveis, esta sofrerá uma preempção para dar preferência à demanda local, tal como é a política praticada em uma grade baseada no middleware OurGrid. Vale ressaltar que, nas simulações executa- 4 O termo job é utilizado como sinônimo de aplicação BoT 5 OurSim - OurGrid Simulator,

137 122 Anais Figura 1. Velocidade das Máquinas de um Site Ourgrid (50 máquinas) das, não foram considerados mecanismos de replicação ou de checkpointing. Diante de um evento de preempção, o JobScheduler apenas ressubmete a tarefa preemptada. Nuvem de Instâncias Spot: O principal componente é o escalonador de instâncias spot (SpotScheduler), responsável por registrar quantas instâncias cada usuário já alocou e, a partir do momento em que o limite tiver sido atingido, enfileirar as tarefas até que instâncias pertencentes ao mesmo usuário sejam liberadas. No caso de instâncias com vários núcleos, é alocada uma tarefa por núcleo. Também são contabilizadas as horas de alocação de cada instância, de forma a permitir o cálculo do custo total de execução. 4. Experimentos e Métricas para Análise 4.1. Parâmetros de Simulação Configuração dos Sistemas: Com o objetivo de analisar cenários envolvendo diferentes níveis de contenção na grade, a estratégia utilizada é de, para um mesmo workload, variar o número de máquinas presentes na grade como um todo. Para tanto, foram consideradas duas dimensões para aumentar o número de máquinas na grade: aumentar o número de máquinas que cada peer possui ou aumentar o número de peers na grade. Foi realizada uma varredura de parâmetros na faixa de 5 a 50 em cada dimensão, com passo de 5 unidades. Devido à restrição de espaço, são apresentados apenas os cenários em que G assume os valores em {10, 25, 50} e S em {10, 25, 35, 50}. Nas simulações, por simplicidade, com relação ao número de máquinas e também quanto à distribuição estatística da capacidade computacional das máquinas, os peers são considerados homogêneos. Para definir a distribuição estatística da capacidade computacional das máquinas, foi realizada uma análise em um site representativo da comunidade OurGrid. Esse site agrega cerca de 50 máquinas do tipo desktop, utilizadas por alunos de graduação e pósgraduação, além de funcionários do laboratório. A Figura 1 apresenta a distribuição da capacidade computacional das máquinas. Com esses dados, foi calculada uma função empírica de distribuição acumulada e a capacidade computacional de cada máquina simulada foi definida com base nesta função. Para o ambiente de nuvem de instâncias spot, foi considerado um limite L = 100, o mesmo praticado pelo serviço Amazon EC2. Para a oscilação dos spot-prices Π i, foram utilizados os históricos de preço informados pelo AWS, o que constrói toda a série temporal O, sendo uma para cada tipo de instância apresentada na Tabela 1. Cada histórico tem duração de pouco mais de 1 ano (desde dezembro de 2009, quando o serviço foi lançado) e a cada execução é escolhido aleatoriamente um instante do trace como instante inicial. Como usuários da nuvem Υ, aos quais é aplicado o limit L, são extraídos todos os usuários que submetem algum job para o sistema (J W user(j) Υ). Como o interesse do presente trabalho na infraestrutura de nuvem é verificar quanto o

138 IX Workshop em Clouds, Grids e Aplicações 123 Tabela 2. Distribuições do Workload e da Volatilidade das Máquinas 1 (a) Modelo de Iosup Usuário IAT 2 Ciclo Diário Tam. do Job ART 3 RTV 4 Z(1.31,368) W(4.25,7.86) W(1.79,24.16) W(1.76,2.11) N(2.73,6.1) W(2.05,12.25) (b) Tempo de Execução Ibercivis L(7.33,0.74) (c) Volatidade das Máquinas Disponibilidade Indisponibilidade L(7.95, 2.12) L(7.24, 1.04) 1 N, L, W, Z referem-se às distribuições Normal, Lognormal, Weibull e Zipf. O segundo parâmetro da Zipf é o número de usuários 2 Tempo entre chegadas (IAT: Inter-Arrival Time) 3 Tempo médio de execução (ART: average task runtime) 4 Variância do ART (RTV: Runtime Variability) limite L afeta o desempenho de aplicações BoT quando comparado com o desempenho na grade, foi considerado que os lances presentes em B são altos o suficiente para superar o spot-price no momento de submissão e até que a última tarefa do job seja concluída. Foram realizadas simulações para todas as instâncias presentes na Tabela 1, porém, em cada execução, o escalonamento é feito para apenas um tipo de instância, de forma que não são permitidas interações entre instâncias diferentes para a execução do workload. Padrão de Disponibilidade das Máquinas: Foi realizada uma análise do padrão de disponibilidade das máquinas da comunidade OurGrid, referente a um intervalo de 4 meses, originados de 4 sites (englobando em torno de 150 máquinas). O objetivo foi encontrar uma função de distribuição de probabilidades que representasse os dados referentes à duração dos intervalos de disponibilidade e de indisponibilidade. Inicialmente foram escolhidas as distribuições exponencial, normal, log-normal e Weibull, por serem comumente utilizadas para tal propósito e apresentarem baixa complexidade. Os valores dos parâmetros das distribuições foram estimados com base no método Estimação por Máxima Verossimilhança (MLE). Para determinar qual das distribuições candidatas melhor se adequava aos dados, foi realizado o teste de Goodness-of-Fit (GoF) baseado no método Kolmogorov-Smirnov (KS-test) para um nível de significância α = As distribuições escolhidas estão na Tabela 2(c). Workload dos Usuários: Foi realizada uma adaptação no modelo para BoT proposto em [Iosup et al. 2008b] e apresentado na Tabela 2(a). São consideradas as características inter-job (usuário de origem e padrão de chegada) e as intra-job (quantidade de tarefas e a distribuição estatística dos tempos de execução). Os aspectos inter-jobs são seguidos integralmente, no entanto, foi necessário realizar um tratamento adicional nos aspectos intra-job, de forma a adaptar os jobs gerados às características de grades oportunistas. Como o modelo original teve como base traces de grades de serviço (que utilizam recursos dedicados) as características intra-jobs diferenciam-se bastante de aplicações BoT típicas de grades oportunistas (jobs grandes e tarefas pequenas [Kondo et al. 2007]). Ao contrário de workloads de grades de serviço, que possuem repositórios de traces e que já foram estudados e caracterizados de forma abrangente [Iosup et al. 2008a], grades oportunistas ainda carecem de uma caracterização de seus workloads típicos e da disponibilização de uma quantidade razoável de traces reais, de modo a se obter tal caracterização. Para contornar essa carência, partiu-se da seguinte suposição: os jobs de grade de serviço podem ser quebrados de forma que o tempo de execução de suas tarefas alcancem um grão similar àqueles de jobs propícios de serem executados em grades oportunistas. Como consequência, obtêm-se tarefas menores e mais tarefas por job.

139 124 Anais Figura 2. Visão geral do workload (a) e do tempo de execução das tarefas (b) O segundo problema a ser atacado é como quebrar o job original. Para tanto, foi utilizado um trace da grade oportunista ibercivis 6, cuja distribuição estimada para o tempo de execução das tarefas se encontra na Tabela 2(b) e foi obtida seguindo a mesma metodologia utilizada para o caso do padrão de disponibilidade das máquinas. Então, para cada tempo de execução gerado a partir do modelo de Iosup, realiza-se a divisão de acordo com valores amostrados da distribuição da Tabela 2(b). A Figura 2(a) ilustra um exemplo de workload gerado, sendo possível perceber o padrão do ciclo diário de submissão. A Figura 2(b) mostra como os tempos de execução ficam estatisticamente distribuídos, como resultado das alterações descritas anteriormente. Ademais, todos os workloads gerados são referentes a um período de 7 dias Métricas de Comparação Em cada simulação, são registrados os makespans de cada job, tanto para a execução na grade quanto na nuvem. No caso da nuvem, também é computado o custo de execução de cada job. Como os peers participantes da grade possuem, cada um, workloads heterogêneos, assim como os jobs são bem diferentes um do outro (um pode ter 10 tarefas enquanto um outro 1.000, por exemplo), se faz necessária uma métrica de desempenho que normalize a variação de demanda entre diferentes peers e jobs, de forma que seja possível comparar os desempenhos obtidos nas diferentes plataformas. Para tanto, é utilizada a razão entre a agregação dos makespans nas duas plataformas, denominada D s, e calculada para cada peer s: D s = P W s j=1 makespanc (W s j ) P W s j=1 makespang (W s j ) Também é calculada a média para essa métrica (D), de tal forma a representar o bem-estar geral que a grade oferece a seus participantes: D = 1 S S s=1 Ds. Ambas as métricas (D s e D), tratadas simplesmente como D, flutuam em torno de uma linha de indiferença (y = 1). A métrica D deve ser interpretada com base nesta linha, 6 Plataforma de Computação Cidadã,

140 IX Workshop em Clouds, Grids e Aplicações 125 Figura 3. Desempenho Grade Vs. Instâncias spot resultando em três casos que guiam a decisão a respeito de qual plataforma fornece, no geral, o melhor desempenho: C, se D < 1; G, se D > 1. Quando D = 1, outro critério deve ser utilizado para o desempate. Também se utiliza o custo médio por tarefa (ACT ), permitindo a comparação de custo de execução em diferentes tipos de instâncias spot: ACT = 1 P W j=1 W j W j=1 5. Resultados e Discussão Wj t=1 cost(w j, t) Para cada combinação da variação dos fatores ( G, S e tipo de instância spot), foram realizadas 30 simulações, de acordo com a configuração estatística da Seção 4, e os valores nos gráficos estão em um intervalo de confiança de 95%, com erro máximo de 5%. A Figura 3 apresenta os resultados da execução de um mesmo workload tanto em uma grade entre pares quanto na nuvem de instâncias spot. Os pontos do gráfico são referentes à comparação com três tipos de instâncias spot (m1.small, c1.medium e m2.4xlarge). Estas instâncias são representativas, pois ilustram os dois extremos e também um valor intermediário para a comparação. Como esperado, ao passo em que o tamanho da grade aumenta, e consequentemente diminui a contenção do sistema, a métrica D se estabiliza acima da linha de indiferença para a instância m1.small e um pouco abaixo para a instância m2.4xlarge. Por sua vez, a instância c1.medium apresenta desempenho muito parecido com o da grade para os cenários em que a contenção não é muito alta. O péssimo resultado apresentado pela instância m1.small é explicado pela baixa capacidade computacional de tais instâncias quando comparadas com os desktops típicos da grade, visto que contam com apenas 1 ECU (vide Tabela 1 e Figura 1). No outro

141 126 Anais Figura 4. Makespan e Custo para as instância spot extremo, o bom resultado apresentado pela instância m2.4xlarge se explica por sua maior capacidade de computação (3.25 ECU) e, de forma mais importante, pelos 8 núcleos disponíveis por instância, o que diminui o efeito negativo do limite L de 100 máquinas. É apresentada, na Figura 4, a contrapartida financeira que o usuário precisa realizar para obter o desempenho presente na Figura 3. De imediato, observa-se que a instância m1.small não é uma boa opção, visto que, embora apresente um custo por tarefa competitivo, apresenta um desempenho sofrível. Já a instância m2.4xlarge, como visto anteriomente, apresenta o melhor desempenho, no entanto, é a solução mais cara. Mais uma vez, destaca-se a instância c1.medium, pois apresenta um desempenho aproximadamente 40% inferior em relação à instância m2.4xlarge, mas, em compensação, obteve o menor custo por tarefa, 5 vezes inferior ao obtido na m2.4xlarge. As instâncias m2.xlarge e c1.xlarge apresentam bom desempenho, mas custam, aproximadamente, 150% e 90% a mais que a c1.medium, por um desempenho apenas 25% superior. Portanto, a instância c1.medium é a melhor opção para servir de referência para estimar o valor de uma grade P2P visto que: 1. os desempenhos apresentados são parecidos (D próxima à linha de indiferença) e 2. representa a solução mais barata (não superestima o valor da grade). Para estimar o valor da grade (V g ), será utilizada a Relação 1, para a qual M g e M c são a soma dos makespans dos jobs quando executados na grade e na nuvem, respectivamente, e C c o custo total de execução de W na nuvem. A relação se baseia na ideia intuitiva de que quão menor o makespan obtido em uma plataforma, maior será o valor desta para o usuário, ou seja, o valor é inversamente proporcional ao makespan. Com o objetivo de estimar monetariamente o valor da grade, recorre-se ao aspecto custo de execução na nuvem, visto que esse custo se refere à execução do mesmo workload. A relação de proporcionalidade entre o valor da grade e o custo de execução na nuvem é, intuitivamente, direta. Por último, resta ponderar o papel desempenhado pelo makespan

142 IX Workshop em Clouds, Grids e Aplicações 127 Tabela 3. Consumo de energia (em Watts) do Processador c t c o c s Athlon Athlon XP Athlon XP Athlon Athlon 64 FX Processador c t c o c s Pentium 4 2,40C GHz Pentium 4 3,40C GHz Pentium 4 EE 3,40 GHz Pentium 4 2,80 GHz Pentium 4 3,40E GHz c t Consumo em carga total do c o Consumo do sistema quando ocioso c s Sobrecarga de consumo (c t c o ) obtido na nuvem para essa estimativa de valor da grade. Caso os makespans na nuvem e na grade fossem idênticos, bastaria-nos mapear diretamente o valor da grade para o custo de execução na nuvem. Como não é esse o caso, é suficiente perceber que o valor da grade depende da relação entre os makespans obtidos na grade e na nuvem. V g = M c M g C c (1) Para o cenário com 50 peers, cada um dispondo de 25 máquinas, tem-se: V g = = 1.697, 42 USD Para verificar a efetividade do valor da grade, deve-se considerar, também, o seu custo de manutenção. Para ser, de fato, uma solução efetiva, deve-se ter: V g > C g (2) Nas grades oportunistas, em que os recursos não são adquiridos tendo a grade em mente, a ideia de custo não se dá de forma direta, tais como em outras plataformas [Opitz et al. 2008]. Na prática, a principal preocupação em relação ao custo extra reside no consumo de energia, visto que, se não fosse a grade, a máquina seria, após o uso, solenemente desligada pelo usuário local. Deste modo, para estimar o custo da grade, serão considerados os gastos extras com eletricidade. Para uma análise que se aproxime da realidade, dois referenciais de consumo devem ser considerados: um para os períodos de completa ociosidade e outro para operação em carga máxima. A Tabela 3 apresenta valores referentes a vários sistemas submetidos à execução do Devem ser consideradas duas situações para o crédito de consumo à grade: (i) - quando o recurso está sendo utilizado apenas pela grade (p. ex, nos períodos noturnos) e (ii) - quando se utiliza o recurso nos pequenos intervalos em que o usuário local deixa temporariamente de utilizar sua máquina. No primeiro caso, todo o consumo deve ser creditado à grade, enquanto, no segundo, apenas a diferença entre os consumos em carga total e em ociosidade devem ser creditados (supondo que o sistema não seria desligado nesses intervalos). Assim, para realizar a estimativa de custo extra introduzido pela grade, basta multiplicar o consumo estimado pelo preço de 1 kwh. Para evitar problemas com conversão de moeda, será considerado o custo médio de 5 centavos de dólar, por kwh, cobrado de instituição educacionais nos Estados Unidos [Kondo et al. 2009]. Após todas as considerações, chega-se ao modelo simplificado C g para o cálculo do custo extra com energia durante d dias, para o caso de máquinas e sites homogêneos.

143 128 Anais Devido à situação (ii) k C g = d np nm { { }} { h r u c s Devido à situação (i) { }} { (24 h) [u c t + (1 u) c o ]} } {{ } Consumo diário por máquina (em Watts) No modelo, np é o número de peers e nm o número de máquinas por peer; c s, c t e c o denotam, respectivamente, os consumos de sobrecarga, total e de ociosidade da máquina homogênea (vide Tabela 3), k é o preço de 1 kwh, r é a taxa de ociosidade das máquinas em horário normal de trabalho (h horas por dia) e u é a utilização do sistema. Consultando a Tabela 3, pode-se perceber dois extremos de consumo de energia, com uma máquina mais eficiente (c t min = 115, c s min = 38 e c o min = 77) do ponto de vista energético e uma extremamente ineficiente (c t max = 198, c s max = 78 e c o max = 120). Dessa forma, aplicando o modelo C g podemos encontrar dois valores limites, Cg min e Cg max, para a estimativa de custo. Assumindo que os recursos são utilizados durante um total de 10 horas diárias por seus usuários locais (h = 10), considerando que a taxa de utilização para np = 50 e nm = 25 é de 17,5% (u = 0, 175), que a ociosidade das máquinas em horário comercial é de cerca de 70% (r = 0, 7) [Kondo et al. 2007], k = 0, 05 USD e sabendo que o workload cobre um período de 7 dias (d = 7), instanciando C g para os dois extremos, temos: C min g = 532, 7219 USD e C max g = 860, 4094 USD. Como se obteve V g = 1.697, 42, maior que Cg max, conclui-se, considerando todas as simplificações e aproximações, que a grade em questão é uma solução de baixo custo para a execução de aplicações BoT. A Tabela 4 resume as considerações para todas as instâncias de grades analisadas. Os valores estão ordenados de acordo com a última coluna, que representa a efetividade da grade como solução de baixo custo no pior caso. A métrica percentual V eff g (V eff g = Vg Cg V g ) indica quanto e como o valor da grade se comporta em relação ao custo de manutenção. Um valor de 100% indicaria um cenário de execução sem custo, enquanto um valor negativo indica um custo superior ao valor obtido. Vale destacar dois casos extremos que resultam em um baixo valor efetivo: 1. quando np = 10 e nm = 10, devido a um desempenho ruim (makespans muito longos em função da altíssima contenção), embora tenha um baixo custo de manutenção. 2. quando np = 50 e nm = 50, devido a uma sub-utilização das máquinas, que permanecem ociosas (desperdiçando energia) a maior parte do tempo, embora apresente um alto valor para V g. Vg eff também pode ser utilizada para indicar em quanto porcento o preço praticado pela Amazon deveria ser reduzido para que a grade não fosse a melhor opção ou, de outra forma, quão mais potente deveria ser a instância c1.medium. Em particular, para as últimas 6 configurações, observa-se que a margem vai, aproximadamente, de 50% a 70%. 6. Trabalhos Relacionados Em [Kondo et al. 2009] os autores analisam o custo-benefício da computação na nuvem e de grades de desktops baseadas em computação voluntária, destacando os trade-offs de desempenho entre as duas plataformas. O trabalho apresentado em [Oprescu and Kielmann 2010] envolve o escalonamento com restrição de orçamento para aplicações BoT em múltiplos provedores de IaaS com diferentes desempenho de CPU e custo, de forma a minimizar o tempo de término enquanto respeita o valor máximo a ser gasto. O foco principal em [Yi et al. 2010] é a investigação de como checkpointing pode ser utilizado para reduzir custos de execução de aplicações na nuvem spot e, ainda assim, manter alta confiabilidade. Por sua vez, em [Andrzejak et al. 2010] é proposto um modelo

144 IX Workshop em Clouds, Grids e Aplicações 129 Tabela 4. Considerações de Custo das Duas Opções de Execução np nm C g (USD) Vg eff (%) V g (USD) min max max min ,58 115,96 14,84-341,91-681, ,55 254,21 268,99 45,52 5, , , ,67 43,39 10, ,67 262,66 334,10 54,90 21, , , ,46 58,84 34, ,72 860, ,42 68,62 49, ,20 836, ,85 69,14 50, ,75 322,18 758,40 75,11 57, ,97 618, ,13 75,95 60, ,66 473, ,90 79,38 66, ,07 409, ,01 80,28 67, ,24 420, ,87 80,57 67,36 probabilístico para otimização de custo, desempenho e confiabilidade para a execução de aplicações BoT sobre a nuvem spot. De acordo com o levantamento bibliográfico realizado, não há nenhum trabalho que considere os efeitos do limite real na elasticidade da nuvem e a consequente implicação no aumento do makespan de aplicações BoT, fator que coloca as grades oportunistas como opções adequadas para a execução de tais aplicações. 7. Conclusão e Trabalhos Futuros Os resultados de simulação mostram que, devido ao limite real na elasticidade oferecida pelo provedor de IaaS, mesmo para grades relativamente pequenas e para os cenários em que a contenção de recursos não é muito alta, uma grade entre pares se mostra uma alternativa mais vantajosa, considerando as métricas custo e makespan. A essência do resultado apresentado está, com relação ao custo, na característica oportunista da grade, e, quanto ao desempenho, na impossibilidade dos atuais provedores de IaaS de oferecer elasticidade ilimitada para todos os usuários que simultaneamente solicitam seus serviços. Como trabalho futuro, pretende-se melhorar as estimativas de custo de manutenção de grade entre pares, ao adicionar outros fatores que influenciam no custo, a exemplo do impacto do aumento de utilização na vida útil dos equipamentos. Também, pretende-se utilizar técnicas mais sofisticadas para o escalonamento de tarefas na nuvem, de forma a permitir uma redução no custo de execução. Referências Andrade, N., Brasileiro, F. V., Cirne, W., and Mowbray, M. (2007). Automatic Grid Assembly by Promoting Collaboration in Peer-to-Peer Grids. Jour. of Par. and Dist. Computing, 67: Andrzejak, A., Kondo, D., and Yi, S. (2010). Decision Model for Cloud Computing under SLA Constraints. In Modeling, Analysis Simulation of Computer and Telecommunication Systems (MASCOTS), 2010 IEEE International Symposium on, pages Anglano, C., Canonico, M., Guazzone, M., Botta, M., Rabellino, S., Arena, S., and Girardi, G. (2008). Peer-to-Peer Desktop Grids in the Real World: The ShareGrid Project. Cluster Computing and the Grid, IEEE International Symposium on, 0:

145 130 Anais Araujo, E., Cirne, W., Wagner, G., Oliveira, N., Souza, E. P., Galvao, C. O., and Martins, E. S. (2005). The SegHidro Experience: Using the Grid to Empower a Hydro-Meteorological Scientific Network. In First Int. Conf. on e-science and Grid Computing. IEEE Computer Society. Armbrust, M., Fox, A., and Griffith, R. (2009). Above the Clouds: A Berkeley View of Cloud Computing, Tech. Rep. EECS , EECS Dept, Univ. of California, Berkeley. Cirne, W., Brasileiro, F., Andrade, N., Costa, L., Andrade, A., Novaes, R., and Mowbray, M. (2006). Labs of the World, Unite!!! Journal of Grid Computing, 4(3): EC2, A. (2010). Amazon Elastic Compute Cloud (Amazon EC2), Epema, D. H. J., Livny, M., van Dantzig, R., Evers, X., and Pruyne, J. (1996). A Worldwide Flock of Condors: Load Sharing among Workstation Clusters. Future Gener. Comput. Syst., 12. Fields, S. (1993). Hunting for Wasted Computing Power, 1993 Research Sampler, University of Wisconsin-Madison, Iosup, A. and Epema, D. (2011). Grid Computing Workloads: Bags of Tasks, Workflows, Pilots, and Others. IEEE Internet Computing, 15: Iosup, A., Li, H., Jan, M., Anoep, S., Dumitrescu, C., Wolters, L., and Epema, D. (2008a). The Grid Workloads Archive. Future Generation Computer Systems, 24(7): Iosup, A., Sonmez, O., Anoep, S., and Epema, D. (2008b). The Performance of Bags-of-Tasks in Large-scale Distributed Systems. In Proceedings of the 17th Int. Symp. on High Performance Distributed Computing, HPDC 08, pages , New York, NY, USA. ACM. Iosup, R., Jan, M., Sonmez, O., and Epema, D. (2007). The Characteristics and Performance of Groups of Jobs in Grids. In In Euro-Par, volume 4641 of LNCS. Springer-Verlag. Ivanov, I. I. (2009). Utility Computing: Reality and Beyond. In Filipe, J. and Obaidat, M. S., editors, E-business and Telecommunications, volume 23 of Communications in Computer and Information Science, pages Springer Berlin Heidelberg / Kondo, D., Fedak, G., Cappello, F., Chien, A. A., and Casanova, H. (2007). Characterizing Resource Availability in Enterprise Desktop Grids. Future Gener. Comput. Syst., 23: Kondo, D., Javadi, B., Malecot, P., Cappello, F., and Anderson, D. (2009). Cost-Benefit Analysis of Cloud Computing Versus Desktop Grids. In Parallel Distributed Processing, IPDPS IEEE International Symposium on, pages Opitz, A., König, H., and Szamlewska, S. (2008). What Does Grid Computing Cost? Journal of Grid Computing, 6: /s Oprescu, A. M. and Kielmann, T. (2010). Bag-of-Tasks Scheduling under Time and Budget Constraints. IEEE Int. Conf. and Workshops on Cloud Comp. Tech. and Science (CloudCom 2010). UCB (2011a). BOINC Statistics, UCB (2011b). University of Berkeley, California, Yi, S., Kondo, D., and Andrzejak, A. (2010). Reducing Costs of Spot Instances via Checkpointing in the Amazon Elastic Compute Cloud. In Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, CLOUD 10. IEEE Computer Society.

146 IX Workshop em Clouds, Grids e Aplicações Sessão Técnica 4 Gerência e QoS

147

148 IX Workshop em Clouds, Grids e Aplicações 133 Sistemas de Armazenamento Compartilhado com Qualidade de Serviço e Alto Desempenho Pedro Eugênio Rocha, Luis Carlos Erpen de Bona Departamento de Informática Universidade Federal do Paraná (UFPR) Caixa Postal CEP Curitiba PR Brazil Abstract. Shared storage systems must provide performance isolation so that QoS guarantees are not affected by concurrent applications. This paper proposes a new non-work-conserving disk scheduling algorithm called HTBS, which is based on BFQ and pclock. HTBS merges these algorithms in order to provide QoS guarantees without decreasing the system overall performance. We show through experiments that HTBS can provide both highthroughput and QoS guarantees to applications with different requirements. Resumo. Servidores de armazenamento compartilhado devem possuir mecanismos que forneçam isolamento de performance, de modo que as garantias de QoS não sejam influenciadas por aplicações concorrentes. Este trabalho propõe um novo algoritmo de escalonamento de disco nãoconservativo, chamado HTBS, baseado nos algoritmos BFQ e pclock. O HTBS utiliza partes destes algoritmos com o objetivo de fornecer garantias de QoS, sem que a performance do disco seja degradada. Mostramos através de experimentos que o HTBS pode atender aplicações com requisitos variados e ao mesmo tempo fornecer alto desempenho. 1. Introdução A centralização da capacidade de armazenamento em servidores dedicados é um paradigma cada vez mais utilizado no gerenciamento de dados organizacionais. Dentre os diversos benefícios trazidos por essa centralização estão a redução de custos e complexidade de manutenção, utilização otimizada do recurso, simplificação no gerenciamento e em políticas de backup e flexibilidade para a alocação de espaço de armazenamento. Diante deste paradigma e da popularização da computação em nuvens, algumas empresas (como Amazon [Amazon EC2 2011] e Google [Google 2011]) criaram serviços para terceirização da administração desses servidores de armazenamento serviços conhecidos como Storage as a Service. Por ser fortemente baseada em virtualização, a computação em nuvens também aumentou a necessidade por mecanismos que possibilitem a criação de infraestruturas de armazenamento virtualizadas. Para que esta centralização seja viável, é desejável que o servidor de armazenamento possa garantir atributos de QoS aos seus usuários, definidos em documentos chamados SLA's (Service Level Agreements) [Vaquero et al. 2009], que especifiquem e mensurem as garantias fornecidas. Tais atributos são baseados em

149 134 Anais conceitos de Qualidade de Serviço ou QoS, como largura de banda, latência e rajadas. O sistema de armazenamento deve também prover isolamento de performance [Seelam e Teller 2006], ou seja, garantir que o desempenho percebido por um usuário não seja influenciado por aplicações concorrentes. A maioria dos sistemas de armazenamento atuais são baseados em discos rígidos, ainda que camadas intermediárias, como RAID (Redundant Array of Independent Disks) ou LVM (Logical Volume Manager) [LVM 2011], sejam utilizadas. Neste tipo de dispositivo é difícil fornecer garantias de QoS, pois o tempo necessário para atender requisições de leitura ou escrita é altamente variável, dependendo de fatores como seek time, latência de rotação, posição dos dados na superfície do disco e caches [Jian et al. 2009]. A ordem em que as requisições são executadas também tem grande impacto no desempenho do dispositivo. Ainda assim, podem existir diversas aplicações com características e requisitos de QoS variados competindo pela utilização do disco. Outro problema enfrentado por este tipo de dispositivo, é o fato de que grande parte das aplicações cria apenas uma requisição por vez, de forma que a criação de uma próxima requisição dependa do término da anterior [Valente e Checconi 2010]. Estas requisições são conhecidas como síncronas. Escalonadores baseados em timestamps ou tags [Gulati et al. 2007], em geral selecionam a próxima requisição a ser atendida com base no tempo de chegada, que pode ser afetado pelo atraso no atendimento da requisição anterior. Assim, o atraso no atendimento de uma requisição de uma aplicação pode causar atraso em todas as requisições seguintes, prejudicando as garantias fornecidas. Como há relação de dependência entre requisições síncronas de uma mesma aplicação, existe um curto intervalo de tempo entre o término do atendimento de uma requisição e a criação da próxima, durante o qual a aplicação é dita deceptive idle [Iyer 2003], ou enganosamente ociosa. Neste intervalo, como ainda não há novas requisições pendentes da mesma aplicação, um algoritmo de escalonamento conservativo serviria outras aplicações, e assim sucessivamente. Este comportamento, conhecido como deceptive idleness, prejudica o desempenho do disco por não executar requisições com a localidade inerente a requisições de uma mesma aplicação. Neste trabalho é proposto um novo algoritmo de escalonamento de disco chamado HTBS (High-throughput Token Bucket Scheduler), baseado em dois algoritmos propostos anteriormente: BFQ (Budget Fair Queueing) [Valente e Checconi 2010] e pclock [Gulati el at. 2007]. O HTBS tem o objetivo de fornecer garantias de QoS, causando o menor impacto possível no desempenho do disco. O algoritmo pclock é utilizado pois provê bom isolamento de performance (como mostrado em [Gulati et al. 2007]), além da possibilidade de ajustar os parâmetros largura de banda, rajadas e latência de forma independente. Apesar disso, mostramos através de experimentos que o algoritmo pclock falha em fornecer as garantias na presença de requisições síncronas. O algoritmo proposto incorpora os mecanismos para tratar requisições síncronas e prevenir a ocorrência de deceptive idleness presentes no algoritmo BFQ, que, por sua vez, não permite a configuração dos atributos largura de banda e latência de forma individual. O algoritmo HTBS foi implementado como um módulo para o Kernel Linux

150 IX Workshop em Clouds, Grids e Aplicações 135 [Linux 2011], e experimentos foram realizados utilizando a ferramenta de benchmark de disco fio [Axboe 2011]. Através dos testes realizados, mostramos que o algoritmo HTBS aumenta o desempenho geral do disco na presença de aplicações que utilizem requisições síncronas e sequenciais, se comparado ao algoritmo pclock, provendo isolamento de performance e sem degradar de maneira significativa a latência das requisições. Mostramos também que o HTBS fornece desempenho próximo ao BFQ que possui mecanismos para prevenção de deceptive idleness, mas não possibilita a configuração dos atributos largura de banda e latência de forma explícita e individual. O restante do artigo está organizado da seguinte forma. A Seção 2 apresenta uma visão geral do problema tratado por este trabalho, bem como definições que serão utilizadas no decorrer do artigo. Na Seção 3 são descritos os trabalhos relacionados. O funcionamento do algoritmo HTBS e seus parâmetros são detalhados na Seção 4, enquanto a Seção 5 apresenta os resultados obtidos através de experimentos. Finalmente, a Seção 6 conclui este trabalho. 2. Visão Geral O objetivo deste trabalho é definir um novo algoritmo de escalonamento que garanta tanto isolamento de performance como alto desempenho. Assumimos neste trabalho que um sistema de armazenamento compartilhado é composto por três entidades, ilustradas na Figura 1: 1) um disco, capaz de atender requisições de leitura e escrita a um ou mais blocos de armazenamento contíguos, chamados setores; 2) um escalonador de requisições; e 3) n filas de requisições, referentes às n aplicações competindo pelo sistema. Aplicações são quaisquer entidades que possam utilizar o disco, como processos, grupos de processos, usuários, grupos de usuários, threads ou máquinas virtuais. Do ponto de vista do escalonador, o disco é composto por uma grande e única sequência de setores, numerados de forma crescente. Figura 1: Modelagem do sistema. Como definido em [Gulati et al. 2007], uma reserva de disco é composta por uma das n filas e seus três atributos de desempenho, σ i, ρ i e δ i, sendo σ i o tamanho máximo de rajadas, ρ i a largura de banda e δ i o limite máximo de latência da i-ésima reserva. O backlog de uma reserva i, representado por B i, é o número de requisições pendentes, ou seja, requisições aguardando atendimento. Uma reserva i está backlogged

151 136 Anais se B i > 0. É denominada ativa a reserva que atualmente está sendo servida pelo disco. No restante deste trabalho, assumimos que os termos reserva, aplicação e fluxo se referem à definição de reserva discutida neste parágrafo. Duas requisições são ditas sequenciais se a posição do final de uma requisição é adjacente ao início da próxima; caso contrário elas são denominadas não-sequenciais ou aleatórias. Caso a emissão de uma requisição dependa do término da anterior, elas são denominadas síncronas. Da mesma forma, requisições assíncronas não possuem relações de dependência. De acordo com [Valente e Checconi 2010], definimos T wait como o tempo máximo que o escalonador aguardará ociosamente por nova requisição síncrona e sequencial de uma mesma reserva. Por último, B max limita o número de requisições síncronas consecutivas que podem ser servidas a uma reserva. Um escalonador que nunca desperdice capacidade, ou seja, nunca mantenha o disco ocioso enquanto houver requisições pendentes, é dito conservativo, ou workconserving. Entretanto, como é mostrado em [Iyer 2003], há casos em que aguardar a requisição seguinte de uma aplicação, desde que síncrona e sequencial, pode aumentar o desempenho total do sistema de armazenamento. Neste caso, como o disco permanece ocioso por um breve intervalo de tempo aguardando novas requisições, estes escalonadores são ditos não-conservativos, ou non-work-conserving. Embora paradoxal, manter o disco ocioso por curtos intervalos de tempo pode aumentar significativamente o desempenho em alguns casos. Isto ocorre porque a maioria das aplicações atuais utilizam requisições síncronas intercaladas com pequenas quantidades de processamento, como, por exemplo, alocação ou liberação de memória, processamento dos dados obtidos ou atualização de variáveis de controle [Valente e Checconi 2010]. Caso não haja uma nova requisição imediatamente após o término da anterior, um escalonador conservativo passará a atender uma nova aplicação. Essa constante troca de atendimento entre aplicações é prejudicial ao desempenho do disco, porque ocasiona seek time e latência de rotação em excesso, devido à falta de localidade no acesso. Esta perda de desempenho é denominada deceptively idleness (ociosidade enganosa) [Iyer 2003], e uma aplicação que se encontre neste tempo entre requisições é dita deceptively idle (enganosamente ociosa). Escalonadores não-conservativos podem manter o disco ocioso por um curto intervalo de tempo após o término de uma requisição, com o objetivo de aguardar o processamento da aplicação e a chegada de uma nova requisição. Caso uma nova requisição seja criada neste intervalo de tempo, ela será atendida imediatamente; caso contrário, a aplicação poderá perder o direito de manter o disco em estado ocioso. 3. Trabalhos Relacionados A abordagem atualmente mais utilizada para fornecer qualidade de serviço no acesso a disco é o desenvolvimento de novos algoritmos de escalonamento. Os trabalhos realizados nesta área podem ser classificados em dois principais grupos: 1) escalonadores de tempo real e 2) escalonadores baseados em algoritmos de enfileiramento justo (fair queueuing). Os escalonadores de tempo real atribuem um deadline para cada requisição, reorganizando-as em função deste atributo. Em geral as requisições são atendidas de

152 IX Workshop em Clouds, Grids e Aplicações 137 acordo com o seu deadline, priorizando as que possuem o deadline mais próximo. A partir deste esquema, também chamado de EDF, ou Earliest Deadline First, foram desenvolvidas diversas variações, visando reduzir o seek-time e a latência de rotação. Alguns exemplos de escalonadores de disco de tempo real são PSCAN, FD-SCAN e SCAN-EDF [Reddy 2005]. Apesar de garantir deadlines para as requisições, estes algoritmos não têm mecanismos para limitar a largura de banda utilizada pelas aplicações ou possuem suporte a rajadas. Algoritmos de enfileiramento justo foram utilizados inicialmente no contexto de redes de computadores, com o objetivo de alocar de forma justa a capacidade de um canal de comunicação compartilhado entre diversos fluxos de dados [Tanenbaum 2002]. Exemplos destes algoritmos são: WFQ, WF 2 Q e WF 2 Q+ [Bennett e Zhang 1997]. Nos escalonadores de disco baseados nesta classe de algoritmos, são atribuídas tags ou timestamps a todas as requisições, baseados em tempo real ou tempo virtual. As requisições são atendidas de acordo com seus timestamps, proporcionando boa distribuição da banda disponível. Alguns exemplos destes algoritmos são YFQ [Bruno et al. 1999], EYFQ, BFQ e pclock. Este trabalho é baseado em dois algoritmos de escalonamento baseados em enfileiramento justo, BFQ e pclock, descritos em detalhes nas subseções seguintes Budget Fair Queueing O BFQ [Valente e Checconi, 2010], ou Budget Fair Queueing, é um escalonador baseado em algoritmos de enfileiramento justo, que possibilita a alocação de uma fração da capacidade do disco a cada aplicação, proporcional ao seu peso. Quando enfileiradas, as aplicações recebem determinada quantidade de budgets, que representa a quantidade de setores de disco que elas poderão transferir. Essa disciplina de alocação de recursos também é conhecida como Token Bucket, ou balde de símbolos [Tanenbaum 2002]. Uma vez selecionada, uma aplicação terá acesso exclusivo ao disco, até que se esgotem seus budgets ou esvazie seu backlog. Em seguida, uma nova aplicação será escolhida de acordo com o algoritmo de enfileiramento justo chamado Budget-WF 2 Q+, ou BWF 2 Q+, uma extensão do algoritmo WF 2 Q+. Para evitar a ocorrência de inanição, existe um limite máximo e configurável de budgets que uma aplicação pode armazenar, representado por B max. Diferentemente de outros escalonadores, o BFQ pode atender requisições de uma mesma aplicação em lotes, cujo tamanho é igual ao número de budgets da aplicação em determinado instante. Este esquema aumenta o desempenho do disco, devido à localidade do acesso e possibilita o agrupamento de requisições. Contudo, esse comportamento só é possível em aplicações que utilizem requisições assíncronas. No BFQ o disco é mantido ocioso por um pequeno instante após o atendimento de requisições síncronas, evitando a ocorrência de deceptively idleness. Por este motivo, ele é classificado como um algoritmo não-conservativo. Essa otimização, presente também nos algoritmos Anticipatory [Iyer 2001] e CFQ [Axboe 2007], garante boa utilização da capacidade do disco, visto que a maioria dos acessos a disco é feita de forma sequencial e síncrona [Valente e Checconi, 2010]. Entretanto, assim como em outros escalonadores baseados em algoritmos de

153 138 Anais enfileiramento justo, no BFQ não é possível configurar a largura de banda e latência de forma independente, nem o suporte a rajadas pclock O pclock [Gulati et al. 2003] é um algoritmo de escalonamento baseado em curvas de chegada, ou arrival curves. Tais curvas são definidas através de três atributos: largura de banda, latência e rajadas, que controlam os parâmetros do Token Bucket de cada aplicação e as tags atribuídas às requisições. O atendimento das aplicações é realizado através de uma espécie de EDF, servindo requisições de acordo com seus deadlines, ou finish tags. Por ser um escalonador conservativo, o pclock aloca a banda ociosa entre aplicações, e não as penaliza pela utilização adicional do disco. A banda ociosa também pode ser alocada a aplicações em background, conhecidas como aplicações best-effort. É provado que aplicações que cumpram suas curvas de chegada, ou seja, não excedam os limites preestabelecidos, nunca perderão seus deadlines, independentemente dos padrões de acesso de outras aplicações. Para que seja possível atender os requisitos de desempenho de todas as aplicações, o pclock define matematicamente um limite mínimo de capacidade que o sistema de armazenamento deve possuir. Entretanto, é muito difícil estimar a capacidade real de um disco, pois esta depende de inúmeros parâmetros, como o padrão de acesso, localidade e até posição dos dados na superfície do disco [Bruno et al. 1999]. Como no algoritmo pclock o atendimento das requisições é baseado exclusivamente no deadline, o algoritmo não se beneficia da localidade das requisições, o que pode resultar na subutilização da capacidade do disco. Ainda, como o algoritmo é conservativo, pode haver deceptive idleness na presença de requisições sequenciais e síncronas. 4. Solução Proposta Este trabalho propõe o HTBS, um novo algoritmo de escalonamento baseado nos algoritmos BFQ e pclock, descritos nas subseções 3.1 e 3.2, respectivamente. O objetivo é utilizar partes destes algoritmos para fornecer garantias de QoS, causando o menor impacto possível na performance do disco. Tomamos inicialmente o algoritmo pclock, por prover bom isolamento de performance (como mostrado nos experimentos presentes em [Gulati et al. 2007]), além da possibilidade de ajustar os parâmetros largura de banda, rajadas e latência de forma independente. A partir deste algoritmo, foram realizadas modificações visando a utilização do disco de forma mais eficiente. Diferentemente do pclock, o HTBS é não-conservativo, pois implementa as políticas de prevenção de deceptive idleness do algoritmo BFQ. Por este motivo, algumas das garantias matemáticas expostas em [Gulati et al. 2007] referentes ao algoritmo pclock não se aplicam diretamente ao novo algoritmo. Contudo, mostramos através de experimentos que é possível manter as garantias relativas ao isolamento de performance e ao mesmo tempo aumentar o desempenho do disco. O algoritmo é apresentado e explicado em detalhes na subseção 4.1, enquanto considerações a respeito de seu funcionamento e parametrização são discutidas em 4.2.

154 IX Workshop em Clouds, Grids e Aplicações High-throughput Token Bucket Scheduler O algoritmo proposto neste trabalho é baseado em tags ou timestamps. Cada requisição criada recebe duas tags: a tag de início (S ij ) e a tag de término (F ij ), onde i representa a reserva e j o identificador da requisição. Além disso, cada reserva i possui duas outras tags: MinS i, que representa a menor tag de início entre as requisições pendentes de i e MaxS i que representa a soma da maior tag de início em i e 1/ρ i. Novas requisições são criadas através da função add_request, enquanto a função dispatch_request retorna a próxima requisição a ser atendida. O algoritmo principal é mostrado em pseudo-código na Figura 2. add_request (i, r) if active_app == i and i is waiting for the next request then unset_timer () update_num_tokens () check_and_adjust_tags () compute_tags () dispatch_request () if active_app == nil or active_app dispatched more than B max then w = request with minimum finish tag F j w active_app = application j who issued w else if active_app is backlogged then w = request with minimum finish tag F j w from active_app else set_timer () return nil MinS k = S k w return w Figura 2: Algoritmo principal do HTBS. A função dispatch_request realiza dois procedimentos: definir a aplicação ativa (active_app) e a partir desta selecionar uma requisição pendente para atendimento. A aplicação ativa é alterada somente em três casos: 1) a aplicação ativa anterior atingiu o limite de requisições consecutivas B max, 2) não foram criadas novas requisições no intervalo de tempo T wait ou 3) o padrão de acesso da aplicação não é sequencial. Quando houver necessidade de alteração, será selecionada a aplicação que possuir a requisição pendente com menor tag de término. Em seguida, caso a aplicação ativa esteja backlogged, será atendida sua requisição pendente com menor tag de término. Caso contrário, o disco será mantido ocioso por no máximo T wait milissegundos, aguardando novas requisições desta aplicação, evitando a ocorrência de deceptive idleness. A função set_timer é responsável por iniciar o período de ociosidade do disco; unset_timer, por interrompê-lo. Quando uma nova requisição é criada, através da função add_request, existem dois cenários possíveis. Se o disco está sendo mantido ocioso e a requisição pertence à

155 140 Anais aplicação ativa, o algoritmo força a execução da função dispatch_request, onde a requisição recém-criada será selecionada imediatamente para atendimento. Por outro lado, se o disco não estava sendo mantido ocioso, a nova requisição é enfileirada junto a outras requisições da mesma aplicação. Em ambos os casos, três funções são executadas: update_num_tokens, check_and_ajust_tags e compute_tags. Essas três funções foram retiradas do algoritmo pclock e são ilustradas na Figura 3. update_num_tokens () Let Δ be the time interval since last request numtokens i += Δ x ρ i if numtokens i > σ i then numtokens i = σ i check_and_adjust_tags () Let C be the set of all backlogged reservations if j C, MinS j > t r then mindrift = min j C {MinS j t r} j C, subtract mindrift from MinS j, MaxS j and all start and finish tags compute_tags () if numtokens i < 1 then S i r = max {MaxS i, t} MaxS i = S i r + 1 / ρ i else S i r = t F i r = S i r + δ i numtokens i -= 1 Figura 3: Funções retiradas do algoritmo pclock. A função update_num_tokens atualiza o número de tokens de uma reserva. Os novos tokens disponibilizados são proporcionais ao tempo decorrido desde a última atualização, bem como a quantidade de banda ρ alocada para a reserva. Tokens regulam a quantidade de requisições que podem ser criadas por uma aplicação, sem que os atributos de desempenho sejam violados. Esta função também controla as rajadas, representadas pelo atributo por σ, por limitar a quantidade máxima de tokens armazenados em uma reserva. Tags são atribuídas a novas requisições através da função compute_tags. A menos que a aplicação exceda os seus atributos de desempenho, a tag de início de uma requisição será igual ao tempo atual. Caso a aplicação ultrapasse os seus atributos de desempenho, isto é, o seu número de tokens esteja negativo, à tag de início será atribuído um valor maior que o tempo atual. Na prática, atribuir um tempo futuro à tag de início, tem como objetivo aproximar o valor que esta mesma tag teria se a aplicação criasse o mesmo número de requisições sem exceder os limites estabelecidos. A tag de término sempre corresponde à soma do valor da tag de início e do atributo de latência da reserva ( δ). Por último, a função check_and_adjust_tags evita que fluxos sejam penalizados pela utilização da banda ociosa do disco. Como explicado, requisições de aplicações

156 IX Workshop em Clouds, Grids e Aplicações 141 que excedam seus atributos recebem tags de início no futuro. Desta forma, quanto mais banda ociosa uma aplicação utilizar, mais distante do tempo atual serão suas tags de início. Seja um sistema com três reservas a, b e c, por exemplo, onde a e b estejam ociosas e c esteja utilizando mais do que seus atributos de desempenho. Como c está excedendo seus limites, suas tags de início estarão cada vez mais distantes no futuro. Quando a e b voltarem a criar requisições, suas requisições terão tags de início no tempo atual, fazendo com que as requisições da aplicação c, com tags de início no futuro, sofram inanição. Esta função impede que isso ocorra, evitando que as tags MinS de todas as aplicações backlogged estejam no futuro Parâmetros O HTBS possui dois parâmetros ajustáveis: T wait, que limita a quantidade de tempo que o disco pode ser mantido ocioso enquanto estiver aguardando novas requisições da aplicação ativa, e B max, que representa o número máximo de requisições consecutivas que uma aplicação pode executar. O valor adequado para T wait depende fortemente do sistema e das características de cada aplicação. É necessário aumentar este intervalo caso as aplicações realizem uma quantidade maior de processamento entre requisições. Contudo, atribuir um valor muito alto para T wait pode diminuir o desempenho do disco, pois também será alto o tempo máximo que o disco poderá ser mantido ocioso desnecessariamente, no caso de uma aplicação ter finalizado o seu acesso ao disco, por exemplo. Além disso, se o tempo que uma aplicação leva para criar sua próxima requisição é grande o suficiente, pode ser mais eficiente atender uma requisição pendente de outra aplicação, mesmo perdendo localidade. O valor ideal para T wait é o menor tempo necessário para as aplicações síncronas criarem suas próximas requisições, sem causar grande impacto no desempenho do sistema. Nos experimentos realizados, o valor utilizado para T wait é de 10 milissegundos. Como exposto, B max regula o número máximo de requisições síncronas e consecutivas que o disco atenderá de uma mesma aplicação. Quanto maior o valor de B max, maior será o número de requisições executadas com localidade, sendo que a localidade é um dos fatores com maior influência no desempenho do disco. Entretanto, como o disco atenderá exclusivamente requisições de uma aplicação se o valor de B max for alto, pode ocorrer inanição de requisições de outras aplicações. Da mesma forma, quanto maior o valor de B max, mais defasadas serão as garantias de latência e maior será a flutuação (jitter) percebida. Na prática, quanto maior o valor de B max, maior a largura de banda do disco, mas maior também é a latência média entre as requisições. O atributo deve ser configurado de forma adequada, ponderando entre alto desempenho e baixa latência. 5. Resultados Experimentais Para a realização dos experimentos, os algoritmos HTBS e pclock foram implementados como módulos para o Kernel Linux [Linux 2011]. Para o algoritmo BFQ, foi utilizada a implementação oficial que pode ser obtida em [BFQ 2011]. Todos os testes foram executados em um PC equipado com um processador AMD Athlon X2 240, 2800 MHz, dual-core, e 4 GB de memória RAM DDR3. O disco

157 142 Anais utilizado é um Samsung HD080HJ SATA, 80 GB, 7200 rpm e 8 MB de cache onboard, sem suporte a NCQ (Native Command Queueing). Todos os workloads utilizados nos experimentos são sintéticos, gerados pela ferramenta de benchmark fio [Axboe 2011]. O fio permite a realização de testes de benchmark de workloads específicos de I/O, sendo possível especificar parâmetros como a API utilizada para as requisições (síncrona ou assíncrona), padrão de acesso (sequencial ou aleatório), tipo da requisição (leitura ou escrita), tamanho das requisições, taxa de criação de requisições, dentre outros parâmetros. Esta ferramenta permite também a execução de jobs concorrentes com parametrização individual. A seguir são apresentados os resultados de três experimentos: 1) comparação do algoritmo proposto com o algoritmo pclock na presença de duas aplicações com diferentes atributos de desempenho, 2) impacto do parâmetro B max na latência das requisições de uma aplicação e 3) comparação da largura de banda acumulada utilizando diversas aplicações Comparação com pclock O algoritmo proposto neste trabalho é semelhante ao algoritmo pclock. A principal diferença entre os algoritmos é que, no algoritmo proposto, foram criados mecanismos para que as garantias de QoS não fossem prejudicadas por aplicações com requisições síncronas, pois, segundo [Valente e Checconi 2010], grande parte das requisições em sistemas reais são síncronas. Neste primeiro experimento são criadas duas aplicações (jobs): app1 com largura de banda igual a 200 KB/s e latência 50 milissegundos, e app2, com largura de banda de 800 KB/s, e latência 100 milissegundos. App1 tem o padrão de acesso aleatório, enquanto app2 é sequencial; ambas síncronas. O experimento foi executado por 5 minutos, com requisições de 4k e B max igual a 20. A Figura 4 mostra a largura de banda alcançada por cada aplicação durante o teste. De acordo com os gráficos, o algoritmo pclock (b), além de não cumprir o requisito de largura de banda de app2, alocou uma quantidade maior de banda para o app1 que o esperado. Desta forma, mesmo não alocando a quantidade de banda adequada a app2, app1 foi capaz de utilizar banda de disco ociosa. Isto ocorre pois, por serem síncronas, logo após o término do atendimento a uma requisição, o backlog de sua respectiva aplicação estará vazio. Há um intervalo de tempo entre o término de uma requisição e a criação da próxima, durante o qual o escalonador, por ser conservativo, atenderá uma requisição pendente de outra aplicação. Logo, o escalonador pclock atenderá as aplicações em política semelhante à round-robin neste cenário, prejudicando o desempenho total do disco e provendo serviço semelhante independente dos atributos de desempenho atribuídos.

158 IX Workshop em Clouds, Grids e Aplicações 143 Figura 4: Largura de banda para (a) HTBS e (b) pclock O HTBS (a) é capaz de aguardar a próxima requisição de uma aplicação síncrona, possibilitando o cumprimento do atributo largura de banda Impacto do Atributo B max na Latência Neste experimento é analisado o impacto do atributo B max sobre as garantias de latência do sistema. O atributo B max limita a quantidade máxima de requisições consecutivas atendidas de uma mesma aplicação. Por um lado, quanto maior o valor do atributo, maior o benefício pela localidade do acesso; por outro, um valor muito grande pode prejudicar as garantias de latência e até causar inanição. Como no experimento anterior, são criadas duas aplicações com os mesmos padrões de acesso e atributos de desempenho app1 aleatória, largura de banda igual a 200 KB/s e latência 50 milissegundos, e app2, sequencial, 800 KB/s de largura de banda e 100 milissegundos de latência. Os gráficos apresentados na Figura 5 mostram a latência sofrida pelas requisições de ambas as aplicações quando executadas com (a) B max igual a 1 e (b) B max igual a 20. Na prática, utilizar o algoritmo HTBS com B max igual a 1 é equivalente a utilizar o algoritmo pclock, logo, este experimento compara a latência sofrida por ambos os algoritmos. O tempo total de execução do teste é de 10 segundos. A latência sofrida pelas requisições de app1 e app2 tem maior variação com o aumento do valor de B max. Com este aumento mostrado em (b), as requisições de app2, que é sequencial, têm maior variação, apresentando valores muito baixos quando são atendidas as suas requisições consecutivas, e valores altos quando a aplicação ativa é alterada, causando seek time. App1 também tem um pequeno aumento em sua latência média em (b), pois até 20 requisições de app2 podem ser atendidas antes que a sua próxima requisição pendente seja servida. Mesmo assim, apesar do aumento na latência das requisições, nenhuma requisição de app1 ou app2 estourou o seu deadline neste experimento. O jitter, contudo, é maior em (b) do que em (a).

159 144 Anais Figura 5: Latência utilizando o algoritmo HTBS com (a) B max = 1 e (b) B max = Largura de Banda Acumulada Neste experimento apresentamos a largura de banda total acumulada por cada escalonador. Com este objetivo, foram criados três casos de teste, sendo cada teste executado com os três algoritmos de escalonamento pclock, BFQ e HTBS. Todos os casos de teste são compostos por sete aplicações executando leituras síncronas e sequenciais em diferentes posições do disco. A diferença entre os casos de teste consiste em que o primeiro executa somente as sete aplicações sequenciais; o segundo executa duas aplicações aleatórias concorrentemente às sete aplicações sequenciais; no terceiro, sete aplicações sequenciais e quatro aleatórias. Cada teste foi executado por 30 segundos e o resultado mostrado corresponde à média aritmética de três execuções. Todas as aplicações aleatórias foram limitadas no benchmark a enviar requisições à taxa de 40 KB/s, enquanto as sequenciais foram mantidas ilimitadas. Estabelecer um baixo limite para o número de requisições aleatórias é uma forma de garantir que, em média, a mesma quantidade destas requisições sejam atendidas em todos os casos, por todos os escalonadores. Caso fossem mantidas ilimitadas, um escalonador poderia servir mais requisições aleatórias que outros, por exemplo, e prejudicar os resultados do experimento. Como o algoritmo BFQ não possui controle explícito para atributos de desempenho, a todas as aplicações foram atribuídos os mesmos parâmetros: largura de banda ilimitada (salvo requisições aleatórias) e 100 milissegundos de latência. Para os algoritmos BFQ e HTBS, o valor de B max utilizado é 20. A Figura 6 apresenta os resultados encontrados. No primeiro caso de teste, como não há requisições aleatórias, o sistema tem o melhor ganho de desempenho com os algoritmos que implementam controle de deceptive idleness: cerca de 25%. No segundo teste pode ser observado que mesmo na presença de requisições aleatórias, como ainda é grande o número de requisições sequenciais, HTBS e BFQ apresentam desempenho superior. No último teste, com quatro jobs aleatórios, é perceptível a degradação do desempenho do sistema. Neste caso, o HTBS mostra desempenho semelhante ao pclock, pois o ganho decorrido das execuções seguidas de requisições sequenciais é pequeno se comparado ao overhead causado pelas requisições aleatórias. Através destes

160 IX Workshop em Clouds, Grids e Aplicações 145 experimentos vemos também que a performance do HTBS é, em média, semelhante ao BFQ, mesmo que o BFQ não possua os mecanismos de controle por aplicação presentes nos outros dois algoritmos. Figura 6: Largura de banda acumulada para os algoritmos pclock, BFQ e HTBS 6. Conclusão Este trabalho apresentou o HTBS, um novo algoritmo de escalonamento de disco, baseados em dois algoritmos propostos anteriormente (pclock e BFQ), com o objetivo de fornecer isolamento de performance a aplicações concorrentes com diferentes atributos de QoS. Através de experimentos, mostramos que o algoritmo pclock, que é a base do algoritmo proposto, não fornece boas garantias de desempenho na presença de requisições síncronas e sequenciais, utilizadas por grande parte das aplicações atuais. Por isso, o HTBS incorpora alguns mecanismos utilizados pelo algoritmo BFQ para tratar este tipo de requisições, em especial o mecanismo de prevenção de deceptive idleness. Os experimentos realizados com o protótipo implementado para o Kernel Linux mostram que o novo algoritmo aumenta o desempenho geral do disco, se comparado ao seu antecessor, pclock, na presença de requisições síncronas e sequenciais, sem que as garantias de latência sejam violadas. Mostramos também que em alguns casos, o desempenho geral provido pelo novo algoritmo supera o algoritmo BFQ, que apesar de prevenir a ocorrência de deceptive idleness, não implementa mecanismos para garantir atributos de largura de banda e latência de forma individual. Dando continuidade ao trabalho, criaremos mais casos de teste para simular a execução de aplicações reais, como servidores Web, SGBD's e servidores de . Pretendemos também analisar o comportamento do novo algoritmo quando utilizado em conjunto com ferramentas como LVM e RAID, para que possa ser adaptado para utilização em servidores de armazenamento de grande porte. Referências Valente, P. e Checconi, F. (2010) High Throughput Disk Scheduling with Fair Bandwidth Distribution, IEEE Transactions on Computers, vol. 59, páginas IEEE Computer Society.

161 146 Anais Gulati, A., Merchant, A. e Varman, P. (2007) pclock: An Arrival Curve Based Approach for QoS Guarantees in Shared Storage Systems, SIGMETRICS Perform. Eval. Rev., New York, NY, USA, vol. 35, páginas ACM. Iyer, S. (2003) The effect of deceptive idleness on disk schedulers., Dissertação de Mestrado, Rice University. Seelam, S. e Teller, P. (2006) Fairness and Performance Isolation: an Analysis of Disk Scheduling Algorithms, IEEE International Conference on Cluster Computing, páginas IEEE Computer Society. Bruno, J., Brustoloni, J., Gabber, E., Ozden, B. E Silberschatz, ª (1999) Disk Scheduling with Quality of Service Quarantees, Proceedings of the IEEE International Conference on Multimedia Computing and Systems, volume 2. IEEE Computer Society. Reddy, A., Wyllie, J. e Wijayartne, K. (2005) Disk Scheduling in a Multimedia I/O System, ACM Trans. Multimedia Comput. Commun. Appl., páginas 37-59, volume 1. ACM. Iyer, S. e Druschel, P. (2001) Anticipatory scheduling: A disk scheduling framework to overcome deceptive idleness in synchronous I/O, ACM Symposium on Operating Systems Principles, páginas ACM. Jian, K., Dong, Z., Wen-wu, N., Jun-wei, Z., Xiao-ming, H., Jian-gang, Z., Lu, X. (2009) A Performance Isolation Algorithm for Shared Virtualization Storage System, Proceedings of the 2009 IEEE International Conference on Networking, Architecture, and Storage, páginas 35-42, IEEE Computer Society. Bennett, J. e Zhang, H. (1997) Hierarchical Packet Fair Queueing Algorithms, IEEE/ACM Trans. Networks, páginas , volume 5. IEEE Press. Vaquero, L., Merino, L., Caceres, J. e Lindner, M. (2009) A Break in the Clouds: Toward a Cloud Definition, SIGCOMM Comput. Commun, páginas Tanenbaum, A. (2002) Computer Networks, volume 4. Prentice Hall Professional Technical Reference. Axboe, J. (2007), CFQ I/O Scheduler, Acessado em 3 de maio de Axboe, J. (2011), Fio flexible I/O tester, Acessado em 3 de maio de Linux Kernel (2011), Acessado em 3 de maio de BFQ and related stuff on disk scheduling (2011), Acessado em 3 de maio de LVM Resource Page (2011), Acessado em 3 de maio de Amazon EC2 (2011), Acessado em 3 de maio de Google Storage for Developers (2011), Acessado em 3 de maio de 2011.

162 IX Workshop em Clouds, Grids e Aplicações 147 Performance Evaluation of Distributed Data Access Optimization Approaches: Experiments versus Simulations Vinicius de Freitas Reis 1 and Rodrigo Fernandes de Mello 1 1 Department of Computer Science Institute of Mathematics and Computer Sciences University of São Paulo São Carlos SP Brazil Abstract. This work was motivated by the gap in between simulation and experimental approaches when evaluating distributed data access operations. The performance of file replication techniques is evaluated and compared under both approaches to investigate whether simulation results are observable in real-world scenarios. In that sense, this paper presents a modular support to implement data access optimization policies in the Gfarm distributed file system and compare it to OptorSim, a broadly used Data Grid simulator. We have concluded that, in some situations, even qualitative results differ significantly in both approaches, raising important considerations when evaluating simulation results and designing real-world scenarios. 1. Introduction Until the last decade, three paradigms were explored in science: empirical, based solely on experimentation; theoretical, which attempts to explain facts by equations; and computational, which addresses complex analytical models by considering simulations. However, recently there has been a huge increase in the data produced by instruments or generated by simulations, drastically changing techniques, technologies and the whole pipeline of scientific exploration. This change, for some authors, can further characterize a new scientific paradigm [Hey et al. 2009]. Examples of applications under this new paradigm are the SKA (Square Kilometer Array) Project, which may produce data at a rate of 4.1 Pbits/s [Dewdney et al. 2009], Pan-STARSS (Panoramic Survey Telescope & Rapid Response System), which captures terabytes of raw data a night [PAN-STARRS 2010] and the LHC (Large Hadron Collider), which is estimated to require in between 50 and 100 PB of storage per year [Hey et al. 2009]. The large volume of data captured by all those projects must be preprocessed before storage, simplifying further analysis. Grid computing [Foster et al. 2001] was proposed as the computational infrastructure to meet these requirements by coordinating the sharing of heterogeneous resources (such as telescopes and other complex instruments) among organizations at geographically distributed locations. In the same way, Chervenak et al. [Chervenak et al. 1999] proposed the concept of Data Grids, a specialization of Grids focused on providing reliable and robust large-scale data sharing. Several application domains, such as high-energy physics, bioinformatics and climate analysis, require such type of infrastructure. Those domains face problems mainly related to storage size, data throughput, application performance as well as the costs involved in all that scenario. Another common problem is that data is heavily generated at

163 148 Anais only one site and accessed by remote computers. Thus, data files must be stored in a way to reduce access costs, such as latency, consequently improving application performance (not only the application generating data, but also others which access the information). Besides, data must not be concentrated, as hotspots and single points of failure would be generated. File replication is the approach commonly considered to address many of those problems. This approach creates multiple file copies at different grid sites in order to: 1) increase file availability, making a file accessible even if some of the replicas are offline or a grid site fails; 2) balance the data servers workload, once file accesses can be distributed among replicas; and 3) decrease file access costs, as every process can use the nearest replica (considering both latency and bandwidth). This scenario brings new problems, as the maintenance of consistency, which creates a tradeoff in between the data distribution benefits (such as performance, availability, etc) and the access of updated data. Ragananthan & Foster [Ranganathan and Foster 2001] evaluated how file replication affects Grid performance using their own developed simulator. Three access patterns were considered, against five dynamic replication strategies. Results showed reductions in the network bandwidth consumption as well as in the file access time. In a similar direction, Bell et al. [Bell et al. 2003a] proposed the OptorSim simulator as a tool to study different replication strategies on Data Grids. The modular approach of OptorSim made it broadly considered [Bell et al. 2003b, Elghirani et al. 2009, Rahman et al. 2008] and also employed in the CERN s EU DataGrid Project. From a more practical point of view, Douceur & Wattenhofer [Douceur and Wattenhofer 2001] evaluated file replica approaches in the Farsite distributed file system in order to increase file availability. A distributed hill climbing approach was used, and networks with more than nodes were simulated. Tatebe et al. [Tatebe et al. 2003] studied the time spent on file replication, considering parallel transfers. Experiments were conducted on networks connecting USA and Japan. Abdullah et al. [Abdullah et al. 2008] considered a peer-to-peer Data Grid model and discussed nearest neighbor-based distributed replication strategies. A simulator was implemented using the PARSEC simulation language and experiments evaluated peer-to-peer domain measurements, such as success rate and flood response time. The results confirmed significant benefits. By analyzing the previous works, we observe there is a gap in between simulation and experimental approaches. Simulations are very useful in order to point out relative tendencies of replication and consistency strategies, however, they neither confirm the actual amount of resources used nor the final performance improvements. On the other hand, experimental approaches are costly and hard to implement, demanding considerable time. Another important concern is how to ensure that simulation results are indeed observable in real-world scenarios. In that sense, this paper proposes a modular support to implement data access optimization policies in the Gfarm distributed file system [Tatebe et al. 2002]. Gfarm was selected due to its stability and robustness, verified after a trial with several distributed file systems 1. 1 Ceph [Weil et al. 2006], Starfish [Starfish 2009], Gfarm [Tatebe et al. 2002], HDFS [Hadoop 2010], Cloudstore [Cloudstore 2010] and PVFS [Carns et al. 2000] were evaluated, as detailed in Section 3

164 IX Workshop em Clouds, Grids e Aplicações 149 The support provides a well-defined interface, allowing researchers and developers to design and test new optimization approaches. Besides this proposal, we also implemented and evaluated the performance of the most commonly considered data access optimization approaches, which are available in the OptorSim simulator. OptorSim was chosen for comparison as it is one of the most used data grid simulators [Bell et al. 2003b, Elghirani et al. 2009, Rahman et al. 2008]. By analyzing the results, we confirm the tendency of OptorSim results. However, the percentages of improvements are very distinct for some situations, which raises important considerations when evaluating simulation results and the design of real-world scenarios. This paper is organized as follows: Section 2 presents some related work; Section 3 describes the architecture of the proposed support as well as implementation details; Section 4 explains how experiments were prepared, presenting results of the execution of those experiments on a real environment and on OptorSim. Finally, conclusions and references are presented. 2. Related Work Related work on data access optimization methods can be divided into two basic approaches: simulation and experimental ones. While simulations are very popular and useful to relatively compare different optimization strategies and point out tendencies, inaccurate results may limit real-world conclusions. On the other hand, the inherent difficulty in building environments, designing and implementing systems has limited experiments in real scenarios. Some of the main works on data access optimization are presented next. As the reader may observe, they are strongly based on simulation methods. Ranganathan & Foster [Ranganathan and Foster 2001] studied the effect of many replication strategies by considering different file access patterns. Results, based on their own simulator, analyzed both the bandwidth consumption and the time consumed to retrieve remote files. Local files were supposed to have zero response time, and file writing was not allowed, avoiding consistency problems. Three file access patterns were considered: one purely random, one with small temporal locality and one with both temporal and geographical locality. Five different replication strategies were studied, and a replacement strategy hybrid in between file popularity and access time was used. No details about network topology and size were given. Results compared replication strategies among themselves, but no comparison was made to an environment without replication. It was possible to observe an approximately 50% reduction in response time for some scenarios, as well as an increase in those times in other cases. Bandwidth consumption and response time were analyzed. Elghirani et al. [Elghirani et al. 2009] explored the synergy in between process scheduling and data management, aiming to increase the overall application performance. They also proposed a framework to replicate and estimate the proper file copy placement. The framework provides file distribution algorithms based on Tabu Search [Glover 1986], Genetic Algorithms [Holland 1975] and Ant Colony Optimization [Dorigo and Di Caro 1999]. Those techniques consider information such as access patterns, dataset popularity, network latency and bandwidth. Simulations were conducted using the proposed framework in conjunction with OptorSim [OptorSim 2009] and the European DataGrid Testbed 1 was evaluated (this is a typical OptorSim testbed)

165 150 Anais [Bell et al. 2002]. Tests considered a single file access pattern, with varying number of jobs, and analyzed the job execution time. Rahman et al. [Rahman et al. 2008] modeled the dynamic data replication problem by using operations research. The replica distribution problem is modeled as the resolution of a p-center or p-median problem [Hakami 1963], or a combination of both, which is achieved by a multi-objective optimization algorithm. The solution is approximated by using Lagrangian relaxation [Fisher 2004]. The OptorSim simulator was used to validate the replication strategies, using the European DataGrid Testbed 1. This work did not consider the time consumed in operations; it only evaluates the approach by counting the number of local and remote accesses. Moreover, it does not compare the proposed approach to others available in OptorSim. Sato et al. [Sato et al. 2008] proposed a data replication strategy considering application dynamics. The replication problem was modeled as a combinatorial optimization problem, which aims to minimize the replication transfer time. The authors approach the problem using an integer linear programming solver [GLPK 2009], fact that created noticeable delay according to them. A prototype was implemented in the Gfarm distributed file system [Tatebe et al. 2002], however experiments in real environments were limited only to network throughput estimates. File size distribution was based on the files used by BLAST biological sequence alignment application [Altschul et al. 1990]. The main evaluations of the proposed approach were drawn from simulations, however no details were given about how simulations were conducted or which tools were used, which does not allow reproducibility. Furthermore, the objective and metrics vary among the presented initiatives. Sato et al. [Sato et al. 2008] and Elghirani et al. [Elghirani et al. 2009] consider the total application execution time as performance metric. On the other hand, Rahman et al. [Rahman et al. 2008] evaluate the data transfer time and the number of local and remote accesses. Ranganathan & Foster [Ranganathan and Foster 2001] analyze bandwidth consumption and response time. Sato et al. [Sato et al. 2008] also study the replication workload, by evaluating the free storage space. Ranganathan & Foster [Ranganathan and Foster 2001] discuss some algorithms storage usage, but do not present any data. Another issue is that the algorithms proposed, except for Ranganathan & Foster [Ranganathan and Foster 2001], are not distributed, requiring a central entity to coordinate all operations. All of them also assume the existence of a graph indicating the network topology, latencies and bandwidths with accurate measurements, an assumption that is very restrictive considering dynamic environments. As previously presented, we have observed a vast list of relevant works on data access approaches, however most of them are based on simulation approaches. That was the main motivation for this work, which considered an experimental strategy and compared it to one of the main simulators currently proposed, called OptorSim [OptorSim 2009]. This comparison allowed confirming sensible differences in simulation and real-world scenarios, influencing decisions in practical situations. 3. Proposed Support This work was motivated by the fact that most data access optimization studies are conducted based on simulations, which can produce inaccurate results when compared to

166 IX Workshop em Clouds, Grids e Aplicações 151 Support Access History File Metadata Replica Management Optimization Plugin Replication Algorithm 1 Replication Algorithm 2 Gfarm Figure 1. Optimization support overview. The blocks inside the support show examples of services provided to optimization plugins. real situations. It proposes a support to design and evaluate distributed data access optimization techniques in real-world scenarios. The support was developed over the Gfarm [Tatebe et al. 2002] distributed file system, and allows optimization strategies to be plugged, easily developed and tested. Figure 1 shows the basic architecture of the system: the support, built over the Gfarm API, offers Replica Management services, File Metadata and Access History retrieval for optimization plugins, which can be tested and interchanged. Before designing it, a distributed file system was selected to take advantage of the support services. In such a situation, we defined the following list of criteria: 1) the file system should be licensed under an open source model, making it available for other researchers, developers and users, and have the source code available for study; 2) the file system should be stable, allowing for reproducible and reliable experiments; 3) the file system should support both read and write operations, enabling its use for scientific applications; 4) the file system should not have any single point of failure. Since then, we defined a set of file systems to be evaluated: Ceph [Weil et al. 2006], Starfish [Starfish 2009], Gfarm [Tatebe et al. 2002], Hadoop s HDFS [Hadoop 2010], Cloudstore [Cloudstore 2010] and PVFS [Carns et al. 2000]. NFS was designed for local networks, therefore it was not considered in this set. Ceph was the first file system to be tested. It satisfied some of the criteria: it supports read-and-write operations, and has distributed storage and distributed metadata. However, even simple file sharing tests in between two machines revealed the existence of bugs. s exchanged with Ceph s author confirmed that the file system was not ready to be used in production environments. The second file system tested was Cloudstore, which also presented stability problems. The third system tested, Gfarm, was selected to support this work. Although it did not fully meet all criteria (it presents a single point of failure in the metadata server), it was the best available. Regarding the other three systems, Starfish could not be used because of patent problems, PVFS replication support required high-cost solutions, such as a SAN (Storage Area Network), and HDFS was designed in write-once approach. The Gfarm distributed file system is open source software distributed under GNU/GPL [GPL 2009] and part of the Asia Pacific Grid project (ApGrid) [Tatebe et al. 2002]. It was designed to manage file accesses in dynamic networks consisting of thousands of computers storing large amounts of data. Gfarm provides the clients a single file system image, transparently available to applications via a FUSE (File system in Userspace) module. Gfarm itself is composed of several data servers and a metadata server which is, unfortunately, a single point of failure to the system. Data servers communicate directly with clients to provide data and the metadata server manages the

167 152 Anais agent Metadata server gfmd Dataserver C agent Dataserver B agent mdsagent Dataserver D agent agent Dataserver A optimizer client process Client Machine fread libintercept fread FUSE Dataserver E agent gfsd Figure 2. Interprocess communication at the proposed support. replica catalog (it provides the association among files and data servers), file permissions and other relevant data. In the next step, the support was designed. We decided to have three main components: one in the clients, one in data servers and one in the metadata server. The client component is responsible for monitoring the application and triggering optimization requests; the data server component runs the optimization techniques and replicates files, and the metadata server optimization component is responsible for removing file replicas. We also had to serialize replica removal requests, ensuring that at least a single file replica would always exist. Due to the distributed nature of the file system, two different data servers may request the removal of a single replica of the same file at the same time. Figure 2 illustrates the interprocess communication during the optimization. The agent process is the optimization process which runs at data servers; optimizer is the process which implements the optimization technique; libintercept.so is an interception library linked to the client process at runtime; gfsd is the Gfarm data server process; gfmd is the Gfarm metadata server process; mdsagent is the process responsible for receiving agent requests to remove file replicas. The client component was implemented by intercepting client processes, allowing the support to capture process data beyond file accesses, such as system calls. This interception is performed using both Dlsym library and the dynamic linker. The Linux environment variable LD PRELOAD allows the process functions from the C standard library to be overwritten by the interception library. After executing the desired code, the original functions from GNU Libc are called using the Dlsym library. This technique has a small overhead (around 1 and 2 percent considering the process total execution time [Ishii 2010]). When a file has been frequently accessed, an optimization request is sent to a data server. To decide whether or not to trigger this request, an EWMA (Exponentially Weighted Moving Average) of access times is used, as averages closer to the current time indicate a burst of file accesses. For example, when the client issue five file reads in less than a second, this average will be very close to the current time, triggering the

168 IX Workshop em Clouds, Grids e Aplicações 153 request. On the other hand, if only a single request occurs, it will not change the average significantly and the optimization will not be triggered. When the difference in between this average and the current time is below some threshold, the optimization request is sent to the nearest data server in terms of RTT (Round-trip time). This is possible because clients keep an updated list of online data servers with measurements of their RTT and free disk space. The request contains information such as every I/O operation parameter and timestamp, available file replicas and file sizes. I/O library call interception layer I/O system call optimization request optimization plugin call file replication Figure 3. Main steps involved in the optimization process. As the support needs to be modular, each optimization technique is a separate program, which receives information from this request through its standard input and writes the resulting actions back to its standard output (file replicas can be created or removed). This makes the development of the optimization technique easier, as any programming language can be used. 4. Experiments 4.1. Environment Configuration The next step in the project development was to evaluate the proposed interface and compare data access optimization strategies under real-world scenarios. An approach based on virtual machines was chosen, as it allowed emulating different network topologies and system scales. The developed software could be used, with no change, to conduct experiments in real-world grid computing environments. One of the goals of these experiments was to evaluate how simulation (using OptorSim [Bell et al. 2002]) results are related to the ones obtained under those virtual environments. The support prototype was built using VirtualBox [VirtualBox 2010] virtual machines, but this approach soon revealed too expensive even to create medium-sized networks, as each virtual machine used a large amount of resources. The solution found was to switch to OpenVZ [OpenVZ 2010] virtual machines, which in fact proved to be much more scalable. VirtualBox uses an approach called hardware-level virtualization [Sugerman et al. 2001] (or full virtualization), in which each virtual machine has its own simulated hardware devices with different instances of operating systems running. On the other hand, OpenVZ uses an approach called operating system-level virtualization [Soltesz et al. 2007], in which a single kernel is shared among all virtual machines (now called containers) and all processes run natively. This approach is capable of providing isolation among containers and also presents less overhead than other virtualization techniques, such as complete virtualization (VirtualBox, VMWare) and paravirtualization (Xen) [Chaudhary et al. 2008].

169 154 Anais After creating the containers, it was necessary to configure the network among them. Each connection in between the machines was defined as a kernel bridge containing two virtual network interfaces. The kernel module netem (Network Emulation) provided control over the connection latency, and the module htb (Hierarquical Token Bucket) provided control over the connection bandwidth. A script was used to automatically create the containers, the network topology (with the given latencies and bandwidths) and the routing tables, which were calculated using the Floyd-Warshall algorithm applied to the input graph. Several dynamic routing software, including BIRD [BIRD 2010] and Quagga [Quagga 2010], were tested, but none of them worked out on the virtual network created. The results of the emulation environments were compared to the ones obtained with OptorSim [Bell et al. 2002]. OptorSim is a broadly used simulator, designed to study the dynamics of data replication strategies in Grid environments. It simulates the Grid as a network of sites, each one having its own set of SEs (Storage Elements) and CEs (Computing Elements). Each site also has a Replica Manager service, which takes replica optimization decisions, and a Global Resource Broker, which schedules jobs among CEs. An arbitrary network topology can be specified and every job can be configured to use a different subset of files. Two file replication techniques implemented in OptorSim are considered in this work: Least Frequently Used (LFU) and Least Recently Used (LRU). Those techniques are based on the well-known cache replacement policies. The link in between caching and file replication is the assumption that, when a file is first used, it is always advantageous to create a its local replica considering there is enough space. When there is no disk space available, a replica must be removed in order to create a new one. LFU removes the least frequently used replica in some predefined time window and LRU removes the least recently used replica. The order in which a job requests files determines its access pattern. Four different access patterns were implemented in OptorSim and also used in this work: Sequential, Unitary Random Walk, Gaussian Random Walk and Flat Random. The first file read is always random, with uniform distribution among files. Let i be the identifier of the file currently read. In the Sequential pattern, next reads follow the sequence (i + 1, i + 2, i + 3,...). In Random Walk patterns, the next file read is chosen using some probability distribution centered at i: in Unitary Walks this distribution is uniform (files i + 1 or i 1 can be chosen), and in Gaussian Walks this distribution is normal. Finally, in the Flat Random pattern, every file has the same probability (uniform distribution) of being chosen in all reads. All simulations and experiments were conducted using the CMS Testbed 2002 network topology available in OptorSim, as shown in Figure 4. This network is based on the CMS (Compact Muon Solenoid) experiment, part of the LHC (Large Hadron Collider) project at CERN (Conseil Européen pour la Recherche Nucléaire), and is composed of 20 data servers and 6 routers distributed among research centers. Such a testbed topology was considered in OptorSim simulations and also emulated in the experimental scenario using OpenVZ. The machine used in the experiments was Intel(R) Core(TM) 2 Quad CPU Q9550 at 2.83GHz with 4GB of RAM running CentOS 5.4.

170 IX Workshop em Clouds, Grids e Aplicações 155 Figure 4. CMS Testbed 2002 network topology [Bell et al. 2003b]. We created 100 files, initially located at FNAL site (Figure 4). All files had the same size, which can also be seen as multiple fixed-size chunks of the same file. The metadata server was located at CERN. The graph used by OptorSim [Bell et al. 2002] did not specify connection latencies, which define the nearby regions for the optimizer. The empirical equation latency = 5000, where x is the link bandwidth (in Mbps), was used x to model those missing latencies. Using such an equation, we had latencies distributed in between 0msec and 110msec Results Figures 5 and 6 present the experimental (using the emulated environment) and simulation (using OptorSim) results, considering different file access patterns. A single job was run on every grid site, reading 30 whole files using 4KB blocks. Although we considered only one job per site, we can indeed see it as one entity summarizing the behavior of multiple jobs running at the same location. Notice that the plots show the sum of the execution time of all jobs, such that the global system behavior is depicted. Any reduction in this time represents a real performance improvement, although some jobs may run slower due to overhead introduced by the support. The free disk space on every data server was enough to store 5 file replicas in all scenarios, avoiding all files being replicated to every grid site. Due to the time required, real experiments were repeated 5 times, while every scenario was executed 30 times on OptorSim (simulations were run more times due to their considerably shorter execution time). Error bars show the confidence interval of 95% for the average time necessary to conduct all file access operations under different scenarios. It is important to notice that the confidence intervals found are small enough to be statistically relevant, despite the relatively small number of repeated experiments (5 times). Notice that the scales in Figures 5 and 6 are quite different, an expected fact as the emulated environment was run on a single physical machine. However, the relative results between the two environments should be equivalent (and they were not).

171 156 Anais No replication LRU LFU No replication LRU LFU No replication LRU LFU Time (sec) Time (sec) Time (sec) Sequential Random Unitary Gaussian 0 Sequential Random Unitary Gaussian 0 Sequential Random Unitary Gaussian (a) 128MB files (b) 256MB files (c) 512MB files Time (sec) No replication LRU LFU Figure 5. Emulated environment results. Time (sec) No replication LRU LFU Time (sec) No replication LRU LFU Sequential Random Unitary Gaussian 0 Sequential Random Unitary Gaussian 0 Sequential Random Unitary Gaussian (a) 128MB files (b) 256MB files (c) 512MB files Figure 6. OptorSim simulation results. Figure 6 clearly shows that, on OptorSim, every replication technique has the same relative results independently of the file size chosen. On the other hand, Figure 5 shows a quite different behavior comparing the 128MB situation to the 256MB and 512MB scenarios. The performance decrease observed at 128MB for the Unitary and Gaussian patterns can be explained by the optimization support overhead: the first file access at every client will trigger an optimization request, which will trigger a latency measurement at the client, causing a significant lag when the job execution time is determined by 128MB files. The time to take this measurement does not lengthen as the file size increases, making it less perceived under other scenarios. Another important analysis is the speedup of replication techniques (compared to the situation with no replication), as it makes possible to compare the relative results between the two environments. In OptorSim experiments, using 256MB files under the Unitary Random Walk access pattern, the LRU replication offers 5.07 of runtime speedup against only 1.87 observed in the real scenario. On the other hand, comparisons with other access patterns are more consistent. For example, considering the Gaussian Walk access pattern, speedups are 1.59 for OptorSim and 1.83 in the real environment. All those results are summarized in Table 1. This type of analysis is an important achievement, because it shows that simulations conducted in OptorSim, even in a qualitative manner, may provide very inaccurate results. For example, Sato et al. [Sato et al. 2008] report that their proposed replication technique provided a speedup equal to 200, a very doubtful result even considering a different network topology and file access patterns. Those authors did not give details on the simulation technique used, which makes it impossible to reproduce experiments. Analyzing the experimental results, we can conclude they are consistent: both Flat Random and Sequential access patterns have compatible performance, which is expected since the probability of a file being read twice is almost zero for Flat Random pattern, and

172 IX Workshop em Clouds, Grids e Aplicações 157 Table 1. Speedup comparison. LRU LFU OptorSim Real OptorSim Real Sequential Flat Random Unitary Walk Gaussian Walk Local Access Rate (%) LRU LFU Free Space (number of files) Local Access Rate (%) LRU LFU Free Space (number of files) Local Access Rate (%) LRU LFU Free Space (number of files) (a) Gaussian Random Walk (b) Unitary Random Walk (c) Flat Random zero for the Sequential one. Figure 7. Monte Carlo simulation results. A study was also conducted to analyze the behavior of the system as the free space, on every data server, is increased. Considering an environment with only two machines a server, containing all files, and a client, that issued requests and had some local disk free space to store replicas a simple Monte Carlo simulation was conducted to calculate the probability of a local file access, given an access pattern and the free space at the client. Each simulation was repeated 3, 000 times, and Figure 7 shows the average of local file access rate for the Unitary Random Walk, Gaussian Random Walk and Flat Random access patterns. The Sequential pattern was not considered because it would always have rates equal to zero. We observed that after 10 files of free space, the performance of the optimization techniques became stabilized (Figure 7). At this point, no replica removal occurs, therefore the performance of LRU and LFU (and every other file replication technique that creates replicas in the first access and uses some other strategy to remove replicas when the local data server becomes full) is exactly the same. Another important consideration is that the free space used in previous experiments (5 files) is very close to the optimal performance, meaning that even if the free space were changed in those experiments, no significant performance changes would occur. In fact, considering that the access times are 4 seconds for local files and 230 for remote ones (these were the average times observed in real experiments for 256MB files), we used the local access rate to estimate the optimal performance achieved when free space was unlimited. Results for an unlimited approach are presented by horizontal dashed bars in Figure 8. It may seem strange that some real results are below the bars, but it can be explained by the fact that a replicated file does reduce the file access cost on all nearby servers (if they read the file), which is an effect not considered on the simulation proposed. However, this type of simulation was very useful because it showed the need for the development of file replication techniques that proactively create replicas and did not rely only on file requests from a single job. Every file replication technique that does not

173 158 Anais No replication LRU LFU Time (sec) Sequential Random Unitary Gaussian Figure 8. Integrated results. Dashed bars show the expected performance if every server had unlimited disk space. follow this approach is bounded by the performance limits shown in Figure Conclusions This work investigates the differences in between experimental and simulation approaches when evaluating distributed data access optimization algorithms. A support for distributed data optimization using the Gfarm distributed file system was implemented and a virtualized environment was used as a testbed for this support. Several experiments were conducted to evaluate some classic algorithms, and these same experiments were reproduced in the OptorSim simulator. A comparative analysis of those results was performed, showing that OptorSim can produce inaccurate results even in relative terms for some scenarios. This result raises important concerns when studying the performance of file replication algorithms, since most works are based on simulations [Ranganathan and Foster 2001, Sato et al. 2008, Bell et al. 2003b, Elghirani et al. 2009, Rahman et al. 2008, Douceur and Wattenhofer 2001, Abdullah et al. 2008]. As future work, we intend to evaluate some real-world applications running in this virtualized environment, which is an important step as the performance improvement is highly dependent on the access pattern considered. We also expect to develop and test a new replica placement algorithm and evaluate its performance in both environments. 6. Acknowledgments This paper is based upon work supported by FAPESP (São Paulo Research Foundation), Brazil. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of FAPESP. References Abdullah, A., Othman, M., Ibrahim, H., Sulaiman, M., and Othman, A. (2008). Decentralized replication strategies for p2p based scientific data grid. In Information Technology, ITSim International Symposium on, volume 3, pages 1 8. Altschul, S. F., Gish, W., Miller, W., Myers, E. W., and Lipman, D. J. (1990). Basic local alignment search tool. Journal of molecular biology, 215(3): Bell, W. H., Bell, W. H., Cameron, D. G., Cameron, D. G., Capozza, L., Capozza, L., Millar, A. P., Millar, A. P., Stockinger, K., Stockinger, K., Zini, F., and Zini, F. (2003a). Optorsim - a grid simulator for studying dynamic data replication strategies. International Journal of High Performance Computing Applications, 17:2003.

174 IX Workshop em Clouds, Grids e Aplicações 159 Bell, W. H., Cameron, D. G., Capozza, L., Millar, A. P., Stockinger, K., and Zini, F. (2002). Simulation of dynamic grid replication strategies in optorsim. In Journal of High Performance Computing Applications, pages Springer-Verlag. Bell, W. H., Cameron, D. G., Carvajal-schiaffino, R., Millar, A. P., Stockinger, K., and Zini, F. (2003b). Evaluation of an economy-based file replication strategy for a data grid. In In Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid, 2003 (CCGrid IEEE Computer Society Press. BIRD (2010). retrieved 03/06/2010. Carns, P. H., Ligon III, W. B., Ross, R. B., and Thakur, R. (2000). PVFS: A parallel file system for linux clusters. In Proceedings of the 4th Annual Linux Showcase and Conference, pages , Atlanta, GA. USENIX Association. Chaudhary, V., Cha, M., Walters, J., Guercio, S., and Gallo, S. (2008). A comparison of virtualization technologies for hpc. In Advanced Information Networking and Applications, AINA nd International Conference on, pages Chervenak, A., Foster, I., Kesselman, C., Salisbury, C., and Tuecke, S. (1999). The data grid: Towards an architecture for the distributed management and analysis of large scientific datasets. Journal of Network and Computer Applications, 23: Cloudstore (2010). retrieved 01/02/2010. Dewdney, P., Hall, P., Schilizzi, R., and Lazio, T. (2009). The square kilometre array. Proceedings of the IEEE, 97(8): Dorigo, M. and Di Caro, G. (1999). The ant colony optimization meta-heuristic. In Corne, D., Dorigo, M., and Glover, F., editors, New Ideas in Optimization, pages McGraw-Hill, Londres. Douceur, J. and Wattenhofer, R. (2001). Optimizing file availability in a secure serverless distributed file system. Reliable Distributed Systems, IEEE Symposium on, 0:0004. Elghirani, A., Subrata, R., and Zomaya, A. Y. (2009). Intelligent scheduling and replication: a synergistic approach. Concurrency and Computation: Practice and Experience, 21(3): Fisher, M. L. (2004). The lagrangian relaxation method for solving integer programming problems. Manage. Sci., 50(12 Supplement): Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. Int. J. High Perform. Comput. Appl., 15(3): Glover, F. (1986). Future paths for integer programming and links to artificial intelligence. Comput. Oper. Res., 13(5): GLPK (2009). retrieved 25/05/2010. GPL (2009). retrieved 25/05/2010. Hadoop (2010). retrieved 06/12/2010. Hakami, S. (1963). Optimum location of switching centers and the absolute centers and medians of a graph. Operations Research, 12:

175 160 Anais Hey, T., Tansley, S., and Tolle, K., editors (2009). The Fourth Paradigm: Data-Intensive Scientific Discovery. Microsoft Research, Redmond, Washington. Holland, J. H. (1975). Adaptation in Natural and Artificial Systems. University of Michigan Press, Ann Arbor, Mich. Ishii, R. P. (2010). Optimization input output operations aiming at reduce execution time of distributed applications which handle large amount of data. PhD thesis, ICMC-USP. OpenVZ (2010). retrieved 25/05/2010. OptorSim (2009). retrieved 25/05/2010. PAN-STARRS (2010). retrieved 22/11/2010. Quagga (2010). retrieved 01/06/2010. Rahman, R., Barker, K., and Alhajj, R. (2008). Replica placement strategies in data grid. Journal of Grid Computing, 6(1): Ranganathan, K. and Foster, I. (2001). Identifying dynamic replication strategies for a high-performance data grid. In In Proc. of the International Grid Computing Workshop, pages Sato, H., Matsuoka, S., Endo, T., and Maruyama, N. (2008). Access-pattern and bandwidth aware file replication algorithm in a grid environment. In GRID, pages IEEE. Soltesz, S., Pötzl, H., Fiuczynski, M. E., Bavier, A., and Peterson, L. (2007). Containerbased operating system virtualization: a scalable, high-performance alternative to hypervisors. SIGOPS Oper. Syst. Rev., 41(3): Starfish (2009). distributed filesystem retrieved 25/05/2010. Sugerman, J., Venkitachalam, G., and Lim, B.-H. (2001). Virtualizing i/o devices on vmware workstation s hosted virtual machine monitor. In Proceedings of the General Track: 2002 USENIX Annual Technical Conference, pages 1 14, Berkeley, CA, USA. USENIX Association. Tatebe, O., Morita, Y., Matsuoka, S., Soda, N., and Sekiguchi, S. (2002). Grid datafarm architecture for petascale data intensive computing. In Proceedings of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2002), pages Tatebe, O., Sekiguchi, S., Morita, Y., and Matsuoka, S. (2003). Worldwide fast file replication on grid datafarm. In Computing in High Energy and Nuclear Physics (CHEP03. VirtualBox, S. (2010). retrieved 01/02/2010. Weil, S., Brandt, S. A., Miller, E. L., Long, D. D. E., and Maltzahn, C. (November 2006). Ceph: A scalable, high-performance distributed file system. In Proceedings of the 7th Conference on Operating Systems Design and Implementation (OSDI 06), pages

176 IX Workshop em Clouds, Grids e Aplicações 161 Proposta de Workflow para Alocação de Máquinas Virtuais Utilizando Características de Processamento Paulo Antônio Leal Rego 1,2, Emanuel Ferreira Coutinho 1,2,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 Instituto UFC Virtual Universidade Federal do Ceará Fortaleza CE Brasil Abstract. This paper describes a proposal for a workflow to handle the allocation of computing resources, specifically the processing power in heterogeneous environments, where there is a wide variety of processors on the machines of the infrastructure. The contribution aims to standardize the representation of the processing capacity in terms of what we call Processing Unit (PU), combined with the limiting of the CPU usage to provide performance isolation and maintaining the processing capability independent of the Physical Machine (PM) in what the Virtual Machine (VM) has been allocated. This work presents experiments with a focus on defining and managing the PU, which aim to assess the initial activities of the proposed workflow. Resumo. Esse artigo descreve uma proposta de workflow para tratar alocação de recursos computacionais, especificamente poder de processamento, em ambientes heterogêneos, onde existe uma grande variedade de processadores nas máquinas da infraestrutura. A contribuição visa padronizar a representação da capacidade de processamento, em termos do que chamamos de Unidade de Processamento (UP), aliado à limitação do uso da CPU para prover isolamento de desempenho e manter a capacidade de processamento independente da Máquina Física (MF) em que a Máquina Virtual (MV) foi alocada. O trabalho apresenta experimentos com foco na definição e gerenciamento da UP, que visam avaliar as atividades iniciais do workflow proposto. 1. Introdução A exigência crescente de recursos computacionais em áreas como computação científica abriu o caminho para o desenvolvimento da computação paralela e distribuída. Depois do sucesso generalizado dos clusters e a adoção mais lenta das Grades Computacionais, o modelo de Computação em Nuvem é cada vez mais adotado em soluções distribuídas [Mc Evoy et al. 2011]. Com o rápido desenvolvimento das tecnologias de processamento e armazenamento, e o grande sucesso da Internet, os recursos computacionais tornaram-se mais baratos, mais poderosos e mais ubiquamente disponíveis que antes. Esta nova tendência tecnológica tornou possível a existência da Computação em Nuvem, onde os recursos são providos sob demanda através da Internet [Zhang et al. 2010].

177 162 Anais A virtualização é uma tecnologia chave da plataforma de Computação em Nuvem, onde as aplicações são encapsuladas dentro de máquinas virtuais (MV) e estas são mapeadas dinamicamente para um conjunto de servidores físicos [Sonnek and Chandra 2009]. Os serviços em execução nas MVs são executados separadamente de todos os processos das máquinas físicas, incluindo o sistema operacional destas. Esta separação traz benefícios como segurança e portabilidade [Chen and Noble 2001]. A Computação em Nuvem aproveita da tecnologia de virtualização para alcançar o objetivo de prover recursos computacionais como deseja a Computação Utilitária. O provedor de infraestrutura pode se aproveitar das tecnologias de migração de MVs para atingir um alto grau de consolidação dos servidores, e assim, maximizar a utilização de recursos enquanto diminui os custos com energia e refrigeração [Zhang et al. 2010]. No entanto, as técnicas de consolidação e alocação dinâmica de MVs têm tratado o impacto da sua utilização como uma medida independente de localização. É geralmente aceito que o desempenho de uma MV será o mesmo, independentemente de qual máquina física (MF) ela é alocada. Esta é uma suposição razoável para um ambiente homogêneo, onde as MFs são idênticas e as MVs estão executando o mesmo sistema operacional e aplicativos. No entanto, em um ambiente de Computação em Nuvem, esperamos compartilhar um conjunto composto por recursos heterogêneos, onde os servidores físicos podem variar em termos de capacidades de seus recursos e afinidades de dados [Sonnek and Chandra 2009]. Este artigo trata o problema de prover recursos computacionais, especificamente poder de processamento, em ambientes heterogêneos, onde existe uma grande variedade entre os processadores das máquinas da infraestrutura. Será proposto um workflow que visa padronizar a representação da capacidade de processamento, denominada por Unidade de Processamento (UP), aliado à limitação do uso da CPU para prover isolamento de desempenho (performance isolation 1 ) e manter a capacidade de processamento independente da MF em que a MV tenha sido alocada. O trabalho está organizado da seguinte forma. A Seção 2 apresenta o problema tratado; a Seção 3 descreve a proposta, detalhando o modelo e apresentando as soluções para limitar o uso da CPU; a Seção 4 apresenta a metodologia de avaliação utilizada; na Seção 5 são apresentados os experimentos e a discussão dos resultados; já na Seção 6 são apresentados os trabalhos relacionados, enquanto que a Seção 7 apresenta a conclusão e trabalhos futuros. 2. Definição do Problema A maioria dos middlewares de Computação em Nuvem utiliza a quantidade de CPU e memória como unidades de escalonamento no momento de decidir em qual servidor físico as máquinas virtuais devem ser alocadas. A maneira como esses dados são representados não identificam o real poder de processamento das MFs. Podemos observar na Figura 1, a maneira como os dados são representados no middleware OpenNebula [OpenNebula 2011]. A MF representada como no3 consta com 400% de processamento livre, enquanto 1 É uma medida de quão bem as MVs visitantes estão protegidas do intenso consumo de recursos das outras MVs [Deshane et al. 2008].

178 IX Workshop em Clouds, Grids e Aplicações 163 Figura 1. Representação dos dados no middleware OpenNebula a MF representada como no4 tem 800%, mas não é possível fazer nenhuma relação entre esses valores, ou seja, não necessariamente o no4 tem o dobro do poder de processamento do no3. Como o ambiente de Computação em Nuvem é bastante heterogêneo, podemos ter máquinas com diferentes quantidades de CPU e estas podem possuir poder de processamento diferente. Essa diferença entre as CPUs pode influenciar o desempenho das MV, e consequentemente as aplicações que estiverem encapsuladas nelas. Como experimento motivacional, foi realizado um benchmark 2 em duas máquinas da infraestrutura utilizada. O benchmark Linpack foi executado numa máquina virtual com uma VCPU (CPU Virtual), 1GB de memória e sistema operacional Ubuntu Server 10.10, 64bits e kernel Esta MV foi executada em dois servidores diferentes, Servidor A e B, cujas configurações podem ser vistas na Tabela 1. Servidor A Intel Corei5-750 (8M Cache, 2.66 GHz) sem Hyper-Threading 4GB memória Ubuntu Server 10.04, 64bits Hypervisor KVM Servidor B Intel Corei7-930 (8M Cache, 2.80 GHz) com Hyper-Threading 24GB memória Ubuntu Server 10.04, 64bits Hypervisor KVM Tabela 1. Configuração das máquinas físicas O resultado 3 deste experimento foi um poder de processamento de 6,8 GFLOPS 4 para o Servidor A e 3,77 GFLOPS para o Servidor B, o que mostra que a MV executada no Servidor A obteve resultado muito superior à executada no Servidor B, causados pela diferença de servidor físico. 3. Proposta O trabalho tem como objetivo propor um workflow que descreva uma maneira de trabalhar a capacidade de processamento de MVs. O objetivo desta proposta é melhorar a representação dos dados, para que estes possam demonstrar a diferença de processamento entre MFs, e apresentar uma maneira de manter a capacidade de processamento solicitada sempre no mesmo nível, independente da MF em que a MV está alocada. A ideia é definir uma Unidade de Processamento (UP) que tenha um valor constante de GFLOPS, e representar o poder de processamento de cada MF em função dessa constante UP. 2 Os testes e benchmark serão detalhados nas seções seguintes. 3 Os gráficos desse experimento serão apresentados na Seção 5. 4 flops = operações de ponto flutuante por segundo. gigaflop = 10 9 flops.

179 164 Anais Uma vez que todas as MFs possuírem seu poder de processamento representado em função da UP, podemos alocar as MVs tendo como base a quantidade de UPs solicitada. Como o poder de processamento de uma UP no Servidor A deve ser igual ao do Servidor B, a MV terá o poder de processamento mantido, independente de onde ela for alocada, e caso haja alguma migração. Para alcançar os resultados desejados, é preciso que os hypervisors permitam uma maneira de definir a percentagem da CPU que será utilizada por uma dada MV. Entre os hypervisors mais utilizados de código aberto, temos o Xen e o KVM (Kernel-based Virtual Machine). O Xen possui esta funcionalidade implementada nativamente através do seu algoritmo de escalonamento Credit Scheduler. Utilizando esse algoritmo, para cada MV é atribuído um peso (weight) e o cap. Através destes parâmetros é possível limitar o uso da CPU e definir se o processo será com (WC-mode) ou sem (NWC-mode) conservação de trabalho. No modo com conservação do trabalho, caso a MV esteja consumindo a CPU sozinha, ela utilizará todos os recursos disponíveis e só obedecerá o limite quando outra MV estiver ativa e houver concorrência pela mesma CPU. No outro modo, mesmo que não haja concorrência pela CPU, a MV utilizará apenas o limite que foi dado [Cherkasova et al. 2007]. O KVM, que foi lançado oficialmente em 2007, ainda não possui uma solução nativa que permita limitar o uso da CPU. Apesar deste fato, as MVs criadas com KVM são processos do Linux e integram-se perfeitamente com o restante do sistema. Aproveitando disto, será proposta e avaliada uma solução utilizando a ferramenta cpulimit [Cpulimit 2011] para definir a percentagem da CPU que vai ser utilizada pela MV Workflow O workflow a seguir descreve as atividades necessárias para garantir que a capacidade de processamento requisitada para uma MV seja mantida, independente da MF em que ela esteja alocada. A Figura 2 apresenta um diagrama de atividades para o workflow proposto, de forma a facilitar a visualização e entendimento das atividades. Figura 2. Atividades do workflow proposto Atividade 1: Definir Unidade de Processamento (UP). Em termos de GFLOPS, é necessário definir um valor padrão UP, para que ele seja a referência de capacidade de processamento para as MVs. Esse valor pode representar um percentual da capacidade de processamento de uma CPU. Na seção de experimentos será

180 IX Workshop em Clouds, Grids e Aplicações 165 apresentada uma estratégia para definição do valor da UP para a infraestrutura utilizada como testbed. Atividade 2: Analisar Ambiente. Tendo a UP definida, é necessário que a capacidade de processamento de todas as MFs da infraestrutura seja definida em termos da UP. Benchmarks para a medição de GFLOPS devem ser executados nas MVs de cada MF, e o poder de processamento de cada MF será descrito em termos da UP. Com isso, deve-se ter uma padronização na representação do poder de processamento. Atividade 3: Solicitar Requisição. Cada requisição de MV deve solicitar certa capacidade de processamento em função da quantidade de UPs. Atividade 4: Escalonar Requisição. As requisições devem ser escalonadas para uma MF conforme um algoritmo de escalonamento que agora é baseado na quantidade de UPs. Atividade 5: Gerenciar Limites. Como o valor de uma UP pode representar também uma fração do valor total de uma CPU, em uma MF específica, é preciso que haja um módulo gerenciador de limitações, que aplique o limite de CPU para cada MV, logo após esta ser alocada em uma MF. Atividade 6: Migrar MV. Dependendo das requisições e das políticas de consolidação de servidores da infraestrutura, pode ser necessário que uma MV seja migrada. Para isso, sabendo-se da quantidade de UPs solicitada para esta MV, é preciso analisar a MF fonte e destino da migração e fazer os ajustes necessários no limite da CPU, através do módulo gerenciador de limitações Limitando o uso da CPU com cpulimit A ferramenta cpulimit, versão 1.1, é um programa de código aberto 5 utilizado para limitar o uso da CPU de um processo no Linux. Ele age no uso da CPU real e é capaz de se adaptar à carga total do sistema, de forma dinâmica e rápida. O trabalho do cpulimit é realizado inteiramente no espaço do usuário, de modo que ele não interfere no escalonador do Linux. O processo é continuamente interrompido e reiniciado, enviando-lhe sinais SIGSTOP 6 e SIGCONT 7. Os sinais são enviados pelo cpulimit nos momentos adequados, com base no limite especificado pelo usuário e as estatísticas do processo de leitura a partir de /proc. A Figura 3 apresenta um exemplo de execução da ferramenta cpulimit, onde a MV, cujo identificador de processo é igual a 4432, é limitada em 75% do uso de CPU. A 5 Foi necessário realizar algumas alterações no código fonte da ferramenta para que ela funcionasse corretamente em máquinas com mais de uma CPU. Com a última versão estável só é possível utilizar limites de 0-100%, mas como os processadores utilizados possuem mais de um núcleo, a ferramenta não tratava corretamente os valores de entrada. Por exemplo, ao utilizar uma MV com duas VCPUs o processamento pode atingir até o valor 200%, e não foi possível definir limites acima de 100%. Sendo assim, a utilização de 1 CPU inteira e metade de outra não era possível. Após a correção, foi possível realizar tal limitação. O código fonte com as modificações será disponibilizado seguindo a licença da ferramenta, GPLv2. 6 Nome do sinal emitido pelo sistema operacional, que faz com que um processo pare a sua execução enquanto não receber o sinal SIGCONT. 7 Nome do sinal enviado para reiniciar um processo pausado por um sinal SIGSTOP ou SIGTSTP.

181 166 Anais ferramenta, que neste exemplo foi executada em modo verbose, apresenta a quantidade de tempo em que o processo ficou ativo e dormindo. Figura 3. Exemplo de execução da ferramenta cpulimit no modo verbose 4. Metodologia de Avaliação Para avaliar a proposta apresentada, foram realizados diversos experimentos. Para isso, foram utilizados, como testbed, 4 máquinas do tipo A, 2 máquinas do tipo B (mesmas configurações apresentadas na Tabela 1), 1 Storage com 4TB de disco rígido, todos ligados a uma rede gigabit. A arquitetura pode ser vista na Figura 4. Figura 4. Infraestrutura do testbed Todas as máquinas estão conectadas ao repositório de imagens do Storage através de NFS (Network File System). Na próxima seção serão apresentados mais detalhes sobre o benchmark escolhido e, na seção seguinte, os experimentos realizados e discussão dos resultados Intel Linpack benchmark O Intel Linpack é uma generalização do benchmark Linpack Ele resolve um sistema denso de equações lineares, e mede a quantidade de tempo que leva para fatorar e resolver o sistema. Após isso, ele converte o tempo em uma taxa de desempenho e testa os resultados por precisão. A generalização 8 está no número de equações que este benchmark pode resolver, que não se limita a Ele usa pivoteamento parcial para assegurar a precisão dos resultados e estes são informados em quantidade de operações de ponto flutuante por segundo(flops), mas especificamente em termos de GFLOPS. O benchmark Linpack foi selecionado por várias razões, dentre elas: 8 Em todos os benchmarks executados, foram utilizados 7000 equações e uma matriz de dimensão 7000, como entrada.

182 IX Workshop em Clouds, Grids e Aplicações 167 Álgebra linear densa é predominante em aplicações científicas. As necessidades das aplicações para computação científica são bem diferentes das aplicações voltadas para Web, compostas principalmente por requisições a banco de dados, que tem sido o foco dos provedores de Computação em Nuvem [Napper and Bientinesi 2009, Keahey et al. 2007] Algoritmos de computação intensiva. O Linpack fornece um bom limitante superior para o desempenho esperado das cargas de trabalho científico [Napper and Bientinesi 2009] O Linpack é semelhante ao utilizado pelo TOP 500 [TOP500.Org 2011] 5. Experimentação e Discussão dos Resultados Nesta seção serão apresentados os experimentos relacionados às atividades do workflow. O Experimento 1 foi realizado para avaliar a ferramenta cpulimit. O Experimento 2 está relacionado à Atividade 1 e ao experimento motivacional. O Experimento 3 visa responder a pergunta O poder de processamento de 1 UP será mantido independente do servidor?. Já o Experimento 4, a pergunta O poder de processamento de 2 UPs é o dobro do de 1 UP? e o Experimento 5 visa responder a pergunta O poder de processamento de 2 UPs será mantido independente do servidor?. Em todos os testes, o benchmark foi executado 30 vezes em cada MV e os resultados agrupados para calcular as médias, limites inferiores e superiores, com confiabilidade de 95% Experimento 1 Este experimento visa avaliar a utilização da ferramenta cpulimit ao coletar o resultado do benchmark para a mesma MV, sujeita a limites variados de utilização de CPU. As Figuras 5 e 6 mostram a variação do poder de processamento, ao variar a fração da CPU alocada para a MV no Servidor A e B, respectivamente. As configurações dos servidores são as mesmas apresentadas na Tabela 1. Figura 5. Variação do poder de processamento para o Servidor A Figura 6. Variação do poder de processamento para o Servidor B Foram utilizados limites de 50%, 60%, 70%, 80% e 90% para analisar a tendência de crescimento dos resultados, onde é possível notar uma curva de crescimento quase linear e proporcional ao valor de limitação. Constata-se que estes resultados reforçam a escolha da ferramenta cpulimit, uma vez que esta mantém a proporção para o valor indicado.

183 168 Anais 5.2. Experimento 2 Este experimento visa auxiliar o processo de definição da UP, que é a Atividade 1 do workflow, conforme a seguinte estratégia: 4 MVs foram criadas no Servidor A e 8 MVs no Servidor B, e o benchmark foi executado em todas as MVs ao mesmo tempo. As MVs criadas tem a configuração apresentada na Tabela 2 e a quantidade de MVs para cada MF foi escolhida devido à quantidade de CPUs que as MFs possuem. Como as máquinas do tipo B possuem a tecnologia de Hyper-Threading, o sistema operacional identifica 8 CPUs, diferente das máquinas do tipo A, que não possuem essa tecnologia e apresentam 4 CPUs. VCPU 1 Memória 1Gb Sistema Operacional Ubuntu Server bits Kernel Tabela 2. Configuração da máquina virtual Para este experimento, os resultados e limites inferiores e superiores são os mesmos apresentados no experimento motivacional e podem ser vistos na Figura 7. Figura 7. Resultados em termos de GFLOPS para os Servidores A e B Uma vez definido o poder de processamento de uma MV com 1 VCPU para cada máquina da infraestrutura, conclui-se a Atividade 1 ao definir o valor da UP. Para simplificar, a UP considerada foi 3,77 GFLOPS, exatamente 100% de uma CPU do Servidor B e, aproximadamente, 55% de uma CPU do Servidor A Experimento 3 A Atividade 2 já foi parcialmente realizada devido à estratégia utilizada para definição da UP. Com os resultados do Experimento 2 foi possível definir o poder de processamento de cada MF em termos de UP. Como o Servidor A tem 4 CPUs e cada uma tem poder de processamento 6,8 GFLOPS, tem-se que esta máquina possui aproximadamente 7,2 UPs. Já o Servidor B equivale a 8 UPs, uma vez que tem 8 CPUs e cada uma delas tem poder de processamento de 3,77 GLFOPS. Estes dados foram compilados na Tabela 3. Com as Atividades 1 e 2 completas, este experimento visa responder à seguinte pergunta: - O poder de processamento de 1 UP é igual independente de MF?

184 IX Workshop em Clouds, Grids e Aplicações 169 Servidor A Servidor B CPUs 4 8 Poder de processamento para cada CPU 6,85 GFLOPS 3,77 GFLOPS Total de poder de processamento 27,4 GFLOPS 30,16 GFLOPS Total de UPs 7,2 8 Tabela 3. Resultados compilados a partir do Experimento 2 Observando a Figura 8, percebe-se que o resultado do benchmark é praticamente igual para 1 UP, independente de servidor em que a MV esteja alocada. Os limites inferiores e superiores são apresentados, com confiabilidade de 95%. Figura 8. Resultado do benchmark para avaliar se 1 UP do Servidor A equivale a 1 UP do Servidor B Este resultado era o esperado, uma vez que a ideia chave da proposta apresentada é manter o poder de processamento independente da máquina física Experimento 4 Este experimento visa avaliar a relação entre o poder de processamento de 2UPs e 1UP. Para atingir o poder de processamento de 2 UPs, uma MV com 2 VCPUs foi criada no Servidor B. As configurações das MVs são as mesmas da Tabela 2, com exceção da quantidade de VCPUs. Na Figura 9, observa-se que 2 UPs possuem o poder de processamento praticamente igual ao dobro do poder de processamento de uma UP. Os limites inferiores e superiores também são apresentados, com confiabilidade de 95%. Estes resultados eram esperados, uma vez que é percebida uma curva de crescimento quase linear nas Figuras 5 e 6, que mostra o poder de processamento para 50%, 60%,..., 90% da CPU, tanto no servidor do tipo A, quanto no servidor do tipo B. Ao definir uma UP, é garantido que independente do servidor, se houver o correto ajuste da CPU, garante-se o mesmo poder de processamento Experimento 5 Este experimento visa comparar o poder de processamento de 2 UPs no Servidor A com 2 UPs no servidor B. Foi observado que os resultados são praticamente iguais. Na Figura 10 podem ser vistos os resultados e os limites inferiores e superiores, com confiabilidade de 95%.

185 170 Anais Figura 9. Resultado do benchmark para avaliar se 2 UPs equivalem ao dobro de 1 UP Figura 10. Resultado do benchmark para avaliar se 2 UPs do Servidor A equivalem a 2 UPs do Servidor B É importante notar que, neste experimento, a MV criada no Servidor A possuía 2 VCPUs, mas limitada a 110% de processamento, uma vez que 1 UP neste servidor equivale a 55% de uma CPU. Já a MV criada no servidor B possuía 2 VCPUs e estas eram usadas completamente, seguindo a definição de UP para este servidor, realizada na Atividade Conclusão dos Experimentos Os resultados apresentados mostram que é possível utilizar a ideia proposta de definir uma Unidade de Processamento, apoiada à limitação do uso da CPU com a ferramenta cpulimit, para possibilitar que o poder de processamento permaneça no mesmo nível independente da máquina física. As atividades de criação e migração de MVs podem ser validadas com os resultados apresentados nas Figuras 8 e 10, uma vez que foi avaliada a execução do benchmark em MV alocadas em diferentes máquinas físicas e os ajustes no limite do uso da CPU foram realizados. Entretanto, essas atividades serão melhor exploradas em trabalhos futuros. Uma das vantagens dessa abordagem, é que, ao utilizar a ferramenta cpulimit, está sendo implantada uma solução sem conservação do trabalho, pois mesmo que não exista outra MV utilizando a CPU, será mantida a limitação. Esta é uma das formas de prover

186 IX Workshop em Clouds, Grids e Aplicações 171 isolamento de desempenho e garantia dos recursos. 6. Trabalhos Relacionados Há diversos trabalhos que exploram a análise de desempenho de MVs em ambientes de Computação em Nuvem, utilizando diversos benchmarks. Em [Deshane et al. 2008], os autores apresentam uma análise quantitativa do Xen e KVM, comparando o desempenho geral ao apresentar resultados de benchmarks sobre o isolamento de desempenho e escalabilidade. Os resultados quanto ao desempenho da CPU são praticamente iguais para Xen e KVM. [Iosup et al. 2008] analisaram a utilidade dos serviços de Computação em Nuvem atuais para computação científica, ao fazer testes na plataforma Amazon EC2. Eles utilizam um benchmark Linpack para avaliação. Outro trabalho que utiliza o Linpack está em [Napper and Bientinesi 2009], onde os autores investigaram se utilizando a Amazon EC2 era possível criar um cluster que tivesse poder de processamento para entrar na lista TOP 500. Outros trabalhos exploram a limitação da capacidade de processamento, como [Baruchi and Midorikawa 2008]. Este trabalho analisa a influência de algoritmos de escalonamento na vazão da rede em um ambiente virtualizado. É estudado o algoritmo Credit Scheduler do Xen para analisar sua influência sobre o desempenho do I/O da rede. [Lee et al. 2010] propõem um novo escalonador que gerencia a latência, implementado sobre o Xen, de forma que ele se torne mais adaptável para aplicações em tempo real. [Bai et al. 2010] apresentam um escalonador orientado a tarefas para um sistema de máquinas virtuais, baseado em técnicas de inferência. Todos esses trabalhos utilizaram o Xen, e manipularam o algoritmo padrão de escalonamento, Credit Scheduler, para limitar/ajustar o uso da CPU pelas MVs. Diversos trabalhos são realizados sobre o hypervisor Xen. Um trabalho que utiliza o KVM e a ideia de limitar o uso de CPU está em [Sangpetch et al. 2010]. Os autores apresentam um sistema de controle adaptativo, que automatiza a tarefa de ajustar a alocação de recursos e a manutenção dos Objetivos de Nível de Serviço (SLOs). Este trabalho foca em manter o tempo de resposta esperado para aplicações Web, onde a alocação e o limite de CPU para as MVs são ajustados constantemente através do uso da ferramenta control groups (cgroups). Apesar de haver algumas semelhanças entre este trabalho e o proprosto neste artigo, os autores utilizam uma solução diferente para realizar a limitação do uso da CPU. Outra diferença é que seu foco são as aplicações Web, então os parâmetros para ajustar o uso da CPU são diferentes dos nossos, sem contar que, com o ajuste dinâmico realizado, o isolamento de desempenho pode ser comprometido. Outros trabalhos propõem modelos para garantir a Qualidade de Serviço (QoS). [Wood et al. 2008] apresenta um modelo para estimar os recursos requisitados por uma aplicação quando elas são transferidas para um ambiente virtualizado. Seu objetivo é eliminar o processo manual, que eles julgam ser propenso a erros. O trabalho [Song et al. 2009] discute sobre um modelo para consolidação de servidores baseados em máquinas virtuais, modelando a interação entre a chegada de requisições no servidor com requisitos de QoS, e a capacidade de fluxo entre serviços simultâneos, baseado na teoria das filas, para a previsão do escalonamento de MVs no

187 172 Anais datacenter. Seu estudo de caso utilizou o Xen, e foi implementado um protótipo para a validação desse modelo através dos benchmarks TPC-W and SPECweb2005. Diversos trabalhos utilizaram diferentes benchmarks e hypervisors para testar a infraestrutura e buscar alcançar certos níveis de QoS, mas poucos trabalharam com o hypervisor KVM. Até onde foi pesquisado, nenhum outro trabalho procurou ajustar o uso da CPU a fim de garantir que o desempenho da MV, em termos de processamento, seja mantido, independente da máquina física em que ela foi alocada, e de/para onde ela foi migrada. 7. Conclusão e Trabalhos Futuros Este trabalho teve como objetivo a criação de um workflow que definisse como a capacidade de processamento poderia ser utilizada para a criação de Unidades de Processamento (UPs) e como elas seriam utilizadas para alocar a capacidade de processamento às Máquinas Virtuais (MVs), independente de qual Máquina Física (MF) elas estivessem alocadas. Durante o projeto de implementação foi identificado um problema relacionado ao KVM, que é o fato de que ele não possui uma funcionalidade nativa para limitar o uso da CPU das MVs, o que impossibilitava a criação das UPs. Foi proposta uma solução temporária para a resolução deste problema, ao utilizar a ferramenta cpulimit. Algumas das atividades do workflow foram avaliadas em laboratório, com exceção do escalonamento das requisições de MVs, e a migração de MVs, sendo estas duas atividades trabalhos futuros do projeto. A implementação do modelo e integração ao Open- Nebula, que está instalado na infraestrutura, será a validação desses dois pontos. O escalonador implementado será incorporado ao OpenNebula, para que a UP seja utilizada como unidade de escalonamento na alocação de MVs. A validação do escalonador de requisições e a avaliação da migração das MVs são trabalhos futuros relacionados ao OpenNebula. Como existem vários trabalhos semelhantes que utilizam o Xen, outro trabalho futuro será a comparação dos resultados entre Xen e KVM. Várias ferramentas foram utilizadas neste trabalho, como o cpulimit para limitar o processamento, e o Linpack como benchmark. Outros trabalhos futuros seriam a identificação e avaliação de outros utilitários para a realização dessas atividades. Salienta-se que o trabalho proposto está sendo desenvolvido no contexto do projeto INCT-MACC (Instituto Nacional de Ciência e Tecnologia - Medicina Assistida por Computação Científica)[INCT-MACC 2011], cujo GREat é um dos laboratórios associados. Agradecimentos Os autores agradecem ao projeto INCT-MACC (processo CNPq /2008-2) e à FUNCAP (Fundação Cearense de Apoio ao Desenvolvimento Científico e Tecnológico), pelo apoio financeiro.

188 IX Workshop em Clouds, Grids e Aplicações 173 Referências Bai, Y., Xu, C., and Li, Z. (2010). Task-aware based co-scheduling for virtual machine system. In Proceedings of the 2010 ACM Symposium on Applied Computing, SAC 10, pages , New York, NY, USA. ACM. Baruchi, A. and Midorikawa, E. (2008). Influência do algoritmo de escalonamento credit scheduler no desempenho de rede. In Workshop de Sistemas Operacionais (WSO), SBC Chen, P. M. and Noble, B. D. (2001). When virtual is better than real [operating system relocation to virtual machines]. In Hot Topics in Operating Systems, Proceedings of the Eighth Workshop on. Cherkasova, L., Gupta, D., and Vahdat, A. (2007). Comparison of the three cpu schedulers in xen. SIGMETRICS Perform. Eval. Rev., 35: Cpulimit (2011). Cpu usage limiter for linux. net/. Deshane, T., Shepherd, Z., Matthews, J., Ben-Yehuda, M., Shah, A., and Rao, B. (2008). Quantitative comparison of Xen and KVM. In Xen summit, Berkeley, CA, USA. USE- NIX association. INCT-MACC (2011). Instituto nacional de ciência e tecnologia - medicina assistida por computação científica. Iosup, R., Ostermann, S., Yigitbasi, N., Prodan, R., Fahringer, T., and Epema, D. (2008). An early performance analysis of cloud computing services for scientific computing. TU Delft, Tech. Rep., Dec 2008, [Online] Available. Keahey, K., Freeman, T., Lauret, J., and Olson, D. (2007). Virtual workspaces for scientific applications. Journal of Physics: Conference Series, 78(1): Lee, M., Krishnakumar, A. S., Krishnan, P., Singh, N., and Yajnik, S. (2010). Supporting soft real-time tasks in the xen hypervisor. In Proceedings of the 6th ACM SIG- PLAN/SIGOPS international conference on Virtual execution environments, VEE 10, pages , New York, NY, USA. ACM. Mc Evoy, G. V., Schulze, B., and Garcia, E. L. M. (2011). Performance and deployment evaluation of a parallel application on a private cloud. Concurrency and Computation: Practice and Experience, pages n/a n/a. Napper, J. and Bientinesi, P. (2009). Can cloud computing reach the top500? In Proceedings of the combined workshops on UnConventional high performance computing workshop plus memory access workshop, UCHPC-MAW 09, pages 17 20, New York, NY, USA. ACM. OpenNebula (2011). The open source toolkit for cloud computing. opennebula.org/. Sangpetch, A., Turner, A., and Kim, H. (2010). How to tame your vms: an automated control system for virtualized services. In Proceedings of the 24th international conference on Large installation system administration, LISA 10, pages 1 16, Berkeley, CA, USA. USENIX Association.

189 174 Anais Song, Y., Zhang, Y., Sun, Y., and Shi, W. (2009). Utility analysis for internet-oriented server consolidation in vm-based data centers. In Cluster Computing, pages Sonnek, J. and Chandra, A. (2009). Virtual Putty: Reshaping the Physical Footprint of Virtual Machines. In Proc. of Workshop on Hot Topics in Cloud Computing (Hot- Cloud 09). TOP500.Org (2011). Top 500 supercomputer sites. Wood, T., Cherkasova, L., Ozonat, K., and Shenoy, P. (2008). Profiling and modeling resource usage of virtualized applications. In Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware, Middleware 08, pages , New York, NY, USA. Springer-Verlag New York, Inc. Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. Journal of Internet Services and Applications, 1(1):7 18.

190 IX Workshop em Clouds, Grids e Aplicações 175 Aplicação de Algoritmos de Provisionamento Baseados em Contratos de Nível de Serviço para Computação em Nuvem Fernando Schubert 1, Carlos Oberdan Rolim 1, Carlos Becker Westphall 2 1 URI Universidade Regional Integrada do Alto Uruguai e das Missões Campus Santo Ângelo Av. Universidade das Missões s/n Santo Ângelo RS Brasil 2 UFSC Universidade Federal de Santa Catarina LRG Laboratório de Redes e Gerência Caixa Postal Florianópolis SC Brasil Abstract. Cloud computing came to change the way that computing is delivered and used, turning it into a utility like water or electricity. In this context, many challenges and opportunities appear to make the Cloud a stable, accessible and trustful environment. Resource provisioning in the Cloud must be dynamic and adapt itself when the needs changes. In this paper, a provisioning method is proposed using neural networks to provide the desired quality of service and assure SLA. Resumo. A computação em nuvem surgiu para mudar a forma que a computação é oferecida e utilizada, tornando a computação um serviço oferecido sob demanda como eletricidade, água, etc. Neste contexto desafios e oportunidades surgem para tornar a Nuvem um ambiente estável, acessível e confiável para seus potenciais usuários. O provisionamento de recursos na Nuvem deve ser dinâmico e atender aos requisitos dos consumidores. Propõese neste artigo um mecanismo de provisionamento dinâmico para ambientes em Nuvem, utilizando-se de máquinas de aprendizado estatísticas, através de redes neurais, obtendo-se como resultados do provisionamento as quantidades de recursos necessários para manutenção da qualidade de serviço e SLA. 1. Introdução Através da história da computação houve várias mudanças de paradigma. Dos mainframes para mini-computadores, dos mini-computadores ao micro-processamento e do micro-processamento aos computadores em rede. Enquanto as definições ainda estão em debate, fundamentalmente, computação em nuvem (cloud computing) pode ser definida como um modelo de serviços onde a informação é armazenada e processada na Internet, a Nuvem, usualmente em datacenters contendo uma grande capacidade de processamento e armazenamento, podendo ser acessado remotamente através de vários clientes e plataformas [Grimes, Jaeger e Lin 2008].

191 176 Anais Computação em nuvem tem sido comumente referenciada como um conjunto de idéias como Software como Serviço (SaaS Software as a Service, em inglês), Web 2.0, computação em grade, utilização maciça de virtualização e computação como utilidade (utility computing). Na essência, computação em nuvem é um conceito chave que busca sintetizar e encapsular este conceito de processamento e armazenamento ubíquo, mascarando dos seus usuários a real complexidade das camadas que compõem a Nuvem [Grimes, Jaeger e Lin 2008]. O modelo computacional em nuvem apresenta vários desafios e obstáculos a serem superados. Um dos mais importantes é proporcionar à Nuvem a elasticidade necessária mantendo os requisitos de qualidade de serviço (QoS) cumprindo assim os acordos de níveis de serviço (SLA Service Level Agreement) requeridos e previamente estabelecidos com clientes. A elasticidade é a capacidade da Nuvem em se auto gerir, escalonando recursos para mais ou menos de acordo com a demanda. Esta elasticidade deve ser capaz de detectar mudanças na demanda de recursos e promover o provisionamento dinâmico de infraestrutura na Nuvem. A proposta apresentada tem como objetivo o desenvolvimento de um modelo de provisionamento e alocação de recursos em ambientes de nuvem, que implementa o monitoramento e provisionamento de recursos utilizando como mecanismo de detecção e predição redes neurais artificiais. O escopo do trabalho está no mecanismo de provisionamento e sugestão de escalonamento de recursos, abstraindo-se a arquitetura complementar que se utiliza dos resultados e alimenta este sistema de predição. O trabalho está organizado da seguinte forma: na seção 2 são apresentados trabalhos relacionados à computação em nuvem, provisionamento de recursos e qualidade de serviço; a seção 3 apresenta alternativas para o provisionamento dinâmico na Nuvem; na seção 4 é proposto um modelo de predição de recursos para a computação em nuvem, baseado em SLAs; na seção 5 são apresentadas as conclusões e trabalhos futuros. 2. Trabalhos relacionados A computação em nuvem tornou-se a concretização de um objetivo buscado há muito tempo pela indústria de TI, da computação como uma utilidade. Este novo modelo tem a capacidade de mudar toda a forma de produção e implantação de software, além de guiar os rumos de como o hardware é desenvolvido e adquirido [Armbrust et al. 2009]. O advento da computação em nuvem não é um fato isolado, mas sim o êxito de várias tecnologias que têm sido combinadas para formar os ambientes computacionais em nuvem. Segundo [Foster et al. 2008] podem ser considerados três fatores principais que contribuíram para o desenvolvimento e aumento no interesse por computação em nuvem: 1) rápida redução nos custos de hardware e aumento no poder computacional e de armazenamento, o advento de tecnologias multi-core e os modernos supercomputadores constituídos de centenas de milhares de núcleos; 2) o crescimento exponencial na quantidade de dados científicos de simulação e instrumentação e aumento na publicação de dados na Internet; 3) a difusão da adoção da Web 2.0 e da arquitetura orientada a serviços.

192 IX Workshop em Clouds, Grids e Aplicações 177 Tabela 1. Níveis de serviço que a computação em nuvem é oferecida Categoria Características Tipo de Produto Vendedores e Produtos SaaS Os consumidores são providos de aplicações que são acessíveis em qualquer horário e qualquer lugar. Aplicações Web e serviços (Web 2.0 SalesForce.com (CRM), Clarizen.com (Gerenciamento de Projetos), Google Docs, Google Mail PaaS Os consumidores recebem uma plataforma para o desenvolvimento de aplicações hospedadas na Nuvem. APIs para programação e frameworks. Google AppEngine, Microsoft Azure, Manjrasoft Aneka. IaaS/HaaS Consumidores tem acesso a hardware ou armazenamento virtualizado. No topo do qual podem construir sua infraestrutura. Máquinas Virtuais, gerenciamento de infraestrutura e de armazenamento. Amazon EC2 e S3, GoGrid, Nirvanix. A computação em nuvem é oferecida em diferentes camadas ou níveis. Cada nível apresenta uma abstração em relação ao anterior, visando oferecer recursos de maneira transparente, através de interfaces definidas, ocultando aos usuários a complexidade que está incluída no modelo. As principais camadas oferecidas são as de IaaS, PaaS e SaaS. A tabela 1 [Buyya et al 2009] exibe um resumo das características dos principais níveis em que a computação em nuvem está sendo oferecida e dividida. O escopo do trabalho está na camada de infraestrutura como serviço. Amazon.com, um dos maiores provedores de ambientes de infraestrutura como serviço da atualidade [Youseff et al 2008] disponibiliza para seus usuários SLA relacionado à disponibilidade, ou seja, caso ocorram problemas de degradação de performance de processamento ou saturação da largura de banda o mecanismo de monitoramento informará o consumidor sobre o caso, sem tomar medidas de contingência proativas [Garfinkel 2007]. Eucalyptus é um framework open source de computação em nuvem focado na pesquisa acadêmica. Provê recursos para experimentos e estudo. Os usuários do Eucalyptus têm a possibilidade de inicializar, controlar e terminar máquinas virtuais integralmente [Endo et al 2009]. De acordo com [Nurmi et al. 2008] Eucalyptus proporciona um SLA baseado em regiões ou zonas, definindo o conceito de zonas, onde conjuntos de computadores com capacidades diferentes são agregados, sendo que o cliente pode definir em caso de violação do SLA migrar em tempo de execução sua instância virtual para um conjunto de recursos com maior capacidade.

193 178 Anais De acordo com [Llorente 2009], o OpenNebula é um framework para computação em nuvem, utilizado para o desenvolvimento de nuvens privadas, públicas e híbridas. Em relação aos recursos de SLA o OpenNebula possibilita o escalonamento de novas instâncias virtuais no caso de violação de SLA. Além destas soluções comerciais e científicas, existem outras técnicas, como a opacidade arquitetural (architectural translucency), proposta por [Stantchev e Malek 2006], que basicamente executa o provisionamento dinâmico a partir da replicação de componentes, criando um paralelismo na infraestrutura. Pode-se observar, que as soluções existentes proporcionam certo nível de SLA e qualidade de serviço, porém não apresentam uma granularidade que possibilite ao consumidor definir requisitos estritos de performance, capacidade e demais atributos de QoS que podem ser necessários para certos tipos de aplicação na Nuvem. Essa carência acaba conduzindo à idéia de necessidade de uma solução que seja capaz de prover os requisitos esperados pelos consumidores. Esta habilidade de prever o comportamento dos sistemas na nuvem e prever uma nova configuração para atender esta mudança será abordada nas próximas seções. 3. Alternativas para o provisionamento dinâmico de recursos Para atender a requisitos não funcionais que constituem os objetos do SLA, é necessário prover um mecanismo que possibilite avaliar o estado atual do serviço, e o volume de requisições e parâmetros de rede como latência, taxa de requisições, entre outros requisitos não funcionais e comparar estes dados com o SLA contratado. Tabela 2. Atributos de QoS Avaliando o panorama de provedores e tecnologias de infraestrutura como serviço, na seção 2, pode-se observar que a maioria das soluções prove mecanismos de SLA e qualidade de serviço, porém estes ainda não conseguem expressar a granularidade e as especificidades que os consumidores corporativos e as aplicações necessitam. Faz-se necessário, portanto, uma avaliação dos algoritmos e mecanismos de provisionamento e de qualidade de serviço.

194 IX Workshop em Clouds, Grids e Aplicações 179 A granularidade referida é a capacidade de garantir a disponibilidade e confiabilidade dos dados e serviços hospedados na nuvem. Esta granularidade corresponde aos requisitos não funcionais característicos a cada aplicação ou serviço hospedado e depende da percepção e necessidade de cada cliente consumidor da nuvem. A principal necessidade para a definição de tal algoritmo ou técnica é que este se enquadre nos requisitos de qualidade de serviço no contexto da computação em nuvem. A tabela 2 apresenta tais requisitos de qualidade de serviço necessários para um mecanismo de provisionamento dinâmico para a Nuvem. Estes requisitos foram extraídos a partir dos requisitos de SLA apontados por [Aib e Daheb 2007] como requisitos de SLA para redes IP, que podem ser aplicados para a computação em nuvem. O levantamento de algoritmos de QoS da tabela 3, foi efetuado com o objetivo de buscar alternativas que já estão consolidadas e estáveis e que possam se adequar ao modelo de computação em nuvem. Foram avaliados os algoritmos de QoS utilizados para gerenciamento de rede, congestionamento, controle de fluxos e priorização de tráfego. Além destes foram buscadas soluções utilizadas em computação em grade e também propostas para a computação em nuvem [Balen e Westphall 2011]. A escolha por redes neurais deve-se ao fato de ser a solução que mais se enquadra nos requisitos propostos devido a sua capacidade de aprendizado com base no comportamento anterior e predição de comportamento futuro. Este comportamento possibilita à nuvem um auto-controle evitando ou minimizando a ação de um administrador humano e reduzindo quebras nos contratos de SLA. Tabela 3. Avaliação de algoritmos e técnicas de QoS É notório que existem outras soluções que abrangem o gerenciamento e manutenção de SLA e QoS em ambientes de computação em grade e em nuvem e que não foram abordados. Isto se deve ao fato que a solução proposta foca no uso de redes neurais como mecanismo de predição e controle de uma arquitetura para computação em nuvem.

195 180 Anais 4. Modelo proposto Faz-se necessária a definição de um modelo que implemente o provisionamento, monitoramento e previsão de recursos para ambientes de computação em Nuvem baseado em redes neurais. Segundo [Carvalho 2009], o desenvolvimento de uma aplicação em redes neurais deve seguir as etapas de coleta de dados e separação em conjuntos, configuração da rede, treinamento, teste e integração. Figura 1. Rede neural artificial implementada pelo modelo A topologia da rede contará conforme a figura 1 com seis entradas, sendo elas os requisitos não funcionais de QoS mais os indicadores do estado do sistema representados pelo load (carga) do sistema, uso de memória e de disco. A saída da rede contará com o resultado dos volumes de memória, núcleos de processamento e disco para o provisionamento, além do valor para o SLA, este valor é representado por uma variável booleana que determina se o SLA foi violado. O cenário utilizado baseia-se em um ambiente de testes constituído por um servidor web virtual sob o virtualizador KVM, Kernel-based Virtual Machine [Kivity et al. 2007] que adiciona um monitor de máquinas virtuais (ou hypervisor) ao kernel Linux. Este servidor web por sua vez constitui-se em uma máquina virtual GNU/Linux com a distribuição Debian e com as seguintes características de hardware: Processador: 1 núcleo de 1.1 GHz Memória: 256 MB RAM Armazenamento: 8 Gb

196 IX Workshop em Clouds, Grids e Aplicações 181 Este ambiente virtual executa o servidor web Apache, e a linguagem de programação PHP. Este conjunto foi utilizado para simular um servidor web e suas requisições através da ferramenta de análise ab (apache benchmark). Com base nos relatórios obtidos foram gerados dados para alimentação da rede. A partir deste cenário foi feita a modelagem da rede neural de predição e monitoramento. As entradas da rede são os atributos de qualidade de serviço e o estado dos recursos de performance do sistema avaliado. Estes atributos que atuam sobre os recursos do sistema foram definidos levando-se em conta os valores que têm influência direta na performance e na disponibilidade do sistema. Atributos definidos como entrada da rede neural: Taxa de requisições: a taxa de requisições é a quantidade de requisições por unidade de tempo. No caso a métrica utilizada foi requisições por segundo (rps). Requisições concorrentes: é o volume de requisições simultâneas que o ambiente está recebendo em um momento. Tempo de requisição: é o tempo necessário para a requisição ser processada e exibir seu retorno. Mensurada em segundos. Consumo de memória: é o volume de memória dinâmica volátil (RAM) consumida pelas requisições no sistema em um momento específico. Exclui a memória utilizada pelo sistema operacional. Load do processador: o load de processador é o uso da capacidade de processamento. Os processos em um sistema ficam em espera ou em execução. O load representa portanto, a soma de todos os processos que estão atualmente em execução mais os processos que estão aguardando na fila de execução para serem executados. O load pode variar de 0 (sem processos rodando ou em fila) a 1.0, ou seja, a fila de execução está cheia, mas não existem processos aguardando o término de um processo para sua execução e valores maiores que 1.0 para o load significam que a fila de execução está cheia e existem processos aguardando execução. Consumo de disco: consumo em megabytes das requisições sobre o espaço de armazenamento do sistema. Após o mapeamento das entradas do sistema, faz-se necessário efetuar a definição das saídas esperadas. Com o intuito de assegurar o SLA e demonstrar o provisionamento de recursos de forma dinâmica, as saídas devem avaliar as entradas e suas saídas devem demonstrar se houve quebra ou não do SLA, e caso houver sugerir os recursos necessários para que um novo ambiente seja criado e instanciado paralelamente ao que não atende mais aos requisitos de SLA. Núcleos: determina a quantidade de núcleos de processamento que devem ser alocados para a nova instância - ou instâncias - virtuais. Memória: determina a quantidade de memória a ser alocada para o novo ambiente. Disco: informa a quantidade de disco que deve ser alocada ao novo ambiente.

197 182 Anais SLA: valor booleano (verdadeiro ou falso) que determina se o SLA foi violado (verdadeiro) ou não (falso). Uma vez definido o modelo, a próxima seção vai demonstrar quais os resultados obtidos a partir de testes que tentam simular cenários que exigem o uso de provisionamento de forma dinâmica demonstrando assim a efetividade deste trabalho. 5. Resultados Para agregar maior confiabilidade à proposta, foi desenvolvido o modelo utilizando-se o simulador de redes neurais EasyNN plus. Após a criação da rede neural na ferramenta, visualizada na figura 2 procedeu-se ao treinamento da rede com dados históricos como entrada, e hipóteses esperadas para a saída. Foi utilizado o algoritmo backpropagation, que possui uma estrutura direta multicamada com neurônios estáticos e seu aprendizado é supervisionado. Optou-se pelo algoritmo de backpropagation por ser uma solução consolidada, estável e amplamente utilizada no estudo e desenvolvimento de redes neurais. Figura 2. Rede neural no software EasyNN Os dados hipotéticos foram gerados a partir de um servidor web Apache físico executando uma aplicação web, conforme definição na seção 4. Realizou-se testes de performance com o uso da ferramenta ab Apache Benchmark, que possibilita gerar um número aleatório de requisições e retorna os tempos de resposta e custo de cada requisição. Os resultados constituem-se na análise das consultas efetuadas na rede neural após seu treinamento. O objetivo desta avaliação é observar o comportamento da rede em relação a entradas aleatórias, diferentes dos valores utilizados no treinamento. Após a finalização do treino, a rede está pronta para ser utilizada formalmente na avaliação de novas situações não previamente treinadas. Esta avaliação é o que irá

198 IX Workshop em Clouds, Grids e Aplicações 183 informar se as redes neurais podem ser utilizadas no contexto de computação em nuvem. O treinamento englobou a realização de ciclos de aprendizado, atingindo ao final do ciclo um erro de aprendizado médio de O erro resultante é proporcional aos ciclos de treinamento realizados. Um ciclo de aprendizado maior resultaria em um erro menor, o que torna a rede mais efetiva nas suas inferências. Tabela 4. Casos de Teste Após o treinamento da rede foram efetuados testes utilizando-se por base alguns cenários de teste. Estes cenários constituem-se em dados de entrada que são introduzidos nas unidades de entrada da rede, que retorna os valores de saída correspondentes ao provisionamento efetuado. A tabela 4 exibe os cenários de teste adotados e os valores desejados para a saída. Os valores dos cenários foram inseridos na ferramenta de consulta do software EasyNN para coleta dos resultados previstos pela rede. Os resultados estão presentes na tabela 5. Esta tabela apresenta os valores de saída da rede neural. Avaliando as entradas e saídas esperadas na tabela 4 e as saídas proporcionadas pela rede na tabela 5 verifica-se que as saídas não foram representativas em todos os casos. Isto indica que o período ou o conjunto de hipóteses utilizados no treinamento da rede não foram representativos para todas as possibilidades de saída. Mesmo com esta discrepância a rede previu corretamente a necessidade de provisionamento, tendo porém dimensionado os valores abaixo do que fora definido nos casos de teste. Tabela 5. Resultado da rede neural para os cenários de teste. Com base nos resultados da tabela 5, os cenários serão avaliados individualmente. O Cenário 1, não violou o SLA. Pode-se constatar que os valores

199 184 Anais esperados pela rede neural foram atingidos, sendo que a rede neural está devidamente treinada para identificar a violação ou não do SLA. Como neste caso não devem ser provisionados recursos, o resultado da rede também é válido de acordo com o esperado, ou seja, os valores ficaram em 0 ou muitos próximos disso. Os cenários 2 e 3 apontaram anomalias em relação ao resultado esperado. A validação do SLA ocorreu satisfatoriamente, sendo que nos dois casos esperava-se a quebra do contrato, o que ocorreu. Porém os valores previstos não seguiram o esperado pela definição da tabela 4. Figura 3. Gráficos de resultado do cenário de teste 2. As figuras 3 e figura 4 apresentam uma representação gráfica dos cenários de teste 2 e 3, que apresentaram violação do SLA e portanto, fizeram com que a rede neural provesse uma sugestão de alocação de recursos para atender à demanda crescente por recursos. Os conjuntos de quatro gráficos estão agrupados e representam respectivamente: o gráfico esquerdo superior representa o percentual provisionado em relação ao esperado. Considera-se 100% como o valor esperado, sendo que a previsão pode ser superior ou inferior ao esperado. Os demais gráficos mostram os recursos previstos e os recursos esperados quantitativamente.

200 IX Workshop em Clouds, Grids e Aplicações 185 Figura 4. Gráficos de provisionamento do cenário 3. Os gráficos e testes efetuados sob a rede neural apresentaram, no geral, resultados satisfatórios. O provisionamento de recursos foi efetuado, e variações no SLA detectadas. Pode-se atribuir a variação no provisionamento devido a limitações nos recursos computacionais e na coleta de dados de maior amplitude, além de possivelmente a rede necessitar de um treinamento maior e com um conjunto de dados mais abrangente. Dessa forma, os resultados demonstram que a proposta abordada mostrou-se válida, no contexto do trabalho, redes neurais podem ser uma alternativa ao provisionamento em ambientes com constante variabilidade no desempenho e com uma ampla variação nos atributos mensurados, mais estudos são necessários, com a formulação de uma arquitetura em nuvem completa, ou a integração de redes neurais às existentes para verificar a eficácia do modelo em simulações ou ambientes reais. A computação como utilidade, e a computação em nuvem por extensão podem se beneficiar do uso de redes neurais para predição do comportamento das suas instâncias.

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar David Beserra 1, Alexandre Borba¹, Samuel Souto 1, Mariel Andrade 1, Alberto Araujo 1 1 Unidade Acadêmica de Garanhuns

Leia mais

Comparativo de desempenho de um cluster virtualizado em relação a um cluster convencional sob condições equipotentes

Comparativo de desempenho de um cluster virtualizado em relação a um cluster convencional sob condições equipotentes IX Workshop em Clouds, Grids e Aplicações 3 Comparativo de desempenho de um cluster virtualizado em relação a um cluster convencional sob condições equipotentes David Willians S.C Beserra 1, Samuel Carlos

Leia mais

Implementação de Clusters Virtuais em Hosts Windows

Implementação de Clusters Virtuais em Hosts Windows Implementação de Clusters Virtuais em Hosts Windows David Beserra 1, Alexandre Borba 1, Samuel Souto 1, Mariel Andrade 1, Alberto Araújo 1 1 Unidade Acadêmica de Garanhuns Universidade Federal Rural de

Leia mais

Assembléia da Comissão Especial de Arquitetura de. Computadores e Processamento de Alto Desempenho da SBC

Assembléia da Comissão Especial de Arquitetura de. Computadores e Processamento de Alto Desempenho da SBC Assembléia da Comissão Especial de Arquitetura de Computadores e Processamento de Alto Desempenho da SBC Data: 29/10/2010 Horário início: 19:12 h Local de realização: SBAC-PAD 2011, Petrópolis, RJ, Brasil

Leia mais

Arquitetura e Sistema de Monitoramento para

Arquitetura e Sistema de Monitoramento para Arquitetura e Sistema de Monitoramento para 1 Computação em Nuvem Privada Mestranda: Shirlei A. de Chaves Orientador: Prof. Dr. Carlos Becker Westphall Colaborador: Rafael B. Uriarte Introdução Computação

Leia mais

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com Cloud Computing Andrêza Leite andreza.lba@gmail.com Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing O

Leia mais

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Márcio Parise Boufleur Guilherme Piegas Koslovski Andrea Schwertner Charão LSC - Laboratório de Sistemas de Computação UFSM - Universidade

Leia mais

Virtualização. O conceito de VIRTUALIZAÇÃO

Virtualização. O conceito de VIRTUALIZAÇÃO Virtualização A virtualização está presente tanto no desktop de um entusiasta pelo assunto quanto no ambiente de TI de uma infinidade de empresas das mais variadas áreas. Não se trata de "moda" ou mero

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines Timothy Wood, Prashant Shenoy, K.K. Ramakrishnan, Jacobus Van der Merwe VEE '11 Proceedings of the 7th ACM SIGPLAN/SIGOPS

Leia mais

EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA

EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA EUCALYPTUS: UMA PLATAFORMA CLOUD COMPUTING PARA QUALQUER TIPO DE USUÁRIO Gustavo Henrique Rodrigues Pinto Tomas 317624 AGENDA Introdução: Cloud Computing Modelos de Implementação Modelos de Serviço Eucalyptus

Leia mais

Virtualização de Sistemas Operacionais

Virtualização de Sistemas Operacionais Virtualização de Sistemas Operacionais Felipe Antonio de Sousa 1, Júlio César Pereira 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil felipeantoniodesousa@gmail.com, juliocesarp@unipar.br Resumo.

Leia mais

CloudSimDB: Um Simulador para o Provisionamento de Máquinas Virtuais para o Processamento de Aplicações Centradas em Banco de Dados *

CloudSimDB: Um Simulador para o Provisionamento de Máquinas Virtuais para o Processamento de Aplicações Centradas em Banco de Dados * CloudSimDB: Um Simulador para o Provisionamento de Máquinas Virtuais para o Processamento de Aplicações Centradas em Banco de Dados * Humberto Lima, Felipe Aragão, Jonas Lima, Flávio R.C. Sousa, José Maria

Leia mais

primeira parte da reunião: 29 de Setembro de 2013 segunda parte da reunião: 30 de Setembro de 2013

primeira parte da reunião: 29 de Setembro de 2013 segunda parte da reunião: 30 de Setembro de 2013 Ata da Reunião da Comissão Especial de Banco de Dados (CEBD) realizada durante o Simpósio Brasileiro de Banco de Dados (SBBD) 2013 na cidade do Recife, PE, Brasil primeira parte da reunião: 29 de Setembro

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Sistemas Paralelos e Distribuídos Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Conceitos preliminares Paralelismo refere-se a ocorrência simultânea de eventos em um computador Processamento

Leia mais

Coordenação Elias Procópio Duarte Jr Ronaldo Alves Ferreira

Coordenação Elias Procópio Duarte Jr Ronaldo Alves Ferreira Coordenação Elias Procópio Duarte Jr Ronaldo Alves Ferreira Organizadora José Augusto Suruagy Monteiro Lisandro Granville Zambenedetti Luciano Paschoal Gaspary Rossana Maria de Castro Andrade Avaliadora

Leia mais

Computação em Grid e em Nuvem

Computação em Grid e em Nuvem Computação em Grid e em Nuvem Computação em Nuvem Molos 1 Definição Um grid computacional é uma coleção recursos computacionais e comunicação utilizados para execução aplicações Usuário vê o grid como

Leia mais

Licenciamento de estações de trabalho Windows para Ambientes VDI

Licenciamento de estações de trabalho Windows para Ambientes VDI Microsoft VDI e Windows VDA Perguntas Frequentes Licenciamento de estações de trabalho Windows para Ambientes VDI Como a Microsoft licencia o Windows das estações de trabalho em ambientes virtuais? A Microsoft

Leia mais

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução Cluster Resumo Introdução Cluster Cluster Beowulf Curiosidades Conclução Introdução Sua empresa esta precisando fazer um grande processamento; As Nuvens existentes não são suficientes para sua empresa;

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Computação em Nuvem Introdução Centralização do processamento Surgimento da Teleinformática Década de 60 Execução de programas localmente Computadores

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Foz do Iguaçu PR Brasil luiz.baltazar@gmail.com, joao@barbosa.net.br, jorgeaikes@gmail.com

Foz do Iguaçu PR Brasil luiz.baltazar@gmail.com, joao@barbosa.net.br, jorgeaikes@gmail.com Análise de Desempenho e Viabilidade do Raspberry Pi como um Thin Client utilizando o Protocolo SPICE Luiz Alberto Alves Baltazar 1, João Paulo de Lima Barbosa 1, Jorge Aikes Junior 1 1 Curso de Ciência

Leia mais

Pesquisa e Formação de Recursos Humanos em Segurança da Informação PROF. DR. RAUL CERETTA NUNES UNIVERSIDADE FEDERAL DE SANTA MARIA

Pesquisa e Formação de Recursos Humanos em Segurança da Informação PROF. DR. RAUL CERETTA NUNES UNIVERSIDADE FEDERAL DE SANTA MARIA Pesquisa e Formação de Recursos Humanos em Segurança da Informação PROF. DR. RAUL CERETTA NUNES UNIVERSIDADE FEDERAL DE SANTA MARIA Sumário Formação em Nível Superior e sua Regulação Denominações de Cursos

Leia mais

Cluster HPC High Performance Computing.

Cluster HPC High Performance Computing. Faculdade de Tecnologia de Guaratinguetá. doze, março de 2009. Cluster HPC High Performance Computing. Diogo Salles, Thiago Pirro, Camilo Bernardes, Paulo Roberto, Ricardo Godoi, Douglas, Fauzer. Sistemas

Leia mais

Análise do Desempenho de Sistemas Operacionais Hospedeiros de Clusters Virtualizados com o VirtualBox

Análise do Desempenho de Sistemas Operacionais Hospedeiros de Clusters Virtualizados com o VirtualBox 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

Leia mais

CASE STUDY FOR RUNNING HPC APPLICATIONS IN PUBLIC CLOUDS

CASE STUDY FOR RUNNING HPC APPLICATIONS IN PUBLIC CLOUDS Universidade da Beira Interior Mestrado em Engenharia Informática Sistemas de Informação Sistemas Distribuídos e Tolerância a Falhas Apresentação de Artigo CASE STUDY FOR RUNNING HPC APPLICATIONS IN PUBLIC

Leia mais

The Eucalyptus Open-source Cloud-computing System

The Eucalyptus Open-source Cloud-computing System The Eucalyptus Open-source Cloud-computing System O sistema Open Source de nuvens computacionais Eucalyptus Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff,

Leia mais

Relatório sobre a Trilha de CSCW WebMídia 2003 Salvador BA

Relatório sobre a Trilha de CSCW WebMídia 2003 Salvador BA Organização da Trilha: Renata Mendes de Araujo UNIRIO Flávia Maria Santoro UNIRIO Comitê de Avaliação da Trilha: Ana Carolina Salgado UFPE Hugo Fuks PUC-Rio José Valdeni UFRGS - UFRJ Organização Geral

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Virtualização - Montando uma rede virtual para testes e estudos de serviços e servidores

Virtualização - Montando uma rede virtual para testes e estudos de serviços e servidores Virtualização - Montando uma rede virtual para testes e estudos de serviços e servidores Este artigo demonstra como configurar uma rede virtual para ser usada em testes e estudos. Será usado o VirtualBox

Leia mais

Expandindo uma Arquitetura para HPC em Nuvens Computacionais Utilizando Conceitos de Computação

Expandindo uma Arquitetura para HPC em Nuvens Computacionais Utilizando Conceitos de Computação Expandindo uma Arquitetura para HPC em Nuvens Computacionais Utilizando Conceitos de Computação Autonômica Emanuel F. Coutinho 1, Gabriel A. L. Paillard 1 Leonardo O. Moreira 1, Ernesto Trajano de Lima

Leia mais

Tecnólogo em Análise e Desenvolvimento de Sistemas

Tecnólogo em Análise e Desenvolvimento de Sistemas Tecnólogo em Análise e Desenvolvimento de Sistemas O conteúdo deste documento tem como objetivos geral introduzir conceitos mínimos sobre sistemas operacionais e máquinas virtuais para posteriormente utilizar

Leia mais

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva The Eucalyptus Open- source Cloud-computing System Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva Sumário Introdução Trabalhos Correlatos Eucalyptus Design Conclusões Visão Geral Introdução:

Leia mais

FTIN Formação Técnica em Informática. Sistema Operacional Proprietário Windows Prof. Walter Travassos

FTIN Formação Técnica em Informática. Sistema Operacional Proprietário Windows Prof. Walter Travassos FTIN Formação Técnica em Informática Sistema Operacional Proprietário Windows Prof. Walter Travassos Aula 01 SISTEMA OPERACIONAL PROPRIETÁRIO WINDOWS Competências do Módulo Instalação e configuração do

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

Computação em Nuvem & OpenStack

Computação em Nuvem & OpenStack Computação em Nuvem & OpenStack Grupo de Pesquisa em Software e Hardware Livre Ação Computação em Nuvem: Charles Christian Miers André Rover de Campos Glauber Cassiano Batista Joinville Roteiro Definições

Leia mais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais Computação em Nuvem Computação em nuvem: gerenciamento de dados Computação em nuvem (Cloud Computing) é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação

Leia mais

Impactos do Envelhecimento de Software no Desempenho dos Sistemas. Jean Carlos Teixeira de Araujo jcta@cin.ufpe.br

Impactos do Envelhecimento de Software no Desempenho dos Sistemas. Jean Carlos Teixeira de Araujo jcta@cin.ufpe.br Impactos do Envelhecimento de Software no Desempenho dos Sistemas Jean Carlos Teixeira de Araujo jcta@cin.ufpe.br 1 Agenda Introdução; Software Aging; Software Rejuvenation; Laboratório MoDCS Cloud; Dúvidas?

Leia mais

Belo Horizonte, 28 de setembro 2015.

Belo Horizonte, 28 de setembro 2015. Certifico que, Ademir dos Santos Ferreira, participou da palestra Logística Urbana, ministrada pelo Certifico que, Almir Junio Gomes Mendonça, participou da palestra Logística Urbana, ministrada pelo Engenheiro

Leia mais

Xen Cloud Platform Xen descomplicado

Xen Cloud Platform Xen descomplicado Xen Cloud Platform Xen descomplicado CAPA A Xen Cloud Platform facilita muito a criação e o gerenciamento de máquinas virtuais sobre o hypervisor Xen. por Boris Quiroz e Stephen Spector A revolução da

Leia mais

Extendendo Grids com gerenciamento de recursos de Cloud para computação científica

Extendendo Grids com gerenciamento de recursos de Cloud para computação científica Extendendo Grids com gerenciamento de recursos de Cloud para computação científica 1. Introdução Bruno Barcarollo Gauer 1 1 Universidade Federal do Paraná (UFPR) Curitiba PR Brazil bbg09@inf.ufpr.br A

Leia mais

Single-Chip Cloud Computer

Single-Chip Cloud Computer IME-USP Departamento de Ciência da Computação Single-Chip Cloud Computer Diogo de Jesus Pina 6798294 (diogojpina@gmail.com) Everton Topan da Silva 6514219 (everton.topan.silva@usp.br) Disciplina: Organização

Leia mais

O que é Grid Computing

O que é Grid Computing Grid Computing Agenda O que é Grid Computing Grid vs Cluster Benefícios Tipos de Grid Aplicações Ferramentas e padrões Exemplos no mundo Exemplos no Brasil Grid no mundo dos negócios Futuro O que é Grid

Leia mais

Segurança e Escalabilidade em WebLab no Domínio de Redes de Computadores

Segurança e Escalabilidade em WebLab no Domínio de Redes de Computadores Segurança e Escalabilidade em WebLab no Domínio de Redes de Computadores Autor: Daniel Vieira de Souza 1, Orientador: Luís Fernando Faina 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade

Leia mais

Proposta para Grupo de Trabalho. GT TV Grupo de Trabalho de TV Digital

Proposta para Grupo de Trabalho. GT TV Grupo de Trabalho de TV Digital Proposta para Grupo de Trabalho GT TV Grupo de Trabalho de TV Digital Guido Lemos de Souza Filho 10/09/2005 1. Título GT TV Grupo de Trabalho de TV Digital 2. Coordenador Guido Lemos de Souza Filho guido@lavid.ufpb.br

Leia mais

A SALA DE AULA é meu paraíso. Nela me realizo, nela exercito minha cidadania e nela me sinto útil.

A SALA DE AULA é meu paraíso. Nela me realizo, nela exercito minha cidadania e nela me sinto útil. Virtualização Meu nome: Nome de guerra: Meu e-mail: Marcos Vinicios Bueno Marques Professor Cidão marcos@cidao.com.br Quem sou? Professor e coordenador de cursos de TI do Senac Informática em Porto Alegre,

Leia mais

Ficha de Avaliação do Programa

Ficha de Avaliação do Programa Ficha de Ficha de do Programa Período de : 2007 a 2009 Etapa: Trienal 2010 Área de : 2 - CIÊNCIA DA COMPUTAÇÃO IES: 24001015 - UFPB/J.P. - UNIVERSIDADE FEDERAL DA PARAÍBA/JOÃO PESSOA Programa: 24001015047P4

Leia mais

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas ATIVIDADE 1 MÁQUINAS VIRTUAIS Existem hoje diversas tecnologias e produtos para virtualização de computadores e ambientes de execução, o que pode gerar uma certa confusão de conceitos. Apesar disso, cada

Leia mais

CERTIFICADO DE ATIVIDADE DE EXTENSÃO

CERTIFICADO DE ATIVIDADE DE EXTENSÃO Certificamos para os devidos que ESTEVÃO JÚNIOR participou da atividade de extensão de Simulado da OAB, promovida pelas Faculdades Kennedy de Minas Gerais, no dia 07 de outubro de 2015, com carga horária

Leia mais

Supercomputadores dominavam o mercado

Supercomputadores dominavam o mercado Clusters e Grids Introdução Supercomputadores dominavam o mercado Alto custo Requerem mão de obra muito especializada Desenvolvimento de microprocessadores poderosos a um baixo custo Desenvolvimento de

Leia mais

Corrida da Saúde. Infantis A - Feminino

Corrida da Saúde. Infantis A - Feminino Corrida da Saúde Classificação geral do corta-mato, realizado no dia 23 de Dezembro de 2007, na Escola E.B. 2,3 de Valbom. Contou com a participação dos alunos do 4º ano e do 2º e 3º ciclos do Agrupamento

Leia mais

João Víctor Rocon Maia Engenharia de Computação - UFES

João Víctor Rocon Maia Engenharia de Computação - UFES João Víctor Rocon Maia Engenharia de Computação - UFES Agenda Quem usa? Conceito Ilustração Vantagens Tipologia Topologia Como fazer? O que é preciso? Infraestrutura Sistema Operacional Software Eucalyptus

Leia mais

Modelo de simulação de um processo de requisições em um servidor web de alta disponibilidade

Modelo de simulação de um processo de requisições em um servidor web de alta disponibilidade Modelo de simulação de um processo de requisições em um servidor web de alta disponibilidade Tiago de Azevedo Santos tiago@iff.edu.br João José de Assis Rangel joao@ucam-campos.br RESUMO Este trabalho

Leia mais

PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS FRONTEIRAS EDITAL PROCAD NF 21/2009 FORMULÁRIO DE INSCRIÇÃO DE PROJETO

PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS FRONTEIRAS EDITAL PROCAD NF 21/2009 FORMULÁRIO DE INSCRIÇÃO DE PROJETO 1/20 FUNDAÇÃO CAPES DIRETORIA DE PROGRAMAS E BOLSAS NO PAÍS COORDENAÇÃO GERAL DE PROGRAMAS ESTRATÉGICOS/CGPE COORDENAÇÃO DE PROGRAMAS ESPECIAIS/CPE PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS

Leia mais

Na Terra ou nas Nuvens, onde fica o HPC?

Na Terra ou nas Nuvens, onde fica o HPC? Na Terra ou nas Nuvens, onde fica o HPC? Fábio Andrijauskas e Sidney Pio de Campos Instituto de Física Gleb Wataghin - IFGW Universidade Estadual de Campinas - UNICAMP 07/Abril/2014 3 o Cinfotec Unicamp

Leia mais

Serviço de Segurança de Middlewares

Serviço de Segurança de Middlewares Serviço de Segurança de Middlewares Autor: Célio Domingues Gonçalves 1, Orientador: Prof. Dr. Luis Fernando Faina 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Uberlândia

Leia mais

BOLETIM TÉCNICO NComputing Brasil - #110502 Instalando o Oracle Virtualbox 4.0.2 e Criando uma VM Windows Server 2008 no Virtualbox O que é virtualbox? O virtualbox é um aplicativo de virtualização multi-plataforma

Leia mais

Segurança da Informação

Segurança da Informação INF 108 Segurança da Informação Computação em Nuvem Prof. João Henrique Kleinschmidt Introdução Centralização do processamento Surgimento da Teleinformática Década de 60 Execução de programas localmente

Leia mais

Introdução. Nível do Sistema Operacional. Introdução. Um Sistema Operacional... Introdução a Sistemas Operacionais

Introdução. Nível do Sistema Operacional. Introdução. Um Sistema Operacional... Introdução a Sistemas Operacionais Introdução Nível do Sistema Operacional (Aula 14) Introdução a Sistemas Operacionais Hardware Provê os recursos básicos de computação (CPU, memória, E/S,etc.) Programas (aplicações) Definem as maneiras

Leia mais

Levantamento sobre Computação em Nuvens

Levantamento sobre Computação em Nuvens Levantamento sobre Computação em Nuvens Mozart Lemos de Siqueira Doutor em Ciência da Computação Centro Universitário Ritter dos Reis Sistemas de Informação: Ciência e Tecnologia Aplicadas mozarts@uniritter.edu.br

Leia mais

COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA

COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA CLASSIFICAÇÕES DO SEGUNDO TESTE E DA AVALIAÇÃO CONTINUA Classificações Classificação Final Alex Santos Teixeira 13 13 Alexandre Prata da Cruz 10 11 Aleydita Barreto

Leia mais

Virtualização Gerencia de Redes Redes de Computadores II

Virtualização Gerencia de Redes Redes de Computadores II Virtualização Gerencia de Redes Redes de Computadores II *Créditos: baseado no material do Prof. Eduardo Zagari Virtualização - Introdução Introduzido nos anos 60 em Mainframes Em 1980 os microcomputadores

Leia mais

Gabriel Oliveira do Nascimento Rogério Libarino Aguilar. UFF - Universidade Federal Fluminense

Gabriel Oliveira do Nascimento Rogério Libarino Aguilar. UFF - Universidade Federal Fluminense Gabriel Oliveira do Nascimento Rogério Libarino Aguilar 1 Introdução Mododelo: Hardware -> Sistema Operacional -> Aplicações Aplicação desenvolvida para um SO. Capacidade de processamento aumentando bastante

Leia mais

Desenvolvimento de um Cluster de Alto Desempenho com PVM

Desenvolvimento de um Cluster de Alto Desempenho com PVM Desenvolvimento de um Cluster de Alto Desempenho com PVM Daniel Cândido de Oliveira 1, Yzaac Gonçalves da Silva 1, Madianita Bogo 1 1 Centro Universitário Luterano de Palmas Universidade Luterana do Brasil

Leia mais

V M 2 T - Um Sistema para Auxílio na Migração de VMs em Nuvens OpenStack

V M 2 T - Um Sistema para Auxílio na Migração de VMs em Nuvens OpenStack V M 2 T - Um Sistema para Auxílio na Migração de VMs em Nuvens OpenStack Felipe Aparecido dos Santos Novais 1, Lúcio Agostinho Rocha 1, Fábio Luciano Verdi 1 1 Departamento de Computação Universidade Federal

Leia mais

4 Computação Paralela 4.1. Introdução

4 Computação Paralela 4.1. Introdução 4 Computação Paralela 4.1. Introdução Nos últimos anos observa-se uma tendência cada vez maior do aumento da demanda computacional na resolução de grandes problemas. Exemplos de aplicações que exigem alto

Leia mais

1. Relato da Coordenação do Comitê de Organização Local do SBBD 2015, Prof. Fábio Porto (LNCC) e Prof. Eduardo Ogasawara (CEFET-RJ)

1. Relato da Coordenação do Comitê de Organização Local do SBBD 2015, Prof. Fábio Porto (LNCC) e Prof. Eduardo Ogasawara (CEFET-RJ) Ata da Reunião da Comissão Especial de Banco de Dados (CEBD) realizada durante o Simpósio Brasileiro de Banco de Dados (SBBD) 2015 na cidade do Petrópolis, RJ, Brasil A reunião da CEBD realizou-se no dia

Leia mais

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS Técnico de Multimédia 10 H 7536 Alberto Filipe Cardoso Pinto 7566 Ana Isabel Lomar Antunes 7567 Andreia Carine Ferreira Quintela 7537 Bruno Manuel Martins Castro 7538 Bruno Miguel Ferreira Bogas 5859 Bruno

Leia mais

I Workhop Brasileiro de Tecnologias para Colaboração WCSCW

I Workhop Brasileiro de Tecnologias para Colaboração WCSCW I Workhop Brasileiro de Tecnologias para Colaboração WCSCW Realização: 13 e 14 de outubro em conjunto com o WebMídia-LA Web 2004 Ribeirão Preto - SP Organização do Workshop: Alberto Raposo PUC-Rio Flávia

Leia mais

MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER

MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER MINICURSO WINDOWS SERVER 2008 UTILIZANDO O VMWARE PLAYER TÁSSIO JOSÉ GONÇALVES GOMES tassiogoncalvesg@gmail.com MINICURSO WINDOWS SERVER 2008 TÁSSIO GONÇALVES - TASSIOGONCALVESG@GMAIL.COM 1 CONTEÚDO Arquitetura

Leia mais

Classificação::Modelo de implantação

Classificação::Modelo de implantação Classificação::Modelo de implantação Modelo de implantação::privado Operada unicamente por uma organização; A infra-estrutura de nuvem é utilizada exclusivamente por uma organização: Nuvem local ou remota;

Leia mais

Xen e a Arte da Virtualização

Xen e a Arte da Virtualização Xen e a Arte da Virtualização Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield University of Cambridge Computer Laboratory Microsoft

Leia mais

hvbacellar@gmail.com Palavras-chave Cluster; Beowulf; OpenMosix; MPI; PVM.

hvbacellar@gmail.com Palavras-chave Cluster; Beowulf; OpenMosix; MPI; PVM. Cluster: Computação de Alto Desempenho Hilário Viana Bacellar Instituto de Computação, Universidade Estadual de Campinas Av. Albert Einstein 1251, Cidade Universitária, CEP 13083-970 Campinas, SP, Brasil

Leia mais

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede Prof. Samuel Souza } Monolíticas Aplicações em um computador centralizado } Em Rede Aplicações com comunicação em rede } Distribuídas Comunicação e cooperação em rede } Aplicações que são funcionalmente

Leia mais

Programação. Dia 31/05 1º período do curso de Engenharia de Computação

Programação. Dia 31/05 1º período do curso de Engenharia de Computação Programação Dia 31/05 1º período do curso de Engenharia de Computação 1ª PALESTRA DO DIA: 19h As perspectivas mercadológicas na era da Tecnologia da Informação para Utilização de Software nas Empresas

Leia mais

INSTALAÇÃO PRINTERTUX Tutorial

INSTALAÇÃO PRINTERTUX Tutorial INSTALAÇÃO PRINTERTUX Tutorial 2 1. O Sistema PrinterTux O Printertux é um sistema para gerenciamento e controle de impressões. O Produto consiste em uma interface web onde o administrador efetua o cadastro

Leia mais

WSCAD. Sistemas Computacionais de Alto Desempenho. Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro. li Workshop em. Organização.

WSCAD. Sistemas Computacionais de Alto Desempenho. Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro. li Workshop em. Organização. li Workshop em Sistemas Computacionais de Alto Desempenho Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro WSCAD 2001 Organização ApOIO Universidade de Brasília Anais 11 W orkshop em Sistemas Computacionais

Leia mais

Núvem Pública, Privada ou Híbrida, qual adotar?

Núvem Pública, Privada ou Híbrida, qual adotar? Instituto de Educação Tecnológica Pós-graduação Gestão e Tecnologia da Informação - Turma 25 03/04/2015 Núvem Pública, Privada ou Híbrida, qual adotar? Paulo Fernando Martins Kreppel Analista de Sistemas

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

CLOUD COMPUTING PEDRO MORHY BORGES LEAL. MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010

CLOUD COMPUTING PEDRO MORHY BORGES LEAL. MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010 CLOUD COMPUTING PEDRO MORHY BORGES LEAL MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010 0 CLOUD COMPUTING 1 1. Introdução Com o grande avanço da tecnologia de processadores,

Leia mais

Proposta para Grupo de Trabalho. GT-Computação em Nuvem para Ciência: Armazenamento de Dados. Roberto Samarone dos Santos Araujo

Proposta para Grupo de Trabalho. GT-Computação em Nuvem para Ciência: Armazenamento de Dados. Roberto Samarone dos Santos Araujo Proposta para Grupo de Trabalho GT-Computação em Nuvem para Ciência: Armazenamento de Dados Roberto Samarone dos Santos Araujo Agosto/2011 1 Título GT-Computação em Nuvem para Ciência: Armazenamento de

Leia mais

Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS

Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS INTEGRANTES Aniel Cruz Claudio Sant Anna José Eurique Ribeiro Roberto Nou HARDWARE & SISTEMAS DISTRIBUÍDOS Clusters Conceito; Desempenho, Disponibilidade, Balanceamento

Leia mais

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores Máquinas Virtuais e Emuladores Marcos Aurelio Pchek Laureano Sistemas de Computadores Os sistemas de computadores são projetados com basicamente 3 componentes: hardware sistema operacional aplicações Sistemas

Leia mais

Reconhecimento de Dados Biométricos em Larga Escala

Reconhecimento de Dados Biométricos em Larga Escala Reconhecimento de Dados Biométricos em Larga Escala Profa. Fabíola Gonçalves Pereira Greve DCC - UFBA Departamento de Ciência da Computação Grupo de Algoritmos e Computação Distribuída http:// Equipe Profa.

Leia mais

MÁQUINAS VIRTUAIS: AVENTURE-SE SEM MEDO NO UNIVERSO GNU/LINUX *

MÁQUINAS VIRTUAIS: AVENTURE-SE SEM MEDO NO UNIVERSO GNU/LINUX * MÁQUINAS VIRTUAIS: AVENTURE-SE SEM MEDO NO UNIVERSO GNU/LINUX * Rodrigo Sacramento de Britto Almeida Instituto Federal de Educação, Ciência e Tecnologia Baiano RESUMO: Assim como os demais softwares livres,

Leia mais

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM Rogério Schueroff Vandresen¹, Willian Barbosa Magalhães¹ ¹Universidade Paranaense(UNIPAR) Paranavaí-PR-Brasil rogeriovandresen@gmail.com, wmagalhaes@unipar.br

Leia mais

Relatório de teste em Ambiente de Cluster OpenVMS

Relatório de teste em Ambiente de Cluster OpenVMS Compaq OpenVMS e Digital Networks Relatório de teste em Ambiente de Cluster OpenVMS 14 de agosto de 2001 1 Resumo executivo Testes foram realizados com equipamentos Digital Networks (DNmultilayer 1200

Leia mais

Análise de Desempenho de um SGBD para Aglomerado de Computadores

Análise de Desempenho de um SGBD para Aglomerado de Computadores Análise de Desempenho de um SGBD para Aglomerado de Computadores Diego Luís Kreutz, Gabriela Jacques da Silva, Hélio Antônio Miranda da Silva, João Carlos Damasceno Lima Curso de Ciência da Computação

Leia mais

Instituto Superior de Engenharia do Porto Administração de Sistemas Informáticos I Clusters

Instituto Superior de Engenharia do Porto Administração de Sistemas Informáticos I Clusters Instituto Superior de Engenharia do Porto Administração de Sistemas Informáticos I Clusters Trabalho elaborado por: 980368 - Sérgio Gonçalves Lima 1010949 - Nisha Sudhirkumar Chaganlal Clusters O que é

Leia mais

Soluções corporativas personalizadas com o Microsoft Exchange 2010 e o Cisco Unified Computing System (UCS)

Soluções corporativas personalizadas com o Microsoft Exchange 2010 e o Cisco Unified Computing System (UCS) Soluções corporativas personalizadas com o Microsoft Exchange 2010 e o Cisco Unified Computing System (UCS) Hoje é fundamental para as empresas poder contar com recursos de comunicação, mobilidade, flexibilidade

Leia mais

Computação em Nuvem. (Cloud Computing) Pesquisa & Desenvolvimento

Computação em Nuvem. (Cloud Computing) Pesquisa & Desenvolvimento Computação em Nuvem (Cloud Computing) Pesquisa & Desenvolvimento Santo André: 20 de fevereiro de 2013 Características de um bom Data Center Bom Desempenho Escalabilidade Alta Disponibilidade Economia Gerência

Leia mais

MESTRADOS E DOUTORAMENTOS - 2015

MESTRADOS E DOUTORAMENTOS - 2015 MESTRADOS E DOUTORAMENTOS - 2015 2ª FASE - ECT SUPLENTE EXCLUÍDO LISTA DE CANDIDATOS SERIAÇÃO CARLA MARIA CARNEIRO ALVES Doutoramento em Didática de Ciências e Tecnologias 3,9 de 5 4 CARLOS EDUARDO DOS

Leia mais

Minicurso Computação em Nuvem Prática: Openstack

Minicurso Computação em Nuvem Prática: Openstack Grupo de Pesquisa em Software e Hardware Livre André Rover de Campos Membro Colméia andreroverc@gmail.com Joinville Minicurso Computação em Nuvem Prática: Openstack Roteiro Definições Virtualização Data

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

I Seminário dos Grupos de Pesquisa da UNISC Ficha de Inscrição do Grupo de Pesquisa. Nome do Grupo: GPSEM Grupo de Projeto de Sistemas Embarcados e

I Seminário dos Grupos de Pesquisa da UNISC Ficha de Inscrição do Grupo de Pesquisa. Nome do Grupo: GPSEM Grupo de Projeto de Sistemas Embarcados e I Seminário dos Grupos de Pesquisa da UNISC Ficha de Inscrição do Grupo de Pesquisa Nome do Grupo: GPSEM Grupo de Projeto de Sistemas Embarcados e Microeletrônica Área: Sistemas de Computação Nome do Líder:

Leia mais

Relatório de Piloto Tecnológico Plataforma de Cloud Privada baseada em OpenStack Março 2015

Relatório de Piloto Tecnológico Plataforma de Cloud Privada baseada em OpenStack Março 2015 Relatório de Piloto Tecnológico Plataforma de Cloud Privada baseada em OpenStack Março 2015 Resumo Executivo: A Inok realizou uma instalação piloto para analisar as funcionalidades, características técnicas,

Leia mais