Seminário CI303Lucas Nascimento Ferreira

Data sharing service:

Propriedades•Persistência

• Independentemente da aplicação

• Permitir o reutilização dos dados

•Transparência• Manipular localização e transferencia de dados

• Garantir a disponibilidade e consistência dos dados

Data sharing service: Restrições•Volatilidade e Dinamismo

• Nós podem sair da rede, isso não pode desabilitar o serviço de gerenciamento de dados.

• Nós podem entrar na rede, o serviço deve colocar na conta os recursos que eles disponibilizam.

•Escalabilidade•Mutação de dados

• O serviço deve considerar protocolos de consistência adaptados para uma arquitetura dinâmica, heterogenea

• e de larga escala.

Motivação•A aplicação é diretamente envolvida com

o processo de transferência de dados.•Tornar o armazenamento e a localização

transparentes em relação a aplicação.•Permitir que aplicações concorrentes

escrevam numa estrutura global de armazenamento, garantindo consistência nos dados

Princípios de Implementação

•Sistemas DSM (Distributed Shared Memory)• Nós sob controle de uma unidade administradora única

• Recursos confiaveis

• Suporte para simulações numéricas complexas, onde os dados são acessados em paralelo pelos multiplos nós

• modelos de consistência e protocolos para gerenciamento transparenteeficiente de dados mutáveis,

• configurações estáticas de pequena escala

Princípios de Implementação

•Sistemas P2P:• Gerenciamento de dados imutáveis

• Configurações dinâmicas de larga escala

• Recursos geralmente localizados na Internet, sem confiabilidade nem controle

• Recursos heterogêneos em termos de processadores, SOs, e enlaces de rede.

• Suporte para armazenamento e compartilhamento de dados que não mudam.

Princípios de Implementação

•Escala do sistema é de centenas de nós, organizados em clusters.

•Em um nível global, os recursos são heterogeneos

•Podem ser considerados homogeneos dentro dos individuais clusters

•Nível de controle e confiabilidade são intermediários, pois os clusters podem pertencer a diferentes administradores

O Framework JXTA•Projeto originalmente iniciado pela Sun

Microsystems•Código aberto, independente de plataforma

e linguagem, protocolos baseados em XML•Provê um conjunto de blocos para

gerenciamento de sistemas P2P: descoberta de recursos, gerenciamento de grupos de peers,comunicação P2P, etc.

O Framework JXTA•Peer: Entidade básica, organizada em redes. São

identificados por IDs. Um ID é um endereço lógico independente da localização do peer na rede física.

•Grupos de Peers: Os peers podem ser membros de um ou mais grupos. Um grupo é composto de diversos peers que compartilham o mesmo interesse.

•Pipes: Comunicação entre peers ou grupos de peers dentro da rede virtual do JXTA é feita através de pipes. Pipes são canais lógicos inseguros

• e assíncronos. Dois tipos: ponto-a-ponto e de propagação.

O Framework JXTA•Advertisement: Formar de descrever e publicar algum serviço. Estruturados em arquivos XML os quais sao publicados através da rede

•Protocolos: 6 protocolos, dois são particularmente uteis para construir servicos P2P de alto nivel.

•Peer Discovery Protocol, utilizado para publicar e descobrir advertisements.

•Pipe Binding protocol, o qual estabelece dinamicamente links entre peers que estao comunicando em um dado pipe.

O JUXMEM•Arquitetura hierárquica•Gerenciamento Recursos de

memória•Gerenciamento de dados

compartilhados•Manipular provedores voláteis•Manipulando gerentes voláteis

Arquitetura Hierárquica•Rede de grupos de peers, em geral

correspondem a cluster no nível físico•Cada grupo consiste de um conjunto de

nós (provedores) os quais provêm memória para armazenamento de dados

• Em cada grupo, um nó é encarregado de gerenciar a memória disponível pelos provedores do grupo

•Um nó que apenas usa o serviço é chamado de cliente.

•Um único nó pode ser provedor, gerente e cliente.

Gerenciamento de Recursos de Memória

Gerenciamento de dados compartilhados

Manipular provedores

voláteis

Manipulando gerentes voláteis

ExperimentoHardware Utilizado•Pentium II 450Mhz•256 MB RAM•Conexão 100 MB/s FastEthernet

Experimento•Objetivo: Medir o overhead das

replicações para manter o grau de redundância (3) em um cluster.

•16 Providers, 1 Cluster Manager e 1 Client (1 máquina para cada)

•O Client executa 100 iterações em um loop com a instrução lock-put-unlock. Ao mesmo tempo a cada X segundos 1 provider é desativado.

Experimento

Experimento•Para X < 80s o overhead torna-se

significante, chegando a 65% para X = 30s.

•Em situações reais, a falha dos providers é muito menor do que no experimento (X >> 80), para essas situações o overhead é inferior a 5%.

Experimento

•A analise do experimento mostra que a plataforma JuxMem prove dinamicamente o nível de redundância especificado e mantem a disponibilidade dos arquivos com um overhead baixo.