SolidFire vs Heartbeat ATS

Nous avons rencontré un cas intéressant sur une nouvelle plateforme VDI qui est hébergée sur des baies SolidFire. Lors de test de démarrage massif de machines virtuelles (boot storm), nous perdions la main sur les serveurs ESX, qui passaient en ‘Not Responding’ sur le vCenter, avec hostd unresponsive dès le moment où nous voulions effectuer des actions locales (console et/ou SSH).

En fouinant sur le net, nous sommes tombé sur une KB IBM qui détaille un comportement similaire : Host Disconnects Using VMware vSphere 5.5.0 Update 2 and vSphere 6.0 et qui met en cause le nouveau comportement du Heartbeat ATS depuis la version vSphere 5.5U2, à savoir l’offload de la partie heartbeat I/O à la baie via la primitive VAAI ATS.

heartbeat

En continuant à chercher sur cette piste, nous sommes retombés sur un très bon article de Cormac qui détaille un peu plus ce mécanisme, et surtout le changement depuis la version 5.5U2 : Heads Up! ATS Miscompare detected between test and set HB images

Aujourd’hui une KB officielle VMware existe pour ce souci : KB2113956, dont voici un extrait qui détaille le changement de comportement du heartbeat ATS avant et après 5.5U2 :

A change in the VMFS heartbeat update method was introduced in VMware vSphere ESXi 5.5, Update 2 to help optimize the VMFS heartbeat process. Whereas the legacy method involves plain SCSI reads and writes with the VMware ESXi kernel handling validation, the new method offloads the validation step to the storage system. This is similar to other VAAI-related offloads.
This optimization results in a significant increase in the volume of ATS commands the ESXi kernel issues to the storage system, and resulting increased load on the storage system. Under certain circumstances VMFS heartbeat using ATS may fail with false ATS miscompare which causes the ESXi kernel to reverify its access to VMFS datastores. This leads to the Lost access to datastore messages.

Le Support Request qui avait été ouvert auprès de SolidFire confirme plus ou moins ce problème, voici un extrait de leur réponse :

SF is a 4K block size array internally but ESX only works with 512-byte blocks. ESX issues single 512-byte block ATS commands, which requires the SF array to perform an internal read-modify-write for every ATS command. If ESX could issue a 4K ATS command (eight 512-byte blocks) our ATS performance should be better. Essentially, every ATS operation is an unaligned I/O.

La recommandation finale a été de désactiver la partie Hearbeat ATS pour rebasculer sur des réservations SCSI-2 classiques (pour la partie Heartbeat uniquement bien entendu).

Cela peut se faire en PowerCLI comme l’indique la KB VMware:

Get-AdvancedSetting -Entity VMHost-Name -Name VMFS3.UseATSForHBOnVMFS5 | Set-AdvancedSetting -Value 0 -Confirm:$false

Nous verrons dans un prochain billet la modification d’un autre paramètre, DelayedAck

Laisser un commentaire

Required fields are marked *.