EQUILIBRANDO ENERGIA, REDUNDÂNCIA E DESEMPENHO EM REDES DE CENTROS DE DADOS DEFINIDAS POR SOFTWARE

(1)

Universidade Federal da Bahia

Universidade Estadual de Feira de Santana

DISSERTAC

¸ ˜

AO DE MESTRADO

Equilibrando Energia, Redundˆ

ancia e Desempenho em Redes de

Centros de Dados Definidas por Software

Antˆ

onio Cleber de Sousa Ara´

ujo

Mestrado Multi - Institucional

em Ciˆ

encia da Computa¸

c˜

ao – MMCC

Salvador - Bahia

7 de outubro de 2016

(2)

(3)

ANT ˆ

ONIO CLEBER DE SOUSA ARA´

UJO

EQUILIBRANDO ENERGIA, REDUND ˆ

ANCIA E DESEMPENHO

EM REDES DE CENTROS DE DADOS DEFINIDAS POR

SOFTWARE

Disserta¸c˜

ao apresentada ao Mestrado

Multi - Institucional em Ciˆ

encia da

Computa¸c˜

ao da Universidade Federal

da Bahia e Universidade Estadual

de Feira de Santana, como requisito

parcial para obten¸c˜

ao do grau de

Mestre em Ciˆ

encia da Computa¸c˜

ao.

Orientador: Leobino Nascimento Sampaio

Salvador - Bahia

7 de outubro de 2016

(4)

ii

Ficha catalogr´afica.

Ara´ujo, Antˆonio Cleber de Sousa

Equilibrando Energia, Redundância e Desempenho em Redes de Centros de Dados Definidas por Software/ Antônio Cleber de Sousa Araújo– Salvador - Bahia, 7 de outubro de 2016.

91p.: il.

Orientador: Leobino Nascimento Sampaio.

Disserta¸c˜ao (Mestrado)– Universidade Federal da Bahia, Instituto de Matem´atica, 7 de outubro de 2016.

1. Eficiˆencia Energ´etica. 2. Redes Definidas por Software. 3. Redes de Centros de Dados.

I. Sampaio, Leobino Nascimento. II. Universidade Federal da Bahia. Instituto de Matem´atica. III MMCC.

(5)

iii

TERMO DE APROVAC

¸ ˜

AO

ANT ˆ

ONIO CLEBER DE SOUSA ARA ´

UJO

EQUILIBRANDO ENERGIA, REDUND ˆ

ANCIA

E DESEMPENHO EM REDES DE CENTROS

DE DADOS DEFINIDAS POR SOFTWARE

Esta disserta¸cão foi julgada adequada à obten¸cão do t´ıtulo de Mestre em Ciência da Computa¸cão e aprovada em sua forma final pelo Mestrado Multi - Institucional em Ciência da Computa¸cão da Universidade Federal da Bahia e Universidade Estadual de Feira de Santana.

Salvador - Bahia, 7 de outubro de 2016

Prof. Dr. Leobino Nascimento Sampaio Universidade Federal da Bahia - UFBA

(Orientador)

Profa. Dra. Fab´ıola Gon¸calves Pereira Greve Universidade Federal da Bahia - UFBA

(Membro interno do programa)

Prof. Dr. Artur Ziviani

Lab. Nacional de Computa¸c˜ao Cient´ıfica - LNCC (Membro externo convidado)

Prof. Dr. Cesar Augusto Cavalheiro Marcondes Universidade Federal de S˜ao Carlos - UFSCar

(6)

(7)

Para meus pais, que mesmo com as limita¸cões de estudo impostas pela árdua vida, nunca deixou faltar nada à fam´ılia, e sempre incentivou com as suas vidas que tanto a minha irmã como eu, alcan¸cássemos tudo aquilo que os estudos podem nos proporcionar, e que nunca é hora de parar...

(8)

(9)

AGRADECIMENTOS

Primeiramente, agrade¸co a Deus por mais esta etapa da minha vida. Obrigado por ter me dado vida, sa´ude, apoio, e acima de tudo, pessoas maravilhosas que cruzaram o meu caminho e me ajudaram bastante a trilhar meus passos.

Obrigado a minha fam´ılia que sempre me apoiou e esteve ao meu lado. Vocˆes s˜ao um presente de Deus na minha vida.

Obrigado a minha esposa, que compreendeu os momentos da minha “ausˆencia” e sempre me ajudou naquilo que lhe competia.

Obrigado ao professor Leobino Nascimento Sampaio, meu orientador, por ser muito mais que um professor e orientador, mas um amigo e parceiro para todas as batalhas. Obrigado pelos “puxões de orelha” que me foram dados e pelo perfeccionismo que sempre o acompanha, tudo isso me tornou mais forte. O senhor é o melhor professor com quem tive o privilégio de estudar na minha vida. Seus ensinamentos de ciência e vida perdurarão comigo para sempre.

Obrigado ao professor Artur Ziviani, um parceiro para todas as horas e um pesquisador incansável. Sua precisão cirúrgica para detectar problemas e propor novas ideias até me assusta. É como dizemos na Bahia “enquanto eu estou indo com o milho, o senhor já está voltando com o cuscuz pronto”. Obrigado pelas inúmeras contribui¸cões ao longo da minha jornada.

A todos os amigos que sempre contribu´ıram comigo em todas as situa¸cões, em especial, Diêgo Braga, Eliseu Torres e ao meu grande parceiro Márcio Miranda que além de dividir uma casa comigo em plena selva amazônica, me ajuda a tentar igualar os seus 4 t´ıtulos de pós-doutorados.

A todos, meu muito obrigado.

(10)

(11)

“Muitos querem aquilo que você tem, mas vão desistir quando souberem o pre¸co que você pagou.”

(12)

(13)

RESUMO

Os grandes centros de dados atuais tipicamente adotam redundância de servidores e equipamentos de comunica¸cão para aumento de sua confiabilidade e disponibilidade. Infraestrutura altamente redundante, contudo, consiste num dos desafios da área devido ao alto consumo de energia. Esta disserta¸cão apresenta a BEEP, uma estratégia energeticamente eficiente para redes de centro de dados definidas por software, baseadas na topologia Fat-Tree. Nossa estratégia, implementada através de uma rede OpenFlow faz uso de múltiplos caminhos, através do MultiPath TCP – MPTCP e da visão global oferecida por controladores de uma rede definida por software, para equilibrar eficiência energética, n´ıvel de redundância dos equipamentos e ganho de desempenho no atendimento às demandas de tráfego. Para alcan¸car este equil´ıbrio, a BEEP procura fazer com que o tráfego de comunica¸cão seja enviado o mais rápido poss´ıvel, utilizando-se da maior quantidade poss´ıvel de caminhos distintos existentes entre a origem o destino de uma comunica¸cão. Desta forma, as interfaces dos comutadores permanecem em estado ocioso na maior parte do tempo e, assim, o consumo energético é reduzido. Resultados experimentais em variantes da topologia Fat-Tree demonstraram ganhos de eficiência energética com a estratégia na ordem de 21% a 47%, em compara¸cão a outras estratégias (ECO-RP e GreenCloud ), além de melhoria na utiliza¸cão da largura de banda dispon´ıvel, conforme haja mais caminhos alternativos dispon´ıveis em todos os cenários avaliados. Além de construir a BEEP, as demais contribui¸cões trazidas por esta disserta¸cão são: i) o desenvolvimento de um ambiente de prototipa¸cão de aplica¸cões de TCP de múltiplos caminhos em redes definidas por software, capaz de mensurar e validar novas propostas para economia de energia baseada em elementos de uma rede de centro de dados; e ii) uma avalia¸cão experimental do TCP de múltiplos caminhos implementado através de redes definidas por software para redes de centro de dados.

Palavras-chave: Centro de Dados, MultiPath TCP, Eficiˆencia Energ´etica, Redes Definidas por Software, OpenFlow.

(14)

(15)

ABSTRACT

Current large-scale data centers typically adopt redundancy of servers and communication devices for improved reliability and availability. A major challenge in the area resides in the high energy consumption of the modern data centers with a highly redundant infrastructure. In this context, we present BEEP, an energy-efficient strategy for data center networks (DCNs) software defined based on the fat-tree topology. Our strategy was implemented in an OpenFlow network and combines multipaths (by using MPTCP – MultiPath TCP) and the global overview offered by software-defined networks (SDNs) to balance the energy efficiency, the equipment redundancy level, and the DCN performance. To achieve this balance, the BEEP sends the fastest possible communication using the possible number of existing different paths between source to destination, so that the switches (their interfaces) remain in idle state most of the time to that its energy consumption is reduced. To achieve this purpose, the BEEP uses three components: FM (Fat-Tree Manager) whose function is to manage the interfaces of switches and control network traffic, the DSW whose function is to disable idle interfaces, and ASW whose function is to enable the necessary interfaces for communication to take place over multiple paths between the source and destination of the communication. Experimental results in variations of the Fat-Tree topology demonstrated energy efficiency gains with the strategy on the order of 21% to 47%, compared to other strategies (ECO-RP and GreenCloud), and improvement in utilization of bandwidth available when there alternative paths available in all scenarios and topologies studied. In addition to building the BEEP, the main contributions brought by this thesis are the development of a prototyping environment for TCP Multiple paths applications in SDN, able to measure and validate new proposals for energy savings based on the DCN elements, and an assessment experimental TCP multipath implemented through to software-defined networks for data center networks.

