Balanceadores de carga NGINX Plus e Microsoft Azure

[Editor – Esta postagem foi atualizada para refletir os recursos suportados pelos serviços de balanceamento de carga do NGINX Plus e do Azure em junho de 2021. Também se refere à API NGINX Plus , que substitui e desaprova o módulo de configuração dinâmica separado mencionado na versão original da postagem.]

Os clientes que usam o Microsoft Azure têm três opções para balanceamento de carga: NGINX Plus , os serviços de balanceamento de carga do Azure, ou NGINX Plus em conjunto com os serviços de balanceamento de carga do Azure. Esta postagem tem como objetivo fornecer informações suficientes para você tomar uma decisão e também mostrar como usar o NGINX Plus com o Azure Load Balancer pode fornecer um balanceador de carga HTTP altamente disponível com rica funcionalidade da Camada 7 .

visão geral

O Microsoft Azure oferece aos seus 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 aplicativo) . Embora essas soluções funcionem para casos de uso simples, elas não oferecem muitos recursos que vêm como padrão com o NGINX Plus.

Aqui está 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 juntos.

Comparando NGINX Plus e serviços de balanceamento de carga do Azure

Métodos de balanceamento de carga

O NGINX Plus oferece uma escolha de vários métodos de balanceamento de carga , além do método Round Robin padrão:

• Menos 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, que é calculada a partir de uma combinação ponderada de latência média e 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 determinada a partir de uma chave definida pelo usuário, que pode conter qualquer combinação de texto e variáveis NGINX, por exemplo, as variáveis correspondentes aos campos de cabeçalho Endereço IP de origem e Porta de origem , ou o URI.
• Aleatório – Cada solicitação é enviada para um servidor selecionado aleatoriamente. Quando os dois parâmetros são incluídos, o NGINX Plus seleciona dois servidores aleatoriamente e então escolhe entre eles usando o algoritmo Least Connections (o padrão) ou Least Time, conforme configurado.

Todos os métodos podem ser estendidos 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, Hash , que por padrão usa uma chave com base 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 fornece apenas um método round-robin .

persistência de sessão

A persistência de sessão , também conhecida como sessões persistentes ou afinidade de sessão , é necessária quando um aplicativo exige que todas as solicitações de um cliente específico continuem sendo enviadas para o mesmo servidor de back-end porque o estado do cliente não é compartilhado entre os servidores de back-end.

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

• Cookie fixo – O NGINX Plus adiciona um cookie de sessão à primeira resposta do grupo upstream para um determinado cliente. Este cookie identifica o servidor de backend que foi usado para processar a solicitação. O cliente inclui esse cookie em solicitações subsequentes e o NGINX Plus o utiliza para direcionar a solicitação do cliente para o mesmo servidor de backend.
• Sticky Learn – O NGINX Plus monitora solicitações e respostas para localizar identificadores de sessão (geralmente cookies) e os usa para determinar o servidor para solicitações subsequentes em uma sessão.
• Sticky Route – Um mapeamento entre valores de rota e servidores de backend pode ser configurado para que o NGINX Plus monitore solicitações para 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 backend é determinado pelo endereço IP da solicitação.
• Hash – O servidor backend é determinado a partir de uma chave definida pelo usuário, por exemplo, Endereço IP de origem e Porta de origem , ou o URI.

O Balanceador de Carga do Azure oferece suporte ao equivalente ao método NGINX Plus Hash, embora a chave seja limitada a certas 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 ao método NGINX Plus Sticky Cookie com as seguintes limitações: você não pode configurar o nome do cookie, sua data de expiração, o domínio, o caminho ou os atributos de cookie HttpOnly ou Secure .

