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=5447 http://www.hypervisor.fr/?p=5447#comments Wed, 25 Mar 2015 21:50:54 +0000 NiTRo http://www.hypervisor.fr/?p=5447 Puisque l’autre cofondateur de SexiLog s’est fendu d’un post plutôt joufflu, nous ne ferons que compléter l’argumentaire En l’occurrence, notre recherche de solution de gestion de logs pour ESXi remonte à bien avant Graylog2 avec le fameux php-syslog-ng (devenu le très payant LogZilla), puis LogAnalyzer. Ensuite il y a eu la tentative raté de Partylog2. Et on ne vous parle pas du misérable vSphere Syslog Collector ni du coûteux Log Insight… Pour finir par le faire nous même :

Nous vous recommandons donc vivement de vous rendre sur sexilog.fr pour y télécharger la dernière version de l’appliance et la déployer sur votre infra, envoyer vos logs ESXi dessus et profitez des dashboards intégrés

Rock n’ Log!

Ah tiens, on a oublié de parler de Splunk.

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 !

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 !

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”

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

su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production streamalarms:send>>/var/log/graylog.log'
su - -c 'cd /usr/share/graylog2-web;rake RAILS_ENV=production subscriptions:send>>/var/log/graylog.log'

Ceux qui connaissent Graylog2 savent à quel point c’est un serveur syslog surpuissant mais pas vraiment simple à installer. De plus, ceux qui s’en servent pour des ESXi ont eu la douloureuse surprise de constater que graylog2 ne supportait pas le format syslog d’ESXi 5.x alors que celui de 4.x était parfaitement géré. Nous allons donc faire d’une pierre deux coups.

En ce qui concerne la simplicité, Mick Pollard a posté cet été comment utiliser ses packages sur un Ubuntu 12.04, ce à quoi nous ajouterons des morceaux d’un autre how-to pour faire tourner l’interface web de graylog2 sous apache.

Et pour la compatibilité, nous configurerons graylog2 pour écouter sur un port “alternatif” (10514 dans notre exemple) car le port 514 sera pour rsyslog qui réécrira tout ce qui passe au bon format et le forwardera (non, ce mot n’existe pas) à graylog2. Attention ca va aller très vite :

echo 'deb http://ppa.lunix.com.au/ubuntu/ precise main' | sudo tee /etc/apt/sources.list.d/aussielunix.list
apt-key adv --keyserver keyserver.ubuntu.com --recv D77A4DCC
apt-get update
apt-get install mongodb elasticsearch graylog2-server graylog2-web apache2 libapache2-mod-passenger

Vous pouvez aller boire un café, ya ~500Mo à downloader/installer. Ensuite il faut configurer quelques trucs :

/etc/graylog2.conf
syslog_listen_port = 10514

/etc/rsyslog.conf
$ModLoad immark
$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514

/etc/rsyslog.d/50-default.conf
#*.*;auth,authpriv.none -/var/log/syslog

/etc/apache2/sites-available/default

<VirtualHost *:80>
    DocumentRoot /usr/share/graylog2-web/public/
        RailsEnv 'production'
    <Directory /usr/share/graylog2-web/public/>
        Allow from all
        Options -MultiViews
    </Directory>

    ErrorLog /var/log/apache2/error.log
    LogLevel warn
    CustomLog /var/log/apache2/access.log combined
</VirtualHost>

/etc/rsyslog.d/32-graylog2.conf

$template GRAYLOG2,"<%PRI%>1 %timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% - %APP-NAME%: %msg:::drop-last-lf%\n"
$ActionForwardDefaultTemplate GRAYLOG2
$PreserveFQDN on
*.*     @localhost:10514

/etc/security/limits.conf
root – nofile 64000
root – memlock unlimited

/etc/pam.d/su
session required pam_limits.so

Après, on secoue bien :

service elasticsearch start
service mongodb restart
service graylog2-server start
service rsyslog restart
service apache2 restart

Selon le formatage des messages, il est parfois nécessaire d’avoir un reverse DNS pour que le hostname remonte bien (au lieu de l’ip). Sur le screenshot suivant vous pourrez constater la présence de log provenant d’ESXi 5, de pfSense et d’Astaro/UTM mais nous avons pu également valider que cette solution était fonctionnelle pour ESXi 4, FreeNAS, NTsyslog, Snare/Epilog et nxlog.

