Conceção de redes multirregional

Este artigo explica como desenhar redes Azure que abrangem múltiplas regiões. Uma rede multirregional oferece alta disponibilidade contra interrupções regionais, serve utilizadores geograficamente distribuídos com menor latência e suporta os requisitos regulatórios de residência de dados.

O que este artigo aborda

Este artigo aborda a redundância por zona versus a redundância regional, as estratégias de encaminhamento entre regiões, as escolhas de topologia em hub para implementações multirregionais, os padrões de failover ativo-ativo versus ativo-passivo e as considerações sobre a latência de replicação.

Quem precisa deste artigo

Leia este artigo se o seu ambiente corresponder a alguma destas condições:

  • A sua carga de trabalho requer proteção em recuperação de desastres contra uma falha total da região Azure.
  • Serve utilizadores em múltiplas geografias e precisa de minimizar a latência da rede.
  • Os requisitos regulatórios ou de conformidade exigem que os dados permaneçam dentro de limites geográficos específicos.
  • Os seus objetivos de continuidade do negócio definem um objetivo de tempo de recuperação (RTO) que uma única região não consegue cumprir sozinha.

Se a sua carga de trabalho opera numa única região e as implementações redundantes de zona cumprem os seus requisitos de disponibilidade, pode ainda não precisar de um design multirregional. Comece com uma topologia hub-and-spoke ou WAN Virtual numa região e estenda mais tarde.

Foco em levantar e deslocar: Cargas de trabalho legadas muitas vezes não conseguem correr ativo-ativo entre regiões. Planeie a recuperação de desastres com o Azure Site Recovery e um hub na região de recuperação, em vez de um design ativo-ativo completo.

Modernizar o foco: Implemente aplicações orientadas para o cliente ativa-ativa em duas regiões com SKUs redundantes por zona, usando espaço de endereçamento não sobreposto para que as regiões possam fazer peering se necessário.

Foco multicloud: Utilize o WAN Virtual do Azure para ligar várias regiões e sucursais e planeie o encaminhamento entre regiões em conjunto com o seu trânsito multicloud.

Serviços e funcionalidades do Azure

A tabela seguinte lista os serviços e funcionalidades do Azure que permitem a rede multirregional:

Serviço ou funcionalidade Papel na conceção multirregião Saiba mais
Gestor de Tráfego do Azure Encaminhamento de tráfego baseado em DNS entre regiões para qualquer protocolo Visão geral do Gestor de Tráfego
Azure Front Door Balanceamento de carga global HTTP/HTTPS com CDN e WAF na periferia Visão geral da Porta Principal
Peering Global de VNet Conectividade privada e de alta largura de banda entre redes virtuais em diferentes regiões Emparelhamento de rede virtual
Alcance Global do ExpressRoute Liga sites on-premises entre si através da backbone do Azure Alcance Global do ExpressRoute
WAN Virtual do Azure (multi-hub) Transporte global gerido pela Microsoft com roteamento automático entre centros Trânsito global WAN Virtual
Azure Virtual Network Manager (AVNM) Automatiza a topologia de peering entre regiões e a gestão de grupos de rede Visão geral do AVNM

Porque é que a multirregião requer múltiplas redes virtuais

Uma rede virtual (VNet) abrange uma única região. As sub-redes dentro desse VNet abrangem todas as zonas de disponibilidade da região, mas o próprio VNet não pode estender-se para além das fronteiras regionais. Rede multirregional significa, portanto, implementar múltiplos VNets, um ou mais por região, e ligá-los a serviços interregionais.

Diagrama que mostra uma topologia ativa-ativa de duas regiões com o Azure Front Door e o WAF a encaminhar o tráfego de entrada global para as regiões Europa Ocidental e Leste dos Estados Unidos, cada uma contendo uma VNet de hub com o Azure Firewall e o Azure Bastion em peering com uma VNet spoke de carga de trabalho, com Global VNet Peering através da rede de backbone da Microsoft a ligar as duas regiões.

