Balanceamento de carga 101: Porcas e parafusos

No mercado dinâmico e centrado em aplicativos de hoje, as organizações estão sob cada vez mais pressão para fornecer as informações, serviços e experiências que seus clientes esperam — e fazê-lo de forma rápida, confiável e segura. As principais funções de rede e aplicativo, como balanceamento de carga, criptografia, aceleração e segurança, podem ser fornecidas por meio de Controladores de Entrega de Aplicativos (ADC), que são dispositivos físicos ou virtuais que funcionam como proxies para servidores físicos. Com a explosão de aplicativos, bem como as demandas impostas às organizações pelo rigoroso ciclo de Integração Contínua e Implantação Contínua (CI/CD), não é de se admirar que o mercado de ADCs esteja projetado para atingir US$ 2,9 bilhões por ano até 2020.¹

Mas antes de avançarmos para o futuro, vamos ver como chegamos 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 de balanceamento de carga começaram a ajudar as organizações a dimensionar seus aplicativos distribuindo cargas de trabalho entre servidores e redes. Esses primeiros dispositivos eram neutros em relação à aplicação e residiam fora dos próprios servidores de aplicação, o que significa que podiam balancear a carga usando técnicas de rede simples. Em essência, esses dispositivos apresentariam um "endereço IP virtual" para o mundo externo e, quando os usuários tentassem se conectar, eles encaminhariam a conexão para o servidor real mais apropriado, fazendo a tradução bidirecional de endereços de rede (NAT).

No entanto, com o advento da virtualização e da computação em nuvem, uma nova iteração de ADCs de balanceamento de carga chegou como edições virtuais entregues por software, destinadas a serem executadas em hipervisores. Hoje, os dispositivos virtuais podem fornecer serviços de aplicativos com a mesma amplitude de recursos daqueles executados em hardware desenvolvido especificamente. Além disso, essas edições virtuais eliminam grande parte da complexidade envolvida na movimentação de serviços de aplicativos entre ambientes virtuais, de nuvem e híbridos, permitindo que as organizações criem serviços de aplicativos de forma rápida e fácil em ambientes de nuvem privada ou pública.

A mais nova tendência que chega ao data center é a conteinerização, um método de virtualização de aplicativos que ajuda a implantar e executar aplicativos distribuídos. O processo isola os aplicativos e os contém em espaços de memória claramente delimitados em um sistema operacional compartilhado, o que não apenas torna o desenvolvimento e a implantação de um aplicativo mais fácil do que a criação de um dispositivo virtual, mas também mais rápido. Devido às melhorias drásticas 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 dos primeiros balanceadores de carga até o processo de virtualização de serviços. E agora, com edições virtuais somente de software, os ADCs podem não apenas melhorar a disponibilidade, mas também ajudar as organizações a fornecer aplicativos escaláveis, de alto desempenho e seguros que seus negócios exigem. No final, porém, 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 do mercado em evolução dinâmica, vamos explorar a base da entrega de aplicativos: Balanceamento de carga 101.

Antes de começar, vamos revisar a terminologia básica do balanceamento de carga. Isso seria mais fácil se todos usassem o mesmo léxico; infelizmente, cada fornecedor de dispositivos de balanceamento de carga (e, por sua vez, ADCs) parece usar terminologia diferente. Com uma pequena explicação, no entanto, podemos acabar com a confusão.

A maioria dos ADCs de balanceamento de carga utiliza os conceitos de nó, host, membro ou servidor; alguns têm todos os quatro, mas eles significam coisas diferentes. Há dois conceitos básicos que todos esses termos tentam expressar. Um conceito — geralmente chamado de nó ou servidor — é a ideia do próprio servidor físico ou virtual que receberá tráfego do ADC. Isso é sinônimo do 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) resolveria. No restante deste artigo, nos referiremos a esse conceito como host.

