Algoritmos distribuídos
fundamentais
Andrey Brito, Lívia Sampaio Campos Sistemas Distribuídos – 2012.3
Plano de aula
• Coordenação e acordo
– Exclusão mútua – Eleição de líder – Problemas de acordo • Consenso • Acordo bizantino • Confirmação atômica • Difusão atômicaMotivação
• Algoritmo → programa → processo
• Algoritmos distribuídos ...
– Sequência de passos a serem executados pelos processos que compõem um programa
distribuído, incluindo a comunicação entre estes processos
– Voltados para a lógica do programa distribuído (nível da aplicação)
– Voltados para o controle do programa distribuído (nível do sistema)
Algoritmos distribuídos fundamentais
• Consenso
• Detecção de falhas
• Detecção de deadlocks (impasses)
• Gravação de estados distribuídos
• Confirmação atômica
• Comunicação em grupo
• Eleição de líder
• Exclusão mútua
• ....
Alguns conceitos e considerações
iniciais
• Propriedades de algoritmos distribuídos
– Segurança: está relacionada com as ações corretas que os participantes do algoritmo devem
desempenhar
– Vivacidade: está relacionada com a ocorrência das ações do algoritmo em um determinado
Alguns conceitos e considerações
iniciais
• Centralizado x Distribuído
– Classificação quanto a carga de trabalho de cada participante do algoritmo
– Centralizado: um ou poucos processos são
responsável por uma carga maior de trabalho
• Ex. cliente-servidor
– Distribuídos ou parcialmente distribuídos
• Ex. gravação de estado global distribuído, consenso, p2p, computação móvel
Alguns conceitos e considerações
iniciais
• Algoritmos simétricos e assimétricos
– Simetria está associada aos papéis assumidos pelos participantes do algoritmo
– Simétrico: todos os processos executam as mesmas funções
• Algoritmos “distribuídos” são, normalmente, simétricos
– Assimétrico: processos diferentes executam funções diferentes
Alguns conceitos e considerações
iniciais
• Anonimato
– Processos que executam o algoritmo são considerados indistinguíveis
– Nem sempre é possível atribuir identificadores aos processos
– Maior complexidade de implementação – Ex. redes de sensores
Alguns conceitos e considerações
iniciais
• Uniforme
– Não existe limitação quanto ao número de processos participantes do algoritmo
– Transparência de escalabilidade – Ex. eleição de líder
Alguns conceitos e considerações
iniciais
• Determinístico x Não-determinístico
– Determinismo está relacionado com a
comunicação entre os processos e a ordenação parcial dos eventos na execução distribuída
– Determinismo é importante em aplicações de debugging, por exemplo
Alguns conceitos e considerações
iniciais
• Síncrono x Assíncrono
– Em termos de:
• Limites nos atrasos na comunicação
• Limites nos desvios dos relógios locais em relação ao tempo real
Alguns conceitos e considerações
iniciais
• Modelo de falhas
– Omissão, valor, temporização e maliciosa
– Podem ocorrer sobre os processos e comunicação – Falhas de temporização podem ocorrer somente
Alguns conceitos e considerações
iniciais
• Detecção de falhas
– Todo sistema que precisa lidar com falhas tem que detectá-las mesmo que de forma imperfeita
– Confiável x não-confiáveis – Como implementar
• Modelo push
Coordenação e acordo
• Objetivo
– Coordena ações de um conjunto de processos ou concordar sobre um ou mais valores
• Exemplos
– Sistemas como Google Chubby ® e Microsoft Autopilot® usam algoritmos de consenso para gerência de réplicas
– Sistema Apache Zookeeper® oferece vários serviços para coordenação distribuída
• Algotitmos de exclusão mútua, eleição de líder e
consenso
Suposições sobre os algoritmos a
serem apresentados
• Canais de comunicação confiáveis
– Eventualmente qualquer link ou roteador falho será reparado
– Processos podem não conseguir se comunicar ao mesmo tempo
• Processos podem sofrer falhas por parada ou
maliciosas
• Troca de mensagens
Exclusão mútua
• Objetivo principal é coordenação
• Importante considerando a necessidade de
compartilhamento de recursos em sistemas
distribuídos
– Problema da “seção crítica”
• Exemplo: acesso a arquivos compartilhados
Definição do algoritmo
• Considere N processos pi = p1, p2, ..., pn
• Acesso a recursos compartilhados através de UMA seção crítica (CS)
• Abordagens baseadas em:
– Token ou permissão
• Sistema assíncrono, comunicação confiável, processos confiáveis
• Primitivas
– enter()
– resourceAccesses() – exit()
Propriedades da exclusão mútua
• ME1 (segurança)
– Apenas um processo pode executar na seção crítica por vez
• ME2 (vivacidade)
– Requisições para entrar e sair da seção crítica eventualmente serão bem-sucedidas
• ME3 (ordenação; justiça)
– Se uma requisição para entrar na seção crítica
“aconteceu antes” de outra, deve-se obedecer essa relação de causalidade
Algoritmo básico: servidor central
• Baseado em permissão
• Permissões são concedidas na ordem em que as
requisições foram recebidas • Não satisfaz ME3
• Poucas mensagens trocadas por pedido de permissão • Servidor torna-se um
gargalo de desempenho • Servidor é ponto único de
falhas Server 1. Request token Queue of requests 2. Release token 3. Grant token 4 2 p 4 p 3 p 2 p 1
Algoritmo baseado em anel + token
• Anel lógico
– Cada processo conhece seu vizinho
– O token é passado para o vizinho, caso o processo não deseja usar a seção crítica
• Elimina gargalo de
desempenho do servidor central
• Também não satisfaz ME3 • Número de mensagens pode
ser um gargalo
• Maior probabilidade de falhas • Token pode ser perdido
p n p 2 p 3 p 4 Token p 1
Algoritmo de Ricart e Agrawala[RA81]
• Baseado em permissão
– Difusão de mensagens
• Idéia básica
– difunde requisição <T, pi> que será considerada bem sucedida quando todos os processos responderem
• Uso de relógios lógicos
• Processos guardam seu estado:
– RELEASED, WANTED, HELD
Algoritmo de Ricart e Agrawala[RA81]
On initialization
state := RELEASED; To enter the section
state := WANTED;
Multicast request to all processes; request processing deferred here
T := request’s timestamp;
Wait until (number of replies received = (N – 1)); state := HELD;
On receipt of a request <Ti, pi> at pj (i ≠ j)
if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi)))
then
queue request from pi without replying;
else
reply immediately to pi; end if
Algoritmo de Ricart e Agrawala[RA81]
– Desempenho: 2(N-1) mensagens – Maior probabilidade de falhas
p 3 34 Reply 34 41 41 41 34 p 1 p 2 Reply Reply
Algumas considerações sobre falhas no
contexto de exclusão mútua
• O que ocorre quando mensagens são
perdidas?
• O que ocorre quando processos falham por
parada?
Eleição de líder
• Objetivo é escolher um processo único (líder)
para desempenhar um papel particular, tal
que todos os demais processos do sistema
conhecem o líder
• Importante em vários sistemas práticos:
Definição do algoritmo
• Considere N processos p1, p2, ..., pn
• Um ou mais processos podem iniciar uma
eleição de líder, mas, o líder deve ser único
• Processos podem estar engajados
(participantes) ou não (não-participantes) em
alguma rodada do algoritmo
• O líder é, normalmente, o processo de maior
identificador
Propriedades da eleição de líder
• E1 (segurança):
– Um processo participante pi tem como lider_i = Ø ou lider_i = P, onde P é escolhido como o processo correto com maior identificador ao final do
algoritmo
• E2 (vivacidade):
– Todos os processos pi podem participar e, eventualmente, definir lider_i ≠ Ø ou falhar
Algoritmo baseado em anel (Chang e
Roberts[RC79])
• Anel lógico e cada processo conhece seu vizinho; não existe token
• Não suporta falhas e sistema assíncrono • Para iniciar uma eleição
– pi envia ao vizinho uma mensagem de eleição contendo seu identificador; processo torna-se participante
– Quando pj recebe mensagem de eleição, se identificador seu identificador for menor do que da mensagem, difunde para vizinho...
– ... se identificador de pj for maior e pj não é participante, atualiza identificador da mensagem e difunde para vizinho
Algoritmo baseado em anel
• Para finalizar uma eleição
– Quando pi participante recebe mensagem de eleição com seu
identificador, torna-se o novo líder
– Líder envia mensagem ao vizinho informando sua identidade
– Ao receber mensagem do líder, todos tornam-se novamente
não-participantes e difundem a mensagem para vizinho
• Garante E1 e E2 24 15 9 4 3 28 17 24 1
O algoritmo “guloso” Garcia e
Molina[GM82]
• Suporta falhas por parada dos processos
– Mas, comunicação deve ser confiável – Mas, sistema síncrono
• Todo processo conhece os processos com
maiores identificadores e pode comunicar-se
com eles
• Tipos de mensagens
O algoritmo “guloso”
• Eleição é iniciada quando percebe-se a falha do líder atual
– Necessidade de detector de falhas confiável
• Processo inicia eleição
– Envia mensagem de eleição para os processos com ID maiores – Processo com maior ID pode tornar-se o líder imediatamente
• Difunde mensagem de eleito para os demais processos
– Processos com IDs menores ficam aguardando mensagem de resposta
• Se não houver resposta, o processo torna-se o novo líder
– Processos que recebem mensagem de eleição, respondem e iniciam nova eleição
• Quando processo recebe mensagem de eleito, atualiza a identidade do novo líder
O algoritmo guloso
• Garante E1
*e E2
p1 p 2 p3 p4 p 1 p2 p3 p4 C coordinator Stage 4 C election election Stage 2 p 1 p2 p3 p4 C election answer answer election Stage 1 timeout Stage 3 Eventually... election answerAcordo e problemas relacionados
• Problemas de acordo
– Um grupo de processos que precisam concordar entre si para alcançar consistência global do sistema
• Exemplos clássicos
– Consenso, acordo bizantino, consistência interativa (blocos básicos)
– Difusão atômica
– Confirmação atômica
Blocos básicos de acordo (problema)
• Acordo bizantino
– Existe um processo particular (fonte) dentro de um grupo, com um valor inicial, que tenta obter acordo com os demais processos sobre este valor
• Consenso
– O acordo será obtido a partir de um conjunto de
valores, cada um proposto por um processo do grupo
• Consistência interativa
– Semelhante ao consenso, mas o acordo resulta em um conjunto de valores, um para cada processo do grupo
Blocos básicos de acordo
(propriedades)
• Acordo bizantino
– Terminação
• Eventualmente, todo processo correto decide sobre o mesmo valor
– Validade
• Se o processo fonte é correto e propõe o valor “v”,
então, todos os processos corretos decidem este valor
– Acordo
• Quaisquer dois processos corretos nunca decidem valores diferentes
Blocos básicos de acordo
(propriedades)
• Consenso
– Terminação (ver acordo bizantino) – Acordo (ver acordo bizantino)
– Validade
• Se todos os processos corretos propõem o mesmo valor “v”, este será o valor decidido por todos os processos corretos
Blocos básicos de acordo
(propriedades)
• Consistência interativa
– Terminação
• Eventualmente, todo processo correto decide sobre o
mesmo conjunto de valores A = [v1, v2, ..., vn]
– Acordo
• Quaisquer dois processos corretos nunca decidem conjuntos
de valores A diferentes
– Validade
• Se um processo i é correto e seu valor inicial é vi, então, todos os processos corretos decidem sobre vi como o
i-ésimo valor do array A; para processos falhos pode-se
Equivalência entre os problemas de
acordo
• Consenso, acordo bizantino e consistência
interativa são equivalentes
– A solução para um problema pode ser usada para resolver outro problema
• Equivalência entre os problemas
– Um problema pode ser reduzido para cada um dos outros dois problemas
• A é redutível a B, então, a solução de B serve para A
• Vamos considerar, assim,
soluções para o
consenso
Lembrando do problema do consenso
1 P2 P3 (crashes) P1 Consensus algorithm v1=proceed v3=abort v2=proceed d1:=proceed d2:=proceedComo resolver o consenso (visão geral)
• Sem falhas
– Conjunto de processos difundem sua proposta de consenso via difusão confiável
– Cada processo espera receber a proposta de todos os demais do conjunto
– Aplica uma função determinística sobre os valores recebidos (majoritário, mínimo, máximo)
– Pode ser resolvido em um número finito de rodadas, tanto em sistemas síncronos quanto assíncronos
Como resolver o consenso (visão geral)
• Com falhas
(por parada)
– Introduz a necessidade de detectar falhas
– Lembrar dos resultados de impossibilidade para sistemas assíncronos
• Com falhas (maliciosas)
– Como falhar (intencional x acidental)? Processos comunicam valores randômicos; omissão de
valores
– Muitas vezes é requerido assinatura de mensagens
Consenso em sistemas síncronos com
falhas por parada
• Suposições
– Seja um grupo de N processos, podem ocorrer f falhas, onde f < N
– O algoritmo procede em f+1 rodadas
– Processos corretos difundem (não confiável) seu valor proposto em cada rodada
Algoritmo de consenso de Attiya e
Welch [AW98]
– Desempenho O((f+1). N2)
O problema dos generais bizantinos
(motivação)
• Guerra do império
bizantino na idade média
– 4 campos do exército
inimigo ao redor do forte Bizantino; cada campo tem seu general
– Ataque deve ser simultâneo
– Acordo sobre o momento do ataque
– Mensageiros podem atrasar ou ser abatidos pelo inimigo
Consenso na presença de falhas
bizantinas
• Suposições
– Processos podem apresentar arbitrárias (bizantinas): envio de mensagens com qualquer valor em qualquer tempo; omissão de mensagens
– Canais de comunicação privados (mensagens não podem ser injetadas na rede por maliciosos)
– Uso de timeouts para detectar ausência de mensagens
– Seja um grupo de N processos, podem ocorrer f falhas, onde N >= 3f+1
– O algoritmo procede em f+1 rodadas
Consenso na presença de falhas
bizantinas (impossibilidade)
• Impossível resolver consenso para N = 3, f = 1
p 1 (Commander) p 2 p 3 1:v 1:v 2:1:v 3:1:u p 1 (Commander) p 2 p 3 1:x 1:w 2:1:w 3:1:x Faulty processes are shown coloured
Consenso na presença de falhas
bizantinas (impossibilidade)
• Generalizando para F >= N/3
– Por redução, considere A(n=3, f=1) e B(n <= 3f, f)
• A é redutível B, se B tem solução, então, A também terá
– Divide o grupo de processos em 3 partes, onde cada parte tem até N/3 processos
– Considere que 1 parte pode falhar (processos bizantinos)
– As outras 2 partes podem obter consenso, então, se B tem solução A também terá: CONTRADIÇÃO
Consenso na presença de falhas
bizantinas (solução)
• Algoritmo de [Pease80]
– N >= 3F+1
• Seja uma execução do algoritmo para N=4, f=1
– 2 rodadas de mensagens
– Cada general recebe 1 mensagem do comandante e N-2 mensagens dos demais
– Se comandante ou general falharem é possível obter acordo sobre os valores recebidos, aplicando uma função de valor majoritário
– No caso de falhas por omissão, após um timeout, considera-se que o processo falho enviou valor Ø
Consenso na presença de falhas
bizantinas (solução)
• Execução do algoritmo[Pease80] para N=4, f=1
p 1 (Commander) p 2 p 3 1:v 1:v 2:1:v 3:1:u p 4 1:v 4:1:v 2:1:v 3:1:w 4:1:v p 1 (Commander) p 2 p 3 1:w 1:u 2:1:u 3:1:w p 4 1:v 4:1:v 2:1:u 3:1:w 4:1:v
Consenso em sistemas assíncronos
• Resultado de impossibilidade [FLP85]
– Não existe solução determinística para o consenso em sistemas assíncronos mesmo que ocorra uma única falha por parada
– Exemplo com 2 processos
• Consequentemente, todo problema que pode
ser reduzido a acordo também não tem
Uma forma de lidar com [FLP85]
• Consenso com detectores não-confiáveis
[CT96]
– Paradigma do coordenador rotativo
– Utiliza detectores de falha ◊S (N 2F+1) – Rodadas assíncronas
– Cada rodada tem um coordenador conhecido a priori
– O consenso termina quando existir um
coordenador que não seja suspeitado por um número suficiente de participantes
Detectores de falhas não-confiáveis ◊S
• Propriedades
• Implementação
– Timeouts crescem à medida que falsas suspeições são descobertas
Consenso com detectores
não-confiáveis [CT96]
• Rodada sem falhas
estimativas proposta ack ou nack decisão
difusão confiável
p3 p2
p1
Consenso com detectores
não-confiáveis [CT96]
• Rodada com falhas
estimativas proposta
p3 p2
p1
Fase 1 Fase 2 Fase 3 Fase 4
ack ou nack
X X
Outros problemas de acordo: difusão
atômica
• Problema:
– Difusão confiável de mensagens com ordenação total
– Muito útil em sistemas tolerantes a falhas
• Propriedades:
– Validade – Acordo
– Integridade
Difusão atômica é equivalente ao
consenso
• Assim:
– [FLP85] também se aplica a difusão atômica – Difusão atômica pode ser resolvida com
detectores de falhas não-confiáveis (ou outros métodos para lidar com [FLP85])
Reduzindo difusão atômica ao
consenso
Outros problemas de acordo:
confirmação atômica
• Transações
– Sequência de operações sobre dados que precisam ser tratadas como um todo
– Tipicamente implementada em banco de dados
• Transações são ACID:
– Atomicity: operações indivisíveis
– Consistency: atualizações levam a estados consistentes
– Isolation: transações paralelas não interferem entre si – Durability: resultados são persistentes
Outros problemas de acordo:
confirmação atômica
• Transações distribuídas
– Transações podem acessar dados distribuídos em diferentes nós pela rede
– Mesmas propriedades ACID – Confirmação atômica
• Todos os nós envolvidos na transação devem concordar se a transação será confirmada ou abortada
Outros problemas de acordo:
confirmação atômica
• Soluções
– Algoritmo de confirmação em 2 fases – Algoritmo de confirmação em 3 fases
Confirmação atômica em duas fases
• Two-phase commit
• E se o coordenador falhar?
Bloqueia até que haja recuperação de falhasConfirmação atômica em três fases
• Three-phase commit
Reduzindo confirmação atômica a
consenso
• Requer acordo uniforme
– Todos os processos (corretos ou falhos) decidem o mesmo valor
• Requer maioria de processos corretos
• Algoritmo...
– Primeira fase: coordenador envia mensagem de
preparação e todos os participantes difundem suas
respostas
– Consenso: participantes que coletaram “OK” dos demais propõem “Confirmar”, caso contrário, propõem “Abortar”
Referências
• CT96
– Unreliable Failure Detectors for Reliable Distributed Systems
• FLP85
– Impossibility of Distributed Consensus with One Faulty Process
• Pease80
Referências
• AW98
– Distributed Computing: Fundamentals, Simulations and Advanced Topics
• GM82
– Elections in Distributed Computing Systems
• CR79
– An improved algorithm for decentralized extrema-finding in circular configurations of processors
• RA81
– An optimal algorithm for mutual exclusion in computer networks
Referências
• Charron-Bost01
– Agreement Problems in Fault-Tolerant Distributed Systems
• BJS11
– Leader Election for Replicated Services Using Application Scores
