Entwurf und Implementierung eines Überwachungsdienstes für ...

CARL
VON
OSSIETZKY
DEPARTMENT FÜR INFORMATIK
SYSTEMSOFTWARE UND VERTEILTE SYSTEME
Entwurf und Implementierung eines
Überwachungsdienstes für das
adaptiv-dynamische
Replikationsrahmenwerk adGSV
Individuelles Projekt
12. November 2006
Matthias Davidek
Bloherfelder Str. 16
26129 Oldenburg
Erstprüfer
Zweitprüfer
Prof. Dr.-Ing. Oliver Theel
Dipl.-Inform. Christian Storm

Erklärung zur Urheberschaft
Hiermit versichere ich, dass ich diese Arbeit selbständig verfasst und keine anderen als
die angegebenen Hilfsmittel und Quellen benutzt habe.
Oldenburg, den 12. November 2006
Matthias Davidek

Die Überwachung von Zuständen und Abläufen eines System ist die zentrale Aufgabe eines
Überwachungsdienstes. Bei Auffälligkeiten kann der Überwachungsdienst in den Ablauf
eines Systems eingreifen und dieses steuern bzw. neu konfigurieren. Die Verwendung eines
Überwachungsdienstes bewirkt eine Automatisierung der Kontrollierung eines Systems. Der
Benutzer muss nicht selber den reibungslosen Ablauf des Systems überprüfen. Ein Überwachungsdienst
kann Fehler im System entdecken und darauf reagieren, um die Fehler schnell
zu beheben. Der Überwachungsdienst besitzt verschiedene Komponenten, die für die diversen
Aufgaben zuständig sind.
Ein Überwachungsdienst für das Rahmenwerk des adaptable dynamic General Structure
Voting-Verfahren soll entwickelt und implementiert werden. Dieser soll in das Rahmenwerk
integriert werden, um zu testen, ob der Überwachungsdienst Fehler in den Abläufen des
Rahmenwerks entdeckt und dementsprechend reagieren kann.
Der Überwachungsdienst soll die Möglichkeit bieten das adGSV-Rahmenwerk durch Sensoren
zu überwachen und bei Ereignissen durch Aktoren einzugreifen. Es sollen neue Sensoren
und Aktoren implementiert und dem Überwachungsdienst zur Verfügung gestellt werden
können. Mit Hilfe logischer Verknüpfungen soll die korrekte Zusammenarbeit der Sensoren
und Aktoren gewährleistet werden. Zudem sollen die logischen Verknüpfungen zwischen
den Sensoren und Aktoren angepasst und erweitert werden können. Messergebnisse und
Statusmeldungen sollen persistent gespeichert und somit protokolliert werden.

Inhaltsverzeichnis
1 Einleitung 1
2 Replikation 3
2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Replikationsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 statische Replikationsverfahren . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 dynamische Replikationsverfahren . . . . . . . . . . . . . . . . . . . . 7
2.3 adaptable dynamic General Structure Voting . . . . . . . . . . . . . . . . . . 8
2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Konzeption des Monitordienstes 10
3.1 Der Monitordienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Sensoren und Aktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Aufbau und Funktion von Sensoren . . . . . . . . . . . . . . . . . . . 11
3.2.2 Aufbau und Funktion von Aktoren . . . . . . . . . . . . . . . . . . . 13
3.2.3 Verwaltung von Sensoren und Aktoren . . . . . . . . . . . . . . . . . 14
3.3 Logik-Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Aufbau und Funktion von Logik-Strukturen . . . . . . . . . . . . . . 17
3.3.2 Verwaltung von Logik-Strukturen . . . . . . . . . . . . . . . . . . . . 21
3.4 Persistentes Speichern von Ergebnissen . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Aufbau und Funktion des Storage-Handlers . . . . . . . . . . . . . . 22
3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Architektur und Realisierung des Monitordienstes 25
4.1 Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Konzept, Entwurf und Komponenten . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Zusammenfassung und Ausblick 33
Literaturverzeichnis 34
A Handbuch 36
A.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2.1 adGSV-Rahmenwerk starten . . . . . . . . . . . . . . . . . . . . . . . 36
A.2.2 Monitordienst starten . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3.1 Erstellen eines neuen Sensors . . . . . . . . . . . . . . . . . . . . . . 37
A.3.2 Hinzufügen eines neuen Sensors . . . . . . . . . . . . . . . . . . . . . 37

A.3.3 Entfernen eines registrierten Sensors . . . . . . . . . . . . . . . . . . 38
A.3.4 Sensoren starten und stoppen . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Aktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.4.1 Erstellen eines neuen Aktors . . . . . . . . . . . . . . . . . . . . . . . 38
A.4.2 Hinzufügen eines neuen Aktors . . . . . . . . . . . . . . . . . . . . . 39
A.4.3 Entfernen eines registrierten Aktors . . . . . . . . . . . . . . . . . . . 39
A.5 Logik-Strukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.5.1 Erstellen einer neuen Logik-Struktur . . . . . . . . . . . . . . . . . . 39
A.5.2 Hinzufügen einer neuen Logik-Struktur . . . . . . . . . . . . . . . . . 40
A.5.3 Entfernen einer registrierten Logik-Struktur . . . . . . . . . . . . . . 40
A.6 Funktionen des Storage-Handlers . . . . . . . . . . . . . . . . . . . . . . . . 40
A.7 Anzeigen von Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Abbildungsverzeichnis
2.1 Eine 4 × 3 Gitterstruktur für 12 Knoten . . . . . . . . . . . . . . . . . . . . 6
3.1 Schema des Monitordienstes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Einzelne Sensoren werden von der abstrakten Basisklasse Sensor abgeleitet . 12
3.3 Einzelne Aktoren werden von der abstrakten Basisklasse Aktor abgeleitet . . 14
3.4 Das Register des Sensor Managers . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Das Register des Aktor Managers . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Logik-Struktur als Verknüpfung zwischen Sensoren und Aktoren . . . . . . . 17
3.7 1:1-Beziehung zwischen einem Sensor und Aktor . . . . . . . . . . . . . . . . 18
3.8 1:n-Beziehung zwischen einem Sensor und zwei Aktoren . . . . . . . . . . . . 18
3.9 n:1-Beziehung zwischen zwei Sensoren und einem Aktor . . . . . . . . . . . . 19
3.10 Syntax der gesamten Logik-Struktur . . . . . . . . . . . . . . . . . . . . . . 20
3.11 Der resultierende Graph aus der Logik-Struktur . . . . . . . . . . . . . . . . 20
3.12 Das Register des Dispatchers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Klassendiagramm des Monitordienstes . . . . . . . . . . . . . . . . . . . . . 27

1 Einleitung
Replikationstechniken verfolgen das Ziel eine höhere Verfügbarkeit von Daten zu gewährleisten.
Bei der Speicherung von Daten auf einem zentralen Rechner besteht das Problem,
dass bei dem Ausfall des Rechners Zugriffe auf die Daten nicht mehr möglich sind (Single
Point of Failure). Bei den Replikationstechniken werden verschiedene Kopien (Replikate)
eines Datums auf verschiedenen Rechnern abgelegt. Wenn ein einzelner Rechner ausfällt,
dann kann trotzdem auf das Datum auf einem anderen Rechner zugegriffen werden. Dabei
stellen die Replikationsverfahren die gegenseitige Konsistenz der Replikate sicher, in dem
verschiedene Strategien für Lese- und Schreiboperationen zur Verfügung gestellt werden.
Die Replikationsverfahren lassen sich in zwei Gruppen einteilen. Es gibt statische und dynamische
Replikationsverfahren. Bei den statischen Replikationsverfahren muss am Anfang
die Anzahl der teilnehmenden Knoten definiert werden. Diese Anzahl ist fix und kann nicht
verändert werden. Durch dieses Konzept kann es passieren, dass durch die vorgegebene
Strategie, wenn eine bestimmte Anzahl an Knoten ausfällt, der Zugriff auf das Datum nicht
mehr möglich ist. Um diesen Problem entgegen zu wirken, gibt es dynamische Replikationsverfahren,
die auf Ausfälle oder das Hinzufügen von Knoten reagieren können. Bei den
dynamischen Replikationsverfahren wird die Strategie nach dem Entfernen oder Hinzufügen
eines Knotens angepasst. Die dynamischen Verfahren sind eine Erweiterung der statischen
Verfahren, bei denen die Dynamikeigenschaften ergänzt wurden. Für die jeweiligen Verfahren
wurde eine Vielzahl an Strategien entwickelt, die verschiedene Vor- und Nachteile je
nach Anwendungszweck mit sich bringen.
Das adaptable dynamic General Structure Voting-Verfahren (adGSV-Verfahren) basiert
analog wie das dynamic General Structure Voting-Verfahren (dGSV-Verfahren) auf die
Verwendung von Voting-Strukturen und Epochen. Es ermöglicht eine flexible Verwaltung
von Replikaten, die zur Laufzeit in einer Voting-Struktur integriert oder aus einer Voting-
Struktur entfernt werden. Des weiteren können inhomogene Strategien verwendet werden, in
dem je nach Knotenanzahl eine andere Strategie verwendet wird. Zur Belegung der Durchführbarkeit
des Konzepts hatte Dipl.-Inform. Christian Storm ein Rahmenwerk entwickelt
und implementiert.
Das Ziel dieser Arbeit ist die Entwicklung und Implementierung eines Überwachungsdienstes
für das adGSV-Rahmenwerk. Der Überwachungsdienst soll in das Rahmenwerk integrierbar
sein und soll somit den Funktionsumfang des adGSV-Rahmenwerks erweitern. Die Aufgabe
des Überwachungsdienstes ist Komponenten zur Verfügung zu stellen, mit denen die Überwachung
bestimmter Bereiche und Funktionen des Rahmenwerks möglich ist. Des weiteren
müssen Komponenten existieren, mit denen auf die Ergebnisse der Überwachung reagiert
werden können. Es soll möglich sein bestimmte Aufgaben und Steuerungen des adGSV-
Rahmenwerks automatisch durch den Überwachungsdienst vornehmen zu lassen.
In dem folgenden Kapitel wird eine kurze Einführung in die Terminologie und Voraussetzun-
1

1 Einleitung
gen der Replikationstechniken gegeben. Es werden die verschiedenen Replikationsverfahren
betrachtet und das adGSV-Verfahren wird vorgestellt. Das 3. Kapitel behandelt die Konzeption
des Überwachungsdienst. Es werden Einblicke in die verschiedenen Komponenten für
die Funktion des Überwachungsdienstes gegeben. Die Implementierung des Überwachungsdienstes,
sowie die verwendeten Technologien werden in Kapitel 4 beschrieben. Das Kapitel
5 ist das abschließende Kapitel dieser Arbeit und bietet eine Zusammungfassung und einen
Ausblick.
2

2 Replikation
Zum besseren Verständnis der Thematik wird in diesem Kapitel eine kleine Einführung
in das Thema der Replikation gegeben. Zunächst werden die grundlegenden Begriffe und
Voraussetzungen für Repliaktionsverfahren erläutert. In Kapitel 2.2 werden die Replikationsverfahren,
sowie deren Arbeitsweise und Unterschiede, betrachtet. Das in [Sto06] beschriebene
adaptable dynamic General Structure Voting-Verfahren wird in dem Kapitel 2.3
kurz vorgestellt.
2.1 Grundlagen
Replikation bedeutet eine Vervielfältigung von Daten. Der Inhalt der replizierten Daten ist
jeweils identisch. Die Daten befinden sich dabei auf verschiedenen Rechnern, die über ein
Netzwerk verbunden sind, was einem verteilten System entspricht. Ein verteiltes System
besitzt eine Menge von voneinander unabhängigen Rechnern, die mit Hilfe eines Netzwerks
miteinander verbunden sind und kommunizieren. Die einzelnen Rechner werden als Knoten
bezeichnet. In einem verteilten System kann ein Knoten entweder verfügbar oder nicht
verfügbar sein, d.h. die Knoten verhalten sich Fail-Stop [SS83]. Die Knoten des verteilten
System stellen die verschiedenen Standorte für die Kopien der Daten dar. Die Kopie eines
Datums wird auch als Replikat bezeichnet. Knoten, die ein Replikat eines Datums besitzen,
nehmen an dem Replikationsverfahren für dieses Datum teil. Die Replikationsverfahren sorgen
für die gegenseitige Konsistenz der Replikate. Ansätze des Korrektheitskriteriums für die
Konsistenz der Replikate verwenden 1-Kopien-Serialisierbarkeit (1SR) [BHG87]. Dies besagt,
dass Operationen auf einem replizierten Datum denselben Operationen auf einem nicht
replizierten Datum gleichen. Für Lese- und Schreiboperationen auf den Knoten verwenden
die Replikationsverfahren verschiedene konsistenzerhaltende Strategien. Die Anforderungen
an die Replikationsverfahren unterscheiden sich in den Kosten und der Verfügbarkeit. Um
geringe Leseoperationskosten zu erzielen, muss ein wahlfreier Zugriff innerhalb einer großen
Anzahl an Replikaten ermöglicht werden. Eine kleine Anzahl an Replikaten, von denen
möglichst wenige synchron aktualisiert werden müssen, erzielen geringe Schreiboperationskosten.
Eine große Anzahl an Replikaten, die synchron aktualisiert werden, sorgen dagegen
für die Erhaltung der Datenkonsistenz.
Zur Konsistenzerhaltung verwenden die verschiedenen Strategien der Replikationsverfahren
eine verschiedene Anzahl an Knoten für Lese- und Schreiboperationen. Die Menge der an
dem Replikationsverfahren teilnehmenden Knoten, die für eine Operation gebraucht wird,
wird als Quorum [AE92] bezeichnet. Für Leseoperationen gibt es Lesequoren und für Schreiboperationen
gibt es Schreibquoren. Die einzelnen Quoren sind Teil einer Quorenmenge, die
für die jeweilige Strategie des Replikationsverfahrens gebraucht wird. Es muss sichergestellt
werden, dass ein Quorum aus einer nicht leeren Menge von dem am Replikationsverfahren
teilnehmenden Knoten besteht. Des weiteren darf ein Quorum keine echte Teilmenge eines
anderen Quorums sein.
3

