Coordenação e consenso
Nazareno Andrade
Universidade Federal de Campina Grande 02/2008
Fundamentos
Coordenando processos
Construíndo sistemas
Sistemas construídos
3
Fundamentos
Coordenando processos
Construíndo sistemas
– Sincronização – Eleição e consenso – ReplicaçãoSistemas construídos
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
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 caminho E que esse algoritmo só é prático para grupos pequenos
Algoritmo de anel
Nós se organizam numa topologia de anel Quando 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ão
Poré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
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
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 p
ipõem o mesmo valor
em uma variável d
i– Não queremos amarrar de onde vem vi
– vi pode ser proposto por um nó ou decidido a partir de várias propostas
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)
Uma boa nova
Esses problemas são equivalentes
– Resolvemos um, resolvemos todosPor 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 decidir
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
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:
17
Voltando ao problema
O commit é um problema de consenso
Primeira solução: 2-phase commit
Você quer marcar um chopp, que protocolo você usa?
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
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?
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
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ção
O 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
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)
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
Idéia geral
Acontece 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
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
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
31
