Improving the Robustness of Distributed Failure Detectors in Adverse Conditions

(1)

Abstract— Failure detection is at the core of most fault tolerance strategies, but it often depends on reliable communication. We present new algorithms for failure detectors which are appropriate as components of a fault tolerance system that can be deployed in situations of adverse network conditions (such as loosely connected and administered computing grids). It packs redundancy into heartbeat messages, thereby improving on the robustness of the traditional protocols. Results from experimental tests conducted in a simulated environment with adverse network conditions show significant improvement over existing solutions.

Keywords— Fault Tolerance, Failure Detection, Distributed Failure Detectors.

I. INTRODUÇÃO

ISTEMAS distribuídos possuem características que permitem que aplicações continuem em execução mesmo na presença de falhas. Se uma falha ocorre em um nó em um ambiente computacional distribuído, é possível que a aplicação que neste executa não seja terminada imediatamente ou até mesmo que os outros nós computacionais não percebam a falha [1]. A detecção de falhas permite a implementação de muitas das técnicas populares de tolerância a falhas que se beneficiam das propriedades destes sistemas.

Grades computacionais são soluções para o problema da distribuição e uso de recursos computacionais de forma controlada e coordenada entre diversas organizações virtuais. Integram estes sistemas distribuídos: unidades computacionais de alto desempenho como clusters de computadores e supercomputadores, recursos de armazenamento, arquiteturas computacionais especializadas e instrumentos científicos, todos conectados por diversas redes. Grades maximizam a utilização dos recursos através de seu compartilhamento entre organizações e domínios administrativos frequentemente conectados por redes de longa distância, respeitando políticas de uso de recursos [2].

Abordagens tradicionais de detecção de falhas baseadas em heartbeats dependem de conectividade de rede que possibilite o recebimento de pacotes em intervalos de tempo relativamente constantes, o que é um requisito facilmente atendido em clusters de computadores. Nestes clusters, os nós estão frequentemente conectados por fibra ótica ou

F. T. C. Lemos, Universidade de São Paulo (USP), São Paulo, SP, Brasil, [email protected]

L. M. Sato, Universidade de São Paulo (USP), São Paulo, SP, Brasil, [email protected]

equipamentos de rede de qualidade e são mantidos em ambientes cuidadosamente monitorados. Neste cenário, os nós são tipicamente dedicados a execução de tarefas distribuídas e problemas de infra-estrutura são incomuns.

Devido à pouca monitoração e controle existente em grades computacionais, as condições em que os nós são mantidos e monitorados tradicionalmente se distanciam do ideal. Grades podem ser compostas por hardware disponível a consumidores finais off-the-shelf e recursos não dedicados. Diferentes instalações são frequentemente conectadas por redes de longa distância e enlaces que apresentam perda.

Como uma consequência destas propriedades, detectores de falha tradicionais apresentam desempenho inferior nestes ambientes. Quando detectores de falha cometem erros, escalonadores da grade podem realizar escolhas ruins ao associar tarefas a nós na grade. Em um caso ainda mais grave, tarefas em execução podem ser interrompidas e reiniciadas se um nó é incorretamente considerado falho.

Neste artigo introduzimos novos algoritmos para detectores de falha distribuídos que trazem redundância adicional em cada mensagem heartbeat. O conceito é aplicado a um simples detector multicast e também a um algoritmo adaptativo e testes experimentais são realizados para efeito de comparação das estratégias.

II. DETECÇÃO DISTRIBUÍDA DE FALHAS

Detectores de falhas distribuídos são módulos de detecção que monitoram um subconjunto de processos no sistema, mantendo uma lista dos processos atualmente suspeitos de estarem falhos [3]. Os módulos podem realizar detecções incorretas ao adicionar processos não-falhos à lista de processos suspeitos ou vice-versa. Um detector de falhas pode em um momento posterior identificar seu erro e tomar as ações apropriadas para revertê-lo. Diferentes módulos de detecção de falhas podem apresentar diferentes e até mesmo conflitantes visões do estado dos outros detectores na rede em qualquer dado instante.

