Intégrer Azure VMware Solution dans une architecture hub and spoke
Cet article fournit des recommandations relatives à l’intégration d’un déploiement Azure VMware Solution dans une architecture hub and spoke existante ou nouvelle sur Azure.
Le scénario Hub and Spoke suppose un environnement de cloud hybride avec des charges de travail sur :
- Azure natif utilisant les services IaaS ou PaaS
- Azure VMware Solution
- vSphere local
Architecture
Le Hub est un réseau virtuel Azure qui centralise la connectivité à votre cloud privé local et Azure VMware Solution. Les Spokes sont des réseaux virtuels appairés avec le Hub pour permettre la communication entre des réseaux virtuels.
Le trafic entre le centre de données local, le cloud privé Azure VMware Solution et le hub passe par des connexions Azure ExpressRoute. Les réseaux virtuels Spoke contiennent généralement des charges de travail IaaS, mais ils peuvent avoir des services PaaS comme App Service Environment, qui a une intégration directe avec le réseau virtuel, ou d’autres services PaaS avec Azure Private Link activé.
Important
Vous pouvez utiliser une passerelle ExpressRoute existante pour vous connecter à Azure VMware Solution, à condition qu’elle ne dépasse pas la limite de quatre circuits ExpressRoute par réseau virtuel. Toutefois, pour accéder à Azure VMware Solution à partir d’un site local via ExpressRoute, vous devez disposer de ExpressRoute Global Reach, car la passerelle ExpressRoute ne fournit pas de routage transitif entre ses circuits connectés.
Le diagramme montre un exemple de déploiement Hub and Spoke dans Azure, connecté en local et à Azure VMware Solution via ExpressRoute Global Reach.
L’architecture possède les composants majeurs suivants :
Site local : un ou plusieurs centres de données client locaux connectés à Azure via une connexion ExpressRoute.
Cloud privé Azure VMware Solution : centre de données défini par logiciel Azure VMware Solution formé par un ou plusieurs clusters vSphere, chacun avec un maximum de 16 hôtes.
Passerelle ExpressRoute : active la communication entre le cloud privé Azure VMware Solution, les services partagés sur le réseau virtuel hub et les charges de travail exécutées sur des réseaux virtuels Spoke au moyen d’une connexion ExpressRoute.
ExpressRoute Global Reach : active la connectivité entre une installation locale et le cloud privé Azure VMware Solution. La connectivité entre Azure VMware Solution et l’infrastructure Azure s’effectue à l’aide d’ExpressRoute Global Reach uniquement.
Considérations relatives à S2S VPN : La connectivité au cloud privé Azure VMware Solution à l’aide d’Azure S2S VPN est prise en charge tant qu’elle répond à la configuration réseau minimale requise pour VMware HCX.
Réseau virtuel hub : fait office de point central de la connectivité pour votre réseau local et le cloud privé Azure VMware Solution.
Réseau virtuel Spoke
Spoke IaaS : héberge des charges de travail basées sur IaaS Azure, y compris des groupes à haute disponibilité de machines virtuelles et des groupes de machines virtuelles identiques, ainsi que les composants réseau correspondants.
Spoke PaaS : héberge des services PaaS Azure à l’aide de l’adressage privé grâce au Point de terminaison privé et à la Liaison privée.
Pare-feu Azure : fait office d’élément central pour segmenter le trafic entre les spokes et Azure VMware Solution.
Application Gateway : expose et protège des applications web qui s’exécutent sur des machines virtuelles IaaS/PaaS Azure ou Azure VMware Solution. Il s’intègre à d’autres services tels que la Gestion des API.
Considérations relatives au réseau et à la sécurité
Les connexions ExpressRoute permettent au trafic de circuler entre les sites locaux, Azure VMware Solution et l’infrastructure du réseau Azure. Azure VMware Solution utilise le service Global Reach d’ExpressRoute pour implémenter cette connectivité.
Comme une passerelle ExpressRoute ne fournit pas de routage transitif entre ses circuits connectés, la connectivité locale doit également utiliser ExpressRoute Global Reach pour communiquer entre l’environnement vSphere local et Azure VMware Solution.
Flux de trafic local vers Azure VMware Solution
Flux de trafic Azure VMware Solution vers le réseau virtuel hub
Pour plus d’informations sur les concepts de connectivité et de mise en réseau Azure VMware Solution, consultez la documentation du produit Azure VMware Solution.
Segmentation du trafic
Pare-feu Azure est la partie centrale de la topologie hub and spoke, déployée sur le réseau virtuel hub. Utilisez le Pare-feu Azure ou une autre appliance virtuelle réseau (NVA) prise en charge par Azure pour établir des règles de trafic et segmenter la communication entre les différents spokes et les charges de travail Azure VMware Solution.
Créez des tables de routage pour diriger le trafic vers le Pare-feu Azure. Pour les réseaux virtuels spoke, créez un itinéraire qui définit l’itinéraire par défaut vers l’interface interne du Pare-feu Azure. Ainsi, lorsqu’une charge de travail dans le réseau virtuel doit atteindre l’espace d’adressage Azure VMware Solution, le pare-feu peut l’évaluer et appliquer la règle de trafic correspondante pour l’autoriser ou la refuser.
Important
Un itinéraire avec le préfixe d’adresse 0.0.0.0/0 sur le paramètre GatewaySubnet n’est pas pris en charge.
Définissez des itinéraires pour des réseaux spécifiques sur la table de routage correspondante. Par exemple, des itinéraires pour atteindre les préfixes d’adresses IP des charges de travail et de gestion Azure VMware Solution depuis des charges de travail de spoke et inversement.
Un deuxième niveau de segmentation du trafic utilisant les groupes de sécurité réseau dans les Spokes et le Hub pour créer une stratégie de trafic plus granulaire.
Remarque
Trafic local vers Azure VMware Solution : le trafic entre des charges de travail locales (vSphere ou autres) est activé par Global Reach, mais le trafic ne passe pas par le Pare-feu Azure sur le hub. Dans ce scénario, vous devez implémenter des mécanismes de segmentation du trafic, localement ou dans Azure VMware Solution.
Application Gateway
Azure Application Gateway V1 et V2 ont été testés avec des applications web qui s’exécutent sur des machines virtuelles Azure VMware Solution en tant que pool principal. L’Application Gateway est actuellement la seule méthode prise en charge pour exposer des applications web s’exécutant sur des machines virtuelles Azure VMware Solution à Internet. Elle peut également exposer les applications aux utilisateurs internes en toute sécurité.
Pour plus d’informations, consultez l’article relatif à Azure VMware Solution sur Application Gateway.
Serveur jump et Azure Bastion
Accédez à l’environnement Azure VMware Solution à l’aide d’un serveur jump, qui est une machine virtuelle Windows 10 ou Windows Server déployée dans le sous-réseau de service partagé au sein du réseau virtuel hub.
Important
Azure Bastion est le service recommandé pour se connecter au serveur de rebond afin d’empêcher l’exposition à Internet d’Azure VMware Solution. Vous ne pouvez pas utiliser Azure Bastion pour vous connecter à des machines virtuelles Azure VMware Solution, car il ne s’agit pas d’objets IaaS Azure.
Pour des raisons de sécurité, il est recommandé de déployer le service Microsoft Azure Bastion au sein du réseau virtuel Hub. Azure Bastion fournit un accès RDP et SSH transparent aux machines virtuelles déployées sur Azure sans approvisionner des adresses IP publiques pour ces ressources. Une fois que vous avez configuré le service Azure Bastion, vous pouvez accéder à la machine virtuelle sélectionnée à partir du Portail Azure. Après avoir établi la connexion, un nouvel onglet s’ouvre et affiche le bureau du serveur jump et, à partir de ce bureau, vous pouvez accéder au plan de gestion du cloud privé Azure VMware Solution.
Important
N’attribuez pas d’IP publique à la machine virtuelle du serveur jump ni n’exposez le port 3389/TCP à l’Internet public.
Considérations relatives à la résolution Azure DNS
Pour la résolution Azure DNS, deux options sont disponibles :
Utilisez les contrôleurs de domaine déployés sur le hub (décrits dans Considérations relatives aux identités) en tant que serveurs de noms.
Déployez et configurez une zone privée Azure DNS.
La meilleure approche consiste à combiner les deux pour fournir une résolution de noms fiable pour Azure VMware Solution, sur site et Azure.
Recommandation de conception générale : utilisez le DNS existant intégré à Active Directory déployé sur au moins deux machines virtuelles Azure dans le réseau virtuel hub et configurées dans les réseaux virtuels Spoke pour utiliser ces serveurs Azure DNS dans les paramètres DNS.
Vous pouvez utiliser Azure DNS privé, où la zone Azure DNS privé est liée au réseau virtuel. Les serveurs DNS sont utilisés en tant que solutions de résolution hybrides avec un transfert conditionnel vers des DNS locaux ou Azure VMware Solution à l’aide de l’infrastructure client d’Azure DNS privé.
Pour gérer automatiquement le cycle de vie des enregistrements DNS pour les machines virtuelles déployées au sein de réseaux virtuels spoke, activez l’inscription automatique. Lorsque l’inscription automatique est activée, le nombre maximal de zones DNS privées est 1. Si l’inscription automatique est désactivée, le nombre maximal est 1 000.
Vous pouvez configurer des serveurs locaux et Azure VMware Solution avec des redirecteurs conditionnels vers des machines virtuelles de résolution dans Azure pour la zone privée Azure DNS.
Identité - Éléments à prendre en compte
À des fins d’identité, la meilleure approche consiste à déployer au moins un contrôleur de domaine sur le hub. Utilisez deux sous-réseaux de service partagés dans le mode distribué par zone ou dans un groupe à haute disponibilité de machines virtuelles. Pour plus d’informations sur l’extension de votre domaine Active Directory (AD) local à Azure, consultez Centre des architectures Azure.
En outre, déployez un autre contrôleur de domaine sur le côté Azure VMware Solution pour agir en tant qu’identité et source DNS au sein de l’environnement vSphere.
Comme meilleure pratique recommandée, intégrez le domaine AD avec Microsoft Entra ID.