Sistemas em Tempo Real Módulo 3: Tolerância a Falhas

Apresentação em tema: "Sistemas em Tempo Real Módulo 3: Tolerância a Falhas"— Transcrição da apresentação:

1 Sistemas em Tempo Real Módulo 3: Tolerância a Falhas
Créditos, em sua maioria, ao Prof. Helano de Sousa Castro. 4 horas de aula : 2 x 20 minutos de exercício e 3 e 20 min de exposição. Necessário: 80 transparências. 1.o tempo: 2 horas e 15 min (135min) Transparências Programação: 30 minutos : famílias 40 minutos : arquitetura 60 minutos : Clocks Intervalo 2.o tempo: 2 horas e 15 min (135min) Programação: 20 minutos : exercícios sobre clocks 60 minutos : inicialização 20 20 minutos : exercícios sobre inicialização 30 minutos : características especiais 20 Jarbas Silveira

2 Roteiro Ementa: 3. Tolerância a Falhas: Falha, Erro e Defeito; Tipos de falhas; Redundância (Estática e Dinâmica); Detecção; Avaliação de Danos; Recuperação de erros. Jarbas Silveira

3 Roteiro Introdução - Classificação das Falhas - Prevenção de Falhas - Tolerância à Falhas - Estratégias de Tolerância à Falhas - Recuperação do Erro Jarbas Silveira

4 Roteiro Jarbas Silveira 4

5 Introdução - Técnicas de tolerância a falhas são usadas em sistemas de computadores como forma de se lidar com condições de erro que podem surgir durante as suas vidas operacionais. - O relacionamento entre causa e efeito é melhor entendido sob a luz de três conceitos básicos : defeito, erro e falha. Jarbas Silveira

6 Introdução -Um defeito é um desvio do comportamento do sistema de algum conjunto de especificações pré-definidas. Um Erro é parte de um estado errôneo que constitui uma diferença de um estado válido. Uma Falha ocorreria como resultado de um erro de um componente ou no projeto do sistema. Jarbas Silveira 6

7 Introdução Relacionamento entre Falha, Erro, e Defeito. Falha Erro
Jarbas Silveira 7

8 Classificação das Falhas
-A fim de proteger o sistema contra falhas, o projetista terá que provê-lo com técnicas que possam lidar com elas. Entretanto, esta estratégia só pode levar em conta as falhas que tenham sido antecipadas durante a fase de projeto. Infelizmente, o único tipo de falha que pode ser antecipadamente previstas com algum grau de precisão são falhas em componentes do hardware do sistema [ANDERSON 81]. Jarbas Silveira 8

9 Classificação das Falhas
-Falhas em um sistema podem resultar de várias e diferentes razões, desde envelhecimento de componentes, a falhas na interação do homem com computador Por este motivo, é comum se classificar as falhas de acordo com suas origens. Avizienis [AVIZIENIS 71] classifica as falhas em três grupos : falhas de projeto, falhas de interação e, falhas físicas. Jarbas Silveira 9

10 Classificação das Falhas
Falhas de projeto podem ser devido a : - especificações erradas, ambíguas, ou incompletas; - enganos cometidos durante a tradução de uma especificação na implementação final. Embora as falhas resultando de erros de projeto possam ocorrer tanto a nível de hardware, quanto a nível de software, estas últimas são mais predominantes e difíceis de se eliminar do sistema [TOY 87] na série Apollo de missões lunares, resultaram de erros de projeto no software. Outro exemplo de missão espacial se refere a sonda espacial Mariner I. Em 28 de Julho de 1962, esta sonda foi lançada do Cabo Canaveral em direção ao planeta Vênus. Após 100 dias, a sonda deveria começar a circular o planeta e coletar dados relacionados com ele. Entretanto, somente poucos minutos após ter sido lançada, a Mariner I mergulhou no oceano Atlântico. Mais tarde foi descoberto que a causa do desastre foi devido a um sinal menos que foi omitido das instruções do programa de controle da nave [PILE 89]. Em 1971, durante um experimento meteorológico francês, 72 balões atmosféricos (de 141) explodiram devido a uma falha no software que controlava o experimento [ANON 71]. Jarbas Silveira 10

