Você está na página 1de 145

Sistemas Distribuídos

Tolerancia a Falhas
Prof Lahoz
Apoio: Prof. André Y. Kusumoto
Profa Ana Paula Couto (DCC/UFJF) http://www.fisiocomp.ufjf.br/anapaula/
SD/cursoSD.html
Tolerância à Falhas
•  Um objetivo importante de um projeto de SD é construir de tal modo que
ele possa se recuperar automaticamente de falhas parciais sem afetar
seriamente o desempenho global.

•  Sempre que houver falhas, o sistema distribuído deve continuar a


funcionar de maneira aceitável enquanto o sistema estiver sendo
recuperado.

•  Isto é, o SD deve tolerar falhas e continuar a funcionar, mesmo na


presença de falhas.
Tolerância à Falhas
Conceitos Básicos
Precisamos entender o que tolerar falhas realmente significa
Sistema tolerante a falhas x Sistemas confiáveis
Confiabilidade é um dos requisitos úteis para SD (Kopetz e Veríssimo,
1993).

Disponibilidade
•  Propriedade de um sistema estar pronto para ser usado
imediatamente. Um sistema de alta disponibilidade é aquele que
mais provavelmente estará funcionando em dado instante de
tempo.
Tolerância à Falhas
Conceitos Básicos

Confiabilidade
•  Propriedade de um sistema poder funcionar continuamente sem
falha. Um sistema de alta confiabilidade é aquele que mais
provavelmente continuará a funcionar sem interrupção durante um
período de tempo relativamente longo.
•  Um sistema que fica fora do ar por um milissegundo a cada hora –
alta disponibilidade (99,9999%), porém baixa confiabilidade.
•  Um sistema que nunca cai, mas é desligado por duas semanas,
todo mês de agosto – alta confiabilidade, porém baixa
disponibilidade (96%).
Tolerância a Falha
Conceitos Básicos

