Confirmação Atómica não-Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente,

Slides:



Advertisements
Apresentações semelhantes
P A P Z P A A Z Z.
Advertisements

Introdução Gdes. bancos de dados: Concorrência: Transação:
Requisitos dos SGBD Recuperação/Tolerância a Falhas
Sistemas distribuídos
Recuperação Como garantir a integridade da informação, em caso de avarias de HW ou SW forma de suportar a reposição de um estado consistente da informação.
Transações Atômicas Distribuídas
Modelos de Comunicação em Sistemas Distribuídos
Transações Atômicas Distribuídas
Arquiteturas de Sistemas Distribuídos: Modelos de Comunicação
Monitores.
Capítulo 4: Estado Global
Sistemas Operacionais II
Árvores.
Unreliable Failure Detectors for Reliable Distributed Systems
Sistemas Distribuídos
Sistemas Distribuídos
Sistemas Distribuídos Walfredo Cirne & Fubica Brasileiro Aula 4: Mais Conceitos Básicos As figuras que aparecem nesses slides são de Veríssimo&Rodrigues,
Uma Introdução a Detectores de Defeitos para Sistemas Assíncronos
Carolina Fonseca Neumar Ribeiro
The Byzantine Generals Problem
Questões Resolvidas - A.C.-10/08/05
CONTROLE DE ADMISSÃO BASEADO EM POLÍTICA
ESTRUTURA DE COMUNICAÇÃO DE DADOS
TFD - Réplicas em máquinas de estados
CONSENSO O grande mal-entendido
Bimodal Multicast Um protocolo de difusão fiável
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.
RECUPERAÇÃO APÓS FALHA
A → B : k * M ( k = fator de ocultação )
Tópicos em Sistemas Distribuídos
Coordenação e consenso
Unidade 3 Controle de Concorrência
Tópicos em redes e sistemas distribuídos Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação.
Difusão de Mensagens Broadcast confiável, atômico e causal
Commit, Rollback, Storage procedure, Triggers
Era uma vez um casal que tinha um filho de dez anos e um burro.
Gestão de Escopo Por Ruan Carlos.
Introdução ao uso de vatores na linguagem PASCAL.
Fiabilidade de Sistemas Informáticos
O Problema Do Acordo Distribuído (Acordo Bizantino)
Fiabilidade de Sistemas Informáticos Acções Atómicas
Software-Based Replication for Fault Tolerance Apresentação do tema por João Ramires Tolerância a Faltas Distribuída Mestrado em Informática FCUL 1999/2000.
Universidade da Beira Interior Processadores Fail-Stop Trabalho realizado por: Rui ferreira Nº Eng. Informática.
Transações Atômicas Distribuídas Prof. Alcides Calsavara
Comunicação de dados Protocolos básicos de enlace de dados.
ARQUITECTURA TCP/IP.
Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática – CEEI Departamento de Sistemas e Computação Programa de Pós-Graduação.
Capítulo 5 Entrada/Saída 5.1 Princípios do hardware de E/S
1 Comunicação Inter-Processos -> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)
Impossibility of Distributed Consensus with One Faulty Process Michael J. Fischer Nancy A. Lynch Michael S. Paterson 1985 Apresentado por Nazareno Andrade.
Controle de Acesso Kerberos
Escola Secundaria Sebastião da Gama Trabalho realizado por: André Santos 12ºL nº:2 Prof: Carlos Pereira.
Camada de aplicação OSI Liane Tarouco UFRGS. Camada de aplicação do modelo OSI ACSE (Application Control Service Element) CCR (Commitment Concurrency.
Key confirmation and adaptive corruptions in the protocol security logic (Chave de confirmação e Corrupções Adaptativas em um protocolo de segurança lógica)
SISTEMAS DISTRIBUÍDOS Transações Atômicas
Otimizações de um Protocolo para Multicast Atômico em Computação Móvel Aluno: Mateus de Freitas Ribeiro Orientador: Markus Endler
Análise e Projeto de Sistemas
Disciplina: Comunicação de Dados Ricardo Bento 12ºL.
Modos de Desconexão para BD’s Móveis Sandberg Marcel Santos Baseado no artigo “Disconnection Modes for Mobile Databases”, de Holliday, Agrawal e El Abbadi.
Modelos de Comunicação em Sistemas Distribuídos
Modelos de Comunicação em Sistemas Distribuídos
Redes de computadores: Camada de Transporte Prof. Dr. Amine BERQIA
Sistemas Distribuídos Carlos Oberdan Rolim Ciência da Computação Sistemas de Informação.
TCP È um dos protocolos sob os quais assenta o núcleo da Internet nos dias de hoje. A versatilidade e robustez deste protocolo tornaram adequado para.
Conceitos de Monitoramento
Herança.
Interpretação do Teorema de Herbrand
Passagens de Mensagens Prof. Dr. Norian Marranghello
Rede de Computadores MAT164 – Redes de Computadores I Universidade Federal da Bahia Instituto de Matemática Departamento de Ciência da Computação.
Lucas R. Costa Rodrigo R. Bezerra Kaio A. da silva
Transcrição da apresentação:

Confirmação Atómica não-Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente, confirmar ou abortar a transacção.

Confirmação Atómica não-Bloqueante Protocolo NBAC depende dos votos dos participantes e das falhas dos mesmos Requisitos do protocolo –Terminação; –Integridade; –Acordo Uniforme; –Validade; –Não-Trivialidade.

Não-Trivialidade Para solucionar cenários de falha. Decisão independente dos votos e do cenário de falha. –S-Não-Trivialidade - Se todos votam YES e não existem falhas, então o resultado é Commit; –AS-Não-Trivialidade - Se todos votam YES e não existem suspeitas de falhas, então o resultado é Commit.

Protocolo Genérico Procedure nbac(voto, participantes) begin (1.1) multicast_2(voto, participantes); (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (existe participante q: excepção(q) foi notificada a p) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := propõe(Abort) (3.3) notificação de excepção -> resultado := propõe(Commit) (3.4) todos os votos YES -> resultado := propõe(Commit) (3.5) fim caso end

Sistemas Assíncronos Multicast_1 => AS_Rel_Multicast Multicast_2 => Multisend Excepção => Suspeita de falha Propõe(x) => Unif_Cons(x)

Protocolo Genérico Procedure AS_nbac(voto, participantes) begin (1.1) Multisend(voto, participantes); (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (existe participante q: suspeita(q)) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := Unif_Cons(Abort) (3.3) notificação de excepção -> resultado := Unif_Cons(Commit) (3.4) todos os votos YES -> resultado := Unif_Cons(Commit) (3.5) fim caso end

Porque é que funciona? Integridade: por 3.2 e 3.4, se o sub-protocolo Unif_Cons satisfizer a propriedade; Validade: resulta da linha 3.4. Se todos votarem YES, o output de Unif_Cons será Commit; Acordo Uniforme: resulta da propriedade Acordo Uniforme do sub-protocolo Unif_Cons; AS-Não-Trivialidade: pela Completude do detector de falhas, pelo Acordo Uniforme e Validade de Unif_Cons, segue-se que a decisão será Commit;

Porque é que funciona? Terminação: depende da Completude dos detectores de falhas. Assuma-se que estes satisfazem a propriedade Completude Forte (i.e., a falha de um participante será suspeitada por todos os correctos). Assuma-se também uma rede fiável. Então p recebe um voto de q ou suspeita dele. Então o comando espera (2.1 a 2.4) termina para cada participante correcto. Pela propriedade de Terminação de Unif_Cons, todos os participantes correctos irão decidir.

Sistemas Assíncronos Multicast_1 => Multisend Multicast_2 => S_Rel_Multicast Excepção => Por timeout Propõe(x) => x

Protocolo Genérico Procedure S_nbac(voto, participantes) begin (1.1) S_Rel_Multicast(voto, participantes); (2.0) coloca timer a δ + Δ; (2.1) espera ((entrega de um voto NO de um participante) (2.2) ou (timeout) (2.3) ou (de cada participante q: entrega de um voto YES) (2.4) ); (3.1) caso (3.2) receba um voto NO -> resultado := Abort (3.3) timeout -> resultado := Commit (3.4) todos os votos YES -> resultado := Commit (3.5) fim caso end

Porque é que funciona? Terminação: ninguém espera mais que δ + Δ; Integridade: resulta da estrutura do protocolo; Validade: resulta de linha 3.4; S-Não-Trivialidade: Se não existirem falhas todos votam. Cada participante recebe os votos antes do seu timer expirar. Se os votos são todos YES então Commit;

Porque é que funciona? Acordo Uniforme: por absurdo, se p decide Commit e q Abort então por 3.4, p recebeu YES de todos e q decidiu em 3.2 ou 3.3. Em 3.2 é impossível porque todos enviam o mesmo voto para p e q (YES). Por 3.3 o timer de q (δ + Δ) expirou, por não receber o voto de r. Mas, no pior caso, r recebeu trans δ após q receber. Como p recebeu YES de r, pela propriedade de acordo uniforme da primitiva S_Rel_Multicast usada por r ao enviar o seu voto e pelo limite Δ associado a essa primitiva, segue-se que q recebeu o voto de r antes do seu timer expirar. Contradição.

Optimizações Se p recebe um voto NO de q pode decidir abortar imediatamente. Para Unif_Cons terminar p terá que propor um valor (Abort). No entanto, não terá que esperar pelo output pois já decidiu Abort. Pode também disseminar a decisão de Abort aos outros participantes através da primitiva AS_Rel_Multicast.