Partagez l'article

Connexion






Mot de passe oublié ?
Identifiant oublié ?
Pas encore inscrit ? Créer un compte

Up-coming events

There are no up-coming events

Hyper-V Thin Provisionning et Unmap PDF Imprimer Envoyer
Note des utilisateurs: / 7
MauvaisTrès bien 
Écrit par Cédric Bravo   

Hyper-V VHDX, Thin Provisionning et Space Reclaim (Trim / Unmap)

 

Le disques virutels VHDX de Windows Server 2012 supportent une fonctionalité peu connue et mal comprise, le Trim/Unmap.

Pourquoi parle t'on de Trim et de Unmap ? Et bien parce que c'est la même chose. Le Trim est l'équivalent ATAPI de la fonction SCSI Unmap (Commande SCSI N°42)

Ces fonctions sont activées par défaut dans Windows 2012 et fonctionnent automatiquement quand les pré-requis nécessaires sont présents.

Alors commençons par tordre le cou à une idée reçue....

Trim / Unmap ne sont pas des fonctions exclusivement dédiées aux disques SSD !

Pour comprendre comment cela fonctionne, attardons nous un peu sur ce qu'il se passe lorsque qu'un fichier est supprimé d'un file system.

De manière très schématique, un système de fichier est composé d'une table d'allocation (appellée Master File Table sous NTFS) qui contient la référence de tous les fichiers stockés sur le disque.

Cette table est une sorte de base de donnée qui décrit l'emplacement de tous les blocs des fichiers stockés sur la partition.

La taille de cette table est déterminante concernant le nombre et la taille des fichiers qu'il est possible de créer sur une partition.

ntfs

 

Composant

Description

NTFS Boot Sector

Block désigné par le Bios qui renseigne la structure du File System et qui indique l'emplacement du volume bootable.

Master File Table

Contients les informations nécessaires pour la localisation des fichiers ainsi que ces attributs.

File System Data

Les données.

Master File Table Copy

Copie de sécurité de la MFT.

 

Quand on supprime un fichier, on ne supprime pas les blocs qui le composent, mais uniquement son entrée de la table d'allocation. Pour cette raison, la suppression est immédiate, mais les données sont toujours présentes physiquement, ce qui permet dailleur de les récupérer relativement facilement à l'aide d'outils spécialisés.


Avec les disques SSD, on se retrouve face à un problème. Pour des raisons techniques, le controleur n'est pas en mesure de déterminer quel sont les blocs non utilisés. Une fois tous les blocs écrits au moins une fois, le disque est obligé de vérifier la disponibilité du bloc... ce qui ralentis les performances.

C'est pour cette raison que la commande Trim éxiste et a été portée dans Windows ainsi que son équivalent SCSI, la commande Unmap.

Le Trim va permettre de marquer les blocs comme récupérable et informer le controleur qu'ils sont de nouveau disponibles pour écrire des données, ce qui permet d'optimiser les accès.

 

Les disques virtuels et l'abstraction du stockage physique SAN.

Avec les disques virtuels on rencontre la même problématique qu'avec les disques SSD, il n'est pas possible d'informer le sous sytstème de stockage de l'espace libéré.

Prenons par exemple une machine virtuelle Hyper-V utilisant un disque VHD fixe (ancien format) installé sur une baie de stockage.

Lors de la création du disque fixe, l'espace est entièrement alloué et l'ensemble des blocs sont écrits avec des 0 (Ce mécanisme permet non seulement d'éffacer des données qui pourrait encore se trouver sur le stockage physique, mais aussi de réclamer l'espace si le SAN le supporte).

Dans le cas de notre disque fixe, les blocs vides qui n'ont jamais été utilisés peuvent êtres récupérés par la baie de stockage qui opère un Space Reclaim (fonction du SAN). Le Space Reclaim va identifier les blocs à 0 et les remettres à disposition pour une utilisation ultérieure.

 