Keywords: Data Center, Fat-Tree, MultiPath TCP, Energy Efficiency, Software-Defined Network, OpenFlow.

(16)

(17)

SUM ´

ARIO

Cap´ıtulo 1—Introdu¸c˜ao 1

1.1 Objetivos . . . 3

1.2 Metodologia . . . 4

1.3 Organiza¸c˜ao . . . 5

Cap´ıtulo 2—Redes de Centro de Dados - DCN 7 2.1 Arquiteturas utilizadas em redes de centro de dados . . . 7

2.1.1 Centros de dados definidos por software . . . 8

2.1.2 Arquiteturas com m´ultiplos caminhos . . . 10

2.2 Eficiˆencia Energ´etica em redes de centro de dados . . . 13

2.3 Propostas para Eficiˆencia Energ´etica em Elementos da DCN . . . 15

2.3.1 ElasticTree . . . 17

2.3.2 PCube . . . 19

2.3.3 HERO . . . 20

2.3.4 GreenCloud . . . 21

2.3.5 ECO-RP . . . 22

Cap´ıtulo 3—Estrat´egia BEEP 25 3.1 O componente Fat-Tree Manager (FM) . . . 26

3.2 O componente de Desativa¸c˜ao de Switches (DSW) . . . 29

3.3 O componente de Ativa¸c˜ao de Switches (ASW) . . . 30

3.3.1 O funcionamento do ASW . . . 31

3.4 Exemplo com as opera¸c˜oes realizadas pelos componentes da BEEP . . . . 32

3.5 O funcionamento da BEEP na topologia Fat-Tree K4 . . . 33

Cap´ıtulo 4—Implementa¸c˜ao 39 4.1 Configura¸c˜ao do MultiPath TCP (MPTCP) . . . 41

4.1.1 Gerenciamento de Caminhos . . . 42

4.1.2 Controle de Fluxo . . . 43

4.1.3 Controle de Congestionamento . . . 44

4.2 Configura¸c˜ao dos Switches . . . 44

4.2.1 Consumo energ´etico dos Switches . . . 45

4.2.2 Os modos de opera¸cão dos Switches utilizados nos experimentos . 46 4.2.3 A desativa¸cão e reativa¸cão de interfaces de switches . . . 47

(18)

xvi SUM ´ARIO

4.2.4 Wake-on-Packet (WoP) . . . 48

4.3 Tr´afego caracterizado . . . 50

Cap´ıtulo 5—Resultados e Discuss˜oes 53 5.1 Avalia¸c˜ao da BEEP quanto ao Desempenho . . . 56

5.1.1 Desempenho quanto a transferˆencia de dados . . . 56

5.1.2 Desempenho quanto a atrasos . . . 58

5.1.3 Desempenho quanto a Transferˆencia de Dados ´Uteis . . . 60

5.1.4 Considera¸cões sobre a avalia¸cão da BEEP quanto ao Desempenho 63 5.2 Avalia¸cão da BEEP quanto a Eficiência Energética . . . 64

5.3 Avalia¸c˜ao da BEEP quanto a Redundˆancia . . . 67

5.3.1 Avalia¸c˜ao de redundˆancia com base no estado de interfaces ativas nos switches . . . 68

5.3.2 Avalia¸c˜ao de redundˆancia com base no estado de interfaces desligadas nos switches . . . 70

5.3.3 Avalia¸c˜ao de redundˆancia com base no estado de interfaces em espera nos switches . . . 72

5.3.4 Considera¸c˜oes sobre a avalia¸c˜ao da BEEP . . . 74

Cap´ıtulo 6—Conclus˜oes 79 6.1 Limita¸c˜oes do Trabalho . . . 80

6.1.1 Topologias em que a BEEP foi testada . . . 80

6.1.2 Estrat´egias comparadas com a BEEP . . . 80

6.1.3 Recursos de tolerˆancia a falhas . . . 80

6.2 Contribui¸c˜oes . . . 81

6.2.1 Publica¸c˜ao e submiss˜oes futuras . . . 81

(19)

LISTA DE FIGURAS

2.1 Camadas da SDN. Adaptado de (KREUTZ et al., 2015). . . 9

2.2 Representa¸c˜ao de um switch OpenFlow (MCKEOWN et al., 2008). . . . 10

2.3 Fluxos TCP e MPTCP. Adaptado de (POL et al., 2012). . . 11

2.4 Comunica¸c˜ao atrav´es do MPTCP. Baseada no Internet-Draft (FORD; RAICIU; HANDLEY, 2012). . . 12

2.5 Topologia ElasticTree (HELLER; SEETHARAMAN; MAHADEVAN, 2006) 18 2.6 O diagrama executado pelos m´odulos da ElasticTree (HELLER; SEETHARAMAN; MAHADEVAN, 2006) . . . 18

2.7 Modelo do modelo experimento criado pela ElasticTree para uma topologia Fat-Tree k = 4 (HELLER; SEETHARAMAN; MAHADEVAN, 2006). Cada NetFPGA emulam 4 servidores com conex˜oes de 1GB. . . . 19

2.8 Estrat´egia PCube mostrando um exemplo das topologias: (a) PCube (2, 4, 4), (b) PCube (2, 4, 3) e (c) PCube (2, 4, 2). Figura adaptada de (HUANG et al., 2011). . . 20

2.9 Otimiza¸c˜oes realizadas pelo HERO: (a) a n´ıvel do POD, e (b) a n´ıvel do n´ucleo (ZHANG; ANSARI, 2015). . . 21

2.10 Arquitetura da GreenCloud em uma topologia de 3 n´ıveis (KLIAZOVICH; BOUVRY; KHAN, 2012). . . 22

3.1 Componentes da estrat´egia BEEP . . . 26

3.2 Processos de Desativa¸cão e Ativa¸cão de Switches na estratégia BEEP . . 28

3.3 A¸c˜oes realizadas nas interfaces pelos componentes DSW e ASW . . . 33

3.4 Exemplo de comunica¸cão entre dois hosts através da estratégia BEEP. . . 34

3.5 Exemplo de comunica¸c˜ao Intra-Switch na estrat´egia BEEP. . . 35

3.6 Exemplo de comunica¸c˜ao Intra-POD na estrat´egia BEEP. . . 35

3.7 Exemplo de comunica¸c˜ao Inter-POD na estrat´egia BEEP. . . 36

3.8 Exemplo com a Fat-Tree sem tr´afego na estrat´egia BEEP. . . 37

4.1 Ambiente experimental da estratégia BEEP. i) topologias Fat-Tree emuladas no Mininet; ii) componentes da estratégia BEEP; iii) atua¸cão do protocolo OpenFlow e; iv) visão global da rede passada para a BEEP pelo controlador OpenFlow. . . 41

4.2 Exemplo de Deslizamento de Janelas utilizado na implementa¸c˜ao da BEEP. 43 4.3 O Protocolo LLDP. Adaptado de (CHOI, 2013). . . 45

4.4 Cabe¸calho de um pacote OpenFlow (SUH et al., 2014). . . 45

4.5 HP Aruba 3800 Switch Series (HPE, 2016) - Switch utilizado como parˆametro nos experimentos. . . 46

(20)

xviii LISTA DE FIGURAS

4.6 Estados das interfaces configuradas nos Switches e os elementos responsáveis pelas a¸cões de ativa¸cão e desativa¸cão das interfaces de rede. 48 4.7 Estágios de funcionamento do Wake-on-Packet (WoP) . . . 49 4.8 Arquitetura do D-ITG. Adaptado de (INTERACTION; ENGINEERING;

II”, 2013). . . 51 5.1 Gr´aficos agregados com os resultados quanto ao tempo gasto para as

transferências das cargas de trabalho. . . 59 5.2 Gráficos agregados com os resultados quanto as médias obtidas com o

Round Trip Delay. . . 61 5.3 Gráficos agregados com os resultados quanto à quantidade de dados úteis

transferidos. . . 63 5.4 Gr´aficos agregados com o desempenho da BEEP com as diferentes cargas

de trabalho. . . 65 5.5 Gráficos com os resultados quanto ao consumo energético pelos Switches. 67 5.6 Gráficos agregados com os resultados quanto a quantidade de interfaces

ativas. . . 70 5.7 Agregado com os resultados quanto a quantidade de interfaces desligadas. 72 5.8 Gr´aficos agregados com os resultados quanto a quantidade de interfaces

em espera. . . 74 5.9 Agregado com o desempenho da BEEP com as diferentes cargas de trabalho. 75 5.10 Gr´aficos agregados com os estados das interfaces da BEEP com as

(21)

LISTA DE TABELAS

4.1 Parˆametros dos Switches OpenFlow utilizados nos experimentos. . . 46 5.1 Quantidade de hosts, switches, e interfaces de comunica¸c˜ao para cada

topologia Fat-Tree emulada nos experimentos. . . 54 5.2 Resultados da avalia¸c˜ao da transferˆencia da carga de trabalho de 10GB

entre os hosts. . . 56 5.3 Resultados da avalia¸c˜ao da transferˆencia da carga de trabalho de 20GB

