Escrito por by KJ (Ken) Salchow, Jr.

| Gerente, Gerncia de Produtos

_________________________________________________________________________________________
F5 Network, Inc - 1 -
Balanceamento de carga: Conceitos bsicos

Introduo A tecnologia de balanceamento de carga est viva e est bem; de fato, ela a base
sobre a qual operam os application delivery controller (ADCs). A disseminao da
tecnologia de balanceamento de carga no significa, porm, que ela seja
universalmente compreendida nem que seja discutida normalmente, a no ser de um
ponto de vista focalizado em redes. Em uma explorao mais aprofundada do
assunto, este documento tenta desvendar um pouco do mistrio e da magia das
prticas bsicas de balanceamento de carga.

Hardware de
Balanceamento
de carga
baseado
em rede A segunda gerao do balanceamento de carga de finalidade especfica (que se
seguiu aos sistemas proprietrios baseados em aplicativos) surgiu na forma de
dispositivos baseados em rede. Esses so os verdadeiros avs dos controladores de
distribuio de aplicativos de hoje. Como esses dispositivos eram neutros em
relao a aplicativos e residiam fora do servidor de aplicativos, eles podiam fornecer
o balanceamento de carga usando tcnicas diretas de rede. Em sntese, esses
dispositivos ofereciam um endereo de servidor virtual para o mundo exterior e,
quando os usurios tentavam se conectar, ele encaminhava a conexo ao servidor
verdadeiro mais apropriado, fazendo uma traduo de endereos de rede (NAT)
bidirecional.



Terminologia
Bsica Tudo seria mais simples se todos usassem o mesmo dicionrio; infelizmente, cada
fornecedor de dispositivos de balanceamento de carga ( e, por sua vez, ADCs)
parece usar uma terminologia diferente. Com uma pequena explicao, entretanto, a
confuso em torno desse assunto pode ser facilmente esclarecida.

N, Host, Membro e Servidor
A maioria dos balanceadores de carga usa o conceito de n, host, membro ou
servidor; alguns usam todos eles, significando coisas diferentes. H dois conceitos
bsicos que todos eles tentam expressar. O primeiro, normalmente chamado de n
ou servidor, a idia do servidor fsico que recebe trfego do balanceador de carga.
Isso equivale ao endereo IP do servidor fsico e, na falta de um balanceador, seria o
endereo IP para o qual o nome do servidor seria atribudo (por exemplo,
www.exemplo.com). No resto desse documento, vamos nos referir a este conceito
como "o host". O segundo conceito o membro (infelizmente, tambm chamado de
n por alguns fabricantes). Um membro normalmente mais bem definido do que
um servidor ou n, visto incluir a porta TCP do aplicativo que recebe o trfego. Por

Escrito por by KJ (Ken) Salchow, Jr. | Gerente, Gerncia de Produtos


_________________________________________________________________________________________
F5 Network, Inc - 2 -
exemplo, um servidor chamado www.exemplo.com pode ser atribudo para o
endereo 172.16.1.10, que representa o servidor/n, e pode ter um aplicativo (um
servidor web) sendo executado na porta TCP 80, formando o endereo do membro
172.16.1.18:80. Simplificando, um membro inclui a definio da porta do aplicativo,
alm do endereo IP do servidor fsico. No resto desse documento, vamos nos
referir a este conceito como "o servio".

Por que tanta complicao? A distino entre o servidor fsico e os servios de
aplicativos sendo executados nele permite que o balanceador de carga interaja
individualmente com os aplicativos, em vez de interagir com o hardware subjacente.
Um host (172.16.1.10) pode ter mais de um servio disponvel (HTTP, FTP, DNS e
assim por diante). Ao definir cada aplicativo individualmente (172.16.1.10:80,
172.16.1.10:21 e 172.16.1.10:53), o balanceador de carga pode aplicar um
balanceamento de carga exclusivo e tambm o monitoramento de estado (que ser
discutido mais tarde) baseando-se nos servios e no no host. Entretanto, ainda h
momentos em que interagir com o host (como no monitoramento de estado em baixo
nvel ou ao desativar um servidor para manuteno) pode ser muito conveniente.

importante lembrar que a maioria das tecnologias de balanceamento de carga
usam algum conceito para representar o host, ou servidor fsico, e um segundo
conceito para representar os servios nele disponveis.

