Réseau public

Les centres de données IBM Cloud et les points de présence (PoP) réseau 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 depuis n'importe quel endroit du monde se connecte au PoP de réseau le plus proche et transite directement par le réseau vers son centre de données, réduisant ainsi le nombre de segments réseau et de relais entre les fournisseurs.

Dans le centre de données, IBM Cloud fournit une bande passante du réseau de 1, 10 ou 25 Gbit/s à 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.

Gestion des hôtes

Sur le réseau privé, chaque serveur IBM Cloud est connecté pour la gestion via le sous-réseau principal privé. 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 d'adresses IP dans ces blocs.
• Des adresses IP portables que vous pouvez affecter et gérer, le cas échéant, sont fournies. Le serveur vCenter contient plusieurs plages d'adresses IP portables pour son utilisation. Utilisez uniquement les plages d'adresses IP portables affectées à des composants NSX®-T spécifiques et spécifiées pour être utilisées par les clients. Par exemple, Customer EDGE.

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).

Virtual Routing and Forwarding (VRF)

Le compte IBM Cloud infrastructure customer portal doit être configuré en tant que compte VRF (Virtual Routing and Forwarding) pour activer le 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.

Etant donné que diverses options de connectivité de même que des options de routage de réseau nécessitent que le compte IBM Cloud soit en mode VRF, il est préférable de placer le compte en mode VRF avant de mettre vCenter Server à disposition.

Connexions d'hôte physique

Chaque hôte physique de cette structure possède deux paires redondantes de connexions Ethernet 10 ou 25 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 ou 25 Gbit/s. Cette configuration permet aux connexions de carte NIC (Networking Interface Card) de fonctionner indépendamment les unes des autres.

Il n'est pas possible de supprimer la connectivité physique au réseau public ou privé pour les serveurs bare metal IBM Cloud utilisés dans le cadre de l'offre automatisée. 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.

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

Les offres IBM Cloud for VMware Solutions sont conçues avec 3 réseaux locaux virtuels, un VLAN public et deux VLAN privés, affecté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.

Le réseau privé est composé de deux réseaux locaux virtuels (VLAN) dans cette conception. Quatre 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 de gestion, telles que vCenter Server Appliance et NSX Controller.
• Le troisième sous-réseau est utilisé pour les points VTEP (VXLAN Tunnel Endpoint) de réseau superposé encapsulé affectés à chaque hôte et serveur de périphérie via NSX Manager.
• Le quatrième sous-réseau est utilisé pour la sortie depuis le réseau superposé encapsulé.

Outre le VLAN privé A, un second réseau local virtuel privé (désigné VLAN privé B ici) est disponible pour prendre en charge des fonctions VMware telles que vSAN™, vMotion et NFS. 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.
• Les autres sous-réseaux sont utilisés pour le trafic de stockage :
  • Si vous utilisez vSAN, un sous-réseau est affecté aux groupes de ports de noyau qui sont utilisés pour le trafic vSAN.
  • Si vous utilisez NAS connecté à un stockage NFS, un sous-réseau est affecté au groupe de ports qui est dédié au trafic NFS.

Tous les sous-réseaux configurés dans le cadre d'un déploiement VMware Cloud Foundation for Classic - Automated utilisent des plages gérées par IBM Cloud, ce qui garantit que n'importe quelle adresse IP peut être acheminée vers n'importe quel centre de données du compte IBM Cloud lorsque vous avez besoin de la connexion.

Voir le tableau suivant pour un récapitulatif.

Dans cette conception, tous les hôtes et toutes les machines virtuelles VLAN sont configurés pour pointer vers le routeur client (BCR) "réseau privé" de back-end IBM Cloud comme route par défaut. Alors que les instances automatisées permettent l'utilisation du Software-Defined Networking (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 les routeurs gérés par IBM Cloud.

Si vous souhaitez établir un itinéraire entre le réseau superposé et le réseau sous-jacent, vous devez déployer un dispositif de pare-feu IBM pour le VLAN privé par défaut en question lors du déploiement de l'instance automatisée. Ce dispositif permet l'insertion de routes statiques et de protocoles de routage dynamiques avec les dispositifs de mise en réseau superposés afin de permettre le routage entre le réseau sous-jacent et le réseau superposé.

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 doit être conservée ; tout changement peut provoquer une fragmentation des paquets sur Internet.