Uma Introdução a Detectores de Defeitos para

Sistemas Assíncronos

Élder Bernardi

Roteiro

Introdução Sistemas síncronos e assíncronos

Failure Detectors (FDs) Problemas que demandam FDs e suas

soluções Consenso Non-blocking Atomic Commit Quiescent Communication

Considerações finais

Introdução - Sistemas Assíncronos

Em sistemas assíncronos, não existe um limite de tempo para que um processo execute uma determinada tarefa, ou para que uma mensagem seja enviada ou recebida dentro de um certo tempo.

A combinação entre defeito de processos e sistemas assíncronos cria um contexto no qual um processo não sabe se outro processo falhou ou não.

Introdução - Exemplo

Seja p e q dois processos assíncronos que se comunicam, para o processo p, o problema está em saber o processo q falhou ou não: Processo p pode parar esperando uma

mensagem de q, entretanto esta mensagem não chegará pois o processo q parou.

Caso p pense que o processo q parou, no entanto o problema foi apenas a demora no envio da mensagem pela rede.

Introdução - Sistemas Síncronos Em sistemas síncronos, é relativamente

simples a detecção de um defeito de um determinado processo.

Se o processo p pára em um instante t, então em um instante (t + timeout) todos os processos saberão que p parou.

Introdução - Solução

q

p

DFp

DFq

q

Lista de suspeitosq rq rede

rede

Pergunte a um oráculo!!!

Introdução – Detectores de Defeitos Um Failure Detector (FD) é um oráculo que

tenta adivinhar o status operacional de outros processos.

No entanto, Estas dicas podem ser incorretas. O oráculo pode “mudar de opinião” sobre o status

operacional de um processo. Protocolos de detecção de defeitos devem existir!!

Propriedades de um FD

Completude (Completeness) Precisão (Accuracy)

Classificação quanto a completude Forte: Qualquer processo falho em algum

momento é suspeitado permanentemente por todos os processos corretos.

Fraca: Qualquer processo falho em algum momento é suspeitado permanentemente por algum processo correto.

Classificação quanto a precisão Forte: Qualquer processo correto nunca é

apontado suspeito de falha por algum outro processo

Fraca: Algum processo correto nunca é suspeito de falha

Event Forte: Depois de certo tempo, qualquer processo correto não é apontado (suspeito) de falha por algum outro processo.

Event Fraco: Depois de certo tempo, algum processo correto não será suspeito por algum outro processo.

Questões sobre implementação Devem ser tão simples quanto a necessidade

da aplicação Evitar overhead, funções desnecessárias.

Recomenda-se que seja um sub-sistema síncrono que NÃO interfera e nem possa ser acessado diretamente pelo sistema principal. Funciona como um oráculo somente.

Modelos de Sistemas Assíncronos Abordados FLP - processos propensos a defeitos e

links de comunicação confiáveis FLL – processos propensos a defeitos e links

de comunicação não confiáveis

Problemas abordados pelo artigo Problema do Concenso Efetivação Atômica Não Bloqueante Comunicação inerte

Problema do Consenso

Considera um cenário FLP Permite que vários processos atinjam

decisões em comum. cada processo Pi propõe um único valor vi. todos os processos interagem para a troca

de valores. em algum momento, os processos entram no

estado “decidido” em que atribuem um valor para a variável de decisão di (que não é mais alterada)

Impossibilidade

A impossibilidade de consenso em sistemas assíncronos com defeitos foi apresentada em 1985 por Fischer.

Devido às incertezas no envio e na entrega das mensagens, é impossível distinguir entre um processo que falhou ou um que está muito lento.

Resolução do Problema do Consenso O problema da impossibilidade da resolução

do consenso em sistemas assíncronos com defeitos foi resolvido através da utilização de detectores de defeitos.

Cada processo do grupo terá associado a ele um detector de defeitos, que irá informar se um determinado processo está ou não com defeito.

Classificação do Algoritmo

Classe S Abrangência Forte: Em algum momento, todos os

processos falhos serão considerados suspeitos por todos os processos corretos.

Exatidão fraca eventual: Depois de um certo tempo, o detector garante a exatidão fraca.

Resolução do consenso Para chegar-se ao consenso, o algoritmo é executado por um

número indefinido de rodadas, onde em cada rodada um dos N processos faz o papel do coordenador.

Cada processo decide o seu valor vi e envia para o coordenador.

O coordenador verifica o valor que mais se repetiu e atribui a uma variável g.

Em cada processo Pi pode acontecer: Recebe do coordenador o valor g -> adota como seu

novo valor e retorna um ack para o coordenador. Ou o DF de Pi suspeita que o coordenador falhou, e

manda um nack para C. O algoritmo termina quando o coordenador recebe

(n+1)/2 acks. Então, ele faz um multicast confiável para os processos informando o novo valor.

Algoritmo do FD para o problema do consenso

Efetivação Atômica não Bloqueante

Problema típico de banco de dados para garantir a propriedade de atomicidade;

Um dos mais antigos problemas conhecidos na computação distribuída

NBAC - Funcionamento É iniciado ao fim de uma computação

distribuída (uma transação) com o objetivo de coletar a intenção de cada participante em validar (votar sim) ou anular (votar não) um conjunto de ações já realizadas.

O resultado da transação depende dos votos coletados: COMMIT - A transação é validada se tudo correr

bem; ABORT - Se pelo menos um processo vota em

não.

NBAC - Propriedades NBAC_Terminação: Todos os processos corretos

eventualmentem decidem; NBAC_Integridade: Um processo decide no máximo

uma vez; NBAC_Acordo_Uniforme: Dois processos não

decidem diferentemente; NBAC_Validade: A Decisão é COMMIT ou ABORT,

salvo: NBAC_Justificativa: Se um processo decide COMMIT é

porque todo mundo votou SIM NBAC_Obrigação: Se todos votaram Sim e não existem

falhas então a decisão é COMMIT

NBAC – Resultados Teóricos

Problema NBAC não tem solução num modelo assíncrono FLP, mesmo se ele é estendido com detectores de defeitos.

Na verdade, é mais difícil de resolver que o problema do concenso

Mesmo parecendo similares o concenso aceita qualquer valor proposto como valor de decisão, a confirmação atômica tem restrição quanto ao valor a ser decidido, em especial, caso não ocorram falhas, a decisão deverá ser necessáriamente COMMIT.

FD para NBAC

Transformar num problema de consenso

Comunicação inerte (Quiescent Communication) Considera-se dois processos Pi e Pj:

Ambos não entram em crash Porém estão num modelo FLL

O problema encontra-se na camada de comunicação Solução: Construir uma camada de comunicação

confiável sobre uma não confiável Implementar FLP sobre FLL

Solução

Implementar mecanismos de retransmissão e acknowledgement através de um FD Porém tal FD não pode ser implementado sobre

um sistema FLL Protocolo Heartbeat FD implementa uma

camada FLD

Heartbeat Protocol

Considerações Finais

Detectores de Falha permitem que problemas sem solução em caso de falha de um processo passam a ser solúveis

Designados para sistemas assíncronos Funcionam como módulos auxiliares Em sistemas síncronos:

Permitem a diminuição da complexidade do tempo de espera ao limite mais baixo possível.