Mise en réseau sous-jacent

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.

Fin de la commercialisation: à compter du 17 juillet 2025, les nouveaux déploiements d'instances VMware Regulated Workloads ne seront plus disponibles pour les nouveaux clients. Si vous êtes un client existant, vous pouvez toujours ajouter ou supprimer des clusters, ajouter ou supprimer VMware ESXi™ servers or NFS storage, et ajouter ou supprimer des services pour vos instances Regulated Workloads existantes. En tant que client existant, vous pouvez également consulter ou supprimer vos instances Regulated Workloads.

IBM Cloud® for VMware® Regulated Workloads nécessite un réseau isolé entre les clusters de charge de travail et les clusters de gestion et de passerelle.

Cluster de gestion

Le cluster de gestion requiert deux réseaux VLAN pour prendre en charge les fonctions de gestion.

Un réseau VLAN inclut des sous-réseaux pour la gestion ESXi (vmk0) et des services de gestion comme vCenter Server. Le dispositif de passerelle établit des zones de sécurité et des règles pour contrôler le flux de trafic dans le réseau VLAN entre les sous-réseaux. Le trafic non sollicité provenant des hôtes ESXi ou bare metal ne peut pas accéder aux systèmes de gestion. La passerelle Edge Gateway contrôle le flux de trafic depuis ces deux sous-réseaux vers toute autre zone se trouvant hors de la région de gestion.

Le second réseau VLAN inclut des sous-réseaux qui sont dédiés à vMotion et vSAN. Aucun routage entre ces sous-réseaux n'est autorisé et le réseau local virtuel est isolé par la passerelle de périmètre à partir de toutes les autres zones de sécurité et réseaux dans un déploiement à une seule zone.

Cluster de passerelles

Le cluster de passerelles optionnel ajoute deux VLAN de réseau de transit à la solution. Ces VLAN connectent le dispositif vSRX à la fois au routeur BCR (Back-end Customer Router) pour le trafic privé et au routeur FCR (Front-end Customer Router) pour les flux de trafic public (Internet). Lorsqu'un déploiement privé uniquement est souhaité, le VLAN de transit public n'est pas commandé. Le VLAN de gestion est relié à la grappe de passerelles.

La conception du réseau est réalisée de sorte à permettre au dispositif vSRX de contrôler les flux de trafic au sein de la zone de gestion et entre la zone de gestion et les réseaux privés et publics IBM Cloud®. Le transit de l'appliance FortiGate et la conception du réseau VLAN sont les mêmes que ceux utilisés avec le cluster de passerelles.

Le site vSRX, qui fonctionne sur la grappe de passerelles, relie le réseau de gestion aux réseaux de transit privé et public. Il est configuré pour n'autoriser le trafic que vers ou hors de la région de gestion nécessaire au bon fonctionnement et à la surveillance de l'environnement. Le site vSRX isole également tout le trafic entre les hôtes ESXi et le serveur vCenter. Les hôtes ESXi d'un cluster peuvent communiquer entre eux et avec le vCenter Server. Les hôtes ESXi d'un cluster (charge de travail ou gestion, par exemple) ne sont pas en mesure de communiquer avec les hôtes d'autres clusters. La limitation du trafic inter-cluster est appliquée par vSRX et par la configuration des pare-feux des hôtes ESXi.

Le cluster de la passerelle est le point de peering pour le trafic entre le fournisseur de SaaS sur site et le Regulated Workloads. Il sert également de démarcation pour le trafic provenant du consommateur SaaS. Le fournisseur SaaS utilise vSRX comme noeud final de tunnel sécurisé pour son VPN.

Le trafic depuis le consommateur SaaS passe par le dispositif vSRX dans un tunnel chiffré, qui se trouve sur l'unité de périphérie virtuelle de réseau superposé.

Cluster de charge de travail

