Aula 3 - Tratamento de Falhas

Prévia do material em texto

Aula 3 - Tratamento de Falhas 
 
Introdução 
O profissional da área de Tecnologia da Informação atua diretamente no 
planejamento, na implementação e na implantação de soluções de TI nas 
organizações. 
 
1 Falhas Parciais 
Uma característica dos sistemas distribuídos: é a noção de falha parcial. 
A falha parcial pode acontecer quando um componente em um sistema distribuído 
não funciona. Essa falha pode afetar a operação adequada de outros componentes 
e, ao mesmo tempo, deixar outros totalmente ilesos. 
A falha em sistemas não distribuídos quase sempre é total, no sentido de que afeta 
todos os componentes e pode, facilmente, fazer o sistema inteiro cair. 
Um objetivo importante do projeto de sistemas distribuídos é construir o sistema de 
tal modo que possa se recuperar automaticamente de falhas parciais, sem afetar, 
seriamente, seu desempenho global. 
Em particular, sempre que ocorrer uma falha, o sistema distribuído deve continuar 
a funcionar de maneira aceitável enquanto o sistema estiver em conserto. 
Em outras palavras, o sistema distribuído deve tolerar falhas e continuar a funcionar 
até certo ponto, mesmo na presença dessas falhas. 
 
2 Tolerância a falhas 
A confiabilidade abrange uma série de requisitos úteis para sistemas distribuídos, tais 
como: 
Disponibilidade 
Sistema estar pronto para ser usado imediatamente, sistema funcionar corretamente em 
qualquer momento e estar disponível para executar funções em nome de seus usuários. 
Se um sistema nunca cai, mas é desligado por duas semanas em um determinado mês, 
todos os anos, tem alta confiabilidade, mas somente 96% de disponibilidade. 
Confiabilidade 
Sistema poder funcionar continuamente sem falhas. 
Definida em um intervalo de tempo, e não de um instante de tempo. 
A alta confiabilidade representa o que provavelmente continuará a funcionar, sem 
interrupção, durante um período de tempo relativamente longo. 
Se um sistema ficar fora do ar por um milissegundo a cada hora, terá uma 
disponibilidade de mais de 99,99%, mas sua confiabilidade ainda será muito baixa. 
 
Segurança 
Se um sistema deixar de funcionar corretamente durante certo tempo, nada de 
catastrófico acontecerá. 
É o que acontece, por exemplo, com sistemas de controle de processos usados em 
usinas de energia nuclear ou sistemas para enviar pessoas ao espaço. 
 
Capacidade de manutenção 
À capacidade de manutenção consiste na facilidade com que um sistema que falhou 
pode ser consertado. 
Sistemas de alta capacidade de manutenção também podem mostrar alto grau de 
disponibilidade, em especial se as falhas puderem ser detectadas e reparadas 
automaticamente. 
 
3 Falha, erro e defeito 
O defeito acontece quando o sistema não pode cumprir o que foi especificado ou 
prometido. 
 Em particular, se um sistema distribuído é projetado para oferecer a seus usuários 
uma série de serviços, o sistema falha quando um ou mais desses serviços não 
podem ser fornecidos completamente. 
O erro, estado de um sistema que pode levar a uma falha (a causa de um erro é 
denominada falha). 
 É o caso da transmissão de pacotes por uma rede. Espera-se que alguns pacotes 
estejam danificados quando chegam ao receptor. Meios de transmissão com 
problemas podem facilmente danificar pacotes. 
 Os erros de transmissão também podem ser causados por más condições 
atmosféricas, como ocorre com redes sem fio. 
 
4 Tipos de falhas 
As falhas são classificadas como: 
Transientes 
As falhas transientes ocorrem uma vez e, depois, desaparecem. Se a operação for 
repetida, a falha não acontecerá novamente. 
 Por exemplo, um pássaro voando pelo feixe de um transmissor de microondas pode 
causar perda de bits em alguma rede. 
Intermitentes 
As falhas intermitentes ocorrem e desaparecem por sua própria vontade. Depois, 
essas falhas reaparecem e assim por diante. 
 Por exemplo, um conector com um contato frouxo causará, muitas vezes, uma 
falha intermitente. 
Permanentes 
As falhas permanentes continuarão a existir até que o componente faltoso seja 
substituído. 
 É o caso dos chips queimados e dos bugs de software. 
 
