Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouGiovanna Cesário César Alterado mais de 8 anos atrás
1
Redes e Sistemas Distribuídos II – Cód. 30127 Prof. MSc. Ronnison Reges Vidal
2
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) 18/10/2015 Mater Christi 2
3
Tolerância a Falhas Introdução 18/10/2015 Mater Christi 3
4
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 18/10/2015 Mater Christi 4
5
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 18/10/2015 Mater Christi 5
6
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 18/10/2015 Mater Christi 6
7
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 18/10/2015 Mater Christi 7
8
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 18/10/2015 Mater Christi 8
9
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 18/10/2015 Mater Christi 9
10
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. 18/10/2015 Mater Christi 10
11
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 18/10/2015 Mater Christi 11
12
Introdução Conceito de tolerância a falhas Um sistema pode prover seus serviços mesmo na presença de falhas Falhas são classificadas como Transiente Intermitente Permanente 18/10/2015 Mater Christi 12
13
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 18/10/2015 Mater Christi 13
14
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 18/10/2015 Mater Christi 14
15
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 18/10/2015 Mater Christi 15
16
Tolerância a falhas Modelos de Falhas 18/10/2015 Mater Christi 16
17
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 18/10/2015 Mater Christi 17
18
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 18/10/2015 Mater Christi 18
19
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 18/10/2015 Mater Christi 19
20
Modelos de Falhas Falha por queda Quando um servidor pára prematuramente, mas estando funcionando corretamente até parar Falha por omissão Quando um servidor não responde a uma requisição 18/10/2015 Mater Christi 20
21
Modelos de Falhas Falha de temporização 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 transição de estado Quando o servidor reage inesperadamente a uma requisição que chega 18/10/2015 Mater Christi 21
22
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 18/10/2015 Mater Christi 22
23
Modelos de Falhas Tipos de falhasDescriçã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 18/10/2015 Mater Christi 23
24
Modelos de Falhas Tipos de falhasDescriçã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 18/10/2015 Mater Christi 24
25
Tolerância a Falhas Mascaramento de Falha por redundância 18/10/2015 Mater Christi 25
26
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 18/10/2015 Mater Christi 26
27
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 18/10/2015 Mater Christi 27
28
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 18/10/2015 Mater Christi 28
29
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 18/10/2015 Mater Christi 29
30
Tolerância a Falhas Resiliência de Processos 18/10/2015 Mater Christi 30
31
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 18/10/2015 Mater Christi 31
32
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 18/10/2015 Mater Christi 32
33
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 18/10/2015 Mater Christi 33
34
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 18/10/2015 Mater Christi 34
35
Resiliência de Processos Grupos simples versus Grupos hierárquicos 18/10/2015 Mater Christi 35
36
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 18/10/2015 Mater Christi 36
37
Resiliência de Processos Método: Porém é uma abordagem centralizada Único ponto de falha Outra abordagem: Gerenciamento de associação ao grupo de modo distribuído 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 18/10/2015 Mater Christi 37
38
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) 18/10/2015 Mater Christi 38
39
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 18/10/2015 Mater Christi 39
40
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 18/10/2015 Mater Christi 40
41
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 18/10/2015 Mater Christi 41
42
Resiliência de Processos 18/10/2015 Mater Christi 42 x X XXXX XX unicastMulticast unicast Não Ordenada Ordenada Limitado Não Limitado Limitado Não Limitado Síncrono Assíncrono Ordenação de Mensagens Transmissão de Mensagens Comportamento do Processo Atraso de Comunicação Circunstâncias sob as quais se pode chegar a um acordo distrubuído
43
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 membro falhou 18/10/2015 Mater Christi 43
44
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 18/10/2015 Mater Christi 44
45
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 18/10/2015 Mater Christi 45
46
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 18/10/2015 Mater Christi 46
47
Tolerância a Falhas Comunicação Confiável Cliente e Servidor 18/10/2015 Mater Christi 47
48
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 18/10/2015 Mater Christi 48
49
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 18/10/2015 Mater Christi 49
50
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 18/10/2015 Mater Christi 50
51
Tolerância a Falhas Comunicação Confiável de Grupo 18/10/2015 Mater Christi 51
52
Tolerância a Falhas Comprometimento Distribuído 18/10/2015 Mater Christi 52
53
Tolerância a Falhas Recuperação 18/10/2015 Mater Christi 53
54
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 18/10/2015 Mater Christi 54
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.