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

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

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

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

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

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

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

]]> http://www.hypervisor.fr/?feed=rss2&p=5492 2 http://www.hypervisor.fr/?p=5318 http://www.hypervisor.fr/?p=5318#comments Mon, 15 Dec 2014 09:33:44 +0000 NiTRo http://www.hypervisor.fr/?p=5318 MAJ 11/05/2017 : Et voila ce que ça donne en production :

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.

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”

Nous profitons de la récente disponibilité de NexentaStor 3.1.4 (toujours pas disponible en version CE) pour vous faire partager le modus operandi de l’installation de SABnzbd sur NexentaStor 3.1 qui nous a été transmis par Brenn Oosterbaan et que nous n’avons que très peu modifié pour le rendre utilisable par (à peu près) tous. Thanks Breen!

Breen nous a aussi fourni le fichier xml permettant de configurer SABnzbd en tant que service mais nous avons été contraint de forcer l’adresse et le port d’écoute dans la commande de démarrage (0.0.0.0:8080) ce qui rend toute modification (lié au host:port d’écoute) dans l’interface de configuration de SABnzbd non persistante. Si vous avez l’intention de changer le port, faites le dans le fichier sabnzbd.xml fourni et relancer la commande d’import.

Une fois l’installation terminée et le service démarré, vous devriez observer quelque chose de similaire à cela dans le log du service :

_yenc module... found!
par2 binary... found (/usr/local/bin/par2)
unrar binary... found (/usr/bin/unrar)
unzip binary... found (/usr/bin/unzip)
nice binary... found (/usr/bin/nice)
ionice binary... NOT found!
pyOpenSSL... found (True)
Starting web-interface on 0.0.0.0:8080
ENGINE Bus STARTING
ENGINE Started monitor thread '_TimeoutMonitor'.
ENGINE Serving on 0.0.0.0:8080
ENGINE Bus STARTED
Starting SABnzbd.py-0.7.11
Dirscanner starting up
URLGrabber starting up

Comme toujours il faudra passer par le fameux mode “expert” pour accéder au shell. Et gare à la Hadopi !

install.txt

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

Tous ceux qui ont eu à affronter un manque d’espace critique sur un zpool se sont au moins une fois posé la question suivante : Pourquoi ZFS n’est il pas capable de supprimer automatiquement les plus anciens snapshot pour libérer de l’espace en cas de besoin ?

La réponse est évidement parce que ce n’est pas (encore) intégré à ZFS mais peut être que le futur principe de “feature flags” (qui remplacera la fameuse “version” de ZFS) facilitera la naissance de cette fonctionnalité tant espérée. En attendant, il y a toujours la bonne vielle crontab toujours très pratique et si on pimente à la sauce oneliner, ça donne quelque chose d’un peu trash mais fonctionnel :

for zpool in `zpool list -H -o name,capacity | sed "s/%//g" | awk '{ if ( $2 > 80 ) { print $1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

Ce oneliner détruira récursivement 25% des plus vieux snapshots (+1 pour éviter les cas ou 25% feraient moins d’1 snapshot) d’un zpool si le remplissage dépasse les 80%.

Voici une démo de ce script sur un zpool soumis à remplissage perpétuel (dd en boucle + snapshot toutes les minutes) :

Observations du graphique : jusqu’à 10h nous avons programmé le script toutes les minutes, puis toutes les 5min jusqu’à 15h30, puis nous l’avons désactivé et le zpool sature presque immédiatement après.

Voici l’extrait de la crontab de notre nexenta de test :

* * * * * for zpool in `zpool list -H -o name,capacity | sed "s/\%//g" | awk '{ if ( \$2 > 80 ) { print \$1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

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=4330 http://www.hypervisor.fr/?p=4330#comments Thu, 25 Oct 2012 22:34:04 +0000 NiTRo http://www.hypervisor.fr/?p=4330 C’est à l’occasion du VMworld 2012 EMEA que nous avons pu en savoir un peu plus sur la roadmap de l’appliance ZFS et sur la fameuse version 3.1.3.5 (oui c’est n’importe quoi mais il paraîtrai qu’il fallait rapidement sortir une version et que la 3.1.4 n’était pas prête…) qui a fait son apparition cette semaine.

