Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Tolerância a falhas

No description
by

Dirceu Semighini Filho

on 30 March 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Tolerância a falhas

62
ECG
bpm
Exercício
Modelos de falha
Queda
Omissão
Tempo
Resposta
Arbitrária
Redundância
Esconder os erros
Tipos
Informação
Tempo
Física

Resiliência de processo
Implementação da tolerância a falha
Mascaramento de falha e replicação
Replicaçao de grupos
Definição da quantidade de replicação
Tendo X processos falhos
X + 1 é considerado tolerante
Falhas Bizantinas
2X +1
Comunicação Confiável entre Cliente e Servidor
Falhas de comunicação também devem ser analisadas
Mascaramento de falha por redundância
O que é tolerância a falha?
Falha parcial

Tolerância a falhas
Falha parcial
Falha de um componente
Operação Atomica
Ou grava tudo ou falha
62
ECG
bpm
Conceitos básicos
Disponibilidade
Confiabilidade
Segurança
Manutenção
Falha e erro
Falha
Sistema não consegue cumprir as funções para qual foi desenvolvido
Causa do erro é uma falha
Erro
Estado do sistema que leva a uma falha
Introdução a tolerância a falhas
Disponibilidade
Sistema está sempre disponível
Probabilidade do sistema estar disponível
24 / 7
Confiabilidade
Tempo em que o sistema permanece disponível sem interrupções
Confiabilidade vs Disponibilidade
Segurança
Na falha o sistema permanece funcionando
Exemplos: Metro, piloto automático

Manutenção
Facilidade do sistema retornar após uma falha
Manutenção automática
Fácil manutenção = alta disponibilidade
Falha transiente
Ocorrem uma vez e não se repete mais
Causas diversas
falha hardware
pássaro no caminho de uma comunicação
Intermitente
Acontece algumas vezes e para
Depois volta a acontecer
Exemplo
Erros de lock

Permanente
Acontecem sempre
Aquelas que precisam de uma correção
Falha de Omissão
Falha na resposta
Omissão de recebimento
Omissão de envio
Falha de software
Falha de resposta
Uma das mais graves
Causada por uma resposta inválida
Tipos:
Falha de valor
Falha de estado
Falha de Queda
Servidor desliga prematuramente
Funcionava antes da queda
Nada vem dele após a queda

Falha arbitrária
Mais grave de todas
Conhecida como falha bizantina
Clientes devem esperar o pior
Servidor produz resposta não planejada
Servidor programado para produzir mensagens inválidas, em conjunto com outros
Falha de resposta por tempo (Timeout)
Resposta chega após um tempo máximo
Uma resposta rápida pode gerar falha de memória
Comumente mensagem atrasa
Causada por problema de performance
Omissão de recebimento
Mensagem nunca chega
Mesmo quando uma conexão está aberta
Não há serviço para as mensagens
Omissão de Envio
Mensagem é processada
Resposta não é enviada
Conexão é estabelecida
Existe um serviço para processar a mensagem
Servidor preparado para reprocessamento
Omissão por falha de Software
Loop infinito
Mau gerenciamento da memória

Falha de valor
Resposta com valor inválido
Fora do range esperado
Tipo inválido
Causada por
Bug de implementação

Falha de estado de transição
Reação inesperada a uma requisição
Servidor não consegue tratar mensagem
Não existe medida preventiva a falha
Redundância da informação
Informação é repetida
Bits adicionados a mensagem
Permitem recuperação dela
Exemplo:
Protocolo de rede
Redundância Tempo
Reprocessadas após um tempo
Transações de banco de dados
Repetem em caso de falha

Redundância física
Máquinas extras adicionadas a rede
Suporta falhas das máquinas do sistema
Suporta aumento de requisições
Problemas de design
Divisão dos processos em grupos
Toda mensagem deve ser enviada a todos os membros
Grupos = Abstração simples
Ao enviar uma mensagem, não se sabe quem são nem quantos são
horizontais vs hierarquicos
Horizontais
Não há lider
Decisões tomadas coletivamente
Não possuem ponto de falha único
Simétrico - Ao falhar o grupo diminui
Tomada de decisão complicada
Hierárquicos
Processo coordenador
Coordenador decide quem irá processar a requisição
Para na falha do coordenador
Processo de decisão rápido e simples
Membro do grupo
Administrador de membros do grupo
Servidor para manter dados dos membros
Administração distribuída através de multicasting
Entrada ou saída do grupo é síncrona
Protocolo de reconstrução é utilizado qto há muitas falhas
Protocolo de reconstrução deve ser único
Acordos em sistemas falhos
Múltiplos processos responsáveis por uma ação
Commit
Com sistema funcionando é fácil
Quando falha, complicação a vista
Definir consenso dos processos corretos
Síncrono vs Assíncrono
Síncrono
Relógio controla processamento
Cada passo do relógio todos os processos executam

