A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Coordenação e consenso Nazareno Andrade Universidade Federal de Campina Grande 02/2008 Sistemas Distribuídos."— Transcrição da apresentação:

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

2 2 Fundamentos Coordenando processos Construíndo sistemas Sistemas construídos

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

4 4 Objetivos Entender algoritmos de eleição Entender algoritmos de consenso famosos e o espaço de soluções

5 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 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 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 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 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 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 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 i põem o mesmo valor em uma variável d i –Não queremos amarrar de onde vem v i –v i pode ser proposto por um nó ou decidido a partir de várias propostas

12 12 Um pouco de formalismo Desejamos: 1.Concordância: Todos os nós escolhem o mesmo valor para d i 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 13 Consenso Consenso com líder (generais bizantinos) Consistência interativa

14 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 decidir Por aí vai...

15 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 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 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 18 Primeira solução: 2-phase commit Você quer marcar um chopp, que protocolo você usa? Votos são booleanos, v i é proposto pelo coordenador

19 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 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 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 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 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 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 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 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 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 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 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 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 31 Na prática Implementado no Chubby, do Google Implementado no Zookeper, da Yahoo Notadamente difícil de entender e implementar Caro Quando usar?


Carregar ppt "Coordenação e consenso Nazareno Andrade Universidade Federal de Campina Grande 02/2008 Sistemas Distribuídos."

Apresentações semelhantes


Anúncios Google