Pós-Graduação em Ciência da Computação

Estudo da viabilidade de um serviço de Cloud Storage, utilizando recursos ociosos, por uma Operadora de Telecomunicações.

Por

Hilson Gomes Vilar de Andrade
Dissertação de Mestrado

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

RECIFE, JANEIRO/2013

2

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Hilson Gomes Vilar de Andrade

Estudo da viabilidade de um serviço de Cloud Storage, utilizando recursos ociosos, por uma Operadora de Telecomunicações.

ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.

ORIENTADOR: Prof. Dr. VINÍCIUS CARDOSO

GARCIA

RECIFE, JANEIRO/2013

3

“A imaginação é mais importante que o conhecimento. O conhecimento é limitado. A imaginação envolve o mundo.” Albert Einstein

4

Agradecimentos

Primeiramente, agradeço a Deus pelas bênçãos que vem derramando sobre minha vida, desde o meu nascimento. Nele, busquei ânimo para perseverar na conclusão desse projeto, superando minhas limitações e fraquezas. Aos meus pais (Neném e Dida) exemplos de vida e superação, que inteligentemente guiaram-me no caminho da ética e do trabalho, mostrando-me que não existe sucesso sem esforço. Exemplo esse que também guiou a minha irmã Danielle, outro grande exemplo de vida para mim e que tanto me ajudou com suas orações. À minha grande companheira Angélica, por ser o meu recanto de paz e apoio incondicional, nos momentos difíceis. Sem o seu apoio certamente eu teria desistido pelo caminho. Agradeço a minha filhinha Júlia, que em tantos sábados e domingos agarrou-se à minha perna para não ser privada de minha presença, algo bastante comum nesses seus quatro anos de vida. Sei que no futuro ela entenderá e ficará orgulhosa dessa jornada. Ao meu orientador, Vinícius Cardoso, exemplo de competência e serenidade nos momentos mais complexos da pesquisa. Agradeço muito pelo voto de confiança e oportunidade que me foi dada. Aos meus fiéis companheiros de turma: André, Wanderson e Anderson. O exemplo de superação e generosidade desses guerreiros foi o combustível que me abasteceu nos momentos de desânimo, no decorrer dessa caminhada. Ao generoso time de desenvolvedores da Ikewai - especialmente ao Anderson Fonseca e Tiago Jamir, que tanto contribuíram para a realização dos experimentos utilizados nessa pesquisa. E por fim, agradeço aos meus colegas da Oi, em especial ao Marcos Alexandre, Gustavo Maciel e Roberto Zurlo, pelo apoio logístico e incentivo, algo imprescindível para conclusão desse sonho.

5

Resumo

Desde a privatização do sistema Telebrás, em 1998, o mercado de telecomunicações brasileiro vem sofrendo profundas transformações. Dentre essas mudanças, as mais marcantes são a convergência na oferta de serviços e a acirrada concorrência entre os principais players. Nesse cenário, a oferta de serviços como valor agregado é fundamental para o crescimento e a sobrevivência das empresas. Um bom exemplo é a oferta do serviço de armazenamento em nuvem, cujo mercado global já alcança a cifra de 40 bilhões de dólares. Essa dissertação estuda a oferta do serviço de armazenamento em nuvem, por uma operadora de telecomunicações, utilizando recursos computacionais ociosos, através da formação de um sistema de armazenamento peer-to-peer. Para tal, a execução da pesquisa estudou três fases necessárias para o lançamento comercial do serviço: a arquitetura de controle, onde foi utilizado o Projeto USTO.RE como testbed; um protótipo para análise do tráfego nos links de interligação em função da capacidade de armazenamento, e por fim a viabilidade econômica do serviço, através de um estudo de caso baseado nas métricas obtidas no protótipo. Como contribuição prática, o estudo apresentou uma solução escalável e com baixo investimento, permitindo o lançamento de serviço de armazenamento como valor agregado, por Operadoras de Telecomunicações.

Palavras Chaves: Sistemas P2P, Cloud computing, Telecomunicações, Armazenamento, Cloud Storage, Storage as a Service.

6

ABSTRACT

Since the event of privatization of the Telebrás 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 Master’s 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.

7

Sumário

1

INTRODUÇÃO ..................................................................................................................... 11 1.1 1.2 1.2.1 1.2.2 1.3 Contextualização ......................................................................................................... 11 Objetivos ..................................................................................................................... 13 Objetivos Gerais ...................................................................................................... 13 Objetivos Específicos .............................................................................................. 14 Organização da Dissertação ........................................................................................ 14

2

SISTEMAS DE ARMAZENAMENTO DISTRIBUÍDO ..................................................... 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 híbridas ............................................................................................... 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 Sumário do Capítulo.................................................................................................... 37

3

ARQUITETURA USTO.RE ................................................................................................. 38 3.1 3.2 3.2.1 3.2.2 Descrição do sistema ................................................................................................... 39 Descrição dos Componentes e serviços ...................................................................... 40 Super peers .............................................................................................................. 40 Servidores ................................................................................................................ 41

8

3.2.3 3.2.4 3.3 4

Proxies ..................................................................................................................... 43 Simple peers ............................................................................................................. 43 Sumário do capítulo .................................................................................................... 47

ANÁLISE DE TRÁFEGO DO PROTÓTIPO ...................................................................... 48 4.1 4.2 4.2.1 4.2.2 4.3 Definição dos objetivos e métricas.............................................................................. 48 Resultados Obtidos...................................................................................................... 51 Cenário I .................................................................................................................. 51 Cenário II ................................................................................................................. 54 Sumário do capítulo .................................................................................................... 57

5

ESTUDO DE CASO ............................................................................................................. 59 5.1 5.2 5.3 5.4 5.5 5.6 Serviço Cloud-Computing nas Operadoras de Telecomunicações ............................. 59 Dimensionamento da Capacidade de armazenamento ............................................... 61 Arquitetura Final da Solução....................................................................................... 64 Estudo da viabilidade econômica da Solução ............................................................. 66 Modelo matemático para avaliação de viabilidade da solução ................................... 69 Sumário do capítulo .................................................................................................... 71

6

CONSIDERAÇÕES FINAIS ................................................................................................ 72 6.1 6.2 6.3 Trabalhos relacionados ................................................................................................ 73 Resumo das contribuições ........................................................................................... 73 Trabalhos futuros......................................................................................................... 73

7

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

9

Lista de figuras

Figura 1 Evolução do mercado global de cloud computing ............................................................................... 16 Figura 2 Taxonomia de sistemas P2P .............................................................................................................. 18 Figura 3 Exemplo de requisição usando a técnica flood ................................................................................... 19 Figura 4 Arquitetura JXTA em três camadas .................................................................................................... 22 Figura 5 Pipes unicast e Pipes de propagação .................................................................................................. 29 Figura 6 Conexão Pipes .................................................................................................................................. 31 Figura 7 Arquitetura GFS ................................................................................................................................ 34 Figura 8 Arquitetura Campus Cloud ................................................................................................................ 36 Figura 9 Visão 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 serviço cloud-computing por uma Operadora ................................. 49 Figura 12 Estrutura hierárquica do modelo GQM da análise do cenário I .......................................................... 50 Figura 13 Estrutura hierárquica do modelo GQM da análise do cenário II ......................................................... 51 Figura 14 Tráfego médio de carga observado nos experimentos do cenário I .................................................... 53 Figura 15 Topologia de simulação da arquitetura proposta .............................................................................. 55 Figura 16 a) Script de configuração do Switch0 ................................................................................................ 55 Figura 16 b) Script de configuração do Router0 ............................................................................................... 55 Figura 17 Roteamento centralizado entre as VLANs ........................................................................................ 56 Figura 18 Consolidação do mercado brasileiro de Telecomunicações ............................................................... 59 Figura 19 Arquitetura do simulador usado como benchmark do tempo teórico de transferência ....................... 62 Figura 20 Flexibilidade do padrão SDH-NG ...................................................................................................... 64 Figura 21 Funcionamento do protocolo GFP, definido pela norma ITU-T G.7041 ............................................... 65 Figura 22 Processo de concatenação, no SDH-NG ............................................................................................ 65 Figura 23 Padrões que compõem a solução proposta ...................................................................................... 66

10

Lista de tabelas

Tabela 1 Conceito dos termos utilizados na arquitetura .................................................................................. 38 Tabela 2 Modelo GQM da Análise do Cenário I ............................................................................................... 49 Tabela 3 Modelo GQM da Análise do Cenário II .............................................................................................. 50 Tabela 4 Tráfego médio de carga, variando-se os parâmetros de chunk e fila ................................................... 53 Tabela 5 Overhead total de controle, da solução proposta .............................................................................. 56 Tabela 6 Produtos cloud-computing ofertados por Operadoras de Telecomunicações ...................................... 60 Tabela 7 Setup do experimento usado como benchmark do tempo teórico de transferência ............................. 63 Tabela 8 Sumário dos resultados do simulador usado como benchmark........................................................... 63 Tabela 9 Comparativo de preço entre os principais serviços de armazenamento existentes .............................. 67 Tabela 10 Fluxo de caixa anual gerado pelo serviço de armazenamento proposto ............................................ 67

11

1 INTRODUÇÃO

1.1 Contextualização
Desde os tempos mais remotos que a preocupação em armazenar informações acompanha os setores produtivos da humanidade. Seja com o advento do papiro, precursor do papel (2500 a.C.), passando pelos sistemas de armazenamento eletrônico, a partir da invenção do transistor na década de 1940, até os sistemas de armazenamento em nuvens atuais, essa necessidade é crescente. Potencializado pelo desenvolvimento tecnológico, que reduziu os custos dos sistemas informatizados, o volume de dados gerados pelas empresas alcançou patamares além da capacidade de armazenamento disponível. 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 disponível em discos rígidos, fitas, CDs, DVDs e memórias, totalizavam 264 hexabytes1. Diante dessa necessidade, a terceirização do serviço de armazenamento, em detrimento a expansão dos datacenters próprios, vem ganhando força no mercado de tecnologia da informação, serviço esse conhecido como armazenamento em nuvem (cloud storage), em virtude da sua natureza distribuída. Empresas como Dropobox, Rackspace, Amazon S3 e Google Drive são exemplos de provedores desse tipo de serviço, cujo potencial inexplorado, sobretudo no mercado corporativo, ainda é muito grande. De olho nesse novo mercado estão as operadoras de telecomunicações, que já detém os serviços de comunicação de voz e dados dessas empresas e passaram a ofertar serviços 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 implantação de novos datacenters ou com a expansão dos existentes, o que demanda elevados investimentos em infra-estrutura e aquisição de hardware, diminuindo assim a rentabilidade do serviço. Uma alternativa para aumentar essa rentabilidade, considerando a topologia de rede dessas empresas, seria através da

1

hexabytes = 1018 bytes

12

utilização dos recursos de armazenamento ociosos e não dedicados, somando-se a capacidade dos datacenters existentes, conforme proposto por Andrzejak, Kondo e Anderson [2]. A existência de recursos de armazenamento ociosos, nas redes locais das grandes operadoras de telecomunicações, fica evidente quando se analisa o espaço em disco nos desktops utilizados como posições de atendimento, nos grandes callcenters operados por essas empresas. Devido à padronização das configurações de hardware praticada pelo mercado, esses desktops são adquiridos com uma capacidade de armazenamento superior a demandada pelos sistemas CRM (Costumer Relationship Management) instalada nas mesmas, dando margem a uma freqüente subutilização. Para viabilizar tecnicamente essa alternativa, diversos trabalhos acadêmicos descrevem a utilização do paradigma P2P (peer-to-peer) para criação de federação de dados e composição 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 espaço livre de outros peers da rede. Um dos principais desafios dos sistemas de armazenamento P2P consiste em construir um sistema eficiente e confiável, a partir de um conjunto de componentes não-confiáveis e sujeitos a instabilidades diversas [3]. Por esse motivo, boa parte das pesquisas recentes que abordam a temática de armazenamento em nuvem utilizando sistemas distribuídos, trata dos aspectos de disponibilidade e desempenho. Com isso, questões referentes a essas aspectos foram aprimoradas, permitindo o avanço 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 avaliação de viabilidade de um sistema cloud storage, baseado em medições de tráfego obtidas em um protótipo e considerando variáveis econômico-financeiras, além de inovadora, contribui para subsidiar a adoção de tal solução por parte da cadeia decisória das empresas. Tanto nas operadoras de telecomunicações, usadas como referência no estudo de caso proposto, quanto em outras empresas que estejam interessadas em oferecer o serviço de armazenamento em nuvem, a partir dos recursos ociosos nas suas redes locais, gerando valor para o segmento econômico onde estão inseridas.

