Tolerância a Falhas. Reliable Broadcast e Atomic Commitment. June 2, 2010

Tolerância a Falhas Reliable Broadcast e Atomic Commitment June 2, 2010

Sumário Difusão/Multicast Fiável Multicast Fiável em Grupos Dinâmicos Multicast: Aplicação à Replicação Atomic Commitment Two-phase Commit Stable Storage Three-phase Commit Leitura Adicional

Mais Histórias de Generais O exército vermelho está rodeado por n exércitos azuis, alguns dos quais comandados por traidores (desconhecidos). O major-general envia uma ordem a todos os generais. Todos os generais leais têm que acordar na ordem. A comunicação é fiável e atempada. A diferença em relação ao problema de acordo distribuído, conhecido por consensus, é subtil: Consensus Cada um dos generais envia uma proposta, e tem que chegar a acordo sobre uma decisão. Neste caso Cada um dos generais recebe uma mensagem e têm que chegar a acordo sobre o seu conteúdo. Este problema é conhecido sob várias designações. Reliable broadcast ou Interactive consistency

Difusão Fiável: Definição Formal Questão O que significa difundir uma mensagem de forma fiável para todos os processos do grupo? Propriedades Validity Se um processo correcto difunde a mensagem m, então todos os processos correctos do grupo entregam inevitavelmente m. Agreement Se um processo correcto entrega a mensagem m, então todos os processos correctos do grupo entregam inevitavelmente m Integrity Para qualquer mensagem m, cada processso correcto entrega m no máximo uma vez, e apenas se m tiver sido préviamente difundida por um processo.

Atomicidade e Consenso Note-se que entregar uma mensagem é diferente de a receber: Message is delivered to application Application Message is received by communication layer Comm. layer Message comes in from the network Local OS Network A implementação de fiabilidade implica consenso entre todos os processos correctos...

Multicast Fiável em Grupos Dinâmicos Para aumentar a tolerância a falhas pode haver interesse em alterar a composição do grupo, i.e. usar grupos dinâmicos. Como adaptar as propriedades de difusão fiável neste contexto? Validity Se um processo correcto difunde a mensagem m, então todos os processos correctos do grupo entregam inevitavelmente m. Agreement Se um processo correcto entrega a mensagem m, então todos os processos correctos do grupo entregam inevitavelmente m. Integrity Para qualquer mensagem m, cada processso correcto entrega m no máximo uma vez, e apenas se m tiver sido préviamente difundida por um processo. Como conciliar as alterações da composição do grupo e a entrega das mensagens?

Virtual Synchronous Multicast (1/2) Ideia Cada processo do grupo mantém informação sobre a composição do grupo: a sua vista do grupo. Se um processo correcto tem uma vista, cada um dos restantes processos da vista acordaram na sua adopção em determinado ponto da sua execução. Os transmissores pertencem também ao grupo. Cada mensagem multicast está associada à vista do grupo que o seu transmissor tem no instante em que envia m. As propriedades de reliable broadcast têm que ser satisfeitas pelos processos que pertencem a essa vista. Uma mensagem não pode ser entregue no contexto duma vista diferente daquela em que foi enviada. Alterações de vista funcionam como barreiras de sincronização.

Virtual Synchronous Multicast (2/2) Uma mensagem enviada por um processo que falha pode não ser entregue, desde que se faça uma alteração da vista: O transmissor não pode fazer parte da vista seguinte. Reliable multicast by multiple P1 joins the group point-to-point messages P3 crashes P3 rejoins P1 P2 P3 P4 G = {P1,P2,P3,P4} G = {P1,P2,P4} G = {P1,P2,P3,P4} Partial multicast from P3 is discarded Time

Virtual Synchronous Multicast: Implementação (1/4) Pressupostos Canais ponto-a-ponto A comunicação é realizada através de canais ponto a ponto. Canais fiáveis I.e., se os processos na extremidade dum canal estão correctos, então a mensagem enviada por um será recebida pelo outro. Canais ordenados I.e., se um processo p recebe uma mensagem enviada por um processo q, então todas as mensagens previamente enviadas por q para p, foram previamente recebidas por p. Crash-failures Processos avariam por crash, i.e. quando avariam os processos param, deixando de executar qualquer instrução, incluindo receber e enviar mensagens.

Virtual Synchronous Multicast: Implementação (2/4) Problema O transmissor avaria a meio do multicast duma mensagem. Neste caso, alguns processos podem receber a mensagem enquanto outros não. Reliable multicast by multiple P1 joins the group point-to-point messages P3 crashes P3 rejoins P1 P2 P3 P4 G = {P1,P2,P3,P4} G = {P1,P2,P4} G = {P1,P2,P3,P4} Partial multicast from P3 is discarded Solução Duas alternativas: 1. Entregar a mensagem apenas se todos os processos não avariados a tiverem recebido 2. Entregar a mensagem desde que um processo avariado a tenha recebido Em ambos os casos é necessário acordo entre os processos sobre a acção a tomar Time

