Qu’est-ce que le Format Sparse dans la Virtualisation ? (VMDK et VHD Expliqués)

Tout déploiement de virtualisation est confronté au même dilemme opérationnel. Un provisionnement généreux permet de s’adapter à la croissance, mais laisse une partie de la capacité physique inutilisée. Un provisionnement prudent préserve l’efficacité du stockage, mais la marge disponible s’épuise rapidement. Le format « sparse » résout cette contrainte.

Un disque virtuel « sparse » n’occupe que l’espace sur lequel le système d’exploitation invité a écrit. Un disque de 100 Go contenant un système d’exploitation de 20 Go occupe environ 20 Go d’espace de stockage dans le datastore, laissant le reste disponible pour d’autres machines virtuelles. Les avantages de cette approche sont considérables. Les compromis sont tout aussi importants, et les uns comme les autres apparaissent clairement lorsque la couche de stockage subit une défaillance.

Il est donc essentiel, pour tout administrateur chargé de gérer une infrastructure virtuelle, de comprendre le fonctionnement du format « sparse » et d’identifier les risques qu’il comporte.

Qu’est-ce qu’un format de disque virtuel ?

Un format de disque virtuel est un fichier, ou parfois un petit ensemble de fichiers, que l’hyperviseur présente à un système d’exploitation invité comme un périphérique de stockage physique. Le système d’exploitation invité reconnaît un contrôleur SCSI ou SATA. Le disque est fondamentalement un conteneur résidant au sein d’un système de fichiers hôte plus vaste, un détail qui reste transparent pour l’invité et ne nécessite aucune prise en compte au niveau de l’invité.

Tous les éléments contenus dans un disque physique se trouvent au sein de ce conteneur : tables de partition, enregistrements d’amorçage principaux, systèmes de fichiers et données utilisateur. L’emplacement de stockage varie selon la plateforme. VMware place ces fichiers sur le système de fichiers de machine virtuelle (VMFS), tandis qu’Hyper-V utilise le NTFS ou le système de fichiers résilient (ReFS). Quelle que soit la plateforme, le format détermine la manière dont les opérations de lecture et d’écriture de l’invité se traduisent en opérations réelles sur le disque physique sous-jacent.

Qu’est-ce que le format « sparse » ?

Un disque « sparse » alloue l’espace de stockage de manière dynamique, en ne réservant de l’espace sur la matrice qu’au fur et à mesure que l’invité y écrit des données. Cela contraste avec un disque à allocation « thick » (ou « flat »), qui réserve l’intégralité de sa capacité allouée dès sa création et remet à zéro chaque bloc de la matrice avant même que les données de l’invité n’y soient reçues.

Une brève précision terminologique s’impose ici. Les termes « provisionnement clairsemé » et « provisionnement fin » renvoient au même concept sous-jacent : la capacité est allouée à la demande et s’étend à mesure que les données s’accumulent. Lorsque l’on compare le « provisionnement clairsemé » au « provisionnement fin », on oppose généralement le format clairsemé d’un fournisseur au format fin d’un autre, plutôt que de décrire deux stratégies d’allocation différentes. La distinction qui importe réellement pour la planification de la capacité est celle entre, d’une part, le provisionnement clairsemé ou fin et, d’autre part, le provisionnement dense ou plat.

Comment les disques « sparse » allouent-ils l’espace à la demande ?

Lorsqu’une application invitée lance une opération d’écriture, l’hyperviseur l’intercepte, détermine l’emplacement logique de ces données, les ajoute à la fin du fichier hôte et met à jour une table de métadonnées interne afin d’associer le secteur logique de l’invité à son nouveau décalage physique. Les blocs logiques occupent rarement un ordre physique contigu, ce qui est une conséquence inhérente de l’allocation à la demande.

Lorsqu’un fichier est supprimé dans l’invité, le fichier hôte correspondant ne rétrécit pas. L’hyperviseur marque les blocs sous-jacents comme disponibles pour être écrasés, mais un processus de récupération distinct est nécessaire avant que cet espace ne soit libéré sur l’hôte.

VMDK clairsemé (VMware)

Dans un environnement VMware de production, un fichier VMDK clairsemé se compose de deux éléments : un fichier descripteur au format texte qui spécifie la géométrie du disque, et un ou plusieurs fichiers d’extension contenant les données binaires. À partir du descripteur, une chaîne de pointeurs s’étend vers le bas à travers le répertoire des grains et les tables de grains jusqu’aux blocs de données eux-mêmes, appelés « grains ». Par défaut, chaque grain mesure 64 Ko.

Deux variantes existent dans les environnements de production. Le format « monolithique » regroupe toutes les données dans un seul fichier contigu et constitue la configuration standard pour la plupart des systèmes de production. Le format « segmenté » divise le disque en segments de 2 Go et est conservé uniquement à des fins de rétrocompatibilité avec les systèmes de fichiers hérités qui ne peuvent pas prendre en charge des fichiers individuels volumineux.

VHD/VHDX clairsemés (Hyper-V)

L’équivalent de Microsoft a connu une transition générationnelle majeure. Le format VHD hérité est limité à une capacité de 2 To. Le format VHDX a relevé ce plafond à 64 To et a introduit une table d’allocation de blocs (Block Allocation Table) pour suivre l’état des données dans l’ensemble de la structure.

Une autre caractéristique du format VHDX est pertinente pour la planification du stockage. La capacité de son secteur physique est alignée sur 4 Ko, ce qui correspond aux spécifications des disques modernes au format avancé et réduit l’amplification d’écriture. La capacité de bloc désigne l’unité de stockage que le format VHDX utilise à chaque extension ; elle est fixée par défaut à 32 Mo sur les disques dynamiques. Des blocs plus volumineux nécessitent moins de surcharge liée aux métadonnées, mais s’étendent par incréments plus grossiers. Microsoft recommande de réduire cette valeur à 1 Mo pour les machines invitées sous Linux.

Comparaison entre les formats « sparse » et « flat/raw »

Les disques « flat » réservent la totalité de leur capacité au moment de leur création. Un disque « flat » de 50 Go occupe immédiatement 50 Go d’espace dans le datastore, quel que soit l’espace de stockage utilisé au sein de la machine invitée. L’hyperviseur remet chaque bloc à zéro lors de la création, ce qui explique pourquoi l’allocation d’un disque « flat » de grande taille prend beaucoup de temps.

En comparaison, les implications opérationnelles du format « sparse » sont les suivantes :

• La consommation d’espace initiale reste minime et n’augmente qu’au fur et à mesure de l’écriture des données.
• Le déploiement est rapide, car la phase de mise à zéro des blocs n’est pas nécessaire.
• La surcharge liée aux métadonnées est plus importante en raison des mises à jour constantes de la table d’allocation.
• La fragmentation logique au sein du système de fichiers de l’hôte augmente progressivement au fil du temps.
• La capacité physique inutilisée reste disponible pour d’autres charges de travail.

Le tableau suivant résume les différences entre les formats « sparse » et « flat » :