Sistemas Distribuídos

Transcrição

1 I Capítulo 6 Replicação DI/FCT/UNL Replicação... O que é?

2 Replicação: Definição e Objectivos A replicação de dados consiste na manutenção de múltiplas cópias da mesma informação em dispositivos distintos de um sistema distribuído. Replicação... Para que serve?

3 Replicação: Definição e Objectivos A replicação de dados consiste na manutenção de múltiplas cópias da mesma informação em dispositivos distintos. Os objectivos da replicação são o aumento da eficácia e do desempenho dos serviços distribuídos. Replicação... É importante?

4 Replicação: Definição e Objectivos A replicação de dados consiste na manutenção de múltiplas cópias da mesma informação em dispositivos distintos. Os objectivos da replicação são o aumento da eficácia e do desempenho dos serviços distribuídos. A replicação é um conceito de grande importância em Sistemas Distribuídos. Replicação... É usado em sistemas reais?

5 Replicação: Definição e Objectivos A replicação de dados consiste na manutenção de múltiplas cópias da mesma informação em dispositivos distintos. Os objectivos da replicação são o aumento da eficácia e do desempenho dos serviços distribuídos. A replicação é um conceito de grande importância em Sistemas Distribuídos. Tem ampla utilização em sistemas reais Web/Internet Sistemas de ficheiros distribuídos Bases de dados distribuídas Replicação : Desempenho... Como é que a replicação de dados pode ajudar a melhorar o desempenho de um sistema distribuído (serviço)?

6 Replicação: Desempenho A replicação pode ter um impacto considerável no desempenho de uma aplicação distribuída. caching é uma forma de replicação, de uso alargado, que permite melhorar o desempenho de serviços distribuídos. Reduzindo o impacto negativo da latência na comunicação, ao aproximar a informação do local onde ela é requerida... Replicação: Desempenho A replicação pode ter um impacto considerável no desempenho de uma aplicação distribuída. caching é uma forma de replicação de uso alargado que permite melhorar o desempenho de serviços distribuídos ao reduzir o impacto negativo da latência da comunicação, ao aproximar a informação do local onde ela é requerida... a replicação também pode melhorar os tempos de reposta ao permitir ter processamento concorrente de pedidos por vários servidores em simultâneo.

7 Replicação : Desempenho A eficácia da replicação de dados como técnica para melhorar o desempenho é garantida? Replicação: Desempenho A replicação pode ter um impacto considerável no desempenho de uma aplicação distribuída. caching é uma forma de replicação de uso alargado que permite melhorar o desempenho de serviços distribuídos ao reduzir o impacto negativo da latência da comunicação, ao aproximar a informação do local onde ela é requerida... a replicação também pode melhorar os tempos de reposta ao permitir ter processamento concorrente de pedidos por vários servidores em simultâneo. Porém, quando os dados replicados estão sujeitos a modificações é necessário assegurar que as replicas permaneçam consistentes, o que pode incorrer num custo que afectará negativamente o desempenho que é possível conseguir através de replicação...

8 Replicação... Além de potenciar melhorias de desempenho, que outros impactos positivos pode ter a replicação de dados? Replicação: Disponibilidade... Disponibilidade? O que é?

9 Replicação: Disponibilidade A disponibilidade dos serviços é sempre desejável, mas em muitos domínios de aplicação é crítica. A replicação é uma técnica útil para melhorar a disponibilidade de um sistema, aumentando a proporção de tempo em que este opera correctamente com tempos de resposta razoáveis. Ou seja, a replicação é uma forma de contrariar os efeitos dos tipos de falhas que reduzem a disponibilidade de um sistema: falhas de servidores partições de rede e desconexão. Replicação: Falhas de Servidores Se os dados de que depende um serviço forem distribuídos por vários servidores com probabilidades independentes de falhar, então o serviço estará sempre disponível enquanto for possível aos clientes dirigir-se a um servidor alternativo sempre que o servidor habitual falha. A disponibilidade que é possível conseguir irá depender do número de réplicas utilizado e da probabilidade de falha (independente) de cada réplica/servidor. Se p é a probabilidade de um servidor falhar, então a probabilidade de todos terem falhado será p n Disponibilidade : 1 - p n

