Accueil > Backup, VMware > Gestion des blocs disques (VMFS et guest FS)
Avr/1122

Il n’est plus nécessaire d’expliquer la différence principale entre ces deux types de disques Thin et Thick proposés par VMware. Mais certains points méritent encore d’être étudiés. La question des performances a déjà été abordée dans plusieurs études (cf site VMware) et montrent dans la plupart des cas une modification très légère du comportement. En résumé on note deux différences :

  1. Le volume créé en thin provisioning doit à un certain moment être étendu pour accueillir de nouvelles données. C’est ce besoin qui est ressenti. Quizz : lorsqu’une donnée est supprimée, une nouvelle donnée demande-t-elle une extension du disque ou peut-elle prendre les blocs des données supprimées ?
  2. La fragmentation des volumes VMFS est alors plus importante. Les fichiers des VM ne peuvent plus être contigus en raison de l’entrelacement des extensions des fichiers VMDK. Quizz : Comment est gérée cette fragmentation sur les volumes VMFS ?

Et un point de détail complémentaire : L’initialisation des blocs à 0. A quoi correspondent les termes Disk Blocks, Lazy Zero, Eager Zero, Zeroing… ?

Formatage du système de fichiers d’une machine virtuelle

Une VM a été déployée avec 2 disques en thin provisioning et 1 en thick. Le disque système en Thin Provisioning fait 10Go et ne prend que 2Go sur disque, un disque Thick de 2Go est ajouté à la VM et enfin un disque de 3Go en Thin provisioning. Sur le disque de 2Go, le formatage NTFS Windows est un formatage normal, alors qu’il a été fait en mode rapide sur le disque de 3Go. La VM est alors migrée de datastore avec un passage de tous les disques en format mince. Une partition est alors reformaté en normal, et l’autre est supprimée. La VM est de nouveau migrée en Thin.

Le résultat : le formatage de la partition n’a pas d’effets sur le contenu des blocs. Aucun bloc n’a été écrit ni mis à 0 . Les uniques informations écrites sont celles liées à la partition. Une partition supprimée ne supprime pas les blocs utilisés sur le VMDK. La migration en Thin d’un disque sur lequel une partition a été supprimée ne libérera pas l’espace. Même dans le cas ou la partition a été recréé, reformatage, long ou rapide, les blocs précedemment activés contiennent toujours des données.

La volumétrie prise sur le disque dépend du type de disque utilisé, un datastore en NFS (avec uniquement de disques Thin autorisés) sera moins gourmand qu’un datastore sur Lun.

Comportement des disques Thin

Les disques Thin grandissent à la demande. Mais peuvent aussi grandir alors que l’on pense avoir assez d’espace sur le système de fichiers de la VM. Exemple : on copie sur un disque Thin des données pour 92Mo. On note une première une augmentation du fichier VMDK. On supprime ces données (sans impact sur la taille du VMDK), mais on est en droit de penser qu’il y aura assez d’espace disque pour stocker moins de 20Mo. Or le VMDK augmente encore un peu. L’augmentation est liée à la taille des blocs du VMFS. Bien que le file system VMware gère des fichiers plus petits que la taille des blocs par des sous-blocs (1/8eme pour les VMFS à 1Mo et 1/128eme à 8Mo), les fichiers VMDK peuvent être fragmentés et séparés d’au moins la taille d’un bloc (cf étude VMware page 7) . 

Zero Lazy ou Eager ?

  • Eager zero est le fait de placer à 0 tous les blocs du disque. Evitant aisi de le faire avant une écriture sur un bloc jusque là non utilisé. C’est un fonctionnement prérequis pour le fault tolerence (FT).
  • Lazy zero est la préparation par défaut d’un disque. Les blocs ne sont pas initialisés. Donc à la première écriture sur un blocs du FS de la VM (par défaut 64Ko) il faut effectuer une remise à Zero d’un bloc du VMDK.

