Compte tenu de son implementation de l’époque (très bien décrite, en Francais, par nos amis d’x86-secret), il était souvent recommandé de désactiver l’HT. Au fil des évolutions des CPU mais aussi des versions d’ESX, la situation a fini par s’inverser et le grand débat de l’HT pouvait prendre fin…

Internal testing shows that the recent generation of HT processors displays a higher performance gain from utilizing both logical processors. This means that the potential performance loss by letting some hyper-threads idle for a fairness reason becomes non trivial.

[...]

On vSphere 5.x, such a benefit is recognized and more CPU time is charged when both logical processors are busy. The implication of this newer charging model on HT is that a vCPU which is lagging behind can catch up more quickly even on a partial core, making it less necessary to use only the whole core.

…Ou pas, car comme l’a décrit x86-secret il y a 16 ans (!) :

Avec l’HT, ce sont désormais deux flux d’instructions qui arrivent à l’entrée du pipeline. A noter que seule la partie en amont du pipeline est, d’une certaine façon, “consciente” de la présence de ces deux flux provenant de deux threads différents, et le reste du traitement s’effectue comme s’il s’agissait d’un unique flux d’instruction. Ainsi, les deux threads se partagent les unités de calcul et les mémoires caches.

Et guess what, une équipe d’un centre de recherche hollandais dit avoir été capable d’exploiter cette faiblesse connue depuis de années (mais c’était avant AWS & Co) maintenant baptisée TLBleed. En pleine “crise” Spectre/Meltdown, Intel semble ne pas avoir l’intention d’adresser cette faille mais les choses pourraient bien changer au moment de la publication d’ici le mois d’Août. Et oui, AMD est potentiellement impacté aussi

Et surprise, l’équipe des devs du projet OpenBSD (“As of February 2018, only two remote vulnerabilities have ever been found in the default install, in a period of almost 22 years“) a décidé de désactiver l’HT dans les nouvelles releases. Et c’est d’ailleurs pour ca que toute l’histoire est remonté à la surface.

On notera au passage que l’ANSSI recommandait déjà de désactiver l’HT depuis 2015 au moins, pour les mêmes raisons.

C’est donc le moment de sortir les popcorn’s. Quand on se souvient de l’affaire du salage de TPS pour des histoires de differences de latences de cache en environnement contrôlé, on se régale de la com VMware qui justifiera la désactivation d’HT dans ESX.

Nous profitons du recent article de The Information qui décrit la volonté d’Apple de construire ses propres serveurs en raison d’une crise de paranoïa, pour partager avec vous une video découverte récemment traitant de Virtual Machine Introspection, une fonctionnalité de l’API Memory Inspection de l’Hyperviseur Xen (utilisé par Amazon pour AWS par exemple…).

Cette vidéo est présentée par Tamas K Lengyel, chercheur en sécurité et développeur actif sur les projets Xen Project Hypervisor, LibVMI et DRAKVUF (Dynamic Malware Analysis system). La description faites sur la home du site de ce dernier est particulièrement flipante :

DRAKVUF is an agentless dynamic malware analysis system built on Xen, LibVMI, Volatility and Rekall. It allows for in-depth execution tracing of malware samples and extracting deleted files from memory, all without having to install any special software within the virtual machine used for analysis.

Un peu avant la 3eme minute de la présentation, vous aller voir Tamas lancer la calculatrice de Windows 7 dans une VM, depuis l’hyperviseur, en “hijackant” la mémoire du GuestOS à l’aide de l’API VMI de Xen. Si si.

Ce projet est loin d’être recent puisqu’il date de 2011 et a bien été amélioré depuis :

In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added.

On vous laisse méditer sur les fonctions clefs du projets pendant que votre DSI se félicite d’avoir migré tout son système d’information sur Azure…

• Agentless start of malware execution.
• Agentless monitoring of Windows internal kernel functions.
• Guest multi-vCPU support.
• Tracing heap allocations.
• Tracing files being accessed.
• Extracting files from memory before they are deleted.
• Cloning of analysis VMs via copy-on-write memory and disk.

Dell EMC has retired ftp.dell.com and transitioned exclusively to a global downloads site with regional hosted repositories .Feb 21, 2021

MAJ 27/07/2016 : Il semblerait que la valeur “/catalog” pour la Catalog Location offre des versions nettement plus up2date.

Parmi les nombreuses méthodes pour upgrader les firmware des composants d’un serveur Dell, il y en une qui nous intéressait beaucoup mais que nous n’arrivions pas à faire fonctionner : la méthode ftp.dell.com

The repository could either be ftp.dell.com or a user generated repository on the local network share.

Sur les serveurs Dell relativement récents, il est en effet possible de “stager” et “scheduler” toutes les updates matérielles possibles directement depuis l’iDRAC en live depuis le ftp Dell. Et depuis la version v.2.21.21.21 les firmwares des HDD/SSD sont complètement supportés même sur un contrôleur en mode HBA (passthrough).