Observação:  Quando você usa o Azure Load Balancer, o método NGINX Plus IP Hash ou o método NGINX Plus Hash com o endereço IP de origem incluído na chave, a persistência da sessão funciona corretamente somente se o endereço IP do cliente permanecer o mesmo durante toda a sessão. Nem sempre é esse o caso, como quando um cliente móvel muda de uma rede WiFi para uma rede celular, por exemplo. Para garantir que as solicitações continuem chegando ao mesmo servidor de backend, é 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 básicas de integridade do aplicativo . Você pode especificar a URL que o balanceador de carga solicita e ele considera o servidor de backend saudável se receber o HTTP esperado200 código de retorno. Você pode especificar a frequência da verificação de integridade e o período de tempo limite antes que o servidor seja considerado insalubre. Com o Azure Application Gateway, você também pode personalizar o código de resposta esperado e compará-lo com o conteúdo do corpo da resposta.

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

Um recurso relacionado útil no NGINX Plus é a inicialização lenta . O NGINX Plus aumenta lentamente a carga para um servidor novo ou recuperado recentemente para que ele não fique sobrecarregado por conexões. Isso é útil quando seus servidores de back-end precisam de algum tempo de aquecimento e falharão se receberem sua cota total de tráfego assim que forem mostrados como saudáveis.

O NGINX Plus também oferece suporte a verificações de integridade em servidores TCP e UDP , o que permite que você especifique uma string para enviar e uma string para procurar na resposta.

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

Encerramento do SSL/TLS

O NGINX Plus oferece suporte à terminação SSL/TLS , assim como o Azure Application Gateway . O Balanceador de Carga do Azure não.

Limites de conexão e taxa

Com o NGINX Plus, você pode configurar vários limites para controlar o tráfego de e para sua instância do NGINX Plus. Isso inclui limitar as conexões de entrada , as conexões com 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 conexão. No entanto, você pode usar outros serviços do Azure para configurar e habilitar a limitação de taxa.

Suporte de Protocolo e Reescrita e Redirecionamento de URL

NGINX Plus, Azure Application Gateway e Azure Load Balancer oferecem suporte ao seguinte:

• HTTP/2 – O NGINX Plus aceita solicitações HTTP/2 de clientes desde 2016. O Azure adicionou suporte a WebSocket mais recentemente.
• WebSocket – O 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ção – A URL de uma solicitação pode ser alterada antes de ser passada para um servidor de backend, o que significa que você pode alterar os caminhos da solicitação e os locais dos arquivos internamente sem modificar as URLs anunciadas aos clientes. Você também pode redirecionar solicitações, por exemplo, alterando o esquema de uma solicitação HTTP para HTTPS.

NGINX Plus com 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 balanceador de carga altamente disponível com rica funcionalidade 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 altamente disponível dentro de uma região.

Dimensionamento automático do NGINX Plus

Você pode configurar o dimensionamento automático de instâncias do NGINX Plus com base no uso médio da CPU. Isso é possível criando Conjuntos de Disponibilidade no Serviço de Nuvem do Azure que hospeda suas instâncias do NGINX Plus. Você precisa cuidar da sincronização dos arquivos de configuração do NGINX Plus.

Dimensionamento automático de instâncias de backend

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

Para automatizar atualizações na configuração do NGINX Plus (em combinação com Conjuntos de Disponibilidade ou ao usar o NGINX Plus sozinho), você pode integrar um sistema de descoberta de serviço com o NGINX Plus, por meio da API do NGINX Plus ou por DNS, se o sistema tiver uma interface DNS. Confira nossas postagens de blog sobre como usar o NGINX Plus com sistemas populares de descoberta de serviços:

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

Integração com o Azure Traffic Manager

Para um ambiente distribuído globalmente, você pode usar o Gerenciador de Tráfego do Azure para distribuir o tráfego de clientes em muitas regiões.

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

O Azure Load Balancer e o Application Gateway são gerenciados pelo Azure Cloud e ambos fornecem uma solução de balanceamento de carga altamente disponível.

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

O Balanceador de Carga do Azure fornece reconfiguração automática ao usar o recurso de dimensionamento automático do Azure Cloud.

Resumo

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

Para experimentar o NGINX Plus no Microsoft Azure, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .