Plugin vCenter sshAutoConnect

sshAutoConnect_feat

Update 2016/05/16: Grace à @jmauser une release Github a été créée avec support de vSphere 6.0 Update 2. Vous pouvez la télécharger ici.

Voilà notre premier plugin pour vCenter ! Cela faisait un petit moment que ça traînait dans la todolist, voilà maintenant une chose de moins :p

sshAutoConnect est donc un plugin pour vCenter ou plus exactement pour vSphere Client.

Dans votre console vSphere Client, une fois connecté, lorsque vous cliquez sur « Plug-ins > Manage Plug-ins…« , vous arrivez sur la page de gestion des plugins et vous voyez ceux qui sont installés/activés/disponibles :

Le plugin sshAutoConnect va vous permettre de vous connecter automatiquement en SSH sur vos serveurs ESX/i directement depuis la console vSphere Client.

Si vous êtes comme dans notre cas où vous avez pas mal de serveurs ESX/i à gérer, ça devenait un peu limite de devoir lancer à côté PuTTY pour se connecter aux serveurs voulus.

On a donc décider de faire un plugin pour intégrer cette fonctionnalité au client vSphere.

Installation

Comme tout plugin du client vSphere, il suffit de télécharger l’archive zip ci-dessous et de la décompresser dans le dossier d’installation des plugin vCenter client et relancer le client vSphere, par défaut :

C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Plugins

Configuration

La configuration du plugin est limité au maximum. Le plugin est livré avec un fichier sshAutoConnect.xml dans le même dossier qui permet de renseigner des credentials à utiliser lors de la connexion automatique (facultatif) :

<?xml version="1.0" encoding="utf-8" ?>
<credentials>
  <default>
    <login>root</login>
    <password>d3d3LnZtZHVkZS5mcg==</password>
  </default>
  <custom_servers>
    <server name="server-esx-01.vmdude.fr">
      <login>root</login>
      <password>d3d3Lmh5cGVydmlzb3IuZnI=</password>
    </server>
    <server name="server-esx-02.vmdude.fr">
      <login>root</login>
      <password>d3d3LnZtd2FyZS5mcg==</password>
    </server>
  </custom_servers>
</credentials>

Le fichier xml comporte 2 sections : <default> et <custom_servers>

La partie <default> sera utilisée si le serveur auquel vous voulez vous connectez n’existe pas dans la partie <custom_servers>. Cela permet de définir des exceptions pour certains serveurs.

Si ce fichier n’existe pas, le plugin ne fournira pas de credential lors de la connexion SSH, et donc l’utilisateur devra s’authentifier normalement.

Note : Les mots de passe mis dans le fichiers de configuration sont encodés en Base64, vous pouvez regarder sur notre précédent billet pour l’encodage/décodage en Base64 en Powershell : Manipulation en base64

Utilisation

L’utilisation du plugin est simple, il suffit de faire un clic droit sur le serveur ESX/i sur lequel vous voulez vous connecter et de cliquer sur le bouton sshAutoConnect :

Téléchargement

  • Voici l’archive .zip qui contient le dossier de plugin avec la dll du projet et un fichier .xml d’exemple : sshAutoConnect
  • Et voici les sources Visual Studio 2010 du projet (comme d’habitude compilable avec MSBuild/csc/VisualStudio) : sshAutoConnect-sources

Note : un grand merci à R0llB4ck pour son aide et son trick sur les Embedded Resource en C#

Kill Them All

Durant nos tribulations sur des phases de troubleshooting, nous avons rencontré un cas intéressant qui nous a mis face à un casse-tête (ça tombe bien, c’est le genre de chose que nous aimons :) ).

homer-thinking

Pour résumer, nous avions un serveur ESXi dont le processus hostd ne répondait plus, son état dans le vCenter était donc en Not Responding (bien évidement, au bout de quelques instants, les VM qui étaient hébergées dessus ont été redémarrées normalement par HA sur d’autres serveurs ESX du cluster, jusque-là rien de bizarre).

En se connectant en console HP ILO sur le serveur ESX (le daemon SSH ne répondait plus non plus), nous nous sommes rendu compte qu’il y avait un souci avec le pilote des cartes réseaux (un fameux problème connu de pilote ELXNET sur ESX 5.5 lié au Native Driver), faisant perdre toute connectivité des vmnic (lien down, ce qui explique la perte de connexion de l’ESX).

Cette perte de connexion a laissé le serveur ESX sans accès au stockage NFS (forcement) et avec des instances de VM qui tournent dans le vide (puisqu’il n’y avait plus de réseaux/stockage).

Le cas intéressant qui nous a donné envie de faire ce billet a découlé de notre volonté de passer le serveur en maintenance dans cet état.

Nous voulions mettre le serveur en maintenance, mais les instances VMM tournaient encore sur le serveur ESX donc pas possible de mettre en maintenance. Nous avons donc entrepris de killer ces instances, au début via l’option ‘k’ de esxtop en spécifiant le world-id. Cependant, la connexion ILO ne permettait pas de faire du copier/coller, et en plus, nous étions sur une connexion VPN avec une latence digne des années 1980, donc effectuer cette opération sur quelques 70 instances allaient prendre beaucoup trop de temps (surtout à 3h du matin…).

minitel

En feignants que nous sommes, nous avons donc voulu automatiser cela, en minimisant les commandes à taper du fait du copier/coller non fonctionnel (nous vous avons prévenu, le maitre mot ici est ‘feignant’).

Nous sommes donc arrivés à ce petit script bash qui utilise le namespace esxcli vm process kill. Ce script va killer toutes les instances VMM (en mode hard, donc trash direct attention !!!) présent sur un serveur ESX:

for vmid in esxcli vm process list | grep "World" | cut -f2 -d: 
do 
esxcli vm process kill --type hard --world-id $vmid
done

Une fois cela fini, nous avons pu mettre le serveur en maintenance et continuer notre troubleshooting pour aller se coucher quelques heures plus tard :)

C’est bien entendu à utiliser en dernier recours, mais cela nous a bien rendu service :)

vExpert 2016

Comme chaque année, VMware vient de publier la liste des vExpert pour l’année 2016 (disponible ici avec un peu plus de 1350 entrées, ca commence a faire du monde ^^) et c’est avec honneur que je reçois cette nomination et renouvelle ce titre pour la 5ème année!

VMW-LOGO-vEXPERT-2016-k

five-stars

Nous tenions avant tout à vous remercier pour votre soutien! Un grand merci aussi à Corey Romero pour cette distinction et pour son travail sur le programme vExpert.

Pour la petite information, nous sommes 27 vExpert en France (la liste est disponible sur le billet de vmnerds.fr), et une liste des avantages vExpert (il en faut toujours ^^) est disponible sur le billet de CloudManiac.net

SolidFire vs DelayedAck

Pour faire suite au précèdent billet SolidFire vs Heartbeat ATS sur les soucis que nous avons eu avec des baies SolidFire, nous avons du désactiver un autre paramètre: DelayedAck

Pour faire simple, ce paramètre indique que le destinataire d’une trame TCP met en attente l’envoi de trame d’accusé de réception (ACK) afin de pouvoir grouper l’envoi de ces trames et ainsi diminuer la charge réseau nécessaire (dans le principe c’est plutôt une bonne chose ^^).

snake

La KB1002598 de VMware détaille aussi ce principe:

A central precept of the TCP network protocol is that data sent through TCP be acknowledged by the recipient. According to RFC 813, « Very simply, when data arrives at the recipient, the protocol requires that it send back an acknowledgement of this data. The protocol specifies that the bytes of data are sequentially numbered, so that the recipient can acknowledge data by naming the highest numbered byte of data it has received, which also acknowledges the previous bytes. ». The TCP packet that carries the acknowledgement is known as an ACK.

A host receiving a stream of TCP data segments can increase efficiency in both the network and the hosts by sending less than one ACK acknowledgment segment per data segment received. This is known as a delayed ACK. The common practice is to send an ACK for every other full-sized data segment and not to delay the ACK for a segment by more than a specified threshold. This threshold varies between 100ms and 500ms. ESXi/ESX uses delayed ACK because of its benefits, as do most other servers.

Le problème est que certaines baies iSCSI attendent de recevoir un segment ACK pour envoyer la trame suivante, ce qui peut amener à des timeout récurrents (c’est facilement visible en faisant une capture Wireshark par exemple), et donc une perte globale de performance.

The affected iSCSI arrays in question take a slightly different approach to handling congestion. Instead of implementing either the slow start algorithm or congestion avoidance algorithm, or both, these arrays take the very conservative approach of retransmitting only one lost data segment at a time and waiting for the host’s ACK before retransmitting the next one. This process continues until all lost data segments have been recovered.

Un point important de l’impact du DelayedAck par rapport au heartbeat VMFS se trouve un peu plus loin dans la KB:

Most notably, the VMFS heartbeat experiences a large volume of timeouts because VMFS uses a short timeout value

Par rapport au fonctionnement de la baie, le support de SolidFire nous a donc demandé de désactiver ce paramètre. Cela peut se modifier a tout niveau de la chaine iSCSI, c’est à dire au niveau de l’adapter, de la target et/ou des devices avec un principe d’héritage de la valeur (pratique pour appliquer ce paramètre de manière globale). Dans notre cas, comme le support de SolidFire demandait de le désactiver définitivement, nous l’avons donc fait directement au niveau de l’adapter:

Advanced_Settings_2015-07-28_17-43-05

Configuration ESXi > Storage Adapters > iSCSI Adapter > Properties > General Tab > Advanced

Afin de pouvoir afficher rapidement l’état de cette valeur sur toute une plateforme, nous avons fait un petit OneLiner rapide:

Get-View -ViewType HostSystem -Property Name, Config.StorageDevice.HostBusAdapter | Select Name, @{Name="DelayedAck"; Expression={($_.Config.StorageDevice.HostBusAdapter.AdvancedOptions | ?{$_.key -eq "DelayedAck"}).value}}

Ensuite, afin de pouvoir désactiver ce paramètre sur toute la plateforme, nous avons fait un autre OneLiner (vous pouvez le relancer autant de fois que vous voulez, il y a une vérification effectuée pour ne changer la valeur que si c’est nécessaire):

Get-View -ViewType HostSystem -Property Config.StorageDevice.HostBusAdapter, ConfigManager.StorageSystem -SearchRoot (Get-View -ViewType ClusterComputeResource -Filter @{"Name" = "nom du cluster a mettre a jour"}).MoRef | ?{ ($_.Config.StorageDevice.HostBusAdapter.AdvancedOptions | ?{$_.key -eq "DelayedAck"}).value} | %{ (Get-View ($_.ConfigManager.StorageSystem) ).UpdateInternetScsiAdvancedOptions( ($_.config.storagedevice.HostBusAdapter | ?{$_.Model -match "iSCSI Software"}).device, $null, (New-Object VMware.Vim.HostInternetScsiHbaParamValue -Property @{Key = "DelayedAck"; Value = $false}))}

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

Page 1 sur 29123451020Dernière page »