Sistemas Distribuídos
description
Transcript of Sistemas Distribuídos
Sistemas DistribuídosFrancisco Brasileiro
Aula 2: Modelos de Sistemas Distribuídos
As figuras que aparecem nesses slides são de Veríssimo&Rodrigues, reproduzidas com o consentimento dos mesmos.
Como aumentar a nossa intuição para resolver problemas?
• Experimentação– abordagem prática baseada no acúmulo de informação– pode ser usada para construir coisas similares a outras
já construídas• Modelagem e análise
– abordagem teórica baseada na simplificação do objeto de estudo (“mundo real”) = criação do modelo
– seguida de análise - matemática ou lógica - para inferir propriedades
• Modelagem e simulação– criação do modelo– simulação do modelo no computador
Trade-offs
• modelagem oferece mais “controle” sobre a intuição adquirida
• modelagem só é útil se o modelo caracteriza o objeto de estudo de forma apropriada
• simulação é mais poderosa e menos genérica que análise
• experimentação é muito importante para validar modelos
Simulação
• Alternativa à experimentação– Mais próximo do sistema real, com um custo
muito menor que o sistema real
• Alternativa à analise– Permite analisar situações que não podem ser
modeladas de forma tratável/representativa
• Precisa ser validada– Testes automáticos são fundamentais para se
reduzir a chance de bugs
O que é um bom modelo?
• Preciso– a análise do modelo deve levar a conclusões
verdadeiras sobre o objeto de estudo
• Tratável– um modelo que não permite a execução de
uma análise ou simulação é inútil– em um modelo tratável, as regras que
governam o comportamento dos atributos do modelo são normalmente definidas através de fórmulas matemáticas ou lógicas
Que respostas um bom modelo pode dar?
• Viabilidade– Que classes de problemas podem ser resolvidos
• Custo– Para as classes que podem ser resolvidas, quão cara
(em termos de recursos, tempo de processamento, etc.) uma solução precisa ser
• Perfomance– Como uma solução se compara com outra
• As respostas têm valor prático e teórico
Modelos para sistemas distribuídos: um exemplo
• O problema da coordenação– Dois processos, A e B, se comunicam através
de troca de mensagens. Nenhum processo falha, mas o canal de comunicação pode perder mensagens. Construa um protocolo que permita que ou a ação ou a ação possa ocorrer, mas (i) A e B executam a mesma ação, e (ii) nenhum executa ambas as ações.
Prova de impossibilidade
• suponha que existe um protocolo que resolve o problema• tal protocolo envolve troca de mensagens entre A e B• vamos escolher o protocolo que resolve o problema com o
número mínimo de trocas de mensagens (i.e. não existe um protocolo que use menos mensagens) e, sem perda de generalidade, assumir que m, a última mensagem enviada no protocolo, foi enviada por A
• mas m poderia ter sido perdida!!!• as ações tomadas por A e B não dependem de m, portanto
m é supérflua e é possível construir um protocolo com uma mensagem a menos; uma contradição!
Vamos entender melhor o que fizemos
• Nós concluímos que o Problema da Coordenação não tem solução para o modelo definido usando duas observações:– todos os protocolos distribuídos entrem os dois
processos são equivalentes a uma série de trocas de mensagens; e
– ações tomadas por um processo dependem apenas da seqüência de mensagens recebidas.
• A partir desse modelo, nossa “intuição” sobre o problema pode ser refinada
Quais são os atributos mais importantes de um sistema
distribuído?• Atrasos no escalonamento e na
transmissão de mensagens– síncronos x assíncronos
• Semântica de falha dos componentes– crash– omissão– desempenho– valor– arbitrária (Bizantina)
Sistemas distribuídos assíncronos
• Nenhuma restrição em relação aos atrasos de escalonamento e de transmissão de mensagens
• Falhas arbitrárias• Resultado de impossibilidade de Fischer, Lynch e
Patterson (FLP, FLP85)– Não há como obter acordo, mesmo que só um processo
falhe e mesmo que a semântica seja crash– Esse modelo assíncrono serve para alguma coisa?
Modelo síncrono
• Características do modelo– Atrasos máximos conhecidos para
escalonamento (), para transmissão de mensagens () e drift dos relógios locais ()
• Sistemas construídos assumindo esse modelo são:– menos portáveis– potencialmente menos seguros
Modelos parcialmente assíncronos
• Assumem que há algum sincronismo no sistema• Duas “escolas” principais
– Sincronismo no tempo• Sistemas que não são sempre assíncronos• Ex. timed asynchronous model (Fetzer&Cristian), quase-
synchronous (Veríssimo&Almeida)
– Sincronismo no espaço• Sistemas que não são completamente assíncronos• Ex. timely computing base (Veríssimo&Casimiro&Fetzer),
GMDC (Fubica&Ely&Andrey), detectores de falha (Chandra&Toueg)
Encapsulando Sincronismo:Detectores de falhas
• Exatidão do detector: que erros podem acontecer– Forte: Nenhum processo correto é considerado falho– Fraca: Pelo menos um processo correto nunca é
considerado falho
• Abrangência do detector: que falhas são detectadas– Forte: Uma falha é detectada por todos os processos– Fraca: Uma falha é detectada por pelo menos um
processo
• Eventualidade– Condição só se aplica depois de um certo tempo
Classes de Detectores de Falha
• O detector perfeito só pode ser implementado em um sistema síncrono!!
• Mas vários problemas podem ser resolvidos se o sistema assíncrono for complementado por detectores de falha imperfeitos!!– Em particular S é de grande interesse prático
Como escolher um modelo?
• Características do ambiente de execução– Tipos dos componentes– Qualidade dos componentes– Controle sobre o ambiente
• Requisitos da aplicação– Aplicações críticas