Capítulo

11
Computação em Grade: Conceitos, Tecnologias,
Aplicações e Tendências

Luís Fabrício Wanderley Góes, 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 evolução dos processadores, redes de interconexão, memórias, sistemas

operacionais, linguagens e outros componentes de computador, surgiram novas
arquiteturas paralelas e distribuídas, dentre as quais destacamos as grades
computacionais. Em decorrência disso, criou-se a possibilidade de resolver problemas
mais complexos como tratamento de conjuntos de imagens, biologia computacional,
mineração de dados e simulação de modelos científicos e de engenharia. Atualmente,
existem diversas tecnologias para o suportar a computação em grade, dentre os quais
destacamos o Globus, Gradebus, Condor, OurGrade e Anthill. Neste trabalho,
detalharemos os conceitos (características, arquiteturas etc.), tecnologias, aplicações
(mineração de dados etc.) e tendências atuais e futuras da computação em grade.
11.1. Introdução
Inspirados pelo sistema de energia elétrica, no meio da década de 90, os cientistas da
computação começaram a explorar o projeto e o desenvolvimento de uma nova infra-
estrutura computacional pelo acoplamento de recursos distribuídos 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 computação em grade [Buyya 2002] [Buyya
2005] [Foster 1999] [Foster 2002]. Esta infra-estrutura é análoga à grade de energia
elétrica que provê acesso consistente, pervasivo e transparente a energia elétrica
independente da origem. A grde de energia elétrica disponibiliza energia elétrica sob
demanda e esconde do usuário detalhes como a origem da energia e a complexidade da
malha de transmissão e distribuição. Ou seja, se temos um equipamento elétrico,
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, periféricos, etc). A Figura 1 ilustra
esta idéia.

Figura 1. Uma Grade Computacional como fonte transparente de poder

computacional sob demanda.

Tanto a origem dos ciclos de processamento quanto da energia é bastante

heterogênea. No caso da energia, ela pode ser gerada por usinas termoelétricas,
hidrelétricas, nucleares e eólicas, enquanto os ciclos de processamento podem surgir de
aglomerados de computadores, PCs, SMPs, etc. com diferentes sistemas operacionais,
arquiteturas e processadores. Além disso, as cargas de trabalho das infra-estruturas são
bastante heterogêneas, começando de eletrodomésticos, televisores até máquina
industriais no caso da grade de energia elétrica, enquanto na grade computacional
existem aplicações científicas, de entretenimento, de engenharia etc [Buyya 2002].
 Mas apesar destas semelhanças, diferentemente da grade de energia elétrica que
