COMPARAÇÃO DE SISTEMAS DE MIDDLEWARE PARA GRADES E CLUSTERS COMPUTACIONAIS

Transcrição

1 COMPARAÇÃO DE SISTEMAS DE MIDDLEWARE PARA GRADES E CLUSTERS COMPUTACIONAIS Paulo H. M. A. Oliveira. Departamento de Ciências de Computação e Estatística - Instituto de Biociências Letras e Ciências Exatas - Universidade Estadual Paulista Júlio de Mesquita Filho (UNESP) - São José do Rio Preto - SP oliveiraph@sjrp.unesp.br Abstract. This paper examines some of the major existing middlewares, describing design concepts, theirs capabilities and applications. Finally, some important criteria for choosing a middleware are listed in an attempt to increase the precision with which this choice is made. Keywords middleware, grid computing, software. Resumo. Este artigo analisa alguns dos principais sistemas de middleware existentes, descrevendo conceitos de projeto, funcionalidades disponíveis em cada um deles e aplicações. Por fim, alguns critérios importantes para a escolha de um middleware são elencados numa tentativa de aumentar o grau de precisão com que essa escolha é feita. Palavras-chave middleware, grades computacionais, software. 1. Introdução O middleware é um componente central da arquitetura de uma grade computacional, pois sua atribuição é ocultar tanto a natureza heterogênea do sistema - ou seja, oferecer uma visão de sistema único - quanto a complexidade decorrente da distribuição dos recursos que compõem a grade. Ele consiste de uma camada de software situada logicamente entre uma camada de nível mais alto, composta de usuários e aplicações, e uma camada subjacente que consiste em sistemas operacionais e facilidades básicas de comunicação. Alguns serviços tipicamente proporcionados pelo middleware são: identificação, autenticação, autorização, diretórios, certificados digitais e outras ferramentas para segurança. A Figura 1 mostra a localização lógica de um middleware perante todo o sistema de uma grade computacional.

2 Figura 1: A localização lógica do middleware. O restante do trabalho consiste num estudo comparativo entre alguns dos principais sistemas de middleware. 2. Sistemas de middleware para grades e clusters computacionais Nesta seção, alguns dos principais sistemas de middleware existentes serão apresentados. Os conceitos envolvidos nos projetos, bem como detalhes sobre funcionamento, disponibilidade e aplicações de cada sistema são descritos Legion O Legion foi desenvolvido na universidade da Virgínia e é um dos projetos pioneiros na sua área de atuação, pois começou em Analogamente ao paradigma de orientação a objetos, o Legion trata todos os recursos, sejam físicos ou lógicos, como objetos. A partir daí, ele possui todas as vantagens inerentes ao paradigma, tais como abstração de dados, encapsulamento, herança e polimorfismo. Essa característica simplifica a construção e a manipulação de ferramentas para visualização de resultados, monitoramento de carga ou migração de tarefas (GRIMSHAW et al., 1994). A comunicação entre os objetos é feita através de chamadas de métodos assíncronas e as interfaces são definidas por um tipo de IDL. As classes possuem responsabilidades de sistema como a criação de objetos, a ativação/desativação e o agendamento das execuções. Os principais recursos do sistema incluem: A eliminação da necessidade de transmitir e instalar manualmente os binários nas múltiplas plataformas. Depois de escalonar um conjunto de tarefas, o Legion transfere automaticamente os binários para cada host. Assim, os binários apropriados de uma única tarefa podem rodar automaticamente em arquiteturas diferentes. Um sistema de arquivos comum entre todos os hosts é criado. Isso possibilita que máquinas que não compartilhem sistemas de arquivos possam manipular os mesmos arquivos. Dessa forma, diferentes usuários

