Balanceamento de carga 101: conceitos básicos
Introdução
No mercado dinâmico e centrado em aplicações de hoje, as organizações estão sob uma pressão cada vez maior para fornecer as informações, os serviços e as experiências que seus clientes esperam — e fazer isso com rapidez, confiabilidade e segurança. As principais funções de rede e de aplicações, como balanceamento de carga, criptografia, aceleração e segurança, podem ser fornecidas por meio de Controladores de Entrega de Aplicações (ADCs), que são dispositivos físicos ou virtuais que atuam como proxies para servidores físicos. Com a explosão do número de aplicações e as exigências impostas às organizações pelo rigoroso ciclo de Integração Contínua e Implantação Contínua (CI/CD), não é de surpreender que o mercado de ADCs tenha uma projeção de atingir US$ 2,9 bilhões por ano até 2020.1
Mas, antes de avançarmos para o futuro, vamos analisar como chegamos até aqui. O balanceamento de carga baseado em rede é a base essencial sobre a qual os ADCs operam. Em meados da década de 1990, os primeiros dispositivos de hardware para balanceamento de carga começaram a ajudar as organizações a dimensionar suas aplicações, distribuindo as cargas de trabalho entre servidores e redes. Esses primeiros dispositivos eram independentes das aplicações e ficavam fora dos próprios servidores de aplicações, o que lhes permitia balancear a carga usando técnicas de rede simples. Em essência, esses dispositivos apresentavam um "endereço IP virtual" ao mundo externo e, quando os usuários tentavam se conectar, encaminhavam a conexão para o servidor real mais adequado, realizando a tradução bidirecional de endereços de rede (NAT).
No entanto, com o advento da virtualização e da computação em nuvem, surgiu uma nova geração de ADCs de balanceamento de carga na forma de edições virtuais fornecidas por software, projetadas para serem executadas em hipervisores. Atualmente, os appliances virtuais podem fornecer serviços de aplicações com a mesma variedade de recursos daqueles executados em hardware desenvolvido especificamente para essa finalidade. Além disso, essas edições virtuais eliminam grande parte da complexidade envolvida na migração de serviços de aplicações entre ambientes virtuais, de nuvem e híbridos, permitindo que as organizações implementem serviços de aplicações de forma rápida e fácil em ambientes de nuvem privada ou pública.
A mais nova tendência a chegar aos data centers é a conteinerização, um método de virtualização de aplicações que facilita a implantação e a execução de aplicações distribuídas. O processo isola as aplicações e as mantém em espaços de memória claramente delimitados em um sistema operacional compartilhado, o que torna o desenvolvimento e a implantação de uma aplicação não apenas mais fáceis, mas também mais rápidos do que a criação de um appliance virtual. Graças às melhorias significativas em portabilidade e desempenho, a conteinerização pode proporcionar às empresas maior escalabilidade e agilidade. No futuro, as arquiteturas de contêineres também poderão ajudar as organizações a aproveitar melhor os diferentes ambientes de nuvem.
Os ADCs atuais evoluíram a partir dos primeiros balanceadores de carga por meio do processo de virtualização de serviços. Agora, com edições virtuais baseadas exclusivamente em software, os ADCs podem não apenas melhorar a disponibilidade, mas também ajudar as organizações a fornecer os aplicativos escaláveis, seguros e de alto desempenho de que seus negócios precisam. No entanto, em última análise, todos esses serviços de aplicativos virtualizados, implantações de infraestrutura compartilhada e recursos de roteamento inteligente não seriam possíveis sem a base sólida da tecnologia de balanceamento de carga.
Para entender como as empresas podem enfrentar melhor os desafios complexos de um mercado em constante evolução, vamos explorar os fundamentos da entrega de aplicações: Introdução ao balanceamento de carga.
Conceitos básicos: terminologia
Antes de começarmos, vamos revisar a terminologia básica do balanceamento de carga. Isso seria mais fácil se todos usassem o mesmo vocabulário; infelizmente, cada fornecedor de dispositivos de balanceamento de carga (e, consequentemente, de ADCs) parece usar uma terminologia diferente. No entanto, com uma breve explicação, podemos esclarecer essa confusão.
Nó, host, membro e servidor
A maioria dos ADCs de balanceamento de carga utiliza os conceitos de nó, host, membro ou servidor; alguns empregam os quatro, mas cada um tem um significado diferente. Há dois conceitos básicos que todos esses termos procuram expressar. Um deles — geralmente chamado de nó ou servidor — refere-se ao próprio servidor físico ou virtual que receberá o tráfego do ADC. Esse conceito corresponde ao endereço IP do servidor físico e, na ausência de um balanceador de carga, seria o endereço IP para o qual o nome do servidor (por exemplo, www.example.com) seria resolvido. No restante deste documento, chamaremos esse conceito de host.
O segundo conceito é expresso pelo termo "membro" (infelizmente, também chamado de nó por alguns fabricantes). Um membro costuma ser um pouco mais específico do que um host, pois inclui a porta TCP da aplicação que efetivamente receberá o tráfego. Por exemplo, um host chamado www.example.com pode ser resolvido para o endereço 172.16.1.10, que representa o host, e pode ter uma aplicação (um servidor web) em execução na porta TCP 80, fazendo com que o endereço do membro seja 172.16.1.10:80. Em termos simples, o membro inclui a definição da porta da aplicação, além do endereço IP do servidor físico/virtual. No restante deste documento, chamaremos esse conceito de serviço.
Por que tanta complexidade? Porque a distinção entre um servidor e os serviços de aplicação executados nele permite que o balanceador de carga interaja individualmente com as aplicações, em vez de interagir com o hardware subjacente ou o hipervisor, seja em um data center ou na nuvem. Um host (172.16.1.10) pode ter mais de um serviço disponível (HTTP, FTP, DNS etc.). Ao definir cada aplicação de forma exclusiva (172.16.1.10:80, 172.16.1.10:21 e 172.16.1.10:53, por exemplo), o ADC pode aplicar balanceamento de carga e monitoramento de integridade específicos (um conceito que abordaremos mais adiante) com base nos serviços, e não no host.
Lembre-se de que a maioria das tecnologias baseadas em balanceamento de carga usa um termo para representar o host, ou servidor físico, e outro para representar os serviços disponíveis nele — neste caso, simplesmente host e serviços.
Pool, cluster e farm
O balanceamento de carga permite que as organizações distribuam o tráfego de entrada das aplicações entre vários destinos de back-end, incluindo implantações em nuvens públicas ou privadas. Portanto, é necessário contar com o conceito de um conjunto de destinos de back-end. Os clusters, como os chamaremos (também conhecidos como pools ou farms), são conjuntos de serviços semelhantes disponíveis em qualquer número de hosts. Por exemplo, todos os serviços que disponibilizam a página da empresa seriam reunidos em um cluster chamado "página da empresa", enquanto todos os serviços de comércio eletrônico seriam reunidos em um cluster chamado "comércio eletrônico".
Servidor virtual
Um servidor virtual é um proxy do servidor real (físico, virtual ou em contêiner). Combinado com um endereço IP virtual, ele constitui o endpoint da aplicação apresentado ao mundo externo.
Juntando tudo
Com a compreensão desses termos, já temos os conceitos básicos do balanceamento de carga. O ADC de balanceamento de carga apresenta servidores virtuais ao mundo externo. Cada servidor virtual aponta para um cluster de serviços hospedados em um ou mais hosts físicos.
Embora a Figura 2 possa não representar uma implantação real, ela fornece a estrutura básica para dar continuidade à discussão sobre o processo de balanceamento de carga e entrega de aplicações.
Como funciona o balanceamento de carga
Com esse vocabulário comum estabelecido, vamos analisar a transação simples de como a aplicação é entregue ao cliente. Conforme ilustrado, o ADC de balanceamento de carga normalmente fica em linha entre o cliente e os hosts que fornecem os serviços que ele deseja usar. Como ocorre com a maioria dos aspectos da entrega de aplicações, esse posicionamento não é uma regra, mas sim uma prática recomendada para qualquer tipo de implantação. Vamos supor também que o ADC já esteja configurado com um servidor virtual que aponta para um cluster composto por dois pontos de serviço. Nesse cenário de implantação, é comum que os hosts tenham uma rota de retorno apontando para o balanceador de carga, para que o tráfego de retorno seja processado por ele no caminho de volta ao cliente.
A transação básica de entrega de aplicações ocorre da seguinte forma:
- O cliente tenta se conectar ao serviço.
- O ADC aceita a conexão e, após decidir qual host deve recebê-la, altera o IP de destino (e possivelmente a porta) para corresponder ao serviço do host selecionado (observe que o IP de origem do cliente não é alterado).
- O host aceita a conexão e responde à origem original, o cliente, por meio de sua rota padrão, o ADC.
- O ADC intercepta o pacote de retorno do host e altera o IP de origem (e possivelmente a porta) para corresponder ao IP e à porta do servidor virtual, encaminhando o pacote de volta ao cliente.
- O cliente recebe o pacote de retorno, acreditando que ele veio do servidor virtual, e dá continuidade ao processo.
Este exemplo bastante simples é relativamente fácil de entender, mas há alguns elementos importantes a serem observados. Primeiro, do ponto de vista do cliente, ele envia pacotes ao servidor virtual e o servidor virtual responde — simples assim. Segundo, ocorre a NAT. É nesse ponto que o ADC substitui o IP de destino enviado pelo cliente (o do servidor virtual) pelo IP de destino do host escolhido para receber a solicitação por meio do balanceamento de carga. Terceiro, há a parte desse processo que torna a NAT "bidirecional". O IP de origem do pacote de retorno enviado pelo host será o IP do próprio host; se esse endereço não fosse alterado e o pacote fosse simplesmente encaminhado ao cliente, o cliente receberia um pacote de alguém a quem não fez nenhuma solicitação e simplesmente o descartaria. Em vez disso, o balanceador de carga, mantendo a conexão em memória, reescreve o pacote para que o IP de origem seja o do servidor virtual, resolvendo assim esse problema.
A decisão de entrega de aplicações
Normalmente, neste ponto, surgem duas perguntas: como o ADC de balanceamento de carga decide para qual host enviar a conexão? E o que acontece se o host selecionado não estiver funcionando?
Vamos discutir primeiro a segunda pergunta. O que acontece se o host selecionado não estiver funcionando? A resposta simples é que ele não responde à solicitação do cliente, e a tentativa de conexão acaba atingindo o tempo limite e falhando. Obviamente, essa não é uma situação desejável, pois não garante alta disponibilidade. É por isso que a maioria das tecnologias de balanceamento de carga inclui algum nível de monitoramento de integridade para determinar se um host está realmente disponível antes de tentar enviar conexões a ele.
Há vários níveis de monitoramento de integridade, cada um com granularidade e foco crescentes. Um monitor básico simplesmente enviaria um ping ao próprio host. Se o host não responder ao ping, é razoável supor que os serviços definidos nele provavelmente estejam indisponíveis e devam ser removidos do cluster de serviços disponíveis. Infelizmente, mesmo que o host responda ao ping, isso não significa necessariamente que o serviço em si esteja funcionando. Portanto, a maioria dos dispositivos pode realizar algum tipo de "ping de serviço", desde simples conexões TCP até a interação com a aplicação por meio de uma interação com script ou inteligente. Esses monitores de integridade de nível mais alto não apenas proporcionam maior confiança na disponibilidade dos serviços propriamente ditos (em vez do host), como também permitem que o balanceador de carga diferencie vários serviços em um único host. O balanceador de carga entende que, embora um serviço possa estar indisponível, outros serviços no mesmo host podem estar funcionando perfeitamente e ainda devem ser considerados destinos válidos para o tráfego dos usuários.
Isso nos traz de volta à primeira pergunta: como o ADC decide para qual host enviar uma solicitação de conexão? Cada servidor virtual tem um cluster específico e dedicado de serviços (que relaciona os hosts que oferecem esse serviço), formando a lista de possibilidades. Além disso, o monitoramento de integridade modifica essa lista para criar uma relação dos hosts "atualmente disponíveis" que fornecem o serviço indicado. É a partir dessa lista modificada que o ADC escolhe o host que receberá uma nova conexão. A escolha do host exato depende do algoritmo de balanceamento de carga associado a esse cluster específico. Alguns desses algoritmos incluem o de menor número de conexões, o de proporção dinâmica e um round-robin simples, no qual o balanceador de carga percorre a lista a partir do início e atribui cada nova conexão ao host seguinte; ao chegar ao fim da lista, ele simplesmente recomeça do início. Embora esse método seja simples e bastante previsível, ele pressupõe que todas as conexões terão carga e duração semelhantes no host de back-end, o que nem sempre é verdade. Algoritmos mais avançados usam fatores como o número de conexões atuais, a utilização do host e até mesmo os tempos de resposta reais do tráfego existente para o host, a fim de escolher o host mais adequado entre os serviços disponíveis no cluster.
Sistemas de entrega de aplicações suficientemente avançados também serão capazes de combinar informações de monitoramento de integridade com algoritmos de balanceamento de carga, levando em conta as dependências entre serviços. Isso é especialmente útil quando um único host oferece vários serviços, todos necessários para atender à solicitação do usuário. Nesse caso, não é desejável direcionar o usuário a um host no qual um serviço esteja operacional, mas outro não. Em outras palavras, se um serviço falhar no host, o outro serviço desse host também deverá ser removido da lista de serviços disponíveis do cluster. Essa funcionalidade torna-se cada vez mais importante à medida que os serviços se diferenciam com o uso de HTML e scripts.
Fazer balanceamento de carga ou não?
A parte do balanceamento de carga que envolve a seleção de um serviço disponível quando um cliente inicia uma solicitação de transação representa apenas metade da solução. Depois que a conexão é estabelecida, o ADC precisa monitorar se o tráfego subsequente desse usuário deve ser balanceado. Em geral, há duas questões específicas relacionadas ao tratamento do tráfego subsequente após o balanceamento de carga: manutenção da conexão e persistência.
Manutenção da conexão
Se o usuário estiver tentando utilizar uma conexão TCP de longa duração (porta 21: FTP, porta 23: Telnet ou outra) que não seja encerrada imediatamente, o balanceador de carga deverá garantir que os vários pacotes de dados transmitidos por essa conexão não sejam distribuídos entre outros hosts de serviço disponíveis. Isso é chamado de manutenção de conexão e requer dois recursos essenciais. O primeiro é a capacidade de acompanhar as conexões abertas e o serviço de host ao qual elas pertencem. O segundo é a capacidade do balanceador de carga de continuar monitorando essa conexão para que a tabela de conexões possa ser atualizada quando ela for encerrada. Esse é um recurso bastante comum na maioria dos ADCs.
Persistência
No entanto, é cada vez mais comum que o cliente use várias conexões TCP de curta duração (por exemplo, porta 80: HTTP) para realizar uma única tarefa. Em alguns casos, como na navegação padrão na Web, isso não importa, e cada nova solicitação pode ser direcionada a qualquer um dos hosts de serviço de back-end. Porém, há muitas situações (XML, comércio eletrônico e assim por diante) em que é extremamente importante que várias conexões do mesmo usuário sejam direcionadas ao mesmo host de serviço de back-end, sem balanceamento de carga. Esse conceito é chamado de persistência ou afinidade de servidor.
Há várias maneiras de lidar com isso, dependendo do protocolo e dos resultados desejados. Por exemplo, nas transações HTTP modernas, o servidor pode especificar uma conexão "keep-alive", que transforma essas várias conexões de curta duração em uma única conexão de longa duração, que pode ser tratada da mesma forma que as demais conexões de longa duração. No entanto, isso proporciona apenas um pequeno alívio, principalmente porque, à medida que aumenta o uso de serviços web e móveis, manter todas as conexões abertas por mais tempo do que o necessário sobrecarrega os recursos de todo o sistema. É por isso que, atualmente — em nome da escalabilidade e da portabilidade —, muitas organizações estão adotando a criação de aplicações sem estado que dependem de APIs. Isso significa, basicamente, que o servidor descartará todas as informações da sessão para reduzir a carga sobre os recursos e, nesses casos, o estado é mantido por meio da transmissão de IDs de sessão, bem como pelo conceito de persistência.
Uma das formas mais básicas de persistência é a afinidade por endereço de origem, que consiste simplesmente em registrar o endereço IP de origem das solicitações recebidas e o host de serviço para o qual elas foram direcionadas pelo balanceamento de carga, fazendo com que todas as transações futuras sejam encaminhadas ao mesmo host. Duas maneiras de fazer isso são usando IDs de sessão SSL e cookies. A persistência SSL rastreia a sessão SSL por meio de IDs de sessão SSL, o que significa que, mesmo quando o endereço IP do cliente muda, o balanceador de carga reconhece a persistência da sessão com base no ID da sessão. A persistência baseada em cookies oferece a opção de inserir um cookie no computador do cliente para identificar uma sessão de forma exclusiva e, em seguida, consultar esse cookie nas solicitações, para que a conexão seja encaminhada ao servidor correto.
Atualmente, a inteligência dos ADCs permite que as organizações abram os pacotes de dados e criem tabelas de persistência para praticamente qualquer informação contida neles. Isso possibilita o uso de informações exclusivas, como o nome de usuário, para manter a persistência. No entanto, as organizações devem garantir que essas informações identificáveis do cliente estejam presentes em todas as solicitações, pois os pacotes que não as contiverem não terão a persistência mantida e passarão novamente pelo balanceamento de carga, o que provavelmente interromperá o funcionamento da aplicação.
Conclusão
No início, o balanceamento de carga se concentrava em distribuir as cargas de trabalho por toda a rede e garantir a disponibilidade de aplicações e serviços. No entanto, à medida que a tecnologia evoluiu, os balanceadores de carga se tornaram plataformas de entrega de aplicações, garantindo que as aplicações essenciais de uma organização tivessem alta disponibilidade e segurança. Embora o balanceamento de carga básico continue sendo a base da entrega de aplicações, os ADCs modernos oferecem funcionalidades muito mais avançadas.
As empresas percebem que simplesmente conseguir acessar uma aplicação não significa que ela seja utilizável — e aplicações inutilizáveis representam desperdício de tempo e dinheiro para a organização que as implementa. É aí que entra o ADC moderno, permitindo que as organizações consolidem serviços baseados em rede, como descarregamento de SSL/TLS, armazenamento em cache, compactação, controle de tráfego, detecção de intrusões, firewalls de aplicações e até mesmo acesso remoto, em um único ponto estratégico que pode ser compartilhado e reutilizado por todos os serviços de aplicações e hosts para criar uma Rede de Entrega de Aplicações virtualizada. Isso permite que as equipes de rede, aplicações e operações respondam melhor às demandas de negócios por prazos de entrega mais curtos e maior escalabilidade, sem jamais comprometer a segurança.
Se quiser saber mais sobre como funciona a entrega avançada de aplicações e sobre o futuro dos ADCs, leia A evolução dos controladores de entrega de aplicações e Vá além do simples balanceamento de carga.
1 http://www.strategyr.com/MarketResearch/Application_Delivery_Controllers_ADC_Market_Trends.asp
PUBLICADO EM 10 DE MAIO DE 2017