2 Replikation
Die Quoren der Quorenmenge müssen eine wichtige Eigenschaft erfüllen, damit die Konsistenz
sicher gestellt werden kann. Jeweils zwei Schreibquoren oder ein Schreibquorum und
ein Lesequorum einer Quorenmenge müssen sich so überschneiden, dass sie mindestens einen
gemeinsamen Knoten besitzen. Eine Coterie [GB85, MN92] bezeichnet eine Quorenmenge,
bei der alle enthaltenden Quoren diese Überschneidungseigenschaft erfüllen. Um den gegenseitigen
Ausschluss von Schreiboperationen zu gewährleisten, muss die Schreibquorenmenge
eine Coterie sein. Der gegenseitige Ausschluss von Lese- und Schreiboperationen wird gewährleistet,
indem jedes Quorum aus der Lesequorenmenge mit jedem Quorum aus der
Schreibquorenmenge eine Coterie bildet. Zudem wird sichergestellt, dass jedes Lesequorum
mindestens einen Knoten mit einem aktuellen Replikat beinhaltet. Jeweils zwei Lesequoren
müssen sich nicht überschneiden, da Leseoperationen nicht modifizierend und somit konsistenzgefährdend
sind.
Jeder am Replikationsverfahren teilnehmende Knoten besitzt eine positive Ganzzahl als
Stimme. Wenn eine Operation durchgeführt werden soll, kann der Knoten seine Stimme
dafür abgegeben. Hat der Knoten seine Stimme für eine Operation abgegeben, dann darf
dieser seine Stimme bis zum Abschluss der Operation nicht erneut abgeben. Nach dem Abschluss
der Operation darf der Knoten seine Stimme für neue Operationen wieder abgeben.
Gibt ein Knoten seine Stimme für eine Operation nicht ab, dann wird die Durchführung
dieser Operation verweigert.
Beispiel Vier Knoten nehmen an einem Replikationsverfahren teil. Die Knoten werden
als R1, R2, R3 und R4 bezeichnet. Für Lese- und Schreiboperationen muss die Mehrzahl
der Knoten teilnehmen. Die Strategie des Replikationsverfahrens für Lese- und Schreiboperationen
entspricht also dem Mehrheitsprinzip (Majority Consensus Voting [HHB96]). Die
Lese- und Schreibquoren, die ebenfalls eine Coterie sind, sehen folgendermaßen aus:
Q r w = {{R 1 , R 2 , R 3 }, {R 1 , R 2 , R 4 }, {R 1 , R 3 , R 4 }, {R 2 , R 3 , R 4 }}
Lese- und Schreiboperationen auf einem Replikat werden als Transaktionen bezeichnet.
Dabei muss beachtet werden, dass eine Transaktion ein Replikat von einem konsistenten
Zustand in einen konsistenten Folgezustand überführt. Hierfür arbeiten die Transaktionen
nach dem ACID-Prinzip [HHB96] und es wird das 2 Phase Commit (2PC)-Protokoll [Ske81]
oder das 3 Phase Commit (3PC)-Protokoll [Ske81] benutzt.
Eine Transaktion wird entweder komplett oder gar nicht aus-
Atomicity (Atomizität)
geführt.
Consistency (Konsistenz) Eine Transaktion muss einen konsistenten Zustand in einen
konsistenten Folgezustand überführen.
Isolation Transaktionen zur Änderung eines Datums dürfen nur seriell ausgeführt werden.
Nur das Endergebnis einer fertigen Transaktion darf gelesen oder verändert werden.
Durability (Persistenz) Eine durchgeführte Änderung einer Transaktion bleibt dauerhaft
erhalten und kann nur durch weitere Transaktionen verändert werden.
4

2.2 Replikationsverfahren
2.2 Replikationsverfahren
Alle Knoten eines verteilten Systems, die an dem Replikationsverfahren für ein Datum
teilnehmen, besitzen ein Replikat dieses Datums. Zur Erhaltung der gegenseitigen Konsistenz
des Datums verfolgen die Replikationsverfahren bestimmte Strategien. Dabei sind
verschiedene Voraussetzungen zu beachten, wodurch sich die Replikationsverfahren in zwei
Kategorien einteilen lassen. Die beiden Kategorien sind statische und dynamische Replikationsverfahren.
In den beiden folgenden Kapiteln werden die statischen und dynamischen Replikationsverfahren
erläutert.
2.2.1 statische Replikationsverfahren
Statische Replikationsverfahren setzen voraus, dass zu Beginn das verwendete Verfahren
und die Anzahl der verwendeten Knoten fest definiert wird. Bei den statischen Replikationsverfahren
wird also mit einer fixen Lese- und Schreibquorenmenge gearbeitet. Es ist
nicht möglich während der Laufzeit das gewählte Verfahren und die Quorenmengen zu manipulieren.
Die statischen Verfahren lassen sich in zwei Untergruppen unterteilen und zwar
in unstrukturierte und strukturierte Verfahren.
unstrukturierte Verfahren Bei den unstrukturierten Verfahren besteht die Anzahl der
an dem Replikationsverfahren teilnehmenden Knoten in den Lese- und Schreibquoren aus
der von der Strategie vorgegebenen Mindestanzahl an Knoten zur Durchführung einer Operation.
Bei dem Weighted Voting-Verfahren [Gif79] werden die Knoten gewichtet, indem
sie eine individuelle Stimmenzuordnung erhalten. Je nach Zuverlässigkeit der Knoten können
diese durch eine hohe bzw. niedrige Stimmenanzahl entsprechend gewichtet werden.
Es werden eine Vielzahl von Strategien bei den unstrukturierten Verfahren verwendet. Als
Beispiel wird das Read One, Write All-Verfahren [HHB96] betrachtet. Die Beschreibung
der anderen Strategien der unstrukturierten Verfahren ist [HHB96] zu finden.
Read One, Write All-Verfahren
Das Read One, Write All-Verfahren (ROWA) stellt die einfachste Strategie dar. Wie der
Name bereits erkennen lässt, werden Schreiboperationen auf allen Knoten ausgeführt und
Leseoperationen können auf einem beliebigen Knoten ausgeführt werden. Dabei besteht
die Schreibquorenmenge aus einem Quorum mit allen an dem Replikationsverfahren teilnehmenden
Knoten. Die Lesequorenmenge beinhaltet Quoren mit jeweils einem Knoten.
Leseoperationen können ausgeführt werden, solange mindestens ein Knoten zur Verfügung
steht. Bei den Schreiboperationen führt bereits der Ausfall eines Knoten zu einer Blockade
aller Schreiboperationen bis der Ausfall behoben wurde.
Damit trotz ausgefallener Knoten Schreiboperationen ausgeführt werden können, kann das
Read One, Write All Available-Verfahren (ROWAA) [HHB96] verwendet werden. Dieses
Verfahren toleriert bei den Schreiboperationen den Ausfall einzelner Knoten. Gegenüber
dem ROWA-Verfahren werden bei dem ROWAA-Verfahren die Schreiboperationen bei Ausfällen
von Knoten nicht verzögert und die Replikate können auf allen verfügbaren Knoten
5

2 Replikation
aktualisiert werden. Das ROWAA-Verfahren toleriert den Ausfall von maximal n-1 Knoten.
Nach der Reparatur eines ausgefallenen Knotens besteht die Gefahr, dass ein veraltetes
Datum gelesen werden kann. Um dies zu verhindern, muss nach der Reparatur mit Hilfe
eines speziellen Protokolls das Replikat aktualisiert werden.
Des weiteren gibt es noch das Primary Copy ROWA- und das True Copy Token ROWA-
Verfahren. Die beiden Varianten werden zum weiteren Verständnis des ROWA-Verfahrens
nicht benötigt und werden nicht weiter betrachtet. Nähere Informationen sind in [HHB96]
zu finden.
strukturierte Verfahren Die an dem Replikationsverfahren teilnehmenden Knoten werden
bei den strukturierten Verfahren in einer logischen Struktur angeordnet. Jeder Knoten
ist an einer bestimmten Position der Struktur wiederzufinden. Anhand der Positionen
werden die Lese- und Schreibquoren gebildet. Bei den strukturierten Verfahren werden verschiedene
Strategien verwendet. Als Beispiel wird das Grid Protocol-Verfahren [AAC90] betrachtet.
Die Beschreibung der anderen Strategien der strukturierten Verfahren ist [HHB96]
zu finden.
Grid Protocol-Verfahren
Bei dem Grid Protocol-Verfahren (GP-Verfahren) werden die teilnehmenden Knoten logisch
in einem Gitter angeordnet. Das Gitter besteht aus M Zeilen und N Spalten. Daraus ergibt
sich ein M × N-Gitter. Alle Stellen des Gitters müssen durch einen Knoten besetzt werden.
Dadurch ist das GP-Verfahren auf Knotenanzahlen beschränkt, die M ∗N entsprechen
müssen. Jeder Knoten in dem Gitter ist mit jedem unmittelbaren Nachbarknoten verbunden.
Ein Lesequorum muss jeweils einen Knoten aus jeder Spalte beinhalten (C-Cover).
Eine andere Möglichkeit für ein Lesequorum ist alle Knoten aus einer Spalte (CC-Cover)
zu beinhalten. Ein Schreibquorum besteht aus einem C-Cover und einem CC-Cover. Dies
stellt sicher, dass sich die Knoten der Lese- und Schreibquoren überschneiden. In Abbildung
2.1 wird eine Gitterstruktur mit 12 Knoten gezeigt.
Abbildung 2.1: Eine 4 × 3 Gitterstruktur für 12 Knoten
6

2.2 Replikationsverfahren
2.2.2 dynamische Replikationsverfahren
Dynamische Replikationsverfahren können auf das Ausfallen und Wiederherstellen von Knoten
reagieren. Die Verfahren müssen an geänderte Knotenzahlen anpassbar sein und die
verwendete Strategie auf die neue Knotenanzahl adaptieren können. Dadurch soll eine höhere
Verfügbarkeit erzielt werden.
Nach dem Ausfallen und Wiederherstellen von Knoten müssen die dynamische Verfahren
darauf achtet, dass sie die Konsistenz der Daten erhalten. Das Problem besteht darin, dass
nach dem Ausfall einiger Knoten das Verfahren für die Anzahl der funktionierenden Knoten
angepasst wird. Bei dem neu angepassten Verfahren können weiterhin Schreiboperationen
durchgeführt werden. Eine bestimmte Menge an ausgefallenen Knoten können nach der Wiederherstellung
ein gültiges Lesequorum ergeben, das sich nicht mit einem Schreibquorum
des angepassten Verfahrens überschneidet. Dadurch kann eine veraltete Version des Datums
gelesen werden.
Beispiel Es sei eine Voting-Struktur mit einem einfachen Mehrheitsverfahren mit sieben
Knoten gegeben. Es fallen die Knoten R1, R2, R3 und R4 aus. Wenn die Strategie an die
restlichen Knoten R5, R6 und R7 angepasst wird, dann können die Replikate auf diesen
Knoten aktualisiert werden. Bei der Wiederherstellung der Knoten R1, R2, R3 und R4 ergeben
diese Knoten ein gültiges Lesequorum für die Strategie mit sieben Knoten. Es besteht
die Gefahr, dass dieses Lesequorum ein veraltetes Datum liest, da sich diese Knoten nicht
mit den Knoten R5, R6 und R7 überschneiden.
Die Verwendung von Epochen [LR93] vermeidet dieses Problem. Eine Submenge aller an
dem Replikationsverfahren teilnehmender Knoten, die zu einer bestimmten Zeit verfügbar
und verbunden sind, wird als Epoche bezeichnet. Zur Unterscheidung der Epochen existieren
Epochennummer. Epochennummern sind positive Ganzzahlen, die mit null initialisiert
werden. Wenn durch den Ausfall oder das Wiederherstellen eines Knotens das Verfahren angepasst
werden muss, dann erfolgt ein Epochenwechsel, bei dem die Epoche um eins erhöht
wird. Damit ein Epochenwechsel durchgeführt werden kann, wird die Zustimmung der Knoten
eines Schreibquorums benötigt. Dieses Schreibquorum muss einem Schreibquorum der
aktuellen und der neuen Epoche entsprechen. Die Vereinigungsmenge der beiden Schreibquoren
erhalten dann die neue Strategie und Epochennummer. Lese- und Schreiboperationen
dürfen nur auf Knoten ausgeführt werden, die die aktuelle Epochennummer besitzen
und somit ein Teil der aktuellen Epoche sind. Existiert in einem Quorum ein Knoten, der
eine niedrigere Epochennummer besitzt als die ermittelte aktuelle Epochennummer, dann
wird die Operation gestoppt und der Knoten wird aktualisiert. Danach wird die Operation
fortgesetzt.
Die dynamischen Replikationsverfahren arbeiten identisch wie die in Kapitel 2.2.1 erläuterten
statischen Replikationsverfahren. Es werden die statischen Replikationsverfahren durch
die o.g. dynamischen Eigenschaften erweitert und werden so zu dynamischen Replikationsverfahren.
7

2 Replikation
2.3 adaptable dynamic General Structure Voting
Das adaptable dynamic General Structure Voting-Verfahren (adGSV -Verfahren) [Sto06]
basiert analog wie das dynamic General Structure Voting-Verfahren (dGSV -Verfahren)
[TS98, TS99] auf Voting-Strukturen [The93] und Epochen. Es unterstützt die Verwaltung
einer flexibler Anzahl von Replikaten, da zur Laufzeit neue Knoten zu dem Replikationsverfahren
hinzugefügt werden können oder teilnehmende Knoten entfernt werden können.
Es können Strategiewechsel durchgeführt werden und es besteht die Möglichkeit der Nutzung
von inhomogenen Strategien, bei denen für jede Knotenanzahl eine andere Strategie
verwendet wird.
Die Voting-Strukturen und das Hinzufügen bzw. das Entfernen von Knoten sind zentrale
Punkte des adGSV-Verfahrens. In den folgenden Abschnitten werden diese Punkte kurz
erläutert. Nähere Informationen über das adGSV-Verfahren sind in [Sto06, ST06] zu finden.
Voting-Strukturen Durch das Hinzufügen und Entfernen von Knoten ändert sich die
Knotenanzahl. Dem Verfahren muss zu jeder Knotenanzahl eine Voting-Struktur bekannt
sein. Das adGSV-Verfahren arbeitet mit Strukturgeneratoren, um diese Voraussetzung zu
Erfüllen und um das Problem zu vermeiden, dass manuell potentiell unendlich viele Voting-
Strukturen erstellt werden müssen. In den Strukturgeneratoren ist die Strategie des Verfahrens
definiert. Für jede Strategie kann es einen Strukturgenerator geben, der vorher
implementiert werden muss. Dieser erzeugt je nach Strategie für eine Knotenzahl die jeweilige
Voting-Struktur. Es ist ebenfalls möglich manuell Voting-Strukturen zu erzeugen. Die
Benutzung einer inhomogenen Strategie kann erreicht werden, indem für jede Knotenanzahl
eine andere Strategie verwendet werden kann.
Hinzufügen von Knoten Es ist möglich neue Knoten in das Replikationsverfahren zu
integrieren. Hierfür muss der Knoten zunächst die Replikats- und Verfahrensinformationen
erhalten. Der neue Knoten wird in die Menge der am Replikationsverfahren teilnehmenden
Knoten hinzugefügt. Ist die Menge der an dem Replikationsverfahren teilnehmenden Knoten
leer, so wird der neue Knoten als initialer Knoten in die Menge aufgenommen. Ansonsten
führt der neue Knoten eine Aktualisierungsoperation anhand eines am Replikationsverfahren
teilnehmenden Knotens durch. Danach startet der neue Knoten einen Epochenwechsel,
bei dem eine neue Voting-Struktur erzeugt wird. Die neu erzeugte Voting-Struktur beinhaltet
den neuen Knoten.
Entfernen von Knoten Zunächst sucht der zu entfernende Knoten aus der Voting-
Struktur, die auf allen Knoten derselben Epoche dieselbe ist, eine Menge an anderen Knoten,
die einem Schreibquorum entsprechen. Von diesen Knoten versucht der zu entfernende
Knoten die Epochen- und Versionsnummern zu ermitteln. Wird keine Antwort gesendet,
wird versucht alternative Schreibquoren zu ermitteln, um die Informationen zu erhalten.
Bleiben alle Versuche erfolglos, so wird das Entfernen des Knotens abgebrochen. Bei Erfolg
wird aus dem Schreibquorum die höchste Epochen- und Versionsnummer erfragt. Besitzt
der zu entfernende Knoten eine niedrigere Epochen- und Versionsnummer, so kann dieser
aus dem Replikationsverfahren entfernt werden. Besitzen Knoten aus dem Schreibquorum
eine kleinere Epochen- und Versionsnummer als die ermittelte höchste Epochen- und Versionsnummer,
so müssen diese erst anhand des zu entfernenden Knotens aktualisiert werden,
8

