TCC1

Universidade de Braslia - UnB
Faculdade UnB Gama - FGA

Engenharia de Software
Projeto de um balanceador de carga de

servidores confivel para sistemas Linux
Autor: Matheus Souza Fonseca

Orientador: Prof. Dr. Luiz Augusto Fontes Laranjeira
Braslia, DF
2014
Matheus Souza Fonseca
Projeto de um balanceador de carga de servidores

confivel para sistemas Linux
Monografia submetida ao curso de graduao

em Engenharia de Software da Universidade
de Braslia, como requisito parcial para obteno do Ttulo de Bacharel em Engenharia
de Software.
Universidade de Braslia - UnB

Faculdade UnB Gama - FGA
Orientador: Prof. Dr. Luiz Augusto Fontes Laranjeira
Braslia, DF
2014
Matheus Souza Fonseca
Projeto de um balanceador de carga de servidores

confivel para sistemas Linux
Monografia submetida ao curso de graduao

em Engenharia de Software da Universidade
de Braslia, como requisito parcial para obteno do Ttulo de Bacharel em Engenharia
de Software.
Trabalho aprovado. Braslia, DF, 16 de Junho de 2014:
Prof. Dr. Luiz Augusto Fontes

Laranjeira
Orientador
Prof. Dra. Carla Silva Rocha Aguiar

Membro convidado 1
Prof. Dr. Andr Barros de Sales

Membro convidado 2
Braslia, DF
2014
Este trabalho dedicado a todas as pessoas que participaram diretamente

ou indiretamente da minha trajetria acadmica at o atual momento.
"No force o crescimento, elimine os fatores que o limitam."

Peter Sange.
Resumo
Com o surgimento da World Wide Web, h uma crescente e incessante demanda por servios fornecidos por sistemas de informao das mais variadas dimenses. Desde o uso
de redes sociais at o uso de sistemas de e-commerce, as infraestruturas de TI das organizaes precisam atender importantes requisitos para alcanar a satisfao do usurio,
dentre os requisitos se encontram o desempenho, escalabilidade, confiabilidade e disponibilidade. Para tentar suprir estes requisitos esto sendo continuamente desenvolvidas
solues em hardware e software, dentre elas existe o Balanceamento de carga de servidores, que constitui em um processo de distribuio uniforme de requisies a servios
utilizando um dispositivo baseado em rede, ou seja, uma tcnica de distribuio de trabalho a um cluster de servidores via um algoritmo de escalonamento. O presente trabalho
tem como ideia a criao do projeto de um produto, um balanceador de carga de servidores simplificado para computadores que fazem uso de sistemas operacionais baseados
em Linux, em integrao conjunta com o software que fornece um servio de failover, o
Application Manager. O core do sistema ser desenvolvido como um mdulo do kernel,
fazendo uso do Netfilter, um framework nativo do kernel do Linux para manipulao de
pacotes de rede.
Palavras-chaves: balanceamento de carga. algoritmo de escalonamento. linux. netfilter.
Abstract
With the emergence of the World Wide Web, there is a growing and constant demand
for services provided by information systems of all sizes. Since the use of social networks
to the use of e-commerce systems, the IT infrastructures of the organizations need to
meet important requirements to achieve user satisfaction, among the requirements are
performance, scalability, reliability and availability. To try to meet these requirements are
continually being developed hardware and software solutions, among them is the Load
balancing server, which is a process of uniform distribution of requests to services using
a network-based device, i.e., a technique of distribution of work to a cluster of servers via
a scheduling algorithm. This present work has the idea to create the design of a product,
a simplified server load balancer for computers that use Linux-based operating systems,
with joint integration with a software that provides a failover service, the Application
Manager. The core of the system will be developed as a kernel module, using Netfilter, a
native Linux kernel framework for handling network packets.
Key-words: load balancing. scheduling algorithm. linux. netfilter.
Lista de ilustraes
Figura 1 Cronograma do TCC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 2 Camadas de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3 Interao de modos de CPU e hardware . . . . . . . . . . . . . . . . . 30
Figura 4 Balanceador de carga de servidores . . . . . . . . . . . . . . . . . . . . 33
Figura 5 Configurao de um balanceador de carga . . . . . . . . . . . . . . . . 38
Figura 6 Retorno de trfego via NAT . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 7 Retorno de trfego via tunelamento IP . . . . . . . . . . . . . . . . . . 42
Figura 8 Retorno de trfego via DR . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 9 Cenrio de redundncia ativo-standby . . . . . . . . . . . . . . . . . . . 48
Figura 10 Processo de comunicao TCP . . . . . . . . . . . . . . . . . . . . . . 53
Figura 11 Viso lgica da soluo de balanceamento de carga . . . . . . . . . . . 57
Figura 12 Estrutura do Application Manager . . . . . . . . . . . . . . . . . . . . 61
Figura 13 Mquina de estados do SMA . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 14 Viso de implantao da soluo de balanceamento de carga . . . . . . 63
Figura 15 Projeto da rede de computadores da soluo . . . . . . . . . . . . . . . 68
Figura 16 Tipos de hook com possibilidade de registro . . . . . . . . . . . . . . . 80
Lista de tabelas
Tabela 1 Estatstica de uso de sistemas operacionais . . . . . . . . . . . . . . . . 29
Tabela 2 Comparao entre tcnicas de retorno de trfego . . . . . . . . . . . . 44
Tabela 3 Eventos para troca de estados do SMA . . . . . . . . . . . . . . . . . . 62
Lista de quadros
Quadro 1 Cdigo fonte C: Envio de um ICMP_ECHO . . . . . . . . . . . . . . 70
Quadro 2 Cdigo fonte C: Recebimento de um ICMP_ECHOREPLY . . . . . . 70
Quadro 3 Cdigo fonte Python: Envio de arquivo via SCP . . . . . . . . . . . . 72
Quadro 4 Cdigo fonte C: Chamadas IOCTL no slbcore . . . . . . . . . . . . . 74
Quadro 5 Cdigo fonte Python: Uso do IOCTL no slbd . . . . . . . . . . . . . . 75
Quadro 6 Cdigo fonte C: Structs para o slbcore . . . . . . . . . . . . . . . . . . 76
Quadro 7 Cdigo fonte C: Struct de cofigurao de um hook . . . . . . . . . . . 79
Quadro 8 Cdigo fonte C: Prottipo de funo para registrar um hook . . . . . . 79
Quadro 9 Cdigo fonte C: Exemplo de um mdulo netfilter simples . . . . . . . 82
Lista de abreviaturas e siglas

TCC
Trabalho de Concluso de Curso
ASICs
Application Specific Integrated Circuits
API
Application Programming Interface
OSI
Open Systems Interconnection
IP
Internet Protocol
VIP
Virtual Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
PDU
Protocol Data Unit
ISO
International Organization for Standardization
ICMP
Internet Control Message Protocol
GPL
GNU Public License
CPU
Central Processing Unit
RAM
Random Access Memory
DNS
Domain Name System
KISS
Keep It Simple, Stupid
NAT
Network address translation
HTTP
Hypertext Transfer Protocol
LAN
Local Area Network
CLI
Command Line Interface
IOCTL
Input/Output Control
LVS
Linux Virtual Server
Sumrio
1
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1
Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2
Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3
Objetivos especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4
Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5
Metodologia de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5.1
Cronograma do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Fundamentao terica . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1
Terminologia bsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2
Protocolos de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1
Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2
Pilha TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3
Sistemas Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1
Conceitos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2
Modos de CPU (kernel e usurio) . . . . . . . . . . . . . . . . . . . . . 30
2.3.3
Mdulos do kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.4
Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4
Balanceamento de carga de servidores . . . . . . . . . . . . . . . . . . . 32
2.4.1
Definio e tipos de balanceamento . . . . . . . . . . . . . . . . . . . . 32
2.4.2
Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.3
Benefcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Arquitetura de um balanceador de carga de servidores . . . . . . . . 37
3.1
Camada de rede de atuao (modelo OSI) . . . . . . . . . . . . . . . . . 38
3.2
Retorno de trfego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1
Retorno de trfego via NAT . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2
Retorno de trfego via tunelamento IP . . . . . . . . . . . . . . . . . . . 41
3.2.3
Retorno de trfego via DR . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.4
Comparao entre as tcnicas de retorno de trfego
3.3
Algoritmos de escalonamento . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4
Redundncia do servio . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Projeto arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1
Representao da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2
Tecnologias e tcnicas utilizadas . . . . . . . . . . . . . . . . . . . . . . 52
4.3
Viso lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
. . . . . . . . . . . 44
4.4
Viso de implantao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5
Restries de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5
5.1
Detalhes tcnicos da soluo . . . . . . . . . . . . . . . . . . . . . . 67

Configurao da rede de computadores . . . . . . . . . . . . . . . . . . 67
5.2
5.3
5.4
Monitoramento do cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Processo de failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Comunicao entre slbd e slbcore . . . . . . . . . . . . . . . . . . . . . 73
5.5
5.6
Tabela de servidores e tabela de conexes . . . . . . . . . . . . . . . . . 75

Persistncia de sesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.7
Interceptao e manipulao de pacotes . . . . . . . . . . . . . . . . . . 78
6
6.1
Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Apndices
APNDICE A Lista de comandos do amcli
89
. . . . . . . . . . . . 91
21
1 Introduo
A internet em conjunto com suas ferramentas de acesso (e.g. World Wide Web)
a mais poderosa ferramenta de comunicao do mundo, por intermdio dessa so diariamente realizadas desde simples conversas entre pessoas, at transaes financeiras de alto
valor. As mudanas na forma de comunicao que esta infraestrutura causou e causa at
hoje na vida das pessoas e suas relaes incalculvel. Todas a vantagem que esse meio
de comunicao oferece, implica no fato de que dia aps dia, existe um aumento de uso
dessa infraestrutura.
Como prova deste aumento de uso, vejamos a progresso do nmero de buscas feitas
na ferramenta de busca Google no perodo de seis anos (STATISTIC BRAIN, 2014). No
ano de 2007foram realizadas uma mdia de 1.200.000.000 (um bilho e duzentos milhes)
de buscas por dia, j no ano de 2013, o dado mais recente no perodo de realizao deste
presente trabalho, foram realizadas uma mdia de 5.922.000.000 (cinco bilhes, novecentas
e vinte e duas milhes) de buscas por dia. Um aumento aproximado de 493,5% nas buscas,
ou seja, um fluxo de requisies quase cinco vezes maior em um perodo 6 anos.
Esta situao se repetiu e se repete em vrios outros servios disponveis na web,
at mesmo internamente em empresas (com uma escala menor, obviamente). Isto motivou o desenvolvimento de diversas solues de sistemas distribudos para amenizar os
impactos causados por esta situao, uma dessas solues o balanceamento de cargas
em servidores.
1.1 Justificativa
Dados os fatos introduzidos anteriormente, este trabalho de concluso de curso
motivado a desenvolver uma soluo que contorne o aumento do uso de servios em uma
rede. Levando-se em considerao um servio que aumenta diariamente a sua taxa de
acessos, podem surgir diversos problemas, como os a seguir:
Diminuio de desempenho do servio;
Caso o servio esteja centralizado em um nico local (e.g. Servidor fsico), se houver
uma falha neste servidor todo o servio ficar indisponvel;
Se for optado pelo aumento dos recursos do servidor (e.g. memria RAM, processamento, interface de rede com maior largura de banda, etc), a situao pode ser
contornada temporariamente, mas se o aumento de requisies prosseguir, em algum
momento ser atingido o limite fsico da mquina, e o problema retornar.
22
Captulo 1. Introduo
O balanceamento de carga em servidores uma possvel soluo definitiva para

estes problemas. Atualmente existem diversas solues de balanceamento baseadas em
software e hardware, disponibilizadas de forma comercial ou at mesmo gratuitamente.
As solues comerciais so normalmente ASICs (Application Specific Integrated Circuits),
uma soluo conjunta de software e hardware especializado para o balanceamento de
carga, possuindo um desempenho melhor e um alto custo, exemplos de solues so o
Cisco CSS1 , o Alteon NG Load Balancer2 e o F5 LTM3 . J em relao as solues baseadas somente em software, que operam sobre sistemas operacionais padres (e.g. Debian
Linux4 , Red Hat ES5 , Windows Server6 , etc), existem verses pagas, gratuitas e at livres,
exemplos de solues so o LVS (Linux Virtual Server) 7 e o HAProxy8 (softwares livres).
O trabalho fica justificado pelo seu fim didtico e por este propor uma soluo
mais minimalstica em relao as citadas anteriormente.
1.2 Objetivo geral

O presente trabalho tem o objetivo de definir o projeto de um sistema de balanceamento de carga de servidores confivel, sendo a sua plataforma de execuo sistemas
operacionais baseados em Linux.
1.3 Objetivos especficos

Levantar material bibliogrfico para suporte a toda a pesquisa e desenvolvimento
relacionado a este trabalho;
Desenvolver a arquitetura geral de uma soluo de balanceamento de carga, definindo as tecnologias a serem utilizadas, como: Linguagem de programao, plataforma de execuo, viso geral dos componentes (APIs, bibliotecas, etc), camada
de rede de atuao, tipo de retorno de trfego, etc;
Desenvolver o projeto detalhado da soluo de balanceamento de carga, contendo as
principais decises de tcnicas a serem utilizadas: Forma de interceptao de pacotes,
forma de comunicao entre os componentes do sistema, forma de configurao do
sistema, etc.
1
2
3
4
5
6
7
8
<http://www.cisco.com/go/css11500/>
<http://www.radware.com/Products/Alteon/>
<https://f5.com/products/modules/local-traffic-manager>
<https://www.debian.org/>
<http://br.redhat.com/products/enterprise-linux/>
<http://www.microsoft.com/pt-br/server-cloud/products/windows-server-2012-r2/>
<http://www.linuxvirtualserver.org/>
<http://haproxy.1wt.eu/>
1.4. Estrutura do trabalho
23
Realizar projeto de integrao do software a ser desenvolvido (balanceador de carga)

e do software Application Manager.
1.4 Estrutura do trabalho

A estruturao do trabalho est de acordo com o sumrio deste documento. No
captulo 1 feita uma introduo ao tema, oferecendo a devida motivao para a realizao da pesquisa, juntamente com informaes adicionais sobre o trabalho. No captulo
2 so citados vrios conceitos que oferecem toda a base para a realizao do trabalho, ou
seja, uma fundamentao terica necessria. O captulo 3 tambm oferece fundamentos
tericos, mas so fundamentos especficos sobre balanceamento de carga. No captulo 4
fornecida uma viso alto nvel (generalista) da soluo que est sendo proposta, demonstrando os componentes da arquitetura do balanceador de cargas. J o captulo 5
responsvel por fornecer detalhes tcnicos sobre como podero ser implementadas determinadas funcionalidades do sistema. No captulo 6 ser feita a concluso do trabalho,
fazendo um resumo a tudo o que feito pesquisado e projetado, e fornecendo uma possvel
estruturao do Trabalho de Concluso de Curso 2, que ser realizado em sequncia.
1.5 Metodologia de trabalho

Para a realizao deste trabalho a coleta de dados foi feita atravs de livros, artigos
e documentaes de software, todos no segmento de Redes de computadores, Sistemas
distribudos e kernel do Linux.
O presente Trabalho de Concluso de Curso tem como objetivo o projeto de um
sistema, e como ao futura no Trabalho de Concluso de Curso 2 este projeto servir
como base para a implementao do sistema.
1.5.1 Cronograma do trabalho
24
Captulo 1. Introduo
Figura 1 Cronograma do TCC1
25
2 Fundamentao terica
Este captulo ter a funo de demonstrar a pesquisa realizada acerca dos diversos
temas que tangem este trabalho, fornecendo um referencial terico para descrio e justificativa do projeto da soluo. Somente assuntos com maior recorrncia sero trabalhados
aqui, caso um determinado assunto pertinente no seja explicado neste captulo, significa
que ele ser abordado diretamente nos posteriores.
2.1 Terminologia bsica

Neste trabalho surgiro diversos termos que sero recorrentemente citados e devem
ter significados esclarecidos para no haver interpretaes incorretas. Ressalta-se que estes
termos possuem estes significados no domnio deste trabalho (balanceamento de carga),
em outros domnios eles podem ter outros significados. A seguir os termos:
Servidor real: Um servidor real um dispositivo conectado em rede que possui servios
em execuo, estes servios tem a carga compartilhada entre os outros servidores
(BOURKE, 2001, p. 15).
Cluster de servidores: Um cluster de servidores (i.e. fazenda de servidores) um aglomerado de servidores independentes, trabalhando em conjunto como um sistema
nico. Neste trabalho o cluster de servidores ser a representao de todos os servidores reais, mas diferentemente de uma soluo de cluster tpica, os servidores no
se comunicaro entre si.
VIP: Um VIP (Virtual IP) o endereo IP do servidor de balanceamento de carga que
acessvel fora da rede (normalmente um IP pblico), fazendo a representao de
todo o cluster de servidores, que so os hosts para quem ele despacha as requisies.
Failover: Failover o processo de troca de um servidor primrio para um servidor secundrio/redundante quando ocorre um colapso do sistema primrio (JAYASWAL,
2006, p. 309). Para determinar quando ocorre o colapso, pode ser utilizada a tcnica
de heartbeat.
Kernel: O kernel o principal programa de computador que compe um sistema operacional. Ele possui funcionalidades essenciais para o funcionamento da mquina, como
a interao com o hardware da mquina e o provimento de ambiente de execuo
para outros programas (BOVET; CESATI, 2000, p. 12).
26
Captulo 2. Fundamentao terica
Camada de rede: Uma camada de rede um componente de uma arquitetura de um

software de rede. Em uma pilha de protocolos, os protocolos so agrupados por
camadas, onde cada camada tem o objetivo de oferecer soluo a um subproblema
do todo.
Pacote de rede: Em sentido estrito, pacote representa o conjunto de informaes trocadas pelas camadas de rede (protocolo IP), mas este termo tambm amplamente
utilizado para representar qualquer PDU (Protocol Data Unit) de qualquer camada
de rede, seja ele um quadro ethernet, um pacote IP ou um segmento TCP. Neste
trabalho um pacote ter este significado mais amplo.
2.2 Protocolos de rede

Logo aps o comeo da pesquisa e desenvolvimento em redes de computadores
, foram desenvolvidas solues de software de rede para reduo da complexidade de
comunicao do sistema. Comumente os software de rede no so um grande amontoado
de cdigo que efetua toda a operao de comunicao entre mquinas. Como uma boa
1
deciso arquitetural o software que realiza essa tarefa foi componentizado, de forma que os
problemas que esse amontoado de cdigo resolveria, fosse dividido de acordo com suas
similaridades e cada componente ficaria responsvel por resolver um pequeno conjunto de
problemas (princpio de Dividir para conquistar2 ).
Estes componentes foram organizados de uma forma hierrquica, formando uma
pilha de camadas, umas sobre as outras. Cada camada tem a funo de fornecer determinados servios as camadas superiores, e uma camada X de uma mquina A tem a
funo de se comunicar com a mesma camada X de uma mquina B (TANENBAUM,
2003, p. 37). Seguindo o fluxo dessa pilha de camadas a comunicao seria estabelecida,
conforme a Figura 2.
A forma em que essas camadas se comunicam determinado pelo protocolo de
rede utilizado, que uma implementao da soluo dos problemas associados a camada,
alinhado a um conjunto de regras e procedimentos a serem respeitados para emisso e
recepo de mensagens.
2.2.1 Modelo OSI

