Redes e Sistemas Distribuídos II – Cód. 30127 Prof. MSc. Ronnison Reges Vidal 2 05/11/2015 Redes e Sistemas Distribuídos II Consistência e réplica, Tolerância a falhas, Sistemas de arquivos distribuídos, Sistemas baseados em objetos distribuídos, Sistemas de arquivos distribuídos (NFS), Sistemas baseados em documentos distribuídos (WWW), Sistemas baseados em coordenação distribuídos (JINI) Mater Christi 3 05/11/2015 Tolerância a Falhas Introdução Mater Christi 4 05/11/2015 Introdução Aspecto característico dos sistemas distribuídos Falha parcial Uma falha pode afetar a operação adequada de outros componentes Objetivo importante do projeto de Sist. Dist.: Construir o sistema de modo tal que ele possa se recuperar automaticamente de falhas parciais sem afetar seriamente o desempenho global Mater Christi 5 05/11/2015 Introdução Sempre que um componente falhar o sistema deve continuar a funcionar de maneira aceitável Tolerar falhas e continuar a funcionar, mesmo na presença de falhas Técnica fundamental para manipulação de falhas: redundância Mater Christi 6 05/11/2015 Introdução Conceitos básicos O que é tolerar falhas? Relação entre tolerância a falhas e sistemas confiáveis Confiabilidade em sistemas distribuídos É o conjunto de requisitos úteis para sistemas distribuídos Disponibilidade Confiabilidade Segurança Capacidade de manutenção Mater Christi 7 05/11/2015 Introdução Disponibilidade Propriedade de um sistema estar pronto para ser usado imediatamente É a probabilidade de um sistema estar funcionando corretamente em qualquer momento determinado e estar disponível para executar suas funções em nome de seus usuários Mater Christi 8 05/11/2015 Introdução Confiabilidade É a propriedade de um sistema poder funcionar continuamente sem falha É definida em termos de um intervalo de tempo em vez de um instante no tempo Um sistema de alta confiabilidade continuará funcionando sem interrupção durante um período de tempo relativamente longo Mater Christi 9 05/11/2015 Introdução Segurança Refere-se a situação onde caso o sistema deixe de funcionar num determinado período de tempo na catastrófico acontecerá Se tais sistemas falharem temporariamente, como uma usina nuclear, os efeitos seriam desastrosos Mater Christi 10 05/11/2015 Introdução Capacidade de manutenção Facilidade com que um sistema que falhou pode ser consertado Um sistema de alta capacidade de manutenção demonstra uma alta disponibilidade, em especial se as falhas puderem ser detectadas e reparadas automaticamente. Mater Christi 11 05/11/2015 Introdução Caraterização de problemas quanto a tolerância a falhas Defeito: quando um sistema não presta o devido serviço Erro: é uma parte do sistema que pode levar a uma falha Falha: Causa de um erro Mater Christi 12 05/11/2015 Introdução Conceito Um sistema pode prover seus serviços mesmo na presença de falhas Falhas de tolerância a falhas são classificadas como Transiente Intermitente Permanente Mater Christi 13 05/11/2015 Introdução Transiente Tipo de falha que ocorre somente uma vez depois desaparece Exemplo Um pássaro que voa sobre um feixe transmissor de micro-ondas pode causar perdas de bits em alguma rede Mater Christi 14 05/11/2015 Introdução Intermitente Ocorre e desaparece por sua própria vontade, depois reaparece e assim por diante. São difíceis de diagnosticar Exemplo Um conector frouxo muitas vezes causará uma falha intermitente Mater Christi 15 05/11/2015 Introdução Permanente É aquele que continua a existir mesmo que o componente faltoso seja substituído Exemplos Chips queimados, bugs de software, quebra de cabeçote de discos Mater Christi 16 05/11/2015 Tolerância a falhas Modelos de Falhas Mater Christi 17 05/11/2015 Modelos de Falhas Um sistema que falha não fornece adequadamente seus serviços Exemplo Conjunto de servidores que se comunicam uns com os outros e com os clientes Servidores ou canais de comunicação ou ambos não estão fazendo o que deveriam Quando o servidor está funcionando mal, nem sempre é a falha que estamos procurando Mater Christi 18 05/11/2015 Modelos de Falhas Dependência de outros servidores podem ser a causa As relações dependência são abundantes em Sist. Dist. Um disco que pode estar falhando Dificulta a vida de um servidor de arquivos Altera o funcionamento de um banco de dados distribuído Mater Christi 19 05/11/2015 Modelos de Falhas Classificação de falhas Falha por queda Falha por omissão Falha por temporização Falha de resposta Falha de transição de estado Falha arbitrária ou falha bizante Falha por parada Mater Christi 20 05/11/2015 Modelos de Falhas Falha Quando um servidor pára prematuramente, mas estando funcionando corretamente até parar Falha por queda por omissão Quando um servidor não responde a uma requisição Mater Christi 21 05/11/2015 Modelos de Falhas Falha Quando uma reposta se encontra fora de um intervalo de tempo real específico Falha de reposta Falha na qual a resposta do servidor simplesmente é incorreta Falha de temporização de transição de estado Quando o servidor reage inesperadamente a uma requisição que chega Mater Christi 22 05/11/2015 Modelos de Falhas Falhas arbitrárias Quando o servidor está produzindo saídas que nunca deveriam ter sido produzido, mas que não podem ser detectados como incorreto Falhas por parada Caracterizadas como falha por queda Quando o servidor falha desse modo simplesmente pára de produzir saídas de modo tal que sua parada pode ser detectada por outros processos Mater Christi 23 05/11/2015 Modelos de Falhas Tipos de falhas Descrição • Falha por queda • O servidor pára de funcionar, mas estava funcionando corretamente até parar • Falha por omissão • Omissão de recebimento • Omissão de envio • O servidor não consegue responder a requisições que chegam O servidor não consegue receber mensagens que chegam O servidor não consegue enviar mensagens • • Mater Christi 24 05/11/2015 Modelos de Falhas Tipos de falhas Descrição • Falha de temporização • A resposta do servidor se encontra fora do intervalo de tempo • Falha de resposta • Falha de valor • Falha de transição de estado • A resposta do servidor está incorreta O valor da resposta está errado O servidor se desvia do fluxo de controle correto • Falha arbitrária • • • Um servidor por produzir respostas arbitrárias em momentos arbitrários Mater Christi 25 05/11/2015 Tolerância a Falhas Mascaramento de Falha por redundância Mater Christi 26 05/11/2015 Mascaramento de Falha por redundância Um sistema para ser tolerante o melhor que pode se fazer é ocultar de outros processos a ocorrência de falhas Redundância Tipos de redundância: Informação Tempo Física Mater Christi 27 05/11/2015 Mascaramento de Falha por redundância Informação São adicionados bits extras para permitir a recuperação de bits deteriorados Exemplo Código de Hamming pode ser adicionado a dados transmitidos pera recuperá-los de ruído na linha de transmissão Mater Christi 28 05/11/2015 Mascaramento de Falha por redundância Tempo Uma ação é realizada, e então, se for preciso, realizada novamente Exemplo Transações utilizam essa abordagem Redundância de tempo são especialmente utilizadas para falhas transientes e intermitentes Mater Christi 29 05/11/2015 Mascaramento de Falha por redundância Física São adicionados equipamentos ou processos extra para possibilitar que o sistema como um todo tolere a perda ou o mal funcionamento de alguns componentes Pode ser aplicada a hardware ou software Exemplo Processos extras para no caso de queda o sistema possa continuar funcionando Mater Christi 30 05/11/2015 Tolerância a Falhas Resiliência de Processos Mater Christi 31 05/11/2015 Resiliência de Processos A abordagem fundamental para tolerar um processo faltoso é: Organizar vários processos idênticos em um grupo Propriedade: Uma mensagem que é enviada ao grupo em si, todos os membros do grupo a recebem Nesse caso se algum processo falhar, espera-se que algum outro se encarregue da mensagem em seu lugar Mater Christi 32 05/11/2015 Resiliência de Processos Grupos de processo podem ser dinâmicos Novos grupos podem ser criados Velhos grupos podem ser eliminados Um processo pode se juntar a um grupo Um processo pode sair de um grupo Um processo pode ser membro de vários grupos ao mesmo tempo São necessário mecanismos para gerenciar grupos e associações A finalidade de introduzir grupos é permitir que processos tratem conjuntos de processos como uma abstração Quem são, quanto são, onde estão Mater Christi 33 05/11/2015 Resiliência de Processos Grupos simples versus Grupos hierárquicos Uma distinção importante entre grupos é o funcionamento interno Em alguns grupos todos são iguais Ninguém manda e todas as decisões são tomadas coletivamente Em outros existe uma hierarquia Quando uma requisição de trabalho é gerada esta é remetida a um processo coordenador Hierarquias mais complexas são possíveis Mater Christi 34 05/11/2015 Resiliência de Processos Cada uma tem suas vantagens e desvantagens Vantagens – Grupos Simples Os grupos simples são simétricos Não têm ponto de falha único Desvantagens Tomada de decisão complexa Votação: atraso e custo adicional Grupos Hierárquicos Têm propriedades opostas A perda do coordenador pode causar parada repentina do grupo inteiro Entretanto enquanto está funcionando toma decisões sem se incomodar Mater Christi 35 05/11/2015 Resiliência de Processos Grupos simples versus Grupos hierárquicos Mater Christi 36 05/11/2015 Resiliência de Processos Associação a um grupo Método de criação e eliminação de grupos Permite que outros processos se juntem a grupos e saiam deles Uma abordagem possível é a criação de um: Servidor de grupos Manter um banco de dados com todos os grupos e de quem são seus associados Método: Direto Eficiente Razoavelmente fácil de implementar Mater Christi 37 05/11/2015 Resiliência de Processos Método: Porém é uma abordagem centralizada Outra abordagem: Gerenciamento de associação ao grupo de modo distribuído Único ponto de falha Multicast (confiável) Operações de entrada e saída Síncronas Converter as operações de a entrada e saída integradas ao fluxo de dados em uma sequencia de mensagens enviadas a todo o grupo Mater Christi 38 05/11/2015 Resiliência de Processos Mascaramento de Falhas e Replicação grupos de processos são parte da solução para construir sistemas tolerantes a falhas Ter um grupo de processos idênticos permite mascarar um ou mais processos faltosos Pode-se replicar processos e organizá-los em um grupo para poder substituir um único processo (vulnerável) por um grupo (tolerante a falhas) Mater Christi 39 05/11/2015 Resiliência de Processos Acordo em sistemas com falha Considerando que processos replicados em um grupo ajudam a aumentar a tolerância a falhas Existe a premissa de que os processos não se juntam para produzir um resultado errada A complexidade é maior ao se exigir que um grupo de processos chegue a um acordo Exemplos: Eleger um coordenador, decidir a validação ou não de uma transação, repartir tarefas entre operários e sincronização Mater Christi 40 05/11/2015 Resiliência de Processos Objetivo geral de algoritmos de acordo distribuídos: É que todos os processos que não apresentam falha cheguem a um consenso sobre alguma questão e estabeleçam esse consenso dentro de um número finito de etapas O problema é complicado pelo fato de que premissas diferentes sobre o sistema subjacente requer soluções diferentes Mater Christi 41 05/11/2015 Resiliência de Processos Distinguem-se os seguintes casos: Sistemas síncronos versus Sistemas assíncronos O atraso de comunicação é limitado ou não A entrega de mensagens é ordenada ou não A transmissão de mensagens é feita em unicast ou multicast Mater Christi 05/11/2015 Resiliência de Processos Ordenação de Mensagens Não Ordenada Limitado Não Limitado x Síncrono Assíncrono Ordenada X X X unicast Multicast X X Limitado X X Não Limitado unicast Multicast Atraso de Comunicação Comportamento do Processo 42 Transmissão de Mensagens Circunstâncias sob as quais se pode chegar a um acordo distrubuído Mater Christi 43 05/11/2015 Resiliência de Processos Detecção de falhas Para mascarar uma falha é necessário detectá-la Esta é uma das pedras fundamentais da tolerância a falhas No caso de um grupo de processos, os membros não faltosos devem ser capazes de decidir quem ainda é um membro e quem não é É preciso ser capaz de descobrir quando um Mater Christi membro falhou 44 05/11/2015 Resiliência de Processos Para detectar falhas há duas maneiras: Os processos mandam ativamente uns aos outros mensagens “vocês está vivo?” (esperando respostas) Esperam passivamente a entrada de mensagens do processos diferentes Mater Christi 45 05/11/2015 Resiliência de Processos A última abordagem só faz sentido quando se pode garantir que haja comunicação suficiente Usualmente é enviado pings ativamente entre processos Mater Christi 46 05/11/2015 Resiliência de Processos Essência: Falhas são detectadas através de mecanismos de timeouts Definir timeouts de maneira eficiente é muito difícil e depende da aplicação É difícil distinguir falhas dos processos das falhas da rede Possível Solução Considerar possíveis notificações de falhas entre os membros do sistema Gossiping Árvores onde os processos “fingem” que falharam Mater Christi 47 05/11/2015 Tolerância a Falhas Comunicação Confiável Cliente e Servidor Mater Christi 48 05/11/2015 Comunicação Confiável Cliente-Servidor E as falhas de comunicação? Canais de comunicação podem exibir falhas por queda, por omissão, de temporização e arbitrárias Na construção de canais de comunicação: evitar falhas por queda e omissão Falhas arbitrárias podem ocorrer sob a forma de mensagens duplicadas Mater Christi 49 05/11/2015 Comunicação Confiável Cliente-Servidor Ponto-a-Ponto O único modo de mascarar falhas de comunicação é permitir que o sistema tente estabelecer automaticamente uma nova conexão, simplesmente com o reenvio de uma requisição de conexão Mater Christi 50 05/11/2015 Comunicação Confiável Cliente-Servidor Ponto-a-Ponto 5 classes de problemas que podem acontecer em sistemas RPC (1) Cliente não consegue localizar o servidor (2) A mensagem de requisição do cliente para o servidor se perde (3) O servidor cai após receber uma requisição (4) A mensagem de resposta do servidor para o cliente se perde (5) O cliente cai após enviar uma requisição Mater Christi 51 05/11/2015 Tolerância a Falhas Comunicação Confiável de Grupo Mater Christi 52 05/11/2015 Tolerância a Falhas Comprometimento Distribuído Mater Christi 53 05/11/2015 Tolerância a Falhas Recuperação Mater Christi 54 05/11/2015 Atividade Resumir as 5 classes de falhas de RPC (1) Cliente não consegue localizar o servidor (2) A mensagem de requisição do cliente para o servidor se perde (3) O servidor cai após receber uma requisição (4) A mensagem de resposta do servidor para o cliente se perde (5) O cliente cai após enviar uma requisição Mater Christi
Download
