Consenso Distribuído

Roteiro:
• Modelo de Sistema
• O problema do Consenso
• Sistemas Síncronos e o Acordo Bizantino
• Consenso em Sistemas Assíncronos
• Detectores de Falha e o Algoritmo de Chandra & Toueg
• Consistência Interativa e relação entre os problemas

Referências:
ƒ Livro:
Li Coulouris,
C l i SeçãoS ã 11.5
11 5
ƒ Livro: Pankaj Jalote: Fault Tolerance in Distributed Systems, seção 3.1
ƒ Livro: Chow, Johnson, Cap. 11
ƒ D. Dolev, C. Dwork, L. Stockmayer: On the minimal synchronization
needed for Distributed Consensus, Journal of the ACM, 35(2), 1997.
ƒ T.D. Chandra, S.Toueg: Unreliable failure detectors for reliable
distributed systems, Journal of the ACM, 43(2), 1996.
© Markus Endler

O Consenso Distribuído
O Consenso é um problema fundamental em Sistemas
Distribuídos p
pois é:

• utilizado como módulo fundamental de vários

algoritmos onde os processos precisam ter uma visão (ou
ação) idêntica.
Exemplos:
- para ordenação total de eventos (ou mensagens)
- sobre o conjunto de processos não falhos/ativos de um grupo
- colaboração entre agentes em sistemas multi-agentes
-...
• pode-se mostrar a sua equivalência com outros
problemas tais como:
- multicast atômico (confiável + ordem total)
- consistência interativa
- acordo bizantino
© Markus Endler

1
 Modelo do Sistema
Sistema:
• conjunto de processos Pi (i= 1,2,..,N)
• comunicação (por envio de mensagem) é confiável
• processos podem apresentar falhas
Tipos:
-falha de parada (crash)
-falta arbitrária (bizantina)
• até f processos podem falhar simultaneamente

•em alguns casos assumiremos que mensagens

recebem uma assinatura digital para garantir
a autenticidade do remetente
Îimpede-se que processos faltosos possam falsificar identidade
do remetente
© Markus Endler

O Problema de Consenso
Definição do problema:
„ Existem N processos, dos quais f processos
apresentam
t falhas.
f lh
„ cada processo Pi propõe um único valor vi ∈ D
„ todos os processos interagem para a troca de valores
entre sí
„ em algum momento, os processos entram no estado
“decided” em que atribuem um valor para a variável
de decisão di (que não é mais alterada)

Obs: O valor de di é uma função dos valores vi

fornecidos pelos N-f processos corretos.

© Markus Endler

2
 Exemplo
d1=OK d2=OK
P1 P2

v1=OK v2=OK

Algorítmo de Consenso

v2=NOK

P3

• P3 propõe NOK, mas falha durante o consenso

• os processos corretos decidem por OK
© Markus Endler

Principais Requisitos
Terminação:
Em algum momento, cada processo correto atinge o
estado “decided” e atribui um valor à variavel de decisão
di
Acordo:
todos os processos corretos atribuemo mesmo valor para
a variável de decisão
Integridade
se todos os processos corretos propuseram o mesmo
valor vi =v, então qq processo correto em “decided”
também terá decidido di =v
Integridade (alternativa mais fraca – depende da aplicação)
o valor de di (i=1,2,..,N) deve ser necessariamente igual ao
valor proposto por um Pi correto

© Markus Endler

3
 Um Algoritmo simples
Assuma um Grupo de processos corretos não faltosos.
Cada processo Pi :
„ usa multicast confiável para mandar o valor vi para os
demais
„ espera até receber N-1 mensagens
„ Define o valor de di usando uma função deterministica:
‹ maioria(v1,v2,..,vN), ou ⊥ se não houver maioria,
‹ máximo (v1,v2,..,vN) ou mínimo(v1,v2,..,vN)
‹ média (v1,v2,..,vN)
‹ ...
ÎTerminação é garantida pelo multicast confiável.
Î Acordo e integridade garantidos pelo uso da mesma
função (determinística) e do multicast confiável
Mas e se processos podem falhar (crash ou bizantinos)?
© Markus Endler

O Consenso com falhas

ÎSe processos podem ter falhas tipo crash (omissão),
então a terminação não estará garantida, a menos que
se detecte a falha.
ÎSe o sistema é assíncrono
assíncrono, pode ser impossivel
distinguir um crash de uma mensagem que demora
um tempo indeterminado.
Î Fischer, Lynch & Paterson(*) apresentaram um resultado
teórico fundamental: Î é impossível garantir a obtenção de
consenso em um sistema assíncrono com falhas tipo crash

Î Se processos podem apresentar falhas abitrárias

(bizantinas), então processos falhos podem comunicar
valores aleatórios aos demais processos, evitando que
os corretos tenham a mesma base de dados
{v1,v2,..,vN}, para a tomada de uma decisão uniforme.
(*) Fischer, Lynch, Paterson: Impossibility of Distributed Consensus
with one faulty process, Journal of the ACM, v.32 (2), 1985.
© Markus Endler