O primeiro e mais conceituado modelo de camadas o OSI (Open System Interconnection), um modelo de referncia publicado pela ISO3 (International Organization for
Standardization) que determina sete camadas e seus objetivos (seguindo a lgica proposta
1
2
3
Ocorreu em meados da dcada de 1960, resultando na rede ARPANET.

<http://pt.wikipedia.org/wiki/Divis%C3%A3o_e_conquista>
Organizao internacional de padronizao: <http://www.iso.org/iso/>
27
2.2. Protocolos de rede
Figura 2 Camadas de rede

na seo anterior). Este somente um modelo conceitual e no um guia de implementao, onde futuras implementaes reais se basearam. A seguir uma breve descrio de
cada camada de acordo com (TANENBAUM, 2003, p. 45-47):
1. Fsica: Trata da transmisso de bits (1s e 0s) por um meio fsico de comunicao
(e.g. cabo coaxicial, cabo de par tranado, cabo de fibra tica, etc);
2. Enlace de dados: Transformar a transmisso de dados em algo mais confivel,
reduzindo os erros de transmisso e agrupando as informaes em pacotes (nesta
camada as PDUs so chamadas de quadro);
3. Rede: Roteamento dos pacotes (pacotes IP) at o seu destino, passando nas subredes onde eles trafegam;
4. Transporte: Fornecer um canal ponto a ponto livre de erros entre os dois hosts
que se comunicam, diferente da camada de enlace esta normalmente tem a funo
de comunicar os hosts de origem e destino, enquanto as camadas inferiores comunicam os hosts com seus vizinhos imediatos, assim a origem e destino podem estar
separados por vrios roteadores;
5. Sesso: Estabelece um controle do dilogo que est ocorrendo entre os dois hosts;
6. Apresentao: Controle da sintaxe e semntica do dilogo, podendo controlar as
diferentes formas em que diferentes arquiteturas computacionais organizam suas
estruturas de dados (e.g. Little endian e Big endian);
7. Aplicao: composta por protocolos para atendimento de demandas do usurio,
que podem ser desde a transferncia de e-mails at a um transmisso multimdia.
28
2.2.2 Pilha TCP/IP

Diferentemente do modelo de referncia OSI, que foi definido inicialmente por um
grupo de trabalho da ISO antes mesmo de qualquer pilha de protocolos serem implementadas, o modelo de referncia oficial da internet foi formalizado aps os protocolos forem
projetados, implementados e testados (COMER, 2013, p. 53). Este modelo oficial chamado de TCP/IP 4 , ele possui somente cinco camadas e cada uma contm n protocolos
associados.
Fazendo uma relao com o modelo OSI, a pilha TCP/IP possui as camadas de
Sesso e Apresentao incorporadas na camada de Aplicao, o restante continuando da
mesma forma, com os mesmos objetivos (fruto da influencia do modelo OSI).
A pilha TCP/IP atualmente implementada por padro em todos os sistemas operacionais modernos, e como um padro utilizado na internet geralmente no ocorrem
problemas de comunicao em mquinas com diferentes sistemas operacionais ou arquiteturas computacionais. A seguir uma breve lista de alguns dos protocolos mais famosos
da pilha TCP/IP, agrupados por camada (WIKIPEDIA, 2014):
1. Fsica: Bluetooth, RS-232, USB (Universal Serial Bus), etc;
2. Enlace de dados: Ethernet, PPP (Point to Point Protocol), Frame Relay, etc;
3. Rede: IP (Internet Protocol), ARP (Address Resolution Protocol), ICMP (Internet
Control Message Protocol), IGMP (Internet Group Management Protocol) etc;
4. Transporte: TCP (Transmission Control Protocol), UDP(User Datagram Protocol), etc;
5. Aplicao: HTTP(Hypertext Transfer Protocol), FTP(File Transfer Protocol), DNS(Domain
Name System), etc.
2.3 Sistemas Linux

O Linux um kernel (ncleo) de sistema operacional baseado em Unix, no sendo
considerado um sistema operacional completo por no incluir por padro outras ferramentas utilitrias necessrias para ser categorizado como tal. Dentro da rvore genealgica
de sistemas operacionais baseados em Unix5 , o Linux hoje obtm a posio de segundo
mais utilizado no mundo at o presente momento, perdendo somente para sistemas Mac
OS X da Apple6 . A Tabela 1 demonstra os dados mensais de deste ano de 2014.
4
5
Faz referncia aos seus dois protocolos mais famosos, TCP e IP.
Imagem da rvore genealgica: <http://www.computerworld.com/common/images/site/features/
2009/062009/unix_chart_775.jpg>
<http://www.apple.com/br/osx/>
29
2.3. Sistemas Linux
Tabela 1 Estatstica de uso de sistemas operacionais

2014
Win8
Win7
Vista
NT
WinXP
Linux
Mac
Mobile
Abril
Maro
Fevereiro
Janeiro
15.8%
15.0%
14.2%
13.4%
55.4%
55.1%
55.0%
55.3%
1.2%
1.3%
1.4%
1.5%
0.2%
0.2%
0.3%
0.3%
8.0%
9.4%
10.1%
11.0%
5.0%
4.9%
5.0%
4.9%
10.3%
9.9%
10.0%
9.6%
4.0%
4.0%
4.0%
4.0%
Fonte: W3SCHOOLS (2014).
Estes resultados englobam sistemas operacionais de todos os tipos, mas se a pesquisa fosse restrita a sistemas operacionais para uso em servidores, os que fazem uso do
kernel Linux disparadamente ocupariam o primeiro lugar. Grande parte desse sucesso
devido a enorme comunidade que oferece desenvolvimento contnuo e grande suporte as
verses do Linux, resultante da filosofia de software livre adotada.
2.3.1 Conceitos bsicos

O Linux um kernel de sistema operacional no-proprietrio sob licensa GPL
(GNU Public License), o que o caracteriza como um software livre. Um software livre se baseia em quatro fundamentos de liberdade principais (FREE SOFTWARE FOUNDATION,
2014):
A liberdade de usar um software para qualquer propsito,
A liberdade de modificar um software para necessidades prprias,
A liberdade de compartilhar um software com seus amigos e vizinhos, e
A liberdade de compartilhar as mudanas que voc fez no software.
Quando um software atinge esse grau liberdade, ele considerado um software
livre. O Linux atende todas estas liberdades, e como resultado disso ele possui uma vasta
comunidade de desenvolvedores experientes, que alm de efetuarem as mais diversas correes e melhorias em seu cdigo, conseguiram portar este para ser utilizado em diferentes
arquiteturas computacionais (e.g. Intel x86, Intel x86-64, AMD 64, ARM, PowerPC, entre
outras), sendo possvel fazer uso do sistema operacional em servidores de grande porte,
computadores pessoais, tablets, celulares e at em uma geladeira!
Todas as caractersticas de software livre citadas anteriormente so extremamente
benficas para os campos de ensino, pesquisa e desenvolvimento tambm. Afinal, as liberdades possibilitam a investigao do cdigo fonte, e maior liberdade de acesso a funcionalidades do sistema, o que facilita o desenvolvimento uma nova soluo (o objetivo deste
trabalho).
30
Como j foi dito anteriormente, o Linux um kernel, sendo o principal programa de

um sistema operacional e ficando responsvel por: Gerenciamento de recursos (memria,
processador, disco e perifricos), escalonamento de processos, provimento de ambiente de
execuo para aplicaes, etc. Outras funcionalidades esto implementadas em aplicativos
utilitrios, como: Editor de texto, interpretador de comandos, compilador, ambiente de
desktop, etc. O kernel Linux e os aplicativos utilitrios em conjunto formam um sistema
operacional por completo, onde normalmente comunidades de desenvolvedoras os customizam e os distribuem com um determinado codinome, as chamadas distribuies Linux
(e.g. Ubuntu, Debian, Fedora, Arch Linux, etc).
2.3.2 Modos de CPU (kernel e usurio)

De acordo com Atwood (2008), o kernel de um sistema trabalha em um modo
especial chamado comumente de modo kernel, este oferece uma srie de privilgios em
relao ao acesso direto de funcionalidades do hardware da mquina (e.g. executar qualquer instruo da CPU e referenciar qualquer rea da memria RAM). Se todo e qualquer
processo pudesse ter acesso a essas funcionalidades, existiram diversos problemas de segurana por conta de programas mal intencionados. Por este motivo os outros aplicativos
(e.g. editores de texto, compiladores, etc) atuam em um modo diferente, mais restritivo,
chamado comumente de modo usurio.
Essa separao garantida pela prpria CPU, que capaz de distinguir qual modo
est sendo executado o processo corrente e ento restringir determinadas instrues. Mas
existem determinados momentos, onde alguns processos comuns precisam ter acesso ao
hardware, como por exemplo, acesso a um arquivo que est gravado em disco. Para ter
tal recurso o processo precisa fazer uma chamada ao sistema (i.e. system call), que um
pedido feito ao kernel do sistema, para que esse acesse o hardware e depois entregue o
pedido de volta ao processo (novamente, uma questo de segurana). A Figura 3 ilustra
essa situao.
Figura 3 Interao de modos de CPU e hardware
31
2.3. Sistemas Linux
Existem outras caractersticas de modos de CPU especficas de sistemas Linux, por

exemplo, em modo kernel o processo tem a maior prioridade de requisio de memria
dinmica, j em modo usurio a requisio de memria considerada no-urgente. Outra
questo, em modo kernel as funcionalidades so consideradas livres de erro (o kernel confia
em si prprio), no sendo necessrios mecanismos avanados de preveno de erros de
programao, j em modo usurio estes erros so esperados e tratados, por isso quando um
processo em modo usurio falha, dificilmente ir travar todo o sistema (BOVET; CESATI,
2000, p. 183).
Estas caractersticas enfatizam duas coisas, o modo kernel preza por desempenho,
j que tem acesso mais direto ao hardware alinhado de maior prioridade de acesso a memria. O modo usurio preza por estabilidade, j que o processo neste modo supervisionado
pelo kernel, possuindo uma maior proteo contra erros.
2.3.3 Mdulos do kernel

O Linux contempla uma srie de funcionalidades como as j descritas anteriormente, mas e quando surge a necessidade de uma funcionalidade que no foi desenvolvida
no seu cdigo fonte? Por exemplo, estabelecer a comunicao com um novo hardware
desenvolvido. Isso possvel graas aos mdulos do kernel. A seguir uma descrio de
acordo com Salzman, Burian e Pomerantz (2007, p. 2):
Mdulos so pedaos de cdigo que so carregados e descarregados no
kernel sob demanda. Eles estendem a funcionalidade do kernel sem a
necessidade de reiniciar o sistema [...] Sem mdulos, ns precisaramos
de criar kernels monolticos7 e adicionar a funcionalidade diretamente
na imagem do kernel. Ter grandes kernels ainda tem a desvantagem de
nos exigir a reconstruo e reiniciao do kernel toda vez que queremos
novas funcionalidades.
A ideia de mdulos vieram de uma estratgia utilizada em microkernels, que so

kernels com somente as principais funcionalidades do sistema, as outras deveriam ser acopladas ao kernel sempre que necessrio, oferecendo uma maior flexibilidade arquitetural
do sistema. Um tipo de mdulo pode ser um device driver 8, um cdigo que oferece uma
interface ao sistema operacional para interao com um hardware. Exemplos de mdulos
que no so device drivers podem ser a implementao de um escalonador de processos
customizado, um manipulador de pacotes de rede, etc.
Os mdulos sempre atuam no modo kernel de CPU, pois quando so carregados
dinamicamente eles so acoplados ao kernel do sistema. O que trs a vantagem de maior
desempenho e acesso a funcionalidades restritas, mas trs a desvantagem de perda de
7
8
<http://pt.wikipedia.org/wiki/N%C3%BAcleo_monol%C3%ADtico>
Caso ele seja inserido estaticamente a imagem do kernel, ele no um mdulo.
32
estabilidade e maior complexidade de desenvolvimento (como foi dito anteriormente na

subseo 2.3.1).
2.3.4 Netfilter
Especificamente para mdulos do kernel Linux que trabalham com aspectos de
rede, existe uma srie de componentes que podem ser utilizados para ter acesso a determinadas funcionalidades, como interceptao de pacotes. Este conjunto de componentes fazem parte do framework chamado de Netfilter, que composto de quatro partes
(RUSSEL; WELTE, 2002):
Hooks: So pontos pr-definidos na travessia de pacotes na pilha de protocolos TCP/IP
de uma mquina. Toda vez que chegado neste ponto pr-definido, o hook chamar
o que estiver registrado nele;
Registro de hooks: Qualquer mdulo do kernel pode registrar um hook com uma funo de callback prpria9 , ou seja, quando um pacote chegar a uma determinada
camada de rede, a funo de callback implementada e registrada no hook ir receber
o pacote da camada e vrias operaes podero ser feitas nele (aceitar, descartar,
esquecer, empilhar e tambm efetuar alteraes);
Empilhamento de pacotes: Quando em uma funo de callback, um pacote empilhado, ele pode ser acessado por aplicaes no modo usurio de CPU, de forma
totalmente assncrona;
Documentao: Todas estas funcionalidades possuem uma boa documentao, alm de
comentrios no prprio cdigo do componente.
2.4 Balanceamento de carga de servidores

Esta seo pode ser considerada uma das mais importantes de todo o trabalho,
pois um dos objetivos especficos citados anteriormente na seo 1.3 era o de levantamento
bibliogrfico para suporte ao trabalho, e como este trabalho ir projetar uma soluo de
balanceamento de carga de servidores, nada mais importante do que possuir uma definio
terica bsica sobre o assunto.
2.4.1 Definio e tipos de balanceamento

De acordo com Karimi et al. (2009):
9
Funes de calback so passadas como argumento de uma outra funo, para serem futuramente
utilizadas.
2.4. Balanceamento de carga de servidores
33
Balanceamento de carga a tcnica de diviso de trabalho entre dois

ou mais computadores, links de rede, CPUs, discos rgidos, ou outros
recursos, a fim de obter a melhor utilizao dos recursos, vazo (i.e.
throughput) ou tempo de resposta.
Como a referncia citou, o termo recurso pode ter diferentes representaes, onde
a definio de balanceamento de carga ainda seria passvel de aplicao, por exemplo,
a distribuio de carga entre trabalhadores de uma empresa. Mas as formas que estes
balanceamentos so feitos contm suas peculiaridades, a seguir diferenas de duas das
principais:
Balanceamento de carga de CPU: Em um sistema com multiprocessamento, as CPUs
podem estar em uma mesma mquina ou distribudas, e o intuito do balanceamento
de carga distribuir um trabalho, mas este trabalho divido em partes, onde os
processados atuam paralelamente (e.g. As instrues de um programa so divididas
entre as CPUs).
Balanceamento de carga de servidores: Em uma arquitetura web podem existir diversos servidores que rodam o mesmo website, a carga de trabalho pode ser distribuda entre eles, mas neste caso os servidores no atuam obrigatoriamente em
paralelo, provavelmente eles nem se comunicam ou sabem da existncia um do outro. Neste caso cada pedido ao website distribudo entre os servidores, mas um
mesmo pedido no ser processado em dois ou mais servidores. A Figura 4 representa
este caso.
Figura 4 Balanceador de carga de servidores
34
Na sua forma mais simples, o processo de balanceamento de carga de servidores

ocorre na Figura 4 o seguinte:
1. Um cliente Y requisita um servio (e.g. HTTP, SMTP, Telnet, FTP, etc) a um
determinado endereo IP (X.X.X.X) e porta;
2. O balanceador de carga que responde pelo VIP X.X.X.X recebe a requisio, determina por meio de um algoritmo qual ser o servidor real a responder pelo servio,
ento altera o IP de destino para corresponder com o servidor real selecionado;
3. O servidor real recebe a requisio, efetua o processamento e envia a resposta para
o endereo do remetente da requisio (cliente Y) por sua rota padro;
4. O balanceador de carga o gateway da rota padro, ento ele recebe de volta a resposta do servidor real, mas para ela no ser descartada pelo cliente X o balanceador
altera agora o IP do remetente, colocando novamente o VIP X.X.X.X.
Esta soluo citada utiliza a tcnica de retorno de trfego via NAT, mas existem
outras forma de efetuar o balanceamento que sero citadas posteriormente no decorrer do
trabalho.
2.4.2 Histrico
Com o aumento do trfego na internet foi necessrio um determinado investimento
na estrutura das redes e das empresas que disponibilizavam servios. Inicialmente como
primeira medida para aumentar o desempenho dos servidores, foi utilizada a abordagem
de scale-up, que consiste em aumentar os recursos computacionais de uma mquina (CPU,
memria RAM, velocidade do disco rgido, etc). Durante algum tempo essa abordagem
atendeu algumas necessidades, mas rapidamente foram atingidos limites de melhoria (os
recursos computacionais para uma mquinas so finitos), alm disso, os recursos com
maior capacidade tinham altos preos, e ao final de tudo as mquinas ainda corriam o
risco de falhar em algum momento e deixar seus servios indisponveis.
Outra abordagem que foi iniciada para se adaptar ao aumento do trfego foi a
de scale-out, onde ao invs de aumentar os recursos de uma nica mquina, aumentado o nmero de mquinas para trabalhar em conjunto de forma distribuda. De acordo
com (SHARMA; SINGH; SHARMA, 2008), um sistema computacionalmente distribudo
prov compartilhamento de recursos como uma das suas maiores vantagens, o que prov
melhor performance e confiabilidade do que qualquer outro sistema tradicional nas mesmas condies.
Antes dos balanceadores de carga virarem um produto real, os administradores de
sistema faziam uso da tcnica baseada em DNS round-robin para atingir resultados simi-
2.4. Balanceamento de carga de servidores
35
lares. Um DNS tradicionalmente faz associao de um domnio (e.g. www.example.com) a

um IP (e.g. 187.10.10.1), mas os servidores de DNS tambm oferecem suporte a associao
de mais de um IP a um domnio, o que possibilita que cada requisio ao domnio seja
distribuda entre os n servidores reais associados.Para escolha de qual ser o servidor que
receber a requisio, utilizado o algoritmo round-robin (ser discutido mais a frente)
para escolha. Mas esta soluo contm algumas desvantagens as solues de balanceamento de carga tradicionais, como suporte a um nico algoritmo de deciso e inexistncia
de monitoramento dos servidores, onde caso ocorra o colapso de um desses servidores, o
DNS no far nada para contornar (BOURKE, 2001, p. 5-6).
2.4.3 Benefcios
Com o surgimento das solues de balanceadores de carga baseados em servidores
(operam sobre mquinas servidoras com sistemas operacionais padro) foram alcanados diversos benefcios, vrios deles j foram citados diretamente ou indiretamente neste
trabalho. A seguir uma lista dos principais de acordo com Bourke (2001, p. 8):
Escalabilidade: Em uma infraestrutura com balanceamento de carga, existe um bom
nvel de escalabilidade dos servios, pois para aumentar o seu poder necessrio somente adicionar mais servidores reais. Tambm facilitada a remoo de servidores
com defeito, ou a desativao e ativao de servidores de acordo com a demanda.
Tudo com transparncia para os clientes.
Desempenho: So alcanados altos nveis de performance a um custo mais baixo do
que se fossem comprados computadores com recursos computacionais mais potentes. Dependendo da eficincia do algoritmo utilizado para deciso de despacho das
requisies, onde sero escolhidos os que estiverem menos ocupados, melhor ser o
desempenho.
Disponibilidade e confiabilidade: Caso um dos servidores falhe, o balanceador de
carga capaz de detectar e redirecionar o fluxo para outros, sem que o servio
como um todo fique indisponvel. Outro aspecto importante que o balanceador de
carga no deve ser um gargalo para o servio (caso ele seja o n a falhar), ento
necessrio aplicar alguma redundncia no servio de balanceamento, possuindo um
servidor de backup adicionado de um processo de failover integrado, aumentando a
confiabilidade do sistema.
37
3 Arquitetura de um balanceador de carga de

