estudo da viabilidade de um serviço de cloud storage, utilizando recursos ociosos, por uma...

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.

Universidade Federal de Pernambuco

[email protected] www.cin.ufpe.br/~posgraduacao

RECIFE, JANEIRO/2013

Por

Hilson Gomes Vilar de Andrade

Dissertação de Mestrado

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-to-

peer 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 Contextualização ......................................................................................................... 11

1.2 Objetivos ..................................................................................................................... 13

1.2.1 Objetivos Gerais ...................................................................................................... 13

1.2.2 Objetivos Específicos .............................................................................................. 14

1.3 Organização da Dissertação ........................................................................................ 14

2 SISTEMAS DE ARMAZENAMENTO DISTRIBUÍDO ..................................................... 16

2.1 Principais arquiteturas P2P ......................................................................................... 18

2.1.1 Arquiteturas puras ................................................................................................... 19

2.1.2 Arquiteturas híbridas ............................................................................................... 21

2.2 Plataforma JXTA......................................................................................................... 21

2.2.1 Arquitetura JXTA .................................................................................................... 22

2.2.2 Funcionamento de um sistema baseado em JXTA ................................................. 23

2.3 Principais frameworks Cloud Storage ......................................................................... 33

2.3.1 GFS .......................................................................................................................... 33

2.3.2 Campus Cloud ......................................................................................................... 35

2.3.3 Projeto USTO.RE .................................................................................................... 36

2.4 Sumário do Capítulo.................................................................................................... 37

3 ARQUITETURA USTO.RE ................................................................................................. 38

3.1 Descrição do sistema ................................................................................................... 39

3.2 Descrição dos Componentes e serviços ...................................................................... 40

3.2.1 Super peers .............................................................................................................. 40

3.2.2 Servidores ................................................................................................................ 41

8

3.2.3 Proxies ..................................................................................................................... 43

3.2.4 Simple peers ............................................................................................................. 43

3.3 Sumário do capítulo .................................................................................................... 47

4 ANÁLISE DE TRÁFEGO DO PROTÓTIPO ...................................................................... 48

4.1 Definição dos objetivos e métricas.............................................................................. 48

4.2 Resultados Obtidos ...................................................................................................... 51

4.2.1 Cenário I .................................................................................................................. 51

4.2.2 Cenário II ................................................................................................................. 54


5 ESTUDO DE CASO ............................................................................................................. 59

5.1 Serviço Cloud-Computing nas Operadoras de Telecomunicações ............................. 59

5.2 Dimensionamento da Capacidade de armazenamento ............................................... 61

5.3 Arquitetura Final da Solução....................................................................................... 64

5.4 Estudo da viabilidade econômica da Solução ............................................................. 66

5.5 Modelo matemático para avaliação de viabilidade da solução ................................... 69


6 CONSIDERAÇÕES FINAIS ................................................................................................ 72

6.1 Trabalhos relacionados ................................................................................................ 73

6.2 Resumo das contribuições ........................................................................................... 73

6.3 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ômico-

financeira 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-a-

Service), 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

desenvolvem estruturas de controle centralizadas e a utilização de recursos descentralizados.

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

De acordo com Schollmeier e

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

Esta localização é feita fazendo uso d

enviada a todos os computadores diretamente ligados ao emissor

mensagem faz o mesmo. Para evitar que a rede entre em colapso (

atribuído a mensagem para que caso

negativos aqui são:

• 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 a

máquina de destino.

Para melhor ilustrar o funcionamento,

busca em execução. É possível perceber

recebida devido a limitações no tempo d

Figura 3: Exemplo de requisição usando a técnica de

uras de controle centralizadas e a utilização de recursos descentralizados.


pode acompanhar na sessão seguinte.

Arquiteturas puras

De acordo com Schollmeier e Rudiger [8], as redes denominadas puras possuem como principal


com uso de um algoritmo descentralizado onde é possível localizar peers

é feita fazendo uso da técnica de enchente (flooding

omputadores diretamente ligados ao emissor e cada máquina

. Para evitar que a rede entre em colapso (loop

para que caso esta não chegue a seu destino seja descartada

lgumas máquinas podem não receber a mensagem, negando assim um serviço

disponível em tese;

Há um grande volume de mensagens enviadas até que a mesma encontre a

máquina de destino.

Para melhor ilustrar o funcionamento, é possível visualizar na

É 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.

Exemplo de requisição usando a técnica de flood (Autor: M. P. Duarte.

19

uras de controle centralizadas e a utilização de recursos descentralizados.


s redes denominadas puras possuem como principal


peers e/ou serviços.

flooding), onde a mensagem é

e cada máquina que recebe a

loop), um tempo de vida é

não chegue a seu destino seja descartada. Os pontos

lgumas máquinas podem não receber a mensagem, negando assim um serviço

té que a mesma encontre a

na Figura 3 o algoritmo de

que algumas máquinas não repassam a mensagem

M. P. Duarte.[26])

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 desempenho, escalabilidade, confiabilidade e

disponibilidade.

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 infra-

estrutura 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) Super Peers Rendezou Relay ou Super Peers;

(ii) Servidores;

(iii) Proxies;

(iv) Banco de Dados Relacionais e Não-SQL;

(v) 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

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

Goal 1: Redução do

tempo de armazenamento

Question: Qual a configuração

de chunk apresenta o

armazenamento mais rápido?

Metric: Tempo de

armazenamento (s)

Question: Qual a configuração

de fila apresenta o

armazenamento mais rápido?

51

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

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 (%)

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 Chunks (KB) Fila Fila Total (KB) Tempo (s) Tráfego médio (Mbps) 1 32 6 192 1130 7,25 2 32 8 256 893 9,17 3 32 10 320 723 11,33 4 64 6 384 615 13,32 5 64 8 512 452 18,12 6 64 10 640 346 23,68 7 128 6 768 294 27,86 8 128 8 1024 188 43,57 9 128 10 1280 200 40,96

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

7,259,17

11,3313,32

18,12

23,68

27,86

43,57

40,96

1 2 3 4 5 6 7 8 9

Tráfego médio (Mbps)

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 Armazenados

(MB)

Dados Armazenados

(bits)

Total bits no entroncamento (input ou

output)

Overhead [ (total bits - bits armazenados) / bits

armazenados)]

1024 8589934592 12829067313 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.


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

Grupo Produto Cloud-

Computing Data de

lançamento Investimento Anunciado Fonte

Oi Oi Smart Cloud fev/12 R$ 30 milhões https://loja.oismartcloud.com.br TIM TIM Cloud mar/12 Não revelado http://exame.abril.com.br

Telefonica Vivo Cloud Plus abr/12 Não revelado http://www.tiinside.com.br Telmex Ainda sem nome set/12 R$ 100 milhões 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 ( i )

Onde: Ca (byte) = Capacidade de armazenamento, em bytes;

Tl (bps) = Taxa líquida do link de entroncamento, em bits por segundo;

Ts = Tempo teórico de transferência em uma aplicação Cloud Storage, em

segundos.

2 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 ( i )

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

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 iCloud Box SugarSync Média Preço por GB (R$) R$ 0,18 R$ 0,36 R$ 0,25 R$ 0,30 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 Valor 1 R$ 28.728,40 2 R$ 30.451,64 3 R$ 32.278,78 4 R$ 34.215,51 5 R$ 36.268,44

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 = Fluxo de Caixa no período t ;

i = Taxa Média de Atratividade;

t = Quantidade de tempo, em anos;

I0 = 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 � 0 o mesmo será

considerado inviável.

Sabendo que o VPL é dado pela expressão:

70

VPL = ∑ ��

��

E que FCt denota o Fluxo de Caixa em função do tempo t, para {t � R / 1 � t < n}, e

pode ser substituído pela expressão:

FCt = Ca (byte) / Fu ( 2 )

Onde:

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 ( 3 )

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 )

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, #$%&'�% (á*'+ � �, #$%&'�% ��*á*'+,

( 1 )

71


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ômico-

financeira 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] http://computerworld.uol.com.br/tecnologia/2008/03/13, acessado em 11/10/2012.

[2] 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] Amazon Inc., “Elastic compute cloud”, 2008. http://aws.amazon.com/ec2.

[6] Amazon Inc., “Simple Storage Service”, 2009. http://www.amazon.com/s3/.

[7] 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.187-

200,

[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-to-

peer 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 calable content-

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.

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.

estudo da viabilidade de um serviço de cloud storage, utilizando recursos ociosos, por uma...

Documents