vSphere 5 introduces a new enhancement that ensures vMotion will not fail due to memory copy convergence issues. As noted in the “Architecture” section, transfer of the virtual machine’s memory contents during the vMotion process involves an iterative precopy procedure. In most cases, a precopy iteration should take less time to complete than the previous iteration. However, a pathological case where the virtual machine modifies memory faster than it can be transferred—due to workload characteristics or network infrastructure limitations—results in aborting vMotion in vSphere 4.1 and prior releases, because precopy fails to make forward progress. The enhancement in vSphere 5 slows down the virtual machine during such pathological cases and ensures that the memory modification rate is slower than the precopy transfer rate, thereby preventing any possible vMotion failures.

Vous l’aurez compris, si l’ESX source n’arrive pas à “dépiler” la vram suffisamment vite lors d’un vMotion, l’execution de la VM en question est ralentie jusqu’à ce qu’une convergence soit possible, dans la limite des timeout par défaut.

Cette fonctionnalité semble parfaite pour les monster VM qu’on a du mal à évacuer lors d’un passage en maintenance mode mais elle est aussi très “problématique” lorsque l’infrastructure réseau n’est pas ou plus adaptée. D’où le très discret “network infrastructure limitations” dans le descriptif.

En l’occurence, le client en question mène une campagne de “refresh” de son parc afin de remplacer des machines ayant largement dépassé leur date de péremption technique. Mais sans faire évoluer son réseau. Il se retrouve donc avec machine de 2To de RAM sur un réseau 1GbE.

Evidement, à mesure que des VM de plus en plus grosses sont provisionnées sur ces environnements, les fenêtres de maintenance sont de plus en plus grande mais surtout des ralentissements apparaissent lors des mise en maintenance ou simplement quand DRS déplace de VM :

018-12-13T16:32:29.378Z cpu18:74031)VMotion: 4943: 7811810961774337297 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 693298, prev 461605, cur 497489, network bandwidth ~28.619 MB/s, 94% t2d)
2018-12-13T16:38:32.426Z cpu188:72874)VMotion: 4943: 7811810962073701659 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 126959, prev 18467, cur 15909, network bandwidth ~60.158 MB/s, 103% t2d)

SDPS fait son boulot et il le fait bien alors évidement pour faire passer des VM de 256Go qui bossent fort dans du 1GbE ca pique… Donc la prochaine fois qu’on vous dit que la bande passante de vmotion peut être sacrifiée, vous saurez quoi répondre.

Evidement, il y a un (mauvais) plan B :

To work around this issue, the Stun During Page Send (SDPS) feature can be disabled on a per-host basis.
[...]
Change the value of Migrate.SdpsEnabled to 0.

Nous en profitons pour souligner un autre “petit” détail du texte au sujet du Page Tracing :

During the pre-copy phase, the vCPU’s, in use by the virtual machine, are briefly stunned to install the page tracers.

Très loin des dashboard cacti fastidieux à réaliser et limités en scalabilité, nous avons voulu une appliance la simple possible : deploy, add vcenter, relax!

Pour ce test nous nous sommes procuré des SSD Intel 530 afin de vérifier que le design du PCB ne représente pas un frein aux performances et la faible latence des puces NAND. Nous nous sommes également amusé à démonter le backplane pour étudier la construction générale du produit.

Contrairement à ce que nous avions imaginé, vous pouvez constater sur les photos qu’il reste encore un peu de place entre les SSD ce qui peut laisser envisager une version 10 slots (SSD only par contre) ! Compte tenu de l’usage cible nous avons retiré les 2 ventilateurs 40 mm ce qui facilite le câblage et nous précisons au passage qu’une seule prise d’alimentation peut suffire même si nous craignons que ce ne soit pas idéal pour le PCB. Comme pour les autres produit de la gamme, la finition est très bonne et le coté “full metal” offre clairement une impression semblable aux produits des gammes professionnels chez les grands constructeurs.

