Dans cette partie de la documenration, nous allons découvrir ensemble les concepts de base du stockage iSCSI.
Nous verrons également comment l'utiliser pour fournir du stockage pour nos ESXi.
Vous avez peut être lu les documentations précédentes mais si ce n'est pas le cas, je vais faire une très brève piqure de rappel.
Voici donc un schéma classique d'infrastructure d'un ESXi qui accède à une baie de stockage iSCSi.
Si vous êtes familié avec les connexion de type Fibre Channel vous verrez que le schéma est très similaire, la différence principale résidera dans le réseau en lui même.
Pour commencer cette documentation, nous allons mettre de côté la partie ESXi et nous concentrer uniquement sur le réseau et sur la baie de stockage.
Dans le schéma, nous avons donc des switches Ethernet reliés à des "storage processor (SP)".
Les "storage processor (SP)" sont les cerveaux des opérations et assurent la connectivité entre la baie de stockage et le réseau.
Dans la baie elle-même nous avons évidemment des disques.
Il peut s'agir de disques dur ou des SSD et quel que soit le type de disque utilisé, la capacité de stockage de ces disques est regroupée sous forme d'agrégat.
Pour faire simple, ça signifie que nous prendrons l'espace de stockage disponible des différents disques pour en faire un seul de manière virtuelle.
C'est ça que l'on appel un agrégat et cela permettra entre autres de pouvoir gérer plus facilement les pannes de disques physiques ou la capacité de stockage.
Lorsque l'on aura créé un agrégat, nous pourrons ensuite le diviser en espaces de stockage plus petits appelés des LUNs ( pour Logical Unit Numbers).
Tout cela fait donc parti des composants de base d'un stockage de type iSCSI.
Pour rappel nous avons évoqué avec un peu plus de détails et d'explication cette partie dans le chapitre 2- VMFS et NFS Datastores dans vSphere 7
Nous venons de revoir quelques principes concernant le stockage iSCSI mais concrètement comment allons nous faire pour connecter nos ESXi sur une baie de stockage en iSCSI ?
Pour répondre à cette question nous aurons plusieurs possibilités.
Commençons par voir ensemble la possibilité logicielle à l'aide de l'initiateur iSCSI logiciel.
Comme toujours le point de départ est notre VM.
Son système d'exploittion va générer des commandes de stockage SCSI et les envoyer vers un contrôleur SCSI virtuel.
Pour rappel, le contrôleur SCSI virtuel est un driver mis à disposition du système d'exploitation pour qu'il puisse accéder au stockage.
Le système d'exploitation ne sait pas du tout qu'il s'agit ici d'un contrôleur virtuel et se comportera de la même manière que s'il s'agissait d'un contrôleur physique sur du matériel physique.
De cette manière le système d'exploitation sera trompé et pensera accéder à du matériel physique dédié.
Donc notre système d'exploitation va générer des commandes de stockage SCSI et les transettre au contrôleur SCSI virtuel. Ce contrôleur va prendre les commandes SCSI et les faire parvenir à un "Storage Adapter (adaptateur de stockage)".
C'est en réalité ici le travail de notre ESXi. Il va recevoir les commandes SCSI depuis le contrôleur SCSI et les transmettre au Storage Adapter approprié.
Le fonctionnement est très similaire à ce que l'on a pu voir dans les documentations précédentes à la différence qu'ici le Storage Adapter sera un "initiateur iSCSI logiciel" qui aura été configuré sur notre ESXi.
Le rôle d'un "initiateur iSCSI logiciel" est identique à celui de n'importe quel autre Storage Adapter. Il va prendre les commandes SCSI brutes qui sont émises par le système d'exploitation et de les convertir dans un format pouvant transiter sur le réseau iSCSI.
L'autre composant logiciel indispensable dont nous allons avoir besoin est un VMKernel Port sur un vSwitch de notre ESXi.
Il y aura donc un VMKernel Port qui sera lié à "l'initiateur iSCSI logiciel" pour agir comme point d'entrée vers le réseau Ethernet.
Pour finir notre vSwitch sera lié à un ou plusieurs adaptateurs physiques.
Il s'agit ici des VMNICs de notre hôte ESXi qui lui permettront d'accéder au réseau Ethenet.
Nous avons à présent le chemin complet que nos commandes de stockages vont emprunter pour atteindre la baie de stockage iSCSI.
Dans cette configuration nous allons donc avoir deux éléments clés qui sont des éléments logiciels :
Gardez en tête que ces ajouts logiciels vont entrainer une consommation supplémentaire de la part des CPU sur notre hôte ESXi.
Nous nous affranchissons de l'installation de matériel physique dédié et des coûts financiers que cela entraine mais il y a toujours un prix à payer et le prix ici est une consommation supplémentaire des CPU de l'ESXi.
Vous l'aurez probablement remarqué mais dans le schéma que j'utilise il y a un défaut majeur : il n'y a pas de redondance.
J'utilise jusqu'à présent un seul VMNIC et un seul switch physique.
Si l'un de ces composants tombe en panne, l'ensemble de mon réseau de stockage tombe en panne et ce n'est biensûr pas une bonne chose.
Il serait donc préférable d'ajuster notre réseau et ce schéma pour inclure un certain niveau de redondance sur ces éléments clés.
Ce que je pourrai faire c'est configurer plusieurs VMKernel Ports sur différents vSwitches ayant eux même différents VMNICs (ports physiques) reliés sur différents switches physiques.
Cela me permettrai de configurer du "multipathing (plusieurs chemins)" pour mon réseau de stockage et permettrai également au Storage Adapter d'effectuer "round robin" pour envoyer la moitié du trafic de stockage à chacun de ces VMKernel Ports.
Dans cette configuration, si un des VMKernel Ports tombait en panne, j'aurai toujours la possibilité d'envoyer le trafic de stockage depuis l'autre VMK.
Il en est de même avec les switches physiques et les storage processor (SP), le trafic serai acheminé via l'autre élément en attendant que la panne soit résolue et notre trafic de stockage serai assuré de toujours atteindre la baie.
Utiliser un initiateur iSCSI logiciel est une option possible pour connecter un hôte ESXi sur une baie de stockage iSCSI.
Une autre solution possible consiste à utiliser du matériel physique, que l'on appelle "Dependent Hardware iSCSI initiator".
Il s'agit ici d'un périphérique physique spécialement installé pour gérer le trafic iSCSI.
Donc cette fois-ci, mon adaptateur de stockage (Storage Adapter) sera un périphérique physique dédié dont le fonctionnement sera identique à celui vu précédemment.
Il va récupérer les commandes de stockage SCSI puis les transmettre sur le réseau Ethernet.
De ce fait nous devrons également configurer des "VMKernel Ports" avec notre initiateur iSCSI physique.
Le fonctionnement reste donc identique à celui que l'on vient de voir mise à part qu'il s'agit ici d'un périphérique physique.
A nouveau si je veux bénéficier de redondence je devrai configurer plusieurs VMKernels Ports sur plusieurs vSwitches qui seront associé à plusieurs VMNICs et réliés à plusieurs switches physiques.
Le fonctionnement est strictement identique à ce que l'on vient de voir et cela nous permettra en cas de panne de garantir une continuité de service pour notre réseau iSCSI.
Je me répète, un "Dependent Hardware iSCSI initiator" est donc un périphérique physique dédié au trafic iSCSi que l'on aura spécialement acheté puis configuré et qui dépendera toujours d'un VMKernel Port et d'un vSwitch pour fonctionner.
Nous venons de voir le fonctionnement de l'initiateur iSCSI logiciel et d'un certain type d'initiateur physique appelé "Dependent Hardware iSCSI initiator" mais il faut savoir qu'il existe une autre solution hardware.
Cette solution hardware s'appelle "Independent Hardware iSCSI initiator" et son fonctionnement est légèrement différent.
En effet un "Independent Hardware iSCSI initiator" possède ses propres ports physiques, ici on se passe totalement de la partie virtuelle et tout se fait directement sur le matériel physique.
Il n'y a plus de VMKernel Ports, plus de vSwitches, tout se passe directement sur le périphérique physique "Independent Hardware iSCSI initiator".
Lorsque le système d'exploitation de notre VM va générer des commandes SCSI, ces commandes vont directement être transmises à notre "Independent Hardware iSCSI initiator" (initiateur iSCSI indépendnat, je sais c'est pas très beau en vf...) qui possède ses propres ports physiques sur lesquels nous aurons configuré des adresses IP.
Il va gérer lui même le "Multipathing" et transmettre le trafic sur ses propres ports physiques vers des switches physiques différents à destination de la baie de stockage iSCSI.
Evidemment il s'agit ici de la solution la plus chère mais elle garantie une réduction de la consommation des ressources CPU des hôtes ESXi sur lesquels nous avons ajouté ce type de périphérique physique.
Nos ESXi n'ont plus besoin d'initiateur iSCSI logiciel ni de VMKernel Port dédié.
Tout est fait au niveau du hardware.
Nous venons de voir les trois options permettant de connecter nos ESXi à un réseau iSCSI mais une fois le réseau connecté il va nous rester encore quelques étapes importantes à réaliser.
Après avoir effectué toutes ces configurations, comment notre ESXi va t-il faire pour découvrir les LUNs disponibles sur notre baie de stockage pour les utiliser ?
Pour que l'on puisse créer des Datastores sur notre baie de stockage les ESXi vont devoir apprendre l'existence de ces LUNs.
Pour cela nous allons utiliser une méthode que l'on appelle "dynamic discovery (découverte dynamique en vf)".
La première étape consiste à configurer nos ESXi avec l'adresse IP de la baie de stockage iSCSI pour qu'ils aient une adresse IP à interroger. C'est ce que l'on appelle une "iSCSI Target".
Ensuite nous pouvons demander à nos ESXi d'effectuer une nouvelle analyse du stockage par le biais de leurs adaptateurs de stockage pour vérifier ce qui est disponible.
Dans notre cas notre adaptateur de stockage enverra une demande à "l'iSCSI Target", que l'on a configuré précédemment et qui est l'adresse IP de notre baie de stockage, de lui fournir la liste de tous les LUNs disponibles.
Pour effectuer cette demande auprès de la baie iSCSI notre adaptateur de stockage va la contacter au travers du réseau Ethernet et lui envoyer une requête de type "SendTargets request".
L'unique but de cette requête étant de récupérer la liste des LUNs disponibles.
Lorsque la baie recevra cette requête elle répondra via un "SendTargets response" pour annoncer la liste de tous les LUNs non utilisés dont elle dispose.
Tous les LUNs déjà utilisés seront automatiquement filtrés et retirés de cette liste, notre ESXi n'aura donc pas connaissances des différents LUNs déjà en service mais seulement de ceux prêt à l'utilisation.
Il nous sera également possible de configurer l'authentification "CHAP (Challenge-Handshake Authentication Protocol)" entre l'hôte ESXi et la baie de stockage iSCSI.
Cette authentification permet de garantir que l'initiateur iSCSi et l'iSCSI Target sont biens des périphériques légitimes.
iSCSI est la seule technologie de stockage permettant d'utiliser une authentification de type "CHAP" avec un ESXi.
Chapitre précédent : 4- Création d'un Datastore NFS : Démonstration - Chapitre suivant : 6- Connecter un ESXi en iSCSI