Implementando Balanceamento de Carga em Redes Virtuais

utilizando OpenFlow e NOX

Mrcio Barbosa de Carvalho, Wanderson Paim Jesus
Instituto de Informtica Universidade Federal do Rio Grande do Sul (UFRGS)
Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil
{mbcarvalho,wpjesus}@inf.ufrgs.br

Abstract. This paper presents a new approach to load balancing between

servers arranged randomly on a computer network, making the balancing
more effective and intelligent. We use an approach in which the control of the
distribution is abstracted by the network centre, keeping the service
completely transparent to the applications involved in requests. To validate
this proposal we use a software defined network, which set up an environment
that combines the features of OpenFlow and NOX.
Resumo. Este trabalho apresenta uma nova proposta para o balanceamento
de carga entre servidores dispostos aleatoriamente em uma rede de
computadores, tornando o balanceamento mais eficaz e inteligente.
Utilizamos uma abordagem em que o controle da distribuio abstrado
pelo centro da rede, mantendo este servio totalmente transparente para as
aplicaes envolvidas nas requisies. Para a validao desta proposta
utilizamos uma rede baseada em software, na qual definimos um ambiente que
agrega as funcionalidades do OpenFlow e do NOX.

1. Introduo
Atualmente muitos esforos esto sendo empreendidos para desenvolver novos
protocolos nas camadas de enlace, rede e transporte, visto que so as camadas que
sofreram poucos aprimoramentos nos ltimos anos, em comparao ao grandes avanos
na camada fsica e de aplicao. A grande dificuldade de avanar nestas camadas a
necessidade de dispor de equipamentos e infraestrutura para desenvolver e testar estes
novos protocolos. Uma excelente estratgia para alcanar este objetivo a utilizao de
redes baseadas em software. Neste ambiente pode-se utilizar a infraestrutura e os
equipamentos existentes para desenvolver e testar novos protocolos. Nesta abordagem, o
plano de controle dos ativos de rede transportado para uma entidade chamada
controlador. No controlador possvel definir regras para fluxos baseados em propostas
de novos protocolos ou nos j existentes. Um ponto muito interessante desta abordagem
que a rede nativa pode continuar operando normalmente, pois definida uma regra de
fluxo padro que direciona fluxos no contemplados pelas polticas do controlador para
o plano de controle nativo dos dispositivos.
Neste novo cenrio, pode-se repensar como resolver problemas enfrentados sem
a possibilidade de interferir na lgica de controle dos dispositivos. O balanceamento de
carga um destes problemas que comumente resolvido atravs do DNS [Xu et al.
2004] ou por um dispositivo dedicado a balanceamento. Pelo DNS, o balanceamento
feito a cada consulta pelo nome de um servidor e o servidor DNS responde endereos

