230 likes | 349 Views
Recovery Blocks. Paulo Junior Penna Pivetta. Introdução. Os Projetos de Tolerância a falhas quase que exclusivamente eram dedicado a hardware
E N D
Recovery Blocks Paulo Junior Penna Pivetta
Introdução • Os Projetos de Tolerância a falhas quase que exclusivamente eram dedicado a hardware • Tolerância em hardware é composta de estruturas que continuam a funcionar apesar de falhas de módulos ou componentes internos sejam elas permanentes ou transientes • As falhas de softwares se tornam cada vez mais presentes com o aumento do tamanho e complexidade dos sistemas de softwares
Introdução² • A freqüência de erros, reflete quanto maior é a complexidade da lógica de um projeto de software típico quando comparado a um projeto de hardware • É mais simples garantir a validação de uma projeto de hardware a um projeto de software • Existindo assim a necessidade de um projeto com um sistema altamente “reliable”, através de um serviço confiável tanto na presença de falhas de hardware como e/ou erros de softwares.
Tolerância a Falha • “Toda tolerância a Falha deve ser baseada na prestação de redundância útil, tanto para detecção de erro como recuperação de erro” - BRIAN RANDELL • Por isso para tolerância a falhas em software, foi desenvolvido uma solução análoga a de projetos de hardwares • A medida que o sistema funciona é checado os resultados gerados por cada componente
Tolerância a Falha • Caso um componente falhe em uma verificação um componente sobre saliente ocupa seu lugar • O componente sobre saliente não é uma copia do principal, para que ele possa lidar com as circunstancias que fizeram o principal falhar • Devido ao fato que em softwares falhas pode ocorrer somente em circunstâncias excepcionais, a rotina é devolvida ao componente principal após validado o seu resultado o que raramente ocorre nos projetos de hardware
Considerações - Tolerância a falhas • A variedade de erros que não pode ser detectados em um componente de software é infinito. Devido a complexidade desse componentes a relação entre eventuais erros e os efeitos dos mesmo em tempo de execução pode ser obscura • Por isso decidiu-se que os diagnósticos dos originais causadores do erros de software deveriam ficar a cargo do homem realizar • Portanto o esquema para tolerancia a falhas que será descrito, em momento algum baseia-se em uma diagnóstico da causa do erro (aumentaria a complexidade e a propensão a erro do sistema)
Caracteristicas - Recovery Block • Incorpora uma solução geral para o problema de mudança para o componente sobre saliente, na ocorrência de um erro no componente principal, transfere o controle para o componente sobre saliente apropriado • O método de validação do componente tem que ser desenvolvido de maneira simples a fim de garantir a “reliability” do sistema e não aumentar a complexidade do mesmo
Recovery Block • Descartou-se a possibilidade de verificação de cada operação básica por questões de custo, e por existir em um cenário mais amplo uma maior dificuldade de formular as verificações. • É uma pratica comum a estrutura de programas em blocos de complexidade significativa, afim de simplificar a tarefa de compreensão e documentação • Sendo assim uma boa prática seria a validação de blocos do software, ou seja, após a execução dos blocos nos softwares são chamadas pequenas rotinas para verificação dos mesmo
Recovery Block • O Recovery Block consiste de um bloco tradicional, acrescido de um dispositivo de detecção de erro chamado de “teste de aceitação” • E também é acrescido de zero ou mais peças de reposição
Recovery Block • Antes de executar a rotina primária realiza um ponto de recuperação • Ao ser detectado um erro o processo é restaurado ao estado em que o ponto de recuperação foi realizado • Se a rotina primária não passa no teste de aceitação alterna em as rotinas de reposição até que uma seja aceita ou termine as opções de rotinas.
Teste de aceitação • Deve garantir a satisfação do programa quanto a operação realizada pelo bloco de recuperação o qual foi envocado • Os testes de aceitação são realizados através de referencia a variáveis do programa, uma vez que as variáveis locais do programa podem não ter significado algum após a saída do bloco • Os testes de aceitação podem ser diferentes para as diversas rotinas de reposição • Não há exigência quando a formalidade do teste, a verificação do rigor do teste fica a cargo do projetista • Quando um teste de aceitação é falho todas as evidencias são escondidas para análise offline (log) • Teste de aceitação simples para evitar falhas
Recuperação de erro em processo interativos Efeito dominó
Efeito dominó • O efeito dominó pode ocorrer quando duas circunstâncias particulares existem em combinação: • A estrutura do recovery block dos diversos processos são descordenados e não levam em conta a causa de interdependência dos processos por suas interações • Os processos são simétricos em relação a propagação de falha – um membro de qualquer par de interação de processo pode realizar um “backup” nos outros. • Para remover tais circunstâncias e evitar-se o perigo do efeito dominó, utiliza-se a técnica de estruturas de processos de interação com “conversas”
Conclusão • Esta técnica para estrutura sistemas tolerantes a falhas, é descrita especialmente para as falhas existente derivadas de erros de projeto, encontradas em sistemas complexos de softwares • A eficácia dessa abordagem de tolerância a falhas dependerá criticamente dos testes de aceitação e dos blocos alternativos adicionais providos pelo sistema