Recovery Blocks

1. Recovery Blocks Paulo Junior Penna Pivetta

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

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

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

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

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

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

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

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

10. Sintaxe Recovery Block

11. Recovery Block Simples

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

13. Recovery block mais complexo

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

15. Teste de aceitação

16. Recuperação de erro em processo interativos Efeito dominó

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

18. Processos de “conversas”

19. Conversação Inválida

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