Introducao a Grades de Computadores e ao Middleware Integrade

Francisco Jos da Silva e Silva1 , Alexandre C sar Tavares Vidal1 e e Universidade Federal do Maranh o a Departamento de Inform tica a Av dos Portugueses, Campus do Bacanga, s/n, 65085-580, S o Lus, MA, Brasil a
{fssilva,vidal}@deinf.ufma.br
1

Abstract. A computer Grid is a computational system that coordinates distributed resources through standard protocols and interfaces, allowing the integration and sharing of computing resources, such as computational power, software, data, and peripheral devices in corporate networks and among them, stimulating the collaboration between users and organizations. The computer Grid technology receives nowadays great attention from both academic and industrial worlds, becoming an attractive alternative for the execution of a wide range of applications on several areas, such as computational biology, image processing and storage, time prevision, and economy simulations. This paper aims to present the main concepts related to the Grid computing eld and to describe the Integrade middleware, a free software infrastructure that allows the establishment of opportunistic grids. This middleware is been developed by the following Brazilian academic institutions: USP, PUC-Rio, UFMA, UFMS, and UFG. Resumo. Uma Grade de Computadores e um sistema que coordena recursos distribudos, utilizando protocolos e interfaces padr es de forma a permitir a o integracao e compartilhamento de recursos computacionais como, por exem plo, poder computacional, softwares, dados e perif ricos em redes corporatie vas e entre elas, fomentando a colaboracao entre usu rios e organizacoes. A a tecnologia de Grades de Computadores recebe hoje grande atencao por parte tanto da academia quanto da ind stria por ter se rmado como uma alternau tiva atraente para a execucao de uma grande variedade de aplicacoes nas mais variadas areas como biologia computacional, processamento e armazenamento de imagens, previs o do tempo e simulacoes de mercado. Este artigo tem por a objetivos apresentar os principais conceitos relacionados a tecnologia de Gra` des de Computadores e descrever o middleware Integrade, uma infra-estrutura de software livre que permite o aproveitamento de recursos ociosos para a estabelecimento de Grades de Computadores desenvolvido em parceria pela USP, PUC-Rio, UFMA, UFMS e UFG.

1. Introducao a Grades de Computadores

Atualmente, ramos de atividades cientcas, comerciais e industriais como biologia, pro cessamento de imagens para diagn stico m dico, previs o do tempo, fsica de alta energia, o e a previs o de terremotos, simulacoes mercadol gicas, prospeccao de petr leo e computacao a o o

gr ca, t m demandado por grande capacidade de processamento, compartilhamento de a e dados e colaboracao entre usu rios e organizacoes. Por m, alternativas tradicionais para a e a realizacao de computacao de alto desempenho, como o uso de supercomputadores ou de aglomerados de computadores como clusters Beowulf, requerem altos investimentos em hardware e software, podendo chegar a custar centenhas de milhares de d lares. o Por outro lado, redes de computadores existentes em instituicoes tanto p blicas u quanto privadas formam hoje um enorme parque computacional interconectado princi` palmente por tecnologias ligadas a Internet. No entanto, apesar de permitir comunicacao es entre computadores, as tecnologias que comp em a Internet atual e troca de informaco o n o disponibilizam abordagens integradas que permitam o uso coordenado de recursos a pertencentes a v rias instituicoes na realizacao de computacoes. Uma nova abordaa gem, denominada computacao em grade (grid computing) [Foster and Kesselman 1999, Buyya 2002], tem sido desenvolvida com o objetivo de superar esta limitacao. Grade, em um nvel conceitual, e um tipo de sistema paralelo e distribudo que possibilita o compartilhamento, selecao, e agregacao de recursos aut nomos geograca o mente distribudos em tempo de execucao, dependendo de sua disponibilidade, capaci dade, desempenho, custo, e requisitos de qualidade de servico de usu rios [Buyya 2002]. a A computacao em grade permite a integracao e o compartilhamento de computa dores e recursos computacionais, como software, dados e perif ricos, em redes corporatie vas e entre estas redes, estimulando a cooperacao entre usu rios e organizacoes, criando a ambientes din micos e multi-institucionais, fornecendo e utilizando os recursos de maa neira a atingir objetivos comuns e individuais [Baker et al. 2000, Foster et al. 2001]. A origem do termo Grid Computing deriva de uma analogia com a rede el trica (Power e Grid), e reete o objetivo de tornar o uso de recursos computacionais distribudos t o a simples quanto ligar um aparelho na rede el trica. e O middleware1 de grade e o componente de software central de um sistema de grade, sendo respons vel pela integracao dos recursos distribudos, de modo a criar a um ambiente unicado para o compartilhamento de dados, recursos computacionais e execucao de aplicacoes. O compartilhamento multi-institucional e din mico proposto pela computacao em a grade deve ser, necessariamente, altamente controlado, com provedores de recursos e con sumidores denindo claramente e cuidadosamente o que e compartilhado, a quem e permitido compartilhar, e as condicoes sob as quais ocorre o compartilhamento. Ian Foster et. al [Foster et al. 2001], conceituam os grupos formados por indivduos e/ou organizacoes que comp em esses ambientes din micos e multi-institucionais como Organizacoes Viro a tuais (OV). Existem atualmente muitas aplicacoes para a computacao em grade. Ian Foster e Carl Kesselman [Foster and Kesselman 1999] identicaram as cinco principais classes de aplicacoes para grades de computadores: supercomputacao distribuda, alto rendimento, computacao sob demanda, computacao intensiva de dados e computacao colaborativa.
middleware e uma camada de software que reside entre o sistema operacional e a aplicacao a m de facilitar o desenvolvimento de aplicacoes, escondendo do programador diferencas entre plataformas de hardware, sistemas operacionais, bibliotecas de comunicacao, protocolos de comunicacao, formatacao de dados, linguagens de programacao e modelos de programacao.
1

Estas classes de aplicacoes s o apresentadas na Tabela 1. a Categoria Supercomputacao tribuda Alto rendimento Caractersticas Grandes problemas com intensiva necessidade de CPU, mem ria, etc. o Agregar recursos ociosos para aumentar a capacidade de processamento. A grade e utilizada para executar uma grande quantidade de tarefas independentes ou fracamente acopladas. Recursos remotos integrados em computacoes lo cais, muitas vezes por um perodo de tempo limitado Sntese de novas informacoes de muitas ou grandes fontes de dados ` Suporte a comunicacao ou a trabalhos colaborativos entre v rios participantes a Exemplos Simulacoes interativas dis tribudas, cosmologia, mo delagem clim tica a Projeto de chips, problemas de criptograa, simulacoes moleculares

dis-

Computacao sob demanda

Instrumentacao m dica, e processamento de imagens microsc picas o Experimentos de alta energia, modernos sistemas meteorol gicos o Educacao, projetos colabo rativos

Computacao intensiva de dados Computacao colaborativa

Tabela 1. Cinco maiores classes de aplicacoes de grades

1.1. Desaos para Construcao de um Middleware de Grade Para que a computacao em grade se torne realidade, um middleware que atenda a diversos requisitos deve ser desenvolvido, entre os quais se destacam: Heterogeneidade de plataformas de hardware: um sistema de computacao em grade pode, eventualmente, lidar com recursos heterog neos, necessitando fore necer mecanismos que tratam essa diversidade de plataformas; Interoperabilidade: uma infraestrutura de grade de computadores deve seguir padr es na construcao de suas interfaces, de forma a fomentar a interoperabilio dade entre os middlewares de grade e o objetivo de integracao em escala global; Custo reduzido: o uso de grade deve se constituir em meio alternativo aos altos custos de hardware de alto desempenho e software; Gerenciamento de recursos: mecanismos que possibilitem o controle de recursos e monitoramento s o essenciais para a alocacao correta de acordo com rea quisitos pr -estabelecidos, balanceamento e escalonamento de tarefas para grade e [Goldchleger et al. 2002]; Qualidade de servico: com uso colaborativo da grade, deve ser garantido que propriet rios de estacoes de trabalho n o tenham suas aplicacoes afetadas devido a a ` as aplicacoes da grade que executam em seus recursos. O eventual uso comer cial da grade deve ser negociado por meio de Service Level Agreement (SLA)