13

1.2 Objetivos

O objeto de estudo desse trabalho consiste em elaborar uma metodologia capaz de avaliar a viabilidade econômico-financeira de um serviço de armazenamento em nuvem, que opte pelo uso de recursos ociosos e não-dedicados ao armazenamento, no contexto da arquitetura de rede local de uma operadora de telecomunicações. Para tal, será investigado o estado da arte dos frameworks de armazenamento em nuvem baseado em P2P, desenvolvido um protótipo e analisado suas métricas através de medições de tráfego reais. Por fim, será descrita uma metodologia de avaliação econômico-financeira da solução, seguida de um estudo de caso prático, baseado na expansão da arquitetura adotada no protótipo, validando a adoção 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 lançamento de serviços de valor agregado; Analisar a viabilidade econômico-financeira desse sistema, incluindo o levantamento do investimento inicial e a taxa de retorno em função da capacidade de armazenamento ofertada; • • Estudar quais os melhores padrões para essa arquitetura, incluindo as camadas de controle lógico e físico; Validar a solução proposta, através de um estudo de caso baseado no mercado brasileiro de telecomunicações.

14

1.2.2 Objetivos Específicos

Os objetivos específicos do projeto de pesquisa aqui proposto são: • Construir um protótipo da arquitetura proposta, no qual poderão ser realizados experimentos onde serão obtidas as métricas necessárias para avaliação da viabilidade do serviço cloud storage; • • Definir os objetivos e métricas que irão orientar a interpretação dos resultados obtidos nos experimentos realizados no protótipo; Propor um modelo de avaliação de viabilidade que considere variáveis econômicas e a capacidade de armazenamento do serviço cloud storage, utilizando a arquitetura apresentada; • Relacionar os valores obtidos aos aspectos da utilização comercial do serviço, por parte de uma operadora de telecomunicações, através de um estudo de caso.

1.3 Organização da Dissertação
O texto desta dissertação está dividido em seis capítulos, incluindo esta introdução, os demais abordam o seguinte conteúdo: •

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

O capítulo 3: Apresenta o Projeto USTO.RE, usado como testbed no desenvolvimento da pesquisa, estudando suas características intrínsecas, mecanismos de controle e principais métricas para a avaliação da viabilidade do serviço de armazenamento em nuvem;

15

O capítulo 4: Apresenta um protótipo de simulação, descrevendo os parâmetros simulados e análise dos resultados obtidos, de modo a permitir o dimensionamento da capacidade de armazenamento sob condições reais de operação, garantindo a melhor experiência do ponto de vista do usuário e da rede;

O capítulo 5: É proposto um modelo de avaliação de viabilidade da exploração do serviço, considerando aspectos econômicos e técnicos. Em seguida, visando à validação do modelo, é apresentado um estudo de caso onde o serviço cloud storage, utilizando recursos computacionais ociosos, é ofertado como um serviço de valor agregado no mercado brasileiro de telecomunicações, de modo a comprovar a viabilidade econômicofinanceira da solução. Por fim, é apresentado um modelo matemático que relaciona as características de tráfego e do retorno econômico-financeiro da solução.

O capítulo 6: Mostra as conclusões sobre esta pesquisa, principais contribuições, trabalhos relacionados, trabalhos futuros e direcionamentos a cerca da pesquisa.

16

2 SISTEMAS DE ARMAZENAMENTO DISTRIBUÍDO
Nicholas Carr, em seu livro The big switch: rewiring the world, from Edison to Google [4], mostra de forma clara e objetiva o quão subutilizado encontram-se os recursos computacionais nas grandes corporações, colocando em cheque a racionalidade das elevadas quantias investidas nos últimos anos para aquisição e manutenção de infra-estrutura própria para o processamento e armazenamento de dados. Ele sugere ser inevitável que tais serviços sejam oferecidos como serviço público, tal como a eletricidade, o gás ou a telefonia. Essa reflexão sintetiza o atual crescimento do mercado de computação em nuvem como serviço público, constituindo-se na plataforma básica para a oferta de serviços de processamento e armazenamento. De acordo com Dignan [9], o mercado global de computação em nuvem crescerá dos atuais 40,7 bilhões de dólares para 241 bilhões em 2020, com destaque para oferta da modalidade BPaaS (Businees-Process-as-a-Service), que inclui o gerenciamento dos principais serviços de TIC (SaaS – Software-as-a-Service; PaaS – Platform-as-a-Service e IaaS – Infraestructure-as-aService), conforme abaixo:

Figura 1: Evolução do mercado global de cloud-computing (Autor: Dignan [9])

17

O primeiro grande projeto de computação em nuvem como serviço público se deu com o lançamento das plataformas EC2 (Elastic Computer Cloud) e S3 (Simple Storage Service), pela Amazon [5][6]. Em essência, essas plataformas baseiam-se na alocação de recursos computacionais distribuídos, virtualmente alocados para um determinado usuário a partir de suas necessidades de processamento ou de armazenamento, de modo transparente e sem restrições. 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 negócio, as empresas trocam o CAPEX (Capital Expenditure) necessário para aquisição de hardware e o OPEX (Operational Expenditure) necessário para a manutenção e atualização tecnológica, por um custo variável em função da demanda necessária. Tal modelo só tornou-se possível graças ao avanço nas tecnologias de acesso banda larga, que elevaram as taxas de transmissão necessárias para o bom funcionamento da arquitetura descentralizada e em nuvem. Outra possibilidade para oferecer infra-estrutura computacional como serviço (IaaS), tal como o serviço de armazenamento, alvo principal dessa pesquisa, é através do estabelecimento de grids computacionais, utilizando recursos distribuídos e não-dedicados. Inicialmente motivada escassez de recursos computacionais para a análise de grande volume de dados decorrentes de pesquisas científicas [7], esses data grids também podem ser utilizados para o desenvolvimento de uma plataforma para a oferta de serviço de armazenamento distribuído. Nesse contexto, o modelo P2P (Peer-to-peer) aparece como candidato natural para essa implementação, dada a sua natureza descentralizada, escalável e auto-organizável, sobretudo para sistemas que se proponham a utilizar recursos ociosos e que já se encontram em produção, alvo principal dessa dissertação. Dessa forma, visando garantir o embasamento teórico necessário, os tópicos seguintes apresentam uma breve revisão das principais arquiteturas P2P, a plataforma JXTA – utilizada para prover a comunicação entre os peers - e alguns frameworks que se baseiam nesse paradigma para construção de um data grid de armazenamento, também chamado de federação de dados, de modo a suportar o serviço cloud storage proposto nessa pesquisa.

18

2.1 Principais arquiteturas P2P
Os grandes responsáveis pelo impulso e popularização dos sistemas distribuídos P2P, foram o Napster, Gnutella e o KaZaA. Além de protagonizar inúmeras questões judiciais quanto a direitos autorais e pirataria, foi através 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 mudanças. Conforme se pode observar a Figura 2 a seguir a caracterização de sistemas P2P seguindo a árvore de classificação dos sistemas computacionais.

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

A ilustração mostra que os sistemas tendem a sofrer um processo de descentralização contínuo, onde o primeiro grande avanço se deu com o modelo cliente-servidor. Este consiste em uma máquina central no qual disponibiliza algum serviço que é consumido por máquinas com um hardware com bem menos recursos. A segunda forma de descentralização mostra o surgimento das aplicações P2P, onde podem ser desenvolvidas sobre sua forma completamente descentralizada (ex: Gnutella), denominada de pura, ou um modelo híbrido (ex: KaZaA), onde se

19

desenvolvem estruturas de controle centralizadas e a utilização de recursos descentralizados. uras Cada um dos modelos de descentralização possui suas vantagens e desvantagens conforme se pode acompanhar na sessão seguinte.

2.1.1 Arquiteturas p puras
De acordo com Schollmeier e Rudiger [8], as redes denominadas puras possuem como principal s característica a não existência de nenhum tipo de controle central. Todo o funcionamento se dá com uso de um algoritmo descentralizado onde é possível localizar peers e/ou serviços. Esta localização é feita fazendo uso da técnica de enchente (flooding onde a mensagem é d flooding), enviada a todos os computadores diretamente ligados ao emissor e cada máquina que recebe a omputadores mensagem faz o mesmo. Para evitar que a rede entre em colapso (loop), um tempo de vida é . (loop atribuído a mensagem para que caso esta não chegue a seu destino seja descartada Os pontos descartada. negativos aqui são: • • lgumas Algumas máquinas podem não receber a mensagem, negando assim um serviço que estaria disponível em tese; Há um grande volume de mensagens enviadas até que a mesma encontre a até máquina de destino. Para melhor ilustrar o funcionamento, é possível visualizar na Figura 3 o algoritmo de busca em execução. É possível perceber que algumas máquinas não repassam a mensagem recebida devido a limitações no tempo de vida e número de repasse. d

Figura 3: Exemplo de requisição usando a técnica de flood (Autor: M. P. Duarte.[26]) Duarte.

20

A técnica mais utilizada na implementação de arquiteturas puras o qual gerou um avanço significativo na área é o Distributed Hash Tables (DHT) [9]. Como exemplo de utilização dessa técnica temos as aplicações pStore [10], Pastiche [11], Oceanstore [12], PeerStore [13] e BitTorrent [14]. As DHTs pertencem à classe de sistemas distribuídos descentralizados e oferecem recursos de localização 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 especificações de DHTs - Pastry [15], Chord [16], CAN [17] e Tapestry [18], surgiram quase simultaneamente no ano 2001, depois disso, sua utilização se popularizou em aplicações destinadas ao compartilhamento de arquivos na internet. As DHTs possuem como principais características: • • • Descentralização: os próprios nós criam e mantêm o sistema, sem a necessidade de um servidor; Escalabilidade: o sistema suporta a participação de um crescente número de nós simultaneamente; Tolerância a erros: o sistema deve ser confiável, mesmo com nós entrando e saindo continuamente da rede. Para alcançar os objetivos supracitados, as redes DHTs utilizam a técnica de que um nó na rede deve estar em contato direto com apenas uma fração de todos os nós participantes. Isso reduz o custo de manutenção 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 nós responsáveis por seu armazenado. Para recuperá-lo, uma mensagem é enviada informando a chave do arquivo desejado, essa mensagem é encaminhada até um nó que possua o conteúdo desejado e então o mesmo é enviado como resposta. As características citadas sugerem que essa arquitetura seja bastante atraente para aplicações de compartilhamento na internet, dada a não necessidade de um controle centralizado. Porém, para aplicações que exijam um elevado nível de serviço, como a oferta de serviço de armazenamento em nuvem, opta-se pelo uso de arquiteturas híbridas, que combinem escalabilidade e confiabilidade.

21

2.1.2 Arquiteturas híbridas
Em alguns sistemas P2P é necessária a identificação 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 responsável pela autenticação dos usuários, manutenção da rede e dos metadados onde as cópias estão armazenadas. Pode-se ressaltar que a utilização de servidores não é obrigatória para a localização 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 operações tais como: autenticação do usuário; manipulação dos dados armazenados por outros peers, adicionar, remover, excluir, atualizar; manipulação dos usuários cadastrados no sistema; localização 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 permissão para executar tais operações. Essa centralização de informações pode trazer prejuízos de escalonamento no sentido de que sempre vai existir uma exigência maior do servidor à medida que se aumenta o número de requisições, usuários, metadados ou quaisquer outras informações delegadas ao serviço. Porém, sistemas como o eDonkey [19] se mostraram bastante eficientes quanto ao gerenciamento centralizado de informações dessa natureza. Se necessário esse escalonamento também pode ser resolvido com a utilização de clusters ou grids no lado do servidor, fazendo-se mais importante a disponibilização da interface de comunicação com a máquina cliente.

2.2 Plataforma JXTA

Descrita a arquitetura na qual os peers poderão estar dispostos para criação da federação de dados, que será utilizada como nuvem de armazenamento na solução proposta, a próxima etapa é descrever o padrão com o qual os mesmos se comunicarão para estabelecer esse agrupamento. Para tal, a tecnologia JXTA [20] fornece um conjunto comum de protocolos abertos, que dão suporte às implementações necessárias para o desenvolvimento de aplicações P2P.

22

Os protocolos JXTA padronizam a maneira como os peers realizam algumas atividades, tais como localização, agrupamento, publicação e descoberta de recursos na rede, comunicação e monitoramento de recursos. Tais protocolos permitem o desenvolvimento de serviços interoperáveis em aplicações P2P. Como os mesmos são independentes tanto da linguagem de programação quanto dos protocolos de transporte, dispositivos heterogêneos com software ou sistemas operacionais completamente diferentes podem interoperar entre si sem quaisquer consequências. Usando a tecnologia JXTA, é possível abstrair muitas funcionalidades necessárias para a criação de aplicativos P2P.

2.2.1 Arquitetura JXTA
A arquitetura do JXTA é dividida em três camadas conforme é ilustrado na Figura 4 abaixo [21].

Figura 4. Arquitetura JXTA em três camadas (Fonte: Sun Microsystems)

a) Core: A principal camada da arquitetura JXTA, o core reúne os recursos essenciais do JXTA, que são encapsulados em um conjunto que inclui: blocos de construção, mecanismos de chaves para aplicações P2P, serviços de descoberta, serviços de comunicação e transporte; serviço de firewall e NAT (Network Address Translation) transversal; serviço para criação de peer; serviço para criação de Grupos de peers e primitivas de segurança [21][22].

