Compartilhar via

Confiabilidade no Azure Load Balancer

O Azure Load Balancer é um serviço de balanceamento de carga da camada 4 (TCP/UDP) que distribui o tráfego de entrada entre as instâncias de serviço. O Load Balancer fornece alta disponibilidade e desempenho de rede para seus aplicativos com latência ultra baixa.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também destaca algumas informações importantes sobre o SLA (contrato de nível de serviço) do Load Balancer.

Importante

A confiabilidade da solução geral depende da configuração das instâncias de back-end (servidores) para as quais o balanceador de carga roteia o tráfego, como VMs (máquinas virtuais) do Azure ou conjuntos de dimensionamento de máquinas virtuais do Azure.

Suas instâncias de back-end não estão no escopo deste artigo, mas suas configurações de disponibilidade afetam diretamente a resiliência do aplicativo. Examine os guias de confiabilidade de todos os serviços do Azure em sua solução para entender como cada serviço dá suporte aos seus requisitos de confiabilidade. Ao garantir que suas instâncias de back-end também estejam configuradas para alta disponibilidade e redundância de zona, você pode obter confiabilidade de ponta a ponta para seu aplicativo.

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 entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável do Load Balancer, consulte as práticas recomendadas de arquitetura para o 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 o tráfego da Internet por meio de um recurso de endereço IP público. Um balanceador de carga interno só pode ser acessado em sua rede virtual e em outras redes que você conecta à rede virtual.

Cada balanceador de carga consiste em vários componentes, incluindo:

  • Configurações de IP de front-end, que recebem tráfego. Um balanceador de carga público recebe tráfego em um endereço IP público. Um balanceador de carga interno recebe tráfego em um endereço IP em sua rede virtual.
  • Pools de back-end, que contêm uma coleção de instâncias de back-end que podem receber tráfego, como VMs individuais que executam seu aplicativo.
  • Regras de balanceamento de carga, que definem como o tráfego de um front-end deve ser distribuído para um pool de back-end.
  • Sondas de saúde, que monitoram a disponibilidade de instâncias de back-end.

Para saber mais sobre como o Load Balancer funciona, consulte os componentes do Load Balancer.

Para soluções implantadas globalmente, você pode implantar um balanceador de carga global, que é um tipo especial de balanceador de carga público projetado para rotear o tráfego entre diferentes implantações regionais de sua solução. Um balanceador de carga global fornece um único endereço IP anycast. Com base na proximidade do cliente e no status de integridade regional, ele roteia o tráfego para o balanceador de carga regional íntegro mais próximo. Para obter mais informações, consulte Resiliência a falhas em toda a região.

Resiliência a falhas transitórias

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

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

Ao usar o Load Balancer, considere as seguintes práticas recomendadas para minimizar o risco de falhas transitórias que afetam seu aplicativo:

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

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

  • Monitore a alocação de porta SNAT. Para conexões de saída, monitore a alocação de porta SNAT e configure regras de saída para evitar falhas transitórias de conexão devido ao esgotamento da porta.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem passar para uma das zonas restantes.

O Load Balancer pode ser implantado como redundância de zona. Basta definir cada configuração de IP de front-end que você criar. Uma configuração de IP de front-end com redundância de zona é servida simultaneamente de infraestruturas independentes em várias zonas. Essa configuração garante que falhas de zona não afetem a capacidade do balanceador de carga de receber e distribuir o tráfego.

O diagrama a seguir mostra um balanceador de carga público com redundância de zona, que é configurado criando um endereço IP público com redundância de zona:

Diagrama mostrando um balanceador de carga público com redundância de zona, com um endereço IP público com redundância de zona, direcionando o tráfego para três VMs diferentes em zonas de disponibilidade diferentes.

O diagrama a seguir mostra um balanceador de carga interno usando uma configuração com redundância de zona semelhante:

Diagrama mostrando um balanceador de carga interno com redundância de zona, direcionando o tráfego para três VMs diferentes em zonas de disponibilidade diferentes.

Observação

Embora você possa implantar balanceadores de carga zonais, recomendamos que você sempre use balanceadores de carga com redundância de zona, mesmo para cargas de trabalho implantadas em uma única zona. Atualmente, a Microsoft está migrando todos os endereços IP públicos e balanceadores de carga para serem com redundância de zona.

