tolerância a falhas em sistemas distribuídos : problemas ... · raimundo macêdo, lasid/ufba 1...

21/9/2010

1

Tolerância a Falhas em Sistemas Distribuídos :

Problemas Fundamentais

Raimundo Macêdo, LaSiD/UFBA 1

Raimundo Macêdo, LaSiD/UFBA

Sistemas Distribuídos nos Dias Atuais

Viabilizado pela WWW/Internet - anos 90

Nossas vidas estão cada vez mais dependentes do pronto funcionamento de aplicações nesses ambientes !!

Comércio EletrônicoBolsa de ValoresAutomação HospitalarDinheiro EletrônicoSistemas de Controle Aéreo,etc


etc.

Requisitos Fundamentais:Correção - Rapidez - Segurança - Privacidade

21/9/2010

2

Exemplo 1

Sistema de Monitoramento Médico

Rede

I

EscritórioMédicoUTI


Internamento

BD ClínicoBiblioteca Digital

Laboratórios

Exemplo 2

Sistema de Controle de Tráfego Aéreo

REDE

Radar

SistemaEmbarcado


Controladores

DB tráfego aéreo(planos de voo, etc)

DiretórioX.500

21/9/2010

3

Um Sistema Distribuído (SD) é composto de componentes que são lógica e fisicamente separados

comp. de soft. comp. de soft.

canal ou porta de comunicaçãocomp. de soft.

Componentes de software são entidades comunicantes(objetos, sistemas, etc.) genericamente chamados de processos


Ações básicas realizadas entre componentes• Transferência de dados (mensagem)• Sincronização

Vantagens dos Sistemas Distribuídos

• Crescimento incremental

• compartilhamento de recursos


compartilhamento de recursos

• maior performance (paralelismo)

• maior confiabilidade (?)

21/9/2010

4

Tolerância a FalhasTolerância a Falhas


Um SD é inerentemente mais confiável ? Um SD é inerentemente mais confiável ?

Você sabe que está num SD quando é impedido de prosseguir com seu trabalho por causa da queda deprosseguir com seu trabalho por causa da queda de

um outro computador do qual nunca ouviu falar

(Leslie Lamport)(Leslie Lamport)


21/9/2010

5

Implicações da definição de LamportImplicações da definição de Lamport

Funções estão distribuídas emFunções estão distribuídas em componentes

Necessidade de sobreviver a falhas de componentes(Tolerância a Falhas)


Considere P(ci) = probabilidade de componente ci funcionar = 0,3

Sem tolerância a falhas, P(s) = P(a1) x P(a2) x P(a3) = 0,027

Um SD é inerentemente mais confiável?

c1 c2

3

S


c3

Com tolerância a falhas (usando replicação de componentes)

P(s) = Prob. de pelo menos um componente funcionar = 1 - 0,34 = 0,66onde, prob. de todos falharem = (0,7)3 = 0,34

21/9/2010

6

Terminologiafailure fault

Fault-toleranced d bilit

confiavel

faltas

error

errofalha

diagnosis

dependability

availabilitydefeito

Confianca no funcioanmento

MTTF


defect Fault-avaidance

falha

defeito

Survivability

Tolerancia a falhas

Tolerancia a faltas

reliability

Somente o básico ....

Fault Error Failure

causa original

ex: bit

perceptível no estado do sistema

ex:registro

funcionamento incorreto (não especificado)

ex: atualização


ex: bit modificado

ex:registro corrompido

ex: atualização errada do salário

21/9/2010

7

Somente o básico ....

Fault Error Failure

falha erro defeito

falta erro falha


Falha = o que causa o sistema desviar da especificação

Tolerância a Falhas = Capacidade de funcionar corretamente na presença de (algumas) falhas

F lt / F lh

Sistema Distribuído

faulterrorfailureFault / Falha

Componente 1 Componente 2

Raimundo Macêdo, LaSiD/UFBA 14Failure para componente = fault para o sistema distribuído

failure

21/9/2010

8

A natureza das falhas

bambiente (discos, memória, rede, etc)

bprojetoprojeto

bimplementação (bugs no código)

O que pode ser feito para evitá-las ??


Prevenção (Verificação e testes) +

Tolerância a Falhas

Tipos de Tolerância a Falhas

Safe masking fail safe

não safe não masking nenhuma

live não live


Pára todos os trens por causa de problemas nos semáforos

21/9/2010