diferentes para o mesmo nome a cada consulta implementando uma estratgia do tipo
round-robin. Dispositivos dedicados fornecem maiores funcionalidades como pesos
atribudos para cada servidor e outras polticas. Entretanto, as duas abordagens
enfrentam problemas graves. O DNS fornece um balanceamento de carga muito
rudimentar e os dispositivos dedicados impem ao ambiente um ponto nico de falha.
Sendo que um dos objetivos do balanceamento de carga eliminar pontos nicos de
falha onde pode-se prover ao ambiente no apenas escalabilidade como tolerncia a
falhas.
A soluo baseada em DNS oferece um benefcio interessante que o
balanceamento de carga baseado na localizao do cliente. Por exemplo, quando uma
requisio para www.dominio.com chega a um DNS brasileiro este servidor pode
retornar o endereo de um servidor brasileiro que atenda ao www.dominio.com. Para
que esta estratgia funcione devero ser configurados vrios servidores DNS ao redor do
mundo o que leva a um problema de escalabilidade na gerncia deste ambiente. O
problema est em ter um servidor DNS para cada localizao que deseja-se tratar.
Portanto, o problema de escala da gerncia deste ambiente tambm aparecer em redes
corporativas onde deseja-se ponderar diversas localizaes. Outra abordagem o
servidor DNS fazer uma anlise do endereo origem da requisio. Nesta abordagem,
apenas um servidor DNS teria as entradas para todos os servidores espalhados pelo
mundo. Certamente, esta soluo mais custosa para o servidor DNS que precisar de
uma maior capacidade de processamento para cumprir esta tarefa.
Utilizando redes baseadas em software pode-se atuar na lgica de controle da
rede. Desta forma, quando uma requisio para um determinado servio chegar ao ativo
de rede ele consultar sua base de polticas para tentar enquadrar o novo fluxo. No
havendo uma poltica adequada, ele perguntar ao controlador que atitude tomar com
aquele fluxo. Neste momento, o controlador poder atuar como um balanceador de
carga, pois saber as localizaes dos clientes e dos servidores e alm disso, saber a
quantidade de fluxos encaminhados para cada servidor, pois possui uma viso ampla da
rede. Nossa proposta atua neste ponto onde o controlador ser programado para prover
balanceamento de carga baseado na topologia da rede e na quantidade de fluxos
encaminhados para cada servidor.
Ser conduzida uma simulao para verificar o funcionamento do controlador
onde dada uma topologia ele dever priorizar o servidor mais prximo.
A Seo 2 apresenta as caractersticas do controlador, qual o seu papel neste
contexto e quais so as especificidades adicionadas para se adequar ao contexto. Um
ambiente de avaliao descrito na Seo 3, apresentando todos os aplicativos
utilizados para se fazer os testes. Na Seo 4 so apresentados os resultados obtidos com
os experimentos. E para finalizar apresentado uma concluso na Seo 5.

2. Controlador
O controlador implementado neste trabalho atuar no balanceamento de carga entre
servidores web dispostos aleatoriamente em uma rede. Desta forma, o principal atributo
que definir o fluxo ser a porta de destino da conexo TCP (80). Este atributo foi
definido para este cenrio e no se caracteriza um regra, nada impediria, por exemplo,
de se utilizar outros parmetros, como o endereo IP ou at mesmo um conjunto IP e
porta.

No faz parte do escopo do trabalho aprender dinamicamente a topologia da

rede, calculando os pesos das arestas dinamicamente ou considerando alteraes na
topologia. Utilizaremos como base a topologia descrita na Figura 1, assumindo para
qualquer efeito seus pesos, endereos MACs e IPs pr definidos. Em uma outra
abordagem, o controlador poderia inferir a topologia analisando o trfego entre os
clientes, da mesma forma que um switch aprende quais computadores esto ligados a
cada uma de suas interfaces.
Na soluo proposta utilizamos a estratgia que prioriza o servidor com menor
nmero de hops necessrios para que o cliente chegue at ele. Entretanto, a tabela que
implementa esta estratgia no baseada no cliente e sim no primeiro switch por onde
est chegando a requisio do cliente. No controlador temos uma tabela indexada pelo
endereo MAC do servidor e o id do switch. Consultando esta tabela obtm-se o peso
para chegar ao servidor X partindo do switch Y.
Quando uma requisio endereada para a porta 80 chega ao switch, ele verifica
se possui uma poltica para aquele fluxo. Se possui, segue a poltica. Caso contrrio,
pergunta para o controlador qual atitude tomar. O controlador verifica em sua tabela
qual o peso para cada um dos servidores partindo do switch que questionou pela
poltica. Baseado nestes valores e na quantidade de requisies j atendidas por cada
servidor, o controlador decide qual o encaminhamento a ser feito.
Em uma rede de maior escala a quantidade de servidores pode variar e desta
forma tambm mudaria a forma de clculo empregada. Na topologia de teste utilizada
neste trabalho, temos apenas dois servidores e portanto esta deciso baseada em um
clculo bem simples, que tem por base duas razes. A primeira entre os pesos obtidos
da tabela citada acima (pesoServidor1 / pesoServidor2).
O controlador mantm um contador de requisies j encaminhadas para cada
servidor. Este contador global para o ambiente. No momento de cada requisio ao
switch, o controlador calcula a razo entre o nmero de requisies atendidas de um
servidor e de outro (nServidor1 / nServidor2), formando assim a segunda razo para o
clculo.
O prximo passo ento comparar as razes. A primeira razo controla quantas
requisies devem ir para cada servidor baseado na distncia em nmero de hops (peso).
A segunda razo identifica a carga atual do balanceamento. Se a razo da carga atual do
sistema for maior que a razo dos pesos, o controlador deve informar uma poltica para
o switch enviar a requisio ao servidor2 ( o divisor, reduzir a razo da carga atual).
Caso contrrio, pode-se informar ao switch a poltica de enviar para o servidor1, o mais
prximo, pois a carga do sistema ainda est adequada. A cada encaminhamento o
contador de requisies do servidor escolhido incrementado.
Esta composio fundamental para no onerar servidores que estejam
prximos a muitos clientes. Ou seja, no se pode utilizar apenas a informao de
proximidade para tomar a deciso, pois poderia sobrecarregar apenas um servidor.
Compondo a informao de carga atual do sistema com a informao de proximidade a
estratgia evolui de envia para o servidor mais prximo para envia para o servidor
mais prximo e menos ocupado.