La conception du réseau de cluster de charge de travail est étroitement liée à celle d'un déploiement vCenter Server traditionnel. Les VLAN et les sous-réseaux sont provisionnés pour prendre en charge vMotion, vSAN, TEP pour le réseau SDN (Software-Defined Networking) et les fonctions de gestion des hôtes des clusters de charge de travail.

Au sein des clusters de charge de travail, NSX® fournit un réseau défini par logiciel hautement sécurisé et flexible pour prendre en charge les exigences de l'application. La gestion NSX est externe au cluster de charge de travail, ce qui garantit que les changements de réseau et de sécurité ne sont pas possibles par d'autres que les administrateurs désignés. Tous les accès réseau nord-sud dans le cluster de charge de travail sont effectués via des connexions privées et sécurisées à l'aide d'IPsec ou d'IBM Direct Link. Les clusters de charge de travail sont protégés par le même cluster de passerelle que le site vSRX ou le site physique FortiGate qui protège le plan de gestion.

IBM Cloud mise en réseau

Le réseau physique d'IBM Cloud est divisé en deux réseaux distincts : public et privé. Le réseau privé contient également le trafic de gestion de l'interface IPMI (Intelligent Platform Management Interface) vers les serveurs physiques.

IBM Cloud réseau de haut niveau réseau de haut niveau réseau de haut niveau
IBM Cloud

Réseau public

Les centres de données et les points de présence (PoP) réseau d'IBM Cloud sont dotés de plusieurs connexions 1 Gbit/s ou 10 Gbit/s aux opérateurs réseau d'appairage et de transit de premier plan. Le trafic réseau n'importe où dans le monde se connecte au PoP de réseau le plus proche et passe par le réseau directement vers son centre de données. Ainsi, le nombre de segments réseau et de relais entre les fournisseurs est réduit.

A l'intérieur du centre de données, IBM Cloud fournit 1 Gbit/s ou 10 Gbit/s de bande passante réseau à des serveurs individuels via une paire de commutateurs FCS (Front-end Customer Switch) distincts et agrégés par homologue. Ces commutateurs agrégés sont connectés à une paire de routeurs (FCR) distincts pour la mise en réseau L3.

Cette conception multiniveau permet la mise à l'échelle du réseau dans des armoires, des lignes et des pods au sein d'un centre de données IBM Cloud.

Réseau privé

Tous les centres de données IBM Cloud et PoP sont connectés par le réseau principal privé. Le réseau privé est distinct du réseau public et permet la connectivité aux services dans des centres de données IBM Cloud situés dans le monde entier. Le transfert de données entre les centres de données IBM Cloud s'effectue par plusieurs connexions 10 Gbit/s ou 40 Gbit/s au réseau privé.

Similaire au réseau public, le réseau privé est multiniveau, en ce sens que les serveurs et les autres composants d'infrastructure sont connectés à des commutateurs BCS (Backend Customer Switch) agrégés. Ces commutateurs agrégés sont connectés à une paire de routeurs BCR (Back-end Customer Router) distincts pour la mise en réseau L3. Le réseau privé prend également en charge l'utilisation de trames jumbo (MTU 9000) pour des connexions hôte physiques.

Réseau de gestion

Outre les réseaux public et privé, chaque serveur IBM Cloud est connecté pour la gestion au sous-réseau du réseau privé principal. Cette connexion permet un accès IPMI (Intelligent Platform Management Interface) au serveur, quels que soient son unité centrale, son microprogramme et son système d'exploitation, à des fins de maintenance et d'administration.

Blocs d'adresses IP principales et portables

IBM Cloud alloue deux types d'adresses IP à utiliser dans l'infrastructure IBM Cloud :

  • Les adresses IP principales sont affectées aux unités, aux serveurs bare metal et aux serveurs virtuels qui sont mis à disposition par IBM Cloud. Vous ne devez pas affecter manuellement d'adresses IP dans ces blocs.
  • Des adresses IP portables vous sont fournies et vous pouvez les affecter et les gérer en fonction de vos besoins. L'automatisation IBM Cloud for VMware Regulated Workloads met à disposition plusieurs plages d'adresses IP portables à cet effet. Utilisez uniquement les plages d'adresses IP portables qui sont attribuées à des composants NSX spécifiques et spécifiées pour l'utilisation par le fournisseur SaaS.