9

A técnica básica para implementar Tolerância a Falhas é uso de Redundância

Espacial e Temporal


Redundância Temporal

FalhaDetecção

retorno a um estadoconsistente

A mesma parte do código pode ser executada várias vezes


Transações Atômicas Distribuídas é exemplo típico

Atomic Commitment é fundamental para garantir a propriedade de safety (ACID) - i.e. não interferência entre transações concorrentes

21/9/2010

10

Redundância Espacial

Falha

Detecção

A falha é “mascarada” eo componente faltosoé posteriormente substituído.


S1 S2 S3 S4

Servidor replicado Protocolos de ordenação, entrega atômica e memberhip são fundamentais

As várias formas de TF são classificadas segundo o modelo do sistema

Diferentes falhas levam a um mesmo comportamento do componente num SD

(ex: ausência de comunicação)


==> devemos agrupá-las em classes e descrever os algoritmos em função dessas classes e do modelo do sistema

21/9/2010

11

Especificação do Serviço

Um certo programa P é tolerante a uma classe de falhas F nummodelo de sistemas M

fail-safemasking;probailistico;determinista

Classes de Falha

Modelo Abstrato do Ambiente

Modelo do Sistema

Benigna;Maligna.

determinista.

Sincrono;Assincrono;S i i


O Ambiente RealEscalonamentode tempo real;Datagrama;QoS guarantida

Semi-sincrono.

Modelos de Sistema Distribuído

Conjunto finito de processos : p1, p2, ...,pn. Não há estado global (compartilhado) entre processos

(i.e., memória ou relógio).Processos comunicam-se somente através de troca de mensagensProcessos comunicam-se somente através de troca de mensagensAssertivas quanto aos tempos de

t1 : transferência de mensagens entre processos et2 : computação + de um ação (evento) num processo.

+ um modelo de falhas para os processos.

+ um modelo de falhas p/ os canais de comunicação

21/9/2010

12

t1 : transferência de mensagens entre processos et2 : computação de um ação (evento) num processo.

Valores máximos para t1 e t2 são finitos e conhecidos

⇒ sistemas síncronos Byzantine AgreementProcessor Membership

Valores máximos para t1 e t2 são finitos, porém desconhecidos

⇒ sistemas assíncronos: Internet ou WANs

pSystem Diagnosis

Group MembershipDistributed Consensus

SíncronoAssíncrono

desconhecido LimitadoParcialmente síncronoTimed-asyncronous,Failure Detectors,TCB, etc.

Distributed Consensus

um modelo de falha para os processos.

sistemas síncronos

d d fi i i (f l )• parada definitiva (fail-stop)• omissão• falhas temporais

mais cedomais tarde (falha de performance)

• falhas arbitrárias (byzantine)

Hipóteses mais fracasAlgoritmos mais complexosAlgoritmos mais portáteisMenos garantias do ambiente


sistemas assíncronos

• parada definitiva (crash)•Crash/Recovery• falhas arbitrarias (byzantine)

21/9/2010

13

um modelo de falha para os canais de comunicação

•omissão (perdas)omissão (perdas)•duplicadas ou não•corrompidas ou não•fora da ordem ou não• falhas arbitrárias (byzantine)


Qual o melhor modelo ???

Depende dos requisitos da aplicação e o ambiente disponíveis !

O sistema assíncrono é o mais portátil e o mais realistaconsiderando-se ambientes como a Internet,

Mas ...


21/9/2010

14

Não existe solução determinista para o problema de consenso em sistemas distribuídos assíncronos sujeitos a falhas tipo crash !!!

Impossibilidade FLP Fischer, Lynch, Paterson (1985)

M Fischer N Lynch and M Peterson "Impossibility of Distributed Consensus


M. Fischer, N. Lynch, and M. Peterson, Impossibility of Distributed Consensus with One Faulty Process", J. ACM, 32, April 1985, pp 374-382

Atomic Commitment ??? Membership??? Atomic Multicast ???

Especificação do Serviço

O que fazer ???

Ou restringe o problema(retirando atributos)

aSoluções Probabilísticas -

randomisation (Ben-Or, Rabin 1983)

Classes de Falha

Modelo Abstrato do Ambiente

ou

restringe o modelo(colocando atributos)

aAdição de Premissas Síncronas

minimal syncronazation (Dolev-Dwork-Stockmeyer, 1986)