Virtual Synchronous Multicast: Implementação (3/4) Definição Uma mensagem m diz-se estável para um processo p, se p souber que m foi recebida por todos os processos operacionais duma vista. Ideia Manter uma cópia das mensagens entregues não estáveis Quando da alteração duma vista: 1. reenviar todas as mensagens não estáveis aos restantes processos; 2. aguardar a recepção de mensagens não estáveis doutros processos na vista e entregá-las se não forem duplicadas; 3. instalar a nova vista, i.e. mudar de vista Alternativa Um dos processos é eleito como coordenador: 1. cada processo envia as suas mensagens não estáveis ao coordenador 2. o processo coordenador difunde cada uma delas

Virtual Synchronous Multicast: Implementação (4/4) Problema Como se sabe que não há mais mensagens não estáveis por receber? Solução Cada processo, difunde uma mensagem especial, FLUSH, após ter difundido todas as mensagens não-estáveis, se alguma. Após receber uma mensagem FLUSH de cada um dos processos na nova vista, um processo pode instalar a nova vista Problema E se processos crasharem durante a execução do protocolo? Solução Iniciar a instalação duma nova vista sem o processo falhado Problema Como garantir terminação?

Ordem em Multicast No que respeita à ordem de entrega das mensagens há várias possibilidades, independentemente da fiabilidade: Sem Ordem a ordem pela qual as mensagens são entregues é arbitrária e pode diferir de processo para processo; FIFO mensagens com a mesma origem são entregues na ordem em que foram enviadas; Causal preserva a causalidade potencial entre mensagens (de acordo com a relação happened-before de Lamport): Basta Lamport timestamps ou é preciso usar os vector timestamps? Total as mensagens são entregues pela mesma ordem por todos os processos do grupo: É independente das outras ordens.

Grupos e Replicação A ideia é que as réplicas formam um grupo. Replicação activa pode ser implementada facilmente usando: grupos estáticos; multicast fiável totalmente ordenado. Replicação passiva pode ser implementada facilmente usando: grupos dinâmicos; view synchronous multicast.

Replicação Activa O cliente pode retomar o processamento assim que receber a primeira resposta Assume-se, que a comunicação multicast garante ordem total e é fiável. Quando uma réplica recupera após uma avaria precisa de resincronizar com as restantes réplicas.

Replicação Passiva V i V i+1 No caso de falha duma réplica, as restantes precisam de instalar uma nova vista Se a réplica que falha é o primário, há que eleger um novo primário. Quando um servidor recupera após uma avaria precisa de resincronizar com as restantes réplicas antes de instalar uma nova vista.

Atomic Commitment Problema: Garantir que um conjunto de operações em diferentes processos ou são todas executadas (commit) ou nenhuma é executada (abort). Este é um caso particular de consenso: a decisão tomada por processos que falham pode vincular outros processos. Admite-se que a avaria dos processos é transitória, i.e. que eventualmente os processos avariados são reparados. Pode ser útil mesmo quando processos não falham: por exemplo, se operações individuais podem falhar porque não se verificam determinadas condições.

Atomic Commitment: Formal Cada participante terá que decidir um de 2 resultados: commit/abort Cada participante deverá votar/propor um destes 2 resultados. AC1: Todos os participantes que decidem tomam a mesma decisão AC2: Se algum participante decide commit, então todos os participantes votaram nesse sentido. AC3: Se todos os participantes votarem a favor de commit e não houver falhas, então todos os participantes decidem commit. AC4: Cada participante decide no máximo uma vez, i.e. a sua decisão é irreversível.

Two-Phase Commit: Uma Solução (1/6) Este protocolo usa um processo especial, o coordenador. Os processos que deverão executar as acções são os participantes: O coordenador pode ou não ser participante. Se fôr, deverá executar quer o protocolo do coordenador quer o protocolo dos participantes. O protocolo envolve duas fases: Na primeira fase: O coordenador envia uma mensagem, VOTE-REQUEST, a cada um dos participantes, e espera pela resposta de todos os participantes. Cada um dos participantes emite um voto: ou VOTE-COMMIT ou VOTE-ABORT.

Two-Phase Commit(2/6) Na segunda fase: O coordenador decide COMMIT se tiver recebido VOTE-COMMIT de todos os participantes, senão decide ABORT. Quando recebem a decisão do coordenador, os participantes actuam de acordo executando ou não as operações, e enviam um ACK. Commit Vote-request Vote-abort Global-abort ABORT INIT WAIT (a) COMMIT Coordenador Vote-commit Global-commit Vote-request Vote-abort INIT Vote-request Vote-commit READY Global-abort ACK ABORT (b) Global-commit ACK COMMIT Participante

