Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure VMware Solution fournit un environnement de cloud privé VMware accessible aux utilisateurs et aux applications depuis des environnements ou ressources sur site et basés sur Azure. La connectivité est assurée via des services de mise en réseau tels qu'Azure ExpressRoute et des connexions VPN. Des plages d'adresses réseau et des ports de pare-feu spécifiques sont requis pour activer ces services. Cet article vous aide à configurer votre mise en réseau afin qu'elle fonctionne avec Azure VMware Solution.
Dans ce tutoriel, découvrez :
- Éléments à prendre en considération pour le réseau virtuel et le circuit ExpressRoute
- Conditions requises pour le routage et le sous-réseau
- Ports réseaux nécessaires pour communiquer avec les services
- Considérations relatives à DHCP et DNS dans Azure VMware Solution
Prérequis
Faire en sorte que toutes les passerelles (y compris le service du fournisseur ExpressRoute) prennent en charge le numéro ASN (Autonomous System Number) sur 4 octets. Azure VMware Solution utilise des numéros de système autonome (ASN) publics à 4 octets pour publier les routes.
Éléments à prendre en considération pour le réseau virtuel et le circuit ExpressRoute
Quand vous créez une connexion de réseau virtuel dans votre abonnement, le circuit ExpressRoute est établi par peering, en utilisant la clé d’autorisation et l’ID de peering que vous demandez sur le portail Azure. Le Peering est une connexion privée de type un-à-un entre votre cloud privé et le réseau virtuel.
Remarque
Le circuit ExpressRoute ne fait pas partie d’un déploiement de cloud privé. Le circuit ExpressRoute local dépasse le cadre de ce document. Si vous avez besoin d'une connectivité sur site à votre cloud privé, utilisez l'un de vos circuits ExpressRoute existants ou achetez-en un dans le portail Azure.
Lors du déploiement d'un cloud privé, vous recevez des adresses IP pour vCenter Server et NSX Manager. Pour accéder à ces interfaces de gestion, créez d'autres ressources dans le réseau virtuel de votre abonnement. Vous trouverez les procédures de création de ces ressources et d'établissement d'un peering privé ExpressRoute dans les tutoriels.
La mise en réseau logique du cloud privé inclut une configuration NSX préapprovisionnée. Une passerelle de niveau 0 et une passerelle de niveau 1 sont pré-approvisionnées pour vous. Vous pouvez créer un segment et l’attacher à la passerelle de niveau 1 existante ou à une nouvelle passerelle de niveau 1 que vous définissez. Les composants de mise en réseau logique NSX fournissent une connectivité Est-Ouest entre les charges de travail et une connectivité Nord-Sud vers Internet et les services Azure.
Important
Si vous prévoyez de mettre à l'échelle vos hôtes Azure VMware Solution en utilisant des magasins de données Azure NetApp Files, il est essentiel de déployer le réseau virtuel à proximité de vos hôtes avec une passerelle de réseau virtuel ExpressRoute. Plus le stockage est proche de vos hôtes, plus les performances sont élevées.
Éléments à prendre en considération en matière de routage et de sous-réseaux
Le cloud privé Azure VMware Solution se connecte à votre réseau virtuel Azure à l'aide d'une connexion Azure ExpressRoute. Cette connexion à bande passante élevée et à faible latence vous permet d’accéder aux services qui s’exécutent dans votre abonnement Azure à partir de votre environnement cloud privé. Le routage utilise le Border Gateway Protocol (BGP), est approvisionné automatiquement et activé par défaut pour chaque déploiement de cloud privé.
Les clouds privés Azure VMware Solution nécessitent un bloc d'adresses réseau CIDR /22 minimum pour les sous-réseaux. Ce réseau complète vos réseaux sur site ; le bloc d'adresses ne doit donc pas chevaucher les blocs d'adresses utilisés dans d'autres réseaux virtuels de votre abonnement et dans les réseaux sur site. Les réseaux de gestion, vMotion et réplication sont approvisionnés automatiquement dans ce bloc d'adresses.
Remarque
Les plages autorisées pour votre bloc d’adresses sont les espaces d’adressage privés RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), à l’exception de 172.17.0.0/16. Le réseau de réplication ne s'applique pas aux nœuds AV64 et sa dépréciation générale est prévue à une date ultérieure.
Important
Évitez d'utiliser les schémas IP suivants, réservés à l'utilisation de NSX :
- 169.254.0.0/24 - utilisé pour le réseau de transit interne
- 169.254.2.0/23 - utilisé pour le réseau de transit inter-VRF
- 100.64.0.0/16 - utilisé pour connecter des passerelles T1 et T0 en interne
Exemple de bloc d’adresses réseau CIDR /22 : 10.10.0.0/22
Les sous-réseaux :
| Utilisation du réseau | Description | Sous-réseau | Exemple |
|---|---|---|---|
| Gestion de cloud privé | Réseau de gestion (par exemple, vCenter, NSX) | /26 |
10.10.0.0/26 |
| Migrations de la gestion HCX | Connectivité locale pour les appliances HCX (liaisons descendantes) | /26 |
10.10.0.64/26 |
| Global Reach, réservé | Interface sortante pour ExpressRoute | /26 |
10.10.0.128/26 |
| NSX DNS Service | Service DNS NSX intégré | /32 |
10.10.0.192/32 |
| Réservé | Réservé | /32 |
10.10.0.193/32 |
| Réservé | Réservé | /32 |
10.10.0.194/32 |
| Réservé | Réservé | /32 |
10.10.0.195/32 |
| Réservé | Réservé | /30 |
10.10.0.196/30 |
| Réservé | Réservé | /29 |
10.10.0.200/29 |
| Réservé | Réservé | /28 |
10.10.0.208/28 |
| Appairage ExpressRoute | Peering ExpressRoute | /27 |
10.10.0.224/27 |
| Gestion ESXi | Interfaces VMkernel de gestion ESXi | /25 |
10.10.1.0/25 |
| Réseau vMotion | Interfaces VMkernel vMotion | /25 |
10.10.1.128/25 |
| Réseau de réplication | Interfaces de réplication vSphere | /25 |
10.10.2.0/25 |
| vSAN | Interfaces VMkernel vSAN et communication de nœud | /25 |
10.10.2.128/25 |
| Liaison montante HCX | Liaisons montantes pour les appliances HCX IX et NE vers des homologues distants | /26 |
10.10.3.0/26 |
| Réservé | Réservé | /26 |
10.10.3.64/26 |
| Réservé | Réservé | /26 |
10.10.3.128/26 |
| Réservé | Réservé | /26 |
10.10.3.192/26 |
Remarque
Les réseaux de gestion/vmotion/réplication ESXi sont techniquement capables de prendre en charge 125 hôtes ; toutefois, le maximum pris en charge est de 96, car 29 sont réservés aux remplacements/à la maintenance (19) et à HCX (10).
Ports réseau requis
| Source | Destination | Protocol | Port | Description |
|---|---|---|---|---|
| Serveur DNS de cloud privé | Serveur DNS local | UDP | 53 | Client DNS : transférez les requêtes depuis le serveur vCenter du cloud privé pour toutes les requêtes DNS sur site (voir la rubrique DNS). |
| Serveur DNS local | Serveur DNS de cloud privé | UDP | 53 | Client DNS : transférez les requêtes depuis les services sur site vers les serveurs DNS du cloud privé (voir la rubrique DNS) |
| Réseau local | Serveur vCenter de cloud privé | TCP (HTTP) | 80 | vCenter Server a besoin du port 80 pour les connexions HTTP directes. Le port 80 redirige les requêtes vers le port HTTPS 443. Cette redirection est utile si vous utilisez http://server au lieu de https://server. |
| Réseau de gestion de cloud privé | Active Directory local | TCP | 389/636 | Permettez au serveur vCenter d'Azure VMware Solutions de communiquer avec le(s) serveur(s) Active Directory/LDAP sur site. Facultatif pour configurer l'AD sur site comme source d'identité sur le serveur vCenter du cloud privé. Le port 636 est recommandé pour des raisons de sécurité. |
| Réseau de gestion de cloud privé | Catalogue global Active Directory local | TCP | 3268/3269 | Permettez au serveur vCenter d'Azure VMware Solutions de communiquer avec le(s) serveur(s) de catalogue global Active Directory/LDAP sur site. Facultatif pour configurer l'AD sur site comme source d'identité sur le serveur vCenter du cloud privé. Utilisez le port 3269 pour la sécurité. |
| Réseau local | Serveur vCenter de cloud privé | TCP (HTTPS) | 443 | Accédez à vCenter Server depuis un réseau sur site. Port par défaut sur lequel vCenter Server écoute les connexions vSphere Client. Pour permettre au système vCenter Server de recevoir des données à partir du client vSphere, ouvrez le port 443 dans le pare-feu. Le système vCenter Server utilise également le port 443 pour superviser le transfert de données à partir des clients du SDK. |
| Réseau local | Gestionnaire cloud HCX | TCP (HTTPS) | 9443 | Interface de gestion des appliances virtuelles du HCX pour la configuration du système du HCX. |
| Réseau Administration local | Gestionnaire cloud HCX | SSH | 22 | Accès SSH administrateur à l’appliance virtuelle HCX Cloud Manager. |
| Responsable HCX | Interconnexion (HCX-IX) | TCP (HTTPS) | 8123 | Contrôle de migration en bloc HCX. |
| Responsable HCX | Interconnexion (HCX-IX), Extension réseau (HCX-NE) | TCP (HTTPS) | 9443 | Envoyer des instructions de gestion au dispositif HCX Interconnect local en utilisant l’API REST. |
| Interconnexion (HCX-IX) | L2C | TCP (HTTPS) | 443 | Envoyer des instructions de gestion d’Interconnect à L2C quand L2C utilise le même chemin qu’Interconnect. |
| HCX Manager, Interconnexion (HCX-IX) | Hôtes ESXi | TCP | 80 443 902 | Gestion et déploiement OVF. |
| Interconnect (HCX-IX), Network Extension (HCX-NE) à la source | Interconnect (HCX-IX), Network Extension (HCX-NE) à la destination | UDP | 4500 | Nécessaire pour IPSEC Échange de clés Internet (IKEv2) pour encapsuler les charges de travail pour le tunnel bidirectionnel. Prend en charge le NAT Traversal (NAT-T). |
| Interconnexion (HCX-IX) / Extension réseau (HCX-NE) | Interconnexion à distance (HCX-IX) / Extension réseau (HCX-NE) | TCP, UDP | 5201 | Requis pour les diagnostics Service Mesh pour le test de liaison montante perftest. (Déplacé à partir du port 4500 avec HCX 4.8). |
| Interconnexion locale (HCX-IX) | Interconnexion cloud (HCX-IX) | UDP | 4500 | Nécessaire pour IPSEC Internet Key Exchange (ISAKMP) pour le tunnel bidirectionnel. |
| Réseau vCenter Server local | Réseau de gestion de cloud privé | TCP | 8000 | vMotion des machines virtuelles d’un vCenter Server local vers un vCenter Server de cloud privé |
| Connecteur HCX | connect.hcx.vmware.com hybridity.depot.vmware.com |
TCP | 443 |
connect est requis pour valider la clé de licence.hybridity est requis pour les mises à jour. |
Ce tableau présente les règles de pare-feu courantes pour des scénarios typiques. Toutefois, il peut être nécessaire de prendre en compte d'autres éléments lors de la configuration des règles de pare-feu. Remarque : lorsque la source et la destination indiquent "sur site", ces informations ne sont pertinentes que si votre centre de données dispose d'un pare-feu qui inspecte les flux. Si vos composants sur site ne disposent pas d'un pare-feu d'inspection, vous pouvez ignorer ces règles.
Pour plus d'informations, consultez la liste complète des exigences de ports VMware HCX.
Éléments à prendre en considération pour la résolution DNS et DHCP
Les applications et les charges de travail exécutées dans un environnement de cloud privé nécessitent une résolution de nom et des services DHCP pour la recherche et les affectations d’adresses IP. Une infrastructure DHCP et DNS appropriée est requise pour fournir ces services. Vous pouvez configurer une machine virtuelle pour fournir ces services dans votre environnement de cloud privé.
Utilisez le service DHCP intégré au Centre de données NSX ou un serveur DHCP local dans le cloud privé au lieu de router le trafic DHCP de diffusion sur le réseau étendu (WAN) vers l’emplacement local.
Important
Si vous publiez une route par défaut vers le Azure VMware Solution, vous devez autoriser le redirecteur DNS à atteindre les serveurs DNS configurés. Ces derniers doivent prendre en charge la résolution de noms publics.
Étapes suivantes
Dans ce tutoriel, vous avez découvert les conditions requises et les éléments à prendre en compte pour déployer un cloud privé Azure VMware Solution. Une fois que le réseau approprié est en place, passez au tutoriel suivant pour créer votre cloud privé Azure VMware Solution.