11 Classificação das Falhas
Falhas de iteração são causadas por: - Ações não apropriadas do operador Uma forma de reduzir o número de ocorrências de tais falhas é fornecer treinamento extensivo tanto para o pessoal de operação como manutenção. Outra forma de atingir esse objetivo poderia ser o uso extensivo de interfaces homem-máquina que fossem de fácil uso (“user-friendly”) [TOY 87]. Jarbas Silveira 11

12 Classificação das Falhas
Falhas físicas geralmente resultam do envelhecimento dos componentes e, portanto, estão associadas com o hardware do sistema. Elas podem ser classificadas por : duração, valor, ou extensão [AVIZIENIS 78]. A duração está relacionada com o fato da falha ser, transiente ou permanente. Jarbas Silveira 12

13 Classificação das Falhas
Valor se refere a se a falha leva as variáveis assumirem um valor determinado ou indeterminado. - No primeiro caso, também conhecida como “colado em” (“stuck-at”), a variável é levada a assumir um valor lógico constante “1” ou “0” No segundo caso, o efeito da falha sobre a variável é tal que seu valor se alterna entre dois valores, mas não em um modo especificado na especificação original. Jarbas Silveira 13

14 Classificação das Falhas
A extensão de uma falha é determinada pelo fato de se os erros provocados por ela são locais ou distribuídos. - Falhas locais afetam somente componentes de uma única variável lógica, enquanto falhas distribuídas afetam duas ou mais variáveis lógicas, um subsistema, ou o sistema [AVIZIENIS 78]. Jarbas Silveira 14

15 Classificação das Falhas
De um modo geral, erros causados por falhas no hardware são mais fáceis de antecipar que aqueles causados por falhas no software. Jarbas Silveira 15

16 Classificação das Falhas
análise dos históricos de falhas para se identificar “tendências” (26R Space Shuttle-Relatório da Comissão Roger): - Criticalidade 1 - Problemas que poderiam resultar em perda de vida ou do veículo; - Criticalidade 2 - Problemas que poderiam criar um perigo real ou em potencial que poderiam levar a perda da carga da missão ou de toda missão, ou ainda em risco à tripulação; - Criticalidade 3 - Problemas que poderiam criar um retardo real ou em potencial da missão; - Criticalidade 4 - Defeitos “cosméticos” e/ou não funcionais, ou defeitos que sejam imediatamente reparáveis, sem nenhum impacto no tempo de execução da missão. O 26R foi o primeiro Space Shuttle lançado após o acidente do Challenger (Janeiro de 1986), e deu origem ao Relatório da Comissão Roger. Este relatório chamou a atenção para a necessidade de se efetuar uma completa análise dos históricos de falhas para se identificar “tendências” de desempenho adverso. Análise de Tendências é a técnica que agrupa dados de algum modo que revela ou realça padrões onde possíveis problemas podem existir [FLORES 91]. No estudo apresentado por Flores et Al (veja referência acima), os relatórios de problemas foram revistos e uma “designação de criticalidade” foi feita, resultando no estabelecimento dos seguintes níveis de criticalidade de problema : Jarbas Silveira 16

17 Distribuição de relatórios de problemas (287 eventos)
Classificação das Falhas Distribuição de relatórios de problemas (287 eventos) Jarbas Silveira 17

18 Classificação das Falhas
-A experiência anterior mostra a importância de se coletar dados relacionados com eventuais problemas que o sistema possa experimentar (comunicação de problemas). Essa informação pode ser usada a fim de corrigir imperfeições no projeto, deste modo aumentado sua confiabilidade (esta estratégia é largamente empregada pelos engenheiros de controle de qualidade em sistemas comerciais). Jarbas Silveira 18

19 Prevenção de Falhas -Na técnica de prevenção de falhas, também conhecida como Intolerância à Falhas , todos os esforços são concentrados na eliminação de todas as possíveis fontes de falhas antes que o sistema entre em operação. - Componentes altamente confiáveis são usados no projeto; Uma blindagem eficaz é utilizada, e testes exaustivos são feitos na esperança de se eliminar todas as falhas. Assim, o sistema funcionará apropriadamente (de acordo com suas especificações), contanto que nenhuma falha ocorra. Jarbas Silveira 19