Grupo, Cluster e Fazenda
O balanceamento de carga permite que voc distribua o trfego de entrada entre
vrios destinos de segundo plano. necessrio, portanto, adotar o conceito da
coleo de destinos de segundo plano. Os clusters, como os chamaremos a partir
de agora, so colees de servios similares disponveis em um nmero qualquer de
hosts. Por exemplo, todos os servios que oferecem a pgina web da companhia
seriam reunidos em um cluster chamado "Pgina web da companhia" e todos os
servios que oferecem comrcio eletrnico seriam reunidos ou colecionados em um
cluster chamado "eCommerce".

O ponto principal que todos os sistemas tm um objeto coletivo, que se refere a
todos os servios similares. Isso torna mais fcil trabalhar com eles como uma nica
entidade. Esse objeto coletivo quase sempre composto de servios e no de hosts.

O servidor virtual
Embora no seja sempre o caso, hoje em dia h poucas divergncias sobre o termo
servidor virtual ou "Virtual". importante notar que, como definio de servios, o
servidor virtual normalmente inclui a porta do aplicativo e o endereo IP. Como a
maioria dos fornecedores usa um servidor virtual, ns continuaremos a usar essa
terminologia nesse documento, embora o termo "Servio virtual" fosse mais
adequado conveno IP:Porta.

Somando tudo
Reunir todos esses conceitos a idia principal do balanceamento de carga. O
balanceador de carga oferece servidores virtuais para o mundo externo. Cada
servidor virtual aponta para um cluster de servios que reside em um ou mais hosts
fsicos.


Escrito por by KJ (Ken) Salchow, Jr. | Gerente, Gerncia de Produtos


_________________________________________________________________________________________
F5 Network, Inc - 3 -


Embora o exemplo demonstrado no represente uma implementao real, ele ilustra
a estrutura bsica para continuarmos a nossa discusso sobre os conceitos bsicos
do balanceamento de carga.

Balanceamento
de carga -
conceito
bsico Agora que temos um vocabulrio comum, podemos comear a examinar a transao
bsica de balanceamento de carga. Conforme demonstrado, o balanceador de carga
normalmente ficar alinhado entre o cliente e os hosts que fornecem os servios
desejados pelos clientes; como muitas outras coisas no balanceamento de carga,
isto no uma regra, mas uma boa prtica em uma implementao tpica. Tambm
vamos considerar que o balanceador de carga j est configurado como servidor
virtual que aponta para um cluster formado por dois pontos de servio. Nesse
cenrio de implementao, tambm normal que os hosts tenham uma rota de
retorno que aponte de volta para o balanceador, para que o trfego de retorno seja
processado por ele, no caminho de volta para o cliente.

A transao bsica de balanceamento de carga funciona assim:
1. O cliente tenta conectar ao servio no balanceador de carga.
2. O balanceador de carga aceita a conexo e, aps decidir qual host deve
receber a conexo, muda o IP de destino (e talvez a porta) para combinar com
o servio do host selecionado (note que o IP de origem do cliente no
alterado).


Escrito por by KJ (Ken) Salchow, Jr. | Gerente, Gerncia de Produtos


_________________________________________________________________________________________
F5 Network, Inc - 4 -


3. O host aceita a conexo e responde ao cliente original pela rota padro, o
balanceador de carga.
4. O balanceador de carga intercepta o pacote de retorno do host e muda o IP de
origem (e provavelmente a porta) para combinar com o IP e a porta do
servidor virtual, que encaminha o pacote de volta para o cliente.
5. O cliente recebe o pacote de retorno, pensando que ele vem do servidor
virtual, e d continuidade ao processo.

Este exemplo simples bastante direto, mas h alguns elementos importantes que
podemos destacar. Primeiro, para o cliente, a comunicao parece ser direta - ele
manda pacotes para o servidor virtual e recebe respostas. Em segundo, o NAT atua
na conexo. aqui que o balanceador de carga substitui o endereo IP de destino
enviado pelo cliente (o do servidor virtual) com o IP de destino do host escolhido
para balancear a carga do pedido O terceiro passo a segunda metade desse
processo (a parte que torna o NAT "bidirecional"). O IP de origem do pacote de
retorno do host ser o IP do host; se esse endereo no for alterado e o pacote for
simplesmente encaminhado para o cliente, o cliente iria descart-lo, pois estaria
recebendo um pacote de algum a quem no solicitou pacotes. Em vez disso, o
balanceador de carga, lembrando-se da conexo, altera o pacote para que o IP de
origem seja aquele do servidor virtual, resolvendo esse problema.

A deciso do balanceamento de carga
Normalmente, nesse ponto que surgem duas questes: como o balanceador de
carga decide para qual host encaminhar a conexo, e o que acontece se o host
selecionado no estiver funcionando?

