1 / 28

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

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.

ilyssa
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related