Segurança
•  Refere-se à situação em que, se um sistema deixar de funcionar
corretamente durante um certo tempo, nada de catastrófico
acontecerá.
•  Capacidade do sistema continuar funcionando mesmo na presença
de perigos (naturais do ambiente ou devido a intervenção humana.
•  Sistemas de controle de usinas de energia nuclear devem ter alto
grau de segurança. Se falharem temporariamente, mesmo que por
apenas um breve instante, os efeitos podem ser desastrosos.
Tolerância a Falha
Conceitos Básicos

Capacidade de Manutenção
•  Facilidade com que um sistema que falhou pode ser consertado e
mantido.
•  Arquitetura e Modularização.
•  Documentação.

•  Um sistema com alta capacidade de manutenção também pode


mostrar alto grau de disponibilidade.
Terminologia: falta, erro, falha

•  Estado de falha (failure) é alcançado quando o sistema executou


suas funções de forma incorreta.

•  As origens elementares deste estado de falha (failure) é


denominada falta (fault), que representa uma imperfeição dentro
de um determinado componente, que pode ser de hardware ou
software.
Terminologia: falta, erro, falha

A manifestação dessa falta (fault) se reflete na contaminação da


informação interna do sistema, sendo caracterizada como um erro
(error).

A manifestação de um erro (error) para o ambiente externo representa


um estado de falha (failure), que pode ser seguro (safe) ou inseguro
(unsafe).
Terminologia: falta, erro, falha

FALTA Causa Leva a FALHA Pode Perigo


ERRO
induzir ou
acidente

Causa erro Detectado por Desvio do estado


quando ativada mensagem ou correto do sistema
sinal (mal funcionamento)
Terminologia: Falta

FALTA (fault): a causa de um erro é uma falta. Uma falta pode


existir muito antes de produzir efeitos - falta inativa ou dormente.
Quando de algum modo é ativada, a falta cria um erro latente que é
efetivo quando ativado; quando o erro afeta o serviço fornecido,
ocorre uma falha.

Falta inativa ou dormente -> falta não ativada


Falta ativa -> falta que produz erro
Terminologia: Falta
FALTA (fault)
Exemplos

• Bug de software.
• Falha aleatóra de hardware.
• Problema de memória.
• Omissão ou comissão na transferência de dados.
Terminologia: erro
ERRO (error): é um problema desenho (design) ou desvio de um
estado pretendido ou desejado.

Uma falha é definida como um evento (comportamento) enquanto


um erro é uma condição estática (um estado).

A falha ocorre em um instante particular no tempo, um erro


mantem-se até ser removido, geralmente através de algum tipo de
intervenção humana.
Uma falta leva a um erro, tornando-se então a falta aparente.
Terminologia: falha

FALHA (failure): problemas de desempenho ou inabilidade do


sistema ou do componente de realizar sua função pretendida por um
tempo especifico sob condições ambientais especificas.

A falha do sistema ocorre quando o serviço fornecido se desvia das


condições mencionadas na especificação do serviço (descrição
combinada do serviço esperado).

A falha ocorre porque o sistema apresentou um erro que conduziu a


um não fornecimento de serviço ou função pretendida.
Terminologia: falha

FALHA (failure)
Taxa de falhas: Indicador mais comum de confiabilidade. Número de
vezes em que uma falha é esperada acontecer num dado período.
Taxa de falha de 1 x 10 -4 por hora de vôo (esperada a ocorrência de
uma falha a cada 10.000 horas). Uma falha de um dispositivo fisico
pode ser causado por dois tipos de falhas:
desvio de projeto: o projeto ou a construção não satisfez os
requisitos.
desvio de operação: a operação não seguiu o projeto original
(disturbios ambientais, procedimentos, desgaste, degradação).
Terminologia: exemplo
Pense num jogador de futebol, o Ronaldo fenomeno, por exemplo, a
especificação deste jogador é fazer gol, portanto, se ele deixa de
fazer o gol ele falha na sua especificação.

Imagine o Ronaldo indo em direção ao gol adversário e surja um


zagueiro que comete uma falta nele, essa falta vai fazer com que o
Ronaldinho cometa um erro em sua trajetória em direção ao gol e,
como conseqüência, falhe no seu objetivo (sua especificação) em
fazer o gol.
Neste exemplo, o Ronaldo é o sistema, se for robusto o suficiente
ele é capaz de tolerar faltas dos zagueiros adversários e fazer o gol.
http://www.inf.ufsc.br/~lau.lung/por-que-tolerancia-a-faltas.html
Terminologia: Acidente

ACIDENTE (accident):
Evento indesejado ou não planejado (não necessariamente
inesperado) que resulta em (no minimo) um nivel de perda
especifico.

Não planejado ou indesejado não significa necessariamente que


não possa ser evitado (excluindo, por exemplo, eventos causados
por sabotagem).
Niveis de perda especifico implica em algum tipo de dano a vida, a
bens materiais, propriedade ou ambiente.
Terminologia: Incidente

INCIDENTE (incident):
Evento que não envolve perda (perda menor ou quase perda), mas
com um potencial para uma perda em diferentes circunstancias.

Por exemplo, uma emissão de substancia tóxica que foi dissipada


no ar sem causar dano é um incidente.

Poderia causar um acidente, sob dadas circunstancias, no caso de


pessoas estando nas proximidades ou sob diferentes condições
climáticas ou de vento.
Terminologia: Perigo

PERIGO (hazard):
Estado ou conjunto de condições de um sistema (ou objeto) que,
junto com outras condições do ambiente deste sistema leve
inevitavelmente a um acidente (evento de perda).

Perigo depende onde estão delineados os limites do sistema.

A probabilidade de ocorrência do perigo pode ser quantitativa


(quando existe dados históricos) ou qualitativa (avaliação de
especialistas).
Terminologia: Perigo

PERIGO (hazard):

A condição de perigo está latente, mas transforma-se num


acidente quando os componentes de estado de perigo inativos são
ativados. É necessário identificar e compreender os componentes
de perigo para determinar o risco envolvido e então eliminar ou
mitigar o perigo.

Possui duas importantes características:

(1)  Severidade
(2)  Probabilidade de ocorrencia
Terminologia: Perigo

PERIGO (hazard): Características

(1)  Severidade: definida como o pior acidente possivel que pode


resultar do perigo, dado um ambiente no seu estado mais
desfavorável.

(2)  Probabilidade de ocorrencia: pode ser especificado


qualitativamente ou quantitativamente. Quando o sistema é
projetado e os perigos são avaliados para priorização, dados
quantitativos quase nunca estão disponiveis. Somente alguns
dados históricos podem ser utilizados, sendo a qualitativa o melhor
a ser feito para avaliação dos perigos restantes.
Terminologia: Risco

RISCO (risk):

O risco caracteriza a incerteza e a ameaça apresentada por um


perigo.

O risco pode ser alterado quando os fatores que compõem um


risco são modificados (por meios de melhoria de projeto).

Risco pode ser considerado como a probabilidade de ocorrência


de um determinado perigo combinado com a magnitude de sua
provável consequência.
Terminologia: Risco
risco
RISCO (risk):


transição acidente
perigo




Risco é uma métrica da probabilidade e consequência de um potencial
futuro evento.
Quando existe perigo, sempre existe risco associado. Perigos e seus
componentes devem ser identificados antes de avaliar o risco. Risco
pode ser eliminado, reduzido ou aumentado através das medidas de
segurança em projeto.
Tolerância a Falha

A construção de sistemas confiáveis está intimamente relacionada com o


controle de falhas.

Para nossa finalidade, a questão mais importante é a tolerância à falhas.


•  Um sistema pode prover seus serviços mesmo na presença de falhas.
Terminologia: Falta
Métodos para lidar com a falta (usualmente tratado coomo falha):
Prevenção de falhas: como prevenir (ex, por construção) a
introdução ou a ocorrencia de faltas;
Tolerancia a falhas: como prover (ex, por redundancia) o
fornecimento do serviço conforme a especificação do mesmo
perante a ocorrencia de faltas;
Supressão de falhas: como minimizar (ex, por verificação) a
presença de faltas;
Previsão de falhas: como estimar( ex, por avaliação) a presença, a
criação e a consequencia das faltas.
Tolerância à Falhas
Tipos de Falhas
•  Falha Transiente (passageiro, transitório)
•  Ocorre uma vez e depois desaparece.
•  Se a operação for repetida, a falha não acontecerá novamente.
•  Ex.: um pássaro voando pelo feixe de um transmissor de mircroondas,
causando perda de bits em alguma rede.
•  Falha Intermitente
•  Ocorre e desaparece por “sua própria vontade”.
•  Ex.: conector com problemas.
•  Difícil de diagnosticar.
•  Falha Permanente
•  Continua a existir até que o componente faltoso seja substituído.
•  Ex.: bugs de software, chips queimados.
Classificação da Falha
•  Um sistema que falha não está fornecendo adequadamente os serviços
para os quais foi projetado.

•  Em SDs pode significar problemas nos servidores, hosts, canais de


comunicação ou possivelmente ambos.
•  A falha pode também estar relacionada com o fornecimento de serviço de
um outro SD, que se propaga até o servidor que está sob análise.

•  Um disco que está falhando pode dificultar a vida de um servidor de


arquivos que foi projetado para implementar um sistema de arquivos de
alta disponibilidade em um SD, podendo por em risco todo o sistema.
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha por queda: servidor para prematuramente apesar de estar


funcionando corretamente.
Aspecto principal: uma vez que o servidor para, nada mais se “ouve”
dele.

Ex.:
•  SO pára e é necessário reinicializá-lo.
•  Curiosidade: falha tão frequente em computadores, que o botão de reset
foi transferido da parte traseira da máquina para dianteira do gabinete.
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha por omissão: servidor deixa de responder a uma requisição.


Possibilidades: (1) servidor nunca recebeu a requisição. (2) servidor
deixa de enviar a resposta.
Ex.:
•  Conexão C-S estabelecida, mas não havia nenhuma thread ouvindo as
requisições.
•  Buffer de envio transborda, erros de software (laços infinitos, problemas
de gerenciamento da memória - servidor “pendurado”).
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha de temporização: resposta se encontra fora de um intervalo de


tempo real especificado.

Ex.:
•  Fornecer dados muito cedo pode facilmente causar problemas para um
receptor se não houver espaço no buffer suficiente para conter todos os
dados que chegam.
•  Servidor responde tarde demais – falha de “desempenho”.
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha de resposta: resposta do servidor é incorreta.


Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha de transição de estado: servidor reage inesperadamente a uma


requisição que chega.

Ex.:
•  Servidor recebe uma msg que não pode reconhecer, acontece uma falha
de transição de estado, se não for tomada nenhuma providência para
manipular tal mensagem
•  Servidor faltoso pode executar incorretamente ações que nunca deveria
ter iniciado.
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)

Falha arbitrária (bizantina): servidor produz respostas arbitrárias em


momentos arbitrários..

Ex.:
•  Servidor produzindo saidas que nunca deveria ter produzido, mas que
não podem ser detectadas como incorretas.
•  Servidor faltoso trabalahndo maliciosamente em conjunto com outros
servidores para produzir respostas erradas intencionalmente.
Classificação da Falha
•  Modelo de classificação de falhas de Cristian (1991) & Hadzilacos e
Toueg (1993)
Mascaramento de Falha por Redundância
•  O melhor que se pode fazer é tentar ocultar de outros processos a
ocorrência de falhas.
•  A técnica fundamental para mascarar falhas é usar redundância.

