Conception de l'infrastructure du réseau physique pour VMware Cloud Foundation

La conception du réseau du centre de données physique inclut la définition de la topologie réseau pour connecter des commutateurs physiques et des hôtes ESXi, déterminant ainsi des paramètres de port de commutateur pour les VLAN et l'agrégation de liens, et la conception du routage.

Un réseau défini par logiciel (SDN) s'intègre aux composants du centre de données physique et utilise ceux-ci. SDN s'intègre à votre réseau physique pour prendre en charge le transit est-ouest dans le centre de données et le transit nord-sud vers les réseaux SDDC et à partir de ceux-ci.

Il existe plusieurs topologies de déploiement réseau du centre de données classique :

• Accès à l'agrégation de cœurs

• Feuille-tronc

• SDN matériel

Note :

Feuille-tronc est la topologie de déploiement réseau du centre de données par défaut utilisée pour VMware Cloud Foundation.

VLAN et sous-réseaux pour VMware Cloud Foundation

Configurez vos VLAN et vos sous-réseaux conformément aux instructions et conditions requises pour VMware Cloud Foundation.

Lors de la conception de la configuration des VLAN et des sous-réseaux pour votre déploiement de VMware Cloud Foundation, tenez compte des instructions suivantes :

Tableau 1. Instructions relatives aux VLAN et aux sous-réseaux pour VMware Cloud Foundation

Toutes les topologies de déploiement	Plusieurs zones de disponibilité	Fédération NSX entre plusieurs instances de VMware Cloud Foundation	Cluster de domaine de charge de travail VI de calcul sur plusieurs racks
Assurez-vous que vos sous-réseaux sont dimensionnés de manière appropriée pour permettre l'extension, car celle-ci peut être perturbatrice si elle est réalisée ultérieurement. Utilisez l'adresse IP de l'interface flottante pour le protocole VRPP (Virtual Router Redundancy Protocol) ou HSRP (Hot Standby Routing Protocol) comme passerelle. Utilisez l'espace d'adresses IPv4 RFC 1918 pour ces sous-réseaux et allouez un octet par instance de VMware Cloud Foundation et un autre octet par fonction.	Pour les segments de réseau qui sont étendus entre les zones de disponibilité, l'ID VLAN doit répondre aux conditions requises suivantes : Être identique dans les deux zones de disponibilité avec les mêmes segments de réseau de couche 3. Disposer d'une passerelle de couche 3 au premier tronçon qui est hautement disponible afin qu'il tolère la panne d'une zone de disponibilité entière. Pour les segments de réseau du même type qui ne sont pas étendus entre les zones de disponibilité, l'ID VLAN peut être identique ou différent entre les zones.	Un segment de réseau RTEP doit disposer d'un ID VLAN et d'une plage de couche 3 propre à l'instance de VMware Cloud Foundation. Dans une instance de VMware Cloud Foundation avec plusieurs zones de disponibilité, le segment de réseau RTEP doit être étendu entre les zones et recevoir le même ID VLAN et la même plage d'adresses IP. Tous les réseaux Edge RTEP doivent être reliés entre eux.	Utilisez l'espace d'adresses IPv4 RFC 1918 pour ces sous-réseaux et allouez un octet par rack et un autre octet par fonction réseau.

Lors du déploiement des VLAN et des sous-réseaux pour VMware Cloud Foundation, ils doivent remplir les conditions requises suivantes en fonction de la topologie de VMware Cloud Foundation :

Figure 1. Choix d'un modèle de VLAN pour le trafic d'hôtes et de VM de gestion

Tableau 2. VLAN et sous-réseaux pour les zones de disponibilité et les instances de VMware Cloud Foundation