4
 Consenso em sistemas síncronos
[Dolev & Strong83] propuseram um algoritmo para o consenso entre N
processos que tolera até k falhas tipo “crash” em um sistema
síncrono.

Ideia central: O algoritmo executa k+1 rodadas: Na rodada j todos os

processos corretos difundem para todos os demais processos o
conjunto de novos valores (propostos) v obtidos na rodada j-1.
Inicialmente, difundem o próprio valor proposto.
Ao final, executam uma função idêntica (p.ex. min/max) sobre o
conjunto de valores coletados.

ç
Observações:
• processos usam multicast não-confiável, mas sabe-se que a duração
máxima de cada difusão é ∆.
• a variável Valuesj contém o conjunto de valores obtidos na rodada j
• Os timers tem identificadores (que identificam a rodada corrente)

© Markus Endler

Consenso em sistemas síncronos

Algorítmo no processo Pi do grupo G:

Set_of_elem: Valuesj (0≤ j ≤ k+1); setV;

Elem: vivi, di;
Inicialização:
Values0:={};
Values1={vi}; // próprio valor proposto
r = 1; // inicializa a rodada corrente
while (r ≤ k) {
set_timer(r, ∆); // timeout para rodada r
mcast(G, Valuesr – Valuesr-1); // difunde a diferença dos conjuntos
Valuesr+11 = Valuesr;
loop {
receive(Pj,setV) => Valuesr+1 = Valuesr+1 ∪ setV;
timeout(r) => {r = r+1; exit; } // incia nova rodada
}
}
di = min(Valuesr); // seta a variável de decisão
© Markus Endler

5
 Consenso em sistemas síncronos
Corretude do Algoritmo de Dolev&Strong:
Terminação: obvio, pois algoritmo termina após ∆*(k+1)
Acordo e Integridade: decorrem do uso da função min e se for mostrado
que ao terminar, todos os processos têm conjuntos Valuesk+1
idênticos

Proposição: Pi.Valuesk+1 = Pj.Valuesk+1 para ∀i,j ∈ N

Prova (contradição): Suponha v ∈ Pi.Valuesk+1 e v ∉ Pj.Valuesk+1. Então
existe um Pk, com v ∈ Pk.Valuesk e que falhou (crash) durante o
multicast na rodada k, entregando v para Pi mas não para Pj. Mas se
v ∈ Pk.Valuesk e v ∉ Pj.Valuesk, isto significa que existe um Pw, com
v ∈ Pw.Valuesk-1 que falhou na rodada k-1, entregando v para Pk
mas não
ã para PjPj, e assim
i por di
diante...
t
Desta forma, conclui-se que houve uma falha (crash) por rodada, mas
por suposição houve no máximo k falhas.

Î Dolev&Strong mostraram que qualquer algoritmo para obter o

consenso na presença de k falhas requer pelo menos k+1 rodadas.
Î Este limite inferior também vale para falhas arbitrárias (Problema do
Acordo Bizantino) © Markus Endler

Alguns artigos sobre Consenso

„ Francisco Brasileiro et al,: Consensus in one communication step,
Tech Report. Université Rennes 1, 2002.
‹ Convergência rápida em “situações favoráveis”
„ R G
R. Gerraoui,i A
A. S
Schiper,
hi C
Consensus: th
the Big
Bi Misunderstanding,
Mi d t di 6th
IEEE CS workshop on Future Trends of Distributed Computing
Systems, 1997
„ Badache, Hurfin, Macedo: Solving the consensus in a Mobile
Environment, Relatório Técnico, IRISA, nov. 1997.
‹ Consenso para redes móveis estruturadas (nós fixos da rede
agregam votos)
„ M. Barborak, M. Malek, A. Dahbura, The Consensus Problem in Fault-
Tolerant Computing, ACM Computing Surveys, vol. 25, no.2, 1993.
„ L.J Camargos, E. Madeira: DisCusS: desenvolvendo um serviço de
consenso genérico, simples e modular. Dissertação de mestrado,
IC/UNICAMP
„ Wei Ren, Beard, Atkins, A survey of Consensus problems in multi-
agent coordination, American Control Conference, 2005

© Markus Endler

6
 Acordo Bizantino
“Problema dos Generais Bizantinos – PGB”
O PGB foi inicialmente proposto por L.Lamport (82) e equivale ao
problema de consenso em um sistema com falhas arbitrárias.
Motivação:
„ N generais (dentre eles, 1 comandante) devem concordar sobre
esperar ou atacar uma cidade sitiada, que só conseguem
conquistar se todos os batalhões atacarem conjuntamente.
„ O comandante dá a ordem (atacar/esperar), e os generais devem
ter certeza que receberam o mesmo.
„ Alguns dos generais (ou o comandante) são traidores e tentam
atrapalhar o consenso, divulgando para uns que receberam a
ordem de atacar,, e p
para outros a ordem de esperar.
p

