Resumo. Introdução Classificação Fases Curiosidades

Transcrição

1 Tolerância à falha

2 Resumo Introdução Classificação Fases Curiosidades

3 Introdução Sistemas Tolerantes a Falhas são aqueles que possuem a capacidade de continuar provendo corretamente os seus serviços mesmo na presença de falhas de hardware ou de software. São aqueles em que os defeitos não são visíveis para o usuário, pois o sistema detecta e mascara, ou recupera, defeitos antes que eles alcancem os limites do sistema (ponto de fuga da especificação).

4 Introdução O estudo dos sistemas tolerantes a falhas surgiu da necessidade de sistemas mais confiáveis. como: controle de vôo, Sistemas bancários, etc; Outros sistemas, não tão criticos, necessitam ser mais confiaveis ou acessiveis por questões: Contratual; Experiência do usuário com o serviço; Logo, a tolerância a falhas, nestes sistemas, visa evitar ao máximo interrupções destes serviços.

5 Introdução Falha Parcial: quando um componente falha; Redundância: tecnica fundamental para manipular falhas; Atomicidade: se uma atividade falhar, todas as outras atividades devem ser desfeitas; Há uma forte relação entre tolerancia a falha e sistema confiável;

6 Introdução Disponibilidade: um sistema pronto para ser usado imediatamente; Confiabilidade: um sistema que funciona normalmente sem falha; Segurança: nada de catastrofico acontecerá se o sistema não funciona corretamente; Capacidade de manutenção: a facilidade de consertar o sistema após uma falha;

7 Defeito, Erro e Falha Erro: O erro é considerado uma ação humana, que resulta em um software com defeitos; Defeito: quando não pode cumprir suas promessas; Falha: o sistema não se comporta como esperado;

8 Defeito, Erro e Falha

9 Modelos de Falhas Serviço é formado por: servidor, cliente e canal de comunicação; A falha pode esta ocorrendo em um deles; Ou, então, em um ponto que eles dependem (ex. Outros serviços);

10 Classificações Transiente: a falha ocorre uma vez e depois desaparece (geralmente, problema externo); Ex.: você tenta ligar para uma pessoas e só na segunda vez funciona; Intermitente: a falha aparece de forma esporádica; Ex.: perder a conexão da rede por mau contato do cabo; Permanente: as falhas sempre ocorreram até quando forem consertadas; Ex.: o sistema não entra porque não tem acesso ao banco de dados;

11 Classificações Sistema Distribuídos Travamento (Crash): são aquelas falhas que causam o travamento ou a perda do estado interno do componente defeituoso; Omissão (Omission): são aquelas que fazem com que um componente não responda a algumas requisições; Performance (Timing): são aquelas que fazem com que um componente responda ou muito cedo ou muito tarde; Bizantinas (Byzantine): São aquelas falhas que fazem com que o componente se comporte de uma maneira totalmente arbitrária;

12 Classificações Sistema Distribuídos

13 Mascaramento de falhas De informação: adicionar bits extras na mensagem para recepcionar bits deteriorados; Códigos de detecção/correção de erros, RAID, etc; De tempo: refazer uma chamada após um tempo; Re-execução de código em momentos distintos, etc; Hardware: replicar alguns equipamentos (ex. memória, fonte de alimentação, computadores); NMR, TMR, SMR, etc; Software: N equipes desenvolvem o mesmo software; N-Version, N-Self-Checking Programming, etc;

14 Resiliência de Processo Resiliência: Capacidade de superar, de recuperar de adversidades. (Priberam, 2013) Como fazer isso em informática: Organizar processos identificos em um grupo; Todos os processos tem a capacidade processar a mesma mensagem; Podemos formar os processos em dois grupos; Plano (simples): todos os processos são iguais e as decisões são tomadas em coletivo; Hierarquico: tem um processo (coordenador) para gereniciar; Um grupo precisa fazer alguns acordos: coordenador, repartir tarefas e etc;

15 Fases Não existe uma arquitetura generica, mas podem seguir uma sequência de fases para tornar um sistema mais tolerantes a falhas: Deteccão de Erros Confinamento de Estragos e Avaliação Recuperação de Erros Tratamento de Falhas e Serviços Continuados

