Conception réseau multirégion

Cet article explique comment concevoir Azure réseaux qui s’étendent sur plusieurs régions. Un réseau multirégion offre une haute disponibilité contre les pannes régionales, sert des utilisateurs géographiquement distribués avec une latence inférieure et prend en charge les exigences de résidence des données réglementaires.

Présentation de cet article

Cet article traite de la redondance zonale par rapport à la redondance régionale, des stratégies de routage interrégion, des choix de topologie de hub pour les déploiements multirégions, des modèles de basculement actif-actif par rapport à actif-passif, et des considérations relatives à la latence de réplication.

Qui a besoin de cet article

Lisez cet article si votre environnement correspond à l’une de ces conditions :

  • Votre charge de travail nécessite une protection de reprise d’activité contre la défaillance complète d’une région Azure.
  • Vous servez les utilisateurs dans plusieurs zones géographiques et devez réduire la latence du réseau.
  • Les exigences réglementaires ou de conformité imposent que les données restent dans des limites géographiques spécifiques.
  • Vos objectifs de continuité d’activité définissent un objectif de délai de récupération (RTO) qu’une seule région ne peut pas respecter seul.

Si votre charge de travail fonctionne dans une seule région et que les déploiements redondants interzone répondent à vos besoins de disponibilité, il se peut que vous n’ayez pas encore besoin d’une conception multirégion. Commencez par une topologie hub-and-spoke ou Virtual WAN dans une région et étendez ultérieurement.

Objectif de la migration lift-and-shift : les charges de travail héritées ne peuvent souvent pas fonctionner en mode actif-actif sur plusieurs régions. Planifiez la récupération d’urgence avec Azure Site Recovery et un hub dans la région de récupération plutôt qu’une conception active complète.

Objectif de la modernisation : déployez des applications destinées aux clients en mode actif-actif sur deux régions avec des références SKU redondantes de zone, en utilisant des espaces d'adressage qui ne se chevauchent pas afin que les régions puissent être appairées si nécessaire.

Accent sur l’intercloud : Utilisez Azure Virtual WAN pour connecter plusieurs régions et succursales, et planifiez le routage interrégional en parallèle de votre transit intercloud.

Azure services et fonctionnalités

Le tableau suivant répertorie les services et fonctionnalités Azure qui activent la mise en réseau multirégion :

Service ou fonctionnalité Rôle dans la conception multirégion Learn more
Azure Traffic Manager Routage du trafic DNS entre régions pour n’importe quel protocole Vue d’ensemble de Traffic Manager
Azure Front Door - Service de passerelle réseau de Microsoft Équilibrage de charge global HTTP/HTTPS avec CDN et WAF à la périphérie Vue d’ensemble de Front Door
VNet Peering global Connectivité privée et à bande passante élevée entre les réseaux virtuels dans différentes régions Interconnexion de réseaux virtuels
ExpressRoute Global Reach Connecte les sites locaux les uns aux autres par le biais de l’Azure principal Service Global Reach d’ExpressRoute
Azure Virtual WAN (multi-hub) transit global géré par Microsoft avec routage automatique entre hubs Transit global Virtual WAN
Azure Virtual Network Manager (AVNM) Automatise la topologie de peering entre régions et la gestion des groupes de réseaux Vue d’ensemble d’AVNM

Pourquoi la multirégion nécessite plusieurs réseaux virtuels

Un réseau virtuel s’étend sur une seule région. Les sous-réseaux au sein de ce réseau virtuel s’étendent sur toutes les zones de disponibilité de la région, mais le réseau virtuel lui-même ne peut pas s’étendre à travers les limites de la région. La mise en réseau multirégion signifie donc déployer plusieurs réseaux virtuels, un ou plusieurs par région et les connecter à des services interrégions.

Schéma montrant une topologie actif-actif sur deux régions avec Azure Front Door et WAF acheminant le trafic entrant mondial vers les régions Europe Ouest et USA Est, chacune contenant un réseau virtuel hub avec Pare-feu Azure et Azure Bastion appairé à un réseau virtuel spoke de charge de travail, avec un peering global de réseaux virtuels via le backbone Microsoft reliant les deux régions.

Cette contrainte fondamentale forme chaque conception multirégion :

  • Chaque région a besoin de son propre espace d’adressage de réseau virtuel (sans chevauchement avec d’autres régions pour le peering).
  • Le trafic interrégional nécessite un mécanisme de connectivité explicite : peering global de réseaux virtuels, interconnexion de hubs Virtual WAN ou routage basé sur des passerelles.
  • Les services d’équilibrage de charge globaux (Traffic Manager ou Front Door) dirigent les utilisateurs vers le déploiement régional approprié.

