Aula 06

Prof.
Luiz Fernando Bittencourt IC - UNICAMP
MC714
Sistemas Distribuídos
2° semestre, 2018
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemas distribuídos pervasivos


Sistemas de saúde distribuídos
• Monitoramento de pessoas em um serviço de saúde

pervasivo.
• (a) concentrador local; ou
• (b) conexão sem fio contínua.

Sistemas de saúde distribuídos
• Questões a serem tratadas:

• Onde e como dados compartilhados devem ser
armazenados?
• Como prevenir perda de dados cruciais?
• Que infraestrutura é necessária para gerar e propagar
alertas?
• Como médicos podem fornecer feedback online?
• Como robustez extrema de sistema de monitoramento
pode ser alcançada?
• Quais as políticas de segurança e como políticas
podem ser impostas?

Redes de sensores
• Redes também usadas para processar

informações, não apenas transmiti-las.
• Comunicação sem fio e nós alimentados por bateria.
• Capacidade restrita de comunicação.
• Eficiência é importante.
• Relação com bancos de dados distribuídos
• “Qual tráfego sentido norte na rodovia X”.
• Resposta dada por colaboração entre vários sensores
ao longo da rodovia.

Redes de sensores
• Dois extremos:
• Fig 29: armazenamento e processamento somente no
servidor do operador da rede.
• Fig 30: armazenamento e processamento somente nos
sensores.
• Ambas tem problemas.
• 29: Enviar todos os dados medidos pode ser
desperdício de recursos.
• 30: Despreza capacidade de agregação, o que
retornaria menos dados ao operador.

Redes de sensores
• Necessário processamento de dados na rede

• Árvore com todos os nós, e agregação de
resultados propagados de volta à raiz.
• Questões:
• Como configurar uma árvore eficiente em redes
de sensores?
• Como agregação de resultados acontece? Pode ser
controlada?
• O que acontece se enlaces falham?

Redes de sensores
• TinyDB: interface de banco de dados em redes sensores

• Pode usar qualquer algoritmo de roteamento em árvore.
• Nós intermediários colhem e agregam resultados de seus
filhos.
• Problema: árvore de uma única raiz pode não ser tão

eficiente se consultas podem partir de qualquer ponto.
• Nós especiais que concentram resultados e consultas
relacionadas
Resumo
Resumo
• SDs: computadores autônomos que trabalham juntos
para dar a aparência de um único sistema.
• Facilita integração de diferentes aplicações que executam
em computadores diferentes.
• Ampliação fácil.
• Custo: software mais complexo, menos segurança,
menor desempenho
• Meta: ocultar parte da complexidade relacionada à
distribuição de processos.
• Premissas erradas dificultam desenvolvimento. Ex:
latência é baixa.
Resumo
• Tipos diferentes de SDs:
• Computação: derivado da computação
paralela.
• Informação: sistemas empresariais, bancos de
dados, intergração de aplicações.
• Pervasivos: ubiquidade do sistema,
administração distribuída.
Arquiteturas
Arquiteturas
• Componentes de sistema distribuído espalhados
por diversas máquinas.
• Controle demanda organização.
• Organização lógica do software e organização
física dos componentes.
Software
• Componentes de software constituem o sistema.
• Arquitetura de software
• 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
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
Estilos arquitetônicos
• Organização lógica do sistema em componentes
de software – arquitetura de software
• Estilo 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;
substituível.
• Conector: mecanismo que serve de mediador da
comunicação entre componentes.
• Facilidades para chamadas de procedimento (remotas),
passagem de mensagem, fluxo de dados.
• Várias configurações usando componentes e
conectores.
• Arquitetura em camadas.
• Arquiteturas baseadas em objetos.
• Arquiteturas centradas em dados.
• Arquiteturas baseadas em eventos.
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.
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.
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 compartilhados.
• Sistemas web possuem processos que se
comunicam por meio de serviços de dados web.
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.
Arquitetura baseada em eventos

• Pode ser combinada com arquiteturas centradas
em dados, resultando em espaços
compartilhados de dados.
• Processos desacoplados no tempo: não precisam ambos estarem
ativos para realizar comunicação.
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.
Arquiteturas de sistema
Arquitetura de sistema
• Onde são colocados os componentes de
software.
• Centralizada, descentralizada, híbrida.
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.
• Cliente-servidor pode ser implementado por
meio de um protocolo simples de comunicação
se rede é confiável.
• Empacota mensagem identificando serviço
desejado junto com dados necessários.
• Mensagem é enviada; servidor aguarda
requisição, processa e empacota resultados em
uma mensagem de resposta.
• 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 repetida sem danos: idempotente.
• Diversas maneiras de tratar falhas, dependendo do tipo de
mensagem perdida.
• Muitos sistemas utilizam 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.
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.
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: estatística + 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
Arquiteturas multidivididas
• 3 níveis lógicos: várias possibilidades para
distribuição física de uma aplicação no modelo
cliente-servidor.
• Mais simples:
• 2 tipos de máquinas: cliente com interface e servidor com
processamento e dados.
• Cliente é “terminal burro”.
• Arquitetura de 2 divisões (físicas)
• Fig. 35.b
• Outras possibilidades.
Arquiteturas multidivididas
• Tendência a retirar processamento e
armazenamento do cliente.
• Mais problemáticas para gerenciar/atualizar.
• Mais software 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 físicos).
• Servidor web repassa requisição para servidor da aplicação
(processamento), consulta BD.
• Fig 36.
Arquiteturas descentralizadas
• Arquiteturas multidivididas: 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 multidivididas: distribuição
vertical.
• Componentes logicamente diferentes em máquinas diferentes.
• Relação com fragmentação vertical: tabelas de BD subdivididas
em colunas e distribuídas.
• Divisão lógica e física: 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.
• 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).
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}

• 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 + Sui
Tempo para distribuir F

para N clientes usando
P2P
DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
Aumentam linearmente em N

• 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
• Peer-to-peer (P2P): distribuição horizontal.
• Processos que constituem 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.
• Arquiteturas P2P estruturadas:
• Rede de sobreposição é construída com a utilização de um
procedimento determinístico.
• Mais utilizado: 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.

Aula 06

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aula 06

Transféré par

Droits d'auteur :

Formats disponibles

Prof.

Luiz Fernando Bittencourt IC - UNICAMP

Sistemas distribuídos pervasivos

Sistemas distribuídos pervasivos

• Monitoramento de pessoas em um serviço de saúde

Sistemas distribuídos pervasivos

• Questões a serem tratadas:

Sistemas distribuídos pervasivos

• Redes também usadas para processar

Sistemas distribuídos pervasivos

Sistemas distribuídos pervasivos

• Necessário processamento de dados na rede

Sistemas distribuídos pervasivos

• TinyDB: interface de banco de dados em redes sensores

• Problema: árvore de uma única raiz pode não ser tão

• Arquiteturas centralizadas, arquiteturas

Software – sistemas autonômicos

Arquitetura baseada em objetos

Arquitetura centrada em dados

Arquitetura baseada em eventos

Arquitetura baseada em eventos

Cliente servidor versus P2P

Tempo para distribuir F

Cliente servidor versus P2P

Tempo para distribuir F

Cliente servidor versus P2P

Vous aimerez peut-être aussi