Figura 1. Topologia considerada no desenvolvimento e avaliao do

controlador.

3. Ambiente de Avaliao
Para avaliar as estratgias apresentadas, utilizamos um ambiente virtualizado
(Testbed) gerado pelo aplicativo Mininet [ Lantz et al. 2010] em sua verso alpha.
Neste aplicativo definimos a topologia apresentada na Figura 1 por meio de um script
em linguagem Python. Os dispositivos criados desta forma recebem um endereo IP
conforme descrito na Figura 1 e por meio de um parmetro definimos que os endereos
MACs dos ns sejam baseados em seus IPs, o servidor 1 por exemplo tem o MAC
00:00:00:00:00:03, pois seu IP 10.0.0.3.
Uma outra ferramenta amplamente utilizada neste cenrio o OpenFlow
[McKeown et al. 2008]. Baseado na manipulao de tabelas de fluxo em switches
Ethernet o OpenFlow vem alimentando as ambies da comunidade cientfica em prol
de superar as dificuldades existentes para propor, experimentar e implementar novas
funcionalidades e solues para a Internet do Futuro. O Mininet, citado acima, permite
que uma rede OpenFlow completa seja simulada em cima de um nico kernel Linux.
Neste trabalho utilizamos sua verso 1.0.
Este ambiente virtualizado controlado por uma plataforma de controle de rede
chamada NOX [ Gude et al. 2008]. Mesmo no sendo a mais estvel, utilizamos a sua
verso de desenvolvimento uma vez que contem as mais recentes atualizaes.
Conforme descrito na seo anterior, o controlador centraliza toda deciso a ser tomada
dado um novo fluxo. Neste trabalho o controlador centraliza as decises de
encaminhamento de pacotes que tenham como destino a porta 80.
A integrao entre estas ferramentas feita por meio de uma mquina virtual, a
qual utiliza um kernel modificado e ajustado especificamente para este tipo de
programao. Para aprimorar a programao utilizamos um controlador NOX instalado
na mquina hospedeira e configuramos para que o ambiente virtualizado criado pelo
Mininet se conecte a ele passando alguns parmetros, como IP do hospedeiro e porta

(padro 6633) configurada pelo NOX.