A principal diferença entre o PGB e consenso: um dos processos

fornece um valor que deve ser acordado entre todos os
processos corretos (ao invés de um valor proposto por cada
processo, como no consenso)

© Markus Endler

O Problema do Acordo Bizantino

Os requisitos:
„ Terminação: Em algum momento, cada processo entra no estado
“decidido” e atribui um valor à sua variável de decisão di
„ Acordo: Se pi e pj são corretos e estão no estado “decidido”
decidido , então di
= dj
„ Integridade: Se o comandante está correto, então todos os processos
usam como valor de di o valor proposto pelo comandante.
Suposições:
„ Possibilidade de falhas arbitrárias = envio de qualquer msg a qualquer
momento, ou omissão de envio
„ Até f processos (de N) podem falhar
„ Processos corretos conseguem detectar ausência de mensagem
(usando timeouts), e neste caso assumem recebimento de um valor
default Î mas são incapazes de detectar falha do processo
„ Canais de comunicação são seguros: não é possível interceptar e
modificar mensagens em trânsito
Idéia de solução: todos contam para todos o que receberam do
comandante
© Markus Endler

7
O Problema do Acordo Bizantino
Impossibilidade de solução para N=3 e f=1 [Lamport,Pease,Shostak82]:
Dois possíveis casos:
„ Comandante (iniciador) é traidor
„ U generall é ttraidor
Um id
Obs: mensagem “3:2:a” significa “P3 diz que P2 diz que comando é a(ttack)”
mensagem “3:2:w” significa “P3 diz que P2 diz que comando é w(ait)”

C C
1:a 1:a 1:a 1:w

2:1:a 2:1:a
p2 p3 p2 3:1:w
p3
3:1:w

(A) General traidor (B) Comandante traidor

Îas duas configuração não são distinguíveis para P2.

© Markus Endler

O Problema do Acordo Bizantino

Esboço da Prova:
Em (A) C esta correto. Pelo Requisito de Integridade, P2 precisa
decidir o valor recebido de C.
C
Como P2 nãoã di
distingue
ti as duas
d configurações,
fi õ em (B) vaii d
decidir
idi
também pelo valor recebido de C
O mesmo se aplica ao P3 correto (que não sabe se C ou P2 é o
traidor). Logo P3 sempre decidiria pelo valor recebido de C.
Mas então, no caso (B), P2 e P3 teriam decidido por valores
distintos (w e a), o que contradiz o Requisito de Acordo.
Logo, não pode existir solução.

Note que o problema todo está no fato de que no caso (A), o

processo P3 forjou a informação recebida de C, e que P2 é
incapaz de distinguir os dois casos.
Obs: Se os generais usarem assinaturas digitais em suas
mensagens (ou seja, as mensagens originais não puderem ser
forjadas), então o PGB para N=3*f tem solução.
© Markus Endler

8
 O Problema do Acordo Bizantino
Pease,Shostak,Lamport mostraram que o problema de
impossibilidade do PGB para qualquer N ≤ 3*f é redutível
ao problema N=3 e f=1f=1.
Idéia:
Faça 3 processos P1,P2 e P3 simularem o comportamento
de n1, n2, n3 generais, respectivamente, tal que:
„ n1+n2+n3 = N
„ n1, n2, n3 ≤ N/3 + 1
„ P
Processos corretos
t simulam
i l o comportamento
t t de
d
generais corretos
„ Um dos processos só simula generais traidores (possível,
pois como no máximo f generais são traidores, N ≤ 3*f e
n1, n2, n3 ≤ N/3 +1 )

© Markus Endler

Exemplo
F C

F F C C

F C
P1 P2
C

C C

P3
„ N=11 e f=4

© Markus Endler

9
 O Problema do Acordo Bizantino

Como supostamente o programa de simulação dos generais

está
tá correto,
t a simulação
i l ã ttermina.
i

Suponha que os N – f generais corretos conseguissem

chegar ao consenso.
Neste caso, os processos simuladores correspondentes
teriam chegado ao consenso (pegando o valor decidido
pelos seus generais simulados)
simulados), o que contradiz o
resultado para N=3 com f=1.

© Markus Endler

O Problema do Acordo Bizantino

A solução para N=4 e f=1 requer apenas 2 (e.g f+1) rodadas.

0a rodada: comandante difunde os comandos

1a rodada:
C C
1:a 1:a 1:a 1:u 1:a 1:w

2:1:a 2:1:u
p2 3:1:u
p3 p2 3:1:w
p3
4:1:a 4:1:a 4:1:a 4:1:a
2:1:a 3:1:w 2:1:u 3:1:w

p4 p4
(A) General traidor (B) Comandante traidor

© Markus Endler

10
 O Problema do Acordo Bizantino
