Arquiteturas Tolerantes a faltas em Sistemas Distribuídos Sistemas Distribuídos

Transcrição

1 Arquiteturas Tolerantes a faltas em Sistemas Distribuídos Replicação Replicação Conceito simples: manter cópias dos dados em múltiplos computadores Exemplos do nosso dia a dia? Page 1 1

2 Replicação: que benefícios? Melhor disponibilidade O sistema mantém-se disponível mesmo quando: Alguns nós falham A rede falha, tornando alguns nós indisponíveis Melhor desempenho e escalabilidade Clientes podem aceder às cópias mais próximas de si Melhor desemepnho Caso extremo: cópia na própria máquina do cliente (cache) Algumas operações podem ser executadas apenas sobre algumas das cópias Distribui-se carga, logo maior escalabilidade Quantas falhas consegue um sistema replicado tolerar? Se as falhas forem silenciosas? Esperaríamos que f+1 réplicas tolerassem f nós em falha Basta que uma réplica correcta responda para termos o valor correcto E se os nós puderem falhar de forma bizantina? Aí pode acontecer que, entre as respostas que recebermos, até a um máximo de f podem ser erradas Logo a única alternativa é recebermos respostas iguais de pelo menos f+1 réplicas correctas Logo esperaríamos que 2f+1réplicas tolerassem fnós com falhas bizantinas Mas a realidade é mais complicada e normalmente precisamos de mais réplicas Page 2 2

3 Replicação: requisitos Transparência de replicação Utilizador deve ter a ilusão de estar a aceder a um objeto lógico Objeto lógico implementado sobre diferentes cópias físicas, mas sem que o utilizador se aperceba disso Replicação: requisitos Consistência Operações efetuadas sobre os objetos lógicos devem satisfazer a especificação de correção desses objetos Page 3 3

4 Consistência: exemplo Cópias de contas bancárias x e y mantidas em réplicas A e B Clientes invocam operações sobre uma réplica Operação executada sobre a cópia local e retorna Alteração é depois propagada à outra réplica Problema? Consistência Como definir? Page 4 4

5 Antes de começarmos... Múltiplas cópias dos dados (réplicas), dois clientes Cliente i invoca operaçõeso i0, o i1, o i2,... Operações síncronas: cliente espera pelo retorno antes de invocar próxima operação Cada réplica executa em série as operações de ambos os clientes Exemplo: o 10, o 11, o 20,o 12, o 21, o 22,o 13, o 23, o 14 As réplicas não executam necessariamente as operações na mesma ordem Linearizabilidade Captura uma execução possível caso o sistema não fosse replicado Um sistema replicado diz-se linearizável sse: Existe uma serialização virtual que: É correta segundo a especificação dos objetos, e Respeitao tempo realemqueas operaçõesforam invocadas A execuçãoobservada porcadacliente é consistente com essaserializaçãovirtual (para todos os clientes) Istoé, osvaloresretornados nasleiturassãoos mesmos Page 5 5

6 Este exemplo é linearizável? Para responder, procurar uma serialização virtual que cumpra as condições anteriores Este exemplo é linearizável? Page 6 6

7 Consistência sequencial Condição mais fraca, porquê? Um sistema replicado diz-se sequencialmente consistente sse: Existe uma serialização virtual que: É correta segundo a especificação dos objetos, e Respeitao tempo reala ordemdo programade cada cliente A execuçãoobservada porcadacliente é consistente com essaserializaçãovirtual (para todos os clientes) Consistência sequencial Permite implementações mais realistas que linearizabilidade Para a maioria das aplicações, consistência sequencial é suficiente Daqui para a frente tentaremos construir soluções que ofereçam esta garantia Page 7 7

8 Este exemplo é sequencialmente consistente? Sistemas replicados Page 8 8

9 Model arquitetural base Requests and replies C FE RM RM Clients Front ends Service C FE RM Replica managers As cinco fases de uma invocação num sistema replicado Pedido O front end enviao pedidoa um oumaisgestoresde réplica Coordenação Osgestoresde réplicascoordenam-se para executaremo pedido consistentemente Execução Cadagestorde réplicaexecutao pedido Acordo Osgestoresde réplicasacordamqualo efeitodo pedido Resposta Um oumaisgestoresde réplicarespondemaocliente Diferentes soluções podem omitir ou reordenar algumas fases. Page 9 9

