Seminário CI303
Lucas 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.
• Peer:
básica, organizada
em redes.
O Entidade
Framework
JXTA
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
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
• Rede de grupos
de peers, em geral
Hierárquica
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
Gerenciamento de
Recursos de Memória
Gerenciamento de dados
compartilhados
Manipular provedores
voláteis
Manipulando
gerentes voláteis
Experimento
Hardware 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.