#vExpert2014

Comme chaque année depuis 2010 c’est un honneur de voir apparaître son nom dans la liste des vExpert (750+ cette année). Merci encore pour votre soutien, vos réactions, vos commentaires et bravo à tous les nominés.

Tags:

Hyper-Vulnérable

Lorsque nous critiquons Hyper-V c’est évidement dans l’optique de voir mûrir le produit. Malgré tout, on ne peut pas s’empêcher de penser qu’il reste encore un peu de chemin…

Tags:

Oh my DRS Goodness!

Ceux d’entre nous qui faisons de l’administration d’infrastructure vSphere au quotidien ont au moins une fois entendu la fameuse phrase “Mais pourquoi DRS ne fait rien alors que le cluster n’est pas équilibré ?!“. Le sujet à déjà largement été traité par des références dans le domaine comme l’est Frank Denneman mais nous allons reformuler la raison une bonne fois pour toute et en français : DRS ne déclenchera un vmotion que si le gain du déplacement est supérieur à son coût.

Evidemment il y a un algorithme complexe, du paramétrage et des seuils variables pour rendre le mécanisme suffisamment intelligent mais dans le cas d’un cluster pas ou peu overcommité (cpu et/ou ram uniquement), le déséquilibre est une situation “normale” puisque le coût d’un vmotion sera presque toujours supérieur a son bénéfice. DRS estime le gain à partir de la demande des vm et n’a de raison d’agir que si elles ne peuvent pas obtenir les ressources demandées. Le bon nivellement des VM dans le cluster n’est absolument pas pris en compte. De plus, DRS fait une projection de ce que la vm pourrait consommer dans un futur proche en fonction des statistiques passées afin de ne pas réagir trop tard.

Néanmoins, dans certains cas il peut s’avérer nécessaire de forcer DRS à “secouer” un peu le cluster pour répartir les vm. Après une opération de maintenance ou de façon proactive (moins de vm par host=moins de conséquences en cas de crash) ou encore pour niveler les I/O disque/réseau pas (encore) pris en compte par DRS.

Nous nous sommes justement retrouvés dans cette situation suite à l’ajout de plusieurs host dans un cluster 5.0 U1 et face à l’immobilisme de DRS, nous nous sommes souvenus d’un post détaillé de Frank à ce sujet faisant référence à une kb vmware.

This issue may occur in an environment with a large number of relatively low demand virtual machines

Il s’agit de modifier *temporairement* les paramètres MinGoodness et CostBenefit pour que DRS déclenche un vmotion à la moindre occasion sans en considérer le coût. le résultat est immédiat :

Depuis vSphere 5.1, l’algorithme de DRS à été modifié pour palier à des situations similaires (vSphere 4.1 U3 et vSphere 5.0 U2 intègre aussi la modification) mais il est toujours possible de forcer si besoin avec d’autres paramètres :

Starting with this release, DRS algorithm is improved to better balance the load in a DRS cluster. If you notice that the cluster is still not balanced with the default settings, you can configure the advanced DRS options with the following values and run DRS to further improve the load balancing capability of the DRS cluster:

SevereImbalanceDropCostBenefit 1
FixSevereImbalanceOnly 0

Tags: , ,

Pimp My (SATA) Ports

Alors que nous pensions avoir fait le tour des possibilités du HP N40L N54L ProLiant MicroServer, nous somme tombé par hasard sur un post revisitant le fameux mod de BIOS, permettant d’avoir accès à tout un tas de hidden settings, afin de pouvoir utiliser un port multiplier sur le eSATA.

A Serial ATA port multiplier is a device that allows multiple SATA devices to be connected to a single SATA host port.

Un peu comme un SAS expander mais en un peu moins enterprise class… Au passage, c’est ce qu’utilise Backblaze pour faire tenir 180 To dans un server 4U.

L’idée de pouvoir se passer de la carte contrôleur qui monopolise le seul port pcie (potable) de notre N40L nous séduit. 40€-et-quelques-sur-ebay plus tard (carte et cables courts compris), FreeNAS reconnait parfaitement le bidule grâce aux modifications de BIOS :

pmp0 at ahcich5 bus 0 scbus7 target 15 lun 0
pmp0: ATA-0 device
pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes)
pmp0: 5 fan-out ports

La carte que nous avons trouvé étant limité à 5 ports, nous avons été contraint d’utiliser un rack 4x 2.5″ mais le pcb se loge parfaitement entre ce dernier et la partie supérieure du boitier :

Vous l’aurez compris, c’est le port ODD interne que nous avons choisi d’utiliser pour rester dans l’esprit NAS compact.

Pour avoir une idée de l’impact qu’une telle solution pouvait avoir sur les performances, nous l’avons comparée à une carte LSI 1068E. Après une séance d’iozone sur un zpool de 4 SSD en striping, nous avons fait chauffer le gnuplot :

Si l’impact sur la latence est acceptable, celui sur les débits d’écriture est très important puisque l’on passe de ~800Mo/s à ~200Mo/s mais il fallait s’y attendre. On constate par contre que tant que les IO restent dans la fenêtre des TXG de ZFS, les débits sont identiques.

Au final, même si les performances sont moins bonnes qu’avec une carte contrôleur, elles sont malgré tout bien meilleures que ce qui pourra passer par un port GbE. De plus, FreeNAS ne supportant pas *encore* FC ou infiniband, une carte dual ou quad GbE  reste un bon début.

Tags: , , , , , ,

ESXCLI is the new VUM

Lors d’une tentative d’upgrade d’ESXi 5.1 vers 5.5 avec VUM, nous nous sommes heurté à un message d’erreur des plus vagues :

The upgrade contains conflicting VIBs. Remove the conflicting VIBs or use Image Builder to create a custom upgrade ISO image that contains the newer versions of the conflicting VIBs, and try to upgrade again.

Il nous a fallu fouiller au fin fond des logs d’ESXi pour identifier les VIB en question :

Si vous lisez attentivement les release notes, vous savez déjà que depuis ESXi 5.1 il est possible d’upgrader avec la commande esxcli directement depuis le vib depot de VMware (William Lam a d’ailleurs écrit un post à ce sujet pour détailler le process) :

You can upgrade and apply patches to ESXi 5.0.x hosts by using the esxcli command-line utility for ESXi to upgrade to ESXi 5.1 from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner.

Nous avons donc tenté la même opération en ssh et l’erreur retournée par ESXCLI est nettement plus précise que celle de VUM :

Au passage, on attend toujours un plugin VUM digne de ce nom pour le webclient…

Tags: , , ,