entre usu rios e provedores de servico para garantir nveis adequados de custo e a prestacao de servico [Menasc and Casalicchio 2004]; e Servicos de informacao: informacoes sobre a estrutura e o estado dos recursos (conguracao, disponibilidade, carga de trabalho, e polticas de uso) s o essen a cias para o gerenciamento dos mesmos, dado que estas informacoes permitem aos gerenciadores de recursos aloc -los de maneira mais eciente; a Polticas de seguranca: devido aos recursos computacionais encontrarem-se em diversos domnios administrativos, eventualmente, existem v rias polticas de a seguranca. Assim, a infra-estrutura de grade deve tratar quest es de integracao o de polticas de seguranca locais, mapeando identidades e autorizacoes, provendo acesso autenticado e con vel, bem como garantindo privacidade e a autonomia a administrativa local; Toler ncia a falhas: tratar falhas em grades e bastante complexo, visto que as graa des agregam uma enorme quantidade de componentes de hardware e software, eventualmente heterog neos, que fazem a probabilidade de falhas aumentar proe porcionalmente ao tamanho do sistema, bem como diculta a identicacao da origem da falha.

2. Taxonomia dos Sistemas de Grade

Krauter et al. [Krauter et al. 2002] prop em uma taxonomia para sistemas de grades de o computadores ilustrada na Figura 1, cujos componentes s o descritos a seguir. a

Figura 1. Taxonomia dos sistemas de grade

Grade Computacional (Computing Grid): e um sistema de computacao em grade que objetiva prover maior capacidade computacional atrav s da agregacao de e recursos computacionais distribudos. Como exemplo de classes de aplicacoes temos: supercomputacao distribuda, cujas aplicacoes usam grades computaci onais para agregar recursos computacionais substanciais para resolver proble mas que n o poderiam ser resolvidos por um unico sistema como, por exemplo, a aplicacoes para planejamento e treinamento militar atrav s de simulacoes interati e vas distribudas e simulacao precisa de processos fsicos complexos; modelagem clim tica; alto rendimento, onde a grade e usada para escalonar grande n mero a u de tarefas independentes ou fracamente acopladas, com o objetivo de utilizar ciclos de processadores ociosos como, por exemplo, a resolucao de problemas crip togr cos; a Grade de Servicos (Service Grid): prov servicos viabilizados pela integracao de e diversos recursos computacionais. Exemplos de classes de aplicacoes s o: a

 Computacao sob demanda: aplicacoes usam as capacidades da grade por perodos curtos de acordo com solicitacoes por recursos como, por exem plo, aplicacoes de instrumentacao m dica e requisicoes de utilizacao de e software especializado por usu rios remotos; a Computacao colaborativa: aplicacoes que utilizam a grade para dar apoio a trabalhos cooperativos envolvendo diversos participantes, como, por exemplo, em projetos colaborativos e educacao; Multimdia: a grade prov a infra-estrutura para aplicacoes multimdia em e tempo real. Grade de Dados (Data Grid): e um sistema de computacao em grade que ob jetiva prover mecanismos especializados para publicacao, descoberta, acesso e classicacao de grandes volumes de dados distribudos. A computacao inten siva de dados cujo foco est na sntese de novas informacoes de dados que s o a a mantidos em reposit rios, bibliotecas digitais e bancos de dados geogracamente o distribudos s o exemplos de grade de dados. a

3. Principais Middlewares de Grade

