PROJETO DE PESQUISA: Infra-Estrutura de Software para Tolerância a Falhas de Aplicações no Middleware MAG (Mobile Agents for Grid Computing)

Transcrição

1 UNIVERSIDADE FEDERAL DO MARANHÃO CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICA DEPARTAMENTO DE INFORMÁTICA CURSO DE CIÊNCIA DA COMPUTAÇÃO PROJETO DE PESQUISA: Infra-Estrutura de Software para Tolerância a Falhas de Aplicações no Middleware MAG (Mobile Agents for Grid Computing) por DIEGO SOUZA GOMES Relatório Final de Bolsa de Iniciação Tecnológica e Industrial - ITI-CNPq Período: Março / Fevereiro Orientador: Prof. Dr. Francisco José da Silva e Silva São Luís, março de 2007.

2 2

3 Relatório Final de Bolsa de Iniciação Tecnológica e Industrial - ITI-CNPq Infra-Estrutura de Software para Tolerância a Falhas de Aplicações no Middleware MAG (Mobile Agents for Grid Computing) O presente relatório se destina à descrição do projeto, do desenvolvimento e dos resultados obtidos de uma infra-estrutura de software que permita a tolerância a falhas de aplicações para a plataforma de grade MAG, baseado em replicação de processos, salva de checkpoints e recuperação por reinício. GRANDE ÁREA DO CONHECIMENTO (CNPq): Ciências Exatas e da Terra ÁREA DO CONHECIMENTO (CNPq): Ciência da Computação SUB-ÁREA DO CONHECIMENTO (CNPq): Sistemas de Computação ESPECIALIDADE DO CONHECIMENTO (CNPq): Redes de Computadores e Sistemas Distribuídos Diego Souza Gomes Bolsista Prof. Dr. Francisco José da Silva e Silva Orientador

4 Sumário 1 Introdução 5 2 Procedimentos Metodológicos 5 3 Grades de Computadores Aplicações de Grades Taxonomia dos sistemas de Grade de computadores Visão Geral da Arquitetura do MAG Componentes da Arquitetura MAG-Integrade Execução de aplicações Mecanismo de Tolerância a Falhas Tratamento de Falhas de Execução em Grades de Computadores Tolerância a Falhas no MAG Replicação de Processos no Middleware MAG Detalhes de Implementação CrmAgent ErmAgent Protocolo de Execução de Aplicações com Réplicas Resultados Obtidos e Conclusões 17 4

5 1 Introdução Com a explosão da Internet e do crescente poder computacional de máquinas desktop durante a década de 90, muitos esforços foram empregados na criação de sistemas de Grades de computadores conectando PC s distribuídos através da rede mundial. Em um nível conceitual, Grades são um tipo de sistema paralelo e distribuído que possibilita interação, compartilhamento, seleção e agregação de recursos autônomos geograficamente distribuídos em tempo de execução, dependendo de sua disponibilidade, capacidade, desempenho, custo, e requisitos de qualidade de serviço de usuários, gerando um ambiente de compartilhamento de recursos computacionais dinâmicos e multiinstitucionais [BBL00]. Recursos típicos desse sistema podem incluir software, dados, supercomputadores, PC s, unidades de armazenamento de dados e equipamentos especializados como microscópios eletrônicos e telescópios de alta capacidade. Explorando a tecnologia de agentes móveis como uma forma de superar os desafios de construção de Grades computacionais, alunos e professores do Laboratório de Sistemas Distribuídos do Departamento de Informática da UFMA (DEINF/Universidade Federal do Maranhão) desenvolvem um middleware de grades chamado MAG (Mobile Agents for Grid Computing Environments)[Lop06, LSS05], cujo principal objetivo é disponibilizar uma infraestrutura de software livre baseada na tecnologia de agentes de software que permita a resolução de problemas computacionalmente intensivos em grades de computadores. A natureza dinâmica da infra-estrutura de grade, sua grande escalabilidade e heterogeneidade exarcebam a probabilidade de ocorrência de erros, impondo a tolerância a falhas como a maior necessidade um middlewares de grade. Desse modo, o objetivo específico deste trabalho de iniciação científica visa agregar à arquitetura do middleware MAG um mecanismo flexível de tolerância a falhas, através do qual os usuários possam optar entre um conjunto de técnicas fornecidas - (reinício da aplicação (sem checkpointing ou replicação), checkpointing sem replicação, replicação sem checkpointing e replicação com checkpointing), por aquela mais adequada a garantir que sua aplicações continuem rodando mesmo na presença de falhas.. Este relatório está organizado como descrito a seguir: a seção 2 discute sobre os procedimentos metodológicos adotados na pesquisa e desenvolvimento deste trabalho, a seção 3 apresenta sucintamente um estudo sobre a tecnologia de Grades de computadores, e a seção 4 descreve detalhamente o middleware MAG. A infra-estrutura desenvolvida por este trabalho será explicada na seção 5, e a seção 6 descreve os resultados obtidos e conclusões decorrentes deste trabalho. 2 Procedimentos Metodológicos No desenvolvimento da infraestrutura do mecanismo de replicação, foi utilizado como processo de desenvolvimento de software orientado a objetos o Processo Unificado com a adoção de diagramas UML. Foram desenvolvidos diagramas de classes e seqüência. Na concepção dos agentes do mecanismo de suporte ao mecanismo de replicação de processos foi utilizada a metodologia para o desenvolvimento de sistemas multiagentes Agil PASSI[CCSS04]. A Agil PASSI é uma adaptação da metodologia PASSI (Process for Agents Societies Specification and Implementation) [CSSC03] original. Ela foi concebida para permitir o desenvolvimento de sistemas multiagentes através de um processo 5

