Captulo

11

Computao em Grade: Conceitos, Tecnologias, Aplicaes e Tendncias

Lus Fabrcio Wanderley Ges, Dorgival Olavo Guedes Neto, Renato Ferreira, Walfredo Cirne

Abstract Due to the evolution of processors, networks, memories, operating systems, languages and other computers components, new parallel and distributed architectures appeared, among them we remark the computational grades. Thus, a wide range of complex problems could be solved such as massive image processing, computational biology, data mining and scientific and engineering simulation models. Nowadays, there are many technologies to support grade computing: Globus, Gradebus, Condor, OurGrade and Anthill. In this work, we detail the concepts (characteristics, architectures etc.), technologies, applications (data mining etc.) and current and future tendencies of the grade computing. Resumo Com a evoluo dos processadores, redes de interconexo, memrias, sistemas operacionais, linguagens e outros componentes de computador, surgiram novas arquiteturas paralelas e distribudas, dentre as quais destacamos as grades computacionais. Em decorrncia disso, criou-se a possibilidade de resolver problemas mais complexos como tratamento de conjuntos de imagens, biologia computacional, minerao de dados e simulao de modelos cientficos e de engenharia. Atualmente, existem diversas tecnologias para o suportar a computao em grade, dentre os quais destacamos o Globus, Gradebus, Condor, OurGrade e Anthill. Neste trabalho, detalharemos os conceitos (caractersticas, arquiteturas etc.), tecnologias, aplicaes (minerao de dados etc.) e tendncias atuais e futuras da computao em grade.

11.1. Introduo
Inspirados pelo sistema de energia eltrica, no meio da dcada de 90, os cientistas da computao comearam a explorar o projeto e o desenvolvimento de uma nova infraestrutura computacional pelo acoplamento de recursos distribudos geograficamente como bases de dados, servidores de armazenamento, redes de alta velocidade, supercomputadores e aglomerados para solucionar problemas de grande escala, levando ao termo popularmente conhecido como computao em grade [Buyya 2002] [Buyya 2005] [Foster 1999] [Foster 2002]. Esta infra-estrutura anloga grade de energia eltrica que prov acesso consistente, pervasivo e transparente a energia eltrica independente da origem. A grde de energia eltrica disponibiliza energia eltrica sob demanda e esconde do usurio detalhes como a origem da energia e a complexidade da malha de transmisso e distribuio. Ou seja, se temos um equipamento eltrico, simplesmente o conectamos na tomada para que ele receba energia. Uma grade computacional, portanto, seria uma rede na qual o individuo se conecta para obter poder computacional (ciclos, armazenamento, software, perifricos, etc). A Figura 1 ilustra esta idia.

Figura 1. Uma Grade Computacional como fonte transparente de poder computacional sob demanda.

Tanto a origem dos ciclos de processamento quanto da energia bastante heterognea. No caso da energia, ela pode ser gerada por usinas termoeltricas, hidreltricas, nucleares e elicas, enquanto os ciclos de processamento podem surgir de aglomerados de computadores, PCs, SMPs, etc. com diferentes sistemas operacionais, arquiteturas e processadores. Alm disso, as cargas de trabalho das infra-estruturas so bastante heterogneas, comeando de eletrodomsticos, televisores at mquina industriais no caso da grade de energia eltrica, enquanto na grade computacional existem aplicaes cientficas, de entretenimento, de engenharia etc [Buyya 2002].

Mas apesar destas semelhanas, diferentemente da grade de energia eltrica que fornece energia de imediato, pois ele no necessita gerar diferentes tipos de energia de acordo com a entrada, a grade computacional necessita de dados de entrada para o uso de seus ciclos de processamento, alm da transmisso dos resultados. Uma outra diferena interessante a questo do armazenamento, pois a energia eltrica pode ser armazenada, enquanto os ciclos de processamento no utilizados so perdidos [Buyya 2002]. Existe um grande nmero de projetos ao redor do mundo empenhados no desenvolvimento de grades computacionais e com isso surgiram diversas definies. O projeto Gridbus define uma grade computacional como um tipo de sistema distribudo e paralelo que permite o compartilhamento, seleo e agregao de recursos autnomos distribudos geograficamente, em tempo de execuo, dependendo da disponibilidade, capacidade, desempenho, custo e requisitos de QoS dos usurios [Buyya 2005]. De acordo com o projeto Globus, uma grade computacional uma infra-estrutura que permite o uso integrado e colaborativo de computadores de alto desempenho, redes de interconexo, bases de dados e instrumentos cientficos pertencidos e gerenciados por mltiplas organizaes [Foster 2002]. 11.1.1. Histrico A computao em grade o resultado de dcadas de pesquisa nas reas de processamento paralelo e sistemas distribudos. A pesquisa em processamento paralelo sempre procurou extrair o mximo de desempenho computacional por meio da criao de mquinas dedicadas com mltiplos processadores, redes especiais de alta velocidade, memrias compartilhadas e processamento vetorial. Todo este esforo levou a construo de supercomputadores como o NEC Earth Simulator e o IBM Blue Gene (MPPs), mquinas extremamente caras e de propsito especfico, alm de aglomerados de computadores (NOWs) de baixo custo financeiro compostos de software e hardware de prateleira.

Figura 2. Evoluo das arquieturas at as Grades Computacionais.

Por outro lado, a rea de sistemas distribudos preocupou-se mais com aspectos ligados comunicao, heterogeneidade e compartilhamento de recursos computacionais, principalmente informaes por meio de arquivos. Com o surgimento da Internet e da Web, por meio de protocolos como o TCP/IP e HTML e redes Ethernet, os sistemas distribudos atingiram uma escalabilidade global propiciando a criao do comrcio eletrnico, redes de troca de arquivos, teleconferncias etc. Esta evoluo

resultou nas redes P2P (peer-to-peer) como Kazaa, Gnutella e Emule, que permitem o compartilhamento de qualquer tipo de arquivo em nvel global [Chetty 2002] [Krauter 2001]. Como resultado da unio destas duas importantes reas da computao, surgiu o conceito de grade computacional (Figura 2). Portanto, as grades computacionais esto preocupadas em agregar supercomputadores distribudos geograficamente para o processamento de grandes massas de dados, enquanto redes P2P procuram compartilhar arquivos distribudos geograficamente e realizar processamento com computadores de pequeno porte, no caso do projeto SETI@home, e os supercomputadores (MPPs, aglomerados etc.) so computadores de grande porte dedicados para soluo de grandes problemas com o menor tempo de resposta. 11.1.2. Objetivos Com a proposta deste trabalho pretendemos atingir quatro objetivos principais: Apresentar e difundir os conhecimentos (tericos e prticos) relacionados com a computao em grade considerando os principais tpicos relacionados com: conceitos; tecnologias, aplicaes e tendncias. Apresentar de modo prtico e exemplificado, a programao de aplicaes para arquiteturas de computao em grade existentes (OurGrid, Anthill etc.). Neste minicurso, apresentamos aplicaes de minerao de dados em bases de dados reais. Incentivar os alunos a programar e utilizar computao em grade nas suas universidades nos contextos das diversas disciplinas e futuramente utilizar este tipo de sistema computacional na sua vida profissional. Produzir e disponibilizar literatura em portugus sobre computao em grade unindo tpicos tericos e prticos, j que a quantidade de material - com este enfoque disponvel em portugus muito pequena. O texto est organizado da seguinte forma: a seo 2 apresenta os principais conceitos de computao em grade. A seo 3 apresenta as tecnologias atuais de computao em grade. A seo 4 apresenta as principais aplicaes para computao em grade, com nfase em aplicaes de minerao de dados e finalmente a seo 5 apresenta algumas concluses, tendncias atuais e futuras, terminando com uma discusso sobre possveis trabalhos futuros na rea de computao em grade.

11.2. Conceitos de Computao em Grade

Muitos domnios de aplicaes, nos quais problemas com alta demanda de processamento e armazenamento de dados podem ser divididos em sub-problemas e resolvidos individualmente, so os mais indicados para a execuo em grades computacionais. Entre essas aplicaes, podemos destacar simulaes de Monte Carlo, projeto de remdios, operaes de pesquisa e minerao de dados. Algumas destas aplicaes esto relacionadas ao termo eScience, que denota a pesquisa realizada de forma colaborativa em escala global. Este ambiente de eScience envolve o compartilhamento de instrumentos cientficos, dados distribudos, visualizao remota e interpretao colaborativa de dados e resultados, se adequando perfeitamente s caractersticas de uma infra-estrutura de computao em grade [Buyya 2005]. Portanto, em uma grade computacional devemos lidar com seis aspectos principais para suportar esses tipos de aplicaes [Buyya 2002]: Heterogeneidade: uma grade envolve uma multiplicidade de recursos que so heterogneos e envolvem uma grande variedade de tecnologias. Escalabilidade: uma grade deve crescer de algumas dezenas de recursos para milhes de recursos sem perda de desempenho. Mas devido a alta disperso geogrfica, as aplicaes de uma grade devem ser projetadas levando-se em considerao problemas com a latncia e a largura de banda para a transmisso de dados. Compartilhamento de Recursos: os recursos de uma grade computacional no podem ser dedicados para nenhuma aplicao especfica. Mltiplos Domnios Administrativos: os recursos de uma grade esto distribudos geograficamente em mltiplos domnios administrativos, onde cada organizao possui suas prprias restries e regras de uso dos recursos, que devem ser respeitadas. Controle Distribudo: em uma grade no existe um gerenciador centralizado que possui uma viso global do sistema. Ento cada componente da grade deve ser autnomo. Dinamicidade e Adaptabilidade: em uma grade, a falha de um recurso uma regra. Portanto, as aplicaes e gerenciadores de recursos devem mudar seu comportamento de acordo com a disponibilidade dos recursos. 11.2.1. Classes de Arquiteturas Existentes Uma aplicao paralela composta por vrias tarefas. As tarefas que compem uma aplicao paralela executam em vrios processadores, caracterizando desta forma o paralelismo da execuo da aplicao e conseqente reduo no seu tempo de execuo. Os processadores usados por uma determinada aplicao e o meio de comunicao entre eles caracterizam a classe de arquitetura de execuo da aplicao. As arquiteturas de aplicaes paralelas variam em diversos aspectos, dos quais destacamos conectividade, heterogeneidade, compartilhamento, imagem de sistema nico e escalabilidade. A conectividade diz respeito aos canais de comunicao que

interligam os processadores que compem a arquitetura. Atributos que definem a conectividade de uma arquitetura so: topologia, largura de banda, latncia e compartilhamento. A heterogeneidade trata das diferenas entre os processadores, que podem ser de velocidade e/ou arquitetura. O compartilhamento est relacionado possibilidade dos recursos usados por uma aplicao serem compartilhados por outras aplicaes. J a imagem de sistema nico o conjunto de computadores (multiprocessadores e/ou estaes de trabalho) que se comporta como um grande computador, ou seja, atravs de software ou hardware possvel criar-se a iluso de que todos os recursos fsicos (processadores, memrias, discos, etc.) e lgicos (processos, tarefas, memrias virtuais, sistemas de arquivos) pertencentes as mquinas que compem o arquitetura sejam um s grande recurso, tornando possvel o acesso qualquer recurso disponvel no ambiente da arquitetura, independente de sua localizao. A escalabilidade preocupase o ganho de desempenho a medida que aumenta-se o nmero de elementos de processamento e recursos em geral consumidos por uma aplicao. Entender as diferenas entre as arquiteturas fundamental, pois cada aplicao paralela e distribuda tem uma srie de requisitos, que podem ser melhores ou piores atendidos por uma dada arquitetura. Em princpio, procuramos executar uma aplicao paralela em uma arquitetura adequada s caractersticas da aplicao. Por exemplo, considere conectividade, um aspecto em que arquiteturas diferem consideravelmente. Obviamente, para obter bom desempenho de uma aplicao paralela cujas tarefas se comunicam e sincronizam freqentemente, necessitamos utilizar uma arquitetura de execuo com boa conectividade. Podemos agrupar as arquiteturas hoje existentes em quatro grandes grupos: SMPs, MPPs, NOWs e Grades. SMPs (ou multiprocessadores simtricos) so mquinas em que vrios processadores compartilham a mesma memria [Hwang 1998]. Os multiprocessadores possibilitam um forte acoplamento entre os processadores e executam uma nica cpia do sistema operacional para todos os processadores. Portanto, eles apresentam uma imagem nica de sistema e alta conectividade. Todavia, multiprocessadores apresentam limitaes de escalabilidade, raramente ultrapassando 32 processadores. Os multiprocessadores so relativamente comuns no mercado e vo desde mquinas duais Intel at grandes servidores como os IBM pSeries. A Figura 3 ilustra a arquitetura de um multiprocessador.

