Balanceamento de carga de várias regiões com o Gerenciador de Tráfego e o Gateway de Aplicativo

Gateway de Aplicativo
Bastion
Load Balancer
Gerenciador de Tráfego

Essa arquitetura de referência atende cargas de trabalho da Web com aplicativos multicamados resilientes e implanta em várias regiões do Azure para obter alta disponibilidade e recuperação robusta de desastres.

Gerenciador de Tráfego do Microsoft Azure balanceia o tráfego entre regiões e há um balanceador de carga regional com base em Gateway de Aplicativo do Azure. Essa combinação obtém os benefícios do roteamento flexível do Gerenciador de Tráfego e dos muitos recursos do Gateway de Aplicativo, incluindo:

  • Firewall de Aplicativo Web (WAF).
  • Encerramento do TLS (Transport Layer Security).
  • Roteamento baseado em caminho.
  • Afinidade de sessão baseada em cookie.

Nesse cenário, o aplicativo consiste em três camadas:

  • Camada da Web: Essa é a camada superior e tem a interface do usuário. Ele analisa as interações do usuário e passa as ações para a camada de negócios para processamento.
  • Camada de negócios: Processa as interações do usuário e determina as próximas etapas. Ele conecta a Web e as camadas de dados.
  • Camada de dados: Armazena os dados do aplicativo, normalmente em um banco de dados, armazenamento de objetos ou arquivos.

Diagrama mostrando o balanceamento de carga de várias regiões com Gateway de Aplicativo e o Gerenciador de Tráfego.

Baixe um Arquivo Visio dessa arquitetura.

Observação

O Azure fornece um conjunto de soluções de balanceamento de carga totalmente gerenciadas. Se você estiver procurando por terminação de protocolo TLS (Transport Layer Security) ("descarregamento SSL") ou solicitação por HTTP/HTTPS, processamento de camada de aplicativo, examine o que é Gateway de Aplicativo do Azure?. Se você estiver procurando balanceamento de carga regional, examine Azure Load Balancer. Cenários de ponta a ponta podem se beneficiar da combinação dessas soluções conforme for necessário.

Para obter uma comparação das opções de balanceamento de carga do Azure, consulte Visão geral das opções de balanceamento de carga no Azure.

Arquitetura

O Gerenciador de Tráfego opera na camada DNS para direcionar o tráfego do aplicativo de acordo com sua escolha de método de roteamento. Por exemplo, você pode direcionar que as solicitações sejam enviadas para os pontos de extremidade mais próximos, para melhorar a capacidade de resposta. Gateway de Aplicativo a carga balancea as solicitações HTTP(S) e WebSocket à medida que as roteia para servidores de pool de back-end. O back-end pode ser pontos de extremidade públicos ou privados, máquinas virtuais, Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, serviços de aplicativo ou clusters AKS. Você pode rotear o tráfego com base em atributos de uma solicitação HTTP, como o nome do host e o caminho do URI.

Componentes

  • Máquinas virtuais do Azure As VMs são recursos de computação escalonáveis e sob demanda que oferecem a flexibilidade da virtualização, mas eliminam as demandas de manutenção do hardware físico. As opções do sistema operacional incluem Windows e Linux. As VMs são um recurso escalonável e sob demanda.
  • Os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure são dimensionamento de VM automatizado e com balanceamento de carga que simplifica o gerenciamento dos seus aplicativos e aumenta a disponibilidade.
  • O Gerenciador de Tráfego é um balanceador de carga de tráfego baseado em DNS que distribui o tráfego de forma ideal para serviços em regiões globais do Azure, fornecendo alta disponibilidade e capacidade de resposta. Para obter mais informações, consulte a Configuração do Gerenciador de Tráfego.
  • O Gateway de Aplicativo é um balanceador de carga da camada 7. Nessa arquitetura, um Gateway de Aplicativo com redundância de zona roteia solicitações HTTP para o front-end da Web. Gateway de Aplicativo também fornece um WAF (Firewall de Aplicativo Web) que protege o aplicativo contra explorações e vulnerabilidades comuns. O SKU v2 de Gateway de Aplicativo dá suporte à redundância entre zonas. Uma implantação do Gateway de Aplicativo pode executar várias instâncias do gateway.
  • O Azure Load Balancer é um balanceador de carga da camada 4. Há dois SKUs: Standard e Basic. Nessa arquitetura, um Standard Load Balancer com redundância de zona direciona o tráfego de rede da camada da Web para a camada de negócios. Como um Load Balancer com redundância de zona não está fixado a uma zona específica, o aplicativo continuará a distribuir o tráfego de rede no caso de uma falha de zona.
  • A Proteção contra DDoS do Azure tem recursos aprimorados para proteger contra ataques de DDoS (negação de serviço distribuído), recursos que vão além da proteção básica fornecida pelo Azure.
  • O DNS do Azure é um serviço de hospedagem para domínios DNS. Ele fornece resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure. O DNS do Azure também dá suporte a zonas DNS privadas. As Zonas Privadas DNS do Azure fornecem resolução de nomes dentro de uma rede virtual, bem como entre redes virtuais. Os registros contidos em uma zona DNS privada não podem ser resolvidos pela Internet. A resolução DNS em relação a uma zona DNS privada funciona apenas de redes virtuais que estão vinculadas a ela.
  • A Rede Virtual do Azure é uma rede privada segura na nuvem. Ela conecta VMs umas às outras, à Internet e a redes locais.
  • O Azure Bastion fornece acesso seguro e contínuo do RDP (Protocolo de Área de Trabalho Remota) e do Secure Shell (SSH) às VMs na rede virtual. Isso fornece acesso ao limitar os endereços IP públicos expostos das VMs na rede virtual. O Azure Bastion fornece uma alternativa econômica a uma VM provisionada para fornecer acesso a todas as VMs na mesma rede virtual.

