No snapshot = No backup

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

Infiniband@home : votre homelab à 20Gbps

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

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

Et enfin, quelques infos utiles :

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

vExpert 2013

La liste des vExpert 2013 vient d’être publiée et pour la 4ème année nous avons l’honneur d’en faire partie. Cette année nous sommes 580+ soit presque 200 de plus qu’en 2012, une liste trop longue au goût de certains… Merci à tous (une fois de plus) pour votre soutien et votre confiance !

Tags:

Storage DRS jet lag

Suite à la publication de l’excellent Understanding VMware vSphere 5.1 Storage DRS rédigé (et surtout illustré) par Frank Denneman, nous nous permettons une petite remarque au sujet de la réactivité de SDRS lors du dépassement du seuil de remplissage. Dans le white paper, on peut lire ceci :

vSphere Storage DRS attempts to avoid an out-of-space situation and therefore runs a load-balancing operation as soon as the datastore exceeds its space-utilization threshold. This operation can be outside of the normal load-balancing interval of every 8 hours.

La première phrase est aussi intéressante qu’imprécise. On y apprend que la réaction est immédiate mais aussi qu’elle dépend de vCenter. Et suite à une batterie de tests sur différents environnement (5.0 et 5.1), nous avons remarqué que la fréquence de rafraîchissement de cette information dans vCenter n’est malheureusement que d’une (1) fois toutes les 30 minutes au mieux. (on soupçonne un algorithme basé sur l’utilisation du datastore mais visiblement pas encore très efficace). Pour le vérifier, rien de tel qu’un petit oneliner de PowerCLI qui check la propriété info.timestamp des datastores :

Get-View -ViewType datastore -property info,name,summary|?{$_.summary.accessible}|select name,{$_.info.timestamp.ToLocalTime()}

On constate donc qu’un des pilier de SDRS repose sur une donnée dont la fiabilité peut malheureusement varier et dont la fraîcheur peut laisser à désirer même dans le cas des 30 minutes. En attendant que ça bouge coté VMware, voici un workaround (nettement moins dingue que celui d’une certaine kb), qui consiste à forcer le refresh rapide à votre convenance sans que la tache n’apparaisse dans le vCenter (merci le SDK). Dans notre exemple, refresh de tous les datastores dont la propriété info.timestamp serait “veille” de plus de 5 minutes :

Get-View -ViewType datastore -property info,summary|?{$_.summary.accessible}|?{($(get-date) - $_.info.timestamp.ToLocalTime()).TotalMinutes -gt 5}|%{$_.RefreshDatastore()}

La seconde phrase de la citation, c’est un RTFM politiquement correct pour ceux qui font encore l’amalgame entre les 8h d’intervales de l’I/O load balancing et le Space-Utilization Load Balancing.

Tags: , , ,

PxCounterLevelMapping : Pimp my stats

Il y a quelques années, un petit outil pas très connu nommé “VC StatLevelConfig“ faisait son apparition dans la liste des Flings de VMware. Cet outil permettait à l’époque de changer unitairement le niveau par défaut de collecte des compteurs de performance du vCenter. Par exemple, si vous vouliez garder les stats d’active memory sur 24h pour vos ESX, cet outil vous permettait de le faire de façon unitaire plutôt que d’augmenter le niveau de collecte global du vCenter. Tout ce mécanisme de collecte est très bien détaillé dans le post de Luc Dekens :

Malheureusement la page de ce fling n’existe plus (même si l’outil est toujours disponible) mais nous avons trouvé son équivalent en PowerCLI au détour de 2 kb traitant de SIOC (ici et ). Il s’agit d’un module powershell qu’il suffit de charger avec la commande “Import-Module” et vous aurez ensuite accès à 2 nouvelles cmdlet (Get-PxCounterLevelMapping et Set-PxCounterLevelMapping) pour opérer les changements désirés.

A titre d’exemple, voici le niveau par défaut du compteur mem.active.average dont nous parlions plus haut :

Après exécution de la commande magique, le résultat (avant/après sur les graphiques) :

Get-PxCounterLevelMapping|?{$_.Name -eq "mem.active.average"}|Set-PxCounterLevelMapping -AggregateLevel 1

Ces modifications auront des conséquences sur la taille et peut être les performances de la base de données de votre vCenter mais ce sera toujours mieux qu’une augmentation “globale” qui entraînera la collecte de compteurs dont vous n’aurez peut être jamais besoin…

Tags: ,