entre os hosts. . . 57 5.6 Percentual de vantagem da BEEP em rela¸c˜ao a outras estrat´egias avaliadas

com base no tempo total para transferência . . . 58 5.7 Resultados da avalia¸cão dos atrasos obtidos durante a transferência da

carga de trabalho de 10GB entre os hosts. . . 59 5.8 Resultados da avalia¸c˜ao dos atrasos obtidos durante a transferˆencia da

carga de trabalho de 200GB entre os hosts. . . 60 5.11 Resultados da avalia¸cão do percentual de utiliza¸cão de dados úteis obtidos

durante a transferência da carga de trabalho de 10GB entre os hosts. . . 61 5.12 Resultados da avalia¸cão do percentual de utiliza¸cão de dados úteis obtidos

durante a transferência da carga de trabalho de 200GB entre os hosts. . . 62 5.15 Resultados da avalia¸cão do consumo energético obtidos durante a

transferência da carga de trabalho de 10GB entre os hosts. . . 65 5.16 Resultados da avalia¸cão do consumo energético obtidos durante a

transferência da carga de trabalho de 20GB entre os hosts. . . 65 5.17 Resultados da avalia¸cão do consumo energético obtidos durante a

transferˆencia da carga de trabalho de 100GB entre os hosts. . . 66

(22)

xx LISTA DE TABELAS

5.18 Resultados da avalia¸cão do consumo energético obtidos durante a transferência da carga de trabalho de 200GB entre os hosts. . . 66 5.19 Percentual de vantagem da BEEP em rela¸cão a outras estratégias avaliadas

com base no consumo energético . . . 66 5.20 Resultados da avalia¸cão da redundância através das interfaces ativas nos

experimentos com carga de trabalho de 10GB entre os hosts. . . 68 5.21 Resultados da avalia¸cão da redundância através das interfaces ativas nos

experimentos com carga de trabalho de 200GB entre os hosts. . . 69 5.24 Resultados da avalia¸cão da redundância através das interfaces desligadas

nos experimentos com carga de trabalho de 10GB entre os hosts. . . 70 5.25 Resultados da avalia¸cão da redundância através das interfaces desligadas

nos experimentos com carga de trabalho de 200GB entre os hosts. . . 71 5.28 Resultados da avalia¸cão da redundância através das interfaces em espera

(23)

LISTA DE SIGLAS

ACPI Advanced Configuration and Power Interface APM Application Performance Management

ASW Activation Switch

BALIA BAlanced LInked Adaptation

BEEP Balanced Energy, rEdundancy, and Performance BWs Balanced Workloads

CAGR Compound Annual Growth Rate CAM Content Addresseable Memory

CIWs Computationally Intensive Workloads CMCF Constraint Multi-Commodity Flow D-ITG Distributed Internet Traffic Generator DCN Data Center Network

DIWs Data-Intensive Workloads DSW Deactivation Switch

DVFS Dynamic Voltage and Frequency Scaling FLOPS Pontos Flutuantes por Segundo

FM Fat-Tree Manager

HERO Hierarchical EneRgy Optimization HLSDB Historical Link State Database

ISO International Standardization Organization LLDP Link Layer Discovery Protocol

LLDPDU Link Layer Discover Protocol Data Unit

(24)

xxii LISTA DE SIGLAS

LSA Link State Adptation

MIB Management Information Base MIP Mixed Integer Program

MPTCP MutiPath TCP MTU Max Transmission Unit NSA Network State Advertisement NSDB Network State Database NTC Network Traffic Consolidation OSI Open System Interconection

POD Performance Optimized Datacenter RTT Round Trip Time

SAT Source Address Table SDN Software Defined Network SLC Server Load Consolidation

SNMP Simple Network Management Protocol TCAM Ternary Content-Addressable Memory TFO TCP FastOpen

TLP TCP Tail-Loss Probe TSQ TCP Small-Queues TWh Terawatt/hora WoP Wake on Packet

(25)

Cap´ıtulo

1

Neste primeiro cap´ıtulo são mostrados o contexto atual dos centros de dados e quais são os principais problemas e desafios enfrentados em rela¸cão ao seu consumo de energia, fatos estes que nortearam as pesquisas realizadas nesta disserta¸cão. Além disso, também são explanados os objetivos, a metodologia utilizada para a constru¸cão e desenvolvimento desta pesquisa e como esta disserta¸cão está organizada.

INTRODUC

¸ ˜

AO

Os centros de dados (do inglês, Datacenter ) são infraestruturas de computa¸cão de larga escala concebidos para atender uma missão cr´ıtica de operar, de acordo com seu clock de processamento (BUYYA; VECCHIOLA; SELVI, 2013), para impulsionar o rápido crescimento da indústria de Tecnologia da Informa¸cão (TI) e transformar a economia em geral (BUYYA; BELOGLAZOV; ABAWAJY, 2010).

A criticidade do aumento da quantidade de centros de dados tem sido alimentada principalmente por dois fatores. O primeiro fator é relativo ao crescente aumento da demanda por dados, processamento e armazenamento por uma variedade de servi¸cos em nuvem em grande escala, tais como Google1 e Facebook2, por parte dos operadores de telecomunica¸cões, tal como a British Telecom3 (KRUG; SHACKLETON; SAFFRE, 2014), por grandes bancos, dentre outros, resultou na prolifera¸cão de grandes centros de dados, com milhares de servidores e de equipamentos para interconexão dos dispositivos. O segundo fator está ligado à necessidade de dar suporte a uma grande variedade de aplica¸cões que vão desde aquelas que são executadas por um tempo periódico espec´ıfico ou ainda aquelas que funcionam de forma persistente em plataformas de hardware compartilhados (BUYYA; BELOGLAZOV; ABAWAJY, 2010), o que promoveu a constru¸cão de infraestruturas de computa¸cão de grande escala. Devido a estes motivos os centros de dados têm sido apontados como uma das tecnologias facilitadoras essenciais para o rápido crescimento da indústria de TI e, ao mesmo tempo, resultando em um mercado global de 172 bilhões de dólares até os dois primeiros meses de 2016 (DAYARATHNA; WEN; FAN, 2016). Assim sendo, os centros de dados,

1_{http://www.google.com/} 2_{http://www.facebook.com/} 3_{http://home.bt.com/}

(26)

2 INTRODUC¸ ˜AO

principalmente aqueles que operam em larga escala, possuem elevados or¸camentos de energia, que deram origem a várias questões sobre a utiliza¸cão de seus recursos.

Por tais motivos, a eficiência energética dos centros de dados atingiu uma importância fundamental para a TI e para a economia nos últimos 20 anos devido ao seu: i) impacto econômico, ii) impacto ambiental, e iii) impacto no desempenho.

Quanto ao impacto econômico, geralmente um centro de dados pode consumir energia suficiente para atender a 25.000 domic´ılios. Em alguns cenários, eles podem consumir de 100 a 200 vezes mais eletricidade que um escritório padrão (POESS; NAMBIAR, 2008). Até o ano de 2010, os custos com energia tinham a tendência de dobrar a cada cinco anos (BUYYA; BELOGLAZOV; ABAWAJY, 2010). Portanto, com tal aumento acentuado do consumo energético, aliado aos custos crescentes de energia elétrica, fizeram com que as contas de energia se tornassem um gasto significativo para os centros de dados atuais (POESS; NAMBIAR, 2008; GAO et al., 2013). Em algumas situa¸cões, os custos de energia podem até exceder os custos obtidos com a aquisi¸cão do hardware (RIVOIRE et al., 2007).

Já quanto ao impacto ambiental, um estudo realizado em 2005 sobre consumo energético dos centros de dados dos Estados Unidados revelou que o consumo total de energia obtido por eles representaram 5% do consumo total de energia do pa´ıs. Além de que, emitiram mais gases que geram o efeito estufa do que um pa´ıs de porte médio como a Argentina (MATHEW; SITARAMAN; SHENOY, 2012). Em 2010, o uso global de eletricidade em um centro de dados foi estimada entre 1,1% e 1,5% do consumo total de eletricidade mundial (ANDRAE; EDLER, 2015), enquanto que nos EUA os centros de dados consumiram entre 1,7% a 2,2% de toda a energia elétrica consumida no pa´ıs (KOOMEY, 2011). Um estudo recente realizado por (HEDDEGHEM et al., 2014) descobriu que os centros de dados em todo o mundo consumiram um total de 270 TWh (Terawatt/hora) de energia em 2012, e segundo o Compound Annual Growth Rate (CAGR) este consumo teve uma taxa de crescimento anual na ordem de 4,4% entre 2007 e 2012. Devido estas razões a eficiência energética dos centros de dados é considerada uma das principais preocupa¸cões para gestores de centro de dados, muitas vezes à frente de fatores considerados mais tradicionais como disponibilidade e seguran¸ca. Uma vez que, independente da fonte de energia a ser utilizada, seu consumo exagerado contribui para o aumento de algum tipo de polui¸cão.

