Les stratégies de stockage vSAN définissent les conditions de stockage requises pour vos machines virtuelles. Ces stratégies garantissent le niveau requis de service pour vos machines virtuelles, car elles déterminent la façon dont le stockage est alloué à la machine virtuelle.

VMware Cloud on AWS inclut deux banques de données vSAN, l'une pour les machines virtuelles de gestion (vsanDatastore) et l'autre pour les machines virtuelles de charge de travail (WorkloadDatastore). Les deux banques de données partagent les mêmes périphériques de stockage sous-jacents et consomment les ressources du même pool d'espace libre.

Chaque machine virtuelle déployée dans une banque de données vSAN se voit attribuer au moins une stratégie de stockage de machine virtuelle. Vous pouvez attribuer des stratégies de stockage lorsque vous créez ou reconfigurez des machines virtuelles.

Les stratégies de stockage ont des attributs de disponibilité et des attributs avancés.

Attributs de disponibilité pour les stratégies de stockage VM vSAN

Tolérance aux sinistres de site
Définit la méthode de redondance des données utilisée par les clusters étendus pour gérer la défaillance d'un site. Cet attribut s'applique aux clusters étendus. Si vous disposez d'un cluster vSAN standard, choisissez Aucun (cluster standard).
Les options sont :
  • Aucun (cluster standard)
  • Surveillance double-site (cluster étendu)
  • Aucun - Conserver les données sur le dispositif primaire (cluster étendu)
  • Aucun - Conserver les données sur le dispositif secondaire (cluster étendu)
