Modelos de sistemas distribuídos

1. SISTEMAS
DISTRIBUÍDOS
MODELOS DE SISTEMA
1
ARTHUR EMANUEL DE OLIVEIRA
CAROSIA

2. 2
INTRODUÇÃO

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

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

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:
5
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
6
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
7
• ser vulnerável a ataques de segurança.

8. 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.
9
• Os inter-relacionamentos entre componentes.

10. 10
CAMADAS DE SOFTWARE

11. 11
CAMADAS DE SOFTWARE

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. 14
ARQUITETURAS
DISTRIBUÍDAS

15. ARQUITETURAS
DISTRIBUÍDAS
• Arquitetura cliente-servidor
15
• Arquitetura peer-to-peer

16. 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.
17
• Existe a possibilidade de um servidor pode ser cliente de
outro servidor.

18. 18
ARQUITETURA
CLIENTE-SERVIDOR

19. 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.
20
O padrão de comunicação entre os peers depende do que do
objetivo da aplicação.

21. 21
ARQUITETURA
PEER-TO-PEER

22. 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.
23
• Com a alteração dos dados, a possibilidade de atualizações
concorrentes e conflitantes aumenta.

24. REQUISITOS DE PROJETOS PARA
ARQUITETURAS DISTRIBUÍDAS
Problemas de desempenho
24
• 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:
25
aplicativos e processos de serviço devem prosseguir
concomitantemente, sem disputar os mesmos recursos.

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

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

28. MODELOS FUNDAMENTAIS
• Modelo de interação;
• Modelo de falha;
28
• 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.
29
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.
:
30
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.
31
Difícil determinar a ordenação dos eventos em um sistema
real.

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

33. MODELO DE INTERAÇÃO
Sistema Distribuído Assíncrono
33
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:
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
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

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
37
• 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
38
• 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.
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 de segurança:
Processos
•
•
Canais usados para envio de mensagens
•
•
Vulnerabilidades
Sniffers
Objetos que podem ser acessados remotamente
•
Uso não autorizado
40
•

41. 41
MODELO DE
SEGURANÇA

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

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

44. SISTEMAS
DISTRIBUÍDOS
MODELOS DE SISTEMA
44
ARTHUR EMANUEL DE OLIVEIRA
CAROSIA