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 :

Follow the Migrate Virtual Machine Wizard to select the ESX 3.0.1 host and VMFS3 datastore destination. The Wizard validates the destination and moves the configuration files of the virtual machine and virtual disks to the new VMFS3 datastore.

Depuis, nous avons étudié, testé, troubleshooté, et utilisé en production (de manière parfois intensive) cette fonctionnalité (qui a beaucoup évolué depuis 2007) devenue presque banale depuis SDRS.

C’est au moment où nous croyons tout savoir du mécanisme que nous prenons une grande claque d’humilité lors d’une migration de plusieurs centaines de VM et que nous nous apercevons pour la première fois qu’un svmotion d’un vmdk thin (ou Lazy Zeroed) génère 2 fois plus d’écritures que de lectures :

Nous n’avions jamais fait le rapprochement entre un svmotion et un sujet qui a longtemps fait polémique :

Because zeroing takes place at run-time for a thin disk, there can be some performance impact for write-intensive applications while writing data for the first time.

Et le pire c’est qu’il nous a fallu un temps infini à l’échelle de Google pour tomber sur un thread reddit où un VCDX explique tout d’une seule phrase :

It has to zero the block before writing the actual data.

Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).

A titre de démonstration, voici un visualEsxtop de 2 svmotion consécutifs de la même VM entre 2 datastore, avec et sans le setting DataMover.HardwareAcceleratedInit :

Ce n’est pas une défaillance de votre téléviseur, avec le zeroing offloadé à la baie c’est presque 2 fois plus rapide (ou 2 fois moins long si vous préférez…).

Ce comportement n’a évidement aucun rapport avec la “non-récupération” des zéros lors d’un svmotion… Bien qu’il semble etre possible de le forcer d’une manière non supportée !

Nous avons alors utiliser vmkfstools pour créer un vmdk eagerzeroedthick et constater l’offload de création de zero mais il semble que ce ne soit pas fonctionnel (ZERO_F) :

Par contre, le UNMAP (vmkfstools -y 99) semble bien fonctionner :

Nous profiterons du VMworld 2013 pour demander à Cormac Hogan si cela signifie qu’ESXi supporte le TRIM, entre autres…

Disons que vous souhaitez limiter la possibilité de faire un snapshot sur vos vm uniquement s’il y a suffisamment d’espace sur les datastore, vous utiliseriez notre beau petit one-liner fait main :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.minFreeSpace"; Value="$($($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum)"}))}))}

Ce script fixe le snapshot.minFreeSpace à la somme de la taille des vmdk (taille max d’un snapshot) et se limite aux vm dont les vmdk résident sur un seul et unique datastore.

Mais avant de passer ce script, peut être voudriez vous vérifier que vous n’avez pas des vm déjà dans cette situation ? Cet autre petit one-liner vous donnera la liste de chaque vm dont la taille totale est supérieure à l’espace libre du datastore où elle réside :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum -gt ((get-view -viewtype datastore -property name,summary -filter @{"name" = ($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique)}).Summary.FreeSpace)}|select name

Voila maintenant 1 mois que nous participons à des tests avec les gens de chez nexenta concernant un problème lié à la routine Atomic Test & Set (ATS) de VAAI. Le symptôme est assez radical : lors de certaines opérations courantes (svmotion par ex.), la LUN reste lockée donc inaccessible jusqu’à ce qu’elle soit “re-maskée” ou que le serveur nexenta soit rebooté.

Jusqu’à ce que le bug soit corrigé, l’option la plus rapide est de désactiver l’ATS. L’idéal c’est un petit one-liner powershell qui le fait sur tous vos ESX :

Get-VMHost|Set-VMHostAdvancedConfiguration -name VMFS3.HardwareAcceleratedLocking -Value 0

Attention aux LUN en VMFS5 natives qui ont été créées avec VAAI actif car elles sont tagguées “ATS-only”, ce qui veux dire qu’il n’est pas possible de les réserver en SCSI-2 classique. Pour désactiver ce mode, il faut utiliser la commande vmkfstools avec le paramètre ”configATSOnly“.

Nous tenons à préciser que ce problème n’est pas lié à celui du UNMAP.

• SCSI Write Same (zeroing)
• SCSI ATS (lock only the specific region on the LUN)
• SCSI Block Copy (instruct the array to perform a block copy)
• SCSI Unmap (return freed blocks in a zvol)

Je vous laisse imaginer l’intérêt d’une solution gratuite (jusqu’à 18To raw max pour la CE) supportant VAAI et reposant sur ZFS (ARC, L2ARC, in-line deduplication, in-line compression, snapshots and copy-on-write clones, RAID-Z, native NFSv4 ACLs, continuous integrity checking and automatic repair, …) face à toutes les appliances payantes du marché.

Et juste pour le plaisir des yeux :