Por fim, quanto ao impacto no desempenho, mesmo quando um servidor ou qualquer equipamento de intercomunica¸cão (switches e roteadores) estão em estado ocioso eles consomem uma quantidade significativa de energia (BARROSO; HOLZLE, 2007). No entanto, algumas solu¸cões para reduzir o consumo energético consistem em desligar estes servidores ou equipamentos. Entretanto, um fator a ser observado é que estas técnicas de economia de energia, de modo geral, possuem como caracter´ıstica reduzir o desempenho do sistema, sendo necessário a realiza¸cão de um complexo equil´ıbrio entre economia de energia e alto desempenho.

Com a inten¸cão de atenuar estes problemas enfrentados pelos centros de dados, pesquisadores tem proposto e discutido novas ideias no tange a cria¸cão de novas arquiteturas, topologias, e estratégias para reduzir o consumo energético dos equipamentos. Entretanto, devido a alta complexidade em prover uma solu¸cão que

(27)

1.1 OBJETIVOS 3

atenda a todos os critérios exigidos, muitas vezes estas pesquisas resultam solu¸cões para apenas algum elemento necessário, em detrimento de outros.

Logo, visando atender à necessidade de equilibrarmos o consumo energético, o desempenho obtido nas comunica¸cões e a redundância de equipamentos, esta disserta¸cão apresenta a estratégia Balanced Energy, rEdundancy, and Performance (BEEP). A BEEP é uma estratégia concebida para realizar este equil´ıbrio em redes de centros de dados baseadas em topologias hierárquicas (como a Fat-Tree), que explora os recursos dispon´ıveis no paradigma das Redes Definidas por Software (do inglês, Software Defined Network - SDN). Este fator fornece a BEEP uma maior flexibilidade de a¸cões e poder de customiza¸cão dos encaminhamentos de pacotes realizados pela rede, de forma a atender `

a necessidade de equilibrar o consumo energético dos equipamentos de interconexão de rede isto é, dos dispositivos comutadores de pacotes, da redundância exigida por uma topologia para centro de dados e o desempenho obtido em suas comunica¸cões.

Com o intuito de alcan¸car um equil´ıbrio entre consumo de energia, redundância m´ınima necessária de equipamentos e o desempenho da rede, a BEEP possui como meta enviar os tráfegos de comunica¸cões o mais rápido poss´ıvel, utilizando-se da maior quantidade poss´ıvel de caminhos distintos existentes entre a origem o destino (através da utiliza¸cão do MPTCP - MultiPath TCP ), a fim de que os switches (suas interfaces) permane¸cam em estado ocioso na maior parte do tempo, a fim de que reduzam o seu consumo energético.

Para realizar tal prop´osito, a BEEP utiliza trˆes componentes:

• Componente Fat-Tree Manager (FM): que tem como fun¸cão administrar e controlar o tráfego da rede, monitorar a utiliza¸cão das interfaces dos switches da topologia a fim de deixá-las, na maior parte do tempo poss´ıvel, em modo de espera ou desligadas, bem como a fun¸cão de inicializar e acionar, quando necessário, os outros dois componentes da estratégia;

• Componente de Desativa¸c˜ao de SWitches (DSW): que tem como fun¸c˜ao desativar (desligar ou colocar em modo de espera) as interfaces dos switches da topologia (com base em sua ociosidade) e;

• Componente de Ativa¸cão de SWitches (ASW): que tem como fun¸cão ativar todas as interfaces de switches capazes de interligar, através de múltiplos caminhos (quando poss´ıvel), os hosts (origem e destino) que desejam se comunicar.

Estes componentes s˜ao explicados, com detalhes, no Cap´ıtulo 3.

1.1 OBJETIVOS

O principal objetivo deste trabalho foi desenvolver uma estratégia para redes de centros de dados, utilizando algumas inova¸cões capazes prover o aumento do desempenho nas comunica¸cões, além de possibilitar a redu¸cão do consumo energético nos equipamentos de comuta¸cão, sem prejudicar a redundância t´ıpica existente em topologias hierárquicas, como a Fat-Tree. A virtualiza¸cão de rede e a utiliza¸cão de protocolos que permitem execu¸cão através de múltiplos caminhos são exemplos deste quesito.

(28)

4 INTRODUC¸ ˜AO

Como objetivos espec´ıficos, tem-se:

1. Compreender o estado atual em que operam os centros de dados modernos no que tange a seus padrões de tráfego bem como às suas limita¸cões e desafios quanto ao consumo energético;

2. Conhecer e testar ferramentas que possam contribuir para melhoria de rendimento nas comunica¸cões, eficiência energética e redundância em centros de dados;

3. Propor e implementar uma heur´ıstica capaz de prover eficiência energética para os equipamentos de interconexão de tais redes (switches e roteadores), operando sobre o Multipath TCP (MPTCP) e o OpenFlow ;

4. Criar um ambiente/cenário experimental no qual seja poss´ıvel validar a implementa¸cão proposta com o intuito de prover uma melhor utiliza¸cão da energia nos ambientes computacionais.

1.2 METODOLOGIA

O passo inicial para a constru¸cão deste trabalho foi a realiza¸cão de uma revisão sistemática sobre redes de centro de dados e eficiência energética. Através deste levantamento do estado da arte, foram verificados as ferramentas e solu¸cões que pudessem contribuir para o cumprimento dos objetivos desta obra.

As etapas efetuadas, de forma interdependente, para a confeçcão deste trabalho foram: • Na etapa 1 foram verificadas as limita¸cões e desafios existentes no

contexto da eficiˆencia energ´etica em redes de centro de dados. Fator que norteou os objetivos deste trabalho;

• Na etapa 2 foram verificadas as ferramentas e solu¸cões que poderiam ser aplicadas à esta pesquisa, capazes de inovar e melhorar a forma de propor novas solu¸cões, além de facilitar sua constru¸cão. Em outras palavras, utilizar ferramentas com o melhor custo/benef´ıcio para a necessidade estudada;

• Na etapa 3 a estratégia BEEP foi implementada e configurada. Ao término desta etapa, foi criado um ambiente composto de tecnologias capazes de contribuir com a estratégia proposta. Ademais, foram definidas e configuradas métricas capazes de mensurar o potencial da estratégia;

• Na etapa 4, foi realizada uma análise experimental da estratégia. Foram emulados cenários de utiliza¸cão de um centro de dados baseados na topologia Fat-Tree, nos quais foram realizados experimentos capazes de representar o comportamento o mais próximo poss´ıvel da realidade destas infraestruturas. Em seguida foram coletados os dados impostos pelas métricas da BEEP. Ao término desta etapa, foi realizado um

(29)

1.3 ORGANIZAC¸ ˜AO 5

estudo anal´ıtico, com base na estat´ıstica descritiva, capaz de mensurar e avaliar o potencial da estrat´egia;

• Por fim, na etapa 5, foram realizados comparativos da estratégia BEEP com algumas solu¸cões já existentes na literatura, fruto de pesquisas na ´

area de propostas correlatas a BEEP para as redes de centro de dados.

1.3 ORGANIZAC¸ ˜AO

A presente disserta¸c˜ao est´a organizada da seguinte forma:

• No Cap´ıtulo 2 são apresentados os fundamentos básicos para o entendimento do problema, que perpassa pelo levantamento bibliográfico quanto às redes de centro de dados, as arquiteturas utilizadas em um centro de dados, eficiência energética em centro de dados e propostas para eficiência energética em elementos de centro de dados;

• No Cap´ıtulo 3 é apresentado a estratégia BEEP e cada um dos componentes que a integram: o Fat-Tree Manager, o DSW e o ASW; • No Cap´ıtulo 4 é apresentado o ambiente experimental constru´ıdo para

valida¸cão e mensura¸cão do potencial da estratégia, utilizando os recursos oferecidos pela SDN e OpenFlow ;

• No Cap´ıtulo 5 são apresentados os resultados obtidos através da análise experimental com a BEEP, além da discussão a respeito deles;

• Por fim, no Cap´ıtulo 6 são apresentadas as conclusões acerca deste trabalho, bem como as limita¸cões da estratégia, contribui¸cões e propostas para trabalhos futuros.

Dado o exposto, neste Cap´ıtulo foram explanados alguns dos inúmeros desafios encontrados nos centros de dados atuais. Também foi poss´ıvel notar que nem sempre é poss´ıvel resolver estes problemas por completo, já que as vezes tentar resolver um destes problemas acaba gerando um outro problema a ser solucionado. No Cap´ıtulo seguinte será mostrado como são concebidas as arquiteturas de um centro de dados, como seu consumo é distribu´ıdo, bem como algumas solu¸cões utilizadas para a melhoria destas infraestruturas.

(30)

(31)

Cap´ıtulo

2

Neste cap´ıtulo é apresentado um breve referencial teórico acerca das Redes de Centro de Dados (DCNs), bem como é apresentado como é realizado a eficiência energética nestas infraestruturas e as propostas existentes para eficiência energética em elementos da DCN.

REDES DE CENTRO DE DADOS - DCN

Um centro de dados é uma instala¸cão criada para centralizar e hospedar recursos de computa¸cão, utilizando a infraestrutura de comunica¸cão para armazenamento de dados, aplica¸cões e hospedagem (SHUJA et al., 2012).

A era atual marca o in´ıcio da computa¸cão Exascale (HPE, 2008). Os centros de dados Exascale são projetados para operar com um poder de computacional de 1.018 opera¸cões de ponto flutuante (flops) por segundo. Consequentemente, o número de servidores hospedados em um centro de dados vem crescendo exponencialmente, aumentando, assim, o papel das redes de centro de dados, do inglês Data Center Network (DCN), responsável por conectar centenas de milhares de servidores.

Com este aumento crescente da demanda dos centros de dados, muitos dos componentes da TI que est˜ao integrados a eles, como servidores e dispositivos para armazenamento e interconex˜ao, tem sido objeto de estudo a fim de melhorar a forma como executam as suas tarefas.

Como os centros de dados atuais são limitados pelas redes de interliga¸cão, ao invés do poder computacional (BERGMAN, 2010), na qual um gargalo pode resultar na perda da escalabilidade, a DCN vem sendo considerada a espinha dorsal da comunica¸cão em um centro de dados e, por este motivo, é uma de suas maiores preocupa¸cões (BILAL et al., 2013). Este fator impõe a DCN desafios cr´ıticos em termos de: i) escalabilidade, ii) tolerância à falhas, iii) eficiência energética, e iv) largura de banda (BILAL et al., 2013). Esta preocupa¸cão têm motivado pesquisadores a buscarem solu¸cões que auxiliem na resolu¸cão destes problemas enfrentados pelas DCNs.

2.1 ARQUITETURAS UTILIZADAS EM REDES DE CENTRO DE DADOS Os inúmeros problemas obtidos em centros de dados convencionais impulsionaram os pesquisadores a projetar e propor diversas arquiteturas capazes de atender a necessidade encontrada em cada cenário espec´ıfico de utiliza¸cão.

(32)

8 REDES DE CENTRO DE DADOS - DCN

Atualmente, as arquiteturas existentes para os centros de dados podem ser classificadas, principalmente, em duas classes:

• switch-centric: arquiteturas em que os switches e os equipamentos utilizados para comuta¸c˜ao e roteamento s˜ao os componentes dominantes da topologia; e

• server-centric: arquiteturas nas quais existem servidores com múltiplas interfaces de rede que são responsáveis pelo roteamento de pacotes e decisões de encaminhamento da topologia.

Nos centros de dados convencionais a arquitetura mais utilizada ´e a switch-centric (HAMMADI; MHAMDI, 2014). Alguns exemplos desta topologia incluem a Fat-Tree (AL-FARES; LOUKISSAS; VAHDAT, 2008), Portland (MYSORE et al., 2009), VL2 (GREENBERG et al., 2011), e Monsoon (GREENBERG et al., 2008).

Por outro lado, as arquiteturas server-centric tem atra´ıdo grande interesse de pesquisadores e muitos projetos j´a foram propostos como o BCube (GUO et al., 2009), DCell (GUO, 2012), FiConn (LI et al., 2009), dentre outros.

2.1.1 Centros de dados definidos por software

Nas últimas décadas, muitos trabalhos têm sido propostos com o intuito de virtualizar servidores e automatizar seu gerenciamento e provisionamento. Devido à complexidade existente nas redes atuais, os pesquisadores têm tentado implementar nos servidores os mesmos recursos de virtualiza¸cão e gerenciamento semelhantes aos existentes para armazenamento.

Atualmente, os centros de dados precisam de uma configura¸cão de rede automatizada, capaz de permitir que switches e roteadores (tanto f´ısicos quanto virtuais rodando em máquinas virtuais dentro de hypervisors), sejam reconfigurados instantaneamente, reagindo às condi¸cões atuais da rede. Entretanto, como cada fabricante de switches e roteadores possuem suas próprias ferramentas de gerenciamento, além de “proteger” suas ideias, ao administrador da rede cabe apenas utilizar aqueles recursos existentes nos mesmos, ainda que sejam limitados para sua necessidade (MORGAN, 2016).

Foi com o propósito de virtualizar a rede e seus equipamentos de intercomunica¸cão, além de permitir uma maior flexibilidade nas tarefas realizadas pelos centros de dados que as Redes Definidas por Software (do inglês, Software-Defined Network - SDN) adentraram nestas estruturas.

Através do uso da SDN, o poder de controlar as tarefas lógicas realizadas em um centro de dados ficam a cargo dos administradores de redes, aos quais é poss´ıvel implementar, de diversas formas diferentes, virtualiza¸cão e automatiza¸cão da rede. Assim como há mais de uma maneira de virtualizar um servidores e automatizar o provisionamento e o gerenciamento de máquinas virtuais (KREUTZ et al., 2015).

(33)

2.1 ARQUITETURAS UTILIZADAS EM REDES DE CENTRO DE DADOS 9

Figura 2.1 Camadas da SDN. Adaptado de (KREUTZ et al., 2015).

• Plano de gerenciamento: Inclui os servi¸cos de software, como ferramentas baseadas em protocolos de gerenciamento de rede, como o SNMP, utilizado para monitorar e configurar remotamente a funcionalidade dos equipamentos;

• Plano de controle: Representa os protocolos usados para preencher as tabelas de encaminhamento dos elementos do plano de dados;

• Plano de dados: Corresponde aos dispositivos de rede, que s˜ao respons´aveis pelo encaminhamento de dados.

Nos dias atuais, o principal produto da SDN é o protocolo OpenFlow (MCKEOWN et al., 2008). Na Figura 2.2 é poss´ıvel visualizar a implementa¸cão de um switch OpenFlow. Nela é poss´ıvel notar que o switch divide o switch em duas partes:

• Secure Channel: se refere ao plano de controle da SDN. Nele são inseridas todas as regras necessárias para os encaminhamos de pacotes. Em outras palavras, é a parte inteligente do switch, na qual são inseridas e administradas as regras pelo controlador OpenFlow através de criptografia SSL;

• Flow Table: se refere `a tabela de fluxos de encaminhamentos. Ou seja, tem a fun¸c˜ao apenas de realizar os encaminhamentos solicitados pela camada Secure Channel, sem fazer tratamentos mais elaborados.