Pannes à tolérer
Définit le nombre de pannes d'hôte et de périphérique qu'une machine virtuelle peut tolérer. Vous pouvez choisir de n'avoir aucune redondance de données ou sélectionner une configuration RAID optimisée pour les performances (mise en miroir) ou la capacité (codage d'effacement).
  • RAID-1 utilise plus d'espace disque pour placer les composants des objets, mais fournit de meilleures performances pour l'accès aux objets.
  • RAID-5/6 (codage d'effacement) utilise moins d'espace disque, mais les performances sont réduites.
Tableau 1. Configurations RAID, FTT et conditions requises de l'hôte
Configuration RAID Pannes à tolérer (FTT) Nombre minimal d'hôtes requis
RAID-1 (mise en miroir) Il s'agit du paramètre par défaut. RAID-1 1 3
RAID-5 (codage d'effacement) 1 4
RAID-1 (mise en miroir) 2 5
RAID-6 (codage d'effacement) 2 6
RAID-1 (mise en miroir) 3 7
Note : Les machines virtuelles avec FTT = 0 (aucune redondance de données) peuvent subir une perte de données en cas de panne ou si la machine virtuelle ne répond plus.

Le profil de stratégie de stockage gérée détermine la configuration RAID initiale d'un cluster. Lorsqu'un profil de stratégie de stockage gérée est appliqué au cluster, la configuration RAID est automatiquement mise à jour lorsque la taille du cluster est modifiée. Reportez-vous à Profils de stratégie de stockage gérée de VMware Cloud on AWS pour plus de détails.

Attributs avancés pour les stratégies de stockage VM vSAN

Nombre de bandes de disque par objet
Nombre minimal de périphériques de capacité sur lesquels chaque réplica d'un objet de machine virtuelle est agrégé par bandes. Une valeur supérieure à 1 peut donner de meilleures performances, mais peut aussi engendrer une plus grande sollicitation des ressources système. La valeur par défaut est 1. La valeur maximale est 12. Modifiez la valeur par défaut uniquement lorsque le support VMware le recommande.
Limite d'IOPS pour un objet
Définit la limite IOPS pour un objet, tel qu'un VMDK. IOPS sont calculées comme le nombre d'opérations d'E/S, en utilisant une taille pondérée. Si le système utilise la taille de base par défaut de 32 Ko, une E/S de 64 Ko représente deux opérations d'E/S.

Lors du calcul d'IOPS, la lecture et l'écriture sont considérées équivalentes, mais le taux de réussite du cache et la séquentialité ne sont pas pris en compte. Si l'IOPS d'un disque dépasse la limite, les opérations d'E/S sont limitées. Si la Limite IOPS pour un objet est définie sur 0, les limites IOPS ne sont pas appliquées.

vSAN permet à l'objet de doubler le taux de la limite IOPS pendant la première seconde d'une opération ou après une période d'inactivité.

Réservation d'espace de l'objet
Ce paramètre définit le pourcentage de la taille logique du disque de machine virtuelle (vmdk) devant être réservé (provisionné) lors du déploiement de machines virtuelles. La valeur de réservation par défaut dans VMware Cloud on AWS est de 0 % ( Provisionnement dynamique). Vous pouvez spécifier Provisionnement statique pour réserver de la capacité pour des écritures vSAN plus volumineuses qu'attendues, mais la structure vmdk sous-jacente reste la même que celle de la configuration Provisionnement dynamique et n'est pas la même que le modèle de provisionnement statique immédiatement mis à zéro disponible sur site.
Réservation de Flash Read Cache
Ce paramètre est ignoré dans VMware Cloud on AWS. Dans les déploiements vSAN hybride, il désigne la capacité de mémoire flash réservée en tant que cache de lecture.
Désactiver le total de contrôle de l'objet
Si l'option est définie sur Non, l'objet calcule les informations de total de contrôle pour garantir l'intégrité de ses données. Si cette option est définie sur Oui, l'objet ne calcule pas les informations de total de contrôle.

vSAN utilise un total de contrôle de bout en bout pour garantir l'intégrité des données en confirmant que chaque copie d'un fichier est exactement la même que le fichier source. Le système vérifie la validité des données pendant les opérations de lecture/écriture et si une erreur est détectée, vSAN répare les données ou signale l'erreur.

Si une non-correspondance de total de contrôle est détectée, vSAN répare automatiquement les données en remplaçant les données incorrectes par les données correctes. Le calcul du total de contrôle et la correction d'erreur sont effectués en arrière-plan.

La valeur par défaut pour tous les objets du cluster est Non, ce qui signifie que le total de contrôle est activé.

Forcer le provisionnement
Si l'option est définie sur Oui, l'objet est provisionné, même si les stratégies Niveau primaire de pannes à tolérer, Nombre de bandes de disque par objet et Réservation de Flash Read Cache spécifiées dans la stratégie de stockage ne peuvent pas être satisfaites par la banque de données. Utilisez ce paramètre dans les scénarios d'amorçage ou lors d'une coupure lorsque le provisionnement standard n'est plus possible.

La valeur par défaut Non est acceptable pour la plupart des environnements de production. vSAN ne parvient pas à provisionner une machine virtuelle lorsque les conditions requises de la stratégie ne sont pas respectées, mais crée avec succès la stratégie de stockage définie par l'utilisateur.

Profils de stratégie de stockage gérée de VMware Cloud on AWS

Lorsque vous créez un cluster dans votre SDDC, VMware Cloud on AWS crée un profil de stratégie de stockage gérée qui est appliqué comme stratégie de stockage par défaut aux machines virtuelles que vous créez dans le cluster. Ce profil de stratégie de stockage est nommé « stratégie de stockage de charge de travail VMC - nom du cluster ». Les paramètres de stratégie sont configurés pour s'assurer que le cluster répond à la configuration requise décrite dans le Contrat de niveau de service pour VMware Cloud on AWS (le SLA).

Les paramètres de stratégie de stockage gérée sont basés sur la configuration du cluster comme suit :

  • Les SDDC à hôte unique ne sont pas couverts par le SLA. Ils utilisent une stratégie Aucune redondance de données.
  • Les clusters à AZ simple utilisent le provisionnement dynamique et la tolérance de panne dépend de la taille du cluster et du type d'instance hôte :
    • Les clusters utilisant un stockage Elastic VSAN utilisent la stratégie 1 panne - RAID-1 (mise en miroir), quelle que soit la taille du cluster.
    • Les clusters utilisant un stockage VSAN non élastique contenant entre 3 et 5 hôtes utilisent la stratégie 1 panne - RAID-1 (mise en miroir).
    • Les clusters utilisant un stockage VSAN non élastique contenant 6 hôtes ou plus utilisent la stratégie 2 pannes : RAID-6 (codage d'effacement).
  • Les clusters étendus utilisent la stratégie 1 panne - RAID-1 (mise en miroir), mais disposent également d'un niveau de Tolérance aux sinistres de site défini sur Surveillance double-site.

Comme la stratégie de stockage gérée des clusters VSAN non élastiques varie en fonction de la taille du cluster, l'ajout ou la suppression d'hôtes déclenche une reconfiguration de la stratégie de stockage si la taille du cluster est modifiée en raison d'une stratégie différente. Par exemple, si vous ajoutez un hôte supplémentaire à un cluster contenant cinq hôtes i3.metal, la stratégie de stockage pour ce cluster est reconfigurée pour passer de la stratégie 1 panne - RAID-1 (mise en miroir) à 2 pannes : RAID-6 (codage d'effacement). L'inverse se produit si l'hôte supplémentaire est supprimé et que le nombre d'hôtes est réduit de six à cinq.

Note : Lorsque vous apportez une modification à un cluster qui déclenche une reconfiguration de la stratégie de stockage gérée, la reconfiguration nécessite un stockage supplémentaire de manière temporaire. Si la capacité de stockage du cluster est proche de 75 %, un événement de montée en charge EDRS peut se déclencher et ajouter un hôte au cluster. Une fois la reconfiguration terminée, EDRS peut ne pas supprimer l'hôte supplémentaire. Vérifiez vos clusters après la reconfiguration du stockage et supprimez l'hôte supplémentaire si nécessaire.

Pour un cluster VSAN non élastique disposant de 6 hôtes ou plus, vous ne pouvez pas supprimer un hôte si l'utilisation du stockage du cluster est supérieure à 40 % de la capacité de stockage totale. Pour tous les autres types de clusters, VMware recommande vivement de ne pas supprimer un hôte si l'utilisation du stockage du cluster est supérieure à 40 % de la capacité de stockage totale.

Si vous supprimez un ou plusieurs hôtes d'un cluster et que cela déclenche une reconfiguration de la stratégie de stockage gérée, la reconfiguration doit se terminer avant la suppression de l'hôte ou des hôtes. Si vos charges de travail utilisent une quantité de stockage importante, cette reconfiguration peut prendre de quelques heures à plusieurs jours. Pendant ce temps, tous les hôtes que vous avez désignés pour être supprimés restent utilisables et vous êtes toujours facturé pour l'utilisation de ces hôtes. Une fois la reconfiguration de la stratégie de stockage terminée, l'hôte ou les hôtes sont supprimés et vous n'êtes plus facturé pour l'utilisation de ceux-ci.

Note : Ne modifiez pas les stratégies de stockage gérées que VMware Cloud on AWS crée pour vos clusters. Si vous renommez la stratégie, celle-ci n'est plus gérée par VMware Cloud on AWS. Si vous modifiez les paramètres de la stratégie de stockage gérée, vos modifications sont écrasées lors de la prochaine reconfiguration de la stratégie de stockage.

Si vous ne souhaitez pas utiliser la stratégie de stockage gérée, vous pouvez définir votre propre stratégie de stockage et l'attribuer comme valeur par défaut pour la banque de données de charge de travail. Reportez-vous à la section https://docs.vmware.com/fr/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-F52F0AE9-FB31-4236-B566-D9610B14C670.html.

Modèles de VM et stratégies de stockage gérées

Si un modèle de machine virtuelle est associé à une stratégie de stockage gérée par VMware Cloud on AWS, la stratégie du modèle n'est pas automatiquement mise à jour si la stratégie du cluster est reconfigurée. Une fois la stratégie de stockage du cluster reconfigurée, l'état de conformité du modèle de machine virtuelle est « Obsolète ». Pour rendre l'état de la stratégie du modèle « Conforme », vous devez convertir le modèle en machine virtuelle, réappliquer la stratégie de stockage de machine virtuelle, puis reconvertir la machine virtuelle en modèle.

Lorsque vous déployez une machine virtuelle à partir d'un modèle, VMware vous recommande de sélectionner Banque de données par défaut pour la stratégie de stockage de machine virtuelle afin de garantir que la machine virtuelle est déployée avec la stratégie de stockage gérée du cluster actuel.

Stratégies de stockage et conditions SLA

Lorsque vous utilisez des stratégies de stockage de machine virtuelle, il est important de comprendre comment elles affectent la consommation de la capacité de stockage dans le cluster vSAN et si elles répondent aux conditions requises définies dans le contrat de niveau de service (SLA) pour VMware Cloud sur AWS.

La stratégie de stockage gérée est initialement configurée en fonction du nombre d'hôtes dans le cluster. Par exemple, un cluster à trois hôtes est défini par défaut sur FTT=1 à l'aide de la stratégie de mise en miroir RAID-1. Les clusters disposant de plus de six hôtes i3.metal dans une seule zone AZ sont définis par défaut sur 2 pannes : RAID-6 (codage d'effacement). Vous pouvez créer des stratégies personnalisées qui alignent la disponibilité des données avec les besoins de vos données sous-jacentes, mais les machines virtuelles de charge de travail avec des stratégies de stockage qui ne répondent pas aux exigences définies dans le contrat de niveau de service peuvent ne pas être éligibles aux crédits SLA. La stratégie de stockage de machine virtuelle doit être configurée avec le niveau de protection approprié. Les charges de travail éphémères peuvent utiliser la stratégie Aucune redondance de données pour économiser de la capacité, conformément aux garanties suivantes de disponibilité du SLA.

Important :

Lors de la montée en puissance d'un cluster i3.metal de cinq à six hôtes, la tolérance de panne de la stratégie sous-jacente doit être mise à jour pour 2 pannes : RAID-6 (codage d'effacement) ou 2 pannes : RAID-6 (mise en miroir) afin de compenser le plus grand pool de pannes. Les clusters utilisant la stratégie de stockage gérée seront reconfigurés automatiquement, mais vous devrez mettre à jour manuellement tous les clusters qui utilisent des stratégies personnalisées. L'utilisation continue d'une tolérance de panne égale à 1 pour cette configuration d'hôte signifie que VMware ne peut pas garantir la disponibilité conformément au guide de définition de service. Les clusters R5.metal utilisant Elastic vSAN peuvent supporter le SLA avec une tolérance de panne égale à 1, quelle que soit la taille du cluster pour trois hôtes ou plus.

Pour plus d'informations sur les considérations de conception et de dimensionnement à prendre en compte dans les stratégies de stockage, reportez-vous à la documentation Administering VMware vSAN.