Fiabilidade no Azure Load Balancer

O Azure Load Balancer é um serviço de balanceamento de carga de camada 4 (TCP/UDP) que distribui o tráfego recebido entre instâncias saudáveis de serviços. O Load Balancer oferece alta disponibilidade e desempenho de rede às suas aplicações com latência ultra-baixa.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Load Balancer resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Também destaca algumas informações chave sobre o acordo de nível de serviço (SLA) do Load Balancer.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, desempenho, segurança, custo e operações. Para compreender como estas áreas se influenciam mutuamente e contribuem para uma solução fiável de Load Balancer, consulte as melhores práticas de arquitetura para Load Balancer no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Um balanceador de carga pode ser público ou interno. Um balanceador de carga público aceita tráfego da internet através de um recurso de endereço IP público. Um balanceador de carga interno é acessível somente dentro da sua rede virtual e de outras redes que se ligam à rede virtual.

Cada balanceador de carga é composto por múltiplos componentes, incluindo:

• Configurações de IP frontend, que recebem tráfego. Um balanceador de carga público recebe tráfego num endereço IP público. Um balanceador de carga interno recebe tráfego num endereço IP dentro da sua rede virtual.
• Pools backend, que contêm um conjunto de instâncias backend capazes de receber tráfego, como VMs individuais que executam a sua aplicação.
• Regras de balanceamento de carga, que definem como o tráfego de um frontend deve ser distribuído para um pool de backend.
• Sondas de saúde, que monitorizam a disponibilidade de instâncias de backend.

Para saber mais sobre como funciona o Load Ballancer, consulte Componentes do Load Ballancer.

Para soluções implementadas globalmente, pode implementar um balanceador de carga global, que é um tipo especial de balanceador público concebido para encaminhar tráfego entre diferentes implementações regionais da sua solução. Um balanceador de carga global fornece um único endereço IP anycast. Encaminha o tráfego para o balanceador de carga regional saudável mais próximo, com base na proximidade com o cliente e no estado de saúde regional. Para mais informações, consulte Resiliência face a falhas regionais.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Ao usar o Balanceador de Carga, considere as seguintes boas práticas para minimizar o risco de falhas transitórias a afetar a sua aplicação:

• Implemente a lógica de repetição. Os clientes devem implementar mecanismos de nova tentativa adequados para falhas de conexão transitórias, incluindo estratégias de recuo exponencial.

• Configure sondas de integridade com tolerância. Configure as suas sondas de saúde para equilibrar a deteção rápida de falhas e evitar falsos positivos durante problemas transitórios.

• Monitorizar a alocação de portas SNAT. Para ligações de saída, monitoriza a alocação de portas SNAT e configura regras de saída para evitar falhas de ligação transitórias devido ao esgotamento das portas.

Resiliência a falhas na 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 Load Balancer pode ser implementado como redundante por zona , configurando cada configuração de IP frontend que criar. Uma configuração de IP frontend redundante de zona é servida simultaneamente a partir de infraestruturas independentes em múltiplas zonas. Esta configuração garante que falhas de zona não afetam a capacidade do balanceador de carga para receber e distribuir tráfego.

O diagrama seguinte mostra um balanceador de carga público redundante por zona, que é configurado criando um endereço IP público redundante por zona:

O diagrama seguinte mostra um balanceador de carga interno usando uma configuração redundante por zonas semelhante:

Em regiões sem zonas de disponibilidade, os balanceadores de carga são criados numa configuração não zonal ou regional , utilizando uma configuração frontend sem zona configurada. Se a região sofrer uma falha, os balanceadores de carga não zonais podem sofrer interrupções.

Instâncias de backend e zonas de disponibilidade

A configuração da zona de disponibilidade das suas instâncias backend é independente da configuração do IP frontend do seu balanceador de carga.

Distribua as suas instâncias backend entre zonas, configurando o serviço relevante de acordo com as funcionalidades de fiabilidade do serviço a que pertencem e a arquitetura que desenha.

Por exemplo, quando se usam VMs, uma abordagem comum de design para cargas de trabalho em produção é alcançar resiliência de zonas colocando múltiplas VMs zonais nas zonas 1, 2 e 3. Para balanceamento de carga, podes então criar um balanceador de carga redundante por zonas e configurar essas VMs como instâncias backend dentro do balanceador de carga. As sondas de saúde do balanceador de carga removem automaticamente VMs não saudáveis da rotação, independentemente da sua localização na zona.

