cap. 08 – tolerância a falha - facomfaina/bcc_crs/gsi028-2014-1s/dl/ds-ch08.pdf · luís f....

Luís F. Faina - 2013 Pg. 1/46

Cap. 08 – Tolerância a Falha

8.1 – Introdução a Tolerância a Falha8.1.1 Conceitos Básicos

8.1.2 Modelo de Falhas

8.1.3 Mascaramento de Falha por Redundância

8.2 – Processamento de Resiliência8.2.1 Aspectos de Projeto

8.2.2 Mascaramento de Falha e Replicação

8.2.3 Concordância em Sistema de Falha

8.2.4 Detecção de Falha


… Cap. 08 – Tolerância a Falha

8.3 – Comunicação Cliente/Servidor Confiável8.3.1 Comunicação Ponto-a-Ponto

8.3.2 Semântica RPC na Presença de Falhas

8.4 – Comunicação de Grupo Confiável8.4.1 Esquema Multicast Básico Confiável

8.4.2 Escalabilidade em Multicasting Confiável

8.4.3 Multicast Atômico


… Cap. 08 – Tolerância a Falha

8.5 - “Commit” Distribuído8.5.1 “Commit” em 02 Fases

8.5.2 “Commit” em 03 Fases

8.6 – Recuperação

8.6.1 Introdução

8.6.2 Salva-guarda - “Checkpointing”

8.6.3 “Logging” de Mensagens

8.6.4 Computação Orientada por Recuperação


Referências Bibliográficas

● Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10: 0132392275, ISBN-13: 9780132392273

… Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen (“www.cs.vu.nl” e “www.distributed-systems.net/”)

● George Coulouris; Jean Dollimore; Tim Kindberg – Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN 9788560031498

● Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - www.ic.unicamp.br/~ranido/

http://www.cs.vu.nl/

http://www.distributed-systems.net/


8 Tolerância a Falhas – 8.1 Introdução

8.1 - 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.



8.1.1 – 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.



… 8.1.1 – Conceitos Básicos


● “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 conti- nuará 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.





● “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.




● “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 com- putadores, 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.




● “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.



8.1.2 – 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 prematura- mente, 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.



… 8.1.2 – Modelos de Falhas

● Outros tipos de falhas por omissão não relacionadas com comuni- caçã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.




● “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 inesperada- mente 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.




● “arbitrary failures” - também conhecidas como “byzantine failures”, é necessário preparar o cliente para o pior.

● “byzantine” - refere-se ao Império Bizantino [330 – 1453] 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.




● Fig. 8.1 – Tipos diferentes de Falhas



8.1.3 – 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 redun- dâ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).



… 8.1.3 – Mascaramento de Falha

● Fig. 8.2 - “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.




● Fig. 8.2 - “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.




● Suponha que o “A1” falha, assim cada um dos eleitores “V1”, “V2” e “V3” 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 “A2” falhar é completamente mascarado;

● … pois “B1”, “B2” e “B3” são exatamente as mesmas que seriam se nenhuma falha tivesse ocorrido.

● Agora considere o que acontece se além de “A2”, “B3” e “C1” tam- bém falham, ainda neste cenário os efeitos serão mascarados.


8 Tolerância a Falhas – 8.2 Resiliência de Processo

8.2 – Resiliência de Processo

● “resiliência” - capacidade de voltar ao seu estado natural, princi- palmente 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.



… 8.2 – Resiliência de Processo

● “resiliência” - capacidade de voltar ao seu estado natural, princi- palmente 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 con- cordância entre de um grupo de processos quando um ou mais de seus membros não mais é confiável.



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.



… 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.




● “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.




● Fig. 8.3 – a) Comunicação em “Flat Group”. b) Comunicação em Grupo Hierárquico simples.




● “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.




● … 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.



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 repli- cação: “primary-based protocols” e “replicated-write protocols”



8.2.2 – Mascaramento de Falha e Replicação

● Como discutido anterioremente, há 02 abordagens para repli- caçã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.



… 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.



… 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.



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.



… 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”.




● 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.




● “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 “vi” para os demais;

● … assume-se que há até “k” processos do “N” são faltosos.

● “objetivo” - cada processo deve construir um vetor “V” de compri- mento “N”, onde para um processo “i” não é faltoso, “V[i] = v i”, caso contrário “V[i]” não é definido.




● Fig. 8.5 – Problema da Concordância Bizantina. a) cada processo envia seus valores para os demais.

● … no 1o passo, cada processo “i” não faltoso envia “vi” 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”;




● 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 2o passo, os resultados dos anúncios do passo 1o são agrupados na forma de vetores.




● Fig. 8.5 – Problema da Concordância Bizantina. c) vetores que cada um dos processos recebe dos demais.

● … no 3o passo cada processo repassa o seu vetor para cada um dos demais processos do grupo de processos.




● … como pode ser constatado, processo “3” inventa “12” novos valores, “a” até “l” como mostrado na Fig. 8.5 c).

● … no 4o 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.




● 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.




● “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.



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 ?



… 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 conside- rados em subsistemas de detecção de falhas.



… 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 comparti- lhadas entre os nós ou entre as partes interessadas.


8 Tolerância a Falhas – 8.3 Comunicação Confiável Cliente/Servidor

8.3 – Comunicação Confiável Cliente/Servidor

● aaa

cap. 08 – tolerância a falha - facomfaina/bcc_crs/gsi028-2014-1s/dl/ds-ch08.pdf · luís f....

Documents