Técnicas de Redundância:
•  Redundância de informação
•  Redundância de Tempo
•  Redundância de Software
•  Redundância de Hardware
Mascaramento de Falha por Redundância
Redundância de informação
•  São adicionados bits extras para permitir recuperação de bits
deteriorados.
Exs.:
•  Paridade
•  Checksums
•  Duplicação de código
•  Códigos cíclicos
•  Códigos de correção de erros
Mascaramento de Falha por Redundância
Redundância de informação
Paridade: adicionar bit(s) para manter a palavra de código com um número
par ou ímpar de 1s.
Principal uso: detecção de erros no armazenamento de memória.
Abordagens:
•  Paridade por palavra
•  Paridade por byte
•  Paridade por chip
•  Paridade por múltiplos chips
•  Paridade entrelaçada
•  Paridade transpassada (overlapping)
Mascaramento de Falha por Redundância
Redundância de informação
Paridade por palavra
•  Permite apenas detecção de erros simples
•  Não permite detecção de muitos erros múltiplos
•  Forma um código separável
Mascaramento de Falha por Redundância
Redundância de informação
Paridade transpassada
•  Cada bit aparece em mais de um grupo de paridade
•  Erros podem ser detectados, localizados e corrigidos por
complementação simples, se desejado
•  Conceito básico dos código de correção de erros de Hamming
Mascaramento de Falha por Redundância
Redundância de informação
Checksums
Adiciona informação a um bloco de informação para possibilitar detecção de
erros. Tipos:
•  Precisão simples
•  Precisão dupla
•  Honeywell
•  Checksum residual
Mascaramento de Falha por Redundância
Redundância de informação
Checksum Precisão simples
•  Realiza somatório do código e ignora bits que extrapolam tamanho da
palavra (n).
•  Usa módulo n.

Checksum Precisão dupla


•  Realiza somatório e utiliza uma palavra de precisão dupla para
armazenar resultado.
•  Ignora bits que extrapolam tamanho da palavra dupla.
•  Usa módulo 2n.
Mascaramento de Falha por Redundância
Redundância de informação
Duplicação de código
100% de redundância da informação, logo caro
Exemplos:
• Retransmitir dado e comparar os dois recebidos
• Escrever em duas posições da memória
Mascaramento de Falha por Redundância
Redundância de tempo
•  Uma ação é realizada e, então, se for preciso, ela é executada
novamente.
Ex:
•  Transações - caso tenham sido abortadas, podem ser refeitas (falhas não
transientes ou intermitentes).
Mascaramento de Falha por Redundância
Redundância de tempo
•  Uma dada função é executada múltiplas vezes, com as mesmas
entradas.
•  Eventuais diferenças nas saídas indicam erros causados por defeitos
físicos transientes (ou por ruído).
•  Garantindo tempo para as duas execuções da tarefa em todas as
respectivas ativações (inclusive no pior caso), pode-se conseguir uma
taxa de detecção de erros acima de 99,9%.
Mascaramento de Falha por Redundância
Redundância de software
•  Replica componentes de software.
•  Linhas extras de código usadas para verificar a magnitude de sinais.
•  Pequenas rotinas utilizadas para, periodicamente, testar a memória.
•  Componentes de software.
Principais técnicas:
•  Verificação de consistência
•  Verificação de capacidade
•  Métodos de replicação de software (software TF)
•  Programação N-auto-verificável
•  Programação N-versão
•  Blocos de recuperação
Mascaramento de Falha por Redundância
Redundância de software
Verificação de consistência
•  Usa conhecimento prévio sobre características da informação para
verificar a corretude da informação.

Exemplos:
•  Verificação de excesso do limite (magnitude do valor ou intervalo da
medida)
•  Verificação de endereço é válido
•  Verificação de códigos de instrução
•  Verificação de derivações excessivas em relação ao previsto (padrão de
comportamento pré-estabelecido)
Mascaramento de Falha por Redundância
Redundância de software
Verificação de capacidade
•  Usa conhecimento prévio sobre características do sistema

Exemplo:
•  Verificação se há memória suficiente
•  Verificação se todos processadores estão funcionando/acessíveis
•  Se unidades funcionais estão funcionando
Mascaramento de Falha por Redundância
Redundância de software
Programação N-versão
Criada para tolerar falhas de projeto.
Conceito básico: projetar e codificar o software N vezes e votar o resultado.
Cada módulo deve ser desenvolvido por equipe independente.
A técnica pode tolerar (N- 1)/2 falhas.

Dificuldades:
•  Desenvolvedores costumam ter as mesmas práticas de programação,
não garantindo a independência das versões
•  Como especificação é a mesma, a técnica não tolera erros na
especificação.
Mascaramento de Falha por Redundância
Redundância de software
Blocos de Recuperação
•  Análoga a redundância de HW ativa (cold standby sparing).
•  N versões, mas com um único teste de aceitação.
•  Uma versão é a primária e outras são secundárias.
•  Assumindo cobertura perfeita e falhas independentes, a técnica suporta
N-1 falhas.
Mascaramento de Falha por Redundância
Redundância física
•  São adicionados equipamentos ou processos extras para que o sistema
tolere a perda ou o mau funcionamento de alguns componentes.
Ex:
•  Servidores, RAID.
•  Processos adicionais podem ser adicionados ao supervisor de modo que
tolere perdas de partes.
Mascaramento de Falha por Redundância
Redundância física
Passiva ou estática: visa mascaramento de falhas usando módulos
adicionais.

Ativa ou dinâmica: para obter redução de custo, baseia- se em detecção/


localização, seguida de remoção e de reconfiguração/recuperação de
falhas

Híbrida: visa o mascaramento de falhas, mas para obter melhor


dependabilidade usa mecanismos de detecção, localização e
recuperação de falhas. Removem falhas de hardware trocando
componentes defeituosos por reposições. Mais eficiente mas cara e
geralmente utilizada em aplicações críticas.
Mascaramento de Falha por Redundância
Redundância física
Passiva ou estática
Objetivo: mascarar falhas
•  Não requer operação do sistema ou operador.
•  Não detecta, simplesmente mascara falhas.
•  Costuma utilizar conceito de votação por maioria.
•  Técnica mais comum: Redundância Modular Tripla (TMR).
Mascaramento de Falha por Redundância
Redundância física
Passiva ou estática
Redundância Modular Tripla (TMR):
Conceito básico: obtenção de mascaramento por triplicação do HW.
(processador, memória ou qualquer unidade de HW) e votação da saída.
Mascaramento de Falha por Redundância
Redundância física
Passiva ou estática
•  Redundância Modular Tripla (TMR).
•  Ponto crítico: votador (chamado single-point-of-failure – SPoF).
•  Confiabilidade (R(t)) nunca é melhor do que a confiabilidade do votador.
•  Generalização do TMR é o NMR (N- modular redundance).
•  N normalmente é um número ímpar para permitir votação por maioria.
•  Limitadores: custo, potência consumida, espaço, etc.
Mascaramento de Falha por Redundância
Redundância física
Ativa
Conceito básico: replicação de módulos, com apenas um ativo (operando).
•  Ponto crítico: detectar que módulo ativo falhou.
•  Funcionamento: detecta a presença de falhas e resolve alguma ação
para eliminá-las
•  Requer reconfiguração para
tolerar falhas
•  Requer componentes standby
Mascaramento de Falha por Redundância
Redundância física
Ativa
Tipos de espera (standby)