A partir do nal da d cada de 90, a computacao em grade tem obtido crescente espaco e entre pesquisadores da area de computacao distribuda. Existem atualmente diversos ` projetos relacionados a computacao em grade, com diferentes objetivos, aspectos de implementacao e modelos de aplicacoes suportadas. Esta secao descreve relevantes pro jetos de computacao em grade. 3.1. Globus O Globus2 [Foster and Kesselman 1999, Foster et al. 2001] e o projeto de computacao em grade com maior relev ncia na atualidade. E desenvolvido pela Globus Alliance, a um grupo formado por in meras instituicoes ao redor de todo o mundo, cujos principais u respons veis s o o Laborat rio Nacional Argonne, o Instituto de Ci ncias da Informacao a a o e da Universidade do Sul da Calif rnia, a Universidade de Chicago, a Universidade de o Edimburgo, o Centro Sueco de Computacao Paralela, o Centro Nacional de Aplicacoes de Supercomputacao (NCSA) e o Laborat rio de Alto Desempenho da Universidade do o Norte de Illinois. Al m disso, a Globus Alliance conta tamb m com o apoio de v rias e e a empresas como a Microsoft e a IBM. O projeto de computacao em grade desenvolvido pela alianca chama-se Globus Tookit. O Globus Tookit fornece um conjunto de servicos e bibliotecas de software de ar quitetura e c digo abertos para o suporte de grades e aplicacoes de grades. O toolkit (caixa o de ferramentas) tem componentes respons veis pelo tratamento de v rios aspectos relatia a vos aos ambientes de grades, como seguranca, descoberta de informacao, gerenciamento de recursos, gerenciamento de dados, comunicacao, deteccao de falhas e portabilidade. A primeira vers o ocial do toolkit foi lancado em 1999. Entretanto, s a partir a o de meados 2001, as empresas despertaram seu interesse e vislumbraram todas as possibilidades que poderiam ser alcancadas atrav s da grade. Ap s o lancamento da vers o 2 do e o a Globus Toolkit (batizado com a sigla GT2), esta arquitetura tornou-se o padr o de facto a para a computacao em grade mundial.
2

http://www.globus.org

Ap s o sucesso do GT2, o Global Grid Forum (comunidade de usu rios, deseno a volvedores e vendedores que objetiva a padronizacao dos conceitos de computacao em grade) decidiu denir uma arquitetura padr o para a construcao de sistemas de grade. Foi a ent o denido o padr o OGSA [Foster et al. 2002] (Open Grid Services Architecture), a a que passou a ser adotado pelo Globus em sua vers o GT3. a O padr o OGSA, ao denir o conceito de servico de grade, fundiu as tecnologias a de grade e servicos web [Booth et al. 2004]. Os servicos de grade s o uma extens o dos a a servicos web que seguem as especicacoes do padr o OGSA para suportar operacoes at a e es de gerenciaent o n o disponibilizadas pelos servicos web, como por exemplo, operaco a a mento do ciclo de vida de servicos. A exemplo dos servicos web, os servicos de grade s o a expressos atrav s da WSDL (Web Service Description Language) [Chinnici et al. 2004], e uma linguagem XML utilizada para descrever servicos a serem acessados atrav s da web. e Uma analogia possvel aos descritores WSDL s o as IDLs CORBA [COR 2002]. a Ap s a denicao da arquitetura do padr o OGSA foi necess rio especicar uma o a a a infraestrutura de servicos b sicos de forma a permitir a implementacao do modelo da a arquitetura OGSA. Esta especicacao foi chamada de OGSI (Open Grid Services Infras tructure) [OGS 2003]. O GT3 foi o primeiro projeto de grade a adotar a especicacao 1.0 da OGSI. O OGSI dene as interfaces b sicas e os comportamentos de um servico de a grade. Entre as v rias especicacoes propostas pelo padr o OGSI encontram-se: a a ` Um conjunto de extens es para a linguagem WSDL, o que deu origem a linguao gem GWSDL; Padr es de estrutura e operacao, em WSDL, para representacao, pesquisa e o atualizacao de dados sobre os servicos; As estruturas GridServiceHandle e GridServiceReference, utilizados para referenciar um servico; Formato para mensagens indicativas de falhas que n o modicam o modelo origia nal de mensagens de falha da linguagem WSDL; Conjunto de operacoes que permitem gerenciar o ciclo de vida dos servicos, como a criacao e destruicao de servicos de grade; Conjunto de operacoes para criacao e uso de colecoes de servicos web; Mecanismos que permitam noticacoes assncronas, caso haja mudanca em dados dos servicos. A Figura 2 mostra o relacionamento entre os diversos padr es especicados e o utilizados para a denicao dos servicos de grade. Como pode ser visto nessa gura, o padr o OGSA dene conceitualmente os servicos de grade, enquanto o OGSI especica a os seus comportamentos. Os servicos web s o estendidos para se tornar servicos de grade, a enquanto que o GT3 implementa a especicacao OGSI. A arquitetura do GT3 pode ser vista na Figura 3. Os servicos da especicacao OGSI s o implementados na camada GT3 Core. a O objetivo desta camada e especicar mecanismos para criacao, gerenciamento e troca de dados entre servicos de grade. A camada GT3 Security Services contem os servicos de seguranca implementados a partir das funcionalidades fornecidas pelo GT3 Core. E nesta camada que se encontram os servicos da GSI (Globus Security Infrastructure)) [Foster et al. 1998], cujo objetivo e prover transpar ncia para os servicos das camadas e de mais alto nvel com relacao a infraestrutura de seguranca da grade. `

 Figura 2. Relacionamento entre padroes na denicao de servicos de grade

Figura 3. Arquitetura do Globus

A camada GT3 Base Services inclui uma gama de servicos b sicos ao uso da a grade, como: Managed Job Service: este servico e normalmente conhecido como job manage ment (neste caso o temo job representa uma operacao sendo executada por um servico de grade). Atrav s deste servico e possvel ao usu rio acompanhar o pro e a gresso na execucao de uma dada computacao, al m de poder exercer controle e sobre ela (suspender, parar, continuar, etc); Index Service: servico de consulta a servicos de grade, atrav s do qual e possvel e localizar um determinado servico de grade segundo quaisquer requisitos parti a culares. E an logo aos registros UDDI (Universal Description, Discovery, and Integration) dos servicos web;

 Reliable File Transfer Service (RFT): este servico permite a transfer ncia e con vel de arquivos (inclusive com grandes volumes de dados) entre o cliente a e um servico de grade. Se algum erro ocorrer no meio da transmiss o o RFT per a mite que a transmiss o continue do mesmo ponto onde parou antes da ocorr ncia a e da falha. A camada GT3 Data Services e respons vel por agrupar servicos de dados, como a por exemplo, o servico de gerenciamento de r plicas. Por m, a camada Other Grid Ser e vices representa outros servicos n o-GT3 que podem ser eventualmente implementados a e agregados ao topo da arquitetura b sica do Globus de forma a prover implementacoes a especcas de usu rios da grade. a No intuito de acompanhar a evolucao dos servicos web e tornar os servicos de grade compatveis com as suas novas especicacoes, a Globus Alliance evoluiu a especicacao OGSI. Entre os aspectos desta evolucao encontram-se: Os mecanismos de enderecamento de servicos de grade (GridServiceHandler e GridServiceReference) foram substitudos pelo WS-Addressing, um novo meca nismo para o enderecamento de servicos web que independe do protocolo da ca mada de transporte [Czajkowski et al. 2004]; A OGSI foi separada em v rias especicacoes menores, por m agrupadas em a e famlias. Esta medida objetiva a reducao da complexidade da OGSI original; A GWSDL modicou o padr o WSDL 1.1 original para acrescentar funcionalidaa des necess rias aos servicos de grade. Isto fez com que a OGSI se tornasse incoma patvel com a WSDL padr o. Entretanto, a nova vers o da OGSI volta a utilizar o a a padr o WSDL 1.1, o que facilita a descricao de servicos de grade, principalmente a ` por desenvolvedores n o habituados a GWSDL: o unico requisito b sico do dea a senvolvedor e conhecer a WSDL, conceito proveniente dos servicos web. Al m e disto, esta medida garante a compatibilidade da especicacao com as ferramentas existentes para XML e servicos web. A partir do renamento da nova vers o da especicacao OGSI surgiu a WSRF a (Web Service Resource Framework) [Czajkowski et al. 2004], uma especicacao comple tamente baseada em servicos web. Ela e utilizada pelo GT4 como uma nova especicacao utilizada para a construcao de middleware de grade. Originalmente, servicos web n o mant m estado e nem t m inst ncias. Apesar a e e a disso, ao estender os servicos web, os servicos de grade prev em em sua especicacao e o uso de servicos web que mantenham estados. Estes servicos devem permitir que seja mantido um certo tipo de mem ria dos servicos, e que eventuais mudancas no estado o dos mesmos sejam v lidas por todo o seu ciclo de vida. O WSFR modica este modelo a de forma a criar uma separacao clara e explcita entre os servicos web e as entidades que mant m estado (inst ncias), que s o manipuladas atrav s destes servicos web. Esta e a a e composicao e denominada pelo padr o WSRF de WS-Resource. a 3.2. Condor O projeto Condor3 [Litzkow et al. 1988, Thain et al. 2004] e um projeto de computacao em grade desenvolvido na Universidade de Wisconsin-Madison, cujo principal pesquisa dor e o professor Miron Livny. E um projeto bastante maduro, dado que est em producao a
3

http://www.cs.wisc.edu/condor

desde a d cada de 80, para uso acad mico e empresarial. Este projeto est focado em e e a desenvolver uma arquitetura que integre recursos computacionais para a execucao de computacoes intensivas. Este sistema permite dois diferentes modos de operacao: grade dedicada e grade oportunista. O objetivo do ambiente de grade dedicado e prover aos seus usu rios grandes quantidades de poder computacional por longos perodos de tempo, utia lizando todos os recursos disponveis na mesma. J o objetivo da grade oportunista e a utilizar somente os recursos que estiverem disponveis em um dado momento, sem reque rer 100% dos recursos das m quinas. a Uma grade Condor e formada por aglomerados de m quinas chamados Condor a Pool. Cada aglomerado, em geral, pertence a um domnio administrativo distinto (apesar de isto n o ser obrigat rio). Os aglomerados que formam a grade s o independentes entre a o a si. A arquitetura de um aglomerado Condor (Condor Pool) e mostrada na Figura 4.

Figura 4. Arquitetura de um Condor Pool

