Fiabilidade de Sistemas Informáticos

Trabalho realizado por: Clara Dimene nº 15589

Introdução

Confiabilidade e disponibilidade são cada vez mais desejáveis em sistemas de computação;

HW é muito confiável e a sua confiabilidade continua a melhorar ao longo do tempo;

SW não é confiável;

O objectivo principal é o de fazer um sistema crítico tolerante às falhas no software.

As falhas de software são sempre falhas de projecto (design) devido ao design incorrecto ou à presença de “bugs” .

Blocos de Recuperação

São utilizadas N versões diferentes de um software, porém cada uma delas possuindo um mecanismo de detecção de erros independente.

A estrutura, basicamente consiste em três elementos: um módulo primário, que executa funções críticas; um teste de aceitação, que testa a saída do módulo

primário após cada execução; um módulo alternativo

Blocos de Recuperação

ensure <acceptance test >

by <primary module >

else by <alternate module 1>

else by <alternate module 2> …

else by <alternate module n>

else error

Blocos de Recuperação

Para a detecção do erro é necessário um teste de aceitação

Se o teste de aceitação falhar, o processo é restaurado ao estado salvo no momento em que o ponto de recuperação foi estabelecido;

Se a versão primária não passar pelo teste, são testadas as versões alternativas até que uma delas passe no teste.

Se nenhuma das versões testadas passar no teste, ocorre falha no sistema. Ou seja, o método tolera N-1 falhas.

Blocos de Recuperação

Esta técnica utiliza um método de detecção de erros e serve para reconfiguração do sistema, sendo desprezados os resultados obtidos por módulos redundantes, que não passarem nos testes de aceitação.

Blocos de recuperação são melhor aplicados a sistemas com computações muito complexas e propensas a falhas de projecto.

N-Versões

Consiste na implementação de versões redundantes de programas ou funções dentro dos programas, seguido de uma votação para saber qual das respostas, se houver discordância entre os módulos, é a correcta.

As várias versões devem apresentar

diferentes projectos e implementações, partindo de uma mesma especificação;

N-Versões - Exemplo

N-Versões

• Os módulos redundantes podem executar em processadores independentes, ou dividir o mesmo processador sendo executados sequencialmente.

• Não existe interacção entre os grupos

• Deve-se utilizar abordagens distintas para a resolução do problema, ou diferentes linguagens de programação, ou contratar equipes de programadores diferentes para o desenvolvimento de cada módulo

N-Versões

Consequentemente, os erros que venham a existir também serão diferentes, e as falhas não ocorrerão em todos os módulos, ou então ocorrerão em locais diferentes em cada um dos módulos

Pode ser utilizada para detecção e mascaramento de falhas

Devido ao alto custo de implementação, a técnica deve ser utilizada apenas em aplicações muito críticas, de longa vida ou de difícil manutenção.

N-Versões

Vantagens A facilidade no reconhecimento de erros na fase de

teste do sistema, a tolerância tanto a falhas transientes quanto a falhas permanentes e a actuação potencial também contra erros externos ao sistema

Desvantagens O aumento dos custos de desenvolvimento e

manutenção, a complexidade de sincronização das versões e o problema de determinar a correlação das fontes de

erro;

N-Versões

A redundância de elementos de hardware aumenta a confiabilidade do sistema, mas tal prova não existe para a diversidade em software;

Um exemplo de diversidade é o sistema

de computadores de bordo do Space Shutle.

Outros Métodos

Deadline Mechanism (Mecanismo deadline)

Blocos de recuperação distribuídos Diversidade de dados Certification trails (Marcas de

certificação)

Blocos de recuperação distribuídos

Concebidos para evitar as falhas transientes (duração limitada) em Hardware

A ideia base é a de distribuir os blocos de recuperação e os testes de aceitação pelos diferentes módulos e executá-los concorrentemente.

Se o nó primário falhar, este envia um aviso ao nó de backup, que então reencaminha o seu próprio output como output final.

Se o watchdog do nó de apoio estiver fora do limite do tempo de execução,

é usado para representar uma falha do módulo primário. Se o primário produzir resultados que passem no teste de aceitação, estes

são reencaminhados como resultado e é enviado um aviso ao nodo de apoio. Este por sua vez não reencaminha este resultado

Recuperação de erros

Restauro de um sistema ao seu estado normal;

A recuperação pode ser implementada segundo dois princípios conhecidos:

recuperação por avanço (forward recovery)

recuperação por retorno ou por retrocesso (backward recovery)

Recuperação por Retorno

Baseia-se na restauração de um processo para um estado anterior livre de falhas

O rollback é usado nos blocos de recuperação como um método na recuperação de erros.

Algoritmos baseados na recuperação por retorno salvam periodicamente os estados de um processo durante uma execução livre de falhas e, após uma falha, reiniciam a partir do estado mais recente, reduzindo a quantidade de trabalho perdido.

Recuperação por Retorno

Para um sistema comunicante, supõe-se que o teste de aceitação de um processo volta ao estado anterior.