Malheureusement impossible de trouver dans les docs Dell les informations nécessaires pour y arriver :

Mais ça c’était avant de connaitre Lionel, Onsite System Engineer chez Dell, qui nous a donné le trick :

FTP Address : ftp.dell.com
User Name : anonymous
Password : user@domain.com
Catalog Location : /
Catalog Filename : Catalog.xml.gz

D’après le serveur ftp de Dell, le password doit etre un e-mail : “Anonymous access allowed, send identity (e-mail name) as password.“

Ensuite vous rebootez quand vous voulez et les patchs sont appliqués (rapidement) par le Lifecycle Controler :

Merci Lionel

<14>2015-09-04T22:03:39.616Z esx.vmware.com vobd:  [VisorfsCorrelator] 2274728093499us: [esx.problem.visorfs.ramdisk.full] The ramdisk ‘vsantraces’ is full.  As a result, the file /vsantraces/vsantraces–2015-09-04T21h31m52s079.gz could not be written.

[...]

<14>2015-09-04T21:00:53.492Z esx.vmware.com vobd:  [VisorfsCorrelator] 2269273677949us: [vob.visorfs.ramdisk.full] Cannot extend visorfs file /vsantraces/vsantraces–2015-09-04T19h34m10s776.gz because its ramdisk (vsantraces) is full.

La cause de ce problème est assez simple : booter ESXi via USB ou SD card = visor-thin = partition /scratch dans la RAM. Et quand vous n’avez pas de scratch persistante, la partition /vsantraces est configurée par défaut à 300MB comme vous pouvez le constater dans /etc/vmware/vsan/vsantraced.conf :

# Ramdisk size in MB (do not increase over 300MB without a matching increase
# to coredump size).
#VSANTRACED_RAMDISK_SIZE=300

Or comme l’explique Cormac dans son post VSAN considerations when booting from USB/SD :

VSAN traces require ~500MB of disk space.

Aprés quelques échanges avec le support VMware, il nous a été confirmé qu’il était possible et supporté de changer la taille de cette partition en modifiant vsantraced.conf, ce que nous avons pu tester et valider en l’augmentant à 500MB pour mettre fin aux erreurs :

GSS nous a cependant mis en garde :

Just be aware that if you do so, you also must increase coredump size by the same value.

Il nous a également fallu rediriger le workingdir de la commande vm-support (lorsque nous en avons besoin) pour éviter l’erreur suivante :

IOError: [Errno 28] No space left on device

Une autre info interessante sur le sujet : Handling VSAN trace files when ESXi boots from a flash device

Historiquement, il était un peu complexe de générer ce genre d’interruption comme le détail William mais avec cette nouvelle API cela devient un jeu d’enfant en PowerCLI :

(Get-VM toto|Get-View).SendNMI()

Malheureusement, connecté au vCenter, on se mange une jolie erreur :

Exception calling “SendNMI” with “0″ argument(s): “The requested operation is not implemented by the server.”

Connecté en direct sur un ESX ça se passe nettement mieux :

En prime, on droit au nouvel événement VmGuestOSCrashedEvent :

<166>NoneZ visor04.lab.schitz.org Hostd: 2015-06-04T22:21:45.933Z info hostd[6DE83B70] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 894 : Win10 on visor04.lab.schitz.org: Guest operating system has crashed.

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=5298 http://www.hypervisor.fr/?p=5298#comments Fri, 13 Feb 2015 07:54:16 +0000 NiTRo http://www.hypervisor.fr/?p=5298 MAJ 18/05/2016 : Finalement les Large Pages c’est vraiment pas top…

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 !

Nous profitons de la sortie de FreeNAS 9.3, qui introduit le support des primitives VAAI TPST et TPSTUN, pour dissiper, une bonne fois pour toute on l’espère, le brouillard de bullshit récurant autour du thin on thin (en mode block).

Pour rappel, TPST(W) et TPSTUN, respectivement Thin Provisioning Space Threshold (Warning) et Thin Provisioning Stun, ont été introduites avec vSphere 5.0 très probablement pour répondre aux énormes risques que représente le thin on thin aka stocker un vmdk thin sur un LUN thin (TPSTUN existait en 4.1 sous le nom Out of Space Condition mais uniquement via plugin constructeur).

En effet, l’espace disponible d’un datastore VMFS est calculé de l’espace consommé par rapport à la taille du filesystem (SCSI oblige) contrairement à un datastore NFS qui interroge la baie/serveur pour le savoir. Ainsi, ESX n’a aucun moyen de savoir s’il reste assez ou plus (+) d’espace qu’il ne le croit. TPST (0×6 0×38 0×7) et TPSTUN (0×7 0×27 0×7) permettent à la baie/target de palier précisément à ce problème en envoyant aux clients/initiator des commandes SCSI lors du passage d’un certain seuil et/ou lorsqu’il n’y a plus d’espace du tout.