23

b) Serviços: Nesta camada, os serviços JXTA incluem serviços de rede que não são absolutamente necessários para uma rede P2P operar, porém são indispensáveis para a construção de um sistema de armazenamento em nuvem sob esse paradigma. Como exemplo, temos os serviços de rede que incluem as pesquisas indexadas, sistemas de diretórios e armazenamentos, compartilhamento de arquivos, sistemas de arquivos distribuídos, agregação de recursos, tradução de protocolos, autenticação e serviços de criptografias como PKI (Public Key Infrastructure) [21][22].

c) Aplicações: A camada de aplicações apresenta implementação de aplicações que usam JXTA integrado, tais como mensagens instantâneas P2P, compartilhamento de recursos e documentos, gerenciamento de conteúdo, e-mail P2P, sistemas de leilões distribuídos, entre outros.

2.2.2 Funcionamento de um sistema baseado em JXTA
Conforme será detalhado no Capítulo 3, o protótipo do sistema de armazenamento em nuvem utilizado para validação dessa pesquisa é baseado na arquitetura JXTA. Para uma melhor compreensão dos componentes e serviços do mesmo, será detalhado o funcionamento de algumas entidades e serviços que compõem um sistema baseado na plataforma JXTA, tais como o Peer, Grupo de peers, Serviços de Rede, Serviços do Grupo de Peer, Mensagens, Pipes e Anúncios. i. Peer No contexto de aplicações desenvolvidas sob a plataforma JXTA, o peer é qualquer entidade que faça 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 assíncrona e independente de todos os outros peers e é identificado por um peer ID [22]. Durante o processo de inicialização, o peer publica um ou mais endereços de rede para uso dos protocolos JXTA e cada endereço publicado é anunciado como um endpoint do peer, que identifica o endereço de rede. Os endpoints são usados para estabelecer conexão ponto-a-ponto de forma direta entre dois peers.

24

Os peers são normalmente configurados para descobrir outros peers na rede de forma espontânea, para estabelecer relacionamentos conhecidos como Grupo de peers, que podem ser de natureza transitória ou persistente. Em JXTA, os peers podem ser caracterizados em três tipos: • • • Minimal-Edge Peer: implementam apenas os serviços essenciais necessários do JXTA; Full-Edge Peer: possuem todas as características do núcleo e padrões de serviço do JXTA; Super-peer: suportam recursos de apoio à implantação e operação de uma rede JXTA. As três principais funções do super-peer são: - Relay – usado para armazenar e encaminhar mensagens entre peers que não têm conexão direta; - Rendezvous – mantém índices globais de anúncios, auxiliando novos peers a ingressar em um grupo de peers e possibilitando a criação do serviço de proxy para a execução das pesquisas de anúncio dos recursos. Também utilizado para as transmissões de mensagens; - Proxy – usado pelos peers para obter acesso a todas as funcionalidades da rede JXTA. O ponto de busca traduz e resume as solicitações, responde a consultas e fornece suporte para os pequenos peers terem acesso às funcionalidades.

Estas categorias descrevem as configurações de peers mais comuns, dependendo da capacidade da aplicação e dos peers, podendo ser feita uma implementação de peers com múltiplas funcionalidades.

ii.

Grupo de peers Um grupo de peer na plataforma JXTA é uma coleção de peers que geralmente

disponibiliza um conjunto comum de serviços ou interesses. Os peers se auto-organizam em grupos, cada grupo é identificado por um ID do grupo e os peers presentes nestes grupos também recebem o ID do grupo. O grupo estabelece a sua própria política de associação, inclusive a política pode ser aberta (qualquer pessoa pode participar) ou ainda rigorosamente seguro e protegido (o que exige credenciais para a adesão) [21]. A especificação dos protocolos JXTA descreve como os peers podem publicar, descobrir, juntar e monitorar grupos de peers, estes protocolos não ditam quando e nem como grupos de

25

peers são criados. Convencionalmente, um grupo de peers é formado simplesmente juntando peers que geralmente são organizados pelo tipo de serviço que oferecem. Além do objetivo de formar uma nuvem de armazenamento, conforme objeto de estudo desse trabalho, há várias outras motivações para a criação de grupos de peers, tais como: • Criação de ambiente seguro - pode ser criado domínio de controle local, no qual política de segurança específica pode ser executada. A política de segurança pode ser uma simples autenticação ou através de um algoritmo de criptografia de chave pública. As fronteiras dos grupos de pares permitem que os peers vizinhos possam acessar e publicar conteúdos protegidos. Os grupos de peers formam regiões lógicas cujos limites restringem o acesso aos recursos apenas entre peers do grupo; • Criação de escopo de ambiente - podem ser criados grupos que permitam o estabelecimento de domínio 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 regiões abstratas que fornecem um mecanismo de escopo implícito As fronteiras do grupo de peers são definidas pelo escopo da pesquisa, quando é realizada uma busca de conteúdos e serviços de um grupo; • Criação de ambiente de monitoramento - grupos de peers permitem a criação de mecanismos para realização de monitoramento dos conjuntos de peers para qualquer propósito específico.

Os grupos também 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.

Serviços de Rede Os peers realizam comunicações e publicações para que possam descobrir e invocar

serviços da rede. Os peers podem publicar vários serviços e estes serviços são descobertos

26

através do DPP (Discovery Protocol Peer). Os protocolos JXTA apresentam dois níveis de serviços de rede: • Serviços de Peer - acessíveis apenas no ponto que está publicando. Se esse ponto vier a falhar, o serviço também falhará e várias instâncias do serviço podem ser executadas em peers diferentes, mas cada instância realiza a publicação do seu próprio anuncio de serviço; • Serviços de Grupo de Peers - compostos por uma coleção de instâncias de serviços que potencialmente cooperarão uns com os outros, sua execução poderá ser hospedada em vários membros do grupo de peer. Caso qualquer um destes membros falhar, o serviço coletivo de peer não é afetado, desde que esteja disponível em pelo menos mais um membro do grupo. Serviços de grupos de peers são publicados como parte do anuncio do grupo, desta forma ao se criar um grupo automaticamente são anunciados os seus serviços. Os serviços podem ser pré-instalados em um ponto ou carregados através da rede. Quando um peer apresenta a necessidade de executar um serviço, este peer pode localizar uma implementação adequada para o ambiente em tempo de execução. O processo de encontrar, baixar e instalar um serviço da rede é análogo ao realizar uma pesquisa na internet para uma página da web [21].

iv.

Serviços do Grupo de Peers O grupo de peers oferece serviços ou conjuntos de serviços que geralmente são

conhecidos por todos os membros do grupo. Por definição, o JXTA oferece alguns serviços básicos para os grupos de peers. A soma dos serviços já existentes, com novos serviços que os peers do grupo oferecem, forma a assinatura de serviços do grupo de peers, logo, quando um novo peer entra no grupo, deve ser repassado a este peer o conhecimento dos serviços disponíveis neste grupo [21]. Os serviços básicos que um peer deve implementar ao entrar em um grupo de peer, numa rede JXTA são:

27

Serviço de Endpoint - usado para enviar e receber mensagens entre peers. Os serviços endpoint implementam os pontos de extremidades no protocolo de encaminhamento, embora as implementações mínimas forneçam apenas uma pequena porção deste protocolo;

Serviço Resolver - serviço de resolução usado para enviar solicitações de consultas genéricas para os peers. Os peers podem trocar consultas para encontrar qualquer informação que possa ser necessária (por exemplo, encontrar anúncios, determinar o status de um serviço ou a disponibilidade de uma extremidade do pipe).

Além dos principais serviços dos grupos de peers necessários para o funcionamento de cada peer, vários outros serviços padrões do JXTA são comumente definidos para o grupo. Nem todos os serviços padrões devem ser implementados pelo grupo de peers, e dependendo da definição do grupo estes serviços podem ser necessários ou não. Um grupo de peer especifica apenas os serviços que encontra entre os peers que formam o grupo, pode também contar com os serviços dos grupos de peers fornecidos pelo JXTA para oferecer implementações genéricas de serviços essenciais. Os serviços peer padrões, que são encontrados na maioria dos grupos de peers, são: • Serviço de Descoberta - usado pelos peers para procurarem recursos do grupos de peers que foram publicados. Estes recursos podem ser: peers, grupos de peers ou serviço de pipes; • Serviço de Composição - utilizado pelos peers para estabelecer de forma segura e confiante a identidade dos peers dentro de um grupo. A identificação permite que os aplicativos e serviços determinem quem está solicitando uma operação e decide se a operação deve ser permitida; • Serviço de Acesso - usado para validar as requisições feitas de um ponto para outro. O peer receptor do pedido verifica as credenciais do peer solicitante e verifica as informações sobre a requisição e após terem sido feitas as verificações determina se o acesso é permitido ou negado; • Serviço de Pipe - usado para criar e gerenciar conexões de pipes entre os membros do grupo de peer;

28

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

v.

Mensagens Serviços e aplicações JXTA se comunicam utilizando mensagem, que é a unidade básica

