Ps-Graduao em Cincia da Computao

Estudo da viabilidade de um servio de Cloud Storage, utilizando recursos ociosos, por uma Operadora de Telecomunicaes.

Por

Hilson Gomes Vilar de Andrade

Dissertao de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE, JANEIRO/2013

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

Hilson Gomes Vilar de Andrade

Estudo da viabilidade de um servio de Cloud Storage, utilizando recursos ociosos, por uma Operadora de Telecomunicaes.

ESTE TRABALHO FOI APRESENTADO PS-GRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.

ORIENTADOR: Prof. Dr. VINCIUS CARDOSO

GARCIA

RECIFE, JANEIRO/2013

A imaginao mais importante que o conhecimento. O conhecimento limitado. A imaginao envolve o mundo. Albert Einstein

Agradecimentos

Primeiramente, agradeo a Deus pelas bnos que vem derramando sobre minha vida, desde o meu nascimento. Nele, busquei nimo para perseverar na concluso desse projeto, superando minhas limitaes e fraquezas. Aos meus pais (Nenm e Dida) exemplos de vida e superao, que inteligentemente guiaram-me no caminho da tica e do trabalho, mostrando-me que no existe sucesso sem esforo. Exemplo esse que tambm guiou a minha irm Danielle, outro grande exemplo de vida para mim e que tanto me ajudou com suas oraes. minha grande companheira Anglica, por ser o meu recanto de paz e apoio incondicional, nos momentos difceis. Sem o seu apoio certamente eu teria desistido pelo caminho. Agradeo a minha filhinha Jlia, que em tantos sbados e domingos agarrou-se minha perna para no ser privada de minha presena, algo bastante comum nesses seus quatro anos de vida. Sei que no futuro ela entender e ficar orgulhosa dessa jornada. Ao meu orientador, Vincius Cardoso, exemplo de competncia e serenidade nos momentos mais complexos da pesquisa. Agradeo muito pelo voto de confiana e oportunidade que me foi dada. Aos meus fiis companheiros de turma: Andr, Wanderson e Anderson. O exemplo de superao e generosidade desses guerreiros foi o combustvel que me abasteceu nos momentos de desnimo, no decorrer dessa caminhada. Ao generoso time de desenvolvedores da Ikewai - especialmente ao Anderson Fonseca e Tiago Jamir, que tanto contriburam para a realizao dos experimentos utilizados nessa pesquisa. E por fim, agradeo aos meus colegas da Oi, em especial ao Marcos Alexandre, Gustavo Maciel e Roberto Zurlo, pelo apoio logstico e incentivo, algo imprescindvel para concluso desse sonho.

Resumo

Desde a privatizao do sistema Telebrs, em 1998, o mercado de telecomunicaes brasileiro vem sofrendo profundas transformaes. Dentre essas mudanas, as mais marcantes so a convergncia na oferta de servios e a acirrada concorrncia entre os principais players. Nesse cenrio, a oferta de servios como valor agregado fundamental para o crescimento e a sobrevivncia das empresas. Um bom exemplo a oferta do servio de armazenamento em nuvem, cujo mercado global j alcana a cifra de 40 bilhes de dlares. Essa dissertao estuda a oferta do servio de armazenamento em nuvem, por uma operadora de telecomunicaes, utilizando recursos computacionais ociosos, atravs da formao de um sistema de armazenamento peer-to-peer. Para tal, a execuo da pesquisa estudou trs fases necessrias para o lanamento comercial do servio: a arquitetura de controle, onde foi utilizado o Projeto USTO.RE como testbed; um prottipo para anlise do trfego nos links de interligao em funo da capacidade de armazenamento, e por fim a viabilidade econmica do servio, atravs de um estudo de caso baseado nas mtricas obtidas no prottipo. Como contribuio prtica, o estudo apresentou uma soluo escalvel e com baixo investimento, permitindo o lanamento de servio de armazenamento como valor agregado, por Operadoras de Telecomunicaes.

Palavras Chaves: Sistemas P2P, Cloud computing, Telecomunicaes, Armazenamento, Cloud Storage, Storage as a Service.

ABSTRACT

Since the event of privatization of the Telebrs system in 1998, the Brazilian telecommunications market is undergoing deep changes. Among these changes, the most striking one is the convergence of services and fierce competition among major players. In this scenario, the supply of services as added value is essential for the business. A good example of such services is cloud storage, whose global market has already reached the figure of 40 billion dollars. This Masters Thesis studies the offering of a cloud computing storage by a telecommunications operator, using idle computing resources through the formation of a peer-topeer storage system. This research studied three phases required for the commercial launch of the service: the control architecture, which used the Project USTO.RE as a testbed, a prototype for analysis of traffic in the interconnection links as a function of storage capacity and the economic viability of the service through a case study based on metrics obtained in the prototype. As a practical contribution, this study presented a low investment strategy, which allows the release of storage service as an added value for Telecommunications Operators.

Keywords: P2P Systems, Clould Computing, Telecommunications, Storage, Cloud Storage, Storage as a Service.

Sumrio

INTRODUO ..................................................................................................................... 11 1.1 1.2 1.2.1 1.2.2 1.3 Contextualizao ......................................................................................................... 11 Objetivos ..................................................................................................................... 13 Objetivos Gerais ...................................................................................................... 13 Objetivos Especficos .............................................................................................. 14 Organizao da Dissertao ........................................................................................ 14

SISTEMAS DE ARMAZENAMENTO DISTRIBUDO ..................................................... 16 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 Principais arquiteturas P2P ......................................................................................... 18 Arquiteturas puras ................................................................................................... 19 Arquiteturas hbridas ............................................................................................... 21 Plataforma JXTA......................................................................................................... 21 Arquitetura JXTA .................................................................................................... 22 Funcionamento de um sistema baseado em JXTA ................................................. 23 Principais frameworks Cloud Storage ......................................................................... 33 GFS .......................................................................................................................... 33 Campus Cloud ......................................................................................................... 35 Projeto USTO.RE .................................................................................................... 36 Sumrio do Captulo.................................................................................................... 37

ARQUITETURA USTO.RE ................................................................................................. 38 3.1 3.2 3.2.1 3.2.2 Descrio do sistema ................................................................................................... 39 Descrio dos Componentes e servios ...................................................................... 40 Super peers .............................................................................................................. 40 Servidores ................................................................................................................ 41

3.2.3 3.2.4 3.3 4

Proxies ..................................................................................................................... 43 Simple peers ............................................................................................................. 43 Sumrio do captulo .................................................................................................... 47

ANLISE DE TRFEGO DO PROTTIPO ...................................................................... 48 4.1 4.2 4.2.1 4.2.2 4.3 Definio dos objetivos e mtricas.............................................................................. 48 Resultados Obtidos...................................................................................................... 51 Cenrio I .................................................................................................................. 51 Cenrio II ................................................................................................................. 54 Sumrio do captulo .................................................................................................... 57

ESTUDO DE CASO ............................................................................................................. 59 5.1 5.2 5.3 5.4 5.5 5.6 Servio Cloud-Computing nas Operadoras de Telecomunicaes ............................. 59 Dimensionamento da Capacidade de armazenamento ............................................... 61 Arquitetura Final da Soluo....................................................................................... 64 Estudo da viabilidade econmica da Soluo ............................................................. 66 Modelo matemtico para avaliao de viabilidade da soluo ................................... 69 Sumrio do captulo .................................................................................................... 71

CONSIDERAES FINAIS ................................................................................................ 72 6.1 6.2 6.3 Trabalhos relacionados ................................................................................................ 73 Resumo das contribuies ........................................................................................... 73 Trabalhos futuros......................................................................................................... 73

REFERENCIAS .................................................................................................................... 75

Lista de figuras

Figura 1 Evoluo do mercado global de cloud computing ............................................................................... 16 Figura 2 Taxonomia de sistemas P2P .............................................................................................................. 18 Figura 3 Exemplo de requisio usando a tcnica flood ................................................................................... 19 Figura 4 Arquitetura JXTA em trs camadas .................................................................................................... 22 Figura 5 Pipes unicast e Pipes de propagao .................................................................................................. 29 Figura 6 Conexo Pipes .................................................................................................................................. 31 Figura 7 Arquitetura GFS ................................................................................................................................ 34 Figura 8 Arquitetura Campus Cloud ................................................................................................................ 36 Figura 9 Viso geral da arquitetura USTO.RE ................................................................................................... 39 Figura 10 a) Funcionamento de um peer ......................................................................................................... 46 Figura 10 b) Funcionamento de um peer Server proxy ..................................................................................... 46 Figura 11 Detalhamento da arquitetura do servio cloud-computing por uma Operadora ................................. 49 Figura 12 Estrutura hierrquica do modelo GQM da anlise do cenrio I .......................................................... 50 Figura 13 Estrutura hierrquica do modelo GQM da anlise do cenrio II ......................................................... 51 Figura 14 Trfego mdio de carga observado nos experimentos do cenrio I .................................................... 53 Figura 15 Topologia de simulao da arquitetura proposta .............................................................................. 55 Figura 16 a) Script de configurao do Switch0 ................................................................................................ 55 Figura 16 b) Script de configurao do Router0 ............................................................................................... 55 Figura 17 Roteamento centralizado entre as VLANs ........................................................................................ 56 Figura 18 Consolidao do mercado brasileiro de Telecomunicaes ............................................................... 59 Figura 19 Arquitetura do simulador usado como benchmark do tempo terico de transferncia ....................... 62 Figura 20 Flexibilidade do padro SDH-NG ...................................................................................................... 64 Figura 21 Funcionamento do protocolo GFP, definido pela norma ITU-T G.7041 ............................................... 65 Figura 22 Processo de concatenao, no SDH-NG ............................................................................................ 65 Figura 23 Padres que compem a soluo proposta ...................................................................................... 66

10

Lista de tabelas

Tabela 1 Conceito dos termos utilizados na arquitetura .................................................................................. 38 Tabela 2 Modelo GQM da Anlise do Cenrio I ............................................................................................... 49 Tabela 3 Modelo GQM da Anlise do Cenrio II .............................................................................................. 50 Tabela 4 Trfego mdio de carga, variando-se os parmetros de chunk e fila ................................................... 53 Tabela 5 Overhead total de controle, da soluo proposta .............................................................................. 56 Tabela 6 Produtos cloud-computing ofertados por Operadoras de Telecomunicaes ...................................... 60 Tabela 7 Setup do experimento usado como benchmark do tempo terico de transferncia ............................. 63 Tabela 8 Sumrio dos resultados do simulador usado como benchmark........................................................... 63 Tabela 9 Comparativo de preo entre os principais servios de armazenamento existentes .............................. 67 Tabela 10 Fluxo de caixa anual gerado pelo servio de armazenamento proposto ............................................ 67

11

1 INTRODUO

1.1 Contextualizao
Desde os tempos mais remotos que a preocupao em armazenar informaes acompanha os setores produtivos da humanidade. Seja com o advento do papiro, precursor do papel (2500 a.C.), passando pelos sistemas de armazenamento eletrnico, a partir da inveno do transistor na dcada de 1940, at os sistemas de armazenamento em nuvens atuais, essa necessidade crescente. Potencializado pelo desenvolvimento tecnolgico, que reduziu os custos dos sistemas informatizados, o volume de dados gerados pelas empresas alcanou patamares alm da capacidade de armazenamento disponvel. De acordo com o portal computerworld [1], j em 2007, o volume de dados gerados atingiu o valor 287 hexabytes1, enquanto a capacidade de armazenamento disponvel em discos rgidos, fitas, CDs, DVDs e memrias, totalizavam 264 hexabytes1. Diante dessa necessidade, a terceirizao do servio de armazenamento, em detrimento a expanso dos datacenters prprios, vem ganhando fora no mercado de tecnologia da informao, servio esse conhecido como armazenamento em nuvem (cloud storage), em virtude da sua natureza distribuda. Empresas como Dropobox, Rackspace, Amazon S3 e Google Drive so exemplos de provedores desse tipo de servio, cujo potencial inexplorado, sobretudo no mercado corporativo, ainda muito grande. De olho nesse novo mercado esto as operadoras de telecomunicaes, que j detm os servios de comunicao de voz e dados dessas empresas e passaram a ofertar servios de armazenamento em nuvem como valor agregado, tais como Oi Smart Cloud, TIM Cloud e Vivo Cloud Plus. Entretanto, as mesmas o fizeram a partir da implantao de novos datacenters ou com a expanso dos existentes, o que demanda elevados investimentos em infra-estrutura e aquisio de hardware, diminuindo assim a rentabilidade do servio. Uma alternativa para aumentar essa rentabilidade, considerando a topologia de rede dessas empresas, seria atravs da

hexabytes = 1018 bytes

12

utilizao dos recursos de armazenamento ociosos e no dedicados, somando-se a capacidade dos datacenters existentes, conforme proposto por Andrzejak, Kondo e Anderson [2]. A existncia de recursos de armazenamento ociosos, nas redes locais das grandes operadoras de telecomunicaes, fica evidente quando se analisa o espao em disco nos desktops utilizados como posies de atendimento, nos grandes callcenters operados por essas empresas. Devido padronizao das configuraes de hardware praticada pelo mercado, esses desktops so adquiridos com uma capacidade de armazenamento superior a demandada pelos sistemas CRM (Costumer Relationship Management) instalada nas mesmas, dando margem a uma freqente subutilizao. Para viabilizar tecnicamente essa alternativa, diversos trabalhos acadmicos descrevem a utilizao do paradigma P2P (peer-to-peer) para criao de federao de dados e composio de uma nuvem de armazenamento, dando origem a sistemas denominados P2PSS (Peer-to-peer storage system). Nessa arquitetura, cada peer recebe um conjunto de arquivos, que criptografado e replicado no espao livre de outros peers da rede. Um dos principais desafios dos sistemas de armazenamento P2P consiste em construir um sistema eficiente e confivel, a partir de um conjunto de componentes no-confiveis e sujeitos a instabilidades diversas [3]. Por esse motivo, boa parte das pesquisas recentes que abordam a temtica de armazenamento em nuvem utilizando sistemas distribudos, trata dos aspectos de disponibilidade e desempenho. Com isso, questes referentes a essas aspectos foram aprimoradas, permitindo o avano de tais sistemas a ponto de coloc-los como uma alternativa concreta s plataformas de armazenamento tradicionais. Dessa forma, a proposta de um modelo de avaliao de viabilidade de um sistema cloud storage, baseado em medies de trfego obtidas em um prottipo e considerando variveis econmico-financeiras, alm de inovadora, contribui para subsidiar a adoo de tal soluo por parte da cadeia decisria das empresas. Tanto nas operadoras de telecomunicaes, usadas como referncia no estudo de caso proposto, quanto em outras empresas que estejam interessadas em oferecer o servio de armazenamento em nuvem, a partir dos recursos ociosos nas suas redes locais, gerando valor para o segmento econmico onde esto inseridas.