Soyons clair : thin|thick on thin sans TPSTUN + saturation de la baie = corruption de VM. Vous pouvez facilement le vérifier en faisant un test et sachez que nous l’avons vécu en production avec nos confrères vmdude et dagnu. On était content d’avoir du (veeam) backup…

Avant de rentrer dans le détail, voici un aperçu de notre vision des avantages et inconvénients des différentes combinaisons thin|thick on thin|thick :

• thick on thick : le top du top dans tous les domaines sauf celui le la rentabilité. Presqu’aucune intervention humaine n’est nécessaire excepté si les VM subissent des snapshot. Financièrement, c’est évidement la pire des solutions.
• thin on thick : le meilleur compromis. Seul l’espace touché est consommé (coté VMware) et en cas de datastore full seules les vm qui veulent grossir sont freezées.
• thin on thin : le rêve des admins SAN, le cauchemar des admins VMware. Cette solution nécessite un monitoring au top du sol au plafond et des tests de validation avant mise en production. Sans les primitives TPST et TPSTUN, cette solution est très proche de la roulette russe.
• thick on thin : les inconvénients du thin on thin sans les avantages. Vous pensez réserver l’espace en faisant du eagerzeroedthick mais en réalité la baie récupère les zéros et compresse le reste. Heureusement TPSTUN agit aussi sur les vmdk thick.

Concentrons nous sur le thin on thin puisque c’est la solution (assumée) qui tend à s’imposer officiellement (oui, avant vous “pensiez” faire du thin on thick). Tant que tout va bien, vous n’avez à craindre que l’impact du thin des vmdk. Mais quand l’espace vient à manquer dans la baie, on espère pour vous que ça se passe comme ça :

Lorsque vous aurez atteint le seuil (parfois) configurable du TPST, disons 75%, vous aurez droit à du “0×6 0×38 0×7″ dans vos logs à une fréquence qui dépend de son implémentation dans le logiciel qui contrôle la baie. Ces messages génèrent des événements esx.problem.scsi.device.thinprov.atquota et vob.scsi.device.thinprov.atquota que vous retrouverez dans le vCenter (alarme possible) sous la forme suivante :

Space utilization on thin-provisioned device naa.xyz exceeded configured threshold. Affected datastores (if any): “xyz”.

Si vous ne faites rien, vous finirez par atteindre le fond du panier et vous mangerez les fameux “0×7 0×27 0×7″. A ce moment là, ESXi freezera n’importe qu’elle VM demandant plus (+) d’espace et vous aurez droit à ce genre de message :

There is no more space for virtual disk xyz.vmdk. You might be able to continue this session by freeing disk space on the relevant volume, and clicking Retry. Click Cancel to terminate this session.

A cet instant précis, la seule et unique bonne chose à faire est de libérer de l’espace sur la baie. Nous avons à peu prés tout essayé de l’UNMAP jusqu’au VMFS3.OpenWithoutJournal sans obtenir de résultat stable. Si vous atteignez le “No space left on device“, la LUN est démontée et toutes vos VM passent en “inaccessible”. Et vous êtes dans la mer*e.

Notre conseil : testez, essayez de remplir/vider/re-remplir un LUN avant de partir en production (on à déjà vu des cas où TPST remontait mal voir pas du tout), monitorez bien les différents messages et commandes SCSI. Mais surtout, ne partez pas du principe que la baie ne sera jamais full…

Et pour ceux qui croiraient encore aux vertus du thick on thin, on vous laisse apprécier les joies d’un datastore full alors que le LUN ne l’est pas :

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.

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…

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”

The Global Positioning System (GPS) is a space-based satellite navigation system that provides location and time information in all weather conditions, anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.

[...]

About nine satellites are visible from any point on the ground at any one time, ensuring considerable redundancy over the minimum four satellites needed for a position.

[...]

GPS time is theoretically accurate to about 14 nanoseconds. However, most receivers lose accuracy in the interpretation of the signals and are only accurate to 100 nanoseconds

C’est sur le blog de Peter Mount que nous avons pu trouver un howto des plus simples au quel nous avons ajouté un dongle wifi usb :

Le tout monitoré grâce à un template cacti :

Et en prime, un module GPIO LedBorg RGB pour savoir de visu si la source GPS du serveur NTP est ok :

Enfin, pour les fanatiques de la précision, il y a le GPS/PPS sur Raspberry Pi détaillé par David Taylor.

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

ESX will not share large physical pages because:

The probability of finding two large pages that are identical is very low.
The overhead of performing a bit-by-bit comparison for a 2MB page is much higher than for a 4KB page.

Paradoxalement, c’est dans l’excellent Windows Internals que nous avons trouvé l’explication la plus synthétique à propos des large pages :

