Coordenação e consenso

Nazareno AndradeUniversidade Federal de Campina Grande

02/2008

Sistemas Distribuídos

2

FundamentosCoordenando processosConstruíndo sistemasSistemas construídos

3

FundamentosCoordenando processosConstruíndo sistemas

– Sincronização– Eleição e consenso– Replicação

Sistemas construídos

4

Objetivos

Entender algoritmos de eleição

Entender algoritmos de consenso famosos e o espaço de soluções

5

Problema da eleição

Diversos algoritmos distribuídos são facilitados com o conceito de líder– Multicast ordenado com coordenador– Sincronismo com coordenador– Redes p2p com supernós

Algoritmos de eleição elegem líders eficientemente– Safety: num instante, todos os nós ou escolheram P ou ainda não

escolheram nó algum– Liveness: em algum momento, nós escolhem um líder ou falham

Consideramos que nós já tem valor que determina eleito e podem falhar

6

Algoritmo do valentão

Cada processo conhece o id de todos os outros

Quando alguém percebe a falha do líder, inicia eleição– Contacta nós com id mais alto, – Cada um deles responde como novo encarregado inicia

uma nova eleição– Quando um novo encarregado inicia eleição e não recebe

respostas, ele é o novo líder e avisa os demais

7

Note que qualquer processo poderia falhar no caminhoE que esse algoritmo só é prático para grupos pequenos

– Pior caso gera O(n^2) mensagens

8

Algoritmo de anel

Nós se organizam numa topologia de anelQuando um nó percebe que líder anterior

falhou, inicia eleição– Passa vetor com seu id adiante no anel– Quando recebe vetor de volta com seu id, o

vetor deu a volta e quem tem o maior id é o novo líder

Em média mais eficiente que o algoritmo do valentãoPorém ainda adequado apenas para grupos

pequenos

9

Eleições em grande escala

Problema: eleger uma série de supernós em um sistema p2p

Abordagem 1: numa DHT, nós responsáveis por ids que satisfazem uma condição são supernós– Supernó com id == (k AND 11100000) é o responsável pelo nó com

chave k– Sou supernó == sou responsável por (meuID AND 11100000)?

Abordagem 2: oganizar nós em um espaço geométrico imaginário e distribuir fichas entre eles– Cada nó procura se seus vizinhos têm fichas– Fichas exercem força de repulsão e fazem nós as transmitirem

10

Consenso

Um dos problemas mais fundamentais de SDs

Informalmente: como fazer um grupo de processos concordar em um valor– Qual é a hora– Fazer ou não fazer commit– Quem é parte do grupo– Quem é o líder do grupo– Podemos seguir para o próximo passo do algoritmo

Já vimos algumas instâncias, agora vejamos o mais geral

11

Um pouco de formalismo

Conjunto de nós– Falhas por fail-stop ou bizantinas – Mais tarde: fail-stop + recuperação

Objetivo: todos os processos pi põem o mesmo valor em uma variável di

– Não queremos amarrar de onde vem vi

– vi pode ser proposto por um nó ou decidido a partir de várias propostas

12

Um pouco de formalismo

Desejamos:1. Concordância: Todos os nós escolhem o mesmo valor para di

2. Validade: O valor escolhido deve ter sido proposto por algum nó3. Terminação: Alguma hora, todos decidem um valor

O que é safety e o que é liveness aqui?

Pode ser descrito de formas ligeiramente diferentes: generais bizantinos, consistência interativa, atomic broadcast, ...

13

Consenso

Consenso com líder(generais bizantinos)

Consistência interativa

14

Uma boa nova

Esses problemas são equivalentes– Resolvemos um, resolvemos todos

Por exemplo:– CI a partir de GB: GB várias vezes, cada processo é líder

uma vez– C de CI: roda CI, depois nós aplicam mesma função a vetor

para decidirPor aí vai...

15

Uma péssima nova

Nenhum desses consensos pode ser garantido em um sistema assíncrono com crash– Não podemos decidir não levar em conta a opinião de um nó; ele

pode estar apenas lento e mandar a mensagem na hora errada

Consenso pode acontecer freqüentemente ou pode acontecer raramente

Não funciona com crash não funciona com falhas bizantinas

16

Mas a vida continua

Se consenso não funciona em um sistema assíncrono e:– Multicast totalmente ordenado?– Replicação consistente?– Commits em grupo?

Na prática, vivemos com isso:– Tentamos até que o sistema se comporte como síncrono– Mascaramos falhas: esperamos até o processo responder– Usamos detectores de falha:

• Crash fail-stop (sempre que funciona, claro)

17

Voltando ao problema

O commit é um problema de consenso– Um dos lados não pode fazer nada se não souber o que o outro fez

18

Primeira solução: 2-phase commit

Você quer marcar um chopp, que protocolo você usa?

