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 computação científica vem evoluindo constantemente, desde seu início com a introdução dos supercomputadores até clusters e Grids. Atualmente a computação nas nuvens (cloud computing) está surgindo como o paradigma que pretende ser a próxima geração em computação de grande escala. Cientistas podem manter suas grids e realizar a extensão para cloud visto que ela pode lhes conceder várias vantagens [1]: infraestrutura como um serviço (IaaS) eliminando a necessidade de adquirir hardware e consequentemente os custos de manutenção gerados e a deprecação conforme a lei de Moore; possibilidade de adaptação da infraestrutura conforme as necessidades pontuais; o conceito de virtualização de hardware pode representar um avanço no desenvolvimento de softwares científicos automatizados e escaláveis, além de melhorar a utilização de recursos; e por fim o fornecimento de recursos como uma forma de negócio praticamente obriga companhias a oferecerem serviços altamente confiáveis. No entanto esta extensão gera novos desafios de como realizar esta integração com os ambientes e aplicações atualmente utilizados, e também gera dúvidas quanto ao desempenho e o custo benefício deste novo modelo. Neste trabalho é demonstrada a extensão de uma aplicação de workflow em Grid para que se utilize dos recursos alugados de provedores Cloud, visto que, os vários middlewares para computação em Grid não fornecem esta possibilidade [2]. O objetivo é fornecer uma infraestrutura para que, durante a execução dos workflows na Grid, caso necessário, seja suplementada com os recursos da Cloud sob demanda. 2. ASKALON Desenvolvido na universidade de Innsbruck, é um ambiente de desenvolvimento de aplicações e computação em Grids [3]. Foi criado com o objetivo de simplificar o desenvolvimento e execução de aplicações workflow em Grids, para isto, os usuários criam as aplicações utilizando um alto nível de abstração através da linguagem AGWL (baseada em XML) que é então repassada aos serviços de middleware que faz seu agendamento e execução. A arquitetura do ambiente é composta pelos seguintes componentes/serviços [3]:
- Resource Manager: responsável pela negociação, reserva e alocação dos recursos, além de fornecer os serviços necessários para a execução das aplicações. É composto por dois componentes principais GridARM: descobre recursos de hardware e faz interface com a Grid information service [8] (arquitetura que provê informações da grid) GLARE: faz o registro e provisionamento de recursos de software, neste contexto temos o conceito de activity deployment (serviços e softwares necessários para execução de uma atividade). - Enactment Engine: fornece execução dos workflows de maneira confiável e tolerante a falhas através de técnicas de checkpointing, migração, reinício, replicação. - Performance Analysis: detecta gargalos (sincronização excessiva, comunicação, desbalanceamento das tarefas, etc.) - Performance Prediction: foca em estimar tempo de execução de atividades workflow através de métodos estatísticos baseados no serviço de análise de performance. - Scheduler: determina mapeamentos efetivos de uma ou múltiplas aplicações workflow na Grid através de heurísticas em grafos e algoritmos de otimização em cima dos serviços de predição de performance e de gerência de recursos. 3. Arquitetura de Gerência de Recursos O serviço de gerência de recursos (resource manager) do ASKALON foi estendido para usufruir dos serviços de Cloud, para isto foram adicionados três novos componentes [1]: Gerência de Cloud (Cloud Management), Catálogo de Imagens (Image Catalogue) e Mecanismos de Segurança (Security Mechanisms). Ao caso dos recursos da Grid serem exauridos, o Scheduler possui a opção de utilizar os da Cloud sendo limitado pelas propriedades das credenciais de cada provedor do serviço, isto evita que seja gasto um valor além do planejado e mantenha o provedor dentro dos seus limites de recurso.
3.1. Gerência de Cloud (Cloud Management) Estende o Resource Manager com 2 novas funcionalidades: provisionamento de recursos para uma atividade específica e a sua liberação, além disso este componente é responsável por verificar o estado de uma instância na Cloud. Os estados possíveis foram generalizados da seguinte forma [3][4][5]: Ao receber a requisição por recursos adicionais é selecionado o recurso com melhor relação preço/performance para onde é transferida a imagem contendo as atividades necessárias a serem realizadas (starting). No estado running a imagem é inicializada, enquanto no estado accessible a instância está pronta para ser usada. Quando o hardware precisa ser reconfigurado (adicionar mais cores, memória, etc.) o estado é resizing e ao reiniciar restarting. Temos ainda o estado shutting down quando a imagem está sendo desligada que ao concluir fica terminated.
Este componente também mantém uma tabela de registros com as classes de recursos (instâncias) oferecidas pelos diferentes provedores de Cloud. Foram apresentados os serviços que oferecem APIs para locação, o que permite a integração no sistema automático. 3.2. Catálogo de Imagens (Image Catalogue) Tem o objetivo de manter organizadas as imagens oferecidas pelos provedores de Cloud para que possam ser utilizadas de maneira eficaz. Algumas APIs de serviços (como o EC2 da Amazon) fornecem funcionalidades para obter a lista de imagens disponíveis, enquanto outras apenas possuem páginas HTML com estas informações. Além disso, podem faltar informações sobre arquitetura suportada, tipo de sistema operacional, etc. que podem então ser adicionadas manualmente pelo administrador da gerência de recursos ao catálogo. 3.3. Mecanismos de Segurança (Security Mechanisms) A segurança é um ponto crítico das Clouds, pois temos de tratar o tráfego de dados confidenciais (números de cartão de crédito, etc.) e também a autenticação ao serviço de Cloud e as instâncias específicas. A autenticação suportada pelos servidores é realizada através do mecanismo de chave e certificado ou login e senha. Em ambientes cloud temos dois tipos de credenciais: - Usuário: credencial persistente associada a um cartão de crédito usado na provisão liberação dos recursos. - Instância: credencial temporária utilizada para manipular uma instância pelo protocolo SSH. Como cada provedor de Cloud terá credenciais diferentes, em adição aos seus certificados Grid Security Infrastructure (GSI), o Resource Manager é responsável por gerencia-las e garantir acesso a Cloud para outros serviços e aplicações de maneira segura. O mecanismo utilizado é baseado em certificados proxy GSI [7] e foi extendido com dois
repositórios: MyCloud (armazena cópias das credenciais dos usuários e só podem ser acessadas após autenticação da credencial GSI associada a ela) e MyInstance (armazena credenciais temporárias geradas para cada instância). O funcionamento do esquema de segurança segue a imagem abaixo: 1 Uma requisição autenticada GSI por uma nova imagem é recebida 2 O componente de segurança verifica no repositório MyCloud para quais provedores o usuários possui credenciais válidas 3 Uma nova credencial é gerada para a nova instância a ser criada 4 As novas credenciais da instância são armazenadas no repositório MyImage e só estarão disponíveis para o serviço de Enactment Engine após uma correta autenticação GSI 5 Uma requisição para iniciar a instância gerada é enviada para a Cloud 6 Ao concluir a utilização da instância a credencial correspondente é removida do repositório MyInstance
4. Funcionamento da Arquitetura A nova arquitetura do Resource Manager funciona da seguinte maneira [1]: 1 Recebe uma requisição por certo número de atividades do workflow 2 O componente de segurança verifica as credenciais do requisitante e quais Clouds estão disponíveis para ele 3 O catálogo de imagens obtém as imagens registradas das Cloud acessíveis 4 As imagens são verificadas se possuem o recursos para execução das atividades (activity deployments) 5- As instâncias são iniciadas usando o componente de Gerência de Cloud e o boot da imagem é monitorado até ser possível realizar uma conexão SSH a ela, caso a instância não possua os activity deployments, um processo opcional de auto deployment utilizando o GLARE pode ser iniciado. 6 Todas atividades contidas na imagem inicializada são registradas no GLARE 7 O Resource Manager responde ao scheduler os resultados das atividades requisitadas
Referências [1] Ostermann, S.; Prodan, R.; Fahringer, T.;, "Extending Grids with cloud resource management for scientific computing," Grid Computing, 2009 10th IEEE/ACM International Conference on, vol., no., pp.42-49, 13-15 Oct. 2009 [2] J. Yu and R. Buyya, A taxonomy of scientific workflow systems for grid computing, ACM SIGMOD Rec., vol. 34, no. 3, pp. 44 49, 2005. [3] T. Fahringer, R. Prodan, R. Duan, F. Nerieri, S. Podlipnig, J. Qin, M. Siddiqui, H. L. Truong, A. Villaz on, and M. Wieczorek, Askalon: a grid application development and computing environment, in 6th IEEE/ACM International Conference on Grid Computing (GRID 2005), November 13-14, 2005, Seattle, Washington, USA, Proceedings. IEEE, 2005, pp. 122 131. [4] Amazon, Elastic compute cloud (EC2), http://aws.amazon.com/ec2/, January 2009. [5] AppNexus, http://www.appnexus.com/, January 2009. [6] GoGrid, Cloud hosting: Instant windows and linux cloud server, http://www.gogrid.com/, January 2009. [7] Globus Documentation Project, Chapter 10. GSI: Grid Security Infrastructure - 10.5. Delegation and single sign-on (proxy certificates), http://gdp.globus.org/gt4- tutorial/multiplehtml/ch10s05.html, November 2011 [8] K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman., Grid information services for distributed resource sharing, in 10th International Symposium on High Performance Distributed Computing. IEEE Computer Society Press, 2001.