Comparação de ferramentas Grid tipo Desktop Computing Boinc, XtremWeb e Condor

Transcrição

1 Comparação de ferramentas Grid tipo Desktop Computing Boinc, XtremWeb e Condor Resumo Almir Jose da Cruz Universidade Federal do Rio Grande do Sul (UFRGS) Porto Alegre RS Brasil almircruz@ig.com.br Este artigo apresenta uma comparação entre ferramentas Grid tipo Desktop Computing. Acreditase que esta comparação possa fornecer subsídios no surgimento de novos conceitos através da identificação das vantagens e desvantagens de algumas plataformas, em relação às necessidades mais freqüentes e dos recursos freqüentes disponíveis. 1 Introdução Um grid computacional pressupõe uma infraestrutura de acesso aos recursos. Entretanto, criar um grid computacional é mais do que instalar um middleware nos recursos que serão disponibilizados. Mesmo que a infra-estrutura para a utilização dos recursos esteja disponível, os usuários ainda precisam ter acesso a esses recursos. Para obter esse acesso em um sistema tradicional, como uma rede local ou um supercomputador, um usuário negocia com seu dono o direito de acesso ao recurso. O administrador do sistema ao qual o recurso pertence configura então para cada um dos usuários ao qual foi concedido o acesso um conjunto de permissões e prioridades. Em um grid, dada suas características inerentes, essa abordagem não é suficiente. Em um grid tanto o conjunto de serviços quanto o conjunto de usuários é muito grande, dinâmico e heterogêneo. Além disso, um grid é potencialmente formado por participantes mutuamente nãoconfiáveis e desconhecidos. Do ponto de vista do usuário, é muito difícil, em um cenário como esse, conseguir acesso a mais que um pequeno conjunto de serviços cujos proprietários são conhecidos. A computação em grid, entretanto, pretende viabilizar a utilização de grandes quantidades de recursos heterogêneos e amplamente distribuídos. Dar aos usuários a possibilidade de acesso apenas a uma pequena quantidade de recursos é sub-utilizar o potencial dessa tecnologia. Na perspectiva oposta, a participação dos provedores de serviços no grid é voluntária. São necessários estímulos para que o acesso destes seja permitido à comunidade de usuários. É preciso que exista alguma espécie de retorno a fim de tornar interessante para os provedores compartilhar seus recursos. Os mecanismos de retorno existentes nos sistemas grid hoje são negociações por garantias estáticas de acesso a recursos quando da configuração da infra-estrutura do grid. 2 Características A abordagem de ferramentas Grid é atraente para aplicações onde uma tarefa computacionalmente onerosa possa ser dividida em múltiplas sub-tarefas praticamente independentes, que possam ser executadas por diferentes computadores (peers) interligados. Todavia, a escolha da plataforma deve levar em consideração algumas necessidades freqüentes: 1.Para algumas aplicações, existe a necessidade de um elemento central, o qual se responsabiliza por armazenar as informações necessárias para a execução das tarefas. Para resolver esse problema, alguns sistemas adotam uma abordagem P2P híbrida, que alia as características de computação P2P ao modelo cliente-servidor. 2.Há aplicações que necessitam resolver dependências de dados em algum ponto da computação, devendo assim haver comunicação entre peers. Para isso é desejável que os peers possam trocar mensagens entre si. 3.Quando se utiliza a plataforma para computação colaborativa, isto é, para permitir que computadores voluntários colaborem na resolução de um problema, é importante prover segurança aos participantes. 4.É possível que os usuários dessas plataformas não sejam especialistas em computação e sim cientistas, como físicos, matemáticos, biólogos, entre outros. Portanto, é importante que o sistema seja fácil de instalar e de utilizar. Além destas necessidades, é importante levar em consideração os recursos freqüentemente disponíveis: 1.Nem sempre há a disponibilidade de um ambiente computacional dedicado para computação paralela e distribuída. Neste caso, pode-se fazer uso compartilhado de redes de computadores. Por isso, a 1