Figura 3. Arquitetura de um Multiprocessador Simtrico (SMP).

Os MPPs (processadores maciamente paralelos) so compostos por vrios ns (processador e memria) independentes, interconectados por redes dedicadas e de alta velocidade. Os MPPs incluem supercomputadores paralelos como o IBM SP2 e Cray T3E, como tambm aglomerados de menor porte montados pelo prprio usurio. Tipicamente cada n roda sua prpria cpia do sistema operacional, mas uma imagem comum do sistema implementada atravs da visibilidade dos mesmos sistemas de arquivo por todos os ns. Um MPP controlado por um escalonador que determina quais aplicaes executaro em quais ns. Ou seja, no se pode utilizar um n que no tenha sido alocado aplicao pelo escalonador. Isto possibilita dedicar parties (um conjunto de ns) s aplicaes, permitindo que estas no precisem considerar compartilhamento. Mas, uma vez que aplicaes executam em parties dedicadas, existe a possibilidade de no haver ns suficientes para executar uma aplicao assim que ela submetida. Neste caso, a aplicao espera em uma fila at que os recursos que solicitou estejam disponveis. A Figura 4 exemplifica a arquitetura de um MPP.

Figura 4. Arquitetura de um MPP.

As NOWs (redes de estaes de trabalho) ou aglomerados de computadores so um conjunto de estaes de trabalho ou PCs, ligados por uma rede local. As NOWs so arquiteturalmente semelhantes aos MPPs. Ambas arquiteturas so formadas por ns que agregam processador e memria. Uma diferena entre NOWs e MPPs que os ns que compem uma MPP tipicamente so conectados por redes desenvolvidas especificamente para o MPP, enquanto uma NOW composto por equipamentos de rede e processadores de prateleira ou COTS (comodity-of-the-shelf). Mas a principal diferena entre as arquiteturas a forma de escalonamento distribudo de uma NOW. Cada n tem seu prprio escalonador local. Como resultado, no h como dedicar uma partio da NOW a uma s aplicao paralela. Portanto, uma aplicao que executa sobre uma NOW deve considerar o impacto sobre seu desempenho da concorrncia por recursos por parte de outras aplicaes. A Figura 5 mostra esquematicamente uma NOW. As grades computacionais so o passo natural depois das NOWs, considerando aspectos de heterogeneidade e disperso geogrfica. Os componentes de um grades no se restringem a processadores, podendo ser SMPs, MPPs e PCs conectados como redes P2P, como tambm instrumentos digitais. As grades tipicamente no fornecem uma imagem comum do sistema para seus usurios. Os componentes da grade podem variar drasticamente em capacidade, software instalado, sistemas de arquivo montados e

perifricos instalados. Alm disso, os componentes de uma grade podem estar sobre controle de diferentes entidades e, portanto, em domnios administrativos diversos.

Figura 5. Arquitetura de uma NOW ou aglomerado de computadores.

Conseqentemente, um dado usurio pode ter acesso e permisses bastante diversas nos diferentes componentes de uma grade. Obviamente, uma grade no pode ser dedicada a um usurio, embora seja possvel que algum componente possa ser dedicado (um MPP, por exemplo). importante salientar que uma aplicao em grade deve estar preparada para lidar com todo um ambiente dinmico, adaptando-se ao cenrio que se apresenta com o intuito de obter o melhor desempenho possvel no momento. A Figura 6 exemplifica uma possvel grade computacional, composta por um MPP e computadores de vrios tipos conectados via Internet. Note que um destes computadores realiza instrumentao (no exemplo, atravs de um microscpio), enquanto outro computador dispe de grande capacidade para armazenamento de dados.

Figura 6. Arquitetura de uma grade computacional.

A Tabela 1 sumariza o comportamento mdio em relao s caractersticas das arquiteturas para execuo de aplicaes paralelas e distribudas. Certas arquiteturas podem apresentar caractersticas arquiteturais adicionais que influenciam no desempenho das aplicaes paralelas. Por exemplo, alguns MPPs oferecem suporte de hardware a memria compartilhada, atravs de um modelo denominado DSM (Distributed Shared Memory), que melhora o desempenho de aplicaes baseadas em memria compartilhada. Uma vez que as grades computacionais so o nosso foco neste texto, referimos [De Rose 2002] caso o leitor queira mais detalhes sobre arquiteturas de execuo de aplicaes paralelas tradicionais (SMPs, MPPs e NOWs).
Tabela 1 Resumo das caractersticas tpicas de diferentes arquiteturas. SMPs Conectividade Heterogeneidade Compartilhado Imagem Escalabilidade excelente Nula No nica 10 MPPs muito boa baixa no comum 1.000 NOWs boa mdia sim comum 1.000 Grades mdia/ruim alta sim mltipla 100.000

Mesmo quando no h distines arquiteturais, diferentes arquiteturas do mesmo tipo podem diferir consideravelmente. Em particular, uma grade pode diferir radicalmente de outro. Por exemplo, considere o TeraGrid [TeraGrid 2005] e o SETI@home [SETI 2005]. O TeraGrid uma grade que interliga 4 centros de supercomputao norte-americanos atravs de canais de altssima velocidade (40 GigaBits/segundo). Cada um dos 4 centros ter milhares de processadores dedicados ao TeraGrid, gerando um poder agregado de 13,6 TeraFlops. O SETI@home, por outro lado, utiliza a capacidade computacional ociosa de computadores que se juntam voluntariamente ao sistema atravs da instalao do software cliente do projeto. Em fevereiro de 2000, SETI@home contava com 1.6 milhes de processadores espalhados em 224 pases, e computava em mdia a uma velocidade de 10 Teraflops. Embora o SETI@home tenha reportado uma desempenho compatvel com o TeraGrid, patente a diferena entre as duas grades. O TeraGrid mais acoplado que o SETI@home. O conceito de acoplamento da grade (i.e. quo prximos esto seus componentes) fundamental para compreendermos quais aplicaes podem executar eficientemente em uma grade. Voltando ao exemplo acima, o SETI@home se presta somente para execuo de aplicaes leves (i.e. levemente acopladas), enquanto o TeraGrade pode propiciar condies para execuo eficiente de aplicaes pesadas (i.e. fortemente acopladas). 11.2.2. Arquitetura de uma Grade Computacional Em uma grade computacional, as funcionalidades necessrias na infra-estrutura so: armazenamento remoto; publicao de bases de dados usando nomeao lgica global; autenticao e autorizao de acesso; acesso transparente a recursos remotos; publicao de servios e acesso de custo; composio de aplicaes distribudas usando diversos componentes de software; descoberta de bases de dados e recursos computacionais;

mapeamento e escalonamento de tarefas; submisso e monitorao da execuo de tarefas etc [Buyya 2005]. Os vrios componentes de uma grade necessrios para prover essas funcionalidades so divididos em camadas mostradas na Figura 7: Grid Fabric, Core Grid, User-Level Grid e Grid Applications [Buyya 2002] [Buyya 2005]. Gride Applications: as aplicaes em grade so tipicamente desenvolvidas usando ambientes de programao de grade, servios de descoberta, interfaces e escalonamento de servios providos por um middleware de nvel de usurio. Um exemplo de aplicao, tal como simulao de parmetros ou um problema de grande desafio, poderia requerer poder computacional, acesso a bases de dados remotas e pode interagir com instrumentos cientficos. User-Level Grid: esta camada composta de middlewares que utilizam interfaces que fornecem abstraes e servios de alto nvel. Isto inclui ambientes de desenvolvimento de aplicaes, ferramentas de programao e resource brokers para gerenciamento de recursos e escalonamento de aplicaes.

Figura 7. Arquitetura em Camadas de uma Grade Computacional

Core Grid: esta camada composta de middlewares que oferecem servios tal como gerenciamento remoto de processos, co-alocao de recursos, acesso de armazenamento, registro e descoberta de informaes, segurana e aspectos de QoS. Estes servios abstraem a complexidade e heterogeneidade da Grid Fabric, provendo um mtodo consistente para acessar recursos distribudos. Grid Fabric: esta camada consiste de recursos distribudos tal como computadores, redes de interconexo, dispositivos de armazenamento e instrumentos cientficos. Os

recursos computacionais representam mltiplas arquiteturas tal como aglomerados, supercomputadores, servidores e PCs que executam diferentes sistemas operacionais. Os instrumentos cientficos, tal como telescpios e redes de sensores, provm dados em tempo real que podem ser transmitidos diretamente a sites de computao ou armazenadas em uma base de dados. Com relao ao projeto de grades, elas podem ser divididas em trs categorias: grades computacionais, grades de dados (data grid) e grades de servios [Krauter 2001]. A categoria de grade computacional est relacionada com infraestruturas que possuem maior capacidade de processamento para execuo de aplicaes paralelas e distribudas. Geralmente, grades computacionais procuram diminuir o tempo de resposta de aplicaes ou aumentar a vazo do sistema. As grades de dados so infraestruturas para sintetizao de informaes novas de repositrios de dados como bibliotecas digitais e data warehouses que esto distribudos em uma rede de alta escala. Elas possuem servios de gerncia de armazenamento e acesso de dados para as aplicaes. Por ltimo, uma grade de servios uma infraestutura que fornece servios que no podem serem providos por apenas uma mquina, como interligao de grupos colaborativos, agregao de recursos para visualizao de dados que permita um cientista aumentar a confiabilidade de suas simulaes e aplicaes multimdia de tempo real. 11.2.3. Modelo Operacional de uma Grade Computacional Em um ambiente de computao em grade, na viso do usurio da grade computacional, existe uma modelo operacional com etapas comuns para a execuo de uma aplicao. Esstas estapas esto descritas abaixo e ilustradas pela Figura 8 [Buyya 2005]: 1) O usurio programa a sua aplicao distribuda utilizando ferramentas de desenvolvimento de aplicaes. Esta aplicao pode seguir diversos modelos de programao: passagem de mensagens, bag-of-tasks (BoT), fluxo de dados com filtros etc. 2) O usurio especifica os seus requisitos de QoS e submete sua aplicao ao escalonador de aplicao da grade. Por exemplo, no ambiente Ourgrid, o usurio especifica os recursos necessrios para a sua aplicao como tamanho da memria e sistema operacional. Ento ele submete a sua aplicao ao escalonador de aplicao MyGrid. 3) O escalonador de aplicao de recursos da grade realiza uma descoberta de recursos e suas caractersticas usando o servio de infromao da grade. 4) O escalonador de aplicao de recursos identifica os preos e/ou a disponibilidade dos recursos por meio de uma busca em um diretrio de mercado da grade. 5) O escalonador de aplicao de recursos identifica uma lista de fornecedores de dados ou rplicas e recurso computacionais que fornecem os servios ou