•  Cold standby: esperas desligados, ativação do zero. Não causa overhead


durante operação.
•  Warm standby: espera desligados, ativação do último ponto de
verificação (checkpoint).
•  Hot standby: esperas ligados, ativação do estado atual. Também
chamado sistema duplex.
Mascaramento de Falha por Redundância
Redundância física
Redundância híbrida
•  Realiza mascaramento de falhas.
•  Usa técnicas de detecção, localização e recuperação de falhas para
melhorar a tolerância a falhas.
•  Remove falhas de hardware trocando componentes defeituosos por
spares.
•  É mais eficiente mas de alto custo.
•  É a técnica mais utilizada em aplicações críticas.
Como o sistema se recupera de uma falha
Como o sistema se recupera de uma falha

•  Resiliência de Processo (questões de projeto, mascaramento de falha e


replicação, acordo em sistemas com falha, detecção de falhas)

•  Comunicação confiável Cliente-Servidor (comunicação ponto a ponto,


RPC na presença de falhas)

•  Comunicação confiável do Grupo (esquema básico, escalabilidade em


multicast confiável, realimentação não hierárquico, hierárquico, multicast
atômico)

•  Recuperação
Como o sistema se recupera de uma falha
Resiliência de Processo
Projeto: Grupos de Processos

• A abordagem principal para tolerar um processo faltoso é organizar vários


processos idênticos em um grupo.
• Propriedade fundamental de um grupo de processos – quando uma
mensagem é enviada para o grupo, todos os membros do grupo a recebem.
• Desse modo, se um processo do grupo falhar, espera-se que algum outro
processo se encarregue da mensagem e seu lugar.
• Em outras palavras, podemos replicar processos e organizá-los para
substituir um único processo (vulnerável) por um grupo (tolerante a falha).
Como o sistema se recupera de uma falha
Resiliência de Processo
Projeto: Grupos de Processos

Exemplo
• Um processo pode enviar uma mensagem a um grupo de servidores sem
precisar saber quem eles são ou quantos existem.
Como o sistema se recupera de uma falha
Resiliência de Processo
Projeto: Grupos Simples versus Grupos Hierárquicos

Grupo Simples
• Todos os processos são iguais.
• Ninguém manda e as decisões são tomadas coletivamente.
• Vantagens
•  Simétrico – processos iguais.
•  Não tem ponto de falha único.
•  Mesmo que um processo caia, o grupo continua a oferecer o serviço.
• Desvantagem
•  Tomada de decisão pode ser complicada – muitas vezes é preciso
realizar uma votação, o que gera um atraso.
Como o sistema se recupera de uma falha
Resiliência de Processo
Projeto: Grupos Simples versus Grupos Hierárquicos

Grupo Hierárquicos
• Um processo é o coordenador e os demais são operários.
• A requisição sempre é enviada ao coordenador.
• O coordenador decide.
• Vantagens
•  O coordenador toma as decisões sozinho, sem a necessidade de
consultar os outros processos.
• Desvantagem
•  Existe um ponto de falha único.
•  Caso o coordenador falhe, um novo coordenador deverá ser eleito.
Como o sistema se recupera de uma falha
Resiliência de Processo
Projeto: Grupos Simples versus Grupos Hierárquicos
Como o sistema se recupera de uma falha
Resiliência de Processo
Mascaramento de falha e replicação

Uma questão importante quando se usam grupos de processos para tolerar


falhas é quanta replicação é necessária.

Diz-se que um sistema é k-tolerante a falha (k-fault tolerant) se puder


sobreviver a falhas em k componentes e ainda assim cumprir suas
especificações.
Como o sistema se recupera de uma falha
Resiliência de Processo
Mascaramento de falha e replicação

Problema: quão grande k precisa ser?

(1)Falhas “silenciosas” → Se k processos pararem sem propagar


informações erradas, basta ter k+1 processos.

(2) Se os processos exibirem falhas e continuarem a enviar respostas erradas


as requisições, é preciso um mínimo de 2k+1 processadores para conseguir
k-tolerância.
Como o sistema se recupera de uma falha
Resiliência de Processo
Acordo em sistemas com falha

Em muitos casos, um grupo de processos deve chegar ao acordo: eleger um


coordenador, decidir a validação de uma transação, repartir tarefas entre
operários e sincronização

Problema: Casos em que os processos não podem ser considerados


perfeitos
Como o sistema se recupera de uma falha
Resiliência de Processo
Acordo em sistemas com falha

Casos – Turek e Sasah (1992):


1. Sistemas síncronos (funcionam no mesmo passo) versus assíncronos.
2. Atraso de comunicação limitado (mensagem entregue dentro do tempo
máximo global e pré-determinado) ou não.
3. Entrega da mensagem é ordenada ou não.
4. Transmissão unicast ou multicast.
Como o sistema se recupera de uma falha
Resiliência de Processo
Acordo em sistemas com falha

Objetivo: Todos os processos que não apresentam falhas devem chegar a


um consenso sobre alguma questão, dentro de um número finito de etapas.

Lamport et al (1982) – Problema do acordo bizantino


Premissa: Processos síncronos, mensagens unicast, ordenação preservada e
o atraso de comunicação limitado.
Sistema: N processos e cada processo i fornece um valor vi aos demais.
Como o sistema se recupera de uma falha
Resiliência de Processo
Acordo em sistemas com falha

Problema do acordo bizantino.


Objetivo: Cada processo deve construir um vetor V de comprimento N tal que,
se o processo i não for faltoso, V[i] = vi.
Caso contrário, V[i] é indefinido.

Considerando que há no máximo K processos faltosos.


Como o sistema se recupera de uma falha
Resiliência de Processo
Acordo em sistemas com falha
Problema do acordo bizantino.
1- Processo 1 reporta 1, processo 2 reporta 2, processo 3
N=4 e k=1 mente e processo 4 reporta 4 (a);
2- Resultados são anunciados por cada vetor do processo,
processo 3 mente mostrando x, y e z (b);
3- Os processos transmite seu vetor para todos os outros
processos, onde o processo 3 mente novamente inventado
outros valores (c);
4- Cada processo examina o i-ésimo elemento . Se qualquer
um dos vetores tiver uma maioria, ele é colocado no vetor de
resultados, senão é marcado como UNKNOWN.
Como o sistema se recupera de uma falha
Resiliência de Processo
Detecção de Falhas