Os n s componentes de um Condor Pool podem assumir tr s pap is: Central o e e Manager, respons vel pelas tarefas de gerenciamento do aglomerado; Submitter que rea presenta um n cliente da grade, solicitando a execucao de computacoes; e Executer que o s o os n s que cedem poder computacional ao aglomerado. Um n pode assumir mais a o o ` de um papel, como no caso de m quinas que fornecem poder computacional a grade e a tamb m solicitam a execucao de computacoes. e Cada n do aglomerado, ao assumir um dos possveis pap is do Condor Pool, o e ` passa a executar alguns m dulos respons veis por exercer atividades relativas a grade. o a Estes m dulos s o detalhados a seguir: o a schedd: m dulo a partir do qual s o feitas as solicitacoes de execucao de o a aplicacoes ao Condor. Atrav s dele e possvel monitorar remotamente o progresso e ` da execucao de aplicacoes submetidas a grade. Executa em n s Submitter; o shadow: representante local de uma aplicacao submetida para execucao na grade. ` E instanciado quando uma aplicacao e submetida a grade. E respons vel por moni a torar a aplicacao e enviar a ela par metros e arquivos (de entrada e sada). Executa a em n s Submitter; o

 startd: m dulo que permite que computacoes da grade sejam executas em uma o m quina do aglomerado. Al m disso, submete periodicamente ao Central Manaa e ger informacoes sobre a disponibilidade de recursos na m quina em que executa. a Ele e tamb m respons vel por aplicar as polticas de compartilhamento de recure a sos denidas pelo usu rio da m quina. Executa em n s Executer; a a o starter: monitora localmente as aplicacoes que executam na grade. E instanci ado quando uma requisicao de execucao chega em um n Executer, com o obje o tivo de monitor -la localmente. Comunica-se diretamente com o m dulo shadow, a o informando-o sobre o progresso da execucao da computacao. collector: m dulo que recebe e mant m as informacoes do aglomerado. Tamb m o e e recebe as solicitacoes de execucao provenientes dos schedds. Periodicamente, ` recebe de cada startd as informacoes relativas a disponibilidade de recursos no n o em que executa. Executa no Central Manager; negotiator: e o escalonador do aglomerado. O negotiator periodicamente verica a exist ncia de requisicoes de execucao junto ao collector. Em caso positivo, ele e procura n s que possam executar a requisicao. Executa no Central Manager; o A Figura 5 ilustra o processo de execucao de aplicacoes no Condor. Este processo ocorre como a seguir: um usu rio da grade solicita a execucao de uma aplicacao a grade a ` (atrav s do schedd). Esta requisicao est associada a um an ncio de pedido de recursos e a u ` e e encaminhada ao collector (1). As m quinas que fornecem recursos a grade, tamb m a e ` enviam periodicamente ao collector um an ncio: s que dos seus recursos cedidos a grade u o (2). De tempos em tempos o negotiator avalia os an ncios de requisicoes e ofertas, asu sociando os que s o compatveis entre si. Este processo e conhecido como matchmaking a [Raman et al. 1998]. O negotiator notica o schedd que efetuou a requisicao, informando quais m quinas executar o sua requisicao. O schedd ent o comunica-se com o startd da a a a m quina que ofereceu o recurso para descobrir se aquela oferta continua v lida (3). Caso a a os recursos ofertados continuem v lidos, a negociacao entre o schedd e o startd foi bem a sucedida. Em seguida o schedd instancia um processo sombra (shadow) (4), que representar localmente a aplicacao que ser executada remotamente. Ele ser respons vel por a a a a monitorar e por gerenciar detalhes da aplicacao a ser executada em nvel local. O shadow comunica-se com o startd da m quina remota informando sobre a execucao da aplicacao. a O startd instancia um processo starter (5), que e respons vel por monitorar a execucao a da aplicacao na m quina remota. O starter ent o instancia a aplicacao (6), solicitando a a o incio de sua execucao. Eventualmente, os processos shadow e starter podem preci sar comunicar-se, trocando informacoes sobre os progressos na execucao da computacao, requisitando os arquivos de sada, ou simplesmente monitorando a aplicacao (7). A arquitetura do Condor foi projetada para operar com um pequeno n mero de u m quinas pertencentes a um mesmo domnio administrativo. Com o aumento do n mero a u de aglomerados Condor surgiu a necessidade de interligacao destes aglomerados em um mesmo sistema, de forma a prover um amplo e eciente comparilhamento de recursos computacionais distribudos entre m ltiplas instituicoes. Como uma forma de contornar u a limitacao inicial da arquitetura do Condor foi proposta uma solucao chamada Gateway Flocking [Epema et al. 1996] ou Flock of Condors, na qual um gateway e introduzido na estrutura dos Condor Pools, sendo este o componente respons vel por interligar um agloa merado a outros. Cada gateway e congurado com informacoes de gateways de outros aglomerados. Esta associacao e v lida somente em um sentido, devendo ser congurada a

Figura 5. Execucao de aplicacoes no Condor

nos dois gateways envolvidos, de forma que um associe-se ao outro. O Flock of Condors permanece transparente aos aglomerados e permite que um aglomerado forneca e utilize recursos de outros aglomerados. Entretanto, os Flock of Condors acumularam uma grade quantidade de tarefas, causando uma queda no desempenho dos gateways. Assim, o Gateway Flocking foi posteriormente substitudo pelo Direct Flocking, onde componentes de um aglomerado comunicam-se diretamente com os componentes de outro, sem a presenca de um gateway. Entretanto, esta abordagem apresenta problemas de escalabilidade, dado que cada componente do aglomerado deve conhecer v rios outros componentes localizaa dos em diversos aglomerados. 3.3. OurGrid OurGrid4 [Andrade et al. 2003, Cirne et al. 2003] e um projeto de grade computacional desenvolvido em conjunto pela Universidade Federal de Campina Grande e Hewlett Packard (HP). O objetivo do OurGrid e pesquisar e desenvolver solucoes para uso e gerenciamento de grades computacionais. O OurGrid e um sistema de grade cooperativo, aberto e gratuito, no qual laborat rios podem doar poder computacional em troca de o acessar, quando necess rio, recursos ociosos pertencentes a outros laborat rios. O proa o jeto OurGrid e fundamentado no projeto MyGrid, desenvolvido tamb m na Universidade e Federal de Campina Grande e est em producao desde dezembro de 2004. a Atualmente o OurGrid permite apenas a execucao de aplicacoes paralelas leves. Aplicacoes leves, tamb m chamadas aplicacoes BoT ou Bag-of-Tasks s o denidas como e a aplicacoes compostas de um conjunto de tarefas independentes que n o necessitam de a comunicacao durante sua execucao. Apesar de parecer um modelo de aplicacoes paralelas simples, as aplicacoes BoT podem ser utilizadas em uma grande variedade de cen rios, a
4

http://www.ourgrid.org

incluindo aplicacoes de mineracao de dados, buscas macicas, varredura de par metros, a biologia computacional e processamento de imagens. O OurGrid foi projetado para poder utilizar tanto os recursos ociosos de estacoes de trabalho como recursos de aglomerados dedicados. Estes ultimos podem, inclusive, ser controlados por outros softwares de gerenciamento de recursos como o Maui5 , OpenPBS6 e LSF7 . Os tr s principais componentes do OurGrid e suas interacoes s o mostradas na e a Figura 6: o MyGrid, a comunidade OurGrid (OurGrid Community) e o SWAN.

Figura 6. Arquitetura do OurGrid

