vExpert VSAN 2016

C’est avec un immense plaisir que je viens de voir que mon nom faisait partie de la liste (très intime, nous ne sommes que 32) des vExpert VSAN 2016.

vExpert_-768x506

En effet, pour la cuvée 2016, VMware a décidé de proposer des spécialités en plus de la nomination générale vExpert. Ainsi, 2 programmes ont vu le jours correspondant a leurs produits phares du moment, vExpert NSX et vExpert VSAN et les résultats viennent juste d’être annoncés.

VMware_vExpert_on_Twitter_The_#vExpert_#VSAN_pro_2016-08-18_22-28-09

Félicitation à tous, et enjoy VSAN !

giphy

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}))}
Page 1 sur 29123451020Dernière page »