NGINX Plus e balanceadores de carga do Microsoft Azure

Michael Pleshakov

[Editor – Esta publicação foi atualizada para refletir os recursos compatíveis com o NGINX Plus e os serviços de balanceamento de carga do Azure em junho de 2021. Ela também faz referência à API do NGINX Plus, que substitui e torna obsoleto o módulo separado de configuração dinâmica mencionado na versão original da publicação.]

Os clientes que usam o Microsoft Azure têm três opções de balanceamento de carga: NGINX Plus, os serviços de balanceamento de carga do Azure ou o NGINX Plus em conjunto com esses serviços. Este artigo fornece informações suficientes para ajudar você a tomar uma decisão e também mostra como o uso do NGINX Plus com o Azure Load Balancer pode oferecer um balanceador de carga HTTP altamente disponível e com recursos avançados de camada 7.

Visão geral

O Microsoft Azure oferece aos usuários duas opções de balanceador de carga: Azure Load Balancer para balanceamento de carga TCP/UDP básico (na Camada 4, a camada de rede) e Azure Application Gateway para balanceamento de carga HTTP/HTTPS (na Camada 7, a camada de aplicação). Embora essas soluções funcionem para casos de uso simples, elas não oferecem muitos dos recursos incluídos por padrão no NGINX Plus.

Veja uma comparação geral entre o NGINX Plus e as ofertas de balanceamento de carga do Azure:

Agora, vamos explorar algumas das diferenças entre o NGINX Plus e os serviços de balanceamento de carga do Azure, seus recursos exclusivos e como o NGINX Plus e os balanceadores de carga do Azure podem trabalhar em conjunto.

Comparação entre o NGINX Plus e os serviços de balanceamento de carga do Azure

Métodos de balanceamento de carga

O NGINX Plus oferece várias opções de métodos de balanceamento de carga além do método Round Robin padrão:

• Menor número de conexões – Cada solicitação é enviada ao servidor com o menor número de conexões ativas.
• Menor tempo – Cada solicitação é enviada ao servidor com a menor pontuação, calculada com base em uma combinação ponderada da latência média e do menor número de conexões ativas.
• Hash de IP – Cada solicitação é enviada ao servidor determinado pelo endereço IP de origem da solicitação.
• Hash genérico – Cada solicitação é enviada ao servidor determinado por uma chave definida pelo usuário, que pode conter qualquer combinação de texto e variáveis do NGINX, por exemplo, as variáveis correspondentes aos campos de cabeçalho Endereço IP de origem e Porta de origem, ou ao URI.
• Aleatório – Cada solicitação é enviada a um servidor selecionado aleatoriamente. Quando o parâmetro two é incluído, o NGINX Plus seleciona dois servidores aleatoriamente e escolhe entre eles usando o algoritmo Menor Número de Conexões (o padrão) ou Menor Tempo, conforme configurado.

Todos os métodos podem ser ampliados atribuindo diferentes valores de peso a cada servidor de backend. Para obter detalhes sobre os métodos, consulte o Guia de Administração do NGINX Plus.

O Azure Load Balancer oferece um método de balanceamento de carga, o Hash, que, por padrão, usa uma chave baseada nos campos de cabeçalho Source IP Address, Source Port, Destination IP Address, Destination Port e Protocol para escolher um servidor de back-end.

O Azure Application Gateway oferece apenas o método round-robin.

Persistência de sessão

Persistência de sessão, também conhecida como sessões persistentes ou afinidade de sessão, é necessária quando uma aplicação exige que todas as solicitações de um cliente específico continuem sendo enviadas ao mesmo servidor de backend, pois o estado do cliente não é compartilhado entre os servidores de backend.

O NGINX Plus oferece suporte a três métodos avançados de persistência de sessão:

• Cookie de persistência – O NGINX Plus adiciona um cookie de sessão à primeira resposta do grupo de servidores upstream para um determinado cliente. Esse cookie identifica o servidor de backend usado para processar a solicitação. O cliente inclui esse cookie nas solicitações subsequentes, e o NGINX Plus o utiliza para direcionar as solicitações do cliente ao mesmo servidor de backend.
• Aprendizado de persistência – O NGINX Plus monitora solicitações e respostas para localizar identificadores de sessão (geralmente cookies) e os utiliza para determinar o servidor que atenderá às solicitações subsequentes de uma sessão.
• Rota persistente – É possível configurar um mapeamento entre valores de rota e servidores de backend para que o NGINX Plus monitore as solicitações em busca de um valor de rota e escolha o servidor de backend correspondente.

