Fiabilidade no Load Balancer

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

Para obter uma visão geral da arquitetura da confiabilidade no Azure, consulte Confiabilidade do Azure.

Recomendações de fiabilidade

Esta seção contém recomendações para alcançar resiliência e disponibilidade. Cada recomendação enquadra-se numa de duas categorias:

• Os itens de integridade abrangem áreas como itens de configuração e a função adequada dos principais componentes que compõem sua Carga de Trabalho do Azure, como definições de configuração 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, testes, monitoramento, implantação e outros itens que, se não forem resolvidos, aumentam as chances de problemas no ambiente.

Matriz de prioridades de recomendações de fiabilidade

Cada recomendação é assinalada de acordo com a seguinte matriz de prioridades:

Image	Prioridade	Description
	Máximo	Correção imediata necessária.
	Meio	Corrigir dentro de 3-6 meses.
	Mínimo	Precisa ser revisto.

Resumo das recomendações de fiabilidade

Category	Prioridade	Recomendação
Disponibilidade		Verifique se o Standard Load Balancer é redundante de zona
		Verifique se o pool de back-end contém pelo menos duas instâncias
Eficiência do sistema		Usar o gateway NAT em vez de regras de saída para cargas de trabalho de produção
		Usar SKU do Balanceador de Carga Padrão

Disponibilidade

Verifique se o Standard Load Balancer é redundante de zona

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

Azure Resource Graph

// 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)

Verifique se o pool de back-end contém pelo menos duas instâncias

Implante o Load Balancer com pelo menos duas instâncias no back-end. Uma única instância pode resultar em um único ponto de falha. Para criar para escala, convém emparelhar o balanceador de carga com Conjuntos de Dimensionamento de Máquina Virtual.

Azure Resource Graph

// 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 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 SNAT para cada instância de máquina virtual em um pool de back-end. Esse método de alocação pode levar ao esgotamento da porta SNAT, especialmente se 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 associar o Balanceador de Carga Padrão ou qualquer implantação de sub-rede ao Gateway NAT do Azure. O NAT Gateway aloca dinamicamente portas SNAT em todas as instâncias de máquina virtual em uma sub-rede e, por sua vez, reduz o risco de esgotamento da porta SNAT.

Azure Resource Graph

// 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 SKU do Balanceador de Carga Padrão

O balanceador de carga SKU padrão suporta zonas de disponibilidade e resiliência de zona, enquanto o SKU básico não. Quando uma zona fica inativa, seu balanceador de carga padrão com redundância de zona não será afetado e suas implantações serão capazes de suportar falhas de zona dentro de uma região. Além disso, o Standard Load Balancer oferece suporte ao balanceamento de carga entre regiões para garantir que seu aplicativo não seja afetado por falhas de região.

Nota

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

Azure Resource Graph

// 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 fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas 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 é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

O Azure Load Balancer dá suporte a cenários de zonas de disponibilidade. Você pode usar o Balanceador de Carga Padrão para aumentar a disponibilidade em todo o cenário, alinhando recursos e distribuindo entre zonas. Analise este documento para entender esses conceitos e diretrizes fundamentais de design de cenário.

Embora seja recomendável implantar o Load Balancer com redundância de zona, um Load Balancer pode ser redundante de zona, zonal ou não zonal. 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. Se o IP público no frontend do balanceador de carga for zonal, o balanceador de carga também será designado para a mesma zona. Para configurar as propriedades relacionadas à zona para seu balanceador de carga, selecione o tipo apropriado de frontend necessário.

Nota

Não é necessário ter um balanceador de carga para cada zona, em vez disso, ter um único balanceador de carga com vários frontends (zonal ou zona redundante) associados aos seus respetivos pools de back-end servirá para o propósito.

Pré-requisitos

• Para usar zonas de disponibilidade com o Load Balancer, você precisa criar seu balanceador de carga em uma região que ofereça suporte a zonas de disponibilidade. Para ver quais regiões oferecem suporte a zonas de disponibilidade, consulte a lista de regiões suportadas.

• Use SKU padrão para balanceador de carga e IP público para suporte a zonas de disponibilidade.

• O tipo de SKU básico não é suportado.

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

Limitações

• As zonas não podem ser alteradas, atualizadas ou criadas para o recurso após a criação.
• Os recursos não podem ser atualizados de zona para zona redundante ou vice-versa após a criação.