Durante a comunicação entre processos, este retorno precisa que os outros processos voltem ao estado prévio, de modo que o sistema atinga um estado consistente.

Este retrocesso forçado pode causar um efeito chamado efeito dominó.

O efeito dominó surge quando não existe sincronização entre os pontos de recuperação nos diferentes processos e os comandos na comunicação.

Recuperação por Retorno

Conversação é um bloco de recuperação com vários processos actuando, cada um com um ponto de verificação inicial,

Foi proposto como uma extensão aos blocos de recuperação de modo a fornecer uma recuperação por retorno estática, nos processos concorrentes, prevenindo também o efeito dominó

Cada processo que se junta á conversação tem um ponto de recuperação, um teste de aceitação e um algoritmo alternativo e só pode terminar (realizar sua conclusão) por consenso.

Se pelo menos um falhar, todos os outros devem voltar ao estado do início da conversação. Para tal, não podem comunicar-se com processos externos durante a conversação.

Recuperação por Retorno

FT-Action são acções atómicas básicas que são planeadas onde a recuperação e a tolerância á falhas é fornecida.

As FT-Action devem ser concebidas de modo que a atomicidade das FT-Action esteja garantida.

A garantia da atomicidade permite a recuperação durante a programação e deve suportar a recuperação por retrocesso (backward recovery) ou por avanço (forward recovery) do estado da computação.

Para suportar a estrutura de um estado de conversação as FT-Action devem possuir as seguintes propriedades:

Recuperação por Retorno

Atomicidade Uma linha de recuperação para recuperação de erros por

retrocesso Uma linha de teste para os processos Medidas de recuperação

FT-Action aninhadas

Outros métodos usados na recuperação por retorno: Conversação usando monitores FT-Action distribuída

Recuperação por Avanço

Baseia-se na transformação do estado errado, efectuando correcções para remover erros.

Assim o sistema é conduzido a um novo estado, não ocorrido anteriormente, ou a um estado por onde o sistema não passou desde a última manifestação do erro

Num sistema concorrente múltiplos processos executam independentemente mas comunicam-se uns com os outros.

Recuperação por Avanço

O mecanismo para a manipulação de excepção é utilizado no suporte a recuperação por avanço em sistemas concorrentes

Mecanismo para a manipulação de excepção é a estrutura que fornece primitivas da linguagem para

organizar a redundância e executar actividades que suportem a tolerância a falhas.

A manipulação de excepções fornece uma estrutura que suporta o design de software tolerante a falhas, não sendo portanto uma técnica para a tolerância a falhas.

Recuperação por Avanço

As medidas fornecidas dentro do módulo ou os programas para tratar das excepções são chamados exception handlers.

Um handler numa excepção é invocado se essa excepção for

sinalizada.

O handler pode conter um rollback para um estado precedente (recuperação por retrocesso) ou executar acções para corrigir o estado usando outros meios (recuperação por avanço)

As FT – Action são usadas como a estrutura básica para suportar a manipulação de excepção.

Recuperação por Avanço

Com este mecanismo, um sistema pode ser considerado como sendo constituído por vários componentes em que cada componente que é uma FT-Action .

Como no mecanismo de manipulação de excepção, se um componente detectar uma excepção levanta a excepção localmente.

Se uma excepção for sinalizada, está é levantada dentro do componente em que o sinal foi emitido, e a recuperação poderá então ser feita nesse componente.

Conclusão

Software tolerante à falhas é usado para detectar erros de projecto (design);

Estática N-Versões;

Dinâmica Blocos de Recuperação: Recuperação por

retrocesso; Excepções: recuperação por avanço;

Conclusão

Overheads de design – ambos requerem algoritmos alternativos, NV por votação, RB pelo teste de aceitação.

Runtime overhead – (NV) N*recursos , RB tem que estabelecer pontos de recuperação;

Diversidade de design – ambos são susceptíveis a erros durante a execução;

Detecção de erros – por comparação de votos (NV) e pelo teste de aceitação (RB).

Atomicidade – 1º é feita a votação e depois é dada a resposta (NV); a resposta é dada mediante a passagem no teste de aceitação RB;

Conclusão

A técnica de recuperação por retrocesso é mais simples do que a recuperação por avanço, pois é independente do conhecimento do tipo de falha e dos erros causados pela mesma, apresentando por isso alguns problemas tais como:

O custo para restaurar um processo ou sistema a um estado anterior pode ser bastante alto, levando à perda de desempenho, inaceitável em algumas aplicações;

Podem ocorrer falhas durante a execução dos procedimento de retorno;

Podem apresentar problemas em casos onde há manipulação de objectos que não podem ser restaurados.

Conclusão

A recuperação por avanço por outro lado, possui custo menor durante a execução, porque somente aquelas partes do sistema que não atingiram o valor esperado são corrigidas.

Entretanto, mostra-se adequado apenas quando os danos podem ser previstos antecipadamente.

Esta técnica pode ser usada somente para os danos que puderem ser completamente identificados. As situações são particulares a cada caso ( aplicações e danos).