servidores
A partir das definies bsicas abordadas anteriormente sobre os balanceadores de
carga de servidores, possvel detalhar melhor os seus componentes, mostrando de fato
como eles atuam nas redes de computadores modernas e demonstrando quais so as suas
possibilidades reais de funcionamento. As decises de quais so as melhores estratgias e
a forma de organizao dos componentes de uma soluo, determina qual a arquitetura
da mesma.
Em um projeto real de um balanceador de cargas devem ser tomadas precaues
para que os objetivos almejados sejam alcanados, ou o pior pode acontecer, o que j
no era o ideal pode se tornar pior, devido ao aumento da complexidade do sistema sem
evidncias de melhoria. De acordo com (BOURKE, 2001, p. 41), existem trs aspectos
que devem ser procurados em uma soluo, e outros trs aspectos que devem ser evitados
em uma soluo: Simplicidade ao invs de complexidade, funcionalidade ao invs de desperdcio e elegncia ao invs de irrelevncia. Todas elas remetem a um princpio conhecido
como KISS (Keep It Simple, Stupid)1 , ou seja, existiro diversas solues que resolvem o
problema de balanceamento de carga, mas cabe ao arquiteto que est projetando a soluo
escolher a que atenda da forma mais simples e direta.
Na seo 2.4.2 j foi citada a existncia de balanceadores de carga DNS-based, que
apesar de ser uma forma de configurao antiga ainda utilizada. Bourke (2001, p. 43)
cita outras duas formas de configurao que so mais utilizadas atualmente, uma delas
a Flat-based, que uma forma simples e eficiente, onde tanto o balanceador de carga
quanto o cluster de servidores se encontram em uma mesma sub-rede (e.g. 192.168.0.0/24).
Outra forma mais complexa, mas com possibilidade de emprego de melhores tcnicas de
segurana a NAT-based, onde o balanceador de carga se encontra em uma sub-rede
pblica (e.g. 192.168.0.0/24) com acesso a internet, mas o cluster de servidores se encontra
em uma sub-rede privada (e.g. 10.0.0.0/24). A Figura 5 ilustra esses casos de configurao
de forma simplificada (no cenrio ficaram omitidos roteadores, switches, etc).
Com isso os detalhes arquiteturais de um balanceador podem ser divididos em
quatro categorias principais:
1. De acordo com a camada de rede de atuao (segundo o modelo OSI);
2. De acordo com o retorno do trfego de rede;
1
Mantenha isso simples, estpido: <http://pt.wikipedia.org/wiki/Keep_It_Simple>
38
Captulo 3. Arquitetura de um balanceador de carga de servidores
Figura 5 Configurao de um balanceador de carga

(a) Configurao DNS-based, (b) Configurao Flat-based e (c) Configurao NAT-based
3. De acordo com a deciso de balanceamento das requisies;

4. De acordo com a forma de redundncia do servio.
3.1 Camada de rede de atuao (modelo OSI)

Uma importante deciso arquitetural na implementao ou implantao de um
balanceador de carga, decidir em qual camada de rede ele vai atuar, ficando definido
qual tipo de pacote ele ir balancear o trfego (e.g. Quadro ethernet, pacote IP, segmento
TCP, mensagem HTTP, etc).
Existe uma forma de balancear o trfego na camada 2, para isso utilizada a
tcnica de link agreggation que consiste unio de dois ou mais links de rede, simulando
3.2. Retorno de trfego
39
um nico link lgico de alta velocidade e redundncia. Tambm pode ser realizado na
camada 3, onde os pacotes IP em um dispositivo de rede so redistribudos seguindo
algum algoritmo, o problema que via camada 3 s so conhecidos os possveis hosts
alvos, no tendo conhecimento da aplicao alvo (s seria acessvel via a porta do servio).
Normalmente os equipamentos como switches e roteadores operam at a camada 3, sendo
possvel acessar cabealhos de quadros ethernet e pacotes IP.
Natrio (2011) cita que as camadas de rede mais utilizadas so a 4 e a 7. O balanceamento de carga na camada 4 um mtodo mais simplista do que na camada 7, consiste
na redistribuio de requisies na camada de transporte, fazendo uso normalmente dos
protocolos TCP ou UDP. A sua simplicidade est ligada ao balanceador no fazer anlise do contedo (i.e payload) dos segmentos TCP ou UDP, somente tendo a funo de
repassar a informao, resultando em um maior desempenho. J na camada 7 feito um
extenso uso de anlise de informaes que esto sendo trefegadas, sendo capaz de analisar
a URL (Uniform Resource Locator) de um pedido, os cookies 2 que esto sendo trefegados,
o tipo de dado que foi requisitado (via mime-type 3 ). Em cima dessas informaes podem
ser tomadas decises mais inteligentes, fazendo por exemplo uma separao dos servidores
da infraestrutura de acordo com os seus dados, um grupo especializado em informaes
estticas (e.g. pginas HTML estticas, imagens e vdeos) e outro grupo especializado em
informaes dinmicas (e.g. scripts PHP), melhorando a organizao da infraestrutura.
Um contra deste tipo de abordagem baseado em contedo que o balanceador fica preso
a determinados tipos de aplicao, isso significa que se ele faz
3.2 Retorno de trfego

Acerca da forma de retorno do trfego dos servidores reais que esto atrs do
balanceador, sero abordados aqui trs estratgias que so parcialmente descritas por
Bourke (2001, p. 44-45), mas principalmente baseadas nas tcnicas de retorno de trfego do
LVS, descritas por Zhang (2000). As tcnicas so via NAT (Network Adress Translation),
via tunelamento IP e via DR (Direct Routing).
3.2.1 Retorno de trfego via NAT

Este a tcnica de retorno de trfego mais simples das trs, mas por conta da
sua simplicidade existe uma considervel perda de desempenho se comparado as outras
tcnicas. Devido ao alcance de endereos IP no IPv4 e tambm por requisitos de segurana,
existem um conjunto de IPs reservados para uso interno em organizaes, chamados de
IP falsos ou IP privados. Isso impossibilita que este endereo seja utilizado publicamente
2
3
<http://en.wikipedia.org/wiki/HTTP_cookie>
<http://en.wikipedia.org/wiki/Internet_media_type>
40
na internet, mas possibilita que o endereo seja reutilizado por outros hosts em subredes internas de outras organizaes, quantas vezes forem necessrias (dependendo da
arquitetura da rede, at na mesma organizao). Mas para estes hosts com IP privados
conseguirem se comunicar com a internet, deve ser utilizada a tcnica conhecida como
NAT, onde o IP privado ser representado pelo IP pblico do gateway que est na sada
padro da rede, sofrendo um processo de traduo sempre que for necessrio.
Figura 6 Retorno de trfego via NAT

Fonte: Zhang (2000). Adaptado pelo autor.
A Figura 6 Ilustra o retorno de trfego via NAT. A seguir uma explicao da

tcnica seguindo a numerao dos passos na Figura 6:
1. Uma requisio realizada por um cliente da internet chega na rede;
2. O balanceador de cargas recebe a requisio, escolhe qual ser o servidor que ir
process-la e ento reescreve o endereo de destinatrio do pacote IP, substituindo
pelo IP privado do servidor real escolhido;
3. A requisio chega a um servidor real, ele a processa e manda a resposta para o
balanceador de volta, j que ele rota padro e o endereo do cliente est na internet;
4. O balanceador recebe o pacote de resposta, ento ele novamente altera o pacote,
inserindo o seu IP como remetente para que o cliente no o descarte;
41
5. O pacote segue de volta ao cliente da requisio.

Essa mesma estratgia pode ser utilizada tambm na camada de transportes, a
diferena principal que as portas de remetente e destinatrio tambm deveriam ser alteradas, como feito no LVS via PAT (Port Address Translantion). Um problema associado
a essa tcnica que o balanceador um potencial gargalo para o sistema, pois ele atua
tanto como porta de entrada da rede como porta de sada, podendo ficar sobrecarregado
de funes. As prximas tcnicas diminuem um pouco essa sobrecarga pelo balanceador se tornar somente porta de entrada da rede, mas em compensao elas aumentam a
complexidade do sistema pois definem restries a rede e/ou ao cluster de servidores.
3.2.2 Retorno de trfego via tunelamento IP

Tunelamento IP uma tcnica que, de forma resumida, encapsula um pacote IP
dentro de outro pacote IP e o repassa para outro host process-lo (ZHANG, 2000). Para
ter suporte a este tipo de tcnica o balanceador de carga e os servidores reais devem ter
suporte ao protocolo de tunelamento IP, alm disso, deve existir uma interface de rede
virtual especfica para tunelamento, e ela deve estar configurada de modo que se estabelea um tnel entre o balanceador de carga com o VIP e os servidores reais. Normalmente
so utilizados dois protocolos de tunelamento IP em conjunto, o L2TP (Layer 2 Tunneling Protocol) na camada 2 em conjunto com o IPsec (Internet Protocol Security) na
camada 3, opes amplamente utilizadas em VPNs (Virtual Private Networks). A Figura
7 demonstra o uso da tcnica.
Observando a Figura 7 vemos algumas diferenas entre a tcnica usando NAT.
At o momento da chegada da requisio no balanceador tudo ocorre da mesma forma,
a escolha do servidor real que ir processar tambm ocorre igualmente, mas no momento
em que deveria ser feita a reescrita do pacote o que ocorre algo diferente. O balanceador
fazendo uso do seu protocolo de tunelamento, insere o pacote IP dentro de um outro
pacote, ento sendo possvel envi-lo ao servidor escolhido via o tnel (anteriormente
configurado entre o balanceador e os servidores reais). No momento em que o servidor
escolhido recebe o pacote, faz uso do seu protocolo de tunelamento para desencapsular o
pacote IP e ento pode processar a requisio normalmente. A grande diferena ocorre
agora, ao analisar o pacote o servidor real consegue averiguar que o pacote era destinado
ao VIP, que est configurado em seu tnel, ento ao gerar uma resposta ele insere o
VIP como remetente, sendo possvel envi-la diretamente ao cliente. Outra caracterstica
marcante da tcnica que somente nela possvel que os servidores reais estejam em uma
sub-rede diferente da do balanceador de carga, isso por conta do pacote da requisio
poder estar encapsulado em outros pacotes.
A tcnica remove o overhead do balanceador, agora ele somente precisa interceptar
42
Figura 7 Retorno de trfego via tunelamento IP

os pacotes que entram na rede, em sua sada os pacotes podem ser enviados diretamente
para o cliente, via uma rota padro diferente. Mas em compensao existe tambm um
overhead neste tipo de tcnica, pois os pacotes agora so inseridos dentro de outros pacotes, existindo dois cabealhos para cada conjunto de dados, agora sero necessrios
trafegar alguns pacotes a mais. Tambm existem as tarefas adicionais de encapsular e desencapsular os pacotes IP, mas mesmo assim, o desempenho da soluo por tunelamento
IP superior a via NAT.
3.2.3 Retorno de trfego via DR

A implementao da tcnica via DR (Direct Routing) a terceira e ltima tcnica
de retorno de trfego explicada por Zhang (2000). Para aplicao desta tcnica necessrio
que o balanceador e os servidores reais tenham uma de suas interfaces de rede ligadas por
um segmento interrupto, ou seja, ou devem estar ligados via um cabeamento direto, ou por
um HUB/switch, tudo em uma nica LAN (Local Area Network). Outra caracterstica
que todos os servidores reais devem possuir um endereo IP igual ao VIP, mas sem remover
o endereo IP que identifica unicamente os servidores reais dentro da LAN.
Um endereo IP s vezes erroneamente definido como uma forma de identificao
de uma mquina na rede, mas na verdade o endereo IP no est associado ao host, ele
associado a uma interface de rede deste, possibilitando que um mesmo host tenha n IPs
para suas n interfaces de rede. Na tcnica via DR, como os servidores reais e o balanceador
43
esto interligados em uma LAN, no h a necessidade de incluir outra interface de rede

para ser possvel associar o VIP nos servidores reais, possvel utilizar a interface de
loopback 4. A Figura 8 ilustra o uso da tcnica.
Figura 8 Retorno de trfego via DR

A Figura 8 demonstra que a arquitetura deve estar configurada de modo que todos
os hosts estejam conectados em um mesmo segmento de rede. O processo que ocorre nesta
tcnica o seguinte:
1. Um cliente envia a requisio ao balanceador de carga;
2. Aps deciso de qual servidor real ir efetuar o processamento, o balanceador troca
o endereo MAC (Media Access Control) do destinatrio (que originalmente era o
seu prprio MAC). Isso deve ocorrer para que o endereo VIP de destino do pacote
permanea inalterado;
3. O servidor real recebe a requisio, verifica que ele o destinatrio por causa do
seu VIP, processo a requisio e envia uma resposta para a sada padro da rede. O
campo de destinatrio da resposta o endereo do cliente e o campo de remetente
o VIP do balanceador, que estava configurado em sua interface de loopback;
4. O cliente recebe a resposta e a aceita, pois o endereo de remetente realmente um
endereo a quem ele fez uma requisio.
4
Interface de rede virtual utilizada para servios locais na mquina
44
Um problema aparente desta soluo com o protocolo ARP, este protocolo tem
a funo de encontrar um endereo MAC de uma interface em uma rede, informando
qual o endereo IP da interface que se deseja a informao. No caso da tcnica via DR
isto representa um problema por conta de todos os hosts da LAN compartilharem um
mesmo IP, podendo ocasionar problemas na rede. Para resolver a situao necessrio
que o sistema operacional hospedeiro dos hosts possibilite a desabilitao do protocolo
ARP nas interfaces de loopback.
3.2.4 Comparao entre as tcnicas de retorno de trfego

A Tabela 2 mostra uma comparao entre as tcnicas de retorno de trfego,
levando-se em considerao: Especificaes do servidor, forma de configurao da rede,
nmero de servidores reais aconselhados na rede e gateway da rede.
Tabela 2 Comparao entre tcnicas de retorno de trfego
Especificaes
Rede
Quantidade
Rota padro
Via NAT
Via tunelamento IP
Qualquer
Protocolo e
Tnel configurado
LAN
Baixo (10 a 20)
Balanceador de carga
LAN/WAN
Alto (aprx. 100)
Roteador da rede
Via Direct Routing

Interface de loopback
com VIP e ARP
desabilitado
LAN
Alto (aprx. 100)
Roteador da rede
3.3 Algoritmos de escalonamento

Esta seo trata de um dos mais importantes aspectos do balanceamento de carga,
no somente de balanceamento de cargas de servidores, mas grande parte das tcnicas que
sero abordadas a seguir so aplicveis em todos os tipos de balanceamento de carga (e.g.
CPU e disco). O balanceamento de carga um problema de escalonamento de trabalho,
trabalho que originalmente deveria ser realizado por um nico indivduo (e.g. Host de
rede ou ncleo de uma CPU) poder ser dividido e realizado por outros n indivduos,
para tomar a deciso de como organizar este trabalho necessrio de um algoritmo de
escalonamento.
Casavant e Kuhl (1988) definiram uma taxonomia para caracterizao de algortimos de balanceamento de carga, a seguir algumas das categorias componentes dessa
taxonomia:
Esttico vs. Dinmico: Um algoritmo esttico tem como premissa o desempenho dos
indivduos que iro realizar o trabalho, ou seja, antes de se iniciar o escalonamento
carga de trabalho definida a forma que ele ser distribudo, no sendo alterado em
3.3. Algoritmos de escalonamento
45
tempo de execuo. J um algoritimo dinmico possui poucas ou nenhuma informao sobre os indivduos, todo a deciso de escalonamento ser realizado em tempo
de execuo;
Cooperativo vs. No-cooperativo: Em um algoritmo no-cooperativo os indivduos
realizam suas tarefas independente dos outros indivduos do sistema, j em um
cooperativo um indivduo pode alterar a forma de realizao de sua tarefa devido
a uma possvel cooperao com outro indivduo (neste caso os indivduos realmente
se conhecem).
Adaptvel vs. No-adaptvel: Em uma soluo adaptvel a forma de escalonamento
da carga de trabalho poder ser modificada em tempo de execuo, isso ocorre
principalmente devido a anlise de um comportamento anterior do sistema, onde
se descobre que uma possvel alterao no escalonamento pode aumentar o desempenho do sistema. J em um no-adaptvel no existe modificao na forma de
escalonamento em tempo de execuo.
Foram omitidas algumas outras categorias dessa taxonomia, pois as selecionadas
so a que tem maior importncia quando se trata especificamente do balanceamento de
carga em servidores. A seguir sero descritos um total de cinco algoritmos de balanceamento de carga de servidores, trs estticos e dois dinmicos.
a) Round-robin e Aleatrio
um dos mais antigos algoritmos na rea da computao, aplicado originalmente em escalonamento de processos. No balanceamento de carga de servidores foi
originalmente aplicado no DNS round-robin (como explicado na seo 2.4.2). um algoritmo esttico, no-cooperativo e no-adaptvel que consiste em uma simples tcnica que distribui de forma homognea as requisies aos servidores que foram previamente ordenados, similar a um sentido horrio. Este algoritmo trata todos os servidores de forma igualitria, somo se tivessem a mesma configurao de hardware, no
diferenciado-os, caso isso seja a realidade do cluster este algoritmo tende a trabalhar bem
(MADHURAVANI; SUMALATHA; SHANMUKHI, 2012).
Um cenrio explicativo desta situao a seguir: Existem trs servidores (S1, S2
e S3) e foram enviadas em sequncia quatro requisies (R1, R2, R3 e R4) ao sistema,
usando o algoritmo round-robin, R1 seria destinado ao S1, R2 ao S2, R3 ao S3 e R4 ao
S1.
A nica diferena do algoritmo round-robin com o aleatrio que ao invs da
requisio ser distribuda seguindo a ordem dos servidores (1, 2, 3, ..., n), ela distribuda
de forma aleatria, mas sem atribuio de duas requisies ao mesmo servidor antes que
um ciclo completo de requisies tenha sido distribudo aos outros servidores.
46
b) Ratio
O algoritmo ratio, tambm chamado de round-robin com pesos em algumas solues de balanceamento de carga, outro algoritimo esttico, no-cooperativo e noadaptvel. O round-robin tradicional aconselhado para clusters com servidores homogneos, mas isso nem sempre a realidade de uma organizao, podendo existir servidores
mais antigos e com configurao mais bsica atuando em conjunto com servidores mais
novos com maior poder computacional, nestes casos o round-robin tradicional pode sobrecarregar alguns servidores enquanto outros esto ociosos (JAYASWAL, 2006, p. 224).
O algoritmo ratio indicado para clusters com servidores heterogneos, onde so
distribudos pesos entre eles, os que tiverem maior poder computacional possuem maior
peso e os com menor poder um peso menor. Um cenrio explicativo poderia ser o seguinte:
Quatro servidores reais (S1, S2, S3 e S4) com os pesos 10, 5, 5 e 7, respectivamente. Com
a soma dos pesos sendo 27, para o servidor S1 seriam direcionadas 37% das requisies,
para o S2 e S3 aproximadamente 18% cada, j pro S4 cerca de 26% das requisies.
c) Menos conexes
Como explicado anteriormente, os algoritmos estticos tem o seu comportamento
determinado previamente, no possuindo mudanas em tempo de execuo. J os algoritmos dinmicos podem tomar as decises baseadas em novas informaes do sistema
(MADHURAVANI; SUMALATHA; SHANMUKHI, 2012), estas podendo ser coletadas
via monitoramento dos servidores ou via anlise de informaes mantidas pelo prprio
balanceador.
Uma informao que o balanceador pode e deve armazenar o nmero de conexes
que cada servidor real esta processando. Uma conexo aqui pode ser tratada como o
processamento de requisies de um nico cliente, por exemplo, caso um servidor real
esteja tratando 10 requisies, sendo que duas destas pertencem a um mesmo cliente, o
servidor possu um total de 9 conexes ento. A partir do nmero de conexes de cada
servidor real, o balanceador poder dirigir as novas requisies ao servidor com o menor
nmero de conexes no momento (JAYASWAL, 2006, p. 224). Este algoritmo chamado
de Menos conexes, ele um algoritmo dinmico, no-cooperativo e adaptvel.
d) Menor latncia
Outro algoritmo dinmico, no-cooperativo e adaptvel, o Menor latncia,
semelhante a estratgia do ultimo algoritmo apresentado, onde tomada a deciso de
balanceamento em cima de informaes do sistema, s que neste caso ela coletada a
partir do monitoramento do cluster. A latncia (i.e. ping), a quantidade de tempo que
um dispositivo de rede deve esperar pela resposta de outro (JAYASWAL, 2006, p. 131).
Em um perodo de tempo pr-determinado feita a coleta do tempo de resposta destes
servidores, onde normalmente se utiliza o protocolo ICPM para tal. Os servidores com
47
3.4. Redundncia do servio
menor latncia sero os escolhidos para receber requisies.

