Gestor de Processos Tolerante a Falhas para Aplicações Paralelas

Gestor de Processos Tolerante a Falhas para Aplicações Paralelas Oberdan Rocha Pinheiro, Josemar Rodrigues de Souza Resumo O desempenho computacional disponibilizado pelos sistemas paralelos resulta da capacidade de dividir o trabalho em partes menores e encaminhar cada uma delas para ser processada paralelamente em diferentes nós de um sistema distribuídos. A interrupção de uma das partes paralelizadas pode comprometer a computação, pois a aplicação depende do resultado de todos os componentes paralelizados. A investigação avalia o comportamento do componente GP (Gestor de Processos) que monitora o ambiente de execução das aplicações paralelas a fim de detectar falhas da classe fail stop em aplicações paralelas que utilizam MPI (Message Passing Interface), permitindo que as mesmas sejam reiniciadas automaticamente em outro nó disponível da computação distribuída para garantir o resultado do processamento na presença de falhas. Palavras chavess Computação de Alto Desempenho, Detectores de Falhas, MPI, Tolerância a Falhas I. INTRODUÇÃO A busca por computação de alto desempenho é cada vez maior nas áreas de aplicações científicas e de engenharia, pois essas áreas têm problemas assintoticamente complexos (em tempo e espaço), com características que facilitam a paralelização. Através da paralelização de aplicações, pode-se obter aumento de desempenho, realizando-se operações mais rapidamente ou processando-se maiores volumes de dados. As arquiteturas de computadores paralelos têm como principal objetivo o aumento da capacidade de processamento, utilizando o potencial oferecido por um grande número de recursos computacionais [1]. Os clusters baseados em passagem de mensagens foram construídos tendo-se como principal preocupação o provimento de um ambiente eficiente e portável, relegando a segundo plano a questão da tolerância a falhas. No caso de aplicações paralelas que utilizam varias máquinas e cuja execução se estende por muitas horas, a falha de uma única Artigo recebido em 03 de Fevereiro de 2012. Este artigo foi desenvolvido pelo Programa de Pós-Graduação da Faculdade SENAI CIMATEC. O.R.P. e J.R.S. estão no Centro Integrado de Manufatura e Tecnologia (SENAI-CIMATEC), Núcleo de Modelagem Computacional, Laboratório de HPC (High Performance Computing), Salvador, Bahia, Brasil, Tel. +55-71- 3462-9538, Fax: +55-71-3462-9559, E-mail: oberdan.pinheiro@gmail.com, josemarsbr@gmail.com. J.R.S. está com a Universidade do Estado da Bahia - UNEB, Núcleo de Arquitetura de Computadores e Sistemas Operacionais - ACSO, Salvador, Bahia, Brasil, Tel. +55 (71) 3117-2200, E-mail: josemarsbr@gmail.com. 7 máquina neste período normalmente faz com que toda a computação já realizada seja perdida [2]. Ao longo do tempo, surgiram várias abordagens e ferramentas para a programação paralela e distribuída, sendo que, nos últimos anos, o uso do MPI tornou-se um padrão para comunicação em clusters. No entanto o padrão MPI não prevê mecanismo para monitoração do ambiente de execução e tratamento de falhas. Neste contexto, o presente trabalho tem como objetivo avaliar o desempenho do componente de software GP (Gestor de Processos) que é responsável pela monitoração do ambiente de execução das aplicações distribuídas a fim de detectar falhas da classe fail stop, onde os nós falham e não executam nenhuma operação após isso, restando ao nó monitor detectar a falha pela omissão de comunicações posteriores, permitindo que as mesmas sejam reiniciadas automaticamente em outro nó disponível do cluster para garantir a continuidade do processamento da aplicação na presença de falhas. O artigo está organizado da seguinte forma. A seção II descreve as considerações sobre tolerância a falhas, na seção III serão apresentadas as principais estratégias de monitoramento utilizadas por detectores de falhas, na seção IV serão apresentadas as principais características sobre qualidade de serviço de detecção de falhas, na seção V são apresentados alguns trabalhos relacionados na área de detectores de falhas, na seção VI é apresentada a solução proposta, na seção VII são apresentados os resultados experimentais e na seção VIII conclui-se a pesquisa. II. TOLERÂNCIA A FALHAS De acordo com Weber [2] o termo tolerância a falhas foi apresentado originalmente por Avizienis em 1967. Quando o sistema exige alta confiabilidade e alta disponibilidade, técnicas de tolerância a falhas devem ser utilizadas para garantir o funcionamento correto do sistema, mesmo na ocorrência de falhas, exigindo componentes adicionais ou algoritmos especiais. Tolerância a falhas tem como objetivo permitir que um sistema comporte-se de maneira bem definida durante a ocorrência de falhas, visando minimizar o aparecimento das mesmas ou então tratá-las quando ocorrerem. A. Modelos de Falhas em Sistemas Distribuídos Existem diversas possibilidades de uma aplicação distribuída falhar. Essas falhas podem ser categorizadas em modelos que descrevem como o sistema se comportará na