3 podem usar o sistema de arquivos virtual de modo colaborativo, compartilhando arquivos de dados e acessando os mesmos executáveis. E mais, dado que o Legion trata os recursos como um ambiente virtual simples, ele reduz drasticamente o overhead do compartilhamento de dados, a execução de aplicações e a utilização do poder computacional disponível (FALAVINHA JUNIOR, 2009). Mecanismos opcionais de privacidade e integridade para aplicações distribuídas que utilizam infraestruturas de redes públicas. O Legion se destaca ainda por possui nativamente implementações das bibliotecas MPI e PVM. Com isso, o sistema se torna mais confiável e facilita a migração de outros sistemas para ele. Além das bibliotecas, o Legion fornece suporte nativo a algumas linguagens de programação paralela. È possível utilizar as linguagens MPL (Mentat Programming Language, uma extensão de C++ para programação paralela), BFS (Basic Fortran Support) e Java. Por fim, aplicações legadas que não utilizem nenhuma das bibliotecas ou linguagens citadas podem ser encapsuladas dentro dos objetos do Legion. Isso é feito de modo muito simples, bastando apenas que o usuário registre o programa legado com um comando (legion_register_program) e o sistema constrói um objeto Legion que encapsula o programa legado tornando-o legível para o middleware. Com isso, tem-se a garantia de que qualquer programa pode ser executado neste ambiente. Mas, para o programa realizar tarefas de comunicação, o programador deve escrever uma interface para o programa legado que converta as chamadas à biblioteca de comunicação para as chamadas a métodos de comunicação do Legion. O Legion possui uma versão comercial chamada Avaki. Esse middleware é dividido em três camadas: Camada de protocolos de grades: estabelece serviços de segurança, nomeação e ligação entre os recursos. Camada de administração de sistema e serviços: oferece métodos para implementação de soluções distribuídas. Camada de aplicação: possui serviços de alto nível capazes de implementar o compartilhamento de arquivos, mecanismos colaborativos e aplicações de alto desempenho. Quando comparado ao Legion, o Avaki tem como grande diferencial os mecanismos para implementação e gerenciamento de uma grade de dados que consiste em um conjunto homogêneo de recursos para armazenamento e manipulação de arquivos que podem ser acessados independentemente da plataforma onde eles são armazenados e da localização física dessa plataforma Globus O Globus, idealizado por (FOSTER; KESSELMAN, 1997) e disponível em (GLOBUS PROJECT, 2009), fornece uma infraestrutura de software que permite a utilização de recursos computacionais distribuídos e heterogêneos como uma simples máquina virtual. Para isso, o sistema é construído como um conjunto de camadas em que

4 serviços globais de alto nível são concebidos e implementados através de serviços locais de baixo nível (FALAVINHA JUNIOR, 2009). O elemento central do projeto Globus é o Globus Toolkit, um conjunto de ferramentas que define e implementa os serviços básicos para construir uma grade, como segurança, locação e gerenciamento de recursos e comunicações. A seguir, essas ferramentas são detalhadas. As diferentes informações necessárias para gerenciar os recursos físicos e lógicos da grade são manipuladas por um conjunto chamado de serviços de informação, cujos elementos são o MDS, o Trigger e o Index. O Monitoring and Discovery Service (MDS) permite a publicação e a consulta de informações sobre a disponibilidade de recursos na grade. O Trigger é um serviço que coleta dados de vários recursos e, quando certas regras definidas pelo administrador são validadas, dispara um gatilho que executa ações pré-definidas. O Index é um índice para concentrar um conjunto de informações sobre os recursos distribuídos. O gerenciamento de execução inclui tarefas como localizar, submeter, monitorar e cancelar processos e é efetuado pelo componente Grid Resource Allocation and Management (GRAM). Outro componente, chamado Dynamic Accounts, permite a um usuário, desde que ele tenha as devidas permissões, criar dinamicamente um espaço de trabalho em um recurso remoto. Assim como no caso das informações de gerenciamento, os dados também são manipulados por uma coleção de serviços. O GridFTP é acionado quando se deseja realizar a distribuição de arquivos para os nós da grade. O Replica Location Service permite, pelo mapeamento direto entre os nomes físicos e os lógicos, o registro e a recuperação de réplicas no sistema computacional. Seu objetivo é fornecer acesso robusto aos dados com alta disponibilidade mesmo em condições adversas. Com relação à segurança do sistema, o Globus Toolkit faz uso de uma série de padrões e protocolos já consagrados. Por exemplo, a identificação de usuários, serviços e recursos é baseada no padrão X.509; a comunicação segura é realizada através do protocolo SSL; e os serviços de autenticação, atributos e autorizações são feitos pela ferramenta OpenSAML. Há também o suporte à delegação, que permite a um usuário delegar alguns de seus direitos de acesso a certos recursos para outros usuários por um período determinado de tempo. Já o Community Authorization Service permite que o administrador de uma organização virtual gerencie coletivamente um grande conjunto de recursos e usuários especificando políticas de segurança e autorizações definidas no do padrão SAML (Simple Assertion Markup Language). Finalmente, uma série de bibliotecas de tempo de execução forma o Common Runtime, componente que auxilia no desenvolvimento da infraestrutura da grade e de aplicações nela executadas. A XIO é uma biblioteca extensível em C usada para a entrada e saída de dados, ela provê uma interface única que pode ser usada por diferentes protocolos, como TCP, UDP, HTTP, Telnet. Um conjunto de bibliotecas chamado de C Common Libraries provê uma camada de abstração unificada para estruturas de dados e para chamadas ao sistema operacional e à biblioteca padrão da linguagem C. Por último, outro conjunto de bibliotecas é usado para prover suporte aos protocolos de serviços Web usados pelo Globus nas linguagens C, Java e Python. Em sua versão 3.0 disponibilizada em 2003, o Globus ofereceu a arquitetura OGSA (Open Grid Services Architecture) que surgiu como uma iniciativa para associar