20 Prevenção de Falhas - Embora esta técnica seja relativamente fácil de implementar, ela tem empecilhos quando usada isoladamente O sistema só irá operar de acordo com suas especificações somente quando estiver livre de erros - O pessoal de manutenção terá que estar de plantão para eventuais interrupções de funcionamento - Tais restrições podem ser inaceitáveis para sistemas que estejam localizados em lugares de difícil acesso para manutenção (p.ex. naves espaciais não tripuladas) Por estas razões, prevenção de falhas é usada conjuntamente com tolerância à falhas. Jarbas Silveira 20

21 Tolerância à Falhas - Nesse caso, o projetista vê o sistema de um modo mais realístico, considerando as falhas como eventos normais que devem ser tratados. Um sistema (de computador) tolerante à falhas é aquele que, sem nenhuma intervenção manual, é capaz de lidar com falhas operacionais e de projeto, e de manter o desempenho do sistema dentro de suas especificações. Jarbas Silveira 21

22 Tolerância à Falhas - Estratégia mais comum: Redundância - Redundância a nivel de software, hardware e tempo - O uso de recursos redundantes empregados em tais sistemas não tem como objetivo aumentar o desempenho deles, como no caso, por exemplo, quando múltiplos processadores são usados para aumentar a velocidade de processamento de dada certa computação. De fato, de um modo geral, a computação em sistemas redundantes pode acabar sendo mais lenta (!) Jarbas Silveira 22

23 Tolerância à Falhas -A redundância em sistemas tolerantes à falhas podem ser classificadas em : hardware, software, e tempo. - Poderia ser dito, entretanto, que o uso de um tipo de redundância pode levar ao uso de outros tipos. Na redundância de software, por exemplo, o programa de controle faz uso tanto do espaço de memória (hardware), como de execução (tempo) [TOY 87]. Jarbas Silveira 23

24 Tolerância à Falhas Redundância de Hardware A redundância de hardware consiste do uso de circuitos extras para detectar e corrigir erros e pode ser dividido em dois tipos : estática e dinâmica. Jarbas Silveira 24

25 Tolerância à Falhas Redundância de Hardware Estática Na redundância estática (ou “mascaramento”), componentes adicionais são usados para mascarar os efeitos de uma falha (isto é normalmente conseguido através do uso de componentes “em paralelo”). Jarbas Silveira 25

26 Tolerância à Falhas Redundância de Hardware Estática - Seu uso em sistemas reparáveis pode vir a ser indesejável, uma vez que o processo de isolamento do componente falho teria que contar com outros mecanismos para localizá-la. - Entretanto, porque a falha não é “sentida” pelo sistema, esta técnica pode ser muito atrativa em aplicações em tempo real com requerimentos de tempo muito exigentes, uma vez que não seria necessário se gastar tempo no processo de detecção e isolamento da falha. Jarbas Silveira 26

27 Tolerância à Falhas Redundância de Hardware Estática - Um exemplo típico do uso deste tipo de redundância é a Redundância Modular Tripla (TMR - “Triple Modular Redundancy”). M1 M2 M3 votador Uma extensão dos sistemas TMR consiste da redundância modular n-upla (NMR - N-uple Modular Redundancy), mostrada na figura Neste caso, existem (2n+1) módulos redundantes e, pelo menos (n+1) módulos são requeridos para concordar em um resultado (assim, esta estrutura é capaz de tolerar n falhas). O computador de bordo do ônibus espacial (Shuttle) faz uso de uma estrutura NMR; cinco computadores (IBM) são usados, com quatro deles operando como um sistema redundante quádruplo e executando operações críticas, e o quinto computador sendo usado em tarefas não críticas [ZOPPETE 85]. Um outro exemplo de redundância estática é o uso de códigos de correção de erros em unidades de memória, onde é feito o uso adicional de hardware e informação (p.ex. , códigos de correção Hamming). Algumas pastilhas de memória não precisam nem mesmo de um hardware adicional para esse propósito; Stapper et al descreve em [STAPPER 91] uma pastilha de memória de 16 Mbits que tem circuitos redundantes e circuitos que implementam códigos de correção. Jarbas Silveira 27

