pós-graduação em ciência da computação · big data, normalmente é bem mais densa e crítica...

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

TÁRCIO NOVAIS OLIVEIRA LUNA

Zona Desmilitarizada Científica, análise e

otimização de fluxos em uma rede

acadêmica multiúso. Um estudo de caso

no Instituto Federal de Pernambuco.

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE

2017

TÁRCIO NOVAIS OLIVEIRA LUNA

Zona Desmilitarizada Científica, análise e otimização de fluxos emuma rede acadêmica multiúso. Um estudo de caso no Instituto

Federal de Pernambuco.

Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação doCentro de Informática da Universidade Fe-deral de Pernambuco como requisito parcialpara obtenção do grau de Mestre Profissio-nal em Ciência da Computação.

Orientador: Kelvin Lopes Dias

Recife2017

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

L961z Luna, Tárcio Novais Oliveira

Zona desmilitarizada científica, análise e otimização de fluxos em uma rede acadêmica multiúso. Um estudo de caso no Instituto Federal de Pernambuco / Tárcio Novais Oliveira Luna. – 2017.

78 f.:il., fig., tab. Orientador: Kelvin Lopes Dias. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências, apêndices e anexos.

1. Redes de computadores. 2. Rede multiúso. I. Dias, Kelvin Lopes (orientador). II. Título. 004.6 CDD (23. ed.) UFPE- MEI 2017-171

Tárcio Novais Oliveira Luna

Zona Desmilitarizada Científica, análise e otimização de fluxos em uma rede acadêmica multiúso. Um estudo de caso no Instituto

Federal de Pernambuco

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 26 de junho de 2017.

BANCA EXAMINADORA

_____________________________________________ Prof. Vinícius Cardoso Garcia Centro de Informática / UFPE

__________________________________________

Prof. Andson Marreiros Balieiro Universidade de Pernambuco

__________________________________________ Prof. Kelvin Lopes Dias

Centro de Informática / UFPE (Orientador)

Aprovado em: 26 / 06 / 2017.

Dedico este trabalho aos meus colegas de curso e a todos que me ajudaram dealguma maneira na conclusão deste objetivo.

Agradecimentos

Agradeço especialmente a paciência e compreensão da minha esposa Kira,nosso gato Keef, pela companhia durante os dias e noites de escrita. Ao meu orientadorKelvin, que teve toda paciência e atenção durante as reuniões de orientação. E agradeçoprincipalmente aos meus pais, Luna e Irailde, que sem eles eu não teria chegado tãolonge.

“for technology, every day is a working day”Bruno Latour (1996)

Resumo

O tráfego das redes acadêmicas é composto por fluxos de dados distintos.Desde o acesso a e-mail, ferramentas de Educação a Distância (EAD), sistemaspara Enterprise Resource Planning (ERP), como também grandes volumes de dadosprovenientes de laboratórios de pesquisas. Toda essa diversidade de dados são fluxoscom prioridades diferentes e que compartilham a mesma infraestrutura multiúso. Re-centemente, tivemos o surgimento da Zona Desmilitarizada Científica (Science DMZ),projeto da Energy Science Network (ESNet) que consiste numa rede otimizada paratransferência de dados científicos entre instituições de pesquisa. Essa grande massade dados científicos não tratada gerada pelas pesquisas científicas, conhecida comoBig Data, normalmente é bem mais densa e crítica do que o tráfego de uma redeacadêmica comum. O Instituto Federal de Educação, Ciência e Tecnologia de Pernam-buco (IFPE), por ter os seus pilares fincados na pesquisa e inovação, fez uma parceriacom a Rede Nacional de Pesquisa (RNP) para implantação da DMZ Científica quedesse suporte as novas necessidades das pesquisas realizadas no Campus Recife, emconjunto com outras instituições. Contudo, a implantação de uma Science DMZ requerplanejamento e depende não só da análise da infraestrutura, mas também do perfil detráfego de cada instituição. Além disso, uma vez implantada, é necessário que o ambi-ente seja continuamente monitorado, visando garantir o Quality Of Service (QoS) dosusuários convencionais, bem como, das transferências de grandes volumes de dadosdas aplicações científicas. Por isso essa pesquisa tem como objetivo mostrar atravésda metodologia Plan - Do - Check - Act (PDCA), fundamentada em informações co-letadas através da ferramenta de monitoramento perfSONAR, a otimização da redemultiúso do IFPE e o desenvolvimento de uma técnica baseada em Software DefinedNetworking (SDN) que encaminhará o fluxo científico local diretamente a ScienceDMZ. Apresentaremos, através da análise de informações, o comportamento dessefluxo de dados científico antes e depois das otimizações. Princípios importantes da TIVerde também foram levados em consideração durante esse trabalho, já que todos osdispositivos utilizados nesta pesquisa estavam em desuso. Nesse estudo, aumentamoso ciclo de vida desses equipamentos que não eram mais utilizados, evitando assimaquisições de novos equipamentos e o descarte prematuro. Considerando a limitaçãoorçamentária do serviço público e a ausência de um investimento imediato, foi possívelotimizar a vazão do fluxo científico em cerca de 40% e gerar uma economia de R$38.227,65, utilizando equipamentos em desuso para trafegar dados de pesquisas cien-tíficas; sem prejuízo para os demais utilizadores dessa infraestrutura.

Palavras-chave: Instituto Federal de Educação, Ciência e Tecnologia de Pernambuco.Zona Desmilitarizada Científica. Redes Definidas por Software. Big Data. Rede Multiúso.

Abstract

The traffic from the academic networks is composed by distinct data flows. Sincethe access to e-mails, e-learning tools, Enterprise Resource Planning (ERP) systems,to large volumes of data which comes from research labs. All this diversity of data areflows with different priorities that share the same multipurpose infrastructure. Recently,we had the emerging of the Science Demilitarized Zone (Science DMZ), a projectfrom the Energy Science Network (ESNet) which consists in an optimized network totransfer data between research institutions. This large mass of scientific non-treateddata generated by scientific researches, known as Big Data, normally is much denserand critic comparing to the traffic of an ordinary academic network. The Federal Instituteof Education, Science and Technology of Pernambuco (IFPE), for having its pillarsfocused on research and innovation, made a partnership with the National ResearchNetwork (RNP) to the implantation of the Science DMZ to support the new necessitiesof the researches done at Campus Recife, in addition to other institutions. Nevertheless,the implantation of a Science DMZ demands planning and depends on not only from theinfrastructures analyses, but also from the traffic profile of each institution. Besides ofthat, once implanted, is vital that the environment is continuously monitored, aiming toensure the Quality Of Service (QoS) of the conventional users, as well as, the transfersof the large volumes of data from the scientific applications. Therefore, this paperaims to show through the methodology Plan - Do - Check - Act (PDCA), based onthe information collected via the monitoring tool perfSONAR, the optimization of themultipurpose network from the IFPE and the development of a technique based on theSoftware Defined Networking (SDN) which will route the local scientific flow directly tothe Science DMZ. We will present, through the information analysis, the behavior ofthese flows of scientific data before and after the optimizations. Important principlesof Green IT were also taken into consideration during these research, once all thedisposables used in this research were in disuse. In this paper, we raised the cycleof life of these equipment which were no longer used, avoiding new acquisition andpremature discard. Considering the budget limitation of the public services and absenceof an immediate investment, it was possible to optimize the output of the scientific flowin 40% and generate an economy of R$ 38.227,65, utilizing equipment in disuse totraffic scientific research data; with no prejudice to other users of this infrastructure.

Keywords: Federal Institute of Education, Science and Technology of Pernam-buco. Science Demilitarized Zone. Software Defined Networking. Big Data. MultipurposeNetwork.

Lista de Figuras

Figura 1 – Rede multiúso com tráfego variado e vários pontos de atraso. . . . . 21Figura 2 – Impacto causado pelo Firewall em uma transmissão de arquivo. . . 22Figura 3 – Camadas SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 4 – Abordagem tradicional (A) contra uma abordagem SDN (B). . . . . . 24Figura 5 – Funcionamento básico de uma rede SDN. . . . . . . . . . . . . . . . 25Figura 6 – Rede de campus sem a Zona Desmilitarizada Científica. . . . . . . . 31Figura 7 – Rede de campus com a Zona Desmilitarizada Científica. . . . . . . . 32Figura 8 – Fluxograma com as atividades de otimização. . . . . . . . . . . . . . 41Figura 9 – Nós perfSONAR coletando informações do ambiente de rede. . . . 42Figura 10 – Modelo de Arquitetura Proposto. . . . . . . . . . . . . . . . . . . . . 46Figura 11 – Fluxo normal até a DMZ Científica. . . . . . . . . . . . . . . . . . . . 51Figura 12 – Resultado do comando tracepath partindo do pesquisador. . . . . . 52Figura 13 – Tráfego redirecionada através do nó SDN. . . . . . . . . . . . . . . . 57Figura 14 – Resultado do comando tracepath com apenas dois saltos. . . . . . . 59

Lista de gráficos

Gráfico 1 – Vazão de dados do pesquisador até a Science DMZ. . . . . . . . . 53Gráfico 2 – Latência do pesquisador (bloco A) até o Core. . . . . . . . . . . . . 54Gráfico 3 – Latência do Core até a Wan. . . . . . . . . . . . . . . . . . . . . . . 54Gráfico 4 – Latência da Wan até a DMZ Científica. . . . . . . . . . . . . . . . . 55Gráfico 5 – Vazão entre pesquisador e DMZ científica passando pelo nó SDN. 60Gráfico 6 – Vazão por Cenário. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Gráfico 7 – Latência por Cenário. . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Lista de diagramas

Diagrama 1 – Estado atual do fluxo na rede. . . . . . . . . . . . . . . . . . . . . 48Diagrama 2 – Nó SDN fazendo o “bypass” do fluxo. . . . . . . . . . . . . . . . . 49

Lista de Tabelas

Tabela 1 – Exemplos de Big Data. . . . . . . . . . . . . . . . . . . . . . . . . . 28Tabela 2 – Principais práticas de TI Verde adotadas pelas organizações . . . . 36Tabela 3 – Tabela de requisitos para o Cenário 01. . . . . . . . . . . . . . . . . 50Tabela 4 – Tabela de requisitos para o Cenário 02 . . . . . . . . . . . . . . . . 58Tabela 5 – Coleta manual da latência através do comando tracepath. . . . . . . 61Tabela 6 – Coleta manual da latência através do comando tracepath no Cenário

01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Tabela 7 – Quantidade de saltos por Cenário. . . . . . . . . . . . . . . . . . . . 63

Lista de abreviaturas e siglas

API Application Programming Interface

BWCTL Bandwith Test Controller

CERN Conseil Européen pour la Recherche Nucléaire

DMZ Desmilitarized Zone

DTN Data Transfer Node

EaD Educação a Distância

EMC Egan Marino Corporation

ERP Entrerprise Resource Planning

ESNET Energy Sciences Network

EUA United States of America

FDT Fast Data Transfer

FTP File Transfer Protocol

HD Hard Disk

ICMP Internet Control Message Protocol

IDC International Data Corporation

IDS Intrusion Detection System

IETF Internet Engineering Task Force

IFPE Instituto Federal de Educação, Ciência e Tecnologia de Pernambuco

IOT Internet Of Things

IP Internet Protocol

IPPM IP Performance Metrics

IPS Intrusion Prevention System

LAN Local Area Network

LCD Liquid Crystal Display

LHC Large Hádrons Collider

LTE Long Term Evolution

MTU Maximum Transmission Unit

NAT Network Address Translation

NTP Network Time Protocol

ONF Open Network Foudation

PDCA Plan, Do, Check and Act

POP Point Of Presence

QoS Quality of Service

RAM Random Access Memory

REST Representational State Transfer

RFC Request For Comments

RFID Radio-Frequency Identification

RNP Rede Nacional de Pesquisa

RTT Round Trip Time

SDN Software Defined Networking

SO Sistema Operacional

TCP Transmission Control Protocol

TI Tecnologia da Informação

UFPE Universidade Federal de Pernambuco

VLAN Virtual Local Area Network

WAN Wide Area Network

WRNP Workshop da Rede Nacional de Pesquisa

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.1 Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 212.1 Redes Multiúso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Redes Definidas Por Software . . . . . . . . . . . . . . . . . . . . . 222.2.1 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.2 Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Pesquisas Científicas e sua Infraestrutura . . . . . . . . . . . . . . 292.5 Zona Desmilitarizada Científica . . . . . . . . . . . . . . . . . . . . 302.6 O desempenho do TCP . . . . . . . . . . . . . . . . . . . . . . . . . 332.7 PerfSONAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.7.1 OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7.2 BWCTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.8 TI Verde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.9 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 PLANEJAMENTO, COLETA E ANÁLISE DOS RESULTADOS . . . 403.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.1 Ciclo PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.1.1 Etapas do Ciclo PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.1 Técnicas e Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . 413.2.2 Métricas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.2.1 Quantidade de saltos . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.2.2 Largura de banda alcançável . . . . . . . . . . . . . . . . . . . . . . . 443.2.2.3 Latência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.3 O estudo de caso no IFPE Campus Recife . . . . . . . . . . . . . . . 453.2.3.1 Modelo de Arquitetura Proposto . . . . . . . . . . . . . . . . . . . . . 453.3 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1 Coleta de Informações . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3.1.1 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.1.1.1 Cenário 01 - Estado Atual da Rede . . . . . . . . . . . . . . . . . . . 48

3.3.1.1.2 Cenário 02 - Aplicação de nó SDN . . . . . . . . . . . . . . . . . . . 49

3.4 Verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 Análise do Cenário 01 . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.1.1 Levantamento de requisitos do Cenário 01. . . . . . . . . . . . . . . 50

3.4.1.2 Criação do plano de execução para o Cenário 01 . . . . . . . . . . 50

3.4.1.3 Modificação do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.1.4 Análise do Tráfego no Ambiente do Cenário 01 . . . . . . . . . . . 51

3.5 Atuação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.5.1 Otimização do fluxo científico com SDN . . . . . . . . . . . . . . . . . 563.5.2 Análise do Cenário 02 . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.5.2.1 Levantamento de requisitos do Cenário 02 . . . . . . . . . . . . . . 57

3.5.2.2 Criação do plano de execução para o Cenário 02 . . . . . . . . . . 58

3.5.2.3 Modificação do ambiente no Cenário 02 . . . . . . . . . . . . . . . 58

3.5.2.4 Análise do Tráfego no Ambiente do Cenário 02 . . . . . . . . . . . 59

3.5.2.5 Repetição do teste de latência no Cenário 01 . . . . . . . . . . . . . 61

3.5.3 Análise dos resultados obtidos . . . . . . . . . . . . . . . . . . . . . . 62

3.5.3.1 Quantidade de saltos . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.5.3.2 Vazão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.5.3.3 Latência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.5.4 Economia de recursos financeiros . . . . . . . . . . . . . . . . . . . . 653.6 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 674.1 Limitações da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

APÊNDICE A - Script de configuração do switch OVS . . . . . . . 75

ANEXO A - Orçamento para passagem de fibra óptica do bloco A(pesquisador) até o datacenter (DMZ Científica) . . . . . . . . . . 78

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

tarcioluna

Linha

17

1 INTRODUÇÃO

A informação será o combustível do século 21, declaração dada por Pettey(2011) do Gartner Company. O volume de dados criado e copiado no mundo, até 2020,girará em torno de 44 Zettabytes, segundo pesquisa encomendada pela Egan MarinoCorporation (EMC) ao International Data Corporation (IDC, 2014). Esse enorme con-junto de dados gerado pelas mais diversas aplicações, como facebook, youtube e asmais variadas aplicações científicas, é chamado de Big Data. De acordo com Chen,Mao e Liu (2014), o termo Big Data se refere a grandes massas de dados não estrutu-rados que necessitam de uma análise em tempo real mais apurada. Com isso novosdesafios surgiram, como gerenciar e organizar efetivamente esses conjuntos de dados.

