Técnicas para obtenção de Tolerância a Falhas

Transcrição

1 Técnicas para obtenção de Tolerância a Falhas Tolerância a falhas / defeitos Bibliografia H. Kopetz, Design Principles for Distributed Embedded Applications, Kluwer Academic Publishers, Tolerância a falhas / defeitos Técnicas para obtenção de tolerância Processamento de erros Tratamento de erros Recuperação de erros Compensação de erros Diagnóstico Passivação para um estado passado para um novo estado Redundância 2 1

2 Detecção de erros Um aspecto fundamental para obter tolerância a falhas é a detecção eficiente de erros Isso requer conhecimento dos estados do sistema: Estado actual Estado correcto desejado Neste contexto, um erro é uma discrepância entre aqueles dois estados. 3 Detecção de erros As técnicas usuais podem dividir-se em 3 grupos consoante sejam baseadas em: Conhecimento apriorístico Cálculos redundantes Dupla execução de tarefas 4 2

3 Detecção de erros Técnicas baseadas em conhecimento apriorístico Usam características pré-conhecidas das grandezas associadas a cada estado do sistema (Domínio lógico) Conhecimento sintáctico sobre o espaço de codificação e.g. Bits de paridade, Somas de controlo, CRCs, i.e., códigos de detecção de erros, eventualmente com correcção. Usa-se muito em transmissão de informação. Verificação de plausabilidade e.g. Comparação das grandezas medidas, tais como valores de entrada ou resultados de cálculos, com gamas de validade préestabelecidas. 5 Detecção de erros Técnicas baseadas em conhecimento apriorístico (Domínio temporal) Padrões de activação de procedimentos e.g. Medição da periodicidade de activação de uma dada função e comparação com o respectivo período especificado. Verificação do tempo de execução de tarefas e.g. Medição do tempo de execução efectivo de cada instância da tarefa (cada activação) e comparação com determinados limites pré-estabelecidos (como máximo WCET, e/ou mínimo) 6 3

4 Detecção de erros Técnicas baseadas em cálculos redundantes Redundância temporal e.g. 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). Redundância de hardware e.g. Um determinado programa é executado simultâneamente em múltiplos controladores e as respectivas saídas comparadas. Este método permite detectar defeitos físicos quer transientes quer permanentes. 7 Detecção de erros Técnicas baseadas em cálculos redundantes Redundância de software: Software diverso sobre o mesmo hardware e.g. Uma função que é escrita por pessoas diferentes, sendo as múlitplas versões executadas em sequência no mesmo controlador. Permite detectar defeitos de software e defeitos físicos transientes. Software diverso sobre múltiplo hardware e.g. Tal como no caso anterior mas em que as múltiplas versões da função são executadas em controladores diferentes. Permite detectar defeitos de software e físicos, quer transientes quer permanentes. 8 4

5 Detecção de erros Réplicas determinísticas A redundãncia de hardware exige a utilização de réplicas determinísticas. Uma réplica de um dado equipamento diz-se determinística se, na ausência de erros e em cada instante, a respectiva saída dá um valor que não difere da do equipamento principal mais do que um certo valor residual pré-estabelecido. e.g. Considere um sistema que gera uma sequência infinita de números. Uma réplica determinística desse sistema gerará, nos mesmos instantes, exactamente os mesmos números. 9 Detecção de erros Técnicas baseadas na dupla execução de tarefas (caso específico de redundância temporal) Consistem em executar (tentar executar) a mesma tarefa duas vezes para cada instância. Permitem a detecção de erros causados por defeitos físicos transientes Garantindo tempo para as duas execuções da tarefa em todas as respectivas activações (inclusivé no pior caso), pode-se conseguir uma taxa de detecção de erros acima de 99,9%. 10 5

