Tolerância a falhas em sistemas distribuídos

TOLERÂNCIAAFALHAS
VICTOR HAZIN DA ROCHA

CONCEITOSBÁSICOS
▸ Técnica fundamental para tratamento de falhas: redundância;
▸ Tolerância a falhas está relacionada à confiabilidade (dependability)
de um sistema;
▸ Requisitos para confiabilidade:
▸ Disponibilidade (availability)
▸ Confiabilidade (reliability)
▸ Segurança (safety)
▸ Capacidade de manutenção (maintainability)

DISPONIBILIDADE(AVAILABILITY)
▸ Indica que um sistema está pronto para uso imediato;
▸ Refere-se à probabilidade de que sistema está operando
corretamente num dado instante e está disponível para
executar suas funções;
▸ Alta disponibilidade indica que sistema muito
provavelmente estará funcionando num dado instante;

CONFIABILIDADE(RELIABILITY)
▸ Refere-se à propriedade que um sistema irá operar
continuamente sem falha;
▸ É deﬁnida em termos de um intervalo de tempo, ao invés
de num dado instante como ocorre com a disponibilidade;
▸ Sistema conﬁável é aquele que muito provavelmente irá
operar sem interrupção durante um período relativamente
longo de tempo;

SEGURANÇA(SAFETY)
▸ Refere-se às consequências da falha de um sistema em
operar corretamente;
▸ Sistemas críticos devem prover alto grau de segurança;

CAPACIDADEDEMANUTENÇÃO(MAINTAINABILITY)
▸ Indica a facilidade para que um sistema que falhou seja
reparado;
▸ Sistema com alta capacidade de manutenção
normalmente também apresenta alto grau de
disponibilidade, especialmente se falhas podem ser
detectadas e reparadas automaticamente;

DISPONIBILIDADEXCONFIABILIDADE
▸ Sistema que falha por 1 milissegundo a cada hora:
▸ Disponibilidade alta, acima de 99.9999 %;
▸ Conﬁabilidade baixa;
▸ Sistema que nunca cai (crashes) mas é desligado por 2
semanas no ano:
▸ Alta conﬁabilidade;
▸ Apenas 96 % de disponibilidade;

CONCEITOSBÁSICOS
▸ Defeito: se um sistema não pode cumprir suas promessas,
apresenta defeito.
▸ Ex.: Não consegue garantir as consistências prometidas.
▸ Erro: parte do estado de um sistema causado por uma
falha.
▸ Ex.: Pacotes daniﬁcados.
▸ Falha: é a causa de um erro.
▸ Ex.: Um meio de transmissão errado ou ruim pode
daniﬁcar pacotes.

CONCEITOSBÁSICOS
▸ Sistema falha quando não pode manter seus
compromissos;
▸ Um erro é uma parte do estado de um sistema que pode
levar a uma falha;
▸ Causa do erro é chamada de falta(fault);
▸ A construção de sistemas conﬁáveis (dependable) está
relacionada ao controle das faltas (faults);
▸ Faltas podem ser prevenidas, removidas e previstas.

CONCEITOSBÁSICOS
▸ Sistemas de uma máquina (não distribuídos): uma falha é
quase sempre total;
▸ Sistemas distribuídos: pode ocorrer uma falha parcial,
quando um componente do sistema falha.
▸ Objetivo: recuperar automaticamente de falhas parciais
sem afetar seriamente o desempenho global

TOLERÂNCIAAFALTAS(FAULTTOLERANCE)
▸ Signiﬁca que um sistema pode prover seus serviços
mesmo na presença de faltas;
▸ NÃO signiﬁca que falhas não vão ocorrer!!!

TIPOSDEFALHAS:
▸ Transiente:
▸ Ocorre uma vez e desaparece;
▸ Intermitente:
▸ Ocorre, para por um período indeterminado, reaparece, e
assim por diante;
▸ Permanente:
▸ Continua a existir até que o componente faltoso seja
substituído;