Detectores podem ser categorizados em duas políticas de interação distintas: o modelo push e o modelo pull [4]. Os detectores de falhas apresentados neste artigo seguem o modelo push. Neste modelo, um detector de falhas periodicamente envia mensagens heartbeat para outros detectores. Após um intervalo de timeout ∆to, caso o detector p não tenha recebido uma mensagem do detector q, p deve adicionar o detector q a sua lista de detectores suspeitos. Se em algum momento posterior p venha a receber uma mensagem de q, conclui que este não está falho e o remove de sua lista de detectores suspeitos.

S

F. T. C. Lemos and L. M. Sato

Improving the Robustness of Distributed Failure

Detectors in Adverse Conditions

(2)

A. Protocolos gossip tradicionais

Detectores podem diferir quanto ao destino de mensagens heartbeat enviadas. Uma estratégia pode ser o envio de mensagens através de um canal multicast, de forma que todos os outros detectores no mesmo domínio de monitoração possam recebê-las e processá-las. Uma abordagem diferente é o envio periódico destas mensagens a detectores específicos. Mensagens enviadas a detectores individuais carregam redundância adicional ao incluir a lista de detectores conhecidos pelo remetente. Protocolos que operam desta maneira são conhecidos como protocolos gossip [5].

No algoritmo gossip original [6], cada detector escolhe um detector aleatório de sua lista de detectores conhecidos e o envia uma mensagem heartbeat. Como o protocolo não é determinístico, enganos podem acontecer a menos que grandes intervalos de timeout sejam utilizados, o que se traduz em um aumento no tempo necessário para a detecção de uma falha. Protocolos diferentes têm sido elaborados para conferir maior previsibilidade ao algoritmo, garantindo que todos os detectores sejam contatados em intervalos regulares [7]. Estas modificações, porém, trazem o requisito adicional de que os detectores devem concordar sobre o número de detectores disponíveis no domínio de monitoração e sobre sua ordem relativa a estes. Caso este requisito não seja atendido, as expectativas de parte dos detectores não serão atendidas, levando a detecções incorretas. Enquanto é possível que os detectores negociem esta informação, dispensando a necessidade de configuração manual prévia, este complexo processo é lento e pode se tornar custoso em um ambiente como grades com rápidas mudanças de topologia.

B. Protocolos adaptativos

Para garantir uma boa qualidade de serviço em um ambiente dinâmico, diversos graus de adaptabilidade podem ser implementados. Detectores adaptativos alteram seus parâmetros para se adequar às condições de rede e atender aos requisitos das aplicações que executam no sistema [8]. Escolhemos implementar um simples algoritmo adaptativo para os testes experimentais apresentados neste artigo.

O detector adaptativo implementado utiliza o algoritmo de Jacobson para o cálculo do timeout de retransmissão do TCP [9] como uma função de avaliação. Quando uma mensagem é recebida, o intervalo até a próxima recepção é estimado. Este intervalo é então considerado o próximo intervalo de timeout (∆to) para o detector associado. A função de avaliação leva em consideração o intervalo entre as duas últimas recepções (R) para estimar a recepção da próxima mensagem:

Esta adaptação permite que o intervalo de timeout ∆to seja aproximado do intervalo de heartbeat ∆i se as mensagens forem recebidas com atraso razoavelmente constante. Se o detector adaptativo não receber as mensagens de heartbeat

com suficiente periodicidade, porém, o tempo necessário para a detecção de uma falha será amplificado, já que a função de avaliação reagirá à variação aumentando o intervalo de timeout.

C. A robustez dos algoritmos existentes

Detectores de falha dependem da recepção de mensagens heartbeat para evitar detecções incorretas. É necessário cautela ao empregar timeouts para evitar que estes sejam curtos demais, ou detecções falsas podem ocorrer. Por outro lado, se os timeouts são demasiadamente longos, o grande intervalo entre um incidente e sua detecção pode prejudicar a utilidade do sistema de detecção.

Este balanço pode ser em parte mitigado pela utilização de detectores de falha adaptativos. Em condições adversas da rede, porém, detectores adaptativos tendem a superestimar os intervalos de recebimento de mensagens heartbeat futuros, causando qualidade de serviço insatisfatória. Adicionalmente, não há garantia de que as condições de rede identificadas pelo detector serão mantidas para as próximas detecções. Neste sentido, a configuração de parâmetros de adaptação requer conhecimento prévio sobre a rede para a obtenção de resultados ótimos.