Fonction	Instances de VMware Cloud Foundation avec une zone de disponibilité unique	Instances de VMware Cloud Foundation avec plusieurs zones de disponibilité
Gestion des VM	Requis en cas de séparation de la gestion des hôtes Passerelle hautement disponible dans l'instance	Requis en cas de séparation de la gestion des hôtes Doit être étendu dans l'instance Passerelle hautement disponible dans les zones de disponibilité de l'instance
Gestion des hôtes - première zone disponible	Obligatoire Passerelle hautement disponible dans l'instance	Obligatoire Passerelle hautement disponible dans les zones de disponibilité de l'instance
vSphere vMotion : première zone de disponibilité	Obligatoire Passerelle hautement disponible dans l'instance	Obligatoire Passerelle hautement disponible dans la première zone de disponibilité de l'instance
vSAN : première zone de disponibilité	Requis pour le cluster par défaut du domaine de gestion Passerelle hautement disponible dans l'instance	Obligatoire Passerelle hautement disponible dans la première zone de disponibilité de l'instance
Superposition de l'hôte : première zone de disponibilité	Obligatoire Passerelle hautement disponible dans l'instance	Obligatoire Passerelle hautement disponible dans la première zone de disponibilité de l'instance
NFS	Requis si vous utilisez NFS comme stockage principal dans le domaine de charge de travail VI	Non pris en charge
Liaison montante 01	Obligatoire Passerelle facultative	Obligatoire Passerelle facultative Doit être étendu dans l'instance
Liaison montante 02	Obligatoire Passerelle facultative	Obligatoire Passerelle facultative Doit être étendu dans l'instance
Superposition du dispositif Edge	Obligatoire Passerelle hautement disponible dans l'instance	Obligatoire Doit être étendu dans l'instance Passerelle hautement disponible dans les zones de disponibilité de l'instance
Gestion des hôtes - deuxième zone disponible	Non requis	Obligatoire Passerelle hautement disponible dans la deuxième zone de disponibilité de l'instance
vSphere vMotion : deuxième zone de disponibilité	Non requis	Obligatoire Passerelle hautement disponible dans la deuxième zone de disponibilité de l'instance
vSAN : deuxième zone de disponibilité	Non requis	Obligatoire Passerelle hautement disponible dans la deuxième zone de disponibilité de l'instance
Superposition de l'hôte : deuxième zone de disponibilité	Non requis	Obligatoire Passerelle hautement disponible dans la deuxième zone de disponibilité de l'instance
RTEP Edge	Requis pour la fédération NSX uniquement Passerelle hautement disponible dans l'instance	Requis pour la fédération NSX uniquement Doit être étendu dans l'instance Passerelle hautement disponible dans les zones de disponibilité de l'instance
Gestion et témoin : dispositif témoin à un troisième emplacement	Non requis	Obligatoire Passerelle hautement disponible à l'emplacement du témoin

Tableau 3. VLAN et sous-réseaux pour les déploiements sur plusieurs racks avec VMware Cloud Foundation

Fonction	Instances de VMware Cloud Foundation avec un cluster de domaine de charge de travail VI de calcul sur plusieurs racks	Instances de VMware Cloud Foundation avec disponibilité de NSX Edge sur plusieurs racks
Gestion des VM	Non requis en tant que calcul uniquement	Requis en cas de séparation de la gestion des hôtes Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack
Gestion des hôtes	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack
vSphere vMotion	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack
vSAN	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack	Requis par rack si vous utilisez vSAN Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack
Superposition de l'hôte	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack
NFS	Non pris en charge	Requis si vous utilisez NFS comme stockage principal pour les clusters avec les nœuds NSX Edge.
Liaison montante 01	Non requis	Requis par rack
Liaison montante 02	Non requis	Requis par rack
Superposition du dispositif Edge	Non requis	Requis par rack Passerelle hautement disponible sur les nœuds ToR commutés ou feuilles dans le rack

Conditions requises et recommandations en matière de conception de réseau physique feuille-tronc pour VMware Cloud Foundation

Feuille-tronc est la topologie de déploiement réseau du centre de données par défaut utilisée pour VMware Cloud Foundation. Tenez compte de la bande passante réseau, de la configuration des ports de jonction, des trames Jumbo et de la configuration du routage pour NSX dans un déploiement comportant une ou plusieurs instances de VMware Cloud Foundation.