Este recurso trazido pela SDN e pelo protocolo OpenFlow permitem, aos administradores de redes, a cria¸cão de regras dinâmicas, capazes de atender às mais complexas demandas de tráfego. Por este motivo, o OpenFlow vem sendo muito utilizado em infraestruturas de centro de dados.

(34)

Figura 2.2 Representa¸c˜ao de um switch OpenFlow (MCKEOWN et al., 2008).

2.1.2 Arquiteturas com m´ultiplos caminhos

Uma vez que as infraestruturas de centro de dados tem como obriga¸c˜ao atender a norma ANSI/TIA-9421_{, que define como os centro de dados devem ser constru´ıdos,}

além de especificar as melhores práticas para sua utiliza¸cão, o uso de mecanismos que promovam redundância de equipamentos e liga¸cões é um fator indispensável. Logo, em uma estrutura que há redundância de liga¸cões entre hosts e equipamentos explorar este recurso é fundamental. Neste sentido, algumas pesquisas vêm sendo criadas com o intuito de explorar estes múltiplos caminhos, como o Equal-Cost Multi-Path routing (ECMP), o DataCenter TCP (DCTCP), o MultiPath TCP (MPTCP), dentre outros.

O ECMP (HOPPS, 2000), é um algoritmo que realiza cálculos métricos de roteamento a fim de calcular todos os saltos entre todos as liga¸cões existentes na infraestrutura de rede. Desta maneira, o ECMP é capaz de explorar os vários caminhos existentes em uma infraestrutura de rede, fazendo com que o encaminhamento de pacotes para um próximo salto tenha como origem vários “melhores caminhos” para um único destino. Uma outra vantagem do ECMP, é que ele pode ser usado, em conjunto, com a maioria dos protocolos de roteamento existentes, o que possibilita ao administrador a cria¸cão uma infraestrutura h´ıbrida capaz de atender suas necessidades. Por este motivo, o ECMP é considerado o protocolo multi caminhos mais usado em centros de dados. Entretanto, já há alguns estudos que demonstram que o ECMP não utiliza corretamente a largura de banda dispon´ıvel em uma rede, o que motiva a cria¸cão de outras estratégias que atenuem este problema (PAASCH; KHALILI; BONAVENTURE, 2013).

O DCTCP (ALIZADEH et al., 2010) é um um aprimoramento do algoritmo de controle de congestionamento TCP para redes de centro de dados. Ele aproveita o Explicit Congestion Notification (ECN), um recurso que está cada vez mais dispon´ıvel em switches dos centros de dados modernos. O DCTCP extrai os bits de feedback do congestionamento e através dos rótulos ECN ele consegue estimar a fra¸cão de pacotes

(35)

2.1 ARQUITETURAS UTILIZADAS EM REDES DE CENTRO DE DADOS 11

rotulados. Este n´ıvel de controle permite ao DCTCP operar com ocupa¸c˜oes de buffer reduzidas, ao passo que consegue diminuir o tempo de envio de cada pacote trafegado.