Um problema deste protocolo que ele est fazendo uma medida relacionada a
mquina servidor, mas o que realmente importa no ponto de vista de um cliente a
performance do servio que este servidor est provendo. Algo ainda pior pode ocorrer, o
servidor real pode estar em pleno funcionamento, mas os servios dele podem se encontrar
inoperantes ou sobrecarregados, neste cenrio caso a latncia do servidor ainda esteja
mais baixa em relao a outros, ele ainda sim poderia ser selecionado para receber novas
requisies (que seriam frustradas). Uma possvel soluo para o problema seria checar os
tempos de resposta dos servios ao invs de ser capturada a latncia do servidor, e uslos para o os valores coletados para escalonamento. A forma de checar a latncia de um
servio pode ser via a diferena de tempo entre uma requisio TCP SYN e o retorno TCP
SYN ACK5 , j que o uma conexo TCP est ligada a uma porta/servio (KOPPARAPU,
2002, p. 34). A mesma soluo no vlida para servios que operam sobre o protocolo
UDP j que este no orientado a conexo, no possuindo mensagens ACK6 .
3.4 Redundncia do servio

Clientes da infraestrutura de TI7 com o passar dos anos aumentaram a sua dependncia de servios disponibilizados na internet, e esse crescimento incessante (e.g.
24h por dia e 7 dias por semana). Ento existe uma necessidade de garantir que os clientes desses servios online no fiquem desapontados com um servio fora do ar por causa
de uma falha em hardware ou software. Existem requisitos no funcionais8 que tratam
paralelamente esta necessidade, os requisitos de disponibilidade e confiabilidade.
Para garantia destes requisitos existe uma rea de estudo na computao chamada
de Tolerncia a falhas. De acordo com Jayaswal (2006, p. 233):
Tolerncia a falhas a capacidade de um host ou subsistema de recuperar a falha de um componente sem a interrupo do servio. Um
host tolerante a falhas ou dispositivo tem componentes redundantes que
monitoram uns aos outros.
Para implementar esta redundncia em balanceadores de cargas de servidores, existem dois cenrios tpicos que sero descritos a seguir. O cenrio mais comum de redundncia o cenrio ativo-standby, onde existem dois servidores (instncias) de balanceador de
cargas, uma sendo o servidor primrio, e outro o servidor secundrio, tambm chamado
5
6
7
8
Parte do que conhecido como handshake de trs vias: <http://andreysmith.wordpress.com/2011/

01/02/three-way-handshake/>
Abreviao de acknowledge. a mensagem de reconhecimento.
Acrnimo para Tecnologia da Informao.
A norma ISO/IEC 9126 trata de conceituar estes requisitos e outros: <http://pt.wikipedia.org/wiki/
ISO/IEC_9126>.
48
de servidor de backup. Quando se inicia a execuo do sistema, o servidor primrio entra

em estado de ativo do sistema (tendo o comportamento normal de um balanceador), j
o servidor secundrio entra em estado de standby (em prontido). Quando ocorre uma
falha no servidor em estado de ativo, o servidor em estado de standby detecta isso usando
algum tipo de tcnica, da em diante o servidor secundrio entra em estado de ativo, e
o servidor primrio (com falha) entra em estado de standby (CISCO SYSTEMS, 2010,
p. 33.1-33.2). Esse processo de troca chamado de failover.
Outro cenrio o ativo-ativo, onde existem dois servidores que atuam de forma
igualitria, os dois se encontram ativos e fazem o balanceamento de carga. Caso ocorra
a falha em um dos servidores, o outro ir continuar executando as suas operaes e o
servio ainda continuar online.
Para que o servidor detecte a falha em outro, seja em ativo-standby ou ativo-ativo,
deve ser utilizado algum protocolo de monitoramento em conjunto com um cabo de heartbeat. Esse cabo (normalmente um par tranado) configurando ligando os dois servidores
diretamente, ento o protocolo de heartbeat estabelece uma comunicao por pulsos entre
os dois servidores, estes pulsos determinam se o servidor est operando normalmente, caso
os pulsos se encerrem significa que alguma falha ocorreu e o servidor entrou em colapso
(JAYASWAL, 2006, p. 334-336). A deteco de erros do sistema est completamente ligada a sua confiabilidade. A Figura 9 ilustra a organizao da tcnica em um cenrio de
redundncia ativo-standby:
Figura 9 Cenrio de redundncia ativo-standby

No cenrio ativo-standby valido ressaltar que ao ocorrer o processo de failover,
as configuraes do servidor falho devem ser incorporadas no novo servidor ativo (e.g.
endereo IP, tabela de conexes, etc), para isso elas devem ser periodicamente transferidas entre os servidores. Tambm deve ser ressaltado que no cenrio ativo-ativo, os dois
3.4. Redundncia do servio
49
servidores devem possuir alguma poltica de configurao do VIP, j que existiro duas
instncias do balanceador de carga trabalhando paralelamente.
51
4 Projeto arquitetural
Este captulo e o captulo posterior (5) tem uma grande importncia para este
trabalho, sero nestes captulos que sero descritas as estratgias que foram desenvolvidas
pelo autor para a soluo que ser implementada posteriormente. Para construo do
conhecimento abordado a seguir, foi necessria a pesquisa prvia de todo o referencial
terico em que este trabalho foi baseado (captulos 2 e 3).
Especificamente neste captulo ser tratada a arquitetura do software proposto,
ser descrito um modelo conceitual que facilitar a transio dos requisitos de um balanceador de carga para a sua implementao, ou seja, servir como um guia para o futuro
TCC 2 do autor. A arquitetura de software uma das subreas de conhecimento da engenharia de software de acordo com SWEBOK1 (Software Engineering Body of Knowledge).
A arquitetura em grosso modo pode ser descrita como a subdiviso de um todo em
partes, estabelecendo relaes especficas entre as partes. Garlan e Shaw (1994) definem
a motivao da arquitetura de software como:
Conforme o tamanho e a complexidade de sistemas de software aumentam, o problema de design vai alm dos algoritmos e das estruturas de
dados da computao. A projeo e a especificao da estrutura geral do
sistema emergem como um novo tipo de problema. As questes estruturais incluem organizao total e estrutura de controle global; protocolos
de comunicao, sincronizao e acesso a dados; atribuio de funcionalidade a elementos de design; distribuio fsica; composio de elementos
de design; escalonamento e desempenho; e seleo entre as alternativas
de design.
Para uma documentao que siga as melhores prticas empreendidas na indstria

atualmente, o projeto arquitetural do balanceador de cargas ser feito tendo como base o
template de um documento de arquitetura de software do RUP (Rational Unified Process)
(IBM RATIONAL SOFTWARE, 2001).
4.1 Representao da arquitetura

Neste captulo sero indicadas as decises de uso das tecnologias que foram explicadas no referencial terico, e pelo seu baseamento em um template de documento de
arquitetura de software, este captulo tambm conter subsees que tratam das vises
de arquitetura aplicveis neste contexto (personalizadas para melhor atender o trabalho),
1
Arquitetura de software est contida dentro de uma outra rea de conhecimento mais genrica que
a de design de software: <http://www.computer.org/portal/web/swebok>
52
Captulo 4. Projeto arquitetural
e ao final listando restries de qualidade do sistema. A seguir uma breve descrio de

cada item citado:
Tecnologias e tcnicas utilizadas: Uma listagem e justificativa de quais tecnologias,
tcnicas e estratgias sero utilizadas no balanceador de carga (e.g. qual espao de
CPU ser utilizado, qual a camada de rede de atuao, qual a tcnica de retorno de
trfego, etc).
Viso lgica: Uma descrio da arquitetura lgica do balanceador, explicando uma decomposio em mdulos e camadas.
Viso de implantao: Uma descrio da decomposio do balanceador em termos fsicos, ou seja, explicao de quais sero os hosts da rede, forma de interconexo dos
hosts (meio fsico e protocolos de comunicao) e mapeamento dos processos (do
sistema operacional) que atuaro nos hosts.
Restries de qualidade: Uma descrio que compreende os requisitos no-funcionais
que restringem, ou delineiam, o projeto do balanceador, como o desempenho, a
disponibilidade e a confiabilidade.
4.2 Tecnologias e tcnicas utilizadas

Seguindo ainda o princpio KISS introduzido por Bourke (2001, p. 41), nesta seo
sero descritos e justificados quais tecnologias, tcnicas e estratgias sero utilizadas na
implementao do balanceador de carga de servidores (grande parte das alternativas j
foram listadas nos captulos 2 e 3), sempre presando pela simplicidade do sistema, at por
conta da viabilidade de sua implementao pelo autor no perodo do TCC 2.
a) Camada de rede de atuao
O balanceador a ser implementado ser baseado em servidores comuns, fazendo
uso de um computador comum com um sistema operacional padro, isso porque este
tipo de soluo requer somente o desenvolvimento do software, no sendo necessrio o
desenvolvimento da soluo de hardware como em balanceadores baseados em AISICs.
Os balanceadores na camada 2 so em sua maioria baseados em AISICs, ficando
descartada a sua utilizao. A camada 3 tambm tem grande parte das suas solues
baseadas as AISICs, isso ocorre por essa camada ser a mais alta camada de atuao de
dispositivos de rede como os roteadores (atuam normalmente na 1, 2 e 3), o que colabora
com o desenvolvimento de um balanceador com software e hardware customizados, mas
mesmo assim existem algumas solues baseadas em servidores comuns na camada 3.
Balanceadores na camada 7 esto ligados a aplicaes especficas (e.g. web, e-mail, servidor
de arquivos, etc), o que no o foco deste trabalho, j que se almeja um sistema mais
4.2. Tecnologias e tcnicas utilizadas
53
genrico que no faa distino do tipo de aplicao, ficando tambm descartada a soluo
na camada 7.
Ficaram como opes as camadas 3 e 4 do modelo OSI para atuao. Depois de
uma anlise de vantagens e desvantagens de atuao nestas duas, foi escolhida a camada
4, a seguir as justificativas:
O protocolo IP, que o principal protocolo da camada 3 no orientado a conexo,
o que significa que este protocolo tem uma baixa confiabilidade.
O protocolo TCP, um dos principais protocolos da camada 4, categorizado como
orientado a conexo e fornece um stream confivel de dados. Isso significa que uma
conexo prvia estabelecida entre os hosts comunicantes (handshake de trs vias),
e para cada segmento de dados enviado existe uma resposta de reconhecimento
(ACK), que afirma que o segmento chegou ao seu destino. Ao final tambm existe
um momento de finalizao da conexo. A Figura 10 explica esse processo de comunicao.
Figura 10 Processo de comunicao TCP
O protocolo TCP oferece um mecanismo de preveno de entrada de dados duplicados, porque cada segmento possui um campo SEQUENCE NUMBER e outro ACKNOWLEDGEMENT
NUMBER, o primeiro nmero identifica o segmento e o segundo nmero serve como
um indicador do que o remetente espera como SEQUENCE NUMBER da resposta, oferecendo um maior controle dos pacotes recebidos (COMER, 2013, p. 211).
Os protocolos da camada 4 de rede esto relacionados a portas, o que os remete
a comunicao entre aplicaes de dois hosts. Isso facilita a preveno o envio de
54
pacotes indesejados do balanceador at o cluster, porque somente sero enviados

pacotes destinados aos servios anteriormente cadastrados pelo balanceador. Por
exemplo, em um cluster de servidores web somente desejado o acesso as portas
80 e 4432 (HTTP e HTTPS), qualquer requisio de acesso a outra porta no ser
enviado. Em um protocolo da camada 3 no existe a distino de tipos de aplicao,
podendo somente ser definido o endereo de um host e no um servio que se deseja
acesso, isso poderia ocasionar o envio de requisies a todo e qualquer servio a um
host, desde que ele esteja cadastrado.
b) Modo de CPU
A deciso do modo de CPU que uma aplicao ir atuar uma ponderao sobre desempenho e estabilidade, como j foi abordado na seo 2.3.2. Este trabalho est
sendo extensamente baseado na implementao da soluo em software livre LVS, e os
seus escalonadores so mdulos do kernel Linux, ou seja, atuam no modo kernel de CPU
(HORMAN, 2003). Para maior desempenho dos sistema, que um dos focos do balanceamento de carga, a soluo proposta tambm ser implementada como um mdulo do
kernel, mas no completamente. Como uma outra parte do sistema ser implementada
como uma ou mais aplicaes para fins de administrao da soluo, atuando no modo
usurio de CPU.
O mdulo do kernel ser responsvel por efetuar a manipulao dos pacotes de
rede, j a aplicao de administrao ser formada por um servio em background e uma
interface com o usurio por linha de comando, onde por intermdio dela ser possvel
configurar o mdulo (maiores explicaes nas sees de vises arquiteturais). A forma
mais recomendada de manipulao destes pacotes de rede no modo kernel, fazendo uso
do framework Netfilter.
c) Linguagens de programao
Como foi tomada a deciso de projeto que o balanceador seria implementado como
um mdulo do kernel para sistemas Linux, obrigatoriamente a linguagem de programao
dever ser C ou C++, que so as nicas linguagens utilizadas. O desenvolvimento de
mdulos usando C++ possvel, mas desencorajada de acordo com o prprio Torvalds
(2004), criador do Linux. Algumas das justificativas dadas so:
O tratamento de excees do C++ so falhos, principalmente em mdulos do kernel;
Qualquer tipo de compilador ou linguagem que abstrai coisas como a alocao de
memria, no uma boa opo para mdulos do kernel, o que o caso do C++ por
ser uma linguagem nativamente orientada a objetos;
2
Lista
de
portas
padro
Lista_de_portas_de_protocolos>
por
protocolo:
<http://pt.wikipedia.org/wiki/Anexo:
4.2. Tecnologias e tcnicas utilizadas
55
Bibliotecas como STL e Boost do C++ trazem abstraes que podem dificultar a
depurao de um mdulo, alm de trazerem falhas que podem ser catastrficas em
um mdulo do kernel;
possvel simular a orientao a objetos na linguagem C, fazendo uso de structs e
ponteiros para funo, melhorando a modularidade do cdigo sem trazer os malefcios citados anteriormente.
Resumindo, o desenvolvimento em C mais propcio pelo programador ter maior
controle das funes do sistema (principalmente nas alocaes dinmicas de memria), o
que na teoria reduz os problemas com estabilidade do cdigo, pois necessrio lembrarse que uma falha em um programa que atua no modo kernel de CPU pode fazer todo o
sistema operacional entrar em colapso. Por conta destes fatores o mdulo ser desenvolvido
usando a linguagem C.
J o aplicativo com fins de administrao do sistema no possu essa necessidade
eminente de ser desenvolvido em C, pelo fato de atuar modo usurio de CPU. Ento foi
ponderado, analisado e acertado que ser utilizada a linguagem de programao Python
para sua implementao, a seguir algumas justificativas:
O interpretador Python vem nativamente instalado em grande parte das distribuies Linux (e.g. Ubuntu, Debian e Fedora), contendo vrias funcionalidades da
prpria distribuio implementadas em Python;
A linguagem Python a 8a mais utilizada do mundo, de acordo com dados de maio de
2014 (TIOBE SOFTWARE, 2014). Este sucesso se faz por conta de vrios benefcios
que a linguagem oferece: Possui uma sintaxe de fcil compreenso e aprendizado, tem
estruturas de dados que facilitam o desenvolvimento (e.g. listas, tuplas e dicionrios)
e uma linguagem de alto nvel, interpretada, imperativa, orientada a objetos,
funcional, de tipagem dinmica e forte;
Por conta da sua vasta comunidade de usurios, existem diversas bibliotecas e frameworks desenvolvidos e distribudos sob licenas livres para os mais diversos domnios de conhecimento (e.g. fsica aplicada, jogos de computadores e computao
grfica);
O autor do trabalho tem experincia com a linguagem devido a trabalhos acadmicos
anteriores que foram desenvolvidos utilizando Python, tendo maior preferencia no
desenvolvimento fazendo o seu uso.
d) Retorno de trfego
56
A tcnica de retorno de trfego via NAT de longe a mais simples de ser implementada, por conta de no exigir qualquer configurao adicional nos servidores do sistema,
tanto o balanceador quanto os servidores reais que iro desempenhar o processamento das
requisies. Mas ela possu uma grande desvantagem de necessitar que o as respostas dos
servidores reais passem de volta pelo balanceador, o que o torna um gargalo, diminuindo
o desempenho do sistema como um todo.
As tcnicas de retorno de trfego via DR e via tunelamento IP necessitam de um
esforo de configurao adicional do balanceador e servidores reais como j foi descrito
nas sees 3.2.2 e 3.2.3. A tcnica via tunelamento oferece a capacidade o envio de carga
de trabalho at para servidores reais que no se encontram na rede, diferentemente do DR
que necessita que todos os hosts estejam na mesma LAN, mas comparando com a tcnica
via DR, esta oferece maior desempenho por no ter o overhead de desencapsulamento dos
pacotes que o tunelamento oferece. A tcnica via DR oferece uma maior complexidade de
implementao, pois alm do balanceador de carga ter que acessar os pacotes relacionados
a sua camada de rede de atuao (e.g. Segmento TCP), ele ainda precisa acessar os quadros
ethernet da LAN para direcionar a carga de trabalho ao cluster de servidores.
Por motivos de simplicidade, a tcnica via NAT ser utilizada, pois mesmo tendo
um menor desempenho relacionado as outras duas, ela elimina uma srie de fatores que
aumentam a complexidade do projeto, que podem eventualmente at arriscar a viabilidade
do trabalho.
e) Algoritmos de escalonamento
Inicialmente iro ficar definidos dois algoritmos a serem implementados, um da
categoria de algoritmos de escalonamento estticos e outro da categoria de algoritmos
dinmicos. O algoritmo esttico a ser implementado ser o round-robin, que apesar de
sua simplicidade tende a ter bons resultados em um cluster heterogneo com aplicaes
de propsito especfico (MADHURAVANI; SUMALATHA; SHANMUKHI, 2012). O algoritmo dinmico escolhido foi o menor latncia, que consegue identificar servidores
reais menos sobrecarregados pelo seu tempo de resposta dos seus servios.
f) Forma de redundncia
Parte do esforo deste trabalho se destina ao projeto de integrao do balanceador
de cargas com o software fornecido pelo professor orientador deste trabalho, o Application
Manager. Este software implementado na linguagem Java um gerenciador de mltiplas
aplicaes em cenrio ativo-standby, destinado a ambientes com mltiplos hosts distribudos (LARANJEIRA, 2011). Por intermdio dele uma mesma aplicao (e.g. servidor
web, servidor de arquivos, etc) pode possuir duas instncias, uma ativa em um host de
uma rede, a outra inativa (em standby) em outro host da mesma rede, e elas podem ser
gerenciadas via um utilitrio de linha de comando (amcli). Em caso de um colapso da
4.3. Viso lgica
57
aplicao ativa, a outra que estava inativa seria iniciada para exercer as mesmas funes
da aplicao que falhou.
Por conta deste objetivo especfico de pesquisa e desenvolvimento pr-definido, o
nico cenrio de redundncia utilizado neste trabalho ser o ativo-standby.
4.3 Viso lgica

