aula06 - home | instituto de computaÇÃobit/mc714/aulas/aula06.pdf · 2018-08-30 · prof. luiz...
TRANSCRIPT
Prof. Luiz Fernando Bittencourt IC - UNICAMP
MC714Sistemas Distribuídos2° semestre, 2018
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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.
SistemasdistribuídospervasivosRedesdesensores
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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?
SistemasdistribuídospervasivosRedesdesensores
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• 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
SistemasdistribuídospervasivosRedesdesensores
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Resumo
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Estilosarquitetônicos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturasdesistema
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturadesistema• Onde são colocados os componentes de
software.• Centralizada, descentralizada, híbrida.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
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.