O segundo conceito é expresso pelo termo "membro" (infelizmente também chamado de nó por alguns fabricantes). Um membro geralmente é um pouco mais definido que um host, pois inclui a porta TCP do aplicativo real que receberá o tráfego. Por exemplo, um host chamado www.example.com pode ser resolvido para um endereço de 172.16.1.10, que representa o host, e pode ter um aplicativo (um servidor web) em execução na porta TCP 80, tornando o endereço do membro 172.16.1.10:80. Simplificando, o membro inclui a definição da porta do aplicativo, bem como o endereço IP do servidor físico/virtual. No restante deste artigo, nos referiremos a isso como serviço.

Por que toda essa complexidade? Porque a distinção entre um servidor e os serviços de aplicativos em execução nele permite que o balanceador de carga interaja individualmente com os aplicativos em vez do hardware ou hipervisor subjacente, em um datacenter 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 aplicativo exclusivamente (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 exclusivos (um conceito que discutiremos mais tarde) com base nos serviços em vez do 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.

O balanceamento de carga permite que as organizações distribuam o tráfego de entrada de aplicativos entre vários destinos de back-end, incluindo implantações em nuvens públicas ou privadas. Portanto, é necessário ter o conceito de uma coleção de destinos de back-end. Clusters, como os chamaremos (também conhecidos como pools ou farms), são coleções de serviços semelhantes disponíveis em qualquer número de hosts. Por exemplo, todos os serviços oferecidos pela página web da empresa seriam reunidos em um cluster chamado "página web da empresa" e todos os serviços que oferecem serviços de comércio eletrônico seriam reunidos em um cluster chamado "comércio eletrônico".

Um servidor virtual é um proxy do servidor real (físico, virtual ou contêiner). Combinado com um endereço IP virtual, este é o ponto de extremidade do aplicativo que é apresentado ao mundo externo.

Com a compreensão desses termos, temos os conceitos básicos do balanceamento de carga. O ADC de balanceamento de carga apresenta servidores virtuais para o mundo externo. Cada servidor virtual aponta para um cluster de serviços que residem em um ou mais hosts físicos.

Embora a Figura 2 possa não ser representativa de nenhuma implantação no mundo real, ela fornece a estrutura elementar para continuar uma discussão sobre o processo de balanceamento de carga e entrega de aplicativos.

Com esse vocabulário comum estabelecido, vamos examinar a transação simples de como o aplicativo é entregue ao cliente. Conforme ilustrado, o ADC de balanceamento de carga normalmente ficará em linha entre o cliente e os hosts que fornecem os serviços que o cliente deseja usar. Como acontece com a maioria das coisas na entrega de aplicativos, esse posicionamento não é uma regra, mas sim uma prática recomendada em qualquer tipo de implantação. Vamos também supor 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 que aponta para o balanceador de carga para que o tráfego de retorno seja processado por meio dele no caminho de volta ao cliente.

A transação básica de entrega do aplicativo é a seguinte:

• 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 à fonte original, o cliente, por meio de sua rota padrão, o ADC.
• O ADC intercepta o pacote de retorno do host e agora altera o IP de origem (e possível porta) para corresponder ao IP e à porta do servidor virtual e encaminha o pacote de volta ao cliente.
• O cliente recebe o pacote de retorno, acreditando que ele veio do servidor virtual, e continua o processo.

Este exemplo muito simples é relativamente direto, mas há alguns elementos importantes a serem observados. Primeiro, até onde o cliente sabe, ele envia pacotes para o servidor virtual e o servidor virtual responde — simples. Em segundo lugar, ocorre o NAT. É aqui que o ADC substitui o IP de destino enviado pelo cliente (do servidor virtual) pelo IP de destino do host para o qual ele escolheu balancear a carga da solicitação. A terceira é a parte desse processo que torna o NAT "bidirecional". O IP de origem do pacote de retorno do host será o IP do host; se esse endereço não fosse alterado e o pacote fosse simplesmente encaminhado ao cliente, o cliente estaria recebendo um pacote de alguém de quem não solicitou um e simplesmente o descartaria. Em vez disso, o balanceador de carga, lembrando-se da conexão, reescreve o pacote para que o IP de origem seja o do servidor virtual, resolvendo assim o problema.

Normalmente neste ponto surgem duas questões: 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 questão. 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 eventualmente expira e falha. Obviamente, essa não é uma circunstância preferencial, 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.

Existem vários níveis de monitoramento de saúde, cada um com granularidade e foco crescentes. Um monitor básico simplesmente executaria ping no próprio host. Se o host não responder ao ping, é uma boa suposição que quaisquer serviços definidos no host provavelmente estejam inativos 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 fazer "pings de serviço" de algum tipo, desde simples conexões TCP até interagir com o aplicativo por meio de uma interação inteligente ou com script. Esses monitores de integridade de nível superior não apenas fornecem maior confiança na disponibilidade dos serviços reais (em oposição ao host), mas também permitem que o balanceador de carga diferencie entre 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 bem e ainda devem ser considerados destinos válidos para o tráfego do usuário.

Isso nos traz de volta à primeira questão: Como o ADC decide para qual host enviar uma solicitação de conexão? Cada servidor virtual tem um cluster específico de serviços dedicados (listando os hosts que oferecem aquele serviço) que compõe a lista de possibilidades. Além disso, o monitoramento de integridade modifica essa lista para criar uma lista de hosts "atualmente disponíveis" que fornecem o serviço indicado. É dessa lista modificada que o ADC escolhe o host que receberá uma nova conexão. A decisão sobre o host exato depende do algoritmo de balanceamento de carga associado a esse cluster específico. Alguns desses algoritmos incluem menos conexões, taxa dinâmica e um round robin simples, onde o balanceador de carga simplesmente percorre a lista começando do topo e aloca cada nova conexão para o próximo host; quando chega ao final da lista, ele simplesmente começa novamente no topo. Embora isso seja simples e muito previsível, 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 coisas como contagens de conexões atuais, utilização do host e até mesmo tempos de resposta do mundo real para o tráfego existente no host, a fim de escolher o host mais apropriado entre os serviços de cluster disponíveis.

Sistemas de entrega de aplicativos suficientemente avançados também serão capazes de sintetizar informações de monitoramento de integridade com algoritmos de balanceamento de carga para incluir uma compreensão da dependência de serviço. Isso é útil principalmente em casos em que um único host tem vários serviços, todos necessários para concluir a solicitação do usuário. Nesse caso, você não quer que um usuário acesse um host que tenha um serviço operacional, mas o outro não. Em outras palavras, se um serviço falhar no host, você também deseja que o outro serviço do host seja retirado da lista de serviços disponíveis do cluster. Essa funcionalidade é cada vez mais importante à medida que os serviços se tornam mais diferenciados com HTML e scripts.

A parte do balanceamento de carga que envolve escolher um serviço disponível quando um cliente inicia uma solicitação de transação é apenas metade da solução. Depois que a conexão é estabelecida, o ADC deve monitorar se o tráfego seguinte daquele usuário deve ter a carga balanceada. Geralmente, há dois problemas específicos ao lidar com o tráfego subsequente após o balanceamento de carga: manutenção da conexão e persistência.

Se o usuário estiver tentando utilizar uma conexão TCP de longa duração (Porta 21: FTP, Porta 23: Telnet ou outro) que não fecha imediatamente, o balanceador de carga deve garantir que vários pacotes de dados transportados por essa conexão não sejam balanceados para outros hosts de serviço disponíveis. Isso é manutenção de conexão e requer dois recursos principais. A primeira é a capacidade de monitorar conexões abertas e o serviço host ao qual elas pertencem. Em segundo lugar, o balanceador de carga deve ser capaz de continuar monitorando essa conexão para que a tabela de conexão possa ser atualizada quando a conexão for fechada. Isso é algo bastante comum para a maioria dos ADCs.

No entanto, é cada vez mais comum quando o cliente usa 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 ir para qualquer um dos hosts de serviço de back-end; no entanto, há muitos casos (XML, comércio eletrônico e assim por diante) em que é extremamente importante que várias conexões do mesmo usuário vão para o mesmo host de serviço de back-end e não sejam balanceadas por carga. Esse conceito é chamado de persistência ou afinidade do servidor.

Há várias maneiras de abordar isso, dependendo do protocolo e dos resultados desejados. Por exemplo, em transações HTTP modernas, o servidor pode especificar uma conexão "keep-alive", que transforma essas múltiplas conexões de curta duração em uma única conexão de longa duração, que pode ser manipulada da mesma forma que as outras conexões de longa duração. No entanto, isso proporciona apenas um pequeno alívio, principalmente porque, à medida que o uso de serviços da web e móveis aumenta, manter todas as conexões abertas por mais tempo do que o necessário sobrecarrega os recursos de todo o sistema. É por isso que hoje — em prol da escalabilidade e da portabilidade — muitas organizações estão migrando para a criação de aplicativos sem estado que dependem de APIs. Isso significa basicamente que o servidor esquecerá todas as informações da sessão para reduzir a carga nos recursos e, nesses casos, o estado é mantido pela passagem de IDs de sessão, bem como pelo conceito de persistência.

Uma das formas mais básicas de persistência é a afinidade de endereço de origem, que envolve simplesmente registrar o endereço IP de origem das solicitações recebidas e o host de serviço para o qual elas foram balanceadas, e fazer com que todas as transações futuras vão para o 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 usando IDs de sessão SSL, o que significa que mesmo quando o endereço IP do cliente muda, o balanceador de carga reconhecerá a sessão como persistente com base no ID da sessão. A persistência baseada em cookie oferece a opção de inserir um cookie no computador de um cliente para identificar exclusivamente uma sessão e, em seguida, fazer referência a esse cookie em solicitações, para que a conexão vá para o servidor correto.

Hoje, a inteligência dos ADCs permite que as organizações abram os pacotes de dados e criem tabelas de persistência para praticamente qualquer coisa dentro deles. Isso permite que eles usem informações exclusivas, como 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 feitas, pois quaisquer pacotes sem elas não serão persistidos e sofrerão balanceamento de carga novamente, provavelmente interrompendo o aplicativo.

No início, o balanceamento de carga se concentrava em distribuir cargas de trabalho pela rede e garantir a disponibilidade de aplicativos e serviços. No entanto, conforme a tecnologia evoluiu, os balanceadores de carga se tornaram plataformas para entrega de aplicativos, garantindo que os aplicativos críticos de uma organização estivessem altamente disponíveis e seguros. Embora o balanceamento de carga básico continue sendo a base da entrega de aplicativos, os ADCs modernos oferecem funcionalidades muito mais aprimoradas.

As empresas percebem que simplesmente conseguir acessar um aplicativo não o torna utilizável — e aplicativos inutilizáveis significam desperdício de tempo e dinheiro para a organização que os implementa. É aí que entra o ADC moderno, permitindo que as organizações consolidem serviços baseados em rede, como descarregamento SSL/TLS, cache, compactação, modelagem de taxas, detecção de intrusão, firewalls de aplicativos e até mesmo acesso remoto em um único ponto estratégico que pode ser compartilhado e reutilizado em todos os serviços de aplicativos e todos os hosts para criar uma Rede de Distribuição de Aplicativos virtualizada. Isso permite que as equipes de rede, aplicativos e operações respondam melhor às demandas comerciais por prazos de entrega mais curtos e maior escalabilidade, sem nunca sacrificar a necessidade de segurança.

Se você quiser saber mais sobre como funciona a entrega avançada de aplicativos e o futuro dos ADCs, leia A evolução dos controladores de entrega de aplicativos e Vá além do bom e velho balanceamento de carga .