Considérations relatives au réseau pour des déploiements Azure VMware Solution à deux régions

  • Article

Cet article décrit comment configurer la connectivité réseau lorsque des clouds privés Azure VMware Solution sont déployés dans deux régions Azure à des fins de résilience aux sinistres. En cas de pannes régionales partielles ou complètes, la topologie de réseau décrite dans cet article permet aux composants survivants (clouds privés, ressources natives Azure et sites locaux) de conserver la connectivité entre eux et avec Internet.

Scénario à deux régions

Cet article se concentre sur un scénario classique à deux régions, illustré dans la figure 1 suivante :

  • Un réseau en étoile (hub-and-spoke) Azure existe dans chaque région.
  • Une configuration résiliente aux sinistres pour ExpressRoute (deux circuits dans deux emplacements de peering différents, chaque circuit étant connecté à des réseaux virtuels hubs dans les deux régions) a été déployée. Les conseils fournis dans les sections suivantes restent les mêmes en cas de configuration de la connectivité VPN de secours.
  • Un cloud privé Azure VMware Solution a été déployé dans chaque région.

Diagramme de la figure 1, qui montre le scénario à deux régions couvert dans cet article.

Notes

Dans le scénario de référence de la figure 1, les deux réseaux virtuels hubs régionaux sont connectés via le peering VNet global. Bien que cela ne soit pas strictement nécessaire, car le trafic entre les réseaux virtuels Azure dans les deux régions peut être acheminé via des connexions ExpressRoute, nous vous recommandons vivement cette configuration. VNet Peering réduit la latence, puis optimise le débit, car il élimine la nécessité de trafic en épingle à cheveux via les routeurs de périphérie de rencontre ExpressRoute.

Modèles de communication à deux régions

Les sections suivantes décrivent la configuration réseau Azure VMware Solution nécessaire pour activer, dans le scénario de référence à deux régions, les modèles de communication suivants :

Connectivité inter-régions Azure VMware Solution

Lorsque plusieurs clouds privés Azure VMware Solution existent, la connectivité de couche 3 entre eux est souvent une exigence pour des tâches telles que la prise en charge de la réplication des données.

Azure VMware Solution prend en charge la connectivité directe entre deux clouds privés déployés dans différentes régions Azure. Les clouds privés se connectent au réseau Azure dans leur propre région via des circuits ExpressRoute, gérés par la plateforme et terminés sur des emplacements de rencontre ExpressRoute dédiés. Tout au long de cet article, ces circuits sont appelés circuits managés Azure VMware Solution. Les circuits managés Azure VMware Solution ne doivent pas être confondus avec les circuits normaux que les clients déploient pour connecter leurs sites locaux à Azure. Les circuits normaux déployés par les clients sont des circuits managés par le client (veuillez consulter la figure 2).

La connectivité directe entre les clouds privés est basée sur les connexions ExpressRoute Global Reach entre les circuits managés Azure VMware Solution, comme le montre la ligne verte dans le diagramme suivant. Si vous souhaitez en savoir plus, veuillez consulter le document Tutoriel : Appairer des environnements locaux à Azure VMware Solution. L’article décrit la procédure de connexion d’un circuit managé Azure VMware Solution à un circuit managé par le client. La même procédure s’applique à la connexion de deux circuits managés Azure VMware Solution.

Diagramme de la figure 2, qui montre des clouds privés dans différentes régions connectées par une connexion Global Reach entre des circuits ExpressRoute managés.

Connectivité hybride

L’option recommandée pour connecter les clouds privés Azure VMware Solution à des sites locaux est ExpressRoute Global Reach. Des connexions Global Reach peuvent être établies entre des circuits ExpressRoute managés par le client et des circuits ExpressRoute managés par Azure VMware Solution. Les connexions Global Reach ne sont pas transitives. Par conséquent, un maillage complet (chaque circuit managé Azure VMware Solution connecté à chaque circuit managé par le client) est nécessaire pour la résilience aux sinistres, comme illustré dans la figure 3 suivante (représentée par des lignes orange).

Diagramme de la figure 3, qui montre les connexions Global Reach connectant les circuits ExpressRoute managés par le client et les circuits ExpressRoute VMware Solution.

