Coordenação e consenso

Apresentação em tema: "Coordenação e consenso"— Transcrição da apresentação:

1 Coordenação e consenso
Sistemas Distribuídos Coordenação e consenso 4,45 Nazareno Andrade Universidade Federal de Campina Grande 02/2008

2 Coordenando processos Construíndo sistemas Sistemas construídos
Fundamentos Coordenando processos Construíndo sistemas Sistemas construídos 9-25

3 Coordenando processos Construíndo sistemas
Fundamentos Coordenando processos Construíndo sistemas Sincronização Eleição e consenso Replicação Sistemas construídos 9-25

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 caminho
E 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 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 ) é o responsável pelo nó com chave k Sou supernó == sou responsável por (meuID AND )? 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:
Concordância: Todos os nós escolhem o mesmo valor para di Validade: O valor escolhido deve ter sido proposto por algum nó 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 (generais bizantinos)
Consenso Consistência interativa Consenso com líder (generais bizantinos)

14 Uma boa nova Esses problemas são equivalentes Por exemplo:
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 decidir Por 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? Qual seu custo?
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çã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 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 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

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 Google
Implementado no Zookeper, da Yahoo Notadamente difícil de entender e implementar Caro Quando usar?