Esta restrição fundamental molda todos os desenhos multirregionais:

  • Cada região precisa do seu próprio espaço de endereçamento de VNet (que não se sobreponha ao das outras regiões para emparelhamento).
  • O tráfego entre regiões requer um mecanismo explícito de conectividade: Global VNet Peering, WAN Virtual inter-hub ou encaminhamento baseado em gateway.
  • Os serviços globais de balanceamento de carga (Traffic Manager ou Front Door) direcionam os utilizadores para a implementação regional correta.

Para orientações sobre planeamento de sub-redes e endereços, consulte planeamento de endereços IP.

Zonas de disponibilidade versus redundância regional

Antes de desenhar uma topologia multirregional, compreenda os dois níveis de redundância de infraestrutura no Azure:

Nível Protege contra Mecanismo Example
Zonas de disponibilidade Falha única do centro de dados numa região Centros de dados fisicamente separados com energia, arrefecimento e rede independentes Azure Firewall redundante de zona implementado em 3 zonas
Redundância regional Falha total da região (desastre natural, interrupção generalizada) Implementar cargas de trabalho em duas ou mais regiões do Azure Aplicação web ativa-ativa no Leste e Oeste dos EUA

Comece com redundância de zonas. Implementações redundantes por zona protegem contra os cenários de falha mais comuns (problemas de centro de dados únicos) sem a complexidade do encaminhamento multirregional. Adicione redundância regional quando o seu negócio precisa de proteção contra falhas regionais ou quando precisa de servir utilizadores geograficamente distribuídos.

Referência de serviços de rede com redundância entre zonas

A tabela seguinte mostra opções de implementação redundantes por zona para serviços de rede central. Implemente estes em todas as regiões onde execute cargas de trabalho:

Serviço Opção com redundância entre zonas Notes
Azure Firewall Implantar em zonas de disponibilidade Distribui-se por todas as 3 zonas da região
Balanceador de Carga Standard Frontend redundante por zona Comportamento padrão para SKU Standard
Gateway de Aplicação v2 Implantação com redundância entre zonas Requer o SKU Standard_v2 ou WAF_v2
Gateway de VPN Ativo-ativo com SKUs com redundância entre zonas Utilize SKUs com o sufixo AZ (VpnGw1AZ, VpnGw2AZ, etc.)
Gateway do ExpressRoute SKUs com redundância entre zonas Use ErGw1AZ, ErGw2AZ ou ErGw3AZ
Azure Bastion Com redundância entre zonas (pré-visualização) SKUs Básicas, Padrão e Premium
NAT Gateway (StandardV2) Redundância zonal SKU StandardV2 obrigatório; O SKU padrão é apenas zonal

Como escolher uma abordagem de encaminhamento de tráfego entre regiões

Use a seguinte tabela de decisão para selecionar o serviço certo para encaminhar o tráfego entre regiões:

O seu requisito Serviço recomendado Como funciona
Failover ou distribuição de carga entre várias regiões para qualquer protocolo (HTTP, TCP, UDP) Gestor de Tráfego do Azure Devolve o melhor IP de endpoint através da resolução DNS. O cliente liga-se diretamente ao endpoint. A velocidade de failover depende do DNS TTL (tipicamente 30–300 segundos).
Distribuição global de carga HTTP/HTTPS com CDN, WAF e comutação automática rápida em caso de falha Azure Front Door Termina as ligações em pontos de presença periféricos (PoPs). Encaminha os pedidos para o backend saudável mais próximo. Fornece failover ao nível da ligação (segundos, não depende de DNS-TTL).
Tráfego backend privado entre regiões (replicação, APIs internas) Peering Global de VNet Liga VNets entre regiões através da espinha dorsal da Microsoft. Peering não é transitivo; cada relação de peering é explícita. Aplicam-se taxas de transferência de dados por GB.
Conectividade site-to-site on-premises através do Azure Alcance Global do ExpressRoute Liga dois circuitos ExpressRoute para que as localizações locais comuniquem através da backbone da Microsoft sem atravessar routers hub.

Dica

Combine estes serviços. Por exemplo, use o Front Door para tráfego HTTP direcionado ao utilizador e o Global VNet Peering para replicação backend entre regiões.

Como escolher uma topologia hub multirregional

Depois de decidir expandir a sua rede por regiões, escolha um padrão hub para gerir a conectividade entre regiões:

