Ausgangspunkt

Zu Beginn der Arbeit bestand die Serverstruktur aus zwei dedizierten Servern, die im Universitätsrechenzentrum der TU Chemnitz stehen und auf Basis des Betriebssystems Fedora Core 1.0 laufen.
Als funktionale Grundlage der Anwendung wurde eine Plattform bestehend aus dem ZOPE-Applikationsserver und dem darauf aufsetzenden Content Management System Plone, einem als Proxy vorgeschaltenem Apache-HTTP-Webserver sowie einer PostgreSQL-Datenbank gewählt.
Für den Einsatz des PostgreSQL wurde sich entschieden, da die Angebotsdaten einfach verfügbar und wiederverwendbar aufbewahrt werden und mit verschiedenen Werkzeugen durchsuchbar sein sollten, weshalb diese Ablage in einer relationalen Datenbank, unabhängig der objektbasierten ZOPE-eigenen ZODB, im Serversystem gewählt wurde.
Der Apache-HTTP-Server dient in der Struktur als Proxy und Cache für den ZOPE-internen Webserver.
Die Entwicklung fand auf dieser Serverstruktur primär auf einer Maschine statt und wurde aus Sicherungs- und Gründen der Ausfallüberbrückung manuell auf den zweiten Server kopiert.

Nun ist die leistungsstarke Bereitstellung der Anwendung geplant. Demnach soll es selbst im Falle eines Ausfalls einzelner Komponenten in der Struktur nicht zu einem Gesamtausfall kommen. Ist der Gesamtausfall unumgänglich, soll er möglichst kurzzeitig sein.
Erwünscht ist außerdem, dass das System selbst einer großen Zahl gleichzeitig darauf zugreifender Nutzer ein zügiges und flüssiges Arbeiten ermöglicht. Demnach ist eine minimale Reaktionszeit des Systems, mit der auf Anfragen von Nutzern reagiert wird, gewollt.

Das Gesamtserver-System besteht aus zwei identischen PC-Systemen, von denen klar war, dass sie jeweils die volle Funktionalität der Anwendung beherbergen können. Um allerdings einen möglichst guten "`Funktionalitätsdurchsatz"' zu erreichen, sollen beide Rechner im Normalbetrieb parallel arbeiten. Kommt es allerdings auf einem der beiden Systeme zu einer Fehlfunktion, sollen beide Rechner jeweils in der Lage sein, die Gesamtfunktionalität zu übernehmen und aufrecht zu erhalten, bis ein Failback die Wiederaufnahme des Normalbetriebs ermöglicht. Diese Übernahme sollte automatisch und idealerweise für Nutzer, die zum Zeitpunkt des Ausfalls das System nutzen, möglichst unbemerkt erfolgen.

Es geht also primär darum zu betrachten, welche Möglichkeiten bestehen, um das System schnell, stabil und möglichst ausfallsicher zu machen - kurz das Gesamtsystem mit entsprechender Perfomanz auszustatten. Dazu sollen vor allem Open-Source-Produkte und Mechanismen betrachtet werden, die frei verfügbar sind.