24/05/1999Non-Blocking Atomic Commitment1 in Distributed Systems Faculdade de Ciências da Universidade de Lisboa Mestrado 98/99 Tolerância a Faltas em.

Apresentação em tema: "24/05/1999Non-Blocking Atomic Commitment1 in Distributed Systems Faculdade de Ciências da Universidade de Lisboa Mestrado 98/99 Tolerância a Faltas em."— Transcrição da apresentação:

1 24/05/1999Non-Blocking Atomic Commitment1 in Distributed Systems Faculdade de Ciências da Universidade de Lisboa Mestrado 98/99 Tolerância a Faltas em Sistemas Distribuídos Sofia Alves Bruno Mendonça Lisboa 24 de Maio de 1999

2 24/05/1999Non-Blocking Atomic Commitment2 Introdução Alguns conceitos no contexto da apresentação : - Sistema Distribuídos Síncronos e Assíncronos - Transacção : manipulação coerente de dados que apresenta atomicidade de concorrência e de falha. - Atomic Commitment : acordo atómico, realizado à custa de transacções. - P. Non-Blocking: protocolos que asseguram que uma transacção acabe mesmo num cenário que contenha falhas. Esta apresentação foca o problema do NBAC e os protocolos que o resolvem tanto em sistemas distribuídos síncronos como em assíncronos

3 24/05/1999Non-Blocking Atomic Commitment3 NBAC Non-Blocking Atomic Commitment Introdução Protocolos non-blocking necessitam que o sistema dê garantias sobre detecção de falhas : - Sistemas síncronos usam timeouts: - S. assíncronos podem usar detectores de falhas Na presença de de falhas, alguns problemas solúveis em s. síncronos são irresolutos em s. assíncronos, a menos que este sejam executados num determinado contexto que verifique algumas propriedades e seja conhecido á priori

4 24/05/1999Non-Blocking Atomic Commitment4 Transacções % Iniciador executa % (1) Multicast_1 trans (corpo_trans, participantes) % Todos os participantes executam incluindo o iniciador % A quando da entrega de trans fazer (2) Realizar operações feitas pelo corpo_trans; (3) Se for possível fazer alteração definitiva então vota := sim senão vota := não (4) NBAC(vota,participantes) Num sistema distribuído a transacção pode aceder a dados partilhados localizados em diferentes locais. A execução paralela de transacções é gerida por um protocolo de controlo de concorrência que que assegura que a execução paralela é equivalente á sequencial. O próximo pseudocódigo descreve o processo associado à execução de uma transacção.

5 24/05/1999Non-Blocking Atomic Commitment5 Detecção de Falhas em Sistemas Síncronos Em sistemas síncronos falhas podem ser facilmente detectados usando mecanismos de timeout. Cada site tem um relógio local de tempo real, assim se um participante p não receber de q uma resposta dentro de um certo tempo (2 ), pode concluir que q falhou. Com este mecanismo detecção e sendo a rede considerada fiável a seguinte propriedade verifica-se: antes de p ser notificado através do mecanismo de timeout que q falhou, p receberá todas as mensagens que q enviou antes de falhar.

6 24/05/1999Non-Blocking Atomic Commitment6 Problema do Consenso O problema do consenso consiste em conceber um protocolo tal que todos os processos decidam por unanimidade e com caracter definitivo um valor sobre o conjunto de valores apresentados. Existem 4 propriedades que definem o problema dos consenso: - Terminação : todos os processos correctos têm de decidir sobre um valor; - Integridade : um processo só decide uma vez; - Concordância : dois processos correctos não decidem de maneira diferente; - Validade : se um processo decide D, então D foi proposto por algum processo. Problema do consenso + concordância uniforme = Problema do Consenso Uniforme dois processos não decidem de maneira diferente; O problema do consenso uniforme é importante para a sua posterior recuperação, visto fazer com que a propriedade de integridade não seja quebrada.

7 24/05/1999Non-Blocking Atomic Commitment7 Problema do Consenso (cont.) Ambos os problemas têm soluções relativamente simples em sistemas distribuídos síncronos, mas o mesmo já não se passa em sistemas assíncronos. Isto é devido à impossibilidade de distinguir correctamente um processo bastante lento de um processo que falhou. Esta impossibilidade motivou investigadores a descoberta de propriedades mínimas que quando satisfeitas num s.d.. Assíncrono, fazem com que o problema do consenso seja solúvel.

8 24/05/1999Non-Blocking Atomic Commitment8 Detecção de Falhas em Sistemas Assíncronos É possível equipar todos os sites com detectores que sugerem o possível acontecimento de falhas. Este detectores não são fiáveis, já que podem produzir suspeições erradas. Chandra and Toueg refinaram as propriedades de completude e exactidão e demonstraram que é possível resolver o problema do consenso em cenários onde os sensores satisfazem estas propriedades. As alterações são: - Forte (Fraca) completude : eventualmente todos os participantes faltosos são permanente suspeitados por todos (alguns) participantes correctos. -( Eventual) Fraca exactidão : (Eventualmente) Existe um participante correcto que nunca é suspeitado.

9 24/05/1999Non-Blocking Atomic Commitment9 Detecção de Falhas em Sistemas Assíncronos O problema do consensos versus nº de participantes correctos 1- Se pelo menos um participante está correcto, é possível resolver o problema onde os detectores de falhas satisfazem a fraca completude e a fraca exactidão. 2- se pelo menos existe uma maioria de participantes correctos, é possível resolver o problema onde detectores de falhas satisfazem a fraca completude e a eventual fraca exactidão. Classe de detectores de falha definidos pela fraca completude e eventual fraca exactidão: 3- Esta classe é a mínima para que o problema do consenso tenha solução. 4- Qualquer protocolo que utilize um detector pertencente a esta classe pode não terminar mas se der um resultado este estará correcto.

10 24/05/1999Non-Blocking Atomic Commitment10 Disseminação de Informação em Sistemas Distribuídos A definição de apropriadas primitivas de comunicação constitui um ponto fundamental no desenho de s.d.. A primitiva de multicast é uma das mais importantes já que permite a um processo dessiminar a mensagem m a conjunto de processos. Neste contexto existem 3 primitivas de contexto: - Unreliable multicast: multisend (m,P) para cada p P executar send(m) para p Contém as seguintes propriedades : terminação,validade, integridade, consenso uniforme - Reliable multicast sistemas assíncronos: o objectivo é enviar uma m para P fiavelmente. Acaba por adicionar a propriedade de tudo ou nada à primitiva anterior. - Reliable multicast sistemas síncronos: S_Rel_Multicast(m,P), é definida pelas 4 propriedades da 1º primitiva mais a propriedade de timeless Existe uma constante de tempo, tal que se o multicast de m for iniciado no tempo real de T, então nenhum processo entrega m após m+