de troca de dados entre os peers. O conjunto de protocolos JXTA define como os participantes da rede farão as trocas de mensagens entre si. As mensagens são enviadas de um peer para o outro usando os serviços de endpoints e serviço de pipes, e em alguns casos são usados também o serviço JxtaSocket ou outras abordagens. Grande parte dos aplicativos não precisa usar pipe unidirecional ou usar serviço de endpoint JXTA. Nestes casos, aplicações e serviços usam Socket JXTA e canais de comunicação 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 utilização de XML (Extensible Markup Language) para descrever estas mensagens permite que diferentes tipos de peers possam utilizar este protocolo. Como os dados são descritos em uma estrutura XML bem formada, cada peer pode implementar o protocolo da forma que se adéqua melhor às suas capacidades e funções. Se um peer só precisa de um determinado subconjunto de informação 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 conteúdo que consegue processar [21].

vi.

Pipes Aplicações JXTA usam pipes para enviar mensagens de um peer para o outro. Os pipes

são mecanismos assíncronos, unidirecionais e não-confiáveis (com a exceção do pipes unicast seguro) de transferência de mensagens usados para comunicação e transferência de dados. Pipes são canais de comunicação virtual e podem conectar os peers que não têm uma ligação física direta e esta ligação resulta em uma ligação lógica. Os pipes podem ser usados para enviar qualquer tipo de dados, incluindo XML e texto HTML (HyperText Markup Language), imagens, músicas, código binário, sequencias de dados e objetos Java.

29

As extremidades do pipe são referenciadas como pipe de entrada ou recepção e pipe de saída ou envio. Os endpoints pipes são ligados dinamicamente aos peers terminais quando o pipe é aberto. Os peers endpoints correspondem a interfaces de rede disponíveis, funcionando como uma porta TCP associada a um endereço IP (Internet Protocol) que pode ser usado para enviar e receber mensagens. Pipes JXTA podem ter endpoints que estão conectados a diferentes peers em diferentes momentos e não podem ser ligados a outro pipe. Todas as resoluções de pipe e comunicação são feitas no âmbito do grupo de peer. Isto é, os pipes de entrada e saída devem pertencer ao mesmo grupo [21]. Os pipes oferecem dois modos de comunicação que são os modelos ponto-a-ponto e propagação, como ilustrado na Figura 5. A implementação JXTA denominada JXSE [23] também fornece segurança nos pipes unicast, onde se trata de uma variação com segurança do pipe ponto-a-ponto.

Figura 5. Pipes unicast e Pipes de propagação (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 saída do peer emissor, sendo possível que múltiplos peers se conectem a um único pipe de entrada;

Pipe de Propagação: interliga um pipe de saída a um pipe de entrada múltiplos. As mensagens de fluxo a partir do pipe de saída são a fonte de propagação para dentro dos pipes de entrada;

Pipe Unicast Seguro: pipe ponto-a-ponto que provê mecanismos de segurança e confiabilidade nos canais de comunicação.

30

Os pipes unidirecionais apresentam na especificação do JXTA um baixo nível de abstração na comunicação. Recomenda-se que desenvolvedores usem um nível de abstração mais alto para a comunicação que pode ser fornecida pelo serviço JXTASocket e JXTABiDiPipe [21].

vii.

JXTASocket e JXTABiDiPipe Os pipes JXTA básicos fornecem canais de comunicação unidirecionais não-confiáveis,

com objetivo de tornar os pipes mais úteis para serviços e aplicações, sendo necessário implementar canais de comunicação bidirecionais confiáveis na parte alto nível do pipe. O JXSE [23] fornece funcionalidades para atender os níveis de qualidade de serviço exigido pelas maiorias das aplicações P2P [21]: • • • • • • Confiabilidade; Garantia do seqüenciamento da mensagem; Garantia de entrega; Exposição das interfaces de streaming de mensagens; Segurança; JxtaSocket e JxtaServerSocket: - Sub-classe java.net.Socket e java.net.ServerSocket respectivamente; - São construídos em cima de pipes e mensagens de endpoit, apoiado por uma biblioteca de confiabilidade; - Fornece canais bidirecionais de comunicações confiáveis e seguras; - Disponibiliza uma interface baseada em streaming; - Fornece buffer interno configurável e mensagens de chunking; • JxtaBiDiPipe e JxtaServerPipe: - São construídos em cima de pipes e mensagens de endpoit, apoiado por uma biblioteca de confiabilidade; - Fornece canais bidirecionais de comunicações confiáveis e seguras; - Disponibiliza uma interface baseada em mensagem.

31

Em resumo, o JxtaServerSocket e JxtaServerPipe disponibilizam um pipe de entrada para processar as solicitações de conexão e negociar os parâmetros de comunicação. 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. Conexão Pipes (Fonte: Sun Microsystems)

viii.

Anúncio

Todos os recursos de rede JXTA como peers, Grupos de peers, pipes e serviços são representados como anúncios, que são de linguagem neutra de meta-dados, representados por documentos com estruturas XML. Os protocolos que compõem o JXTA usam anúncios para descreverem e publicarem as existências de recursos entre peers. Os peers descobrem recursos, procurando por anúncios correspondentes, e podem armazenar localmente em cache todos os anúncios descobertos [21]. Cada anúncio é publicado com um tempo de vida que especifica a disponibilidade de seu recurso associado. O tempo de vida permite a supressão de recursos obsoletos sem necessidade

32

de qualquer controle centralizado. O anúncio pode ser re-publicado (antes de o anúncio original expirar) para estender a vida útil de um recurso. O protocolo JXTA define os seguintes tipos de anúncio: • Anúncio de Peers: descreve os recursos do peer, e a principal utilização deste anúncio é para armazenar informações específicas sobre o peer, como seu nome, ID de peer, os endpoints disponíveis, e todos os atributos e serviços individuais de grupo que pretende publicar em tempo de execução; • • Anúncio de Grupo de Peers: descreve os recursos específicos do grupo de peers, tais como nome, ID de grupo de peers, descrição, especificação e parâmetros de serviço; Anúncio de Pipe: descreve o canal de comunicação do pipe, e é usado pelo serviço de pipe para criar a entrada associada ao ponto da extremidade de saída do pipe. Cada anúncio de pipe contém um ID opcional simbólico, um tipo de pipe ID único; • Anúncio de Classe de Módulo: descreve as classes de módulos e sua principal finalidade é documentar formalmente a existência de uma classe de módulo e são incluídos nome, uma descrição e uma identificação única que é o ModuleClassID; • Anúncio de Especificação de Módulo: define a especificação do módulo e seu principal objetivo é oferecer referências para a documentação necessária a fim de criar implementações conforme a especificação. O uso secundário e opcional deste anúncio pode ser feito através da execução de uma instância utilizável remotamente através da publicação de informações como anúncio de pipes. Isso inclui nome, descrição, identificação única que é o ModuleSpecID, anúncio dos pipes e campos contendo parâmetros arbitrários para serem interpretados por cada aplicação; • Anúncio de Implementação de Módulo: define a implementação da especificação de um módulo, os elementos incluem nome associado ao ModuleSpecID, código, pacote, e campos de parâmetros que permitem que um peer recupere dados necessários para executar uma aplicação; • • Anúncio de Rendezvous: descreve um peer que atua como um ponto de encontro para os grupos de peers; Anúncio de Informação de Peer: descreve as informações de recurso do peer e a principal utilização deste anúncio é armazenar informações específicas sobre o estado atual de um

33

peer, como tempo de atividade, número de mensagens de entrada e saída, tempo da última mensagem recebida e mensagem enviada pela última vez. Cada anúncio é representado por um documento XML, e os anúncios são compostos de uma série de elementos hierarquicamente dispostos, onde cada elemento pode conter os seus dados ou elementos adicionais. Um elemento também 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 distribuído P2P e a Plataforma JXTA, que consistem no estado da arte para o desenvolvimento de grids computacionais utilizando recursos ociosos, o tópico a seguir descreve três frameworks desenvolvidos para implementar, gerenciar e controlar o armazenamento e a recuperação dos dados pelos usuários finais. Em seguida, a partir da observação das principais características que compõem essas três abordagens, será escolhido um framework no qual será desenvolvido um testbed com o objetivo de simular o funcionamento do sistema. Dessa forma, será possível aferir as principais métricas de desempenho e subsidiar o modelo de avaliação 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 distribuído através de milhares de máquinas 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 preocupações dos sistemas de armazenamento distribuídos, tais como disponibilidade. desempenho, escalabilidade, confiabilidade e

34

O cluster GFS consiste em um controlador, chamado master, e múltiplos chunkservers, acessado por múltiplos clientes, conforme mostra a Figura 7. Cada um desses componentes é tipicamente uma máquina Linux, executando um processo de servidor a nível usuário, sendo comum executar as funções de master e chunkserver na mesma máquina, desde que a mesma possua recursos para tal e seja aceita a redução de confiabilidade do sistema decorrente de uma paralisação simultânea de ambas as funções. Os arquivos são divididos em fragmentos de tamanho fixo, denominados chunks. Cada chunk é identificado por uma identificação global fixa de 64 bit (chunk handle), designada pelo servidor máster no momento da criação 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 informações de chunk handle e na capacidade de bytes. Para garantir a confiabilidade do sistema, cada fragmento é replicado em múltiplos chunkservers. Por padrão, são geradas três réplicas do mesmo chunk, porém esse valor pode ser alterado de acordo com as especificações do sistema.

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

O master mantém todos os metadados do sistema de arquivos, incluindo nome do arquivo, controle de acesso, a correspondência entre os arquivos e os fragmentos e a localização dos chunks. Ele também controla todas as atividades de gerenciamento do sistema, tais como designação da identificação dos chunks, deleção de fragmentos órfãos e migração de fragmentos entre chunkservers. Para tal, o master envia atualizações periódicas para cada chunkserver, através de mensagens do tipo “HeartBeat”, contendo instruções e verificando os seus estados.

35

Para armazenamento e recuperação dos dados, os clientes GFS possuem aplicações que implementam uma interface lógica (API – Application Programming Interface) de comunicação entre o master e os chunkservers. Esses clientes interagem diretamente com o servidor master, porém todos os dados enviados são fragmentados, replicados e enviados para os elementos de armazenamento (chunkservers). Embora não descreva detalhadamente os componentes de software que compõem os módulos de controle (master) e de armazenamento (chunkservers), o GFS introduziu conceitos importantes para o desenvolvimento de ferramentas de armazenamento em nuvem a partir da formação de clusters, ou federação de dados, tais como a fragmentação em tamanho fixo (chunks), a quantidade de réplicas necessárias e os mecanismos de interação entre os diversos componentes, de modo a garantir o desempenho e a flexibilidade necessária 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 série de recursos que podem ser acessados de forma distribuída. Esta ferramenta disponibiliza para os usuários uma interface de acesso ao sistema de arquivo, tornando a tarefa de acessar e manipular arquivos de fácil manuseio para o usuário. Para aumentar a comodidade dos usuários, ela propõe dois meios de utilização, 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 acessível de forma online. Não é característica da ferramenta, prover recursos de manipulação de dados, visto que a mesma apenas disponibiliza um sistema de arquivo. Os dados armazenados neste sistema de arquivo são distribuídos entre a infraestrutura do Campus Cloud, e os meios pelos quais os usuários destes dados tem acesso a eles são completamente abstraídos 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 distribuída, reforçando 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 manutenção dos mesmos tanto através de um browser acessado via internet, quanto através de um cliente instalado no computador. Em ambos os casos, tem-se um ambiente de fácil interação para o usuário 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, através do cálculo de probabilidade de falha de cada nó de armazenamento. Essa ferramenta, inicialmente denominada U-BKP, utiliza uma arquitetura P2P Híbrida baseada na Plataforma JXTA, detalhadas no início desse capítulo.

37

Nesse cenário, os peers são agrupados em federações de dados, permitindo o crescimento elástico e a escalabilidade do sistema, definindo assim uma cloud storage. A principal vantagem da ferramenta USTO.RE é a capacidade de prover soluções de armazenamento de dados em ambientes de nuvens públicas ou privadas. Por esse motivo, essa ferramenta será utilizada na elaboração do protótipo e nos experimentos a serem desenvolvidos para validação dessa pesquisa, os quais serão detalhados nos Capítulos 3 e 4.

2.4 Sumário do Capítulo
Conforme acompanhado na leitura do capítulo, este teve a finalidade de descrever o modelo P2P e a Plataforma JXTA, tecnologias que suportam o desenvolvimento de um sistema de armazenamento distribuído conforme proposto por essa pesquisa. Após essa descrição, foi realizado um levantamento de três ferramentas capazes de subsidiar a elaboração de um protótipo para validação da proposta, bem como suas arquiteturas e aspectos funcionais. Por fim, foi escolhida a ferramenta USTO.RE para suportar tal protótipo, que será detalhada no capítulo a seguir.

38

3 ARQUITETURA USTO.RE
No capítulo que se segue, é detalhada a arquitetura da plataforma apresentada pelo Projeto USTO.RE, descrevendo seus principais padrões, módulos, componentes, frameworks e integrações. De modo a permitir uma visão de alto nível do contexto utilizado como testbed para análise do tráfego de um sistema de armazenamento P2P em nuvem. Alguns termos importantes que serão mencionados no decorrer deste capítulo. Estes termos são descritos na tabela a seguir, estando apresentados por ordem alfabética:
Tabela 1 Conceito dos termos utilizados na arquitetura
Termo Descrição

Componente

Elemento de software reusável, independente e com interface pública bem definida, que encapsula uma série de

funcionalidades e que pode ser facilmente integrado a outros componentes. Serviço Agrupamento lógico de funcionalidades para facilitar a divisão e entendimento de um software.

A especificação do sistema foi dividida em duas partes: Descrição do Sistema e Descrição dos componentes e serviços. Cada uma dessas visões aborda as principais perspectivas: • • A Descrição do Sistema apresenta o hardware envolvido e o mapeamento dos elementos de software para os elementos de hardware nos ambientes do sistema. A Descrição dos Componentes e Serviços apresenta os aspectos de concorrência e sincronização do sistema, alocando os elementos da visão funcional dos processos, threads e tarefas de execução. Como o sistema de armazenamento USTO.RE já se encontra em produção e disponível comercialmente (http://usto.re), alguns aspectos relacionados à implementação do mesmo foram suprimidos, tais como os padrões de codificação, tecnologias utilizadas, ambientes de desenvolvimento e bibliotecas, porém, sem prejuízo para a pesquisa apresentada nesse trabalho.

39

3.1 Descrição do sistema
Esta seção apresenta a descrição geral do sistema, especificando os principais componentes, dependências e relacionamentos. O objetivo geral do USTO.RE, é permitir a criação de uma nuvem para armazenamento de dados utilizando a tecnologia P2P que se baseia na disponibilidade de cada peer para, dinamicamente, criar federações e definir a quantidade de replicações de cada fragmento (chunk) de cada arquivo, conforme visão geral disposta na figura 9 abaixo.

Figura 9. Visão geral da arquitetura USTO.RE (Autor: Rodrigo Elia Assad)

O sistema é composto por um conjunto de cinco componentes, dispostos em uma arquitetura P2P híbrida e em três camadas:

40

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

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

Estes componentes possuem funcionalidades distintas e interagem como um sistema distribuído descentralizado híbrido, de modo semelhante a uma rede P2P, onde cada nó realiza tanto funções de servidor quanto de cliente. Os componentes agrupam-se dinamicamente como federações de dados, onde os grupos são montados de modo a minimizar a troca de mensagens no sistema. A organização do sistema nesta arquitetura multicamadas possibilita a distribuição do processamento, uma vez que os componentes estão fisicamente distribuídos. Entretanto, por se tratar de uma arquitetura híbrida P2P estruturada e multicamadas, o sistema possui uma distribuição dita horizontal. Nesta distribuição 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 própria porção dos dados, propiciando um balanceamento da carga. Na seção seguinte, serão detalhadas as funções de cada componente descrito nesse tópico, bem como as etapas de funcionamento indicadas nas setas vermelhas, da Figura 9.

3.2 Descrição dos Componentes e serviços
Esta seção irá detalhar as funcionalidades e interações e serviços oferecidos pelos componentes apresentados no tópico anterior, visando o melhor entendimento da solução estudada nessa pesquisa.

3.2.1 Super peers
Os super peers funcionam como elementos de referência para os demais componentes da arquitetura, sendo a porta de entrada para a participação de servidores, proxies e simple peers no

41

sistema. O papel do super peer é definir as federações de dados quando cada peer solicita conexão à rede. Para isso, os super peers devem ter sua localização previamente conhecida por todos os demais peers por meio de uma pré-configuração. Conseqüentemente, eles são os primeiros componentes a serem inicializados para o correto funcionamento do USTO.RE. Também como conseqüência, um super peer guarda informação sobre todos os servidores, proxies e simple peers, agrupando-os dinamicamente de acordo com o perfil de cada peer, a ser descrito adiante. Também é papel deste tipo de peer, escolher dinamicamente os peers e servidores das federações, baseando-se no algoritmo de dispersão descrito por Duarte [26] e citado no tópico 2.3.3 deste trabalho. O agrupamento em federações permite o crescimento elástico e garante a escalabilidade do sistema, pois não existe um limite para a quantidade de federações que podem ser criadas. Por crescimento elástico temos a característica de o sistema crescer ou diminuir, em termos de capacidade e consumo de recursos, de maneira dinâmica e não intrusiva. Os peers se comunicam com a rede P2P através do protocolo JXTA, descrito no tópico 2.1 dessa pesquisa, e opcionalmente podem ofertar uma interface de serviço REST [27] para permitir a interoperabilidade com outras aplicações.

3.2.2 Servidores
Os peers servidores são aqueles que oferecem um conjunto (ou subconjunto) de uma lista prédefinida de serviços. Na ordem de configuração do USTO.RE, os servidores são os componentes que devem ser executados logo após a inicialização dos super peers (Passo 1 na Figura 9). Super peers estabelecem um esquema de sincronização, fazendo com que a lista de servidores em cada um deles seja atualizada, quando da entrada ou saída de um peer servidor. A definição de peers com funcionalidades específicas na rede opõem-se a algumas propostas para sistemas P2P, onde cada peer deveria ser capaz de desempenhar todos os papéis no sistema, promovendo a idéia de uma DHT (Distributed Hash Table) completa [9]. No entanto, a implementação utilizando uma DHT em sua essência é bastante custosa e de difícil escalabilidade, conforme demonstrou Nocentini, Crescenzi e Lanzi [28]. Sendo assim, a proposta adotada no USTO.RE é a criação de níveis hierárquicos que implementam serviços bem

42

definidos e que podem crescer horizontalmente. Dentre os serviços disponibilizados pelos servidores, pode-se citar: 1) Autenticação: 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 Capítulo 4; 4) Controle de Saída: controla a saída voluntária de um peer, quando este se desconecta voluntariamente da rede; 5) Gerência de Diretórios: utilizado para armazenamento e recuperação de diretórios inteiros; 6) Gerência de Arquivos: utilizado para armazenamento e recuperação de arquivos; 7) Busca: procura por um conjunto de peers que obedecem ao acordo de nível de serviço, no caso dessa aplicação, está fortemente relacionado à disponibilidade do peer para o armazenamento de um arquivo; 8) Árvore de Diretórios: utilizado para visualização de diretórios inteiros; 9) Segurança de Acesso: controla a permissão de acesso aos chunks; 10) Rastreamento: mantém uma lista de usuários e arquivos a ser consultada quando a recuperação de um arquivo é solicitada. Como se observa na Figura 9, os peers servidores utilizam dois tipos de banco de dados para manter a consistência do sistema. Um banco de dados tradicional relacional contém dados dos usuários do sistema e um banco de dados No-SQL [29], que permite um crescimento horizontal e a recuperação mais rápida das informações relacionadas ao desempenho do sistema. Caso não 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 não ocorre com a utilização de um sistema nativamente, garantindo assim a viabilidade e escalabilidade da solução. Todas as informações referentes à autenticação e níveis de serviço dos peers são salvas no banco de dados relacional, dada a garantia da integridade relacional provida por esse tipo de banco de dados. Já o serviço do FileTracker, que permite a identificação 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 instâncias de ambos os bancos podem ser compartilhadas entre mais de um servidor. Um peer servidor pode prover um ou mais serviços de rede, sendo assim, da mesma forma que na criação de federações de dados, pode-se iniciar peers servidores e proxies ad-hoc (sob demanda), aumentando a escalabilidade e elasticidade do sistema. No atual estágio do projeto, este aumento é feito manualmente, a partir do monitoramento do desempenho do sistema.