Pour obtenir des conseils de planification de sous-réseau et d’adresse, consultez la planification des adresses IP.

Zones de disponibilité et redondance régionale

Avant de concevoir une topologie multirégion, comprenez les deux niveaux de redondance de l’infrastructure dans Azure :

Level Protège contre Mécanisme Example
Zones de disponibilité Défaillance d’un centre de données unique dans une région Centres de données physiquement distincts avec alimentation, refroidissement et mise en réseau indépendants Pare-feu Azure redondant interzone déployée sur 3 zones
Redondance régionale Défaillance complète de la région (catastrophe naturelle, panne généralisée) Déploiement de charges de travail dans deux régions Azure ou plus Application web actif-actif dans les régions USA Est et USA Ouest

Commencez par la redondance de zone. Les déploiements redondants interzone protègent contre les scénarios d’échec les plus courants (problèmes de centre de données uniques) sans la complexité du routage multirégion. Ajoutez une redondance régionale lorsque votre entreprise nécessite une protection contre les pannes à l’échelle de la région ou lorsque vous devez servir des utilisateurs géographiquement distribués.

Référence des services réseau avec redondance de zone

Le tableau suivant présente les options de déploiement redondant interzone pour les services réseau principaux. Déployez-les dans chaque région où vous exécutez des charges de travail :

Service Option de redondance de zone Remarques
Pare-feu Azure Déploiement entre plusieurs zones de disponibilité Réparti sur les 3 zones de la région
Équilibreur de charge standard Front-end redondant de zone Comportement par défaut pour la référence SKU Standard
Application Gateway v2 Déploiement redondant interzone Nécessite une référence SKU Standard_v2 ou WAF_v2
passerelle VPN Actif-actif avec des références SKU redondantes de zone Utiliser des SKU avec le suffixe AZ (VpnGw1AZ, VpnGw2AZ, etc.)
Passerelle ExpressRoute Références SKU redondantes de zone Utiliser ErGw1AZ, ErGw2AZ ou ErGw3AZ
Azure Bastion Redondance de zone (préversion) SKU Basic, Standard et Premium
Passerelle NAT (StandardV2) Zone-redundant Référence SKU StandardV2 requise ; La référence SKU standard est zonale uniquement

Comment choisir une approche de routage du trafic inter-régions

Utilisez le tableau de décision suivant pour sélectionner le service approprié pour le routage du trafic entre les régions :

Vos besoins Service recommandé Fonctionnement
Basculement multirégion ou répartition de charge pour tout protocole (HTTP, TCP, UDP) Azure Traffic Manager Retourne la meilleure adresse IP de point de terminaison par le biais de la résolution DNS. Le client se connecte directement au point de terminaison. La rapidité du basculement dépend du TTL DNS (généralement de 30 à 300 secondes).
Équilibrage de charge HTTP/HTTPS global avec CDN, WAF et basculement rapide Azure Front Door - Service de passerelle réseau de Microsoft Termine les connexions aux points de présence en périphérie (PoPs). Route les requêtes vers le back-end sain le plus proche. Assure un basculement au niveau des connexions (en quelques secondes, sans dépendre du TTL DNS).
Trafic principal privé entre les régions (réplication, API internes) VNet Peering global Connecte des VNets entre différentes régions via le réseau principal de Microsoft. Le peering n’est pas transitif ; chaque relation de peering est explicite. Des frais de transfert de données par Go s’appliquent.
Connectivité de site à site locale via Azure ExpressRoute Global Reach Connecte deux circuits ExpressRoute afin que les sites locaux communiquent via le réseau principal de Microsoft sans passer par les routeurs de hub.

Tip

Combinez ces services. Par exemple, utilisez Front Door pour le trafic HTTP destiné aux utilisateurs et Global VNet Peering pour la réplication back-end entre les régions.

Guide pratique pour choisir une topologie de hub multirégion

Une fois que vous avez décidé d’étendre votre réseau dans plusieurs régions, choisissez un modèle hub pour la gestion de la connectivité entre régions :