2.4 Zusammenfassung
bevor dieser gelöscht werden kann, da der zu entfernende Knoten ein aktuelleres Replikat
besitzt. Zum Entfernen des gewünschten Knotens, initiiert dieser einen Epochenwechsel,
bei dem der zu entfernende Knoten nicht mehr in der neu erzeugten Voting-Struktur vorhanden
ist und löscht danach seine lokalen Daten. Wenn kein Epochenwechsel durchgeführt
werden kann, dann wird das Entfernen des Knotens abgebrochen. Falls ein Abbruch statt
gefunden hat, versucht der zu entfernende Knoten nach einer gewissen Zeitspanne erneut
sich zu löschen. Dies wird solange probiert bis der Knoten erfolgreich entfernt wurde.
Für das adGSV-Verfahren wurde von Dipl.-Inform. Christian Storm ein Rahmenwerk entwickelt,
in dem die o.g. Konzepte des adGSV-Verfahren implementiert wurden. Es hat die
Durchführbarkeit des Konzepts belegen und zu Testzwecken genutzt werden.
2.4 Zusammenfassung
Die Unterschiede zwischen statischen und dynamischen Replikationsverfahren liegen in der
Verwaltung der teilnehmenden Knoten. Bei den statische Verfahren müssen am Anfang die
teilnehmenden Knoten festgelegt werden. Die Anzahl der Knoten ist fix und kann nicht
geändert werden. Bei Ausfällen von Knoten kann der Zugriff auf die Daten durch die vorgegebene
Strategie nicht mehr gegeben werden. Mit Hilfe der Erweiterung von dynamischen
Eigenschaften, die mit einer dynamischen Anzahl von Knoten arbeiten können, kann diese
Beschränkung aufgehoben werden. Die dynamischen Replikationsverfahren verwenden die
selben Strategien wie die statischen Replikationsverfahren, die durch die Dynamikeigenschaften
erweitert wurden.
Das adGSV-Verfahren als Erweiterung und Weiterführung des dSGV-Verfahrens bietet die
Möglichkeit inhomogene Strategien zu verwenden. Replikate können zu dem Replikationsverfahren
hinzugefügt werden oder aus dem Replikationsverfahren entfernt werden. Je nach
Knotenanzahl kann eine andere Strategie verwendet werden. Voting-Strukturen können je
nach Strategie manuell oder durch Strukturgeneratoren für die jeweilige Anzahl von Knoten
erstellt werden.
Das folgende Kapitel stellt die Konzeption eines Monitordienstes, der als Überwachungsdienst
im adGSV-Rahmenwerk dienen soll, vor. Der Funktionsumfang des adGSV- Rahmenwerks
soll durch den Einsatz des Monitordienstes erweitert werden. Es werden die
Überwachungs- und Aktionskomponenten, sowie deren Zusammenarbeit, erläutert.
9

3 Konzeption des Monitordienstes
Der Monitordienst stellt eine Ergänzung des Funktionsumfangs des adGSV-Rahmenwerks
dar. Mit Hilfe von Sensoren und Aktoren werden Komponenten zur Verfügung gestellt, die
Aufgaben der Überwachung und des Eingreifens in das adGSV-Rahmenwerk übernehmen.
Die dabei anfallendenden Messergebnisse und Änderungsmeldungen werden gespeichert und
protokolliert. Dem Benutzer des Monitordienstes wird die Möglichkeit geboten den Monitordienst
je nach Aufgabenbereich anzupassen und zu erweitern. Es können neue Sensoren,
Aktoren, Verknüpfungen und Storage-Handler zum persistenten speichern erstellt und dem
Monitordienst zugänglich gemacht werden. In diesem Kapitel wird die Konzeption des Monitordienstes
vorgestellt.
Zunächst wird der generelle Aufbau und die Funktion des Monitordienst erläutert. Abschnitt
3.2 behandelt die Sensoren und Aktoren, die als zentrale Komponenten zur Überwachung
und zur Änderung der Konfiguration des adGSV-Rahmenwerks dienen. Der Aufbau, die
Funktion und die Verwaltung der logischen Verknüpfung von Sensoren und Aktoren wird
in Abschnitt 3.3 beschrieben. Zuletzt wird die Speicherung von Messergebnissen und Statusmeldungen
im Monitordienst im Abschnitt 3.4 betrachtet.
3.1 Der Monitordienst
Als Monitordienst wird das gesamte System bezeichnet, das zur Überwachung von Ereignissen
und Zuständen des adGSV-Rahmenwerks dient. Für ein solches System werden verschiedene
Komponenten benötigt, die jeweils bestimmte Teilaufgaben bewältigen. Folgende
Komponenten sind für den Monitordienst wichtig:
ˆ Die Komponente zur Registrierung von Ereignissen und Zuständen (Sensor)
ˆ Die Komponente zum Eingriff bzw. Steuerung auf Grund bestimmter Ereignisse und
Zustände (Aktor)
ˆ Die Komponente zum Speichern von Ergebnissen und Meldungen
ˆ Die Komponenten zur Steuerung und Verwaltung des Monitordienstes
Detailliertere Ausführungen zu den jeweiligen Komponenten des Monitordienstes sind in
den nachfolgenden Kapiteln zu finden.
Mit Hilfe der Sensoren überwacht der Monitordienst bestimmte Bereiche des adGSV- Rahmenwerks.
Die Ergebnisse der Überwachung werden gespeichert. Schlägt ein Sensor Alarm,
dann greifen die Aktoren ein. Die Änderungen, die die Aktoren vornehmen werden in Form
einer Meldung gespeichert.
10

3.2 Sensoren und Aktoren
Abbildung 3.1: Schema des Monitordienstes
Abbildung 3.1 zeigt eine schematische Darstellung des Monitordienstes. Eine detailliertere
Abbildung des Monitordienstes ist in Form eines Klassendiagramms in Kapitel 4 Abbildung
4.1 zu sehen. Der Monitordienst besitzt mehrere Sensoren und Aktoren zur Überwachung
und zum Ändern bestimmter Bereiche des adGSV-Rahmenwerks. Hierzu kann der Monitordienst
Informationen vom Rahmenwerk abfragen und Änderungen durchführen. Die dabei
anfallenden Ergebnisse und Meldung werden gespeichert.
Bei der Konzeption des Monitordienstes gibt es einige wichtige Aspekte, die der Monitordienst
genügen soll. Die wichtigsten Aspekte, die verfolgt werden, sind folgende:
ˆ Einfache Integration in den Funktionsumfang des adGSV-Rahmenwerks
ˆ Konfigurierbarkeit
ˆ Hinzufügen und Entfernen von Komponenten zur Laufzeit
3.2 Sensoren und Aktoren
Mit Hilfe von Sensoren und Aktoren soll dem Monitordienst die Möglichkeit gegeben werden
bestimmte Ereignisse und Zustände im adGSV-Rahmenwerk zu registrieren und darauf zu
reagieren. Durch den Einsatz verschiedener Sensoren und Aktoren ist die Überwachungsfunktion
des Monitordienstes nicht nur auf einen bestimmten Teilbereich begrenzt.
In den folgenden Abschnitten werden der Aufbau und die Funktion von den Sensoren und
Aktoren, sowie deren Verwaltung beschrieben.
3.2.1 Aufbau und Funktion von Sensoren
Das Prinzip eines Sensors im Monitordienst ist äquivalent zu einem Sensor aus der Messtechnik.
In der Messtechnik erfassen Sensoren bestimmte chemische oder physikalische Eigenschaften
entweder quantitativ oder qualitativ. Die Sensoren des Monitordienstes erfassen
bestimmte Eigenschaften im adGSV-Rahmenwerk, wie z.B. den momentanen Status eines
11

3 Konzeption des Monitordienstes
Knotens. Da die Sensoren des Monitordienstes bei einer Messung das Rahmenwerk ansprechen
und nicht angesprochen werden, kann man die Sensoren als aktive Sensoren einstufen.
Der funktionale Arbeitsablauf eines Sensors ist immer identisch. In bestimmten Zeitabständen
misst der Sensor in dessen definierten Bereich des adGSV-Rahmenwerks und wertet die
Messung aus. Das Messergebnis, sei es positiv oder negativ, wird gespeichert und protokolliert.
Fällt ein Messung negativ aus, dann löst der Sensor, den ihm zugeordneten Aktor aus.
Die Verknüpfung zwischen Sensoren und Aktoren wird in Kapitel 3.3 behandelt. Danach
beginnt der Ablauf wieder von vorn.
Der Aufbau eines Sensors ist immer gleich und lässt sich in folgende drei Bereiche aufteilen:
ˆ Initialisierung
ˆ Messen
ˆ Speichern der Messergebnisse
Abbildung 3.2: Einzelne Sensoren werden von der abstrakten Basisklasse Sensor abgeleitet
1 def Measure ( ) :
2 r e p l i c a s = ReplicaManager . G e t R e p l i c a s ( )
3 f o r i t e r a t o r i n r e p l i c a s . v o t i n g s t r u c t u r e . nodes phys :
4 t r y :
5 N e t w o r k i n g C l i e n t . Ping ( n e t r e f e r e n c e = i t e r a t o r . n e t r e f e r e n c e )
6 S a v e R e s u l t ( ”node ”+i t e r a t o r . name+” i s o n l i n e ”)
7 except E x c e p t i o n s . ErrorNet , msg :
8 S a v e R e s u l t ( ”node ”+i t e r a t o r . name+” f a i l e d ”)
9 A c t u a t o r S i g n a l ( )
10
11 def S a v e R e s u l t ( msg ) :
12 s t o r a g e . Write ( l o c a l t i m e ( ) , msg )
Listing 3.1: Pseudocode für einen Sensor
Aufgrund des identischen Aufbaus jedes Sensors wird eine abstrakte Basisklasse verwendet,
die als Vorlage zur Erstellung konkreter Sensoren dient (siehe Abbildung 3.2). Der strukturelle
Aufbau eines Sensors wird von der Basisklasse vorgegeben und spezielle Aufgaben
werden in den abgeleiteten Sensoren definiert. Für die Bereiche Messen und Speichern von
Messergebnissen der Sensoren existiert jeweils eine Methode. Die Methoden sind Measure()
12

3.2 Sensoren und Aktoren
und SaveResult(). In diesen beiden Methoden wird das Messen und das Speichern von Messergebnissen
für den jeweiligen Sensor und dessen Aufgabenbereich definiert und spezialisiert.
In Listing 3.1 sind die Methoden Measure() und SaveResult() eines Sensors in Form eines
Pseudocodes zu sehen. Es ist ein Beispiel für einen Sensor, der kontrolliert, ob alle Knoten
einer Votingstruktur online sind. Die Syntax des Pseudocodes ist an Python 1 angelehnt.
Sensoren werden in Form von Threads gestartet. Dies bietet den Vorteil nebenläufiger Abläufe
von Sensoren. Um Fehler zu vermeiden, nutzen die Sensoren Synchronisationskonzepte
(z.B.Locks Locks = Sperren), damit kritische Abschnitte im System geschützt werden. Des
weiteren kann beim Start der Sensoren die Zeitabstände zwischen den einzelnen Messungen
eingestellt werden, indem man die Wartezeit der Threads zwischen den Abläufen bestimmt.
Das Konzept der Sensoren verfolgt eine offene Struktur, das dem Administrator des Monitordienstes
erlaubt jegliche Arten von Messungen, Bedingungen usw. in den einzelnen
Sensoren zu definieren. Somit ist die Überwachungsfunktion des Monitordienstes nicht auf
bestimmte Bereiche oder Aufgaben begrenzt.
3.2.2 Aufbau und Funktion von Aktoren
Ursprünglich kommen Aktoren aus der Steuer- und Regelungstechnik und stellen das Gegenstück
zu den Sensoren dar. Aktoren sind der ausführende Teil, wenn ein Signal von
einem Sensor gesendet wird. Sie wandeln einen bestimmten Stimulus in eine Aktion um.
Die Aktoren von dem Monitordienst dienen dazu bei einem Signal von einem Sensor in das
adGSV-Rahmenwerk einzugreifen und es neu zu konfigurieren.
Der funktionale Arbeitsablauf eines Aktors ist immer gleich. Wenn bei einer Messung eines
Sensors ein per Definition abweichendes Ergebnis festgestellt wird, wird der zugehörige
Aktor durch ein Signal aktiviert. Die Verknüpfung zwischen Sensoren und Aktoren wird
in Kapitel 3.3 behandelt. Der Aktor führt die definierten Änderung in dem Rahmenwerk
durch und speichert danach eine Statusmeldung zur Protokollierung. Nach der Ausführung
des Aktors wartet dieser auf das nächste Signal eines Sensors
Der Aufbau eines Aktors ist immer identisch und lässt sich in folgende drei Bereiche aufteilen:
ˆ Initialisierung
ˆ Durchführung der Änderungen
ˆ Speichern der Statusmeldung
Genauso wie bei den Sensoren wird bei den Aktoren ebenfalls eine abstrakte Basisklasse als
Vorlage zur Erstellung einzelner Aktoren verwendet (siehe Abbildung 3.3), da der Aufbau
der Aktoren immer identisch ist. Die Basisklasse der Aktoren bestimmt den strukturellen
Aufbau. Die jeweiligen Änderungen, die ein Aktor durchführt, werden in den abgeleiteten
Aktoren definiert. Es existiert jeweils eine Methode für das Ausführen von Änderungen
1 Python http://www.python.org[07.2006]
13