A topologia utilizada neste trabalho contm quatro mquinas (dois clientes e
dois servidores) e cinco switches. Supomos que este ambiente de pequena escala seja
suficiente para demonstrar a validade da proposta, uma vez que os servidores e clientes
esto dispostos de forma estratgica.
Supomos um ambiente de navegao, onde estariam presentes servidores web,
de e-mails, de bancos de dados e tambm clientes acessando estes servios. Para melhor
exemplificar nomeamos a mquina cliente h1 de Anne e a mquina cliente h2 de James.
Sendo assim, uma requisio web feita por Anne seria atendida de maneira mais eficaz
pelo Servidor 1, por estar mais perto, assim como o Servidor 2 atenderia de maneira
mais eficaz uma requisio do cliente James.
Assumimos para isso que o comprimento dos enlaces sejam os mesmos, e
portanto a distncia considerada neste caso a quantidade de hops at o servidor,
conforme ilustrado na Figura 1. Assumimos tambm igualdade de largura de banda nos
enlaces.

4. Avaliao
O objetivo desta avaliao provar a validade da soluo de balanceamento de
carga apresentada, alm de demonstrar a capacidade das ferramentas utilizadas neste
processo. Foge ao escopo deste trabalho demonstraes de performance dos enlaces
uma vez que a abordagem proposta trata de modificaes na lgica de funcionamento do
balanceamento de carga, tornando-o um processo mais inteligente e eficaz.
Podemos caracterizar essa abordagem como uma tentativa de solucionar o
problema de balanceamento de carga ponderando a carga que cada servidor recebe com
base na garantia de um certo nvel de qualidade de servio (QoS). Essa caracterstica
semelhante quelas encontradas em redes de Content Delivery Networks CDN [ Yin et
al. 2010], em que o principal objetivo a entrega de servios sensveis ao tempo, o que
exige eficincia nas solues que tratam QoS. Para isso as redes CDN utilizam, dentre
outras solues, uma parecida com a apresentada neste artigo: mantem o servidor, ou
rplicas dele, prximas dos clientes de forma que os custos entre eles seja os menores
possveis.
Para a execuo dos testes, utilizamos um script shell com uma estrutura de
repetio para executar diversas vezes o comando telnet <IP> 80 atravs dos
terminais simulados dos ns dos clientes. Desta forma conseguimos simular diversas
requisies web com origem em um cliente especfico e destino em um dos servidores.
Quando essa requisio chega ao primeiro switch o controlador (NOX) identifica o
fluxo e o modifica de acordo com a poltica que implementamos. Ou seja, os campos de
destino, MAC e IP, so alterados a cada novo fluxo e para isso utilizamos as funes do
OpenFlow OFPAT_SET_NW_DST e OFPAT_SET_DL_DST que so instaladas como
forma de poltica no switch atravs do comando install_datapath_flow. Desta forma
informamos ao switch que todos os pacotes daquele fluxo recebero essas mesmas
modificaes.
Para identificarmos o recebimento das requisies por parte dos servidores e
consequentemente identificarmos que uma dada requisio foi efetivamente
encaminhada a um determinado servidor, possibilitando a contabilizao do nmero de
requisies pra cada um deles, instalamos uma poltica de contagem no controlador que

incrementa uma certa varivel sempre que recebesse o aviso de um fluxo vindo de um
servidor com destino ao cliente na porta 80. Ou seja sabemos que neste momento o
servidor j recebeu a requisio e est respondendo ao cliente. Sendo assim, se o loop
citado anteriormente fez, por exemplo, 100 requisies, e foram identificadas 25
respostas (a um dos cliente de teste) vindas do Servidor 1 e 75 do Servidor 2, podemos
calcular a proporo, neste caso 1:3, e comparar com a proporo esperada, que varia de
acordo com a posio de ambos: cliente e servidor.

Servidor 1

Servidor 2

Nmero de requisies

30
25
20
15
10
5
0
2
1

4
3

6
5

8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
Tempo

Grfico 1. Requisies feitas a partir do cliente James.

Para demonstrar a validade da abordagem de balanceamento de carga ponderado