COMOTRATARFALTAS:
▸ Fault prevention:
▸ Prevenir a ocorrência de faltas
▸ Fault tolerance:
▸ Construir componente que possa mascarar a presença de faltas;
▸ Fault removal:
▸ Reduzir a presença, o número e a gravidade (seriousness) de
faltas;
▸ Fault forecasting:
▸ Estimar a situação atual e futura de faltas e as consequências de
suas ocorrências;

MODELOSDEFALHA
▸ Para melhor identiﬁcar as falhas, foram desenvolvidos
diversos esquemas de classiﬁcação, entre eles, o quadro
abaixo:

MASCARAMENTODEFALHAPORREDUNDÂNCIA
▸ Para o sistema ser tolerante a falhas, as ocorrências destas
devem ser ocultas de outros processos e dos usuários;
▸ A técnica fundamental para mascarar falhas é usar
redundância;

▸ Redundância de informação:
▸ bits extras para recuperação de pacotes (Hamming);
▸ Redundância de tempo:
▸ executar novamente uma ação, se for preciso;
▸ Redundância física:
▸ adicionar equipamentos ou processos extras para
possibilitar tolerância a perda ou mal funcionamento de
alguns componentes;

RESILIÊNCIADEPROCESSO
▸ Resiliência:
▸ The ability to recover quickly from illness, change, or
misfortune;
▸ The property of a material that enables it to resume its
original shape or position after being bent, stretched, or
compressed; elasticity;
▸ Proteção contra falha de processos: obtida com
replicação de processos em grupos;

▸ Diversos processos idênticos são organizados num grupo;
▸ Quando uma mensagem é enviada para um grupo, todos
os processos membros deste grupo a recebem;
▸ Se um processo no grupo falha, outro pode assumir;
▸ Grupos podem ser dinâmicos, criados e destruídos por
demanda;

▸ Processos podem entrar e sair de grupos em tempo de
execução e podem pertencer a vários grupos simultaneamente;
▸ Mecanismos devem existir para gerenciamento de grupos e
processos;
▸ Grupos permitem tratar com vários processos usando uma
abstração;
▸ Mensagens podem ser enviadas para grupos sem saber
informações sobre;

QUESTÕESDEPROJETODEGRUPOS
▸ A abordagem fundamental para tolerar um processo faltoso
é organizar vários processos idênticos em um grupo.
▸ Quando uma mensagem é enviada a um grupo, todos
membros do grupo a recebem;
▸ Se um processo falhar, espera-se que algum outro se
encarregue da mensagem em seu lugar;
▸ Grupos podem ser dinâmicos;
▸ A ﬁnalidade de introduzir grupos é permitir que
processos tratem conjuntos de processos como uma
única abstração;

GRUPOSSIMPLES(FLATGROUP)
▸ Todos processos são iguais dentro de um grupo;
▸ Ninguém manda, todas decisões são coletivas;
▸ Simétrico, sem um ponto único de falha;
▸ Tomada de decisão é mais complexa;
▸ Entrada e saída de membros no grupo feitas através de
mensagens multicast (conﬁáveis); pode ocorrer fail-stop;

GRUPOSHIERÁRQUICOS:(HIERARCHICALGROUP)
▸ Possui coordenador(es) e operários;
▸ Comunicação ocorre via coordenador;
▸ Não completamente tolerante a falhas e escalável, mas de
fácil implementação;
▸ Servidor de grupo (group server) gerencia entrada e saída
de membros no grupo;

GRUPOSSIMPLESXGRUPOSHIERÁRQUICOS

▸ Processos podem ser replicados e organizados num
grupo(tolerante a faltas) para substituir um processo único
(vulnerável);
▸ Existência de processos idênticos num grupo permite
mascarar a falha de um ou mais processos nesse grupo;
▸ Replicação pode ocorrer através de protocolos baseados
em primário (primary-based) ou com escrita
replicada(replicated-write);