Muito se tem avançado no desenvolvimento de novas tecnologias de rede volta-das para o encaminhamento de grandes volumes de dados. Porém, a tecnologia legadadas redes multiúso atuais precisa conviver por bastante tempo com as novas técnicas earquiteturas para transferência de dados. Alguns dos motivos para a dificuldade na ado-ção de novas tecnologias está no custo de substituir toda uma infraestrutura funcionale principalmente os complexos planejamentos e aquisições no âmbito das instituiçõespúblicas (FARIA et al., 2011). Esse tempo de convivência entre a tecnologia legada dasredes multiúso e uma nova proposta, como as Redes Definidas Por Software (KREUTZet al., 2014), não têm um prazo de validade, tudo irá depender da popularização dessasnovas tecnologias (LEVIN et al., 2013). Seja por motivos ambientais, econômicos ousimplesmente por uma dificuldade no complexo planejamento e efetivação das aquisi-ções, essa interoperabilidade entre tecnologias deve perdurar. Sendo assim, existe anecessidade de se explorar ao máximo a otimização das redes multiúso legadas, paraque se possa extrair o máximo de desempenho suportado por essas tecnologias e comisso suprir novas necessidades trazidas pela evolução das pesquisas científicas.

1.1 Motivação

Dessa evolução das pesquisas científicas, o que se é mais notado é a grandemassa de dados gerada por esses novos experimentos. Com isso, nos últimos anos,houve uma grande evolução no desenvolvimento de novas tecnologias especializadasna transferência desses dados científicos. A Zona Desmilitarizada Científica (ScienceDMZ ou DMZ Científica) é uma dessas novas arquiteturas (DART et al., 2014). Elaconsiste basicamente em dedicar uma parte da rede para tráfego de dados científicos,fazendo com que esses dados sejam priorizados e não sofram interferência, ou concor-rência, do tráfego comum da rede. Essa grande massa de dados científicos pode chegar

Capítulo 1. INTRODUÇÃO 18

a casa dos petabytes, como no caso do Grande Colisor de Hádrons (LHC)1. Assim,depois de gerada, é transferida para análise pelos cientistas em outros locais devido aquestões políticas, técnicas ou por restrições financeiras (MONGA; POUYOUL; GUOK,2012, p. 1629). Por causa desse fluxo de dados intenso, a Science DMZ é localizadapróximo a borda de saída da rede, evitando a concorrência com tráfego da rede local.

Numa rede local comum, de um Campus por exemplo, os dados que trafegam porela sofrem constantes verificações antes de chegar ao seu destino. Essas checagenssão feitas pelos mais diferentes dispositivos como firewalls, ips/ids e roteadores. Normal-mente, esses equipamentos são de desempenho limitado e são dedicados ao tráfegocomum, como navegação na internet, e-mails, acesso a sistemas administrativos, etc.São adquiridos levando em consideração seu custo benefício e consequentemente têmum hardware mais limitado, como baixa memória, o que influencia seu desempenhofinal. A checagem dos diferentes tipos de dados que trafegam por essa rede acadêmica,acarreta no aumento do atraso para essa informação chegar ao destino. A informaçãolevará um tempo maior para sair da origem até o destino. Com isso o tempo totalgasto na transferência de um fluxo dados científicos, que normalmente ultrapassa acasa dos gigabytes, pode levar dias, semanas ou até meses para ser concluída, oque inviabiliza a maioria dos trabalhos científicos que dependem do fator tempo emsuas pesquisas. Um dos requisitos de uma zona desmilitarizada científica é que afonte de dados que está para ser transmitida esteja o mais próximo possível da bordade saída, pois quanto menos saltos essa transferência sofrer, mais eficiente será atransmissão (DART et al., 2014, p. 176).

Para difundir, padronizar e ajudar as instituições de ensino e pesquisa no tratodesses grandes volumes de dados científicos, a RNP iniciou o desenvolvimento deum modelo de DMZ Científica para instituições brasileiras, baseado no padrão pri-meiramente proposto pela ESnet2. Inicialmente ela criou kits de “baixo custo”, comequipamentos que podem ser adquiridos no Brasil, com capacidade 1G e 10G. Comoapresentado no XV WRNP (CARVALHO et al., 2009), a ciência atual, também chamadapor E-Science, requer uma pesquisa colaborativa, onde é crescente a transferência degrandes volumes de dados e têm como requisitos o baixo tempo de transferência ebanda larga de transmissão. Os trabalhos científicos, por serem colaborativos, com-partilham recursos computacionais e dados. Sendo assim, com essa colaboração, énecessário movimentar grandes volumes de dados, da ordem de gigabytes ou terabytespor dia.

Com essa iniciativa da Rede Nacional de Pesquisa, várias instituições, incluindoo IFPE, receberam e instalaram o kit da Zona Desmilitarizada Científica. Nesse mo-1 http://home.cern/topics/large-hadron-collider2 https://fasterdata.es.net/science-dmz/


mento foram feitos alguns testes iniciais, mas os estudos e modelo de implantaçãoficaram em aberto.

Assim, como um dos requisitos da DMZ Científica é que ela esteja próximo aborda de saída da rede, o que otimiza suas transferências, existe uma área que aindanão foi plenamente tratada na documentação de implantação dessa arquitetura. Paraque os dados saiam do local de onde são gerados, até a DMZ Científica local, elesprecisam trafegar pela rede interna das instituições, concorrendo com todo tipo detráfego comum numa rede multiúso. E é sabido que a tecnologia legada das redesmultiúso atuais não está otimizada para tratar esse tipo de fluxo. Sendo assim, existea necessidade de se explorar ao máximo a otimização dessas redes locais, para queseja possível a transferência desses fluxos de dados científicos e o usuário comum nãotenha seu acesso a rede degradado.

1.2 Objetivos

1.2.1 Geral

Elaborar de uma maneira geral um modelo de otimização inicial de uma redeacadêmica multiúso, preparada para integração com o ambiente de uma DMZ Cientí-fica. Trazendo assim benefícios para administração pública como economicidade, porreutilizar a infraestrutura e equipamentos já existentes, e agilidade na transferência dasinformações das pesquisas científicas, obtidas pela aplicação de novos métodos natransferência dos fluxos de dados científicos.

1.2.2 Específicos

• Analisar o comportamento atual que a transferência de um grande fluxo dedados causa numa rede multiúso sem a devida segmentação do tráfego comum.

• Otimizar o tráfego desse fluxo de dados científicos utilizando técnicas de RedesDefinidas por Software.

• Sugerir um modelo de coleta de informações de desempenho com o softwareperfSONAR para automatizar o encaminhamento do fluxo através do controladorSDN Opendaylight.

1.3 Organização

Este trabalho está organizado da seguinte maneira. No Capítulo 2, entraremosno embasamento teórico do que foi estudado e evidenciado nessa trabalho. Decrevere-mos sobre Redes Multiúso, SDN, Opendaylight, perfSONAR, Science DMZ e Big Data.O Capítulo 3 servirá para mostrarmos o modelo de arquitetura proposto, como foi feita


toda a coleta dos dados, as ferramentas e métodos utilizados. Também citaremos comofoi feita a análise desses dados e seu comparativo. Chegando na Seção 3.5.1 , mostra-remos a otimização de fluxos feita utilizando SDN e faremos novamente um comparativode resultados. Por fim, o Capítulo 4 servirá para nossas conclusões finais e indicativospara trabalhos futuros.

21

2 REFERENCIAL TEÓRICO

Neste capítulo, como forma de obter um melhor entendimento do estudo reali-zado, faremos uma explanação dos principais agentes envolvidos no monitoramento eotimização da rede apresentados nesse trabalho.

2.1 Redes Multiúso

As redes multiúso estão presentes na maioria das empresas e instituições deensino. Mount (1988) descreveu que uma rede multiúso não é uma solução total,mas é um importante componente da infraestrutura geral. Ela deve oferecer uma altae estável largura de banda por usuário, assim como seu gerenciamento. As redesmultiúso são classificadas dessa maneira pois seu tráfego é composto das maisdiversas aplicações, como e-mail, navegação web, acesso a sistemas ERP, entreoutros e não são projetadas para suportar grandes fluxos de dados científicos(DARTet al., 2014). Na Figura 1 ilustramos esses fluxos de dados variados, onde cada correpresenta um fluxo diferente. Além disso, podemos observar que os dados passampor diversos dispositivos durante seu percurso na rede, o que causa um aumento notempo de chegada ao destino. A verificação do fluxo de dados feita por equipamentoscomo IDS/IPS, Firewalls e Roteadores atrapalha bastante a entrega de dados em altodesempenho.

Figura 1 – Rede multiúso com tráfego variado e vários pontos de atraso.

Fonte: Do Autor.

Capítulo 2. REFERENCIAL TEÓRICO 22

Com isso, o tempo levado na transferência de um grande fluxo de dados, quepode chegar a casa dos petabytes, levará dias, semanas ou até meses para serconcluída. Nos casos das pesquisas científicas, em que a análise desses dadosdepende do fator tempo, essa demora inviabilizará esse trabalho.

Para termos uma ideia do impacto causado pela verificação desses dados du-rante a sua transferência, o exemplo abaixo, mostrado no 15º Workshop da RNP (CAR-VALHO et al., 2009), exibe o impacto em uma comunicação de 1Gbps entre doisservidores, quando esse tráfego passa por um Firewall (Iptables) com 6324 regras emsua tabela.

Figura 2 – Impacto causado pelo Firewall em uma transmissão de arquivo.

Fonte: (CARVALHO et al., 2009)

2.2 Redes Definidas Por Software

A configuração de uma rede de grande porte requer conhecimento no gerenci-amento dos elementos que compõem esse ambiente. Switches, roteadores, proxys,firewalls e as interações entre esses equipamentos de diferentes fabricantes sãocomplexas. Cada um desses dispositivos possui sua própria inteligência e são gerenci-ados através de softwares embarcados, utilizando comandos próprios e geralmenteexclusivos. Essa heterogeneidade torna difícil o gerenciamento programável dessesambientes, pois não é possível realizá-lo de um único ponto central (SEZER et al.,2013).

Assim, os custos operacionais envolvidos no provisionamento e gerenciamentodas redes formadas por equipamentos de fabricantes diversos, que cobrem diferentes


tecnologias, vem aumentando com o passar dos anos. Dessa forma surgiu a neces-sidade de um novo modelo de rede, conhecido por Redes Definidas por Software(SDN).

SDN é descrito pela Open Network Foundation (2012) da seguinte maneira:“Na arquitetura SDN, o plano de controle e dados são desacoplados, a inteligência darede e estado são logicamente centralizados, e a infraestrutura de rede subjacente éabstraída das aplicações.”

Dessa maneira, a tecnologia SDN parece se encaixar nessa nova demanda,onde o gerenciamento deve ser centralizado e a administração dos equipamentos, quecompõem a rede, passa a ter uma linguagem única.

Figura 3 – Camadas SDN

Fonte: Software-Defined Networking: The New Norm for Networks. Palo Alto: ONF, White Paper, 2012.

SDN foca em quatro características-chave:

• Separação do plano de controle do plano de dados.

• Um visualizador e controlador da rede centralizado.

• Interfaces abertas entre os dispositivos no plano de controle e no plano dedados.


• Programabilidade da rede por aplicações externas.

A Figura 3 ilustra bem o modelo de arquitetura SDN. Ele se divide em trêscamadas, Infrastructrure Layer, que é a camada onde se localizam os equipamentosfísicos da rede. Inclui switches ethernet e roteadores.

A camada central, chamada de Control Layer, consiste nos controladores quefacilitam a configuração centralizada dos fluxos e caminhos na rede. Esses controlado-res podem obter informações sobre capacidade e demanda da rede através do tráfegode fluxos e repassar os dados para a camada superior, chamada de Application Layer.

Na Application Layer é onde a programação da rede é executada. Aplicaçõesfuncionais como redes de eficiência energética, monitoramento, segurança, controle deacesso para operação e gerenciamento da rede são representadas nessa camada. Des-tacando o controle de usuário/gerenciamento separado do controle de dados.

Comparando a abordagem de rede tradicional com o modelo SDN (Figura 4), umavez que o gerenciamento de fluxo(política de encaminhamento) é definido, a únicamaneira de ajustar o que a política faz é através de alterações na configuração local dodispositivo. Isso tem se mostrado restritivo para administradores de rede que queremexpandir suas redes em resposta as demandas de mudança de tráfego, que ocorremcom frequência com o aumento no uso de dispositivos móveis e o impacto causadopelo “Big Data”.

Figura 4 – Abordagem tradicional (A) contra uma abordagem SDN (B).

Fonte: (Sakir Sezer et al., 2013)


Em uma rede SDN padrão, o funcionamento básico segue o padrão ilustrado naFigura 5. No Step 1, quando o primeiro pacote de um novo fluxo chega ao switch vindoda origem (Sender ), o switch procura uma regra de fluxo para esse pacote no cacheSDN. Se esse pacote combinar com alguma regra, as instruções associadas a estefluxo específico são executadas e os pacotes são encaminhados ao destino (Step 2).

Caso não haja nenhuma combinação com a tabela de fluxos, o pacote pode serencaminhado ao controlador através de um canal seguro (Step 3). Assim, o controladorpode adicionar, atualizar e deletar entradas de fluxos, reativamente ou proativamenteem resposta aos novos pacotes. Depois, o controlador executa o algoritmo de rotea-mento e adiciona uma nova entrada de encaminhamento a tabela de fluxo do switch(Step 4) e a todos os outros switchs que sejam relevantes ao longo do caminho. Por fimo switch encaminha o pacote a porta apropriada para ser enviado ao destino (Step 5).

Figura 5 – Funcionamento básico de uma rede SDN.

Fonte: (Sakir Sezer et al., 2013)

O Volume massivo de dados criados, simulados, processados e analisados porcolaborações científicas globalmente distribuídas continua a crescer exponencialmente.Isso acelerou o desenvolvimento de novos métodos para uma rápida, eficiente econfiável transferência de dados sobre distâncias nacionais e globais. Também fez surgiruma nova geração de inteligência em redes orientadas a software, capaz de suportarmúltiplos programas científicos com necessidades diversas de grandes volumes e/ouentrega de dados em tempo real, se tornando essencial para que esses programascontinuem a crescer e atinjam seus objetivos. (NEWMAN et al., 2015, p. 1)

O Large Hadron Collider ou o Square Kilometer Array são experimentos queexemplificam bem a colaboração em larga escala. Eles dependem das redes definidas


por software para distribuir os petabytes de dados, resultado das pesquisas, aoscientistas espalhados pelo globo (MONGA; POUYOUL; GUOK, 2012). Geralmenteos dados não são processados, visualizados e analisados no local onde são produ-zidos. Eles são movidos para uma região mais conveniente para pesquisadores queestão geograficamente distribuídos. Daí a necessidade de se utilizar essa nova tecno-logia para segmentar e distribuir dinamicamente esses dados através das inúmerasredes acadêmicas de pesquisa.

As redes definidas por software utilizam como padrão o protocolo OpenFlow. Esseprotocolo provê interessantes recursos que podem ser aproveitados para resolver novosdesafios como interoperabilidade e também simplificar a implementação de soluçõesexistentes (MONGA; POUYOUL; GUOK, 2012).

Interoperabilidade: É possível que a solução baseada em SDN possa ser inte-grada com redes existentes?