The primary advantage of large pages is speed of address translation for references to other data within the large page. This advantage exists because the first reference to any byte within a large page will cause the hardware’s translation look-aside buffer (TLB, described in a later section) to have in its cache the information necessary to translate references to any other byte within the large page. If small pages are used, more TLB entries are needed for the same range of virtual addresses, thus increasing recycling of entries as new virtual addresses require translation. This, in turn, means having to go back to the page table structures when references are made to virtual addresses outside the scope of a small page whose translation has been cached. The TLB is a very small cache, and thus large pages make better use of this limited resource.

On comprend donc aisément que sur des systèmes avec de plus en plus de RAM, les accès au TLB puissent être coûteux en CPU sans l’utilisation des large pages. Par contre, lorsqu’il n’y a plus de pages de 2Mo disponibles et parce que les large pages ne peuvent pas être swappées, ESX “casse” les large pages en small pages (dont le hash a déjà été computé) et TPS déduplique le tout :

Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages. ESX tries to share those small pages using the pre-generated hashes before they are swapped out.

Sur un système raisonnablement overcommité et sans tuning spécifique, l’ESX risque de ne pas “casser” et dedupliquer les pages suffisamment rapidement pour répondre à la demande de mémoire, ce qui peut engendrer une dégradation de performance (ballooning/zipping/swapping). A l’inverse, si le coût CPU est acceptable, le même système tuné pour ne faire que (ou presque que) des small pages n’aura pas cette problématique.

Ci dessous, la comparaison des stats mémoire d’un cluster (composé de serveurs à base d’Intel Nehalem) sans tuning spécifique et des stats de ce même cluster après avoir forcé l’utilisation des small pages sur les vm (workload comparable) :

La première chose qui frappe c’est le compteur “consumed” qui a diminué de moitié (le workload s’y prête bien dans ce cas puisqu’il s’agit d’une ferme de serveurs xenapp) grâce à TPS,  le compteur “shared” a en effet été multiplié par 10. Dans le cas présent, la consommation CPU a augmenté d’environ 15% lors du passage aux small pages.

Voici la commande powershell qui a permis de désactiver les large pages sur les vm (vm reboot ou “vmotion shake” pour la prise en compte) :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.ExtraConfig|?{$_.Key -eq "monitor_control.disable_mmu_largepages"}|?{$_.value -match "true|1"})}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=(New-Object Vmware.Vim.OptionValue -Property @{Key="monitor_control.disable_mmu_largepages";Value="1"})}))}

Il est également possible d’obtenir un résultat similaire en forçant la VMM a utiliser le mode mmu software :

C’est quasiment identique mais la grande classe c’est qu’en powershell on peut forcer le mode cpu auto et le mode mmu software de la VMM (impossible en GUI) :

Get-View -ViewType virtualmachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.Flags.VirtualExecUsage -eq "hvauto" -and $_.Config.Flags.VirtualMmuUsage -eq "off")}|%{($_.ReconfigVM_Task((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{flags=(New-Object VMware.Vim.VirtualMachineFlagInfo -property @{virtualExecUsage="hvauto";virtualMmuUsage="off"})})))}

C’est beau mais pas vraiment pratique à maintenir à cause des erreurs possibles via la GUI. De plus, nous avons eu l’opportunité précieuse d’échanger avec un Senior Staff Engineer de chez VMware qui nous a laissé entendre que ce n’était pas la meilleure option :

The sw-mmu [...] has slightly higher overheads (for the shadow pagetables and related data structures) and this will reduce the total available memory for backing guest pages.

Dans notre grande quête d’overcommit, notre contact chez VMware nous a parlé d’un paramètre assez génial qui permet de changer la politique d’allocation agressive de large pages de la mmu (en anglais c’est plus facile à comprendre) :

The heuristic, when enabled, basically says that whenever possible when backing any part of a 2MB-region of guest memory, try to do so with a large 2MB page. This may involve remapping existing small 4KB pages into that new 2MB page. But it basically tries to aggressively back everything large

Ce qui explique pourquoi, par défaut, TPS n’a presque pas d’effet (sauf pour les zero) même pour les guest qui ne “demandent” pas de large pages. La raison est bien liée aux performances :

When overcommitment isn’t an issue, large pages really do help TLB-performance with hw-mmu on most workloads.

A l’inverse, si on passe le paramètre à 0 (sched.mem.alwaysTryLPageAlloc pour une vm ou LPage.LPageAlwaysTryForNPT pour un host) la mmu n’allouera une large page qu’à la demande du guest. L’explication est d’ailleurs disponible au fin fond du documentation center de VMware :

Try to allocate large pages for nested page tables (called ‘RVI’ by AMD or ‘EPT’ by Intel). If you enable this option, all guest memory is backed with large pages in machines that use nested page tables. If NPT is not available, only some portion of guest memory is backed with large pages.