3.2.3 Proxies
Após a inicialização de super peers e servidores, o terceiro componente que precisa ser executado é o proxy. Cada proxy atua como um catálogo, um serviço de localização para serviços em execução 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. Além disso, um proxy obtém a informação de quais serviços estão disponíveis em cada servidor. Desta forma, quando um peer deseja a informação sobre um determinado serviço, um proxy pode fornecer a referência para um servidor que atenda tal requisição. Dessa forma, um proxy estabelece uma ponte de ligação entre consumidores de serviços, tipicamente os simple peers, e os provedores de um serviço, no caso, os peers servidores.

3.2.4 Simple peers
Simple peers são aqueles responsáveis por armazenarem os chunks (fragmentos) dos arquivos. Na visão alto nível da proposta, estes peers representam máquinas de usuários comuns que possam oferecer espaço de armazenamento para ser compartilhada entre vários usuários. Cada simple peer possui um perfil que define a sua disponibilidade e que lhe é atribuído quando da sua conexão com o sistema. Esta disponibilidade é relacionada ao período de tempo em que o peer esteja disponível para compartilhar dados. Como exemplo, um peer que esteja na intranet de uma empresa pode ter em seu perfil, a disponibilidade atribuída 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 disponíveis (Passo 3 da Figura 9). Desta lista, o proxy busca por um serviço específico e obtém a referência de quais servidores ofertam determinado serviço (Passo 4 da Figura 9). Um servidor aleatório é escolhido e o simple peer solicita o serviço desejado (Passo 5 da Figura 9). Caso um serviço não seja atendido por algum motivo, como um timeout, o proxy pode fornecer um novo servidor para o simple peer. Como citado anteriormente, simple peers são agrupados em federações de dados pelos super peers. O objetivo de agrupá-los dessa forma é minimizar a sobrecarga na rede e em cada peer, além de diminuir a quantidade de mensagens trocadas e permitir que uma federação desempenhe o papel de backup da outra federação. O agrupamento dos peers em federações obedece aos seguintes critérios, por ordem de relevância: proximidade; perfil de cada simple peer; latência de rede; latência da federação; georeferenciação; capacidade de cada peer e capacidade final da federação, definida pelos super peers. Cada peer possui uma interface de serviço REST [27] que permite a autenticação do usuário, armazenamento, recuperação e remoção dos dados salvos. Tal característica apresenta como principal vantagem a possibilidade de compatibilizar o sistema com outras interfaces existentes, como S3 da Amazon [6]. Na atual arquitetura, o serviço de armazenamento dos dados pode ser modificado para outras opções (i.e.: Megastore, MSFSS ou S3). Para garantir o espalhamento de cada chunk de forma a garantir os níveis de serviço 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 à comunicação 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 elegível para receber chunks no horário definido. Também periodicamente peer verifica com os demais peers existentes se os chunks que ele possui estão replicados na quantidade mínima de peers obedecendo ao critério de disponibilidade exigida [26]. Caso não 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 conexão de peer local à rede, ao salvamento dos arquivos solicitados. Após o peer (PL1) se conectar à rede P2P1, o super peer indica um peer servidor para ele se autenticar. Com a autenticação bem sucedida, o processo de identificação dos pares para formar as federações é executado. Com a federação (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 segmentação do arquivo (em chunks) e estes segmentos são 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, conseqüentemente, da disponibilidade dos segmentos do arquivo na rede e caso exista uma combinação de peers que atenda ao SLA para o armazenamento, os segmentos do arquivo são enviados para estes peers. Se não 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: Vinícius Cardoso Garcia)