10 Replicação: Exemplo Disponibilidade Probabilidade de Falha #réplicas 25% 10% 5% % % % % % % % % % % % % % % % % % % Replicação: Tolerância a Falhas A replicação de dados assenta no princípio da redundância e é uma forma de introduzir tolerância a falhas num sistema distribuído

11 Replicação: Tolerância a Falhas A replicação de dados assenta no princípio da redundância e é uma forma de introduzir tolerância a falhas num sistema distribuído A eficácia da replicação de dados como técnica base á tolerância a falhas assenta no facto da redundância ser a forma directa para lidar com falhas de omissão. Replicação : Falhas... Falando de falhas

12 Replicação : Falhas... As questões relacionadas com falhas são delicadas...em especial quando se trata de uma certa classe de falhas Replicação: Tolerância a Falhas... Poderá a replicação de dados ajudar a tornar um sistema distribuído tolerante a falhas incluindo as falhas arbitrárias?

13 Replicação: Tolerância a Falhas... O que são falhas arbitrárias? Exemplos? Replicação: Tolerância a Falhas... Sabotagem?

14 Replicação: Tolerância a Falhas... Poderá a replicação ser uma solução para tornar um sistema tolerante a falhas, incluindo falhas arbitrárias, e.g., incluindo sabotagem? Replicação: Tolerância a Falhas... Poderá a replicação ser uma solução para tornar um sistema tolerante a falhas, incluindo falhas arbitrárias, incluindo sabotagem? SIM!

15 Replicação: Tolerância a Falhas... Poderá a replicação ser uma solução para tornar um sistema tolerante a falhas, incluindo falhas arbitrárias, incluindo sabotagem? SIM! Como? / Porquê? Replicação: Tolerância a Falhas... Poderá a replicação ser uma solução para tornar um sistema tolerante a falhas, incluindo falhas arbitrárias, incluindo sabotagem? SIM! Em caso de sabotagem deliberada, o atacante terá que vencer a redundância do sistema Havendo múltiplas réplicas da mesma informação, não bastará comprometer um servidor O seu esforço terá que ser desdobrado e distribuído pelas réplicas...

16 Replicação: Tolerância a Falhas... Recapitulando, um sistema tolerante a falhas é um sistema que produz resultados correctos na presença das mesmas. Ou, em alternativa, não produz resultados. A replicação de dados e de funcionalidade por múltiplos dispositivos consiste em aplicar o mesmo princípio de redundância para conseguir tornar um sistema distribuído tolerante a uma certa classe de falhas. Em geral, f + 1 réplicas são necessárias para mascarar f falhas por omissão. Em geral, na presença de f falhas arbitrárias, são precisas 2f +1 (ou mesmo 3f +1) réplicas para o mesmo efeito... Replicação: Tolerância a Falhas... Como é que num sistema replicado se dão garantias que os resultados produzidos são fidedignos, na presença de falhas arbitrárias? Porquê 2f+1 réplicas para tolerar f falhas arbitrárias?

17 Replicação: Tolerância a Falhas... Como é que num sistema replicado se dão garantias que os resultados produzidos são fidedignos, na presença de falhas arbitrárias? Porquê 2f+1 réplicas para tolerar f falhas arbitrárias? E se o resultado correcto for identificado por votação? Replicação : Outras Propriedades... Os requisitos da replicação em termos de objectivos a conseguir são importantes, mas a forma de interacção é igualmente importante Que outras propriedades serão, então, desejáveis?

18 Replicação : Interacção...pensando na conveniência dos clientes, dos programadores? Replicação: Transparência Idealmente, a replicação deverá ser tão transparente quanto o possível. Há todo o interesse que os clientes não tenham que se preocupar com os detalhes da replicação, em particular com o número de réplicas existente e da sua localização.

19 Replicação: Correcção Poderá a transparência interferir com a correcção? Correcção? Replicação: Consistência O outro aspecto importante no contexto de um sistema replicado prende-se com o critério de consistência entre réplicas. Será necessário que as réplicas sejam idênticas? O que se ganha e o que se perde se os critérios de consistência forem maleáveis? Afinal, o que é necessário garantir?

