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

Transcrição

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

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

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

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

5 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 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

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

7 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

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

9 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 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) 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;

10 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

11 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 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

12 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

13 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 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 GSI GRAM Nexus MPI-G MDS GASS GridFTP Funcionalidade Segurança, autenticação única na grade Submissão e controle de tarefas Comunicação entre tarefas MPI sobre Nexus Informações e diretórios Transferência de arquivos Transferência de arquivos 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).

14 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 u 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

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

16 Figura 10. Exemplo de submissão de aplicações a grade Globus [Foster 1998] 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).

17 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 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

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

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

20 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 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

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

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