13

1.2 Objetivos

O objeto de estudo desse trabalho consiste em elaborar uma metodologia capaz de avaliar a viabilidade econmico-financeira de um servio de armazenamento em nuvem, que opte pelo uso de recursos ociosos e no-dedicados ao armazenamento, no contexto da arquitetura de rede local de uma operadora de telecomunicaes. Para tal, ser investigado o estado da arte dos frameworks de armazenamento em nuvem baseado em P2P, desenvolvido um prottipo e analisado suas mtricas atravs de medies de trfego reais. Por fim, ser descrita uma metodologia de avaliao econmico-financeira da soluo, seguida de um estudo de caso prtico, baseado na expanso da arquitetura adotada no prottipo, validando a adoo do modelo proposto.

1.2.1 Objetivos Gerais

O presente trabalho de pesquisa tem como objetivos gerais: Propor uma arquitetura de cloud storage que utilize recursos computacionais ociosos e suporte o lanamento de servios de valor agregado; Analisar a viabilidade econmico-financeira desse sistema, incluindo o levantamento do investimento inicial e a taxa de retorno em funo da capacidade de armazenamento ofertada; Estudar quais os melhores padres para essa arquitetura, incluindo as camadas de controle lgico e fsico; Validar a soluo proposta, atravs de um estudo de caso baseado no mercado brasileiro de telecomunicaes.

14

1.2.2 Objetivos Especficos

Os objetivos especficos do projeto de pesquisa aqui proposto so: Construir um prottipo da arquitetura proposta, no qual podero ser realizados experimentos onde sero obtidas as mtricas necessrias para avaliao da viabilidade do servio cloud storage; Definir os objetivos e mtricas que iro orientar a interpretao dos resultados obtidos nos experimentos realizados no prottipo; Propor um modelo de avaliao de viabilidade que considere variveis econmicas e a capacidade de armazenamento do servio cloud storage, utilizando a arquitetura apresentada; Relacionar os valores obtidos aos aspectos da utilizao comercial do servio, por parte de uma operadora de telecomunicaes, atravs de um estudo de caso.

1.3 Organizao da Dissertao

O texto desta dissertao est dividido em seis captulos, incluindo esta introduo, os demais abordam o seguinte contedo:

O captulo 2: Define o estado da arte das arquiteturas cloud storage que utilizam recursos computacionais ociosos e descreve os principais frameworks para implementao dessa arquitetura, incluindo suas terminologias, arquiteturas, mecanismos de funcionamento e fatores limitantes;

O captulo 3: Apresenta o Projeto USTO.RE, usado como testbed no desenvolvimento da pesquisa, estudando suas caractersticas intrnsecas, mecanismos de controle e principais mtricas para a avaliao da viabilidade do servio de armazenamento em nuvem;

15

O captulo 4: Apresenta um prottipo de simulao, descrevendo os parmetros simulados e anlise dos resultados obtidos, de modo a permitir o dimensionamento da capacidade de armazenamento sob condies reais de operao, garantindo a melhor experincia do ponto de vista do usurio e da rede;

O captulo 5: proposto um modelo de avaliao de viabilidade da explorao do servio, considerando aspectos econmicos e tcnicos. Em seguida, visando validao do modelo, apresentado um estudo de caso onde o servio cloud storage, utilizando recursos computacionais ociosos, ofertado como um servio de valor agregado no mercado brasileiro de telecomunicaes, de modo a comprovar a viabilidade econmicofinanceira da soluo. Por fim, apresentado um modelo matemtico que relaciona as caractersticas de trfego e do retorno econmico-financeiro da soluo.

O captulo 6: Mostra as concluses sobre esta pesquisa, principais contribuies, trabalhos relacionados, trabalhos futuros e direcionamentos a cerca da pesquisa.

16

2 SISTEMAS DE ARMAZENAMENTO DISTRIBUDO

Nicholas Carr, em seu livro The big switch: rewiring the world, from Edison to Google [4], mostra de forma clara e objetiva o quo subutilizado encontram-se os recursos computacionais nas grandes corporaes, colocando em cheque a racionalidade das elevadas quantias investidas nos ltimos anos para aquisio e manuteno de infra-estrutura prpria para o processamento e armazenamento de dados. Ele sugere ser inevitvel que tais servios sejam oferecidos como servio pblico, tal como a eletricidade, o gs ou a telefonia. Essa reflexo sintetiza o atual crescimento do mercado de computao em nuvem como servio pblico, constituindo-se na plataforma bsica para a oferta de servios de processamento e armazenamento. De acordo com Dignan [9], o mercado global de computao em nuvem crescer dos atuais 40,7 bilhes de dlares para 241 bilhes em 2020, com destaque para oferta da modalidade BPaaS (Businees-Process-as-a-Service), que inclui o gerenciamento dos principais servios de TIC (SaaS Software-as-a-Service; PaaS Platform-as-a-Service e IaaS Infraestructure-as-aService), conforme abaixo:

Figura 1: Evoluo do mercado global de cloud-computing (Autor: Dignan [9])

17

O primeiro grande projeto de computao em nuvem como servio pblico se deu com o lanamento das plataformas EC2 (Elastic Computer Cloud) e S3 (Simple Storage Service), pela Amazon [5][6]. Em essncia, essas plataformas baseiam-se na alocao de recursos computacionais distribudos, virtualmente alocados para um determinado usurio a partir de suas necessidades de processamento ou de armazenamento, de modo transparente e sem restries. Para tal, imensos datacenters funcionam com uma usina de armazenamento e processamento dos dados, oferecendo toda a capacidade demandada pelos clientes. Nesse novo modelo de negcio, as empresas trocam o CAPEX (Capital Expenditure) necessrio para aquisio de hardware e o OPEX (Operational Expenditure) necessrio para a manuteno e atualizao tecnolgica, por um custo varivel em funo da demanda necessria. Tal modelo s tornou-se possvel graas ao avano nas tecnologias de acesso banda larga, que elevaram as taxas de transmisso necessrias para o bom funcionamento da arquitetura descentralizada e em nuvem. Outra possibilidade para oferecer infra-estrutura computacional como servio (IaaS), tal como o servio de armazenamento, alvo principal dessa pesquisa, atravs do estabelecimento de grids computacionais, utilizando recursos distribudos e no-dedicados. Inicialmente motivada escassez de recursos computacionais para a anlise de grande volume de dados decorrentes de pesquisas cientficas [7], esses data grids tambm podem ser utilizados para o desenvolvimento de uma plataforma para a oferta de servio de armazenamento distribudo. Nesse contexto, o modelo P2P (Peer-to-peer) aparece como candidato natural para essa implementao, dada a sua natureza descentralizada, escalvel e auto-organizvel, sobretudo para sistemas que se proponham a utilizar recursos ociosos e que j se encontram em produo, alvo principal dessa dissertao. Dessa forma, visando garantir o embasamento terico necessrio, os tpicos seguintes apresentam uma breve reviso das principais arquiteturas P2P, a plataforma JXTA utilizada para prover a comunicao entre os peers - e alguns frameworks que se baseiam nesse paradigma para construo de um data grid de armazenamento, tambm chamado de federao de dados, de modo a suportar o servio cloud storage proposto nessa pesquisa.

18

2.1 Principais arquiteturas P2P

Os grandes responsveis pelo impulso e popularizao dos sistemas distribudos P2P, foram o Napster, Gnutella e o KaZaA. Alm de protagonizar inmeras questes judiciais quanto a direitos autorais e pirataria, foi atravs destas ferramentas que se evidenciou o potencial da tecnologia no que diz respeito a compartilhamento de recursos sem desprender maiores investimentos em hardware. Desde a poca dos precursores a tecnologia sofreu diversas mudanas. Conforme se pode observar a Figura 2 a seguir a caracterizao de sistemas P2P seguindo a rvore de classificao dos sistemas computacionais.

Figura 2: Taxonomia de sistemas P2P (Autor: M. P. Duarte.[26])

A ilustrao mostra que os sistemas tendem a sofrer um processo de descentralizao contnuo, onde o primeiro grande avano se deu com o modelo cliente-servidor. Este consiste em uma mquina central no qual disponibiliza algum servio que consumido por mquinas com um hardware com bem menos recursos. A segunda forma de descentralizao mostra o surgimento das aplicaes P2P, onde podem ser desenvolvidas sobre sua forma completamente descentralizada (ex: Gnutella), denominada de pura, ou um modelo hbrido (ex: KaZaA), onde se

19

desenvolvem estruturas de controle centralizadas e a utilizao de recursos descentralizados. uras Cada um dos modelos de descentralizao possui suas vantagens e desvantagens conforme se pode acompanhar na sesso seguinte.

2.1.1 Arquiteturas p puras

De acordo com Schollmeier e Rudiger [8], as redes denominadas puras possuem como principal s caracterstica a no existncia de nenhum tipo de controle central. Todo o funcionamento se d com uso de um algoritmo descentralizado onde possvel localizar peers e/ou servios. Esta localizao feita fazendo uso da tcnica de enchente (flooding onde a mensagem d flooding), enviada a todos os computadores diretamente ligados ao emissor e cada mquina que recebe a omputadores mensagem faz o mesmo. Para evitar que a rede entre em colapso (loop), um tempo de vida . (loop atribudo a mensagem para que caso esta no chegue a seu destino seja descartada Os pontos descartada. negativos aqui so: lgumas Algumas mquinas podem no receber a mensagem, negando assim um servio que estaria disponvel em tese; H um grande volume de mensagens enviadas at que a mesma encontre a at mquina de destino. Para melhor ilustrar o funcionamento, possvel visualizar na Figura 3 o algoritmo de busca em execuo. possvel perceber que algumas mquinas no repassam a mensagem recebida devido a limitaes no tempo de vida e nmero de repasse. d

Figura 3: Exemplo de requisio usando a tcnica de flood (Autor: M. P. Duarte.[26]) Duarte.

20

A tcnica mais utilizada na implementao de arquiteturas puras o qual gerou um avano significativo na rea o Distributed Hash Tables (DHT) [9]. Como exemplo de utilizao dessa tcnica temos as aplicaes pStore [10], Pastiche [11], Oceanstore [12], PeerStore [13] e BitTorrent [14]. As DHTs pertencem classe de sistemas distribudos descentralizados e oferecem recursos de localizao similar as hash tables (chave, valor). Um par de chaves e valor armazenado na DHT e qualquer participante da rede pode acessar o valor desejado apenas informando a chave associada. As primeiras quatro especificaes de DHTs - Pastry [15], Chord [16], CAN [17] e Tapestry [18], surgiram quase simultaneamente no ano 2001, depois disso, sua utilizao se popularizou em aplicaes destinadas ao compartilhamento de arquivos na internet. As DHTs possuem como principais caractersticas: Descentralizao: os prprios ns criam e mantm o sistema, sem a necessidade de um servidor; Escalabilidade: o sistema suporta a participao de um crescente nmero de ns simultaneamente; Tolerncia a erros: o sistema deve ser confivel, mesmo com ns entrando e saindo continuamente da rede. Para alcanar os objetivos supracitados, as redes DHTs utilizam a tcnica de que um n na rede deve estar em contato direto com apenas uma frao de todos os ns participantes. Isso reduz o custo de manuteno quando um n entra ou sai do sistema. Para armazenar um arquivo numa DHT, primeiro se calcula uma chave e em seguida esse arquivo enviado para a rede at ser encontrado o conjunto de ns responsveis por seu armazenado. Para recuper-lo, uma mensagem enviada informando a chave do arquivo desejado, essa mensagem encaminhada at um n que possua o contedo desejado e ento o mesmo enviado como resposta. As caractersticas citadas sugerem que essa arquitetura seja bastante atraente para aplicaes de compartilhamento na internet, dada a no necessidade de um controle centralizado. Porm, para aplicaes que exijam um elevado nvel de servio, como a oferta de servio de armazenamento em nuvem, opta-se pelo uso de arquiteturas hbridas, que combinem escalabilidade e confiabilidade.

21

2.1.2 Arquiteturas hbridas

Em alguns sistemas P2P necessria a identificao dos peers conectados na rede. Para tal, sistemas como o OurBackup[10], que fazem uso de redes sociais para backup, utilizam em sua arquitetura um servidor responsvel pela autenticao dos usurios, manuteno da rede e dos metadados onde as cpias esto armazenadas. Pode-se ressaltar que a utilizao de servidores no obrigatria para a localizao dos peers e dos metadados, podendo essa ser feita utilizando as DHT mencionadas anteriormente. Nesses sistemas, o papel do servidor est em oferecer uma interface aos peers da rede com diversas operaes tais como: autenticao do usurio; manipulao dos dados armazenados por outros peers, adicionar, remover, excluir, atualizar; manipulao dos usurios cadastrados no sistema; localizao dos peers e relacionamento entre eles; dentre outras tarefas que venham a atender os requisitos do sistema. Em todos os casos geralmente verificado se o cliente possui permisso para executar tais operaes. Essa centralizao de informaes pode trazer prejuzos de escalonamento no sentido de que sempre vai existir uma exigncia maior do servidor medida que se aumenta o nmero de requisies, usurios, metadados ou quaisquer outras informaes delegadas ao servio. Porm, sistemas como o eDonkey [19] se mostraram bastante eficientes quanto ao gerenciamento centralizado de informaes dessa natureza. Se necessrio esse escalonamento tambm pode ser resolvido com a utilizao de clusters ou grids no lado do servidor, fazendo-se mais importante a disponibilizao da interface de comunicao com a mquina cliente.

2.2 Plataforma JXTA

Descrita a arquitetura na qual os peers podero estar dispostos para criao da federao de dados, que ser utilizada como nuvem de armazenamento na soluo proposta, a prxima etapa descrever o padro com o qual os mesmos se comunicaro para estabelecer esse agrupamento. Para tal, a tecnologia JXTA [20] fornece um conjunto comum de protocolos abertos, que do suporte s implementaes necessrias para o desenvolvimento de aplicaes P2P.

22

Os protocolos JXTA padronizam a maneira como os peers realizam algumas atividades, tais como localizao, agrupamento, publicao e descoberta de recursos na rede, comunicao e monitoramento de recursos. Tais protocolos permitem o desenvolvimento de servios interoperveis em aplicaes P2P. Como os mesmos so independentes tanto da linguagem de programao quanto dos protocolos de transporte, dispositivos heterogneos com software ou sistemas operacionais completamente diferentes podem interoperar entre si sem quaisquer consequncias. Usando a tecnologia JXTA, possvel abstrair muitas funcionalidades necessrias para a criao de aplicativos P2P.

2.2.1 Arquitetura JXTA

A arquitetura do JXTA dividida em trs camadas conforme ilustrado na Figura 4 abaixo [21].

Figura 4. Arquitetura JXTA em trs camadas (Fonte: Sun Microsystems)

a) Core: A principal camada da arquitetura JXTA, o core rene os recursos essenciais do JXTA, que so encapsulados em um conjunto que inclui: blocos de construo, mecanismos de chaves para aplicaes P2P, servios de descoberta, servios de comunicao e transporte; servio de firewall e NAT (Network Address Translation) transversal; servio para criao de peer; servio para criao de Grupos de peers e primitivas de segurana [21][22].

