Vous reprendrez bien un peu de iSCSI avec votre vSphere?

Bonjour 

Voici un moment que je me réjouis de trouver le temps de faire un article (oui, cela fait longtemps !) sur le iSCSI. Non pas le iSCSI en général, mais le iSCSI et ses différentes formes, dans une infrastructure vSphere.

Commençons par un petit rappel. Quelles sont elles ses différentes formes de iSCSI ?

1)    Le software iSCSI. Cette solution se base entièrement sur du software, implémenté dans le VMkernel, qui va faire le travail d’initiateur (celui qui établi la connexion avec la baie de stockage) et le travail lié au protocole TCP/IP (encapsulation des commandes SCSI dans le TCP/IP, utilisé comme protocole de transport). Le software iSCSI va ajouter une carte VMHBA, qui va permettre de faire la configuration des targets, le CHAP pour la sécurité et l’assignement des ports VMkernel (j’y reviens). Le software iSCSI repose entièrement sur le réseau virtuel, où l’on doit donc créer des ports VMkernel pour que celui-ci puisse se connecter à la baie de stockage iSCSI puis dans les propriétés du software iSCSI, assigner les ports VMkernel :

Création des port VMkernel et des Switches Virtuels:

 

 

 

 

 

 

 

 

Assignement des ports VMkernel au trafic iSCSI (sur cette image les vmk1 er vmk2 appartiennent au même vSwitch. Cette configuration est acceptée, à condition de configurer les ports vmk1 et 2 pour qu’ils n’utilisent qu’une vmnic. Toutefois la best practice serait plutôt comme indiqué sur la première image):

 

 

 

 

 

 

 

 

 

  

 

 

 

 

 

2)    Le hardware iSCSI. Comme son nom l’indique, le iSCSI ne repose plus ici que sur du software, mais sur des cartes spéciales, qui prennent en charge certaines fonctionnalités. Il en existe deux types :

  1. Le Independent Hardware iSCSI. Ici les cartes sont vues comme des cartes HBA (comme des HBA Fiber Channel) et elles n’utilisent pas du tout la couche réseau de notre ESX.
  2. Le Dependent Hardware iSCSI. Ici les cartes sont vues comme des cartes HBA (VMHBA) et comme des cartes réseaux. L’astuce est de faire le lien entre la carte VMHBA et la vmnic correspondante. Pour cela, il suffit d’aller dans les propriétés de la carte VMHBA, sous l’onglet Network Configuration et la carte vmnic correspondante est listée. Ensuite il faut créer un port VMkernel sur un vSwitch dédié, avec comme seul uplink la vmnic identifiée, selon l’image précédente. 

Les cartes iSCSI, qu’elles soient Independent ou Dependent, présentent un avantage considérable, c’est celui de prendre en charge la lourde tâche (lourde pour le CPU) du iSCSI. Les deux rôles que ces cartent prennent en charge, sont :

  1. iSCSI initiator : fonctionnalité qui permet d’établir la connexion à la baie iSCSI et de présenter les volumes.
  2. TCP/IP Offload Engine (TOE) : fonctionnalité qui permet de soulager l’ESX de tout le traitement lié au protocole TCP/IP et l’encapsulation des commandes SCSI dans le TCP/IP.

Pour en finir avec l’énumération de termes et de fonctionnalités, en voici encore deux qu’il me faut expliquer :

  1. Jumbo Frames : comme on le sait, le protocole TCP/IP est très… Gentleman : « pouvons-nous parler ? » ; « oui nous le pouvons » ; « puis-je vous envoyer le premier paquet ? » ; « oui vous pouvez » ; « le voici, l’avez-vous bien reçu ? » ; « oui, merci » ; « voici le deuxième, l’avez-vous bien reçu ? » etc. Les paquets, par défaut ont une taille maximum de 1500 bytes. C’est à dire que tout les 1500 bytes envoyés, on s’arrête pour se faire des politesses. Le Jumbo Frames permet d’envoyer des paquets beaucoup plus gros, jusqu’à 9000 bytes à chaque fois. Donc les effets sont : moins de données superflues transmises ; moins de traitement CPU pour couper les données en paquets. Le protocole est donc beaucoup plus rapide.
  2. Delayed ack : permet de regrouper plusieurs acknowledgments TCP/IP (confirmation de réception des paquets) dans un seul paquet, afin d’optimiser le protocole. Cette fonctionnalité est uniquement recommandée avec des baies de stockage EMC Clariion et les VNX.