O NGINX Plus também oferece dois métodos básicos de persistência de sessão, implementados como dois dos métodos de balanceamento de carga descritos acima:

• Hash de IP – O servidor de backend é determinado pelo endereço IP da solicitação.
• Hash – O servidor de backend é determinado com base em uma chave definida pelo usuário, por exemplo, Endereço IP de origem e Porta de origem, ou no URI.

O Azure Load Balancer oferece suporte ao equivalente ao método Hash do NGINX Plus, embora a chave esteja limitada a determinadas combinações dos campos de cabeçalho Endereço IP de origem, Porta de origem, Endereço IP de destino, Porta de destino e Protocolo.

O Azure Application Gateway oferece suporte ao equivalente do método Sticky Cookie do NGINX Plus, com as seguintes limitações: não é possível configurar o nome do cookie, sua data de expiração, o domínio, o caminho nem os atributos de cookie HttpOnly ou Secure.

Observação: Ao usar o Azure Load Balancer, o método IP Hash do NGINX Plus ou o método Hash do NGINX Plus com o Endereço IP de origem incluído na chave, a persistência de sessão só funciona corretamente se o endereço IP do cliente permanecer o mesmo durante toda a sessão. Isso nem sempre acontece, como, por exemplo, quando um cliente móvel alterna de uma rede Wi-Fi para uma rede celular. Para garantir que as solicitações continuem sendo direcionadas ao mesmo servidor de back-end, é melhor usar um dos métodos avançados de persistência de sessão listados acima.

Verificações de integridade

O Azure Load Balancer e o Azure Application Gateway oferecem suporte a verificações de integridade de aplicativos. Você pode especificar a URL que o balanceador de carga solicita, e ele considera o servidor de back-end íntegro se receber o código de retorno HTTP esperado, 200. Você pode especificar a frequência da verificação de integridade e o período de tempo limite antes que o servidor seja considerado não íntegro. Com o Azure Application Gateway, você também pode personalizar o código de resposta esperado e verificar se ele corresponde ao conteúdo do corpo da resposta.

O NGINX Plus amplia essa funcionalidade com verificações avançadas de integridade. Além de especificar a URL a ser usada, com o NGINX Plus você pode inserir cabeçalhos na solicitação, procurar diferentes códigos de resposta e examinar tanto os cabeçalhos quanto o corpo da resposta.

Um recurso relacionado útil do NGINX Plus é a inicialização lenta. O NGINX Plus aumenta gradualmente a carga em um servidor novo ou recém-recuperado para evitar que ele fique sobrecarregado com conexões. Isso é útil quando os servidores de backend precisam de algum tempo de aquecimento e falhariam se recebessem sua parcela total de tráfego assim que fossem considerados íntegros.

O NGINX Plus também oferece suporte a verificações de integridade de servidores TCP e UDP, permitindo especificar uma string a ser enviada e outra a ser procurada na resposta.

O Azure Load Balancer oferece suporte a verificações de integridade TCP, mas não oferece esse nível de monitoramento.

Terminação SSL/TLS

O NGINX Plus oferece suporte a terminação SSL/TLS, assim como o Gateway de Aplicativo do Azure. O Azure Load Balancer não oferece esse suporte.

Limites de conexões e de taxa

Com o NGINX Plus, você pode configurar vários limites para controlar o tráfego de entrada e saída da sua instância do NGINX Plus. Isso inclui limitar as conexões de entrada, as conexões com os nós de backend, a taxa de solicitações de entrada e a taxa de transmissão de dados do NGINX Plus para os clientes.

O Azure Application Gateway e o Azure Load Balancer não oferecem suporte a limites de taxa ou de conexões. No entanto, você pode usar outros serviços do Azure para configurar e habilitar a limitação de taxa.