6 ágil[agi].este metodologia é composta fundamentalmente por 4 modelos: Requisitos: modelo dos requisitos envolvidos no desenvolvimento do sistema; Sociedade de agentes: uma visão dos agentes envolvidos na solução, suas interações e seu conhecimento sobre o sistema; Codificação: modelos que descrevem como o sistema deverá ser codificado; Testes: planejados antes da fase de codificação e executados logo após ela. Com relação aos testes dos mecanismos, foram feitas várias aplicações com o intuito de testar todos os requisitos apontados durante a modelagem dos requisitos. Foram utilizadas aplicações robustas que necessitavam de um número alto de arquivos de entrada e também geravam muitos arquivos de saída, cujo desempenho comprovaram o bom funcionamento do sistema. 3 Grades de Computadores A computação em grade permite a integração e o compartilhamento de computadores e recursos computacionais, como software, dados e periféricos, em redes corporativas e entre estas redes, estimulando a cooperação entre usuários e organizações, criando ambientes dinâmicos e multi-institucionais, fornecendo e utilizando recursos de forma a alcançar objetivos comuns e individuais [FKT01]. 3.1 Aplicações de Grades Através da infra-estrutura de grade é possível executar diversos tipos de aplicações, Ian Foster e Carl Kesselman [FK99] identificaram as cinco principais classes de aplicações para grades de computadores: Supercomputação distribuída: caracteriza-se por uma intensa necessidade de recursos de hardware como velocidade da CPU e memória. É representada por por aplicações que necessitam de computação intensiva problemas como, por exemplo, aplicações para planejamento e treinamento militar através de simulações interativas distribuídas e simulação precisa de processos físicos complexos (e.g. modelagem climática); Computação de alto rendimento: identifica-se pela necessidade de agregar recursos ociosos para aumentar a capacidade de processamento para execução de uma grande quantidade de tarefas independentes ou fracamente acopladas. Como exemplo desta classe de aplicações temos problemas de criptografia e de simulações moleculares; Computação sob demanda: caracteriza-se pela integração de recursos remotos em computações locais que são executadas muitas vezes por um período de tempo limitado. Problemas de instrumentação médica e processamento de imagens microscópicas exemplificam essa classe de aplicações; 6

7 Computação intensiva de dados: caracteriza-se pela síntese de novas informações de muitas ou grandes origens de dados. É representada pelos modernos sistemas meteorológicos ou sistemas cujo foco está na síntese de novas informações de dados que são mantidos em repositórios, bibliotecas digitais e banco de dados geograficamente distribuídos é um exemplo de grade de dados; Computação colaborativa: identifica-se pela necessidade de suporte a comunicação ou a trabalhos colaborativos entre vários participantes, como sistemas na área de educação e projetos colaborativos. 3.2 Taxonomia dos sistemas de Grade de computadores De acordo com a atividade principal a qual se destinam, Krauter et al. [KBM02] propõe a seguinte classificação: Grade computacional (Computing Grid): é um sistema de computação em grade que objetiva prover maior poder computacional através da combinação da capacidade computacional disponível de uma rede para execução de trabalhos que necessitam de computação intensiva, como aplicações que estão representadas nas classes de Supercomputação distribuída e Computação de alto rendimento; Grades de Dados (Data Grid): É um sistema de computação que objetiva prover mecanismos especializados para publicação, descoberta, acesso e classificação de grande volume de dados distribuídos, o que permite desenvolver uma infraestrutura capaz de sintetizar novas informações a partir de repositórios de dados. São utilizadas para resolverem problemas de Computação intensiva de dados; Grade de Serviços (Service Grid): provê serviços viabilizados pela integração de diversos recursos computacionais, o que acarreta em diminuição do tempo de atendimento aos clientes, em comparação aos sistemas onde os servidores trabalham independentemente entre si. São utilizadas para resolverem problemas de Computação sob demanda e Computação colaborativa; O MAG, middleware de grades ao qual este projeto se relaciona, é uma grade de aspectos mistos: possui tanto uma infraestrutura para manipular grandes volumes de dados e metadados, o MagCat [SSTF06], quanto é capaz de resolver problemas computacionalmente intensivos utilizando o poder computacional compartilhado pelos nós da grade, o que caracteriza uma grade computacional. 4 Visão Geral da Arquitetura do MAG O MAG é um subprojeto do projeto Integrade (descrito abaixo). Ele executa aplicações carregando dinamicamente seus códigos nos agentes móveis. O agente do MAG pode ser realocados dinamicamente entre nós da grade através de um mecanismo de migração transparente chamado MAG/Brakes, como uma forma de prover suporte a nós não dedicados. O MAG inclui mecanismos de tolerância a falhas de aplicações e grade de dados. O paradigma de agentes foi extensivamente utilizado para projetar e implementar os componentes do MAG, formando uma infraestrutura multiagente para grades computacionais. 7

