Zusammenfassung

  • RFC 2039 unterschied ein Betriebsmodell für Hardware, Betriebssystem, Prozesse, Abhängigkeiten und Kapazität von einem Dienstmodell für Anfragen und Antworten der Webnutzer.
  • Das Beispiel dreier virtueller Domains auf einem Rechner zeigte, dass Dienstidentität und Prozessbestand nicht fest gekoppelt sind und deshalb eine gepflegte Zuordnung brauchen.

Der Prozessor ist nicht ausgelastet, das Laufwerk antwortet, die Netzschnittstelle ist aktiv und der Serverprozess läuft. Trotzdem kann eine dynamische Seite ausfallen, wenn ihr Gateway oder ihre Datenbank nicht erreichbar ist. Die Host-Messungen sind dann nicht falsch. Falsch wäre nur, aus ihnen eine Aussage über ein anderes Objekt abzuleiten.

RFC 2039 erschien im November 1996 als Informational-Dokument und legte keinen Internetstandard fest. Der Text entstand auf Bitte des Network Management Area Director nach dem HTTP-MIB BOF beim 35. IETF-Treffen in Los Angeles. Er prüfte, wie weit bestehende Standards-Track-MIBs für die Verwaltung von WWW-Servern reichten.

Im Betriebsmodell ist der Webserver ein Computer aus Hardware, Platten, Betriebssystem, Serversoftware, Dateien und Prozessen. Verwaltung bedeutet hier, CPU-, Speicher- und Netzlast zu kennen, Abhängigkeiten abzubilden, Fehler einheitlich zu melden, Kapazitätsverläufe zu speichern und die Folgen eines Stopps oder einer Neukonfiguration zu verstehen.

Das Dienstmodell betrachtet denselben Server als Blackbox für Client-Anfragen und Antworten. Es fragt nach Nutzung und Leistung des Abrufdienstes, nach statischen und dynamischen Dokumenten, Berechtigungen und dem Betriebszustand jener Anwendungen, die dynamische Inhalte liefern.

Beide Modelle ergänzen einander, sind aber nicht austauschbar. Ein Host kann gesund und ein virtueller Dienst defekt sein. Ein Dienst kann noch antworten, obwohl seine betriebliche Reserve schwindet. Die Aussagen widersprechen sich nicht; sie betreffen verschiedene Ebenen.

Drei virtuelle Domains widerlegen die Eins-zu-eins-Annahme

Der RFC untersuchte MIB-II, Host Resources MIB, Network Services Monitoring MIB und die damalige Application-MIB-Arbeit. Es gab bereits nützliche Informationen über System, Schnittstellen, Prozessoren, Speicher, Geräte, installierte und laufende Software sowie Dienstanwendungen und Verbindungen. Ein großer Teil der betrieblichen Anforderungen war damit abgedeckt, der Dienstblick jedoch nur teilweise.

Das Problem erschien im Szenario eines Rechners mit drei virtuellen Domains. Ein Programm könnte alle drei bedienen, oder jede Domain hätte einen eigenen Prozess. Ein statisches Dokument hängt vielleicht nur von einer Datei ab, ein dynamisches zusätzlich von Gateway und Datenbank. Die Prozesstabelle kann wahrheitsgemäß melden, dass der Server läuft, ohne die gestörte Domain oder ihre Übertragung zu benennen. Die Diensttabelle kann Domains und Verbindungen trennen, ohne das zu reparierende Programm oder die nachgelagerte Abhängigkeit zu identifizieren.

Die Verbindung zwischen beiden Sichten war daher kein universeller Zeiger, sondern eine implementierungsabhängige Zuordnung. Sie musste gepflegt und durch web-spezifische Instrumentierung ergänzt werden.

Für die Betriebsseite verlangte RFC 2039 CPU-, Platten- und Netzwerte, Anwendungsabhängigkeiten, standardisierte Fehlermeldung, Kapazitätshistorie und strukturierte Informationen aus Serverprotokollen. Für die Dienstseite verlangte er Abrufnutzung und -leistung, Dokumentaktivität und Rechte, den Zustand dynamischer Quellen sowie zentrale Konfiguration, Start, Stopp, Protokollwechsel und einen Hinweis auf Dienstqualität.

Das waren Anforderungen, keine Erfolgsbilanz. Der RFC belegt weder Verbreitung noch Leistungsgewinn oder weniger Ausfälle. Internet-Draft, Mailingliste und Beispielimplementierung belegen damalige Arbeit, keinen Betrieb im Feld. Sicherheitsfragen wurden ausdrücklich nicht erörtert.

RFC 2594 konkretisierte 1999 als Proposed Standard die Dienstseite. Er modellierte WWW-Dienste, Dokumentübertragungsaktionen, Anfragen, Antworten, Statuscodes, virtuelle Hosts und Statistiken. Seine Sicht war ausdrücklich dienst- statt prozessorientiert und auf kurzfristige Fehlererkennung und Diagnose begrenzt, nicht auf Abrechnung. Er aktualisierte oder ersetzte RFC 2039 nicht formal, zeigte aber, warum ein Webdienst ein eigenes Vokabular benötigt.

Quellen