presença de falhas. O modelo de Cristian [3], ilustrado na Fig. 1, classifica as falhas em falhas por colapso, omissão, temporização, resposta e arbitrárias. O modelo de Schneider [4] estende esse modelo adicionando a classe fail-stop, que é um subconjunto da classe de falhas por colapso, e especializando as falhas de omissão em: falhas de omissão de envio e falhas de omissão de recepção. A classe de falhas fail-stop é a mais específica desses modelos e comporta as falhas que são detectadas antes que o processo que falhou possa causar alterações no restante da computação. Por exemplo, nesse modelo, um processador que apresente uma falha na execução de alguma operação deixará de funcionar em vez de fornecer resultados incorretos. A classe de falhas arbitrárias, também chamadas de Bizantinas, são as mais abrangentes. Nessa classe o processo que falhou pode apresentar um comportamento fora da sua especificação, totalmente imprevisível e podendo comprometer o restante da computação. Um sistema que assume o tratamento somente da classe fail-stop é bem mais simples de ser implementado do que um que trate também as falhas arbitrárias. FIG. 1. MODELOS DE FALHAS EM SISTEMAS DISTRIBUÍDOS. A computação em clusters depende de elementos centralizados para operar. Nodos de gerência são utilizados para o escalonamento de tarefas e monitoramento do ambiente. Nodos de armazenamento oferecem acesso a discos de grande capacidade e altas taxas de transferência. Nodos de front-end permitem que os usuários interajam com o sistema sem interferir no tempo de processamento dos nodos de computação. Devido à importância crítica desses componentes, e por eles representarem uma pequena fração da computação que eles compõem, é recomendado dedicar uma atenção especial a esses recursos. A forma mais comum de suporte a tolerância a falhas para componentes centralizados é a replicação da funcionalidade que pode ser feita de duas formas: replicação ativa e replicação passiva. Na replicação ativa, um processo secundário recebe uma cópia das entradas do processo primário e mantêm uma cópia idêntica do estado da computação em execução. Além disso, o processo secundário monitora o processo primário para detectar comportamentos 8 incorretos. Se o processo secundário detectar uma falha ele assume o comando da funcionalidade crítica do sistema [5]. Na replicação passiva, uma máquina secundária aguarda a falha do processo primário sem manter o estado do sistema. Tipicamente, essa máquina permanece inativa, porém com todo software necessário para substituir o processo primário quando necessário. Podem acontecer interrupções do serviço durante a substituição do processo primário pelo secundário dependendo do estado da réplica. O monitoramento das réplicas normalmente é implementado utilizando um dos dois mecanismos: heartbeat [6] [7] ou consenso Bizantino [8]. No monitoramento por heartbeat um processo monitor recebe mensagens periódicas dos componentes monitorados. Essas mensagens indicam que o componente funciona de forma correta o suficiente para conseguir enviá-las. Se o processo monitor deixa de recebê-las de um determinado componente além de um limite de tempo estabelecido o nodo é considerado falho. Uma variação do heartbeat utiliza protocolos epidêmicos ou hierárquicos [9] para a propagação das mensagens no sistema. Essas variantes permitem que o heartbeat escale com um número maior de nodos. No consenso Bizantino as réplicas votam por um resultado ou ação a ser tomada com base nas entradas observadas. Quando existe um desacordo entre os processos então os processos que tem minoria na votação são considerados falhos. Esse tipo de monitoramento consegue detectar falhas Bizantinas. No entanto, o custo de comunicação desse tipo de monitoramento é muito maior do que o monitoramento por heartbeat já que no pior caso do algoritmo é necessário que todos os nodos se comuniquem entre si. Apesar disso, para um pequeno número de réplicas, esse algoritmo ainda é aceitável. B. Sistemas de Arquivos Tolerantes a Falhas Um sistema de arquivos tolerante a falhas é importante em função de que os arquivos produzidos na computação distribuída serão armazenados e recuperados do mesmo. É importante que ele esteja sempre disponível para atender às requisições e, quando existirem, consiga atender o volume necessário em um tempo aceitável. Para garantir a tolerância a falhas e alta disponibilidade, algumas soluções podem ser empregadas. Algumas destas soluções são viabilizadas através de hardware, tais como a técnica de RAID (Redundant Array of Independent Disks), multiplexação de discos e replicação de primeira classe e outras viabilizadas por software como, por exemplo, a replicação de segunda classe [10] [11]. No caso da replicação de primeira classe, o servidor é replicado e, conseqüentemente, o sistema de arquivos também e na replicação de segunda classe utiliza-se a técnica conhecida como caching do cliente ou journal file system; são exemplos desta replicação os sistemas de arquivos CODA [11] [12]. A técnica empregada no RAID consiste em agrupar uma série de discos em um único local e disponibilizá-los na forma de uma imagem única de sistema de armazenamento e recuperação de informações [10]. Sua implementação pode ser viabilizada por hardware, ou seja, um dispositivo com

