Zusammenfassung

  • RowStatus unterscheidet lesbare Zustände (active, notInService, notReady) von nur schreibbaren Aktionen (createAndGo, createAndWait, destroy). Die Anweisung des Managers wird nicht mit dem vom Agenten feststellbaren Ergebnis gleichgesetzt.
  • Eine mit createAndWait angelegte Zeile kann unvollständig bestehen und Ressourcen binden, ohne exklusiv reserviert oder sicher aktivierbar zu sein. Gleichzeitige Zuweisung und Rollback gelten für ein SetRequest, nicht für mehrere Austauschschritte oder Geräte.

Was eine atomare Schreibgrenze tatsächlich umfasst

RFC 3416 lässt einen Agenten die Variablenbindungen eines SetRequest zunächst prüfen. Danach geschehen die Zuweisungen derselben Anfrage so, als wären sie untereinander gleichzeitig. Scheitert eine Zuweisung nach der Prüfung, werden die übrigen rückgängig gemacht und commitFailed wird gemeldet. Kann der Agent nicht alles zurücknehmen, meldet er undoFailed.

Das ist mehr als eine lose Folge einzelner Schreibvorgänge. Ein Manager kann mehrere Spaltenwerte und eine Erstellungsaktion in einer Nachricht zusammenfassen und erhält für genau diese Nachricht einen gemeinsamen Prüf- und Commit-Rahmen.

Die Formulierung verführt jedoch zu einer größeren Behauptung. Wird eine Zeile mit createAndWait angelegt, anschließend gelesen, in einer weiteren Anfrage ergänzt und später aktiviert, liegen mehrere abgeschlossene SetRequests vor. Zwischen ihnen kann der Manager ausfallen, ein Konkurrent schreiben oder das Gerät seinen Zustand ändern. Der Rollback der letzten Anfrage hebt die früheren nicht rückwirkend auf.

Ebenso wenig koordiniert ein SetRequest mehrere Agenten. „Wie gleichzeitig“ vergleicht Zuweisungen innerhalb eines PDU bei einer antwortenden Instanz. Es ist keine verteilte Transaktion für einen Gerätebestand. Schon undoFailed zeigt, dass selbst die lokale Rücknahme beobachtet und gegebenenfalls repariert werden muss.

Weshalb eine Zeile einen Zustand zwischen den Nachrichten braucht

Das SNMP von RFC 1157 aus dem Mai 1990 modellierte Agentenfunktionen bewusst als Zugriff auf und Änderung von benannten Variablen. Ein kleiner Satz von Operationen sollte viele unterschiedliche Verwaltungsobjekte tragen, anstatt gerätespezifische Befehle ständig zu vermehren.

Eine konzeptionelle Tabellenzeile verbindet jedoch mehrere Variablen über Zeit. Sie kann einen freien Index, Pflichtspalten ohne Standardwert, Konsistenz zwischen Werten und knappe Ressourcen benötigen. Mehrere Manager können dieselbe Steuertabelle benutzen. Auch das Gerät selbst kann Instanzen erzeugen.

Eine einzelne Schreiboperation beantwortet deshalb nicht, wie unvollständige Arbeit sichtbar bleibt, wann sie benutzt werden darf und wer sie entfernt, falls der Initiator nicht zurückkehrt. Diese Fragen gehören zum Lebenszyklus, nicht zu einem größeren Feldwert.

RMON machte das Problem früh praktisch. RFC 1271 behandelte im November 1991 Steuertabellen, in denen mehrere Manager begrenzte Überwachungsressourcen teilten. EntryStatus kannte createRequest, underCreation, valid und invalid. Der Text diskutierte Kollisionen, ausgefallene Manager, verwaiste Einträge und eine Owner-Zeichenkette zur Verständigung zwischen Beteiligten.

Eine solche Zeichenkette authentifiziert niemanden und erteilt keine Berechtigung. Sie liefert Kontext. Der wichtigere Schritt war, Erzeugung als sichtbare Phase anzuerkennen, die fehlschlagen oder zurückgelassen werden kann.

RFC 1443 verallgemeinerte dieses Muster im April 1993 als RowStatus und nannte RMONs EntryStatus ausdrücklich als Ursprung. RFC 1903 überarbeitete die Konvention 1996. Die Fassung in RFC 2579 von 1999 liefert die hier verwendeten detaillierten Übergänge. Aus dem Ressourcenproblem einer speziellen Steuertabelle entstand eine wiederverwendbare Lebenszyklus-Schnittstelle.

Aktionen werden nicht als Tatsachen zurückgelesen

RFC 2579 teilt die sechs RowStatus-Werte in unterschiedliche Rollen. active und notInService dürfen gelesen und geschrieben werden. notReady darf gelesen, aber nicht geschrieben werden. createAndGo, createAndWait und destroy dürfen geschrieben, aber niemals gelesen werden.

Schreibt ein Manager createAndWait, hinterlegt er nicht diesen Namen als dauerhaften Status. Der Agent führt eine Erstellungsaktion aus. Fehlen notwendige Informationen, erscheint anschließend notReady. Sind genug Informationen vorhanden, um den Einsatz zu versuchen, erscheint notInService.

Ein notReady-Ergebnis ist daher nicht gleichbedeutend mit „nichts angelegt“. Die Zeile kann existieren und Ressourcen verbrauchen. notInService ist wiederum kein Qualitätsnachweis. Es bedeutet nur, dass die Informationsschwelle für einen Aktivierungsversuch erreicht wurde.