▸ Primary-based: grupo é organizado de forma hierárquica e
processo primário coordena todas as operações de escrita;
▸ Se primário falha, processos backup executam
algoritmo de eleição para escolha de um novo primário;
▸ Operação na forma de replicação ativa, ou de protocolos
baseados em quórum (quorum-based);
▸ Processos idênticos operam em organização ﬂat com
coordenação distribuída;

MASCARAMENTODEFALHAEREPLICAÇÃO
▸ Questão: quanta replicação é necessária?
▸ Sistema é dito k fault tolerant(k-tolerante a faltas) se pode
sobreviver a faltas em k componentes e ainda cumprir suas
especiﬁcações;
▸ Se componentes (processos) falham silenciosamente, k+1
processos remanescentes são suﬁcientes para prover k-
tolerância a faltas;
▸ Nesse caso, se k processos falharem, processo restante provê
a resposta desejada

ACORDOEMSISTEMASCOMFALHAS
▸ Organizar processos replicados em um grupo ajuda a
aumentar a tolerância a falha. Existem várias situações:
▸ Sistemas síncronos vs. assíncronos;
▸ Atraso de comunicação limitado ou não;
▸ Entrega de mensagens ordenada ou não;
▸ Transmissão de mensagens unicast ou multicast;

▸ Esse problema, estudado pela primeira vez por Lamport
(1982), é também conhecido como problema do acordo
bizantino, consideramos problemas assíncronos,
mensagens unicast, ordenação preservada e atraso
limitado.

▸ Em um sistema com k processos faltosos pode-se
conseguir um acordo somente se estiverem presentes
2k+1 processos funcionando corretamente, para um total
de 3k+1 (ou seja, mínimo mais que 2/3).

