VMware vSphere est une plate-forme de virtualisation de VMware, qui transforme les centres de données en infrastructures informatiques agrégées incluant le CPU, le stockage et les ressources de mise en réseau. vSphere gère ces infrastructures sous forme d’environnement d’exploitation unifié et fournit les outils permettant d’administrer les centres de données qui participent à cet environnement.

Les deux principaux composants de vSphere sont ESXi et vCenter Server. ESXi est la plate-forme de virtualisation sur laquelle vous créez et exécutez des machines virtuelles et des dispositifs virtuels. vCenter Server est le service qui vous permet de gérer plusieurs hôtes connectés dans un réseau et les ressources d’hôtes dans un pool.

• Comprendre le fonctionnement de vSphere
• Apprendre à déployer une solution vSphere
• Mettre à jour une solution vSphere
• Configurer une solution vSphere (réseau, stockage, etc.)
• Mettre en place une banque de données avec VMFS un stockage SIOC
• Configuration de DRS, DPM et EVC
• Mettre en place une architecture haute disponibilité
• Gestion de profil et création d’images ESXi

Déploiement d’une nouvelle infrastructure vSphere 6.7

vSphere est une suite de solutions d’infrastructure de base qui constituent la base de tout centre de données moderne virtualisé à l’aide de VMware. La planification du déploiement de ces composants et de leur mise en œuvre est importante car elle constitue la base de toute autre solution.

vSphere comprend essentiellement l’hyperviseur (ESXi), vCenter Server et ses plug-ins, prenant en charge les bases de données et les agents de gestion d’hôte. Ces hyperviseurs créent une plate-forme pour exécuter des machines virtuelles (VM) et vCenter forme la couche de gestion. vCenter permet la création de centres de données virtuels. Toutes les autres solutions s’interfacent et interagissent avec vCenter pour gérer ou utiliser le centre de données virtuel. Par exemple, vRealize Automation, NSX et vRealize Operations interagissent avec vCenter.

Cela dit, VMware propose des API qui permettent aux développeurs de logiciels tiers de créer des outils qui aident à gérer les plates-formes ou à tirer parti de la couche de gestion formée par les serveurs vCenter dans un environnement. Par exemple, votre logiciel de sauvegarde interagit avec vCenter pour gérer les sauvegardes de machines virtuelles.

Les composants logiciels suivants constituent la base d’un environnement vSphere :

• Hyperviseur : VMware ESXi 6.7
• Logiciel de gestion de base : serveur VMware vCenter 6.7 et ses composants
• Logiciel de gestion des correctifs : VMware Update Manager 6.7

ESXi Hypervisor est la couche d’abstraction qui vous permet d’exécuter plusieurs instances de systèmes d’exploitation traditionnels en tant que VM partageant les mêmes ressources physiques. Avec chaque version majeure, la version 6.7 améliore la capacité de l’hyperviseur à évoluer, ainsi que d’autres nouvelles fonctionnalités. L’une des nouvelles fonctionnalités notables est le démarrage rapide. Contrairement aux versions précédentes, un redémarrage ne redémarre pas l’hôte; au lieu de cela, il redémarre uniquement l’hyperviseur, réduisant ainsi une quantité considérable de temps qui serait autrement nécessaire lors de l’initialisation du serveur.

Lisez le livre blanc QUOI DE NEUF DANS VMWARE vSPHERE 6.7 pour un bref aperçu de toutes les nouvelles fonctionnalités de vSphere 6.7 sur https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsphere/vmware- whats-new-in-vsphere-whitepaper.pdf.

Bien que le livre soit basé sur vSphere 6.7 U1, VMware a publié deux mises à jour supplémentaires après cela. Lisez les notes de publication de vSphere 6.7 U2 et U3 pour plus de détails.

vSphere 6.7 U2: https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-67u2-release-notes.html et https://docs.vmware.com/en/VMware- vSphere / 6.7 / rn / vsphere-vcenter-server-67u2-release-notes.html

vSphere 6.7U3: https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-67u3-release-notes.html et https://docs.vmware.com/en/VMware- vSphere / 6.7 / rn / vsphere-vcenter-server-67u3-release-notes.html

Logiciel de gestion de base – VMware vCenter Server 6.7 et ses composants :