Die Trennung schützt die Aussagekraft der Schnittstelle. Der geschriebene Wert beschreibt die Absicht des Managers; der gelesene Zustand beschreibt, was der Agent nach Bearbeitung bestätigen kann. Eine Anweisung wird nicht allein dadurch zur Tatsache, dass sie angenommen wurde.

Unvollständigkeit als wiederaufnehmbarer Zustand

createAndWait ist nützlich, wenn der Manager noch nicht alle Pflichtwerte kennt. Bei notReady kann er die Spalten lesen. Für eine erforderliche, noch nicht vorhandene Instanz erhält er noSuchInstance und kann den Wert setzen. Sobald die nötigen Angaben vorliegen, wechselt der Zustand zu notInService.

Der Zwischenstand bleibt damit auf der verwalteten Seite sichtbar. Nach einem Prozessabsturz kann ein Bediener die Zeile erneut lesen. Ein anderer Manager kann eine fehlende Zeile von einer vorhandenen, aber unvollständigen unterscheiden. Fortschritt ist nicht nur flüchtiger Clientzustand.

Der nächste Schritt bleibt dennoch eine Entscheidung des Agenten. Ein Schreiben von active kann mit inconsistentValue scheitern. Vorhandene Werte können miteinander unvereinbar sein; Ressourcen können fehlen; Voraussetzungen können sich seit der Erzeugung geändert haben. „Ausreichend für einen Versuch“ ist enger als „für den Betrieb akzeptiert“.

Auch Änderungsregeln bleiben objektspezifisch. Die DESCRIPTION einer Tabelle kann festlegen, welche Spalten während active veränderbar sind oder ob eine Zeile zuerst notInService werden muss. RowStatus liefert ein gemeinsames Gerüst, keine einheitliche Bearbeitungspolitik für jede MIB.

Warten ist kein exklusives Reservieren

Die sichtbare Zwischenphase kann wie eine Reservierung wirken. RFC 2579 warnt ausdrücklich vor dieser Annahme. Zwischen createAndWait und der späteren Aktivierung kann das verwaltete Gerät selbst dieselbe Instanz anlegen. Werte im Agenten können dann die vom Manager gelieferten Werte verdrängen.

Mehrere Nachrichten öffnen ein Konkurrenzfenster. Der erste Manager erhält keinen Sperrbesitz. Vor active die entscheidenden Spalten erneut zu lesen ist daher eine Konfliktprüfung. Eine Abweichung kann ein Beleg für ein anderes handelndes System sein und sollte nicht durch blindes Wiederholen überschrieben werden.

Auch destroy ist Aktion statt Endzustand. Sie kann für eine active, notInService oder notReady befindliche Zeile verlangt werden. Bei Erfolg verschwinden sämtliche Instanzen der Zeile. Danach existiert kein Objekt, das den Wert destroy als Grabstein zurückgeben könnte.

Wer einen historischen Löschbeleg benötigt, muss deshalb Anfrage, vorherigen Zustand und Autorisierung in einem eigenen Auditpfad festhalten. Der Statusspalte die Rolle eines Ereignisprotokolls zuzuschreiben, würde ihren Vertrag erweitern.

Verwaiste Zeilen und die Pflicht zur Bereinigung

Der Manager kann nach der Erzeugung ausfallen. Eine nicht eingesetzte Zeile bleibt dann in notReady oder notInService und bindet möglicherweise Speicher, einen Tabellenplatz oder Überwachungsressourcen.

RFC 2579 verpflichtet den Agenten, Zeilen zu erkennen, die ungewöhnlich lange in einem dieser Zustände verharren, und sie zu entfernen. Die DESCRIPTION der Statusspalte soll die Frist nennen. Nur wenn sie schweigt, schlägt der RFC ungefähr fünf Minuten vor.

Die fünf Minuten sind kein universeller Timer. Eine knappe Ressource kann eine kürzere Rückgewinnung verlangen; ein legitimer, genehmigungsabhängiger Ablauf braucht womöglich länger. Die Frist verteilt die Kosten zwischen Wiederaufnahme und Verfügbarkeit für andere Manager.

Die Bereinigung gilt außerdem für zuvor aktive Zeilen, die zu lange außer Dienst bleiben. Nicht das Alter der Erzeugung allein ist entscheidend, sondern ein Zwischenzustand, der seine normale Dauer überschreitet und weiterhin Ressourcen hält.

Eine genaue Aufteilung begrenzter Verantwortung

RowStatus garantiert keinen erfolgreichen Gesamtumbau. Der Manager fordert die Erzeugung an, liefert Werte und wählt den Zeitpunkt des Aktivierungsversuchs. Der Agent entscheidet, ob er die Instanz anlegen kann, ob Informationen genügen, ob Werte konsistent und Ressourcen verfügbar sind, und bereinigt verwaiste Arbeit. Die jeweilige Tabelle beschreibt ihre Änderungs- und Fristregeln.

So bleiben mehrere Aussagen getrennt: Die Aktion wurde gesendet. Die Erzeugung wurde akzeptiert. Die Zeile existiert. Die Pflichtangaben sind vorhanden. Der Agent akzeptiert active. Der beabsichtigte Dienst wirkt tatsächlich. Keine dieser Aussagen beweist automatisch die nächste.

Die Zeile, die vor ihrer Bereitschaft existierte, war kein unfertiger Sonderfall. Sie war die sichtbare Form einer Wahrheit, die ein binärer Erfolgswert verdeckt hätte. SNMP bewahrte kleine Operationen, indem es den längeren Prozess begrenzte und benannte, nicht indem es ihn leugnete.

Quellen