Slides for Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001.

Apresentação em tema: "Slides for Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001."— Transcrição da apresentação:

1 Slides for Chapter 14: Replication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

2 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zReplicação é a chave para melhorar a performance de serviços, para garantir alta disponibilidade de serviços e tornar serviços em SDs, tolerantes a falhas. zAlta disponibilidade, atualmente, é de interesse crescente, tendendo em direção à computação móvel e conseqüentemente em modo de operação desconectada. zTolerância a Falhas atém-se a serviços de segurança crítica e outros sistemas importantes.

3 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zReplicação é amplamente usada. zExemplos de uso: - O “caching” de recursos de servidores Web em browsers e servidores proxy Web é uma forma de replicação. - O serviço de nomeação DNS mantém cópias de mapeamentos de nomes-para-atributos para computadores, que servem para acessar serviços através da Internet.

4 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zPerformance aumentada: O “caching” de dados em clientes e servidores é bastante conhecido, como um meio de aumentar a performance de aplicações na Web. - O “caching” em browsers e servidores proxy de cópias de recursos Web, evitam a latência de busca de recursos no servidor mantendo o recurso.

5 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication - Dados são algumas vezes replicados transparentemente entre servidores em um mesmo domínio. A carga de trabalho (“Workload”) é compartilhada entre os servidores por ligar todos os endereços IP de servidores ao nome DNS do “site”, digamos, www.aWebSite.org. Um “lookup” de DNS de www.aWebSite.org resulta em um dos endereços IP dos diversos servidores. www.aWebSite.org

6 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication - Replicação de dados que nunca mudam é trivial: aumenta a performance com um baixo custo para o sistema. - Replicação, quando dados mudam, incorre em “overheads” na forma de protocolos projetados para garantir que clientes receberão dados atualizados. - “Overheads” limitam a efetividade de replicação como uma técnica para aumentar a performance.

7 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zAlta Disponibilidade Usuários requerem serviços serem altamente disponíveis. Isto é, a proporção de tempo para o qual o serviço é acessível com tempo de resposta razoável, de ser próximo a 100%.

8 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zCom exceção de, atrasos devidos a conflitos em controle de concorrência pessimista, os fatores que são relevantes para alta disponibilidade são: - Falhas de servidores: replicação é uma técnica para automaticamente manter a disponibilidade de dados apesar das falhas de servidores. - Partições de redes e operações desconectadas: desconexões de comunicação que são deliberadamente realizadas ou são frequentemente não planejadas, na mobilidade de usuários numa rede sem fio.

9 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zTolerância a Falhas Um serviço tolerante a falha, sempre garante um comportamento estritamente correto, apesar de um certo número de falhas e tipo de falhas. - Dados altamente disponíveis, nem sempre são necessariamente estritamente corretos: - os dados podem estar fora de data; - dois usuários em lados opostos de uma partição de rede podem fazer atualizações que conflitam e precisam ser resolvidas.

10 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zA correção diz respeito aos efeitos das operações do cliente sobre os dados, e a atualização recente dos dados proporcionadas por essas operações (freshness of data), suprida ao cliente. zA corretude do serviço, também, diz respeito a escala de tempo (que pode ser curta), quanto a resposta do serviço. - Exemplo: o serviço de Controle de Tráfego Aéreo.

11 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zA mesma técnica usada para alta disponibilidade: replicação de dados e funcionalidade entre computadores é também aplicável para se alcançar tolerância a falhas. z Se até f, de f+1 servidores, “crash”, então em princípio, pelo menos um servidor permanece para suprir o serviço.

12 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zSe até f, de f+1 servidores, podem exibir falhas bizantinas, então em princípio um grupo de 2f+1 servidores podem prover um serviço correto, por ter os servidores corretos substituídos os servidores falhados. zUm sistema distribuído tolerante a falha deve gerenciar a coordenação de seus componentes precisamente, para manter a garantia de correção em face de falhas, as quais podem ocorrer em qualquer tempo.

13 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Replication zRequisitos comuns quando dados são replicados: - transparência de replicação - consistência dos dados: “as operações realizadas sobre um coleção de dados replicados produzem resultados que satisfazem a especificação de correção para aqueles dados”

14 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Consistência Forte zConsistência Forte (o mesmo que Estrita) Garantem que todas as réplicas retém a mesma atualização mais recente(dados autorizados) em qualquer instante de tempo dado.

15 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Consistência Forte zIsto é alcançado se: 1. Todas as réplicas recebem o estado atualizado. 2. Todas as réplicas processam o estado atualizado, na mesma sequência correta através da comunicação de grupo por multicast.

16 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Consistência Fraca zDados replicados são atualizados em um servidor- mestre e propagados de lá para servidores- escravos, usando comunicação um-a-um, ao contrário de comunicação em grupo. zÉ satisfatória para muitos propósitos, tal como certos tipos de armazenagem de registros de administração de sistemas.

17 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.1 A basic architectural model for the management of replicated data FE Requests and replies C Replica C Service Clients Front ends managers RM FE RM