Segundo Sezer et al. (2013), seria relativamente simples implementar umanova infraestrutura completamente baseada na tecnologia SDN. Para isso, todos oselementos e dispositivos na rede teriam que ter o SDN habilitado. No entanto, existeuma vasta infraestrutura base de redes suportando sistemas e negócios vitais hoje emdia. Simplesmente “jogar fora” essa rede para implantar uma nova infraestrutura não épossível de uma hora para outra.

Durante a transição para essa nova tecnologia, é necessário haver suporte si-multâneo entre SDN e equipamentos legados. Nossa pesquisa mostrará que é possívelutilizar SDN simultâneamente com a rede legada e melhorar o desempenho do fluxode dados científicos.

2.2.1 OpenFlow

O protocolo mais utilizado nas redes definidas por software é o OpenFlow. Eleé uma tecnologia SDN criada para padronizar a maneira como o controlador irá secomunicar com os dispositivos de rede numa arquitetura SDN.

O OpenFlow teve seu desenvolvimento motivado por algumas necessidades daarquitetura SDN. A primeira foi a de executar tarefas que não poderiam ser feitas semsoftwares adicionais para cada um dos elementos de rede. A segunda foi a transferênciade parte da complexidade da rede para o controlador, baseado em software, ao invésde contar apenas com o hardware dos dispositvos de rede. Inicialmente o OpenFlowfoi aplicado apenas em redes acadêmicas. O objetivo era prover uma plataforma quepermitisse aos pesquisadores executar experimentos em redes de produção (FARIASet al., 2011).

Desde que o OpenFlow se tornou a tecnologia SDN mais popular, alguns


consideram esses termos como sinônimos. Entretanto, é importante notar a diferençaentre eles. SDN consiste em dissociar o plano de controle do plano de dados, já oOpenFlow descreve como o controlador e o switch irão se comunicar numa arquiteturaSDN. Fazendo uma analogia com sistemas operacionais, o SDN seria um sistemaoperacional e o OpenFlow o driver que serviria para fazer a comunicação do SistemaOperacional (SO) com o componente de rede (LARA; KOLASANI; RAMAMURTHY,2014).

Redes OpenFlow tem características específicas. Por exemplo, é possível con-trolar vários switches a partir de um único controlador. Também é possível analizarestatísticas de tráfego utilizando o software. Informações de encaminhamento podemser atualizadas dinamicamente, alocação de largura de banda de acordo com a cargade tráfego, bem como diferentes tipos de tráfego podem ser gerenciados como fluxos.

Essa característica de abstração de fluxo é um ponto chave na nossa pesquisa.O OpenFlow pode abstrair todo o tráfego em fluxos. Para cada fluxo haverá umaentrada na tabela de fluxos. Para cada entrada, diferentes regras podem ser definidas.Um fluxo pode ser todo o tráfego que utiliza um protocolo TCP específico. Outro podeser todos os pacotes que trafegam entre dois endereços MAC definidos ou todo dadocom um IP de destino definido. Em nosso trabalho o OpenFlow será o responsável pordeterminar por onde o fluxo do pesquisador deverá ser encaminhado para chegar commais eficiência até o destindo, a Science DMZ.

2.2.2 Open vSwitch

O Open vSwitch é um comutador virtual com diversas camadas e é disponi-bilizado como um software livre através da licença Apache 2.0. É comum utilizar oOpen vSwitch como um switch SDN, principalmente por ele utlizar o protocolo Open-Flow para realizar o encaminhamento de pacotes. Através de um simples protocoloOpenFlow, o Open vSwitch permite que o controlador SDN adicione, remova, atualize,monitore e obtenha estatísticas das suas tabelas de fluxos, bem como desvie pacotesselecionados ao controlador e injete pacotes do controlador no switch (PFAFF et al.,2015).

O Open vSwitch será utilizado em nosso trabalho como o switch principal.Ele fará o encaminhamento dos fluxos através das instruções recebidas manualmenteou automaticamente através do controlador SDN.

2.3 Big Data

Nos últimos 20 anos, houve um aumento em larga escala na quantidade dedados em vários segmentos. Chen, Mao e Liu (2014) citam em sua pesquisa um


relatório do IDC (International Data Corporation), que a média do volume de dadoscriados e copiados no mundo em 2011 foi de 1.8ZB, e que deve ser incrementadapelo menos nove vezes em cinco anos. Em média, 72 horas de vídeos são enviadasao Youtube a cada minuto. Já Kaisler et al. (2013) mostraram em seu trabalho algunsexemplos de big data, descrevendo o seu tamanho e mostrando como foi o crescimentodesses dados em um determinado espaço de tempo, Tabela 1, para termos umapequena noção da quantidade de dados gerada por diferentes segmentos de TI.

Tabela 1 – Exemplos de Big Data.

Data Set/Domain Description

Large HadronCollider/Particle Physics(CERN)

13-15 petabytes in 2010

Internet Communications(Cisco)

667 exabytes in 2013

Social Media12+ Tbytes of tweets every day and growing.Average retweets are 144 per tweet.

Human Digital Universe1.7 Zbytes (2011) -> 7.9 Zbytes in 2015 (Gantzand Reinsel 2011)

British Library UK WebsiteCrawl

∼ 110 TBytes per domain crawl to be archived

OtherRFIDS, smart electric meters, 4.6 billion cameraphones w/ GPS

Fonte: Stephen Kaisler et al. (2013)

O termo Big Data é normalmente utilizado para descrever enormes conjuntosde dados. Comparado com tradicionais, big data inclui normalmente uma massa dedados não estruturados que precisarão de análise em tempo real.

Recentemente, as indústrias ficaram interessadas no enorme potencial do bigdata e muitas agências governamentais anunciaram planos para acelerar a pesquisa eaplicação do big data1. Assim, o rápido crescimento da computação em nuvem e dainternet das coisas trouxe a preocupação de que esses dados, em grande quantidadee com mutual relacionamento, devem ultrapassar a capacidade da infraestrutura earquitetura de T.I. existente atualmente nas instituições. No paradigma da Internet dasCoisas (IoT), sensores ao redor do mundo estão sempre coletando e transmitindo1 https://obamawhitehouse.archives.gov/the-press-office/2015/12/04/fact-sheet-big-data-across-fede

ral-government


dados que serão armazenados e processados em algum lugar na nuvem (MANYIKA etal., 2011).

O volume do conjunto de dados não pode ser o único critério para se caracterizaro big data. A escala de crescimento e seu gerenciamento que não pode ser administradopor tecnologias tradicionais de banco de dados são os próximos dois critérios chavespara definir big data.

Em um relatório da McKinsey, Manyika et al. (2011) sumarizaram o valor queo big data pode gerar: se o big data puder ser criativamente e efetivamente utilizadopara incrementar a eficiência e qualidade, o valor potencial que a indústria médica dosU.S. pode adquirir através dos dados ultrapassará 300 bilhões de dólares, reduzindo osgastos da saúde nos EUA em 8%; big data também pode ser utilizada para aumentar aeficiência das operações do governo, de modo que as operações econômicas desen-volvidas na Europa puderam gerar mais de 100 bilhões de euros em economias (queexclui o efeito da redução de fraudes, erros, e diferença de impostos).

Durante a pandemia de gripe, em 2009, o Google obteve informações oportunasanalisando big data, divulgando assim informações mais valiosas do que as obtidaspelos centros de prevenções de doenças. Logo, todos países requisitaram que oshospitais informassem os centros de prevenção de doenças os novos casos de gripeinfluenza. Em 2008, a Microsoft comprou a Farecast, uma empresa de previsão detickets de linhas aéreas, que indicava a tendência de aumento e queda nos valores dospreços das passagens. O sistema dessa empresa foi incorporado ao buscador Bing, daMicrosoft, fazendo com que em 2012 houvesse uma economia de cerca de 50 dólarespor passagem de cada passageiro, tendo a previsão 75% de precisão. Chen, Mao eLiu (2014) também afirma que atualmente, os dados se tornaram tão importantes quesão comparados aos ativos materiais e capital humano.

Dentre os principais desafios, um se destaca por se relacionar diretamente comessa pesquisa, a cooperação. Análise de big data é uma pesquisa interdisciplinar, querequer experts em diferentes campos cooperando para colher o potencial do big data.Uma compreensiva arquitetura de rede para big data precisa ser estabelecida paraajudar cientistas e engenheiros em vários campos a acessar diferentes tipos de dadose utilizar totalmente seu conhecimento, bem como cooperar para completar os objetivosanalíticos.

2.4 Pesquisas Científicas e sua Infraestrutura

Atualmente, a maioria dos equipamentos utilizados nas pesquisas científicas es-tão conectados a infraestrutura de rede. Essa evolução se deu pela necessidade de umambiente de trabalho colaborativo, onde os pesquisadores precisam compartilhar seus


resultados para uma maior agilidade na obtenção de resultados (DEBROY; CALYAM;DICKINSON, 2015).

Magri et al. (2014) citam que a E-Ciência se sustenta em três pilares, a teoria, aexperimentação e a tecnologia. Antes as pesquisas científicas se baseavam apenasna teoria e experimentação. Agora, com a Tecnologia fazendo parte do conjunto, épossível compartilhar os recursos como: informações, processamento, transferência dedados e aplicações, tornando o resultado desses trabalhos mais rápido e eficiente.

Conforme citado na Seção 2.1, as redes multiúso recebem os mais variadosfluxos de dados, pois são configuradas para dar suporte a uma grande variedadede aplicações e usuários. Além disso, é necessário prover segurança a essa grandequantidade de usuários. Dispositivos complexos precisam ser inseridos nessa infraes-trutura para que ela se torne resiliente as falhas de segurança. Já um ambiente voltadopara pesquisas científicas possui uma quantidade limitada de usuários e aplicaçõesespecíficas, que necessitam geralmente de grande largura banda durante as transfe-rência dos dados. E caso utilize a mesma infraestrutura de rede do tráfego comum,haverá uma redução no desempenho, podendo até inviabilizar a pesquisa.

2.5 Zona Desmilitarizada Científica

Um padrão de projeto é uma solução que pode ser aplicada na resolução devários problemas (ALEXANDER, 1979). Essa é uma definição originada no campo daarquitetura e que foi adotada na ciência da computação, onde a ideia é utilizada nodesenvolvimento de softwares e também na implantação de redes. A Zona Desmilitari-zada Científica é um padrão de projeto, e pode ser adotada para resolver problemas deperformance em qualquer rede. Entre esses problemas, a perda de pacotes é o quecausa a maior queda no troughput de diversas aplicações (DART et al., 2014, 1).

Muitos desses problemas são encontradas na redes locais denominadas demultiúso, e que não foram criadas para suportar fluxos de dados científicos. Hoje emdia, muitos cientistas estão confiando nessas redes para compartilhar, armazenar eanalisar os dados que estão geograficamente dispersados.

Os dados que trafegam por uma rede multiúso, antes de chegar ao seu des-tino, sofrem constantes verificações, feitas por dispositivos como firewalls, ips/ids eroteadores. Normalmente, esses equipamentos são de baixo desempenho, pois sãoadquiridos devido ao seu menor custo e consequentemente têm um limite baixo dememória. A checagem dos diferentes tipos de dados acarreta no aumento do atrasopara essa informação chegar ao destino. Com isso, a demora na transferência de umfluxo dados científicos pode levar dias, semanas ou até meses para ser concluída, oque inviabilizaria esse trabalho. A Figura 6 mostra o percurso do tráfego entra a Rede


Acadêmica e um Sistema Científico de Computação. Podemos notar que os dadospassam por toda rede de produção do campus, firewall e roteador antes de chegar aodestino.

Figura 6 – Rede de campus sem a Zona Desmilitarizada Científica.

Fonte: Do Autor (baseado em figura do XV WRNP).

Para resolver essas questões foi desenvolvida uma tecnologia chamada deZona Desmilitarizada Científica (Science DMZ), que é uma rede de alto desempenho,destinada a receber fluxos de dados resultantes de pesquisas científicas. Ela possuialgumas das características abaixo:

• Segmento especializado da rede ou de um laboratório do campus

• Próximo ao perímetro da rede

• Projetado para aplicações científicas de alto desempenho

Um dos requisitos de uma zona desmilitarizada científica é que a fonte de dadosque está para ser transmitida esteja o mais próximo possível da borda de saída, poisquanto menos saltos essa transferência sofrer, mais eficiente será a transmissão (DARTet al., 2014, 3). A Figura 7 mostra uma DMZ Científica já implantada. Percebemos queela está conectada diretamente ao roteador de borda, o que otimiza o acesso externoe a comunicação com outra DMZ Científica.


Figura 7 – Rede de campus com a Zona Desmilitarizada Científica.

Fonte: Do Autor (baseado em figura do XV WRNP).

Monga, Pouyoul e Guok (2012), citaram um modelo de arquitetura Open-Flow/SDN ScienceDMZ muito próximo ao proposto neste trabalho. Esse modelo dearquitetura propõe o uso de um redirecionador Data Transfer Node (DTN) junto com aDMZ Científica. Quando o redirecionador DTN recebe a requisição de transferênciade dados, o fluxo é redirecionado ao DTN apropriado utilizando as regras de fluxo.O firewall sofre um bypass através do encapsulamento do fluxo em uma das vlanspré aprovadas.

O modelo da DMZ Científica tem se tornado indispensável para o presente efuturo do trabalho da ciência. Provendo uma infraestrutura de de rede escalável, livrede perdas de pacotes que causa a baixa performance do TCP. Esse modelo faz o usoadequado de políticas de segurança para que as aplicações de alta perfomance nãosejam impactadas. Ele cria um caminho efetivo para os recursos locais acessarem ser-viços na WAN e define mecanismos para teste e medição, garantindo uma performanceconsistente.

Segundo Dart et al. (2014), os princípios da Science DMZ são:

• Ser otimizada para Ciência.


• Escalável(servindo tanto a experimentos com supercomputadores quanto pes-quisas multidisciplinares e cientistas individuais).

• Aceitar uma variação crescente de dados a todo momento.

A DMZ científica foi criada com a inovação em mente, sendo flexível paraincorporar novos serviços de rede, como o 100 Gigabit Ethernet. Assim, avanços emserviços de circuitos virtuais e as redes definidas por software representam novasoportunidades para incrementar a produtividade científica.

O primeiro princípio do modelo da DMZ Científica é que a rede seja otimizadapara dados científicos. Sendo assim, existem duas áreas que devem ser consideradas:as WANs e as LANs. As WANs geralmente são otimizadas para aceitar fluxos de dadosde até 100Gbps. Porém, as LANs não tem como características aceitar fluxos de dadostão intensos.

Tentativas científicas de executar essas aplicações numa rede local multiúso,resultaram numa performance muito baixa, e com o aumento da complexidade dosdados e seu tamanho, os cientistas tiveram que esperar horas, dias ou semanas paraque seus dados chegassem (DART et al., 2014).

2.6 O desempenho do TCP

O Protocolo de Controle de Transmissão do TCP/IP é usado para transferirdados entre aplicações, como e-mail, web browsing e aplicações similares. Muitasaplicações científicas também são desenvolvidas baseadas no protocolo TCP, por issoé importante que essas redes sejam capazes de trabalhar com essas aplicações, paraotimizar a rede para a ciência.

O TCP é robusto em muitos aspectos, tem entrega de dados confiável, ouseja, com proteção contra perda de dados, congestionamentos e perdas de conexão(FOROUZAN, 2009). Porém esses mecanismos fazem com que o TCP seja confiável,mas seu desempenho quando as condições da rede não são ideais é muito baixo.