Pour le benchmark, nous avons installé le rack dans un HP ML 110 G6 équipé d’un Xeon  x3430 et d’une carte LSI 9240-8i. C’est sur FreeNAS 9.3 que nous avons lancé iozone afin d’obtenir un résultat un peu plus réaliste qu’avec un simple dd :

180 µs de latence à 2.5 Go/s c’est quand même pas mal du tout

Durant le test de “reread”, nous avons pris une capture d’iostat pour avoir une idée de l’état des SSD et on remarque qu’ils ne sont même pas au maximum de leur capacité à en croire le %b :

Et pour le fun, on s’est dit que ce serait la classe dans mettre ça dans un N40L même si le processeur est loin de pouvoir suivre :

]]> http://www.hypervisor.fr/?feed=rss2&p=5492 2 http://www.hypervisor.fr/?p=5456 http://www.hypervisor.fr/?p=5456#comments Thu, 02 Apr 2015 14:32:22 +0000 NiTRo http://www.hypervisor.fr/?p=5456 Nous avons eu l’opportunité de déployer notre fameuse sauce “Large Page on Demand“ sur un environnement VDI de 5 stretched cluster de 32 nodes (soit 160 lames HP BL460c Gen8 bi E5 2680 v2 – 256Go) pour un total de 5000 VM Windows 7. Voici le summary d’un des cluster :

Sans autre tuning que le paramètre LPageAlwaysTryForNPT, TPS nous a permis de récupérer plus de 50% de RAM soit + de 12.5To sans impact sur le ressenti utilisateur (cliquez sur les graphs pour avoir le détail des compteurs) :

Merci qui ?

These issues are due to bug in large page promotion path on destination host during vMotion.

MAJ 22/10/2015 : Et encore des mecs qui confondent cloud et homelab…

All experiments run on a dual CPU blade server with two AMD Opteron 6272 CPUs (16 cores each) and 32 GB of RAM.

MAJ 26/02/2015 : Le patch pour la 5.0 vient de sortir, la boucle est bouclée.

Vous ne vous en êtes peut être pas rendu compte lors de votre dernière campagne de patching mais depuis mi-Octobre 2014, tout nouveau patch d’ESXi ajoute une fonctionnalité de salage pour TPS. Désactivée lors de son introduction mais bien destinée à être activée de force lors d’un patch ultérieur. Jusqu’à fin Janvier, seule la version 5.1 était concernée mais depuis le 27/01 la version 5.5 bénéficie aussi de cette nouvelle “feature”. La 5.0 est encore épargnée à ce jour.

As we noted earlier on Oct 16, Nov 24 and Dec 4, VMware has introduced new TPS (Transparent Page Sharing) management options. Today’s release of ESXi 5.5 U2d restricts TPS to individual VMs and disables inter-VM TPS by default unless an administrator chooses to re-enable it. Please see KB 2097593 for full details on the functionality.

Depuis l’annonce, beaucoup de bullshit. De nombreux blogeurs ont donné leur avis sur la question en omettant volontairement (aka je-suis-pas-un-expert-en-sécu) d’analyser les recherches qui ont abouti a cette rustine. Nous ne sommes pas expert en matière de sécurité non plus, par contre on ne va pas se gêner pour décortiquer les résultats de ces recherches et les critiquer. On commence par la kb 2080735 de VMware :

Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try and determine an AES encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing is enabled between the two virtual machines. This technique works only in a highly controlled system configured in a non-standard way that VMware believes would not be recreated in a production environment.

Even though VMware believes information being disclosed in real world conditions is unrealistic, out of an abundance of caution upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default

C’est pourtant clair mais VMware à quand même choisi de jouer la carte de la sécurité.

Une petit coup de Google nous a rapidement permis d’identifier les rapports de recherche à l’origine du mélodrame : Fine grain Cross-VM Attacks on Xen and VMware are possible! et Wait a minute! A fast, Cross-VM attack on AES dont les travaux semble basés sur un autre rapport datant de 2013 : FLUSH+RELOAD: a High Resolution, Low Noise, L3 Cache Side-Channel Attack