23

b) Servios: Nesta camada, os servios JXTA incluem servios de rede que no so absolutamente necessrios para uma rede P2P operar, porm so indispensveis para a construo de um sistema de armazenamento em nuvem sob esse paradigma. Como exemplo, temos os servios de rede que incluem as pesquisas indexadas, sistemas de diretrios e armazenamentos, compartilhamento de arquivos, sistemas de arquivos distribudos, agregao de recursos, traduo de protocolos, autenticao e servios de criptografias como PKI (Public Key Infrastructure) [21][22].

c) Aplicaes: A camada de aplicaes apresenta implementao de aplicaes que usam JXTA integrado, tais como mensagens instantneas P2P, compartilhamento de recursos e documentos, gerenciamento de contedo, e-mail P2P, sistemas de leiles distribudos, entre outros.

2.2.2 Funcionamento de um sistema baseado em JXTA

Conforme ser detalhado no Captulo 3, o prottipo do sistema de armazenamento em nuvem utilizado para validao dessa pesquisa baseado na arquitetura JXTA. Para uma melhor compreenso dos componentes e servios do mesmo, ser detalhado o funcionamento de algumas entidades e servios que compem um sistema baseado na plataforma JXTA, tais como o Peer, Grupo de peers, Servios de Rede, Servios do Grupo de Peer, Mensagens, Pipes e Anncios. i. Peer No contexto de aplicaes desenvolvidas sob a plataforma JXTA, o peer qualquer entidade que faa parte da rede e que implemente um ou mais dos protocolos da arquitetura JXTA [21]. O peer pode estar presente em sensores, telefones e PDAs, PCs ou servidores e supercomputadores. Para o funcionamento da rede, cada peer opera de forma assncrona e independente de todos os outros peers e identificado por um peer ID [22]. Durante o processo de inicializao, o peer publica um ou mais endereos de rede para uso dos protocolos JXTA e cada endereo publicado anunciado como um endpoint do peer, que identifica o endereo de rede. Os endpoints so usados para estabelecer conexo ponto-a-ponto de forma direta entre dois peers.

24

Os peers so normalmente configurados para descobrir outros peers na rede de forma espontnea, para estabelecer relacionamentos conhecidos como Grupo de peers, que podem ser de natureza transitria ou persistente. Em JXTA, os peers podem ser caracterizados em trs tipos: Minimal-Edge Peer: implementam apenas os servios essenciais necessrios do JXTA; Full-Edge Peer: possuem todas as caractersticas do ncleo e padres de servio do JXTA; Super-peer: suportam recursos de apoio implantao e operao de uma rede JXTA. As trs principais funes do super-peer so: - Relay usado para armazenar e encaminhar mensagens entre peers que no tm conexo direta; - Rendezvous mantm ndices globais de anncios, auxiliando novos peers a ingressar em um grupo de peers e possibilitando a criao do servio de proxy para a execuo das pesquisas de anncio dos recursos. Tambm utilizado para as transmisses de mensagens; - Proxy usado pelos peers para obter acesso a todas as funcionalidades da rede JXTA. O ponto de busca traduz e resume as solicitaes, responde a consultas e fornece suporte para os pequenos peers terem acesso s funcionalidades.

Estas categorias descrevem as configuraes de peers mais comuns, dependendo da capacidade da aplicao e dos peers, podendo ser feita uma implementao de peers com mltiplas funcionalidades.

ii.

Grupo de peers Um grupo de peer na plataforma JXTA uma coleo de peers que geralmente

disponibiliza um conjunto comum de servios ou interesses. Os peers se auto-organizam em grupos, cada grupo identificado por um ID do grupo e os peers presentes nestes grupos tambm recebem o ID do grupo. O grupo estabelece a sua prpria poltica de associao, inclusive a poltica pode ser aberta (qualquer pessoa pode participar) ou ainda rigorosamente seguro e protegido (o que exige credenciais para a adeso) [21]. A especificao dos protocolos JXTA descreve como os peers podem publicar, descobrir, juntar e monitorar grupos de peers, estes protocolos no ditam quando e nem como grupos de

25

peers so criados. Convencionalmente, um grupo de peers formado simplesmente juntando peers que geralmente so organizados pelo tipo de servio que oferecem. Alm do objetivo de formar uma nuvem de armazenamento, conforme objeto de estudo desse trabalho, h vrias outras motivaes para a criao de grupos de peers, tais como: Criao de ambiente seguro - pode ser criado domnio de controle local, no qual poltica de segurana especfica pode ser executada. A poltica de segurana pode ser uma simples autenticao ou atravs de um algoritmo de criptografia de chave pblica. As fronteiras dos grupos de pares permitem que os peers vizinhos possam acessar e publicar contedos protegidos. Os grupos de peers formam regies lgicas cujos limites restringem o acesso aos recursos apenas entre peers do grupo; Criao de escopo de ambiente - podem ser criados grupos que permitam o estabelecimento de domnio local. Por exemplo, os peers podem se agrupar para criar uma rede de compartilhamento de documento ou de compartilhamento de CPU (Central Processing Unit). Os grupos de peers servem para subdividir a rede em regies abstratas que fornecem um mecanismo de escopo implcito As fronteiras do grupo de peers so definidas pelo escopo da pesquisa, quando realizada uma busca de contedos e servios de um grupo; Criao de ambiente de monitoramento - grupos de peers permitem a criao de mecanismos para realizao de monitoramento dos conjuntos de peers para qualquer propsito especfico.

Os grupos tambm podem ser formados seguindo hierarquia de pais e filhos. Neste modelo, uma busca que se origina no grupo pai poder percorrer a rede at chegar aos grupos filhos, e a busca poder ainda continuar descendo na hierarquia at que seja devolvido um ou mais resultado a quem a realizou [21].

iii.

Servios de Rede Os peers realizam comunicaes e publicaes para que possam descobrir e invocar

servios da rede. Os peers podem publicar vrios servios e estes servios so descobertos

26

atravs do DPP (Discovery Protocol Peer). Os protocolos JXTA apresentam dois nveis de servios de rede: Servios de Peer - acessveis apenas no ponto que est publicando. Se esse ponto vier a falhar, o servio tambm falhar e vrias instncias do servio podem ser executadas em peers diferentes, mas cada instncia realiza a publicao do seu prprio anuncio de servio; Servios de Grupo de Peers - compostos por uma coleo de instncias de servios que potencialmente cooperaro uns com os outros, sua execuo poder ser hospedada em vrios membros do grupo de peer. Caso qualquer um destes membros falhar, o servio coletivo de peer no afetado, desde que esteja disponvel em pelo menos mais um membro do grupo. Servios de grupos de peers so publicados como parte do anuncio do grupo, desta forma ao se criar um grupo automaticamente so anunciados os seus servios. Os servios podem ser pr-instalados em um ponto ou carregados atravs da rede. Quando um peer apresenta a necessidade de executar um servio, este peer pode localizar uma implementao adequada para o ambiente em tempo de execuo. O processo de encontrar, baixar e instalar um servio da rede anlogo ao realizar uma pesquisa na internet para uma pgina da web [21].

iv.

Servios do Grupo de Peers O grupo de peers oferece servios ou conjuntos de servios que geralmente so

conhecidos por todos os membros do grupo. Por definio, o JXTA oferece alguns servios bsicos para os grupos de peers. A soma dos servios j existentes, com novos servios que os peers do grupo oferecem, forma a assinatura de servios do grupo de peers, logo, quando um novo peer entra no grupo, deve ser repassado a este peer o conhecimento dos servios disponveis neste grupo [21]. Os servios bsicos que um peer deve implementar ao entrar em um grupo de peer, numa rede JXTA so:

27

Servio de Endpoint - usado para enviar e receber mensagens entre peers. Os servios endpoint implementam os pontos de extremidades no protocolo de encaminhamento, embora as implementaes mnimas forneam apenas uma pequena poro deste protocolo;

Servio Resolver - servio de resoluo usado para enviar solicitaes de consultas genricas para os peers. Os peers podem trocar consultas para encontrar qualquer informao que possa ser necessria (por exemplo, encontrar anncios, determinar o status de um servio ou a disponibilidade de uma extremidade do pipe).

Alm dos principais servios dos grupos de peers necessrios para o funcionamento de cada peer, vrios outros servios padres do JXTA so comumente definidos para o grupo. Nem todos os servios padres devem ser implementados pelo grupo de peers, e dependendo da definio do grupo estes servios podem ser necessrios ou no. Um grupo de peer especifica apenas os servios que encontra entre os peers que formam o grupo, pode tambm contar com os servios dos grupos de peers fornecidos pelo JXTA para oferecer implementaes genricas de servios essenciais. Os servios peer padres, que so encontrados na maioria dos grupos de peers, so: Servio de Descoberta - usado pelos peers para procurarem recursos do grupos de peers que foram publicados. Estes recursos podem ser: peers, grupos de peers ou servio de pipes; Servio de Composio - utilizado pelos peers para estabelecer de forma segura e confiante a identidade dos peers dentro de um grupo. A identificao permite que os aplicativos e servios determinem quem est solicitando uma operao e decide se a operao deve ser permitida; Servio de Acesso - usado para validar as requisies feitas de um ponto para outro. O peer receptor do pedido verifica as credenciais do peer solicitante e verifica as informaes sobre a requisio e aps terem sido feitas as verificaes determina se o acesso permitido ou negado; Servio de Pipe - usado para criar e gerenciar conexes de pipes entre os membros do grupo de peer;

28

Servio de Monitoramento - usado para permitir que um peer possa monitorar outros membros do mesmo grupo de peers a que pertence.

v.

Mensagens Servios e aplicaes JXTA se comunicam utilizando mensagem, que a unidade bsica

de troca de dados entre os peers. O conjunto de protocolos JXTA define como os participantes da rede faro as trocas de mensagens entre si. As mensagens so enviadas de um peer para o outro usando os servios de endpoints e servio de pipes, e em alguns casos so usados tambm o servio JxtaSocket ou outras abordagens. Grande parte dos aplicativos no precisa usar pipe unidirecional ou usar servio de endpoint JXTA. Nestes casos, aplicaes e servios usam Socket JXTA e canais de comunicao JxtaBiDiPipe para enviar e receber mensagens pela rede [21]. Os protocolos JXTA especificam um conjunto de mensagens que devem ser trocadas na rede, e a utilizao de XML (Extensible Markup Language) para descrever estas mensagens permite que diferentes tipos de peers possam utilizar este protocolo. Como os dados so descritos em uma estrutura XML bem formada, cada peer pode implementar o protocolo da forma que se adqua melhor s suas capacidades e funes. Se um peer s precisa de um determinado subconjunto de informao contida na mensagem, as tags de dados XML permitem que o peer identifique apenas os dados da mensagem de que o peer necessita. Desta forma um peer que tem pouca capacidade de processamento seleciona apenas o contedo que consegue processar [21].

vi.

Pipes Aplicaes JXTA usam pipes para enviar mensagens de um peer para o outro. Os pipes

so mecanismos assncronos, unidirecionais e no-confiveis (com a exceo do pipes unicast seguro) de transferncia de mensagens usados para comunicao e transferncia de dados. Pipes so canais de comunicao virtual e podem conectar os peers que no tm uma ligao fsica direta e esta ligao resulta em uma ligao lgica. Os pipes podem ser usados para enviar qualquer tipo de dados, incluindo XML e texto HTML (HyperText Markup Language), imagens, msicas, cdigo binrio, sequencias de dados e objetos Java.

29

As extremidades do pipe so referenciadas como pipe de entrada ou recepo e pipe de sada ou envio. Os endpoints pipes so ligados dinamicamente aos peers terminais quando o pipe aberto. Os peers endpoints correspondem a interfaces de rede disponveis, funcionando como uma porta TCP associada a um endereo IP (Internet Protocol) que pode ser usado para enviar e receber mensagens. Pipes JXTA podem ter endpoints que esto conectados a diferentes peers em diferentes momentos e no podem ser ligados a outro pipe. Todas as resolues de pipe e comunicao so feitas no mbito do grupo de peer. Isto , os pipes de entrada e sada devem pertencer ao mesmo grupo [21]. Os pipes oferecem dois modos de comunicao que so os modelos ponto-a-ponto e propagao, como ilustrado na Figura 5. A implementao JXTA denominada JXSE [23] tambm fornece segurana nos pipes unicast, onde se trata de uma variao com segurana do pipe ponto-a-ponto.

Figura 5. Pipes unicast e Pipes de propagao (Fonte: Sun Microsystems)

Pipe Ponto-a-Ponto: conectam dois peers em conjunto e, nas extremidades, o pipe de entrada do peer receptor recebe mensagens enviadas a partir do pipe de sada do peer emissor, sendo possvel que mltiplos peers se conectem a um nico pipe de entrada;

Pipe de Propagao: interliga um pipe de sada a um pipe de entrada mltiplos. As mensagens de fluxo a partir do pipe de sada so a fonte de propagao para dentro dos pipes de entrada;

Pipe Unicast Seguro: pipe ponto-a-ponto que prov mecanismos de segurana e confiabilidade nos canais de comunicao.

30

Os pipes unidirecionais apresentam na especificao do JXTA um baixo nvel de abstrao na comunicao. Recomenda-se que desenvolvedores usem um nvel de abstrao mais alto para a comunicao que pode ser fornecida pelo servio JXTASocket e JXTABiDiPipe [21].

vii.

JXTASocket e JXTABiDiPipe Os pipes JXTA bsicos fornecem canais de comunicao unidirecionais no-confiveis,

