Sistemas Distribuídos Replicação. Vinícius Fernandes Soares Mota

Transcrição

1 Sistemas Distribuídos Replicação Vinícius Fernandes Soares Mota 1

2 2 O Papel da replicação

3 Melhorando serviços com dados replicados 3 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.

4 Melhorando serviços com dados replicados 4 Balanceamento de carga carga de trabalho é compartilhada entre servidores amarrando-se vários IPs a um único nome de DNS.

5 Melhorando serviços com dados replicados 5 Tolerância à falha se f de f + 1 servidores falham, pelo menos um mantémse 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

6 Melhorando serviços com dados replicados 6 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. P n : probabilidade de n servidores falharem 1 P n : disponibilidade do serviço por exemplo, se P = 5%, n = 3 => serviço está disponível % do tempo

7 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?

8 8 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? Probabilidade Falha individual = 4/(5*24 ) ~ Disponibilidade do serviço: =

9 Modelo arquitetural básico para o gerenciamento de dados replicados 9 Requisições e respostas C FE RM RM Clientes Front ends Serviço C FE RM Replica managers Transparência de replicação usuário/cliente não precisa saber que existem diversas cópias do recurso Consistência de replicação os dados são consistentes entre todas as réplicas, ou estão no processo de se tornarem consistentes

10 10 Gerenciamento de replicação 5 Fases que afetam o desempenho de acesso a objetos replicados Requisição Coordenação Execução Acordo Resposta

11 11 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 aplicadas ordem 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

12 12 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

13 13 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

14 14 Modo de visualização - Views Uma view V p (g) é o entendimento do processo p de seu grupo (lista de membros) Exemplo: V p.0 (g) = {p}, V p.1 (g) = {p, q}, V p.2 (g) = {p, q, r}, V p.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

15 15 Views Requisitos para entrega de uma view Ordem: se p entrega uma v i (g), e então uma v i+1 (g), então nenhum outro processo q envia v i+1 (g) antes de v i (g) Garantia de consistência Integridade: se p envia v i (g), então p está na view v i (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 views entregues a p Previne soluções triviais

16 Comunicação síncrona em uma view 16 Usa serviço de comunicação de grupo + multicast confiável Garantias providas pelo protocolo multicast confiável: Integridade: se p enviou a mensagem m, p não irá enviar m novamente, 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

17 17 Grupos de comunicação 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

18 18 Grupos de comunicação 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 a (Permitido). p p crashes b (Permitido). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

19 19 Grupos de comunicação a (Permitido). p p crashes b (Permitido). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) c (Proibido). p p crashes d (Proibido). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

20 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

21 21 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

22 22 Serviços Tolerantes a Falhas Inicialmente, x = y = 0 Cliente 1 atualiza objeto x em uma réplica B Réplica B falha

23 23 Serviços Tolerantes a Falhas Inicialmente, x = y = 0 Cliente 1 atualiza objeto x em uma réplica B Réplica B falha X não foi atualizado no servidor A Houve atualização de X no servidor B

24 24 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

25 25 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

26 26 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.

27 27 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

28 28 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

29 29 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

30 30 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.

31 31 Consistência sequencial 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).

32 Modelo de tolerância à falhas baseado em replicação passiva (backup primário) 32 Primary C FE RM RM Backup C FE RM Backup

33 Replicação passiva (backup primário) 33 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

34 Tolerância à falhas na replicação passiva 34 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

35 35 Replicação ativa RM C FE RM FE C RM Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

36 36 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

37 Tolerância à falhas na replicação ativa 37 RM exercem papeis equivalente -> respondem a uma sequencia de requisições da mesma forma Se alguma RM cai, o estado é mantido pelas demais RMs corretas 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

38 38 Serviços de alta Disponibilidade Sistemas que oferecem serviços de alta disponibilidade Gossip Bayou Coda

39 39 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.

40 40 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.

41 Operações de consulta (query) e updates no serviço gossip 41 RM RM gossip RM Query, prev Val, new Update, prev Update id FE FE Query Val Update Clients

42 Operações de consulta (query) e updates no serviço gossip Requisição 2. Resposta de atualização RM 3. Coordenação 4. Execução RM gossip RM 5. Resposta de Consulta Query, prev Val, new Update, prev Update id 6. Acordo FE FE Query Val Update Clients

43 43 Carimbo de tempo Service RM Front ends propagam seus timestamps sempre que um cliente se comunica diretamente RM FE gossip Vector timestamps RM FE Clients Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

44 Os componentes principais do estado de uma RM gossip 44 Gossip messages Other replica managers Replica timestamp Replica log Replica manager Timestamp table Replica timestamp Update log Stable updates Value timestamp Value Executed operation table FE Updates FE OperationID Update Prev

45 45 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

46 Ao receber uma mensagem Gossip 46 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