Os usu rios que interagem com o OurGrid utilizam o MyGrid, um componente de a software respons vel por prover aos usu rios, abstracoes de alto nvel que permitem que a a eles utilizem a grade. As abstracoes chave providas pelo MyGrid s o os jobs, as tasks a e as grid machines. Um job e uma colecao de tasks: as tasks s o as unidades b sicas a a ` de trabalho da grade que s o executadas paralelamente. Cada n conectado a grade e a o chamado de grid machine. O usu rio e respons vel por prover uma descricao de seus a a jobs e um ponto de entrada para a comunidade OurGrid na forma de uma URL para um peer8 OurGrid. O MyGrid utiliza esta URL para requisitar grid machines disponveis no peer. Jobs, tasks e grid machines t m atributos que permitem que o usu rio especique e a requisitos para os jobs e tasks e assim permitir que o MyGrid aloque as tasks nas grid
http://mauischeduler.sourceforge.net http://www.openpbs.org 7 http://www.platform.com/Products/Platform.LSF.Family 8 Um peer OurGrid corresponde a um aglomerado de m quinas da grade, compreendendo geralmente a um unico domnio administrativo
6 5

machines. Esta alocacao pode incorporar heursticas de escalonamento para melhorar o desempenho de diferentes tipos de aplicacao. A arquitetura da comunidade OurGrid foi projetada para ser escal vel e permitir a que milhares de aglomerados possam estar conectados ao sistema. Esta escalabilidade prov m do fato de ela basear-se em redes P2P (peer-to-peer), em que cada aglomerado e representa um peer. Entretanto, redes P2P podem ter o seu desempenho comprometido por causa de peers chamados freeriders [Hughes et al. 2005]. Um freerider e um peer que somente consome recursos, nunca contribuindo com a comunidade. Este comportamento poderia ter um impacto negativo no OurGrid, dado que muitos usu rios apresentam a uma insaci vel demanda por recursos computacionais. Para lidar com este problema foi a criada uma rede de favores (network of favors), um mecanismo de alocacao de recursos totalmente descentralizado e e aut nomo que marginaliza os freeriders. o Para que um peer tenha acesso aos recursos disponveis na grade e necess rio que a cada n da grade execute uma implementacao de uma interface chamada GridMachine. o A GridMachine (ou GuM) dene um conjunto mnimo de operacoes necess rias para a executar uma task em um n . Tr s implementacoes de GuM est o atualmente disponveis o e a no OurGrid: (a) GridScript, que faz uso de aplicativos de linha de comando como o ssh e o scp para transferir dados e executar as computacoes da grade, (b) Globus Proxy, permite que n s de uma grade Globus executem computacoes requisitadas atrav s do o e OurGrid (criando uma interface entre o Globus e o OurGrid) e (c) UserAgent, que e uma implementacao Java para executar aplicacoes em n s da grade. Atrav s dos GuMs o resto o e do sistema pode abstrair a complexidade de tratar diferentes tipos de recursos. A Tabela 2 mostra as cinco operacoes denidas na interface e suas sem nticas. Estas operacoes s o a a simples, mas sucientes para permitir que uma task seja executada em uma grid machine. Operacao ping() run() putFile() getFile() kill() Sem ntica a Verica a disponibilidade da grid machine Inicia um processo na grid machine Armazena arquivos na grid machine Recupera arquivos da grid machine Mata um processo na grid machine

Tabela 2. Semantica das operacoes denidas na interface GridMachine

No OurGrid, tasks de um aglomerado possivelmente executar o em outros agloa merados. Isto traz consigo uma forte preocupacao com a seguranca das m quinas que a ` colaboram cedendo recursos computacionais a grade, dado que c digo desconhecido exeo cutar nelas. Como uma maneira de proteger as m quinas da grade de aplicacoes hosa a tis, o OurGrid utiliza um software chamado SWAN (Sandboxing Without A Name), uma solucao baseada na m quina virtual Xen [Barham, P. et al. 2003] que isola o c digo pro a o veniente da grade em uma sandbox que n o permite o acesso a dados e a dispositivos a locais e nem a utilizar a rede. 3.4. CoordAgent O CoordAgent [Fukuda et al. 2003] e um middleware de grade que agrega poder com` putacional de computadores pessoais conectados a Internet. Foi desenvolvido no Laborat rio de Sistemas Distribudos da Universidade de Washington, Bothell, cujo principal o

 pesquisador e o professor Munehiro Fukuda. Sua infraestrutura e composta por agentes ` m veis que realizam todas as funcoes pertinentes a grade, como a busca por recursos o disponveis e a execucao de aplicacoes. A Figura 7 mostra a organizacao da arquitetura de um aglomerado CoordAgent. Para formar este aglomerado, um moderador (i.e. um administrador da infraestrutura da grade) deve iniciar um Internet Group, que compreende a infraestrutura b sica resa ` pons vel por manter as informacoes das m quinas conectadas a grade. Para isso, o a a Internet Group conta com uma base de dados de m quinas conectadas ao aglomerado. a M ltiplos Internet Groups podem ser organizados utilizando o Globus Metacomputing u Directory Service (MDS). Cada usu rio deve ent o criar uma conta de convidado, exea a cutar um servidor web em sua m quina, registrar suas informacoes no Internet Group e a baixar o mecanismo de execucao de aplicacoes (desenvolvido como um agente m vel). o Ap s entrar no Intenet Group, o usu rio invoca o agente m vel que exibe a janela atrav s o a o e da qual ele poder solicitar a execucao de aplicacoes. Estas aplicacoes podem ter sido dea senvolvidas utilizando as linguagens C/C++ e Java. O CoordAgent permite a execucao de aplicacoes paralelas na grade utilizando ambas as linguagens: C/C++ podem ser desen volvidas utilizando MPI e PVM, enquanto que as aplicacoes Java podem utilizar JPVM9 .

Figura 7. Arquitetura do CoordAgent

Ap s receber a requisicao de execucao, o agente migra at a base de dados do Ino e ternet Group procurando por computadores que possam satisfazer a requisicao do cliente. Caso n o existam m quinas que atendam os requisitos de execucao da aplicacao, o agente a a tenta repetidamente visitar bases de dados em outros Internet Groups atrav s do MDS, e procurando a melhor m quina para atender a requisicao. Na migracao, o agente utiliza a uma t cnica de tunelamento HTTP, na qual o agente e entregue como uma mensagem e HTTP e depois e recriado por um servlet no destino. Ap s localizar uma m quina que possa atender a requisicao do usu rio, o agente o a a
Java Parallel Virtual Machine biblioteca Java que permite a implementacao de aplicacoes paralelas ` utilizando Java. Fornece uma interface id ntica a da biblioteca PVM original e
9

` m vel copia todos os arquivos necess rios a execucao da aplicacao, da m quina cliente o a a para a m quina destino. Se a aplicacao for uma aplicacao que venha requerer mais de a uma m quina para sua execucao (por exemplo, uma aplicacao paralela), o agente cria a ` novos agentes lhos e os envia as outras m quinas. Assim, todos os agentes lancam a as aplicacoes nas m quinas de destino e passam a monitorar suas execucoes. Caso uma a m quina se torne indisponvel durante a execucao de uma aplicacao, o agente deve migrar a sua aplicacao correspondente para uma outra m quina disponvel. Este processo requer a que o estado de execucao da aplicacao seja capturado, migrado e recuperado no destino. Este mecanismo tamb m e utilizado para prover toler ncia a falhas, onde o estado de e a execucao e periodicamente salvo em um reposit rio que resiste a falhas do sistema. o Para salvar o estado de execucao de aplicacoes que executam na grade, o Coor dAgent insere (atrav s de um pr -processador) em seu c digos-fonte funcoes de captura e e o e recuperacao do estado de execucao. Este mecanismo e fornecido por pr -compiladores e baseados em duas ferramentas: ANTLR10 para aplicacoes C/C++ e JavaCC11 para aplicacoes Java. 3.5. Organic Grid O Organic Grid12 [Chakravarti et al. 2005b, Chakravarti et al. 2005a, Chakravarti et al. 2004] e um projeto de grade oportunista em desenvolvimento na Universidade de Ohio. O projeto prop e uma abordagem completamente descentralizada, o sem a presenca de componentes que mantenham informacoes sobre todos os recursos presentes no sistema. Al m disso, utiliza um esquema de escalonamento aut nomo e o inspirado na organizacao de complexos sistemas biol gicos (e.g. a organizacao das o formigas). Atrav s deste esquema de escalonamento e possvel atingir um alto grau de e escalabilidade, agregando ao sistema milh es de computadores o que n o e possvel o a quando uma abordagem centralizada e utilizada. O esquema de escalonamento descentralizado utilizado neste projeto foi baseado em um trabalho anteriormente proposto por Kreaseck et al. [Kreaseck et al. 2003]. Ambos os trabalhos organizam as computacoes em redes overlay (tamb m chamadas redes e sobrepostas) [Doval and OMahony 2003] estruturadas como arvores. Redes overlay s o a estruturas l gicas que representam topologias virtuais13 estruturadas sobre o protocolo o de transporte utilizado, facilitando, por exemplo, buscas determinsticas na rede. As re des overlay representam em suas estruturas, os n s da rede, seus vizinhos e as ligacoes o l gicas existentes entre eles. A presenca de uma ligacao l gica entre dois n s em uma o o o rede overlay indica que eles podem comunicar-se diretamente um com o outro. Redes ` overlay s o consideradas uma alternativa escal vel as atuais redes P2P. a a ` O Organic Grid encapsula as computacoes submetidas a grade em agentes m veis, o ou seja, todas as computacoes na grade t m um agente respons vel por efetuar sua e a execucao. Al m de executar aplicacoes, os agentes do Organic Grid tamb m permitem e e que n s da grade sejam liberados, caso os usu rios reclamem o seu uso. Esta capacidade e o a
http://www.antlr.org http://www.webgain.com/products/javacc 12 http://bit.csc.lsu.edu/ gb/OrganicGrid 13 A topologia l gica formada pelas redes overlay s o ditas virtuais porque n o representam a rede o a a como ela est organizada sicamente a
11 10