com objetivo de tornar os pipes mais teis para servios e aplicaes, sendo necessrio implementar canais de comunicao bidirecionais confiveis na parte alto nvel do pipe. O JXSE [23] fornece funcionalidades para atender os nveis de qualidade de servio exigido pelas maiorias das aplicaes P2P [21]: Confiabilidade; Garantia do seqenciamento da mensagem; Garantia de entrega; Exposio das interfaces de streaming de mensagens; Segurana; JxtaSocket e JxtaServerSocket: - Sub-classe java.net.Socket e java.net.ServerSocket respectivamente; - So construdos em cima de pipes e mensagens de endpoit, apoiado por uma biblioteca de confiabilidade; - Fornece canais bidirecionais de comunicaes confiveis e seguras; - Disponibiliza uma interface baseada em streaming; - Fornece buffer interno configurvel e mensagens de chunking; JxtaBiDiPipe e JxtaServerPipe: - So construdos em cima de pipes e mensagens de endpoit, apoiado por uma biblioteca de confiabilidade; - Fornece canais bidirecionais de comunicaes confiveis e seguras; - Disponibiliza uma interface baseada em mensagem.

31

Em resumo, o JxtaServerSocket e JxtaServerPipe disponibilizam um pipe de entrada para processar as solicitaes de conexo e negociar os parmetros de comunicao. J o JxtaSocket e JxtaBiDiPipe se conecta aos respectivos pipes dedicados independentes do pipe, a Figura 6 ilustra os passos realizado por ambas as abordagens [21].

Figura 6. Conexo Pipes (Fonte: Sun Microsystems)

viii.

Anncio

Todos os recursos de rede JXTA como peers, Grupos de peers, pipes e servios so representados como anncios, que so de linguagem neutra de meta-dados, representados por documentos com estruturas XML. Os protocolos que compem o JXTA usam anncios para descreverem e publicarem as existncias de recursos entre peers. Os peers descobrem recursos, procurando por anncios correspondentes, e podem armazenar localmente em cache todos os anncios descobertos [21]. Cada anncio publicado com um tempo de vida que especifica a disponibilidade de seu recurso associado. O tempo de vida permite a supresso de recursos obsoletos sem necessidade

32

de qualquer controle centralizado. O anncio pode ser re-publicado (antes de o anncio original expirar) para estender a vida til de um recurso. O protocolo JXTA define os seguintes tipos de anncio: Anncio de Peers: descreve os recursos do peer, e a principal utilizao deste anncio para armazenar informaes especficas sobre o peer, como seu nome, ID de peer, os endpoints disponveis, e todos os atributos e servios individuais de grupo que pretende publicar em tempo de execuo; Anncio de Grupo de Peers: descreve os recursos especficos do grupo de peers, tais como nome, ID de grupo de peers, descrio, especificao e parmetros de servio; Anncio de Pipe: descreve o canal de comunicao do pipe, e usado pelo servio de pipe para criar a entrada associada ao ponto da extremidade de sada do pipe. Cada anncio de pipe contm um ID opcional simblico, um tipo de pipe ID nico; Anncio de Classe de Mdulo: descreve as classes de mdulos e sua principal finalidade documentar formalmente a existncia de uma classe de mdulo e so includos nome, uma descrio e uma identificao nica que o ModuleClassID; Anncio de Especificao de Mdulo: define a especificao do mdulo e seu principal objetivo oferecer referncias para a documentao necessria a fim de criar implementaes conforme a especificao. O uso secundrio e opcional deste anncio pode ser feito atravs da execuo de uma instncia utilizvel remotamente atravs da publicao de informaes como anncio de pipes. Isso inclui nome, descrio, identificao nica que o ModuleSpecID, anncio dos pipes e campos contendo parmetros arbitrrios para serem interpretados por cada aplicao; Anncio de Implementao de Mdulo: define a implementao da especificao de um mdulo, os elementos incluem nome associado ao ModuleSpecID, cdigo, pacote, e campos de parmetros que permitem que um peer recupere dados necessrios para executar uma aplicao; Anncio de Rendezvous: descreve um peer que atua como um ponto de encontro para os grupos de peers; Anncio de Informao de Peer: descreve as informaes de recurso do peer e a principal utilizao deste anncio armazenar informaes especficas sobre o estado atual de um

33

peer, como tempo de atividade, nmero de mensagens de entrada e sada, tempo da ltima mensagem recebida e mensagem enviada pela ltima vez. Cada anncio representado por um documento XML, e os anncios so compostos de uma srie de elementos hierarquicamente dispostos, onde cada elemento pode conter os seus dados ou elementos adicionais. Um elemento tambm pode ter atributo como nome do peer. Um atributo usado para armazenar meta-dados, o que ajuda a descrever os dados dentro de cada elemento.

2.3 Principais frameworks Cloud Storage

Uma vez apresentado o modelo de sistema distribudo P2P e a Plataforma JXTA, que consistem no estado da arte para o desenvolvimento de grids computacionais utilizando recursos ociosos, o tpico a seguir descreve trs frameworks desenvolvidos para implementar, gerenciar e controlar o armazenamento e a recuperao dos dados pelos usurios finais. Em seguida, a partir da observao das principais caractersticas que compem essas trs abordagens, ser escolhido um framework no qual ser desenvolvido um testbed com o objetivo de simular o funcionamento do sistema. Dessa forma, ser possvel aferir as principais mtricas de desempenho e subsidiar o modelo de avaliao de viabilidade proposto por essa pesquisa.

2.3.1 GFS
Apresentado em 2003, o Google File System [24] a primeira abordagem em larga escala visando o armazenamento distribudo atravs de milhares de mquinas diferentes ao longo de uma rede. Inicialmente desenvolvido para suprir a crescente demanda de processamento do site de buscas Google, o GFS fornece as bases para as principais preocupaes dos sistemas de armazenamento distribudos, tais como disponibilidade. desempenho, escalabilidade, confiabilidade e

34

O cluster GFS consiste em um controlador, chamado master, e mltiplos chunkservers, acessado por mltiplos clientes, conforme mostra a Figura 7. Cada um desses componentes tipicamente uma mquina Linux, executando um processo de servidor a nvel usurio, sendo comum executar as funes de master e chunkserver na mesma mquina, desde que a mesma possua recursos para tal e seja aceita a reduo de confiabilidade do sistema decorrente de uma paralisao simultnea de ambas as funes. Os arquivos so divididos em fragmentos de tamanho fixo, denominados chunks. Cada chunk identificado por uma identificao global fixa de 64 bit (chunk handle), designada pelo servidor mster no momento da criao do chunk. Os chunkservers, por sua vez, armazenam os chunks nos discos locais como arquivos Linux e armazenam e recuperam os dados a partir das informaes de chunk handle e na capacidade de bytes. Para garantir a confiabilidade do sistema, cada fragmento replicado em mltiplos chunkservers. Por padro, so geradas trs rplicas do mesmo chunk, porm esse valor pode ser alterado de acordo com as especificaes do sistema.

Figura 7. Arquitetura GFS (Autores: Ghemawat, Gobioff e Leung [24])

O master mantm todos os metadados do sistema de arquivos, incluindo nome do arquivo, controle de acesso, a correspondncia entre os arquivos e os fragmentos e a localizao dos chunks. Ele tambm controla todas as atividades de gerenciamento do sistema, tais como designao da identificao dos chunks, deleo de fragmentos rfos e migrao de fragmentos entre chunkservers. Para tal, o master envia atualizaes peridicas para cada chunkserver, atravs de mensagens do tipo HeartBeat, contendo instrues e verificando os seus estados.

35

Para armazenamento e recuperao dos dados, os clientes GFS possuem aplicaes que implementam uma interface lgica (API Application Programming Interface) de comunicao entre o master e os chunkservers. Esses clientes interagem diretamente com o servidor master, porm todos os dados enviados so fragmentados, replicados e enviados para os elementos de armazenamento (chunkservers). Embora no descreva detalhadamente os componentes de software que compem os mdulos de controle (master) e de armazenamento (chunkservers), o GFS introduziu conceitos importantes para o desenvolvimento de ferramentas de armazenamento em nuvem a partir da formao de clusters, ou federao de dados, tais como a fragmentao em tamanho fixo (chunks), a quantidade de rplicas necessrias e os mecanismos de interao entre os diversos componentes, de modo a garantir o desempenho e a flexibilidade necessria ao sistema. Aplicando esses conceitos, novas ferramentas foram desenvolvidas e aprimoradas, tais como o Projeto Campus Cloud [25] e USTO.RE [26], apresentados a seguir.

2.3.2 Campus Cloud

Partindo dos conceitos apresentados pelo Projeto GFS, o Campus Cloud [25] trata-se de uma ferramenta desenvolvida com objetivo principal de armazenar e compartilhar dados, apresentando uma srie de recursos que podem ser acessados de forma distribuda. Esta ferramenta disponibiliza para os usurios uma interface de acesso ao sistema de arquivo, tornando a tarefa de acessar e manipular arquivos de fcil manuseio para o usurio. Para aumentar a comodidade dos usurios, ela prope dois meios de utilizao, sendo estes: via ferramenta instalada no computador e via portal web. Esse framework tem como base o modelo de cloud computing IaaS (Infrastructure as a Service), oferecendo um sistema de arquivo acessvel de forma online. No caracterstica da ferramenta, prover recursos de manipulao de dados, visto que a mesma apenas disponibiliza um sistema de arquivo. Os dados armazenados neste sistema de arquivo so distribudos entre a infraestrutura do Campus Cloud, e os meios pelos quais os usurios destes dados tem acesso a eles so completamente abstrados pela ferramenta. A Figura 8 ilustra a arquitetura Campus Cloud.

36

Figura 8. Arquitetura Campus Cloud (Autores: Xu, Huang, Wu, Liu e Zheng [25])

Cada elemento apresentado na terceira camada da arquitetura Campus Cloud pode estar em local distinto de forma distribuda, reforando a potencialidade da ferramenta em manter sua interoperabilidade e heterogeneidade. O grande diferencial desta ferramenta a facilidade que ela proporciona aos utilizadores em realizar atividades como enviar e resgatar dado, permitindo a manuteno dos mesmos tanto atravs de um browser acessado via internet, quanto atravs de um cliente instalado no computador. Em ambos os casos, tem-se um ambiente de fcil interao para o usurio final, abstraindo todo que h por traz do funcionamento da ferramenta.

2.3.3 Projeto USTO.RE

Visando aliar a escalabilidade apresentada pelo Projeto GFS com a usabilidade do framework Campus Cloud, foi apresentada a ferramenta USTO.RE. Primeiramente apresentada por Duarte [26] como testbed para o desenvolvimento de um algoritmo de disponibilidade usando a arquitetura P2P, atravs do clculo de probabilidade de falha de cada n de armazenamento. Essa ferramenta, inicialmente denominada U-BKP, utiliza uma arquitetura P2P Hbrida baseada na Plataforma JXTA, detalhadas no incio desse captulo.

37

Nesse cenrio, os peers so agrupados em federaes de dados, permitindo o crescimento elstico e a escalabilidade do sistema, definindo assim uma cloud storage. A principal vantagem da ferramenta USTO.RE a capacidade de prover solues de armazenamento de dados em ambientes de nuvens pblicas ou privadas. Por esse motivo, essa ferramenta ser utilizada na elaborao do prottipo e nos experimentos a serem desenvolvidos para validao dessa pesquisa, os quais sero detalhados nos Captulos 3 e 4.

2.4 Sumrio do Captulo

Conforme acompanhado na leitura do captulo, este teve a finalidade de descrever o modelo P2P e a Plataforma JXTA, tecnologias que suportam o desenvolvimento de um sistema de armazenamento distribudo conforme proposto por essa pesquisa. Aps essa descrio, foi realizado um levantamento de trs ferramentas capazes de subsidiar a elaborao de um prottipo para validao da proposta, bem como suas arquiteturas e aspectos funcionais. Por fim, foi escolhida a ferramenta USTO.RE para suportar tal prottipo, que ser detalhada no captulo a seguir.

38

3 ARQUITETURA USTO.RE
No captulo que se segue, detalhada a arquitetura da plataforma apresentada pelo Projeto USTO.RE, descrevendo seus principais padres, mdulos, componentes, frameworks e integraes. De modo a permitir uma viso de alto nvel do contexto utilizado como testbed para anlise do trfego de um sistema de armazenamento P2P em nuvem. Alguns termos importantes que sero mencionados no decorrer deste captulo. Estes termos so descritos na tabela a seguir, estando apresentados por ordem alfabtica:
Tabela 1 Conceito dos termos utilizados na arquitetura
Termo Descrio

Componente

Elemento de software reusvel, independente e com interface pblica bem definida, que encapsula uma srie de

funcionalidades e que pode ser facilmente integrado a outros componentes. Servio Agrupamento lgico de funcionalidades para facilitar a diviso e entendimento de um software.

