Tolerancia A Falha PDF

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.
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.
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.
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).
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).
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
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.
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.
•  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.
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”).
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”.
Toueg (1993)
Falha de resposta: resposta do servidor é incorreta.

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.
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.
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
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
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)
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
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
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
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.
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
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).
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%.
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
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)
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
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.
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.
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.
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.
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).
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.
•  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.
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
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.
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
•  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
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).
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.
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.
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.
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.
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.
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
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.
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.
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.

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.
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.
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).
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.
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.
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.
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.

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.
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” !!!
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"
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.
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.
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.
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.
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?

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.
uma requisição.

• 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.
uma requisição.

• 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.
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.
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!
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
Toda mensagem deve ser entregue a cada membro do grupo no momento
em questão
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.
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.
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
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!
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.
(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).
- 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.
- 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.
Vários receptores escalonaram uma requisição para transmissão, mas a

primeira requisição de retransmissão resulta na supressão das outras.
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.
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)
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.

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.
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!
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.
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????
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.
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.
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.
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.
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 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
• 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
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.

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.
Multicast virtualmente sincrono
Ex: Mais tarde, quando P3 de recupera, ele pode se juntar ao grupo
novamente, após seu estado ter sido atualizado,
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.
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
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.
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.
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).
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
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
Seis versões diferentes de multicast confiável virtualmente sincrono.

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.
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.
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
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)
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.
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.
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.
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
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
Recuperaçã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
Recuperação
Salvar o estado dos processos de tempos em tempos: linha de recuperação

(recovery line)
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ó
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’)
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ó
Recuperação
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.
Recuperação
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.
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
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
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.
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.

Tolerancia A Falha PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tolerancia A Falha PDF

Caricato da

Copyright:

Formati disponibili

Sistemas Distribuídos

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

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

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

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

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

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

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

FALTA Causa Leva a FALHA Pode Perigo

Causa erro Detectado por Desvio do estado

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

Falta inativa ou dormente -> falta não ativada

Uma falha é definida como um evento (comportamento) enquanto

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

FALHA (failure): problemas de desempenho ou inabilidade do

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

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

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

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

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

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

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

A probabilidade de ocorrência do perigo pode ser quantitativa

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

Possui duas importantes características:

PERIGO (hazard): Características

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

(2) Probabilidade de ocorrencia: pode ser especificado

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

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

Risco pode ser considerado como a probabilidade de ocorrência

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

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

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

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

Falha por queda: servidor para prematuramente apesar de estar

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

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

Falha de resposta: resposta do servidor é incorreta.

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

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

Checksum Precisão dupla

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

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

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

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

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

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

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

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

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

Problema: quão grande k precisa ser?

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

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

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

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

Casos – Turek e Sasah (1992):

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

Lamport et al (1982) – Problema do acordo bizantino

Problema do acordo bizantino.

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

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

A abordagem usualmente seguida é enviar pings

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

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

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

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

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

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

(2)  Probabilidade de ocorrencia: pode ser especificado

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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