TCC1 MatheusFonseca PDF

Universidade de Braslia - UnB
Faculdade UnB Gama - FGA

Engenharia de Software
Projeto de um balanceador de carga de
servidores convel 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
convel para sistemas Linux
Monograa submetida ao curso de graduao
em Engenharia de Software da Universidade
de Braslia, como requisito parcial para ob-
teno 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
convel para sistemas Linux
Monograa submetida ao curso de graduao
em Engenharia de Software da Universidade
de Braslia, como requisito parcial para ob-
teno 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 ser-
vios 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 orga-
nizaes precisam atender importantes requisitos para alcanar a satisfao do usurio,
dentre os requisitos se encontram o desempenho, escalabilidade, conabilidade e dispo-
nibilidade. Para tentar suprir estes requisitos esto sendo continuamente desenvolvidas
solues em hardware e software, dentre elas existe o Balanceamento de carga de servi-
dores, 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 traba-
lho 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 servi-
dores simplicado 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 Netlter, um framework nativo do kernel do Linux para manipulao de
pacotes de rede.
Palavras-chaves: balanceamento de carga. algoritmo de escalonamento. linux. netlter.
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 simplied 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 Netlter, a
native Linux kernel framework for handling network packets.
Key-words: load balancing. scheduling algorithm. linux. netlter.
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 Congurao 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 cogurao 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 netlter simples . . . . . . . 82
Lista de abreviaturas e siglas
TCC Trabalho de Concluso de Curso
ASICs Application Specic 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 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Metodologia de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5.1 Cronograma do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 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 Netlter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Balanceamento de carga de servidores . . . . . . . . . . . . . . . . . . . 32
2.4.1 Denio e tipos de balanceamento . . . . . . . . . . . . . . . . . . . . 32
2.4.2 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.3 Benefcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 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 . . . . . . . . . . . 44
3.3 Algoritmos de escalonamento . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Redundncia do servio . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Projeto arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Representao da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Tecnologias e tcnicas utilizadas . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Viso lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 Viso de implantao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Restries de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Detalhes tcnicos da soluo . . . . . . . . . . . . . . . . . . . . . . 67
5.1 Congurao da rede de computadores . . . . . . . . . . . . . . . . . . 67
5.2 Monitoramento do cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Processo de failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 Comunicao entre slbd e slbcore . . . . . . . . . . . . . . . . . . . . . 73
5.5 Tabela de servidores e tabela de conexes . . . . . . . . . . . . . . . . . 75
5.6 Persistncia de sesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.7 Interceptao e manipulao de pacotes . . . . . . . . . . . . . . . . . . 78
6 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Apndices 89
APNDICE A Lista de comandos do amcli . . . . . . . . . . . . 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 diaria-
mente realizadas desde simples conversas entre pessoas, at transaes nanceiras 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 uxo 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 mo-
tivou 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 Justicativa
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 car indisponvel;
Se for optado pelo aumento dos recursos do servidor (e.g. memria RAM, proces-
samento, 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 denitiva 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 Specic 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 CSS
1
, o Alteon NG Load Balancer
2
e o F5 LTM
3
. J em relao as solues base-
adas somente em software, que operam sobre sistemas operacionais padres (e.g. Debian
Linux
4
, Red Hat ES
5
, Windows Server
6
, etc), existem verses pagas, gratuitas e at livres,
exemplos de solues so o LVS (Linux Virtual Server)
7
e o HAProxy
8
(softwares livres).
O trabalho ca justicado pelo seu m 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 denir o projeto de um sistema de balan-
ceamento de carga de servidores convel, sendo a sua plataforma de execuo sistemas
operacionais baseados em Linux.
1.3 Objetivos especcos
Levantar material bibliogrco para suporte a toda a pesquisa e desenvolvimento
relacionado a este trabalho;
Desenvolver a arquitetura geral de uma soluo de balanceamento de carga, de-
nindo as tecnologias a serem utilizadas, como: Linguagem de programao, plata-
forma 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 congurao do
sistema, etc.
1
<http://www.cisco.com/go/css11500/>
2
<http://www.radware.com/Products/Alteon/>
3
<https://f5.com/products/modules/local-trac-manager>
4
<https://www.debian.org/>
5
<http://br.redhat.com/products/enterprise-linux/>
6
<http://www.microsoft.com/pt-br/server-cloud/products/windows-server-2012-r2/>
7
<http://www.linuxvirtualserver.org/>
8
<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 reali-
zao 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 especcos sobre balanceamento de carga. No captulo 4
fornecida uma viso alto nvel (generalista) da soluo que est sendo proposta, de-
monstrando os componentes da arquitetura do balanceador de cargas. J o captulo 5
responsvel por fornecer detalhes tcnicos sobre como podero ser implementadas de-
terminadas 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 justi-
cativa do projeto da soluo. Somente assuntos com maior recorrncia sero trabalhados
aqui, caso um determinado assunto pertinente no seja explicado neste captulo, signica
que ele ser abordado diretamente nos posteriores.
2.1 Terminologia bsica
Neste trabalho surgiro diversos termos que sero recorrentemente citados e devem
ter signicados esclarecidos para no haver interpretaes incorretas. Ressalta-se que estes
termos possuem estes signicados no domnio deste trabalho (balanceamento de carga),
em outros domnios eles podem ter outros signicados. 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 aglo-
merado de servidores independentes, trabalhando em conjunto como um sistema
nico. Neste trabalho o cluster de servidores ser a representao de todos os servi-
dores 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 se-
cundrio/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 operaci-
onal. 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 tro-
cadas 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 signicado mais amplo.
2.2 Protocolos de rede
Logo aps o comeo da pesquisa e desenvolvimento em redes de computadores
1
, 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
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 caria responsvel por resolver um pequeno conjunto de
problemas (princpio de Dividir para conquistar
2
).
Estes componentes foram organizados de uma forma hierrquica, formando uma
pilha de camadas, umas sobre as outras. Cada camada tem a funo de fornecer deter-
minados 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 uxo 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 Inter-
connection), um modelo de referncia publicado pela ISO
3
(International Organization for
Standardization) que determina sete camadas e seus objetivos (seguindo a lgica proposta
1
Ocorreu em meados da dcada de 1960, resultando na rede ARPANET.
2
<http://pt.wikipedia.org/wiki/Divis%C3%A3o_e_conquista>
3
Organizao internacional de padronizao: <http://www.iso.org/iso/>
2.2. Protocolos de rede 27
Figura 2 Camadas de rede
na seo anterior). Este somente um modelo conceitual e no um guia de implemen-
tao, 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 bra tica, etc);
2. Enlace de dados: Transformar a transmisso de dados em algo mais convel,
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 sub-
redes 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 comu-
nicam 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.
2.2.2 Pilha TCP/IP
Diferentemente do modelo de referncia OSI, que foi denido inicialmente por um
grupo de trabalho da ISO antes mesmo de qualquer pilha de protocolos serem implemen-
tadas, o modelo de referncia ocial da internet foi formalizado aps os protocolos forem
projetados, implementados e testados (COMER, 2013, p. 53). Este modelo ocial cha-
mado 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 inuencia do modelo OSI).
A pilha TCP/IP atualmente implementada por padro em todos os sistemas ope-
racionais modernos, e como um padro utilizado na internet geralmente no ocorrem
problemas de comunicao em mquinas com diferentes sistemas operacionais ou arqui-
teturas 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 Proto-
col ), 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 ferramen-
tas utilitrias necessrias para ser categorizado como tal. Dentro da rvore genealgica
de sistemas operacionais baseados em Unix
5
, o Linux hoje obtm a posio de segundo
mais utilizado no mundo at o presente momento, perdendo somente para sistemas Mac
OS X da Apple
6
. A Tabela 1 demonstra os dados mensais de deste ano de 2014.
4
Faz referncia aos seus dois protocolos mais famosos, TCP e IP.
5
Imagem da rvore genealgica: <http://www.computerworld.com/common/images/site/features/
2009/062009/unix_chart_775.jpg>
6
<http://www.apple.com/br/osx/>
2.3. Sistemas Linux 29
Tabela 1 Estatstica de uso de sistemas operacionais
2014 Win8 Win7 Vista NT WinXP Linux Mac Mobile
Abril 15.8% 55.4% 1.2% 0.2% 8.0% 5.0% 10.3% 4.0%
Maro 15.0% 55.1% 1.3% 0.2% 9.4% 4.9% 9.9% 4.0%
Fevereiro 14.2% 55.0% 1.4% 0.3% 10.1% 5.0% 10.0% 4.0%
Janeiro 13.4% 55.3% 1.5% 0.3% 11.0% 4.9% 9.6% 4.0%
Fonte: W3SCHOOLS (2014).
Estes resultados englobam sistemas operacionais de todos os tipos, mas se a pes-
quisa 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 losoa 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 ba-
seia em quatro fundamentos de liberdade principais (FREE SOFTWARE FOUNDATION,
2014):
A liberdade de usar um software para qualquer propsito,
A liberdade de modicar 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 cor-
rees 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
bencas para os campos de ensino, pesquisa e desenvolvimento tambm. Anal, as liber-
dades possibilitam a investigao do cdigo fonte, e maior liberdade de acesso a funciona-
lidades do sistema, o que facilita o desenvolvimento uma nova soluo (o objetivo deste
trabalho).
Como j foi dito anteriormente, o Linux um kernel, sendo o principal programa de
um sistema operacional e cando 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 custo-
mizam 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 qual-
quer 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 se-
gurana 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
2.3. Sistemas Linux 31
Existem outras caractersticas de modos de CPU especcas 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 cona
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, dicilmente 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 mem-
ria. 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 anterior-
mente, 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 monolticos
7
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 aco-
pladas ao kernel sempre que necessrio, oferecendo uma maior exibilidade 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
<http://pt.wikipedia.org/wiki/N%C3%BAcleo_monol%C3%ADtico>
8
Caso ele seja inserido estaticamente a imagem do kernel, ele no um mdulo.
estabilidade e maior complexidade de desenvolvimento (como foi dito anteriormente na
subseo 2.3.1).
2.3.4 Netlter
Especicamente para mdulos do kernel Linux que trabalham com aspectos de
rede, existe uma srie de componentes que podem ser utilizados para ter acesso a de-
terminadas funcionalidades, como interceptao de pacotes. Este conjunto de componen-
tes fazem parte do framework chamado de Netlter, que composto de quatro partes
(RUSSEL; WELTE, 2002):
Hooks: So pontos pr-denidos na travessia de pacotes na pilha de protocolos TCP/IP
de uma mquina. Toda vez que chegado neste ponto pr-denido, o hook chamar
o que estiver registrado nele;
Registro de hooks: Qualquer mdulo do kernel pode registrar um hook com uma fun-
o de callback prpria
9
, 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 empi-
lhado, 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 especcos citados anteriormente na seo 1.3 era o de levantamento
bibliogrco 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 denio
terica bsica sobre o assunto.
2.4.1 Denio 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 m 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 denio 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 di-
versos servidores que rodam o mesmo website, a carga de trabalho pode ser dis-
tribuda entre eles, mas neste caso os servidores no atuam obrigatoriamente em
paralelo, provavelmente eles nem se comunicam ou sabem da existncia um do ou-
tro. 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
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, deter-
mina 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 res-
posta 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 nitos), alm disso, os recursos com
maior capacidade tinham altos preos, e ao nal 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, aumen-
tado 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 conabilidade do que qualquer outro sistema tradicional nas mes-
mas 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 balancea-
mento 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 alcana-
dos 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 so-
mente 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 poten-
tes. Dependendo da ecincia do algoritmo utilizado para deciso de despacho das
requisies, onde sero escolhidos os que estiverem menos ocupados, melhor ser o
desempenho.
Disponibilidade e conabilidade: Caso um dos servidores falhe, o balanceador de
carga capaz de detectar e redirecionar o uxo para outros, sem que o servio
como um todo que 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
conabilidade do sistema.
37
3 Arquitetura de um balanceador de carga de
servidores
A partir das denies 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 des-
perdcio 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 congurao antiga ainda utilizada. Bourke (2001, p. 43)
cita outras duas formas de congurao que so mais utilizadas atualmente, uma delas
a Flat-based, que uma forma simples e eciente, 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 congurao
de forma simplicada (no cenrio caram 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 Congurao de um balanceador de carga
(a) Congurao DNS-based, (b) Congurao Flat-based e (c) Congurao 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, cando denido
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 balan-
ceamento 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 an-
lise 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 ca preso
a determinados tipos de aplicao, isso signica 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
<http://en.wikipedia.org/wiki/HTTP_cookie>
3
<http://en.wikipedia.org/wiki/Internet_media_type>
na internet, mas possibilita que o endereo seja reutilizado por outros hosts em sub-
redes 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;
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 alte-
radas, 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 car sobrecarregado
de funes. As prximas tcnicas diminuem um pouco essa sobrecarga pelo balancea-
dor se tornar somente porta de entrada da rede, mas em compensao elas aumentam a
complexidade do sistema pois denem 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 especca para tunelamento, e ela deve estar congurada de modo que se estabe-
lea 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 Tun-
neling 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
congurado 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 congurado 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
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 pa-
cotes, existindo dois cabealhos para cada conjunto de dados, agora sero necessrios
trafegar alguns pacotes a mais. Tambm existem as tarefas adicionais de encapsular e de-
sencapsular 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 identica unicamente os servidores reais dentro da LAN.
Um endereo IP s vezes erroneamente denido como uma forma de identicao
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
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 congurada 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, verica 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 congurado 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
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: Especicaes do servidor, forma de congurao da rede,
nmero de servidores reais aconselhados na rede e gateway da rede.
Tabela 2 Comparao entre tcnicas de retorno de trfego
Via NAT Via tunelamento IP Via Direct Routing
Especicaes Qualquer
Protocolo e
Tnel congurado
Interface de loopback
com VIP e ARP
desabilitado
Rede LAN LAN/WAN LAN
Quantidade Baixo (10 a 20) Alto (aprx. 100) Alto (aprx. 100)
Rota padro Balanceador de carga Roteador da rede 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) deniram uma taxonomia para caracterizao de algor-
timos 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 denida 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 informa-
o 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 modicada 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 desem-
penho do sistema. J em um no-adaptvel no existe modicao 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 especicamente do balanceamento de
carga em servidores. A seguir sero descritos um total de cinco algoritmos de balancea-
mento de carga de servidores, trs estticos e dois dinmicos.
a) Round-robin e Aleatrio
um dos mais antigos algoritmos na rea da computao, aplicado original-
mente 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 al-
goritmo esttico, no-cooperativo e no-adaptvel que consiste em uma simples tc-
nica que distribui de forma homognea as requisies aos servidores que foram previ-
amente ordenados, similar a um sentido horrio. Este algoritmo trata todos os servi-
dores de forma igualitria, somo se tivessem a mesma congurao 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.
b) Ratio
O algoritmo ratio, tambm chamado de round-robin com pesos em algumas so-
lues de balanceamento de carga, outro algoritimo esttico, no-cooperativo e no-
adaptvel. O round-robin tradicional aconselhado para clusters com servidores homog-
neos, mas isso nem sempre a realidade de uma organizao, podendo existir servidores
mais antigos e com congurao mais bsica atuando em conjunto com servidores mais
novos com maior poder computacional, nestes casos o round-robin tradicional pode so-
brecarregar 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 algo-
ritmos 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
3.4. Redundncia do servio 47
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 us-
los 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 ACK
5
, 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 ACK
6
.
3.4 Redundncia do servio
Clientes da infraestrutura de TI
7
com o passar dos anos aumentaram a sua de-
pendncia 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 clien-
tes desses servios online no quem desapontados com um servio fora do ar por causa
de uma falha em hardware ou software. Existem requisitos no funcionais
8
que tratam
paralelamente esta necessidade, os requisitos de disponibilidade e conabilidade.
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 re-
cuperar 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, exis-
tem dois cenrios tpicos que sero descritos a seguir. O cenrio mais comum de redundn-
cia 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
Parte do que conhecido como handshake de trs vias: <http://andreysmith.wordpress.com/2011/
01/02/three-way-handshake/>
6
Abreviao de acknowledge. a mensagem de reconhecimento.
7
Acrnimo para Tecnologia da Informao.
8
A norma ISO/IEC 9126 trata de conceituar estes requisitos e outros: <http://pt.wikipedia.org/wiki/
ISO/IEC_9126>.
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 heart-
beat. Esse cabo (normalmente um par tranado) congurando 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 signica que alguma falha ocorreu e o servidor entrou em colapso
(JAYASWAL, 2006, p. 334-336). A deteco de erros do sistema est completamente li-
gada a sua conabilidade. 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 conguraes do servidor falho devem ser incorporadas no novo servidor ativo (e.g.
endereo IP, tabela de conexes, etc), para isso elas devem ser periodicamente transferi-
das 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 congurao 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).
Especicamente neste captulo ser tratada a arquitetura do software proposto,
ser descrito um modelo conceitual que facilitar a transio dos requisitos de um balan-
ceador 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 enge-
nharia de software de acordo com SWEBOK
1
(Software Engineering Body of Knowledge).
A arquitetura em grosso modo pode ser descrita como a subdiviso de um todo em
partes, estabelecendo relaes especcas entre as partes. Garlan e Shaw (1994) denem
a motivao da arquitetura de software como:
Conforme o tamanho e a complexidade de sistemas de software aumen-
tam, o problema de design vai alm dos algoritmos e das estruturas de
dados da computao. A projeo e a especicao da estrutura geral do
sistema emergem como um novo tipo de problema. As questes estrutu-
rais incluem organizao total e estrutura de controle global; protocolos
de comunicao, sincronizao e acesso a dados; atribuio de funcionali-
dade 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 Unied Process)
(IBM RATIONAL SOFTWARE, 2001).
4.1 Representao da arquitetura
Neste captulo sero indicadas as decises de uso das tecnologias que foram ex-
plicadas 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 nal listando restries de qualidade do sistema. A seguir uma breve descrio de
cada item citado:
Tecnologias e tcnicas utilizadas: Uma listagem e justicativa 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 de-
composio em mdulos e camadas.
Viso de implantao: Uma descrio da decomposio do balanceador em termos f-
sicos, 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 conabilidade.
4.2 Tecnologias e tcnicas utilizadas
Seguindo ainda o princpio KISS introduzido por Bourke (2001, p. 41), nesta seo
sero descritos e justicados 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, cando
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 especcas (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, cando 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 justicativas:
O protocolo IP, que o principal protocolo da camada 3 no orientado a conexo,
o que signica que este protocolo tem uma baixa conabilidade.
O protocolo TCP, um dos principais protocolos da camada 4, categorizado como
orientado a conexo e fornece um stream convel de dados. Isso signica 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 arma que o segmento chegou ao seu destino. Ao nal tambm existe
um momento de nalizao da conexo. A Figura 10 explica esse processo de comu-
nicao.
Figura 10 Processo de comunicao TCP
O protocolo TCP oferece um mecanismo de preveno de entrada de dados duplica-
dos, porque cada segmento possui um campo SEQUENCE NUMBER e outro ACKNOWLEDGEMENT
NUMBER, o primeiro nmero identica o segmento e o segundo nmero serve como
um indicador do que o remetente espera como SEQUENCE NUMBER da resposta, ofe-
recendo 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
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 443
2
(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 denido 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 so-
bre 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 balan-
ceamento 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 ns 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
congurar 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 Netlter.
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 justicativas 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 por protocolo: <http://pt.wikipedia.org/wiki/Anexo:
Lista_de_portas_de_protocolos>
4.2. Tecnologias e tcnicas utilizadas 55
Bibliotecas como STL e Boost do C++ trazem abstraes que podem dicultar a
depurao de um mdulo, alm de trazerem falhas que podem ser catastrcas 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 malef-
cios 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 lembrar-
se 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 ns 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 justicativas:
O interpretador Python vem nativamente instalado em grande parte das distri-
buies Linux (e.g. Ubuntu, Debian e Fedora), contendo vrias funcionalidades da
prpria distribuio implementadas em Python;
A linguagem Python a 8
a
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 fra-
meworks desenvolvidos e distribudos sob licenas livres para os mais diversos do-
mnios de conhecimento (e.g. fsica aplicada, jogos de computadores e computao
grca);
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
A tcnica de retorno de trfego via NAT de longe a mais simples de ser implemen-
tada, por conta de no exigir qualquer congurao 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 congurao 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 car denidos 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 especco (MADHURAVANI; SUMALATHA; SHANMUKHI, 2012). O al-
goritmo dinmico escolhido foi o menor latncia, que consegue identicar 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 distri-
budos (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 especco de pesquisa e desenvolvimento pr-denido, 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 signicativo no ponto de vista da arquitetura
(IBM RATIONAL SOFTWARE, 2001). A Figura 11 a seguir demonstra um diagrama de
pacotes
3
da UML (Unied 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 servi-
dores. Aps sua instalao em um servidor Linux ser possvel efetuar a congurao e
uso da soluo de balanceamento de carga.
b) slbcli
3
<http://pt.wikipedia.org/wiki/Diagrama_de_pacotes>
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 congurar 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 congurao
# slbcli --unload : Descarrega o mdulo do balanceador do kernel
# slbcli --reload : Recarrega o mdulo do balanceador no kernel. Por padro, antes de efe-
tuar a carga do mdulo, sero lidos e aplicados os itens do arquivo padro de congurao
# slbcli --load-noconf : Carrega o mdulo do balanceador no kernel, ignorando o arquivo
padro de congurao
# slbcli --reload-noconf : Rearrega o mdulo do balanceador no kernel, ignorando o ar-
quivo padro de congurao
# slbcli --restore conf_file.conf : Carrega as conguraes que esto contidas no ar-
quivo conf_le.conf
# slbcli --bind 172.17.60.201:80 : Atribui um endereo VIP 172.17.60.201 ao balancea-
dor, 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 congurao do sistema
# slbcli --clearconf : Limpa toda a congurao j feita, inclusive exclui todos os itens do
arquivo de congurao padro
4.3. Viso lgica 59
O smbolo # signica 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 congur-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) netlter
o componente que representa o framework Netlter 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 monitora-
mento dos servidores reais em tempo de execuo. O cluster-monitor um subcomponente
4
Iterpretador de comandos Unix: <http://en.wikipedia.org/wiki/Unix_shell>
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 identicar 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) conguration-synchronizer
Este um componente a parte do balanceador de cargas, responsvel por sincroni-
zar a congurao 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, cando 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 congurao 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 congurao 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 ambi-
entes 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 gerencia-
dos tanto a soluo de balanceamento de carga, quanto o componente conguration-
synchronizer, que so duas aplicaes independentes. Mais detalhes sobre os subcompo-
nentes do Application Manager sero dados a seguir.
j) SMA
4.3. Viso lgica 61
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 exemplicada a mquina de estados
5
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_nitos>
Tabela 3 Eventos para troca de estados do SMA
Estado atual Novo estado Evento
OFFLINE INIT Aplicao iniciada
INIT STANDBY Aplicao inicializada, congurao BACKUP e aplicao dual em ACTIVE
INIT ACTIVE Aplicao inicializada, congurao PRIMARY e aplicao dual no em ACTIVE
INIT MAINT. Aplicao inicializada e congurao INHIBITED
STANDBY MAINT. Comando TEST
MAINT. STANDBY Comando UNTEST
STANDBY ACTIVE Falha do aplicao, dual ACTIVE ou comando SWITCH
Todos FAILED Falha da aplicao
Todos OFFLINE Comando SHUTDOWN ou SHUTDOWN-F
uma comunicao local com ela. Para isso a aplicao gerenciada deve implementar uma
interface com o mecanismo de identicao 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 congurar
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 Ma-
nager. Eles implementam um protocolo de comunicao heartbeat para vericao 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,
cando 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 pro-
cessos/threads nesses hosts (IBM RATIONAL SOFTWARE, 2001). A seguir na Figura
14 representa o diagrama de implantao
6
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 com-
ponentes internos no foram ilustrados por possurem a mesma disposio dos com-
ponentes 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 congurao 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 o, etc), representa-
dos 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.
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 signica o envio de pings para vericar
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 signica a forma de comunicao en-
tre 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 con-
gurao sempre que o slbcli indicar novos comandos de congurao (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 congurao
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 conguration-synchronizer e o slbconf.conf de leitura de
arquivos. Isso ocorre porque periodicamente este arquivo de congurao ser sin-
cronizado entre Primary Load Balancer e o Secondary Load Balancer.
SCP: A associao entre o conguration-synchronizer e o Secondary Load Balancer re-
presenta o protocolo SCP (Secure Copy Protocol ), que ser o responsvel pela trans-
ferncia segura do arquivo do Primary Load Balancer para o Secondary Load Ba-
lancer.
TCP Socket: Essa forma de comunicao via a API de comunicao TCP Socket
7
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 vericar 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 co-
mandos 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 especicamente re-
quisitos no funcionais. No contexto do projeto do balanceador de carga j foram evi-
denciadas diversas vezes durante este trabalho importantes categorias de requisitos que
tiveram total impacto na soluo que est sendo projetada, como o Desempenho, a Dis-
ponibilidade, a Conabilidade, etc. Para cada uma dessas categorias podemos extrair al-
guns 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.
Conabilidade
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.
Conabilidade
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 vericao 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 tolern-
cia 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 sis-
tema 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 imple-
mentadas determinadas caractersticas, ou como podero ser solucionados determinados
problemas que foram evidenciados. Este nvel de detalhes visa renar o projeto da soluo,
facilitando o alcance do sucesso no processo de codicao do sistema. Para viabilidade
da descrio destes detalhes, sero descritos somente alguns dos considerados mais impor-
tantes, porque seria invivel detalhar totalmente todas as caractersticas de um sistema.
5.1 Congurao 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 dedigno a uma so-
luo 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 implemen-
tao do sistema possuir uma determinada dvida em como congurar a rede, necessrio
determinar uma provvel congurao.
A Figura 15 ilustra um projeto simples de uma rede baseado em uma congura-
o descrita por Kopparapu (2002, p. 90), podendo ser utilizado em uma situao real.
Neste cenrio existe um roteador com IP pblico e xo, provavelmente com uma WAN
(Wide Area Network) congurada diretamente com sua ISP (Internet Service Provider),
isso possibilitar que demandas da internet cheguem na rede congurada. 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 xo acessvel pela internet, congu-
rado em uma de suas interfaces de rede (e.g. eth0 em um servidor Linux), ele tambm
possuir um IP privado e nico na rede congurado 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 balan-
ceador em standby congurado 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 balancea-
dor ativo) somente sero congurados em um processo de failover, quando o balanceador
ativo falhar. Enquanto esse processo no ocorrer, estas interfaces de rede caro 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 decincias, 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) veri-
car se cada servidor real est em seu normal funcionamento, para que no sejam enviadas
requisies a servidores inoperantes, e (ii) vericar a latncia dos servios providos pelos
servidores reais, fornecendo parmetros para a deciso do algoritimo de menor latncia.
Para vericar se um servidor est operante, em teoria pode ser utilizado o proto-
colo 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 dene um campo type, que pode receber 18 valores diferentes de ti-
pos do pacote, de acordo com o que foi denido na RFC
1
792 (Request for Comments).
1
Uma RFC um documento ocial que dene 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 dene 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 vericados 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 vericado 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 vericao 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 modicam de acordo com que so passados de uma camada a outra. Nesta
estrutura so inseridos os cabealhos dos diversos protocolos que ela trafega, ao nal 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 vericao da latncia dos servios e no a latncia na comunicao entre os
hosts, como pode ocorre no mtodo anterior. Para vericar 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.
Quadro 1 Cdigo fonte C: Envio de um ICMP_ECHO
1 // ...
2 icmp.type = ICMP_ECHO; // Define um ECHO para o ICMP
3 ip.protocol = IPPROTO_ICMP; // Define que o protocolo sera ICMP
4 ip.daddr = inet_addr("10.10.10.2"); // Define o end. do destinarario
5 // ...
6
7 // Reserva uma estrutura "struct sk_buff" no tamanho de um frame
ethernet
8 struct sk_buff *skb = dev_alloc_skb(1500);
9 skb ->dev = __dev_get_by_name(net , "eth0"); // Define o device de saida
10
11 // ...
12 // Configura o cabecalho da camada de transporte (ICMP)
13 skb ->transport_header =skb_push(skb ,sizeof(icmp));
14 memset (skb ->transport_header ,0,sizeof(struct icmphdr));
15 memcpy (skb ->transport_header ,&icmp ,sizeof(struct icmphdr));
16 // ...
17 // Configura o cabecalho da camada de rede (IP)
18 skb ->network_header=skb_push(skb ,sizeof(ip));
19 memset (skb ->network_header ,0,sizeof(struct iphdr));
20 memcpy (skb ->network_header ,&ip ,sizeof(struct iphdr));
21 // ...
22 dev_queue_xmit(skb); // Despacha o sk_buff
23 kfree(skb);
Quadro 2 Cdigo fonte C: Recebimento de um ICMP_ECHOREPLY
1 //...
2 if(skb == NULL)
3 return -1;
4
5 iph = ip_hdr(skb); // Pega o cabecalho IP
6 //...
7 // Verifica se o "protocol" eh mesmo o ICMP
8 if(iph ->protocol == IPPROTO_ICMP) {
9 icmph = icmp_hdr(skb); // Pega o cabecalho ICMP
10 if(icmph ->type == ICMP_ECHOREPLY) { // eh um ECHO REPLY?
11 // Servidor esta acessivel entao
12 } else if(icmph ->type == ICMP_DEST_UNREACH) { // eh um DEST.
UNREACHABLE?
13 // Servidor esta inacessivel , deve ser removido temporariamente do
cluster de tempos em tempos sera verificado o seu retorno...
14 }
15 }
de uma conexo TCP. Pode ser criar um raw packet de um segmento TCP com a ag do
tipo SYN ativada (bit = 1), e ento envi-lo ao servidor e esperar como resposta um
TCP segmento TCP com as ags 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 vericada
5.3. Processo de failover 71
a latncia com o protocolo ICMP, igual ao exemplo de vericao da conexo com os
servidores reais com um adicional de vericao de tempo entre os eventos.
5.3 Processo de failover
Em um cenrio ativo-standby, caso o sistema ativo venha a falhar, algumas provi-
dncias sero tomadas reativamente a situao (logo aps a falha) e algumas providncias
j devem estar sendo tomadas preventivamente (anteriormente a falha). Aqui ser expli-
cado sucintamente esse processo.
O mdulo conguration-synchronizer atua preventivamente, pois sincroniza con-
tinuamente a congurao 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 congurao da soluo de balanceamento de carga car localizado em
uma pasta especca do sistema (e.g. /etc/slb/slbconf.conf), ou poder ser so-
licitado 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 criptograa, este protocolo
baseado em outro, o SSH
2
(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 exemplica realizao da transferncia
usando as bibliotecas paramiko e scp
3
para Python.
3. Quando o failover ocorrer e for iniciado o slbd no novo balanceador ativo, o arquivo
de congurao 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>
3
<https://pypi.python.org/pypi/scp>
Quadro 3 Cdigo fonte Python: Envio de arquivo via SCP
1 import scp
2 import paramiko
3
4 # Cria o cliente SSH
5 def createSSHClient(server , port , user , password):
6 client = paramiko.SSHClient()
7 client.load_system_host_keys()
8 client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
9 client.connect(server, port , user , password)
10 return client
11
12 # Conecta com o servidor
13 ssh_cliente = createSSHClient("10.10.10.2", 22, "root", "passwd")
14 scp_cliente = scp.SCPClient(ssh_cliente.get_transport())
15 # Transfere o arquivo
16 scp_cliente.put(files=["/etc/slb/slbconf.conf"],remote_path="/etc/slb/
slbconf.conf",recursive=False , preserve_times=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, congura 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 congura de
acordo com o contedo do arquivo de congurao slbconf.conf.
importante ressaltar que esse processo de failover descrito considerado stateless
e no stateful. Um failover stateless no dene 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
congurao 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 con-
gurao do slbcore, foi dito que ela seria feita atravs de uma interao via IOCTL com
o slbd, este daemon iria realizar a leitura da congurao ou iria receber um comando do
slbcli, e logo aps iria se comunicar com o mdulo do kernel para congur-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 buer overows, que signica
ultrapassar os limites de escrita de um buer
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 m-
dulo do kernel o local de arquivos de congurao 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 ca quase irrestrito a nvel de acesso de instrues.
Para evitar esse problema de acesso direto a arquivos de congurao o ideal a
congurao via uma aplicao no modo usurio. Para estabelecer essa comunicao exis-
tem diversas formas, podem ser utilizados os sistemas de arquivo padro Linux para infor-
maes de processos ou para informaes de congurao, /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 dene uma forma de entrada
e sada de dados destinados a um device le
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 con-
tm 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
Anlise sinttica: <http://pt.wikipedia.org/wiki/An%C3%A1lise_sint%C3%A1tica_(computa%C3
%A7%C3%A3o)>
5
<http://pt.wikipedia.org/wiki/Buer_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)>
6
Um arquivo que normalmente representa um dispositivo fsico, mas qualquer mdulo do kernel pode
registrar um.
Quadro 4 Cdigo fonte C: Chamadas IOCTL no slbcore
1 // Constante que define o comando de adicionar um servidor (IOW =
escrita)
2 #define ADD_SERVER _IOW(MAGIC_CHAR , 0, int)
3 // Constante que define o comando listar conexoes ativas (IOR = leitura)
4 #define LIST_ACTIVE_CONN _IOR(MAGIC_CHAR , 1, int)
5
6 static struct file_operations fops = {
7 .read = slbcore_read , // Ponteiro para funcao de callback da leitura
do arquivo
8 .write = slbcore_write , // Ponteiro para funcao de callback da
escrita do arquivo
9 .ioctl = slbcore_ioctl , // Ponteiro para funcao de callback de uma
chamada ioctl
10 };
11
12 // Registra o device file
13 register_chrdev(0, "slb", &fops);
14
15 int slbcore_ioctl(struct inode *inode , struct file *filep , unsigned int
cmd , unsigned long arg) {
16 int len = 200;
17 char buf[200];
18 switch(cmd) {
19 case LIST_ACTIVE_CONN:
20 // Aqui deve se colocar a lista de conexoes ativas na variavel "
buf" para serem enviadas ao slbd
21 copy_to_user((char *)arg , buf , 200);
22 break;
23
24 case ADD_SERVER:
25 copy_from_user(buf , (char *)arg , len);
26 // Aqui deve se adicionar o servidor a lista de servidores , seu
IP:Porta estarao na variavel "buf"
27 break;
28 default:
29 return -ENOTTY;
30 }
31 return len;
32 }
As constantes LIST_ACTIVE_CONN_CONSTANT e ADD_SERVER_CONSTANT que esto
exemplicadas no Quadro 5 devem ser encontradas para comunicao entre os componen-
tes, 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 import fcntl # Modulo python para manipular IOCTL
2
3 # Devem ser descobertas as constantes numericas que representam os
comandos definidos no slbcore
4 LIST_ACTIVE_CONN_CONSTANT = 2983579
5 ADD_SERVER_CONSTANT = -3487538
6
7 # Abre o device file
8 dev_file = open("/dev/slb")
9 # Define o IP:Porta de um servidor
10 buf = array.array(1,0,.,1,0,.,1,0,.,3, :, 8, 0
)
11 # Faz chamada ao comando de adicionar um servidor
12 fcntl.ioctl(dev_file , ADD_SERVER_CONSTANT , buf , 1)
13
14 # Faz chamada ao comando de listar conexoes
15 buf = None
16 fcntl.ioctl(dev_file , LIST_ACTIVE_CONN_CONSTANT , buf , 1)
17 # Imprime a lista de conexoes
18 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 IPv4
7
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 atu-
almente 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.
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 dene um esboo de uma lista com possveis structs C que
sero utilizadas.
Quadro 6 Cdigo fonte C: Structs para o slbcore
1 // Representa uma conexao
2 typedef struct {
3 uint32_t client_ip4; // IP do cliente
4 uint16_t client_port; // Porta do cliente
5 } conn;
6
7 // Representa uma lista de conexoes para um servidor
8 typedef struct {
9 conn *conns; // Lista de conexoes
10 uint16_t conns_count; // Quantidade de conexoes
11 server *server; // Servidor associado
12 } conn_list;
13
14 // Tipo de protocolo da camada de transporte
15 typedef enum {TCP_PROTOCOL , UDP_PROTOCOL} transp_protocol;
16
17 // Representa uma porta
18 typedef struct {
19 uint16_t port; // Numero da porta
20 transp_protocol proto; // Qual protocolo (TCP ou UDP)
21 conn_list *conn_list; // Lista de conexoes associadas ao servico
22 } service;
23
24 // Representa um servidor real
25 typedef struct {
26 uint32_t ip4; // IP do servidor real
27 service *services; // Array de servicos do servidor real
28 uint16_t services_count; // Quantidade de servicos do servidor real
29 } server;
30
31 // Representa todos os servidores reais
32 typedef struct {
33 server *servers; // Lista de servidores reais
34 uint16_t servers_count; // Quantidade de servidores reais
35 } server_table;
36
37 // Representa todos as conexoes
38 typedef struct {
39 conn_list ** conn_lists_list; // Uma lista de listas de conexoes
40 uint16_t conn_lists_list_count; // Quantidade de listas de conexoes
41 } conn_table;
Essas estruturas servem somente como esboo para demonstrao dos dados que
devero ser mantidos e manipulados. Uma real implementao iria requerer o uso de es-
truturas 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 exem-
plo, 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 desa-
locao 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 ca 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 nati-
vamente 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
ao chegar uma nova requisio de um cliente, deve ser vericado 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 ser-
vidor que atua como intermedirio de um grupo de usurios a uma rede externa para me-
lhorar a segurana (rewall ) e desempenho (caching). Este grupo de usurios ao fazerem
requisies a uma rede externa so representados externamente pelo proxy, consequente-
mente 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 balan-
ceamento 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 importan-
tes componentes do kernel se tratando de redes. O projeto desenvolvido por Russel e Welte
(2002), teve a inteno de denir novas formas de ltragem e manipulao de pacotes de
rede em sistemas Linux. Foi desenvolvido um grande framework para manipulao de pa-
cotes chamado de Netlter, 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 rewall, como o iptables e o arptables.
Dentro deste framework foram denidos vrios hooks (ganchos), que so pontos
bem denidos na travessia de pacotes da pilha de protocolos do sistema. Cada protocolo
dene 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 netlter 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 netlter, o responsvel pelo seu
destino agora ser do prprio mdulo.;
NF_QUEUE: O pacote deve ser enleirado 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 netlter,
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 cogurao de um hook
1 struct nf_hook_ops
2 {
3 struct list_head list; // Nao deve ser preenchido
4 nf_hookfn *hook; // Ponteiro para a funcao que ira registrar o hook
5 int pf; // A familia do protocolo de rede
6 int hooknum; // O identificador do tipo de hook
7 int priority; // Prioridade do hook
8 };
Cada um dos campos sero explicados para melhor entendimento do funciona-
mento do netlter. 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 netlter dene 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 unsigned int hook_function_name(unsigned int hooknum ,
2 struct sk_buff **skb ,
3 const struct net_device *in ,
4 const struct net_device *out ,
5 int (*okfn)(struct sk_buff*));
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;
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 denido 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 l-
tragem 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 dene qual tipo de hook ser
trabalhada na funo de callback, denindo em que ponto da travessia de rede o pacote
car acessvel. A Figura 16 dene 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 netlter 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 m j que o IP de destinatrio o VIP. Ento ser utilizado
o hook NF_IP_PRE_ROUTING.
O prximo campo da estrutura de congurao 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 denidos. 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 denem prioridades intermedirias.
Com o preenchimento dos campos da estrutura nf_hook_ops j possvel fazer
um simples mdulo netlter. 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.
Quadro 9 Cdigo fonte C: Exemplo de um mdulo netlter simples
1 // Funcao que realiza o balanceamento
2 int process_segment(struct sk_buff *skb) {
3 // Verifica se eh o pacote eh valido
4 if(!skb) return NF_ACCEPT;
5 if(!(skb ->nh.iph)) return NF_ACCEPT;
6
7 struct tcphdr *tcp=NULL;
8 struct iphdr *iph=NULL;
9 iphdr = ip_hdr(skb);
10
11 if(iph ->protocol == IPPROTO_TCP){
12 tcphdr = tcp_hdr(skb);
13 uint16_t dport = tcphdr ->th_dport;
14 // ...
15 // Verifica se algum servidor real contem o servico com "dport"
16 // Se nao existir eh dado um "return NF_DROP;"
17 // ...
18 // Caso existam , eh feito o escalonamento de qual servidor sera
o responsavel
19 uint32_t realserver_ip = scheduling_algorithm();
20
21 iphdr ->daddr = realserver_ip;
22
23 // Refaz os checksums
24 iphdr ->check = checksum(iphdr);
25 tcphdr ->th_sum = checksum(tcphdr);
26 } else if(iph ->protocol == ...) { // Outros protocolos de transporte
...
27
28 }
29 return NF_ACCEPT;
30 }
31 // Funcao de callback para o hook
32 static u_int slbcore_hook_fn( u_int hooknum ,
33 struct sk_buff **skb ,
34 const struct net_device *in,
35 const struct net_device *out ,
36 int (*okfn)(struct sk_buff *)) {
37
38 // Verifica se o pacote chega pela interface do VIP
39 // se nao vier desta o pacote seguira o seu caminho
40 if(strcmp(in ->name , "eth0") != 0){
41 return NF_ACCEPT;
42 }
43 return process_segment(*skb);
44 }
45 // Funcao de inicializacao do modulo
46 struct nf_hook_ops slbcore_nfh_ops;
47 static int __init slbcore_init() {
48 // Configura o hook
49 slbcore_nfh_ops.hook = slbcore_hook_fn;
50 slbcore_nfh_ops.hooknum = NF_IP_PRE_ROUTING;
51 slbcore_nfh_ops.pf = PF_INET;
52 slbcore_nfh_ops.priority = NF_IP_PRI_FIRST;
53 // Registra o hook
54 nf_register_hook(& slbcore_nfh_ops);
55 return 0;
56 }
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 rearmao 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 conabilidade 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 ns 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 denidos, 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 especco 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 vericao 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 denir 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. Congurao de um ambiente de desenvolvimento da soluo (Computadores, m-
quinas 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 congurao 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-denidos).
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 conguration-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 vericao e validao de
toda a soluo. Esforo = 8.
Para estimativa de esforo foi denido o valor 1 a atividade com menor complexi-
dade (nmero 10), depois foram estimados valores proporcionais a este usando nmeros da
sequncia de Fibonacci
1
, levando em considerao a complexidade das outras atividades.
1
Exemplo: 0, 1, 1, 2, 3, 5, 8, 13, 21, ...(<http://pt.wikipedia.org/wiki/Sequ%C3
%AAncia_de_Fibonacci>)
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 Conguration 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/conguration/guide/cong.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 Unied 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 prot. 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 netlter Hacking HOWTO. 2002. Rev. 521. Disponvel
em: <http://www.netlter.org/documentation/HOWTO/netlter-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 + Makele. 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 congurao 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 congurao).
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 congurao
dinmica UNINHIBITED)
DISABLE: Muda a instncia da aplicao que STANDBY para MAINTENANCE e a res-
tringe para no se tornar ACTIVE caso a dual falhe (mudando o valor no arquivo de
congurao 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 congurao 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 congurao dinmica para UNINHIBITED.
GETPID: Solicita o PID de um processo especco da instncia local da aplicao.
KILLPROC: Executa o comando Unix/Linux kill -0 sobre um processo especco 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 MatheusFonseca PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC1 MatheusFonseca PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade de Braslia - UnB

Faculdade UnB Gama - FGA

Você também pode gostar