6 Tolerância a falhas Confome referido anteriormente, a redundância de hardware permite evitar que falhas de componentes causem uma falha do sistema global (compensação de erros). O número de réplicas por componente (incluíndo o próprio) depende do número (k) de falhas que se pretende tolerar e do respectivo tipo: k+1 componentes para falhas do tipo falha-silêncio 2*k+1 componentes para falhas do tipo falha-consistente 3*k+1 componentes para falhas maliciosas. 11 Tolerância a falhas As técnicas de tolerância a falhas podem ser aplicadas a dois níveis: Ao nível da arquitectura, i.e., de forma transparente para a aplicação (Tolerância a Falhas Sistemática) Ao nível da aplicação, i.e., inseridas no código específico da aplicação (Tolerância a Falhas Específica da Aplicação) A tolerância a falhas sistemática permite aliviar a complexidade da aplicação, transferindo-a, no que diz respeito áquele aspecto, para hardware e software de sistema adicionais. 12 6

7 Nodo como unidade de falha Num sistema distribuído cada nodo constitui um elemento com fronteiras bem definidas, que fornece um serviço através de um interface também bem definido. Pode-se então falar de um nodo como uma unidade de falha do sistema, i.e., ou está operacional ou não, do ponto de vista do serviço que fornece. Por sua vez, a redundância pode ser aplicada ao nível de nodo, i.e., a replicação de hardware ser feita usando o nodo como unidade. 13 Nodo como unidade de falha Exemplos de técnicas relacionadas com tolerância a falhas em sistemas distribuídos e baseadas em nodos como unidades de falha: Controlo de presença (membership services) Serviços que permitem saber quais os nodos que se encontram operacionais, e.g., através da activação periódica de um bit num determinado registo. Gestão da redundância Serviços que efectuam a detecção de discrepâncias entre as saídas de nodos replicados e controlam a entrada e saída de funcionamento das réplicas. 14 7

8 Nodo como unidade de falha Aspectos a ter em conta ao nível de cada nodo: Definição de um nível mínimo de serviço Fasquia que define a separação entre os estados operacional e de falha para cada nodo. Detecção de erros no interior do nodo Os erros internos devem ser detectados e mapeados num único modo de falha externo, i.e., falha-silêncio. Cuidados a ter com tratamento de excepções A detecção de erros leva, normalmente, à execução de exception handlers cujo tempo de execução tem se ser contabilizado. 15 Unidades tolerantes a falhas A incorporação de técnicas de tolerância a falhas ao nível do nodo leva à criação de unidades tolerantes a falhas. (FTUs Fault-Tolerant Units) Estas unidades desempenham a mesma funcionalidade do nodo base, prestam os mesmos serviços, mas estão dotadas de serviços suplementares que lhe conferem um certo nível de tolerância a falhas. De um ponto de vista macroscópico, cada FTU é como um simples nodo do sistema, apenas com uma taxa de falha mais baixa devida às situações de falha que são toleradas. 16 8

9 Unidades tolerantes a falhas Tolerência a uma falha do tipo falha-silêncio Estas são falhas em que o nodo ou produz um valor temporalmente e logicamente correcto ou simplesmente omite a saída. FTU Nodo Uma FTU em que o nodo base só apresenta falhas do tipo falha-silêncio requer a utilização de dois nodos. Se um falha o outro continua a responder. Nodo de backup 17 Unidades tolerantes a falhas Tolerência a uma falha do tipo falha-pára ou falha-consistente Estas são falhas em que o nodo, após uma falha, pode continuar a produzir um valor errado mas consistente, i.e., uma saída de valor constante. Uma FTU em que o nodo base pode apresentar falhas do tipo falha-pára ou falha-consistente requer a utilização de três nodos e um mecanismo de votação para eleger de entre as três saída a que está correcta (uma estará errada e duas estarão correctas). (TMR Triple Modular Redundancy) FTU Nodo votação 18 9

10 Unidades tolerantes a falhas Tolerência a uma falha do tipo falha-inconsistente (maliciosa ou bizantina) Estas são falhas em que o nodo, após uma falha, pode continuar a produzir valores errados e inconsistentes, i.e., uma saída de valor variável. Uma FTU em que o nodo base pode apresentar falhas do tipo falha-inconsistente requer a utilização de quatro nodos e um protocolo adequado que permita determinar qual o nodo que está a produzir o valor errado. Este protocolo requer a troca de mensagens entre todos os nodos da FTU, com os valores das respectivas saídas. (Byzantine-Resilient Agreement Protocol) 19 FTU nodo 10