Two-Phase Commit(3/6) Possíveis Execuções P P P C P 1 P 2 P 3 C 1 2 3 Vote-request Vote-request V-Abort V-Commit G-Commit V-Commit G-Abort ACK ACK Na ausência de avarias o protocolo é simples.

Two-Phase Commit(4/6) C P 1 P 2 P 3 C P 1 P 2 P 3 Vote-request Vote-request V-Commit G-Abort V-Commit G-Commit ACK ACK Avarias em processos podem ser detectadas por time-outs. Mesmo que o sistema não seja síncrono. O protocolo tem que prever as acções a executar na eventualidade de time-outs.

Two-Phase Commit(5/6): Timeout e Recuperação Acções por timeout Coordenador Só espera por mensagens no estado READY: Decide ABORT, e envia G_Abort a todos os participantes. Participante Pode bloquear em: INIT Decide ABORT e passa para o estado correspondente. READY Precisa contactar outros participantes para determinar o resultado. Poderá ter que bloquear à espera que o coordenador recupere, para tomar conhecimento da decisão. Acções de recuperação Se o processo ainda não decidiu então: Se num estado onde espera uma mensagem, pode usar as mesmas acções que no caso de timeout; Senão coordenador no estado INIT pode decidir

Two-Phase Commit(6/6): Recuperação Para permitir recuperação local, os processos deverão acrescentar um registo com o seu estado a um log em disco. A escrita no log deve ser feita antes ou depois de enviar as mensagens correspondentes? Além do estado do protocolo, poderá ser necessário gravar em disco estado da aplicação. O protocolo apresentado satisfaz as propriedades AC1 a AC4 em presença de: falhas de comunicação, incluindo partição da rede; falhas nos nós, desde que não sejam arbitrárias. O principal problema deste protocolo é a possibilidade dos participantes bloquearem quando o coordenador falha Este problema pode ser obviado: usando reliable multicast na comunicação; o protocolo three-phase commit.

Stable Storage (1/2) Problem Tal como 2PC, muitos protocolos tolerantes a falhas supõem que parte do estado dos processos sobrevive falhas de processos. Tipicamente, isso significa guardar esse estado no disco. Como garantir que o estado sobrevive falhas no disco? Solução: Stable Storage Usar 2 discos idênticos. Escrever um bloco implica escrever no disco 1 primeiro e no disco 2 depois. Na leitura, lêr do disco 1, a menos que a sua checksum seja inválida.

Stable Storage (2/2) Sector has different value a h b g c d e f a h b g c d e f a h b g c d e f a h b g c d e f a h b g c d e f a h b g c d e f Bad checksum (a) (b) (c) Recuperação após crash Se os sectores forem diferentes: actualizar o do 2 o disco com o valor do sector do 1 o. Se a checksum de um não for válida: usar o outro, e tentar actualizar o sector com erros. Se ambos tiverem checksums inválidas: falha catastrófica.

Three-Phase Commit (1/3) Evita bloqueio acrescentando uma fase entre as 2 do two-phase commit, na qual o coordenador dá a conhecer a sua intenção em decidir commit: Commit Vote-request Vote-abort Global-abort ABORT INIT WAIT PRECOMMIT COMMIT Vote-commit Prepare-commit Ready-commit Global-commit Vote-request Vote-abort INIT Vote-request Vote-commit READY Global-abort ACK ABORT Prepare-commit Ready-commit PRECOMMIT COMMIT Global-commit ACK (a) Coordenador (b) Participante

Three-Phase Commit (2/3) Os novos estados garantem que: 1. Não há qualquer estado com transições para o estado COMMIT e para o estado ABORT. 2. Não há qualquer estado onde: 2.1 não seja possível tomar a decisão, e 2.2 seja possível fazer uma transição para o estado COMMIT. Pode mostrar-se que estas condições são necessárias e suficientes para evitar bloqueio.

Three-Phase Commit (3/3) O algoritmo garante que não há bloqueio no caso do coordenador falhar, desde que haja uma maioria de participantes que acordem no resultado: 1. Se a maioria dos participantes estiver no estado READY pode decidir ABORT. 2. Se a maioria dos participantes estiver no estado PRECOMMIT pode decidir COMMIT. Como duas maiorias se sobrepõem, não é possível tomar decisões contraditórias. Note que um processo no estado PRECOMMIT pode ainda abortar, no caso de falhar. Note-se que este algoritmo não admite partições: doutro modo seria possível que a maioria dos participantes decidisse de forma distinta do coordenador.

Leitura Adicional Capítulo 8 de Tanenbaum e van Steen, Distributed Systems, 2nd Ed. Secção 8.4: Reliable Group Communication (excepto subsecção 8.4.2) Secção 8.5: Distributed Commit Parágrafo Stable Storage da subsecção 8.6.1.