2 plataforma deve poder trabalhar com a dinamicidade de ambientes como esse. 2.Também em ambientes compartilhados, pode ser necessário trabalhar apenas com períodos de ociosidade computacional, de modo a n.ao concorrer por recursos, com as aplicações de usuários. 3.É comum a utilização de ferramentas para o gerenciamento de recursos, como por exemplo Condor. Portanto, é geralmente desejável que o sistema de computação P2P seja capaz de interoperar com estas e outras ferramentas que eventualmente possam estar em funcionamento no ambiente utilizado. 4.O ambiente computacional existente pode possuir diferentes configurações de hardware e software. Portanto, o sistema para computação P2P também deve ser capaz de operar em sistemas heterogêneos. 3 Boinc BOINC (Berkeley Open Infrastructure for Network Computing) é uma plataforma para computação distribuída que permite utilizar recursos públicos. BOINC foi desenvolvido pelo Laboratório de Ciências Espaciais de Berkeley, mesmo grupo desenvolveu e continua a operar o projeto SETI@home. BOINC tem como principal objetivo avançar o paradigma de computação que utiliza recursos públicos, e encorajar uma boa parte dos usuários de computador do mundo a disponibilizar o tempo ocioso de seus computadores para um ou mais projetos de pesquisa. BOINC possui uma arquitetura cliente-servidor. O servidor é centrado em um banco de dados relacional, tipicamente MySQL, o qual armazena a descrição das aplicações e todas as informações necessárias para o seu funcionamento. As funções do servidor são executadas por um conjunto de web services e processos daemons, que juntos realizam o escalonamento de tarefas, atendimento aos clientes via RPC (Chamada de Procedimento Remoto), carga de arquivos e recebimento dos resultados final da computação. Já os clientes são responsáveis por executar a aplicação no computador voluntário, quando o mesmo estiver ocioso. Para garantir a validade dos resultados, normalmente o servidor escalona várias unidades de trabalho e depois compara as várias respostas considerando a moda como resultado final. Com a resposta escolhida, o servidor remove do banco de dados a unidade de trabalho terminada, eliminando também as redundâncias de dados. A geração de unidades de trabalho fica sob responsabilidade do desenvolvedor de aplicações. Para isso, BOINC oferece uma API para criação de unidades de trabalho no banco de dados. É importante mencionar que BOINC não possui suporte para comunicação entre clientes. 3.1 Escalonamento de tarefas A política de escalonamento FIFO com prioridades. O BOINC gerencia a maior parte das tarefas de redundância, embora a aplicação deva se envolver com os processos de validação e assimilação. Validação acontece quando um número suficiente de respostas chega ao servidor (foi alcançado um número mínimo de respostas, considerado como quorum mínimo) e deve ser avaliado se existe consenso. O método de comparar resultados e a política para determinar se há ou não consenso deve ser fornecido pela aplicação no servidor. Assimilação é o mecanismo no qual o projeto é notificado do término, com sucesso ou não, de uma unidade de trabalho. Quando é obtido consenso, os resultados são enviados para processamento complementar pela aplicação no servidor. Se a unidade de trabalho não conseguir ser executada com sucesso, por exemplo, por não haver quorum ou não ter sido obtido consenso, a aplicação no servidor é acionada para determinar ações alternativas. Como a disponibilidade das máquinas é dinâmica e pode variar sem aviso prévio, BOINC fornece uma API para checkpointing, a qual permite que o estado de execução da aplicação seja salvo e retomado posteriormente. A aplicação deve estar ciente dos momentos de checkpointing, ou seja, ela deve indicar explicitamente os pontos no qual o estado de execução deva ser salvo, se possível. Também é responsabilidade da aplicação decidir o que deve ser salvo para posteriormente retomar a computação. BOINC já possui um mecanismo que submete um número de tarefas baseado na quantidade de unidades de processamento disponíveis em cada recurso escravo, buscando utilizar desta forma toda a capacidade de processamento disponível nos hosts. Sendo assim, o BOINC é capaz de se adaptar nas diversas configurações de máquinas, quando considerado a heterogeneidade do número de unidades de processamento das mesmas. Em todo o momento as tarefas são iniciadas no cliente. Isto evita complicações com roteadores e firewall na liberação de portas de acesso. O cliente solicita ao servidor instruções sobre tarefas a executar, logo após, o servidor envia as instruções necessárias para execução, tais como: porta, servidor destino dos resultados e outros. Como mostra na figura