caractersticas necessrios pela aplicao, por meio dos escalonadores de recursos. Ento ele seleciona os melhores fornecedores. 6) O escalonador de aplicao escalona e envia as tarefas para os escalonadores de recursos que so responsveis pelos recursos escolhidos para a execuo das aplicaes. 7) O agente local do usurio no recurso executa e monitora a tarefa e retorna os resultados para o escalonador. Enquanto o escalonador de aplicao monitora a grade pra lidar com eventuais falhas nos recursos e mudanas de configuraes da grade. 8) O escalonador de aplicao coleta os resultados e repassa para o usurio.

Figura 8. Modelo Operacional de uma Grade Computacional

11.3. Tecnologias de Computao em Grade

Vrios sistemas para suporte computao em garde surgiram nos ltimos anos, tanto atravs de esforos acadmicos (e.g. Globus, Gridbus, Legion, Condor, MyGrid, Anthill), quando decorrentes de empreendimento comerciais (e.g. Entropia, distributed.net). Dentre os esforos acadmicos, Globus foi de longe o projeto que teve maior impacto. Todavia, Globus no soluciona todos os problemas existentes na computao em grade. importante tambm conhecer alternativas e, principalmente, solues complementares a Globus. Quanto aos esforos comerciais, ainda muito cedo para determinar seu impacto. Alm disso, pela prpria natureza comercial destes esforos, muito menos detalhes tcnicos esto disponveis sobre o funcionamento de tais sistemas. Em particular, um aspecto que necessita melhor definio por parte da Entropia e da distributed.net diz respeito a abertura dos seus sistemas, i.e. a capacidade de interoperar com outros sistemas para computao em grade. 11.3.1. Globus Globus consiste de um conjunto de servios que facilitam computao em grade [Foster 1998]. Os servios Globus podem ser usados para submisso e controle de aplicaes, descoberta de recursos, movimentao de dados e segurana na grade. Os principais servios Globus disponveis atualmente (na verso 2.0) so apresentados na Tabela 2.
Tabela 2. Principais Servios do Globus. Servio GSI GRAM Nexus MPI-G MDS GASS GridFTP Funcionalidade Segurana, autenticao nica na grade Submisso e controle de tarefas Comunicao entre tarefas MPI sobre Nexus Informaes e diretrios Transferncia de arquivos Transferncia de arquivos

11.3.1.1. Segurana e Autenticao Um aspecto que complica o uso de grades na prtica a autenticao de usurios em diferentes domnios administrativos. Em princpio, o usurio tem que se autenticar para cada domnio administrativo de uma forma determinada pelo administrador do domnio (que tipicamente envolve fornecer uma identificao de usurio e uma senha). Este esquema coloca uma grande carga no usurio (quem usa vrios sites Web que exigem login, tem uma idia bem concreta destes problemas). No contexto de computao em grade, os problemas de mltipla autenticao so agravados pois queremos ter programas que possam efetuar aes que exigem autenticao (e.g. submeter uma tarefa a um site remoto).

GSI (Globus Security Infrastructure) o servio Globus que ataca este problema. GSI viabiliza o login nico na grade. GSI utiliza criptografia de chave pblica, certificados X.509 e comunicao SSL (Secure Sockets Layer) para estabelecer a identidade Globus do usurio. Por exemplo, C=US, O=University of California San Diego, OU=Grid Computing Lab, CN=Walfredo Cirne era nossa identidade em Gusto (a primeira grade montado com Globus). Depois do usurio ter se identificado junto ao GSI, todos os demais servios Globus sabero, de forma segura, que o usurio de fato quem diz ser. Uma vez que um servio sabe a identidade Globus do usurio, resta estabelecer quais operaes tal usurio pode realizar. Isto feito mapeando a identidade Globus para um usurio local. Por exemplo, o servio GRAM (submisso e controle de tarefas) instalado em t hing1.ucsd.edu mapeava C=US, O=University of California San Diego, OU=Grid Computing Lab, CN=Walfredo Cirne para walf r edo. J o GRAM que rodava em bluehor izon.sdsc.edu mapeava C=US, O=University of California San Diego, OU=Grid Computing Lab, CN=Walfredo Cirne para u15595 . 11.3.1.2. Alocao e Descoberta de Recursos As grades no tm um escalonador que controla todo o sistema. Assim sendo, quando um usurio que submeter uma aplicao para execuo na grade, o usurio utiliza um escalonador de aplicao que escolhe os recursos a utilizar, particiona o trabalho entre tais recursos, e envia tarefas para os escalonadores dos recursos, como ilustrado pela Figura 9. Em Globus, os escalonadores de recurso so acessados atravs do servio GRAM. O GRAM fornece uma interface nica que permite submeter, monitorar e controlar tarefas de forma independente do escalonador de recursos. Assim sendo, escalonadores de aplicao no precisam entender dos detalhes particulares de cada escalonador de recurso. Para facilitar ainda mais a tarefa dos escalonadores de aplicao, o Globus tambm disponibiliza MDS (Metacomputing Directory Service), um servio de informao sobre o Grade. O MDS contm informaes sobre os recursos que formam a grade e tambm sobre seu estado (carga, disponibilidade, etc). Uma idia bastante interessante em Globus que escalonadores de aplicao podem usar os servios de outros escalonadores de aplicao. O escalonador que recebe a solicitao do cliente lida com a especificao em mais alto nvel. Ele refina tal especificao e, para implement-la, submete novas solicitaes a escalonadores de recurso (que de fato executam solicitaes) e/ou escalonadores de aplicao (que utilizam outros escalonadores para executar solicitaes). O Globus suporta bem esta hierarquia de escalonadores atravs da linguagem RSL (Resource Specification Language). O RSL capaz de expressar tanto solicitao de alto nvel (como a que o usurio envia a seu escalonador de aplicaes), como tambm solicitaes concretas (que so enviadas para GRAMs, que as traduzem para escalonadores de recurso locais). Portanto, o trabalho de um escalonador de aplicao em Globus pode ser descrito como sendo o de refinar solicitaes RSL. A Figura 9 ilustra este processo. Note que o Globus usa o broker para o que chamamos de escalonador de aplicao. J o co-alocador (co-allocator) um escalonador de aplicao especializado em garantir que tarefas localizadas em mquinas distintas executem

simultaneamente. O co-alocador fundamental para execuo em grades de aplicaes fortemente acopladas. Em aplicaes fortemente acopladas, as tarefas precisam se comunicar para que a aplicao faa progresso. Portanto, todas as tarefas da aplicao tm que ser executadas simultaneamente. importante ressaltar que uma boa implementao de co-alocao depende da implementao, por parte dos escalonadores de recurso, do servio de reserva adiantadas (advance reservation). As reservas adiantadas permitem a escalonadores de aplicao obter garantias de escalonadores de recurso que determinados recursos (e.g. processadores) estaro disponveis para aplicao em um intervalo de tempo preestabelecido [Smith 2000].

Figura 9 Processo de especializao de requisio [Foster 1998].

A Figura 10 apresenta um exemplo da submisso de uma aplicao em uma grade Globus. Veja que um usurio envia uma solicitao de executar uma simulao interativa envolvendo 100.000 entidades para um escalonador de aplicao especializado em simulao interativa distribuda. Tal escalonador converte a solicitao original em outra mais especifica, que descreve a necessidade do usurio em termos de ciclos, memria e latncia de comunicao. Esta nova solicitao ento enviada a um escalonador de aplicao especializado em MPPs. Este escalonador consulta o MDS para descobrir quais MPPs (dentro aqueles aos quais o usurio tem acesso) so os melhores para utilizar no momento. Alm disso, o escalonador especializado em MPPs faz a partio do trabalho entre os MPPs escolhidos e envia a solicitao mais refinada para o co-alocador. O co-alocador garante que as tarefas submetidas aos distintos MPPs comecem a executar simultaneamente. Note tambm que outros escalonadores de aplicaes podem participar do sistema. A Figura 10, por exemplo, exemplifica ainda escalonadores para varredura de parmetros e para ambientes de colaborao virtual.

Figura 10. Exemplo de submisso de aplicaes a grade Globus [Foster 1998].

11.3.1.3. Comunicao O problema de comunicao na grade pode ser visto como uma instncia do eterno conflito entre generalidade e desempenho. Caso utilizemos um mecanismo de comunicao genrico (e.g. TCP) que viabilize a comunicao fim-a-fim entre quaisquer duas tarefas na Grade, perdemos desempenho em casos especiais (e.g. se ambas tarefas rodam em uma mquina de memria compartilhada, elas poderiam se comunicar muito mais rapidamente pela memria). Por outro lado, gostaramos de usar um mecanismo genrico para no ter que programar para cada uma das vrias tecnologias de comunicao existentes. O Globus ataca este problema com o Nexus. O Nexus fornece uma interface de baixo nvel, mas uma implementao adaptvel que escolhe dentre as tecnologias de comunicao disponveis, a que vai oferecer melhor desempenho. Por exemplo, se ambas tarefas esto em uma mquina de memria compartilhada, o Nexus utilizar a memria para efetuar a comunicao. Caso as tarefas estejam em um MPP, Nexus utilizar o switch de alta velocidade para comunicao. Caso as tarefas estejam em mquinas geograficamente distantes, o Nexus utilizar TCP/IP. O Nexus fornece uma interface de relativo baixo nvel: invocao remota de procedimento, mas sem retorno de resultado. Portanto, programar diretamente em Nexus no das tarefas mais agradveis. Entretanto, a idia da equipe Globus que Nexus seja usado por desenvolvedores de ferramentas e mecanismos de comunicao, no diretamente pelo desenvolvedor de aplicaes. O MPI-G o exemplo perfeito desta abordagem. O MPI-G implementa o popular padro MPI (Message Passing Interface) sobre Nexus. Assim, o desenvolvedor de aplicaes escrever em MPI e link-editar sua aplicao com MPI-G para automaticamente ter acesso a melhor tecnologia de comunicao disponvel (selecionada pelo Nexus).

11.3.1.4. Transferncia de Dados A necessidade de acesso remoto e transferncia de dados uma constante na computao em grade. Na verdade, vrias das aplicaes aptas a executar na grade necessitam de paralelismo, exatamente porque processam enormes quantidades de dados. Ciente deste fato, o Globus logo disponibilizou GASS (Global Access to Secundary Storage), um servio para acesso remoto a arquivos sob a tutela de um servidor GASS. O cliente GASS uma biblioteca C que link-editada aplicao usuria do servio. Com o intuito de fornecer boa desempenho, o servio GASS implementa as otimizaes tpicas de acesso remoto como caching e pre-fetching. Apesar de ser um bom servio, o GASS encontrou problemas de implantao. A dificuldade encontrada foi a interoperabilidade. A maioria das fontes de dados onde se instalaria um servidor GASS j executa algum servio de transferncia e/ou acesso remoto aos arquivos. Os administradores de sistema se questionavam porque no se poderia usar os servios existentes. Essa realidade motivou a introduo do GridFTP [Allcock 2002] por parte da equipe Globus. O GridFTP estende o popular protocolo FTP para torn-lo mais adequado para as necessidades da computao em grade. Mais precisamente, o GridFTP introduz suporte a: Autenticao GSI e Kerberos. Transferncia em paralelo (vrias conexes TCP entre fonte e destino). Transferncia em faixas (conexes TCP entre vrias fontes e um destino). Controle manual dos buffers TCP (usado para afinamento de desempenho). Instrumentao embutida. Uma vez que o GridFTP uma extenso do FTP, o problema de interoperabilidade fica resolvido, pois FTP amplamente suportado pelos servidores de dados. Obviamente, se as extenses GridFTP no estiverem implementadas em um dado servidor, os benefcios adicionais do protocolo no estaro disponveis. Mas o cliente GridFTP ainda ser capaz de obter os dados desejados. 11.3.1.5. OGSA/OGSI/Globus 3.x No intuito de realizar a viso da orientao a servios, houve um convergncia de tecnologias da rea de computao de alto desempenho e de padres bem consolidados pela indstria, isso ocorreu atravs da unio de tecnologias e conceitos grades com web services [Kreger 2003]. A partir disto foi definida uma arquitetura de servios bsicos para a construo de uma infraestrutura de Grades Computacionais baseados em Servios. Esta arquitetura foi denominada Open Grid Services Architecture, OGSA [Foster 2002]. A definio do OGSA contempla a idia de interconexo de sistemas e acriao de ambientes virtuais multi-institucionais. Alm disso, os recursos que podem ser agregados grade so representados por servios e estes servios so chamados de Grid Services [Foster 2002]. Os grid services so essencialmente web services que seguem convenes estabelecidas na especificao da OGSA e suportam interfaces padronizadas

