Parcours des I/O d’une VM

Découvrons les différentes couches que traversent les I/O lorsqu’une VM souhaite lire ou écrire sur son disque virtuel (VMDK).


  1. Lorsqu’une application ou système d’exploitation d’une VM souhaite effectuer des opérations de lecture ou d’écriture sur son disque virtuel, ils envoient des commandes SCSI vers le VMDK.
  2. Un driver installé dans le système d’exploitation invité de la VM va permettre au contrôleur SCSI virtuel de transférer les données au VMkernel. La VM va utiliser l’émulation SCSI via son contrôleur SCSI virtuel pour rediriger les demandes I/O clientes vers le VMkernel de l’ESXi
  3. Le Vmkernel va localiser le fichier correspondant au disque de la VM sur le volume VMFS. Il va mapper les requêtes des blocs du disque virtuel (VMDK) vers les disques physiques du volume VMFS.
  4. En fonction du type de disque virtuel, les demandes I/O peuvent traverser différentes couches qui gèrent la transcription du VMDK (Snapshot, Vmfs, Nfs, Rdm, etc …)
  5. Les demandes d’I/O sont prises en charge par le scheduler d’I/O au sein du VMkernel. C’est lui qui gère les demandes en I/O de toutes les VMs depuis et vers les périphériques physiques. Le scheduler d’I/O va transmettre les demandes à l’architecture PSA.
  6. L’hyperviseur ESXi, utilise un ensemble d’API de stockage, appelé également PSA (Pluggable Storage Architecture). La PSA permet de gérer les multiples chemins d’accès, l’équilibrage de charge et les mécanismes de bascule des multiples périphériques de stockage présentés aux ESXi. La PSA est une structure ouverte permettant aux développeurs de logiciels tiers de concevoir leurs propres techniques d’équilibrage et/ou mécanismes de basculement pour des baies de stockage particulières. Cela leurs permet d’insérer leur code directement sur le chemin des I/O.
L’architecture PSA fait partie du VMkernel. Elle se compose d’un module « NMP – Native MultiPathing Plugin » et de un ou plusieurs modules « MPP – MultiPathing Plugin ».

  • Le NMP est un module extensible qui regroupe deux types de sous plug-ins: Storage Array Type Plug-Ins (SATP) et Path Selection Plug-Ins (PSP). SATP et PSP peuvent être intégrés et fournis par VMware ou par un tiers.
  • Les MPP sont des modules fournis par des tiers et exécuter en complément ou en remplacement du NMP. Ils intègrent certaines fonctionnalités de gestion optimisée pour des baies de stockage. Lorsqu’un MPP est activé pour un type de stockage, il remplace le comportement du NMP et prend le contrôle total des chemins et des opérations d’équilibrage de charge vers ce périphérique de stockage.

Lors de l’utilisation de plusieurs stockages différents, il y a de grande chance d’utiliser un module MPP et NMP en parallèle. La PSA va gérer la coordination entre les modules, le chargement et déchargement des modules, le routage des I/O vers le bon module, etc …

Le NMP prend en charge toutes les baies de stockage répertoriées dans la liste de compatibilité matérielle (HCL) de stockage de VMware et fournit des algorithmes de sélection de chemin par défaut reposant sur le type de baie. Le NMP associe une série de chemins physiques à un périphérique de stockage spécifique ou à une LUN.

Comme nous l’avons évoqué plus haut, le NMP est composé de sous plugins SATP et PSP. Ces sous plugins sont en général intégrés et fournis par VMware mais aussi par des éditeurs/constructeurs tiers.

Quel est le rôle des sous plugins du NMP :

Les plugins SATP :

Un SATP est utilisé pour chaque type de baie pris en charge par VMware. Il existe des SATP génériques par défaut qui prennent en charge des baies de stockage (de type active/active, active/passive et ALUA) ainsi qu’un SATP local pour les périphériques locaux. Chaque SATP contient des caractéristiques propres à une classe de baie de stockage et effectue des opérations spécifiques à cette baie.