partial synchrony (Dwork-Lync-Stochmeyer 1987)


Modelo Realdo Ambiente

(colocando atributos)timed asynchronous (Christian-Fetzer, 1995)

quasi-synchronous (Almeida e Veríssimo, 1997)

unreliable failure detectors (Chandra-Toueg, 1991, 1992)

TCB (Verissimo et al, 2000)

21/9/2010

15

FD1 P1FD1 P1

FDn Pn

Cada processo é equipado com um failure detector local que mantém uma lista de processos que ele suspeita como crashed.

Um failure detector pode cometer erros :

(i) não suspeitando de um processo que realmente falhou (crashed) ou(ii) it d d t ( ã f lh )

Assincronia


Propriedades:Completeness : requer que um FD suspeite os processos que falharam.Accuracy : restringe a quantidade de erros que o FD pode cometer.

(ii) suspeitando de um processo correto (que não falhou).

completeness accuracyStrong weak <>strong <>weak

Classes de Failure Detectors

Nonestrong

weak

P S <>P <>S

Q W <>Q <>W

VW

VW ==> Impossível consenso ou membership determinista


VW + “best effort” group membership = particionamento virtual

<>S + rotating paradign = possibilidade de consenso

21/9/2010

16

Pn-1

p1

p2

p1

Algoritmo de Consenso Baseado nos Detectores <>S

p3

Pn-2


Teorema: O algoritmo resolve consenso usando <>S num SD assíncronocom número de crashes < n/2

Liveness : cada processo correto “eventualmente”decide um valorAgreement (safety) : todos os processos corretos decidem pelo mesmo valor

Porque FDs <>S de Chandra-Toueg é um bom modelo ?

10 é o único que resolve consenso sem assumir premissas temporais(síncronas).

20 permite caracterizar as condições em que consenso é solúvel.

30 algoritmo baseado em<> S pode violar terminação (liveness)mas não irá JAMAIS violar correção (safety) ==> Fail-safe


J S ç ( f y)

40 FDs da classe <> S podem cometer um número arbitrário de erros

21/9/2010

17

Componentes Fundamentais paraComponentes Fundamentais paraImplementação de Técnicas de Tolerância a Falhas


De uma lado, computação distribuída requer coordenação e sincronização entre processos.

De outro lado, como sincronizar ou coordenar, se não há estado global ou compartilhado ?? Somente troca de mensagens !!!

É possível a especificação (e implementação) de abstrações que incluam garantias “globais” que facilitem a construção de software distribuído?

Resposta :RPC (Chamada de Procedimento Remoto)Transações DistribuídasObjetos Distribuídos


group communicatione membership service (virtual sincrony)

consensus

Memória Compartilhada DistribuídaReplicação,etc.

21/9/2010

18

Comunicação em Grupo

Group Communication


Group Communication

P1

P2P4

Send(msg, G_id)Receive(msg_buffer, G-id)create(G_id, type_com, proc_ids...)open P1

P3 PN

pjoinetc.

Quais propriedades fundamentaisprecisam ser encapsuladas dentro

cliente


das operações de grupo ??

Quais são os problemas ?

Servidor Replicado

Grupo

21/9/2010

19

P1

P2P4

Grupo

cliente

P1P3 PN

visão coerente (serviço de membership)

Servidor Replicado

Grupo


visão coerente (serviço de membership)entrega ordenada (causal, total, ...)controle de fluxo Falhas

Como garantir visão coerente da lista de participantes ???

Assinconia + falhas de comunicação + crash !!!!

Situação Possível!

VisãoP1 = {p1, p2, p3, p4}VisãoP2 = { p1, p2}

p1

Joinp4


crash

{ p , p }VisãoP4 = {p1, p2,p4}p2p3

21/9/2010

20

Como se concretiza um serviço de membership?Vi

1 = {P1, P2, ..., Pn} Vi1, Vi

2,..., Vi r

p1

p4

P3 falhou?


crash

p2p3

G

Vi2

ParticionáveisClasses de soluções

G

Vi2

Partição primária

G

Vi1

G

Vi2

G


G

21/9/2010

21

Problemas enfrentados pelas aplicações devido àassíncronia e falhas típicas do SD assíncronos


Exemplo 1 - ordem idênticaBanco de Dados Replicado para aumentar disponibilidade

(reserva de assentos de avião)

m1 m2

X X

m1, m2 m2, m1


Aloca X para U1

m2

