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 executadas 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 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 2015 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, permanentes A semântica de invocação dos RPC é no-máx-1-vez Page 13 13

14 Solução é linearizável? 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 Seq. consistente? Page 14 14

15 Cenários de Falha do primário (II) FE P S 1 /P FE New S 2 Seq. 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 Seq. 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 Seq. 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 Replicação Ativa Replicação Activa RM C FE RM FE C RM Page 17 17

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

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

20 Uma solução hipotética: Protocolo write-all-avaliable Uma solução hipotética: 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 FE espera pela primeira resposta e retorna-a Page 20 20

21 Write-all-avaliable parece ter grau de replicação óptimo mas write(v 1 ) v 01 C write ack write FE v 0 t v 0 Write-all-avaliable parece ter grau de replicação óptimo mas write(v 1 ) v 01 r = read() C read read FE v 0 v 0 v 0 v 0 t Seq. consistente? Page 21 21

22 De quantas réplicas ler/escrever? 1 réplica escrita v 01 3 réplica escritas v 1 2 réplica escritas (uma maioria) v 1 v 0 v 1 v 1 v 0 1 réplica lida v 1 3 réplicas lidas v 0 2 réplicas lidas (uma maioria) Não é seq. consistente Não tolera falhas Uma melhor solução: Protocolo QuorumConsensus, variante ABD (proposta por Attiya, Bar-Noy e Dolev) Page 22 22

23 Protocolo Quorum Consensus Sistema de Quóruns 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 Protocolo Quorum Consensus Réplicas Cada réplica guarda: val, valor do objecto(registo) tag, queidentifica a versão Tag é compostapor: seq(númerode sequênciada escritaquedeuorigemà versão) pid(identificador do processo que escreveu) Dizemosquetag1 é maiorque tag2 sse: seq1 > seq2, ou seq1=seq2 e pid1>pid2 Page 23 23

24 Protocolo Quorum Consensus Leituras Frontend: Envia read() para todos os gestores de réplica No-máximo-1-vez AguardaporQ respostas SejamaxValo valor que recebeu com maior tag Retorna maxval Gestor de réplica i: Ao receber read(), responde com <val i,tag i > Protocolo Quorum Consensus Escritas Frontend: Executa leitura para obter maxtag=<seq,pid> newtag = <seq+1, meupid> Enviawrite(val, newtag) a todos os gestores de réplica EsperaporQ acks Retorna ao cliente Gestor de réplica i: Ao receber write(v,t): se (t > tag i ) { val i = v tag i = t } Responde ack Page 24 24

25 Exemplo 1: escrita isolada FE calcula t 1 = <seq 0 +1, pid> FE w 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 Seq. consistente? Exemplo 2: escritas concorrentes FE A Fase de leitura Obtém t 0 Fase de escrita de valor v A Calcula Envia t A =<seq 0 +1,A> write(v A,t A ) <v r1 0,t 0 > <v r2 0,t 0 > r3 <v 0,t 0 > <v B,t B > <v B,t B > <v A,t A > r1 r2 r3 FE B Fase de leitura Obtém t 0 Calcula t B =<seq 0 +1,B> Envia write(v B,t B ) Fase de escrita de valor v B Page 25 25

26 Exemplo 2: escritas concorrentes Caso FE A e FE B tentem escrever partindo da mesma tag inicial: Depois da escrita de FE A chegar a Q réplicas, outros FE poderão ler val A No entanto, assim que escrita de FE B chegar a Q réplicas, todas as leituras devolverão val B Seq. consistente? Exemplo 3: ler durante escrita incompleta FE calcula t 1 = <seq 0 +1, pid> Lê v 1 Lê v 0 Lê v 1 FER FE w r1 r2 r3 x r1 r2 r3 Fase de Leitura Lê <v 0,t 0 > Fase de Escrita Escreve <v 1,t 1 > Oper. de Escrita do valor v 1 Seq. consistente? Page 26 26

27 Protocolo Quorum Consensus: variante ABD Leituras(agora, com writeback) Frontend: Enviaread() para todosos gestores de réplica No-máximo-1-vez Aguarda por Q respostas SejamaxValo valor que recebeucom maiortag (maxtag) Enviawrite(maxVal,maxTag) a todososgestoresde replica EsperaporQ acks Retorna maxval writeback Gestor de réplica i: Ao receber read(), responde com <val i,tag i > Caso o valor mais recente sejade escritaquenãochegou ainda a Q réplicas, assegura queessaescritachegaa Q Exemplo 3: ler durante escrita incompleta (agora com writeback) FE calcula t 1 = <seq 0 +1, pid> Write Lê v 1 back Lê v 1 Lê v 1 FER FE w r1 r2 r3 x r1 r2 r3 Fase de Leitura Lê <v 0,t 0 > Fase de Escrita Escreve <v 1,t 1 > Oper. de Escrita do valor v 1 Seq. consistente? 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