Sistemas Tolerantes a Falhas: Conceitos e Técnicas

1. Sistemas Tolerantes a Falhas: Conceitos e Técnicas FURB – DSC Paulo Fernando da Silva

2. Sumário • Introdução • Conceitos e Terminologia • Redundância Temporal • Redundância de Hardware • Redundância de Software

3. Introdução • Falhas são inevitáveis: • Paralisia do sistema pode ser evitada; • Técnicas têm alto custo: • Computacional: backup; • Financeiro: Redundâncias; • Avaliação Custo x Benefício;

4. Introdução • Expansão das redes de computadores; • Maior disponibilidade de serviços; • Ex.: transações eletrônicas; • Maior dependência de serviços; • Ex.: Site de vendas pela internet; • Falhas podem prejudicar empresas;

5. Introdução • Confiabilidade e disponibilidade são cada vez mais importantes; • Dependência da sociedade; • Tráfego aéreo; • Área da saúde; • Área financeira; • Telecomunicações;

6. Introdução • Hardware: • Teve grande aumento de confiabilidade; • Software: • Está se tornando cada vez mais complexo; • Apresenta muito problemas; • Só o hardware não garante a confiabilidade e disponibilidade dos sistemas;

7. Introdução • Algumas falhas: • Falhas em mísseis na guerra do golfo (1991) • Falhas na comunicação de ambulâncias em Londres (1992) • Falhas no sistema de crédito da França (1993)

8. Introdução - Desafios • Como evitar, detectar e contornar bugs? • Como explorar a rede aumentando a confiabilidade e a disponibilidade? • Como desenvolver um sistema confiável em uma plataforma não confiável?

9. Conceitos – TF x Depend. • Tolerância a Falhas: • Localização e recuperação de falhas do sistema; • Chamados de sistemas redundantes; • Falsa impressão de que o sistema não falha!!! • Dependabilidade: • Conceito mais atual; • Confiança que se pode ter em um sistema;

10. Conceitos - Objetivo

11. Conceitos – Falha, Erro e Defeito • Defeito: • Desvio da especificação; • Não pode ser tolerado; • Erro: • Causador de defeito em potencial; • Falha: • Causa física ou algoritmica do erro;

12. Conceitos – Falha, Erro e Defeito

13. Conceitos – Falha, Erro e Defeito

14. Conceitos – Falha, Erro e Defeito • Falhas são inevitáveis: • Componentes físicos envelhecem; • Projetos de software podem apresentar falhas humanas; • Defeitos são evitáveis: • Através de técnicas de tolerância a falhas;

15. Conceitos – Falha, Erro e Defeito • Exemplo: • Chip com defeito: falha; • Interpretação errada da informação: erro; • Provoca negação de acesso ao usuário: defeito; • Nem toda falha leva a um erro; • Nem todo erro leva a um defeito; • Podem não aparecer durante a execução do sistema;

16. Conceitos – Classificação das Falhas

17. Conceitos – Classificação das Falhas • Natureza: falhas de hardware, software, operação; • Extensão: local ou global; • Valor: determinado ou indeterminado no tempo; • Falhas de interação intencional: • são tratadas por técnicas de segurança, não por tolerância a falhas;

18. Conceitos – Classificação das Falhas • Tf 1.2.doc • Atributos e dependabilidade • xxx

19. Técnicas de Dependabilidade

20. Técnicas de Dependabilidade

21. Técnicas de Dependabilidade

22. Técnicas de Tolerância a Falhas • Classificam-se em: • Técnicas de mascaramento; • Técnicas de detecção e reconfiguração; • Mascaramento: • Usa redundância para mascarar o defeito; • É mais rápida; • Própria para tempo real;

23. Técnicas de Tolerância a Falhas Detecção e Reconfiguração • Fase de Detecção: • xxx

24. Redundância da Informação • Repete bits na transmissão: • Códigos de paridade; • Técnicas de checksum; • Detecta apenas erros simples; • Usado em componentes de hardware: • Memórias e processadores; • Redes de computadores;

25. Redundância Temporal • Torna redundante as informações no tempo; • Evita custo de harware, aumentando o tempo; • Usado onde o tempo não é crítico; • Para detectar falhas transitórias: • Repete-se a computação no tempo; • Resultados diferentes indicam falhas;

