Confiabilidade no Load Balancer

Este artigo contém recomendações de confiabilidade específicas para o Load Balancer e também informações detalhadas sobre a resiliência regional do Load Balancer, com zonas de disponibilidade e recuperação de desastres e continuidade dos negócios em várias regiões.

Para ter uma visão geral arquitetônica da confiabilidade no Azure, confira Confiabilidade do Azure.

Recomendações de confiabilidade

Essa seção contém recomendações para obter resiliência e disponibilidade. Cada recomendação se enquadra em uma das duas categorias:

• Os itens de integridade abrangem áreas como itens de configuração e a função adequada dos principais componentes que compõem a carga de trabalho do Azure, como configurações de recursos do Azure, dependências de outros serviços e assim por diante.

• Os itens de risco abrangem áreas como requisitos de disponibilidade e recuperação, teste, monitoramento, implantação e outros itens que, se deixados não resolvidos, aumentam as chances de problemas no ambiente.

Matriz de prioridade de recomendações de confiabilidade

Cada recomendação é marcada de acordo com a seguinte matriz de prioridade:

Imagem	Prioridade	Descrição
	Alto	Correção imediata necessária.
	Médio	Correção dentro de 3 a 6 meses.
	Baixo	Precisa de revisão.

Resumo das recomendações de confiabilidade

Categoria	Prioridade	Recomendação
Disponibilidade		Certifique-se de que o Standard Load Balancer tenha redundância de zona
		Certifique-se de que o pool de back-end contenha pelo menos duas instâncias
Eficiência do sistema		Usar o Gateway da NAT em vez de regras de saída para cargas de trabalho de produção
		Usar o SKU do Standard Load Balancer

Disponibilidade

Certificar-se de que o Standard Load Balancer tenha redundância de zona

Em uma região compatível com zonas de disponibilidade, o Standard Load Balancer deve ser implantado com redundância de zona. Um Load Balancer com redundância de zona permite que o tráfego seja distribuído por um único endereço IP de front-end capaz de sobreviver a uma falha de zona. O IP de front-end pode ser usado para alcançar todos os membros (não afetados) do pool de back-end, independentemente da zona. Se uma zona de disponibilidade falhar, o caminho de dados poderá sobreviver, desde que as zonas restantes na região permaneçam íntegras. Para obter mais informações, confira Balanceador de carga com redundância de zona.

Gráfico de Recursos do Azure

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Certifique-se de que o pool de back-end contenha pelo menos duas instâncias

Implante o Load Balancer com pelo menos duas instâncias no back-end. Uma só instância pode resultar em um ponto único de falha. Para compilar de modo a permitir o dimensionamento, talvez você queira combinar o balanceador de carga com os Conjuntos de Dimensionamento de Máquinas Virtuais.

Gráfico de Recursos do Azure

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Eficiência do sistema

Usar o Gateway da NAT em vez de regras de saída para cargas de trabalho de produção

As regras de saída alocam quantidades fixas de portas de SNAT para cada instância de máquina virtual em um pool de back-end. Esse método de alocação pode causar o esgotamento das portas de SNAT, especialmente no caso de padrões de tráfego irregulares resultarem em uma máquina virtual específica enviando um volume maior de conexões de saída. Para cargas de trabalho de produção, é recomendável que você combine o Standard Load Balancer ou qualquer implantação de sub-rede com o Gateway da NAT do Azure. O Gateway da NAT aloca as portas de SNAT dinamicamente em todas as instâncias de máquina virtual em uma sub-rede, o que, por sua vez, reduz o risco de esgotamento das portas de SNAT.

Gráfico de Recursos do Azure

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Usar o SKU do Standard Load Balancer

O SKU do Standard Load Balancer é compatível com zonas de disponibilidade e resiliência de zona, ao contrário do SKU Básico. Quando uma zona se tornar inoperante, seu Standard Load Balancer com redundância de zona não será afetado e suas implantações conseguirão resistir às falhas de zona dentro de uma região. Além disso, o Standard Load Balancer é compatível com o balanceamento de carga entre regiões para garantir que seu aplicativo não seja afetado por falhas na região.

Observação

Os balanceadores de carga básicos não têm um Contrato de Nível de Serviço (SLA).

Gráfico de Recursos do Azure

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões 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.