Connectivité de réseau virtuel Azure

Le Réseau virtuel Azure peut être connecté à des clouds privés Azure VMware Solution via des connexions entre des passerelles ExpressRoute et des circuits managés Azure VMware Solution. Cette connexion est faite pour correspondre exactement à la manière de connecter le Réseau virtuel Azure à des sites locaux via des circuits ExpressRoute gérés par le client. Si vous souhaitez obtenir des instructions de configuration, veuillez consulter la rubrique Se connecter manuellement au cloud privé.

Dans les scénarios à deux régions, nous recommandons un maillage complet pour les connexions ExpressRoute entre les deux réseaux virtuels hubs régionaux et les clouds privés, comme illustré dans la figure 4 (représentée par des lignes jaunes).

Diagramme de la figure 4, qui montre que les ressources natives Azure dans chaque région bénéficient d’une connectivité L3 directe vers les clouds privés Azure VMware Solution.

Connectivité Internet

Lors du déploiement de clouds privés Azure VMware Solution dans plusieurs régions, nous recommandons des options natives pour la connectivité Internet (traduction d’adresses réseau de source managée (SNAT) ou adresses IP publiques jusqu’à NSX-T). Les deux options peuvent être configurées via le Portail Azure (ou via PowerShell, l’interface CLI ou les modèles ARM/Bicep) au moment du déploiement, comme illustré dans la figure 5 suivante.

Diagramme de la figure 5, qui montre les options natives Azure VMware Solution pour la connectivité Internet dans le Portail Azure.

Les deux options mises en évidence dans la figure 5 fournissent à chaque cloud privé un breakout Internet directe dans sa propre région. Les considérations suivantes doivent guider la décision quant à l’option de connectivité Internet native à utiliser :

  • La traduction SNAT managée doit être utilisée dans les scénarios avec des exigences de base et sortantes uniquement (faibles volumes de connexions sortantes et nul besoin de contrôle granulaire sur le pool SNAT).
  • Nous recommandons les adresses IP publiques jusqu’à la périphérie NSX-T dans les scénarios avec de grands volumes de connexions sortantes ou lorsque vous avez besoin d’un contrôle granulaire sur les adresses IP NAT. Par exemple, les machines virtuelles Azure VMware Solution qui utilisent SNAT derrière telle ou telle adresse IP. Les adresses IP publiques jusqu’à la périphérie NSX-T prennent également en charge la connectivité entrante via DNAT. La connectivité Internet entrante n’est pas abordée dans cet article.

La modification de la configuration de connectivité Internet d’un cloud privé après le déploiement initial est possible. Toutefois, le cloud privé perd la connectivité à Internet, au réseau virtuel Azure et aux sites locaux pendant la mise à jour de la configuration. Lorsque l’une des options de connectivité Internet native de la figure 5 précédente est utilisée, aucune configuration supplémentaire n’est nécessaire dans les scénarios à deux régions (la topologie reste identique à celle illustrée dans la figure 4). Si vous souhaitez en savoir plus sur la connectivité Internet pour Azure VMware Solution, veuillez consulter la rubrique Considérations relatives à la conception de la connectivité Internet.

Breakout Internet natif Azure

Si une périphérie Internet sécurisée a été créée dans le Réseau virtuel Azure avant l’adoption d’Azure VMware Solution, vous devrez sans doute l’utiliser pour l’accès à Internet pour les clouds privés Azure VMware Solution. L’utilisation d’une périphérie Internet sécurisée de cette façon est nécessaire pour la gestion centralisée des stratégies de sécurité réseau, l’optimisation des coûts, et bien plus encore. Les périphéries de sécurité Internet dans le proxy Azure peuvent être implémentées à l’aide du Pare-feu Azure ou d’appliances virtuelles réseau proxy et de pare-feu tierces disponibles sur la Place de marché Azure.