3 Figura 3.1 : Escalonamento de tarefas 3.2 Segurança As questões de segurança, uma vez que vários projetos podem estar executando na mesma máquina, merecem atenção. Para impedir falsificação de resultados, o BOINC utiliza redundância para diminuir a chance de ocorrências. Cada unidade de trabalho é distribuída para múltiplos clientes, os resultados gerados por eles são comparados e são aceitos apenas aqueles nos quais o consenso é obtido. Eventualmente, novos clientes são acionados para executar as mesmas computações, quando não for alcançado o consenso com as computações que tenham chegado ao servidor. Para eliminar distribuição forjada de aplicações ou a possibilidade de um cracker distribuir um código cliente falso (um vírus) no lugar de código valido, o BOINC utiliza assinatura de código. Cada projeto possui um par de chaves criptográficas que são utilizadas para autenticar os programas que distribui. 4 XTremWeb O XtremWeb é uma ferramenta que visa facilitar a programação de algoritmos para grades computacionais. De forma muito simplificada, ele possui dois módulos: os workers, instalados em cada um dos nós de computação (heterogêneos), responsáveis por executar as tarefas (ou jobs), e o server, responsável por gerenciar as tarefas, escaloná-las para os workers e recolher os resultados. Um módulo adicional, client, é responsável por receber as chamadas da linha de comando e enviá-las para o server. Entre as facilidades providas pelo cliente, as principais são: 1.Registro de uma aplicação: Uma aplicação é um arquivo binário executável que executa uma job. Diversas jobs podem usar a mesma aplicação, passando diferentes parâmetros para cada instância. 2. Submissão de jobs: Enviar uma tarefa para o servidor, que irá escaloná-la aos clientes. Vale destacar que a chamada é assíncrona, ou seja, o cliente não espera a resposta. 3. Verificação de status: Para saber se determinada job já concluiu, ainda está na fila, ou está rodando. 4. Obtenção de Resultado: Fazer o download do resultado de uma job. O resultado é um arquivo correspondendo a cada saída do executável (stdout e stderr). O XtremWeb, entretanto, não realiza a divisão das tarefas em jobs automaticamente. Além disso, a reunião dos resultados intermediários em um resultado único também não é realizada pela ferramenta. É principalmente nesses dois pontos que será preciso desenvolver código para implementar o algoritmo distribuído. 4.1 Escalonamento de tarefas O escalonador gerencia a factory de serviços através da criação de instâncias e aplicações nos workers e gerencia o ciclo de vida. O escalonador implementa o modelo "pull" para alocação das tarefas. Isso significa que as tarefas são alocadas nos workers por demanda, de acordo com a iniciativa dos workers. Após o processamento da atividade ou tarefa proposta, os workers enviam o resultado processado, que são, por fim, depositados no terceiro serviço oferecido pelos coordenadores: o depósito de resultados. O coordenador aceita a requisição de tarefas de diversos clientes e as distribui, de acordo com a política de escalonamento, transferindo o código da aplicação (se necessário), supervisionando a execução das tarefas, monitorando erros ou desconexões por parte dos workers, reiniciando tarefas que foram interrompidas, coletando resultados de tarefas processadas pelos workers e oferecendo os resultados finais aos clientes. O coordenador não é, necessariamente, implementado por um nodo centralizado; ele pode ser baseado em uma solução de serviços distribuídos, instalados nos nodos participantes, juntamente com outros serviços. A arquitetura típica de um servidor da plataforma XtremWeb é composta por alguns componentes básicos. As seções seguintes apresentam esses componentes, detalhando suas funcionalidades e características. Através da figura 3

4 4.1, é possível identificar esses componentes, bem como a comunicação existente entre os mesmos. 1.Pool de Aplicações, XtremWeb foca em aplicações seqüenciais, com múltiplos parâmetros. A distribuição de uma aplicação consiste em prover, aos workers, os binários pré-compilados, de acordo com a plataforma do worker solicitante. Além disso, é necessária uma breve descrição da aplicação, uma definição de como os parâmetros devem ser interpretados e entendidos pelos workers além da especificação dos resultados que são esperados. Para toda esse armazenamento, além do controle de versão e upgrades das aplicações disponibilizadas, o pool de aplicações é utilizado. 2.Pool de Jobs, um cliente pode submeter uma tarefa para o XtremWeb através da disponibilização de uma referência à aplicação e um conjunto de parâmetros que caracteriza o job a ser executado. 4.1 Escalonamento de tarefas As tarefas do Condor são chamadas jobs. O usuário submete jobs para o Condor e ele decide quando e onde eles serão executados, seguindo o seguinte fluxo: - usuário submete o job para um agente (escalonador); - o job é armazenado em uma estrutura persistente enquanto o agente procura por recursos que possam executá-lo; - agentes e recursos utilizam um matchmaker para analisar a compatibilidade entre eles; - o agente contata o recurso para executar o job. Figura 4.2 : Arquitetura do Condor 4.2 Segurança Figura 4.1 : Escalonamento de tarefas O XtremWeb busca cumprir as atividades que lhe são propostas em um tempo aceitável. Em contraponto, é necessário também garantir aos participantes da grade segurança e confiabilidade na execução das tarefas. Para endereçar ambos requisitos, o XtremWeb _e escrito em Java que oferece a proteção e portabilidade da máquina virtual. Para cumprir com o objetivo de desenvolver as atividades com boa performance, todo o código final e as requisições de comunicações diretas com os sistemas operacionais são feitas de maneira nativa. Cada um dos jobs e máquinas possuem atributos para qualificá-los, que são chamados ClassAds (Classified Advertisements). Estes atributos definem os requisitos e as características de jobs e recursos. Eles são combinados e ordenados de forma a selecionar o recurso mais apropriado para executar o job. As aplicações Condor são definidas pelo submit description file, que é um arquivo texto com informações do job (código executável, arquivos de entrada e saída, parâmetros, requisitos, etc.). Este arquivo é passado para o comando condor_submit, que faz uma varredura e uma verificação de erros gerando um ClassAdd com a especificação do job. O ClassAdd e os executáveis são enviados ao condor_schedd, que os coloca em uma fila, aguardando o momento de execução. 5 Condor Condor é um sistema tipo high-throughput que realiza o gerenciamento de recursos e tarefas, utilizando uma política de escalonamento e monitoramento de recursos. 4