10 Pressupostos nos slides seguintes Processos podem falhar silenciosamente Ou seja, não há falhas arbitrárias de processos Operações executadas em cada gestor de réplica não deixam resultados incoerentes caso falhem a meio Replicação total Cada gestor de réplica mantém cópia de todos os objetos lógicos Conjunto de gestores de réplica é estático e conhecido a priori Replicação Passiva vs. Activa Replicação Passiva ( primarybackup ) Os clientes interatuam com um servidor principal. Os restantes servidores estão de reserva (backups), quando detetam que o servidorprimário falhou, um deles torna-se o primário; Politica de Recuperação da falta Replicação Ativa Todos os servidores recebem pela mesma ordem os pedidos dos clientes, efetuam a operação, determinam qual o resultado corretopor votação, e respondem ao cliente. Política de Compensação da falta 2014 Sistemas Distribuídos Page 10 10

11 Replicação Passiva Replicação passiva: arquitectura C Serviço de Nomes FE Primary RM RM Backup C FE RM Backup Page 11 11

12 Um Protocolo Simples de Replicação Passiva Resposta Acordo Exec. Coordenação Pedido FE envia pedido aoprimário Usando semântica no-máximo-1-vez Primário ordenaospedidos porordemde chegada Se pedido repetido, devolve resposta já guardada Primário executa pedido e guarda resposta Primário enviaaossecundários: (novo estado, resposta, id.pedido) Primário responde aofront end, queretorna ao cliente Que simplificações possíveis com operações determinísticas? Deteção da falha do primário Solução com 1 secundário apenas Primário enviamensagens I m alive cadap unidades de tempo Se o secundário nãorecebermensagem I m alive apósexpirar um temporizador, torna-se o primário: Avisaosfront endse/ouo registode nomes Começa a processar os pedidos Se front end fez pedido e nãorecebeuresposta, reenvia o pedido para o novo primário Page 12 12

13 FE Exemplo P 1 3 P 1 4 P 2 Mensagens de Prova de vida t max 2 1 Mensagem do cliente 2 Mensagem de update do secundário 3 Resposta ao cliente Em que instante P 2 pode assumir que é o primário? Pressupostos O que pode acontecer se falharem estes pressupostos? A comunicação é fiável o transporte recupera de faltas temporárias de comunicação e não há faltas permanentes; Sistema síncrono; em particular, são conhecidos os limites máximos para: Tempo de transmissão de uma mensagem na rede (tmax) Tempo de processamento de pedido; Taxa de desvio dos relógios locais A rede assegura uma ordem FIFO na comunicação Nós só têm faltas por paragem silenciosa A semântica de invocação dos RPC é no-máx-1-vez Page 13 13

14 Solução garante consistência sequencial? Numa situação sem falhas do primário? Sim, pois clientes interagem apenas com uma réplica (do primário) E caso o primário falhe e seja substituído por secundário? Mais complicado de analisar Cenários de Falha do primário (I) FE P S 1 /P O S 2 tem de ser colocado em funcionamento com a base de dados consistente a partir de S 1 2 New S 2 Sequencialmente consistente Page 14 14

15 Cenários de Falha do primário (II) FE P S 1 /P FE New S 2 Sequencialmente consistente Cenários de Falha do primário (III) FE P S 1 /P New S Necessário que o FE reenvie o pedido com semântica nomáx-1-vez e receberá a resposta do secundário, que foi actualizado correctamente Sequencialmente consistente Page 15 15

16 Cenários de Falha do primário (IV) FE P S 1 /P O sistema ficou consistente O news tem de ser colocado em funcionamento com a base de dados consistente a partir de S1 New S 2 Sequencialmente consistente E se houver múltiplos secundários simultâneos? Após deteção da falha do primário, secundários disponíveis elegem o novo primário Mais complicado Necessário assegurar que todos os secundários elegem o mesmo primário Matéria fora do âmbito das teóricas de SD Page 16 16

