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

Sintaxe Recovery Block

Recovery Block Simples

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.

Recovery block mais complexo

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

Teste de aceitação

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”

Processos de “conversas”

Conversação Inválida

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