A la lecture du release notes, on remarque tout de suite qu’il est globalement question de nouveaux drivers dont vmxnet3 (très attendu) et pvscsi, derniers maillons manquant à Nexenta pour être une pure appliance de stockage VMware.

Pour ceux qui passeraient par le processus d’upgrade, il est fort probable que vous ayez à lancer les commandes suivantes (suivit d’un reboot) pour installer les 2 packages contenant les pilotes :

apt-get install nexenta-vmxnet3
apt-get install nexenta-pvscsi

Pendant notre échange avec les gens de chez Nexenta (qui nous ont confirmé la sortie de Nexenta 4.0 basé sur illumos d’ici la fin de l’année), nous avons pu apercevoir la nouvelle version de NexentaVSA for View (une appliance dédié au VDI)  mais surtout l’intégration d’une version++ d’Aura, l’interface de monitoring révolutionnaire développé à l’arrache pendant le VMworld 2011 :

D’après le sales manager présent lors de notre discussion, l’intégration d’Aura serait prévue dans la version 4.0 de Nexenta et le support de VAAI NFS sera pour la suivante mais surtout inclut dans la version Community Edition comme pour le VAAI en mode block depuis la 3.1.3. D’ici la, nous aurons tout de même droit à la version 3.1.4

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=4010 http://www.hypervisor.fr/?p=4010#comments Thu, 02 Aug 2012 17:36:40 +0000 NiTRo http://www.hypervisor.fr/?p=4010 Nous avons enfin terminé le fignolage des tous les graphs cacti dont nous nous servons pour la supervision de nos appliances Nexenta, il était donc temps d’en faire profiter la communauté !

Tout comme pour notre post sur le monitoring smart, le tout se fait uniquement dans le fichier snmpd.conf sans script annexe. Pour rappel, l’édition de la config snmp sous nexenta se fait via la nmc avec la commande suivante :

setup network service snmp-agent edit-settings snmpd.conf

Pour chaque graphique, il faudra ajouter une ou plusieurs lignes à la config snmp et importer le template dans cacti.

extend .1.3.6.1.4.1.2021.85 arc_meta_max /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_max|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_used /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_used|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_size /bin/bash -c "echo ::arc | mdb -k| grep -w size|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_limit /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_limit|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_c_max /bin/bash -c "echo ::arc | mdb -k| grep c_max|tr -cd '[:digit:]'"

Graph template à importer dans cacti : ZFS – ARC Usage

extend .1.3.6.1.4.1.2021.89 arc_hits /bin/bash -c "kstat -p ::arcstats:hits| cut -s -f 2"
extend .1.3.6.1.4.1.2021.89 arc_misses /bin/bash -c "kstat -p ::arcstats:misses| cut -s -f 2"

Graph template à importer dans cacti : ZFS – ARC Stats

extend .1.3.6.1.4.1.2021.89 arc_l2_hits /bin/bash -c "kstat -p ::arcstats:l2_hits| cut -s -f 2"
extend .1.3.6.1.4.1.2021.89 arc_l2_misses /bin/bash -c "kstat -p ::arcstats:l2_misses| cut -s -f 2"

Graph template à importer dans cacti : ZFS – L2ARC Stats

extend .1.3.6.1.4.1.2021.90 vopstats_zfs_nread /bin/bash -c "kstat -p ::vopstats_zfs:nread | cut -s -f 2"
extend .1.3.6.1.4.1.2021.90 vopstats_zfs_nwrite /bin/bash -c "kstat -p ::vopstats_zfs:nwrite | cut -s -f 2

Graph template à importer dans cacti : ZFS – VFS IOPS

extend .1.3.6.1.4.1.2021.90 vopstats_zfs_read_bytes /bin/bash -c "kstat -p ::vopstats_zfs:read_bytes | cut -s -f 2"
extend .1.3.6.1.4.1.2021.90 vopstats_zfs_write_bytes /bin/bash -c "kstat -p ::vopstats_zfs:write_bytes | cut -s -f 2"

Graph template à importer dans cacti : ZFS – VFS Throughput