16 Detecção Como as falhas e avarias não podem ser detectadas diretamente, elas serão deduzidas a partir da detecção de erros no sistema. Fica claro que a eficiência de um esquema de tolerância a falhas está baseada na sua eficiência em detectar erros. Idealmente, seria adequado que todos os erros fossem detectados. Entretanto, tal mecanismo exaustivo não seria viável na prática;

17 Detecção Existem algumas propriedades importantes que devem ser satisfeitas para fazer um teste ideal de erros: Um teste ideal deve se basear somente na especificação do sistema; A implementação do sistema deve ser uma 'caixa preta'; Mas nem sempre é bom, muitas vezes tem que chegar o fluxo da informação para garantir que não é a mesma em todos os testes; Um teste ideal deve ser completo e correto; Todos os possiveis erros devem ser verificados; O teste deve ser independente do sistema com respeito à suscetibilidade de falhas; Os testes também podem falhar!

18 Detecção Testes de Replicação Testes de Replicação são muito comuns e poderosos, podendo ser bem completos e implementados sem o conhecimento do funcionamento interno do sistema; Tal teste implica em replicar algum componente do sistema, e comparar ou votar resultados de diferentes componentes a fim de detectar erros. O tipo e a quantidade de replicações dependem da aplicação; Tal forma de teste é usada frequentemente em hardware;

19 Detecção Testes de Temporização (Timing) Se a especificação de um componente inclui restrições no tempo de resposta, então testes de Timing podem ser aplicados. Basicamente, tais testes realizam uma solicitação a algum componente e verificam se o tempo de resposta excede ou não a restrição imposta na especificação. Testes de Timing são usados tanto em hardware como em software. Em sistemas distribuídos, ele possui um papel importante, pois a falha de um nó é determinada pelo seu tempo de resposta a uma determinada solicitação.

20 Detecção Testes Estruturais e Semânticos Em quaisquer dados, dois tipos gerais de testes são possíveis: testes de semântica e estruturais. Testes Semânticos tentam garantir se o valor é consistente com o resto do sistema. Testes Estruturais só consideram a informação e garantem que internamente a estrutura dos dados é como deveria ser. A forma mais comum de teste estrutural é a codificação, que é usada intensamente em hardware. Nela, bits extras são adicionados aos dados, de forma que é possível detectar se existe algum bit corrompido. Tal teste também pode ser usado em software, sendo aplicado às estruturas de dados.

21 Detecção Testes de Consistência Utilizando o conhecimento de características inerentes ao sistema (invariantes), essa técnica consiste em realizar verificações em determinados pontos da computação, testando a consistência, ou seja, se os invariantes continuam sendo respeitados. Como exemplo de invariante podemos citar o caso de uma variável sempre conter um valor que pertença a um determinado intervalo. Pode-se testar se o valor dessa variável está no intervalo esperado. Outro exemplo é colocar assertions no meio do sistema, a fim de que inconsistências sejam detectadas.

22 Detecção Testes de Diagnóstico Em Testes de Diagnóstico, um sistema usa alguns testes em seus componentes para verificar se ele está funcionando corretamente. A partir do conhecimento prévio de certos valores de entrada e de seus resultados de saída corretos, estes valores são aplicados ao componente e a saída é comparada com os resultados corretos.

23 Detecção Teste de Capacidade (Capability check) Essa técnica consiste em verificar a capacidade do sistema antes da execução de alguma tarefa ou simplesmente utilizar o tempo livre do processador para verificar o funcionamento dos componentes do sistema. Pode-se verificar, por exemplo, se há quantidade de memória suficiente para a execução da tarefa, testar se não há falhas de comunicação entre os processadores de um multicomputador, dentre outros.

24 Detecção Detectar Erros Duplicação: Consiste em simplesmente duplicar a informação original. Duplica o número de bits extra, e permite apenas a detecção de erros. Não é necessária nenhuma operação sobre a informação, sendo a simplicidade sua principal vantagem. Checksum: Nessa técnica, os valores dos caracteres (bytes) da mensagem enviada são somados, e o resultado da operação módulo é o valor do checksum. Ao receber a mensagem, verifica se a mensagem é a mesma.

25 Confinamento de Estragos e Avaliação Se o sistema não for monitorado constantemente, haverá um intervalo entre a falha e a deteccção do erro. Desta maneira, este erro pode se propagar para outras partes do sistema. Por isso, para avaliar o estrago após a detecção de um erro, o fluxo da informação entre diferentes componentes deve ser examinado.

