|
Dieser Abschnitt entwickelt die Architektur des Speichersystems. Der grundlegende Aufbau des Speichersystems unterscheidet zunächst zwischen drei verschiedenen Arten von Komponenten, die im Speichersystem Verwendung finden können.
Unter Schnittstellenkomponenten versteht man Komponenten, die die Kommunikation mit der Infrastruktur bzw. dem Gesamtsystem durchführen. Ein Speichersystem kann mehrere Schnittstellenkomponenten besitzen. Diese können alle mit dem gleichen Gesamtsystem interagieren oder es ermöglichen, das Speichersystem an mehrere digitale Bibliotheken parallel zu verbinden. Über die Schnittstellenkomponenten erhält das Speichersystem die auszuführenden Aufträge. Die Ergebnisse eines Auftrages werden dann ebenfalls durch die Schnittstellenkomponente an den Auftraggeber geschickt.
Die Speicherkomponenten haben die Aufgabe Informationen aufzubewahren und diese Informationen auf Anfrage wieder zur Verfügung zu stellen. Weiterhin stellt ein Speicher eine oder mehrere Ablaufumgebungen und die dazugehörigen Programmbibliotheken für Dokumentenmethoden zur Verfügung, die es ermöglichen, die in Kapitel 2.4.2 erwähnten dokumentspezifischen Operationen speicherseitig auszuführen. Einige Operationen müssen speicherseitig ausgeführt werden, wie zum Beispiel der Vorgang des Speicherns, andere wie das Durchsuchen eines Dokuments können speicherseitig ausgeführt werden und wieder andere können nicht speicherseitig ausgeführt werden, beispielsweise die Darstellung (Präsentation) eines Dokuments.
Prinzipiell können Speicher für jede spezielle Art von Information (Videospeicher, Audiospeicher, u.s.w.) in das Speichersystem integriert werden. In Kapitel 4 wird ein aktiver Speicher behandelt, der zum einen exemplarisch in das Speichersystem eingebunden wird, zum anderen auf die speziellen Bedürfnisse von SGML-Dokumenten ausgerichtet ist.
Vermittlerkomponenten sorgen für die Verteilung der Aufträge auf die Speicher und für die Beantwortung jedes eingegangenen Auftrags. Weiterhin überwacht eine Vermittlerkomponente die Verbindungen zu Schnittstellen- und Speicherkomponenten. Vermittlerkomponenten tragen damit wesentlich zur konsistenten Verarbeitung der Auträge bei.
Die verschiedenen Komponententypen kommunizieren über definierte Schnittstellen unter Verwendung einer zuverlässigen Netzverbindung (z.B. TCP/IP).
Die verschiedenen Arten das Speichersystem als verteiltes System zu konzipieren unterscheiden sich durch die Ausprägung bzw. das Vorhandensein der Vermittlerkomponenten.
Ausgehend von der Aufteilung der Funktionalitäten auf die unterschiedlichen Komponententypen werden in den folgenden Abschnitten drei verschiedene Ansätze untersucht. Zum einen wird das klassische Client-Server-Paradigma (Two-Tier-Architektur) betrachtet, zum anderen zwei Ausprägungen der Three-Tier-Architektur. Die Ansätze werden beschrieben, auf Verwendbarkeit im vorliegenden Falle untersucht und die Auswahlentscheidung dargestellt.
Will man einen Speicher hinzufügen, so muß man entweder die Adresse des neuen Speichers allen Schnittstellenkomponenten mitteilen oder eine zusätzliche Schnittstellenkomponente starten, die dessen Adresse kennt. Die Adresse der neuen Schnittstellenkomponente muß dann allerdings publiziert werden, damit von außen Aufträge an die Schnittstellenkomponente geschickt werden können. Um allen Schnittstellenkomponenten die Adresse eines neuen Speichers mitzuteilen, muß entweder der Speicher alle Schnittstellenkomponenten kennen oder diese müssen manuell umkonfiguriert werden.
Möchte man einen Speicher aus dem System ausgliedern, so ist ein ähnlich komplizierter Vorgang durchzuführen, nur werden die Adressen des Speichers diesmal aus der Konfiguration der Schnittstellenkomponenten gelöscht oder die korrespondierende Schnittstellenkomponente wird ebenfalls ausgegliedert und dies wieder publiziert. Das Speichersystem muß also ganz oder teilweise angehalten werden, um neue Speicher ein- oder auszugliedern. Desweiteren müssen Mechanismen vorgesehen werden, die es ermöglichen Aufträge zu serialisieren und nacheinander auszuführen. Diese Mechanismen können entweder in die Schnittstellenkomponente oder in den Speicher integriert werden. Abbildung 3.1 veranschaulicht das Szenario.
Die Schnittstellenkomponente fragt zuerst beim Trader nach der Adresse eines Speichers und wendet sich dann direkt an den Speicher. Durch diese Vermittlungsinstanz ist es möglich zur Laufzeit neue Speicher in das Speichersystem einzubinden oder auszugliedern. In Abbildung 3.2 ist diese Anordnung schematisch dargestellt.
Zu inkonsistenten Zuständen des Speichersystems kommt es dann, wenn die Datenübertragungszeiten zwischen Schnittstellenkomponente und Speicherkomponente stark von den Laufzeiten zwischen Speicherkomponente und Trader abweichen.
Ist die Datenübertragungszeit zwischen Speicher und Trader wesentlich größer als die zwischen Schnittstellenkomponente und Trader, dann kann es passieren, daß der Trader gleichzeitig mehrere Aufträge an einen Speicher vermittelt, weil die Nachricht an den Trader über die Zustandsveränderung des Speichers noch nicht vom Trader empfangen wurde. Analog kann es zu einer Situation kommen, in der der Trader glaubt alle Speicher wären beschäftigt, obwohl diese ihre Aufträge bereits abgearbeitet haben. Im umgekehrten Fall tritt eine ähnliche Situation ein, da sich gleichzeitig mehrere Aufträge auf dem Weg zum Speicher befinden können.
Eine gleichmäßige Auslastung des Systems kann dann nicht mehr gewährleistet werden. Sieht man entsprechende Rückmeldemechanismen vor, können auch diese Probleme gelöst werden.
Die Schnittstellenkomponenten (Clients) kennen die Adresse des Brokers, ebenso die Speicher (Server). Die Speicher melden sich beim Broker an und ab, wenn sie ein- oder ausgegliedert werden. Eine Schnittstellenkomponente übermittelt einen Auftrag an den Broker, dieser prüft welche Speicher verfügbar sind und leitet den Auftrag an diesen Speicher weiter. Der Broker wartet auf die Antwort vom Speicher und sendet sie an die Schnittstellenkomponente.
Will man einen Speicher eingliedern, dann muß der Speicher nur die Adresse des Brokers kennen, er meldet sich an und ist ab diesem Zeitpunkt Bestandteil des Speichersystems. Das Ausgliedern eines Speichers kann direkt durch den Broker veranlaßt werden oder durch ein Signal an den Speicher erfolgen, der sich nach Ausführung des evtl. laufenden Auftrags beim Broker abmeldet. Der Broker kann seinerseits ein Kommando an den Speicher senden, der sich dann beendet.
Der Broker ist also immer über den Zustand aller Speicher informiert und kann diese steuern. Auch wenn ein Speicher „abstürzt“ wird dies vom Broker bemerkt (Timeout, Lost-Connection) und eine Fehlermeldung an die Schnittstellenkomponente gesendet oder sogar der Auftrag an einen anderen Speicher geschickt.
Zu Performanceproblemen kann es kommen, wenn die Aufträge große Datenmengen beinhalten und der Broker zu lange braucht um sie an die Speicher „durchzureichen“. Zu Überlastungen der Speicher kann es nicht kommen, da der Broker den nächsten Auftrag erst an den Speicher weiterleitet, wenn der Speicher verfügbar ist. Bei diesem Aufbau benötigt man deshalb keine Mechanismen zur Serialisierung der Aufträge in den Schnittstellenkomponenten oder den Speichern. Sollten einmal mehr Aufträge an den Broker übergeben werden als Speicher verfügbar sind, können diese entweder vom Broker zwischengespeichert werden bis ein Speicher frei wird oder der Broker gibt eine entsprechende Fehlermeldung an die Schnittstellenkomponente zurück.
Ein leistungsfähiger Lastverbund zeichnet sich dadurch aus, daß man ihn zur Laufzeit an quantitative Bedürfnisse anpassen kann, eine gleichmäßige Verteilung gewährleistet ist und man den „status quo“ des Lastverbundes und damit der einzelnen Speicher jederzeit ermitteln kann. Dabei bedeutet gleichmäßige Verteilung, daß die einzelnen Speicher gleichermaßen mit Aufträgen versorgt werden.
|
Hält man die Funktionalität der Schnittstellenkomponenten und Speicher so klein wie möglich, so vereinfacht dies evtl. vorzunehmende Anpassungen an das Gesamtsystem einer digitalen Bibliothek.
|
Das für das Speichersystem zugrundeliegende Konzept sieht vor, daß die Dokumente in Form von Metadokumenten an das Speichersystem übergeben werden. Die Metadokumente selbst referenzieren die Operationen und beinhalten oder referenzieren den Inhalt des Dokuments. Da Metadokumente nur beim Vorgang des Speicherns durch den Broker verarbeitet werden müssen und nicht etwa bei der Verteilung von anderen Aufträgen, ist ein Leistungsengpass nur zu erwarten, wenn zu viele Speicheraufträge zur selben Zeit an das Speichersystem gestellt werden. In der Regel wird das Speichersystem aber in Relation zum Gesamtauftragsvolumen nur verhältnismäßig wenige Speicheraufträge durchzuführen haben, die Anzahl von Abfragen und Suchaufträgen wird um ein vielfaches höher liegen. Aus diesem Grund ist nicht zu erwarten, daß der Broker einen Engpaß bildet, da die durch ihn durchschnittlich vermittelten Datenmengen im Verhältnis zum Inhalt eines Dokuments eher gering sind.
Der Nachteil dieser Architektur ist, setzt man nur einen Broker ein, ist das System bei Ausfall des Brokers nicht mehr funktionsfähig. Setzt man mehrere Broker ein, so müssen Mechanismen in Schnittstellenkomponenten und Speicher implementiert werden, die dafür Sorge tragen, daß automatisch ein anderer Broker kontaktiert wird. Auf Seiten der Schnittstellenkomponente läßt sich dies einfach dadurch erzielen, daß jede Schnittstellenkomponente mehrere Broker kennt und bei Ausfall des primären Brokers automatisch einen anderen Broker anspricht, sowie für die laufenden Aufträge eine Fehlermeldung an den Auftraggeber schickt, damit dieser den Auftrag erneut stellt.
Die Speicher können sich bei Ausfall des primären Brokers nicht mehr bei diesem abmelden und können nicht feststellen, daß der Broker nicht mehr verfügbar ist. Hier ist eine Art „Puls“ von Vorteil, d.h. der Speicher schickt in bestimmten Zeitintervallen eine kurze Nachricht an den Broker und wartet auf eine Antwort. Antwortet der Broker nicht innerhalb einer bestimmten Zeitspanne, so versucht sich der Speicher bei einem anderen Broker anzumelden. Auch hier muß der Speicher mehrere Broker kennen.
Alternativ kann ein Protokoll definiert werden, das es den Brokern ermöglicht untereinander zu kommunizieren. Werden die Speicherlisten ständig ausgetauscht und ein „Puls“ unter den Brokern realisiert, dann ist bei Ausfall eines Brokers die Übernahme der Speicher- und Schnittstellenkomponenten durch einen anderen Broker möglich. Allerdings bedarf es hierzu eines nicht geringen Realisierungsaufwands.
