GriDE

GriDE [SSP⁺03, gri06b] ´e um ambiente integrado de desenvolvimento (IDE) para computa¸c˜ao em grade que visa fornecer em uma ´unica ferramenta recursos para o de-senvolvimento, depura¸c˜ao, execu¸c˜ao e monitoramento de aplica¸c˜oes de grade. Esta ferramenta, desenvolvida no Asia Pacific Science and Technology Center da Sun Mi-crosystem, foi projetada como um m´odulo da plataforma NetBeans IDE [net06], que fornece um arcabou¸co para a cria¸c˜ao de IDEs.

As funcionalidades j´a dispon´ıveis de GriDE incluem a submiss˜ao de tarefas na grade, busca de recursos na grade e monitoramento das tarefas submetidas com recupera¸c˜ao de resultados. Al´em disso, existe ainda algumas fun¸c˜oes preliminares de um editor de workflow para a grade. Todas essas funcionalidades s˜ao realizadas atualmente basea-das no Globus, mas no futuro poder˜ao utilizar servi¸cos de outras grades. O c´odigo da implementa¸c˜ao atual ´e fechado mas promete se tornar c´odigo-aberto em breve.

Nesta se¸c˜ao vimos as principais funcionalidades dispon´ıveis nas atuais ferramentas de Computa¸c˜ao em Grade. Na categoria de ambientes para workflows, vimos a cons-tru¸c˜ao de aplica¸c˜oes usando componentes gr´aficos, que apesar de n˜ao ter ainda uma linguagem padronizada, promete crescer bastante usando pesquisas da ´area de pro-grama¸c˜ao baseada em componentes da Engenharia de Software. Vimos os PSEs, que oferecem recursos de reutiliza¸c˜ao de software para a constru¸c˜ao de aplica¸c˜oes restritas a um dom´ınio espec´ıfico. Apesar de normalmente serem dependentes de um ambiente de execu¸c˜ao, os PSEs s˜ao bastante eficientes na dissemina¸c˜ao da Computa¸c˜ao em Grade junto `a comunidade cient´ıfica. Os Portais, apesar de n˜ao atenderem a fase de cons-tru¸c˜ao das aplica¸c˜oes, s˜ao a principal ferramenta usada na intera¸c˜ao com a Grade. O ambiente web, familiar ao usu´ario, facilita o seu uso e dissemina¸c˜ao, al´em de ser muito pr´atico, pois n˜ao necessita de instala¸c˜ao. O uso dos portais personaliz´aveis que usam a tecnologia de portlets vem crescendo bastante, mostrando o sucesso dos portais junto

`a comunidade. Na ´ultima categoria apresentada, os PSAs, vimos funcionalidades es-pec´ıficas que s˜ao importantes por atenderem uma grande comunidade de usu´arios: os desenvolvedores deaplica¸c˜os param´etricas.

Por fim, vimos ferramentas interessantes que n˜ao se encaixaram em nenhuma das categorias da nossa classifica¸c˜ao. Primeiramente vimos as funcionalidades de IC2D para monitoramento e controle de aplica¸c˜oes que usam a biblioteca ProActive. Em seguida vimos os projetos GT4IDE e Gride, ambos baseados no sistema Globus e que, como o nosso projeto, usa a plataforma Eclipse para fornecer uma ambiente de desenvolvimento.

E importante salientar a diferen¸ca entre os dois: GT4IDE visa fornecer um ambiente´ para a constru¸c˜ao de servi¸cos para a Grade, e Gride fornece uma IDE para facilitar todas as fases do ciclo de desenvolvimento de aplica¸c˜oes.

Na pr´oxima se¸c˜ao descreveremos o problema que este trabalho visa solucionar, ana-lisando as dificuldades existentes para a utiliza¸c˜ao da Grade por parte dos usu´arios e desenvolvedores de aplica¸c˜oes.

4 Descri¸c˜ ao do Problema