para garantir algumas operaes adicionais, como gerenciamento do ciclo de vida do servio. As interfaces padres definidas pelo OSGA facilitam a virtualizao de recursos e servios. Isso possibilita o uso de vrios tipos de recursos de forma transparente. Outra vantagem da virtualizao que interfaces padres permitem um baixo acoplamento entre o cliente e o provedor do servio. Esse baixo acoplamento facilita a mudana na implementao dos servios sem causar, necessariamente, mudanas na implementao do cliente, bem como o inverso. Aps a definio do modelo da arquitetura e identificao de servios bsicos atravs do padro OGSA foi necessria a especificao do comportamento desses servios. Sendo assim, o passo seguinte foi a especificao dessa infraestrutura servios bsicos, no intuito de permitir a implementao do modelo da arquitetura definida pela OGSA. A nova especificao foi denominada Open Grid Services Infrastructure (OGSI) [Alliance 2003] e tem o objetivo de definir as interfaces bsicas e os comportamentos de um Grid Service [Alliance 2003]. OGSI a materializao da arquitetura definida pelo padro OSGA, pois os servios especificados servem como base para construo das grades. Em termos prticos, a especificao OSGI define: Um conjunto de extenses para a linguagem WSDL (Web Service Description Language). Padres de estrutura e operao, em WSDL, para representao pesquisa e atualizao de dados sobre os servios. As estruturas Grid Service Handle e Grid Service Reference usados para referenciar um servios. Formato para mensagens que indicam falhas, sem modificar o modelo de mensagens de falha da linguagem WSDL. Conjunto de operaes que permitem a criao e destruio de Grid Services. Esse conjuntos de operaes devem fornecer destruio explcita de servios, como tambm garbage collection (destruio implcita do servio). Conjunto de operaes para criao e uso de colees de Web Services por referncia. Mecanismos que permitam notificao assncrona, caso haja mudana em valores dos elementos de dados dos servios.

O Globus Toolkit 3.0 (GT3) [Foster 1997] forneceu a primeira implementao da OGSI 1.0 em julho de 2003. No intuito de esclarecer melhor o papel de OGSA, OGSI e Globus. Note, portanto, que Grid Service um conceito central no relacionamento destas tecnologias e padres. Assim, OGSA define Grid Services, OGSI especifica o comportamento de Grid Services, Web Services so estendidos para se tornar Grid Services e Globus 3 implementa a especificao OGSI. Alm disso, Globus prov servios bsicos necessrios para a construo de servios de mais alto nvel (e.g. servios de autenticao via GSI).

11.3.1.6. WSRF/Globus 4.x Uma vez que toda a base de Grid Services surgiu das tecnologias para Web Services, alguns aspectos da especificao OGSI precisavam ser refinados devido a evoluo da arquitetura Web Services. O principal ponto de crtica foram os mecanismos de endereamento para os servios (i.e. Grid Service Handler e Grid Service Reference). Nesse caso, WSAddressing surgiu pra fornecer um mecanismo de endereamento independente da camada de transporte [Alliance 2003]. Alm disso, outras caractersticas de OGSI precisavam ser modificadas para acompanhar a evoluo da tecnologia Web Service, melhorando assim a especificao OGSI. Assim, WSRF (Web Service Resource Framework}) basicamente o resultado do refinamento de OGSI no intuito de aproveitar a existncia dos novos padres que surgiram para para Web Services (e.g. WS-Addressing, WS-Notification) e assimilar a demanda da comunidade Web Services. O primeiro efeito do refatoramento foi a diviso de OGSI em vrias especificaes separadas, porm agrupadas em uma famlia. A idia reduzir a complexidade de uma especificao longa, que dificulta a adoo incremental de funcionalidades. Outra medida importante foi a recuperao da compatibilidade com as ferramentas existentes para XML e Web Services, pois OGSI usa GWSDL, a qual prov acrscimos WSDL 1.1 que estaro disponveis na WSDL 1.2/2.0. Ao contrrio de OGSI, ao invs de estender a definio de portType WSDL 1.1, ou mesmo esperar pelo da nova verso WSDL 2.0, WS-Resource Framework utiliza puramente WSDL 1.1, o que garante compatibilidade com as ferramentas existentes para Web Services. Alguns entusiastas da rea de Web Services, em geral, argumentam que Web Services no devem manter estado ou ter instncias. Ou seja, OGSI modela um recurso que mantm estado como um Web Service que encapsula o estado do recurso. WSResource Framework modifica esse modelo para criar uma distino explcita entre servio e entidades que mantm estado e so manipuladas atravs do servio. Esta composio denominada WS-Resource pelo padro WSRF, que introduz a idia de recursos que mantm estados e podem ser acessados atravs de Web Services via o uso convencional de WS-Addressing. Portanto, em linhas gerais, a evoluo de OGSI obedeceu trs fases de forma incremental. A primeira, a introduo do conceito de WS-Resource. Em seguida a diviso de funcionalidades em vrias especificaes melhorando a compatibilidade com ferramentas usadas para Web Service. Finalmente, uma melhoria nos mecanismos de notificao. O padro WSRF deve se materializar, de forma estvel, atravs do lanamento do Globus 4. Atualmente, o Globus se encontra na verso 3.9.5, que apesar de instvel j incorpora vrias das funcionalidades contempladas no padro WSRF. Por exemplo, o GRAM do Globus 3, ser substitudo pelo WS-GRAM, o qual segue as especificaes definidas na famlia de padres WSRF.

11.3.1.7. Avaliao do Globus Um aspecto importante para grande aceitao do Globus que os servios oferecidos so razoavelmente independentes, possibilitando que se utilize apenas parte dos servios Globus em uma dada soluo. Essa possibilidade do uso parcial de Globus ajuda bastante na adaptao de aplicaes paralelas existentes para a grade. Pode-se comear usando servios mais bsicos e ir, aos poucos, incorporando funcionalidades mais avanadas. O projeto oposto abordagem conjunto de servios independentes do Globus exemplificado pelo Legion [Grimshaw 1997]. O Legion fornece um modelo orientado por objetos poderoso e flexvel. Entretanto, o usurio tem que abraar a soluo Legion integralmente, sem estgios intermedirios. Esta diferena de abordagem talvez tenha contribudo para prevalncia do Globus como padro de facto como infra-estrutura para computao em grade. interessante notar que a deciso de estruturar Globus como um conjunto de servios independentes deixa claro que Globus no uma soluo pronta e completa (plug-and-play) para construo de grades. O Globus certamente fornece servios teis para computao em grade, mas desenvolvedores, administradores e usurios precisam despender certo esforo para finalizar a instalao de sua grade. Por exemplo, administradores precisam decidir como e quais usurios tero acesso a quais recursos e em quais condies este acesso se dar. Em outro exemplo, freqentemente necessrio desenvolver escalonadores de aplicao que tenham conhecimento sobre as aplicaes que sero executadas e eventualmente tambm sobre a estrutura da grade a ser usada. A computao em grade simplesmente muito complexa para possibilitar solues plug-and-play. Portanto, o fato do Globus no ser uma soluo pronta e completa no nenhum demrito. Entretanto, algumas pessoas tm a idia de que Globus a soluo completa e perfeita. Esta falsa concepo um problema, pois gera falsas expectativas e obscurece discusses tcnicas com alegaes de marketing. A introduo do padro OGSA criou um alinhamento com tecnologias e padres Web Services, assim vrios desses aspectos discutidos anteriormente se modificaram em busca da implementaes de padres que promovem maior interoperabilidade. A arquitetura do Globus Toolkit 3 uma implementao da especificao OGSI (Open Grid Services Infrastructure), os servios implementados na camada GT3 Core Services representam os servios especificados pela OGSI. O objetivo especificar mecanismos para criao, gerenciamento e troca de dados entre Grid Services. Como discutimos anteriormente, h uma tendncia forte de convergncia entre as tecnologias de Grades Computacionais e Web Services. Isso fica claro com a introduo da especificao WSRF, que posiciona as tecnologias de grades junto aos padres para Web Services. 11.3.2. Gridbus O projeto Gridbus um projeto cdigo aberto e multi institucional comandado pelo GRIDS Lab na University of Melbourne. O seu principal objetivo o projeto e desenvolvimento de tecnologias de middleware para grades orientadas por servio para o suporte de aplicaes de eScience e eBusiness. Ele prov uma camada de abstrao que esconde as peculiaridades dos recursos heterogneos middlewares de baixo nvel

dos desenvolvedores de aplicaes. Alm disso, o Gridbus usa modelos econmicos para o gerenciamento eficiente de recursos compartilhados. Portanto, ele aumenta a possibilidade de negociao de servios de grade gerencia eficientemente o fornecimento e a demanda de recursos. O Gridbus suporta a especificao de servios de grade em vrios nveis: (i) Raw Resource Level pela venda de ciclos de CPU e recursos de armazenamento; (ii) Application Level por operaes de modelagem de molculas para aplicaes de projeto de novos remdios; (iii) Aggregated Services pela busca de servios atravs de mltiplos domnios [Asadzadeh 2005].

Figura 11. Arquitetura do GridBus [Asadzadeh 2005].

