Práticas recomendadas do Balanceador de Carga do Azure

Este artigo discute uma coleção de práticas recomendadas do Azure para sua implantação de balanceador de carga. Essas práticas recomendadas são derivadas de nossa experiência com a rede do Azure e das experiências de clientes como você.

Para cada prática recomendada, este artigo explica:

• Qual é a melhor prática
• Por que você deseja habilitar essa prática recomendada
• O que pode acontecer se você não habilitar as melhores práticas
• Como você pode aprender a habilitar essa prática recomendada

Essas práticas recomendadas são baseadas em uma opinião consensual e nas capacidades e funcionalidades da plataforma Azure, tal como existem no momento em que este artigo foi escrito.

Melhores práticas arquitetônicas

As diretrizes de arquitetura a seguir ajudam a garantir a confiabilidade da implantação do Balanceador de Carga do Azure. Inclui práticas recomendadas para implementação com redundância de zona, redundância no seu pool de back-end e implementação de um balanceador de carga global. Juntamente com a confiabilidade do Gateway Balanceador de Carga, que é recomendado ao usar NVAs em vez de uma configuração de balanceamento de carga dupla.

Práticas recomendadas de confiabilidade

As práticas recomendadas a seguir são recomendadas para garantir a confiabilidade da implantação do Balanceador de Carga do Azure.

Implantar com redundância zonal

A redundância de zona fornece a melhor resiliência, protegendo o caminho de dados contra falhas de zona. A seleção da zona de disponibilidade do balanceador de carga é sinônimo da seleção de zona do IP do frontend. Para balanceadores de carga públicos, se o IP público no frontend do balanceador de carga for redundante de zona, o balanceador de carga também será redundante de zona.

• Implante o balanceador de carga numa região que ofereça suporte a zonas de disponibilidade e ative a redundância de zona ao criar um novo endereço IP público usado para a configuração de IP de Frontend.
• Os endereços IP públicos não podem ser alterados para zona redundante, mas estamos atualizando todos os IPs públicos padrão não zonais para serem redundantes de zona por padrão. Para obter mais informações, visite o seguinte Blog do Microsoft Azure Os IPs públicos do Azure agora são redundantes por zona por padrão | Blog do Microsoft Azure. Para ver a lista mais atualizada de regiões que suportam IPs públicos padrão redundantes de zona por padrão, consulte Endereços IP públicos no Azure
• Se você não puder implantar como redundante de zona, a próxima opção será ter uma implantação de balanceador de carga zonal.
• Um frontend Zonal é recomendado quando o backend está concentrado em uma zona específica. No entanto, recomendamos a implantação de membros do pool de back-end em várias zonas para se beneficiar da redundância de zonas.
• Consulte o seguinte documento se quiser migrar implantações existentes para Balanceador de Carga zonal ou com redundância de zona suportado por zonas de disponibilidade.

Redundância no seu pool de back-end

Verifique se o pool de back-end contém pelo menos duas instâncias. Se o pool de back-end tiver apenas uma instância e estiver com problemas, todo o tráfego enviado para o pool de back-end falha devido à falta de redundância. O SLA do Balanceador de Carga Padrão também só é suportado quando há pelo menos duas instâncias de pool de back-end saudáveis em cada pool de back-end. Visite a documentação do SLA para obter mais informações.

Implantar um balanceador de carga global

O Balanceador de Carga Standard suporta balanceamento de carga entre regiões, permitindo redundância regional por meio da vinculação de um balanceador de carga global aos seus balanceadores de carga regionais existentes. Com um balanceador de carga global, se uma região falhar, o tráfego será roteado para o próximo balanceador de carga regional saudável mais próximo. Para obter mais detalhes, visite a documentação do Global Balanceador de Carga.

Para obter mais informações, consulte a documentação de Confiabilidade do Balanceador de Carga do Azure.

Confiabilidade com o Gateway Balanceador de Carga

As práticas recomendadas a seguir são recomendadas para garantir a confiabilidade da implantação do Gateway Balanceador de Carga.