8 As características da tecnologia de agentes móveis que mais contribuíram para o desenvolvimento da infra-estrutura da grade são: Cooperação: agentes têm a habilidade de interagir e cooperar com outros agentes. Isto pode ser explorado para o desenvolvimento de mecanismos de comunicação complexos entre os nós da grade; Autonomia: agentes são entidades autônomas, significando que suas execuções ocorrem sem nenhuma, ou com muito pouca intervenção dos clientes que os iniciaram. Este é um modelo adequado para a submissão e a execução de aplicações na grade; Heterogeneidade: muitas plataformas de agentes móveis podem ser executadas em ambientes heterogêneos, uma característica importante para um melhor uso dos recursos computacionais entre ambientes multi-institucionais; Reatividade: agentes podem reagir a eventos externos, como variações na disponibilidade de recursos; Mobilidade: agentes móveis podem migrar de um nó para outro,movendo parte da computação sendo executada de forma a prover balanceamento de carga entre os nós da grade e suporte a nós não dedicados. A arquitetura do MAG está organizada na forma de uma pilha de camadas, conforme pode ser visto na Figura 1. Figura 1: Arquitetura em camadas do middleware MAG A camada superior representa as duas classes distintas de aplicações - regulares e paramétricas - que podem ser executadas atualmente no MAG. As aplicações regulares são aplicações seqüenciais compostas por um único binário que executa em uma só máquina. Já as aplicações paramétricas são aquelas que executam múltiplas cópias do mesmo binário em máquinas distintas e com entradas diferentes. Nesta classe de aplicações (também, chamada de BoT ou Bag-of-Tasks) as tarefas são divididas em sub-tarefas menores que executam de forma independente, sem haver comunicação entre elas. Várias aplicações enquadram-se nesta categoria, como as de processamento de imagens, simulação e mineração de dados. A camada JADE (Java Agent Development Framework) [JAD] representa o arcabouço utilizado para a construção de sistemas multiagentes adotado no MAG. Este arcabouço provê ao MAG várias funcionalidades como facilidades de comunicação, controle do ciclo de vida e monitoração da execução dos agentes móveis. O JADE é uma plataforma 8

9 portável (pois foi desenvolvida com tecnologia Java) e aderente à especificação FIPA [FIP]. As camadas superiores utilizam a tecnologia de objetos distribuídos CORBA para promover a comunicação entre seus componentes. Além disso, esta tecnologia fornece diversos serviços que podem ser utilizados pela infraestrutura do MAG, como serviço de nome e serviço de trading. O Integrade [GKG + 04, INT] é um middleware de grade cujo desenvolvimento envolve um conjunto de universidades brasileiras (USP, Puc-Rio, UFMS, UFG e UFMA), coordenadas pelo Instituto de Matemática e Estatística da Universidade de São Paulo (IME/USP). O MAG utiliza o Integrade como fundação para sua implementação, evitando assim a duplicação de esforços no desenvolvimento de uma série de componentes, além disto, também adiciona ao Integrade um novo mecanismo de execução de aplicações, através do uso da tecnologia de agentes móveis, para permitir a execução de aplicações Java, não suportadas nativamente pelo Integrade. Os componentes principais da arquitetura do Integrade e os componentes da arquitetura do MAG relacionados à execução de aplicações será discutido em detalhes na seção Componentes da Arquitetura MAG-Integrade O Integrade é estruturado em aglomerados organizados de uma forma hierárquica 2. Um aglomerado é definido como uma unidade autônoma dentro da grade, uma vez que o mesmo contém todos os componentes necessários para funcionar independentemente. Figura 2: Arquitetura de um aglomerado Integrade OBS: Somente os componentes que estão relacionados ao nosso trabalho estão representados neste diagrama. Outros componentes relacionados à utilização de recursos ociosos de máquinas não dedicadas são encontrados na arquitetura do Nó Compartilhado, o que o difere do Nó Dedicado Os componentes da arquitetura do Integrade relacionados a execução de aplicações e que por isso estão relacionados ao nosso trabalho são: Application Submission and Control Tool ou ASCT: é a interface gráfica que permite aos usuários da grade, submeter aplicações para serem executadas na grade. Através dele também é possível acompanhar o estado das aplicações submetidas à grade. Application Repository ou ASCT: armazena as aplicações a serem executadas na grade, sendo chamado durante a execução de uma aplicação para recuperar o seu código executável. 9

