Cap. 08 Tolerância a Falha

(1)

Cap. 08 – Tolerância a Falha

8.1 – Introdução a Tolerância a Falha

8.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ência

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

(2)

… Cap. 08 – Tolerância a Falha

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

8.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ável

8.4.1 Esquema Multicast Básico Confiável

8.4.2 Escalabilidade em Multicasting Confiável 8.4.3 Multicast Atômico

(3)

… Cap. 08 – Tolerância a Falha

8.5 - “Commit” Distribuído 8.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

(4)

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

(5)

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.

(6)

8.1.1 – Conceitos Básicos

● … para melhor entender o papel da tolerância a falha em siste-

mas 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á

(7)

… 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

(8)

… 8.1.1 – Conceitos Básicos

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

(9)

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

(10)

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

(11)

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.

(12)

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

(13)

… 8.1.2 – 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 inesperada-

mente a uma requisição que chega.

● … servidor recebe uma msg e não pode reconhecer, o que gera uma falha

(14)

… 8.1.2 – 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 [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.

(15)

… 8.1.2 – Modelos de Falhas

(16)

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

(17)

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

(18)

… 8.1.3 – Mascaramento de Falha

● 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

(19)

… 8.1.3 – Mascaramento de Falha

● Suponha que o “A₁” falha, assim cada um dos eleitores “V₁”, “V₂” e

“V₃” 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₂” falhar é completamente mascarado;

● … pois “B₁”, “B₂” e “B₃” são exatamente as mesmas que seriam se

nenhuma falha tivesse ocorrido.

● Agora considere o que acontece se além de “A₂”, “B₃” e “C₁” tam-

(20)

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

(21)

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

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

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

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

(25)

… 8.2.1 – Questões de Projeto

● Fig. 8.3 – a) Comunicação em “Flat Group”. b) Comunicação em

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

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

(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 repli-

(29)

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

(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

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

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

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

(34)

… 8.2.3 – Concordância em Sistemas Faltosos

● Fig. 8.4 – Circunstâncias sob as quais acordos distribuídos podem

(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 compri-

mento “N”, onde para um processo “i” não é faltoso, “V[i] = v_i”, caso contrário “V[i]” não é definido.

(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 1o 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.,

(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 2o passo, os resultados dos anúncios do passo 1o são

(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 3o passo cada processo repassa o seu vetor para cada um

(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 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

(40)

… 8.2.3 – Concordância em Sistemas Faltosos

● Fig. 8.6 – Cenário semelhante ao da Fig. 8.5, exceto que com

(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

(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, normal-

(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 conside-

(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 mensa-

gem 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-

(45)

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

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

(46)

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