sistemas distribuídos · 2018. 1. 30. · sistemas distribuídos replicação vinícius fernandes...

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


• 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


• 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




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


a (Permitido). b (Permitido).




p

q

r

p crashes


p

q

r

p crashes


a (Permitido). b (Permitido).

p

q

r

view (p, q, r)

p

q

r

p crashes


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


• 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


• Inicialmente, x = y = 0

• Cliente 1 atualiza objeto x em uma réplica B

• Réplica B falha

DECSI/ICEA UFOP

22


• 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


• 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


• 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


• 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


• 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


• 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


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



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



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



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


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



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


FE

Replica manager

Timestamp table

DECSI/ICEA UFOP

48

• Carimbo de tempo vetorial

• Atualizações que foram aceitas pelo gerenciador de réplica



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


FE

Replica manager

Timestamp table

DECSI/ICEA UFOP

49

valor do estado da

aplicação



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


FE

Replica manager

Timestamp table

DECSI/ICEA UFOP

50

carimbo de tempo vetorial que representa as atualizaçõesrefletidas no valor



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


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



Replica timestamp

Update log

Value timestamp

Value


Stable

updates

Updates

Gossip

messages

FE

Replicatimestamp

Replica log


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?


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


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


• 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


• 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


• 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

sistemas distribuídos · 2018. 1. 30. · sistemas distribuídos replicação vinícius fernandes...

Documents