sistemas distribuídos · 2018. 1. 21. · 1) no algoritmo do servidor central para exclusão...
TRANSCRIPT
Sistemas Distribuídos
Coordenação
Vinícius Fernandes Soares Mota
1DECSI/ICEA UFOP
2
DECSI/ICEA UFOP
Até agora
• Vimos algumas formas para processos sincronizarem suas ações
• Estudamos vários problemas que podem surgir com a concorrência de processos
Agora
• Nosso objetivo é verificar como os mecanismos de sincronização centralizada podem ser estendidos a um ambiente distribuído.
• Existe um curso somente sobre algoritmos distribuídos.
• Nosso objetivo é introduzir alguns dos principais aspectos.
DECSI/ICEA UFOP
3
Sincronização de Processos
• Processos Cooperativos:• Afetam ou são afetados por outros processos.
• Podem compartilhar um mesmo espaço de endereços lógicos, ou um mesmo arquivo.• Endereços lógicos: threads, ou processos leves.
• Acesso concorrente a dados pode gerar inconsistência de dados.• Devem ser desenvolvidos mecanismos para garantir a
consistência de dados compartilhados por processos cooperativos.
DECSI/ICEA UFOP
4
Jantar dos filósofos...
• Formulado por Dijkstra, 1965
• Cada filósofo come• Usando 2 garfos simultaneamente
• Usa ou larga 2 garfos
• Modela a disputa por recursos
DECSI/ICEA UFOP
5
Jantar dos filósofos...
• Algoritmo básico• Pense até que o garfo esquerdo esteja disponível;
Quando estiver, pegá-lo;
• Pense até que o garfo direito esteja disponível; Quando estiver, pegá-lo;
• Quando possuir ambos os garfos, comer por um período fixo de tempo;
• Então, coloque o garfo direito para baixo;
• Então, coloque o garfo esquerdo para baixo;
• Repetir desde o início.
DECSI/ICEA UFOP
6
O caso produtor/consumidor
• O caso produtor/consumidor:• Suponha processos com memória compartilhada
• Memória consiste em um buffer de tamanho variável que abriga itens em estoque. Variável counter indica o número de itens em estoque (itens no buffer.
• Toda vez que um produto é adicionado incrementa-se o counter.
• Toda vez que um produto é retirado decrementa-se o counter.
DECSI/ICEA UFOP
7
O caso produtor/consumidor// inicializacao
fim = 0;
ini = 0;
n = 0;
// codigo do produtor
for (i=0; i<1000; i++) {
while (n == capacidade);
buf[fim] = produzir(i);
fim = (fim + 1) % capacidade;
n++;
}
DECSI/ICEA UFOP
8
// codigo do consumidor
for (i=0; i<1000; i++) {
while (n == 0) ;
consumir(buf[ini]);
ini = (ini + 1) % capacidade;
n--;
}
O caso produtor/consumidor
• Algoritmos corretos isoladamente.
• Podem causar inconsistência se rodados em paralelo.
• Problema: Sessão Crítica!!!• Região de código onde um processo está acessando
dados compartilhados.
• Problemas de inconsistência ocorrem em sessões críticas e devem ser evitados.
DECSI/ICEA UFOP
9
O problema da sessão crítica
• Soluções para o problema da sessão crítica devem satisfazer os requisitos:• Exclusão mútua: Se um processo está executando uma sessão crítica
(acessando dados compartilhados) os demais processos devem esperar.
• Progressão:Se não há processos executando em sessão crítica, somente processos que não estão executando no final da sessão podem competir pela sessão crítica.
• Espera limitada:existe um limite no número de vezes que outros processos são permitidos a entrar na sessão crítica após m processo requisitar a sessão crítica.
DECSI/ICEA UFOP
10
Sessão Crítica
• Algoritmo básico
DECSI/ICEA UFOP
11
enter() // entra na seção crítica – bloqueia, se necessário
resourceAccesses() // acessa recursos compartilhados na seção crítica
exit() // sai da seção crítica – outros processos podem entrar agora
Sistemas centralizados:Semáforos• Um semáforo é um tipo abstrato de dados que
possui um valor inteiro, uma lista de processos em espera e duas operações• P (do holandês Proberen, testar)
• V (do holandês Verhogen, incrementar)
• A implementação do semáforo deve ser atômica
• Garantido por linguagens que oferecem o recurso
DECSI/ICEA UFOP
12
Sistemas centralizados:Semáforos• Para garantir exclusão mútua a uma determinada
região (região crítica), cada processo deve chamar a operação P antes de acessar tal região e chamar a operação V após sair dessa região
• Operação P sobre um semáforo S• Testa se o processo que executou P(S) pode ou não
entrar na região crítica
• Operação V sobre um semáforo S• Sinaliza ao semáforo que o processo não está mais na
região crítica e retira outro processo da fila de espera
DECSI/ICEA UFOP
13
Sistemas centralizados:Semáforos• // S.valor começa com 1
• P(S)
• S.valor -= 1;
• Se (S.valor < 0) • // bloqueia o processo e insere em S.fila
• V(S)
• S.valor += 1;
• Se (S.valor <= 0)
// retira algum processo de S.fila e o coloca em execução
DECSI/ICEA UFOP
14
O caso produtor/consumidor com semáforos
DECSI/ICEA UFOP
15
// inicializacaofim = 0; ini = 0; n = 0; semaforo S; S.valor = 1;
// codigo do produtor for (i=0; i<1000; i++) {
while (n == capacidade) ; buf[fim] = produzir(i); fim =
(fim + 1) % capacidade; P(S); n++; V(S);
}
// codigo do consumidor for (i=0; i<1000; i++) {
while (n == 0) ; consumir(buf[ini]); ini = (ini + 1) % capacidade; P(S); n--; V(S);
}
O caso produtor/consumidor com semáforos
• Código do produtor:
...
produzir um item ...
wait(empty);
wait(mutex);
...
Adicionar um item no vetor
...
signal(mutex);
signal(full);
DECSI/ICEA UFOP
16
O caso produtor/consumidor com semáforos
• Código do consumidor:
wait(full);
wait(mutex);
...
remove nextc do buffer;
...
signal(mutex);
signal(empty);
...
consome o próximo item
...
DECSI/ICEA UFOP
17
Sincronização em Sistemas Distribuídos
• Conceitos importantes no projeto de qualquer aplicação distribuída:• Comunicação
• Sincronização
• Sincronização em aplicações distribuídas:• Como garantir exclusão mútua no acesso a seções críticas ?
• Como garantir atomicidade na execução de uma transação distribuída ?
• Como alocar recursos evitando a ocorrência de deadlocks ?
DECSI/ICEA UFOP
18
Sincronização em Sistemas Distribuídos• Sincronização em sistemas centralizados: utiliza
memória compartilhada• Exemplos: semáforos, monitores etc
• Sincronização em sistemas distribuídos: utiliza troca de mensagens• Implementada via algoritmos distribuídos
• Mesmo determinar se um evento A ocorreu antes ou depois de um evento B é mais complexo do que em um sistema centralizado
DECSI/ICEA UFOP
19
Exclusão Mútua Distribuída
• Sistemas Centralizados: memória compartilhada (semáforos, monitores etc)
• Sistemas Distribuídos: via troca de mensagens
• Requisitos:• Segurança: No máximo um processo pode estar
executando na seção crítica (SC)
• Subsistência: Um processo que requisita acesso à SC, obtém este acesso em algum momento. Ou seja, não há deadlock ou starvation.
• Ordenação: Se uma requisição para entrar na SC aconteceu antes de outra, a entrada de SC é garantida na ordem
DECSI/ICEA UFOP
20
Primeira Solução: Algoritmo Centralizado• Existe um processo coordenado (PC)
• Gerencia o acesso à SC
• Processos comuns• Antes de entrar na SC: enviam request ao PC
• Quando recebem reply: entram na SC
• Quando saem da SC: enviam release ao PC
• Processo Coordenador:• Enfileira request quando a SC ocupada
• Desenfileira request ao receber um release
DECSI/ICEA UFOP
21
Primeira Solução: Algoritmo Centralizado
DECSI/ICEA UFOP
22
Server
1. Requesttoken
Queue ofrequests
2. Releasetoken
3. Granttoken
4
2
p4
p3p
2
p1
Primeira Solução: Algoritmo Centralizado (cont.)• Número de mensagens trocadas para entrar na SC:
duas (um request e um reply)
• Saída da SC: uma mensagem (release).
• Problema: processo que centraliza todas as informações e decisões
• Solução: distribuir a fila de pedidos• Todos os nós recebem todos os pedidos
• Pedidos são ordenados pelos nós da mesma maneira
DECSI/ICEA UFOP
23
Algoritmos de Exclusão Mútua Distribuída• Principais Algoritmos:
• Token Ring (*)
• Ricart e Agrawala (*)
• Osvaldo e Roucariol
• Maekawa
(*) Algoritmos que serão estudados a seguir
DECSI/ICEA UFOP
24
Algoritmo Token Ring
• Supõe que os processos são organizados como um anel lógico, por onde circula uma token• Não exige que a topologia da rede seja em anel (anel
lógico e não físico)
• Cada processo deve armazenar a configuração completa do anel
• Correção: ao processo de posse da token é garantido o acesso à SC
DECSI/ICEA UFOP
25
Algoritmo Token Ring
• Idéia básica:• Se um processo não deseja entrar na SC:
• Ao receber a token, repassa a mesma para seu vizinho
• Se um processo deseja entrar na SC: • Aguarda a passagem da token e a retém
• Número de mensagens trocadas: entre 1 e n-1
DECSI/ICEA UFOP
26
Algoritmo Token Ring
DECSI/ICEA UFOP
27
pn
p
2
p3
p
4
Token
p1
Algoritmo Token Ring
• Vantagens: simplicidade
• Desvantagem: tratamento de erros• Perda da mensagem que contém a token
• Deve-se gerar a token novamente
• Quando gerar ? Quem deve gerar ?
• Travamento de processos• Deve-se reconfigurar o anel
DECSI/ICEA UFOP
28
Algoritmo de Ricart e Agrawala
• Algoritmo executado por cada processo Pi, que compartilha uma SC ( i <= n):• Variáveis:
estado: estado da seção crítica
OSN: relógio lógico do processo
HSN: maior valor do timestamp de qualquer mensagem enviada ou recebida
• Inicialização:
estado:= livre;
HSN:= 0;
DECSI/ICEA UFOP
29
1. Broadcast de mensagem request comtimestamp
2. 2. Após receber um request, envia ack SE
-Não quer entrar na SC, ou
-Está tentando entrar na SC, mas seu timestampé maior do que o enviado
(Se está na SC, coloque o request no buffer)
3. Entrar na SC, quando receber ack de todos
4. Após sair da SC, envia ack para cada requestpendent e antes de fazer nova requisição
Algoritmo de Ricart e Agrawala
DECSI/ICEA UFOP
30
Algoritmo de Ricart e AgrawalaOn initialization
state := RELEASED; To enter the section
state := WANTED;Multicast request to all processes; request processing deferred hereT := 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
To exit the critical sectionstate := RELEASED;reply to any queued requests;
DECSI/ICEA UFOP
31
Algoritmo de Ricart e Agrawala
• Número de mensagens trocadas para entrar na SC:
• 2 (n -1)• n-1: requests
• n-1: replys
• Vantagem:• Distribuído (sem um ponto central de falha)
• Desvantagem:
Em qual situação este algoritmo pode ser ineficiente?
DECSI/ICEA UFOP
32
Algoritmo de Ricart e Agrawala
• Número de mensagens trocadas para entrar na SC:
• 2 (n -1)• n-1: requests• n-1: replys
• Vantagem:• Distribuído (sem um ponto central de falha)
• Desvantagem:
Em qual situação este algoritmo pode ser ineficiente?
Caso de Mútliplas requisições por um SC
DECSI/ICEA UFOP
33
Jantar dos filósofos...
• Uma solução distribuída (Kandy, 1984)• Para cada par de filósofos que disputam um recurso, crie um garfo e dê-
o ao filósofo com a ID mais baixa (n para o agente Pn). • Cada garfo pode estar sujo ou limpo. Inicialmente, todos os garfos estão sujos.
• Quando um filósofo quer usar um conjunto de recursos (isto é, comer), esse filósofo deve obter os garfos de seus vizinhos. Para cada garfo o filósofo não tem, ele envia uma mensagem de pedido.
• Quando um filósofo com um garfo recebe uma mensagem de pedido, ele mantem o garfo se ele está limpo, mas desiste quando está sujo. Se o filósofo envia o garfo, ele limpa o garfo antes de fazê-lo.
• Depois que um filósofo acaba de comer, todos os garfos ficam sujos. Se outro filósofo havia pedido anteriormente um dos garfos, o filósofo que acabou de comer limpa o garfo e o envia.
DECSI/ICEA UFOP
34
Reforçando
1) No algoritmo do servidor central para exclusão mútua, descreva uma situação na qual duas requisições não são processadas na ordem acontece-antes
2) Qual o impacto na largura de banda de algoritmos de exclusão mútua
3) O algoritmo de Ricart e Agrawala tem o problema de que se um processo cai e não responde a uma solicitação de outro processo para acessar recursos, a falta de resposta será interpretada como negação de permissão. Solução: todas as solicitações serem respondidas imediatamente para facilitar a detecção de processos quebrados. Existem circunstâncias em que mesmo este método é insuficiente? Discutir.
DECSI/ICEA UFOP
35
Reforçando
1) No algoritmo do servidor central para exclusão mútua, descreva uma situação na qual duas requisições não são processadas na ordem acontece-antes
• O Processo A envia uma solicitação rA para entrar na Seção crítica e envia uma mensagem m para B.
• Ao receber m, B envia um pedido rB para entrar na SC.
• Para satisfazer a regra aconteceu-antes• rA deve ser concedido antes de rB.• No entanto, devido a atrasos de propagação de mensagem, rB
chega ao servidor antes de rA, • Eles serão atendidos na ordem oposta.
DECSI/ICEA UFOP
36
Reforçando
2) Qual o impacto na largura de banda de algoritmos de exclusão mútua
A largura de banda será dividida pelo tempo que cada processo “segurar” a exclusão mútua
DECSI/ICEA UFOP
37
Reforçando
3) O algoritmo de Ricart e Agrawala tem o problema de que se um processo cai e não responde a uma solicitação de outro processo para acessar recursos, a falta de resposta será interpretada como negação de permissão.
Suponha que um processo nega permissão e, em seguida, falha. O processo solicitante pensa que ele está vivo, mas a permissão nunca virá.
Uma saída é o solicitante não bloquear realmente, mas sim ir dormir por um período de tempo fixo, após o qual ele examina todos os processos que negaram permissão para ver se eles ainda estão em execução.
DECSI/ICEA UFOP
38
Algoritmos de Eleição
• Grupo de processos deve eleger um coordenador.
• Aplicações:• Gerenciamento de réplicas,
• Algoritmos centralizados de coordenação, sincronização, etc...
• A escolha do coordenador deve ser única, mesmo que vários processos de eleição tenham começado simultaneamente.
DECSI/ICEA UFOP
42
Requisitos Algoritmos de Eleição
• Segurança
• Um processo conhece o processo eleito
• Subsistência
• Todos os processos participam da eleição
DECSI/ICEA UFOP
43
Algoritmo de eleição baseado em anel• Processos organizados em topologia anel
• Todos processos iniciam como não participantes
• Marca a si mesmo como participante e envia uma mensagem com seu id no sentido horário
• Ao receber• Se o id recebido é maior, encaminha para o vizinho
• Se o id é menor• Se é não participante, substitui pelo seu id
• Se é participante, não encaminha a mensagem
DECSI/ICEA UFOP
44
Algoritmo de eleição baseado em anel
DECSI/ICEA UFOP
45
24
15
9
4
3
28
17
24
1
Nota: Eleição iniciada pelo processo 17.
O maior identificador encontrado até então é o 24.
Processos com estado participante estão escurecidos
Algoritmo Tirano (Valentão)The bully algorithm• Membros do grupo devem conhecer a identidade e o
endereço dos outros membros.
• Mensagens:• Eleição: enviada para anunciar o início de uma nova eleição
• Resposta: enviada em resposta a uma mensagem de eleição.
• Coordenador: enviada para anunciar o coordenador.
• Um processo inicia uma eleição quando notar uma falha no coordenador (não recebeu uma resposta a uma requisição depois de um certo número de tentativas ou após um certo timeout, por exemplo).
DECSI/ICEA UFOP
46
Algoritmo TiranoThe bully algorithm• Processo inicia eleição
enviando mensagem de eleição para os processos de maior prioridade.
DECSI/ICEA UFOP
47
eleição
p1
p2
p3
p4
C
eleição
resposta
resposta
eleição
Estágio 1
Algoritmo TiranoThe bully algorithm• Processo inicia eleição
enviando mensagem de eleição para os processos de maior prioridade.
• Processos respondem a mensagem e iniciam nova eleição
DECSI/ICEA UFOP
48
p1 p2
p3
p4
C
eleição
eleiçãoEstágio 2
p1
p2
p3
p4
C
eleição
resposta
resposta
eleição
Estágio 1
eleição
resposta
Algoritmo TiranoThe bully algorithm• Processo inicia eleição
enviando mensagem de eleição para os processos de maior prioridade.
• Processos respondem a mensagem e iniciam nova eleição
• Processo coordenador envia mensagem de coordenador.
DECSI/ICEA UFOP
49
p1 p2
p3
p4
p1
p2
p3
p4
C
eleição
eleiçãoEstágio 2
p1
p2
p3
p4
C
eleição
resposta
resposta
eleição
Estágio 1
timeout
Estágio 3
eleição
resposta
Algoritmo TiranoThe bully algorithm• Processo inicia eleição
enviando mensagem de eleição para os processos de maior prioridade.
• Processos respondem a mensagem e iniciam nova eleição
• Processo coordenador envia mensagem de coordenador.
• Se nenhuma mensagem for recebida, processo se declara coordenador e envia mensagem de coordenador para os processos de menor prioridade.
DECSI/ICEA UFOP
50
p1 p2
p3
p4
p1
p2
p3
p4
C
coordenador
Estágio 4
C
eleição
eleiçãoEstágio 2
p1
p2
p3
p4
C
eleição
resposta
resposta
eleição
Estágio 1
timeout
Estágio 3
Eventualmente.....
p1
p2
p3
p4
eleição
resposta
Reforçando
1) Compare o algoritmo de eleição do anel com oalgoritmo valentão
2) Esboce um pseudo-código para ambos os algoritmos.
DECSI/ICEA UFOP
51
52
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
53
Um pouco de formalismo
Consenso:
Para chegar a um consenso, todo processo p i começa no estado indeciso e propõe um único valor v i , extraído de um conjunto D (i = 1, 2,..., N).
Os processos se comunicam, trocando valores. Cada processo configura o valor de uma variável de decisão d i .
Ao fazer isso, ele entra no estado decidido, no qual não pode mais mudar d i (i = 1, 2,..., N).
54
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
55
Um pouco de formalismo
1
P 2
P 3 (crashes)
P 1
Consensus algori thm
v 1 =proceed
v 3=abort
v 2=proceed
d 1 :=proceed d2 :=proceed
56
Um pouco de formalismo
Requisitos:
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
Pode ser descrito de formas ligeiramente diferentes: generais bizantinos, consistência interativa, atomic broadcast, ...
57
Consenso
Consenso com líder
(generais bizantinos)
Consistência interativa
58
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...
59
Uma péssima nova
Nenhum desses consensos pode ser garantido em um sistema assíncrono com falha
– 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 frequentemente ou pode acontecer raramente
Não funciona com crash não funciona com falhas bizantinas
60
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)
61
Comentário
Eleição é um consenso
Casos de falha, 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
Questões
DECSI/ICEA UFOP
Vinícius Fernandes Soares Mota
Sincronização
70