Vamos discutir a segunda questo primeiro. O que acontece se o host selecionado
no estiver funcionando? A resposta mais simples que ele no responder ao
pedido do cliente e o tempo da conexo se esgotar, fazendo que ela falhe.
Obviamente, essa no a circunstncia ideal, pois no garante uma alta
disponibilidade. por isso que a maioria das tecnologias de balanceamento de carga
incluem algum tipo de "Monitoramento de estado" que determina se um host est ou
no disponvel antes de tentar estabelecer conexes com ele. H vrios nveis de
monitoramento de estado, cada um deles com granularidade e foco crescentes. Um
monitor bsico ir apenas executar um PING e aguardar a resposta do host. Se o
host no responder ao PING, razovel assumir que os servios definidos no host
provavelmente no esto ativos e deveriam ser removidos do cluster de servios

Escrito por by KJ (Ken) Salchow, Jr. | Gerente, Gerncia de Produtos


_________________________________________________________________________________________
F5 Network, Inc - 5 -
disponveis. Infelizmente, mesmo que o host responda ao PING, isso no significa
necessariamente que o servio est funcionando. Por isso, a maioria dos dispositivos
tm a capacidade de executar algum tipo de "PINGS de servio", desde conexes
TCP simples at a interao com o aplicativo por meio de scripts. Esses monitores
de estado de alto nvel no s oferecem mais confiana na disponibilidade do
servios (e no do host) como tambm permitem que o balanceador de carga
distinga entre mltiplos servios em um mesmo host. O balanceador de carga
entende que, embora um servio possa estar indisponvel, outros servios no mesmo
host podem estar funcionando perfeitamente e devem ser considerados como
destinos vlidos para o trfego de usurios.
Isso nos leva de volta primeira pergunta: como o balanceador de carga decide para
qual host encaminhar o pedido de conexo? Cada servidor virtual tem um cluster
dedicado a servios (listando os hosts que oferecem aquele servio) formando uma
lista de possibilidades. Alm disso, o monitoramento de estado discutido antes
modifica essa lista para marcar os hosts atualmente disponveis que fornecem o
servio indicado. Essa lista modificada ser usada pelo balanceador de carga para
escolher o host que receber a nova conexo. Decidir qual ser o host exato
depende do algoritmo de balanceamento de carga associado quele cluster em
particular. O mais comum o round-robin simples, em que o balanceador de carga
percorre a lista de cima para baixo, alocando cada nova conexo para o prximo
host; chegando ao fim da lista, ele retorna ao incio. Embora isso seja simples e
previsvel, ele assume que todas as conexes tero uma carga e durao similares
no host de segundo plano, o que nem sempre verdade. Os algoritmos mais
avanados usam coisas como contagem de conexes atuais, utilizao do host e
at tempos de resposta reais do trfego existente para o host, a fim de escolher o
host mais apropriado no cluster de servios disponveis.
Os sistemas de balanceamento de carga suficientemente avanados sero capazes
de sintetizar as informaes do monitor de estado com os algoritmos de
balanceamento para incluir uma compreenso da dependncia de servios. Esse o
caso quando um nico host tem vrios servios, todos necessrios para completar o
pedido do usurio. Um exemplo comum seria em situaes de comrcio eletrnico,
em que um nico host fornecer servios HTTP padro (porta 80) bem como HTTPS
(SSL/TLS na porta 443). Em muitas dessas circunstncias, voc no quer que o
usurio v para um host que tenha um servio operacional, e o outro no. Em outras
palavras, se o servio HTTPS falhar em um host, voc tambm vai querer que o
servio HTTP daquele Host seja excludo da lista de servios disponveis naquele
cluster. Essa funcionalidade cada vez mais importante, visto que servios
baseados em HTTP se tornam mais diferenciados com o uso de XML e scripting.

Balancear ou no balancear a carga?
O balanceamento de carga na escolha de servios disponveis quando um cliente
inicia um pedido de transao apenas metade da soluo. Depois que a conexo
estabelecida, o balanceador de carga deve manter um registro para decidir se o
trfego daquele usurio deve ser balanceado ou no. De maneira geral, h dois
problemas especficos com o gerenciamento do trfego que teve a carga
balanceada: manuteno da conexo e persistncia.
Se o usurio estiver tentando utilizar uma conexo TCP de longa vida (telnet, FTP e
outras) que no se encerram imediatamente, o balanceador de carga deve se
certificar de que os vrios pacotes de dados trafegando por aquela conexo no
sejam encaminhados para outros hosts de servios disponveis. Esse processo
chamado de manuteno da conexo e exige duas capacidades principais: 1) manter
um registro das conexes abertas e do host de servios ao qual elas pertencem; e 2)
continuar a monitorar aquela conexo para que a tabela de conexes possa ser
atualizada quando a conexo for encerrada. Isso um procedimento padro para a
maioria dos balanceadores de carga.

