Camilo Silva

Tolerância de Falhas
CONCEITOS BÁSICOS
▸ Técnica fundamental para tratamento de falhas: redundância;

▸ Tolerância a falhas está relacionada à confiabilidade

(dependability) de um sistema;

▸ Requisitos para confiabilidade:

▸ Disponibilidade (availability)

▸ Confiabilidade (reliability)

▸ Segurança (safety)

▸ Capacidade de manutenção (maintainability)

DISPONIBILIDADE (AVAILABILITY)
▸ Indica que um sistema está pronto para uso imediato;

▸ Refere-se à probabilidade de que sistema está operando

corretamente num dado instante e está disponível
para executar suas funções;

▸ Alta disponibilidade indica que sistema muito

provavelmente estará funcionando num dado instante;
CONFIABILIDADE (RELIABILITY)
▸ Refere-se à propriedade que um sistema irá operar
continuamente sem falha;

▸ É definida em termos de um intervalo de tempo, ao invés

de num dado instante como ocorre com a disponibilidade;

▸ Sistema confiável é aquele que muito provavelmente irá

operar sem interrupção durante um período relativamente
longo de tempo;
SEGURANÇA (SAFETY)
▸ Refere-se às consequências da falha de um sistema
em operar corretamente;

▸ Sistemas críticos devem prover alto grau de

segurança;
CAPACIDADE DE MANUTENÇÃO
(MAINTAINABILITY)
▸ Indica a facilidade para que um sistema que falhou seja
reparado;

▸ Sistema com alta capacidade de manutenção

normalmente também apresenta alto grau de
disponibilidade, especialmente se falhas podem ser
detectadas e reparadas automaticamente;
DISPONIBILIDADE X CONFIABILIDADE
▸ Sistema que falha por 1 milissegundo a cada hora:

▸ Disponibilidade alta, acima de 99.9999 %;

▸ Confiabilidade baixa;

▸ Sistema que nunca cai (crashes) mas é desligado por

2 semanas no ano:

▸ Alta confiabilidade;

▸ Apenas 96 % de disponibilidade;
CONCEITOS BÁSICOS
▸ Defeito: se um sistema não pode cumprir suas promessas,
apresenta defeito.

▸ Ex.: Não consegue garantir as consistências prometidas.

▸ Erro: parte do estado de um sistema causado por uma falha.

▸ Ex.: Pacotes danificados.

▸ Falha: é a causa de um erro.

▸ Ex.: Um meio de transmissão errado ou ruim
pode danificar pacotes.
CONCEITOS BÁSICOS
▸ Sistema falha quando não pode manter
seus compromissos;

▸ Um erro é uma parte do estado de um sistema que

pode levar a uma falha;

▸ Causa do erro é chamada de falta(fault);

▸ A construção de sistemas confiáveis (dependable)

está relacionada ao controle das faltas (faults);

▸ Faltas podem ser prevenidas, removidas e previstas.

CONCEITOS BÁSICOS
▸ Sistemas de uma máquina (não distribuídos): uma falha é
quase sempre total;

▸ Sistemas distribuídos: pode ocorrer uma falha parcial,

quando um componente do sistema falha.

▸ Objetivo: recuperar automaticamente de falhas parciais sem

afetar seriamente o desempenho global
TOLERÂNCIA A FALTAS(FAULT
TOLERANCE)
▸ Significa que um sistema pode prover seus
serviços mesmo na presença de faltas;

▸ NÃO significa que falhas não vão ocorrer!!!

TIPOS DE FALHAS:
▸ Transiente:

▸ Ocorre uma vez e desaparece;

▸ Intermitente:

▸ Ocorre, para por um período indeterminado, reaparece,

e assim por diante;

▸ Permanente:

▸ Continua a existir até que o componente faltoso

seja substituído;
COMO TRATAR FALTAS:
▸ Fault prevention:
▸ Prevenir a ocorrência de faltas

▸ Fault tolerance:
▸ Construir componente que possa mascarar a presença de
faltas;

▸ Fault removal:
▸ Reduzir a presença, o número e a gravidade (seriousness) de
faltas;