Dès que le NMP détermine le SATP à utiliser pour un périphérique de stockage et qu’il associe le SATP aux chemins physiques de ce périphérique, le SATP met en œuvre les tâches suivantes :

  • Une surveillance du bon fonctionnement de chaque chemin physique.
  • Des rapports sur les modifications d’état de chaque chemin physique.
  • Le déclenchement d’actions spécifiques à la baie comme le basculement de contrôleur (exemple : activer les chemins passifs d’une baie active/passive)
VMW_SATP_LOCAL  Support des disques locaux.
VMW_SATP_DEFAULT_AA SATP générique pour les baies active/active
VMW_SATP_DEFAULT_AP SATP générique pour les baies active/passive
VMW_SATP_ALUA SATP générique pour les baies Asymmetric Logical Unit Access (ALUA)
VMW_SATP_MSA Support des baies HP MSA
VMW_SATP_SVC Support des baies IBM SVC (SVC, V7000, Actifio)
VMW_SATP_EQL Support des baies Dell Equalogic
VMW_SATP_INV Support des baies EMC Invista & Vplex
VMW_SATP_EVA Support des baies HP EVA
VMW_SATP_ALUA_CX Support des baies EMC CX utilisant ALUA
VMW_SATP_SYMM Support des baies EMC Symmetrix
VMW_SATP_CX Support des baies EMC CX
VMW_SATP_LSI Support des baies basées sur LSI et autres EOM (Dell, HDS, IBM, Oracle, SGI)

Les plugins PSP :

Un PSP par défaut est affecté par le NMP pour chaque périphérique logique (LUN / Datastore) selon le SATP associé aux chemins physiques de ce périphérique. Le SATP traite la bascule des liens, le PSP, lui, détermine les chemins physiques à utiliser pour émettre les demandes d’I/O aux périphériques de stockage. Le PSP est responsable du choix des liens à utiliser pour répartir la charge I/O.

PSP Policy

Description

VMW_PSP_MRU Le VMkernel sélectionne le chemin utilisé le plus récemment. Si le chemin devient indisponible, le VMkernel sélectionne un autre chemin d’accès. Le VMkernel ne revient pas sur le chemin d’accès d’origine même quand ce chemin est de nouveau disponible.
VMW_PSP_FIXED Le VMkernel utilise un chemin favori lorsqu’il a été configuré. Sinon, il utilise le 1er chemin fonctionnel détecté au moment du démarrage de l’hyperviseur ESXi. Il est possible définir un chemin favori en le configurant manuellement.
Si le VMkernel utilise un chemin privilégié par défaut et que l’état du chemin devient inaccessible, un nouveau chemin est sélectionné. Par contre, si le chemin privilégié est explicitement configuré, il le restera même si il devient inaccessible.
VMW_PSP_RR Le VMkernel utilise un algorithme de sélection de chemin automatique en effectuant un changement circulaire sur tous les chemins actifs pour la connexion à des baies actives/passives ou sur tous les chemins disponibles lors de la connexion à des baies actives/actives.
C’est la valeur par défaut pour plusieurs baies et peut être utilisée avec les baies actives-actives et actives-passives pour mettre en œuvre de l’équilibrage de charge.

Pourquoi des plugins tiers ?

  • Les SATP tiers:

Ils sont coordonnés par le NMP et dans la plupart des cas, ils sont développés par les fabricants de stockage. Les SATP tiers permettent d’optimiser les échanges avec certaines baies.

  • Les PSP tiers :

Ils sont coordonnés par le NMP et dans la plupart des cas développés par des éditeurs de logiciels tiers. Ils intègrent de nouveaux algorithmes d’équilibrage de charge.

  • Les MPP tiers :

Ils s’exécutent en parallèle du NMP VMware. Ils peuvent prendre totalement en charge le rôle du NMP. Ils apportent de nouvelles méthodes de tolérance de panne.

Interactions dans l’architecture PSA :


