Les politiques de stockage vSAN

Tweet

Les politiques de stockage

Disk Stripes par Objet

Le nombre de Disk Stripes par objet ou Stripe Width (SW) définit le nombre minimum de disques (Capacity Tier) sur lesquels chaque réplicas d’un objet sera distribué. VSAN peut effectivement créer plus de stripes que le nombre indiqué dans la politique.

Le striping peut améliorer les performances si certaines machines virtuelles sont fortement consommatrice d’IO et d’autres non. Avec le striping, les données d’une VM sont réparties sur plusieurs disques qui contribuent tous à la performance globale du stockage de cette machine virtuelle. Dans un cluster Hybride le striping se fera sur les disques magnétiques. Dans un cluster Full Flash le striping se fera sur les disques SSD composant le Capacity Tier.

Les best practices recommandent de laisser le nombre Disk Stripes par Objet à la valeur pas défaut de 1, sauf si des problématiques de performance peuvent être soulagées par le striping.

Flash Read Cache Reservation

Plus haut dans ce document, nous avons mentionné la règle des 10% minimum pour le sizing du Caching Tier. Ce Caching Tier est utilisé comme cache en écriture et buffer de lecture dans les Cluster Hybrides et comme buffer d’écriture uniquement dans les Cluster Full Flash, il est distribué de manière homogène sur les hôtes du Cluster.

L’utilisation de cette politique va permettre de dédier une portion du Cache à une ou plusieurs machines virtuelles.

Ce réglage définit quelle capacité du Cache en lecture doit être réservé pour un objet spécifique. Il se définit en un pourcentage de la taille logique de l’oject disque d’une VM.

Cette politique ne doit être utilisée que pour adresser des problématiques de performance en lecture clairement identifiées. En effet les objets des autres VMs ne pourront pas utiliser cette portion de Cache.

Cette politique n’est pertinente que dans le Cluster Hybrides. Elle n’est ni supportée, ni pertinente dans les configurations Full Flash puisque qu’il n’y a pas de cache en lecture dans ces configurations, les lectures étant délivrées directement par les disques SSD sur Capacity Tier.

Number of Failure To Tolerate (FTT)

Cette politique permet de définir le niveau de disponibilité (tolérance de panne) de toute une machine virtuelle ou d’une VMDK individuelle.

Pour « n » pannes tolérées, « n+1 » copies de l’objet sont créée et « 2n+1 » hôtes contribuant au stockage sont nécessaires. La valeur par défaut du FTT est égale à 1. Cela signifie que même si une politique de stockage n’est pas choisie au moment du déploiement d’une VM, il y aura quand même un réplica des données de la machine virtuelle. La valeur maximum du FFT est 3 (sauf pour les VMDK dont la taille est supérieure à 16TB qui sont limitée à un FTT =1).  Si avec un FTT=1 on créée 2 copies de la donnée, avec un FTT=2 nous aurons 3 copie et 4 copies avec un FTT=3

Grace au concept du Fault Domain, VSAN permet de tolérer non seulement la panne d’un hôte mais aussi des pannes plus environnementales telles que la défaillance d’un rack, d’un switch ou de l’alimentation électrique en positionnant les réplicas des données dans différents endroits

Quand on travaille avec des Fault Domains, pour tolérer « n » pannes, « n+1 » copies de l’objet sont créée mais « 2n+1 » Fault Domains sont également nécessaires. Chaque Fault Domain doit contenir au minimum 1 hôte contribuant au stockage.

Force Provisionning

La politique de Force Provisionning permet à VSAN de ne pas respecter les politiques de stockages vues précédemment (Stripe par Objet(SW), Flash Read Cache Reservation (FRCR) et FTT) au moment de la création d’une machine virtuelle.

Par défaut VSAN va essayer de positionner les données de façon à respecter tous les prérequis. Si ce n’est pas possible, VSAN essayera un placement plus simple en réduisant le FTT à 0, le Stripe par objet à 1 et le FRCF à 0. Cela signifie que VSAN va créer un objet avec une seule copie des données.

Cette politique de stockage s’utilise principalement pour autoriser la création de VM meme dans le cas où le cluster ne présente plus assez de host et/ou Fault domaine pour garantir le FTT.

Object Space Reservation

Par défaut, les objets d’une machine virtuelle déployée dans un Cluster VSAN sont Thin-provisionnées. La politique Object Space Reservation (OSR) permet de définir le pourcentage de la taille logique d’un objet qui doit être réservée (Thick-provisionné) quand la VM est créée. Le pourcentage restant de l’objet restera thin-provisionné.

La valeur par défaut est 0%, impliquant que l’objet déployé est thin, la valeur maximum est 100% ce qui veut dire que la capacité de l’objet est entièrement réservée.

Il existe un certain nombre de gardes fous afin de se prémunir d’une surconsommation. Par exemple, s’il n’y a pas assez de capacité disponible dans les nombre d’hôtes requis pour satisfaire le FTT ou le WS, alors le message d’alerte ci-dessous s’affiche

IOPS Limit par Objet

Il existe des situations ou on peut souhaiter de limiter le nombre maximum d’IOPS disponible pour un objet ou une machine virtuelle. Il y a deux cas d’usage pour cette fonctionnalité :

• Empêcher certains workloads d’impacter les autres qui ont plus besoin de performance
• Créer des niveaux de services artificiels dans le cadre d’une offre de service à plusieurs niveaux utilisant le même pool de ressources.

Cette politique limite donc le niveau de performance disponible pour un objet et fonctionnera sur une base de bloc de 32KB. Une machine virtuelle qui lit des ou écrit des blocs de 16KB sera traitée de la même manière qu’une autre travaillant avec des blocs de 32KB. Les lectures et écritures de 64KB seront traitées comme 2 opérations séparées.

Disable Checksum

L’Object Checksum permet la détection de corruption de données causées par des composants matériels ou logiciels (mémoire, disques, …) pendant les opérations de lecture ou l’écriture.

L’Object Checksum est activé par défaut pour tous les objets résidant sur environnement VSAN. Les Checksum sont vérifiés pour toutes les lectures et un scan est effectué régulièrement pour toutes les blocs non accédés en lecture depuis un an. Ce scan peut être configuré avec une fréquence plus régulière mais cela peut affecter les IO disques en tache de fond.

L’Object Checksum implique une légère consommation d’IO disques, de mémoire et de CPU et peut donc être désactivée à l’objet via cette politique.

Failure Tolerance Method (FTM)

Dans les configurations Full Flash le FTT peut être garanti de deux manière différentes. Alors que les techniques de mirroring excellent pour les workloads où la performance est un des facteurs les plus important, elles sont coûteuses en terme de capacité nécessaire. Les approches RAID-5/6 (Erasure Coding) peuvent être utilisées pour garantir les mêmes niveau de disponibilité mais en consommant moins de capacité disque que le RAID-1 ( Mirroring).

Le choix entre RAID-1 et RAID-5/6 se fait au travers la politique de stockage Failure Tolerance Method (FTM) et peut être appliqué à toute la VM ou à une VMDK.

L’Erasure Coding peut permettre une économie significative de la capacité en comparaison du mirroring mais il est important de considérer qu’il va aussi induire une consommation additionnelle des ressources. Dans la mesure ou l’erasure coding n’est supporté que dans les configuration Full Flash les effets sur la latence et les IOPS sont négligeable dans la majorité des cas d’usage en raison de la performance inhérente aux composants Flash