On vous laisse découvrir les joyeusetés des streams et des analytics de Graylog2

B&R 6.1 will not be officially supported with vSphere 5.1
[...]
we will NOT be performing any further testing of B&R 6.1 vs. vSphere 5.1, and instead will focus our efforts on B&R 6.5 release – which, in addition to all the new functionality, will include full vSphere 5.1 support.

C’est pas cool mais la bonne nouvelle c’est que B&R 6.5 intégrera gratuitement Veeam Explorer for Exchange, en beta depuis quelques semaines. Ce super outil permet de visualiser ou d’extraire des mails vers un fichier pst depuis un backup d’une base exchange.

Veeam Explorer for Exchange is a new feature of Veeam Backup & Replication. Currently available as a beta, Veeam Explorer will be included in all editions of Veeam Backup—even Free Edition. You no longer need expensive standalone tools for Exchange item recovery that are licensed per mailbox.

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=3123 http://www.hypervisor.fr/?p=3123#comments Fri, 08 Jul 2011 13:04:05 +0000 NiTRo http://www.hypervisor.fr/?p=3123 Nous profitons de l’annonce du lancement de la version Community Edition de VMTurbo (anciennement VMTurbo Monitor mais pas de gros changements, juste un renommage marketing) pour vous faire partager notre expérience très positive du produit.

A la base, hors considérations de licensing, VMTurbo Virtualization Management Suite est (surprise !) une suite de composants offrant (re-surprise !) un outil de monitoring (c’est ce composant qui est gratuit) sur lequel s’appuient 3 autres outils : capacity planning, reporting et optimisation. Ce dernier est un genre de DRS à large scope qui peut vous suggérer (et surtout le faire pour vous si vous achetez la licence) de diminuer la quantité de ram d’une VM, de lui rajouter un vcpu ou de la  déplacer sur un autre datastore en fonction des métrics remonté par monitor.

Le composant qui nous intéresse le plus est évidement ”monitor” qui se démarque par sa simplicité et surtout par sa fluidité (accès web mais flash). Même sur une grosse infra vous n’aurez pas l’effet “usine à gaz” que peuvent offrir certains produits concurrents…

Cette simplicité peut aussi lui être reproché mais imaginons que vous souhaitiez vérifier que vous n’avez pas trop de CPU Ready Time sur toutes les VM d’un cluster, que vous souhaitiez connaitre la tendance en IOPS d’une VM, ou encore que vous vous inquiétiez du niveau de latence d’un datastore, ça vous donne quelque chose comme ça :

Ajoutez à cela un format appliance (assez light) en ovf avec pour seule configuration la config réseau et l’ajout du (ou des) vcenter à monitorer et vous obtenez un produit à tester d’urgence si ce n’est pas déjà fait !

Depuis ce matin, VMware offre VMware Compliance Checker for vSphere qui s’installe rapidement sous Windows (nécessite une JRE) et s’utilise via une GUI minimaliste :

Le report (sous forme de page web -incompatible avec Chrome !?-) est bien clean et contient le détail de chaque check :

Nous vous rappelons également l’existence du plugin SiteSurvey Report permettant de tester rapidement la capacité des membres d’un cluster à supporter Fault Tolerance :

(1-contention rapide / 2-contention lente)

De plus, comme indiqué dans le Resource Management Guide, plus la VM est riche en vCPU et en vRAM, plus elle imposera un overhead important au VMkernel. Cet overhead est réservé et donc totalement “perdu”. Il ne sera pas non plus soumis aux differents mécanismes de récupération d’ESX (Transparent Page Sharing > Memory Idle Tax/Ballooning > Memory Compression > Hypervisor Swapping).

On ne parle que d’une centaine de Mo pour une VM avec 1 vCPU et 1Go de vRAM, mais un petit one-liner de PowerCLI nous permet de savoir de combien on parle pour une infra de plus de 1200 VM :

Write-Host -ForegroundColor Red -BackgroundColor Yellow $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Runtime|Measure-Object -Sum -Property MemoryOverhead).sum/1GB,1)) / $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Config|Measure-Object -Sum -Property MemorySizeMB).sum/1KB,1))

Presque 220Go d’overhead sur environ 3,8To de vRAM attribué, soit près de 6% !

