Uma proposta arquitetural para serviços escaláveis de dados em nuvens Anderson Fonseca e Silva 1, Marco André Santos Machado 2, Paulo Fernando A. Soares 2, Francisco M. Soares-Neto 2, Vinicius Cardoso Garcia 2, Rodrigo Elia Assad 1 1 C.E.S.A.R. - Centro de Estudos e Sistemas Avançados do Recife 2 Centro de Informática - Universidade Federal de Pernambuco (UFPE) anderson.fonseka@gmail.com, {masm, pfas, fmssn, vcg, rea}@cin.ufpe.br Abstract. The increase of the peer-to-peer networks popularity is related to decentralized resources sharing, where peers could exchanging messages among theirs. Through the aggregation and replication techniques, this model offer more robustness and performance when compared to client-server model. In this context, where the peer-to-peer paradigm was selected to development the U-Store, a data cloud solution project, this article presents an architectural proposal towards to create distributed and scalable services, aiming to solve the known issues such as latency, performance, load balancing and so on. Resumo. O aumento da popularidade de redes peer-to-peer, está relacionado com o compartilhamento de recursos descentralizado, onde os pares podem trocar mensagens entre si. Através de técnicas de agregação e de replicação, este modelo oferece mais robustez e desempenho quando comparado ao modelo cliente-servidor. Neste contexto, onde o paradigma peer-to-peer (p2p) foi selecionado para o desenvolvimento do U-Store, uma solução de dados em nuvem, este artigo apresenta uma proposta de arquitetura para a criação de serviços distribuídos e escaláveis, com o objetivo de solucionar questões relativas à latência, desempenho, balanceamento de carga dentre outros. 1. Introdução Após os modelos clientes/servidores dominarem por anos a Internet, novos sistemas distribuídos utilizando-se de estruturas p2p ganharam popularidade rapidamente. Esses sistemas se apresentaram principalmente em duas categorias: file sharing [Iamnitchi et al. 2011] (ex. Napster [Poblocki 2001], Gnutella ou Morpheus) e instant messaging [Herbsleb et al. 2002] (ex. ICQ, AOL Instant Messenger ou Jabber). Alguns desses sistemas podem fornecer funcionalidades de outra categoria, como por exemplo: uma aplicação de file sharing pode fornecer um chat, ou uma aplicação de instant messaging pode permitir o compartilhamento de arquivos entre amigos, porém esses sistemas não oferecem um suporte genérico para aplicações distribuídas, se limitando às categorias mencionadas. Um sistema puramente p2p é um sistema distribuído sem qualquer controle centralizado [Schollmeier 2001]. Neste sistemas todos os nós são nomeados como servant (SERver+cliENT), este termo representa a capacidade dos nós agirem como clientes
e servidores ao mesmo tempo. Nos últimos anos, este antigo conceito novamente ganhou atenção dentro nas comunidades da Internet. As vantagens relativas à utilização de redes p2p comparadas com o modelo cliente/servidor tradicional estão na escalabilidade e tolerância a falhas [Das et al. 2009]. Dentro deste contexto, este trabalho apresenta uma proposta arquitetural para a criação e distribuição de serviços entre nós, objetivando a redução no consumo de recursos, aumento de disponibilidade e eliminando pontos centrais de controle e falha. No restante deste artigo as seções serão apresentadas da seguinte forma: Seção 2, Motivação e objetivos; Seção 3, JXTA; Seção 4, Trabalhos relacionados; Seção 5, Uma proposta arquitetural para serviços escaláveis de dados em nuvens; e por fim, na Seção 6, as Considerações finais. 2. Motivação e objetivos A motivação para a elaboração deste estudo surgiu dentro do projeto U-Store, que consiste em uma solução p2p para o storage de arquivos de forma distribuída. Nesta solução, os arquivos são separados em chunks (pedaços com tamanho pré-definido) e gravados em outros nós conectados na rede. Diante disto, devido a sua larga audiência ao comtemplar tanto clientes desktops, quanto clientes com acessos via browser em sua utilização, torna-se primordial a previsão de requisitos como: Utilização de recursos computacionais ociosos; Performance e redução no tempo de resposta; Alta disponibilidade dos serviços. Permitir que nós provenham serviços à rede de forma distribuída e configurável. Neste modelo, para o correto funcionamento da solução, foi desenvolvido um conjunto de serviços ao qual compõe a infra-estrutura base para a execução das funcionalidades de backup e restore de arquivos por parte do usuário, destacados na Tabela 1: Tabela 1. Serviços do projeto U-Store Serviços Descrição AuthenticationService Autenticação do usuário AvailabilityService Checagem de disponibilidade de espaço em disco dos nós conectados à rede ChunkService Registro de chunks no repositório ChunkAvailabilityService Disponibilidade dos chunks na rede ErrorService Controle de erros na rede ExitService Controle de saída dos nós na rede FileDirectory Serviço de sincronização de diretórios FileManagerService Serviço de gerenciamento de arquivos SearchService Serviço de verificação de melhores nós para a distribuição dos chunks MessageController Serviço de verificação e garantia de entrega de mensagens Neste contexto, a adoção de um nó como ponto central de acesso aos serviços descritos, considerando o alto grau de acessos, gerou uma sobrecarga, comprometendo a
disponibilidade no funcionamento da solução como um todo. Como solução, a realização dos serviços descritos passou a prever tanto o deployment de forma conjunta, quanto em nós distintos, da mesma forma em que tornou-se possível a adição de novos serviços à rede, permitindo sua descoberta e utilização por nós conectados de forma transparente. Esta abordagem permitiu a redução de sobrecarga no acesso aos serviços, através da eliminação de pontos únicos de acesso; o aumento de desempenho, através da descoberta dos serviços em nós vizinhos; e da alta disponibilidade, por meio do uso de técnicas para o balanceamento das requisições aos serviços. 3. JXTA JXTA [Wilson 2002] é uma especificação para a plataforma p2p desenvolvida pela Sun Microsystems sob a direção de Bill Joy e Mark Clary, propondo os seguintes objetivos: Nós devem estar habilitados a se descobrirem; Nós devem se auto-organizar em grupos; Nós devem publicar e descobrir recursos na rede; Nós devem se comunicar uns com os outros; Nós devem monitorar uns aos outros; Não deve requerer o uso de qualquer linguagem proprietária ou sistema operacional; Não deve obrigar o uso de qualquer transporte ou tecnologia de rede proprietária; Não deve obrigar o uso de qualquer autenticação, segurança ou modelo de encriptação proprietária; Uma das principais funcionalidades da plataforma é fornecer um padrão, permitindo que desenvolvedores comerciais e de código-aberto criem serviços interoperáveis e aplicações. O JXTA foi modelado utilizando um pequeno número de protocolos para o tratamento de serviços. Estes protocolos podem ser implementados utilizando qualquer linguagem, permitindo dispositivos heterogêneos se comunicarem um com o outro em uma rede p2p. Conforme [Brookshier et al. 2002], o JXTA possui seis protocolos, os quais são descritos na Tabela 2: Tabela 2. Protocolos JXTA Protocolos Descrição Peer Resolver Protocol (PRP) Envio e recebimento de consultas a outros nós. Peer Discovery Protocol (PDP) Publicação e descoberta de advertisement. Peer Information Protocol (PIP) Obter a informação de status do nó. Pipe Binding Protocol (PBP) Criação de canais de comunicação entre os nós. Peer Endpoint Protocol (PEP) Encontrar rotas entre dois nós. Rendezvous Protocol (RVP) Propagação de mensagens na rede. Este modelo de implementação na forma de um network overlay, age como uma hashtable virtual contendo os índices de todos os objetos publicados através do uso de advertisements. Deste modo, o JXTA implementa o uso de DHT abstraindo o desenvolvedor de preocupações relativas à performance na comunicação entre nós, permitindo um maior foco no negócio da solução.
Figura 1. Arquitetura do JXTA A Figura 1 apresenta uma visão da arquitetura JXTA dividida em três camadas: Application Layer (implementada sobre a camada de serviços, fornecendo os recursos para a construção de aplicativos como instant messaging), Services Layer (implementa serviços como: busca de recursos em nós, compartilhamento de documentos e autenticação) e Core Layer (inclui os seis principais protolos descritos anteriormente). A arquitetura JXTA segundo [Buford 2009], possui três tipos de nós categorizados da seguinte forma: Minimal-Edge Peers - Implementam somente as funcionalidades básicas do JXTA; Full-Edge Peers - Implementam as funcionalidades básicas e os serviços padrões oferecidos pelo JXTA; Super-Peers - Implementam e provisionam recursos para suportar a implantação e operação de uma rede JXTA. O JXTA foi utilizado na elaboração do projeto U-Store, devido a sua maturidade, modelo de distribuição open-source, documentação e fontes disponíveis. 4. Trabalhos relacionados Nesta seção são apresentados os trabalhos relacionados ao contexto de P2P data storage, considerando os seguintes critérios: Projeto arquitetural disponível; Abordagem focada em composição e distribuição de serviços; Criação de grupos ou papéis, subsidiando o estudo na divisão de responsabilidades entre nós. Desta forma, [Martalo et al. 2010] apresenta um modelo arquitetural baseado no Chord overlay scheme [Flocchini et al. 2004], classificando os nós em três diferentes grupos: Super Nodes, que cuidam do kernel da aplicação, fornecendo um mecanismo para o roteamento das mensagens e permitindo que os clientes encontrem os nós de Storage, sua execução deve prevêr alta disponiblidade (24x7), podendo ocorrer danos à rede em caso de mau funcionamento. Storage Nodes, que guardam os fragmentos publicados pelos Client Nodes e por fim, Client Nodes que funcionam como publicadores e consumidores de recursos através do sistema. O P2PCS (Peer-to-Peer Cloud System) [Babaoglu et al. 2012] apresenta uma proposta arquitetural e um protótipo, para disponibilizar uma infra-estrutura como serviço
através de uma Cloud. O modelo tem como base a utilização de algoritmos gossip-based [Fernandess et al. 2007], implementando uma coleção de processos executadas em hosts separados. Cada processo é composto por diversos módulos organizados em camadas. Como foco, este trabalho apresenta a manutenção da coesão entre nós não-confiáveis, e o particionamento de recursos em múltiplas subclouds que podem ser atribuídas individualmente à usuários da rede. A implementação do protótipo utiliza o JRMI [Waldo 1998] para o gerenciamento de comunicação remota, cobrindo serviços como gerenciamento de instâncias, monitoramento e agregação de serviços, e peer sampling service, que fornece a cada nó uma lista de outros nós, para a troca de mensagens. O FARSITE [Adya et al. 2002] assume uma escala de aproximadamente 100.000 máquinas, onde nenhuma das quais agem como servidores dedicados, porém são interconectadas não considerando uma topologia de redes em particular. Neste modelo, cada máquina pode executar três papéis: como clients, membros de um directory group, e como file host. Como client, são máquinas que interagem diretamente com o usuário, como um directory group, gerencia um conjunto de máquinas que coletivamente fornecem informações e metadados dos arquivos, guardando-as redundantemente em todas as máquinas pertencentes ao grupo, e por fim, como file hosts, para o recebimento das replicas de arquivos encriptadas. O PeerMart [Hausheer and Stiller 2005] implementa sua arquitetura tendo como base o Pastry [Rowstron and Druschel 2001], neste modelo os nós são definidos como: Consumer, Provider e Brokers, onde um nó pode assumir um ou mais papéis ao mesmo tempo. O destaque nesta arquitetura são os nós intermediários (Brokers), sendo responsáveis por se adequar às necessidades demandadas pelo nós Consumers e Providers de maneira eficiente, possuindo uma lista para cada serviço sob sua responsabilidade, e notificando os nós numericamente mais próximos, sobre a oferta de um novo serviço. 5. Uma proposta arquitetural para serviços escaláveis de dados em nuvens Nesta seção são apresentadas as definições relativas à análise, projeto, implementação e implantação de serviços, utilizando como infra-estrutura a plataforma JXTA. Na Figura 2 é apresentada a visão geral da arquitetura, onde os nós, classificados em: Client e Service contribuem para a execução das funcionalidades do projeto U-Store, ora fornecendo respostas, ora agindo como um nó requisitante. Também é identificada a conexão entre nós clientes que se utiliza do procotolo HTTP 1 para a troca de mensagens de forma direta, utilizada para a distribuição de chunks, como exemplo. O nó nomeado como Web Application Server, neste contexto, surge como uma alternativa para a exposição dos serviços definidos dentro da rede p2p, para um contexto cliente-servidor expostos via REST [Webber 2010], agindo como um fornecedor dos serviços internos da solução, para consumo por outros aplicativos. Neste modelo, é possível acrescentar nós de serviços à medida em que ocorrem a degradação no tempo de resposta, o aumento no grau de sobrecarga da rede, devido à um alto número de requisições e a queda de performance na execução das funcionalidades. 1 http://www.w3.org/protocols/
Figura 2. Visão geral da arquitetura Para a definição dos serviços, inicialmente foram considerados fatores importantes dentro do contexto de storage distribuido como: classificação dos nós, quanto ao seu papel no propósito do projeto; implantação dos serviços quanto à sua importância dentro da classificação dos nós; interface de construção dos serviços utilizando o JXTA como infra-estrutura; e por fim, exposição dos serviços para uma audiência web em formato de webservices. Para classificação dos nós, o projeto U-Store formalizou a seguinte classificação: Client: Fornece a GUI para a interação do usuário com as funcionalidades de backup e restore, contendo também serviços para a gravação e replicação de chunks, análise de disponibilidade dos nós, dentre outros. Proxy: Fornece a descoberta, disponibilização e roteamento dos serviços para os nós clientes. Server/Service: Fornece os serviços necessários para a operacionalização da solução no que se relaciona à autenticação, gerenciamento de arquivos, registro de informações de persistência relativos à gravação e restauração de chunks. A Figura 3 apresenta uma visão para a implantação dos serviços (descritos na Tabela 1), quanto à sua importância dentro da classificação dos nós, como se segue: Os nós clientes possuem como responsabilidade o fornecimento de informações relativos à sua condição dentro da rede, dentre estas: espaço em disco disponível para compartilhamento, tempo conectado à rede de forma periódica e a execução do serviço de gravação de chunks através do ChunkService. Os nós de serviços devem prover funcionalidades de gravação e recuperação de chunks (RestoreService e BackupService), gestão e autenticação de usuários (AuthenticationService) e gerenciamento de arquivos (FileManagerService).
Figura 3. Classificação dos nós e serviços relacionados Uma das preocupações principais dentro desta proposta, diz respeito à condição de criação e consumo dos serviços de forma transparente para o desenvolvedor, neste sentido, foi definido um conjunto de componentes que utilizando como base a plataforma JXTA, provê uma abstração para novas implementações. Neste modelo, foram definidos dois componentes: Service e ServiceConsumer. O primeiro, abstrai o modo como os serviços são registrados e publicados pela plataforma, e o último, é responsável por abstrair a descoberta dos serviços publicados, o envio de mensagens aos serviços encontrados e o controle no retorno das requisições solicitadas. Figura 4. Modelo para a criação e publicação de serviços Na Figura 4 os serviços FileManagerService, ChunkService, AuthenticationService herdam a classe Service, preocupando-se somente com as implementações de suas funcionalidades. Para o consumo destes serviços, o componente AuthenticationService- Consumer estende o componente ServiceConsumer.
5.1. Descoberta e enfileiramento dos serviços Os serviços utilizados pela plataforma são publicados e descobertos utilizando o Peer Discovery Protocol - PDP fornecido pelo JXTA. Porém, para a descoberta e entrega do serviço, além da implementação fornecida pela plataforma, foi desenvolvido um componente (ServiceWatcher), que encapsula o protocolo PDP, abstraindo do desenvolvedor o tratamento de erros de indisponiblidade, cache e resolução na troca de mensagens, caso haja o mesmo serviço publicado em vários nós de serviço. Devido a natureza assícrona do modelo p2p utilizando JXTA, e a grande quantidade de requisições para envio e recebimento de chunks pela solução, foram definidas filas de envio e recebimento de mensagens, onde toda a comunicação entre serviços na rede se utilizam dos componentes (MessageSendQueue e MessageReceiveQueue), reduzindo dessa forma a sobrecarga de requisições. A utilização de filas juntamente com o serviço de controle de mensagens (MessageController), garante a entrega e recebimento das mesmas, através do uso de tokens de identificação de cada mensagem enviada, podendo ocorrer o reenvio, caso o tempo de expiração de cada mensagem seja atingido. 5.2. Serviços P2P e webservices Para a exposição dos serviços, é utilizado o estilo arquitetural para sistemas de hipermídia distribuída conhecido como REST (REpresentational State Transfer). Neste contexto, a implementação JXTA se utiliza do servlet container Jetty 2 de forma embeddable utilizando o protocolo HTTP. Na implementação, para a exposição dos serviços como webservices é utilizado o Jersey [Hadley et al. 2010], desta forma, os serviços anteriormente consumidos somente entre os nós conectados, podem ser expostos de forma simples com a utilização de anotações fornecidas por esta implementação. Figura 5. Trecho de código do serviço REST para autenticação Na Figura 5, o serviço AuthenticationService (A) é exposto como um serviço REST através da classe AuthenticantionRestService de forma delegada. 2 http://jetty.codehaus.org/jetty/
5.3. Segurança A segurança no acesso aos serviços desenvolvidos, se utiliza da solução de grupos implementados pela própria plataforma JXTA, desta forma, é possivel a criação de grupos privados, gerenciados por meio do Membership Service Implementation, no qual pode ser utilizado como forma de autenticação tanto o PasswdMembershipService com autenticação de usuários e senhas, bem como, certificação digital (PKI) com o uso do PSEMembershipService [Wilson 2002]. 5.4. Validação Para validar a utilização da proposta foi utilizado o paradigma GQM (Goal /Question/Metric) proposto por [Basili et al. 1994], com o planejamento definido conforme a Tabela 3. Objeto de estudo Equipe de avaliação Características Tabela 3. Planejamento Proposta Arquitetural para a criação de serviços escaláveis de dados em nuvens Equipe do projeto U-Store composta por 2 Doutores, 1 Mestre, 8 Mestrandos Verificar a carga de requisições em serviços disponiveis em um único nó de serviço; Verificar o comportamento após a adição de outros nós de serviços na mesma rede; Utilizar como itens de verificação os consumos de memória e CPUs. Dentro das definições para a validação da arquitetura foi elaborado um cenário com as seguintes caracterísitcas: Dezoito nós clientes, 1 nó Super-Peer e 1 nó de serviços; Envio simultâneo de 10,5Gb de arquivos; Utilização da funcionalidade de backup; Submissão de carga de arquivos através da GUI; Rede Windows interna com 100Mbps. Nesta configuração foi definida a utilização da funcionalidade de backup, por envolver o consumo de serviços disponíveis em nós clientes e de nós de serviços simultâneamente. Para a medição dos resultados, foi o utilizada a ferramenta JConsole 3, monitorando os resultados somente para o nó de serviços. Na Figura 6, são exibidos os resultados obtidos considerando o cenário proposto, onde é possivel identificar o tempo total de testes em 1 hora e 20 minutos de duração, com envio de arquivos para a gravação de forma distribuída. Nos quadros, são apresentados em ordem de cima para baixo, os dados relativos ao Heap Memory Usage, a quantidade de Threads utilizadas, e por fim, o CPU Usage. 3 http://java.sun.com/developer/technicalarticles/j2se/jconsole.html
Figura 6. Resultados da validação arquitetural Nesta validação, após um intervalo de 35 minutos utilizando as configurações propostas no cenário inicial, foram acrescentados mais 2 nós de serviços à rede. Desta forma, é possível identificar que a partir das 23:25h, as informações relativas à utilização de Threads e o CPU Usage apresentaram alterações quanto à redução no consumo de recursos do nó de serviços, e que ocorre uma estabilização no Heap Memory Usage, devido à distribuição de requisições em outros nós de serviços. Na Tabela 4 são apresentadas as médias de tempo total (envio e recebimento) de cada mensagem, enviada aos principais serviços envolvidos na operação de Backup. Tabela 4. Roundtrip messages (em segundos) Serviços 1 Serviço (Nó) 3 Serviço (Nós) AuthenticationService 1,000 0,582 FileManagerService 1,000 0,130 BackupService 2,000 1,161 ChunkService 1,750 0,956
6. Considerações finais Este artigo apresentou uma proposta arquitetural dentro do contexto de storage em nuvens, utilizando a implementação JXTA como solução para a construção de redes peer-to-peer, bem como, a classificação definida para os nós dentro do projeto U-Store, sua organização e distribuição em serviços, de forma a reduzir a sobrecarga de requisições na solução. Ainda neste trabalho, foi apresentado um modelo para a implementação de interfaces para a construção de novos serviços utilizando JXTA, o uso de filas de mensagens para a melhoria na comunicação entre os nós, e um serviço de descoberta, cache e delegação de serviços aos nós clientes (ServiceWatcher). Apresentou a possiblidade de exposição de serviços como webservices, através do uso da implementação REST, se utilizando de um web conteiner provido pela plataforma JXTA. Desta forma, é possível implementar de forma configurável o deployment de serviços em nós de forma a se obter um maior ganho de qualidade, na construção de redes de dados em nuvens de forma escalável. Referências Adya, A., Bolosky, W. J., Castro, M., Cermak, G., Chaiken, R., Douceur, J. R., Howell, J., Lorch, J. R., Theimer, M., and Wattenhofer, R. (2002). Farsite: Federated, available, and reliable storage for an incompletely trusted environment. In OSDI. Babaoglu, O., Marzolla, M., and Tamburini, M. (2012). Design and implementation of a p2p cloud system. SAC 27th Symposium On Applied Computing, page 1. Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The goal question metric approach. Brookshier, D., Govoni, D., Krishnan, N., and Soto, J. C. (2002). JXTA: Java P2P Programming. Sams, Indianapolis, IN, USA. Buford, J. (2009). P2P networking and applications. Elsevier/Morgan Kaufmann, Amsterdam Boston. Das, S., Agrawal, D., and Abbadi, A. E. (2009). Elastras: An elastic transactional data store in the cloud. Fernandess, Y., Fernández, A., and Monod, M. (2007). A generic theoretical framework for modeling gossip-based algorithms. ACM SIGOPS Operating Systems Review, 41(5):19. Flocchini, P., Nayak, A., and Xie, M. (2004). Hybrid-chord: A peer-to-peer system based on chord. In Ghosh, R. K. and Mohanty, H., editors, ICDCIT, volume 3347 of Lecture Notes in Computer Science, pages 194 203. Springer. Hadley, M., Pericas-Geertsen, S., and Sandoz, P. (2010). Exploring hypermedia support in jersey. In Proceedings of the First International Workshop on RESTful Design, WS- REST 10, pages 10 14, New York, NY, USA. ACM. Hausheer, D. and Stiller, B. (2005). Peermart : The technology for a distributed auctionbased market for peer-to-peer services. Computer, 3(C):1583 1587.
Herbsleb, J. D., Atkins, D. L., Boyer, D. G., Handel, M., and Finholt, T. A. (2002). Introducing instant messaging and chat in the workplace. In CHI, pages 171 178. Iamnitchi, A., Ripeanu, M., Santos-Neto, E., and Foster, I. (2011). The small world of file sharing. IEEE Transactions on Parallel and Distributed Systems, 22(7):1120 1134. Martalo, M., Picone, M., Bussandri, R., and Amoretti, M. (2010). A practical network coding approach for peer-to-peer distributed storage. 2010 IEEE International Symposium on Network Coding NetCod, pages 1 6. Poblocki, K. (2001). The napster network community. First Monday, 6(11). Rowstron, A. and Druschel, P. (2001). Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In Middleware 2001, pages 329 350. Springer. Schollmeier, R. (2001). [16] a definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. In Proceedings of the First International Conference on Peer-to-Peer Computing, P2P 01, pages 101, Washington, DC, USA. IEEE Computer Society. Waldo, J. (1998). Remote procedure calls and java remote method invocation. IEEE Concurrency, 6(3):5 7. Webber, J. (2010). REST in practice. O Reilly, Farnham Sebastopol, CA. Wilson, B. (2002). JXTA. New Riders, Indianapolis, Ind.