10 Local Resource Manager ou LRM: é o componente que executa em cada nó do aglomerado, coletando informações sobre o estado dos recursos dos nós da grade como memória CPU, disco e utilização da rede. Ele é também responsável por instanciar aplicações escalonadas ao nó. Global Resource Manager ou GRM: gerencia os recursos do aglomerado, recebendo notificações de utilização de recursos a partir dos LRMs e executando o escalonador que aloca tarefas aos nó, de acordo com a disponibilidade de seus recursos. Para permitir a execução de aplicações Java através da tecnologia de agentes de software, o MAG adiciona trás novos componentes à arquitetura original do Integrade: MagAgent: é um agente móvel responsável por executar aplicações na grade. Em resposta a cada solicitação de execução de aplicação, um novo MagAgent é criado. Ele atua como um wrapper da aplicação, sendo responsável por: baixar o bytecode das aplicações a partir do repositório de aplicações; dinamicamente instanciar e executar a aplicação utilizando mecanismos de reflexão computacional fornecidos pela plataforma Java; capturar qualquer exceção não capturada pela aplicação; e capturar e salvar periodicamente o estado de execução da aplicação (checkpoint), de forma a permitir sua posterior recuperação caso uma falha ocorra. AgentHandler: somente uma instância deste componente executa em cada nó da grade que fornece recursos para a execução de aplicações. Ele mantém o container de agentes executando no nó e também, é responsável por criar MagAgents ao receber requisições de execução. Este componente torna o paradigma de agentes de software transparente ao Integrade. ExecutionManagementAgent ou EMA: mantem todas as informações sobre cada execução de uma aplicação em um repositório de dados. Os dados armazenados são formados tanto informação estáticas, como identificador da execução, nome da aplicação, parâmetros da execução e arquivos de entrada e saída, quanto informações dinâmicas, como o identificador do nó onde a aplicação está sendo executada e o estado da execução. Todos os dados são armazenados em arquivos XML em um banco de dados XML. Além de permitir a execução de aplicações Java através da tecnologia de agentes de software, o MAG disponibiliza um mecanismo para migração transparente de aplicações e um mecanismo de tolerância a falhas de aplicações executadas pelo MAG. 4.2 Execução de aplicações Um diagrama UML de seqüência que ilustra a cooperação entre os agentes do MAG e os componentes do Integrade para a execução de aplicações é representado na figura 3. Neste cenário um usuário requisita a execução de uma aplicação através da interface gráfica disponibilizada pelo componente ASCT (a aplicação deve ter sido previamente registrada no repositório de aplicações). O ASCT então encaminha esta requisição ao GRM (1), que executa seu algoritmo de escalonamento de forma a selecionar um nó disponível. Caso encontre um nó disponível, O GRM então repassa a requisição ao LRM do nó escalonado(2). 10

11 Figura 3: Diagrama UML de seqüência de submissão e execução de aplicações no middleware MAG Caso a aplicação a ser executada seja nativa do sistema operacional o LRM executa a aplicação sem nenhuma intervenção por parte do MAG. Entretanto, se esta for uma aplicação escrita usando a linguagem Java, a requisição é encaminhada ao AgentHandler local (3) e este então informa ao ASCT que aceitou o seu pedido de execução (4). Ao receber essa informação, o ASCT comunica ao EMA que teve uma aplicação submetida e aceita para execução à Grade (5). Em seguida o AgentHandler requisita ao ASCT os arquivos de entrada da aplicação salvando-os no sistema de arquivos local (6) e instancia um MagAgent responsável por executar a aplicação do usuário (7), que por sua vez prepara o ambiente para a execução da aplicação baixando o bytecode da aplicação do repositório (8). Logo após, o MagAgent informa ao EMA os dados relativos ao início da execução de sua aplicação (9) e instancia a aplicação e inicia sua execução em uma thread independente (10). O MagAgent então monitora a execução esperando pelo seu término. Ao perceber o fim da execução da aplicação, o MagAgent envia ao EMA e ao ASCT que originou a requisição uma notificação informando o término da execução (11 e 12). 11