3 Konzeption des Monitordienstes
Abbildung 3.3: Einzelne Aktoren werden von der abstrakten Basisklasse Aktor abgeleitet
und das Speichern von Statusmeldungen. Die Methoden sind Reconfigure() und SaveReport().
In diesen beiden Methoden wird die durchzuführende Änderung und das Speichern
der Statusmeldung für den jeweiligen Aktor definiert und spezialisiert. In Listing 3.2 sind
die Methoden Reconfigure() und SaveReport() eines Aktors in Form eines Pseudocodes zu
sehen. Das Beispiel zeigt einen Aktor, der einen Epochenwechsel einer Votingstruktur initialisiert.
1 def R e c o n f i g u r e ( ) :
2 r e p l i c a s = ReplicaManager . G e t R e p l i c a s ( )
3 r e p l i c a s [ 0 ] . EpochChange ( )
4 SaveReport ( ”epoch changed ”)
5
6 def SaveReport ( s e l f , msg ) :
7 s t o r a g e . Write ( l o c a l t i m e ( ) , msg )
Listing 3.2: Pseudocode für einen Aktor
Das Konzept der Aktoren verfolgt ebenfalls, wie das Konzept der Sensoren, eine offene
Struktur. So ist es dem Administrator des Monitordienstes möglich nötige Änderungen,
die aufgrund eines Messergebnisses in dem Rahmenwerk vorgenommen werden müssen, in
den einzelnen Aktoren zu definieren. Das Eingreifen und das Ändern der Konfiguration des
Monitordienstes ist dadurch nicht auf bestimmte Bereiche oder Aufgaben begrenzt.
3.2.3 Verwaltung von Sensoren und Aktoren
Der Monitordienst bietet die Möglichkeit mit mehreren Sensoren und Aktoren zu arbeiten.
Dadurch ist es nicht zwingend notwendig verschiedene Messbereiche und Änderungen in
einem Sensor und Aktor zu definieren. Verschiedene Aufgabenbereiche können feingranular
auf verschiedene Sensoren und Aktoren verteilt werden. Um die einzelnen Sensoren und
Aktoren verwalten zu können, wird eine zentrale Komponente benötigt, die diese Aufgabe
übernimmt.
Im Monitordienst existieren zwei zentrale Komponenten zur Verwaltung der Sensoren und
Aktoren. Der Sensor Manager und der Actuator Manager übernehmen jeweils Typ spezifisch
die Verwaltung der einzelnen Sensoren und Aktoren. Hierfür stellen die Manager
verschiedene Methoden zur Verfügung. Die zentrale Struktur zur Verwaltung der Sensoren
und Aktoren ist ein Sensor- und ein Aktorregister, in denen alle dem Monitordienst zur
14

3.2 Sensoren und Aktoren
Abbildung 3.4: Das Register des Sensor Managers
Abbildung 3.5: Das Register des Aktor Managers
15

3 Konzeption des Monitordienstes
Verfügung stehenden Sensoren und Aktoren registriert sind (siehe Abbildung 3.4 und 3.5).
Die Indizierung der jeweiligen Sensoren und Aktoren erfolgt über deren Namen und bietet
so einen leichten Zugriff. Dabei wird darauf geachtet, dass zwei verschiedene Sensoren oder
Aktoren nicht den selben Namen besitzen dürfen.
Das Hinzufügen und das Entfernen von Sensoren und Aktoren funktioniert nach dem Plugin-
Prinzip. Plugin bedeutet, dass Ergänzungs- bzw. Zusatzmodule dynamisch zur Laufzeit
ohne besonderen Aufwand zu einer Software hinzugefügt werden können und somit den
Funktionsumfang erweitern. Bei dem Monitordienst sind die von der Basisklasse abgeleiteten
Sensoren und Aktoren die Zusatzmodule, die den Umfang der Überwachungs- und
Steuerungsfunktion ergänzen bzw. erweitern. Dadurch werden die verschiedenen Funktionen
der Überwachung und Steuerung definiert und ermöglicht. Es ist möglich Sensoren und
Aktoren dynamisch zur Laufzeit in das Register des Sensor bzw. Aktor Managers zu laden
oder zu entfernen. Hierfür stehen drei Varianten zur Verfügung.
Plugin-Verzeichnis Alle Sensoren und Aktoren werden in einem bestimmten Verzeichnis
abgelegt. Der Sensor bzw. Aktor Manager erhält den Verzeichnispfad und lädt alle sich
dort befindenden Plugins in das Sensor bzw. Aktorregister. Dies wird bei jedem Start des
Monitordienstes einmal ausgeführt. Wenn ein weiterer Sensor oder Aktor im Verzeichnis
abgelegt wurde, kann diese Methode jederzeit wiederholt werden und so wird das neue Plugin
in das Sensor- oder Aktorregister geladen. Bereits registrierte Sensoren und Aktoren
werden dabei nicht doppelt in das Register geladen.
Manuelles Laden Es besteht die Möglichkeit gezielt einzelne Sensoren oder Aktoren
manuell in das Sensor- oder Aktorregister zu laden. Hierbei ist es nicht zwingend notwendig,
dass sich der neue Sensor oder Aktor im Plugin-Verzeichnis befindet. Der Sensor bzw.
Aktor Manager erhält die Pfadangabe und den Namen des Plugins als Übergabeparameter
und lädt dieses dann einzeln in das Sensor- bzw. Aktorregister.
Manuelles Entfernen Es besteht die Möglichkeit einzelne Sensoren oder Aktoren manuell
aus dem Sensor- oder Aktorregister zu entfernen. Hierfür benötigt der Manager lediglich
den Namen des Plugins, um dieses aus dem Register zu löschen. Hierbei wird das Plugin
nur aus dem Register des Managers entfernt. Das Plugin wird nicht physikalisch auf der
Festplatte gelöscht. Nach dem Löschen eines Sensors oder Aktors werden die Verknüpfungen
aktualisiert, damit es zu keinem Fehler kommt. Weitere Dinge müssen bei dem Entfernen
nicht beachtet werden.
3.3 Logik-Strukturen
In den vorherigen Kapiteln wurde die Funktion und der Aufbau von Sensoren und Aktoren
erläutert. Damit die Sensoren und Aktoren sinnvoll zusammenarbeiten, ist ein Konstrukt
nötig, das die einzelnen Sensoren und Aktoren miteinander verknüpft (siehe Abbildung 3.6).
Die Verknüpfungen zwischen Sensoren und Aktoren werden als Logik-Strukturen bezeichnet.
Diese Logik-Strukturen stellen die elementare Komponente für die Zusammenarbeit
der Sensoren und der Aktoren des Monitordienstes dar.
16

3.3 Logik-Strukturen
Abbildung 3.6: Logik-Struktur als Verknüpfung zwischen Sensoren und Aktoren
In den folgenden Abschnitten wird der Aufbau und die Funktion von Logik-Strukturen,
sowie deren Verwaltung beschrieben.
3.3.1 Aufbau und Funktion von Logik-Strukturen
Logik-Strukturen ermöglichen gezielte Verknüpfungen zwischen Sensoren und Aktoren. Per
Definition wird einem Sensor ein bzw. mehrere Aktoren zugewiesen, die der Sensor im Falle
einer Messsituation ansteuern soll. Logik-Strukturen sind Graphen, in denen Wurzelknoten
(Sensoren), Kanten und Blattknoten (Aktoren) definiert werden. In den folgenden Abschnitten
werden die Basisübergänge, sowie deren formale Darstellung der Logik-Strukturen
beschrieben.
Grundlegendes Zunächst werden die Mengen der Sensoren und Aktoren definiert.
Sensors = {S 1 , S 2 , . . . , S n } wobei n ∈ N \ {0}
Actuators = {A 1 , A 2 , . . . , A n } wobei n ∈ N \ {0}
Weiter bedeuten:
↦→ : schaltet
0 bedeutet bei Sensoren: Sensor gibt kein Signal
0 bedeutet bei Aktoren: Aktor wird nicht ausgeführt
1 bedeutet bei Sensoren: Sensor gibt ein Signal
1 bedeutet bei Aktoren: Aktor wird ausgeführt
1:1-Beziehung Die 1:1-Beziehung bedeutet, dass nur ein Sensor mit einem Aktor verknüpft
ist. Dies ist die minimalste Beziehung, die zwischen Sensoren und Aktoren bestehen
kann. Abbildung 3.7 zeigt eine 1:1-Beziehung zwischen dem Sensor S 1 und dem Aktor A 1 .
Formal betrachtet, sieht eine 1:1-Beziehung folgendermaßen aus:
S i ↦→ A j : i, j ∈ N \ {0} und S i ∈ Sensors und A j ∈ Actuators
Folgende Tabelle zeigt das Verhalten der Sensoren und Aktoren bei einer 1:1 Beziehung:
Ereignis Resultat
S i = 0 A j = 0
S i = 1 A j = 1
17

3 Konzeption des Monitordienstes
Abbildung 3.7: 1:1-Beziehung zwischen einem Sensor und Aktor
1:n-Beziehung Die 1:n-Beziehung bedeutet, dass ein Sensor mit mehreren Aktoren verknüpft
ist. Dabei löst der Sensor, wenn er ein Signal sendet, alle mit ihm verknüpften
Aktoren aus. In Abbildung 3.8 ist eine 1:n-Beziehung zwischen dem Sensor S 1 und den
Aktoren A 1 und A 2 zu sehen.
Abbildung 3.8: 1:n-Beziehung zwischen einem Sensor und zwei Aktoren
Formal betrachtet, sieht eine 1:n-Beziehung folgendermaßen aus:
S i ↦→ A 1 ∧ · · · ∧ A k : i, j, k ∈ N \ {0} und S i ∈ Sensors und A 1 , . . . , A k ∈ Actuators
Folgende Tabelle zeigt das Verhalten der Sensoren und Aktoren bei einer 1:n Beziehung:
Ereignis Resultat
S i = 0 A 1 , . . . , A k = 0
S i = 1 A 1 , . . . , A k = 1
n:1-Beziehung Die n:1-Beziehung bedeutet, dass mehrere Sensoren mit einem Aktor verknüpft
sind. Dabei kann jeder einzelne Sensor diesen Aktor auslösen. Abbildung 3.9 zeigt
eine n:1-Beziehung zwischen den Sensor S 1 und S 2 und dem Aktor A 1 .
Formal betrachtet, sieht eine n:1-Beziehung folgendermaßen aus:
S 1 ∨ · · · ∨ S j ↦→ A k : i, j, k ∈ N \ {0} und S 1 , . . . , S j ∈ Sensors und A j ∈ Actuators
18

3.3 Logik-Strukturen
Abbildung 3.9: n:1-Beziehung zwischen zwei Sensoren und einem Aktor
Folgende Tabelle zeigt das Verhalten der Sensoren und Aktoren bei einer n:1 Beziehung:
Ereignis
Resultat
S 1 , . . . , S j = 0 A k = 0
∃S = 1 : S ∈ {S 1 , . . . , S j } A k = 1
Übergänge zwischen Sensoren oder zwischen Aktoren werden nicht betrachtet, da die Strukturen
ansonsten zu komplex und unübersichtlich werden. Die offene Struktur zur Definition
von Sensoren und Aktoren bietet trotzdem die Möglichkeit Beschränkungen durch die Logik-
Strukturen zu kompensieren.
Beispiel Anstatt zwei Aktoren zu definieren, die nacheinander ausgeführt werden sollen,
indem sie eine 1:1 -Beziehung zwischen Aktoren besitzen, kann ein komplexerer Aktor definiert
werden, der die Aufgaben beider Aktoren übernimmt und nacheinander ausführt.
In Abbildung 3.10 ist das Syntaxdiagramm für die formale Darstellung von Logik-Strukturen
zu sehen. Es zeigt, welche Logik-Strukturen sich durch die Basisübergängen bilden lassen.
Der Monitordienst bietet eine Komponente, in der die Logik-Strukturen erfasst werden.
In dieser Komponente werden die erstellten Logik-Strukturen gespeichert und es werden
die Verknüpfungen zwischen den Sensoren im Sensor Manager und den Aktoren im Actuator
Manager hergestellt. Wenn ein Sensor ein per Definition abweichendes Messergebnis
erfasst, sendet dieser ein Signal an den Logik-Struktur-Dispatcher, der die verschiedenen
Logik-Strukturen verwaltet (siehe Kapitel 3.3.2). Die Logik-Struktur kennt die Verknüpfungen
zwischen den signalisierenden Sensor und die Aktoren, die dieser Sensor auslösen
möchte. Die passenden Aktoren werden dann von der Logik-Struktur aktiviert.
Logik-Strukturen können entweder manuell eingegeben werden oder aus Konfigurationsdateien
geladen werden. Für die Definition von Logik-Strukturen müssen jeweils die Wurzelund
Blattknoten der Struktur gesetzt werden. Als Beschreibungssprache zur Definition von
Logik-Strukturen in einer Konfigurationsdatei bietet sich die Dot-Beschreibungssprache von
GraphViz 2 an. In dieser Beschreibungssprache lassen sich einfach Graphen definieren, was
die Erstellung von Logik-Strukturen vereinfacht. Das folgende Listing zeigt eine Konfigura-
2 GraphViz http://www.graphviz.org[08.2006]
19

3 Konzeption des Monitordienstes
Abbildung 3.10: Syntax der gesamten Logik-Struktur
tionsdatei im Dot-Format für eine Logik-Struktur mit drei Sensoren und zwei Aktoren.
1 d i g r a p h ”L o g i c S t r u c t u r e ” {
2
3 S1−>A1 ;
4 S1−>A2 ;
5 S2−>A2 ;
6 S3−>A2 ;
7 }
Listing 3.3: Definition einer Logik-Struktur
Aus dem oben gezeigten Listing resultiert eine Logik-Struktur, dessen Graphen in Abbildung
3.11 zu sehen ist.
Abbildung 3.11: Der resultierende Graph aus der Logik-Struktur
Der Sensor S1 besitzt eine 1:n-Beziehung zu den Aktoren A1 und A2. Die Sensoren S2
und S3 besitzen jeweils eine 1:1 -Beziehung zu dem Aktor A2. Wenn der Sensor S1 ein per
20