No entanto, se optar por implantar as suas VMs na mesma zona de disponibilidade, ainda pode implementar uma configuração de IP frontend redundante por zona no seu balanceador de carga, como ilustra o diagrama seguinte:

Requerimentos

Apoio regional: Balanceadores de carga redundantes de zona podem ser implementados em qualquer região que suporte zonas de disponibilidade.

Custo

A configuração da zona de disponibilidade não altera a forma como um balanceador de carga é faturado. A faturação baseia-se no número de regras configuradas e dados processados, independentemente da configuração da zona. Para obter mais informações, consulte preços do Azure Load Balancer.

Configurar o suporte à zona de disponibilidade

Quando trabalhas com o Load Balancer, defines o suporte à zona de disponibilidade na configuração do IP frontend.

• Crie um novo balanceador de carga com suporte para zonas de disponibilidade.

  • Para balanceadores de carga públicos, a configuração de IP frontend adota automaticamente a configuração da zona de disponibilidade do recurso de endereço IP público que lhe associa. Para tornar a configuração do IP frontend redundante por zona, crie ou selecione um endereço IP público redundante por zona. Os endereços IP públicos são redundantes por zona por defeito. Para passos detalhados, consulte Criar um balanceador de carga público para balancear VMs usando o portal Azure.

  • Para balanceadores de carga internos, quando configuras o IP frontend do balanceador, defines o tipo de zona de suporte à zona de disponibilidade na configuração do IP frontend. Para passos detalhados, consulte Criar um balanceador de carga interno para balancear VMs usando o portal Azure.

• Altere a configuração da zona de disponibilidade de um balanceador de carga existente. Para alterar a configuração da zona de disponibilidade de um balanceador de carga existente, é necessário substituir a configuração do IP frontend. Pode usar esta abordagem para passar de uma configuração de IP de frontend zonal para uma configuração de IP de frontend redundante de zona. A abordagem de alto nível é:

  1. Crie uma nova configuração de IP frontend com a configuração desejada da zona de disponibilidade.

     Para balanceadores de carga públicos, crie primeiro um novo endereço IP público que use a configuração da zona de disponibilidade desejada. Depois, reconfigure o seu balanceador de carga para adicionar uma configuração de IP frontend que faça referência a esse endereço IP público.

     Para balanceadores de carga internos, reconfigure o seu balanceador de carga para adicionar uma nova configuração de IP frontend com a configuração de disponibilidade desejada. Esta etapa atribui um novo endereço IP privado a partir da sua sub-rede.

  2. Reconfigure as suas regras de balanceamento de carga para usar a nova configuração de IP frontend.

     Importante

     Esta operação exige que reconfigure os seus clientes para enviar tráfego para o novo endereço IP frontend. Dependendo dos seus clientes, o processo pode exigir tempo de inatividade.

  3. Remova a antiga configuração de IP frontend.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um balanceador de carga utiliza uma configuração IP de zona de redundância no frontend e todas as zonas de disponibilidade estão operacionais.

• Encaminhamento do tráfego entre zonas: O balanceamento de carga pode ser realizado em qualquer zona de disponibilidade. O tráfego é enviado para instâncias de backend saudáveis especificadas no grupo de backend, sem considerar em que zona de disponibilidade se encontra a instância de backend.

• Replicação de dados entre zonas. O Load Balancer é um serviço de rede de passagem que não armazena nem replica dados da aplicação. Mesmo que atives a persistência da sessão no balanceador de carga, nenhum estado é armazenado no balanceador de carga. A persistência de sessão ajusta o processo de hashing para encaminhar pedidos para a mesma instância backend. No entanto, a persistência da sessão não é garantida. Quando o pool de backend muda, a distribuição dos pedidos do cliente é recalculada. Este processo é feito sem armazenar ou sincronizar o estado.

  O serviço mantém o seu estado de configuração com replicação síncrona entre zonas, garantindo a consistência imediata das regras de balanceamento de carga, configurações de sondas de saúde e pertença ao backend pool em todas as zonas.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um balanceador de carga utiliza uma configuração de IP frontend redundante por zona e há uma falha na zona de disponibilidade.

• Deteção e resposta: A plataforma Azure é responsável por detetar uma falha numa zona de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar o Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Service Health para o notificar de problemas.