fornece energia de imediato, pois ele não 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, além da transmissão dos resultados. Uma outra
diferença interessante é a questão do armazenamento, pois a energia elétrica pode ser
armazenada, enquanto os ciclos de processamento não utilizados são perdidos [Buyya
2002].
Existe um grande número de projetos ao redor do mundo empenhados no
desenvolvimento de grades computacionais e com isso surgiram diversas definições. O
projeto Gridbus define uma grade computacional como um tipo de sistema distribuído e
paralelo que permite o compartilhamento, seleção e agregação de recursos autônomos
distribuídos geograficamente, em tempo de execução, dependendo da disponibilidade,
capacidade, desempenho, custo e requisitos de QoS dos usuários [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
interconexão, bases de dados e instrumentos científicos pertencidos e gerenciados por
múltiplas organizações [Foster 2002].

11.1.1. Histórico
A computação em grade é o resultado de décadas de pesquisa nas áreas de
processamento paralelo e sistemas distribuídos. A pesquisa em processamento paralelo
sempre procurou extrair o máximo de desempenho computacional por meio da criação
de máquinas dedicadas com múltiplos processadores, redes especiais de alta velocidade,
memórias compartilhadas e processamento vetorial. Todo este esforço levou a
construção de supercomputadores como o NEC Earth Simulator e o IBM Blue Gene
(MPPs), máquinas extremamente caras e de propósito específico, além de aglomerados
de computadores (NOWs) de baixo custo financeiro compostos de software e hardware
de prateleira.

Figura 2. Evolução das arquieturas até as Grades Computacionais.

Por outro lado, a área de sistemas distribuídos preocupou-se mais com aspectos
ligados à comunicação, heterogeneidade e compartilhamento de recursos
computacionais, principalmente informações 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 distribuídos atingiram uma escalabilidade global propiciando a criação do
comércio eletrônico, redes de troca de arquivos, teleconferências etc. Esta evolução
resultou nas redes P2P (peer-to-peer) como Kazaa, Gnutella e Emule, que permitem o
compartilhamento de qualquer tipo de arquivo em nível global [Chetty 2002] [Krauter
2001].
Como resultado da união destas duas importantes áreas da computação, surgiu o
conceito de grade computacional (Figura 2). Portanto, as grades computacionais estão
preocupadas em agregar supercomputadores distribuídos geograficamente para o
processamento de grandes massas de dados, enquanto redes P2P procuram compartilhar
arquivos distribuídos geograficamente e realizar processamento com computadores de
pequeno porte, no caso do projeto SETI@home, e os supercomputadores (MPPs,
aglomerados etc.) são computadores de grande porte dedicados para solução 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 (teóricos e práticos) relacionados com a
computação em grade considerando os principais tópicos relacionados com:
conceitos; tecnologias, aplicações e tendências.
• Apresentar de modo prático e exemplificado, a programação de aplicações para
arquiteturas de computação em grade existentes (OurGrid, Anthill etc.). Neste
minicurso, apresentamos aplicações de mineração de dados em bases de dados reais.
• Incentivar os alunos a programar e utilizar computação 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 português sobre computação em grade unindo
tópicos teóricos e práticos, já que a quantidade de material - com este enfoque -
disponível em português é muito pequena.

O texto está organizado da seguinte forma: a seção 2 apresenta os principais

conceitos de computação em grade. A seção 3 apresenta as tecnologias atuais de
computação em grade. A seção 4 apresenta as principais aplicações para computação
em grade, com ênfase em aplicações de mineração de dados e finalmente a seção 5
apresenta algumas conclusões, tendências atuais e futuras, terminando com uma
discussão sobre possíveis trabalhos futuros na área de computação em grade.
11.2. Conceitos de Computação em Grade
Muitos domínios de aplicações, nos quais problemas com alta demanda de
processamento e armazenamento de dados podem ser divididos em sub-problemas e
resolvidos individualmente, são os mais indicados para a execução em grades
computacionais. Entre essas aplicações, podemos destacar simulações de Monte Carlo,
projeto de remédios, operações de pesquisa e mineração de dados. Algumas destas
aplicações estão relacionadas ao termo eScience, que denota a pesquisa realizada de
forma colaborativa em escala global. Este ambiente de eScience envolve o
compartilhamento de instrumentos científicos, dados distribuídos, visualização remota e
interpretação colaborativa de dados e resultados, se adequando perfeitamente às
características de uma infra-estrutura de computação em grade [Buyya 2005].
Portanto, em uma grade computacional devemos lidar com seis aspectos
principais para suportar esses tipos de aplicações [Buyya 2002]:
• Heterogeneidade: uma grade envolve uma multiplicidade de recursos que são
heterogêneos e envolvem uma grande variedade de tecnologias.
• Escalabilidade: uma grade deve crescer de algumas dezenas de recursos para
milhões de recursos sem perda de desempenho. Mas devido a alta dispersão
geográfica, as aplicações de uma grade devem ser projetadas levando-se em
consideração problemas com a latência e a largura de banda para a transmissão de
dados.
• Compartilhamento de Recursos: os recursos de uma grade computacional não
podem ser dedicados para nenhuma aplicação específica.
• Múltiplos Domínios Administrativos: os recursos de uma grade estão distribuídos
geograficamente em múltiplos domínios administrativos, onde cada organização
possui suas próprias restrições e regras de uso dos recursos, que devem ser
respeitadas.
• Controle Distribuído: em uma grade não existe um gerenciador centralizado que
possui uma visão global do sistema. Então cada componente da grade deve ser
autônomo.
• Dinamicidade e Adaptabilidade: em uma grade, a falha de um recurso é uma regra.
Portanto, as aplicações e gerenciadores de recursos devem mudar seu comportamento
de acordo com a disponibilidade dos recursos.

11.2.1. Classes de Arquiteturas Existentes

Uma aplicação paralela é composta por várias tarefas. As tarefas que compõem uma
aplicação paralela executam em vários processadores, caracterizando desta forma o
paralelismo da execução da aplicação e conseqüente redução no seu tempo de execução.
Os processadores usados por uma determinada aplicação e o meio de comunicação entre
eles caracterizam a classe de arquitetura de execução da aplicação.
As arquiteturas de aplicações paralelas variam em diversos aspectos, dos quais
destacamos conectividade, heterogeneidade, compartilhamento, imagem de sistema
único e escalabilidade. A conectividade diz respeito aos canais de comunicação que
interligam os processadores que compõem a arquitetura. Atributos que definem a
conectividade de uma arquitetura são: topologia, largura de banda, latência e
compartilhamento. A heterogeneidade trata das diferenças entre os processadores, que
podem ser de velocidade e/ou arquitetura. O compartilhamento está relacionado à
possibilidade dos recursos usados por uma aplicação serem compartilhados por outras
aplicações.
Já a imagem de sistema único é o conjunto de computadores (multiprocessadores
e/ou estações de trabalho) que se comporta como um grande computador, ou seja,
através de software ou hardware é possível criar-se a ilusão de que todos os recursos
físicos (processadores, memórias, discos, etc.) e lógicos (processos, tarefas, memórias
virtuais, sistemas de arquivos) pertencentes as máquinas que compõem o arquitetura
sejam um só grande recurso, tornando possível o acesso à qualquer recurso disponível
no ambiente da arquitetura, independente de sua localização. A escalabilidade preocupa-
se o ganho de desempenho a medida que aumenta-se o número de elementos de
processamento e recursos em geral consumidos por uma aplicação.
Entender as diferenças entre as arquiteturas é fundamental, pois cada aplicação
paralela e distribuída tem uma série de requisitos, que podem ser melhores ou piores
atendidos por uma dada arquitetura. Em princípio, procuramos executar uma aplicação
paralela em uma arquitetura adequada às características da aplicação. Por exemplo,
considere conectividade, um aspecto em que arquiteturas diferem consideravelmente.
Obviamente, para obter bom desempenho de uma aplicação paralela cujas tarefas se
comunicam e sincronizam freqüentemente, necessitamos utilizar uma arquitetura de
execução com boa conectividade.
Podemos agrupar as arquiteturas hoje existentes em quatro grandes grupos:
SMPs, MPPs, NOWs e Grades. SMPs (ou multiprocessadores simétricos) são máquinas
em que vários processadores compartilham a mesma memória [Hwang 1998]. Os
multiprocessadores possibilitam um forte acoplamento entre os processadores e
executam uma única cópia do sistema operacional para todos os processadores.
Portanto, eles apresentam uma imagem única de sistema e alta conectividade. Todavia,
multiprocessadores apresentam limitações de escalabilidade, raramente ultrapassando 32
processadores. Os multiprocessadores são relativamente comuns no mercado e vão
desde máquinas duais Intel até grandes servidores como os IBM pSeries. A Figura 3
ilustra a arquitetura de um multiprocessador.

Figura 3. Arquitetura de um Multiprocessador Simétrico (SMP).

 Os MPPs (processadores maciçamente paralelos) são compostos por vários nós
(processador e memória) independentes, interconectados por redes dedicadas e de alta
velocidade. Os MPPs incluem supercomputadores paralelos como o IBM SP2 e Cray
T3E, como também aglomerados de menor porte montados pelo próprio usuário.
Tipicamente cada nó roda sua própria cópia do sistema operacional, mas uma imagem
comum do sistema é implementada através da visibilidade dos mesmos sistemas de
arquivo por todos os nós. Um MPP é controlado por um escalonador que determina
quais aplicações executarão em quais nós. Ou seja, não se pode utilizar um nó que não
tenha sido alocado à aplicação pelo escalonador. Isto possibilita dedicar partições (um
conjunto de nós) às aplicações, permitindo que estas não precisem considerar
compartilhamento. Mas, uma vez que aplicações executam em partições dedicadas,
existe a possibilidade de não haver nós suficientes para executar uma aplicação assim
que ela é submetida. Neste caso, a aplicação espera em uma fila até que os recursos que
solicitou estejam disponíveis. A Figura 4 exemplifica a arquitetura de um MPP.

Figura 4. Arquitetura de um MPP.

As NOWs (redes de estações de trabalho) ou aglomerados de computadores são

um conjunto de estações de trabalho ou PCs, ligados por uma rede local. As NOWs são
arquiteturalmente semelhantes aos MPPs. Ambas arquiteturas são formadas por nós que
agregam processador e memória. Uma diferença entre NOWs e MPPs é que os nós que
compõem uma MPP tipicamente são 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
diferença entre as arquiteturas é a forma de escalonamento distribuído de uma NOW.
Cada nó tem seu próprio escalonador local. Como resultado, não há como dedicar uma
partição da NOW a uma só aplicação paralela. Portanto, uma aplicação que executa
sobre uma NOW deve considerar o impacto sobre seu desempenho da concorrência por
recursos por parte de outras aplicações. A Figura 5 mostra esquematicamente uma
NOW.
As grades computacionais são o passo natural depois das NOWs, considerando
aspectos de heterogeneidade e dispersão geográfica. Os componentes de um grades não
se restringem a processadores, podendo ser SMPs, MPPs e PCs conectados como redes
P2P, como também instrumentos digitais. As grades tipicamente não fornecem uma
imagem comum do sistema para seus usuários. Os componentes da grade podem variar
drasticamente em capacidade, software instalado, sistemas de arquivo montados e
periféricos instalados. Além disso, os componentes de uma grade podem estar sobre
controle de diferentes entidades e, portanto, em domínios administrativos diversos.

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

Conseqüentemente, um dado usuário pode ter acesso e permissões bastante

diversas nos diferentes componentes de uma grade. Obviamente, uma grade não pode
ser dedicada a um usuário, embora seja possível que algum componente possa ser
dedicado (um MPP, por exemplo). É importante salientar que uma aplicação em grade
deve estar preparada para lidar com todo um ambiente dinâmico, adaptando-se ao
cenário que se apresenta com o intuito de obter o melhor desempenho possível no
momento. A Figura 6 exemplifica uma possível grade computacional, composta por um
MPP e computadores de vários tipos conectados via Internet. Note que um destes
computadores realiza instrumentação (no exemplo, através de um microscópio),
enquanto outro computador dispõe de grande capacidade para armazenamento de dados.

Figura 6. Arquitetura de uma grade computacional.

 A Tabela 1 sumariza o comportamento médio em relação às características das
arquiteturas para execução de aplicações paralelas e distribuídas. Certas arquiteturas
podem apresentar características arquiteturais adicionais que influenciam no
desempenho das aplicações paralelas. Por exemplo, alguns MPPs oferecem suporte de
hardware a memória compartilhada, através de um modelo denominado DSM
(Distributed Shared Memory), que melhora o desempenho de aplicações baseadas em
memória compartilhada. Uma vez que as grades computacionais são o nosso foco neste
texto, referimos [De Rose 2002] caso o leitor queira mais detalhes sobre arquiteturas de
execução de aplicações paralelas tradicionais (SMPs, MPPs e NOWs).

Tabela 1 – Resumo das características típicas de diferentes arquiteturas.

SMPs MPPs NOWs Grades

Conectividade excelente muito boa boa média/ruim
Heterogeneidade Nula baixa média alta
Compartilhado Não não sim sim
Imagem única comum comum múltipla
Escalabilidade 10 1.000 1.000 100.000

Mesmo quando não há distinções 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
supercomputação norte-americanos através de canais de altíssima 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 através da instalação do software cliente do projeto. Em
fevereiro de 2000, SETI@home contava com 1.6 milhões de processadores espalhados
em 224 países, e computava em média a uma velocidade de 10 Teraflops. Embora o
SETI@home tenha reportado uma desempenho compatível com o TeraGrid, é patente a
diferença entre as duas grades. O TeraGrid é mais acoplado que o SETI@home.
O conceito de acoplamento da grade (i.e. quão próximos estão seus
componentes) é fundamental para compreendermos quais aplicações podem executar
eficientemente em uma grade. Voltando ao exemplo acima, o SETI@home se presta
somente para execução de aplicações leves (i.e. levemente acopladas), enquanto o
TeraGrade pode propiciar condições para execução eficiente de aplicações pesadas (i.e.
fortemente acopladas).

11.2.2. Arquitetura de uma Grade Computacional

Em uma grade computacional, as funcionalidades necessárias na infra-estrutura são:
armazenamento remoto; publicação de bases de dados usando nomeação lógica global;
autenticação e autorização de acesso; acesso transparente a recursos remotos; publicação
de serviços e acesso de custo; composição de aplicações distribuídas usando diversos
componentes de software; descoberta de bases de dados e recursos computacionais;
mapeamento e escalonamento de tarefas; submissão e monitoração da execução de
tarefas etc [Buyya 2005].
Os vários componentes de uma grade necessários para prover essas
funcionalidades são divididos em camadas mostradas na Figura 7: Grid Fabric, Core
Grid, User-Level Grid e Grid Applications [Buyya 2002] [Buyya 2005].
• Gride Applications: as aplicações em grade são tipicamente desenvolvidas usando
ambientes de programação de grade, serviços de descoberta, interfaces e
escalonamento de serviços providos por um middleware de nível de usuário. Um
exemplo de aplicação, tal como simulação de parâmetros ou um problema de grande
desafio, poderia requerer poder computacional, acesso a bases de dados remotas e
pode interagir com instrumentos científicos.
• User-Level Grid: esta camada é composta de middlewares que utilizam interfaces
que fornecem abstrações e serviços de alto nível. Isto inclui ambientes de
desenvolvimento de aplicações, ferramentas de programação e resource brokers para
gerenciamento de recursos e escalonamento de aplicações.

Figura 7. Arquitetura em Camadas de uma Grade Computacional

• Core Grid: esta camada é composta de middlewares que oferecem serviços tal
como gerenciamento remoto de processos, co-alocação de recursos, acesso de
armazenamento, registro e descoberta de informações, segurança e aspectos de QoS.
Estes serviços abstraem a complexidade e heterogeneidade da Grid Fabric, provendo
um método consistente para acessar recursos distribuídos.
• Grid Fabric: esta camada consiste de recursos distribuídos tal como computadores,
redes de interconexão, dispositivos de armazenamento e instrumentos científicos. Os
 recursos computacionais representam múltiplas arquiteturas tal como aglomerados,
supercomputadores, servidores e PCs que executam diferentes sistemas
operacionais. Os instrumentos científicos, tal como telescópios e redes de sensores,
provém dados em tempo real que podem ser transmitidos diretamente a sites de
computação ou armazenadas em uma base de dados.

Com relação ao projeto de grades, elas podem ser divididas em três categorias:
grades computacionais, grades de dados (data grid) e grades de serviços [Krauter 2001].
A categoria de grade computacional está relacionada com infraestruturas que possuem
maior capacidade de processamento para execução de aplicações paralelas e
distribuídas. Geralmente, grades computacionais procuram diminuir o tempo de resposta
de aplicações ou aumentar a vazão do sistema.
As grades de dados são infraestruturas para sintetização de informações novas de
repositórios de dados como bibliotecas digitais e data warehouses que estão distribuídos
em uma rede de alta escala. Elas possuem serviços de gerência de armazenamento e
acesso de dados para as aplicações.
Por último, uma grade de serviços é uma infraestutura que fornece serviços que
não podem serem providos por apenas uma máquina, como interligação de grupos
colaborativos, agregação de recursos para visualização de dados que permita um
cientista aumentar a confiabilidade de suas simulações e aplicações multimídia de
tempo real.

11.2.3. Modelo Operacional de uma Grade Computacional

Em um ambiente de computação em grade, na visão do usuário da grade computacional,
existe uma modelo operacional com etapas comuns para a execução de uma aplicação.
Esstas estapas estão descritas abaixo e ilustradas pela Figura 8 [Buyya 2005]:
1) O usuário programa a sua aplicação distribuída utilizando ferramentas de
desenvolvimento de aplicações. Esta aplicação pode seguir diversos modelos de
programação: passagem de mensagens, bag-of-tasks (BoT), fluxo de dados com
filtros etc.
2) O usuário especifica os seus requisitos de QoS e submete sua aplicação ao
escalonador de aplicação da grade. Por exemplo, no ambiente Ourgrid, o usuário
especifica os recursos necessários para a sua aplicação como tamanho da
memória e sistema operacional. Então ele submete a sua aplicação ao
escalonador de aplicação MyGrid.
3) O escalonador de aplicação de recursos da grade realiza uma descoberta de
recursos e suas características usando o serviço de infromação da grade.
4) O escalonador de aplicação de recursos identifica os preços e/ou a
disponibilidade dos recursos por meio de uma busca em um diretório de
mercado da grade.
5) O escalonador de aplicação de recursos identifica uma lista de fornecedores de
dados ou réplicas e recurso computacionais que fornecem os serviços ou
 características necessários pela aplicação, por meio dos escalonadores de
