Tolerância a falha
8.1.2. Modelos de falha
Falha por queda ou falha por parada – É aquela em que um servidor para prematuramente, mas estava funcionando corretamente até parar.
Falha por omissão – É aquela na qual o servidor não consegue mais responder a uma requisição. Esta pode ser por omissão de recebimento, que é quando o servidor não consegue receber as mensagens que chegam, ou por omissão de envio, que ocorre quando o servidor não consegue enviar mensagens.
Falha de temporização – Ocorre quando a resposta do servidor se encontra fora de um intervalo de tempo real especificado.
Falha de resposta – É um grave problema e é aquele que a resposta do servidor é incorreta. Pode acontecer de dois tipos, a falha de valor que é quando um servidor fornece uma resposta errada a uma requisição e a falha de transição de estado que acontece quando o servidor reage inesperadamente a uma requisição que chega.
Falha arbitrária ou falha bizantina – São as falhas mais sérias. Neste tipo, pode ocorrer do servidor produzir saídas que nunca deveria ter produzido e que não podem ser caracterizadas como incorretas.
8.1.3. Mascaramento de falha por redundância
Para que um sistema seja tolerante a falha, o melhor a ser feito é tentar ocultar de outros processos a tolerância de falhas. A melhor maneira de mascarar falhas é utilizar a redundância. Existem três tipos possíveis de redundância:
Redundância de informação – São adicionados bits extras para permitir recuperação de bits deteriorados.
Redundância de tempo – uma ação é realizada e se for preciso, ela é executada novamente.
Redundância física – são adicionados equipamentos ou processos extras para possibilitar que o sistema, como um todo,tolere a perda ou o mau funcionamento de componentes.
8.2.1. Questões de projeto
Um ponto fundamental para tolerar um processo faltoso é organizar vários processos idênticos em um grupo.Os grupos de processos podem ser dinâmicos. A finalidade de introduzi-los é permitir