Encadeie seu Balanceador de Carga de Gateway a um Balanceador de Carga Público Padrão

É recomendável encadear o Balanceador de Carga do Gateway a um Balanceador de Carga Público Padrão. Essa configuração fornece alta disponibilidade e redundância no NVA e na camada de aplicativos. Para obter mais informações, consulte Tutorial: Criar um balanceador de carga de gateway

Use um balanceador de carga de gateway ao usar NVAs em vez de uma configuração com dois balanceadores de carga.

Recomendamos o uso de um balanceador de carga do Gateway em cenários de tráfego norte-sul com NVAs (Network Virtual Appliances) parceiros. É mais fácil de implantar porque os balanceadores de carga do Gateway não exigem configuração extra, como UDRs (rotas definidas pelo usuário), pois mantêm a aderência e a simetria do fluxo. Também é mais fácil de gerenciar porque os NVAs podem ser facilmente adicionados e removidos. Para obter mais informações, consulte a documentação do Gateway Balanceador de Carga.

Diretrizes de configuração

As diretrizes de configuração a seguir são práticas recomendadas para configurar suas implantações do Balanceador de Carga do Azure.

Criar NSGs (grupos de segurança de rede)

Utilize uma regra de balanceamento de carga para mapear o tráfego de front-end para um conjunto de back-end e utilize um grupo de segurança de rede (NSG) na sub-rede de back-end ou na interface de rede para permitir o tráfego da aplicação. Para tráfego balanceado de carga, o NSG avalia o endereço IP de origem e a porta de origem do cliente, não o balanceador de carga, permitindo assim a gama de portas de origem do cliente em vez de apenas a porta de destino da aplicação. Para obter mais informações, consulte Criar, alterar ou excluir um grupo de segurança de rede do Azure.

Desbloqueie o endereço IP 168.63.129.16

Verifique o acesso à sonda de saúde separadamente do acesso ao tráfego de aplicações. Permitir sondas de saúde a partir da AzureLoadBalancer etiqueta de serviço nos NSGs e a partir do 168.63.129.16 nas políticas locais de firewall. Se bloquear o tráfego da aplicação, mas as sondas forem bem-sucedidas, reveja a regra de NSG para o tráfego da aplicação. Se as sondas falharem, verifique a tolerância da sonda e a aplicação em escuta na porta de sonda. Para mais informações, consulte Sonda de estado de funcionamento do Balanceador de Carga do Azure e O que é o endereço IP 168.63.129.16?

Usar regras de tráfego de saída com alocação manual de portas

Utilize regras de saída com alocação manual de porta em vez de alocação de porta padrão para evitar a exaustão de SNAT ou falhas de conexão. A alocação de portas padrão atribui automaticamente um número conservador de portas, o que pode causar um maior risco de exaustão da porta SNAT. A alocação manual de portas pode ajudar a maximizar o número de portas SNAT disponibilizadas para cada uma das instâncias em seu pool de back-end, o que pode ajudar a evitar que suas conexões sejam afetadas devido à realocação de portas. Há duas opções para alocação manual de portas, "portas por instância" ou "número máximo de instâncias de back-end". Para entender as considerações de ambos, consulte Tradução de endereços de rede de origem (SNAT) para conexões de saída.

Verifique o modo de distribuição

O Balanceador de Carga do Azure usa um modo de distribuição baseado em hash de 5 tuplas por padrão e também oferece persistência de sessão usando um hash de 2 tuplas ou 3 tuplas. Considere se sua implantação poderia se beneficiar da persistência de sessão (também conhecida como afinidade de sessão), onde as conexões do mesmo IP do cliente ou do mesmo IP e protocolo do cliente vão para a mesma instância de back-end dentro do pool de back-end. Considere também que habilitar a afinidade de sessão pode causar uma distribuição desigual de carga, pois a maioria das conexões que vêm do mesmo IP do cliente ou do mesmo IP e protocolo serão enviadas para a mesma VM de back-end. Para obter mais informações sobre os modos de distribuição do Balanceador de Carga do Azures, consulte Modos de distribuição do Balanceador de Carga do Azure.