5 computação em grade e Web Services, facilitando, assim, a adoção de serviços da grade por usuários de Web Services. 2.3 Condor e Condor-G O Condor, idealizado por (LITZKOW et al., 1988) e disponível em (CONDOR PROJECT, 2009), surgiu da consonância dos projetos Crystal Multicomputer e Remote UNIX e é um sistema de gerenciamento de recursos especializado em tarefas de computação intensiva. Em contraste com o modelo de controle centralizado dominante, o Condor foi o único middleware que defendeu a ideia de que os participantes da grade são livres para contribuir com qualquer poder computacional, mesmo que mínimo (THAIN et al., 2004). A partir daí, o número de usuários do sistema cresceu, mas gerenciar a grande diversidade de arquiteturas de hardware e software se traduziu em um desafio para o middleware, que teve como única saída se tornar altamente flexível. A flexibilidade do sistema foi baseada em três preceitos: Não interferência na dinâmica de crescimento dos grupos de usuários: o sistema não deve estipular a maneira como seus usuários interagem entre si, ou seja, ele deve permitir, mas não obrigar que haja cooperação. Manter o proprietário no controle: é evidente que os usuários somente disponibilizarão seus recursos para o bem comum se eles mantiverem algum controle sobre como esses recursos serão utilizados. Por isso, deve-se ter o cuidado de fornecer ferramentas para o proprietário de um recurso definir políticas de uso e bloqueio de seus recursos. Planejamento sem exigências: num sistema relativamente grande, sempre haverá recursos disponíveis para executar uma tarefa, entretanto, também existirão os recursos lentos, mal-configurados ou desligados e tentar exigir a não ocorrência desse fato prejudicial é perda de tempo. Quando as falhas ocorrerem, o sistema deve estar preparado para refazer ou reatribuir o trabalho da melhor maneira possível. Seguindo esses preceitos, o Condor procura alcançar os seguintes objetivos: Fornecer grandes quantidades de poder computacional tolerante a falhas durante períodos prolongados de tempo, utilizando eficazmente todos os recursos disponíveis para a rede. Utilizar os recursos sempre que eles estiverem disponíveis. Para isso, o sistema implementa mecanismos para gerenciamento de tarefas, definição de políticas de escalonamento, esquemas de prioridades, monitoramento e gerenciamento de recursos. Assim, quando os usuários submetem seus trabalhos para o Condor, este escolhe (baseado em alguma política) quando e onde executar os trabalhos, monitora o progresso e finalmente informa o término do trabalho ao usuário (FALAVINHA JUNIOR, 2009). como: Para executar suas funções, o Condor faz uso de algumas ferramentas, tais ClassAd: a linguagem ClassAd oferece uma grande flexibilidade e um considerável framework para solicitações de recursos lógicos ou físicos.