Recomendações

As seguintes recomendações aplicam-se à maioria dos cenários. Siga estas recomendações, a menos que você tenha um requisito específico que as substitua.

  • Use pelo menos duas regiões do Azure para maior disponibilidade. Você pode implantar seu aplicativo em várias regiões do Azure em configurações ativas/passivas ou ativas/ativas. Para obter detalhes, consulte Várias regiões.
  • Para cargas de trabalho de produção, execute pelo menos duas instâncias de gateway. Observe que, nessa arquitetura, os pontos de extremidade públicos dos Gateways de Aplicativo são configurados como back-ends do Gerenciador de Tráfego.
  • Use regras de NSG (Grupos de Segurança de Rede) para restringir o tráfego entre as camadas. Para obter detalhes, consulte Grupos de Segurança de Rede.

Considerações sobre disponibilidade

Zonas de Disponibilidade do Azure

O Azure Zonas de Disponibilidade fornecer alta disponibilidade dentro de uma região. Uma rede regional conecta pelo menos três datacenters colocados estrategicamente fisicamente distintos em cada região.

Várias regiões

A implantação em várias regiões pode fornecer maior disponibilidade do que a implantação em uma única região. Se uma interrupção regional afetar a região primária, você poderá usar o Gerenciador de Tráfego para fazer failover para a região secundária. Várias regiões também podem ajudar se um subsistema individual do aplicativo falhar.

Observe que essa arquitetura é aplicável a configurações ativas/passivas e ativas em regiões do Azure.

Para obter informações técnicas, consulte Regiões e Zonas de Disponibilidade no Azure.

Regiões emparelhadas

Cada região do Azure é emparelhada com outra região na mesma geografia (por exemplo, o Estados Unidos, Europa ou Ásia). Essa abordagem permite a replicação de recursos, como o armazenamento de VM, entre regiões. A ideia é manter uma região disponível mesmo que a outra se torne indisponível devido a desastres naturais, agitação civil, perda de energia, interrupção de rede e assim por diante.

Há outras vantagens do emparelhamento regional, incluindo:

  • No caso de uma interrupção mais ampla do Azure, é priorizada uma região de cada par para ajudar a reduzir o tempo de restauração dos aplicativos.
  • As atualizações planejadas do Azure são distribuídas para regiões emparelhadas uma por vez, de modo a minimizar o tempo de inatividade e o risco de interrupção dos aplicativos.
  • Os dados continuam residindo na mesma geografia que seu par (com exceção do Sul do Brasil) para fins de jurisdição do imposto e aplicação da lei.

Verifique se ambas as regiões dão suporte a todos os serviços do Azure de que seu aplicativo precisa (consulte Serviços por região). Para saber mais sobre pares regionais, confira Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Combinadas do Azure.

Configuração do Gerenciador de Tráfego

O Gerenciador de Tráfego oferece alta disponibilidade para seus aplicativos críticos monitorando pontos de extremidade e fornecendo failover automático quando um ponto de extremidade fica inoperante.