Já o MPTCP (BARRÉ; PAASCH; BONAVENTURE, 2011), visa fazer uso simultâneo de múltiplos caminhos disjuntos (ou parcialmente disjuntos) através de uma rede. Entre os principais benef´ıcios desta recurso, podemos citar: i) o aumento da resiliência da conectividade, uma vez que o tráfego é encaminhado por múltiplos caminhos, o sistema continua a transmitir mesmo diante da falha de algum caminho (ou host ); e ii) o aumento da eficiência da utiliza¸cão de recursos, dado que o gargalo na rede é diminu´ıdo, aumentando assim a capacidade de tráfego (largura de banda) dispon´ıvel na rede. Desta forma, o MPTCP permite a utiliza¸cão de vários caminhos fim-a-fim, nos quais um ou ambos os hosts finais fornecem vários servi¸cos, provendo uma melhor utiliza¸cão dos recursos dispon´ıveis na rede. Além disso, o MPTCP possui a funcionalidade de ser roteado por portas em redes em que as aplica¸cões possuam vários caminhos, assim como o ECMP.

A Figura 2.3 mostra a principal diferen¸ca entre a arquitetura convencional do TCP e o MPTCP. Em um kernel com o MPTCP habilitado, o componente TCP é dividido em um componente MPTCP com vários subfluxos (na forma de conexões convencionais TCP) para cada interface. Para que haja comunica¸cão, o componente MPTCP recebe um fluxo de bytes da aplica¸cão (o MPTCP utiliza uma API de soquete sem modifica¸cões e semântica do TCP para que os aplicativos não precisem ser adaptados), e em seguida divide o fluxo de bytes em vários segmentos, que são entregues aos componentes de subfluxos TCP. O que diferencia o MPTCP das conexões TPC convencionais é a inser¸cão do MP CAPABLE no campo de op¸cões (options) do pacote IP.

Figura 2.3 Fluxos TCP e MPTCP. Adaptado de (POL et al., 2012).

Além de dividir o tráfego da rede em subfluxos TCP o componente MPTCP implementa outras fun¸cões, sendo as mais destacadas:

• Gerenciamento de caminhos através da deteçcão e uso de vários caminhos para um destino. Essa fun¸cão consulta o host (com MPTCP) que inicia o tráfego de dados e verifica se ele oferece a capacidade de receber fluxos adicionais e caso positivo quantos subfluxos podem ser adicionados a esta conexão;

• Escalonador de pacotes. Que tem como fun¸cão dividir o fluxo de bytes recebidos da aplica¸cão em vários segmentos e transmitir esses segmentos em um dos subfluxos

(36)

dispon´ıveis. Estes segmentos s˜ao numerados, de modo que o receptor MPTCP possa colocar os segmentos na ordem correta e reconstruir o fluxo de bytes de origem; • Controle de congestionamento em todos os subfluxos. Esta fun¸c˜ao distribui a carga

sobre os subfluxos dispon´ıves. Quando um subfluxo fica congestionado, o tráfego é movido para um subfluxo menos congestionado. Esta fun¸cão também cuida das retransmissões de outros subfluxos quando esses vem a falhar.

Quando uma conexão MPTCP é iniciada é utilizada a mesma sinaliza¸cão para que uma conexão TCP convencional usa, porém os pacotes SYN, SYN/ACK e ACK carregam consigo a op¸cão MP CAPABLE. Esta op¸cão é variável e serve para dois propósitos: i) verificar se o host remoto suporta Multipath TCP; e ii) permitir que os hosts troquem algumas informa¸cões para autenticar o estabelecimento de subfluxos adicionais.

Na Figura 2.4 é mostrado como o MPTCP processa a comunica¸cão entre dois hosts com duas interfaces de rede (FORD; RAICIU; HANDLEY, 2012). Vale salientar que a organiza¸cão e a forma como a comunica¸cão é apresentada na Figura 2.4 é apenas para melhorar a didática. O MPTCP pode ser executado em hosts com n-interfaces (tendo seu rendimento prejudicado quando operado em apenas uma interface por conta do gargalo gerado) e a comunica¸cão entre elas pode realizada das mais diferentes combina¸cões poss´ıveis.

Figura 2.4 Comunica¸c˜ao atrav´es do MPTCP. Baseada no Internet-Draft (FORD; RAICIU; HANDLEY, 2012).

Seguindo o exemplo da Figura 2.4, o MPTCP inicia sua comunica¸cão semelhante a uma conexão TCP convencional, com uma sequência de SYN, SYN/ACK, e ACK. Como

(37)

2.2 EFICI ˆENCIA ENERG ´ETICA EM REDES DE CENTRO DE DADOS 13

o host H1 fornece o MPTCP, ele adiciona a op¸cão MP CAPABLE ao pacote SYN enviado ao host H2. Este campo da op¸cão além do MP CAPABLE também contém sua chave de autentica¸cão, os parâmetros necessários para a cria¸cão de subfluxos, além de dados adicionais para indicar se serão necessárias somas de verifica¸cão e, caso haja, qual o algoritmo de criptografia a ser usado. Uma chave de autentica¸cão de 64 bits é utilizada para autenticar os futuros subfluxos adicionais para esta conexão MPTCP. Neste caso, como o host H2 fornece o MPTCP, ele responde ao host H1 com um pacote SYN/ACK com a op¸cão MP CAPABLE, além de sua chave de autentica¸cão e as flags. Se o host H2 não possu´ısse o MPTCP, ele não entenderia a op¸cão MP CAPABLE e responderia com um SYN/ACK (sem o MP CAPABLE), então o host H1 continuaria o processamento e realizaria uma conexão TCP convencional (sem o MPTCP). Como neste exemplo o host H2 possui o MPTCP, o host H1 irá responder com um ACK com a op¸cão MP CAPABLE, além das chaves de autentica¸cão do host emissor e do host receptor e suas flags. Isso completa a configura¸cão inicial da conexão MPTCP.

Já as conexões de subfluxos adicionais podem ser iniciadas por qualquer um dos lados, mas normalmente eles são iniciadas pelo host que fez a configura¸cão da conexão inicial. Assim como na conexão inicial do MPTCP, os subfluxos adicionais são configurados de forma similar à configura¸cão de uma conexão TCP convencional com a troca de pacotes SYN, SYN/ACK e ACK, mas no caso de subfluxos estes pacotes contêm a op¸cão MP JOIN - que tem como fun¸cão identificar a conexão a ser unida pelo novo subfluxo.

A op¸cão MP JOIN em pacotes com a flag SYN também inclui 4 bits de flags, 3 dos quais são atualmente reservados e deve ser ajustado para zero pelo remetente. Uma outra fun¸cão do MP JOIN é sinalizar se o subfluxo a ser criado será utilizado como um caminho de backup, em caso de falha de algum outro caminhos, ou usado imediante sem a op¸cão de backup.

No exemplo da Figura 2.4, a configura¸cão da conexão do subfluxo adicional é iniciada quando o host H1 envia para o host H2 um pacote SYN com a op¸cão MP JOIN, um token, um número aleatório (nonce), uma identifica¸cão de endere¸co e as flags. O token é um hash criptografado (SHA-1) contendo a chave do host H1 (os 32 bits mais significativos). Este hash pode ser utilizado pelo host H2 para identificar a conexão. O número aleatório (de uso único) é usado para evitar ataques de repeti¸cão do método de autentica¸cão. O ID identifica o endere¸co atribu´ıdo a interface do host emissor (neste caso, a interface eth1 do host H1). A identifica¸cão de endere¸co permite a remo¸cão de endere¸co sem a necessidade de saber qual é o endere¸co de origem no receptor, permitindo assim a remo¸cão de endere¸co através de NAT (do inglês, Network Address Translator ). As flags podem ser utilizadas pelo host de origem para informar a outros hosts para utilizar um dado subfluxo imediatamente ou usá-lo como redundância caso os outros caminhos falhem.

2.2 EFICIˆENCIA ENERG´ETICA EM REDES DE CENTRO DE DADOS

Segundo (BELOGLAZOV et al., 2011) o consumo energ´etico de um centro de dados pode ser classificado em duas partes:

(38)

equipamentos para interconex˜ao de redes, dispositivos de armazenamento, dentre outros, e;

2. o consumo de energia dos equipamentos que mantˆem sua infraestrutura f´ısica: sistemas de refrigera¸c˜ao e de reserva de energia).

A quantidade de energia consumida por estes dois subcomponentes depende da fun¸cão do centro de dados, bem como da eficiência dos seus equipamentos. Por exemplo, de acordo com (BUYYA; BELOGLAZOV; ABAWAJY, 2010) o maior consumo de energia em um centro de dados t´ıpico é a infraestrutura de refrigera¸cão, que representa 50% do total gasto com energia pelo centro de dados (HEDDEGHEM et al., 2014), enquanto os servidores e dispositivos de armazenamento ocupam o segundo lugar na hierarquia do consumo de energia, representando um total de aproximadamente 26%.

A abordagem gen´erica para gerenciar o consumo de energia de um centro de dados consiste em quatro etapas principais:

• Extra¸cão de caracter´ısticas: a fim de reduzir o consumo de energia de um centro de dados, faz-se necessário medir o consumo energético de seus componentes (BROWN; REAMS, 2010), e identificar onde a maior parte da energia é consumida;

• Constru¸cão do modelo: as caracter´ısticas coletadas são selecionadas e usadas para construir um modelo de consumo de energia utilizando técnicas de análise, tais como regressão, aprendizagem de máquina, dentre outras. Um dos principais problemas enfrentados nesta etapa é que certos parâmetros importantes do sistema, como o consumo de energia de um componente em particular não pode ser medidos de forma direta. Além disso, os métodos de análise clássicos podem não produzir resultados precisos em tais situa¸cões e as técnicas de aprendizado de máquina podem obter resultados melhores. O resultado desta etapa é um modelo de potência do centro de dados; • Valida¸cão do modelo: em seguida, o modelo deve ser validado através