12 5 Mecanismo de Tolerância a Falhas Como descrito na seção 1, a partir desta seção serão apresentados os componentes de software desenvolvidos durante este projeto de pesquisa, em atendimento aos objetivos apresentados também na seção introdutória deste relatório. 5.1 Tratamento de Falhas de Execução em Grades de Computadores Se um nó da grade falha, todas as aplicações sendo executas no nó vão falhar também, causando a perda de todas as computações realizadas até o momento da falha. O mecanismo de tolerância a falhas deve evitar a perda dessas computações, o desperdício dos recursos computacionais e deve ser totalmente transparente para a aplicação e o usuário. Para prover essas funcionalidades, um conjunto de mecanismos deve ser disponibilizado na plataforma de grade, tais como: 1. Detector de falhas em nós da grade: Os nós da grade devem ser constantemente monitorados. Duas abordagens podem ser utilizadas: push model - Nesta abordagem componentes da grade enviam periodicamente mensagens para um detector de falhas (failure detector) anunciando desta forma que eles estão vivos. Estas mensagem são freqüentementeente chamadas de heartbeat message. pull model - Nesta outra abordagem o detector de falhas é quem envia mensagens ( Are you alive? messages) para verificar se os componentes da grade estão ativos. [HCK02] No Integrade-MAG a detecção de falhas é feita através do envio periódico de heartbeat messages ( I am alive ) dos LRMs que executam em cada nó disponível na grade para o GRM. 2. Serviço de tratamento de falhas: Diversas estratégias para o tratamento de falhas podem ser empregadas no ambiente de grades computacionais e assim garantir a execução da aplicação mesmo na presença de falhas. Algumas das principais técnicas adotadas são: Retrying - É a técnica mais simples de tratamento de falhas. A idéia básica é que quando a execução de uma aplicação falhar, ela deve ser iniciada do princípio de sua execução. Apresenta como desvantagem a perda da computação efetuada antes da falha. Replicação - A idéia deste mecanismo de tratamento de falha é possuir múltiplas cópias de uma aplicação executando em recursos distintos da grade e assim aumentar as chances da tarefa executar em processadores mais velozes ou menos sobrecarregados. Esta técnica tolera a ocorrência de n-1 falhas, onde n é o número total de réplicas. Apresenta como desvantagem a alocação de múltiplos recursos para execução de uma única tarefa. Checkpointing - Esta técnica objetiva a salva periódica do estado de execução da aplicação (denominado checkpoint) em um armazém estável. Este estado 12

13 é constituído por vários tipos de informações, como a pilha de chamadas, os valores de retorno dos métodos, o conteúdo das variáveis locais, etc. A partir deste estado, a execução de uma dada aplicação pode ser restaurada ao seu estado pré-falha, reduzindo a quantidade de computação perdida. O uso desta técnica normalmente impõem alguma sobrecarga no tempo de execução da aplicação causado pela salva periódica do estado de execução, contudo esta é uma técnica bastante utilizada para promover tolerância a falhas em grades computacionais. 3. Armazém estável: as informações que tornarão possível recuperar o estado préfalha das aplicações devem ser salvas em um repositório de dados que deve sobreviver a eventuais falhas nos nós da grade. O armazém estável pode ser implementado de forma centralizada ou distribuída. Na primeira abordagem, ele deve executar em um nó dedicado da grade. Esta solução pode padecer de alguns problemas como a falta de escalabilidade, a presença de um ponto único de falhas e a criação de um gargalo gerando sobrecarga de comunicação na rede e prejudicando o desempenho. Na segunda abordagem, os dados de recuperação são espalhados através dos nós da grade. Esta abordagem soluciona os problemas da abordagem centralizada. Porém, visto que os nós da grade são instáveis, isto pode implicar na perda de parte dos dados de recuperação armazenados. Para evitar este problema, algoritmos de replicação e consistência de dados devem ser utilizados, de forma a aumentar a disponibilidade dos dados de recuperação. Além das falhas de nós, podem ocorrer em ambientes de grade falhas de aplicações individuais. Essas aplicações podem falhar por duas razões: (1) erros de implementação, e (2) erros incidentais. Erros de implementação são causados por erros de programação, como quando um programa tenta acessar uma posição inexistente de um vetor. Esse tipo de erro não pode ser recuperado, devendo portanto, ser imediatamente relatado ao usuário da grade. Já os erros incidentais estão normalmente relacionados a algumas condições do ambiente de execução, como falhas de hardware (p. ex. falhas temporárias de dispositivos) e condições limites (p. ex. falta de espaço em disco ou memória). Esses erros podem e devem ser tratados. No MAG, para assegurar que estes erros serão percebidos e tratados, o agente MagAgent foi implementado de modo a capturar as exceções lançadas pelas aplicações que eles executam e verificar se essas exceções são tratáveis. 5.2 Tolerância a Falhas no MAG A implementação corrente do MAG têm uma infra-estrutura básica para fornecer tolerância a falhas para aplicações que executam nesta Grade. A atual implementação trata falhas do tipo fail-stop (i.e. falhas de nós e de processos) uma importante classe de falhas em ambientes de Grade [LdSeS06]. A recuperação de aplicações no MAG é baseada na abordagem de recuperação por retorno (i.e. checkpoint [EAWJ96]), onde o estado de execução das aplicações é salvo periodicamente em um armazém estável de dados. Assim, se uma falha vier a ocorrer, as computações podem ser recuperadas a partir de seu último estado. O MAG também disponibiliza a abordagem de recuperação por reinício, onde as aplicações que são iniciadas do princípio da sua execução, no caso de falhas. 13

