Prof.

Luiz Fernando Bi1encourt IC - UNICAMP

MC714
Sistemas Distribuídos
1° semestre, 2017
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas
•  Componentes de sistema distribuído espalhados
por diversas máquinas.
•  Controle demanda organização.
•  Organização lógica do soRware e organização
Tsica dos componentes.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Software
•  Componentes de soRware consUtuem o sistema.
•  Arquitetura de soRware
•  Como vários componentes estão organizados
•  Como devem interagir

•  Arquiteturas centralizadas, arquiteturas

descentralizadas, arquiteturas híbridas
•  Separar aplicações das plataformas subjacentes:
middleware
•  Várias técnicas para alcançar transparência, e
que afetam o próprio middleware
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Software – sistemas autonômicos

•  Também é possível conseguir adaptabilidade
fazendo o sistema monitorar seu próprio
comportamento.
•  Sistemas autonômicos
•  Realimentação de informação
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Estilos arquitetônicos
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Estilos arquitetônicos
•  Organização lógica do sistema em componentes
de soRware – arquitetura de soRware
•  EsUlo arquitetônico: componentes, modo como
estão conectados, dados trocados, como são
configurados para formar o sistema
•  Componente: unidade modular com interfaces
requeridas e fornecidas bem definidas;
subsUtuível.
•  Conector: mecanismo que serve de mediador da
comunicação entre componentes.
•  Facilidades para chamadas de procedimento (remotas),
passagem de mensagem, fluxo de dados.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Estilos arquitetônicos
•  Várias configurações usando componentes e
conectores.
•  Arquitetura em camadas.
•  Arquiteturas baseadas em objetos.
•  Arquiteturas centradas em dados.
•  Arquiteturas baseadas em eventos.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura em camadas
•  Um componente da camada Li tem permissão de
chamar componentes na camada subjacente
Li-1 , mas não o contrário.
•  Adotado em redes.
•  Em geral requisições descem pela hierarquia,
resultados sobem.
•  Fig. 31.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura baseada em objetos

•  Cada objeto, em essência, corresponde a um
componente.
•  Conexão através de chamada de procedimento
remoto.
•  Se ajusta à arquitetura cliente-servidor.
•  Fig. 32.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura centrada em dados

•  Processos se comunicam por um repositório
comum.
•  Em sistemas distribuídos, tão importante quanto
camadas e objetos.
•  Muitas aplicações se comunicam por escrita/
leitura de arquivos comparUlhados.
•  Sistemas web possuem processos que se
comunicam por meio de serviços de dados web.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura baseada em eventos

•  Processos se comunicam por meio de
propagação de eventos que podem transportar
dados.
•  Associado a sistemas publish/subscribe.
•  Processos publicam eventos; middleware
transmite somente para assinantes.
•  Processos fracamente acoplados; não precisam
se referir explicitamente uns aos outros.
•  Fig. 33.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura baseada em eventos