Em regiões sem zonas de disponibilidade, os balanceadores de carga são criados em uma configuração nonzonal ou regional usando uma configuração de front-end sem zona configurada. Se a região sofrer uma interrupção, os balanceadores de carga nonzonal poderão experimentar tempo de inatividade.

Instâncias de back-end e zonas de disponibilidade

A configuração da zona de disponibilidade das instâncias de back-end é independente da configuração de IP de front-end do Load Balancer.

Distribua suas instâncias de back-end entre zonas configurando o serviço relevante, de acordo com os recursos de confiabilidade do serviço ao qual pertencem e a arquitetura que você projeta.

Observação

Distribuir instâncias de back-end em várias zonas de disponibilidade é essencial para resiliência. Se todas as instâncias de back-end estiverem localizadas em uma única zona, uma interrupção nessa zona deixará seu aplicativo indisponível, mesmo se você usar um balanceador de carga com redundância de zona.

Por exemplo, quando você usa VMs, uma abordagem de design comum para cargas de trabalho de produção é obter resiliência de zona colocando várias VMs zonais nas zonas 1, 2 e 3. Para balanceamento de carga, você pode criar um balanceador de carga com redundância de zona e configurar essas VMs como as instâncias de back-end dentro do balanceador de carga. As investigações de integridade do Load Balancer removem automaticamente as VMs que não estão íntegras da rotação, independentemente da localização da zona.

No entanto, se você optar por implantar suas VMs na mesma zona de disponibilidade, ainda poderá implantar uma configuração de IP de front-end com redundância de zona no balanceador de carga, que o diagrama a seguir ilustra:

Diagrama mostrando um balanceador de carga público com redundância de zona, direcionando o tráfego para duas VMs diferentes na zona 1.

Requirements

Suporte à região: Balanceadores de carga com redundância de zona podem ser implantados em qualquer região que dê suporte a zonas de disponibilidade.

Custo

A configuração da zona de disponibilidade não altera a forma como um balanceador de carga é cobrado. A cobrança é baseada no número de regras configuradas e nos dados processados, independentemente da configuração da zona. Consulte Preços do Azure Load Balancer a fim de obter mais informações.

Configurar o suporte à zona de disponibilidade

Quando você trabalha com o Load Balancer, define o suporte à zona de disponibilidade na configuração de IP de front-end.

  • Crie um novo balanceador de carga com suporte à zona de disponibilidade.

  • 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, você precisa substituir a configuração de IP de front-end. Você pode usar essa abordagem para mudar de uma configuração zonal para uma de IP de front-end com redundância de zona. A abordagem de alto nível é:

    1. Crie uma nova configuração de IP de front-end com a configuração de zona de disponibilidade desejada.

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

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

    2. Reconfigure suas regras de balanceamento de carga para usar a nova configuração de IP de front-end.

      Importante

      Essa operação exige que você reconfigure seus clientes para enviar tráfego para o novo endereço IP de front-end. Dependendo de seus clientes, o processo pode exigir tempo de inatividade.

    3. Remova a configuração de IP de front-end antiga.

