SISTEMAS
DISTRIBUÍDOS
MODELOS DE SISTEMA

1

ARTHUR EMANUEL DE OLIVEIRA
CAROSIA
2

INTRODUÇÃO
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:

3

• interagem;
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:

4

• interagem;
• são mapeados em uma rede de computadores.
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem;
• são mapeados em uma rede de computadores.
Exemplos incluem:

5

cliente-servidor
INTRODUÇÃO
Um modelo de arquitetura de um sistema distribuído:
• Define a forma pelo qual os componentes do sistema:
• interagem;
• são mapeados em uma rede de computadores.
Exemplos incluem:
cliente-servidor

6

peer-to-peer.
CONSIDERAÇÕES
Em um sistema distribuído:

• Não existe a noção de relógio global.

Toda comunicação entre processos pode sofrer:
• atrasos;
• variedade de falhas; e

7

• ser vulnerável a ataques de segurança.
8

MODELOS DE ARQUITETURAS DE
SISTEMAS DISTRIBUÍDOS
MODELOS DE ARQUITETURAS DE
SISTEMAS DISTRIBUÍDOS
Deve-se considerar:
• O posicionamento dos componentes em uma rede de
computadores.

9

• Os inter-relacionamentos entre componentes.
10

CAMADAS DE SOFTWARE
11

CAMADAS DE SOFTWARE
CAMADAS DE SOFTWARE
Plataforma
• Camadas de hardware e software de mais baixo nível.

12

• Oferecem uma interface de programação do sistema a um nível que facilita a
comunicação e coordenação entre processos.
CAMADAS DE SOFTWARE

13

Middleware
• Camada de software cujo objetivo é mascarar a heterogeneidade e fornecer
um modelo de programação conveniente.
• Implementa a comunicação e oferecendo suporte para compartilhamento de
recursos a aplicativos distribuídos.
• Ex: CORBA, JAVA RMI e Web Services.
14

ARQUITETURAS
DISTRIBUÍDAS
ARQUITETURAS
DISTRIBUÍDAS
• Arquitetura cliente-servidor

15

• Arquitetura peer-to-peer
16

ARQUITETURA
CLIENTE-SERVIDOR
ARQUITETURA
CLIENTE-SERVIDOR
• Arquitetura mais estudada e amplamente empregada.
• Processos clientes interagem com processos servidores
para acessar os recursos compartilhados que estes
gerenciam.

17

• Existe a possibilidade de um servidor pode ser cliente de
outro servidor.
18

ARQUITETURA
CLIENTE-SERVIDOR
19

ARQUITETURA
PEER-TO-PEER
ARQUITETURA
PEER-TO-PEER
• O modelo cliente-servidor não é flexível em termos de
escalabilidade:
• centraliza o fornecimento de serviços
Peer-to-peer

• processos desempenham funções semelhantes, interagindo
cooperativamente como pares (peers)
• sem distinção entre processos clientes e servidores.

20

O padrão de comunicação entre os peers depende do que do
objetivo da aplicação.
21

ARQUITETURA
PEER-TO-PEER
22

REQUISITOS DE PROJETOS PARA
ARQUITETURAS DISTRIBUÍDAS
REQUISITOS DE PROJETOS PARA
ARQUITETURAS DISTRIBUÍDAS
• O compartilhamento eficiente de dados em larga escala é
um importante desafio.

23

• Com a alteração dos dados, a possibilidade de atualizações
concorrentes e conflitantes aumenta.
REQUISITOS DE PROJETOS PARA
ARQUITETURAS DISTRIBUÍDAS
Problemas de desempenho

24

• São os desafios advindos da distribuição de recursos.
PROBLEMAS DE
DESEMPENHO
Reatividade:

os usuários exigem resposta rápida e consistente, mas os
programas clientes acessam recursos compartilhados, o que
introduz atraso de processamento.

Taxa de rendimento (throughput):
velocidade com que o trabalho computacional é feito.

Balanceamento de carga computacional:

25

aplicativos e processos de serviço devem prosseguir
concomitantemente, sem disputar os mesmos recursos.
PROBLEMAS DE
DESEMPENHO
Uso de cache:

melhorar o desempenho em sistemas distribuídos no instante em
que o cliente faz uma requisição a um servidor.
Tolerância a falhas:
desejável que as aplicações continuem a funcionar corretamente na
presença de falhas no hardware, software e comunicação.
Segurança:

26

armazenamento de dados sigilosos em sistemas distribuídos está
intimamente ligado com a necessidade de segurança contra
ataques.
MODELOS
FUNDAMENTAIS
Um modelo deve responder ás seguintes questões:
• Como são as principais entidades do sistema?
• Como elas interagem?

27

• Quais as características que afetam seu comportamento
individual e coletivo?
MODELOS FUNDAMENTAIS
• Modelo de interação;

• Modelo de falha;

28

• Modelo de segurança;
MODELO DE
INTERAÇÃO
Interação entre processos ocorre com o uso de troca de
mensagens.

O modelo de interação deve considerar que ocorrem atrasos e
isso pode limitar a coordenação dos processos.

29

Envio de mensagens Síncrono vs Assíncrono
MODELO DE
INTERAÇÃO
Sistema Distribuído Síncrono

• Tempo de cada etapa de um processo tem valores
conhecidos;
• Mensagens: são recebidas dentro de um tempo
limitado, conhecido;
• Relógio local: taxa de desvio do tempo real conhecido.

Sistema cujas restrições são difíceis de atingir.

:

30

Serve para simplificar a modelagem de um sistema real.
MODELO DE INTERAÇÃO
Sistema Distribuído Assíncrono:

Não possui considerações sobre:
• Velocidades de execução dos processos.
• Atrasos na transmissão das mensagens.
• Taxas de desvio do relógio.

31

Difícil determinar a ordenação dos eventos em um sistema
real.
MODELO DE INTERAÇÃO
Sistema Distribuído Assíncrono

32

Exemplo: sistema de troca de mensagens
MODELO DE INTERAÇÃO
Sistema Distribuído Assíncrono

33

Exemplo: sistema de troca de mensagens
MODELO DE FALHAS
A operação correta de um sistema distribuído é ameaçada
quando ocorre uma falha em qualquer um dos computadores
que ele é executado ou na rede que os interliga.

O modelo de falhas define e classifica as falhas para que os
sistemas projetados sejam capazes de:

34

• tolerar certos tipos de falhas e
• continuar funcionando corretamente.
MODELO DE FALHAS
É possível construir serviços
componentes que exibem falhas.

confiáveis

a

partir

de

35

O conhecimento das características da falha de um
componente pode permitir que um novo serviço seja projetado de
forma a mascarar a falha dos componentes dos quais depende.
MODELO DE FALHAS
Falha por omissão de processo:

Acontece quando o processo entra em colapso, parando
e não executando o outro passo de seu programa.

Indicador:

36

Timeout
MODELO DE FALHAS
Falha por omissão de processo

Sistema assíncrono:
• o processo pode ter entrado em colapso;
• estar lento;
• as mensagens podem não ter chegado;
Sistema síncrono

37

• processos deixaram de responder a mensagens
sabidamente entregues.
MODELO DE FALHAS
Na falha de omissão por comunicação

Canal de comunicação não concretiza a transferência de uma
mensagem do buffer de envio de para o buffer de recepção.
• Falta de espaço no buffer de recepção

38

• Perda de mensagens
MODELO DE
SEGURANÇA
A natureza modular dos sistemas distribuídos os expõe a
ataques de agentes externos e internos.

39

O modelo de segurança define e classifica as formas que os
ataques podem assumir, dando uma base para a análise de
possíveis ameaças a um sistema e guiar o desenvolvimento de
sistemas capazes de resistir a eles.
MODELO DE
SEGURANÇA
Precisam de segurança:

Processos
•

•

Canais usados para envio de mensagens
•

•

Vulnerabilidades

Sniffers

Objetos que podem ser acessados remotamente
•

Uso não autorizado

40

•
41

MODELO DE
SEGURANÇA
MODELO DE
SEGURANÇA
Processos interagem trocando mensagens

•

as mensagens ficam expostas a ataques na rede.

Invasor

42

• atacante capaz de enviar mensagem para qualquer
processo e ler ou copiar qualquer mensagem entre dois
processos.
MODELO DE
SEGURANÇA

43

Os ataques podem ser realizados por um computador conectado
a uma rede para executar um programa que lê as mensagens ou
por programas que gerem mensagens que façam falsos
pedidos para serviços e deem a entender que sejam
provenientes de usuários autorizados.
SISTEMAS
DISTRIBUÍDOS
MODELOS DE SISTEMA

44