Votos são booleanos, vi é proposto pelo coordenador

19

Funcionamento

2PC atende nossos requisitos?– Mesmo em um sistema assíncrono?

Qual seu custo?

E se nós puderem falhar (fail-stop)?– Coordenador ou nó antes de qualquer mensagem– Coordenador após (algumas) propostas– Nós após (algumas) propostas– Coordenador após (algumas) respostas

20

Falha do coordenador durante votos

Se nós guardam votos por algum tempo, é possível mudar de coordenador– Mas e se um coordenador + um nó falharem?

Algo semelhante acontece para falhas durante o commit

21

Na prática

Custo não é muito alto (3N-1) Latência é baixa (3 msgs)

Porém, na prática, é comum um coordenador ser um participante– A falha dele pára o sistema– Como o TCP lida com isso?

Útil para aplicações onde o protocolo pode reiniciar por timeouts a qualquer instante– Perigoso para aplicações onde isso não é permitido

22

Resolvendo o 2PC 3PC

Problema do 2PC: um nó pode fazer commit e falhar com o coordenador– Nesse caso, nunca saberemos o que eles tinham decidido

Solução: adicionamos uma outra fase antes, que informa a decisão antes de qualquer açãoO que isso muda na recuperação de falhas?

.

23

Se o coordenador e um nó falharem após um commit, todos os outros nós receberam prepare-commit– Se algum nó não recebeu prepare-commit, ninguém fez

commit

Podemos relaxar o recebimento de N confirmações antes do prepare-commit– Para tolerar f falhas, precisamos de f+1 confirmações

24

O cúmulo do robusto: Paxos

Para algumas situações, 3PC não é robusto– Coordenador recebe prepare-commit de N-1 nós e falha– Substituto começa a enviar commits– Coordenador volta das cinzas e começa a cancelar commit

Fail-recover é uma aproximação de sistemas assíncronos– Equivale a errar na detecção de falhas, o que acontece no mundo real

Paxos é um algoritmo para consenso em sistemas assíncronos com crash (ou fail-recover)– Paxos roda em sistemas da Google, Yahoo, ...

25

Como pode?

Consenso em sistema assíncrono?– É impossível garantir safety e liveness em um sistema assíncrono– Paxos pára até que haja sincronia

Na prática, sistemas se alternam entre síncrono e assíncrono– Quando não há sincronia, não há liveness– Em compensação, safety nunca é violada

Entender isso levou mais tempo do que parece necessário...

26

Idéia geralAcontece em turnos

Em cada turno, há um proponente e vários aceitadores– Se um falha, outro nó vira proponente– Se há vários, paramos até que só um deles se

mantenha– Proposta tem valor e contador (totalmente

ordenado)

Aceitadores respondem uma proposta rejeitando ou aceitando um valor e dizendo que propostas estão aceitando

– Assim, proponentees sabem de propostas mais atuais que as suas e propostas antigas não são aceitas

Proponentees enviam commit se receberam N/2+1 respostas positivas. Se não, novo turno

27

Comentário

Eleição é um consenso– Caso paxos dependesse de eleição, não resolvia nada

Em lugar disso, não há acordo sobre quem é líder– Qualquer um pode achar que é – Se gente demais achar que é, há um livelock

Como um líder não bagunça trabalho do outro?– Propostas são ordenadas– Todos os nós sabem qual a mais recente que conhecem

Coordenador resolve commit se maioria aceita proposta– Se maioria aceitou, qualquer maioria contém alguém que conhece a

proposta mais atual

28

Mais sobre a ordenação

Quando recebe uma proposta, o aceitador checa:– Se essa é a proposta mais atual, responde aceitando ou

rejeitando e não aceita mais propostas anteriores– Se a proposta é mais antiga, responde dizendo o número

da mais atual (assim um proponente pode continuar o algoritmo em caso de falha)

29

Por que maioria

Quaisquer duas maiorias têm um nó em comum– proponente um avisa N + 1 nós de pr1– proponente dois enviará pr2 a pelo menos um nó que

conhece pr1– proponente tês enviará pr3 a um nó que conhece p1 e p2

ou a um nó que conhece p1 e um nó que conhece p2

Qualquer proponente consegue descobrir última Qualquer proponente consegue marcar sua proposta

como mais recente para qualquer outro

30

Detalhe a mais

Quando um aceitador envia a proposta previamente aceita para um novo proponente, envia também o valor concordado– Um proponente continuando o algoritmo não pode mudar

o valor da proposta

Propositores podem co-existir– Porém eles se atrapalham e precisam se detectar– O sistema se organiza quando ficar síncrono em um

período e permitir isso

31

Na prática

Implementado no Chubby, do GoogleImplementado no Zookeper, da Yahoo

Notadamente difícil de entender e implementarCaro

Quando usar?