17 Como medir os custos da replicação? Grau de replicação: número de servidores usados para implementar o serviço Tempo de resposta (blocking time): tempo máximo entre um pedido e a sua resposta, no período sem falhas Tempo de recuperação (failover time): Tempo desde falha do primário até clientesernotificadodo novo primário Objectivo: assumindo que f componentes podem falhar, minimizar as métricas acima Custos da nossa solução? Pensar em casa! 2014 Sistemas Distribuídos Page 17 17

18 Custos da nossa solução Custos Grau de replicação: óptimo f+1 réplicas toleram f faltas Tempo de resposta: 2*t max ignorando tempo de processamento Tempo de recuperação: P+3*t max Desde falha até cliente ser notificado Assumindo situação mínima em que o secundário avisa o cliente; com um servidor de nomes é mais demorado Assumindo taxa de desvio dos relógios é nula 2014 Sistemas Distribuídos 2º Projeto de SD Aplicar replicação passiva ao RegistoFatura Detalhes sairão na próxima semana Que alterações implica sobre o projeto? Page 18 18

19 Replicação Ativa Replicação Activa RM C FE RM FE C RM Page 19 19

20 Protocolos de replicação ativa As réplicas são todas idênticas e executam em paralelo o mesmo serviço como máquinas de estado determinísticas FE do cliente envia mensagem aos gestores de réplica Cada gestor executa a mensagem e envia a resposta O FE espera por um conjunto de respostas e retorna uma delas Por quantas respostas precisa o FE esperar? Se chegarem respostas diferentes, qual escolher? Tentemos construir um protocolo de replicação ativa Page 20 20

21 Modelo de interação/faltas que assumiremos Sistema assíncrono em que: Mensagens não se perdem mas podem chegar arbitrariamente atrasadas Não há garantia de recepção FIFO Réplicas podem falhar silenciosamente Simplificação: Interface leitura/escrita de registo Sistema replica apenas um registo Por exemplo, um inteiro Suporta apenas duas operações Leitura do registo replicado val = read( ); Escrita no registo replicado ack = write(new_val); Queremos garantir consistência sequencial Page 21 21

22 Uma solução hipotética: Protocolo write-all-avaliable Protocolo write-all-avaliable Para escrever, o FE: Envia pedido de escrita para todas as réplicas Cada réplica que recebe o pedido, escreve o novo valor sobre o seu registo local e responde ack Quando receber ack de pelo menos uma réplica, FE dá a escrita como terminada Para ler, o FE: Envia pedido de leitura para todas as réplicas Cada réplica que recebe o pedido responde com o valor actual do registo local Cliente espera pela primeira resposta e retorna-a Page 22 22

23 Write-all-available: vantagens aparentes Grau de replicação óptimo: f+1 réplicas toleram f falhas Tanto para efectuar escritas como leituras Operações muito rápidas Basta receber a primeira resposta e FE retorna Tipicamente, a primeira resposta chega da réplica mais próxima do cliente e/ou menos sobrecarregada Um caso particularmente interessante é quando existe uma réplica na mesma máquina do cliente Write-all-avaliable parece ter grau de replicação óptimo mas O que pode acontecer caso uma réplica não receba um pedido de escrita e depois responda a leitura? Em caso de mensagem perdida, atrasada ou falha temporária da réplica Réplica pode levar FE a retornar leitura inconsistente! Mesmo quando não há falhas, o que pode correr mal? Se houver múltiplos pedidos de escrita concorrentes, réplicas podem ficar inconsistentes e leituras posteriores retornarem 2013 valores diferentes! Sistemas Distribuídos Page 23 23

24 Uma solução hipotética: Protocolo write-all-avaliable Uma melhor solução: Protocolo Quorum Consensus Page 24 24

25 Protocolo Quorum Consensus Sistema de Quóruns: conjunto de sub-conjuntos das réplicas, tal que quaisquer dois sub-conjuntos se intersetam Por exemplo: Quórum ser qualquer maioria, Q >N/2 Cada réplica guarda: valor do objecto(registo) respectivo timestamp, ts Protocolo Quorum Consensus Operação de Leitura FE enviapedidode leiturapara todasas réplicas No-máximo-1-vez Ao receber pedido, réplica responde ao cliente com valor actual de <val,ts> Cliente aguarda resposta de um quórum Escolhe valor associado ao maior timestamp Page 25 25

