Zusammenfassung

  • RFC 7147 führte iSCSIProtocolLevel als Attribut jeder Sitzung und erhielt so den Geltungsbereich der Aushandlung zwischen Initiator und Ziel.
  • Stufe 2 belegt einen Protokollzustand dieser Sitzung. Sie bestätigt weder den Erfolg einer konkreten SCSI-Aufgabe noch ein von der Anwendung akzeptiertes Ergebnis.

Ein Gerät, mehrere Vereinbarungen

Ein Produktdatenblatt fasst Kompatibilität gern in einem Häkchen zusammen. Ein iSCSI-System besteht im Betrieb jedoch aus mehr als einer Verbindung: Es kann mehrere Instanzen, Knoten, Portale, Sitzungen und TCP-Verbindungen enthalten. Jede Sitzung verbindet einen Initiator mit einem Ziel. Die Protokollparameter werden zwischen diesen beiden Seiten ausgehandelt; eine weitere Sitzung kann andere Gegenstellen und einen anderen Zustand haben.

Genau diese Granularität machte RFC 7147 sichtbar. Der im April 2014 veröffentlichte Standard löste RFC 4544 ab und aktualisierte die iSCSI-Management-Information-Base passend zu RFC 7143 und RFC 7144. Neu waren zwei schreibgeschützte Attribute in der Sitzungstabelle: iscsiSsnProtocolLevel und iscsiSsnTaskReporting. Das erste nennt die für diese Sitzung ausgehandelte iSCSI-Protokollstufe. Das zweite hält die mit dem SCSI-Ziel ausgehandelten Regeln für die Meldung eines Aufgabenabschlusses fest.

Der Tabellenplatz ist mehr als eine Modellierungsfrage. Würde ein Dashboard den Wert als Geräteeigenschaft darstellen, würde eine Vereinbarung mit einem Initiator zur pauschalen Zusage für alle Pfade. RFC 7147 folgt der Grenze des Protokolls: Die Stufe gehört zu einer bestimmten Sitzung und bleibt dort zugeordnet.

Eine Aushandlung ist noch kein Ausführungserfolg

RFC 7144 verlangt, den Wert 2 von iSCSIProtocolLevel auszuhandeln, wenn die dort beschriebenen Funktionen verwendet werden sollen. Zugleich stellt der RFC klar: Die Aushandlung ist notwendig, aber nicht hinreichend, um die entsprechenden SCSI-Fähigkeiten zu nutzen. Eine Implementierung kann eine bestimmte Task-Management-Funktion weiterhin ablehnen. Der Initiator muss die SCSI-Antwort verarbeiten; ein SNMP-Lesezugriff kann sie nicht ersetzen.

Darum bedeutet „Stufe 2“ im Managementbildschirm nicht „alle Funktionen funktionieren“. Es bedeutet enger und belastbarer, dass die beiden Endpunkte dieser Sitzung die entsprechende Protokollstufe vereinbart haben. Ob eine konkrete Implementierung die benötigte Funktion anbietet, ob ein Befehl gesendet wurde, wie das Ziel antwortete und wie der Host damit umging, sind weitere Fragen.

Das zweite neue Attribut hält dieselbe Trennlinie ein. TaskReporting ist eine Bitmenge ausgehandelter Regeln zur Meldung von Aufgabenabschlüssen: neben dem Verhalten aus RFC 3720 etwa ResponseFence und FastAbort. Es beschreibt die Meldesemantik. Es belegt nicht, dass eine bestimmte Aufgabe lief, Daten dauerhaft gespeichert wurden oder eine Anwendung das Resultat übernahm.

Das Managementmodell trennt die Ebenen

Die MIB beginnt mit einer iSCSI-Instanz und ordnet darunter Knoten, Portale, Sitzungen und Verbindungen ein. Jedes nicht skalare Objekt wird zuerst über eine Instanz indiziert. Sie kann eine physische oder virtuelle Partition eines Speichersystems abbilden. RFC 7147 betont, dass eine Instanz keinen SNMP-Kontext ersetzt. Sie erleichtert vielmehr, eine Partition einem oder mehreren Kontexten zuzuordnen, ohne jede Knoten-, Portal- und Sitzungszeile einzeln abzubilden.

Damit bleiben verschiedene Nachweise unterscheidbar. Die Sitzungstabelle zeigt ausgehandelten iSCSI-Zustand; die TCP-MIB beschreibt Transportverbindungen; die SCSI-MIB kann Attribute der SCSI-Schicht erfassen. Host und Anwendung haben zusätzlich eigene Erfolgskriterien. Ein Managementsystem kann die Ansichten verknüpfen, doch ein einzelnes Feld macht daraus keinen Gesamtnachweis.

Die Vorrangstellung laufenden Codes wird hier sehr konkret. Eine Spezifikation zählt, weil Initiator und Ziel sie implementieren, aushandeln und Befehle austauschen. Die MIB zählt, weil sie einen definierten Zustand im laufenden System beobachtbar macht. Aber eine Beobachtung bleibt an eine Ebene und einen Zeitpunkt gebunden. Wer den Erfolg eines Vorgangs feststellen will, muss den Nachweis bis zur SCSI-Antwort und zum nutzenden System verfolgen.

Wofür die Zahl taugt

Die sitzungsbezogene Stufe kann erklären, warum zwei Pfade zum selben Speichersystem anders arbeiten. Sie unterstützt Kompatibilitätsanalysen, Änderungsprüfungen und Fehlersuche. Ebenso kann sie eine Abweichung zwischen Konfigurationserwartung und tatsächlicher Aushandlung sichtbar machen. Eine globale Gerätekennzeichnung würde gerade diesen Nutzen verwischen.

RFC 7147 sagt nicht, wie viele Hersteller die Objekte implementierten, wie oft sie abgefragt wurden oder wie Betreiber die Daten verwendeten. Zu einem Messwert gehören daher Sitzungskennung und Beobachtungszeitpunkt. Wurde die Sitzung neu aufgebaut, beschreibt ein alter Messwert den aktuellen Pfad nicht. Für den Erfolg eines Speicherbefehls braucht es die Korrelation mit SCSI-Antwort, Hostprotokoll und Anwendungsergebnis.

Die Aussage ist begrenzt, aber tragfähig: Die Protokollstufe gehört zu der Vereinbarung, die sie hervorgebracht hat. RFC 7147 gab dieser Vereinbarung einen eigenen Datensatz; das Ergebnis eines konkreten Vorgangs muss durch weitere Belege gezeigt werden.

Quellen