Lors d’une demande d’I/O par une VM à un périphérique de stockage géré par le NMP,

  1. Le NMP appelle le PSP assigné à ce périphérique de stockage logique.
  2. Le PSP sélectionne le chemin physique approprié sur lequel il peut envoyer l’I/O
  3. Le NMP envoi la requête I/O sur le chemin sélectionné par le PSP
  4. Si l’opération I/O échoue, le NMP signale l’échec et appel le SATP approprié.
  5. Le SATP interprète l’erreur I/O et active les chemins inactifs si nécessaire.
  6. Le PSP est de nouveau appelé et sélectionne un nouveau chemin pour l’envoi de l’I/O.
  7. Si l’opération I/O réussie, le NMP signale la réussite et l’opération est terminée.

Lister les MultiPathing Plugins du VMkernel :


Lister les sous-plugins SATP et PSP disponibles dans le VMkernel :

Pour lister les SATP et leurs PSP associés par défaut:

Pour lister les PSP disponibles:


Pour attribuer un PSP par défaut à un SATP et éviter de le refaire à chaque présentation de nouvelle LUN :

esxcli storage nmp satp set –satp <SATP Name> –default-psp <PSP Name>

Comment sont découverts les chemins physiques vers les périphériques de stockage disponibles ?

Au démarrage d’un hôte ESXi, un ‘rescan’ des adaptateurs de stockage est effectué.

Ce ‘rescan’ permet la découverte des chemins physiques disponibles vers les périphériques de stockage. Le Vmkernel va se baser sur un ensemble de règles (claimrules) pour déterminer le plugin NMP ou MPP qui doit réclamer les chemins vers le périphérique de stockage et devenir le responsable de la gestion du périphérique.

Par défaut, l’ESXi effectue une vérification périodique des chemins (toutes les 5 minutes) forçant le module approprié à réclamer tous les chemins non affectés.

Les règles de réclamation (claimrules) sont numérotées. Pour chaque chemin physique, l’hôte parcourt les règles de ‘reclaiming’ en commençant par celle ayant l’ID le plus petit. Les attributs du chemin physique sont comparés aux informations du chemin définit dans la règle.

Si l’ESXi trouve une correspondance, il assigne le MPP spécifié dans la ‘claimrule’ pour l’administration du chemin physique.

Ce processus continue jusqu’à ce que tous les chemins physiques soient revendiqués soit par des plugins MPP, soit par le plugin natif (NMP).

Ces règles déterminent les Storage Array Type Plug-In (SATP) qui doivent être utilisés pour gérer les chemins pour un type de baie et le Path Selection Plug-In (PSP) qui doit être utilisé pour chaque périphérique de stockage.

Comment ajouter ou supprimer des règles de revendication de chemin (Claimrules) dans le VMkernel ?

  • Liste des règles d’un ESXi

esxcli storage core claimrule list

  • Création d’une nouvelle règle

-r | –rule=<long> : Indique le nombre (ID) de la règle (0-100 réservé à VMware / 101–65435 utilisé pour un usage général et les plugins tiers / 65436–65535 utilisé pour un usage interne VMware)

-V | –vendor=<str> : Indique le fournisseur des chemins SCSI.

-M | –model=<str> : Indique le modèle des chemins SCSI à utiliser.

-P | –plugin=<str> : Indique le plugin PSA à utiliser pour l’opération. (Requis NMP ou MASK_PATH)

-t | –type=<str> : Indique le type d’information à rechercher pour la prise en compte de la règle [vendor, location, driver, transport, device, target].

-R | –transport=<str> : Indique le type de transport à utiliser. [block, fc, iscsi, iscsivendor, ide, sas, sata, usb, parallel, unknown]

    Exemple :

Ajouter une règle 500, qui revendique tous les chemins avec comme fournisseur « VMWARE » et comme modèle « Virtual » pour le plugin NMP :

Ajouter une règle 501, qui revendique le chemin sur l’adaptateur vmhba0, le channel 0, target 0, LUN 0 pour le plugin NMP :

Ajouter une règle 502, qui revendique tous les chemins fournis par des adaptateurs FC pour le plugin NMP :

Ajouter une règle 503, qui revendique tous les chemins fournis par un adaptateur avec le pilote mptscsi pour le plugin NMP :

  • Chargement des règles

  • Supprimer une règle