▸ Fault forecasting:
▸ Estimar a situação atual e futura de faltas e as consequências de
suas ocorrências;
MODELOS DE FALHA
▸ Para melhor identificar as falhas, foram desenvolvidos
diversos esquemas de classificação, entre eles, o
quadro abaixo:
MASCARAMENTO DE FALHA POR
REDUNDÂNCIA
▸ Para o sistema ser tolerante a falhas, as ocorrências destas
devem ser ocultas de outros processos e dos usuários;

▸ A técnica fundamental para mascarar falhas é usar

redundância;
MASCARAMENTO DE FALHA POR
REDUNDÂNCIA
▸ Redundância de informação:

▸ bits extras para recuperação de pacotes (Hamming);

▸ Redundância de tempo:

▸ executar novamente uma ação, se for preciso;

▸ Redundância física:

▸ adicionar equipamentos ou processos extras para

possibilitar tolerância a perda ou mal funcionamento de
alguns componentes;
MASCARAMENTO DE FALHA POR
REDUNDÂNCIA
RESILIÊNCIA DE
PROCESSO
RESILIÊNCIA DE
PROCESSO
▸ Resiliência:

▸ The ability to recover quickly from illness, change, or

misfortune;

▸ The property of a material that enables it to resume its

original shape or position after being bent, stretched, or
compressed; elasticity;

▸ Proteção contra falha de processos: obtida

com replicação de processos em grupos;
RESILIÊNCIA DE
PROCESSO
▸ Diversos processos idênticos são organizados num grupo;

▸ Quando uma mensagem é enviada para um grupo,

todos os processos membros deste grupo a recebem;

▸ Se um processo no grupo falha, outro pode assumir;

▸ Grupos podem ser dinâmicos, criados e destruídos

por demanda;
RESILIÊNCIA DE
PROCESSO
▸ Processos podem entrar e sair de grupos em tempo de
execução e podem pertencer a vários grupos simultaneamente;

▸ Mecanismos devem existir para gerenciamento de grupos e

processos;

▸ Grupos permitem tratar com vários processos usando uma

abstração;

▸ Mensagens podem ser enviadas para grupos sem saber

informações sobre;
QUESTÕES DE PROJETO
DE G RUPO S
▸ A abordagem fundamental para tolerar um processo
faltoso é organizar vários processos idênticos em um
grupo.
▸ Quando uma mensagem é enviada a um grupo,
todos membros do grupo a recebem;
▸ Se um processo falhar, espera-se que algum outro
se encarregue da mensagem em seu lugar;

▸ Grupos podem ser dinâmicos;

▸ A finalidade de introduzir grupos é permitir que

processos tratem conjuntos de processos como
uma única abstração;
GRUPOS SIMPLES (FLAT
GROUP)
▸ Todos processos são iguais dentro de um grupo;

▸ Ninguém manda, todas decisões são coletivas;

▸ Simétrico, sem um ponto único de falha;

▸ Tomada de decisão é mais complexa;

▸ Entrada e saída de membros no grupo feitas através de

mensagens multicast (confiáveis); pode ocorrer fail-stop;
GRUPOS HIERÁRQUICOS: (HIERARCHICAL
GROUP)
▸ Possui coordenador(es) e operários;

▸ Comunicação ocorre via coordenador;

▸ Não completamente tolerante a falhas e escalável, mas

de fácil implementação;

▸ Servidor de grupo (group server) gerencia entrada e saída

de membros no grupo;
GRUPOS SIMPLES X GRUPOS
HIERÁRQUICOS
RESILIÊNCIA DE
PROCESSO
▸ Processos podem ser replicados e organizados num
grupo(tolerante a faltas) para substituir um processo
único (vulnerável);

▸ Existência de processos idênticos num grupo permite

mascarar a falha de um ou mais processos nesse
grupo;

▸ Replicação pode ocorrer através de protocolos baseados

em primário (primary-based) ou com escrita
replicada(replicated-write);
RESILIÊNCIA DE
PROCESSO
▸ Primary-based: grupo é organizado de forma hierárquica e
processo primário coordena todas as operações de escrita;
▸ Se primário falha, processos backup executam
algoritmo de eleição para escolha de um novo primário;
▸ Operação na forma de replicação ativa, ou de protocolos
baseados em quórum (quorum-based);
▸ Processos idênticos operam em organização flat com
coordenação distribuída;
MASCARAMENTO DE FALHA E
REPLICAÇÃO
▸ Questão: quanta replicação é necessária?