Vous aurez compris où nous voulons en venir : trouver un bon équilibre entre le bénéfice en matière de performance des large pages (presque incontestable lorsque c’est le guest qui en fait la demande) et le bénéfice de TPS en matière de consolidation mémoire. Exemple sur notre fameux cluster :

Si vous êtes attentif vous aurez remarqué qu’il n’y a que très peu de différence de consolidation avec les résultats en mode small pages forcées, c’était une feinte pour ceux du fond qui ne suivent pas… Dans ce cas c’est parfaitement normal car aucun des guestOS présent dans cet exemple n’utilise de large pages (windows 2003 32bit). Si les vm avaient été, par exemple, des windows 2008 R2, le niveau de consommation se serait situé quelque part entre le “full” large pages et le “full” small pages en fonction des applications et du comportement de l’OS. Nous ne manquerons pas de compléter ce post avec un exemple impliquant des guestOS et des applications exploitant les large pages.

Voici la commande powershell qui a permis de désactiver sched.mem.alwaysTryLPageAlloc sur les vm (vm reboot ou “vmotion shake” pour la prise en compte) :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{!($_.Config.ExtraConfig|?{$_.Key -eq "sched.mem.alwaysTryLPageAlloc"}|?{$_.value -match "false|0"})}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=(New-Object Vmware.Vim.OptionValue -Property @{Key="sched.mem.alwaysTryLPageAlloc";Value="0"})}))}

Pour afficher un tableau récapitulatif des infos qui nous intéressent :

Get-View -ViewType VirtualMachine|?{!$_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|select @{n="VM";e={$_.Name}}, @{n="HV";e={$_.Config.Flags.VirtualExecUsage}}, @{n="HVMMU";e={$_.Config.Flags.VirtualMmuUsage}}, @{n="disable_mmu_largepages";e={($_.Config.ExtraConfig|?{$_.Key -eq "monitor_control.disable_mmu_largepages"}).value}}, @{n="alwaysTryLPageAlloc";e={($_.Config.ExtraConfig|?{$_.Key -eq "sched.mem.alwaysTryLPageAlloc"}).value}}, @{n="ESX";e={(Get-View -property Name $_.Runtime.Host).Name}}|sort hv,hvmmu,disable_mmu_largepages,alwaysTryLPageAlloc,ESX|ft -AutoSize

Pour information, depuis ESXi 5.0, il existe une commande très utile pour monitorer l’utilisation des large pages (memstats -r lpage-stats -v) :

En cas de vmotion, les pages de la “future” vm sont allouées au format 4k et reconverties par la suite :

The vmkernel allocates the memory for a VM during precopy using small pages. These are then converted to large as the VM begins to run but it is based on guest accesses. esx5.0 and esx5.1 each improved on the ability to recover the large mappings.

Et parce que nous sommes de grands fan de l’overcommit mémoire, voici notre poudre de perlimpinpin à ajouter dans vos recettes de scripts de déploiements si vous voulez overcommiter bien comme il faut (nous déclinons toute implosion de votre infra…) :

vim-cmd hostsvc/advopt/update VMkernel.Boot.sharePerNode bool false
vim-cmd hostsvc/advopt/update Mem.ShareRateMax long 32768
vim-cmd hostsvc/advopt/update Mem.ShareScanTime long 10
vim-cmd hostsvc/advopt/update Mem.ShareScanGHz long 32
vim-cmd hostsvc/advopt/update Mem.IdleTax long 95
#vim-cmd hostsvc/advopt/update Mem.AllocGuestLargePage long 0
#vim-cmd hostsvc/advopt/update Mem.AllocGuestRemoteLargePage long 0
#vim-cmd hostsvc/advopt/update LPage.LPageAlwaysTryForNPT long 0
vim-cmd hostsvc/advopt/update Mem.MemZipMaxPct long 25
#vsish -e set /sched/freeMemoryState/minFreePct 3

Nous finirons par une petite citation pour ceux qui ne jurent que par les large pages (qui a dit Hyper-V ?!) :

The performance increase is somewhat dependant upon the type of workload the virtual machine is executing; memory-intensive applications see more performance improvement than applications that are not heavily dependent on memory access.

Un grand merci à Alex Garthwaite pour son aide à la rédaction de ce post et à la compréhension des mécanismes de gestion de la mémoire d’ESX.

In ESXi 5.0, VMW_PSP_MRU has path ranking capabilities that allows you to assign ranks to individual paths. VMW_PSP_MRU goes through the path group states in the following order: Active, Active_UO and Standby, and picks a path that has the highest rank for I/O.

Evidemment, le scénario dans le quel le path ranking nous intéresse le plus est le fameux FC to iSCSI failover dans le quel nous étions particulièrement gêné par le fait que les chemins en FC n’étaient pas prioritaires sur les chemins iSCSI et pouvant mener à des situations où un chemin iSCSI serait utilisé alors qu’un chemin FC serait disponible :

On passe le PSP du datastore en MRU et un coup de PowerCLI pour monter le ranking des chemins FC :

(Get-VMHost esx.vmware.com|Get-EsxCli).storage.nmp.path.list("naa.0123456789")|sort RuntimeName|select RuntimeName, @{n="rank";e={(Get-VMHost esx.vmware.com|Get-EsxCli).storage.nmp.psp.generic.pathconfig.get($_.RuntimeName)}}|ft -AutoSize

(Get-VMHost vmvisor01.vmwa.re|Get-EsxCli).storage.nmp.psp.generic.pathconfig.set("rank=1","vmhba0:C0:T0:L0")

Le (bon) résultat est immédiat :

]]> http://www.hypervisor.fr/?feed=rss2&p=4389 4 http://www.hypervisor.fr/?p=4289 http://www.hypervisor.fr/?p=4289#comments Sun, 21 Oct 2012 21:18:48 +0000 NiTRo http://www.hypervisor.fr/?p=4289 Pour ceux qui n’y croient pas ou ceux qui ont trop peur d’essayer, nous avons pu valider avec succès la méthode sur une carte IBM BR10i (à base de LSI 1068e) :