Balanceador de carga redundante de zona

Em uma região com zonas de disponibilidade, um Balanceador de Carga Padrão pode ser redundante de zona com tráfego servido por um único endereço IP. Um único endereço IP frontend sobrevive a uma falha de zona. O IP de front-end pode ser usado para alcançar todos os membros do pool de back-end (não afetados), independentemente da zona. Até uma zona de disponibilidade pode falhar e o caminho de dados sobrevive enquanto as zonas restantes na região permanecerem íntegras.

O endereço IP do frontend é servido simultaneamente por várias implantações de infraestrutura independentes em várias zonas de disponibilidade. Qualquer nova tentativa ou restabelecimento será bem-sucedido em outras zonas não afetadas pela falha de zona.

Nota

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 normalmente são associados a uma única zona, como máquinas virtuais zonais. Um design comum para cargas de trabalho de produção seria ter vários recursos zonais. Por exemplo, colocar máquinas virtuais da zona 1, 2 e 3 no back-end de um balanceador de carga com um frontend redundante de zona atende a esse princípio de design.

Balanceador de carga zonal

Você pode optar por ter um frontend garantido para uma única zona, que é conhecida como zonal. Com esse cenário, uma única zona em uma região atende a todo o fluxo de entrada ou saída. Seu frontend compartilha o destino com a saúde da zona. O caminho de dados não é afetado por falhas em zonas diferentes de onde foi garantido. Você pode usar frontends zonais para expor um endereço IP por zona de disponibilidade.

Além disso, há suporte para o uso de frontends zonais diretamente para pontos de extremidade com balanceamento de carga dentro de cada zona. Você pode usar essa 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 DNS, como o Gerenciador de Tráfego, e usar um único nome DNS.

Para um front-end de balanceador de carga público, você adiciona um parâmetro zones ao IP público. Este IP público é referenciado pela configuração de IP frontend usada pela respetiva regra.

Para um front-end do balanceador de carga interno, adicione um parâmetro zones à configuração IP do frontend do balanceador de carga interno. Um frontend zonal garante um endereço IP em uma sub-rede para 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 frontend "sem zona". Nesses cenários, um balanceador de carga público usaria um IP público ou prefixo IP público, um balanceador de carga interno usaria um IP privado. Esta opção não dá garantia de redundância.

Nota

Todos os endereços IP públicos que são atualizados de Basic SKU para Standard SKU serão do tipo "no-zone". Saiba como Atualizar um endereço IP público no portal do Azure.

Melhorias no SLA

Como as zonas de disponibilidade são fisicamente separadas e fornecem fonte de alimentação, rede e resfriamento distintos, os SLAs (contratos de nível de serviço) podem aumentar. Para obter mais informações, consulte os Contratos de Nível de Serviço (SLA) para Serviços Online.

Criar um recurso com a zona de disponibilidade ativada

Para saber como balancear a carga de VMs dentro de uma zona ou em várias zonas usando um Balanceador de Carga, consulte Guia de início rápido: criar um balanceador de carga público para balancear a carga de VMs.

Nota

• As zonas não podem ser alteradas, atualizadas ou criadas para o recurso após a criação.
• Os recursos não podem ser atualizados de zona para zona redundante ou 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 sendo reiniciado no novo servidor. Você deve consultar o processo de failover para recuperação de desastres, reunindo máquinas virtuais no planejamento de recuperação e executando exercícios de recuperação de desastres para garantir que sua solução de tolerância a falhas seja bem-sucedida.

Para obter mais informações, consulte os processos de recuperação de site.

Experiência de zoneamento

Redundância de zona não implica plano de dados ou plano de controle sem acertos. Os fluxos redundantes de zona podem usar qualquer zona e seus fluxos usarão todas as zonas saudáveis de uma região. Em uma falha de zona, os fluxos de tráfego usando zonas saudáveis não são afetados.

Os fluxos de tráfego usando 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 convergiu em torno da falha de zona.

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

Vários front-ends

