UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO Uso de Processamento Paralelo e Distribuído no Plano de Controle de Redes Definidas por Software para Aumento da Eficiência Energética em Redes de Datacenters Tadeu Ferreira Oliveira Orientador: Prof. Dr. Luiz Felipe de Queiroz Silveira Tese de Doutorado apresentada ao Pro- grama de Pós-Graduação em Engenharia Elétrica e de Computação da UFRN (área de concentração: Engenharia de Computação) como parte dos requisitos para obtenção do título de Doutor em Ciências. Natal, RN, Julho de 2021
Transcript
UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
E DE COMPUTAÇÃO
Uso de Processamento Paralelo e Distribuído noPlano de Controle de Redes Definidas por
Software para Aumento da EficiênciaEnergética em Redes de Datacenters
Tadeu Ferreira Oliveira
Orientador: Prof. Dr. Luiz Felipe de Queiroz Silveira
Tese de Doutorado apresentada ao Pro-grama de Pós-Graduação em EngenhariaElétrica e de Computação da UFRN (área deconcentração: Engenharia de Computação)como parte dos requisitos para obtenção dotítulo de Doutor em Ciências.
Natal, RN, Julho de 2021
Oliveira, Tadeu Ferreira. Uso de processamento paralelo e distribuído no plano decontrole de redes definidas por software para aumento daeficiência energética em redes de datacenters / Tadeu FerreiraOliveira. - 2021. 109 f.: il.
Tese (doutorado) - Universidade Federal do Rio Grande doNorte, Centro de Tecnologia, Programa de Pós-Graduação emEngenharia Elétrica e de Computação, Natal, RN, 2021. Orientador: Prof. Dr. Luiz Felipe de Queiroz Silveira.
1. Processamento paralelo - Tese. 2. Eficiência energética -Tese. 3. Redes de computadores - Tese. 4. Redes definidas porsoftware - Tese. I. Silveira, Luiz Felipe de Queiroz. II.Título.
RN/UF/BCZM CDU 004.7:620.91
Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262
Uso de Processamento Paralelo e Distribuído noPlano de Controle de Redes Definidas por
Software para Aumento da EficiênciaEnergética em Redes de Datacenters
Tadeu Ferreira Oliveira
Tese de Doutorado aprovada em 30 de julho de 2021 pela banca examinadora compostapelos seguintes membros:
Prof. Dr. Luiz Felipe de Queiroz SilveiraOrientador
Prof. Dr. Agostinho de Medeiros Brito JuniorExaminador Externo - UFRN
Prof. Dr. Andrey Elísio Monteiro BritoExaminador Externo - UFCG
Prof. Dr. Carlos Avelino de BarrosExaminador Externo - IFRN
Prof. Dr. Samuel Xavier de SouzaExaminador Interno - UFRN
A Soraya e Davi que foram aomesmo tempo porto seguro e vento
amigo nessa tão árdua jornada.
Agradecimentos
Aos meus pais, Dilma e Augusto, que sempre apoiaram minha formação, mesmo quandoisso significou abrir mão das suas.
A Soraya e Davi pelo companheirismo e alegria.
Ao IFRN e os colegas de trabalho por investirem no fortalecimento da formação docente.
Ao professor Luiz Felipe pela confiança especialmente nesses momentos de trabalho re-moto.
For it is far better to know somethingabout everything than to know all
about one thing.(Blaise Pascal)
Resumo
As redes definidas por software têm como principal característica a separação entre a
função de tomada de decisão, que define o plano de controle, da função de encaminha-
mento dos pacotes, que define o plano de dados. Essa separação permitiu que se intro-
duzisse o conceito de programabilidade da rede. Com isto, novas aplicações puderam
ser implementadas para interagir diretamente com o funcionamento das redes. Hoje, es-
sas aplicações permitem que ambientes de datacenters adaptem-se à demanda de maneira
elástica, viabilizando os serviços de computação em nuvem. Neste cenário, os datacen-
ters são os grandes provedores de serviços, e um de seus principais custos é o consumo de
energia na infraestrutra de servidores e de equipamentos de rede. Muitos trabalhos indi-
cam que o uso da SDN em redes de datacenter permite uma melhor eficiência energética,
especialmente no plano de dados. Neste trabalho, apresenta-se uma estratégia de uso do
processamento paralelo e processamento distribuído, com diminuição de frequência dos
elementos processadores, com o objetivo de diminuir o consumo de energia nos controla-
dores de redes definidas por software. A implementação de um controlador paralelo para
uso em um ambiente multi-core homogêneo, bem como uma implementação distribuída
que oferece maior tolerância a falha são apresentadas com foco na eficiência energética.
Foi possível obter um ganho em eficiência energética nos cenários multicore de até 31%
quando comparados com cenários single-core.
Palavras-chave: Redes de computadores, paralelismo, redes definidas por software,
eficiência energética, datacenter.
Abstract
The main feature of the software-defined networks is the separation of the role of
decision-making, known as control-plane, and the role of routing of the packages, known
as data-plane. This separation allowed the introduction of the concept of network pro-
grammability, with which new applications could be implemented to interact directly with
the operation of the networks. Today, these applications enable data center environments
to match demand elastically, enabling cloud computing services. In this scenario, the
datacenters became the prominent service providers, and one of its main costs is the con-
sumption of energy in the infrastructure of servers and network equipment. Many papers
indicate that software-defined network in datacenter networks allows for better energy
efficiency, especially in the data plane. In this work, we present a strategy to – using
parallel processing and distributed processing with lower operating frequency on the pro-
cessing elements – reduce the energy consumption of the controllers on a software-defined
network. The implementation of parallel and distributed versions of an SDN controller
offers a fault-tolerant energy-aware solution to the presented problem. This new multicore
implementation achived up to 31% improvement on energy efficiency when compared to
a singlecore version.
Keywords: Computer Networks, Paralellism, Software Defined Network, Energy Efi-
4.3 Consumo total durante o teste com latência máxima de 5 ms . . . . . . . 62
4.4 Consumo total durante o teste com latência máxima de 6 ms . . . . . . . 63
4.5 Estatísticas, em milissegundos, dos resultados para Latência a 5 ms . . . . 64
4.6 Estatísticas, em milissegundos, dos resultados para Latência a 6 ms . . . . 64
vi
Lista de Símbolos e Abreviaturas
API: Application Program Interface, página 14
BPP: Bin-packing problem, página 36
CapEX: Capital Expenditure, página 3
CNEE: Communication Network Energy Efficiency, página 29
CPP: Controller Placement Problem, página 9
DCiE: Data Center Infrastructure Efficiency, página 29
DCN: Datacenter Network, página 9
EUE: Energy Usage Effectviness, página 29
GIL: Global Interperter Lock, página 46
IaaS: Infrastructure-as-a-Service, página 1
MSR: Model Specific Registers, página 51
NAS: Network Attached Storage, página 55
NoC Network-on-Chip, página 6
NPU: Network Processing Unit, página 24
NPUE: Network Power Usage Effectiveness, página 21
OpEX: Operational Expenditure, página 3
vii
PaaS: Platform-as-a-Service, página 1
PUE: Power Usage Effectiveness, página 29
QoE: Quality of Experience, página 34
RAPL: Running Average Power Limit, página 51
SaaS: Software-as-a-Service, página 1
SDN: Software Defined Network, página 2
SLA Service Level Agreement, página 8
TIC: Tecnologia da Informação e Comunicação, página 21
ToR: Top of Rack, página 11
XaaS: Everything as a Service, página 1
Capítulo 1
Introdução
1.1 Contextualização
As redes de computadores vêm evoluindo desde sua criação, nos primeiros centros de
pesquisa, através de mudanças constantes de tecnologia e adaptação às novas demandas de
seus usuários. Com a introdução de novas aplicações de rede, estes ambientes se tornaram
cada vez mais complexos, tanto para sua manutenção e gerência, como na adaptação a
falhas e novas demandas.
Com a disseminação dos serviços de redes em todo o globo através da Internet, mui-
tos datacenters passaram a concentrar grande capacidade de processamento e comunica-
ção, permitindo a entrega desses recursos como serviços, nos modelos conhecidos como:
Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) e Infrastructure-as-a-Service
(IaaS). Essas abordagens compõem o paradigma de computação em nuvem, que permite
o uso mais racional de recursos computacionais, se comparado ao provisionamento local.
Muitas aplicações de redes, como os serviços web, têm demandas que variam no
tempo. O pico de utilização dessas aplicações pode ser ordens de grandeza maior que
seu estado médio. Exemplos desse cenário são as demandas de eventos artísticos ou
esportivos transmitidos online, inscrições e resultados de atividades governamentais, entre
outros.
A computação em nuvem, que disponibiliza recursos como serviços (Everything as a
CAPÍTULO 1. INTRODUÇÃO 2
Service XaaS) (Banerjee et al. 2011), permitiu que usuários paguem de acordo com a de-
manda usada, aumentando e diminuindo elasticamente os recursos alocados no datacenter
para cada usuário. Um administrador de rede pode contratar recursos de acordo com a
carga eventual, economizando na aquisição e manutenção de equipamentos.
Sem o uso de computação elástica, o administrador seria obrigado a adquirir equipa-
mentos capazes de suportar o pico de uso, mas que ficariam subutilizados durante a maior
parte da vida útil destes. Essa vantagem da computação elástica, porém, vem acompa-
nhada de desafios como: automação de provisionamento, tolerância a falhas, concentra-
ção e alteração do modelo de consumo energético destes provedores e sua capacidade de
evolução e adaptação a novas demandas.
Redes tradicionais são compostas de equipamentos ativos e passivos onde as funções
de controle/gerenciamento (control-plane) estão atreladas fisicamente às funções de en-
caminhamento dos dados (data-plane), esse acoplamento dificulta a introdução de novas
tecnologias ou substituição da tecnologia existente. Um exemplo desta dificuldade na in-
trodução de uma nova tecnologia em redes tradicionais é a implantação da nova versão do
Internet Protocol (IP), o IPv6. Apesar deste estar aos poucos substituindo o IPv4, sua am-
pla adoção ainda esbarra na imutabilidade de um conjunto de equipamentos legados, que
terão de ser substituídos, normalmente devido a problemas de suporte com novas versões.
Outro problema trazido para as redes tradicionais pelo avanço da computação em nu-
vem e a crescente escala de serviços de redes em datacenters é a complexidade da manu-
tenção e gerenciamento destas redes. Um datacenter composto por centenas ou milhares
de servidores e equipamentos de rede, por vezes de fabricantes diferentes, implica na ne-
cessidade de gerenciamento centralizado. Mas isto só é possível utilizando ferramentas
específicas dos fabricantes dos equipamentos (o que leva a uma dependência forte do for-
necedor) ou utilizando várias ferramentas, frequentemente uma para cada fabricante, o
que torna mais complexa a gerência centralizada de recursos.
As Redes Definidas por Software (SDN) trazem uma mudança importante com a se-
CAPÍTULO 1. INTRODUÇÃO 3
paração entre o control-plane e o data-plane, como ilustrado na Figura 1.1.
Figura 1.1: Arquitetura de uma Rede Definida por Software
A separação de control-plane e data-plane permitiu a introdução do conceito de pro-
gramabilidade da rede, assim, novas funcionalidades e automação puderam ser mais fa-
cilmente inseridas nas SDN em comparação com as redes tradicionais.
Os novos desafios inseridos pela computação em nuvem e elástica vêm sendo estuda-
dos e várias propostas (Kreutz et al. 2015) utilizam a capacidade de automação e adapta-
ção das SDN na sua solução. A programabilidade do control-plane permite a automação
de provisionamento de recursos de rede (Son & Buyya 2018) e uma tolerância a falhas
mais inteligente e menos custosa do ponto de vista do custo de capital (CapEX) e do custo
operacional (OpEX) (Fonseca & Mota 2017).
A introdução da SDN, apesar de buscar resolver as questões de gerenciamento e adap-
tabilidade da rede, acabou por introduzir novos desafios que precisam ser tratados pela
academia e pela indústria. Um destes desafios está relacionado ao uso de energia nas re-
des definidas por software. Ao mover parte do processamento do hardware especializado
para software, o modelo energético sofreu também mudanças e as técnicas usadas para
CAPÍTULO 1. INTRODUÇÃO 4
redução de consumo em redes convencionais (desligar equipamentos, alterações de topo-
logia) continuam a ser aplicadas ao data-plane, mas passam a ter sua validade questionada
e novas técnicas precisam ser desenvolvidas.
1.2 Motivação
Os datacenters são o ponto central da arquitetura em nuvem, segundo Masanet et al.
(2020) em 2018 existiam mais de 300.000.000 de servidores instalados mundialmente,
variando entre servidores de pequeno, médio e grande porte. Além da base de servidores,
a rede que interliga estes equipamentos é responsável por até 15% do consumo de energia
em um datacenter (Heddeghem et al. 2014).
Outra preocupação comum nestes grandes provedores é o consumo energético das es-
truturas de rede e processamento (Popoola & Pranggono 2018). Estima-se que a partici-
pação dos dispositivos de Tecnologia da Informação e Comunicação no consumo mundial
de energia cresceu de 3,9% para 4,6% entre 2007 e 2012 (Heddeghem et al. 2014). Em
um reavaliação deste impacto, Masanet et al. (2020) considera que novos equipamentos de
comunicação têm se tornado mais eficientes energeticamente. No entanto, ainda estima-
se que o consumo de energia em datacenters no mundo aumentou de 95 TWh em 2010
para 130 TWh em 2018, devendo alcançar 155 TWh em 2023, apenas com os servidores,
equipamentos de armazenamento e comunicação.
Nas redes SDN, a separação de control-plane e data-plane criou uma nova camada de
software e hardware, o que implicou em mudanças no perfil de consumo dos datacenters.
Estratégias para aumentar a eficiência energética neste ambiente ainda são alvo de estudos
(Rawat & Reddy 2017, Lis et al. 2020). Muitos trabalhos aplicam técnicas de eficiência
energética, já consolidadas nas redes tradicionais, no novo contexto das SDN. Mas essas
técnicas se aplicam ao data-plane e ainda são poucos os trabalhos que se preocupam em
mapear e melhorar o consumo do control-plane das SDN.
CAPÍTULO 1. INTRODUÇÃO 5
A separação do control-plane e data-plane implica que os switches no data-plane têm
como tarefa apenas armazenar tabelas de regras de encaminhamento e realizar o encami-
nhamento próprio dos pacotes. Todo o processamento mais complexo desloca-se de um
hardware, que era construído especificamente para esta tarefa, para um hardware de pro-
pósito geral, comum em servidores de datacenters (Ferguson et al. 2021), e muitas vezes
virtualizado (Cisco 2021).
Nas redes tradicionais, os equipamentos ativos (switches e roteadores) são construídos
com software e hardware integrados, comumente pelo mesmo fabricante. Esses fabrican-
tes buscam projetar o hardware para o melhor desempenho no menor custo de produção
e com o menor consumo de energia por bit tratado.
Fabricantes oferecem linhas diferentes de equipamentos, desenhadas para camadas di-
ferentes da rede, seja no núcleo da rede ou na camada de acesso. Com as SDN, o hardware
do switch ainda é definido pelo fabricante, mas comumente o hardware do controlador é
constituído por vários servidores espalhados pelo datacenter. Ao utilizar servidores de
propósito geral, e principalmente ao oferecer uma interface northbound, os controladores
SDN permitem que aplicações executem dentro da rede.
As duas principais diferenças apontadas implicam em um consumo maior de energia,
ou seja: (i) utilizar hardware de propósito geral não otimizado implica em um consumo
maior de energia por bit tratado (se não forem aplicadas técnicas de melhoria); (ii) novas
aplicações executando nos controladores da rede irão consumir mais recursos (processa-
mento, memória, etc) o que implica em maior consumo de energia.
1.3 O problema
Processadores de propósito específico, também chamados ASIC (Application Speci-
fic Integrated Circuit) ou NPU (Network Processing Unit), para redes de computadores
vêm sendo utilizados em equipamentos de rede há muitos anos. Técnicas de paralelismo
CAPÍTULO 1. INTRODUÇÃO 6
também são aplicadas nesses equipamentos, em especial nos processadores da chamada
era many-core, em que se utilizam as Network-on-Chip (NoC) para interligar centenas de
núcleos de processamento em um único chip (Majumder et al. 2013).
Apesar de existirem controladores como appliances que podem utilizar ASIC ou
NPU, a adaptabilidade das SDN emerge da capacidade de provisionar serviços em hard-
ware comum (Son & Buyya 2018) ou mesmo em nuvem, de acordo com a demanda
(Cisco 2021).
Em um datacenter, Heddeghem et al. (2014) afirma que a maior parte do consumo de
energia, descontado o consumo da infraestrutura, é devido aos servidores. O paradigma
SDN move parte de seu processamento executado em switches e roteadores dedicados
para os controladores virtualizados em servidores, aumentando a parcela de consumo
destes equipamentos no datacenter. A busca então por redes mais energeticamente efi-
cientes impacta também nesses servidores, que agora abrigam o software que é parte da
rede.
A capacidade de entregar e processar pacotes em uma SDN está diretamente ligada
à capacidade de processamento do controlador. Como apresentado em Intel (2018) para
aplicações de roteamento na borda da rede, desenvolvedores devem priorizar o número de
núcleos e a frequência de operação destes núcleos.
Os processadores de propósito geral, utilizados em servidores, aplicam técnicas para
economia de energia que podem colocar os núcleos em diferentes estados de execução,
modificando a tensão e frequência de operação. Nos processadores Intel, esses estados
são conhecidos como estados de performance (P-states), e a interface ACPI (Advanced
Configuration and Power Interface) permite o controle dos estados a partir do sistema
operacional (Intel 2019b).
Enquanto muitos trabalhos buscam melhorar a eficiência das SDN no data-plane
(Priyadarsini et al. 2018, Tran Hoang Vu et al. 2012, Assefa & Ozkasap 2020, Younus
et al. 2019), o control-plane acaba por ser negligenciado no quesito de eficiência energé-
CAPÍTULO 1. INTRODUÇÃO 7
tica (Assefa & Özkasap 2019). É preciso tratar a eficiência energética das redes definidas
por software de maneira abrangente, incluindo o control-plane com suas peculiaridades,
pois neste paradigma essa parte da rede assemelha-se mais aos servidores do que aos
ASICs de transmissão de dados presentes nas redes tradicionais.
Um controlador SDN é o responsável minimamente pelas decisões de encaminha-
mento da rede, em camada 2 e camada 3. No entanto a sua programabilidade permite que
aplicações externas à rede comuniquem-se com o controlador mudando o comportamento
da rede de acordo com regras complexas. As regras são implementadas em software e são
executadas e avaliadas pelos controladores cuja função final será aplicá-las e traduzindo-
as para comandos de controle de fluxo enviados aos switches SDN.
1.4 Delimitação da pesquisa
As SDN podem ser aplicadas no amplo contexto em que redes tradicionais são utili-
zadas. Nesta tese, no entanto, o foco é sua utilização nos ambientes de datacenter. Hoje,
os serviços de datacenter são oferecidos ao usuário final como serviços no modelo XaaS
(Everything as a Service), justificando o fato do provisionamento de recursos, tolerância
a falha e automação das redes serem de vital importância.
As questões, hipóteses e técnicas apresentadas nos próximos capítulos aplicam-se ao
contexto de SDN aplicada a DCN (Datacenter Network). As premissas incluem o fato de
que controladores executam em equipamentos distintos dos switches e com processadores
de múltiplos núcleos. Esses processadores podem ter seus núcleos configurados para
operar em frequências diferentes e inclusive ser parcialmente desativados de acordo com
a carga da rede.
CAPÍTULO 1. INTRODUÇÃO 8
1.5 Objetivo geral
O objetivo geral deste trabalho é a avaliação e redução do consumo energético de
controladores de redes definidas por software em cenários de múltiplos núcleos de pro-
cessamento. Dividir tarefas e reduzir a frequência de operação com objetivo de reduzir o
consumo, mantendo um limiar de operação pré-determinado como os definidos em acor-
dos de prestação de serviço SLA (Service Level Agreement) de provedores de nuvem.
Neste cenário de um controlador centralizado multicore os experimentos desenvolvidos
demonstram ganhos de performance com a paralelização. A versão multicore chega a um
ganho na eficiência de até 31% em alguns cenários, apresentados em mais detalhes nos
Capítulos 4 e 5.
Além do cenário multi-core é apresentado o uso de técnica semelhante de paraleliza-
ção para um cenário com múltiplos controladores físicos que busca aumentar a tolerância
a falha com o mínimo de aumento do consumo no plano de controle.
1.6 Objetivos específicos
São objetivos específicos deste trabalho:
• Implementação de um controlador SDN paralelo multicore
• Comparação da eficiência energética de controladores SDN single-core e multi-core
• Implementação de um controlador SDN paralelo multicore e distribuído
• Comparação da eficiência energética de controladores SDN distribuídos com o uso
de paralelismo
CAPÍTULO 1. INTRODUÇÃO 9
1.7 Organização do trabalho
O restante do trabalho está organizado como segue: o Capítulo 2 apresenta os fun-
damentos teóricos das redes definidas por software (SDN), os aspectos mais relevantes
do problema da localização dos controladores (CPP), o consumo de energia em redes de
datacenter (DCN) e estratégias de medição e eficiência energética em datacenters. O Ca-
pítulo 3 apresenta um conjunto de trabalhos recentes no domínio de eficiência energética
em DCN e SDN. A implementação paralela de um controlador SDN é descrita no Capí-
tulo 4, assim como os resultados obtidos. No Capítulo 5 a versão distribuída é discutida e
são apresentadas as medições e resultados. Por fim, o Capítulo 6 apresenta uma discussão
destes resultados, bem como as contribuições e novas linhas de pesquisa e expansão da
tese.
Capítulo 2
Fundamentação Teórica
Este capítulo realiza um apanhado das bases teóricas utilizadas neste trabalho. Inici-
almente é apresentado o cenário atual das redes de datacenter (DCN) e o surgimento das
redes definidas por software, a motivação da separação entre control-plane e data-plane,
as vantagens do seu uso e cenários comuns.
Na Seção 2.3 é apresentado em detalhes o uso dos controladores SDN e o problema
da localização de controladores. A localização de controladores além de influenciar na
vazão da rede, i.e., na sua capacidade de transportar dados, também tem impacto sobre
outras características da rede, como: tolerância a falhas, custos de instalação e operação, e
a eficiência energética, sendo este último em especial, o foco deste trabalho. As métricas
de consumo de datacenters são apresentadas na Seção 2.4.
A solução apresentada nesta tese baseia-se no uso de múltiplos controladores exe-
cutando em paralelo, portanto, as técnicas de paralelismo e sua influência na eficiência
energética são detalhadas nas Seções 2.5 e 2.6.
2.1 Redes em Datacenter (DCN)
As redes de datacenter (DCN) formam a estrutura onde estão apoiados todos os servi-
ços de nuvem. Popoola & Pranggono (2018) apontam que os componentes de comunica-
ção são responsáveis por até 40% do consumo de um datacenter. A cada dia estes centros
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 11
crescem em número e capacidade instalada, para obter um crescimento sustentável é pre-
ciso garantir eficiência no consumo de energia de cada componente destas instalações.
A arquitetura mais comum para redes de datacenter (DCN) está organizada em 3 ca-
madas (3-Tier): core, aggregation, edge, conforme ilustrado na Figura 2.1. Os equipa-
mentos finais, como servidores e storages, estão conectados à camada edge composta por
switches conhecidos como Top-of-Rack (ToR), cuja principal característica é a alta densi-
dade de portas, que por sua vez estão conectados aos switches da camada aggregation, que
permitem uma divisão de tráfego implementando mecanismos de camada 3 (router-switch
ou switch layer 3), que se ligam a um número menor de switches com alta capacidade de
vazão e processamento, classificados como switches core.
Figura 2.1: Arquitetura de datacenter 3-Tier
Uma segunda arquitetura comum em DCN é chamada Fat-Tree (Al-Fares et al. 2008),
composta por switches mais simples (commodity-switch) o que a torna mais barata em ter-
mos de CapEx (Capital Expenditure). Além disto, esta arquitetura, segundo seus autores,
tem capacidade de entregar largura de banda maior, evitando o problema da limitação da
camada core da arquitetura 3-Tier.
Nesse modelo, uma k-fat-tree é montada como ilustrado na Figura 2.2. Na camada
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 12
mais baixa existem conjuntos de switches denominados k pods, cada um contém k/2
switches de k portas conectadas a k/2 hosts. As portas restantes desses switches são
conectadas aos switches da camada de agregação. Na camada superior (core), (k/2)2
switches tem uma porta conectada a cada pod, a i-ésima porta de um switch core está
conectada ao pod-i de modo que as portas na camada de agregação dos switches de cada
pod estão conectadas a um switch do core a cada k/2 portas. Nesse modelo, a arquitetura
suporta até k3/4 hosts.
Pod 1 Pod 2 Pod 3 Pod 4
Figura 2.2: Arquitetura de datacenter 4-Fat-Tree
Essas arquiteturas de datacenter impactam diretamente no consumo desses centros
como demonstrado por (Al-Fares et al. 2008). Enquanto nossa proposta busca melhorar a
eficiência energética a estratégia selecionada deve ser adaptável às diferentes arquiteturas
aqui apresentadas. A estratégia de redução de consumo por paralelismo pode ser aplicada
tanto a arquiteturas 3-Tier como Fat-Tree pois a localização dos switches não impactará
no desempenho da solução, como apresentado na Seção 4.6.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 13
2.2 Redes definidas por software
Redes de computadores são abstratamente entendidas como um conjunto de cinco
camadas: aplicação, transporte, rede, enlace e física no modelo conhecido como TCP/IP
(Ross & Kurose 2013). Comumente, a camada de rede e enlace no núcleo da rede são
compostas por switches 1 e roteadores. Enquanto switches tem o objetivo de realizar
encaminhamento de camada de enlace (baseado em endereços físicos), os roteadores são
responsáveis por encontrar os melhores caminhos entre as diversas redes (baseado em
endereços lógicos IPv4 e IPv6).
Com o aumento no número de elementos e complexidade das redes, os equipamentos
que a compõem também passaram a incluir funções de gerenciamento, como por exem-
plo: protocolos de monitoramento (SNMP, SFlow), segurança (SSH, criptografia, VPN),
Authentication-Authorization-Accountability (AAA) (Scott-Hayward et al. 2016), entre
outros. Essas funcionalidades são implementadas por um conjunto de softwares sendo
executados em um hardware dedicado. Cada fabricante implementa, portanto, seu con-
junto de funcionalidades de acordo com seu público alvo e estratégias de marketing e
custo. De fato, muito do custo de um equipamento de rede hoje está atrelado a estas
funções extras implementadas em software.
Essas funcionalidades permitiram muitos avanços na confiabilidade, segurança, resi-
liência, e aplicações das redes, mas por serem implementadas apenas pelos fabricantes,
comumente no hardware dedicado, não há espaço para customização destas funções. A
justificativa para este engessamento das plataformas de hardware dedicado é que assim
pode-se obter mais velocidade no encaminhamento dos pacotes e nas decisões de rotea-
mento.
Em 2008 McKeown et al. (2008) publicam um dos primeiros trabalhos na área de
redes definidas por software definindo uma primeira versão do protocolo OpenFlow. Ba-1O termo switch é usado neste trabalho para referir-se a equipamentos que fazem rotea-
mento/encaminhamento de camadas 2 ou 3.
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 14
seado em switches Ethernet que usam uma tabela interna e uma interface padrão para
adicionar e remover entradas nesta tabela de fluxos. O objetivo inicial dos autores era
permitir que pesquisadores executassem protocolos experimentais em equipamentos de
rede comuns. Na prática, este trabalho separou as decisões de encaminhamento (control-
plane) do equipamento usado no encaminhamento em si (data-plane).
Na definição do protocolo OpenFlow os autores descrevem-no como uma solução
para o problema da falta de flexibilidade das arquiteturas fechadas dos equipamentos de
rede. O uso do OpenFlow permitiria maior facilidade nos experimentos, especialmente
de pesquisadores da área. Não tardou para que a indústria também percebesse a utilidade
desta flexibilidade para o mercado e para o valor agregado de seus produtos (Kreutz et al.
2015).
Esta separação entre control-plane e data-plane, como visto na Figura 2.3, permitiu
a programabilidade da rede. As decisões podem ser tomadas externamente usando um
outro equipamento, denominado controlador, que utiliza processadores de propósito geral.
Esses controladores passam então a poder executar mais do que a simples avaliação de
encaminhamento; um desenvolvedor pode usar uma Application Program Interface (API)
para acessar os dados de rede e tomar decisões de encaminhamento baseado em dados em
tempo real.
Uma vez que ocorra a separação dos planos de controle e de dados, é possível usar
equipamentos simples no plano de dados, responsáveis apenas por enviar e receber men-
sagens OpenFlow. Toda a inteligência pode ser centralizada no controlador. Além do
controle centralizado e independente do fabricante, a capacidade de extensão de funcio-
nalidades do controlador está limitada apenas ao hardware usado.
As redes definidas por software tem um conjunto padronizado de interfaces que per-
mite a programabilidade da rede, conforme ilustrado na Figura-2.4. A interface South-
bound, que liga o plano de dados ao plano de controle, é dominada pelo protocolo Open-
Flow, apesar de haver outros protocolos concorrentes (ForCES, POF, NCP, RCP, entre
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 15
Figura 2.3: Arquitetura do protocolo OpenFlow
outros) (Kreutz et al. 2015). Já a interface denominada Northbound, que liga o plano de
controle às aplicações de rede, é oferecida pelos controladores para que outras aplica-
ções tenham acesso de leitura e alteração do estado da rede, sendo normalmente uma API
aberta, definida pelo controlador. Outras estratégias existem para a interface Northbound
como: FML, Frenetic, NetKAT, Procera, NetCore, entre outras (Latif et al. 2020).
Uma outra interface importante na arquitetura SDN é chamada East/Westbound essa
interface trata da comunicação entre controladores, especialmente controladores distribuí-
dos e replicados. Essa interface transporta informações sobre o estado da rede, sincronia
de controladores, estados dos controladores (online, offline), distribuição de carga etc.
Nesse domínio, as APIs são muito diversas e não há interoperabilidade entre controla-
dores diferentes, apesar de haver esforços no sentido de padronização destas mensagens
como o protocolo SDNi (Yin et al. 2012).
Apesar de vantajosa, a arquitetura da SDN trouxe também novos desafios para os
pesquisadores e administradores de rede. Ameaças à segurança como: (i) ataques à co-
municação com o control-plane; (ii) ataques a novas vulnerabilidades introduzidas pelos
controladores; (iii) ausência de um mecanismo claro de confiança entre as aplicações
de gerenciamento e os controladores (Yan et al. 2016); (iv) resiliência do control-plane
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 16
Figura 2.4: Interfaces SDN
(Oktian et al. 2017); (v) uso de switches mais inteligentes (stateful) para a divisão de ta-
refas entre controlador/switch (Bi et al. 2016); (vi) eficiência energética dos elementos de
rede, entre outras (Rawat & Reddy 2017).
Diferente das redes tradicionais, o consumo energético de uma rede SDN está mais
distribuído, enquanto que em uma rede comum o consumo energético dos equipamentos
de rede se concentra nos roteadores e switches. Na SDN, este consumo está disperso
em vários equipamentos diferentes, já que o processamento necessário para realizar o
encaminhamento está fisicamente separado no(s) controlador(es).
O trabalho de Priyadarsini et al. (2018), discutido na Seção 3.4, apresenta-se um mo-
delo detalhado do consumo de redes SDN. Nele os autores separam o consumo da rede
entre: consumo dos switches; consumo dos controladores; consumo dos links usados; e
um fator relacionado à latência da rede.
Uma das decisões iniciais na implantação de SDN é o número e localização dos con-
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 17
troladores. Apesar da centralização de controle ser uma vantagem do ponto de vista do
gerenciamento da rede, um único controlador para toda a rede representará um ponto-
único-de-falha. Então, um administrador de redes implantando uma SDN deve considerar
o fator resiliência e tolerância a falha da rede, aumentando o número de controladores,
sejam eles distribuídos ou replicados.
2.3 Controladores SDN
Em uma SDN, o papel principal do controlador é o recebimento de requisições dos
switches e a resposta de como estes devem tratar os pacotes que chegam às suas portas.
A aplicação mais simples do controlador é a de um switch Ethernet camada 2, que segue
a descrição apresentada no Algoritmo 1. O controlador pode efetuar uma série de outras
funções com os dados recebidos, como descrito na Seção 2.2.
Algoritmo 1: Switch simples/* Essa tabela contém endereço destino e porta do switch */
1 cria tabela de encaminhamento vazia;2 enquanto ativo faça3 recebe pacote;4 adiciona origem à tabela de encaminhamento;5 se destino está na tabela então6 encaminha pacote pela porta de destino;7 senão8 encaminha pacote a todas as portas exceto a de origem (FLOOD)9 fim
10 fim
A implementação do Algoritmo 1 em redes SDN está separada entre o controlador e
o switch. Nesse cenário, a implementação fica detalhada no Algoritmo 2.
O controlador irá tomar a decisão de encaminhamento segundo o Algoritmo 3. Em
primeiro lugar é necessário manter um registro de quais switches estão associados ao
controlador Isso é feito armazenando uma identificação do switch e fazendo uma confi-
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 18
Algoritmo 2: Switch simples SDN/* Essa tabela contém vários campos e porta de saída do switch
*/1 cria tabela de fluxos vazia;2 enquanto ativo faça3 recebe pacote;4 se há match do pacote com uma linha da tabela de fluxos então5 encaminha pacote pela porta de destino;6 senão7 encaminha mensagem (PACKET_IN) ao controlador;8 fim9 fim
guração inicial enviando a mensagem FLOW_MOD que cria a tabela inicial no switch e o
configura para enviar os pacotes para o controlador.
Caso o controlador receba um pacote, que necessita de encaminhamento, deve avaliar
se o destino já é conhecido, sendo conhecido deve configurar o switch para que os novos
pacotes sejam sempre encaminhados pelo destino conhecido. Caso o destino não seja
conhecido é necessário fazer flood na camada 2 da rede o que é obtido devolvendo o
pacote para o switch de origem com a mensagem PACKET_OUT e destino FLOOD.
Algoritmo 3: Controlador SDN1 enquanto ativo faça2 se novo switch então3 envia msg FLOW_MOD ao switch criando uma entrada padrão na tabela
de fluxos;4 fim5 recebe PACKET_IN do switch;6 se endereço destino é conhecido então7 envia msg FLOW_MOD ao switch criando uma entrada na tabela de
fluxos;8 envia msg PACKET_OUT ao switch para que este encaminhe o pacote;9 senão
10 envia msg PACKET_OUT ao switch para que este encaminhe o pacotepor todas as portas (FLOOD);
11 fim12 fim
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 19
É importante entender que o controlador não executa apenas a função descrita no
Algoritmo 3 de learning switch, mas também pode executar uma série de atividades que
oferecem serviços às aplicações de redes usando a interface Northbound definida pelo
desenvolvedor do controlador.
Percebe-se que sempre que o switch encontra uma situação para a qual não está pre-
viamente configurado (não há uma entrada na tabela de fluxos), a decisão de encaminha-
mento é adiada e uma mensagem do tipo PACKET_IN é enviada ao controlador, que deve
decidir o que fazer com o pacote e informar ao switch, usando uma mensagem do tipo
PACKET_OUT.
Outro aspecto importante é que o switch não necessita de grande capacidade de pro-
cessamento, já que sua função mais custosa computacionalmente é a busca na tabela de
fluxos. Esta tabela pode ser implementada em hardware para aumentar a eficiência da
busca nos switches.
Uma variação deste modelo, proposta por Dargahi et al. (2017) e Bi et al. (2016), é
o uso de um data-plane stateful. A ideia neste caso é desafogar algumas decisões do
controlador, e com isso permitir a implementação de aplicações que dependem de tempos
de resposta próximos dos tempos de chegada dos pacotes. Essa nova abordagem vai na
contramão da separação do control-plane e data-plane, já que leva de volta ao data-plane
algumas funções de controle. A justificativa para este retorno parcial às redes tradicionais
é que segundo os autores, apenas neste modelo é possível implementar aplicações de
tempo-real estrito, desde que estas não dependam do conhecimento do estado geral da
rede (Dargahi et al. 2017).s
As implementações de switches stateful se preocupam, essencialmente, em evitar o
problema da latência da comunicação com o controlador. Uma outra área de pesquisa
busca diminuir esta latência, sem alterar a arquitetura da SDN, através do estudo da me-
lhor localização dos controladores e da correta distribuição de carga e switches alocados
a cada controlador. Esta área concentra-se na resolução do problema conhecido como
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 20
Problema da localização do Controlador Controller Placement Problem (CPP). Em geral
Wang et al. (2017) busca posicionar os controladores em uma SDN e associá-los aos swit-
ches de modo a obter um ou mais objetivos que incluem: diminuir a latência, aumentar a
confiabilidade, aumentar a eficiência energética entre outros.
2.3.1 Problema da localização do controlador
O CPP pode ser dividido em duas categorias: online ou offline, a diferença destes está
no fato de levar em consideração o tráfego da rede em tempo real na alocação dos switches
para os controladores. Além da divisão entre online e offline, os objetivos do CPP podem
ser variados.
As entradas para um CPP são as possíveis localizações dos controladores, localização
dos switches e, no caso do CPP online, o fluxo da rede em tempo real. A saída é composta
pela localização dos controladores e a alocação dos switches a controladores.
A abordagem adotada por (Chen et al. 2017) foi modelar o CPP como um problema de
empacotamento (Bin-packing problem) (Cormen et al. 2001), no qual temos como entrada
um conjunto de objetos de diferentes volumes Oi que precisam ser armazenados em caixas
de volume fixo V , minimizando o número de caixas. Nesta modelagem, os switches com
diferentes demandas de fluxo de rede são representados pelos objetos de volume variável,
enquanto os controladores com sua capacidade fixa de processamento são representados
pelas caixas de volume fixo. Com essa modelagem, os autores afirmam por redução, que
o CPP é também um problema NP-Hard. Soluções para o CPP que se relacionam com o
consumo de energia estão detalhadas na Seção 3.3.
2.4 Medição de consumo e eficiência em DCN
Heddeghem et al. (2014) e Shuja et al. (2016) já apresentam estimativas de consumo
dos datacenters atuais na ordem de centenas de TWh, com taxa de crescimento da or-
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 21
dem de 10% ao ano. Os provedores de nuvem utilizam os datacenters para oferecer seus
serviços, e seu lucro está diretamente relacionado ao custo operacional (OpEx), que é
largamente composto pelo custo da energia consumida nestes centros.
Portanto os provedores buscam ao máximo otimizar o uso de energia nestes centros.
No entanto, não é possível controlar o que não é medido. Um conjunto de políticas
para medição de consumo em datacenters é usado para avaliar não apenas o consumo em
Watts-hora, mas principalmente a eficiência deste consumo. A principal métrica usada na
avaliação de eficiência em datacenters é o Power Usage Effectiveness (PUE) que busca
comparar o consumo de energia de toda a instalação do datacenter em relação ao valor
consumido exclusivamente por equipamentos de Tecnologia da Informação e Comunica-
ção (TIC) .
PUE =Energia total da fonte do datacenter
Energia total da fonte de equipamentos de TIC(2.1)
Observando a Equação (2.1), entende-se que um valor PUE igual a 1 implica que todo
o consumo do datacenter é direcionado aos equipamentos de TIC. Para um PUE igual,
por exemplo, a 2, para cada 2 watts gastos pelo datacenter, 1 é usado pelos equipamentos
de TIC.
A partir do PUE não é possível estimar valores de eficiência de partes do datacen-
ter, já que o consumo de todos os equipamentos de TI está representado por uma única
variável. Apesar do PUE ser usada amplamente, inclusive por recomendações internacio-
nais (Energy Star 2011), outras métricas mais detalhadas são propostas por vários autores,
entre eles Fiandrino et al. (2017), que apresenta um conjunto de métricas que focam na efi-
ciência de cada componente do datacenter. Em especial a métrica Network Power Usage
Effectiveness (NPUE) é detalhada na Seção 3.1.
As unidades de medida de eficiência energética em datacenters são importantes na
avaliação dos resultados apresentados nos Capítulos 4 e 5. A compreensão do impacto
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 22
dos elementos de rede no PUE e sua sub-divisão NPUE motiva este trabalho. O CNEE
foi adaptado na seção 5.5 para apresentar uma avaliação equivalente mas focada nos con-
troladores SDN.
2.5 Processamento paralelo: Dispatcher/Workers
A conhecida lei de Amdahl (Amdahl 1967), que trata do ganho de desempenho em
processamento paralelo, divide problemas em duas frações: Uma parte infinitamente pa-
ralelizável P e uma fração S = 1�P que é estritamente serial. Assim, o ganho de desem-
penho R obtido pela adição de capacidade de paralelismo é limitado pela fração serial S,
como definido por:
R = RS ⇤S+PS+ P
M(2.2)
em que RS é o desempenho de um computador que executa o problema de maneira total-
mente serial, e M é o número de unidades de execução paralelas (em nosso caso, núcleos
de processamento).
A lei de Amdahl assume um tamanho fixo do problema a ser tratado, o que não é o
caso para controladores SDN já que a carga de trabalho de um controlador SDN está li-
gada ao tráfego e às condições de funcionamento das aplicações na interface northbound
e portanto, mudam constantemente. Para este tipo de problema onde o tamanho da parte
paralelizável cresce à medida que novos recursos estão disponíveis é possível aplicar a
lei de Gustafson (1988). Esta lei afirma que problemas maiores se beneficiam, para além
dos limites da lei de Amdahl, se a fração paralela também cresce de acordo com a dispo-
nibilidade de recursos. Isto implica em uma relação de tempo de execução serial sobre
o tempo de execução em paralelo, denominada speedup, mais otimista, pois com a par-
cela paralela crescente o impacto da parcela serial é cada vez menos relevante. Esta nova
lei vem sendo aplicada e provou-se verdadeira em vários problemas reais, ratificada pela
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 23
prevalência dos processadores multi-core nos computadores atuais.
A proposta apresentada neste trabalho busca melhorar a eficiência energética do con-
trolador. Neste escopo a Lei de Gustafson é aplicada buscando a divisão da parte paraleli-
zável entre os vários núcleos de processamento disponíveis. Com o aumento dos recursos
disponíveis (número de núcleos) cada processador terá uma parcela menor a ser executada
e poderá operar em uma frequência menor, diminuindo o consumo geral do controlador.
Na implementação dos experimentos apresentados nos Capítulos 4 e 5, o problema
do controlador SDN é implementado de forma paralela utilizando o modelo Dispat-
cher/Worker (Tanenbaum & Bos 2014). Neste modelo, ilustrado na Figura 2.5, a parte
serial do problema é chamada Dispatcher, sua função é aguardar requisições e distribuí-
las entre os Workers, que executam suas tarefas em paralelo. Uma instância do Dispatcher
aguarda que novos pacotes cheguem à interface de rede. Quando isto ocorre, o Dispatcher
não realiza processamento sobre os dados recebidos, apenas seleciona um dos vários Wor-
kers e encaminha os pacotes para que este execute o processamento necessário, voltando
imediatamente ao estado de aguardar novo pacote.
Figura 2.5: Modelo Dispatcher Worker
Neste modelo, quanto mais pacotes chegarem ao controlador, mais Workers serão ne-
cessários e poderão se beneficiar de mais núcleos de processamento, seguindo um com-
portamento mais próximo do descrito por (Gustafson 1988). A medida que novos recursos
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 24
são adicionados ao sistema menor é a carga de trabalho dos Workers, se mantido o fluxo
constante de pacotes de rede, com a redução da carga em cada Worker é possível reduzir
sua frequência de operação obtendo um ganho de eficiência energética como apresentado
na seção seguinte.
2.6 Redução de consumo por redução de frequência de
processamento
A principal função de um controlador SDN é a tomada de decisões de roteamento
e/ou encaminhamento. Essa tarefa, no mais simples dos cenários (switch padrão layer 2),
depende exclusivamente da consulta a um conjunto de regras implementadas em software.
A capacidade do controlador em atender à demanda está relacionada a sua capacidade de
executar rapidamente o software de decisão de encaminhamento.
Switches SDN podem ser baseados em processadores de propósito específico (Network
Processing Unit) (Kreutz et al. 2015) ou em processadores de propósito-geral. Diferente
dos switches, que compõe o data-plane, para utilizar a principal vantagem de um contro-
lador SDN, sua programabilidade, o software do controlador será comumente executado
em um processador de propósito geral.
Barros (2016) apresenta uma abordagem para a redução do consumo de energia por
meio do processamento de tarefas em arquiteturas multi-core. Especificamente, o autor
considera uma mesma tarefa executada em um processador singlecore comparada com
uma implementação paralela, executando no mesmo intervalo de tempo em um processa-
dor multicore. Neste modelo, o autor não considera o fator A, que representa o nível de
atividade do processador, mas afirma que é possível desconsiderar este fator para tarefas
que sejam altamente demandantes de processamento (cpu-bound), por aproximar-se de 1
para um determinado intervalo de tempo pequeno em que o consumo está sendo medido.
Inicialmente, o autor define um modelo de potência associado ao processador, que
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 25
considera apenas a sua parcela de potência dinâmica, denominado M1, como sendo:
PM1tot ⇡ k0 ·g(F)2 ·A ·F, (2.3)
em que PM1tot é a potência dissipada pelo processador; k0 é uma constante de proporci-
onalidade; F é a frequência de operação e g(F) é uma função que relaciona tensão de
alimentação e frequência, A é o fator de atividade do processador.
A Equação (2.4) apresenta uma relação entre a tensão V , a tensão de threshold Vth e a
frequência F , onde k1 é uma constante de proporcionalidade:
F = k1 ·(V �Vth)h
V. (2.4)
No modelo da equação (2.3) denominado M1, considerando a tensão threshold Vth⇡ 0
e h = 2, a função g(F) é dada por (1/k1) ·F e portanto, a Equação (2.3) pode ser reescrita
como:
PM1tot ⇡ a ·A ·F3, (2.5)
em que a é uma constante equivalente a (k0/k21).
A partir deste modelo, o autor encontra uma relação entre o consumo de energia de
processadores single-core e multi-core homogêneo, no cenário em que estes executam no
mesmo intervalo de tempo uma determinada tarefa.
Essa relação é dada por: Er =Pho
Psc, em que Pho é a potência no processador multi-core
homogêneo e Psc é a potência no processador single-core. Considerando a Equação (2.3),
e que por simetria Pho = p ·P1(Fho), em que p é o número de núcleos do processador
multi-core e P1 é a potência de um dos núcleos, pode-se escrever:
Er = p ·F3
hoF3
sc. (2.6)
O Speedup da aplicação denominado Sp, definido como a relação entre o tempo de
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 26
execução serial e o tempo de execução paralela, para uma mesma frequência, ou seja:
Sp =Ts
Tp. (2.7)
Pode-se observar que a relação entre o consumo de energia do processador multi-
core homogêneo e o consumo de energia do processador single-core, com o modelo de
potência M1, é dada por:
Er =p
S3p, (2.8)
considerando o caso específico em que ambos os processadores executam a tarefa no
mesmo intervalo de tempo.
A Equação (2.8) demonstra que para um speedup linear, há sempre economia de ener-
gia ao utilizar-se um processador multi-core, desde que o tempo total da execução paralela
seja igual ao tempo de execução single-core. É importante ressaltar que a variável de Spe-
edup já representa em sua formulação elementos da qualidade da paralelização, overheads
como o memory-wall e questões relacionadas a escalonamento do sistema operacional,
entre outros.
Em última instância, o autor aponta um valor limite para o Speedup a partir do qual
há economia de energia em processadores multi-core homogêneos, dado por:
SLIMp = p1/3. (2.9)
Um segundo modelo de potência para processadores, denotado M2, também é apre-
sentado em (Barros 2016), o qual passa a considerar em adição à potência dinâmica, a
parcela de potência devida a corrente de fuga no processador Pleak, assim: PM2 = PM1 +
Pleak. Esse modelo mais completo considera especialmente a fuga de corrente devido ao
efeito de Sub-threshold nos transistores do processador.
Sabendo-se possível paralelizar a tarefa de decisão de encaminhamento em controla-
CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 27
dores SDN, este trabalho busca portanto determinar a melhor relação entre os fatores de
paralelização/tolerância-a-falhas e consumo de energia em controladores de redes defini-
das por software em um datacenter.
Ao observar a Equação (2.8) observa-se que a relação entre o número de processadores
e o Speedup de uma aplicação permite a redução do consumo. Assim este trabalho busca
aumentar o Speedup da aplicação executada em controladores SDN, através de uma nova
implmentação paralela.
2.7 Resumo
As topologias mais comuns e usos das redes em datacenters (DCN) foram apresen-
tadas neste capítulo. A implementação, características, vantagens e desafios das SDN
também foram apresentadas. Foi discutida a separação do plano de controle e de dados
e como esta separação resolve problemas e cria novos desafios de segurança, gerência e
impacta na eficiência energética das redes.
O problema da localização e número ideal de controladores é apresentado com uma
descrição breve de soluções atuais. As maneiras de medir eficiência energética nas DCN
são a base para a justificativa do uso de processamento paralelo para redução de consumo,
conforme descrito na Seção 2.6.
No Capítulo 3 serão apresentadas as soluções da literatura para os problemas aqui
apresentados e a localização desta tese no cenário científico mais recente.
Capítulo 3
Estado da arte
Neste capítulo são apresentados alguns trabalhos presentes na literatura relacionados
ao domínio abordado nesta pesquisa, com o objetivo posicionar o problema e a solução
encontrada nesta tese no contexto científico.
Inicialmente, a maneira como a eficiência energética de DCN é medida é discu-
tida na Seção 3.1. Muitos dos trabalhos relacionados à eficiência energética em SDN
concentram-se no data-plane, no entanto alguns trabalhos vêm margeando as questões de
consumo e otimização do control-plane. Apesar do foco no plano de dados, as técnicas
utilizadas em alguns trabalhos apresentados na Seção 3.2 podem ser utilizadas em para-
lelo à técnica desenvolvida nesta tese. Um conjunto de trabalhos focados no plano de
controle também é apresentado na Seção 3.3. A Seção 3.4 discute um modelo energético
mais completo que inclui o consumo dos switches e dos controladores. Uma breve apre-
sentação de redes SDN em datacenters comerciais de larga escala é apresentada na Seção
3.5.
3.1 Métricas de consumo em DCN
Tradicionalmente, a principal métrica de eficiência energética em um DC é a PUE,
apresentada na Equação 2.1, e definida como a relação entre a energia consumida pelas
instalações do datacenter como um todo em relação à energia efetivamente consumida
CAPÍTULO 3. ESTADO DA ARTE 29
pelos equipamentos de TIC.
A principal contribuição de (Fiandrino et al. 2017) é um conjunto mais granular de
métricas sobre eficiência energética em datacenters. Os autores afirmam que as métricas
existentes são muito genéricas e não permitem diferenciar uma melhoria na eficiência
da rede de uma melhoria na eficiência dos servidores de um datacenter, já que todos os
equipamentos são tratados genericamente como ETIC (Equipamentos de Tecnologia de
Informação e Comunicação).
Inicialmente, os autores discutem as limitações das duas métricas mais comuns em
eficiência energética para datacenters: PUE (Power Usage Effectiveness) e DCiE (Data
Center Infrastructure Efficiency). PUE é definida como a relação entre a potência con-
sumida pelas instalações do datacenter e a potência consumida pelos equipamentos de
TI, enquanto DCiE é o recíproco do PUE. Outra métrica é o EUE (Energy Usage Ef-
fectiviness) que é nada mais que o PUE substituindo potência por energia. Os autores
também tratam brevemente de outras métricas, como por exemplo, Energy Reuse Effecti-
viness, Energy Reuse Factor, UPS Load Factor, Data Center Energy Productivity, entre
outras. Métricas de resfriamento e para equipamentos condicionadores de ar também são
definidas pelos autores.
Os autores propõem no total 17 novas métricas relacionadas a eficiência em redes e
comunicação em datacenters, das quais duas estão relacionadas a eficiência energética
de redes: CNEE (Communication Network Energy Efficiency), NPUE (Network Power
Usage Effectiveness).
As definições dessas métricas são:
• CNEE: Energia necessária para entregar 1 bit de dados;
• NPUE: Relação entre o total da energia consumida por TI e energia consumida por
equipamentos de rede;
CAPÍTULO 3. ESTADO DA ARTE 30
As métricas estão definidas formalmente como segue:
CNEE =Potência consumida por equipamentos de rede
Capacidade de Throughput efetiva. (3.1)
Assim a CNEE é medida em watts/bit/segundo que é equivalente a joules/bit, ou a
quantidade de energia necessária para transmitir 1 bit na rede.
NPUE =Potência consumida pelos equipamentos de TICPotência consumida pelos equipamentos de rede
. (3.2)
NPUE é a razão da potência consumida por todos os equipamento de TI e a potên-
cia consumida pelos equipamentos de rede. Na prática esta métrica é uma sub-divisão
mais granular da métrica PUE definida na Seção 2.4 enquanto a PUE trata da eficiência
energética de todo o datacenter o NPUE é focado nos equipamentos de rede.
O valor do NPUE vai de 1 a infinito, um NPUE de valor 1 significaria um cenário
em que toda potência está sendo usada pelos equipamentos de rede, nenhuma potência
consumida por servidores e storage. Um NPUE muito alto pode significar que o consumo
dos equipamentos de rede neste datacenter é desprezível se comparado com o consumo
dos servidores e storage. Um NPUE igual a 6, por exemplo, indica que a cada 6 watts de
potência dissipada pelos equipamentos de TI, 1 watt é dissipado pelos equipamentos de
rede.
3.2 Eficiência energética no plano de dados
Os estudos em eficiência energética de redes de computadores apresentam muitos
exemplos de algoritmos aplicados a redes sem fio definidas por software e mais recente-
mente, aplicados a SDN em DCN, provedores de cloud, 5G e edge-computing.
CAPÍTULO 3. ESTADO DA ARTE 31
3.2.1 Eficiência energética baseada em roteamento
Há mais de duas décadas, Heinzelman et al. (2000) apresentaram o algoritmo LEACH
(Low-Energy Adaptive Clustering Hierarchy), sendo um dos primeiros trabalhos a utilizar
técnicas de roteamento buscando a eficiência energética. O LEACH realiza um balance-
amento do uso de energia em nós de uma rede de sensores sem fio dividindo a rede em
clusters e alternando os heads de cada cluster, evitando que um único caminho consuma
toda a energia dos nós. Isto distribui a carga dos vários nós em vários caminhos que po-
dem ser usados pelos pacotes para alcançar a estação base. Hoje, este algoritmo ainda é
usado como benchmark por vários trabalhos que utilizam roteamento para economia de
energia. Variações desta estratégia são usadas para reduzir o consumo em redes SDN, já
que esta permite que as regras de roteamento sejam alteradas dinamicamente, usando a
capacidade de processamento do controlador e o contato com as aplicações na interface
northbound. A abordagem desta tese busca assim como Heinzelman et al. (2000) balan-
cear a carga entre os controladores de rede, porém, isto é feito em nível de processador
aproveitando os vários núcleos disponíveis nos processadores atuais.
O poder de processamento dos controladores e a programabilidade das SDN são ex-
plorados por (Aujla et al. 2018) para mudar as regras de roteamento de acordo com a
localização das aplicações dentro de um mesmo datacenter. Para isso, os autores utili-
zam informações das aplicações como deadline e demanda por recursos, que precisam
ser conhecidos antes da execução. A partir destas informações, um modelo é construído
para avaliar onde a tarefa deve ser alocada na DCN ou em um dispositivo de borda (edge-
computing). Aplicando o modelo, a solução é dividida em dois passos: (i) O modelo
migrará as tarefas das máquinas virtuais (VM) considerando os prazos e necessidade de
recursos; (ii) O controlador SDN decidirá o conjunto de rotas com a melhor eficiência
energética. A solução de agendamento energeticamente eficiente dos fluxos depende da
capacidade de processamento do controlador, o que implica em um aumento de consumo
deste. Porém, segundo os autores, a economia de energia no plano de dados compensa
CAPÍTULO 3. ESTADO DA ARTE 32
o consumo do controlador. Esta solução necessita de conhecimento completo de toda a
topologia da rede intra-DCN e dos dispositivos de borda (edge). Para diminuir esta limi-
tação, os autores utilizam vários controladores virtuais que tem conhecimento parcial da
rede e um controlador principal com conhecimento de toda a rede. Outra limitação desta
abordagem é a necessidade de conhecimento prévio das demandas e prazos das aplicações
em execução.
A solução apresentada no Capítulo 4 relaciona-se com esta por buscar redução de
consumo alterando o funcionamento do controlador. Considerando as limitações da rede
de datacenter como: garantias de deadline para entregas de pacotes e tolerância a falha.
Como apresentado anteriormente, a maioria dos trabalhos utiliza o plano de dados
como métrica para a melhoria do consumo de energia em SDN. Seguindo essa tendência,
Xu et al. (2017) observa o uso dos links do plano de dados como a métrica para seu
algoritmo de roteamento. Os autores observam que o consumo de energia em um switch
SDN não é proporcional ao tráfego, mas está relacionado ao número de portas ativas. A
solução busca então concentrar tráfego no menor número de links ativos, mantendo um
tempo máximo de entrega dos pacotes.
Nas redes SDN 5G, que incluem entre outras as redes com alto número de dispositivos
IoT, Fernández-Fernández et al. (2017) definem o problema de roteamento energetica-
mente eficiente como um problema NP-Hard, assim, o tempo de cálculo da solução ótima
cresce de maneira exponencial com o tamanho da rede. Para tratar este problema, os auto-
res propõem duas heurísticas, uma online e uma offline. A heurística offline, denominada
Static Network Configuration Algorithm (SNetCA) apresenta um modelo da rede com
controladores e switches como um grafo conexo com um número mínimo de links com
alguma redundância. A heurística online, denominada Dynamic Energy Saving Routing
Algorithm (DESRA), busca reduzir o número de links usados no encaminhamento dos
pacotes a medida que novos fluxos chegam à rede, assim quando um fluxo desconhecido
chega a um switch, o controlador buscará o caminho com o mínimo de links (reduzindo
CAPÍTULO 3. ESTADO DA ARTE 33
consumo) e definirá este caminho no switch para os próximos fluxos equivalentes.
Redes de sensores sem fio definidas por software (SDWSN) comumente apresentam
restrições de disponibilidade de energia devido à sua própria natureza e aplicações, em
especial, quando compostas de equipamentos que utilizam baterias. O trabalho de You-
nus et al. (2019) propõe um algoritmo para as SDWSN. O objetivo é aumentar o tempo
de vida da rede melhorando o atraso médio dos pacotes. O algoritmo Energy-Aware Soft-
ware Defined Network (EASDN) é dividido em três fases: (i) descoberta dos vizinhos,
através de um pacote HELLO em broadcast; (ii) cada nó envia aos vizinhos os seus da-
dos de status (bateria, localização, outros vizinhos) colhidos na fase 1; (iii) o controlador
define as tabelas de rotas mínimas de cada nó na rede. Durante a fase operacional, se o
controlador detecta que algum nó está com energia abaixo de um limiar, este gera uma
nova tabela que é repassada aos nós da rede. Essa abordagem concentra no controlador
único a gerência da rede e implica que este precisa de conhecimento prévio de toda a rede
para o funcionamento adequado.
Uma das abordagens mais recentes em eficiência energética para SDN é apresentada
em (Assefa & Ozkasap 2020). Neste trabalho, os autores apresentam uma nova métrica
para eficiência energética, denominada Ratio for Energy Saving in SDN (RESDN), que
considera o uso dos links no plano de dados em um intervalo de tempo definido. Assim,
a métrica permite identificar links subutilizados, com o objetivo de migrar os fluxos que
passariam por estes links para outros links, desligando os primeiros. Usando esta métrica,
os autores propõem o método Maximizing Ratio for Energy Saving in SDN (MaxRESDN),
buscando diminuir o número de saltos para desativar links e reduzir o consumo. O algo-
ritmo MAXRESDN é executado em um controlador único que precisa ter conhecimento
completo da topologia da rede.
No contexto desta tese os trabalhos de eficiência energética do plano de dados apontam
as limitações de soluções baseadas unicamente no plano de dados. No entanto, as técnicas
apresentadas nesta seção podem ser associadas às desenvolvidas em nossos experimentos,
CAPÍTULO 3. ESTADO DA ARTE 34
como indicado na no Capítulo 6.
3.2.2 Eficiência energética baseada em alocação de recursos
Uma estratégia diferente é usada por Son et al. (2017). Os autores usam a capacidade
de migração de máquinas virtuais e das Virtual Network Functions (VNF) para conso-
lidar tráfego em alguns switches, buscando desativar links pouco usados, diminuindo o
consumo e buscando minimizar possíveis violações do SLA. Diferente da abordagem de
Aujla et al. (2018), esta solução pode funcionar de forma online, inferindo a carga futura
a partir da informação disponível sobre a carga atual da rede. A estratégia é baseada na
interface northbound e considera que o controlador tem acesso a todas as informações de
recursos usados pelas aplicações em execução na DCN, e que estas podem ser movidas
para diferentes servidores físicos usando uma estratégia de sobre-alocação (overbooking).
Esta solução implica que o controlador esteja ativo e avaliando a demanda da rede cons-
tantemente, os autores não consideram esta demanda aumentada nos cálculos de consumo.
Um estratégia semelhante é usada por Zhao et al. (2018) para uma avaliação da aloca-
ção de máquinas virtuais em um ambiente de provedor de cloud computing. Este trabalho
relaciona-se com o nosso no sentido que um controlador de SDN pode ser implementado
totalmente em software em uma máquina virtual (VM - Virtual Machine). Portanto, as
técnicas apresentadas podem ser aplicadas a um controlador. A decisão de migração con-
sidera o aspecto do desempenho da máquina virtual. Os autores afirmam que este aspecto
é um dos principais na visão de qualidade de experiência (QoE) do usuário de serviços de
nuvem. Ao migrar VMs entre máquinas físicas os autores buscam diminuir o consumo
desligando máquinas físicas, ou colocando-as em modo de baixa energia.
Esse refinamento no consumo energético será feito, portanto, de forma a garantir o
desempenho para o usuário final. Os autores apresentam um novo modelo (não-linear) de
consumo de energia da máquina física (PM - Physical Machine). Também é desenvol-
vido um modelo de degradação de desempenho das VMs que compartilham uma mesma
CAPÍTULO 3. ESTADO DA ARTE 35
PM. O algoritmo denominado Power-aware and Performance-guaranteed Virtual Ma-
chine Placement (PPVMP), apresentado no trabalho, utiliza a heurística de colônia de
formigas para encontrar a melhor localização das VMs nas PMs disponíveis. O objetivo
do algoritmo apresentado é diminuir o consumo das máquinas físicas, enquanto garante o
desempenho esperado das VMs instanciadas. Como demonstração e avaliação, o trabalho
utiliza transcoding de vídeo em uma plataforma OpenStack.
3.3 Eficiência energética no plano de controle
O problema de alocação do controlador (CPP), discutido na Seção 2.3, vem sendo
tratado por vários trabalhos, os quais, em geral, buscam a localização ótima dos contro-
ladores na rede de modo a balancear requisitos como: tolerância a falha, latência, vazão,
tempo de recuperação entre falhas, menor consumo energético (Wang et al. 2017, Hu
et al. 2017, Killi & Rao 2016, Yao et al. 2014).
Apesar da maioria dos trabalhos buscarem avanços no sentido da latência e vazão,
há trabalhos cujo foco é também a eficiência energética. Um exemplo desta abordagem
é o trabalho de Hu et al. (2017), onde os autores utilizam a eficiência energética como
métrica para o CPP. O CPP é modelado como um Binary Integer Program (BIP) cujo
objetivo é minimizar o consumo de energia. Devido à complexidade computacional da
busca pela solução ótima, este modelo não é viável para redes grandes. Neste caso, uma
solução heurística é aplicada usando um algoritmo genético denominado Improved Ge-
netic Controller Placement Algorithm (IGCPA), que busca uma solução sub-ótima para
redes grandes. A combinação das duas soluções, BIP e IGCPA, determina a localização
dos controladores, e a abordagem GreCo (Ruiz-Rivera et al. 2015) é usada para associar
os switches aos controladores. Importante observar que BIP e IGCPA são estratégias
offline, já que ambos os algoritmos necessitam de conhecimento prévio da rede, dos con-
troladores e das aplicações que serão executadas para determinar a melhor localização
CAPÍTULO 3. ESTADO DA ARTE 36
dos controladores, visando a eficiência energética.
Um dos trabalhos relacionados a eficiência energética do plano de controle foi desen-
volvido por Chen et al. (2017). Neste trabalho, o objetivo geral é apresentar um algoritmo
online para o balanceamento dos controladores, minimizando o número de controladores.
O trabalho relaciona-se com o nosso no sentido que descreve um algoritmo de alocação
ótima dos controladores que leva em consideração a minimização do número de contro-
ladores, respeitando o tempo de resposta esperado. Os autores apresentam ainda uma
demonstração de que este é um problema NP-Hard e deve, para instâncias grandes do
problema, ser resolvido com uma heurística.
A prova de que o problema de localização de controlador é de fato NP-Hard é feita
através da comparação entre este e o problema da mochila (BPP - bin-packing problem).
Os autores atribuem a cada objeto do problema clássico do BPP, com peso W , um switch
com demanda de tráfego F . Cada mochila (bin no problema clássico) refere-se a um
controlador que pode receber um ou mais switches. Desse modo, o problema CPP é
análogo ao problema do BPP, e portanto no mínimo NP-Hard.
Os autores observam que é possível concentrar switches em um mesmo roteador bus-
cando desligar controladores, reduzindo o consumo no plano de controle. Esse ganho de
eficiência energética é obtido mantendo o tempo de resposta esperado, mas sacrificando
a resiliência da rede, já que menos controladores implica que uma falha afetará um bloco
maior da rede, enquanto nossa abordagem busca aumentar a resiliência junto com a efi-
ciência energética, mantendo o tempo de resposta definido. Ao introduzir mais de um
controlador multi-core é possível dividir a tarefa de encaminhamento de pacotes entre os
novos controladores, assim, em caso de falha o novo controlador poderá assumir a parte
da rede do controlador que falhou. Esta é a abordagem apresentada no Capítulo 5.
Para tratar o problema da alocação de maneira energeticamente eficiente Chen et al.
(2017) propõe um algoritmo que busca minimizar o número de controladores ativos em
função da fração de tráfego alocada a um determinado link entre switch e controlador.
CAPÍTULO 3. ESTADO DA ARTE 37
Há uma versão online e outra offline que se propõe a resolver de forma quase-ótima o
problema da alocação de controladores.
O sistema é dividido em 4 módulos: Measure, Monitor, Action e Distributed Control-
ler Plane. O módulo Distributed Controller Plane é formado pelo conjunto dos próprios
controladores. Os outros módulos são definidos como segue: (i) o módulo denominado
Monitor observa constantemente a demanda de tráfego observando as estatísticas de ba-
lanceamento de carga quando acionado; (ii) o módulo denominado Measure recebe os
dados do Monitor e toma decisões de ajustes para balancear a rede; (iii) o módulo Action
toma as ações necessárias a executar as decisões do Measure. Essas ações são novamente
reportadas ao Measure para que o novo estado da rede seja conhecido, e novas ações
sejam tomadas até que o estado alcançado seja o desejado por Measure.
Os resultados indicam que a variação no número de controladores tem impacto real
no consumo da rede. Este fato reforça a tese de que controladores distribuídos podem
ser importantes não apenas na tolerância a falhas, mas também na eficiência energética.
Os autores ainda apresentam um aumento do número de controladores de acordo com a
variação da demanda de fluxo de forma linear. Em nossas avaliações de controladores
distribuídos apresentadas no Capítulo 5 é possível observar que mesmo com o aumento
de controladores é possível obter melhoria da eficiência, se comparado ao cenário single-
core.
3.3.1 Plano de Controle distribuído e multi-domínio
Como já discutido na Seção 2.3, os controladores SDN representam pontos únicos de
falha em uma rede SDN. Uma solução poderia ser o uso de estratégias de replicação de
controladores para evitar a paralisação de blocos grandes das redes. Apesar da replicação
do controlador ser eficaz no quesito de backup, esta solução não é eficiente quanto ao
uso de recursos. Por isso, a estratégia distribuída apresenta-se como a mais aceita para
cenários de redes mais complexas.
CAPÍTULO 3. ESTADO DA ARTE 38
As implementações distribuídas são exploradas em (Wibowo et al. 2017). Neste traba-
lho, os autores justificam a implementação de controladores distribuídos em função de um
conjunto de requisitos que devem ser atendidos pelas redes SDN, são eles: escalabilidade,
localidade e confiabilidade, segurança e finalmente disponibilidade.
A primeira estratégia de escalabilidade usa apenas um único controlador, onde o foco
é reduzir o overhead associado ao controlador, transportando tarefas para o data-plane por
meio de switches stateful. Essa estratégia vai de encontro à característica de centralização
do controle da SDN.
A segunda estratégia de escalabilidade é relacionada à distribuição dos controladores.
Nesta estratégia, as soluções podem ser classificadas em duas categorias: replicadas e
distribuídas. Na solução distribuída, cada controlador fica responsável por uma parte da
rede, enquanto que na solução baseada no conceito de replicação, todos os controladores
precisam conhecer o estado total da rede. Portanto, a solução distribuída é capaz de en-
tregar mais robustez e desempenho que a replicada (Wibowo et al. 2017). Neste trabalho
a estratégia aplicada é distribuir partes da rede entre os controladores buscando diminuir
a comunicação entre eles como descrito no Capítulo 5.
No item localidade e confiabilidade, os autores afirmam que a localização de um ou
mais controladores deve ser definida considerando que esta escolha impacta no custo
da rede e em seu desempenho como um todo. Algumas métricas são importantes na
decisão da localização dos controladores: latência no caso médio e no pior caso, latência
inter-controladores e latência em caso de falha. A melhor localização busca aumentar
a confiabilidade e diminuir a latência controlador-switch. Alguns trabalhos modelam as
redes e apresentam algoritmos para determinar a melhor localização.
Em relação à segurança, os autores separam os ataques em três categorias: ataques à
camada de aplicação, à camada de encaminhamento e à camada de controle. São mencio-
nadas estratégias para mitigar os vários tipos de ataques, dentre elas: atribuição dinâmica
de controlador master, uso de cache nos switches e aggregation das regras, replicação dos
CAPÍTULO 3. ESTADO DA ARTE 39
controladores, entre outras.
As estratégias para aumentar a disponibilidade baseiam-se na capacidade de se recu-
perar de falhas. Uma dessas estratégias é permitir que um sistema em tempo de execução
monitore falhas de controladores e instancie um novo controlador em caso de falha. Em
cenários com multi-controladores é possível também realizar o balanceamento de carga.
Um detalhe a ser observado no balanceamento de carga é que a comunicação do estado de
carga de cada controlador (usando a interface East/Westbound) não deve consumir muito
da banda alocada para o plano de controle.
No cenário distribuído utilizado nesta tese, apresentado no Capítulo 5, utilizamos uma
implementação distribuída em que a comunicação East/Westbound é reduzida, uma vez
que, os controladores são responsáveis por partições distintas das redes.
3.4 Modelo energético
Em (Priyadarsini et al. 2018), os autores apresentam duas contribuições principais ao
problema da eficiência energética em redes SDN: (i) um modelo de consumo de energia
em SDN; (ii) um algoritmo denominado Efficient Routing Algorithm Selection (ERAS),
cujo objetivo é obter eficiência energética em SDN, selecionando entre 6 protocolos de
roteamento conhecidos, o mais eficiente em função do consumo geral da rede.
O modelo de consumo de energia de uma SDN proposto em (Priyadarsini et al. 2018)
considera a parcela de potência dissipada que é devida ao uso de CPU do controlador. A
potência integral da SDN é modelada por:
P =n
Âi=1
(k1i ⇤Pswi + k2i ⇤Pci + k3i ⇤LTi)+Plink. (3.3)
Essa equação pode ser dividida em 4 partes: (i) Pswi é a potência de cada switch i; (ii)
Pci é a potência de cada controlador i; (iii) LT é a latência total da rede e está relacionada
CAPÍTULO 3. ESTADO DA ARTE 40
ao tamanho das filas na rede; (iv) Plink modela a potência devida às portas dos switches e
controladores que estão ativos.
O foco do nosso trabalho está na equação que define o componente Pci, pois este des-
creve o consumo de energia do controlador. Esse componente é modelado pelas equações
Pci = b⇤PAC +(1�b)⇤PN
C (3.4)
onde b é uma variável binária sendo 1 quando o controlador está executando (awake),
ou 0 quando está inativo. O parâmetro PNC indica a potência consumida pelo controlador
(para detecção de pacotes) enquanto não é ativado por um controlador vizinho.
PAC = PSA +
n
Âi=1
Wi ⇤CPUutili + f (T )⇤Ps. (3.5)
O termo PAC (awake) contém a potência relacionada ao processamento necessário para
cada pacote, representado pelo parâmetro constante CPUutili, relacionado à natureza do
processador sendo usado. Este parâmetro é ponderado por Wi que varia de acordo com
o tipo de pacote e também em função de outras aplicações que estejam em execução no
controlador. O termo f (T ) é uma função que representa o número de pacotes que chegam
à interface do controlador no instante de tempo T . Finalmente, Ps representa a potência
consumida para detectar os pacotes (sensing energy).
3.4.1 O algoritmo ERAS (Efficient Routing Algorithm Selection)
A entrada do algoritmo é o modelo da rede e duas pilhas de protocolos de roteamento,
uma com protocolos de roteamento hierárquico: Leach (Heinzelman et al. 2000), Teen
(Manjeshwar & Agrawal 2002) e Apteen (Manjeshwar & Agrawal n.d.), e uma segunda
usando protocolos híbridos: EIGRP, CEDAR (IETF, 1998) e ZRP (IETF, 1997). A partir
dessas entradas o algoritmo ERAS retorna o melhor protocolo, o consumo de energia dos
CAPÍTULO 3. ESTADO DA ARTE 41
controladores (Pci) e dos links (Plink).
Importante notar que este trabalho atua de forma offline, avaliando toda a topologia
da rede apresentada e definindo, segundo o modelo, qual o algoritmo de roteamento mais
eficiente quanto ao consumo de energia. Por outro lado, a abordagem apresentada nesta
tese busca obter eficiência energética independente da topologia da rede, podendo ser
implementado de forma online.
3.5 Soluções comerciais
Em publicação recente (Ferguson et al. 2021), Google apresentou uma visão geral do
plano de controle denominado Orion em sua WANSDN B4 nos datacenters Jupiter usados
globalmente pela companhia. Cada instância do Orion executa em um equipamento servi-
dor de até 23 núcleos com 24 GB de memória. Cada datacenter Jupiter executa múltiplas
instâncias do Orion para o controle da rede.
A solução de SDN da CISCO descrita em (Cisco 2021) utiliza o controlador virtual
Application Policy Infrastructure Controller (APIC). Por ser um controlador virtual, ele
pode ser comercializado em um equipamento da CISCO ou pode ser instanciado em um
provedor de nuvem como Amazon ou Azure. O hardware necessário é equivalente ao
utilizado em uma instância do controlador Orion, em uma plataforma de servidor comum.
A empresa disponibiliza duas configurações L3 e M3, que utilizam processadores Xeon
de 1.7 GHz a 2.1 GHz, sempre em configurações redundantes de múltiplos controladores.
Esses produtos comerciais usam as plataformas equivalentes às aplicadas nos expe-
rimentos apresentados nos Capítulos 4 e 5, o que indica que os resultados obtidos nesta
tese podem ser expandidos para redes de maior porte.
CAPÍTULO 3. ESTADO DA ARTE 42
3.6 Resumo
Neste capítulo foi apresentada uma revisão dos principais trabalhos no contexto da efi-
ciência energética para SDN em DCN. Muitos trabalhos buscam aplicar técnicas conhe-
cidas das redes tradicionais (Fernández-Fernández et al. 2017, Younus et al. 2019, Assefa
& Ozkasap 2020) , e conseguem obter resultados interessantes. Porém, com a capacidade
de adaptação das SDN é possível mudar dinamicamente o comportamento da rede e tra-
balhos como (Priyadarsini et al. 2018, Aujla et al. 2018) exploram esta capacidade para
alternar entre os melhores algoritmos de roteamento para cada cenário.
Foram apresentadas as métricas de eficiência energética NPUE e CNEE utilizadas
especificamente para medir eficiência em redes de datacenter. Apesar de pouco explorada,
a eficiência energética do plano de controle também é foco de alguns trabalhos, como em
(Hu et al. 2017, Chen et al. 2017). Por fim, soluções de SDN comerciais e de larga escala
foram brevemente apresentadas.
A seguir, apresentamos a Tabela 3.1 que resume um comparativo entre os principais
trabalhos atuais da literatura quanto à eficiência energética em SDNs.
Tabela 3.1: Posicionamento da nossa proposta
Autores A B C D E Estratégia(Aujla et al. 2018) 7 3 7 3 7 Balanceamento(Xu et al. 2017) 7 7 3 7 7 Agendamento(Fernández-Fernández et al. 2017) 7 3 7 3 7 Roteamento(Younus et al. 2019) 7 3 3 7 7 Roteamento(Assefa & Ozkasap 2020) 7 3 7 3 7 Roteamento(Son et al. 2017) 7 7 7 3 7 Migração de tarefas(Zhao et al. 2018) 3 7 3 3 7 Migração de tarefas(Hu et al. 2017) 3 3 3 3 7 Balanceamento(Chen et al. 2017) 3 3 3 3 7 Balanceamento(Priyadarsini et al. 2018) 7 3 3 3 7 RoteamentoNossa proposta 3 3 3 3 3 Paralelismo
A=Eficiência no control-plane; B=Tolerância a falhas;C=Energia do Controlador; D=Multi-Controlador;E=Topologia Parcial.
As características apresentadas na Tabela 3.1 buscam orientar a comparação dos tra-
CAPÍTULO 3. ESTADO DA ARTE 43
balhos com esta tese segundo os seguintes critérios:
• (A) Eficiência no control-plane: O trabalho apresenta alguma melhora na eficiência
energética no plano de controle da SDN;
• (B) Tolerância a falhas: O trabalho permite que mais de um controlador esteja
disponível para o caso de falha de um ou mais controladores outro possa assumir,
evitando o ponto único de falha;
• (C) Energia do Controlador: O trabalho considera o consumo dos controladores do
plano de controle no cálculo de eficiência;
• (D) Multi-Controlador: O trabalho permite que mais de um controlador execute a
solução de maneira distribuída ou replicada;
• (E) Topologia Parcial: O trabalho permite que os controladores da rede tenham
apenas uma visão parcial da rede, não necessitando de conhecimento de todos os
links e dispositivos da rede.
Ao utilizar o processamento paralelo é possível reduzir a frequência de operação dos
núcleos para o cenário de um controlador multi-core ou múltiplos controladores multi-
core. Essa alternativa também preenche uma lacuna na pesquisa de controladores SDN
energeticamente eficientes em que o controlador não precisa necessariamente ter conhe-
cimento de toda a topologia previamente para obter ganhos de eficiência energética.
Importante notar que o trabalho de Hu et al. (2017) é aplicável apenas a redes que já se
conhece o padrão de tráfego e topologia previamente, já que este é executado offline. Além
disso, o trabalho de Chen et al. (2017), descrito na Seção 3.3, busca diminuir ao máximo
o número de controladores, o que diminui também a tolerância a falhas. Porém, nossa
proposta considera que um número maior de controladores operando em uma frequência
mais baixa pode ser energeticamente mais eficiente, aumentando a tolerância a falhas e
mantendo o SLA definido, conforme demonstrado nos Capítulos 4 e 5.
Capítulo 4
Experimentos em um controlador SDN
multicore
Neste capítulo é apresentado o método proposto de paralelismo no controlador SDN.
O modelo Dispatcher and Workers (Tanenbaum & Bos 2014) discutido na seção 2.5 é
implementado em um controlador Ryu e seu desempenho é aferido usando diferentes
métricas: vazão (throughput) e latência. Um avaliação do consumo energético dos mo-
delos single-core e multi-core é apresentada, demonstrando melhor eficiência do modelo
paralelo com diminuição da frequência de operação.
4.1 Controladores SDN paralelos
Como descrito na Seção 1.1, redes definidas por software são compostas minima-
mente por uma camada de controle (plano de controle) e uma camada de encaminha-
mento de dados (plano de dados). A camada de controle é responsável por muitas ativi-
dades paralelas relacionadas a decisões de encaminhamento, mas também a novas fun-
ções de rede, como: segurança, contabilidade, alocação de recursos, entre outras. Mui-
tos controladores existem no mercado (Kreutz et al. 2015), alguns de código proprietá-
rio como (Cisco 2021, Ferguson et al. 2021), outros baseados em código aberto como
(Ryu 2021a, ONF 2021, ODL 2021).
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 45
Para os experimentos aqui descritos, foi selecionado o controlador Ryu (Ryu 2021a).
Essa escolha é baseada nos critérios apresentados na Tabela 4.1. O primeiro critério foi a
seleção de controladores de código aberto, de modo que fosse possível analisar a imple-
mentação de paralelismo nestes. Apesar de vários controladores terem seu código aberto,
nem todos oferecem uma documentação clara e abrangente da implementação, focando
mais em tutoriais de uso ou descrições de funcionalidades, como é o caso do Pox e do
Cisco ACI. Também foi considerado importante que o controlador estivesse ativamente
em desenvolvimento e em atualização contínua, o que excluiu o controlador Nox, cuja
última atualização ocorreu em 2014, sendo posteriormente substituído pelo Pox. Como
último critério, buscou-se um controlador modular com o mínimo de funcionalidades
obrigatórias, ou seja, de baixa complexidade para que fosse possível avaliar em detalhes
o funcionamento interno do controlador.
Tabela 4.1: Comparação de controladores SDN
CódigoAberto Documentação Última
Atualização Complexidade Linguagem
Onos Sim Abrangente 2021 Alta JavaNox Sim Abrangente 2014 Baixa C++Pox Sim Limitada 2020 Baixa PythonOpenDayLight Sim Abrangente 2021 Alta JavaRyu Sim Abrangente 2021 Baixa PythonCisco ACI Não Limitada 2021 Alta N/A
Ryu é um framework escrito em Python, modular, que implementa uma camada de
abstração para o protocolo Openflow. O framework oferece um módulo central (ryu-
manager) e aplicações podem ser executadas por este. Exemplos de aplicações incluem:
switch layer 2, monitor de rede, provedor de uma API REST, entre outras. Assim, o
administrador de rede pode carregar apenas a aplicação necessária ao cenário em uso.
Uma aplicação comum estende a classe RyuApplication e implementa métodos para tratar
eventos como: o cadastro de um novo switch, a chegada de um pacote ao controlador,
mudanças de topologia, entre outros.
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 46
4.2 Método proposto de Paralelismo no controlador Ryu
Segundo (Ryu 2021b), as aplicações são single-thread apesar do framework ser multi-
threaded, usando para isso Greenlet Event Lib (GEvent 2021) que permite programação
concorrente intra-processo. Apesar de ser efetiva para o tratamento de eventos paralelos
pertencentes à mesma aplicação, essa implementação limita o uso de múltiplos processa-
dores pela natureza das threads leves. Outra limitação deste modelo está no interpretador
da linguagem Python; a versão oficial do Python inclui um mecanismo de controle de
concorrência que permite o fácil isolamento de threads, mas com o contraponto de blo-
quear acessos de outras threads que poderiam executar em paralelo. Este controle do
interpretador Python, chamado de Global Interpreter Lock (GIL), oferece simplicidade
no desenvolvimento, mas cria um mutex que restringe a apenas uma thread em execução
a cada instante de tempo, o que é muito prejudicial para tarefas paralelas associadas a
múltiplos núcleos de processamento.
A documentação oficial apresenta diferentes implementações da linguagem Python
(Python 2021b). Várias implementações existem com objetivos variados, buscando pa-
ralelismo (Python 2021), velocidade (Pypy 2021) ou uso em sistemas com restrições de
recursos como os sistemas embarcados (CircuitPython 2021). Nem todas as implemen-
tações suportam todo o conjunto de instruções da implementação de referência chamada
de CPython. Como Jython e IronPython são implementações sobre outras plataformas,
Java e .Net respectivamente, o objetivo destas não está no desempenho ou economia de
recursos, mas na facilidade para os desenvolvedores e integração com as outras platafor-
mas. Entre as alternativas a Pypy é conhecida por seus ganhos de velocidade, por usar um
compilador do tipo just-in-time (JIT). Durante os teste realizados o uso do Pypy exigiria
uma reimplementação de muitas partes do núcleo do framework Ryu o que foge ao escopo
deste trabalho.
Para evitar o mutex do GIL uma estratégia é substituir a implementação multi-thread
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 47
por uma multi-processos. Com o uso de multi-processos uma aplicação Python (neste
caso uma aplicação Ryu) dispara múltiplos processos concorrentes e cada processo en-
tão poderá ser alocado a um núcleo de processamento, de acordo com o escalonador do
sistema operacional em execução. Essa foi a estratégia usada para garantir que o con-
trolador Ryu utilizasse ao máximo a capacidade de paralelização do hardware usado no
experimento.
Uma nova versão da aplicação de exemplo que acompanha o Ryu chamada sim-
ple_switch_13 foi implementada usando o mecanismo multi-processos com a biblioteca
multiprocesing (Python 2021a) da linguagem Python, de forma a garantir que múltiplos
processos filhos pudessem utilizar os vários núcleos de processamento disponíveis. A
Figura 4.1 ilustra um comparativo da versão original e da nova versão.
No tipo (A), foi utilizada a biblioteca disponibilizada pelo controlador Ryu, baseada
em greenThreads e eventlets. A vantagem desta abordagem é sua facilidade de implemen-
tação já que o framewrok Ryu disponibiliza métodos diretos para a criação de threads de
usuário. Porém, como o Sistema Operacional não tem controle sobre estas threads, o
escalonamento entre os diferentes núcleos fica prejudicado.
No tipo (B), a biblioteca multiprocessing do Python foi utilizada para permitir a cri-
ação de processos separados a partir do controlador Ryu. Apesar de incluir o overhead
das trocas de contexto, essa abordagem permite o uso dos N núcleos disponíveis, es-
calonando segundo a política do Sistema Operacional. Nesta versão, apenas o próprio
framework Ryu passa a ser um gargalo na distribuição das tarefas. Este gargalo foi con-
tornado dividindo tarefas de cada pacote de rede entre os vários processos criados no
início da aplicação.
O Algoritmo 4 apresenta a implementação padrão de um switch Ryu, enquanto o
Algoritmo 5 apresenta a implementação multi-processos. Apesar do controlador Ryu
utilizar várias threads internamente para leitura e processamento de pacotes quando um
pacote chega e precisa ser tratado, como na função encontraRota(), apenas um núcleo
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 48
RYU
O.S.
RYU
O.S.
Process Thread
(A) (B)
Figura 4.1: (A)Implementação original (B)Implementação Ryu multi-core
de processamento será usado, o que implica em um gargalo caso esta função tome muito
tempo de CPU. Na nova implementação, o processo pai recebe um novo pacote e delega o
processamento para um dos processos filhos, que pode estar executando em outro núcleo,
o processo pai fica livre para obter mais pacotes da interface de rede e distribuí-los aos
vários processos filhos distribuídos nos vários núcleos, como ilustrado na Figura 2.5.
Importante notar que o centro das operações a ser executadas para cada pacote (re-
presentado pelas funções encontraRota() e outrasOperações()) são executadas pelos pro-
cessos Workers desde a escolha das rotas até o envio final da instrução de configuração
OpenFlow para o switch em questão.
Algoritmo 4: Switch Single Ryu1 function Main:2 while controladorLigado() do3 obtemPacote;
/* Bloqueia o controlador até finalizar processamentodeste pacote */
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 49
Algoritmo 5: Switch Multicore Ryu1 def processoFilho(pacote):2 while controladorLigado() do3 obtemPacote;4 encontraRota();5 outrasOperações();6 end
7 function Main:8 criarProcessoPai();9 i � 0 ;
10 while i < Número de Núcleos do11 criarProcessoFilho(i);12 i++;13 end14 while controladorLigado do15 aguardarNovoPacote();16 selecionarProcessoFilho;
/* libera o processo pai (dispatcher) para obter opróximo pacote */
Em sistema Linux, a frequência de operação dos núcleos de processamento pode ser
ajustada individualmente utilizando ferramentas como o cpupower (CPUPower 2021). O
processador (Intel Xeon E31220 ) utilizado nos experimentos, apresentados aqui, permite
frequências que variam de 1.6 GHz a 3.0 GHz. O ajuste de frequência dos núcleos pode
ser definido de forma automática utilizando os cpu-governors. Esses reguladores definem
o modo de operação e o balanceamento entre performance e consumo (Linux 2021b).
O kernel Linux oferece quatro reguladores padrão: userspace, performance, schedutil e
ondemand.
O performance ajusta as frequência ao valor máximo de operação disponível, indepen-
dente de fatores externos como a demanda ou a ociosidade. É uma política que compro-
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 50
mete o consumo em função de uma garantia de entrega de performance máxima constante.
O schedutil utiliza informações do escalonador do kernel para medir a carga atual
do sistema como um todo e ajustar a frequência de operação em linha com a demanda.
Assim o schedutil age em reação ao aumento ou diminuição da carga no sistema, aumen-
tando a frequência de operação em sistema com uma carga alta e diminuindo a frequência
quando o sistema está mais ocioso, economizando energia nestes momentos. Este re-
gulador também pode aumentar a frequência de operação de núcleos em que estejam
executando processos que passaram muito tempo bloqueados aguardando operações de
entrada e saída.
O terceiro modelo, denominado onDemand, usa dados obtidos de seu próprio contexto
(não vindos do kernel) para estimar a carga à qual a CPU está submetida. Um processo
leve é invocado a cada 10 ms para computar o tempo que a CPU ficou ociosa desde a
última execução. Essa métrica é então usada para calcular a frequência adequada para a
CPU nos próximos milissegundos.
O último modelo, denominado userSpace, permite que um usuário administrador
ajuste a frequência individual dos núcleos manualmente para um valor estático; este foi
o regulador utilizado nos experimentos de modo a ter controle preciso da frequência de
operação.
Além da frequência de operação, é possível desativar os núcleos de processamento
em tempo de execução utlizando o subsistema do kernel conhecido como CPU Hotplug
(Linux 2021a). O controle dos núcleos em execução é feito através de uma interface sysfs
em /sys/devices/system/cpu.
4.4 Métodos de medição de consumo do processador
O consumo de energia em processadores modernos passou a ter grande importância
com o aumento do número destes equipamentos em grandes datacenters. Assim, fabri-
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 51
cantes de processadores incluíram em seus chips sensores e métricas específicos para a
medição dessa grandeza. Os processadores Intel de famílias posteriores à Sandybridge
incluem um conjunto de registradores model specific registers (MSR) capazes de arma-
zenar informação sobre o consumo do núcleo de processamento (core), do processador
como um todo (package) e do acesso à memória (DRAM). Esses registradores, em pro-
cessadores Intel, fazem parte de uma interface conhecida como Running Average Power
Limit (RAPL) . Essa funcionalidade também está presente em processadores AMD, mas
até o momento é pouco consistente, como aponta (Weaver 2015). As avaliações aqui
apresentadas ocorrem em processadores com suporte a Intel RAPL.
4.4.1 Turbostat
Um dos softwares utilizados na medição de consumo de aplicações em ambiente Li-
nux é o Turbostat (Linux 2021c). Este software, desenvolvido e disponibilizado no kernel
Linux, permite obter informações de tecnologia, frequência e estatísticas de consumo de
processadores x86. O software pode ser usado para medir o consumo de um determinado
software ou medir o status do sistema, a cada intervalo de tempo.
Para apresentar as informações de consumo, o turbostat precisa de acesso aos regis-
tradores específicos do processador (MSR). Para acesso a esses registradores é necessário
utilizar o módulo msr1 do kernel linux. O módulo msr permite acesso a informações espe-
cíficas do modelo do processador através de arquivos especiais disponibilizados na pasta
/dev/cpu/[numero]/msr.
4.4.2 Interface sysfs do Kernel Linux
Por ser uma ferramenta de fácil utilização, o Turbostat é útil em uma avaliação pre-
liminar do consumo do processador em diferentes cenários de carga e frequência. Para1usando o comando insmod msr
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 52
medições mais frequentes e precisas e para ser possível utilizar como uma interface direta
com os dados de consumo nos experimentos, optou-se por acessar os dados diretamente
da interface sysfs do kernel Linux.
As medições de consumo para os experimentos com um controlador multi-core são
feitas diretamente da interface, do tipo ramfs, conhecida como sysfs do kernel Linux dis-
ponível em: /sys/class/powercap/intel-rapl. Este diretório é uma interface para a estrutura
RAPL do processador, e apresenta, no arquivo energy_uj, o consumo acumulado de cada
processador em µJoules.
4.5 Erro em medições
Os resultados apresentados nas Seções 4.6.1, 4.6.2 e 5.5.1 foram obtidos através da
interface sysfs para o Intel RAPL. O uso desta interface permite a realização de leituras
sequenciais muito rapidamente já que o sysfs é um RAMFS, um sistema de arquivos virtual
que reside em memória de trabalho.
Apesar da interface RAPL apresentar uma resolução em µJoules, as operações neces-
sárias para a leitura deste dado presente no processador consomem tempo, o que implica
na inserção de um erro no tempo de amostragem.
Os registradores MSR do RAPL "report the actual energy use for the respective power
plane domains. These MSRs are updated every 1msec."(Intel 2019b). O que em teoria
permitiria medições precisas na faixa dos milissegundos. No entanto como apresentado
no Algoritmo 6 as operações de leitura e registro não são atômicas tampouco podem ser
consideradas instantâneas.
No 6 a instrução leituraSysfs() na verdade é divida em um conjunto de chamadas ao
Sistema Operacional que permitem a leitura e cópia do valor do registrador MSR do Intel
RAPL (representado pelo arquivo energy_uj) para uma variável do programa, esse tempo
de execução atrasa a leitura em frações de segundo.
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 53
A segunda linha, comando sleep, é uma chamada ao Sistema Operacional que coloca
o processo em estado de suspensão por pelo menos 1 segundo. Esse estado pode ser um
pouco maior considerando o tempo para processar a chamada ao Sistema Operacional ou
pelo próprio scheduler.
Ao executar a segunda leitura, presumivelmente 1 segundo após a primeira, subtraí-
mos as leituras e obtemos o resultado da medição de consumo na amostragem de 1 se-
gundo. Porém, esse resultado será adicionado dos erros de tempo de leitura e cópia men-
cionados anteriormente, além do possível erro de tempo comando usleep.
Algoritmo 6: Leitura de Energia RAPL Sysfs1 abrirArquivoSysfs();2 while TRUE do3 start = leituraSysfs();4 usleep(1)5 end = leituraSysfs();6 print(end - start);7 end
Para avaliar o impacto deste erro de tempo de amostragem, inserido pelos tempos de
execução das instruções experimentos foram realizados onde mede-se o tempo decorrido
entre a primeira leitura e a segunda leitura. Desse modo o erro será a diferença entre o
tempo pretendido, 1 segundo, e o tempo medido.
A Figura 4.2 apresenta os valores de tempo real obtidos neste experimento, percebe-se
que o erro no tempo será sempre adicional pois este corresponde aos tempos de execução
das instruções. O gráfico permite observar que o erro varia não uniformemente, mas está
limitado a uma região pequena, entre 1,000097769 e 1,000183288.
Um resumo das informações da amostragem está na Tabela 4.2. O valor máximo da
amostragem 1,000183288 representa um erro de 0,018% e o valor médio do tempo de
amostragem real é de 1,00015700 o que representa um erro de 0,016% se comparados ao
valor esperado de amostragem de 1 segundo. Desse modo, o erro inserido pelo método
de medição pode ser considerado aceitável para os cenários usados nos experimentos.
CAPÍTULO 4. EXPERIMENTOS EM UM CONTROLADOR SDN MULTICORE 54
