Conception de VMware NSX-T
Fin de la commercialisation: à compter du 31 octobre 2025, les nouveaux déploiements des offres « VMware Solutions » ne seront plus disponibles pour les nouveaux clients. Les clients existants peuvent continuer à utiliser et à développer leurs charges de travail VMware® actives sur IBM Cloud®. Pour plus d'informations, voir Fin de la commercialisation pour VMware sur IBM Cloud.
VMware NSX-T™ est conçu pour répondre aux cadres d'application et aux architectures qui ont des points d'extrémité et des piles technologiques hétérogènes. Outre VMware vSphere®, ces environnements peuvent inclure d'autres hyperviseurs, une KVM, des conteneurs et des serveurs non virtualisés. NSX-T est conçu pour couvrir un réseau défini par logiciel et une infrastructure de sécurité sur des plates-formes autres que vSphere. Bien qu'il soit possible de déployer des composants NSX-T sans avoir besoin de vSphere, cette conception est axée sur NSX-T et son intégration, principalement au sein d'un déploiement automatisé vCenter Server vSphere.
NSX-T version 3 et ultérieure peut fonctionner sur le commutateur distribué virtuel (VDS) vSphere version 7.0. Tous les nouveaux déploiements de VMware NSX et vSphere utilisent NSX-T sur VDS (N-VDS n'est pas utilisé). Pour NSX-T version 2.4 et suivantes, les fonctions de gestionnaire VM et de contrôleur VM sont combinées. Par conséquent, trois machines virtuelles de contrôleur ou de gestionnaire sont déployées. Si elles se trouvent sur le même sous-réseau, elles utilisent un équilibreur de charge réseau interne. Si elles sont dans des sous-réseaux différents, un équilibreur de charge externe est nécessaire.
NSX-T apporte de nombreuses fonctionnalités avancées, telles que les politiques de pare-feu, l'inclusion de l'introspection des invités dans les politiques de pare-feu et le suivi avancé du flux net. La description de ces fonctionnalités dépasse le cadre du présent document. Dans cette conception, l'infrastructure de gestion NSX-T est déployée lors du déploiement initial du cluster vCenter Server®. Pour plus d'informations sur NSX-T, consultez la documentation NSX à l'adresse VMware.
Besoins en ressources
Dans cette conception, les machines virtuelles du gestionnaire-contrôleur NSX-T sont déployées dans le cluster de gestion. En outre, chaque gestionnaire de contrôleur se voit attribuer une adresse IP adossée à un VLAN à partir du bloc d'adresses portables privées. Le bloc d'adresse est désigné pour les composants de gestion et configuré avec les serveurs DNS et NTP dont il est question dans la section 0. Un résumé de l'installation de NSX Manager est présenté dans le tableau suivant.
| Attribut | Spécification |
|---|---|
| Gestionnaires ou contrôleurs NSX | Trois dispositifs virtuels |
| Nombre de vCPU | 6 |
| Mémoire | 24 Go |
| Disque | 300 Go |
| Type de disque | Allocation dynamique |
| Réseau privé A | Privé A |
La figure suivante montre l'emplacement des gestionnaires NSX par rapport aux autres composants de cette architecture.
Remarques relatives au déploiement
Avec NSX-T v3.x sur vSphere VDS switch version 7.0, N-VDS n'est plus nécessaire sur les hôtes ESXi. Lorsqu'il est configuré en tant que noeuds de transport, vous pouvez utiliser le commutateur VDS version 7, le cluster consolidé constituant dans ce cas une solution plus optimale.
Après le déploiement initial, l'automatisation IBM Cloud® déploie trois dispositifs virtuels gestionnaire-contrôleurs NSX-T dans le cluster de gestion. Les contrôleurs sont affectés à une adresse IP adossée à un VLAN du sous-réseau portable Private A qui est désigné pour les composants de gestion. De plus, les règles d'anti-affinité VM–VM sont créées de telle sorte que les contrôleurs soient répartis parmi les hôtes du cluster.
Vous devez déployer le cluster initial avec trois noeuds au moins afin de garantir la haute disponibilité pour les gestionnaires ou les contrôleurs. En plus des gestionnaires, l'automatisation IBM Cloud prépare le cluster de charge de travail déployé en tant que noeuds de transport NSX-T. Les nœuds de transport ESXi sont affectés à une adresse IP adossée à un VLAN de la plage d'adresses IP portable Private A spécifiée par un pool d'adresses IP NSX dérivé du résumé du VLAN et du sous-réseau. Le trafic du nœud de transport réside sur le VLAN non marqué et est affecté au VDS NSX-T privé.
En fonction de la topologie NSX-T choisie, vous pouvez déployer un cluster de passerelles NSX-T sous la forme d'une paire de VM ou d'un logiciel déployé sur des nœuds de cluster en métal nu. Les serveurs de périphérie bare metal ne sont pas pris en charge par l'automatisation d'IBM Cloud et doivent être déployés et configurés manuellement. Que la paire de clusters soit virtuelle ou physique, des liaisons montantes sont configurées sur des commutateurs VDS pour les réseaux privés d'IBM Cloud et les réseaux publics (le cas échéant).
Le tableau suivant récapitule les exigences relatives à un environnement de taille moyenne, qui est la taille de départ recommandée pour les charges de travail de production.
| Ressources | Gestionnaire x3 | Cluster de services de périphérie x4 |
|---|---|---|
| Taille moyenne | Dispositif virtuel | Dispositif virtuel |
| Nombre de vCPU | 6 | 4 |
| Mémoire | 24 Go | 8 Go |
| Disque | 300 Go vSAN ou NFS de gestion | 200 Go vSAN ou NFS de gestion |
| Type de disque | Allocation dynamique | Allocation dynamique |
| Réseau | Privé A | Privé A |
Conception de commutateur distribué
La conception utilise un nombre minimal de commutateurs vDS. Les hôtes dans le cluster de gestion sont connectés aux réseaux privés et publics (en option). Les hôtes sont configurés avec deux commutateurs virtuels distribués. L'utilisation de deux commutateurs est conforme à la pratique du réseau IBM Cloud qui sépare le réseau public et le réseau privé. Tous les nouveaux déploiements de NSX et vSphere tirent parti de l'exécution du commutateur vSphere VDS version 7.0, qui permet une architecture NSX-T convergée.
Comme indiqué dans les diagrammes précédents, le vDS public *instancename*-*clustername*-public est configuré pour la connectivité du réseau public et le vDS public *instancename*-*clustername*-private est configuré
pour la connectivité du réseau privé. La séparation des différents types de trafic est nécessaire pour réduire les conflits et les temps d'attente et renforcer la sécurité.
Les VLAN sont utilisés pour segmenter les fonctions de réseau physique. Cette conception utilise VLAN, deux pour le trafic de réseau privé et l'autre pour le trafic de réseau public. Le tableau suivant illustre la séparation du trafic.
| VLAN | Désignation | Type de trafic |
|---|---|---|
| Réseau local virtuel 1 | Privé A | Gestion ESXi, gestion, liaisons montantes périphériques |
| Réseau local virtuel 2 | Privé B | Genève (TEP), vSAN, NFS, et vMotion |
| Réseau local virtuel 3 | Public | Disponible pour l'accès à Internet |
Pour les deux clusters de passerelle d'hôte facultatifs, cette conception utilise deux VLAN, un pour le trafic de réseau privé et l'autre pour le trafic de réseau public. Ce type de cluster utilise des disques locaux comme magasin de données. Par conséquent, il n'est pas nécessaire de séparer le trafic de stockage. De plus, conformément à la conception, le trafic NSX-T Geneve (TEP) est exclu. Le tableau suivant illustre la séparation du trafic entre les VLAN pour ce type de cluster :
| VLAN | Désignation | Type de trafic |
|---|---|---|
| Réseau local virtuel 1 | Transit privé | VLAN de transit privé, gestion ESXi et vMotion |
| Réseau local virtuel 2 | Transit public | VLAN de transit public |
désignation des conventions
Les conventions de dénomination suivantes sont utilisées pour le déploiement. Pour une meilleure lisibilité, seule la dénomination détaillée est utilisée. Par exemple, instancename-dcname-clustername-tz-edge-private est référencé
sous la forme tz-edge-private.
| Description | Norme de dénomination |
|---|---|
| Machines virtuelles de gestion | instancename-nsxt-ctrlmgr0instancename-nsxt-ctrlmgr1instancename-nsxt-ctrlmgr2 |
| Profils de liaison montante | instancename-esxi-private-profileinstancename-esxi-public-profileinstancename-edge-private-profileinstancename-edge-public-profileinstancename-edge-tep-profileinstancename-mgmt-edge-private-profileinstancename-mgmt-edge-public-profileinstancename-mgmt-edge-tep-profile |
| Profils NIOC | instancename-clustername-nioc-private-profileinstancename-clustername-nioc-public-profile |
| Profils des clusters de passerelles | instancename-dcname-clustername-service-edge-cluster-profileinstancename-dcname-clustername-service-edge-cluster-profile |
| Zones de transport | instancename-tz-esxi-privateinstancename-tz-esxi-publicinstancename-tz-vm-overlayinstancename-tz-edge-privateinstancename-tz-edge-public |
| Segments | instancename-podname.dcname-customer-t0-172-16-16-0instancename-podname.dcname-customer-t1-192-168-0-0instancename-podname.dcname-customer-t1-192-168-1-0instancename-podname.dcname-customer-to-privateinstancename-podname.dcname-customer-to-publicinstancename-podname.dcname-service-to-privateinstancename-podname.dcname-service-to-publicinstancename-clustername-edge-teps |
| Pools d'adresses IP | instancename-clustername-tep-pool |
| Profils de noeuds de transport | instancename-podname.dcname-clustername-esxi-tpn-profile |
| Passerelles Tier-0 et Tier-1 | instancename-podname.dcname-clustername-T0-function (où function comprend services, workload, openshift)instancename-podname.dcname-clustername-T1-function |
Noeuds de transport
Les noeuds de transport définissent les objets serveur physique ou les machines virtuelles qui participent à la matrice de réseau virtuel. Pour comprendre la conception, revoyez le tableau suivant.
| Type de noeud de transport | Profil de liaison montante | Affectation d'IP |
|---|---|---|
| ESXi | esxi-private-profileesxi-public-profile |
tep-pool |
| Cluster de passerelles | edge-private-profileedge-public-profileedge-tep-profilemgmt-edge-private-profilemgmt-edge-public-profilemgmt-edge-tep-profile |
tep-pool |
Profils de liaison montante et groupage
Un profil de liaison montante définit des politiques pour les liens entre les hôtes de l'hyperviseur et les commutateurs logiques NSX-T ou entre les nœuds NSX Edge et les commutateurs TOR (top-of-rack).
| Nom du profil de liaison montante | VLAN | Règle de groupage | Liaisons montantes actives | Liaisons de secours | Unité de transmission maximale |
|---|---|---|---|---|---|
esxi-private-profile |
Valeur par défaut | Valeur par défaut - source d'équilibrage de charge | uplink-1 uplink-2 |
Géré par vCenter Server | |
esxi-private-profile |
Valeur par défaut | TEP - ordre de basculement | uplink-1 | uplink-2 | Géré par vCenter Server |
esxi-public-profile |
Valeur par défaut | Valeur par défaut - source d'équilibrage de charge | uplink-1 uplink-2 |
Géré par vCenter Server | |
edge-private-profile |
Valeur par défaut | uplink-1 | 9000 | ||
edge-public-profile |
Valeur par défaut | uplink-1 | 1 500 | ||
edge-tep-profile |
Valeur par défaut | Commande de basculement | uplink-1 | 9000 | |
mgmt-edge-private-profile |
Valeur par défaut | uplink-1 | 9000 | ||
mgmt-edge-public-profile |
Valeur par défaut | uplink-1 | 1 500 | ||
mgmt-edge-tep-profile |
Valeur par défaut | Commande de basculement | uplink-1 | 9000 |
Pools de VNI
Les identificateurs de réseau virtuel (VNI, Virtual Network Identifier) sont similaires aux réseaux locaux virtuels (VLAN, Virtual Local Area Network) dans un réseau physique. Ils sont automatiquement créés lors de la création d'un commutateur logique à partir d'un pool ou d'une plage d'ID. Cette conception utilise le pool de VNI par défaut déployé avec NSX-T.
Segments
Un segment NSX-T reproduit des fonctionnalités de commutation, de diffusion, d'unicast inconnu, de trafic de multidiffusion (BUM), dans un environnement virtuel découplé du matériel sous-jacent.
| Nom du segment | VLAN | Zone de transport | Règle de groupage de liaison montante |
|---|---|---|---|
edge-teps |
Valeur par défaut | tz-esxi-private |
TEP - ordre de basculement |
service-to-private |
Valeur par défaut | tz-edge-private |
|
service-to-public |
Valeur par défaut | tz-edge-public |
|
customer-to-private |
Valeur par défaut | tz-edge-private |
|
customer-to-public |
Valeur par défaut | tz-edge-public |
|
customer-t0-172-16-16-0 |
tz-vm-overlay |
||
customer-t1-192-168-0-0 |
tz-vm-overlay |
||
customer-t1-192-168-1-0 |
tz-vm-overlay |
Cluster de passerelles
Dans cette conception, deux clusters de noeud Edge virtuels sont mis à disposition, l'un pour la gestion et l'autre pour les charges de travail client. Une limite d'un T0 par noeud de transport Edge est appliquée, ce qui signifie qu'un cluster de noeuds Edge unique peut prendre en charge une passerelle T0 (en mode actif-de secours ou actif-actif).
Les figures suivantes montrent les composants fonctionnels d'un cluster de passerelle NSX-T.
Passerelle de routeur logique de niveau 0
Une passerelle logique de niveau 0 NSX-T fournit un service passerelle entre le réseau logique et le réseau physique (pour le trafic nord-sud). Dans cette conception, deux passerelles T0 hautement disponibles sont déployées dans deux clusters de passerelles NSX-T distincts, l'un pour les clients et l'autre pour les services ou les besoins de gestion. D'autres services et produits sont optionnels pour les topologies choisies par les clients, qui utilisent les services T0 pour leurs besoins de connectivité entrante ou sortante. Chaque passerelle logique T0 est configurée avec deux liaisons montantes pour le réseau privé et deux liaisons montantes pour le réseau public. De plus, des adresses IP virtuelles sont affectées aux liaisons montantes publiques et privées.
Passerelle logique de niveau 1
Une passerelle logique de niveau 1 NSX-T dispose de ports de liaison descendante pour se connecter aux commutateurs logiques des centres de données NSX-T et de ports de liaison montante pour se connecter aux passerelles logiques de niveau 0 des centres de données NSX-T. Ils fonctionnent au niveau du noyau de l'hyperviseur pour lequel ils sont configurés et sont des instances de routeur virtuel (vrf) du cluster de passerelles NSX-T. Dans cette conception, une ou plusieurs passerelles logiques T1 peuvent être créées pour les besoins des topologies choisies par le client.
Annonces de routage du niveau 1 vers le niveau 0
Afin de fournir une connectivité de couche 3 entre les machines virtuelles connectées aux commutateurs logiques reliés à différentes passerelles logiques de niveau 1, il est nécessaire d'activer les annonces de routage du niveau 1 à destination du niveau 0. Inutile de configurer un protocole de routage ou des routes statiques entre les routeurs logiques de niveau 1 et de niveau 0. NSX-T crée automatiquement des routes statiques lorsque vous activez les annonces de routage. Pour cette conception, les annonces de routage sont toujours activées pour toutes les passerelles de niveau 1 créées par automatisation IBM Cloud® for VMware Solutions.
Topologies préconfigurées
Charge de travail à T1 à T0 gateway - virtual gateway cluster
Avec NSX-T, pas de configuration de protocole de routage dynamique entre T1 et T0. L'espace d'adresse IP RFC-1891 est utilisé pour le réseau superposé de charge de travail et le réseau superposé de transport. Un espace d'adresses IP portables privées et publiques client est affecté à l'usage des clients. Un espace d'adresses IP portables privées et publiques IBM Cloud désigné par le client est affecté à T0 pour une utilisation par le client.