Para mascarar adequadamente, em geral, também é preciso detectá-las.


Uma das pedras fundamentais da tolerância a falhas em SD.
Em um grupo de processos, por exemplo, é preciso que os membros não
faltosos do grupo sejam capazes de detectar quando um membro falhou,
decidindo que, ainda é membro e quem não é.

A abordagem usualmente seguida é enviar pings


•  Tipo de mensagem enviada para verificar a presença de uma entidade
remota.
Como o sistema se recupera de uma falha
Resiliência de Processo
Detecção de Falhas
Tudo se resume a utilização de mecanismos de temporização

Em ambientes reais esta abordagem tem 2 problemas:


1-Falsos-positivos: declarar que um processo falhou porque não retornou um
ping, pode ser um erro de julgamento: redes não confiáveis.
2-Esgotamento da temporização (timeout ineficiente): (sub)sistemas
inadequados de detecção de falha que levem em conta mais do apenas a
falta de resposta de uma única mensagem.

Possível Solução: Considerar possíveis notificações de falhas entre os


membros do sistema (Gossiping: anunciar ao vizinho que está vivo e
funcionando).
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor

Falhas não atingem somente processos, mas também a comunicação entre


eles
• Um canal de comunicação pode exibir falhas por queda, omissão,
temporização e arbitrárias.
• Na prática, ao se “construir” canais de comunicação confiáveis, o foco está
em mascarar falhas por queda e omissão.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Comunicação ponto-a-ponto

Quando um middleware de comunicação não é usado, a comunicação


confiável em um SD pode ser estabelecida com a utilização de um protocolo
de transporte confiável → ex. TCP.

TCP mascara falhas por omissão → mensagens perdidas →


reconhecimentos e retransmissões.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Comunicação ponto-a-ponto

Falhas por queda não são mascaradas: conexão TCP é interrompida


abruptamente de modo que nenhuma mensagem possa ser transmitida pelo
canal.

Um SD pode mascarar tal falha, tentando estabelecer automaticamente uma


nova conexão, com o reenvio de uma requisição de conexão.

Premissa subjacente é que o outro lado ainda, ou novamente, será capaz de


responder.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas

Objetivo da RPC (Remote Procedure Call) é ocultar comunicação fazendo


chamadas de procedimentos remotos parecerem chamadas locais

Quando erros ocorrem, é difícil mascarar a diferença entre chamadas locais e


remotas

São distintas 5 classes de erros e possíveis soluções.


Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas

Classes de erros:
(1) Cliente não consegue localizar o servidor.
(2) Mensagens de requisição do cliente para o servidor perdidas.
(3) Queda do servidor após receber uma requisição.
(4) Mensagens de resposta do servidor para o cliente se perde.
(5) Queda do cliente após enviar uma requisição.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas: (1) Cliente não consegue localizar
o servidor.

Possíveis problemas:
(1) Servidores podem ter caído
(2) Cliente pode ter sido compilado usando uma versão de apêndice antiga

Solução: Ativar uma exceção (Java: invocação de procedimento para


tratamento de erros – divisão por zero, por ex.)
→ acarreta em perda da transparência: produzindo mensagens do tipo “não
pode localizar o servidor” !!!
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (2) Mensagens de requisição do
cliente para o servidor perdidas.

Solução: SO ou apendice do cliente inicia temporizador de espera para a


mensagem de resposta servidor. Enviar novamente no caso de expirar tempo
sem resposta.

Problema: se a requisição não for perdida o servidor precisa detectar que


está lidando com um retransmissão (mensagem original ≠mensagem de
retransmissão) → evitar o “Não pode localizar o servidor"
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (3) Queda do servidor após receber
uma requisição.

Sequências:
(a) requisição chega, é executada, sua resposta enviada – normal.
(b) requisição chega, é excutada e o servidor cai antes de enviar resposta.
(c) requisição chega, mas o servidor cai antes de poder executar a
requisição.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (3) Queda do servidor após receber
uma requisição.

Estratégias que o cliente pode seguir (exemplo impressão de um texto):


1. Cliente pode decidir NUNCA reemitir uma requisição – risco de nunca
imprimir;
2.  Cliente pode decidir SEMPRE reemitir uma requisição – risco de
impressão de imprimir 2 vezes;
3.  Cliente pode decidir reemitir somente quando NÃO RECEBE ACK –
servidor caiu antes da requisição de impressão ser entregue;
4.  Cliente pode decidir reemitir uma requisição somente SE TIVER
RECEBIDO ACK de reconhecimento para requisição de impressão.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (4) Mensagens de resposta do
servidor para o cliente se perde.

Problema: cliente não sabe com certeza por que não houve resposta.
Requisição ou resposta que se perdeu ou servidor está lento?

No caso de requisição idempotente: operações que podem ser repetidas


sem causar nenhum dano. e.x leitura de arquivos retransmissão → pode ser
feita sem problemas a consistência do SD.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (4) Mensagens de resposta do
servidor para o cliente se perde.

E no caso de requisições não idempotentes? (transmissão de dinheiro, por


ex).
(1) Estruturar todas as requisições como idempotentes (quando couber)
(2) Abordagem TCP-like, onde o cliente designa um número de sequência a
cada requisição → servidor deve manter informações de cada cliente.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (5) Queda do cliente após enviar
uma requisição.

Que acontece quando um cliente envia uma requisição a um servidor para


executar algum trabalho e cai antes dele responder?
Computação está ativa mas processo pai morre → orfão
• Provoca diversos problemas: desperdiça ciclos de CPU, trava arquivos,
amarra outros recursos, etc.

O Que pode ser feito com orfãos?


Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (5) Queda do cliente após enviar
uma requisição.

O que pode ser feito com orfãos?


• Extermínio de órfão: manter registro em disco (ou outro meio que sobreviva
a quedas) antes de enviar msg RPC. Após a reinicialização, o registro é
verificado e o órfão é explicitamente exterminado.
• Desvantagem: despesa de escrever um registro em disco para toda RPC.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (5) Queda do cliente após enviar
uma requisição.

O que pode ser feito com orfãos?


• Reencarnação: divide o tempo em épocas numeradas em sequencia.
Quando o cliente reinicializa, envia mensagens broadcast a todas as
máquinas, declarando um (re)inicio.

• Reencarnação gentil: quando um broadcast de época chega, cada


máquina verifica se há computação remota executando no local. Se sim,
localiza seu proprietário. Se não, remove a computação.
Como o sistema se recupera de uma falha
Comunicação Confiável Cliente-Servidor
Semantica RPC na presença de falhas (5) Queda do cliente após enviar
uma requisição.

O que pode ser feito com orfãos?


• Expiração: RPC recebe quantidade de tempo padrão T, para fazer o
trabalho.Não conseguir terminar, solicita um outro quantum.

