Aula 11
Tolerância a Falhas
Conteúdo
 Introdução à Tolerância a Falha
 Resiliência
 Recuperação
Introdução à Tolerância a Falha
 Conceitos básicos:
Muita pesquisa tem sido feita, na área de computação, sobre
tolerância a falha. Principalmente em sistemas grandes e
complexos (como a maioria hoje), existem diversos riscos que
precisam ser previstos.
O entendimento do que significa realmente “ser tolerante à falha”
necessita de uma definição clara do que é um sistema confiável.
A confiabilidade representa uma conjunto de requisitos
importantes:
 Disponibilidade
 Confiabilidade
 Segurança
 Capacidade de manutenção
Introdução à Tolerância a Falha
É importante ainda diferenciar três termos que são
frequentemente mal utilizados:
 Defeito: um defeito é uma característica do aplicativo que
resulta na incapacidade em cumprir sua finalidade, as
expectativas do usuário. A falha ocorre quando o defeito se
manifesta.
 Erro: Normalmente provocado por um defeito, erro é o
estado em que se encontra um sistema que não pode
cumprir suas obrigações.
 Falha: É o resultado de um defeito que gerou um erro.
Nesse cenário, é um evento disparado por um defeito, que
coloca o sistema em erro e o conjunto dessa situação é
denominado falha.
Introdução à Tolerância a Falha
O controle de falhas (seja ao evitar, remover ou prever falhas) é
de vital importância à construção de Sistemas confiáveis. Mas,
além disso, outra estratégia é prover tolerância a falha, o que
significa que o sistema deverá ser capaz de atuar mesmo na
presença de falhas.
As falhas podem ser classificadas em três tipos. Tal classificação
é de vital importância na definição dos mecanismos de tolerância:
 Falhas transientes
 Falhas intermitentes
 Falhas permanentes
Introdução à Tolerância a Falha
 Modelos de falha
Nem sempre o efeito mensurável de um falha ajuda a identificar
sua causa. Essa situação é pior em Sistemas Distribuídos porque,
como são compostos de vários elementos cooperativos, a falha
em um deles pode afetar outros.
Para facilitar o estudo das falhas, existe uma classificação dos
modelos possíveis. Esses são os modelos mais comuns:
 Falha por queda
 Falha por omissão (de recebimento ou envio)
 Falha de temporização
 Falha de resposta (de valor ou transição de estado)
 Falha arbitrária
Introdução à Tolerância a Falha
 Mascaramento de falha por redundância
Quando de trata de tolerância a falha (e não de controle de falha),
a estratégia mais comum é mascarar eventuais falhas com o uso
de redundância. Há três tipos básicos:
Redundância de Informação
Redundância de tempo
Redundância física
Um exemplo notável de redundância é a chamada Redundância
Modular Tripla (Triple Modular Redundancy ou TMR). Ela pode
ser vista na figura a seguir:
Introdução à Tolerância a Falha
Considere um circuito com dispositivos interdependentes como
na figura abaixo:
A
B
C
Uma falha no dispositivo A ou B pode comprometer todo o
circuito. A TMR consiste em tratar essas falhas com redundância
de dispositivos e tratamento das informações utilizando-se de
votantes:
A1
V1
B1
V4
C1
V7
A2
V2
B2
V5
C2
V8
A3
V3
B3
V6
C3
V9
Resiliência de processo
 Questões de projeto
Descartadas as hipóteses de mascaramento,
Sistemas realmente tolerantes à falhas?
como criar
Para que isso seja possível, o sistema deve ter meio de
impedir (?), detectar e/ou se recuperar de situações de falha
Uma abordagem, com foco em proteção à falhas de processo
é o agrupamento de processos. Nesse caso, um grupo de
processos é tratado abstratamente como um só e recebem as
mesmas mensagens.
Resiliência de processo
 Grupos simples versus grupos hierárquicos
A organização do grupo pode ser hierárquica ou não. O que
traz vantagens e desvantagens. Essa diferenciação se reflete
também na forma como os processos se associam.
Quando descentralizados, grupos de processo atuam em
conjunto e devem chegar a um acordo. Para isso existem
alguns algoritmos específicos e o problema aumenta na
mesma medida que que os processos discordam. Nesse
cenário, caso haja falha em um dos processos, os demais
assumem sua carga de modo transparente.
Resiliência de processo
 Associação a um grupo
Os agrupamentos hierárquicos e não hierárquicos possuem
suas vantagens e desvantagens. Enquanto um agrupamento
simples é simétrico e não possui pontos únicos de falha, os
hierárquicos tem um tomada de decisão menos complicada,
uma vez que o processo de maior hierarquia toma as decisões
sozinho, sem necessitar de votação.
Uma dificuldade na utilização da estratégia de grupos é o
tratamento de inclusão e exclusão dos processos nos grupos.
Uma solução elegante é ter um servidor de grupos que cuide
das particularidades desse processo de maneira transparente.
Resiliência de processo
 Mascaramento de falha e replicação
