Zusammenfassung

  • RFC 3721 unterschied den dauerhaften Protokollnamen eines iSCSI-Knotens von seiner veränderlichen Netzwerkadresse und einem nicht zwingend eindeutigen Alias für Menschen.
  • Discovery konnte Zielnamen und Pfade finden, aber keine SCSI-Logical-Units entdecken und weder Login noch Berechtigung oder erfolgreiche Ein-/Ausgabe beweisen.

„Lokale Festplatte“ ist eine beruhigende Anzeige in einer Speicherverwaltung. Als Protokollidentität taugt sie nicht. Die Bezeichnung hilft vielleicht einem Menschen, eine Zeile auszuwählen; sie sagt einem entfernten System aber nicht, welches Ziel es kontaktieren soll, belegt nicht, wer sich verbindet, und entscheidet nicht, was diese Verbindung verwenden darf. Im April 2004 machte RFC 3721 diese Unterschiede für die Namensgebung und Discovery der Internet Small Computer Systems Interface (iSCSI) ausdrücklich.

Der zentrale Entwurfsschritt bestand darin, den Namen eines Knotens von seiner Adresse zu trennen. Ein logischer iSCSI-Knoten erhält für seine gesamte Lebensdauer einen dauerhaften, ortsunabhängigen Namen. Die Adresse kombiniert diesen Namen mit einem TCP-Standort, etwa Host und Port. Ein Knoten kann mehrere Adressen haben; seine Netzwerkkoordinaten können sich ändern. Dass ein Adapter zwischen Rechnern verschoben werden kann, war ein Grund, nicht den Adapter selbst zur Identität zu machen: Der logische Speicherknoten kann seinen SCSI-Zustand und seine Berechtigungskonfiguration behalten, obwohl sich der Pfad ändert.

Der qualifizierte Name iqn. enthält ein Datum, einen umgekehrten Domainnamen als Namensautorität und optional ein lokales Suffix. Die Syntax strukturiert einen Namensraum; sie beweist weder den heutigen Besitz der Domain noch den aktuellen Standort eines erreichbaren Ziels. RFC 3721 beschreibt außerdem das auf einem IEEE-EUI-64-Bezeichner beruhende Format eui.. In beiden Fällen identifiziert der Name den Knoten und dient nicht als Netzwerkroute.

Der Alias liegt auf einer anderen Ebene. Er ist eine optionale UTF-8-Anzeigezeichenfolge und muss nicht eindeutig sein. Das Beispiel in RFC 3721 zeigt „Local Disk“ neben dem tatsächlichen Zielnamen. Der Alias hilft Menschen, einen Eintrag wiederzuerkennen; das Protokoll darf ihn nicht zum Identifizieren, Adressieren oder Authentisieren eines Initiators oder Ziels verwenden. Zwei Systeme können denselben freundlichen Text anzeigen und trotzdem unterschiedliche Ziele meinen. Der Name kann stabil bleiben, während sich die Adresse ändert. Ein Pfad kann zu einem Ziel führen, ohne zu klären, ob ein Nutzer zugreifen darf.

Diese Trennung ist besonders wichtig, wenn Speicher bewegt wird. Wäre der Knotenname an eine bestimmte Schnittstelle oder Adresse gebunden, könnte eine Netzwerkanpassung wie eine neue Speicheridentität aussehen. Mit dem stabilen Namen kann die Konfiguration den logischen Knoten adressieren; die Adressen beschreiben, wo ein Verbindungsaufbau versucht werden kann. Das ist ein Kontinuitätsmechanismus, aber keine automatische Migrationsgarantie: Der RFC legt Namens- und Discovery-Verhalten fest, beweist jedoch nicht, dass jede Implementierung beim Umzug Zustände korrekt erhält.

Auch Discovery hat einen klaren Umfang. Ein Initiator soll Ziele finden, auf die er zugreifen darf, und mindestens eine Adresse dafür erhalten. Eine statische Konfiguration kann die Angaben vorab liefern. SendTargets lässt einen Initiator eine bekannte Netzwerkstelle kontaktieren und Zielinformationen anfordern. Zero-Configuration-Verfahren wie SLP und iSNS bieten breitere Möglichkeiten. Dass eine Spezifikation diese Verfahren beschreibt, ist keine Erhebung darüber, welche Speichernetze sie eingesetzt haben.

Vor allem gilt: Ein Ziel zu finden heißt nicht, dessen Laufwerke zu finden. RFC 3721 behandelt die Ermittlung von SCSI-Logical-Units (LUNs) als Aufgabe der SCSI-Schicht, getrennt von der iSCSI-Zieldiscovery. Ein gefundener Name samt Adresse beweist weder eine aufgebaute Sitzung noch erfolgreiche Authentisierung, Berechtigung, sichtbare LUNs oder übertragene Anwendungsdaten. Jede Stufe hat eine eigene Entscheidung und eigene Nachweise.

Der Sicherheitsabschnitt verstärkt diese Trennung. In nicht vertrauenswürdigen Umgebungen reicht der vom Initiator behauptete Knotenname nicht als Vertrauensgrundlage. Das Ziel authentisiert eine Sicherheitskennung – als Beispiele nennt der RFC CHAP, SRP und Kerberos – und erteilt anschließend typischerweise über eine Zugriffskontrollliste Berechtigungen. Diese authentisierte Kennung kann vom behaupteten iSCSI-Namen abweichen; die Richtlinie muss beide ausdrücklich zuordnen. Authentisierung beantwortet, wer einen Berechtigungsnachweis erbracht hat. Autorisierung beantwortet, was diese Identität tun darf.

Weder Alias noch Discovery-Antwort beantworten eine dieser Fragen.

Die spätere Standardisierung liefert einen nützlichen, aber begrenzten Nachtrag. RFC 4171 machte iSNS für iSCSI optional und für iFCP verpflichtend. RFC 7143, das iSCSI 2014 konsolidierte, empfiehlt Geräten mit Discovery-Bedarf über SendTargets hinaus iSNS für erweiterte Discovery-Verwaltung und Interoperabilität. Zugleich hielt der RFC fest, SLP sei für iSCSI nicht weit verbreitet implementiert oder eingesetzt worden; Implementierungen sollten sich daher nicht auf SLP-basierte Interoperabilität verlassen.

Das ist eine begrenzte Aussage über iSCSI in einem späteren RFC, keine Bestandsaufnahme aller Speicherprodukte oder Service-Discovery-Verfahren.

RFC 3721 ist ein Informational-Dokument und ergänzt, ersetzt aber nicht die Protokollspezifikation RFC 3720. Sein historischer Beitrag ist ein Vokabular für nicht austauschbare Datensätze: stabiler Knotenname, aktuelle Adresse, optionaler Anzeigealias, authentisierte Sicherheitsidentität, Berechtigungsregel und entdecktes Ziel. Eine praktische Konsole kann sie gemeinsam anzeigen. Verlässlicher Betrieb beginnt damit, sie nicht gleichzusetzen.

Quellen