Facteur Hub par région (traditionnel) Virtual WAN à plusieurs hubs
Connectivité inter-régions Le client configure le peering global de réseaux virtuels entre les hubs régionaux et gère les routes définies par l'utilisateur (UDR). Routage automatique entre les hubs : tous les hubs Virtual WAN sont interconnectés par défaut
Management Contrôle total du client sur le routage, les règles de pare-feu et le peering infrastructure hub gérée par Microsoft avec gestion basée sur des stratégies
Idéal pour Organisations qui ont besoin d’un contrôle précis du routage, de NVA personnalisées ou d’investissements existants dans un hub Organisations avec de nombreuses régions, sites de succursale 30+ ou préférence pour l’infrastructure managée
Transit mondial Nécessite une configuration explicite du peering et des UDR entre chaque paire de hubs Intégré : le trafic entre n’importe quels deux hubs est acheminé automatiquement
Scaling Ajouter des hubs et des peerings manuellement (AVNM peut automatiser) Ajouter des hubs via la configuration de Virtual WAN: les mises à jour du routage s’effectuent automatiquement
Modèle de coût Ressources de réseau virtuel hub (pare-feu, passerelle, peering) facturées séparément tarification unitaire Virtual WAN plus ressources connectées

Pour une comparaison détaillée de la topologie hub-and-spoke et de Virtual WAN dans une seule région, consultez la topologie hub-and-spoke et Virtual WAN.

Considérations relatives à la conception

Objectif de conception multirégion pour la migration lift-and-shift

  • Pour les charges de travail existantes qui ne peuvent pas s’étendre sur plusieurs zones ou régions, prévoyez une stratégie de reprise d’activité après sinistre plutôt qu’une architecture active-active : répliquez-les avec Azure Site Recovery vers une région de reprise.
  • Créez un hub dans la région de reprise qui reproduit le hub principal afin que le trafic basculé bénéficie des mêmes services partagés.
  • Utilisez Azure Traffic Manager ou le basculement DNS pour rediriger les utilisateurs lors d’une panne régionale.
  • Veillez à ce que l'espace d'adressage de la région de secours ne chevauche pas celui de la région principale afin d'éviter les conflits lors du basculement et de tout peering ultérieur.

Moderniser le focus de conception multirégion

  • Déployez les charges de travail destinées aux clients en mode actif-actif sur deux régions avec des références SKU redondantes de zone afin d'obtenir le plus haut niveau de résilience.
  • Attribuez des plages d'adresses qui ne se chevauchent pas aux régions principale et de secours afin que les spokes actifs-actifs puissent utiliser ultérieurement le peering global de réseaux virtuels sans renumérotation des adresses.
  • Choisissez votre couche de remise par type d’application : Azure Front Door pour les applications web et Traffic Manager pour les applications non web, répartis entre les points de terminaison publics régionaux.
  • Frontez les points de terminaison publics de chaque région avec le pare-feu hub (SNAT et DNAT) afin que le trafic entrant soit inspecté avant d’atteindre les back-ends.

Objectif de conception multirégion multicloud

  • Utilisez Azure Virtual WAN pour interconnecter plusieurs régions Azure, succursales et points de présence cloud grâce à un routage automatique de type any-to-any.
  • Planifiez des plages d’adresses agrégées et non chevauchantes d’une région et d’un cloud à l’autre afin que le routage de transit reste simple.
  • Terminez les connexions IPsec interclouds sur des hubs sécurisés régionaux et laissez Virtual WAN gérer le routage inter-hubs.
  • Distribuez l’entrée publique entre les régions à l’aide de Front Door ou Traffic Manager, et effectuez une inspection sur chaque pare-feu de hub régional.

Prerequisites

Avant de concevoir un réseau multirégion, assurez-vous d’avoir :

  • Déployé et testé une topologie monorégion. Commencez par hub-and-spoke ou Virtual WAN.
  • Exigences de haute disponibilité et de récupération d’urgence définies : RTO, objectif de point de récupération (RPO) et mandats de conformité.
  • Création d’un plan d’adresse IP qui ne se chevauche pas dans toutes les régions. Consultez la planification des adresses IP.
  • Identifié les charges de travail qui ont besoin de redondance régionale par rapport à la redondance de zone uniquement.

Modèles de déploiement actif-actif versus actif-passif

Votre modèle de déploiement multirégion détermine comment le trafic circule pendant l’opération normale et lors d’une défaillance régionale :

Active-active

Les deux régions servent simultanément le trafic. Un équilibreur de charge global, tel que Traffic Manager ou Front Door, distribue les requêtes entre les régions en fonction de la proximité, des performances ou du poids.

