1 / 16

Sistemas Distribuídos

Sistemas Distribuídos. Francisco 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

tana
Download Presentation

Sistemas Distribuídos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistemas Distribuídos Francisco 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.

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

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

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

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

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

  7. 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 a ou a ação b possa ocorrer, mas (i) A e B executam a mesma ação, e (ii) nenhum executa ambas as ações.

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

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

  10. 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)

  11. 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?

  12. Modelo síncrono • Características do modelo • Atrasos máximos conhecidos para escalonamento (s), para transmissão de mensagens (d) e drift dos relógios locais (r) • Sistemas construídos assumindo esse modelo são: • menos portáveis • potencialmente menos seguros

  13. 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)

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

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

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

More Related