Design de rede de várias regiões

Este artigo explica como projetar redes Azure que abrangem várias regiões. Uma rede de várias regiões fornece alta disponibilidade contra interrupções regionais, atende usuários geograficamente distribuídos com menor latência e dá suporte aos requisitos de residência de dados regulatórios.

O que este artigo aborda

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

Quem precisa deste artigo

Leia este artigo se o ambiente corresponder a qualquer uma dessas condições:

• Sua carga de trabalho requer proteção de recuperação de desastre contra uma falha de região de Azure completa.
• Você atende usuários em várias geografias e precisa minimizar a latência de rede.
• Os requisitos regulatórios ou de conformidade exigem que os dados permaneçam dentro de limites geográficos específicos.
• Seus objetivos de continuidade de negócios definem um RTO (objetivo de tempo de recuperação) que uma única região não pode atender sozinha.

Se sua carga de trabalho opera em uma única região e implantações com redundância de zona atendem aos seus requisitos de disponibilidade, talvez você ainda não precise de um design de várias regiões. Comece com uma topologia hub-and-spoke ou WAN Virtual em uma região e expanda posteriormente.

Azure serviços e recursos

A tabela a seguir lista os Azure serviços e recursos que habilitam a rede de várias regiões:

Por que a multirregião requer várias redes virtuais

Uma rede virtual (VNet) abrange uma única região. As sub-redes nessa VNet abrangem todas as zonas de disponibilidade na região, mas a própria VNet não pode se estender entre os limites da região. A rede de várias regiões significa, portanto, implantar várias VNets, uma ou mais por região, e conectá-las com serviços entre regiões.

Essa restrição fundamental forma cada design de várias regiões:

• Cada região precisa de seu próprio espaço de endereços VNet (sem sobreposição com outras regiões para o emparelhamento).
• O tráfego entre regiões requer um mecanismo de conectividade explícito: emparelhamento global de VNet, roteamento entre hubs do WAN Virtual ou um roteamento baseado em gateway.
• Os serviços globais de balanceamento de carga (Gerenciador de Tráfego ou Front Door) direcionam os usuários para a implantação regional correta.

Para obter diretrizes de planejamento de sub-rede e endereço, consulte o planejamento de endereço IP.

Zonas de disponibilidade versus redundância regional

Antes de criar uma topologia de várias regiões, entenda os dois níveis de redundância de infraestrutura em Azure:

Comece com redundância de zona. As implantações com redundância de zona protegem contra os cenários de falha mais comuns (problemas de datacenter único) sem a complexidade do roteamento de várias regiões. Adicione redundância regional quando sua empresa exigir proteção contra interrupções em toda a região ou quando você precisar atender usuários geograficamente distribuídos.

Referência de serviços de rede com redundância de zona

A tabela a seguir mostra as opções de implantação com redundância de zona para os principais serviços de rede. Implante-as em todas as regiões em que você executa cargas de trabalho:

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

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

Como escolher uma topologia de hub de várias regiões

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

Para obter uma comparação detalhada de hub-and-spoke versus WAN Virtual em uma única região, consulte a topologia hub-and-spoke e WAN Virtual.

Considerações sobre o design

Pré-requisitos

Antes de criar uma rede de várias regiões, verifique se você tem:

• Implantou e testou uma topologia de região única. Comece com hub-and-spoke ou WAN Virtual.
• Requisitos de alta disponibilidade e recuperação de desastre definidos: RTO, RPO (objetivo de ponto de recuperação) e mandatos de conformidade.
• Criou um plano de endereço IP não sobreposto em todas as regiões. Consulte o planejamento de endereço IP.
• Identificou quais cargas de trabalho precisam de redundância regional e quais precisam apenas de redundância de zona.

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

Seu modelo de implantação de várias regiões determina como o tráfego flui durante a operação normal e durante uma falha regional:

Active-active