Em particular, o TCP interpreta a perda de pacotes como um congestionamentona rede, e reduz a taxa de envio quando uma perda é detectada. Na prática, umapequena perda de pacotes irá causa uma grande redução na performance do TCP,aumentando assim o tempo total de transferência. Quando aplicada em escala científica,essa diferença pode significar o aumento em dias, em vez de horas ou minutos.

Como o protocolo TCP é utilizado na maiorias das transmissões científicas,incluindo a Science DMZ, é fundamental que o meio de transmissão não apresenteerros, pois assim será possível conseguir uma taxa de vazão mais alta e estável.


2.7 PerfSONAR

Falhas na infraestrutura de rede causam prejuízos a projetos e serviços. O moni-toramento de redes é uma técnica imprescindível, pois seu objetivo é detectar possíveisindicadores de falhas e diminuição no desempenho da rede, definidos a partir demétricas e mapeamento do comportamento deste ambiente (HANEMANN et al., 2005).

Definido o indicador padrão, é preciso comparar grandezas ou métricas demesma natureza para manter o controle contínuo e se tomar medidas preventivase corretivas, se necessário. Essas medições também servem de base para futurasdecisões de adequação e expansão de recursos, para assim manter o nível de serviçosatisfatório.

Existem dois métodos para a monitoração de um ambiente de rede, ativo epassivo. O método ativo consiste em injetar um tráfego com as características ne-cessárias na rede, utilizando softwares específicos para isso, e observar o seu com-portamento durante o trajeto da origem até o destino, permitindo assim a análise ecálculo de alguns parâmetros de desempenho. Já o método passivo monitora o tráfegoexistente na rede, coletando os dados a medida em que eles trafegam pelo ambiente.A medição ativa é mais eficiente e normalmente mais utilizada. Sua aplicação é maisprática e rápida, pois não é necessário aguardar que o fluxo passe para efetivar amedição (BATTISTI; TAROUCO, 2007).

O monitoramento de desempenho é crítico na descoberta dos chamados soft-ware failures na rede. Falhas de software são problemas que não causam uma falhacompleta a ponto de bloquear um fluxo de dados, como por exemplo uma quebra deuma fibra óptica, mas esse tipo de problema causa uma queda no desempenho, sendodifícil de detectar sem o uso de uma ferramenta como o perfSONAR.

Essas falhas podem passar despercebidas por muitos meses, já que a maioriados gerenciadores de rede e sistemas de detecção de erros são otimizados para avisarapenas falha de hardware, como a perda de um link ou dispositivo (HANEMANN et al.,2005).

Um host perfSONAR ajuda nos diagnósticos de falha numa DMZ Científica. Eleoferece testes fim-a-fim com sites colaborativos que têm as ferramentas do perfSONARinstaladas, o que permite multi-domains troulbeshooting.

perfSONAR é uma infraestrutura de serviços web para coleta e publicação domonitoramento de desempenho de redes. O objetivo primário do perfSONAR é tornarfácil a resolução de problemas de desempenho fim a fim em caminhos que passam porvárias redes (TIERNEY et al., 2009, p. 1).

O perfSONAR tem uma ampla variedade de casos de uso. Alguns deles são:


coleta e publicação de dados de latência, coleta e publicação de largura de bandaalcançável, publicação de utilização de dados, publicação de dados da topologia derede, diagnostico de problemas de desempenho, entre outros. Por ser direcionado parapublicação de métricas, ele é designado para ser flexível o suficiente para lidar comnovas métricas de tecnologias como middlewares ou monitoramento de hosts.

Tierney et al. (2009) cita que engenheiros de rede podem utilizar o perfSONARpara ajudar a automatizar a detecção de grandes volumes de fluxo de dados quepodem requerer um tratamento especial, como marcar esse fluxo em alta ou baixaprioridade, dependendo da sua origem ou destino.

Muito do esforço de desenvolvimento inicial do perfSONAR se deu pela neces-sidade da comunidade do Large Hadron Collider (LHC). O acelerador de partículasLHC é um experimento onde dois feixes de partículas, de direções opostas, colidem auma velocidade próxima a da luz. Essa colisão gera uma grande massa de dados queprecisa ser analisada detalhadamente pelos cientistas. Porém essa analise não é feitano local, estes dados precisam ser transferidos para grandes centros científicos, longedo LHC (JOHNSTON et al., 2013).

2.7.1 OWAMP

OWAMP (One-Way Active Measurement Protocol) é uma implementação utili-zada para coletar a latência em um sentido e outras métricas relacionadas a perdase variação de delay. Como definido na RFC 4656, latências de um sentido são úteispara isolar a direção do problema, mas para uma medição precisa é necessária asincronização dos relógios, via protocolo NTP (SHALUNOV et al., 2006).

2.7.2 BWCTL

O BWCTL (Bandwith Test Controller ) é uma ferramenta que adiciona um agen-damento distribuído e capacidade de utilização de políticas a já conhecida ferramentade testes de taxas de transferência IPERF. Isso permite testes de taxa de transferên-cia ocorram no mesmo host com medições regulares sem que aja preocupação emsobrescrever testes distorcendo os resultados.

2.8 TI Verde

TI Verde pode ser considerado um movimento sócio-técnico onde políticas,pesquisas, produtos e práticas buscam minimizar os efeitos danosos ao meio ambiente,provocados pelo intensivo da tecnologia da informação (SALLES et al., 2013).

É baseado no conceito acima que a responsabilidade socioambiental não émais apenas uma opção para as organizações, ela é se tornou uma parte da estratégia,


da visão, e também uma razão para a sobrevivência no mercado. Sendo assim, ogerenciamento inteligente de TI pode ser uma alternativa as organizações, não apenascom o intuito de minimizar os danos causados ao meio ambiente, mas também comouma maneira de melhorar a efetividade do consumo elétrico, reduzir o descarte dosequipamentos e reduzir o custo operacional do negócio. (LUNARDI; ALVES; SALLES,2012)

Um estudo procurou identificar as principais práticas de TI Verde adotadas pelasorganizações. Lunardi, Frio e Brum (2011) cita em seu trabalho que o crescimentocontínuo do uso da TI fez surgir uma preocupação relacionada às questões ambientais,ligadas especialmente ao mau uso e ao descarte dos equipamentos eletrônicos. Sendoum dos principais problemas o descarte de equipamentos eletrônicos obsoletos. Naépoca da fabricação dos equipamentos reutilizados nesses estudo, somente no Brasil,em 2006, foram vendidos cerca de 6 milhões de desktops (CHEROBINO, 2007). E umdos questionamentos de Guilherme era para onde esses computadores iriam depoisde 10 anos?

A TI Verde não é um conceito bem definido, nem um conjunto de práticas unifor-memente aceitas. Mas uma definição abrangente foi dada por Murugesan (2008) ondeele diz que a TI Verde é o estudo e a prática de projetar, produzir, utilizar e descartarcomputadores, servidores e subsistemas associados, eficiente e eficazmente com omínimo ou sem impacto ao meio-ambiente. Brooks, Wang e Sarker (2010) destacam di-ferentes vantagens de ser verde e as divide em duas grandes categorias de benefícios:os ambientais e os financeiros.

Nosso trabalho mostrará que é possível uma prática estar incluída em duas ca-tegorias ao mesmo tempo. Contribuindo tanto para a economia de recursos financeirosquanto para os recursos ambientais.

Na análise do conteúdo de 196 artigos, realizada por Lunardi, Alves e Salles(2012), foram categorizadas diferentes práticas de TI Verde adotadas pelas organiza-ções. Dentro da categoria de Hardware está o aumento do ciclo de vida dos produtos,que na época do estudo já era implantado em duas organizações, demonstrado pelacoluna “n” da Tabela 2.

Tabela 2 – Principais práticas de TI Verde adotadas pelas organizações

Práticas de TI Verde Objetivo n



Práticas de Conscientização

campanhas de conscientização ecoequidade 13

fornecedores verdes ecoequidade 12

política de sustentabilidade ecoequidade 12

teletrabalho/vídeo conferência ecoeficiência 6

prédio verde ecoequidade 3

comitês de sustentabilidade ecoeficiência 1

análise de sustentabiliade ecoeficiência 1

Datacenter Verde

consolidação de servidores ecoeficiência 36

consolidação de desktops ecoeficiência 14

modernização do datacenter ecoeficiência 13

terceirização de servidores ecoeficiência 2

Descarte e Reciclagem

reciclagem de peças, cartuchos e equipamentos ecoeficiência 14

descarte correto ecoequidade 12

recolhimento de materiais ecoequidade 8

doação ou entrega de equipamentos ecoequidade 6

estímulo para recicladores ecoequidade 3

leis de regulamentação ecoequidade 2

trade-in (incentivo à entrega do equipamento antigo nacompra do novo)

ecoeficácia 2

Fontes Alternativas de Energia



uso de energias renováveis ecoeficácia 9

aproveitamento do calor para outros fins ecoeficácia 1

aproveitamento da água ecoeficácia 1

Hardware

equipamentos mais eficientes ecoeficiência 25

substituição de monitores CRT por LCD ecoeficiência 9

eliminação de componentes nocivos nos produtos ecoequidade 6

produtos novos com componentes reciclados ecoeficácia 3

aumento do ciclo de vida dos produtos ecoeficiência 2

Impressão

monitorar impressões ecoeficiência 6

digitalização de documentos ecoeficiência 6

terceirização de impressões ecoeficiência 6

impressão frente-e-verso ecoequidade 4

consolidação de impressoras ecoeficiência 3

uso de papel reciclado ecoequidade 2

uso de multifuncionais ecoeficiência 1

Software

sistema de gerenciamento de energia ecoeficiência 9

aplicativos eficientes ecoeficiência 7

sistemas de controle (emissão de gases, qualidade daágua)

ecoequidade 6

sistema para projetar produtos mais eficientes ecoeficácia 1



Fonte: Tecnologia da Informação e Sustentabilidade: Um estudo sobre adisseminação das práticas de TI Verde nas organizações

O aumento do ciclo de vida dos produtos é uma importante característicaquando se fala em TI Verde. Tanto é possível evitar o descarte de equipamentos queainda podem ter potencial para outras aplicações, quanto também a economia derecursos financeiros ao se evitar novas aquisições ou obras para adequação de outrainfraestrutura.

2.9 Resumo do capítulo

Neste capítulo abordamos todo o referencial teórico das tecnlogias que serãoutilizadas nesse estudo. Vimos os itens que compõem as Redes Definidas por Software,como o protocolo OpenFlow e o Open vSwitch. Estudamos sobre o perfSONAR eseus principais agentes utilizados no monitoramento da infraestrutura de rede. Tambémfalamos sobre os benefícios trazidos pela TI Verde ao se reutilizar equipamentos.

No capítulo seguinte veremos como foi feita a análise interpretação dos resulta-dos, assim como as técnicas e ferramentas aplicadas na coleta dos dados.

40

3 PLANEJAMENTO, COLETA E ANÁLISE DOS RESULTADOS

3.1 Metodologia

Como base para análise, implementação de melhorias e otimização, iremosutilizar o ciclo PDCA (Plan, Do, Check and Act) para a criação de um fluxograma deprocessos, com as atividades essenciais do nosso estudo.

3.1.1 Ciclo PDCA

O ciclo PDCA, segundo Moura (1997), pode ser descrito como “uma ferramentaque orienta a sequência de atividades para se gerenciar uma tarefa, processo”. Esteciclo ou método é largamente difundido em escala mundial e foi amplamente utilizadopor W. Edward Deming em suas atividades desenvolvidas na implementação de umsistema de qualidade na produção da indústria japonesa. J. Juran e K. Ishikawa tam-bém realizaram estudos relevantes sobre o método de melhorias que levaram aoestabelecimento do método PDCA (ANDRADE; MELHADO; MELHADO, 2003).

3.1.1.1 Etapas do Ciclo PDCA

• Planejar: É o início do ciclo, a etapa mais importante, onde o problema é definido.Nesse momento é feito um levantamento e análise de todo ambiente relativo aoestudo, para a correta definição dos objetivos e metas, para a partir de então seelaborar o plano de ação.

• Executar: Com o planejamento tendo sido bem elaborado na primeira etapa, épreciso iniciar a execução do que foi planejado. Nesta etapa, todos os envolvidosno projeto, de acordo com as especialidades, devem ser treinados. Ao final daexecução deve ser feita a coleta dos dados, servindo de base para a próximaetapa.

• Verificar: Aqui os resultados da etapa anterior são verificados, se foram satisfa-tórios ou não.

• Atuar: Para fechar o ciclo, a última etapa parte das verificações realizadasanteriormente, conferindo se as metas foram alcançadas ou se devem ser novasmetas para atuar corretivamente no processo de melhoria contínua, resultandona continuidade do ciclo.

Tendo como base as etapas do ciclo PDCA, criamos a representação dasatividades realizadas para a otimização da rede multiúso. A Figura 8 apresenta o

Capítulo 3. PLANEJAMENTO, COLETA E ANÁLISE DOS RESULTADOS 41

fluxograma com as etapas desenvolvidas para esse processo de melhoria. A primeiraetapa, Planejar, foi dividida em três atividades: Análise do cenário e do problema,Levantamento de requisitos e por última a Criação do plano de execução. A próximaetapa, Executar, tem duas atividades: Modificar o ambiente (sim ou não) e Implantaçãodo monitoramento. A etapa Verificar possui as atividades: Coleta dos resultados eAvaliação do desempenho. Para finalizar, a etapa Atuar, que possui a definição denovas metas.

Figura 8 – Fluxograma com as atividades de otimização.

Fonte: Do Autor.

O conjunto desses processos representam as atividades que foram realizadasem cada uma das etapas da otimização da rede multiúso do IFPE. As seções a seguirrepresentarão cada etapa do ciclo PDCA e suas atividades. Detalharemos algumasdelas para melhor compreensão de todo o processo.

3.2 Planejamento

3.2.1 Técnicas e Ferramentas Utilizadas

Dentro da etapa de planejamento, foi preciso encontrar a situação atual dainfraestrutura de rede do IFPE - Campus Recife. Para isso utilizamos o software perf-


SONAR (detalhado na Seção 2.7), que foi originalmente desenvolvido para encontrarproblemas em links utilizados para grandes transferências de dados científicos. Porém,ele hoje é útil para verificar qualquer rede que trabalhe com transferências de grandesarquivos. (TIERNEY, 2015)

O perfSONAR é uma ferramenta que nos ajudou da seguinte maneira:

• Encontrar problemas na infraestrutura de rede

• Atingir o desempenho esperado da rede

• Ajudar a resolver falhas no ambiente

A estrutura física do IFPE Campus Recife se dividide em blocos. Na Figura 9representamos em cores onde está localizado cada um dos respectivos disposiitivos.Em todos os blocos existem laboratórios de pesquisa. Para o nosso estudo de caso, opesquisador está localizado bloco A, representado pela cor amarela. A velocidadedos links de ligação entre os blocos também é mostrado no mapa e os dispositivosrepresentados pela cor vermelha se encontram todos no Datacenter do Campus Recife.

No início da execução desse trabalho, vários pontos de medição com o perf-SONAR foram configurados, também mostrado na Figura 9 , dando início a coletade informações do ambiente de rede no Instituto Federal de Pernambuco.

Figura 9 – Nós perfSONAR coletando informações do ambiente de rede.

Fonte: Do Autor.

Durante 60 dias, entre os meses de abril e maio, foram realizadas mediçõesentre os nós perfSONAR. Em média, a cada hora um nó realizava uma medição


até outro ponto predefinido em sua configuração. Já nos primeiros dias de coleta deinformações detectamos alguns problemas que afetavam bastante o desempenho darede local:

• O primeiro problema foi o cabo de fibra óptica que liga o bloco E ao core da rede.Ele estava com uma de suas fibras(Tx) dobrada, o que impedia o fluxo totalda luz, causando perda de desempenho. O link de 100mbps estava atingindosomente 0,3mbps de upstream. Esse tipo de problema é conhecido como HardFailure.

• No bloco A, que é onde há a maior concentração de tráfego no Campus, o linkde fibra óptica estava funcionando apenas a 100mbps, porém estava conectadoa uma porta de 1gbps. Após verificarmos a configuração do equipamentos,vimos que a porta estava configurada para trabalhar apenas a 100mbps, entãosó foi preciso alterar a configuração da porta do switch para o link passasse afuncionar a 1gbps. Problemas desse tipo, onde apenas a configuração resolve,são conhecidos como Soft Failure.

Após a resolução inicial desses problemas, observamos algumas mediçõesiniciais nas transmissões e fizemos uma análise do comportamento do fluxo de dados.Os resultados estão apresentados na Seção 3.4.1.4 desse trabalho.

Em posse dos resultados desses testes iniciais, fizemos a otimização dessefluxo de dados utilizando as Redes Definidas Software, e confrontamos os resultadosobtidos, como pode ser visto na Seção 3.5.2.

Por fim, na Seção de trabalhos futuros, iremos sugerir um modelo para coletaautomatizada dessas informações, utilizando o perfSONAR em conjunto com o contro-lador SDN Opendaylight. Mostrando como o Opendaylight pode controlar esse fluxo,liberando ou não o mesmo dependendo do tráfego atual da rede.

3.2.2 Métricas utilizadas

As características de desempenho do estado da rede devem ser determinadasa partir da definição dos projetos ou serviços que serão monitorados. As métricas es-tarão conectadas diretamente com o que o usuário, nesse caso o pesquisador, temcomo necessidade. O acompanhamento dessas métricas é fundamental para as redesacadêmicas, pois seu objetivo é promover o desenvolvimento tecnológico e viabilizara pesquisa colaborativa em variadas áreas de conhecimento, necessitando de níveisde serviço satisfatórios. Na sequência mostramos as principais métricas que serãoobservadas nesse trabalho.


3.2.2.1 Quantidade de saltos

Dart et al. (2014) citam em seu trabalho, que quanto menor a quantidade desaltos, mais eficiente será a transmissão. Isso dependendo do ambiente a ser estudadoe outros fatores devem ser levados em consideração. No entanto, para nosso estudo decaso que é localizado numa LAN, onde é possível medir o comportamento dos caminhospor onde os dados irão seguir, essa métrica será muito importante para conseguirmosuma transferência mais estável e eficiente. Em uma rede local, a quantidade máximade saltos recomendada pela indústria é sete (HOGG, 2013), por causa do tempode propagação do protocolo spannig tree. Utilizaremos o ferramenta tracepath paracalcular a quantidade de saltos da origem até o destino.

3.2.2.2 Largura de banda alcançável

A vazão é quantidade máxima de dados que pode ser transferida entre dois pon-tos na rede em um determinado espaço de tempo. Também é conhecida por throughput.Num mundo ideal, essa taxa de transferência máxima seria igual a capacidade nomi-nal da interface de comunicação, como 100Mbps, 1Gbps ou 10Gbps. Esses valoresnominais não são alcançados, pois durante a transmissão, vários fatores influenciampara essa taxa não ser alcançada, como os campos adicionais para que os quadrospossam ser transportados, o hardware e software utilizados, infraestrutura, protocolosde transmissão e configuração do sistema. Segundo Costa (2008) e Costa Neto (2008),todas as aplicações produzem uma vazão que deve ser suportada pela rede, o quetorna essa métrica uma das mais importantes para se avaliar a qualidade do serviço.

3.2.2.3 Latência

O tempo que um pacote leva para sair da origem até o destino e depois retornara origem, como uma confirmação do destinatário, é chamado de RTT (Round TripTime). Para medir o RTT, conhecido também como atraso bidirecional, a RFC 2681 foidefinida como base para essa medição (QUEIRÓS, 2013). Sendo assim, o atraso,como também é conhecida a latência, está relacionada com o tempo que a informaçãoleva para ir de uma lado a outro da rede. Essa padronização foi realizada pelo IPPM(IP Performance Metrics) que é um grupo de pesquisa do IETF (Internet EngineeringTask Force) cujo objetivo é padronizar um conjunto de métricas que possam seraplicadas para avaliação de qualidade. Essa mesma equipe também definiu o One-Way Delay, que mede somente o tempo que a informação leva da origem até chegarao seu destino, detalhado na RFC 7669.


3.2.3 O estudo de caso no IFPE Campus Recife

Em um trabalho recente conduzido no Instituto Federal de Pernambuco, ospesquisadores realizaram um estudo sobre as redes de telefonia móvel LTE, mostrandoos diferentes modelos de propagação existentes e as técnicas para cálculo da perda depotência do sinal. Em um ambiente controlado, esse cálculo fez uso do simulador de re-des móveis LTE-Advanced e implementou modelos para automação dos experimentos.A utilização desse software, juntamente com sua execução automatizada, resultaramna criação de numa quantidade massiva de dados que precisaram ser transferidos paraanálise em outro local.

A quantidade de dados gerados possuia o tamanho aproximado de até 120Gigabytes, por arquivo. Para a transferência desses arquivos, a DMZ Científica precisouser utilizada por conta da demanda de tempo para análise, visto que alguns dos nós dapesquisa se encontravam em cidades distintas como Recife, São Paulo e Manaus.

O principal obstáculo na transferência desses dados foi resolvido em parte pelautilização da DMZ Científica, que resultou numa queda no tempo de transferência emcerca de 46%, comparando com a transferência normal, que utilizava o link comum desaída para a Internet. Porém o tempo de transferência do local onde esses arquivoseram gerados, um laboratório localizado no bloco A do IFPE Campus Recife, até aDMZ Científica localizada no datacenter do bloco F, se tornou também um obstáculo.Em média a transferência de um único arquivo de 120GB durava cerca de 34 minutos,utilizando a taxa de transferência de 522mbps.

Para armazenar todas as simulações, foram necessários 4 Terabytes de espaçoem disco. Com isso para a transferência de todos esses arquivos foram gastas 19 horase 38 minutos. Que é um tempo consideravelmente alto, já que a origem e o destino seencontram na mesma rede local.

Nas próximas seções trataremos este estudo de caso apenas como “pesquisa-dor”, simplificando a referência a esta pesquisa.

3.2.3.1 Modelo de Arquitetura Proposto

Como base para nosso estudo, propusemos o modelo de arquitetura ilustradona Figura 10. A descrição básica deste modelo consiste em:

• Controlador SDN coletando infomações dos nós perfSONAR sobre todo oambiente de rede ao seu alcance. Ilustrustrado nas linhas pontilhadas vermelhas.

• Informações como horários de pico de tráfego e vazão disponível são recebidaspelo Controlador e enviadas em forma de instruções aos switches virtuais (OpenvSwitch). Mostrado pela linha pontilhada amarela.


• Com essas instruções, o Open vSwitch pode liberar ou não a passagem do fluxocientífico. Se for um tráfego comum, ele será entregue normalmente ao roteadorlocal.

• O fluxo científico não seria autorizado se o Controlador tivesse recebido ainformação de que aquele momento, que está sendo feita a transmissão, équando a rede está mais sobrecarregada. Então, o fluxo científico, por exigirmuita banda disponível, não estaria autorizado a passar. Com isso evitaríamosdegradar o desempenho do usuário comum no acesso a infraestrutura de rede.

• Caso o fluxo fosse autorizado, o Open vSwitch irá separar o fluxo científico dosdemais, encaminhando-o diretamente ao Data Transfer Node (DTN) da ScienceDMZ. Como mostrado pela linha verde. O DTN é a máquina responsável porarmazenar e disponibilizar os dados das pesquisas científicas para outros DTNs.

• A taxa de vazão do fluxo científico será superior, pois as informações coletadase repassadas ao controlador fizeram com que ele enviasse uma instrução aoOpen vSwitch, dizendo que quando for detectado o fluxo científico o mesmoseja enviado diretamente a Science DMZ, não passando pelo firewall e demaisroteadores da rede.

Figura 10 – Modelo de Arquitetura Proposto.

Fonte: Do Autor.


A seguir, na fase de execução, divideremos esse modelo de arquitetura emcenários, analisando detalhamente os resultados obtidos nos testes feitos em cada umdeles.

3.3 Execução

3.3.1 Coleta de Informações

Para termos conhecimento do nosso ambiente, fizemos uma coleta de infor-mações utilizando o perfSONAR como ferramenta. A melhor maneira de demonstrarfielmente o estado atual da rede, é coletar essas informações em tempos determinados,pois análises regulares de métricas de rede podem mostrar tendências e reduzir o riscode falhas em aplicações importantes. Fizemos a coleta desses dados no período de 60dias, nos meses de abril e maio. As medições foram realizadas de hora em hora, todosos dias da semana. Para esse tipo de análise e medição o perfSONAR foi projetado,ele é uma parte importante da arquitetura de uma DMZ Científica, trabalhando emconjunto com outras ferramentas para facilitar e otimizar o uso da rede em pesquisascientíficas livres de impactos externos.

No início da coleta de informações, não foi feita nenhuma alteração na infraes-trutura de rede, apenas adicionamos os nós perfSONAR e iniciamos o monitoramento.Conforme comentado na Seção 3.2.1 e ilustrado na Figura 9. Assim definimos trêscenários, com suas respectivas características, que irão servir para comparação ecomprovação do nosso experimento.


3.3.1.1 Cenários

3.3.1.1.1 Cenário 01 - Estado Atual da Rede

Diagrama 1 – Estado atual do fluxo na rede.

Fonte: Do Autor.

O Diagrama 1 mostra o caminho que os dados gerados pelo Pesquisadorprecisam percorrer na rede para chegar até seu destino, que nesse caso é a ScienceDMZ. Sua transferência passa por toda rede local do Campus, sem nenhuma distinção,competindo com todo tipo de tráfego comum numa rede multiúso, como web, ftp, e-mail, vídeo, etc. O fluxo de dados do Pesquisador ainda é filtrado pelo Firewall, queadicionará mais atraso na transmissão e por fim ainda sofrerá o roteamento final antesde ser encaminhado para a Science DMZ. Todos esses saltos e filtragens irão adicionaratrasos a transferência e impactarão no tempo final de transferência.


3.3.1.1.2 Cenário 02 - Aplicação de nó SDN

Diagrama 2 – Nó SDN fazendo o “bypass” do fluxo.

Fonte: Do Autor.

Com a primeira alteração feita no ambiente, o Diagrama 2, mostra a implantaçãode um nó SDN que servirá de “proxy” para o tráfego vindo do Pesquisador. Todo otráfego saindo do Pesquisador passará pelo nó SDN. Quando for detectado um fluxocientífico, com destino a DMZ Científica, esses dados serão redirecionados, fazendoum bypass pelos dispositivos que iriam gerar um aumento no atraso da entrega dessesdados ao destino. Ou seja, o tráfego científico seria encaminhados direto para a DMZCientífica. Caso não fosse um fluxo científico, os dados seguiriam seu caminho normalpela rede local até sair para internet.

3.4 Verificação

3.4.1 Análise do Cenário 01

No cenário 01, conforme exibido anteriormente na Seção 3.2.1.1, o fluxo dedados científicos do pesquisador, precisa percorrer toda infraestrutura de rede do IFPE


para chegar até o destino, que é a DMZ Científica. Com isso ele está sujeito a todo tipode concorrência de tráfego e a verificação de dispositivos, como firewalls, durante ocaminho.

3.4.1.1 Levantamento de requisitos do Cenário 01

Aqui listamos os equipamentos estão disponíveis para utilizarmos na nossapesquisa. A reutilização de equipamentos é importante, pois valoriza os conceitos daTI Verde, evitando o descarte prematuro e aumentado a vida útil do equipamento.

Tabela 3 – Tabela de requisitos para o Cenário 01.

Equipamento Fabricante/Modelo Características Quantidade

Desktop Itautec Infoway

• Celeron Dual Core

• 2GB RAM

• HD 300GB

• Placa de rede 1gbps

7

Fonte: Do Autor.

O restante do material necessário, como cabos de rede, conectores, entre outros,não foram listados nessa tabela pois são considerados como insumos.

3.4.1.2 Criação do plano de execução para o Cenário 01

Neste ponto definimos as tarefas que deveriam ser realizadas antes da coletados dados:

1) Definição do local de instalação das máquinas perfSONAR.

2) Instalação do software perfSONAR nas respectivas máquinas.

3) Implantar as estações perfSONAR.

4) Início das medições

3.4.1.3 Modificação do Ambiente

A análise do Cenário 01 não exigiu nenhuma modificação do ambiente. Já que ointuito era saber o desempenho e qual o caminho o tráfego científico iria percorrer parachegar até a DMZ Científica, sem que fosse feita nenhuma alteração na infraestrutura.


3.4.1.4 Análise do Tráfego no Ambiente do Cenário 01

Na análise do ambiente em seu estado atual, a primeira métrica verificada foia quantidade de saltos que os dados enviados pelo pesquisador precisarão dar parachegar ao seu destino, que é a DMZ Científica. A Figura 11 ilustra o percurso do fluxode dados, representado pela linha vermelha, partindo do pesquisador com destino aDMZ Científica.

Figura 11 – Fluxo normal até a DMZ Científica.

Fonte: Do Autor.

Confirmando a imagem acima, executamos o comando tracepath na máquinado pesquisador localizado no bloco A, e o resultado é exibido na Figura 12, ondesão mostrados quatro saltos da origem, que é o perfSONAR do pesquisador, até odestino, um dos perfSONAR localizado na DMZ Científica. A linha vermelha mostraque o fluxo tem início no pesquisador, sofre o primeiro encaminhamento do switchdo bloco A ao Core da rede(primeiro salto), depois é encaminhado ao Firewall parafiltragem (segundo salto), na sequência chega ao roteador de borda (terceiro salto), porfim, passa pelo switch Brocade da Science DMZ e é entregue ao destino (quartosalto). Essa será uma das primeiras métricas que iremos tratar na nossa otimização.Pois quanto menor a quantidade de saltos, menor será o acréscimo no tempo total datransmissão.


Figura 12 – Resultado do comando tracepath partindo do pesquisador.

Fonte: Do Autor.

A segunda métrica utilizada está representada no Gráfico 1. Que é quanti-dade média de dados trafegados naquele momento. Para chegarmos a vazão média(vm), pegamos cinco amostras de modições (m) realizadas em períodos diferentes dodia, somamos e dividimos pela quantidade de medições (qm). Dessa forma uma vazãomédia de 522mbps foi detectada durante um dia medição, partindo do pesquisador atéa DMZ científica. Como não houve grande variação na leitura do tráfego, coletamosum ponto de medição a cada três horas, totalizando cinco medições e encontramos amédia simples da vazão diária, conforme fórmula abaixo:

vm = m1+m2+m3+m4+m5qm = vm = 520+530+520+500+540

5 = 522Mbps


Gráfico 1 – Vazão de dados do pesquisador até a Science DMZ.

Fonte: Do autor.

Para medirmos a latência, não foi possível medir diretamente do pesquisadorpara a DMZ Científica. Precisamos dividir o percurso em partes. Por uma limitaçãoda ferramenta, a medição de latência do perfSONAR não funciona quando o tráfegoprecisa passar por um NAT. Dividimos o percurso baseado nos saltos, a primeira partemedida foi do pesquisador até o Core da rede, exibido na Figura 2. Onde a lantênciamédia (lm) foi encontrada através da soma de cinco amostras de medições (m), divididapela quantidade de medições (qm). Com isso notamos que em um dia de medição,esse trecho apresentou uma média de 4ms, com alguns picos entre 6 e 11ms.