28 Redundância de Hardware Estática
Tolerância à Falhas Redundância de Hardware Estática M1 M2 Vota Mn M3 Redundância N-modular (NMR) Jarbas Silveira 28

29 Tolerância à Falhas Redundância de Hardware Dinâmica Em contraste com a redundância estática, nesta técnica, (também conhecida como redundância seletiva), os módulos redundantes existem em um modo “stand-by” e podem substituir um módulo falho, automaticamente ou manualmente, pelo módulo reserva selecionado, que pode está ativo (ligado) ou passivo (desligado). Jarbas Silveira 29

30 Redundância de Hardware Dinâmica
Tolerância à Falhas Redundância de Hardware Dinâmica M1 M2 saída Mn M3 Em um sistema Stand-by, um dos n módulos é usado para fornecer a saída do sistema e n-1 módulos são usados como cópias. Jarbas Silveira 30

31 Tolerância à Falhas Redundância de Hardware Dinâmica - A falha tem que ser primeiramente detectada, uma vez que ela não é mascarada. - Se uma falha é detectada, um procedimento de diagnóstico deve ser executado a fim de localizar quais os módulos que estão falhos, antes de substituí-los. - Note que o tempo entre a detecção da falha e a substituição de um módulo falho por um reserva pode ser considerável (especialmente se o módulo reserva é passivo), e isto pode não ser tolerável em algumas aplicações em tempo real. Jarbas Silveira 31

32 Tolerância à Falhas Redundância de Software Redundância de software é usada para ajudar o sistema a superar tanto falhas de hardware como de software. Ela consiste de programas e instruções extras tanto em macro como micro níveis [TOY 87]. Existem dois tipos de redundância de software : estática e dinâmica. Jarbas Silveira 32

33 Tolerância à Falhas Redundância de Software Estática Na redundância de software estática, programas replicados são executados concorrentemente em máquinas separadas e seus resultados são comparados numa base de “a maioria vence” (uma versão software de um TMR). Jarbas Silveira 33

34 Tolerância à Falhas Redundância de Software Dinâmica Na redundância de software dinâmica, uma cópia do estado de um módulo é salva, periodicamente, em alguns pontos do programa, conhecidos como pontos de checagem (“checkpoints”), durante a operação do sistema. A recuperação de um erro é alcançada retrocedendo a execução do programa (“rolling back”) para o último ponto de checagem. Jarbas Silveira 34

35 Tolerância à Falhas Redundância de Tempo Neste caso a redundância é implementada através da repetição de operações e é normalmente usada para detectar falhas transientes [LALA 85]. Exemplos desta técnica são : re-execução (“rollback”) de instruções, segmentos de programas ou programas inteiros, e o re-envio de mensagens em um sistema distribuído. Jarbas Silveira 35

36 Tolerância à Falhas Redundância de Tempo Em operações “rollback”, a re-execução de programas começa de pontos pré-definidos em um programa, conhecidos como pontos de checagem (“checkpoints”), onde o status do programa e toda informação necessária para uma recuperação bem sucedida é armazenada. O JPL-STAR [AVIZIENIS 71] e o computador Non-Stop Tandem [KATZMAN 78] são exemplos de sistemas que fazem extensivo uso desta técnica. Jarbas Silveira 36

37 Estratégias de Tolerância à Falhas
Um sistema tolerante à falhas deve executar uma seqüência de passos, (que incluem detecção e recuperação), após a ocorrência de uma falha. O número e tipo de passos podem depender do tipo de redundância a ser empregada. Existem, entretanto, quatro passos básicos que iremos descrever agora : - Detecção de Erros; - Confinamento e Avaliação de Danos; - Recuperação de Erros; - Tratamento da Falha e Continuação do Serviço. Jarbas Silveira 37