de uma an´alise experimental com o intuito de verificar se o mesmo atende aos fins previstos (HAMMADI; MHAMDI, 2014);

• Uso do modelo: finalmente, o modelo identificado pode ser usado como a base para predizer o componente ou o consumo de energia do sistema utilizado. Tais previsões podem, então, ser usadas para melhorar a eficiência energética do centro de dados, por exemplo, incorporando o modelo em técnicas tais como a redu¸cão de temperatura ou a programa¸cão do consumo de energia pelos equipamentos (BELLOSA, 2000), escalonamento da frequência de tensão dinâmica (Dynamic Voltage and Frequency Scaling - DVFS) (JING et al., 2013), recursos de virtualiza¸cão (LIU et al., 2011), melhoria dos algoritmos utilizados pelas aplica¸cões (BELOGLAZOV; BUYYA, 2010), a mudan¸ca para estado de baixa potência (do inglês,

(39)

2.3 PROPOSTAS PARA EFICI ˆENCIA ENERG ´ETICA EM ELEMENTOS DA DCN 15

switching to low-power states) (FELLER et al., 2012), o nivelamento do consumo (do inglˆes, Power Capping) (LEFURGY; WANG; WARE, 2008), ou desligar completamente servidores n˜ao utilizados na topologia (LIN et al., 2013), dentre outros, com o intuito de tornar o consumo de energia de um centro de dados mais eficiente. No entanto, ´

e poss´ıvel notar que possuir um modelo para redu¸cão do consumo de energia nem sempre significa que o consumo será previsto com antecedência, já que o volume de dados trafegados são alterados de forma dinâmica e imprevis´ıvel.

Entretanto, o principal desafio técnico encontrado pelos esquemas de economia de energia é um tradeoff existente entre a redu¸cão do consumo de energia e a degrada¸cão do desempenho da rede (DAYARATHNA; WEN; FAN, 2016). Intuitivamente, objetivando economizar energia, os administradores de rede poderiam prover menos recursos de equipamentos de comuta¸cão ou servidores, porém este fator diminuiria a capacidade dos servi¸cos de rede, assim como degradaria seu desempenho e redundância. Por conseguinte, encontrar um equil´ıbrio entre redu¸cão de consumo energético, desempenho e redundância tem se tornado um desafio para projetistas de esquemas de redu¸cão do consumo de energia para centros de dados.

2.3 PROPOSTAS PARA EFICIÊNCIA ENERGÉTICA EM ELEMENTOS DA DCN A ideia de reduzir os consumos de energia dos elementos de rede na Internet foi inicialmente proposto em 2003, com a sugestão de explorar a possibilidade de colocar alguns componentes em estado de espera durante algum per´ıodo de tempo (GUPTA; SINGH, 2003). Nos anos seguintes, muitas pesquisas sobre esse tema foram propostas e desde então vem sendo amplamente pesquisadas (BOLLA et al., 2011; ZHANG et al., 2010; BIANZINO et al., 2012). No entanto, a maioria dos esquemas propostos visam a economia de energia em elementos de redes genéricos, com apenas alguns deles no ˆ

ambito de elementos de redes DCN. Portanto, nesta se¸cão serão expostos os esquemas para economia de energia que foram especificamente propostas no interesse das DCN’s e que possuem correla¸cão direta com a estratégia BEEP.

(MAHADEVAN et al., 2009b), compararam o consumo de energia de vários switches e roteadores em diferentes cenários de tráfego. Eles obtiveram a conclusão de que os seus consumos de energia são determinados principalmente por dois fatores: i) o quantidade de portas ativas em cada equipamento e ii) a largura de banda configurada para cada porta. Em suas conclusões também foi diagnosticado que as cargas de tráfego reais nas interfaces de rede não possuem impacto significativo no consumo de energia. Estas conclusões são consideradas de suma importância, pois elas se tornaram a base para um estudo mais aprofundado sobre os regimes de economia de energia de elementos de redes DCN como visto em (MAHADEVAN et al., 2009a) e (MAHADEVAN; BANERJEE; SHARMA, 2010).

Em (MAHADEVAN; BANERJEE; SHARMA, 2010), foi realizado um estudo com base em medi¸cões em uma DCN operacional com 90 switches ativos. As configura¸cões e informa¸cões de tráfego de cada switch foram configuradas a partir da Management

(40)

Information Base (MIB) do Simple Network Management Protocol (SNMP), e seu consumo de energia foi implementando com o modelo obtido a partir de (MAHADEVAN et al., 2009b). Com base nos resultados emp´ıricos publicados, foi sugerido que a implementa¸cão de algumas opera¸cões consideradas simples poderiam reduzir o consumo de energia nos switches em até 36%. Tais opera¸cões incluem desligar portas não utilizadas, adaptar a velocidade máxima configurada nas portas, e consolidar as portas necessárias para comunica¸cão em uma quantidade menor de switches. No entanto, o estudo não considerou restri¸cões de desempenho, como por exemplo, a velocidade do link enquanto as a¸cões para economizar energia são inseridas. Além disso, como as estratégias propostas foram baseadas em dados de rastreamento de tráfego históricas, faltou um esquema capaz de prever a carga de trabalho real.

Em (MAHADEVAN et al., 2009a), foram propostos trˆes esquemas para economizar energia:

• Adapta¸c˜ao de Estados dos Links, Link State Adptation (LSA), que adapta a velocidade m´axima, de cada link, de acordo com sua carga real;

• Consolida¸cão de Tráfego de Rede, Network Traffic Consolidation (NTC), que é uma abordagem de engenharia de tráfego que agrupa todo o tráfego de rede para uma quantidade menor de switches e links, enquanto switches e links não utilizados podem ser desativados e; • Consolida¸cão de Carga do Servidor, Server Load Consolidation (SLC),

que consolida as cargas de trabalho na menor quantidade poss´ıvel de servidores com o prop´osito de diminuir a quantidade de switches e interfaces utilizadas.

Também foi aplicado uma restri¸cão no desempenho em cada esquema para estabelecer mais três servi¸cos baseados em n´ıveis, level-aware (SL- aware). O objetivo principal destes seis esquemas é usar o menor número de switches e interfaces para encaminhar o tráfego na rede. Além disso, como alguns elementos de rede estão desativados para economizar energia, a disponibilidade da rede serão inevitavelmente reduzida. Esse trade-off foi investigado sob os seis regimes, em um trace real com tráfego Web, e observou-se que o SLC alcan¸cou uma economia de energia máxima de 75%. Em contraste, os três esquemas SL-aware alcan¸caram uma disponibilidade muito maior da rede, enquanto que a economia de energia gerada eram muito piores que o SLC.

Com objetivo semelhante, (SHANG; LI; XU, 2010) propuseram um modelo com o objetivo de minimizar a quantidade de switches ativos em uma DCN sujeita a um determinado padrão de tráfego e restri¸cão de desempenho. O throughput da rede foi utilizado como métrica de desempenho. No modelo, os fluxos de tráfegos foram ajustados para serem indivis´ıveis com a inten¸cão de evitar o desordenamento de pacotes. O modelo foi provado ser NP-hard e uma heur´ıstica foi proposta, da qual os resultados da economia de energia foram promissores. No entanto, por se tratar de um esquema offline implementado em um modelo NP-hard, ele possui uma escalabilidade ineficiente além de uma alta complexidade, motivo pelo qual tem limitado a sua viabilidade em redes de centros de dados em grande escala com milhares de switches.

(41)

(SI; TAHERI; ZOMAYA, 2012) propuseram um esquema distribu´ıdo para redu¸cão do consumo energético chamado “eAware”, que atua examinando os tamanhos e taxas de ocupa¸cão das filas e a utiliza¸cão de portas dos switches. Com base nestes elementos, ele pode colocar alguns equipamentos em modo de espera para que seja economizado energia. A ideia principal do “eAware” é que, se um comprimento de fila ou a taxa de ocupa¸cão de uma porta ultrapasse um certo limite, outras portas deverão ser ativadas para diminuir o tamanho das filas; e se uma porta possui a fila com tamanho zero e a sua utiliza¸cão baixa, ela será desativada; se todas as portas de um switch estiver em modo de espera, o switch também será desativado. Os resultados das simula¸cões mostram que o “eAware” pode economizar na ordem de 30% a 50% de energia no centro de dados.

(BOTERO et al., 2012) apresentaram um problema com uma rede virtual dotada de um reconhecimento de consumo energético na qual o objetivo é atribuir um grupo de redes virtuais a um grupo reduzido de equipamentos de rede, em seguida os switches não utilizados, bem como suas portas são desligados. Os autores propuseram o Mixed Integer Program (MIP) para resolver este problema. Resultados obtidos através de simula¸cões demonstraram que quando o o tráfego da rede é baixo, o esquema proposto consegue diminuir o consumo de energia em até 35%.