A viso lgica nica para todo o sistema, ela visa ilustrar os subsistemas, mdulos
e tudo mais que possuir comportamento significativo no ponto de vista da arquitetura
(IBM RATIONAL SOFTWARE, 2001). A Figura 11 a seguir demonstra um diagrama de
pacotes3 da UML (Unified Modeling Language) do balanceador de cargas projetado.
Figura 11 Viso lgica da soluo de balanceamento de carga

A seguir ser feita uma descrio de cada componente pertencente ao diagrama.
a) Load Balancer Solution
Este o conjunto de programas que constituem o balanceador de cargas de servidores. Aps sua instalao em um servidor Linux ser possvel efetuar a configurao e
uso da soluo de balanceamento de carga.
b) slbcli
3
<http://pt.wikipedia.org/wiki/Diagrama_de_pacotes>
58
O componente slbcli (Server Load Balancer CLI ) ser um programa do tipo CLI
(Command Line Interface). Ele contm uma srie de funcionalidades administrativas do
servio que podero ser acessadas via o interpretador de comandos do Linux (Shell).
Este programa ser a interface do balanceador de cargas com o usurio administrador do
sistema, onde ser possvel iniciar, parar e configurar o balanceador de carga.
A seguir exemplos de possveis de comandos:
# slbcli --load : Carrega o mdulo do balanceador no kernel. Por padro, antes de efetuar
a carga do mdulo, sero lidos e aplicados os itens do arquivo padro de configurao
# slbcli --unload : Descarrega o mdulo do balanceador do kernel
# slbcli --reload : Recarrega o mdulo do balanceador no kernel. Por padro, antes de efetuar a carga do mdulo, sero lidos e aplicados os itens do arquivo padro de configurao
# slbcli --load-noconf : Carrega o mdulo do balanceador no kernel, ignorando o arquivo
padro de configurao
# slbcli --reload-noconf : Rearrega o mdulo do balanceador no kernel, ignorando o arquivo padro de configurao
# slbcli --restore conf_file.conf : Carrega as configuraes que esto contidas no arquivo conf_file.conf
# slbcli --bind 172.17.60.201:80 : Atribui um endereo VIP 172.17.60.201 ao balanceador, juntamente com a porta 80 que ele ir atender
# slbcli --alg RR : Seleciona o algortimo de balanceamento de carga round-robin para ser
utilizado
# slbcli --add 192.168.0.1:80 : Adiciona um servidor real com IP 192.168.0.1 ao cluster
de servidores, podendo receber requisies na porta 80
# slbcli --rm 192.168.0.1:80 : Remove um servidor real com IP 192.168.0.1
# slbcli --lconn : Lista todas as conexes atualmente ativas
# slbcli --lserv : Lista os servidores reais do cluster e os seus respectivos status (e.g. UP e
DOWN)
# slbcli --lconf : Lista toda a configurao do sistema
# slbcli --clearconf : Limpa toda a configurao j feita, inclusive exclui todos os itens do
arquivo de configurao padro
4.3. Viso lgica
59
O smbolo # significa que o comando est sendo executado em um shell 4 pelo

usurio root do sistema Linux. A lista de comandos provavelmente sofrer alteraes na
futura implementao do balanceador pela mudana ou descoberta de novos requisitos.
O slbcli ser um programa implementado em Python, ele ir interagir com o servio de
balanceamento de carga que estar executando em background, fazendo um repasse dos
comandos para que este execute-os.
c) slbd
O componente slbd (Server Load Balancer Daemon) ser um programa do tipo
daemon, um tipo de processo que executado em brackground e no possui interao direta
com nenhum tipo de usurio. Esse processo ser o responsvel por ser a aplicao no modo
usurio de CPU que ir interagir com o mdulo do kernel, tendo as funcionalidades de
carreg-lo, descarreg-lo e configur-lo.
d) slbcore
O componente slbcore (Server Load Balancer Core) ser o ncleo de todo o sistema,
ser um LKM (Loadable Kernel Module), um cdigo objeto carregvel que ir estender as
funcionalidades do kernel Linux. Este mdulo ir fazer o balanceamento no modo NAT,
que foi o tipo de retorno de trfego escolhido para ser implementado na soluo. Ele ser
responsvel por interceptar os segmentos TCP e UDP que contm as requisies a servios
que os servidores reais iro desempenhar, e aps deciso de qual ser o servidor escolhido
para processamento da requisio (por intermdio do subcomponente scheduling-algs),
este mdulo ir repassar o segmento.
e) netfilter
o componente que representa o framework Netfilter a ser utilizado pelo slbcore
para acesso a funcionalidades de interceptao de pacotes de rede, fazendo a importao
de suas devidas bibliotecas de forma privada (por isso o uso da associao com esteretipo
access no diagrama UML).
f) scheduling-algs
O scheduling-algs o componente responsvel pela implementao dos algoritmos
de escalonamento de servidores, uma referncia a Scheduling Algorithms. O algoritmo
padro a ser utilizado ser o round-robin (RR), mas tambm ser possvel selecionar o
algoritmo menor latncia (LL). Este um subcomponente do slbcore, sendo parte do
mdulo do kernel.
g) cluster-monitor
O componente cluster-monitor a referncia do sistema para funes de monitoramento dos servidores reais em tempo de execuo. O cluster-monitor um subcomponente
4
Iterpretador de comandos Unix: <http://en.wikipedia.org/wiki/Unix_shell>
60
do slbcore, tambm sendo parte do mdulo do kernel.

Existiro a princpio duas funcionalidades exercidas por este componente:
Monitorar a latncia dos servidores reais quando estiver sendo utilizado o algoritmo
menor latncia do componente scheduling-algs, servindo como parmetro para
suas decises de escalonamento.
Monitorar periodicamente o cluster para detectar possveis falhas nos servidores.
A princpio o objetivo deste monitoramento servir para identificar servidores reais
inacessveis, que consequentemente devem ser removidos da tabela de servidores do
slbcore enquanto no voltarem e executar suas funes normalmente.
Mais informaes sobre como esse monitoramento ir ocorrer sero descritos no
captulo 5.
h) configuration-synchronizer
Este um componente a parte do balanceador de cargas, responsvel por sincronizar a configurao do balanceador em um cenrio de redundncia ativo-standby. dito a
parte porque ele ser implementado de forma independente da soluo de balanceamento
de carga, ficando a cargo do administrador do sistema decidir se ir ou no utiliz-lo.
O seu uso necessrio no caso de um desastre eventual que ocorra no sistema,
para que no momento em que ocorrer o processo de failover a instncia secundria possua
toda a configurao mais recente da instncia primria (com falha), mascarando a falha
ocorrida no ponto de vista dos usurios dos servios. Para realizar a sincronizao ser feita
uma cpia peridica do arquivo de configurao do servidor primrio para o secundrio
(maiores detalhes no captulo 5). Este componente tambm ser implementado em Python
j que ele ser implementado no modo usurio de CPU.
i) Application Manager
Este o conjunto de programas que constituem o software Application Manager,
um um gerenciador de mltiplas aplicaes em cenrio ativo-standby, destinado a ambientes com mltiplos hosts distribudos. No contexto da soluo que est sendo projetada,
existiro duas instncias do software, uma no balanceador de carga primrio e outra no
secundrio. A Figura 12 ilustra a estrutura do sistema.
Como pode se observar em cada host podem existir mais de uma aplicao sendo
gerenciada (e.g. app-1, app-2, app-3), o que oferece a capacidade de serem gerenciados tanto a soluo de balanceamento de carga, quanto o componente configurationsynchronizer, que so duas aplicaes independentes. Mais detalhes sobre os subcomponentes do Application Manager sero dados a seguir.
j) SMA
61
4.3. Viso lgica
Figura 12 Estrutura do Application Manager

Fonte: Laranjeira (2011). Adaptado pelo autor.
O SMA o subcomponente do Application Manager responsvel por gerenciar o

estado de cada aplicao, ou seja, para cada aplicao que est sendo gerenciada existiro
duas instncias do SMA que administram os seus estados, um para a aplicao ativa e
outro para a aplicao em standby. Na Figura 13 exemplificada a mquina de estados5
que o SMA atribui a cada aplicao, e na Tabela 3 so descritos os eventos para a transio
dos estados.
Figura 13 Mquina de estados do SMA

A forma que este componente gerencia o estado de uma aplicao estabelecendo

5
<http://pt.wikipedia.org/wiki/M%C3%A1quina_de_estados_finitos>
62
Tabela 3 Eventos para troca de estados do SMA

Estado atual
Novo estado
Evento
OFFLINE
INIT
INIT
INIT
STANDBY
MAINT.
STANDBY
Todos
Todos
INIT
STANDBY
ACTIVE
MAINT.
MAINT.
STANDBY
ACTIVE
FAILED
OFFLINE
Aplicao iniciada
Aplicao inicializada, configurao BACKUP e aplicao dual em ACTIVE
Aplicao inicializada, configurao PRIMARY e aplicao dual no em ACTIVE
Aplicao inicializada e configurao INHIBITED
Comando TEST
Comando UNTEST
Falha do aplicao, dual ACTIVE ou comando SWITCH
Falha da aplicao
Comando SHUTDOWN ou SHUTDOWN-F
uma comunicao local com ela. Para isso a aplicao gerenciada deve implementar uma
interface com o mecanismo de identificao das mensagens de troca de estados, e tambm
um mecanismo para informar que est ativa.
k) amcli
O subcomponente amcli (Application Manager CLI ), um programa do tipo CLI.
Este o responsvel por interagir com o administrador do sistema, aceitando uma grande
gama de comandos para alteraes nos estados das aplicaes gerenciadas ou configurar
o prprio Application Manager.Uma lista completa dos comando est no Apndice A.
l) heartbeat
Programa do tipo daemon que possui uma instncia por host do Application Manager. Eles implementam um protocolo de comunicao heartbeat para verificao das
atividades do seu par, caso no consiga estabelecer a comunicao.
4.4 Viso de implantao

A viso de implantao tem a funo de descrever a decomposio fsica do sistema,
ficando visvel o conjunto de hosts onde ocorrer o processamento, inclusive a distribuio
dos componentes/pacotes de software que em um ambiente de execuo se tornaro processos/threads nesses hosts (IBM RATIONAL SOFTWARE, 2001). A seguir na Figura
14 representa o diagrama de implantao6 da UML para balanceador de carga projetado.
Neste diagrama esto dispostos os ns (forma geomtrica de paraleleppedo), os
componentes de software (retngulos internos aos ns) e suas associaes. A seguir uma
descrio de cada n:
Primary Load Balancer: Balanceador de carga primrio da soluo;
6
<http://pt.wikipedia.org/wiki/Diagrama_de_instala%C3%A7%C3%A3o>
4.4. Viso de implantao
63
Figura 14 Viso de implantao da soluo de balanceamento de carga

Real Server: Servidor real. No diagrama foi colocado como um nico n, mas na soluo
real existiro n ns;
Secondary Load Balancer: Balanceador de carga secundrio ou de backup. Seus componentes internos no foram ilustrados por possurem a mesma disposio dos componentes do Primary Load Balancer.
Grande parte dos componentes j foram descritos anteriormente no diagrama de
pacotes da viso lgica do sistema, com exceo do artefato slbconf.conf que representa o
arquivo de configurao do balanceador de carga, e o componente Any Service que faz a
representao de qualquer tipo de servio que um servidor real pode prover (e.g. servidor
web, servidor de e-mail, etc).
As associaes ilustradas no diagrama so categorizadas em dois tipos, associaes
fsicas e associaes lgicas. As associaes fsicas associam dois ns do sistema, ou seja,
so os meios fsicos de rede (e.g. cabo de rede ethernet, rede sem fio, etc), representados no diagrama por linhas contnuas. As associaes lgicas normalmente associam um
componente a outro componente, seja ele local ou remoto, podendo at ser utilizado para
associar um componente a um n. As associaes lgicas so protocolos, ou at mesmo
programas completos, e foram representadas no diagrama por linhas tracejadas. A seguir
a descrio das associaes:
LAN: Conexo fsica entre os hosts em uma rede local. Sero um conjunto de switches
de rede conectando os hosts com cabos par tranado cat 5e e conectores RJ-45.
64
TCP/UDP: Como a camada de rede de atuao do balanceador de carga a camada

4, no ponto de vista do sistema sero transmitidos e recebidos segmentos TCP
e/ou UDP entre o balanceador de carga e os servidores reais. Tambm representa
a estratgia com TCP SYN / SYNACK para checagem da latncia de servios
baseados no protocolo TCP.
ICMP: A associao do slbcore com o Real Server significa o envio de pings para verificar
se servidor est ativo e qual a latncia da conexo (no caso do servio provido no
for baseado em TCP).
IOCTL: Essa associao entre o slbd e o slbcore significa a forma de comunicao entre o programa no modo usurio de CPU e o mdulo do kernel em modo kernel
de CPU. IOCTL (Input Output Control) uma system call que serve como meio
de comunicao entre aplicaes nos dois modos de CPU. Maiores explicaes no
captulo 5.
Read/Write: A associao entre o slbd e o slbconf.conf de leitura e escrita de arquivos.
Isso ocorre porque o slbd ir ser o responsvel por atualizar este arquivo de configurao sempre que o slbcli indicar novos comandos de configurao (inseridos via
linha de comando pelo usurio), e ele tambm far a leitura do arquivo sempre que
o mdulo do kernel for carregado ou recarregado, para passagem dessa configurao
via IOCTL. O motivo pelo qual o mdulo do kernel no far acesso direto a esse
arquivo ser descrito no captulo 5.
Read: A associao entre o configuration-synchronizer e o slbconf.conf de leitura de
arquivos. Isso ocorre porque periodicamente este arquivo de configurao ser sincronizado entre Primary Load Balancer e o Secondary Load Balancer.
SCP: A associao entre o configuration-synchronizer e o Secondary Load Balancer representa o protocolo SCP (Secure Copy Protocol), que ser o responsvel pela transferncia segura do arquivo do Primary Load Balancer para o Secondary Load Balancer.
TCP Socket: Essa forma de comunicao via a API de comunicao TCP Socket7 ocorre
em trs pontos do sistema. (i) A associao entre o Application Manager e o slbd
representa uma comunicao interna no servidor primrio e secundrio, fazendo o
envio de alteraes de estados do servio de balanceamento de carga (e.g. ativo, em
standby, em manuteno), e tambm a checagem constante da execuo processo
slbd, para verificar se est em execuo ou parou mediante alguma falha. (ii) A
associao entre as duas instncias do Application Manager, uma no Primary Load
7
Um socket uma API (Application Programming Interface) oriunda de sistemas BSD Unix para
comunicao entre aplicativos sobre a pilha TCP/IP, normalmente baseado em TCP (Stream) ou
UDP (Datagrama).
4.5. Restries de qualidade
65
Balancer e outra no Secondary Load Balancer, onde so enviados e processados comandos que normalmente so solicitados pelo administrador do sistema ou enviados
automaticamente ao ocorrer um processo de failover, sendo necessrio iniciar o slbd
no Secondary Load Balancer. (iii) A associao entre o slbcli e o slbd representa
uma comunicao interna do servidor, onde so repassadas comandos inseridos por
um usurio para o daemon slbd, j que o mesmo no possui interao direta com o
usurio.
UDP Socket: Essa comunicao ocorre entre os componentes heartbeat do Application
Manager no Primary Load Balancer e no Secondary Load Balancer, sendo uma
implementao de uma comunicao heartbeat.
4.5 Restries de qualidade

Um importante aspecto de uma arquitetura so as suas restries de qualidade
do produto, estas restries possuem um grande impacto nas decises de projeto de um
sistema por estarem totalmente associadas s dimenses de qualidade de um software.
Essas dimenses de qualidade so capturadas como requisitos, mais especificamente requisitos no funcionais. No contexto do projeto do balanceador de carga j foram evidenciadas diversas vezes durante este trabalho importantes categorias de requisitos que
tiveram total impacto na soluo que est sendo projetada, como o Desempenho, a Disponibilidade, a Confiabilidade, etc. Para cada uma dessas categorias podemos extrair alguns requisitos e para cada requisito podemos indicar como a arquitetura ir suport-los
(IBM RATIONAL SOFTWARE, 2001).
Desempenho
Requisito: A latncia dos servios providos pelo cluster de servidores no pode
ser maior do que a latncia do mesmo servio sendo oferecido por um servidor
individual (sem balanceamento de carga).
Suporte da arquitetura: A soluo de balanceamento de carga serve exatamente
para aumentar o desempenho, pois a carga de trabalho que seria realizada por
um nico host ser dividida entre n hosts.
Confiabilidade
Requisito: O sistema dever se recuperar caso ocorra um falha no servidor de
balanceamento de carga.
Suporte da arquitetura: Isso ocorre mediante a integrao com o Application
Manager.
66
Confiabilidade
Requisito: O sistema dever reconhecer hosts com defeito no cluster de servidores
e remov-los do cluster enquanto no voltarem a normalidade.
Suporte da arquitetura: O componente slbcore faz essa verificao via envio e
receptao de pacotes ICMP e TCP SYN / SYNACK.
Disponibilidade
Requisito: O sistema de balanceamento de carga dever ser capaz de oferecer seu
servio 24h por dia e 7 dias por semana.
Suporte da arquitetura: A soluo de balanceamento de carga oferece a tolerncia a falhas, o que determina meios de ter uma alta disponibilidade.
Escalabilidade
Requisito: O sistema dever suportar a insero e remoo de servidores do cluster
sem a interrupo do servio.
Suporte da arquitetura: O slbcli possibilitar a insero e remoo de forma
simples.
67
5 Detalhes tcnicos da soluo