Extraits choisis du document de 2013 :

The technique uses the processor’s clflush instruction to evict the monitored memory locations from the cache, and then tests whether the data in these locations is back in the cache after allowing the victim program to execute a small number of instructions.

While copy-on-write protects shared pages from modifications, it is not fully transparent. The delay introduced when modifying a shared page can be detected by processes, leading to a potential information leak attack.

An important feature of the LLC in modern Intel processors is that it is an inclusive cache (NDLR : Et donc pas AMD). That is, the LLC contains copies of all of the data stored in the lower cache levels. Consequently, flushing or evicting data from the LLC also remove said data from all other cache levels of the processor. Our attack exploits this cache behaviour.

Retrieving data from memory or from cache levels closer to memory takes longer than retrieving it from cache levels closer to the core. This difference in timing has been exploited for side-channel attacks.

A round of attack consists of three phases. During the first phase, the monitored memory line is flushed from the cache hierarchy.

The spy, then, waits to allow the victim time to access the memory line before the third phase.

In the third phase, the spy reloads the memory line, measuring the time to load it. If during the wait phase the victim accesses the memory line, the line will be available in the cache and the reload operation will take a short time.

Maintenant qu’on en sait un peut plus sur la nature de l’attaque, voyons un peu les contraintes d’applications dans la vraie vie :

For a virtualised environment, the attacker needs access to a guest co-located on the same host as the victim guest. Techniques for achieving co-location are described by Ristenpart et al.
[...]
Identifying the OS and software version in co-resident guests has been dealt with in past research.

D’un coup de baguette magique, on se retrouve sur le même ESX avec le même GuestOS. Facile. On continue :

For the attack to work, the spy and the victim must execute on the same physical processor. For our testing, we set the processor affinity on the multi-processor system. However, in a real attack scenario the attack depends on the system scheduler.

Vous avez bien lu, la VM de l’attaquant doit résider sur le même processeur que la VM de la victime. Cache L3 oblige. Et c’est pas fini :

When performing the tests, the spy and the victim were the only load on the system. Such a scenario is not representative of a real system where multiple processes are running. We expect such load to create noise that will affect the quality of capture. Furthermore, for a load that includes multiple parallel instances of GnuPG, the spy will be unable to distinguish between memory access of each instance and will be unable to recover any data.

Donc, pour que l’attaque soit réalisable, il faut que la VM de l’attaquant se retrouve, avec la VM de la victime, seules sur le même socket du même ESX et avec le même GuestOS ! Et c’est toujours pas fini.

Extraits choisis du document sur l’attaque AES :

We know that VMware implements TPS with large pages (2 MB) or small pages (4 KB). We decided to use the later one, since it seems to be the default for most systems. Furthermore, as stated in [28], even if the large page sharing is selected, the VMM will still look for identical small pages to share.

Sachant que TPS ne supporte pas les large pages qui sont la configuration par défaut d’ESX depuis des années, non seulement ESX ne serait que partiellement vulnérable uniquement en cas d’overcommit important mais de plus le contexte initiale de l’étude est complètement faux.

Disabling the deduplication would make the attack impossible in the cloud however memory deduplication is highly performance beneficial, especially in cloud where multiple users share the same hardware. This is why we believe that the system designers should restrict the deduplication mechanism rather then completely disabling it.

Quel dilemme…

We not only performed the attack in native machine, but also in a cloud-like cross-VM scenario.

“cloud-like” et pourtant :

All experiments were performed on a machine featuring an Intel i5-3320M four core clocked at 3.2GHz.

Ironie du sort, un récent rapport de recherche décrit un nouveau type d’attaque sur le cache L3 en exploitant…les large pages !

S$A: A new deduplication free L3 cache side channel technique: We proposed a new side channel technique that is applied in the L3 cache and therefore can be applied in cross-core scenarios. The new side channel technique bases its methodology in the usage of huge size pages, which give extra information about the position that each memory location occupies in the L3 cache.