Considere os seguintes pontos ao configurar o Gerenciador de Tráfego:

  • Roteamento: O Gerenciador de Tráfego dá suporte a seis métodos de roteamento de tráfego para determinar como rotear o tráfego para os vários pontos de extremidade de serviço. Nessa arquitetura, usamos o roteamento de desempenho, que roteia o tráfego para o ponto de extremidade que tem a menor latência para o usuário. O Gerenciador de Tráfego é ajustado automaticamente à medida que as latências de ponto de extremidade são alteradas. Além disso, se você precisar de um controle mais granular, por exemplo, para escolher um failover preferencial em uma região, poderá usar o Gerenciador de Tráfego em uma configuração aninhada.

    Para obter informações de configuração, consulte Configurar o método de roteamento de tráfego de desempenho.

    Para obter informações sobre os vários métodos de roteamento, consulte os métodos de roteamento do Gerenciador de Tráfego.

  • Investigação de integridade: O Gerenciador de Tráfego usa uma investigação HTTP (ou HTTPS) para monitorar a disponibilidade de cada região. A investigação verifica uma resposta HTTP 200 para um caminho de URL especificado. Como uma prática recomendada, crie um ponto de extremidade que relata a integridade geral do aplicativo e use esse ponto de extremidade para a investigação de integridade. Caso contrário, a investigação poderá relatar um ponto de extremidade íntegro quando partes críticas do aplicativo estiverem falhando. Para obter mais informações, consulte Padrão de monitoramento de ponto de extremidade de integridade.

    Quando o Gerenciador de Tráfego faz failover, há um período em que os clientes não podem acessar o aplicativo. A duração é afetada pelos seguintes fatores:

    • A investigação de integridade precisa detectar que a região primária ficou inacessível.
    • Os servidores DNS precisam atualizar os registros DNS armazenados em cache para o endereço IP, dependendo da TTL (vida útil) DNS. A TTL padrão é 300 segundos (5 minutos), mas você pode configurar esse valor ao criar o perfil do Gerenciador de Tráfego.

    Para obter mais detalhes, consulte Sobre o Monitoramento do Gerenciador de Tráfego.

  • Modo de Exibição de Tráfego: Habilite o Modo de Exibição de Tráfego para entender quais regiões têm uma grande quantidade de tráfego, mas sofrem com latências mais altas. Em seguida, usar essas informações para planejar sua expansão de volume para novas regiões do Azure. Dessa forma, os usuários terão uma experiência de latência mais baixa. Consulte o Modo de Exibição de Tráfego do Gerenciador de Tráfego para obter detalhes.

Gateway de Aplicativo

  • Gateway de Aplicativo SKU v1 dá suporte a cenários de alta disponibilidade quando você implanta duas ou mais instâncias. O Azure distribui essas instâncias entre domínios de atualização e de falha para garantir que todas as instâncias não falham ao mesmo tempo. O v1 SKU suporta escalabilidade adicionando várias instâncias do mesmo gateway para compartilhar a carga.
  • Gateway de Aplicativo SKU v2 garante automaticamente que novas instâncias sejam distribuídas entre domínios de falha e domínios de atualização. Se você escolher redundância de zona, as instâncias mais recentes também serão distribuídas entre zonas de disponibilidade para oferecer resiliência de falha de zona.

Investigações de integridade

O Gateway de Aplicativo e o Load Balancer usam investigações de integridade para monitorar a disponibilidade de instâncias de VM.

  • O Gateway de Aplicativo sempre usa uma investigação HTTP.
  • O Load Balancer pode testar HTTP ou TCP. Em geral, se uma VM executar um servidor HTTP, use uma investigação HTTP. Caso contrário, use TCP.

Se uma investigação não puder alcançar uma instância dentro de um período de tempo limite, o Gateway de Aplicativo ou Load Balancer interromperá o envio de tráfego para essa VM. A investigação continua a verificar e retornará a VM para o pool de back-end se a VM ficar disponível novamente. As investigações HTTP enviam uma solicitação HTTP GET para um caminho especificado e escutam uma resposta HTTP 200. Esse caminho pode ser o caminho raiz ("/"), ou um ponto de extremidade de monitoramento de integridade que implementa a lógica personalizada para verificar a integridade do aplicativo. O ponto de extremidade deve permitir solicitações HTTP anônimas.

Para obter mais informações sobre investigações de integridade, confira:

Para obter considerações sobre como criar um ponto de extremidade de investigação de integridade, confira Padrão de Monitoramento de Ponto de Extremidade de Integridade.

