1

SISTEMAS DISTRIBUÍDOS

MODELOS DE SISTEMA

ARTHUR EMANUEL DE OLIVEIRA CAROSIA

2

INTRODUÇÃO

3

INTRODUÇÃO

Um modelo de arquitetura de um sistema distribuído:

• Define a forma pelo qual os componentes do sistema:

• interagem;

4

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.

5

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

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

peer-to-peer.

7

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

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

8

MODELOS DE ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS

9

MODELOS DE ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS

Deve-se considerar:

• O posicionamento dos componentes em uma rede de computadores.

• Os inter-relacionamentos entre componentes.

10

CAMADAS DE SOFTWARE

11

CAMADAS DE SOFTWARE

12

CAMADAS DE SOFTWAREPlataforma

• Camadas de hardware e software de mais baixo nível.

• 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 SOFTWAREMiddleware• 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

15

ARQUITETURAS DISTRIBUÍDAS• Arquitetura cliente-servidor

• Arquitetura peer-to-peer

16

ARQUITETURA CLIENTE-SERVIDOR

17

ARQUITETURA CLIENTE-SERVIDOR• Arquitetura mais estudada e amplamente empregada.

• Processos clientes interagem com processos servidores para acessar os recursos compartilhados que estes gerenciam.

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

18

ARQUITETURA CLIENTE-SERVIDOR

19

ARQUITETURA PEER-TO-PEER

20

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.

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

23

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

um importante desafio.

• Com a alteração dos dados, a possibilidade de atualizações concorrentes e conflitantes aumenta.

24

REQUISITOS DE PROJETOS PARA ARQUITETURAS DISTRIBUÍDASProblemas de desempenho

• São os desafios advindos da distribuição de recursos.

25

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:

aplicativos e processos de serviço devem prosseguir concomitantemente, sem disputar os mesmos recursos.

26

PROBLEMAS DE DESEMPENHOUso 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:

armazenamento de dados sigilosos em sistemas distribuídos está intimamente ligado com a necessidade de segurança contra ataques.

27

MODELOS FUNDAMENTAIS

Um modelo deve responder ás seguintes questões:

• Como são as principais entidades do sistema?

• Como elas interagem?

• Quais as características que afetam seu comportamento individual e coletivo?

28

MODELOS FUNDAMENTAIS• Modelo de interação;

• Modelo de falha;

• Modelo de segurança;

29

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.

Envio de mensagens Síncrono vs Assíncrono

30

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.

Serve para simplificar a modelagem de um sistema real.

:

31

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.

Difícil determinar a ordenação dos eventos em um sistema real.

32

MODELO DE INTERAÇÃOSistema Distribuído Assíncrono

Exemplo: sistema de troca de mensagens

33

MODELO DE INTERAÇÃOSistema Distribuído Assíncrono

Exemplo: sistema de troca de mensagens

34

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:

• tolerar certos tipos de falhas e • continuar funcionando corretamente.

35

MODELO DE FALHAS

É possível construir serviços confiáveis a partir de componentes que exibem falhas.

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

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:

Timeout

37

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

• processos deixaram de responder a mensagens sabidamente entregues.

38

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

• Perda de mensagens

39

MODELO DE SEGURANÇA

A natureza modular dos sistemas distribuídos os expõe a ataques de agentes externos e internos.

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 de segurança:

• Processos• Vulnerabilidades

• Canais usados para envio de mensagens• Sniffers

• Objetos que podem ser acessados remotamente• Uso não autorizado

41

MODELO DE SEGURANÇA

42

MODELO DE SEGURANÇA

Processos interagem trocando mensagens

• as mensagens ficam expostas a ataques na rede.

Invasor

• atacante capaz de enviar mensagem para qualquer processo e ler ou copiar qualquer mensagem entre dois processos.

43

MODELO DE SEGURANÇAOs 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.

44

SISTEMAS DISTRIBUÍDOS

MODELOS DE SISTEMA

ARTHUR EMANUEL DE OLIVEIRA CAROSIA