18 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 A basic architectural model for the management of replicated data zModelo de Sistema - Dados, em nosso sistema, consistem de uma coleção de itens, que podem ser um arquivo, ou um objeto Java. - Cada objeto lógico (representando um serviço) é implementado por uma coleção de cópias físicas chamados réplicas.

19 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 A basic architectural model for the management of replicated data - Réplicas são objetos físicos, cada um armazenado em um computador, com dados e comportamento que dizem respeito a algum grau de consistência pela operação do sistema. - As “réplicas” de um dados objeto podem não ser necessariamente idênticas, pelo menos em um dado instante no tempo. Algumas réplicas podem ter recebido atualizações que outras não receberam, ainda.

20 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 A basic architectural model for the management of replicated data zUm modelo de sistema geral para gerenciar réplicas. zDescrever um sistema de comunicação de grupo. zParticularmente úteis para alcançar tolerância a falha através de replicação.

21 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.2 Services provided for process groups Join Group address expansion Multicast communication Group send Fail Group membership management Leave Process group

22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.3 View-synchronous group communication

23 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Modelo de Sistema z Assume-se um sistema assíncrono, na qual processos podem falhar somente por “crash”. zHipótese default: partições de rede podem não ocorrer, mas pode-se considerar o que acontece se partições ocorrem. zCom partições de rede é mais difícil construir detectores de falhas, os quais usa-se para alcançar multicast confiável, totalmente ordenado.

24 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Modelo de Sistema zPor questões de generalidade, o modelo descreve os componentes arquiteturiais pelos seus papéis e não significando implicar que eles são necessariamente implementados por processos distintos. zO modelo envolve réplicas retidas por gerenciadores distintos, que são componentes que contém as réplicas sobre um dado computador e realiza operações sobre elas diretamente.

25 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Modelo de Sistema zEste modelo pode ser aplicado a um ambiente cliente-servidor, no caso em que um gerenciador de réplica é um servidor. zPode ser aplicado a uma aplicação ou processos de aplicação que agem como ambos, cliente e gerenciador de réplica. - Exemplo, o laptop de um usuário viajando num trem pode conter uma aplicação que age como um gerenciador de réplica para a sua agenda.

26 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.4 The passive (primary-backup) model for fault tolerance FE C C RM Primary Backup RM

27 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance zNo modelo passivo de replicação para tolerância a falha, existe em qualquer tempo um único gerenciador de réplica primário e um ou mais gerenciadores de réplicas secundários. zFront-ends correspondem ao mecanismo para se obter transparência de replicação). Podem ser implementados no espaço de endereçamento do cliente ou ser um processo separado. Neste caso, se comunicam somente com o gerenciador de réplica primário, para realizar o serviço.

28 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 zA sequência de eventos quando um cliente “requests” uma operação a ser realizada é como segue: 1. Request: O front end emite o “request”, contendo um único identificador de front end, ao gerenciador de réplica primário. 2. Coordenação: O primário toma cada “request” atomicamente, na ordem na qual ele recebe (FIFO ordering). Ele verifica o identificador único do front-end. Verifica se ele já executou o “request” e se assim, ele simplesmente reenvia a resposta. The passive (primary-backup) model for fault tolerance

29 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance 3. Execução: O primário executa o “request” e armazena a resposta. 4. Acordo: Gerenciadores de Réplicas alcançam consenso sobre o efeito do “request”. Se existe o consenso o “request” ele será realizado (committed). Se o “request” é uma atualização, então o primário envia o estado atualizado, a resposta e o identificador único para todos os backups. Os backups enviam um acknowledgement.

30 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance 5. Resposta: O primário responde ao front end, o qual envia a resposta de volta ao cliente. zSe o primário falha, um dos backups é promovido a agir como o primário. zO primário é substituído por um único backup.

31 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance zSe o primário falha, um dos backups é promovido a agir como o primário. zO primário é substituído por um único backup. zGerenciadores de réplicas que estão funcionando concordam sobre quais operações foram realizadas, no tempo quando a substituição do primário toma lugar.

32 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance zO modelo primary-backup pode ser usado mesmo onde o primário comporta-se não- deterministicamente. Por exemplo,em operação multi-threaded. zUm tal sistema não pode tolerar falhas bizantinas. Se até f, de f+1 servidores, “crash”, então em princípio, pelo menos um servidor permanece para suprir o serviço.

33 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance zO front end tem pouca funcionalidade para implementar tolerância a falha. Ele precisa ter capacidade para procurar o novo primário quando o primário corrente não responde. zReplicação passiva é usada no Sistema de Arquivos Replicados Harp [Liskov et al. 1991]. O Sun Network Information Service (NIS) usa replicação passiva para alcançar alta disponibilidade e boa performance.

34 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The passive (primary-backup) model for fault tolerance zA principal vantagem do modelo passivo de replicação é que leituras e escritas (atualizações) são manipuladas mais eficientemente e a recuperação em caso de falha do servidor primário, é mais rápida. zNeste caso, um servidor somente falha (o primário). zUm algoritmo de eleição é executado, quando uma réplica descobre o servidor falhado, ou ele se torna inacessível devido a um particionamento de rede.