26 Recuperação Após detectar a falha, podemos recuperar o estado do servidor: Recuperação para a tras: ao longo do tempo, cria-se pontos de restauração; quando ocorrer um erro, é só voltar ao último ponto válido; Recuperação para a frente: tente corrigir o problema automaticamente; para isso, é necessário saber os possíveis erros e soluções;

27 Tratamento Se ele foi gerado por uma falha transiente, ela não precisa ser tratada, pois já desapareceu. Caso o erro persiste, o tratamento possui duas subfases: Localização da Falha - Nesta fase, o componente defeituoso precisa ser identificado. Geralmente, o componente defeituoso é identificado como sendo aquele mais próximo da origem do erro. Reparo do Sistema - Nesta fase, o sistema é reparado para que o componente defeituoso não seja usado novamente. Deve ser notado que a manutenção é feita on-line, sem intervenção manual.

28 Blocos Básicos em Sistemas Distribuídos Tolerante a Falhas O objetivo de sistemas de alta disponibilidade (ou seja, tolerante a falhas) é continuar a prover serviços mesmo na ocorrência de falhas em alguns de seus componentes. Existem diferentes métodos e esquemas para promover tal capacidade a sistemas distribuídos. Acordo Bizantino (Byzantine Agreement) Relógios Sincronizados (Synchronized Clocks) Repositório Estável (Stable Storage) Processadores Fail Stop (Fail Stop Processors) Detecção de Avarias e Diagnóstico de Falhas (Failure Detection and Fault Diagnosis) Entrega Confiável de Mensagens (Reliable Message Delivery) Broadcast de Mensagens

29

30 Para mascará uma falha, é importante detecta-la; Os processos não faltosos devem detectar quem ainda esta vivo! Um das formas é usar o ping ou avisar sua situação perodicamente (keep alive); Mas como saber se foi uma falha da rede ou do nó? Muitas vezes, não tem como saber isso.

31 Comunicação confiável Cliente-Servidor Precisamos considerar falhas na comunicação; TCP: já resolve o problema de pacotes perdidos, mas não quando a conexão cai; Isso fica a cargo da aplicação; Nem sempre é possível mascará tudo, porque: O cliente não consegue localizar o servidor; A mensagem se perde entre eles; O servidor ou cliente pode cair;

32 Comunicação confiável Cliente-Servidor O servidor pode garantir que: a mensagem vai ser executada uma vez, no máximo uma vez ou nada; Por exemplo, caso o servidor cai e volta, o cliente pode reenviar a mensagem; O servidor irá processar novamente uma mensagem caso já tenha recebido? Mas nem todas as mensagens são idempotentes: podem ser processadas varias vezes e não muda o resutaldo; O servidor pode manter um controle das mensagens: Identificando elas por um número; Um campo da mensagem diz se é, ou não, restranmissão;

33 Comunicação Confiável do Grupo Podemos trabalhar com multicast, quando todos os processos recebem a mesma mensagem; Problema: o remetente receberá várias mensagens; Multicast atomico Ou todo mundo recebe, ou ninguém processa; Quando um nó cai, ele sai do grupo e, depois, é forçado a junta-se, recebendo todas as mensagens;

34 Comprometimento Distribuído Problema: cada replica deve executar uma operação ou nenhuma; Protocolo de uma fase O coordenador informa se as replicas devem (ou não) receber uma mensagem; As replicas não retornam, caso haja um problema; Protocolo de duas fases O coordenador verifica se todos as replicas podem executar a mensagem;

35 Recuperação Após detectar a falha, podemos recuperar o estado do servidor: Recuperação retroativa: ao longo do tempo, cria-se pontos de restauração; quando ocorrer um erro, é só voltar ao último ponto válido; Recuperação para a frente: tente corrigir o problema automaticamente; para isso, é necessário saber os possíveis erros e soluções; Mas isso tras perda de desempenho e até entrar em um loop; Os pontos de verificação podem estar no remetente ou no receptor (cada um armazem as mensagens enviadas ou recebidas); Pode-se usar armazenamento estável (redudância de HD);

36 Curiosidade

37 Curiosidade Geralmente, quando você deseja medir a disponibilidade de um sistema, você introduz falhas nele; Quando se faz uma pesquisa no Google, ele repassa a requisição para diversas máquinas; a que responder primeiro, é a sua resposta;

38 Referências Nelio Pereira, Avarias, Erros e Falhas, ha/html/node30.html