Conception logique du réseau physique feuille-tronc

Chaque hôte ESXi dispose d'une connectivité redondante aux commutateurs ToR (Top-of-Rack) de l'infrastructure réseau SDDC à l'aide d'au moins deux ports avec une vitesse recommandée de 25 GbE au minimum. Les commutateurs ToR sont configurés pour fournir tous les VLAN nécessaires à l'aide d'une jonction 802.1Q. Ces connexions redondantes utilisent des fonctionnalités dans vSphere Distributed Switch et NSX pour garantir qu'aucune interface physique n'est dépassée et que des chemins redondants disponibles sont utilisés.

Figure 2. Conception logique du réseau physique feuille-tronc

Conditions requises et recommandations en matière de conception de réseau physique feuille-tronc

Les conditions requises et les recommandations pour la configuration du réseau feuille-tronc déterminent la disposition physique et l'utilisation des VLAN. Elles incluent également des conditions requises et des recommandations sur les trames Jumbo, et sur les exigences liées au réseau, telles que DNS, NTP et le routage.

Tableau 4. Conditions requises pour la conception de réseau physique feuille-tronc pour VMware Cloud Foundation

ID de conditions requises	Conditions requises pour la conception	Justification	Implication
VCF-NET-REQD-CFG-001	N'utilisez pas la configuration EtherChannel (LAG, LACP ou vPC) pour les liaisons montantes de l'hôte ESXi.	Simplifie la configuration des commutateurs Top-of-Rack. Les options d'association disponibles avec vSphere Distributed Switch fournissent l'équilibrage de charge et le basculement. Les mises en œuvre EtherChannel peuvent présenter des limitations propres au fournisseur.	Aucun.
VCF-NET-REQD-CFG-002	Utilisez des VLAN pour séparer les fonctions de réseau physique.	Prend en charge la connectivité réseau physique sans nécessiter de nombreuses cartes réseau. Isole les différentes fonctions réseau dans le SDDC afin que vous puissiez disposer de services différenciés et hiérarchiser le trafic si nécessaire.	Nécessite une configuration et une présentation uniformes sur toutes les jonctions mises à la disposition des hôtes ESXi.
VCF-NET-REQD-CFG-003	Configurez les VLAN comme membres d'une jonction 802.1Q.	Tous les VLAN deviennent disponibles sur les mêmes adaptateurs réseau physiques sur les hôtes ESXi.	Le VLAN de gestion peut éventuellement agir en tant que VLAN natif.
VCF-NET-REQD-CFG-004	Définissez la taille de la MTU sur au moins 1 700 octets (9 000 octets recommandés pour les trames Jumbo) sur les ports de commutateur physique, les commutateurs vSphere Distributed Switch, les groupes de ports vSphere Distributed Switch et les commutateurs N-VDS qui prennent en charge les types de trafic suivants : Superposition (Geneve) vSAN vSphere vMotion	Améliore le débit du trafic. Prend en charge Geneve en augmentant la taille de MTU à un minimum de 1 600 octets. Geneve est un protocole extensible. La taille de la MTU peut augmenter avec les capacités futures. Bien que 1 600 octets soient suffisants, une taille de MTU de 1 700 octets offre plus d'espace pour augmenter la taille de la MTU Geneve sans avoir à modifier la taille de MTU de l'infrastructure physique.	Lors de l'ajustement de la taille des paquets MTU, vous devez également configurer l'intégralité du chemin réseau (adaptateurs réseau VMkernel, commutateurs virtuels, commutateurs physiques et routeurs) pour prendre en charge la même taille des paquets MTU. Dans un environnement comportant plusieurs zones de disponibilité, la MTU doit être configurée sur l'intégralité du chemin réseau entre les zones.

Tableau 5. Conditions requises pour la conception de réseaux physiques feuille-tronc pour le cluster de domaine de charge de travail VI de calcul sur plusieurs racks pour VMware Cloud Foundation