Il est donc nettement plus judicieux de bien determiner la taille de vRAM nécéssaire au “Guest OS“ et de tailler au plus juste plutot que mettre une valeur trop large au risque de voir la VM en souffrir plutot que d’en bénéficier (idem pour les vCPU d’ailleurs).

A lire tous les soirs après s’etre brossé les dents : Understanding Memory Resource Management in VMware ESX 4.1

Ça n’a qu’un lointain rapport avec la virtualisation mais puisque ca peut aussi vous arriver sur une VM, nous avons pensé que cela pourrai toujours servir de faire un petit retour d’expérience sur les solutions antivirus offline gratuites et efficaces. Après avoir subit les foudres d’un horrible trojan polymorphe à tête chercheuse, nous nous sommes retrouvés avec un Windows 7 tellement pourri qu’il ne reboutait même plus décemment, même après un coup de NAV 10 (ok, nous l’avions cherché, NAV avait été -bêtement- désactivé volontairement pour suspicion de zèle). Visez un peu le chantier :

(Cain ça compte pas…)

Une seule solution : trouver un antivirus sous forme de liveCD qui tienne un minimum la route. Trois secondes de google plus tard (à partir d’une autre machine biensur), nous trouvions des munitions. Les 2 meilleurs que nous ayons essayé sont Kaspersky Rescue Disk 10 (disponible aussi pour clef usb) et BitDefender Rescue CD. La particularité de ces 2 solutions est que si la machine victime à accès à Internet, il est possible de faire une mise à jour des signatures avant le scan. 1h après le massacre, l’OS a rebooté correctement même si nous avons du en tuer encore des bouts vivant grâce au Kaspersky Removal Tool, encore plus complet et tout aussi gratuit.

Il est 5h du mat’ donc je ne m’abaisserai pas à dire ce que je pense de ceux qui pondent ce genre de trojans pourris par contre je remercie sincèrement les gens de chez Kaspersky et BitDefender de mettre à dispo ce genre d’outils qui sans nuls doutes laissent une trace indélébile dans nos esprits, surtout dans les moments les plus délicats. A prendre en compte lors du choix d’une solution AV…

Runtime processes for guest processing (also known as the Veeam VSS agent) no longer require a direct network connection between the backup server and the processed VM. This allows you to process VMs that are behind firewalls or located in a DMZ or other network that the backup server cannot access.

Sortie il y a à peine quelques jours, la liste des nouveautés de Veeam Backup & Replication v5 est hallucinante. Instant VM Recovery mise à part, voici nos préférées :

• Universal Application-Item Recovery *
• SureBackup Recovery Verification **
• Guest File System Indexing ***
• VM-level retention
• ZFS support
• VM search (Restore)
• Datastore-based jobs
• Continuous job schedule

* Connecteurs applicatifs pour une restauration d’objet type AD, Exchange ou SQL
** Test/validation de restauration dans un environnement cloisonné
*** Catalogue d’index des fichiers contenu dans les backup

Ce qui frappe le plus dans cette liste c’est le nombre de “petites bonnes idées” qui fait de Veeam Backup un produit encore plus différent des solutions de backup traditionnelles. Consultez le User Guide de la v5 si vous avez encore des doutes

Revenons sur Instant VM Recovery qui nous a clairement marqué par son ingéniosité : vous avez la possibilité de démarrer la VM directement depuis l’archive de backup ! Vous pouvez ainsi valider instantanément si la VM (ou le restore point) que vous voulez restaurer est le bon.  Le tout grâce à un service NFS qui présente à l’ESX un datastore contenant la VM :

Et si le stockage qui héberge le fichier est trop lent, vous pouvez rediriger (grâce à un simple snapshot) les I/O sur un datastore plus rapide. Surpuissant !

Voici une video issue de notre test :

Veeam Backup & Replication 5.0 – Instant VM Recovery (avi)

Veeam réussi clairement à garder sa philosophie “proche des utilisateurs” pour le développement des ses produits. Ce qui explique, en autre, le succès de cette petite boite qui a pondu, fin 2006, l’un des outils les plus populaire pour VI3 : FastSCP.

