Normalmente, é nesse ponto que surgem questões, como: o balanceador de carga decide para qual host encaminhar a conexão, e o que acontece se o host selecionado não estiver funcionando?
É que ele não responderá ao pedido do cliente e o tempo da conexão se esgotará, fazendo que ela falhe. É 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 não disponível antes de tentar estabelecer conexões com ele.
Existem vários níveis de monitoramento de estado, cada um deles com granularidade e foco crescentes.
Um monitor básico irá apenas executar um PING e aguardar a resposta do host, se o host não responder ao PING, é razoável assumir que os serviços definidos no host provavelmente não estão ativos e deveriam 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 está funcionando,por isso, a maioria dos dispositivos têm
a capacidade de executar algum tipo de “PINGS de serviço”, desde conexões TCP simples até a interação com o aplicativo por meio de scripts. Esses monitores de estado de alto nível não só oferecem mais confiança na disponibilidade do serviços (e não do host) como também permitem que o balanceador de carga distinga entre outros serviços em um mesmo 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 devem ser considerados como destinos válidos para o tráfego de usuários. Como o balanceador de carga decide para qual host encaminhar o pedido de conexão, cada servidor virtual tem um cluster dedicado a serviços (listando os hosts que oferecem aquele serviço) formando uma lista de possibilidades. Além disso, o monitoramento de estado modifica essa lista para marcar os hosts atualmente
disponíveis que fornecem o serviço indicado. Essa lista modificada será usada pelo balanceador de carga para escolher o host que receberá a nova conexão. 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 conexão para o próximo host; chegando ao fim da lista, ele retorna ao início. Embora isso seja simples e previsível, ele assume que todas as conexões terão uma carga e duração similares no host de segundo plano.
Os sistemas de balanceamento de carga suficientemente avançados serão capazes de sintetizar as informações do monitor de estado com os algoritmos de balanceamento para incluir uma compreensão da dependência de serviços. Esse é o caso quando um único host tem vários serviços, todos necessários para completar o pedido do usuário. Um exemplo comum seria em situações de comércio eletrônico, em que um único host fornecerá serviços HTTP padrão (porta 80) bem como HTTPS (SSL/TLS na porta 443). Em muitas dessas circunstâncias, você não quer que o usuário vá para um host que tenha um serviço operacional, e o outro não. Em outras palavras, se o serviço HTTPS falhar em um host, você também vai querer que o serviço HTTP daquele Host seja excluído da lista de serviços disponíveis naquele cluster. Essa funcionalidade é cada vez mais importante, visto que serviços baseados em HTTP se tornam mais diferenciados com o uso de XML e scripting.
MANUTENÇÃO DA CONEXÃO
Quando um cliente inicia um pedido de transação, o balanceamento de carga na escolha dos serviços é apenas metade da solução. Estando a conexão estabelecida, o balanceador de carga tem que manter um registro para escolher se o tráfego daqueleusuário deve ser balanceado ou não. Geralmente, há dois problemas específicos com o gerenciamento do tráfego que teve a carga balanceada: manutenção da conexão e persistência.
Se o usuário estiver tentando usar uma conexão TCP de grande duração (telnet, FTP e outras) que não se finalizam rapidamente, o balanceador de carga tem que se certificar de que os muitos pacotes de dados trafegando por aquela conexão não sejam direcionados para outros hosts de serviços disponíveis. Esse processo é chamado de manutenção da conexão e exige duas capacidades principais:
1) manter um registro das conexões abertas e do host de serviços ao qual elas pertencem;
2) continuar a monitorar aquela conexão para que a tabela de conexões possa ser atualizada quando a conexão for encerrada. Isso é um procedimento padrão para a maioria dos balanceadores de carga;
Entretanto, está se tornando muito comum o uso de conexões TCP múltiplas de vida curta (por exemplo, o HTTP) pelo cliente para executar uma só tarefa. Em alguns casos, como a navegação comum na web, isso é irrelevante e cada nova requisição pode ser direcionada a qualquer um dos hosts de serviços de segundo plano; entretanto, há muitas outras instâncias (como XML, carrinhos de compra, HTTPS e afins) em que é
imprescindível que várias conexões do mesmo usuário sejam direcionadas ao mesmo host de serviços de segundo plano, em vez de terem a carga balanceada. Esse conceito se chama persistência ou afinidade com servidor. Há muitas maneiras de cuidar desse problema, dependendo do protocolo e dos resultados desejados. Por exemplo, nas transações HTTP modernas, o servidor pode especificar uma conexão “keep alive” para
agrupar as várias conexões de vida curta em uma única conexão de vida longa, que pode ser gerenciada como qualquer outra conexão de vida longa. Infelizmente, isso não é o suficiente para resolver o problema. O mais grave, com o aumento do uso dos serviços web, é manter todas essas conexões abertas por mais tempo do que o necessário, 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 básicas de persistência é a afinidade de endereço de origem. Isso envolve o simples registro do IP de origem dos pedidos recebidos e do Host de serviços a que foram encaminhados, fazendo que todas as transações futuras sejam enviadas ao mesmo Host. Essa também é uma forma simples de lidar com
dependências de aplicativos, visto que pode ser aplicada em todos os servidores virtuais e serviços. Na prática, entretanto, o uso disseminado de servidores proxy na Internet, bem como em redes corporativas internas, inutilizou esse tipo de persistência; embora ela funcione, os servidores proxy escondem muitos usuários por trás de um único endereço IP, o que faz que o tráfego desses usuários não possa ser balanceado após o
pedido do primeiro usuário, basicamente anulando a capacidade de balanceamento de carga. Hoje, a inteligência 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 informações mais exclusivas e identificáveis como o nome de usuário para manter a persistência; entretanto, é necessário ser
cuidadoso para garantir que essas informações identificáveis do cliente serão exibidas em todos os pedidos feitos, visto que todos os pacotes sem essa informação não serão considerados persistentes e passarão pelo processo de balanceamento de carga, o que provavelmente causaria erros no aplicativo.
TRANSAÇÃO BÁSICA DO BALANCEAMENTO
O balanceador de carga normalmente fica alinhado entre o cliente e os hosts que fornecem os serviços desejados pelos clientes; como isto não é uma regra, mas uma boa prática em uma implementação considera-se que o balanceador de carga está configurado como servidor virtual que aponta para um cluster formado por dois pontos de serviço.
Na implementação é normal que os hosts tenham uma rota de retorno que aponte de volta para o balanceador, para que o tráfego de retorno seja processado por ele, no caminho de volta para o cliente. A transação básica de balanceamento de carga funciona:
1. O cliente tenta conectar ao serviço no balanceador de carga.
2. O balanceador de carga aceita a conexão e, após decidir qual host deve receber a conexão, muda o IP de destino (e talvez a porta) para combinar com o serviço do host selecionado (note que o IP de origem do cliente não é alterado).
3. O host aceita a conexão e responde ao cliente original pelo 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.
Proximo : Linux Virtual Server (LVS) – Balanceamento de Carga
Post Anterior : Balanceamento de Carga
Jaqueline Santos, Aline Lúcia, André Marques, Manoel Augusto, Renato Dórea,
Rodney Carlos, Éber Rodrigo – Faculdade de Tecnologia de Guaratinguetá (FATEC)
Gestão em TI 