14 Quando submete uma aplicação no MAG, o usuário pode habilitar ou não a salva de checkpoints que será feita durante a execução da aplicação. Assim como poderá determinar também, o intervalo de tempo entre a salva destes checkpoints. Se o usuário desabilita o uso da técnica de checkpointing o mecanismo de retrying será adotado por padrão. O mecanismo de tolerância a falha do MAG atualmente é composto de três agentes: O StableStorage é um repositório para o armazenamento dos checkpoints de aplicações. Hoje ele está implementado de forma centralizada, devendo executar no nó gerenciador da Grade. Mas poderia ser implementado de maneira distribuída, tornando-o mais resistente a eventuais falhas nos nós do aglomerado. O AgentRecover este agente é responsável por iniciar o processo de recuperação das aplicações que executavam em um nó da grade que tenha falhado. Ele também participa da recuperação de aplicações individuais que tenham falhado por erros incidentais, ou seja, erros relacionados a condições do ambiente de execução, como por exemplo: falta de espaço em disco ou memória.. O ExecutionManagementAgent, já descrito anteriormente, auxilia o mecanismo de tolerância a falhas do MAG provendo três funcionalidades: ele fornece informações sobre as execuções das aplicações (como a localização dos arquivos de entrada). Mapeia as aplicações com os nós onde elas executam e armazena dados que são utilizados para gerar algumas estatísticas úteis. 5.3 Replicação de Processos no Middleware MAG A fim de tornar o mecanismo de tolerância a falhas do middleware MAG mais flexível, é conveniente que seja implementado o suporte a outra importante técnica de tratamento de falhas de aplicações: a replicação de processos. Nesta técnica, várias cópias da mesma aplicação (e com o mesmo conjunto de dados de entrada) são submetidas simultaneamente para execução na Grade. Assim, a falha de uma réplica da aplicação não acarreta perda de tempo computacional já realizado, uma vez que as outras réplicas da mesma aplicação continuarão a executar sem problemas. Para alcançar tal objetivo foram adicionados os seguintes agentes de software a arquitetura do middleware: Cluster Replication Manager Agent (CrmAgent): O responsável por gerenciar todas as execuções com réplicas no aglomerado, inicializar os ERM, bem como, liberar os ERM quando pelo menos uma das réplicas finalizar sua execução. Execution Replication Manager Agent (ErmAgent): gerencia a execução das réplicas para uma dada solicitação de execução, garante a execução das réplicas em recursos distintos, mapeia as réplicas da aplicação com os AgentHadlers responsáveis por suas execuções, podendo assim, requisitar o término das réplicas adicionais quando pelo menos uma delas finalizar corretamente sua execução, e assim, liberar recursos da grade. Além de obter os resultados da computação junto ao MagAgent que finalizou a execução e informar ao ASCT requisitante se a requisição foi aceita, recusada ou finalizada. 14

