Computação em Grid

40
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.

Transcript of Computação em Grid

Page 1: Computação em Grid

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.

Page 2: Computação em Grid

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].

Page 3: Computação em Grid

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

Page 4: Computação em Grid

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.

Page 5: Computação em Grid

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

Page 6: Computação em Grid

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).

Page 7: Computação em Grid

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

Page 8: Computação em Grid

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.

Page 9: Computação em Grid

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;

Page 10: Computação em Grid

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

Page 11: Computação em Grid

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

Page 12: Computação em Grid

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

Page 13: Computação em Grid

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).

Page 14: Computação em Grid

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

Page 15: Computação em Grid

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.

Page 16: Computação em Grid

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).

Page 17: Computação em Grid

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

Page 18: Computação em Grid

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).

Page 19: Computação em Grid

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.

Page 20: Computação em Grid

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

Page 21: Computação em Grid

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.

Page 22: Computação em Grid

• 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

Page 23: Computação em Grid

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 é

Page 24: Computação em Grid

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

Page 25: Computação em Grid

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

Page 26: Computação em Grid

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.

Page 27: Computação em Grid

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

Page 28: Computação em Grid

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.

Page 29: Computação em Grid

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

Page 30: Computação em Grid

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.

Page 31: Computação em Grid

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.

Page 32: Computação em Grid

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.

Page 33: Computação em Grid

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.

Page 34: Computação em Grid

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].

Page 35: Computação em Grid

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.

Page 36: Computação em Grid

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

Page 37: Computação em Grid

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)

Page 38: Computação em Grid

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

Page 39: Computação em Grid

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.

Page 40: Computação em Grid

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)