Fiabilidade no balanceador de carga

Este artigo contém informações detalhadas sobre a resiliência regional do Load Balancer com zonas de disponibilidade , recuperação de desastres globais e continuidade de negócios.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

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 implementar o Load Balancer com redundância de zona, um Load Balancer pode ser redundante de zona ou associado a uma zona específica (em regiões com zonas de disponibilidade). 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 estiver configurado com redundância de zona, o balanceador de carga também será com redundância 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.

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 frontend pode ser usado para alcançar todos os membros não afetados do pool de backend, 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.

Os membros no pool de back-end de um balanceador de carga geralmente são associados a uma única zona, tal como acontece com 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 das zonas 1, 2 e 3 no back-end de um balanceador de carga com um frontend com redundância 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. O seu frontend partilha o seu destino com a saúde da área. 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 esta configuração para expor pontos de extremidade balanceados por carga por zona para monitorar individualmente cada zona. Para pontos de extremidade públicos, pode-se 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

Em regiões sem zonas de disponibilidade, 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.

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.

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, reunir máquinas virtuais no planejamento de recuperação de desastres e executar exercícios de recuperação de desastres para garantir que a sua solução de tolerância a falhas seja bem-sucedida.

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

Experiência de redução de intensidade

A redundância de zona não implica o funcionamento do plano de dados ou plano de controlo sem interrupções. 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 que utilizam uma zona no momento da sua falha podem ser afetados, mas os aplicativos conseguem recuperar-se. O tráfego continua nas zonas saudáveis dentro da região após a retransmissão, quando o Azure convergiu após a falha da 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 frontends

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 na 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 globais e continuidade de negócios

A recuperação de desastres (DR) refere-se a práticas que as organizações usam para se recuperar 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 criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Para DR, a Microsoft usa o modelo de responsabilidade compartilhada . Neste modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam dados automaticamente nem possuem mecanismos de fallback para mudar de uma região com falha para outra região ativada. 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 da plataforma Azure como serviço (PaaS) fornece recursos e orientações para dar suporte à DR. Você pode usar recursos específicos do serviço para apoiar a recuperação rápida e ajudar a desenvolver o seu plano de DR.

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

• Tráfego de entrada originado de várias regiões.
• Failover global imediato para a próxima localização regional mais adequada.
• Distribuição de carga entre regiões para a região do Azure mais próxima com ultrabaixa latência.
• 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
• Aperfeiçoe a solução de balanceador de carga existente sem curva de aprendizado

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

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 global 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 global 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 global 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 global 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 global 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 por detrás de um único endpoint

Ao expor o ponto de extremidade global de um balanceador de carga global 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 global 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 global é 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 global 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 global, a interface de loopback apropriada precisará ser adicionada às VMs de back-end.

Sondas de Saúde

O Azure Global Load Balancer 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 global são feitas automaticamente a cada 5 segundos, dado que um usuário configura testes de integridade em seu balanceador de carga regional.

Crie uma solução global no Azure Load Balancer existente

O pool de back-end de um balanceador de carga global contém um ou mais balanceadores de carga regionais.

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

A região inicial é onde o balanceador de carga global 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

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 global 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

Limitações

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

• O balanceador de carga privado ou interno não pode ser associado ao grupo de back-end de um balanceador de carga global.

• 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 em um balanceador de carga global para IPv6.

• O tráfego UDP na porta 3 não é suportado em um Load Balancer global

• As regras de saída não são suportadas num Load Balancer global. 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 global compartilha o SLA do balanceador de carga padrão.

Próximos passos

• Fiabilidade no Azure
• Consulte Tutorial: Criar um balanceador de carga global usando o portal do Azure para criar um balanceador de carga global.
• Saiba mais sobre o balanceador de carga global neste vídeo.
• Saiba mais sobre o Azure Load Balancer.