Utiliser le Thin Provisionning sous VMware vSphere 4

Une des avancées majeures de vSphere 4 concerne le support du Thin Provisionning qui permet d’économiser de l’espace disque sur un SAN en donnant la possibilité à l’administrateur de spécifier à des disques virtuels de ne consommer que la place réellement utile et de grandir au besoin, plutôt que d’allouer tout l’espace par défaut. Si la technologie est connue, son comportement sous vSphere mérite d’être mieux appréhendé.

Lorsque l’on déploie une machine, l’assistant Disk Format nous propose désormais l’option Thin provisioned format. Vous remarquerez au passage que seuls les systèmes de fichiers VMFS-3 supportent cette fonctionnalité.

Dans le montage ci-dessous, on a déployé le même template deux fois de suite. La première fois on a choisi Same format as source qui crée dans notre cas un disque Thick par défaut. La deuxième fois, on a choisi Thin provisioned format. On peut dès lors observer les différences d’allocation d’espace disque. La machine dont le disque utilise le Thin Provisionning ne consomme effectivement que 5,90 Go sur les 16 potentiels.

Lorsque l’on navigue dans le Datastore correspondant et qu’on ouvre le conteneur de la VM, on obtient la preuve que le Thin Provisionning est bien pris en compte.

Si maintenant on veut tester la fonctionnalité, il suffit de remplir l’espace disque vide en copiant des fichiers et constater l’agrandissement du disque VMDK en temps réel dans le Datastore.

Dans l’inventaire de la VM, un rafraîchissement de la vue du stockage indiquera la nouvelle allocation.

A partir de ces observations, vous devrez avoir compris le principe. Sachez toutefois que faire de la place sur un disque en Thin provisioned format ne provoquera pas une réduction du disque .vmdk pour autant. L’opération ne fonctionne en effet que dans un sens…

Le cas des snapshots

Etude de cas très importante que la création de snapshots en mode Thin Provisionning. Du moment où vous en aurez créé un, le provisionnement du disque augmentera automatiquement pour refléter les changements.

De retour dans le conteneur de la VM, vous découvrirez alors les fichiers habituels .vmsn et le nouveau .vmdk dans lequel les écritures s’effectueront jusqu’à la consolidation du snapshot. Lors de sa suppression, le provisionnement reviendra à son état initial.

Thin Provisionning rime avec planification

Si l’utilisation de cette technique est séduisante et permet de maximiser l’utilisation d’un SAN, n’oubliez jamais qu’elle peut vous amener à gérer des situations douloureuses, par exemple dans le cas où la taille totale de l’espace provisionné dépasserait l’espace disque total de votre Datastore à cause – pourquoi pas – de snapshots non maîtrisés.

La capture écran ci-dessous reflète l’utilisation la plus sécurisée de l’espace, dans le sens où la valeur Provisioned Space ne dépasse pas la valeur Capacity. C’est en revanche un constat extrêmement fréquent que de relever des valeurs de provisionning bien supérieures à la capacité totale physiquement disponible.

Pour éviter de vous faire surprendre par un volume plein, une seule solution invariable : monitorez plutôt deux fois qu’une le remplissage des disques, que ce soit par le biais d’alarmes dans le vCenter ou par un outil tiers !

Supprimez vos snapshots avant d’agrandir un disque VMDK dans VMware vSphere

Dans un environnement de production, les administrateurs effectuent maintes tâches qui ne sont pas toujours relatées dans une fiche de suivi du serveur (c’est mal). Cela amène parfois des situations problématiques – heureusement pas trop souvent – ou bien des anecdotes similaires à celle dont je vais vous parler ici.

Prenez un environnement VMware où l’on a la possibilité d’effectuer des snapshots à tour de bras en quelques clics. Derrière la qualité de travail indéniable que cela procure au quotidien, le premier travers que l’on subit tous consiste à oublier de les supprimer après avoir validé ses modifications ou installations. Vous savez peut-être qu’un snapshot consiste à transférer indéfiniment toutes les écritures disque d’une VM vers un nouveau disque VMDK, jusqu’à ce ledit snapshot soit consolidé. Outre l’insidieux problème de place disque que cela peut au final engendrer sur votre LUN, il y a d’autres opérations qui seront impossibles. C’est justement le cas de l’agrandissement d’un disque VMDK.

Dans la capture écran ci-dessous, la machine possède deux disques VMDK. Nous voulons augmenter la taille du deuxième disque et surprise, la case est grisée. L’opération est donc impossible. Comme toujours, les utilisateurs qui demandent d’agrandir un disque n’ont pas anticipé le remplissage du volume…ni les administrateurs qui n’ont peut-être pas pensé à mettre des compteurs WMI sur le serveur ou tout simplement à prendre le temps de régler le problème.

Un rapide debug permet de se rendre compte qu’une opération non rapportée a consisté à créer un snapshot avant une installation de SQL Server 2005.

Cela fait des semaines que la machine était utilisée et qu’un snapshot était toujours présent…prenant tout de même 12 Go de disque ! Heureusement que la virtualisation VMware est fiable ; une simple suppression du snaphost oublié permet de repartir avec un VMDK consolidé et d’avoir de nouveau accès à l’agrandissement du disque.

Comment éviter cela à l’avenir ?

• Mettez en place une routine de vérification de l’ancienneté des snapshots (via PowerCLI par exemple)
• Notez TOUTES vos modifications sur une fiche de suivi de serveur pour que la personne qui interviendra derrière vous ne perdre pas de temps à découvrir la situation

Pour finir, je vous invite à lire l’article Utiliser diskpart pour étendre un disque Windows qui vous donnera plus d’informations quant aux opérations Windows postérieures au Disk Provisionning.