Cap. 08 Tolerância a Falha

Transcrição

1 Cap. 08 Tolerância a Falha 8.1 Introdução a Tolerância a Falha Conceitos Básicos Modelo de Falhas Mascaramento de Falha por Redundância 8.2 Processamento de Resiliência Aspectos de Projeto Mascaramento de Falha e Replicação Concordância em Sistema de Falha Detecção de Falha Luís F. Faina Pg. 1/46

2 Cap. 08 Tolerância a Falha 8.3 Comunicação Cliente/Servidor Confiável Comunicação Ponto-a-Ponto Semântica RPC na Presença de Falhas 8.4 Comunicação de Grupo Confiável Esquema Multicast Básico Confiável Escalabilidade em Multicasting Confiável Multicast Atômico Luís F. Faina Pg. 2/46

3 Cap. 08 Tolerância a Falha Commit Distribuído Commit em 02 Fases Commit em 03 Fases 8.6 Recuperação Introdução Salva-guarda - Checkpointing Logging de Mensagens Computação Orientada por Recuperação Luís F. Faina Pg. 3/46

4 Referências Bibliográficas Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10: , ISBN-13: Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen ( e ) George Coulouris; Jean Dollimore; Tim Kindberg Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - Luís F. Faina Pg. 4/46

5 8 Tolerância a Falhas 8.1 Introdução Introdução falha parcial - característica dos sistemas distribuídos que os distingue dos sistemas de uma única máquina; falha parcial pode ocorrer quando um componente no sistema distribuído deixa de operar normalmente. Em sistemas não distribuídos, uma falha frequentemente afeta todos os componentes, pois o sistema todo pode parar; em sistemas distribuídos, uma falha pode afetar a operação de alguns componentes e, ao mesmo tempo, não afetar um outro conjunto de componentes que permanecem operando. Luís F. Faina Pg. 5/46

6 8 Tolerância a Falhas 8.1 Introdução Conceitos Básicos para melhor entender o papel da tolerância a falha em sistemas distribuídos é necessário entender o que significa para um sistema distribuído ser tolerante a falha; tolerância a falha está fortemente relacionado ao que se chama de sistema confiáveis - dependable systems, que por sua vez contemplam os sequintes requisitos: availability - probabilidade do sistema funcionar corretamente em dado momento e realizar suas funções em benefícios dos seus usuários; sistema de alta disponibilidade é aquele que provavelmente estará funcionando em dado instante de tempo. Luís F. Faina Pg. 6/46

7 8 Tolerância a Falhas 8.1 Introdução Conceitos Básicos tolerância a falha está fortemente relacionado ao que se chama de sistema confiáveis - dependable systems, que por sua vez contemplam os sequintes requisitos: reliability - definido em termos de intervalo de tempo ao invés de um dado momento como na availability, refere-se a abilidade do sistema funcionar continuamente sem falhas. sistema de alta confiabilidade é aquele que mais provavelmente continuará a funcionar sem interrupção durante um longo período de tempo. safety - refere-se a situação na qual um sistema temporariamente falha ou deixa de operar corretamente sem nenhum acontecimento catastrófico. sistemas de controle de usinas de energia nuclear ou de envio de pessoas ao espaço provêem alto grau de segurança. Luís F. Faina Pg. 7/46

8 8 Tolerância a Falhas 8.1 Introdução Conceitos Básicos tolerância a falha está fortemente relacionado ao que se chama de sistema confiáveis - dependable systems, que por sua vez contemplam os sequintes requisitos: maintainability - refere-se em com que facilidade um sistema que falhou pode ser reparado, ou seja, volta a operar corretamente. sistema com alta de manutenção também mostra alto grau de disponibilidade, especialmente se falhas podem ser detectadas e reparadas automaticamente. Obs.: frequentemente, sistemas confiáveis contempla alto grau de segurança, especialmente quando se trata questões como integridade do sistema. Luís F. Faina Pg. 8/46

9 8 Tolerância a Falhas 8.1 Introdução Conceitos Básicos fail ou falha ocorre quando um sistema não cumpre o que se propõe a oferecer, ou seja, apresenta defeito. e.g., sistema distribuído projetado para prover aos seus usuários um nro. de serviços, assim, o sistema falha quando um ou mais serviços deixam de ser oferecidos por alguma razão. error - parte do estado do sistema que pode conduzir o sistema para uma falha, consequência de uma falta - fault. e.g., quando da transmissão de pacotes por um rede de computadores, espera-se alguns pacotes cheguem ao receptor com danos, ou seja, receptor não é capaz de detectar os bits que foram recebidos ou os recebeu incorretamente. Luís F. Faina Pg. 9/46

