Exemples d’architectures pour Azure VMware Solution
Lorsque vous établissez une zone d’atterrissage Azure VMware Solution, vous devez d’abord concevoir et implémenter des fonctionnalités de mise en réseau. Les produits et services de mise en réseau Azure prennent en charge plusieurs scénarios de mise en réseau. Cet article décrit les quatre scénarios de mise en réseau les plus courants.
- Scénario 1 : hub WAN Virtuel sécurisé avec intention de routage
- Scénario 2 : une appliance virtuelle réseau (NVA) dans Le réseau virtuel Azure inspecte tout le trafic réseau
- Scénario 3 : le trafic sortant à partir d'Azure VMware Solution avec ou sans NSX-T ou appliances virtuelles de réseau
- Scénario 4 : Solutions de pare-feu non-Microsoft dans un réseau hub virtuel avec Azure Route Server
Pour choisir une architecture appropriée et planifier la structure de vos services, évaluez les charges de travail, la gouvernance et les exigences de votre organisation.
Considérations relatives au scénario
Passez en revue les considérations suivantes et les exigences clés avant de choisir votre scénario de déploiement Azure VMware Solution.
Configuration requise pour le trafic Internet qui entre dans les applications Azure VMware Solution
Considérations relatives au chemin d’accès pour le trafic Internet qui quitte les applications Azure VMware Solution
Extension du réseau L2 pour les migrations
Utilisation de l'NVA dans l’architecture actuelle
Connectivité Azure VMware Solution à un réseau virtuel hub standard ou à un hub Azure Virtual WAN
Connectivité Azure ExpressRoute à partir de centres de données locaux vers Azure VMware Solution
Utilisation d’ExpressRoute Global Reach
Exigences d’inspection du trafic pour :
- Accès Internet aux applications Azure VMware Solution
- Accès Azure VMware Solution à Internet
- Accès Azure VMware Solution aux centres de données locaux
- Accès Azure VMware Solution au réseau virtuel
- Trafic dans le cloud privé Azure VMware Solution
Le tableau suivant décrit les recommandations et considérations en fonction des exigences d’inspection du trafic Azure VMware Solution pour chaque scénario.
Scénario | Exigences en matière d’inspection du trafic | Conception de solution recommandée | Considérations |
---|---|---|---|
1 | - À partir d’Internet - À Internet |
Utilisez un hub sécurisé Virtual WAN qui a une propagation de passerelle par défaut. Utilisez Azure Application Gateway pour le trafic HTTP ou HTTPS. Utilisez le Pare-feu Azure pour le trafic non HTTP ou HTTPS. Déployez un hub Virtual WAN sécurisé qui a une intention de routage. |
Cette option utilise Global Reach, qui n’est pas efficace pour le filtrage local, car elle contourne les hubs Virtual WAN. |
2 | - À partir d’Internet - À Internet - Vers le centre de données local - Vers un réseau virtuel |
Utilisez des solutions de pare-feu NVA non-Microsoft dans le réseau virtuel hub qui dispose du Route Server. N’utilisez pas Global Reach. Utilisez Application Gateway pour le trafic HTTP ou HTTPS. Utilisez une appliance virtuelle réseau de pare-feu non Microsoft sur Azure pour le trafic non HTTP ou HTTPS. |
Choisissez cette option si vous souhaitez utiliser votre NVA existante et centraliser l’inspection du trafic au sein de votre réseau virtuel hub. |
3 | - À partir d’Internet - À Internet - Vers le centre de données local - Vers un réseau virtuel - Dans Azure VMware Solution |
Utilisez NSX-T Centre de données ou un pare-feu NVA non Microsoft dans Azure VMware Solution. Utilisez Application Gateway pour le trafic HTTPS. Utilisez le Pare-feu Azure pour le trafic non HTTPS. Déployez le hub Virtual WAN sécurisé et activez une adresse IP publique dans Azure VMware Solution. |
Choisissez cette option si vous devez inspecter le trafic à partir de deux clouds privés Azure VMware Solution ou plus. Utilisez cette option pour tirer parti des fonctionnalités natives NSX-T. Vous pouvez également combiner cette option avec des NVAs (appliances virtuelles de réseau) qui s'exécutent sur Azure VMware Solution. |
4 | - À partir d’Internet - À Internet - Vers le centre de données local - Vers un réseau virtuel |
Utilisez des solutions de pare-feu non Microsoft dans un réseau virtuel hub qui a le serveur de routage. Utilisez Application Gateway pour le trafic HTTP ou HTTPS. Utilisez une appliance virtuelle réseau de pare-feu non Microsoft sur Azure pour le trafic non HTTP ou HTTPS. Utilisez une appliance virtuelle réseau de pare-feu non Microsoft locale. Déployez des solutions de pare-feu non-Microsoft dans un réseau virtuel hub disposant du serveur de routage. |
Choisissez cette option pour publier l’itinéraire 0.0.0.0/0 d’une appliance virtuelle réseau dans votre réseau virtuel Azure Hub vers un Azure VMware Solution. |
Tenez compte de ces points clés sur les scénarios de mise en réseau :
Tous les scénarios ont des modèles d’entrée similaires via Application Gateway et pare-feu Azure.
Vous pouvez utiliser des solutions L4 vers L7 d’équilibreur de charge dans Azure VMware Solution.
Vous pouvez utiliser le pare-feu distribué NSX-T pour l’un de ces scénarios.
Les sections suivantes décrivent les modèles architecturaux pour les clouds privés Azure VMware Solution. Pour plus d’informations, consultez concepts de mise en réseau et d’interconnexion d’Azure VMware Solution.
Scénario 1 : hub Virtual WAN sécurisé qui a l’intention de routage
Ce scénario implique les composants architecturaux et considérations suivants.
Quand utiliser ce scénario
Utilisez ce scénario si :
Vous n’avez pas besoin d’inspection du trafic entre Azure VMware Solution et les centres de données locaux.
Vous avez besoin d’une inspection du trafic entre les charges de travail Azure VMware Solution et Internet.
Vous devez sécuriser le trafic d’entrée public vers les charges de travail Azure VMware Solution.
Tenez également compte de ces autres facteurs :
Dans ce scénario, vous pouvez posséder les adresses IP publiques. Pour plus d’informations, consultez Préfixes d’adresse IP personnalisés.
Vous pouvez ajouter des services entrants L4 ou L7 publics si nécessaire.
Il se peut que vous ayez ou non déjà une connectivité ExpressRoute entre les centres de données locaux et Azure.
Aperçu
Le diagramme suivant fournit une vue d’ensemble générale du scénario 1.
Téléchargez un fichier PowerPoint de cette architecture.
Composants
Ce scénario se compose des composants suivants :
Pare-feu Azure dans un hub Virtual WAN sécurisé dédié aux pare-feux
Application Gateway pour l’équilibrage de charge L7 et pare-feu d’applications web Azure
Traduction d’adresses réseau de destination L4 avec pare-feu Azure pour traduire et filtrer le trafic d’entrée réseau
Internet sortant via le pare-feu Azure dans votre hub Virtual WAN
EXR, VPN ou SD-WAN pour la connectivité entre les centres de données locaux et Azure VMware Solution
Téléchargez un fichier Visio de cette architecture.
Considérations
Le Pare-feu Azure dans un hub Virtual WAN sécurisé publie l’itinéraire
0.0.0.0/0
vers Azure VMware Solution. Cette route est également annoncée localement via Global Reach. Vous pouvez utiliser SD-WAN ou un VPN pour implémenter un filtre de routage sur site afin d'empêcher l'apprentissage des routes0.0.0.0/0
.Les connexions VPN, ExpressRoute ou de réseau virtuel établies vers un hub Virtual WAN sécurisé qui ne nécessitent pas de publication de
0.0.0.0/0
reçoivent la publication dans tous les cas. Pour empêcher cette action, vous pouvez :Utilisez un périphérique local pour filtrer l’itinéraire
0.0.0.0/0
.Désactivez la propagation de
0.0.0.0/0
sur des connexions spécifiques.- Déconnectez les connexions ExpressRoute, VPN ou réseau virtuel.
- Activer la propagation de
0.0.0.0/0
. - Désactivez la propagation de
0.0.0.0/0
sur ces connexions spécifiques. - Reconnectez ces connexions.
Vous pouvez héberger Application Gateway sur un réseau virtuel spoke qui se connecte à votre hub Virtual WAN.
Activer Azure VMware Solution pour inspecter le trafic local via le Pare-feu Azure
Pour permettre à Azure VMware Solution d’inspecter le trafic local via le Pare-feu Azure, procédez comme suit :
- Supprimez la connexion Global Reach entre Azure VMware Solution et localement.
- Ouvrez un dossier d'assistance auprès du Support Microsoft pour activer la connectivité de transit ExpressRoute-to-ExpressRoute via une appliance de pare-feu dans le hub avec des stratégies de routage privé.
Scénario 2 : une appliance virtuelle réseau dans le hub Azure Virtual Network inspecte tout le trafic réseau
Ce scénario implique les composants architecturaux et considérations suivants.
Quand utiliser ce scénario
Utilisez ce scénario si :
Vous devez utiliser vos appliances virtuelles de pare-feu non-Microsoft dans un réseau virtuel central pour inspecter tout le trafic, et vous ne pouvez pas utiliser Global Reach pour des raisons géopolitiques ou pour d'autres motifs.
- Vous disposez d’une connectivité entre les centres de données locaux et Azure VMware Solution.
- Vous disposez d’une connectivité entre le réseau virtuel et Azure VMware Solution.
- Vous avez besoin d’un accès Internet à partir d’Azure VMware Solution.
- Vous avez besoin d’un accès Internet à Azure VMware Solution.
Vous avez besoin d’un contrôle précis sur les pare-feu qui se trouvent en dehors du cloud privé Azure VMware Solution.
Vous avez besoin de plusieurs adresses IP publiques pour les services entrants et besoin d’un bloc d’adresses IP prédéfinies dans Azure. Dans ce scénario, vous ne possédez pas d’adresses IP publiques.
Ce scénario suppose que vous disposez d’une connectivité ExpressRoute entre les centres de données locaux et Azure.
Aperçu
Le diagramme suivant fournit une vue d’ensemble générale du scénario 2.
Téléchargez un fichier Visio de cette architecture.
Composants
Ce scénario se compose des composants suivants :
Les appliances virtuelles réseau de pare-feu non-Microsoft hébergées dans un réseau virtuel pour l’inspection du trafic et autres fonctions de mise en réseau.
Route Server pour router le trafic entre Azure VMware Solution, les centres de données locaux et les réseaux virtuels.
Application Gateway assure l'équilibrage de charge HTTP ou HTTPS de niveau 7.
Vous devez désactiver ExpressRoute Global Reach dans ce scénario. Les appliances virtuelles réseau non-Microsoft fournissent un accès Internet sortant à Azure VMware Solution.
Téléchargez un fichier Visio de cette architecture.
Considérations
Ne configurez pas ExpressRoute Global Reach pour ce scénario, car le trafic Azure VMware Solution circule directement entre les routeurs ExpressRoute Microsoft Enterprise Edge (MSEE). Le trafic ignore le réseau virtuel hub.
Déployez le serveur de routage dans votre réseau virtuel hub. Le serveur de routes doit être appairé au protocole BGP (Border Gateway Protocol) avec les appliances virtuelles réseau dans le réseau virtuel de transit. Configurez le Serveur de routes pour autoriser la connectivité de branche à branche.
Utilisez les tables de routage personnalisées et les itinéraires définis par l’utilisateur pour acheminer le trafic vers/depuis Azure VMware Solution et l’équilibreur de charge des appliances virtuelles réseau de pare-feu non-Microsoft. Cette configuration prend en charge tous les modes de haute disponibilité, notamment actif/actif et actif/veille, et permet de garantir la symétrie du routage.
Si vous avez besoin d’une haute disponibilité pour les appliances virtuelles réseau, consultez la documentation de votre fournisseur d’appliances virtuelles réseau et déployez des appliances virtuelles hautement disponibles.
Scénario 3 : le trafic sortant à partir d'Azure VMware Solution avec ou sans NSX-T ou appliances virtuelles de réseau
Ce scénario implique les composants architecturaux et considérations suivants.
Quand utiliser ce scénario
Utilisez ce scénario si :
Vous utilisez la plateforme de centre de données NSX-T native. Vous avez donc besoin d’un déploiement PaaS (Platform as a Service) pour Azure VMware Solution.
Vous avez besoin d’une appliance virtuelle réseau BYOL (apportez votre propre licence) au sein d’Azure VMware Solution pour l’inspection du trafic.
Vous avez besoin de services HTTP, HTTPS ou L4 entrants.
Il se peut que vous ayez ou non déjà une connectivité ExpressRoute entre les centres de données locaux et Azure. Tout le trafic d’Azure VMware Solution vers un réseau virtuel, vers l’Internet et vers des centres de données sur site est acheminé par le biais des passerelles de niveau 0 ou de niveau 1 du centre de données NSX-T ou des appliances virtuelles de réseau.
Aperçu
Le diagramme suivant fournit une vue d’ensemble générale du scénario 3.
Téléchargez un fichier Visio de cette architecture.
Composants
Ce scénario se compose des composants suivants :
- Un pare-feu distribué NSX ou une appliance virtuelle réseau derrière le niveau 1 dans Azure VMware Solution.
- Application Gateway pour fournir l’équilibrage de charge L7.
- DNAT de couche 4 avec le Pare-feu Azure.
- Breakout Internet à partir d’Azure VMware Solution.
Téléchargez un fichier Visio de cette architecture.
Considérations
Activez l’accès à Internet dans le portail Azure. Pour ce scénario, une adresse IP sortante peut changer et n’est pas déterministe. Les adresses IP publiques se trouvent en dehors de l’appliance virtuelle réseau. L'appliance réseau virtuelle dans l'offre Azure VMware a toujours des adresses IP privées et ne détermine pas l'adresse IP publique sortante.
Il vous appartient d’apporter une licence et de mettre en œuvre une haute disponibilité pour l’appliance virtuelle réseau.
Consultez la documentation VMware pour les options de placement de l'appliance réseau virtuelle (NVA) et pour des informations sur la limite de VMware de huit cartes d'interface réseau virtuelles sur une machine virtuelle. Pour plus d'informations, consultez l'intégration du pare-feu dans Azure VMware Solution.
Scénario 4 : Solutions de pare-feu non-Microsoft dans un réseau virtuel hub qui a le serveur de routage
Ce scénario implique les composants architecturaux et considérations suivants.
Quand utiliser ce scénario
Utilisez ce scénario si :
Vous devez activer la sortie Internet d'Azure VMware Solution via votre appliance virtuelle réseau non-Microsoft dans un hub de réseau virtuel Azure. Vous souhaitez également inspecter le trafic entre Azure VMware Solution et le réseau virtuel.
Vous souhaitez inspecter le trafic entre les centres de données sur site et Azure via votre appliance virtuelle de réseau non-Microsoft.
Vous avez besoin de plusieurs adresses IP publiques pour les services entrants et besoin d’un bloc d’adresses IP prédéfinies dans Azure. Dans ce scénario, vous ne possédez pas d’adresses IP publiques.
Vous avez besoin d’un contrôle précis sur les pare-feu en dehors du cloud privé Azure VMware Solution.
Aperçu
Le diagramme suivant fournit une vue d’ensemble générale du scénario 4.
Téléchargez un fichier Visio de cette architecture.
Composants
Ce scénario se compose des composants suivants :
Les appliances virtuelles réseau non-Microsoft, configurées en mode actif/actif ou actif/veille, qui sont hébergées dans un réseau virtuel pour agir en tant que pare-feu et effectuer d'autres fonctions réseau.
Route Server pour échanger des routes entre Azure VMware Solution, des centres de données locaux et des réseaux virtuels.
Vos appliances virtuelles réseau non-Microsoft dans votre hub de réseau virtuel Azure pour fournir un trafic Internet sortant à Azure VMware Solution.
ExpressRoute pour la connectivité entre les centres de données locaux et Azure VMware Solution.
Télécharger un fichier Visio de cette architecture.
Considérations
Pour ce scénario, les adresses IP publiques sortantes sont affectées aux appliances virtuelles réseau sur le réseau virtuel Azure.
Les appliances virtuelles réseau non-Microsoft dans le hub de réseau virtuel sont configurées pour homologuer le service de routage via BGP et Equal-Cost routage ecMP (Multi-Path). Ces appliances virtuelles réseau publient l’itinéraire par défaut
0.0.0.0/0
vers Azure VMware Solution.L’itinéraire par défaut
0.0.0.0/0
est également publié localement via Global Reach. Implémentez un filtre de routage local pour empêcher l’apprentissage de l’itinéraire par défaut0.0.0.0/0
.Le trafic entre Azure VMware Solution et votre réseau local transite par ExpressRoute Global Reach. Si vous souhaitez en savoir plus, consultez Appairer des environnements locaux à Azure VMware Solution. L’appliance virtuelle réseau non-Microsoft locale effectue une inspection du trafic entre les appliances virtuelles virtuelles locales et Azure VMware Solution au lieu des appliances virtuelles réseau non-Microsoft dans le hub de réseau virtuel Azure.
Vous pouvez héberger Application Gateway sur un réseau virtuel spoke qui se connecte à un hub ou qui se trouve sur le réseau virtuel hub.
Étapes suivantes
Intégrer Azure VMware Solution dans une architecture hub-and-spoke
configurer des composants réseau NSX à l’aide d’Azure VMware Solution
Pour découvrir les principes architecturaux de la zone d’atterrissage à l’échelle du Cloud Adoption Framework, les différentes considérations relatives à la conception et les meilleures pratiques pour Azure VMware Solution, consultez l’article suivant de cette série :