A Figura 11 mostra a arquitetura em camadas do Gridbus mostrando alguns de seus componentes em conjunto com outras tecnologias de middleware (como Globus). O Gridbus prov tecnologias de software distribudas nas seguintes categorias [Asadzadeh 2005]: Infra-Estrutura de Grade Empresarial: o software Alchemi lida com a necessidade das empresas em aproveitar os ciclos ociosos dos computadores Windows da organizao. Alocao de Recurso e Economia de Cluster: a tecnologia Libra um sistema de escalonamento em aglomerados que garante um certo compartilhamento de recursos para a aplicao de um usurio, que deve executar at um determinado deadline. Economia de Grade e Empresa Virtual: o Grid Market Directory um servio de registro, onde os provedores de servios podem registra-se e publicar servios que eles provm e consumidores podem procurar por servios que atendem aos seus requisitos. Negociao da Grade e Servios de Contas: o Grid Bank um servio de contas e pagamento que prov uma infra-estrutura segura para o pagamento pelo uso dos servios prestados pelos provedores de recursos.

 Busca e Escalonamento de Recursos na Grade: o Gridbus Broker prov uma abstrao complexidade das grades garantindo a transparncia de acesso a recursos de dados e computacionais para a execuo de uma tarefa na grade. Ele utiliza requisitos do usurio para a criao de um conjunto de tarefas, descoberta de recursos, escalonamento, execuo e monitoramento das tarefas. Gerenciamento de Trfego da Grade (Gridbus Workflow Engine). Interface de Programao de Aplicaes (Visual Parametric Modeller). Portais da Grade: a ferramenta GMonitor um portal web para monitoramento de computaes em grades globais. Simulao da Grade: o Gridsim uma ferramenta de simulao que suporta modelagem e simulao discreta por eventos de arquiteturas em grade heterogneas, tal como mono ou multiprocessadores, mquinas de memria compartilhada e distribuda, e escalonamento de tarefas em sistemas paralelos e distribudos (aglomerados de computadores etc.). Atualmente existem diversas aplicaes e ferramentas de grade que utilizam o Gridbus, dentre elas: ePhysics Portal, Australian Virtual Observatory, Belle Analysis Data Grid, NeuroGrid, HydroGrid e Amsterdam Private Grid [Asadzadeh 2005]. 11.3.3. Condor O Condor um sistema que objetiva fornecer grande quantidade de poder computacional a mdio e longo prazo (dias a semanas) utilizando recursos ociosos na rede [Litzkow 1988]. Os autores do sistema salientam insistentemente que o Condor tem como objetivo a alta vazo (high throughput) e no alto desempenho [Basney 1999] [Epema 1996] [Frey 2001] [Litzkow 1988]. Entenda-se disto que Condor visa fornecer desempenho sustentvel a mdio e longo prazos, mesmo que o desempenho instantneo do sistema possa variar consideravelmente. O usurio submete ao Condor tarefas independentes para execuo. Isso significa que uma aplicao Condor uma aplicao Bag of Tasks (BoT). Enquanto este fato limita as aplicaes que podem ser executadas no Condor, deve-se salientar que h um grande nmero de aplicaes importantes que so BoT. Alm disso, aplicaes BoT, devido ao seu fraco acoplamento, so bastante adequadas para execuo em grades computacionais. O Condor foi inicialmente concebido para funcionar em NOWs. Uma NOW que executa Condor denomina-se Condor Pool. O elemento arquitetural mais importante de um Condor Pool o Matchmaker. O Matchmaker aloca tarefas a mquinas pertencentes ao Pool. Tal alocao baseada nas necessidades de cada tarefa e nas restries de uso de cada mquina. As necessidades de uma tarefa so especificadas pelo usurio quando de sua submisso. Por exemplo, uma tarefa pode precisar de uma mquina Sun Sparc, rodando Solaris, com pelo menos 256MB de memria. J as restries de uso de uma dada mquina, estas so especificadas por seu dono quando da incluso da mquina no Pool. Por exemplo, o dono pode preferir que sua mquina execute as aplicaes de Joo, seguido das aplicaes do grupo de sistemas operacionais, e que nunca execute as

aplicaes de Pedro. Ou seja, as restries permitem ao dono determinar como sua mquina ser usada no Condor Pool. Tipicamente, o que o dono estabelece inclui que sua mquina s usada quando estiver ociosa e que, quando ele voltar a utilizar a mquina, qualquer aplicao Condor em execuo seja suspensa imediatamente. Um aspecto interessante do Condor que ambos usurios e donos de mquinas so representados no sistema por agentes de software. O Agente do Usurio (Customer Agent) envia as necessidades da tarefa para o Matchmaker. Similarmente, o Agente do Dono (Resource Owner Agent) envia as restries de uso do recurso ao Matchmaker. Ao efetuar o casamento entre tarefa e mquina, o Matchmaker notifica ambos agentes. A partir da, o Agente do Usurio e o Agente do Dono interagem diretamente para realizar a execuo da tarefa. A Figura 12 ilustra este protocolo.

Figura 12. Condor Matchmaking [Basney 1999].

Outro aspecto atraente do Condor seu mecanismo de checkpointing. Uma vez que o dono normalmente especifica que sua mquina seja desocupada pela tarefa Condor assim que ele retornar a us-la, garantir progresso das tarefas torna-se um problema no-trivial. O Condor aborda esta questo fazendo o checkpoint da tarefa (i.e. salvando transparentemente seu estado), o que permite que a tarefa seja re-executada em outra mquina a partir do ponto em que parou. O mecanismo de checkpoint do Condor implementado atravs da substituio da biblioteca do sistema por uma biblioteca Condor. Note, portanto, que o mecanismo de checkpointing implementado em conjunto com o mecanismo de re-direcionamento de acesso a arquivos. Na verdade, o acesso aos arquivos na mquina base e migrao de tarefas so complementares. O Condor foi inicialmente concebido para execuo em NOWs [Litzkow 1988], mas posteriormente estendido para execuo em grades [Epema 1996] [Frey 2001]. O que tornou possvel extenso relativamente simples do Condor de NOWs a grades coputacionais, foi o fato da aplicao suportada (BoT) ser bastante adequada a grades computacionais. interessante notar que Condor dispe de duas formas de funcionamento em grades: Flock of Condors [Epema 1996] e Condor-G [Frey 2001]. O Flock of Condors um trabalho que antecede Condor-G. Um Flock of Condors uma grade formada por vrios Condor Pools[Epema 1996]. A construo do Flock bastante elegante do ponto de vista de sistemas distribudos, pois no acrescenta nenhuma centralizao a arquitetura Condor original. A base para criao de um Flock

um acordo de cooperao (de troca de recursos) entre dois Condors Pools. Portanto, por maior que seja o Flock, suas ligaes so sempre dois-a-dois, sem envolver nenhuma entidade centralizadora. Mais que isso, o Flock of Condors no chega a alterar o software Condor original. Toda a funcionalidade do Flock of Condors implementada por uma mquina especial, chamada Gateway. Ambos os Pools que firmam um acordo de cooperao instalam cada qual um Gateway. Os dois Gateways mantm comunicao constante para troca de tarefas entre os Pools. Para o Pool local, o Gateway uma mquina qualquer. Entretanto, ao invs de oferecer seus prprios recursos, o Gateway simplesmente representa os recursos do Pool remoto, republicado as restries estabelecidas pelos donos das mquinas remotas. Quando uma tarefa recebida pelo Gateway, este a repassa para o Gateway remoto que ento a encaminha para uma mquina para execuo. Talvez por ser mais recente, o Condor-G adota uma viso mais heterognea de grade. Alm de Condor Pools, o Condor-G tambm utiliza recursos via Globus. Devido necessidade de suportar ambientes mais heterogneos, o Condor-G usa uma arquitetura mais centralizada que o Flock of Condors. O Condor-G Scheduler controla a execuo da aplicao, submetendo tarefas tanto a Condor Pools quanto a recursos acessveis via Globus (como MPPs). No caso de recursos Globus, o Condor-G utiliza os servios GRAM, GASS, MDS e GSI para viabilizar a execuo das tarefas. 11.3.4. MyGrid A motivao para a construo do MyGrid surgiu do fato que, embora bastante pesquisa tenha sido realizada para o desenvolvimento dos grades computacionais, poucos usurios executavam suas aplicaes paralelas sobre essa infraestrutura. Assim, foi concebido projeto MyGrid, com o intuito de alterar esta situao. Para tanto, foram atacadas apenas aplicaes Bag-of-Tasks, ou seja, aquelas aplicaes cujas tarefas so independentes, podendo ser executadas em qualquer ordem. Aplicaes Bag-of-Tasks so um alvo interessante porque (i) se adequam melhor a ampla distribuio, heterogeneidade e dinamicidade da grade, e (ii) resolvem vrios problemas importantes, tais como minerao de dados, processamento genmico, pesquisa massiva (como quebra de chaves criptogrficas), varredura de parmetros, simulaes Monte Carlo (muito utilizado, por exemplo, pela indstria farmacutica [Hoffman 2005]), computao de fractais (como Mandelbrot), e manipulao de imagem (como tomografia). Estabelecido o escopo do MyGrid, nosso objetivo construir um sistema simples, completo e seguro. Por simples queremos dizer que o esforo para utilizao do MyGrid deve ser mnimo. Em particular, queremos chegar o mais prximo possvel de uma soluo pronta (plug-and-play). Por completo denotamos a necessidade de cobrir todo o ciclo de uso de um sistema computacional, do desenvolvimento execuo, passando por instalao e atualizao e incluindo tambm a manipulao de arquivos. Por seguro expressamos a necessidade de no introduzir vulnerabilidades ao ambiente computacional do usurio. Ou seja, no queremos que falhas de segurana em qualquer uma das mquinas que o usurio possa utilizar sejam propagadas para sua mquina base (i.e. o computador usado pelo usurio). MyGrid diferencia entre mquina base e mquina do grade. Em um MyGrid, a mquina base aquela que controla a execuo da aplicao. Ela tipicamente contm os

dados de entrada e coleta os resultados da computao. A mquina base normalmente usada pelo usurio diretamente no seu dia-a-dia, muitas vezes sendo o prprio computador desktop do usurio. Esperamos, portanto, que o usurio tenha excelente acesso mquina base e que tenha customizado um ambiente de trabalho confortvel nela. Todas as mquinas usadas via MyGrid para executar tarefas so chamadas de mquinas da grade. Ao contrrio da mquina base, no assumimos que o usurio customizou cada mquina da grade para criar-lhe um ambiente de trabalho familiar. Alm disso, todas as mquinas da grade tipicamente no compartilham um mesmo sistema de arquivo ou tm os mesmos softwares instalados. A imagem do sistema pode variar de uma mquina da grade para outra. Portanto, para mantermos a simplicidade de uso do sistema, precisamos evitar que o usurio tenha que lidar diretamente com as mquinas da grade. Por exemplo, queremos evitar que o usurio tenha que instalar software em cada mquina de sua grade. A idia que mquinas da grade sejam manipuladas atravs das abstraes criadas por MyGrid (descritas a seguir na Tabela 3). Um aspecto importante de MyGrid dar ao usurio a possibilidade de usar quaisquer recursos que ele tenha acesso . Este no um objetivo trivial porque ele implica que temos que assumir muito pouco a respeito de uma mquina da grade, de forma a no impedir algum usurio de usar uma mquina que no suporta nossas hipteses. Em particular, no podemos assumir que tal recurso tenha software MyGrid instalado. MyGrid define Grid Machine Interface como sendo o conjunto mnimo de servios que precisam estar disponveis para que uma dada mquina possa ser adicionada grade do usurio. Tais servios so:
Tabela 3. Servios que definem a Grid Machine Abstraction.

Servios
Execuo remota Transferncia de arquivos da mquina da grade para a mquina base Transferncia de arquivos da mquina base para a mquina da grade Interrupo de uma execuo mltipla

Como ilustrado pela Figura 13, h vrias formas de implementar os servios oferecidos atravs da Grid Machine Interface. Uma forma fornecer ao sistema scripts que implementam os servios listados na Tabela 3. Neste caso, MyGrid utiliza o mdulo Grid Script para acessar a m-quina em questo. Note que Grid Script possibilita que, qualquer que seja a mquina que o usurio tem acesso, ele possa informar como este acesso se d atravs da escrita de trs scripts. Alternativamente, h casos em que a forma de acessar uma determinada mquina da grade j do conhecimento do MyGrid. Por exemplo, suponha que a mquina em questo pode ser acessada via servios Globus (GSI, GRAM e GridFTP). Neste caso, o usurio no precisa fornecer os scripts, indicando apenas que o acesso mquina j conhecido de MyGrid. Finalmente, MyGrid tambm prov um mecanismo de acesso a mquinas da grade, chamado de User Agent. O User Agent prov servios simples. interessante notar que, pela terminologia