20 Replicação: Consistência O outro aspecto importante no contexto de um sistema replicado prende-se com o critério de consistência entre réplicas. Será necessário que as réplicas sejam idênticas? O que se ganha e o que se perde se os critérios de consistência forem maleáveis? Afinal, o que é necessário garantir? É, sobretudo, necessário garantir que a correcção da aplicação distribuída é preservada caso os critérios de consistência da replicação sejam relaxados. Replicação: Nomenclatura... Para efeitos de replicação, chamam-se objectos a todos os dados replicados num sistema. Cada objecto lógico é implementado por um número variável de cópias físicas denominadas de réplicas. Cada uma está alojada num único computador e relacionam-se entre si por um certo grau de consistência nos dados e nas operações que suportam. Apesar de serem cópias não é imperativo que sejam absolutamente idênticas, num dado momento pode ser distintas dependendo das actualizações que receberam...

21 Replicação: Grupos de Objectos Cliente A interacção entre os clientes e os objectos replicados é realizada através de proxies/ frontends. O proxy/frontend intercepta as operações e actualiza as réplicas recorrendo a uma primitiva de comunicação em grupo. réplica a 1 host B réplica a 2 proxy a proxy b comunicação em grupo réplica b 1 host A host C réplica b 2 Replicação: Grupos de Objectos Modelo simples e transparente do ponto de vista do cliente. O grau de consistência das réplicas é condicionado pela semântica da primitiva de comunicação em grupo. proxy a Cliente proxy b comunicação em grupo host A A maior parte da responsabilidade e complexidade de implementação é transferida para o middleware de comunicação em grupo. réplica a 1 host B réplica a 2 réplica b 1 host C réplica b 2

22 Replicação: Grupos de Objectos Se os objectos replicados forem numerosos pode ser mais simples e barato usar um gestor de réplicas por cada máquina. proxy a Cliente proxy b host A Tratar cada grupo de objectos separadamente complica a gestão dos grupos de comunicação; comunicação em grupo e pode dificultar ou encarecer a solução caso seja necessário impor consistência entre grupos distintos de objectos réplica a 1 réplica b 1 Gestor de Réplicas host B réplica b 2 réplica a 2 Gestor de Réplicas host C Replicação: Comunicação em Grupo A replicação suportada por primitivas de comunicação em grupo é um modelo atraente sob diversos aspectos, mas só é eficaz se as garantias oferecidas pelo middleware de comunicação em grupo forem suficientemente fortes: As garantias de fiabilidade e ordenação são cruciais. Em caso de insuficiência, as réplicas irão divergir rapidamente, levando o sistema a produzir resultados erróneos.

23 Replicação: Comunicação em Grupo Em geral, além de fiabilidade é também necessário um critério forte de ordenação na entrega das mensagens ao grupo. No que diz respeito aos dados, a ordenação total causal fiável é preferível pois permite que as réplicas evoluam em conjunto. Garantias mais fracas irão exigir mais trabalho aos níveis superiores para compensar as falhas e, no limite, a responsabilidade pode mesmo ter de ser delegado à aplicação ou e mesmo ao utilizador. É preciso mais... Replicação: Comunicação em Grupo No contexto da replicação, o recurso a primitivas de comunicação em grupo com transparência completa nos aspectos relacionados com a filiação do grupo não é desejável. A replicação tem implícita a presença de falhas, pelo que se o substrato de comunicação em grupo carece de um serviço de notificação de mudanças na filiação do grupo, este terá que ser implementado separadamente. A inclusão de um serviço de notificação da composição do grupo no substrato de comunicação em grupo tem sempre implícito um detector de falhas e permite concertar as entregas de dados com a detecção de falhas, sob um ponto de vista de consistência.

24 Replicação: Comunicação em Grupo Requisitos relativos à filiação dos grupos: Primitivas para alterar a composição do grupo Criar e Destruir grupos; Entrar e Sair de grupos, permitindo a um processo pertencer a vários grupos. Detector de falhas Identificar nós que suspeitos de terem entrado em crash ou terem ficado fora de alcance devido a partições de rede. Actualizar a composição do grupo face às falhas detectadas Replicação: Comunicação em Grupo Requisitos relativos à filiação dos grupos: Comunicação das mudanças de filiação do grupo aos membros Sempre que a composição do grupo se altera, quer por entrada, saída ou falha de algum membro, essa informação é notificada aos membros correntes. Expansão de Endereços Ser capaz de, num dado momento, de forma transparente traduzir o identificador de grupo na lista de endereços correspondente aos membros correntes do grupo.