Suporte a protocolos e reescrita e redirecionamento de URLs

NGINX Plus, o Azure Application Gateway e o Azure Load Balancer oferecem suporte aos seguintes recursos:

• HTTP/2 – NGINX Plus aceita solicitações HTTP/2 de clientes desde 2016. O Azure adicionou suporte a WebSocket mais recentemente.
• WebSocket – NGINX Plus aceita conexões WebSocket de clientes desde 2014. O Azure adicionou suporte a WebSocket mais recentemente.
• Reescrita de URL e redirecionamento de solicitações – A URL de uma solicitação pode ser alterada antes de ser encaminhada a um servidor de backend, o que permite alterar internamente os caminhos das solicitações e os locais dos arquivos sem modificar as URLs divulgadas aos clientes. Também é possível redirecionar solicitações, por exemplo, alterando o esquema de uma solicitação HTTP para HTTPS.

NGINX Plus com os serviços de balanceamento de carga do Azure

Quando usado em conjunto com o Azure Load Balancer e o Azure Traffic Manager, o NGINX Plus se torna uma solução de balanceamento de carga altamente disponível, com recursos avançados de camada 7.

Alta disponibilidade ativo-ativo

Ao usar o Azure Load Balancer para balancear a carga entre instâncias do NGINX Plus em um Conjunto de Disponibilidade, você cria um balanceador de carga de alta disponibilidade em uma região.

Dimensionamento automático do NGINX Plus

Você pode configurar o dimensionamento automático das instâncias do NGINX Plus com base no uso médio da CPU. Para isso, crie Conjuntos de Disponibilidade no Serviço de Nuvem do Azure que hospeda suas instâncias do NGINX Plus. Você precisa garantir a sincronização dos arquivos de configuração do NGINX Plus.

Escalonamento automático de instâncias de backend

Você também pode configurar o dimensionamento automático das suas instâncias de backend com base no uso médio da CPU. Isso é possível por meio da criação de Conjuntos de Disponibilidade no Serviço de Nuvem do Azure que hospeda suas instâncias de backend. Você precisa adicionar ou remover as instâncias de backend da configuração do NGINX Plus, o que pode ser feito com a API do NGINX Plus.

Para automatizar as atualizações da configuração do NGINX Plus (seja em conjunto com Conjuntos de Disponibilidade ou ao usar o NGINX Plus de forma independente), você pode integrar um sistema de descoberta de serviços ao NGINX Plus, por meio da API do NGINX Plus ou via DNS, caso o sistema tenha uma interface DNS. Confira nossas publicações no blog sobre o uso do NGINX Plus com sistemas populares de descoberta de serviços:

• Descoberta de serviços para NGINX Plus usando registros DNS SRV do Consul
• Descoberta de serviços para NGINX Plus usando APIs do Consul
• Descoberta de serviços para NGINX Plus com etcd
• Descoberta de serviços para NGINX Plus com ZooKeeper

Integração com o Azure Traffic Manager

Para um ambiente distribuído globalmente, você pode usar o Azure Traffic Manager para distribuir o tráfego dos clientes entre várias regiões.

Recursos adicionais nos serviços de balanceamento de carga do Azure

O Azure Load Balancer e o Application Gateway são gerenciados pela nuvem do Azure e ambos oferecem uma solução de balanceamento de carga de alta disponibilidade.

Um recurso do Azure Load Balancer que não está disponível no NGINX Plus é a NAT de origem, na qual o tráfego de saída das instâncias de back-end tem o mesmo endereço IP de origem que o balanceador de carga.

O Azure Load Balancer oferece reconfiguração automática ao usar o recurso de dimensionamento automático do Azure Cloud.

Resumo

Se os seus requisitos de balanceamento de carga forem simples, as ofertas de balanceamento de carga do Azure podem ser uma boa solução. Quando os requisitos se tornam mais complexos, o NGINX Plus é uma boa opção. Você pode usar o NGINX Plus de forma independente ou em conjunto com o Azure Load Balancer para garantir a alta disponibilidade das instâncias do NGINX Plus.

Para experimentar o NGINX Plus no Microsoft Azure, inicie sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Michael Pleshakov

Mais publicações de Michael Pleshakov