3.3 Sumário do capítulo
No capítulo que se seguiu, foi detalhada a arquitetura do sistema USTO.RE, cuja operação foi especificada tendo como meta atingir um conjunto de atributos de qualidade peculiares aos sistemas de armazenamento distribuído, aliado a aspectos intrínsecos da arquitetura P2P, tais como: a) Escalabilidade: atendendo a possibilidade de explorar recursos de hardware de um grande número de máquinas (hosts) conectados à rede, principalmente por meio do uso racional de recursos ociosos em grandes corporações, tais como empresas Operadoras de telecomunicações.

b) Desempenho: O “encurtamento da distância” entre os peers que interagem no sistema, graças ao agrupamento dos mesmos em federações, reduz a latência na troca das mensagens de controle, proporcionando melhor desempenho em relação aos sistemas puramente DHTs.

c) Disponibilidade: Graças ao algoritmo de disponibilidade utilizado pelo sistema, no qual são associados perfis de disponibilidade para os peers que compõem o sistema, é garantida a conectividade e a qualidade de serviço necessária a um sistema de armazenamento com alta disponibilidade, superando assim algumas restrições impostas pela arquitetura P2P.

Diante do exposto, conclui-se que a arquitetura USTO.RE apresenta todas as características necessárias para o gerenciamento de um sistema de armazenamento em nuvem, utilizando o paradigma P2P, conforme será demonstrado nos capítulos seguintes, através da análise de um protótipo do sistema e de um estudo de caso.

48

4 ANÁLISE DE TRÁFEGO DO PROTÓTIPO
No capítulo a seguir é especificado um protótipo do serviço, no qual serão analisadas algumas métricas necessárias para definição de parâmetros de controle e dimensionamento do tráfego, de modo a subsidiar um modelo de análise de viabilidade do serviço. Esse modelo será validado em um estudo de caso em uma Operadora de Telecomunicações. A análise será composta pela especificação da arquitetura adotada no protótipo e pela descrição dos experimentos realizados, no qual foi utilizada a metodologia GQM (Goal Question Metric) [30], que orientou a avaliação estabelecendo o objetivo do estudo, as perguntas a serem respondidas e as métricas para interpretar as respostas.

4.1 Definição dos objetivos e métricas
A partir da Figura 11, temos uma visão macro da arquitetura proposta para a oferta do serviço cloud-computing, utilizando recursos ociosos – como a capacidade de armazenamento nas estações utilizadas como posições de atendimento do Callcenter, por exemplo. Os links grafados em azul são conexões internas entre os elementos do core de rede da Operadora, e seu tráfego está relacionado à banda contratada pelo cliente, ou seja, não será influenciado pela contratação do serviço de armazenamento, assim como o tráfego nos links grafados em vermelho. Para esses links, a oferta do serviço de armazenamento utilizando recursos internos ao domínio de rede da Operadora será benéfica, no sentido de reduzir o tráfego pelos mesmos, cuja banda representa um custo variável elevado para as Operadoras, muitas vezes utilizando cabos submarinos ou satélites como meio de transmissão. Isso ocorre porque os clientes que contratarem tal solução deixarão de utilizar serviços armazenados em provedores externos ao ambiente dessas operadoras. Diferentemente dos links marcados em azul e vermelho, o tráfego do link marcado em lilás será fortemente influenciado pelo overhead de controle da arquitetura proposta, na qual será utilizada a capacidade de armazenamento das posições de atendimento do Callcenter. Por esse fato, a principal métrica a ser analisado no protótipo será o tráfego nesse link em função da capacidade de armazenamento. Conforme será detalhado no Cenário II, a linha tracejada indica o

49

túnel ethernet que será criado nesse link, através do padrão IEEE 802.1Q [31], para separar o tráfego dos sistemas privados existentes no Callcenter. Uma vez dimensionado o link lilás, será possível mensurar o investimento necessário na ampliação do meio de transmissão que o atende, em função da receita gerada pela capacidade de armazenamento que será ofertada, algo fundamental para a investigação da viabilidade econômica da solução proposta por essa pesquisa.

Figura 11: Detalhamento da arquitetura do serviço cloud-computing por uma Operadora

Por definição da metodologia GQM, utilizada para orientação da análise proposta, a análise foi dividida em dois cenários, conforme abaixo: a) Cenário I
Tabela 2: Modelo GQM da Análise do Cenário I

50

Goal 1: Redução do tempo de armazenamento

Question: Qual a configuração de chunk apresenta o armazenamento mais rápido?

Question: Qual a configuração de fila apresenta o armazenamento mais rápido?

Metric: Tempo de armazenamento (s)

Figura 12: Estrutura hierárquica do modelo GQM da Análise do Cenário I

b) Cenário II: Tabela 3: Modelo GQM da Análise do Cenário II

51

Goal 2: Medição do tráfego médio entre as redes de carga e de dados

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

Metric: Relação entre os bits trafegados pelos bits armazenados (%)

Figura 13: Estrutura hierárquica do modelo GQM da Análise do Cenário II

4.2 Resultados Obtidos
Após definidos os objetivos dos experimentos, serão descritos os resultados obtidos e detalhados os cenários.

4.2.1 Cenário I
Aplicando-se a metodologia GQM, neste cenário foi definido o seguinte objetivo: definir qual a configuração de controle apresenta o melhor desempenho – sob o ponto de vista do usuário, em um sistema de armazenamento P2P utilizando recursos computacionais ociosos e não dedicados. Pelas características de controle do testbed utilizado (USTO.RE), o desempenho tem relação direta com a quantidade de mensagens trocadas pelos seus componentes internos, tanto no que se refere ao tráfego gerado pela aplicação, quanto no consumo dos recursos computacionais de hardware dos peers (consumo de CPU e memória RAM). Essa quantidade de

52

mensagens tem por sua vez, uma relação 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 variação do tamanho dos chunks e da sua fila, analisando dessa forma o impacto destas variáveis no tempo de envio dos dados. O objetivo desse teste é identificar se é necessário realizar configurações específicas quando o ambiente estiver funcionando em ambientes LAN, conforme o proposto por esse trabalho e que será detalhado no Estudo de caso do Capítulo 5. Para a execução deste teste foram utilizadas 20 máquinas com o sistema implantado, todas com as mesmas configurações de hardware: Processador Pentium IV, com 2GB de RAM e placa de rede 100 Mbps, de acordo com o padrão IEEE 802.3. Ou seja, todas compatíveis com o parque instalado nas posições de atendimento do Call-center, coadunando com a idéia da utilização de recursos computacionais não dedicados para o armazenamento de dados em nuvem. Destas máquinas, 15 (quinze) enviavam dados (carga) e 5 (cinco) representavam um storage com 10TB de armazenamento. As máquinas de carga enviavam 1GB de dados, sendo: • • • • 3 máquinas enviando 2000 arquivos de 500 KB; 6 máquinas enviando 500 arquivos de 5 MB; 3 máquinas enviando 50 arquivos de 50 MB; 3 máquinas 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 variáveis de controle responsáveis pela fragmentação 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 tráfego médio em cada experimento, calculado pelo tráfego cursado em função do tempo total de transferência. Fica evidente o impacto significativo no desempenho do sistema quando há variação dos parâmetros analisados, sendo este impacto maior, quando há variação 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, conseqüentemente, a melhor taxa de transferência média 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 decréscimo na taxa de transferência, 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 tráfego médio de carga, registrado em cada um dos experimentos.
Tabela 4: Tráfego médio de carga, variando-se os parâmetros 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) Tráfego médio (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

Tráfego médio (Mbps)
43,57 40,96

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

7,25 1 2

3

4

5

6

7

8

9

Figura 14: Tráfego médio de carga observado nos experimentos do Cenário I

Nesse cenário também foi analisada a questão relacionada ao desempenho das máquinas que recebiam os dados, uma vez que o objetivo da pesquisa é propor uma arquitetura transparente ao cenário existente, para utilização dos recursos de armazenamento ocioso, em máquinas não dedicadas, para a oferta do serviço de armazenamento. Isto é, a implantação dessa aplicação deve afetar minimamente o desempenho das aplicações existentes. Observou-se que as máquinas que

54

recebiam os dados chegaram ao limite de consumo do CPU e de memória RAM, ou seja, 100% e 2GB, respectivamente. Por ser essa condição extremamente indesejável, dada a premissa da transparência necessária da solução, foi repetido o experimento 8, que apresentou o melhor resultado na carga de dados, mantendo-se a fila total em 1024 KB, porém utilizando um único chunk de 1MB. Nessa condição, observou-se uma taxa de transferência similar ao experimento anterior, porém, sem a saturação da capacidade de processamento e memória das máquinas de carga. Dessa forma, temos que a seguinte resposta ao “Goal 1” da análise do protótipo: Do ponto de vista do usuário final, a melhor configuração 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 Cenário II
Partindo-se do resultado encontrado no Cenário 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 variável, é reproduzir de forma controlada e manipulável o cenário apresentado na figura 11, no qual é apresentada a arquitetura para implantação do serviço 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, através da criação de VLANs e um roteador (modelo Cisco 2620 XM), para a interconexão dessas VLANs, através de uma porta tronco, de acordo com o padrão IEEE 802.1Q [31]. A topologia e os scripts de configuração são apresentados na figura 15 e 16 - respectivamente. Todas as portas utilizam o padrão FastEthernet 100 Mbps, full-duplex e endereçamento IPv4.

55

Figura 15: Topologia de simulação da arquitetura proposta

Figura 16: a) Script de configuração do Switch0 b) Script de configuração do Router0

Após a criação e testes de conectividade no cenário acima, recriando o protótipo de testes descrito no cenário I, com o acréscimo da segmentação física entre a LAN de carga e de armazenamento, permitindo um controle centralizado do tráfego entre as mesmas, visto que todo o tráfego cursado entre as mesmas será encaminhado pelo Router0, através da porta tronco, para o Switch0. Isso se faz necessário em virtude da necessidade de segmentação entre a LAN de armazenamento, que estará em um ambiente privado, de acesso restrito, e da LAN de carga, que estará em um ambiente público, de acesso não controlado. No Projeto GFS [24], descrito no tópico 2.3.1, utilizou-se uma arquitetura similar à proposta nesse experimento. Entretanto, o mesmo não utilizou a segmentação através de VLANs entre elas, criando assim um único

56

domínio de broadcast em todo o cenário, não sendo possível separar o tráfego da aplicação 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 Capítulo 5 faz uso de VLAN para a separação do tráfego. A partir daí, foi refeito o experimento 9, no novo cenário segmentado, e avaliada a relação do tráfego transmitido nos link de entroncamento e a quantidade de bits armazenados pelo serviço P2PSS, através da edição do comando “show interface Fa0/0”, no prompt de comandos do roteador Cisco 2620XM. Conforme destacado na figura 17 abaixo, o tráfego em questão pode ser avaliado no sentido input (1) ou output (2), dada a simetria de tráfego resultante da centralização 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 avaliação, verificou-se que o overhead total de controle da solução proposta, incluindo os protocolos de aplicação (HTTP), transporte (TCP), internet (IP), acesso ao meio (Ethernet), além dos bits de marcação de VLAN (IEEE 802.1q) é de 49,35%, conforme mostrado na tabela 5.
Tabela 5: Overhead total de controle, da solução 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 máxima líquida de 66 Mbps para a transferência de dados, em cada link de entroncamento. Caso sejam utilizados links de 1 Gbps, conforme proposto no Projeto Google File System [24], teríamos uma taxa máxima líquida de 666 Mbps. Com isso, temos que a seguinte resposta ao ”Goal 2” da análise do protótipo: 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 serviço de armazenamento em nuvem Dropbox [33], similar a proposta do USTO.RE. Nele, foi verificado que na grande maioria das operações de armazenamento o overhead de controle ficou em 309 bytes por chunk, desconsiderando as mensagens de autenticação do protocolo SSL (usado pelo Dropbox) e de encapsulamento descritos pelas camadas de transporte, rede e enlace do modelo de referência OSI [34]. Abstraindo-se esse fato e transportando essa relação para a análise descrita nessa dissertação – que considera todos os protocolos de controle - teríamos diferença aproximada de 45 p.p. Mesmo considerando o fato da análise proposta pro Drago, Mellia e Munafò não considerar todos os protocolos de controle e encapsulamento descritos no modelo OSI na análise do overhead de armazenamento do Dropbox, essa diferença significativa, em relação aos resultados observados no Cenário II dessa dissertação, sugere novos trabalhos que investiguem mecanismos para a redução do overhead de armazenamento nos links de entroncamento do framework USTO.RE.

4.3 Sumário do capítulo
No capítulo que se seguiu, foi especificado um protótipo do sistema de armazenamento proposto nessa pesquisa, e, através 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 parâmetros eram mais relevantes e a melhor configuração dos mesmos, através de nove experimentos práticos. Tais experimentos

58

comprovaram a influência da fragmentação no tempo de armazenamento e indicaram o uso de fragmentos de 1MB, enfileirados um-a-um. Com relação ao segundo atributo, procurou-se estabelecer uma relação da capacidade de armazenamento com o dimensionamento dos links de interligação entre os subsistemas de armazenamento e carga, através do estudo do overhead de controle da aplicação. Partindo-se do experimento que apresentou melhor resultado no tempo de armazenamento, foi introduzida uma arquitetura de roteamento centralizado e analisada a relação do tráfego transmitido com os dados armazenados, chegando-se ao valor de 49,35% de overhead de controle. Esse valor, comparado a estudos em uma aplicação 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
Após a definição da arquitetura proposta nessa pesquisa, bem como a investigação do seu funcionamento, o presente capítulo contextualiza a oferta do serviço de armazenamento distribuído (Cloud computing) nas Operadoras de Telecomunicações, caracteriza o

dimensionamento e a especificação técnica da solução. Em seguida, é apresentada uma análise da viabilidade econômica do Projeto, utilizando ferramentas clássicas de Engenharia Econômica.

5.1 Serviço Cloud-Computing nas Operadoras de Telecomunicações
Desde a privatização do sistema Telebrás, em 1998, o mercado de telecomunicações brasileiro vem sofrendo profundas transformações. Dentre essas mudanças, as mais marcantes são a convergência na oferta de serviços e a acirrada concorrência entre os principais players. A Figura 18 abaixo ilustra a dinamicidade e a tendência de concentração nesse segmento econômico, mostrando a evolução do mercado nos últimos 12 anos. Somados, os sete principais grupos listados, apresentaram uma receita líquida superior a R$ 30 bilhões, no segundo trimestre de 2012.

Figura 18: Consolidação do mercado brasileiro de Telecomunicações

60

Nesse cenário, o aumento de receita proveniente da oferta de serviços convergentes, como valor agregado, é determinante para a sobrevivência das empresas, e um bom exemplo disso é a oferta de serviço de armazenamento em nuvem. Cientes dessa realidade, quatro dos principais grupos citados, incluíram recentemente o produto cloud computing em seus portfólios, especialmente voltado para o mercado corporativo, conforme abaixo:
Tabela 6: Produtos cloud-computing ofertados por Operadoras de Telecomunicações Produto CloudComputing Oi Smart Cloud TIM Cloud Vivo Cloud Plus Ainda sem nome Data de lançamento fev/12 mar/12 abr/12 set/12 Investimento Anunciado R$ 30 milhões Não revelado Não revelado R$ 100 milhões

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

Além da receita proveniente dos serviços de valor agregado, outro aspecto importante a ser observado em mercados de concorrência acirrada como o de telecomunicações é a maximização do uso dos recursos disponíveis, uma vez que se trata de um setor com necessidade de investimento massivo e inovação tecnológica constante. Entretanto, os quatro grupos que anunciaram o lançamento do serviço de armazenamento destacaram o investimento na aquisição de novos datacenters, ou na ampliação dos existentes. Paradoxalmente, tanto o Grupo Oi - que anunciou o investimento de R$ 30 milhões, quanto o Grupo Telmex – cujo investimento é da ordem de R$ 100 milhões, para ampliação da capacidade de armazenamento demandada pelo novo produto, não consideraram o uso do parque disponível nas empresas de Callcenter que detém. Segundo o portal www.callcenter.inf.br [35], a subsidiária Contax, do Grupo Oi, possui um parque instalado de 48.233 posições de atendimento, enquanto a subsidiária BrasilCenter, da Embratel (Grupo Telmex), opera um parque de 3.950 posições de atendimento. Caso fosse considerado o uso de apenas 1 GB de armazenamento em cada posição de atendimento, teríamos uma capacidade de 47,1 TB de armazenamento disponível na Contax e 3,85 TB na BrasilCenter, respectivamente. Ainda segundo esse portal, nos Callcenters brasileiros existe um parque total de 232 mil posições de atendimento, que, seguindo o raciocínio anterior, representam uma capacidade de 226,5 TB de armazenamento ocioso. Levando em consideração a baixa demanda

61

de armazenamento nos desktops usados nessas posições de atendimento, é possível que esse número seja ainda bem maior e a capacidade ociosa atinja a ordem de grandeza de petabytes.2 Diante dos números apresentados, fica evidente o grande potencial que um sistema de armazenamento distribuído, utilizando recursos ociosos, em dispositivos não dedicados a armazenamento, representa para as Operadoras de Telecomunicações. Outro aspecto que reforça essa possibilidade é o fato dessas Operadoras já possuírem toda a infra-estrutura de transmissão instalada, entre os prédios onde esses Callcenters operam e o núcleo de suas redes, conforme apresentado na Figura 11 (página 49). Dessa forma, basta apenas ampliar a capacidade desses sistemas para suportar o tráfego gerado por esse serviço, conforme será detalhado no tópico a seguir.

5.2 Dimensionamento da Capacidade de armazenamento
Com a experimentação prática realizada a partir de um protótipo do sistema de armazenamento distribuído proposto (Capítulo 4) temos a base para o dimensionamento completo do sistema e a arquitetura final da solução. Através do protótipo, inferiu-se que para cada link de 1 Gbps entre a Operação de Callcenter – onde estarão os peers de armazenamento, e o core de rede da Operadora – onde estarão conectados os peers de carga, temos uma banda líquida disponível de 666 Mbps. Com isso, para dimensionarmos a capacidade de armazenamento, em bytes, que cada link desses pode cursar simultaneamente, basta multiplicar essa banda líquida (onde foi descontada a perda devido ao overhead de controle da aplicação) pelo tempo médio teórico de transferência em uma aplicação P2PSS, conforme equação ( i ) abaixo: Ca (byte) = (Tl (bps) x Ts) / 8 Onde: Ca (byte) = Tl (bps) = Ts segundos.
2

(i)

Capacidade de armazenamento, em bytes; Taxa líquida do link de entroncamento, em bits por segundo; Tempo teórico de transferência em uma aplicação 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 transferência em uma aplicação P2PSS. Por apresentar características de controle idênticas 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 teórico da transferência de dados, nesse estudo de caso. A partir da implementação do processo de download e recovery no simulador NS-2 [37], os pesquisadores avaliaram o tempo de transferência sob diversas condições: diferentes topologias de rede, heterogeneidade dos peers, diferentes tempos de propagação e processos de controle (centralizado e distribuído). A figura abaixo apresenta de forma resumida a arquitetura do simulador utilizado, onde foi utilizada a versão 2.33 do NS-2 e realizadas algumas modificações nos arquivos node.cc, node.h, agent.cc, agent.h, tcp-full.cc.

Figura 19: Arquitetura do simulador usado como benchmark do tempo teórico de transferência (Autor: Dandoush [36])

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

63

Tabela 7: Setup do experimento usado como benchmark do tempo teórico de transferência

A partir dessa escolha, na Tabela 8, temos o resultado do tempo médio de transferência nesse experimento, onde se observa o tempo de 105,254 segundos, sendo esse o valor utilizado para o dimensionamento proposto na equação ( 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 máxima de armazenamento simultâneo igual de 8,55 GB, considerando o overhead do sistema de controle descrito no Projeto USTO.RE e o tempo de transferência proposto pelo benchmark utilizado. Considerando um fator de utilização empírico de 5% ou seja, em média, 1 a cada 20 usuários irá armazenar ou recuperar os dados simultaneamente, tem-se uma capacidade final de armazenamento igual a 171 GB, para cada link de interligação de 1 Gbps.
Tabela 8: Sumário dos resultados do simulador usado como benchmark

(i)

64

5.3

Arquitetura Final da Solução

A partir dos resultados obtidos na seção anterior, podemos detalhar a arquitetura do serviço Cloud Storage por uma Operadora, proposta na figura 6 (página 37), descrevendo as tecnologias utilizadas em cada subsistema, os padrões de interligação entre eles e a capacidade final da solução. Com isso, tem-se a descrição necessária para orientar os futuros Projetos que adotem a tecnologia proposta por essa pesquisa, cuja viabilidade econômica será comprovada na seção seguinte. Partindo-se da premissa de utilização da capacidade de transmissão existente, sobretudo o entroncamento óptico entre os prédios da Operação do Callcenter - onde estão as Posições de Atendimento (PAs) e do núcleo de rede da Operadora - recomenda-se a implantação de um novo nó de multiplexação digital. É importante ressaltar que na arquitetura proposta, as PAs funcionarão como peers de armazenamento e os hosts interligados ao núcleo de rede da Operadora (os clientes finais) serão os peers de carga. Como a arquitetura é baseada no padrão Gigabit Ethernet (IEEE 802.3ab) para interligação das LAN’s (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 padrões, o transporte de pacotes IP, encapsulados em quadros ethernet, com marcação de VLAN (IEEE 802.1q), no meio óptico existente, conforme Figura 20 abaixo.

Figura 20: Flexibilidade do padrão SDH-NG (Fonte: Trend Communications)

65

A flexibilidade da tecnologia SDH-NG para o transporte de pacotes IP ocorre graças ao protocolo GFP (Generic Framing Protocol). Definido pela norma ITU-T G.7041, esse padrão provê adaptação da taxa de dados e mapeamento dos mesmos na estrutura STM-n do padrão SDH, que em seguida são 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 utilização do meio óptico, aumentando assim a capacidade de transmissão e, conseqüentemente, de armazenamento da solução, a tecnologia SDH-NG permite a concatenação de vários 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 concatenação, no SDH-NG (Fonte: Trend Communications)

Graças 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 seção 5.2, equação ( i ). Com isso, seguindo o modelo de referência OSI, os padrões que compõe a arquitetura final da solução proposta é descrito na Figura 23, onde temos nas camadas superiores o protocolo HTTP na camada de aplicação, o padrão XML para apresentação dos dados, conforme definido pelo padrão JXTA, descrito na camada de sessão. As demais camadas descrevem o protocolo TCP na camada de transporte e os padrões IP, Ethernet e SDH-NG, nas camadas de rede, sessão e física, respectivamente.

Figura 23: Padrões que compõe a solução proposta

5.4 Estudo da viabilidade econômica da Solução
Como contribuição final do estudo de caso proposto nessa pesquisa, temos a avaliação da viabilidade econômica da solução. Para tal, será estimado o investimento inicial para implementação da solução, adotando-se os padrões descritos na seção anterior e utilizando-se valores de mercado para ampliação da capacidade de transmissão nos equipamentos. Em seguida, partindo-se da comparação média dos valores praticados pelos principais produtos de armazenamento disponíveis no mercado, será inferida a receita mensal do produto, de acordo

67

com a capacidade de armazenamento calculada (6.840 GB). Por fim, serão utilizados os métodos do Valor Presente Líquido (VPL), da Taxa Interna de Retorno (TIR) e do Payback, para comprovação da viabilidade econômico-financeira da solução proposta. Considerando a utilização da capacidade de transmissão já existente entre os subsistemas de armazenamento e carga (Contact Center e Operadora, respectivamente), o investimento inicial ( I0 ) necessário consiste apenas na ampliação de multiplexadores e demultiplexadores SDH-NG existentes, com placa STM-256 (40 Gbps) no entroncamento e portas Gigabit Ethernet (padrão 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 adequação. O próximo passo é inferir a receita mensal que a capacidade de 6.840 GB irá gerar para a Operadora. Na Tabela 9, extraída do site www.tecmundo.com.br [47], temos a comparação de preço dos principais serviços de armazenamento existentes no mercado. Nessa pesquisa, será considerada a média dos valores como valor mensal a ser pago, ou seja, R$ 0,35 por GB armazenado.
Tabela 9: Comparativo de preço entre os principais serviços de armazenamento existentes Serviço Google Drive Dropbox Ubuntu One Preço por GB (R$) R$ 0,18 R$ 0,36 R$ 0,25 iCloud R$ 0,30 Box SugarSync Média 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 correção monetária de 6% ao ano, considerando a taxa oficial de inflação registrada nos anos anteriores.
Tabela 10: Fluxo de caixa anual gerado pelo serviço 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, serão utilizados métodos do Valor Presente Líquido, da Taxa Interna de Retorno e do Payback. a) Valor Presente Líquido (VPL): Também conhecido como Valor Atual Líquido (VAL) ou método do valor atual, é a fórmula matemático-financeira capaz de determinar o valor presente de pagamentos futuros descontados a uma taxa de juros apropriada – também chamada de Taxa Mínima de Atratividade (TMA), subtraído do custo do investimento inicial. Em termos práticos, um dado Projeto é considerado viável, caso apresente um VPL > 0, em um período pré-determinado, normalmente 5 anos, a uma Taxa Mínima de Atratividade superior às taxas praticadas pelo mercado financeiro. O mesmo pode ser expresso pela fórmula abaixo: VPL = ∑ Onde: FCt i t I0 = = = = Fluxo de Caixa no período t ; Taxa Média de Atratividade; Quantidade de tempo, em anos; Investimento inicial no Projeto.

Aplicando esse método 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 viável e apresenta uma taxa de retorno superior ao praticado no mercado de telecomunicações. b) Taxa Interna de Retorno (TIR): Conceito proposto pelo economista John Maynard Keynes (1883 - 1946), esse método de análise de investimento propõe uma taxa de desconto hipotética 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, também trazidos ao valor presente. Em outras palavras, é uma taxa complementar a análise do VPL, que expressa a taxa de retorno de um determinado Projeto.

69

Aplicando esse método ao Projeto em análise, obtém-se um TIR igual a 35%, no período de 5 anos, que ratifica a viabilidade economico-financeira do Projeto, uma vez que essa taxa é superior ao padrão encontrado no mercado de telecomunicações. c) Payback É o tempo decorrido entre o investimento inicial e o momento no qual o lucro líquido acumulado se iguala ao valor desse investimento. Trata-se de uma técnica de análise de

investimento alternativas ao método do Valor presente líquido (VPL), levando em conta apenas o prazo de retorno do investimento, sendo calculada pela divisão do investimento inicial pelas entradas médias de caixa. No Projeto em questão, 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 matemático para avaliação de viabilidade da solução
Além do setor de telecomunicações, utilizado como referência no estudo de caso dessa pesquisa, para avaliação de viabilidade do serviço cloud storage proposto, outros segmentos econômicos também podem se valer da solução proposta para geração de receita a partir de recursos a partir de recursos ociosos em seus parques computacionais. Empresas como concessionárias públicas e privadas de água e luz, operadoras de cartões de crédito e grandes redes varejistas são alguns exemplos onde tal serviço pode ser viável. De modo a subsidiar a decisão em adotar a proposta apresentada nessa pesquisa, será apresentado um modelo matemático, a partir da aplicação da equação da Capacidade de armazenamento (Ca), descrita pela equação ( i ) no tópico 5.2, na equação do Valor Presente Líquido (VPL), sendo observado o valor resultante. Caso a expressão resultante, apresente um VPL > 0, a adoção do projeto será considerado viável, enquanto para um VPL considerado inviável. Sabendo que o VPL é dado pela expressão: 0 o mesmo será

70

VPL = ∑

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

E que FCt denota o Fluxo de Caixa em função do tempo t, para {t pode ser substituído pela expressão: FCt = Ca (byte) / Fu Onde: (2)

Fu é igual ao Fator de utilização da aplicação, ou seja, a relação de acessos simultâneos em função do número total de usuários do sistema; Ca (byte) é igual a Capacidade de Armazenamento em função da largura de banda do uplink de conexão à rede pública e pode ser descrito por: Ca (byte) = (Tl (bps) x Ts) / 8 Sendo: Ts igual ao tempo médio de transferência do serviço Cloud Storage, em segundos; Tl (bps) igual à taxa líquida do link de entroncamento, em bits por segundo, ou seja: Tl (bps) = BW / O (4) (3)

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

Por fim, aplicando a expressão ( 5 ) em ( 1 ) temos o modelo matemático para avaliação de viabilidade da solução, em função das características de tráfego do serviço e do retorno econômico-financeiro da solução: VPL = ∑ 0, , á á

71

5.6 Sumário do capítulo
Nesse capítulo, foi contextualizada a necessidade do setor brasileiro de telecomunicações em oferecer serviços de valor agregado, como o serviço de armazenamento em nuvem. Para tal, foi apresentada a possibilidade de utilização de recursos de armazenamento ociosos e distribuídos em Posições de Atendimento dos contact centers de empresas subsidiárias desses players, o que atualmente corresponde a um parque de 232 mil estações. Nessa arquitetura, é imprescindível avaliar a capacidade de armazenamento que pode ser ofertada. Para tal, foi apresentado estudo a partir das métricas tráfego observado em um protótipo, e de tempo de transferência introduzidas por um simulador, resultando na capacidade de armazenamento de 6.840 GB, usando uma capacidade de transmissão igual a 40 Gbps, utilizando-se a tecnologia SDH-NG sob o meio óptico existente. Após a descrição final da arquitetura avaliada, seguindo o modelo de referência OSI, foi comprovada a viabilidade econômico-financeira do Projeto, através dos métodos do Valor Presente Líquido, Taxa Interna de Retorno e Payback. Por fim, a partir do estudo de caso baseado no mercado brasileiro de telecomunicações, foi descrito um modelo matemático para avaliação de viabilidade da solução. Esse modelo visa subsidiar a decisão de lançamento do serviço cloud storage utilizando recursos ociosos por quaisquer empresas, de todos os segmentos econômicos, utilizando quaisquer plataformas de gerenciamento e controle, desde que sejam conhecidas as variáveis de tráfego da solução e o investimento inicial necessário.

72

6 CONSIDERAÇÕES FINAIS

A utilização de recursos de armazenamento ocioso, em desktops utilizados como Posições de Atendimento de um Callcenter, mostrou-se uma solução viável, escalável e de baixo investimento inicial. Com isso foi proposta uma nova alternativa às Operadoras de Telecomunicações que detém a operação de tais contact centers, ou para quais empresas que detenham recursos de armazenamento ocioso em seus desktops, para geração de valor através da oferta do serviço de armazenamento em nuvem. Tal proposta consiste em uma alternativa para o ingresso no mercado de computação em nuvem. Mercado esse que se encontra em plena expansão, devendo atingir a casa de 241 bilhões de dólares em 2020. Analisando-se isoladamente o mercado brasileiro de telecomunicações, o ingresso nesse mercado representa uma grande oportunidade, tendo em vista a acirrada competição e o declínio de receita nos serviços tradicionais, como a telefonia fixa. No contexto atual, a expansão de receita para as operadoras de telecomunicações ocorrerá na expansão do market share de serviços com baixa penetração, como a TV por assinatura, ou na oferta de novos serviços de valor agregado, como o armazenamento em nuvem. Esse fato fica evidenciado nos anúncios recentes de serviços Cloud Storage, por quatro dos maiores conglomerados de telecomunicações. Por fim, essa pesquisa propõe uma arquitetura inovadora, baseada em estudos recentes sobre sistemas de armazenamento distribuído que utilizam recursos não dedicados. Para validar tal proposta, foi descrito um estudo de caso - baseando no cenário de uma operadora de telecomunicações - e apresentado um modelo matemático para avaliação de viabilidade da solução proposta. Esse modelo, que considera variáveis de tráfego e o investimento inicial necessário para oferta do serviço Cloud Storage, pode ser utilizado para o desenvolvimento de pesquisas futuras e por agentes decisórios das empresas que pretendam entrar no mercado de armazenamento como serviço, utilizando recursos de armazenamento ociosos.

73

6.1 Trabalhos relacionados
Conforme exposto nesse trabalho, várias pesquisas vêm se destacando no tocante aos sistemas de armazenamento distribuídos, quer do ponto de vista de controle, como os Projetos GFS [24], Campus Cloud [25] e USTO.RE [26], utilizado como testbed dos experimentos práticos aqui apresentados, quer do ponto de vista do uso de recursos não dedicados, conforme proposto pelos pesquisadores Andrzejak, Kondo e Anderson [2], ou ainda na análise e simulação de tráfego, conforme proposto pelos pesquisadores Drago, Mellia e Munafò [32] e Alouf, Dandoush e Nain [36] [38].

6.2 Resumo das contribuições
A seguir é apresentado um resumo das principais contribuições deste trabalho: • Definição das variáveis a serem consideradas para o dimensionamento da capacidade de armazenamento em função das características de tráfego em sistema de armazenamento distribuído usando recursos ociosos; • Introdução de micro-segmentação através de VLANs em um sistema de armazenamento P2P, garantindo a transparência dessa aplicação em relação às pré-existentes na rede local; • • Descrição de uma arquitetura para exploração do serviço Cloud Storage utilizando recursos de armazenamento ociosos por uma Operadora de Telecomunicações; Apresentação de um modelo matemático para avaliação de viabilidade econômicofinanceira da solução de armazenamento distribuído proposta.

6.3 Trabalhos futuros
Dentre as características da arquitetura proposta que precisam ser evoluídas, do ponto de vista do sistema e da pesquisa, temos: • A necessidade de evolução do protótipo no que se refere à redução do overhead de controle, maximizando a capacidade de armazenamento e a rentabilização do Projeto;

74

• • •

Elaboração e implementação de mecanismo de adaptação da fragmentação em função do tamanho do arquivo a ser armazenado; Avaliação do impacto da replicação, no consumo de banda e de processamento da LAN de armazenamento, tornando o sistema o mais transparente possível a esse ambiente; Criação de mecanismos de priorização de tráfego entre usuários, de modo a permitir a diferenciação de preço no serviço ofertado.

75

7 REFERÊNCIAS

[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 HotP2P’09, 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. disponível 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 Distribuído 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”, O´Reilly 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”. IMC’12, November 14–16, 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.