Replicação de servidores

(1)

Replicação de servidores

Arquiteturas Tolerantes a faltas em Sistemas

Distribuídos

2013 Sistemas Distribuídos

Departamento de Engenharia Informática

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…

(2)

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+1 réplicas tolerassem f nós com falhas bizantinas

• No entanto, veremos que a realidade é mais

(3)

Protocolos de Replicação

Sistemas Distribuídos

Politica de replicação

• Replicação passiva

• Replicação activa

Tipo de servidor

replicado

• Replicação de

máquinas de estados

• Replicação de dados

com apenas

operações de

Leitura/Escrita

(registos)

2013

Replicação Passiva vs. Activa

Sistemas Distribuídos

Replicação Passiva (“primary-backup”)

• Os clientes interatuam com um servidor principal. Os restantes servidores estão de reserva (backups), quando detetam que o servidor primá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 correto por votação, e respondem ao cliente.

• Política de Compensação da falta

(4)

Replicação Passiva

Replicação passiva: arquitectura

FE C FE C RM Primary Backup Backup RM RM

Nós só exibem falhas de paragem silenciosa (crash)

Serviço de

(5)

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

(6)

Protocolo Simples de Replicação Passiva

2013 Sistemas Distribuídos P P₂ P₁ t max 4 3 1 2 c Mensagens de Prova de vida

Em que instante P2pode assumir que é o primário?

1 – Mensagem do cliente 2 – Mensagem de update do secundário 3 – Resposta ao cliente

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

O que pode acontecer se falharem estes pressupostos?

(7)

Cenários de Falha do primário (I)

2013 Sistemas Distribuídos C P S1/P New S₂ O S2tem de ser colocado em funcionamento com a base de dados consistente a partir de S1 1 1 2 3

Cenários de Falha do primário (II)

2013 Sistemas Distribuídos C P Necessário que o Cliente reenvie o pedido com semântica at-most-once e receberá a resposta do secundário que foi actualizado correctamente S1/P New S₂ 1 1 2 3 2

(8)

Cenários de Falha do primário (II)

2013 Sistemas Distribuídos C P S1/P New S₂ O sistema ficou consistente O new S tem de ser colocado em funcionamento com a base de dados consistente a partir de S1 1 2 3

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

(9)

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

Sistemas Distribuídos 2013

(10)

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

at-most-once

(11)

Replicação Activa

2013 Sistemas Distribuídos FE C FE C RM RM 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?

(12)

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

(13)

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

(14)

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

(15)

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

• Mesmo quando não há falhas, o que pode

correr mal?

Réplica pode levar FE a retornar leitura inconsistente!

Se houver múltiplos pedidos de escrita concorrentes, réplicas podem ficar inconsistentes e leituras posteriores retornarem valores diferentes!

(16)

Protocolo write-all-avaliable

Uma solução hipotética:

Protocolo Quorum Consensus

(17)

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

(18)

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-val se 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)

Fase de Leitura Lê <v0,t0>

x

Fase de Escrita

Escreve <v₁,t₁, > Oper. de Leitura Lê <v₁,t₁> c

r1 r2 r3

Oper. de Escrita do valor v₁

r1 r2 r3 c calcula t1=

(19)

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

(20)

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

(21)

Como ir além do modelo de operações

leitura/escrita sobre um registo?

Quorum Consensus

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

(22)

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

(23)

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!

(24)

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