C’est tellement plus pratique dans une VM

Ok, rien d’exceptionnel si ce n’est le très bon rapport qualité/prix et un système de fermeture “eagle-hook” très efficace. En effet, 4 slots 2.5″ dans une baie 5.25″ tout le monde en fait depuis longtemps mais Cremax s’apprête à lancer un rack similaire avec une légère différence : il aura 6 slots. Oui vous avez bien lu, un rack 100% métal 6 slots 2.5″ dans une seule baie 5.25″ avec le même système ”eagle-hook” et un switch High/Low/Off pour la ventilation.

Nous avons eu l’immense privilège d’obtenir un sample afin de vous le faire découvrir sous toutes les coutures mais surtout dans ce pourquoi il a été conçu : un NAS ultra compact.

Tout d’abord, comparons notre EZ Compact 6 (son vrai nom c’est MB996SP-6SB mais Cremax France a accepté de lui donner un nom un peu plus sexy pour l’occasion) avec son petit frère :

Vous noterez que là ou l’EZ Compact 4 pouvait accueillir des disques ou SSD jusqu’à 15mm de haut, la version 6 slots ne peut évidement accueillir que des 9mm max. Heureusement, la majorité des unités 2.5″ font 9mm ou même 7mm pour les SSD récents.

On remarque également que la version 6 slots est plus courte de quelques centimètres qui pourront s’avérer précieux dans les encombrements les plus réduits (comme celui de notre NAS de test).

Concernant l’aspect refroidissement, nous avons mentionné la présence d’un interrupteur (présent également sur la nouvelle version de l’EZ Compact 4 -SATA- qui n’a plus qu’un seul connecteur molex) permettant de choisir le mode de fonctionnement (High/Low/Off) de l’unique ventilateur. Vous l’aurez deviné, les SSD sont donc un choix idéal pour ce rack.

Pour notre test, nous nous sommes procuré 6 SSD Intel 320 Series de 160Go afin de vérifier que notre nouveau backplane ne serait pas un goulet d’étranglement pour les configurations les plus extrêmes :

Et un HP Proliant MicroServer (aka N40L que notre ami vmdude.fr à testé avec 16Go de RAM) pour vérifier que l’encombrement du EZ Compact 6 puisse s’adapter aux configurations les plus compactes :

Comme vous pourrez le vérifier sur les photos, le N40L est très dense mais particulièrement bien conçu et où chaque cm3 d’espace est exploité ou exploitable car il est possible d’ajouter quelques options. Il y a en l’occurrence un slot PCIe 16x low-profile dans lequel nous avons installé une carte IBM ServeRAID-BR10i (chip LSI 1068E) très abordable et facilement trouvable sur ebay.

Nous avons presque eu du mal à passer les 2 cables SFF-8087 nécessaires pour relier le rack à la carte mais à l’inverse vous pouvez constater que l’EZ Compact 6 est parfaitement à l’aise dans cet environnement plus que condensé. L’emplacement 5.25″ étant prévu pour accueillir un lecteur optique générallement plus profond, on a même le luxe d’un peut d’espace libre derrière le rack :

On en croirait presque que l’EZ Compact 6 est fait pour le N40L tant l’intégration est “fluide”, à l’opposé on peut égallement rêver d’une configuration à base de Lian Li PC-A17B blindé d’un total de 54 SSD !

