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

(1)

Luís Almeida, EST -IPCB, 2º semestre 2001 1

Sistemas Tolerantes a Falhas

• Tolerância a falhas / defeitos

• Bibliografia

• H. Kopetz, Design Principles for Distributed Embedded Applications, Kluwer Academic Publishers, 1997.

Tolerância a falhas / defeitos

Técnicas para

obtenção de tolerância

Processamento de erros Recuperação

de erros Diagnóstico Passivação

Tratamento de erros Compensação de erros para um estado passado para um novo estado Redundância

(2)

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.

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

(3)

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.

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)

(4)

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.

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

(5)

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.

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%.

(6)

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.

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.

(7)

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 falhado 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.

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

(8)

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.

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.

(9)

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.

Uma FTU em que o nodo base só apresenta falhas do tipo falha-silênciorequer a

utilização de dois nodos. Se um falha o outro continua a responder.

FTU

Nodo de backup

Nodo

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 nodose 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

(10)

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 nodose 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)