Sistemas Distribuídos – Aula 09
Download
Report
Transcript Sistemas Distribuídos – Aula 09
Redes e
Sistemas
Distribuídos II –
Cód. 30127
Prof. MSc. Ronnison Reges
Vidal
2
10/04/2015
Redes e Sistemas
Distribuídos II
Consistência e réplica, Tolerância a falhas, Sistemas de
arquivos distribuídos, Sistemas baseados em objetos
distribuídos, Sistemas de arquivos distribuídos (NFS),
Sistemas baseados em documentos distribuídos
(WWW), Sistemas baseados em coordenação
distribuídos (JINI)
Mater Christi
3
10/04/2015
Tolerância a Falhas
Introdução
Mater Christi
4
10/04/2015
Introdução
Aspecto característico dos sistemas distribuídos
Falha parcial
Uma falha pode afetar a operação adequada
de outros componentes
Objetivo importante do projeto de Sist. Dist.:
Construir o sistema de modo tal que ele possa
se recuperar automaticamente de falhas
parciais sem afetar seriamente o desempenho
global
Mater Christi
5
10/04/2015
Introdução
Sempre que um componente falhar o sistema
deve continuar a funcionar de maneira aceitável
Tolerar falhas e continuar a funcionar, mesmo na
presença de falhas
Técnica fundamental para manipulação de
falhas:
redundância
Mater Christi
6
10/04/2015
Introdução
Conceitos básicos
O que é tolerar falhas?
Relação entre tolerância a falhas e sistemas
confiáveis
Confiabilidade em sistemas distribuídos
É o conjunto de requisitos úteis para sistemas
distribuídos
Disponibilidade
Confiabilidade
Segurança
Capacidade de manutenção
Mater Christi
7
10/04/2015
Introdução
Disponibilidade
Propriedade de um sistema estar pronto
para ser usado imediatamente
É a probabilidade de um sistema estar
funcionando corretamente em qualquer
momento determinado e estar disponível
para executar suas funções em nome de
seus usuários
Mater Christi
8
10/04/2015
Introdução
Confiabilidade
É a propriedade de um sistema poder
funcionar continuamente sem falha
É definida em termos de um intervalo de
tempo em vez de um instante no tempo
Um sistema de alta confiabilidade
continuará funcionando sem interrupção
durante um período de tempo
relativamente longo
Mater Christi
9
10/04/2015
Introdução
Segurança
Refere-se a situação onde caso o sistema
deixe de funcionar num determinado
período de tempo na catastrófico
acontecerá
Se tais sistemas falharem temporariamente,
como uma usina nuclear, os efeitos seriam
desastrosos
Mater Christi
10
10/04/2015
Introdução
Capacidade
de manutenção
Facilidade com que um sistema que falhou
pode ser consertado
Um sistema de alta capacidade de
manutenção demonstra uma alta
disponibilidade, em especial se as falhas
puderem ser detectadas e reparadas
automaticamente.
Mater Christi
11
10/04/2015
Introdução
Caraterização
de problemas quanto a
tolerância a falhas
Defeito: quando um sistema não presta o
devido serviço
Erro: é uma parte do sistema que pode
levar a uma falha
Falha: Causa de um erro
Mater Christi
12
10/04/2015
Introdução
Conceito
Um sistema pode prover seus serviços
mesmo na presença de falhas
Falhas
de tolerância a falhas
são classificadas como
Transiente
Intermitente
Permanente
Mater Christi
13
10/04/2015
Introdução
Transiente
Tipo de falha que ocorre somente uma vez
depois desaparece
Exemplo
Um
pássaro que voa sobre um feixe
transmissor de micro-ondas pode causar
perdas de bits em alguma rede
Mater Christi
14
10/04/2015
Introdução
Intermitente
Ocorre e desaparece por sua própria
vontade, depois reaparece e assim por
diante. São difíceis de diagnosticar
Exemplo
Um
conector frouxo muitas vezes causará
uma falha intermitente
Mater Christi
15
10/04/2015
Introdução
Permanente
É aquele que continua a existir mesmo que
o componente faltoso seja substituído
Exemplos
Chips
queimados, bugs de software, quebra
de cabeçote de discos
Mater Christi
16
10/04/2015
Tolerância a falhas
Modelos de Falhas
Mater Christi
17
10/04/2015
Modelos de Falhas
Um
sistema que falha não fornece
adequadamente seus serviços
Exemplo
Conjunto de servidores que se comunicam
uns com os outros e com os clientes
Servidores ou canais de comunicação ou
ambos não estão fazendo o que deveriam
Quando
o servidor está funcionando mal,
nem sempre é a falha que estamos
procurando
Mater Christi
18
10/04/2015
Modelos de Falhas
Dependência
de outros servidores
podem ser a causa
As relações dependência são
abundantes em Sist. Dist.
Um disco que pode estar falhando
Dificulta
a vida de um servidor de arquivos
Altera o funcionamento de um banco de
dados distribuído
Mater Christi
19
10/04/2015
Modelos de Falhas
Classificação
de falhas
Falha por queda
Falha por omissão
Falha por temporização
Falha de resposta
Falha de transição de estado
Falha arbitrária ou falha bizante
Falha por parada
Mater Christi
20
10/04/2015
Modelos de Falhas
Falha
Quando um servidor pára
prematuramente, mas estando
funcionando corretamente até parar
Falha
por queda
por omissão
Quando um servidor não responde a uma
requisição
Mater Christi
21
10/04/2015
Modelos de Falhas
Falha
Quando uma reposta se encontra fora de
um intervalo de tempo real específico
Falha
de reposta
Falha na qual a resposta do servidor
simplesmente é incorreta
Falha
de temporização
de transição de estado
Quando o servidor reage inesperadamente
a uma requisição que chega
Mater Christi
22
10/04/2015
Modelos de Falhas
Falhas arbitrárias
Quando o servidor está produzindo saídas que
nunca deveriam ter sido produzido, mas que
não podem ser detectados como incorreto
Falhas por parada
Caracterizadas como falha por queda
Quando o servidor falha desse modo
simplesmente pára de produzir saídas de modo
tal que sua parada pode ser detectada por
outros processos
Mater Christi
23
10/04/2015
Modelos de Falhas
Tipos de falhas
Descrição
• Falha por queda
•
O servidor pára de funcionar,
mas estava funcionando
corretamente até parar
• Falha por omissão
• Omissão de
recebimento
• Omissão de envio
•
O servidor não consegue
responder a requisições que
chegam
O servidor não consegue receber
mensagens que chegam
O servidor não consegue enviar
mensagens
•
•
Mater Christi
24
10/04/2015
Modelos de Falhas
Tipos de falhas
Descrição
• Falha de temporização
•
A resposta do servidor se
encontra fora do intervalo de
tempo
• Falha de resposta
• Falha de valor
• Falha de transição de
estado
•
A resposta do servidor está
incorreta
O valor da resposta está errado
O servidor se desvia do fluxo de
controle correto
• Falha arbitrária
•
•
•
Um servidor por produzir respostas
arbitrárias em momentos
arbitrários
Mater Christi
25
10/04/2015
Tolerância a Falhas
Mascaramento de Falha por redundância
Mater Christi
26
10/04/2015
Mascaramento de Falha
por redundância
Um
sistema para ser tolerante o melhor
que pode se fazer é ocultar de outros
processos a ocorrência de falhas
Redundância
Tipos
de redundância:
Informação
Tempo
Física
Mater Christi
27
10/04/2015
Mascaramento de Falha
por redundância
Informação
São adicionados bits extras para permitir a
recuperação de bits deteriorados
Exemplo
Código
de Hamming pode ser adicionado a
dados transmitidos pera recuperá-los de
ruído na linha de transmissão
Mater Christi
28
10/04/2015
Mascaramento de Falha
por redundância
Tempo
Uma ação é realizada, e então, se for
preciso, realizada novamente
Exemplo
Transações
utilizam essa abordagem
Redundância de tempo são especialmente
utilizadas para falhas transientes e
intermitentes
Mater Christi
29
10/04/2015
Mascaramento de Falha
por redundância
Física
São adicionados equipamentos ou
processos extra para possibilitar que o
sistema como um todo tolere a perda ou o
mal funcionamento de alguns
componentes
Pode ser aplicada a hardware ou software
Exemplo
Processos extras para no caso de queda o
sistema possa continuar funcionando Mater Christi
30
10/04/2015
Tolerância a Falhas
Resiliência de Processos
Mater Christi
31
10/04/2015
Resiliência de Processos
A abordagem fundamental para tolerar um
processo faltoso é:
Organizar vários processos idênticos em um
grupo
Propriedade:
Uma mensagem que é enviada ao grupo em si,
todos os membros do grupo a recebem
Nesse caso se algum processo falhar, espera-se
que algum outro se encarregue da mensagem
em seu lugar
Mater Christi
32
10/04/2015
Resiliência de Processos
Grupos de processo podem ser dinâmicos
Novos grupos podem ser criados
Velhos grupos podem ser eliminados
Um processo pode se juntar a um grupo
Um processo pode sair de um grupo
Um processo pode ser membro de vários grupos ao mesmo
tempo
São necessário mecanismos para gerenciar grupos e
associações
A finalidade de introduzir grupos é permitir que
processos tratem conjuntos de processos como uma
abstração
Quem são, quanto são, onde estão
Mater Christi
33
10/04/2015
Resiliência de Processos
Grupos
simples versus Grupos
hierárquicos
Uma distinção importante entre grupos é o
funcionamento interno
Em alguns grupos todos são iguais
Ninguém manda e todas as decisões são tomadas
coletivamente
Em outros existe uma hierarquia
Quando uma requisição de trabalho é gerada
esta é remetida a um processo coordenador
Hierarquias mais complexas são possíveis
Mater Christi
34
10/04/2015
Resiliência de Processos
Cada uma tem suas vantagens e desvantagens
Vantagens – Grupos Simples
Os grupos simples são simétricos
Não têm ponto de falha único
Desvantagens
Tomada de decisão complexa
Votação: atraso e custo adicional
Grupos Hierárquicos
Têm propriedades opostas
A perda do coordenador pode causar parada repentina do
grupo inteiro
Entretanto enquanto está funcionando toma decisões sem se
incomodar
Mater Christi
35
10/04/2015
Resiliência de Processos
Grupos simples versus Grupos hierárquicos
Mater Christi
36
10/04/2015
Resiliência de Processos
Associação a um grupo
Método de criação e eliminação de grupos
Permite que outros processos se juntem a grupos e saiam
deles
Uma abordagem possível é a criação de um:
Servidor de grupos
Manter um banco de dados com todos os grupos e de
quem são seus associados
Método:
Direto
Eficiente
Razoavelmente fácil de implementar
Mater Christi
37
10/04/2015
Resiliência de Processos
Método:
Porém é uma abordagem centralizada
Outra abordagem:
Gerenciamento de associação ao grupo de modo
distribuído
Único ponto de falha
Multicast (confiável)
Operações de entrada e saída
Síncronas
Converter as operações de a entrada e saída integradas
ao fluxo de dados em uma sequencia de mensagens
enviadas a todo o grupo
Mater Christi
38
10/04/2015
Resiliência de Processos
Mascaramento de Falhas e Replicação
grupos de processos são parte da solução para
construir sistemas tolerantes a falhas
Ter um grupo de processos idênticos permite
mascarar um ou mais processos faltosos
Pode-se replicar processos e organizá-los em um
grupo para poder substituir um único processo
(vulnerável) por um grupo (tolerante a falhas)
Mater Christi
39
10/04/2015
Resiliência de Processos
Acordo em sistemas com falha
Considerando que processos replicados em um
grupo ajudam a aumentar a tolerância a falhas
Existe a premissa de que os processos não se juntam
para produzir um resultado errada
A complexidade é maior ao se exigir que um
grupo de processos chegue a um acordo
Exemplos:
Eleger um coordenador, decidir a validação ou não
de uma transação, repartir tarefas entre operários e
sincronização
Mater Christi
40
10/04/2015
Resiliência de Processos
Objetivo geral de algoritmos de acordo
distribuídos:
É que todos os processos que não apresentam falha
cheguem a um consenso sobre alguma questão e
estabeleçam esse consenso dentro de um número
finito de etapas
O problema é complicado pelo fato de que
premissas diferentes sobre o sistema subjacente
requer soluções diferentes
Mater Christi
41
10/04/2015
Resiliência de Processos
Distinguem-se os seguintes casos:
Sistemas síncronos versus Sistemas assíncronos
O atraso de comunicação é limitado ou não
A entrega de mensagens é ordenada ou não
A transmissão de mensagens é feita em unicast ou
multicast
Mater Christi
10/04/2015
Resiliência de Processos
Ordenação de Mensagens
Não Ordenada
Limitado
Não Limitado
x
Síncrono
Assíncrono
Ordenada
X
X
X
unicast
Multicast
X
X
Limitado
X
X
Não Limitado
unicast
Multicast
Atraso de Comunicação
Comportamento do Processo
42
Transmissão de Mensagens
Circunstâncias sob as quais se pode chegar a um acordo distrubuído
Mater Christi
43
10/04/2015
Resiliência de Processos
Detecção
de falhas
Para mascarar uma falha é necessário
detectá-la
Esta é uma das pedras fundamentais da
tolerância a falhas
No caso de um grupo de processos, os
membros não faltosos devem ser capazes
de decidir quem ainda é um membro e
quem não é
É
preciso ser capaz de descobrir quando um
Mater Christi
membro falhou
44
10/04/2015
Resiliência de Processos
Para
detectar falhas há duas maneiras:
Os processos mandam ativamente uns aos
outros mensagens “vocês está vivo?”
(esperando respostas)
Esperam passivamente a entrada de
mensagens do processos diferentes
Mater Christi
45
10/04/2015
Resiliência de Processos
A
última abordagem só faz sentido
quando se pode garantir que haja
comunicação suficiente
Usualmente é enviado pings ativamente
entre processos
Mater Christi
46
10/04/2015
Resiliência de Processos
Essência:
Falhas são detectadas através de mecanismos
de timeouts
Definir timeouts de maneira eficiente é muito difícil
e depende da aplicação
É difícil distinguir falhas dos processos das falhas da
rede
Possível Solução
Considerar possíveis notificações de falhas
entre os membros do sistema
Gossiping
Árvores onde os processos “fingem” que falharam
Mater Christi
47
10/04/2015
Tolerância a Falhas
Comunicação Confiável Cliente e Servidor
Mater Christi
48
10/04/2015
Comunicação Confiável
Cliente-Servidor
E
as falhas de comunicação?
Canais de comunicação podem exibir
falhas por queda, por omissão, de
temporização e arbitrárias
Na construção de canais de
comunicação: evitar falhas por queda e
omissão
Falhas arbitrárias podem ocorrer sob a
forma de mensagens duplicadas
Mater Christi
49
10/04/2015
Comunicação Confiável
Cliente-Servidor
Ponto-a-Ponto
O único modo de mascarar falhas de
comunicação é permitir que o sistema
tente estabelecer automaticamente uma
nova conexão, simplesmente com o
reenvio de uma requisição de conexão
Mater Christi
50
10/04/2015
Comunicação Confiável
Cliente-Servidor
Ponto-a-Ponto
5 classes de problemas que podem
acontecer em sistemas RPC
(1)
Cliente não consegue localizar o servidor
(2) A mensagem de requisição do cliente
para o servidor se perde
(3) O servidor cai após receber uma
requisição
(4) A mensagem de resposta do servidor para
o cliente se perde
(5) O cliente cai após enviar uma requisição
Mater Christi
51
10/04/2015
Tolerância a Falhas
Comunicação Confiável de Grupo
Mater Christi
52
10/04/2015
Tolerância a Falhas
Comprometimento Distribuído
Mater Christi
53
10/04/2015
Tolerância a Falhas
Recuperação
Mater Christi
54
10/04/2015
Atividade
Resumir
as 5 classes de falhas de RPC
(1) Cliente não consegue localizar o
servidor
(2) A mensagem de requisição do cliente
para o servidor se perde
(3) O servidor cai após receber uma
requisição
(4) A mensagem de resposta do servidor
para o cliente se perde
(5) O cliente cai após enviar uma
requisição
Mater Christi