ID de conditions requises	Conditions requises pour la conception	Justification	Implication
VCF-NET-L3MR-REQD-CFG-001	Pour un cluster de domaine de charge de travail VI de calcul sur plusieurs racks, fournissez des VLAN distincts par rack pour chaque fonction réseau. Gestion des hôtes vSAN vSphere vMotion Superposition de l'hôte	Une infrastructure feuille-tronc de couche 3 possède une limite de couche 3 au niveau des commutateurs feuilles dans chaque rack créant une limite de couche 3 entre les racks.	Nécessite des VLAN supplémentaires pour chaque rack.
VCF-NET-L3MR-REQD-CFG-002	Pour un cluster de domaine de charge de travail VI de calcul sur plusieurs racks, les sous-réseaux de chaque réseau par rack doivent être routables et accessibles aux commutateurs feuilles dans les autres racks. Gestion des hôtes vSAN vSphere vMotion Superposition de l'hôte	Garantit la circulation du trafic de chaque réseau entre les racks.	Nécessite une configuration réseau physique supplémentaire pour rendre les réseaux routables entre les racks.

Tableau 6. Conditions requises pour la conception de réseau physique feuille-tronc pour la fédération NSX dans VMware Cloud Foundation

ID de conditions requises	Conditions requises pour la conception	Justification	Implication
VCF-NET-REQD-CFG-005	Définissez la taille de MTU sur au moins 1 500 octets (1 700 octets préférés ; 9 000 octets recommandés pour les trames Jumbo) sur les composants du réseau physique entre les instances de VMware Cloud Foundation pour les types de trafic suivants. RTEP NSX Edge	Les trames Jumbo ne sont pas requises entre les instances de VMware Cloud Foundation. Toutefois, une MTU accrue améliore le débit du trafic. L'augmentation de la MTU RTEP à 1 700 octets réduit la fragmentation des paquets de charge de travail de taille standard entre les instances de VMware Cloud Foundation.	Lors de l'ajustement de la taille des paquets MTU, vous devez également configurer l'intégralité du chemin réseau, c'est-à-dire les interfaces virtuelles, les commutateurs virtuels, les commutateurs physiques et les routeurs pour prendre en charge la même taille des paquets MTU.
VCF-NET-REQD-CFG-006	Assurez-vous que la latence entre les instances de VMware Cloud Foundation connectées dans une fédération NSX est inférieure à 500 ms.	La fédération NSX nécessite une latence inférieure à 500 ms.	Aucun.
VCF-NET-REQD-CFG-007	Fournissez une connexion routée entre les clusters NSX Manager dans les instances de VMware Cloud Foundation connectées dans une fédération NSX.	La configuration de la fédération NSX nécessite une connectivité entre les instances du gestionnaire global NSX, les instances du gestionnaire local NSX et les clusters NSX Edge.	Vous devez attribuer des adresses IP routables uniques pour chaque domaine de pannes.

Tableau 7. Recommandations en matière de conception de réseau physique feuille-tronc pour VMware Cloud Foundation

