O documento discute as arquiteturas de sistemas distribuídos, definindo componentes, conectores e estilos arquitetônicos como camadas, objetos, dados e eventos. Também aborda arquiteturas centralizadas, descentralizadas e híbridas, incluindo peer-to-peer estruturado e não estruturado.

1. Sistemas Distribuídos
Arquiteturas
Frederico Madeira
LPIC-1, LPIC-2, CCNA
fred@madeira.eng.br
www.madeira.eng.br

2. Referências
- Tanenbaum, A.; Steen, M.; Sistemas Distribuídos, princípios
e paradigmas. Capítulo 2.
- Coulouris, G.;Dollimore, J.; Kindberg, T.;
SISTEMAS DISTRIBUIDOS CONCEITOS E PROJETO. Capítulo 2.

3. ✔
Sistemas Distribuídos podem ser bem complexos
✔
Composto por componentes, muitas vezes distribuídos em
várias máquinas
✔
Estes componentes precisam ser organizados
✔
Normalmente se baseiam na organização dos compontentes
de software
✔
As Arquiteturas de Software/Sistemas nos dizem como os
diversos componentes de software devem ser organizados e
como devem interagir
Definição

4. ✔
Sistemas Distribuídos podem ser bem complexos
✔
Composto por componentes, muitas vezes distribuídos em
várias máquinas
✔
Estes componentes precisam ser organizados
✔
Normalmente se baseiam na organização dos componentes
de software
✔
As Arquiteturas de Software/Sistemas nos dizem como os
diversos componentes de software devem ser organizados e
como devem interagir
Definição

5. Modelos
• Componente = unidade modular com interfaces
requeridas e fornecidas bem definidas que é
substituído em seu ambiente
– Ele pode ser substituído, desde que sejam
respeitadas suas interfaces
• Conector = Mecanismo que serve de mediador
de comunicação e cooperação entre componentes
• Usando os itens acima, chegamos a diversos
estilos arquitetônicos, sendo os mais relevantes:
– Arquitetura em Camada
– Arquitetura baseada em Objetos
– Arquitetura centrada em dados
– Arquitetura baseada em eventos.

6. Modelos
• Arquitetura em Camadas
– Componentes são organizados em camadas
– Componentes da camada L podem chamar L+1
– Amplamente adotado pela comunidade de
redes
• OSI
• TCP/IP
– Requisições descem pela Hierarquia
– Respostas fluem para cima

7. • Arquitetura em Camadas
Modelos
Estilo Arquitetônico em camadas Modelo OSI

8. • Arquitetura em Camadas
Modelos
Estilo Arquitetônico em camadas Modelo OSI

9. Modelos
• Arquitetura baseada em Objetos
– Bem mais solta
– Cada Objeto corresponde ao que definimos
com o componente
– São conectados por chamadas de procedimento
(remoto)
– Arquitetura Cliente/Servidor se ajusta a esse
modelo
– Estilo mais importante para sistemas de grande
porte

10. • Arquitetura baseada em Objetos
Modelos
Estilo Arquitetônico baseado em objetos

11. Modelos
• Arquitetura centrada em dados
– Processos se comunicam por meio de um
repositório comum (espaço de dados
compartilhados)
– Sistemas distribuídos baseados na Web, em
grande parte, são centrados em dados
– Tão importante quanto as duas anteriores

12. Modelos
• Arquitetura baseada em eventos
– Sistema de Publicar/subscrever
– Processos publicam eventos e o middleware
assegura que somente os processos que se
subscreveram (“se inscreveram”) para esses
eventos os receberão
– Processos são fracamente acoplados
• Não precisam se referir uns aos outros =
Referencialmente desacoplados
– Podem ser combinados com a arquitetura
centrada em dados
• Resultando em um espaço compartilhado
de dados
• Processos também são desacoplado no
tempo (não precisam estar ativos quando
ocorrer a comunicação)
• Usam interface semelhante ao SQL

13. • Arquitetura baseada em eventos
Modelos
Estilo Arquitetônico baseado em eventos

14. • Relacionada ao posicionamento dos componentes de
softwares e suas interações.
– Arquiteturas Centralizadas
– Arquiteturas Descentralizadas
– Híbridas
Arquitetura de Sistemas

15. Arquiteturas Centralizadas
• Processos são distribuídos em dois grupos:
– Servidor: Processo que implementa um serviço
específico
• Ex: sistema de arquivo ou banco de dados
– Cliente: Processo que requisita um serviço
• Envia requisição e aguarda resposta
• Essa interação é conhecida como comportamento de
requisição-resposta

16. Arquiteturas Centralizadas
• Problemática: Como distinguir um cliente de um
servidor ?
• Essa distinção pode ser feita em três níveis
– Nível de Interface de usuário
– Nível de Processamento
– Nível de Dados