26. Redundância Temporal • Para detectar falhas permanentes: • Com base em uma computação normal; • Repete-se a computação com dados codificados; • Compara-se o resultado da computação normal com o resultado esperado na computação codificada; • A codificação força o uso diferente do componente;

27. Redundância HW - Passiva • Faz mascaramento de falhas; • Vários componentes executam a mesma tarefa; • Resultado determinado por votação; • Resultado obtido por maioria ou valor médio;

28. Redundância HW - Passiva

29. Redundância HW - Passiva

30. Redundância HW - Passiva • TMR: redundância modular tripla; • NMR: redundância modular N; • É ideal para falhas temporárias: • Suporta apenas uma falha permanente;

31. Redundância HW - Ativa • Técnicas de detecção, localização e reconfiguração;

32. Redundância HW - Ativa

33. Redundância HW - Ativa • Reconfiguração do módulo estepe: • Alimentado: minimiza a descontinuidade do sistema; • Não alimentado: espete só começa a operar quando necessário; • Módulo não alimentado minimiza a vida útil do estepe;

34. Redundância HW - Híbrida • Baseado em votação: • Módulo que descorda é desconectado; • Estepe entra em seu lugar; • Modelo redundância auto-eliminadora • xxx

35. Redundância HW - Híbrida

36. Redundância Software • Se a falha está no software, replicação de hardwares é inútil; • Solução: replicar o software: • Diversidade; • Blocos de recuperação; • Verificação de consistência;

37. Redundância SW - Diversidade • São implementadas diversas soluções em software; • Resultado determinado por votação; • Diversidade de algoritmos; • Diversidade de versões;

38. Redundância SW - Diversidade

39. Redundância SW - Diversidade • xxx • Problemas: • Aumento do custo de desenvolvimento; • Não há garantias de que o erro não esteja em todas as versões;

40. Redundância SW – Blocos Recuperação • xxx

41. Pesquisas sobre IDSs Aspectos em desenvolvimento • Técnicas de Detecção: • Inteligência Artificial; • Sistemas Imunológicos; • Técnicas de Correlação; • Diminuir informações no log; • Identificar ataques distribuídos; • Interoperabilidade: • Diferentes IDSs trocando informações;

42. Pesquisas - Interoperabilidade • Existe uma grande diversidade de IDSs: • análise de assinaturas, métodos estatísticos; • baseados em rede, baseados em host; • centralizados, distribuídos; • Sem padrão de arquitetura e comunicação; • A necessidade de interoperabilidade leva à necessidade de padronização;

43. Interoperabilidade – Padrões • Modelo CIDF: • Divisão em módulos; • Atualmente abandonado; • Modelo IDWG: • Está em fase de Draft (IETF); • Modelo de dados IDMEF; • Tendência a ser implementado;

44. Interoperabilidade - IDMEF • Define formato e significados dos dados; • Diversidade de informações: • alertas grandes e pequenos; • rede, sistema operacional, aplicativos; • É orientado a objetos;

45. Interoperabilidade – IDMEFVisão Geral

46. Interoperabilidade - IDMEF • Não define comunicação de respostas: • Não gerencia respostas; • Sem interoperabilidade de respostas; • Operador tem que conhecer cada IDS; • Atrazo no envio de respostas;

47. Pesquisa LRG – Extensão IDWG • Objetivo geral: • Propor uma extensão ao modelo IDWG, de forma a suportar o envio de respostas; • Objetivos específicos: • estender a arquitetura IDWG; • estender o modelo de dados IDMEF; • desenvolver um gerenciador de alertas e respostas;

48. Pesquisa LRG – Modelo PropostoArquitetura

49. Pesquisa LRG – Modelo IDREFVisão Geral

50. Pesquisa LRG - Desenvolvimento • Componentes desenvolvidos: • IDSMan: gerenciador IDMEF / IDREF; • IDSAna: ponte entre Analisador e Gerenciador; • IDSRes: componente de Contra-Medidas; • Desenvolvida biblioteca IDREF; • Linguagem Java; • Orientação a objetos; • Bibliotecas existentes;