Fiabilidade de Sistemas Informáticos Trabalho realizado por: Clara Dimene nº 15589.
Transcript of Fiabilidade de Sistemas Informáticos Trabalho realizado por: Clara Dimene nº 15589.
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).