Ambas as regiões atendem ao tráfego simultaneamente. Um balanceador de carga global, como o Gerenciador de Tráfego ou o Front Door, distribui solicitações entre regiões com base na proximidade, desempenho ou peso.

Quando usar ativo-ativo:

• Seu aplicativo pode lidar com solicitações em qualquer região sem dependências de estado específicas da região.
• Você precisa do menor RTO possível (o failover é imediato porque a região íntegra já está atendendo o tráfego).
• Você deseja usar a capacidade em ambas as regiões durante a operação normal (eficiência de custo).

Considerações de rede:

• Ambas as regiões devem ter infraestrutura de rede idêntica, incluindo firewalls, gateways e balanceadores de carga.
• A replicação de dados entre regiões deve manter ambas as implantações atuais.
• Os intervalos das sondas de integridade e o TTL do DNS determinam com que rapidez o Gerenciador de Tráfego redireciona o tráfego. O Front Door proporciona um failover mais rápido em nível de conexão.

Active-passive

Uma região (primária) manipula todo o tráfego. A região secundária permanece pronta, mas não atende às solicitações do usuário até um evento de failover.

Quando usar ativo-passivo:

• Seu aplicativo tem requisitos estritos de região de gravação ou não pode replicar facilmente o estado.
• Restrições de custo impedem a execução de capacidade total em duas regiões simultaneamente.
• Sua tolerância de RTO permite o tempo necessário para ativar a região secundária.

Considerações de rede:

• A infraestrutura de rede da região passiva pode usar níveis menores ou capacidade reduzida até que ocorra o failover.
• O failover automatizado requer sondagens de integridade com limites apropriados (para evitar oscilações).
• Teste o failover regularmente. As configurações de rede na região passiva podem ficar divergentes se não forem validadas.
• Mantenha tabelas de rotas e regras NSG sincronizadas entre regiões. Use modelos de infraestrutura como código para garantir que a região passiva corresponda à postura de segurança da região primária.
• Pré-provisionar gateways VPN ou ExpressRoute na região passiva. O provisionamento de gateway pode levar de 20 a 45 minutos. Isso é lento demais para a maioria das metas de RTO.

Escolhendo entre redes ativas-ativas e ativas-passivas

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

Replicação e latência de dados

A replicação entre regiões introduz a latência de rede que afeta o design do aplicativo. As regiões do Azure na mesma região geográfica normalmente apresentam latência de ida e volta de 1 a 10 ms para pares de regiões próximas (por exemplo, East US para East US 2) e de 30 a 70 ms para pares de regiões distantes (por exemplo, East US para West US). Pares de regiões transatlânticos ou transpacíficos podem exceder 100 ms.

Principais considerações de design:

• Topologia de replicação: Escolha a replicação síncrona somente para pares de região com baixa latência (< 10 ms). Use a replicação assíncrona para pares distantes para evitar a degradação do desempenho do aplicativo.
• Planejamento de largura de banda: estime os requisitos de taxa de transferência de replicação e considere os custos de transferência de dados por GB do Emparelhamento VNET Global. A replicação de alto volume entre regiões distantes pode gerar encargos de saída significativos.
• Resolução de conflitos: Padrões ativos com gravações bidirecionais exigem estratégias de resolução de conflitos na camada de aplicativo ou banco de dados. A rede fornece conectividade, mas os aplicativos devem lidar com conflitos de gravação.
• Pontos de extremidade privados para replicação de PaaS: Ao replicar SQL do Azure, Cosmos DB ou Armazenamento entre regiões, use pontos de extremidade privados em cada região para manter o tráfego de replicação no Microsoft backbone e evitar a exposição pública à Internet.

Considerações de custo

A rede de várias regiões aumenta os custos por meio da infraestrutura duplicada e da transferência de dados entre regiões. Planeje seu orçamento em torno desses drivers de custo primários:

• Transferência de dados entre regiões: O Emparelhamento Global de VNet e o tráfego entre hubs da WAN Virtual geram cobrança por GB para dados que cruzam os limites entre regiões. O tráfego intra-região entre VNets emparelhadas na mesma região não tem custo adicional para a mesma zona e é cobrado a uma taxa menor para zonas diferentes.
• Dispositivos de rede duplicados: Cada região requer seu próprio firewall, balanceador de carga e instâncias de gateway. Implantações ativas-ativas dobram esses custos. Implantações ativas-passivas podem reduzir custos usando camadas menores na região de espera e escalando durante a falha.
• Taxas globais de balanceamento de carga: O Gerenciador de Tráfego e o Front Door cobram com base em consultas DNS ou solicitações processadas. O Front Door cobra adicionalmente pela transferência de dados dos PoPs de borda para os back-ends.
• ExpressRoute e Gateway de VPN: Projetos multirregionais geralmente exigem instâncias de gateway em cada região. Os circuitos do ExpressRoute que conectam várias regiões adicionam taxas mensais de porta e encargos de dados medidos por GB.
• Otimize considerando a localidade do tráfego: Projete camadas da aplicação para minimizar chamadas entre regiões. Mantenha as réplicas de leitura localizadas junto com o poder computacional em cada região para reduzir a largura de banda de replicação e as consultas sensíveis à latência.

Considerações de segurança

Uma rede de várias regiões apresenta considerações de segurança além das implantações de região única:

• O tráfego permanece na infraestrutura da Microsoft. Todo o tráfego entre regiões pelo emparelhamento global de VNets ou pela conectividade entre hubs da WAN Virtual percorre a rede de backbone da Microsoft, não a internet pública.
• Implante firewalls com redundância de zona em todas as regiões. Cada hub regional precisa de sua própria instância de firewall para inspeção de tráfego. Implante firewalls entre zonas de disponibilidade para manter a segurança durante falhas de zona.
• O Front Door WAF fornece segurança de borda. Quando você usa o Front Door, seu Firewall de Aplicativo Web integrado inspeciona o tráfego antes de atingir qualquer implantação regional. Isso fornece uma primeira camada de defesa na borda da rede.
• Planeje o failover de DNS com cuidado. O failover do Gerenciador de Tráfego depende do TTL do DNS. TTLs mais curtos permitem um failover mais rápido, mas aumentam o volume de consultas DNS. O Front Door fornece failover em nível de conexão que não depende da expiração do cache DNS do cliente.
• O tráfego do Alcance Global do ExpressRoute permanece privado. O tráfego entre sites on-premises conectados por meio do Global Reach nunca passa pela internet pública. Ele permanece na rede principal da Microsoft entre os circuitos.
• Proteger canais de replicação entre regiões. O tráfego de replicação de back-end sobre o Emparelhamento VNet Global é privado por padrão, mas aplique grupos de segurança de rede e criptografia para dados confidenciais em trânsito.

Artigos relacionados

Se o design de várias regiões envolver cenários específicos abordados em outros lugares neste guia, confira:

• Topologia hub-and-spoke: padrão de design com um hub por região para implantações multirregionais.
• WAN Virtual: WAN Virtual padrão de vários hubs com roteamento entre hubs automático.
• Conectividade entre regiões: diretrizes detalhadas sobre emparelhamento, Alcance Global e opções de conectividade entre hubs.
• VNets e sub-redes: design de VNet por região e planejamento de sub-rede.
• Planejamento de endereço IP: espaços de endereço não sobrepostos entre regiões.
• Firewall do Azure e inspeção de tráfego: implantação de firewall com redundância de zona em cada hub regional.

Saiba mais

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

• Visão geral do Gerenciador de Tráfego
• Visão geral do Azure Front Door
• Visão geral do emparelhamento de rede virtual
• Alcance Global do ExpressRoute Global
• Arquitetura da rede global de trânsito da WAN Virtual
• Regiões e zonas de disponibilidade no Azure

Próximas Etapas