17. Arquiteturas Centralizadas

18. Arquiteturas Centralizadas
• Nível de Interface de usuário
– Tudo que é necessário para fazer interface
diretamente com o usuário
– Tela baseada em caracteres / Interação com a
aplicação
• Nível de Processamento
– Contém as aplicações (Núcleo do Sistema)
• Nível de Dados
– Gerencia os dados propriamente ditos sobre os quais
está sendo executada alguma ação
– Dados persistentes: ainda que nenhuma aplicação
esteja sendo executada, os dados estarão
armazenados em algum lugar para a próxima
utilização

19. Arquiteturas Multidividas

20. Arquiteturas Multidividas
• A Distinção entre 3 níveis lógicos sugere várias
possibilidades para distinção física entre a aplicação
cliente-servidor entre várias máquinas
• Os modelos apresentados nas imagens 2.5(a, c, d, e)
são cada vez menos utilizadas
– Máquinas clientes são mais problemáticas para
gerenciar
– Quando mais funcionalidades no lado do cliente mais
propenso a erro é a aplicação
– Fica mais dependente do SO do cliente e seus
recursos
– Clientes Gordos (Fat Clients)
– Clientes Magros (Thin Clients)
• A necessidade de Sistemas Distribuídos está
aumentando, uma vez que o servidor único está sendo
substituído por vários servidores.

21. Voltando a problemática: quem é o cliente e quem é o
servidor ?

22. Arquiteturas Descentralizadas
• Processamento distribuído = Organizar app client-server
como Multidividida
• Esse tipo de distribuição é conhecido como distribuição
vertical
• Distribuição Vertical = componentes logicamente
diferentes em máquinas diferentes
• Alternativamente temos:
– Distribuição Horizontal
• Cliente ou servidor pode ser fisicamente dividido
em partes logicamente equivalentes
• Cada parte opera em sua própria porção do
conjunto completo de dados
• Equilíbrio de carga
• Exemplo: Redes peer-to-peer

23. Arquiteturas peer-to-peer
• Processos deste sistema são todos iguais
• Cada processo agirá como cliente e servidor ao mesmo
tempo = Agir com SERVENTE
• Redes peer-to-peer são desenvolvidas sobre a
perspectiva de como se organizar processos em uma
rede de sobreposição
– Nós são formados pelos processos
– Enlaces representam canais de comunicação TCP
– Um processo não pode se comunicar diretamente
com outro processo arbitrário, mas envia msg via
canis de comunicação
• Dois tipos de rede de sobreposição:
– Estruturadas
– Não estruturadas

24. Arquiteturas peer-to-peer Estruturadas
• Organiza processos via Tabela de Hash Distribuída
(DHT – Distributed Hash Table)
– Itens de dados recebem uma chave aleatória com
identificador de 128 ou 160 bits.
– Os nós também recebem um número aleatório
– Sistema DHT mapeia de forma eficiente e
determinístico que a chave de um dado para o
identificador de um nó tendo como base alguma
distância métrica
• DHTs formam infra-estruturas que podem ser usadas
para construir sistemas mais complexos
– como sistema de arquivos distribuído
– compartilhamento de arquivos peer-to-peer
– sistemas de distribuição de conteúdo

25. Arquiteturas peer-to-peer Estruturadas
Fonte: Distributed hash tables

26. DHT - Histórico
• A pesquisa em DHT foi originalmente motivada, em
parte, pelos sistemas peer-to-peer como Napster,
Gnutella e Freenet:
• Esses sistemas se diferenciavam em como eles
encontravam os dados que seus peers continham:
– O Napster mantinha um banco de dados central
mapeando cada chave ao endereço do servidor que
continha o arquivo.
– Durante o join, um novo nó enviava uma lista
contendo os arquivos guardados localmente para o
servidor.
– o servidor recebia requisições dos clientes e as
direcionava para os nodos que continham os
resultados.
– Esse componente central deixava o sistema
vulnerável a ataques e apresentava problemas de
escalabilidade e elasticidade.

27. DHT - Histórico
• Gnutella e redes similares usavam um modelo de
requisições em inundação (flooding).
– Cada busca resultava numa mensagem em
broadcast para todo as outras máquinas.
– Evita o ponto único de falha,
– Significantemente menos eficiente que do Napster.
Fonte: https://cloudcolby.files.wordpress.com/2010/12/nap_gnu.gif

28. DHT - Histórico
• Freenet também era completamente distribuído.
– Requisições eram enviadas de nó em nó até o objeto
desejado ser encontrado.
– Arquivos similares tendiam a se acumular num
conjunto similar de nós,
– As requisições roteavam pela rede para o conjunto
de nós similares responsável sem a necessidade de
visitar muitos deles.
– Devido ao anonimato dos servidores, não é
garantido que um dado seria encontrado uma vez
que nenhum servidor fica responsável por um
arquivo em especial caso ele seja pouco popular na
comunidade.