extend .1.3.6.1.4.1.2021.88 zpool_name /bin/bash -c "zpool list -H -o name"
extend .1.3.6.1.4.1.2021.88 zpool_snap /bin/bash -c "zpool list -Ho name|for zpool in `xargs`;do zfs get -rHp -o value usedbysnapshots $zpool|awk -F: '{sum+=$1} END{print sum}';done"
extend .1.3.6.1.4.1.2021.88 zpool_used /bin/bash -c "zpool list -Ho name|xargs zfs get -Hp -o value used"
extend .1.3.6.1.4.1.2021.88 zpool_data_used /bin/bash -c "zpool list -Ho name|for zpool in `xargs`;do snap=`zfs get -rHp -o value usedbysnapshots $zpool|awk -F: '{sum+=$1} END{print sum}'`;pool=`zfs get -Hp -o value used $zpool`; echo $pool $snap|awk '{print (\$1-\$2);}';done"
extend .1.3.6.1.4.1.2021.88 zpool_available /bin/bash -c "zpool list -Ho name|xargs zfs get -Hp -o value available"
extend .1.3.6.1.4.1.2021.88 zpool_capacity /bin/bash -c "zpool list -H -o capacity|cut -d % -f 1"

Script à copier dans le répertoire ”/resource/snmp_queries/” : ZFS – zpool usage
Graph template à importer dans cacti : ZFS – zpool usage
Ce dernier graph est similaire à celui que nous avions posté il y a quelques temps mais permet de distinguer la consommation des data de celle des snapshot.

extend .1.3.6.1.4.1.2021.84 busy /bin/bash -c "iostat -xrn 1 3|grep -E 'c2t'|grep -vE c2t15d0|tail -\$((\$(paste -d= <(iostat -x | tail -n +3 | awk '{print \$1}') <(iostat -nx | tail -n +3 | awk '{print \"/dev/dsk/\"\$11}')|grep -E 'c2t'|grep -vE c2t15d0|wc -l)*2))| awk -F',' 'BEGIN { n=0; sum=0; } { n++; sum += \$(NF-1); } END { printf (\"%.2f\",sum / n); }'|awk '{ printf (\"%d\", (\$1 > 100) ? 0 : \$1); }'"

Graph template à importer dans cacti : ZFS – disk busy
Ce graph est expérimentale et spécifique dans la mesure où il représente la charge estimée des disk filtrés par les differents grep de la commande, à ajuster en fonction de la cible. Le scénario cible idéal est un système avec un seul zpool (mis à part celui du système). Dans notre exemple, nous avons limité à tous les disques dont les noms commencent par “c2t” et exclu “c2t15d0″ (hot spare dans ce cas).

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…

Keep pool space under 80% utilization to maintain pool performance.

[...]

If the primary workload is immutable files (write once, never remove), then you can keep a pool in the 95-96% utilization range.

Le 95-96% correspond au changement de block allocation contrôlé par le paramètre metaslab_df_alloc_threshold :

The minimum free space, in percent, which must be available in a space map to continue allocations in a first-fit fashion. Once the space_map’s free space drops below this level we dynamically switch to using best-fit allocations.

Vous l’aurez compris, le monitoring des zpool est primordiale. Sous Nexenta ce n’est pas chose facile car seuls les point de montage sont visibles par défaut en snmp, mais nous avons une solution simple n’impliquant que peux de modifications.

• ajouter les lignes suivantes dans votre conf snmp :

extend .1.3.6.1.4.1.2021.87 zpool_name /bin/bash -c “zpool list -H -o name”
extend .1.3.6.1.4.1.2021.87 zpool_capacity /bin/bash -c “zpool list -H -o capacity”

• copier le fichier zpool_capacity.xml dans le répertoire /resource/snmp_queries de votre cacti
• importer les templates cacti_data_query_zfs_-_zpool_capacity.xml et cacti_graph_template_zfs_-_zpool_capacity.xml dans l’interface web cacti
• choisissez les zpool à monitorer sur votre/vos nexenta (y compris le syspool)

• en option, créez un Threshold Template pour recevoir une alerte en cas de dépassement de 80%

zpool capacity

MAJ 30/10/2012 : Mise à jours des scripts pour n’exclure que les vm “invalid” ou “orphaned”.