pela qualidade de servios foram realizados alguns testes. O primeiro deles utilizou
como fonte das requisies o cliente James, que est conectado ao switch s4 e portanto
tem como servidor mais prximo o Servidor 2. Considerando que o nmero de hops a
partir do switch s4 at o switch s3 (o qual agrega o Servidor 1) seja 2 e at o switch s5
(o qual agrega o Servidor 2) seja 1, o balanceamento ideal teria que manter essa
proporo, ou seja, espera-se que sejam encaminhadas duas vezes mais requisies para
o Servidor 2 do que para o Servidor 1. Podemos observar este comportamento no
Grfico 1 e Grafico 2 analisando a sequncia de testes do loop, representado pelo eixo x
no primeiro grfico e pelo eixo y no segundo.

Servidor 1

Servidor 2

37
33
29

Tempo

25
21
17
13
9
5
1
0

10

15

20

25

30

Nmero de requisies

Grfico 2. Requisies feitas a partir do cliente James.

Analisando o Grfico 2, por exemplo, podemos verificar que no instante de

tempo 29, a barra que representa o Servidor 1, acusa o envio de 10 requisies,
enquanto a barra que representa o Servidor 2, acura o envio de 20 requisies. Mantemse desta forma justamente a proporo definida pela quantidade de hops entre os clientes
e os servidores, que de 1:2.
O segundo teste tomou como origem das requisies a cliente Anne, que est
mais prxima do Servidor 1 e est ligada ao switch s1. Este switch mantm uma
distncia de 2 hops at o switch em que est ligado o Servidor 1 e de 3 hops at o switch
em que est ligado o Servidor 2. Sendo assim, da mesma forma apresentada no teste
anterior, espera-se que o balanceamento seja feito mantendo essa proporo, ou seja, a
cada duas requisies feitas ao Servidor 2, trs sejam feitas ao Servidor 1, que est mais
perto, justificando a maior quantidade de requisies.
Os resultados obtidos no segundo teste so apresentados no Grfico 3 e Grfico
4. No primeiro deles possvel acompanhar no eixo vertical o nmero de requisies
feitas aos dois servidores (Servidor 1, identificado pela linha com losangulos e Servidor
2, identificado pela linha com tringulos). No instante 24 podemos perceber que apenas
10 requisies foram feitas ao Servidor 2, enquanto que ao servidor 1 foram feitas 15.
Estes valores seguem a proporo definida pelo nmero de hops entre os servidores: 2/3.
Justifica-se essa distribuio utilizando o contra-exemplo de se utilizar apenas o
servidor mais prximo como destino das requisies, neste caso, se tivssemos diversos
clientes ligados ao switch s1, o mesmo em que est Anne, apenas o Servidor 1 receberia
requisies, e causaria uma sobrecarga, da mesma forma, se tivssemos vrios clientes
ligados ao switch s4, apenas o Servidor 2 receberia requisies. Por tanto a utilizao da
proporo entre distncia e quantidade de requisies j enviadas quele servidor
especfico.

Servidor 1

Servidor 2

30

Nmero de requisies

25
20
15
10
5
0
2
1

4
3

6
5

8
7

10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
Tempo

Grfico 3. Requisies feitas a partir da cliente Anne.

Servidor 1

Servidor 2

37
33
29
25
21
17
13
9
5
1
0

10

15

20

Grfico 4. Requisies feitas a partir da cliente Anne.

25

30