O not´orio desenvolvimento da computa¸c˜ao em Grade deve-se principalmente ao grande interesse na utiliza¸c˜ao dos valiosos recursos oferecidos pelas Grades. V´arios esfor¸cos tˆem sido feitos para fornecer uma infra-estrutura (middleware) que disponibilize o acesso `a estes recursos. Entretanto, em virtude da complexidade computacional do ambiente, a forma de acesso aos servi¸cos oferecidos pelos middlewares ainda ´e muito complexa para o usu´ario da Grade, haja visto que este usu´ario normalmente ´e um cientista desenvolvedor de aplica¸c˜oes.

As principais necessidades dos usu´arios da Grade incluem atividades relacionadas `a constru¸c˜ao de suas aplica¸c˜oes e `a intera¸c˜ao com os servi¸cos da Grade para a submiss˜ao, monitoramento e controle, e a obten¸c˜ao dos resultados da execu¸c˜ao. Conforme visto na se¸c˜ao 3, os portais (Se¸c˜ao 3.3) fornecem ferramentas que vem atendendo cada vez melhor `a quest˜ao da intera¸c˜ao com os servi¸cos da Grade. Entretanto, os t´ıpicos portais fornecem pouco suporte ao usu´ario na constru¸c˜ao de suas aplica¸c˜oes. Os ambientes de workflow (Se¸c˜ao 3.1), por sua vez, fornecem suporte nas atividades de constru¸c˜ao das aplica¸c˜oes, mas a maioria peca pela falta de portabilidade das aplica¸c˜oes constru´ıdas nestes ambientes, que normalmente s˜ao desenvolvidas para um middleware de Grade espec´ıfico. A exce¸c˜ao a este caso ´e o projeto P-GRADE (Se¸c˜ao 3.1.1) que fornece gera¸c˜ao de c´odigo somente para o sistema Globus, mas prevˆe futuramente a gera¸c˜ao de c´odigo para GAT (Se¸c˜ao 2.7.1). Outras ferramentas como o GT4IDE (Se¸c˜ao 3.5.2) e o comercial IBM Grid Toolbox [IBM06] fornecem um ambiente de desenvolvimento, mas restrito `a constru¸c˜ao e implanta¸c˜ao de servi¸cos para a Grade. J´a o projeto Gride (Se¸c˜ao 3.5.3), apesar de fornecer ferramentas para o ciclo completo de desenvolvimento de aplica¸c˜oes, ´e espec´ıfico para o sistema Globus.

Esta carˆencia de uma ferramenta para v´arios middlewares, na qual o usu´ario dis-ponha de recursos para realizar todas as atividades que comp˜oem o ciclo completo de desenvolvimento e que permita a constru¸c˜ao de aplica¸c˜oes port´aveis, gera um cen´ario no qual este usu´ario utiliza v´arias ferramentas n˜ao integradas que atendem `a diferentes necessidades. Neste cen´ario ´e poss´ıvel encontrar usu´arios realizando tarefas de forma n˜ao automatizada (e.g. ssh). A situa¸c˜ao piora quando a mesma aplica¸c˜ao deve execu-tar em um novo middleware de Grade: al´em de ter que utilizar novas ferramentas, o usu´ario tem que reescrever sua aplica¸c˜ao para adequ´a-la ao novo ambiente de execu¸c˜ao.

Acreditamos que o f´acil acesso aos recursos da Grade unido `a portabilidade das

aplica¸c˜oes escritas para esta, s˜ao condi¸c˜oes necess´arias para a dissemina¸c˜ao desta tec-nologia junto `a comunidade de usu´arios. O usu´ario deve enxergar a Grade como se fosse uma extens˜ao do seu ambiente de computa¸c˜ao local, e pensar que vai escrever suas aplica¸c˜oes independente do ambiente de execu¸c˜ao utilizado.

5 Integrated Grid Development Environment (In-GriDE)

Neste trabalho propomos o desenvolvimento deInGriDE, um ambiente integrado de desenvolvimento (IDE) para computa¸c˜ao em Grade, que tem como objetivo facilitar as tarefas dos usu´arios da Grade em todas as etapas do ciclo de desenvolvimento de suas aplica¸c˜oes. Essas etapas incluem desde a constru¸c˜ao da aplica¸c˜ao, passando pela sub-miss˜ao na Grade, monitoramento e controle, at´e a obten¸c˜ao dos resultados da execu¸c˜ao.

Utilizaremos como estudo de caso o middleware InteGrade, desenvolvido pelo Grupo de Sistemas Distribu´ıdos do IME-USP ⁵, grupo de pesquisa no qual este trabalho est´a sendo desenvolvido. Nesta se¸c˜ao apresentaremos InGride mostrando sua arquitetura, principais componentes e as funcionalidades propostas para o ambiente.