• O problema é escolher um valor razoável para T em face de RPCs com


requisitos muito variados.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável

Mensagens são entregues a um grupo de processos . No entanto, a


comunicação multicast é bem complicada!

- Camadas de Transporte oferecem comunicação ponto-a-ponto confiável


(TCP)
- Raro oferecer comunicação confiável a um conjunto de processos
Possível solução: Estabelecer comunicações ponto-a-ponto entre os
processos → Problema: desperdício de largura de banda de rede.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
O que é multicast confiável?
Significa que uma mensagem enviada a um grupo de processos deve ser
entregue a cada membro do grupo
• O que ocorre se durante a comunicação um processo se juntar ao grupo?
• O que ocorre se um processo sair deste grupo?

Soluções considerando dois cenários:


(1) Processos estáo funcionando corretamente e o grupo é estático
(2) Processos falham!
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.

Processos não falham e não se juntam ao grupo nem saem dele enquanto a
comunicação está em curso

Multicast confiável
Toda mensagem deve ser entregue a cada membro do grupo no momento
em questão
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.

Suposições
(1) Caso em que um único remetente queira enviar uma mensagem multicast
a vários receptores. E.x: Algoritmo de Berkeley para sincronizar os relógios.

(2) Rede de Comunicação não confiável: mensagem multicast pode se perder


em algum ponto do caminho e ser entregue a alguns, mas não a todos os
receptores.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 1: Esquema básico
(1) Processo remetente designa um número de sequência a cada mensagem
multicast.
(2) Mensagens são recebidas na ordem.
(3) Cada mensagem multicast é armazenada no remetente, em um buffer.
(4) Mensagem é mantida até receptores confirmem o recebimento.
(5) Retransmissão: reconhecimento negativo ou timeout.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 1: Esquema básico
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 1: Esquema básico
Questões:
(1) Como reduzir o número de mensagens retornadas ao remetente?
piggybacking (enviar mensagens de um protocolo dentro de mensagens de
um outro protocolo)?
(2) Como fazer a retransmissão? Ponto-a-ponto ou novamente multicast
(3) E a escalabilidade?
Caso com N receptores, o remetente deve estar preparado para aceitar no
mínimo N reconhecimentos → IMPLOSÃO DE RETORNO
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 2: Escalabilidade em multicast confiável
(1) Receptores enviam mensagem de retorno somente para informar ao
remetente a FALTA de uma mensagem.
(2) Retornar somente reconhecimentos negativos melhora a escalabilidade
(Towsley et al 1997), mas não garante que implosões de retorno nunca
acontecerão.

Problema: Remetente será forçado a manter uma mensagem em seu buffer


de histórico para “sempre” → timeout para retirada da msg pode levar ao
caso onde uma requisição pode não ser efetivada!
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

(1) Objetivo principal: Reduzir mensagens de retorno (supressão de retorno).


(2) Utiliza o protocolo de multicast confiável escalável (Scalable Reliable
Multicast SRM).
(3) Somente reconhecimentos negativos são devolvidos como realimentação.
Aplicação decide como detectar a perda de uma mensagem.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

(4) Ao reconhecer que está faltando uma mensagem, receptor envia o pedido
da mensagem perdida, usando multicast, ao resto do grupo.
(5) Utilizar realimentação multicast permite que um outro membro do grupo
suprima seu reconhecimento (realimentação).
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

- Suponha que vários receptores tenham percebido a falta da msg m.


- Cada um deles precisará retornar um reconhecimento negativo ao
remetente S, para retransmissão de m.
- Se considerarmos que as retransmissões são enviadas ao grupo, basta uma
única mensagem de requisição para que o pedido de retransmissão chegue
até S.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

- Um receptor R que não recebeu a msg m escalona uma msg de


realimentação com certo atraso aleatório.
- A requisição para retransmissão não é enviada até passar algum tempo
aleatório.
- Se um requisição de m chegar a R, antes do timeout, R não enviará a msg
de realimentação negativa.
- Espera-se que somente uma msg de pedido de retransmissão de m chegue
a S.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

Vários receptores escalonaram uma requisição para transmissão, mas a


primeira requisição de retransmissão resulta na supressão das outras.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

Aprimoramento:
Permitir que um receptor tenha o papel de transmitir uma mensagem m,
mesmo antes de a requisição de retransmissão chegar ao remetente original.

Exemplo de aplicação: aplicações colaborativas, como a de whiteboard


compartilhado.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 3: Realimentação não hierárquico

Problemas
- Garantir que somente uma requisição de retransmissão chegue ao
remetente S → temporizadores?
- Interrupção dos processos os quais a msg já foi entregue → separar os
processos que não receberam m em um grupo separado (Kasera et al,1997)
→ gerenciamento dos grupos
- Reunir os processos em grupos que tendem a perder mensagens (Lui et al,
1998)
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 4: Controle de realimentação hierárquico

- Único remetente.
- Grupo é dividido em sub-grupos, organizados em árvore.
- Cada sub-grupo possui um coordenador que gerencia os pedidos de
retransmissão.
- O coordenador possui um buffer para armazenar as msgs para atender
pedidos dos membros do seu sub-grupo.

Problema: Construção e manutenção da árvore.


Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (1) Processos estáo funcionando corretamente e o grupo é estático.
Solução 4: Controle de realimentação hierárquico

Cada coordenador local


repassa a mensagem a
seus filhos e mais tarde
manipula requisições de
retransmissão contidas
em seu subgrupo.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (2) Processos podem falhar!
Solução: Multicast atômico

Deve-se chegar a um acordo sobre a real composição do grupo!


- Objetivo:
Uma msg será entregue a todos os processos ou a nenhum deles.
Mensagens são entregues na mesma ordem a todos os processos
→ Atomicidade!
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (2) Processos podem falhar: Mustcast Atomico
Solução: Multicast atômico - Exemplo: Banco de Dados replicado

- Banco de dados é construído como um grupo de processos, um processo


para cada réplica.
- Operações de atualização são enviadas em multicast a todas as réplicas
(multicast confiável na entrega destas operações!)
Suponha que durante a execução de uma das atualizações de uma
sequência, uma réplica caia.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (2) Processos podem falhar: Mustcast Atomico
Solução: Multicast atômico - Exemplo: Banco de Dados replicado

Se o sistema NÃO suporta multicast atômico, problema!

Réplica se recupera: essencial que seja atualizada em relação as outras


réplicas.
Quais operações estão faltando e em que ordem devem ser executadas????
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (2) Processos podem falhar: Mustcast Atomico
Solução: Multicast atômico - Exemplo: Banco de Dados replicado

Se o sistema suporta multicast atômico