38 Estratégias de Tolerância à Falhas
Detecção de Erros: Este é o ponto de partida para qualquer técnica de tolerância à falhas com alguma chance de ser bem sucedida. De um modo geral, quanto mais detecção de erros em um sistema, mais confiável ele será. Não é prático, entretanto, equipar o sistema com um grande número de facilidades para detecção de erros, sobretudo devido ao custo e “overheads” impostos por extensivas checagens. Jarbas Silveira 38

39 Estratégias de Tolerância à Falhas
Detecção de Erros: O sistema não deve ter nenhum ponto comum de falhas relacionado com seu checador e, idealmente, ele (checador) deveria ser projetado por uma diferente equipe de projetistas. Anderson e Lee [ANDERSON 81] dão três critérios que balizam o projeto de um checador ideal: 1. Ele deveria ser derivado tão somente das especificações do sistema; 2. Ele deveria ser capaz de fazer uma completa checagem do sistema; 3. Ele deveria ser independente do sistema. Jarbas Silveira 39

40 Estratégias de Tolerância à Falhas
Detecção de Erros: Duas principais estratégias podem ser usadas, no que se refere a quando a checagem deveria ser feita. – Last-moment checks – Early check Na prática, entretanto, uma combinação das duas estratégias acima deveriam ser usadas para se atingir uma boa cobertura de falhas. Jarbas Silveira 40

41 Estratégias de Tolerância à Falhas
Detecção de Erros: Enquanto as técnicas de detecção de erros podem variar de sistema para sistema, a maioria delas pode ser situadas em uma das seguintes [ANDERSON 81] : - Checagem por Replicação - Checagem por temporização - Checagem por Codificação - Checagem por Reversão - Checagem por Consistência - Checagem por Diagnóstico - Checagem por Sequência de Controle Jarbas Silveira 41

42 Estratégias de Tolerância à Falhas
Checagem por Replicação Consiste da replicação da atividade do sistema que está sendo checada e é uma das mais completas medidas para se detectar erros em um sistema de computador [ANDERSON 81]. É normalmente usada a fim de se detectar falhas no hardware, e pode ser implementada tanto a nível de circuito como a nível de subsistema. Apesar de ser uma técnica relativamente cara, está se tornando praticável, em termos de custos, para aplicações que têm grandes requisitos de confiabilidade, devido aos rápidos avanços nas tecnologias de VLSI e microprocessadores [TOY 87]. Jarbas Silveira 42

43 Checagem por Replicação
Estratégias de Tolerância à Falhas Checagem por Replicação “Matching Circuits” usados no sistema de comutação ESS da AT&T Jarbas Silveira 43

44 Estratégias de Tolerância à Falhas
Checagem por temporização Checagem por Temporização é particulamente eficaz na detecção de erros no software em programas replicados [TOY 87]. Aqui, a execução de uma operação não deve exceder um tempo máximo pré-determinado, caso contrário um exceção de “timeout” (“tempo ultrapassado”) é levantada para indicar que um defeito ocorreu. Jarbas Silveira 44

45 Estratégias de Tolerância à Falhas
Checagem por temporização Esta técnica é normalmente associada com o uso de um temporizador, que pode ser implementado tanto por hardware como por software. Quando um temporizador hardware é utilizado, ele é chamado de temporizador “cão de guarda” (“watchdog timer”) e tem que ser periodicamente “resetado”pelo programa. Caso este temporizador não “resete” (atualize) o temporizador (devido a, por exemplo, um laço infinito no programa, ou um problema qualquer no software e/ou hardware), ele irá levantar uma exceção. Jarbas Silveira 45

46 Estratégias de Tolerância à Falhas
Checagem por Codificação Esta técnica usa uma representação redundante de objetos como forma de detectar erros. Esta representação mantém um relacionamento fixo com a representação original (não redundante) do objeto, e uma exceção será levantada se este relacionamento não existir mais, como resultado de um erro [ANDERSON 81]. Jarbas Silveira 46

47 Estratégias de Tolerância à Falhas
Checagem por Codificação O exemplo mais comum de checagem por codificação é o uso de checadores de paridade, onde um bit de paridade está associado com um número de bits (normalmente uma palavra), e seu relacionamente é tal que a soma módulo 2 de todos os bits é ou 0 (zero), paridade par, ou 1 (um), paridade ímpar. Jarbas Silveira 47