InGriDE foi projetada levando em considera¸c˜ao dois requisitos principais: (1) o conjunto de ferramentas deve ser f´acil de usar, conforme sugerido por Foster [FK04] e (2) as aplica¸c˜oes desenvolvidas no ambiente devem ser port´aveis para diferentes mid-dlewares de Grade. Para atender ao primeiro requisito, decidimos que nossa ferramenta fornecesse as diferentes funcionalidades necess´arias para atender todo o ciclo de desen-volvimento de aplica¸c˜oes para a Grade em um ´unico ambiente. Portanto, InGriDE est´a sendo desenvolvida como uma IDE que disponibiliza os recursos necess´arios para o desenvolvimento completo de uma aplica¸c˜ao de Grade. Esta IDE est´a sendo constru´ıda baseada na plataforma Eclipse (apresentado na Se¸c˜ao 5.2), um arcabou¸co para cria¸c˜ao de IDEs que tem como preocupa¸c˜ao quest˜oes de usabilidade. O uso de Eclipse permitiu que as funcionalidades b´asicas de uma IDE fossem reutilizadas do arcabou¸co. InGriDE

´e um plugin [GB04] da plataforma Eclipse, que estende a plataforma adicionando suas funcionalidades espec´ıficas.

Para a quest˜ao da portabilidade das aplica¸c˜oes, nosso segundo requisito, construi-remos uma arquitetura na qual o modelo de portabilidade utilizado vai ser baseado na id´eia do projeto GridLab com sua API GAT (Se¸c˜ao 2.7.1). Este modelo usa GAT como uma interface de programa¸c˜ao unificada de alto n´ıvel para a Grade, que fornece a portabilidade tanto para as aplica¸c˜oes escritas quanto para as ferramentas do ambiente que interagem com o ambiente de execu¸c˜ao da Grade. Para viabilizar a nossa solu¸c˜ao

5http://gsd.ime.usp.br

em tempo h´abil, ao inv´es de utilizar GAT, criaremos uma interface que seja um sub-conjunto de GAT e que tenha mapeamento direto para o middleware que utilizaremos como estudo de caso, o InteGrade (apresentado na pr´oxima se¸c˜ao). ´E importante frisar neste caso que tentaremos utilizar ao m´aximo as interfaces (e n˜ao a implementa¸c˜ao) de GAT para minimizar o impacto de um futuro encaixe de InGriDE em GAT. Uma descri¸c˜ao mais detalhada desta integra¸c˜ao ´e feita na se¸c˜ao 5.5.

As funcionalidades fornecidas por InGriDE normalmente est˜ao relacionadas `a tare-fas de constru¸c˜ao das aplica¸c˜oes ou `a intera¸c˜ao com a Grade. Para os usu´arios da Grade que n˜ao s˜ao desenvolvedores de aplica¸c˜ao e tem interesse apenas na intera¸c˜ao com os servi¸cos da Grade, nem sempre a utiliza¸c˜ao de uma IDE completa ´e a melhor interface com a Grade. Para atender estes usu´arios, e os pr´oprios desenvolvedores quando inte-ressar, pretendemos desenvolver algumas funcionalidades b´asicas em uma interface web usando o portal GridSphere. Para fazer isso teremos que criar portlets espec´ıficos para o middleware InteGrade.

5.1 InteGrade

InteGrade [GKG⁺04] ´e uma infra-estrutura de middleware para a grade com foco na reutiliza¸c˜ao de recursos computacionais ociosos de computadores pessoais. O objetivo de InteGrade ´e permitir que o poder computacional ocioso de computadores comuns compartilhados seja utilizado em tarefas de computa¸c˜ao de alto desempenho. A ar-quitetura permite que organiza¸c˜oes possam se beneficiar do poder computacional do hardware j´a existente. Isso ´e obtido com a integra¸c˜ao de esta¸c˜oes de trabalho e recursos de laborat´orios compartilhados, em uma grade computacional de intranet ou Internet.