Embora seja recomendável que você implante o Load Balancer com redundância de zona, um balanceador de carga pode ter redundância de zona e ser zonal ou não zonal. A seleção da zona de disponibilidade do balanceador de carga é sinônimo de seleção de zona do IP de front-end. Para balanceadores de carga públicos, se o IP público no front-end do balanceador de carga for redundante de zona, o balanceador de carga também será redundante de zona. Se o IP público no front-end do balanceador de carga for zonal, o balanceador de carga também será designado para a mesma zona. Para configurar as propriedades relacionadas à zona do seu balanceador de carga, selecione o tipo apropriado de front-end necessário.

Observação

Não é necessário ter um balanceador de carga para cada zona, em vez disso, ter um único balanceador de carga com vários front-ends (zonal ou redundante de zona) associados aos respectivos pools de back-end servirá à finalidade.

Pré-requisitos

• Para usar zonas de disponibilidade com o Load Balancer, você precisa criar seu balanceador de carga em uma região que seja compatível com zonas de disponibilidade. Para ver quais regiões são compatíveis com zonas de disponibilidade, confira a lista de regiões compatíveis.

• Use o SKU Standard para o Load Balancer e um IP público para compatibilidade com zonas de disponibilidade.

• Não há suporte para o tipo de SKU básico.

• Para criar seu recurso, você precisa ter uma função de Colaborador de Rede ou superior.

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.

Balanceador de carga com redundância de zona

Em uma região com zonas de disponibilidade, o Standard Load Balancer pode ter redundância de zona com tráfego distribuído por um único endereço IP. Um único endereço IP do front-end sobrevive à falha de 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. Até uma zona de disponibilidade pode falhar e o caminho de dados sobreviverá enquanto as zonas restantes na região permanecerem íntegras.

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.

Observação

As VMs 1,2 e 3 podem pertencer à mesma sub-rede e não precisam necessariamente estar em zonas separadas como sugere o diagrama.

Os membros no pool de back-end de um balanceador de carga são normalmente associados a uma única zona, como em máquinas virtuais por zona. Um design comum para cargas de trabalho de produção seria ter diversos recursos zonais. Por exemplo, colocar máquinas virtuais das zonas 1, 2 e 3 no back-end de um balanceador de carga que possui um front-end com redundância de zona atende a esse princípio de design.

Balanceador de carga zonal

Você pode optar por ter um front-end garantido para uma única zona, conhecido como um zonal. Com esse cenário, uma única zona em uma região atende a todo o fluxo de entrada ou de saída. 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.

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.

Balanceador de carga não zonal

Os balanceadores de carga também podem ser criados em uma configuração não zonal usando um front-end "sem zona". Nesses cenários, um balanceador de carga público usaria um IP público ou prefixo de IP público, e um balanceador de carga interno usaria um IP privado. Esta opção não oferece garantia de redundância.

Observação

Todos os endereços IP públicos atualizados do SKU Básico para o Standard serão do tipo "sem zona". Saiba como atualizar um endereço IP público no portal do Azure.

Aprimoramentos do SLA

Como as zonas de disponibilidade são fisicamente separadas e fornecem fontes de alimentação, redes e refrigeração distintas, os SLAs (Contratos de Nível de Serviço) podem aumentar. Para mais informações, confira SLAs (Contratos de Nível de Serviço) para Serviços Online.

Criar um recurso com a zona de disponibilidade habilitada

Para aprender como balancear a carga de VMs em uma ou várias zonas usando um balanceador de carga, consulte Início Rápido: Criar um balanceador de carga público para balancear a carga de VMs.

Observação

• 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.

Tolerância a falhas

As máquinas virtuais podem fazer failover para outro servidor em um cluster, com o sistema operacional da VM reiniciando no novo servidor. Você deve consultar o processo de failover para recuperação de desastre, reunindo máquinas virtuais no planejamento de recuperação e executando exercícios de recuperação de desastre para garantir que sua solução de tolerância a falhas seja bem-sucedida.

Para obter mais informações, confira os processos de recuperação de sites.