O ltimo captulo ofereceu uma abordagem arquitetural sobre o balanceador de
cargas que est sendo projetado, fornecendo uma viso geral do comportamento do sistema para que seja possvel observar suas principais funcionalidades e caractersticas.
Propositalmente a arquitetura de software no tende a entrar em pequenos detalhes da
soluo, j que ela pretende fornecer uma viso alto nvel do sistema e no um projeto
detalhado da soluo.
Este captulo tem uma abordagem diferente, ele visa oferecer certo detalhamento
sobre alguns dos componentes do sistema que foram levantados. Esse detalhamento
necessrio para um esclarecimento de forma mais tcnica de como podero ser implementadas determinadas caractersticas, ou como podero ser solucionados determinados
problemas que foram evidenciados. Este nvel de detalhes visa refinar o projeto da soluo,
facilitando o alcance do sucesso no processo de codificao do sistema. Para viabilidade
da descrio destes detalhes, sero descritos somente alguns dos considerados mais importantes, porque seria invivel detalhar totalmente todas as caractersticas de um sistema.
5.1 Configurao da rede de computadores

Em diversos momentos neste trabalho foram demonstrados possveis cenrios de
balanceamento de carga, mas em nenhum deles o projeto da rede foi fidedigno a uma soluo real, ou seja, em todos eles foram omitidos algum elemento de rede para facilitar a
visualizao e entendimento da soluo. Como no desejado no momento de implementao do sistema possuir uma determinada dvida em como configurar a rede, necessrio
determinar uma provvel configurao.
A Figura 15 ilustra um projeto simples de uma rede baseado em uma configurao descrita por Kopparapu (2002, p. 90), podendo ser utilizado em uma situao real.
Neste cenrio existe um roteador com IP pblico e fixo, provavelmente com uma WAN
(Wide Area Network) configurada diretamente com sua ISP (Internet Service Provider),
isso possibilitar que demandas da internet cheguem na rede configurada. Conectados
ao roteador estaro as duas instncias de balanceadores de carga, uma ativa e outra em
standby. O balanceador ativo ter um VIP pblico e fixo acessvel pela internet, configurado em uma de suas interfaces de rede (e.g. eth0 em um servidor Linux), ele tambm
possuir um IP privado e nico na rede configurado em outra interface (e.g. eth1) para
comunicar-se entre os servidores e servir como gateway dos mesmos, tambm necessrio
um terceiro IP privado para uso do heartbeat entre os balanceadores (e.g. eth2). O balanceador em standby configurado da mesma forma que o ativo, com exceo que seu VIP
68
Captulo 5. Detalhes tcnicos da soluo
Figura 15 Projeto da rede de computadores da soluo

e o IP para comunicar-se entre os servidores (que tero os mesmos endereos do balanceador ativo) somente sero configurados em um processo de failover, quando o balanceador
ativo falhar. Enquanto esse processo no ocorrer, estas interfaces de rede ficaro sem IP.
Para possibilitar a comunicao entre o balanceador e os servidores, dever existir
um switch da camada 2 que estar conectado aos balanceadores e os servidores reais.
Neste cenrio existem algumas deficincias, como os gargalos que podem se tornar o
roteador e o switch, pois uma falha em algum dos dois dispositivos tiraria o servio do
ar. Para resoluo desse problema seria necessrio uma soluo com mltiplos switches e
roteadores, aumentando a redundncia da rede, mas este cenrio no foi planejado por
ser muito custoso, o que inviabiliza a sua realizao no contexto deste trabalho.
5.2 Monitoramento do cluster

O monitoramento do cluster de servidores necessrio por dois motivos, (i) verificar se cada servidor real est em seu normal funcionamento, para que no sejam enviadas
requisies a servidores inoperantes, e (ii) verificar a latncia dos servios providos pelos
servidores reais, fornecendo parmetros para a deciso do algoritimo de menor latncia.
Para verificar se um servidor est operante, em teoria pode ser utilizado o protocolo ICMP, destinado principalmente para troca de mensagens de controle, o protocolo
trabalha juntamente com o IP e seus pacotes so inseridos dentro de pacotes IP para
envio de relatrios sobre a comunicao (BENVENUTI, 2005, p. 585). O cabealho de
um pacote ICMP define um campo type, que pode receber 18 valores diferentes de tipos do pacote, de acordo com o que foi definido na RFC1 792 (Request for Comments).
1
Uma RFC um documento oficial que define o padro de um protocolo de rede. A grande maioria
5.2. Monitoramento do cluster
69
Dentro desses tipos existem trs que interessam ao caso, ICMP_ECHO, ICMP_ECHOREPLY e
ICMP_DEST_UNREACH.
Para checagem da existncia de um host em uma rede, pode ser preparado um
pacote ICMP do tipo ICMP_ECHO e envi-lo ao host desejado, caso o host receba o pacote
ele ir retornar um ICMP_ECHOREPLY, o tempo entre essas duas aes define a latncia.
Caso o host no esteja acessvel um ICMP_DEST_UNREACH gerado.
Existem pacotes de rede que so gerados de forma programtica por um programa,
ou seja, no so gerados da forma natural que o sistema operacional lida com a pilha
TCP/IP, esses pacotes so chamados de raw packets. O cabealho e o payload desses
pacotes so montados de forma manual, o que requer grande cuidado em sua montagem
para que ele seja descartado pelo destinatrio ao serem feitas suas validaes.
Para monitorar cada servidor real dever ser gerado um raw packet ICMP do
tipo ICMP_ECHO, depois deve ser gerado um raw packet IP e encapsular o pacote ICMP
dentro do seu payload, para s ento enviar para o dispositivo de rede responsvel (e.g.
eth0). Quando forem recebidos pacotes IP de resposta, devem ser verificados se o campo
protocol do seu cabealho (campo que determina qual protocolo est contido no payload,
e.g. TCP, UDP, ICMP, IGMP, etc) indica que ele contm carrega um pacote ICMP, depois
deve ser desencapsulado o pacote ICMP e ento verificado se o seu campo type indica
um ICMP_ECHOREPLY.
O cdigo no Quadro 1 contm algumas partes de um cdigo que realiza o envio
de um ICMP_ECHO. J o cdigo no Quadro 2 contm algumas partes de um cdigo que
realiza a verificao do ICMP_ECHOREPLY.
Deve se salientar que os dois exemplos anteriores so apenas partes de cdigos
que implementam as funcionalidades. Uma importante estrutura de dados para redes em
Linux foi utilizada nestes exemplos, o sk_buff. De acordo com Benvenuti (2005, p. 23),
esta estrutura utilizada por vrias camadas de rede (MAC ou outra protocolo de enlace
da camada 2, IP na camada 3, TCP ou UDP na camada 4), e vrias outros campos da
estrutura se modificam de acordo com que so passados de uma camada a outra. Nesta
estrutura so inseridos os cabealhos dos diversos protocolos que ela trafega, ao final do
caminho na pilha (camada 1) existir uma estrutura sk_buff com diversos cabealhos
de protocolos, acessveis por intermdio de funes como ip_header = ip_hdr(skb),
acrescentado dos dados que se deseja transmitir (e.g. texto, vdeo, udio, etc).
Algo semelhante ocorre no monitoramento da latncia dos servidores, mas neste
caso feita a verificao da latncia dos servios e no a latncia na comunicao entre os
hosts, como pode ocorre no mtodo anterior. Para verificar a velocidade de resposta de um
servio, pode ser utilizado parte do handshake de trs vias que ocorre no estabelecimento
dos protocolos possui uma RFC associada.
70
Quadro 1 Cdigo fonte C: Envio de um ICMP_ECHO

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// ...
icmp . type = I C M P _ E C H O; // Define um ECHO para o ICMP
ip . p r o t o c o l = I P P R O T O _ I C M P ; // Define que o p r o t o c o l o sera ICMP
ip . daddr = i n e t _ a d d r( " 1 0 . 1 0 . 1 0 . 2 " ) ; // Define o end . do d e s t i n a r a r i o
// ...
// R e s e r v a uma e s t r u t u r a " struct s k _ b u f f" no t a m a n h o de um frame
ethernet
struct s k _ b u f f * skb = d e v _ a l l o c _ s k b (1500) ;
skb - > dev = _ _ d e v _ g e t _ b y _ n a m e ( net , " eth0 " ) ; // Define o device de saida
// ...
// C o n f i g u r a o c a b e c a l h o da camada de t r a n s p o r t e ( ICMP )
skb - > t r a n s p o r t _ h e a d e r = s k b _ p u s h( skb , sizeof ( icmp ) ) ;
memset ( skb - > t r a n s p o r t _h ead er ,0 , sizeof ( struct i c m p h d r) ) ;
memcpy ( skb - > t r a n s p o r t _h ead er ,& icmp , sizeof ( struct i c m p h d r) ) ;
// ...
// C o n f i g u r a o c a b e c a l h o da camada de rede ( IP )
skb - > n e t w o r k _ h e a d e r = s k b _ p u s h( skb , sizeof ( ip ) ) ;
memset ( skb - > n e t w o r k _h eade r ,0 , sizeof ( struct iphdr ) ) ;
memcpy ( skb - > n e t w o r k _h eade r ,& ip , sizeof ( struct iphdr ) ) ;
// ...
d e v _ q u e u e _ x m i t ( skb ) ; // D e s p a c h a o s k _ b u f f
kfree ( skb ) ;
Quadro 2 Cdigo fonte C: Recebimento de um ICMP_ECHOREPLY

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// ...
if ( skb == NULL )
return -1;
iph = ip_hdr ( skb ) ; // Pega o c a b e c a l h o IP
// ...
// V e r i f i c a se o " p r o t o c o l" eh mesmo o ICMP
if ( iph - > p r o t o c o l == I P P R O T O _ I C M P ) {
icmph = i c m p _ h d r( skb ) ; // Pega o c a b e c a l h o ICMP
if ( icmph - > type == I C M P _ E C H O R E P L Y ) { // eh um ECHO REPLY ?
// S e r v i d o r esta a c e s s i v e l entao
} else if ( icmph - > type == I C M P _ D E S T _ U N R E A C H ) { // eh um DEST .
U N R E A C H A B L E?
// S e r v i d o r esta inacessivel , deve ser r e m o v i d o t e m p o r a r i a m e n t e do
c l u s t e r de tempos em tempos sera v e r i f i c a d o o seu r e t o r n o ...
}
}
de uma conexo TCP. Pode ser criar um raw packet de um segmento TCP com a flag do
tipo SYN ativada (bit = 1), e ento envi-lo ao servidor e esperar como resposta um
TCP segmento TCP com as flags SYN e ACK ativadas, a diferena de tempo entre esses
dois eventos indica a latncia do servio (KOPPARAPU, 2002, p. 30). Caso o servio
seja baseado em UDP, por exemplo, essa tcnica no surtir efeito j que o protocolo
no possui segmentos de reconhecimento (ACK), podendo como alternativa ser verificada
5.3. Processo de failover
71
a latncia com o protocolo ICMP, igual ao exemplo de verificao da conexo com os

servidores reais com um adicional de verificao de tempo entre os eventos.
5.3 Processo de failover