48 Estratégias de Tolerância à Falhas
Checagem por Reversão A Checagem por Reversão envolve o cálculo de qual deveria ser a entrada para uma computação, baseado em uma saída (já obtida) para aquela mesma computação, e posterior comparação daquela entrada com a entrada original. Jarbas Silveira 48

49 Estratégias de Tolerância à Falhas
Checagem por Reversão Ela é somente factível quando o relacionamento entre as entradas e saídas é na base de uma para uma. Estes tipos de checagens podem ser usados, com grande eficiência, em sistemas onde funções matemáticas estão envolvidas (no relacionamento de entrada com saída), embora margem para discrepâncias deve ser aceita quando operações em ponto flutuante são usadas. Jarbas Silveira 49

50 Estratégias de Tolerância à Falhas
Checagem por Consistência Nesta técnica um teste é feito para checar se o estado das variáveis no sistema é “razoável”, baseado no conhecimento prévio de suas características. Por exemplo, se o resultado de uma dada computação não pode resultar em valores negativos, uma checagem por consistência poderia ser usada para levantar uma exceção caso um valor negativo fosse obtido como resultado. Jarbas Silveira 50

51 Estratégias de Tolerância à Falhas
Checagem por Diagnóstico Checagem por diagnóstico também usa um conhecimento prévio de partes do sistema. Entretanto, nesta técnica, uma checagem é feita nos componentes do sistema, e não no seu comportamento (como na checagem por consistência). Nesse sentido, a checagem por diagnóstico usa o conhecimento prévio das saídas dos componentes para todas as possíveis entradas, de modo a compará-las com as saídas resultantes da estimulação dos componentes com algum conjunto pré-definido de entradas. Jarbas Silveira 51

52 Estratégias de Tolerância à Falhas
Checagem por Sequência de Controle Esta técnica é basicamente relacionada com detecção de erros no software e é baseada em técnicas que checam o sistema para qualquer desvio de uma sequência de execução especificada. Uma falha relacionada com este tipo de erro é chamada uma falha de controle (“control fault”) e pode causar as seguintes conseqüências [TOY 87] : - execução infinita de um laço; - execução de um laço de programa em um número incorreto de vezes; - desvio ilegal ou errado. Jarbas Silveira 52

53 Estratégias de Tolerância à Falhas
Checagem por Sequência de Controle Tres tipos de técnicas podem ser usadas para lidar com falhas de controle : checagem de desvios permitidos , esquema do “passador de bastão (“relay-runner”), e o uso combinado do “watchdog timer” e do esquema do passador de bastão. Jarbas Silveira 53

54 Estratégias de Tolerância à Falhas
Checagem por Sequência de Controle Checagem de desvios permitidos consiste na detecção da execução de uma operação de desvio inapropriada [GALLAHER 81] e um exemplo do uso desta técnica pode ser achado no sistema de comutação eletrônica da AT&T. Nesse esquema, um bit de desvio-permitido está associado com cada palavra na memória principal, e é usado para indicar se uma posição de memória pode ou não ser usada por qualquer instrução de desvio. Jarbas Silveira 54

55 Estratégias de Tolerância à Falhas
Checagem por Sequência de Controle O esquema do passador de passador de bastão [RAMAMOORTHY 74] pode ser usado também como um meio de detecção de execução ilegal de “jumps”. Nesse esquema, códigos pré-definidos ou bastões (similares a senhas), são associados com cada transferência de controle e são checados em pontos apropriados. Jarbas Silveira 55

56 Estratégias de Tolerância à Falhas
Checagem por Sequência de Controle O esquema que consiste da combinação “watchdog timer” e “relay runner”, é usado a fim de detectar laços infinitos em um programa e falhas na estrutura de sequência de controle de um programa [KRAFT 81]. O temporizador (“timer”) levantará um exceção de “timeout” caso o programa não se apresente apropriadamente (por exemplo, se um número especificado de pontos de checagem não tenham sido atravessados em uma dada ordem e dentro de um dado período). Jarbas Silveira 56