3.3 Logik-Strukturen
Definition abweichendes Messergebnis erfasst, dann steuert dieser die Aktoren A1 und A2
an.
3.3.2 Verwaltung von Logik-Strukturen
Logik-Strukturen können bei einer hohen Anzahl von Sensoren und Aktoren schnell zu
komplex und unübersichtlich werden. Um diesem Problem entgegen zu wirken, besteht die
Möglichkeit mehrere Logik-Strukturen zu definieren. So können z.B. die Verknüpfungen
zwischen Sensoren und Aktoren in verschiedenen Logik-Strukturen gruppiert werden. Die
verschiedene Logik-Strukturen werden im Monitordienst mit Hilfe einer zentralen Komponente
(Dispatcher) verwaltet. Die hierfür verwendete Struktur im Dispatcher ist ein ein
Logik-Struktur-Register, in dem alle erstellten Logik-Strukturen vorliegen (siehe Abbildung
3.11). Die einzelnen Logik-Strukturen werden in dem Logik-Struktur-Register mit ihren Name
indiziert, was einen leichten Zugriff ermöglicht. Dabei wird darauf geachtet, dass zwei
verschiedene Logik-Strukturen nicht den selben Namen besitzen dürfen.
Abbildung 3.12: Das Register des Dispatchers
Der Dispatcher deckt verschiedene Aufgabenbereiche zur Verwaltung der Logik-Strukturen
ab. In den folgenden Abschnitten werden diese Aufgabenbereiche beschrieben.
Hinzufügen von Logik-Strukturen Dem Benutzer des Monitordienstes wird die Möglichkeit
gegeben Logik-Strukturen manuell zu erstellen und in das Logik-Struktur-Register
abzulegen. Die komfortablere Lösung ist das Definieren von Logik-Strukturen per Konfigurationsdateien.
Der Dispatcher benötigt lediglich die Pfadangabe zur Konfigurationsdatei
und kann die sich darin befindende Logik-Struktur in das Logik-Struktur-Register laden.
Es ähnelt dem in Kapitel 3.2.3 beschriebenden Plugin-Konzept.
21

3 Konzeption des Monitordienstes
Entfernen von Logik-Strukturen Registrierte Logik-Strukturen können auch wieder
entfernt werden. Hierfür benötigt der Dispatcher lediglich den Namen der Logik-Struktur,
um diese aus dem Logik-Struktur-Register zu löschen. Hierbei muss jedoch vom Benutzer
beachtet werden, dass alle Sensoren und Aktoren der zu entfernenden Logik-Struktur nicht
mehr aktiv sein dürfen oder aus dem Monitordienst gelöscht wurden. Da durch das Löschen
einer Logik-Struktur einzelne Verknüpfungen zwischen Sensoren und Aktoren nicht dem
System nicht mehr bekannt sind, kann es zu Fehlern kommen.
Aktualisieren der Logik-Strukturen Falls Sensoren aus dem Sensorregister des Sensor
Managers oder Aktoren aus dem Aktorregister des Aktor Managers gelöscht wurden,
müssen die Logik-Strukturen angepasst werden. Verknüpfungen zu gelöschten Sensoren und
Aktoren müssen entfernt werden, da es ansonsten zu Fehlern im Ablauf des Monitordienstes
kommen kann, weil die gelöschten Sensoren und Aktoren nicht mehr aufgerufen werden
können.
Weiterleiten der Sensor-Signale Da der Monitordienst mit mehreren Logik-Strukturen
arbeitet, die in dem Dispatcher verwaltet werden, können die Sensoren ihre Signale nicht
direkt an die Logik-Struktur senden, sondern müssen den Dispatcher kontaktieren. Der Dispatcher
empfängt die Signale der Sensoren und leitet sie an die jeweiligen Logik-Strukturen
weiter. Hierfür erfasst der Dispatcher in welchen Logik-Strukturen der signalisierende Sensor
auftritt und leitet das Signal an diese Logik-Strukturen weiter.
3.4 Persistentes Speichern von Ergebnissen
Ein weiterer wichtiger Bereich des Monitordienstes ist das persistente Speichern von Messergebnissen
und Statusmeldungen. Dies dient als Protokollierung des Überwachungsablaufs.
Durch die gespeicherten Messergebnisse, die die Sensoren liefern, können Erfahrungswerte
für das Debugging und die Optimierung des adGSV-Rahmenwerks gewonnen werden. Das
Speichern der Statusmeldungen der Aktoren dient zur Nachvollziehbarkeit der vorgenommenen
Änderungen im Rahmenwerk. Zum Speichern dieser Daten eignen sich verschiedene
Speichermöglichkeiten wie z.B. Datenbanken oder Dateien. Im weiteren Verlauf werden als
Speichermöglichkeit Datenbanken betrachtet, da der Monitordienst Datenbanken zum persistenten
Speichern von Daten nutzt.
Der folgende Abschnitt beschreibt den Aufbau und die Funktion der Komponente im Monitordienst,
die für das persistente Speichern von Daten zuständig ist.
3.4.1 Aufbau und Funktion des Storage-Handlers
Der Storage-Handler stellt die Schnittstelle zwischen den Sensoren bzw. Aktoren und der
Datenbank dar. Die Sensoren bzw. Aktoren haben Zugriff auf den Storage-Handler und
können so die Messergebnisse bzw. die Statusmeldungen in einer Datenbank speichern. Im
Monitordienst wird die Möglichkeit geboten verschiedene Storage-Handler zu nutzen, um
die Auswahl der Speichermöglichkeiten nicht zu beschränken.
Es existiert eine abstrakte Basisklasse des Storage-Handlers, die als Vorlage für weitere
Storage-Handler dienen soll. Die Basisklasse gibt den strukturellen Aufbau der Storage-
22

3.4 Persistentes Speichern von Ergebnissen
Handler vor. In den abgeleiteten Storage-Handlern kann der Zugriff auf verschiedene Speichermöglichkeiten
definiert werden. Das folgende Listing zeigt den strukturellen Aufbau der
Basisklasse des Storage-Handlers in Form eines Pseudocodes.
1 c l a s s S t o r a g e H a n d l e r ( ) :
2 def C r e a t e ( storagename , a r e a=None , i t e m s=None ) :
3 pass
4
5 def D e l e t e ( storagename , a r e a=None , i t e m s=None ) :
6 pass
7
8 def C l e a r ( storagename , a r e a=None ) :
9 pass
10
11 def Read ( storagename , a r e a=None , item=None , c o n d i t i o n=None ) :
12 pass
13
14 def Write ( storagename , v a l u e s , a r e a=None ) :
15 pass
Listing 3.4: Pseudocode der Storage-Handler Basisklasse
In den folgenden Abschnitten wird der strukturelle Aufbau der abstrakten Basisklasse des
Storage-Handlers beschrieben.
Create Im Create Bereich können für die gewählte Möglichkeit zur Speicherung die spezifischen
Abläufe zum Erstellen eines Objektes zur Speicherung definiert werden. Bei einer
Datenbank muss im Create Bereich das Erstellen einer Tabelle definiert werden.
Delete Im Delete Bereich können für die gewählte Möglichkeit zur Speicherung die spezifischen
Abläufe zum Löschen eines Objektes zur Speicherung oder zum Löschen bestimmter
Datensätze definiert werden. Bei einer Datenbank muss im Delete Bereich das Löschen einer
Tabelle oder das Löschen eines bestimmten Datensatzes der Tabelle definiert werden.
Clear Im Clear Bereich können für die gewählte Möglichkeit zur Speicherung die spezifischen
Abläufe zum Löschen der Datensätze definiert werden. Bei einer Datenbank muss im
Clear Bereich das Löschen aller Datensätze einer Tabelle definiert werden.
Read Im Read Bereich können für die gewählte Möglichkeit zur Speicherung die spezifischen
Abläufe zum Lesen der Datensätze definiert werden. Bei einer Datenbank muss im
Read Bereich das Lesen der Datensätze aus einer Tabelle definiert werden.
Write Im Write Bereich können für die gewählte Möglichkeit zur Speicherung die spezifischen
Abläufe zum Schreiben von Datensätzen definiert werden. Bei einer Datenbank muss
im Write Bereich das Schreiben von Datensätzen in eine Tabelle definiert werden.
23

3 Konzeption des Monitordienstes
3.5 Zusammenfassung
Die Komponenten des Monitordienstes verfolgen eine offene Struktur, die es dem Benutzer
ermöglicht den Monitordienst anzupassen und zu erweitern. Neue Sensoren und Aktoren
können erstellt werden und in den Monitordienst geladen werden. Das Plugin-Prinzip erlaubt
es das Hinzufügen und Entfernen von Sensoren und Aktoren dynamisch zur Laufzeit
vorzunehmen. Mit Hilfe der Logik-Strukturen werden die Verknüpfungen zwischen den
Sensoren und Aktoren definiert und sorgen dafür, dass die Sensoren die richtigen Aktoren
ansprechen und auslösen. Das Erstellen neuer Storage-Handler ermöglicht dem Benutzer
eine freie Auswahl der Speicherobjekte, in denen die Messergebnisse und Statusmeldungen
gespeichert werden sollen.
Im folgenden Kapitel wird die Implementierung, sowie die verwendeten Technologien, des
Monitordienstes vorgestellt.
24

4 Architektur und Realisierung des Monitordienstes
Die im vorigen Kapitel beschriebenen Ideen zum Aufbau und zur Funktion des Monitordienstes
wurden implementiert, um den Monitordienst als Überwachungskomponente in das
adGSV-Rahmenwerk zu integrieren.
Im nächsten Abschnitt werden die verwendeten Technologien beschrieben und Entscheidung
zu der jeweiligen Wahl der Technologien begründet. Die Konzeption und der Entwurf des
Monitordienstes wird im Abschnitt 4.2 beschrieben. Abschnitt 4.3 befasst sich mit Erweiterungen
des Monitordienstes, die aus zeitlichen Gründen nicht mehr vorgenommen werden
konnten.
4.1 Technologien
Für die Implementierung des Monitordienstes fiel die Wahl der Programmiersprache auf
Python. Die genutzte Version ist Python 2.4.1. Verschiedene Gründe sprachen für die Nutzung
von Python. Der Monitordienst dient als Erweiterung des adGSV-Rahmenwerks, das
ebenfalls in Python implementiert ist. Durch die Verwendung der selben Programmiersprache
können unnötige Schnittstellen-Klassen zwischen zwei verschiedenen Programmiersprachen
und Inkompatibilitäten vermieden werden. Des weiteren ist Python eine leicht zu
erlernende Programmiersprache mit einer simplen Syntax. Viele Konstrukte, sowie Funktionen
darauf, die in anderen Sprachen implementiert werden müssen, sind in Python bereits
integriert. Der Funktionsumfang von Python ist leicht durch das Installieren weiterer Bibliotheken
erweiterbar.
Um Ergebnisse und Meldungen des Monitordienstes zu speichern, wird eine Datenbank
verwendet. Die Vorteile einer Datenbank gegenüber einer Textdatei liegen in der persistenten
und effizienten Verwaltung von Daten, sowie der einfache Zugriff auf die Daten.
Als Datenbanksystem kommt SQLite 1 zum Einsatz. SQLite speichert die Datenbanken in
Form von Dateien, sodass Server-Applikationen nicht notwendig sind. Für die Integration
von SQLite in Python steht eine Schnittstelle in Form einer nachinstallierbaren Bibliothek
zur Verfügung. Die verwendete Schnittstelle ist die von Gerhard Häring entwickelte PyS-
QLite 2 -API in der Version 2.3.2. PySQLite entspricht weitestgehend den SQL-92 3 Standard.
Der Monitordienst soll über ein Netzwerk entfernt administrierbar sein und mit den Knoten
im adGSV-Rahmenwerk kommunizieren. Die Kommunikation der Knoten im Rahmenwerk
wird mit der Kommunikationsbibliothek Common Object Request Broker Architecture
(CORBA) realisiert. Der Monitordienst nutzt ebenfalls CORBA, um die Kommunikation zu
gewährleisten. Die Object Management Group (OMG) 4 hat die Spezifikation von CORBA
1 SQLite http://www.sqlite.org [08.2006]
2 PySQLite http://initd.org/tracker/pysqlite [08.2006]
3 SQL-92 Standard http://www.contrib.andrew.cmu.edu/ shadow/sql/sql1992.txt [09.2006]
4 OMG http://www.omg.org [07.2006]
25

4 Architektur und Realisierung des Monitordienstes
definiert. Der Monitordienst verwendet, wie das adGSV Rahmenwerk, als CORBA-ORB
omniORB 5 in der Version 4.0.6, sowie omniORBpy, als Python-Anbindung, in der Version
2.6.
4.2 Konzept, Entwurf und Komponenten
Der Monitordienst soll folgenden Anforderungen entsprechen:
ˆ modularer Aufbau und leichte Erweiterbarkeit
ˆ Es soll die Möglichkeit bestehen, einfach neue Sensoren und Aktoren zu erstellen
und dem Monitordienst hinzuzufügen.
ˆ Das einfache Hinzufügen neuer Storage-Handler soll die Möglichkeit bieten Daten
z.B. in Datenbanken, in Textdateien, etc. persistent abspeichern zu können.
ˆ Rekonfiguration zur Laufzeit
ˆ Sensoren sollen zur Laufzeit hinzugefügt oder entfernt werden können.
ˆ Aktoren sollen hinzugefügt oder entfernt werden können.
ˆ Logikstrukturen sollen dem Monitordienst hinzugefügt oder daraus entfernt werden
können.
Die Entwicklung der strukturierten Architektur des Monitordienstes wurde mit Hilfe der
OMG Unified Modelling Language 6 und den von Erich Gamma, Richard Helm, Ralph Johnson
und John Vlissides beschriebenen Entwurfsmustern[GHJV94], sowie den Python Entwurfsmustern
[Sav97], vorgenommen. Die Entwurfsmuster, die als Leitfaden zur Entwicklung
von strukturierten Softwarearchitekturen dienen, sind in drei Bereiche aufgeteilt. In den
Erzeugungsmustern werden verschiedene Arten der Erzeugung von Objekten beschrieben.
Aus diesem Teilbereich der Entwurfsmustern kommen für den Monitordienst die Singletonund
Abstract-Factory-Entwurfsmustern zur Anwendung. Bei dem Singleton-Entwurfsmuster
wird sicher gestellt, dass nur eine Instanz von einer Klasse erstellt wird, auf die global zugegriffen
werden kann. Das Factory-Entwurfsmuster erzeugt Objekte eines bestimmten Typs,
die eine spezialisierte Form dieses Typs darstellen. In dem zweiten Teilbereich der Entwurfsmuster,
den Strukturmustern, werden Vorschläge zur Komposition von Klassen gegeben. Das
Facade-Entwurfsmuster ist ein Teil der Strukturmuster und findet ebenfalls Anwendung im
Monitordienst. Es dient zur Definition von einheitlichen und einfachen Schnittstellen zu
den Schnittstellen eines Subsystems. Die Verhaltensmuster sind der letzte Bereich der Entwurfsmuster
und behandeln die Dynamik, Interaktion und Kommunikation der Objekte
untereinander.
Im Verlauf dieses Kapitels werden die Klassen des Monitordienstes vorgestellt. Dabei wird
nur der konzeptionelle Aspekt betrachtet. Weiterführende Informationen und Details sind
in der API-Dokumentation des Monitordienstes zu finden.
5 omniORB http://omniORB.sourceforge.net [07.2006]
6 OMG UMLhttp://www.uml.org[07.2006]
26

4.2 Konzept, Entwurf und Komponenten
Abbildung 4.1: Klassendiagramm des Monitordienstes
27

4 Architektur und Realisierung des Monitordienstes
Das Klassendiagramm in Abbildung 4.1 zeigt eine Übersicht über die Komponenten des
Monitordienstes und deren Zusammenhang. Nur konzeptionell wichtige Methoden und Attribute
werden dargestellt, um die Übersichtlichkeit des Klassendiagramms zu bewahren.
MonitorController Die MonitorController-Klasse ist die zentrale Schnittstelle
zur Verwaltung des Monitordienstes. Die Komponenten ActuatorManager, Sensor-
Manager, StorageHandler und SensorActuatorLogicDispatcher können über
den Monitor Controller angesteuert werden. Durch die StartSensoring()-Methode werden
per Übergabeparameter ausgewählte Sensoren gestartet. Des weiteren besteht die Möglichkeit
alle im SensorManager registrierten Sensoren zu starten. Analog zu der StartSensoring()-Methode
werden bei der StopSensoring()-Methode per Übergabeparameter entweder
bestimmte oder alle laufende Sensoren angehalten.
1 def Measure ( s e l f ) :
2 t r y :
3 s e l f . g l o b a l l o c k . a c q u i r e ( )
4 s e l f . l o c a l t i m e = l o c a l t i m e ( )
5 s e l f . t i m e = s t r f t i m e ( ”%c ” , s e l f . l o c a l t i m e )
6 f a i l e d n o d e s = [ ]
7 f a i l e d g r o u p = [ ]
8 f a i l e d r e p l i c a s = [ ]
9 i n f o = [ ]
10 groups = s e l f . rpm . GetGroups ( )
11 f o r group i n groups :
12 r e p l i c a s = s e l f . rpm . G e t R e p l i c a s ( group )
13 f o r i t e r a t o r i n r e p l i c a s [ 0 ] . v s d i s p a t c h e r . v o t i n g s t r u c t u r e .
nodes phys :
14 t r y :
15 N e t w o r k i n g C l i e n t . Ping ( n e t r e f e r e n c e=i t e r a t o r . n e t r e f e r e n c e )
16 s e l f . S a v e R e s u l t ( ”node ”+i t e r a t o r . name+” i s o n l i n e ”)
17 except E x c e p t i o n s . ErrorNet , msg :
18 f a i l e d n o d e s += [ i t e r a t o r ]
19 f a i l e d r e p l i c a s +=[ i t e r a t o r . name ]
20 i t e r a t o r . f a i l e d = True
21 i f not group i n i n f o :
22 f a i l e d g r o u p . append ( group )
23 s e l f . S a v e R e s u l t ( ”node ”+i t e r a t o r . name+” f a i l e d ”)
24 i n f o = [ f a i l e d g r o u p , f a i l e d r e p l i c a s ]
25 i f l e n ( f a i l e d n o d e s ) > 0 :
26 t r y :
27 s e l f . l o g d i s p . PushMessage ( s e l f . name , i n f o )
28 s e l f . l o g d i s p . S e n s o r S i g n a l ( s e l f . name )
29 except ( E x c e p t i o n s . ErrorBusy , E x c e p t i o n s . ErrorNoQuorum ,
E x c e p t i o n s . E r r o r I m p o s s i b l e ) :
30 s y s . e x i t ( 1 )
31 f i n a l l y :
32 s e l f . g l o b a l l o c k . r e l e a s e ( )
33
34 def S a v e R e s u l t ( s e l f , msg ) :
35 s e l f . s t o r a g e . Write ( ”/home/ monitor . db ” , ” ’ ”+s e l f . t i m e+” ’ , ’ ”+msg+” ’ ” ,
”SensorEPOCH ”)
Listing 4.1: Sensor für den Epochenwechsel
28

4.2 Konzept, Entwurf und Komponenten
Sensor Die abstrakte Basisklasse Sensor dient als Vorlage zur Implementierung von
Sensoren. Um einen neuen Sensor zu definieren, müssen die Methoden Measure() und SaveResult()
von der abgeleiteten Klasse implementiert werden. In der Methode Measure()
müssen für die jeweilige Aufgabe des Sensors die Messbereiche, Zeitfaktoren usw. definiert
und implementiert werden. Um die Messergebnisse zu speichern, muss in der SaveResult()-
Methode der gewünschte Storage-Handler angesprochen werden.
Das Listing 4.1 zeigt die Methoden Measure() und SaveResult() der SensorEPOCH-
Klasse. Die Measure()-Methode des Sensors testet, ob die Knoten der Voting Strukturen
online sind oder nicht. Die SaveResult()-Methode speichert das Ergebnis in der Datenbank.
Zunächst werden alle registrierten Voting Strukturen mit der Methode GetGroups() in Zeile
10 ermittelt. In den Zeilen 12 und 13 werden alle zu den Voting Strukturen gehörenden
Replikate, sowie deren Knoten ermittelt. Mit der Methode Ping() in Zeile 15 wird getestet,
ob die Knoten online oder offline sind. Die fehlgeschlagene Knoten werden in den Zeilen
18 bis 22 registriert. Falls fehlgeschlagene Knoten registriert wurden, wird der zum SensorEPOCH
zugehörige Aktor durch ein Signal mit der Methode SensorSignal() in Zeile
28 aktiviert. Die Funktion SaveResult() in den Zeilen 34 und 35 speichert das übergebene
Messergebnis in der Datenbank.
1 def R e c o n f i g u r e ( s e l f ) :
2 t r y :
3 s e l f . g l o b a l l o c k . a c q u i r e ( )
4 s e l f . t i m e = s t r f t i m e ( ”%c ” , l o c a l t i m e ( ) )
5 i n f o = s e l f . l o g d i s p . PullMessage ( ”EPOCH”)
6 f a i l e d g r o u p s = i n f o [ 0 ]
7 f a i l e d n o d e s = i n f o [ 1 ]
8 s e e k i n d e x = True
9 i n d e x = 0
10 f o r group i n f a i l e d g r o u p s :
11 r e p l i c a s = s e l f . rpm . G e t R e p l i c a s ( group )
12 while s e e k i n d e x == True :
13 i f i n d e x == l e n ( r e p l i c a s ) :
14 r a i s e E x c e p t i o n s . E r r o r I m p o s s i b l e , ” a l l nodes i n group ’% s ’
a r e f a i l e d n o d e s . can ’ t do epoch change . ” % group
15 i f r e p l i c a s [ i n d e x ] . name i n f a i l e d n o d e s : i n d e x += 1
16 e l s e : s e e k i n d e x = F a l s e
17 t r y :
18 r e p l i c a s [ i n d e x ] . EpochChange ( )
19 s e l f . SaveReport ( ”group ”+group+”: epoch changed ”)
20 except ( E x c e p t i o n s . ErrorBusy , E x c e p t i o n s . ErrorNoQuorum ,
E x c e p t i o n s . E r r o r I m p o s s i b l e ) :
21 s e l f . SaveReport ( ”group ”+group+”: epoch change f a i l e d ”)
22 s y s . e x i t ( 1 )
23 f i n a l l y :
24 s e l f . g l o b a l l o c k . r e l e a s e ( )
25 def SaveReport ( s e l f , msg ) :
26 s e l f . s t o r a g e . Write ( ”/home/ monitor . db ” , ” ’ ”+s e l f . t i m e+” ’ , ’ ”+
msg+” ’ ” , ”ActuatorEPOCH ”)
Listing 4.2: Aktor für den Epochenwechsel
29

4 Architektur und Realisierung des Monitordienstes
Actuator Die abstrakte Basisklasse Actuator dient als Vorlage zur Implementierung
von Aktoren. Um einen neuen Aktor zu definieren, müssen die Methoden Reconfigure() und
SaveReport() von der abgeleiteten Klasse implementiert werden. In der Methode Reconfigure()
müssen für die jeweilige Aufgabe des Aktors die Änderungen, die der Aktor durchführen
soll, definiert und implementiert werden. Um die Statusmeldungen zu speichern, muss in
der SaveReport()-Methode der gewünschte Storage-Handler angesprochen werden.
Das Listing 4.2 zeigt die Methoden Reconfigure() und SaveReport() der ActuatorE-
POCH-Klasse, die, falls der zugehörige Sensor fehlgeschlagene Knoten registriert hat, einen
Epochenwechsel initialisiert. Die Reconfigure()-Methode des Aktors führt alle dafür notwendigen
Operationen durch. Die SaveReport()-Methode speichert eine Meldung in der Datenbank,
ob der Epochenwechsel erfolgreich war oder nicht.
Als erstes werden die Informationen zu den fehlgeschlagenen Knoten geholt (Zeile 6 bis 8).
Danach werden die Knoten einer betroffenden Voting Struktur mit der Methode GetReplicas()
ermittelt. Es wird ein Abgleich gemacht, welches Replikat zum Initialisieren eines
Epochenwechsels geeignet ist (Zeile 13 bis 17). Die Methode EpochChange() in Zeile 19 initialisiert
den Epochenwechsel. Die Funktion SaveReport() in den Zeilen 27 und 28 speichert
die übergebene Statusmeldung in der Datenbank.
SensorManager und ActuatorManager Die Sensor- und Actuator-Instanzen werden
in der SensorManager- und ActuatorManager-Klasse verwaltet. Das Hinzufügen
neuer Sensoren und Aktoren bzw. das Entfernen registrierter Sensoren und Aktoren
wird in Form eines Plugin-Mechanismus realisiert. Zur Laufzeit können mittels der Load()-
Methode neue Sensoren und Aktoren bei dem jeweiligen Manager registriert werden und
mittels der Unload()-Methode können geladene Sensoren und Aktoren entfernt werden. Die
SensorManager- und ActuatorManager-Klasse besitzen jeweils ein Sensor- und ein
Aktorregister, in dem die zur Verfügung stehenden Sensoren bzw. Aktoren aufgelistet sind.
SensorActuatorLogic Die Klasse SensorActuatorLogic repräsentiert die Beziehungen
zwischen Sensoren und Aktoren. Hierfür werden die Namen der Sensoren und der
Aktoren, die zu einer Logikstruktur gehören, sowie deren Verknüpfungen zueinander, in der
SensorActuatorLogic gespeichert. Mit der AddEdge()-Methode wird eine neue Verknüpfung
zwischen einem Sensor und einem Aktor zu der Logik-Struktur in der SensorActuatorLogic
hinzugefügt. Die Signal()-Methode ermittelt zu dem per Übergabeparameter
gegebenen Sensor die passenden Aktoren in der Logik-Struktur.
SensorActuatorLogicDispatcher Zur Verwaltung der Logikstrukturen wird die SensorActuatorLogicDispatcher-Klasse
verwendet. Diese Klasse besitzt ein Logikstruktur-
Register, in dem alle SensorActuatorLogic-Instanzen aufgelistet sind. Wenn ein Sensor
einen Aktor triggern will, dann muss der Sensor die SensorSignal()-Methode aufrufen. Der
Dispatcher ermittelt daraufhin, ob es zu dem Sensor eine Logikstruktur gibt.
Die Load()-Methode ermöglicht das Laden von Logikstrukturen. Hierfür wird eine SensorActuatorLogic-Instanz
erzeugt, in der die zu Logikstruktur gehörenden Sensoren
und Aktoren, sowie deren Verknüpfungen zueinander, gespeichert werden. Die neu erstellte
SensorActuatorLogic-Instanz wird danach in dem Logikstruktur-Register von der
30

4.2 Konzept, Entwurf und Komponenten
SensorActuatorLogicDispatcher-Instanz registriert. Das eigentliche Laden der Logikstrukturen
wird von der Load()-Methode an spezielle, für ein bestimmtes Datenformat
angelegte Methoden weitergeleitet. Im Monitordienst wurde exemplarisch die Unterstützung
der DOT -Beschreibungssprache implementiert. Es können weitere Format spezifische
Load-Methoden implementiert werden, um diverse Dateiformate zu unterstützen. Alle unterstützen
Formate müssen in types definiert werden.
Das folgende Listing zeigt die Definition und Syntax einer Logikstruktur mit vier Sensoren
und drei Aktoren.
1 d i g r a p h ”L o g i c S t r u c t u r e 1 ” {
2
3 UPTIME−>CHANGE;
4 PING−>CHANGE;
5 FAILURE−>CHANGE;
6 FAILURE−>NEWSTRUCTURE;
7 EPOCH−>EPOCH;
8 }
Listing 4.3: Definition einer Logikstruktur
In der Zeile 1 ist das Schlüsselwort digraph und der Name der Logikstruktur zu finden.
Danach folgt eine öffnende geschweifte Klammer, die den Definitionsteil einleitet. Um eine
Relation zwischen einem Sensor und einem Aktor zu definieren, muss auf der linken Seite
des Pfeils der Name des Sensors und auf der rechte Seite des Pfeils der Name des Aktors,
der von dem Sensor ausgelöst werden soll, notiert werden. In den Zeilen 3 bis 7 sind mehrere
Relationen zwischen Sensoren und Aktoren zu sehen. Die schließende geschweifte Klammer
in Zeile 8 schließt den Definitionsteil ab.
In der LogicStructure1 werden die Verknüpfungen zwischen den Sensoren UPTIME, PING,
FAILURE, EPOCH und den Aktoren CHANGE, NEWSTRUCTURE, EPOCH definiert.
Es repräsentiert einen Graphen mit den Sensoren als Wurzelknoten, den Pfeilen als Übergänge
und den Aktoren als Blattknoten. Zeile 3 in dem Listing 4.3 definiert, dass der Sensor
UPTIME den Aktor CHANGE auslösen soll. In den Zeilen 4 bis 7 des Listings werden analog
die weiteren Übergänge zwischen den Sensoren und Aktoren definiert. Die Sensoren
UPTIME, PING, FAILURE und der Aktor CHANGE bilden eine n:1 -Beziehung. Die Verknüpfungen
in Zeile 6 und 7 sind jeweils 1:1 -Beziehungen.
StorageHandler und StorageSQL Die StorageHandler-Klasse ist eine abstrakte
Basisklasse, die die Vorlage für verschiedene Storage-Handler definiert. Von der StorageHandler
abgeleitete Klassen müssen die Methoden Create(), Delete(), Read(), Write()
und Clear() für den jeweiligen Speichertyp implementieren. Diese Methoden dienen zum Erzeugen
und Löschen der Dateien zur Speicherung, sowie zum Lesen, Schreiben und Löschen
von Daten. Die Klasse StorageSQL ist von der StorageHandler-Klasse abgeleitet und
implementiert die Verwendung einer Datenbank zum persistenten Speichern von Messergebnissen
und Statusmeldungen. Die verwendete Datenbankabfragesprache ist SQLite, die bei
dem Monitordienst im Zusammenhang mit Python mit Hilfe der PySQLite-API benutzt
wird.
31