Quand utiliser active-active :

  • Votre application peut gérer les requêtes dans n’importe quelle région sans dépendances d’état spécifiques à la région.
  • Vous avez besoin du RTO le plus faible possible (le basculement est immédiat, car la région saine traite déjà le trafic).
  • Vous souhaitez utiliser la capacité dans les deux régions pendant l’opération normale (efficacité des coûts).

Considérations relatives à la mise en réseau :

  • Les deux régions doivent avoir une infrastructure réseau identique, notamment des pare-feu, des passerelles et des équilibreurs de charge.
  • La réplication des données entre les régions doit conserver les deux déploiements actuels.
  • Le TTL DNS et les intervalles des sondes d'intégrité déterminent la rapidité avec laquelle Traffic Manager redirige le trafic. Front Door offre un basculement au niveau de la connexion plus rapide.

Active-passive

Une région (primaire) gère tout le trafic. La région secondaire reste prête, mais ne traite pas les requêtes des utilisateurs tant qu'aucun basculement n'est déclenché.

Quand utiliser active-passive :

  • Votre application a des exigences strictes en matière de région d’écriture ou ne peut pas facilement répliquer l’état.
  • Les contraintes de coût empêchent l’exécution simultanée de la capacité totale dans deux régions.
  • Votre tolérance de RTO permet de disposer du temps nécessaire pour activer la région secondaire.

Considérations relatives à la mise en réseau :

  • L'infrastructure réseau de la région passive peut utiliser des niveaux inférieurs ou une capacité réduite jusqu'au basculement.
  • Le basculement automatique nécessite des sondes d'intégrité avec des seuils appropriés (afin d'éviter les basculements intempestifs).
  • Testez régulièrement le basculement. Les configurations réseau dans la région passive peuvent dériver si elles ne sont pas validées.
  • Conservez les tables de routage et les règles de groupe de sécurité réseau synchronisées entre les régions. Utilisez des modèles d’infrastructure en tant que code pour vous assurer que la région passive correspond à la posture de sécurité de la région primaire.
  • Préprovisionner des passerelles VPN ou ExpressRoute dans la région passive. L’approvisionnement de passerelle peut prendre 20 à 45 minutes. C’est trop lent pour la plupart des objectifs de RTO.

Choix entre la mise en réseau active-active et active-passive

Le choix entre la mise en réseau active et active-passive affecte le dimensionnement, le coût et la complexité opérationnelle du réseau :

Point à considérer Active-active Active-passive
Capacité réseau Capacité totale dans les deux régions Capacité réduite dans la région passive (montée en charge lors du basculement)
Approvisionnement de passerelle Toujours activé dans les deux régions Préapprovisionnée, mais pouvant utiliser des niveaux inférieurs
Synchronisation des données interrégions Trafic de réplication bidirectionnel continu Réplication asynchrone unidirectionnelle en veille
Règles de pare-feu Ensembles de règles identiques, appliqués activement Ensembles de règles identiques, mais ensemble passif rarement exercé
Adressage IP Les deux régions annoncent leurs routes à l'équilibreur de charge global. Seule la région principale annonce ses routes jusqu'au basculement.
Risque opérationnel En bas : les deux chemins sont sollicités en permanence Plus élevé : le chemin passif peut dériver ou avoir des configurations non testées

Réplication et latence des données

La réplication interrégion introduit une latence réseau qui affecte la conception de l’application. Azure régions situées dans la même zone géographique présentent généralement une latence aller-retour de 1 à 10 ms pour les paires proches (par exemple, USA Est vers USA Est 2) et 30 à 70 ms pour les paires distantes (par exemple, USA Est vers USA Ouest). Les paires de régions transatlantiques ou transpacifiques peuvent dépasser 100 ms.

Considérations clés relatives à la conception :

  • Topologie de réplication : Choisissez la réplication synchrone uniquement pour les paires de régions avec une faible latence (< 10 ms). Utilisez la réplication asynchrone pour les paires distantes afin d’éviter la dégradation des performances des applications.
  • Planification de la bande passante : estimez les besoins de débit pour la réplication et tenez compte des coûts de transfert de données par Go du peering global de réseaux virtuels. La réplication à volume élevé entre les régions distantes peut générer des frais de sortie significatifs.
  • Résolution des conflits : Les modèles actifs avec des écritures bidirectionnelles nécessitent des stratégies de résolution de conflit au niveau de l’application ou de la couche de base de données. Le réseau fournit une connectivité, mais les applications doivent gérer les conflits d’écriture.
  • Points de terminaison privés pour la réplication PaaS : Lors de la réplication de Azure SQL, Cosmos DB ou Stockage entre les régions, utilisez des points de terminaison privés dans chaque région pour conserver le trafic de réplication sur le Microsoft principal et éviter l’exposition à Internet public.