Voilà, maintenant que tout cela est posé, qu’en faire ? Ce qui nous intéresse évidemment sont les performances, mais là, cela devient très difficile de comparer. Le graphique suivant est issu d’une étude comparative de VMware en version 4.0. Cela donne toutefois une bonne idée de la différence de performance entre le hardware et le software iSCSI (attention, ce graphique montre que le FC est énormément plus performant, mais les tests comparent du FC 4Gb avec du iSCSI 1Gb sans Jumbo Frames).

 

 

 

 

 

 

 

 

 

 

Le Jumbo Frames quand à lui n’a semble t-il pas fait l’objet d’une comparaison de la part de VMware, tout du moins je n’en ai pas trouvé. Ce que je puis dire suite à beaucoup de recherches et en ayant vu bon nombre de comparaisons faites par des particuliers, c’est qu’en moyenne, on peut espérer une amélioration des performances de 10% ou 15% dans le meilleur des cas.

Pour supporter le Jumbo Frames, il faut que le réseau de bout en bout le supporte et soit configuré avec un MTU (Maximum Transfert Unit) à 9000 (ou plus). Par contre, les cartes Broadcom Dependent Hardware iSCSI ne supportent pas le Jumbo Frames.

En conclusion, je dirai que le règne du FC touche peut-être à sa fin, que le Independent Hardware iSCSI (qu’il soit dit au passage que ces cartes coûtent cher) n’a peut-être plus lieu d’être et que le Dependent Hardware iSCSI à de beaux jours devant lui. Pourquoi ? En premier lieu car la plupart des cartes mère récentes présentent des ports Ethernet on-board qui supportent le Dependent Hardware iSCSI (attention toutefois aux Broadcom qui ne supportent pas le Jumbo Frames) ; car le 10Gb Ethernet est comparable voir plus rapide que du FC 8Gb ; car le coût d’acquisition d’une solution iSCSI est, rappelons-le, généralement plus faible que pour une solution FC. Egalement car dans vSphere 5, il est possible de multipather et d’activer même le Round Robin sur des Datastores en Software ou hardware iSCSI.

Je finirai en disant que j’ai eu à quelques reprises récemment l’occasion de savourer des projets avec du Cisco UCS tout en 10Gb, du EMC VNX5300, le tout accompagné d’une infrastructure VMware View 5 sur lit de vSphere 5, et là, une voix dans ma tête m’a dit « et avec ça, vous reprendrez bien un peu de iSCSI ? ».

Merci de votre intérêt et à bientôt.

Stéphane.

A propos de 

http://ch.linkedin.com/in/sgrimbuhler

Stéphane GRIMBUHLER 

Virtualization & Storage Architect (VCP / VCAP-DCA)
VMware Instructor (VCI)
vExpert 2012 to 2014

twitter : @sgrimbuhler
sgrimbuhler@virtualgeek.ch

  1. Très intéressant, merci

  2. Hello.

    Merci pour cet article intéressant.

    Broadcom supporte les Jumbo Frames, toutefois, le pilote installé sur ESXi 4 ne les supporte pas en HW iSCSI. Il est tout à fait possible de les activer en SW iSCSI.

    C’était aussi le cas à la sortie de vSphere 5, toutefois, depuis le 13 mars de cette année, Broadcom a édité un nouveau pilote permettant l’utilisation de Jumbo Frames en mode HW iSCSI:

    Version 2.72.10 (Mar. 13, 2012)
    ==========================
    Enhancements
    ————
    1. Change: Default MAX MTU support to 9000 for iSCSi offload for ESX5.0. (Approved by VMware)

  3. Stéphane Grimbuhler

    Bonjour Akim,

    Merci pour ces précisions et cette actualisation.
    Il est en effet important de relever que maintenant, le Jumbo Frame (MTU9000) est supporté avec toute forme de iSCSI et tout vendeur.

    Du iSCSI sans Jumbo Frame, c’est un peu comme une Ferrari avec un moteur de twingo non?!

  4. Je ne serais pas si catégorique. Les Jumbo Frames apportent certes un léger gain de performance (autour de 15% sauf erreur), mais surtout, limite l’overhead dû aux headers de trames plus petites.

    Dans un environnement intensif, ça a beaucoup de sens, mais dans un environnement léger, comme le stockage de fichiers, la différence n’est pas vraiment perceptible par les utilisateurs.

    De toute façon, nous savons tous que l’IP n’est pas un protocole qui est fait pour le transport de bloc. Mais on va pas refaire le monde 🙂 Ca sert très bien dans les PMEs vu le coût bas par rapport à un environnement FC.

    Mais probablement qu’avec l’avènement de vSphere 5.1 et les VSA incluses dans Essential Plus et les Acceleration Kits, l’iSCSI va avoir moins de succès.

    Je vois plutôt l’avenir en NAS et en SAN FC.

    A suivre…

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>