29. DHT - Histórico
Fonte: Peer to Peer Routing, Freenet

30. DHT - Histórico
• Freenet também era completamente distribuído.
– Requisições eram enviadas de nó em nó até o objeto
desejado ser encontrado.
– Arquivos similares tendiam a se acumular num
conjunto similar de nós,
– As requisições roteavam pela rede para o conjunto
de nós similares responsável sem a necessidade de
visitar muitos deles.
– Devido ao anonimato dos servidores, não é
garantido que um dado seria encontrado uma vez
que nenhum servidor fica responsável por um
arquivo em especial caso ele seja pouco popular na
comunidade.

31. Arquiteturas peer-to-peer Estruturadas
• O Chord é um algorítimo que usa DHT
– Cada nó possui um sucessor e um predecessor
– Para evitar colisões, o ID do nó é gerado pelo hash
do endereço IP do nó.
– Cada chave é armazenada no nó sucessor
– A pesquisa de uma chave é realizada no sucessor do
nó

32. Arquiteturas peer-to-peer não Estruturadas
• Se baseiam em algoritmos aleatórios ara construir a
rede de sobreposição
• Cada nó possua uma lista de vizinhos
• Quando se deseja fazer uma consulta, esta é enviada
para toda a rede.

33. Superpares (superpeers)
• Problemática:
– Ausência de mecanismo de roteamento de uma
requisição de pesquisa em sistemas não
estruturados
– Quando sistemas não estruturados crescem muito,
como evitar uma inundação na mensagens na rede ?
– Temos problemas de escalabilidade ?
• Solução
– Utilização de nós especiais que mantenham um
índice de itens de dados
– Nós que mantém um índice ou agem como
intermediário são chamados de
Superpares(superpeers)
• O conceito de superpares nos leva a uma organização
hierárquica
• A comunicação entre os nós ocorrem via os superpares
• Problema de seleção do Líder (quem será o superpar ?)
• Devem ter alta-disponibilidade

34. Superpares (superpeers)

35. Arquiteturas Híbridas
• Muitos sistemas distribuídos combinam estilos
arquitetônicos
• São classes específicas de sistemas onde soluções
cliente-server são combinadas com a arquitetura
descentralizada
• Veremos duas classes:
– Sistemas de servidor de borda
– Sistemas distribuídos colaborativos

36. Sistemas de servidor de borda
• Sistemas disponibilizados na internet
• Localizados na borda da rede
– Fronteira entre as redes corporativas e a internet
propriamente dita
• Usuários finais se conectam a internet através dos
servidores de borda
• Principal função é servidor conteúdo, podendo usar
vários servidores replicados

37. Sistemas distribuídos colaborativos
• Estruturas híbridas são notavelmente dessa classe
• Em muitos casos o modelo descentralizado é usado
apenas para iniciar o sistema/solução, em seguida é
disponibilizado o esquema cliente/servidor padrão
• Exemplo: BitTorrent
– Sistema peer-to-peer de transferência de arquivos
– Usuário transfere porções do arquivo desejado a
partir de diversos outros nós da rede
– Ao mesmo tempo transfere porções do arquivo para
ouros nós que não os tenham ainda
– O arquivo desejado é endereçado através de um
arquivo .torrent que possui a descrição de um
tracker (rastreador)
– O tracker possui a contabilidade dos nós ativos e
que possuem o arquivo desejado (ou partes dele)

38. BitTorrent

39. BitTorrent

40. BitTorrent – Conteúdo do arquivo .torrent
[root@madeira ~] $ transmission-show /home/fred_m/Download/Lilo__Stitch__Dublado_.torrent
Name: (Disney) Lilo & Stitch (Dublado).avi
File: /home/fred_m/Download/Lilo__Stitch__Dublado_.torrent
GENERAL
Name: (Disney) Lilo & Stitch (Dublado).avi
Hash: 252b29f72070759269bb4e0bc3b598656cd01d8d
Created by: uTorrent/1810
Created on: Wed Dec 31 04:10:29 2008
Piece Count: 700
Piece Size: 1.00 MiB
Total Size: 733.9 MB
Privacy: Public torrent
TRACKERS
Tier #1
http://www.bj-share.net/announce.php?passkey=5741ab47d331f7ee05032750d4b66ea2
FILES
(Disney) Lilo & Stitch (Dublado).avi (733.9 MB)

41. Sistemas Distribuídos
Arquiteturas
Frederico Madeira
LPIC-1, LPIC-2, CCNA
fred@madeira.eng.br
www.madeira.eng.br