¶ Importance
Les fonctionnalités d’évolutivité et les configurations de stockage défini par logiciel dans vSphere peuvent vous aider à gérer efficacement la croissance dans votre environnement.
Pour la croissance des datastores et les problèmes d’équilibrage, vous pouvez utiliser vSphere Storage DRS.
Avec les connaissances et les compétences en gestion basée sur les stratégies de stockage, vous pouvez aligner le stockage sur les exigences applicatives de vos VMs.
¶ Leçons du module
- Systèmes de stockage NVMe
- Extension iSCSI pour RDMA (iSER)
- Datastores VMFS
- Datastores vSAN
- vSphere Storage APIs – Array Integration (VAAI)
- vSphere Storage API for Storage Awareness et vSphere APIs for I/O Filtering (VASA et VAIO)
- Vue d’ensemble de la gestion basée sur les stratégies de stockage
- Utilisation des stratégies de stockage de VM
- Stratégies de stockage pour vSAN
- Stratégies de stockage pour vSphere Virtual Volumes
- Storage I/O Control
- Datastore Clusters et vSphere Storage DRS
¶ Leçon 1 : Systèmes de stockage NVMe
¶ Objectifs d’apprentissage
- Identifier la prise en charge du NVMe
- Configurer ESXi pour NVMe over RDMA (RoCE v2)
- Décrire l’architecture VMware Pluggable Storage Architecture (PSA)
- Décrire le but du High-Performance Plug-in (HPP)
¶ Prise en charge de vSphere pour NVMe
Non-Volatile Memory Express (NVMe) est un protocole standardisé pour la communication multi-queue haute performance avec des périphériques NVM.
ESXi prend en charge le protocole NVMe pour se connecter à des périphériques de stockage locaux et en réseau.
Introduit dans vSphere 7, les fonctionnalités suivantes ont été ajoutées pour améliorer la prise en charge du NVMe :
- Pluggable Storage Architecture (PSA) utilisant un High-Performance Plug-In (HPP) avec multipathing
- Ajout et retrait à chaud de périphériques NVM locaux, si le serveur le prend en charge
- Prise en charge des périphériques NVMe en réseau connectés via Fibre Channel ou RDMA
ESXi utilise la Pluggable Storage Architecture (PSA) comme couche VMkernel pour la gestion du multipathing du stockage.
La PSA est une structure ouverte et modulaire. Elle coordonne les modules logiciels responsables des opérations de multipathing.
Les modules incluent des multipathing modules (MPPs) génériques fournis par VMware, tels que le Native Multipathing Plug-In (NMP) et le High Performance Plug-In (HPP), ainsi que des MPPs tiers.
¶ Topologies NVMe prises en charge
Le stockage NVMe peut être directement connecté à un hôte ou indirectement via différents fabric transports, ce qui est connu sous le nom de Shared NVMe over Fabrics, ou simplement NVMe-oF.
| NVMe Transport | Prise en charge à partir de ESXi 7 et versions ultérieures |
|---|---|
| NVMe over PCIe | Stockage local |
| NVMe over RDMA | Stockage partagé NVMe-oF |
| NVMe over Fibre Channel (FC-NVMe) | Stockage partagé NVMe-oF |
| NVMe over TCP | Stockage partagé NVMe-oF |
¶ FC-NVMe et NVMe over RDMA (RoCE v2)
vSphere 7 et les versions ultérieures prennent en charge l’accès à distance au NVMe-oF.
Cela inclut à la fois les topologies "FC-NVMe et NVMe over RDMA".
¶ Prise en charge du FC-NVMe
FC-NVMe est une technologie qui permet de mapper le protocole NVMe sur le protocole Fibre Channel.
Avec FC-NVMe, les données et les commandes peuvent être transférées entre un ordinateur hôte et un périphérique de stockage cible.
Pour accéder au stockage FC-NVMe, vous devez installer un adaptateur de stockage Fibre Channel compatible NVMe sur votre hôte ESXi.
Vous n’avez pas besoin de configurer le contrôleur. Une fois l’adaptateur matériel NVMe requis installé, il se connecte automatiquement à toutes les cibles (targets) et contrôleurs accessibles.
Votre hôte ESXi détecte le périphérique et l’affiche dans le vSphere Client comme un adaptateur Fibre Channel (vmhba) standard, avec le protocole de stockage indiqué comme NVMe.
Vous n’avez pas besoin de configurer le contrôleur.
Une fois que vous avez installé l’adaptateur matériel NVMe requis, il se connecte automatiquement à toutes les cibles et contrôleurs qu’il peut atteindre.
Vous pouvez ensuite reconfigurer l’adaptateur et déconnecter ses contrôleurs, ou connecter d’autres contrôleurs qui n’étaient pas disponibles lors du démarrage de l’hôte.
¶ Exigences pour FC-NVMe
Lorsque vous utilisez FC-NVMe, les composants suivants sont requis :
- Une baie de stockage Fibre Channel prenant en charge NVMe.
- Un contrôleur NVMe sur votre baie de stockage.
- ESXi 7 ou version ultérieure.
- Un adaptateur matériel NVMe sur votre hôte ESXi : cet adaptateur est généralement un adaptateur Fibre Channel Host Bus Adapter (HBA) prenant en charge NVMe.
Valeurs maximales de configuration pour NVMe-oF :
- 256 namespaces
- 2048 paths
- 4 paths par namespace et par hôte
Pour plus d’informations sur les concepts NVMe, consultez le chapitre intitulé About VMware NVMe Storage dans la documentation vSphere Storage, disponible à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-storage-guide.pdf
¶ Prise en charge de NVMe over RDMA (RoCE v2)
La technologie NVMe over RDMA (RoCE v2) utilise RDMA pour le transport entre deux systèmes sur le réseau.
L’échange de données s’effectue directement en mémoire principale, contournant le système d’exploitation et le processeur des deux systèmes.
ESXi 7 et les versions ultérieures prennent en charge la technologie RoCE v2, qui permet le RDMA sur un réseau Ethernet.
Pour accéder au stockage, l’hôte ESXi utilise un adaptateur réseau RDMA installé sur l’hôte ainsi qu’un adaptateur de stockage NVMe over RDMA logiciel.
Le NVMe over RDMA avec la technologie RoCE v2 offre un stockage ultra-efficace permettant d’optimiser les charges de travail sensibles aux performances sur votre infrastructure Ethernet existante.
Vous devez configurer les deux adaptateurs pour pouvoir effectuer la détection du stockage.
Le processus de configuration des adaptateurs consiste à configurer la liaison VMkernel pour un adaptateur réseau RDMA et activer un adaptateur NVMe over RDMA logiciel.
¶ Exigences pour NVMe over RDMA (RoCE v2)
Le NVMe over RDMA (RoCE v2) nécessite les composants suivants :
- Une baie de stockage NVMe prenant en charge le transport NVMe over RDMA (RoCE v2)
- Un contrôleur NVMe sur votre baie de stockage
- ESXi 7 ou version ultérieure
- Des Switches Ethernet prenant en charge un réseau sans perte (lossless network)
- Un adaptateur réseau sur votre hôte ESXi prenant en charge RoCE v2
- Un adaptateur NVMe over RDMA logiciel activé sur vos hôtes ESXi
Valeurs maximales de configuration pour NVMe-oF :
- 32 namespaces
- 128 chemins (paths)
- 4 chemins par namespace et par hôte
¶ Configuration d’ESXi pour NVMe over RDMA (RoCE v2)
Pour configurer votre hôte ESXi afin d’utiliser NVMe over RDMA (RoCE v2) :
- Sur votre hôte ESXi, installez une interface réseau prenant en charge RDMA (RoCE v2).
- Dans le vSphere Client, vérifiez que l’adaptateur RDMA est détecté par votre hôte.
- Configurez la liaison VMkernel pour l’adaptateur RDMA.
- Vérifiez la configuration de la liaison VMkernel pour l’adaptateur RDMA.
- Activez l’adaptateur NVMe over RDMA logiciel.
- Découvrez les contrôleurs NVMe sur votre baie (automatiquement ou manuellement).
- Analysez à nouveau le stockage (rescan storage) pour découvrir les namespaces NVMe.
- Créez vos datastores.
Identifiez l’adaptateur réseau physique qui correspond à l’adaptateur RDMA.
La configuration du Port binding pour NVMe over RDMA consiste à créer un Switch et à connecter l’adaptateur réseau physique et l’adaptateur VMkernel à ce Switch.
Grâce à cette connexion, l’adaptateur RDMA devient lié à l’adaptateur VMkernel.
Sélectionnez Add software NVMe over RDMA adapter et choisissez un adaptateur RDMA approprié (vmrdma) dans le menu déroulant.
L’adaptateur software NVMe over RDMA apparaît alors dans la liste en tant qu’adaptateur de stockage vmhba.
Vous pouvez supprimer cet adaptateur si vous devez libérer l’adaptateur réseau RDMA sous-jacent pour d’autres usages.
Pour plus d’informations sur la configuration des adaptateurs pour NVMe over RDMA (RoCE v2), consultez la documentation VMware : Configuring Adapters for NVMe over RDMA (RoCE v2) Storage
¶ Architecture de stockage enfichable (Pluggable Storage Architecture)
La Pluggable Storage Architecture (PSA) est un cadre ouvert et modulaire qui coordonne divers modules logiciels responsables des opérations de multipathing.
| Acronyme | Définition |
|---|---|
| PSA | Pluggable Storage Architecture |
| NMP | Native Multipathing Plug-in : Module de multipathing VMware générique utilisé avec les périphériques de stockage SCSI |
| PSP | Path Selection Plug-in : Gère la sélection de chemin pour un périphérique de stockage SCSI |
| SATP | Storage Array Type Plug-in : Gère le basculement de chemin pour une baie de stockage SCSI donnée |
| Acronyme | Définition |
|---|---|
| MPP (third party) | Multipathing Plug-in : Module de multipathing développé et fourni par un tiers |
| HPP | High-Performance Plug-in fourni par VMware : Utilisé avec les périphériques flash locaux et en réseau à très haute vitesse |
| PSS | Path Selection Scheme : Gère le multipathing pour les périphériques de stockage NVMe |
VMware fournit des modules de multipathing natifs génériques, appelés VMware NMP et VMware HPP.
De plus, la PSA offre un ensemble d’API VMkernel que les développeurs tiers peuvent utiliser.
Les développeurs de logiciels peuvent créer leurs propres modules d’équilibrage de charge et de basculement pour une baie de stockage spécifique. Ces modules de multipathing tiers (MPP) peuvent être installés sur l’hôte ESXi et fonctionner en plus des modules VMware natifs, ou les remplacer.
Comme le montre le schéma de la diapositive précédente, plusieurs MPP tiers peuvent s’exécuter en parallèle avec les modules VMware NMP ou HPP.
Une fois installés, les MPP tiers peuvent remplacer le comportement des modules natifs. Les MPP peuvent prendre le contrôle du basculement de chemin et des opérations d’équilibrage de charge pour les périphériques de stockage spécifiés.
¶ Plug-in haute performance (HPP) pour NVMe
Le HPP (High-Performance Plug-in) assure les fonctions suivantes :
- Sert de plug-in par défaut qui revendique les cibles NVMe-oF.
- Prend en charge uniquement les cibles ALUA (Asymmetric Logical Unit Access) actives-actives et implicites.
- Améliore les performances des périphériques flash ultra-rapides installés sur ESXi.
- Peut remplacer le Native Multipathing Plug-in (NMP) pour les périphériques NVMe locaux.
- Prend en charge le multipathing pour NVMe-oF.
Pour prendre en charge le multipathing, le HPP utilise un schéma de sélection de chemin (PSS – Path Selection Scheme) lors de la sélection des chemins physiques pour les requêtes d’E/S.
Vous pouvez utiliser vSphere ESXi Shell ou la vSphere CLI (avant vSphere 7.0) pour configurer le HPP et le PSS.
À partir de vSphere 7 et versions ultérieures, le HPP intègre la logique de sélection et de basculement de chemin dans un seul module, ce qui réduit les appels inter-modules.
Pour les périphériques NVMe locaux, NMP reste le plug-in par défaut, mais il est possible de le remplacer par le HPP.
¶ Prise en charge du multipathing avec le Plug-in haute performance (HPP)
Le HPP (High-Performance Plug-in) améliore les performances des périphériques NVMe sur votre hôte ESXi.
| Prise en charge HPP | vSphere 7 et versions ultérieures |
|---|---|
| Périphériques de stockage | NVMe PCIe local NVMe-oF partagé (uniquement pour les cibles actives-actives et les cibles ALUA implicites) |
| Multipathing | Oui |
| Plug-ins de second niveau | Non Schéma de sélection de chemin (PSS – Path Selection Scheme) |
| Réservations persistantes SCSI-3 | Non |
| Périphériques 4Kn avec émulation logicielle | Non |
| vSAN | Oui |
¶ Bonnes pratiques pour le Plug-in haute performance (HPP)
Pour obtenir le débit le plus rapide à partir d’un périphérique de stockage haute vitesse, suivez les recommandations suivantes :
- Utilisez le HPP pour les périphériques NVMe locaux ou en réseau.
- N’activez pas le HPP pour les disques durs (HDD) ou les périphériques flash plus lents.
- Lors de l’utilisation de FC-NVMe, suivez les recommandations générales pour le stockage Fibre Channel.
- Lors de l’utilisation de NVMe-oF, ne mélangez pas les types de transport pour accéder au même namespace.
- Avant d’enregistrer les namespaces NVMe-oF, assurez-vous que les chemins actifs sont présentés à l’hôte.
- Configurez vos machines virtuelles (VM) pour utiliser les contrôleurs paravirtuels VMware (PVSCSI).
- Configurez vos VMs pour utiliser la sensibilité haute latence.
- Si une seule VM gère une part importante de la charge d’E/S du périphérique, envisagez de répartir les opérations d’E/S sur plusieurs disques virtuels, en attachant ces disques à des contrôleurs virtuels distincts dans la VM.
N’activez pas le HPP pour les disques durs ou les périphériques flash plus lents. Le HPP n’apporte aucun avantage de performance pour des périphériques incapables d’atteindre au moins 200 000 IOPS.
Si vous n’attachez pas les disques à des contrôleurs virtuels séparés dans la VM, le débit d’E/S peut être limité. Cette limitation est due à la saturation du cœur CPU chargé de traiter les opérations d’E/S sur un contrôleur de stockage virtuel.
¶ Revue des objectifs d’apprentissage
- Identifier la prise en charge du NVMe
- Configurer ESXi pour NVMe over RDMA (RoCE v2)
- Décrire l’architecture de stockage enfichable (Pluggable Storage Architecture) de VMware
- Décrire le rôle du Plug-in haute performance (HPP)
¶ Leçon 2 : Extension iSCSI pour RDMA (iSER)
¶ Objectifs d'apprentissage
- Décrire la prise en charge d’iSER dans vSphere
- Configurer iSER sur les hôtes ESXi
¶ À propos d’iSER
Les extensions iSCSI pour RDMA (iSER) offrent une connectivité iSCSI hautes performances pour les cartes réseau RDMA standard.
En plus de la prise en charge de l’iSCSI traditionnel, ESXi prend également en charge le protocole iSER.
Lorsque le protocole iSER est activé, le framework iSCSI sur l’hôte ESXi peut utiliser le transport RDMA au lieu de TCP/IP.
vSphere 7.0 a ajouté la prise en charge des volumes virtuels vSphere (vVols) via iSER.
À partir de vSphere 7 et versions ultérieures, la prise en charge d’iSER nécessite les éléments suivants :
- Des périphériques compatibles RoCE
- Une baie de stockage cible prenant en charge iSER sur RoCE
¶ Configuration d’iSER**
Configurez iSER sur votre hôte ESXi afin que le framework iSCSI sur l’hôte puisse utiliser le transport Remote Direct Memory Access (RDMA) à la place de TCP/IP.
| Étape de configuration | Description |
|---|---|
| Activer l’adaptateur VMware iSER. | Utilisez la commande esxcli pour activer l’adaptateur VMware iSER. |
| Modifier les propriétés générales des adaptateurs iSCSI ou iSER. | Si nécessaire, modifiez le nom par défaut et l’alias attribué à votre adaptateur. |
| Configurer la liaison de port pour iSCSI ou iSER. | Vous devez créer des connexions réseau pour lier le moteur iSER et l’adaptateur réseau compatible RDMA. |
| Configurer la découverte dynamique ou statique pour iSCSI et iSER. | En mode de découverte dynamique, chaque fois que l’initiateur contacte un système de stockage iSER spécifié, il envoie une requête SendTargets au système. En mode statique, vous devez entrer manuellement les informations des cibles. |
| Configurer CHAP pour iSCSI ou iSER. | Cette étape est nécessaire uniquement si votre environnement utilise le protocole CHAP (Challenge Handshake Authentication Protocol). |
| Activer les trames jumbo pour la mise en réseau. | Si votre environnement prend en charge les trames jumbo, activez-les pour l’adaptateur. |
Lorsqu’il est installé sur l’hôte, l’adaptateur compatible RDMA apparaît dans vCenter Server comme un adaptateur réseau (vmnic).
Pour rendre l’adaptateur fonctionnel, vous devez activer le composant VMware iSER et connecter l’adaptateur iSER au vmnic compatible RDMA. Vous pouvez ensuite configurer des propriétés telles que les cibles et CHAP pour l’adaptateur iSER.
Remarque : iSER ne prend pas en charge le NIC teaming. Lors de la configuration de la liaison de port, utilisez un seul adaptateur RDMA par commutateur virtuel.
¶ Exigences pour iSER
Pour activer l’adaptateur VMware iSER, utilisez la commande esxcli et assurez-vous de répondre aux exigences suivantes :
- Vérifiez que votre stockage iSCSI prend en charge le protocole iSER.
- Installez l’adaptateur compatible RDMA sur votre hôte ESXi.
- Utilisez le commutateur compatible RDMA.
- Activez le contrôle de flux sur l’hôte ESXi. Pour activer le contrôle de flux sur l’hôte, utilisez la commande :
esxcli system module parameters - Configurez les ports du commutateur RDMA pour créer des connexions sans perte entre l’initiateur iSER et la cible.
Pour plus d’informations sur l’activation du contrôle de flux, consultez l’article 1013413 de la base de connaissances VMware à l’adresse : http://kb.vmware.com/kb/1013413
¶ Exécution d’iSER
Exécutez la commande suivante depuis l’hôte ESXi pour activer l’adaptateur iSER : esxcli rdma iser add
¶ Revue des objectifs d’apprentissage
- Décrire la prise en charge d’iSER dans vSphere
- Configurer iSER sur les hôtes ESXi
¶ Leçon 3 : Datastores VMFS
¶ Objectifs d'apprentissage
- Expliquer pourquoi VMFS est un système de fichiers haute performance et évolutif
- Identifier les améliorations de performance de VMFS6 par rapport à VMFS5
- Décrire la procédure de migration de VMFS5 vers VMFS6
¶ À propos des Datastores VMFS
Les datastores VMFS sont des conteneurs logiques qui masquent les spécificités du stockage physique des machines virtuelles et fournissent un modèle uniforme pour le stockage des fichiers de machines virtuelles.
VMFS est un système de fichiers en cluster haute performance, optimisé pour les machines virtuelles.
vSphere 6.5 et les versions ultérieures prennent en charge les datastores VMFS5 et VMFS6.
VMFS5 a été introduit dans vSphere 5.0. VMFS6 a été introduit dans vSphere 6.5.
¶ Datastores VMFS5 et VMFS6
Les datastores VMFS5 et VMFS6 sont hautement évolutifs :
- La taille maximale d’un datastore ou d’une seule étendue est de 64 To.
- La taille du bloc du système de fichiers est de 1 Mo, ce qui prend en charge des fichiers allant jusqu’à 62 To.
- Les petits fichiers sont stockés efficacement :
— Les blocs du système de fichiers sont divisés en sous-blocs pour un stockage optimal des petits fichiers.
— Les données des petits fichiers (inférieurs ou égaux à 1 Ko) sont stockées directement dans le descripteur de fichier. - Un disque virtuel peut être étendu à chaud à n’importe quelle taille, jusqu’à 62 To.
Pour plus d’informations sur la fonctionnalité d’extension à chaud, consultez vSphere Storage à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-storage-guide.pdf
¶ Datastores VMFS6
VMFS6 apporte des améliorations en termes d’évolutivité et de performance par rapport à VMFS5 :
- Les datastores VMFS6 (et NFS) peuvent être montés sur jusqu’à 128 hôtes ESXi.
- Temps de création de fichiers plus rapides.
- Opérations disque parallèles et transactions simultanées.
Un VMDK partagé sur VMFS6 prend en charge les réservations persistantes SCSI-3 (SCSI-3 PR) au niveau du disque virtuel (VMDK) :
- Un cluster de basculement Windows Server (WSFC) peut utiliser des disques partagés sur VMFS.
- Il peut prendre en charge des disques virtuels en cluster sur certains datastores (si le matériel le permet).
- Vous pouvez utiliser le vSphere Client pour migrer des RDMs vers VMFS.
Pour les RDMs en compatibilité virtuelle, vous pouvez effectuer une migration Storage vMotion.
Pour les RDMs en compatibilité physique vers des disques virtuels, un temps d’arrêt est nécessaire pour effectuer la migration.
¶ Formats des périphériques de stockage
ESXi prend en charge les périphériques de stockage utilisant des formats de secteur traditionnels et avancés :
- 512n : format de secteur traditionnel.
- 512e (émulation de 512 octets) : un disque 4K capable d’émuler des secteurs de 512 octets pour les applications et systèmes d’exploitation anciens.
- 4Kn (4K natif) : présente des secteurs de 4 Ko sans aucune émulation.
| Format de secteur | Taille de secteur logique | Taille de secteur physique |
|---|---|---|
| 512n | 512 | 512 |
| 512e | 512 | 4 096 |
| 4Kn | 4 096 | 4 096 |
L’industrie du stockage évolue vers des disques à format avancé afin de fournir des disques de grande capacité pour les serveurs et baies de stockage.
Les disques 4K offrent plusieurs avantages par rapport aux disques à secteurs de 512 octets :
- Réduction du coût total de possession (TCO) : les disques 4K nécessitent moins d’espace pour les codes de correction d’erreurs (ECC) que les disques 512 octets classiques. Cet espace libéré permet une densité de données plus élevée sur les disques 4K, ce qui améliore le coût total de possession.
- Meilleure disponibilité : les disques 4K disposent d’un champ ECC plus grand, améliorant ainsi la correction d’erreurs et l’intégrité des données.
- Meilleures performances : les disques 4K devraient offrir de meilleures performances que les disques 512 octets. Toutefois, cette amélioration n’est réelle que si le système d’exploitation invité est configuré pour exécuter des opérations d’E/S alignées sur la taille de secteur 4K.
Comme les applications et systèmes d’exploitation anciens ne prennent pas en charge les disques 4K natifs, l’industrie a introduit les disques 4K avec taille de secteur émulée en 512 octets pour garantir la compatibilité.
Ces disques ont une taille de secteur physique de 4 Ko, mais une taille logique de 512 octets.
Ces disques sont appelés disques 512e, où la lettre e signifie émulation.
Les disques 512e facilitent l’adoption des disques 4K.
L’objectif final de l’industrie est de migrer entièrement vers des disques 4K natifs (4Kn).
¶ Périphériques de stockage pris en charge par les datastores VMFS
Vous pouvez déployer des datastores VMFS5 et VMFS6 sur des périphériques de stockage 512n et 512e.
Avec vSphere 6.7 et les versions ultérieures, les datastores VMFS6 peuvent également être déployés sur des périphériques de stockage 4Kn connectés directement.
ESXi continue d’exposer des fichiers de disque virtuel avec des secteurs de 512 octets au système d’exploitation invité.
| Périphérique de stockage | Pris en charge par VMFS5 | Pris en charge par VMFS6 |
|---|---|---|
| 512n | Oui | Oui |
| 512e | Oui. Cependant, VMFS5 n’est pas pris en charge sur les périphériques 512e locaux. | Oui |
| 4Kn | Non | Oui |
Pour plus d’informations sur la compatibilité de vSphere avec les disques 512e et 4K natifs, consultez l’article de la base de connaissances VMware 2091600 à l’adresse : http://kb.vmware.com/kb/2091600
¶ Limitations liées à l’utilisation de disques 4Kn
Lorsqu’ils sont utilisés dans un environnement vSphere, les disques 4Kn présentent les limitations suivantes :
-
Seuls les disques durs locaux SAS et SATA sont pris en charge.
-
Les disques SSD 4Kn, NVMe 4Kn et les disques 4Kn utilisés en RDM ne sont pas pris en charge.
-
Le démarrage à partir de disques 4Kn n’est pris en charge qu’en mode UEFI.
-
Seul le Native Multipathing Plug-In (NMP) peut gérer les périphériques 4Kn :
- Le High-Performance Plug-In (HPP) ne peut pas être utilisé pour ces périphériques.
- Les plug-ins multipathing tiers ne sont pas pris en charge.
-
Pour vSAN, les disques 4Kn peuvent uniquement être utilisés comme disques durs de capacité (HDD) en mode hybride.
¶ Formats de Snapshot pour VMFS
Sur le datastore VMFS, le disque delta d’un Snapshot de machine virtuelle est un disque “sparse”.
Les disques delta utilisent différents formats “sparse” selon le type de datastore VMFS.
Le format SEsparse est similaire au VMFSsparse, avec certaines améliorations :
- SEsparse est plus efficace en termes d’espace et prend en charge la récupération d’espace.
- Ce format de disque est recommandé pour les environnements d’infrastructure de bureau virtuel (VDI).
| Format Sparse | Utilisé par VMFS5 | Utilisé par VMFS6 |
|---|---|---|
| VMFSsparse | Oui, pour les disques virtuels de moins de 2 To. | Non. |
| SEsparse (sparse efficace en espace) | Oui, pour les disques virtuels égaux ou supérieurs à 2 To. | Oui, c’est le format par défaut. |
Lorsque vous prenez un Snapshot, l’état du disque virtuel est préservé, empêchant le système d’exploitation invité d’écrire sur le disque.
Un disque delta ou un disque enfant est créé. Le disque delta représente la différence entre l’état actuel du disque virtuel et l’état qui existait lors de la prise du précédent Snapshot.
VMFSsparse est implémenté au-dessus de VMFS.
La couche VMFSsparse traite les opérations d’E/S émises vers un Snapshot de VM.
Techniquement, VMFSsparse est un journal de reprise (redo-log) qui commence vide immédiatement après la prise d’un Snapshot de VM.
Le redo-log s’agrandit jusqu’à la taille de son disque virtuel de base (VMDK) lorsque l’ensemble du VMDK est réécrit avec de nouvelles données après la prise du Snapshot.
Ce redo-log n’est qu’un fichier dans le datastore VMFS.
Après la prise du Snapshot, le VMDK de base attaché à la VM est remplacé par le nouveau VMDK “sparse” créé.
Avec SEsparse, la récupération d’espace permet de marquer les blocs supprimés par le système d’exploitation invité, et des commandes sont envoyées à la couche SEsparse dans l’hyperviseur pour “démapper” ces blocs.
Cette opération aide à récupérer l’espace alloué par SEsparse après la suppression des données par le système invité.
SEsparse est le format de disque recommandé pour les environnements VMware Horizon.
Dans ces environnements, la récupération de l’espace de stockage est essentielle en raison du grand nombre de locataires partageant la même infrastructure.
¶ Migration de vos données de VMFS5 vers VMFS6
En raison des changements dans les structures de métadonnées de VMFS6, vous ne pouvez pas effectuer de mise à niveau directe de VMFS5 vers VMFS6.
Un datastore VMFS6 ne peut être créé qu’en tant que nouveau datastore.
Utilisez vSphere Storage vMotion pour migrer les données de votre datastore VMFS5 vers un datastore VMFS6.
Pour plus d’informations, consultez cet article de la base de connaissances VMware : kb2147824
¶ QCM : Fonctionnalités de VMFS6
Quelles fonctionnalités de scalabilité et de performance sont disponibles uniquement avec les datastores VMFS6 ?
Sélectionnez toutes les réponses qui s’appliquent.
☐ Prise en charge des disques 4Kn
☐ Temps de création de fichiers plus rapides
☐ SEsparse comme format de snapshot
☐ Taille maximale du datastore : 64 To
☐ Extension à chaud d’un disque virtuel jusqu’à 62 To
☐ Opérations de disque parallèles et transactions concurrentes
¶ Réponses : Fonctionnalités de VMFS6
Quelles fonctionnalités de scalabilité et de performance sont disponibles uniquement avec les datastores VMFS6 ?
✓ Prise en charge des disques 4Kn
✓ Temps de création de fichiers plus rapides
☐ SEsparse comme format de snapshot
☐ Taille maximale du datastore : 64 To
☐ Extension à chaud d’un disque virtuel jusqu’à 62 To
✓ Opérations de disque parallèles et transactions concurrentes
¶ Revue des objectifs d’apprentissage
- Expliquer pourquoi VMFS est un système de fichiers évolutif et à hautes performances.
- Identifier les améliorations de performance de VMFS6 par rapport à VMFS5.
- Décrire la procédure de migration de VMFS5 vers VMFS6.
¶ Leçon 4 : Datastores vSAN
¶ Objectifs d’apprentissage
- Expliquer le but d’un datastore vSAN
- Décrire l’architecture et les exigences de la configuration vSAN
- Expliquer le but des stratégies de stockage vSAN
- Décrire le but des domaines de panne
¶ Architecture de stockage vSAN
Introduite dans vSAN 8, vSAN Express Storage Architecture (ESA) est une nouvelle architecture de stockage optionnelle sur la plateforme vSAN qui permet d’atteindre de nouveaux niveaux de performance, de scalabilité, de résilience et de simplicité.
¶ vSAN Original Storage Architecture (OSA)
- Cache et périphériques de capacité dédiés
- Prend en charge les anciens périphériques de stockage variés
- Utilise des groupes de disques pour offrir des performances via la mise en cache et la capacité
¶ vSAN Express Storage Architecture (ESA)
- Architecture flexible utilisant un niveau unique dans vSAN 8
- Optimisée pour les périphériques flash NVMe hautes performances
- Aucun groupe de disques — tous les périphériques contribuent aux performances et à la capacité
¶ À propos des datastores vSAN
vSAN est une solution de stockage définie par logiciel qui fournit un stockage partagé pour les clusters vSphere sans utiliser de stockage externe traditionnel.
Un cluster vSAN nécessite :
- Un minimum de trois hôtes faisant partie du cluster vSphere et configurés pour vSAN
- Un réseau vSAN
- Des périphériques de stockage locaux sur chaque hôte, regroupés pour créer un datastore vSAN partagé virtuel
Les datastores vSAN aident les administrateurs à utiliser le stockage défini par logiciel de la manière suivante :
- Stratégie de stockage par machine virtuelle (VM) : avec plusieurs stratégies par datastore, chaque VM peut avoir ses propres capacités de stockage uniques.
- Intégration avec vSphere et vCenter Server : la fonctionnalité vSAN est intégrée et ne nécessite aucun dispositif supplémentaire. Vous créez un cluster vSAN comme vous le feriez avec vSphere HA ou vSphere DRS.
- Stockage évolutif (scale-out) : jusqu’à 64 hôtes ESXi peuvent faire partie d’un cluster. L’extension se fait en ajoutant de nouveaux nœuds au cluster.
- Résilience intégrée : la stratégie de stockage par défaut de vSAN établit une redondance RAID 1 pour toutes les machines virtuelles (VM).
¶ Groupes de disques
Les groupes de disques sont des éléments de gestion vSAN présents sur tous les hôtes ESXi d’un cluster vSAN.
Un hôte peut inclure jusqu’à cinq groupes de disques au maximum.
Les groupes de disques sont combinés pour créer un seul datastore vSAN.
Un groupe de disques nécessite :
- Un périphérique flash pour la mise en cache
- Un à sept périphériques de capacité pour le stockage
vSAN utilise le concept de groupes de disques pour regrouper les périphériques de cache et de capacité au sein d’une même unité de gestion.
Un groupe de disques est un ensemble composé d’un périphérique de cache et de un à sept périphériques de capacité.
¶ Exigences matérielles de vSAN
Les fonctionnalités de vSAN sont natives à ESXi et ne nécessitent aucun logiciel supplémentaire.
vSAN nécessite plusieurs composants matériels que les hôtes n’ont généralement pas :
-
Un disque SCSI SAS, SSD SATA, ou SSD NVMe, et de un à sept disques magnétiques pour chaque groupe de disques hybride.
-
Un SAS ou SATA SSD, et de un à sept disques flash pour chaque groupe de disques tout-flash.
-
Un réseau dédié de 1 Gbps (10 Gbps recommandé) pour les groupes de disques hybrides.
-
Un réseau dédié de 10 Gbps pour les groupes de disques tout-flash.
Les vitesses de réseau de 1 Gbps entraînent une congestion préjudiciable pour les architectures tout-flash et ne sont pas prises en charge. -
Le réseau vSAN doit être configuré pour IPv4 ou IPv6.
De plus, chaque hôte doit disposer d’un minimum de 32 Go de mémoire afin de pouvoir prendre en charge un maximum de cinq groupes de disques et un maximum de sept périphériques de capacité par groupe de disques.
¶ Visualisation du résumé du vSAN Datastore
L’onglet Summary du vSAN datastore affiche les informations générales de configuration de vSAN.
¶ Objets dans les vSAN Datastores
Le stockage vSAN est basé sur les objets et guidé par les politiques.
Les machines virtuelles (VM) créées sur un vSAN datastore incluent les objets suivants :
- Un espace de noms principal de la VM (VM home namespace)
- Un ou plusieurs objets VMDK
- Un objet d’échange (swap) de VM en thin provisioning
- Un ou plusieurs objets de mémoire de VM
Autres objets vSAN :
- Objets de données de performance vSAN
- Objets LUN iSCSI
| Objet vSAN | Fichiers VM traditionnels |
|---|---|
| VM home namespace | .nvram, .vmsd, .vmx, vmx-*.vswp, .log, .hlog |
| VMDK | -flat.vmdk |
| VM swap | .vswp |
| VM memory | .vmem |
| Snapshot delta | -00000#-delta.vmdk, -00000#-sesparse.vmdk |
Un cluster vSAN stocke et gère les données sous forme de conteneurs flexibles appelés objets.
Lors de la création d’une VM sur un vSAN datastore, un ensemble d’objets est généré :
- VM home namespace : Stocke les métadonnées de la machine virtuelle (fichiers de configuration).
- VMDK : Disque de la machine virtuelle.
- VM swap : Fichier d’échange de la machine virtuelle, créé lorsque la VM est mise sous tension.
- VM memory : État mémoire de la machine virtuelle lorsque celle-ci est suspendue ou lorsqu’un snapshot est pris et que l’état mémoire est conservé.
- Snapshot delta : Créé lorsqu’un snapshot de machine virtuelle est pris.
¶ Politiques de stockage des VM
Les politiques de stockage définissent la manière dont les objets inclus dans une machine virtuelle (VM) sont stockés.
Les politiques de stockage présentent les caractéristiques suivantes :
- Basées sur les capacités de stockage
- Définies pour une VM ou un disque au moment du déploiement
- Peuvent être appliquées ultérieurement
- Peuvent être modifiées à tout moment
- Ne peuvent pas être supprimées si elles sont en cours d’utilisation
Les politiques de stockage des VM sont un ensemble de règles que vous configurez pour les machines virtuelles.
Chaque politique de stockage reflète un ensemble de capacités répondant aux exigences de disponibilité, de performance et de stockage de l’application ou de l’accord de niveau de service (SLA) de cette VM.
Il est recommandé de créer les politiques de stockage avant de déployer les machines virtuelles qui en ont besoin.
Vous pouvez appliquer et mettre à jour les politiques de stockage après le déploiement.
Un administrateur vSphere responsable du déploiement des machines virtuelles peut sélectionner des politiques créées en fonction des capacités de stockage.
En fonction de la politique sélectionnée pour l’objet VM, ces capacités sont appliquées au vSAN datastore.
L’objet est créé sur plusieurs hôtes ESXi et groupes de disques pour satisfaire ces politiques.
¶ Affichage des paramètres de la VM pour les informations vSAN
La consommation du stockage vSAN est basée sur la politique de stockage de la machine virtuelle (VM).
La vue de placement physique des disques de la VM fournit les informations suivantes :
- État des composants
- Hôte ESXi
- Emplacement des fichiers de disque sur un vSAN datastore
¶ À propos des domaines de défaillance vSAN
Dans vSAN, un domaine de défaillance (fault domain) représente un ensemble de matériel partageant un même point de défaillance potentiel :
- vSAN peut tolérer la défaillance d’un hôte unique, d’un rack complet, d’un commutateur réseau, et plus encore.
- Les objets protégés sont distribués entre différents domaines de défaillance.
Pour plus d’informations sur la gestion et la configuration des domaines de défaillance dans vSAN, consultez Administering VMware vSAN à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-80-administration-guide.pdf
¶ Configurations de domaines de défaillance
Les domaines de défaillance vSAN sont configurés selon le cas d’utilisation :
- Cluster étendu (Stretched cluster) : vSAN est configuré sur des hôtes répartis sur plusieurs sites physiques.
- Cluster non étendu (Nonstretched cluster) : plusieurs domaines de défaillance sont créés au sein d’un même cluster.
- Configuration vSAN à deux nœuds (Two-node configuration) : vSAN est configuré avec deux nœuds de données et un nœud témoin (witness) sur un site distinct.
Lors des opérations du cycle de vie, vSphere Lifecycle Manager prend en charge les demandes suivantes :
- Mettre à niveau le cluster étendu vSAN afin que les hôtes du domaine de défaillance préféré soient mis à jour avant ceux du domaine de défaillance secondaire.
- Mettre à niveau le cluster vSAN comportant plusieurs domaines de défaillance de sorte que tous les hôtes d’un domaine de défaillance soient mis à jour avant de passer au domaine suivant.
¶ Lab 10 : Visualiser une configuration de vSAN Datastore
Visualisez une configuration de vSAN datastore et les composants d’une machine virtuelle sur le vSAN datastore :
- Afficher une configuration de vSAN Datastore
- Afficher la politique de stockage par défaut de vSAN
- Afficher une machine virtuelle sur le vSAN Datastore
Retrouvez le lien du Lab en cliquant ici : Lab 10 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Expliquer le but d’un vSAN datastore
- Décrire l’architecture et les exigences d’une configuration vSAN
- Expliquer le but des politiques de stockage vSAN
- Décrire le but des domaines de défaillance
¶ Leçon 5 : vSphere Storage APIs - Array Integration
¶ Objectifs d’apprentissage
- Décrire comment vSphere Storage APIs - Array Integration aide les baies de stockage à s’intégrer avec vSphere.
- Expliquer comment la récupération d’espace fonctionne avec les VMFS datastores.
¶ À propos de vSphere Storage APIs - Array Integration
Les vSphere Storage APIs - Array Integration aident les fournisseurs de stockage à fournir une assistance matérielle pour accélérer les opérations d’E/S vSphere qui sont plus efficacement réalisées au niveau du matériel de stockage.
Les vSphere Storage APIs - Array Integration constituent un ensemble de protocoles et de fonctionnalités du VMkernel qui prennent en charge l’intégration entre ESXi et les baies de stockage :
- Grâce aux APIs d’accélération matérielle, les baies peuvent s’intégrer à vSphere pour déléguer de manière transparente certaines opérations de stockage au matériel.
- Les APIs de provisionnement fin (thin provisioning) aident à éviter les conditions de manque d’espace et à exécuter la récupération d’espace.
Les vSphere Storage APIs - Array Integration sont une famille d’APIs utilisées par des fournisseurs tiers de matériel, de logiciels et de stockage pour développer des composants qui améliorent plusieurs fonctionnalités et solutions de vSphere.
Dans un environnement virtualisé, les disques virtuels sur un VMFS datastore ne peuvent pas être interprétés par la baie de disques ; le VMFS datastore ne peut donc pas utiliser les fonctions matérielles par machine virtuelle ou par fichier de disque virtuel.
Les plug-ins vSphere Storage APIs - Array Integration peuvent améliorer les performances de transfert de données et sont transparents pour l’utilisateur final.
¶ APIs d’accélération matérielle pour le stockage en blocs
Grâce aux APIs d’accélération matérielle, l’hôte ESXi peut déléguer certaines opérations spécifiques de gestion de machines virtuelles (VM) et de stockage au matériel de stockage :
- L’utilisation de ces APIs réduit considérablement la charge CPU sur l’hôte.
- Les périphériques de stockage en blocs, tels que Fibre Channel et iSCSI, prennent en charge l’accélération matérielle.
- L’accélération matérielle pour les périphériques de stockage en blocs prend en charge plusieurs opérations de baie (array operations).
| Array Operation | Cas d’utilisation |
|---|---|
| Full copy, aussi appelé clone blocks, copy offload ou XCOPY | Utilisé par vSphere Storage vMotion, pour le clonage de VMs et le déploiement d’une VM à partir d’un modèle |
| Block zeroing, aussi appelé write same | Utilisé lors de la création de disques virtuels épais avec eager-zeroed |
| Hardware-assisted locking, aussi appelé atomic test and set | Améliore les performances lors des modifications de métadonnées VMFS |
Avec l’assistance du matériel de stockage, l’hôte exécute les opérations de baie plus rapidement, tout en consommant moins de CPU, de mémoire et de bande passante du réseau de stockage.
L’accélération matérielle ESXi pour les périphériques de stockage en blocs prend en charge les opérations suivantes :
-
Full copy : les baies de stockage peuvent effectuer des copies complètes des données directement au sein de la baie. L’hôte n’a pas besoin de lire et d’écrire les données. Cette opération réduit le temps et la charge réseau lors du clonage de VMs, du provisionnement à partir d’un modèle ou lors d’une migration avec vSphere Storage vMotion.
-
Block zeroing : les baies de stockage peuvent mettre à zéro plusieurs blocs afin de fournir un espace de stockage nouvellement alloué, libre de toute donnée précédente. Cette opération réduit le temps et la charge réseau lors de la création de VMs ou du formatage de disques virtuels. Elle est activée lorsque l’option Thick Provision Eager Zero est utilisée pour un disque.
-
Hardware-assisted locking : cette option prend en charge le verrouillage granulaire des VMs sans utiliser de réservations SCSI. Le verrouillage des disques s’effectue par secteur, contrairement aux réservations SCSI qui verrouillent l’ensemble du LUN (Logical Unit Number).
Les fonctionnalités d’accélération matérielle sont activées par défaut et utilisées sur les baies de stockage qui les prennent en charge.
Il est possible de désactiver ces fonctionnalités, mais ce n’est pas recommandé.
Les anciennes baies ou celles disposant d’un firmware obsolète peuvent ne pas prendre en charge l’accélération matérielle. Dans ce cas, l’hôte doit recourir à des techniques plus anciennes et plus gourmandes en CPU pour effectuer les mêmes tâches.
Pour plus d’informations sur vSphere Storage APIs - Array Integration, consultez l’article VMware de la base de connaissances : VMware KB 1021976.
¶ Accélération matérielle pour NAS
Avec l’accélération matérielle pour le Network-Attached Storage (NAS), les baies NAS peuvent s’intégrer à vSphere pour déléguer certaines opérations de stockage, comme le clonage hors ligne, directement à la baie.
Cette intégration réduit la charge CPU sur l’hôte.
L’accélération matérielle pour NAS prend en charge les opérations NAS suivantes :
- Full file clone : le fichier entier, et non des segments de fichier, est cloné.
- Reserve space : l’espace pour un disque virtuel est alloué en format épais (thick).
- Native Snapshot support : VMware Horizon peut déléguer la création de linked clones à une baie NAS.
- Extended file statistics
Avec l’accélération matérielle, l’hôte peut s’intégrer aux périphériques NAS et utiliser plusieurs opérations matérielles que le stockage NAS met à disposition :
- Full file clone : cette opération est similaire au clonage de blocs VMFS, sauf que les baies NAS clonent des fichiers entiers au lieu de segments de fichiers.
- Reserve space : les baies de stockage allouent l’espace pour un fichier de disque virtuel en format épais (thick).
En général, lorsque vous créez un disque virtuel sur un NFS datastore, le serveur NAS détermine la politique d’allocation.
La politique d’allocation par défaut sur la plupart des serveurs NAS est fine (thin) et ne garantit pas un espace de stockage réservé pour le fichier.
Cependant, l’opération reserve space peut instruire le périphérique NAS d’utiliser des mécanismes spécifiques au fournisseur pour réserver de l’espace pour un disque virtuel.
Ainsi, vous pouvez créer des disques virtuels épais sur le NFS datastore. - Native Snapshot support : cette opération permet à View (Horizon) de déléguer la création de linked clones à une baie NAS.
- Extended file statistics : les baies de stockage peuvent rapporter avec précision l’utilisation de l’espace.
L’accélération matérielle pour NAS est mise en œuvre à l’aide de plug-ins NAS spécifiques aux fournisseurs.
Ces fournisseurs créent et maintiennent généralement ces plug-ins, puis les distribuent sous forme de vSphere Installation Bundles (VIBs) via une page Web.
¶ API de Thin Provisioning pour les baies de stockage
Avec les Array Thin Provisioning APIs, un hôte peut s’intégrer au stockage physique et détecter l’utilisation de l’espace dans les LUNs à provisionnement fin (thin-provisioned).
-
Un VMFS datastore déployé sur un LUN à provisionnement fin ne peut détecter que la taille logique du LUN.
Par exemple, si une baie indique 2 To d’espace de stockage mais ne fournit en réalité qu’1 To, le datastore considérera 2 To comme la taille du LUN. -
En utilisant l’intégration de thin provisioning, l’hôte peut effectuer les tâches suivantes :
-
Surveiller l’utilisation de l’espace sur les LUNs thin-provisioned afin d’éviter un manque d’espace physique.
-
Informer la baie de l’espace du datastore libéré lorsque les actions suivantes se produisent :
- Les disques virtuels et les fichiers de machines virtuelles sont supprimés du datastore.
- Les disques virtuels et les fichiers de machines virtuelles sont migrés hors du datastore via vSphere Storage vMotion.
- Les VM Snapshots sont supprimés et consolidés.
-
Les LUNs traditionnels présentés à l’hôte ESXi par les baies de stockage sont à provisionnement fixe (thick-provisioned).
L’espace physique nécessaire pour chaque LUN est entièrement alloué à l’avance.
ESXi prend également en charge les LUNs thin-provisioned.
Lorsqu’un LUN est à provisionnement fin, la baie de stockage indique la taille logique du LUN, qui peut être supérieure à la capacité physique réelle sous-jacente.
Lorsque le datastore s’étend ou lorsque vSphere Storage vMotion est utilisé pour migrer des machines virtuelles vers un LUN thin-provisioned, les Array Thin Provisioning APIs permettent à l’hôte de communiquer avec le LUN.
L’hôte peut alors émettre des avertissements en cas de dépassement de la capacité physique ou de conditions de manque d’espace.
Aucune étape d’installation n’est requise pour les extensions d’array thin provisioning.
Le thin provisioning des baies fonctionne sur tous les volumes VMFS5 et VMFS6.
Le micrologiciel des périphériques (firmware) activé pour cette API doit prendre en charge les fonctionnalités de thin provisioning.
ESXi vérifie en permanence la compatibilité du firmware avec les fonctionnalités de array thin provisioning.
Après la mise à jour du firmware, ESXi commence automatiquement à utiliser ces fonctionnalités.
¶ À propos de la récupération d’espace
Dans un environnement virtualisé, différents niveaux d’abstraction existent au niveau de la couche de stockage :
- Les fichiers utilisateurs résident dans la couche du système d’exploitation invité (Guest OS). Le système d’exploitation invité gère ces fichiers.
- Le système d’exploitation invité (Guest OS) réside dans le fichier VMDK, qui est géré par le VMFS datastore.
- Le VMFS datastore réside sur le LUN, qui est présenté comme périphérique de stockage à l’hôte ESXi.
Les données sont supprimées du VMFS datastore de la manière suivante :
- Les données sont supprimées à partir du système d’exploitation invité (guest OS).
- Un fichier VMDK est supprimé du datastore.
Dans les deux cas, l’espace sur la baie (array) n’est pas libéré.
Cet espace est appelé espace mort ou espace sale.
La baie ne peut pas réutiliser cet espace, sauf si une commande lui indique de le faire, comme la commande SCSI UNMAP.
Supprimer ou retirer des fichiers d’un VMFS datastore libère de l’espace au sein du système de fichiers.
Cet espace libre reste associé au périphérique de stockage jusqu’à ce que le système de fichiers le libère ou l’unmappe.
¶ Récupération d’espace avec VMFS
ESXi prend en charge la récupération d’espace libre.
Lorsque vous exécutez la commande SCSI unmap, un hôte ESXi informe la baie de stockage qu’elle peut récupérer l’espace libre :
- Avec un VMFS5 datastore, vous pouvez envoyer manuellement la commande
unmapà l’aide de la commandeesxcli. - Avec un VMFS6 datastore, l’hôte ESXi envoie automatiquement la commande
unmapà la baie de stockage.
| Fonctionnalité | VMFS5 | VMFS6 |
|---|---|---|
| Récupération d’espace automatique | Non | Oui |
| Récupération d’espace manuelle via ESXCLI | Oui | Oui |
Lorsque vous exécutez la commande unmap, un hôte ESXi informe la baie de stockage que les fichiers de machine virtuelle (VM files) ont été supprimés ou retirés d’un VMFS datastore en thin provisioning.
Suite à cette notification, la baie peut récupérer les blocs libérés.
¶ Effectuer une récupération d’espace manuelle sur un VMFS5 Datastore
Pour récupérer manuellement de l’espace sur un VMFS5 datastore, vous pouvez exécuter la commande esxcli suivante : esxcli storage vmfs unmap
Vous pouvez automatiser ce processus en utilisant cette commande dans un script PowerCLI et en planifiant l’exécution du script en dehors des heures de pointe.
| Option de commande | Description | |
|---|---|---|
| -l / --volume-label=volume_label | Le label du volume VMFS à désassocier (unmap). Argument obligatoire. Utilisez soit l’option -l, soit l’option -u, mais pas les deux. | |
| -u / --volume-uuid=volume_uuid | L’UUID du volume VMFS à désassocier. Argument obligatoire. Utilisez soit l’option -l, soit l’option -u, mais pas les deux. | |
| -n / --reclaim-unit=number | Nombre de blocs VMFS à désassocier par itération. Argument optionnel. La valeur par défaut est 200. |
Sur les VMFS5 datastores, vous devez exécuter manuellement la commande : esxcli storage vmfs unmap.
Le serveur cible vous demande un nom d’utilisateur et un mot de passe.
D’autres options de connexion, comme un fichier de configuration ou un fichier de session, sont également prises en charge.
Cette commande peut être exécutée sans fenêtre de maintenance :
- Vous pouvez spécifier la taille de récupération en blocs plutôt qu’en pourcentage, ce qui rend le calcul de la taille de récupération plus intuitif.
- L’espace inutilisé (“dead space”) est récupéré par incréments, plutôt que tout en une seule fois, afin d’éviter d’éventuels problèmes de performance.
Lorsque vous exécutez cette commande, elle peut envoyer plusieurs requêtes unmap simultanément, ce qui peut temporairement bloquer certaines ressources pendant l’opération.
Pour plus d’informations sur cette commande, consultez la documentation vSphere Storage : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-storage-guide.pdf
¶ Activer la récupération d’espace automatique sur un VMFS6 Datastore
Lorsque vous créez un VMFS6 datastore, vous pouvez modifier les paramètres par défaut pour la récupération d’espace asynchrone automatique :
-
Space Reclamation Granularity : définit la taille d’unité utilisée pour la commande UNMAP. La valeur par défaut est 1 MB.
-
Space Reclamation Priority : contrôle la vitesse à laquelle les blocs supprimés ou désassociés (unmapped) sont récupérés sur les LUNs qui soutiennent le datastore.
La priorité par défaut est Low, ce qui correspond à un taux UNMAP de 25 MBps.
Par défaut, la granularity (granularité) de récupération d’espace est égale à la taille de bloc, c’est-à-dire 1 MB. Les secteurs de stockage plus petits que 1 MB ne sont pas récupérés.
Par défaut également, la LUN exécute l’opération de récupération d’espace à un rythme faible.
Vous pouvez aussi définir la space reclamation priority sur None pour désactiver cette opération pour le datastore.
¶ Configurer le taux automatique d’UNMAP
Introduit dans vSphere 6.7, vous pouvez définir un taux UNMAP fixe pour le datastore.
Le taux UNMAP correspond à la vitesse à laquelle les commandes automatiques UNMAP sont traitées.
Vous pouvez modifier ce taux UNMAP pour l’adapter aux capacités de la baie de stockage (storage array).
¶ Prise en charge de la récupération d’espace pour les systèmes d’exploitation invités
Les VMFS5 et VMFS6 datastores prennent tous deux en charge la commande UNMAP émise par le système d’exploitation invité.
Certains systèmes d’exploitation invités, tels que Windows Server 2012 R2, peuvent envoyer des commandes UNMAP à la baie.
Les commandes UNMAP de l’invité sont traduites et transmises à la baie, qui peut alors récupérer l’espace libéré.
Pour les fichiers VMDK à provisionnement fin (thin-provisioned), l’espace disque virtuel diminue de la quantité d’espace récupérée.
ESXi prend en charge les commandes UNMAP émises directement depuis un système d’exploitation invité pour récupérer de l’espace de stockage.
VMFS5 prend en charge les requêtes automatiques de récupération d’espace pour un nombre limité de systèmes d’exploitation invités.
Pour envoyer des requêtes UNMAP depuis le système d’exploitation invité vers la baie, la machine virtuelle (VM) doit remplir les conditions préalables suivantes :
- Le disque virtuel doit être en provisionnement fin (thin-provisioned).
- Le système d’exploitation invité doit être capable d’identifier le disque virtuel comme étant à provisionnement fin.
- Le paramètre avancé de l’hôte ESXi “EnableBlockDelete” doit être défini sur 1.
Avec VMFS6, utilisez le paramètre Space Reclamation Priority sur le datastore.
L’option EnableBlockDelete est ignorée.
Lorsque vous utilisez la récupération d’espace avec des datastores VMFS6, la considération suivante s’applique :
- VMFS6 traite la requête UNMAP provenant du système d’exploitation invité uniquement lorsque l’espace à récupérer est égal à 1 Mo ou à un multiple de 1 Mo.
VMFS6 prend généralement en charge les requêtes automatiques de récupération d’espace provenant des systèmes d’exploitation invités et transmet ces requêtes à la baie.
De nombreux systèmes d’exploitation invités peuvent envoyer la commande UNMAP sans nécessiter de configuration supplémentaire.
Les systèmes d’exploitation invités qui ne prennent pas en charge les UNMAP automatiques peuvent nécessiter une intervention manuelle.
Pour obtenir des informations sur les systèmes d’exploitation invités qui prennent en charge la récupération automatique d’espace sur VMFS6, contactez votre fournisseur.
¶ Copie étendue (XCOPY)
Introduit avec vSphere 8 Update 1, ESXi prend désormais en charge la fonction Extended Copy (XCOPY) entre des datastores situés sur différentes baies de stockage.
XCOPY optimise la copie de données entre des datastores hébergés sur différentes baies de stockage.
Les administrateurs ont maintenant la possibilité de déléguer (offload), migrer et cloner des charges de travail directement vers leurs baies de stockage.
Bien que vSphere 8 U1 active cette fonctionnalité, la migration réelle des données entre les baies doit être prise en charge du côté de la baie de stockage.
¶ QCM : vSphere Storage APIs – Intégration avec les baies
Quelles actions s’appliquent à un hôte ESXi qui utilise des périphériques de stockage prenant en charge les vSphere Storage APIs – Array Integration ?
(Sélectionnez toutes les réponses applicables.)
☐ Informer la baie de stockage qu’elle peut récupérer l’espace libre dans un datastore VMFS.
☐ Déléguer certaines opérations de stockage, telles que le clonage hors ligne, à une baie NAS.
☐ Récupérer des informations sur une baie de stockage, telles que sa topologie et ses capacités.
☐ Déléguer certaines opérations de stockage à un périphérique de stockage en mode bloc, tel que Fibre Channel ou iSCSI.
¶ Réponses : vSphere Storage APIs – Intégration avec les baies
Quelles actions s’appliquent à un hôte ESXi qui utilise des périphériques de stockage prenant en charge les vSphere Storage APIs – Array Integration ?
(Sélectionnez toutes les réponses applicables.)
✓ Informer la baie de stockage qu’elle peut récupérer l’espace libre dans un datastore VMFS.
✓ Déléguer certaines opérations de stockage, telles que le clonage hors ligne, à une baie NAS.
☐ Récupérer des informations sur une baie de stockage, telles que sa topologie et ses capacités.
✓ Déléguer certaines opérations de stockage à un périphérique de stockage en mode bloc, tel que Fibre Channel ou iSCSI.
¶ Revue des objectifs d’apprentissage
- Décrire comment les vSphere Storage APIs – Array Integration aident les baies de stockage à s’intégrer avec vSphere.
- Expliquer comment fonctionne la récupération d’espace (space reclamation) avec les datastores VMFS.
¶ Leçon 6 : vSphere Storage APIs for Storage Awareness et vSphere APIs for I/O Filtering (VASA et VAIO)
¶ Objectifs d’apprentissage
- Décrire comment l’API vSphere for Storage Awareness (VASA) garantit que les exigences de stockage d’une machine virtuelle (VM) sont respectées.
- Expliquer comment les fournisseurs peuvent créer des services de données pour les VMs en utilisant les vSphere APIs for I/O Filtering (VAIO).
¶ À propos de vSphere API for Storage Awareness
Avec vSphere API for Storage Awareness, un fournisseur de stockage peut développer un composant logiciel appelé storage provider pour ses baies de stockage.
Grâce à cette API, un storage provider obtient des informations sur la topologie, les capacités et l’état du stockage disponible dans la baie.
vCenter se connecte au storage provider. Les informations issues de ce fournisseur apparaissent dans le vSphere Client.
Naviguez dans vCenter > onglet Configure > Storage Providers
Dans vCenter, les administrateurs vSphere ne peuvent pas accéder directement aux capacités de stockage du LUN sur lequel leurs machines virtuelles (VMs) sont stockées.
Les VMs sont approvisionnées sur un “storage black box” : les administrateurs ne voient qu’un identifiant de LUN, comme un NAA ID (Network Address Authority ID) ou un identifiant T10.
Un fournisseur de stockage peut utiliser vSphere API for Storage Awareness pour fournir des informations détaillées sur le LUN.
Le storage provider est développé par le fournisseur de la baie de stockage.
Ce provider peut résider soit sur le processeur de la baie de stockage, soit sur une appliance virtuelle — le choix revient au fournisseur.
vCenter se connecte ensuite à ce provider pour obtenir des informations sur la topologie, les capacités et l’état du LUN.
Ces informations sont affichées dans le vSphere Client.
Un storage provider peut fournir des informations sur un ou plusieurs périphériques de stockage.
Il peut prendre en charge des connexions vers une seule instance de vCenter ou vers plusieurs instances.
¶ Avantages des Storage Providers
Les storage providers fournissent aux administrateurs vSphere des informations sur la topologie, les capacités et l’état des LUNs utilisés pour leurs machines virtuelles (VMs).
Les administrateurs peuvent utiliser ces informations de plusieurs façons :
- Pour surveiller l’état de santé et l’utilisation de leurs LUNs.
- Pour configurer les VM storage policies avec le stockage adéquat en termes d’espace, de performance et de respect des accords de niveau de service (SLA).
Un storage provider fournit des informations de capacités concernant la configuration du stockage, son état et les services de données disponibles dans l’environnement.
vSphere Storage DRS utilise ces informations pour effectuer le placement et la migration des VMs de manière compatible avec le système de stockage.
Un storage provider fournit notamment les informations suivantes :
-
Storage capabilities : Informations sur les caractéristiques et services du stockage, tels que le nombre et le type de disques utilisés pour un LUN, les opérations d’E/S en mégaoctets par seconde, le type de compression appliqué, et si le format thick-provisioned est utilisé.
-
Storage status : État des entités de stockage ainsi que les alarmes et événements liés aux changements de configuration.
¶ Catégories de Storage Providers
En général, vCenter et ESXi utilisent des storage providers pour obtenir des informations sur la configuration, l’état et les services de données du stockage dans votre environnement.
¶ Persistence Storage Providers :
-
Gèrent les baies et les abstractions de stockage.
-
Peuvent fournir des services de données, tels que la réplication basée sur la baie.
-
Exemples :
- vSAN storage provider
- vSphere Virtual Volumes storage provider
¶ Data Service Providers :
-
Appelés également I/O filter storage providers ou data service providers.
-
Exemples :
- Mise en cache basée sur l’hôte (Host-based caching)
- Compression
- Encryption
Les persistence storage providers et les data service providers peuvent appartenir à l’une des catégories suivantes :
¶ Built-in Storage Providers :
-
Fournis par VMware.
-
En général, ils ne nécessitent pas d’enregistrement.
-
Exemples :
- Les storage providers prenant en charge vSAN ou les I/O filters sont intégrés et s’enregistrent automatiquement.
¶ Third-party Storage Providers :
-
Fournis par un tiers et nécessitent généralement un enregistrement manuel.
-
Exemples :
- vSphere Virtual Volumes storage provider
- vSphere APIs for Storage Awareness storage providers
¶ Enregistrement d’un Storage Provider
Dans le vSphere Client, sélectionnez Configure > Storage Providers pour enregistrer et gérer un storage provider.
Depuis le panneau Storage Providers, vous pouvez enregistrer un storage provider. Toutes les capacités de stockage du système présentées par le storage provider apparaissent ensuite dans le vSphere Client.
Pour enregistrer un storage provider, le fournisseur de stockage (storage vendor) doit fournir une URL, un compte de connexion et un mot de passe.
Les utilisateurs se connectent au provider pour obtenir les informations sur la baie (array information).
Le vCenter doit faire confiance à l’hôte du provider, donc un certificat de sécurité provenant du provider doit être installé sur le système vCenter.
Pour plus d’informations sur la procédure d’enregistrement des Storage Providers, consultez : VMware Docs – Register Storage Providers
¶ À propos des vSphere APIs pour le filtrage I/O
Les vSphere APIs for I/O Filtering (VAIO) fournissent un cadre permettant de créer et d’implémenter des filtres d’E/S (I/O filters) dans le flux de données d’une machine virtuelle (VM) :
- Les filtres d’E/S interceptent et modifient les opérations I/O du disque de la VM dans le VMkernel, avant que les données ne soient transférées vers ou depuis le stockage physique.
- Les filtres d’E/S sont indépendants de la topologie de stockage.
Avec VAIO, VMware et les fournisseurs tiers peuvent créer des services de données, tels que la mise en cache (caching) et la réplication (replication).
Les filtres d’E/S peuvent accéder directement au chemin d’E/S de la VM. Vous pouvez activer un filtre d’E/S pour un disque virtuel individuel.
VMware propose certaines catégories de filtres d’E/S. De plus, des fournisseurs tiers peuvent créer leurs propres filtres. En général, ces filtres d’E/S sont distribués sous forme de packages qui incluent un programme d’installation pour déployer les composants du filtre sur vCenter et les hôtes ESXi du cluster.
Les filtres d’E/S peuvent prendre en charge tous les types de datastores suivants :
- VMFS
- NFS 3
- NFS 4.1
- vSphere Virtual Volumes
- vSAN
¶ Types de filtres d’E/S (I/O Filters)
Les types de filtres d’E/S pouvant être appliqués aux machines virtuelles (VM) sont regroupés par catégories de filtres.
| Catégorie | Exemples |
|---|---|
| Replication (Réplication) | Réplique toutes les opérations d’écriture E/S vers une cible externe, comme un autre hôte ou un cluster. |
| Encryption (Chiffrement) | Fournit des mécanismes de chiffrement pour les machines virtuelles. |
| Caching (Mise en cache) | Met en œuvre une mémoire cache pour les données des disques virtuels. |
| Storage I/O Control (Contrôle des E/S de stockage) | Donne la priorité aux opérations d’E/S de stockage attribuées aux VMs lors de périodes de contention d’E/S. |
VMware fournit certaines catégories de filtres d’E/S installés sur vos hôtes ESXi.
De plus, les partenaires VMware peuvent créer leurs propres filtres d’E/S via les vSphere APIs for I/O Filtering dans le cadre du programme de développement.
Les filtres d’E/S peuvent remplir plusieurs fonctions selon leur conception et leur objectif.
¶ Fonctionnement des filtres d’E/S
Le framework de filtre d’E/S au sein du VMkernel est responsable de l’interception des E/S et de l’application des filtres associés à une machine virtuelle (VM).
Les filtres d’E/S s’exécutent dans le VM user world afin de garantir que tout problème lié à un filtre affecte uniquement la VM et non l’ensemble de l’hôte.
Les filtres fonctionnent en interceptant les données dans le VMkernel avant que celles-ci ne soient envoyées vers le stockage physique.
Le framework de filtre d’E/S existe en dehors de la couche SCSI virtuelle, ce qui signifie que les E/S hors ligne vers le disque (c’est-à-dire les modifications effectuées lorsque la VM est éteinte) peuvent également être interceptées.
Le framework définit quels filtres doivent être appliqués et dans quel ordre.
Les filtres d’E/S s’exécutent dans le VM’s user world.
Un world est un contexte d’exécution planifié sur un processeur.
Un world est similaire à un processus dans les systèmes d’exploitation conventionnels.
Le framework de filtre d’E/S applique les filtres d’E/S dans l’ordre suivant :
- Réplication
- Chiffrement
- Mise en cache
- Contrôle des E/S de stockage
L’ordre dans lequel les E/S passent à travers ces catégories de filtres est prédéfini.
Cet ordre, tel qu’illustré sur la diapositive, est important — en particulier si vous prévoyez de mettre en œuvre un filtre de réplication et un filtre de chiffrement.
Les données passent par les filtres dans cet ordre prédéfini avant d’être transférées vers le stockage où résident les fichiers ou objets de la VM.
Vous pouvez installer plusieurs filtres appartenant à la même catégorie sur votre hôte ESXi.
Cependant, une seule instance de filtre d’une même catégorie peut être appliquée à un disque virtuel donné.
Comme le filtre de réplication s’exécute avant le filtre de chiffrement, les données répliquées le sont en texte clair.
Des mesures de sécurité supplémentaires doivent donc être prises pour protéger ces transmissions et les données présentes sur la cible de réplication.
¶ Fournisseurs de filtres d’E/S
ESXi dispose de filtres d’E/S préinstallés :
- VM encryption
- Storage I/O Control
Les filtres d’E/S tiers doivent être installés selon les instructions du fournisseur.
Une fois les filtres d’E/S installés sur les hôtes ESXi, le framework de filtre d’E/S configure et enregistre un fournisseur de stockage, également appelé IOFilter provider, pour chaque hôte.
Le fournisseur IOFilter annonce les nouvelles capacités de filtre d’E/S à vCenter.
Vous pouvez utiliser ces capacités pour créer des politiques de stockage (Storage Policies).
Les fournisseurs de stockage pour le filtrage d’E/S sont des composants logiciels de vSphere.
Ces fournisseurs s’intègrent avec les filtres d’E/S et rapportent à vCenter les capacités de service de données prises en charge par les filtres d’E/S.
Si vous utilisez des filtres d’E/S fournis par des tiers, vous devez installer les filtres d’E/S dans un cluster d’hôtes ESXi.
Vous ne pouvez pas installer les filtres sur des hôtes individuels.
Les packages de filtres sont généralement distribués sous forme de VIBs (VMware Installation Bundles), qui peuvent inclure des démons de filtres d’E/S, des fournisseurs CIM et d’autres composants associés.
En général, pour déployer les filtres, vous exécutez les installateurs fournis par les vendeurs.
Les capacités renseignent le volet VM Storage Policies dans le vSphere Client et peuvent être référencées dans une politique de stockage VM.
Vous appliquez cette politique aux disques virtuels afin que les filtres d’E/S puissent traiter les opérations d’E/S des disques.
¶ Affichage des informations sur les fournisseurs de filtres d’E/S
Pour afficher les fournisseurs de filtres d’E/S pour chaque hôte, sélectionnez l’objet vCenter dans l’inventaire, puis sélectionnez : Configure > Storage Providers
¶ Revue des objectifs d’apprentissage
- Décrire comment vSphere API for Storage Awareness garantit que les exigences de stockage d’une VM sont respectées.
- Expliquer comment les fournisseurs peuvent créer des services de données pour les machines virtuelles (VMs) en utilisant les vSphere APIs for I/O Filtering.
¶ Leçon 7 : Vue d’ensemble de la gestion basée sur les stratégies de stockage
¶ Objectifs d’apprentissage
- Décrire la gestion basée sur les stratégies de stockage (Storage Policy Based Management – SPBM).
- Identifier les catégories de règles de stratégies de stockage.
¶ À propos de la gestion basée sur les stratégies de stockage
La gestion basée sur les stratégies de stockage (SPBM) garantit que les machines virtuelles (VMs) utilisent un stockage qui offre un niveau spécifié de capacité, de performance, de disponibilité, de redondance, et ainsi de suite.
SPBM regroupe et abstrait les services de stockage et de données fournis par vSAN, vSphere Virtual Volumes, les I/O Filters, ou encore le stockage traditionnel.
Les partenaires VMware et les fournisseurs de stockage peuvent prendre en charge ces services de stockage et de données.
Au lieu d’intégrer chaque fournisseur ou type de service de stockage individuellement, la SPBM fournit un cadre universel pour de nombreux types d’entités de stockage.
Lorsqu’une application doit être provisionnée, vSphere utilise le module Storage Policy Based Management pour faire correspondre les exigences de la stratégie aux capacités configurées des conteneurs de stockage.
De cette manière, vSphere détermine où les fichiers VMDK doivent être placés.
La gestion basée sur les stratégies de stockage (Storage Policy Based Management – SPBM) présente les fonctionnalités suivantes :
- Publication des capacités de stockage et des services de données que les baies de stockage et les I/O filters fournissent
- Communication bidirectionnelle entre ESXi et vCenter d’un côté, et les baies de stockage et I/O filters de l’autre
- Provisionnement des VM basé sur les stratégies de stockage des machines virtuelles
Les stratégies de stockage des VM réduisent la quantité de planification de stockage nécessaire pour chaque VM.
Par exemple, vous pouvez utiliser ces stratégies pour créer des niveaux de stockage (storage tiers) de base.
Les datastores présentant des capacités similaires sont regroupés en catégories telles que Gold, Silver et Bronze.
- Un stockage redondant et haute performance peut être étiqueté Gold tier.
- Un stockage non redondant avec performance moyenne peut être étiqueté Bronze tier.
Les capacités exposées peuvent inclure la performance, la capacité, la protection, etc.
Les capacités demandées sont alignées sur les limites des VM.
Les capacités satisfaites correspondent au datastore provisionné, et la stratégie est associée à ce datastore.
¶ À propos des stratégies de stockage des VM
Une VM storage policy contrôle le type de stockage fourni à la machine virtuelle (VM) ainsi que la façon dont cette VM est placée dans le stockage.
Elle détermine également les services de données que la VM peut utiliser.
Les VM storage policies vous aident à atteindre les objectifs suivants :
- Catégoriser les datastores selon différents niveaux de service.
- Placer les disques de VM sur le stockage approprié.
Les VM storage policies capturent les caractéristiques de stockage dont les fichiers/objets principaux de la VM et les disques virtuels ont besoin pour exécuter les applications sur une VM.
Ces caractéristiques de stockage sont définies dans un ensemble de règles.
Les VM storage policies sont essentielles au provisionnement des VM.
Vous utilisez les VM storage policies lors du provisionnement d’une VM afin de garantir que les disques de la VM soient placés sur le stockage le mieux adapté à sa situation.
Par exemple, avec les VM storage policies, vous pouvez vous assurer qu’une VM exécutant une base de données critique et intensive en I/O soit placée dans le Gold tier.
Idéalement, vous cherchez à obtenir la meilleure correspondance possible entre les exigences de stockage prédéfinies pour la VM et les propriétés physiques du stockage disponible.
¶ À propos des règles de stratégie de stockage
Les règles sont les éléments de base d’une storage policy.
Chaque règle est une déclaration décrivant une exigence spécifique pour le stockage des VM et les services de données.
| Catégorie | Description | Exemples |
|---|---|---|
| Capability-based placement rules | Spécifient une exigence particulière de stockage pour la VM, ce qui guide la décision concernant le placement de la VM. | - Niveau RAID - Nombre de défaillances tolérées |
| Tag-based placement rules | Référencent les tags de datastore pour définir le placement de la VM. | - Gold Tier tag - Silver Tier tag - Bronze Tier tag |
| Data service rules | Activent des services de données spécifiques pour la VM, mais ne définissent pas le placement du stockage ni les exigences de stockage de la VM. | - Caching - Replication |
Les capability-based placement rules décrivent la manière dont les objets de stockage de VM sont alloués dans un datastore afin d’atteindre le niveau de service requis.
Par exemple, les règles peuvent lister les virtual volumes comme destination et définir l’objectif maximal de point de récupération (RPO) pour ces objets.
Le Storage Policy Based Management (SPBM) recherche les datastores de virtual volumes capables de correspondre à ces règles et de satisfaire les exigences de stockage de la VM.
Les tag-based placement rules utilisent les tags de datastore.
Vous pouvez employer ces règles basées sur les tags pour ajuster la demande de placement de votre VM.
Par exemple, vous pouvez exclure les datastores avec un tag spécifique, comme Palo Alto, de la liste de vos virtual volumes datastores.
Les data service rules activent des services de données spécifiques.
Les systèmes de stockage ou d’autres entités peuvent fournir ces services.
Ils peuvent également être installés sur vos hosts ESXi et votre vCenter.
Vous incluez les data service rules dans les composants de la storage policy.
¶ Exemple de Storage Policy
Lorsque vous créez une storage policy, vous pouvez sélectionner une ou plusieurs règles qui représentent les niveaux de service exigés par les VMs.
Ces règles définissent les caractéristiques de stockage.
Chaque fournisseur de baies de stockage (array vendor) possède un namespace identifié.
Ce namespace contient les identifiants des conteneurs de stockage ainsi que leurs capacités attribuées.
Les capabilities apparaissent ensuite comme options dans l’interface client.
Les VM storage policies permettent de vérifier que les VMs s’exécutent sur un stockage correspondant aux caractéristiques de performance et de disponibilité requises.
Pour vSAN et les virtual volumes, les VM storage policies garantissent que les VMs sont placées sur le stockage approprié.
Par exemple, pour placer les disques d’un serveur de base de données sur le bon type de stockage :
- Attribuez la Silver policy au disque du système d’exploitation :
la Silver policy est configurée pour n’utiliser que des HDDs. - Attribuez la Gold policy au disque de données :
la Gold policy utilise uniquement des SSDs.
¶ À propos des composants de Storage Policy
Une VM storage policy peut inclure un ou plusieurs blocs de construction réutilisables et interchangeables, appelés composants de Storage Policy, en utilisant les services de stockage basés sur VAIO.
Chaque composant décrit un type de service fourni par un fournisseur de stockage.
Les services varient selon le fournisseur de stockage utilisé, mais ils appartiennent généralement à l’une des catégories suivantes :
- Réplication
- Chiffrement
- Mise en cache (Caching)
- Contrôle des entrées/sorties de stockage (Storage I/O Control)
Le fournisseur de services peut être un système de stockage, un filtre d’E/S (I/O filter) ou une autre entité.
¶ Exemple de composant de Storage Policy
Lorsque vous créez un composant de Storage Policy, vous définissez les règles pour un type et un niveau de service spécifiques.
Vous devez ajouter le composant à la Storage Policy et attribuer la policy à la VM.
Vous ne pouvez pas attribuer un composant directement à une VM ou à un disque virtuel.
Vous pouvez définir les composants de policy à l’avance et les associer à plusieurs Storage Policies de VM.
¶ QCM : Storage Policy Rules
Laquelle des affirmations suivantes décrit le mieux les Storage Policy Rules dans vSphere ?
☐ Les Storage Policy Rules définissent les autorisations d’accès pour les administrateurs vSphere.
☐ Les Storage Policy Rules déterminent les caractéristiques de performance et les paramètres de disponibilité du stockage des machines virtuelles.
☐ Les Storage Policy Rules spécifient les paramètres de réplication pour les machines virtuelles.
☐ Les Storage Policy Rules définissent les politiques de sauvegarde et de restauration des données des machines virtuelles.
¶ Réponses : Storage Policy Rules
Laquelle des affirmations suivantes décrit le mieux les Storage Policy Rules dans vSphere ?
☐ Les Storage Policy Rules définissent les autorisations d’accès pour les administrateurs vSphere.
✓ Les Storage Policy Rules déterminent les caractéristiques de performance et les paramètres de disponibilité du stockage des machines virtuelles.
☐ Les Storage Policy Rules spécifient les paramètres de réplication pour les machines virtuelles.
☐ Les Storage Policy Rules définissent les politiques de sauvegarde et de restauration pour les données des machines virtuelles.
¶ Revue des objectifs d’apprentissage
- Décrire la gestion basée sur les Storage Policies
- Identifier les catégories de règles de Storage Policy
¶ Leçon 8 : Utilisation des stratégies de stockage des machines virtuelles (VM Storage Policies)
¶ Objectifs d’apprentissage
- Créer des stratégies de stockage pour machines virtuelles (VM storage policies)
- Utiliser les stratégies de stockage des VM pour créer un stockage à plusieurs niveaux (tiered storage)
¶ Création et gestion des stratégies de stockage
Le processus de création et de gestion des stratégies de stockage pour les datastores NFS/VMFS (sans fournisseur VASA) comprend généralement plusieurs étapes :
- Configurer le stockage à utiliser pour les stratégies de stockage.
- Créer les composants de la stratégie de stockage.
- Créer les stratégies de stockage des VM.
- Appliquer la stratégie de stockage à la VM.
- Vérifier la conformité de la VM avec la stratégie de stockage.
¶ Étape 1 : Configuration du stockage à utiliser pour les stratégies de stockage
Pour les entités représentées par des fournisseurs de stockage, le fournisseur approprié doit être enregistré :
- Les entités de fournisseurs de stockage incluent vSAN, vSphere Virtual Volumes et I/O Filters.
- Certains fournisseurs s’enregistrent automatiquement (self-registered). D’autres doivent être enregistrés manuellement.
Pour les datastores qui ne sont pas représentés par des fournisseurs de stockage, il faut créer des balises de datastore (tags) :
- Utilisez des balises pour indiquer une propriété qui n’est pas communiquée par les fournisseurs de stockage, par exemple la localisation géographique ou le groupe administratif.
Lorsque vous créez des stratégies de stockage, le vSphere Client affiche les informations issues de la configuration des datastores et des services de données présents dans votre environnement.
Ces informations sont obtenues à partir des fournisseurs de stockage et des balises de datastore.
¶ Étape 2 : Création des composants de stratégie de stockage
Vous définissez les composants de stratégie de stockage à l’avance afin de pouvoir les utiliser lorsque vous créez une stratégie de stockage.
vCenter fournit plusieurs composants intégrés de stratégie de stockage, notamment pour le chiffrement (encryption), le contrôle d’E/S de stockage (Storage I/O Control)
¶ Étape 3 : Création des stratégies de stockage pour machines virtuelles (VM Storage Policies)
Lorsque vous créez une stratégie de stockage, vous devez sélectionner la structure de la stratégie :
- Host based services (services basés sur l’hôte) :
Définissent les règles permettant d’activer et de configurer les services de données fournis par votre hôte via VAIO (vSphere APIs for I/O Filters).
Ces services peuvent inclure le chiffrement, le contrôle d’E/S ou la mise en cache. - Datastore specific rules (règles spécifiques au datastore) :
Décrivent les exigences ou services associés à un type de stockage particulier à l’aide de VASA (vSphere APIs for Storage Awareness) et de balises (tags).
¶ Exemple : Création d’une stratégie de stockage Silver Tier
Dans cet exemple, vous créez une stratégie de stockage appelée Silver Tier Policy afin de mettre en œuvre un stockage hiérarchisé (tiered storage) dans votre environnement.
Le stockage hiérarchisé permet de répondre à différentes exigences de stockage en créant plusieurs niveaux de stockage avec des degrés variables de performance, de fiabilité et de coût, selon les besoins de charge de travail des applications.
La Silver Tier Policy utilise une règle d’attribution basée sur des balises (tag-based placement rule).
La Silver Tier Policy est configurée pour correspondre à tous les datastores marqués comme Silver Tier.
Vous sélectionnez la catégorie de balises Storage Tier, puis la balise Silver Tier.
Le panneau de compatibilité du stockage (Storage compatibility) répertorie les datastores compatibles avec la Silver Tier Policy.
¶ Étape 4 : Application de la stratégie de stockage à la machine virtuelle (VM)
Après avoir créé la stratégie de stockage, vous pouvez l’attribuer à une machine virtuelle (VM) lors de la création, du déploiement ou du clonage d’une VM, ou encore lors de la migration d’une VM vers un nouveau datastore.
Lorsque vous assignez la Silver Tier Policy à une VM, une liste des datastores compatibles s’affiche.
Dans cet exemple, un seul datastore est compatible : ICM-Datastore.
Lorsque vous sélectionnez une stratégie de stockage pour VM, le vSphere Client affiche les datastores compatibles avec les capacités de cette stratégie.
Vous pouvez sélectionner un datastore ou un cluster de datastores dans la liste.
Si vous sélectionnez un datastore qui ne correspond pas à la stratégie de stockage, le vSphere Client indique que la VM utilise un stockage non conforme.
¶ Étape 5 : Vérification de la conformité de la stratégie de stockage de la VM
Vous pouvez vérifier si les machines virtuelles (VM) utilisent des datastores conformes à la stratégie de stockage.
Vous pouvez utiliser les stratégies de stockage pour VM lors de la gestion continue des machines virtuelles.
Vous pouvez vérifier périodiquement si une VM a été migrée vers un stockage inapproprié ou créée sur un stockage non conforme, ce qui pourrait la rendre non conforme à la stratégie.
Vous pouvez également utiliser les informations de stockage pour surveiller l’état et l’utilisation du stockage et signaler les cas où le stockage d’une VM devient non conforme.
¶ Lab 11 : Utilisation du stockage basé sur des stratégies
Utilisez le stockage basé sur des stratégies pour créer un stockage hiérarchisé pour un datastore VMFS sans fournisseur VASA :
- Ajouter des datastores à utiliser pour le stockage basé sur des stratégies.
- Utiliser vSphere Storage vMotion pour migrer le stockage d’une VM.
- Configurer des tags de stockage.
- Créer des stratégies de stockage de VM.
- Attribuer des stratégies de stockage aux VM.
Retrouvez le lien du Lab en cliquant ici : Lab 11 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Créer des stratégies de stockage de VM.
- Utiliser des stratégies de stockage de VM pour créer un stockage hiérarchisé.
¶ Leçon 9 : Stratégies de stockage pour vSAN
¶ Objectifs d’apprentissage
- Créer des stratégies de stockage vSAN
¶ Fournisseurs de stockage vSAN
Le datastore vSAN est représenté par un fournisseur de stockage.
Grâce à ce fournisseur, le datastore vSAN publie ses capacités, ses services de données et d’autres caractéristiques dans le client vSphere.
Vous utilisez ces caractéristiques pour définir des règles de placement basées sur les capacités pour vos stratégies de stockage.
Les fournisseurs de stockage vSAN signalent à vCenter un ensemble de capacités de stockage sous-jacentes.
Ils communiquent également avec la couche vSAN afin de transmettre les exigences de stockage des machines virtuelles (VM).
¶ Stratégies de stockage vSAN
Vous pouvez créer plusieurs stratégies de stockage de machines virtuelles (VM) pour un seul datastore vSAN :
- vSAN possède une stratégie de stockage par défaut pour les VM.
- Vous pouvez créer des stratégies de stockage personnalisées qui utilisent les capacités de vSAN.
- La stratégie de stockage vSAN par défaut est utilisée, sauf si vous en sélectionnez une autre.
- Vous utilisez le client vSphere pour afficher, créer et modifier les stratégies.
Les VM déployées sur des datastores vSAN se voient attribuer au moins une stratégie de stockage VM.
Si aucune stratégie de stockage n’est attribuée à la VM lors de son approvisionnement, une stratégie de stockage par défaut du datastore est automatiquement appliquée à cette VM.
¶ Création de stratégies de stockage vSAN
Pour créer une stratégie de stockage vSAN, vous devez sélectionner des règles pour le type de stockage vSAN.
¶ Capacités vSAN
Vous définissez l’ensemble des règles ou des capacités.
Dans l’onglet Availability (Disponibilité), vous pouvez définir la manière dont les données sont protégées à l’intérieur d’un cluster à un seul site ou d’un cluster étendu.
Dans l’onglet Advanced Policy Rules (Règles de stratégie avancée), vous pouvez configurer une ou plusieurs options avancées de vSAN.
Dans l’onglet Tags (Étiquettes), vous pouvez créer une règle basée sur une étiquette qui utilise le stockage associé à une certaine étiquette.
Par exemple, vous pouvez utiliser des étiquettes pour créer des capacités de stockage définies par l’utilisateur et les référencer lors de la définition d’une stratégie de stockage pour une machine virtuelle.
Pour plus d’informations sur les options avancées de vSAN, consultez le guide :
Administering VMware vSAN à l’adresse : https://docs.vmware.com/en/VMware-vSphere/8.0/vsan-80-administration-guide.pdf
¶ Lab 12 : Création de stratégies de stockage vSAN
Créez et examinez les stratégies de stockage vSAN :
- Examiner la stratégie de stockage par défaut
- Créer une stratégie personnalisée sans tolérance de panne
- Attribuer la stratégie personnalisée à une machine virtuelle
- Rendre la machine virtuelle conforme
Retrouvez le lien du Lab en cliquant ici : Lab 12 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Créer des stratégies de stockage vSAN
¶ Leçon 10 : Stratégies de stockage pour les volumes virtuels vSphere
¶ Objectifs d’apprentissage
- Identifier les composants de l’architecture des volumes virtuels vSphere
- Expliquer l’ensemble de règles permettant de créer des stratégies de stockage pour les volumes virtuels vSphere
¶ À propos des volumes virtuels vSphere
Avec les volumes virtuels vSphere (vSphere Virtual Volumes), les conteneurs de stockage remplacent les volumes de stockage traditionnels basés sur des LUN ou des partages NFS.
Traditionnellement, les baies de stockage fournissaient des services tels que la réplication, la déduplication et le chiffrement au niveau des LUN ou des partages NFS (c’est-à-dire au niveau du datastore VMFS ou NFS).
Les volumes virtuels vSphere permettent d’appliquer ces fonctionnalités au niveau des machines virtuelles individuelles (VMs) et de leurs disques virtuels.
La fonctionnalité des volumes virtuels vSphere modifie le paradigme de gestion du stockage :
elle passe de la gestion de l’espace à l’intérieur des datastores à la gestion d’objets de stockage abstraits gérés directement par les baies de stockage.
Traditionnellement, la gestion du stockage dans vSphere utilise une approche centrée sur le datastore.
Avec cette approche, les administrateurs de stockage et les administrateurs vSphere discutent à l’avance des besoins de stockage sous-jacents pour les machines virtuelles (VMs).
L’administrateur de stockage configure des LUNs ou des partages NFS et les présente aux hôtes ESXi.
L’administrateur vSphere crée ensuite des datastores à partir de ces LUNs ou partages NFS et les utilise comme stockage pour les VMs.
En général, le datastore représente le plus bas niveau auquel la gestion des données s’effectue du point de vue du stockage.
Cependant, un seul datastore peut contenir plusieurs VMs ayant des exigences différentes.
Avec cette approche traditionnelle, il est difficile de différencier les besoins de stockage par VM.
Grâce aux vSphere Virtual Volumes, vous pouvez différencier les services de stockage des VMs selon les applications, en adoptant une nouvelle approche de gestion du stockage.
Les vSphere Virtual Volumes prennent en charge les protocoles Fibre Channel (FC), FCoE, iSCSI et NFS.
¶ Architecture des volumes virtuels vSphere
L’architecture des vSphere Virtual Volumes est un cadre d’intégration et de gestion qui virtualise les baies de stockage, permettant un modèle d’exploitation plus efficace, optimisé pour les environnements virtualisés et centré sur les applications plutôt que sur l’infrastructure.
Les composants suivants constituent l’architecture des volumes virtuels vSphere :
- Fournisseurs de stockage vSphere Virtual Volumes
- Points de terminaison de protocole
- Conteneurs de stockage
- Datastores de volumes virtuels
- Volumes virtuels
¶ Fournisseurs de stockage vSphere Virtual Volumes
Un fournisseur de stockage vSphere Virtual Volumes est un composant logiciel qui assure la médiation de la communication entre vSphere et un système de stockage.
Un fournisseur de stockage vSphere Virtual Volumes est implémenté via l’API vSphere pour la gestion du stockage (vSphere API for Storage Awareness — VASA).
Il est utilisé pour gérer tous les aspects du stockage vSphere Virtual Volumes.
Ce fournisseur de stockage s’intègre au service de surveillance du stockage (Storage Monitoring Service), avec vSphere, afin de communiquer avec vCenter Server et les hôtes ESXi.
Le fournisseur de stockage transmet les exigences de stockage des VMs — définies dans une stratégie de stockage (storage policy) — à la couche de stockage.
De cette manière, un volume virtuel créé au niveau du stockage répond automatiquement aux exigences spécifiées dans la stratégie.
En général, les fournisseurs de stockage sont fournis par les fabricants et peuvent s’intégrer à vSphere tout en prenant en charge les volumes virtuels.
Chaque fournisseur de stockage doit être certifié par VMware et déployé correctement.
Pour plus d’informations sur le déploiement du fournisseur de stockage vSphere Virtual Volumes, il est recommandé de contacter votre fournisseur de stockage.
Pour plus d’informations sur les partenaires de stockage vSphere Virtual Volumes, consultez la page produit officielle de VMware : http://www.vmware.com/products/vsphere/features/virtual-volumes.html
¶ Points de terminaison de protocole (Protocol Endpoints)
ESXi utilise des points de terminaison de protocole pour établir un chemin de données à la demande entre les machines virtuelles (VMs) et leurs volumes virtuels respectifs.
Les points de terminaison de protocole sont configurés sur le système de stockage, et peuvent inclure un ou plusieurs points par conteneur de stockage.
Chaque volume virtuel est lié à un point de terminaison de protocole spécifique.
Un seul point de terminaison de protocole peut se connecter à plusieurs volumes virtuels.
Les points de terminaison de protocole prennent en charge les protocoles suivants :
SCSI (iSCSI / FC / FCoE) et NFS.
Bien que les systèmes de stockage gèrent tous les aspects des volumes virtuels,
les hôtes ESXi n’ont pas d’accès direct aux volumes virtuels du côté du stockage.
À la place, les hôtes ESXi utilisent un proxy logique d’E/S, appelé point de terminaison de protocole,
pour communiquer avec les volumes virtuels et les fichiers de disques virtuels encapsulés dans ces volumes.
Lorsque le protocole basé sur SCSI est utilisé,
le point de terminaison de protocole représente un LUN défini par un nom mondial T10 (T10-based LUN World Wide Name).
Pour le protocole NFS, le point de terminaison de protocole représente un point de montage,
tel qu’une adresse IP ou un nom DNS, associé à un nom de partage.
Lorsqu’une VM effectue une opération d’E/S,
le point de terminaison de protocole oriente l’E/S vers le volume virtuel approprié.
En général, un système de stockage nécessite seulement quelques points de terminaison de protocole.
L’administrateur du stockage configure les points de terminaison de protocole.
Ces points font partie du stockage physique et sont exportés avec les conteneurs de stockage associés via le fournisseur de stockage.
Après avoir mappé un conteneur de stockage à un datastore de volumes virtuels,
les points de terminaison de protocole sont découverts automatiquement par ESXi
et apparaissent dans le vSphere Client.
Les points de terminaison de protocole peuvent également être découverts lors d’un rescannage du stockage.
¶ Conteneurs de stockage et datastores de volumes virtuels vSphere
Les volumes virtuels résident dans un conteneur de stockage.
Un conteneur de stockage est une construction logique qui peut englober la capacité d’une baie de stockage entière et regrouper logiquement les volumes virtuels selon des besoins de gestion et d’administration.
Par exemple, un conteneur de stockage peut contenir tous les volumes virtuels d’une organisation donnée.
Un datastore de volumes virtuels est mappé à un conteneur de stockage spécifique.
Contrairement au stockage vSphere traditionnel basé sur LUN ou NFS,
la fonctionnalité vSphere Virtual Volumes n’exige pas de volumes préconfigurés sur le système de stockage.
À la place, vSphere Virtual Volumes utilise un conteneur de stockage,
qui représente soit un pool de capacité brute, soit une agrégation de fonctionnalités de stockage que le système de stockage peut fournir aux volumes virtuels.
En général, c’est l’administrateur du stockage (du côté du système de stockage) qui définit les conteneurs de stockage.
Le nombre et la capacité de ces conteneurs dépendent du fournisseur et de la mise en œuvre spécifique,
mais chaque système de stockage doit contenir au moins un conteneur.
Après que le vCenter Server a découvert les conteneurs de stockage présentés par les systèmes de stockage,
vous devez associer (mapper) un conteneur de stockage à un datastore de volumes virtuels.
Le datastore de volumes virtuels que vous créez correspond directement au conteneur de stockage spécifique
et devient la représentation de ce conteneur dans vCenter Server et dans le client vSphere.
¶ Volumes virtuels (Virtual Volumes)
Les volumes virtuels sont des objets stockés nativement à l’intérieur d’un système de stockage connecté via un réseau Ethernet ou un réseau Fibre Channel.
Les volumes virtuels ne sont pas préconfigurés, mais sont créés automatiquement par la baie de stockage lorsque vous effectuez des opérations de gestion de machines virtuelles.
Les volumes virtuels sont des encapsulations de fichiers de machines virtuelles (VM), de disques virtuels et de leurs dérivés.
Les volumes virtuels sont exportés comme des objets par un système de stockage compatible et sont hébergés sur des périphériques de stockage au sein de la baie.
En général, chaque volume virtuel est identifié par un GUID (Global Unique Identifier) unique.
¶ Association des fichiers de VM aux volumes virtuels
Le système de stockage crée des volumes virtuels pour les éléments principaux qui composent la machine virtuelle (VM) :
- Les volumes virtuels de configuration, représentant les disques virtuels.
- Les volumes virtuels de données, contenant les fichiers de configuration d’une machine virtuelle.
Des volumes virtuels supplémentaires peuvent être créés pour d’autres composants de la VM, tels que les instantanés (snapshots) et les fichiers d’échange (swap files).
Les vSphere Virtual Volumes associent directement les objets aux volumes virtuels.
vSphere peut ainsi déléguer les opérations de stockage intensives, telles que la prise de snapshots, le clonage et la réplication, au système de stockage.
Un volume virtuel de données correspond directement à chaque disque virtuel (fichier -flat.vmdk). Comme les fichiers de disque virtuel dans les datastores traditionnels, les volumes virtuels sont présentés aux VMs sous forme de disques SCSI, vSATA ou vNVMe.
Un volume virtuel de configuration, ou répertoire personnel, représente un petit répertoire contenant les fichiers de métadonnées d’une VM.
Ces fichiers de métadonnées incluent un fichier .vmx (fichier de configuration de la VM), des fichiers de descripteurs de disque virtuel, des fichiers journaux, etc.
Le volume virtuel de configuration est formaté avec un système de fichiers lorsqu’ESXi utilise le protocole SCSI pour se connecter au stockage, les volumes de configuration sont formatés avec VMFS. Avec le protocole NFS, les volumes de configuration sont présentés comme un répertoire NFS.
Des volumes virtuels supplémentaires peuvent être créés pour d’autres composants de VM ou dérivés de disques virtuels, tels que les clones, snapshots et réplicas.
Ces volumes supplémentaires incluent un volume virtuel d’échange (swap) pour contenir les fichiers d’échange de la VM, un volume virtuel de mémoire pour contenir le contenu de la mémoire d’une VM lors d’un snapshot ou lorsqu’une VM est suspendue.
¶ Réplication des volumes virtuels vSphere
Les vSphere Virtual Volumes prennent en charge la réplication.
Grâce à cette fonctionnalité, vous pouvez déléguer la réplication des machines virtuelles (VMs) à votre baie de stockage et exploiter toutes les capacités de réplication offertes par celle-ci.
Propriétés de la réplication des vSphere Virtual Volumes :
- Disponible avec l’API vSphere for Storage Awareness version 3.0
- Compatible avec les hôtes ESXi à partir de la version 6.5
- Nécessite que la baie de stockage soit compatible avec la réplication
Implémentation de la réplication des vSphere Virtual Volumes
L’implémentation de la réplication dépend du modèle de votre baie de stockage et peut varier selon les fournisseurs.
Cependant, les exigences générales suivantes s’appliquent à tous :
- Les baies de stockage utilisées pour la réplication doivent être compatibles avec les vSphere Virtual Volumes.
- Les baies doivent s’intégrer avec la version 3.0 ou ultérieure du fournisseur de stockage (VASA), compatible avec la réplication des vSphere Virtual Volumes.
- Les baies doivent être réplicables et configurées pour utiliser les mécanismes de réplication fournis par le fournisseur.
Les configurations typiques impliquent généralement une ou deux cibles de réplication.
Toute configuration requise — comme l’appairage du site répliqué et du site cible — doit également être effectuée par le système de stockage. - Lorsque cela s’applique, les groupes de réplication et les domaines de tolérance aux pannes pour les volumes virtuels doivent être préconfigurés dans le système de stockage.
¶ Politiques de stockage des volumes virtuels
Une machine virtuelle (VM) qui s’exécute sur un datastore de volumes virtuels nécessite une politique de stockage VM.
Si vous ne créez pas de politique de stockage VM compatible avec le datastore de volumes virtuels, le système utilise la politique par défaut "No Requirements" (aucune exigence) :
- Cette politique générique de volumes virtuels ne contient aucune règle ni spécification de stockage.
- Les baies de stockage peuvent déterminer le placement optimal des objets de la machine virtuelle.
¶ Exemples de politiques de stockage des volumes virtuels
En utilisant différents volumes virtuels pour les différents composants d’une VM, vous pouvez appliquer des politiques de stockage spécifiques à des niveaux détaillés.
Par exemple :
- Un volume virtuel contenant un disque de données virtuel peut bénéficier d’un ensemble de services plus complet que le volume virtuel utilisé pour le disque d’amorçage (boot disk).
- Un volume virtuel de snapshot (instantané) peut utiliser un niveau de stockage différent par rapport à un volume virtuel de données.
- Si les informations sur les capacités de réplication de la baie de stockage des volumes virtuels sont présentées par le fournisseur VASA de la baie, vous pouvez activer la réplication pour vos machines virtuelles critiques pour l’entreprise.
¶ Création de politiques de stockage pour les volumes virtuels
Une politique de stockage des volumes virtuels peut inclure des règles de service basées sur l’hôte, des règles VAIO (vSphere APIs for I/O Filtering) et des règles spécifiques au datastore.
Cette exemple montre comment définir des règles spécifiques au datastore pour un stockage de volumes virtuels (ici, EMC Unity VVOL).
¶ QCM: Displaying Storage Capabilities
Cet exercice demande de vérifier pourquoi les capacités de votre baie de stockage de volumes virtuels ne s’affichent pas dans l’interface du vSphere Client.
Les éléments à vérifier sont :
☐ Que les tags pour la baie de stockage de volumes virtuels sont créés.
☐ Que les composants de la politique de stockage sont préconfigurés.
☐ Que le fournisseur de stockage des volumes virtuels (VASA provider) est bien enregistré auprès de vCenter Server.
☐ Que la politique “VVol No Requirements” n’a pas été supprimée.
¶ Réponses: Displaying Storage Capabilities
Si les capacités de votre baie de stockage de volumes virtuels ne s’affichent pas dans l’interface de stratégie de stockage du vSphere Client, que devez-vous vérifier ?
☐ Que les tags sont créés pour la baie de stockage de volumes virtuels
☐ Que les composants de la stratégie de stockage des volumes virtuels sont préconfigurés
✓ Que le fournisseur de stockage des volumes virtuels est enregistré auprès du vCenter Server
☐ Que la politique de stockage VVol No Requirements n’a pas été supprimée
¶ Revue des objectifs d’apprentissage
- Reconnaître les composants de l’architecture vSphere Virtual Volumes.
- Expliquer l’ensemble des règles nécessaires à la création des vSphere Virtual Volumes storage policies.
¶ Leçon 11 : Contrôle d’E/S de stockage
¶ Objectifs d’apprentissage
- Décrire comment le contrôle d’E/S de stockage équilibre la charge d’E/S sur un datastore
- Configurer le contrôle d’E/S de stockage
¶ À propos du contrôle d’E/S de stockage
Le contrôle d’E/S de stockage fournit une priorisation des E/S de stockage à l’échelle du cluster, ce qui permet une meilleure consolidation des charges de travail et aide à réduire les coûts supplémentaires associés à la surprovisionnement.
Le contrôle d’E/S de stockage étend les concepts de parts, de limites et de réservations pour gérer les ressources d’E/S de stockage.
Le contrôle d’E/S de stockage est un planificateur d’opérations d’E/S par seconde (IOPS) à parts proportionnelles qui, en cas de contention, limite les IOPS.
Vous pouvez contrôler la quantité d’E/S de stockage allouée aux machines virtuelles pendant les périodes de congestion d’E/S.
Le contrôle d’E/S garantit que les machines virtuelles les plus importantes obtiennent la priorité sur les moins importantes pour l’allocation des ressources d’E/S.
Pour plus d’informations, consultez Managing Storage I/O Resources à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-resource-management/GUID-7686FEC3-1FAC-4DA7-B698-B808C44E5E96.html
¶ Parts et limites des ressources du contrôle d’E/S de stockage
Les Storage I/O shares sont similaires aux shares utilisées pour l’allocation des ressources de mémoire et de processeur.
Les shares sont généralement définies comme High, Normal ou Low, et ces valeurs spécifient des valeurs de share avec un rapport de 4:2:1 respectivement.
Vous pouvez également sélectionner Custom pour attribuer un nombre spécifique de shares (ce qui exprime un poids proportionnel) à chaque machine virtuelle.
Ces shares représentent l’importance relative d’une machine virtuelle en ce qui concerne la répartition des ressources d’E/S de stockage.
En cas de contention des ressources, les machines virtuelles avec des valeurs de share plus élevées ont un meilleur accès à la baie de stockage.
Lorsque vous allouez des ressources d’E/S de stockage, vous pouvez limiter le nombre d’IOPS autorisées pour une machine virtuelle.
Par défaut, les IOPS sont illimitées.
¶ Activation du contrôle d’E/S de stockage
Avec le Storage I/O Control, vous pouvez vous assurer que les machines virtuelles les plus importantes obtiennent le niveau approprié de ressources d’E/S, même pendant les périodes de congestion.
Le Storage I/O Control est désactivé par défaut.
Lorsqu’il est activé sur un datastore, toutes les machines virtuelles ont par défaut 1 000 disk shares, aucune limite d’IOPS et aucune réservation.
Vous définissez le nombre de shares, une limite supérieure pour les IOPS, et le nombre d’IOPS réservées pour les machines virtuelles en appliquant une politique de stockage.
Le Storage I/O Control offre des fonctionnalités de qualité de service (QoS) pour les E/S de stockage sous la forme de shares, de limites et de réservations, appliquées à toutes les machines virtuelles accédant à un datastore, quel que soit l’hôte sur lequel elles s’exécutent.
Lorsque vous activez le Storage I/O Control sur un datastore, ESXi commence à surveiller la latence du périphérique observée par les hôtes lors de la communication avec ce datastore.
Lorsque la latence dépasse un seuil défini, le datastore est considéré comme congestionné, et chaque machine virtuelle qui y accède se voit attribuer des ressources d’E/S proportionnellement à ses shares.
L’exemple suivant illustre deux machines virtuelles exécutant Iometer.
Ce tableau compare VM1 et VM2 en utilisant les paramètres par défaut (1 000 shares et aucune limite d’IOPS). Aucune limite ni réservation n’est définie.
| IOPS | Latence Iometer | |
|---|---|---|
| VM1 | 1 500 | 20 ms |
| VM2 | 1 500 | 21 ms |
Ce tableau compare VM1 et VM2.
VM1 utilise toujours 1 000 shares tandis que VM2 utilise 2 000 shares.
Des shares ou des limites peuvent être définies, mais aucune réservation n’est appliquée.
| IOPS | Latence Iometer | |
|---|---|---|
| VM1 | 1 080 | 31 ms |
| VM2 | 1 900 | 16 ms |
Lorsque vous allouez des ressources d’E/S de stockage, vous pouvez limiter les IOPS autorisées pour une machine virtuelle.
Par défaut, le nombre d’IOPS autorisées pour une machine virtuelle est illimité.
Si la limite que vous souhaitez définir pour une VM est exprimée en mégaoctets par seconde plutôt qu’en IOPS, vous pouvez convertir les mégaoctets par seconde en IOPS en fonction de la taille typique d’E/S pour cette machine virtuelle.
Par exemple, une application de sauvegarde a généralement une taille d’E/S de 64 KB.
Pour limiter une application de sauvegarde à 10 MB/s, définissez une limite de 160 IOPS :
10 MB/s ÷ 64 KB (taille d’E/S) = 160 IOPS.
Les machines virtuelles VM1 et VM2 exécutent un générateur de charge d’E/S appelé Iometer afin de générer suffisamment de trafic pour provoquer une contention.
Chaque machine virtuelle s’exécute sur un hôte différent, mais toutes deux exécutent le même type de charge de travail, à savoir des lectures aléatoires de 16 KB.
Les shares de VM2 sont définies pour être deux fois plus nombreuses que celles de VM1, ce qui implique que VM2 est plus importante que VM1.
Avec le Storage I/O Control désactivé, les IOPS et la latence d’E/S obtenues par chaque machine virtuelle sont identiques.
Cependant, lorsque le Storage I/O Control est activé, les IOPS obtenues par la machine virtuelle ayant davantage de shares (VM2) sont supérieures à celles de VM1.
Cet exemple suppose que chaque machine virtuelle exécute une charge suffisante pour provoquer un goulet d’étranglement sur le datastore.
¶ Surveillance de la latence
Lorsque vous activez Storage I/O Control, ESXi surveille la latence du datastore et régule la charge d’E/S si la latence moyenne du datastore dépasse le seuil défini.
Par défaut, Storage I/O Control utilise un modèle basé sur un injecteur (injector-based model) pour détecter automatiquement le seuil de latence.
L’avantage de ce modèle basé sur un injecteur est que Storage I/O Control détermine le meilleur seuil pour un datastore.
Lorsque Storage I/O Control est activé, les statistiques de performance sont collectées et utilisées pour améliorer le comportement de vSphere Storage DRS.
Storage I/O Control détermine automatiquement le seuil de latence optimal à l’aide de modèles basés sur un injecteur.
Cependant, vous pouvez également remplacer ce seuil en définissant une valeur de latence spécifique.
Ce paramètre de latence par défaut peut convenir à certains périphériques de stockage, mais d’autres peuvent atteindre leur seuil de latence bien avant ou bien après la valeur par défaut.
¶ Détection automatique du seuil
Avec le modèle basé sur un injecteur, Storage I/O Control détermine le débit maximal (peak throughput) du périphérique de stockage et fixe le seuil à 90 % de cette valeur :
- La détection automatique du seuil fonctionne bien lorsqu’une gamme de baies de disques et de datastores est configurée.
- Le seuil varie en fonction des performances de chaque datastore.
Vous pouvez également définir manuellement la valeur du seuil pour un datastore.
Si cette option est sélectionnée, la valeur de latence par défaut est fixée à 30 ms.
Le modèle d’injecteur d’E/S (I/O injector model) détermine le débit maximal (peak throughput) d’un datastore.
La mesure du débit maximal obtenu peut ensuite être utilisée pour déterminer la latence maximale (peak latency) d’un datastore.
¶ Composants de stratégie de stockage pour Storage I/O Control
Introduit dans vSphere 6.5, Storage I/O Control est implémenté en tant que filtre d’E/S (I/O filter). Le fournisseur IOFilter annonce les fonctionnalités Storage I/O Control à vCenter.
Les composants intégrés de stratégie de stockage définissent les capacités de Storage I/O Control.
¶ Configuration de Storage I/O Control
Vous pouvez utiliser un composant de stratégie de stockage pour Storage I/O Control.
Ou bien, vous pouvez créer un composant de stratégie de stockage personnalisé, qui définit la limite IOPS, la réservation IOPS et les IOPS shares.
Vous utilisez ensuite ce composant dans la stratégie de stockage et assignez cette stratégie à une machine virtuelle (VM).
¶ Exigences de Storage I/O Control
Storage I/O Control a plusieurs exigences :
-
Storage I/O Control est pris en charge uniquement sur les datastores gérés par un seul système vCenter.
-
Storage I/O Control est pris en charge pour les stockages Fibre Channel, iSCSI, VMFS et NFS3 :
- Le Raw Device Mapping n’est pas pris en charge.
- Les datastores vSAN et virtual volumes ne sont pas pris en charge.
-
Storage I/O Control ne prend pas en charge les datastores avec plusieurs extents.
-
Si vos datastores sont situés sur des baies de stockage disposant de fonctionnalités de tiering automatique, votre baie doit être certifiée compatible avec Storage I/O Control.
Le tiering automatique est la capacité d’une baie (ou d’un groupe de baies) à migrer des LUNs, des volumes virtuels ou des parties de LUNs/volumes virtuels vers différents types de supports de stockage (SSD, Fibre Channel, SAS, SATA, etc.) en fonction des politiques définies par l’utilisateur et des modèles d’E/S actuels.
Aucune certification spéciale n’est requise pour les baies qui ne disposent pas de ces fonctions automatiques ou de tiering, y compris celles permettant la migration manuelle des données entre différents types de supports.
Pour vérifier que votre baie de stockage à tiering automatique est certifiée compatible avec Storage I/O Control, consultez le VMware Compatibility Guide à l’adresse suivante : http://www.vmware.com/resources/compatibility
¶ Activité : Storage I/O Control
Sur un datastore avec Storage I/O Control activé, quelles étapes devez-vous suivre pour vous assurer que la machine virtuelle du magasin en ligne (Online Store VM) et celle du serveur de messagerie (Mail Server VM) disposent d’un IOPS plus élevé que les autres machines virtuelles pendant les périodes de contention ?
Les étapes suivantes décrivent une méthode permettant de s’assurer que la machine virtuelle du magasin en ligne (Online Store VM) et celle du serveur de messagerie (Mail Server VM) disposent d’un débit plus élevé que les autres machines virtuelles pendant les périodes de contention :
-
Créez une stratégie de stockage (storage policy) utilisant le composant de stratégie de stockage prédéfini appelé High IO Shares Allocation.
High IO Shares Allocation a une valeur de 2 000 disk shares. -
Attribuez la stratégie de stockage uniquement à la machine virtuelle du magasin en ligne (Online Store VM) et à celle du serveur de messagerie (Mail Server VM).
Toutes les autres machines virtuelles du datastore utilisent la valeur par défaut de 1 000 disk shares.
¶ Revue des objectifs d’apprentissage
- Décrire comment Storage I/O Control équilibre la charge d’E/S (I/O load) sur un datastore.
- Configurer Storage I/O Control.
¶ Leçon 12 : Clusters de datastores et vSphere Storage DRS
¶ Objectifs d’apprentissage
- Créer un cluster de datastores
- Configurer vSphere Storage DRS
- Expliquer comment Storage I/O Control et vSphere Storage DRS se complètent l’un l’autre
¶ À propos des clusters de datastores
Un cluster de datastores est un ensemble de datastores regroupés, mais qui fonctionnent comme des entités distinctes.
Lorsque vous activez un cluster de datastores avec vSphere Storage DRS, les datastores du cluster travaillent ensemble pour équilibrer la capacité et la latence d’E/S (I/O).
Le cluster de datastores agit comme un conteneur ou un dossier. Vous pouvez y stocker des datastores, mais ces derniers continuent à fonctionner comme des entités séparées.
Un cluster de datastores activé pour vSphere Storage DRS est un ensemble de datastores qui fonctionne comme une seule unité.
¶ Exigences relatives aux clusters de datastores
Les datastores et les hôtes associés à un cluster de datastores doivent répondre à certaines exigences pour pouvoir utiliser efficacement les fonctionnalités d’un cluster de datastores :
- Les clusters de datastores doivent contenir des datastores similaires ou interchangeables, avec les exceptions suivantes :
— Tous les datastores d’un cluster doivent être au même format, soit VMFS soit NFS.
— Les datastores vSAN et Virtual Volumes (vVols) ne sont pas pris en charge dans un cluster de datastores.
— Les datastores répliqués ne peuvent pas être combinés avec des datastores non répliqués dans le même cluster de datastores activé pour vSphere Storage DRS.
Cette exception s’applique uniquement aux baies de stockage qui ne prennent pas en charge l’API vSphere for Storage Awareness (VASA). - Les datastores partagés entre plusieurs data centers ne peuvent pas être inclus dans un cluster de datastores.
- Les datastores avec accélération matérielle activée ne doivent pas être inclus dans le même cluster que des datastores sans accélération matérielle.
Un cluster de datastores peut contenir un mélange de datastores de tailles et de capacités d’E/S différentes, ainsi que des datastores provenant de baies et de fournisseurs différents.
Cependant, les LUN ayant des caractéristiques de performance différentes peuvent causer des problèmes de performance.
vSphere Storage DRS ne peut pas déplacer des machines virtuelles entre des datastores NFS et VMFS.
¶ Relations entre cluster d’hôtes et cluster de datastores
Un cluster d’hôtes vSphere et un cluster de datastores peuvent interagir selon différentes relations :
- Un à un (One-to-One)
- Un à plusieurs (One-to-Many)
- Plusieurs à plusieurs (Many-to-Many)
Les clusters d’hôtes et les clusters de datastores peuvent coexister au sein de l’infrastructure virtuelle.
Un cluster d’hôtes est un cluster vSphere DRS ou un cluster vSphere HA.
L’équilibrage de charge assuré par vSphere DRS et vSphere Storage DRS peut avoir lieu simultanément vSphere DRS équilibre les machines virtuelles entre les hôtes en fonction de l’utilisation du processeur (CPU), de la mémoire, et de l’utilisation réseau (dans le cas où Network I/O Control version 3 est utilisé). vSphere Storage DRS équilibre la charge des machines virtuelles entre les datastores, en fonction de la capacité de stockage et des IOPS (opérations d’entrée/sortie par seconde).
Un hôte autonome (c’est-à-dire un hôte qui ne fait pas partie d’un cluster d’hôtes) peut également utiliser un cluster de datastores.
¶ Vue d’ensemble de vSphere Storage DRS
Avec vSphere Storage DRS, vous pouvez gérer les ressources agrégées d’un cluster de datastores de la manière suivante :
- Placement initial des machines virtuelles (VM) en fonction de la capacité de stockage et, éventuellement, de la latence d’E/S (I/O latency).
- Utilisation de vSphere Storage vMotion pour migrer les VM en fonction de la capacité de stockage et, éventuellement, de la latence d’E/S.
- Utilisation de règles d’affinité et d’anti-affinité pour régir l’emplacement des disques virtuels.
- Utilisation du mode de maintenance du datastore pour libérer une LUN contenant des fichiers de machines virtuelles.
vSphere Storage DRS peut être configuré pour fonctionner soit en mode manuel, soit en mode entièrement automatisé.
vSphere Storage DRS gère le placement des VM dans un cluster de datastores, en se basant sur l’utilisation de l’espace de stockage.
Il essaie de maintenir une utilisation équilibrée entre les différents datastores du cluster.
vSphere Storage DRS utilise vSphere Storage vMotion pour migrer les machines virtuelles afin de maintenir l’équilibre entre les datastores.
En option, l’utilisateur peut configurer vSphere Storage DRS pour équilibrer la latence d’E/S entre les membres du cluster de datastores, afin d’aider à atténuer les problèmes de performance causés par une latence élevée.
vSphere Storage DRS peut fonctionner selon deux modes :
- Mode manuel : présente des recommandations de migration et de placement à l’utilisateur, mais aucune action n’est effectuée tant que l’utilisateur n’a pas accepté la recommandation.
- Mode entièrement automatisé : gère automatiquement le placement initial et les migrations selon les conditions d’exécution.
¶ Placement initial du disque
Le placement initial se produit lorsque vSphere Storage DRS sélectionne un datastore dans un cluster de datastores sur lequel placer le disque d’une machine virtuelle (VM).
Lorsque des VM sont créées, clonées ou migrées, vous sélectionnez un cluster de datastores plutôt qu’un datastore unique.
vSphere Storage DRS choisit alors un datastore membre en fonction de la capacité de stockage et, éventuellement, de la charge d’IOPS.
Par défaut, les fichiers d’une VM sont placés sur le même datastore au sein du cluster de datastores.
Ce comportement peut être modifié en utilisant les règles d’anti-affinité de vSphere Storage DRS.
Lorsque qu’une VM est créée, clonée ou migrée, et que l’utilisateur sélectionne un cluster de datastores,
vSphere Storage DRS choisit un datastore membre dans le cluster en fonction de l’utilisation du stockage.
vSphere Storage DRS essaie de maintenir une utilisation équilibrée entre les datastores membres.
¶ Règles d’affinité vSphere Storage DRS
Vous pouvez créer des règles d’anti-affinité vSphere Storage DRS afin de contrôler quels disques virtuels ne doivent pas être placés sur le même datastore dans un cluster de datastores.
¶ Règle d’affinité Intra-VM VMDK (par défaut)
- Garde les disques virtuels d’une même machine virtuelle (VMDK) ensemble sur le même datastore.
- Maximise la disponibilité de la machine virtuelle lorsque tous les disques sont utilisés.
¶ Règle d’anti-affinité Intra-VM VMDK
- Garde les disques virtuels (VMDK) d’une machine virtuelle sur des datastores différents.
- Peut s’appliquer à tous ou à un sous-ensemble de VMDK.
¶ Règle d’anti-affinité inter-VM
- Garde les VM sur des datastores différents.
- Maximise la disponibilité d’un ensemble de VM redondantes.
Par défaut, tous les disques d’une VM peuvent se trouver sur le même datastore.
Cependant, un utilisateur peut souhaiter placer les disques virtuels sur des datastores différents.
Par exemple, il peut placer le disque système sur un datastore et les disques de données sur un autre.
Dans ce cas, l’utilisateur peut définir une règle d’anti-affinité VMDK, qui maintient les disques virtuels d’une VM sur des datastores distincts.
Les règles d’anti-affinité entre VM conservent les VM sur des datastores séparés.
Cette règle est utile lorsque des VM redondantes doivent toujours être disponibles.
¶ Recommandations de migration de stockage
vCenter affiche des recommandations de migration sur la page vSphere Storage DRS Recommendations pour les clusters de datastores configurés en mode manuel.
Les recommandations de migration sont exécutées dans les circonstances suivantes :
- Lorsque le seuil de latence d’E/S (I/O latency) est dépassé
- Lorsque le seuil d’utilisation de l’espace est dépassé
Si cette fonction est activée, l’historique de charge d’IOPS est vérifié toutes les huit heures par défaut.
vSphere Storage DRS sélectionne un datastore en fonction de son taux d’utilisation et, de manière optionnelle, de la latence d’E/S.
L’équilibrage de charge est basé sur la charge de travail IOPS, ce qui garantit qu’aucun datastore ne dépasse un certain niveau de latence d’E/S VMkernel.
Les recommandations de migration de stockage fonctionnent comme suit :
-
vSphere Storage DRS fournit autant de recommandations que nécessaire pour équilibrer
les ressources d’espace et, de manière optionnelle, les ressources IOPS du cluster de datastores. -
Les raisons de ces recommandations de migration incluent :
- L’équilibrage de l’utilisation de l’espace dans le datastore
- La réduction de la latence d’E/S du datastore
- L’équilibrage de la charge IOPS entre datastores
-
vSphere Storage DRS peut également formuler des recommandations obligatoires lorsque les conditions suivantes sont remplies :
- Un datastore est à court d’espace
- Les règles d’affinité ou d’anti-affinité de vSphere Storage DRS sont violées
- Un datastore entre en mode de maintenance
Afin d’obtenir un équilibre optimal des machines virtuelles (VM) à travers les datastores d’un cluster,
vSphere Storage DRS envisage également de déplacer les VM éteintes vers d’autres datastores.
¶ Détecteur de corrélation de datastores
La corrélation de datastores fait référence aux datastores créés sur le même ensemble physique de disques (spindles).
vSphere Storage DRS détecte la corrélation des datastores en effectuant les opérations suivantes :
- Mesure des performances individuelles des datastores
- Mesure des performances combinées des datastores
Si la latence augmente sur plusieurs datastores lorsqu’une charge est appliquée sur l’un d’eux, ces datastores sont considérés comme corrélés.
Les règles d’anti-affinité peuvent utiliser la détection de corrélation pour garantir que les VM ou disques virtuels se trouvent sur des disques physiques différents.
L’objectif de la corrélation de datastores est d’aider vSphere Storage DRS à déterminer où déplacer une machine virtuelle (VM).
Par exemple, il y a peu d’intérêt à déplacer une VM d’un datastore vers un autre si les deux reposent sur le même ensemble de disques physiques dans la baie de stockage.
Le détecteur de corrélation de datastores utilise un injecteur d’E/S (I/O injector) pour déterminer si la source et le datastore de destination utilisent les mêmes disques physiques en arrière-plan.
Le détecteur fonctionne en surveillant la charge sur un datastore et la latence sur un autre.
Si la latence augmente sur d’autres datastores lorsqu’une charge est appliquée sur un datastore, cela indique que les datastores sont corrélés.
Il peut également être utilisé pour les règles d’anti-affinité, garantissant que les VM et les disques virtuels ne sont pas seulement placés sur des datastores distincts, mais également sur des disques physiques distincts à l’arrière-plan.
La corrélation est déterminée par un processus d’arrière-plan de longue durée.
La corrélation des datastores est activée par défaut.
¶ Configuration des paramètres d’exécution de vSphere Storage DRS
Vous pouvez configurer les seuils (thresholds) de vSphere Storage DRS afin de déterminer à quel moment les migrations sont effectuées ou recommandées.
- Lorsque vous créez un datastore cluster, vous pouvez cocher ou décocher la case Enable I/O metric for SDRS recommendations pour activer ou désactiver l’utilisation des métriques IOPS dans les recommandations ou migrations automatiques.
- Lorsque vous activez l’équilibrage de charge I/O, la fonction Storage I/O Control est activée pour tous les datastores du cluster si elle ne l’était pas déjà.
- Lorsque cette option est désactivée, vous désactivez les fonctions suivantes :
- L’équilibrage de charge des IOPS entre les datastores du cluster.
- Le placement initial des disques virtuels basé sur la métrique IOPS. Seule la capacité d’espace est alors prise en compte lors des recommandations de placement et d’équilibrage.
- Les paramètres d’exécution (runtime settings) de vSphere Storage DRS incluent les options suivantes :
- I/O latency threshold : indique la latence d’E/S minimale pour chaque datastore, en dessous de laquelle les déplacements d’équilibrage de charge ne sont pas pris en compte.
Ce paramètre est applicable uniquement si la case Enable I/O metric for SDRS recommendations est cochée. - Space threshold : détermine les niveaux minimaux d’espace consommé et d’espace libre pour chaque datastore, servant de seuil de déclenchement pour une action (migration ou recommandation).
- I/O latency threshold : indique la latence d’E/S minimale pour chaque datastore, en dessous de laquelle les déplacements d’équilibrage de charge ne sont pas pris en compte.
¶ Mode de maintenance de vSphere Storage DRS
Avec le mode de maintenance de vSphere Storage DRS, vous pouvez retirer un datastore du service afin de l’entretenir.
Le mode de maintenance de vSphere Storage DRS évacue les machines virtuelles (VM) d’un datastore placé en mode de maintenance :
- Les VM enregistrées (qu’elles soient allumées ou éteintes) sont déplacées.
- Les modèles (templates), VM non enregistrées, images ISO et fichiers non liés aux machines virtuelles ne sont pas déplacés.
Avec vSphere Storage DRS, vous pouvez placer un datastore en mode de maintenance.
Le mode de maintenance Storage DRS est disponible uniquement pour les datastores qui appartiennent à un datastore cluster activé pour vSphere Storage DRS.
Les datastores autonomes ne peuvent pas être placés en mode de maintenance.
Le datastore n’entre pas en mode de maintenance tant que tous les fichiers présents sur le datastore n’ont pas été déplacés.
Vous devez déplacer manuellement ces fichiers afin que le datastore puisse entrer en mode de maintenance vSphere Storage DRS.
Si le datastore cluster est configuré en mode entièrement automatisé (fully automated mode), les VM sont automatiquement migrées vers d’autres datastores.
Si le datastore cluster est configuré en mode manuel (manual mode), des recommandations de migration apparaissent dans le vSphere Client. Les disques virtuels ne peuvent pas être déplacés tant que les recommandations n’ont pas été acceptées.
¶ Sauvegardes et vSphere Storage DRS
La sauvegarde des machines virtuelles (VM) peut ajouter de la latence à un datastore.
En utilisant le vSphere Client, vous pouvez planifier une tâche pour désactiver le comportement de vSphere Storage DRS pendant la sauvegarde.
Vous pouvez configurer des tâches planifiées afin de modifier le comportement de vSphere Storage DRS.
Ces tâches planifiées peuvent être utilisées pour adapter la configuration de vSphere Storage DRS du cluster de datastores à l’activité de l’entreprise.
Par exemple, si le cluster de datastores est configuré pour effectuer des migrations basées sur la latence d’E/S (I/O latency), vous pouvez désactiver l’utilisation des métriques d’E/S par vSphere Storage DRS pendant la fenêtre de sauvegarde.
Vous pouvez ensuite réactiver l’utilisation des métriques d’E/S une fois la fenêtre de sauvegarde terminée.
¶ vSphere Storage DRS et contrôle d’E/S de stockage (Storage I/O Control)
Pour vSphere Storage DRS, le contrôle d’E/S de stockage (Storage I/O Control) recueille les statistiques de latence d’un hôte ESXi, les envoie à vCenter, puis celles-ci sont stockées dans la base de données vCenter.
Grâce à ces statistiques, vSphere Storage DRS peut décider si une machine virtuelle (VM) doit être migrée vers un autre datastore.
Avec Storage I/O Control, vous pouvez équilibrer la charge d’E/S (I/O load) dans un cluster de datastores activé pour vSphere Storage DRS.
¶ Activité : vSphere Storage DRS
Considérez l’exemple du cluster de datastores.
Comment configurez-vous vSphere Storage DRS afin d’éliminer le point de défaillance unique (Single Point of Failure) pour les serveurs DNS primaire et secondaire ?
Vous créez une règle d’anti-affinité de machines virtuelles (VM) pour les serveurs DNS primaire et secondaire.
Une règle d’anti-affinité de VM garantit que les machines virtuelles indiquées dans la règle sont toujours placées sur des datastores différents.
¶ Revue des objectifs d’apprentissage
- Créer un cluster de datastores
- Configurer vSphere Storage DRS
- Expliquer comment Storage I/O Control et vSphere Storage DRS se complètent mutuellement
¶ Points clés
- vSAN regroupe les disques directement connectés aux serveurs pour créer un stockage partagé conçu pour les machines virtuelles (VM).
- Avec un datastore VMFS6, l’hôte ESXi envoie automatiquement la commande SCSI unmap à la baie de stockage, et le taux de désallocation (unmap rate) est configurable.
- Grâce à l’API vSphere pour la sensibilisation au stockage (vSphere API for Storage Awareness), les fournisseurs de stockage peuvent fournir des informations sur les capacités de leurs baies de stockage à vCenter.
- Avec les API vSphere pour le filtrage des E/S (vSphere APIs for I/O Filtering), VMware et les fournisseurs tiers peuvent créer des services de données tels que la mise en cache et la réplication.
- La gestion basée sur les stratégies de stockage (Storage Policy-Based Management) abstrait le stockage et les services de données fournis par vSAN, les volumes virtuels vSphere (vSphere Virtual Volumes), les filtres d’E/S, ou le stockage traditionnel.
- Storage I/O Control fournit une priorisation des E/S à l’échelle du cluster.
- Un cluster de datastores activé pour vSphere Storage DRS est un ensemble de datastores travaillant ensemble pour équilibrer la capacité de stockage et la latence des E/S.
Chapitre précédent : 4 - Opérations réseau - Chapitre suivant : 6 - Opérations vCenter et ESXi