A especificao do sistema foi dividida em duas partes: Descrio do Sistema e Descrio dos componentes e servios. Cada uma dessas vises aborda as principais perspectivas: A Descrio do Sistema apresenta o hardware envolvido e o mapeamento dos elementos de software para os elementos de hardware nos ambientes do sistema. A Descrio dos Componentes e Servios apresenta os aspectos de concorrncia e sincronizao do sistema, alocando os elementos da viso funcional dos processos, threads e tarefas de execuo. Como o sistema de armazenamento USTO.RE j se encontra em produo e disponvel comercialmente (http://usto.re), alguns aspectos relacionados implementao do mesmo foram suprimidos, tais como os padres de codificao, tecnologias utilizadas, ambientes de desenvolvimento e bibliotecas, porm, sem prejuzo para a pesquisa apresentada nesse trabalho.

39

3.1 Descrio do sistema

Esta seo apresenta a descrio geral do sistema, especificando os principais componentes, dependncias e relacionamentos. O objetivo geral do USTO.RE, permitir a criao de uma nuvem para armazenamento de dados utilizando a tecnologia P2P que se baseia na disponibilidade de cada peer para, dinamicamente, criar federaes e definir a quantidade de replicaes de cada fragmento (chunk) de cada arquivo, conforme viso geral disposta na figura 9 abaixo.

Figura 9. Viso geral da arquitetura USTO.RE (Autor: Rodrigo Elia Assad)

O sistema composto por um conjunto de cinco componentes, dispostos em uma arquitetura P2P hbrida e em trs camadas:

40

(i) (ii) (iii) (iv) (v)

Super Peers Rendezou Relay ou Super Peers; Servidores; Proxies; Banco de Dados Relacionais e No-SQL; Simple Peers

Estes componentes possuem funcionalidades distintas e interagem como um sistema distribudo descentralizado hbrido, de modo semelhante a uma rede P2P, onde cada n realiza tanto funes de servidor quanto de cliente. Os componentes agrupam-se dinamicamente como federaes de dados, onde os grupos so montados de modo a minimizar a troca de mensagens no sistema. A organizao do sistema nesta arquitetura multicamadas possibilita a distribuio do processamento, uma vez que os componentes esto fisicamente distribudos. Entretanto, por se tratar de uma arquitetura hbrida P2P estruturada e multicamadas, o sistema possui uma distribuio dita horizontal. Nesta distribuio horizontal, em uma rede P2P, um cliente ou um servidor podem estar fisicamente divididos em partes logicamente equivalentes, onde cada um atua sobre a sua prpria poro dos dados, propiciando um balanceamento da carga. Na seo seguinte, sero detalhadas as funes de cada componente descrito nesse tpico, bem como as etapas de funcionamento indicadas nas setas vermelhas, da Figura 9.

3.2 Descrio dos Componentes e servios

Esta seo ir detalhar as funcionalidades e interaes e servios oferecidos pelos componentes apresentados no tpico anterior, visando o melhor entendimento da soluo estudada nessa pesquisa.

3.2.1 Super peers

Os super peers funcionam como elementos de referncia para os demais componentes da arquitetura, sendo a porta de entrada para a participao de servidores, proxies e simple peers no

41

sistema. O papel do super peer definir as federaes de dados quando cada peer solicita conexo rede. Para isso, os super peers devem ter sua localizao previamente conhecida por todos os demais peers por meio de uma pr-configurao. Conseqentemente, eles so os primeiros componentes a serem inicializados para o correto funcionamento do USTO.RE. Tambm como conseqncia, um super peer guarda informao sobre todos os servidores, proxies e simple peers, agrupando-os dinamicamente de acordo com o perfil de cada peer, a ser descrito adiante. Tambm papel deste tipo de peer, escolher dinamicamente os peers e servidores das federaes, baseando-se no algoritmo de disperso descrito por Duarte [26] e citado no tpico 2.3.3 deste trabalho. O agrupamento em federaes permite o crescimento elstico e garante a escalabilidade do sistema, pois no existe um limite para a quantidade de federaes que podem ser criadas. Por crescimento elstico temos a caracterstica de o sistema crescer ou diminuir, em termos de capacidade e consumo de recursos, de maneira dinmica e no intrusiva. Os peers se comunicam com a rede P2P atravs do protocolo JXTA, descrito no tpico 2.1 dessa pesquisa, e opcionalmente podem ofertar uma interface de servio REST [27] para permitir a interoperabilidade com outras aplicaes.

3.2.2 Servidores
Os peers servidores so aqueles que oferecem um conjunto (ou subconjunto) de uma lista prdefinida de servios. Na ordem de configurao do USTO.RE, os servidores so os componentes que devem ser executados logo aps a inicializao dos super peers (Passo 1 na Figura 9). Super peers estabelecem um esquema de sincronizao, fazendo com que a lista de servidores em cada um deles seja atualizada, quando da entrada ou sada de um peer servidor. A definio de peers com funcionalidades especficas na rede opem-se a algumas propostas para sistemas P2P, onde cada peer deveria ser capaz de desempenhar todos os papis no sistema, promovendo a idia de uma DHT (Distributed Hash Table) completa [9]. No entanto, a implementao utilizando uma DHT em sua essncia bastante custosa e de difcil escalabilidade, conforme demonstrou Nocentini, Crescenzi e Lanzi [28]. Sendo assim, a proposta adotada no USTO.RE a criao de nveis hierrquicos que implementam servios bem

42

definidos e que podem crescer horizontalmente. Dentre os servios disponibilizados pelos servidores, pode-se citar: 1) Autenticao: usado para que cada peer se autentique; 2) Disponibilidade: permite checar a disponibilidade de cada peer; 3) Chunk: usado para controle dos chunks, conforme detalhamento no Captulo 4; 4) Controle de Sada: controla a sada voluntria de um peer, quando este se desconecta voluntariamente da rede; 5) Gerncia de Diretrios: utilizado para armazenamento e recuperao de diretrios inteiros; 6) Gerncia de Arquivos: utilizado para armazenamento e recuperao de arquivos; 7) Busca: procura por um conjunto de peers que obedecem ao acordo de nvel de servio, no caso dessa aplicao, est fortemente relacionado disponibilidade do peer para o armazenamento de um arquivo; 8) rvore de Diretrios: utilizado para visualizao de diretrios inteiros; 9) Segurana de Acesso: controla a permisso de acesso aos chunks; 10) Rastreamento: mantm uma lista de usurios e arquivos a ser consultada quando a recuperao de um arquivo solicitada. Como se observa na Figura 9, os peers servidores utilizam dois tipos de banco de dados para manter a consistncia do sistema. Um banco de dados tradicional relacional contm dados dos usurios do sistema e um banco de dados No-SQL [29], que permite um crescimento horizontal e a recuperao mais rpida das informaes relacionadas ao desempenho do sistema. Caso no fosse dada essa abordagem, com o aumento do volume de arquivos e chunks salvos, o sistema de gerenciamento de banco de dados tenderia a se tornar um ponto de gargalo, o que no ocorre com a utilizao de um sistema nativamente, garantindo assim a viabilidade e escalabilidade da soluo. Todas as informaes referentes autenticao e nveis de servio dos peers so salvas no banco de dados relacional, dada a garantia da integridade relacional provida por esse tipo de banco de dados. J o servio do FileTracker, que permite a identificao de qual peer possui partes do arquivo a ser recuperado, utilizada no banco de dados No-SQL, o que garante o

43

crescimento horizontal. As instncias de ambos os bancos podem ser compartilhadas entre mais de um servidor. Um peer servidor pode prover um ou mais servios de rede, sendo assim, da mesma forma que na criao de federaes de dados, pode-se iniciar peers servidores e proxies ad-hoc (sob demanda), aumentando a escalabilidade e elasticidade do sistema. No atual estgio do projeto, este aumento feito manualmente, a partir do monitoramento do desempenho do sistema.

3.2.3 Proxies
Aps a inicializao de super peers e servidores, o terceiro componente que precisa ser executado o proxy. Cada proxy atua como um catlogo, um servio de localizao para servios em execuo nos diferentes servidores do USTO.RE. Um Proxy ao se anunciar a um super peer (Passo 2 na Figura 9), recebe a lista de servidores registrados. Alm disso, um proxy obtm a informao de quais servios esto disponveis em cada servidor. Desta forma, quando um peer deseja a informao sobre um determinado servio, um proxy pode fornecer a referncia para um servidor que atenda tal requisio. Dessa forma, um proxy estabelece uma ponte de ligao entre consumidores de servios, tipicamente os simple peers, e os provedores de um servio, no caso, os peers servidores.

3.2.4 Simple peers

Simple peers so aqueles responsveis por armazenarem os chunks (fragmentos) dos arquivos. Na viso alto nvel da proposta, estes peers representam mquinas de usurios comuns que possam oferecer espao de armazenamento para ser compartilhada entre vrios usurios. Cada simple peer possui um perfil que define a sua disponibilidade e que lhe atribudo quando da sua conexo com o sistema. Esta disponibilidade relacionada ao perodo de tempo em que o peer esteja disponvel para compartilhar dados. Como exemplo, um peer que esteja na intranet de uma empresa pode ter em seu perfil, a disponibilidade atribuda como plena das 8h s 12h e 14h s 18h. Quando um simple peer se conecta ao sistema, ele recebe de um super peer a lista de

44

proxies disponveis (Passo 3 da Figura 9). Desta lista, o proxy busca por um servio especfico e obtm a referncia de quais servidores ofertam determinado servio (Passo 4 da Figura 9). Um servidor aleatrio escolhido e o simple peer solicita o servio desejado (Passo 5 da Figura 9). Caso um servio no seja atendido por algum motivo, como um timeout, o proxy pode fornecer um novo servidor para o simple peer. Como citado anteriormente, simple peers so agrupados em federaes de dados pelos super peers. O objetivo de agrup-los dessa forma minimizar a sobrecarga na rede e em cada peer, alm de diminuir a quantidade de mensagens trocadas e permitir que uma federao desempenhe o papel de backup da outra federao. O agrupamento dos peers em federaes obedece aos seguintes critrios, por ordem de relevncia: proximidade; perfil de cada simple peer; latncia de rede; latncia da federao; georeferenciao; capacidade de cada peer e capacidade final da federao, definida pelos super peers. Cada peer possui uma interface de servio REST [27] que permite a autenticao do usurio, armazenamento, recuperao e remoo dos dados salvos. Tal caracterstica apresenta como principal vantagem a possibilidade de compatibilizar o sistema com outras interfaces existentes, como S3 da Amazon [6]. Na atual arquitetura, o servio de armazenamento dos dados pode ser modificado para outras opes (i.e.: Megastore, MSFSS ou S3). Para garantir o espalhamento de cada chunk de forma a garantir os nveis de servio adequado, cada peer precisa relatar seu estado atual com o objetivo de manter o SLA (Service Level Agreement) sempre atualizado. A Figura 10(a) apresenta o fluxo de funcionamento de um peer (PL1), desde o momento em que ele anuncia o seu perfil comunicao estabelecida com os demais pares por meio do servidor (PS1). Periodicamente cada peer envia para um dos servidores uma mensagem de Keep alive informando que est on-line. Desta forma, o servidor sabe se o peer est cumprindo com o perfil acordado (SLA) e o torna elegvel para receber chunks no horrio definido. Tambm periodicamente peer verifica com os demais peers existentes se os chunks que ele possui esto replicados na quantidade mnima de peers obedecendo ao critrio de disponibilidade exigida [26]. Caso no esteja, ele replica o chunk em outro peer. Quando o peer que possui esse chunk voltar a se conectar a rede, ele ir verificar que existe um excesso deste chunk e ir exclu-lo.

45

A Figura 10(b) apresenta o fluxo de funcionamento entre peers e servidores desde a conexo de peer local rede, ao salvamento dos arquivos solicitados. Aps o peer (PL1) se conectar rede P2P1, o super peer indica um peer servidor para ele se autenticar. Com a autenticao bem sucedida, o processo de identificao dos pares para formar as federaes executado. Com a federao (o agrupamento de peers) estabelecida, o sistema est apto a receber arquivos. Ao receber um arquivo (arq1.zip), o peer PL1 informa a necessidade de armazen-lo no sistema, para isto feita uma segmentao do arquivo (em chunks) e estes segmentos so enviados para serem salvos na rede P2P1. Em seguida, para efetuar um salvamento, um rotina para medir a confiabilidade analisa o estado dos peers e, conseqentemente, da disponibilidade dos segmentos do arquivo na rede e caso exista uma combinao de peers que atenda ao SLA para o armazenamento, os segmentos do arquivo so enviados para estes peers. Se no houver mais segmentos de arquivos a serem salvos, o peer servidor (PS1) comunica ao peer (PL1), que solicitou o salvamento do arquivo e que o mesmo foi salvo com sucesso.

Figura 10: a) Funcionamento de um peer b) Funcionamento de um peer Server proxy (Autor: Vincius Cardoso Garcia)

3.3 Sumrio do captulo

No captulo que se seguiu, foi detalhada a arquitetura do sistema USTO.RE, cuja operao foi especificada tendo como meta atingir um conjunto de atributos de qualidade peculiares aos sistemas de armazenamento distribudo, aliado a aspectos intrnsecos da arquitetura P2P, tais como: a) Escalabilidade: atendendo a possibilidade de explorar recursos de hardware de um grande nmero de mquinas (hosts) conectados rede, principalmente por meio do uso racional de recursos ociosos em grandes corporaes, tais como empresas Operadoras de telecomunicaes.

b) Desempenho: O encurtamento da distncia entre os peers que interagem no sistema, graas ao agrupamento dos mesmos em federaes, reduz a latncia na troca das mensagens de controle, proporcionando melhor desempenho em relao aos sistemas puramente DHTs.

c) Disponibilidade: Graas ao algoritmo de disponibilidade utilizado pelo sistema, no qual so associados perfis de disponibilidade para os peers que compem o sistema, garantida a conectividade e a qualidade de servio necessria a um sistema de armazenamento com alta disponibilidade, superando assim algumas restries impostas pela arquitetura P2P.

Diante do exposto, conclui-se que a arquitetura USTO.RE apresenta todas as caractersticas necessrias para o gerenciamento de um sistema de armazenamento em nuvem, utilizando o paradigma P2P, conforme ser demonstrado nos captulos seguintes, atravs da anlise de um prottipo do sistema e de um estudo de caso.

48

4 ANLISE DE TRFEGO DO PROTTIPO

No captulo a seguir especificado um prottipo do servio, no qual sero analisadas algumas mtricas necessrias para definio de parmetros de controle e dimensionamento do trfego, de modo a subsidiar um modelo de anlise de viabilidade do servio. Esse modelo ser validado em um estudo de caso em uma Operadora de Telecomunicaes. A anlise ser composta pela especificao da arquitetura adotada no prottipo e pela descrio dos experimentos realizados, no qual foi utilizada a metodologia GQM (Goal Question Metric) [30], que orientou a avaliao estabelecendo o objetivo do estudo, as perguntas a serem respondidas e as mtricas para interpretar as respostas.

4.1 Definio dos objetivos e mtricas

A partir da Figura 11, temos uma viso macro da arquitetura proposta para a oferta do servio cloud-computing, utilizando recursos ociosos como a capacidade de armazenamento nas estaes utilizadas como posies de atendimento do Callcenter, por exemplo. Os links grafados em azul so conexes internas entre os elementos do core de rede da Operadora, e seu trfego est relacionado banda contratada pelo cliente, ou seja, no ser influenciado pela contratao do servio de armazenamento, assim como o trfego nos links grafados em vermelho. Para esses links, a oferta do servio de armazenamento utilizando recursos internos ao domnio de rede da Operadora ser benfica, no sentido de reduzir o trfego pelos mesmos, cuja banda representa um custo varivel elevado para as Operadoras, muitas vezes utilizando cabos submarinos ou satlites como meio de transmisso. Isso ocorre porque os clientes que contratarem tal soluo deixaro de utilizar servios armazenados em provedores externos ao ambiente dessas operadoras. Diferentemente dos links marcados em azul e vermelho, o trfego do link marcado em lils ser fortemente influenciado pelo overhead de controle da arquitetura proposta, na qual ser utilizada a capacidade de armazenamento das posies de atendimento do Callcenter. Por esse fato, a principal mtrica a ser analisado no prottipo ser o trfego nesse link em funo da capacidade de armazenamento. Conforme ser detalhado no Cenrio II, a linha tracejada indica o

49

tnel ethernet que ser criado nesse link, atravs do padro IEEE 802.1Q [31], para separar o trfego dos sistemas privados existentes no Callcenter. Uma vez dimensionado o link lils, ser possvel mensurar o investimento necessrio na ampliao do meio de transmisso que o atende, em funo da receita gerada pela capacidade de armazenamento que ser ofertada, algo fundamental para a investigao da viabilidade econmica da soluo proposta por essa pesquisa.

Figura 11: Detalhamento da arquitetura do servio cloud-computing por uma Operadora

