IBM Cloud Docs
Conception de l'infrastructure virtuelle

Conception de l'infrastructure virtuelle

La couche d'infrastructure virtuelle inclut les composants logiciels VMware® qui virtualisent les ressources de calcul, de stockage et de réseau fournies dans la couche d'infrastructure physique : VMware vSphere ESXi®, VMware NSX-T™ et en option VMware vSAN™.

Infrastructure virtuelle
Figure 1. Infrastructure virtuelle

Conception de VMware vSphere

La configuration de vSphere ESXi comprend les aspects suivants :

  • Configuration d'amorçage
  • Synchronisation de temps
  • Accès à l'hôte
  • Accès utilisateur
  • Configuration DNS

Le tableau ci-après présente les spécifications de chaque aspect. Après la configuration et l'installation d'ESXi, l'hôte est ajouté à une instance VMware vCenter Server® et est géré depuis cette instance.

Cette conception vous permet d'accéder aux hôtes virtuels via l'interface DCUI (Direct Console User Interface) et vSphere Web Client. Après la mise à disposition, Secure Shell (SSH) et ESXi Shell sont désactivés conformément aux pratiques recommandées.

Par défaut, les seuls utilisateurs qui peuvent se connecter directement sont les utilisateurs Racine et Ibmvmadmin pour la machine physique de l'hôte. L'administrateur peut ajouter des utilisateurs à partir du domaine MSAD (Microsoft® Active Directory™) pour permettre l'accès utilisateur à l'hôte. Tous les hôtes de la solution VMware Cloud Foundation for Classic - Automated sont configurés pour se synchroniser avec un serveur NTP central.

configuration devSphere ESXi
Attribut Paramètre de configuration
Emplacement de l'amorçage ESXi

Différentes configurations d'hôtes peuvent être déployées avec:

  • Des disques locaux configurés avec RAID-1
  • Une paire de M.2 lecteurs de démarrage dans une configuration en miroir
  • Un seul M.2 lecteur de démarrage
Synchronisation de temps Utilisation du serveur NTP IBM Cloud®
Accès à l'hôte Prend en charge l'interface DCUI. SSH et ESXi Shell sont prises en charge mais ne sont pas activées par défaut
Accès utilisateur Authentification locale et MSAD
Résolution de nom de domaine Utilisation de DNS comme indiqué dans Conception des services communs.
Mode EVC Niveau le plus élevé disponible pris en charge par la version vSphere. Cependant, pour un cluster de gestion avec des processeurs Intel® Cascade Lake, aucun EVC n'est défini car l'EVC Cascade Lake n'est pas pris en charge par la version de vSphere.

Le cluster vSphere héberge les machines virtuelles (VM) qui gèrent l'instance VMware Cloud Foundation for Classic - Automated et les ressources de calcul pour les charges de travail des utilisateurs.

  • Lorsqu'une instance VMware Cloud Foundation for Classic - Automated utilise vSAN, nombre minimum d'hôtes ESXi lors du déploiement initial est de quatre.
  • Lorsqu'une instance VMware Cloud Foundation for Classic - Automated utilise un stockage partagé au niveau des fichiers ou des blocs, le nombre minimum d'hôtes ESXi lors du déploiement initial est de trois.

Vous pouvez déployer jusqu'à 20 hôtes ESXi dans ce cluster lors du déploiement initial. Après le déploiement initial, vous pouvez étendre le cluster jusqu'à un maximum de 50 hôtes par incréments de 20 hôtes au plus à la fois.

Pour prendre en charge davantage de charges de travail utilisateur, vous pouvez effectuer une mise à l'échelle de l'environnement en :

  • Déployant d'autres hôtes de calcul dans des clusters existants.
  • Déployant d'autres clusters gérés par le même dispositif vCenter Server.
  • Déploiement de nouvelles instances VMware Cloud Foundation for Classic - Automated avec leur propre appliance vCenter Server.

Conception de VMware vSAN

Dans cette conception, le stockage VMware vSAN est utilisé dans les instances VMware Cloud Foundation for Classic - Automated pour fournir un stockage partagé aux hôtes vSphere.

Comme illustré dans la figure suivante, vSAN agrège le stockage local sur plusieurs hôtes ESXi dans un cluster vSphere et gère le stockage agrégé comme un seul magasin de données de machine virtuelle. Avec cette conception, les noeuds de traitement contiennent les unités de disque local pour le système d'exploitation ESXi et le magasin de données vSAN.

Différentes configurations d'hôtes peuvent être déployées :

  • Disques locaux configurés avec RAID-1
  • Une paire de disques d'amorçage M.2 dans une configuration en miroir
  • Un seul disque de démarrage M.2

concept vSAN
concept vSAN

vSAN emploie les composants suivants :

  • Conception vSAN avec deux groupes de disques ; chaque groupe de disques est composé d'au moins deux disques. L'unité SSD ou NVMe la plus petite dans le groupe sert de niveau de cache et les autres unités SSD servent de niveau de capacité.
  • Le contrôleur RAID intégré est configuré dans une grappe RAID 0 pour chaque unité individuelle qui est utilisée pour le cache ou la capacité vSAN.
  • Un seul magasin de données vSAN est créé à partir de toutes les unités de stockage.