6 Além disso, ela permite que o middleware adote praticamente qualquer abordagem de planejamento na incorporação de recursos da grade. Checkpoint e migração de tarefas: de modo transparente ao usuário, o sistema pode, com alguns tipos de tarefas, gravar um checkpoint e, posteriormente, retomar a aplicação desse arquivo. Com isso, é possível implementar uma forma de tolerância a falhas e garantir o tempo de computação de um trabalho. A verificação também permite a migração de trabalhos de uma máquina para outra. Sistema de chamadas remotas: se desejado, é possível fazer com que o middleware, através de chamadas ao sistema remoto, preserve o ambiente local de tarefas executadas remotamente e também que ele redirecione os trabalhos de entrada e saída de volta para a máquina de origem do trabalho. Dessa forma, não é preciso que os usuários disponibilizem os arquivos de dados para as estações de trabalho remotas antes do Condor executar os seus programas lá, mesmo na ausência de um sistema de arquivos compartilhados. O Condor-G (FREY et al., 2002) representa o casamento das tecnologias dos projetos Globus e Condor. Do Globus são utilizados os protocolos para comunicação segura e acesso padronizado para uma variedade de sistemas remotos. Do Condor são utilizados os conceitos de submissão e alocação de trabalhos, recuperação de erros e criação de um ambiente de execução amigável. O resultado é muito benéfico para o usuário que pode utilizar grandes conjuntos de recursos distribuídos sobre múltiplos domínios administrativos como se todos esses recursos fossem locais (FALAVINHA JUNIOR, 2009) InterGrade O Projeto InteGrade (INTEGRADE PROJECT, 2010) é uma iniciativa de algumas universidades brasileiras e visa desenvolver um middleware para computação oportunista, isto é, que permita a utilização de recursos computacionais ociosos em aplicações que demandem alto poder de processamento, principalmente aquelas onde haja um nível bastante significativo de comunicação entre os nós. Entretanto, isso deve ser feito priorizando-se os usuários locais de cada aglomerado. A versão atual do sistema conta com cerca de 30 mil linhas de código-fonte e pretende ser multi-plataforma, incluindo versões para Linux, Windows e MacOSX. Os serviços administrativos executados nos nós de gerenciamento da grade são escritos na linguagem Java, devido ao grau de portabilidade da linguagem. Já os componentes executados nas máquinas dos usuários que compartilham seus recursos com a grade são implementados nas linguagens C e Lua de forma a minimizar o consumo de memória e processador, não prejudicando a qualidade de serviço desses usuários. Já o padrão CORBA foi utilizado para realizar a comunicação entre os nós da grade e os serviços são acessados através de interfaces definidas em IDL (Interface Definition Language). Mas, nas máquinas dos usuários e nos nós provedores de recursos, utiliza-se OiL (ORB in Lua), pois este padrão apresenta um menor consumo de memória.

7 Os principais componentes do InteGrade são: Application Submission and Control Tool (ASCT): permite aos usuários realizarem requisições, controle e visualização de resultados de suas aplicações. Esta ferramenta pode ser executada em qualquer máquina, mesmo que ela não compartilhe recursos com a grade. Uma opção à ferramenta ACST é o portal Web do InteGrade que oferece a vantagem do acesso remoto aos usuários. Global Resource Manager (GRM): é o módulo responsável pelo gerenciamento dos recursos de um aglomerado, pela interação com outros aglomerados e pelo escalonamento da execução de aplicações. Local Resource Manager (LRM): gerencia os recursos de uma única máquina. Execution Manager (EM): é responsável por gerenciar os checkpoints das aplicações e acompanhar a execução de todas as tarefas das aplicações em execução em um dos clusters. O LRM e o GRM informam o EM quando aplicações iniciam e terminam a sua execução e o EM coordena o processo de reinicialização de tarefas que estavam executando em nós que falharam ou se tornaram indisponíveis. O GRM mantém uma lista dos LRMs ativos e, ao receber requisições para execução de aplicações, escolhe um LRM que atende, naquele momento, às necessidades da aplicação. Para tal, assim que um LRM é inicializado, ele localiza o GRM da máquina e se registra, enviando informações - como, por exemplo, velocidade do processador, quantidade de memória RAM e sistema operacional - sobre características e recursos oferecidos na máquina em que reside. Além disso, o LRM envia a quantidade de recursos disponíveis para utilização em sua máquina, periodicamente ao GRM. O LRM recebe requisições de execução do GRM e determina se estas requisições podem ser aceitas. Em caso afirmativo, um novo processo é criado para realizar a execução. Caso contrário, o LRM notifica o GRM que a execução não pode ser realizada. Quando a execução de um processo termina, o LRM avisa o EM sobre o fim desta execução, que por sua vez, avisa o ASCT ou o portal Web. O usuário então pode solicitar, quando desejar, os arquivos de saída de sua aplicação. Application Repository (AR): armazena, de forma segura, os executáveis de aplicações submetidas à grade. Estes executáveis são enviados pelo ASCT/portal Web ao AR de modo a serem posteriormente utilizados pelos LRMs. O AR também pode armazenar os dados de entrada e saída das aplicações. Local Usage Pattern Analyzer (LUPA) e Global Usage Pattern Analyzer (GUPA): ainda estão em desenvolvimento, mas o GUPA tem como objetivo analisar o padrão de utilização das máquinas dos aglomerados. Já o LUPA é executado juntamente com o LRM nos nós provedores de recursos, coletando dados da máquina e analisando seu padrão de uso. Esta informação é disponibilizada ao GRM e, futuramente, permitirá um escalonamento mais eficiente das aplicações. A versão mais recente do InteGrade provê suporte a execução de aplicações paramétricas (bag of tasks), MPI e BSP.