Experiência de zona inoperante

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.

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, considere como a redundância de zona interage com diversos front-ends. Se o objetivo for sempre ter todos os front-ends resilientes a falhas, todos os endereços IP atribuídos como front-ends deverão ter 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. Um balanceador de carga não é necessário em cada zona. Em vez disso, cada front-end zonal (ou conjunto de front-ends zonais) pode ser associado a máquinas virtuais no pool de back-end que fazem parte dessa zona de disponibilidade específica.

Técnicas de implantação segura

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

Migrar para o suporte às zonas de disponibilidade

No caso da ampliação de uma região para ter zonas de disponibilidade, todos os IPs existentes permanecerão não zonais, como os IPs usados para front-ends do balanceador de carga. Para se certificar de que sua arquitetura possa tirar proveito das novas zonas, é recomendável que você crie um novo IP de front-end. Após tê-lo criado, você poderá substituir o front-end não zonal existente por um novo front-end com redundância de zona. Para aprender como migrar uma VM para a compatibilidade com zona de disponibilidade, confira Migrar o Load Balancer para a compatibilidade com zona de disponibilidade.

Recuperação de desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

O Azure Standard Load Balancer dá suporte ao balanceamento de carga entre regiões, permitindo cenários de alta disponibilidade com redundância geográfica, como:

• Tráfego de entrada proveniente de várias regiões.
• Failover global instantâneo para a próxima implantação regional ideal.
• Carregar a distribuição entre regiões para a região do Azure mais próxima com latência extremamente baixa.
• Capacidade de escalar verticalmente por trás de um único ponto de extremidade.
• Endereço IP global anycast estático
• Preservação de IP do cliente
• Criar uma solução de balanceador de carga existente sem curva de aprendizado

A configuração de IP de front-end do balanceador de carga entre regiões é estática e anunciada na maioria das regiões do Azure.

Observação

A porta de back-end de sua regra de balanceamento de carga no balanceador de carga entre regiões deve corresponder à porta de front-end da regra de NAT de entrada/regra de balanceamento de carga no balanceador de carga Standard regional.

Recuperação de desastre na geografia de várias regiões

Redundância regional

Configure a redundância regional vinculando perfeitamente um balanceador de carga entre regiões aos balanceadores de carga regionais existentes.

Se uma região falhar, o tráfego será roteado para o balanceador de carga regional íntegro mais próximo.

A investigação de integridade do balanceador de carga entre regiões coleta informações sobre a disponibilidade de cada balanceador de carga a cada 5 segundos. Se um balanceador de carga regional reduzir sua disponibilidade para 0, o balanceador de carga entre regiões detectará a falha. O balanceador de carga regional é então retirado da rotação.

Latência ultra baixa

O algoritmo de balanceamento de carga de proximidade geográfica baseia-se na localização geográfica dos usuários e nas implantações regionais.

O tráfego iniciado a partir de um cliente atinge a região participante mais próxima e percorre o backbone da rede global da Microsoft para chegar à implantação regional mais próxima.

Por exemplo, você tem um balanceador de carga entre regiões com balanceadores de carga padrão em regiões do Azure:

• Oeste dos EUA
• Norte da Europa

Se um fluxo for iniciado de Seattle, o tráfego entrará no Oeste dos EUA. Essa região é a região participante mais próxima de Seattle. O tráfego é roteado para o balanceador de carga da região mais próxima, que é Oeste dos EUA.

O balanceador de carga entre regiões do Azure usa o algoritmo de balanceamento de carga de proximidade geográfica para a decisão de roteamento.

O modo de distribuição de carga configurado dos balanceadores de carga regionais é usado para tomar a decisão final de roteamento quando vários balanceadores de carga regionais são usados para proximidade geográfica.

Para saber mais, confira Configurar o modo de distribuição para o Azure Load Balancer.

O tráfego de saída segue a preferência de roteamento definida nos balanceadores de carga regionais.

Capacidade de escalar verticalmente por trás de um único ponto de extremidade

Ao expor o ponto de extremidade global de um balanceador de carga entre regiões aos clientes, você pode adicionar ou remover implantações regionais por trás do ponto de extremidade global sem interrupção.

Endereço IP global anycast estático

O balanceador de carga entre regiões vem com um IP público estático, o que garante que o endereço IP permaneça o mesmo. Para saber mais sobre o IP estático, leia mais aqui

Preservação de IP do cliente