Prochaine étape : désactivation des large pages par défaut ou V2P en masse.

The relevance of these studies is highlighted by the prompt security update by VMware, making memory deduplication an opt-in feature that was formerly enabled by default.
[...]
We have disclosed our attack to the security teams of VMware, Amazon AWS and Citrix.

Mais revenons en au salting et à ses effets en cas d’overcommit. Sur un Dell R730 avec 256Go de RAM, nous nous sommes amusé à démarrer 512 VM SUSE 11 x64 1vcpu 2Go de vRAM avec des combinaisons de settings Mem.ShareForceSalting et Mem.AllocGuestLargePage différentes. Pour éviter que ça coince pendant le swapout, nous avons redirigé les vswp sur des SSD NVMe. On commence en mode défaut (Mem.ShareForceSalting=2 et Mem.AllocGuestLargePage=1) :

La courbe d’overhead (orange) permet de se rendre compte de la progression du démarrage des 512 VM. On remarque qu’au 3/4 du bootstorm le premier mécanisme de reclaim est la swap, viennent ensuite la compression, le ballooning et seulement après le sharing (principalement des zéros). Avec 23Go de swap et 43Go de zip, n’espérez pas des temps de réponses de folie même avec du SSD. On continue sans le salting (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=1) :

Avec plus de 100Go de sharing et seulement 3,6Go de swap les effets de l’overcommit (3:1 quand même) sont presque imperceptibles dans ce scénario même si on regrette de constater que le swapping est encore le 1er mécanisme à se déclencher. Maintenant passons en full small pages (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=0) :

Là on est au top, 200Go de sharing et un démarrage tout en douceur sans swap, compression ni balloon. Et pour finir, notre fameuse technique du Large Page on Demand (Mem.ShareForceSalting=0 Mem.AllocGuestLargePage=1 et LPage.LPageAlwaysTryForNPT=0) :

Même chose mais avec “seulement” 143Go de sharing, la différence étant vraisemblablement attribuée à des large pages.

Moralité, optez pour un régime sans sel !

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

Afin d’avoir une meilleure visibilité sur ce qui change au moment où nous avons activé le paramètre et lancé une vague de vmotion au sein du cluster pour l’appliquer, nous avons utilisé les mêmes compteurs que le “dashboard” Guest Memory (aka ResourcePoolQuickStats) pour en faire un rrd sous cacti (avec les même couleurs) :

Un gain immédiat de 20% de RAM sans consommation CPU supplémentaire ni augmentation manifeste de latence (dans notre cas) :

Et pour ceux qui se posent la question, dans ce cluster cumulant 1.5To de RAM attribuée à des VM Windows 2008 R2 et RHEL 6 x64, seulement 40Go de Large Pages sont allouées en moyenne.

Moralité, TPS c’est bon, mangez-en !

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

Follow the Migrate Virtual Machine Wizard to select the ESX 3.0.1 host and VMFS3 datastore destination. The Wizard validates the destination and moves the configuration files of the virtual machine and virtual disks to the new VMFS3 datastore.

Depuis, nous avons étudié, testé, troubleshooté, et utilisé en production (de manière parfois intensive) cette fonctionnalité (qui a beaucoup évolué depuis 2007) devenue presque banale depuis SDRS.

C’est au moment où nous croyons tout savoir du mécanisme que nous prenons une grande claque d’humilité lors d’une migration de plusieurs centaines de VM et que nous nous apercevons pour la première fois qu’un svmotion d’un vmdk thin (ou Lazy Zeroed) génère 2 fois plus d’écritures que de lectures :

Nous n’avions jamais fait le rapprochement entre un svmotion et un sujet qui a longtemps fait polémique :

Because zeroing takes place at run-time for a thin disk, there can be some performance impact for write-intensive applications while writing data for the first time.