lm = m1+m2+m3+m4+m5qm = 11+1+2+3+3

5 = 4ms


Gráfico 2 – Latência do pesquisador (bloco A) até o Core.

Fonte: Do Autor.

Na segunda parte do percurso, fizemos a medição de latência partindo Coreaté a WAN do IFPE, que é o roteador de borda, conectado diretamente a internet. Oresultado é exibido no Gráfico 3. Para encontrar a latência média (lm), somamos cincoamostras de medições (m) e dividimos pela quantidade de medições (qm). Podemosobservar que nesse trecho a latência se manteve em média abaixo dos 2ms, com boaparte do tempo próximo a 0ms e com um pico de 8ms.

lm = m1+m2+m3+m4+m5qm = 1+2+0+0+4

5 = 1, 4ms

Gráfico 3 – Latência do Core até a Wan.

Fonte: Do Autor.


No terceiro trecho de medição, que se dá entre a Wan e a DMZ científicaobservamos o comportamento da latência no Gráfico 4. Para encontrar a latênciamédia (lm), somamos cinco amostras de medições (m) e dividimos pela quantidade demedições (qm). Aqui podemos identificar que houve um importante aumento na taxade erros de transmissão, provavelmente causada pelos fluxos de dados concorrentesda Wan, e também um acréscimo na latência, com picos de até 19ms.

lm = m1+m2+m3+m4+m5qm = 1+0+2+5+5

5 = 2, 6ms

Gráfico 4 – Latência da Wan até a DMZ Científica.

Fonte: Do Autor.

Então, se somarmos a latência média (lm) de cada trecho, teremos o seguinteresultado para a latência média total (lmt):

lmt = lm1 + lm2 + lm3 = 4 + 1, 4 + 2, 6 = 8ms

Chegamos a conclusão que no Cenário 01, o pesquisador ao tentar transferir osdados do seu experimento científico até a DMZ científica, terá uma vazão média de522mbps com uma latência de 8ms e haverá uma quantidade total de quatro saltosaté o destino. Reforçamos que não houve nenhuma alteração, além da inserção dospontos de medição, no ambiente.

3.5 Atuação

Nessa etapa iremos mostrar a última fase do ciclo PDCA, mostrando comoagimos para melhorar o desempenho do ambiente. A partir da Seção 3.5.2 algunstópicos pertencentes a fases anteriores do PDCA irão aparecer, optamos por nãorepetir as fases, nos títulos das seções, para o texto ficar mais objetivo.


3.5.1 Otimização do fluxo científico com SDN

A informação será o combustível do século 21, declaração dada por Pettey(2011) do Gartner Company. O volume de dados criado e copiado no mundo, até 2020,girará em torno de 44ZB, segundo pesquisa encomendada pela EMC ao InternationalData Corporation (IDC, 2014). Esses enormes conjuntos de dados, gerados pelas maisdiversas aplicações, como facebook, youtube e as mais variadas aplicações científicasque gerem uma quantidade significativa de dados, são chamados de Big Data. Deacordo com Chen, Mao e Liu (2014), o termo Big Data se refere a grandes massas dedados não estruturados, que necessitam de uma análise em tempo real, mais apurada.Com isso novos desafios surgiram, como gerenciar e organizar efetivamente essesconjuntos de dados.

Redes de médio a grande ponte, em Instituições de Ensino, precisam serconfiáveis e prover conectividade de alto desempenho enquanto reforça as políticasorganizacionais. Ela precisa também prover um isolamento entre as redes e se manterfácil de gerenciar. Todo o tempo, os custos operacionais e de capital precisam se manterbaixos. Redes Definidas Por Software tem o potencial de ser a solução para essescomplexos desafios operacionais. Porém, a maioria dos trabalhos existentes sobreSDN, tratam apenas de uma implantação completa, não levando em consideração ainfraestrutura de rede legada. (LEVIN et al., 2013, p. 473)

Levin et al. (2013) falam principalmente sobre a metodologia e arquiteturaPanapticon, onde o SDN é aplicado em apenas alguns pontos da rede, coexistindocom a rede legada. Basicamente consiste em integrar switches legados com switchesSDN e exibir, ao controlador, uma abstração da rede física como uma rede SDN.

Farias et al. (2011) também propuseram algo semelhante. Um datapah alterna-tivo que integra switches legado a arquitetura SDN. Em seu trabalho ele citou dificul-dade para habilitar o OpenFlow em um ambiente de produção, por exemplo em umcampus universitário. Pois toda infraestrutura de equipamentos legados deve ser subs-tituída por equipamentos compatíveis com OpenFlow. Tendo um alto custo financeiro eintelectual, podendo também levar a prejuízos e dificuldades na implementação.

Este estudo tem como uma de suas finalidades, reutilizar equipamentos parapropor um modelo de configuração e otimização para utilização da DMZ Científica, emuma rede multiúso, com o advento das redes definidas por software.

Como: A partir dos dados levantados e das premissas básicas das ZonasDesmilitarizadas Científicas, implantar um nó SDN que irá detectar o fluxo científico e oredirecionará através de um “atalho” para a Zona Desmilitarizada Científica.


3.5.2 Análise do Cenário 02

Para esta análise, faremos a inserção de um nó SDN, utilizando o softwareopenvswitch, fazendo com que o mesmo trabalhe como uma espécie de proxy SDN.Esse nó receberá todo o tráfego vindo do pesquisador, caso for detectado um fluxocientífico será feito o bypass de uma parte da rede multiúso, encaminhando o tráfegodiretamente para a DMZ Científica.

Figura 13 – Tráfego redirecionada através do nó SDN.

Fonte: Do Autor

Detalhando a Figura 13, o tráfego científico representado pela linha laranja,tem seu ponto inicial no pesquisador. A linha vermelha representa um fluxo de dadoscomum, como acesso web, e-mail, etc. Note que todo o tráfego do pesquisador édirecionado ao nó SDN, que age como um proxy, redirecionando o fluxo científicodiretamente para a DMZ científica e o fluxo comum é encaminhado ao firewall para seudevido tratamento.

3.5.2.1 Levantamento de requisitos do Cenário 02

Conforme já fizemos também na Seção 3.4.1.1, listamos na Tabela 4 os equipa-mentos necessários para essa etapa da nossa pesquisa.


Tabela 4 – Tabela de requisitos para o Cenário 02

Equipamento Fabricante/ModeloCaracterísticas

Quantidade

Servidor HP HP

• Processador Xeon

• 4GB de Ram

• 2 interfaces de rede Gigabit(onboard)

1

Placa deRede

HP 1 Gbps 2

Fonte: Do Autor.

O restante do material necessário, como cabos de rede, conectores, entreoutros não foram listados nessa tabela, pois são considerados como insumos.

3.5.2.2 Criação do plano de execução para o Cenário 02

As tarefas que devem ser realizadas nessa etapa foram definidas da seguintemaneira:

1) Instalação do sistema operacional Linux Ubuntu Server 14.04 LTS.

2) Instalação das interfaces de rede adicionais no Servidor HP.

3) Instalação do OpenvSwitch no Servidor HP.

4) Configuração das regras OpenFlow no Servidor HP.

3.5.2.3 Modificação do ambiente no Cenário 02

Dessa vez, no ambiente do Cenário 02, houve a necessidade da modificaçãodo ambiente. Pois agora queremos, a partir desse ponto, medir as melhorias causadaspela adição de um nó SDN na rede. Na rede do pesquisador, alteramos o gateway parao Open vSwitch (nó SDN), fazendo com que todo o fluxo saindo dessa parte da redeseja direcionado para esse switch virtual. Com isso duas modificações principais foramfeitas, a adição de um nó SDN (Open vSwitch) e a mudança do gateway da rede dopesquisador.


3.5.2.4 Análise do Tráfego no Ambiente do Cenário 02

Neste cenário, iremos refazer todos os testes, porém agora esperamos obter umdesempenho bem superior devido as otimizações e implantação do nó SDN. Repetindoa medição da primeira métrica, abaixo na Figura 14, podemos perceber que o resultadodo comando tracepath, executado no terminal do pesquisador, agora exibe apenas doissaltos. Não mais quatro como mostrado na Seção 3.3.1.1.1. Ou seja, o fluxo originadono pesquisador foi encaminhado diretamente ao nó SDN (primeiro salto), depois jáchegou ao seu destino na Science DMZ (segundo salto). Obtendo assim uma reduçãode 50% no número de saltos.

Figura 14 – Resultado do comando tracepath com apenas dois saltos.

Fonte: Do Autor.

Outra otimização feita após a adição do nó SDN, foi a modificação do MTU,para 9000 bytes, em todas as interfaces do servidor e também dos switches legados.Liberando nos switches o tráfego de Jumbo Frames, aumentamos o tamanho do frametransmitido e consequentemente diminuímos a quantidade de overhead gerado pelosframes menores.

A segunda métrica, que é a vazão direta entre o terminal do pesquisador ea DMZ Científica, foi medida novamente pelo perfSONAR, durante um dia. Agora otráfego do fluxo passando pelo Nó SDN. O resultado é mostrado no Gráfico 5.


Gráfico 5 – Vazão entre pesquisador e DMZ científica passando pelo nó SDN.

Fonte: Do Autor.

Podemos perceber que praticamente não houve variação significativa na taxade vazão, o que representa agora, conforme o Gráfico, uma vazão media de 870 Mbps,entre o pesquisado e a DMZ científica. Essa estabilidade na vazão foi conseguidaatravés da redução da taxa de erros na transmissão. Pois, conforme citado na Seção 2.6,o TCP trata os erros de transmissão como congestionamento, reduzindo a taxa deenvio. Com isso a taxa de vazão sofrerá sofrerá uma queda abrupta e será aumentadagradativamente até o próximo erro. A vazão estável indica que não houve perda depacotes, ou a perda foi insignificante.

Para a coleta da terceira métrica foi preciso fazer uma pequena mudançano modo como receberemos essa informação. Como o tráfego agora passa peloopenvswitch, e por uma limitação da ferramenta perfSONAR não resolvida até aconclusão desse trabalho, os gráficos de latência não eram exibidos e não puderam serapresentados. Como workaround, utilizamos as medições feitas manualmente comandotracepath, realizadas em cinco momentos durante um dia. Coletando a informação deRTT exibida pelo comando conforme Tabela 5.


Tabela 5 – Coleta manual da latência através do comando tracepath.

Hora 1º Salto (OpenvSwitch) 2º Salto (Wan) RTT

13:00 0.606ms 1.032ms 1.638ms

15:58 0.576ms 1.185ms 1,761ms

17:29 0.559ms 0.912ms 1,417ms

18:20 0.559ms 1.279ms 1,838ms

19:25 0.574ms 1.256ms 1,830ms

Fonte: Do Autor.

Se utilizarmos a mesma fórmula para calcular a média do Round Trip Time,teremos o seguinte:

lm = m1+m2+m3+m4+m5qm = 1,638+1,761+1,417+1,838+1,830

5 = 1, 69ms

Como o Round Trip Time é o tempo de ida e volta dos pacotes, para chegarmosa latência em apenas um sentido só precisamos dividir o resultado por 2. Com issoconcluímos que o fluxo de dados, passando pelo nó SDN, tem uma latência média totalde 1,69ms / 2 = 0,845ms.

3.5.2.5 Repetição do teste de latência no Cenário 01

Já que não foi possível medir a latência do Cenário 02 utilizando os gráficosdo perfSONAR, fizemos o teste de latência novamente no Cenário 01. Dessa vezutilizamos o comando tracepath repetindo o workaround do Cenário 02. Optamos porrepetir o teste para que a comparação fosse feita com dois testes iguais, utilizando amesma ferramenta.


Tabela 6 – Coleta manual da latência através do comando tracepath no Cenário 01.

Hora1º Salto (Bloco

A)2º Salto(Core)

3º Salto(Firewall)

4º Salto(Wan)

RTT

09:1019.120ms 0.357ms 1.301ms 0.702ms

21.480ms

11:4618.878ms 0.424ms 1.208ms 0.695ms

21.205ms

13:168.693ms 0.384ms 1.223ms 0.636ms

10.936ms

17:5711.563ms 0.441ms 1.239ms 0.701ms

13.944ms

18:2710.140ms 0.421ms 1.218ms 0.666ms

12.445ms

Fonte: Do Autor.

Se utilizarmos a mesma fórmula para calcular a média do Round Trip Time,teremos o seguinte:

lm = m1+m2+m3+m4+m5qm = 21,480+21,205+10,936+13,944+12,445

5 = 16, 002ms

Considerando somente um sentido para medição, podemos dividir o RTT por2 que chegaremos a latência: 16,002 / 2 = 8,001ms. Com isso podemos concluir queo resultado da latência obtido no Cenário 01, através dos gráficos do perSONAR, épraticamente o mesmo do que o obtido pela execução manual do comando tracepath,feita também no Cenário 02.

3.5.3 Análise dos resultados obtidos

Com os resultados de ambos cenários em mãos, podemos fazer uma análisequantitativa e inferir todas as melhorias trazidas ao ambiente com a adoção das RedesDefinidas Por Software, bem como o benefício trazido pela economia de recursosfinanceiros e o reaproveitamento de equipamentos fora de uso, que seriam descartados.

3.5.3.1 Quantidade de saltos

Uma das métricas trabalhadas foi a quantidade de saltos necessários para ofluxo chegar ao destino. Como estamos tratando de um fluxo trafegando por uma redelocal, quanto menor o número de saltos, mais rápida será a transmissão. Pois o tempode roteamento e verificação desses equipamentos será excluído do tempo final detransmissão do fluxo de dados. O número de erros e retransmissões também deverá


ser menor, já que partes da rede não serão utilizadas, o que também ajudará no enviomais eficiente dos dados.

A Tabela 7 compara os resultados obtidos nos dois cenários, mostrando adiferença na quantidade de saltos.

Tabela 7 – Quantidade de saltos por Cenário.

Cenário Saltos RTT Médio

Cenário 1 4 11,1ms

Cenário 2 2 1,69ms

Fonte: Do Autor

Podemos observar a redução de 2 saltos do Cenário 1 para o Cenário 2, oque levou também a redução do RTT em 9,41ms. Comparando com o Cenário 1,concluímos que o número de de saltos foi 50% menor e consequetemente o RTT foireduzido em mais de 84%.

3.5.3.2 Vazão

Observando agora a métrica de vazão, que é a mais importante tratada neste tra-balho, visto que geralmente a natureza dos dados científicos são massas de dados nãoestruturados, transferidos em rajadas, para serem analisados em outros locais (CHEN;MAO; LIU, 2014).

O Gráfico abaixo faz um comparativo entre a vazão de dados nos dois cenários.


Gráfico 6 – Vazão por Cenário.

Fonte: Do Autor

No ambiente sem sofrer nenhuma alteração, a vazão de dados era de 522mbps.Já no ambiente otimizado, a vazão saltou para 870mbps, um aumento de 40% na taxa.Ilustrando ainda mais, se o pesquisador fosse transferir 1 TB de dados para a DMZCientífica, a uma taxa de 522 mbps, o tempo total seria de aproximadamente 04 horase 52 minutos. Já se fosse realizada a mesma transferência, agora com a taxa de vazãodo cenário 2 que é de 870mbps, o tempo total seria de 02 horas e 56 minutos. Umaredução de quase 02 horas no tempo total de transferência.

3.5.3.3 Latência