Pour voir si un disque contient des blocs devant être mis à Zero : # vmkfstools -D <path_to_my.vmdk>. Sur un disque Thin, il n’y aura pas de blocs devant être mis à Zero, l’espace utilisé du VMDK est l’espace sur lequel aura été écrit une donnée (nb x tbz 0). NB correspond au nombre de blocs du VMFS utilisés pour stocker le disk thin (x=<max vmdk size> / <vmfs block size>). Et TBZ correspond aux blocs à mettre à 0. Pour un disque Thick  en Lazy Zero, les deux valeurs sont au maximum, alors que pour un disque Thin les deux valeurs seront à 0 au départ et TBZ le restera.

Pour voir le nombre de blocs à zero au prochain accès : # vmkfstools -t0 <path_to_my.vmdk>. Dans un fonctionnement classique, sans opérations de maintenance, un disque Thin n’a pas de blocs à Zero et n’est pas provisionné de blocs devant être mis à Zero. Il n’y a donc aucune ligne contenant : [VMFS Z– LVID:. Les lignes contenant  [VMFS Z- LVID: indiquent qu’il y aura une remise à Zero lors du premier accès.

Exemple à la création d’un disque Thick eagerzeroed :

~ # vmkfstools -t0 /vmfs/volumes/vmfs1/XP/XP_3.vmdk
Mapping for file /vmfs/volumes/vmfs1/XP/XP_3.vmdk (1073741824 bytes in size):
[           0:   985661440] --> [VMFS Z- LVID:4d92731c-67c8c0c3-37f9-000c2924d896/4d92731c-329b1479-a039-000c2924d896/1:(  1339097088 -->   2324758528)]
[   985661440:    88080384] --> [VMFS Z- LVID:4d92731c-67c8c0c3-37f9-000c2924d896/4d92731c-329b1479-a039-000c2924d896/1:( 19957612544 -->  20045692928)]
~ # vmkfstools -k /vmfs/volumes/vmfs1/XP/XP_3.vmdk
Eagerly zeroing: 100% done.
~ # vmkfstools -t0 /vmfs/volumes/vmfs1/XP/XP_3.vmdk
Mapping for file /vmfs/volumes/vmfs1/XP/XP_3.vmdk (1073741824 bytes in size):
[           0:   985661440] --> [VMFS -- LVID:4d92731c-67c8c0c3-37f9-000c2924d896/4d92731c-329b1479-a039-000c2924d896/1:(  1339097088 -->   2324758528)]
[   985661440:    88080384] --> [VMFS -- LVID:4d92731c-67c8c0c3-37f9-000c2924d896/4d92731c-329b1479-a039-000c2924d896/1:( 19957612544 -->  20045692928)]

Il n’est pas autorisé d’utiliser cette procédure pour la mise à 0 d’un disque Thin.

Informations disponibles sur le site de VMware : kb1011170