Fator Centro por região (tradicional) WAN Virtual multi-hub
Conectividade entre regiões O cliente configura o Peering Global VNet entre hubs regionais e gere os UDRs Encaminhamento automático entre hubs: todos os hubs WAN Virtual interligam-se por defeito
Management Controlo total do cliente sobre o encaminhamento, regras de firewall e peering Infraestrutura de hub gerida pela Microsoft com gestão baseada em políticas
Melhor para Organizações que necessitam de controlo de roteamento granular, NVAs personalizadas ou investimentos em hubs existentes Organizações com muitas regiões, 30+ filiais, ou preferência por infraestrutura gerida
Trânsito global Requer emparelhamento explícito + configuração de UDR entre cada par de hubs Incorporado: o tráfego entre quaisquer dois hubs roteia automaticamente
Escalonamento Adicionar hubs e emparelhamentos manualmente (o AVNM pode automatizar) Adicionar hubs através da configuração da WAN Virtual: atualizações automáticas de roteamento
Modelo de custo Os recursos do Hub VNet (firewall, gateway, peering) são faturados separadamente Preços unitários do WAN Virtual mais recursos ligados

Para uma comparação detalhada entre hub-and-spoke versus WAN Virtual numa única região, veja Topologia Hub-and-spoke e WAN Virtual.

Considerações de design

Foco em design multi-região lift-and-shift

  • Para cargas de trabalho legadas que não podem abranger zonas ou regiões, conceba a solução para recuperação após desastre em vez de ativo-ativo: replique com o Azure Site Recovery para uma região de recuperação.
  • Constrói um hub na região de recuperação que espelhe o hub principal para que o tráfego de failover tenha os mesmos serviços partilhados.
  • Use o Gestor de Tráfego do Azure ou o failover DNS para redirecionar utilizadores durante uma falha regional.
  • Mantenha o espaço de endereçamento da região de recuperação não sobreposto à região primária para evitar conflitos durante o failover e qualquer peering posterior.

Modernizar o foco do design multirregional

  • Implemente cargas de trabalho orientadas para o cliente ativas-ativas em duas regiões com SKUs redundantes por zona para garantir a mais alta postura de resiliência.
  • Atribuir intervalos de endereços não sobrepostos às regiões primária e de backup para que os spokes ativo-ativo possam utilizar mais tarde o peering global de VNet sem reendereçamento.
  • Escolha a sua camada de entrega por tipo de aplicação: Azure Front Door para aplicações web e Traffic Manager para aplicações não-web, distribuindo entre endpoints públicos regionais.
  • Coloque os endpoints públicos de cada região com o firewall do hub (SNAT e DNAT) para que o tráfego de entrada seja inspecionado antes de chegar aos backends.

Foco na conceção multirregional entre clouds

  • Utilize o WAN Virtual do Azure para interligar múltiplas regiões do Azure, filiais e extremidades da cloud com encaminhamento automático entre quaisquer pontos.
  • Planeie intervalos de endereços agregados e não sobrepostos entre regiões e ambientes de cloud, para que o encaminhamento de trânsito se mantenha simples.
  • Termine as ligações IPsec entre nuvens em hubs regionais seguros e deixe que a WAN Virtual trate do encaminhamento entre hubs.
  • Distribua a entrada pública entre regiões usando o Front Door ou o Traffic Manager, e mantenha a inspeção em cada firewall regional do hub.

Pré-requisitos

Antes de desenhar uma rede multirregional, certifique-se de que tem:

  • Implementou e testou uma topologia de região única. Comece com hub-and-spoke ou WAN Virtual.
  • Requisitos definidos de alta disponibilidade e recuperação de desastres: RTO, objetivo do ponto de recuperação (RPO) e mandatos de conformidade.
  • Criei um plano de endereços IP sem sobreposição em todas as regiões. Ver planeamento de endereços IP.
  • Identificou quais as cargas de trabalho que necessitam de redundância regional versus redundância apenas de zona.

Padrões de implantação ativo-ativo versus ativo-passivo

O seu modelo de implementação multirregional determina como o tráfego flui durante a operação normal e durante uma falha regional:

Active-active

Ambas as regiões servem o tráfego em simultâneo. Um balanceador de carga global, como o Traffic Manager ou o Front Door, distribui pedidos entre regiões com base na proximidade, desempenho ou peso.

