Uma Introdução a Detectores de Defeitos para Sistemas Assíncronos

Apresentação em tema: "Uma Introdução a Detectores de Defeitos para Sistemas Assíncronos"— Transcrição da apresentação:

1 Uma Introdução a Detectores de Defeitos para Sistemas Assíncronos
Élder Bernardi

2 Roteiro Introdução Failure Detectors (FDs)
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

3 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.

4 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.

5 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.

6 Introdução - Solução Pergunte a um oráculo!!! rede p DFp
Lista de suspeitos q q q r DFq q

7 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!!

8 Propriedades de um FD Completude (Completeness) Precisão (Accuracy)

9 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.

10 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.

11 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.

12 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

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

14 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)

15 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.

16 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.

17 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.

18 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.

19 Algoritmo do FD para o problema do consenso

20 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

21 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.

22 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

23 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.

24 FD para NBAC Transformar num problema de consenso

25 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

26 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

27 Heartbeat Protocol

28 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.