Et le pire c’est qu’il nous a fallu un temps infini à l’échelle de Google pour tomber sur un thread reddit où un VCDX explique tout d’une seule phrase :

It has to zero the block before writing the actual data.

Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).

A titre de démonstration, voici un visualEsxtop de 2 svmotion consécutifs de la même VM entre 2 datastore, avec et sans le setting DataMover.HardwareAcceleratedInit :

Ce n’est pas une défaillance de votre téléviseur, avec le zeroing offloadé à la baie c’est presque 2 fois plus rapide (ou 2 fois moins long si vous préférez…).

Ce comportement n’a évidement aucun rapport avec la “non-récupération” des zéros lors d’un svmotion… Bien qu’il semble etre possible de le forcer d’une manière non supportée !

Aussi farfelu que cela puisse paraître, une nouvelle partie de notre homelab est *temporairement* connecté sur du CPL. Et du coup, “les débits doivent être pourris ?!” me demanderez vous. Et bien figurez vous que nous nous sommes posé la même question au moment de connecter un ESX sur cette portion de notre réseau domestique !

Pour tester un segment de réseau rien de tel qu’iperf évidement mais nous ne voulions pas faire le test entre 2 VM, entre 2 ESX c’est beaucoup plus intéressant… Nous avons donc déterré un vieux post du forum vm-help où danisoto détail que le binaire iperf i386 pour rhel5 fonctionne nativement sur ESXi. C’était à l’époque d’ESXi 4 mais le binaire fonctionne toujours aussi bien sur ESXi 5.5 :

Après quelques tests où nous avons du désactiver (temporairement) le firewall d’ESXi faute de règle associée, nous avons pensé qu’il serait bien pratique d’avoir une jolie vib avec une version uptodate d’iperf, une règle de firewall custom et une “SecPolicy”…