Aloca X para U2

Qual a ordem correta para m1 e m2 ?

21/9/2010

22

m1

Exemplo 2 - ordem causalListas de Correio Eletrônico, Teleconferência, etc.)

m1

RE:m1


Como deduzir que “m1” precede “RE:m1” ?

Dificuldades adicionais : grupos sobrepostos

P1

P2

P3

P4

P5

P6

m1 m2

m3


Como P4 pode deduzir m1⌫ m3 ?

21/9/2010

23

Grupos Sobrepostos com Ciclos

G1G2

q

p

r

m1m2

m3


G3

Como r pode deduzir m1⌫ m3 ?

A questão da visão mutualmente consistenteComo garantir que todos os membros do grupo tenham uma

visão coerente da lista de participantes ???

Mesmo com Assinconia + falhas de comunicação + crash !!!!

crash

Situação Possível nummesmo “instante” !

VisãoP1 = {p1, p2, p3, p4}VisãoP2 = { p1, p2} VisãoP4 = {p1, p2,p3}

p1

p2p3

Joinp4


Esse requisito é fundamental para aplicações como trabalho

cooperativo (CSCW), teleconferência,balanceamento de carga, agentes móveis, etc.

crash

21/9/2010

24

Para tolerar as falhas de ambiente e assincronia típicas dossistemas assíncronos, as seguintes propriedades devem serencapsuladas dentro dos operadores de grupo:

atomicidade : falhas de comunicação + crashesçordenação: “assincronia”visão consistente : falhas de comunicação + crashes

Sincronia Virtual e suas variações atendem ao requisito de visão consistente


Estrita : Variações :

ISIS/87, Birman

Transis/92 Amir, Dolev, Kramer, Malki

Newtop/94, Ezhulchelvan, Macêdo, Shrivastava

Relacs/94, Babaoglu, Davoli, Gichini, Baker

O requisito de ordenação (inclusive em grupos sobrepostos)foi resolvido através do uso dos relógios lógicos de Lamport (78) e variações desse mecanismo.

Grafos de dependência (Peterson-Bucholz-Schlichting, 89)

Vetores de relógios lógicos (Mattern/89, Fidge/91, Birman/91)

Árvores de Ordenação (Garcia-Molina, 91)


Causal Blocks (Macêdo-Ezhilchelvan-Shrivastava, 93)

Matrizes de Relógios(Raynal, 93)

21/9/2010

25

G0={p,q}

Virtual Synchrony, Ken Birman, 1997

Processos recebem a mesma seqüência de visões e o mesmo conjunto de mensagens entre visões

p

q

rst r s request to join


t r, s request to join

G0={p,q} G1={p,q,r,s}



crashp

q

rst r s request to join


t r, s request to join

r,s added; state transfer

21/9/2010

26

G0={p,q} G1={p,q,r,s} G2={q,r,s}



crashp

q

rs

r s request to join p fails


t r, s request to joinr,s added; state xfer

t requests to join

p fails

G0={p,q} G1={p,q,r,s} G2={q,r,s} G3={q,r,s,t}



crashp

q

rs

r s request to join p fails


t r, s request to joinr,s added; state xfer

t added, state transfer

t requests to join

p fails

21/9/2010

27

Outro Problema !!!

Sistemas de Grupos Tolerantes a Falhas precisam manter na memória mensagens para garantir atomicidade/recuperação. Mas até quando ??? (memória não é infinita !!)

N id d d l d fl í l d==>> Necessidade de controle de fluxo ao nível dos grupos

Macêdo, Ezhilchelvan, Shrivastava == Conceito e Condições de Super-estabilidade

1994 (Broadcast Workshop, Grenoble)

1995 (in IEEE PFTCS)


Flaviu Cristian, Mishra, 1995 (In IEEE ISADS)

Mishra, L. Wu, 1997 (in IEEE ISHPC)

Sistemas de Grupos para ambientesassíncronos característicos da Internet ou WAN’s ?Primitivas para comunicação com garantias variadas

CAUSALTOTALControle de MembershipSincronia Virtual

Sobreposição

Total = Causal + Idêntica

O h d i dSincronia Virtual

ISIS (Ken Birman) 1987-1993 (pioneiro)

Primary-Partition(Ricciardi e Birman, 1991) - ISIS

(Kaashoek e Tanenbaum, 1991) - AMOEBA

lli S i h A l 1994 ( A d i S ( ) 4 9 4 3)

