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

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

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

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. p DFp Lista de suspeitos q DFq Introdução - Solução • Pergunte a um oráculo!!! rede q q r 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.