O experimento em questão tem o propósito de verificar a funcionalidade do balanceador de carga como um serviço em nuvem (PaaS), bem como a simplicidade de sua implementação.
Para a experiência foram provisionados: um Elastic Load Balancer (ELB), três instâncias de servidor Ubuntu (IaaS) e um serviço de banco de dados (Relational Database Service – RDS).

As instâncias em questão foram criadas a partir do Amazon AWS EC2. Cada instância se trata de um servidor Ubuntu 16.04 LTS, configurado com Apache2 e PHP5. A aplicação executada nesse servidor busca uma página PHP, que se conecta a um banco de dados MySQL na versão 5, presente em outra máquina (RDS).
O load balancer foi criado também como uma máquina independente e serve para balancear as requisições à aplicação web, entre os servidores Ubuntu disponíveis.
Na experiência é visto que cada servidor Ubuntu se diferencia entre si pela cor do background da aplicação (servidor 1 em branco, servidor 2 em laranja e servidor 3 em verde). A aplicação executa um código PHP que alimenta um banco de dados MySQL com os dados submetidos em um formulário. Dessa forma a página index.php contém o formulário e a página registros.php exibe os valores armazenados pelo banco de dados.

Em um primeiro momento cada servidor é testado de forma isolada. Depois o virtual IP (load balancer) é acessado para testar a comutação das requisições, à cada um dos servidores. O balanceador utilizado é do tipo Classic, ou seja, trabalha em camada 4, comutando sessões TCP. Seu predictor é, por padrão, o Round Robin, como é verificado na sequência dos acessos à aplicação (servidor 1, 2 e 3; e assim sucessivamente) independentemente de qualquer outro fator pertinente às máquinas. A submissão do formulário alimenta o banco de dados, o que se reflete automaticamente na página “registros.php” de todos os servidores Ubuntu. Nenhum cookie é gerado.

No segundo momento, o load balancer é configurado para ativar a persistência e, o faz, através de um cookie (nomeado AWSELB). Dessa vez o balanceador aponta apenas para um dos 3 servidores. Durante sua primeira sessão, um cookie é usado para avisar o load balance para aderir a este, mesmo para as sessões seguintes (enquanto a aderência, stickiness, estiver habilitada). Este recurso é muito utilizado em aplicações de e-commerce, onde é necessário que as ações do cliente, durante a possível compra, não se percam, o que poderia ocorrer se o load balance alternasse o acesso entre os servidores.

Finalmente, a aderência é desabilitada e o balanceador volta a apontar para cada um dos servidores alternadamente. Além disso, os valores do banco de dados foram removidas diretamente no MySQL e isso foi refletido na aplicação.

---