Fiabilidade de Sistemas Informáticos

Apresentação em tema: "Fiabilidade de Sistemas Informáticos"— Transcrição da apresentação:

1 Fiabilidade de Sistemas Informáticos
Trabalho realizado por: Clara Dimene nº 15589

2 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” . Confiabilidade e disponibilidade são cada vez mais desejáveis em sistemas de computação pois dia a dia aumenta a dependência da sociedade a sistemas automatizados e informatizados . Em hardware são falhas físicas ocorridas nos componentes físicos tais como nós e links, chips de memória etc. O software pelo contrário, não tem propriedades físicas porque é uma entidade meramente conceptual. Para construir software capaz de mascarar falhas dos seus componentes, são necessárias técnicas que possam lidar com as tais falhas de design – tais técnicas são conhecidas como software tolerante á falhas.

3 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 Foram propostos por Homing et al [H+74] para fornecer uma aproximação para organizar diversos designs de modo a suportar software tolerante a falhas. O objectivo destes blocos é o de mascarar falhas nalgum módulo Um teste de aceitação é uma asserção1 ao estado do módulo. Se a asserção1 falhar, significa a presença de um erro no estado. Se não, o estado do módulo supostamente está sem erros.

4 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 Um teste de aceitação altamente confiável é essencial a implementação de um módulo de bloco de recuperação. O teste de aceitação deve ser mantido razoavelmente simples, para minimizar a probabilidade que o próprio teste de aceitação conter erros, para garantir uma alta cobertura de detecção de erro. Além disso, o teste de aceitação introduzirá uma sobrecarga ao tempo de execução que pode ser inaceitável se for muito complexo.

5 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. Um teste de aceitação é uma asserção1 ao estado do módulo. Se a asserção1 falhar, significa a presença de um erro no estado. Se não, o estado do módulo supostamente está sem erros. Embora cada uma das alternativas dentro de um bloco de recuperação empreende satisfazer o mesmo teste de aceitação, não há nenhuma exigência de que elas todas devam produzir os mesmos resultados . A única reserva é que os resultados devem ser aceitáveis, como determinado pelo teste. Assim, enquanto a alternativa primária deveria tentar produzir o resultado desejado, alternativa adicional só pode tentar fornecer um serviço degradado.

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

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

8 N-Versões - Exemplo A aplicação da técnica não leva em conta se erros em programas alternativos apresentam a mesma causa (por exemplo: falsa interpretação de uma especificação ou uma troca de um sinal numa fórmula). Os erros, para poderem ser detectados, devem necessariamente se manifestar de forma diferente nas diversas alternativas, ou seja, devem ser estatisticamente independentes

9 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

10 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. A técnica de programação N-versões pode ser utilizada em todas as fases do desenvolvimento de um programa, desde sua especificação até o teste, dependendo do tipo de erro que se deseja detectar (erro de especificação, de design, ou de implementação)

11 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;

12 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. Esta técnica é chamada de design diversificado quando o desenvolvimento do sistema é realizado de forma diversificada e de programação em N-versões quando se restringe à implementação do sistema. Pode ser também usada como técnica de prevenção de falhas. Neste último caso, várias alternativas de design ou de implementação são desenvolvidas para que, na fase de teste, erros eventuais possam ser localizados e corrigidos de uma forma mais simples e efectiva. No final da fase de teste, é então escolhida a alternativa em que se detectou a menor ocorrência de erros, e apenas esta alternativa é integrada ao sistema

13 Outros Métodos Deadline Mechanism (Mecanismo deadline)
Blocos de recuperação distribuídos Diversidade de dados Certification trails (Marcas de certificação) Embora os blocos de recuperação e a programação com N-versões sejam as técnicas mais conhecidas para suportar software tolerante a falhas, outras técnicas evoluíram com o tempo e podem servir nalgumas situações especiais.

14 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 Falhas Transientes - São aquelas de duração limitada, causadas por mal funcionamento temporário ou por alguma interferência externa. Tais falhas podem ser também intermitentes, ocorrendo repetidamente por curtos intervalos de tempo. Combinam a ideia dos blocos de recuperação com processos distribuídos de modo a obter resultados desejados.

15 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) Por exemplo, um processo falhou após ter modificado parcialmente uma base de dados (sem concluir a operação), então é importante que todas as modificações feitas na base de dados pelo processo falhado sejam desfeitas. Por outras palavras, se o processo executou durante algum tempo antes de falhar, a melhor opção é executar novamente o processo desde o ponto onde ocorreu a falha e retornar à execução

16 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. É um método simples para o suporte a tolerância a falhas contra as falhas de design no software para os sistemas concorrentes. Em sistemas concorrentes, as falhas são na maior parte das vezes transitórias, em relação aos sistemas uniprocessadores, isto quer dizer que as falhas de software ocorrem somente em algumas situações, mas se o software for executado de novo, isso já não provoca a falha, mas em outras situações que não é este o caso as falhas no software podem ser permanentes.

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

18 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. O início da conversação é marcado pelo estabelecimento de uma linha de recuperação que servirá como referência do ponto de partida de uma eventual recuperação de estados dos processos participantes. No final, uma linha de teste estabelece um limite no qual cada processo deverá passar pelo teste de aceitação

19 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:

20 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

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

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

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

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

25 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;

26 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;

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

28 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).