Load Balancer e Zonas de Disponibilidade

O Azure Load Balancer fornece suporte para cenários de zonas de disponibilidade. Você pode usar o Standard Load Balancer para aumentar a disponibilidade em todo o cenário alinhando recursos com e a distribuição entre zonas. Revise este documento para entender esses conceitos e as diretrizes fundamentais de design de cenários.

Um Load Balancer pode ser com redundância de zona, em zonas ou sem zonas. Para configurar as propriedades relacionadas à zona (mencionadas acima) para o balanceador de carga, selecione o tipo apropriado de front-end necessário.

Redundância de zona

Em uma região com Zonas de Disponibilidade, um Standard Load Balancer pode ter, por padrão, redundância de zona. Esse tráfego é atendido por um único endereço IP.

Um único endereço IP de front-end sobreviverá à falha da zona. O IP de front-end pode ser usado para alcançar todos os membros do pool de back-end (não impactados), independentemente da zona. Uma ou mais zonas de disponibilidade podem falhar e o caminho de dados sobreviver enquanto uma zona na região permanecer íntegra.

O endereço IP de front-end é atendido simultaneamente por várias implantações de infraestrutura independentes em diversas zonas de disponibilidade. Quaisquer retries ou restabelecimento terão êxito em outras zonas não afetadas pela falha de zona.

Figure depicts a zone-redundant standard load balancer directing traffic in three different zones to three different subnets in a zone redundant configuration.

Figura: Load balancer com redundância de zona

Zonal

Você pode optar por ter um front-end garantido para uma única zona, conhecido como um zonal. Este cenário significa que qualquer fluxo de entrada ou saída é atendido por uma única zona em uma região. O front-end compartilha o destino com a integridade da zona. O caminho de dados não é afetado por falhas em outras zonas além de onde foi garantido. É possível utilizar front-ends zonais para expor um endereço IP por Zona de Disponibilidade.

Além disso, há suporte para o uso de front-ends de zona diretamente em pontos de extremidade com balanceamento de carga em cada zona. Você pode usar esta configuração para expor pontos de extremidade com balanceamento de carga por zona para monitorar individualmente cada zona. Para pontos de extremidade públicos, você pode integrá-los a um produto de balanceamento de carga de DNS como o Gerenciador de Tráfego e usar um único nome DNS.

Figure depicts three zonal standard load balancers each directing traffic in a zone to three different subnets in a zonal configuration.

Figura: balanceador de carga zonal

Para um front-end público do load balancer, você inclui um parâmetro zonas para o IP público. Esse IP público é referenciado pela configuração de IP de front-end usada pela respectiva regra.

Para um front-end público do load balancer, você inclui um parâmetro zonas para o IP público referenciado pela configuração de IP de front-end. Um front-end zonal garante um endereço IP em uma sub-rede a uma zona específica.

Não zonal

Os balanceadores de carga também podem ser criados em uma configuração não zonal por meio de um front-end "sem zona" (IP público ou prefixo IP público). Essa opção não dá uma garantia de redundância. Observe que todos os endereços IP públicos que são atualizados serão do tipo "sem zona".

Considerações sobre o design

Agora que você entendeu como usar as propriedades relacionadas à zona no Standard Load Balancer, as considerações sobre design a seguir podem ajudar durante o projeto para alta disponibilidade.

Tolerância a falhas de zona

  • Um front-end com redundância de zona pode atender a um recurso de zona em qualquer zona com um só endereço IP. Este IP pode sobreviver a uma ou mais falhas de zona, desde que pelo menos uma zona permaneça íntegra na região.
  • Um front-end zonal é uma redução do serviço para uma única zona e compartilha o destino com a respectiva zona. Se a implantação na zona ficar inoperante, o balanceador de carga não sobreviverá a essa falha.

Os membros do pool de back-end de um balanceador de carga normalmente são associados a uma zona individual (por exemplo, máquinas virtuais de zona). Um design comum para cargas de trabalho de produção é ter vários recursos de zona (por exemplo, máquinas virtuais das zonas 1, 2 e 3) no back-end de um balanceador de carga com um front-end com redundância de zona.

Vários front-ends

O uso de vários front-ends permite balancear a carga do tráfego em mais de uma porta e/ou endereço IP. Ao projetar a arquitetura, é importante levar em conta a maneira como a redundância de zona e vários front-ends podem interagir. Observe que, se a meta é sempre que cada front-end seja resiliente a falhas, todos os endereços IP usados atribuídos como front-ends devem ser com redundância de zona. Se um conjunto de front-ends for destinado a ser associado a uma zona individual, todos os endereços IP desse conjunto precisarão ser associados a essa zona específica. Não é necessário ter um balanceador de carga para cada zona. Em vez disso, cada front-end de zona (ou conjunto de front-ends de zona) pode ser associado a máquinas virtuais no pool de back-end que faz parte dessa zona de disponibilidade específica.

Transição entre modelos de zona regionais

No caso em que uma região é ampliada para ter zonas de disponibilidade, os IPs públicos existentes (por exemplo, usados para os front-ends do balanceador de carga) permanecem sem zona. Para garantir que a arquitetura aproveite as novas zonas, recomendamos criar IPs de front-end e replicar as regras e as configurações apropriadas para utilizar esses novos IPs públicos.

Implicações de controle versus plano de dados

A redundância de zona não implica em um plano de dados ou plano de controle sem ocorrência. Fluxos com redundância de zona podem usar qualquer zona e seus fluxos usarão todas as zonas íntegras em uma região. Em uma falha de zona, os fluxos de tráfego usando zonas íntegras não são afetados.

Os fluxos de tráfego que usam uma zona no momento da falha de zona podem ser afetados, mas os aplicativos podem se recuperar. O tráfego continua nas zonas íntegras dentro da região após a retransmissão quando o Azure converge em torno da falha de zona.

Revise padrões de design de nuvem do Azure para melhorar a resiliência do seu aplicativo para cenários de falha.

Limitações

  • As zonas não podem ser alteradas, atualizadas nem criadas para o recurso após a criação.
  • Os recursos de zona não podem ser atualizados para recurso com redundância de zona e vice-versa após a criação.

Próximas etapas