Arquiteturas Tolerantes a faltas em Sistemas Distribuídos Replicação de servidores Replicação: que benefícios nos dá? 1) Melhor desempenho e escalabilidade Replicar serviços permite que algumas operações sejam feitas apenas sobre parte dos nós Dessa forma distribui-se carga, pois os outros nós ficam livres para servir mais clientes Permite também que cliente contacte os nós mais próximos de si, obtendo uma resposta mais rápida Muito fácil quando dados são imutáveis Muito mais difícil quando dados podem mudar ao longo do tempo Page 1
Replicação: que benefícios nos dá? 2) Melhor disponibilidade O sistema mantém-se disponível mesmo quando: Alguns nós falham A rede falha, tornando alguns nós indisponíveis Ao mesmo tempo, gostaríamos que o sistema se comportasse de uma forma equivalente a um sistema não replicado Só dessa forma conseguimos transparência de replicação Precisamos de protocolos de replicação para garantir consistência entre as réplicas 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 No entanto, veremos que a realidade é mais complicada e normalmente precisamos de mais réplicas Page 2
Protocolos de Replicação Politica de replicação Replicação passiva Replicação activa Tipo de servidor replicado Replicaçãode máquinas de estados Replicação de dados com apenas operaçõesde Leitura/Escrita (registos) 2013 Sistemas Distribuídos 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 2013 Sistemas Distribuídos Page 3
Replicação Passiva Replicação passiva: arquitectura C Serviço de Nomes FE Primary RM RM Backup C FE RM Backup Nós só exibem falhas de paragem silenciosa (crash) Page 4
Protocolo Simples Replicação Passiva (Replicação Máquina de Estados) Quando P1 recebe um pedido: Processa-o e actualiza o seu estado interno Envia uma mensagem de update a P2 Responde ao cliente, sem esperar pela resposta de P2 P2 actualiza o seu estado quando recebe a mensagem de update de P1 P1: servidor primário P2: servidor secundário Protocolo Simples Replicação Passiva (Replicação Máquina de Estados) P1 envia a P2 mensagens I m alive cada P unidades de tempo Se P2 não receber uma mensagem I m alive após expirar um temporizador, torna-se o primário: Avisa os clientes e/ou oregisto de nomes Começa a processar os pedidos P1: servidor primário P2: servidor secundário Page 5
c Protocolo Simples de Replicação Passiva 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: Pode definir-se um limite para o tempo máximo de transmissão de uma mensagem na rede (tmax) e para o respectivo processamento; A rede assegura uma ordem FIFO na comunicação Relógios das máquinas estão sincronizados (ou, pelo menos, as respectivas velocidades) Nós só têm faltas por paragem silenciosa (crash) A semântica de invocação dos RPC é no máximo uma vez Page 6
Cenários de Falha do primário (I) C P S 1 /P 1 1 2 3 O S 2 tem de ser colocado em funcionamento com a base de dados consistente a partir de S 1 New S 2 Cenários de Falha do primário (II) C P S 1 /P 1 1 2 New S 2 2 3 Necessário que o Cliente reenvie o pedido com semântica atmost-oncee receberá a resposta do secundário que foi actualizado correctamente Page 7
Cenários de Falha do primário (II) C P S 1 /P 1 3 2 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 Semântica da invocação do cliente No protocolo anterior assume-se que o cliente executa um protocolo at-most-once ou seja reenvia o pedido quando não tem resposta Contudo, para que funcione correctamente é necessário que o FE do cliente: execute o protocolo para descobrir o novo primário reenvie o pedido se não fizer o estado evoluiu no secundário mas o cliente considera que o serviço não foi executado Page 8
Custos da Replicação Passiva Objectivo: assumindo que f componentes podem falhar, minimizar o grau de replicação, tempo de resposta e tempo de recuperaçã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é cliente ser notificado do novo primário Protocolo Simples de Replicação Passiva 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) situação mínima em que o secundário avisa o cliente Com um servidor de nomes é evidentemente mais demorado 2013 Sistemas Distribuídos Page 9
Cliente O FE do cliente tem de ser modificado para encontrar o novo primário quando não obtém resposta Solução mais simples é fazê-lo através de um servidor de nomes. Quando serviço fica indisponível pergunta novamente ao servidor de nomes Mas o tempo de indisponibilidade aumenta Tem de garantir a semântica de execução atmost-once Replicação Activa Page 10
Replicação Activa RM C FE RM FE C RM Protocolos de replicação activa 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 às réplicas Cada réplica 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? Page 11
Tentemos construir um bom protocolo de replicação activa Modelo de faltas que assumiremos Sistema assíncrono Mensagens não se perdem mas podem chegar arbitrariamente atrasadas Não há garantia de recepção FIFO Réplicas podem falhar silenciosamente Page 12
Para já, assumiremos a seguinte especificação do sistema replicado 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); Para já, assumiremos a seguinte especificação do sistema replicado Comportamento esperado do sistema: Caso a leitura se execute quando não existe nenhuma escrita em execução: Leitura retorna o valor escrito pela última escrita Caso tenham ocorrido escritas concorrentes, o sistema define uma ordem total entre elas Caso a leitura se execute quando existem escritas em curso: Leitura retorna o valor de uma das escritas em curso ou o valor da última escrita completada Page 13
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 14
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 15
Uma solução hipotética: Protocolo write-all-avaliable Uma melhor solução: Protocolo Quorum Consensus Page 16
Protocolo Quorum Consensus Sistema de Quóruns: conjunto de sub-conjuntos das réplicas, tal que quaisquer dois sub-conjuntos se intersectam. Por exemplo: N réplicas Quórum: qualquer maioria: Q >N/2 Cada réplica guarda: valor do objecto (registo) respectivo timestamp Protocolo Quorum Consensus Operação de Leitura Envia pedido de leitura para todas as réplicas (retransmitindo-o até concluir a operação, para colmatar falhas temporárias na rede) 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 17
Protocolo Quorum Consensus Operação de Escrita (2 fases leitura e escrita) Efectua pedido de leitura a todas as réplicas (ler timestamp actual) Aguarda resposta de um quórum Escolha o maior timestamp, t, e incrementa Efectua um um novo pedido a todas as réplicas para escrever <novo-val, t+1> (Servidores respondem ack, e apenas guardam novo-valse o timestamp for maior do que o actual) Cliente aguarda acknowledge de um quórum Problema: Duas escritas concorrentes podem escolher o mesmo timestamp Solução: timestamp = <Nº seq., client-id> Exemplo (Quorum Consensus) 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 Page 18
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 19
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 20
Quorum Consensus Como ir além do modelo de operações leitura/escrita sobre um registo? Como ir além do modelo de operações leitura/escrita sobre um registo? O modelo assumido até agora é limitativo: Não permite operações complexas cuja execução envolva sequência de múltiplas leituras e escritas a diferentes registos Por outras palavras, não temos o modelo da máquina de estados replicada Esta limitação pode ser ultrapassada incorporando transacções distribuídas Page 21
Como ir além do modelo de operações leitura/escrita sobre um registo? Cada réplica passa a manter múltiplos registos Cada registo com o seu timestamp próprio Operações complexas vistas como transacções distribuídas No início, uma transacção distribuída é iniciada Cada leitura/escrita a um registo segue o protocolo definido atrás Única diferença: pedido leva também o identificador da transacção distribuída Cada réplica que execute o pedido passa a ser participante da transacção distribuída Depois de todas as leituras/escritas da operação complexa terem retornado, executa-se um protocolo de confirmação atómica (2PC ou outro) Tolerância a falhas bizantinas com quóruns Page 22
O que muda se réplicas passam a poder falhar de forma bizantina? Réplica bizantina pode dar resposta errada Por exemplo, réplica tem <valor=5, ts=1> e responde <valor=5, ts=8>, fazendo com que a sua resposta desactualizada seja aceite pelo cliente Réplica bizantina pode responder em nome de outra réplica Por exemplo, réplica envia resposta <valor=5, ts=1> em nome de várias outras réplicas, levando o cliente pensar que recebeu respostas de um quórum Entre outros comportamentos Como estender o Quorum Consensus para tolerar falhas bizantinas? Exigir que cada réplica assine as suas mensagens Neste caso, as mensagens são auto-verificáveis ou seja, se mensagem for gerada/modificada por outros nós, o receptor consegue descobrir e descartar a mensagem a capacidade de uma réplica bizantina provocar erros limita-se as suas próprias acções, não pode actuar por outros consegue-se por assinatura digital veremos mais à frente o que significa Mas apenas isto não é suficiente! Page 23
Como estender o Quorum Consensus para tolerar falhas bizantinas? (II) Na leitura, só se pode retornar valor que tenha sido retornado por pelo menos f+1 réplicas Porquê? É necessário esperar por mais respostas Na escrita, esperar por suficientes ack que permitam certeza de que a escrita chegou a pelo menos WT réplicas correctas, mesmo que f bizantinas tenham enviado ack Na leitura, esperar por respostas suficientes que garantam que, entre elas, há pelo menos RT respostas de réplicas correctas, mesmo que f bizantinas tenham respondido também Como estender o Quorum Consensus para tolerar falhas bizantinas? (III) Existem várias soluções concretas baseadas no quorum consensus que toleram falhas bizantinas Não as estudaremos em SD Também existem outras soluções baseadas noutros protocolos de replicação Page 24