• Pedidos ativos: Quaisquer fluxos TCP/UDP existentes dentro da zona falhada são reiniciados e precisam de ser tentados novamente pelo cliente. Os seus clientes devem implementar um tratamento adequado de falhas transitórias, incluindo tentativas automáticas.

• Perda de dados esperada: Como serviço de rede sem estado, o Load Balancer não armazena dados da aplicação, pelo que não ocorre perda de dados na camada do balanceador de carga.

• Tempo de inatividade esperado: Não se espera tempo de inatividade para balanceadores de carga redundantes por zona, porque o balanceador continua a funcionar a partir de zonas saudáveis.

  No entanto, se a falha afetar os serviços de computação na zona, então quaisquer VMs ou outros recursos que estejam na zona afetada podem estar indisponíveis. As sondas de saúde do balanceador de carga são concebidas para detetar estas falhas e encaminhar o tráfego para instâncias alternativas noutra zona, com base no algoritmo de balanceamento de carga e no estado de saúde das instâncias do backend.

• Redirecionamento de tráfego: O balanceador de carga continua a operar a partir das zonas saudáveis. O serviço de balanceamento de carga mantém o mesmo endereço IP do frontend durante falhas de zona. Este comportamento significa que não precisa de aplicar atualizações DNS nem de reconfigurar clientes. Novas ligações são automaticamente estabelecidas através das zonas saudáveis que remanescem.

Recuperação de zona

Quando uma zona de disponibilidade recupera, o Load Balancer retoma automaticamente as operações normais. A interface redundante de zona começa automaticamente a servir o tráfego da zona recuperada juntamente com outras zonas operacionais. As sondagens de saúde da zona recuperada retomam a avaliação das instâncias de backend.

Se a falha da zona também afetou os seus serviços de computação na zona, então, à medida que as instâncias de backend na zona recuperada passam nos testes de integridade, são automaticamente reintegradas ao pool de backend saudável. A distribuição do tráfego reequilibra-se em todas as zonas disponíveis com base no algoritmo de balanceamento de carga e no estado de saúde das instâncias do backend.

Teste de falhas de zona

A plataforma Azure gere o encaminhamento do tráfego, a resposta de zona reduzida e a recuperação. Estas capacidades são totalmente geridas, por isso não precisa de iniciar ou validar processos de falha em zonas de disponibilidade.

Podes usar o Azure Chaos Studio para simular a falha de uma VM numa única zona. O Chaos Studio fornece falhas incorporadas para VMs, incluindo o encerramento de uma VM. Você pode usar esses recursos para simular falhas de zona e testar seus processos de failover.

Resiliência a falhas em toda a região

Balanceadores de carga públicos e internos são implementados numa única região Azure. Se a região ficar indisponível, os teus balanceadores de carga nessa região também ficam indisponíveis. No entanto, o Azure Load Balancer oferece suporte nativo multi-região através do Global Load Balancer, que permite o balanceamento de carga entre regiões Azure. Também podes implementar outros serviços de balanceamento de carga para encaminhar e fazer failover entre regiões Azure.

Balanceadores de carga globais

O Global Load Balancer fornece um único endereço IP anycast estático que encaminha automaticamente o tráfego para a implementação regional ótima, com base na proximidade do cliente e na saúde regional. O Global Load Balancer pode ajudar a melhorar a fiabilidade e o desempenho da sua aplicação.

Com o Global Load Balancer, implementas múltiplos balanceadores de carga públicos em diferentes regiões, e o global load balancer atua como um frontend global. Se os servidores backend numa região tiverem um problema, o tráfego muda automaticamente para regiões saudáveis e sem alterações no DNS, porque o endereço IP anycast mantém-se constante e encaminha o tráfego para outra região.

Para mais informações, consulte Global Load Balancer.

Soluções personalizadas de várias regiões para resiliência

O Azure oferece uma variedade de serviços de balanceamento de carga que se adaptam a diferentes necessidades. Pode selecionar um balanceador de carga que cumpra os seus requisitos de resiliência e que se adeque ao seu tipo de aplicação. Para obter mais informações, consulte Opções de balanceamento de carga.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O Azure Load Balancer SLA aplica-se quando existem pelo menos duas VMs saudáveis configuradas como instâncias backend. O SLA exclui o tempo de inatividade devido ao esgotamento das portas SNAT ou a grupos de segurança de rede (NSGs) que bloqueiam o tráfego.

Conteúdo relacionado

• Documentação do Azure Load Balancer
• Balanceador de Carga Global
• Visão geral da confiabilidade do Azure