▸ Sistema é dito k fault tolerant(k-tolerante a faltas) se pode

sobreviver a faltas em k componentes e ainda cumprir
suas especificações;

▸ Se componentes (processos) falham silenciosamente, k+1

processos remanescentes são suficientes para prover k-
tolerância a faltas;

▸ Nesse caso, se k processos falharem, processo restante

provê a resposta desejada
ACORDO EM SISTEMAS
COM FALHAS
▸ Organizar processos replicados em um grupo ajuda a
aumentar a tolerância a falha. Existem várias
situações:

▸ Sistemas síncronos vs. assíncronos;

▸ Atraso de comunicação limitado ou não;

▸ Entrega de mensagens ordenada ou não;

▸ Transmissão de mensagens unicast ou multicast;

ACORDO EM SISTEMAS
COM FALHAS
ACORDO EM SISTEMAS
COM FALHAS
▸ Esse problema, estudado pela primeira vez por Lamport
(1982), é também conhecido como problema do acordo
bizantino, consideramos problemas assíncronos,
mensagens unicast, ordenação preservada e atraso
limitado.
ACORDO EM SISTEMAS
COM FALHAS
▸ Em um sistema com k processos faltosos pode-se
conseguir um acordo somente se estiverem presentes
2k+1 processos funcionando corretamente, para um total
de 3k+1 (ou seja, mínimo mais que 2/3).
DETECÇÃO DE
FALHA
▸ Mascaramento de falha requer sua identificação prévia;

▸ Membros do grupo que não têm falta devem ser

capazes de detectar quem ainda é membro do grupo e
quem apresentou falta e deve ser removido;

▸ Mecanismos:

▸ Envio de msg: “are you alive?” entre os nós, e espera

por resposta – ping ativo;

▸ Espera passiva até que mensagens cheguem dos