Les adresses IP principales ou portables peuvent devenir routables vers n'importe quel réseau local virtuel (VLAN) au sein de votre compte lorsque celui-ci est configuré en tant que compte VRF (Virtual Routing and Forwarding).

Compte VRF (Virtual Routing and Forwarding)

Le compte d'infrastructure IBM Cloud doit être configuré en tant que compte VRF (Virtual Routing and Forwarding), ce qui permet un routage global automatique entre les blocs d'adresses IP de sous-réseau. Tous les comptes dotés de connexions Direct Link doivent être créés ou convertis en compte VRF.

Comme diverses options de connectivité et de routage réseau exigent que le compte IBM Cloud soit en mode VRF, il est recommandé que le compte soit en mode VRF avant de provisionner le compte Regulated Workloads.

Connexions d'hôte physique

Chaque hôte physique de cette structure possède deux paires redondantes de connexions Ethernet 10 Gbit/s dans chaque commutateur IBM Cloud de niveau supérieur (ToR) (public et privé). Les adaptateurs sont configurés comme des connexions individuelles (non liées) pour un total de 4 connexions 10 Gbit/s. Cette configuration permet aux connexions de carte d'interface réseau (NIC) de fonctionner indépendamment les unes des autres.

Il est impossible de retirer la connectivité de réseau physique au réseau public ou privé pour les serveurs bare metal qui sont utilisés dans l'offre vCenter Server. Les ports physiques de la carte NIC interne du serveur bare metal peuvent être désactivés, mais il n'existe aucun support concernant le débranchement des câbles. Cette configuration, parfois appelée "air gap", englobe les actions nécessaires à la désactivation des ports réseau côté public des hôtes ESXi et des ports ToR pour ces connexions et à la configuration d'IBM Cloud IAM pour empêcher quiconque ne disposant pas de privilèges suffisants d'activer les connexions. De plus, le VLAN public côté client est affecté au dispositif de passerelle Edge Gateway et sécurisé pour empêcher tout trafic en provenance et à destination du VLAN public. La passerelle et les connexions de passerelle vers le VLAN de transit public (le cas échéant) sont aussi administrativement interrompues (et non pas déconnectées), permettant ainsi de surveiller toute tentative de trafic en sortie et en entrée sur le VLAN de transit public vers et depuis le routeur FCR.

Bien que IBM Cloud offre une option SSL VPN, cette option est déconseillée et strictement limitée aux situations où l'accès hors bande aux charges de travail réglementées est essentiel.