•  Pode ser combinada com arquiteturas centradas
em dados, resultando em espaços
comparUlhados de dados.
•  Processos desacoplados no tempo: não precisam ambos estarem
aUvos para realizar comunicação.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas de software
•  Visam obter nível razoável de transparência de
distribuição.
•  Compromisso entre desempenho, tolerância a
falha, facilidade de programação.
•  Dependente de requisitos/aplicações: não há um sistema para
cobrir tudo.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas de sistema
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura de sistema
•  Onde são colocados os componentes de
soRware.
•  Centralizada, descentralizada, híbrida.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura centralizada
•  Processos divididos em dois grupos: clientes e
servidores.
•  Servidor implementa um serviço específico.
•  Cliente requisita um serviço enviando uma
requisição e aguarda resposta.
•  Clientes requisitam serviços de servidores.
•  Comportamento de requisição-resposta.
•  Fig. 34.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura centralizada
•  Cliente-servidor pode ser implementado por
meio de um protocolo simples de comunicação
se rede é confiável.
•  Empacota mensagem idenUficando serviço
desejado junto com dados necessários.
•  Mensagem é enviada; servidor aguarda
requisição, processa e empacota resultados em
uma mensagem de resposta.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura centralizada
•  Aplicação: protocolo de comunicação.
•  Confiabilidade versus eficiência; sem conexão,
com conexão; retransmissão.
•  Depende da aplicação.
•  Retransmissão de mensagem: transfira R$1.000 da minha
conta.
•  Retransmissão de mensagem: qual o saldo da minha conta?
•  Operação repeUda sem danos: idempotente.
•  Diversas maneiras de tratar falhas, dependendo do Upo de
mensagem perdida.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquitetura centralizada
•  Muitos sistemas uUlizam protocolos confiáveis orientados à
conexão.
•  TCP/IP.
•  Primeiro estabelece conexão, depois envia requisição.
•  Servidor pode usar a mesma conexão para enviar resposta.
•  Conexão pode ser caro.
•  Estabelecer e encerrar conexão pode ocupar maior parte do
tempo, principalmente se mensagens de requisição e resposta
são pequenas.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Camadas de aplicação
•  Cliente-servidor: quem é quem?
•  Ex: banco de dados recebe consultas, mas
somente realiza requisições a sistemas de
arquivos que implementam as tabelas.
•  Banco de dados apenas faz consultas.
•  Muitas aplicações cliente-servidor visam dar
suporte aos usuários de bancos de dados: três
níveis.
•  1. Interface de usuário – interação.
•  2. Nível de processamento – aplicação.
•  3. Nível de dados – gerência dos dados.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Camadas de aplicação
•  Interface:
•  Tela baseada em caracteres (terminal).
•  X-window
•  Processamento:
•  Busca web: palavra chave, ordenar resultados, fazer consultas aos
bancos de dados.
•  Análise de dados financeiros: estaosUca + IA.
•  Dados
•  Dados persistentes.
•  Geralmente no lado do servidor.
•  Manter consistência de dados (triggers).
•  Muito comum ser banco de dados relacional.
•  Fig 35.a
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas multidivididas
•  3 níveis lógicos: várias possibilidades para
distribuição Tsica de uma aplicação no modelo
cliente-servidor.
•  Mais simples:
•  2 Upos de máquinas: cliente com interface e servidor com
processamento e dados.
•  Cliente é “terminal burro”.
•  Arquitetura de 2 divisões (Tsicas)
•  Fig. 35.b
•  Outras possibilidades.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas multidivididas
•  Tendência a reUrar processamento e
armazenamento do cliente.
•  Mais problemáUcas para gerenciar/atualizar.
•  Mais soRware no cliente = mais propenso a erros.
•  Clientes gordos / clientes magros.
•  Clientes magros: não precisamos mais de sistemas
distribuídos?
•  SD muda para o lado do servidor.
•  Arquiteturas de 3 divisões (em termos Tsicos).
•  Servidor web repassa requisição para servidor da aplicação
(processamento), consulta BD.
•  Fig 36.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas descentralizadas
•  Arquiteturas mulUdivididas: conseqüência da divisão de
aplicação em interface/processamento/dados.
•  Em muitos ambientes, organização de aplicações cliente-
servidor é feita em arquiteturas mulUdivididas: distribuição
verUcal.
•  Componentes logicamente diferentes em máquinas diferentes.
•  Relação com fragmentação verUcal: tabelas de BD subdivididas
em colunas e distribuídas.
•  Divisão lógica e Tsica: cada máquina executa grupo específico de
funções
•  Distribuição horizontal
•  Servidor/cliente divididos em partes logicamente equivalentes.
•  Cada parte operando sobre seu próprio conjunto de dados.
•  Distribuição de carga.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas descentralizadas
•  Peer-to-peer (P2P): distribuição horizontal.
•  Não há servidor sempre ligado.
•  Sistemas finais comunicam-se diretamente.
•  Peers intermitentemente conectados e mudam de endereço.
•  Ex: distribuição de arquivos (bitTorrent), streaming (KanKan),
VoIP (Skype).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Cliente servidor versus P2P

•  Quanto tempo para distribuir arquivo de tamanho F para N
clientes: cliente-servidor versus P2P.
•  Fig. 37.
•  Cliente-servidor: envia sequencialmente N cópias.
•  Servidor:
•  tempo para enviar 1 cópia: F/us
•  tempo para enviar N cópias: NF/us
•  Cliente: cada cliente faz o download
•  dmin = taxa de download mínima entre os clientes. Aumenta linearmente
em N
•  Tempo de download do cliente mais lento: F/dmin

Tempo para distribuir F

para N clientes usando
cliente-servidor
Dc-s > max{NF/us,,F/dmin}
 Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Cliente servidor versus P2P

•  P2P:
•  Servidor: upload de pelo menos uma cópia – tempo F/us
•  Cliente: cada cliente faz o download de uma cópia
•  Tempo de download do cliente mais lento: F/dmin
•  Clientes: download agregado de NF bits
•  Taxa máxima de upload: us + Σui

Tempo para distribuir F

para N clientes usando DP2P > max{F/us,,F/dmin,,NF/(us + Σui)}
P2P

Aumentam linearmente em N
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Cliente servidor versus P2P

•  Upload cliente = u, F/u = 1 hora, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas descentralizadas
•  Peer-to-peer (P2P): distribuição horizontal.
•  Processos que consUtuem o sistema são todos iguais.
•  Funções necessárias são executadas por todos.
•  Interação simétrica: cliente e servidor ao mesmo tempo.
•  Como organizar os peers? Rede de sobreposição (overlay).
•  Nós são processos; enlaces são canais de comunicação lógicos.
•  Em geral, processo não pode se comunicar diretamente com
outro processo arbitrário: deve obedecer overlay.
•  Redes de sobreposição: estruturadas e não estruturadas.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Arquiteturas descentralizadas
•  Arquiteturas P2P estruturadas:
•  Rede de sobreposição é construída com a uUlização de um
procedimento determinísUco.
•  Mais uUlizado: tabela hash distribuída (distributed hash table –
DHT).
•  Ex.: Chord, CAN, Pastry, Tapestry
•  Arquiteturas P2P não estruturadas:
•  Algoritmos aleatorizados para construir a rede de sobreposição.
•  Idéia é que cada nó mantenha lista de vizinhos, mas que essa lista
seja construída de modo que envolva alguma aleatorização.
•  Localização de item pode depender de inundação da rede.