Em um cenrio ativo-standby, caso o sistema ativo venha a falhar, algumas providncias sero tomadas reativamente a situao (logo aps a falha) e algumas providncias
j devem estar sendo tomadas preventivamente (anteriormente a falha). Aqui ser explicado sucintamente esse processo.
O mdulo configuration-synchronizer atua preventivamente, pois sincroniza continuamente a configurao do balanceador, para que o n em standby tenha o mesmo
comportamento do ativo quando ocorrer um failover. A seguir as tarefas realizadas pelo
componente:
1. O arquivo de configurao da soluo de balanceamento de carga ficar localizado em
uma pasta especfica do sistema (e.g. /etc/slb/slbconf.conf), ou poder ser solicitado ao programa slbcli (e.g. # slbcli --lconf > slbconf_dump_file.txt).
2. Periodicamente (e.g. de 10 em 10 segundos) essa arquivo ser transferido via o
protocolo SCP (Secure Copy Protocol), que um meio de transferncia de arquivos
entre dois hosts remotos de forma segura, fazendo uso de criptografia, este protocolo
baseado em outro, o SSH2 (Secure Shell). Para realizar essa tarefa ser necessria
uma biblioteca Python (linguagem do componente em questo) para comunicao
via o protocolo SCP. O cdigo no Quadro 3 exemplifica realizao da transferncia
usando as bibliotecas paramiko e scp3 para Python.
3. Quando o failover ocorrer e for iniciado o slbd no novo balanceador ativo, o arquivo
de configurao ser o mais recente possvel e o servio continuar com as mesmas
caractersticas do antigo balanceador ativo.
As duas instncias do Application Manager no balanceador ativo e standby atuam
de forma reativa, esto em constante troca de heatrbeats via um cabo de rede exclusivo,
mas alm disso tambm podem ser trocados comandos administrativos (e.g. efetuar um
uma troca de estados, primrio vira em standby e secundrio vira ativo). Os heartbeats so
trocados via uma comunicao UDP. Caso seja percebida uma falha no servidor primrio,
de forma reativa sero realizadas as seguintes tarefas:
2
O protocolo SSH prov a estrutura para conexo remota entre hosts: <http://pt.wikipedia.org/wiki/
SSH>
<https://pypi.python.org/pypi/scp>
72
Quadro 3 Cdigo fonte Python: Envio de arquivo via SCP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import scp
import p a r a m i k o
# Cria o c l i e n t e SSH
def c r e a t e S S H C l i e n t ( server , port , user , p a s s w o r d) :
client = p a r a m i k o. S S H C l i e n t ()
client . l o a d _ s y s t e m _ h o s t _ k e y s ()
client . s e t _ m i s s i n g _ h o s t _ k e y _ p o l i c y ( p a r a m i k o. A u t o A d d P o l i c y () )
client . c o n n e c t( server , port , user , p a s s w o r d)
return client
# C o n e c t a com o s e r v i d o r
s s h _ c l i e n t e = c r e a t e S S H C l i e n t ( " 1 0 . 1 0 . 1 0 . 2" , 22 , " root " , " passwd " )
s c p _ c l i e n t e = scp . S C P C l i e n t( s s h _ c l i e n t e . g e t _ t r a n s p o r t () )
# Transfere o arquivo
s c p _ c l i e n t e . put ( files =[ " / etc / slb / s l b c o n f. conf " ] , r e m o t e _ p a t h = " / etc / slb /
s l b c o n f. conf " , r e c u r s i v e= False , p r e s e r v e _ t i m e s = False )
1. A instncia do componente heartbeat no servidor secundrio ao perceber que o seu

par no est mais se comunicando, se comunica com a instncia do Application
Manager informando a falha do outro servidor.
2. O Application Manager se comunica via seu socket TCP com a interface da aplicao
que ele est gerenciando, no caso o slbd, enviando um comando para que ele se torne
a instncia ativa.
3. O slbd ao receber o comando, configura duas interfaces de rede (e.g. eth0 e eth1),
uma com o VIP do servio de balanceamento de carga e outra com o IP para
comunicao interna com os servidores reais e para servir como gateway da rede
interna. Logo aps o slbd carrega o mdulo do kernel (slbcore) e o configura de
acordo com o contedo do arquivo de configurao slbconf.conf.
importante ressaltar que esse processo de failover descrito considerado stateless

e no stateful. Um failover stateless no define que a tabela de conexes que regia na
instncia ativa (agora com falha) ser passada e usada pelo servidor em standby (agora
se tornando ativo), ou seja, todas as conexes TCP ativas que existiam entre clientes
e servidores reais ser perdida, j em um processo de failover stateful essa tabela de
conexes tambm ser compartilhada (KOPPARAPU, 2002, p. 96). A sincronizao da
configurao que foi projetada garante apenas que o novo balanceador de carga ativo
saber quais so os servidores reais que ele redistribui a carga, quais portas poder atender,
qual algoritimo ser utilizado, etc.
5.4. Comunicao entre slbd e slbcore
73
5.4 Comunicao entre slbd e slbcore

Em alguns momentos na descrio deste trabalho foi falada sobre o modo de configurao do slbcore, foi dito que ela seria feita atravs de uma interao via IOCTL com
o slbd, este daemon iria realizar a leitura da configurao ou iria receber um comando do
slbcli, e logo aps iria se comunicar com o mdulo do kernel para configur-lo. Mas ainda
no foi explicado o motivo dessa deciso arquitetural, qualquer um poderia se questionar
do porque do slbcore no ler diretamente o arquivo slbconf.conf, ou do porque o slbcli
no se comunica diretamente com ele. A seguir as explicaes para estes fatos.
De acordo com Kroah-Hartman (2005), a leitura de arquivos dentro de mdulos do
kernel uma m ideia pois os problemas que isso pode causar so devastadores dentro de
um mdulo. Em primeiro lugar existe o problema da interpretao dos dados (parsing 4),
uma simples interpretao errada pode abrir espaos para buffer overflows, que significa
ultrapassar os limites de escrita de um buffer 5 , acessando memria indevida e oferecendo
uma abertura para execuo de instrues mal intencionadas (LEVY, 1996). Ou seja,
usurios mal intencionados podem inserir instrues que fazem acesso ou manipulao
de arquivos protegidos. Outro problema a padronizao da estrutura de arquivos da
distribuio Linux em questo, dependendo da distribuio em que se encontra o mdulo do kernel o local de arquivos de configurao pode ser diferente, oferecendo uma
complexidade em se encontrar o arquivo e abrindo espao para mais problemas. Deve se
lembrar que erros dentro de mdulos do kernel so devastadores, pois nesse modo de CPU
o sistema fica quase irrestrito a nvel de acesso de instrues.
Para evitar esse problema de acesso direto a arquivos de configurao o ideal a
configurao via uma aplicao no modo usurio. Para estabelecer essa comunicao existem diversas formas, podem ser utilizados os sistemas de arquivo padro Linux para informaes de processos ou para informaes de configurao, /proc e /sys respectivamente.
Tambm pode ser utilizada a famlia de sockets Netlink, especialmente desenvolvida para
comunicao entre processos nos dois modos de CPU, estritamente para uso interno (no
mesmo host). Outra forma o uso do IOCTL, uma funo que define uma forma de entrada
e sada de dados destinados a um device file 6 , onde podero ser enviados qualquer tipo
de comando com parmetros associados (SALZMAN; BURIAN; POMERANTZ, 2007,
p. 2). O IOCTL foi escolhido inicialmente pela sua simplicidade de implementao, mas
os outros mtodos ainda sero melhor estudados no decorrer do TCC 2. O Quadro 4 contm partes do cdigo que poderiam implementar as chamadas no slbcore. J o Quadro 5
contm partes de cdigo que poderiam fazer parte da implementao do slbd.
4
5
6
Anlise sinttica: <http://pt.wikipedia.org/wiki/An%C3%A1lise_sint%C3%A1tica_(computa%C3

%A7%C3%A3o)>
<http://pt.wikipedia.org/wiki/Buffer_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)>
Um arquivo que normalmente representa um dispositivo fsico, mas qualquer mdulo do kernel pode
registrar um.
74
Quadro 4 Cdigo fonte C: Chamadas IOCTL no slbcore

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// C o n s t a n t e que define o c o m a n d o de a d i c i o n a r um s e r v i d o r ( IOW =

e s c r i t a)
# define A D D _ S E R V E R _IOW ( MAGIC_CHAR , 0 , int )
// C o n s t a n t e que define o c o m a n d o listar c o n e x o e s ativas ( IOR = l e i t u r a)
# define L I S T _ A C T I V E _ C O N N _IOR ( MAGIC_CHAR , 1 , int )
static struct f i l e _ o p e r a t i o n s fops = {
. read = slbcore_read , // P o n t e i r o para funcao de c a l l b a c k da l e i t u r a
do a r q u i v o
. write = s l b c o r e _wri te , // P o n t e i r o para funcao de c a l l b a c k da
e s c r i t a do a r q u i v o
. ioctl = s l b c o r e _ioc tl , // P o n t e i r o para funcao de c a l l b a c k de uma
c h a m a d a ioctl
};
// R e g i s t r a o device file
r e g i s t e r _ c h r d e v (0 , " slb " , & fops ) ;
int s l b c o r e _ i o c t l ( struct inode * inode , struct file * filep , u n s i g n e d int
cmd , u n s i g n e d long arg ) {
int len = 200;
char buf [200];
switch ( cmd ) {
case L I S T _ A C T I V E _ C O N N :
// Aqui deve se c o l o c a r a lista de c o n e x o e s ativas na v a r i a v e l "
buf " para serem e n v i a d a s ao slbd
c o p y _ t o _ u s e r (( char *) arg , buf , 200) ;
break ;
23
case A D D _ S E R V E R :
c o p y _ f r o m _ u s e r ( buf , ( char *) arg , len ) ;
// Aqui deve se a d i c i o n a r o s e r v i d o r a lista de servidores , seu
IP : Porta e s t a r a o na v a r i a v e l " buf "
break ;
d e f a u l t:
return - ENOTTY ;
}
return len ;
24
25
26
27
28
29
30
31
32
As constantes LIST_ACTIVE_CONN_CONSTANT e ADD_SERVER_CONSTANT que esto

exemplificadas no Quadro 5 devem ser encontradas para comunicao entre os componentes, isso possvel via a impresso (printk()) do seu valor dentro do mdulo slbcore.
Outra questo que deve ser esclarecida o porqu de no existir uma comunicao
direta entre o slbcli e o slbcore. O slbcli somente um programa utilitrio, quando um
comando enviado a este utilitrio ele somente executa a sua funo e depois o seu
processo deixa de existir, ou seja, ele no um processo em background. Isso j um dos
pontos a favor da existncia do slbd como um componente intermedirio, ele possibilita
que exista um processo que represente o servio de balanceamento de carga enquanto
ele estiver ativo na mquina. Outra questo que favorece a existncia do slbd a sua
5.5. Tabela de servidores e tabela de conexes
75
Quadro 5 Cdigo fonte Python: Uso do IOCTL no slbd

1
2
import fcntl # Modulo python para m a n i p u l a r IOCTL
# Devem ser d e s c o b e r t a s as c o n s t a n t e s n u m e r i c a s que r e p r e s e n t a m os

c o m a n d o s d e f i n i d o s no s l b c o r e
LIST_ACTIVE_CONN_CONSTANT = 2983579
A D D _ S E R V E R _ C O N S T A N T = -3487538
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Abre o device file

d e v _ f i l e = open ( " / dev / slb " )
# Define o IP : Porta de um s e r v i d o r
buf = array . array ( 1 , 0 , . , 1 , 0 , . , 1 , 0 , . , 3 , : , 8 , 0
)
# Faz c h a m a d a ao c o m a n d o de a d i c i o n a r um s e r v i d o r
fcntl . ioctl ( dev_file , A D D _ S E R V E R _ CO NS TA NT , buf , 1)
# Faz c h a m a d a ao c o m a n d o de listar c o n e x o e s
buf = None
fcntl . ioctl ( dev_file , L I S T _ A C T I V E _ C O N N _ CO N ST A NT , buf , 1)
# I m p r i m e a lista de c o n e x o e s
print buf
responsabilidade de implementar a interface de comunicao com o Application Manager,

fazendo a escuta da conexo TCP para recepo de comandos de troca de estado. Sem o
slbd esta conexo no poderia ser estabelecida continuamente, j que o slbcli somente
um programa utilitrio e no um processo em background.
5.5 Tabela de servidores e tabela de conexes

Aqui entramos em um campo de discusso mais ligado as estruturas de dados que
sero utilizadas para o slbcore executar as suas funcionalidades. Existem duas principais
estruturas que devem existir:
Tabela de servidores: Esta estrutura de dados dever conter uma lista de servidores
reais atualmente administrados pelo sistema. Cada servidor possuir um campo com
o endereo IPv47 associado (o projeto inicialmente ir comportar IPs nesta verso),
e tambm ter uma lista de 1 a n servios, representados pelo nmero da porta e
pelo tipo de protocolo de transporte (TCP ou UDP).
Tabela de conexes: Esta estrutura de dados dever conter uma lista de conexes atualmente estabelecidas. Cada conexo dever possuir o IPv4 e a porta do cliente em
questo. A lista de conexes em si ser agrupada por servio de um servidor, para
7
O IP verso 4 a verso do protocolo IP mais utilizada atualmente na internet. Mas a verso 6 (IPv6)
aos poucos vem crescendo e tende a substituir o IPv4 por conta dos seus benefcios.
76
ter acesso a todas as conexes devero ser acessadas todas as listas de conexes por
servio (uma lista de listas).
Como um esboo de representao dessas estruturas na linguagem de programao
a ser utilizada, o Quadro 6 define um esboo de uma lista com possveis structs C que
sero utilizadas.
Quadro 6 Cdigo fonte C: Structs para o slbcore
1
2
3
4
5
// R e p r e s e n t a uma c o n e x a o
t y p e d e f struct {
u i n t 3 2 _ t c l i e n t _ i p 4 ; // IP do c l i e n t e
u i n t 1 6 _ t c l i e n t _ p o r t ; // Porta do c l i e n t e
} conn ;
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// R e p r e s e n t a uma lista de c o n e x o e s para um s e r v i d o r

conn * conns ; // Lista de c o n e x o e s
u i n t 1 6 _ t c o n n s _ c o u n t ; // Q u a n t i d a d e de c o n e x o e s
server * server ; // S e r v i d o r a s s o c i a d o
} c o n n _ l i s t;
// Tipo de p r o t o c o l o da camada de t r a n s p o r t e
t y p e d e f enum { TCP_PROTOCOL , U D P _ P R O T O C O L } t r a n s p _ p r o t o c o l ;
// R e p r e s e n t a uma porta
u i n t 1 6 _ t port ; // Numero da porta
t r a n s p _ p r o t o c o l proto ; // Qual p r o t o c o l o ( TCP ou UDP )
c o n n _ l i s t * c o n n _ l i s t; // Lista de c o n e x o e s a s s o c i a d a s ao s e r v i c o
} s e r v i c e;
// R e p r e s e n t a um s e r v i d o r real
u i n t 3 2 _ t ip4 ; // IP do s e r v i d o r real
s e r v i c e * s e r v i c e s; // Array de s e r v i c o s do s e r v i d o r real
u i n t 1 6 _ t s e r v i c e s _ c o u n t ; // Q u a n t i d a d e de s e r v i c o s do s e r v i d o r real
} server ;
30
31
32
33
34
35
36
37
38
39
40
41
// R e p r e s e n t a todos os s e r v i d o r e s reais
server * s e r v e r s; // Lista de s e r v i d o r e s reais
u i n t 1 6 _ t s e r v e r s _ c o u n t ; // Q u a n t i d a d e de s e r v i d o r e s reais
} server_table;
// R e p r e s e n t a todos as c o n e x o e s
c o n n _ l i s t ** c o n n _ l i s t s _ l i s t ; // Uma lista de listas de c o n e x o e s
u i n t 1 6 _ t c o n n _ l i s t s _ l i s t _ c o u n t ; // Q u a n t i d a d e de listas de c o n e x o e s
} c o n n _ t a b l e;
Essas estruturas servem somente como esboo para demonstrao dos dados que
devero ser mantidos e manipulados. Uma real implementao iria requerer o uso de estruturas de dados auxiliares mais complexas, como listas ligadas, tabelas hash e vetores,
5.6. Persistncia de sesso
77
fazendo escolhas de qual usar de acordo com as necessidades de uso dos dados, por exemplo, caso existam remoes constante de elementos de uma estrutura, recomendado o
uso de listas ligadas ao invs de vetores, ou se existe uma iterao contgua constante sobre
elementos de uma estrutura, recomendado o uso de vetores ao invs de listas ligadas.
Alm do problema da escolha das estruturas auxiliares, tambm ser necessrio
estabelecer uma forte poltica de alocao e desalocao de memria para as estruturas,
pois algumas delas teriam referencias cruzadas (e.g. Servidor tem uma lista de servios,
servio tem uma lista de conexes, conexo est associada a um servidor), uma desalocao de memria poderia levar uma outra estrutura que tinha referncia a ela agora
referenciar uma rea de memria indevida, podendo levar a falhas de segmentao. Uma
m desalocao de memria tambm poderia resultar em vazamentos de memria, que
so reas da memria devidamente alocadas, mas que no possuem atualmente nenhuma
referncia a ela, ou seja, a rea fica reservada e inutilizvel (LEVY, 1996).
5.6 Persistncia de sesso

Um dos maiores problemas que os balanceadores de carga devem superar o fato
das sesses de clientes. Existem diversas aplicaes que atualmente so dependentes de
uma sesso, estas so denominadas aplicaes stateful, um exemplo uma loja online onde
o usurio possui um carrinho de compras, as informaes sobre este carrinho de compras
so mantidas em memria RAM pelo servidor (memria voltil), ou seja, no so inseridas
em uma base de dados persistente. Caso este servio esteja replicado em vrios servidores
reais da soluo de balanceamento de carga, quando um usurio se realizar uma requisio
(e.g. uma pgina web) ele ser destinado a um servidor real, mas quando ele efetuar outra
requisio (e.g. outra pgina web) ele corre o risco de ser destinado a outro servidor real
(dependendo da deciso do algoritmo de escalonamento), caso o usurio tenha solicitado
a compra de um produto e este foi adicionado ao seu carrinho de compras virtual, ao ser
enviado para outro servidor ele perderia essa informao. Ento o ideal que um usurio
mantenha a sua conexo com um nico servidor para evitar problemas de perda da sesso.
Um fato que deve ser levado em considerao que o TCP um protocolo nativamente orientando a conexo, j o UDP no. Mas mesmo o UDP no sendo orientado a
conexo, os protocolos da camada de aplicao que fazem uso do UDP podem determinar
mecanismos de estabelecimento de uma sesso, fazendo que at mesmo segmentos UDP
vindos de um mesmo usurio, tenham a necessidade de serem enviados para um nico
servidor.
De acordo com Kopparapu (2002, p. 53), existem meios de contornar este problema,
um deles a persistncia de sesso baseada em IP, que ser o mtodo implementado no
slbd para amenizar o problema. Este mtodo relativamente simples, ele determina que
78
ao chegar uma nova requisio de um cliente, deve ser verificado se ele j possui uma
recente conexo estabelecida com algum servidor (acessado via a tabela de conexes),
caso ele possua alguma a requisio ser enviada ao servidor em questo, caso no possua
a requisio ser enviada a algum servidor selecionado pelo algoritmo de escalonamento.
Infelizmente o mtodo de persistncia baseado em IP no infalvel, Kopparapu
(2002, p. 58) descreve o problema deste mtodo com proxies de rede. Um proxy um servidor que atua como intermedirio de um grupo de usurios a uma rede externa para melhorar a segurana (firewall) e desempenho (caching). Este grupo de usurios ao fazerem
requisies a uma rede externa so representados externamente pelo proxy, consequentemente este ir fazer um processo de NAT para que as requisies tenham como remetente
o seu endereo. Caso usurios de um mesmo proxy faam requisies ao servio de balanceamento de carga, todos os n usurios tero o mesmo IP de remetente (o IP do proxy
que os representa), o que poder sobrecarregar um servidor real, que receber um grande
nmero de requisies de diferentes usurios por causa da persistncia de sesso. Existem
alguns meios de contornar parte deste problema, mas devido as suas complexidades de
implementao eles no sero trabalhados neste projeto.
5.7 Interceptao e manipulao de pacotes

A partir do da verso 2.3.X do kernel do Linux foi inserida uns dos mais importantes componentes do kernel se tratando de redes. O projeto desenvolvido por Russel e Welte
(2002), teve a inteno de definir novas formas de filtragem e manipulao de pacotes de
rede em sistemas Linux. Foi desenvolvido um grande framework para manipulao de pacotes chamado de Netfilter, totalmente integrado a implementao da pilha de protocolos
TCP/IP do sistema, e junto a ele foram desenvolvidos mdulos do kernel e aplicativos
utilitrios para exercer a funcionalidade de firewall, como o iptables e o arptables.
Dentro deste framework foram definidos vrios hooks (ganchos), que so pontos
bem definidos na travessia de pacotes da pilha de protocolos do sistema. Cada protocolo
define os seus hooks, e possibilitam que funes de callback sejam registradas a eles,
possibilitando que um mdulo do kernel tenha acesso aos pacotes que atravessam a pilha
de protocolos no hook registrado em questo. Ao ter acesso aos pacotes de rede, podem ser
efetuadas alteraes e ainda podem ser dadas instrues ao netfilter sobre o que deve ser
feito com o pacote a partir do retorno da funo de callback (RUSSEL; WELTE, 2002).
A seguir as cinco constantes que podem servir como retorno de funo, seguido dos seus
respectivos efeitos:
NF_ACCEPT: O pacote continua a sua travessia normalmente;
NF_DROP: O pacote ser descartado;
5.7. Interceptao e manipulao de pacotes
79
NF_STOLEN: O pacote dever ser esquecido pelo netfilter, o responsvel pelo seu
destino agora ser do prprio mdulo.;
NF_QUEUE: O pacote deve ser enfileirado para uso de aplicativos no modo usurio
de CPU;
NF_REPEAT: Esse hook com este mesmo pacote em questo dever ser chamado
novamente.
Para registrar um hook necessrio informar alguns dados ao framework netfilter,
estes dados so passados via a struct nf_hook_ops, que possui o formato do cdigo no
Quadro 7.
Quadro 7 Cdigo fonte C: Struct de cofigurao de um hook
1
2
3
4
5
6
7
8
struct n f _ h o o k _ o p s
{
struct l i s t _ h e a d list ; // Nao deve ser p r e e n c h i d o
n f _ h o o k f n * hook ; // P o n t e i r o para a funcao que ira r e g i s t r a r o hook
int pf ; // A f a m i l i a do p r o t o c o l o de rede
int h o o k n u m; // O i d e n t i f i c a d o r do tipo de hook
int p r i o r i t y; // P r i o r i d a d e do hook
};
Cada um dos campos sero explicados para melhor entendimento do funcionamento do netfilter. O primeiro campo hook um ponteiro para uma funo implementada
no prprio mdulo do kernel, ela ser a funo de callback que ir receber os pacotes
de rede. O netfilter define um prottipo para essa funo com o formato do cdigo no
Quadro 8.
Quadro 8 Cdigo fonte C: Prottipo de funo para registrar um hook
1
2
3
4
5
u n s i g n e d int h o o k _ f u n c t i o n _ n a m e ( u n s i g n e d int hooknum ,

struct s k _ b u f f ** skb ,
const struct n e t _ d e v i c e * in ,
const struct n e t _ d e v i c e * out ,
int (* okfn ) ( struct s k _ b u f f *) ) ;
A seguir a descrio de cada parmetro:

hooknum: Tipo de hook (ser melhor explicado adiante);
skb: Estrutura que contm o pacote, ou conjunto de pacotes a serem manipulados. Seu
contedo mutvel de acordo com a camada de rede em que se encontra, por conta
de estruturas union que ele contm;
80
in: Ponteiro para a estrutura que representa a interface de rede em que o pacote chegou ao
host (e.g eth0). Vlido para pacotes que acabaram de chegar, seno far referncia
a NULLl;
out: Ponteiro para a estrutura que representa a interface de rede em que o pacote ser
destinado para sair do host (e.g eth0), o que foi definido aps roteamento do mesmo.
Vlido para pacotes que esto para sair, seno far referncia a NULL;
okfn: Ponteiro para uma funo que ser invocada caso todas as funes de callback
registradas ao hook em questo retornem NF_ACCEPT.
Dentro da funo hook_function_name que poder ser feita a manipulao e filtragem dos pacotes de rede. O prximo campo da estrutura principal o pf, que faz
uma simples referncia a famlia do protocolo que est sendo trabalhado, PF_INET para
IPv4 e PF_INET6 para IPv6, no caso do slbcore o pf ser a princpio PF_INET. O prximo
campo o hooknum, este um dos mais importantes pois define qual tipo de hook ser
trabalhada na funo de callback, definindo em que ponto da travessia de rede o pacote
ficar acessvel. A Figura 16 define os cinco hooks acessveis da travessia. A descrio de
cada hook e cada evento da travessia vir a seguir.
Figura 16 Tipos de hook com possibilidade de registro

Fonte: Wehrle et al. (2004). Adaptado pelo autor.
0. O pacote chega em uma interface de rede de entrada do host;

1. O primeiro hook, antes do roteamento inicial possvel acessar o pacote;
2. Ocorre o roteamento do pacote;
3. O segundo hook, analisado que o pacote se destina ao host em questo e antes
dele ser processado possvel acess-lo;
5.7. Interceptao e manipulao de pacotes
81
4. O pacote processado pelas aplicaes do host a quais ele era destinado;

