sistemas distribuídos · 2018. 1. 30. · sistemas distribuídos replicação vinícius fernandes...
TRANSCRIPT
Sistemas Distribuídos
Replicação
Vinícius Fernandes Soares Mota
1
O Papel da replicação
DECSI/ICEA UFOP
2
Melhorando serviços com dados replicados• Balanceamento de carga
• carga de trabalho é compartilhada entre servidores amarrando-se vários IPs a um único nome de DNS. Endereços IP são retornados utilizando uma política tipo round-robin.
DECSI/ICEA UFOP
3
Melhorando serviços com dados replicados• Balanceamento de carga
• carga de trabalho é compartilhada entre servidores amarrando-se vários IPs a um único nome de DNS.
DECSI/ICEA UFOP
4
Melhorando serviços com dados replicados• Tolerância à falha
• se f de f + 1 servidores falham, pelo menos um mantém-se ativo e provendo o serviço
• Aumento da disponibilidade• serviço pode não estar disponível quando servidores
falham ou quando a rede é particionada
DECSI/ICEA UFOP
5
Melhorando serviços com dados replicados• Aumento da disponibilidade
P: probabilidade de falha de um servidor
1 – P: disponibilidade do serviço
Por exemplo, se P = 5%
Serviço está disponível 95% do tempo.
Pn: probabilidade de n servidores falharem
1 – Pn: disponibilidade do serviço
por exemplo, se P = 5%, n = 3
=> serviço está disponível 99.875% do tempo
DECSI/ICEA UFOP
6
Detectando falhas - Exercício
• Três computadores juntos fornecem um serviço replicado. Os fabricantes dizem que cada computador tem um tempo médio entre falhas de cinco dias; normalmente, uma falha demora quatro horas para ser corrigida. Qual é a disponibilidade do serviço replicado?
DECSI/ICEA UFOP
7
Detectando falhas - Exercício
• Três computadores juntos fornecem um serviço replicado. Os fabricantes dizem que cada computador tem um tempo médio entre falhas de cinco dias; normalmente, uma falha demora quatro horas para ser corrigida. Qual é a disponibilidade do serviço replicado?
DECSI/ICEA UFOP
8
Probabilidade Falha individual = 4/(5*24 ) ~ 0.03.
Disponibilidade do serviço:
1 – 0.033 = 0.999973.
Modelo arquitetural básico para o gerenciamento de dados replicados
FE
Requisições
e respostas
C
ReplicaC
ServiçoClientes Front ends
managers
RM
RMFE
RM
Transparência de replicaçãousuário/cliente não precisa saber que existem diversas cópias do recurso
Consistência de replicaçãoos dados são consistentes entre todas as réplicas, ou estão no processo de se
tornarem consistentes
DECSI/ICEA UFOP
9
Gerenciamento de replicação
• 5 Fases que afetam o desempenho de acesso a objetos replicados
• Requisição
• Coordenação
• Execução
• Acordo
• Resposta
DECSI/ICEA UFOP
10
Gerenciamento de replicação
• Requisições- requisições podem ser feitas a um RM
- Via multicast a múltiplos RM
• Coordenação: os RM devem decidir:- se a requisição será aplicada
- a ordem em que as requisições serão aplicadasordem FIFO: se um FE envia uma requisição r e então uma requisição r’, então toda RM deve tratar r e depois r’ordem causal: se a requisição r “happens-before” r’, então toda RM deve tratar r e depois r’ordem total: se uma RM trata r e depois r’, então todas as RM devem tratar r e depois r’
• Execução: Tentativas de executar a requisição
DECSI/ICEA UFOP
11
Gerenciamento de replicação
• Acordo/Consenso: • as RMs tentam alcançar o consenso sobre o efeito da requisição
• exemplo: Two-phase commit através de um coordenador
• se bem sucedido, a requisição se torna permanente
• Resposta: • uma ou mais RM respondem ao FE
• o FE retorna a primeira resposta obtida
DECSI/ICEA UFOP
12
Comunicação de grupos
• Grupos estáticos: membros são pré-definidos
• Grupos dinâmicos: membros podem entrar (join) e sair (leave) do grupo
• Um serviço de gerenciamento de membros em um grupo mantém visões de grupo (views):• listas dos membros atuais do grupo
• não é uma lista mantida por um membro, mas cada membro possui sua view local
DECSI/ICEA UFOP
13
Modo de visualização - Views
• Uma view Vp(g) é o entendimento do processo p de seu grupo (lista de membros)
Exemplo: Vp.0(g) = {p}, Vp.1(g) = {p, q}, Vp.2 (g) = {p, q, r}, Vp.3 (g) = {p,r}
• Uma nova view é disseminada através do grupo sempre que um membro entra ou sai do grupo• membros que detectarem uma falha de um outro
membro, envia um multicast confiável notificando a mudança da view (requer ordem total para multicasts)
• Mensagens enviadas em uma view devem ser enviada a todos os membros do grupo
DECSI/ICEA UFOP
14
Views
• Requisitos para entrega de uma view• Ordem: se p entrega uma vi(g), e então uma vi+1(g),
então nenhum outro processo q envia vi+1(g) antes de vi(g)
Garantia de consistência
• Integridade: se p envia vi(g), então p está na view vi(g)
Garantia de sanidade
• Não trivialidade: se o processo q entra em uma view e se torna alcançável pelo processo p, então, eventualmente, q estará sempre presente nas viewsentregues a p
Previne soluções triviais
DECSI/ICEA UFOP
15
Comunicação síncrona em uma view• Usa serviço de comunicação de grupo + multicast
confiável
• Garantias providas pelo protocolo multicastconfiável:
• Integridade: se p enviou a mensagem m, p não irá enviar mnovamente, e p grupo(m).
• Validade: processos corretos sempre entregam todas as suas mensagens
• Acordo/Consenso: processos corretos entregam o mesmo conjunto de mensagens em uma view
DECSI/ICEA UFOP
16
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Grupos de comunicação
DECSI/ICEA UFOP
17
Considere um grupo com três processos p, q e r .Suponha que p envie uma mensagem m enquanto está no modo de visualização (p, q, r);P falha após o envio
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Grupos de comunicação
DECSI/ICEA UFOP
18
Considere um grupo com três processos p, q e r .Suponha que p envie uma mensagem m enquanto está no modo de visualização (p, q, r);P falha após o envio
p
q
r
p crashes
view (q, r)view (p, q, r)
p
q
r
p crashes
view (q, r)view (p, q, r)
a (Permitido). b (Permitido).
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Grupos de comunicação
p
q
r
p crashes
view (q, r)view (p, q, r)
p
q
r
p crashes
view (q, r)view (p, q, r)
a (Permitido). b (Permitido).
p
q
r
view (p, q, r)
p
q
r
p crashes
view (q, r)view (p, q, r)
c (Proibido). d (Proibido).
p crashes
view (q, r)
DECSI/ICEA UFOP
19
Serviços Tolerantes a Falhas
• como fornecer um serviço correto quando ocorrer falhas?• Supõe-se que cada gerenciador de réplica se comporta
de acordo com os objetos que gerencia
• Exemplo: contas bancárias incluiria a garantia de que os fundos transferidos entre as contas nunca poderia desaparecer
DECSI/ICEA UFOP
20
Serviços Tolerantes a Falhas
• como fornecer um serviço correto quando ocorrer falhas?• Supõe-se que cada gerenciador de réplica se comporta
de acordo com os objetos que gerencia
• Exemplo: contas bancárias incluiria a garantia de que os fundos transferidos entre as contas nunca poderia desaparecer
• Podem surgir anomalias quando houver vários gerenciadores de réplicas
DECSI/ICEA UFOP
21
Serviços Tolerantes a Falhas
• Inicialmente, x = y = 0
• Cliente 1 atualiza objeto x em uma réplica B
• Réplica B falha
DECSI/ICEA UFOP
22
Serviços Tolerantes a Falhas
• Inicialmente, x = y = 0
• Cliente 1 atualiza objeto x em uma réplica B
• Réplica B falha
DECSI/ICEA UFOP
23
Houve atualização de X no servidor B
X não foi atualizado no servidor A
Serviços Tolerantes a Falhas
• Entender o que é um comportamento correto em um sistema replicado
• Como “serializar” as operações?
• Critérios de correção para objetos replicados:• Capacidade de linearização
• Interposição das operações para todos os clientes, para qualquer operação.
• Consistência sequencial• Interposição das operações
DECSI/ICEA UFOP
24
Capacidade de linearização
• Um serviço de compartilhamento de objetos replicado é dito linearizável se
• Obedecem à especificação de uma única cópia do objeto
• É consistente com os tempos reais com que cada operação ocorreu durante a execução
DECSI/ICEA UFOP
25
Capacidade de linearização
• A capacidade de linearização diz respeito à interposição de operações individuais e não se destina a ser transacional.
• Uma execução que pode ser linearizada pode violar as noções de consistência específicas da aplicação, caso não seja aplicado controle de concorrência.
DECSI/ICEA UFOP
26
Capacidade de linearização
• O exemplo anterior não pode ser linearizado
• Não há interposições das operações que leve ao resultado correto
DECSI/ICEA UFOP
27
Capacidade de linearização
• Linearização é difícil (ou quase impossível) de ser alcançada em sistemas reais
• Um critério menos restritivo é o de consistência sequencial
DECSI/ICEA UFOP
28
Consistência sequencial
• Um serviço de compartilhamento de objetos replicado é sequencialmente consistente se, para qualquer execução (real) existe alguma intercalação de operações do cliente (virtual) que:
• Obedecem à especificação de uma única cópia do objeto
• É consistente com ordem individual em que cada cliente executou a operação
DECSI/ICEA UFOP
29
Consistência sequencial
• Não exige ordenação total ou tempo absoluto.
• Para cada cliente, a ordem de execução da sua sequencia de operações deve ser consistente com a ordem do programa (~FIFO)
• Linearização implica em consistência sequencial, mas não vice versa• Como garantir consistência sequencial: garantindo que todas as
réplicas de um objeto sejam consistentes.
DECSI/ICEA UFOP
30
Consistência sequencial
DECSI/ICEA UFOP
31
O critério do tempo real para a capacidade de linearização
não é satisfeito, pois getBalanceA(x) 0 ocorre depois de
setBalanceB(x,1);
A interposição das operações do Cliente 2 serem
executadas antes do cliente 1 satisfaz os dois critérios da
consistência sequencial:
getBalanceA(y) 0, getBalanceA(x) 0
setBalanceB(x, 1), setBalanceA(y, 2).
Modelo de tolerância à falhas baseado em replicação passiva (backup primário)
FEC
FEC
RM
Primary
Backup
Backup
RM
RM
DECSI/ICEA UFOP
32
Replicação passiva (backup primário)• Comunicação: a requisição é encaminhada para o RM primário e
possui um único identificador de requisição
• Coordenação: o RM primário recebe todas as requisições atomicamente, em ordem, checa o id (reenvia resposta se não é novo identificador)
• Execução: RM primário executa e armazena as requisições
• Acordo/Consenso: se é atualização, RM primário envia estado atualizado/resultado do objeto, identificador de requisição e resposta para todos os RM de backups (1-phase commit).
• Resposta: RM primário envia resposta ao front end
DECSI/ICEA UFOP
33
Tolerância à falhas na replicação passiva• Implementa linearização
• Se RM primário falha, um backup se torna o líder por eleição e as RM que sobreviveram concordam sobre o conjunto de operações que foram realizados até o ponto em que o novo líder assume• requisito é alcançado se as RM estão organizadas como
um grupo e a réplica primária utiliza visão síncrona de grupo para comunicar updates
• O sistema permanece linearizável após a queda do servidor primário
DECSI/ICEA UFOP
34
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Replicação ativa
FE CFEC RM
RM
RM
DECSI/ICEA UFOP
35
Replicação ativa
1. Comunicação: a requisição contém um identificador único e é enviada por multicast confiável ordenado a todos os RM
2. Coordenação: comunicação de grupo garante que as requisições são entregues a cada RM na mesma ordem (pode ser em instantes físicos diferentes)
3. Execução: cada réplica executa a requisição (réplicas corretas retornam a mesma resposta)
4. Acordo/consenso: não é necessário acordo, devido às primitivas semânticas do multicast
5. Resposta: cada réplica envia a resposta diretamente para o front end
DECSI/ICEA UFOP
36
Tolerância à falhas na replicação ativa• RM exercem papeis equivalente -> respondem a uma
sequencia de requisições da mesma forma
• Se alguma RM cai, o estado é mantido pelas demais RMscorretas
• Implementa consistência sequencial
• Ordenação total de requisições garante que todas as réplicas executem a mesma sequencia de requisições
• Cada requisição do front end é executada na ordem FIFO, porque o FE espera pela resposta para fazer nova requisição
DECSI/ICEA UFOP
37
Serviços de alta Disponibilidade
Sistemas que oferecem serviços de alta disponibilidade
•Gossip
•Bayou
•Coda
DECSI/ICEA UFOP
38
Arquitetura Gossip (Fofoca)
• Desenvolvida para implementar serviços de alta disponibilidade por meio da replicação de dados próximos aos pontos onde os grupos de clientes precisam deles
• Os gerenciadores de réplicas trocam mensagens periodicamente para transmitir as atualizações que cada um recebeu dos clientes
• Oferece dois tipos básicos de operação: • somente de leitura
• atualizações que modificam mais não leem o estado.
DECSI/ICEA UFOP
39
Arquitetura Gossip (Fofoca)
• Vantagem • Clientes podem continuar a obter um serviço mesmo
quando são separados do resto da rede• Desde que pelo menos um gerenciador de réplica continue a
funcionar na partição.
• Desvantagem • Escalabilidade de seu sistema
• a medida que o número de gerenciadores de réplica aumenta, também aumenta o número de mensagens de fofoca.
DECSI/ICEA UFOP
40
Operações de consulta (query) e updates no serviço gossip
Query Val
FE
RM RM
RM
Query, prev Val, new
Update
FE
Update, prev Update id
Clients
gossip
DECSI/ICEA UFOP
41
Operações de consulta (query) e updates no serviço gossip
Query Val
FE
RM RM
RM
Query, prev Val, new
Update
FE
Update, prev Update id
Clients
gossip
DECSI/ICEA UFOP
42
1. Requisição
2. Resposta de atualização
3. Coordenação
4. Execução
5. Resposta de Consulta
6. Acordo
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Carimbo de tempo
FE
Clients
FE
Service
Vector
timestamps
RM RM
RM
gossip
DECSI/ICEA UFOP
43
Front ends propagam seus timestamps sempre que um cliente se comunica diretamente
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
44
Processamento das operações
• Front-end envia a requisição
• RM verifica se já não processou baseado na tabela de operações realizadas
• Se não processou, incrementa seu relógio
• Atribui um carimbo de tempo da operação
• Armazena a operação no log
• Verifica se a atualização é estável (ao receber as msg gossip de outros RMs)
• Realiza as atualizações
DECSI/ICEA UFOP
45
Ao receber uma mensagem Gossip
• Integrar o log recebido com o seu próprio
• Aplicar as atualizações que se tornaram estáveis e não foram executadas antes
• Eliminar registros do log e entradas na tabela de operações executadas• Quando for conhecido que as atualizações foram
aplicadas por toda parte e para as quais não há perigo de repetições
• Entradas redundantes
DECSI/ICEA UFOP
46
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
47
• mantém as atualizações em um log
• Realiza apenas atualizações consistentes com suas garantias de ordenação
• Mantem no log até que outras réplicas também tenham recebido a atualização
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
48
• Carimbo de tempo vetorial
• Atualizações que foram aceitas pelo gerenciador de réplica
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
49
valor do estado da
aplicação
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
50
carimbo de tempo vetorial que representa as atualizaçõesrefletidas no valor
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
51
• Contém um carimbo de tempo vetorial de todos os outros gerenciadores de réplica
• Preenchido com carimbos de tempo que chegam deles em mensagens de fofoca
Os componentes principais do estado de uma RM gossip
Other replica managers
Replica timestamp
Update log
Value timestamp
Value
Executed operation table
Stable
updates
Updates
Gossip
messages
FE
Replicatimestamp
Replica log
OperationID Update Prev
FE
Replica manager
Timestamp table
DECSI/ICEA UFOP
52
• impede que uma atualização seja aplicada duas vezes
• contendo os identificadores únicos, fornecidos pelo front-end
Considerações sobre o Gossip
• Depende do tempo entre as mensagens gossip• Muito alto: Inunda a rede
• Muito baixo: Pode inviabilizar sistemas de tempo real
• Escalabilidade• R gerenciadores de réplica normalmente reúne G
atualizações em uma mensagem de fofoca, então o número de mensagens trocadas é de
2 + (R – 1)/G.
DECSI/ICEA UFOP
53
Bayou
• Garantia de disponibilidade menor que Gossip
• Suporta conectividade variável
• Permite a detecção/solução de conflitos
DECSI/ICEA UFOP
54
Bayou
• Mantido na forma de um banco de dados
• consultas e atualizações
• Desfaz e refaz as atualizações no banco de dados
• cada gerenciador de réplica receberá o mesmo conjunto de atualizações e aplicará essas atualizações de maneira tal que os bancos de dados dos gerenciadores de réplica sejam idênticos
DECSI/ICEA UFOP
55
Committed updates e tentativeupdates no Bayou• Atualizações são marcadas como de tentativa
quando são aplicadas a um banco de dados pela primeira vez• o sistema pode desfazê-las e reaplicá-las
• Atualizações de tentativa são colocadas em uma ordem canônica, e após aplicadas são confirmadas• permanecem aplicadas em sua ordem definida.
DECSI/ICEA UFOP
56
Committed updates e tentativeupdates no Bayou
c0 c1 c2 cN t0 t1 ti
Committed Tentative
t2
Tentative update ti se torna o próximo committed update
E é inserido após o último committed update cN.
ti+1
DECSI/ICEA UFOP
57
Considerações Bayou
• Voltado para aplicações de “co-working”• Focar que o que foi feito por um usuário, não conflite
com outro
• Maior complexidade para o desenvolvedor • precisa fornecer verificações de dependência e
procedimentos de integração
• Maior complexidade para o usuário• Usuário pode lidar com dados que ainda não foram
confirmados
DECSI/ICEA UFOP
58
Sistema de arquivos Coda
• Um sistema de arquivo distribuído com réplicas
• Desenvolvido na Universidade de Carnegie Melon
DECSI/ICEA UFOP
59
Arquitetura CODA
• Venus Cliente
• Vice Servidores
DECSI/ICEA UFOP
60
Estratégia de replicação do CODA
• Permite que a modificação dos arquivos prossiga quando a rede é particionada ou durante a operação desconectada
• Mantém histórico de atualização de cada réplica de arquivo• Histórico baseado em carimbo de tempo
• Permite que conflitos em potencial possam ser detectados e submetidos à intervenção manual
DECSI/ICEA UFOP
61
Estratégias de replicação
• Gossip
• Focado em manter todos os servidores atualizados
• Bayou
• Focado em resolver conflitos
• Permite que usuários operem “offline”
• CODA
• Sistema de arquivo distribuído
DECSI/ICEA UFOP
62
Transações em dados replicados
• Uma transação sobre objetos replicados deve ser idêntica à dos objetos não replicados.• capacidade de serialização de uma cópia
• Principais problemas• se a requisição de um cliente pode ser tratada em
qualquer um dos gerenciadores de réplica;
• se o gerenciador de réplica contatado por um cliente pode adiar o encaminhamento das requisições até que uma transação seja confirmada
• como executar um protocolo de confirmação de duas fases.
DECSI/ICEA UFOP
63
Arquitetura para Transações replicadas
B
A
Client + front end
BB BA A
getBalance(A)
Client + front end
Replica managersReplica managers
deposit(B,3);
UT
DECSI/ICEA UFOP
64
Um lê/Todos EscrevemRead-one/write all
Arquitetura para Transações replicadas• Estratégia preguiçosa de atualização
• gerenciador de réplica adia o encaminhamento das requisições de atualização para outros gerenciadores de réplica do grupo, até que uma transação seja confirmada
• Estratégia ávida de atualização• encaminha cada requisição de atualização para todos os
gerenciadores de réplica necessários dentro da transação e antes de confirmar
DECSI/ICEA UFOP
65
Arquitetura para Transações replicadasProtocolo de confirmação de duas fases
• Primeira fase:• coordenador envia a requisição de canCommit? para os
operários,
• os quais a passam para os outros gerenciadores de réplica e reúnem suas respostas, antes de responder para o coordenador.
• Segunda fase:• o coordenador envia a requisição de doCommit ou
doAbort, a qual é passada para os membros dos grupos de gerenciadores de réplica.
DECSI/ICEA UFOP
66
Replicação Cópias disponíveis
A
X
Client + front end
P
B
Client + front end
Replica managers
deposit(A,3);
UT
deposit(B,3);
getBalance(B)
getBalance(A)
Replica managers
Y
M
B
N
A
B
DECSI/ICEA UFOP
67
O que acontece se um servidor falhar antes de replicar?
Replicação Cópias disponíveis
A
X
Client + front end
P
B
Client + front end
Replica managers
deposit(A,3);
UT
deposit(B,3);
getBalance(B)
getBalance(A)
Replica managers
Y
M
B
N
A
B
DECSI/ICEA UFOP
68
X e N falham após a operação getBalance
Replicação Cópias disponíveis
A
X
Client + front end
P
B
Client + front end
Replica managers
deposit(A,3);
UT
deposit(B,3);
getBalance(B)
getBalance(A)
Replica managers
Y
M
B
N
A
B
DECSI/ICEA UFOP
69
• O controle de concorrência de A no gerenciador de réplica X não impede que a transação U atualize A no gerenciador de réplica Y.
• O controle de concorrência de B no gerenciador de réplica N impede que a transação T atualize B nos gerenciadores de réplica M e P
Partição de rede
Client + front end
B
withdraw(B, 4)
Client + front end
Replica managers
deposit(B,3);
UTNetwork
partition
B
B B
DECSI/ICEA UFOP
70
Partição de rede
• Estratégia otimista• permitem atualizações em todas as partições
• Pode levar a inconsistências entre as partições, as quais deverão ser resolvidas quando o particionamento for reparado
• Estratégia pessimista• limita a disponibilidade
• mas impede a ocorrência de inconsistências durante o particionamento
DECSI/ICEA UFOP
71
Partição de rede
• Em caso de partição deve-se estabelecer regras que as operações só sejam executadas em uma partição
• Protocolo de consenso de Quórum• Um quorum é um subgrupo degerenciadores de réplica
cujo tamanho proporciona a ele o direito de executar operações.
DECSI/ICEA UFOP
72
Protocolo Quorum Consensus
Sistema de Quóruns:
• Conjunto de subconjuntos das réplicas, tal que quaisquer dois subconjuntos se intersectam.• N réplicas -> Quórum: qualquer maioria: |Q|>N/2
• Cada réplica guarda:• valor do objeto (registo)
• Timestamp e versão
• A cópia mais atualizada mantém a versão corrente
73DECSI/ICEA UFOP
Protocolo Quorum Consensus
• Operação de Leitura• Envia pedido de leitura para todas as réplicas
(retransmitindo-o até concluir a operação, para superar falhas temporárias na rede)
• Ao receber pedido, • réplica responde ao cliente comvalor atual de <val,ts>
• Cliente aguarda resposta de um quórum
• Escolhe valor associado ao maior timestamp
74DECSI/ICEA UFOP
Protocolo Quorum Consensus
• Operação de Escrita (2 fases – leitura e escrita)• Efetua pedido de leitura a todas as réplicas (ler
timestamp atual)
• Aguarda resposta de um quórum
• Escolha o maior timestamp, t, e incrementa
• Efetua um novo pedido a todas as réplicas para escrever <novo-val, t+1>
• Servidores respondem ack, e apenas guardam novo-valse o timestamp for maior do que o atual
• Cliente aguarda acknowledge de um quórum
75DECSI/ICEA UFOP
Protocolo Quorum Consensus
• Problema: • Duas escritas concorrentes podem escolher o mesmo
timestamp
• Solução: timestamp = <Nº seq., client-id>
76DECSI/ICEA UFOP
Cenários para o protocolo Quorum concensus de Gifford
Example 1 Example 2 Example 3
Latency Replica 1 75 75 75
(milliseconds) Replica 2 65 100 750
Replica 3 65 750 750
Voting Replica 1 1 2 1
configuration Replica 2 0 1 1
Replica 3 0 1 1
Quorum R 1 2 1
sizes W 1 3 3
Derived performance of file suite:
Read Latency 65 75 75
Blocking probability 0.01 0.0002 0.000001
Write Latency 75 100 750
Blocking probability 0.01 0.0101 0.03
DECSI/ICEA UFOP
77
Protocolo Quorum Consensus de Gifford• Vantagens:
• Primeiro protocolo que tolera falhas silenciosas em sistemas assíncronos
• Réplica que falhe temporariamente e recupera está imediatamente pronta para participar
• Ficará naturalmente atualizada quando receber próximo pedido de escrita
• Desvantagens:• À medida que os nós falham, há uma degradação da
disponibilidade.
• Quoruns são grandes
DECSI/ICEA UFOP
78
Concluindo
• Replicação visa aumentar a disponibilidade do sistema
• As réplicas devem manter consistência entre si
• A replicação pode ser passiva ou ativa
• Transações com dados replicados podem usarreplicação passiva• Em caso de partição, protocolo consensus permite as
operações nas cópias disponíveis
DECSI/ICEA UFOP
79
Questões
DECSI/ICEA UFOP
Vinícius Fernandes Soares Mota
Replicação
80