Balanceamento de Carga por Software
Vamos dar agora uma rápida vista de olhos às soluções de balanceamento de carga executadas sem a necessidade de hardware específico, como os ADCs já discutidos em artigos anteriores. Embora existam várias soluções de software disponíveis para o mundo Unix / Linux, vou-me concentrar principalmente nas tecnologias da Microsoft. No futuro pretendo escrever uma série de tutoriais passo a passo e então eu poderei fazê-lo também para a comunidade Linux.
Balanceamento de Carga por DNS
O balanceamento de carga por DNS é uma abordagem popular e simples para as solicitações de balanceamento de servidores e consiste basicamente na criação de múltiplas entradas DNS no registo do DNS para o domínio, ou seja, o servidor DNS autoritário contém vários registos do tipo "A" para um único host.
Imaginemos que queremos equilibrar a carga em www.meusite.com, e temos três servidores web com endereços IP 64.13.192.120, 64.13.192.121 e 64.13.192.122, respectivamente, cada um deles tem uma cópia completa do site e assim, seja para qual deles for direccionado o pedido, a resposta fornecida será sempre a mesma.
Para implementar isso, basta criar as seguintes entradas no DNS:
www.meusite.com 64.13.192.120
www.meusite.com 64.13.192.121
www.meusite.com 64.13.192.122
Quando chega um pedido de DNS para o servidor DNS resolver o nome de domínio, ele pode dar um dos endereços IP do servidor com base em diferentes critérios, como a simples rotatividade (round-robin) ou localização geográfica redireccionando assim o pedido para um dos servidores de um grupo de servidores. Uma vez que o domínio seja resolvido para um dos servidores especificados, as solicitações subsequentes dos clientes usando o mesmo servidor DNS local serão enviadas ao mesmo servidor mas as provenientes de outros DNSs locais serão encaminhadas para outro servidor. Este processo é conhecido como Round Robin DNS (RRDNS).
Geralmente, são estes os passos que ocorrem assim que é feita uma consulta DNS:
- Quando um cliente tenta aceder ao site, é realizada uma pesquisa no DNS local para determinar qual é o endereço IP correspondente;
- O pedido de endereço chega ao servidor de DNS autoritário do domínio;
- A primeira vez que esta consulta é feita, o servidor DNS remoto pode retornar todos os registos de endereços que ele tem para o site;
- O servidor DNS local, em seguida, determina o endereço de registo para retornar ao cliente;
- Se todos os registos são retornados, o cliente utilizará o primeiro que lhe é atribuído;
- O servidor responde ao cliente e atende a pedido;
- A cada pedido, o algoritmo Round Robin roda os endereços a retornar pela ordem em que eles estão;
- Cada consulta DNS irá resultar num cliente a usar um endereço IP diferente;
- Esta rotação de endereços irá distribuir de pedidos para os servidores.
- Alguns clientes guardam em cache as pesquisas realizadas a fim de melhorar o desempenho e assim as consultas subsequentes não podem ser executadas porque a resolução de endereço já foi realizada. O resultado final é que o mesmo endereço IP será devolvido para vários clientes, ou seja, o mecanismo da cache quebra este esquema de balanceamento de carga;
- O RRDNS não lida bem com máquinas que respondem porque o servidor DNS não tem absolutamente nenhum meio de monitorizar o estado dos hosts individuais e, consequentemente, um servidor DNS utilizando o algoritmo Round Robin poderá muito bem retornar o endereço IP de um servidor que tenha sido desligado ou que está ligado, mas teve uma falha nos seus serviços;
- Finalmente, há ocasiões em que o estado da sessão é importante e é necessário amarrar o cliente ao mesmo servidor, o que é algo que não pode ser feito usando o Round Robin DNS.
Network Load Balancing
A solução Network Load Balancing (NLB) da Microsoft é uma implementação baseada em software que é executada em cada nó de cluster usando um algoritmo de hash que usa o endereço IP, ou endereço IP e a porta, de um pedido e determina que nó (host) no cluster irá processar este pedido. Todos os nós no cluster recebem todos os pacotes de tráfego e a determinação de qual o nó responsável por responder é feita através da aplicação de um filtro para cada pacote e assim apenas um nó acaba por atender a solicitação.
O conceito por trás do NLB é bastante simples: cada servidor num cluster (não confundir com o Microsoft Cluster Service) com balanceamento de carga é configurado com um endereço IP “virtual" e este endereço IP é configurado em todos os servidores que participam no "cluster" do balanceamento de carga. Sempre que uma solicitação é feita para este IP virtual, um driver de rede em cada uma destas máquinas intercepta a solicitação para o endereço IP e reencaminha o pedido para uma das máquinas do cluster com balanceamento de carga com base em regras que podem ser configuradas para cada um dos servidores no cluster.
O software do NLB actua como um dispositivo de rede virtual, com seu próprio endereço IP e os dispositivos reais (as portas Ethernet) são associados com o software NLB. Em vez de utilizar e anunciar os endereços IP das portas, o sistema usa o endereço IP do software NLB o que acaba faz com que o software NLB e seus portos sejam vistos pelos clientes como um dispositivo único.
À medida que novas máquinas são adicionadas ou removidas do cluster, e para que a carga seja distribuída correctamente entre os nós activos, o algoritmo deve ser executado novamente num processo de reavaliação extremamente importante chamado convergência. Também é importante perceber que em momento algum é possível ao NLB saber qual a carga em de cada nó do cluster porque o NLB não consegue determinar se a utilização da CPU de um nó é extremamente alta, ou se um nó tem pouca ou nenhuma memória disponível para processar o pedido.
Se um nó no cluster experimentar uma saturação desses recursos, o NLB vai continuar a enviar-lhe pedidos até que o nó pare de enviar mensagens de pulsação/sincronização (heartbeat), momento em que o nó é automaticamente retirado do cluster. No entanto, se o nó continua a enviar as mensagens de heartbeat, permanecerá no cluster, embora possa estar num estado inutilizável.
A fim de monitorizar o estado do cluster, todos os nós transmitem uma mensagem de pulsação de 1500 bytes por segundo para todos os outros nós permitindo assim que qualquer nó no cluster possa facilmente determinar quando é necessária uma operação de convergência. A frequência com que estas mensagens de pulsação são transmitidas pode ser definida explicitamente, alterando o valor da chave do registo AliveMsgPeriod, mas se esse valor for alterado (1000 milissegundos) tem que o ser em cada nó no cluster para evitar problemas de funcionalidade no NLB.
O NLB fornece alta disponibilidade para aplicações “stateless” tais como servidores Web, adicionando servidores adicionais à medida que aumenta a carga e pode ser usado com praticamente qualquer aplicação TCP ou UDP. O termo " stateless" refere-se aplicações que respondem a cada solicitação do cliente como uma operação isolada o que significa que solicitações tratadas antes de um pedido de determinado cliente não têm nenhum impacto sobre a transacção actual.
Um bom exemplo disto é um servidor Web; para cada solicitação de uma página da Web, o servidor reúne todas as informações necessárias para apresentar essa página ao cliente. O servidor então reúne todas as informações necessárias para a solicitação do cliente seguinte, e assim por diante. Como cada solicitação fornece toda a informação que um servidor stateless precisa para completar a transacção, é uma questão relativamente simples para qualquer solicitação ser manipulada por qualquer uma das cópias idênticas de um site em execução em qualquer um dos hosts de um cluster NLB.
O diagrama abaixo ilustra o uso do NLB:
Cada servidor no cluster é totalmente auto-suficiente, o que significa que deve ser capaz de funcionar sem qualquer outro no cluster à excepção da base de dados (se esta existir e que não é parte do cluster NLB). Isso significa que cada servidor deve ser configurado separadamente mas no caso de alojar um site estático, todos os arquivos HTML e as imagens devem ser replicadas entre todos os servidores.
Há uma série de benefícios significativos na implantação de uma solução de NLB, nomeadamente:
- O Network Load Balancing é muito eficiente e pode fornecer um grande incremento de desempenho de cada máquina adicionado ao cluster;
- O NLB tem capacidade de tolerância a falhas. Muitas implementações de balanceamento de carga, como o Round Robin DNS (RRDNS), continuam a enviar pedidos a servidores que "morreram" até que os administradores do sistema reparem nesse facto e executem manualmente uma alteração de configuração. A chave, além do balanceamento de carga, é a redundância; se qualquer máquina no cluster for abaixo o NLB irá reequilibrar as solicitações de entrada para os servidores ainda em funcionamento lidando assim com cenários de fontes de alimentação queimadas, placas de rede avariadas, falhas no disco rígido primário, etc;
- Este nível de redundância aumentando a capacidade de balanceamento de carga torna-se simplesmente uma questão de adicionar máquinas ao cluster, o que resulta numa praticamente ilimitada escalabilidade da aplicação;
- O NLB funciona com qualquer aplicação assente nos protocolos TCP ou UDP. Isto significa que dentro de uma organização podem ser configurados uma variedade de clusters NLB, e cada um pode ter a sua própria função específica. Por exemplo, um cluster pode ser dedicado a lidar com todo o tráfego HTTP vindo da Internet, enquanto outro pode ser utilizado para servir todos os pedidos da intranet. Se os funcionários têm uma grande necessidade de transferência de arquivos, pode ser criado um cluster de FTP centralizando o armazenamento de ficheiros com monitorização de uploads e downloads;
- De longe, uma das maiores vantagens da NLB é a sua facilidade de uso. O NLB instala apenas um componente de driver de redes sem absolutamente nenhuma necessidade de hardware especial o que não só facilita a implementação de uma solução de balanceamento de carga, como também reduz significativamente os custos.