Msgs do p3 C
3:1:u
traidor: 1:u 1:w
3:1:w 1:a
2a rodada:
2:4:1:a
p3 p2 p3
p2 3:4:1:a
4:3:1:w
4:3:1:w 4:2:1:u 3:2:1:u

2:3:1:u 2:3:1:w
Î P3 é traidor! Î C é traidor!
pp4 pp4
(A) General traidor (B) Comandante traidor

P2 terá obtido: P4 terá obtido: P2 obterá: P3 obterá: P4 obterá:

• 1:a • 1:a • 1:u • 1:w • 1:a
• 3:1:u • 3:1:w • 3:1:w • 4:1:a • 2:1:u
• 4:1:a • 2:1: a • 4:3:1:w • 2:3:1:w • 3:2:1:u
• 4:3:1:w • 2:3:1:u • 3:4:1:a • 4:2:1:u • 2:3:1:w
© Markus Endler

O Problema do Acordo Bizantino

Vejamos os 2 casos:

(A): todos os corretos terão recebido N-2

N 2 versões do valor
proposto por C e terão recebido valores inconsistentes do
processo traidor (P3).

(B): todos os corretos terão recebido valores inconsistentes do

Comandante, concluindo que este é o traidor.

Em ambos os casos, aplicando-se a função maioria* sobre os

valores originalmente
g p
propostos
p p
pelo Comandante, chega-se
g
• ao mesmo valor ou
• valor default quando não há valor majoritário, p.ex.
maioria(u,a,w) = w

• Portanto, cada um dos generais corretos irá tomar a mesma

decisão (atacar ou esperar).

© Markus Endler

11
O Problema do Acordo Bizantino
O Algorítmo Geral funciona em f+1 rodadas:
1. Comandante C manda comando para todos
2. Em cada rodada, um general P difunde os valores recebidos de Q
para todos demais, exceto C e Q
3. Todos os generais executam maioria sobre todas as msgs recebidas
Obs: Se um processo deixar de enviar em uma rodada, considera-se que
enviou ⊥

A Eficiência de uma solução para o PGB é dada pelo:

„ Número de rodadas
„ Quantidade de mensagens (e seu tamanho) necessárias
Î O número de rodadas mínimo é f+1 [Fischer&Lynch82].
Î no algorítmo acima o número de mensagens é O(Nf+1), mas existem
otimizações, em especial, se as mensagens contém assinatura
digital, pode-se obter número de mensagens = O(N2)
Î O alto custo do algoritmo só se justifica em sistemas em que há
problemas de segurança. Se defeitos são de hardware, então falhas
não são realmente arbitrárias.
© Markus Endler

Consenso: Impossibilidade em
Sistemas Assíncronos
[Fischer,Lynch,Peterson85] mostraram que o consenso
em um sistema assíncrono (com a possibilidade de
um único processo falho tipo “fail-stop”) não tem
solução, isto é, não existe algoritmo que garanta o
consenso em qualquer processamento.
Principal Razão:
„ Consenso com falha (crash, arbitrária) requer que
cada processo receba um conjunto completo de
valores de todos os demais processos corretos Î só
assim consegue
g criar uma base idêntica de valores
para a tomada de decisão comum.
„ Devido a inexistência de um limite superior para o
tempo de comunicação, não é possível distinguir uma
falha de processo (fail-stop), de uma mensagem
muito demorada (falha de temporização)

© Markus Endler

12
Consenso: Impossibilidade em
Sistemas Assíncronos
A idéia da prova da impossibilidade:
Assume-se a existência de um adversário “muito
esperto”
p q
que seria capaz
p de p perpetuar
p
indefinidamente a execução do protocolo através de:
‹ Atraso imprevisível de mensagens em determinados
momentos
‹ Aceleração ou retardo da velocidade de um processo
de forma que este permaneça sempre fora de
sincronia com a atividade dos demais processos
Mesmo q que seja
j muito improvável
p q
que exista uma rede
(ou usuário) que seja capaz de interferir no
consenso de forma tão metódica e ágil Î o consenso
não pode ser garantido...
... mesmo que (na maioria dos casos) o consenso possa
ser alcançado.

© Markus Endler

Abordagens para lidar com a

Impossibilidade
Levando em conta que:
„ o consenso é um serviço fundamental
„ a maioria dos sistemas são assíncronos
Como resolver? Possíveis abordagens:
„ Eliminar a possibilidade de falhas “fail-stop”:
‹ Idéia: Manter o estado atualizado de cada processo em
memória persistente. Após uma falha, processo é
reiniciado a partir do estado salvo. Os demais processos
só percebem um atraso na execução do processo
„ Usar detectores de falha Î (a seguir...)
„ Usar algoritmos randômicos
‹ Idéia: Comportamento randômico do algoritmo impede
que o adversário esperto consiga sistematicamente
impedir o consenso
‹ Obs: Não vai garantir que consenso seja sempre
alcançado, mas com certa probabilidade (dependendo do
sistema) e após tempo T, todos os processos saberão se
consenso foi ou não atingido.
© Markus Endler