Comportamento quando todas as zonas estão saudáveis

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

  • Roteamento de tráfego entre zonas: O balanceamento de carga pode ser executado em qualquer zona de disponibilidade. O tráfego é enviado para instâncias de back-end saudáveis especificadas no pool de back-end, sem considerar em qual zona de disponibilidade a instância de back-end está.

  • Replicação de dados entre zonas. Load Balancer é um serviço de passagem de rede que não armazena nem replica dados do aplicativo. Mesmo se você habilitar a persistência de sessão no balanceador de carga, nenhum estado será armazenado no balanceador de carga. A persistência de sessão ajusta o processo de hash para rotear solicitações para a mesma instância de backend. No entanto, a persistência da sessão não é garantida. Quando o pool de back-end é alterado, a distribuição de solicitações de cliente é recomputada. Esse processo é feito sem armazenar ou sincronizar o estado.

    O serviço mantém seu respectivo estado de configuração com a replicação síncrona entre as zonas, o que assegura consistência imediata das regras de balanceamento de carga, das configurações de investigação de integridade e da associação de pool de back-end em todas as zonas.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um balanceador de carga usa uma configuração de IP front-end com redundância de zona e ocorre uma interrupção em uma zona de disponibilidade.

  • Detecção e resposta: a plataforma do Azure é responsável por detectar uma falha em uma zona de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona.

  • Solicitações ativas: todos os fluxos TCP/UDP existentes dentro da zona com falha são redefinidos e precisam ser repetidos pelo cliente. Seus clientes devem ter tratamento de falhas transitórias suficiente implementado, incluindo novas tentativas automatizadas.

  • Perda de dados esperada: como um serviço de rede sem estado, o Load Balancer não armazena dados do aplicativo, portanto, nenhuma perda de dados ocorre na camada do balanceador de carga.

  • Tempo de inatividade esperado: Não é esperado tempo de inatividade para balanceadores de carga com redundância de zona, pois o balanceador de carga continua funcionando a partir de zonas saudáveis.

    No entanto, se a falha afetar os serviços de computação na zona, todas as VMs ou outros recursos que estão na zona afetada poderão ficar indisponíveis. As sondas de saúde do balanceador de carga são projetadas para detectar essas falhas e rotear o tráfego para instâncias alternativas em outra zona, com base no algoritmo de balanceamento de carga e no status de integridade das instâncias de back-end.

  • Redirecionamento de tráfego: o balanceador de carga continua operando das zonas saudáveis. O serviço Load Balancer mantém o mesmo endereço IP de front-end durante falhas de zona. Esse comportamento significa que você não precisa aplicar atualizações DNS ou reconfigurar clientes. Novas conexões são estabelecidas automaticamente por meio das zonas íntegras restantes.

Recuperação de zona

Quando uma zona de disponibilidade é recuperada, o Load Balancer retoma automaticamente as operações normais. O front end com redundância de zona começa automaticamente a atender o tráfego da zona recuperada junto com as outras zonas operacionais. As investigações de integridade da zona de recuperação retomam a avaliação das instâncias de back-end.

Se a falha de zona também afetou seus serviços de computação nessa zona, à medida que as instâncias de backend na zona recuperada passam pelas verificações de integridade, elas são reintegradas automaticamente ao pool de servidores de backend saudável. A distribuição de tráfego é reequilibrada por todas as zonas disponíveis com base no algoritmo de balanceamento de carga e no status de integridade dos servidores back-end.

Testar falhas em zonas

A plataforma do Azure gerencia o roteamento de tráfego, a resposta de zona inoperante e a recuperação. Esses recursos são totalmente gerenciados, portanto, você não precisa iniciar nem validar processos de falha de zona de disponibilidade.

Você pode usar o Azure Chaos Studio para simular a falha de uma VM em uma única zona. O Chaos Studio fornece falhas integradas para VMs, incluindo desligar 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 implantados em uma única região do Azure. Se a região ficar indisponível, os balanceadores de carga nessa região também ficarão indisponíveis. No entanto, o Azure Load Balancer fornece suporte nativo de várias regiões por meio do Balanceador de Carga Global, que permite o balanceamento de carga entre regiões do Azure. Você também pode implantar outros serviços de balanceamento de carga a fim de rotear e fazer failover nas regiões do Azure.

Balanceadores de carga globais

O Balanceador de Carga Global fornece um único endereço IP de anycast estático que roteia automaticamente o tráfego para a implantação regional ideal com base na proximidade do cliente e na saúde regional. O Load Balancer Global pode ajudar a melhorar a confiabilidade e o desempenho do aplicativo.

Com o Balanceador de Carga Global, você implanta vários balanceadores de carga públicos em regiões diferentes e o balanceador de carga global atua como um front-end global. Se os servidores de back-end em uma região tiverem um problema, o tráfego mudará para regiões íntegras automaticamente e sem alterações de DNS porque o endereço IP anycast permanecerá constante e roteará o tráfego para outra região.

Para obter mais informações, consulte o Balanceador de Carga Global.

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

O Azure fornece um intervalo de serviços de balanceamento de carga que atendem a requisitos diferentes. Você pode selecionar um balanceador de carga que atenda aos seus requisitos de resiliência e que se adapte ao seu tipo de aplicativo. Para obter mais informações, consulte opções de balanceamento de carga.

Contrato de nível de serviço

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

O SLA do Azure Load Balancer se aplica quando há pelo menos duas VMs íntegras configuradas como instâncias de back-end. O SLA exclui o tempo de inatividade devido ao esgotamento da porta SNAT ou aos NSGs (grupos de segurança de rede) que bloqueiam o tráfego.

Conteúdo relacionado

  • Last updated on