Por definio da metodologia GQM, utilizada para orientao da anlise proposta, a anlise foi dividida em dois cenrios, conforme abaixo: a) Cenrio I
Tabela 2: Modelo GQM da Anlise do Cenrio I

50

Goal 1: Reduo do tempo de armazenamento

Question: Qual a configurao de chunk apresenta o armazenamento mais rpido?

Question: Qual a configurao de fila apresenta o armazenamento mais rpido?

Metric: Tempo de armazenamento (s)

Figura 12: Estrutura hierrquica do modelo GQM da Anlise do Cenrio I

b) Cenrio II: Tabela 3: Modelo GQM da Anlise do Cenrio II

51

Goal 2: Medio do trfego mdio entre as redes de carga e de dados

Question: Qual o overhead de controle, nos links de entroncamento, na arquitetura proposta?

Metric: Relao entre os bits trafegados pelos bits armazenados (%)

Figura 13: Estrutura hierrquica do modelo GQM da Anlise do Cenrio II

4.2 Resultados Obtidos

Aps definidos os objetivos dos experimentos, sero descritos os resultados obtidos e detalhados os cenrios.

4.2.1 Cenrio I
Aplicando-se a metodologia GQM, neste cenrio foi definido o seguinte objetivo: definir qual a configurao de controle apresenta o melhor desempenho sob o ponto de vista do usurio, em um sistema de armazenamento P2P utilizando recursos computacionais ociosos e no dedicados. Pelas caractersticas de controle do testbed utilizado (USTO.RE), o desempenho tem relao direta com a quantidade de mensagens trocadas pelos seus componentes internos, tanto no que se refere ao trfego gerado pela aplicao, quanto no consumo dos recursos computacionais de hardware dos peers (consumo de CPU e memria RAM). Essa quantidade de

52

mensagens tem por sua vez, uma relao direta com o tamanho dos chunks e o tamanho das filas de chunks que formam essas mensagens. Nesse contexto, o desempenho foi analisado considerando a variao do tamanho dos chunks e da sua fila, analisando dessa forma o impacto destas variveis no tempo de envio dos dados. O objetivo desse teste identificar se necessrio realizar configuraes especficas quando o ambiente estiver funcionando em ambientes LAN, conforme o proposto por esse trabalho e que ser detalhado no Estudo de caso do Captulo 5. Para a execuo deste teste foram utilizadas 20 mquinas com o sistema implantado, todas com as mesmas configuraes de hardware: Processador Pentium IV, com 2GB de RAM e placa de rede 100 Mbps, de acordo com o padro IEEE 802.3. Ou seja, todas compatveis com o parque instalado nas posies de atendimento do Call-center, coadunando com a idia da utilizao de recursos computacionais no dedicados para o armazenamento de dados em nuvem. Destas mquinas, 15 (quinze) enviavam dados (carga) e 5 (cinco) representavam um storage com 10TB de armazenamento. As mquinas de carga enviavam 1GB de dados, sendo: 3 mquinas enviando 2000 arquivos de 500 KB; 6 mquinas enviando 500 arquivos de 5 MB; 3 mquinas enviando 50 arquivos de 50 MB; 3 mquinas enviando 5 arquivos de 200 MB. A tabela 4 apresenta os resultados obtidos nos nove experimentos realizados simulando a carga de dados em um sistema de armazenamento P2P em uma LAN, manipulando-se as variveis de controle responsveis pela fragmentao e enfileiramento dos chunks. Na segunda coluna temos os valores referentes ao tamanho do chunk em KB, enquanto na terceira temos o tamanho da fila em quantidade de chunks e na coluna mais direita, temos o trfego mdio em cada experimento, calculado pelo trfego cursado em funo do tempo total de transferncia. Fica evidente o impacto significativo no desempenho do sistema quando h variao dos parmetros analisados, sendo este impacto maior, quando h variao do tamanho do chunk. Isso ocorre, pois h um aumento na quantidade de mensagens a serem enviadas para que um arquivo seja salvo. O menor tempo de carga e, conseqentemente, a melhor taxa de transferncia mdia ocorreu no experimento 8 (marcado em negrito), quando foi utilizada uma fila de 8 chunks de 128 KB totalizando um buffer de 1024 KB (1 MB) a ser transferido. A partir desse ponto, observou-

53

se um decrscimo na taxa de transferncia, indicado que foi atingido o ponto quiescente para a carga de dados pelos peers de carga, conforme fica evidenciado na figura 14, onde temos o trfego mdio de carga, registrado em cada um dos experimentos.
Tabela 4: Trfego mdio de carga, variando-se os parmetros de Chunk e Fila Experimento 1 2 3 4 5 6 7 8 9 Chunks (KB) 32 32 32 64 64 64 128 128 128 Fila 6 8 10 6 8 10 6 8 10 Fila Total (KB) Tempo (s) Trfego mdio (Mbps) 192 1130 7,25 256 893 9,17 320 723 11,33 384 615 13,32 512 452 18,12 640 346 23,68 768 294 27,86 1024 188 43,57 1280 200 40,96

Trfego mdio (Mbps)

43,57 40,96

27,86 23,68 18,12 9,17 11,33 13,32

7,25 1 2

Figura 14: Trfego mdio de carga observado nos experimentos do Cenrio I

Nesse cenrio tambm foi analisada a questo relacionada ao desempenho das mquinas que recebiam os dados, uma vez que o objetivo da pesquisa propor uma arquitetura transparente ao cenrio existente, para utilizao dos recursos de armazenamento ocioso, em mquinas no dedicadas, para a oferta do servio de armazenamento. Isto , a implantao dessa aplicao deve afetar minimamente o desempenho das aplicaes existentes. Observou-se que as mquinas que

54

recebiam os dados chegaram ao limite de consumo do CPU e de memria RAM, ou seja, 100% e 2GB, respectivamente. Por ser essa condio extremamente indesejvel, dada a premissa da transparncia necessria da soluo, foi repetido o experimento 8, que apresentou o melhor resultado na carga de dados, mantendo-se a fila total em 1024 KB, porm utilizando um nico chunk de 1MB. Nessa condio, observou-se uma taxa de transferncia similar ao experimento anterior, porm, sem a saturao da capacidade de processamento e memria das mquinas de carga. Dessa forma, temos que a seguinte resposta ao Goal 1 da anlise do prottipo: Do ponto de vista do usurio final, a melhor configurao para um sistema de armazenamento P2P, controlado pela arquitetura USTO.RE, em um ambiente LAN, ocorre utilizando-se fragmentos de 1MB, enfileirados um-a-um.

4.2.2 Cenrio II
Partindo-se do resultado encontrado no Cenrio I e novamente aplicando a metodologia GQM, foi especificado o seguinte objetivo: definir o overhead de controle, nos links de entroncamento, na arquitetura proposta. O primeiro passo, para inferir essa varivel, reproduzir de forma controlada e manipulvel o cenrio apresentado na figura 11, no qual apresentada a arquitetura para implantao do servio cloud-computing em uma Operadora, utilizando recursos ociosos do seu Contact Center. Para tal, foi utilizado um Switch gerenciado (modelo Cisco Catalyst 2950), no qual foram segmentadas as LANs de carga de dados e de armazenamento, atravs da criao de VLANs e um roteador (modelo Cisco 2620 XM), para a interconexo dessas VLANs, atravs de uma porta tronco, de acordo com o padro IEEE 802.1Q [31]. A topologia e os scripts de configurao so apresentados na figura 15 e 16 - respectivamente. Todas as portas utilizam o padro FastEthernet 100 Mbps, full-duplex e endereamento IPv4.

55

Figura 15: Topologia de simulao da arquitetura proposta

Figura 16: a) Script de configurao do Switch0 b) Script de configurao do Router0

Aps a criao e testes de conectividade no cenrio acima, recriando o prottipo de testes descrito no cenrio I, com o acrscimo da segmentao fsica entre a LAN de carga e de armazenamento, permitindo um controle centralizado do trfego entre as mesmas, visto que todo o trfego cursado entre as mesmas ser encaminhado pelo Router0, atravs da porta tronco, para o Switch0. Isso se faz necessrio em virtude da necessidade de segmentao entre a LAN de armazenamento, que estar em um ambiente privado, de acesso restrito, e da LAN de carga, que estar em um ambiente pblico, de acesso no controlado. No Projeto GFS [24], descrito no tpico 2.3.1, utilizou-se uma arquitetura similar proposta nesse experimento. Entretanto, o mesmo no utilizou a segmentao atravs de VLANs entre elas, criando assim um nico

56

domnio de broadcast em todo o cenrio, no sendo possvel separar o trfego da aplicao P2PSS no link de entroncamento existente, entre o Contact-Center e o core de rede da Operadora. Diante desse fato, no Estudo de caso apresentado no Captulo 5 faz uso de VLAN para a separao do trfego. A partir da, foi refeito o experimento 9, no novo cenrio segmentado, e avaliada a relao do trfego transmitido nos link de entroncamento e a quantidade de bits armazenados pelo servio P2PSS, atravs da edio do comando show interface Fa0/0, no prompt de comandos do roteador Cisco 2620XM. Conforme destacado na figura 17 abaixo, o trfego em questo pode ser avaliado no sentido input (1) ou output (2), dada a simetria de trfego resultante da centralizao do roteamento de pacotes realizada pelo Router0. Ou seja, todo pacote que sai da VLAN de carga passa pelo Router0, onde encaminhado para a VLAN de Armazenamento, e vice-versa.

Figura 17: Roteamento centralizado entre as VLANs

Nessa avaliao, verificou-se que o overhead total de controle da soluo proposta, incluindo os protocolos de aplicao (HTTP), transporte (TCP), internet (IP), acesso ao meio (Ethernet), alm dos bits de marcao de VLAN (IEEE 802.1q) de 49,35%, conforme mostrado na tabela 5.
Tabela 5: Overhead total de controle, da soluo proposta. Dados Dados Armazenados Armazenados (MB) (bits) 1024 8589934592 Total bits no entroncamento (input ou output) 12829067313 Overhead [ (total bits - bits armazenados) / bits armazenados)] 49,35%

57

Aproximando o overhead total para 50%, podemos concluir que para cada 2 bits armazenados, teremos 3 bits transmitidos, sendo 1 de overhead de controle. Ou seja, para a arquitetura proposta, teremos uma taxa mxima lquida de 66 Mbps para a transferncia de dados, em cada link de entroncamento. Caso sejam utilizados links de 1 Gbps, conforme proposto no Projeto Google File System [24], teramos uma taxa mxima lquida de 666 Mbps. Com isso, temos que a seguinte resposta ao Goal 2 da anlise do prottipo: Para a arquitetura proposta, temos um overhead de controle, nos links de entrocamento, de 49,35%. No estudo apresentado por Drago, Mellia e Munaf [32], os autores analisaram o desempenho do servio de armazenamento em nuvem Dropbox [33], similar a proposta do USTO.RE. Nele, foi verificado que na grande maioria das operaes de armazenamento o overhead de controle ficou em 309 bytes por chunk, desconsiderando as mensagens de autenticao do protocolo SSL (usado pelo Dropbox) e de encapsulamento descritos pelas camadas de transporte, rede e enlace do modelo de referncia OSI [34]. Abstraindo-se esse fato e transportando essa relao para a anlise descrita nessa dissertao que considera todos os protocolos de controle - teramos diferena aproximada de 45 p.p. Mesmo considerando o fato da anlise proposta pro Drago, Mellia e Munaf no considerar todos os protocolos de controle e encapsulamento descritos no modelo OSI na anlise do overhead de armazenamento do Dropbox, essa diferena significativa, em relao aos resultados observados no Cenrio II dessa dissertao, sugere novos trabalhos que investiguem mecanismos para a reduo do overhead de armazenamento nos links de entroncamento do framework USTO.RE.

4.3 Sumrio do captulo

No captulo que se seguiu, foi especificado um prottipo do sistema de armazenamento proposto nessa pesquisa, e, atravs da metodologia GQM, analisados dois atributos de funcionamento do sistema: o tempo de armazenamento e o overhead de controle. Para o primeiro atributo, foram investigados quais os parmetros eram mais relevantes e a melhor configurao dos mesmos, atravs de nove experimentos prticos. Tais experimentos

58

comprovaram a influncia da fragmentao no tempo de armazenamento e indicaram o uso de fragmentos de 1MB, enfileirados um-a-um. Com relao ao segundo atributo, procurou-se estabelecer uma relao da capacidade de armazenamento com o dimensionamento dos links de interligao entre os subsistemas de armazenamento e carga, atravs do estudo do overhead de controle da aplicao. Partindo-se do experimento que apresentou melhor resultado no tempo de armazenamento, foi introduzida uma arquitetura de roteamento centralizado e analisada a relao do trfego transmitido com os dados armazenados, chegando-se ao valor de 49,35% de overhead de controle. Esse valor, comparado a estudos em uma aplicao similar (Dropbox) sugere o desenvolvimento de novos estudos que investiguem mecanismos que reduzam overhead de armazenamento nos links no framework USTO.RE.

59

5 ESTUDO DE CASO
Aps a definio da arquitetura proposta nessa pesquisa, bem como a investigao do seu funcionamento, o presente captulo contextualiza a oferta do servio de armazenamento distribudo (Cloud computing) nas Operadoras de Telecomunicaes, caracteriza o

dimensionamento e a especificao tcnica da soluo. Em seguida, apresentada uma anlise da viabilidade econmica do Projeto, utilizando ferramentas clssicas de Engenharia Econmica.

5.1 Servio Cloud-Computing nas Operadoras de Telecomunicaes

Desde a privatizao do sistema Telebrs, em 1998, o mercado de telecomunicaes brasileiro vem sofrendo profundas transformaes. Dentre essas mudanas, as mais marcantes so a convergncia na oferta de servios e a acirrada concorrncia entre os principais players. A Figura 18 abaixo ilustra a dinamicidade e a tendncia de concentrao nesse segmento econmico, mostrando a evoluo do mercado nos ltimos 12 anos. Somados, os sete principais grupos listados, apresentaram uma receita lquida superior a R$ 30 bilhes, no segundo trimestre de 2012.

Figura 18: Consolidao do mercado brasileiro de Telecomunicaes

60

Nesse cenrio, o aumento de receita proveniente da oferta de servios convergentes, como valor agregado, determinante para a sobrevivncia das empresas, e um bom exemplo disso a oferta de servio de armazenamento em nuvem. Cientes dessa realidade, quatro dos principais grupos citados, incluram recentemente o produto cloud computing em seus portflios, especialmente voltado para o mercado corporativo, conforme abaixo:
Tabela 6: Produtos cloud-computing ofertados por Operadoras de Telecomunicaes Produto CloudComputing Oi Smart Cloud TIM Cloud Vivo Cloud Plus Ainda sem nome Data de lanamento fev/12 mar/12 abr/12 set/12 Investimento Anunciado R$ 30 milhes No revelado No revelado R$ 100 milhes