8 2.5. OurGrid O OurGrid (Andrade et al., 2003) é um projeto coordenado por pesquisadores da Universidade Federal de Campina Grande. Ele oferece um middleware Java para a execução de aplicações sequenciais e do tipo bag of tasks. Devido ao grande esforço despendido na instalação e na configuração dos principais sistemas de middleware disponíveis, a ideia central do projeto OurGrid é criar um ambiente de fácil instalação e configuração. Para tanto, desenvolveu-se um mecanismo simples de integração de recursos através de uma rede peer-to-peer e o compartilhamento desses recursos é baseado no conceito de rede de favores que determina que a prioridade de um usuário no uso dos recursos é dada pela razão entre a quantidade de recursos oferecidos por ele à grade e a quantidade de recursos utilizados por ele. Aqui é possível traçar um paralelo com um dos preceitos do projeto Condor, já que este último estimulava, ao contrário do OurGrid, a utilização da infraestrutura computacional por todos os usuários, independentemente da quantidade de recursos disponibilizados à grade por eles. Para proteger os recursos locais de aplicações maliciosas, o OurGrid utiliza a máquina virtual Xen. Atualmente, o middleware não oferece suporte nem à privacidade nem à criptografia dos dados. O OurGrid não possui um escalonador global que tenha uma visão abrangente da utilização de recursos na grade. Os usuários interagem com a grade através de um agente pessoal chamado MyGrid que é responsável pelo escalonamento das aplicações e provê a transparência do sistema. Para compensar o fato de que é difícil prever a confiabilidade dos nós de computação do OurGrid, O MyGrid utiliza-se da execução replicada da aplicação em mais de um nó. A falta de um escalonador com uma visão abrangente das aplicações em execução no sistema faz com que os escalonadores pessoais compitam entre si, e assim pode haver desperdício na utilização dos recursos. Finalmente, a versão mais recente do escalonador utiliza o conceito de afinidade de armazenamento para executar as tarefas em nós mais próximos de onde os seus dados de entrada estão armazenados, otimizando assim o seu tempo total de execução e a latência percebida pelo usuário. 2.6 Microsoft Windows HPC Server 2008 O Microsoft Windows HPC Server 2008 (HPCS) (MICROSOFT, 2008) é um ambiente completo e integrado para clusters computacionais que inclui um sistema operacional (Windows Server 2008), um escalonador de tarefas, suporte à biblioteca MPIv2 e componentes para gerenciamento e monitoração do sistema. O escalonador de tarefas é flexível e capaz de interoperar com aplicações Linux. Além disso, outros produtos de software Microsoft, como o Windows PowerShell, podem ser integrados ao HPCS. Ao desenvolver o Windows HPC Server 2008, a Microsoft se concentrou em quatro áreas principais: sistema de gerenciamento, escalonamento de tarefas, rede de comunicação/mpi e armazenamento. A primeira atribuição do sistema de gerenciamento é fornecer uma interface com o usuário que, graficamente, é baseada na solução System Center e, na interface em linha de comando, no PowerShell. Através do sistema de gerenciamento também é possível direcionar a alocação de lotes de tarefas a determinados nós do cluster. Mas o