Escrito por by KJ (Ken) Salchow, Jr. | Gerente, Gerncia de Produtos


_________________________________________________________________________________________
F5 Network, Inc - 6 -
Entretanto, cada vez mais comum o uso de conexes TCP mltiplas de vida curta
(por exemplo, o HTTP) pelo cliente para executar uma tarefa nica. Em alguns
casos, como a navegao comum na web, isso no faz diferena e cada novo
pedido pode ser encaminhado a qualquer um dos hosts de servios de segundo
plano; entretanto, h muitas outras instncias (como XML, carrinhos de compra,
HTTPS e afins) em que muito importante que vrias conexes do mesmo usurio
sejam encaminhadas ao mesmo host de servios de segundo plano, em vez de
terem a carga balanceada. Esse conceito chamado de persistncia ou afinidade
com servidor. H vrias maneiras de cuidar desse problema, dependendo do
protocolo e dos resultados desejados. Por exemplo, nas transaes HTTP
modernas, o servidor pode especificar uma conexo "keep alive" para agrupar as
mltiplas conexes de vida curta em uma nica conexo de vida longa, que pode ser
gerenciada como qualquer outra conexo de vida longa. Infelizmente, isso no o
suficiente para resolver o problema. O mais grave, com o aumento do uso dos
servios web, manter todas essas conexes abertas por mais tempo do que o
necessrio, sobrecarregando os recursos de todo o sistema. Nesses casos, a
maioria dos balanceadores de carga oferece outros mecanismos para criar uma
afinidade artificial com o servidor.
Uma das formas mais bsicas de persistncia a afinidade de endereo de origem.
Isso envolve o simples registro do IP de origem dos pedidos recebidos e do Host de
servios a que foram encaminhados, fazendo que todas as transaes futuras sejam
enviadas ao mesmo Host. Essa tambm uma forma simples de lidar com
dependncias de aplicativos, visto que pode ser aplicada em todos os servidores
virtuais e servios. Na prtica, entretanto, o uso disseminado de servidores proxy na
Internet, bem como em redes corporativas internas, inutilizou esse tipo de
persistncia; embora ela funcione, os servidores proxy escondem muitos usurios
por trs de um nico endereo IP, o que faz que o trfego desses usurios no
possa ser balanceado aps o pedido do primeiro usurio, basicamente anulando a
capacidade de balanceamento de carga. Hoje, a inteligncia dos dispositivos de
balanceamento de carga permite que voc abra os pacotes de dados e crie tabelas
persistentes com virtualmente qualquer coisa dentro deles. Dessa forma, voc pode
usar informaes mais exclusivas e identificveis como o nome de usurio para
manter a persistncia; entretanto, necessrio ser cuidadoso para garantir que
essas informaes identificveis do cliente sero exibidas em todos os pedidos
feitos, visto que todos os pacotes sem essa informao no sero considerados
persistentes e passaro pelo processo de balanceamento de carga, o que
provavelmente causaria erros no aplicativo.

O balanceamento
de carga hoje Esse documento descreveu os conceitos bsicos da tecnologia de balanceamento
de carga. importante compreender que essa tecnologia, embora ainda em uso,
considerada hoje como uma funo dos ADCs. Os ADCs evoluram dos primeiros
balanceadores de carga e completaram o processo de virtualizao de servios,
permitindo no apenas uma melhoria na disponibilidade, mas tambm no
desempenho em segurana do servios de aplicativos sendo solicitados. Hoje, a
maior parte das organizaes compreende que a mera capacidade de alcanar o
aplicativo no o torna utilizvel, e que aplicativos no-utilizveis significam tempo e
dinheiro desperdiados para a companhia que os implementou. Os ADCs permitem a
consolidao dos servios baseados na rede, como SSL/TLS, caching, compresso,
rate shaping, deteco de intrusos, firewalls e at o acesso remoto a um nico ponto
que pode ser compartilhado e reutilizado por todos os servios de aplicativos e todos
os hosts, criando uma rede virtualizada de distribuio de aplicativos. Ao mesmo
tempo, sem os fundamentos bsicos do balanceamento de carga descritos neste
documento, nenhuma das funcionalidades aprimoradas dos ADCs seria possvel.