DETECÇÃODEFALHA
▸ Mascaramento de falha requer sua identiﬁcação prévia;
▸ Membros do grupo que não têm falta devem ser capazes
de detectar quem ainda é membro do grupo e quem
apresentou falta e deve ser removido;
▸ Mecanismos:
▸ Envio de msg: “are you alive?” entre os nós, e espera
por resposta – ping ativo;
▸ Espera passiva até que mensagens cheguem dos
diferentes processos (viável apenas se há comunicação
suﬁciente (frequente) entre os nós;

DETECÇÃODEFALHA
▸ Mecanismo de timeout é usado para veriﬁcar se processo tem
falta;
▸ Problema: ausência de resposta pode indicar erroneamente
que processo tem falta;
▸ Implementação pode considerar mecanismo de gossiping,
em que nó propaga informações do seu estado aos vizinhos;
▸ Necessidade de distinguir falha da rede e falha de um
processo;

DETECÇÃODEFALHA
▸ Detecção de faltas também pode ser feita como um efeito
colateral do uso de gossiping para troca de informações
entre os vizinhos, propagando informações sobre os
estados dos nós;
▸ Eventualmente, todo processo terá informações
suﬁcientes para decidir sobre o estado dos demais e se há
processos com falta;

COMUNICAÇÃOCONFIÁVEL
CLIENTE-SERVIDOR

COMUNICAÇÃOPONTO-A-PONTO
▸ Tolerância a falta normalmente concentra-se na detecção
de falta de processo;
▸ Faltas na comunicação também devem ser consideradas;
▸ Modelos de falha também se aplicam aos canais de
comunicação: crash, omissão, timing e arbitrárias;
▸ Construção de canais de comunicação normalmente foca
no mascaramento de falhas do tipo crashe omissões;

▸ Falhas arbitrárias podem ocorrer na forma de mensagens
duplicadas, resultantes de armazenamento temporário e
retransmissões;
▸ Na comunicação ponto-a-ponto, conﬁabilidade é obtida
com o uso de protocolos de transporte conﬁável, como
TCP;
▸ Mensagens de reconhecimento e retransmissões
mascaram omissões;
▸ Falhas na conexão TCP podem ser tratadas permitindo
que SD tente estabelecer uma nova conexão;

▸ A forma mais adotada para adquirir esta transparência é
através do uso de RPC;
▸ RPCs visam esconder detalhes da comunicação, tornando
chamadas remotas semelhantes às chamadas locais;

FALHASEMRPC
‣ Falhas possíveis:
‣ Cliente não consegue localizar o servidor;
‣ Mensagem do cliente não chega ao servidor (perdida);
‣ Servidor cai (crashes) depois de receber pedido;
‣ Resposta do servidor ao cliente é perdida;
‣ Cliente cai (crashes) depois de enviar pedido;

FALHASEMRPC
▸ Cliente não consegue localizar o servidor:
▸ Servidores todos podem ter caído (down);
▸ Cliente pode estar usando versão stub antiga
incompatível com versão atual do servidor;
▸ Erro pode gerar exceção (exception– Java, ou sinal
especíﬁco – C);
▸ Nem toda linguagem tem suporte;

FALHASEMRPC
▸ Mensagem do cliente não chega ao servidor (perdida):
▸ Pode ser tratada com timer mantido pelo SO ou pelo
stub do cliente;
▸ Expiração de timeout antes de resposta ou
reconhecimento gera retransmissão;
▸ Servidor pode precisar diferenciar retransmissões de
novas chamadas;

FALHASEMRPC
▸ Servidor cai (crashes) depois de receber pedido:
▸ Possíveis tratamentos dependem do que é esperado
pelo cliente:
a. Semântica at-least-once (ao menos uma vez): sistema cliente
continua tentando (retransmitindo pedido) até uma resposta seja
recebida. Nesse caso, RPC terá sido executada ao menos1vez;
b. Semântica at-most-once (no máximo uma vez): cliente desiste
imediatamente e retorna indicação de falha. RPC terá sido
executada no máximo 1 vez, mas possivelmente nenhuma;
c. Semântica exactly once (exatamente uma vez);

FALHASEMRPC
▸ Servidor cai (crashes) depois de receber pedido;
▸ Quedas de Servidor – situações possíveis na ocorrência
de uma queda do servidor.

FALHASEMRPC
▸ Resposta do servidor ao cliente é perdida;
▸ Ausência de resposta pode gerar retransmissões depois
da expiração de temporizadores
▸ Problema: como saber se servidor recebeu pedido (e
realizou serviço)?
▸ Solução: tentar tornar operações idempotentes
(repetíveis sem efeitos indesejados)

FALHASEMRPC
▸ Resposta do servidor ao cliente é perdida;
▸ Para operações não idempotentes pode-se atribuir
número de sequência para requisições de cada cliente;
▸ Números permitem ao servidor diferenciar pedido de
retransmissões. Servidor tem que manter informações
de estado;
▸ Mensagens podem conter (bit) identiﬁcador de
retransmissão: novos pedidos podem ser realizados
imediatamente. Retransmissões requerem tratamento;

FALHASEMRPC
▸ Cliente cai (crashes) depois de enviar pedido;
▸ Problema: servidor está realizando solicitação e
mantendo recursos por nada;
▸ Computação órfã gera desperdício de recursos de
processamento;
▸ Pode haver bloqueio de recursos;

FALHASEMRPC
▸ Soluções:
▸ Client stub salva registro (log) em disco (persistente)
antes de realizar chamada RPC. Depois de um reinício
(reboot) computação órfã é explicitamente encerrada
(or rolled back): orphan extermination
▸ Possibilidade de surgimento de grandorphans, e atrasos para
acesso ao disco antes de RPCs tornam proposta não
interessante

FALHASEMRPC
▸ Soluções:
▸ Tempo é dividido em épocas; ao reiniciar, cliente
divulga uma mensagem às demais máquinas
declarando nova época. Ao receber mensagem, nó
remove todas as computações anteriores daquele
cliente. Falha na rede pode gerar órfãos ativos.
Estratégia conhecida como reencarnação
(reincarnation).

FALHASEMRPC
▸ Soluções:
▸ Gentle reincarnation: ao receber mensagem de nova
época, servidor tenta localizar todos os clientes remotos
associados. Na ausência de comunicação, computações
são encerradas.
▸ Expiration: cada RPC recebe um tempo (T) para
conclusão. Se não for concluída nesse tempo, RPC deve
negociar novo prazo. Em caso de reiniciação, servidor
pode encerrar requisições órfãs depois de tempo T.

FALHASEMRPC
▸ Problemas:
▸ Encerramento das computações órfãs pode ter
consequência imprevistas
▸ Requisições podem ter bloqueado recursos
▸ Requisições podem ter iniciado outras requisições...

COMUNICAÇÃOCONFIÁVELDE
GRUPO

MULTICASTCONFIÁVEL(RELIABLEMULTICASTING)
▸ Multicast confiável é importante para garantir que
mensagens sejam entregues a todos os processos
replicados num grupo;
▸ Protocolos de transporte oferecem comunicação confiável
apenas ponto-a-ponto;
▸ Possível abordagem para multicast confiável consiste em
criar-se vários canais unicast, um para cada receptor:
solução ineficiente;
Comunicação Confiável de G

▸ Situações envolvem diferentes aspectos se processos
membros do grupo podem variar, saindo por falha, ou
ingressando no grupo, durante transmissão de
mensagem;
▸ Como garantir que mensagem seja entregue aos
processos do grupo apenas se todos receberem?
▸ Transmissor associa número a cada mensagem
transmitida;

▸ Mensagens são transmitidas em sequência;
▸ Mensagens transmitidas são mantidas em buffer no
transmissor até que todos os destinatários conﬁrmem
recebimento;
▸ Receptores conseguem identiﬁcar mensagens fora de
ordem e geram reconhecimento negativo (negative
acknowledgment) solicitando retransmissão;

▸ Transmissor também pode manter temporizador que
indica necessidade de retransmissão em caso de ausência
de resposta;
▸ Reconhecimentos podem ser enviados “de carona” em
mensagens;

▸ Abordagem usando reconhecimento não é adequada para
grande número de receptores (não escalável);
▸ Um problema apresentado é a implosão de retorno, que pode
lotar o remetente com mensagens de confirmação de
recebimento;
▸ Solução: Não confirmar recebimento, mas apenas devolver
respostas quando detectar faltas.
▸ Gera novo problema: Quando remover mensagem enviada do
buffer?
▸ Quando fica cheio, mas pode resultar em uma retransmissão não ser honrada!
▸ Implosões de retorno ainda podem acontecer!

CONTROLEDERECONHECIMENTO(FEEDBACK)NÃOHIERÁRQUICO
▸ Proposta: Scalable Reliable Multicasting (SRM);
▸ Receptores geram notificações apenas para mensagens
não recebidas;
▸ Identificação de mensagem não recebida é deixada a
cargo da aplicação;
▸ Ao detectar falha, receptor notifica os demais processos
no grupo via multicast;

▸ Outros membros do grupo com falha não precisam
gerar notiﬁcações também;
▸ Supondo que m processos podem ter falha de
recebimento, uso de multicast gera economia de
transmissões;
▸ Atraso aleatório é introduzido antes do envio da
mensagem de feedback;

▸ Algoritmo tem boa escalabilidade, mas pode fazer com
que processos tenham que tratar transmissões de
mensagens já recebidas;
▸ Possibilidade de criação de sub-grupos; requer
gerenciamento eﬁciente de grupos;

CONTROLEDERECONHECIMENTO(FEEDBACK)HIERÁRQUICO
▸ Escalabilidade no envio de mensagens para grandes
grupos requer abordagem hierárquica;
▸ Receptores são particionados em subgrupos e
organizados na forma de uma árvore;
▸ Dentro de cada subgrupo, qualquer mecanismo de
entrega, adequado para pequenos grupos, pode ser
usado;

▸ Cada subgrupo determina um coordenador local, que
passa a ser responsável pelos envios de pedidos de
retransmissão deste subgrupo
▸ Coordenador local tem seu próprio buffer de histórico de
transmissões.
▸ Mensagens recebidas por todos no subgrupo podem ser
descartadas.
▸ Questão: diﬁculdade para construção da árvore.
▸ Normalmente, roteador multicast no grupo é usado como
coordenador

MULTICASTATÔMICO
▸ Comunicação multicast conﬁável implica que mensagens
sejam entregues a todos os processos ou a nenhum
▸ Mensagens também devem ser entregues na mesma
ordem a todos os processos
▸ Considerando que operações são replicadas em vários
processos de um grupo, aplicação das operações
depende de processos estarem em acordo sobre quem
participa do grupo (está ativo), de forma que ou todos
realizem as operações, ou nenhum

MULTICASTATÔMICO–SINCRONIAVIRTUAL

MULTICASTATÔMICO–SINCRONIAVIRTUAL
▸ Há apenas uma situação em que entrega de mensagem
pode falhar: quando participação no grupo muda como
resultado do emissor da mensagem m quebrar(crash)
▸ Nesse caso, deve ser entregue a cada um dos processos
restantes, ou pode ser ignorada por todos os membros do
grupo, como se o emissor tivesse quebrado antes do
envio
▸ Multicast conﬁável com essas características é
denominado virtualmente síncrono(virtually synchronous)

ORDENAÇÃODEMENSAGENS
▸ São distinguidas quatro ordenações diferentes:
▸ Multicasts não ordenados;
▸ Multicasts ordenados em FIFO;
▸ Multicasts ordenados por causalidade;
▸ Multicasts totalmente ordenados;

▸ Multicast conﬁável não ordenado é um multicast
virtualmente síncrono sem garantias sobre a ordem em
que mensagens recebidas são entregues aos diferentes
processos
▸ Com multicasts ordenados em FIFO, camada de
comunicação deve entregar as mensagens aos processos
na mesma ordem em que foram enviadas

▸ Multicast conﬁáveis ordenados por causalidade entregam
mensagens de forma que potenciais causalidades entre
mensagens diferentes é preservada
▸ Com multicasts totalmente ordenados, independente de
ordenações entre as mensagens, todos os processos as
recebem na mesma ordem

▸ Multicasts não ordenados;
▸ Multicasts ordenados em FIFO

▸ A entrega totalmente ordenada é aplicada em adição às
três primeiras, e signiﬁca que, independente da ordem
aplicada, a ordem de entrega deve ser a mesma em todos
os membros do grupo.
▸ Multicasts que apresentam essa propriedade são
denominados multicasts atômicos.

RECUPERAÇÃO
▸ Ocorrida uma falha, é necessário não apenas identiﬁcá-la,
mas recuperar-se da mesma e voltar para um estado
correto.
▸ Essencialmente existem 2 maneiras de se recuperar:
▸ Recuperação retroativa – volta para um estado anterior à
falha;
▸ Recuperação para a frente – tenta levar o sistema para um
novo estado correto para que possa continuar a executar.

PONTOSDEVERIFICAÇÃO
▸ Independentes:
▸ Coordenados: usam, por exemplo, bloqueio em duas fases

RECUPERAÇÃO-CARACTERIZAÇÃODEESQUEMASDEREGISTRODEMENSAGENS

REFERÊNCIAS
▸ Cap 8 Tanenbaum e van Steen - Sistemas Distribuídos:
princípios e paradigmas

Tolerância a falhas em sistemas distribuídos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Tolerância a falhas em sistemas distribuídos

Semelhante a Tolerância a falhas em sistemas distribuídos (7)

Tolerância a falhas em sistemas distribuídos