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.

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

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

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.