10 8 Tolerância a Falhas 8.1 Introdução Conceitos Básicos fault tolerance - sistema que provê seus serviços até mesmo na presença de faltas, ou seja, o sistema pode tolerar faltas e continuar a operar normalmente. transient fault - ocorre uma vez e depois desaparece, ou seja, se a operação é repetida a falta simplesmente desaparece. intermittent fault - normalmente difíceis de serem identificadas, ocorrem e desaparecem de forma intermitente. permanent fault - contínua a existir até que o componente com defeito seja substituído, p.ex., bugs de software. Luís F. Faina Pg. 10/46

11 8 Tolerância a Falhas 8.1 Introdução Modelos de Falhas sistema que falha não está fornecendo adequadamente os serviços para os quais foi projetado. crash failure - ocorre quando um servidor para prematuramente, embora estivesse funcionando corretamente até parar. e.g., sistema operacional no estado de parada total por alguma falha, irá necessariamente exigir a sua reinicialização. omission failure - ocorre quando um servidor falha ou deixa de responder uma requisição e, pode ser dividida em: omissão de recebimento - servidor não consegue receber msgs. que chegam, p.ex., nenhuma thread escutando requisições que chegam; omissão de envio - servidor processa a requisição, mas não consegue enviar uma resposta, p.ex., sobrecarga de buffer de envio ou buffer transborda sem que o servidor esteja preparado. Luís F. Faina Pg. 11/46

12 8 Tolerância a Falhas 8.1 Introdução Modelos de Falhas Outros tipos de falhas por omissão não relacionadas com comunicação podem ser causadas por erros de software tais como laços infinitos ou gerenciamento inadequado da memória. timing failures - ocorre quando a resposta se encontra fora de um intervalo de tempo real especificado. fornecer dados muito cedo para o receptor pode causar problemas se não houver espaço suficiente no buffer; mais comum é o servidor enviar a resposta tarde demais, acarretando falha de desempenho. Luís F. Faina Pg. 12/46

13 8 Tolerância a Falhas 8.1 Introdução Modelos de Falhas response failure - ocorre quando a resposta do servidor está incorreta e, pode ser classificada em 02 tipos: value failure - servidor fornece a resposta errada a uma requisição, p.ex., mecanismo de busca que simplesmente retorna página não relacionadas com qualquer uma das palavras de busca. state transaction failure - ocorre quando um servidor reage inesperadamente a uma requisição que chega. servidor recebe uma msg e não pode reconhecer, o que gera uma falha caso nenhuma providencia para manipular tal mensagem seja tomada. Luís F. Faina Pg. 13/46

14 8 Tolerância a Falhas 8.1 Introdução Modelos de Falhas arbitrary failures - também conhecidas como byzantine failures, é necessário preparar o cliente para o pior. byzantine - refere-se ao Império Bizantino [ ] no Balcãs (Turquia) famoso pelas infindáveis conspirações, intrigas e deslealdades que a história alega terem sido comuns no poder. estão intimamente relacionadas com as falhas acidentais - crash failures pois, como já mencionado, o servidor produz saídas que não deveriam ter produzidas; também referenciadas como fail-stop failures, o servidor para de produzir saída de modo que sua parada possa ser detectada por outros processos parada amigável. Luís F. Faina Pg. 14/46

15 8 Tolerância a Falhas 8.1 Introdução Modelos de Falhas Fig. 8.1 Tipos diferentes de Falhas Luís F. Faina Pg. 15/46

16 8 Tolerância a Falhas 8.1 Introdução Mascaramento de Falha Se um sistema deve ser tolerante a falhas, o melhor é tentar esconder a ocorrência de falhas dos outros processos. técnica chave para o mascaramento de faultas é a redundância e que pode ser explorada de 03 maneiras: information redundancy - bits extras para recuperação de pacotes; time redundancy - se preciso, executar novamente a ação; physical redundancy - adicionar equipamentos ou processos extras para obter tolerância à perda ou mal funcionamento de algun componente. redundância física é uma técnica bastante utilizada para prover tolerância a falha. e.g., considere 03 dispositivos eletrônicos A, B e C operando sem redundância e com redundância (Fig. 8.2). Luís F. Faina Pg. 16/46

17 8 Tolerância a Falhas 8.1 Introdução Mascaramento de Falha Fig Triple Modular Redundancy com 03 dispositivos eletrônicos A, B e C operando sem redundância. sinais passam pelos dispositivos A, B e C na sequência, assim se um deles falha, o resultado final será incorreto. Luís F. Faina Pg. 17/46