finalidade única de agrupar os discos e realizar o gerenciamento dos mesmos, estando este dispositivo ligado através de um barramento de alta velocidade aos nós de computação. O Sistema de Arquivos de Rede NFS (Network File System) da Sun Microsystems é considerado o padrão de fato para o compartilhamento de arquivos pela rede e é suportado nativamente na maioria das versões do UNIX e Linux, estando disponível para praticamente qualquer ambiente operacional e opera baseado no modelo cliente servidor [13]. O projeto original do NFS tinha o TCP/IP como base e assim pôde ser facilmente adaptado para conectar sistemas de arquivos geograficamente dispersos através da Internet e outras redes de longa distância. porém estas mensagens são do tipo query-response, também conhecidas como ping. O mecanismo ilustrado na Fig. 3 funciona da seguinte maneira: seja Worker o processo monitorado e Master o processo detector de falhas. O processo Master envia periodicamente uma query ( você está vivo?") para o processo Worker, que deve responder ( eu estou vivo!") em tempo hábil, porém, caso tal resposta não chegue num certo timeout, o Master assume que ocorreu uma falha do processo Worker. III. DETECÇÃO DE FALHAS EM SISTEMAS DISTRIBUÍDOS Grande parte dos problemas relacionados aos sistemas distribuídos requer algum tipo de coordenação entre os diversos componentes [14]. Em sistemas compostos por vários nodos a falha ou desconexão destes nodos é um evento freqüente e deve ser considerado. Desse modo, um requisito fundamental para a coordenação dos processos é que estes tenham os seus estados armazenados para posterior reconfiguração do sistema em caso de falhas. As principais estratégias de monitoramento utilizadas por detectores de falhas são a push e a pull. Numa abordagem push o processo monitorado toma um papel mais ativo, enquanto que numa abordagem pull, ele adota um papel mais passivo [15]. Segundo Satzger [15], detectores de falhas que utilizem o paradigma push possuem alguns benefícios se comparados àqueles que utilizem uma abordagem pull, necessitam de apenas a metade das mensagens para uma qualidade de detecção equivalente. A. Estratégia push O mecanismo ilustrado na Fig. 2 funciona da seguinte maneira: seja Worker o processo monitorado e Master o processo detector de falhas. O processo Worker envia periodicamente um heartbeat ( estou vivo") para o processo Master. Quando o Master recebe um heartbeat ele confia no Worker por um período de tempo, porém caso novas mensagens não cheguem até expirar este timeout, o Master assume que ocorreu uma falha do processo Worker. Naturalmente, o timeout deve ter um valor maior que o intervalo de heartbeat. FIG. 3. MONITORAMENTO POR PULL. IV. QUALIDADE DO SERVIÇO DE DETECÇÃO DE FALHAS Um detector de falhas pode ser definido por duas características: Completude é a garantia de que a falha em um membro do grupo é eventualmente detectada por cada outro membro não-falho. Eficiência significa que as falhas são detectadas rápida e precisamente. Algumas aplicações distribuídas confiam em um único ou mesmo poucos computadores centrais para a detecção de falhas ao longo da computação. Estes computadores são responsáveis por manter as informações ao longo de toda a computação e, portanto, a eficiência na detecção de uma falha depende do tempo em que a falha é inicialmente detectada por um membro não-falho. Gupta et al. [16] observou que mesmo na falta de um servidor central, a notificação de uma falha é tipicamente comunicada pelo primeiro membro a detectá-la a todo o grupo via broadcast. Portanto, mesmo sendo importante alcançar completude, uma eficiente detecção de falhas é mais comumente relacionada com o tempo da primeira detecção da falha. Chandra & Toueg [17] analisaram as propriedades dos detectores de falhas demonstrando porque é impossível para um algoritmo de detecção de falhas deterministicamente alcançarem ambas as características de completude e precisão estando numa rede assíncrona e não-confiável. Como conseqüência, a maioria das aplicações distribuídas tem optado por contornar esta impossibilidade ao confiar em algoritmos de detecção de falhas que garantam completude deterministicamente enquanto alcançam eficiência apenas probabilisticamente [16]. FIG. 2. MONITORAMENTO POR PUSH. B. Estratégia pull Esta estratégia é também baseada na troca de mensagens periódicas para suspeitar acerca de falhas em processos, 9 V. TRABALHOS RELACIONADOS Chen et al. [15] propõem um modelo baseado numa análise probabilística do tráfego de rede, utilizando amostragens dos tempos de chegada para calcular uma estimativa acerca do tempo de chegada da próxima mensagem. O timeout é

configurado de acordo com esta estimativa e é acrescida de uma margem de segurança constante α, que é calculada uma única vez. Hayashibara et al. [18] propuseram um detector de falhas accrual cuja particularidade é ajustar dinamicamente a escala onde o nível de suspeita é expresso às condições da rede. A distribuição das amostras recebidas anteriormente é utilizada como uma aproximação da distribuição probabilística das futuras mensagens de heartbeat. Satzger et al. [19] propuseram um novo detector accrual adaptativo, com características para aumentar a flexibilidade e diminuir os custos computacionais. É armazenado um histórico dos tempos de chegada entre mensagens, de maneira que é possível realizar uma estimativa da probabilidade de que nenhuma mensagem chegue após determinado atraso, ou seja, do processo ter falhado. Das et al. [20], apresenta um protocolo de gestão da composição de grupos, chamado SWIM. O protocolo SWIM é dividido em duas partes: um detector de falhas e um protocolo de disseminação da composição do grupo. Este detector de falhas foi proposto inicialmente em [16]. O detector utiliza uma estratégia de ping randomizado, onde cada processo periodicamente testa outro processo, selecionado aleatoriamente. Informações sobre a composição do grupo e falhas de processos são transmitidas nas próprias mensagens do detector de falhas, através de um mecanismo de piggybacking. VI. SOLUÇÃO PROPOSTA Informações sobre a situação operacional dos processos são freqüentemente necessárias para implementar aplicações confiáveis e distribuídas. O trabalho propõe um Gestor de Processos colaborativo para detectar e tratar falhas da classe fail stop em aplicações paralelas. O monitoramento dos processos é realizado através da estratégia push, e o timeout do heartbeat é fixado e deve ser ajustados conforme o ambiente onde este mecanismo será empregado. A fixação do valor desse parâmetro implica em um trade-off entre corretude e eficiência. Para não exceder o limite de tempo tão cedo, os valores de timeout poderiam ser determinados de forma conservadora, ou seja, valores muito grandes. No entanto, isto implica em uma demora na detecção de falhas, conseqüentemente acarretando em maior sobrecarga da aplicação. A orientação é definir os valores desses parâmetros tão grandes quanto necessários, mas tão pequenos quanto possíveis. A Fig. 4 apresenta os componentes que compõe a arquitetura do ambiente. A arquitetura do ambiente de computação tolerante a falhas foi projetada utilizando o paradigma SPMD (Single Program Multiple Data) implementado sob o esquema Master/Worker. No modelo SPMD o mesmo programa é executado em diferentes máquinas, entretanto esses programas manipulam um conjunto de dados diferentes. No esquema Master/Worker, o Master é o processo responsável por decompor o problema em diversas tarefas menores e distribuir essas tarefas entre os Workers. A. Arquitetura FIG. 4. ARQUITETURA DO AMBIENTE TOLERANTE A FALHAS. O Worker é o processo que recebe os trabalhos, processam e devolvem para o Master, que gerencia, organiza e controla os dados processados. A comunicação entre os processos (Master/Worker) é feita através de troca de mensagens realizadas por chamadas explícitas às rotinas da biblioteca MPI [21]. O SATF (Sistema de Arquivos Tolerante a Falhas) é o local de armazenamento confiável que utiliza o sistema de arquivos de rede NFS onde são registrados os dados para manter o cluster operante em caso de falha. Esse componente é imprescindível em razão de que os dados produzidos serão armazenados e recuperados do mesmo. As operações de E/S ao SAFT será realizada através do padrão MPI-IO que é um recurso útil para a criação e manipulação de arquivos paralelos [22]. O componente AP (Aplicação Paralela) representa o programa paralelizado, esse componente está presente tanto no grupo Master quanto no grupo Worker, o componente GP é o componente responsável pela monitoração do ambiente e gestão dos processos em caso de falhas, estando presente apenas no grupo Master. Esse componente é o responsável por aguardar o envio de pacotes periódicos heartbeat por parte dos Workers, quando o GP detectar que um Worker não enviou o pacote dentro do tempo estabelecido, então o mecanismo assume que o nó que parou de enviar os pulsos está indisponível. A Fig. 5 ilustra o funcionamento do ambiente de execução. Quando o processo Master escalonar um bloco de dados para um Worker um trigger será acionado para enviar uma solicitação ao GP para criar um backup do bloco de dados que será armazenado em um servidor de arquivos estável (SATF). Em seguida os blocos de dados serão enviados para os Workers realizarem o processamento da tarefa. 10

FIG. 5. INTERAÇÃO ENTRE OS COMPONENTES. O GP aguarda o envio de pacotes periódicos (heartbeat) por parte dos Workers, quando o GP detectar que um Worker não enviou o pacote dentro do tempo estabelecido, então o mecanismo assume que o Worker está indisponível e esse será excluído logicamente do cluster e não terá mais blocos de dados escalonados. Para permitir a continuidade da computação o GP recupera o bloco de dados destinado ao Worker que parou de funcionar através dos backups armazenados no servidor de arquivos, em seguida o bloco de dados recuperado é escalonado para o próximo Worker disponível dar continuidade ao processamento. B. Implementação Os componentes do serviço foram implementados utilizando a linguagem C++. A aplicação paralela utilizada para a validação do GP foi o programa de multiplicação de matrizes ilustrada na Fig. 6, por ser facilmente escalável tanto em cômputo quanto em comunicação. FIG. 7. ENVIO DO TIMEOUT VIA MPI_BCAST. Os processos são alocados de maneira estática e realizam atividades idênticas sobre um conjunto de dados distintos. É necessário que todos os Workers só comecem o processamento quando todos tiverem recebidos os seus respectivos timeout para envio de pacotes periódicos ao Master. Para a manipulação dos registros que contém o estado dos Workers armazenados no SAFT o GP utiliza o paradigma Single Process I/O que determina que apenas um processo realize o I/O. A Fig. 9 apresenta o mecanismo de acesso aos arquivos através do padrão MPI-IO. n a C = ij k = 1 FIG. 6. MULTIPLICAÇÃO DE MATRIZES. ik b kj A forma matemática de multiplicação de matrizes (1) consiste do somatório dos produtos entre os elementos da linha i de A pelos elementos da coluna j de B, com i variando de 1 até a quantidade de linhas de A e j de 1 até o número de colunas de B. O processo Master é responsável pela inicialização das matrizes A e B, envio dos blocos de dados para os Workers e sincronização dos dados para montagem da matriz C. Os Workers além de realizarem o produto dos vetores enviados pelo processo Master, também devem periodicamente enviar os pacotes heartbeat dentro do timeout determinado pelo Master. O timeout será comunicado aos Workers através da operação MPI_Bcast, essa rotina permite ao processo Master enviar dados para todos os processos Workers de um determinado grupo, conforme Fig. 7. (1) 11 FIG. 9. MECANISMO DE ACESSO AOS ARQUIVOS. Os Workers enviam os pacotes heartbeat para o GP e ele realiza o armazenamento dessas informações através das seguintes operações: MPI_File_open() para associar um file handle a um arquivo. MPI_File_read() para lê uma quantidade fixa de dados a partir da posição do ponteiro do arquivo. (não coletiva e bloqueante). MPI_File_write() para escrever uma quantidade fixa de dados a partir da posição do ponteiro do arquivo. (não coletiva e bloqueante). MPI_File_close() para fechar o arquivo. VII. AVALIAÇÃO E RESULTADOS EXPERIMENTAIS Para a avaliação do componente de software GP (Gestor de Processos) colaborativo foi utilizada a técnica de injeção de falhas por software por se tratar de um método eficiente para a validação de sistemas [23]. A abordagem visa à emulação de falhas de hardware, sem comprometer fisicamente o ambiente, e a análise do comportamento do sistema na presença destas falhas. Os experimentos foram realizados no laboratório de HPC (High Performance Computing) do Centro Integrado de

Manufatura e Tecnologia (SENAI CIMATEC). O ambiente consistiu de um cluster de computadores formado por 16 blades HP ProLiant DL120 G6 Quad core Intel Xeon HP X3450 (2.67GHz, 95W, 8MB, 1333, HT, Turbo), utilizandose do sistema operacional Ubuntu/Linux 64 bit, mpich 1.2.52 que implementa todo o padrão MPI 1.1 e o compilador gnu gcc 3.2.3. A rede de conexão utilizada segue o padrão Gigabit Ethernet. A. Tempo de Detecção de Falhas A decisão de quando a informação fornecida por um detector de falhas deve ser considerada verdadeira é de responsabilidade da aplicação [24]. Esta decisão envolve custos ao programa para realizar uma ação de reconfiguração do ambiente. O componente GP utiliza à variável timeout para representar o tempo máximo de espera por uma mensagem de heartbeat. A fixação dessa variável implica na eficiência da detecção das falhas nos nodos do cluster. A parametrização dessa variável com um valor muito longo implicaria em uma demora na detecção de falhas, o que comprometeria a eficiência do GP, determinar bons valores para esse parâmetro se torna um desafio. Nesse sentido, foram realizados experimentos onde alguns valores para o timeout foram testados a fim de avaliar o impacto dessa escolha no tempo da aplicação. Os resultados dos experimentos foram obtidos pela média dos resultados de três execuções. Os experimentos foram feitos em um ambiente com falhas, as falhas foram injetadas nos Workers forçando esses processos a não enviarem os dados do heartbeat apartir de um determinado momento ao processo GP. Nos experimentos os Workers foram configurados com valores do timeout iguais a 15, 30, 45 e 60 s, o cluster foi configurado com 21 processos, sendo 20 processos Workers e um processo Master. No primeiro experimento conforme Tabela 1 o valor do timeout foi de 15 s, no segundo experimento conforme Tabela 2 o valor do timeout foi de 30 s, no terceiro experimento conforme Tabela III o valor do timeout foi de 45 s e no quarto experimento conforme Tabela IV o valor do timeout foi de 60 s. TABELA I CENÁRIO DO PRIMEIRO EXPERIMENTO 4 03:19:50 03:20:07 00:00:17 8 03:21:06 03:21:27 00:00:21 12 03:25:47 03:26:15 00:00:28 16 03:27:55 03:28:15 00:00:20 20 03:30:26 03:30:52 00:00:26 12 03:57:19 03:58:06 00:00:47 16 03:56:39 03:57:31 00:00:52 20 03:57:25 03:58:06 00:00:41 TABELA III CENÁRIO DO TERCEIRO EXPERIMENTO 4 04:39:46 04:41:03 00:01:17 8 04:41:23 04:42:43 00:01:20 12 04:43:02 04:44:23 00:01:21 16 04:42:55 04:44:23 00:01:28 20 04:45:23 04:46:53 00:01:30 TABELA IV CENÁRIO DO QUARTO EXPERIMENTO 4 04:45:15 04:46:39 00:01:24 8 04:47:32 04:48:59 00:01:27 12 04:49:02 04:50:50 00:01:48 16 04:51:40 04:52:59 00:01:19 20 04:53:15 04:54:59 00:01:44 O cenário do primeiro experimento configurado com um timeout de 15 s é quem apresenta um melhor resultado na detecção de falhas por realizar um monitoramento freqüente dos processos envolvidos na computação. Note que um freqüente monitoramento pode levar a um aumento no tempo de execução da aplicação e conseqüentemente irá levar mais tempo para completar o processamento da aplicação. Uma vez que em cada nó, os processos monitores compartilham um núcleo de processamento com um processo de aplicação. Na Fig. 10 observa-se que, em geral, quanto maior o valor do timeout, maior o tempo gasto na detecção da falha. Tempo de Detecção (s) 120 100 80 60 40 20 0 4 8 12 16 20 Nº de processos timeout 15 s timeout 30 s timeout 45 s timeout 60 s FIG. 10. AVALIAÇÃO DO MONITORAMENTO PARA DIFERENTES VALORES DE TIMEOUT EM UM CENÁRIO COM DE FALHAS. TABELA II CENÁRIO DO SEGUNDO EXPERIMENTO 4 03:39:40 03:40:31 00:00:51 8 03:55:33 03:56:21 00:00:48 Entretanto os valores de 45 s e 60 s segundos obtiveram resultados muito próximos na detecção de até oito processos. Também é possível observar uma estabilidade na detecção de falhas para o valor do timeout igual a 60 s. VIII. CONCLUSÃO Aplicações paralelas de alto desempenho são projetadas 12

para minimizar o tempo de execução, em geral, o padrão MPI de troca de mensagens tem sido utilizado para sua execução em diversas plataformas paralelas e distribuídas. Uma aplicação paralela pode necessitar de horas, dias ou meses de tempo de computação, sendo necessário protegê-la das falhas de componentes do cluster. O mecanismo de tolerância a falhas proposto mostrou-se eficiente na detecção de falhas da classe fail stop em aplicações paralelas que utilizam MPI, permitindo que as mesmas sejam reiniciadas em outro nó disponível do cluster para garantir a continuidade do processamento da aplicação na presença de falhas. Os processos Workers identificados como falhos foram excluídos logicamente do cluster e não tiveram mais blocos de dados enviados para processamento. Os blocos de dados enviados aos processos falhos foram recuperados do SATF e encaminhados ao próximo Worker disponível do cluster. A maior sobrecarga apresentada na solução aconteceu na camada de monitoramento quando o valor definido para o timeout foi muito baixo. Como trabalho futuro, uma análise mais aprofundada deve ser realizada em todos os experimentos com um maior número de nós. Uma estratégia hibrida de armazenamento e recuperação deverá ser adotada ao mecanismo, a fim de minimizar o tempo de reconfiguração do sistema, tratamento de falhas referente ao processo Master, isso poderá ser alcançado através dos backups armazenados no SATF. Por fim, o mecanismo de detecção de falhas proposto suporta múltiplas falhas ao mesmo tempo, se aproximando assim das reais situações de ocorrência de falhas em grandes clusters de computadores. REFERENCIAS BIBLIOGRÁFICAS [1] Sterling, Thomas L. Salmon, John. Becker, Donald J. e Savaresse, Daniel F. How to build a Beowulf: a guide to the implementation and aplication of PC clusters. Massachuset t s Institute of Technology. 1999. [2] Weber, Taisy Silva, Um roteiro para exploração dos conceitos básicos de tolerância a falhas. Apostila do Programa de Pós- Graduação Instituto de Informática - UFRGS. Porto Alegre, 2003. [3] CRISTIAN, F. A Rigorous Approach to Fault-Tolerant Programming. IEEE Trans. Softw. Eng., Piscataway, NJ, USA, v.11, n.1, p.23 31, 1985. [4] SCHNEIDER, F. B. Abstractions for Fault Tolerance in Distributed Systems. Ithaca, NY, USA: [s.n.], 1986. [5] GOLDBERG, D. et al. The Design and Implementation of a Fault- Tolerant Cluster Manager. Tech. Rep., Xerox Systems Institute, [S.l.], 2001. [6] LEANGSUKSUN, C. B. et al. Achieving high availability and performance computing with an HA-OSCAR cluster. Future Gener. Comput. Syst., Amsterdam, The Netherlands, The Netherlands, v.21, n.4, p.597 606, 2005. [7] BAGCHI, S. et al. Chameleon: software infrastructure for adaptive fault tolerance. IEEE Transactions on Parallel and Distributed Systems, [S.l.], v.10, p.560 579, 1999. [8] LAMPORT, L.; PEASE, M. The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst., New York, NY, USA, v.4, n.3, p.382 401, 1982. [9] COMPUTINA, I. et al. Algorithm-dependent Fault Tolerance for Distributed Computing. 2000. [10] KRISTLER, James J. 1990. Increasing File System Availability Through Second-Class Replication - Proceedings of the IEEE Workshop on Management of Replicated Data, (Nov. 1990), Houston, Texas. [11] SATYANARAYANAN, M. 1989. CODA: A Highly Available File System for a Distributed Workstation Environment Proceedings of the Second IEEE Workshop on Workstation Operating Systems, (Set.1989), Pacific Grove, California. [12] CODA 2012 - CODA File System. Disponível em http://www.coda.cs.cmu.edu/doc/html/coda-howto-1.html, (Jan. 2012). [13] DEITEL, Harvey M. e DEITEL, Paul J. e CHOFFNES,David R. Sistemas Operacionais Terceira Edição - Editora Pearson Prentice Hall, 2005. [14] Greve, F. G. P. (2005). Protocolos fundamentais para o desenvolvimento de aplicações robustas. SBRC 05. [15] Chen, W.; Toueg, S. & Aguilera, M. (2002). On the quality of service of failure detectors. IEEE Transactions on Computers, 51(5):561 580. [16] Gupta, I.; Chandra, T. D. & Goldszmidt, G. S. (2001). On scalable and efficient distributed failure detectors. In Proceedings of the 20 th annual ACM Symposium on Principles of Distributed Computing (PODC '01), pp. 170 179, New York, NY, EUA. ACM. [17] Chandra, T. D. & Toueg, S. (1996). Unreliable failure detectors for reliable distributed systems. Journal of the ACM, 43(2):225 267. [18] Hayashibara, N.; Défago, X.; Yared, R. & Katayama, T. (2004). The accrual failure detector. In Proceedings of the 2004 IEEE Symposium on Reliable Distributed Systems, pp. 66 78, Los Alamitos, CA, EUA. IEEE Computer Society [19] Satzger, B.; Pietzowski, A.; Trumler, W. & Ungerer, T. (2007). A new adaptive accrual failure detector for dependable distributed systems. In Proceedings of the 2007 ACM Symposium on Applied Computing (SAC '07), pp. 551 555, New York, NY, EUA. ACM. [20] Das, A., Gupta, I., and Motivala, A. (2002). Swim: scalable weaklyconsistent infectionstyle process group membership protocol. In Proc. International Conference on Dependable Systems and Networks DSN 2002, pages 303 312. [21] MPI FORUM. The MPI Message Passing Interface Standard. Knoxville: University of Tennessee, 1994. [22] T. M.-I. Committee. Mpi-io: A parallel file i/o interface for mpi version 0.5, 1996. [23] Juliano C. Vacaro, Taisy S. Weber, Injeção de Falhas na Fase de Teste de Aplicações Distribuídas. XX Simpósio Brasileiro de Engenharia de Software. 2006 - Florianópolis, SC, Brasil. [24] Stelling, P., DeMatteis, C., Foster, I., Kesselman, C., Lee, C., von Laszewski, G. A fault detection service for wide area distributed computations. Cluster Computing 2 (1999), 117 128. 13