Grupo Oi TIM Telefonica Telmex

Fonte https://loja.oismartcloud.com.br http://exame.abril.com.br http://www.tiinside.com.br http://www.embratel.com.br

Alm da receita proveniente dos servios de valor agregado, outro aspecto importante a ser observado em mercados de concorrncia acirrada como o de telecomunicaes a maximizao do uso dos recursos disponveis, uma vez que se trata de um setor com necessidade de investimento massivo e inovao tecnolgica constante. Entretanto, os quatro grupos que anunciaram o lanamento do servio de armazenamento destacaram o investimento na aquisio de novos datacenters, ou na ampliao dos existentes. Paradoxalmente, tanto o Grupo Oi - que anunciou o investimento de R$ 30 milhes, quanto o Grupo Telmex cujo investimento da ordem de R$ 100 milhes, para ampliao da capacidade de armazenamento demandada pelo novo produto, no consideraram o uso do parque disponvel nas empresas de Callcenter que detm. Segundo o portal www.callcenter.inf.br [35], a subsidiria Contax, do Grupo Oi, possui um parque instalado de 48.233 posies de atendimento, enquanto a subsidiria BrasilCenter, da Embratel (Grupo Telmex), opera um parque de 3.950 posies de atendimento. Caso fosse considerado o uso de apenas 1 GB de armazenamento em cada posio de atendimento, teramos uma capacidade de 47,1 TB de armazenamento disponvel na Contax e 3,85 TB na BrasilCenter, respectivamente. Ainda segundo esse portal, nos Callcenters brasileiros existe um parque total de 232 mil posies de atendimento, que, seguindo o raciocnio anterior, representam uma capacidade de 226,5 TB de armazenamento ocioso. Levando em considerao a baixa demanda

61

de armazenamento nos desktops usados nessas posies de atendimento, possvel que esse nmero seja ainda bem maior e a capacidade ociosa atinja a ordem de grandeza de petabytes.2 Diante dos nmeros apresentados, fica evidente o grande potencial que um sistema de armazenamento distribudo, utilizando recursos ociosos, em dispositivos no dedicados a armazenamento, representa para as Operadoras de Telecomunicaes. Outro aspecto que refora essa possibilidade o fato dessas Operadoras j possurem toda a infra-estrutura de transmisso instalada, entre os prdios onde esses Callcenters operam e o ncleo de suas redes, conforme apresentado na Figura 11 (pgina 49). Dessa forma, basta apenas ampliar a capacidade desses sistemas para suportar o trfego gerado por esse servio, conforme ser detalhado no tpico a seguir.

5.2 Dimensionamento da Capacidade de armazenamento

Com a experimentao prtica realizada a partir de um prottipo do sistema de armazenamento distribudo proposto (Captulo 4) temos a base para o dimensionamento completo do sistema e a arquitetura final da soluo. Atravs do prottipo, inferiu-se que para cada link de 1 Gbps entre a Operao de Callcenter onde estaro os peers de armazenamento, e o core de rede da Operadora onde estaro conectados os peers de carga, temos uma banda lquida disponvel de 666 Mbps. Com isso, para dimensionarmos a capacidade de armazenamento, em bytes, que cada link desses pode cursar simultaneamente, basta multiplicar essa banda lquida (onde foi descontada a perda devido ao overhead de controle da aplicao) pelo tempo mdio terico de transferncia em uma aplicao P2PSS, conforme equao ( i ) abaixo: Ca (byte) = (Tl (bps) x Ts) / 8 Onde: Ca (byte) = Tl (bps) = Ts segundos.
2

(i)

Capacidade de armazenamento, em bytes; Taxa lquida do link de entroncamento, em bits por segundo; Tempo terico de transferncia em uma aplicao Cloud Storage, em

1 petabyte = 1024 gigabytes

62

Dandoush, Alouf e Nain, na pesquisa Simulation Analysis of download and recovery processes in P2P Storage Systems [36], introduziram um estudo detalhado do tempo de transferncia em uma aplicao P2PSS. Por apresentar caractersticas de controle idnticas ao Projeto USTO.RE, tais como a arquitetura centralizada e o tamanho dos fragmentos (aqui chamados de chunks), esse estudo ser usado como benchmark do tempo terico da transferncia de dados, nesse estudo de caso. A partir da implementao do processo de download e recovery no simulador NS-2 [37], os pesquisadores avaliaram o tempo de transferncia sob diversas condies: diferentes topologias de rede, heterogeneidade dos peers, diferentes tempos de propagao e processos de controle (centralizado e distribudo). A figura abaixo apresenta de forma resumida a arquitetura do simulador utilizado, onde foi utilizada a verso 2.33 do NS-2 e realizadas algumas modificaes nos arquivos node.cc, node.h, agent.cc, agent.h, tcp-full.cc.

Figura 19: Arquitetura do simulador usado como benchmark do tempo terico de transferncia (Autor: Dandoush [36])

Na Tabela 7, so apresentados os setups dos experimentos realizados. Dos sete experimentos, observa-se que o experimento 3 o mais aderente a Proposta do testbed utilizado no prottipo, visto que o mesmo simulou uma aplicao do tipo backup, com o fragmento de tamanho igual a 1024 KB, mesmo valor considerado no chunk do prottipo adotado nessa pesquisa.

63

Tabela 7: Setup do experimento usado como benchmark do tempo terico de transferncia

A partir dessa escolha, na Tabela 8, temos o resultado do tempo mdio de transferncia nesse experimento, onde se observa o tempo de 105,254 segundos, sendo esse o valor utilizado para o dimensionamento proposto na equao ( i ), resultando no seguinte: Ca (byte) = (666 Mbps x 105,254 s) / 8 Ca (byte) = 8 762,39 MB = 8,55 GB Logo, para cada uplink de 1 Gbps, observa-se uma capacidade mxima de armazenamento simultneo igual de 8,55 GB, considerando o overhead do sistema de controle descrito no Projeto USTO.RE e o tempo de transferncia proposto pelo benchmark utilizado. Considerando um fator de utilizao emprico de 5% ou seja, em mdia, 1 a cada 20 usurios ir armazenar ou recuperar os dados simultaneamente, tem-se uma capacidade final de armazenamento igual a 171 GB, para cada link de interligao de 1 Gbps.
Tabela 8: Sumrio dos resultados do simulador usado como benchmark

(i)

64

5.3

Arquitetura Final da Soluo

A partir dos resultados obtidos na seo anterior, podemos detalhar a arquitetura do servio Cloud Storage por uma Operadora, proposta na figura 6 (pgina 37), descrevendo as tecnologias utilizadas em cada subsistema, os padres de interligao entre eles e a capacidade final da soluo. Com isso, tem-se a descrio necessria para orientar os futuros Projetos que adotem a tecnologia proposta por essa pesquisa, cuja viabilidade econmica ser comprovada na seo seguinte. Partindo-se da premissa de utilizao da capacidade de transmisso existente, sobretudo o entroncamento ptico entre os prdios da Operao do Callcenter - onde esto as Posies de Atendimento (PAs) e do ncleo de rede da Operadora - recomenda-se a implantao de um novo n de multiplexao digital. importante ressaltar que na arquitetura proposta, as PAs funcionaro como peers de armazenamento e os hosts interligados ao ncleo de rede da Operadora (os clientes finais) sero os peers de carga. Como a arquitetura baseada no padro Gigabit Ethernet (IEEE 802.3ab) para interligao das LANs (Local Area Network), optou-se pela tecnologia SDH-NG (Synchronous Digital Hierarchy Next Generation), nesse novo n. Tal escolha se deve fundamentalmente pela flexibilidade que essa tecnologia oferece, suportando entre outros padres, o transporte de pacotes IP, encapsulados em quadros ethernet, com marcao de VLAN (IEEE 802.1q), no meio ptico existente, conforme Figura 20 abaixo.

Figura 20: Flexibilidade do padro SDH-NG (Fonte: Trend Communications)

65

A flexibilidade da tecnologia SDH-NG para o transporte de pacotes IP ocorre graas ao protocolo GFP (Generic Framing Protocol). Definido pela norma ITU-T G.7041, esse padro prov adaptao da taxa de dados e mapeamento dos mesmos na estrutura STM-n do padro SDH, que em seguida so multiplexados e transmitidos, conforme resume a Figura 21.

Figura 21: Funcionamento do protocolo GFP, definido pela norma ITU-T G.7041 (Fonte: Trend Communications)

Visando maximizar a utilizao do meio ptico, aumentando assim a capacidade de transmisso e, conseqentemente, de armazenamento da soluo, a tecnologia SDH-NG permite a concatenao de vrios quadros STM-1 (155 Mbps), formando uma estrutura STM-256, capaz de transportar, no mesmo meio ptico, uma taxa de 40 Gbps, conforme Figura 22.

Figura 22: Processo de concatenao, no SDH-NG (Fonte: Trend Communications)

Graas a esse recurso, que permitiu atingir a taxa de 40 Gbps no entroncamento entre os subsistemas de armazenamento e carga, consegue-se atingir uma capacidade de armazenamento

66

total de 6.840 GB (ou 6,84 TB), considerando a capacidade de 171 GB por link de 1 Gbps, conforme detalhado na seo 5.2, equao ( i ). Com isso, seguindo o modelo de referncia OSI, os padres que compe a arquitetura final da soluo proposta descrito na Figura 23, onde temos nas camadas superiores o protocolo HTTP na camada de aplicao, o padro XML para apresentao dos dados, conforme definido pelo padro JXTA, descrito na camada de sesso. As demais camadas descrevem o protocolo TCP na camada de transporte e os padres IP, Ethernet e SDH-NG, nas camadas de rede, sesso e fsica, respectivamente.

Figura 23: Padres que compe a soluo proposta

5.4 Estudo da viabilidade econmica da Soluo

Como contribuio final do estudo de caso proposto nessa pesquisa, temos a avaliao da viabilidade econmica da soluo. Para tal, ser estimado o investimento inicial para implementao da soluo, adotando-se os padres descritos na seo anterior e utilizando-se valores de mercado para ampliao da capacidade de transmisso nos equipamentos. Em seguida, partindo-se da comparao mdia dos valores praticados pelos principais produtos de armazenamento disponveis no mercado, ser inferida a receita mensal do produto, de acordo

67

com a capacidade de armazenamento calculada (6.840 GB). Por fim, sero utilizados os mtodos do Valor Presente Lquido (VPL), da Taxa Interna de Retorno (TIR) e do Payback, para comprovao da viabilidade econmico-financeira da soluo proposta. Considerando a utilizao da capacidade de transmisso j existente entre os subsistemas de armazenamento e carga (Contact Center e Operadora, respectivamente), o investimento inicial ( I0 ) necessrio consiste apenas na ampliao de multiplexadores e demultiplexadores SDH-NG existentes, com placa STM-256 (40 Gbps) no entroncamento e portas Gigabit Ethernet (padro 1000 BASE-T) adicionais para acesso. Adotando-se valores de mercado dos principais fornecedores dessa tecnologia, estima-se o valor de R$ 70.000,00 para essa adequao. O prximo passo inferir a receita mensal que a capacidade de 6.840 GB ir gerar para a Operadora. Na Tabela 9, extrada do site www.tecmundo.com.br [47], temos a comparao de preo dos principais servios de armazenamento existentes no mercado. Nessa pesquisa, ser considerada a mdia dos valores como valor mensal a ser pago, ou seja, R$ 0,35 por GB armazenado.
Tabela 9: Comparativo de preo entre os principais servios de armazenamento existentes Servio Google Drive Dropbox Ubuntu One Preo por GB (R$) R$ 0,18 R$ 0,36 R$ 0,25 iCloud R$ 0,30 Box SugarSync Mdia R$ 0,72 R$ 0,30 R$ 0,35

Seguindo essa premissa, encontra-se uma receita mensal de R$ 2.394,00 (R$ 0,35 x 6.840 GB). Na Tabela 10, temos o fluxo de caixa anualizado que essa receita ir gerar. A partir do ano 2, foi considerada a correo monetria de 6% ao ano, considerando a taxa oficial de inflao registrada nos anos anteriores.
Tabela 10: Fluxo de caixa anual gerado pelo servio de armazenamento proposto. Ano 1 2 3 4 5 Valor 28.728,40 30.451,64 32.278,78 34.215,51 36.268,44

R$ R$ R$ R$ R$

68

Por fim, para avaliar a viabilidade financeira do Projeto proposto, sero utilizados mtodos do Valor Presente Lquido, da Taxa Interna de Retorno e do Payback. a) Valor Presente Lquido (VPL): Tambm conhecido como Valor Atual Lquido (VAL) ou mtodo do valor atual, a frmula matemtico-financeira capaz de determinar o valor presente de pagamentos futuros descontados a uma taxa de juros apropriada tambm chamada de Taxa Mnima de Atratividade (TMA), subtrado do custo do investimento inicial. Em termos prticos, um dado Projeto considerado vivel, caso apresente um VPL > 0, em um perodo pr-determinado, normalmente 5 anos, a uma Taxa Mnima de Atratividade superior s taxas praticadas pelo mercado financeiro. O mesmo pode ser expresso pela frmula abaixo: VPL = Onde: FCt i t I0 = = = = Fluxo de Caixa no perodo t ; Taxa Mdia de Atratividade; Quantidade de tempo, em anos; Investimento inicial no Projeto.

Aplicando esse mtodo ao fluxo de caixa descrito pela Tabela 10, chega-se a um VPL igual a R$ 36.825,19, considerando um ciclo de vida de 5 anos, e uma taxa de retorno de 15% a.a. Ou seja, o Projeto financeiramente vivel e apresenta uma taxa de retorno superior ao praticado no mercado de telecomunicaes. b) Taxa Interna de Retorno (TIR): Conceito proposto pelo economista John Maynard Keynes (1883 - 1946), esse mtodo de anlise de investimento prope uma taxa de desconto hipottica que, quando aplicada a um fluxo de caixa, faz com que os valores das despesas, trazidos ao valor presente, seja igual aos valores dos retornos dos investimentos, tambm trazidos ao valor presente. Em outras palavras, uma taxa complementar a anlise do VPL, que expressa a taxa de retorno de um determinado Projeto.

69

Aplicando esse mtodo ao Projeto em anlise, obtm-se um TIR igual a 35%, no perodo de 5 anos, que ratifica a viabilidade economico-financeira do Projeto, uma vez que essa taxa superior ao padro encontrado no mercado de telecomunicaes. c) Payback o tempo decorrido entre o investimento inicial e o momento no qual o lucro lquido acumulado se iguala ao valor desse investimento. Trata-se de uma tcnica de anlise de