Detectores gossip podem ser modificados para que se tornem menos sensíveis a adversidades com a introdução de redundância adicional. Como exemplo, detectores que implementam o protocolo Double Binary Round-Robin [7], enviam mais mensagens heartbeat do que seria necessário para a formação do grafo conectado dos nós. Isto reduz a probabilidade de falha de detecção no caso de falhas de alguns detectores, mas o requerimento de que os detectores concordem sobre o número e ordem dos nós é muitas vezes inatingível em ambientes com constantes alterações.

III. INTRODUZINDO O GOSSIP PAYLOAD

Apresentamos nesta seção uma proposta de algoritmo visando prover a detectores de falha maior resistência a condições adversas de infra-estrutura. Isto é atingido com a introdução de redundância nas mensagens heartbeat enviadas pelos detectores com o carregamento da lista de detectores conhecidos em cada mensagem. Este conceito se assemelha ao funcionamento de protocolos gossip tradicionais, porém o aplicamos a detectores baseados em comunicação multicast. Chamamos este conteúdo adicional em cada mensagem heartbeat de gossip payload.

A. Implementação

A estrutura básica do detector multicast está apresentada no Algoritmo 1. Os detectores são inicializados com listas vazias que conterão os outros detectores descobertos pelo protocolo (lista de peers) e de detectores considerados suspeitos de estarem falhos. Enquanto os detectores podem ser descobertos automaticamente pelo protocolo e adicionados à lista de peers, nossa implementação também permite ao administrador que uma lista de detectores seja configurada manualmente, visando acelerar o processo de detecção.

(3)

Algoritmo 1. Estrutura básica do detector multicast simples.

O detector envia mensagens heartbeat a cada intervalo ∆i na Tarefa 1 através de um canal multicast. Estas mensagens contêm a identificação da fonte e um número de sequência associado à mensagem. Se o gossip payload está sendo utilizado, informações sobre cada detector conhecido por p devem ser adicionadas à mensagem. Esta informação consiste do identificador e crença sobre o estado (suspeito ou não) de cada detector. A utilização de números sequenciais permite que o algoritmo funcione mesmo caso os relógios locais dos detectores não estejam sincronizados.

O identificador do detector deve identificá-lo unicamente entre todos os detectores no domínio de monitoração. Em nossa implementação, escolhemos utilizar o domínio qualificado de cada nó (FQDN) como o identificador de detector, já que este identificador, além de único, normalmente pode ser associado a um endereço de rede. Identificadores mais compactos devem ser utilizados caso haja interesse em reduzir o consumo de banda do protocolo.

Na recepção de uma mensagem heartbeat, o detector armazena o horário de recepção na Tarefa 2. O procedimento visto é invocado para o detector que originou a mensagem assim como para cada outro detector enviado no gossip payload da mensagem. Este procedimento, mostrado no Algoritmo 2, recebe como argumentos o identificador do

detector, número de sequência associado à mensagem, a crença sobre estado do detector e um horário de recebimento da mensagem. O detector que originou a mensagem nunca é considerado suspeito, já que sua mensagem foi recebida. Para os outros detectores, a informação sobre seu estado é obtida na lista de detectores da mensagem heartbeat.

A Tarefa 3 consiste em adicionar detectores à lista de detectores suspeitos de estarem falhos e reiniciar a sequência do detector após o timeout de limpeza. Caso um número de sequência não tenha sido recebido após o intervalo de timeout ∆to, o detector associado passa a ser considerado suspeito. Se após um intervalo de limpeza ∆cl o detector não tenha recebido informações atualizadas sobre um detector suspeito, o número de sequência associado ao detector suspeito é reinicializado para zero.