Esse sistema de computa¸c˜ao em grade vem sendo desenvolvido por cinco universida-des brasileiras: IME-USP, DCT-UFMS, DI-PUC-Rio, UFMA e UFG. Diferentemente dos sistemas de computa¸c˜ao em grade existentes, InteGrade est´a baseado em uma mo-derna tecnologia de interliga¸c˜ao de objetos distribu´ıdos (CORBA) [OMG02], que ´e um padr˜ao da ind´ustria para sistemas de objetos distribu´ıdos. O uso desta tecnologia traz ao Integrade duas vantagens: a primeira ´e a interoperabilidade entre diferentes lingua-gens de programa¸c˜ao, obtida atrav´es das interfaces IDL de CORBA; e a segunda ´e a reutiliza¸c˜ao de uma s´erie de servi¸cos como Servi¸co de Nomes, Trading, Transa¸c˜oes e Persistˆencia. A interoperabilidade permite que os componentes do InteGrade se co-muniquem mesmo sendo escritos em diferentes linguagens de programa¸c˜ao. O uso dos servi¸cos de CORBA pelo InteGrade ajuda a diminuir a complexidade do sistema e o custo de manuten¸c˜ao.

Um importante requisito do InteGrade, ´e que os usu´arios que decidam compartilhar suas m´aquinas na grade nunca devem perceber perda na qualidade de servi¸co oferecida por suas aplica¸c˜oes. Desta forma, o middleware deve garantir que as aplica¸c˜oes de

terceiros executando nos recursos cedidos n˜ao atrapalhem o propriet´ario. Este requi-sito pode levar a um cen´ario no qual uma aplica¸c˜ao de terceiro que esteja rodando em uma m´aquina, tenha que parar sua execu¸c˜ao para a disponibiliza¸c˜ao dos recursos para o uso de seu propriet´ario. Para tal cen´ario dinˆamico InteGrade provˆe um mecanismo de checkpointing [CGKG04] que garante o progresso da aplica¸c˜ao atrav´es do armaze-namento de seus estados em dados momentos (checkpoints). Com isso, uma aplica¸c˜ao interrompida pode retomar a execu¸c˜ao a partir de seu ´ultimo checkpoint.

Em um ambiente dinˆamico como esse, torna-se dif´ıcil o agendamento de execu¸c˜ao das aplica¸c˜oes de forma a evitar situa¸c˜oes como a descrita no par´agrafo anterior. Para minimizar este problema, a arquitetura do InteGrade utiliza um componente para coleta e an´alise de padr˜oes de uso. Esse componente funciona atrav´es da coleta de longas s´eries de informa¸c˜oes de uso dos recursos das m´aquinas da grade e, baseado nessas informa¸c˜oes, s˜ao feitas an´alises para detec¸c˜ao de padr˜oes de uso. Isso possibilita a determina¸c˜ao da probabilidade de um n´o ocioso tornar-se ocupado. Essas informa¸c˜oes sobre os recursos ajudam o escalonador de aplica¸c˜oes a melhorar a sua capacidade de decis˜ao de onde alocar uma tarefa a ser executada. Entretanto, conv´em lembrar que esse mecanismo fornece apenas dicas, e de maneira alguma representa uma garantia de que o recurso estar´a ocupado ou ocioso.

Apesar de v´arias tipos de aplica¸c˜oes poderem se beneficiar de sistemas de com-puta¸c˜ao em grade, s˜ao as aplica¸c˜oes paralelas que se beneficiam mais. Em virtude de sua natureza de utilizar v´arios recursos simultaneamente, esse tipo de aplica¸c˜ao pode tirar maior proveito do ambiente de grade. Normalmente essas aplica¸c˜oes s˜ao execu-tadas em ambientes de recursos dedicados, mas o InteGrade possibilita que elas sejam executadas em v´arios recursos compartilhados. No entanto, em um ambiente no qual os n´os que executam as aplica¸c˜oes podem tornar-se indispon´ıveis a qualquer momento, ´e necess´ario que o estado da aplica¸c˜ao seja salvo para uma poss´ıvel retomada de execu¸c˜ao.

Nesse contexto, fica dif´ıcil manter o estado de aplica¸c˜oes paralelas pela dificuldade ge-rada pela poss´ıvel troca de mensagens entre os v´arios n´os da aplica¸c˜ao. Para solucionar este problema, InteGrade usa o modelo de programa¸c˜ao paralela BSP [Val90], que imp˜oe sincroniza¸c˜oes peri´odicas entre os n´os da aplica¸c˜ao permitindo retomadas de est´agios anteriores de execu¸c˜ao em caso de falhas.