investimento alternativas ao mtodo do Valor presente lquido (VPL), levando em conta apenas o prazo de retorno do investimento, sendo calculada pela diviso do investimento inicial pelas entradas mdias de caixa. No Projeto em questo, observa-se um Payback igual a 2,16 anos, conforme abaixo:

Payback = I0 / FCt = R$ 70.000,00 / R$ 32.388,48 = 2,16

5.5 Modelo matemtico para avaliao de viabilidade da soluo

Alm do setor de telecomunicaes, utilizado como referncia no estudo de caso dessa pesquisa, para avaliao de viabilidade do servio cloud storage proposto, outros segmentos econmicos tambm podem se valer da soluo proposta para gerao de receita a partir de recursos a partir de recursos ociosos em seus parques computacionais. Empresas como concessionrias pblicas e privadas de gua e luz, operadoras de cartes de crdito e grandes redes varejistas so alguns exemplos onde tal servio pode ser vivel. De modo a subsidiar a deciso em adotar a proposta apresentada nessa pesquisa, ser apresentado um modelo matemtico, a partir da aplicao da equao da Capacidade de armazenamento (Ca), descrita pela equao ( i ) no tpico 5.2, na equao do Valor Presente Lquido (VPL), sendo observado o valor resultante. Caso a expresso resultante, apresente um VPL > 0, a adoo do projeto ser considerado vivel, enquanto para um VPL considerado invivel. Sabendo que o VPL dado pela expresso: 0 o mesmo ser

70

VPL =

(1) R /1 t < n}, e

E que FCt denota o Fluxo de Caixa em funo do tempo t, para {t pode ser substitudo pela expresso: FCt = Ca (byte) / Fu Onde: (2)

Fu igual ao Fator de utilizao da aplicao, ou seja, a relao de acessos simultneos em funo do nmero total de usurios do sistema; Ca (byte) igual a Capacidade de Armazenamento em funo da largura de banda do uplink de conexo rede pblica e pode ser descrito por: Ca (byte) = (Tl (bps) x Ts) / 8 Sendo: Ts igual ao tempo mdio de transferncia do servio Cloud Storage, em segundos; Tl (bps) igual taxa lquida do link de entroncamento, em bits por segundo, ou seja: Tl (bps) = BW / O (4) (3)

Onde: BW = Taxa bruta de transmisso do link de entroncamento, em bps; O = Overhead de controle do framework Cloud Storage usado. Aplicando a expresso ( 4 ) em ( 3 ) e a expresso resultante na expresso ( 2 ) temos: FCt = (BW x T(s) x Fu) / ( 8 x O ) (5)

Por fim, aplicando a expresso ( 5 ) em ( 1 ) temos o modelo matemtico para avaliao de viabilidade da soluo, em funo das caractersticas de trfego do servio e do retorno econmico-financeiro da soluo: VPL = 0, ,

71

5.6 Sumrio do captulo

Nesse captulo, foi contextualizada a necessidade do setor brasileiro de telecomunicaes em oferecer servios de valor agregado, como o servio de armazenamento em nuvem. Para tal, foi apresentada a possibilidade de utilizao de recursos de armazenamento ociosos e distribudos em Posies de Atendimento dos contact centers de empresas subsidirias desses players, o que atualmente corresponde a um parque de 232 mil estaes. Nessa arquitetura, imprescindvel avaliar a capacidade de armazenamento que pode ser ofertada. Para tal, foi apresentado estudo a partir das mtricas trfego observado em um prottipo, e de tempo de transferncia introduzidas por um simulador, resultando na capacidade de armazenamento de 6.840 GB, usando uma capacidade de transmisso igual a 40 Gbps, utilizando-se a tecnologia SDH-NG sob o meio ptico existente. Aps a descrio final da arquitetura avaliada, seguindo o modelo de referncia OSI, foi comprovada a viabilidade econmico-financeira do Projeto, atravs dos mtodos do Valor Presente Lquido, Taxa Interna de Retorno e Payback. Por fim, a partir do estudo de caso baseado no mercado brasileiro de telecomunicaes, foi descrito um modelo matemtico para avaliao de viabilidade da soluo. Esse modelo visa subsidiar a deciso de lanamento do servio cloud storage utilizando recursos ociosos por quaisquer empresas, de todos os segmentos econmicos, utilizando quaisquer plataformas de gerenciamento e controle, desde que sejam conhecidas as variveis de trfego da soluo e o investimento inicial necessrio.

72

6 CONSIDERAES FINAIS

A utilizao de recursos de armazenamento ocioso, em desktops utilizados como Posies de Atendimento de um Callcenter, mostrou-se uma soluo vivel, escalvel e de baixo investimento inicial. Com isso foi proposta uma nova alternativa s Operadoras de Telecomunicaes que detm a operao de tais contact centers, ou para quais empresas que detenham recursos de armazenamento ocioso em seus desktops, para gerao de valor atravs da oferta do servio de armazenamento em nuvem. Tal proposta consiste em uma alternativa para o ingresso no mercado de computao em nuvem. Mercado esse que se encontra em plena expanso, devendo atingir a casa de 241 bilhes de dlares em 2020. Analisando-se isoladamente o mercado brasileiro de telecomunicaes, o ingresso nesse mercado representa uma grande oportunidade, tendo em vista a acirrada competio e o declnio de receita nos servios tradicionais, como a telefonia fixa. No contexto atual, a expanso de receita para as operadoras de telecomunicaes ocorrer na expanso do market share de servios com baixa penetrao, como a TV por assinatura, ou na oferta de novos servios de valor agregado, como o armazenamento em nuvem. Esse fato fica evidenciado nos anncios recentes de servios Cloud Storage, por quatro dos maiores conglomerados de telecomunicaes. Por fim, essa pesquisa prope uma arquitetura inovadora, baseada em estudos recentes sobre sistemas de armazenamento distribudo que utilizam recursos no dedicados. Para validar tal proposta, foi descrito um estudo de caso - baseando no cenrio de uma operadora de telecomunicaes - e apresentado um modelo matemtico para avaliao de viabilidade da soluo proposta. Esse modelo, que considera variveis de trfego e o investimento inicial necessrio para oferta do servio Cloud Storage, pode ser utilizado para o desenvolvimento de pesquisas futuras e por agentes decisrios das empresas que pretendam entrar no mercado de armazenamento como servio, utilizando recursos de armazenamento ociosos.

73

6.1 Trabalhos relacionados

Conforme exposto nesse trabalho, vrias pesquisas vm se destacando no tocante aos sistemas de armazenamento distribudos, quer do ponto de vista de controle, como os Projetos GFS [24], Campus Cloud [25] e USTO.RE [26], utilizado como testbed dos experimentos prticos aqui apresentados, quer do ponto de vista do uso de recursos no dedicados, conforme proposto pelos pesquisadores Andrzejak, Kondo e Anderson [2], ou ainda na anlise e simulao de trfego, conforme proposto pelos pesquisadores Drago, Mellia e Munaf [32] e Alouf, Dandoush e Nain [36] [38].

6.2 Resumo das contribuies

A seguir apresentado um resumo das principais contribuies deste trabalho: Definio das variveis a serem consideradas para o dimensionamento da capacidade de armazenamento em funo das caractersticas de trfego em sistema de armazenamento distribudo usando recursos ociosos; Introduo de micro-segmentao atravs de VLANs em um sistema de armazenamento P2P, garantindo a transparncia dessa aplicao em relao s pr-existentes na rede local; Descrio de uma arquitetura para explorao do servio Cloud Storage utilizando recursos de armazenamento ociosos por uma Operadora de Telecomunicaes; Apresentao de um modelo matemtico para avaliao de viabilidade econmicofinanceira da soluo de armazenamento distribudo proposta.

6.3 Trabalhos futuros

Dentre as caractersticas da arquitetura proposta que precisam ser evoludas, do ponto de vista do sistema e da pesquisa, temos: A necessidade de evoluo do prottipo no que se refere reduo do overhead de controle, maximizando a capacidade de armazenamento e a rentabilizao do Projeto;

74

Elaborao e implementao de mecanismo de adaptao da fragmentao em funo do tamanho do arquivo a ser armazenado; Avaliao do impacto da replicao, no consumo de banda e de processamento da LAN de armazenamento, tornando o sistema o mais transparente possvel a esse ambiente; Criao de mecanismos de priorizao de trfego entre usurios, de modo a permitir a diferenciao de preo no servio ofertado.

75

7 REFERNCIAS

[1] [2]

http://computerworld.uol.com.br/tecnologia/2008/03/13, acessado em 11/10/2012. Andrzejak, A., Kondo, D. e Anderson, D.P. Exploiting non-dedicated resources for cloud computing. In Network Operations and Management Symposium (NOMS), 2010 IEEE.

[3]

M. Oliveira, W. Cirne, F. Brasileiro e D. Guerrero. On the impact of the data redundancy strategy on the recoverability of friend-to-friend backup systems. In Proceedings of the 26th Brazilian Simposium on Computer Networks and Distributed Systems. Rio de Janeiro, Brazil, May 2008.

[4]

N. Carr. The big switch: rewiring the world, from Edison to Google. Editora: W.W. Norton & Co., New York, 2008.

[5] [6] [7]

Amazon Inc., Elastic compute cloud, 2008. http://aws.amazon.com/ec2. Amazon Inc., Simple Storage Service, 2009. http://www.amazon.com/s3/. A. Chervenak, I. Foster, C. Kesselman, C. Salisbury and S. Tuecke,The data grid: Towards architecture for the distributed management and analysis of large scientific datasets, Journal of Network and Computer Applications, vol. 23, No. 3, 2001, pp.187200,

[8]

Schollmeier, Rudiger. A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. In IEEE Internet Computing, 2002.

[9]

Balakrishnan, H., Kaashoek, M.F., Karger, D., Morris, R., and Stoica, I. Looking up data in P2P systems. In Communications of the ACM 46, 2003.

[10] Barr, K., Batten, C., Saraf, A. and Trepetin, S. pStore: A Secure Distributed Backup System. Massachusetts Institute of Technology, USA, 2001.

76

[11] Cox, L., Murray, C. and Noble, B. Pastiche: making backup cheap and easy. In ACM SIGOPS Operating Systems Review - OSDI '02: Proceedings of the 5th symposium on Operating systems design and implementation. Volume 36 Issue SI, Pages 285-298. 2002, New York, NY, USA [12] OceanStore, http://oceanstore.cs.berkeley.edu/info/overview. Acessado em 20/02/2012. [13] Landers, M., Zhang, H., and Tan, K. PeerStore: better performance by relaxing in peer-topeer backup. In Proceedings of the Fourth International Conference on Peer-to-Peer Computing, 2004. [14] BitTorrent. Site Ofical. http://www.bittorrent.com/ . Acessado em Fevereiro de 2012. [15] Rowstron, A. and Druschel, P. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. Lecture Notes in Computer Science, November 2001. [16] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and Balakrishnan, H. Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, 2001. [17] Ratnasamy, S., Francis, P., Handley, M., Karp, R., Shenker, S. A addressable network. In Proceedings of ACM SIGCOMM, 2001. [18] Zhao, B., Huang, L., Stribling, J., Rhea, S., Joseph, A. and Kubiatowicz, J. Tapestry: A Resilient Global-Scale Overlay for Service Deployment. In IEEE Journal on selected areas in Communications, 2004. [19] Aidouni, F., Latapy, M. and Magnien, C. "Ten weeks in the life of an eDonkey server," In Proceedings of HotP2P09, 2009. [20] The JXTA project. http://www.jxta.org/. [21] Microsystems, S. (2007). JXTA Java Standard Edition v2.5:Programmers Guide. Sun Microsystems. calable content-

77

[22] Brookshier, D., Govoni, D., Krishnan, N., and Soto, J. C. (2002). JXTA: Java P2P Programming. Sams Publishing, United States of America ,San Francisco, California. [23] The java implementation of the jxta protocols. disponvel em: <http://jxse.kenai.com>. Acessado em 07/06/2012. [24] G. Sanjay, G. Howard and S. Leung, The Google file system, Proc. the 19th ACM Symposium on Operating Systems Principles (SOSP 03), 2003, pp. 29-43. [25] Xu, P., Huang, X., Wu, Y., Liu, L., and Zheng, W. (2009b). Campus cloud for data storage and sharing. In Grid and Cooperative Computing, 2009. GCC 09. Eighth International Conference on, pages 244 249. [26] M. P. Duarte. Um Algoritmo de Disponibilidade em Sistemas de Backup Distribudo Seguro Usando a Plataforma Peer-to-peer, MSc Thesis, Universidade Federal de Pernambuco, Brazil, 2010. [27] Webber, J., Parastatidis, S., Robinson, I. REST in Practice: Hypermedia and Systems Architecture, OReilly Media, 2010. [28] Nocentini, C., Crescenzi, P., Lanzi, L. Performance evaluation of a chord-based jxta implementation. In Proceedings of the 2009 First International Conference on Advances in P2P Systems, pages 7-12. IEEE Computer Society, 2009. [29] Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., Gruber, R. E. Bigtable: a distributed storage system for structured data. In Proceedings of the 7th USENIX Symposium on Opeating Systems Design and Implementation, Volume 7, pages 15-15. USENIX Association, 2006. [30] Basili, V., Caldiera, G., Rombach, H. The Goal Question Metric Approach. [31] Chiruvolu, G. Issues and approaches on extending Ethernet beyond LANs. IEEE Communications Magazine, Vol. 42, pages 80-86, 2004. [32] Drago, I., Mellia, M. and Munaf, M. (2012). Inside Dropbox: Understanding Personal Cloud Storage Services. IMC12, November 1416, 2012, Boston, Massachusetts, USA.

78

[33] Dropbox, http://www.dropbox.com. Acessado em 20/02/2012. [34] Zimmermman, H. OSI Reference Model--The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, pages 425-432, 1980. [35] www.callcenter.inf.br, acessado em 11/10/2012. [36] Alouf, S., Dandoush, A., Nain, P. Simulation analysis of download and recovery in P2P storage systems. In Teletraffic Congress, 2009. ITC 21 2009. 21st International pp. 1-8. [37] Fall, K., Varadhan, K., The NS manual, the VINT project, UC Berkley, LBL, USC/ISI and Xerox PARC, http://www.isi.edu/nsnam/ns/ns-documentation.html, November 2008. [38] Alouf, S., Dandoush, A., Nain, P. Performance analysis of peer-to-peer storage systems. In Proceedings of 20th ITC, ser. Lecture Notes in Computer Science, vol 4516, Ottawa, Canada, June 2007 pp. 642-653.