25 Replicação: Comunicação em Grupo A comunicação das mudanças de vistas (composição/filiação) aos membros do grupo) é muito pertinente Em especial, no que toca à ordenação desses eventos globalmente no grupo e à sua concertação com a entrega das mensagens de dados. Adicionalmente, põe-se a questão da existência ou não de garantias de uniformidade... Replicação: Comunicação em Grupo A título de exemplo, uma garantia forte é a sincronia virtual total, que consiste em garantir que as mudanças de vistas são comunicadas a todos os membros do grupo pela mesma ordem e que esses eventos também estão ordenados pelo mesmo critério usado na entrega das mensagens. Este é um requisito bastante forte O custo da comunicação pode ser bastante elevado, mas do ponto de vista da aplicação ajuda, pois permite com um mínimo de esforço ver as réplicas evoluir em conjunto com elevada consistência.

26 Replicação Passiva: Primário/Secundário A replicação passiva consiste em dar a uma réplica (gestor de réplicas) uma responsabilidade acrescida, enquanto as demais são passivas e servem de reserva/backup. As actualizações são dirigidas primeiramente à réplica primária (ou gestor de réplicas) que, depois, fica encarregue de as repercutir nas réplicas de reserva. pode usar unicast ou multicast para actualização dos secundários. Quando o primário falha, é substituído por uma réplica secundária de reserva. Podendo assim resistir até f falhas (crash), caso existam f+1 réplicas no total. A grande vantagem reside no facto do primário servir de sequenciador e impôr a mesma ordenação das operações sobre todas as réplicas. Replicação Activa Neste modelo, os gestores de réplicas estão ao mesmo nível. A interacção com o sistema de replicação é através de um middleware frontend. O cliente pode dialogar com uma única réplica ou várias. Cliente frontend host A Por comparação das respostas é possível tolerar falhas bizantinas. 3f+1, 2f+1 réplicas/para f falhas. réplica a 1 Gestor de Réplicas host B réplica b 1 réplica b 2 réplica a 2 Gestor de Réplicas host C

27 Replicação Activa : Discussão Colocar todos os gestores de réplicas ao mesmo nível supõe que os clientes se podem ligar a qualquer gestor de réplicas... Pode então haver várias réplicas a ser actualizadas em simultâneo... Para garantir que as réplicas evoluem de forma consistente é preciso impor algum critério global de ordenação... Este problema pode ser tratado usando comunicação em grupo com as características adequadas (ordem total, ordem total causal) Também é possível recorrer a um log se guardam as operações de forma provisória até haver um consenso que elas podem ser repercutidas de forma definitiva. estampilhas vectoriais, relógios físicos sincronizados, etc. Se as operações forem especiais (comutativas ou se puderem ser desfeitas, etc) então poderá ser possível realizar optimizações de carácter optimista Replicação: Desconexão / Assíncronia Em cenários envolvendo desconexão ou latência elevada um modelo de replicação demasiado síncrono não é prático e incompatível com uma elevada disponibilidade. Nestes cenários, a comunicação em grupo pode deixar de fazer sentido. Uma réplica desligada não é necessariamente uma réplica que falhou...mas simplesmente indisponível Como tratar um cenário deste género?

28 Replicação: Soluções epidémicas... Uma forma de suportar replicação com elevada disponibilidade em cenários com conectividade intermitente pode passar por usar técnicas de gossiping/epidemia em alternativa a um modelo de comunicação em grupo síncrono. Cada réplica evolui de forma relativamente autónoma. Se possível, periodicamente, é efectuada uma ronda epidémica, onde cada réplica procura outra, ao acaso, para proceder a uma sincronização. Neste processo, as réplicas trocam a história das actualizações que cada uma viu desde um passado comum; Os logs respectivos são actualizados no processo e as operações ditas estáveis são repercutidas no estado definitivo. (Quando truncar o log?) Este modelo pressupõe que cada operação é anotada com uma estampilha temporal que permite definir uma ordenação total das operações (e.g. relógio vectorial). Replicação : Exemplos - Gossip Architecture - Bayou - Coda FileSystem - LiveFeeds (Content-based Routing)