Un petit coup d’ESXi5-CPT plus tard, et nous voila avec une vib contenant la version 2.0.5-1 i386 d’iperf (pour laquelle nous avons honteusement pompé le binaire d’un rpm plutôt que de le compiler nous même #shame) et la règle de firewall qui ouvre le port 5001 en TCP/UDP :

Pour information, nous n’avons pas pu compiler de version 2.0.5-11 ni de version 3.x fonctionnelle mais la v2 semble la plus répandue à ce jour et la version 2.0.5-1 ne semble pas souffrir de bug majeur.

Ce petit exercice nous a permis de découvrir le “VMkernel Access Control System” (SecPolicy) qu’Andreas décrit dans l’un de ses posts dédiés à la création d’une vib. Sans son aide on y serait encore… Vielen Dank! Au passage, pour faire passer la secpolicy, il faut impérativement le level “VMwareAccepted” ce qui rend le –no-sig-check obligatoire malheureusement.

Pour ceux qui ont la chance de pouvoir accéder au net depuis leur ESXi, la vib est disponible sur le vibsdepot d’Andreas, sinon c’est ici :

iperf-2.0.5-1

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

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.

Premier constat, le temps de compute des valeurs moyennes de cpu et ram est très important et c’est évidement proportionnel au nombre de nœuds. Pour optimiser ce script, nous nous somme rabattu sur les quickstats du resource pool “racine” du cluster (aka “resources”). Ces valeurs étant basé sur les 5 dernières minutes d’activité (et non sur les 24 dernières heures comme le script original), il faut l’exécuter au moment de la journée où l’activité du cluster est la plus importante pour avoir des valeurs vraiment représentatives du workload. Le gros avantage de ces valeurs est qu’il n’est pas nécessaire de faire une requête dans les statistiques, elles sont pré-computées et disponibles sous forme de propriétés, on passe donc d’une exécution pouvant aller jusqu’à plusieurs minutes à 2 secondes par cluster. Comme dirait Mozinor, “tu peux pas test”.

Deuxième constat, le mode “slot size” d’admition control ne tiens pas compte de l’overcommit. Duncan et Frank l’explique en détail dans leur bouquin mais voici un exemple encore plus parlant :

3 hosts sur 12 (25%) en mode “slot size” contre 67% en mode “resources”. Dans ce dernier mode, HA tiens compte de la consommation réelle du cluster pour déterminer ce qu’il reste.

With the resources failover policy in place, vSphere HA uses the following calculations to control virtual machine migration in the cluster
1. Calculate the total resource requirements for all powered-on virtual machines in the cluster.
[...]

Il est donc clair que sur des gros cluster avec de l’overcommit, le mode “slot size” est totalement inutilisable.

En attendant de déguster la dinde farcie aux marrons de tante Yolande, voici le oneliner powershell à deguster en amuse-bouche :

foreach ($cluster in (Get-View -ViewType ClusterComputeResource|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster|?{$_.host}|select @{n="mem";e={(($_|%{(Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.HostMemoryUsage/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="cpu";e={(($_|%{((Get-View $cluster.ResourcePool|?{$_.Parent -eq $cluster.Moref}).Summary.QuickStats.OverallCpuUsage)/(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState|?{$_.Runtime.PowerState -eq "poweredOn"}).count}))}}, @{n="vcpu";e={(Get-View -ViewType virtualmachine -SearchRoot $cluster.moref -Property Runtime.PowerState,Config.Hardware.NumCpu|?{$_.Runtime.PowerState -eq "poweredOn"}|Select @{n="vcpu";e={$_.Config.Hardware.NumCPU}}|Measure-Object -Average -Property vcpu).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum -and ($_|measure -Sum).sum -gt "64") {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

Joyeux Noël à tous !

In order to support virtual machines with strict latency requirements, vSphere 5.5 introduces a new per-VM feature called Latency Sensitivity.

Cela nous a fait curieusement penser à une autre feature disponible dans la version 5.1 : VM Latency Sensitivity.

vSphere 5.1 simplifies the process of configuring a virtual machine to support low-latency applications. It now offers a latency sensitivity advanced setting that automatically makes low-level changes in the vSphere kernel to reduce latency for the virtual machine.

Ah tiens c’est bizarre, elles ont le même nom…

Vous constaterez qu’il n’en est nullement fait référence dans le whitepaper de la 5.5 donc impossible de savoir si c’est “vraiment” une nouvelle fonctionnalité, la même fonctionnalité améliorée ou un gros pipeau.

En attendant d’en savoir plus, on vous a préparé un petit oneliner pour activer la fonctionnalité et même fixer le nombre de µs secondes que vous souhaiter (2000 dans notre exemple) :

Get-VM "Flash_Gordon"|Get-View|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{latencySensitivity=(New-Object VMware.Vim.LatencySensitivity -Property @{level="custom";sensitivity="2000"})}))}

Et pour savoir ce qui a été configurer :

(Get-VM "Flash_Gordon"|Get-View).Config.LatencySensitivity

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…

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.

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

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”

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 là). 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…

Using swap to host cache and putting the regular swap file in SSD (as described below) are two different approaches for improving host swapping performance. Swap to host cache makes the best use of potentially limited SSD space while also being optimized for the large block sizes at which some SSDs work best.

Facile avec ZFS, un petit coup de DTrace et on peut rapidement voir la caractéristique des IO sur un datastore utilisé en tant qu’Host Cache (il nous aura fallu tout de même faire le coup du SSD). Pour cela nous avons utilisé le boot d’une VM Windows 2008 R2 limité à 256Mo de RAM pour que le reste déborde sur la swap.

D’abord, la taille des IO (en écriture) sur la swap classique :

C’est étonnamment distribué mais c’est largement du 4K. Voyons les IO (toujours en écriture) sur du Host Cache :

Pas de doutes, les IO font uniquement 128K (ceux de 512 bytes n’ont pas de rapport avec la swap) ce qui prouve l’intérêt d’activer la fonctionnalité plutôt que de simplement rediriger les vswp.

Pour ceux qui se poserait la question, la taille des IO en lecture est la même dans les 2 cas : 4K