![Connexions physiques de l'hôte* "){: caption="](../../images/vrw-v2-net-physical.svg "de l'hôte* Connexions physiques de l'hôte* " caption-side="bottom"} physiques de l'hôte*

Réseaux locaux virtuels (VLAN) et routage du réseau sous-jacent au réseau superposé

Les offres VMware Solutions sont conçues avec trois VLAN, un public et deux privés, attribués lors du déploiement. Comme le montre la figure précédente, le VLAN public est affecté à eth1 et à eth3, et les VLAN privés sont affectés à eth0 et eth2.

Par défaut, le VLAN public et le premier VLAN privé créés et affectés dans cette conception ne sont pas balisés dans IBM Cloud. Ensuite, le VLAN privé supplémentaire est partagé sur les ports de commutation physiques et balisé dans les groupes de ports VMware qui utilisent ces sous-réseaux.

![Connexions VLAN* Connexions](../../images/vrw-v2-net-physical-vlans.svg "Connexions VLAN* " caption-side="bottom"}"){: caption="

Le réseau privé est composé de deux réseaux locaux virtuels (VLAN) dans cette conception. Trois sous-réseaux sont alloués au premier de ces réseaux locaux virtuels (appelé ici VLAN privé A) :

  • Le premier sous-réseau est une plage de sous-réseaux d'adresses IP privées principales affectées par IBM Cloud aux hôtes physiques.
  • Le deuxième sous-réseau est utilisé pour les machines virtuelles (VM) de gestion telles que vCenter Server Appliance et Platform Services Controller (PSC).
  • Le troisième sous-réseau est utilisé pour les points de terminaison des tunnels du réseau superposé encapsulé (TEP) attribués à chaque hôte par l'intermédiaire du NSX Manager.

En plus du réseau VLAN privé A, il existe un deuxième réseau VLAN privé (VLAN privé B, ici) pour prendre en charge les fonctionnalités VMware, telles que vSAN et vMotion. Ainsi, le réseau VLAN est divisé en deux sous-réseaux portables ou plus :

  • Le premier sous-réseau est affecté à un groupe de ports de noyau pour le trafic vMotion.
  • Le ou les sous-réseaux restants sont utilisés pour le trafic de stockage. Lorsque vous utilisez vSAN,, un sous-réseau est affecté aux groupes de ports du noyau qui sont utilisés pour le trafic vSAN.

Le réseau public est constitué d'un réseau VLAN dans cette structure. Les sous-réseaux suivants sont alloués à ce VLAN :

  • Le premier sous-réseau est une plage de sous-réseaux IP primaires que IBM Cloud affecte aux hôtes physiques.
  • Une adresse IP publique est attribuée aux hôtes, mais cette adresse IP n'est pas configurée sur les hôtes. Ils ne sont donc pas directement accessibles sur le réseau public.
  • Le second sous-réseau est utilisé pour l'accès public des composants comme un dispositif de passerelle virtuelle.
  • Le VLAN public est destiné à fournir un accès public à Internet.

Tous les sous-réseaux configurés dans le cadre du déploiement automatisé des charges de travail réglementées utilisent des plages gérées par IBM Cloud pour garantir que toute adresse IP peut être acheminée vers n'importe quel centre de données au sein de IBM Cloud.

Voir le tableau suivant pour un récapitulatif.

Résumé du VLAN et du sous-réseau
VLAN Type Description
Public C Principal Affecté à des hôtes physiques pour l'accès au réseau public.
Privé A Principal Sous-réseau unique affecté aux hôtes physiques affectés par IBM Cloud. Utilisé par l'interface de gestion pour le trafic de gestion vSphere.
Privé A Portable Sous-réseau unique affecté aux machines virtuelles qui fonctionnent comme des composants de gestion
Privé A Portable Sous-réseau unique attribué à NSX TEP
Privé B Portable Sous-réseau unique affecté pour vSAN, si utilisé.
Privé B Portable Sous-réseau unique affecté pour NAS, si utilisé.
Privé B Portable Sous-réseau unique affecté pour vMotion.

Dans cette structure, toutes les machines virtuelles et hôtes VLAN sont configurés pour pointer vers la passerelle Edge Gateway comme route par défaut. Bien que les instances Regulated Workloads permettent l'utilisation du SDN, les superpositions de réseaux créées au sein d'une instance VMware qui incluent le routage vers des sous-réseaux internes ne sont pas connues par la passerelle de périmètre, à moins que des protocoles de routage dynamique ou des routes statiques ne soient configurés.

Les connexions de réseau privé sont configurées pour utiliser 9000 comme taille MTU de trame jumbo afin d'améliorer les performances des transferts d'importantes quantités de données, comme le stockage et vMotion. Il s'agit de la valeur MTU maximale autorisée dans VMware et par IBM Cloud. Les connexions de réseau public utilisent 1500 comme taille MTU Ethernet standard, cette valeur devant être conservée, car tout changement peut provoquer une fragmentation des paquets sur Internet.