thin|thick on thin|thick chick chicky boom

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 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 :

Tags: , , , ,

PunchZero online

Depuis l’apparition du thin provisioning, la question de la récupération de l’espace disque libéré après allocation refait surface régulièrement.

Historiquement, il suffisait de “zeroer” l’espace libre inGuest et faire un storage vmotion vers n’importe quel autre datastore pour récupérer l’espace “zeroé” grâce au datamover fsdm qui zappe les zéros. Malheureusement, depuis l’apparition du datamover fs3dm dans vSphere 4.0 cet avantage a disparu comme l’explique Duncan dans un vieux post de 2011.

A cette époque, il était courant d’avoir des datastores configurés avec des blocksize différents ce qui permettait de contourner le problème facilement. Aujourd’hui, VMFS 5 a changé cette approche avec le blocksize unifié à 1M.

Pour tricker comme avant et forcer fsdm à faire le boulot il faut une rupture technologique VMFS <> NFS ou jouer avec un paramètre caché de vsish comme l’indique William Lam dans son commentaire :

Whether VMFS should handle data movement requests by leveraging FS3DM

Et depuis le temps que nous voulions le tester, nous sommes enfin tomber sur une VM avec ~60Go à récupérer dans un environnement VMFS5 only:

Un coup de sdelete -z plus tard, on change le paramètre /config/VMFS3/intOpts/EnableDataMovement dans vsish et on lance un storage vmotion.

Au passage on remarque bien la phase de lecture sans écriture pendant le svmotion :

Après la migration (qui vous permettra aussi de renommer officiellement les fichiers de votre VM), la VM a maigri comme il faut :

Pour ceux qui voudrait tout simplement le faire offline, il y a l’option –punchzero de vmkfstools.

Tags: , , ,

Large Pages on Demand

Comme nous vous l’avions promis, voici un retour d’expérience sur l’implémentation du paramètre LPageAlwaysTryForNPT à “0″ qui force ESX à n’allouer une Large Page que lorsque le GuestOS d’une VM le lui demande explicitement et qui permet de bénéficier de TPS sans attendre que l’ESX n’ait à les “casser” en cas de contention.

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

Afin d’avoir une meilleure visibilité sur ce qui change au moment où nous avons activé le paramètre et lancé une vague de vmotion au sein du cluster pour l’appliquer, nous avons utilisé les mêmes compteurs que le “dashboard” Guest Memory (aka ResourcePoolQuickStats) pour en faire un rrd sous cacti (avec les même couleurs) :

Un gain immédiat de 20% de RAM sans consommation CPU supplémentaire ni augmentation manifeste de latence (dans notre cas) :

Et pour ceux qui se posent la question, dans ce cluster cumulant 1.5To de RAM attribuée à des VM Windows 2008 R2 et RHEL 6 x64, seulement 40Go de Large Pages sont allouées en moyenne.

Moralité, TPS c’est bon, mangez-en !

Tags: , , , , ,

storageRM level 1

Instruit par la kb Troubleshooting Storage I/O Control (1022091), nous nous sommes rendu compte qu’en fixant le log level à 1, le service storageRM crachait les informations de latency, qdepth et iops des datastores concernés dans les logs d’ESXi (et donc vers le(s) serveur(s) syslog) toutes les 4 secondes. Sur une grosse infra ça peut faire beaucoup mais ça offre de belles perspective de monitoring/troubleshooting :

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

Tags: , , , , ,

Purple Screen on Demand – MAJ

MAJ 19/10/2014 : Le patch ESXi550-201410001 règle le problème sans un mot dans les release notes ni les fixed PRs

MAJ 30/07/2014 : VMware vient de nous informer de la prise en compte du bug (PR 1286205) et que le correctif sera dispo Q4 2014 dans le patch 3 d’ESXi 5.5 :

Customer observed ESXi PSOD when polling IP-MIB. snmpd calling NetVsi_TcpipSysctlGet

Hormis la fameuse commande crashMe de vsish, il est généralement très difficile de reproduire un PSOD à la demande. Pourtant, nous avons trouvé un cas assez violent où l’utilisation de SNMPv3 via cacti fait crasher l’ESX de façon systématique et ce sur toutes les version depuis la 5.1 :

Evidemment, VMware est sur le coup. Pour info, nous avons utilisé le “walk through” de William pour la configuration.

Tags: , , ,