13
Outros Modelos
O modelo síncrono é muito restrito (e.g. muito “otimista”),
o modelo assíncrono é muito geral (“pessimista”)
Isto levou pesquisadores a definirem modelos
intermediários entre os dois, e que não estão sujeitos
ao teorema da impossibilidade de FLP, por fazerem
hipóteses sobre as falhas de temporização (delays
arbitrários na execução ou comunicação).
São eles:
„ Modelo de sincronia parcial (partially synchronous
model)
„ Modelo de assincronia temporal (timed asynch. model)
„ Modelo assíncrono com detectores de falha(*)
(*) um detector de falhas pode suspeitar da falha de um processo,
e pode errar se esse estiver correto
© Markus Endler

Outros Modelos

Modelo de sincronia parcial (partially synchronous)

“...existe um momento t a partir do qual não existem mais falhas de
temporização”
Modelo de assincronia temporal (timed asynchonous model)
“...a execução do sistema alterna entre períodos de estabilidade e
instabilidade, sendo que no primeiro não correm falhas de
temporização.”
Modelo assíncrono com detectores de falha
“... existe um momento t a partir do qual um processo correto nunca
mais é suspeito de estar faltoso, por qualquer outro processo
correto.”

© Markus Endler

14
 Detectores de Falha
Um Detector de Falha (DF) é um serviço que pode ser consultado
para informar sobre o estado de qualquer processo P.
Retorna um de dois possíveis valores:
DF(P) = { Suspected(P), Unsuspected(P)}, onde:
„ Suspected(P) :: há indícios de que P esteja falho (“crashed”)
„ Unsuspected(P):: há indícios de que P esteja correto (ativo)

A maioria dos DF não fornece quaisquer garantias sobre a

informação fornecida, isto é, são não-confiáveis (“Unreliable
FD”), podendo ser:
„ Imprecisos: podem suspeitar de processos ainda ativos (falso
positivo)
„ Incompletos: podem deixar de identificar processos falhos
Definição: DF confiáveis (DFC) são completos, e cujos valores
retornados são:
DFC(P) = {Failed(P), Unsuspected(P)}, onde:
„ Failed(P):: significa que o DFC definiu que P está falho (mesmo
que de fato esteja correto)
„ Unsuspected(P):: como no caso de DF © Markus Endler

Detectores de Falha: Implementação

DF geralmente são implementados através de processos
(threads) monitores executando em cada nó
„ a cada T unidades de temp, difunde uma mensagem
“heartbeat” para todos os demais monitores do grupo
„ Se um monitor não recebe um sinal de vida de um outro
monitor P após T+ k*D desde a última mensagem
recebida, então este retorna Suspected(P)
„ O processo de aplicação consulta o DF local, e recebe
uma lista dos processos suspeitos.

Appl. P alive?

heartbeat
DF DF

© Markus Endler

15
Detectores de Falha: Implementação
Em sistemas assíncronos, não há nenhuma garantia de que
mensagens serão transmitidas em D unidades de tempo.
Se T for pequeno demais:
‹ Aumenta a probabilidade de suspeitas falsas
‹ Aumenta o tráfego na rede
Se T for grande demais:
‹ Processos falhos podem demorar para serem
descobertos
‹ Falhas transientes podem permanecer desapercebidas
Na prática,
prática usa
usa-se
se um ajuste dinâmico do timeout:
‹ p.ex. Se heartbeat chega após T+D(mas antes de
T+2D) ajusta-se proximo timeout para T+2D, até um
certo limite, de T+ n*D.
Obs: Em sistemas síncronos, os DF são sempre confiáveis:
usa-se D = tempo máximo de transmissão de msgs
© Markus Endler

Detectores de Falha & Consenso

Os algoritmos mais populares para consenso usam um
DF.

A idéia central:
„ Desconsiderar as mensagens de um membro do
grupo suspeito de ter falhado (“fail-silent”).
„ Desvantagem: se DF é impreciso, então pode-se ter
suspeitas falsas, e possivelmente reduz-se
desnecessariamente o número de processos
Î Usando um DF embute-se todo tratamento temporal
no DF e simula-se um sistema síncrono.

Esta abordagem é usada em alguns serviços para

comunicação de Grupo (p.ex. ISIS/Cornell)
© Markus Endler

16
Detectores de Falha & Consenso
[Chandra,Hadzilacos,Toueg96] desenvolveram um
algoritmo para consenso em sist. assíncronos que
usa um DF não-confiável e que permite que
processos suspeitos (erroneamente) continuem
participando do grupo, e:
„ mostraram que o consenso em um sist. assíncrono
pode ser atingido com estes DF, contanto que f < N/2
e que a comunicação seja confiável
„ e definiram 8 classes de DF, segundo as
propriedades de Completude e Precisão.