29 Replication : Gossip Architecture Um framework para implementar serviços com alta disponibilidade, replicando os dados em locais próximos onde existem grupos de clientes Duas operações Queries (read-only) Updates (write-only) Os clientes (via frontend) podem interagir com qualquer réplica, qualquer que esteja disponível e ofereça bom tempo de resposta desde que haja uma réplica, há serviço As réplicas sincronizam-se através de rumores. i.e., os updates são espalhados por epidemia. Replication : Gossip Architecture Garantias: Os clientes recebem um serviço consistente ao longo do tempo Uma query terá uma resposta que reflecte os updates que o cliente já tinha visto (causalidade), mesmo que seja dirigida a uma réplica qualquer ou uma réplica atrasada. A consistência entre réplicas é relaxada, mas as actualizações são incorporadas com garantias de ordenação que tornam as réplicas suficientemente iguais para o domínio de aplicação. pode acontecer que duas réplicas que tenham visto as mesmas actualizações não sejam estritamente iguais. (sem violar causalidade) mas serão equivalentes do ponto de vista da aplicação.

30 Replication : Gossip Architecture Interacção Os updates retornam imediatamente... As queries são bloqueantes... Porquê? Replication : Gossip Architecture Interacção entre Cliente/Réplica Os updates retornam imediatamente... As queries são bloqueantes... Porquê? Uma query terá uma resposta que reflecte os updates que o cliente já tinha visto (causalidade), mesmo que seja dirigida a uma réplica qualquer ou uma réplica atrasada. Interacção entre Réplica/Réplica De vez em quando, trocam rumores com os últimos updates que já viram.

31 Replication : Gossip Architecture Quais os ingredientes fundamentais? Consistência? Replication : Gossip Architecture Quais os ingredientes fundamentais? Estampilhas Vectoriais Log Tabela de Actualizações

32 Replication : Gossip Architecture Quais os ingredientes fundamentais? Estampilhas Vectoriais Causalidade leituras/escritas Log Registar actualizações pendentes que aguardam actualizações em falta Tabela de Actualizações Evitar duplicados Replication : Bayou A replicação tem como objectivo a elevada disponibilidade dos dados. Tal como a Gossip Architecture, usa epidemia para disseminar as operações Oferece ainda suporte para Desconexão É possível consultar e alterar os dados mesmo estando desligado da rede.

33 Replication : Bayou O suporte à desconexão aumenta (grandemente) a possibilidade de conflitos (actualizações concorrentes). O sistema Bayou oferece meios para a resolução automática de conflitos... As operações são reordenadas e ou transformadas Pretende-se resolver conflitos em operações concorrentes Respeitar a intenção da aplicação/utilizador. A replicação deixa de ser transparente Replication : Coda Filesystem Um sistema de ficheiros replicado que suporta desconexão. Replicação entre servidores Disponibilidade e desempenho (débito) Replicação junto dos clientes Desconexão caching de um subconjunto dos ficheiros Faltas implicam a paragem. Sistema optimista para detecção de conflitos Resolução manual

34 Replication : LiveFeeds Replicação aplicada ao encaminhamento baseado no conteúdo. Replication : LiveFeeds Content-based Routing (Publish/Subscribe) As mensagens tem como alvo um conjunto de interessados que manifestaram interesse em determinado tipo / padrão de conteúdo, através de um filtro. As mensagens são filtradas para serem entregues exclusivamente aos interessados. Pretende-se evitar falsos positivos (spam) Pretende-se evitar falsos negativos

35 Replication : LiveFeeds A ideia base no sistema LiveFeeds consiste replicar a filiação por todos os participantes. Cada participante irá conhecer todos os outros participantes e quais os eventos em que eles estão interessados (através do seu filtro). Com base nessa premissa, o encaminhamento pode ser cooperativo, distribuindo o fardo de avaliar os filtros e executar a entrega das mensagens Replication : LiveFeeds Replicação da Filiação/Membership Usa-se um algoritmo de broadcast P2P best-effort, não fiável. Usa-se epidemia para colmatar as falhas... Como se detectam as falhas? As mudanças de vista são anotadas com uma estampilha vectorial cada nó, individualmente, pode detectar e preencher as faltas quando faz uma ronda epidémica com outro nó.

36 O que estudar... G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design, Addison-Wesley, 4th Edition, 2005 Capítulo 15