Nous profitons de la sortie de FreeNAS 9.3, qui introduit le support des primitives VAAI TPST et TPSTUN, pour dissiper, une bonne fois pour toute on l’espère, le brouillard de bullshit récurant autour du thin on thin (en mode block).

Pour rappel, TPST(W) et TPSTUN, respectivement Thin Provisioning Space Threshold (Warning) et Thin Provisioning Stun, ont été introduites avec vSphere 5.0 très probablement pour répondre aux énormes risques que représente le thin on thin aka stocker un vmdk thin sur un LUN thin (TPSTUN existait en 4.1 sous le nom Out of Space Condition mais uniquement via plugin constructeur).

En effet, l’espace disponible d’un datastore VMFS est calculé de l’espace consommé par rapport à la taille du filesystem (SCSI oblige) contrairement à un datastore NFS qui interroge la baie/serveur pour le savoir. Ainsi, ESX n’a aucun moyen de savoir s’il reste assez ou plus (+) d’espace qu’il ne le croit. TPST (0×6 0×38 0×7) et TPSTUN (0×7 0×27 0×7) permettent à la baie/target de palier précisément à ce problème en envoyant aux clients/initiator des commandes SCSI lors du passage d’un certain seuil et/ou lorsqu’il n’y a plus d’espace du tout.

Soyons clair : thin|thick on thin sans TPSTUN + saturation de la baie = corruption de VM. Vous pouvez facilement le vérifier en faisant un test et sachez que nous l’avons vécu en production avec nos confrères vmdude et dagnu. On était content d’avoir du (veeam) backup…

Avant de rentrer dans le détail, voici un aperçu de notre vision des avantages et inconvénients des différentes combinaisons thin|thick on thin|thick :

• thick on thick : le top du top dans tous les domaines sauf celui le la rentabilité. Presqu’aucune intervention humaine n’est nécessaire excepté si les VM subissent des snapshot. Financièrement, c’est évidement la pire des solutions.
• thin on thick : le meilleur compromis. Seul l’espace touché est consommé (coté VMware) et en cas de datastore full seules les vm qui veulent grossir sont freezées.
• thin on thin : le rêve des admins SAN, le cauchemar des admins VMware. Cette solution nécessite un monitoring au top du sol au plafond et des tests de validation avant mise en production. Sans les primitives TPST et TPSTUN, cette solution est très proche de la roulette russe.
• thick on thin : les inconvénients du thin on thin sans les avantages. Vous pensez réserver l’espace en faisant du eagerzeroedthick mais en réalité la baie récupère les zéros et compresse le reste. Heureusement TPSTUN agit aussi sur les vmdk thick.

Concentrons nous sur le thin on thin puisque c’est la solution (assumée) qui tend à s’imposer officiellement (oui, avant vous “pensiez” faire du thin on thick). Tant que tout va bien, vous n’avez à craindre que l’impact du thin des vmdk. Mais quand l’espace vient à manquer dans la baie, on espère pour vous que ça se passe comme ça :

Lorsque vous aurez atteint le seuil (parfois) configurable du TPST, disons 75%, vous aurez droit à du “0×6 0×38 0×7″ dans vos logs à une fréquence qui dépend de son implémentation dans le logiciel qui contrôle la baie. Ces messages génèrent des événements esx.problem.scsi.device.thinprov.atquota et vob.scsi.device.thinprov.atquota que vous retrouverez dans le vCenter (alarme possible) sous la forme suivante :

Space utilization on thin-provisioned device naa.xyz exceeded configured threshold. Affected datastores (if any): “xyz”.

Si vous ne faites rien, vous finirez par atteindre le fond du panier et vous mangerez les fameux “0×7 0×27 0×7″. A ce moment là, ESXi freezera n’importe qu’elle VM demandant plus (+) d’espace et vous aurez droit à ce genre de message :

There is no more space for virtual disk xyz.vmdk. You might be able to continue this session by freeing disk space on the relevant volume, and clicking Retry. Click Cancel to terminate this session.

A cet instant précis, la seule et unique bonne chose à faire est de libérer de l’espace sur la baie. Nous avons à peu prés tout essayé de l’UNMAP jusqu’au VMFS3.OpenWithoutJournal sans obtenir de résultat stable. Si vous atteignez le “No space left on device“, la LUN est démontée et toutes vos VM passent en “inaccessible”. Et vous êtes dans la mer*e.

Notre conseil : testez, essayez de remplir/vider/re-remplir un LUN avant de partir en production (on à déjà vu des cas où TPST remontait mal voir pas du tout), monitorez bien les différents messages et commandes SCSI. Mais surtout, ne partez pas du principe que la baie ne sera jamais full…

Et pour ceux qui croiraient encore aux vertus du thick on thin, on vous laisse apprécier les joies d’un datastore full alors que le LUN ne l’est pas :

MAJ 07.06.2013 : Nouvelle version 2.1 plus rapide et dotée des nouveaux paramètres -onlyfree (pour ne retourner que les LUN vides) et -minVMFSsizeGB (pour ne retourner que les datastore d’une taille minimum de xGB – 1GB par défaut)

Avec la cmd-let Get-ScsiLunPath, il est très facile de repérer les “dead path” sur un ou une liste d’ESX et c’est d’ailleurs de cette façon que vCheck v5+ les obtient. Le problème est qu’il n’est pas facile ensuite de faire le rapport avec le datastore concerné et si c’est bien d’un datastore dont il est question (cela peut être un périphérique de stockage autre comme un lecteur cdrom ou une clef usb par exemple).

Nous avons donc créé pour cela un script avec la collaboration de notre ami JJR (qui souhaite conserver l’anonymat dans cette affaire) qui nous a été d’une grande aide en ce qui concerne l’optimisation du script lorsqu’il est exécuté sur un gros environnement. Ce script génère une liste des chemins de LUN (dead ou non selon le paramétrage) avec les informations suivantes :

• ClusterName : nom du cluster
• ESX : nom de l’ESX
• CanonicalName : LUN identifier
• Runtime : vmhba<Adapter>:C<Channel>:T<Target>:L<LUN>
• State : active, standby ou dead
• IsWorkingPath : true ou false
• LunSize : exprimé en MB, GB ou TB (le cas échéant)
• Datastore : nom du datastore VMFS (le cas échéant)
• UUID : VMFS UUID (ou “cdrom” si le périphérique est un lecteur optique)

Pour plus d’informations, nous vous recommandons de consulter la kb Identifying disks when working with VMware ESX

Voici le détails et les valeurs par défaut des paramètres disponibles :

• cluname : permet de spécifier un cluster (parcours tous les hosts par défaut)
• nofile : n’affiche que le résultat dans la console et ne génère pas de fichier (“0″ par défaut)*
• html : génère un fichier html au lieu d’un csv (“0″ par défaut)*
• onlydead : ne liste que les chemins “dead” (“1″ par défaut)
• onlyvmfs : ne liste que les chemins de LUN comportant un datastore VMFS (“0″ par défaut)

* le fichier est généré dans le répertoire de travail.

Exemple d’usage pour afficher tous les chemins d’un cluster :

.\Get-DeadPath+.ps1 -cluname "CLU01" -html "1" -onlydead "0"

Exemple d’usage pour n’afficher que les chemins “dead” :

.\Get-DeadPath+.ps1 -html "1" -onlydead "1"

Nous ne manquerons pas mettre à jour vCheck en conséquence.

download