==> Impossibilidade de membership com partição primária (Anceaume, Charron-Bost, Minet, Toueg - 1995)

Na prática funciona, pois de forma implícitaforam assumidas premissas síncronas ==> violação de safety

Overheads variados


MelliarsSmith, Moser e Agrawala, 1994 (In IEEE Tras. Par. And Dist. Systems 5(5):459-473)

Sistemas ParticionáveisAmir, Dolev, Kramer, Malki (1992) - TRANSIS (In IEEE FTCS)

Ezhulchelvan, Macêdo, Shrivastava - NEWTOP (Broadcast Deliverable Report, 1994 e IEEE ICDCS, 1995)

Babaoglu, Davoli, Gichini, Baker - RELACS (Broadcast Deliverable Report, 1994)

foram assumidas premissas síncronas. . > violação de safety.

Corretos Formalmente, mas partições podem

se degenerar. São necessários mecanismos de

“re-merging”.

21/9/2010

28

Componentede software

Existe algum REQUISITO comum ainda mais elementar que comunicação em grupo ?

canal ou porta de comunicação

Processos cooperantes precisam concordar em ações comuns•quem faz qual tarefa


==> Concordar em ações (obter consenso) parece ser o “máximo denominador comum”das computações distribuídas.

•quem faz qual tarefa, •concretizar ou abortar uma transação, •quem terá direito a determinado recurso, •qual a ordem de entrega, etc

Consenso

O módulo elementar para a construçãode software distribuído confiável


21/9/2010

29

Formalizando ...Dado um conjunto predeterminado de processos P = {p1, p2, ..., pn}Cada processo pi propõe um valor viProcessos têm que concordar em um valor

Propriedades que devem ser satisfeitas:p q

termination (liveness) : cada processo correto “eventualmente”decidirá por algum valor

validity (safety) : se um processo decide v, então v foi proposto por algum q ∈ P.


Agreement (safety) :se pi (correto) decide vi e pj decide vj, então vi = vj

Uniform Agreement (safety) :se pi decide vi e pj decide vj, então vi = vj

Relação entre Consenso e Atomic BroadcastaAtomic Broadcast (ou Atomic multicast) - AB

G = (p1, p2, ..pn)

i) atomicidade, AB(m,G) :

∃ pi ∈ G, delivery (m,pi) ⇒∀ pj ∈ G, delivery (m,pj)

Teorema : AB e Consenso são equivalentes (Chandra e Toueg, 1996)

i) qualquer solução para AB pode ser usada para resolver Consenso

pi , y ( ,pi) pj , y ( ,pj)

ii) ordem idêntica, AB(m,G), AB(m’,G) :

∀ pi ∈ G delivery (m,pi) → delivery (m’,pi) ⇒∀ pj ∈ G, delivery (m,pj) → delivery (m’,pj)


==> FLP se aplica a AB

∀ pi ⏐ pi ∈ G, AB(vi,G) vetor (v1, v2, ..., vn)

decida pelo primeiro vi delivered

ii) qualquer solução para Consenso pode ser usada para resolver AB

==> consenso pode ser usado como modulo de construção de AB

redução

21/9/2010

30

Relação entre Consenso e NBACNon-Blocking Weak Atomic Commitment - NBWAC

No final de uma transação atômica, processos devem concordar com sua concretização (votando SIM ou NÃO)

1. termination (liveness): se um conjunto de processos corretos iniciar NBAC,

então cada processo desse conjunto “eventualmente” decidirá por um resultado

2. validity (safety): a decisão tem que ser abort ou commit.

3. uniform agrrement (safety): processos decidem pelo mesmo resultado.

4. justification : se a decisão for commit é porque todos votaram SIM.


5. obligation (safety) : se todos processos votam SIM e não há suspeitas de

falhas, então a decisão tem que ser commit.

Teorema : NBAWC é redutível para Consenso (Guerraoui e Schiper, 1995)

Redução de NBWAC para Consenso

Procedure NBWAC(votoi)

Begin

send(votoi) para todos processos( ) p p

