Résumé

  • RFC 3721 séparait le nom de protocole permanent d’un nœud iSCSI, son adresse réseau modifiable et son alias humain, trois valeurs qui ne répondent pas à la même question.
  • La découverte pouvait trouver des noms de cibles et des chemins, mais elle ne découvrait pas les unités logiques SCSI et ne prouvait ni connexion, ni autorisation, ni transfert réussi.

« Disque local » est un libellé rassurant dans une console de stockage. C’est aussi une mauvaise identité de protocole. Il aide éventuellement une personne à choisir une ligne, mais ne dit pas à un système distant quelle cible contacter, ne prouve pas qui se connecte et ne détermine pas ce que cette connexion peut utiliser. En avril 2004, RFC 3721 a rendu ces distinctions explicites pour le nommage et la découverte d’Internet Small Computer Systems Interface (iSCSI).

Le geste de conception central consiste à séparer le nom du nœud de son adresse. Un nœud iSCSI logique reçoit un nom permanent, indépendant de son emplacement, pour toute sa durée de vie. L’adresse associe ce nom à une localisation TCP, par exemple un hôte et un port. Un nœud peut avoir plusieurs adresses, et ces coordonnées réseau peuvent changer. Le déplacement d’une carte réseau entre machines explique notamment pourquoi l’identité ne doit pas être celle de la carte : le nœud logique peut conserver son état SCSI et sa configuration d’autorisation alors que son chemin change.

Le format de nom qualifié iqn. comprend une date, un nom de domaine inversé qui désigne l’autorité de nommage, puis un suffixe local facultatif. Cette syntaxe structure un espace de noms ; elle ne prouve ni la propriété actuelle du domaine ni l’emplacement où la cible est joignable. RFC 3721 décrit également le format eui., fondé sur un identifiant IEEE EUI-64. Dans les deux cas, le nom identifie le nœud ; il ne constitue pas une route réseau.

L’alias appartient à une autre couche. C’est une chaîne d’affichage UTF-8 facultative, qui n’a pas besoin d’être unique. L’exemple de RFC 3721 associe l’étiquette « Local Disk » au véritable nom de cible. L’alias aide une personne à reconnaître une entrée ; le protocole ne doit pas s’en servir pour identifier, adresser ou authentifier un initiateur ou une cible. Deux systèmes peuvent afficher la même formule sans désigner la même cible. Le nom peut rester stable alors que l’adresse change. Un chemin peut mener à une cible sans dire si l’utilisateur a le droit d’y entrer.

Cette séparation est particulièrement utile quand le stockage se déplace. Si le nom du nœud était lié à une interface ou à une adresse donnée, une reconfiguration réseau pourrait ressembler à la création d’une nouvelle identité de stockage. Le nom stable permet à la configuration de viser le nœud logique ; les adresses indiquent les chemins où une session peut être tentée. C’est un mécanisme de continuité, pas une garantie automatique de migration : le RFC définit un modèle de nommage et de découverte, non la preuve que toute implémentation préserve correctement l’état lors d’un déplacement.

La découverte est elle aussi circonscrite. Elle doit permettre à un initiateur de trouver les cibles auxquelles il a accès et d’obtenir une ou plusieurs adresses. Une configuration statique peut fournir ces informations d’avance. SendTargets permet de contacter une entité réseau connue pour demander des informations sur ses cibles. Des mécanismes de configuration sans intervention, dont SLP et iSNS, proposent une découverte plus étendue. Leur présence dans un document de spécification ne constitue pas un recensement des réseaux de stockage qui les ont déployés.

Surtout, trouver une cible ne revient pas à trouver ses disques. RFC 3721 distingue la découverte des unités logiques SCSI (LUN), qui relève de la couche SCSI, de celle des cibles iSCSI. Un nom et une adresse retournés ne prouvent ni l’établissement d’une session, ni l’authentification, ni une décision d’accès, ni la visibilité d’un LUN, ni le déplacement des données de l’application. Chaque étape possède sa propre décision et ses propres éléments de preuve.

La section sécurité renforce cette séparation. Dans un environnement non fiable, le nom de nœud revendiqué par un initiateur ne suffit pas à lui faire confiance. La cible authentifie un identifiant de sécurité — RFC 3721 cite notamment CHAP, SRP et Kerberos — puis autorise l’accès, généralement au moyen d’une liste de contrôle d’accès. Cet identifiant authentifié peut différer du nom iSCSI revendiqué ; la politique doit alors établir explicitement la correspondance entre les deux. L’authentification répond à « qui a prouvé un justificatif ? » L’autorisation répond à « que peut faire cette identité ?

» Ni l’une ni l’autre ne découle d’un alias ou d’une réponse de découverte.

La suite de la normalisation apporte une conclusion utile, mais limitée. RFC 4171 rend iSNS facultatif pour iSCSI, tout en l’exigeant pour iFCP. RFC 7143, qui consolide le protocole iSCSI en 2014, indique que les équipements ayant besoin d’une découverte au-delà de SendTargets devraient implémenter iSNS pour la gestion étendue et l’interopérabilité. Il note aussi que SLP n’avait pas été largement implémenté ni déployé pour iSCSI et recommande de ne pas compter sur son interopérabilité.

C’est une observation circonscrite à iSCSI dans ce RFC ultérieur, pas une affirmation sur tous les produits de stockage ou tous les mécanismes de découverte de services.

RFC 3721 est un document informatif qui complète, sans le remplacer, le protocole défini par RFC 3720. Son apport historique est un vocabulaire de données non interchangeables : nom stable du nœud, adresse actuelle, alias d’affichage facultatif, identité de sécurité authentifiée, règle d’autorisation et cible découverte. Une console pratique peut les présenter ensemble. Une exploitation fiable commence par ne pas les confondre.

Sources