Mise en réseau spoke-to-spoke
Les modèles de conception de réseau les plus courants dans Azure impliquent la création de topologies de réseau virtuel hub-and-spoke dans une ou plusieurs régions Azure, éventuellement connectées à des réseaux locaux par le biais d’Azure ExpressRoute ou de tunnels de réseau privé virtuel (VPN) site à site sur l’Internet public.
La plupart des guides de conception se concentrent sur le trafic des applications vers ces réseaux virtuels à partir d’utilisateurs dans des réseaux internes, locaux ou à partir d’Internet (ce que le secteur désigne généralement le trafic nord-sud, car il est souvent représenté par des lignes verticales dans les diagrammes de réseau). Cet article se concentre sur différents modèles disponibles pour le trafic est-ouest. Ce trafic correspond aux flux de communication entre les charges de travail déployées dans des réseaux virtuels Azure, dans une seule ou plusieurs régions.
Il est essentiel de vérifier que la conception du réseau répond aux exigences du trafic est-ouest pour garantir un certain niveau de performance, de scalabilité et de résilience aux applications qui s’exécutent dans Azure.
Cas d’usage potentiels
Le trafic spoke-to-spoke peut être important dans plusieurs scénarios :
- Les différentes couches d’une même application se trouvent dans des réseaux virtuels distincts. Par exemple, les serveurs de réseau de périmètre (également appelés serveurs DMZ) dans un réseau virtuel de périmètre communiquent avec les services d’application d’un réseau virtuel interne.
- Les charges de travail d’application dans différents environnements (développement, préproduction, production) doivent répliquer les données entre elles.
- Différents microservices ou applications doivent communiquer entre eux.
- Les bases de données doivent répliquer les données sur plusieurs régions pour garantir la continuité de l’activité en cas de sinistre.
- Les utilisateurs se trouvent dans des réseaux virtuels Azure. Par exemple, ils utilisent Azure Virtual Desktop.
Modèles et topologies pour la communication inter-spoke
Il existe deux topologies principales que vous pouvez utiliser dans les conceptions Azure qui traversent plusieurs réseaux virtuels : hub et spoke autogérés et Azure Virtual WAN. Dans un environnement Virtual WAN, Microsoft gère les réseaux virtuels hub et tout ce qu’il contient. Dans un environnement hub-and-spoke auto-géré, vous gérez le réseau virtuel hub.
Les topologies hub-and-spoke autonomes et virtual WAN sont des exemples d’architectures dans lesquelles les charges de travail s’exécutent dans des réseaux virtuels spoke et la connectivité à local sont centralisées dans un réseau virtuel hub. Tant de concepts expliqués dans cet article s’appliquent aux conceptions hub-and-spoke auto-managées et virtual WAN.
Il existe deux modèles principaux pour connecter des réseaux virtuels spoke entre eux :
- Les spokes sont directement connectés entre eux. Des appairages de réseaux virtuels ou des tunnels VPN sont créés entre les réseaux virtuels spoke pour établir une connectivité directe sans traverser le réseau virtuel hub.
- Les spokes communiquent sur une appliance réseau. Chaque réseau virtuel spoke est appairé à Virtual WAN ou à un réseau virtuel hub. Une appliance achemine le trafic de spoke en spoke. L’appliance peut être gérée par Microsoft (comme avec Virtual WAN) ou par vous-même.
Modèle 1 : spokes directement connectés entre eux
Les connexions directes entre spokes offrent généralement un meilleur niveau de débit, de latence et de scalabilité que les connexions qui passent par une appliance virtuelle réseau (NVA) sur un hub. L’envoi de trafic par le biais de NVA peut accroître la latence du trafic si les NVA se trouvent dans une zone de disponibilité différente et que le trafic envoyé via le hub doit franchir au moins deux appairages de réseaux virtuels. Plusieurs options s’offrent à vous pour connecter directement deux réseaux virtuels spoke : appairage de réseaux virtuels, Azure Virtual Network Manager et tunnels VPN.
Peering de réseaux virtuels. Les avantages des peerings de réseaux virtuels directs sur les spokes sont les suivants :
- Coût inférieur, car moins de tronçons d’appairage de réseaux virtuels sont nécessaires.
- Meilleur niveau de performance, car le trafic n’a pas besoin de traverser une appliance réseau qui introduit de la latence ou des goulots d’étranglement potentiels.
D’autres scénarios incluent la connectivité inter-locataires. Toutefois, vous devrez peut-être inspecter le trafic entre les réseaux virtuels spoke, ce qui peut nécessiter l’envoi du trafic par le biais d’appareils réseau centralisés dans le réseau virtuel hub.
Peering de sous-réseaux. Similaire au peering de réseaux virtuels, mais le peering de sous-réseaux permet une granularité plus précise en spécifiant quels sous-réseaux des deux côtés du peering sont autorisés à communiquer entre eux.
Azure Virtual Network Manager. Outre les avantages offerts par le peering de réseaux virtuels, Azure Virtual Network Manager fournit un service de gestion qui vous permet de gérer des environnements de réseau virtuel et de créer une connectivité à grande échelle. Azure Virtual Network Manager vous permet de créer trois types de topologies entre abonnements, aussi bien pour les réseaux virtuels existants que pour les nouveaux :
Hub-and-spoke avec des spokes qui ne sont pas connectés entre eux.
Hub-and-spoke avec des spokes directement connectés entre eux, sans aucun tronçon au milieu.
Groupe maillé de réseaux virtuels interconnectés.
Téléchargez tous les diagrammes Visio de cet article.
Lorsque vous créez une topologie hub-and-spoke avec Azure Virtual Network Manager dans lequel les spokes sont connectés les uns aux autres, la connectivité directe entre les réseaux virtuels spoke dans le même groupe de réseaux réseau est automatiquement créée bidirectionnellement. Azure Virtual Network Manager vous permet de configurer statiquement ou dynamiquement des réseaux virtuels spoke comme membres d’un groupe de réseaux spécifique, ce qui établit automatiquement la connectivité pour n’importe quel réseau virtuel.
Vous pouvez créer plusieurs groupes de réseaux pour isoler des clusters de réseaux virtuels spoke de la connectivité directe. Chaque groupe de réseaux fournit la même prise en charge régionale et multirégionale pour la connectivité spoke-to-spoke. Veillez à rester en dessous des limites maximales d’Azure Virtual Network Manager décrites dans la FAQ Azure Virtual Network Manager.
Tunnels VPN connectant des réseaux virtuels. Vous pouvez configurer des services VPN pour connecter directement des réseaux virtuels spoke à l’aide de passerelles VPN Microsoft ou d’appliances virtuelles RÉSEAU VPN tierces . L’avantage de cette option est que les réseaux virtuels spoke se connectent entre clouds commerciaux et souverains au sein du même fournisseur de cloud ou de fournisseurs de connectivité intercloud. Par ailleurs, si des NVA SD-WAN (réseau étendu à définition logicielle) sont présentes dans chaque réseau virtuel spoke, cette configuration peut faciliter l’utilisation du plan de contrôle et de l’ensemble de fonctionnalités du fournisseur tiers pour gérer la connectivité du réseau virtuel.
Cette option peut également vous aider à répondre aux exigences de conformité pour le chiffrement du trafic entre les réseaux virtuels dans un seul centre de données Azure qui ne sont pas déjà fournis par le chiffrement MACsec. Mais cette option présente ses propres défis en raison des limites de bande passante des tunnels IPsec (1,25 Gbits/s par tunnel) et des contraintes de conception d’avoir des passerelles de réseau virtuel dans les réseaux virtuels hub-and-spoke : si le réseau virtuel spoke a une passerelle de réseau virtuel, il ne peut pas être connecté à Virtual WAN ni utiliser la passerelle de réseau virtuel d’un hub pour se connecter aux réseaux locaux.
Modèle 1a : région unique
Quelle que soit la technologie que vous utilisez pour connecter les réseaux virtuels spoke entre eux, les topologies de réseau ressemblent à ceci pour une seule région :
Modèle 1b : Plusieurs régions
Les conceptions qui connectent tous les réseaux virtuels spoke entre eux peuvent également être étendues à plusieurs régions. Dans cette topologie, Azure Virtual Network Manager est encore plus critique pour réduire la surcharge administrative liée à la maintenance du grand nombre requis de connexions.
Notes
Quand vous connectez directement des réseaux virtuels spoke, dans une ou plusieurs régions, songez à connecter les réseaux virtuels spoke d’un même environnement. Par exemple, connectez un réseau virtuel de développement spoke à un autre réseau virtuel de développement spoke. Toutefois, évitez de connecter un réseau virtuel de développement spoke à un réseau virtuel de production spoke.
Quand vous connectez directement des réseaux virtuels spoke entre eux dans une topologie entièrement maillée, vous devez tenir compte du nombre potentiellement élevé d’appairages de réseaux virtuels nécessaires. Le diagramme suivant illustre ce problème. Dans ce scénario, il est vivement recommandé d’utiliser Azure Virtual Network Manager pour créer automatiquement des connexions de réseau virtuel.
Modèle 2 : Spokes communiquant sur une appliance réseau
Au lieu de connecter directement les réseaux virtuels spokes entre eux, vous pouvez utiliser des appliances réseau pour transférer le trafic entre les spokes. Les appliances réseau fournissent des services réseau supplémentaires tels que l’inspection approfondie des paquets et la segmentation ou le monitoring du trafic, mais elles peuvent introduire des goulots d’étranglement en termes de latence et de performances si elles ne sont pas correctement dimensionnées. Ces appliances sont généralement situées dans un réseau virtuel hub auquel les spokes se connectent. L’utilisation d’une appliance réseau pour transférer le trafic entre les spokes offre plusieurs options :
Routeur hub Virtual WAN. Complètement managé par Microsoft, Virtual WAN contient un routeur virtuel qui attire le trafic des spokes et l’achemine vers un autre réseau virtuel connecté à Virtual WAN ou vers des réseaux locaux par le biais d’ExpressRoute ou de tunnels VPN site à site ou point à site. Le routeur Virtual WAN effectue un scale-up et un scale-down automatiquement. Vous devez donc vous assurer que le volume de trafic entre les spokes reste dans les limites de Virtual WAN.
Pare-feu Azure.Le Pare-feu Azure est une appliance réseau gérée par Microsoft et peut être déployée dans des réseaux virtuels hub que vous gérez ou dans des hubs Virtual WAN. Il peut transférer des paquets IP, et il peut également les inspecter et appliquer des règles de segmentation du trafic définies dans des stratégies. Il fournit une mise à l’échelle automatique jusqu’aux limites du Pare-feu Azure afin qu’il ne devienne pas un goulot d’étranglement. Notez que les fonctionnalités multirégionales prêtes à l’emploi du Pare-feu Azure ne sont disponibles qu’avec Virtual WAN. Sans Virtual WAN, vous devez implémenter des routes définies par l’utilisateur pour établir une communication spoke-to-spoke interrégionale.
Appliances virtuelles réseau tierces. Si vous préférez utiliser l’appliance virtuelle réseau d’un partenaire Microsoft pour effectuer le routage et la segmentation du réseau, vous pouvez déployer des appliances virtuelles réseau dans une topologie hub-and-spoke ou Virtual WAN. Pour plus d’informations, consultez Déployer des appliances virtuelles réseau ou des appliances virtuelles virtuelles réseau dans un hub Virtual WAN. Vous devez vérifier que l’appliance virtuelle réseau prend en charge la bande passante générée par les communications inter-spokes.
Passerelle VPN Azure. Vous pouvez utiliser une passerelle VPN Azure comme type de tronçon suivant d’une route définie par l’utilisateur, mais Microsoft ne recommande pas d’utiliser des passerelles de réseau virtuel VPN pour acheminer le trafic spoke-to-spoke. Ces appareils sont conçus pour chiffrer le trafic vers des sites locaux ou des utilisateurs VPN. Par exemple, la bande passante pour le trafic entre spokes acheminé par une passerelle VPN n’est pas garantie.
ExpressRoute. Dans certaines configurations, une passerelle ExpressRoute peut publier des routes qui attirent la communication spoke-to-spoke. Le trafic est alors envoyé au routeur de périphérie Microsoft où il est acheminé vers le spoke de destination. Ce modèle est parfois appelé épinglage ExpressRoute et doit être activé explicitement en suivant les instructions de l’instruction Activer ou désactiver le réseau virtuel vers le réseau virtuel ou le réseau virtuel vers le trafic Virtual WAN via ExpressRoute. Microsoft décourage fortement ce scénario en raison de la latence introduite par les allers-retours du trafic vers la périphérie du réseau principal de Microsoft. En plus de cela, Microsoft ne recommande pas cette approche, en raison du point de défaillance unique et du grand rayon d’impact. Ce scénario présente également plusieurs problèmes liés à la pression supplémentaire exercée sur l’infrastructure ExpressRoute (passerelle et routeurs physiques). Cette pression supplémentaire peut provoquer des pertes de paquets.
Dans les conceptions de réseau hub-and-spoke autonomes avec des appliances virtuelles réseau centralisées, l’appliance est généralement placée dans le hub. Les appairages de réseaux virtuels entre réseaux virtuels hub-and-spoke doivent être créés manuellement ou automatiquement avec Azure Virtual Network Manager :
Peerings de réseaux virtuels manuels ou peerings de sous-réseaux. Cette approche convient si vous avez un petit nombre de réseaux virtuels spoke, mais elle génère une surcharge de gestion à grande échelle.
Azure Virtual Network Manager. Comme indiqué précédemment, Azure Virtual Network Manager fournit des fonctionnalités pour gérer les environnements de réseau virtuel et les peerings à grande échelle. Les configurations d’appairage entre les réseaux virtuels hub-and-spoke sont automatiquement configurées de manière bidirectionnelle pour les groupes de réseaux.
Azure Virtual Network Manager permet d’ajouter statiquement ou dynamiquement des appartenances de réseau virtuel spoke à un groupe de réseau spécifique, ce qui crée automatiquement la connexion de peering pour les nouveaux membres. Les réseaux virtuels spoke dans les groupes de réseaux peuvent utiliser le VPN hub ou les passerelles ExpressRoute pour la connectivité. Veillez à rester en dessous des limites maximales pour Azure Virtual Network Manager.
Modèle 2a : région unique
Le diagramme suivant montre une topologie hub-and-spoke monorégion qui envoie le trafic entre les spokes par le biais d’un pare-feu Azure déployé dans le réseau virtuel hub. Le trafic est transféré à l’appliance centralisée dans le hub par le biais des routes définies par l’utilisateur qui sont appliquées aux sous-réseaux spoke.
Dans certaines circonstances, il peut être avantageux de séparer les appliances virtuelles réseau qui gèrent le trafic spoke-to-spoke et Internet à des fins de scalabilité. Pour accomplir cette séparation, vous pouvez :
- Réglage des tables de routage dans les spokes pour envoyer des adresses privées (celles qui ont un itinéraire pour les préfixes RFC 1918) à une appliance virtuelle réseau responsable d’Azure-à-Azure et d’Azure -to-on-trafic local (également appelé trafic est-ouest).
- Régler le trafic Internet (avec la route 0.0.0.0/0) pour l’envoyer vers une deuxième NVA. Cette appliance virtuelle réseau est responsable du trafic Azure-à-Internet (également appelé trafic nord-sud).
Le diagramme suivant montre cette configuration :
Notes
Le pare-feu Azure exige qu’une seule ressource Pare-feu Azure puisse être déployée dans un réseau virtuel. Un réseau virtuel hub distinct est donc requis pour des ressources Pare-feu Azure supplémentaires. Pour les scénarios NVA, vous pouvez utiliser un réseau virtuel hub unique pour des déploiements NVA supplémentaires.
Modèle 2b : Plusieurs régions
Vous pouvez étendre la même configuration à plusieurs régions. Par exemple, dans une conception hub-and-spoke auto-managée qui utilise le Pare-feu Azure, vous devez appliquer des tables de routage supplémentaires aux sous-réseaux du Pare-feu Azure dans chaque hub pour les spokes dans la région distante. Cette configuration garantit que le trafic interrégional peut être transféré entre les pare-feu Azure dans chaque réseau virtuel hub. Le trafic interrégional entre les réseaux virtuels spoke traverse ensuite les deux pare-feux Azure. Pour plus d’informations, consultez Pare-feu Azure pour acheminer une topologie multi hub-and-spoke :
La variante de conception avec des pare-feux Azure ou des appliances virtuelles réseau distincts pour le trafic nord-sud et est-ouest est également possible dans une topologie hub-and-spoke multirégionale :
Notes
Le pare-feu Azure exige qu’une seule ressource Pare-feu Azure puisse être déployée dans un réseau virtuel. Un réseau virtuel hub distinct est donc requis pour des ressources Pare-feu Azure supplémentaires. Pour les scénarios NVA, vous pouvez utiliser un réseau virtuel hub unique pour des déploiements NVA supplémentaires.
Virtual WAN crée une topologie similaire et se charge de la complexité du routage. Il le fait à la fois dans les hubs (gérés par Microsoft) et dans les spokes (où les routes peuvent être injectées sans être définies manuellement dans des tables de routage). Il ne reste plus à l’administrateur réseau qu’à connecter les réseaux virtuels spoke à un hub Virtual WAN sans se soucier du transfert du trafic entre les régions.
Modèles mixtes
Certaines situations peuvent nécessiter une approche hybride qui combine les deux modèles décrits précédemment. Dans ce cas, le trafic entre certains spokes doit passer par des connexions directes, mais le reste des spokes communique par le biais d’une appliance réseau centrale. Par exemple, dans un environnement WAN virtuel, vous pouvez connecter directement deux spokes spécifiques qui nécessitent une bande passante élevée et une faible latence. Un autre scénario implique des réseaux virtuels spoke qui font partie d’un environnement unique. Par exemple, vous pouvez autoriser un réseau virtuel de développement spoke à se connecter directement à un autre réseau virtuel de développement spoke, mais forcer les charges de travail de développement et de production à communiquer à travers l’appliance centrale.
Un autre modèle courant consiste à connecter des spokes dans une région via des peerings de réseaux virtuels directs ou des groupes connectés Azure Virtual Network Manager, mais en autorisant le trafic interrégional vers des appliances virtuelles réseau croisées. L’objectif principal de ce modèle est de réduire le nombre d’appairages de réseaux virtuels dans l’architecture. Toutefois, par rapport au premier modèle (connectivité directe entre les spokes), celui-ci a l’inconvénient d’introduire davantage de tronçons d’appairage de réseaux virtuels pour le trafic interrégional. Ces tronçons augmentent les coûts en raison des multiples appairages de réseaux virtuels qui sont traversés. Un autre inconvénient est la charge supplémentaire pour les NVA du hub qui font face à tout le trafic interrégional.
Les mêmes conceptions s’appliquent à Virtual WAN. Toutefois, notez que la connectivité directe entre les réseaux virtuels spoke doit être configurée manuellement entre les réseaux virtuels et non par le biais de la ressource Virtual WAN. Azure Virtual Network Manager ne prend pas actuellement en charge les architectures basées sur Virtual WAN. Par exemple :
Notes
Pour les approches mixtes, il est important de comprendre que la connectivité directe via le peering de réseaux virtuels propage les itinéraires système pour ses réseaux virtuels qui sont souvent plus spécifiques que les itinéraires personnalisés configurés via des tables de routage. Par conséquent, le chemin d’accès de peering de réseau virtuel est préféré aux itinéraires personnalisés qui suivent la sélection de routage de correspondance de préfixe la plus longue.
Toutefois, dans des scénarios moins courants, s’il existe à la fois une route système et une route personnalisée définie par l’utilisateur avec le même préfixe d’adresse, la route définie par l’utilisateur a priorité sur les routes système (créées automatiquement par l’appairage de réseaux virtuels). De par ce comportement, le trafic de réseau virtuel spoke-to-spoke traverse le réseau virtuel hub, même si l’appairage offre une connexion directe.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
- Jay Li | Chef de produit senior
- Jose Moreno | Ingénieur client principal
- Alejandra Alexandras | Ingénieur client d’infrastructure Azure senior
Autres contributeurs :
- Mick Alberts | Rédacteur technique
- Mohamed Hassan | Responsable principal du PM
- Andrea Michael | Gestionnaire de programmes
- Yasukuni Morishima | Ingénieur client II
- Jithin PP | Ingénieur client
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Framework d’adoption du cloud : topologie de réseau de zone d’atterrissage et connectivité
- Peering de réseaux virtuels
- Azure Virtual Network Manager
- Virtual WAN
- Pare-feu Azure
- Sécuriser la connectivité réseau sur Azure
- Présentation des réseaux virtuels Azure