26 Pedido Coord. Respost + exec. a Quorum Consensus Escrita assumindo escritor único FE do escritormantém número de sequência, seq Operação de Escrita: ts= ++seq FE envia write(novo-val, ts) a todas as réplicas (Servidores respondem ack, e apenas guardam novo-valse o timestamp for maiordo queo actual) FE escritor aguarda acknowledge de um quórum Assim que tiver acknowledge de um quórum retorna ao cliente Garante consistência sequencial? Exemplo c c calcula t 1 = <t 0.seq#+1, cid> r1 x r1 r2 r3 x r2 r3 Fase de Leitura Lê <v 0,t 0 > Fase de Escrita Escreve <v 1,t 1, > Oper. de Leitura Lê <v 1,t 1 > Oper. de Escrita do valor v 1 Sequencialmente consistente Page 26 26

27 Quorum Consensus Versão múltiplos escritores/leitores Timestamp passa a ser <Nº seq., client-id> Assume-se quecadafe tem um client-id único Aocompararde timestamps, comparamoso nºseq.; em caso de empate, client-id desempata Quorum Consensus Versão múltiplos escritores/leitores Operaçãode Escrita(2 fases leitura e escrita): FE efectuapedidode leituraa todasas réplicas(ler timestamp actual) Aguarda resposta de um quórum Escolha o nºseq. do maior timestamp Efectuaum umnovo pedidoa todasas réplicas para escrever <novo-val, <nºseq+1, client-id>> (Servidores respondem ack, e apenas guardam novo-valse o timestamp for maiordo queo actual) FE aguardaacknowledge de um quórum antes de retornar ao cliente Page 27 27

28 Variantes ao protolo: pesos variáveis Cada réplica tem um peso não negativo Soma total de pesos é conhecida a priori Um quórum passa a ser qualquer conjunto de réplicas tal que a soma do peso do quórum é superior a (peso total do sistema)/2 Interessante porque permite dar maior peso a réplicas mais fiáveis, com melhor conectividade ou maior poder computacional Variantes ao protocolo: Quóruns de leitura e escrita O peso exigido para cada tipo de operação passa a ser distinto: read threshold (RT) para leituras write threshold(wt) para escritas Estes parâmetros têm de assegurar que: 2WT > peso total do sistema, e RT + WT > peso total do sistema Interessante porque permite optimizar uma operação, à custa da outra Por exemplo, em sistemas em que as leituras são mais frequentes, podemos ter RT << WT Page 28 28

29 Quorum Consensus: Vantagens? Primeiro protocolo que aprendemos que tolera falhas silenciosas em sistemas assíncronos Réplica que falhe temporariamente e recupera está imediatamente pronta para participar Ficará naturalmente actualizada quando receber próximo pedido de escrita Quorum Consensus: Desvantagens? Protocolo caro : exige muitas réplicas para tolerar número curto de falhas Com quóruns de maioria, precisamos de 2*f+1 réplicas para tolerar f falhas de réplicas Leituras implicam respostas de múltiplas réplicas Em muitos sistemas, leituras são predominantes, logo o ideal seria permitir que leitura retornasse após resposta de uma réplica apenas Uma hipótese para conseguir isso seria definir WT máximo, mas aí deixaríamos de tolerar qualquer falha em escritas Page 29 29

30 Para além do Quorum Consensus Suporte a interfaces genéricas Uso de transações distribuídas Veremos mais à frente no semestre Tolerância a f gestores de réplica bizantinos Várias soluções disponíveis, normalmente baseadas em replicação ativa Quóruns maiores, pois é necessário acautelar o pior caso: mesmo que o quórum contenha as f réplicas bizantinas, há também réplicas corretas em número suficiente no quórum Mensagens autenticadas, para evitar que réplicas bizantinas enviem mensagens em nome de réplicas corretas Para além do Quorum Consensus Melhor eficiência nos acessos de leitura Combinar técnicas de protocolos anteriores Exemplo: protocolos de virtual partition Na operação normal, usa-se write-all dentro do conjunto de gestores de réplica Quorum consensus usado apenas quando há suspeita de falha de gestor de réplica Usado para que restantes gestores acordem em retirar o gestor suspeito de falha do grupo Grupo chama-se view e este caso chama-se view change Page 30 30