3.4 Funktionsweise des Speichersystems

Die folgenden Abschnitte beschäftigen sich mit der Funktionsweise der Komponenten des Speichersystems (Schnittstellenkomponente, Broker, Managementkomponente, Speicher) und deren Zusammenspiel. Weiterhin wird ein Überblick über Art und Funktionalität des zu verwendenden Übertragungsprotokolls gegeben.

3.4.1 Das Übertragungsprotokoll des Speichersystems

Innerhalb des Speichersystems wird ein Übertragungsprotokoll verwendet, das dem „Hyper Text Transfer Protocol“ (HTTP, [BLFFN95]) ähnlich, ASCII-basiert und zustandslos ist. Die eingesetzten Dienstprimitive können in zwei Klassen unterteilt werden, Speicherkommandos und Steuerkommandos. Die Menge der Speicherkommandos beinhaltet alle Befehle, die von den Speichern ausgeführt werden können. Folgende Grundfunktionalitäten müssen bereitgestellt werden:

In der Klasse der Steuerkommandos sollen mindestens folgende Funktionen unterstützt werden:

3.4.2 Die Schnittstellenkomponente

Schnittstellenkomponenten stellen das Bindeglied zwischen dem Speichersystem und dem Gesamtsystem dar. Die Schnittstellenkomponente dient weiterhin dazu, die eingehenden Nachrichten zu filtern und zu konvertieren, d.h. die Kommandos des Gesamtsystems werden in Kommandos des Speichersystems übersetzt und evtl. vorzunehmende länderspezifische Konvertierungen vorgenommen (z.B. Umlaute). Es ist zu bemerken, daß nicht die eigentlichen Dokumente gefiltert und damit verändert werden, sondern die eingegangenen Aufträge. In einem Speichersystem kann es mehrere Schnittstellenkomponenten geben. In Abbildung 3.5 werden unterschiedliche Möglichkeiten der Einbindung skizziert.
PIC
Abbildung 3.5: Einbindung der Schnittstellenkomponente

Die Schnittstellenkomponente wartet unter einer dem Gesamtsystem bekannten Adresse auf Aufträge aus der Infrastruktur (Client). Eine Schnittstellenkomponente kann gleichzeitig mehrere Aufträge aus der Infrastruktur verarbeiten.

Für jeden Auftrag unterhält die Schnittstellenkomponente zwei Netzverbindungen, eine zur auftraggebenden Instanz und eine zum Broker. Das hat den Vorteil, daß man keine Auftragskennung innerhalb des Speichersystems vergeben muß, um ein Ergebnis, einem Auftrag und dem Auftraggeber zuzuordnen. Die Zuordnung erfolgt durch einen verbindungsorientierten Dienst und ist damit eindeutig.

Empfängt die Schnittstellenkomponente einen Auftrag, so baut sie eine Netzverbindung zu einem Broker auf und leitet den Auftrag an diesen weiter. Die Schnittstellenkomponente wartet jetzt bis Resultate oder eine Fehlermeldung vom Broker empfangen werden und sendet diese an den Auftraggeber. Nachdem die Nachricht vom Broker empfangen wurde, sei es eine Fehlermeldung oder ein Ergebnis, wird die Verbindung zum Broker abgebaut.

Sollte die Schnittstellenkomponente keine Verbindung zum Broker aufbauen können, sendet sie eine entsprechende Fehlermeldung an den Auftraggeber.

Damit der Zugang zum Dokumentenspeichersystem selbst bei Ausfall des Brokers bestehen bleibt, werden Schnittstellenkomponenten nicht angehalten. Aus diesem Grund sind keine Steuerungsfunktionalitäten für diesen Komponententyp im Übertragungsprotokoll vorgesehen. Hiermit wird sichergestellt, daß eine auftraggebende Instanz immer eine Antwort auf einen Auftrag erhält und das ein Verbindungsaufbau zum Dokumentenspeichersystem ständig gewährleistet ist.

Wie und wann die Netzverbindung zur auftraggebenden Instanz des Gesamtsystems auf- bzw. abgebaut wird, hängt von den verwendeten Transportmechanismen der Infrastruktur ab. Dieser Teil der Funktionalität der Schnittstellenkomponente muß an das jeweilige Gesamtsystem angepaßt werden, weil verschiedene Infrastrukturen unterschiedliche Kommunikationsprotokolle zur Benutzung festlegen. Im Normalfall wird es sich hierbei um verbindungsorientierte TCP/IP-Verbindungen ([CK+81]) handeln. Eine Einführung in das TCP/IP-Protokoll bietet [Ste94]. Denkbar sind auch Anbindungen über IPX/SPX ([Nov92]) oder NetBeui/NetBios ([IBM88]) als Netzprotokoll. Darauf aufsetzend werden häufig HTTP-ähnliche Protokolle (Kap. 3.4.1) oder email-Protokolle (SMTP, [Pos82]) als Übertragungsprotokolle verwendet.

3.4.3 Der Broker

Broker haben die Aufgabe, die Aufträge, die sie durch die Schnittstellenkomponenten erhalten, auf die Speicher zur Ausführung zu verteilen und die Speicher zu steuern. Man kann Broker als zentrale Verwaltungs- und Steuerinstanz des Speichersystems verstehen.