En information complémentaire, pour préprovisionner un disque Thin, il est possible de faire un inflate ( #vmkfstools -j /vmfs/volumes/vmfs1/XP/XP_1.vmdk). Cela aura pour conséquence de gonfler le VMDK à sa taille maximum et de le préparer en eager zero, près à écrire !

Migration Thin-Thick et Thick-Thin

Tout changement de type de disque ne peut se faire que par migration, clonage de disque. En ligne de commande, ou par interface du vCenter. En ligne de commande :

#vmkfstools -i <disque_source> <disque_cible> -d <format>

Format = zeroedthick | thin | eagerzeroedthick

Par l’interface du vCenter, il est possible (sous réserve de licence Storage vMotion) d’effectuer un changement de stockage en live avec changement de format, ou bien de cloner la VM en changant le format.

Remise à Zero 0 des blocs du système de fichiers d’une machine virtuelle

Définition d’une remise à zero : c’est une opération qui vise à supprimer toute trace d’une précédente donnée sur un disque, partition ou bloc. On retrouve souvent cette opération sur des baies Netapp lorsque l’on supprime des agrégats, et que l’on en crée d’autres… Le passage à 0 permet une écriture directe des données sans avoir à initialiser l’espace.

Dans une machines virtuelle, lorsque l’on supprime une donnée, elle n’est pas réellement effacée du disque. C’est bien grace à cela que l’on arrive parfois à récupérer un fichier supprimé par erreur ou que certaines données sont récupérable tant qu’il n’y a pas eu de défragmentation ou de réécriture sur les blocs du disque. Cela à un impact sur les sauvegardes (temps de sauvegarde et volume de stocakge secondaire) des serveurs virtualisés, qui ne se basent pas sur l’explorateur du serveur pour lister les documents à sauvegarder. Vu de l’hyperviseur, les bocs sont occupés, et à ce titre ne pourront pas forcément faire bénéficier les outils de sauvegarde d’une déduplication importante. Les données y étant stockées sont très certainement différentes.

Pour les serveurs Windows, on peut utiliser l’outil SDelete (à télécharger sur le site Microsoft).

Attention ! Sdelete réinitialise tous les blocs disques. Y compris ceux qui n’avaient pas encore été initialisés par la VM. Cela veut dire que sur des disques minces (thin provisioned), le disque va prendre la totalité de sa volumétrie au fur et à mesure que l’outil passera sur les blocs. Donc, à ne pas utiliser sur un disque de 200Go, provisionné à hauteur de 50Go pour gagner 10Go. La datastore risque fortement de saturer avant de pouvoir permettre de récupérer la volumétrie.

Tests effectués :

  1. Déploiement d’une VM XP, avec deux disques C: et E: chacun de 10Go en format mince. Les fichiers VMDK n’occupent alors que 1 491 856 Ko (pour le C:) et 55 312 Ko (pour le E:).
  2. Une volumétrie identique est copiée sur chaque disque (690Mo). Les fichiers VMDK sont bien étendus des blocs nécessaires. Mais à la suppression, les VMDK ne sont pas réduits, pourtant le système ne voit plus les données.
  3. Lors d’une opération de clonage de la VM (Photo1), le format Mince (Thin) est séléctionné. La VM est recréé avec la même taille. Aucune volumétrie n’est récupérée.
  4. Après redémarage de la VM, on exécute (sdelete.exe -c E: ) pour ne remettre à 0 que les blocs du disque E: (le fichier _1.vmdk). Il faut alors faire attention à la volumétrie que cela va prendre ! (Photo2)
  5. Enfin, on re-clone cette VM. On récupère bien l’espace sur le disque _1.vmdk. (Photo3)

      

Pour les serveurs Linux, le constat est le même. Des données supprimées dans le file system occupent toujours les blocs disques et donc la volumétrie. Plusieurs outils semblent pouvoir répondre au besoin de remise à 0 de l’espace libre sans stopper le serveur : secure-delete (sfill), dd (pour tout un disque), et bcwipe (en version d’essai limité à 21jours). Bcwipe est un outil complet. Pour ne faire qu’une remise à zero des blocs, il faut passer la commande :

#bcwipe -F -mz -v <mount_path>

Cela va prendre un certain temps et va réinitialiser les blocs de l’espace libre à la valeur 0. Le disque qui héberge le point de montage est alors étendu a la volumétrie maximale du point de montage, donc attention à la place disponible sur le datastore. Par la suite, une migration de la VM en Thin permettra de récupérer la volumétrie.

   

  1. 23/04/2011 à 14:28 | #1

    Hyper intéressant ton article!
    Et avec le Shrink, on ne récupère pas la place? Par contre ca peut impacter les perfs et la dispo d’une VM.

    • 26/04/2011 à 09:29 | #2

      La réduction des disques par Shrink n’est pas autorisée dans les cas suivants : la VM est sur ESX/ESXi (la VM doit être exportée), l’espace disque ne doit pas être préalloué, la VM ne doit pas avoir de snapshot, la VM est un clone lié ou un parent lié, les disques sont en indépendant et non persistant, les systèmes de fichiers sont de type journalisation (ext4, xfs…). A retrouver dans l’aide des VMware Tools. Dommage !

  1. Pas encore de trackbacks