L’une d’entre elles, Heterogeneous Pools, permet de composer un cluster (Pool chez Citrix) avec des serveurs dont les cpu sont de différentes générations  en s’appuyant sur Intel Flex Migration et AMD Extended Migration (tout comme VMware EVC depuis Q3 2008…). On comprend très bien l’intérêt de pouvoir mixer des Xeon Core 2 avec des Xeon Core i7 mais lorsque qu’on tente de mixer 2 serveurs identiques avec une simple difference de stepping (codification des révisions chez Intel, induisant des corrections de bug et/ou évolution de process de fabrication), on a droit à un joli message d’erreur :

Là on se dit, Citrix a voulu assurer grave sur les pools hétérogènes pour éviter les problèmes de XenMotion. Oui mais non. Car si sur ces mêmes serveurs, vous installez XenServer 5.5, toujours avec des licences gratuites, que vous créez un pool avec et que vous upgradez ce pool en 5.6, ca marche :

Je vous laisse en tirer la conclusion qui adhérera le mieux à votre niveau de paranoïa…

Lors des Synergy 2010, Citrix a annoncé (lors d’un show plein de démos ratées…) la disponibilité de la RC de XenClient, l’hyperviseur client de Citrix. C’est donc VMware qui perd sur son propre terrain et s’en est suivi, comme de coutume, une tirade de justifications douteuses sur l’intérêt réel d’un hyperviseur client, finalement trop limitatif selon VMware. Et pour être limité, XenClient est très limité : 9 modèles de laptop supportés et seulement 3 OS (XP, Vista et Win7). On regrette donc vraiment l’absence de support d’une version de linux, la faute au xenclient-tools indispensables au bon fonctionnement de la VM et de l’accès aux périphériques (usb, eth, wifi, etc…) grâce aux PV drivers.

Avec la collaboration de notre cher confrère CTXBLOG, nous avons pu nous procurer un HP Elite Book 2530p pour un petit test rapide. Nous n’avons pas eu le temps de tester l’appliance Citrix Synchronizer qui permet de mettre à dispo des VM aux XenClient qui s’y connectent et gérer les policy de sécurité. L’installation de l’hyperviseur est aussi simple que la GUI qui permet de créer/contrôler les VM et configurer les quelques paramètres de l’environnement (password, wifi, lan, power, etc…). Vous retrouverez la liste des features et limitations dans le pdf d’administration.

Le VT-d offre la possibilité de donner à une VM l’accès direct au GPU pour l’accélération 3D et la prise en charge de certains codec, la partie réseau offre le choix sharing/bridge des connections réseaux et le top du top c’est bien évidement la possibilité de publier une application d’une VM à l’autre grâce aux composants ICA, Receiver et Dazzle. Cette application publiée bénéficie d’une sécurité renforcé (on peut voir sur cette vidéo que même un keylogger n’en vient pas à bout).

Sur les photos ci-dessus, vous pouvez voir à un IE8 local sur une VM Win7 côte à côte avec un IE6 publié depuis une VM Win XP (on la distingue par un fin contour vert).

N’étant qu’une RC, cette version de XenClient souffre encore de nombreux bugs mais l’ensemble reste tout même très abouti et Citrix n’est qu’à seulement quelques réglages de la version finale. Par contre, il nous parait clair que si le support matériel et surtout d’OS n’évolue pas, le succès du produit sera sérieusement compromis.

On attend la riposte de VMware avec impatience…

Sur certains des plus récents serveurs IBM (HS22 par exemple), certains auront remarqué la présence d’un adapter réseau connecté en 0 Half, nommé “vusb0″ par ESX(i) :

Nous avons trouvé la nature de ce nouveau composant, intégré à l’IMM, dans un redbook et un white paper IBM :

The IMM performs the functions of the Baseboard Management Controller (BMC) of earlier blade servers, and adds the features of the Remote Supervisor Adapter  found in IBM System x servers, as well as remote control and remote media.

../..

As mentioned above, we no longer require IPMI device drivers or USB daemons to communicate with the IMM In-Band.  We can now use a LAN over USB interface.  This means that we expose an Ethernet NIC from the IMM to the operating system.

Cette interface permet donc la configuration mais aussi l’accès à l’IMM via une connexion Ethernet. Cette connexion est strictement locale mais permet de donner l’accès à une VM :

Vous voudrez donc probablement désactiver cette fonction par sécurité (via l’AMM du châssis par exemple) :