Considerações sobre capacidade de gerenciamento

  • Grupos de recursos: Use grupos de recursos para gerenciar recursos do Azure por tempo de vida, proprietário e outras características.
  • Emparelhamento de rede virtual: Use o emparelhamento de rede virtual para conectar diretamente duas ou mais redes virtuais no Azure. As redes virtuais aparecerão como uma só para fins de conectividade. O tráfego entre máquinas virtuais em uma rede virtual emparelhada usa infraestrutura de backbone da Microsoft. Verifique se o espaço de endereço das redes virtuais não se sobrepõe. Nesse cenário, as redes virtuais são emparelhadas por meio do emparelhamento de rede virtual global para permitir a replicação de dados da região primária para a região secundária.
  • Rede virtual e sub-redes: A VM do Azure e recursos específicos do Azure (como Gateway de Aplicativo e Load Balancer) são implantados em uma rede virtual que pode ser segmentada em sub-redes. Sempre crie uma sub-rede separada para cada camada.

Considerações de segurança

  • Use o DDoS Protection Standard para maior proteção contra DDoS do que a proteção básica fornecida pelo Azure. Para obter mais informações, confira Considerações de segurança.
  • Use NSGs (Grupos de Segurança de Rede) para restringir o tráfego de rede na rede virtual. Por exemplo, na arquitetura de três camadas mostrada aqui, a camada de banco de dados aceita o tráfego somente da camada de negócios e da sub-rede bastion, não do front-end da Web.

Grupos de segurança de rede

Somente a camada de negócios pode se comunicar diretamente com a camada de banco de dados. Para impor essa regra, a camada de banco de dados deve bloquear todo o tráfego de entrada, exceto para a sub-rede da camada de negócios.

  1. Negue todo o tráfego de entrada da rede virtual. (Use a marca VIRTUAL_NETWORK na regra.)
  2. Permitir o tráfego de entrada da sub-rede da camada de negócios.
  3. Permitir o tráfego de entrada da própria sub-rede da camada de banco de dados. Essa regra permite a comunicação entre as VMs de banco de dados, que é necessária para failover e replicação de banco de dados.

Crie regras 2 – 3 com prioridade maior do que a primeira regra, portanto, elas a substituem.

Você pode usar marcas de serviço para definir controles de acesso à rede em Grupos de Segurança de Rede ou Firewall do Azure. Consulte Gateway de Aplicativo configuração de infraestrutura para obter detalhes sobre Gateway de Aplicativo requisitos do NSG.

Preços

Use a Calculadora de Preços do Azure para estimar os custos. Algumas outras considerações.

Conjuntos de Dimensionamento de Máquinas Virtuais

Conjuntos de Dimensionamento de Máquinas Virtuais estão disponíveis em todos os tamanhos de VM do Windows. Você só é cobrado pelas VMs do Azure implantadas e pelos recursos de infraestrutura subjacentes adicionais consumidos, como armazenamento e rede. Não há encargos incrementais para o serviço Conjuntos de Dimensionamento de Máquinas Virtuais.

Para obter opções de preços de VM única, consulte Preços de Máquinas Virtuais do Windows.

Standard Load Balancer

O preço do Standard Load Balancer é por hora com base no número de regras de balanceamento de carga de saída configuradas. As regras NAT de entrada são gratuitas. Não há nenhum custo por hora para a SKU Standard Load Balancer quando nenhuma regra é configurada. Também há uma cobrança pela quantidade de dados que o Load Balancer processa.

Para obter mais informações, confira os preços do Balanceamento de Carga.

SKU Gateway de Aplicativo v2

O Gateway de Aplicativo deve ser provisionado com a SKU v2 e pode abranger vários Zonas de Disponibilidade. Com a SKU v2, o modelo de preços é impulsionado pelo consumo e tem dois componentes: preço fixo por hora e custo baseado em consumo.

Para obter mais informações, consulte Gateway de Aplicativo preços.

Gerenciador de Tráfego

A cobrança do Gerenciador de Tráfego é baseada no número de consultas DNS recebidas, com um desconto para serviços que recebem mais de 1 bilhão de consultas mensais. Você também é cobrado por cada ponto de extremidade monitorado. Para obter informações sobre preços, consulte os preços do Gerenciador de Tráfego.

Emparelhamento de rede virtual

Uma implantação de alta disponibilidade que aproveita várias Regiões do Azure usa o emparelhamento de rede virtual. Os encargos para emparelhamento de rede virtual na mesma região não são os mesmos que os encargos para emparelhamento de rede virtual global.

Para saber mais, confira Preços de rede virtual.

Próximas etapas

Para arquiteturas de referência adicionais usando as mesmas tecnologias, consulte: