aula06 - home | instituto de computaÇÃobit/mc714/aulas/aula06.pdf · 2018-08-30 · prof. luiz...

Prof. Luiz Fernando Bittencourt IC - UNICAMP

MC714Sistemas Distribuídos2° semestre, 2018


Sistemasdistribuídospervasivos


• Monitoramento de pessoas em um serviço de saúde pervasivo.• (a) concentrador local; ou• (b) conexão sem fio contínua.

SistemasdistribuídospervasivosSistemasdesaúdedistribuí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?

SistemasdistribuídospervasivosSistemasdesaúdedistribuídos


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

SistemasdistribuídospervasivosRedesdesensores


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



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



• 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– sistemasautonômicos• Também é possível conseguir adaptabilidade

fazendo o sistema monitorar seu próprio comportamento.

• Sistemas autonômicos

• Realimentação de informação


Estilosarquitetônicos


Estilosarquitetô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.


Estilosarquitetônicos• Várias configurações usando componentes e

conectores.• Arquitetura em camadas.• Arquiteturas baseadas em objetos.• Arquiteturas centradas em dados.• Arquiteturas baseadas em eventos.


Arquiteturaemcamadas• 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.


Arquiteturabaseadaemobjetos• 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.


Arquiteturacentradaemdados• 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.


Arquiteturabaseadaemeventos• 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.


Arquiteturabaseadaemeventos• 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.


Arquiteturasdesoftware• 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.


Arquiteturasdesistema


Arquiteturadesistema• Onde são colocados os componentes de

software.• Centralizada, descentralizada, híbrida.


Arquiteturacentralizada• 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.


Arquiteturacentralizada• 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.


Arquiteturacentralizada• 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.


Arquiteturacentralizada• 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.


Camadasdeaplicaçã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.


Camadasdeaplicaçã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


Arquiteturasmultidivididas• 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.


Arquiteturasmultidivididas• 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.


Arquiteturasdescentralizadas• 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.


Arquiteturasdescentralizadas• 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).


ClienteservidorversusP2P• 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.• 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}

Aumenta linearmenteem N


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

P2PDP2P > max{F/us,,F/dmin,,NF/(us + Sui)}

Aumentam linearmente em N


ClienteservidorversusP2P• Upload cliente = u, F/u = 1 hora, us = 10u, dmin ≥ us

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imum

Dis

tribu

tion

Tim

e P2PClient-Server


Arquiteturasdescentralizadas• 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.


Arquiteturasdescentralizadas• 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.

aula06 - home | instituto de computaÇÃobit/mc714/aulas/aula06.pdf · 2018-08-30 · prof. luiz...

Documents