5. Concluses
Dados os resultados apresentados no captulo anterior, conclumos que a
abordagem desenvolvida eficaz e inteligente, fazendo o balanceamento baseado na
distncia e na carga dos servidores, o que acaba atribuindo uma soluo conjunta para
problemas que exigem qualidade de servio.
Este tipo de estratgia, j utilizada em solues de rede de fornecimento de
contedo (CDN) de grandes corporaes, entretanto o caso abordado neste artigo
apresenta uma maneira simplificada deste tipo de soluo, que poderia ser aplicada em
qualquer tipo de rede em que se pretenda considerar a distncia do cliente com o
servidor, o que supostamente garante a qualidade de servio. Solues deste tipo
geralmente dependem da replicao de contedo, uma vez que os dados poderiam ser
acessados tanto de um servidor quanto de outro, alm de grandes esforos relacionados
ao gerenciamento das rplicas e das conexes.
A proposta apresentada permitiria por exemplo manter esse tipo de deciso a
cargo de um controlador ou um conjunto deles (para garantir tolerncia a falhas), de
forma que toda deciso fique em um nvel mais prximo do substrato de rede,
garantindo maior performance na aplicao das mesmas. Por outro lado solues em
nvel de aplicao no podem tirar proveito do contato direto com os dispositivos
envolvidos nas conexes de rede, por isso mantm todo controle de proximidade,
transferncia, balanceamento de carga e qualidade de servio sobre aplicaes que tem
seu escopo de atuao bem restrito decises neste nvel. No seria possvel, por
exemplo, definir uma regra de fluxo que seja executada j na primeira camada de rede.
Seria necessrio fazer todo o desemcapsulamento do pacote para que s ento na
camada de aplicao se tome uma deciso sobre ele, alm do fator principal, que neste
caso a tomada de decises no centro da rede e no apenas nos hosts.
Este trabalho s foi possvel devido aos avanos da comunidade cientfica em
prol do desenvolvimento de ferramentas que auxiliem os testes e implantaes de novas
solues e ideias. O grupo Internet2 mantm alguns projetos nesta rea e apoiado por
diversas grandes companhias, como Facebook, Google, Microsoft, Verizon, Yahoo!,
Broadcom, Cisco, Dell, Ericsson, Extreme Networks, HP, IBM, Intel, as quais, em
conjunto formaram uma organizao sem fins lucrativos chamada ONF (Open Network
Foundation). Esta organizao dedicada a promover uma nova abordagem para a rea
de redes, marcada pela utilizao de Redes Definidas por Software (do ingls, Software
Defined Network). O OpenFlow protagoniza neste cenrio um papel importante.
Seguindo esta tendncia espera-se que grandes avanos sejam vistos na Internet
do Futuro.
Os trabalhos futuros propostos so direcionados a aplicar modificaes na
implementao dos testes de modo que se automatize o reconhecimento da rede,
identificando os clientes e servidores de forma menos engessada. Possibilitando desta
forma at a implantao deste sistema em ambientes reais.

Referncias
Nick McKeown; Tom Anderson; Hari Balakrishnan; Guru Parulkar; Larry Peterson;
Jennifer Rexford; Scott Shenker; Jonathan Turner. OpenFlow: enabling innovation
in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (March 2008), 69-

74. 2008.
Zhong Xu; Rong Huang; Bhuyan, L.N.; , "Load balancing of DNS-based distributed
Web server systems with page caching," Parallel and Distributed Systems, 2004.
ICPADS 2004. Proceedings. Tenth International Conference on , 587- 594, 2004.
Bob Lantz; Brandon Heller; Nick McKeown; A network in a laptop: rapid prototyping
for software-defined networks. In Proceedings of the Ninth ACM SIGCOMM
Workshop on Hot Topics in Networks (Hotnets '10). ACM, Article 19 , 6 pages, 2010.
Natasha Gude; Teemu Koponen; Justin Pettit; Ben Pfaff; Martin Casado; Nick
McKeown;Scott Shenker; NOX: towards an operating system for networks.
SIGCOMM Comput. Commun. Rev. 38, 3 (July 2008), 105-110, 2008.
Hao Yin; Xuening Liu; Geyong Min; Chuang Lin; , "Content delivery networks: a
bridge between emerging applications and future IP networks," Network, IEEE ,
vol.24,52-56,2010.