Escrito por by KJ (Ken) Salchow, Jr.

| Gerente, Gerncia de Produtos

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 _________________________________________________________________________________________ F5 Network, Inc -1-

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

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.

_________________________________________________________________________________________ F5 Network, Inc -2-

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

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 Agora que temos um vocabulrio comum, podemos comear a examinar a transao bsico 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).

_________________________________________________________________________________________ F5 Network, Inc -3-

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

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 _________________________________________________________________________________________ F5 Network, Inc -4-

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

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. _________________________________________________________________________________________ F5 Network, Inc -5-

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

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.

_________________________________________________________________________________________ F5 Network, Inc -6-