Résumé

  • RFC 7147 inscrit le niveau iSCSI négocié dans les attributs de chaque session, là où l’accord entre initiateur et cible prend effectivement forme.
  • La valeur 2 décrit un état de protocole ; elle ne prouve pas qu’une commande SCSI précise a abouti ni qu’une application a accepté le résultat.

Deux sessions, deux négociations

Une fiche technique aime les adjectifs au singulier : compatible, actuel, pris en charge. Une baie iSCSI, elle, peut parler à plusieurs initiateurs, par plusieurs portails, au moyen de plusieurs sessions. Ces sessions ne sont pas les multiples noms d’une seule conversation. Chacune relie un initiateur à une cible et porte son propre état négocié.

C’est ce niveau de précision que RFC 7147 rend observable. Publié en avril 2014, le texte remplace RFC 4544 et met à jour le MIB iSCSI en cohérence avec RFC 7143 et RFC 7144. Il ajoute à la table des sessions deux attributs en lecture seule : iscsiSsnProtocolLevel et iscsiSsnTaskReporting. Le premier indique le niveau iSCSI négocié pour cette session. Le second indique les règles convenues avec la cible pour signaler la fin des tâches.

Le choix de cette table n’est pas un détail de rangement. Il empêche de transformer un accord local entre deux extrémités en qualité permanente de tout l’appareil. Une session ouverte par un autre initiateur peut avoir un autre interlocuteur et un autre niveau. Présenter un unique badge « niveau 2 » masquerait justement la différence que le protocole a négociée.

Une condition préalable ne vaut pas preuve d’exécution

RFC 7144 exige que la valeur 2 de la clé iSCSIProtocolLevel soit négociée pour utiliser les fonctionnalités qu’il décrit. Mais le texte ajoute aussitôt une limite : cette négociation est nécessaire, pas suffisante, pour utiliser les capacités SCSI correspondantes. Une cible peut toujours refuser une fonction particulière de gestion des tâches. L’initiateur doit alors traiter la réponse SCSI ; une lecture du MIB ne la remplace pas.

Cette distinction compte parce que le nombre paraît plus absolu qu’il ne l’est. Le niveau 2 signifie que les deux extrémités d’une session ont convenu d’un cadre de protocole. Il ne signifie pas que chaque fonction a été implémentée, qu’une requête donnée a été envoyée, que la cible l’a acceptée ou que l’application a consommé les données comme prévu. Ce sont des étapes différentes, qui exigent des preuves différentes.

La seconde entrée ajoutée par RFC 7147 illustre la même discipline. TaskReporting est un ensemble de sémantiques de signalement négociées — notamment le comportement de référence de RFC 3720, ResponseFence et FastAbort. Il décrit comment la fin d’une tâche doit être signalée. Il ne certifie ni la fin d’une tâche particulière, ni la persistance des données, ni la réussite d’un traitement applicatif.

Le MIB conserve aussi le périmètre de gestion

L’arbre de gestion commence par une instance iSCSI, puis décrit nœuds, portails, sessions et connexions. Chaque objet non scalaire est d’abord indexé par une instance. Celle-ci peut représenter une partition physique ou virtuelle d’un système de stockage. RFC 7147 précise qu’une instance ne remplace pas un contexte SNMP ; elle simplifie l’affectation d’une partition à un ou plusieurs contextes, sans répéter l’opération ligne par ligne.

Ces niveaux répondent à des questions distinctes. La table des sessions observe l’état iSCSI négocié. Le MIB TCP décrit les connexions de transport. Le MIB SCSI, lorsqu’il s’applique, porte les attributs de cette couche. L’hôte et l’application définissent encore leurs propres critères de réussite. Un outil de gestion peut relier les vues ; il ne transforme pas ces vues en une preuve unique.

La priorité au code qui tourne prend ici un sens concret. Le document compte parce qu’un initiateur et une cible l’implémentent, négocient, puis échangent des commandes. Le MIB compte parce qu’il permet d’observer un état défini dans ce système en fonctionnement. Mais cette observation reste située dans une couche et à un instant donnés. Pour dire qu’une opération a réussi, il faut suivre la chaîne jusqu’à la réponse et au consommateur concerné.

Ce qu’un opérateur peut conclure

Le niveau par session aide à comprendre pourquoi deux chemins vers le même stockage peuvent différer. Il peut orienter une enquête de compatibilité, une revue de changement ou un diagnostic, et révéler qu’une négociation réelle ne correspond pas à l’attente de configuration. Sa valeur tient à son périmètre ; le réduire à un attribut global la détruirait.

RFC 7147 définit des objets de gestion, mais ne mesure ni leur adoption par les fabricants, ni la fréquence de leur collecte, ni la manière dont les clients s’en servent. Un échantillon doit aussi conserver l’identité de session et son horodatage. Si la session a été recréée, une valeur ancienne ne décrit pas le chemin actuel. Pour vérifier une commande, il faut corréler l’observation avec la réponse SCSI, les traces de l’hôte et le résultat de l’application.

La leçon est sobre : le niveau appartient à l’accord qui l’a produit. RFC 7147 lui donne une ligne propre dans le MIB et laisse ouverte la question suivante : qu’a réellement fait l’opération ?

Sources