ID de recommandation	Recommandation en matière de conception	Justification	Implication
VCF-NET-RCMD-CFG-001	Utilisez deux commutateurs ToR pour chaque rack.	Prend en charge l'utilisation de deux liaisons 10 GbE (au moins 25 GbE recommandés) vers chaque serveur, fournit une redondance et réduit la complexité globale de la conception.	Nécessite deux commutateurs ToR par rack, ce qui peut augmenter les coûts.
VCF-NET-RCMD-CFG-002	Mettez en œuvre l'architecture réseau physique suivante : Au moins un port de 25 GbE (10 GbE minimum) sur chaque commutateur ToR pour les liaisons montantes de l'hôte ESXi (hôte vers ToR). Périphérique de couche 3 prenant en charge BGP.	Fournit la disponibilité lors d'une panne de commutateur. Fournit la prise en charge du protocole de routage dynamique BGP	Peut limiter les choix de matériel. Nécessite la configuration du protocole de routage dynamique dans le réseau physique.
VCF-NET-RCMD-CFG-003	Utilisez un réseau physique configuré pour la contiguïté de routage BGP.	Prend en charge la flexibilité de conception pour le routage de charges de travail multisite et mutualisée. BGP est le seul protocole de routage dynamique pris en charge pour la fédération NSX. Prend en charge le basculement entre les liaisons montantes ECMP Edge.	Nécessite une configuration BGP dans le réseau physique.
VCF-NET-RCMD-CFG-004	Attribuez des configurations d'adresses IP persistantes pour les points de terminaison de tunnel (TEP) NSX qui utilisent l'adressage des pools d'adresses IP dynamiques plutôt que celui des pools d'adresses IP dynamiques.	Garantit que les points de terminaison disposent d'une adresse IP TEP persistante. Dans VMware Cloud Foundation, l'attribution d'adresses IP de TEP à l'aide de pools d'adresses IP statiques est recommandée pour toutes les topologies. Cette configuration supprime toutes les conditions requises pour les services DHCP externes.	L'ajout d'hôtes supplémentaires au cluster peut nécessiter l'augmentation des pools d'adresses IP statiques.
VCF-NET-RCMD-CFG-005	Configurez les ports de jonction connectés aux cartes réseau ESXi comme PortFast de jonction.	Réduit le délai de transition des ports vers l'état de transfert.	Bien que cette conception n'utilise pas le protocole STP, celui-ci est généralement configuré par défaut sur les commutateurs.
VCF-NET-RCMD-CFG-006	Configurez VRRP, HSRP ou une autre méthode de disponibilité de passerelle de couche 3 pour ces réseaux. Gestion Superposition du dispositif Edge	Garantit que les VLAN étendus entre les zones de disponibilité sont connectés à une passerelle hautement disponible. Sinon, une panne dans la passerelle de couche 3 entraîne une interruption du trafic dans la configuration SDN.	Nécessite la configuration d'une technologie haute disponibilité pour les passerelles de couche 3 dans le centre de données.
VCF-NET-RCMD-CFG-007	Utilisez des VLAN distincts pour les fonctions réseau de chaque cluster.	Réduit la taille du domaine de diffusion de couche 2 à un cluster vSphere unique.	Augmente le nombre global de VLAN requis pour une instance de VMware Cloud Foundation.

Tableau 8. Recommandations en matière de conception de réseaux physiques feuille-tronc pour la montée en charge et les performances du dispositif Edge dédié de VMware Cloud Foundation

ID de recommandation	Recommandation en matière de conception	Justification	Implication
VCF-NET-DES-RCMD-CFG-001	Mettez en œuvre l'architecture réseau physique suivante : Deux ports de 100 GbE sur chaque commutateur ToR pour les liaisons montantes de l'hôte ESXi (hôte vers ToR). Périphérique de couche 3 prenant en charge BGP.	Prend en charge les conditions requises pour la bande passante élevée et les paquets par seconde pour les déploiements à grande échelle.	Nécessite des commutateurs réseau de 100 GbE.

Tableau 9. Recommandations en matière de conception de réseau physique feuille-tronc pour la fédération NSX dans VMware Cloud Foundation

ID de recommandation	Recommandation en matière de conception	Justification	Implication
VCF-NET-RCMD-CFG-008	Fournissez le routage BGP entre toutes les instances de VMware Cloud Foundation connectées dans une configuration de la fédération NSX.	BGP est le protocole de routage pris en charge pour la fédération NSX.	Aucun.
VCF-NET-RCMD-CFG-009	Assurez-vous que la latence entre les instances de VMware Cloud Foundation connectées dans une fédération NSX est inférieure à 150 ms pour la mobilité des charges de travail.	Une latence inférieure à 150 ms est requise pour les fonctionnalités suivantes : Cross-vCenter Server vMotion	Aucun.