Jeder Speicher meldet sich beim Broker an bzw. ab, wenn er gestartet oder beendet wird und teilt dem Broker die Adresse mit, unter der er auf Aufträge wartet. Der Broker unterhält seinerseits eine Liste aller angemeldeten Speicher und deren Zustände. Es handelt sich hierbei nicht um den Prozeßzustand der Speicher bzw. des Brokers, sondern um einen systeminternen Zustand der jeweiligen Komponente. Die Zustände der Komponenten werden vom Broker gespeichert und Aufträge dementsprechend verteilt. Ein Speicher befindet sich beispielsweise im Zustand „passive“, wenn er keinen Auftrag bearbeitet und er dem Broker als „passive“ bekannt ist. Der Speicher selbst hat keine Kenntnis davon, daß er „passiviert“ wurde, er empfängt lediglich keine weiteren Aufträge mehr. Mögliche Zustände aus der Sicht des Brokers sind:

Ein Zustandsdiagramm, das in gleicher Weise für den Broker und die Speicher gilt, ist in Abb. 3.6 dargestellt.


PIC
Abbildung 3.6: Zustandsdiagramm des Brokers und der Speicher

Der Zustand „not connected“ wird angenommen, wenn die Komponenten noch nicht oder nicht mehr Bestandteil des verteilten Systems sind.

Wenn eine Schnittstellenkomponente eine Verbindung zum Broker aufbaut und einen Auftrag sendet, überprüft der Broker in der Speicherliste welcher Speicher verfügbar ist. Der Broker baut eine Verbindung zum Speicher auf, sendet den Auftrag an den Speicher und vermerkt in der Speicherliste, daß der Speicher jetzt arbeitet (active busy) in der Speicherliste.

Der Broker wartet auf Antwort vom Speicher, erhält er eine Antwort, dann wird die Speicherliste wiederum aktualisiert (active idle) und die Verbindung zum Speicher abgebaut. Sollte die Verbindung zum Speicher gestört werden oder wird innerhalb einer bestimmten Zeitspanne keine Antwort empfangen, dann sendet der Broker selbständig eine Fehlermeldung an die Schnittstellenkomponente.

Die Auswahl eines geeigneten Speichers stellt ein nicht triviales Problem dar. Die gleichmäßige Verteilung der Aufträge unter Berücksichtigung der unterschiedlichen Performance der einzelnen Speicher sollte empirisch erfolgen. Dazu sammelt der Broker Informationen über Ausführungszeiten und Auftragsmenge der einzelnen Speicher. Anhand dieser statistischen Daten läßt sich jedem Speicher ein Perfomance-Index zuordnen (z.B. durchschnittliche Verarbeitungszeit pro Auftrag). Der Broker sucht dann immer den Speicher zur Abwicklung eines Auftrags aus, der den besten Performanceindex hat und momentan keinen Auftrag verarbeitet. Eine detailierte Beschreibung verschiedener Verfahren zur Leistungsmessung in verteilten Systemen findet sich in [Heu94].

3.4.4 Das Monitor-/Steuerungswerkzeug

Um das System steuern zu können, besitzen die Broker eine Steuerverbindung zu einer Managementkomponente, die als Monitor-/Steuerungswerkzeug bezeichnet werden soll. Mit diesem Werkzeug kann man sich an einen Broker verbinden und die Konfiguration des Brokers und der daran verbundenen Speicher anzeigen lassen. Über das Monitor-/Steuerungswerkzeug kann der Zustand der Speicher, sowie des Brokers verändert werden. Darüber hinaus können Speicher aus dem System ausgegliedert werden und Aufträge manuell auf die Speicher verteilt werden.

Es werden folgende Operationen unterstützt:

Die vom Monitor-/Steuerungswerkzeug initiierten Operationen bzgl. der Speicher werden dabei auf die in Abschnitt 3.4.1 beschriebenen Funktionen abgebildet. Die Operationen werden direkt durch den Broker verarbeitet. Das Monitor-/Steuerungswerkzeug verbindet sich über eine ausgezeichnete Netzverbindung an den Broker.

3.4.5 Der Speicher

Die Integration der Speicher in das Speichersystem erfolgt wiederum über einen verbindungsorientierten Dienst. Innerhalb eines Speichersystems können und sollen mehrere Speicher parallel eingesetzt werden, sie bilden einen Lastverbund. Alle Speicher im Lastverbund werden über das gleiche Netz- und Übertragungsprotokoll angesprochen und müssen dieses unterstützen.

Wird ein Speicher neu initiiert, dann schickt er eine Nachricht an den Broker und teilt diesem seine Existenz und die Adresse, unter der er auf Aufträge wartet, mit. Die Adresse des Brokers muß dem Speicher vorab bekannt sein. Soll der Speicher terminiert werden, so schickt er zuvor ebenfalls eine Nachricht an den Broker, um sich abzumelden und um damit zu verhindern, daß weitere Aufträge an ihn vergeben werden.

Der Broker wendet sich an den Speicher, wenn ein Auftrag von diesem Speicher ausgeführt werden soll. Der Speicher empfängt einen Auftrag vom Broker, ermittelt welche Aktion (Methode) auszuführen ist und führt die Methode innerhalb einer geeigneten Ablaufumgebung für mobilen Code aus. Das Ergebnis des Methodenaufrufs wird an den Broker zurückgegeben. Ein solcher Ablauf ist in Abbildung 3.7 skizziert. Ein Speicher kann immer nur einen Auftrag gleichzeitig bearbeiten.


PIC
Abbildung 3.7: Auftragsausführung aus Sicht des Speichers

Bemerkenswert ist, daß alle in das Speichersystem eingebundenen Speicher auf demselben Datenbestand operieren. Trotzdem wird durch die Verteilung auf mehrere Speicher ein großer Leistungsgewinn erreicht, da die Speicher auf unterschiedlichen Teilmengen der Daten operieren und die eigentliche Verarbeitung der Daten innerhalb der Ablaufumgebungen der Speicher erfolgt (z.B. das Entpacken und Packen von Bilddateien). Dabei werden die Speicher im allgemeinen auf unterschiedliche Rechnerknoten verteilt.