Assíncrono
Processos escalonam para executar
Prioritários executam.
Tempo de conexão limitado ou não
Tempo limitado
Ocorre quando há garantia de entrega de todas mensagens
Transmissão
Unicast
Mensagem enviada para um ponto
Multicast
Mensagem enviada para vários pontos
Problema de acordo Bizantino
Considerando um grupo de 4 processos
Cada processo envia mensagem a todos outros
Cada processo tem 3 valores em vetor
Soma do vetor, a maioria vence
Processo falho envia mensagens aleatórias
Não funciona quando não há garantia de entrega
Ordem
Entrega ordenada
Ordem de entrega = ordem de envio
Detecção a falha
Ponto importante no mascaramento
Duas maneiras de se detectar
Envio de mensagem perguntando
Espera passivamente receber mensagem do processo
Timeout
Alto número de Falso positivo
Muito básico
Protocolo de fofoca
Eventualmente atinge todos do grupo
Diferenciar falha de comunicação de falha de processamento
Comunicação ponto a ponto
Comunicação confiável
Protocolos confiáveis - TCP
Omite falhas de omissão
Falhas de colisão não podem ser mascaradas
Conexão para abrutamente
Mascaramento através da reconexão/reenvio
Semântica RPC na presença de falhas
Comunicação de um RPC
Objetivo do RPC é mascarar chamadas
Emula chamadas locais
Perda da mensagem de resposta
Difícil de lidar
Solução simples:
timeout
Mensagem é reenviada
Soluciona alguns casos
Selects podem ser reenviados
Updates não
Estruturar processos
Inserir contador nas mensagens
Ordem das mensagens
Bit verificador marca retransmissão
Cliente não localiza servidor
Todos os servidores estão desligados
Versão de serviço incompatível
Solução
Disparo de exceções ou sinais
Nem todas linguagens possuem exceções ou sinais
Quebra de transparência
Mensagem de requisição perdida
Solução
Usar um contador de mensagens
Reenviar após timeout
Servidor não distingue cópia da original
Mais fácil dos erros

Queda do servidor
Dois caminhos de falha possíveis
Mensagem é processada
Mensagem não processada
Três filosofias de solução
Espera reinicio do servidor e reexecuta a mensagem
Desiste e emite mensagem de erro
Não garante nada, não reexecuta

Queda do cliente
Envia e morre antes da resposta
Gera processos orfãos

Caso de Exemplo
Instrução de impressão
E quando o servidor de impressão cai?
4 Estratégias do cliente
RPC distribuído
8 Caminhos possíveis
Nenhum deles é satisfatório
RPC != Sistemas simples
Não reenviar
Assume o risco de nunca ser impresso
Reenviar sempre
Assume o risco de imprimir 2 cópias
Reenviar em caso de não confirmação
Assume que o servidor caiu antes de receber a mensagem
Reenviar sempre que receba uma confirmação
Assume que o servidor recebeu mas não processou a mensagem
Armazena mensgem no log
Log deve sobreviver ao reinício
Ao reiniciar
Mata todas mensagens que estão no log
Desvantagens
Custo da escrita
Espaço usado pelo log
Processos órfãos podem criar filhos
Problema de rede impede a eliminação
Reincarnação
Definição de épocas
Cada reinício cria uma época
Todos os filhos são eliminados
Problema de rede
Impede eliminação de alguns processos
Respostas dests clientes são descartadas
Reincarnação Gentil
Ao receber mensagem de época
Tenta achar donos dos processos locais
Só elimina os órfãos

Expiração
Toda mensagem tem um tempo de vida T
Processo pode pedir prorrogação
Servidor aguarda T antes de matar
É possível eliminar todos os órfãos
Problema
Determinar um tempo T ideal
Full transcript