ARTHUR EMANUEL DE OLIVEIRA
CAROSIA

Sistemas Distribuídos - Aula 02

  • 1.
  • 2.
  • 3.
    INTRODUÇÃO Um modelo dearquitetura de um sistema distribuído: • Define a forma pelo qual os componentes do sistema: 3 • interagem;
  • 4.
    INTRODUÇÃO Um modelo dearquitetura de um sistema distribuído: • Define a forma pelo qual os componentes do sistema: 4 • interagem; • são mapeados em uma rede de computadores.
  • 5.
    INTRODUÇÃO Um modelo dearquitetura de um sistema distribuído: • Define a forma pelo qual os componentes do sistema: • interagem; • são mapeados em uma rede de computadores. Exemplos incluem: 5 cliente-servidor
  • 6.
    INTRODUÇÃO Um modelo dearquitetura de um sistema distribuído: • Define a forma pelo qual os componentes do sistema: • interagem; • são mapeados em uma rede de computadores. Exemplos incluem: cliente-servidor 6 peer-to-peer.
  • 7.
    CONSIDERAÇÕES Em um sistemadistribuído: • Não existe a noção de relógio global. Toda comunicação entre processos pode sofrer: • atrasos; • variedade de falhas; e 7 • ser vulnerável a ataques de segurança.
  • 8.
    8 MODELOS DE ARQUITETURASDE SISTEMAS DISTRIBUÍDOS
  • 9.
    MODELOS DE ARQUITETURASDE SISTEMAS DISTRIBUÍDOS Deve-se considerar: • O posicionamento dos componentes em uma rede de computadores. 9 • Os inter-relacionamentos entre componentes.
  • 10.
  • 11.
  • 12.
    CAMADAS DE SOFTWARE Plataforma •Camadas de hardware e software de mais baixo nível. 12 • Oferecem uma interface de programação do sistema a um nível que facilita a comunicação e coordenação entre processos.
  • 13.
    CAMADAS DE SOFTWARE 13 Middleware •Camada de software cujo objetivo é mascarar a heterogeneidade e fornecer um modelo de programação conveniente. • Implementa a comunicação e oferecendo suporte para compartilhamento de recursos a aplicativos distribuídos. • Ex: CORBA, JAVA RMI e Web Services.
  • 14.
  • 15.
  • 16.
  • 17.
    ARQUITETURA CLIENTE-SERVIDOR • Arquitetura maisestudada e amplamente empregada. • Processos clientes interagem com processos servidores para acessar os recursos compartilhados que estes gerenciam. 17 • Existe a possibilidade de um servidor pode ser cliente de outro servidor.
  • 18.
  • 19.
  • 20.
    ARQUITETURA PEER-TO-PEER • O modelocliente-servidor não é flexível em termos de escalabilidade: • centraliza o fornecimento de serviços Peer-to-peer • processos desempenham funções semelhantes, interagindo cooperativamente como pares (peers) • sem distinção entre processos clientes e servidores. 20 O padrão de comunicação entre os peers depende do que do objetivo da aplicação.
  • 21.
  • 22.
    22 REQUISITOS DE PROJETOSPARA ARQUITETURAS DISTRIBUÍDAS
  • 23.
    REQUISITOS DE PROJETOSPARA ARQUITETURAS DISTRIBUÍDAS • O compartilhamento eficiente de dados em larga escala é um importante desafio. 23 • Com a alteração dos dados, a possibilidade de atualizações concorrentes e conflitantes aumenta.
  • 24.
    REQUISITOS DE PROJETOSPARA ARQUITETURAS DISTRIBUÍDAS Problemas de desempenho 24 • São os desafios advindos da distribuição de recursos.
  • 25.
    PROBLEMAS DE DESEMPENHO Reatividade: os usuáriosexigem resposta rápida e consistente, mas os programas clientes acessam recursos compartilhados, o que introduz atraso de processamento. Taxa de rendimento (throughput): velocidade com que o trabalho computacional é feito. Balanceamento de carga computacional: 25 aplicativos e processos de serviço devem prosseguir concomitantemente, sem disputar os mesmos recursos.
  • 26.
    PROBLEMAS DE DESEMPENHO Uso decache: melhorar o desempenho em sistemas distribuídos no instante em que o cliente faz uma requisição a um servidor. Tolerância a falhas: desejável que as aplicações continuem a funcionar corretamente na presença de falhas no hardware, software e comunicação. Segurança: 26 armazenamento de dados sigilosos em sistemas distribuídos está intimamente ligado com a necessidade de segurança contra ataques.
  • 27.
    MODELOS FUNDAMENTAIS Um modelo deveresponder ás seguintes questões: • Como são as principais entidades do sistema? • Como elas interagem? 27 • Quais as características que afetam seu comportamento individual e coletivo?
  • 28.
    MODELOS FUNDAMENTAIS • Modelode interação; • Modelo de falha; 28 • Modelo de segurança;
  • 29.
    MODELO DE INTERAÇÃO Interação entreprocessos ocorre com o uso de troca de mensagens. O modelo de interação deve considerar que ocorrem atrasos e isso pode limitar a coordenação dos processos. 29 Envio de mensagens Síncrono vs Assíncrono
  • 30.
    MODELO DE INTERAÇÃO Sistema DistribuídoSíncrono • Tempo de cada etapa de um processo tem valores conhecidos; • Mensagens: são recebidas dentro de um tempo limitado, conhecido; • Relógio local: taxa de desvio do tempo real conhecido. Sistema cujas restrições são difíceis de atingir. : 30 Serve para simplificar a modelagem de um sistema real.
  • 31.
    MODELO DE INTERAÇÃO SistemaDistribuído Assíncrono: Não possui considerações sobre: • Velocidades de execução dos processos. • Atrasos na transmissão das mensagens. • Taxas de desvio do relógio. 31 Difícil determinar a ordenação dos eventos em um sistema real.
  • 32.
    MODELO DE INTERAÇÃO SistemaDistribuído Assíncrono 32 Exemplo: sistema de troca de mensagens
  • 33.
    MODELO DE INTERAÇÃO SistemaDistribuído Assíncrono 33 Exemplo: sistema de troca de mensagens
  • 34.
    MODELO DE FALHAS Aoperação correta de um sistema distribuído é ameaçada quando ocorre uma falha em qualquer um dos computadores que ele é executado ou na rede que os interliga. O modelo de falhas define e classifica as falhas para que os sistemas projetados sejam capazes de: 34 • tolerar certos tipos de falhas e • continuar funcionando corretamente.
  • 35.
    MODELO DE FALHAS Épossível construir serviços componentes que exibem falhas. confiáveis a partir de 35 O conhecimento das características da falha de um componente pode permitir que um novo serviço seja projetado de forma a mascarar a falha dos componentes dos quais depende.
  • 36.
    MODELO DE FALHAS Falhapor omissão de processo: Acontece quando o processo entra em colapso, parando e não executando o outro passo de seu programa. Indicador: 36 Timeout
  • 37.
    MODELO DE FALHAS Falhapor omissão de processo Sistema assíncrono: • o processo pode ter entrado em colapso; • estar lento; • as mensagens podem não ter chegado; Sistema síncrono 37 • processos deixaram de responder a mensagens sabidamente entregues.
  • 38.
    MODELO DE FALHAS Nafalha de omissão por comunicação Canal de comunicação não concretiza a transferência de uma mensagem do buffer de envio de para o buffer de recepção. • Falta de espaço no buffer de recepção 38 • Perda de mensagens
  • 39.
    MODELO DE SEGURANÇA A naturezamodular dos sistemas distribuídos os expõe a ataques de agentes externos e internos. 39 O modelo de segurança define e classifica as formas que os ataques podem assumir, dando uma base para a análise de possíveis ameaças a um sistema e guiar o desenvolvimento de sistemas capazes de resistir a eles.
  • 40.
    MODELO DE SEGURANÇA Precisam desegurança: Processos • • Canais usados para envio de mensagens • • Vulnerabilidades Sniffers Objetos que podem ser acessados remotamente • Uso não autorizado 40 •
  • 41.
  • 42.
    MODELO DE SEGURANÇA Processos interagemtrocando mensagens • as mensagens ficam expostas a ataques na rede. Invasor 42 • atacante capaz de enviar mensagem para qualquer processo e ler ou copiar qualquer mensagem entre dois processos.
  • 43.
    MODELO DE SEGURANÇA 43 Os ataquespodem ser realizados por um computador conectado a uma rede para executar um programa que lê as mensagens ou por programas que gerem mensagens que façam falsos pedidos para serviços e deem a entender que sejam provenientes de usuários autorizados.
  • 44.