adotada por [Foster 2002], Grid Machine Interface uma virtualizao para os servios de acesso a uma mquina da grade.

Figura 13. Arquitetura do MyGrid.

Outro componente fundamental a arquitetura MyGrid o escalonador ou scheduler. O escalonador recebe do usurio a descrio das tarefas a executar, escolhe qual processador usar para cada tarefa, e finalmente submete e monitora a execuo da tarefa. O MyGrid possui atualmente duas heursticas de escalonamento: Workqueue with Replication (WQR [Paranhos 2003]} e Storage Affinity [Neto 2005]. Ambas, conseguem obter uma boa performance mesmo sem utilizar informaes sobre o estado do Grid ou o tamanho de cada tarefa. O WQR foi definido para aplicaes de cpu intensivas, enquanto Storage Affinity foi desenvolvido para melhorar o desempenho de aplicaes que processam grandes quantidades de dados. Note que ter um algoritmo de escalonamento que funciona bem sem depender de muita informao importante, pois simplifica a definio da Grid Machine Interface. Caso o algoritmo de escalonamento do MyGrid necessitasse de informaes sobre as mquinas da grade, Grid Machine Interface teria que ser mais rica e, portanto, mais difcil de virtualizar. Por exemplo, o Nimrod-G [Buyya 2000] define uma interface de abstrao para os recursos, que contempla mtodos de fornecimento de informao sobre o recurso. Certamente, a informao obtida por esses mtodos valiosa para o escalonamento eficiente das aplicaes. Porm, isso limita o tipo de recurso que pode ser utilizado, pois torna o middleware dependente de um recurso que fornea uma implementao para os mtodos dessa interface. Uma aplicao (ou job) MyGrid composta de tarefas independentes. Estas tarefas so compostas por trs partes ou sub-tarefas: init, remote e final. As sub-tarefas so executadas seqencialmente ($init final$). As sub-tarefas init e final so usadas para efetuar as transferncias de arquivo de entrada e sada da tarefa respectivamente.

Sendo assim, tanto a sub-tarefa inicial quando a final so executadas na mquina base. Enquanto, a sub-tarefa remote, como o prprio nome sugere, executada em uma mquina da grade e realiza a computao propriamente dita da tarefa. Para definir as sub-tarefas inicial e final, o usurio tem disponvel algumas abstraes providas pelo MyGrid para lidar com a mquina da garde sem necessitar de conhecer sua imagem do sistema. As abstraes providas pelo MyGrid so storage e playpen. O servio de storage possui a semntica de uma rea de armazenamento persistente execuo da tarefa. Ou seja, til usar storage para distribuio de arquivos que provavelmente sero reutilizados no Grid (ex.: executveis da aplicao). Assim sendo, qualquer arquivo transferido para o storage automaticamente includo no PATH da mquina da grade. Por outro lado, o playpen prov uma rea de armazenamento temporria de maneira independente das convenes locais do sistema de arquivo de uma dada mquina da grade. Essa rea de armazenamento temporria criada automaticamente e o diretrio base de execuo da sub-tarefa remote. Note que o playpen foi concebido para possibilitar o armazenamento de dados temporrios e resultados de tarefas. Tambm no sentido de simplificar a escrita das sub-tarefas, as variveis de ambiente $storage, $playpen, $proc e $task so automaticamente definidas pelo MyGrid e contm, respectivamente, o caminho completo para rea de storage, o caminho completo para o playpen de uma dada tarefa, o nome da mquina da grade escolhida para executar a tarefa e um identificador da tarefa. 11.3.4.1. OurGrid Ao contrrio do Globus, a soluo OurGrid tem um escopo diferente, porm complementar. O objetivo prover uma soluo efetiva para a execuo de aplicaes Bag-of-Tasks em Grades Computacionais. Sendo assim, as decises de projeto esto centradas no uso da soluo em ambientes de produo. Portanto, a idia bsica abdicar da generalidade, em alguns casos, no intuito de se obter uma soluo, apesar de simples, eficiente e que possa ser facilmente usada em produo. A arquitetura do OurGrid, ilustrada na Figura 13, formada por trs componentes: MyGrid Broker, OurGrid Peer e uma soluo de sandboxing baseada na mquina virtual Xen [Barham 2003]. Nas sees seguintes descreveremos como os componentes do OurGrid abordam alguns spectos importantes da Computao em Grade. 11.3.4.2. Autenticao Na arquitetura OurGrid existem basicamente dois nveis de autenticao. Esses nveis dependem de como o usurio obteve o recurso. Primeiramente, o usurio pode ter acesso direto a alguns recursos (i.e. Grid Machines - GuMs - em sua rede local), neste caso o usurio usa o esquema de autenticao tradicional, em geral, isso implica na utilizao da infraestrutura de autenticao do sistema operacional do recurso, ou seja, nome de usurio (login) e uma senha. Contudo, alm das GuMs que o usurio tem acesso direto, OurGrid permite (e promove) a obteno de acesso a GuMs de outros sites, isso ocorre atravs de um OurGrid Peer local ao site do usurio. Este peer deve estar conectado rede de favores (ver Figura 13). Assim, para as GuMs obtidas da comunidade, h uma autenticao em

duas vias baseada em certificados digitais no formato X.509. A primeira parte da autenticao deve garantir que o usurio tem permisso para solicitar servios s GuMs (i.e. que a GuM conhece o usurio que est requisitando seus servios). A segunda parte deve garantir que o usurio no est solicitando servios a uma falsa GuM. Ou seja, tanto o usurio, atravs do broker, quanto os peers da comunidade possuem uma lista de certificados que so usadas para validar a tentativa de aceso. Isso impede que usurios no autorizados pelo peer, obtenham acesso aos servios de descoberta de novas Grid Machines, transferncia de arquivos, execuo e gerenciamento do ciclo de vida de replicas fornecido pelas GuMs controladas por um dado peer. Outro aspecto importante que atravs da utilizao de certificados, a comunicao entre o MyGrid Broker, o peer e as Grid Machines ser segura, evitando que os dados sejam interceptados e manipulados durante a comunicao. A segurana na comunicao fornecida atravs do uso de RMI baseado em SSL (Secure Socket Layer), que garante comunicao criptografada. 11.3.4.3. Descoberta e Alocao de Recursos Para executar uma aplicao usando a OurGrid o usurio deve descrever sua aplicao e o conjunto de recursos que o usurio tem acesso. Note que esse conjunto de recursos pode ser apenas a indicao de um OurGrid Peer, que tem a funo de obter recursos para o usurio. A descrio da aplicao basicamente: um conjunto tarefas, seus arquivos de entrada, arquivos de sada e seus requisitos (e.g. sistema operacional necessrio, mnimo de memria, arquitetura do processador). Em seguida, o usurio o submete sua aplicao para execuo no Grid atravs do MyGrid Broker. O componente interno do MyGrid Broker que recebe a submisso o escalonador. Por sua vez, o Scheduler requisita aos provedores de GuMs recursos para executar a aplicao submetida pelo usurio. Esses provedores podem responder com recursos locais ou recursos obtidos na rede de favores. Para que o escalonador receba uma resposta dos provedores necessrio que tenha sido encontrada uma GuM que preenche os requisitos determinados na descrio da aplicao. Portanto, aps ter sido descoberto um recurso que possui atributos compatveis com os requisitos da aplicao, o recurso alocado e repassado para o escalonador que o solicitou. Certamente, isso s ir ocorrer caso o recurso esteja disponvel. Porm, caso o recurso tenha sido descoberto atravs da rede de favores, o recurso pode ser tomado de volta (i.e. preemptado) pelo peer que o forneceu, seguindo a dinmica da rede de favores. A preempo um evento natural e previsto pela arquitetura do OurGrid, uma vez que os recursos s so cedidos caso esteja ocioso. Ou seja, uma solicitao local no site, ao qual o recurso pertence, pode ocasionar a preempo. Vale tambm ressaltar que a alocao do recurso feita no nvel do MyGrid Broker, ou seja, isso no significa que o recurso estar dedicado exclusivamente ao MyGrid Broker. Portanto, no h impedimento para que outras aplicaes que no usam a infraestrutura do OurGrid estejam executando concorrentemente com a aplicao submetida pelo usurio.

11.3.4.4. Comunicao Uma vez que o foco da soluo OurGrid est nas aplicaes Bag-of-Tasks, no faz parte do escopo da soluo OurGrid prover mecanismos de comunicao para aplicaes fortemente acopladas. Mesmo assim, possvel usar a infraestrutura OurGrid para executar aplicaes deste tipo, desde que a execuo seja interna a um site. Por exemplo, uma aplicao que usa MPI, quando descrita pelo usurio, pode ter especificado em seus requisitos que necessita de uma GuM (Grid Machine), que na verdade o front end de uma coleo de vrios processadores (i.e. um cluster). Essa demanda ser atendida se existir uma GuM, no alocada, que possua um atributo compatvel com o requisito especificado pela aplicao. Portanto, apesar de no ter uma arquitetura que prov comunicao entre as tarefas que esto sendo executadas nas GuMs, a soluo OurGrid prov meios de agregar ao Grid GuMs que permitem a execuo de aplicaes fortemente acopladas. 11.3.4.5. Transferncia de Dados A soluo OurGrid para transferncia de dados baseada no tratamento de arquivos. Desta forma, o usurio ao descrever sua aplicao tem a sua disposio o uso de trs operaes de transferncia arquivos, put, store e get, que podem ser usadas para preparar o ambiente para execuo da aplicao (colocando os arquivos nos sites onde a aplicao ir executar), como tambm coletar os dados resultantes do processamento. Tanto put quanto store so operaes que permitem a transferir arquivos para a GuM. A diferena entre as duas operaes consiste apenas do fato que store evita a transferncia do arquivo caso o arquivo j se encontre armazenado no lado remoto. Isso til, por exemplo, para executveis da aplicao e dados que so reutilizados entre execues sucessivas da aplicao. A terceira operao, get, fornece um mtodo de coletar arquivos resultantes da execuo das aplicaes. A infraestrutura de comunicao usada para a transferncia a mesma usada para a solicitao de servios de execuo, ou seja, RMI. Uma vez que possvel ter segurana na comunicao com as GuMs de RMI sobre SSL, as operaes de transferncias de dados tambm gozam da segurana fornecida pela camada de comunicao baseada em certificados. 11.3.4.6. Avaliao do OurGrid A caracterstica mais importante do OurGrid conseguir prover uma soluo til e eficiente para uma comunidade de usurios em produo, apesar de se basear em solues simples e de escopo limitado (i.e. apenas aplicaes do tipo Bag-of-Tasks). importante notar que o objetivo do OurGrid contrasta com o objetivo do Globus, que fornece um conjunto de servios para a construo da infraestrutura da grade. Portanto, OurGrid uma soluo que complementa o Globus provendo um broker (i.e. MyGrid) e abstraes que permitem o usurio usar recursos Globus e noGlobus. Por outro lado, Globus complementa o OurGrid ao fornecer a infraestrutura de servios para execuo de aplicaes em larga escala. OurGrid persegue um objetivo diferente do que seria prover uma soluo genrica para computao em Grid. Com o foco em aplicaes BoT foi possvel