4 Architektur und Realisierung des Monitordienstes
NetworkingClient und NetworkingServer NetworkingClient und NetworkingServer
sind Klassen zur Kapselung der CORBA-Anbindung des adGSV- Rahmenwerks.
Für die Kommunikation zwischen dem Monitordienst und dem adGSV-Rahmenwerk
werden Methoden benutzt, die in beiden Klassen implementiert sind. Des weiteren sind in
NetworkingClient und NetworkingServer Methoden implementiert, um den Monitordienst
in einem Netzwerk entfernt zu administrieren.
4.3 Erweiterungen
In den nachfolgenden Abschnitten werden Erweiterungen des Monitordienstes vorgestellt,
die im zeitlichen Rahmen dieser Arbeit nicht mehr realisiert wurden.
Asynchrones Triggern von Logikstrukturen Zur Zeit arbeitet der SensorActuatorLogicDispatcher
Signale von Sensoren synchron ab. Es werden nacheinander alle
registrierten Logik-Strukturen nach dem Sensor, der ein Signal gesendet hat, durchsucht.
Bei einem Suchtreffer wird das Signal an die ermittelte Logik-Struktur weitergeleitet. Erst
wenn die Logik-Struktur das Signal verarbeitet hat, kann der SensorActuatorLogic-
Dispatcher nach weiteren Strukturen suchen. Durch das Ändern der Arbeitsweise des
SensorActuatorLogicDispatchers, indem z.B. die Logikstrukturen als Threads implementiert
werden, könnte eventuell eine Performance-Verbesserung erreicht werden.
Auswertung von Messergebnissen Auf Basis gegebener Informationen zu Replikationsverfahren
(z.B. in einer Datenbank) könnten die Messergebnisse der Sensoren automatisch
ausgewertet werden und in Form einer Hilfestellung zur Konfiguration dem Benutzer
des adGSV-Rahmenwerks zur Verfügung gestellt werden. So könnte der Benutzer anhand
der aus den Messergebnissen erstellten Konfigurationsvorschlägen das adGSV-Rahmenwerk
schnell und einfach neu konfigurieren. Die mühsame Auswertung der protokollierten Messergebnisse
müsste nicht vom Benutzer selber durchgeführt werden.
4.4 Zusammenfassung
Um eine einfache Integration und hohe Kompatibilität des Monitordienstes zum adGSV-
Rahmenwerk zu gewährleisten, mussten einige konzeptionelle Vorgaben des Rahmenwerks
beachtet werden. Der Monitordienst entspricht den geforderten Aspekten und somit wurde
das Ziel, den Monitordienst als Überwachungskomponente in das adGSV-Rahmenwerk
zu integrieren, erreicht. Die Konzeption als modulare Architektur sorgt für eine einfache
Erweiterbarkeit, Wartung und Austausch des Monitordienstes.
32

5 Zusammenfassung und Ausblick
Replikationstechniken verfolgen das Ziel eine höhere Verfügbarkeit von Daten zu gewährleisten.
Um dieses Ziel zu erreichen werden verschiedene Replikationsstrategien verwendet. Es
wird zwischen zwei verschiedenen Arten von Replikationsverfahren unterschieden. Es gibt
statische und dynamische Replikationsverfahren. Bei den statischen Replikationsverfahren
muss am Anfang die Anzahl der teilnehmenden Knoten definiert werden. Diese Anzahl ist fix
und darf nicht verändert werden. Statische Verfahren können nicht auf Veränderungen der
Knotenanzahl reagieren und so kann es passieren, dass der Zugriff auf das Datum nicht mehr
gewährleistet werden kann. Dynamische Replikationsverfahren erweitern die statischen Verfahren
durch Dynamikeigenschaften. Auf Ausfälle oder das Hinzufügen von Knoten können
die dynamischen Verfahren reagieren und passen die Strategie des Replikationsverfahrens
an.
Ein weiteres Verfahren, was mehr Flexibilität bietet, ist das von Dipl.-Inform. Christian
Storm entwickelte adaptable dynamic General Structure Voting-Verfahren. Das adGSV-
Verfahren basiert wie das dGSV-Verfahren auf die Verwendung von Voting-Strukturen und
Epochen. Durch die Möglichkeit zur Laufzeit Replikate in eine Voting-Struktur zu integrieren
oder aus einer Voting-Struktur zu entfernen, bietet das adGSV-Verfahren eine flexible
Verwaltung von Replikaten. Des weiteren können inhomogene Strategien verwendet werden,
in dem je nach Knotenanzahl eine andere Strategie verwendet wird.
Der in dieser Arbeit vorgestellte Monitordienst bietet die Möglichkeit das adGSV- Rahmenwerk
durch Sensoren zu überwachen und bei Ereignissen durch Aktoren einzugreifen.
Es können neue Sensoren und Aktoren implementiert und dem Monitordienst zur Verfügung
gestellt werden. Die offene Struktur dieser Komponenten bietet dabei dem Benutzer
jegliche Form von Überwachungs- und Steuerungsaufgaben in den Sensoren und Aktoren
zu definieren. Zudem können auch die logischen Verknüpfungen zwischen den Sensoren und
Aktoren angepasst und erweitert werden. Messergebnisse und Statusmeldungen lassen sich
in der Datenbank persistent abspeichern und werden somit protokolliert.
Die Optimierung der Performance, sowie das Auswerten der Messergebnisse, konnte nicht
mehr realisiert werden und bleibt Gegenstand weiterer Arbeiten.
33

Literaturverzeichnis
[AAC90] Ammar, Mostafa H. ; Ahamad, Mustaque ; Cheung, Shun Y.: The Grid Protocol:
A High Performance Scheme for Maintaining Replicated Data. In: Proceedings
of the 16th Very Large Data Bases Conference (VLDB’90), 1990, S. 243–254
[AE92] Agrawal, D. ; El Abbadi, A.: The Generalized Tree Quorum Protocol: An Efficient
Approach for Managing Replicated Data. In: ACM Transactions on Database
Systems 17, 1992, S. 689–717
[BHG87] Bernstein, Philip A. ; Hadzilacos, Vassos ; Goodman, Nathan: Concurrency
Control and Recovery in Database Systems. Addison-Wesley, 1987
[GB85] Garcia-Molina, Hector ; Barbara, Daniel: How to Assign Votes in a Distributed
System. In: Journal of the ACM 32, 1985, S. 841–860
[GHJV94] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994
[Gif79] Gifford, D. K.: Weighted Voting for Replicated Data. In: Proceedings of the 7th
Symposium on Operating Systems Principles (SOSP’79) Bd. 13, 1979, S. 150–161
[HHB96] Helal, Abdelsalam A. ; Heddaya, Abdelsalam A. ; Bhargava, Bharat B.:
Replication Techniques in Distributed Systems. Kluwer Academic Press, 1996
[Lae91] Laeuchli, P.: Algorithmische Graphentheorie. Birkhaeuser, 1991
[LR93] Lazowska, Edward D. ; Rabinovich, Michael: Asynchronous Epoch Management
in Replicated Databases. In: Proceedings of the International Workshop on
Distributed Algorithms (WDAG’93), 1993, S. 115–128
[Lun01] Lundh, Fredrik: Python Standard Library. O’Reilly & Associates, Inc., 2001
[Mar03] Martelli, A.: Python in a Nutshell. O’Reilly & Associates, Inc., 2003
[MN92] Mizuno, Masaaki ; Neilsen, Mitchell L.:
Quorum Structures. 1992
Measures of Node Importance for
[NS96] Naegler, G. ; Stopp, F.: Graphen und Anwendungen. Teubner, 1996
[Sav97] Savikko, Vespe: Design Patters in Python. In: Proceedings of the 6th International
Python Conference, 1997
[Sch01] Schöning, Uwe: Theoretische Informatik — kurzgefaßt. Spektrum Akademischer
Verlag GmbH, 2001
[Ske81] Skeen, Dale: Non-Blocking Commit Protocols. In: Proceedings of the ACM SIG-
MOD Conference, 1981
34

Literaturverzeichnis
[SS83] Schlichting, R. D. ; Schneider, F. B.: Fail-Stop Processors: An Approach to
Designing Fault-Tolerant Computer Systems. 1983. – 222–238 S.
[ST06] Storm, Christian ; Theel, Oliver: Highly Adaptable Dynamic Quorum Schemes
for Managing Replicated Data. In: Proceedings of the 1st International Conference
on Availability, Reliability and Security (ARES’06) IEEE Computer Society, IEEE
Computer Society Press, April 2006, S. 245–253
[Sto06] Storm, Christian: Konzeption und Implementierung eines Rahmenwerkes für
adaptiv-dynamische Replikationsstrategien. Carl von Ossietzky Universität Oldenburg,
Department für Informatik / Systemsoftware und Verteilte Systeme, Diplomarbeit,
2006. – Diplomarbeit
[The93] Theel, Oliver: General Structured Voting: A Flexible Framework for Modelling
Cooperations. In: Proceedings of the 13th International Conference on Distributed
Computing Systems (ICDCS’93) IEEE Computer Society, 1993, S. 227–236
[TS98] Theel, Oliver ; Strauss, Thomas: Automatic Generation of Dynamic Coteriebased
Replication Schemes. University of Darmstadt, Department of Computer
Science, Institute for System Architecture, Diplomarbeit, 1998. – Forschungsbericht
[TS99] Theel, Oliver ; Strauss, Thomas: An Excursion to the Zoo of Dynamic Coteriebased
Replication Schemes. In: Proceedings of the 28th International Conference
on Parallel Processing (ICPP’99), 1999, S. 344–352
35

A Handbuch
Das Handbuch dient als Hilfestellung zur Benutzung des Monitordienstes. Es bietet eine
kurze Beschreibung der Funktionen des Monitordienstes. Detailliertere Informationen können
in der API-Dokumentation des Monitordienstes nachgeschlagen werden.
In dem folgenden Kapitel wird erklärt, wie der Monitordienst installiert werden kann. Danach
werden in Kapitel A.2 die ersten Schritte, wie das Starten des Systems, gezeigt. Die
Kapitel A.3, A.4 und A.5 erläutern alle wichtigen Funktionen, wie das Erstellen, Hinzufügen
und Entfernen, von Sensoren, Aktoren und Logik-Strukturen. Der Funktionsumfang
des Storage-Handlers wird in Kapitel A.6 beschrieben. Zuletzt wird in Kapitel A.7 erklärt
wie man bestimmte Informationen von dem Monitordienst abfragen kann.
A.1 Installation
Die Anweisungen der Installation beziehen sich auf Linux. Um den Monitordienst nutzen
zu können, muss zunächst das adGSV-Rahmenwerk installiert werden. Informationen zu
der Installation des Rahmenwerks sind den Installationsanweisungen der Dokumentation
des Rahmenwerks zu entnehmen. Der Monitordienst basiert auf den selben Systemvoraussetzung
wie das adGSV-Rahmenwerk. Es muss zusätzlich nur noch die Python Bibliothek
PySQLite 1 in der Version 2.3.2 installiert werden. Der Monitordienst kann in einem beliebigen
Verzeichnis abgelegt werden. Am besten jedoch ist es den Monitordienst im adGSV-
Rahmenwerk Verzeichnis abzulegen.
$RIPLEYDIR/monitor
Danach muss der Monitordienst nur noch zu der Umgebungsvariable PYTHONPATH hinzugefügt
werden und dann ist die Installation abgeschlossen.
export PYTHONPATH=$PYTHONPATH:$MONITORPATH
A.2 Erste Schritte
Dieses Kapitel beschreibt die ersten Schritte, die getätigt werden müssen, um das adGSV-
Rahmenwerk und danach den Monitordienst zu starten.
A.2.1 adGSV-Rahmenwerk starten
Damit das adGSV-Rahmenwerk gestartet werden kann, muss zunächst omniORB 2 , was
als CORBA-ORB dient, gestartet werden. Der dafür zuständige Befehl lautet omniNames
1 PySQLite http://initd.org/tracker/pysqlite [08.2006]
2 omniORB http://omniORB.sourceforge.net [07.2006]
36

A.3 Sensoren
-start. Danach kann mit dem Befehl python Ripley.py das adGSV-Rahmenwerk gestartet
werden und man gelangt in den Konsolenmodus.
A.2.2 Monitordienst starten
Wenn man sich auf der Konsole des adGSV-Rahmenwerk befindet, kann man den Monitordienst
starten. Als erstes muss die Server-Seite des Monitordienst mit dem Befehl
start monitor server gestartet werden. Wenn dies geschehen ist, kann man auf einem beliebigen
Rechner im Netzwerk die Client-Seite des Monitordienstes starten. Dies wird mit
dem Befehl start monitor client getan. Nun kann man den Monitordienst vom Client aus
Steuern.
A.3 Sensoren
Sensoren sind die Komponenten des Monitordienstes, die zur Überwachung des adGSV-
Rahmenwerks dienen. Die folgenden Kapitel beschreiben wie neue Sensoren erstellt und
dem Monitordienst hinzugefügt werden können. Des weiteren wird erläutert wie im Monitordienst
registrierte Sensoren entfernt werden können und wie Sensoren gestartet und
gestoppt werden.
A.3.1 Erstellen eines neuen Sensors
Für die Erstellung eines neuen Sensors muss von der abstrakten Basisklasse eine weitere
Klasse abgeleitet werden. Danach kann die abgeleitete Klasse je nach Aufgabenbereich
angepasst werden. Im Init-Bereich können benötigte Variablen und Attribute initialisiert
werden. Sobald dies getan wurde, kommt der wichtigste Punkt der Anpassung des neuen
Sensors. In der Methode Measure() müssen alle notwendigen Funktionen implementiert und
aufgerufen werden, die für den Aufgabenbereich benötigt werden. Das adGSV-Rahmenwerk
stellt bereits eine Vielzahl von Funktionen zur Verfügung. Weitere Informationen hierzu
sind aus der API-Dokumentation des Rahmenwerks zu entnehmen. Nachdem die Measure()-Methode
implementiert wurde, kann die SaveResult()-Methode angepasst werden. Hier
kann ein gewünschter Storage Handler angesteuert werden, um die Messergebnisse des Sensors
zu speichern.
A.3.2 Hinzufügen eines neuen Sensors
Neu erstellte Sensoren müssen, damit sie benutzt werden können, zu dem Monitordienst
hinzugefügt werden. Hierfür muss in der Konsole der Befehl load sensor -p PFAD -n NA-
ME eingegeben werden. Bei der Option -p muss der Pfad des Sensors übergeben werden.
Die Option -n gibt den Namen der Sensordatei an. Bei dem Namen ist zu beachten, dass die
Endung der Datei weggelassen wird. Folgendes Beispiel zeigt, wie man einen neuen Sensor
dem Monitordienst hinzufügt:
load sensor -p /home/user -n SensorPING
37