Quando usar ativo-ativo:

  • A sua aplicação pode tratar pedidos em qualquer região sem dependências de estado específicas de cada região.
  • Precisas do RTO mais baixo possível (o failover é imediato porque a região saudável já serve o tráfego).
  • Queres usar a capacidade em ambas as regiões durante a operação normal (eficiência de custos).

Considerações de networking:

  • Ambas as regiões devem ter uma infraestrutura de rede idêntica, incluindo firewalls, gateways e balanceadores de carga.
  • A replicação de dados entre regiões deve manter ambas as implementações atualizadas.
  • O TTL do DNS e os intervalos da sonda de estado de funcionamento determinam a rapidez com que o Traffic Manager redireciona o tráfego. O Front Door oferece um failover de nível de ligação mais rápido.

Active-passive

Uma região (primária) gere todo o tráfego. A região secundária mantém-se pronta, mas não processa os pedidos dos utilizadores até ocorrer um failover.

Quando usar ativo-passivo:

  • A sua aplicação tem requisitos rigorosos de região de escrita ou não consegue replicar facilmente o estado.
  • As restrições de custo impedem a operação de capacidade total em duas regiões simultaneamente.
  • A sua tolerância ao RTO permite o tempo necessário para ativar a região secundária.

Considerações de networking:

  • A infraestrutura de rede da região passiva pode utilizar escalões inferiores ou capacidade reduzida até ocorrer a comutação por falha.
  • A comutação pós-falha automatizada requer sondas de estado de funcionamento com limiares adequados (para evitar oscilações).
  • Teste regularmente a ativação pós-falha. Configurações de rede na região passiva podem derivar se não forem validadas.
  • Mantenha as tabelas de rotas e as regras NSG sincronizadas entre regiões. Utilize modelos de infrastructure-as-code para garantir que a região passiva corresponde à postura de segurança da região principal.
  • Pré-aprovisionar os gateways VPN ou ExpressRoute na região passiva. O provisionamento do gateway pode demorar entre 20 a 45 minutos. É demasiado lento para a maioria dos objetivos de RTO.

Escolha entre redes ativas-ativas e ativas-passivas

A escolha entre rede ativa-ativa e ativa-passiva afeta o tamanho da rede, o custo e a complexidade operacional:

Consideração Active-active Active-passive
Capacidade da rede Capacidade total em ambas as regiões Capacidade reduzida na região passiva (dimensionamento em caso de ativação pós-falha)
Aprovisionamento de gateway Sempre ativo em ambas as regiões Pré-provisionado, mas pode usar níveis mais pequenos
Sincronização de dados entre regiões Tráfego contínuo e bidirecional de replicação Replicação assíncrona unidirecional para standby
Regras de firewall Conjuntos de regras idênticos, ambos ativamente aplicados Conjuntos de regras idênticos, mas conjunto passivo raramente utilizado
Endereçamento IP Ambas as regiões anunciam para o balanceador de carga global Apenas a região principal anuncia até ao failover
Risco operacional Inferior: ambos os caminhos são exercidos continuamente Mais alto: o caminho passivo pode derivar ou ter configurações não testadas

Replicação de dados e latência

A replicação entre regiões introduz latência de rede que afeta o design da aplicação. As regiões Azure dentro da mesma geografia apresentam tipicamente uma latência de ida e volta de 1–10 ms para pares próximos (por exemplo, East US para East US 2) e 30–70 ms para pares distantes (por exemplo, East US para West US). Pares de regiões transatlânticas ou transpacíficas podem exceder os 100 ms.

Principais considerações de design:

  • Topologia de replicação: Escolha replicação síncrona apenas para pares de regiões com baixa latência (< 10 ms). Utilize replicação assíncrona para pares distantes para evitar degradação do desempenho da aplicação.
  • Planeamento da largura de banda: Estimar os requisitos de throughput de replicação e contabilizar os custos de transferência de dados do Global VNet Peering por GB. A replicação de alto volume entre regiões distantes pode gerar cargas de saída significativas.
  • Resolução de conflitos: Padrões ativo-ativo com escritas bidirecionais exigem estratégias de resolução de conflitos ao nível da aplicação ou da base de dados. A rede fornece conectividade, mas as aplicações têm de lidar com conflitos de escrita.
  • Pontos finais privados para replicação de PaaS: Ao replicar o SQL do Azure, o Cosmos DB ou o Armazenamento entre regiões, utilize pontos finais privados em cada região para manter o tráfego de replicação na rede principal da Microsoft e evitar a exposição à Internet pública.