Le vCenter Appliance avec vSphere 6.5 a été une amélioration significative et a vu un changement substantiel dans l’adoption de vCenter Server Appliance (VCSA). VCSA 6.5 / 6.7 est également évolutif, car la version Windows du vCenter, il va sans dire, est plus stable et plus facile à dépanner car tous les composants logiciels sont conditionnés pour fonctionner sur un système d’exploitation Linux léger appelé PHOTON OS (https: // vmware.github.io/photon/ ). En outre, VMware s’éloigne progressivement de sa dépendance à l’égard des systèmes de base de données Microsoft SQL et Oracle en utilisant une base de données basée sur PostgreSQL ( https://www.postgresql.org/ ) appelée vPostgres.

vSphere 6.7 sera la dernière version qui inclut une version Windows installable de vCenter. Toutes les futures versions de vCenter seront uniquement en tant qu’appliance (VCSA).

VMware a commencé à regrouper les services essentiels, tels que l’authentification unique, le service d’inventaire et la gestion des certificats, en un seul composant gérable appelé Platform Services Controller ( PSC ), à partir de vSphere 6.0. Avec les versions antérieures à vCenter 6.0 pour Windows, tous ces composants avaient des programmes d’installation individuels, ce qui leur permettait soit d’être installés sur la même machine que vCenter soit installés sur des machines distinctes. Par conséquent, il est devenu nécessaire de protéger et de gérer plusieurs machines virtuelles ou physiques exécutant Windows. Il a également rendu la mise à niveau et le dépannage fastidieux. Les regrouper sur la même machine Windows ou les déployer en tant qu’appliance a facilité la gestion et la mise à niveau de ces composants.

PSC peut être déployé en tant que machine virtuelle distincte (Windows / VCSA) ou rester en tant que composant intégré de VCSA. Depuis vSphere 6.7, le besoin d’un PSC externe est obsolète.

SSO est un composant serveur d’authentification intégré au PSC. Il agit comme une passerelle d’authentification et accepte les demandes d’authentification des composants enregistrés et valide la paire d’informations d’identification par rapport aux sources d’identité qui sont ajoutées au serveur SSO. Une fois authentifiés avec succès, ils reçoivent des jetons de sécurité pour les échanges d’authentification à l’avenir.

vCenter Update Manager ( VUM ) est utilisé pour mettre à niveau ou corriger un environnement vSphere. Il est principalement utilisé pour installer des correctifs ou effectuer des mises à niveau ESXi. Il peut effectuer des tâches supplémentaires, telles que la mise à niveau des outils VMware et la mise à niveau du matériel de la machine virtuelle. La solution est entièrement intégrée à vCenter Appliance et est activée par défaut.

Certificat vSphere Manager est un certificat intégré gestionnaire qui utilise l’autorité de certification VMware (VMCA) comme l’autorité par défaut émission.

VMware Licensing Service est un référentiel pour les informations de licence de tous les produits VMware qui fonctionnent avec PSC / vCenter. Les informations de licence sont répliquées entre les PSC qui se trouvent dans le même domaine SSO.

La base de données vCenter est la source de vérité pour vCenter. vCenter ne fonctionnera pas sans une connexion active à la base de données.

Dans ce chapitre, nous couvrirons les recettes suivantes :

• Installer ESXi – la méthode interactive
• Configuration du réseau de gestion ESXi
• Déploiement scripté d’ESXi
• Déploiement de vCenter Server Appliance (VCSA)
• Déploiement de vCenters dans une configuration Linked Mode
• Configuration des sources d’identité à authentification unique (SSO)
• Configuration des rôles et autorisations vCenter
• Joindre ESXi à un domaine Active Directory

Installer ESXi – la méthode interactive

VMware ESXi peut être installé de plusieurs manières. L’approche traditionnelle consiste à utiliser l’image du CD / DVD-ROM ESXi pour effectuer une installation interactive. Dans cette recette, nous apprendrons comment installer ESXi à l’aide de l’image du programme d’installation amorçable.

Se préparer

Avant de commencer, il est recommandé de consulter le Guide de compatibilité VMware pour vérifier si le matériel du serveur est compatible avec VMware ESXi 6.7.

Le Guide de compatibilité VMware est disponible à l’adresse http://www.vmware.com/resources/compatibility/search.php.

Configuration matérielle requise

Une fois que vous vous êtes assuré que le matériel du serveur est compatible, l’étape suivante consiste à vous assurer que le serveur répond aux exigences de capacité matérielle, qui sont les suivantes :

• Le serveur physique doit avoir au moins deux cœurs de processeur x86 64 bits.
• Les fonctions de processeur AMD No Execute (NX) et Intel Execute Disable (XD) doivent être activées dans le BIOS du serveur.
• Pour pouvoir exécuter des systèmes d’exploitation 64 bits sur des machines virtuelles, vous devez autoriser l’utilisation de la virtualisation matérielle (Intel VT-x ou AMD RVI) dans le BIOS du serveur.
• Un minimum de 4 Go de mémoire physique pour l’hyperviseur seul et 4 Go supplémentaires pour commencer à héberger des machines virtuelles.

Logiciel requis pour l’installation

L’image ISO de l’hyperviseur VMware ESXi 6.7 peut être téléchargée à partir de la page de téléchargements de VMware, à l’adresse https://my.vmware.com/web/vmware/downloads.

Les fournisseurs de serveurs fournissent des images personnalisées d’ESXi afin qu’il puisse inclure les pilotes et d’autres composants, tels que les fournisseurs CIM. Contactez toujours le fournisseur pour télécharger l’image OEM ESXi.

Utilisation de l’image ESXi

Vous avez besoin d’un moyen de présenter l’ISO à la machine physique afin qu’elle puisse démarrer à partir de celle-ci.

Bien sûr, vous pouvez graver l’ISO sur un DVD physique, puis l’insérer dans le lecteur DVD de la machine physique. Cependant, la plupart des serveurs modernes auront une méthode pour présenter l’image ISO au serveur en tant que lecteur virtuel via son interface IPMI. Si vous êtes administrateur, vous connaissez peut-être déjà des termes tels que ILO (HP), DRAC (Dell) et KVM manager (Cisco). Ce sont des outils Web qui se connecteront à une carte d’accès à distance ( RAC ) sur le serveur et permettront l’accès à distance à la console du serveur via l’interface Web.

Comment le faire

La procédure suivante vous guidera à travers les étapes impliquées dans le déploiement d’ESXi 6.7 à l’aide du programme d’installation interactif :

1. Montez l’ISO sur le serveur via son interface IPMI.
2. Démarrez le serveur de l’ISO. Contrairement à l’ancienne version des programmes d’installation, il ne vous présente plus le menu de démarrage du programme d’installation. Au lieu de cela, il commence à charger le programme d’installation dans la mémoire et affiche ensuite l’écran de bienvenue suivant dans l’installation de VMware ESXi 6.7.0 :

1. Une fois que vous avez appuyé sur Entrée pour continuer, sur l’écran suivant, appuyez sur F11 pour accepter le contrat de licence et continuer.
2. Sur l’écran suivant, vous serez invité à choisir un périphérique de stockage sur lequel installer ESXi, qui pourrait être un SSD local, un disque dur local ou un LUN du stockage distant (dans un démarrage à partir d’un scénario SAN). Utilisez le clavier pour faire une sélection et appuyez sur Entrée pour confirmer. Alternativement, pour faire un effort prudent pour vous assurer que vous avez sélectionné le bon disque et avant de confirmer la sélection en appuyant sur Entrée, appuyez sur F1 pour obtenir plus de détails concernant le périphérique de stockage que vous avez sélectionné. L’étape 5 couvre ce processus :

1. Une étape facultative : sélectionnez le périphérique de stockage et appuyez sur F1. Il vous sera présenté aujourd’hui avec des détails uniques, tels que le chemin de CTL au périphérique, LUN ID, ID cible (si vous utilisez iSCSI), et la capacité du disque, ainsi que d’autres informations générales. Il vous indiquera également si une installation existante d’ESXi est présente sur le périphérique de stockage :

Détails généraux sur le disque

1. Une fois que vous avez terminé le processus de vérification, appuyez sur Entrée. Vous serez ramené à l’écran Sélectionner un disque à installer ou à mettre à niveau. Appuyez sur Entrée pour confirmer la sélection de l’appareil.
2. Sur l’écran suivant, sélectionnez une disposition de clavier. La valeur par défaut aux États-Unis est présélectionnée. Faites une sélection différente si nécessaire et appuyez sur Entrée pour continuer.
3. Vous serez invité à définir un mot de passe pour le compte racine ESXi. Une fois que vous avez tapé le mot de passe, appuyez sur Entrée pour continuer.

À ce stade, le programme d’installation analysera le matériel du serveur pour rechercher des informations supplémentaires ou des conditions préalables dont il aurait besoin pour continuer. Si l’une des vérifications préalables échoue, vous serez averti en conséquence. Par exemple, si vous n’avez pas activé Intel VT-x ou AMD-V dans le BIOS, il vous en avertira. Il peut également vous avertir des périphériques non pris en charge qui sont détectés lors de l’analyse. La plupart des avertissements ne vous empêcheront pas de continuer et indiqueront uniquement ce qui ne sera pas configuré ou pris en charge. Appuyez sur Entrée pour continuer.

1. Sur l’écran Confirmer l’installation, vérifiez le nom du périphérique de stockage qui s’affiche. Si c’est le bon appareil, appuyez sur F11 pour démarrer l’installation. En cas de doute, utilisez F9 pour revenir en arrière et apporter les modifications nécessaires :

1. L’écran Installer ESXi 6.7.0 affichera la progression de l’installation. Cela pourrait prendre quelques minutes.
2. Une fois l’installation terminée, il vous sera conseillé de retirer le support d’installation (démonter l’ISO) avant de redémarrer le serveur. Une fois cela fait, appuyez sur Entrée pour redémarrer :

1. Après un redémarrage, vous serez sur l’écran principal d’ESXi 6.7.0.

Ceci termine le processus d’installation d’ESXi sur un serveur bare-metal à l’aide du programme d’installation ISO ESXi.

Comment ça marche

Le programme d’installation ESXi charge tous les modules nécessaires dans la mémoire, détecte les ressources matérielles, puis vous permet d’effectuer l’installation sur un périphérique de stockage spécifié. Une fois installé, ESXi s’exécute dans un mode d’évaluation de 60 jours et doit être concédé sous licence pour une utilisation en production. La première étape de post-installation consiste à rendre l’hôte ESXi disponible sur le réseau en configurant sa pile TCP / IP de gestion. Lisez la configuration suivante de la recette du réseau de gestion ESXi pour en savoir plus.

Configuration du réseau de gestion ESXi

Après avoir installé ESXi, il est indispensable de configurer son réseau de gestion. La configuration du réseau de gestion est associée à une interface VMkernel. Considérez-le comme une interface réseau virtuelle pour VMkernel. Nous en apprendrons plus à ce sujet dans le chapitre 3, Configuration de l’accès réseau à l’aide de commutateurs standard vSphere. L’hyperviseur ESXi exécute un client DHCP, il obtient donc une adresse DHCP s’il y a un serveur DHCP sur son réseau ; cependant, dans la plupart des cas, cela ne suffit pas. Par exemple, si votre réseau de gestion est sur un VLAN, vous devrez configurer un ID VLAN. De plus, il est recommandé d’attribuer une adresse IP statique au réseau de gestion ESXi.

Dans cette recette, nous utiliserons l’interface utilisateur de la console directe (DCUI) pour y parvenir.

Se préparer

Vous aurez besoin des informations suivantes pour poursuivre les étapes :

• Vous aurez besoin d’accéder à la console distante du serveur via son interface IPMI (Dell DRAC, HPE ILO, Cisco KVM).
• Mot de passe du compte root.
• Configuration TCP / IP – Adresse IP, masque de sous-réseau, adresse de passerelle IP, ID VLAN, adresses de serveur DNS et nom d’hôte.

Comment le faire

La procédure suivante vous guidera à travers les étapes requises pour installer la configuration TCP / IP pour le réseau de gestion d’ESXi :

1. Sur l’écran principal d’ESXi, appuyez sur F2 pour vous connecter à DCUI en fournissant le mot de passe root.
2. Accédez à Configurer le réseau de gestion et appuyez sur Entrée :

1. L’écran Configurer le réseau de gestion vous présente des options pour sélectionner les adaptateurs réseau, attribuer un ID VLAN si nécessaire et configurer les paramètres IPv4 / IPv6 et la configuration DNS. Chacune de ces sections peut être sélectionnée en appuyant sur Entrée puis en utilisant les instructions à l’écran pour sélectionner / modifier / confirmer les paramètres :

1. La section Adaptateurs réseau peut être utilisée pour attribuer / annuler l’attribution d’adaptateurs au groupe de ports du réseau de gestion. Utilisez les instructions à l’écran pour effectuer des sélections et les confirmer :

1. La section VLAN (facultative) est utilisée pour fournir un ID VLAN pour l’interface. La section Configuration IPv4 est utilisée pour fournir une adresse IP / un masque de sous – réseau / une passerelle par défaut :

1. La section Configuration IPv6 est utilisée pour fournir des adresses IPv6. IPv6 est activé par défaut. Si IPv6 n’est pas requis pour votre environnement, sélectionnez l’option Désactiver IPv6 (redémarrage requis) et appuyez sur Entrée.
2. La section Configuration DNS peut être utilisée pour fournir des adresses de serveur DNS principal / secondaire et des noms d’hôte :

Si vous ne fournissez pas de FDQN lors de la définition du nom d’hôte, assurez-vous de configurer un suffixe DNS personnalisé.

1. Les suffixes DNS personnalisés sont facultatifs si vous avez utilisé un nom de domaine complet comme nom d’hôte à l’étape précédente :
2. Une fois que vous avez terminé avec toute la configuration du réseau, sur l’écran Configurer le réseau de gestion : Confirmer, appuyez sur Échap. Vous serez invité à appliquer les modifications en redémarrant le réseau de gestion. Appuyez sur Y pour appliquer les paramètres et redémarrer les hôtes :
3. Une fois le redémarrage terminé, vous devriez pouvoir atteindre l’hôte ESXi via le réseau. À partir de là, l’hôte ESXi peut être géré directement à l’aide du client hôte ou peut être ajouté à vCenter Server.

Comment ça marche

Tout comme les machines virtuelles qui s’exécuteraient sur les hôtes ESXi, le VMkernel devrait également s’interfacer avec le réseau à diverses fins. Ces interfaces agissent comme des points de nœud de réseau pour le VMkernel. La toute première interface VMkernel – vmk0 est créée lors de l’installation d’ESXi. Cette interface est l’interface de gestion de l’hôte ESXi. VMware vous permet de créer un maximum de 256 interfaces VMkernel (vmk0 – vmk255) sur un hôte ESXi.

Les cas d’utilisation incluent des interfaces pour le trafic de gestion, le trafic VMotion, le trafic FT, le trafic Virtual SAN, iSCSI et les interfaces NAS. Étant donné que chaque interface est un point de nœud de réseau, elle aura besoin d’une configuration IP et d’une adresse MAC.

La première interface VMkernel (vmk0) fournira l’adresse MAC de la carte réseau physique à laquelle elle est connectée. Les interfaces restantes récupèrent l’adresse MAC VMware OUI générée par l’hôte ESXi.

Déploiement scripté d’ESXi

Lorsque vous avez un grand nombre d’hôtes ESXi à déployer, toute méthode pour automatiser et réduire la quantité de travail manuel est considérée comme la meilleure solution. L’automatisation de l’installation présente l’avantage principal de normaliser plusieurs installations sans avoir à auditer soigneusement chaque installation. VMware a toujours pris en charge l’installation scriptée des hôtes ESXi, et cela n’a pas changé avec vSphere 6.7.

Comme pour toute tâche automatisée, l’installation scriptée d’un hôte ESXi nécessite l’utilisation d’un fichier de configuration qui contient la configuration d’hôte prévue qui est stockée à un emplacement accessible à l’hôte ESXi. Le fichier de configuration est appelé fichier kickstart ( .cfg ) .

Un fichier kickstart peut être stocké à l’un des emplacements pris en charge suivants :

• Un serveur web (accès via HTTP ou HTTPS)
• Un serveur de fichiers réseau (FTP / NFS)
• Un support de stockage local accessible à l’hôte (CD-ROM / USB)

Dans cette recette, nous apprendrons comment effectuer une installation sans assistance d’ESXi à l’aide du support d’installation, d’un périphérique USB local et d’un emplacement réseau.

Se préparer

Avant de commencer, préparez un script pour l’installation. Un script par défaut est disponible sur chaque hôte ESXi à /etc/vmware/weasel/ks.cfg . Bien que l’extension soit .cfg , le nom de fichier n’a pas besoin d’être le même. Il doit s’agir d’un fichier texte brut avec l’extension .cfg .

Voici un exemple de script:

# Sample scripted installation file for vdescribed.lab
# Accept the VMware End User License Agreement
vmaccepteula
# Clear/format existing partitions
clearpart –firstdisk –overwritevmfs
# Set the root password for the DCUI and Tech Support Mode
rootpw password@123
# The install media is in the CD-ROM drive
install –firstdisk –overwritevmfs
# Set a static IP Configuration
network –bootproto=static –device=vmnic0 –ip=192.168.78.91 –netmask=255.255.255.0 –gateway=192.168.78.1 –nameserver=192.168.78.130 –hostname=bkesx02
reboot
# Post Installation Tasks
%firstboot –interpreter=busybox
#Create vSwitch
esxcli network vswitch standard add –vswitch-name=vSwitch2
# Disable ipv6
esxcli network ip set –ipv6-enabled=false
sleep 30
reboot

Une fois le script préparé, stockez-le dans l’un des emplacements d’assistance. Pour cette recette, je l’ai stockée sur un serveur NFS.

Comment le faire

La procédure suivante vous guidera à travers les étapes requises pour effectuer une installation scriptée de l’hôte ESXi :

1. Démarrez le serveur à l’aide de l’ISXi ISO. L’ISO peut être monté sur le serveur via son interface IPMI (DRAC, ILO, etc.).
2. Sur l’écran Loading ESXi Installer, avant qu’il ne démarre automatiquement, appuyez sur Maj + O pour modifier les options de démarrage. Ceci est indiqué dans le coin inférieur droit de l’écran :

1. Sur l’écran suivant, entrez l’emplacement du fichier kickstart et appuyez sur Entrée pour commencer l’installation :

1. Une fois l’installation terminée, si le script kickstart comprend une commande de redémarrage, comme il le fait dans notre script, le serveur sera redémarré ; sinon, vous serez invité à confirmer.

Comment ça marche

Lorsque vous utilisez un fichier kickstart, l’installation ESXi ne nécessite aucune intervention de l’utilisateur. Le fichier kickstart peut être configuré pour exécuter une variété de tâches. Il peut également être configuré pour exécuter des scripts Python après l’installation.

Examinons l’exemple de script utilisé dans cette recette. Ce script est disponible dans la section Préparation :

Script command	Purpose
vmaccepteula	Accepts the ESXi End User License Agreement.
clearpart –firstdisk –overwritevmfs	Used to format the selected disk and overwrite any VMFS volume. This is a destructive process and cannot be reversed.
install –firstdisk –overwritevmfs	Used to indicate that this is a fresh installation, and the installation will be informed on the first disk in the list by overwriting any VMFS volume.
rootpw password@123	Sets the root password as password@123.
network –bootproto=static –device=vmnic0 –ip=192.168.78.91 –netmask=255.255.255.0 –gateway=192.168.78.1 –nameserver=192.168.78.130 –hostname=bkesx02	Configures a static IP address, a DNS server address, and a hostname for ESXi.
reboot	Reboots the ESXi host.
%firstboot –interpreter=busybox	This is used to indicate that the commands following this line will be executed on first boot. Setting the interpreter to busybox will let you execute the CLI command. Setting it to Python will let you run Python scripts.
esxcli network vswitch standard add -v=vSwitch2	Creates a second standard switch with the name vSwitch2.
esxcli network ip set –ipv6-enabled=false	Disables IPv6.
sleep 30	Will not execute any commands for 30 seconds.

Pour obtenir la liste de toutes les commandes prises en charge dans le fichier kickstart, reportez-vous à la section Commandes de script d’installation et de mise à niveau à la page 78 du guide d’installation et de configuration de VMware ESXi, disponible à l’adresse https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-esxi-67-installation-setup-guide.pdf.

Il y a plus

Bien que l’installation par script automatise le processus dans une certaine mesure, elle vous oblige toujours à vous connecter à chaque hôte ESXi et à fournir un emplacement pour le fichier de script. Un déploiement sans assistance ne doit nécessiter aucune intervention de l’utilisateur autre que le simple démarrage du serveur. Pour ce faire, PXE démarre les hôtes et utilise le script kickstart à partir d’un emplacement réseau pour exécuter l’installation. Cependant, si un déploiement sans assistance a été pris en compte, la recommandation est d’utiliser vSphere Auto Deploy, qui offre plus de contrôle et de gestion. vSphere Auto Deploy sera traité dans un chapitre ultérieur.

Déploiement de vCenter Server Appliance (VCSA)

Le déploiement de VCSA se fait avec un programme d’installation, qui déploie la machine virtuelle VCSA sur un hôte ESXi choisi. L’interface graphique du programme d’installation collecte toutes les informations requises pour configurer le serveur vCenter.

Il existe deux types de déploiement :

• Appliance intégrée
• VCenter et PSC Appliance séparés (obsolètes)

Un PSC externe était une exigence dans le passé si vous avez choisi de configurer le mode lié amélioré pour vos vCenters. Ce n’est plus le cas dans vSphere 6.7. Avec vCenter 6.7, le concept d’un PSC externe est déconseillé et le mode lié amélioré entre les vCenters avec des PSC intégrés est désormais entièrement pris en charge. Nous en apprendrons plus sur Enhanced Linked Mode dans la rubrique Déploiement de serveurs vCenter dans une recette de configuration Linked Mode.

Se préparer

Voici ce dont vous aurez besoin avant d’installer vCenter Server :

• Téléchargez l’ISO de VMware VCSA 6.7 depuis https://my.vmware.com/web/vmware/downloads
• Accès à une machine (Windows / Linux / macOS) pour exécuter le programme d’installation de vCenter à partir de
• Adresse IP / FQDN de l’hôte ESXi ou du vCeter sur lequel VCSA sera déployé
• Configuration IP (adresse IP statique, masque de sous-réseau, adresse de passerelle et adresses de serveur DNS)
• Un enregistrement d’hôte DNS pour le VCSA

Comment le faire

La procédure suivante vous guidera à travers les étapes impliquées dans le déploiement de VCSA 6.7 avec un PSC intégré :

1. Montez le VCSA ISO sur une machine à partir de laquelle exécuter le programme d’installation.
2. Accédez au CD – ROM : \\ VMware VCSA \ vcsa-ui-installer \ win32 et exécutez installer.exe pour afficher l’assistant d’installation VCSA.

L’étape 1 du déploiement commence ici :

1. Dans l’écran Étape 1 : Déployer l’appliance , cliquez sur Installer .
2. Sur l’écran Introduction, cliquez sur Suivant pour continuer.
3. Acceptez le contrat de licence utilisateur final et cliquez sur Suivant.
4. Dans l’écran Sélectionner le type de déploiement, choisissez Embedded Platform Services Controller :

1. Sur l’ écran cible de déploiement de l’appliance, indiquez l’adresse IP de l’hôte ESXi ou du vCenter sur lequel VCSA sera déployé et fournissez ses informations d’identification. Cliquer sur Suivant pour continuer.
2. Acceptez le certificat vCenter / ESXi en cliquant sur Oui.
3. Dans l’écran Configurer la machine virtuelle de l’appliance, spécifiez un nom de machine virtuelle pour VCSA et définissez son mot de passe racine. Le nom de la machine virtuelle n’a pas besoin d’être identique au nom d’hôte ou au nom de domaine complet de l’appliance:

1. Dans l’écran Sélectionner la taille de déploiement, spécifiez une taille de déploiement et une taille de stockage pour l’appliance. Il existe une taille de stockage par défaut pour chaque taille de déploiement. Cependant, cela peut être remplacé en sélectionnant une taille de stockage plus grande (Large ou X-Large) si vous voulez un disque plus grand (vmdk) pour la partition / storage / seat qui stocke les statistiques, les tâches, les événements et les alarmes :

1. Sur l’écran Sélectionner une banque de données, choisissez une banque de données pour le VCSA et cliquez sur Suivant pour continuer. Activer le mode disque mince est sélectionné par défaut.
2. Sur l’écran Configurer les paramètres réseau, choisissez un groupe de ports VM pour la machine virtuelle VCSA, la version IP et définissez le type d’adresse IP sur statique. Spécifiez le FQDN, l’adresse IP / le masque de réseau, la passerelle et les adresses de serveur DNS. Ne modifiez pas les ports communs (HTTP / HTTPS) de 80/443, sauf si cela est absolument nécessaire :

1. Sur l’écran Prêt à terminer l’étape 1, passez en revue les paramètres et cliquez sur Terminer pour commencer à déployer la machine virtuelle.
2. Une fois le déploiement terminé, un écran vous le confirmera. Cliquez sur Continuer :

Si vous fermez accidentellement l’assistant ou choisissez de continuer ultérieurement, le programme d’installation de l’étape 2 peut être démarré en se connectant à l’URL d’administration de l’appliance, c’est-à-dire https://VCSA IP ou FQDN:5480 , et en utilisant la configuration Option vCenter Server Appliance.

L’étape 2 du déploiement commence ici :

1. Sur l’écran d’ installation – Étape 2: configurer vCenter Server Appliance avec un écran PSC intégré, cliquez sur Suivant.
2. Sur l’écran de configuration de l’appliance, spécifiez un mode de synchronisation de l’heure et activez l’accès SSH (désactivé par défaut).
3. Sur l’écran de configuration SSO, choisissez de créer un nouveau domaine SSO. Spécifiez un nom de domaine (la valeur par défaut est vsphere.local ) et définissez le mot de passe pour l’administrateur SSO:

1. Sur l’écran Configure CEIP, choisissez de décocher le programme Join VMware Customer Experience Improvement Program (CIEP).
2. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur TERMINER pour lancer la configuration :

1. Vous serez invité avec un avertissement indiquant qu’une fois que vous choisissez de continuer, l’opération ne peut pas être arrêtée. Cliquez OK pour continuer.
2. Une fois l’installation / configuration terminée, un écran de confirmation et l’URL ( https: // FQDN de vCSA: 443 ) vous seront présentés vers la page de démarrage de vCenter. Cliquez sur Fermer pour quitter le programme d’installation.

Ceci termine l’installation, et vous pourrez maintenant accéder à la page de démarrage de vCenter:

Comment ça marche

Le processus de déploiement d’un VCSA est divisé en deux phases. Dans la phase 1 , le programme d’installation déploie une machine virtuelle de dispositif vCenter en fonction des exigences de dimensionnement spécifiées, tandis que dans la phase 2 , vous devez spécifier la configuration SSO. Il est courant de prendre un instantané du VCSA nouvellement déployé après la phase 1 afin qu’il puisse être réutilisé en cas d’échec de la phase 2 de l’installation pour une raison quelconque.

Déploiement de vCenters dans une configuration Linked Mode

Lorsque vous avez plusieurs vCenter à gérer dans votre environnement, pouvoir les gérer sous une seule vue est toujours avantageux. Ceci est réalisé en configurant les PSC pour qu’ils fassent partie du même domaine SSO, les plaçant ainsi dans une configuration Enhanced Linked Mode. Les vCenters en mode lié répliqueront les rôles et les autorisations, les licences et d’autres détails, permettant à l’administrateur d’effectuer une connexion unique dans vSphere Web Client pour afficher et gérer les objets d’inventaire de tous les serveurs vCenter liés.

vCenter 6.7 prend désormais entièrement en charge la configuration des PSC intégrés dans une configuration en mode lié, éliminant ainsi la nécessité de protéger les nœuds PSC lors de la configuration de la haute disponibilité pour vCenter.

Se préparer

Vous aurez besoin des informations suivantes à portée de main avant de continuer :

• ISO de VMware VCSA 6.7 sur https://my.vmware.com/web/vmware/downloads
• Accès à une machine (Windows / Linux / macOS) pour exécuter le programme d’installation de vCenter à partir de
• L’adresse IP / FQDN de l’hôte ESXi ou du vCenter sur lequel VCSA sera déployé
• La configuration IP (y compris l’adresse IP statique, le masque de sous-réseau, l’adresse de passerelle et les adresses de serveur DNS)
• Un enregistrement d’hôte DNS créé pour le nouveau VCSA
• L’adresse IP / FQDN du PSC homologue
• Le nom de domaine SSO du PSC homologue
• Informations d’identification de l’administrateur SSO pour le domaine choisi

Comment le faire

La procédure suivante vous guidera à travers les étapes requises pour configurer vCenters dans une configuration Linked Mode:

1. Passez à l’étape 1 de l’installation en déployant un nouveau VCSA.
2. Sur l’écran d’installation – Étape 2: configurer vCenter Server Appliance avec un écran PSC intégré, cliquez sur Suivant.
3. Sur l’écran de configuration de l’appliance, spécifiez un mode de synchronisation de l’heure et activez l’accès SSH (désactivé par défaut).
4. Sur l’écran de configuration SSO, choisissez de rejoindre un domaine SSO existant. Spécifiez le FQDN / IP du PSC homologue, son domaine SSO et les informations d’identification de l’administrateur:

1. Sur l’écran Configure CEIP, choisissez de décocher le programme Join VMware Customer Experience Improvement Program (CIEP).
2. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur TERMINER pour lancer la configuration :

1. Une fois la configuration / configuration terminée, un écran de confirmation vous sera présenté, ainsi que l’URL (https://FQDN de VCSA:443) de la page de démarrage de vCenter. Cliquez sur Fermer pour quitter le programme d’installation.

Ceci termine la configuration du mode lié :

Maintenant, lorsque vous vous connectez au client Web, il doit répertorier tous les serveurs vCenter dans le même domaine PSC.

Comment ça marche

Une fois que les vCenters sont dans ELM, ils répliquent le contenu VMDir, les clés de licence, les autorisations globales, les balises et les catégories.

L’état de réplication peut être vérifié à partir de chaque nœud en exécutant les commandes suivantes :

Les mêmes commandes, lorsqu’elles sont exécutées sur le vCenter / PSC homologue, doivent signaler des données similaires:

Il y a plus

Vous pouvez toujours déployer des PSC externes dans vSphere 6.7, bien qu’il n’y ait pas de cas d’utilisation fort pour le faire. Si votre environnement 6.5.x ou plus ancien avait des serveurs PSC ou SSO externalisés, ils seront migrés / mis à niveau pour devenir des PSC externes par défaut. Ceux-ci peuvent cependant être convertis en VCSA intégrés lors de la mise à niveau. Nous en apprendrons plus à ce sujet dans le chapitre suivant.

Configuration des sources d’identité SSO (Single Sign-On)

Une source d’identité SSO est un référentiel d’utilisateurs ou de groupes. Il peut s’agir d’un référentiel d’utilisateurs d’OS locaux, Active Directory ou OpenLDAP et VMDir. L’ajout d’une source d’identité vous permet d’attribuer des autorisations vCenter aux utilisateurs à partir d’un tel référentiel.

Le VCSA Photon OS (OS local) et le domaine SSO ( vsphere.local ) sont des sources d’identité pré-reconnues. Cependant, lorsque vous essayez d’ajouter des sources d’identité, vous êtes autorisé à ajouter trois types différents :

• Active Directory (authentification intégrée Windows)
• Active Directory sur LDAP
• Ouvrez LDAP

Dans cette recette, nous apprendrons comment ajouter une source d’identité Active Directory.

Comment le faire

La procédure en deux parties suivantes vous permettra de joindre le PSC à Active Directory et d’ajouter une source d’identité Active Directory.

Partie 1 – Joindre le PSC à Active Directory

La jonction du PSC à Active Directory doit être effectuée une seule fois au cours du cycle de vie du PSC.

1. Connectez-vous à vCenter Server / PSC en tant qu’administrateur SSO ( administrator@vsphere.local ).
2. Utilisez le menu pour accéder à Administration:

Menu | Administration

1. Sur la page Administration, accédez à Authentification unique | Configuration | Domaine Active Directory et cliquez sur JOIN AD :

1. Dans la fenêtre Rejoindre un domaine Active Directory, spécifiez le nom du domaine, l’unité d’organisation (facultative) et les informations d’identification d’un utilisateur de domaine autorisé à joindre la machine au domaine. Cliquez sur Rejoindre.
2. Une fois cela fait, l’hôte doit être redémarré pour que les modifications prennent effet.
3. Une fois le redémarrage terminé, il devrait afficher le vCenter / PSC comme joint au domaine :

Partie 2 – Ajout de la source d’identité

Utilisez le processus suivant pour ajouter une source d’identité :

1. Accédez à la page Administration, accédez à Authentification unique | Configuration | Sources d’identité, puis cliquez sur AJOUTER UNE SOURCE D’IDENTITÉ :

1. Dans la fenêtre Ajouter une source d’identité, définissez le type de source d’identité sur Active Directory (authentification intégrée Windows). Le nom de domaine sera prérempli avec le FQDN du domaine auquel le PSC est joint. Utilisez le compte d’ordinateur pour vous authentifier :

1. Une fois cela fait, le domaine Active Directory sera répertorié parmi les autres sources d’identité :

Ceci termine le processus de configuration des sources d’identité SSO sur un vCenter Server.

Comment ça marche

VMware SSO est un serveur d’authentification mis à disposition à partir de vSphere 5.1. Avec la version 5.5, il a été redéfini afin qu’il soit simple à planifier et à déployer, ainsi que plus facile à gérer. Avec vSphere 6.0 et 6.5, il est désormais intégré au PSC.

SSO agit comme une passerelle d’authentification, qui prend les demandes d’authentification de divers composants enregistrés et valide la paire d’informations d’identification par rapport aux sources d’identité qui sont ajoutées au serveur SSO. Les composants sont enregistrés sur le serveur SSO lors de leur installation.

Une fois authentifiés, les clients SSO reçoivent un jeton pour les échanges ultérieurs. L’avantage ici est que l’utilisateur ou l’administrateur du service client n’est pas invité à entrer une paire d’informations d’identification (nom d’utilisateur et mot de passe) chaque fois qu’il doit s’authentifier.

SSO prend en charge l’authentification par rapport aux sources d’identité suivantes:

• Active Directory
• Active Directory en tant que serveur LDAP
• Ouvrez LDAP
• OS local

Voici certains des composants qui peuvent être enregistrés auprès de VMware SSO et tirer parti de ses fonctionnalités. Ces composants, en termes d’authentification unique, sont appelés clients SSO:

• VMware vCenter Server
• VMware vCenter Orchestrator
• VMware NSX
• VMware vCloud Director
• VMware vRealize Automation
• VMware vSphere Web Client
• Protection des données VMware vSphere
• Navigateur de journaux VMware

Configuration des rôles et autorisations vCenter

Par défaut, le groupe SSO-Domain \ Administrators ( vsphere.local \ Administrators ) se voit attribuer un rôle d’administrateur sur le vCenter et est défini comme une autorisation globale . Cela signifie que s’il devait y avoir plus d’un vCenter dans une configuration Enhanced Linked Mode, le groupe vsphere \ Administrators disposera des autorisations de rôle d’administrateur sur tous les vCenters connectés.

Le seul membre du groupe vsphere.local \ Administators est l’administrateur SSO ( administator@vsphere.local ). Des utilisateurs d’autres sources d’identité peuvent être ajoutés en tant que membres de ce groupe si vous le souhaitez.

Cependant, dans la plupart des environnements, bien que plusieurs vCenters soient gérés sous un seul parapluie ELM, vous devrez parfois fournir des autorisations spécifiques à vCenter. Par exemple, si vous gérez plusieurs vCenters appartenant à différents clients, l’attribution d’autorisations globales n’est pas considérée comme idéale. Dans de tels cas, vous devrez fournir un accès utilisateur à des vCenters spécifiques uniquement.

Dans cette recette, nous apprendrons comment attribuer des autorisations vCenter à un utilisateur / groupe Active Directory.

Se préparer

Avant de démarrer et d’attribuer des autorisations vCenter, assurez-vous que le domaine hébergeant l’utilisateur / le groupe prévu est ajouté en tant que source d’identité. Pour savoir comment ajouter des sources d’identité, lisez la recette Configuration des sources d’identité SSO dans ce chapitre.

Comment faire

La procédure suivante vous guidera à travers les étapes requises pour configurer les autorisations vCenter pour un utilisateur ou un groupe de domaine :

1. Connectez-vous à l’interface vSphere Client (HTML 5) en tant qu’administrateur SSO.
2. Sélectionnez l’objet vCenter dans l’inventaire, accédez à son onglet Autorisations et cliquez sur + pour afficher la fenêtre Ajouter une autorisation :

1. Dans la fenêtre Ajouter une autorisation, sélectionnez un utilisateur ou un groupe de domaine à l’aide de la zone de recherche, puis spécifiez un rôle. Vous pouvez également choisir de propager les autorisations de cascade vers d’autres objets d’inventaire. Cliquez sur OK pour confirmer:

1. Une fois cela fait, l’utilisateur / groupe doit être répertorié sous Autorisations.

Comment ça marche

Tout compte d’utilisateur utilisé pour se connecter à vSphere Web Client a besoin d’une autorisation sur le vCenter pour pouvoir afficher et gérer son inventaire. Lors de la configuration des autorisations globales, il est important de s’assurer qu’il est propagé aux objets enfants afin que les autorisations soient également définies sur le ou les vCenter Server. Les autorisations peuvent être configurées pour les utilisateurs locaux et Active Directory, à condition que les sources d’identité requises soient ajoutées à SSO.

Joindre ESXi à un domaine Active Directory

En tant qu’administrateur gérant un environnement vSphere, la dernière chose que vous voudriez faire est de partager le mot de passe root. N’oubliez pas qu’un mot de passe root oublié ne peut pas être récupéré / réinitialisé et nécessitera une réinstallation d’ESXi.

Rejoindre un hôte ESXi à un domaine Active Directory permet aux utilisateurs d’un groupe d’utilisateurs de domaine particulier de se connecter à l’hôte ESXi sans avoir besoin de connaître le mot de passe root. Cela élimine non seulement la nécessité de changer périodiquement le mot de passe root, mais permet également un meilleur audit.

Se préparer

Voici ce dont vous aurez besoin avant de rejoindre l’hôte ESXi au domaine et de configurer l’accès à celui-ci:

• Le nom du domaine
• Nom d’utilisateur et mot de passe d’un utilisateur de domaine autorisé à joindre la machine au domaine
• Le nom du groupe d’utilisateurs du domaine dont les utilisateurs sélectionnés feront partie

Comment faire

La procédure suivante vous guidera à travers les étapes nécessaires pour joindre l’hôte ESXi au domaine et permettre à un groupe d’utilisateurs de domaine d’y accéder :

1. Connectez-vous à l’interface HTML 5 du vCenter Server, c’est-à-dire https://FQDN of vCenter / ui.
2. Sélectionnez l’hôte ESXi dans l’inventaire et accédez à Configurer | Système | Services d’authentification. À partir d’ici, cliquez sur Rejoindre le domaine.
3. Sur l’écran Join Domain, spécifiez un nom de domaine et des informations d’identification de domaine et cliquez sur OK :

1. Vous devriez voir un message Tâche de rejoindre le domaine Windows terminée avec succès dans le volet Tâches récentes.

Maintenant que l’hôte est joint au domaine, nous pouvons le configurer pour autoriser l’accès à un groupe d’utilisateurs de domaine.

1. Avec l’hôte sélectionné, accédez à Configurer | Système | Paramètres système avancés et cliquez sur Modifier.
2. Sur l’écran Modifier les paramètres système avancés, tapez esxadmin dans la zone de recherche pour filtrer les paramètres.
3. Cliquez sur le champ Valeur correspondant au paramètre Config.HostAgent.plugins.hostsvc.esxAdminsGroup et entrez le nom du groupe d’utilisateurs du domaine:

Vous devriez maintenant pouvoir vous connecter en tant qu’utilisateur de domaine à la console (direct / SSH) et DCUI en utilisant les formats suivants :

• user @ domain : par exemple, abhilashgb @ vdescribed
• domaine \ utilisateur : par exemple, vdescribed \ abhilashgb

Comment ça marche

Une fois que l’hôte ESXi a été joint au domaine Active Directory, un groupe d’utilisateurs de domaine peut être autorisé à se connecter à l’hôte ESXi. Cet accès est activé en spécifiant le nom du groupe d’utilisateurs à l’aide du paramètre système avancé, c’est-à-dire Config.HostAgent.plugins.hostsvc.esxAdminsGroup .

Par défaut, ce groupe d’utilisateurs bénéficie de privilèges d’administrateur. Ce comportement peut cependant être modifié en utilisant le paramètre système avancé, c’est-à-dire Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd .

Planification et exécution de la mise à niveau de vSphere

L’objectif de ce chapitre est de vous aider à comprendre, planifier et exécuter le processus de mise à niveau de votre infrastructure vSphere principale vers VMware vSphere 6.7. Le noyau comprend votre hyperviseur ESXi, vCenter Server et les composants de vCenter Server. La mise à niveau des produits de troisième couche qui exploitent l’infrastructure de base de vSphere, tels que vRealize Automation, NSX et VMware Horizon View, ne sont pas traités dans ce chapitre car ils dépassent la portée et l’objectif de ce livre.

Permettez-moi de vous présenter les principaux composants de l’infrastructure qui seront mis à niveau :

• VMware vCenter Server : la viabilité d’une mise à niveau ou la nécessité d’une nouvelle version dépendra de la version actuelle de vCenter et du chemin de mise à niveau pris en charge.
• vCenter Inventory Service : il ne s’agit plus d’un service distinct dans vCenter 6.5 / 6.7.
• vSphere Web Client : le composant Web Client sera mis à niveau dans le cadre de la mise à niveau de vCenter.
• vSphere Platform Services Controller (PSC) : si vous effectuez une mise à niveau de vSphere 6.0 vers 6.7, vous devrez revoir le modèle de déploiement actuel et appliquer une stratégie appropriée pour mettre à niveau le PSC. Une fois que les PSC ont été mis à niveau vers 6.7 Update 1, ils peuvent être convergés vers vCenter Appliance puis mis hors service.
• vSphere Update Manager (VUM) : VUM doit être mis à jour vers la dernière version avant de pouvoir être utilisé pour mettre à niveau les hôtes ESXi qui sont gérés par le vCenter VUM avec lequel il est intégré. Les composants VUM sont désormais intégrés à vCenter Appliance.
• VMware ESXi : l’hyperviseur peut être mis à niveau en démarrant le serveur à l’aide de l’image ISO, à l’aide de vSphere Update Manager ou en mettant à jour le profil d’image si les serveurs existants sont déployés automatiquement.

Il est important de noter qu’il n’y a pas de chemin de mise à niveau directe de vSphere 5.5 vers vSphere 6.7 . Vous devrez mettre à niveau vers vSphere 6.0 / 6.5 avant de pouvoir mettre à niveau l’environnement vers vSphere 6.7.

Dans ce chapitre, nous couvrirons les recettes suivantes :

• Planification de la mise à niveau de votre infrastructure vSphere
• Exécution de VMware Migration Assistant
• Mise à niveau des contrôleurs de services de plate-forme (PSC)
• Mise à niveau des serveurs vCenter
• Utilisation de l’outil de convergence vCenter
• Mise à niveau des hôtes ESXi à l’aide du programme d’installation interactif
• Mise à niveau d’ESXi à l’aide de l’interface de ligne de commande

Planification de la mise à niveau de votre infrastructure vSphere

Avant de vous lancer dans la mise à niveau de tous les différents composants de votre infrastructure vSphere, il est essentiel de préparer et de mettre en page les effets de la mise à niveau des composants, qui incluent la prise en compte des temps d’arrêt nécessaires. Où commençons-nous? La réponse dépend des composants / solutions de notre environnement et des effets de leur compatibilité une fois mis à niveau.

Nous commençons par utiliser des ouvrages de référence tels que les matrices d’interopérabilité des produits VMware et les guides de compatibilité VMware. Il en va de même pour les autres produits / solutions de notre environnement. Par exemple, si nous avons une solution de sauvegarde tierce, il est essentiel de s’assurer que la solution de sauvegarde est compatible avec la version de vSphere vers laquelle nous procédons à la mise à niveau.

Un autre aspect critique est l’atténuation des défaillances. Et si la mise à niveau échoue? Il est essentiel d’inclure une procédure de restauration lorsque vous préparez un runbook.

Dans cette recette, vous apprendrez à planifier la mise à niveau de votre environnement vSphere.

Se préparer

Vous aurez besoin des outils suivants pour planifier la mise à niveau:

• Guide de compatibilité VMware (www.vmware.com/resources/compatibility/search.php)
• Matrices d’interopérabilité des produits VMware (www.vmware.com/resources/compatibility/sim/interop_matrix.php)
• Accès à la documentation du fournisseur pour les produits tiers qui s’intègrent avec vSphere

Comment le faire

Les procédures de haut niveau suivantes peuvent être utilisées pour planifier la mise à niveau d’un environnement vSphere:

• Déterminez la version et la compatibilité des composants vSphere.
• Vérifiez le chemin de mise à niveau et assurez-vous qu’il est pris en charge.
• Planifiez la séquence de mise à niveau des composants vSphere.
• Planifiez le temps d’arrêt des composants vSphere.
• Planifiez l’atténuation des échecs de mise à niveau.

Comment ça marche

Passons en revue ces étapes, une par une:

Partie 1 : Déterminer la version et la compatibilité :

• Rassemblez la version actuelle et les numéros de build des hôtes vCenter Server et ESXi.
• Vérifiez si le matériel du serveur est compatible avec VMware ESXi 6.7.x à l’aide du Guide de compatibilité VMware.
• Faites une liste de tous les plug-ins vCenter Server actuellement installés.
• Pour les plug-ins VMware, utilisez les matrices d’interopérabilité des produits VMware pour confirmer leur compatibilité avec vSphere 6.7.
• Pour les plug-ins tiers, utilisez la documentation du fournisseur correspondant pour confirmer leur compatibilité avec vSphere 6.7.

Partie 2 : Vérifiez le chemin de mise à niveau :

• Chaque produit, qu’il s’agisse de VMware ou d’une solution tierce qui s’intègre à vSphere, doit suivre un chemin de mise à niveau. Par exemple, un environnement vSphere 5.5 ne peut pas être directement mis à niveau vers 6.7. Il doit être mis à niveau vers 6.0 ou version ultérieure pour vCenter et ESXi 6.0 U3 ou version ultérieure avant de pouvoir être mis à niveau vers vSphere 6.7.

Pour ce faire, utilisez la section Chemin de mise à niveau des matrices d’interopérabilité des produits VMware.

• Certains produits tiers devront également passer à une version particulière (build) avant de pouvoir être mis à niveau vers une version compatible avec vSphere 6.7. Reportez-vous à la documentation du fournisseur pour vérifier le chemin de mise à niveau.

Partie 3 : Planifiez la séquence de mise à niveau des composants vSphere :

• Une fois les versions du produit et leur compatibilité confirmées, vous devrez arriver à une commande (séquence) dans laquelle les composants seront mis à niveau.
• Pour les produits VMware, utilisez VMware KB # 53710 (kb.vmware.com/kb/53710) pour comprendre la séquence dans laquelle les solutions doivent être mises à niveau. Si votre infrastructure vSphere possède d’autres produits VMware, tels que vROPS, vRA, SRM, NSX, etc., il est essentiel d’utiliser la base de connaissances pour comprendre la séquence.
• Une fois vCenter mis à niveau, vous pouvez ensuite mettre à niveau les hôtes ESXi.
• La mise à niveau des composants vCenter ne modifie pas le modèle / la topologie de déploiement. Cela signifie que, s’il existe des PSC externes dans l’environnement, ils devront d’abord être mis à niveau.
• vCenter 6.7 Update 1 comprend un outil de convergence , qui peut être utilisé pour transformer des PSC externes en composants intégrés de VCSA 6.7 Update 1.
• Avec chaque version majeure d’ESXi, VMware inclut une nouvelle version matérielle virtuelle qui apporte de nouvelles fonctionnalités et améliorations. vSphere 6.7 a la version matérielle 14. Nous apprendrons comment mettre à niveau les outils VMware et le matériel virtuel sur des machines virtuelles individuelles (VM) au chapitre 13, Création et gestion de machines virtuelles. Ce processus peut être orchestré à l’aide de VMware Update Manager afin de gérer les mises à niveau de plusieurs machines virtuelles. Nous en apprendrons plus à ce sujet dans un chapitre distinct qui couvre VMware Update Manager.

Partie 4 : planifier le temps d’arrêt des composants vSphere :

• La plupart de la mise à niveau peut être effectuée sans aucun temps d’arrêt pour les charges de travail VM. Cependant, les solutions mises à niveau entraîneront un temps d’arrêt temporaire. La durée d’indisponibilité requise dépend du temps nécessaire à la mise à niveau. Par exemple, si vous deviez migrer de vCenter (Windows) vers vCSA, pendant la mise à niveau, la base de données est transférée vers vCSA via le réseau. La quantité de données et l’encombrement du réseau pourraient jouer un rôle dans la détermination du temps requis pour l’importation et la mise à niveau.
• La mise à niveau des hôtes ESXi nécessitera un redémarrage.
• Lors de la prise en compte du temps d’arrêt requis, vous devrez prendre en compte le temps nécessaire pour dépanner une mise à niveau ou le temps nécessaire pour effectuer une restauration en cas d’échec de la mise à niveau.

Partie 5 : Plan d’atténuation des défaillances :

• En mettant à niveau la version actuelle de Windows / Appliance vers 6.7, Appliances déploie toujours un nouveau VCSA avec les données qui lui sont transférées, ce qui signifie qu’il n’apportera aucune modification au VCSA source. Cependant, il est toujours recommandé de prendre des instantanés des machines virtuelles source avant la mise à niveau afin de pouvoir les restaurer si nécessaire. Une restauration sans instantané est également possible en mettant simplement hors tension l’appliance cible et en mettant sous tension les machines virtuelles source.
• Une mise à niveau ESXi est non destructive dans la plupart des cas. Si la mise à niveau échoue pour une raison quelconque, l’hôte doit simplement être redémarré. Cependant, dans de rares cas, vous devrez effectuer une nouvelle installation.
• Il est recommandé de prendre des instantanés sur la machine virtuelle avant une mise à niveau des outils VMware ou du matériel virtuel. Le processus de mise à niveau des outils et du matériel virtuel sera traité dans le chapitre 14 , Mise à niveau et correction à l’aide de vSphere Update Manager .

Une fois que vous avez atteint un plan vérifié et documenté, vous pouvez procéder à l’exécution de la mise à niveau. Si votre environnement existant comprend des composants vCenter basés sur Windows, vous devrez commencer par apprendre à utiliser l’assistant de migration. Veuillez-vous référer à la recette Running VMware Migration Assistant pour plus d’informations.

Exécution de VMware Migration Assistant

VMware Migration Assistant est utilisé comme agent proxy afin que vous puissiez collecter des informations de configuration sur les composants vCenter exécutés sur Microsoft Windows et exécuter des vérifications de pré-mise à niveau, et il facilite le transfert de données de la machine Windows vers l’appliance vCenter.

L’assistant de migration est fourni avec l’ISO du programme d’installation de vCenter Server Appliance.

Dans cette recette, vous apprendrez à exécuter VMware Migration Assistant sur des machines Windows en exécutant les composants PSC, vCenter et Update Manager vCenter.

Se préparer

Avant de commencer, téléchargez l’ISO du programme d’installation de vCenter Server Appliance 6.7 et montez-le sur la machine Windows exécutant PSC ou vCenter.

Comment le faire

La procédure suivante vous guidera à travers les étapes impliquées dans l’exécution de l’assistant de migration vCenter 6.7 sur une machine de composant vCenter source :

1. Copiez le dossier de l’assistant de migration de la racine de l’ISO du programme d’installation de VCSA 6.7 vers le PSC source qui doit être mis à niveau :

1. Exécutez VMware-Migration-Assistant à partir du dossier migration-assistant sur le disque dur :

1. Lors de son initialisation, vous serez invité à saisir le mot de passe administrateur SSO. Tapez le mot de passe et appuyez sur Entrée ; il commencera à exécuter des vérifications préalables.
2. Une fois les vérifications préalables terminées, il affichera la configuration source et confirmera qu’il est prêt à démarrer le processus de migration:

1. L’assistant de migration doit continuer de fonctionner jusqu’à la fin de la mise à niveau. Ne fermez pas la fenêtre avant d’avoir terminé.

Pendant la mise à niveau de vCenter Server, si Update Manager s’exécute sur une autre machine Windows, l’assistant de migration doit également être exécuté sur celle-ci.

Comment ça marche

migration-assistant doit être exécuté séparément sur les machines hébergeant les services vCenter / PSC / Update Manager avant de lancer la migration / mise à niveau de vCenter. Le processus de migration / mise à niveau migre uniquement les données de tous les serveurs de composants avec une session d’assistant de migration active .

Si le programme d’installation détecte un plug-in Update Manager enregistré sur vCenter et si l’assistant de migration n’est pas actif sur la machine Windows exécutant le service Update Manager, l’installation peut échouer en l’indiquant.

Mise à niveau des contrôleurs de services de plate-forme (PSC)

Dans un environnement où les PSC sont externalisés, vous devrez d’abord mettre à niveau tous les PSC d’un domaine SSO avant de mettre à niveau les serveurs vCenter correspondants. Pendant la mise à niveau, les PSC seront d’une version ultérieure par rapport à leurs vCenters correspondants. Une telle configuration de version mixte n’est prise en charge qu’au cours de la mise à niveau.

Dans cette recette, nous apprendrons comment mettre à niveau ou migrer des PSC.

Se préparer

Vous aurez besoin des éléments suivants avant de procéder à la mise à niveau :

• Une compréhension de la topologie actuelle : vous devrez identifier tous les PSC dans un seul domaine SSO. Les vCenters correspondant à ces PSC seront dans une configuration ELM ( Enhanced Linked Mode ).
• Adresses IP temporaires pour les appliances PSC qui seront déployées : Une IP temporaire est attribuée à l’appliance lors de son installation afin que les données / configuration puissent être transférées du PSC source vers l’appliance. Le nouvel appareil prendra l’identité du PSC source lors de la dernière étape de la mise à niveau (une fois le transfert de données terminé).
• Créez un instantané du PSC source (facultatif).

Comment le faire

La procédure suivante vous guidera à travers les étapes de la mise à niveau des PSC (Windows / Appliance) vers PSC 6.7.

Migration de PSC (Windows) vers PSC (Appliance) 6.7

1. Exécutez l’assistant de migration sur le PSC source. Pour obtenir des instructions, lisez la recette Running VMware Migration Assistant.
2. Exécutez le programme d’installation de VCSA 6.7 à partir d’une machine autre que le PSC source.

L’emplacement du programme d’installation pour Windows est CDROM : \ vcsa-ui-installer \ win32 \ installer.exe.

Migrer – Étape 1: déployer l’appliance :

1. Sur l’écran du programme d’installation de vCenter Server Appliance 6.7 – Étape 1: Déployer l’appliance, cliquez sur Migrer.
2. Sur l’écran Introduction, cliquez sur Suivant pour continuer.
3. Acceptez le contrat de licence utilisateur final et cliquez sur Suivant pour continuer.
4. Sur l’écran Se connecter au serveur source, indiquez l’adresse FQDN / IP de la machine Windows source exécutant le PSC et les informations d’identification de l’administrateur SSO. Cliquer sur Suivant pour continuer :

1. Sur l’écran Vérifier l’empreinte numérique, comparez l’empreinte numérique avec la configuration source capturée par l’assistant de migration (sous Paramètres de migration dans la fenêtre Assistant de migration sur la source) et cliquez sur Oui pour continuer.
2. Sur l’écran cible de déploiement de l’appliance, indiquez l’adresse IP / FQDN de l’hôte ESXi sur lequel l’appliance sera déployée et fournissez les informations d’identification racine ESXi. Cliquer sur Suivant pour continuer :

1. Sur l’écran Avertissement de certificat, vérifiez l’empreinte numérique de l’hôte ESXi et cliquez sur Oui.
2. Dans l’écran Configurer la machine virtuelle de l’appliance cible, spécifiez un nom pour la machine virtuelle de l’appliance PSC et définissez le mot de passe racine. Lorsque vous avez terminé, cliquez sur Suivant pour continuer :

1. Sur l’écran Sélectionner la banque de données, choisissez la banque de données souhaitée pour placer la machine virtuelle. Si vous le souhaitez, vous pouvez choisir d’allouer de manière dynamique ses VMDK en cochant la case Activer le mode disque léger. Cliquer sur Suivant pour continuer.
2. Dans l’écran Configurer les paramètres réseau, sélectionnez le groupe de ports pour la machine virtuelle de l’appliance PSC à connecter à une configuration d’adresse IP temporaire. Cliquer sur Suivant pour continuer :

1. Sur l’écran de l’étape 1 Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer.
2. Une fois que l’appliance PSC a été déployée avec succès, il confirmera la même chose et suggérera de passer à l’étape 2. Cela peut être fait en cliquant sur CONTINUER ou en utilisant la page https://Temp-IP:5480 :

Migrer – Étape 2: Appliance Platform Service Controller :

1. Dans l’écran Introduction de l’assistant Migrate – Étape 2 : Appliance Platform Service Controller, cliquez sur Suivant pour continuer.
2. Sur l’écran Connexion à la source SSO ou PSC, la plupart des informations sont préremplies (y compris le mot de passe SSO). Cliquer sur Suivant pour continuer :

1. Il effectue ensuite une vérification de prémigration et passe à l’ écran Join AD Domain. Fournissez les informations d’identification AD pour joindre l’appliance PSC au domaine et cliquez sur Suivant pour continuer:

1. Sur l’écran Configurer le CIEP, vous pouvez choisir de rejoindre ou de ne pas rejoindre le CIEP. Faites un choix et cliquez sur Suivant pour continuer.
2. Sur l’écran Prêt à terminer, cochez la case qui confirme que vous avez sauvegardé le PSC source , vérifiez les paramètres et cliquez sur TERMINER:

1. Sur l’écran Avertissement d’arrêt, cliquez sur OK.
2. Le programme d’installation va commencer à copier les données du PSC source vers le PSC cible, arrêter le PSC source, puis configurer le PSC cible pour prendre l’identité du PSC source, démarrer les services et importer les données / la configuration qui a été copiée de la source PSC.
3. Une fois le déploiement terminé, un écran Migrate – Étape 2 : Terminé s’affiche. Cliquez sur FERMER pour quitter le programme d’installation :

Ceci termine la migration de PSC (Windows) vers PSC 6.7 (Appliance).

Mise à niveau de l’ appliance PSC vers PSC 6.7

Contrairement à la migration depuis PSC (Windows), la mise à niveau d’une appliance ne nécessite pas l’utilisation d’un assistant de migration. Commençons :

Mise à niveau – Étape 1: Déployez l’appliance PSC cible :

1. Exécutez le programme d’installation VCSA à partir d’une machine disposant d’un accès réseau au PSC source et à l’hôte ESXi de destination sur lequel le PSC cible sera placé.
2. Dans l’écran du programme d’installation de vCenter Server Appliance 6.7 – Étape 1: Déployer l’appliance, cliquez sur Mettre à niveau.
3. Sur l’écran Introduction, cliquez sur Suivant pour continuer.
4. Acceptez le contrat de licence utilisateur final et cliquez sur Suivant pour continuer.
5. Sur l’écran Se connecter à l’appliance source, indiquez l’adresse FQDN / IP de l’appliance PSC source et cliquez sur CONNECTER À LA SOURCE:

1. Si le programme d’installation peut se connecter à l’appliance PSC source, le même écran est automatiquement développé pour demander des détails supplémentaires, tels que le mot de passe racine de l’appliance PSC, l’adresse FQDN / IP de l’ESXi / vCenter qui gère la machine virtuelle de l’appliance PSC source, et le nom d’utilisateur / mot de passe (root si les informations d’identification ESXi ou SSO si vCenter). Fournissez les détails demandés et cliquez sur Suivant pour continuer :

1. L’avertissement de certificat affiche les empreintes pour le PSC source et pour la gestion d’ESXi / vCenter. Cliquez sur Oui pour confirmer.
2. Sur l’écran cible de déploiement de l’appliance, spécifiez un ESXi / vCenter cible et ses informations d’identification :

1. L’avertissement de certificat affiche l’empreinte numérique de l’ESXi / vCenter cible. Cliquez sur Oui pour confirmer.
2. Dans l’écran Configurer la machine virtuelle de l’appliance cible, spécifiez un nom pour la machine virtuelle PSC cible et définissez un mot de passe racine pour l’appliance:

1. Sur l’écran Sélectionner la banque de données, choisissez la banque de données souhaitée pour placer la machine virtuelle. Si vous le souhaitez, vous pouvez choisir d’allouer de manière dynamique ses VMDK en cochant la case Activer le mode Think Disk. Cliquer sur Suivant pour continuer.
2. Dans l’écran Configurer les paramètres réseau, sélectionnez un groupe de ports pour la machine virtuelle de l’appliance PSC cible et spécifiez une configuration d’adresse IP temporaire. Cliquer sur Suivant pour continuer :

1. Sur l’écran Prêt à terminer l’étape 1, vérifiez les paramètres et cliquez sur Terminer.
2. Une fois que l’appliance PSC cible a été déployée avec succès, elle confirmera la même chose et vous suggérera de passer à l’étape 2, ce qui peut être fait en cliquant sur Continuer ou en utilisant la page https://Temp-IP:5480 .

Mise à niveau – Étape 2: utilisez l’assistant de Platform Services Controller Appliance :

1. Dans l’écran Mise à niveau – Étape 2 : Introduction, cliquez sur Suivant pour continuer.
2. Sur l’écran Se connecter au PSC source, indiquez le PSC source et les détails de gestion d’ESXi / vCenter. Cliquer sur Suivant pour continuer.
3. Il va maintenant effectuer une vérification préalable à la mise à niveau et passer à l’écran suivant.
4. Sur l’écran Configurer CEIP, choisissez de rejoindre ou de ne pas rejoindre VMware CEIP et cliquez sur Suivant pour continuer.
5. Sur l’écran Prêt à terminer, vérifiez les paramètres et utilisez la case à cocher pour confirmer que l’appliance PSC source a été sauvegardée. Cliquez ensuite sur Terminer.
6. Sur l’écran Avertissement d’arrêt, cliquez sur OK.
7. Une fois la mise à niveau terminée, un écran Upgrade – Stage 2: Complete vous sera présenté . Cliquez sur Fermer pour quitter le programme d’installation.

Ceci termine la mise à niveau du Platform Service Controller.

Comment ça marche

Le processus de migration déploie une vCSA Appliance et importe les données de l’installation de Windows vCenter. Il conserve l’adresse IP, l’UUID, le nom d’hôte, les certificats SSL et les ID de référence des objets de gestion du vCenter Server ; par conséquent, une fois l’installation terminée, la machine Windows vCenter Server est arrêtée. Si, pour une raison quelconque, la mise à niveau échoue et que la machine vCenter Windows est arrêtée, il vous suffit de mettre hors tension la machine virtuelle VCSA et de mettre sous tension la machine vCenter Windows. Le processus de mise à niveau et de migration n’apportera aucune modification à la machine Windows source.

Tous les PSC de votre infrastructure vCenter doivent être mis à niveau avant de mettre à niveau vCenter Server. Par conséquent, vous devez répéter la même procédure sur d’autres PSC dans le même domaine SSO. Une fois que tous les PSC ont été migrés / mis à niveau, vous pouvez procéder à la migration / mise à niveau de vCenter Server.

Mise à niveau des serveurs vCenter

vSphere 6.7 est la dernière version à inclure ou à prendre en charge l’installation de vCenter sous Windows. À l’avenir, toutes les versions de vCenter seront des appliances. Par conséquent, il est logique d’adopter le modèle d’appareil. Un vCenter basé sur Windows peut être migré (pendant le processus de mise à niveau) pour devenir une appliance.

Dans cette recette, nous couvrirons les étapes impliquées dans la mise à niveau de vCenter, en supposant que leurs PSC correspondants ont déjà été mis à niveau.

Se préparer

Vous aurez besoin des éléments suivants pour pouvoir compléter cette recette :

• VCSA 6.7 Installer ISO
• FQDN ou adresse IP du vCenter source
• IP temporaires pour le VCSA

Comment le faire

La procédure suivante vous guidera à travers les étapes de la mise à niveau d’une paire vCenter et PSC Windows vers les appliances VCSA 6.7 et PSC 6.7:

Mise à niveau – Étape 1: Déployer vCenter Server: Déployez l’appliance cible :

1. Montez l’ISO vCSA 6.7 Installer sur une machine Windows.
2. Exécutez le programme d’installation à partir de la source, c’est-à-dire CD – ROM : \ vcsa-ui-installer\win32\installer.exe.
3. Sur l’écran du programme d’installation de vCenter Server Appliance 6.7 – Étape 1 : Déployer l’appliance , cliquez sur Migrer.
4. Sur l’écran Introduction, cliquez sur Suivant pour continuer.
5. Acceptez le contrat de licence utilisateur final et cliquez sur Suivant pour continuer.
6. Sur l’écran Se connecter à l’appareil source, fournissez les détails de l’appareil source (FQDN / IP source, informations d’identification SSO, mot de passe racine de l’appareil source) et la gestion ESXi / vCenterFQDN / IP et ses informations d’identification :

Acceptez l’avertissement de certificat, si vous y êtes invité.

1. Sur l’écran cible de déploiement de l’appliance, spécifiez les détails du vCenter / ESXi sur lequel l’appliance cible sera déployée et cliquez sur Suivant pour continuer.
2. Dans l’écran Configurer la machine virtuelle de l’appareil cible, spécifiez un nom pour la machine virtuelle de l’appareil cible et définissez le mot de passe racine de l’appareil cible.
3. Dans l’écran Sélectionner la taille de déploiement, choisissez une taille de déploiement (petite, petite, moyenne, grande ou très grande). Une taille de stockage par défaut est choisie en fonction du type de déploiement sélectionné, mais vous pouvez choisir une taille de stockage non par défaut si vous le souhaitez. Faites un choix et cliquez sur Suivant pour continuer.
4. Sur l’écran Sélectionner la banque de données, choisissez un emplacement pour la machine virtuelle cible, choisissez d’alléger la provision si vous le souhaitez, puis cliquez sur Suivant pour continuer.
5. Sur l’écran Configurer les paramètres réseau, sélectionnez un groupe de ports auquel connecter la machine virtuelle cible et spécifiez la configuration IP temporaire. Celui-ci sera utilisé lors du transfert de données. Cliquer sur Suivant pour continuer.
6. Sur l’écran Prêt à terminer l’étape 1, vérifiez les paramètres et cliquez sur Terminer.
7. Une fois que l’appliance VCSA a été déployée avec succès, elle confirmera la même chose et vous suggérera de passer à l’étape 2. Cela peut être fait en cliquant sur Continuer ou en utilisant la page https: // Temp-IP: 5480 .

Mise à niveau – Stage 2 vCenter Appliance :

1. En cliquant sur Continuer, vous serez redirigé vers l’assistant de mise à niveau – Étape 2: vCenter Appliance.
2. Sur l’écran Introduction, cliquez sur Suivant.
3. L’écran Se connecter à la source utilisera des détails préremplis pour démarrer automatiquement la vérification de pré-mise à niveau. Si ce n’est pas le cas, entrez les détails lorsque vous y êtes invité et cliquez sur Suivant.
4. Une fois les vérifications préalables à la mise à niveau terminées, un écran de résultats de vérification préalable à la mise à niveau peut s’afficher. Si vous l’êtes, cliquez sur FERMER pour continuer :

1. Sur l’écran Sélectionner les données de mise à niveau, vous pouvez choisir de transférer uniquement la configuration ou inclure des données historiques et des mesures de performances. Par défaut, seule la configuration est sélectionnée. Faites la sélection souhaitée et cliquez sur Suivant pour continuer:

1. Sur l’écran Prêt à terminer, vérifiez les paramètres et utilisez la case à cocher pour confirmer que vous avez sauvegardé l’appliance source. Cliquez ensuite sur Terminer:

Cliquez sur OK dans l’avertissement d’arrêt indiquant que l’appliance source sera finalement arrêtée.

1. Une fois la mise à niveau terminée, un écran Upgrade – Stage 2: Complete vous sera présenté . Cliquez sur Fermer pour quitter le programme d’installation.

Ceci termine la mise à niveau du vCSA.

Comment ça marche

La procédure de migration d’un vCenter à partir de Windows est similaire, à l’exception de l’exécution de VMware Migration Assistant sur les machines Windows source exécutant vCenter Server et Update Manager.

Utilisation de l’outil de convergence vCenter

À partir de vSphere 6.7, il n’est pas nécessaire d’externaliser le PSC pour ELM, ce qui simplifie la protection des serveurs vCenter à l’aide de vCenter High Availability ( vCHA ). Cependant, si votre environnement existant possède des PSC externes, leur mise à niveau vers vCenter 6.7 conservera la même topologie.

Avec vCenter 6.7 Update 1, VMware comprend un outil de convergence, qui peut être utilisé pour installer des composants PSC dans les nœuds VCSA 6.7U1 existants et migrer la configuration PSC des PSC externes vers celui-ci, éliminant ainsi les nœuds PSC externes.

PSC 6.7 U1 (Windows) ne peut pas être converti en composants intégrés d’un vCenter existant. Les outils de convergence ne fonctionnent qu’avec vCenter et les appareils PSC.

Au moment de la publication de ce livre, la version la plus récente était vCenter 6.7 U2. La mise à jour 2 comprend une version GUI de l’outil de convergence. Cependant, le problème est que les PSC source devraient également exécuter 6.7U2. Pour plus de détails, reportez-vous à la démonstration de VMware Tech Pubs – https://youtu.be/HlL4KzAPx0c

Se préparer

Les conditions suivantes doivent être remplies avant de pouvoir utiliser l’outil de convergence vCenter :

• vCenter et PSC doivent être des appliances exécutant la version 6.7 Update 1 ou ultérieure.
• vCHA doit être désactivé. Notez qu’il ne s’agit pas de vSphere HA.
• Créez des instantanés sur les vCSA et les PSC.
• Vous pouvez également créer des sauvegardes basées sur des fichiers vCSA du VCSA et des PSC.
• Passez en revue le vCenter pour tous les plugins / solutions qui sont actuellement enregistrés et authentifiez-les avec PSC. Ceci est nécessaire car l’adresse IP et le nom de domaine complet du PSC changeront après leur convergence vers le vCSA.
• Définissez le niveau d’automatisation de vSphere Distributed Resource Scheduler (DRS) sur Manual sur le cluster de destination pour éviter la migration du vCSA cible ou du PSC source pendant la convergence.

Comment faire

La procédure suivante vous guidera à travers les étapes de la migration des composants PSC et de leur configuration vers un vCSA existant :

1. Assurez-vous que les conditions préalables mentionnées dans la section Préparation sont remplies.
2. Notez le Type du vCenter dans l’onglet Résumé du VAMI du vCenter. Il doit lire vCenter Server avec un Platform Services Controller externe :

1. Montez l’ISO du programme d’installation VCSA 6.7U1 sur une machine Windows.
2. Localisez le fichier converge.json sur le lecteur de DVD. Il doit être dans vcsa-converge-cli \ templates \ converge :

1. Copiez le fichier converge.json dans un emplacement de lecture / écriture, tel que C: \ Converge \ converge.json . Ouvrez le fichier dans un éditeur de texte enrichi tel que WordPad et spécifiez les détails demandés. Ensuite, enregistrez les modifications:

1. Démarrez l’invite de commandes Windows en tant qu’administrateur et accédez au répertoire DVD ROM: \ vcsa-converge-cli \ win32 . Ensuite, exécutez la commande suivante:

vcsa-util.exe converge –no-ssl-certificate-verification –backup-taken –verbose <Ptch to converge.json>

Voici la sortie de la commande précédente:

1. Une fois la convergence terminée, il l’indiquera et recommandera un redémarrage. Appuyez sur Y pour continuer :

1. Une fois terminé, l’onglet Résumé de vCenter indiquera qu’il s’agit désormais d’un vCenter avec un Platform Services Controller intégré :

1. Une fois la convergence terminée, l’étape suivante consiste à mettre hors service le PSC source qui a réussi à converger.

Une règle générale consiste à s’assurer que tous les serveurs vCenter enregistrés auprès des PSC ont convergé avant de procéder à la mise hors service des PSC externes. Passez à la section suivante pour savoir comment désactiver les PSC externes.

Comment ça marche

Pendant la convergence, les composants PSC sont installés sur l’appliance vCenter cible, puis le PSC intégré est joint au même domaine SSO que le PSC externe, établissant ainsi un accord de réplication avec lui. Une fois cela fait, le vCenter est automatiquement rejoint par le PSC intégré.

Lors de la mise hors service des PSC externes déjà convergés, le nœud PSC est arrêté et il n’est pas enregistré du domaine SSO. La tâche de désinscription est automatiquement exécutée à partir du vCenter avec le PSC nouvellement intégré.

La convergence des PSC en appliances intégrées réduit la complexité de votre topologie vCenter et élimine la nécessité de disposer de nœuds PSC à l’aide d’équilibreurs de charge réseau.

Mise à niveau d’ESXi à l’aide du programme d’installation interactif

Une fois que vous avez terminé la mise à niveau de la couche de gestion (vCenters / PSC), les hôtes ESXi de l’environnement peuvent être mis à niveau. Il existe plusieurs façons de mettre à niveau les hôtes ESXi, et la façon dont vous le faites dépend également de la façon dont ils ont été déployés précédemment. Par exemple, si les hôtes exécutent des hôtes ESXi sans état / avec état et déployés automatiquement, il ne serait pas logique d’utiliser le programme d’installation interactif pour mettre à niveau les hôtes. L’hôte ESXi peut être mis à niveau sans avoir besoin de se connecter à chacun d’eux à l’aide de VMware Update Manager. Nous apprendrons comment utiliser Update Manager au chapitre 14, Mise à niveau et correctif à l’aide de vSphere Update Manager.

D’autres méthodes incluent l’utilisation de l’ESXi CLI ou d’un script kickstart.

Dans cette recette, nous allons apprendre à utiliser l’installateur interactif pour mettre à niveau ESXi.

Se préparer

Voici ce que vous devrez faire avant de pouvoir mettre à niveau ESXi vers ESXi 6.7:

• Assurez-vous que le matériel est compatible avec ESXi 6.
• Assurez-vous que la version en cours d’exécution est ESXi 6.0 U3 ou version ultérieure.
• Téléchargez l’image ISO OEM ESXi 6.7 pour l’installation.
• Assurez-vous que vous avez accès à la console des serveurs à l’aide des interfaces d’accès à distance IPMI (DRAC, ILO, KVM, etc.).

Comment faire

La procédure suivante vous guidera à travers les étapes de la mise à niveau d’ESXi vers ESXi 6.7:

1. Montez l’ISO sur le serveur via son interface IPMI.
2. Démarrez le serveur de l’ISO. Contrairement à l’ancienne version des programmes d’installation, il ne vous présente plus le menu de démarrage du programme d’installation. Au lieu de cela, il commence à charger le programme d’installation en mémoire et affiche ensuite un écran Bienvenue dans l’installation ESXi. Appuyez sur Entrée pour continuer.
3. Sur l’écran CLUF, appuyez sur F11 pour accepter et continuer.
4. Sur l’écran Sélectionner un disque à installer ou à mettre à niveau, vous devrez sélectionner le périphérique qui contient l’installation précédente. Si vous n’êtes pas sûr, sélectionnez un appareil et appuyez sur F1 pour trouver ses détails.
5. Si l’écran Détails du disque indique qu’il a une installation précédente d’ESXi dessus, alors vous avez le bon périphérique :

Écran Détails du disque avec l’installation précédente détectée

1. Appuyez sur Entrée pour revenir à l’écran Sélectionner un disque à installer ou à mettre à niveau. Appuyez de nouveau sur Entrée pour confirmer la sélection et continuer.
2. Sur l’écran ESXi et VMFS trouvé, choisissez de mettre à niveau ESXi, de conserver la banque de données VMFS et appuyez sur la touche Entrée pour continuer:

Options d’installation

1. Sur l’écran Confirmer la mise à niveau, passez en revue les détails et appuyez sur F11 pour lancer la mise à niveau :

1. Si la mise à niveau se termine avec succès, un écran de mise à niveau terminée s’affichera. Démontez l’ISO de la console du serveur et appuyez sur Entrée pour redémarrer:

Ceci termine la mise à niveau d’ESXi à l’aide du programme d’installation interactif ESXi 6.7.

Comment ça marche

Le programme d’installation interactif ESXi détecte une installation existante et vous permet de la mettre à niveau si vous le souhaitez. La mise à niveau peut être effectuée en préservant le volume VMFS local ou en le remplaçant simplement. Dans la plupart des cas, vous conservez toutes les données disponibles.

Mise à niveau d’ESXi à l’aide de l’interface de ligne de commande

ESXi peut être mis à niveau à partir de la CLI. Contrairement à la méthode interactive, la CLI nécessite l’utilisation d’un ensemble ZIP hors ligne.

Voici ce dont vous aurez besoin pour effectuer une mise à niveau ESXi à l’aide de la CLI :

• Assurez-vous que le matériel est compatible avec ESXi 6.7.
• Assurez-vous que la version en cours d’exécution est ESXi 6.0 U3 ou version ultérieure.
• Téléchargez le fichier .zip du pack hors ligne OEM ESXi 6.7.
• Accès SSH à l’hôte ESXi et au mot de passe root.

Comment le faire

La procédure suivante vous guidera à travers les étapes de mise à niveau d’un hôte ESXi à partir de son interface de ligne de commande :

1. Téléchargez-le package ZIP hors ligne ESXi dans l’une des banques de données accessibles par l’hôte ESXi. Cela peut être fait en utilisant la fonction de téléchargement du navigateur de magasin de données vCenter / ESXi.
2. SSH dans l’hôte ESXi en tant qu’utilisateur root.
3. Exécutez la commande esxcli software sources profile list sur le bundle hors ligne pour répertorier tous les profils d’image inclus dans le bundle :
   • Syntax: esxcli software sources profile list -d /vmfs/volumes/oldesx02_local/<Full Path to the Offline Bundle>
   • Example: esxcli software sources profile list -d /vmfs/volumes/oldesx02_local/update-from-esxi6.7-6.7_update01.zip
4. Exécutez la commande de mise à jour du profil du logiciel esxcli pour effectuer une mise à niveau à l’aide du profil d’image souhaité du bundle hors ligne :
   • Syntax: esxcli software profile update -p <Image Profile>-d <Full Path to the Offline Bundle>
   • Example: esxcli software profile update -p ESXi-6.7.0-20181002001-standard -d /vmfs/volumes/oldesx02_local/update-from-esxi6.7-6.7_update01.zip

Écran de sortie de mise à jour du profil du logiciel esxcli

1. Redémarrez l’hôte ESXi.

Ceci termine la méthode CLI de mise à niveau d’ESX.

Comment ça marche

La méthode de mise à niveau de l’ESXi CLI est une alternative au programme d’installation interactif. Avec la méthode d’installation interactive, l’ESXi doit démarrer l’image ISO pour effectuer la mise à niveau, ce qui signifie que vous auriez besoin d’un accès physique au serveur ou d’un accès à son interface IPMI.

Cependant, avec la méthode CLI, la mise à niveau peut être effectuée pendant que ESXi est opérationnel. Cela se fait via une session SSH vers l’hôte et ne nécessite qu’un seul redémarrage. Vous ne pouvez pas utiliser une image ISO du programme d’installation ESXi pour effectuer l’installation CLI – cela ne peut être réalisé qu’en utilisant un ensemble hors ligne. Un ensemble hors ligne peut avoir plusieurs profils d’image, et l’un d’entre eux doit être spécifié pour effectuer la mise à niveau. Vous en apprendrez plus sur les profils d’image au chapitre 11, Création d’images ESXi personnalisées à l’aide d’Image Builder.

Configuration de l’accès réseau à l’aide de commutateurs standard vSphere

La mise en réseau est l’épine dorsale de toute infrastructure, qu’elle soit virtuelle ou physique. Il permet des connexions entre divers composants d’infrastructure. En ce qui concerne les composants réseau traditionnels côté serveur, nous parlons souvent d’un ou plusieurs adaptateurs physiques câblés à un commutateur physique. Mais les choses changent légèrement lorsque vous installez un hyperviseur sur un serveur et exécutez une machine virtuelle par-dessus. Alors pourquoi et qu’est-ce qui devrait changer ?

Premièrement, maintenant que nous pouvons créer des machines virtuelles sur l’hyperviseur, chacune des machines virtuelles aurait besoin d’une identité réseau pour lui permettre de faire partie d’un réseau. Par conséquent, nous créons des vNIC sur la machine virtuelle, qui apparaîtront comme des adaptateurs réseau au système d’exploitation invité (Windows / Linux) qui s’exécute à l’intérieur de la machine virtuelle.

Maintenant que nous avons pris soin de la connexion réseau de la machine virtuelle, le deuxième obstacle est de laisser les machines virtuelles communiquer sur le réseau. Sur un serveur, étant donné qu’il y aurait un nombre limité de cartes réseau physiques, il est difficile de présenter ces cartes réseau à des machines virtuelles individuelles. Par exemple, si vous deviez exécuter 20 machines virtuelles sur un hôte avec quatre cartes réseau physiques, il devrait y avoir un moyen d’autoriser efficacement toutes les machines virtuelles à partager les ressources physiques de la carte réseau. Le partage du matériel d’interface réseau physique est réalisé en activant une couche d’abstraction appelée le commutateur virtuel vSphere.

Le commutateur virtuel (ou simplement vSwitch) est une construction de commutation logicielle qui fournit une infrastructure réseau pour les machines virtuelles exécutées sur un hôte. Il vous permet d’agréger les connexions réseau de plusieurs vNIC, leur applique des stratégies de configuration réseau et les épingle également aux adaptateurs réseau physiques sur les hôtes ESXi pour la circulation. Contrairement à un commutateur physique, un vSwitch n’est pas un commutateur géré. Il n’apprend pas les adresses MAC et ne crée pas de table de mémoire adressable de contenu (CAM) comme un commutateur physique, mais il dispose de suffisamment d’intelligence pour prendre connaissance des adresses MAC des vNIC de machine virtuelle qui lui sont connectées.

Il existe deux autres couches d’abstraction, appelées groupes de ports de machine virtuelle et groupe de ports VMkernel . Un groupe de ports, en général, est une méthode pour regrouper un ensemble de ports virtuels sur un vSwitch sous un parapluie de configuration commun. Un groupe de ports de machine virtuelle ne peut être utilisé que pour y connecter des interfaces réseau de machine virtuelle. Un groupe de ports VMkernel est formé lors de la création d’une interface VMkernel. Nous en apprendrons plus à ce sujet plus loin dans ce chapitre.

vSphere Standard Switch est une construction de commutation logicielle créée et gérée par l’hôte ESXi. D’un autre côté, vSphere Distributed Switch est géré par vCenter Server, éliminant ainsi la nécessité de gérer des commutateurs virtuels locaux sur chaque hôte ESXi. Nous en apprendrons davantage sur les commutateurs distribués dans le chapitre suivant.

Dans ce chapitre, nous couvrirons les recettes suivantes :

• Création de commutateurs standard vSphere
• Création de groupes de ports de machine virtuelle sur des commutateurs standard vSphere
• Création d’interfaces VMkernel supplémentaires sur les commutateurs standard vSphere
• Création de piles TCP / IP VMkernel supplémentaires
• Gestion des liaisons montantes physiques d’un commutateur standard vSphere
• Configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement

Création de commutateurs standard vSphere

Un vSwitch est local à chaque hôte ESXi. Un commutateur standard par défaut, vSwitch0 , avec un groupe de ports de gestion et un groupe de ports de machine virtuelle est créé lors de l’installation d’ESXi. Dans cette recette, nous allons apprendre à créer de nouveaux commutateurs standard vSphere en utilisant à la fois le client HTML5 et la CLI ESXi.

Se préparer

Avant de commencer, il est important d’identifier les bonnes liaisons montantes. Toutes les liaisons montantes physiques sur un hôte ne peuvent pas passer tout le trafic. Par exemple, seul un certain nombre de VLAN seraient connectés aux ports de commutation physiques auxquels la ou les liaisons montantes sont câblées.

Comment faire

La procédure suivante vous guidera à travers les étapes impliquées dans la création d’un vSphere Standard Switch (vSwitch) à l’aide du client HTML5. Nous utiliserons l’assistant d’ajout de réseau pour accomplir cette tâche. Cet assistant peut être lancé à partir de divers points de vue dans l’inventaire. Dans cette recette, nous utiliserons la section de configuration de mise en réseau de l’hôte. Nous allons commencer par apprendre à créer un vSwitch à l’aide du client HTML5, puis à utiliser la CLI ESXi.

Création d’un vSwitch à l’aide du client HTML5

Voici les étapes de création de vSwitches:

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Dans la vue d’inventaire Hosts and Clusters, sélectionnez l’hôte ESXi sur lequel créer le vSwitch.
3. Accédez à Configurer | Réseautage | Commutateurs virtuels et cliquez sur Ajouter un réseau … pour démarrer l’assistant:
4. Dans l’assistant Ajouter un réseau, définissez le type de connexion sur Carte réseau physique et cliquez sur Suivant :
5. Dans l’écran Sélectionner le périphérique cible, choisissez de créer un nouveau commutateur standard et laissez la MTU (octets) à la valeur par défaut de 1 500 octets, sauf s’il est nécessaire de l’augmenter. Cliquer sur Suivant pour continuer :
6. Dans l’écran Créer un commutateur standard – Adaptateurs attribués, vous devrez affecter des adaptateurs réseau (vmnic) au vSwitch. Cliquez sur l’icône + pour afficher la fenêtre Ajouter des adaptateurs physiques à la fenêtre Switch :
7. Sur l’écran Ajouter des adaptateurs physiques au commutateur, sélectionnez les vmnics à ajouter et cliquez sur OK :
8. Une fois que vous êtes de retour sur l’écran Créer un commutateur standard – Adaptateurs attribués, vous verrez la liste des adaptateurs sélectionnés en tant qu’adaptateurs actifs. Vous pouvez l’utiliser pour supprimer ou modifier l’ordre des vmnics:
9. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer :
10. Le volet Tâches récentes doit indiquer qu’une tâche de mise à jour du réseau de configuration s’est terminée avec succès.
11. Une fois cela fait, le vSwitch nouvellement créé doit être répertorié comme l’un des commutateurs virtuels sous Configurer | Réseautage | Commutateurs virtuels.

Création d’un vSwitch à l’aide de l’interface de ligne de commande ESXi

Les commutateurs standard vSphere peuvent également être créés à l’aide de l’ESXi CLI. La procédure nécessite que vous accédiez à la console de ligne de commande de l’hôte ESXi via une console IPMI (HPE ILO, Dell DRAC, KVM, etc.) ou SSH dans l’hôte ESXi à l’aide d’outils tels que PuTTY ou SecureCRT. Commençons :

1. SSH (PuTTY) dans l’hôte ESXi en tant qu’utilisateur root.
2. Exécutez la commande esxcfg-nics -l pour répertorier toutes les cartes réseau physiques sur l’hôte.
3. Créez un commutateur vSphere Standard à l’aide de la syntaxe de commande suivante :

# esxcli network vswitch standard add -v <Nom du vSwitch>

1. Ajoutez une liaison montante au vSwitch nouvellement créé à l’aide de la syntaxe de commande suivante :

# esxcli network vswitch standard uplink add -u <Nom du vmnic> -v <Nom du vSwitch créé>

1. Exécutez la commande suivante (syntaxe) pour afficher les détails du vSwitch nouvellement créé :

# esxcli network vswitch standard list -v <Nom du vSwitch créé>

Voici la sortie des commandes précédentes :

Ceci termine le processus de création d’un vSwitch standard à l’aide de l’ESXi CLI.

L’un des avantages de l’utilisation de l’interface de ligne de commande est qu’elle vous permettra de créer un vSwitch avec un nom défini par l’utilisateur. La méthode GUI qui utilise le client HTML5 utilise la convention de dénomination vSwitchX.

Comment ça marche

Le vSwitch standard est une construction réseau de base de l’hyperviseur ESXi. Le diagramme suivant est une représentation logique d’un commutateur standard vSphere. Il montre un vSwitch unique avec des groupes de ports utilisant deux NIC physiques connectés à deux commutateurs empilés.

Un vSwitch – vSwitch0 – est créé pendant l’installation pour configurer l’interface de gestion VMkernel (vmk0) sur celui-ci.

Pour comprendre le fonctionnement d’un commutateur virtuel, il est essentiel de comparer ses fonctions à un commutateur physique.

Lorsqu’une trame entre dans un commutateur physique, sa destination est déterminée par le numéro de port du commutateur correspondant à son adresse MAC de destination dans la table MAC du commutateur physique. S’il ne trouve pas d’entrée dans la table MAC, il inonde la trame via tous les ports autres que le port source. Tout comme le commutateur physique, un commutateur virtuel maintient également une table MAC, mais il n’y a pas de processus d’apprentissage pour un commutateur virtuel. Un commutateur virtuel aura déjà une liste d’adresses MAC et leurs numéros de port virtuels. Si une trame avec un MAC de destination qui n’est pas présent dans la table MAC du commutateur virtuel entre dans un commutateur virtuel, elle est envoyée via des cartes réseau physiques (liaisons montantes actives) qui sont connectées au commutateur virtuel. Cela n’est vrai que si une machine virtuelle ou une interface VMkernel est la source du flux, c’est-à-dire uniquement si cette trame entre via un port virtuel. Si une trame avec un MAC inconnu entre dans le commutateur virtuel via ses liaisons montantes physiques, cette trame sera abandonnée par le commutateur virtuel.

Les commutateurs physiques auront un nombre fixe de ports ; cependant, un commutateur virtuel aura une limite maximale mais un grand nombre de ports configurables. La troisième différence est que, contrairement à certains ou à la plupart des commutateurs physiques ; ce n’est pas un commutateur gérable, en soi, ce qui signifie qu’il n’a pas sa propre adresse IP de gestion ou un système d’exploitation tel que Cisco IOS. Au lieu de cela, les commutateurs virtuels sont gérés au niveau de l’hyperviseur ou du vCenter, selon le type de commutateur virtuel (vSwitch standard ou VDS) utilisé.

Création de groupes de ports de machine virtuelle sur des commutateurs standard vSphere

Les groupes de ports sont des conteneurs logiques créés sur un commutateur virtuel. Considérez-les comme des agrégateurs de ports auxquels des politiques de configuration et de gestion du trafic peuvent être appliquées ; par exemple, un ID VLAN peut être défini sur un groupe de ports. Les machines virtuelles bénéficient d’un accès réseau lorsque vous connectez leurs cartes réseau virtuelles à un groupe de ports.

Dans cette recette, nous allons apprendre à créer un groupe de ports de machine virtuelle.

Se préparer

Avant de commencer, vous aurez besoin des informations suivantes :

• Le nom souhaité (étiquette réseau) pour le groupe de ports. Il est important de noter que le nom est sensible à la casse.
• Liaisons montantes physiques (vmics) à utiliser pour le groupe de ports (facultatif).
• Un ID VLAN facultatif. Si un ID VLAN est utilisé, il est essentiel d’identifier les liaisons montantes physiques à utiliser avec le groupe de ports. En effet, toutes les liaisons montantes ne sont pas configurées pour transmettre tout le trafic.

Comment le faire

Les procédures suivantes vous aideront à créer des groupes de ports de machine virtuelle. Tout comme d’autres tâches de mise en réseau, nous pourrions utiliser l’assistant d’ajout de réseau ou la méthode CLI ESXi.

Création d’un groupe de ports standard à l’aide de l’interface HTML5

Suivez ces étapes pour créer un groupe de ports standard :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Dans la vue d’inventaire Hosts and Clusters, sélectionnez l’hôte ESXi sur lequel créer le vSwitch.
3. Accédez à Configurer | Réseautage | Commutateurs virtuels et cliquez sur Ajouter un réseau pour démarrer l’assistant.
4. Dans l’assistant Ajouter un réseau, sélectionnez Groupe de ports de machine virtuelle pour un commutateur standard et cliquez sur Suivant pour continuer :
5. Sur l’écran Sélectionner le périphérique cible, parcourez et sélectionnez un vSwitch standard existant et cliquez sur Suivant pour continuer :

Vous pouvez également choisir de créer un nouveau vSwitch standard pour le groupe de ports à former.

1. Sur l’écran Paramètres de connexion, spécifiez un nom (étiquette réseau) pour le groupe de ports et un ID VLAN facultatif. Cliquer sur Suivant pour continuer :
2. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer:
3. L’onglet Groupes de ports du vSwitch doit maintenant répertorier le groupe de ports nouvellement créé:

Ceci termine le processus de création d’un groupe de ports sur un vSwitch standard à l’aide du client HTML5.

Création d’un groupe de ports standard à l’aide de l’ESXi CLI

Un groupe de ports standard peut également être créé à l’aide de la CLI ESX. Cette méthode est pratique lorsque vous n’avez pas accès à l’interface utilisateur graphique. La procédure vous oblige à accéder à la console de ligne de commande de l’hôte ESXi via une console IPMI (HPE ILO, Dell DRAC, KVM, etc.) ou à SSH dans l’hôte ESXi à l’aide d’outils tels que PuTTY ou SecureCRT. Commençons :

1. SSH (PuTTY) dans l’hôte ESXi en tant qu’utilisateur root.
2. Créez un groupe de ports sur un vSwitch existant à l’aide de la syntaxe de commande suivante :

# esxcli network vswitch standard portgroup add -p <Network Label for the port group> -v <Name of the existing vSwitch>

1. (Facultatif) Attribuez un ID VLAN au groupe de ports à l’aide de la syntaxe de commande:

# esxcli network vswitch standard portgroup set -p <Network Label for the port group> -v <VLAN Number>

1. Exécutez la commande suivante pour répertorier tous les groupes de ports disponibles sur l’hôte ESXi. Le groupe de ports nouvellement créé doit être répertorié dans la sortie:

# esxcli network vswitch standard portgroup list

Voici la sortie des commandes précédentes:

Ceci termine le processus de création d’un groupe de ports sur un vSwitch standard à l’aide de l’ESXi CLI.

Comment ça marche

Les groupes de ports sont des constructions logiques utilisées pour regrouper des ports virtuels sur un vSwitch. Le vSwitch standard n’expose pas les ports individuels de l’interface utilisateur sur lesquels appliquer des stratégies. Au lieu de cela, nous sommes autorisés à utiliser un groupe de ports pour y parvenir. Il est intéressant de noter qu’il n’y a pas de nombre défini ou de limite sur le nombre de ports virtuels qu’un groupe de ports peut englober. Cependant, il existe des limites par vSwitch et par hôte. Le guide Configuration Maximums est la référence absolue pour comprendre ces limites de configuration et peut être trouvé sur https://configmax.vmware.com.

Les ports sont ajoutés sous l’égide d’un groupe de ports lorsque vous y connectez de plus en plus de vNIC. Depuis vSphere 5.5, il n’y a pas de nombre défini de ports sur un vSwitch. Si vous deviez afficher les mêmes propriétés vSwitch, la valeur du nombre de ports sera affichée comme élastique, ce qui signifie que les ports virtuels sont ajoutés / utilisés sur un vSwitch lorsque vous connectez des vNIC à un groupe de ports.

Un groupe de ports de machine virtuelle ne peut être utilisé que pour y connecter les vNIC d’une machine virtuelle. Il peut y avoir plusieurs groupes de ports de machine virtuelle sur un vSwitch standard.

Un groupe de ports VMkernel ne peut être utilisé que pour connecter une interface VMkernel. Un certain nombre de machines virtuelles peuvent se connecter à un seul groupe de ports de machine virtuelle, mais chaque groupe de ports VMkernel nécessite un groupe de ports distinct sur un vSwitch standard. Ce comportement est légèrement différent sur un vSwitch distribué – qui sera traité dans le chapitre 4 , Configuration de l’accès réseau à l’aide de vSphere Distributed Switches .

Création d’interfaces VMkernel supplémentaires sur les commutateurs standard vSphere

Les interfaces VMkernel (vmks) sont des interfaces réseau pour VMkernel. L’interface réseau de gestion par défaut d’un hôte ESXi est une interface VMkernel créée lors du processus d’installation. VMware vous permet de créer jusqu’à 256 interfaces VMkernel (vmk0 – vmk255) par hôte ESXi.

Dans cette recette, nous allons apprendre à créer des interfaces VMkernel sur un vSwitch standard.

Se préparer

Avant de poursuivre la création d’interfaces VMkernel, vous aurez besoin des informations suivantes:

• Vous avez besoin du nom souhaité du groupe de ports pour l’interface VMkernel.
• Vous devez identifier le vSwitch sur lequel l’interface sera formée.
• Vous avez besoin de liaisons montantes si vous voulez créer un nouveau vSwitch pour l’interface.

Comment le faire

Cette section couvrira les méthodes HTML5 et CLI de création d’interfaces VMkernel sur un commutateur standard.

Création d’une interface VMkernel à l’aide du client HTML5

Voici les étapes de création d’une interface VMkernel:

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Dans la vue d’inventaire Hosts and Clusters, sélectionnez l’hôte ESXi sur lequel créer le vSwitch.
3. Accédez à Configurer | Réseautage | Commutateurs virtuels et cliquez sur Ajouter un réseau pour démarrer l’assistant.
4. Dans l’assistant d’ajout de réseau, sélectionnez l’adaptateur réseau VMkernel et cliquez sur Suivant pour continuer :
5. Sur l’écran Sélectionner le périphérique cible, recherchez et sélectionnez un commutateur standard pour former l’interface VMkernel. Cliquez ensuite sur Suivant pour continuer:

Vous pouvez choisir de créer un vSwitch distinct pour l’interface VMkernel si vous le souhaitez. Cependant, cela dépendra de la disponibilité des liaisons montantes physiques inutilisées (vmnics) qui peuvent transmettre le trafic prévu.

1. Sur l’écran Propriétés du port, spécifiez une étiquette de réseau pour le groupe de ports, un ID VLAN facultatif, MTU, une pile TCP / IP à utiliser et les services activés sur celui-ci. Cliquer sur Suivant pour continuer :

VMkernel possède trois piles TCP / IP par défaut : une pile par défaut, une pile de provisioning et une pile vMotion. L’utilisation de différentes piles permet l’utilisation de différentes passerelles, ce qui permet une meilleure isolation du trafic.

1. Dans l’écran des paramètres IPv4, fournissez une adresse IP statique pour l’interface VMkernel, spécifiez une passerelle différente si vous le souhaitez, puis cliquez sur Suivant pour continuer :
2. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer:
3. Une fois que vous avez terminé, vous devriez voir l’interface nouvellement créée sous Configurer | Réseautage | Adaptateurs VMkernel:

Ceci termine le processus de création d’interfaces VMkernel sur un vSwitch standard à l’aide du client HTML5.

Création d’interfaces VMkernel à l’aide de la CLI ESXi

Cette procédure nécessite que vous accédiez à la console de ligne de commande de l’hôte ESXi via une console IPMI (HPE ILO, Dell DRAC, KVM, etc.) ou SSH dans l’hôte ESXi à l’aide d’outils tels que PuTTY ou SecureCRT. Commençons :

1. SSH (PuTTY) dans l’hôte ESXi en tant qu’utilisateur root.
2. Créez un groupe de ports sur un vSwitch standard à l’aide de la syntaxe de commande suivante :

# esxcli network vswitch standard portgroup add -p <Network Label for the port group> -v <Name of the existing vSwitch>

1. Une fois que vous avez terminé, créez une interface VMkernel sur le groupe de ports à l’aide de la syntaxe de commande suivante :

# esxcli network ip interface add -p <Network Label for the port group>

Comme nous n’avons pas spécifié de nom d’interface ( vmkx ) à l’aide de l’ option -i , une nouvelle interface vmk numérotée séquentiellement est créée sur le groupe de ports spécifié.

1. Pour trouver l’interface VMkernel nouvellement créée, exécutez esxcfg-vmknic -l .
2. Une fois la nouvelle interface ( vmkx ) identifiée, émettez les commandes suivantes pour affecter une configuration TCP / IP et associer une balise de type de trafic à l’interface:

# esxcli network ip interface ipv4 set -t=<static/dhcp> -I=<IP
Address> -N=<Subnet Mask> -g=<Gateway > -i <vmkx>

La commande suivante est utilisée pour associer une balise de type de trafic à l’interface:

La capture d’écran suivante montre les commandes précédentes en action:

Ceci termine le processus de création d’interfaces VMkernel à l’aide de l’ESXi CLI.

Comment ça marche

Tout comme les machines virtuelles qui s’exécutent sur les hôtes ESXi, le VMkernel doit également s’interfacer avec le réseau à diverses fins. Ces interfaces agissent comme des points de nœud de réseau pour le VMkernel.

Les types de trafic suivants nécessitent l’utilisation d’une interface VMkernel:

• Trafic de gestion ESXi
• Trafic vMotion
• Trafic VMware Fault Tolerance ( FT )
• Trafic vSAN
• iSCSI
• NFS

Chaque interface VMkernel nécessite un identifiant réseau unique, c’est-à-dire une adresse MAC et IP. L’interface par défaut (première) VMkernel — vmk0 — utilisera le MAC de la première liaison montante physique active (vmnic).

Le vmk doit être connecté à un groupe de ports sur un vSwitch. Sur un vSwitch standard, chaque interface VMkernel a besoin de son propre groupe de ports, et le groupe de ports ne peut pas être partagé avec d’autres interfaces VMkernel ou machines virtuelles.

La première interface VMkernel (vmk0) fournira l’adresse MAC de la carte réseau physique à laquelle elle est connectée. Les interfaces restantes récupèrent l’adresse MAC VMware OUI générée par l’hôte ESXi.

Création de piles TCP / IP VMkernel supplémentaires

VMkernel comprend plusieurs piles TCP / IP. Il existe trois piles système : vMotion, l’approvisionnement et la valeur par défaut. Cependant, vous êtes également autorisé à créer des piles TCP / IP personnalisées. Dans cette recette, nous apprendrons comment configurer et utiliser des piles TCP / IP personnalisées.

Se préparer

Cette procédure nécessite que vous accédiez à la console de ligne de commande de l’hôte ESXi via une console IPMI (HPE ILO, Dell DRAC, KVM, etc.) ou SSH dans l’hôte ESXi à l’aide d’outils tels que PuTTY ou SecureCRT.

Comment le faire

La procédure suivante vous guidera à travers les étapes de création de piles TCP / IP personnalisées / supplémentaires :

1. SSH (PuTTY) dans l’hôte ESXi en tant qu’utilisateur root.
2. Exécutez la commande suivante pour créer une pile TCP / IP :

# esxcli network ip netstack add -N <Name of the custom stack>

Répertoriez toutes les piles sur l’hôte pour les vérifier, comme suit:

# esxcli network ip netstack list

Ce qui suit est une capture d’écran montrant les commandes précédentes:

1. Créez une interface VMkernel et mappez-la à la pile TCP / IP personnalisée nouvellement créée :

Pour savoir comment créer des interfaces VMkernel, lisez la création d’interfaces VMkernel supplémentaires sur une recette de commutateur standard de ce chapitre.

1. Utilisez le client HTML5 pour accéder à la configuration de l’hôte | Réseautage | Dans la section Configuration TCP / IP, sélectionnez la pile TCP / IP nouvellement créée et cliquez sur Modifier … :
2. Dans la section Routage de l’écran Modifier la configuration de la pile TCP / IP, spécifiez une adresse de passerelle par défaut pour la pile et cliquez sur OK :
3. Malheureusement, comme vCenter 6.7 U1, les paramètres DNS ne sont pas disponibles via le client HTML5. Modifiez la pile à l’aide du client Web et spécifiez une adresse de serveur DNS pour le sous-réseau de la pile :
4. Dans la section Avancé, vous pouvez choisir l’algorithme de contrôle de congestion souhaité et le Max. nombre de connexions. Vous n’êtes pas obligé d’apporter des modifications à la configuration par défaut dans des circonstances normales :
5. Une fois que vous avez terminé, la nouvelle pile personnalisée sera répertoriée avec toutes les configurations spécifiées:

Ceci termine le processus de création de piles TCP / IP supplémentaires (personnalisées) pour le VMkernel.

Comment ça marche

Le concept de plusieurs piles TCP / IP pour VMkernel a été introduit avec vSphere 5.5. L’utilisation de la pile TCP / IP signifie que les interfaces VMkernel ne peuvent pas se trouver sur des segments de réseau distincts, mais elles peuvent conserver des segments de mémoire, des tables ARP, des tables de routage et des passerelles par défaut distincts. Cela permet une meilleure isolation et sécurité du trafic.

Il existe trois piles TCP / IP prédéfinies, comme suit :

• Pile par défaut : ce sera la seule pile utilisée si vous ne spécifiez pas de pile pour une interface lors de sa création
• Pile vMotion : elle peut être utilisée pour isoler tout le trafic vMotion de la pile par défaut
• Pile de provisioning : utilisée pour isoler le clonage de machine virtuelle, la migration à froid et le trafic NFC longue distance

Des piles personnalisées peuvent être utilisées pour isoler le trafic sur des passerelles VMkernel distinctes si nécessaire.

Gestion des liaisons montantes physiques d’un commutateur standard vSphere

La liaison montante est un terme vSphere pour une carte réseau physique. Il peut y avoir des scénarios dans lesquels il est nécessaire de mapper des liaisons montantes supplémentaires à un vSwitch à des fins de regroupement et d’équilibrage de charge. Un tel ajout est généralement effectué dans le but de permettre l’utilisation des fonctionnalités d’association et d’équilibrage de charge. Il existe différentes méthodes GUI pour y parvenir : vous pouvez soit utiliser l’assistant d’ajout de réseau, soit gérer le réseau physique.

Dans cette recette, nous apprendrons comment accomplir cela via le client HTML5 et la CLI ESXi.

Comment faire

La procédure suivante vous guidera à travers les étapes impliquées dans le mappage d’une carte réseau physique à un vSwitch, puis leur gestion à l’aide du client HTML5:

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Dans la vue d’inventaire Hosts and Clusters, sélectionnez l’hôte ESXi sur lequel créer le vSwitch.
3. Accédez à Configurer | Réseautage | Commutateurs virtuels, sélectionnez le vSwitch souhaité et cliquez sur Gérer les adaptateurs physiques …:
4. Dans la fenêtre Gérer les adaptateurs réseau physiques, cliquez sur + pour ajouter des adaptateurs physiques. Une fois qu’ils ont été ajoutés, utilisez les icônes x ↑ ↓ pour supprimer ou modifier l’ordre des adaptateurs. Une fois que vous avez terminé, cliquez sur OK pour enregistrer les modifications :

Ceci termine le processus de mappage d’une carte réseau physique à un vSwitch, puis de les gérer à l’aide du client HTML5.

Comment ça marche

Chaque port NIC physique détecté par l’hôte ESXi est énuméré en tant que vmnic. Chaque vmnic correspond à un port Ethernet.

Vous pouvez activer jusqu’à 32 ports Ethernet 1 Gbit / s, 16 ports Ethernet 10 Gbit / s et 16 ports Ethernet 20 Gbit / s sur un hôte ESXi 6.7. Les maximums sont régis par la marque / le modèle / le pilote / la fonction des cartes NIC et leurs combinaisons. Par exemple, vous pouvez avoir jusqu’à 32 ports Ethernet Broadcom 1 Go avec un pilote tg3 et NetQueue désactivés, mais la même carte réseau avec NetQueue activée ne peut présenter que 16 ports. Si vous deviez utiliser une combinaison de ports Ethernet 10 Go et 1 Go, seuls 16 ports 10 Go et 4 ports 1 Go pourraient être activés.

Maintenant qu’ESXi est capable de gérer un grand nombre de cartes réseau physiques, il devrait y avoir une méthode pour présenter logiquement ces cartes réseau afin que nous puissions leur appliquer des stratégies de configuration. Ceci est réalisé en énumérant la carte réseau physique avec un modèle vmnicX (vmnic0 … vmnic32). Il y a aussi une logique derrière l’énumération. Les cartes réseau sont énumérées séquentiellement pendant le processus de démarrage ESXi en scannant le bus PCI, l’emplacement et le numéro de port. Le mappage PCI-ID vers vmnic se trouve dans la configuration /etc/vmware/esx.conf d’un hôte ESXi.

Voici une capture d’écran de la configuration d’un hôte ESXi:

Il y a plus

Bien que l’ordre des adaptateurs ne puisse pas être modifié à l’aide de l’ESXi CLI, des méthodes CLI sont disponibles pour vous permettre d’ajouter et de supprimer des adaptateurs physiques. Passons en revue ces derniers maintenant :

1. SSH dans l’hôte ESXi en tant qu’utilisateur root.
2. Pour ajouter une liaison montante à un vSwitch physique, utilisez la syntaxe de commande suivante :

# esxcli network vswitch standard uplink add -u <Physical Uplink> -v <Name of the vSwitch>

1. Exécutez la commande suivante pour récupérer les détails du vSwitch et vérifier si la liaison montante physique a été ajoutée avec succès:

# esxcli network vswitch standard list -v <Name of the vSwitch>

Ce qui suit est une capture d’écran montrant les commandes précédentes :

Ceci termine le processus de mappage de la carte réseau physique / liaisons montantes à un vSwitch standard à l’aide de l’ESXi CLI.

Configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement

Les mécanismes de sécurité, de mise en forme du trafic, de regroupement et de basculement sont identiques pour un vSwitch standard et un vSwitch distribué (dvSwitch ou VDS), le VDS offrant un peu plus de fonctionnalités.

VDS peut être configuré pour gérer à la fois la mise en forme du trafic d’entrée et de sortie, et il prend en charge l’équilibrage de charge en fonction de la charge sur une carte réseau physique.

Bien que nous verrons comment configurer ces paramètres, nous discuterons en détail des concepts sous-jacents dans le chapitre suivant.

Comment faire

La procédure suivante vous guidera à travers les étapes de configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement sur un commutateur standard vSphere :

1. Connectez-vous à vCenter Server en utilisant l’une des méthodes suivantes :

• Utilisez le client HTML5.
• Dans la vue d’inventaire Hosts and Clusters, sélectionnez l’hôte ESXi sur lequel créer le vSwitch.

1. Accédez à Configurer | Réseautage | Commutateurs virtuels, sélectionnez le vSwitch souhaité et cliquez sur Modifier … :
2. Utilisez la section Sécurité de la fenêtre Modifier les paramètres pour configurer le mode Promiscuous souhaité, les modifications d’adresse MAC et les stratégies de transmission forgée pour le vSwitch:
3. Utilisez la section Traffic shaping pour contrôler la bande passante moyenne / crête et la taille de rafale du trafic sortant:
4. Utilisez la section Association et basculement pour spécifier l’équilibrage de charge et toute autre configuration souhaitée :

Ceci termine le processus de configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement sur les commutateurs standard vSphere.

Nous approfondirons chacun de ces paramètres dans le chapitre 4 , Configuration de l’accès au réseau à l’aide de vSphere Distributed Switches , où nous les comparerons avec vSphere Distributed Switch.

Configuration de l’accès réseau à l’aide de commutateurs distribués vSphere

Un commutateur distribué vSphere ( dvSwitch ou vDS ) est le deuxième type de construction de commutation logicielle qui peut être utilisé dans un environnement vSphere. Contrairement à un vSphere Standard Switch ( vSS ), qui doit être géré par hôte, le vDS est géré au niveau de la couche vCenter. Cependant, cela ne change pas la façon dont ESXi gère les E / S réseau.

Un vDS est souvent mal conçu comme un commutateur virtuel unique couvrant plusieurs hôtes ESXi. L’une des raisons de cette idée fausse est qu’il est généralement documenté comme un vSwitch à l’échelle du centre de données. En substance, ce n’est que le plan de gestion du vDS qui crée cette illusion. VMware utilise toujours un plan de données individuel (commutateurs virtuels masqués) sur chaque hôte ESXi. Il est appelé un commutateur distribué car le plan de gestion et les plans de données qui sont distribués sur les hôtes ESXi sont traités comme une seule entité gérable.

dvSwitch fournit des fonctionnalités avancées, telles que l’apprentissage MAC natif, la mise en forme du trafic d’entrée / sortie, les groupes d’agrégation de liens, la mise en miroir des ports et NetFlow. Le diagramme logique suivant illustre le concept d’un dvSwitch:

Un groupe de ports distribués ( dvPortGroup ) ressemble beaucoup à un groupe de ports standard mais peut s’étendre sur des hôtes ESXi. Cependant, la différence remarquable est que, contrairement à la nécessité de groupes de ports VMkernel et de groupes de ports de machine virtuelle avec des commutateurs standard, un dvPortGroup peut servir à la fois les types de trafic de machine virtuelle et VMkernel.

Un dvUplink est une couche d’abstraction utilisée pour gérer et appliquer des stratégies d’ association, d’ équilibrage de charge et de basculement pour les cartes réseau physiques sur un hôte ESXi. Chaque dvUplink a une relation un-à-plusieurs avec les liaisons montantes physiques de différents hôtes. Le nombre de dvUplinks dicte le nombre de liaisons montantes physiques ( de chaque hôte ESXi ) qui peuvent participer à la configuration du réseau.

Vous pouvez configurer jusqu’à 32 dvUplinks au maximum sur un dvSwitch. Ce maximum est dicté par la limite de 32 adaptateurs physiques sur un hôte ESXi.

Tous les dvUplinks sont gérés sous un seul groupe de ports dvUplink .

Dans ce chapitre, nous couvrirons les sujets suivants :

• Création d’un commutateur distribué vSphere (vDS)
• Connexion d’hôtes ESXi à un vDS
• Création de groupes de ports distribués (dvPortGroup)
• Configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement
• Configuration de VLAN sur vDS
• Configuration de VLAN privés sur un vDS
• Configuration d’un groupe d’agrégation de liens (LAG) sur un vDS
• Configuration des pools de réseaux définis par l’utilisateur – NIOC
• Migration du réseau de machines virtuelles de vSS vers vDS
• Migration des interfaces VMkernel de vSS vers vDS
• Configuration de la mise en miroir de ports sur vDS
• Configuration de NetFlow sur vDS
• Mise à niveau de vDS
• Sauvegarde et restauration d’un vDS

Création d’un commutateur distribué vSphere (vDS)

Contrairement au vSphere Standard Switch (vSS), qui est créé sur un hôte ESXi, le vDS doit être créé au niveau de l’objet du centre de données du vCenter. Par conséquent, il va sans dire que vous aurez besoin d’accéder à un vCenter autorisé à créer et gérer des vDS.

Comment le faire

La procédure suivante vous guidera à travers les étapes de création d’un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Accédez à la vue Inventaire du réseau, cliquez avec le bouton droit sur le centre de données BK, puis accédez à Commutateur distribué | Nouveau commutateur distribué …:

Assistant Démarrer un nouveau commutateur distribué

1. Dans l’assistant Nouveau commutateur distribué, spécifiez un nom pour le vDS et cliquez sur Suivant pour continuer :
2. Sur l’écran Select version, choisissez une version pour le vDS. Notez la version et sa compatibilité avant de continuer. Par exemple, si le vDS est créé pour un environnement de centre de données mixte avec des versions antérieures d’hôtes ESXi, vous devrez choisir une version vDS compatible avec la version ESXi la plus ancienne :
3. Sur l’écran Configurer les paramètres, vous pouvez spécifier le nombre de liaisons montantes par hôte (la valeur par défaut est 4) et le contrôle des E / S réseau (activé par défaut), puis choisir de créer ou non un groupe de ports par défaut et un nom de groupe de ports :
4. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer:
5. Le volet Tâches récentes doit afficher les tâches liées à la création du vDS, à l’activation de NIOC et à la création réussie du dvPortGroup par défaut :

Ceci termine le processus de création d’un vDS.

Comment ça marche

La configuration dvSwitch est enregistrée dans la base de données vCenter et une copie locale de la configuration est enregistrée sur chacun des hôtes ESXi participants dans le fichier /etc/vmware/dvsdata.db . dvsdata.db est synchronisé avec la base de données vCenter toutes les 300 secondes.

Connexion des hôtes ESXi à un vDS

Une fois que vous avez créé un vDS, l’étape suivante consiste à lui ajouter des hôtes ESXi. Ce processus associe essentiellement les hôtes ESXi souhaités au vDS. Cependant, mapper uniquement les hôtes ESXi sur le vDS ne les rend pas utilisables. Vous devrez mapper les liaisons montantes physiques des hôtes ESXi au dvSwitch. Le nombre d’adaptateurs physiques pouvant être mappés à un dvSwitch dépend du nombre de dvUplinks configurés sur le vDS. La valeur par défaut est 4 (le maximum est 32 ).

Comment faire

La procédure suivante vous guidera à travers les étapes de mappage des hôtes ESXi à un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et cliquez sur Ajouter et gérer des hôtes …:
3. Dans l’assistant Ajouter et gérer des hôtes, sélectionnez Ajouter des hôtes et cliquez sur Suivant pour continuer:
4. Sur l’écran Sélectionner les hôtes, cliquez sur Nouveaux hôtes … pour ajouter les hôtes ESXi souhaités. Une fois que vous avez terminé, cliquez sur Suivant pour continuer :
5. Dans l’écran Gérer les adaptateurs physiques, sélectionnez l’adaptateur physique (vmnic) à mapper et cliquez sur Attribuer la liaison montante :
6. Sur l’écran Select an Uplink, choisissez le dvUplink souhaité pour le vmnic et cochez la case Appliquer cette affectation de liaison montante à tous les autres hôtes pour garder les affectations de liaison montante uniformes sur tous les hôtes ESXi qui sont ajoutés. Cliquez sur OK pour confirmer la sélection :
7. Une fois que vous avez terminé, vous serez de retour à l’écran Gérer les adaptateurs physiques. Passez en revue les affectations et cliquez sur Suivant pour continuer :
8. Sur l’écran Gérer les adaptateurs VMkernel, vous pouvez choisir de migrer les interfaces vmk vers dvPortGroups sur le vDS. Puisque nous ajoutons simplement les hôtes au vDS, nous n’avons pas à apporter de modifications sur cet écran. Cliquer sur Suivant pour continuer.
9. Sur l’écran Migrate VM networking, vous pouvez choisir de migrer les interfaces virtuelles vers les dvPortGroups sur le vDS. Encore une fois, puisque nous ajoutons simplement les hôtes au vDS, nous n’avons pas à apporter de modifications sur cet écran. Cliquez sur Suivant pour continuer.
10. Sur l’écran Prêt à terminer, passez en revue le résumé et cliquez sur Terminer :
11. Le volet Tâches récentes doit indiquer la réussite de toutes les tâches connexes:

Comment ça marche

Une fois qu’un hôte est ajouté au vDS, l’exécution de la commande net-dvs sur l’hôte ESXi doit afficher la copie de l’hôte du vDS:

Ces informations sont stockées sur l’hôte dans le fichier /etc/vmware/dvsdata.db .

Une fois les hôtes ajoutés au vDS, toute modification du mappage vmnic-à-dvUplink peut être effectuée à partir de chaque hôte ESXi ou en utilisant le workflow de gestion du réseau hôte de l’assistant Prod-vDS – Ajouter et gérer des hôtes. Voici une capture d’écran de l’assistant Prod-vDS – Ajouter et gérer des hôtes :

Le flux de travail est identique à Ajouter des hôtes, avec des options supplémentaires pour gérer les liaisons montantes, comme suit :

Maintenant que nous avons appris à connecter des hôtes ESXi à un vDS, dans la section suivante, nous allons apprendre à créer des dvPortGroups.

Création de groupes de ports distribués (dvPortGroup)

Lors de la création d’un vDS à l’aide de l’assistant Nouveau commutateur distribué, un dvPortGroup est créé par défaut. Cependant, il existe plusieurs cas d’utilisation pour plusieurs dvPortGroup; par exemple, un dvPortGroup distinct pour les machines virtuelles nécessitant un VLAN. Comme vSphere 6.7, vDS peut avoir environ 10000 dvPortGroups statiques / élastiques et environ 1016 groupes de ports éphémères.

Reportez-vous à VMware Configuration Maximums sur https://configmax.vmware.com pour comprendre les limites de configuration.

Comment faire

La procédure suivante vous aidera à créer un vSphere dvPortGroup:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et accédez à Distributed Port Group | Nouveau groupe de ports distribués … :
3. Dans l’assistant Nouveau groupe de ports distribués, spécifiez un nom pour le dvPortGroup et cliquez sur Suivant pour continuer :
4. Sur l’écran Configurer les paramètres, procédez comme suit:

• Spécifiez les méthodes de liaison de port (Static / Ephermeral) et d’allocation de port (Static-Elastic / Static-Fixed) souhaitées.
• Spécifiez le nombre de ports pour dvPortGroup.
• Fournissez un pool de ressources réseau.
• Fournissez un type de VLAN (VLAN / VLAN Trunking / Private VLAN).

1. Sélectionnez Personnaliser la configuration des stratégies par défaut sous Avancé pour activer la sécurité, la mise en forme du trafic, l’association et le basculement, NetFlow et le blocage des ports :
2. Sur l’écran Sécurité, vous pouvez modifier la façon dont le dvPortGroup gère les modifications de sécurité et d’adresse MAC :
3. Sur l’écran de mise en forme du trafic, choisissez de configurer la mise en forme du trafic d’entrée / sortie :
4. Sur l’écran Association et basculement, configurez la façon dont le réseau est équilibré en charge et comment les liaisons montantes sont associées pour gérer la défaillance :
5. Sur l’écran de surveillance, vous pouvez choisir d’activer NetFlow:
6. Sur l’écran Divers, vous pouvez choisir de bloquer tous les ports si nécessaire. La valeur par défaut est Non :
7. Sur l’écran Lire pour terminer, passez en revue le résumé et cliquez sur Terminer :
8. Vous devriez voir une tâche Ajouter des groupes de ports distribués terminée avec succès dans le volet Tâches récentes.
9. Le nouveau dvPortGroup sera répertorié sous l’onglet Réseaux du vDS:

Ceci termine le processus de création de dvPortGroups.

Fonctionnement

Chaque groupe de ports que vous créez sur un vDS est appelé réseau. Chaque vDS aura un groupe de ports pour dvUplinks, ce qui fait que le réseau compte sur le vDS par défaut de 1. Chaque autre groupe de ports que vous créez sur le vDS augmente le travail du réseau.

Dans la capture d’écran suivante, nous pouvons voir 3 réseaux et 24 ports. Nous avons trois réseaux car nous avons un groupe de ports dvUplink et deux dvPortGroups. Le nombre de ports est de 24 car les trois groupes de ports ont un nombre de ports par défaut de 8 :

Liaison de port et attribution de port

Lorsque vous connectez une machine virtuelle à un dvPortGroup, le vNIC de la machine virtuelle est connecté à un port dvSwitch ( dvPort ). Les dvPorts sont associés aux vNIC à l’aide de deux méthodes :

• Liaison statique
• Éphémère (sans reliure)

La liaison statique est la méthode par défaut, dans laquelle vCenter attribue et réserve un dvPort pour un vNIC lorsqu’il est connecté à un dvPortGroup pour la première fois. La réservation est maintenue jusqu’à ce que la vNIC soit dissociée du dvPortGroup. Il est important de noter que la déconnexion de la vNIC ne supprimera pas la réservation. La méthode statique de liaison conserve les statistiques de port, ce qui permet de surveiller le trafic de la machine virtuelle.

La méthode éphémère n’implique pas de réserver un dvPort pour un vNIC. Les dvPorts sont créés et supprimés à la demande. Un dvPort est créé et associé à une vNIC lorsqu’une machine virtuelle connectée au dvPortGroup est sous tension. Le dvPort est supprimé si la vNIC est déconnectée ou si la machine virtuelle est migrée ou mise hors tension.

La liaison statique nécessite la disponibilité de vCenter, tandis que l’allocation Ephermeral ne dépend pas de vCenter.

L’allocation de port fait référence au concept d’allocation de ports à un dvPortGroup lorsque la méthode de liaison statique est utilisée. Il existe deux types de méthode d’allocation de port :

• Méthode élastique : comme son nom l’indique, le groupe de ports se développe et se contracte en termes de nombre de dvPorts. Par défaut, chaque groupe de ports possède 8 dvPorts (sauf s’ils sont configurés avec un numéro différent). Plus de dvPorts sont mis à la disposition du dvPortGroup à la demande et lorsque les ports ne sont plus utilisés, les dvPorts ne sont pas alloués. Cependant, il est important de noter que le nombre de dvPort ne descendra pas en dessous du nombre configuré.
• Méthode fixe : le nombre de dvPorts reste fixe au nombre de ports configuré. La valeur par défaut est 8. Cela signifie que vous pouvez uniquement connecter jusqu’à n nombre de vNIC au dvPortGroup, n étant le nombre configuré de ports.

Pool de ressources réseau

L’option de pool de ressources réseau disponible dans l’assistant de création de dvPortGroup vous permettra de sélectionner un pool de ressources réseau défini par l’utilisateur. Si aucun pool de ressources défini par l’utilisateur n’est disponible, il correspondra par défaut au pool de ressources du réseau système appelé Virtual Machine Traffic, bien que cela ne soit pas explicitement indiqué dans l’interface utilisateur.

Type de VLAN

Le dvPortGroup vous permet de spécifier un numéro de VLAN pour tout le trafic réseau, de trunk tout le trafic VLAN, ou d’utiliser un VLAN privé :

• Type de VLAN – VLAN : vous pouvez définir un numéro de VLAN pour le groupe de ports. Tout le trafic sera marqué sur le groupe de ports avec le numéro de VLAN configuré.
• Type de VLAN – jonction VLAN : vous pouvez spécifier une liste séparée par des virgules et / ou une plage de numéros VLAN à jonction. Cette méthode est utilisée pour le Virtual Guest Tagging (VGT).

La capture d’écran suivante illustre le type de VLAN et la plage de lignes réseau :

Nous en apprendrons plus sur les VLAN dans la section Configuration des VLAN sur une recette vDS de ce chapitre.

Configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement

Comme indiqué dans le chapitre précédent, les mécanismes S ecurity, Traffic Shaping, Teaming et Failover fonctionnent de manière identique sur les commutateurs standard et distribués, vDS offrant des fonctionnalités et des améliorations supplémentaires. Vous devriez déjà avoir eu un aperçu de ces paramètres si vous lisez la recette Création de groupes de ports distribués. Dans cette recette, nous verrons où nous pouvons configurer ces paramètres sur un vDS – ou plus précisément, sur un dvPortGroup qui a déjà été créé.

Il est important de noter que ces paramètres ne peuvent pas être configurés sur le vDS lui-même mais uniquement sur les dvPortGroups.

La section Comment ça marche … de cette recette explique l’impact de chacun de ces paramètres sur le trafic réseau.

Comment le faire

La procédure suivante vous aidera à configurer les paramètres de sécurité, de mise en forme du trafic, d’association et de basculement sur un dvPortGroup:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le dvPortGroup souhaité et cliquez sur Modifier les paramètres … :
3. Dans la fenêtre Edit Settings, utilisez l’écran Security pour accepter / rejeter le mode Promiscuous, les changements d’adresse MAC et les transmissions forgées. Notez que les trois paramètres sont définis sur Rejeter par défaut :
4. Sur l’écran Association et basculement, configurez l’équilibrage de charge, la détection des pannes réseau, les commutateurs de notification et la restauration automatique. Configurez également l’ordre de basculement des liaisons montantes, si nécessaire :
5. Sur l’écran de mise en forme du trafic, activez et configurez la mise en forme du trafic d’entrée / sortie :
6. Une fois les paramètres souhaités configurés, cliquez sur OK pour confirmer.

Ceci termine le processus de configuration de la sécurité, de la mise en forme du trafic, de l’association et du basculement sur un vDS.

Comment ça marche

Avant d’approfondir chacun de ces paramètres, comparons les paramètres disponibles sur vSS et vDS.

Sécurité, mise en forme du trafic, regroupement et basculement – vSS contre vDS :

Category	vSphere Standard Switch (vSS)	vSphere Distributed Switch(vDS)
Security	Promiscuous mode MAC Address changes Forged Transmits	Promiscuous mode MAC Address changes Forged Transmits
Traffic shaping	Egress Traffic Shaping Average Bandwidth Burst Size Peak Bandwidth	Egress and Ingress Traffic Shaping Average Bandwidth Burst Size Peak Bandwidth
Teaming and failover	Route based on originating virtual port Route based on IP hash Route based on source MAC hash Use explicit failover order Failover detection Failover order	Route based on originating virtual port Route based on IP hash Route based on source MAC hash Route based on physical NIC load Use explicit failover order Failover detection Failover order

Plongeons-nous dans chaque catégorie.

Sécurité

Les paramètres de sécurité du réseau ont le même impact sur le trafic, quel que soit le type de commutateur sur lequel il est configuré :

• Un vDS permet un niveau supplémentaire de granularité en rendant les mêmes paramètres configurables au niveau dvPort. Pour que cela fonctionne, le dvPortGroup doit être configuré pour autoriser les remplacements de stratégie au niveau du dvPort.
• Avec un vSS, les paramètres de sécurité ne peuvent être appliqués qu’au niveau du groupe de ports.

Les trois paramètres de sécurité réseau qui peuvent être définis sur Accepter / Rejeter sont les suivants :

• Mode promiscuité
• Changements d’adresse MAC
• Transmissions forgées

Mode promiscuité

Lorsque le mode promiscuous est activé ( Accept ) sur un groupe de ports, tous les vNIC de machine virtuelle connectés au groupe de ports peuvent voir tout le trafic sur le commutateur virtuel. C’est pourquoi il est toujours désactivé (Rejeter) par défaut. Lorsqu’il est défini sur Rejeter, une vNIC ne verra que le trafic destiné à son adresse MAC. Le mode promiscuous est particulièrement utile si vous devez laisser les machines virtuelles exécutant des outils de surveillance du réseau analyser le trafic sur le commutateur virtuel. En tant que meilleure pratique, sur un vSS, ces machines virtuelles sont placées dans un groupe de ports distinct avec Mode Promiscuous défini sur Accepter. Ce faisant, vous activez uniquement ces machines virtuelles pour voir le trafic souhaité. Cependant, sur un vDS, ces paramètres peuvent être configurés pour chacun des dvPorts auxquels les vNIC de la machine virtuelle de surveillance sont connectés.

Changements d’adresse MAC et transmissions falsifiées

Chaque machine virtuelle a deux adresses MAC par définition. L’adresse MAC attribuée à la vNIC d’une machine virtuelle lors de la création de la vNIC est appelée l’adresse MAC initiale. L’adresse MAC qu’un système d’exploitation invité configure pour l’interface réseau qu’il détecte est appelée l’adresse MAC effective. L’adresse MAC effective doit généralement correspondre à l’adresse MAC initiale (qui est le MAC réel sur la carte réseau).

Modifications d’adresse MAC (par défaut : rejeter) : cela s’applique au trafic entrant dans une machine virtuelle à partir du commutateur virtuel. Si les modifications d’adresse MAC sont définies sur Accepter, cela signifie que vous autorisez la machine virtuelle à recevoir le trafic qui était initialement destiné à une autre machine virtuelle en empruntant l’identité MAC de l’autre machine virtuelle.

Par exemple, si VM-A voulait recevoir du trafic destiné à VM-B, alors VM-A devra se présenter avec une adresse MAC appartenant à VM-B. Ceci est généralement obtenu en modifiant l’adresse MAC effective (niveau OS). L’adresse MAC initiale d’une telle machine virtuelle restera inchangée. Lorsque les modifications d’adresse MAC sont définies sur Accepter, le commutateur virtuel permet à l’adresse MAC effective d’être différente de l’adresse MAC initiale. Lorsque les changements d’adresse MAC sont définis sur Rejeter, le port / dvPort auquel le vNIC est connecté sera bloqué si le MAC effectif ne correspond pas à l’adresse MAC initiale. Par conséquent, la machine virtuelle cessera de recevoir du trafic.

Transmissions falsifiées (par défaut : rejeter) : cela s’applique au trafic sortant d’une machine virtuelle et entrant dans le commutateur virtuel. Si les transmissions falsifiées sont définies sur Accepter, cela permet l’usurpation d’adresse MAC. Cela signifie qu’une machine virtuelle sera autorisée à envoyer des trames Ethernet avec une adresse MAC source différente de l’adresse MAC effective / initiale. Lorsqu’il est défini sur Rejeter, le commutateur virtuel supprimera la trame Ethernet avec une adresse MAC source différente du MAC effectif / initial.

Mise en forme du trafic

Les commutateurs virtuels (vSS / vDS) incluent un modulateur de trafic qui permet de contrôler les taux de transfert du réseau. La seule différence est que le shaper de trafic sur le vSS ne peut gérer que le trafic de sortie, bien que vSphere Distributed Switch puisse gérer à la fois les entrées et les sorties.

Tout ce qui quitte un commutateur virtuel (vSS ou vDS) est le trafic sortant, et tout ce qui entre dans un commutateur virtuel (vSwitch ou dvSwitch) est le trafic entrant. La source d’entrée peut être une interface vNIC ou VMkernel.

VMware ne peut pas contrôler ce qui se passe au-delà des limites de la carte réseau physique de l’hôte. Par conséquent, le flux de trafic que le gestionnaire de trafic peut contrôler est le flux (entrée / sortie) entre les interfaces machines virtuelles / VMkernel et le commutateur virtuel. Le diagramme suivant illustre la direction du trafic entrant / sortant.

Le shaper de trafic fait son travail en contrôlant trois paramètres :

• Bande passante moyenne
• Bande passante maximale
• Taille de rafale

La bande passante moyenne est le taux de transfert moyen auquel le commutateur virtuel peut envoyer du trafic. Il est mesuré en kilobits par seconde (kbps). La valeur est normalisée dans le temps.

La bande passante de pointe est le taux de transfert maximal auquel le commutateur virtuel est autorisé à effectuer. Il est mesuré en kilobits par seconde (kbps). Cette limite ne peut pas être dépassée.

La taille de rafale est un concept délicat à comprendre. Bien que spécifié en kilo-octets (Ko), il s’agit en fait de la durée effective (mesurée en secondes) que le commutateur virtuel est autorisé à exécuter au taux de transfert maximal.

La quantité effective de temps de rafale est calculée à l’aide de la formule suivante: Temps de rafale effectif = (taille de rafale en kilobits) / (valeur de bande passante maximale en kbps) .

Examinons un scénario afin de comprendre comment le temps de rafale effectif est atteint.

Si vous deviez définir la valeur de bande passante de pointe à 4 000 kbps, la bande passante moyenne à 2 000 kbps et la taille de la rafale à 2 000 Ko, vous autorisez le commutateur virtuel à fonctionner au taux de transfert maximal de 4 000 kbps, ce qui ne dure plus de 4 secondes.

Voici comment la valeur a été obtenue :

1. La taille de rafale en Ko doit être convertie en kbits en multipliant la valeur par 8. Dans ce cas, il s’agit de 2 000 Ko * 8 = 16 000 kbits.
2. Maintenant, nous appliquons la formule, c’est-à-dire 16 000 kbits / 4 000 kbps = 4 secondes.

Association et basculement

Les charges de travail des machines virtuelles partagent non seulement les ressources de calcul et de stockage sur un serveur ESXi, mais également les interfaces réseau physiques. Il existe des limites physiques à la capacité de ces interfaces réseau à répondre aux besoins de bande passante des machines virtuelles. Plus important encore, toutes les machines virtuelles n’ont pas les mêmes caractéristiques de charge de travail réseau. Par conséquent, il devient extrêmement critique pour les commutateurs virtuels d’avoir des capacités de répartition de charge réseau, d’équilibrage de charge et de basculement.

Commençons par comparer les capacités d’association et de basculement des deux types de commutateurs:

Teaming methods	vSS	vDS
Route based on the originating virtual port ID	Yes	Yes
Route based on source MAC hash	Yes	Yes
Load-based teaming	No	Yes
Use explicit failover order	Yes	Yes

Passons en revue les différentes méthodes d’association et de basculement, une par une.

Route basée sur l’ID de port virtuel d’origine

Il s’agit du mécanisme d’équilibrage de charge par défaut pour vSS et vDS. Avec ce mécanisme, chaque port de commutateur virtuel auquel une interface vNIC / VMkernel se connecte est associé à une liaison montante (vmnic / dvUplink) de façon circulaire. Une fois associées, les liaisons montantes correspondantes sont toujours utilisées pour le trafic, sauf en cas de panne de liaison montante, de VMotion ou de cycle d’alimentation d’une VM.

Le diagramme suivant illustre la distribution circulaire des ports – où les ports 1 et 3 sont affectés à la liaison montante-A et les ports 2 et 3 à la liaison montante B:

Route basée sur le hachage MAC source

Il s’agit d’une méthode obsolète d’équilibrage de charge dans laquelle une liaison montante est choisie en fonction de l’adresse MAC source de la trame qui entre dans le commutateur virtuel.

Route basée sur le hachage IP

Cette méthode utilise une valeur de hachage combinée des adresses IP source et de destination pour choisir une liaison montante. Cependant, pour que ce mécanisme fonctionne, les cartes réseau physiques doivent être dans le même groupe d’agrégation de liens. Si les cartes réseau physiques sont câblées à différents commutateurs physiques, ces commutateurs doivent être empilés. Le mécanisme de hachage IP est particulièrement avantageux lorsque le trafic comprend plusieurs sources et adresses IP de destination. Par exemple, un serveur Web avec plusieurs clients se connectant à partir d’un certain nombre de sous-réseaux est un candidat idéal.

Route basée sur la charge NIC physique

L’association basée sur la charge n’est disponible que sur un dvSwitch. Contrairement aux autres méthodes, cela offre une véritable méthode d’équilibrage de la charge réseau. Les autres méthodes que nous avons discutées jusqu’à présent n’offrent qu’un mécanisme de distribution de charge, ce qui se fait en gérant les affectations d’adaptateurs physiques en fonction de l’algorithme choisi. Avec un regroupement basé sur la charge, l’affectation initiale est effectuée de manière circulaire, mais à partir de là, les adaptateurs physiques sont surveillés pour la saturation de la charge. Si l’un des adaptateurs physiques atteint un seuil de saturation de 75% qui persiste pendant plus de 30 secondes, une partie du trafic est déplacée vers un adaptateur physique non saturé.

Utiliser un ordre de basculement explicite

Bien que présentée comme une option sous l’association et le basculement, l’utilisation d’un ordre de basculement explicite n’est pas une méthode d’équilibrage de charge ou de distribution. Au lieu de cela, il utilise un ordre de basculement prédéfini pour utiliser les adaptateurs physiques disponibles et actifs en cas de défaillance. Lorsque vous définissez l’équilibrage de charge pour utiliser l’ordre de basculement explicite, tout le trafic est traversé par un seul adaptateur physique à tout moment. S’il y a plus d’un adaptateur physique actif, il choisira l’adaptateur qui a été actif et le plus longtemps. Par exemple, si vmnic1, vmnic2 et vmnic3 sont les trois liaisons montantes actives et qu’elles ont une durée de disponibilité de 48 heures, 32 heures et 5 minutes respectivement, alors vmnic1 avec 48 heures de disponibilité est choisi. La logique derrière un tel choix est de sélectionner le plus stable / fiable parmi les adaptateurs disponibles.

Détection de panne de réseau

La détection de défaillance du réseau est utilisée pour déterminer la vivacité d’une liaison montante physique à l’aide de l’un des deux mécanismes – état de la liaison uniquement ou détection de balise:

• Seul l’état de la liaison est utilisé pour déterminer l’état de la connectivité de la liaison montante physique, qui aurait pu rencontrer une panne de carte réseau, une déconnexion de câble, etc.
• La détection par balise est utilisée pour déterminer une défaillance du réseau en amont. Pour plus d’informations sur la détection des balises, consultez l’ article 100577 de la base de connaissances VMware à l’ adresse https://kb.vmware.com/kb/1005577 .

Notifier les commutateurs

Les commutateurs physiques de couche 2 ont la capacité de maintenir une table d’adresses MAC. Le tableau mappe les adresses MAC aux numéros de port d’un commutateur physique. S’il n’y a pas d’entrée correspondante pour l’adresse MAC de destination d’une trame dans la table de recherche, le commutateur inondera la trame via chaque port de commutateur, autre que le port source. Pour réduire l’occurrence d’une telle inondation, le commutateur a un mécanisme pour apprendre les adresses MAC et maintenir une table de mappage. Il le fait en lisant les informations de l’adresse MAC source dans les trames qui entrent dans le commutateur.

Désormais, lorsque vous câblez les cartes réseau physiques d’un hôte ESXi aux ports du commutateur physique, le commutateur doit voir les adresses MAC d’un certain nombre de cartes réseau virtuelles. Le commutateur ne pourra ajouter une entrée à la table de recherche que si les machines virtuelles commencent à communiquer. VMware ESXi, cependant, peut notifier de manière proactive le commutateur physique des adresses MAC de la machine virtuelle afin que sa table MAC soit à jour avant même qu’une VM ne commence à communiquer. Il y parvient en envoyant un ARP gratuit (considéré comme une trame RARP par le commutateur) avec l’adresse MAC effective d’un vNIC comme MAC source de la trame RARP. Le RARP aura l’adresse MAC de destination définie sur l’adresse de diffusion, qui se présente sous la forme FF: FF: FF: FF: FF: FF .

ESXi envoie un RARP dans les circonstances suivantes :

• Lorsqu’une machine virtuelle est sous tension : la carte réseau virtuelle de la machine virtuelle doit être liée à une carte réseau physique. La liaison montante physique choisie dépend de la stratégie d’équilibrage de charge utilisée. Pour en savoir plus sur ces stratégies d’équilibrage de charge, lisez la section Association et basculement. Lorsque vSwitch associe un NIC physique à un vNIC, ESXi devra envoyer une trame RARP pour permettre au commutateur physique de mettre à jour sa table de recherche avec un nouveau mappage de numéro de port physique pour l’adresse MAC du vNIC. Cela est nécessaire car, à chaque mise sous tension d’une machine virtuelle, il n’est pas garanti que le même mappage vNIC vers PNIC soit utilisé.
• Lorsqu’une machine virtuelle est vMotioned d’un hôte à un autre : Après une vMotion, la vNIC de VM sera désormais associée à la liaison montante physique sur l’hôte ESXi de destination. Par conséquent, il devient une nécessité proactive de rendre le commutateur physique conscient du fait que l’adresse MAC de la machine virtuelle se trouve désormais sur un port de commutateur physique différent afin que la table MAC puisse être mise à jour en conséquence.
• Lorsqu’une liaison montante physique bascule : après une défaillance de liaison montante, les ports virtuels sont basculés vers d’autres liaisons montantes physiques disponibles, créant ainsi une nouvelle association. Par conséquent, il devient nécessaire d’aviser le commutateur physique du nouveau numéro de port physique que les adresses MAC sont activées.
• Lorsque l’association basée sur la charge lie à nouveau une carte réseau virtuelle à une liaison montante différente : L’association basée sur la charge peut déplacer automatiquement le trafic de machine virtuelle en fonction de la charge sur les liaisons montantes physiques. Lorsqu’une telle réinstallation se produit, le commutateur physique doit être informé du nouveau port physique sur lequel les adresses MAC de la machine virtuelle sont activées.

Rétablissement

Lorsqu’il est défini sur Oui (par défaut), il permet à une liaison montante récupérée de reprendre son rôle actif. En d’autres termes, une liaison montante active ayant échoué, lorsqu’elle est revenue à la normale, sera redésignée comme liaison montante active. L’impact de cette configuration dépend de l’ordre de basculement qui a été configuré.

Ordre de basculement

Les liaisons montantes physiques sur un hôte ESXi peuvent être associées pour fournir le basculement, les performances et la redondance.

Avec les deux types de commutateurs virtuels, nous pouvons contrôler la participation des liaisons montantes dans différentes configurations de regroupement. Cela se fait en regroupant les liaisons montantes disponibles en trois catégories :

• actif
• Etre prêt
• Inutilisé

Les adaptateurs actifs sont disponibles pour une utilisation dans n’importe quelle configuration et achemineront le trafic.

Les adaptateurs de secours agissent comme une sauvegarde des adaptateurs actifs et ne seront activés que si l’un des adaptateurs actifs tombe en panne.

Les adaptateurs inutilisés ne peuvent participer à aucune des configurations du commutateur virtuel. En substance, ils ne seront pas utilisés pour transporter du trafic.

Il y a plus

Par défaut, tous les paramètres réseau sont gérés au niveau dvPortGroup et nous ne sommes pas autorisés à configurer les paramètres réseau sur un dvPort. Toutefois, ce comportement peut être modifié en activant des remplacements pour les stratégies de port. Cela peut être fait dans la section Avancé de l’écran Modifier les paramètres d’un dvPortGroup, comme suit:

Par exemple, dans ce cas, nous avons autorisé le remplacement de VLAN et NetFlow, ce qui signifie que nous pouvons remplacer la configuration au niveau dvPort:

Configuration des VLAN sur vDS

Le VLAN est une méthode que vous pouvez utiliser pour subdiviser un sous-réseau de réseau en domaines de diffusion distincts. Dans une infrastructure moderne, il est très courant d’héberger vos charges de travail d’entreprise ou d’autres composants dans différents VLAN. VSS et vDS prennent en charge l’utilisation de VLAN.

Comment le faire

La procédure suivante vous aidera à configurer le VLAN sur un groupe dvPort:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le dvPortGroup souhaité et cliquez sur Modifier les paramètres ….
3. Dans la fenêtre Edit Settings, accédez à VLAN et définissez le type de VLAN souhaité (VLAN, VLAN trunking, Private VLAN). Cliquez ensuite sur OK:
4. La définition du type de VLAN sur VLAN sera nécessaire pour spécifier un numéro de VLAN (la valeur par défaut est 1):
5. Si vous définissez le type de VLAN sur la jonction VLAN, vous devrez spécifier les VLAN à trunker par le dvPortGroup. La valeur par défaut est 0-4094, qui correspond à tous les VLAN:

Les trames avec le numéro de VLAN spécifié par cette plage ne seront pas marquées / non marquées par le vDS. Contrairement au vSS, où vous devez spécifier 4095 pour activer la jonction, avec vDS, vous pouvez spécifier une plage ou un numéro de VLAN séparé par des virgules à jonction.

1. La définition du type de VLAN sur Private VLAN nécessite qu’il soit déjà configuré sur le vDS. Nous apprendrons comment procéder dans la recette Configuration des VLAN privés sur vDS :

Ceci termine le processus de configuration des VLAN sur un vDS.

Comment ça marche

vDS prend en charge quatre types de marquage VLAN:

• Étiquetage des commutateurs externes
• Étiquetage de commutateur virtuel (VST)
• Étiquetage d’invité virtuel (VGT)
• VLAN privés (PVLAN) – uniquement pris en charge sur un vDS

Marquage des commutateurs externes

Avec le balisage de commutateur externe, ce sera le commutateur physique auquel l’hôte ESXi est connecté qui effectue le balisage ou le balisage des trames Ethernet. Les ports de commutation physiques, dans ce cas, sont des ports d’accès. Par conséquent, il n’est pas nécessaire de configurer les VLAN sur les groupes de ports du commutateur virtuel. Les images entrent et laissent le commutateur virtuel sans étiquette.

L’un des inconvénients majeurs de ce type d’implémentation est que l’intégralité du commutateur virtuel (tous les groupes de ports sur celui-ci) ne traitera que le trafic provenant d’un seul sous-réseau de couche 2. En effet, un port d’accès sur un commutateur physique ne peut pas être configuré pour acheminer le trafic provenant de plusieurs VLAN. Le diagramme suivant illustre le flux de trames en mode EST.

VST

Avec VST, les trames Ethernet de couche 2 sont étiquetées au niveau de la couche de commutateur virtuel.

Pour que cette implémentation fonctionne, la carte réseau physique transportant le trafic doit être connectée à un port de commutateur physique, qui est configuré pour agréger les VLAN nécessaires. Les groupes de ports sur le vSwitch doivent être configurés avec les ID VLAN de leurs sous-réseaux respectifs.

VST est l’implémentation la plus courante et privilégiée dans la plupart des environnements grands / moyens / petits, non seulement en raison de la flexibilité qu’il offre, mais également en raison du fait que la plupart des environnements de systèmes lames modernes ont réduit le nombre de ports NIC physiques sur le serveur matériel, grâce à l’avènement de l’Ethernet 10 Gbps. Le diagramme suivant illustre le flux de trames en mode VST :

En mode VST, une trame provenant d’une machine virtuelle entre dans le commutateur virtuel sans étiquette. Le commutateur virtuel attribue ensuite une balise VLAN à la trame en fonction du numéro de VLAN configuré sur le groupe de ports. La trame balisée sera ensuite transférée sur la carte réseau physique active au port de jonction sur le commutateur physique.

Lorsqu’une trame balisée entre dans un commutateur virtuel à partir du commutateur physique, la couche de commutateur virtuel supprimera la balise avant qu’elle ne soit envoyée à la machine virtuelle.

VGT

Avec VGT, les trames ne sont marquées ni par le commutateur physique ni par le commutateur virtuel. Les deux couches de commutation achemineront le trafic des machines virtuelles. Le système d’exploitation invité s’exécutant sur la machine virtuelle est seul responsable du balisage et du désétiquetage des trames. Voici un diagramme du flux de trames en mode VGT :

Pour que VGT fonctionne, le groupe de ports du commutateur virtuel doit être configuré pour agréger les VLAN.

Sur un vSphere Distributed Switch, le type de VLAN sur le dvPortGroup doit être défini sur la jonction VLAN et spécifier une plage ou des numéros VLAN séparés par des virgules à jonction :

Sur un vSwitch vSphere Standard, vous spécifiez un ID VLAN de 4095 pour activer la jonction. Ce faisant, tous les VLAN seront agrégés:

Il est essentiel de savoir que les VLAN ne peuvent pas être configurés sur des commutateurs virtuels – ils ne peuvent être configurés que sur des groupes de ports (standard / dvPortGroup) et dvPorts.

Configuration de VLAN privés sur un vDS

Les VLANs fournissent la segmentation logique d’un réseau afin de différents domaines de diffusion. Les PVLAN fournissent une méthode pour segmenter davantage un VLAN en différents groupes privés. Nous pouvons ajouter et configurer des PVLAN sur un commutateur distribué vSphere. Pour que les PVLAN fonctionnent, les commutateurs physiques qui sauvegardent votre environnement doivent être compatibles PVLAN.

Les PVLAN doivent être configurés sur les commutateurs physiques pour que la configuration fonctionne. Contactez votre administrateur réseau pour les numéros VLAN principaux, communautaires et isolés.

Comment faire

La procédure suivante vous aidera à configurer les PVLAN sur un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et accédez à Paramètres | Modifier le VLAN privé … :
3. Dans la fenêtre Edit Private VLAN Settings, ajoutez l’ID de VLAN principal, puis les ID de VLAN secondaires souhaités. Une fois que vous avez terminé, cliquez sur OK:
4. Maintenant, vous devriez pouvoir définir un ID de VLAN privé sur un dvPortGroup:

Ceci termine le processus de configuration des PVLAN sur un vDS.

Fonctionnement

Comme nous l’avons mentionné au début de cette recette, pour que les PVLAN fonctionnent, les VLAN primaires et secondaires doivent être créés sur le commutateur physique. Le VLAN principal est un VLAN qui a été configuré en tant que VLAN privé sur l’interface du commutateur physique en mode Promiscuous. Les VLAN secondaires sont des VLAN associés à un VLAN principal.

Il existe trois types de PVLAN secondaires :

• PVLAN promiscuous : les machines virtuelles d’un VLAN privé promiscuous peuvent communiquer avec n’importe quelle machine virtuelle appartenant à l’un de ses PVLAN secondaires. Le PVLAN promiscuous agit comme une passerelle pour d’autres PVLAN secondaires.
• PVLAN communautaire : les machines virtuelles d’un VLAN privé communautaire ne peuvent parler qu’entre les machines virtuelles du même PVLAN communautaire ou du PVLAN promiscuous. Ils ne peuvent pas communiquer avec des machines virtuelles dans d’autres PVLAN secondaires.
• PVLAN isolé : VM dans un PVLAN isolé et isolées de toutes les autres VM dans le même PVLAN isolé. Ils peuvent uniquement communiquer avec les machines virtuelles dans un PVLAN promiscuous. Il ne peut y avoir qu’un seul PVLAN isolé par PVLAN principal.

Ces PVLAN sont illustrés dans le diagramme suivant :

Comme nous l’avons mentionné précédemment, la prise en charge des VLAN privés permet une ségrégation supplémentaire des sous-réseaux VLAN. Il offre un niveau de flexibilité avec ses définitions de limites d’accès intrinsèques. PVLAN n’est pas un concept VMware, mais un concept de réseau pris en charge par VMware sur VDS.

Configuration d’un groupe d’agrégation de liens (LAG) sur un vDS

Le protocole LACP (Link Aggregation Control Protocol) vous permet de regrouper les adaptateurs physiques hôtes et les ports sur un commutateur physique pour former un pipeline de communication plus important, augmentant ainsi la disponibilité et la bande passante. Un tel pipeline est appelé Ether Channel. Le diagramme suivant illustre le flux de travail de configuration du LAG:

Les adaptateurs réseau physiques et les groupes de ports de commutateurs physiques sont appelés LAG .

Comment le faire

La procédure suivante vous aidera à configurer le LAG sur un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Sélectionnez le vDS, accédez à Configurer | Paramètres | LACP, puis cliquez sur + NOUVEAU:
3. Dans la fenêtre Nouveau groupe d’agrégation de liaisons, indiquez un nom pour le LAG, le nombre de ports, le mode et le mode d’équilibrage de charge. Une fois les paramètres spécifiés, cliquez sur OK pour créer le LAG :
4. Maintenant, utilisez le flux de travail Migration du trafic réseau vers les LAG pour migrer le trafic souhaité vers le LAB nouvellement créé sans perdre la connectivité réseau:

Comme vous pouvez le voir sur la capture d’écran ci-dessus, la migration du trafic vers le LAG est un processus en trois étapes et les sous-sections suivantes les couvrent.

Définition de LAG comme liaison montante de secours sur des groupes de ports distribués

La première étape de la migration du trafic réseau consiste à faire du LAG une liaison montante de secours sur le dvPortGroup souhaité. Commençons :

1. Dans la fenêtre Migration du trafic réseau vers des groupes d’agrégation de liens, cliquez sur Gérer les groupes de ports distribués.
2. Dans l’écran Select port group policies , sélectionnez Teaming and failover. Cliquer sur Suivant pour continuer :
3. Sur l’écran Select port groups, sélectionnez un dvPortGroup et cliquez sur Next:
4. Sur l’écran Teaming and failover, déplacez le LAG des liaisons montantes inutilisées vers les liaisons montantes de secours :
5. Dans la fenêtre Confirmer les paramètres de regroupement et de basculement, cliquez sur OK :
6. Sur l’écran Prêt à terminer, cliquez sur Terminer.

Une fois que vous avez ajouté le LAG en tant que liaison montante de secours pour le dvPortGroup, l’étape suivante consiste à commencer à réaffecter les cartes réseau physiques aux ports du LAG.

Réaffectation des adaptateurs réseau physiques des hôtes aux ports LAG

La procédure suivante vous aidera à mapper vmnics aux ports LAG :

1. Dans la fenêtre Migration du trafic réseau vers des groupes d’agrégation de liens, cliquez sur Ajouter et gérer des hôtes.
2. Dans l’assistant Ajouter et gérer des hôtes, sélectionnez Gérer la mise en réseau des hôtes. Cliquer sur Suivant pour continuer.
3. Sur l’écran Sélectionner les hôtes, cliquez sur Hôtes attachés … pour ajouter les hôtes souhaités. Cliquez sur Suivant pour continuer :
4. Dans la section Gérer les adaptateurs physiques, cliquez sur Attribuer la liaison montante pour mapper les ports LAG aux vmnics. Cliquez ensuite sur Suivant pour continuer:
5. Passez à travers les écrans Gérer les adaptateurs VMkernel et Migrer les réseaux VM en cliquant sur Suivant.
6. Sur l’écran Prêt à terminer, cliquez sur Terminer.

Une fois que les cartes réseau physiques sont attribuées aux LAG, l’étape suivante consiste à reconfigurer le dvPortGroup avec LAG comme seule liaison montante active.

Définition du LAG pour être la seule liaison montante active sur les groupes de ports distribués

La procédure suivante vous aidera à configurer l’ordre de basculement NIC du dvPortGroup pour faire du LAG la liaison montante active :

1. Dans la fenêtre Migration du trafic réseau vers des groupes d’agrégation de liens, cliquez sur Gérer les groupes de ports distribués.
2. Dans l’écran Gérer les groupes de ports distribués, sélectionnez Association et basculement. Cliquez sur Suivant pour continuer.
3. Sur l’écran Select port groups, sélectionnez le dvPortGroup souhaité et cliquez sur Next.
4. Sur l’écran Association et basculement, déplacez le LAG des liaisons montantes de secours vers les liaisons montantes actives et assurez-vous qu’il s’agit de la seule liaison montante active pour le dvPortGroup. Déplacez ensuite toutes les autres liaisons montantes vers les liaisons montantes inutilisées :
5. Sur l’écran Prêt à terminer, cliquez sur Terminer.

Vous avez maintenant correctement configuré le dvSwitch et le groupe de ports souhaité pour utiliser les groupes d’agrégation de liens.

Comment ça marche

Bien que les LAG soient créés sur le vDS, ils sont directement associés à l’hôte ESXi à partir duquel les liaisons montantes sont utilisées. Vous pouvez configurer jusqu’à un maximum de 64 LAG par hôte ESXi, et donc le nombre total de LAG sur un vDS est également de 64. Chaque LAG peut avoir jusqu’à 32 ports LAG, ce qui signifie que chaque hôte peut contribuer jusqu’à 32 vmnics à un DÉCALAGE.

Pour que les LAG créés sur le vDS fonctionnent, il est important de s’assurer que les vmnics mappés aux ports LAG qui ont été créés sont membres d’un groupe Ether Channel sur le commutateur physique. Le diagramme suivant illustre la disposition de configuration LACP – Infrastructure Wide:

Les LAG LACP fonctionnent selon deux modes : actif (dynamique) et passif (statique). En mode dynamique, le LAG est en mode actif, ce qui lui permet d’envoyer des PDU LACP afin de négocier l’état et la configuration du LACP. En mode statique, le LAG est en mode passif, en attente sur les PDU LACP du LAG actif. Au moins un des LAG d’un groupe Ether Channel doit être en mode actif pour que LACP fonctionne.

Configuration des pools de réseaux définis par l’utilisateur – NIOC

Le contrôle des E / S réseau (NIOC) est une fonctionnalité vDS qui peut gérer l’utilisation de la bande passante réseau des types de trafic système en fonction des partages, des réservations et des limites. NIOC est actuellement à la version 3 et a été publié avec vSphere 6.0. Il existe différents types de gestion du trafic système : FT, vMotion, VM, iSCSI, NFS, réplication vSphere, vSAN et vSphere protection des données. Voici une capture d’écran des différents types de gestion du trafic système :

Par défaut, le trafic système n’a aucune réservation. Cependant, vous pouvez définir une réservation sur le type de trafic de la machine virtuelle, puis séparer davantage la bande passante en créant des pools de ressources réseau. Ces pools de ressources réseau définis par l’utilisateur sont ensuite mappés sur dvPortGroups.

Dans cette recette, nous allons apprendre à créer des pools de ressources réseau définis par l’utilisateur.

Se préparer

NIOC est une fonctionnalité de licence Enterprise Plus et est activée par défaut sur un vDS:

Si vous avez choisi de désactiver le NIOC qui a créé le vDS, vous devrez activer le NIOC avant de continuer.

Comment faire

La procédure suivante vous aidera à créer des pools de ressources réseau définis par l’utilisateur :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Sélectionnez le vDS et accédez à Configurer | Allocation des ressources | Pools de ressources réseau. Ensuite, cliquez sur Réserver la bande passante pour le trafic des machines virtuelles :
3. Dans la fenêtre Modifier les paramètres de ressource, définissez une réservation en Mbps ou Gbps et cliquez sur OK :
4. Une fois que vous avez terminé, cliquez sur + AJOUTER pour créer un pool de ressources réseau :
5. Dans la fenêtre Nouveau pool de ressources réseau, spécifiez un nom, définissez une réservation de bande passante en Gbps ou Mbps, puis cliquez sur OK :

Vous venez de créer un pool de ressources réseau.

Fonctionnement

La réservation que nous avons configurée pour le réseau de machines virtuelles sur le vDS est une réservation de bande passante par carte réseau physique (vmnic). La réservation totale équivaut au nombre total de cartes réseau physiques participant à vDS, multiplié par la bande passante réservée par carte réseau.

Par exemple, réservation 5 Gbps x 6 vmnics = 30 Gbps . Il y a six vmnics car il y a trois vmnics participants de deux hôtes :

Capacité de bande passante = (bande passante de l’adaptateur physique) x (nombre de vmnics de chaque ESXi participant) x (nombre d’hôtes ESXi).

Réservation configurée = (réservation de bande passante) x (nombre de vmnics de chaque ESXi participant) x (nombre d’hôtes ESXi).

Le pool de ressources réseau nouvellement créé peut être mappé à un dvPortGroup. Cela garantira que les machines virtuelles du dvPortGroup recevront la bande passante réservée pendant la contention :

Contrairement aux réservations, les partages allouent une bande passante non réservée aux types de trafic de contenu ou aux VM en fonction de leur valeur de partage relative. Découvrez les instances suivantes :

• Valeur de partage par défaut de 50 pour les types de trafic vMotion, gestion et réplication vSphere.
• Les liaisons montantes utilisées doivent avoir la même capacité de bande passante, qui, dans ce cas, est de 10 Gbps.
• Étant donné que chaque type de trafic a une valeur de partage de 50, la valeur de partage cumulée est de 150.
• Pendant la contention, chacun des types de trafic obtiendra (50/150) x 100 = 33% de la bande passante totale. Cela représente 33% de 30 Gbit / s, soit environ 9,9 Gbit / s pour chaque type de trafic.

Migration du réseau de machines virtuelles de vSS vers vDS

Une fois que vous avez créé et configuré le vDS et son dvPortGroup, l’une des étapes suivantes consiste à migrer le réseau de machines virtuelles de vSS vers vDS. Pour ce faire, remplacez l’étiquette de réseau (groupe de ports) utilisée par les vNIC par le dvPortGroup souhaité. Bien que cela puisse être fait à l’aide de diverses méthodes d’interface utilisateur, la méthode la plus intuitive et conviviale consiste à utiliser l’assistant Migrer les machines virtuelles vers un autre réseau car il vous permet d’orchestrer sélectivement ce processus pour un grand nombre de machines virtuelles sur plusieurs hôtes.

Se préparer

Avant de commencer, il est essentiel de vous assurer que les dvPortGroups sont configurés pour utiliser les mêmes paramètres de VLAN, MTU, d’association et de sécurité.

Pour garantir que les machines virtuelles ne perdent pas la connectivité réseau, le dvPortGroup doit être configuré avec une liaison montante qui prend en charge le trafic de la machine virtuelle.

Comment faire

La procédure suivante vous aidera à migrer des machines virtuelles actuellement connectées à des groupes de ports sur un vSS vers dvPortGroups sur un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le groupe de ports vSphere Standard à partir duquel vous souhaitez migrer la machine virtuelle et cliquez sur Migrer les machines virtuelles vers un autre réseau:

Assistant de démarrage de migration

1. Sur l’écran Sélectionner les réseaux source et de destination, parcourez et définissez le dvPortGroup souhaité comme réseau de destination. Une fois que vous avez terminé, cliquez sur Suivant pour continuer :
2. Dans l’écran Sélectionner les machines virtuelles à migrer, sélectionnez Toutes les machines virtuelles ou sélectionnez uniquement les machines virtuelles que vous souhaitez migrer. Cliquez ensuite sur Suivant pour continuer:
3. Sur l’écran Prêt à terminer, passez en revue le résumé et cliquez sur Terminer:
4. Le volet Tâches récentes doit indiquer que les tâches de reconfiguration de la machine virtuelle ont été effectuées avec succès:

Ceci termine le processus de migration d’un réseau de machines virtuelles de vSS vers vDS.

Comment ça marche

Lorsque vous migrez un réseau de machine virtuelle d’un vSS vers un vDS, il modifie le mappage d’étiquette de réseau (groupe de ports) pour les vNIC sélectionnés pour correspondre au nom du dvPortGroup. Tant que le dvPortGroup de destination dispose de liaisons montantes qui prennent en charge le trafic réseau de la machine virtuelle (par exemple, il se trouve sur le même VLAN), la connectivité réseau des machines virtuelles reste inchangée.

Migration des interfaces VMkernel de vSS vers vDS

L’une des étapes suivantes après la création d’un vDS et de ses dvPorts consiste à migrer les interfaces VMkernel sur l’hôte ESXi vers le VDS. Étant donné que les interfaces VMkernel sont spécifiques à chaque hôte, la meilleure méthode consiste à utiliser l’assistant de mise en réseau Migrate à partir de l’hôte ESXi.

Se préparer

Avant de migrer les interfaces VMkernel (qui peuvent inclure l’interface de gestion), il est essentiel que le dvPortGroup soit configuré avec au moins une liaison montante qui prend en charge le trafic. Assurez-vous également que les paramètres VLAN, MTU, d’association et de sécurité sont répliqués à partir du groupe de ports vSS.

Comment faire …

La procédure suivante vous aidera à migrer les interfaces VMkernel de vSS vers vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue Hôte et cluster.
2. Sélectionnez l’hôte ESXi souhaité, accédez à Configurer | Commutateurs virtuels, sélectionnez le vDS vers lequel vous souhaitez migrer les interfaces VMkernel, puis cliquez sur Migrer le réseau …:
3. Sur l’écran Gérer les adaptateurs physiques de l’assistant de migration de réseau, mappez les liaisons montantes au VDS si vous ne l’avez pas déjà fait. Cliquez ensuite sur Suivant pour continuer :
4. Sur l’écran Gérer les adaptateurs VMkernel, sélectionnez l’interface VMkernel et cliquez sur Affecter un groupe de ports pour lui mapper un dvPortGroup. Une fois que vous avez terminé, cliquez sur Suivant pour continuer :
5. Ignorez l’écran de mise en réseau Migrate VM en cliquant sur Suivant, car il n’est pas pertinent pour cette procédure.
6. Consultez le résumé sur l’écran Prêt à terminer et cliquez sur Terminer :
7. Une fois cela fait, l’interface VMkernel devrait maintenant être sur le vDS:

Ceci termine le processus de migration des interfaces VMkernel de vSS vers vDS.

Comment ça marche …

Pendant la migration de l’interface VMkernel, la communication sur ces ressources ne sera pas affectée. Cependant, si pour une raison quelconque vous finissez par migrer l’interface VMkernel de gestion vers un dvPortGroup sans la configuration nécessaire pour prendre en charge le trafic des interfaces, vous perdrez la connectivité avec l’hôte ESXi. Pour récupérer de cela, vous devrez accéder à la console de l’hôte ESXi via la console IPMI de l’hôte, telle que le DRAC, l’OIT ou le KVM, et utiliser la DCUI pour restaurer le vSwitch standard ou utiliser la CLI pour modifier la configuration du dvPortGroup.

Il y a plus …

Plus d’informations sur la migration d’une interface VMkernel utilisée pour le réseau de gestion entre vSwitches standard (article 2037654 de la base de connaissances VMware) sont disponibles sur http://kb.vmware.com/kb/2037654.

Configuration de la mise en miroir des ports sur vDS

La mise en miroir des ports est une fonctionnalité qui vous permet de cloner le trafic réseau sur un dvPort vers un autre port ou une liaison montante (destination) sur le même dvSwitch. Cela est particulièrement utile lorsque vous disposez d’un analyseur de paquets ou d’un système de détection d’intrusion ( IDS ) déployé sur le réseau. La mise en miroir des ports ne peut être activée que sur un vDS et non sur un vSS.

Se préparer

Avant d’apprendre à configurer la mise en miroir des ports, il est important que vous ayez une bonne compréhension des méthodes de mise en miroir et des sources / destinations prises en charge.

Le tableau suivant compare les options de sélection de sources / destinations disponibles en fonction des types de session miroir, ce qui vous aidera à décider du type de session miroir requis :

Session type	Supported source types	Supported destination types
Distributed port mirroring	dvPorts	dvPorts
Remote mirroring source	dvPorts	Uplinks
Remote mirroring destination	VLAN	dvPorts
Encapsulated remote mirroring (L3) source	dvPorts	IP address

Comment le faire …

La procédure suivante vous aidera à configurer la mise en miroir des ports sur un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Sélectionnez le vDS souhaité et accédez à Configurer | Miroir de port. Cliquez ensuite sur Nouveau … :
3. Sur l’écran Sélectionner le type de session, sélectionnez le type de session souhaité et cliquez sur Suivant pour continuer.

Pour en savoir plus sur les différents types de sessions, lisez la section fonctionnement de cette recette.

1. Sur l’écran Modifier les propriétés, les paramètres de la session peuvent être configurés comme indiqué dans la capture d’écran suivante :

Passons en revue les paramètres de la session de mise en miroir :

• Name : il s’agit d’un nom unique pour la session.
• Status: l’état doit être défini sur Activé.
• Normal I/O on destination ports : interdites / autorisées – elles sont utilisées pour autoriser / interdire le trafic normal, ainsi que le trafic en miroir sur le port de destination.
• Mirrored packet length: Ceci est utilisé pour définir une limite sur la longueur de paquet en miroir en octets. La valeur par défaut est 60 octets. Le reste du paquet est tronqué. Il n’est pas nécessaire de le configurer à moins que l’outil de surveillance de destination ne soit configuré pour décomposer / combiner les paquets selon ses besoins.
• Sampling rate : il est utilisé pour définir le n ème paquet qui doit être mis en miroir. La valeur par défaut est 1, ce qui reflète chaque paquet. Par exemple, si vous définissez à 4, elle reflète tous les 4 e paquet.
• Description : Il s’agit d’une description facultative.
• Encapsulation VLAN ID : il n’est disponible que lorsque le type de session est Source de mise en miroir à distance. Étant donné que la destination du type de session Source de mise en miroir à distance est une ou des liaisons montantes, il est possible que les liaisons montantes soient agrégées pour plusieurs VLAN. Par conséquent, il peut s’avérer nécessaire d’encapsuler les trames à l’aide d’un VLAN. Si les dvPorts source se trouvent sur un autre VLAN eux-mêmes, vous pouvez choisir de conserver l’option VLAN d’origine pour encapsuler deux fois les trames en miroir.

1. Les options présentées dans les écrans Sélectionner les sources et Sélectionner les destinations dépendent du type de mise en miroir sélectionné.
2. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer :

Ceci termine le processus de configuration de la mise en miroir des ports sur un vDS.

Comment ça marche …

Une fois qu’une session de mise en miroir de ports a été créée, tout le trafic provenant de la source sélectionnée est mis en miroir vers la destination souhaitée. Il peut s’agir de dvPorts ou de VLAN. La destination peut être des dvPorts, des liaisons montantes ou les adresses IP des machines exécutant l’application de surveillance du trafic.

Il existe quatre types de mise en miroir :

• Mise en miroir de ports distribués : cela réplique le trafic d’un ou plusieurs dvPorts vers d’autres dvPorts auxquels les vNIC de la machine virtuelle exécutant le logiciel de surveillance sont connectés. Ce type de session ne fonctionnera que si les machines virtuelles source et de destination sont sur le même hôte ESXi.
• Source de mise en miroir à distance : Cela réplique le trafic d’un ou plusieurs ports DV vers les liaisons montantes. Ceci est utilisé lorsqu’un analyseur de trafic est une machine connectée à l’un des ports du commutateur physique. Cela nécessiterait un changement de configuration sur le commutateur physique pour refléter le trafic reçu sur un port physique vers un autre port physique sur le même commutateur auquel la machine de l’analyseur de paquets est connecté ou vers un port sur un commutateur différent (avec l’aide de RSPAN VLAN).
• Destination de mise en miroir à distance : Cela réplique le trafic d’un VLAN vers dvPorts. Ceci est utilisé lorsque vous souhaitez surveiller le trafic d’un VLAN particulier en mettant en miroir le trafic vers un dvPort auquel une machine virtuelle de surveillance est connectée.
• Source de mise en miroir à distance encapsulée (L3) : Ceci réplique le trafic d’un ou plusieurs ports dv vers une adresse IP distante. Ceci est utilisé lorsque l’analyseur de paquets s’exécute sur une machine sur un sous-réseau différent.
• Miroir de port distribué (hérité) : cela réplique le trafic d’un ou plusieurs dvPorts vers d’autres dvPorts ou ports de liaison montante sur l’hôte.

Configuration de NetFlow sur vDS

NetFlow est une norme de l’industrie pour la surveillance du trafic réseau. Développé à l’origine par Cisco, il est depuis devenu un standard de l’industrie. VMware prend en charge IP Flow Information Export (IPFIX), qui est similaire à NetFlow et était à l’origine basé sur NetFlow version 9. Bien que VMware l’appelle NetFlow version 10, il s’agit essentiellement d’IPFIX.

Une fois activé, il peut être utilisé pour capturer des statistiques de trafic IP à partir de toutes les interfaces sur lesquelles NetFlow est activé et les envoyer en tant qu’enregistrements au logiciel collecteur NetFlow.

Comment le faire …

La procédure suivante vous aidera à configurer IPFIX sur un vDS et à l’activer sur un dvPortGroup:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Sélectionnez le vDS souhaité, allez dans Configurer | NetFlow, puis cliquez sur MODIFIER …:
3. Sur l’écran Modifier les paramètres NetFlow, spécifiez la demande de détails et cliquez sur OK:
4. Une fois que vous avez terminé, vous pouvez maintenant activer NetFlow sur les dvPortGroups souhaités :

Ceci termine le processus d’activation de NetFlow sur un vDS.

Comment ça marche …

NetFlow, une fois configuré sur le dvSwitch, permettra au logiciel collecteur NetFlow de capturer et d’analyser les statistiques du dvSwitch. Le dvSwitch est identifié par le logiciel collecteur NetFlow à l’aide de l’adresse IP que nous avons attribuée au dvSwitch lors de la configuration de NetFlow dessus. Les adresses IP attribuées au dvSwitch ne lui donnent pas d’identité de réseau. Il est uniquement utilisé par le collecteur NetFlow pour identifier de manière unique le dvSwitch. Si vous ne spécifiez pas d’adresse IP, vous verrez une session distincte pour l’hôte ESXi qui est membre de l’adresse IP dvSwitch.Collector. Il s’agit de l’adresse IP de la machine collecteur NetFlow dans votre environnement.

Passons en revue tous les paramètres de flux net :

• Adresse IP du collecteur : il s’agit de l’adresse IP de la machine du collecteur NetFlow dans votre environnement.
• Port collecteur : le port UDP 2055 est le numéro de port collecteur NetFlow le plus utilisé.
• ID de domaine d’observation : il s’agit de l’ID d’observation du collecteur NetFlow. Ces informations peuvent être obtenues à partir de la machine du collecteur NetFlow.
• Adresse IP du commutateur : il s’agit simplement d’une adresse IP représentative et non de la vraie. Cela ne constitue pas la partie VDS d’un réseau. Il fournit uniquement un ID unique au VDS dans le logiciel de surveillance NetFlow.
• Délai d’expiration du flux actif : il s’agit de la durée, mesurée en secondes, que le VDS attendra avant de commencer à fragmenter un flux de trafic actif et à envoyer les données au moniteur NetFlow.
• Délai d’expiration du flux inactif : il s’agit de la durée, mesurée en secondes, que le VDS attendra avant de commencer à fragmenter un flux inactif et à envoyer les données au moniteur NetFlow.
• Taux d’échantillonnage : cette valeur détermine le nombre et la fréquence de la collecte du paquet. La valeur par défaut de 1 collectera chaque paquet. Si la valeur est définie sur 5, il collecte tous les cinq paquets.
• Traiter uniquement les flux internes : permet de collecter des données à partir du trafic qui ne quitte jamais un hôte ESXi. Par exemple, le trafic entre deux machines virtuelles dans le même VLAN et le même hôte ne doit pas quitter l’hôte.
  1. Mettre à niveau un vDS

Pendant le processus de mise à niveau d’un environnement vSphere, une fois que le vCenter et les hôtes ESXi ont été mis à niveau, l’une des prochaines étapes sera de mettre à niveau les commutateurs distribués vSphere, le cas échéant.

• • 1. Comment le faire

La procédure suivante vous aidera à mettre à niveau un vDS:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et accédez à Mise à niveau | Mettre à niveau le commutateur distribué … :

Démarrer l’assistant de mise à niveau du commutateur distribué

1. Dans l’écran Configurer la mise à niveau de l’assistant, choisissez une version vers laquelle effectuer la mise à niveau et cliquez sur Suivant pour continuer :
2. L’écran Vérifier la compatibilité affichera les résultats du contrôle de compatibilité de l’hôte. Vérifiez ces paramètres et cliquez sur Suivant pour continuer :
3. Sur l’écran Prêt à terminer, passez en revue le résumé et cliquez sur Suivant pour continuer:
4. Vous devriez voir une tâche connexe terminée dans le volet Tâches récentes :

Ceci termine le processus de mise à niveau des commutateurs distribués vSphere.

• • 1. Comment ça marche

La mise à niveau du vDS est un processus non perturbateur, mais ne peut pas être inversé.

• 1. Sauvegarde et restauration d’un vDS

La configuration vDS peut être sauvegardée puis restaurée à partir de, si nécessaire. Dans cette recette, nous allons apprendre à exporter la configuration vDS puis à restaurer à partir d’une configuration exportée.

• • 1. Comment le faire

La procédure suivante vous aidera à sauvegarder et restaurer vDS à l’aide du client HTML5.

• • 1. Exportation de la configuration vDS

Regardons les étapes suivantes :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et accédez à Paramètres | Exporter la configuration …:
3. Sur l’écran Exporter la configuration, choisissez le vDS entier ou simplement le vDS à l’exclusion de dvPortGroups, fournissez une description facultative et cliquez sur OK :
4. Cela exportera un fichier appelé backup.zip.
   • 1. Restauration à partir d’une sauvegarde

Regardons les étapes suivantes :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire du réseau.
2. Cliquez avec le bouton droit sur le vDS souhaité et accédez à Paramètres | Restaurer la configuration ..:
3. Sur l’écran de configuration du commutateur de restauration, parcourez et sélectionnez le fichier de sauvegarde et choisissez de restaurer l’intégralité du vDS ou simplement le vDS sans dvPortGroups. Ensuite, cliquez sur Suivant pour continuer :
4. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer :

Ceci termine le processus de sauvegarde et de restauration d’un vDS.

• • 1. Comment ça marche

L’exportation créée est un instantané de la configuration actuelle de vDS. L’archive ZIP contient les fichiers de données vDS au format binaire et un fichier data.xml avec les métadonnées dvSwitch:

Le dossier de données conserve un fichier .bak distinct pour chaque dvPortGroup et un pour le vDS:

Le fichier ZIP de sauvegarde peut être utilisé pour restaurer la configuration ou même former un nouveau vDS via l’assistant d’importation de commutateur distribué.

Configuration de l’accès au stockage pour votre environnement vSphere

Le stockage fait partie intégrante de toute infrastructure vSphere car il est nécessaire pour stocker vos machines virtuelles (VM). Différents types de stockage peuvent être incorporés dans une infrastructure vSphere, et ces types sont déterminés en fonction de divers facteurs, tels que le type de disques utilisés, le protocole de stockage et le type de connectivité. La façon la plus courante de se référer aux types de stockage présentés à une infrastructure vSphere est basée sur le protocole de stockage utilisé, leur type de connexion et leur localité (stockage directement connecté ou distant).

ESXi prend en charge le stockage local et distant. Le stockage local fait référence au stockage accessible depuis le serveur ou directement connecté au serveur à l’aide d’une connectivité point à point. Le stockage à distance, au contraire, est accessible via une infrastructure réseau, que ce soit Fibre Channel (FC) ou Ethernet. Le diagramme suivant montre les types de disques, les initiateurs et les protocoles de stockage pris en charge :

Passons en revue chacun des protocoles de stockage pris en charge dans un environnement vSphere :

• Fibre Channel (FC) : ce type de stockage est accessible via un réseau Fibre Channel composé de commutateurs de matrice et de la baie FC. Le protocole FC est utilisé pour encapsuler et transmettre des commandes SCSI entre les hôtes et la baie. Les hôtes se connectent au réseau FC à l’aide d’un adaptateur de bus hôte FC (FC-HBA). La matrice de stockage se connecte au réseau FC à l’aide des ports de leurs points d’extrémité appelés processeur de stockage, contrôleur de stockage ou processeur de service.
• FC sur Ethernet (FCoE) : ce type de stockage se connecte sur un réseau Ethernet composé de commutateurs FCoE et de la baie FC. Les trames FC sont encapsulées dans des trames FCoE. Il est important de noter que FCoE n’utilise pas TCP / IP pour le transport de trames. Les hôtes se connectent au réseau FCoE à l’aide d’une carte réseau convergée compatible FCoE.
• Stockage connecté au réseau (NAS) : ce type de stockage se connecte sur le réseau TCP / IP existant, ce qui facilite sa mise en œuvre. Contrairement à FC et FCoE, ce n’est pas une implémentation sans perte. Comme les commandes SCSI sont envoyées sur le réseau TCP / IP, elles sont sujettes à des pertes de paquets en raison de divers facteurs. Bien que la perte de paquets ne brise rien, elle aura un impact significatif par rapport au FC et au FCoE. ESXi prend en charge deux types de NAS : Internet SCSI (iSCSI) et Network File System (NFS) :
  • iSCSI : cela vous permet d’envoyer des commandes SCSI sur un réseau IP à un système de stockage qui prend en charge l’utilisation de ce protocole.
  • NFS : il s’agit d’un protocole de système de fichiers distribué qui vous permet de partager l’accès aux fichiers sur le réseau IP. Contrairement à iSCSI, FC, FCoE ou Direct Attached Storage (DAS), ce n’est pas un protocole de stockage par blocs. La différence essentielle ici est que le stockage de blocs peut être présenté dans un format brut sans système de fichiers. Au contraire, le stockage NFS n’est rien d’autre qu’un dossier partagé (montage) sur un système de fichiers déjà existant. VMware prend en charge NFS version 3 et NFS 4.1.
• Stockage attaché direct (DAS) : il s’agit d’un module de stockage directement connecté à l’hôte.

Il existe quatre autres termes courants que nous utilisons lorsque nous traitons du stockage dans un environnement vSphere : numéro d’unité logique (LUN), système de fichiers de machine virtuelle (VMFS), montages NFS et magasins de données :

• LUN : le stockage à partir d’un tableau est présenté sous la forme de conteneurs logiques. Le conteneur n’est rien d’autre qu’une collection de blocs de stockage découpés dans l’ensemble du pool de l’espace libre disponible sur la baie. Chacun de ces conteneurs logiques se voit attribuer un numéro d’unité logique ou LUN. Ces unités logiques sont considérées comme des périphériques de stockage par un hôte ESXi.

vSphere 6.7 prend en charge jusqu’à 1 024 LUN par hôte. Cependant, VMware prend uniquement en charge jusqu’à 1 024 banques de données partagées dans un cluster.

• VMFS : un LUN présenté à partir du stockage FC / iSCSI / DAS peut être formé à l’aide du système de fichiers propriétaire de VMware, appelé VMFS. La version la plus récente de VMFS est VMFS6. VMFS permet à plusieurs hôtes ESXi d’effectuer une lecture / écriture sur le même volume. Ceci est réalisé en utilisant un mécanisme de verrouillage sur disque appelé verrouillage distribué, qui empêche un fichier d’être simultanément accédé par plus d’un processus hôte. Les verrous sont implémentés en utilisant des réservations SCSI-2 ou la primitive ATS de VAAI :
  • VMFSv6 prend en charge une taille de volume maximale de 64 To, une taille de bloc uniforme de 1 Mo et des sous-blocs plus petits de 8 Ko.
  • VMFS6 prend également en charge la récupération automatique de l’espace à l’aide de VAAI UNMAP.
• NFS mounts : contrairement aux volumes VMFS, les montages NFS sont des montages partagés sur un système de fichiers distant. Le système de fichiers sous-jacent peut varier en fonction du type de serveur NFS.

Vous pouvez configurer jusqu’à 256 montages spécifiques à la version NFS sur un hôte ESXi. Cela signifie que nous pouvons monter 256 NFSv3 avec des montures 256NFS4.1.

• Magasins de données : il s’agit d’un terme courant utilisé pour désigner les conteneurs de stockage créés sur un hôte ESXi. Les conteneurs peuvent être des volumes VMFS ou des montages NFS. Tous les fichiers qui composent une machine virtuelle sont stockés dans une banque de données.

Dans ce chapitre, nous couvrirons les recettes suivantes :

• Connexion d’hôtes ESXi à un stockage Fabric
• Connexion d’ESXi au stockage iSCSI
• Multipathing iSCSI utilisant la liaison de port
• Connexion des hôtes ESXi au stockage NFS
• Affichage des périphériques de stockage et des banques de données sur les hôtes ESXi
• Masquage des chemins vers un périphérique de stockage
• Démasquer les chemins d’accès à un périphérique de stockage

Connexion des hôtes ESXi à un stockage Fabric

Les hôtes ESXi peuvent être configurés pour accéder aux LUN à partir d’un stockage Fabric. Pour ce faire, connectez les hôtes ESXi aux commutateurs FC auxquels la baie Fibre Channel est connectée. Le diagramme suivant est une configuration d’infrastructure courante :

Comment faire

Dans cette recette, nous allons couvrir un aperçu de très haut niveau de ce qui doit être fait pour présenter les LUN aux hôtes ESXi :

1. Planifiez et implémentez l’infrastructure Fabric pour éviter les points de défaillance uniques :

• Sur l’hôte : chaque adaptateur de bus hôte (HBA) sur un hôte est un point de défaillance unique.
• Au niveau du tissu : chaque commutateur de tissu est un point de défaillance unique.
• Au niveau de la baie : chaque contrôleur de stockage, contrôleur RAID et disque est un point de défaillance unique.

1. Une fois les hôtes connectés (câblés) aux commutateurs FC, créez des zones FC pour donner accès aux contrôleurs de la baie de stockage. Le zonage est utilisé pour configurer des segments logiques dans une structure. Seuls les nœuds d’une zone peuvent communiquer entre eux. Le zonage est généralement effectué à l’aide des noms mondiaux (WWN) des nœuds qui se connectent à la structure.
2. Une fois que les hôtes ont obtenu l’accès aux contrôleurs de stockage, utilisez le masquage pour restreindre davantage l’accès aux LUN, si nécessaire.
3. Au niveau de la baie de stockage, affectez des LUN aux initiateurs hôtes. La méthode varie selon chaque fournisseur de stockage, mais le concept de mappage des LUN reste le même.
4. Exécutez une nouvelle analyse sur les adaptateurs HBA sur les hôtes ESXi pour détecter les LUN qui lui sont présentés.
5. Vous pouvez ensuite créer des volumes VMFS sur ces LUN ou utiliser les LUN comme mappages de périphériques bruts.

Nous en apprendrons plus sur la création et la gestion de volumes VMFS dans les recettes ultérieures de ce chapitre.

Comment ça marche

Les centres de données modernes sont remplis de tant de composants qu’il est très facile d’ignorer des points de défaillance uniques. Les pannes de composants sont relativement courantes lorsque vous avez une grande infrastructure. Par conséquent, il est nécessaire de concevoir l’infrastructure pour survivre à de telles défaillances. L’accès au stockage fait partie intégrante de toute infrastructure VMware. Par conséquent, il est impératif de s’assurer que l’infrastructure de stockage est conçue et mise en œuvre d’une manière qui non seulement atteint le niveau de performance souhaité, mais la rend également résistante aux défaillances. La résilience peut être obtenue en concevant l’infrastructure de redondance. Nous en apprendrons plus à ce sujet dans les sections suivantes.

Conception pour la redondance

Les centres de données modernes sont remplis de tant de composants qu’il est très facile d’ignorer des points de défaillance uniques. Les pannes de composants sont relativement courantes lorsque vous avez une grande infrastructure. Par conséquent, il est nécessaire de concevoir l’infrastructure pour survivre à de telles défaillances. L’accès au stockage fait partie intégrante de toute infrastructure VMware. C’est principalement pour cette raison qu’il est essentiel de s’assurer qu’il est conçu et mis en œuvre d’une manière qui non seulement atteint le niveau de performance souhaité, mais le rend également résistant aux défaillances.

Les types d’échecs les plus courants que vous rencontrerez sont les suivants :

• Câbles en tissu défectueux
• Défaillances HBA / port
• Défaillances de commutateur / port de matrice
• Défaillances de contrôleur / port de baie de stockage
• Défaillances du disque dur

Passons maintenant en revue les mesures proactives qui peuvent être envisagées pour éviter des points de défaillance uniques dans l’infrastructure de stockage. Nous couvrirons les mesures suivantes:

• Éviter les points de défaillance uniques sur l’hôte ESXi
• Éviter les points de défaillance uniques sur le tissu
• Éviter les points de défaillance uniques sur la baie de stockage

Éviter les points de défaillance uniques sur l’hôte ESXi

Les hôtes ESXi qui ont besoin d’accéder au stockage FC devront être équipés d’initiateurs FC ou de HBA. Certains serveurs sont livrés avec des adaptateurs intégrés, certains avec une option pour installer des cartes, et certains avec une combinaison des deux. Les adaptateurs de bus hôte sont fabriqués avec un ou plusieurs ports par carte. Quel que soit le nombre de ports, chaque HBA est un point d’échec, il est donc important de s’assurer que vous avez au moins deux HBA par serveur sur lesquels ESXi sera installé.

Éviter les points de défaillance uniques au niveau du tissu

Le réseau FC est formé à l’aide d’un ensemble de commutateurs de structure. Ces réseaux sont appelés tissus . Il est recommandé d’utiliser plus d’un commutateur de matrice afin de soutenir votre matrice afin d’éliminer les points de défaillance uniques.

Éviter les points de défaillance uniques sur la baie de stockage

La baie de stockage est le cœur et l’âme de tout centre de données et elle stocke la plupart des données de l’entreprise. Il est primordial de s’assurer qu’il existe différents niveaux de redondance au sein d’une baie de stockage afin d’éviter des points de défaillance uniques. Pour commencer, tous les LUN créés dans la matrice de stockage sont soutenus par plusieurs disques durs (HDD) dans un groupe RAID pour prendre en charge les performances et la récupération envisagées. S’il n’y a pas de groupes RAID et si les LUN sont soutenus par un seul grand disque dur, les composants du disque dur, tels que le contrôleur de disque dur, deviendront un point de défaillance unique. Aujourd’hui, la plupart des baies auront plus d’un contrôleur de stockage permettant d’accéder à tous les LUN et d’éliminer les points de défaillance uniques.

Zonage et masquage des tissus

Lorsque vous implémentez une infrastructure avec un stockage FC, il est impératif de vous assurer que lors de la présentation du stockage aux hôtes ESXi, vous vous assurez que seuls les hôtes ESXi prévus voient les LUN requis. Ceci est réalisé en utilisant deux méthodes, appelées zonage et masquage.

Le zonage est configuré sur le commutateur de matrice auquel les HBA ESXi et les contrôleurs de stockage sont câblés. La fonction de zonage est utilisée pour créer des segments logiques dans une structure. Seuls les nœuds d’une zone peuvent communiquer entre eux, avec des initiateurs (HBA) et des cibles (contrôleurs). Il existe deux types de zonage : le zonage dur et le zonage doux :

• Le zonage dur est effectué en regroupant les ports F dans une zone. Un port F est un port physique sur un commutateur Fabric. Tout appareil qui se connecte à un port F de la zone aura accès aux autres appareils de la zone. Chaque port F aura une adresse FC attribuée dynamiquement qui lui sera attribuée lorsque le port se connectera à la structure. Ceci est considéré comme le type de zonage le plus sécurisé, mais comme les adresses FC peuvent être affectées par des changements de configuration sur la structure, de tels événements vous obligeront à refaire le zonage avec les adresses FC nouvellement affectées des ports F. Le diagramme suivant illustre le zonage dur de tissu :
• Le zonage logiciel est effectué à l’aide des WWN des nœuds qui se connectent à la structure. Étant donné que les WWN sont statiques et ne sont pas tenus de changer, cela est considéré comme le type de zonage le plus flexible. Vous pouvez même refaire le câblage des nœuds vers différents ports F sur un commutateur Fabric sans affecter la configuration de la zone. Le diagramme suivant illustre le zonage Fabric Soft (WWN):

WWN : Tout comme les adresses MAC sont destinées à une infrastructure Ethernet, dans une infrastructure FC, chaque périphérique se voit attribuer un identifiant unique 64 bits appelé WWN. Les WWN peuvent être de deux types : un nom de nœud mondial (WWNN) ou un nom de port mondial (WWPN). Les WWPN sont également appelés ID de port de nœud. Par exemple, un adaptateur HBA à deux ports aura un WWPN affecté à chacun de ses ports et un seul WWNN pour le HBA lui-même.

Le masquage peut être effectué sur la baie de stockage ou sur l’hôte ESXi. Le zonage ne peut pas dépasser les limites des ports de nœud qui se connectent à la structure. Le masquage est effectué pour ajouter un niveau de sécurité plus profond au sein d’une zone. Lorsque vous zonez des HBA et des contrôleurs de stockage dans une zone, les HBA ont accès à tous les LUN présentés aux contrôleurs de stockage. Dans un environnement de grande taille, une baie de stockage hébergera un certain nombre de LUN et tous ne devraient pas être visibles par chaque nœud initiateur qui se trouve dans la zone. C’est là que le masquage entre en scène. Le masquage segmente davantage une zone en listes de contrôle d’accès en permettant uniquement aux hôtes prévus de voir les LUN requis.

Prenons l’exemple suivant :

• Une fois le zonage terminé, nous avons deux hôtes, [H1] et [H2], zonés pour accéder aux contrôleurs de stockage [A] et [B].
• Le contrôleur [A] a des LUN [L1] et [L2] qui lui sont mappés et le contrôleur [B] a des LUN [L2] et [L3] qui lui sont mappés. Le diagramme suivant illustre le zonage après accès aux LUN :

Supposons maintenant que tous les hôtes ESXi de la zone ne doivent pas accéder à tous les LUN zonés. Dans ce cas, [H1] a uniquement besoin d’accéder aux LUN [L1] et [L4] et [H2] n’a besoin d’accéder qu’aux LUN [L2] et [L3]. Ceci peut être réalisé en créant des listes de contrôle d’accès ( ACL ) sur les contrôleurs [A] et [B]. Le diagramme suivant illustre l’accès aux LUN après le masquage dans le zonage de la baie de stockage :

Par conséquent, le contrôleur [A] aura une entrée ACL pour [H1] et les LUN [L1] et [L4], et le contrôleur [B] aura une entrée ACL pour [H2] et les LUN [L2] et [L3].

Connexion d’ESXi au stockage iSCSI

iSCSI est un protocole utilisé pour transporter des commandes SCSI sur un réseau TCP / IP. Dans un environnement iSCSI, la machine cliente (dans ce cas, un hôte ESXi) utilise des initiateurs iSCSI (matériel / logiciel) pour se connecter aux cibles iSCSI sur un système de stockage iSCSI (baie).

Dans cette recette, nous apprendrons comment configurer et se connecter à la baie en utilisant le type le plus utilisé: l’initiateur logiciel iSCSI.

Se préparer

Avant de commencer, vous aurez besoin des informations suivantes à portée de main :

• Une adresse IP détectable du serveur cible iSCSI et le numéro de port à utiliser
• Détails d’authentification du protocole CHAP (Challenge Handshake Authentication Protocol) (le cas échéant)

Comment le faire

La procédure suivante vous aidera à activer le logiciel iSCSI et à configurer l’accès au stockage iSCSI :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Sélectionnez l’hôte ESXi, accédez à Configurer | Adaptateurs de stockage, puis cliquez sur Ajouter un adaptateur logiciel :
3. Dans la fenêtre Ajouter un adaptateur logiciel, cliquez sur Ajouter un adaptateur iSCSI logiciel et cliquez sur OK :

Pour configurer l’accès à la baie, procédez comme suit :

1. Sélectionnez l’adaptateur iSCSI et notez son nom qualifié iSCSI ( IQN ) dans l’onglet Propriétés. L’IQN est utilisé pour ajouter l’initiateur hôte à la baie et lui mapper les LUN :
2. Accédez à l’onglet Découverte dynamique et cliquez sur Ajouter … pour spécifier les détails du serveur / de la baie iSCSI :
3. Dans la fenêtre Ajouter un serveur cible d’envoi, spécifiez le nom de domaine complet ou l’adresse IP du serveur iSCSI et cliquez sur OK :
4. Analysez à nouveau l’adaptateur logiciel iSCSI afin de découvrir les périphériques qui lui sont mappés :
5. Une fois la nouvelle analyse terminée, l’onglet Périphériques répertorie les LUN mappés à l’hôte:

Ceci termine le processus de configuration de l’accès iSCSI pour ESXi à l’aide d’un adaptateur logiciel iSCSI.

Comment ça marche

Passons en revue certains des concepts iSCSI essentiels qui pourraient vous aider à apprendre comment fonctionne iSCSI dans un environnement vSphere :

• Initiateur iSCSI : il s’agit d’un adaptateur logiciel / matériel qui réside sur un hôte ESXi et peut se connecter à une cible iSCSI. L’adaptateur logiciel iSCSI est intégré au VMkernel et peut être activé à volonté. L’adaptateur matériel iSCSI peut être de deux types : dépendant et indépendant. Bien que l’adaptateur iSCSI dépendant gère le traitement des paquets, il dépend toujours d’ESXi pour sa configuration et sa gestion de réseau. L’adaptateur iSCSI indépendant permet à la fois la configuration et le traitement des paquets.
• Cible iSCSI : il s’agit d’une interface réseau sur la baie iSCSI ou simplement d’une référence à un LUN. Certaines baies, telles que Dell EqualLogic et HP StoreVirtual, présentent chaque LUN comme cible.

À partir de vSphere 6.5, l’initiateur iSCSI et la cible iSCSI peuvent désormais se trouver sur deux sous-réseaux de couche 2 différents.

• Portail iSCSI : il s’agit d’une combinaison de l’adresse IP de la cible iSCSI et du port d’écoute (par défaut : 3260). Un portail iSCSI à l’initiateur est l’adresse IP de l’interface VMkernel et un numéro de port aléatoire.
• Session iSCSI : il s’agit d’une session TCP / IP établie entre un initiateur iSCSI et une cible iSCSI. Chaque session peut avoir une ou plusieurs connexions vers la même cible. Dans le cas d’un logiciel iSCSI, une session est établie entre chaque interface VMkernel bornée (liaison de port) et une cible iSCSI. Par exemple, s’il existe deux interfaces VMkernel liées à l’initiateur iSCSI, l’initiateur établira deux sessions distinctes pour chaque cible qu’il découvre.
• Connexion iSCSI : chaque session iSCSI peut avoir plusieurs connexions au portail cible iSCSI. Le diagramme suivant illustre une seule session iSCSI avec deux connexions :
• CHAP : Ceci est utilisé par iSCSI pour s’assurer que l’initiateur et la cible établissent une connexion sécurisée et sécurisée.
• Découverte dynamique : il s’agit du mécanisme de découverte de cible le plus couramment utilisé, ce qui est pratique lorsque le serveur iSCSI expose un grand nombre de LUN / cibles via son portail cible.
• Découverte statique : contrairement au mécanisme de découverte dynamique, la découverte statique ne voit pas chaque LUN / cible exposée via le portail cible. Au lieu de cela, il ne voit que les cibles spécifiées.
• IQN : il s’agit d’un identifiant unique associé à chaque initiateur iSCSI ou cible iSCSI. L’identifiant commence par la chaîne IQN suivie de l’année et du mois où l’autorité de nommage a été établie, le domaine de l’autorité de nommage à l’envers et un nom unique pour le nœud de stockage. Chacune de ces chaînes est séparée par un point ( . ). Le diagramme suivant illustre le format de nom qualifié iSCSI :

Multipathing iSCSI utilisant la liaison de port

Le multipathing iSCSI dépendra du type de stockage et de la topologie du réseau utilisés. Il existe deux méthodes pour cela:

• Multipathing pour iSCSI en utilisant la liaison de port : Ceci est réalisé en ayant deux interfaces VMkernel configurées avec un adaptateur actif chacune, mais pas d’adaptateurs de secours. Une fois cela fait, ces interfaces VMkernel (vmk) doivent être liées à l’adaptateur logiciel iSCSI.
• Multipathing pour iSCSI sans liaison de port : lisez la section Quand ne pas utiliser la liaison de port de VMware KB : 2038869 pour plus de détails (http://kb.vmware.com/kb/2038869).

Dans cette recette, nous apprendrons comment préparer le réseau vSphere pour le multichemin iSCSI en créant plusieurs interfaces VMkernel, ce que nous ferons en utilisant le même ensemble de cartes réseau physiques en alternant les paires actives / inutilisées. Cette méthode est utilisée pour réaliser le multichemin iSCSI en utilisant la méthode de liaison de port.

Se préparer

Créez deux interfaces VMkernel sur deux groupes de ports distincts (standard ou distribués), avec des adresses IP dans le même sous-réseau que le système de stockage iSCSI (portail cible). Utilisez la capture d’écran suivante comme exemple :

Une fois cela fait, modifiez l’ordre de basculement de telle manière que seule l’une des liaisons montantes soit active et que l’autre ne soit pas utilisée. Utilisez la capture d’écran suivante comme exemple :

Pour que la liaison de port fonctionne, les interfaces VMkernel et les portails cibles iSCSI ne peuvent pas se trouver sur des sous-réseaux réseau disparates. En d’autres termes, ils doivent être dans le même domaine de diffusion (VLAN). Ce n’est qu’une limitation avec la liaison de port ; iSCSI prend autrement en charge le routage.

Il existe des cas où la liaison de port ne doit pas être utilisée pour réaliser le multichemin. La section Quand ne pas utiliser la liaison de port de l’article 2038869 de la base de connaissances VMware ( https://kb.vmware.com/kb/2038869) contient plus de détails.

Comment le faire

La procédure suivante vous aidera à lier les adaptateurs VMkernel à l’adaptateur logiciel iSCSI :

1. Assurez-vous que les adaptateurs VMkernel ont été préparés en utilisant les instructions de la section Préparation de cette recette.
2. Accédez à l’hôte ESXi et accédez à Configurer | Adaptateurs de stockage, sélectionnez l’adaptateur iSCSI, accédez à son onglet Liaison de port réseau et cliquez sur + Ajouter … :
3. Dans la fenêtre Bind vmhba65 with VMkernel Adapter, sélectionnez les deux groupes de ports correspondant aux interfaces VMkernel et cliquez sur OK :
4. Une fois cela fait, les adaptateurs VMkernel seront répertoriés sous Liaison de port réseau. L’état du chemin d’accès n’est pas utilisé car les cibles n’ont pas encore été associées aux interfaces. Exécutez une nouvelle analyse pour associer les cibles à l’interface VMkernel:
5. Après une nouvelle analyse, l’état du chemin pour les deux interfaces liées est défini sur Actif :
6. Vous devriez maintenant voir deux chemins par cible de l’initiateur iSCSI:

Ceci termine le processus de liaison des ports VMkernel à l’adaptateur logiciel iSCSI pour réaliser le multiacheminement.

Comment ça marche

Par défaut, un seul chemin de sortie existe entre l’adaptateur logiciel iSCSI et une cible iSCSI :

Pour activer l’équilibrage de charge ou la redondance pour le trafic iSCSI régressant un hôte ESXi, nous utilisons la liaison de port. Avec la liaison de port, vous liez plusieurs interfaces VMkernel (vmk) à l’adaptateur iSCSI logiciel, comme illustré dans le diagramme suivant :

Le nombre de chemins mis à la disposition de l’initiateur iSCSI dépendra du type de système de stockage iSCSI (baie).

Le type d’une baie iSCSI est basé sur le nombre de cibles ou de portails cibles qu’elle expose. La principale différence entre une cible et un portail cible est qu’une cible iSCSI sera associée à un IQN unique, tandis qu’un portail cible est identifié par une combinaison adresse IP : numéro de port.

Il existe trois types de baies iSCSI, comme suit :

• Baie à portail unique
• Tableau multi-portail
• Tableau multi-cible

Avec une baie à portail unique, le système de stockage expose un portail unique à découvrir par la source (initiateur). Par conséquent, le nombre de chemins d’accès à un tel tableau dépendra du nombre d’interfaces VMkernel associées à l’initiateur iSCSI. Le processus d’association d’interfaces VMkernel avec un initiateur iSCSI est appelé liaison de port. Nous en apprendrons plus sur la liaison de port dans cette recette.

Avec une baie multi-portails, le système de stockage expose plusieurs portails à découvrir par l’initiateur iSCSI. Par conséquent, le nombre de chemins d’accès à la baie dépendra non seulement du nombre de ports VMkernel liés à l’initiateur iSCSI mais également du nombre de portails exposés. Par exemple, si deux ports VMkernel sont liés à l’initiateur iSCSI découvrant quatre portails cibles, le nombre de chemins vers la cible iSCSI est de huit.

Avec une baie multi-cibles, le système de stockage expose plus d’une interface cible iSCSI (donc différents IQN) avec un ou plusieurs portails associés à chaque interface. Il est important de comprendre que cela est différent du système de stockage exposant les LUN en tant que cibles à l’initiateur.

La formule pour calculer le nombre de chemins possibles dépend du nombre de portails source (ports VMkernel) et de portails cibles, et non du nombre de cibles :

• Le nombre total de chemins = (nombre de portails source) x (nombre de portails cibles).
• Ici, le portail source n’est rien d’autre que les interfaces VMkernel liées à l’initiateur iSCSI.

Lorsque vous affichez les informations de multiacheminement pour les baies à un ou plusieurs portails à partir de l’interface graphique de vCenter, chaque portail de découverte est répertorié comme cible. Ces cibles auront le même IQN, mais des adresses IP de portail différentes qui leur sont associées. Cependant, pour les tableaux multi-cibles, vous verrez également des cibles avec différents IQN.

Connexion des hôtes ESXi au stockage NFS

Le stockage NFS est également un NAS, comme iSCSI. Par conséquent, il peut être facilement intégré au réseau TCP / IP existant. Contrairement à iSCSI, NFS n’est pas un système de stockage par blocs, ce qui signifie que NFS maintient son système de fichiers. Par conséquent, ESXi ne peut pas formater ou former un nouveau système de fichiers sur les volumes qui lui sont présentés à partir d’un tableau NFS. Au lieu de cela, les volumes NFS (également appelés exportations) sont configurés comme points de montage vers des partages distants sur une matrice de stockage NFS.

VMware a introduit la prise en charge de NFS 4.1 à partir de vSphere 6.0:

• Il prend désormais en charge le cryptage AES.
• Il prend en charge IPv6.
• Il prend en charge le mécanisme de vérification d’intégrité de Kerberos.

Vous pouvez créer des banques de données NFS 3 et NFS 4.1 sur ESXi.

Se préparer

Vous aurez besoin des détails suivants à portée de main avant de continuer :

• L’adresse FQDN / IP du serveur NFS
• Un chemin d’accès complet au partage sur le serveur NFS
• Une interface VMkernel sur l’hôte ESXi qui peut se connecter au serveur NFS
• Autoriser l’accès root aux partages sur le serveur NFS, communément appelé no_rootsquash

Comment le faire

La procédure suivante vous aidera à créer une banque de données NFS :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Accédez à l’inventaire de stockage, cliquez avec le bouton droit sur l’objet du centre de données et accédez à Stockage | Nouveau magasin de données … :
3. Dans l’assistant New Datastore, sélectionnez Type as NFS et cliquez sur Next pour continuer:
4. Sur l’écran Sélectionner la version NFS, choisissez la version NFS prise en charge par le serveur NFS et cliquez sur Suivant :
5. Sur l’écran Nom et configuration, spécifiez un nom pour la banque de données, le chemin d’accès au dossier du partage NFS (tel qu’il se trouve sur le serveur NFS) et l’adresse FQDN / IP du serveur NFS. Vous pouvez également choisir de monter NFS en lecture seule. Une fois terminé, cliquez sur Suivant pour continuer :
6. Sur l’écran d’accessibilité de l’hôte, sélectionnez-le ou les hôtes ESXi souhaités et cliquez sur Suivant pour continuer :
7. Sur l’écran Prêt à terminer, vérifiez les paramètres et cliquez sur Terminer:
8. Les tâches récentes doivent afficher une tâche de création de magasin de données NAS qui s’est terminée avec succès :

Ceci termine le processus de mappage des montages de stockage NFS aux hôtes ESXi.

Comment ça marche

Par défaut, vous ne pouvez créer que huit montages NFS par serveur ESXi. Bien que cette limite puisse être augmentée jusqu’à 256 en utilisant le paramètre NFS.MaxVolumes avancé, l’augmentation de cette limite nécessiterait généralement une augmentation de la quantité minimale de mémoire de tas VMkernel TCP / IP. La valeur de mémoire minimale du segment de mémoire peut être spécifiée à l’aide du paramètre avancé Net.TcpipHeapSize . Vous pouvez également définir la quantité maximale de taille de segment de mémoire en utilisant le paramètre avancé Net.TcpipHeapMax .

Pour plus d’informations sur la valeur de taille de segment TCP / IP, consultez l’article 2239 de la base de connaissances VMware (https://kb.vmware.com/kb/2239).

Affichage des périphériques de stockage et des banques de données sur les hôtes ESXi

VMware ESXi utilise des conteneurs de stockage logiques appelés banques de données pour stocker les fichiers qui sauvegardent une machine virtuelle. Une banque de données peut être un volume VMFS ou un montage NFS. Chaque hôte ESXi gère une liste de périphériques et de banques de données auxquels il a accès.

Dans cette recette, nous allons apprendre à afficher les périphériques et les banques de données disponibles sur un hôte ESXi.

Comment le faire

La procédure suivante vous aidera à afficher les périphériques de stockage et les banques de données disponibles sur un hôte ESXi :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Sélectionnez l’hôte dans l’inventaire et accédez à Configurer | Périphériques de stockage afin de visualiser tous les périphériques LUN vus par l’hôte ESXi :
3. Accédez à l’ onglet Banques de données pour afficher toutes les banques de données vues par l’hôte ESXi:

Ceci termine le processus d’affichage des informations concernant les périphériques de stockage et les banques de données accessibles aux hôtes ESXi.

Comment ça marche

Bien qu’il soit assez simple, il est essentiel de savoir comment consulter les informations concernant le stockage accessible lors de l’audit de votre environnement ou du dépannage d’un problème.

Vous pouvez également utiliser l’interface de ligne de commande ( CLI ) ESXi pour afficher les périphériques et les banques de données:

Certaines des autres commandes sont les suivantes :

• esxcli storage filesystem list
• esxcli storage nfs list
• esxcli storage vmfs extent list
• esxcli storage san iscsi list
• esxcli storage san fc list

Masquage des chemins vers un périphérique de stockage

Lors du dépannage des problèmes d’accès au stockage, vous pouvez supprimer l’accès via des chemins d’accès individuels à un périphérique de stockage. Ceci est réalisé en utilisant le plugin MASK_PATH de PSA pour revendiquer les chemins souhaités correspondant au périphérique.

L’organigramme suivant illustre un aperçu de haut niveau du processus :

Se préparer

Avant de masquer les chemins d’accès à un LUN, il est important de s’assurer que les volumes VMFS qui leur correspondent n’hébergent plus aucune machine virtuelle en cours d’exécution. De plus, si les LUN sont des mappages de périphériques bruts (RDM), ils ne doivent être mappés à aucune des VM en cours d’exécution.

Comment faire

La procédure suivante vous aidera à masquer les chemins d’accès individuels à un périphérique LUN:

1. SSH dans l’hôte ESXi souhaité.
2. Obtenez l’ID NAA de l’appareil pour lequel le chemin doit être masqué, en exécutant la commande suivante :

esxcli storage vmfs extent list

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante:

1. Obtenez les informations de multiacheminement actuelles du périphérique à l’aide de la syntaxe de commande suivante :

esxcfg-mpath -l -d <naa-id of the LUN>

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante:

Dans ce cas, il existe deux chemins vers le périphérique LUN et nous masquerons l’un des chemins (vmhba65 : C1: T3: L0 ).

1. Créez une règle de revendication pour masquer le chemin d’accès souhaité à l’aide de la syntaxe de commande suivante :

esxcli storage core claimrule add -r <rule_number> -t location -A <vmhba> -C <channel number> -L <LUN Number> -P MASK_PATH

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante :

1. Une règle de réclamation créée doit être chargée dans la mémoire pour qu’elle soit effective. Pour ce faire, exécutez la commande suivante :

esxcli storage core claimrule load

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante :

1. Maintenant que la règle est active, le chemin peut être revendiqué par le plugin MASK_PATH , en utilisant la syntaxe de commande suivante:

esxcli storage core claiming reclaim -d <naa.id of the device>

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante:

Ceci termine le processus de masquage des chemins vers un périphérique de stockage présenté à un hôte ESXi.

Comment ça marche

Une fois que vous avez masqué les chemins d’accès à un périphérique LUN, l’hôte ESXi n’aura pas accès au LUN. L’accès ne peut être restauré qu’en démasquant les chemins d’accès au LUN.

Démasquage des chemins vers un périphérique de stockage

Il est possible de démasquer les chemins d’accès à un périphérique de stockage. La suppression des règles de revendication et la non-réclamation des chemins du plugin MASK_PATH y parviennent. Comprendre comment les chemins d’accès à un LUN sont masqués sera un bon point de départ pour cette tâche. Lisez les chemins de masquage vers une recette de périphérique de stockage avant de commencer cette recette.

L’organigramme suivant fournit un aperçu de haut niveau de la procédure de démasquage :

Comment le faire

La procédure suivante vous aidera à démasquer les chemins d’accès à un périphérique de stockage :

1. SSH dans l’hôte ESXi.
2. Identifiez la règle de réclamation correspondant au périphérique. Les règles de revendication sur l’hôte peuvent être répertoriées à l’aide de la syntaxe de commande suivante :

esxcli storage core claimrule list

Une fois que vous exécutez la commande précédente, vous verrez la sortie suivante:

1. Supprimez la règle identifiée à l’aide de la syntaxe de commande suivante :

esxcli storage core claimrule remove -r <Rule ID>

Cela supprimera l’entrée de fichier correspondant à la règle spécifiée. Comme indiqué dans la capture d’écran suivante, l’entrée de fichier correspondant à l’entrée d’exécution est supprimée.

1. Rechargez les règles de revendication pour que les modifications prennent effet en exécutant la commande suivante :

esxcli storage core claimrule load.

Cela supprimera l’entrée d’exécution de la règle puisque l’entrée de fichier de la règle a déjà été supprimée, désactivant ainsi la règle de revendication. La capture d’écran suivante montre que le runtime a également été supprimé.

1. Une fois la règle de revendication désactivée, les chemins peuvent être récupérés à partir du plugin MASK_PATH en utilisant la syntaxe de commande suivante :

esxcli storage core claiming unclaim -t location -A <vmhba number>-C <channel number> -L <LUN ID> -P MASK_PATH

1. Maintenant, lancez une nouvelle analyse sur l’adaptateur à l’aide de la syntaxe de commande suivante :

esxcfg-rescan <vmhba number>

1. Vérifiez le résultat de l’opération de démasquage en répertoriant tous les chemins correspondant au périphérique. Pour ce faire, utilisez la syntaxe de commande suivante :

esxcfg-mpath -l -d <naa.id of the LUN>

Une fois que vous avez exécuté la syntaxe de commande précédente, vous verrez la sortie suivante :

Comment ça marche

Le démasquage des chemins vers un LUN restaure l’accès aux LUN sur l’hôte ESXi. Cette activité est généralement effectuée une fois que l’activité de maintenance ou de dépannage du stockage est terminée.

Création et gestion de banques de données VMFS

Dans le chapitre précédent, nous avons appris à configurer les hôtes ESXi pour accéder aux périphériques de stockage ou LUN iSCSI et Fibre Channel.

Les LUN présentés à partir de la baie n’auraient aucun système de fichiers dessus. VMware vous permet de créer un système de fichiers propriétaire appelé Virtual Machine File System (VMFS). La version la plus récente de VMFS est la version 6. vSphere 6.7 permet la création d’un système de fichiers VMFS5 ou VMFS6 sur le périphérique de stockage.

Dans ce chapitre, nous couvrirons les recettes suivantes :

• Création de banques de données VMFS
• Mise à niveau des banques de données VMFS
• Gestion du multipathing de stockage
• Étendre ou agrandir une banque de données VMFS
• Extension d’une banque de données VMFS
• Démontage des banques de données VMFS et détachement des périphériques de stockage
• Connexion de périphériques de stockage et remontage des banques de données VMFS
• Gestion des instantanés VMFS

Création de banques de données VMFS

Les périphériques de stockage (LUN) présentés à l’hôte ESXi peuvent être formatés avec le système de fichiers de machine virtuelle (VMFS) pour créer des banques de données qui peuvent être utilisées pour stocker des machines virtuelles. Le magasin de données peut être réalisé par soit une connexion directe à l’hôte ESXi ou du vCenter.

Dans cette recette, nous découvrirons comment créer des banques de données VMFS à l’aide de vCenter Server.

Comment le faire

La procédure suivante vous aidera à créer une banque de données VMFS :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Dans la vue Inventaire de stockage, cliquez avec le bouton droit sur le centre de données souhaité et accédez à Stockage | Nouveau magasin de données … :
3. Dans l’assistant New Datastore, sélectionnez Type as VMFS et cliquez sur Next pour continuer :
4. Dans l’écran de sélection du nom et du périphérique, spécifiez un nom pour la banque de données, sélectionnez un hôte ESXi auquel les LUN ont été présentés, puis sélectionnez le périphérique LUN souhaité. Une fois terminé, cliquez sur Suivant pour continuer :
5. Sur l’écran suivant, sélectionnez la version VMFS souhaitée et cliquez sur Suivant pour continuer :
6. Sur l’écran de configuration de partition, choisissez Utiliser toutes les partitions disponibles, puis spécifiez la taille de la banque de données et la priorité de récupération d’espace (aucune / faible). La taille de bloc et la granularité de récupération d’espace seront définies sur 1 Mo et ne peuvent pas être modifiées :
7. Sur l’écran Prêt à terminer, passez en revue le résumé et cliquez sur Terminer pour créer la banque de données :
8. Une fois terminé, le magasin de données nouvellement créé sera répertorié sous l’objet du centre de données, qui se trouve dans l’inventaire de stockage. Sélectionnez la banque de données et accédez à l’onglet Hôtes pour afficher une liste des hôtes ESXi auxquels la banque de données est connectée :

Ceci termine le processus de création de banques de données VMFS.

Comment ça marche

La création d’un magasin de données VMFS efface essentiellement le LUN sélectionné et y écrit le VMFS. L’opération ne doit être effectuée qu’une seule fois à partir de n’importe quel hôte ESXi pouvant accéder au LUN. Une fois cela fait, tous les autres hôtes ESXi peuvent voir le volume VMFS créé sur le LUN.

Mise à niveau des banques de données VMFS

S’il existe des banques de données VMFS5 dans votre environnement, il est important de noter qu’il n’existe aucune méthode pour effectuer une mise à niveau sur place de VMFS5 vers VMFS6. Cela est dû aux modifications apportées à la structure des métadonnées VMFS6 pour la rendre compatible avec l’alignement 4K.

Cette recette vous fournira un aperçu de très haut niveau sur la façon de planifier la migration de vos charges de travail vers VMFS 6.

Comment le faire

La procédure suivante fournit des instructions générales sur la façon dont les charges de travail de VM sur VMFS5 peuvent être migrées vers VMFS6:

1. Faites une liste de toutes les banques de données VMFS5 et de leur utilisation actuelle du stockage.
2. Selon la quantité de capacité disponible disponible dans le système de stockage, vous pouvez choisir de créer des banques de données VMFS6 de tailles similaires ou de créer un ensemble de banques de données plus grandes pour le stockage temporaire.
3. Si des banques de données VMFS6 de taille similaire sont créées, alors Storage vMotion le stockage de la machine virtuelle sur la nouvelle banque de données.
4. Si vous avez créé des LUN temporaires plus importants, vous devez effectuer les étapes suivantes :
   1. Sélectionnez des VM à partir de plusieurs banques de données VMFS5 et migrez les VM vers un LUN plus grand.
   2. Une fois cela fait, supprimez les banques de données VMFS5 maintenant vides.
   3. Créez des banques de données VMFS6 sur les mêmes LUN.
   4. Migrez les machines virtuelles des plus grandes LUN vers les banques de données VMFS6.

Comment ça marche

Étant donné que chaque environnement est différent, plusieurs facteurs pourraient affecter la méthodologie choisie. Reportez-vous à l’article 2147824 de la base de connaissances VMware – https://kb.vmware.com/kb/2147824 – pour différents cas d’utilisation et méthodes.

Gestion du multipath de stockage

La disponibilité du stockage présentée aux hôtes ESXi est essentielle pour le fonctionnement d’un environnement vSphere. L’un des facteurs qui augmente la disponibilité du stockage est le maintien d’une connectivité résiliente au système de stockage. La résilience est obtenue en formant des chemins redondants vers le stockage présenté aux hôtes ESXi. Les chemins peuvent soit être utilisés pour le basculement ou la charge.

Dans cette recette, nous apprendrons comment passer en revue la configuration de multiacheminement actuelle pour chaque périphérique de stockage.

Comment le faire

La procédure suivante vous aidera à afficher et à gérer la configuration de chemins multiples :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à la vue d’inventaire Hosts and Clusters :
2. Sélectionnez l’hôte ESXi souhaité et accédez à Configurer | Périphériques de stockage.
3. Sur l’écran Périphériques de stockage, sélectionnez un périphérique de stockage et son onglet Chemins pour revoir les chemins configurés pour le périphérique. Sur le même écran, vous pouvez même choisir d’activer / désactiver un chemin si nécessaire :

Chemins d’accès aux périphériques de stockage

1. Si vous avez l’intention de changer le dispositif de politique multipathing (chemin politique de sélection (PSP)), puis passez à l’appareil Propriétés de l’onglet, puis cliquez sur Modifier multipathing …:
2. Dans l’onglet Modifier les stratégies de chemins multiples, sélectionnez la stratégie de sélection de chemin préférée et cliquez sur OK pour enregistrer les modifications :
3. Par exemple, ici, nous avons deux chemins vers le périphérique, avec un marqué Actif (E / S) car la stratégie est définie sur Fixe (VMware). Par conséquent, vous êtes autorisé à sélectionner un chemin préféré en le mettant en surbrillance.
4. Maintenant, si nous changeons la stratégie de sélection de chemin d’accès en Round Robin (VMware), les deux correctifs seront marqués pour Actif (E / S), comme indiqué dans la capture d’écran suivante :

Ceci termine la procédure impliquée dans l’affichage et la gestion des chemins d’accès aux périphériques de stockage.

Comment ça marche

Un chemin vers un LUN inclut le HBA ou l’initiateur, les commutateurs de matrice / réseau et les contrôleurs de stockage de la baie. La disponibilité d’un chemin sera affectée si l’un de ces composants matériels le long du chemin échoue ou cesse de fonctionner. Le multichemin est une méthode de configuration et de maintenance de plusieurs chemins entre l’hôte et la baie de stockage. Bien que des commutateurs redondants soient utilisés pour y parvenir, les informations de multiacheminement disponibles sur ESXi ne montreront pas les commutateurs impliqués.

Le multiacheminement du stockage sur un hôte ESXi est réalisé à l’aide d’une infrastructure d’API appelée Pluggable Storage Architecture (PSA). Les API peuvent être utilisées par les fournisseurs de stockage pour développer des plugins multichemin (MPP), permettant ainsi une intégration plus étroite de leurs périphériques de stockage. Voici quelques exemples de MPP tiers disponibles :

• EMC PowerPath
• Dell EqualLogic MEM pour le multichemin iSCSI
• Multipathing dynamique VERITAS pour VMware

Le plug-in de multichemin par défaut sur un hôte ESXi est appelé plug-in de multichemin natif ( NMP ). Le NMP ajoute la prise en charge de toutes les baies de stockage prises en charge dans la liste de compatibilité VMware.

Les sections suivantes vous aideront à comprendre le fonctionnement du NMP et les différents types de stockage pris en charge dans un environnement vSphere.

NMP

Le NMP possède deux sous-plug-ins connus sous le nom de Storage Array Type Plugin ( SATP ) et Path Selection Plugin ( PSP ). VMware inclut les associations SATP et PSP pour toutes les baies de stockage testées et prises en charge sous la forme de règles de revendication. Le SATP détecte l’état du chemin et gère le basculement de chemin, tandis que PSP détermine quel chemin physique disponible doit être utilisé pour envoyer les E / S.

VMware NMP utilise à la fois SATP et PSP pour conserver l’accès aux périphériques de stockage présentés à l’hôte ESXi. Passons en revue ce qui se passe pendant une opération d’E / S, tel que géré par NMP :

• Lorsqu’une E / S est émise vers un périphérique de stockage, le NMP demandera au PSP correspondant au LUN de placer les E / S sur un chemin basé sur la politique (Dernière utilisation (MRU) / Fixe / Round Robin (RR)) choisi.
• Si, pour une raison quelconque, l’opération d’E / S échoue, elle est renvoyée au NMP.
• Le NMP, à son tour, demande au SATP de déterminer la cause de la panne et de prendre les mesures appropriées.
• Si les E / S avaient échoué en raison d’une défaillance de chemin, le SATP marquera ce chemin comme mort et rendra un autre chemin actif.
• Le NMP appellera alors à nouveau la PSP pour réessayer les E / S.
• Cette fois, la PSP peut choisir d’utiliser le nouveau chemin actif.

VMware prend en charge les PSP suivants :

• Most Recently Used(MRU) : en cas de basculement de chemin, cela continuerait à utiliser le chemin même si le chemin d’origine redevenait accessible. Sa sélection de chemin initiale se produit lors du démarrage d’ESXi, où il sélectionne le premier chemin qu’il découvre comme chemin actif. MRU est le PSP préféré pour les baies actives / passives et les baies basées sur ALUA ( Asymmetric Logical Unit Access ).
• Fixed : l’un des multiples chemins est marqué comme chemin préféré. Ainsi, dans le cas où un chemin préféré redeviendrait accessible, il reviendrait au chemin préféré. Ceci est le plus souvent utilisé avec les baies actives / actives et les baies basées sur ALUA.
• Round Robin (RR) : cela distribue les E / S à tous les chemins actifs. Par défaut, il distribue 1 000 opérations d’E / S sur un chemin actif avant d’envoyer les 1 000 E / S suivantes sur le chemin actif suivant.

Multipathing – types de tableaux

Il est également important de comprendre les différents types de tableaux du point de vue des chemins multiples. Le type de tableau est déterminé par le mode dans lequel il fonctionne. Il existe trois types de ce type dans une perspective de chemins multiples :

• Tableaux actifs / actifs
• Matrices actives / passives
• Tableaux ALUA

Tableaux actifs / actifs

Une baie active / active ou symétrique active / active aura tous les ports de ses contrôleurs de stockage configurés pour permettre le traitement simultané des E / S, offrant ainsi les mêmes niveaux de performances et d’accès à tous les LUN. Par conséquent, ils prennent essentiellement en charge la propriété simultanée d’un LUN par plusieurs processeurs de stockage. Il n’y a pas de concept de contrôleur de secours sur une baie active / active :

Lors de la configuration du multichemin vers le stockage présenté à partir d’une telle baie, vous choisissez les différents chemins préférés sur différents ensembles d’hôtes ESXi dans un cluster / centre de données.

Par exemple, si vous avez un cluster à huit hôtes, vous pouvez définir quatre hôtes pour utiliser un chemin préféré via Storage Controller-A, et les quatre autres hôtes pour utiliser un chemin préféré via Storage Controller-B. Cette opération permet de répartir la charge d’E / S entre les contrôleurs.

Tableaux actifs / passifs

Les baies actives / passives ont des contrôleurs de stockage actifs et de secours. Un contrôleur est appelé actif ou passif par rapport aux LUN qu’il possède. Une baie active / passive prend en charge un seul processeur de stockage possédant un LUN particulier.

Dans une baie active / passive, une E / S vers un ensemble de LUN ne peut être traitée que par un contrôleur de stockage qui en est propriétaire. Le contrôleur qui possède un ensemble de LUN est appelé contrôleur actif pour ces LUN. Le même contrôleur peut agir en tant que contrôleur de secours pour un autre ensemble de LUN. Par conséquent, pendant le basculement, le contrôleur de secours peut assumer la propriété des LUN correspondant au contrôleur défaillant, devenant ainsi le nouveau contrôleur actif pour ces LUN. Le diagramme suivant illustre le tableau actif / passif :

Dans cet exemple, il existe deux groupes de LUN, le groupe A et le groupe B , sur une baie active / passive avec les contrôleurs de stockage SP A et SP B:

• Le SP A a été configuré pour posséder des LUN du groupe A et le SP B a été configuré pour posséder des LUN du groupe B.
• Le SP A devient un contrôleur actif et le SP B devient un contrôleur passif pour les LUN du groupe A.
• Le SP B devient un contrôleur actif et le SP A devient un contrôleur passif pour les LUN du groupe B.

Lors de la conception d’un environnement avec des baies actives / passives, assurez-vous que tous les hôtes ESXi sont configurés pour voir les LUN via leurs propres contrôleurs. Une mauvaise configuration entraînera le dépassement de la propriété du LUN par la baie, ce qui peut entraîner un contournement de chemin.

Réseaux d’accès aux unités logiques asymétriques (ALUA)

La baie ALUA est un type de baie active / active, qui peut utiliser simultanément tous ses contrôleurs pour traiter les E / S et également être des partenaires de basculement les uns des autres.

Tout comme dans une baie active / passive, un LUN ou un ensemble de LUN ne peut appartenir qu’à un seul contrôleur. Le contrôleur propriétaire aura un accès symétrique (direct) au LUN, offrant ainsi les meilleures performances. Le contrôleur non propriétaire peut traiter les E / S indirectement (asymétriques) pour le LUN en transférant les E / S via l’interconnexion au contrôleur propriétaire. Par conséquent, il y a un impact sur les performances en raison du temps nécessaire pour transférer les E / S vers le contrôleur propriétaire via l’interconnexion.

Étant donné que la baie présente un moyen – optimal et sous-optimal – d’E / S de processus pour les LUN, il doit y avoir un moyen de faire connaître à ESXi les chemins directs et indirects (via l’interconnexion) vers le LUN. Ceci est réalisé par une fonctionnalité de tableau appelée Groupes de ports cibles (TPGS). TPGS est une méthode pour regrouper séparément les chemins directs et indirects vers un LUN. ESXi les considère comme des chemins actifs (optimisés) et actifs (non optimisés) vers le LUN. Les ports actifs (non optimisés) du contrôleur de stockage peuvent être des ports actifs (optimisés) pour un autre ensemble de LUN. ESXi placera toujours les E / S sur les chemins actifs (optimisés).

L’administrateur de stockage doit répartir uniformément les LUN entre les contrôleurs selon les besoins pour obtenir une utilisation efficace d’une baie ALUA, comme illustré dans le diagramme suivant.

Si vous deviez configurer une baie comme indiqué dans le diagramme précédent, une E / S pour le groupe A , si elle était émise via le contrôleur SP B , entraînerait le passage du trafic par le SP B via l’interconnexion vers le contrôleur SP A, qui puis traitez les E / S. Ce chemin alternatif sera appelé chemin non optimisé actif.

Extension ou croissance d’une banque de données VMFS

Au fur et à mesure que vous déployez de plus en plus de machines virtuelles dans votre environnement, vous pouvez rencontrer une situation dans laquelle la quantité d’espace libre dans une banque de données peut ne pas être suffisante pour les opérations quotidiennes, telles que les sauvegardes, qui impliquent la prise d’instantanés. De l’espace libre peut être ajouté à la banque de données VMFS si la taille du périphérique de stockage qui sauvegarde le volume VMFS peut également être augmentée. Vous pouvez également utiliser un autre LUN pour y étendre le volume VMFS. La procédure d’extension du magasin de données sera traitée dans la prochaine recette, Extension d’un magasin de données VMFS.

La décision de choisir l’une ou l’autre méthode dépendra de la capacité de l’administrateur de stockage à augmenter la taille du périphérique LUN soutenant le volume VMFS.

La procédure pour redimensionner / étendre le LUN dans la matrice de stockage diffère d’un fournisseur à l’autre, et, comme cela dépasse la portée de ce manuel, nous supposons que le LUN a de l’espace libre ou a déjà été étendu.

L’organigramme suivant fournit un aperçu de haut niveau de la procédure :

Comment le faire

La procédure suivante vous aidera à augmenter la taille d’une banque de données en utilisant l’espace libre sur le périphérique de stockage de sauvegarde :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Sélectionnez la banque de données souhaitée dans l’inventaire de stockage, puis accédez à son onglet Configurer afin d’identifier le périphérique LUN qui sauvegarde le volume VMFS :
3. Contactez votre administrateur de stockage pour augmenter la taille du périphérique LUN qui sauvegarde la banque de données que vous êtes sur le point d’étendre.
4. Maintenant, cliquez à nouveau avec le bouton droit sur le magasin de données et cliquez sur Augmenter la capacité du magasin de données … :
5. Sélectionnez le périphérique LUN qui correspond à la banque de données et cliquez sur Suivant pour continuer :
6. L’écran Spécifier la configuration affichera la quantité d’espace libre sur le LUN. Il n’est pas nécessaire d’apporter des modifications sur cet écran. Cliquez sur Suivant pour continuer :
7. Sur l’écran Prêt à terminer, passez en revue le résumé et cliquez sur Terminer :
8. Vous devez voir les tâches connexes terminées avec succès dans le volet Tâches récentes :

Ceci termine le processus d’augmentation / d’extension de la taille d’une banque de données en utilisant la capacité disponible existante ou nouvellement créée sur le LUN soutenant le volume VMFS.

Comment ça marche

L’extension d’une banque de données VMFS fait référence à l’augmentation de sa taille dans sa propre mesure. Cela n’est possible que si de l’espace libre est disponible immédiatement après l’extension. La taille maximale d’un LUN est de 64 To, donc la taille maximale d’un volume VMFS est également de 64 To. Les machines virtuelles hébergées sur ce magasin de données VMFS peuvent continuer à être sous tension pendant que cette tâche est en cours.

Extension d’une banque de données VMFS

Dans la recette Étendre ou agrandir une banque de données VMFS, nous avons appris comment augmenter la taille d’une banque de données en utilisant l’espace inutilisé sur le même LUN qui soutient la banque de données.

Vous pouvez rencontrer une situation dans laquelle il n’y a pas d’espace inutilisé sur le LUN qui sauvegarde le volume VMFS et l’administrateur de stockage n’est pas en mesure de développer davantage le LUN. Heureusement, vSphere prend en charge la répartition d’un volume VMFS sur plusieurs LUN. Cela signifie que vous pouvez répartir le volume VMFS sur un nouveau LUN afin qu’il puisse utiliser l’espace libre sur celui-ci. Ce processus de couvrant un volume VMFS sur un autre numéro d’ unité logique est appelée extension d’ une banque de données VMFS.

Se préparer

Avant que tu commences,

• Présentez un LUN inutilisé de la taille souhaitée à tous les hôtes ESXi qui partagent la banque de données VMFS.
• Notez l’ID NAA, l’ID LUN et la taille du LUN vierge.
• Exécutez une nouvelle analyse des adaptateurs de stockage sur tous les hôtes ESXi qui partagent la banque de données.
• Comment faire…

La procédure suivante vous aidera à augmenter la taille d’un magasin de données VMFS en étendant / répartissant le volume sur un LUN supplémentaire inutilisé avec une capacité libre :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Accédez à l’inventaire de stockage, cliquez de nouveau avec le bouton droit sur la banque de données et cliquez sur Augmenter la capacité de la banque de données … :

Lancer l’assistant d’augmentation de la capacité de la banque de données

1. Dans l’assistant d’ augmentation de la capacité de la banque de données , dans l’ écran Sélectionner un périphérique , sélectionnez le périphérique qui correspond aux détails (ID NAA, ID LUN et taille) fournis par l’administrateur de stockage, puis cliquez sur Suivant pour continuer:
2. Sur l’écran Spécifier la configuration, vous pouvez choisir de spécifier une taille inférieure à la capacité libre, si vous le souhaitez. Sinon, aucune modification n’est requise sur cet écran. Cliquez sur Suivant pour continuer :
3. Sur l’écran Prêt à terminer , passez en revue le résumé et cliquez sur Terminer:
4. Vous devez voir les tâches connexes terminées avec succès dans le volet Tâches récentes :

Ceci termine le processus d’augmentation de la taille d’une banque de données en étendant le volume VMFS sur un périphérique LUN supplémentaire.

Comment ça marche

Contrairement à l’expansion / croissance d’un volume VMFS, l’extension d’un volume étendra le volume sur plusieurs LUN, et cela se fait en ajoutant des extensions supplémentaires au volume VMFS. Lorsque je dis ajouter des extensions supplémentaires, la signification contextuelle fait référence à la partition principale sur le nouveau LUN, qui sera utilisée pour y étendre le volume VMFS.

Une banque de données VMFS peut s’étendre sur un maximum de 32 extensions de LUN. La taille de l’extension peut être supérieure à 2 To, la limite étant la taille de volume VMFS maximale de 64 To.

La première extension du volume VMFS contient les métadonnées de l’ensemble complet des extensions. Si le LUN avec la première extension était perdu, vous perdriez des données sur toutes les autres extensions dépendantes.

Voici à quoi ressemblerait un volume VMFS étendu. Le volume était initialement de 4 To et était soutenu par LUN-A, qui était de la même taille. Le volume a ensuite été étendu sur un nouveau LUN (LUN-B), d’une taille de 2 To, augmentant ainsi la taille effective du volume VMFS à 6 To. Le diagramme suivant illustre les volumes VMFS étendus:

Une idée fausse commune est que si l’un de ces LUN (LUN-A ou LUN-B) se déconnecte ou est inaccessible, le volume VMFS (magasin de données) deviendra également inaccessible. Ce n’est pas vrai. Lorsque vous ajoutez des extensions à une banque de données, le tout premier LUN qui a initialement soutenu la banque de données devient l’étendue principale, car il contient toutes les informations concernant les autres extensions. Si, pour une raison quelconque, vous perdez l’étendue de la tête, cela rendrait la banque de données VMFS entière hors ligne. Cependant, si vous perdez une étendue qui n’est pas une étendue principale, la banque de données restera toujours accessible, mais seules les machines virtuelles dont les disques virtuels dépendent de l’étendue perdue deviendront inaccessibles.

Démontage des banques de données VMFS et détachement des périphériques de stockage

Le démontage d’une banque de données est effectué lorsque vous avez l’intention de conserver les données sur un volume VMFS, mais supprimez l’accès au volume. Le détachement est effectué sur un périphérique LUN et est effectué pour s’assurer que l’accès au LUN est gracieusement supprimé. Il est recommandé de démonter une banque de données VMFS et de détacher son entrée de périphérique de stockage correspondante avant que le LUN qui sauvegarde la banque de données ne soit démappé d’un hôte ESXi.

Se préparer

Avant de commencer, assurez-vous que les étapes suivantes ont été effectuées :

• Migrez toutes les machines virtuelles de la banque de données que vous souhaitez démonter vers une autre banque de données.
• Le magasin de données doit être supprimé d’un cluster de magasins de données.
• Le magasin de données ne doit pas être géré par Storage DRS (SDRS).
• Le contrôle d’E / S de stockage (SIOC) doit être désactivé pour le magasin de données.
• La banque de données ne doit pas être utilisée en tant que banque de données de pulsation vSphere High Availability (HA).
• Notez l’ID NAA du périphérique de stockage qui sauvegarde la banque de données VMFS. Pour ce faire, sélectionnez le magasin de données et accédez à Configurer | Sauvegarde de l’appareil :
• Vous pouvez également exécuter la commande esxcli storage vmfs extend list pour afficher la liste suivante:

Quelle que soit la méthode utilisée, il est important de démonter le volume VMFS de tous les hôtes avant de détacher le périphérique de stockage et de présenter le LUN.

Comment faire

La procédure suivante vous aidera à démonter et à détacher une banque de données VMFS :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à l’inventaire de stockage.
2. Cliquez avec le bouton droit sur le magasin de données souhaité et sélectionnez Démonter le magasin de données …:

Démarrez l’assistant de démontage de la banque de données.

1. Dans la fenêtre Démonter la banque de données, sélectionnez l’hôte ESXi pour démonter la banque de données et cliquez sur OK :
2. Le volet Tâches récentes indiquera la réussite du démontage du volume VMFS:
3. Une fois cela fait, allez dans Configurer | Dans l’onglet Périphériques de stockage de l’hôte ESXi à partir duquel la banque de données a été démontée, sélectionnez le périphérique correspondant à la banque de données VMFS, puis cliquez sur Détacher :
4. Dans la fenêtre Détacher le périphérique, cliquez sur OUI :
5. Le volet Tâches récentes indique que la tâche Détacher le LUN SCSI s’est terminée avec succès:
6. Une fois cela fait, le périphérique de stockage doit être répertorié comme Détaché:

Ceci termine le processus de démontage d’une banque de données et de détachement du périphérique de stockage de l’ESXi. Vous pouvez désormais annuler le mappage du LUN en toute sécurité à partir de l’hôte ESXi en utilisant le système de gestion du stockage de la baie.

Comment ça marche

Le démontage d’une banque de données est un moyen de dire à l’hôte ESXi que le LUN ne sera plus disponible pour aucune opération d’E / S jusqu’à ce qu’il soit remonté. Il est recommandé de démonter une banque de données VMFS avant que le LUN ne la représente à partir d’un hôte ESXi.

La commande esxcli peut également être utilisée pour démonter la banque de données VMFS, mais gardez à l’esprit que cela se fait via la ligne de commande, cela se fait au niveau de chaque hôte. Si vous devez démonter la banque de données de cette façon sur plusieurs hôtes ESXi, vous devrez alors SSH / console dans chacun de ces hôtes ESXi et émettre la commande de démontage.

Connexion de périphériques de stockage et remontage de banques de données VMFS

Un périphérique de stockage précédemment détaché peut être reconnecté et le volume VMFS qu’il contient peut-être à nouveau monté. Si le LUN n’a pas été mappé à l’aide du système de stockage, il doit être mappé à l’hôte avant de continuer.

Comment faire

La procédure suivante vous aidera à monter une banque de données VMFS à partir d’un périphérique reconnecté sur l’hôte ESXi:

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Accédez à Configurer | Onglet Périphériques de stockage de l’hôte ESXi à partir duquel la banque de données a été démontée.
3. Sélectionnez le périphérique détaché et cliquez sur Attacher:
4. Le volet Tâches récentes doit indiquer qu’une tâche Attacher un LUN SCSI s’est terminée avec succès :
5. Une fois cela fait, basculez vers l’inventaire de stockage , cliquez avec le bouton droit sur la banque de données, puis cliquez sur Monter la banque de données …:

Lancer l’assistant de montage de banque de données

1. La fenêtre Monter la banque de données répertorie uniquement les hôtes sur lesquels la banque de données n’est pas actuellement montée. Utilisez la case à cocher pour sélectionner l’hôte ESXi et cliquez sur Suivant :
2. Le volet Tâches récentes doit montrer que le montage du volume VMFS s’est terminé avec succès:

Ceci termine le processus de connexion des périphériques LUN aux hôtes ESXi et de montage des volumes VMFS sur celui-ci.

Comment ça marche

L’opération de montage ne peut être effectuée que sur un périphérique LUN qui n’est plus détaché. Cela rendra la banque de données VMFS disponible pour les opérations d’E / S.

Gestion des instantanés VMFS

Une entreprise peut décider de maintenir des sauvegardes de ses charges de travail de production en répliquant ou en prenant périodiquement les LUN sauvegardant leurs banques de données. Si, pour une raison quelconque, un LUN répliqué ou son instantané est présenté à un hôte ESXi, l’hôte ne montera pas le volume VMFS sur le LUN. Il s’agit d’une précaution pour éviter la corruption des données.

ESXi identifie chaque volume VMFS à l’aide de sa signature désignée par un identificateur universel unique (UUID). L’UUID est généré lorsque le volume est créé ou resignaté pour la première fois et est stocké dans l’en-tête LVM du volume VMFS.

Lorsqu’un hôte ESXi recherche de nouveaux périphériques de stockage, il compare l’ID de périphérique physique (ID NAA) du LUN à la valeur d’ID de périphérique (ID NAA) stockée dans l’en-tête LVM du volume VMFS sur le périphérique. S’il trouve une incompatibilité, il marque le volume comme volume d’instantané. Ces volumes peuvent être montés en attribuant une nouvelle signature ou en conservant la signature existante.

Se préparer

Avant de commencer, assurez-vous que la banque de données VMFS d’origine est démontée et que le support de LUN est détaché de l’hôte ESXi auquel le snapshot LUN est présenté. Procurez-vous également les détails du LUN auprès de l’administrateur du stockage. Les détails incluent l’ID NAA, la capacité LUN et l’ID LUN.

La capture d’écran suivante montre les NAA-ID des LUN d’origine et d’instantané :

Comment faire

La procédure suivante vous aidera à monter des volumes VMFS à partir de périphériques de stockage détectés en tant qu’instantanés :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à l’inventaire Hosts and Clusters.
2. Cliquez avec le bouton droit sur l’hôte ESXi auquel le LUN d’instantané a été mappé et accédez à Stockage | Nouvelle analyse du stockage … :

Lancer l’analyse de stockage

1. Dans la fenêtre Rescan Storage, cliquez sur OK :
2. Cliquez de nouveau avec le bouton droit sur l’hôte ESXi et accédez à Stockage | Nouveau magasin de données … :
3. Dans l’écran Type de l’assistant Nouveau magasin de données, sélectionnez le type de magasin de données en tant que VMFS et cliquez sur Suivant :
4. Sur l’écran de sélection du nom et du périphérique, sélectionnez le périphérique de stockage approprié et cliquez sur Suivant :
5. Sur l’écran d’options de montage, choisissez d’attribuer une nouvelle signature ou de conserver la signature existante et cliquez sur Suivant :
6. Sélectionnez la version VMFS souhaitée et cliquez sur Suivant pour continuer:
7. L’écran Prêt à terminer fournit un résumé du résultat attendu. Vérifiez-le et cliquez sur Terminer :

Ceci termine le processus de gestion des volumes VMFS détectés comme instantanés.

Comment ça marche

Les volumes VMFS sur les périphériques de stockage détectés comme instantanés ne sont pas montés par défaut. Il existe deux façons de monter de tels volumes / banques de données :

• Montez-les en gardant la signature existante intacte : ceci est utilisé lorsque vous essayez de monter temporairement le volume de capture instantanée sur un ESXi qui ne voit pas le volume d’origine. Si vous tentiez de monter le volume VMFS en conservant la signature existante, et si l’hôte devait voir le volume d’origine, le volume VMFS sur le LUN d’instantané ne serait pas monté.
• Montez-les en attribuant une nouvelle signature : cela doit être utilisé si vous montez un clone ou un instantané d’une banque de données VMFS existante sur les mêmes hôtes. Le processus d’attribution d’une nouvelle signature mettra non seulement à jour l’en-tête LVM avec l’UUID nouvellement généré, mais également avec l’ID de périphérique physique (ID NAA) du LUN de capture instantanée. Ici, le volume / magasin de données VMFS sera renommé en préfixant le mot snap-, suivi d’une chaîne alphanumérique aléatoire et du nom du magasin de données d’origine.

SIOC, stockage DRS et stockage piloté par profil

Configuration des partages de disque sur le stockage VM

La définition de partages de disque personnalisés est particulièrement utile lorsque vous souhaitez vous assurer qu’une machine virtuelle reçoit une plus grande partie de la bande passante du disque pendant la contention pour la bande passante d’E / S de stockage. Par défaut, le partage de disque est défini sur Normal (1000). Les autres préréglages disponibles pour définir des partages personnalisés sont Low (500) et High (2000). Dans cette recette, nous apprendrons comment configurer des partages de disque sur des disques de machine virtuelle (VMDK).

Comment le faire

La procédure suivante vous aidera à configurer / modifier des partages de disque sur un VMDK :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Cliquez avec le bouton droit sur la machine virtuelle souhaitée et accédez à Modifier les paramètres … :

Écran Appeler les paramètres de modification

1. Dans la fenêtre Modifier les paramètres, développez le disque dur 1 souhaité et utilisez le paramètre Partages pour définir une valeur de partage égale à faible (500), normal (1000) ou élevé (2000), ou définissez une valeur de partage personnalisée. Une fois terminé, cliquez sur OK pour enregistrer les paramètres :

Comment ça marche

Chaque hôte ESXi exécute un planificateur local pour surveiller et équilibrer les E / S entre les machines virtuelles.

S’il y a des machines virtuelles générant une quantité considérable d’E / S (plus que la normale), il est important de s’assurer que les autres machines virtuelles exécutées sur la même banque de données ne sont pas affectées, car elles doivent être autorisées à émettre des E / S vers le périphérique. avec les performances attendues. Cela peut être réalisé en définissant des partages par disque (VMDK), contrôlant ainsi le volume d’E / S que chaque machine virtuelle participante peut générer pendant la contention.

Les partages de disque fonctionnent à peu près comme les partages CPU / mémoire et ne démarrent qu’en cas de conflit :

• La valeur de partage de disque virtuel par défaut est 1 000, la valeur haute étant 2 000 et la valeur basse 500.
• Le disque avec une valeur de partage relativement plus élevée pourra émettre un plus grand volume d’E / S vers le périphérique.

SIOC prendra en compte la valeur de partage personnalisée lors de la limitation de la file d’attente de périphériques VMkernel.

Activation de SIOC

L’utilisation de partages de disque fonctionnera très bien tant que la banque de données est vue par un seul hôte ESXi. Malheureusement, ce n’est pas un cas courant. Les banques de données sont souvent partagées entre plusieurs hôtes ESXi. Lorsque les banques de données sont partagées, vous intégrez plusieurs planificateurs d’hôte local au processus d’équilibrage des E / S entre les machines virtuelles. Cependant, ces planificateurs d’hôtes perdus ne peuvent pas se parler et leur visibilité est limitée aux hôtes ESXi sur lesquels ils s’exécutent. Cela contribue facilement à un problème grave appelé la situation de voisin bruyant.

Dans l’exemple suivant, puisque VM-C est la seule machine virtuelle sur ESX-02 , il arrive à consommer la profondeur de file d’attente entière, ce qui pourrait affamer les machines virtuelles sur les deux autres hôtes. Si VM-C fait en effet beaucoup d’E / S consommant la profondeur de file d’attente du LUN , il sera alors appelé voisin bruyant:

Le travail de SIOC consiste à activer une certaine forme de communication entre les planificateurs d’hôte local afin que les E / S puissent être équilibrées entre les machines virtuelles exécutées sur des hôtes distincts. Nous en apprendrons plus sur la façon dont SIOC améliore la situation dans la section Comment ça marche … de cette recette. Mais avant cela, nous apprendrons comment activer SIOC.

Se préparer

Avant de commencer, il est important de comprendre les conditions préalables suivantes :

• SIOC ne peut pas être activé sur les banques de données avec plusieurs extensions.
• Le magasin de données ne doit être géré que par un seul vCenter. Cela signifie que si vous partagiez la banque de données entre des clusters d’hôtes gérés par différents vCenters, l’activation de SIOC sur une telle banque de données ne serait pas prise en charge.
• Si votre baie prend en charge la hiérarchisation du stockage, consultez votre fournisseur de stockage avant d’activer SIOC sur vos banques de données.

Comment le faire

La procédure suivante vous aidera à activer SIOC sur une banque de données :

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à l’inventaire de stockage.
2. Cliquez avec le bouton droit sur la banque de données souhaitée et cliquez sur Configurer le contrôle des E / S de stockage … :

Affichez l’écran de configuration SIOC.

1. Sur l’écran Configurer le contrôle des E / S de stockage, cochez Activer le contrôle des E / S de stockage et la collecte des statistiques. Vérifiez la valeur du seuil de congestion et assurez-vous qu’elle est idéale pour votre environnement. Par défaut, SIOC définit dynamiquement la valeur de latence apprise pendant que la banque de données exploite un débit de pointe de 90%. Les statistiques d’E / S collectées seront pour Storage DRS par défaut. Cela peut être modifié en décochant la case Inclure les statistiques d’E / S pour SDRS :
2. Une fois cela fait, accédez à Configurer | Général | Page des capacités du magasin de données pour confirmer :

Ceci termine le processus d’activation de SIOC sur une banque de données.

Comment ça marche

SIOC permet la communication entre les planificateurs de l’hôte local afin que les E / S puissent être équilibrées entre les machines virtuelles exécutées sur des hôtes distincts. Il le fait en conservant un fichier iostats partagé dans la banque de données que tous les hôtes peuvent lire / écrire / mettre à jour.

Le planificateur local sur chacun des hôtes ESXi gère un fichier iostats pour tenir ses hôtes compagnons au courant des statistiques d’E / S de périphérique observées sur le LUN. Le fichier est placé dans un répertoire ( naa.xxxxxxxxx ) sur la même banque de données:

Lorsque SIOC est activé sur une banque de données, il commence à surveiller la latence du périphérique sur le LUN soutenant la banque de données. Si la latence dépasse le seuil, elle limite la profondeur de file d’attente du LUN sur chacun des hôtes ESXi dans une tentative de distribuer une part équitable d’accès au LUN pour toutes les machines virtuelles émettant les opérations d’E / S.

Passons en revue le scénario présenté au début de cette recette et voyons comment SIOC aide à résoudre une situation de voisin bruyant.

Selon le scénario, six machines virtuelles s’exécutent sur trois hôtes ESXi différents, accédant à un LUN partagé. Parmi les 6 machines virtuelles, quatre d’entre elles ont une valeur de partage normale de 1 000 et les 2 autres ont une valeur de partage de disque élevée (2 000) définie sur elles. Ces VM n’ont qu’un seul VMDK qui leur est attaché.

VM-C sur l’hôte ESX-02 émet un grand nombre d’opérations d’E / S. Étant donné que c’est la seule machine virtuelle à accéder au LUN partagé à partir de cet hôte, elle obtient la bande passante de la file d’attente entière. Cela peut induire une latence sur les opérations d’E / S effectuées par les autres VM : ESX-01 et ESX-03 . Si SIOC détecte que la valeur de latence est supérieure au seuil dynamique, il commencera alors à limiter la profondeur de la file d’attente.

Le tableau suivant vous aidera à comprendre comment le pourcentage de part équitable est calculé par SIOC :

Le DQLEN étranglé pour une machine virtuelle est calculé comme suit:

DQLEN pour la VM = (pourcentage de partages de la VM) de (profondeur de file d’attente)

• Voir l’exemple suivant :
• 5% de 64 -> (12,5 * 64) / 100 = 8.

Le DQLEN limité par hôte est calculé comme suit :

DQLEN de l’hôte = somme des DQLEN des machines virtuelles sur celui-ci

• Voir l’exemple suivant :
• VM-A (8) + VM-B (16) = 24 .

Le diagramme suivant montre l’effet de la limitation de la profondeur de file d’attente par SIOC :

Équilibrer l’utilisation du stockage à l’aide de Storage DRS (SDRS)

Le DRS de stockage est un mécanisme permettant d’équilibrer l’utilisation de l’espace et la charge d’E / S dans les banques de données d’un cluster de banques de données. L’équilibrage est obtenu en migrant les machines virtuelles entre les banques de données à l’aide de Storage vMotion.

Le DRS de stockage ne peut être activé que sur un cluster de banques de données.

Les banques de données (VMFS / NFS) peuvent être regroupées pour former un cluster de banques de données. Le DRS de stockage surveille l’utilisation de l’espace de la banque de données et les métriques SIOC pour redistribuer les fichiers VM entre les banques de données d’un cluster de banques de données. Il fournit également des recommandations de placement initial lors du déploiement de machines virtuelles dans le cluster de banques de données.

Dans cette recette, nous allons apprendre à créer un cluster de banques de données et à activer le DRS de stockage sur celui-ci.

Se préparer

Avant de commencer, il est essentiel de comprendre les exigences suivantes :

• Les banques de données d’un cluster de banques de données ne doivent être accessibles aux hôtes ESXi qu’à partir d’un seul centre de données (objet d’inventaire de centre de données vCenter).
• Un cluster de banques de données ne peut pas contenir à la fois des banques de données VMFS et NFS.

Pour les FAQ sur le DRS de stockage, consultez l’article 2149938 de la base de connaissances VMware à l’adresse https://kb.vmware.com/kb/2149938.

Comment faire

La procédure suivante vous aidera à créer un cluster de banques de données sur lequel SDRS est activé:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à l’inventaire de stockage.
2. Cliquez avec le bouton droit sur l’objet du centre de données et accédez à Stockage | Nouveau cluster de banques de données …:

Lancer l’assistant Nouveau cluster de banques de données.

1. Dans l’écran Nom et emplacement de l’assistant Nouveau cluster de banques de données, spécifiez un nom pour le cluster de banques de données, assurez-vous que Turn ON Storage DRS est sélectionné, puis cliquez sur Suivant pour continuer :
2. Sur l’écran Storage DRS Automation, configurez les niveaux d’automatisation souhaités. Il existe deux niveaux d’automatisation :

• Aucune automatisation (mode manuel)
• Entièrement automatisé (c’est le mode par défaut)

Vous pouvez également configurer l’espace, l’équilibre des E / S, l’application des règles d’affinité, l’application de la politique de stockage / VM et les niveaux d’automatisation d’évacuation des VM. Par défaut, tous ces paramètres héritent du niveau d’automatisation configuré sur le cluster :

1. Sur l’écran Storage DRS Runtime Settings, spécifiez si la métrique d’E / S est utilisée pour les recommandations SDRS. Le seuil par défaut est de 15 millisecondes. Spécifiez également le seuil d’utilisation de l’espace en fonction d’un centile d’utilisation (il s’agit de la méthode par défaut) ou d’une quantité minimale d’espace libre :
2. Sur l’écran Sélectionner les clusters et les hôtes, choisissez les hôtes souhaités et cliquez sur Suivant pour continuer :
3. Sur l’écran Sélectionner les banques de données, sélectionnez toutes les banques de données à inclure dans le cluster de banques de données et cliquez sur Suivant pour continuer :
4. Sur l’écran Prêt à terminer, passez en revue le résumé de la configuration du cluster et cliquez sur Terminer :
5. Le volet Tâches récentes doit afficher les tâches connexes terminées avec succès :

Ceci termine le processus d’activation de Storage DRS sur un cluster de banques de données.

Fonctionnement

Une fois que Storage DRS est activé, il s’exécute périodiquement toutes les 8 heures et génère des recommandations de migration de stockage en fonction de l’utilisation de l’espace et des seuils de latence. Il fonctionne en fonction des paramètres d’exécution configurés. Le paramètre d’exécution a déterminé s’il fallait ou non prendre en compte les mesures d’E / S lors de la génération de recommandations, la latence d’E / S et le seuil d’espace.

Lorsque vous déployez une machine virtuelle sur un cluster de banques de données avec SDRS activé, SDRS fournira des recommandations de placement en fonction de l’utilisation de l’espace et de la charge d’E / S sur les banques de données. Cela réduit la complexité de la prise de décision lorsque vous avez un grand nombre de banques de données dans l’environnement, et bien sûr, elles doivent faire partie d’un cluster de banques de données pour que cela fonctionne.

SDRS fournit des recommandations de placement et choisit l’une des banques de données recommandées. Cependant, l’utilisateur peut choisir de sélectionner un autre magasin de données recommandé. Bien que l’équilibrage de charge d’E / S puisse être désactivé, le SDRS aura toujours accès aux statistiques d’E / S des banques de données. Si SDRS trouve plusieurs banques de données appropriées pour placer la machine virtuelle, il choisira la banque de données avec la charge d’E / S la plus faible.

Sans Storage DRS, il est fort possible qu’au fil du temps, au fur et à mesure que vous déployez de plus en plus de machines virtuelles, vous finissiez par saturer l’espace libre sur un ensemble particulier de banques de données tout en laissant quelques autres banques de données sous-utilisées. Cela pourrait éventuellement entraîner des conditions d’espace insuffisant, affectant les machines virtuelles s’exécutant sur ces banques de données.

Lorsque Storage DRS est activé sur un cluster de banques de données, l’utilisation de l’espace sur les banques de données et le taux de croissance des VMDK (s’ils sont alloués de manière fine) sont surveillés. Le seuil par défaut pour l’utilisation de l’espace est de 80%. Storage DRS commencera à générer des recommandations Storage vMotion lorsque ce seuil sera dépassé. Cependant, ce faisant, il considère le centile de différence d’utilisation minimale de l’espace configuré dans les options avancées du cluster. La valeur par défaut est définie sur 5%, ce qui signifie que si la différence d’utilisation de l’espace entre deux bases de données ne dépasse pas 5%, SDRS ne générera pas de recommandations de migration pour déplacer les données de machine virtuelle entre ces deux banques de données.

La charge d’E / S sur une banque de données est mesurée en fonction de la latence d’E / S actuelle, telle que vue par les machines virtuelles s’exécutant sur la banque de données donnée. Le seuil par défaut pour la latence est de 15 millisecondes (15 000 microsecondes). Si l’équilibrage de charge d’E / S est activé, les statistiques de latence d’E / S sont évaluées toutes les huit heures. SDRS utilise 16 heures de données pour générer des recommandations Storage vMotion. Les migrations basées sur un déséquilibre de charge d’E / S ne se produisent qu’une fois par jour.

Par défaut, lors de la génération de recommandations SDRS, les disques virtuels correspondant à une machine virtuelle sont toujours conservés ensemble.

Voici quelques-unes des options avancées configurables, modifiées en modifiant les paramètres du cluster de banques de données :

Étant donné que toutes les options avancées sont explicites, nous ne les discuterons pas séparément dans cette recette.

Définition des capacités de stockage à l’aide de balises vCenter

La gestion basée sur les politiques de stockage (SPBM) aide un administrateur vSphere à créer des politiques de stockage VM pour permettre la sélection de banques de données en fonction de leurs caractéristiques de stockage, qui sont définies par l’utilisateur ou apprises à l’aide d’un fournisseur VASA.

Si vous disposez d’une baie compatible VASA, vous pouvez ajouter un fournisseur VASA à vCenter Server afin qu’il puisse générer des capacités de baie pour chaque LUN ou magasin de données. Une capacité générée par le fournisseur est appelée capacité de stockage système.

Reportez-vous à la documentation du fournisseur de stockage pour obtenir des instructions sur la configuration de vCenter pour se connecter au fournisseur VASA.

Étant donné que la configuration d’un fournisseur VASA dépasse le cadre de ce livre, nous nous concentrerons sur la définition des capacités de stockage à l’aide de balises vCenter.

Comment le faire

La procédure suivante vous aidera à définir les capacités de stockage à l’aide de balises vCenter:

1. Connectez-vous à vCenter Server à l’aide du client HTML5 et accédez à Menu | Tags Attributs personnalisés :

Nous allons créer quatre balises, Gold, Silver, Bronze et Local Storage, puis les associer aux banques de données.

1. Sur la page Tags & Attributs client, allez dans Catégories et cliquez sur + pour créer une catégorie :
2. Utilisez la fenêtre Ajouter une catégorie pour créer une catégorie de niveaux de stockage, avec des balises par objet définies sur une balise, et autorisez les associations avec les banques de données et les clusters de banques de données :
3. Sur la page Tags & Attributs client, accédez à Tags et cliquez sur + pour créer des tags :
4. Dans la fenêtre Ajouter une balise, spécifiez un nom, une description et une catégorie pour la nouvelle balise. Chaque balise doit être associée à une catégorie. Par conséquent, si aucune catégorie souhaitée n’est disponible, une nouvelle catégorie doit être créée à l’aide des étapes 2 et 3 :
5. Utilisez l’étape 5 pour créer des balises supplémentaires si nécessaire. Dans ce cas, nous allons créer des balises Gold Tier, Silver Tier et Bronze Tier :

Maintenant que nous avons créé nos balises, nous les associons à un cluster de banque de données / banque de données :

1. Cliquez avec le bouton droit sur un magasin de données / cluster de magasins de données et accédez à Tags et attributs personnalisés | Attribuer une balise … :
2. Sélectionnez une balise dans la fenêtre Attribuer une balise à associer au magasin de données / cluster de magasins de données :

Ceci termine le processus de définition des capacités de stockage à l’aide de balises vCenter et de les associer aux banques de données.

Comment ça marche

Alors que nos centres de données virtuels continuent d’héberger diverses charges de travail de VM, il devient important de séparer, isoler et allouer des ressources de stockage pour optimiser les performances et la fiabilité. Pour ce faire, les VM doivent être placées sur les banques de données avec les caractéristiques pertinentes pour aider au fonctionnement optimal de ces charges de travail. Malheureusement, la plupart des administrateurs VMware n’auraient pas nécessairement une visibilité des caractéristiques de stockage sous-jacentes, principalement parce que, dans la plupart des organisations, une équipe différente gère le stockage. Un administrateur VMware demande généralement un LUN d’une taille particulière, puis l’administrateur du stockage découpe un LUN à partir d’un pool de stockage disponible et le présente à l’hôte ESXi. Cela signifierait que l’administrateur ne pourrait répartir les charges de travail sur plusieurs banques de données qu’en fonction de l’utilisation de l’espace.

Alors, comment l’administrateur peut-il contourner ce problème ? Il existe trois façons :

• Utilisez une feuille de calcul ou toute autre méthode de conservation des enregistrements pour conserver une liste de tous les LUN présentés aux hôtes ESXi et leurs caractéristiques de stockage. Les informations sur les caractéristiques de stockage doivent être collectées auprès de l’équipe de stockage.
• Si la baie est capable de VMware VASA, un fournisseur VASA du fournisseur de stockage peut être déployé et configuré pour extraire les caractéristiques de stockage.
• Si VASA n’est pas configuré, nous pourrions utiliser le mécanisme de balisage de vCenter pour créer et associer des balises aux banques de données. Les balises sont définies par l’utilisateur et peuvent avoir n’importe quel nom et catégorie. Les balises peuvent ensuite être incluses dans une politique de stockage pour faciliter le placement des VM sur celles-ci.

Création de stratégies de stockage VM

Les politiques de stockage VM permettront à un administrateur de regrouper les banques de données sous des politiques basées sur la capacité de la banque de données. Ces capacités peuvent être liées à des caractéristiques de capacité, de performances ou de redondance. Les capacités peuvent être apprises via VASA si la baie de stockage prend en charge l’API, ou via des balises de capacité définies par l’utilisateur.

Par exemple, si vous avez classé votre stockage en différents niveaux en fonction de leurs caractéristiques de performances, vous pouvez créer des politiques de stockage de machine virtuelle pour faciliter la prise de décision lors de la création ou de la migration de machines virtuelles.

Dans cette recette, nous allons apprendre à créer des politiques de stockage de machine virtuelle à l’aide des capacités de stockage basées sur des balises vCenter définies par l’utilisateur.

Se préparer

Avant de commencer, vous aurez besoin de capacités de stockage ; soit défini par l’utilisateur à l’aide de balises vCenter, soit appris via un fournisseur VASA. De plus, plus important encore, l’utilisation de profils de stockage nécessite la licence vSphere Enterprise Plus.

Comment le faire

La procédure suivante vous aidera à créer des stratégies de stockage de machine virtuelle :

1. Connectez-vous à vCenter Server à l’aide du client HTML5.
2. Accédez à l’inventaire des raccourcis et cliquez sur Stratégies de stockage VM :
3. Sur la page Stratégies de stockage VM, cliquez sur Créer une stratégie de stockage VM:
4. Dans l’écran Créer une stratégie de stockage VM, sélectionnez le serveur vCenter sur lequel la stratégie est créée et fournissez un nom et une description facultative pour la stratégie:
5. Sur l’écran Structure de stratégie, sélectionnez Activer les règles de placement basées sur des balises et cliquez sur Suivant pour continuer :
6. Dans l’écran de placement basé sur les onglets, procédez comme suit :

• Sélectionnez la catégorie d’étiquette souhaitée.
• Définissez l’option Utilisation sur Utiliser le stockage marqué avec.
• Parcourez et sélectionnez la balise souhaitée :

1. L’écran de compatibilité de stockage doit maintenant répertorier tous les clusters de banques de données / magasins de données compatibles avec les balises. Cliquer sur Suivant pour continuer :
2. Sur l’écran Revoir et terminer, passez en revue le résumé et cliquez sur Terminer :

Ceci termine le processus de création de stratégies de stockage de machine virtuelle.

Comment ça marche

Une fois que les stratégies de stockage de VM sont attribuées à une VM et à ses VMDK, son état de conformité de profil restera non conforme à moins qu’il ne soit déplacé vers une banque de données correspondant à la stratégie de stockage de VM. La machine virtuelle peut être déplacée à l’aide de l’assistant de migration. Dans l’assistant de migration, la stratégie de stockage de machine virtuelle prévue peut être sélectionnée pour répertorier les banques de données conformes afin que la machine virtuelle et ses fichiers puissent être déplacés vers l’un d’eux.

Une fois créées, les politiques de stockage des machines virtuelles peuvent également être utilisées pour filtrer et choisir la banque de données souhaitée lors de divers scénarios de placement VMDK. Par exemple, si vous deviez créer une nouvelle machine virtuelle, vous pouvez choisir de placer ses VMDK sur une banque de données qui correspond à la politique de stockage de la machine virtuelle. La capture d’écran suivante montre la liste des banques de données en cours de filtrage en fonction de la stratégie de stockage VMware sélectionnée :

Les politiques de stockage des machines virtuelles peuvent également être appliquées aux machines virtuelles existantes et corrigées pour la conformité.

Avec les politiques de stockage VM, chaque caractéristique de stockage aura un impact sur les performances ou la fiabilité qu’un LUN peut offrir. Avant d’aller plus loin, il est important de savoir quelles pourraient être certaines de ces caractéristiques de stockage et quel rôle elles jouent dans la prise de décision concernant le placement des machines virtuelles. Voici une liste commune des caractéristiques de stockage et de leur impact sur les performances et la fiabilité :

Characteristics	Performance	Reliability
RAID level	Yes	Yes
Underlying disk technology	Yes	Yes
Spindle speed	Yes	No
Capacity	No	No
Storage tiers	Yes	Yes

En termes vSphere, ces caractéristiques sont appelées capacités de stockage, qui peuvent être apprises par le système (via VASA) ou définies par l’utilisateur. Qu’elles soient apprises ou définies, il doit exister un moyen d’associer les machines virtuelles aux banques de données qui ont la capacité souhaitée. Une telle association est créée à l’aide de stratégies de stockage VM. Une fois les stratégies définies, les disques VM peuvent ensuite être associés à ces stratégies. Cela permettra à vSphere de prendre des décisions de placement de VM.