5. O terceiro hook, aps o processamento do pacote no host ele pode ser acessado;
6. Ocorre o roteamento de sada do pacote processado no host;
7. O quarto hook, analisado que o pacote no se destina ao host em questo, e antes
dele ser repassado (i.e. forwarded) possvel acess-lo;
8. O quinto hook, o pacote est de sada do host e antes disso possvel acess-lo;
9. O pacote chega a interface de rede de sada do host.
No caso do slbcore o que se deseja realizar um DNAT (Destination Network
Adress Translation), ou seja, o endereo de destino do pacote de rede ser alterado e
repassado para o roteamento (onde ser enviado ao servidor real escolhido). A realizao
do DNAT sempre dever ocorrer na chegada do pacote a rede, para isso o seu acesso via
o netfilter dever ser feito pelos hooks NF_IP_PRE_ROUTING ou NF_IP_LOCAL_IN. Como
no desejado que o pacote seja processado por nenhuma aplicao dentro do servidor de
balanceamento de carga, necessrio que ele seja acessado antes do roteamento ocorrer,
pois ele ser destinado a este fim j que o IP de destinatrio o VIP. Ento ser utilizado
o hook NF_IP_PRE_ROUTING.
O prximo campo da estrutura de configurao nf_hook_ops o priority, esse
campo indica qual a prioridade de acesso do hook ao pacote em questo, pois em um
mesmo host podem existir diversos mdulos do kernel com hooks definidos. Ento quanto
maior a prioridade de acesso prvio a um pacote dever ser indicado pela constante
NF_IP_PRI_FIRST, e no caso de existir uma prioridade mnima de acesso poder ser
indicado pela constante NF_IP_PRI_LAST. Entre essas duas constantes existem outras
que definem prioridades intermedirias.
Com o preenchimento dos campos da estrutura nf_hook_ops j possvel fazer
um simples mdulo netfilter. Para realizar uma pequena demonstrao de uso, foi feito
um esboo no Quadro 9 que une algumas partes de cdigo C e pseudocdigo para melhor
visualizao do sua utilizao.
82
Quadro 9 Cdigo fonte C: Exemplo de um mdulo netfilter simples

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Funcao que r e a l i z a o b a l a n c e a m e n t o
int p r o c e s s _ s e g m e n t ( struct s k _ b u f f * skb ) {
// V e r i f i c a se eh o pacote eh valido
if (! skb ) return N F _ A C C E P T ;
if (!( skb - > nh . iph ) ) return N F _ A C C E P T ;
struct tcphdr * tcp = NULL ;
struct iphdr * iph = NULL ;
iphdr = ip_hdr ( skb ) ;
if ( iph - > p r o t o c o l == I P P R O T O _ T C P) {
tcphdr = t c p _ h d r( skb ) ;
u i n t 1 6 _ t dport = tcphdr - > t h _ d p o r t;
// ...
// V e r i f i c a se algum s e r v i d o r real contem o s e r v i c o com " dport "
// Se nao e x i s t i r eh dado um " return N F _ D R O P ;"
// ...
// Caso existam , eh feito o e s c a l o n a m e n t o de qual s e r v i d o r sera
o responsavel
u i n t 3 2 _ t r e a l s e r v e r _ i p = s c h e d u l i n g _ a l g o r i t h m () ;
20
21
22
23
24
25
26
iphdr - > daddr = r e a l s e r v e r _ i p ;

// Refaz os c h e c k s u m s
iphdr - > check = c h e c k s u m( iphdr ) ;
tcphdr - > th_sum = c h e c k s u m( tcphdr ) ;
} else if ( iph - > p r o t o c o l == ...) { // Outros p r o t o c o l o s de t r a n s p o r t e
...
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
}
return N F _ A C C E P T;
}
// Funcao de c a l l b a c k para o hook
static u_int s l b c o r e _ h o o k _ f n ( u_int hooknum ,
struct s k _ b u f f ** skb ,
const struct n e t _ d e v i c e * in ,
const struct n e t _ d e v i c e * out ,
int (* okfn ) ( struct s k _ b u f f *) ) {
// V e r i f i c a se o pacote chega pela i n t e r f a c e do VIP
// se nao vier desta o pacote s e g u i r a o seu c a m i n h o
if ( strcmp ( in - > name , " eth0 " ) != 0) {
return N F _ A C C E P T;
}
return p r o c e s s _ s e g m e n t (* skb ) ;
}
// Funcao de i n i c i a l i z a c a o do modulo
struct n f _ h o o k _ o p s s l b c o r e _ n f h _ o p s ;
static int __init s l b c o r e _ i n i t () {
// C o n f i g u r a o hook
s l b c o r e _ n f h _ o p s . hook = s l b c o r e _ h o o k _ f n ;
slbcore_nfh_ops. hooknum = NF_IP_PRE_ROUTING;
s l b c o r e _ n f h _ o p s . pf = P F _ I N E T;
slbcore_nfh_ops. priority = NF_IP_PRI_FIRST;
// R e g i s t r a o hook
n f _ r e g i s t e r _ h o o k (& s l b c o r e _ n f h _ o p s ) ;
return 0;
}
83
6 Concluso
Por intermdio deste trabalho de concluso de curso foi possvel realizar um estudo
sobre diversas reas da computao que tangem desde redes de computadores, sistemas
operacionais, engenharia de software e outras. Todo este estudo foi necessrio para se
obter maior entendimento sobre ferramentas de balanceamento de carga de servidores,
deste o seu histrico de uso, suas principais funcionalidades, benefcios e sua arquitetura
geral.
Na introduo deste trabalho foi indicada a motivao real da implementao desta
ferramenta, e na concluso deve ser feita uma reafirmao da importncia que este tipo
de produto tem no mundo hoje. O uso de balanceadores de carga uma das formas de
garantia de desempenho, disponibilidade e confiabilidade de servios, e juntamente com
outros tipos de solues forma uma estrutura bsica de uma infraestrutura de TI que visa
oferecer estes servios a um grande nmero de usurios sem pecar com a sua qualidade a
um nvel tcnico.
Para fins de pesquisa e desenvolvimento foi feito o projeto de uma soluo original
de balanceamento de carga, tendo como participantes os presentes autor e orientador deste
trabalho. A soluo proposta conseguiu atingir dois nveis de projeto que iro proporcionar
a base de uma futura implementao, foi atingido um nvel arquitetural, mais genrico
e mais abstrato, onde foram definidos, descritos e relacionados todos os componentes
que iro agregar a soluo de balanceamento de carga, com a viso de sua organizao
lgica e com a viso de sua disposio fsica. Outro nvel de projeto atingido foi um nvel
mais detalhado, mais especfico e concreto, onde foram levantados e descritos importantes
problemas que deveriam ser solucionados para se tornar vivel a futura implementao do
balanceador de carga. Estes resultados alcanados conseguem demonstrar que os objetivos
deste trabalho foram atingidos.
6.1 Trabalhos futuros

O contexto desse projeto foi a disciplina de Trabalho de Concluso de Curso 1,
do curso de Engenharia de Software da Universidade de Braslia. A continuao deste
trabalho ser realizado na disciplina de Trabalho de Concluso de Curso 2, e o objetivo
geral deste trabalho futuro ser a real implementao do balanceador de carga em conjunto
com a criao de uma sute de testes para verificao de suas funcionalidades. Todo o
projeto da soluo realizado neste trabalho atual dever servir como base para a futura
implementao.
84
Captulo 6. Concluso
A partir do conhecimento adquirido possvel definir uma estrutura de trabalho

a ser utilizada no TCC2, mesmo sabendo-se que provavelmente sofrer alteraes no
decorrer da execuo. A seguir uma estrutura cronolgica:
1. Configurao de um ambiente de desenvolvimento da soluo (Computadores, mquinas virtuais, roteadores, switches e cabeamento). Esforo = 3.
2. Implementao e testes do componente cluster-monitor. Esforo = 8.
3. Implementao e testes do componente scheduling-algorithms. Esforo = 3.
4. Implementao e testes do componente slbcore (com uma configurao totalmente
esttica). Esforo = 13.
5. Implementao da integrao e realizao de testes de integrao entre o slbcore,
cluster-monitor e scheduling-algorithms. Esforo = 8.
6. Implementao e testes do componente slbd (com execuo de comandos pr-definidos).
Esforo = 8.
7. Implementao da integrao e realizao de testes de integrao entre o slbd e
slbcore. Esforo = 5.
8. Implementao e testes do componente slbcli. Esforo = 3.
9. Implementao da integrao e realizao de testes de integrao entre o slbcli e
slbd. Esforo = 2.
10. Implementao e testes do configuration-synchronizer. Esforo = 1.
11. Implementao da integrao e realizao de testes de integrao entre o Application
Manager e slbd. Esforo = 13.
12. Realizao de testes de sistema e testes de aceitao para verificao e validao de
toda a soluo. Esforo = 8.
Para estimativa de esforo foi definido o valor 1 a atividade com menor complexidade (nmero 10), depois foram estimados valores proporcionais a este usando nmeros da
sequncia de Fibonacci1 , levando em considerao a complexidade das outras atividades.
Exemplo: 0, 1, 1, 2,
%AAncia_de_Fibonacci>)
3,
5,
8,
13,
21,
...(<http://pt.wikipedia.org/wiki/Sequ%C3
85
Referncias
ATWOOD, J. Understanding User and Kernel Mode. 2008. Blog Coding Horror.
Disponvel em: <http://blog.codinghorror.com/understanding-user-and-kernel-mode/>.
Citado na pgina 30.
BENVENUTI, C. Understanding Linux Network Internals. 1. ed. EUA: OReilly, 2005.
Citado 2 vezes nas pginas 68 e 69.
BOURKE, T. Server Load Balancing. 1. ed. EUA: OReilly, 2001. Citado 5 vezes nas
pginas 25, 35, 37, 39 e 52.
BOVET, D. P.; CESATI, M. Understanding the Linux Kernel. EUA: OReilly, 2000.
CASAVANT, T. L.; KUHL, J. G. A taxonomy of scheduling in general-purpose
distributed computing systems. Software Engineering, IEEE Transactions, v. 14, n. 2,
1988. Citado na pgina 44.
CISCO SYSTEMS. Cisco ASA 5500 Series Configuration Guide using the CLI. 8.2. ed.
[S.l.], 2010. Cap. 33. Disponvel em: <http://www.cisco.com/c/en/us/td/docs/security/
asa/asa82/configuration/guide/config.html>. Citado na pgina 48.
COMER, D. E. Internetworking with TCP/IP: Principles, Protocol, and Architecture. 6.
ed. New Jersey, EUA: Pearson, 2013. Citado 2 vezes nas pginas 28 e 53.
FREE SOFTWARE FOUNDATION. What is free software? 2014. Verso 1.135.
Disponvel em: <https://www.gnu.org/philosophy/free-sw.en.html>. Citado na pgina
29.
GARLAN, D.; SHAW, M. An introduction to software architecture. Advances in
Software Engineering and Knowledge Engineering, v. 1, 1994. Citado na pgina 51.
HORMAN, S. Linux Virtual Server Tutorial. 2003. Ultra Monkey Project. Disponvel
em: <http://www.ultramonkey.org/papers/lvs_tutorial/html/>. Citado na pgina 54.
IBM RATIONAL SOFTWARE. Rational Unified Process (RUP): Diretrizes de um
Documento de Arquitetura de Software. 2001. Disponvel em: <http://www.wthreex.
com/rup/portugues/process/modguide/md_sad.htm>. Citado 4 vezes nas pginas 51,
57, 62 e 65.
JAYASWAL, K. Administering Data Centers: Servers, Storage, and Voice over IP.
Indianapolis, EUA: Wiley, 2006. Citado 4 vezes nas pginas 25, 46, 47 e 48.
KARIMI, A. et al. A new fuzzy approach for dynamic load balancing algorithm.
International Journal of Computer Science and Information Security (IJCSIS), v. 6,
n. 1, 2009. Citado na pgina 32.
KOPPARAPU, C. Load Balancing Servers, Firewalls, and Caches. New York, EUA:
Wiley, 2002. Citado 6 vezes nas pginas 47, 67, 70, 72, 77 e 78.
86
Referncias
KROAH-HARTMAN, G. Things you never should do in the kernel. Linux Journal,

n. 133, 2005. Citado na pgina 73.
LARANJEIRA, L. A. F. Manuteno e Evoluo de Software: Aula 3A, Apresentao do
Trabalho. 2011. Universidade de Braslia, Faculdade UnB Gama. 21 slides. Citado 4
vezes nas pginas 56, 61, 62 e 91.
LEVY, E. Smashing the stack for fun and profit. Phrack Magazine, v. 7, n. 49, 1996.
MADHURAVANI, P.; SUMALATHA, G.; SHANMUKHI, M. An emperical study of
static and dynamic load balancing algorithms in parallel and distributed computing
environment. International Journal of Emerging trends in Engineering and Development,
v. 3, n. 2, 2012. Citado 3 vezes nas pginas 45, 46 e 56.
NATRIO, R. Load Balancing III. 2011. Blog Network and Servers. Disponvel em:
<http://networksandservers.blogspot.com.br/2011/03/balancing-iii.html>. Citado na
pgina 39.
RUSSEL, R.; WELTE, H. Linux netfilter Hacking HOWTO. 2002. Rev. 521. Disponvel
em: <http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.
html>. Citado 2 vezes nas pginas 32 e 78.
SALZMAN, P. J.; BURIAN, M.; POMERANTZ, O. The Linux Kernel Module
Programming Guide. 2007. Verso 2.6.4. Linux Documentation Project. Citado 2 vezes
nas pginas 31 e 73.
SHARMA, S.; SINGH, S.; SHARMA, M. Performance analysis of load balancing
algorithms. World Academy of Science, Engineering and Technology, n. 38, 2008. Citado
na pgina 34.
STATISTIC BRAIN. Google Annual Search Statistics. 2014. Disponvel em: <http://
www.statisticbrain.com/google-searches/>. Citado na pgina 21.
TANENBAUM, A. S. Redes de Computadores. Trad. 4. ed. So Paulo: Campus Elsevier,
2003. Citado 2 vezes nas pginas 26 e 27.
TIOBE SOFTWARE. TIOBE Programming Community Index. 2014. Disponvel em:
<http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. Citado na
pgina 55.
TORVALDS, L. Re: Compiling C++ kernel module + Makefile. 2004. Mensagem enviada
a lista de e-mails em 19 janeiro 2004. Disponvel em: <https://groups.google.com/
forum/#!forum/fa.linux.kernel>. Citado na pgina 54.
W3SCHOOLS. OS Platform Statistics. 2014. Disponvel em: <http://www.w3schools.
com/browsers/browsers_os.asp>. Citado na pgina 29.
WEHRLE, K. et al. The Linux Networking Architecture: Design and Implementation of
Network Protocols in the Linux Kernel. EUA: Prentice Hall, 2004. Citado na pgina 80.
WIKIPEDIA. Internet protocol suite Wikipedia, The Free Encyclopedia. 2014.
Disponvel em: <http://en.wikipedia.org/wiki/Internet_protocol_suite>. Citado na
pgina 28.
Referncias
87
ZHANG, W. Linux virtual server for scalable network services. National Key Laboratory
of Parallel and Distributed Processing, 2000. The Linux Virtual Server Project. Citado
6 vezes nas pginas 39, 40, 41, 42, 43 e 44.
Apndices
91
APNDICE A Lista de comandos do amcli
A seguir uma lista comandos do componente amcli do Application Manager e seus

respectivos efeitos (LARANJEIRA, 2011):
START: Inicia a aplicao em um ou dois hosts.
RESTART: Fecha e recomea a aplicao (exceto se ela for ACTIVE e no houver uma verso
STANDBY)
SHUTDOWN: Fecha a aplicao (exceto se ela for ACTIVE e no houver uma verso STANDBY)
SWITCH: Reverte o estado da aplicao (ACTIVE e STANDBY)
RELOAD: Recarrega o arquivo de configurao esttica da aplicao.
TEST: Faz com que a instncia STANDBY da aplicao mude para MAINTENANCE.
UNTEST: Faz com que a instncia MAINTENANCE da aplicao mude para STANDBY.
PRIMARY: Muda a instncia da aplicao que no PRIMARY para PRIMARY (no arquivo
de configurao).
ENABLE: Muda a instncia da aplicao que MAINTENANCE para STANDBY e a libera
para se tornar ACTIVE caso a dual falhe (mudando o valor no arquivo de configurao
dinmica UNINHIBITED)
DISABLE: Muda a instncia da aplicao que STANDBY para MAINTENANCE e a restringe para no se tornar ACTIVE caso a dual falhe (mudando o valor no arquivo de
configurao dinmica para INHIBITED)
INHIBIT: Restringe a instncia da aplic. a no se tornar ACTIVE (caso seja STANDBY e a
dual falhe) mudando o valor no arquivo de configurao dinmica para INHIBITED.
UNINHIBIT: Libera a instncia da aplic. para se tornar ACTIVE (caso seja STANDBY e a
dual falhe) mudando o valor no arquivo de configurao dinmica para UNINHIBITED.
GETPID: Solicita o PID de um processo especfico da instncia local da aplicao.
KILLPROC: Executa o comando Unix/Linux kill -0 sobre um processo especfico de uma
aplicao.
KILLRM: Executa o comando Unix/Linux kill -0 sobre o AppMgr que roda em um dado host.
92
APNDICE A. Lista de comandos do amcli
QUERY: Solicita o estado da aplicao (das duas instncias)

REBOOT: Fecha e recomea a aplicao (exceto se ela for ACTIVE e no houver uma verso
STANDBY)
SHUTDOWN-F: Fecha a instncia da aplicao mesmo se ela for ACTIVE e a outra no for
STANDBY.
DISABLE-F: Muda a instncia da aplicao para o estado MAINTENANCE mesmo se ela
for ACTIVE.
RESTART-F: Fecha e recomea a instncia da aplic. mesmo se ela for ACTIVE e no houver
STANDBY.

TCC1

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TCC1

Hochgeladen von

Copyright:

Verfügbare Formate

Universidade de Braslia - UnB

Faculdade UnB Gama - FGA

Projeto de um balanceador de carga de

Autor: Matheus Souza Fonseca

Matheus Souza Fonseca

Projeto de um balanceador de carga de servidores

Monografia submetida ao curso de graduao

Universidade de Braslia - UnB

Orientador: Prof. Dr. Luiz Augusto Fontes Laranjeira

Matheus Souza Fonseca

Projeto de um balanceador de carga de servidores

Monografia submetida ao curso de graduao

Trabalho aprovado. Braslia, DF, 16 de Junho de 2014:

Prof. Dr. Luiz Augusto Fontes

Prof. Dra. Carla Silva Rocha Aguiar

Prof. Dr. Andr Barros de Sales

Este trabalho dedicado a todas as pessoas que participaram diretamente

"No force o crescimento, elimine os fatores que o limitam."

Lista de abreviaturas e siglas

Trabalho de Concluso de Curso

Application Specific Integrated Circuits

Application Programming Interface

Open Systems Interconnection

Virtual Internet Protocol

Transmission Control Protocol

User Datagram Protocol

Protocol Data Unit

International Organization for Standardization

Internet Control Message Protocol

GNU Public License

Central Processing Unit

Random Access Memory

Domain Name System

Keep It Simple, Stupid

Network address translation

Hypertext Transfer Protocol

Local Area Network

Command Line Interface

Linux Virtual Server

Modos de CPU (kernel e usurio) . . . . . . . . . . . . . . . . . . . . . 30

Balanceamento de carga de servidores . . . . . . . . . . . . . . . . . . . 32

Definio e tipos de balanceamento . . . . . . . . . . . . . . . . . . . . 32

Arquitetura de um balanceador de carga de servidores . . . . . . . . 37

Camada de rede de atuao (modelo OSI) . . . . . . . . . . . . . . . . . 38

Retorno de trfego via NAT . . . . . . . . . . . . . . . . . . . . . . . . 39

Retorno de trfego via tunelamento IP . . . . . . . . . . . . . . . . . . . 41

Retorno de trfego via DR . . . . . . . . . . . . . . . . . . . . . . . . . 42

Comparao entre as tcnicas de retorno de trfego

Tecnologias e tcnicas utilizadas . . . . . . . . . . . . . . . . . . . . . . 52

Detalhes tcnicos da soluo . . . . . . . . . . . . . . . . . . . . . . 67

Tabela de servidores e tabela de conexes . . . . . . . . . . . . . . . . . 75

Interceptao e manipulao de pacotes . . . . . . . . . . . . . . . . . . 78

O balanceamento de carga em servidores uma possvel soluo definitiva para

1.2 Objetivo geral

1.3 Objetivos especficos

1.4. Estrutura do trabalho

Realizar projeto de integrao do software a ser desenvolvido (balanceador de carga)

1.4 Estrutura do trabalho

1.5 Metodologia de trabalho

1.5.1 Cronograma do trabalho

Figura 1 Cronograma do TCC1

2.1 Terminologia bsica

Captulo 2. Fundamentao terica

Camada de rede: Uma camada de rede um componente de uma arquitetura de um