Liste de vérification pour la planification réseau pour Azure VMware Solution
Azure VMware Solution fournit un environnement de cloud privé VMware accessible aux utilisateurs et aux applications à partir de ressources ou d’environnements locaux et Azure. La connectivité est assurée à travers des services réseau comme des connexions VPN et Azure ExpressRoute. Des plages d’adresses réseau et des ports de pare-feu spécifiques sont nécessaires pour activer ces services. Cet article vous aide à configurer votre réseau pour qu’il 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.
Notes
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é locale à 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 plus de ressources dans le réseau virtuel de votre abonnement. Vous trouverez les procédures de création de ces ressources et d’établissement du peering privé ExpressRoute dans les tutoriels.
La mise en réseau logique du cloud privé comprend une configuration NSX préprovisionné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 la 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 de magasins de données Azure NetApp Files, il est important de déployer le réseau virtuel proche 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 au moyen 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 protocole BGP (Border Gateway Protocol), est automatiquement provisionné et est activé par défaut pour chaque déploiement de cloud privé.
Les clouds privés Azure VMware Solution nécessitent, au minimum, un bloc d’adresses réseau CIDR /22 pour les sous-réseaux. Ce réseau complétant vos réseaux locaux, le bloc d’adresses ne doit pas chevaucher les blocs d’adresses utilisés dans d’autres réseaux virtuels situés de votre abonnement et de vos réseaux locaux. Les réseaux de gestion, vMotion et de 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 n’est pas applicable aux nœuds AV64 et est prévu pour une dépréciation générale à une date ultérieure.
Important
Évitez d’utiliser les schémas IP suivants qui sont 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 | Subnet | 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 |
| Service DNS NSX | Service DNS NSX intégré | /32 |
10.10.0.192/32 |
| Reserved | 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é | Reserved | /26 |
10.10.3.192/26 |
Remarque
Les réseaux de réplication/vmotion/gestion ESXi sont techniquement capables de prendre en charge 125 hôtes, mais le nombre maximal pris en charge est de 96, car 29 sont réservés pour les 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ère les demandes du vCenter Server du cloud privé pour toutes les requêtes DNS locales (voir la section DNS). |
| Serveur DNS local | Serveur DNS de cloud privé | UDP | 53 | Client DNS : transfère les requêtes des services locaux aux serveurs DNS du cloud privé (voir la section 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 | Permet au vCenter Server Azure VMware Solution de communiquer avec le ou les serveurs Active Directory/LDAP locaux. Facultatif pour la configuration d’AD local en tant que source d’identité sur le 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 | Permet au vCenter Server Azure VMware Solution de communiquer avec le ou les serveurs de catalogue global Active Directory/LDAP locaux. Facultatif pour la configuration d’AD local en tant que source d’identité sur le vCenter Server du cloud privé. Utilise le port 3269 pour des raisons de sécurité. |
| Réseau local | Serveur vCenter de cloud privé | TCP (HTTPS) | 443 | Permet d’accéder à vCenter Server à partir d’un réseau local. Port par défaut utilisé par vCenter Server pour écouter 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. |
| HCX Manager | Interconnect (HCX-IX) | TCP (HTTPS) | 8123 | Contrôle de migration en bloc HCX. |
| HCX Manager | Interconnect (HCX-IX), Network Extension (HCX-NE) | TCP (HTTPS) | 9443 | Envoyer des instructions de gestion au dispositif HCX Interconnect local en utilisant l’API REST. |
| Interconnect (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, Interconnect (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 NAT-T (Network Address Translation-Traversal). |
| Interconnexion locale (HCX-IX) | Cloud Interconnect (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 nécessaire pour valider la clé de licence.hybridity est nécessaire pour les mises à jour. |
Ce tableau présente les règles de pare-feu courantes pour des scénarios classiques. Toutefois, vous devrez peut-être prendre en compte plus d’éléments lors de la configuration de règles de pare-feu. Notez que l’indication « local(e) » dans la source et la destination ne s’applique que si votre centre de données dispose d’un pare-feu qui inspecte les flux. Si vos composants locaux ne disposent pas d’un pare-feu pour l’inspection, vous pouvez ignorer ces règles.
Pour plus d’informations, consultez la liste complète des exigences relatives aux 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.