Uma latência menor indica que o tempo para os dados chegarem ao seu destinotambém é menor. Com o nó SDN fazendo com que o fluxo de dados científicos sofraum bypass, deixando de trafegar por parte da rede, a transferência dessas dados setornou bem mais eficiente. Como mostra o gráfico abaixo comparando os dois cenários.


Gráfico 7 – Latência por Cenário.

Fonte: Do Autor.

3.5.4 Economia de recursos financeiros

A atual crise financeira vivida pelo Governo Federal está fazendo com que oorçamento destinado a Educação sofra diversos cortes, isso inclui a verba destinadaaos Institutos Federais de Educação, Ciência e Tecnologia. Com isso o investimentoem tecnologia acaba sofrendo também as consequências, dificultando ainda mais aobtenção de verbas. Sem falar também na burocracia empregada para as aquisiçõesno serviço público, onde em média um processo de compra por concorrência duraaproximadamente 4 meses (FARIA et al., 2011).

A maneira mais “simples” de resolver o problema da passagem do fluxo científicopela rede interna, até chegar a DMZ Científica, seria a implantação de uma novainfraestrutura. Essa nova infraestrutura ligaria diretamente o pesquisador a rede daDMZ científica, através de uma fibra óptica dedicada. Porém, o que é mais “simples”nem sempre é possível, ou é recomendado. Reutilizar equipamentos que não cumpremmais seu papel original, para outros fins como nesse estudo, resulta num benefíciomútuo tanto no orçamento quanto para o meio ambiente.

Solicitamos que uma empresa privada fizesse um orçamento para a implantaçãodessa infraestrutura, envolvendo desde mão de obra até os equipamentos necessáriospara ligação de uma fibra óptica, do bloco A onde fica o pesquisador, até o datacenterlocalizado no Departamento de Gestão em Tecnologia da Informação, que é onde está


instalada a DMZ Científica.

O valor total da obra foi orçado em R$ 38.337,65. Incluindo fibra óptica, es-cavações, conversores de mídia e demais itens necessários ao serviço. Conformeorçamento na Seção de Anexos. Salientando que este valor foi orçado para apenas umponto de pesquisa, e levando em consideração que os equipamentos de interligação,como switches, já existem no local. Outro ponto importante, relacionado ao custo total,é que as instituição não têm apenas um pesquisador, mas sim grupos de pesquisadoresem várias áreas e locais distintos. Por isso o valor final de uma obra que envolva várioscenários de pesquisa, será bem maior.

Apesar dessa economia inicial, sabemos que a longo prazo essa infraestruturade rede precisará de atualizações. Não será possível atingir novos patamares dedesempenho sem um investimento financeiro real, assim, nosso trabalha serve comotransição até que seja feito o investimento necessário. Mas deixamos claro que o modeloproposto foi criado para permanecer em produção, mesmo que sejam inseridos novosdispositivos e caminhos de alto desempenho ao ambiente de rede. Serão necessáriosapenas ajustes em seus parâmetros de configuração.

3.6 Resumo do capítulo

Vimos toda a análise detalhada dos dois cenários e os benefício trazidos pelaotimização e utilização das técnicas de SDN no ambiente do IFPE. Por fim, comparamosos resultados das medições através de gráficos e mostramos a economia financeiraque este estudo trouxe ao reutilizar equipamentos.

67

4 CONSIDERAÇÕES FINAIS

A evolução das tecnologias em redes de computadores é constante, a cadaano surgem novos métodos, técnicas, protocolos que auxiliam na transmissão maiseficiente dos dados. Porém todas essas novas tecnologias precisam conviver com asque elas vieram para substituir, durante o tempo de transição. Às vezes, por ter umcusto bem menor e atender minimamente os requisitos do mercado, as tecnologias jáobsoletas continuam fazendo parte das infraestruturas de rede, sem prazo de validade.

Sendo assim é importante que enquanto essas tecnologias mais antigas es-tejam em uso, seja extraído o máximo de sua capacidade, ou até mesmo superaressas expectativas combinando o que já existe com novos métodos e técnicas.

A utilização das DMZ Científicas vêm se tornando cada vez mais comum nasinstituições de ensino e pesquisa. Ter uma rede local que dê suporte a transferênciadesses fluxos científicos, sem atrapalhar a experiência do usuário comum, é fundamen-tal para a longevidade e desenvolvimento dessa tecnologia. Mas para chegarmos a esteresultado satisfatório, a otimização da rede multiúso e utilização das redes definidas porsoftware foi fundamental. O reuso de equipamentos, evitando seu descarte prematuroe beneficiando a natureza através dos conceitos da TI Verde, também somou bastanteao resultado final deste trabalho.

4.1 Limitações da pesquisa

Uma pesquisa que envolva testes em ambiente de produção está sujeita ainterferência de agentes externos e internos. Como agentes externos podemos citar aépoca em que os testes foram realizados, coincidindo com o início dos meses de chuvana região nordeste. O tempo instável causou inúmeras interrupções no fornecimentode energia do IFPE Campus Recife, onde as estações de medições perfSONAR eos testes estavam sendo executados. Com isso, os testes que tinham uma duraçãode tempo maior ficavam poluídos com erros, tornando os gráficos inconsistentes eatrasando a coleta de informações. Outro obstáculo encontrado, causado também pelafalta de energia, foi a perda de bases de dados de coletas de informação, sendo precisogerar uma nova instalação do nó perfSONAR e iniciar uma nova rodada de testes.

Já os agentes internos, que nós consideramos como os usuários da rede doIFPE, tiveram a utilização da infraestrutura de rede afetada algumas vezes duranteos testes iniciais. O balanceamento na carga de testes foi fundamental para que nãofosse afetado o ambiente de rede acadêmico, o que custou um aumento de tempoconsiderável na obtenção dos resultados. Foi preciso reduzir a quantidade dos testes

Capítulo 4. CONSIDERAÇÕES FINAIS 68

simultâneos, a fim de que a utilização da rede multiúso do Campus permanecesseestável.

Tínhamos a intenção inicial de inserir o Cenário 03 neste trabalho, onde umainterface de comunicação entre o nó perfSONAR e um controlador SDN seria desenvol-vida. Porém devido a sua complexidade de criação e a extensão de sua documentação,somando com a atuação dos agentes externos e internos, preferimos deixá-lo para acontinuidade deste documento, em um trabalho futuro.

4.2 Conclusões

Nosso trabalho mostrou como é possível reutilizar equipamentos através denovos softwares, fazendo com que o desempenho das redes locais possam chegarmais próximo da sua taxa teórica. Também vimos como o monitoramento de redesajuda a detectar falhas e auxilia na otimização desses ambientes.

Com a utilização da ferramenta perfSONAR, foi possível traçar o perfil de toda ainfraestrutura de rede do IFPE Campus Recife. Conseguimos medir as taxa de vazãode todos os blocos e solucionar os problemas encontrados. Também percebemos queo perfSONAR ainda possui algumas limitações, principalmente no que diz respeito aomonitoramento da latência, que não funciona quando temos um NAT separando os doispontos a serem medidos. Outro problema detectado é que as medições não funcionamquando há apenas um servidor NTP configurado no perfSONAR, e pelo menos trêsprecisam estar configurados para que o monitoramento fique ativo.

O método PDCA foi fundamental para nos ajudar a agilizar os testes e melhorara eficiência na obtenção dos resultados. Sem ele não teríamos um padrão a seguir eos resultados poderiam não representar o esperado.

A utilização do OpenVswitch como software SDN, permitiu criarmos as regrasde uma forma mais simples, possibilitando observar os resultados de imediato. Tambémfoi relativamente rápido instalá-lo no sistema Ubuntu 14.04 LTS, que foi a plataformautilizada para rodar o software. O openvswitch é um software maduro e estável, sendofácil integrá-los aos controles SDN mais comuns do mercado, como o OpenDayLight.

Percebemos que a configuração e otimização dos switches legados foi umpouco trabalhosa, pois precisamos mapear em qual porta estava conectado cadaequipamento e também quais portas conectavam a outros switches. Os diferentesfabricantes também dificultaram, pois cada tinha seu padrão de configuração via linhade comando. Depois dessas configurações conseguimos realizar as configurações etestes no ambiente de produção, sem o risco de afetar os usuários. Alguns testes, maisespecificamente os de vazão, quando eram aplicados em mais de nó perfSONAR aomesmo tempo, acabavam afetando o desempenho, causando uma lentidão perceptível


ao usuário no acesso aos recursos de rede. Por isso tivemos que tomar cuidado emnão deixar vários testes rodando simultaneamente, e quando foi preciso, programá-lospara rodar em horários alternados.

Com esse conjunto de ações, chegamos a conclusão que é possível otimizarum ambiente legado para o trabalho com novas tecnologias, como o SDN. O estudo decaso, relatado na Secão 3.2.3, mostra que antes da otimização, o pesquisador gastou19 horas e 38 minutos para enviar todos os dados da sua pesquisa. Após a implantaçãodo nó SDN, essa mesma transmissão levaria apenas 11 horas e 47 minutos.

Com o ambiente otimizado, o pesquisador teve uma economia de 7 horase 51 minutos, em relação ao ambiente em seu estado inicial. Esse tempo, agoradisponível, trará diversos benefícios como redução de gastos energéticos, maior tempolivre para aprimoramento da pesquisa, resultados mais rápidos das análises, entreoutros. A separação do fluxo, através do nó SDN, faz com que o fluxo de dadoscientíficos não interfira no tráfego comum do ambiente de rede institucional. Abaixolistamos resumidamente outros objetivos atingidos nesse trabalho e na sequênciadaremos início ao que podemos trabalhar no futuro.

• Descoberta e resolução de problemas na infraestrutura de rede local.

• Aumento no desempenho da vazão em 40%.

• Diminuição da latência em mais de 80%.

• Aumento do ciclo de vida de equipamentos.

• Compatibilidade com novas tecnologias.

• Economia em aquisições no valor de R$ 38.227,65.

• Aderência com conceitos da TI Verde.

4.3 Trabalhos Futuros

Como proposta para um trabalho futuro e consequentemente a continuaçãodesta pesquisa, está a criação de uma interface de comunicação entre os nós perfSO-NAR e um controlador SDN, como o Opendaylight.

A ideia resumida deste conceito, era fazer com que as informações coletadasdo ambiente pelo perfSONAR, fossem lidas e interpretadas pelo controlador SDN. Asinformações seriam basicamente, os horários de pico de tráfego, melhor momento paratransmissões dos fluxos científicos e caminhos com menor taxas de erro. Para que, comessas informações, o controlador definisse o melhor caminho para aquele determinadofluxo científico, separando o mesmo do tráfego comum e mantendo a mesma qualidade


na transmissão encontrada nesse trabalho. O grande acréscimo a essa pesquisa seriaa inteligência do controlador SDN em determinar os melhores momentos e definir ocaminho para passagem daquele fluxo, conforme a demanda do ambiente de rede.

71

Referências

ALEXANDER, C. The Timeless Way Of Building. Oxford University Press, 1979. ISBN978-0-19-502402-9. Disponível em: <http://library.uniteddiversity.coop/Ecological_Building/The_Timeless_Way_of_Building_Complete.pdf>. Citado na página 30.

ANDRADE, F. F. de; MELHADO, S. B.; MELHADO, S. B. O método de melhoriasPDCA. 2003. Dissertação (Mestrado) — Universidade de São Paulo. Disponível em:<http://www.teses.usp.br/teses/disponiveis/3/3146/tde-04092003-150859/>. Citado napágina 40.

BATTISTI, G.; TAROUCO, L. M. R. Modelo de gerenciamento para infra-estrutura de medições de desempenho em redes de computadores. 2007. Tese(Doutorado) — Universidade Federal do Rio Grande do Sul. Disponível em:<http://hdl.handle.net/10183/12671>. Citado na página 34.

BROOKS, S.; WANG, X.; SARKER, S. Unpacking Green IT: A Review of the ExistingLiterature. AMCIS 2010 Proceedings, Americas Conference on Information Systems,Lima, Agosto 2010. Disponível em: <http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1392&context=amcis2010>. Acesso em: 16/05/2017. Citado na página 36.

CARVALHO, T. C. M. B. et al. XV Seminário de Capacitação e Inovação da RNP.2009. Disponível em: <https://memoria.rnp.br/capacitacao/sci/2009/>. Acesso em:14/02/2017. Citado 2 vezes nas páginas 18 e 22.

CHEN, M.; MAO, S.; LIU, Y. Big Data: A Survey. Journal Mobile Networksand Applications, v. 19, n. 2, p. 171 – 209, Abril 2014. Disponível em: <http://mmlab.snu.ac.kr/~mchen/min_paper/BigDataSurvey2014.pdf>. Citado 5 vezes naspáginas 17, 27, 29, 56 e 63.

CHEROBINO, V. TI Verde: Como reduzir gasto de energia e resíduos em PCs? 2007.Computerworld. Disponível em: <http://gestaoambientalfatec.blogspot.com.br/2009/12/ti-verde-como-reduzir-gasto-de-energia.html>. Acesso em: 16/05/2017. Citado napágina 36.

COSTA, G. H. da. Métricas para Avaliação de Desempenho em Redes QOS sobreIP. Porto Alegre: [s.n.], 2008. Disponível em: <https://www.lume.ufrgs.br/bitstream/handle/10183/15972/000695256.pdf?sequence=1>. Acesso em: 01/04/2017. Citadona página 44.

COSTA NETO, J. A. T. Avaliação de Desempenho da Rede do POP-PI. Teresina: [s.n.],2008. Disponível em: <http://www.pop-pi.rnp.br/system/uploads/article/archive/11/Athayde_aval_desempenho_2008.pdf>. Citado na página 44.

DART, E. et al. The Science DMZ: A Network Design Pattern for Data-Intensive Science.Scientific programming, EUA, v. 22, n. 2, p. 173 – 185, Janeiro 2014. Disponível em:<http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation>. Citado 8 vezes nas páginas 17, 18, 21, 30, 31, 32, 33 e 44.

http://library.uniteddiversity.coop/Ecological_Building/The_Timeless_Way_of_Building_Complete.pdf

http://library.uniteddiversity.coop/Ecological_Building/The_Timeless_Way_of_Building_Complete.pdf

http://www.teses.usp.br/teses/disponiveis/3/3146/tde-04092003-150859/

http://hdl.handle.net/10183/12671

http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1392&context=amcis2010

http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1392&context=amcis2010

https://memoria.rnp.br/capacitacao/sci/2009/

http://mmlab.snu.ac.kr/~mchen/min_paper/BigDataSurvey2014.pdf

http://mmlab.snu.ac.kr/~mchen/min_paper/BigDataSurvey2014.pdf

http://gestaoambientalfatec.blogspot.com.br/2009/12/ti-verde-como-reduzir-gasto-de-energia.html

http://gestaoambientalfatec.blogspot.com.br/2009/12/ti-verde-como-reduzir-gasto-de-energia.html

https://www.lume.ufrgs.br/bitstream/handle/10183/15972/000695256.pdf?sequence=1

https://www.lume.ufrgs.br/bitstream/handle/10183/15972/000695256.pdf?sequence=1

http://www.pop-pi.rnp.br/system/uploads/article/archive/11/Athayde_aval_desempenho_2008.pdf

http://www.pop-pi.rnp.br/system/uploads/article/archive/11/Athayde_aval_desempenho_2008.pdf

http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation

http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation

Referências 72

DEBROY, S.; CALYAM, P.; DICKINSON, M. Orchestrating Science DMZs for Big DataAcceleration: Challenges and Approaches. In: Networking for Big Data. [S.l.: s.n.], 2015.Citado na página 30.

