Considérations relatives au réseau pour les déploiements à double région d’Azure VMware Solution
Cet article explique 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 des sinistres. S’il existe des pannes régionales partielles ou complètes, la topologie de réseau de cet article permet aux composants survivants (clouds privés, ressources natives Azure et sites locaux) de maintenir la connectivité entre eux et avec Internet.
Scénario de région double
Cet article se concentre sur un scénario à double région classique, illustré dans la figure 1 suivante :
- Un réseau hub-and-spoke Azure existe dans chaque région.
- Une configuration résiliente aux sinistres pour Azure ExpressRoute (deux circuits dans deux emplacements de peering différents, chaque circuit connecté aux réseaux virtuels hub dans les deux régions) a été déployé. Les instructions fournies dans les sections suivantes restent les mêmes si la connectivité VPN de secours est configurée.
- Un cloud privé Azure VMware Solution a été déployé dans chaque région.
Figure 1 : un scénario à deux régions qui montre comment le peering global de réseaux virtuels connecte deux réseaux virtuels dans différentes régions
Remarque
Dans le scénario de référence de la figure 1, les deux réseaux virtuels de hub régional sont connectés via le peering de VNet global. Bien qu’il 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 à double région, les modèles de communication suivants :
- Azure VMware Solution à Azure VMware Solution (abordé dans la section connectivité inter-régions Azure VMware Solution) ;
- Azure VMware Solution vers des sites locaux connectés via ExpressRoute (abordé dans la section de connectivité hybride) ;
- Azure VMware Solution vers un réseau virtuel Azure (décrit dans la section connectivité de réseau virtuel Azure) ;
- Azure VMware Solution à Internet (abordé dans la section Connectivité Internet).
Connectivité interrégionale de Azure VMware Solution
Quand plusieurs clouds privés Azure VMware Solution existent, la connectivité de couche 3 est souvent requise pour les 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 région respective via des circuits ExpressRoute, administrés par la plateforme et terminés sur des points 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 que les clients déploient sont circuits gérés par le client (voir la figure 2).
La connectivité directe entre les clouds privés est basée sur les connexions ExpressRoute Global Reach entre les circuits gérés via Azure VMware Solution, comme le montre la ligne verte dans le diagramme suivant. Pour plus d’informations, consultez Tutoriel : Homologuer des environnements locaux vers Azure VMware Solution. L’article décrit la procédure de connexion d’un circuit managé Azure VMware Solution à un circuit géré par le client. La même procédure s’applique à la connexion de deux circuits managés Azure VMware Solution.
Figure 2 : Ce scénario de référence montre les clouds privés Azure VMware Solution dans différentes régions. Une connexion Global Reach connecte directement les clouds entre leurs circuits ExpressRoute managés.
Connectivité hybride
L’option recommandée pour connecter des clouds privés Azure VMware Solution à des sites locaux est ExpressRoute Global Reach. Les connexions Global Reach peuvent être établies entre les circuits ExpressRoute gérés par le client et les circuits ExpressRoute géré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 géré 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 oranges).
Figure 3 : Ce scénario de référence montre les connexions Global Reach entre les circuits ExpressRoute gérés par le client et les circuits ExpressRoute Azure 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 exactement la même façon que le réseau virtuel Azure peut être connecté à des sites locaux via des circuits ExpressRoute gérés par le client. Consultez Se connecter au cloud privé manuellement pour obtenir des instructions de configuration.
Dans les scénarios à deux régions, nous vous recommandons d’établir un maillage complet pour les connexions ExpressRoute entre les deux clouds virtuels du hub régional et des clouds privés, comme illustré dans la figure 4 (représentée par des lignes jaunes).
Figure 4 : Ce scénario de référence montre les ressources natives Azure dans chaque région qui disposent d’une connectivité L3 directe vers des clouds privés Azure VMware Solution.
Connectivité Internet
Lors du déploiement de clouds privés Azure VMware Solution dans plusieurs régions, nous vous recommandons d’utiliser des options natives pour la connectivité Internet (traduction d’adresses réseau source gérées) ou les adresses IP publiques jusqu’à NSX-T. L’une ou l’autre option peut être configurée via le portail Azure (ou via des modèles PowerShell, CLI ou ARM/Bicep) au moment du déploiement, comme illustré dans la figure 5 suivante.
Figure 5 : Cette capture d’écran met en évidence les options natives d’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 direct dans sa propre région. Les considérations suivantes doivent informer la décision quant à l’option de connectivité Internet native à utiliser :
- Le SNAT managé doit être utilisé dans des scénarios avec des exigences de base et sortantes uniquement (de faibles volumes de connexions sortantes et n’ont pas besoin d’un contrôle granulaire sur le pool SNAT).
- Les adresses IP publiques jusqu’à la périphérie NSX-T doivent être préférées 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 utilisent SNAT derrière quelles adresses 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.
Il est possible de modifier la configuration de connectivité Internet d’un cloud privé après le déploiement initial. 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 natives de la figure 5 précédente n’est utilisée, aucune configuration supplémentaire n’est nécessaire dans les scénarios à double région (la topologie reste la même que celle illustrée dans la figure 4). Pour plus d’informations sur la connectivité Internet pour Azure VMware Solution, consultez 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 un réseau virtuel Azure avant l’adoption d’Azure VMware Solution, il peut être nécessaire de 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, etc. 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.
Le trafic lié à Internet émis par les machines virtuelles Azure VMware Solution peut être attiré par un réseau virtuel Azure en provenance d’un itinéraire par défaut et en l’annonçant, via le protocole BGP (Border Gateway Protocol), vers le circuit ExpressRoute managé du cloud privé. Cette option de connectivité Internet peut être configurée via le portail Azure (ou via des modèles PowerShell, CLI ou ARM/Bicep) au moment du déploiement, comme illustré dans la figure 6 suivante. Pour plus d’informations, consultez Désactiver l’accès à Internet ou activer un itinéraire par défaut.
Figure 6 : Cette capture d’écran met en évidence la configuration d’Azure VMware Solution que vous devez sélectionner pour activer la connectivité Internet via des périphéries Internet dans le réseau virtuel.
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. Pour plus d’informations sur l’implémentation de la connectivité sortante Internet pour Azure VMware Solution dans une seule région, consultez Implémentation de la connectivité Internet pour Azure VMware Solution avec des appliances virtuelles Azure. Dans le scénario à double région décrit dans cet article, la même configuration doit être appliquée aux deux régions.
La principale considération dans les scénarios à double région est que l’itinéraire par défaut provient de chaque région doit être propagé sur ExpressRoute uniquement vers le cloud privé Azure VMware Solution dans 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 indiquée dans la figure 4, chaque cloud privé Azure VMware Solution reçoit également un itinéraire par défaut à coût égal de la région distante via les connexions ExpressRoute inter-régions. Les lignes en pointillés rouges représentent cette propagation d’itinéraires interrégions indésirables par défaut dans la figure 7.
Figure 7 : Ce scénario de référence montre les connexions interrégions entre les passerelles ExpressRoute et les circuits ExpressRoute gérés par Azure VMware Solution que vous devez supprimer pour empêcher la propagation interrégion de l’itinéraire par défaut.
La suppression des connexions ExpressRoute inter-régions Azure VMware Solution permet d’injecter, dans chaque cloud privé, un itinéraire par défaut pour transférer des connexions liées à Internet vers 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 interrégion de l’itinéraire par défaut se produit toujours sur Global Reach. Toutefois, les itinéraires propagés sur Global Reach ont un chemin AS plus long que ceux provenant localement et sont ignorés par le processus de sélection de routage BGP.
La propagation interrégion sur Global Reach d’un itinéraire par défaut moins préféré fournit 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 diffuser la route par défaut. Dans ce cas, l’itinéraire par défaut moins préféré appris à partir de la région distante s’installe dans le cloud privé Azure VMware Solution, afin que le trafic lié à Internet soit routé via la sortie de la région distante.
La topologie recommandée pour les déploiements dans deux régions avec des points de sortie Internet dans les VNets Azure est illustrée dans la figure 8 ci-dessous.
Figure 8 : Ce scénario de référence montre la topologie recommandée pour les déploiements à deux régions disposant d’un accès sortant Internet via des périphéries Internet dans le réseau virtuel Azure.
Lorsque vous initiez des itinéraires par défaut dans Azure, il est crucial de prendre des précautions spéciales pour éviter leur propagation vers les sites locaux, sauf s'il est nécessaire de fournir un accès Internet aux sites locaux via une passerelle Internet dans Azure. Les appareils gérés par le client qui terminent les circuits ExpressRoute géré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.
Figure 9 : ce scénario de référence montre les haut-parleurs Border Gateway Protocol qui terminent les circuits ExpressRoute managés par le client et filtrent les itinéraires par défaut de l’appliance virtuelle réseau Azure.
Étapes suivantes
Pour plus d’informations sur les fonctionnalités réseau d’Azure VMware Solution, consultez concepts de mise en réseau et d’interconnexion d’Azure VMware Solution.
Pour plus d’informations sur la connectivité Internet pour Azure VMware Solution, consultez considérations relatives à la conception de la connectivité Internet.