- A operação de atualização que foi enviada a todas as réplicas um pouco
antes de uma delas cair ou é executada em todas as réplicas não faltosas ou
em nenhuma.
- A atualização é realizada se as réplicas restantes concordarem que a
réplica que caiu não pertence mais ao grupo.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast confiável
Cenário (2) Processos podem falhar: Mustcast Atomico
Solução: Multicast atômico - Exemplo: Banco de Dados replicado

Se o sistema suporta multicast atômico


- Após a recuperação, a réplica é validada como sendo do grupo e recebe as
atualizações.

Multicast atômico garante que processos não faltosos mantenham uma visão
consistente do banco de dados e força a reconciliação quando uma réplica se
recupera e se junta ao grupo novamente.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Como implementar?
Sistema distribuído possui uma camada de comunicação , que gerencia o
recebimento das mensagens em um buffer local, até que possa ser entregue
à aplicação.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Musticast confiável pressupõe que uma mensagem será entregue a todos os
processos de um grupo ou a nenhum deles.

Exemplo:
Banco de Dados replicado construído com um grupo de processos para os
quais as mensagens podem ser enviadas de modo confiável.
Operações de atualização são enviadas em multicast para todas as réplicas,
e na sequencia, executadas no local.
Se uma réplica cai durante a comunicação, a atualização esta perdida para
esta réplica.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Musticast confiável pressupõe que uma mensagem será entregue a todos os
processos de um grupo ou a nenhum deles.

Exemplo:
As outras replicas podem entrar em um acordo para a realização da
atualização, e a réplica em falta não fará mais parte do grupo de processos.

Ela só poderá retornar ao grupo se seu estado seja atualizado em relação ao


resto dos membros do grupo.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Musticast confiável pressupõe que uma mensagem será entregue a todos os
processos de um grupo ou a nenhum deles.

Como implementar?
• Uma mensagem m está associada com uma lista de processos aos quais
deve ser entregue
• Lista de entrega corresponde a uma visão do grupo
• Todos os processos possuem a mesma visão, concordando que m deve ser
entregue a cada um deles e a nenhum outro processo
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Musticast confiável pressupõe que uma mensagem será entregue a todos os
processos de um grupo ou a nenhum deles.

• Suponha que a mensagem m seja enviada em multicast no instante que seu


remetente tem visão de grupo G
• Se um processo entra ou sai do grupo, ocorre uma mudança de visão

• Duas mensagens: m e a de entrada/saída do novo processo (vc)


• Garantir que todos os processos em G recebam m antes de vc, evitando
inconsistência
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual

Multicast confiável garante que uma mensagem enviada em multicast para a


visão de grupo G seja entregue a cada processo não faltoso em G.

• Se o remetente cair durante o multicast, a mensagem pode ou ser entregue


a todos os processos restantes ou ser ignorada por cada um deles →
multicast virtualmente síncrono (Birman e Joseph, 1987).

• Mensagens multicast ocorrem entre mudanças de visão.


Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Multicast virtualmente sincrono
Ex: em um certo instante, o processo P1 se junta ao grupo P2, P3, P4. Após o
envio de algumas mensagens o P3 cai. Contudo antes e cair, ele consegue
enviar uma msg multicast para P2 e P4., mas não a P1.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual
Multicast virtualmente sincrono
Ex: Mais tarde, quando P3 de recupera, ele pode se juntar ao grupo
novamente, após seu estado ter sido atualizado,
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Sincronia Virtual

Uma mudança de visão é considerada uma barreira pela qual nenhum


multicast pode passar!

Aplicação de sincronia virtual: Isis → implementações de ferramentas para


desenvolvimento de SDs tolerantes a falhas: gerenciamento de replicação de
dados, sincronização de computação distribuída, reconfiguração dinâmica de
um sistema.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Sincronia virtual permite que um desenvolvedor de aplicações imagine que
multicasts ocorram em épocas que são separadas por mudanças nas
associações aos grupos.

Tipos de ordenação das mensagens


• Multicasts não ordenados
• Multicasts ordenados em Fifo
• Multicasts ordenados por causalidade
• Multicasts totalmente ordenados
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Multicast confiável não ordenado

Não são dadas garantias quanto à ordem na qual as mensagens recebidas


são entregues aos diferentes processos.

Tres processos que se comunicam no mesmo grupo. A ordenação dos


eventos por processos ao longo do eixo vertical.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Multicast confiável ordenado em FIFO
Camada de comunicação é forçada a entregar as mensagens que chegam do
mesmo processo na mesma ordem em que elas foram enviadas.

Na Figura a única coisa que importa é que a mensagem m1 é sempre


entregue antes da m2 e da mesma maneira m3 antes de m4.
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Multicast confiável ordenado em FIFO
Esta regra deve ser obedecida por todos os processos do grupo. Isto quer
dizer se P3 receber m2 antes de m1, a mensagem m2 ficará em espera até a
entrega de m1.

Não há restrição em relação a entrega de mensagens enviada por processos


diferentes (P1 e P4, por exemplo).
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Multicast confiável ordenado por causalidade
• Entrega de mensagens de modo que a potencial causalidade entre
mensagens diferentes seja preservada
• Se m1 precede uma outra mensagem m2 por causalidade,
independentemente de terem sido enviadas por processos diferentes,
camada de aplicação sempre entregará m2 após ter recebido e entregado m1
• Utilização de relógios vetoriais para a marcação das entregas
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens
Multicast confiável com entrega totalmente ordenada
• Significa que as mensagens devem ser entregues na mesma ordem a todos
os membros do grupo
• Entregas podem ser dos tipos não ordenada, ordenada em FIFO ou
ordenada por causalidade

Multicast Atomico = Multicast Confiável virtualmente síncrono que oferece


entrega de mensagens totalmente ordenadas
Como o sistema se recupera de uma falha
Comunicação Confiável de Grupo
Multicast Atômico – Ordenação de mensagens

Seis versões diferentes de multicast confiável virtualmente sincrono.


Como o sistema se recupera de uma falha
Recuperação
Recuperação
Essência: Quando ocorre uma falha no sistema, é necessário “levar” o
sistema para um estado livre de erro.

Recuperação de um erro é fundamental em tolerância a falhas.

A ideia geral da recuperação de erro é substituir um estado errôneo por um


estado livre de erro.
Como o sistema se recupera de uma falha
Recuperação
Recuperação
Recuperação de um erro - formas principais:

Recuperação retroativa: Retorna o sistema a algum estado que antes


estava correto, continuando a execução após a recuperação. Mecanismo de
ponto de verificação (estado presente do sistema é registrado).

Recuperação para frente: Tentativa de levar o sistema para um próximo


estado correto.
Como o sistema se recupera de uma falha
Recuperação
Recuperação de um erro

(1) Recuperação retroativa: Comunicação multicast confiável →


retransmissão de pacote

(2) Recuperação para frente: recuperação de pacotes a partir de outros


pacotes
Como o sistema se recupera de uma falha
Recuperação