5 Modelos de falha 
Um sistema falha quando não fornece, adequadamente, os serviços para os quais foi 
projetado. 
Se considerarmos um sistema distribuído como um conjunto de servidores que se 
comunicam entre si e com seus clientes, esse fornecimento inadequado de serviços 
significa que servidores, canais de comunicação ou, possivelmente, ambos não estão 
fazendo o que deveriam fazer. 
Contudo, nem sempre um servidor que funciona mal representa a falha que estamos 
procurando. Se tal servidor depender de outros servidores para prestar seus serviços 
adequadamente, é possível que a causa de um erro tenha de ser procurada em 
algum outro lugar. 
Para que tivéssemos uma ideia melhor da real seriedade de uma falha, foram 
desenvolvidos diversos esquemas de classificação. 
 
 
 
6 Técnicas de tratamento 
Mascaramento de falha por redundância 
Se um sistema deve ser tolerante a falhas, o melhor que ele pode fazer é tentar ocultar 
de outros processos a ocorrência de falhas. À técnica fundamental para mascarar 
falhas é usar redundância. 
 
Redundância de Informação 
Na redundância de informação, os bits extras são adicionados para permitir recuperação 
de bits deteriorados. 
Por exemplo, um código de Hampming pode ser adicionado a dados transmitidos para 
recuperá-los de ruído na linha de transmissão. 
 