A Handbuch
A.3.3 Entfernen eines registrierten Sensors
Registrierte Sensoren können aus dem Monitordienst entfernt werden. Hier ist zu beachten,
dass der Sensor nur aus dem Register der Sensor Manager gelöscht wird und so dem
Monitordienst nicht mehr zur Verfügung steht. Die Sensordatei bleibt auf dem Datenträger
erhalten. Um einen Sensor zu entfernen, muss in der Konsole der Befehl unload sensor -n
NAME eingegeben werden. Bei der Option -n muss der registrierte Name des Sensors und
nicht der Dateiname angegeben werden. Das folgende Beispiel zeigt, wie man einen registrierten
Sensor aus dem Monitordienst entfernt:
unload sensor -n PING
A.3.4 Sensoren starten und stoppen
Damit ein Sensor seine Arbeit aufnimmt, muss dieser erst gestartet werden. Um einen Sensor
zu starten, muss in der Konsole der Befehl start sensoring -n NAME eingegeben werden.
Bei der Option -n muss der registrierte Name des Sensors und nicht der Dateiname angegeben
werden. Wenn man die Option -n ALL wählt, dann werden alle im Sensor Manager
registrierten Sensoren gestartet. Das folgende Beispiel zeigt, wie man einen Sensor startet:
start sensoring -n PING
Laufende Sensoren können mit dem Befehl stop sensoring -n NAME gestoppt werden. Bei
der Option -n muss der registrierte Name des Sensors und nicht der Dateiname angegeben
werden. Wenn man die Option -n ALL wählt, dann werden alle laufenden Sensoren
gestoppt. Das folgende Beispiel zeigt, wie man einen Sensor stoppt:
stop sensoring -n PING
A.4 Aktoren
Aktoren sind die Komponenten des Monitordienstes, die zur Ansteuerung des adGSV-
Rahmenwerks dienen. Die folgenden Kapitel beschreiben wie neue Aktoren erstellt und
dem Monitordienst hinzugefügt werden können. Des weiteren wird erläutert wie im Monitordienst
registrierte Aktoren entfernt werden können.
A.4.1 Erstellen eines neuen Aktors
Für die Erstellung eines neuen Aktors muss von der abstrakten Basisklasse eine weitere Klasse
abgeleitet werden. Danach kann die abgeleitete Klasse je nach Aufgabenbereich angepasst
werden. Im Init-Bereich können benötigte Variablen und Attribute initialisiert werden. Sobald
dies getan wurde, kommt der wichtigste Punkt der Anpassung des neuen Aktors. In der
Methode Reconfigure() müssen alle notwendigen Funktionen implementiert und aufgerufen
werden, die für den Aufgabenbereich benötigt werden. Das adGSV-Rahmenwerk stellt bereits
eine Vielzahl von Funktionen zur Verfügung. Weitere Informationen hierzu sind aus der
API-Dokumentation des Rahmenwerks zu entnehmen. Nachdem die Reconfigure()-Methode
38

A.5 Logik-Strukturen
implementiert wurde, kann die SaveReport()-Methode angepasst werden. Hier kann ein gewünschter
Storage-Handler angesteuert werden, um die definierten Meldungen des Aktors
zu speichern.
A.4.2 Hinzufügen eines neuen Aktors
Neu erstellte Aktoren müssen, damit sie benutzt werden können, zu dem Monitordienst hinzugefügt
werden. Hierfür muss in der Konsole der Befehl load actuator -p PFAD -n NAME
eingegeben werden. Bei der Option -p muss der Pfad des Aktors übergeben werden. Die
Option -n gibt den Namen der Aktordatei an. Bei dem Namen ist zu beachten, dass die
Endung der Datei weggelassen wird. Folgendes Beispiel zeigt, wie man einen neuen Aktor
dem Monitordienst hinzufügt:
load actuator -p /home/user -n ActuatorCHANGE
A.4.3 Entfernen eines registrierten Aktors
Registrierte Aktoren können aus dem Monitordienst entfernt werden. Hier ist zu beachten,
dass der Aktor nur aus dem Register der Actuator Manager gelöscht wird und so dem
Monitordienst nicht mehr zur Verfügung steht. Die Aktordatei bleibt auf dem Datenträger
erhalten. Um einen Aktor zu entfernen, muss in der Konsole der Befehl unload actuator
-n NAME eingegeben werden. Bei der Option -n muss der registrierte Name des Aktors
und nicht der Dateiname angegeben werden. Das folgende Beispiel zeigt, wie man einen
registrierten Aktor aus dem Monitordienst entfernt:
unload actuator -n CHANGE
A.5 Logik-Strukturen
Logik-Strukturen beinhalten die logischen Verknüpfungen zwischen den Sensoren und Aktoren.
Die folgenden Kapitel beschreiben wie neue Logik-Strukturen erstellt und dem Monitordienst
hinzugefügt werden können. Des weiteren wird erläutert wie im Monitordienst
registrierte Logik-Strukturen entfernt werden können.
A.5.1 Erstellen einer neuen Logik-Struktur
Logik-Strukturen müssen in Konfigurationsdateien mit Hilfe einer bestimmten Beschreibungssprache
definiert werden. Zur Zeit unterstützt der Monitordienst lediglich die DOT -
Beschreibungssprache von GraphViz 3 . Es besteht die Möglichkeit weitere Beschreibungssprachen
zu nutzen. Hierfür müssen neue Loader implementiert werden, die die neuen Beschreibungssprachen
unterstützen. Die neuen Beschreibungssprachen müssen in dem Attribut
types definiert werden. Im folgenden wird das Erstellen einer neuen Logik-Struktur mit
Hilfe der DOT-Beschreibungssprache erläutert.
3 GraphVizhttp://www.graphviz.org[08.2006]
39

A Handbuch
Das folgende Listing zeigt die Definition und Syntax einer Logikstruktur mit vier Sensoren
und drei Aktoren.
1 d i g r a p h ”L o g i c S t r u c t u r e 1 ” {
2
3 UPTIME−>CHANGE;
4 PING−>CHANGE;
5 FAILURE−>CHANGE;
6 FAILURE−>NEWSTRUCTURE;
7 EPOCH−>EPOCH;
8 }
Listing A.1: Definition einer Logikstruktur
In der Zeile 1 ist das Schlüsselwort digraph und der Name der Logikstruktur zu finden.
Danach folgt eine öffnende geschweifte Klammer, die den Definitionsteil einleitet. Um eine
Relation zwischen einem Sensor und einem Aktor zu definieren, muss auf der linken Seite
des Pfeils der Name des Sensors und auf der rechte Seite des Pfeils der Name des Aktors,
der von dem Sensor ausgelöst werden soll, notiert werden. In den Zeilen 3 bis 7 sind mehrere
Relationen zwischen Sensoren und Aktoren zu sehen. Die schließende geschweifte Klammer
in Zeile 8 schließt den Definitionsteil ab.
A.5.2 Hinzufügen einer neuen Logik-Struktur
Neu erstellte Logik-Strukturen müssen, damit sie benutzt werden können, zu dem Monitordienst
hinzugefügt werden. Hierfür muss in der Konsole der Befehl load structure -p PFAD
-n NAME eingegeben werden. Bei der Option -p muss der Pfad der Logik-Struktur übergeben
werden. Die Option -n gibt den Namen der Konfigurationsdatei an. Folgendes Beispiel
zeigt, wie man eine neue Logik-Struktur dem Monitordienst hinzufügt:
load structure -p /home/user -n LogicStructure1.dot
A.5.3 Entfernen einer registrierten Logik-Struktur
Registrierte Logik-Strukturen können aus dem Monitordienst entfernt werden. Hier ist zu
beachten, dass die Logik-Struktur nur aus dem Register der Sensor Actuator Logic Dispatcher
gelöscht wird und so dem Monitordienst nicht mehr zur Verfügung steht. Die Konfigurationsdatei
bleibt auf dem Datenträger erhalten. Um eine Logik-Struktur zu entfernen,
muss in der Konsole der Befehl unload structure -n NAME eingegeben werden. Bei der
Option -n muss der registrierte Name der Logik-Struktur und nicht der Dateiname angegeben
werden. Das folgende Beispiel zeigt, wie man eine registrierte Logik-Struktur aus dem
Monitordienst entfernt:
unload structure -n LogicStructure1
A.6 Funktionen des Storage-Handlers
In der Konsole stehen folgende Operationen des Storage-Handlers zur Verfügung:
40

A.6 Funktionen des Storage-Handlers
ˆ Anlegen einer Datenbank
ˆ Löschen eines Datenbank
ˆ Löschen aller Datensätze einer Datenbank
ˆ Lesen einer Datenbank
Die folgenden Abschnitte beschreiben die Funktionen der o.g. Operationen des Storage-
Handlers. Da zur Zeit nur ein Storage-Handler für die Verwaltung von Datenbanken im
Monitordienst existiert, basieren die Beispiele auf einer Datenbank.
Anlegen einer Datenbank Zum Anlegen einer Datenbank muss in der Konsole der
Befehl create storage eingegeben werden. Dieser Befehl besitzt mehrere Optionen, mit denen
weitere Informationen für die Erstellung übergeben werden können. Mit der Option
-l SPEICHERORT wird der Pfad und der Name der Datenbank definiert. Die Option -a
BEREICH übergibt den Namen eines Bereichs. Bei einer Datenbank wird bei dieser Option
der Name einer Tabelle übergeben. Mit der Option -t TRUE TAGS können weitere
Unterteilungen des Bereichs vorgenommen werden. Bei einer Datenbank werden hier die
Namen und der Inhaltstyp der Spalten übergeben. Das folgende Beispiel zeigt den Befehl
zur Erstellung einer Datenbankdatei mit einer Tabelle, die zwei Spalten besitzt:
create storage -l /Test.db -a Table1 -t TRUE Sensor=TEXT Messergebnis=TEXT
Löschen einer Datenbank Beim Löschen stehen drei Varianten zur Verfügung. Es kann
die gesamte Datenbank mit dem Befehl delete storage -l OBJEKT gelöscht werden. Bei der
Option -l muss der Pfad und der Name der Datenbank übergeben werden. Soll ein Bereich
in der Datenbank gelöscht werden, muss zusätzlich zur -l Option mit -a BEREICH der zu
löschende Bereich angegeben werden. Fügt man zu den Optionen -l und -a noch die Option
-t TRUE BEDINGUNG hinzu, können einzelne Datensätze, die der Bedingung entsprechen
gelöscht werden. Folgende Beispiele zeigen die verschiedenen Lösch-Varianten bei einer Datenbank:
delete storage -l /Test.db : löscht die Datei ”
Test.db“
delete storage -l /Test.db -a Table1 : löscht die Tabelle ”
Table1“ in der Datei ”
Test.db“
delete storage -l /Test.db -a Table1 -t TRUE Sensor=’Sensor1’ : löscht alle Datensätze
in der Tabelle Table1“ in der Datei Test.db“, die in der Spalte Sensor“ Sensor1“
” ” ” ”
beinhalten
Löschen aller Datensätze einer Datenbank Zum Löschen aller Datensätze einer Datenbank
muss in der Konsole der Befehl clear storage -l OBJEKT eingegeben werden. Mit
der Option -l wird der Pfad und der Name der Datenbank übergeben. Benutzt man zusätzlich
die Option -a BEREICH werden alle Datensätze des übergebenen Bereichs gelöscht.
Folgendes Beispiel zeigt das Löschen aller Datensätze einer Tabelle in einer Datenbank:
41

A Handbuch
clear storage -l /Test.db -a Table1
Lesen einer Datenbank Beim Lesen einer Datenbank stehen vier Varianten zur Verfügung.
Um die gesamte Datenbank zu lesen, muss der Befehl read storage -l OBJEKT in der
Konsole eingegeben werden. Bei der Option -l muss der Pfad und der Name der Datenbank
übergeben werden. Sollen die Datensätze eines Bereichs gelesen werden, muss zusätzlich
die Option -a BEREICH angegeben werden. Fügt man zu den Optionen -l und -a noch
die Option -i DATENSATZ hinzu, können einzelne Datensätze eines Bereichs aus der Datenbank
gelesen werden. Sollen einzelne Datensätze gelesen werden, die einer bestimmten
Bedingung entsprechen, muss zusätzlich die Option -c TRUE BEDINGUNG hinzufügen.
Das folgende Beispiel zeigt den Befehl zum Lesen einzelner Datensätze mit einer Bedingung
aus einer Datenbank:
read storage -l /Test.db -a Table1 -i Messergebnis -c TRUE Sensor=’Sensor1’ : liest
alle Datensätze der Spalte Messergebnis“ aus der Tabelle Table1“ der Datei Test.db“, die
” ” ”
von dem Sensor Sensor1“ stammen.
”
A.7 Anzeigen von Informationen
Es besteht die Möglichkeit Informationen über den laufenden Monitordienst zu erhalten.
Es lassen sich Informationen über folgende Komponenten des Monitordienstes abfragen:
ˆ Sensor Manager
ˆ Actuator Manager
ˆ Sensor Actuator Logic Dispatcher
Hierfür muss in der Konsole der Befehl monitor info mit der Option -c KOMPONEN-
TE eingegeben werden. Um die Informationen einer gewünschten Komponente zu erhalten,
kann als Komponente SENSORS für den Sensor Manager, ACTUATORS für den Actuator
Manager und LOGICS für den Sensor Actuator Logic Dispatcher eingegeben werden. Die
Option -c ALL bewirkt, dass die Informationen aller Komponenten angezeigt werden.
Die Informationen des Sensor Manager beinhalten eine Auflistung aller registrierten Sensor,
sowie deren Status, ob sie gerade Laufen oder Ruhen. Die Informationen des Actuator Managers
beinhalten eine Auflistung aller registrierten Aktoren. Die Informationen des Sensor
Actuator Logic Dispatcher beinhalten eine Auflistung aller registrierten Logik-Strukturen,
sowie der Verknüpfungen zwischen Sensoren und Aktoren.
42