A transmissão dos horários nas mensagens simplificaria o algoritmo, mas implicaria na necessidade de relógios locais sincronizados. Por esse motivo, números de sequência são utilizados. Mensagens diferentes de um mesmo detector podem, porém, conter um mesmo número de sequência caso o detector que emite a mensagem seja reiniciado no período entre o envio das mensagens. Para resolver este problema, um intervalo de limpeza ∆cl é utilizado. Se um detector p não recebe uma mensagem de um detector suspeito q por um intervalo ∆cl, passa a acreditar que q está inequivocadamente falho e reinicia o número de sequência associado a q.

Algoritmo 2. Procedimento visto para o detector multicast simples.

O procedimento visto apresentado no Algoritmo 2 é responsável pela atualização da crença sobre o estado dos outros detectores por parte de um detector, reunindo as informações previamente coletadas de mensagens heartbeat. Se o detector q é conhecido por p, a nova informação será integrada na visão de p, mas apenas caso o número de sequência associado a q nesta informação seja superior ao

(4)

número de sequência associado à informação que p possui. Isto previne que p atualize o último recebimento de informações ult_visto(q) caso processe dados que não contribuam na atualização das crenças sobre o estado de q. Se a informação traz mudanças para as crenças de p, uma notificação de detecção é gerada.

No procedimento visto, se o detector q não é conhecido por p, este é adicionado à lista de peers de p apenas caso a informação descreva q como um peer não-suspeito. Isto permite que o algoritmo funcione com configuração mínima, já que os detectores são descobertos conforme os heartbeats são recebidos, o que é uma característica importante em ambientes dinâmicos tais como grades computacionais.

B. Gossip payload para detectores adaptativos

A utilização do conceito de gossip payload para detectores multicast pode ser transportada para detectores adaptativos com modificações simples. Apresentamos brevemente as modificações necessárias para a utilização do conceito em um detector multicast adaptativo.

A Tarefa 2 deve ser alterada para que seja passado um parâmetro extra ao procedimento visto. Este parâmetro deve informar se a chamada está sendo realizada com referência ao detector que originou a mensagem sendo processada ou se o detector referenciado foi encontrado na lista de detectores trazida na mensagem. Esta distinção é importante, já que um detector adaptativo não deve considerar informações indiretas ao estimar futuras recepções diretas de heartbeats.

Um detector irá verificar se o número de sequência associado a um peer deve ser reiniciado para zero apenas se o este for considerado suspeito. Isto é de especial importância em detectores adaptativos, já que o intervalo de timeout pode exceder o intervalo de limpeza de acordo com a estimação da função de avaliação. Se o número de sequência associado a um detector é reiniciado enquanto este detector ainda não tenha sido adicionado à lista de detectores suspeitos, uma recepção de heartbeat posterior pode trazer informações indiretas sobre o detector reiniciado. Isto causaria a identificação incorreta de uma atualização sobre o estado do detector reiniciado, prevenindo que certas detecções ocorram.

IV. MODELO DE ADVERSIDADES

Um modelo de adversidades foi elaborado para simular um ambiente justo para a comparação de diferentes estratégias de detecção de falhas. Uma rede congestionada conectando detectores sujeitos a falhas é simulada. Os seguintes conceitos são recriados no modelo de adversidades:

• Perda de pacotes • Atraso da rede • Falha dos detectores

Perda de pacotes se refere à perda de pacotes de rede antes que estes possam alcançar seu destino. Na prática, a perda de pacotes resulta tipicamente da degradação do sinal no meio da rede, de equipamentos de rede defeituosos ou de congestionamento na rede. No modelo de adversidades, a perda de pacotes é configurada como uma probabilidade de

que qualquer pacote de rede seja perdido antes do seu processamento pelo destinatário. A probabilidade de perda de pacotes é verificada em duas situações: enquanto o pacote se encontra na fila de envio enquanto o pacote se encontra na fila de recepção, anterior ao seu processamento.

Atraso de rede é o atraso médio na rede em que se encontram os nós e pode resultar da utilização de conexões de longa distância ou de retransmissões causadas pela perda de pacotes. No modelo de adversidades, o atraso é especificado como um intervalo de tempo fixo e uma variação aleatória limitada a uma margem. Este atraso é aplicado nas filas de recebimento e envio do sistema operacional de cada nó.