57 Estratégias de Tolerância à Falhas
Confinamento e Avaliação de Danos: As técnicas discutidas na última sessão fornecem ao sistema a capacidade de detectar os efeitos de uma falha (isto é, o erro). Entretanto, mesmo se o mecanismo de detecção fosse perfeito (todos os erros fossem detectados), haveria ainda um período de tempo decorrido entre o momento em que a falha ocorreu e o momento em que o erro foi detectado (este tempo é geralmente referido com latência da falha). Jarbas Silveira 57

58 Estratégias de Tolerância à Falhas
Confinamento e Avaliação de Danos: Um conceito útil para organizar um sistema a fim de facilitar o confinamento dos danos é o da ação atômica [LOMET 77]. A atividade de um elemento constitui uma ação atômica se não existem interações entre aquele elemento e o resto do sistema por toda duração da atividade [ANDERSON 81]. Jarbas Silveira 58

59 Estratégias de Tolerância à Falhas
Recuperação de Erros: As discussões apresentadas nas duas sessões anteriores não se preocuparam com a alteração do sistema após a ocorrência de uma falha. Uma vez que um erro é detectado, esforços devem ser feitos a fim de trazer o sistema de volta para um estado operacional ou, em outras palavras, fazer o sistema recuperar-se dos erros. Jarbas Silveira 59

60 Estratégias de Tolerância à Falhas
Recuperação de Erros: O método de recuperação de erro usado pode ser influenciado pela técnica de detecção de erros utilizada. Em sistemas que usam as técnicas de mascaramento de falhas (p.ex, sistemas TMR), a detecção e a recuperação de erros ocorrem simultaneamente. Esses sistemas não necessitam incorporar todos os passos relacionados com sistemas tolerantes à falhas mencionados anteriormente, por razões óbvias. A ação de recuperação de erro envolve o uso de algoritmos de recuperação que podem (ou não) requerer decisões humanas. Jarbas Silveira 60

61 Estratégias de Tolerância à Falhas
Recuperação de Erros: A primeira classe de algoritmos é dita de automática , ao passo que o segundo caso é dita controlada manualmente. Algoritmos de recuperação automática podem ser classificados, de acordo com o estado do sistema após a ação de recuperação, como : recuperação completa, recuperação com degradação, e desligamento seguro (“safe shutdown”) [AVIZIENIS 78]. Jarbas Silveira 61

62 Estratégias de Tolerância à Falhas
Recuperação de Erros: Recuperação completa tenta deixar o sistema com a mesma capacidade de hardware e software que existia antes da ocorrência da falha. Isto é alcançado usando-se chaveamento automático dos módulos falhos (reconfiguração) e substituido-os por cópias “sadias”. Jarbas Silveira 62

63 Estratégias de Tolerância à Falhas
Recuperação de Erros: Na recuperação com degradação, também conhecida como degradação progressiva (“graceful degradation” ou “fail-soft operation”) [LALA 85], os módulos falhos são também isolados, como no método anterior, entretanto, não existem cópias disponíveis e portanto o sistema irá prosseguir de uma forma degradada. Jarbas Silveira 63

64 Estratégias de Tolerância à Falhas
Recuperação de Erros: Desligamento seguro (“safe shutdown” ou “fail-safe operation”), é o caso limite de uma recuperação com degradação [TOY 87]; nesse caso o sistema não é mais capaz de fornecer a computação requerida porque todas as cópias foram utilizadas em tentativas anteriores de recuperação, ou o número de cópias sobreviventes não pode dar conta da computação requerida. Jarbas Silveira 64

65 Estratégias de Tolerância à Falhas
Tratamento da Falha e Continuação do Serviço: Uma vez que os passos anteriores não asseguram que a falha que provocou o(s) erro(s) seja identificada, outro passo pode ser necessário a fim de evitar que a falha ocorra novamente. Note que um tipo particular de erro poderia ser o resultado de muitas fontes de falhas. Este passo é utilizado para isolar a falha, ou para reconfigurar o resto do sistema, em um esforço para evitar suas manifestações repetidas e, usualmente envolve dois estágios : localização e reparo do sistema. Jarbas Silveira 65