18 8 Tolerância a Falhas 8.1 Introdução Mascaramento de Falha Fig Triple Modular Redundancy onde cada dispositivo A,. B e C é replicado 03 vezes. seguindo cada estágio no circuito, encontramos 03 circuitos que tem 03 entradas e 01 saída; se 02 ou 03 entradas são as mesmas, a saída é igual a entrada, caso contrário, a saída é não definida. Luís F. Faina Pg. 18/46

19 8 Tolerância a Falhas 8.1 Introdução Mascaramento de Falha Suponha que o A 1 falha, assim cada um dos eleitores V 1, V 2 e V 3 obtém 02 entradas idênticas e 01 entrada incorreta; na sequência 02 saídas idênticas são encaminhadas para as entradas do próximo estágio, ou seja, o efeito de A 2 falhar é completamente mascarado; pois B 1, B 2 e B 3 são exatamente as mesmas que seriam se nenhuma falha tivesse ocorrido. Agora considere o que acontece se além de A 2, B 3 e C 1 também falham, ainda neste cenário os efeitos serão mascarados. Luís F. Faina Pg. 19/46

20 8.2 Resiliência de Processo resiliência - capacidade de voltar ao seu estado natural, principalmente após alguma situação crítica e fora do comum; [física] - propriedade de que são dotados alguns materiais, de acumular energia quando exigidos ou submetidos a estresse sem ocorrer ruptura poderá ou não haver deformação residual. [ecologia] - capacidade de um sistema restabelecer seu equilíbrio após este ter sido rompido por um distúrbio, ou seja, sua capacidade de recuperação; difere de resistência, que é a capacidade de um sistema de manter sua estrutura e funcionamento após um distúrbio. Luís F. Faina Pg. 20/46

21 8.2 Resiliência de Processo resiliência - capacidade de voltar ao seu estado natural, principalmente após alguma situação crítica e fora do comum. Iniciamos a discussão que a proteção contra falhas de processos pode ser alcançada pela replicação de processos em grupos; discutiremos as questões de projeto de grupos de processos bem como o que é um grupo tolerante a falhas; outro aspecto igualmente importante é como obter concordância entre de um grupo de processos quando um ou mais de seus membros não mais é confiável. Luís F. Faina Pg. 21/46

22 8.2.1 Questões de Projeto Abordagem fundamental para tolerar um processo faltoso é organizar vários processos idênticos em um grupo; grupo tem a propriedade de que quando uma mensagem é enviada a um grupo, todos membros do grupo a recebem; se um processo no grupo falha, espera-se que algum outro processo assuma a tarefa em seu lugar. finalidade de se introduzir grupos é permitir que processos tratem conjuntos de processos como uma única abstração. adicionalmente, grupos podem ser dinâmicos. Luís F. Faina Pg. 22/46

23 8.2.1 Questões de Projeto Flat Groups vs Hierarchical Groups - diferentes grupos possuem diferentes estruturas quanto a sua organização interna. flat group - todos processos são iguais dentro de um grupo, ou seja, ninguém manda, todas decisões são coletivas. vantagens - simetria entre os processos e ponto de falha distribuído, ou seja, não há ponto de falha único; se um dos processos falha, o grupo simplesmente torna-se menor mas pode continuar o trabalho. desvantagens - maior custo na tomada de decisão. Luís F. Faina Pg. 23/46

24 8.2.1 Questões de Projeto hierarchical groups - contempla propriedades opostas do flat group, p.ex., possui coordenador(es) e operários. vantagens - maior rapidez na tomada de decisão, pois o coordenador recebe a requisição e repassa para os operários. desvantagens - perda do coordenador provoca a parada repentina do grupo inteiro, mas tão logo volte a executar, ele pode tomar decisões sem incomodar ninguém. Luís F. Faina Pg. 24/46

25 8.2.1 Questões de Projeto Fig. 8.3 a) Comunicação em Flat Group. b) Comunicação em Grupo Hierárquico simples. Luís F. Faina Pg. 25/46

26 8.2.1 Questões de Projeto Group Membership - quando a comunicação em grupo se faz presente, métodos para criação e remoção de grupos assim como entrada e saída de processos se fazem necessários. problema - como criar e eliminar grupos, assim como permitir a entrada e saída de processos em um grupo? abordagem centralizada - uma possibilidade é o servidor de grupo, responsável por receber todas as requisições e manter o banco de dados completo sobre todos grupos e seus membros. abordagem distribuída - processo solicita por multicast a entrada ou saída de um grupo, mas as operações de inserção e remoção do grupo devem ser síncronas. Luís F. Faina Pg. 26/46

