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 portent sur le trafic d’applications vers ces réseaux virtuels en provenance d’utilisateurs dans des réseaux internes locaux ou de l’Internet (généralement appelé trafic nord-sud dans l’industrie, car il est souvent représenté par des lignes verticales dans les diagrammes de réseau). Cet article examine les 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 dans 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 couvrant plusieurs réseaux virtuels : hub-and-spoke traditionnel et Azure Virtual WAN. Dans un environnement Virtual WAN, Microsoft gère le réseau virtuel hub et tout ce qu’il contient. Dans un environnement hub-and-spoke traditionnel, c’est vous qui gérez le réseau virtuel hub.

Les topologies Virtual WAN et hub-and-spoke sont deux exemples d’architectures où les charges de travail s’exécutent dans des réseaux virtuels spoke et où la connectivité au réseau local est centralisée dans un réseau virtuel hub. Bon nombre des concepts traités dans cet article s’appliquent à la fois aux conceptions hub-and-spoke 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.

• Appairage de réseaux virtuels. Les appairages directs de réseaux virtuels présentent les avantages suivants par rapport aux spokes :

  • 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.

• Azure Virtual Network Manager. Outre les avantages offerts par l’appairage 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.

    Quand vous créez une topologie hub-and-spoke avec Azure Virtual Network Manager dans laquelle les spokes sont connectés entre eux, une connectivité directe entre les réseaux virtuels spoke du même groupe de réseaux est automatiquement créée de manière bidirectionnelle. 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 pour Azure Virtual Network Manager décrites dans le FAQ sur 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 en utilisant des passerelles VPN Microsoft ou des NVA 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é en matière de chiffrement du trafic entre réseaux virtuels dans un même centre de données Azure qui ne sont pas déjà satisfaites 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 1 : Une seule région

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 1 : 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.

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 effectuant automatiquement un scale-up et un scale-down, vous devez vérifier 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 qui peut être déployée dans les 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 pour ne pas devenir 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 NVA à haute disponibilité ou NVA 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. Elles sont conçues 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. 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 réseau hub-and-spoke avec des NVA 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 :

• Appairages de réseaux virtuels manuels. 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 offre des fonctionnalités permettant de gérer les environnements et les appairages de réseaux virtuels à 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 réseaux virtuels spoke comme membres d’un groupe de réseaux spécifique, ce qui crée automatiquement la connexion d’appairage pour les nouveaux membres. Les réseaux virtuels spoke appartenant à des groupes de réseaux peuvent utiliser les passerelles ExpressRoute ou VPN du hub pour la connectivité. Veillez à rester en dessous des limites maximales pour Azure Virtual Network Manager.

Modèle 2 : Une seule région

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égler les tables de routage dans les spokes de manière à envoyer les adresses privées (celles qui ont une route pour les préfixes RFC 1918) à une NVA responsable du trafic Azure vers Azure et Azure vers réseau 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 NVA est responsable du trafic Azure vers Internet (également appelé trafic nord-sud).

Le diagramme suivant montre cette configuration :

Modèle 2 : Plusieurs régions

Vous pouvez étendre la même configuration à plusieurs régions. Par exemple, dans une conception hub-and-spoke qui utilise le Pare-feu Azure, vous devez appliquer des tables de routage supplémentaires aux sous-réseaux Pare-feu Azure dans chaque hub pour les spokes de 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 Utiliser le 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 :

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 hybrides

De nombreuses situations nécessitent une approche hybride combinant les deux schémas décrits précédemment. Dans cette approche, le trafic entre certains spokes doit passer par des connexions directes, mais le reste des spokes communique au moyen 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 par le biais d’appairages directs de réseaux virtuels ou de groupes connectés Azure Virtual Network Manager, mais en autorisant le trafic interrégional à traverser les NVA. 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 :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

• Jay Li | Responsable de produit senior
• Jose Moreno | Ingénieur client principal
• Alejandra Palacios | Ingénieur client de l’infrastructure Azure senior

Autres contributeurs :

• Mick Alberts | Rédacteur technique
• Mohamed Hassan | Responsable de programme principal
• Andrea Michael | Responsable de programme
• Yasukuni Morishima | Ingénieur client II
• Jithin PP | Ingénieur client

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Cloud Adoption Framework : Topologie de réseau et connectivité pour les zones d’atterrissage
• Peering de réseau virtuel
• Azure Virtual Network Manager
• Virtual WAN
• Pare-feu Azure
• Sécuriser la connectivité réseau sur Azure
• Introduction aux réseaux virtuels Azure

Ressources associées

• Topologie réseau hub-and-spoke dans Azure
• Topologie réseau hub-and-spoke avec Azure Virtual WAN
• Topologie de mise en réseau Azure classique