O modelo pode ser configurado para simular perda de pacotes e atraso de rede em rajadas. Com rajadas, a probabilidade de que um pacote seja perdido depende parcialmente na probabilidade obtida para os eventos anteriores. De maneira similar, a variação no atraso da rede depende parcialmente da variação do atraso empregada anteriormente. No modelo, rajadas são configuradas como uma porcentagem indicando a importância dada na obtenção de novos aleatórios a valores escolhidos anteriormente.

Perda de pacotes e atraso de rede são simulados utilizando o software netem, parte da suíte de software iproute2 para Linux. O Intermediate Functional Block é utilizado para aplicar o cenário de rede na fila de recebimento de pacotes.

O modelo de adversidades simula também falhas dos detectores. Estas falhas buscam se assimilar a falhas ocorridas devido a problemas no software detector de falhas (situações levando a terminação anormal dos programas) ou falhas relacionadas ao ambiente em que os detectores de falhas executam (como falhas do hardware ou sistema operacional). A cada 25 segundos, o modelo reconsidera se cada detector que está em execução deve ser terminado e se cada detector terminado deve ser recuperado. Um detector pode ser recuperado apenas se este foi terminado há um intervalo de tempo superior ou igual ao intervalo de limpeza ∆cl. Probabilidades de falha e recuperação de detectores são configuráveis.

O gerador de números pseudo-aleatórios (PRNG) utilizado para determinar a ocorrência de falhas e recuperação é inicializado com uma semente fixa para prover um ambiente justo para os diferentes detectores. O PRNG utilizado para determinar os parâmetros de perda de pacotes e atraso na rede é inicializado com entropia do sistema operacional de cada nó. Todos os testes são executados múltiplas vezes para contabilizar esta variação.

Três diferentes configurações são utilizadas para simular diferentes níveis de carga na infra-estrutura da rede simulada. Estas configurações estão detalhadas na Tabela I.

TABELA I

CONFIGURAÇÕES DO MODELO DE ADVERSIDADES

Configuração Parâmetros Valores

Baixa carga

Probabilidade de perda de pacotes Rajada na perda de pacotes Atraso da rede

Rajada no atraso da rede

5% Sem rajada 15ms ± 5ms Sem rajada

(5)

Probabilidade de falha do detector Probabilidade de recuperação do detector

5% 70%

Média carga

Rajada no atraso da rede Probabilidade de falha do detector Probabilidade de recuperação do detector

10% 10% 50ms ± 15ms 5% 7% 65% Alta carga

Rajada no atraso da rede Probabilidade de falha do detector Probabilidade de recuperação do detector

20% 15% 100ms ± 25ms 10% 10% 60% V. AMBIENTE DE TESTES

Resultados foram obtidos pela comparação entre as notificações de falhas enviadas pelos detectores de falhas e a informação real do estado dos detectores.

Esta seção apresenta o ambiente no qual os testes foram realizados. As métricas utilizadas para analisar o desempenho dos detectores também são apresentadas.

A. Ambiente de testes

Os testes foram conduzidos em uma rede de 8 máquinas virtuais utilizando sistema operacional Debian 6.0.2 (kernel Linux 2.6.32). As notificações de falhas são enviadas a um coletor localizado no sistema hospedeiro.

Cada máquina virtual é configurada com duas interfaces de rede. Uma destas interfaces permite à máquina comunicar-se com o sistema hospedeiro, enquanto a outra conecta as máquinas virtuais em rede. Apenas a interface conectada à rede virtual é afetada pelo modelo de adversidade. Todas as notificações de falhas são recebidas normalmente.

Os detectores são configurados da seguinte maneira. O intervalo de heartbeat (∆i) é configurado para 5s, e o intervalo de timeout (∆to) é configurado para 10s. O intervalo de

limpeza (∆cl) é configurado em 30s. Os parâmetros para a

estimação adaptativa são 1/8 para o ganho da média (α), 1/4 para o ganho do desvio de média (β) e 4 para a influência do desvio (γ), mesmos parâmetros usados para a implementação original do timeout de retransmissão TCP/IP [10].

B. Métricas

O objetivo dos testes é determinar o desempenho dos algoritmos modificados apresentados neste artigo em comparação com as abordagens tradicionais. Em cada ciclo de testes, os parâmetros são acumulados na medida em que o sistema hospedeiro recebe as notificações de falha.