15 5.4 Detalhes de Implementação Nesta seção serão descritos em mais detalhes os novos agentes adicionados a arquitetura geral do MAG para prover o suporte a replicação. Serão apresentados também seus diagramas de definição de estrutura de agentes (SASD). O diagrama SASD representa a estrutura interna dos agentes, seus comportamentos e interfaces, sendo um diagrama previsto na metodologia para o desenvolvimento de sistemas multiagentes Agil PASSI [CCSS04]. A Agil PASSI é uma adaptação da metodologia PASSI (Process for Agents Societis Specification and Implementation) original [CSSC03, CSS03]. Ela foi concebida para permitir o desenvolvimento de sistemas multiagentes utilizando processos ágeis. O diagrama SASD utiliza diagrama de classes como forma de representação. Será descrito ainda, o refatoramento realizado sobre o componente da arquitetura geral do MAG ExecutionManagementAgent, para que este conseguisse efetuar o registro das informações relativas a execução com réplicas na grade CrmAgent O CrmAgent é um agente que é executado no nó gerenciador do aglomerado, sendo que cada aglomerado que deseje prover suporte a execução com réplicas deve possuir um agente CRM executando na plataforma de agentes. Sua principal funcionalidade é gerenciar todas as execuções com réplicas do aglomerado. Quando uma solicitação de execução com réplicas é realizada na grade, o CrmAgent trata de inicializar agentes ERM, um para cada requisição, para que estes gerenciem esses execuções e suas respectivas réplicas. Este agente também tem o trabalho de eliminar os ErmAgents que gerenciam as execuções com réplicas que já foram completadas pela grade. Este agente está estruturado como mostra a figura 4 Figura 4: Diagrama SASD do CrmAgent 15

16 5.4.2 ErmAgent O ErmAgent é o agente iniciado pelo CrmAgent a cada solicitação de execução com réplicas. Sua principal finalidade é monitorar as réplicas inicializadas em uma dada execução. Este agente é responsável por requisitar e armazenar os arquivos de entrada da aplicação, obtidos junto ao ASCT no qual a solicitação foi feita. Os MagAgents responsáveis por executar cada réplica, devem então, requisitar os arquivos de entrada junto ao ErmAgent antes do início da execução da aplicação. O ErmAgent também solicita, ao final da execução, os arquivos de saída gerados ao MagAgent que finalizou a execução, armazenando-os para que estes possam ser posteriormente obtidos pelo ASCT requisitante. O diagrama SASD que mostra a estrutura do ErmAgent é mostrado na figura 5. Figura 5: Diagrama SASD do ErmAgent 5.5 Protocolo de Execução de Aplicações com Réplicas Para permitirmos a correta execução das aplicações com réplicas, o protocolo de execução padrão do MAG conforme descrito na seção 4.2 foi alterado. A título de exemplificação será demonstrado a seqüência de passos do protocolo necessários a execução de uma aplicação regular com uma réplica. Estas interações são ilustrada na figura 6. Uma vez que uma aplicação tenha sido previamente registrada no Repositório de Aplicações através do ASCT, o usuário solicita a execução da aplicação informando a quantidade de réplicas desejadas para aquela execução. Assim que a execução é encaminhada ao GRM (1), ele procura por recursos disponíveis para executar as réplicas da aplicação, utilizando os requisitos especificados pelo usuário e as informações sobre disponibilidade de recursos. Caso não existam nós com os recursos para atender os requisitos da aplicação, o GRM notifica ao ASCT, que solicitou a execução. Entretanto, caso haja recursos disponíveis, o GRM informa ao CrmAgent quais recursos foram escalonados para a execução das réplicas (2). Em seguida, o CrmAgent atribui um identificador único para cada réplica, informando ao ExecutionManagementAgent sobre o escalonamento destas (3) e então inicializa um Er- 16

