Redes e Sistemas Distribuídos II – Cód Prof. MSc. Ronnison Reges Vidal

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

Tolerância a Falhas Introdução 18/10/2015 Mater Christi 3

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

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

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

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

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

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

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

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

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

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

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

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

Tolerância a falhas Modelos de Falhas 18/10/2015 Mater Christi 16

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

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

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

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

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

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

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

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

Tolerância a Falhas Mascaramento de Falha por redundância 18/10/2015 Mater Christi 25

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

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

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

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

Tolerância a Falhas Resiliência de Processos 18/10/2015 Mater Christi 30

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

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

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

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

Resiliência de Processos  Grupos simples versus Grupos hierárquicos 18/10/2015 Mater Christi 35

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

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

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

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

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

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

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

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

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

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

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

Tolerância a Falhas Comunicação Confiável Cliente e Servidor 18/10/2015 Mater Christi 47

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

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

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

Tolerância a Falhas Comunicação Confiável de Grupo 18/10/2015 Mater Christi 51

Tolerância a Falhas Comprometimento Distribuído 18/10/2015 Mater Christi 52

Tolerância a Falhas Recuperação 18/10/2015 Mater Christi 53

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