Exemple :

Supprimer la règle 500:

Considération concernant le multipathing :

Si aucune règle n’a affectée de SATP au périphérique, le SATP par défaut pour iSCSI ou pour les périphériques FC est VMW_SATP_DEFAULT_AA et le PSP par défaut est VMW_PSP_FIXED

Lorsque le VMkernel recherche les règles SATP pour localiser le SATP d’un périphérique, il recherche les règles basées sur le « driver » en premier, les règles du fournisseur/modèle en deuxième et pour finir, les règles de transport. En cas de non correspondance avec aucune des règles, NMP sélectionne le  SATP par défaut pour le périphérique.

Comment masquer des règles des périphériques de stockage dans le VMkernel ?

De la même façon qu'il est possible de créer des règles de revendication de périphériques de stockage et de LUNs pour déterminer quels modules doivent réclamer les chemins d'accès. Il est possible d'empêcher totalement ou partiellement au VMkernel d'accéder aux chemins d'accès des LUN. Pour cela, il suffit de les masquer en créant des règles affectées au plugin MASK_PATH.

Les règles de ‘masking’ sont identiques à celles attribuées au plugin NMP à la différence qu’il faut préciser le plugin MASK_PATH (-P MASK_PATH) 

  • Création d’une règle de mask

Ajouter une règle 600, qui masque tous les chemins avec comme fournisseur « VMWARE » et comme modèle « Virtual » pour le plugin  MASK_PATH:

Ajouter une règle 601, qui masque le chemin sur l’adaptateur vmhba0, le channel 0, target 0, LUN 0 pour le plugin MASK_PATH :

Ajouter une règle 602, qui masque tous les chemins fournis par des adaptateurs FC pour le plugin MASK_PATH :

Ajouter une règle 603, qui masque tous les chemins fournis par un adaptateur avec le pilote mptscsi pour le plugin MASK_PATH :

7. Une fois la traversée du VMkernel effectuée, les I/O sont transmis aux ports physiques des cartes HBA ou des cartes réseaux. Nous ne parlerons pas du traitement des files d’attente dans ce post, car ce sujet a déjà été abordé dans un autre article.

En fonction du type d’adaptateur iSCSI, les I/O vont être encapsulés pour pouvoir traverser le réseau jusqu’aux périphériques de stockage. (Nous n’entrerons pas non plus dans les détails de la traversée des switch et des buffers d’entrées et de sortie)

En iSCSI Hardware (avec des cartes HBA – Host Bus Adapter):

Les cartes HBA à la différence de certaines cartes réseau classiques, permettent de prendre complétement en charge la gestion de la couche iSCSI et TCP/IP.

  • La carte HBA va encapsuler les requêtes I/O dans des PDU (Protocol data Unit)
  • Elle va ensuite encapsuler ses PDUs dans des paquets TCP/IP
  • Puis, les encapsuler dans des trames Ethernet pour les envoyer au stockage iSCSI

En iSCSI Software (avec des cartes réseaux classique):

Sur les cartes réseau classique toute la couche iSCSI et TCP/IP (en fonction du type de carte) est gérée par le VMkernel et utilise les ressources CPU & RAM de l’hôte ESXi pour traiter ces actions.

  • L’initiateur iSCSI software de VMware va encapsuler les requêtes I/O dans des PDU iSCSI
  • Il va encapsuler ses PDUs dans des paquets TCP/IP
  • Il va envoyer ses paquets TCP/IP à destination de la pile TCP/IP du VMkernel.
  • La pile TCP/IP du VMkernel va relayer les paquets TCP/IP vers la carte réseau physique
  • La carte réseau physique va encapsuler les paquets dans des trames Ethernet à destination du stockage iSCSI
8. Les I/O sont reçus sur les ports des cartes HBA des contrôleurs des baies de stockage, arrivent sur les différents niveaux de cache des contrôleurs puis sur les disques physiques.

twitterlinkedin
Publié dans Stockage, Vmware vSphere

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*