27 8.2.1 Questões de Projeto um outro aspecto igualmente importante é o que fazer quando muitas máquinas deixam de operar, inviabilizando a existência de um dado grupo de processos?! normalmente, alguns protocolos se fazem necessários para reconstruir o grupo e, invariavelmente, alguns processo terão que iniciar o processo de criação de novo grupo. Luís F. Faina Pg. 27/46

28 8.2.2 Mascaramento de Falha e Replicação grupos de processos - são parte da solução para sistemas tolerantes a falhas, ou seja, um grupo de processos idênticos permite mascarar um ou mais processos faltosos no grupo; em outras palavras, processos podem ser replicados e organizados em grupos para substituir um ou mais processos faltosos naquele grupo. como discutido anterioremente, há 02 abordagens para replicação: primary-based protocols e replicated-write protocols Luís F. Faina Pg. 28/46

29 8.2.2 Mascaramento de Falha e Replicação Como discutido anterioremente, há 02 abordagens para replicação: primary-based protocols e replicated-write protocols primary-based protocols - grupo de processos é organizado de forma hierárquica no qual um processo primário coordena todas as operações de escrita. replicated-write protocols - corresponde a organização de uma coleção de processos idênticos em um grupo plano - flat group ; tem como vantagens a ausência de um único ponto de falha e o custo da coordenação distribuída. Luís F. Faina Pg. 29/46

30 8.2.2 Mascaramento de Falha e Replicação system is said to be k fault tolerant - se pode sobreviver a k faltas de componentes e ainda atender às suas especificações; se processos, falham silenciosamente, então k+1 deles são suficientes para prover tolerância de k faltas, pois, caso k parem de operar, a resposta do outro processo pode ser usada. Para processos/componentes que exibem falhas bizantinas, continuar a operar na presença de falhas, exige o mínimo de 2k+1 processos para prover tolerância de k faltas; no pior caso, k processos faltosos podem acidentalmente gerar a mesma resposta, entretanto, os k+1 restantes k+1 restantes irão produzir a mesma resposta permitindo que o cliente ou eleitor acredite nos votos majoritários. Luís F. Faina Pg. 30/46

31 8.2.2 Mascaramento de Falha e Replicação na prática é difícil imaginar uma circustância na qual k processos com certeza falham, mas k+1 não falham; por isso, em sistemas tolerantes a falhas algum tipo de análise estatística se faz necessária. atomic multicast problem - para tais modelos serem relevantes assume-se como pré-condição que todas as requisições chegam em todos os servidores na mesma ordem. Luís F. Faina Pg. 31/46

32 8.2.3 Concordância em Sistemas Faltosos com a premissa de que processos não montam times para produzir resultados errados, um cliente pode basear suas decisões através de mecanismos de votação; pode-se tolerar até k processos mentindo sobre seus resultados no universo de 2k+1 processos. objetivo - obter de todos os processos não faltosos o consenso em alguma questão, bem como atingir esse consenso em um número finito de passos. trata-se de um problema complicado, posto que em função do grande nro. de suposições sobre o sistema subjacente podem levar/exigir diferentes soluções. Luís F. Faina Pg. 32/46

33 8.2.3 Concordância em Sistemas Faltosos Turek and Shasha (1992) distingues os seguinte casos: synchronous vs assynchronous - um sistema é síncrono se e somente se os processos operam no modo lock-step ; ou seja, dado que c >= 1, se algum processo está no passo c + 1, todos os outros processos estão ao menos no passo 1. communication delay - atraso de comunicação é limitado se e somente se toda mensagem é entregue dentro de um tempo global máximo predeterminado; message delivery - garantia de que as mensagens de um servidor sejam entregues na ordem em que foram enviadas. message transmission - unicast ou multicast. Luís F. Faina Pg. 33/46

34 8.2.3 Concordância em Sistemas Faltosos Fig. 8.4 Circunstâncias sob as quais acordos distribuídos podem ser alcançados, ou seja, nos outros casos não há solução. Luís F. Faina Pg. 34/46

35 8.2.3 Concordância em Sistemas Faltosos Lamport et al (1982) descreveu uma solução para o Byzantine Agreement Problem encontrado em sistemas distribuídos. assume-se que os processos são síncronos com mensagens unicast com a ordem preservada e o atraso de comunicação é restrito a valores predeterminados; considera-se um grupo de N processos, onde cada processo i envia um valor v i para os demais; assume-se que há até k processos do N são faltosos. objetivo - cada processo deve construir um vetor V de comprimento N, onde para um processo i não é faltoso, V[i] = v i, caso contrário V[i] não é definido. Luís F. Faina Pg. 35/46