47 Os componentes principais do 47 estado de uma RM gossip Gossip messages Other replica managers Replica timestamp Update log Replica timestamp Timestamp table Stable updates Replica log Value timestamp Value Replica manager Executed operation table 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 FE Updates FE OperationID Update Prev

48 Os componentes principais do 48 estado de uma RM gossip Gossip messages Other replica managers Replica timestamp Replica log Carimbo de tempo vetorial Atualizações que foram aceitas pelo gerenciador de réplica Replica manager Timestamp table Replica timestamp Update log Stable updates Value timestamp Value Executed operation table FE Updates FE OperationID Update Prev

49 Os componentes principais do estado de uma RM gossip 49 Gossip messages Other replica managers Replica timestamp Replica log valor do estado da aplicação Replica manager Timestamp table Replica timestamp Update log Stable updates Value timestamp Value Executed operation table FE Updates FE OperationID Update Prev

50 Os componentes principais do 50 estado de uma RM gossip Gossip messages Other replica managers Replica timestamp Replica log carimbo de tempo vetorial que representa as atualizações refletidas no valor Replica manager Timestamp table Replica timestamp Update log Stable updates Value timestamp Value Executed operation table FE Updates FE OperationID Update Prev

51 Os componentes principais do 51 estado de uma RM gossip Gossip messages Other replica managers Replica timestamp Update log Replica timestamp Timestamp table Stable updates Replica log Value timestamp Value Contém um carimbo de tempo vetorial de todos os outros gerenciadores de réplica Replica manager Preenchido com carimbos de tempo que chegam deles em mensagens de fofoca Executed operation table FE Updates FE OperationID Update Prev

52 Os componentes principais do 52 estado de uma RM gossip Gossip messages Other replica managers Replica timestamp Timestamp table Replica log impede que uma atualização seja aplicada duas vezes contendo os identificadores únicos, Replica manager fornecidos pelo frontend Replica timestamp Update log Stable updates Value timestamp Value Executed operation table FE Updates FE OperationID Update Prev

53 53 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.

54 54 Bayou Garantia de disponibilidade menor que Gossip Suporta conectividade variável Permite a detecção/solução de conflitos

55 55 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

56 Committed updates e tentative updates no Bayou 56 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.

57 Committed updates e tentative updates no Bayou 57 Committed Tentative c 0 c 1 c 2 c N t 0 t 1 t 2 t i t i+1 Tentative update t i se torna o próximo committed update E é inserido após o último committed update c N.

58 58 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

59 59 Sistema de arquivos Coda Um sistema de arquivo distribuído com réplicas Desenvolvido na Universidade de Carnegie Melon

60 60 Arquitetura CODA Venus Cliente Vice Servidores

61 61 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

62 62 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

63 63 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.

64 Arquitetura para Transações replicadas 64 Client + front end Client + front end T U deposit(b,3); getbalance(a) Replica managers B Replica managers A A A B B B Um lê/todos Escrevem Read-one/write all

65 Arquitetura para Transações replicadas 65 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

66 Arquitetura para Transações replicadas 66 Protocolo 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.

67 67 Replicação Cópias disponíveis Client + front end T U Client + front end getbalance(a) deposit(b,3); B getbalance(b) deposit(a,3); Replica managers Replica managers M X A Y A P B N B O que acontece se um servidor falhar antes de replicar?

68 68 Replicação Cópias disponíveis Client + front end T U Client + front end getbalance(a) deposit(b,3); B getbalance(b) deposit(a,3); Replica managers Replica managers M X A Y A P B N B X e N falham após a operação getbalance

69 69 Replicação Cópias disponíveis Client + front end T U Client + front end getbalance(a) deposit(b,3); B getbalance(b) deposit(a,3); Replica managers Replica managers M X A Y A P B N B 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

70 70 Partição de rede Client + front end withdraw(b, 4) T Network partition Client + front end deposit(b,3); U B Replica managers B B B

71 71 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

72 72 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.

73 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 73

74 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 74

75 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-val se o timestamp for maior do que o atual Cliente aguarda acknowledge de um quórum 75

76 Protocolo Quorum Consensus Problema: Duas escritas concorrentes podem escolher o mesmo timestamp Solução: timestamp = <Nº seq., client-id> 76

77 Cenários para o protocolo Quorum concensus de Gifford 77 Example 1 Example 2 Example 3 Latency Replica (milliseconds) Replica Replica Voting Replica configuration Replica Replica Quorum R sizes W Derived performance of file suite: Read Latency Blocking probability Write Latency Blocking probability

78 Protocolo Quorum Consensus de Gifford 78 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

79 79 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 usar replicação passiva Em caso de partição, protocolo consensus permite as operações nas cópias disponíveis

80 80 Questões Replicação Vinícius Fernandes Soares Mota