fornecida atrav s do arcabouco para migracao forte de aplicacoes multi-threading descrito e em [Chakravarti et al. 2003]. Al m de encapsular as aplicacoes em execucao na grade, os agentes do Organic e Grid s o respons veis por implementar seu esquema de escalonamento aut nomo. A a a o arvore overlay, que constitui a base do escalonamento no Organic Grid, e mantida por estes agentes, sendo cada um deles mapeado como um n da arvore. o O algoritmo de escalonamento do Organic Grid, em linhas gerais, funciona da seguinte maneira: quando uma computacao e submetida a partir de um n A, este divide o a tarefa em sub-tarefas menores e passa a executar uma delas. Ent o, o n A inicia a a o montagem da arvore overlay, sendo ele mesmo a raiz desta. Outras sub-tarefas s o ent o a a enviadas a seus amigos14 , que tamb m passam a executar sub-tarefas. Assim, e formada e uma hierarquia, onde os amigos de A tornam-se lhos de A. A cadeia prossegue com os lhos de A, at que toda a arvore seja montada. N s que recebem solicitacoes de execucao e o tornam-se lhos dos solicitantes. ` A medida que alguns n s concluem a execucao de sub-tarefas, seus resultados o v o sendo devolvidos a seus pais. Neste interstcio, os n s lhos podem ainda solicitar a a o seus pais mais sub-tarefas a executar. Ap s o retorno dos resultados de todos os lhos, o o n pai dever escolher o lho que tiver o maior throughput (i.e. os n s que devolvem o a o mais rapidamente o resultado das computacoes) para mov -lo15 um nvel acima na arvore e (juntamente com sua sub- rvore, se esta existir), de forma que ele que mais pr ximo ao a o n A, ou seja, a raiz da arvore. Ao assumir uma nova posicao na arvore, este n ganha o o de seus novos pais o estado de lho em potencial, e permanece neste estado at que e seu throughput seja avaliado por seu novo pai. De maneira an loga, o lho com o menor a throughput ser removido da arvore, e poder no futuro, tentar voltar a compor a arvore. a a ` Futuramente, ao tentar se reintegrar a arvore, os n s excludos tamb m ganhar o o estado o e a de lhos em potencial, at que tenham os seus throughputs novamente avaliados. Como e pode ser percebido, este algoritmo tende a fazer com que os n s mais r pidos quem o a mais pr ximos ao n que solicitou a execucao da computacao, e que os n s lentos sejam o o o ` removidos da estrutura, melhorando assim o tempo de resposta da grade as solicitacoes de execucao de aplicacoes. Este esquema e inspirado em sistemas biol gicos compostos o por milh es de organismos encontrados na natureza que, de maneira aut noma, produzem o o complexos padr es de formacao, organizando-se da melhor maneira para executarem seu o trabalho. O algoritmo de escalonamento utilizado no Organic Grid, apesar de ser extremamente escal vel, pode n o resultar em um aproveitamento dos recursos t o bom quanto a a a a abordagem centralizada. Al m disso, o desempenho deste esquema depende diretamente e da formacao inicial da arvore. A Figura 8(a) mostra a formacao inicial de uma grade Organic Grid. J a Figura 8(b) apresenta a formacao da arvore overlay da mesma grade a ap s a execucao de algumas rodadas do algoritmo descrito. o
N s amigos s o aqueles n s cujos enderecos s o previamente conhecidos, tendo sidos congurados o a o a manualmente ou obtidos atrav s de outros mecanismos como, por exemplo, uma rede P2P de compartilhae mento de arquivos [Ratnasamy et al. 2001] 15 O verbo mover e aqui empregado no sentido de alterar as ligacoes hier rquicas que existem entre os a n s. Por exemplo, na hierarquia X e pai de Y , e Y e pai de Z, mover Z um nvel acima signica torn -lo o a lho direto de X, ou seja: X e pai de Y e Z
14

(a) Conguracao inicial de um aglomerado do Orga nic Grid

(b) Organizacao dos n s ap s alguns ciclos de o o execucao do algoritmo de escalonamento do Organic Grid Figura 8. Grade Organic Grid

A vers o atual do Organic Grid suporta a execucao de duas classes de aplicacoes: a regulares e param tricas. Entretanto, os desenvolvedores do Organic Grid demostrae ram, utilizando uma implementacao tolerante a falhas do algoritmo de Cannon para multiplicacao de matrizes, como esta infraestrutura poderia ser facilmente adaptada para permitir a execucao de aplicacoes paralelas que utilizam comunicacao entre suas sub tarefas [Chakravarti et al. 2004]. O Organic Grid prop e um esquema de escalonamento descentralizado em que o as decis es de escalonamento independem da exist ncia de conhecimento global sobre o e os recursos disponveis na grade. Esta abordagem cria um alto grau de escalabilidade ao sistema, uma vez que n o h a presenca de elementos centralizadores. a a

4. O Middleware Integrade
Integrade e um middleware de grade atualmente em desenvolvido pelo Instituto de Matem tica e Estatstica da Universidade de S o Paulo (IME/USP), o Departamento de a a Computacao e Estatstica da Universidade Federal de Mato Grosso do Sul (DCT/UFMS), o Departamento de Inform tica da Pontifcia Universidade Cat lica do Rio de Janeiro a o (DI/PUC-Rio), o Instituto de Inform tica da Universidade Federal de Goi s (UFG) e o a a Departamento de Inform tica da Universidade Federal do Maranh o (DEINF/UFMA). a a Os principais objetivos do projeto Integrade s o [Goldchleger et al. 2004]: a Utilizar o poder computacional ocioso de m quinas disponveis em instituicoes a para resolver problemas computacionais; Permitir o acesso remoto a hardware e software de outras m quinas, como procesa sadores, discos e compiladores; Permitir o compartilhamento de recursos computacionais, evitando a necessidade, por exemplo, de adquirir novo hardware para utilizar o sistema; Ser escal vel e facilmente gerenciado atrav s de uma estrutura hier rquica. a e a O Integrade e estruturado em aglomerados, ou seja, unidades aut nomas dentro da o grade que cont m todos os componentes necess rios para funcionar independentemente. e a Estes aglomerados podem estar organizados de uma forma hier rquica ou conectados a atrav s de uma rede ponto-a-ponto (Peer-to-Peer ou P2P) [Goldchleger 2004]. A arquitee tura de um aglomerado Integrade pode ser visto na Figura 9.

Figura 9. Arquitetura de um aglomerado Integrade

O n Gerenciador do Aglomerado representa o n respons vel por gerenciar o o o a aglomerado e por comunicar-se com os outros gerenciadores de aglomerados. Um N o de Usu rio e um n pertencente a um usu rio que submete aplicacoes para execucao a o a na grade. Um N Compartilhado e tipicamente um PC ou estacao de trabalho em um o laborat rio compartilhado que exporta parte de seus recursos, tornando-os disponveis aos o ` usu rios da grade. Um N Dedicado e aquele reservado a execucao de computacoes a o da grade. Estas categorias podem sobrepor-se: um n pode ser ao mesmo tempo um o