recursos. Então ele seleciona os melhores fornecedores.
6) O escalonador de aplicação escalona e envia as tarefas para os escalonadores de
recursos que são responsáveis pelos recursos escolhidos para a execução das
aplicações.
7) O agente local do usuário no recurso executa e monitora a tarefa e retorna os
resultados para o escalonador. Enquanto o escalonador de aplicação monitora a
grade pra lidar com eventuais falhas nos recursos e mudanças de configurações
da grade.
8) O escalonador de aplicação coleta os resultados e repassa para o usuário.

Figura 8. Modelo Operacional de uma Grade Computacional

11.3. Tecnologias de Computação em Grade
Vários sistemas para suporte à computação em garde surgiram nos últimos anos, tanto
através de esforços acadêmicos (e.g. Globus, Gridbus, Legion, Condor, MyGrid,
Anthill), quando decorrentes de empreendimento comerciais (e.g. Entropia,
distributed.net). Dentre os esforços acadêmicos, Globus foi de longe o projeto que teve
maior impacto. Todavia, Globus não soluciona todos os problemas existentes na
computação em grade. É importante também conhecer alternativas e, principalmente,
soluções complementares a Globus.
Quanto aos esforços comerciais, ainda é muito cedo para determinar seu
impacto. Além disso, pela própria natureza comercial destes esforços, muito menos
detalhes técnicos estão disponíveis sobre o funcionamento de tais sistemas. Em
particular, um aspecto que necessita melhor definição 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 computação em grade.

11.3.1. Globus
Globus consiste de um conjunto de serviços que facilitam computação em grade [Foster
1998]. Os serviços Globus podem ser usados para submissão e controle de aplicações,
descoberta de recursos, movimentação de dados e segurança na grade. Os principais
serviços Globus disponíveis atualmente (na versão 2.0) são apresentados na Tabela 2.

Tabela 2. Principais Serviços do Globus.

Serviço Funcionalidade
GSI Segurança, autenticação única na grade
GRAM Submissão e controle de tarefas
Nexus Comunicação entre tarefas
MPI-G MPI sobre Nexus
MDS Informações e diretórios
GASS Transferência de arquivos
GridFTP Transferência de arquivos

11.3.1.1. Segurança e Autenticação

Um aspecto que complica o uso de grades na prática é a autenticação de usuários em
diferentes domínios administrativos. Em princípio, o usuário tem que se autenticar para
cada domínio administrativo de uma forma determinada pelo administrador do domínio
(que tipicamente envolve fornecer uma identificação de usuário e uma senha). Este
esquema coloca uma grande carga no usuário (quem usa vários sites Web que exigem
login, tem uma idéia bem concreta destes problemas). No contexto de computação em
grade, os problemas de múltipla autenticação são agravados pois queremos ter
programas que possam efetuar ações que exigem autenticação (e.g. submeter uma tarefa
a um site remoto).
 GSI (Globus Security Infrastructure) é o serviço Globus que ataca este problema.
