Hypervisor.fr

Lors d’une séance de troubleshooting impliquant un petit tour d’esxtop, nous nous sommes aperçu que les stats VAAI d’un SSD attaché localement comportaient des valeurs non nulles. un check avec esxcli nous confirme la bizarrerie, les deux SSD attachés en SATA “supportent” certaines primitives VAAI :

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…

Tags: esxtop, SSD, TRIM, VAAI

Si vos amis se moquent de vous parce que vous n’utilisez toujours pas le webclient, ils déballent surement les nouvelles features telles que l’onglet “Utilization” des cluster :

Disponible uniquement sur les resource pools dans le client legacy, cette vue synthétise l’utilisation “near real-time” cpu/ram du cluster des 5 dernières minutes (quickstats). Il suffit de créer un resource pool à la racine de votre cluster (sans reservations ni limites, les shares n’ont pas d’importances ici) pour avoir une visibilité comparable des ressources du cluster :

La vue “Guest Memory” se paye même le luxe d’être un peu plus détaillée graphiquement alors que la vue “Host Memory” est faussée par la mémoire allouée aux VM.

Tags: DRS, ResourcePool, sso, webclient

Ce post aurait du voir le jour il y a longtemps déjà mais vous savez ce que c’est, la crise, le réchauffement climatique toussa… Bref, vous n’êtes pas sans savoir que VMware a considérablement réduit l’overhead des VM depuis la version 5.0 en partie grâce au vmx swap (et encore un peu plus avec la 5.1 grâce au system swap) mais surtout en modifiant le comportement de la VMM selon le type de vMMU. En effet, après moult tests, nous nous sommes rendu compte qu’en swMMU l’overhead était comparable à ce qu’il était en version 4.x alors qu’en hwMMU l’overhead est environ 10x moindre.

Vous allez me dire “on s’en fout bien du swMMU, c’est old school et on a plus de VM sous Windows 2000 !” et je suis bien d’accord avec vous mais Duncan a récemment posté un billet très intéressant sur les notions de static et dynamic overhead et en particulier sur la réservation de mémoire lors d’un vmotion.

[...] the vMotion process aims to be conservative and uses static overhead memory instead of dynamic

Vous l’aurez compris, en swMMU c’est du static et en hwMMU c’est du dynamic mais pour certaines actions, les valeurs du static overhead font référence. Dans le cas d’une mise à jour d’un cluster un peu chargé cela peut avoir toute son importance compte tenu de l’écart de réservation être les deux techniques :

Et pour ceux qui aiment se faire du mal, on a essayez avec 1TB de vRAM (merci l’overcommit) :

Tags: memory overcommit, overhead

Aussi invraisemblable que cela puisse paraître, il peut arriver que vous ayez besoin d’empêcher le backup sur une VM sans être en mesure de l’exclure, ou le faire exclure, de l’outil de backup. Aux grands maux, les grands remèdes : on empêche les snapshots en PowerCLI (et à chaud).

Get-VM nobackup|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.maxSnapshots"; Value="0"}))}))}

Ça pique mais ça marche :

A general system error occurred: Exceeded the maximum number of permitted snapshots

Tags: powershell, veeam

MAJ 07/03/2014 : Le beta test du package ib-opensm-3.3.15 pour ESXi 5.5 est terminé et Andreas Peetz nous a fait l’honneur de le publier sur son vibdepot. Toutes les informations d’usage sont disponibles sur son wiki mais nous reprécisons que ce package n’est pas supporté pour VSAN à cause du timeout trop important en cas de (ré)élection du master opensm.

MAJ 30/01/2014 : Suite à d’autres problèmes de stabilité avec ESXi 5.5, nous retirons la version x64. Une nouvelle version est actuellement en beta test, n’hésitez pas à nous contacter pour la tester.

MAJ 26/11/2013 : Suite à des problèmes de stabilité, nous avons compilé la version 3.3.15 en 64bit et remis à disposition la 3.3.15 32bit en lieu et place de la version 3.3.16

MAJ 22/10/2013 : Nouvelle vib en version 3.3.16-64 qui apporte le support d’ESXi 5.5 (les binaires et librairies sont maintenant en 64bit) et rétrocompatible en 5.1 (probablement 5.0 aussi).

MAJ 02/10/2013 : Mise à jour du vib avec la version 3.3.16 d’opensm. Aucune version compatible avec ESXi 5.5 pour le moment.

Suite à notre post sur l’EZ Compact 6 il y a quelques mois, nous avons été victimes de “l’effet SSD” qui donne l’impression que n’importe quelle grappe de disques SAS 15K en stripping est une grosse brouette. En effet, après avoir goutté à un agrégea de SSD vous devenez immédiatement addict aux latences extrêmement faibles ainsi qu’aux débits improbables qui vous font douter de la bande passante théorique du PCIe. Mais pour en profiter au delà du serveur dans lequel se trouve vos précieux, il faut un protocole de transport plus rapide et performant que du simple GbE. Suite à quelques recherches, le choix du Fibre Channel en mode FC-P2P ou FC-AL s’avérait être le plus pratique (pas besoin de switch, seulement des cartes HBA et des fibres pour les relier) et peu coûteux compte tenu de l’immense marché de l’occasion.

Un petit tour sur eBay et nous voila avec notre FC@home qui nous a permis de faire des tests intéressants comme ceux pour notre post sur le MRU ranking mais aussi de profiter pleinement des performances des SSD. Le seul “inconvénient” du FC est de ne transporter que du block et donc de ne permettre qu’un accès à des LUN. Sur une petite baie de stockage ZFS c’est un réel problème car cela oblige à prendre certaines précautions concernant la taille des LUN présentées pour profiter des snapshots et de la compression. Il y a donc de fortes chances que vous soyez dans l’obligation de réserver une quantité d’espace non négligeable pour éviter de saturer le zpool.