Após entender os mecanismos de redundância que provêm
tolerância, a próxima pergunta pertinente é: o quanto o
sistema é tolerante. Com um grupo de processos, diz-se que o
sistema é k-tolerante se puder lidar com até k falhas
simultâneas. Para isso serão necessários k+1 processos no
grupo.
Porém, em caso de falhas arbitrárias, em que o processo não
deixa de funcionar, mas apresenta resultados incorretos, serão
necessários 2k+1 processos no grupo, de modo que uma
votação entre os processos decida qual é o resultado correto.
Resiliência de processo
 Acordo em sistemas com falha
Porém, mesmo a tarefa de votar (ou chegar a um acordo)
entre processos de um grupo apresenta dificuldades. Para que
ocorra, uma série de decisões menores precisam ser tomadas
(que processo coordenará, como se dará a sincronização, etc).
Existem diversos algoritmos de acordo entre processo (cujo
objetivo é obter o consenso). Mas, para que possam ser
implementados, é importante distinguir fatores importantes
como: se a comunicação é síncrona ou assíncrona, se a
comunicação é ordenada ou desordenada e, ainda, se a
comunicação é feita por unicast ou multicast. Todos esses
fatores interferem na escolha e funcionamento do algoritmo.
Resiliência de processo
 Detecção de falha
O mascaramento de falhas só é possível se o sistema for
capaz de detectar a falha quando esta ocorrer. Essa tarefa é
fundamental na construção da tolerância. O mecanismo mais
comum é enviar “pings” para outros processo com o objetivo
de descobrir se continuam ativos.
O problema dessa solução é que, em redes não confiáveis, a
demora em obter uma resposta pode gerar uma falsa
informação de falha. E, ainda, essa solução não permite
diagnosticar se a falha ocorre no processo ou no meio de
comunicação. Há muitas outras estratégicas teóricas para
resolver essas questões mas, na prática, o uso de pings ainda
é a solução mais comum.
Recuperação
 Introdução
O mascaramento é uma das faces da tolerância a falhas. Mas,
para sua total implementação, é fundamental que o sistema
possa se recuperar e voltar a um estado livre de erro.
Existem duas abordagens básicas, cada uma com suas
vantagens e desvantagens:
Recuperação retroativa
Recuperação para a frente
Por serem mais simples de implementar, as técnicas de
recuperação retroativa são as mais comuns. Porém,
normalmente tem um impacto significativo no desempenho
Recuperação
 Pontos de verificação
Para a aplicação de uma abordagem de recuperação
retroativa, é necessário que o sistema guarde, periodicamente,
fotos do seu estado. Em sistemas distribuídos, essa foto
precisa ser global e é chamada de Fotografia Distribuída.
Um problema dessa abordagem é que, como cada processo
distribuído armazena seus próprios pontos de verificação e
estes são independentes, é difícil formar uma foto distribuída
em que todos os pontos estejam sincronizados. Nesse caso, é
preciso retroagir ainda mais nos pontos de verificação de cada
processo até encontrar um que seja consistente com os
demais. Essa situação é chamada Efeito dominó.
Recuperação
 Pontos de verificação (continuação)
Uma solução para esse problema é a utilização de pontos de
verificação coordenados. A estratégia consistem em fazer com
que todos os processos se sincronizem antes de gravarem
seus pontos de verificação.
Para essa sincronização, um mecanismo de bloqueio simples
em duas fases e a adoção de um processo coordenador são
suficientes. A grande vantagem é que o estado armazenado a
partir dessa estratégia é globalmente consistente. Porém,
como se pode imaginar, a troca extra de mensagens entre os
processos pode ter impacto significativo no desempenho.
Recuperação
 Registro de mensagens
Para minimizar o impacto ao desempenho, uma abordagem
possível é diminuir a quantidade de pontos de verificação sem
comprometer a capacidade de recuperação. Com esse intuito,
uma outra técnica complementar pode ser utilizada, o registro
de mensagens.
A ideia básica é armazenar todas as mensagens trocadas pelo
processo desde o último ponto de verificação. Desse modo,
mesmo com menos pontos, seria possível reproduzir as
mensagens trocadas posteriormente e voltar a um estado
válido.
Recuperação
 Computação orientada a recuperação
Em alguns casos, outro modo de lidar com a recuperação é
simplesmente começar de novo e reiniciar o sistema. Nessa
abordagem, a implementação é otimizada para reiniciar se
necessário. Essa abordagem é denominada Computação
orientada a recuperação.
Para que seja possível, durante o projeto do sistema, os
componentes precisam ser planejados para possuir um alto
grau de desacoplamento. Somente desse modo é possível
reiniciar parte de um sistema distribuído sem causar falha nos
demais módulos.