A qualquer momento, o estado real do sistema é o conjunto dos estados reais (terminado ou em execução) de cada detector na rede simulada. O estado detectado do sistema é o conjunto dos estados dos detectores na rede de acordo com a visão de um detector específico.

Um engano é uma detecção incorreta de falha recebida em uma notificação. Um incidente é um evento real de falha ou recuperação de um dado detector. A duração de um engano é um intervalo de tempo entre o engano e sua reversão, que pode ser consequência de uma correção ou de outro incidente.

Uma detecção é uma reação de um dado detector a uma falha real de outro detector. Tempo de detecção é o intervalo de tempo entre uma falha real e sua detecção.

As seguintes métricas são coletadas: • Número de enganos

• Duração média de enganos (DME) • Tempo médio de detecção (TMD)

O número de enganos é de especial interesse para a tolerância a falhas, já que um trabalho em curso pode ser abortado por detecções falsas. De maneira similar, um trabalho pode ser associado a um detector falho detectado incorretamente como operacional.

VI. RESULTADOS

Os testes foram realizados com quatro diferentes detectores de falhas:

• Multicast simples (MS)

• Multicast simples com gossip payload (MSG) • Multicast adaptativo (MA)

• Multicast adaptativo com gossip payload (MAG)

As informações apresentadas nas Tabelas II, III e IV mostram os resultados obtidos com as configurações de baixa, média e alta carga, respectivamente. Para cada detector, cinco ciclos de execução foram realizados e a média e desvio padrão de cada métrica são apresentadas.

TABELA II

RESULTADOS NA CONFIGURAÇÃO DE BAIXA CARGA

Detector Enganos DME TMD

MS 61,60 ± 5,28 0,86 ± 0,38s 2,87 ± 0,19s MSG 3,80 ± 1,17 13,20 ± 4,70s 8,89 ± 2,93s MA 48,20 ± 4,17 3,20 ± 0,70s 4,04 ± 0,52s MAG 19,80 ± 4,07 7,46 ± 3,62s 21,02 ± 4,23s

Como é possível observar na Tabela II, a utilização do gossip payload leva a significante redução no número de enganos devido à redundância adicional. A redução na duração média de enganos e tempo médio de detecção nos detectores que não utilizam o gossip payload é uma consequência do grande número de pequenos enganos cometidos pelos algoritmos que não apresentam redundância, causados principalmente pela perda de pacotes.

TABELA III

RESULTADOS NA CONFIGURAÇÃO DE MÉDIA CARGA

Os resultados na configuração de média carga são similares, como pode ser visto na Tabela III. A duração média dos enganos é consideravelmente maior para o detector multicast simples, possivelmente devido à introdução de rajadas de perda de pacotes e maior atraso na rede. O número de enganos permanece menor para os detectores que utilizam o gossip payload. Os detectores adaptativos mostram melhor

(6)

desempenho neste cenário em comparação ao cenário anterior em relação ao número de enganos. Isso pode ser explicado pela alimentação de dados mais estáveis à função de avaliação do estimador devido às rajadas.

TABELA IV

RESULTADOS NA CONFIGURAÇÃO DE ALTA CARGA

A Tabela IV apresenta os resultados na configuração de alta carga. Como as condições de rede se tornam mais inóspitas, o número de enganos aumenta para todos os detectores. O número de enganos com detectores utilizando o gossip payload ainda é significantemente menor. Para detectores adaptativos, o ganho trazido por rajadas não é suficiente para balancear as perdas de heartbeats, fazendo com que detectores adaptativos apresentem um desempenho inferior à configuração anterior.

VII. CONCLUSÃO E TRABALHOS FUTUROS

Com base nos resultados expostos, conclui-se que a introdução do gossip payload em detectores simples ou adaptativos traz significantes melhorias em comparação aos protocolos tradicionais. Em especial, o número de enganos é reduzido com as modificações propostas, levando a um sistema de detecção de falhas consideravelmente mais estável. Estas melhorias são atribuídas à redundância adicional trazida pela distribuição do estado detectado do sistema.