Considérations relatives aux coûts

La mise en réseau multirégion augmente les coûts par le biais d’une infrastructure en double et d’un transfert de données interrégion. Planifiez votre budget autour de ces principaux facteurs de coût :

  • Transfert de données entre régions : Le peering global de réseaux virtuels et le trafic inter-hub de Virtual WAN entraînent une facturation par Go pour les données traversant les frontières entre régions. Le trafic intrarégional entre des réseaux virtuels appairés dans la même région est gratuit lorsqu'il reste dans la même zone et facturé à un tarif inférieur lorsqu'il traverse des zones.
  • Équipements réseau dupliqués : Chaque région nécessite son propre pare-feu, son propre équilibreur de charge et ses propres instances de passerelle. Les déploiements actif-actif doublent ces coûts. Les déploiements actif-passif peuvent réduire les coûts en utilisant des niveaux inférieurs dans la région de secours et en montant en charge lors du basculement.
  • Frais d’équilibrage de charge globaux : Traffic Manager et Front Door sont facturés en fonction des requêtes DNS ou des requêtes traitées. Front Door facture en plus le transfert de données entre les PoP de périphérie et les serveurs back-end.
  • ExpressRoute et passerelle VPN : les conceptions multirégions nécessitent souvent des instances de passerelle dans chaque région. Les circuits ExpressRoute connectant plusieurs régions ajoutent des frais de port mensuels et des frais de données mesurés par Go.
  • Optimiser avec la localité du trafic : Concevoir des niveaux d’application pour réduire les appels interrégions. Conservez les réplicas en lecture dans la même région que les ressources de calcul afin de réduire la bande passante de réplication et la latence des requêtes sensibles.

Considérations relatives à la sécurité

Un réseau multirégion introduit des considérations de sécurité au-delà des déploiements à une seule région :

  • Le trafic reste sur le réseau principal de Microsoft. Tout le trafic interrégional transitant via le peering global de réseaux virtuels ou la connectivité inter-hub de Virtual WAN traverse le réseau backbone de Microsoft, et non l’Internet public.
  • Déployez des pare-feu redondants interzone dans chaque région. Chaque hub régional a besoin de sa propre instance de pare-feu pour l’inspection du trafic. Déployez des pare-feu dans des zones de disponibilité pour maintenir la sécurité pendant les défaillances de zone.
  • Front Door WAF offre une sécurité en périphérie. Lorsque vous utilisez Front Door, son Web Application Firewall intégré inspecte le trafic avant d’atteindre un déploiement régional. Cela fournit une première couche de défense au niveau de la périphérie du réseau.
  • Planifiez attentivement le basculement DNS. Le basculement de Traffic Manager dépend du TTL DNS. Des durées de vie (TTL) plus courtes permettent un basculement plus rapide, mais augmentent le volume des requêtes DNS. Front Door assure un basculement au niveau des connexions, sans dépendre de l'expiration du cache DNS des clients.
  • Le trafic ExpressRoute Global Reach reste privé. Le trafic entre les sites locaux connectés via Global Reach ne touche jamais l’Internet public. Le trafic reste sur le backbone Microsoft entre les circuits.
  • Sécuriser les canaux de réplication inter-régions. Le trafic de réplication des back-ends via le peering global de réseaux virtuels est privé par défaut, mais appliquez des groupes de sécurité réseau et le chiffrement pour les données sensibles en transit.

Si votre conception multirégion implique des scénarios spécifiques abordés ailleurs dans ce guide, consultez :

Learn more

Pour plus d’informations sur les services et concepts abordés dans cet article, consultez les ressources suivantes :

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Connectez-vous à votre réseau local : après la planification de la récupération d’urgence, établissez une connectivité VPN ou ExpressRoute locale.

Ensuite, dans votre parcours de modernisation :

Concevez vos modèles d’entrée Internet : déterminez comment le trafic client atteint vos applications dans vos régions principales et de sauvegarde.

Prochaine étape de votre parcours multi-cloud :

Configurez des tunnels chiffrés sur vos autres clouds : après la planification de la multirégion, configurez la connectivité VPN entre clouds.

  • Last updated on