wait ( (n mensagens SIM) ou

(1 mensagem NÃO ou falha de algum p)

if (n mensagens SIM) then

voto-consenso:= Commit

else


voto-consenso:= Abort;

decidedi := consenso(voto-consenso);

End

21/9/2010

31

Não existe solução determinista para o problema de consenso em sistemas distribuídos assíncronos sujeitos a falhas tipo crash !!!

Impossibilidade FLP Fischer, Lynch, Paterson (1985)

M Fischer N Lynch and M Peterson "Impossibility of Distributed Consensus


M. Fischer, N. Lynch, and M. Peterson, Impossibility of Distributed Consensus with One Faulty Process", J. ACM, 32, April 1985, pp 374-382

Nota : A impossibilidade de membership resulta de FLP

time-out P2 falhou

crash

p1

p2

Cenário 1

Em sistemas assíncronos é impossíveldistinguir cenário1 do cenário3

Por que FLP? Intuição da prova

v1

Consenso entre P1 e P2 ?

time-out P2 está correto

p1

p2

Cenário 2

distinguir cenário1 do cenário3.

No cenário 1,

Se P1 não decide depois de time-out

(espera por v2) ==> mantém safety e

viola termination

v1 v2


time-out P2 falhoup1

p2

Cenário 3

No cenário 3

Se P1 decide após time-out,

não espera por v2

==> assegura liveness e viola safetyv1v2

21/9/2010

32

Modelos restritivos onde consenso é solúvel

Trabalhos a partir de FLP


FLP existe, mas o que se pode fazer com os sistemasassíncronos característicos da Internet ou WAN’s ?

aSoluções Probabilísticas - randomisation (Ben-Or, Rabin 1983)

aAdição de Premissas Síncronas

minimal syncronazation (Dolev-Dwork-Stockmeyer, 1986)

partial synchrony (Dwork-Lync-Stochmeyer 1987)

timed asynchronous (Christian-Fetzer, 1995)


quasi-synchronous (Almeida e Veríssimo, 1997)

aAdditional assumptions on failure detection

unreliable failure detectors (Chandra-Toueg, 1991, 1992)

21/9/2010

33

FLP existe ! Mas então porque não usar (ou quando usar) o modelo síncrono ?

L. Lamport , R. Shastak, and M Pease, “The ByzantineGenerals Problem”, ACM Trans, on Programming Lang.And Systems, 4(3):382-401, july, 1982.

Existe solução para consenso, desde que mais que 2/3 dos processos não falhem de forma

Quando maior o tempo assumido (t1 e t2), maior a demora para reaçãoe recuperação de um chash (ex: crash do processo líder num esquema de primary-backup)

Quanto menor o tempo assumido, mais rápida a reação e maior a possibilidade de falhas temporais. Muitas falhas temporais ==> sistema assíncronos.

generalizada (bizantina). Para falhas fail-stop, qualquer número de falhas é tolerada.


Em sistemas síncronos, a violação da hipótese de tempo (timing failures) pode resultar na violação da propriedade de safety (agreement)

Para sistemas assíncronos há soluções que preservam safety, apesar das falhas,porém liveness pode ser comprometida.

FD1 P1FD1 P1

FDn Pn

Cada processo é equipado com um failure detector local que mantém uma lista de processos que ele suspeita como crashed.

Um failure detector pode cometer erros :

(i) não suspeitando de um processo que realmente falhou (crashed) ou

(ii) suspeitando de um processo correto (que não falhou)

Assincronia


Completeness : requer que um FD suspeite os processos que de fato falharam.Accuracy : restringe a quantidade de erros que o FD pode cometer.

FDs podem ser classificados por duas propriedades básicas :(ii) suspeitando de um processo correto (que não falhou).

21/9/2010

34

completeness accuracyStrong weak <>strong <>weak

strong

weak

P S <>P <>S

Q W <>Q <>W

Classes de Failure Detectors

Alguns Resultados:

Teorema 1: <> S é a classe de FD mais fraca que permite resolver consenso(Chandra-Hadzilacos-Toueg, 92)

Teorema 2: <> S requer a maioria dos processos corretos (Chandra-Toueg, 91)


Eventually strong failure detector <>SStrong completeness: “eventualmente” cada processo falho (crashed)é permanentemente suspeitado por cada processo correto.Eventual strong accuracy :Existe um tempo a partir do qual algumprocesso correto não é “suspeitato” por nenhum processo correto.

Porque FDs de Chandra-Toueg é um bom modelo ?

10 é o único que resolve consenso sem assumir premissas temporais(síncronas).

20 permite caracterizar as condições em que consenso é solúvel.

30 algoritmo baseado em<> S pode violar terminação(caso as propriedades de <> S não sejam satisfeitas), mas não irá JAMAIS violar correção (safety).


J S ç ( f y)

40 FDs da classe <> S podem cometer um número arbitrário de erros (ex: um processo correto pode repetidamente suspeitar e não suspeitar um outro processo correto).

21/9/2010

35

O protocolo de Consenso baseado em <>S

Paradigma do Coordenador Circulante

Princípios Gerais:Cada processo executa rodadas (rounds) consecutivos de forma assíncrona

Durante o round r, um processo predeterminado pc (c = (r mod n) + 1) atua como coordenador e seleciona um valor. O algoritmo tenta impôr esse valor como o valor da decisão.

Princípios Gerais:


Crashed (ou suspeitas) são tratadas, movendo-se para o próximo round (processos podem decidir em rounds diferentes, mas com o mesmo valor final)

Existirá um round em que o coordenador não é suspeitado (Garantido pela premissa do <> S)

Cada round é composto de 4 fases.

Ex: round 1numa execução sem falhas

p1

p2

p3ackest4 x

xx

x

x


fase 1 fase 2 fase 3 fase 4 (decisão)p4

4 x

21/9/2010

36

Rounds -------- R0 R1 R2 ... Rn-1 Rn Rn+1 ...Coordenador -- p1 p2 p3 ... Pn p1 p2 ...

Pn-1

p1

p2

p1 Quando um processo termina round r,ele imediatamente segue para o round r +1,exceto se já recebeu a msg de decisão

p3

Pn-2

Quando a maioria dos processos mandaramum ack para um valor proposto pelo coordenador,esse valor é preservado (locked) para evitar queoutros processos escolham valores diferentesem futuros rounds

Teorema: O algoritmo resolve consenso usando <>S num SD assíncrono


com número de crashes < n/2

Lema 1 :Termination :cada processo correto “eventualmente”decide um valorLema 2 : Agreement : todos os processos corretos decidem pelo mesmo valor

validity (trivial) + lema 1 + lema 2

Adaptações do algoritmo de Chandra-Toueg para resolver outros problemas, ou resolver problemas em outros modelos de sistema

Decisão mais cedo (early)

Consenso : Guerraoui-Larrea-Schiper, 1995 (in IEEE SRDS)

Algoritmo Original

Atomic-Broadcast : Chandra-Toueg, 1996 (in JACM 43(2))g ( ( ))

Alteração do valor proposto

Prefix-Atomic-Broadcast: Anceaume, A. 1997 (in IEEE FTCS)

Adiamento da entrega do valor

Semi-Passive Replication : Defago-Schiper-Sargent, 1998 (in IEEE SRDS)

Concordar num vetor de valores


Consenso : Hurfin-Tronel, 1997 (in IEEE WFTDSC)

Consenso : Doudou-Schiper, 1998 (in ACM SPDC)

Adiamento de entrega do valor, modificação do valor, possível recusa de resultado

Consenso para Sistemas Móveis : Badache-Hurfin-Macêdo, 1999 (in IEEE IPCCC)

21/9/2010

37

input

E porque não ??

Máquina de Consensus <>S


output

NBACGroup MembershipTotal Orderetc.

Um framework para gerar componentes f p g pde software que implementem variadas técnicas de tolerância a falhas


21/9/2010

38

É possível a construção de um único frameworkpara resolver diferentes tipos de consenso usando <> S ??

Decisão mais cedo (early)

Alteração do valor proposto Atomic broadcastç p p

Adiamento da entrega do valor

Concordar num vetor de valores

Possível recusa de resultado

Resposta : Hurfin-Macêdo-Raynal-Tronel, 1999 (in IEEE SRDS)

Atomic-broadcast,NBACPrefix-Atomic-BroadcastSemi-Passive ReplicationEtc.


A General Framework to Solve Agreement Problems. Hurfin, M. , Macêdo, R., Raynal, M. and Tronel, F. The proceedings of the 18th International Symposium on Reliable Distributed Systems (SRDS'99). Lausanne, Switzerland. IEEE Computer Society. October/1999.

O framework geral (GAF) baseia-se no uso de 6 parâmetros(funções) genéricos. Os códigos das funções devem ser fornecidos

pelo serviço (e.g. replicação) em tempo de compilação.


21/9/2010

39


Fim


tolerância a falhas em sistemas distribuídos : problemas ... · raimundo macêdo, lasid/ufba 1...

Documents