N de Usu rio e um N Compartilhado. Como tamb m pode ser visto na Figura 9, o a o e v rias entidades de software comp em a arquitetura mostrada. Elas executam nos n s a o o componentes do aglomerado de forma a prover as funcionalidades necess rias a cada a categoria de n . Estas entidades ser o descritas a seguir: o a GRM (Global Resource Manager): gerenciador de recursos do aglomerado. Mant m informacoes a respeito do estado de disponibilidade dos recursos pree sentes nas m quinas que comp em o aglomerado, efetuando o escalonamento de a o tarefas nos n s de acordo com estas informacoes e efetuando negociacao e reserva o de recursos. Executa no n gerenciador do aglomerado; o GUPA (Global Usage Pattern Analyser): executa em cooperacao com o GRM, gerenciando informacoes sobre os padr es de uso de recursos dos n s componen o o tes do aglomerado. Fornece estas informacoes ao GRM de forma a colaborar para que ele tome melhores decis es de escalonamento; o AR (ApplicationRepository): armazena as aplicacoes que podem executar na ` grade. Toda aplicacao submetida a execucao deve ser primeiramente registrada neste reposit rio; o LRM (Local Resource Manager): e executado em cada n que fornece recursos ao o aglomerado. Coleta informacoes sobre o estado do n como mem ria, CPU, disco o o e utilizacao da rede. Os LRMs enviam periodicamente informacoes ao GRM de seus aglomerados, atrav s de um protocolo de atualizacao de informacoes; e LUPA (Local Usage Pattern Analyser): executa junto ao LRM e coleta localmente informacoes de padr es de uso dos usu rios do n . Baseia-se em longas s ries de o a o e dados derivadas de padr es semanais de uso do n . Periodicamente transmite as o o informacoes locais ao GUPA; ASCT (Application Submission and Control Tool): ferramenta para submiss o a aplicacoes para execucao na grade. Os usu rios podem especicar pr -requisitos a e de execucao, como a plataforma de hardware e software nas quais a aplicacao deve ` ser executada, requisitos de mem ria necess rios a execucao da aplicacao, entre o a outros. Tamb m e possvel monitorar o progresso da aplicacao em execucao. e O Integrade atualmente permite a execucao de tr s classes de aplicacoes: e 1. Aplicacoes regulares, onde o c digo execut vel e designado para um unico n da o a o grade; 2. Aplicacoes param tricas ou BoT (Bag-of-tasks), onde v rias c pias do c digo e a o o execut vel s o designadas para n s diferentes da grade. Cada n recebe um suba a o o conjunto dos dados de entrada da aplicacao e computa o resultado em paralelo com os demais. Neste caso, n o existe comunicacao entre os n s; a o 3. Aplicacoes paralelas que seguem o modelo BSP [Valiant 1990] (Bulk Synchro nous Parallelism) ou MPI, onde v rios n s s o designados para a execucao da a o a aplicacao e as computacoes s o realizadas em cada um dos n s participantes, mas a o neste caso, os processos ocasionalmente trocam dados entre eles. 4.1. Protocolo de Execucao da Aplicacao A Figura 10 mostra as interacoes entre os componentes do Integrade necess rias para a a execucao de aplicacoes. O usu rio solicita a execucao da aplicacao atrav s da interface a e ASCT. A aplicacao deve ter sido previamente registrada no reposit rio de aplicacoes. Op o cionalmente, o usu rio pode denir alguns requisitos para a execucao da aplicacao, tais a

como a plataforma na qual a aplicacao foi compilada e a quantidade mnima de mem ria o necess ria para essa execucao. O ASCT encaminha a solicitacao ao GRM (1), o qual a executa seu escalonemento de algoritmo para selecionar um n disponvel. O GRM ino forma ao EM que a aplicacao foi escalonada (2) e encaminha os dados da submiss o para a o LRM do n selecionado (3). o

Figura 10. Integrade application execution protocol