(XU et al., 2013) propõem um algoritmo de roteamento, chamado de throughput-guaranteed power-aware routing, capaz de garantir o throughput das conexões. A ideia principal da proposta é usar o m´ınimo poss´ıvel de energia da rede para fornecer o servi¸co de roteamento, enquanto ele define o throughput da rede. O algoritmo de roteamento proposto, tomando como base algumas topologias, calcula as rotas para os fluxos de tráfego e o throughput da rede (chamada de roteamento básico) além da taxa básica. Em seguida, ele remove os switches e links envolvidos no roteamento básico, de acordo com as cargas de trabalho dos switches até que o throughput da rede atinja o limite inferior. Finalmente os links e switches que não estão envolvidos na topologia final são colocados em modo de espera. Resultados obtidos por simula¸cões mostram que o algoritmo de roteamento proposto pode economizar energia em centros de dados sob cargas de rede baixa.

Por fim, nas próximas Se¸cões serão apresentados os trabalhos mais relevantes relacionados ao ajuste dinâmico dos elementos ativos com gerenciamento de energia: o ElasticTree, o PCube e o HERO.

2.3.1 ElasticTree

A ElasticTree (HELLER; SEETHARAMAN; MAHADEVAN, 2006), representada na Figura 2.5, é uma topologia de centro de dados baseada na Fat-Tree, que consiste de um otimizador de rede que monitora continuamente as condi¸cões de tráfego dentro do centro de dados.

A ElasticTree consiste em três módulos lógicos: otimizador, roteamento e controle de energia (como mostrado na Figura 2.6). O papel do otimizador é encontrar o subconjunto m´ınimo da rede, a fim de satisfazer as demandas de tráfego (mantendo um desempenho aceitável). Uma vez que o otimizador analisa a matriz de tráfego, ele seleciona o conjunto m´ınimo de equipamentos necessários para satisfazer as demandas, em seguida, ele passa

(42)

Figura 2.5 Topologia ElasticTree (HELLER; SEETHARAMAN; MAHADEVAN, 2006)

as informa¸cões para os módulos de potência e de roteamento, que por sua vez, controlam o ativa¸cão e desativa¸cão de links, assim como os caminhos aos quais devem ser seguidos pelos fluxos.

Figura 2.6 O diagrama executado pelos m´odulos da ElasticTree (HELLER; SEETHARAMAN; MAHADEVAN, 2006)

O objetivo de otimiza¸cão realizada pela ElasticTree é minimizar a quantidade de equipamentos ligados, enquanto atende a demanda e mantêm as restri¸cões de conserva¸cão de fluxos. A economia de energia pode ser calculada ao considerar a rela¸cão entre a energia consumida pela ElasticTree e a energia consumida pela Fat-Tree. Nos experimentos,

(43)

Figura 2.7 Modelo do modelo experimento criado pela ElasticTree para uma topologia Fat-Tree k = 4 (HELLER; SEETHARAMAN; MAHADEVAN, 2006). Cada NetFPGA emulam 4 servidores com conex˜oes de 1GB.

quatro NetFPGA representando 16 servidores foram usadas para gerar tr´afego, e um monitor de latˆencia foi utilizado para coletar as perdas e atrasos ocorridas com os pacotes (como mostrado na Figura 2.7).

Vários métodos são propostos por seus autores com o intuito de decidir qual subconjunto de links e switches devem ser usados em cada comunica¸cão. Estes métodos podem ser “gananciosos” (como o greedy bin-packer ), uma heur´ıstica chamada de “topologia consciente”, ou uma tentativa de prever o tráfego da rede. Foi mostrado que estes métodos, podem alcan¸car a economia de energia entre 25% a 40%.

2.3.2 PCube

Além de trabalhos baseados em topologias centradas em switches, isto é, switch-centric, os pesquisadores também investigaram como melhorar a eficiência de energia, em topologias server-centric, através do ajuste dinâmico da estrutura da rede com base nas demandas de tráfego. A inten¸cão destes estudos era mensurar se era poss´ıvel obter a mesma economia de energia concentrando a comuta¸cão de pacotes nos servidores.

Centro de dados modulares, com topologias centradas em servidores, como a BCube, pode oferecer alta largura de banda com velocidade suficiente para atender demandas de alto desempenho para aplica¸c˜oes um-para-um, um-para-todos e todos-para-todos.

A PCube (HUANG et al., 2011), como mostrado na Figura 2.8, é representada como PCube (n, k, q), no qual n é o número de portas dos switches, k é a quantidade de n´ıveis da topologia e q é o número de portas em cada servidor.

PCube é um projeto que se apoia na computa¸cão adaptativa com a capacidade de desligar links, dependendo dos padrões de tráfego, dentro de uma rede de centro de dados. Quando a demanda de tráfego está baixa, a PCube reduz a quantidade de links

(44)

Figura 2.8 Estrat´egia PCube mostrando um exemplo das topologias: (a) PCube (2, 4, 4), (b) PCube (2, 4, 3) e (c) PCube (2, 4, 2). Figura adaptada de (HUANG et al., 2011).

na topologia. A Figura 2.8(a) demonstra um exemplo em que a topologia possui uma alta demanda de tráfego. Na Figura 2.8(b), que representa a PCube (2, 4, 3), é mostrado que 25% dos switches estão desligados para economizar 25% da energia consumida. Porém, outra redu¸cão pode ocorrer quando a demanda de tráfego estiver ainda mais baixa, o que a faz desligar mais 8 switches, resultando em uma (2,4,2), como mostrado na Figura 2.8(b), contribuindo para uma economia de 50% na energia gasta pelos switches.

Na PCube, um servidor dedicado, agindo como o gestor de rede, é responsável por receber os pedidos de requisitos de largura de banda de outros servidores e, com base em suas decisões, define a forma como a estrutura pode ser transformada a fim de atender aos seus objetivos. Quando há alguma altera¸cão na topologia, a PCube calcula os novos caminhos de roteamento para a estrutura modificada e transmite a nova estrutura e as informa¸cões de roteamento para todos os servidores. Quando a rede está sobrecarregada, o servidor gestor da rede permite, por alguns segundos a mais, que um dado switch desnecessário permane¸ca ativo até garantir que todos os servidores receberam as mudan¸cas na topologia e tomem suas decisões.

A PCube, em rela¸cão à estratégia ElasticTree, citada na Se¸cão anterior, embora atuem em topologias completamente distintas (server-centric e switch-centric, respectivamente) a solu¸cão PCube (baseada na topologia BCube) proporciona distribui¸cão de tráfego do tipo um-para-todos e com respeito ao consumo de energia, a PCube pode economizar, em até 50%, a energia consumida pela ElasticTree servindo a mesma quantidade de servidores (HUANG et al., 2011).

2.3.3 HERO

O Hierarchical EneRgy Optimization (HERO) ´e um trabalho recente publicado por (ZHANG; ANSARI, 2012, 2015), que visa resolver o problema de otimiza¸c˜ao, de uma

(45)

forma hierárquica, para alcan¸car resultados semelhantes à economia de energia alcan¸cada em modelos não-hierárquicos. Uma vez que as variáveis e restri¸cões são entre 35% a 40% menores em infraestruturas hierárquicas, o HERO consegue reduzir a complexidade de tempo gerada para a tomada de decisões.

No HERO, a otimiza¸cão de energia em redes de centros de dados é dividida em dois n´ıveis: em n´ıvel do núcleo e em n´ıvel do POD. Na otimiza¸cão em n´ıvel do núcleo, os switches core, que servem de sa´ıda de tráfego, e os switches de agrega¸cão, que servem para levar o tráfego para fora do POD, devem estar no modo ativo. Enquanto na otimiza¸cão em n´ıvel do POD, permanecem ativos apenas os switches de agrega¸cão. Estes modos de otimiza¸cão estão descritos na Figura 2.9.

Figura 2.9 Otimiza¸c˜oes realizadas pelo HERO: (a) a n´ıvel do POD, e (b) a n´ıvel do n´ucleo (ZHANG; ANSARI, 2015).

Para uma dada matriz de tráfego, o problema da otimiza¸cão da Constraint Multi-Commodity Flow (CMCF) é formulado para cada n´ıvel da topologia com a proposta de determinar quais os switches e links que devem ser desligados na rede, garantindo simultaneamente a conectividade e Quality of Service (QoS).

Heur´ısticas gulosas, com base em diferentes critérios para switches e links, também foram implementadas com o intuito de encontrar nós e links que possam ser desligados e, portanto, alcan¸car uma economia de energia adicional.

Foram realizadas simula¸cões para diferentes cenários de tráfego e os resultados mostraram que o modelo hierárquico pode conseguir resultados semelhantes à economia de energia alcan¸cada com o modelo não-hierárquico, com uma grande redu¸cão na complexidade do algoritmo.

2.3.4 GreenCloud

A GreenCloud (LIU et al., 2009; KLIAZOVICH; BOUVRY; KHAN, 2012), é uma arquitetura desenvolvida com o propósito de mensurar e reduzir o consumo energético de um Centro de Dados, garantir o desempenho (do ponto de vista do usuário) e, assim, contribuir para a constru¸cão de um Centro de Dados “Verde”. Além de contribuir com os projetos GreenIT2 _{e ECO-CLOUD}3_.

2_{https://greenit.gforge.uni.lu/} 3_{https://ecocloud.gforge.uni.lu/}