La carte BR10i que nous avons utilisé a l’avantage de présenter les disques directement à l’OS sans passer par une configuration RAID quelconque (IT mode). C’est donc tout naturellement que nous avons installé FreeNAS sur une clef usb et créé un beau zpool avec les 6 SSD en stripping. Nous aurions très bien pu choisir EON comme nous le recommande notre-pote-Rémi, l’expert ZFS en chef. D’autant plus que la dernière beta est basé sur Illumos, digne successeur fork d’opensolaris. Malheureusement Nexenta n’étant pas stateless, il ne sera évidement pas envisageable de lui consacrer 2 périphériques. ZFS oblige, nous avons du réduire au minimum l’ARC afin de ne pas solliciter la RAM lors des tests.

Pour ce benchmark, nous avons utilisé iozone qui est un outil bien connu dans l’univers du stockage. Parmi tous les tests disponibles, c’est évidement celui de la lecture qui aura permis d’atteindre les débits les plus importants dans notre configuration. Le test à été effectué sur une plage de 256Mo à 16Go pour la taille de fichier avec une plage de 16k à 16M pour le “record size”. Couplé à gnuplot, ça donne des beaux graphiques :

Sur les résultats du test read, on constate clairement un “effet de cache” sur les premiers résultats et une stabilisation autour d’1Go/s (~8Gb/s) sur tout le reste du test. On est donc très proches des capacités brut des 6 SSD en parallèle ce qui est tout à fait honorable et permet de confirmer que le backplane est largement capable de supporter des gros débits.

Conclusion, si vous chercher de quoi loger un maximum d’unité 2.5″ dans un minimum d’espace à un prix abordable (environ 100€ au lancement d’après Cremax France) sans sacrifier la qualité, ce rack est clairement le meilleur choix aujourd’hui. En face on a du supermicro à un tarif exorbitant ou du Thermaltake trop cheap et surtout indisponible sur le marché.

]]> http://www.hypervisor.fr/?feed=rss2&p=4093 39 http://www.hypervisor.fr/?p=4039 http://www.hypervisor.fr/?p=4039#comments Fri, 10 Aug 2012 07:09:04 +0000 NiTRo http://www.hypervisor.fr/?p=4039 Suite à notre post sur la création d’alarmes de latence pour les datastore, nous nous sommes aperçu que sur des environnements relativement important cela pouvait générer une quantité importante d’events inutiles. En effet, les alarmes étant créées à la “racine” du vCenter et propagées sur tous les hosts par héritage, il est fréquent de voir des events liés à une alarme (green>gray et gray>green lors d’un reboot par exemple) d’un datastore n’existant pas sur l’ESX en question. Nous avons donc modifiés nos onliner pour que les alarmes soient créées à la “racine” des cluster et comme le nom d’une alarme doit être unique, nous y avons rajouté le nom du cluster :

Alarme de latence Read ou Write pour datastore partagé NFS par cluster, yellow 300ms/5min et red 500ms/3min (mailto:admin@vmware.local) :

foreach ($vicluster in Get-View -ViewType ClusterComputeResource) {foreach ($dsname in ($vicluster.Datastore|%{Get-View $_}|?{$_.summary.Accessible -and $_.summary.MultipleHostAccess -and $_.info.nas})){if (!((Get-View AlarmManager).GetAlarm($vicluster.moref)|?{(get-view $_).info.name -match "Datastore $($dsname.name) datastore RW latency"})){(Get-View AlarmManager).CreateAlarm($vicluster.moref,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Datastore $($dsname.name) datastore RW latency in $($vicluster.name)";Description = "Custom alarm to monitor NFS $($dsname.name) ($($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)) read or write latency in $($vicluster.name)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "datastore"}|?{$_.nameinfo.key -match "totalReadLatency"}|?{$_.RollupType -match "average"}).key;Instance = ($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)});Operator = "isAbove";Yellow = "300";YellowInterval = "300";Red = "500";RedInterval = "180";Type = "HostSystem"});(New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "datastore"}|?{$_.nameinfo.key -match "totalWriteLatency"}|?{$_.RollupType -match "average"}).key;Instance = ($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)});Operator = "isAbove";Yellow = "300";YellowInterval = "300";Red = "500";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] $($dsname.name) RW latency on {targetName}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}}}

Alarme de latence Read ou Write pour datastore partagé VMFS par cluster, yellow 30ms/5min et red 40ms/3min (mailto:admin@vmware.local) :

foreach ($vicluster in Get-View -ViewType ClusterComputeResource) {foreach ($dsname in ($vicluster.Datastore|%{Get-View $_}|?{$_.summary.Accessible -and $_.summary.MultipleHostAccess -and $_.info.vmfs})){if (!((Get-View AlarmManager).GetAlarm($vicluster.moref)|?{(get-view $_).info.name -match "Datastore $($dsname.name) RW latency in $($vicluster.name)"})){(Get-View AlarmManager).CreateAlarm($vicluster.moref,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Datastore $($dsname.name) RW latency in $($vicluster.name)";Description = "Custom alarm to monitor VMFS $($dsname.name) ($($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)) read or write latency in $($vicluster.name)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "datastore"}|?{$_.nameinfo.key -match "totalReadLatency"}|?{$_.RollupType -match "average"}).key;Instance = ($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)});Operator = "isAbove";Yellow = "30";YellowInterval = "300";Red = "40";RedInterval = "180";Type = "HostSystem"});(New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "datastore"}|?{$_.nameinfo.key -match "totalWriteLatency"}|?{$_.RollupType -match "average"}).key;Instance = ($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)});Operator = "isAbove";Yellow = "30";YellowInterval = "300";Red = "40";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] $($dsname.name) RW latency on {targetName}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}}}