O balanceador de carga entre regiões é um balanceador de carga de rede de passagem de Camada 4. Essa passagem preserva o IP original do pacote. O IP original está disponível para o código em execução na máquina virtual. Essa preservação permite que você aplique uma lógica específica a um endereço IP.

IP flutuante

O IP flutuante pode ser configurado no nível do IP global e no nível do IP regional. Para saber mais, visite Diversos front-ends para o Azure Load Balancer

É importante observar que o IP flutuante configurado no Balanceador de carga entre regiões do Azure opera independentemente das configurações de IP flutuante nos balanceadores de carga regionais de back-end. Se o IP flutuante estiver habilitado no balanceador de carga entre regiões, a interface de loopback apropriada precisará ser adicionada às VMs de back-end.

Investigações de integridade

O Load Balancer entre regiões do Azure utiliza a integridade dos balanceadores de carga regionais de back-end ao decidir para onde distribuir o tráfego. As verificações de integridade pelo balanceador de carga entre regiões são feitas automaticamente a cada 5 segundos, desde que um usuário tenha configurado as investigações de integridade em seu balanceador de carga regional.

Criar solução entre regiões em Azure Load Balancer

O pool de back-end do balanceador de carga entre regiões contém um ou mais balanceadores de carga regionais.

Adicione suas implantações de balanceador de carga existentes a um balanceador de carga entre regiões para uma implantação altamente disponível entre regiões.

A região de residência é onde o balanceador de carga entre regiões ou o endereço IP público da camada global é implantado. Essa região não afeta a forma como o tráfego é roteado. Se uma região de residência falhar, o fluxo de tráfego não será afetado.

Regiões residenciais

• Centro dos EUA
• Leste da Ásia
• Leste dos EUA 2
• Norte da Europa
• Sudeste Asiático
• Sul do Reino Unido
• Gov. dos EUA – Virgínia
• Europa Ocidental
• Oeste dos EUA

Observação

Você só pode implementar seu balanceador de carga entre regiões ou IP Público na Camada Global em uma das regiões iniciais listadas.

Uma região participante é onde o IP público global do balanceador de carga está sendo anunciado.

O tráfego iniciado pelo usuário viaja para a região participante mais próxima através da rede principal da Microsoft.

O balanceador de carga entre regiões roteia o tráfego para o balanceador de carga regional apropriado.

Regiões participantes

• Leste da Austrália
• Australia Southeast
• Índia Central
• Centro dos EUA
• Leste da Ásia
• Leste dos EUA
• Leste dos EUA 2
• Leste do Japão
• Centro-Norte dos EUA
• Norte da Europa
• Centro-Sul dos Estados Unidos
• Sudeste Asiático
• Sul do Reino Unido
• DoD Central dos EUA
• DoD do Leste dos EUA
• Governo dos EUA do Arizona
• Governo dos EUA do Texas
• Gov. dos EUA – Virgínia
• Centro-Oeste dos EUA
• Europa Ocidental
• Oeste dos EUA
• Oeste dos EUA 2

Observação

Os balanceadores de carga regionais de back-end podem ser implantados em qualquer região do Azure disponível publicamente e não se limitam apenas às regiões participantes.

Limitações

• As configurações de IP de front-end entre regiões são apenas públicas. No momento, não há suporte para um front-end interno.

• O balanceador de carga interno ou privado não pode ser adicionado ao pool de back-end de um balanceador de carga entre regiões

• No momento, não há suporte para a conversão NAT64. Os IPs de front-end e back-end precisam ser do mesmo tipo (v4 ou v6).

• Não há suporte para o tráfego UDP no Load Balancer para IPv6 entre regiões.

• O tráfego UDP na porta 3 não é compatível com o Balanceador de Carga entre Regiões

• As regras de saída não têm suporte no Azure Load Balancer Entre Regiões. Para conexões de saída, utilize as regras de saída no balanceador de carga regional ou gateway NAT.

Preço e SLA

O balanceador de carga entre regiões compartilha o SLA do balanceador de carga padrão.

Próximas etapas

• Confiabilidade no Azure
• Consulte Tutorial: criar um balanceador de carga entre regiões usando o portal do Azure para criar um balanceador de carga entre regiões.
• Saiba mais sobre o balanceador de carga entre regiões.
• Saiba mais sobre o Azure Load Balancer.