Referências:
[Chandra,Toueg,94]. Chandra, Toueg: Unreliable Failure Detectors for Reliable
Distributed Systems (1994), Journal of the ACM, 1994.
[Chandra,Hadzilacos,Toueg,96] The weakest failure detector for solving
Consensus, (1996), http://citeseer.ist.psu.edu/chandra96weakest.html

© Markus Endler

Detectores de Falha & Consenso

Completude (Completeness):
‹ 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.

Precisão (Accuracy) Fraca, Forte, Eventualmente Fraca e Eventualmente

Forte:
‹ 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.

© Markus Endler

17
Detectores de Falha & Consenso
Strong Weak Eventual Eventual Weak
Accuracy Accuracy Strong Accuracy
Acc.
Strong Perfect Strong S ാP ാS
p
completeness P

Weak Q Weak W ാQ ാW
Completeness

„ O “Eventually Weak FD (EWFD)”, ാW é aquele que têm as

propriedades mínimas necessárias para o consenso:
‹ Completude Fraca: após um certo tempo, cada processo
falho será suspeito por algum processo correto
‹ Precisão EW: após um certo tempo
tempo, pelo menos um
processo correto não é suspeito de falha por qualquer
processo correto
„ Chandra&Toueg também mostraram que não é possível
implementar um EWFD em sistemas assíncronos apenas
com o envio de mensagens.
„ Mas mostraram que o DF com time-outs adaptativos é
uma ótima aproximação para o EWFD © Markus Endler

O Algorítmo de Chandra&Toueg
Em vez de ാW, vamos mostrar o algoritmo que
funciona para um FD um pouco mais forte, o ാS
(Eventual-weak Accuracy & Strong Completeness)

‹ Completude Forte: Qualquer processo falho em

algum momento é suspeitado permanentemente
por todos os processos corretos.
‹ Precisão Eventualmente Fraca: Depois de certo
tempo, algum processo correto não será suspeito
por algum outro processo.
processo

© Markus Endler

18
O Algorítmo de Chandra&Toueg
Princípio (para cada consenso):
„ Executa um número indefinido de rodadas assíncronas r,
onde em cada rodada um dos N processos faz o papel de
coordenador (usa Paradigma do Coordenador Rotativo)
„ Todos os processos sabem qual processo será o
coordenador na rodada r. Exemplo: c = (r mod N) +1
„ Em vez de executar uma função comum f(v1,v2,..,vN), o
coordenador da rodada corrente sugere como valor de
decisão d um dos vis recebidos (estimativa g) e difunde-os
para os demais,
„ Cada Pi que recebe valor do coordenador “muda
muda de
opinião”, re-setando o seu valor proposto vi ← g e envia
uma confirmação.
„ O coordenador tenta coletar (n+1)/2 confirmações, e se
conseguir, congela g como novo valor de decisão e
difunde de forma confiável o g como resultado do
consenso para todos.
© Markus Endler

O Algorítmo de Chandra&Toueg
Cada consenso consiste de 4 etapas (que podem demorar
várias rodadas):
1) Cada processo Pi envia o seu vi com o seu número de
rodada atual para o “coordenador
coordenador da vez”
vez C
2) C recolhe (n+1)/2 mensagens, escolhe o valor g com
o maior time-stamp, e difunde este valor para todos Pi
i∈[1,N]
3) Em cada Pi pode acontecer:
1) Recebe g de C ⇒ adota g como seu valor e retorna
ack para C
2) Seu DF notifica: Suspected(C) ⇒ envia um NACK
para C
4) Se C receber  (n+1)/2 ACKS, faz multicast confiável(1)
para todos indicando o valor escolhido

(1) Garante que se um processo correto entregou m, então todos os processos

corretos em algum momento entregam m.
© Markus Endler

19
 Troca de mensagens em rodada r

v1,TS p1 ack pp1

c v2,TS
c nack
p2 p2
a) Todos processos enviam votos para c) Processos que suspeitam da falha
Coordenador, e assim que coordenador de C, enviam nack
receber (n+1)/2 mensagens,
escolhe g=vi de maior TS
g,maxTS,decided
p1
g,maxTS p1 c
g,maxTS, decided p2
c g,maxTS
p2 d) Se coordenador receber (n+1)/2 acks,
Então faz um multicast confiável com o
b) Coordenador difunde o g valor decidido
© Markus Endler

O Algorítmo de Chandra&Toueg
Procedure propose(vi)
g = vi; // estimativa incial
decided = false;
r = 0; TS = 0;
while (¬ decided) {
r++;;
C = (r mod N) +1;
1: send(C, r, g, TS); // cada processo envia sua estimativa
2: if (C == myself) { // coordenador escolhe um valor com max time-stamp
espere por (n+1)/2 mensagens (q, r, e, ts) e armazene em msg[r]
T = max( { ts | (q, r, e, ts) ∈ msg[r]})
g = { e | ts == T ∧ (q, r, e, ts) ∈ msg[r] }
mcast(all, r, g, T);
}
3: when received(C, r, e, ts) ⇒ { g = e; T = r; // adota estimativa e envia ack
send (C, r, ack); }
when received (DF, (DF suspected (C)) ⇒ send (C, (C rr, nack);
4: if (C == myself) { // coordenador difunde se tiver recebido maioria acks
espere por (n+1)/2 mensagens (q, r, ack) ou (q, r, nack)
if (# acks >= (n+1)/2 ) {d = g; R-mcast(all, r, d, decided) }
}
when ¬ decided && R-receiv (any, r, g, decided) { // escolha final
d = g; decided= true;
}
}
© Markus Endler

20
Terminação de Chandra&Toueg
Proposição: Cada processo correto eventualmente chega ao estado
decided.

Dois Casos:
a) Se um Pi correto decide, então este executou R-receive
(..,decided). Pela propriedade de R-mcast, todos decidem.
b) Nenhum processo correto em algum momento decide. Precisa-
se mostrar que isto não ocorre:
1. Que nenhum processo correto fica indefinidamente
bloqueado em qualquer comando “espere”.
2 Que existe um processo coordenador que recebe (n+1)/2
2.
acks

© Markus Endler

Terminação de Chandra&Toueg
Prova de 1:
• Seja r a menor rodada em que um processo correto fica
bloqueado. Logo todos os processos corretos executaram etapa
1 da rodada r e enviaram ((n+1)/2) estimativas para C. (pois
etapa 1 não é afetada pelo bloqueio).
bloqueio)
ƒ Como comunicação é confiável, em algum momento C recebe
todas as estimativas e executa mcast(all, r, e, T), que faz com
que todos os corretos eventualmente recebam a mensagem e
não fiquem bloqueados.
ƒ Se C falhar, devido a completude forte de ാS, para todos os
processos corretos, existe um momento em que a falha de C é
permanentemente detectada (suspected(C))
ƒ Portanto nenhum processo correto fica bloqueado na etapa 3
Portanto, 3, e
todos enviam ACK ou NACK para C. Como existem ((n+1)/2)
corretos, C também não pode ficar bloqueado na fase 4.
ƒ Logo, todos os processos corretos irão completam a rodada r.

© Markus Endler

21
Terminação de Chandra&Toueg
Prova de 2: Existência de um Pi que decide:

ƒ Como DF satisfaz Precisão EW, existe um processo Q e um

instante de tempo τ, de forma que nenhum processo correto
suspeita da falha de Q. Seja t’ > τ tal que todos os processos
falhos já falharam (e Q não foi suspeitado).
ƒ Então deve existir uma rodada r tal que:
ƒ Todos os processos corretos chegam à rodada r > t’
ƒ Q é o coordenador de r, ou seja Q = (r mod N) +1
ƒ Nesta rodada r, todos os processos corretos enviam suas
estimativas para Q, que difunde a de maior TS. Como nenhum
p
suspeita de Q em r, (n+1)/2
( ) mandam um ack p para Q, q
que
executa o R-mcast para todos.
ƒ Devido às propriedades do R-mcast, em algum momento todos
irão executar o R-receive, e vão chegar ao estado “decided”.

© Markus Endler

Chandra & Toueg em Rede Móvel

Solving The consensus problem in a Mobile Environment, N.
Badache, M. Hurfin, R. Macedo, Publication Interne 1146,
IRISA França
IRISA,

„ Modelo de Rede móvel estruturada (MHs e MSSs)

„ Cada um dos N MHk propõem um valor vk e todos os MHs
precisam concordar sobre mesmo conjunto de valores
„ MSSs são os representantes de todos os MHs em sua área
de cobertura (isto pode mudar Î handover)
„ MSSs vão coletando os votos dos MHs, executam o
algoritmo de consenso, e assim que o conjunto de valores
propostos fica estável entram no estado decided , e notificam
os MHs do resultado

© Markus Endler

22
O Algoritmo Paxos
Paxos [Lamport, 98] é outro algoritmo para consenso de
N processos baseado no paradigma do líder.
Usa o detector de falha Ω, que retorna somente um valor -
o de um processo correto, e garante:
Existe um momento t a partir do qual existe
extamente um processo correto PL que nunca é
suspeito por qualquer outro processo correto.
Idéia basica do Paxos: A cada momento cada processo
considera um pprocesso correto ((PL)) como líder
(escolhido por Ω) , e é este líder que tenta chegar ao
consenso. Se PL falha, em algum momento Ω vai
selecionar outro processo correto como líder.
L. Lamport, The Part-Time Parliament, ACM Transactions on Computer systems
Nr. 16, 2, May 1998. começa: “Recent archeological discoveries on the island of
Paxos reveal that the parliament functioned ...” © Markus Endler

