Mantendo conexões persistentes no Load Balancer do Azure
Migrar websites que não foram preparados para ambientes de nuvem nem sempre é uma tarefa fácil. Há muito o que considerar antes de tomar decisões na arquitetura que a nova aplicação terá. Uma delas é quando queremos trabalhar com múltiplos servidores web em um conjunto de load balance. A maioria dos websites foram desenvolvidos para executar em apenas um servidor físico e quando migramos esta aplicação para uma arquitetura multi-servidor problemas como escritas em disco ou gerenciamento de sessão podem surgir.
O load balancer do Azure é do tipo Layer-4 [2]. Neste cenário, todo o tráfego de entrada é distribuído entre as instâncias virtuais definidas dentro de um conjunto de balanceamento. Por padrão, é feito um round-robin entre as conexões de entrada de forma que todo o tráfego seja distribuído igualmente entre todos os servidores participantes.
http://acom.azurecomcdn.net/80C57D/blogmedia/blogmedia/2014/10/21/SLB-5-tuple_thumb.pngDistribuição das conexões para um endpoint em balanceamento de carga [1]
Embora este seja o melhor método para garantir performance, imagine um site de e-commerce que precisa manter a sessão do usuário persistente durante todo o período de compra. Ao adicionar um produto no carrinho e seguir para a próxima tela, poderemos cair em um servidor diferente do que estava conectado anteriormente, sendo assim, perderia o produto que acabou de adicionar no carrinho, e mais, perderia o login ou qualquer outra informação que fosse armazenada em sessão no servidor web criando um mundo de inconsistências e má experiência para o usuário.
Quando trabalhamos com servidores de nuvem, temos que garantir que este tipo de cenário não aconteça e um deles é através do gerenciamento de sessão utilizando serviços como Redis Cache ou storage compartilhado, garantindo que nenhum dos servidores tenha informações diferentes do outro.
Como nem sempre temos a possibilidade de modificar a aplicação para este cenário, podemos contar com uma solução nativa do Azure para resolver este problema. É possível modificar a forma como o load balancer distribui as conexões de entrada para os servidores do conjunto. São 3 possíveis modos:
sourceIP (Source IP, Destination IP)
Utiliza o hash de uma tupla dupla contendo apenas o ip de entrada e ip de origem. Mantém o cliente conectado sempre no mesmo DIP independente do protocolo utilizado.
sourceIPProtocol (Source IP, Destination IP, Protocol)
Além do ip de entrada e destino, utiliza o protocolo para definir quando persistir a conexão do cliente no mesmo DIP.
none: (Source IP, Source Port, Destination IP, Destination Port, Protocol)
Método padrão. O cliente pode se conectar em qualquer um dos servidores disponíveis no set do load balance a qualquer momento.
Alterando o modo padrão:
Supondo que queremos modificar o modo de distribuição padrão ou “none” para “sourceIP” de um conjunto de load balance que responde na porta 80 (HTTP/TCP) de um cloud service que já existe, digite o seguinte comando no Azure powershell [3]:
Set-AzureLoadBalancedEndpoint -ServiceName "<NomeCloudService>" -LBSetName "<NomeLoadBalanceSet" -Protocol tcp -LocalPort 80 -ProbeProtocolTCP -ProbePort 8080 –LoadBalancerDistribution "sourceIP"
E para criar um novo endpoint em um conjunto de load balance para uma VM:
Get-AzureVM -ServiceName "<NomeCloudService>" -Name "<NomeVM>" | Add-AzureEndpoint -Name "Http" -Protocol "tcp" -PublicPort 80 -LocalPort 8080 –LoadBalancerDistribution “sourceIP” | Update-AzureVM
Para listar o modo de distribuição do endpoint atual:
Get-AzureVM –ServiceName "<NomeCloudService>" –Name "<NomeVM>" | Get-AzureEndpoint
É isso! Dentro de poucos segundos a nova configuração será habilitada e qualquer conexão de entrada se tornará persistente a um DIP específico.
Apesar de ter exemplificado o cenário de um website, esta solução também é importante para ambientes que utilizam Terminal Services, pois em caso de timeout da conexão, o usuário poderá reconectar no servidor que estava originalmente, consequentemente sem perder tudo que estava fazendo antes.
Referências:
[1] http://azure.microsoft.com/blog/2014/10/30/azure-load-balancer-new-distribution-mode/
[2] http://windowsitpro.com/azure/azure-load-balancer-stickiness-options
[3] http://msdn.microsoft.com/en-us/library/azure/dn495300.aspx
*"Este documento foi originalmente publicado como http://www.azurekb.com.br/mantendo-conexoes-persistentes-no-load-balancer-do-azure/ e foi reproduzido aqui para permitir que a comunidade corrija eventuais imprecisões ou forneça outras melhorias antes de atualizar a versão original deste tópico". *