9 aspecto mais interessante é o subsistema de diagnósticos e relatórios que conta, inclusive, com mapas de calor para monitoramento da temperatura do hardware. Enquanto isso, o escalonador de tarefas enfileira as tarefas, aloca os recursos necessários para executá-las e as inicia. A partir daí, monitora o status tanto dos recursos quanto das tarefas. Para escalonar as tarefas, existem cinco políticas possíveis: alocação específica de recursos, acesso às tarefas através de templates, alocação de processador multi-nível, alocação adaptativa (sob demanda) e preempção. Em relação à rede de comunicação, o HPCS suporta quatro diferentes topologias de rede. As quatro topologias, por sua vez, permitem que cada nó do cluster tenha entre uma e três placas de rede. Para o armazenamento e compartilhamento de dados entres os nós, o HPCS utiliza o protocolo SMB (Server Message Block) já implementado no Windows Server O SMB é um protocolo de camada de aplicação que estabelece políticas para o acesso aos arquivos, impressoras e portas seriais compartilhados. Ele fornece também um mecanismo de autenticação através de comunicação inter-processos. O HPCS também possui suporte ao barramento iscsi, amplamente utilizado em redes locais de armazenamento (SAN). A segurança do ambiente está baseada em políticas como proibir que o escalonador submeta tarefas de computação utilizando as credenciais de administrador do sistema. Além disso, todas as credenciais de usuário são criptografadas e são armazenadas somente até a conclusão do trabalho. Esse comportamento permite que os nós escravos acessem os recursos de rede, como servidores de arquivos ou banco de dados, apenas durante o tempo estritamente necessário e que seja possível auditar esses acessos. Adicionalmente a isso, o mecanismo para gerenciamento de tarefas é feito através de canais criptografados e autenticados e as credenciais do usuário são conhecidas apenas pelo escalonador e pelo processo em questão, esse isolamento tem a função de manter a integridade do sistema. No nível do sistema operacional, o HPCS herda os mecanismos de segurança adicionais do Windows Server 2008, tais como gerenciamento de funções, política de gestão da rede, e um sistema integrado de firewall bidirecional. Outra característica importante de segurança e estabilidade é o gerenciamento de patches integrado construído em 2008 para HPC Pack. Isso permite que o administrador agende atualizações de grupos de nós do cluster com a garantia de que elas não irão interferir no funcionamento dos processos em execução. 3. Conclusões O middleware é um componente essencial para uma grade computacional executar as tarefas de modo eficiente, pois a transparência proporcionada por ele permite que o usuário se preocupe apenas em colher os resultados de sua tarefa e não com questões secundárias. Os sistemas de middleware comparados são bastante robustos. A modularização das funcionalidades é uma característica comum a todos eles, e as peculiaridades, basicamente, se concentram na maneira de implementação delas, sendo que alguns fazem suas próprias versões dos serviços - por exemplo, de identificação, autenticação

10 ou autorização e outros, como o InteGrade que usa o CORBA para a comunicação dos nós, utilizam versões já consagradas. Cabe ao administrador da grade computacional conhecer as necessidades de seus usuários para concluir, com maior precisão, qual desses sistemas se adéqua melhor ao seu caso. Entretanto, alguns fatores que ele deve levar em consideração são quantidade e qualidade da documentação presente na literatura, critério no qual o Globus leva alguma vantagem sobre os demais; possibilidade de suporte por uma equipe especializada, benefício oferecido pelo Microsoft Windows HPC Server 2008; custo, sendo que o baixo custo de adoção é característica de todos os sistemas apresentados, exceto do Microsoft Windows HPC Server 2008; e facilidade de uso, fator preponderante no OurGrid. 4. Referências Bibliográficas ANDRADE, N. et al. OurGrid: an approch to easily assemble grids with equitable resourde sharing. In: WORKSHOP ON JOB SCHEDULING STRATEGIES FOR PARALLEL PROCESSING, 9, Seattle. CONDOR PROJECT. Condor website Disponível em Acesso em 16/06/2010 FALAVINHA JUNIOR, J. N., Escalonamento de tarefas em sistemas distribuídos baseado no conceito de propriedade distribuída. Tese (Doutorado em Engenharia Elétrica) Faculdade de Engenharia de Ilha Solteira - UNESP, FREY, J. et al. Condor-G: a computation management agent for multi-institutional grids. Cluster Computing, v. 5, p Disponível em: Acesso em 16/06/2010. FOSTER, I., KESSELMAN, C. Globus: a metacomputing infrastructure toolkit. Internacional Journal of Supercomputer Applications, Cambridge, v. 11, p , 1997 GLOBUS PROJECT. Globus project website. Disponível em: Acesso em: 15/06/2010 GRIMSHAW, A. et al. A synopsis of the Legion project. Virginia: University of Virginia in Charlottesville, 1994 (Technical Report) INTEGRADE PROJECT. InteGrade project website. Disponível em: Acesso em: 17/06/2010 LITZKOW, M. et al. Condor - a Hunter of Idle Workstations Disponível em: Acesso em 16/06/2010 MICROSOFT. Technical Overview of Windows HPC Server Disponível em: 0ed1888a9093/Windows%20HPC%20Server%202008%20Technical%20Overview. doc. Acesso em: 18/06/2010 THAIN, D. et al. Distributed computing in practice: the Condor experience Disponível em: Acesso 16/06/2010