5 Também é possível descrever múltiplos jobs em um arquivo, neste caso ele é chamado de cluster. Cada job no cluster é chamado processo. No exemplo abaixo, em vez de submeter um único job, são enviados 600 jobs de uma única vez. Os arquivos de entrada e saída de cada processo estão localizados em diretórios distintos, no caso diretórios run_0 a run_599. Referências cessoemgrids/node6.html 5.2 Segurança O Condor é um sistema de gerenciamento de tarefas para computação intensiva. Este projeto evoluiu de forma que pode ser usado para construir uma infra-estrutura de grade, compartilhando recursos entre diferentes domínios administrativos. A solução de segurança no Condor incorpora: o gerenciamento das identidades dos participantes e a proteção dos recursos contra aplicações. O gerenciamento de identidades é realizado usando os mesmos protocolos utilizados pelo projeto Globus. Atualmente a segurança dos recursos é feita limitando o acesso remoto a uma conta de login restrita (uma modificação da conta padrão Unix, nobody). Em versões anteriores, as soluções de segurança do Condor incluíram o uso de chroot, uma técnica de isolamento que restringe a execução de processos em porções seguras do sistema de arquivos. Esta técnica é considerada ineficaz, pois existem vulnerabilidades conhecidas que permitem aos processos isolados escaparem da barreira de segurança. A utilização de mecanismo de sandbox oferece um lugar seguro para a aplicação rodar. 6 Conclusão Com o estudo realizado, foi possível identificar os mecanismos de comunicação utilizados entre os componentes, assim como foi possível determinar como o requisito segurança é contemplado. É preciso definir formas de estabelecer dinamicamente relações de confiança entre eles e dar aos provedores de recurso do grid alguma forma de retorno pelo acesso aos seus recursos. 6.1 Tabela de comparação Tabela de comparação das ferramentas Grid. 5

6 ITENS BOINC CONDOR XTREMWEB Aplicação Aplicações para computação Programas de computação Aplicações P2P distribuída pública intensiva Modelo de Aplicação Projetos submeter tarefas (mais que uma!) Escolha da melhor máquina Usuário submeter jobs (uma de cada vez!) Sistema Operacional Aaplicação cliente disponível para Microsoft Windows, OS Linux, Microsoft Windows, OS X, AIX Linux, Microsoft Windows, OS X X, Linux/x86,Solaris/SPARC Grade computacional oportunista Sim Sim (pioneiro) Indicado para sistemas de grades leves (LightWeight Grid Systems) Código aberto Sim Não Sim Binários gratuitos Sim Sim Sim* Implementação orientada a Sim Não Sim objetos Suporte a múltiplas Sim Sim Sim aplicações Suporte a comunicação Não Sim Não entre os peers Suporte a comunicação Sim Sim Sim entre os servidores Suporte a aplicações Não Sim Não paralelas (*) Interoperabilidade Não Sim Sim Escalonamento utiliza ciclos ociosos Utiliza ciclos ociosos Utiliza ciclos ociosos Arquitetura Centralizada Centralizada (Central Manager) Centralizada Tolerância a Falhas Suporta escalonadores separados e conta com um algorítimo inteligente para evitar que clientes sobrecarreguem o servidor após um down-time. Mecanismo de Segurança Uso de criptografia e a autenticações por chaves públicas. Checkpointing (condor libraries) Acesso remoto a uma conta de login restrita. Mecanismos baseados em logging que permitem recomeçar uma aplicação a partir do ponto onde ela foi interrompida. comunicassl (Secure Sockets Layer). Tabela 1: Tabela de comparação. 6