produzir uma soluo efetiva para uma comunidade de usurios em produo. No se quer dizer com isso que no se pretende introduzir novas funcionalidades, que aumentem o escopo da soluo. Ao contrrio, a idia gradativamente permitir que mais aplicaes possam utilizar a soluo. Por exemplo, suporte a fluxo de dados, suporte a minerao de dados etc. Atualmente na verso 3.0.2, OurGrid j usado em produo por vrios grupos de pesquisa no Brasil [Cirne 2004]. As prximas verses prometem incorporar melhorias no escalonamento de aplicaes, soluo de sandboxing, bem como maior tolerncia para aplicaes de longa durao (high-throughput computing) atravs do uso de checkpoint. O software OurGrid est disponvel para download em {http://www.ourgrid.org}. 11.3.5. Anthill Como extenso do ambiente DataCutter, a plataforma Anthill foi criada [Meira 2005]. Ela prov um mecanismo chamado fluxo identificado (labeled stream) que permite a seleo de uma cpia particular baseada nos dados relacionados com as mensagens (labels). Essa extenso permite um modelo de programao mais rico, facilitando a partio do estado global de cpias transparentes. Alm disso, o Anthill prov um framework, no qual a execuo da aplicao pode ser decomposta numa seqncia de tarefas intermedirias que precisam ser realizadas e tambm pode criar mltiplos filtros em um ambiente iterativo. Ele explora o paralelismo em vrios nveis: tempo, espao e assincronia.

Figura 14. Modelo de Programao de uma Aplicao Anthill.

Como podemos observar na Figura 14, uma aplicao Anthill explora o paralelismo de tempo como um pipeline, porque ela composta de N filtros (estgios ou fases de processamento) conectados por fluxos de dados (canais de comunicao). Esse modelo de aplicao fora explicitamente o programador a dividir o programa em fases bem definidas (filtros), nos quais o dado transformado, por um filtro, em um dado de outro domnio ou espao de dados, que necessrio para o prximo filtro.

O modelo de programao do Anthill tambm explora o paralelismo de espao, pois cada filtro possui mltiplas cpias ou instncias. Cada canal de comunicao entre filtros pode ser nomeado para direcionar um fluxo de dados para uma cpia especfica de um filtro (ponto a ponto) ou para todas as cpias de um filtro (broadcast). Uma consequncia do paralelismo de espao o paralelismo de dados, porque um banco de dados automaticamente dividido entre as cpias dos filtros. Juntamente com os fluxos, o paralelismo de dados prov um mecanismo eficiente de diviso da demanda de E/S entre os filtros. Alm disso, o Anthill tira vantagem da assincronia e prov iteratividade. Cada aplicao possui um conjunto de pedaos de trabalho (work slices) a serem executados. De acordo com os conjuntos de dados lidos das bases de dados, um pedao de trabalho criado. Eles podem ser executados independentemente, respeitando apenas a dependncia de dados. Depois de processados, eles tambm podem gerar novos pedaos de trabalho, esse fato justifica a necessidade de um processo iterativo.

11.4. Aplicaes de Computao em Grade

Neste tpico apresentamos diversos tipos de aplicaes para a computao em grade: minerao de dados, buscas massivas, simulaes de Monte Carlo, clculo de fractais, biologia computacional e processamento de imagens. Dentre essas aplicaes, destacaremos as que seguem os modelos bag-of-tasks e fluxo de dados. Apresentaremos aplicaes de minerao de dados (fluxo de dados) em bases de dados reais, executando em uma plataforma de computao em grade. 11.4.1. Jacobi Jacobi AppLeS [Berman 1996] um exemplo interessante por ter lanado a idia de escalonamento de aplicaes e tambm por escalonar uma aplicao bem conhecida (Jacobi). Jacobi um mtodo usado para resolver a aproximao por diferenas finitas da equao de Poisson e portanto aplicvel a problemas que envolvem fluxo de calor, eletrosttica e gravitao. Alm de ser interessante por si s, Jacobi pode ser visto como uma instncia de uma importante classe de aplicaes paralelas: aplicaes fortemente acopladas de paralelismo em dados. Jacobi AppLeS um escalonador para Jacobi 2D. Em Jacobi 2D, o domnio do problema discretizado em uma matriz bidimensional. Em cada iterao, cada elemento da matriz atualizado com a mdia dos seus quatro vizinhos. O Jacobi termina por convergncia, isto , quando uma iterao altera muito pouco os elementos da matriz.

Figura 15. Jacobi rodando com 4 processadores em um MPP.

Quando Jacobi executado em um MPP, a matriz bidimensional tipicamente dividida em ambas as dimenses, gerando sub-matrizes de igual tamanho. Cada submatriz ento alocada a um processador. A cada iterao, portanto, necessrio comunicao entre processadores para troca das fronteiras das sub-matrizes. A Figura 15 mostra a distribuio de dados entre 4 processadores de um MPP alocados para executar Jacobi. Como, em um MPP, os processadores so idnticos e dedicados e a comunicao muito boa entre quaisquer dois processadores, esta simples estratgia de alocao de trabalho balanceia a carga entre os processadores, garantindo bom desempenho.

Entretanto em uma grade computacional, processadores e canais de comunicao so heterogneos. Alm disso, outras aplicaes esto concorrendo pelos mesmos recursos (processadores e canais de comunicao) enquanto a aplicao Jacobi executa. Conseqentemente, a estratgia descrita acima provavelmente vai produzir um desbalanceamento de carga, afetando o desempenho. Mais ainda, uma vez que as condies de carga da grade variam dinamicamente, o que uma boa diviso de carga vai variar a cada execuo da aplicao. Finalmente, devido existncia de canais de comunicao mais lentos e compartilhados com outras aplicaes, talvez no valha a pena utilizar todos os processadores disponveis. A soluo oferecida por AppLes Jacobi se baseia em trs elementos principais. Primeiro, o escalonamento em si simplificado pela deciso de utilizar um particionamento unidimensional. Segundo, o escalonador se utiliza do NWS [Wolski 1998] para obter previses de curto prazo da disponibilidade de cada processador e da latncia e banda da comunicao entre quaisquer dois processadores. Terceiro, o escalonador dispe de um modelo de desempenho da aplicao, que usado para avaliar suas decises. Este modelo o seguinte: Ti = Ai Pi + Ci, onde: Ti o tempo para o processador i executar uma iterao Ai a rea da submatriz alocada ao processador i Pi o tempo que o processador i leva para computar um elemento Ci o tempo que o processador i leva para comunicar suas fronteiras Note que Pi e Ci so estimados com base nos dados fornecidos pelo NWS. O escalonamento propriamente dito comea ordenando os processadores por uma distncia especfica da aplicao (que cresce quadraticamente com a diferena de velocidade dos processadores e linearmente com a diferena de suas capacidades de comunicao). Uma vez os processadores ordenados, tenta-se iterativamente uma soluo com os n primeiros processadores, at que a soluo com n - 1 processadores se mostre mais rpida, ou at que no haja mais processadores. Naturalmente, o tempo de uma iterao estimado como o maior Ti de todos os processadores. Fixados n processadores, a soluo de escalonamento obtida dividindo a matriz proporcionalmente a Pi. Por exemplo, suponha que a grade tem quatro processadores: P0, P1, P2 e P3. Assuma ainda que P0 e P1 tem o dobro da velocidade de P2 e P3, que P1 tem uma outra aplicao rodando e s poder dedicar 50% de seu poder computacional a aplicao, que P3 est conectado a uma rede que vivencia intenso trafego e que sua comunicao est ordens de grandeza mais lenta que entre os demais processadores. Uma vez que P3 est se comunicando muito lentamente, o AppLeS no vai utiliz-lo para esta execuo. Note que esta deciso no descarta a possibilidade que P3 venha a ser usado em uma futura execuo da aplicao, quando as condies da rede forem diferentes. Note tambm que, embora P1 seja duas vezes mais rpido que P2, uma vez que s 50% de P1 est disponvel, P1 e P2 so idnticos para a aplicao (pelo menos nesta execuo). A Figura 16 mostra o resultado que o AppLeS Jacobi produziria neste cenrio.

Devemos salientar que um aspecto importante para o bom funcionamento do Jacobi AppLeS o tempo relativamente curto de execuo da aplicao. O tempo de execuo dos experimentos descritos em [Berman 1996] da ordem de segundos, casando perfeitamente com as previses de curto prazo do NWS. Para aplicaes que executam por mais tempo (horas, digamos), seria necessrio prever a disponibilidade de recursos da grade por prazos mais longos. Uma alternativa interessante seria construir um escalonador que, alm do escalonamento inicial, continuasse funcionando para reescalonar a aplicao caso as condies da grade mudassem consideravelmente [Shao 1997]. Neste caso, naturalmente, a aplicao teria que ser escrita para permitir tal reescalonamento, suportando a redistribuio de trabalho durante a execuo.

Figura 16. Escalonado feito pelo AppLeS Jacobi [Berman 1996].

11.5. Concluses e Tendncias

Neste trabalho apresentamos os principais aspectos de computao em grade, desde a apresentao de um conceito do que classifica uma infraestrutura de computao distribuda como uma grade computacional, at o estado atual do desenvolvimento de tecnologia para a construo dessas infraestruturas. Alm disso, apresentamos os principais conceitos, ferramentas e aplicaes em computao em grade. As grades computacionais levantam questes em vrias reas de pesquisa, porm seus benefcios vo alm de uma simples plataforma para execuo de aplicaes em larga escala. A idia facilitar a colaborao de grupos de pesquisa distribudos geograficamente. Mostramos ento que as grades computacionais surgiram da unificao dos esforos realizados pela comunidade de Sistemas Distribudos e Processamento Paralelo. A infra-estrutura anloga a grade de fornecimento de energia eltrica, mas possui vrias diferenas discutidas neste trabalho. Finalmente, a discusso sobre os padres emergentes para o desenvolvimento de infraestruturas de grades computacionais, mostra que os esforos tm amadurecido, fomentado a pesquisa e o desenvolvimento de ferramentas, que contribuem para a concretizao de um ambiente amplamente distribudo onde ser possvel consumir servios computacionais de forma transparente.

Referncias Bibliogrficas
B. Allcock, J. Bester, J. Bresnahan, A. L. Chervenak, I. Foster, C. Kesselman, S. Meder, V. Nefedova, D. Quesnal, S. Tuecke. Data Management and Transfer in High Desempenho Computational Grid Environments . Parallel Computing Journal, Vol. 28 (5), May 2002, pp. 749-771. (http://www.globus.org/research/papers.html) W. Allcock, J. Bester, J. Bresnahan, A. Chervenak, L. Liming, S. Meder, S. Tuecke. GridFTP Protocol Specification . GGF GridFTP Working Group Document, September 2002. (http://www.globus.org/research/papers.html) Jim Basney and Miron Livny. Deploying a High Throughput Computing Cluster . High Desempenho Cluster Computing, Rajkumar Buyya, Editor, Vol. 1, Chapter 5, Prentice Hall PTR, Maio, 1999. (http://www.cs.wisc.edu/condor/publications.html) F. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao. Application-Level Scheduling on Distributed Heterogeneous Networks . Supercomputing96, 1996. (http://apples.ucsd.edu/hetpubs.html) R. Buyya, D. Abramson, J. Giddy. An Economy Driven Resource Management Architecture for Global Computational Power Grids . The 2000 International Conference on Parallel and Distributed Processing Techniques and Applications, Las Vegas, USA, June 26-29, 2000. (http://www.cs.mu.oz.au/~raj/ecoGrid/) H. Casanova, A. Legrand, D. Zagorodnov e F. Berman. Heuristics for Scheduling Parameter Sweep Applications in Grid Environments . 9th Heterogeneous Computing Workshop, pp349-363. (http://apples.ucsd.edu/hetpubs.html) W. Cirne e K. Marzullo. The Computacional Co-op: Gathering Clusters into a Metacomputer . Proceeding of the IPPS/SPDP' 99 Symposium. April 1999. (http://walfredo.dsc.ufcg.edu.br/resume.html#publications) W. Cirne e K. Marzullo. Open Grid: A User-Centric Approach for Grid Computing . 13th Symposium on Computer Architecture and High Desempenho Computing, 2001. (http://walfredo.dsc.ufcg.edu.br/resume.html#publications) W. Cirne, D. Paranhos, E. Santos-Neto, L. Costa, F. Brasileiro, C. Osthoff e F. Silva. Running Bag of Tasks Applications on Computational Grids . Submetido para publicao. (http://walfredo.dsc.ufcg.edu.br/resume.html#publications) A. Chervenak, I. Foster, C. Kesselman, C. Salisbury, S. Tuecke. The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Datasets . Journal of Network and Computer Applications, 23:187-200, 2001. (http://www.globus.org/research/papers.html) K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, S. Tuecke. A Resource Management Architecture for Metacomputing Systems . Proc. IPPS/SPDP ' 98 Workshop on Job Scheduling Strategies for Parallel Processing, po. 62-82, 1998. (http://www.globus.org/research/papers.html) Distributed.net Web Page. (http://www.distributed.net/index.html) Wael Elwasif, James S. Plank and Rich Wolski. Data Staging Effects in Wide Area Task Farming Applications . IEEE International Symposium on Cluster Computing

and the Grid, Brisbane, Australia, May, 2001, (http://www.cs.utk.edu/~plank/plank/papers/CC-GRID-01.html)

pp.

122-129.

D. H. Epema, Miron Livny, R. van Dantzig, X. Evers, and Jim Pruyne. A Worldwide Flock of Condors: Load Sharing among Workstation Clusters . Journal on Future Generations of Computer Systems, Volume 12, 1996. (http://www.cs.wisc.edu/condor/publications.html) Entropia Web Page. (http://www.entropia.com/) I. Foster and C. Kesselman. The Globus Project: A Status Report . Proc. IPPS/SPDP ' 98 Heterogeneous Computing Workshop, pg. 4-18, 1998. (http://www.globus.org/research/papers.html) I. Foster and C. Kesselman (editors). The Grid: Blueprint for a New Computing Infrastructure . Morgan Kaufmann Publishers. 1999. I. Foster, C. Kesselman, and S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations . International Journal of Supercomp. Applications, 15(3), 2001. (http://www.globus.org/research/papers.html) I. Foster, C. Kesselman, J. Nick, S. Tuecke. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration . June 22, 2002. (http://www.globus.org/research/papers.html) I. Foster. What is the Grid? A Three Point Checklist . GRID today, vol. 1, no. 6, 22 de julho de 2002. (http://www.Gridtoday.com/02/0722/100136.html) Paul Francis, Sugih Jamin, Vern Paxson, Lixia Zhang, Daniel Gryniewicz, and Yixin Jim. An Architecture for a Global Internet Host Distance Estimation Service . Proceedings of IEEE INFOCOM, 1999. James Frey, Todd Tannenbaum, Ian Foster, Miron Livny, and Steven Tuecke. CondorG: A Computation Management Agent for Multi-Institutional Grids . Proceedings of the Tenth IEEE Symposium on High Desempenho Distributed Computing (HPDC10), San Francisco, California, August 7-9, 2001. (http://www.cs.wisc.edu/condor/publications.html) Globus Web Page. (http://www.globus.org/) Grid Forum Web Page. (http://www.Gridforum.org/) A. Grimshaw and W. Wulf. Legion: The Next Logical Step Toward the World-Wide Virtual Computer . Communications of the ACM, 40(1):39-45, January 1997. (http://citeseer.nj.nec.com/article/grimshaw96legion.html) T. Hogg and B. Huberman. Controlling Chaos in Distributed Systems . IEEE Transactions on Systems, Man, and Cybernetics, vol. 21, no. 6, Nov/Dec 1991. J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels, R. Gummadi, S. Rhea, H. Weatherspoon, W. Weimer, C. Wells, and B. Zhao. OceanStore: An Architecture for Global-Scale Persistent Storage . Proceedings of ACM ASPLOS, Boston, MA, November 2000. (http://oceanstore.cs.berkeley.edu/publications/papers/pdf/asplos00.pdf)

M. Litzkow, M. Livny, and M. Mutka. Condor A Hunter of Idle Workstations . In Proceedings of the 8th International Conference of Distributed Computing Systems, pages 104-111, June 1988. B. Lowekamp, N. Miller, D. Sutherland, T. Gross, P. Steenkiste, and J. Subhlok. A Resource Query Interface for Network-Aware Applications . Seventh IEEE Symposium on High-Desempenho Distributed Computing, July 1998. (http://www.cs.cmu.edu/~cmcl/remulac/papers.html) M. Mitzenmacher. How Useful is Old Information? . Proc. of the 16th Annual ACM Symposium on Principles of Distributed Computing (PODC 97), 1997. Also in IEEE Transaction in Parallel and Distributed Systems, 11(1), pg. 6-20, Jan. 2000. MyGrid Web Page. (http://www.dsc.ufcg.edu.br/MyGrid) D. Paranhos, W. Cirne e F. Brasileiro. Trading Information for Cycles: Using Replication to Sched-ule Bag of Tasks Applications on Computational Grids . (http://walfredo.dsc.ufcg.edu.br/resume.html#publications) C. De Rose e P. Navaux. Fundamentos de Processamento de Alto Desempenho . ERAD 2002 2a Escola Regional de Alto Desempenho, So Leopoldo, RS, Brasil, 15 a 19 de janeiro de 2002. SETI@home Web Page. (http://www.seti.org/science/setiathome.html) Gary Shao, Rich Wolski, and Fran Berman. Predicting the Cost of Redistribution in Scheduling . 8th SIAM Conference on Parallel Processing for Scientific Computing, 1997. (http://www.cs.ucsd.edu/groups/hpcl/apples/hetpubs.html) W. Smith, I. Foster, V. Taylor. Scheduling with Advanced Reservations . Proceedings of the IPDPS Conference, May 2000. (http://www.globus.org/research/papers.html) TeraGrid Web Page. (http://www.teraGrid.org/) A. Vahdat, P. Eastham, C. Yoshikawa, E. Belani, T. Anderson, D. Culler, and M. Dahlin. WebOS: Operating System Services for Wide Area Applications . Proceedings of the Seventh Symposium on High Desempenho Distributed Computing, 1998. (http://citeseer.nj.nec.com/vahdat97webos.html) C. Waldspurger e William Weihl. Stride Scheduling: Deterministic Proportional-Share Resource Mangement . Technical Memorandum MIT/LCS/TM-528, MIT Laboratory for Computer Science, June 1995. (http://www.research.digital.com/SRC/personal/caw/papers.html) Jon Weissman and Andrew Grimshaw. A Framework for Partitioning Parallel Computations in Heterogeneous Environments . Concurrency: Practice and Experience, Vol. 7, No. 5, August 1995. (http://ringer.cs.utsa.edu/faculty/weissman.html/pub.html) Jon Weissman. Gallop: The Benefits of Wide-Area Computing for Parallel Processing . Journal of Parallel and Distributed Computing, Vol. 54(2), November 1998. (http://ringer.cs.utsa.edu/faculty/weissman.html/pub.html) R. Wolski, N. Spring, and J. Hayes. The Network Weather Service: A Distributed Resource Desempenho Forecasting Service for Metacomputing . Journal of Future

Generation Computing Systems, (http://www.cs.utk.edu/~rich/publications/index.html)

1998.

Huican Zhu et al. Adaptive Load Sharing for Clustered Digital Library Servers . 7th IEEE International Symposium on High Desempenho Distributed Computing, Illinois, 1998. (http://www.alexandria.ucsb.edu/~zheng/publications.html)

R. Buyya. Economic-based Distributed Resource Management and Scheduling for Grid Computing . Ph.D. Thesis, Monash University, Melbourne, Australia, April 12, 2002. (http://www.buyya.com/thesis/)
Parvin Asadzadeh, Rajkumar Buyya, Chun Ling Kei, Deepa Nayar, and Srikumar Venugopal. Global Grids and Software Toolkits: A Study of Four Grid Middleware Technologies . High Desempenho Computing: Paradigm and Infrastructure, Laurence Yang and Minyi Guo (editors), ISBN: 0-471-65471-X, Wiley Press, New Jersey, USA, June 2005. (http://www.buyya.com/papers/gmchapter.pdf) Klaus Krauter, Rajkumar Buyya, and Muthucumaru Maheswaran. A Taxonomy and Survey of Grid Resource Management Systems for Distributed Computing . International Journal of Software: Practice and Experience (SPE), ISSN: 0038-0644, Volume 32, Issue 2, Pages: 135-164, Wiley Press, USA, February 2002. (http://www.buyya.com/papers/Gridtaxonomy.pdf) Madhu Chetty and Rajkumar Buyya. Weaving Computational Grids: How Analogous Are They with Electrical Grids? . Computing in Science and Engineering (CiSE), ISSN 1521-9615, Volume 4, Issue 4, Pages: 61-71, IEEE Computer Society Press and American Institute of Physics, USA, July-August 2002. (http://www.buyya.com/papers/WeavingGrid.pdf) Rajkumar Buyya and Srikumar Venugopal. A Gentle Introduction to Grid Computing and Technologies . CSI Communications, pp. 9-19, Vol.29, No.1, July 2005. (http://www.buyya.com/papers/CSICommunicationsJuly2005.pdf) Ferreira, R. A., W. Meira Jr., Guedes, D., Drumond, D. Anthill: A Scalable Run-Time Environment for Data Mining Applications . SBAC-PAD, 2005. Ges, L. F. W. et al, AnthillSched: A Scheduling Strategy for Irregular and Iterative I/O-Intensive Parallel Jobs , Job Scheduling Strategies for Parallel Processing, 2005. Hwang, K., Xu, Z. Scalable Parallel Computing: Technology, Architecture, Programming , Mcgraw-Hill, 1998. K. E. Hoffman, Ending the Grid Lock. , 2005. (http://www.technologyreview.com/articles/05/03/wo/wo hoffman030205) E. Santos-Neto, W. Cirne, F. Brasileiro, and A. Lima, Exploiting replication and data reuse to efficiently schedule data-intensive applications on grids, Lecture Notes in Compute Science, vol. 3277, pp. 210232, 2005. D. Paranhos, W. Cirne, and F. Brasileiro, Trading cycles for information: Using replication to schedule bag-of-tasks applications on computational grids, in Proceedings of the Euro-Par 2003: International Conference on Parallel and Distributed Computing, Klagenfurt, Austria, 2003.

R. Buyya, D. Abramson, and J. Giddy, Nimrod/g: An architecture of a resource management and scheduling system in a global computational grid, in The 4th International Conference on High Performance Computing in Asia-Pacific Region (HPC Asia 2000), Beijing, China, 2000. P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebar, I. Pratt, and A. Warfield, Xen and the art of virtualization, in Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), 2003. W. Cirne, F. Brasileiro, L. Costa, D. Paranhos, E. Santos-Neto, N. Andrade, C. D. Rose, T. Ferreto, M.Mowbray, R. Scheer, and J. Jornada, Scheduling in bag-of-task grids: The pau case in Proceedings of the 16th Symposium on Computer Architecture and High Performance Computing (SBAC-PAD2004), October 2004. S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, P. Vanderbilt, and D. Snelling, Open grid services infrastructure (ogsi) version 1.0. Global Grid Forum Draft Recommendation, June 2003. H. Kreger, Web services conceptual architrecture. , 2003. (www-3.ibm.com/software/solutions/ webservices/pdf/WSCA.pdf) G. Alliance, Ogsa site , 2003. (http://www.globus.org/ogsa)