GSI viabiliza o login único na grade. GSI utiliza criptografia de chave pública,
certificados X.509 e comunicação SSL (Secure Sockets Layer) para estabelecer a
identidade Globus do usuário. 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 usuário ter se identificado junto ao
GSI, todos os demais serviços Globus saberão, de forma segura, que o usuário é de fato
quem diz ser.
Uma vez que um serviço sabe a identidade Globus do usuário, resta estabelecer
quais operações tal usuário pode realizar. Isto é feito mapeando a identidade Globus
para um usuário local. Por exemplo, o serviço GRAM (submissão 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. Alocação e Descoberta de Recursos

As grades não têm um escalonador que controla todo o sistema. Assim sendo, quando
um usuário que submeter uma aplicação para execução na grade, o usuário utiliza um
escalonador de aplicação 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 são acessados através do serviço
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 aplicação não precisam entender dos detalhes particulares de cada
escalonador de recurso. Para facilitar ainda mais a tarefa dos escalonadores de aplicação,
o Globus também disponibiliza MDS (Metacomputing Directory Service), um serviço
de informação sobre o Grade. O MDS contém informações sobre os recursos que
formam a grade e também sobre seu estado (carga, disponibilidade, etc).
Uma idéia bastante interessante em Globus é que escalonadores de aplicação
podem usar os serviços de outros escalonadores de aplicação. O escalonador que recebe
a solicitação do cliente lida com a especificação em mais alto nível. Ele refina tal
especificação e, para implementá-la, submete novas solicitações a escalonadores de
recurso (que de fato executam solicitações) e/ou escalonadores de aplicação (que
utilizam outros escalonadores para executar solicitações).
O Globus suporta bem esta hierarquia de escalonadores através da linguagem
RSL (Resource Specification Language). O RSL é capaz de expressar tanto solicitação
de alto nível (como a que o usuário envia a seu escalonador de aplicações), como
também solicitações concretas (que são enviadas para GRAMs, que as traduzem para
escalonadores de recurso locais). Portanto, o trabalho de um escalonador de aplicação
em Globus pode ser descrito como sendo o de refinar solicitações RSL. A Figura 9
ilustra este processo. Note que o Globus usa o broker para o que chamamos de
escalonador de aplicação. Já o co-alocador (co-allocator) é um escalonador de aplicação
especializado em garantir que tarefas localizadas em máquinas distintas executem
simultaneamente. O co-alocador é fundamental para execução em grades de aplicações
fortemente acopladas. Em aplicações fortemente acopladas, as tarefas precisam se
comunicar para que a aplicação faça progresso. Portanto, todas as tarefas da aplicação
têm que ser executadas simultaneamente. É importante ressaltar que uma boa
implementação de co-alocação depende da implementação, por parte dos escalonadores
de recurso, do serviço de reserva adiantadas (advance reservation). As reservas
adiantadas permitem a escalonadores de aplicação obter garantias de escalonadores de
recurso que determinados recursos (e.g. processadores) estarão disponíveis para
aplicação em um intervalo de tempo preestabelecido [Smith 2000].

Figura 9 – Processo de especialização de requisição [Foster 1998].

A Figura 10 apresenta um exemplo da submissão de uma aplicação em uma

grade Globus. Veja que um usuário envia uma solicitação de executar “ uma simulação
interativa envolvendo 100.000 entidades” para um escalonador de aplicação
especializado em simulação interativa distribuída. Tal escalonador converte a solicitação
original em outra mais especifica, que descreve a necessidade do usuário em termos de
ciclos, memória e latência de comunicação. Esta nova solicitação é então enviada a um
escalonador de aplicação especializado em MPPs. Este escalonador consulta o MDS
para descobrir quais MPPs (dentro aqueles aos quais o usuário tem acesso) são os
melhores para utilizar no momento. Além disso, o escalonador especializado em MPPs
faz a partição do trabalho entre os MPPs escolhidos e envia a solicitação mais refinada
para o co-alocador. O co-alocador garante que as tarefas submetidas aos distintos MPPs
comecem a executar simultaneamente. Note também que outros escalonadores de
aplicações podem participar do sistema. A Figura 10, por exemplo, exemplifica ainda
escalonadores para varredura de parâmetros e para ambientes de colaboração virtual.
 Figura 10. Exemplo de submissão de aplicações a grade Globus [Foster 1998].

11.3.1.3. Comunicação
O problema de comunicação na grade pode ser visto como uma instância do eterno
conflito entre generalidade e desempenho. Caso utilizemos um mecanismo de
comunicação genérico (e.g. TCP) que viabilize a comunicação fim-a-fim entre
quaisquer duas tarefas na Grade, perdemos desempenho em casos especiais (e.g. se
ambas tarefas rodam em uma máquina de memória compartilhada, elas poderiam se
comunicar muito mais rapidamente pela memória). Por outro lado, gostaríamos de usar
um mecanismo genérico para não ter que programar para cada uma das várias
tecnologias de comunicação existentes.
O Globus ataca este problema com o Nexus. O Nexus fornece uma interface de
baixo nível, mas uma implementação adaptável que escolhe dentre as tecnologias de
comunicação disponíveis, a que vai oferecer melhor desempenho. Por exemplo, se
ambas tarefas estão em uma máquina de memória compartilhada, o Nexus utilizará a
memória para efetuar a comunicação. Caso as tarefas estejam em um MPP, Nexus
utilizará o switch de alta velocidade para comunicação. Caso as tarefas estejam em
máquinas geograficamente distantes, o Nexus utilizará TCP/IP.
O Nexus fornece uma interface de relativo baixo nível: invocação remota de
procedimento, mas sem retorno de resultado. Portanto, programar diretamente em
Nexus não é das tarefas mais agradáveis. Entretanto, a idéia da equipe Globus é que
Nexus seja usado por desenvolvedores de ferramentas e mecanismos de comunicação,
não diretamente pelo desenvolvedor de aplicações. O MPI-G é o exemplo perfeito desta
abordagem. O MPI-G implementa o popular padrão MPI (Message Passing Interface)
sobre Nexus. Assim, o desenvolvedor de aplicações escrever em MPI e link-editar sua
aplicação com MPI-G para automaticamente ter acesso a melhor tecnologia de
comunicação disponível (selecionada pelo Nexus).
11.3.1.4. Transferência de Dados
A necessidade de acesso remoto e transferência de dados é uma constante na
computação em grade. Na verdade, várias das aplicações 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 serviço para acesso remoto a arquivos sob a tutela de um
servidor GASS. O cliente GASS é uma biblioteca C que é link-editada à aplicação
usuária do serviço. Com o intuito de fornecer boa desempenho, o serviço GASS
implementa as otimizações típicas de acesso remoto como caching e pre-fetching.
Apesar de ser um bom serviço, o GASS encontrou problemas de implantação. A
dificuldade encontrada foi a interoperabilidade. A maioria das fontes de dados onde se
instalaria um servidor GASS já executa algum serviço de transferência e/ou acesso
remoto aos arquivos. Os administradores de sistema se questionavam porque não se
poderia usar os serviços existentes.
Essa realidade motivou a introdução 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 computação em grade. Mais precisamente, o GridFTP
introduz suporte a:
• Autenticação GSI e Kerberos.
• Transferência em paralelo (várias conexões TCP entre fonte e destino).
• Transferência em faixas (conexões TCP entre várias fontes e um destino).
• Controle manual dos buffers TCP (usado para afinamento de desempenho).
• Instrumentação embutida.
Uma vez que o GridFTP é uma extensão do FTP, o problema de
interoperabilidade fica resolvido, pois FTP é amplamente suportado pelos servidores de
dados. Obviamente, se as extensões GridFTP não estiverem implementadas em um dado
servidor, os benefícios adicionais do protocolo não estarão disponíveis. 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 visão da orientação a serviços, houve um convergência de
tecnologias da área de computação de alto desempenho e de padrões bem consolidados
pela indústria, isso ocorreu através da união de tecnologias e conceitos grades com web
services [Kreger 2003]. A partir disto foi definida uma arquitetura de serviços básicos
para a construção de uma infraestrutura de Grades Computacionais baseados em
Serviços. Esta arquitetura foi denominada Open Grid Services Architecture, OGSA
[Foster 2002].
A definição do OGSA contempla a idéia de interconexão de sistemas e acriação
de ambientes virtuais multi-institucionais. Além disso, os recursos que podem ser
agregados à grade são representados por serviços e estes serviços são chamados de Grid
Services [Foster 2002]. Os grid services são essencialmente web services que seguem
convenções estabelecidas na especificação da OGSA e suportam interfaces padronizadas
para garantir algumas operações adicionais, como gerenciamento do ciclo de vida do
serviço.
As interfaces padrões definidas pelo OSGA facilitam a virtualização de recursos
e serviços. Isso possibilita o uso de vários tipos de recursos de forma transparente. Outra
vantagem da virtualização é que interfaces padrões permitem um baixo acoplamento
entre o cliente e o provedor do serviço. Esse baixo acoplamento facilita a mudança na
implementação dos serviços sem causar, necessariamente, mudanças na implementação
do cliente, bem como o inverso.
Após a definição do modelo da arquitetura e identificação de serviços básicos
através do padrão OGSA foi necessária a especificação do comportamento desses
serviços. Sendo assim, o passo seguinte foi a especificação dessa infraestrutura serviços
básicos, no intuito de permitir a implementação do modelo da arquitetura definida pela
OGSA. A nova especificação foi denominada Open Grid Services Infrastructure
(OGSI) [Alliance 2003] e tem o objetivo de definir as interfaces básicas e os
comportamentos de um Grid Service [Alliance 2003]. OGSI é a materialização da
arquitetura definida pelo padrão OSGA, pois os serviços especificados servem como
base para construção das grades. Em termos práticos, a especificação OSGI define:
• Um conjunto de extensões para a linguagem WSDL (Web Service Description
Language).
• Padrões de estrutura e operação, em WSDL, para representação pesquisa e
atualização de dados sobre os serviços.
• As estruturas Grid Service Handle e Grid Service Reference usados para referenciar
um serviços.
• Formato para mensagens que indicam falhas, sem modificar o modelo de mensagens
de falha da linguagem WSDL.
• Conjunto de operações que permitem a criação e destruição de Grid Services. Esse
conjuntos de operações devem fornecer destruição explícita de serviços, como
também garbage collection (destruição implícita do serviço).
• Conjunto de operações para criação e uso de coleções de Web Services por
referência.
• Mecanismos que permitam notificação assíncrona, caso haja mudança em valores
dos elementos de dados dos serviços.

O Globus Toolkit 3.0 (GT3) [Foster 1997] forneceu a primeira implementação

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 padrões. Assim, OGSA define Grid Services, OGSI
especifica o comportamento de Grid Services, Web Services são estendidos para se
tornar Grid Services e Globus 3 implementa a especificação OGSI. Além disso, Globus
provê serviços básicos necessários para a construção de serviços de mais alto nível (e.g.
serviços de autenticação 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 especificação OGSI precisavam ser refinados devido a evolução da
arquitetura Web Services.
O principal ponto de crítica foram os mecanismos de endereçamento para os
serviços (i.e. Grid Service Handler e Grid Service Reference). Nesse caso, WS-
Addressing surgiu pra fornecer um mecanismo de endereçamento independente da
camada de transporte [Alliance 2003]. Além disso, outras características de OGSI
precisavam ser modificadas para acompanhar a evolução da tecnologia Web Service,
melhorando assim a especificação OGSI. Assim, WSRF (Web Service Resource
Framework}) é basicamente o resultado do refinamento de OGSI no intuito de
aproveitar a existência dos novos padrões 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 divisão de OGSI em várias
especificações separadas, porém agrupadas em uma família. A idéia é reduzir a
complexidade de uma especificação longa, que dificulta a adoção incremental de
funcionalidades.
Outra medida importante foi a recuperação da compatibilidade com as
ferramentas existentes para XML e Web Services, pois OGSI usa GWSDL, a qual provê
acréscimos à WSDL 1.1 que estarão disponíveis na WSDL 1.2/2.0. Ao contrário de
OGSI, ao invés de estender a definição de portType WSDL 1.1, ou mesmo esperar pelo
da nova versão 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 não devem manter estado ou ter instâncias. Ou seja, OGSI modela um recurso
que mantém estado como um Web Service que encapsula o estado do recurso. WS-
Resource Framework modifica esse modelo para criar uma distinção explícita entre
serviço e entidades que mantêm estado e são manipuladas através do serviço. Esta
composição é denominada WS-Resource pelo padrão WSRF, que introduz a idéia de
recursos que mantêm estados e podem ser acessados através de Web Services via o uso
convencional de WS-Addressing.
Portanto, em linhas gerais, a evolução de OGSI obedeceu três fases de forma
incremental. A primeira, a introdução do conceito de WS-Resource. Em seguida a
divisão de funcionalidades em várias especificações melhorando a compatibilidade com
ferramentas usadas para Web Service. Finalmente, uma melhoria nos mecanismos de
notificação.
O padrão WSRF deve se materializar, de forma estável, através do lançamento
do Globus 4. Atualmente, o Globus se encontra na versão 3.9.5, que apesar de instável
já incorpora várias das funcionalidades contempladas no padrão WSRF. Por exemplo, o
GRAM do Globus 3, será substituído pelo WS-GRAM, o qual segue as especificações
definidas na família de padrões WSRF.
11.3.1.7. Avaliação do Globus
Um aspecto importante para grande aceitação do Globus é que os serviços oferecidos
são razoavelmente independentes, possibilitando que se utilize apenas parte dos serviços
Globus em uma dada solução. Essa possibilidade do uso parcial de Globus ajuda
bastante na adaptação de aplicações paralelas existentes para a grade. Pode-se começar
usando serviços mais básicos e ir, aos poucos, incorporando funcionalidades mais
avançadas. O projeto oposto à abordagem “ conjunto de serviços independentes” do
Globus é exemplificado pelo Legion [Grimshaw 1997]. O Legion fornece um modelo
orientado por objetos poderoso e flexível. Entretanto, o usuário tem que abraçar a
solução Legion integralmente, sem estágios intermediários. Esta diferença de
abordagem talvez tenha contribuído para prevalência do Globus como padrão de facto
como infra-estrutura para computação em grade.
É interessante notar que a decisão de estruturar Globus como um conjunto de
serviços independentes deixa claro que Globus não é uma solução pronta e completa
(plug-and-play) para construção de grades. O Globus certamente fornece serviços úteis
para computação em grade, mas desenvolvedores, administradores e usuários precisam
despender certo esforço para finalizar a instalação de sua grade. Por exemplo,
administradores precisam decidir como e quais usuários terão acesso a quais recursos e
em quais condições este acesso se dará. Em outro exemplo, freqüentemente é necessário
desenvolver escalonadores de aplicação que tenham conhecimento sobre as aplicações
que serão executadas e eventualmente também sobre a estrutura da grade a ser usada.
A computação em grade é simplesmente muito complexa para possibilitar
soluções plug-and-play. Portanto, o fato do Globus não ser uma solução pronta e
completa não é nenhum demérito. Entretanto, algumas pessoas têm a idéia de que
Globus é a solução completa e perfeita. Esta falsa concepção é um problema, pois gera
falsas expectativas e obscurece discussões técnicas com alegações de marketing.
A introdução do padrão OGSA criou um alinhamento com tecnologias e padrões
Web Services, assim vários desses aspectos discutidos anteriormente se modificaram em
busca da implementações de padrões que promovem maior interoperabilidade.
A arquitetura do Globus Toolkit 3 é uma implementação da especificação OGSI
(Open Grid Services Infrastructure), os serviços implementados na camada GT3 Core
Services representam os serviços especificados pela OGSI. O objetivo é especificar
mecanismos para criação, gerenciamento e troca de dados entre Grid Services.
Como discutimos anteriormente, há uma tendência forte de convergência entre
as tecnologias de Grades Computacionais e Web Services. Isso fica claro com a
introdução da especificação WSRF, que posiciona as tecnologias de grades junto aos
padrões para Web Services.

11.3.2. Gridbus
O projeto Gridbus é um projeto código 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 serviço para
o suporte de aplicações de eScience e eBusiness. Ele provê uma camada de abstração
que esconde as peculiaridades dos recursos heterogêneos middlewares de baixo nível
dos desenvolvedores de aplicações. Além disso, o Gridbus usa modelos econômicos
para o gerenciamento eficiente de recursos compartilhados. Portanto, ele aumenta a
possibilidade de negociação de serviços de grade gerencia eficientemente o
fornecimento e a demanda de recursos. O Gridbus suporta a especificação de serviços de
grade em vários níveis: (i) Raw Resource Level pela venda de ciclos de CPU e recursos
de armazenamento; (ii) Application Level por operações de modelagem de moléculas
para aplicações de projeto de novos remédios; (iii) Aggregated Services pela busca de
serviços através de múltiplos domínios [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 distribuídas 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 organização.
• Alocação de Recurso e Economia de Cluster: a tecnologia Libra é um sistema de
escalonamento em aglomerados que garante um certo compartilhamento de recursos
para a aplicação de um usuário, que deve executar até um determinado deadline.
• Economia de Grade e Empresa Virtual: o Grid Market Directory é um serviço
de registro, onde os provedores de serviços podem registra-se e publicar serviços que
eles provém e consumidores podem procurar por serviços que atendem aos seus
requisitos.
• Negociação da Grade e Serviços de Contas: o Grid Bank é um serviço de contas e
pagamento que provê uma infra-estrutura segura para o pagamento pelo uso dos
serviços prestados pelos provedores de recursos.
• Busca e Escalonamento de Recursos na Grade: o Gridbus Broker provê uma
abstração à complexidade das grades garantindo a transparência de acesso a recursos
de dados e computacionais para a execução de uma tarefa na grade. Ele utiliza
requisitos do usuário para a criação de um conjunto de tarefas, descoberta de
recursos, escalonamento, execução e monitoramento das tarefas.
• Gerenciamento de Tráfego da Grade (Gridbus Workflow Engine).
• Interface de Programação de Aplicações (Visual Parametric Modeller).
• Portais da Grade: a ferramenta GMonitor é um portal web para monitoramento de
computações em grades globais.
• Simulação da Grade: o Gridsim é uma ferramenta de simulação que suporta
modelagem e simulação discreta por eventos de arquiteturas em grade heterogêneas,
tal como mono ou multiprocessadores, máquinas de memória compartilhada e
distribuída, e escalonamento de tarefas em sistemas paralelos e distribuídos
(aglomerados de computadores etc.).

Atualmente existem diversas aplicações 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 médio 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 vazão (high throughput) e não alto desempenho [Basney 1999]
[Epema 1996] [Frey 2001] [Litzkow 1988]. Entenda-se disto que Condor visa fornecer
desempenho sustentável a médio e longo prazos, mesmo que o desempenho instantâneo
do sistema possa variar consideravelmente.
O usuário submete ao Condor tarefas independentes para execução. Isso
significa que uma aplicação Condor é uma aplicação Bag of Tasks (BoT). Enquanto este
fato limita as aplicações que podem ser executadas no Condor, deve-se salientar que há
um grande número de aplicações importantes que são BoT. Além disso, aplicações BoT,
devido ao seu fraco acoplamento, são bastante adequadas para execução 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 máquinas pertencentes
ao Pool. Tal alocação é baseada nas necessidades de cada tarefa e nas restrições de uso
de cada máquina. As necessidades de uma tarefa são especificadas pelo usuário quando
de sua submissão. Por exemplo, uma tarefa pode precisar de uma máquina Sun Sparc,
rodando Solaris, com pelo menos 256MB de memória. Já as restrições de uso de uma
dada máquina, estas são especificadas por seu dono quando da inclusão da máquina no
Pool. Por exemplo, o dono pode preferir que sua máquina execute as aplicações de João,
seguido das aplicações do grupo de sistemas operacionais, e que nunca execute as
aplicações de Pedro. Ou seja, as restrições permitem ao dono determinar como sua
máquina será usada no Condor Pool. Tipicamente, o que o dono estabelece inclui que
sua máquina só é usada quando estiver ociosa e que, quando ele voltar a utilizar a
máquina, qualquer aplicação Condor em execução seja suspensa imediatamente.
Um aspecto interessante do Condor é que ambos usuários e donos de máquinas
são representados no sistema por agentes de software. O Agente do Usuário (Customer
Agent) envia as necessidades da tarefa para o Matchmaker. Similarmente, o Agente do
Dono (Resource Owner Agent) envia as restrições de uso do recurso ao Matchmaker. Ao
efetuar o casamento entre tarefa e máquina, o Matchmaker notifica ambos agentes. A
partir daí, o Agente do Usuário e o Agente do Dono interagem diretamente para realizar
a execução 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 máquina seja “ desocupada” pela tarefa
Condor assim que ele retornar a usá-la, garantir progresso das tarefas torna-se um
problema não-trivial. O Condor aborda esta questão fazendo o checkpoint da tarefa (i.e.
salvando transparentemente seu estado), o que permite que a tarefa seja re-executada em
outra máquina a partir do ponto em que parou. O mecanismo de checkpoint do Condor é
implementado através da substituição 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 máquina base e migração de tarefas são complementares.
O Condor foi inicialmente concebido para execução em NOWs [Litzkow 1988],
mas posteriormente estendido para execução em grades [Epema 1996] [Frey 2001]. O
que tornou possível à extensão relativamente simples do Condor de NOWs a grades
coputacionais, foi o fato da aplicação suportada (BoT) ser bastante adequada a grades
computacionais. É interessante notar que Condor dispõe 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 vários Condor Pools[Epema 1996]. A construção do
Flock é bastante elegante do ponto de vista de sistemas distribuídos, pois não acrescenta
nenhuma centralização a arquitetura Condor original. A base para criação de um Flock é
um acordo de cooperação (de troca de recursos) entre dois Condors Pools. Portanto, por
maior que seja o Flock, suas ligações são sempre dois-a-dois, sem envolver nenhuma
entidade centralizadora. Mais que isso, o Flock of Condors não chega a alterar o
software Condor original. Toda a funcionalidade do Flock of Condors é implementada
por uma máquina especial, chamada Gateway. Ambos os Pools que firmam um acordo
de cooperação instalam cada qual um Gateway. Os dois Gateways mantém comunicação
constante para troca de tarefas entre os Pools. Para o Pool local, o Gateway é uma
máquina qualquer. Entretanto, ao invés de oferecer seus próprios recursos, o Gateway
simplesmente representa os recursos do Pool remoto, republicado as restrições
estabelecidas pelos donos das máquinas remotas. Quando uma tarefa é recebida pelo
Gateway, este a repassa para o Gateway remoto que então a encaminha para uma
máquina para execução.
Talvez por ser mais recente, o Condor-G adota uma visão mais heterogênea de
grade. Além de Condor Pools, o Condor-G também utiliza recursos via Globus. Devido
à necessidade de suportar ambientes mais heterogêneos, o Condor-G usa uma
arquitetura mais centralizada que o Flock of Condors. O Condor-G Scheduler controla a
execução da aplicação, submetendo tarefas tanto a Condor Pools quanto a recursos
acessíveis via Globus (como MPPs). No caso de recursos Globus, o Condor-G utiliza os
serviços GRAM, GASS, MDS e GSI para viabilizar a execução das tarefas.

11.3.4. MyGrid
A motivação para a construção do MyGrid surgiu do fato que, embora bastante pesquisa
tenha sido realizada para o desenvolvimento dos grades computacionais, poucos
usuários executavam suas aplicações paralelas sobre essa infraestrutura. Assim, foi
concebido projeto MyGrid, com o intuito de alterar esta situação. Para tanto, foram
atacadas apenas aplicações Bag-of-Tasks, ou seja, aquelas aplicações cujas tarefas são
independentes, podendo ser executadas em qualquer ordem. Aplicações Bag-of-Tasks
são um alvo interessante porque (i) se adequam melhor a ampla distribuição,
heterogeneidade e dinamicidade da grade, e (ii) resolvem vários problemas importantes,
tais como mineração de dados, processamento genômico, pesquisa massiva (como
quebra de chaves criptográficas), varredura de parâmetros, simulações Monte Carlo
(muito utilizado, por exemplo, pela indústria farmacéutica [Hoffman 2005]),
computação de fractais (como Mandelbrot), e manipulação de imagem (como
tomografia).
Estabelecido o escopo do MyGrid, nosso objetivo é construir um sistema
simples, completo e seguro. Por simples queremos dizer que o esforço para utilização do
MyGrid deve ser mínimo. Em particular, queremos chegar o mais próximo possível de
uma solução pronta (plug-and-play). Por completo denotamos a necessidade de cobrir
todo o ciclo de uso de um sistema computacional, do desenvolvimento à execução,
passando por instalação e atualização e incluindo também a manipulação de arquivos.
Por seguro expressamos a necessidade de não introduzir vulnerabilidades ao ambiente
computacional do usuário. Ou seja, não queremos que falhas de segurança em qualquer
uma das máquinas que o usuário possa utilizar sejam propagadas para sua máquina base
(i.e. o computador usado pelo usuário).
MyGrid diferencia entre máquina base e máquina do grade. Em um MyGrid, a
máquina base é aquela que controla a execução da aplicação. Ela tipicamente contém os
dados de entrada e coleta os resultados da computação. A máquina base é normalmente
usada pelo usuário diretamente no seu dia-a-dia, muitas vezes sendo o próprio
computador desktop do usuário. Esperamos, portanto, que o usuário tenha excelente
acesso à máquina base e que tenha customizado um ambiente de trabalho confortável
nela.
Todas as máquinas usadas via MyGrid para executar tarefas são chamadas de
máquinas da grade. Ao contrário da máquina base, não assumimos que o usuário
customizou cada máquina da grade para criar-lhe um ambiente de trabalho familiar.
Além disso, todas as máquinas da grade tipicamente não compartilham um mesmo
sistema de arquivo ou têm os mesmos softwares instalados. A imagem do sistema pode
variar de uma máquina da grade para outra. Portanto, para mantermos a simplicidade de
uso do sistema, precisamos evitar que o usuário tenha que lidar diretamente com as
máquinas da grade. Por exemplo, queremos evitar que o usuário tenha que instalar
software em cada máquina de sua grade. A idéia é que máquinas da grade sejam
manipuladas através das abstrações criadas por MyGrid (descritas a seguir na Tabela 3).
Um aspecto importante de MyGrid é dar ao usuário a possibilidade de usar
quaisquer recursos que ele tenha acesso . Este não é um objetivo trivial porque ele
implica que temos que assumir muito pouco a respeito de uma máquina da grade, de
forma a não impedir algum usuário de usar uma máquina que não suporta nossas
hipóteses. Em particular, não podemos assumir que tal recurso tenha software MyGrid
instalado. MyGrid define Grid Machine Interface como sendo o conjunto mínimo de
serviços que precisam estar disponíveis para que uma dada máquina possa ser
adicionada à grade do usuário. Tais serviços são:

Tabela 3. Serviços que definem a Grid Machine Abstraction.

Serviços
Execução remota
Transferência de arquivos da máquina da grade para a máquina base
Transferência de arquivos da máquina base para a máquina da grade
Interrupção de uma execução múltipla

Como ilustrado pela Figura 13, há várias formas de implementar os serviços

oferecidos através da Grid Machine Interface. Uma forma é fornecer ao sistema scripts
que implementam os serviços listados na Tabela 3. Neste caso, MyGrid utiliza o módulo
Grid Script para acessar a má-quina em questão. Note que Grid Script possibilita que,
qualquer que seja a máquina que o usuário tem acesso, ele possa informar como este
acesso se dá através da escrita de três scripts. Alternativamente, há casos em que a
forma de acessar uma determinada máquina da grade já é do conhecimento do MyGrid.
Por exemplo, suponha que a máquina em questão pode ser acessada via serviços Globus
(GSI, GRAM e GridFTP). Neste caso, o usuário não precisa fornecer os scripts,
indicando apenas que o acesso à máquina já é conhecido de MyGrid. Finalmente,
MyGrid também provê um mecanismo de acesso a máquinas da grade, chamado de User
Agent. O User Agent provê serviços simples. É interessante notar que, pela terminologia
adotada por [Foster 2002], Grid Machine Interface é uma virtualização para os serviços
de acesso a uma máquina da grade.

Figura 13. Arquitetura do MyGrid.

Outro componente fundamental a arquitetura MyGrid é o escalonador ou

scheduler. O escalonador recebe do usuário a descrição das tarefas a executar, escolhe
qual processador usar para cada tarefa, e finalmente submete e monitora a execução da
tarefa. O MyGrid possui atualmente duas heurísticas de escalonamento: Workqueue
with Replication (WQR [Paranhos 2003]} e Storage Affinity [Neto 2005]. Ambas,
conseguem obter uma boa performance mesmo sem utilizar informações sobre o estado
do Grid ou o tamanho de cada tarefa. O WQR foi definido para aplicações de cpu
intensivas, enquanto Storage Affinity foi desenvolvido para melhorar o desempenho de
aplicações que processam grandes quantidades de dados.
Note que ter um algoritmo de escalonamento que funciona bem sem depender de
muita informação é importante, pois simplifica a definição da Grid Machine Interface.
Caso o algoritmo de escalonamento do MyGrid necessitasse de informações sobre as
máquinas da grade, Grid Machine Interface teria que ser mais rica e, portanto, mais
difícil de virtualizar. Por exemplo, o Nimrod-G [Buyya 2000] define uma interface de
abstração para os recursos, que contempla métodos de fornecimento de informação
sobre o recurso. Certamente, a informação obtida por esses métodos é valiosa para o
escalonamento eficiente das aplicações. Porém, isso limita o tipo de recurso que pode
ser utilizado, pois torna o middleware dependente de um recurso que forneça uma
implementação para os métodos dessa interface.
Uma aplicação (ou job) MyGrid é composta de tarefas independentes. Estas
tarefas são compostas por três partes ou sub-tarefas: init, remote e final. As sub-tarefas
são executadas seqüencialmente ($init → final$). As sub-tarefas init e final são usadas
para efetuar as transferências de arquivo de entrada e saída da tarefa respectivamente.
Sendo assim, tanto a sub-tarefa inicial quando a final são executadas na máquina base.
Enquanto, a sub-tarefa remote, como o próprio nome sugere, é executada em uma
máquina da grade e realiza a computação propriamente dita da tarefa.
Para definir as sub-tarefas inicial e final, o usuário tem disponível algumas
abstrações providas pelo MyGrid para lidar com a máquina da garde sem necessitar de
conhecer sua imagem do sistema. As abstrações providas pelo MyGrid são storage e
playpen. O serviço de storage possui a semântica de uma área de armazenamento
persistente à execução da tarefa. Ou seja, é útil usar storage para distribuição de
arquivos que provavelmente serão reutilizados no Grid (ex.: executáveis da aplicação).
Assim sendo, qualquer arquivo transferido para o storage é automaticamente incluído
no PATH da máquina da grade. Por outro lado, o playpen provê uma área de
armazenamento temporária de maneira independente das convenções locais do sistema
de arquivo de uma dada máquina da grade. Essa área de armazenamento temporária é
criada automaticamente e é o diretório base de execução da sub-tarefa remote. Note que
o playpen foi concebido para possibilitar o armazenamento de dados temporários e
resultados de tarefas. Também no sentido de simplificar a escrita das sub-tarefas, as
variáveis de ambiente $storage, $playpen, $proc e $task são automaticamente definidas
pelo MyGrid e contêm, respectivamente, o caminho completo para área de storage, o
caminho completo para o playpen de uma dada tarefa, o nome da máquina da grade
escolhida para executar a tarefa e um identificador da tarefa.

11.3.4.1. OurGrid
Ao contrário do Globus, a solução OurGrid tem um escopo diferente, porém
complementar. O objetivo é prover uma solução efetiva para a execução de aplicações
Bag-of-Tasks em Grades Computacionais. Sendo assim, as decisões de projeto estão
centradas no uso da solução em ambientes de produção. Portanto, a idéia básica é
abdicar da generalidade, em alguns casos, no intuito de se obter uma solução, apesar de
simples, eficiente e que possa ser facilmente usada em produção.
A arquitetura do OurGrid, ilustrada na Figura 13, é formada por três
componentes: MyGrid Broker, OurGrid Peer e uma solução de sandboxing baseada na
máquina virtual Xen [Barham 2003]. Nas seções seguintes descreveremos como os
componentes do OurGrid abordam alguns spectos importantes da Computação em
Grade.

11.3.4.2. Autenticação
Na arquitetura OurGrid existem basicamente dois níveis de autenticação. Esses níveis
dependem de como o usuário obteve o recurso. Primeiramente, o usuário pode ter
acesso direto a alguns recursos (i.e. Grid Machines - GuMs - em sua rede local), neste
caso o usuário usa o esquema de autenticação tradicional, em geral, isso implica na
utilização da infraestrutura de autenticação do sistema operacional do recurso, ou seja,
nome de usuário (login) e uma senha.
Contudo, além das GuMs que o usuário tem acesso direto, OurGrid permite (e
promove) a obtenção de acesso a GuMs de outros sites, isso ocorre através de um
OurGrid Peer local ao site do usuário. Este peer deve estar conectado à rede de favores
(ver Figura 13). Assim, para as GuMs obtidas da comunidade, há uma autenticação em
duas vias baseada em certificados digitais no formato X.509. A primeira parte da
autenticação deve garantir que o usuário tem permissão para solicitar serviços às GuMs
(i.e. que a GuM conhece o usuário que está requisitando seus serviços). A segunda parte
deve garantir que o usuário não está solicitando serviços a uma falsa GuM. Ou seja,
tanto o usuário, através do broker, quanto os peers da comunidade possuem uma lista de
certificados que são usadas para validar a tentativa de aceso.
Isso impede que usuários não autorizados pelo peer, obtenham acesso aos
serviços de descoberta de novas Grid Machines, transferência de arquivos, execução e
gerenciamento do ciclo de vida de replicas fornecido pelas GuMs controladas por um
dado peer.
Outro aspecto importante é que através da utilização de certificados, a
comunicação entre o MyGrid Broker, o peer e as Grid Machines será segura, evitando
que os dados sejam interceptados e manipulados durante a comunicação. A segurança na
comunicação é fornecida através do uso de RMI baseado em SSL (Secure Socket
Layer), que garante comunicação criptografada.

11.3.4.3. Descoberta e Alocação de Recursos

Para executar uma aplicação usando a OurGrid o usuário deve descrever sua aplicação e
o conjunto de recursos que o usuário tem acesso. Note que esse conjunto de recursos
pode ser apenas a indicação de um OurGrid Peer, que tem a função de obter recursos
para o usuário.
A descrição da aplicação é basicamente: um conjunto tarefas, seus arquivos de
entrada, arquivos de saída e seus requisitos (e.g. sistema operacional necessário, mínimo
de memória, arquitetura do processador). Em seguida, o usuário o submete sua
aplicação para execução no Grid através do MyGrid Broker. O componente interno do
MyGrid Broker que recebe a submissão é o escalonador. Por sua vez, o Scheduler
requisita aos provedores de GuMs recursos para executar a aplicação submetida pelo
usuário. Esses provedores podem responder com recursos locais ou recursos obtidos na
rede de favores. Para que o escalonador receba uma resposta dos provedores é
necessário que tenha sido encontrada uma GuM que preenche os requisitos
determinados na descrição da aplicação.
Portanto, após ter sido descoberto um recurso que possui atributos compatíveis
com os requisitos da aplicação, o recurso é alocado e repassado para o escalonador que
o solicitou. Certamente, isso só irá ocorrer caso o recurso esteja disponível. Porém, caso
o recurso tenha sido descoberto através da rede de favores, o recurso pode ser tomado de
volta (i.e. preemptado) pelo peer que o forneceu, seguindo a dinâmica da rede de
favores. A preempção é um evento natural e previsto pela arquitetura do OurGrid, uma
vez que os recursos só são cedidos caso esteja ocioso. Ou seja, uma solicitação local no
site, ao qual o recurso pertence, pode ocasionar a preempção.
Vale também ressaltar que a alocação do recurso é feita no nível do MyGrid
Broker, ou seja, isso não significa que o recurso estará dedicado exclusivamente ao
MyGrid Broker. Portanto, não há impedimento para que outras aplicações que não usam
a infraestrutura do OurGrid estejam executando concorrentemente com a aplicação
submetida pelo usuário.
11.3.4.4. Comunicação
Uma vez que o foco da solução OurGrid está nas aplicações Bag-of-Tasks, não faz parte
do escopo da solução OurGrid prover mecanismos de comunicação para aplicações
fortemente acopladas. Mesmo assim, é possível usar a infraestrutura OurGrid para
executar aplicações deste tipo, desde que a execução seja interna a um site. Por
exemplo, uma aplicação que usa MPI, quando descrita pelo usuário, pode ter
especificado em seus requisitos que necessita de uma GuM (Grid Machine), que na
verdade é o front end de uma coleção de vários processadores (i.e. um cluster). Essa
demanda será atendida se existir uma GuM, não alocada, que possua um atributo
compatível com o requisito especificado pela aplicação. Portanto, apesar de não ter uma
arquitetura que provê comunicação entre as tarefas que estão sendo executadas nas
GuMs, a solução OurGrid provê meios de agregar ao Grid GuMs que permitem a
execução de aplicações fortemente acopladas.

11.3.4.5. Transferência de Dados

A solução OurGrid para transferência de dados é baseada no tratamento de arquivos.
Desta forma, o usuário ao descrever sua aplicação tem a sua disposição o uso de três
operações de transferência arquivos, put, store e get, que podem ser usadas para preparar
o ambiente para execução da aplicação (colocando os arquivos nos sites onde a
aplicação irá executar), como também coletar os dados resultantes do processamento.
Tanto put quanto store são operações que permitem a transferir arquivos para a
GuM. A diferença entre as duas operações consiste apenas do fato que store evita a
transferência do arquivo caso o arquivo já se encontre armazenado no lado remoto. Isso
é útil, por exemplo, para executáveis da aplicação e dados que são reutilizados entre
execuções sucessivas da aplicação. A terceira operação, get, fornece um método de
coletar arquivos resultantes da execução das aplicações.
A infraestrutura de comunicação usada para a transferência é a mesma usada
para a solicitação de serviços de execução, ou seja, RMI. Uma vez que é possível ter
segurança na comunicação com as GuMs de RMI sobre SSL, as operações de
transferências de dados também gozam da segurança fornecida pela camada de
comunicação baseada em certificados.

11.3.4.6. Avaliação do OurGrid

A característica mais importante do OurGrid é conseguir prover uma solução útil e
eficiente para uma comunidade de usuários em produção, apesar de se basear em
soluções simples e de escopo limitado (i.e. apenas aplicações do tipo Bag-of-Tasks).
É importante notar que o objetivo do OurGrid contrasta com o objetivo do
Globus, que fornece um conjunto de serviços para a construção da infraestrutura da
grade. Portanto, OurGrid é uma solução que complementa o Globus provendo um
broker (i.e. MyGrid) e abstrações que permitem o usuário usar recursos Globus e não-
Globus. Por outro lado, Globus complementa o OurGrid ao fornecer a infraestrutura de
serviços para execução de aplicações em larga escala.
OurGrid persegue um objetivo diferente do que seria prover uma solução
genérica para computação em Grid. Com o foco em aplicações BoT foi possível
produzir uma solução efetiva para uma comunidade de usuários em produção. Não se
quer dizer com isso que não se pretende introduzir novas funcionalidades, que
aumentem o escopo da solução. Ao contrário, a idéia é gradativamente permitir que
mais aplicações possam utilizar a solução. Por exemplo, suporte a fluxo de dados,
suporte a mineração de dados etc.
Atualmente na versão 3.0.2, OurGrid já é usado em produção por vários grupos
de pesquisa no Brasil [Cirne 2004]. As próximas versões prometem incorporar
melhorias no escalonamento de aplicações, solução de sandboxing, bem como maior
tolerância para aplicações de longa duração (high-throughput computing) através do uso
de checkpoint. O software OurGrid está disponível para download em
{http://www.ourgrid.org}.

11.3.5. Anthill
Como extensão do ambiente DataCutter, a plataforma Anthill foi criada [Meira 2005].
Ela provê um mecanismo chamado fluxo identificado (labeled stream) que permite a
seleção de uma cópia particular baseada nos dados relacionados com as mensagens
(labels). Essa extensão permite um modelo de programação mais rico, facilitando a
partição do estado global de cópias transparentes. Além disso, o Anthill provê um
framework, no qual a execução da aplicação pode ser decomposta numa seqüência de
tarefas intermediárias que precisam ser realizadas e também pode criar múltiplos filtros
em um ambiente iterativo. Ele explora o paralelismo em vários níveis: tempo, espaço e
assincronia.

Figura 14. Modelo de Programação de uma Aplicação Anthill.

Como podemos observar na Figura 14, uma aplicação Anthill explora o

paralelismo de tempo como um pipeline, porque ela é composta de N filtros (estágios ou
fases de processamento) conectados por fluxos de dados (canais de comunicação). Esse
modelo de aplicação força 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 domínio ou espaço de dados, que é necessário para o próximo filtro.
 O modelo de programação do Anthill também explora o paralelismo de espaço,
pois cada filtro possui múltiplas cópias ou instâncias. Cada canal de comunicação entre
filtros pode ser nomeado para direcionar um fluxo de dados para uma cópia específica
de um filtro (ponto a ponto) ou para todas as cópias de um filtro (broadcast). Uma
consequência do paralelismo de espaço é o paralelismo de dados, porque um banco de
dados é automaticamente dividido entre as cópias dos filtros. Juntamente com os fluxos,
o paralelismo de dados provê um mecanismo eficiente de divisão da demanda de E/S
entre os filtros.
Além disso, o Anthill tira vantagem da assincronia e provê iteratividade. Cada
aplicação possui um conjunto de pedaços de trabalho (work slices) a serem executados.
De acordo com os conjuntos de dados lidos das bases de dados, um pedaço de trabalho é
criado. Eles podem ser executados independentemente, respeitando apenas a
dependência de dados. Depois de processados, eles também podem gerar novos pedaços
de trabalho, esse fato justifica a necessidade de um processo iterativo.
11.4. Aplicações de Computação em Grade
Neste tópico apresentamos diversos tipos de aplicações para a computação em grade:
mineração de dados, buscas massivas, simulações de Monte Carlo, cálculo de fractais,
biologia computacional e processamento de imagens. Dentre essas aplicações,
destacaremos as que seguem os modelos bag-of-tasks e fluxo de dados. Apresentaremos
aplicações de mineração de dados (fluxo de dados) em bases de dados reais, executando
em uma plataforma de computação em grade.

11.4.1. Jacobi
Jacobi AppLeS [Berman 1996] é um exemplo interessante por ter lançado a idéia de
escalonamento de aplicações e também por escalonar uma aplicação bem conhecida
(Jacobi). Jacobi é um método usado para resolver a aproximação por diferenças finitas
da equação de Poisson e portanto é aplicável a problemas que envolvem fluxo de calor,
eletrostática e gravitação. Além de ser interessante por si só, Jacobi pode ser visto como
uma instância de uma importante classe de aplicações paralelas: aplicações fortemente
acopladas de paralelismo em dados.
Jacobi AppLeS é um escalonador para Jacobi 2D. Em Jacobi 2D, o domínio do
problema é discretizado em uma matriz bidimensional. Em cada iteração, cada elemento
da matriz é atualizado com a média dos seus quatro vizinhos. O Jacobi termina por
convergência, isto é, quando uma iteração 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 dimensões, gerando sub-matrizes de igual tamanho. Cada sub-
matriz é então alocada a um processador. A cada iteração, portanto, é necessário
comunicação entre processadores para troca das fronteiras das sub-matrizes. A Figura
15 mostra a distribuição de dados entre 4 processadores de um MPP alocados para
executar Jacobi. Como, em um MPP, os processadores são idênticos e dedicados e a
comunicação é muito boa entre quaisquer dois processadores, esta simples estratégia de
alocação de trabalho balanceia a carga entre os processadores, garantindo bom
desempenho.
 Entretanto em uma grade computacional, processadores e canais de comunicação
são heterogêneos. Além disso, outras aplicações estão concorrendo pelos mesmos
recursos (processadores e canais de comunicação) enquanto a aplicação Jacobi executa.
Conseqüentemente, a estratégia descrita acima provavelmente vai produzir um
desbalanceamento de carga, afetando o desempenho. Mais ainda, uma vez que as
condições de carga da grade variam dinamicamente, o que é uma boa divisão de carga
vai variar a cada execução da aplicação. Finalmente, devido à existência de canais de
comunicação mais lentos e compartilhados com outras aplicações, talvez não valha a
pena utilizar todos os processadores disponíveis.
A solução oferecida por AppLes Jacobi se baseia em três elementos principais.
Primeiro, o escalonamento em si é simplificado pela decisão de utilizar um
particionamento unidimensional. Segundo, o escalonador se utiliza do NWS [Wolski
1998] para obter previsões de curto prazo da disponibilidade de cada processador e da
latência e banda da comunicação entre quaisquer dois processadores. Terceiro, o
escalonador dispõe de um modelo de desempenho da aplicação, que é usado para avaliar
suas decisões. Este modelo é o seguinte:
Ti = Ai × Pi + Ci, onde:
Ti é o tempo para o processador i executar uma iteração
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 são estimados com base nos dados fornecidos pelo NWS.
O escalonamento propriamente dito começa ordenando os processadores por
uma “ distância” específica da aplicação (que cresce quadraticamente com a diferença de
velocidade dos processadores e linearmente com a diferença de suas capacidades de
comunicação). Uma vez os processadores ordenados, tenta-se iterativamente uma
solução com os n primeiros processadores, até que a solução com n - 1 processadores se
mostre mais rápida, ou até que não haja mais processadores. Naturalmente, o tempo de
uma iteração é estimado como o maior Ti de todos os processadores. Fixados n
processadores, a solução 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
aplicação rodando e só poderá dedicar 50% de seu poder computacional a aplicação, que
P3 está conectado a uma rede que vivencia intenso trafego e que sua comunicação está
ordens de grandeza mais lenta que entre os demais processadores. Uma vez que P3 está
se comunicando muito lentamente, o AppLeS não vai utilizá-lo para esta execução. Note
que esta decisão não descarta a possibilidade que P3 venha a ser usado em uma futura
execução da aplicação, quando as condições da rede forem diferentes. Note também
que, embora P1 seja duas vezes mais rápido que P2, uma vez que só 50% de P1 está
disponível, P1 e P2 são idênticos para a aplicação (pelo menos nesta execução). A Figura
16 mostra o resultado que o AppLeS Jacobi produziria neste cenário.
 Devemos salientar que um aspecto importante para o bom funcionamento do
Jacobi AppLeS é o tempo relativamente curto de execução da aplicação. O tempo de
execução dos experimentos descritos em [Berman 1996] é da ordem de segundos,
casando perfeitamente com as previsões de curto prazo do NWS. Para aplicações que
executam por mais tempo (horas, digamos), seria necessário prever a disponibilidade de
recursos da grade por prazos mais longos. Uma alternativa interessante seria construir
um escalonador que, além do escalonamento inicial, continuasse funcionando para
reescalonar a aplicação caso as condições da grade mudassem consideravelmente
[Shao 1997]. Neste caso, naturalmente, a aplicação teria que ser escrita para permitir tal
reescalonamento, suportando a redistribuição de trabalho durante a execução.

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

11.5. Conclusões e Tendências
Neste trabalho apresentamos os principais aspectos de computação em grade, desde a
apresentação de um conceito do que classifica uma infraestrutura de computação
distribuída como uma grade computacional, até o estado atual do desenvolvimento de
tecnologia para a construção dessas infraestruturas. Além disso, apresentamos os
principais conceitos, ferramentas e aplicações em computação em grade.
As grades computacionais levantam questões em várias áreas de pesquisa, porém
seus benefícios vão além de uma simples plataforma para execução de aplicações em
larga escala. A idéia é facilitar a colaboração de grupos de pesquisa distribuídos
geograficamente.
Mostramos então que as grades computacionais surgiram da unificação dos
esforços realizados pela comunidade de Sistemas Distribuídos e Processamento
Paralelo. A infra-estrutura é análoga a grade de fornecimento de energia elétrica, mas
possui várias diferenças discutidas neste trabalho.
Finalmente, a discussão sobre os padrões emergentes para o desenvolvimento de
infraestruturas de grades computacionais, mostra que os esforços têm amadurecido,
fomentado a pesquisa e o desenvolvimento de ferramentas, que contribuem para a
concretização de um ambiente amplamente distribuído onde será possível consumir
serviços computacionais de forma transparente.
Referências Bibliográficas
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” . Supercomputing’96, 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
publicação. (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, pp. 122-129.
(http://www.cs.utk.edu/~plank/plank/papers/CC-GRID-01.html)
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. “ Condor-
G: 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 Transac-
tions 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, São 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, 1998.
(http://www.cs.utk.edu/~rich/publications/index.html)
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.
Góes, 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. 210–232, 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-PAD’2004), 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)