36 8.2.3 Concordância em Sistemas Faltosos Fig. 8.5 Problema da Concordância Bizantina. a) cada processo envia seus valores para os demais. no 1 o passo, cada processo i não faltoso envia v i para os demais processos usando comunicação unicast confiável; processos faltosos podem enviar qualquer coisa, p.ex., processo 3 envia x para 1, y para 2 e z para 4 ; Luís F. Faina Pg. 36/46

37 8.2.3 Concordância em Sistemas Faltosos Fig. 8.5 Problema da Concordância Bizantina. a) cada processo envia seus valores para os demais. b) vetores que os processos montambaseados nos valores que recebem. no 2 o passo, os resultados dos anúncios do passo 1 o são agrupados na forma de vetores. Luís F. Faina Pg. 37/46

38 8.2.3 Concordância em Sistemas Faltosos Fig. 8.5 Problema da Concordância Bizantina. c) vetores que cada um dos processos recebe dos demais. no 3 o passo cada processo repassa o seu vetor para cada um dos demais processos do grupo de processos. Luís F. Faina Pg. 38/46

39 8.2.3 Concordância em Sistemas Faltosos como pode ser constatado, processo 3 inventa 12 novos valores, a até l como mostrado na Fig. 8.5 c). no 4 o passo, cada processo examina o i-ésimo elemento de cada um dos vetores que recebeu; se algum valor é majoritário, este valor é colocado no vetor resultante, caso contrário, o elemento correspondente é marcado no vetor resultante como não conhecido - UNKNOWN ; Obs.: Concordância bizantina estabelece o consenso por meio dos valores fornecidos pelos processos não faltosos. Luís F. Faina Pg. 39/46

40 8.2.3 Concordância em Sistemas Faltosos Fig. 8.6 Cenário semelhante ao da Fig. 8.5, exceto que com N = 3 e k = 1, 02 processo corretos e 01 faltoso. Luís F. Faina Pg. 40/46

41 8.2.3 Concordância em Sistemas Faltosos Lamport et al (1982) prova que em um sistema com k processo em falta, a concordância pode ser obtida somente se 2k + 1 processos funcionam corretamente de um total 3k + 1. basicamente, o que se precisa alcançar é o voto majoritário entre o grupo de processos não faltosos, independente se há algum processo faltoso em seu meio; com 2k + 1 processos não faltosos significa a concordância de mais de 2/3 dos votos são os mesmos. Luís F. Faina Pg. 41/46

42 8.2.4 Detecção de Falha deve estar claro que para mascarar falhas, geralmente é necessário detectá-las, o que nem sempre é tão simples; resumo - para um grupo de processos, membros não faltosos devem ser capazes de decidir quem continua como um membro e quem não, ou seja, detecção de quando um membro falha. detecção de processos com falhas - 02 mecanismos: processos tomam a decisão de enviar mensagens are you alive? para cada um dos membros do grupo e na sequência esperam por resposta; passivamente esperam por mensagem dos diferentes processos, normalmente quando há comunicação suficiente entre os processos. mas como detectar se algum processo está com falta? Luís F. Faina Pg. 42/46

43 8.2.4 Detecção de Falha timeout mechanism - pode ser usado para verificar quando um processo falhou, embora tenha 02 problemas: em razão da comunicação não confiável, estabelecer que um processo falhou simplesmente porque não respondeu a um ping pode ser errado, p.ex., por gerar falsos positivos; no falso positivo, um processo não faltoso foi removido da lista de membros, logo estamos fazendo algo errado. por fim, há muitos outros aspectos que precisam ser considerados em subsistemas de detecção de falhas. Luís F. Faina Pg. 43/46

44 8.2.4 Detecção de Falha subsistemas de detecção de faltas - necessitam distinguir quando a falta é na rede ou nós nós com a compõem. uma forma de tratar esta questão é não permitir que um nó decida quando um de seus vizinhos falhou; ao invés disso, quando perceber um timeout em uma mensagem de ping, o nó solicita a outro vizinho que verifique se o mesmo pode alcançar o nó que presumivelmente falhou; naturalmente que informações positivas devem ser compartilhadas entre os nós ou entre as partes interessadas. Luís F. Faina Pg. 44/46

45 aaa 8 Tolerância a Falhas 8.3 Comunicação Confiável Cliente/Servidor 8.3 Comunicação Confiável Cliente/Servidor Luís F. Faina Pg. 45/46

46 aaa 8 Tolerância a Falhas 8.3 Comunicação Confiável Cliente/Servidor 8.3 Comunicação Confiável Cliente/Servidor Luís F. Faina Pg. 46/46