Comme pour les disques SSD, la chose se complique quand des données sont écrites, puis supprimées. En effet, ces blocs n'étant pas remis à 0, ils ne seront pas récupérés lors du passage du Space Reclaim.

Le seul moyen est alors d'utiliser des outils tiers (comme SDelete), capable de remettre à 0 les blocs inutilisés. Problème, ces outils doivent être schédulés, et ne permettent pas toujours de récupérer l'espace d'un volume qui ne dispose pas de lettre de lecteur (comme c'est le cas des clusters Hyper-V).

 

notrim

En conséquence, si votre SAN ne fait pas de réclamation, l'espace physique consomé va comprendre les blocs utilisés, mais aussi les blocs inutilisés et les blocs libérés suite à des suppressions.

Si vous utilisez des disques virtuels de taille fixe sur des luns de taille dynamique (voir plus bas), l'espace physiquement disponible est alors amputé de nombreux blocs "vides".

 

Optimiser la consomation de stockage avec le Thin Provisionning coté SAN

L'utilisation de disques virtuels de taille dynamiques pose de nombreux soucis. Bien que les performances soient désormais aussi bonne (voire meilleures dans certains cas) que les disques fixes, leur utilisation nécessite une grande maturité dans la gestion de la capacité. Un Lun plein à 100% aurait des conséquences catastrophiques pour toutes les VM du Lun qui deviendraient incapable d'écrire quoi que ce soit (Stopping Critical).

L'utilisation de disques virtuels de taille fixes reste donc un "best practice" de prudence, malgrès la sur-consomation d'espace vide qu'ils engendrent.

Cependant, les constructeurs de stockage présentent eux aussi du stockatge "virtualisé", en exposant une capacité logique et non plus physique (C'est ce que l'on appelle le Logical Volume Management, en homage aux Unix sur lesquels cette abstraction du stockage est apparue).

 

Cette virtualisation permet la présentation de Volumes et de Luns "Logiques" Thin provisionnés. Comme pour les disques virtuels dynamiques, cela permet d'optimiser l'espace de stockage et de présenter plus de capacité que ce que la baie de stockage en contient réellement (Sur-allocation).

 

Cette Sur-allocation est indispensable à une gestion efficiente du stockage, surtout quand on doit gérer de grosses quantités de machines virtuelles.

La Sur-Allocation, Pourquoi ?

Et bien parce que le stockage alloué aux machines virtuelles est constitué de beaucoup d'espace vide, et plus vous avez de VM plus vous "gaspillez d'espace", ce qui au bout, se traduit en dizaine voire centaines de millier d'euros.

 

On descend donc le problème, non plus au niveau du LUN, mais au niveau plus global de la baie de stockage. Il faut alors monitorer l'espace physique consommé pour s'assurer qu'il reste dans un intervalle acceptable.

La gestion de la capactié au niveau de la baie reste cependant beaucoup plus simple, et permet de bénéficier de nombreux mécanismes offerts par les constructeurs (notamment la déduplication).

 

Les VHDX fixes, Thin provisionning Friendly

Si votre baie SAN le supporte, les fichiers VHDX prenent en charge directement les commandes Unmap. En résumé, ce mécanisme va vous permettre de bénéficier des avantages du thin provisionning, même avec des disques fixes, si vous utilisez des Luns dynamiques coté SAN.

Pour que cela fonctionne, il faut respecter une liste de pré-requis.

  • Le système d'exploitation de la VM est Windows 2012 à minima
  • Le disque virtuel est de format VHDX
  • Le disque est virtuel est attaché à un bus SCSI
  • La machine virtuelles tourne sur un Hyper-V 2012 à minima
  • La baie SAN est compatible avec les commandes Unmap.

Si tous ces pré-requis sont remplis, lors de la suppression d'un fichier, le driver Hyper-V va passer directement les commandes Unmap à la baie SAN.

Cela signifie que tous les fichiers supprimés seront automatiquement remis à disposition... mais, il y a un mais...

 

Avec trim

 

Les limitations et les problèmes posés par Trim / Unmap