diferentes processos (viável apenas se há comunicação
suficiente (frequente) entre os nós;
DETECÇÃO DE
FALHA
▸ Mecanismo de timeout é usado para verificar se processo
tem falta;

▸ Problema: ausência de resposta pode indicar erroneamente que

processo tem falta;

▸ Implementação pode considerar mecanismo de gossiping,

em que nó propaga informações do seu estado aos
vizinhos;

▸ Necessidade de distinguir falha da rede e falha de

um processo;
DETECÇÃO DE
FALHA
▸ Detecção de faltas também pode ser feita como um
efeito colateral do uso de gossiping para troca de
informações entre os vizinhos, propagando informações
sobre os estados dos nós;

▸ Eventualmente, todo processo terá informações

suficientes para decidir sobre o estado dos demais e se
há processos com falta;
COMUNICAÇÃO
CONFIÁVEL CLIENTE-
COMUNICAÇÃO PONTO-A-
PONTO
▸ Tolerância a falta normalmente concentra-se na detecção
de falta de processo;

▸ Faltas na comunicação também devem ser consideradas;

▸ Modelos de falha também se aplicam aos canais

de comunicação: crash, omissão, timing e
arbitrárias;

▸ Construção de canais de comunicação normalmente foca

no mascaramento de falhas do tipo crashe omissões;
COMUNICAÇÃO PONTO-A-
PO NTO
▸ Falhas arbitrárias podem ocorrer na forma de mensagens
duplicadas, resultantes de armazenamento temporário e
retransmissões;

▸ Na comunicação ponto-a-ponto, confiabilidade é obtida

com o uso de protocolos de transporte confiável, como
TCP;
▸ Mensagens de reconhecimento e retransmissões
mascaram omissões;
▸ Falhas na conexão TCP podem ser tratadas permitindo
que SD tente estabelecer uma nova conexão;
COMUNICAÇÃO PONTO-A-
PONTO
▸ A forma mais adotada para adquirir esta transparência é
através do uso de RPC;

▸ RPCs visam esconder detalhes da comunicação, tornando

chamadas remotas semelhantes às chamadas locais;
FALHAS
EM RPC
‣ Falhas possíveis:

‣ Cliente não consegue localizar o servidor;

‣ Mensagem do cliente não chega ao servidor (perdida);

‣ Servidor cai (crashes) depois de receber pedido;

‣ Resposta do servidor ao cliente é perdida;

‣ Cliente cai (crashes) depois de enviar pedido;

FALHAS
EM RPC
▸ Cliente não consegue localizar o servidor:

▸ Servidores todos podem ter caído

(down);

▸ Cliente pode estar usando versão stub antiga

incompatível com versão atual do servidor;

▸ Erro pode gerar exceção (exception– Java, ou sinal

específico – C);

▸ Nem toda linguagem tem suporte;

FALHAS
EM RPC
▸ Mensagem do cliente não chega ao servidor (perdida):

▸ Pode ser tratada com timer mantido pelo SO ou

pelo stub do cliente;

▸ Expiração de timeout antes de resposta ou

reconhecimento gera retransmissão;

▸ Servidor pode precisar diferenciar retransmissões de

novas chamadas;
FALHAS
EM RPC
▸ Servidor cai (crashes) depois de receber pedido:

▸ Possíveis tratamentos dependem do que é esperado

pelo cliente:
a. Semântica at-least-once (ao menos uma vez): sistema cliente
continua tentando (retransmitindo pedido) até uma resposta seja
recebida. Nesse caso, RPC terá sido executada ao menos1vez;
b. Semântica at-most-once (no máximo uma vez): cliente desiste
imediatamente e retorna indicação de falha. RPC terá sido
executada no máximo 1 vez, mas possivelmente nenhuma;

c. Semântica exactly once (exatamente uma vez);

FALHAS
EM RPC
▸ Servidor cai (crashes) depois de receber pedido;

▸ Quedas de Servidor – situações possíveis na

ocorrência de uma queda do servidor.
FALHAS
EM RPC
▸ Resposta do servidor ao cliente é perdida;

▸ Ausência de resposta pode gerar retransmissões depois

da expiração de temporizadores

▸ Problema: como saber se servidor recebeu pedido (e

realizou serviço)?

▸ Solução: tentar tornar operações idempotentes

(repetíveis sem efeitos indesejados)
FALHAS
EM RPC
▸ Resposta do servidor ao cliente é perdida;

▸ Para operações não idempotentes pode-se atribuir

número de sequência para requisições de cada cliente;

▸ Números permitem ao servidor diferenciar pedido de

retransmissões. Servidor tem que manter
informações de estado;
▸ Mensagens podem conter (bit) identificador de
retransmissão: novos pedidos podem ser realizados
imediatamente. Retransmissões requerem tratamento;
FALHAS
EM RPC
▸ Cliente cai (crashes) depois de enviar pedido;

▸ Problema: servidor está realizando solicitação e

mantendo recursos por nada;

▸ Computação órfã gera desperdício de recursos de

processamento;

▸ Pode haver bloqueio de recursos;

FALHAS
EM RPC
▸ Cliente cai (crashes) depois de enviar pedido;

▸ Soluções:

▸ Client stub salva registro (log) em disco (persistente)

antes de realizar chamada RPC. Depois de um reinício
(reboot) computação órfã é explicitamente encerrada
(or rolled back): orphan extermination

▸ Possibilidade de surgimento de grandorphans, e atrasos

para acesso ao disco antes de RPCs tornam proposta não
interessante
FALHAS
EM RPC
▸ Cliente cai (crashes) depois de enviar pedido;

▸ Soluções:

▸ Tempo é dividido em épocas; ao reiniciar, cliente

divulga uma mensagem às demais máquinas
declarando nova época. Ao receber mensagem, nó
remove todas as computações anteriores daquele
cliente. Falha na rede pode gerar órfãos ativos.
Estratégia conhecida como reencarnação
(reincarnation).
FALHAS
EM RPC
▸ Cliente cai (crashes) depois de enviar pedido;

▸ Soluções:

▸ Gentle reincarnation: ao receber mensagem de nova

época, servidor tenta localizar todos os clientes remotos
associados. Na ausência de comunicação, computações
são encerradas.
▸ Expiration: cada RPC recebe um tempo (T) para
conclusão. Se não for concluída nesse tempo, RPC deve
negociar novo prazo. Em caso de reiniciação,
servidor pode encerrar requisições órfãs depois de
tempo T.
FALHAS
EM RPC
▸ Cliente cai (crashes) depois de enviar pedido;

▸ Problemas:

▸ Encerramento das computações órfãs pode ter

consequência imprevistas

▸ Requisições podem ter bloqueado recursos

▸ Requisições podem ter iniciado outras

requisições...
COMUNICAÇÃO
CONFIÁVEL DE GRUPO
MULTICAST CONFIÁVEL (RELIABLE
MULTICASTING)
▸ Multicast confiável é importante para garantir que
mensagens sejam entregues a todos os
processos replicados num grupo;

▸ Protocolos de transporte oferecem comunicação confiável

apenas ponto-a-ponto;

▸ Possível abordagem para multicast confiável consiste em

criar-se vários canais unicast, um para cada receptor:
solução ineficiente;
MULTICAST CONFIÁVEL (RELIABLE
MULTICASTING)
▸ Situações envolvem diferentes aspectos se processos
membros do grupo podem variar, saindo por falha,
ou ingressando no grupo, durante transmissão de
mensagem;

▸ Como garantir que mensagem seja entregue aos

processos do grupo apenas se todos receberem?

▸ Transmissor associa número a cada

mensagem transmitida;
MULTICAST CONFIÁVEL (RELIABLE
MULTICASTING)
▸ Mensagens são transmitidas em sequência;

▸ Mensagens transmitidas são mantidas em buffer no

transmissor até que todos os destinatários
confirmem recebimento;

▸ Receptores conseguem identificar mensagens fora de

ordem e geram reconhecimento negativo (negative
acknowledgment) solicitando retransmissão;
MULTICAST CONFIÁVEL (RELIABLE
MULTICASTING)
▸ Transmissor também pode manter temporizador que
indica necessidade de retransmissão em caso de ausência
de resposta;

▸ Reconhecimentos podem ser enviados “de carona” em

mensagens;
MULTICAST CONFIÁVEL (RELIABLE
MULTICASTING)
MULTICAST CONFIÁVEL (RELIABLE
M ULT I
C ASTI
N G)
▸ Abordagem usando reconhecimento não é adequada
para grande número de receptores (não escalável);

▸ Um problema apresentado é a implosão de retorno, que

pode lotar o remetente com mensagens de confirmação de
recebimento;
▸ Solução: Não confirmar recebimento, mas apenas
devolver respostas quando detectar faltas.
▸ Gera novo problema: Quando remover mensagem enviada do
buffer?

▸ Quando fica cheio, mas pode resultar em uma retransmissão não ser
honrada!
▸
Implosões de retorno ainda podem acontecer!
CONTROLE DE RECONHECIMENTO (FEEDBACK)
NÃO HIERÁRQUICO
▸ Proposta: Scalable Reliable Multicasting (SRM);

▸ Receptores geram notificações apenas para mensagens

não recebidas;

▸ Identificação de mensagem não recebida é deixada a

cargo da aplicação;

▸ Ao detectar falha, receptor notifica os demais

processos no grupo via multicast;
CONTROLE DE RECONHECIMENTO (FEEDBACK)
NÃO HIERÁRQUICO
▸ Proposta: Scalable Reliable Multicasting (SRM);

▸ Outros membros do grupo com falha não precisam

gerar notificações também;

▸ Supondo que m processos podem ter falha de

recebimento, uso de multicast gera economia
de transmissões;

▸ Atraso aleatório é introduzido antes do envio da

mensagem de feedback;
CONTROLE DE RECONHECIMENTO (FEEDBACK)
NÃO HIERÁRQUICO
▸ Proposta: Scalable Reliable Multicasting (SRM);

▸ Algoritmo tem boa escalabilidade, mas pode fazer

com que processos tenham que tratar transmissões de
mensagens já recebidas;

▸ Possibilidade de criação de sub-grupos; requer

gerenciamento eficiente de grupos;
CONTROLE DE RECONHECIMENTO (FEEDBACK)
NÃO HIERÁRQUICO
CONTROLE DE RECONHECIMENTO (FEEDBACK)
HIERÁRQUICO
▸ Escalabilidade no envio de mensagens para grandes
grupos requer abordagem hierárquica;

▸ Receptores são particionados em subgrupos e

organizados na forma de uma árvore;

▸ Dentro de cada subgrupo, qualquer mecanismo de

entrega, adequado para pequenos grupos, pode ser
usado;
CONTROLE DE RECONHECIMENTO (FEEDBACK)
HIERÁRQUICO
▸ Cada subgrupo determina um coordenador local,
que passa a ser responsável pelos envios de
pedidos de retransmissão deste subgrupo
▸ Coordenador local tem seu próprio buffer de histórico
de transmissões.
▸ Mensagens recebidas por todos no subgrupo podem
ser descartadas.

▸ Questão: dificuldade para construção da árvore.

▸ Normalmente, roteador multicast no grupo é usado

como coordenador
CONTROLE DE RECONHECIMENTO (FEEDBACK)
HIERÁRQUICO
MULTICAST
ATÔMICO
▸ Comunicação multicast confiável implica que mensagens
sejam entregues a todos os processos ou a nenhum

▸ Mensagens também devem ser entregues na mesma

ordem a todos os processos

▸ Considerando que operações são replicadas em vários

processos de um grupo, aplicação das operações
depende de processos estarem em acordo sobre quem
participa do grupo (está ativo), de forma que ou todos
realizem as operações, ou nenhum
MULTICAST ATÔMICO –
SINCRONIA VIRTUAL
MULTICAST ATÔMICO –
SI
N CRO NIA VIRTUA L
▸ Há apenas uma situação em que entrega de mensagem
pode falhar: quando participação no grupo muda
como resultado do emissor da mensagem m
quebrar(crash)

▸ Nesse caso, deve ser entregue a cada um dos processos

restantes, ou pode ser ignorada por todos os membros
do grupo, como se o emissor tivesse quebrado antes do
envio
▸ Multicast confiável com essas características é
denominado virtualmente síncrono(virtually synchronous)
MULTICAST ATÔMICO –
SINCRONIA VIRTUAL
ORDENAÇÃO DE
MENSAGENS
▸ São distinguidas quatro ordenações diferentes:

▸ Multicasts não ordenados;

▸ Multicasts ordenados em FIFO;

▸ Multicasts ordenados por causalidade;

▸ Multicasts totalmente ordenados;

ORDENAÇÃO DE
MENSAGENS
▸ Multicast confiável não ordenado é um multicast
virtualmente síncrono sem garantias sobre a ordem em
que mensagens recebidas são entregues aos diferentes
processos

▸ Com multicasts ordenados em FIFO, camada de

comunicação deve entregar as mensagens aos processos
na mesma ordem em que foram enviadas
ORDENAÇÃO DE
MENSAGENS
▸ Multicast confiáveis ordenados por causalidade entregam
mensagens de forma que potenciais causalidades entre
mensagens diferentes é preservada

▸ Com multicasts totalmente ordenados, independente de

ordenações entre as mensagens, todos os processos as
recebem na mesma ordem
ORDENAÇÃO DE
MENSAGENS
▸ Multicasts não ordenados;

▸ Multicasts ordenados em FIFO

ORDENAÇÃO DE
MENSAGENS
▸ A entrega totalmente ordenada é aplicada em adição às
três primeiras, e significa que, independente da ordem
aplicada, a ordem de entrega deve ser a mesma em todos
os membros do grupo.

▸ Multicasts que apresentam essa propriedade são

denominados multicasts atômicos.
ORDENAÇÃO DE
MENSAGENS
RECUPERAÇÃ
RECUPERAÇÃ
O
▸ Ocorrida uma falha, é necessário não apenas identificá-
la, mas recuperar-se da mesma e voltar para um estado
correto.

▸ Essencialmente existem 2 maneiras de se recuperar:

▸ Recuperação retroativa – volta para um estado anterior

à falha;

▸ Recuperação para a frente – tenta levar o sistema para

um novo estado correto para que possa continuar a
executar.
GARANTIA DE ESTADO
ESTÁVEL
PONTOS DE
VERIFICAÇÃO
▸ Independentes:

▸ Coordenados: usam, por exemplo, bloqueio em duas

fases
RECUPERAÇÃO - CARACTERIZAÇÃO DE ESQUEMAS DE REGISTRO DE
MENSAGENS
REFERÊNCIA
S
▸ Cap 8 Tanenbaum e van Steen - Sistemas
Distribuídos: princípios e paradigmas