Nous partons alors en quête de cartes réseau 10GbE avec lesquelles nous pourrions faire du NFS mais aussi des vmotion à des vitesses indécentes. Malheureusement ce matériel reste encore très cher pour un particulier à l’heure actuelle y compris d’occasion. Après quelques recherches, nous avons trouvé une solution très abordable (en occasion toujours) permettant de faire du block ainsi que du réseau à des débits hallucinants et avec des temps de latence extrêmement faibles : l’infiniband !

L’infiniband est un type de réseau très particulier permettant à la base de transporter des messages :

The basic idea behind InfiniBand is simple; it provides applications with an easy-to-use messaging service. This service can be used to communicate with other applications or processes or to access storage.

Grace à des ULP (Upper Layers Protocol) il est possible de transporter différents protocoles tels que du SCSI, de l’IP, du NFS ou du Lustre et même de faire du RDMA pour certains comme dans le cas du SRP ou du GPUDirect. Au fil de nos recherches nous avons pu remarquer que malgré des débuts difficiles, l’architecture infiniband semble s’imposer petit à petit dans de nombreux domaines pour des raisons de flexibilité, de performances et de coûts.

Pour en revenir à notre homelab, nous avons soigneusement cherché un modèle de carte dual port capable de fonctionner sur ESXi 5 ainsi que Nexenta 3 et c’est sur le forum de nexenta que nous avons trouvé la bonne affaire : HP 448397-B21 (chip Mellanox ConnectX). A 50€ sur ebay nous en avons donc commandé 3 ainsi que les câbles CX4 pour les connecter (infiniband supporte le back-to-back à l’instar du FC et de l’ethernet).

Tout semblait “se dérouler sans accrocs” mais alors que nous relisions le User Manual des drivers Mellanox en attendant que les cartes nous soient livrées, un paragraphe allait radicalement changer la nature de notre aventure :

The driver package requires InfiniBand Subnet Manager (SM) to run on the subnet. The driver package does not include an SM.
If your fabric does not include a managed switch/gateway, an SM application should be installed on at least one non-ESXi Server machine in the subnet. You can download an InfiniBand SM such as OpenSM from www.openfabrics.org under the Downloads section.

En effet, contrairement à FC ou ethernet, les cartes infiniband (HCA) ne suffisent pas à constituer un réseau fonctionnel (et sans SM sur le subnet, les ports IPoIB sont down), il faut un Subnet Manager pour gérer la topologie du réseau infiniband et ce composant n’existe pas (publiquement) pour ESXi, pas jusqu’à maintenant en tout cas…

Un SM étant nécessaire pour chaque subnet, notre design en “triangle” (2 ESXi + 1 Nexenta) nécessitait forcement un SM coté ESXi pour gérer le subnet entre les 2 ESXi (pour le vmotion) et un SM pour chacun des liens ESXi/Nexenta (pour le SCSI et le NFS). Et dans un excès d’optimisme, nous voila parti à essayer de compiler OpenSM pour ESXi et en faire un vib

Nous avons commencé grâce au post de William Lam basé sur le post de Stjepan Groš et avons réussi à compiler une version fonctionnelle après avoir résolu des problèmes de dépendances (libibmad, libibumad et libwrap) et de chemins dans les sources (umad.h). Nous avons ensuite du faire face à un problème de cpu loop (osm_vendor_ibumad.c) que nous n’aurions pu résoudre sans l’aide précieuse de Hal Rosenstock, de chez Mellanox (très actif sur la mailing list d’openfabrics). Finalement, après avoir mijoté un script d’init, nous avions une version capable de démarrer un SM par subnet, supportant un fichier de partition (topologie du réseau) et capable de réassigner les LIDS (équivalent des adresses MAC ou des WWN) en cas de besoin. Yatta !

Nous n’avons eu qu’à utiliser l’excellent ESXi Community Packaging Tools d’Andreas Peetz (autrement plus abouti que VIB Author) pour packager un joli vib à déployer avec esxcli (VUM ne supportant pas l’indispensable –no-sig-check) et hotplug ! De plus, OpenSM est capable de supporter plusieurs instances sur le même subnet où une seule sera MASTER et les autres STANDBY.

Voici donc le seul et unique vib qui vous permettra de faire du back-to-back entre 2 ESXi ou entre ESXi et n’importe quoi d’autre :

ib-opensm x86

ib-opensm x64

Un petit tour par l’onglet configuration d’ESXi :

Et enfin, quelques infos utiles :

• Les logs d’openSM sons placés dans /var/log/opensm/{LID}/opensm.log
• Les fichiers partitions.conf (qui définie la topologie du réseau) sont à placer dans /scratch/opensm/{LID}/
• Pour fixer le MTU à 4092, suivez le User Manual de Mellanox et utilisez ce partitions.conf
• Pour activer ibsrp/target sur Nexenta 3, suivez le Basic COMSTAR Quick-Start Guide for SRP

Passons aux gros chiffres. On commence par une vague de vmotion :

On continue avec un test d’IOPS avec VMware I/O Analyzer (appliance iometer) :

Et on termine par un test de throughput, toujours avec I/O Analyzer :

Il ne vous reste plus qu’à sécher vos larmes et aller vous faire plaisir sur eBay

Ces tests ont été réalisés sur 1 seul port 10Gbps DDR (soit 20Gbps) alors imaginez les résultats avec des cartes 56Gbps…

PS : Un grand merci à vmdude pour son aide et à tous les autres pour nous avoir supporté pendant notre période “infiniband cay le bien”

Tags: 10GbE, FC, HCA, infiniband, iometer, vib