Considerações de custos

A rede multirregional aumenta os custos através da infraestrutura duplicada e da transferência de dados entre regiões. Planeie o seu orçamento em função destes principais fatores de custo:

  • Transferência de dados entre regiões: O Peering Global VNet e o tráfego inter-hub WAN Virtual incorrem em custos por GB para os dados que atravessam fronteiras de região. O tráfego intrarregional entre VNets emparelhadas na mesma região não tem custo adicional na mesma zona e é cobrado a uma taxa inferior entre zonas.
  • Aparelhos de rede duplicados: Cada região requer o seu próprio firewall, balanceador de carga e instâncias de gateway. Implantações ativas-ativas duplicam estes custos. As implementações em ativo-passivo podem reduzir os custos ao utilizar níveis inferiores na região de contingência e aumentar a capacidade durante a comutação por falha.
  • Taxas globais de balanceamento de carga: Tanto o Traffic Manager como o Front Door cobram com base nas consultas ou pedidos DNS processados. A Front Door cobra ainda pela transferência de dados dos PoPs da periferia para os backends.
  • ExpressRoute e Gateway de VPN: Os designs multirregional frequentemente requerem instâncias de gateway em cada região. Os circuitos ExpressRoute que ligam várias regiões implicam taxas mensais da porta e custos de dados medidos por GB.
  • Otimize com a localidade do tráfego: Projetar camadas de aplicação para minimizar chamadas entre regiões. Mantenha as réplicas de leitura alojadas na mesma localização que a computação em cada região para reduzir o consumo de largura de banda da replicação e as consultas sensíveis à latência.

Considerações de segurança

Uma rede multirregional introduz considerações de segurança para além das implementações de uma única região:

  • O tráfego permanece na rede principal da Microsoft. Todo o tráfego inter-regional através do Global VNet Peering ou da conectividade inter-hub da WAN Virtual passa pela rede backbone da Microsoft, e não pela Internet pública.
  • Implemente firewalls redundantes de zona em todas as regiões. Cada hub regional precisa da sua própria instância de firewall para inspeção de tráfego. Implante firewalls em várias zonas de disponibilidade para manter a segurança durante falhas de zona.
  • O WAF do Front Door oferece segurança na periferia. Quando utiliza o Front Door, o seu Firewall de Aplicações Web integrado inspeciona o tráfego antes de este chegar a qualquer implementação regional. Isto fornece uma primeira camada de defesa na periferia da rede.
  • Planeia cuidadosamente o failover do DNS. O failover do Traffic Manager depende do DNS TTL. TTLs mais curtos permitem um failover mais rápido, mas aumentam o volume de consultas DNS. O Front Door fornece failover ao nível da ligação que não depende da expiração da cache DNS do cliente.
  • O tráfego ExpressRoute Global Reach mantém-se privado. O tráfego entre os locais locais ligados através do Global Reach nunca chega à internet pública. Permanece na rede principal da Microsoft entre circuitos.
  • Canais de replicação seguros entre regiões. O tráfego de replicação de back-end através do Global VNet Peering é privado por defeito, mas deve aplicar os grupos de segurança de rede e a encriptação aos dados sensíveis em trânsito.

Se o seu design multirregional envolver cenários específicos abordados noutros locais deste guia, veja:

Saiba mais

Para mais informações sobre os serviços e conceitos discutidos neste artigo, consulte os seguintes recursos:

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Ligue-se à sua rede local: Após planear a recuperação em caso de desastre, estabeleça conectividade VPN ou ExpressRoute ao local.

Próximo passo na sua jornada de modernização:

Desenhe os seus padrões de entrada na internet: Determine como o tráfego dos clientes chega às suas aplicações nas suas regiões principais e de backup.

A seguir na sua jornada através da cloud:

Configure túneis cifrados para as suas outras nuvens: Após o planeamento multirregional, configure a conectividade VPN entre nuvens.

  • Last updated on