FARIA, E. R. de et al. Pregão Eletrônico Versus Pregão Presencial: EstudoComparativo de Redução de Preços e Tempo. Revista de Contabilidade do Mestradoem Ciências Contábeis da UERJ, Universidade do Estado do Rio de Janeiro, Riode Janeiro, v. 16, n. 1, p. 47 – 62, Janeiro 2011. ISSN 1984-3291. Disponível em:<http://www.e-publicacoes.uerj.br/index.php/rcmccuerj/article/view/5478>. Acesso em:18/05/2017. Citado 2 vezes nas páginas 17 e 65.

FARIAS, F. N. N. et al. Implementação de um Novo Datapath OpenFlowem Ambientes de Switches Legados. Anais do II Workshop de PesquisaExperimental em Internet do Futuro, p. 15 – 18, 2011. Disponível em: <http://sbrc2011.facom.ufms.br/files/workshops/wpeif/ST01_4.pdf>. Citado 2 vezes naspáginas 26 e 56.

FOROUZAN, B. A. TCP/IP Protocol Suite. 4. ed. New York: McGraw-Hill Education,2009. (McGraw-Hill Forouzan Networking). ISBN 978-0073376042. Disponível em:<http://dl.acm.org/citation.cfm?id=940580>. Acesso em: 22/05/2016. Citado na página33.

HANEMANN, A. et al. PerfSONAR: A Service Oriented Architecture for Multi-domain Network Monitoring. In: SPRINGER (Ed.). International Conference onService-Oriented Computing. Springer, 2005. v. 3826, p. 241 – 254. Disponível em:<https://www.es.net/assets/pubs_presos/hbbd05.pdf>. Acesso em: 22/05/2017. Citadona página 34.

HOGG, S. Network World : 9 Common Spanning Tree Mistakes. 2013. Disponível em:<http://www.networkworld.com/article/2223757/cisco-subnet/cisco-subnet-9-common-spanning-tree-mistakes.html>. Acesso em: 20/07/2017. Citado na página 44.

IDC. The Digital Universe of Opportunities: Rich Data and the Increasing Value of theInternet of Things. 2014. Disponível em: <https://www.emc.com/leadership/digital-universe/2014iview/executive-summary.htm>. Acesso em: 23/05/2017. Citado 2 vezesnas páginas 17 e 56.

JOHNSTON, W. E. et al. Enabling high throughput in widely distributed datamanagement and analysis systems: Lessons from the LHC. Maastricht, 2013. TERENANetworking Conference. Disponível em: <https://tnc2013.terena.org/core/presentation/63>. Acesso em: 22/05/2017. Citado na página 35.

KAISLER, S. et al. Big Data: Issues and Challenges Moving Forward. SystemSciences (HICSS), Wailea, Maui, HI, USA, n. 46, Janeiro 2013. Disponível em:<http://ieeexplore.ieee.org/abstract/document/6479953/>. Acesso em: 22/05/2016.Citado na página 28.

KREUTZ, D. et al. Software-Defined Networking: A Comprehensive Survey. CoRR,abs/1406.0440, 2014. Disponível em: <http://arxiv.org/abs/1406.0440>. Citado napágina 17.

http://www.e-publicacoes.uerj.br/index.php/rcmccuerj/article/view/5478

http://sbrc2011.facom.ufms.br/files/workshops/wpeif/ST01_4.pdf

http://sbrc2011.facom.ufms.br/files/workshops/wpeif/ST01_4.pdf

http://dl.acm.org/citation.cfm?id=940580

https://www.es.net/assets/pubs_presos/hbbd05.pdf

http://www.networkworld.com/article/2223757/cisco-subnet/cisco-subnet-9-common-spanning-tree-mistakes.html

http://www.networkworld.com/article/2223757/cisco-subnet/cisco-subnet-9-common-spanning-tree-mistakes.html

https://www.emc.com/leadership/digital-universe/2014iview/executive-summary.htm

https://www.emc.com/leadership/digital-universe/2014iview/executive-summary.htm

https://tnc2013.terena.org/core/presentation/63

https://tnc2013.terena.org/core/presentation/63

http://ieeexplore.ieee.org/abstract/document/6479953/

http://arxiv.org/abs/1406.0440

Referências 73

LARA, A.; KOLASANI, A.; RAMAMURTHY, B. Network Innovation using OpenFlow: ASurvey. IEEE Communications Surveys and Tutorials, v. 16, n. 1, p. 493 – 512, 2014.Disponível em: <http://dx.doi.org/10.1109/SURV.2013.081313.00105>. Citado napágina 27.

LEVIN, D. et al. Incremental SDN deployment in enterprise networks. ACM SIGCOMMComputer Communication Review, ACM New York, v. 43, n. 4, p. 473 – 474, Outubro2013. Disponível em: <http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p473.pdf>. Citado 2 vezes nas páginas 17 e 56.

LUNARDI, G. L.; ALVES, A. P. F.; SALLES, A. C. TI Verde e seu Impactona Sustentabilidade Ambiental. In: XXXVI ENCONTRO DA ANPAD, 36.,2012. XXXVI Encontro da ANPAD. 2012. p. 1 – 16. Disponível em: <http://www.anpad.org.br/admin/pdf/2012_ADI1891.pdf>. Acesso em: 16/05/2017. Citadona página 36.

LUNARDI, G. L.; FRIO, R. S.; BRUM, M. de M. Tecnologia da Informação eSustentabilidade: Um estudo sobre a disseminação das práticas de TI Verde nasorganizações. In: ANPAD, 35., 2011, Rio de Janeiro. XXXV Encontro da ANPAD. 2011.p. 1 – 17. Disponível em: <http://www.anpad.org.br/admin/pdf/ADI2808.pdf>. Acessoem: 16/05/2017. Citado na página 36.

MAGRI, D. R. C. et al. Science DMZ: Support for e-Science in Brazil. In: IEEE 10thInternational Conference on eScience. [S.l.: s.n.], 2014. Citado na página 30.

MANYIKA, J. et al. Big data: the next frontier for innovation, competition, andproductivity. 2011. Disponível em: <http://www.mckinsey.com/~/media/McKinsey/BusinessFunctions/McKinseyDigital/OurInsights/BigdataThenextfrontierforinnovation/MGI_big_data_full_report.ashx>. Acesso em: 06/02/2017. Citado na página 29.

MONGA, I.; POUYOUL, E.; GUOK, C. Software-Defined Networking for Big-DataScience - Architectural Models from Campus to the WAN. High Performance Computing,Networking, Storage and Analysis (SCC), 2012 SC Companion, p. 1629 – 1635, 2012.Disponível em: <https://www.es.net/assets/pubs_presos/ESnet-SRS-SC12-paper-camera-ready.pdf>. Citado 3 vezes nas páginas 18, 26 e 32.

MOUNT, R. P. What users want. Computer Networks and ISDN Systems, v. 16, p. 146 –149, 1988. ISSN 0169-7552. Citado na página 21.

MOURA, L. R. Qualidade simplesmente total : uma abordagem simples e prática dagestão da qualidade. Rio de Janeiro: Qualitymark, 1997. ISBN 857303419x. Citado napágina 40.

MURUGESAN, S. Harnessing Green IT: Principles and Practices. IT Professional,IEEE, v. 10, Fevereiro 2008. ISSN 1520-9202. Disponível em: <http://ieeexplore.ieee.org/document/4446673/>. Acesso em: 16/05/2017. Citado na página 36.

NEWMAN, H. et al. High speed scientific data transfers using software definednetworking. INDIS ’15 Proceedings of the Second Workshop on Innovating the Networkfor Data-Intensive Science, Austin, TX, USA, n. 2, p. 1 – 9, Novembro 2015. Disponívelem: <http://dl.acm.org/citation.cfm?id=2830320>. Citado na página 25.

http://dx.doi.org/10.1109/SURV.2013.081313.00105

http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p473.pdf

http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p473.pdf

http://www.anpad.org.br/admin/pdf/2012_ADI1891.pdf

http://www.anpad.org.br/admin/pdf/2012_ADI1891.pdf

http://www.anpad.org.br/admin/pdf/ADI2808.pdf

http://www.mckinsey.com/~/media/McKinsey/Business Functions/McKinsey Digital/Our Insights/Big data The next frontier for innovation/MGI_big_data_full_report.ashx



https://www.es.net/assets/pubs_presos/ESnet-SRS-SC12-paper-camera-ready.pdf

https://www.es.net/assets/pubs_presos/ESnet-SRS-SC12-paper-camera-ready.pdf

http://ieeexplore.ieee.org/document/4446673/

http://ieeexplore.ieee.org/document/4446673/

http://dl.acm.org/citation.cfm?id=2830320

Referências 74

OPEN NETWORK FOUNDATION. Software-Defined Networking: The New Normfor Networks. 2012. White Paper. Disponível em: <https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf>. Acessoem: 08/02/2017. Citado na página 23.

PETTEY, C. Gartner Says Worldwide Enterprise IT Spending to Reach$2.7 Trillion in 2012. Orlando: [s.n.], 2011. Press Release. Disponível em:<http://www.gartner.com/newsroom/id/1824919>. Acesso em: 23/05/2017. Citado 2vezes nas páginas 17 e 56.

PFAFF, B. et al. The Design and Implementation of Open vSwitch. In: 12th USENIXSymposium on Networked Systems Design and Implementation. USENIX Association,2015. Disponível em: <https://www.usenix.org/conference/nsdi15>. Acesso em:16/07/2017. Citado na página 27.

QUEIRÓS, P. F. M. Monitorização da qualidade de serviço da rede portuguesa deinvestigação e ensino (RCTS). 2013. Dissertação (Mestrado) — Universidade do Minho.Citado na página 44.

SALLES, A. C. et al. Adoção de Práticas de TI Verde nas Organizações: Um EstudoBaseado em Mini Casos. In: IV ENCONTRO DE ADMINISTRAÇÃO DA INFORMAÇÃO,2013, Bento Gonçalves. 2013. Disponível em: <http://repositorio.furg.br/handle/1/5373>.Acesso em: 16/05/2017. Citado na página 35.

SEZER, S. et al. Are we ready for SDN? Implementation challenges for software-definednetworks. IEEE Communications Magazine, v. 51, n. 7, p. 36 – 43, 2013. Disponível em:<http://dx.doi.org/10.1109/MCOM.2013.6553676>. Citado 2 vezes nas páginas 22e 26.

SHALUNOV, S. et al. RFC 4656: A One-way Active Measurement Protocol (OWAMP).2006. Disponível em: <https://tools.ietf.org/html/rfc4656>. Citado na página 35.

TIERNEY, B. perfSONAR: Troubleshooting Network Performance Issues with ActiveMonitoring. 2015. Disponível em: <http://www.perfsonar.net>. Acesso em: 15/02/2017.Citado na página 42.

TIERNEY, B. et al. perfSONAR: Instantiating a Global Network MeasurementFramework. In: 4th Workshop on Real Overlays and Distributed Systems (ROADS’09).[s.n.], 2009. p. 1 – 7. Disponível em: <https://www.es.net/assets/perfsonar-roads.pdf>.Citado 2 vezes nas páginas 34 e 35.

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

http://www.gartner.com/newsroom/id/1824919

https://www.usenix.org/conference/nsdi15

http://repositorio.furg.br/handle/1/5373

http://dx.doi.org/10.1109/MCOM.2013.6553676

https://tools.ietf.org/html/rfc4656

http://www.perfsonar.net

https://www.es.net/assets/perfsonar-roads.pdf

APÊNDICE A 75

APÊNDICE A – Script de configuração do switch OVS

# ! / b in / sh

# c r i a r a br idge pesqbridgeovs−v s c t l add−br pesqbridge

# levan ta r a br idge cr iadai f c o n f i g pesqbridge up

# ad i c i ona r a por ta eth3 a br idge cr iada − a por ta eth3 estal i gada na v lan do bloco a

ovs−v s c t l add−po r t pesqbridge eth3

#remover o endereco i p da i n t e r f a c e eth3i f c o n f i g eth3 0

# ad i c i ona r o endereco i p na br idge pesqbridgei f c o n f i g pesqbridge 192.168.102.96 netmask 255.255.248.0 up

# ad i c i ona r ro ta d e f a u l t para a pesqbridgerou te add d e f a u l t gw 192.168.103.254 pesqbridge

# c r i a r a br idge scdmzbridgeovs−v s c t l add−br scdmzbridge

# levan ta r a br idge cr iadai f c o n f i g scdmzbridge up

# ad i c i ona r a por ta eth0 a scdmzbridge − a por ta eth0 estal i gada di retamente ao swi tch brocade

ovs−v s c t l add−po r t scdmzbridge eth0

#remover o endereco i p da i n t e r f a c e eth0i f c o n f i g eth0 0

# ad i c i ona r o endereco i p a scdmzbridgei f c o n f i g scdmzbridge 200.133.17.37 netmask 255.255.255.224 up

# ad i c i ona r ro ta d e f a u l t para ascdmzbridgerou te add d e f a u l t gw 200.133.17.62 scdmzbidge

# c r i a r os f l u x o s openflow

ovs−o f c t l add−f l ow pesqbridge i n _ p o r t =1 , ac t i ons=LOCALovs−o f c t l add−f l ow pesqbridge i n _ p o r t =LOCAL, ac t ions=output :1

ovs−o f c t l add−f l ow scdmzbridge i n _ p o r t =1 , ac t i ons=LOCALovs−o f c t l add−f l ow scdmzbridge i n _ p o r t =LOCAL, ac t ions=output :1

# c r i a r NAT para mudar o enderamento l o c a l para o enderecamentoexterno

i p t a b l e s −−t ab l e nat −−append POSTROUTING −−out− i n t e r f a c e

APÊNDICE A 76

scdmzbridge − j MASQUERADEi p t a b l e s −−append FORWARD −−in− i n t e r f a c e pesqbridge − j ACCEPT

# a l t e r a r o MTU de todas i n t e r f a c e s para 9000

i f c o n f i g eth0 mtu 9000i f c o n f i g eth3 mtu 9000i f c o n f i g pesqbridge mtu 9000i f c o n f i g scdmzbridge mtu 9000

Código 2 – Script para coleta manual do RTT entre pesquisador e DMZ Científica.

# ! / b in / bash## Reg is t ra r o ho ra r i o da execucao do comando no arqu ivo

t racepath . logdate >> / roo t / t racepath . log# Executar o camando t racepath com dest ino ao i p 200.133.17.36

(DMZ C i e n t i f i c a ) e sa l va r o resu l tado no arqu ivo t racepa th .log

t racepath 200.133.17.36 >> / roo t / t racepath . log

Código 3 – Arquivo tracepath.log contendo os registros da coleta de latência manual.

Mon May 15 15:21:28 −03 20171?: [LOCALHOST] pmtu 70001: 192.168.102.96 (192.168.102.96)

0.714ms2: ps− l t . sciencedmz . i f p e . edu . br (200.133.17 .36)

1.088ms !HResume : pmtu 7000

Tue May 16 13:00:37 −03 20171?: [LOCALHOST] pmtu 70001: 192.168.102.96 (192.168.102.96)







0.588ms1: 192.168.102.96 (192.168.102.96)



Tue May 16 15:58:42 −03 2017

APÊNDICE A 77

1?: [LOCALHOST] pmtu 70001: 192.168.102.96 (192.168.102.96)












Wed May 17 10:31:58 −03 20171?: [LOCALHOST] pmtu 70001: 192.168.102.96 (192.168.102.96)



ANEXO A 78

ANEXO A – Orçamento para passagem de fibra óptica do bloco A (pesquisador) até

o datacenter (DMZ Científica).

pós-graduação em ciência da computação · big data, normalmente é bem mais densa e crítica...

Documents