O LRM escalonado baixa o arquivo bin rio da aplicacao (previamente registrada) a do AR (4), solicita os arquivos de entrada (se houver algum) do ASCT (5), noticando a aceitacao da solicitacao (6). Antes de comecar a executar a aplicacao, o LRM notica o EM sobre a inicializacao da aplicacao (7) e comeca a monitorar o progresso da execucao (8), at a sua conclus o. Nesse momento, o LRM informa o EM (9) e o ASCT (10) sobre e a o m da execucao da aplicacao. o ASCT pode ent o baixar os resultados (arquivos de a sada) da aplicacao executada (11). 4.2. Gerenciamento de Dados das Aplicacoes Os usu rios podem registrar uma aplicacao no Integrade usando o portal Web, providencia ando a descricao da aplicacao e um ou mais arquivos bin rios para permitir sua execucao a em diferentes plataformas. O Integrade armazena, no m dulo Reposit rio de Aplicacoes o o (AR, os bin rios da aplicacao e os metadados a aplicacao e as plataformas para as quais a os bin rios est o disponveis. a a E mais difcil gerenciar e armazenar os arquivos de entrada e sada do que os arquivos da aplicacao, uma vez que os primeiros podem ser muito grandes. Para li dar com esses arquivos, foi desenvolvido um reposit rio de dados distribudo chamado o OppStore[de Camargo and Kon 2007]. O acesso aos dados distribudo e atrav s de uma e biblioteca chamada access broker, que interage com OppStore. OppStore e um middleware que prov armazenamento distribuido de dados e con vel usando espaco livre de discos de m quinas compartilhadas na grade. O oba a jetivo e usar o espaco livre dos discos de um modo oportunista, isto e, apenas quando as

 m quinas estiverem ociosas. O sistema e estruturado como uma federacao de clusters e a e conectado por uma rede peer-to-peer em um modo escal vel e tolerante a falhas. Essa a estrutura de federacao permite ao sistema distribuir os dados da aplicacao atrav s de toda e a grade. Durante o armazenamento, o sistema divide os dados em fragmentos codicados redundantes e os armazena em diferentes clusters da grade. Essa distribuicao aumenta a disponibilidade dos dados e melhora a toler ncia a falhas, uma vez que fragmentos a s o armazenados em clusters geogracamente dispersos. Na recuperacao dos dados, as a aplicacoes podem simultaneamente baixar fragmentos de arquivos armazeandos em clus ters com maior largura de banda, possibilitando recuperacao eciente dos dados. Quando um usu rio do Integrade submete uma aplicacao para execucao, seus ara quivos de entrada s o armazenados antes em m quinas distribudas. O pedido de execucao a a e enviado ent o para o GRM que seleciona quais LRMs v o executar a aplicacao e ena a caminha o pedido para aqueles n s. Quando o LRM recebe um pedido de execucao da o aplicacao, ele obt m do AR o bin rio da aplicacao para sua plataforma especca e os e a arquivos de entrada do OppStore. Quando a execucao termina, os arquivos de sada s o a armazenados no OppStore. Usando OppStore, os arquivos de entrada e sada da aplicacao podem ser obtidos a partir de qualquer n na grade. Consequentemente, ap s a ocorr ncia de uma falha, o o e a reinicializacao da execucao de uma aplicacao em outra m quina pode ser facilmente a executada. Do mesmo modo, no nal da execucao de uma aplicacao, os arquivos de sada armazenados no reposit rio distribudo podem ser acessados pelos usu rios a partir de o a qualquer m quina na grade. a Simulacoes executadas[de Camargo and Kon 2007] mostraram que, usando ape nas os perodos ociosos das m quinas compartilhadas, para recuperar os da a dos em situacoes realistas, o OppStore pode prover 99.9% de disponibilidade de dados usando um fator de replicacao de 3. Experimentos de avaliacao do OppStore[de Camargo and Kon 2007] mostraram que a recuperacao de um arquivo arma zenado no OppStore e muito eciente quando ocorre uma selecao criteriosa dos clusters para recuperacao dos fragmentos. Consequentemente, pelo uso de espaco livre de dis cos das m quinas apenas durante seus perodos ociosos, o Integrade e capaz de prover a alta disponibilidade e bom desempenho para aplicacoes que precisam armazenar desde alguns poucos kilobytes at diversos gigabytes de dados. e

5. Conclus es o
A tecnologia de Grades de Computadores recebe hoje grande atencao por parte tanto da academia quanto da ind stria por ter se rmado como uma alternativa atraente para a u execucao de uma grande variedade de aplicacoes nas mais variadas areas como biolo gia computacional, processamento e armazenamento de imagens, previs o do tempo e a simulacoes de mercado. Este artigo apresentou o estado da arte em tecnologia de Grades de Computadores. Foram descritas as classes de aplicacoes que fazem uso deste tipo de tecnologia e uma taxonomia que classica as grades de computadores em grades computacionais, de dados e de servicos. Os aspectos mais importantes dos principais middlewares de grade foram tamb m descritos. e Uma enfase especial foi dada ao middleware Integrade, uma infra-estrutura de

software livre que permite o aproveitamento de recursos ociosos para a estabelecimento de Grades de Computadores desenvolvido em parceria pela USP, PUC-Rio, UFMA, UFMS e UFG.

Refer ncias e
(2002). CORBA v3.0 Specication. Object Management Group, Needham, MA. OMG Document 02-06-33. (2003). Open Grid Services Infrastructure (OGSI) Version 1.0. Global Grid Forum. GFDR-P.15 (Proposed Recommendation). Andrade, N., Cirne, W., Brasileiro, F., and Roisenberg, P. (2003). OurGrid: An approach to easily assemble grids with equitable resource sharing. In Proc. of the 9th Workshop on Job Scheduling Strategies for Parallel Processing. Baker, M., Buyya, R., and Laforenza, D. (2000). The grid: International efforts in global computing. In Proc. of the International Conference on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet. Barham, P. et al. (2003). Xen and the Art of Virtualization. In SOPS. Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C., and Orchard, D. (2004). Web services architecture. World Wide Web Consortium. Buyya, R. (2002). Understanding the Grid. Grid Computing Planet Conference. Chakravarti, A., Baumgartner, G., and Lauria, M. (2004). Application-specic scheduling for the Organic Grid. In Proceedings of Fifth IEEE/ACM International Workshop on Grid Computing, pages 146155. Chakravarti, A., Baumgartner, G., and Lauria, M. (2005a). The organic grid: Selforganizing computation on a peer-to-peer network. To appear in IEEE Transactions on Systems, Man, and Cybernetics, Vol. 35(No. 3). Chakravarti, A., Baumgartner, G., and Lauria, M. (2005b). The organic grid: Selforganizing computational biology on desktop grids. To appear in A. Zomaya (ed.), Parallel Computing for Bioinformatics. Chakravarti, A. J., Wang, X., Hallstrom, J. O., and Baumgartner, G. (2003). Implementation of Strong Mobility for Multi-Threaded Agents in Java. In 2003 International Conference on Parallel Processing (ICPP 03). IEEE Computer Society Press., pages 321330, Koahsiung, Taiwan. Chinnici, R., Gudgin, M., Moreau, J.-J., Schlimmer, J., and Weerawarana, S. (2004). Web services description language (wsdl) version 2.0 part 1: Core language. World Wide Web Consortium. Cirne, W., Paranhos, D., Costa, L., Santos-Neto, E., Brasileiro, F., Sauve, J., Silva, F. A. B., Barros, C. O., and Silveira, C. (2003). Running Bag-of-Tasks Applications on Computational Grids: The MyGrid Approach. In In Proc. International Conference on Parallel Processing (ICPP03), page 407. Czajkowski, K., Ferguson, D., Foster, I., Frey, J., Graham, S., Maquire, T., Snelling, D., and Tuecke, S. (2004). From open grid services infrastructure to ws-resource framework: Refactoring & evolution. Global Grid Forum Draft Recommendation.

de Camargo, R. Y. and Kon, F. (2007). Design and implementation of a middleware for data storage in opportunistic grids. In CCGrid 07: Proceedings of the 7th IEEE/ACM International Symposium on Cluster Computing and the Grid, Washington, DC, USA. Doval, D. and OMahony, D. (2003). Overlay networks: A scalable alternative for P2P. IEEE Internet Computing, 7:7982. Epema, D., Livny, M., Dantzig, R. v., Evers, X., and Pruyne, J. (1996). A worldwide ock of condors: Load sharing among workstation clusters. Future Generation Computer Systems, 12(53):65. Foster, I. and Kesselman, C. (1999). The Grid: Blueprint for a Future Computing Infrastructure, chapter Globus: A Toolkit-Based Grid Architecture, pages 259278. Morgan Kaufmann Publisher. Foster, I., Kesselman, C., Nick, J., and Tuecke, S. (2002). The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. In Open Grid Service Infrastructure WG, Global Grid Forum. Foster, I., Kesselman, C., Tsudik, G., and Tuecke, S. (1998). A Security Architecture for Computational Grids. In In Proceedings of the 5th ACM Conference on Computer and Communications Security, pages 8392. Foster, I., Kesselman, C., and Tueke, S. (2001). The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of Supercomputing Applications. Fukuda, M., Tanaka, Y., Bic, L. F., and Kobayashi, S. (2003). A mobile-agent-based pc grid. IEEE Computer. Goldchleger, A. (2004). InteGrade: Um Sistema de Middleware para Computacao em Grade Oportunista (InteGrade: a Middleware System for Opportunistic Grid Computing). Masters thesis, Department of Computer Science - University of S o Paulo. in a Portuguese. Goldchleger, A., Kon, F., Goldman, A., Finger, M., and Bezerra, G. C. (2004). Integrade: Object-oriented grid middleware leveraging idle computing power of desktop machines. Concurrency and Computation: Practice & Experience. Vol. 16, pp. 449-459. Goldchleger, A., Kon, F., Goldman, A., M., F., and Song, S. W. (2002). Integrade: Rumo a um sistema de computacao em grade para aproveitamento de recursos ociosos em m quinas compartilhadas. Technical report, Departamento de Ci ncia da Computacao. a e Instituto de Matem tica e Estatstica - Universidade de S o Paulo. a a Hughes, D., Coulson, G., and Walkerdine, J. (2005). Free Riding on Gnutella Revisited: the Bell Tolls? Submitted to IEEE Distributed Systems. Draft at http://www.comp.lancs.ac.uk/computing/users/hughesdr/papers/freeriding.pdf. Krauter, K., Buyya, R., and Maheswaran, M. (2002). A taxonomy and survey of grid resource management systems for distributed computin. In Software - Practice and Experience, volume 32, pages 135164. Kreaseck, B., Carter, L., Casanova, H., and Ferrante, J. (2003). Autonomous protocols for bandwidth-centric scheduling of independent-task applications. In In Proceedings of the International Parallel and Distributed Processing Symposium, pages 2325.

Litzkow, M., Livny, M., and Mutka, M. (1988). Condor - a hunter of idle workstations. In Proceedings of the 8th International Conference of Distributed Computing Systems. Menasc , D. A. and Casalicchio, E. (2004). Qos in grid computing. IEEE Internet Come puting, pages 8587. Raman, R., Livny, M., and Solomon, M. (1998). Matchmaking: Distributed resource management for high throughput computing. In Proceedings of the Seventh IEEE International Symposium on High Performance Distributed Computing (HPDC7), Chicago, IL. Ratnasamy, S., Francis, P., Handley, M., Karp, R., and Shenker, R. (2001). A scalable content addressable network. In In Proceedings of ACM SIGCOMM01. Thain, D., Tannenbaum, T., and Livny, M. (2004). Distributed computing in practice: The condor experience. Concurrency and Computation: Practice and Experience. Valiant, L. G. (1990). A bridging model for parallel computation. Communications of the ACM, 8(33):103111.