Redundância de Tempo 
Uma ação é realizada e, se for preciso, essa ação será executada novamente. 
Transações (banco de dados usam essa abordagem. Se uma transação for abortada, 
ela pode ser refeita sem causar nenhum dano. 
 
Redundância Física 
Na redundância física*, são adicionados equipamentos ou processos extras para 
possibilitar que o sistema como um todo tolere a perda ou o mau funcionamento de 
alguns componentes. A redundância física pode ser feita em hardware ou 
em software. 
Processos extras podem ser adicionados ao sistema, de modo que, se uma pequena 
quantidade deles cair, o sistema ainda possa funcionar corretamente. 
Em outras palavras, replicando processos, podemos conseguir alto grau de 
tolerância à falha. 
*A redundância física é uma técnica bem conhecida para prover tolerância à 
falha. Essa técnica é usada em: 
Biologia – mamíferos têm dois olhos, dois ouvidos, dois pulmões e assim por 
diante; 
Aeronaves – aviões 747 têm quatro motores, mas podem voar com três; 
Esportes – com a utilização de vários juízes, caso algum deles não perceba um 
evento. 
A referida técnica também vem sendo usada, há anos, para tolerância à falha 
em circuitos eletrônicos. 
 
Mascaramento de falhas e replicação 
Grupos de processos fazem parte da solução para construir sistemas tolerantes à 
falha. 
Em particular, ter um grupo de processos idênticos permite-nos mascarar um ou mais 
processos faltosos àquele grupo. Podemos replicar processos e organizá-los em um 
grupo para substituir um único processo (vulnerável) por um grupo (tolerante à falha). 
De modo geral, em casos de tolerância à falha, a replicação é baseada na forma de um 
protocolo de primário e backup. 
Nesse caso, um grupo de processos é organizado de modo hierárquico, no qual um 
servidor primário coordena todas as operações de escrita. 
Na prática, o servidor primário é fixo, embora seu papel possa ser assumido por um 
dos backups (caso necessário). 
Na verdade, quando um servidor primário cai, os backups executam algum algoritmo 
de eleição para escolher um novo servidor primário. 
 
 
Acordo em Sistemas com Falha 
Organizar processos replicados em um grupo ajuda a aumentar a tolerância à falha. 
Em geral, as coisas tornam-se mais complicadas se exigirmos que um grupo de 
processos chegue a um acordo, o que é necessário em muitos casos, tais como: 
· Eleger um coordenador; 
· Decidir a validação ou não de uma transação; 
· Repartir tarefas entre operários; 
· Sincronização. 
Quando a comunicação e os processos são todos perfeitos, chegar a tal acordo 
costumaacontecer de forma direta, mas, quando não o são, surgem problemas. 
O objetivo geral de algoritmos de acordo distribuído é que todos os processos que não 
apresentam falha cheguem a um consenso sobre alguma questão e estabeleçam esse 
consenso dentro de um número finito de etapas. 
O problema é complicado pelo fato de que premissas diferentes sobre o sistema 
subjacente requerem soluções diferentes, considerando que existam soluções para as 
mesmas. 
 
 
Detecção de falha 
Para mascarar falhas adequadamente, em geral, também é necessário detectá-las! 
A detecção de falhas é uma das bases da tolerância à falha em sistemas 
distribuídos. 
No caso de um grupo de processos, os sistemas devem ser capazes de decidir quem 
ainda é um membro e quem não é, isto é, o sistema deve ser capaz de detectar quando 
um membro de um grupo falhou. 
Quando se trata de detectar falhas de processos, há, essencialmente, dois mecanismos: 
1. Os processos enviam as mensagens ativamente uns aos outros; 
2. Os processos esperam passivamente pela entrada de mensagens de processos 
diferentes. 
A detecção de falha (Por exemplo, a detecção de falha pode ocorrer por gossiping, 
no qual cada nó anuncia, periodicamente, a seus vizinhos que ainda está vivo e 
funcionando) também pode ser realizada como resultado da troca regular de 
informações com vizinhos, como acontece na disseminação de informações baseada 
em gossiping. 
Em determinado momento, todo processo saberá da existência de cada um dos 
outros processos. Entretanto, o mais importante é que o referido processo terá 
informações disponíveis suficientes para decidir se outro processo falhou ou não. 
Detecção de falha – exemplo 
Podemos também nos deparar com a seguinte situação: 
um subsistema de detecção de falhas que não consegue distinguir falhas de rede de 
falhas de nós. 
Um modo de lidar com esse problema é não permitir que um único nó decida se um de 
seus vizinhos caiu. 
Em vez disso, ao perceber que a temporização de uma mensagem ping se esgotou, 
um nó requisita a outros vizinhos que verifiquem se podem alcançar o nó que, 
presumivelmente, falhou. 
Certamente, informações positivas também podem ser compartilhadas: se um nó ainda 
estiver vivo, essa informação poderá ser transmitida para outras partes 
interessadas (que podem detectar uma falha de enlace com o nó suspeito). 
 
Recuperação 
Uma vez ocorrida a falha, é essencial que o processo em que a mesma aconteceu se 
possa recuperar para um estado correto. 
A recuperação de um erro é fundamental para a tolerância à falha! 
 
Atenção! 
É bom lembrar que um erro é parte de um sistema que pode levar a uma falha. 
A ideia geral de recuperação de erro é substituir um estado errôneo por um 
estado livre de erro. 
 
7 Formas de Recuperação de Erro 
Essencialmente, existem duas formas de recuperação de erro, quais sejam: 
Recuperação Retroativa 
A questão principal da recuperação retroativa* é trazer o sistema de seu estado com 
o erro presente para um estado anterior, que estava correto. 
Para fazer isso, é necessário registrar o estado do sistema de tempos em tempos e 
restaurar tal estado registrado quando ocorrer o erro. 
Toda a vez que o estado presente de um sistema (ou parte dele) é registrado, 
dizemos que foi realizado um ponto de verificação (check-point). 
* De modo geral, técnicas retroativas de recuperação de erro são amplamente 
aplicadas como um mecanismo geral para recuperação de falhas em sistemas 
distribuídos. 
Em outras palavras, a recuperação retroativa pode ser integrada a um sistema 
distribuído (camada de middleware) como um serviço de uso geral. 
 
Recuperação para a Frente 
Quando o sistema entra em um estado de erro, em vez de retroagir para um estado 
anterior correspondente a um ponto de verificação, realiza-se uma tentativa para levar 
o sistema a um novo estado correto, a partir do qual ele possa continuar a executar. 
O principal problema dos mecanismos de recuperação para a frente* é que 
precisamos saber, de antemão, quais erros podem ocorrer. Só assim, é possível 
corrigir esses erros e passar para um novo estado. 
* Para distinguirmos recuperação de erro retroativa e para a frente, basta 
considerarmos a implementação da comunicação confiável. 
A abordagem comum para se recuperar um pacote perdido é permitir que o 
remetente retransmita esse pacote. Na verdade, a retransmissão de pacotes determina 
que tentamos voltar a um estado anterior correto, ou seja, ao estado no qual o pacote 
que foi perdido está sendo enviado. 
Portanto, a comunicação confiável por meio de retransmissão de pacote é um 
exemplo de aplicação de técnicas retroativas de recuperação de erro. 
 
 
CONCLUSÃO