Configuration de réseau virtuel pour vSAN

Pour cette conception, le trafic vSAN parcourt les hôtes ESXi sur un réseau local privé dédié. Les deux adaptateurs de réseau connectés au commutateur de réseau privé sont configurés dans vSphere sous la forme d'un commutateur vDS avec les deux adaptateurs de réseau sous la forme de liaisons montantes. Un groupe de ports de noyau vSAN dédié qui est configuré pour le réseau local virtuel vSAN réside dans le commutateur vDS. Les trames Jumbo (MTU 9000) sont activées pour le commutateur vDS privé.

vSAN ne procède pas à l'équilibrage de charge du trafic entre les liaisons montantes. Par conséquent, un adaptateur est actif tandis que l'autre est en veille pour assurer la haute disponibilité. La règle de reprise par transfert configurée pour vSAN entre les ports de réseau physique est Basculement explicite.

Pour plus d'informations sur les connexions NIC physiques, voir Connexions NIC hôte physiques.

Conception de règles vSAN

Lorsque vSAN est activé et configuré, des règles de stockage sont configurées pour définir les caractéristiques de stockage de machine virtuelle. Les caractéristiques de stockage spécifient différents niveaux de service pour différentes machines virtuelles.

Les règles de stockage définies par défaut dans cette conception ne tolèrent qu'une seule panne. La règle par défaut est configurée avec la codification de l'effacement, avec la mméthode de tolérance d'échec défini sur RAID-5/6 (codification de l'effacement) - Capacité et Niveau primaire des échecs défini sur 1. La configuration RAID 5 requiert au moins quatre hôtes.

Sinon, vous pouvez choisir la configuration RAID 6, avec la valeur Niveau-5/6 (Codage d'effacement) - Capacité affectée à Méthode de tolérance aux défaillances et la valeur 2 affectée à Niveau principal des pannes. La configuration RAID 6 requiert au moins six hôtes. Normalement, les options Dédoublonnage et compression sont activées dans la règle de stockage par défaut, mais vous pouvez les désactiver si nécessaire.

Une instance utilise les règles par défaut sauf indication contraire à partir de la console vSphere. Lorsqu'une stratégie personnalisée est configurée, elle est garantie par vSAN, si possible. Toutefois, si la stratégie ne peut pas être garantie, il n'est pas possible de mettre à disposition une machine virtuelle qui utilise cette stratégie, sauf si la mise à disposition peut être forcée.

Les règles de stockage doivent être réappliquées après l'ajout de nouveaux hôtes ESXi ou l'application de modules de correction aux hôtes ESXi.

Paramètres vSAN

Les paramètres vSAN sont définis selon les meilleures pratiques relatives au déploiement de solutions VMware dans IBM Cloud. Ils incluent les paramètres SIOC, le groupe de ports des paramètres de basculement explicite et les paramètres de cache-disque.

  • Paramètres de règle de cache SSD - NRWTD (No Read Ahead, Write Through, Direct)
  • Paramètres de contrôle d'E-S de réseau
    • Gestion - 20 partages
    • Machine virtuelle - 30 partages
    • vMotion - 50 partages
    • vSAN - 100 partages
  • Ports de noyau vSAN - Basculement explicite

Stockage NFS connecté

Les migrations LIF du serveur NFS peuvent entraîner un temps d'attente excessif lorsqu'elles utilisent NFS version 4.1. Lorsque vous utilisez un stockage connecté au réseau NFS, cette architecture prescrit l'utilisation de NFS version 3 au lieu de NFS version 4.1. Chaque hôte vSphere est connecté au stockage NFS à l'aide de son nom d'hôte.

Un magasin de données NFS 2 To est connecté à un cluster pour être utilisé par des composants de gestion avec un niveau de performance de IOPS/Go. D'autres magasins de données peuvent être connectés à un cluster pour l'utilisation de charge de travail, à différentes tailles et différents niveaux de performance.

De plus, cette architecture requiert que tous les hôtes disposent d'une route de sous-réseau créée pour le sous-réseau sur lequel réside le stockage NFS. Cette route de sous-réseau a pour objet de diriger tout le trafic NFS afin d'utiliser le groupe de ports, le sous-réseau et le VLAN conçus pour le trafic NFS. Si plusieurs magasins de données NFS sont connectés, il peut être nécessaire de configurer plusieurs routes car ces magasins de données peuvent se trouver dans différents sous-réseaux distants.

Les machines virtuelles de gestion peuvent être situées sur un magasin de données NFS. Cette approche crée un problème d'amorçage car certaines des machines de gestion peuvent être responsables des services DNS qui sont utilisés pour résoudre le nom d'hôte NFS. Par conséquent, cette architecture spécifie qu'au moins l'une des adresses IP pour le magasin de données de gestion doit être codée en dur dans /etc/hosts sur chacun des hôtes.