MAJ 06/07/2012 : Mise à jour des scripts pour exclure “*/hostCache/*” pour ne pas remonter les fichiers vswp de la fonction Host Cache d’ESXi 5.

MAJ 05/07/2012 : Mise à jour des scripts pour intégrer les fichiers vswp.xxxxxx, merci à Larus Hjartarson pour l’idée.

MAJ 21/03/2012 : Mise à jour des scripts pour exclure “var/tmp/cache” dans le cas d’une redirection de la partition scratch sur un datastore.

MAJ 06/03/2012 : Mise à jour des scripts pour le support des multi-datacenter/multi-vcenter, des snapshot NetApp et des fichiers zdump qui trainent.

MAJ 28/02/2012 : Mise à jour des scripts suite à une erreur dans le “SideIndicator”

MAJ 24/02/2012 : Et pour ceux qui ont *VRAIMENT* confiance, voici le script pour supprimer les fichiers vswp orphelins (et si vraiment vous en avez, vous pouvez changer le filtrage au niveau du |?{$_.lostfile -match “vswp”}) :

foreach ($lost in (compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|?{$_.lostfile -match "vswp"})){(get-view (Get-View ServiceInstance|select -first 1).content.filemanager|select -first 1).DeleteDatastoreFile($lost.LostFile,(Get-View -ViewType datacenter|?{$_.Datastore -match (get-datastore $lost.LostFile.split("[]")[1]|get-view).moref}|select -first 1).moref)}

MAJ 24/02/2012 : Mise à jour du script pour afficher la taille en MegaBytes et la date de modification des fichiers.

Très fortement inspiré du célèbre Raiders of the Lost VMX (mais aussi du post Orphaned files and folders – Spring cleaning) de LucD, nous avons enfin fini de finioler un oneliner PowerCLI qui va vous lister les fichiers .xml, .vmsn, .vmsd, .vswp, .vmx, .vmdk, .vmss, .nvram et .vmxf qui traînent sur vos datastores et qui ne sont pas rattachés à une quelconque vm du vcenter depuis lequel vous avez exécuté le script.

compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|ft -autosize

Les snapshots ZFS (.zfs/snapshot), les fichiers -ctk.vmdk (fichiers CBT) et les vmdk des COS d’ESX classic (esxconsole-) sont filtrés, n’hésitez pas à nous remonter d’autres faux positifs que vous pourriez rencontrer. Prochaine étape : ménage automatique…

Disons que vous souhaitez limiter la possibilité de faire un snapshot sur vos vm uniquement s’il y a suffisamment d’espace sur les datastore, vous utiliseriez notre beau petit one-liner fait main :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.minFreeSpace"; Value="$($($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum)"}))}))}

Ce script fixe le snapshot.minFreeSpace à la somme de la taille des vmdk (taille max d’un snapshot) et se limite aux vm dont les vmdk résident sur un seul et unique datastore.

Mais avant de passer ce script, peut être voudriez vous vérifier que vous n’avez pas des vm déjà dans cette situation ? Cet autre petit one-liner vous donnera la liste de chaque vm dont la taille totale est supérieure à l’espace libre du datastore où elle réside :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum -gt ((get-view -viewtype datastore -property name,summary -filter @{"name" = ($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique)}).Summary.FreeSpace)}|select name

Voila maintenant 1 mois que nous participons à des tests avec les gens de chez nexenta concernant un problème lié à la routine Atomic Test & Set (ATS) de VAAI. Le symptôme est assez radical : lors de certaines opérations courantes (svmotion par ex.), la LUN reste lockée donc inaccessible jusqu’à ce qu’elle soit “re-maskée” ou que le serveur nexenta soit rebooté.

Jusqu’à ce que le bug soit corrigé, l’option la plus rapide est de désactiver l’ATS. L’idéal c’est un petit one-liner powershell qui le fait sur tous vos ESX :

Get-VMHost|Set-VMHostAdvancedConfiguration -name VMFS3.HardwareAcceleratedLocking -Value 0

Attention aux LUN en VMFS5 natives qui ont été créées avec VAAI actif car elles sont tagguées “ATS-only”, ce qui veux dire qu’il n’est pas possible de les réserver en SCSI-2 classique. Pour désactiver ce mode, il faut utiliser la commande vmkfstools avec le paramètre ”configATSOnly“.

Nous tenons à préciser que ce problème n’est pas lié à celui du UNMAP.

Tout à commencé à partir d’un post qui traite de la customization du snmpd.conf en vue de faire un joli graph de l’ARC de ZFS avec cacti et d’un autre au sujet de smartmontools sous Solaris. En mixant les 2, nous sommes arrivé à un moyen simple de remonter la moyenne des températures des disques d’un Nexenta dans cacti via SNMP.

• Installez smartmontools en mode expert : “apt-get install smartmontools”
• Ajoutez la ligne suivante dans la configuration snmp de Nexenta (“setup network service snmp-agent edit-settings snmpd.conf” dans la NMC) :

extend .1.3.6.1.4.1.2021.87 smart_temp /bin/bash -c "find /dev/rdsk/ -name \"*p0\" -exec /usr/sbin/smartctl -a -d scsi {} \\;|grep -E \"Temperature:.*C\"| awk 'BEGIN { n=0; sum=0; } { n++; sum += \$(NF-1); } END { printf (\"%.2f\",sum / n); }'"

• Importez notre template dans cacti et créez le graphique sur votre Nexenta

]]> http://www.hypervisor.fr/?feed=rss2&p=3335 2 http://www.hypervisor.fr/?p=3239 http://www.hypervisor.fr/?p=3239#comments Sat, 20 Aug 2011 00:30:47 +0000 NiTRo http://www.hypervisor.fr/?p=3239 Après un faux départ, NexentaStor 3.1 est enfin (re)disponible ! En plus des quelques nouvelles features et corrections de bug, la grosse bonne nouvelle c’est le support de VAAI pour ESXi 5+ (contrairement à ce qui avait été annoncé) y compris pour la version Community Edition. Ce qui en fait la toute première et seule solution VAAI gratuite, pour le mode block uniquement. Voici la liste des routines VAAI supportées :

• SCSI Write Same (zeroing)
• SCSI ATS (lock only the specific region on the LUN)
• SCSI Block Copy (instruct the array to perform a block copy)
• SCSI Unmap (return freed blocks in a zvol)

Je vous laisse imaginer l’intérêt d’une solution gratuite (jusqu’à 18To raw max pour la CE) supportant VAAI et reposant sur ZFS (ARC, L2ARC, in-line deduplication, in-line compression, snapshots and copy-on-write clones, RAID-Z, native NFSv4 ACLs, continuous integrity checking and automatic repair, …) face à toutes les appliances payantes du marché.

Et juste pour le plaisir des yeux :

Et justement, en ce moment nous sommes en pleine découverte de la configuration FC sur Nexenta (plus particulièrement sur la configuration du mode target) qui est un Unified Storage System  tout à fait capable de présenter la même LUN (un zvol pour être précis) via FC et iSCSI. Voici donc une petite démo en 4 étapes :

1. Coupure de vmhba1 (prefered path) > Bascule sur vmhba2
2. Coupure de vmhba2 > Bascule sur vmhba32 (iSCSI)
3. Restauration de vmhba2 > Aucun effet
4. Restauration de vmhba1 > bascule sur vmhba1

Tout d’abord, vous remarquerez que ça bombarde à 10k+ IOPS (alors que le serveur Nexenta est une petite VM), remettez vous, c’est l’effet ZFS

Plus sérieusement, on remarque que le failover se fait dans le sens croissant des vmhba, ce qui règle le problème du choix d’iSCSI qu’en dernier recours étant donné que l’initiateur est toujours à 32 ou plus. De plus le failover se fait dans un délais raisonnable de 10 secondes (contre 30sec pour MPIO de Windows 2008 R2 et donc d’Hyper-V) mais cette solution pose un réel problème si le chemin préféré venait a être le seul à ne PAS être restauré car le chemin iSCSI est considéré comme les autres donc restera “valable” (cf FC to iSCSI failover : MRU ranking). Mais nous pensons que cela reste néanmoins une solution à connaitre et peut être à envisager pour les plus parano du HA.

Et le plus drôle dans l’histoire c’est que vous n’avez rien à configurer !

PS: Ça doit être possible à faire avec les autres hyperviseurs évidement…