A arquitetura BioNimbus ´e projetada de forma que atenda os objetivos, e cumpra os requisitos de uma federa¸c˜ao de nuvens computacionais, listados na Se¸c˜ao 2.2. Al´em disso, a proposta ´e diferente das arquiteturas apresentadas na mesma Se¸c˜ao.
4.4.1
Requisitos Atendidos
Na arquitetura BioNimbus, os objetivos de alcan¸car a impress˜ao de recursos ilimitados, de permitir a elimina¸c˜ao da dependˆencia de ´unico provedor, e de otimizar o uso de recursos dos provedores federados, s˜ao atingidos por meio da cria¸c˜ao de uma rede P2P de diversos provedores, com o gerenciamento destes por parte dos servi¸cos controladores da federa¸c˜ao. Com isso, tem-se uma uni˜ao de recursos computacionais, oferecidos por diversos provedo- res, que permitem sua utiliza¸c˜ao por parte de todos os provedores e por parte de usu´arios externos que tenham acesso `a federa¸c˜ao, sendo poss´ıvel a distribui¸c˜ao desse uso entre seus membros.
Com o Discovery Service, ´e cumprido o requisito de automatismo na identifica¸c˜ao das nuvens que comp˜oem a federa¸c˜ao. Isso porque ele monitora os membros da rede P2P, sua entrada e sa´ıda, e tamb´em faz requisi¸c˜oes para identificar os recursos e aplica¸c˜oes dispon´ıveis neles. Assim, de maneira transparente e autom´atica, o servi¸co constr´oi uma vis˜ao geral da federa¸c˜ao, que pode ser consultada por todos seus membros.
Por meio do uso combinado do Scheduling Service, do Storage Service e do Monitoring Service, a arquitetura ´e capaz de cumprir os requisitos de previs˜ao de carga de aplica¸c˜oes e mapeamento de servi¸cos a recursos. As escolhas de distribui¸c˜ao de processamento e de armazenamento realizadas pelos dois primeiros servi¸cos podem ser baseadas nas informa- ¸c˜oes sobre tempo de execu¸c˜ao, localiza¸c˜ao de dados e carga de utiliza¸c˜ao de recursos, entre outras, recolhidas durante o tempo pelo Monitoring Service. Essas informa¸c˜oes podem ser organizadas de tal forma que seja poss´ıvel criar uma combina¸c˜ao aplica¸c˜ao-localiza¸c˜ao de dados-infraestrutura possivelmente adequada para cada escolha.
Finalmente, a utiliza¸c˜ao do Security Service e dos plug-ins de integra¸c˜ao permitem `a arquitetura construir um modelo de seguran¸ca interoper´avel, j´a que o servi¸co cria uma pol´ıtica geral para a federa¸c˜ao, mas que respeita as diversas pol´ıticas particulares de cada uma das nuvens.
4.4.2
Compara¸c˜ao com Outras Propostas
`
A semelhan¸ca das demais propostas da Se¸c˜ao 2.2, a arquitetura aqui apresentada prevˆe um componente que esteja localizado dentro da infraestrutura das nuvens que s˜ao membros da federa¸c˜ao, que neste caso ´e o plug-in de integra¸c˜ao. Contudo, sua fun¸c˜ao ´e coletar dados sobre a nuvem, como recursos, aplica¸c˜oes e pol´ıticas pr´oprias, e apresent´a-las `a federa¸c˜ao em formato padr˜ao, e tamb´em oferecer uma interface para a utiliza¸c˜ao desses recursos e aplica¸c˜oes, baseadas em suas pol´ıticas. N˜ao ´e sua fun¸c˜ao executar servi¸cos de
escalonamento e descobrimento, ao contr´ario das outras propostas. Essa escolha foi feita pois procurou-se dar uma vis˜ao ´unica a todos os membros da federa¸c˜ao com o objetivo de evitar conflitos ou escolhas baseadas em dados diferentes, que poderiam gerar, por exemplo, um balanceamento de carga ineficiente.
Al´em disso, a escolha acima foi tomada pois na arquitetura BioNimbus o usu´ario n˜ao interage diretamente com uma das nuvens, mas utiliza um servi¸co de intera¸c˜ao previsto pela arquitetura, como tamb´em acontece com a proposta de Buyya et al. [15]. A inten¸c˜ao ´
Cap´ıtulo 5
Estudo de Caso
Neste cap´ıtulo, ´e descrito o estudo de caso realizado como prova de conceito para a ar- quitetura BioNimbus. Nele foram federados diferentes provedores de servi¸co, privados e p´ublicos, para realizar uma federa¸c˜ao de provedores de aplica¸c˜oes de bioinform´atica. Os provedores s˜ao detalhados na Se¸c˜ao 5.1. Com esta federa¸c˜ao, foi executado um workflow de bioinform´atica com ferramentas e dados reais, descrito na Se¸c˜ao 5.2. A federa¸c˜ao foi constru´ıda por meio de um prot´otipo da arquitetura BioNimbus, detalhado na Se¸c˜ao 5.3. O prot´otipo cont´em os servi¸cos controladores principais para execu¸c˜ao de workflows: Dis- covery, Storage, Monitoring e Scheduling. Ademais, foram utilizados plug-ins de integra- ¸c˜ao implementados tamb´em durante este trabalho. A intera¸c˜ao, no estudo de caso, ´e feita por meio de uma linha de comando. Finalmente, a comunica¸c˜ao foi feita por meio da implementa¸c˜ao de um m´odulo de mensageria com uma camada de roteamento acima para a constru¸c˜ao de redes P2P, detalhado na Se¸c˜ao 5.4. A discuss˜ao sobre os resultados do estudo de caso ´e feita na Se¸c˜ao 5.5.
5.1
Ambiente de Execu¸c˜ao
Para o estudo de caso, foram utilizados dois clusters distintos:
• Na Universidade de Bras´ılia, um cluster Hadoop [36] foi implementado com trˆes m´aquinas, cada uma possuindo um processador Intel Core 2 Duo com 2.66GHz de frequˆencia, 4 gigabytes de mem´oria RAM e sistema operacional Linux, distribui¸c˜ao Ubuntu 11.10. No total, o cluster possui seis n´ucleos (cores) de processamento e 565 gigabytes de armazenamento. O armazenamento foi implementado por meio do Hadoop Distributed Filesystem (HDFS) [13]. As aplica¸c˜oes de bioinform´atica executam no cluster utilizando o modo streaming do Hadoop MapReduce [23]. • Na infraestrutura da Amazon Elastic Compute Cloud (EC2) [57] tamb´em foi imple-
mentado um cluster Hadoop. Foram utilizadas cinco m´aquinas virtualizadas, cada uma com processador Intel Xeon com 2.27GHz de frequˆencia, 8 gigabytes de me- m´oria RAM e sistema operacional Linux, distribui¸c˜ao Fedora 8. Uma das m´aquinas servia como controladora do cluster, enquanto as demais eram n´os trabalhadores. O cluster totalizava ent˜ao oito n´ucleos de processamento, com 1,6 terabytes de ar- mazenamento. O armazenamento e a execu¸c˜ao das aplica¸c˜oes se deram nos mesmos moldes do cluster da UnB.