Il est nécessaire de différencier plusieurs mécanismes.

  • Le Zeroing de l'espace vide (Réalisé lors de la création d'un disque virtuel de taille fixe ou avec l'utilisation d'un outil tiers).
  • Le Space Reclaim, qui permet, si la baie SAN le propose, de remettre à disposition les blocs à 0.
  • Le Trim / Unmap, qui "démappe" à la volée les fichiers supprimés.

Ces mécanismes vont permettre d'optimiser la consomation physique du stockage, notamment quand on utilise des disques fixes sur des luns dynamiques.

Malheureusement, si Trim et Unmap fonctionnent très bien avec des disques de type "Flash", ces commandes peuvent dans certains cas poser de gros soucis de performances (notamment lors de la suppression de fichiers  de grande taille). Microsoft nous met d'ailleur en garde.

 

Processing trim commands can reduce performance of some of the storage hardware because it may delay servicing of reads and writes while servicing a trim notification.

 

En gros, on peut dans certains cas complètement bloquer les IO d'une VM en attendant la réalisation d'une commande Unmap.

On retrouve le même genre de mise en garde chez Netapp qui recommande la désactivation du Trim dans les machines Guest (Bug ID 604916)

In a SAN environment, the SCSI UNMAP command can, under certain circumstances,

 cause degraded system performance. The SCSI UNMAP command is used by

 operating systems such as VMware vSphereB. 5 and higher and Microsoft Windows

Server 2012.

 

Exemple issu du terrain :

Un Guest Cluster SQL Allways On qui effectue tous les jours une sauvegarde locale d'une base de plusieurs To.

Pour des raisons de place, seule la sauvegarde J-1 est conservée, les plus anciènne étant supprimées... provoquant un unmap très consomateur.

Il peut en résulter un Freeze, voir un crash complet de la VM, le cluster ne va pas aimer.

Idem si vous tentez d'effectuer un formatage rapide d'une partition de plusieurs To dans une machine virtuelle. Le formattage risque de prendre plusieurs heures voir de planter la machine !

 

Pour palier à ces soucis plusieurs contournement peuvent êtres proposés.

  • Utiliser des LUN de taille fixe (Pas toujours possible).
  • Désactiver le Unmap sur les machines virtuelles (au détriment d'une augmentation de la consomation physiques).
  • Mettre en place des processus de maintenances dans les VM (SDelete) pour récupérer l'espace libre si le trim est désactivé
  • Désactiver la prise en charge de la commande Unmap directement sur la baie (Pas forcément une bonne idée).

La désactivation du Trim/Unmap est géré par la commande suivante.

fsutil behavior Set disabledeletenotify=1

 

La clef de registre associée est la suivante.

HKLM\System\CurrentControlSet\Control\Filesystem\DisableDeleteNotify

 

Au final, il n'est pas si simple d'évaluer l'opportunité de laisser activé ou non cette fonction, voici quelques règles de prudence.

  • Faite valider que votre baie San supporte correctement la fonction (KB, Bugs connus etc.)
  • Effectuer plusieurs tests pour vérifier le comportement de la baie et de vos VM (Effectuer pluiseurs formattage rapide d'un disque virtuel de plus de 1To par exemple).
  • Dans le doute, désactiver la fonction Trim dans les machines virtuelles.
  • A moins de mettre en place un process de maintenance de type SDelete sur les hôtes, laisser le trim activé sur les Hyper-V pour récupérer l'espace alloué aux VM supprimées.

 

Pour aller plus loin.

Plan and Deploy Thin Provisionning

Composant

Description

NTFS Boot Sector

Block désigné par le Bios qui renseigne la structure du File System et qui indique l'emplacement du volume bootable.

Master File Table

Contients les informations nécessaires pour la localisation des fichiers ainsi que ces attributs.

File System Data

Les données.

Master File Table Copy

Copie de sécurité de la MFT.

Mise à jour le Mardi, 12 Avril 2016 19:26
 
Bannière

Joomla! is Free Software released under the GNU/GPL License.