Post on 04-Jul-2020
Prof. Luiz Fernando Bittencourt IC - UNICAMP
MC714Sistemas Distribuídos2° semestre, 2018
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Tiposdesistemasdistribuídos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
TiposdeSDs• Sistemas de computação distribuídos• Sistemas de informação distribuídos• Sistemas embutidos (embarcados)
distribuídos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
SistemasdeComputaçãoDistribuídos• Utilizado para tarefas de computação
(frequentemente de alto desempenho).• Computação em cluster• Computação em grade• Computação em nuvem
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cluster Computing• Tornaram-se populares pela razão preço/desempenho.• Estações mais potentes e mais baratas• Rede melhor
• Computação intensiva paralela.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cluster Computing
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cluster Computing• Ex.: Beowulf. Fig 22.• Mestre• Alocação de nós / fila / escalonamento• Interface para usuário• Executa middleware para execução de programas e gerência
do cluster.• Nós de computação: SO padrão pode ser suficiente.
• Bibliotecas de execução em sistemas paralelos: facilidades para comunicação por troca de mensagem.• Migração de processos: movimento transparente de
processos de um nó nativo para qualquer outro nó.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade• Cluster: homogêneo.• Grade: heterogênea, nenhuma premissa adotada em
relação a hardware, S.O., rede, domínio administrativo, política de segurança, etc.
• Recursos de diferentes organizações reunidos para permitir colaboração.• Organização virtual: pessoas em uma organização virtual
têm direitos sobre recursos dessa organização.• Servidores de computação (inclusive clusters),
armazenamento, instrumentos, bancos de dados, equipamentos, sensores, telescópios, etc.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade
http://wlcg.web.cern.ch/
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade
http://wlcg.web.cern.ch/
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade
http://wlcg.web.cern.ch/
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade• Software de grade: grande parte com finalidade de prover
acesso a recursos de diferentes domínios administrativos.
• Fig 23.
• Camada base: interfaces para recursos locais em site específico. Consultar estado de recursos e gerência de recursos locais.
• Camada de conectividade: protocolos de comunicação para suportar transações utilizando múltiplos recursos. Ex.: transferência de dados, autenticação, protocolos de segurança.
• Camada de recurso: gerência de um único recurso. Ex.: criar processo, ler dados. Responsável por controle de acesso –necessita autenticação.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade• Camada coletiva: manipular acesso a múltiplos recursos.
Serviços de descoberta de recursos, alocação / escalonamento de tarefas para múltiplos recursos, replicação de dados, etc.• Muitos serviços - pode consistir de muitos protocolos
independentes.
• Camada de aplicação: aplicações que usam o ambiente virtual dentro da grade.
• Coletiva + conectividade + recursos = middleware da grade.
• Noção de “site” é comum: tendência do SOA (acesso às camadas através de serviços web).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Computaçãoemgrade• Camadas Coletiva+conectividade+recurso formam o
cerne de um middleware de grade.• Dão acesso e gerenciam recursos dispersos por vários “sites”.
• Noção de “site” é comum: tendência do SOA (acesso às camadas através de serviços web).
• OGSA à Open Grid Services Architecture• Várias camadas e muitos componentes voltados a definir uma
grade aberta orientada a serviços
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cloud Computing• Introduz noção de “computação como serviço”.• Relação com utility grids.• Recursos virtualizados.
• Diferentes níveis de serviço. IaaS, PaaS, SaaS.• Pagamento pelo uso.
• Nuvem pública / privada / híbrida / comunitária.
• Evita alto investimento inicial.
• Fig. 24
• Visões: provedor e cliente.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdeinformaçãodistribuídos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
SistemasdeInformaçãodistribuídos• Organizações se defrontaram com uma profusão de
aplicações em rede.
• Interoperabilidade complicada.
• Algumas soluções de middleware existentes são resultado da integração de tais aplicações em um sistema empresarial
• Mais fácil que desenvolver todas novamente.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
SistemasdeInformaçãodistribuídos• Integração em vários níveis.• Aplicação (servidor + banco de dados) disponibilizada a
clientes remotos.• Cliente envia requisição, recebe resposta.• Integração em nível mais baixo: clientes poderiam empacotar
várias requisições para diferentes servidores em uma única requisição maior.• Envio para execução em forma de transação distribuída.• Idéia fundamental: ou todas ou nenhuma seria executada.
• Ex.: reserva passagem, hotel, aluguel de automóvel, restaurante (groupon), passagem de trem. • Com e sem sistema computacional
Prof. Luiz Fernando Bittencourt IC - UNICAMP
SistemasdeInformaçãodistribuídos• Aplicações tornaram-se gradualmente separadas em
componentes independentes• Componentes de banco de dados e de processamento
• Integração deveria ocorrer em nível mais alto• Comunicação também entre aplicações
• Indústria de integração de aplicações empresariais (EnterpriseApplication Integration – EAI).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transações• Aplicações de bancos de dados costumam ser
realizadas sob a forma de transações.• Programá-las requer primitivas especiais que devem ser
fornecidas pelo sistema distribuído ou pela linguagem em tempo de execução.• Lista de primitivas depende dos tipos de objetos que
estão sendo usados na transação.• Read e write são primitivas típicas.• Chamadas de procedimento remoto (RPC – remote
procedure calls) costumam ser encapsuladas em transações – RPC transacional.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transações• BEGIN_TRANSACTION: marca o início de uma transação.• END_TRANSACTION: finaliza transação e tenta commit.• ABORT_TRANSACTION: mata a transação e restaura
valores anteriores.• READ: lê dados de um arquivo, tabela, etc.• WRITE: escreve dados em um arquivo, tabela, etc.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transações• Propriedades (ACID):• Atomicidade: (para o mundo externo) transação
ocorre de forma indivisível.• Consistência: transação não viola invariantes do
sistema.• Isolamento: transações concorrentes não interferem
uma na outra.• Durabilidade: uma vez dado commit
(“comprometimento”), as mudanças são permanentes.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transaçõesaninhadas• Transações aninhadas.• Subtransações.
• 1 transação pode gerar subtransações paralelas e distribuídas, que podem gerar subtransações ...
• Fig. 25.
• Problema: • Transações em paralelo, uma se compromete, tornando
resultados visíveis à transação-pai.
• Transação-pai é abortada, restaurando o sistema ao estado anterior ao início da transação de nível mais alto.
• Resultados da subtransação comprometida devem ser anulados –“permanência” (durabilidade) se aplica somente às transações de nível mais alto.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transaçõesaninhadas• Profundidade arbitrária.• Considerável trabalho administrativo para conseguir que tudo
esteja correto.• Semântica é: • Transação ou subtransação inicia, recebe uma cópia privada de
todos os dados presentes no sistema inteiro, manipulando como desejar.
• Se abortar, seu universo privado some.• Se comprometer, seu universo privado substitui o do pai.• Dessa forma, se uma subtransação é comprometida e mais tarde
uma nova é iniciada, a segunda vê os resultados da primeira.• Se uma transação do nível mais alto abortar, todas as subjacentes
também têm de ser abortadas.• Fig 26
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transaçõesaninhadas• Importantes em sistemas distribuídos.• Modo natural de distribuir uma transação em
várias máquinas.• Divisão lógica do trabalho da transação original.• Ex: reserva de diversos trechos de vôo.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Transações• No início dos middlewares empresariais, componente
que manipulava transações formava o núcleo para integração de aplicações no nível do servidor ou do banco de dados.• Componente denominado monitor de processamento de
transações (monitor TP).• Permitir modelo de programação transacional para
aplicações.• Fig. 27.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Integraçãodeaplicaçõesempresariais• Aplicações passaram a se desvincular dos bancos de
dados sobre os quais eram construídas.• Necessidade de integrar aplicações
independentemente de seus bancos de dados.• Componentes de aplicação deveriam comunicar-se
diretamente uns com os outros.
• Integração de aplicações via middleware• Fig 28.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Integraçãodeaplicaçõesempresariais• Vários tipos de middleware de comunicação
• RPC – remote procedure call: componente de aplicação pode enviar efetivamente uma requisição a outro componente de aplicação executando uma chamada de procedimento local• Empacotamento da requisição como uma mensagem e envio.
• Orientação a objetos: invocação de método remoto (remote method invocation – RMI). Em essência o mesmo que RPC, mas funciona com objetos ao invés de aplicações.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Integraçãodeaplicaçõesempresariais• RPC e RMI: ambos precisam estar ligados (chamador e
chamado) e precisam saber como se referir um ao outro – esse acoplamento pode ser desvantagem.• Middleware orientado a mensagem (MOM)• Aplicações enviam mensagem a pontos lógicos de
contato.• Aplicações podem indicar interesse por um tipo
específico de mensagem que o middleware cuidará para que sejam entregues a essas aplicações.• Sistemas publicar/inscrever (publish/subscribe).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos• SDs até agora: estáveis / nós fixos e
conexões, até certo ponto, permanentes.• Alcançado através de diversas técnicas (p.ex. mascarar
falhas, esconder localização, etc)• Dispositivos móveis e embarcados: instabilidade é o
comportamento esperado.
• Sistemas distribuídos pervasivos (espalhado; difuso...)• Características: equipamentos pequenos, bateria,
mobilidade.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos• Inerentemente distribuído.• Configurados pelos proprietários.• Descobrir ambiente automaticamente é desejável.• Encaixar-se no ambiente onde está.
• Requisitos:• Aceitar/adotar mudanças de contexto.• Encorajar composição ad hoc.• Reconhecer compartilhamento como comportamento
padrão.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos• Adotar mudanças de contexto:• Dispositivo ciente de que seu ambiente pode mudar continuamente.• Ex.: descobrir que rede não está disponível porque usuário está se
movimentando. Conectar-se a outra rede ou tomar providências adequadas.
• Incentivar composição ad-hoc• Dispositivos utilizados de formas diferentes por usuários diferentes• Configuração, automática ou não, de aplicações tem que ser fácil
• Compartilhamento como padrão• Dispositivos se comunicam para trocar informações.• Meios para ler, armazenar, gerenciar e compartilhar informações.• Conectividade intermitente e dinamicidade de dispositivos
conectados: espaço de informações muda o tempo todo.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Sistemasdistribuídospervasivos• Mobilidade necessita de suporte a adaptação fácil e
dependente de aplicação a seu ambiente local.• Descobrir serviços eficientemente e agir de acordo.• Existe transparência de distribuição em sistemas
pervasivos?• Distribuição de dados e controle é inerente a tais
sistemas.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
SistemasdistribuídospervasivosSistemasdomésticos
• 1 ou mais computadores pessoais, televisão, backup, celulares, geladeira, câmeras de vigilância, relógios, iluminação...• Necessidade de autoconfiguração e autogerência• Não assumir que usuários finais são capazes ou têm
disposição para configurar e manter em funcionamento, além de corrigir falhas• Primeiro passo: universal plug and play
• Gerenciamento do espaço pessoal• O que compartilhar, com qual dispositivo, sob quais
circunstâncias, por quanto tempo, etc
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• Haverá uma máquina que gerencia sistema doméstico?• Outros dispositivos só fornecem interface.
• Sistemas de recomendação.• Dedução do que deve ser colocado no espaço pessoal
de alguém.• Metadados para sistemas de recomendação.
SistemasdistribuídospervasivosSistemasdomésticos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• Dispositivos de monitoramento de saúde• Contato automático com o médico• Evitar hospitalização• Vários sensores em uma rede de área
corporal (body-area network – BAN)• Preferencialmente sem fio
SistemasdistribuídospervasivosSistemasdesaúdedistribuídos
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.