Vous pouvez attirer le trafic internet émis par les machines virtuelles Azure VMware Solution vers un réseau virtuel Azure en créant une route par défaut et en l’annonçant, via le protocole BGP (Over Border Gateway Protocol), vers le circuit ExpressRoute managé du cloud privé. Vous pouvez configurer les deux options via le Portail Azure (ou via PowerShell, l’interface CLI ou les modèles ARM/Bicep) au moment du déploiement, comme illustré dans la figure 6 suivante. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Désactiver l’accès à Internet ou activer un itinéraire par défaut.

Diagramme de la figure 6, qui montre la configuration Azure VMware Solution pour activer la connectivité Internet via des périphéries Internet dans le Réseau virtuel Azure.

Les appliances virtuelles réseau de périphérie Internet peuvent créer l’itinéraire par défaut si elles prennent en charge BGP. Si ce n’est pas le cas, vous devez déployer d’autres appliances virtuelles réseau compatibles avec BGP. Si vous souhaitez en savoir plus sur l’implémentation de la connectivité sortante Internet pour Azure VMware Solution dans une seule région, veuillez consulter la rubrique Implémentation de la connectivité Internet pour Azure VMware Solution avec des appliances virtuelles réseau Azure. Dans le scénario à deux régions décrit dans cet article, vous devez appliquer la même configuration aux deux régions.

La considération clé dans les scénarios à deux régions est que l’itinéraire par défaut provenant de chaque région doit être propagé via ExpressRoute uniquement vers le cloud privé Azure VMware Solution de la même région. Cette propagation permet aux charges de travail Azure VMware Solution d’accéder à Internet via un breakout local (dans la région). Toutefois, si vous utilisez la topologie illustrée dans la figure 4, chaque cloud privé Azure VMware Solution reçoit également un itinéraire par défaut à coût égal depuis la région distante via les connexions ExpressRoute inter-régions. Les lignes en pointillés rouges représentent cette propagation d’itinéraire par défaut inter-régions indésirable dans la figure 7.

Diagramme de la figure 7, qui montre que les connexions inter-régions entre les passerelles ExpressRoute et les circuits ExpressRoute managées par VMware Solution doivent être supprimées.

La suppression des connexions ExpressRoute inter-régions Azure VMware Solution permet d’atteindre l’objectif d’injecter, dans chaque cloud privé, un itinéraire par défaut pour transférer les connexions Internet à la périphérie Internet Azure dans la région locale.

Il convient de noter que si les connexions ExpressRoute inter-régions (lignes en pointillés rouges dans la figure 7) sont supprimées, la propagation inter-régions de l’itinéraire par défaut se produit toujours via Global Reach. Toutefois, les itinéraires propagés via Global Reach ont un chemin d’accès AS plus long que les itinéraires d’origine locale et sont ignorés par le processus de sélection d’itinéraire BGP.

La propagation inter-régions via Global Reach d’un itinéraire par défaut moins recommandé offre une résilience contre les pannes de la périphérie Internet locale. Si la périphérie Internet d’une région est hors connexion, elle cesse de créer l’itinéraire par défaut. Dans ce cas, l’itinéraire par défaut moins recommandé appris depuis la région distante s’installe dans le cloud privé Azure VMware Solution, de sorte que le trafic Internet est acheminé via le breakout de la région distante.

La topologie recommandée pour les déploiements à deux régions avec des breakouts Internet dans les réseaux virtuels Azure est illustrée dans la figure 8 suivante.

Diagramme de la figure 8, qui montre la topologie recommandée pour les déploiements à deux régions avec un accès sortant Internet via des périphéries Internet.

Lorsque vous créez des itinéraires par défaut dans Azure, vous devez prendre des précautions particulières pour éviter la propagation vers des sites locaux, sauf s’il est nécessaire de fournir un accès Internet aux sites locaux via une périphérie Internet dans Azure. Les appareils exploités par le client qui mettent fin aux circuits ExpressRoute managés par le client doivent être configurés pour filtrer les itinéraires par défaut reçus d’Azure, comme illustré dans la figure 9. Cette configuration est nécessaire pour éviter de perturber l’accès à Internet pour les sites locaux.

Diagramme de la figure 9, qui montre que les haut-parleurs BGP qui terminent les circuits ExpressRoute managés par le client filtre les itinéraires par défaut de l’appliance virtuelle réseau Azure.

Étapes suivantes