Considerada a importância de um baixo número de enganos em sistemas tolerantes a falhas, é possível concluir que a redundância adicional proporcionada pelos algoritmos propostos os torna adequados a condições adversas de infra-estrutura como as condições encontradas em grades computacionais.

Detectores adaptativos não apresentam bom desempenho em tais cenários, já que são particularmente sensíveis a perda de pacotes e à variação do atraso da rede. É possível que resultados mais favoráveis possam ser obtidos após uma revisão dos parâmetros utilizados na configuração do protocolo adaptativo. Os resultados apresentados mostram que a adaptação contribui para uma pequena redução no número de enganos. Também é possível constatar que a introdução do gossip payload neste tipo de protocolo resulta em significante redução no número de enganos.

Técnicas como o processamento de notificações de falha podem ser utilizadas em conjunto com os protocolos apresentados neste artigo. Estudos futuros podem revelar a influência de tais medidas com relação ao desempenho dos detectores de falhas apresentados.

Os algoritmos apresentados neste artigo são parte de uma arquitetura completa de detecção de falhas especialmente adequada para grades computacionais, incluindo detectores de

falha distribuídos, detectores de falha locais, gerenciadores de falha e ferramentas auxiliares.

REFERÊNCIAS

[1] P. Stelling, C. Dematteis, I. Foster, C. Kesselman, C. Lee, and G. Laszewski, “A fault detection service for wide area distributed computations,” Cluster Computing, vol. 2, pp. 117-128, 1999.

[2] I. Foster, C. Kesselman, and S. Tuecke, “The anatomy of the grid: Enabling scalable virtual organizations,”, International Journal of High

Performance Computing Applications, vol. 15, no. 3, p. 200, 2001.

[3] T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” Journal of the ACM, vol. 43, pp. 225-267, March 1996.

[4] N. Hayashibara, A. Cherif, and T. Katayama, “Failure detectors for large-scale distributed systems,” 2002. Conference of the IEEE

Computer and Communications Societies, March, 2004.

[5] X. Défago, N. Hayashibara, and T. Katayama, “On the design of a failure detection service for large scale distributed systems,” in

Proceedings of the International Symposyum Towards Peta-Bit Ultra-Networks. Citeseer, 2003, pp. 88-95.

[6] R. Van Renesse, Y. Minsky, and M. Hayden, “A gossip-style failure detection service,” in Proceedings of the Middleware Conference. Citeseer, 1998.

[7] S. Genaud and C. Rattanapoka, “Fault management in P2P-MPI,” in

International Journal of Parallel Programming. Springer, 2009.

[8] M. Bertier, O. Marin, and P. Sens, “Implementation and performance evaluation of an adaptable failure detector,” in Proceedings of the

International Conference on Dependable Systems and Networks, pp.

354-363, 2002.

[9] V. Jacobson, “Congestion avoidance and control,” in ACM SIGCOMM

Computer Communication Review, vol. 18, no. 4. ACM, 1988, pp.

314-329.

[10] W. Stevens and G. Wright, TCP/IP Illustrated: the protocols. Addison-Wesley, 1994.

Fernando Tarlá Cardoso Lemos recebeu seu título de Tecnólogo em Processamento de Dados pela Faculdade de Tecnologia de São Paulo (FATEC-SP) em 2009, quando foi homenageado pela Sociedade Brasileira de Computação como aluno destaque. Atualmente é aluno do programa de Mestrado em Engenharia Elétrica no Departamento de Engenharia da Computação e Sistemas Digitais (PCS) da Escola Politécnica da Universidade de São Paulo.

Liria Matsumoto Sato possui graduação em EESC pela Universidade de São Paulo (1977), mestrado em Engenharia Eletrônica e Computação pelo Instituto Tecnológico de Aeronáutica (1983) e doutorado em Engenharia Elétrica pela Universidade de São Paulo (1989). Atualmente é Professora Associada da Universidade de São Paulo. Tem experiência na área de Ciência da Computação, com ênfase em Sistemas de Computação. Atuando principalmente nos seguintes temas: Alto Desempenho, Cluster de Computadores, Linguagens e Ferramentas de Programação Paralela, Grades Computacionais.