Paxos
Se um processo Pi se considera líder, inicia um novo
“round”, que pode assumir valores(*):
RoundNumber (RN): i, i+n, i+2n, i+3n, ... etc.
Desta forma, cada número de rodada será único. Isto é
necessário, pois vários processos podem se considerar
líderes simultaneamente, e portanto, vários consensos
podem estar acontecendo concomitantemente.
Cada rodada consiste de 2 fases:
1.Líder
1 Líder verifica se os participantes ainda não participaram de um
consenso com número de rodada maior ,e espera por confirmação
da maioria (se recebe um NACK, aborta e passa para nova
rodada).
2. Líder envia um accept_req para os participantes com o valor de
consenso proposto, e espera por confirmação da maioria, Se
recebeu, confirma para todos.
© Markus Endler

23
 Paxos
Fase 1:
„ Líder difunde “prepare(RN)” para todos
„ Particpante aceita, i.e. responde com ACK (v, RN) (*) sse:
‹ RN é maior
i d do que qq propostat d
de consenso aceita
it e
‹ ainda não aceitou a nenhuma proposta com número de rodada
> RN
„ Senão,responde com NACK, e rejeita o
(*) o ACK vem com o RN do momento em que a proposta foi aceita
„ Líder espera a resposta de pelo menos N+1/2. Se só recebeu
ACK, decide qqual é o valor a ser p
porposto,
p senão aborta o p
processo
e recomeça Fase 1 com RN+n.
Fase 2:
„ Líder difunde msg “accept (d)”, e espera resposta da maioria com
ACK. Se for o caso, difunde a msg decided, senão aborta o
consenso e redefine o RN

© Markus Endler

Paxos
Propose(v) Decided(d))
ACK Succeed
prepare Confirmed accept ACK -Voted
PL

P2

P3

P4
Fase 1 Fase 2

© Markus Endler

24
Consistência Interativa
É uma variante do problema do consenso.
Para N processos, todos os processos corretos devem entrar
em acordo sobre um vetor de valores v[N], onde cada
elemento
l d
do vetor v[i]
[i] corresponde
d ao valor
l proposto por
processo Pi.
Exemplo: v[i] poderia conter o estado de Pi (correto ou
faltoso)

Requisitos da Consistência Interativa CI(v1,v2,..,vN):

„ Terminação: em algum momento todo processo correto
chega
h ao estado
t d “d
“decided”;
id d”
„ Acordo: O vetor de todos os processos corretos no estado
“decided” é idêntico;
„ Integridade: Se Pi está correto e vP[i]=x, então todos os
processos Q tem vQ[i]=x.

© Markus Endler

Equivalência dos Problemas

De fato, Consenso (C),o PGB e a CI são equivalentes.
Assuma que existem algoritmos que resolvam:

„ Ci(v1,v
v2,..,v
vN) retorna o valor de decisão de Pi
Pi, onde
v1,v2,..,vN são os valores propostos pelos processos

„ PGBi(j,v) retorna o valor de decisão de Pi para a proposta

de Pj (o comandante)

„ CIi(v1,v2,..,vN)[j] retorna o j-ésimo valor do vetor de decisão

de Pi, onde v1,v2,..,vN são os valores propostos pelos
demais processos

Sem perda de generalidade, pode-se assumir que um

processo incorreto/traidor propõem um único valor
possível (mas incorreto1) para todos, em vez de diferentes
valores para cada um.
(1) incorreto = que impede a decisão coordenada
© Markus Endler

25
 Equivalência dos Problemas
Construindo uma solução a partir de outra conhecida:

CI usando PGB:
„ Execute PGB N vezes,
vezes uma vez para cada processo no
papel de comandante, e use
CIi(v1,v2,..,vN)[j] = PGBi(j,vj)

Consenso usando CI:

„ Execute CI e calcule o valor de decisão usando maioria
dos elementos do vetor acordados, ou seja
Ci(v1,v2,..,vN)= maioria(CIi(v1,v2,..,vN)[1], .. CIi(v1,v2,..,vN)[N])

PGB usando Consenso:

„ O comandante Pj envia o seu valor para os demais e para
sí próprio, e todos executam o consenso para os valores
v1,v2,..,vN que receberam, e cada Pi decide:
PGBi(j,v) = Ci(v1,v2,..,vN) para i=1,..N
© Markus Endler

Segundo Trabalho de AD’08

Relatório de simulações: 23/06
Demonstração: 30/06
Tarefa:
„ Implementar o algoritmo de Chandra, Hadzilacos &
Toueg para consenso em sistemas assíncronos
„ Sistema simulado:
‹ Comunicação confiável (não há perda de mensagens)
‹ No envio de qualquer mensagem p/outro processo
escolhe-se um atraso arbitrário
‹ Permite-se
P it até
té n/2
/2 falhas
f lh permanentes
t ded processos
(pe.x. sorteie quais processos poderão falhar)
‹ Ativação de consenso simultânea em todos os
processos (por comunicação ou mecanismo sem
atraso)

© Markus Endler

26