Alarme de latence SIOC Normalized Latency pour datastore partagé par cluster, yellow 30ms/5min et red 40ms/3min (mailto:admin@vmware.local) :

foreach ($vicluster in Get-View -ViewType ClusterComputeResource) {foreach ($dsname in ($vicluster.Datastore|%{Get-View $_}|?{$_.summary.Accessible -and $_.summary.MultipleHostAccess -and $_.IormConfiguration.Enabled})){if (!((Get-View AlarmManager).GetAlarm($vicluster.moref)|?{(get-view $_).info.name -match "Datastore $($dsname.name) SIOC Normalized Latency in $($vicluster.name)"})){(Get-View AlarmManager).CreateAlarm($vicluster.moref,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Datastore $($dsname.name) SIOC Normalized Latency in $($vicluster.name)";Description = "Custom alarm to monitor $($dsname.name) ($($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)) datastore SIOC Normalized Latency in $($vicluster.name)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "datastore"}|?{$_.nameinfo.key -match "sizeNormalizedDatastoreLatency"}|?{$_.RollupType -match "average"}).key;Instance = ($dsname|%{$_.Host}|%{$_.MountInfo.Path.split("/")[-1]}|sort -unique)});Operator = "isAbove";Yellow = "30000";YellowInterval = "300";Red = "40000";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] $($dsname.name) SIOC Normalized Latency on {targetName}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}}}

Alarme de Disk Command aborts pour datastore VMFS partagé par cluster, en cas de défaillance/saturation DAS/SAN/iSCSI (mailto:admin@vmware.local) :

foreach ($vicluster in Get-View -ViewType ClusterComputeResource) {foreach ($diskname in ($vicluster.Datastore|%{Get-View $_}|?{$_.info.vmfs -and $_.summary.Accessible -and $_.summary.MultipleHostAccess}|%{$_.info.vmfs.extent}|%{$_.diskname})){if (!((Get-View AlarmManager).GetAlarm($vicluster.moref)|?{(get-view $_).info.name -match "Disk $diskname command aborts"})){(Get-View AlarmManager).CreateAlarm($vicluster.moref,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Disk $diskname command aborts in $($vicluster.name)";Description = "Custom alarm to monitor $diskname disk command aborts in $($vicluster.name)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = (New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "disk"}|?{$_.nameinfo.key -match "commandsAborted"}|?{$_.GroupInfo.Key -ne "virtualDisk"}|?{$_.RollupType -match "summation"}).key;Instance = $diskname});Operator = "isAbove";Yellow = "1";Red = "2";Type = "HostSystem"})});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] command aborts on disk $diskname on {targetName}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))}}}

Durant l’OpenStorage Summit EMEA 2012, Andy Bennett raconte comment VMware a sollicité Nexenta pour pondre une solution de stockage comparable aux Vblocks d’EMC et FlexPods de NetApp mais à un coût radicalement inférieur (l’objectif était le meilleur prix au Téraoctet) et comment cette solution s’est retrouvée à héberger une partie des “Hands on lab” des 2 VMworld 2011 avec des disques NL-SAS 7500 rpm en face d’EMC et NetApp avec des baies remplies de SAS 15K et de SSD.

Résultat, plus de de 10 milliards d’IOPS NFS sur les 2 VMworld à 2ms en moyenne (~1,2 VM déployées par seconde !) avec une solution à 330K$ face à NetApp et EMC avec des solution à 2M$…

Il raconte également comment un module de RAM défectueux a fait planter un des nœuds de leur cluster sans conséquence sur les labs mais aussi comment, en quelques heures seulement, l’un des membres de l’équipe a designé et codé la fameuse interface Aura (basé sur DTrace) contenant les metrics les plus importants pour les équipes d’experts VMware qui monitoraient l’infrastructure sur place. Du caviar pour les plus curieux d’entre nous…

Cette bonne nouvelle, nous la devons à crucial qui produit des modules de 8Go DDR3 PC3-10600 Unbuffered ECC *Quad Rank*. Il vous en coûtera pas loin de 600€ pour 4 de ces “gros barreaux” mais cela décuplera sans nul doute le potentiel de votre lab.

Il est fort probable que d’autres modules compatibles existent aussi chez d’autres constructeurs mais qui s’y risquerait sans confirmation ?