17 magent para gerenciar aquela solicitação (4). O ErmAgent por sua vez obtém, junto ao ASCT solicitante, os arquivos de entrada (5) e solicita aos AgentHandlers das máquinas escalonadas a execução da aplicação (6 e 7). Logo após, os AgentHandlers instanciam MagAgents responsáveis por executar cada réplica da aplicação (8 e 9), que por sua vez preparam o ambiente para a execução das aplicações baixando o bytecode da aplicação no repositório (10 e 11), solicitam, caso existam, os arquivos de entrada da aplicação ao ErmAgent (12 e 13) e informam ao ErmAgent que a réplica foi aceita para execução (14 e 15). Em seguida, o ErmAgent informa ao ASCT requisitante que a aplicação foi aceita (16). Logo após, os MagAgents informam ao EMA os dados relativos ao início da execução de sua aplicação (17 e 18). Após o início da execução da computação (19 e 20), cada MagAgent passa a monitorar a sua réplica, aguardando por ser término. Ao perceber o fim da execução, o MagAgent notifica a finalização da execução da réplica ao ERM (21) e ao ExecutionManagementAgent (22), assim, o ERM passa a executar suas rotinas de término das réplicas. Inicialmente solicita a finalização da execução das réplicas adicionais aos AgentHandlers responsáveis (23) liberando, então, os recursos computacionais. O ErmAgent modifica o estado das réplicas que foram mortas para finalizadas junto ao EMA (24). A seguir, solicita os resultados da computação ao MagAgent que finalizou a execução (25), informando ao ASCT requisitante sobre o término da solicitação de execução da aplicação (26). E por fim, o ASCT pede os resultados da computação ao ERM (27), exibindo-os ao usuário. 6 Resultados Obtidos e Conclusões A partir da implementação da técnica de replicação de processos foi possível fornecer ao usuário da grade um esquema flexível para o tratamento de falhas de aplicações. Esta flexibilidade é proveniente da combinação das técnicas fornecidas pelo MAG, resultando em quatro diferentes abordagens para o tratamento de falhas: reinício da aplicação (sem checkpointing ou replicação), checkpointing sem replicação, replicação sem checkpointing e replicação com checkpointing. O uso de cada uma destas técnicas deverá ser configurado pelo usuário através da interface de submissão de aplicações da grade (ASCT). A adoção de um mecanismo flexível no MAG, visa permitir que as tarefas possam ser executadas utilizando o mecanismo de tolerância a falhas, ou combinação de mecanismos, mais apropriados. Esta escolha dependerá das características do ambiente de execução e de sua confiabilidade. Referências [AGI] Agile Manifesto website. Acessado em: 01/12/2005. [BBL00] M. Baker, R. Buyya, and D. Laforenza. The grid: International efforts in global computing. In Proc. of the International Conference on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet, [CCSS04] Antonio Chella, Massimo Cossentino, Luca Sabatucci, and Valeria Seidita. From PASSI to Agile PASSI: Tailoring a Design Process to Meet New Needs. In 17

18 Figura 6: Diagrama de seqüência de submissão e execução de aplicações utilizando réplicas 18

19 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT 04), pages , [CSS03] Massimo Cossentino, Luca Sabatucci, and Valeria Seidita. Spem description of the passi process rel Technical Report RT-ICAR-20-03, Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni, December [CSSC03] M. Cossentino, L. Sabatucci, S. Sorace, and A. Chella. Patterns reuse in the PASSI methodology. In Proceedings of the Fourth International Workshop Engineering Societies in the Agents World (ESAW 03), pages 29 31, Imperial College London, UK, October [EAWJ96] Mootaz Elnozahy, Lorenzo Alvisi, Yi-min Wang, and David B. Johnson. A survey of rollback-recovery protocols in message-passing systems [FIP] [FK99] [FKT01] Foundation for Intelligent Physical Agents website. Ian Foster and Carl Kesselman. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, San Francisco, I. Foster, C. Kesselman, and S. Tueke. The anatomy of the grid: Enabling scalable virtual organizations. International Journal of Supercomputing Applications, [GKG + 04] A. Goldchleger, F. Kon, A. Goldman, M. Finger, and G. C. Bezerra. Integrade: Object-oriented grid middleware leveraging idle computing power of desktop machines. Concurrency and Computation: Practice & Experience. Vol. 16, pp , [HCK02] [INT] [JAD] [KBM02] Naohiro Hayashibara, Adel Cherif, and Takuya Katayama. Failure detectors for large-scale distributed systems. srds, 00:404, InteGrade website. Java Agent DEvelopment Framework website. Klaus Krauter, Rajkumar Buyya, and Muthucumaru Maheswaran. A taxonomy and survey of grid resource management systems for distributed computin. In Software - Practice and Experience, volume 32, pages February [LdSeS06] Rafael Fernandes Lopes and Francisco José da Silva e Silva. Fault Tolerance in a Mobile Agent Based Computational Grid. In AgentGrid2006: 4th International Workshop on Agent Based Grid Computing. IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 06), Singapore, May IEEE Computer Society Press. to appear. [Lop06] Rafael Fernandes Lopes. MAG: uma grade computacional baseada em agentes móveis. Master s thesis, Universidade Federal do Maranhão, Sã Luís, MA, Brasil, Janeiro In Portuguese. 19

20 [LSS05] Rafael Fernandes Lopes, Francisco José da Silva Silva, and Bysmarck Barros de Sousa. MAG: A Mobile Agent based Computational Grid Platform. In In Proceedings of the 4th International Conference on Grid and Cooperative Computing (GCC 2005), Lecture Notes in Computer Science, Beijing, November Springer-Verlag. [SSTF06] Bysmarck Barros de Sousa, Francisco José da Silva Silva, Mário Meireles Teixeira, and Gilberto Cunha Filho. MagCat: An Agent-based Metadata Service for Data Grids. In 4th International Workshop on Agent Based Grid Computing. IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 06), Singapore, May IEEE Computer Society Press. 20