Recuperação para frente – desvantagem


• É preciso saber de antemão quais erros podem ocorrer.
• Tendo conhecimento de todos os erros e como levar o sistema para um
estado correto, é possível recuperar totalmente o sistema.

Recuperação retroativa: desvantagens


• Pontos de validação podem ser caros para serem implementados
• Não existem garantias que o erro não acontecerá novamente
• Em alguns casos não é possível retroagir a um estado sem erros (ex.
comando UNIX rm –rf *
(*) comando que remove a deleção recursiva de arquivos e diretórios)
Como o sistema se recupera de uma falha
Recuperação
Armazenamento estável
Para conseguir recuperar os dados para um estado seguro é necessário
possuir um armazenamento estável.

• Armazenamento em RAM (apaga sem energia ou em falha)


• Armazenamento em disco (pode ter falha de cabeçote)
• Armazenamento estável: adoção de uma matriz de discos que faz a
redundância/distribuição dos dados.
Como o sistema se recupera de uma falha
Recuperação
Armazenamento estável

(a) Armazenamento
estável
(b) Crash do disco
antes da atualização
no disco 2 (spare)
(c) Soma de verificação
de um bloco errada no
disco 2

Quando dados são escritos no armazenamento estavel, e então lidos novamente para
verificar se foram escritos corretamente, a probabilidade de eles serem perdidos em seguida
é extremamente pequena.
Como o sistema se recupera de uma falha
Recuperação
Registro de mensagens

Ideia principal: Combinar pontos de verificação com o registro da sequência


de mensagens recebidas
(1) O processo receptor registra uma mensagem antes de entregá-la a
aplicação (ou então, o emissor registra as mensagens antes de enviá-las).

(2) Quando um processo cai, o sistema é restaurado para o estado


correspondente ao ponto de verificação mais recente e, a partir deste ponto,
reproduz as mensagens recebidas.
Como o sistema se recupera de uma falha
Recuperação
Registro de mensagens

Qual a diferença entre utilizar apenas pontos de verificação e pontos de


verificação + registro de mensagens?
(1) No caso do uso isolado de pontos de verificação, os processos são
restaurados para o ponto antes da falha e o comportamento pode ser
diferente após a recuperação (ex. msgs podem ser entregues em ordenação
diferente).

(2) No caso do registro de mensagens, o comportamento é reproduzido do


mesmo modo entre o ponto de recuperação e o ponto em que ocorreu a falha
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação

A recuperação retroativa de erros requer que o sistema salve periodicamente


seu estado em armazenamento estável.

Fotografia Distribuída: Registro de um estado global consistente.

Em uma fotografia distribuída, se um processo P tiver registrado o


recebimento de uma mensagem, então também deve existir um processo Q
que registrou o envio dessa mensagem
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação

Cada processo salva seu estado periodicamente em um armazenamento


estável disponível localmente.

A recuperação após uma falha de processo ou de sistema requer a


construção de um estado global consistente com base nesses estados locais.

Melhor alternativa é recuperar a fotografia mais recente, denominada linha de


recuperação → mais recente conjunto consistente de pontos de verificação
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação

Salvar o estado dos processos de tempos em tempos: linha de recuperação


(recovery line)
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação Independentes

Descobrir uma linha de recuperação requer que cada processo seja revertido
a seu estado salvo mais recente.

Se, em conjunto, os estados locais não formam uma fotografia distribuída, é


preciso reverter ainda mais para trás.
• processo de reversão em cascata pode resultar no efeito dominó
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação Independentes

Pode causar um efeito dominó na recuperação para um estado livre de erros


Para recuperar o Processo P2 (mensagem m perdida), é preciso recuperar o
processo P1 (m’)
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação Coordenados

Todos os processos sincronizam para escrever, em conjunto, seu estado


para armazenamento local.

O estado salvo é globalmente consistente, evitando as reversões em cascata


que levam ao efeito dominó
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação Coordenados

Solução Simples: Usar protocolo de bloqueio de duas fases


(1) Coordenador envia uma msg multicast CHECKPOINT_REQUEST a todos
os processos.
(2) Quando o processo recebe esta mensagem, estabelece um ponto de
verificação local e enfileira qualquer msg e envia uma mensagem de
reconhecimento ao coordenador indicando que estabeleceu o ponto de
verificação.
(3) Após receber todos os ACKS, coordenador envia msg multicast
CHECKPOINT_DONE para desbloquear os processos.
Como o sistema se recupera de uma falha
Recuperação
Pontos de Verificação Coordenados
Estado globalmente consistente: não existirão mensagens que ultrapassem
as linhas de recuperação, ou seja, a mensagens são tratadas entre os pontos
de verificação.

Qualquer mensagem que vier após uma requisição para estabelecer um


ponto de verificação não é considerada como parte do ponto de verificação
local.

Ao mesmo tempo, mensagens que estão saindo são enfileiradas no local até
a mensagem CHECKPOINT_DONE ser recebida.
Como o sistema se recupera de uma falha
Recuperação
Resumo

Tolerância a falha é uma questão importante no projeto de sistemas


distribuídos: característica pela qual um sistema pode mascarar a ocorrência
e a recuperação de falhas.

Vários tipos:
Falha por queda, por omissão, temporização, falha de resposta,
arbitrárias
Como o sistema se recupera de uma falha
Recuperação
Resumo
Redundância é a técnica fundamental necessária para conseguir tolerância a
falha.

No caso de processos, é formado Grupos que podem ser simples (todos


processos tomam decisões da mesma maneira ) ou hierárquicos
(coordenador gerencia).

Se os processos falham e devem chegar a um acordo, situação se complica!


Algoritmo de Lamport, onde resultados de computação são trocados e a
decisão final é tomada como sendo a da maioria
Como o sistema se recupera de uma falha
Recuperação
Resumo
No caso da comunicação confiável multicast, deve-se garantir que todos as
mensagens chegarão aos membros de um grupo.

Se não existem falhas dos processos, e os grupos são pequenos, pode-se


usar os mecanimos de confirmação. Por questões de escalabilidade, é usado
os NACKs e temporizadores.

No caso de fornecer multicast atômico, onde todos os membros do grupo


devem receber a informação na mesma ordem, A entrega das informações é
baseada em visões de grupo.
Como o sistema se recupera de uma falha
Recuperação
Resumo
Recuperação em sistemas tolerantes a falhas é alcançada por pontos de
verificação periódicos do estado do sistema.

A verificação é completamente distribuída, sendo esta uma operação cara,


principalmente no caso de pontos de verificação independentes.

Para melhorar o desempenho, muitos sistemas distribuídos combinam pontos


de verificação com registro de mensagens.

Registrado a comunicação entre processos, torna-se possível reproduzir a


execução do sistema após a ocorrência de uma queda.