35 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.5 Active replication FEC CRM

36 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zGerenciadores de réplicas são organizados como um grupo. zO front end “multicast” seus requests para o grupo e todos os gerenciadores processam o request independentemente, mas identicamente, e respondem ao front end. zO front end coleta e compara as respostas que ele recebe.

37 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zO número de respostas que o front end coleta depende do número de réplicas falhadas e do algoritmo de multicast. zSe a meta é tolerar falhas por crash e o multicast satisfaz a um acordo uniforme e propriedades de ordenação, então o front end passa ao cliente a primeira resposta que chega de volta de descarta as demais.

38 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zAcordo (Agreement) – em multicast confiável Se um processo correto recebe uma mensagem m, então todos os outros processos corretos em um grupo g, eventualmente, receberão m. zEsta definição é relacionada a atomicidade, a propriedade do “tudo ou nada” aplicada a entrega de mensagens para um grupo

39 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zPropriedade Uniforme: Qualquer propriedade que ocorre, se processos são ou não corretos, é chamada de uma propriedade uniforme. zAcordo Uniforme: Se um processo, se correto ou com falha, recebe uma mensagem m, então todos os processos corretos no grupo g eventualmente receberão m.

40 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zSequência de eventos quando um cliente “request” uma operação: 1. Request: O front end coloca um identificador único ao request e multicast para o grupo de réplicas de servidores, usando ordenação total, com primitiva de multicast confiável. Ele não emite o próximo “multicast” até que ele tenha recebido a resposta.

41 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication 2. Coordenação: O sistema de comunicação de grupo entrega o request para todo gerenciador de réplica correto (sem falha) na mesma ordem total. Ordem Total: Se um gerenciador de réplica manipula r antes de r’, então qualquer gerenciador de réplica correto que manipula r’, manipula r, antes de r’.

42 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication 3. Execução: Todo gerenciador de réplica executa o request identicamente. Eles são máquinas de estado e requests são entregues na mesma ordem total. A resposta contém o identificador de request único do cliente.

43 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication 4. Acordo: Nenhum acordo é necessário, por causa da semântica de entrega do multicast. 5. Resposta: Cada gerenciador de réplica envia sua resposta ao front end.

44 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zExiste uma FIFO ordering quanto ao envio de multicasts pelo front end, visto que ele sempre espera a resposta de um multicast r antes de enviar um multicast r’. zReplicação ativa pode tolerar falhas bizantinas, porque o front end pode coletar e comparar as respostas que ele recebe.

45 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Active replication zSistemas com replicação ativa não alcançam linearidade, isto é porque a ordem total na qual os gerenciadores de réplica processam os requests não é a mesma com a ordem no tempo real no qual os clientes fazem seus requests.

46 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.6 Query and update operations in a gossip service QueryVal FE RM Query,prevVal,new Update FE Update,prevUpdate id Service Clients gossip

47 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.7 Front ends propagate their timestamps whenever clients communicate directly FE Clients FE Service Vector timestamps RM gossip

48 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.8 A gossip replica manager, showing its main state components Replica timestamp Update log Value timestamp Value Executed operation table Stable updates Updates Gossip messages FE Replica timestamp Replica log OperationIDUpdate Prev FE Replica manager Other replicamanagers Timestamp table

49 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.9 Committed and tentative updates in Bayou c0c0 c1c1 c2c2 cNcN t0t0 t1t1 titi CommittedTentative t2t2 Tentative update t i becomes the next committed update and is inserted after the last committed update c N. t i+1

50 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.10 Transactions on replicated data B A Client + front end BBB A A getBalance(A) Client + front end Replica managers deposit(B,3); U T

51 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.11 Available copies A X Client + front end P B Replica managers deposit(A,3); UT deposit(B,3); getBalance(B) getBalance(A) Replica managers Y M B N A B

52 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.12 Network partition Client + front end B withdraw(B, 4) Client + front end Replica managers deposit(B,3); U T Network partition B BB

53 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Page 600 Gifford’s quorum concensus examples

54 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.13 Two network partitions Replica managers Network partition VXYZ TTransaction

55 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.14 Virtual partition XVYZ Replica managers Virtual partition Network partition

56 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.15 Two overlapping virtual partitions Virtual partition V 1 2 YXVZ

57 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 14.16 Creating a virtual partition Phase 1: The initiator sends a Join request to each potential member. The argument of Join is a proposed logical timestamp for the new virtual partition. When a replica manager receives a Join request, it compares the proposed logical timestamp with that of its current virtual partition. –If the proposed logical timestamp is greater it agrees to join and replies Yes; –If it is less, it refuses to join and replies No. Phase 2: If the initiator has received sufficient Yes replies to have read and write quora, it may complete the creation of the new virtual partition by sending a Confirmation message to the sites that agreed to join. The creation timestamp and list of actual members are sent as arguments. Replica managers receiving the Confirmation message join the new virtual partition and record its creation timestamp and list of actual members.