O uso de vários frontends permite balancear a carga do tráfego em mais de uma porta e/ou endereço IP. Ao projetar sua arquitetura, certifique-se de levar em conta como a redundância de zona interage com vários frontends. Se o seu objetivo é sempre ter todos os frontends resilientes a falhas, todos os endereços IP atribuídos como frontends devem ser redundantes de zona. Se um conjunto de frontends se destinar a ser associado a uma única zona, cada endereço IP desse conjunto deve ser associado 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 implementação seguras

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

Migrar para o suporte à zona de disponibilidade

No caso em que uma região é aumentada 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 garantir que sua arquitetura possa aproveitar as novas zonas, é recomendável criar um novo IP frontend. Uma vez criado, você pode substituir o frontend não zonal existente por um novo frontend redundante de zona. Para saber como migrar uma VM para o suporte à zona de disponibilidade, consulte Migrar o balanceador de carga para o suporte da zona de disponibilidade.

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

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para 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 originado de várias regiões.
• Failover global instantâneo para a próxima implantação regional ideal.
• Carregue a distribuição entre regiões para a região do Azure mais próxima com latência ultrabaixa.
• Capacidade de aumentar ou diminuir a escala atrás de um único ponto de extremidade.
• Endereço IP global anycast estático
• Preservação do IP do cliente
• Desenvolva a solução de balanceador de carga existente sem curva de aprendizado

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

Nota

A porta de back-end da regra de balanceamento de carga no balanceador de carga entre regiões deve corresponder à porta frontend da regra de balanceamento de carga/regra nat de entrada no balanceador de carga padrão regional.

Recuperação de desastres em geografia de várias regiões

Redundância regional

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

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

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

Latência ultrabaixa

O algoritmo de balanceamento de carga de proximidade geográfica é baseado na localização geográfica de seus usuários e suas implantações regionais.

O tráfego iniciado a partir de um cliente atinge a região participante mais próxima e percorre o backbone de 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:

• E.U.A. Oeste
• Europa do Norte

Se um fluxo é iniciado a partir de Seattle, o tráfego entra no oeste dos EUA. Esta 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 é o 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 obter mais informações, consulte 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 aumentar ou diminuir a escala atrás de um único endpoint

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, que garante que o endereço IP permaneça o mesmo. Para saber mais sobre 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. Esta 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 tanto no nível IP global quanto no nível IP regional. Para obter mais informações, visite Vários frontends 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 em 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.

Pesquisas de Estado de Funcionamento

O Balanceador de Carga 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, dado que um usuário configurou testes de integridade em seu balanceador de carga regional.

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

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 inicial é onde o balanceador de carga entre regiões ou o endereço IP público da camada Global é implantado. Esta região não afeta a forma como o tráfego é encaminhado. Se uma região de origem diminuir, o fluxo de tráfego não será afetado.

Regiões de origem

• E.U.A. Central
• Ásia Leste
• E.U.A. Leste 2
• Europa do Norte
• Sudeste Asiático
• Sul do Reino Unido
• US Gov - Virginia
• Europa Ocidental
• E.U.A. Oeste

Nota

Você só pode implantar seu balanceador de carga entre regiões ou IP público na camada Global em uma das regiões Home listadas.

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

O tráfego iniciado pelo utilizador 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
• Austrália Sudeste
• Índia Central
• E.U.A. Central
• Ásia Leste
• E.U.A. Leste
• E.U.A. Leste 2
• Leste do Japão
• E.U.A. Centro-Norte
• Europa do Norte
• E.U.A. Centro-Sul
• Sudeste Asiático
• Sul do Reino Unido
• US DoD - Centro
• US DoD - Leste
• US Gov - Arizona
• US Gov - Texas
• US Gov - Virginia
• E.U.A. Centro-Oeste
• Europa Ocidental
• E.U.A. Oeste
• E.U.A. Oeste 2

Nota

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

Limitações

• As configurações de IP frontend entre regiões são apenas públicas. Um frontend interno não é suportado no momento.

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

• A tradução NAT64 não é suportada no momento. Os IPs frontend e backend devem ser do mesmo tipo (v4 ou v6).

• O tráfego UDP não é suportado no Cross-region Load Balancer for IPv6.

• O tráfego UDP na porta 3 não é suportado no Cross-Region Load Balancer

• As regras de saída não são suportadas no Balanceador de Carga entre regiões. Para conexões de saída, utilize regras de saída no balanceador de carga regional ou gateway NAT.

Preços e SLA

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

Próximos passos

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