Home | INSTITUTO DE COMPUTAÇÃO - aula08bit/mc714/aulas/aula05.pdfProf. Luiz Fernando Bittencourt IC -UNICAMP ClusterComputing •Ex.: Beowulf. Fig22. •Mestre •Alocação de nós

Prof. Luiz Fernando Bittencourt IC - UNICAMP

MC714Sistemas Distribuídos2° semestre, 2018


Tiposdesistemasdistribuídos


TiposdeSDs• Sistemas de computação distribuídos• Sistemas de informação distribuídos• Sistemas embutidos (embarcados)

distribuídos


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


Cluster Computing• Tornaram-se populares pela razão preço/desempenho.• Estações mais potentes e mais baratas• Rede melhor

• Computação intensiva paralela.


Cluster Computing


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


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.


Computaçãoemgrade

http://wlcg.web.cern.ch/


Computaçãoemgrade



Computaçãoemgrade



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.


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


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


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.


Sistemasdeinformaçãodistribuídos


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.


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


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


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.


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.


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.


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.


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


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.


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.


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.


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.


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


Sistemasdistribuídospervasivos


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.


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.


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.


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.


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


• 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


• 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


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



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

Documents

Home | INSTITUTO DE COMPUTAÇÃO - aula08bit/mc714/aulas/aula05.pdfProf. Luiz Fernando Bittencourt IC -UNICAMP ClusterComputing •Ex.: Beowulf. Fig22. •Mestre •Alocação de nós