Ativar redefinições de TCP

Ao habilitar as redefinições de TCP no seu Balanceador de Carga, são enviados pacotes de redefinição TCP bidirecionais para os pontos de extremidade do cliente e do servidor durante o tempo de inatividade, informando os pontos de extremidade da aplicação de que a ligação expirou e já não é utilizável. Sem habilitar a redefinição de TCP, o Balanceador de Carga silenciosamente descarta fluxos quando o tempo limite ocioso de um fluxo é atingido. Também pode ser benéfico aumentar o tempo limite ocioso e/ou usar um keep-alive TCP se você estiver vendo o tempo limite das conexões. Para obter mais informações sobre redefinições de TCP, tempos limite ociosos e manutenção de TCP, visite Redefinição de TCP do Balanceador de Carga e tempo limite ocioso no Azure.

Configurar a interface de loop back ao configurar o IP flutuante

Se você habilitar o IP flutuante, certifique-se de ter uma interface de loopback no SO convidado configurada com o endereço IP de front-end do balanceador de carga. O IP flutuante precisa ser ativado se quiser reutilizar a porta de back-end nas várias regras. Alguns exemplos de casos de uso de reutilização de porta incluem clusters de alta disponibilidade e aplicações virtuais de rede. Para obter mais informações, consulte Configuração de IP flutuante do Balanceador de Carga do Azure.

Implementar as práticas recomendadas de configuração do Balanceador de Carga de Gateway

Separe seu tráfego confiável e não confiável em duas interfaces de túnel diferentes; Use o tipo de interface de túnel externo para tráfego não confiável/ainda não inspecionado ou gerenciado e use o tipo de interface de túnel interno para tráfego confiável/inspecionado. Como prática recomendada de segurança, isso garante o isolamento de tráfego confiável e não confiável e pode permitir um controle de tráfego e solução de problemas mais granulares.

Certifique-se de que o limite de unidade de transmissão máxima (MTU) das suas NVAs esteja aumentado para pelo menos 1550, ou até os limites recomendados de 4000 para cenários em que os quadros jumbo são utilizados. Sem aumentar o limite de MTU, poderá ocorrer perdas de pacotes devido ao tamanho maior dos pacotes gerados pelos cabeçalhos VXLAN.

Anúncios de aposentadoria

Juntamente com novas melhorias e atualizações para o Balanceador de Carga do Azure, também há descontinuação de funcionalidades. É fundamental manter-se atualizado e garantir que está a fazer as alterações necessárias para evitar potenciais interrupções do serviço. Para uma lista completa de anúncios de descontinuações, consulte a página Atualizações do Azure e filtre por "Balanceador de Carga" em "Produtos" e "Desativações" em "Tipo de Atualização".

Usar ou fazer upgrade para o Balanceador de Carga Standard

O Basic Balanceador de Carga foi retirado de serviço a 30 de setembro de 2025. Se ainda estiveres a usar o Basic Balanceador de Carga, atualiza para o Balanceador de Carga Standard o mais rápido possível. Balanceador de Carga Standard oferece melhorias significativas, incluindo alto desempenho, latência ultra-baixa, segurança predefinida e um SLA de disponibilidade de 99,99%.

Não utilize o acesso de saída predefinido

No futuro, não utilize o acesso de saída predefinido e assegure que todas as VMs tenham um método de saída explícito definido. Esta abordagem oferece melhor segurança e maior controlo sobre como as suas VMs se ligam à internet. O acesso de saída por defeito foi descontinuado em 31 de março de 2026 e as VMs criadas após essa data têm de utilizar uma das seguintes soluções de saída para comunicar com a Internet:

• Associar um GW NAT à sub-rede
• Usar um ou mais IPs frontend de um Balanceador de Carga para saída por meio de regras de saída
• Atribuir um endereço IP público no nível da instância à VM

Próximos passos