E-Commerce-Kunden, egal ob aus dem Business-to-Consumer- oder dem Business-to-Business-Segment, reagieren schnell. Sie kehren einem Anbieter, dessen E-Commerce-Site wiederholt oder längere Zeit nicht verfügbar ist, den Rücken und wenden sich der im Internet reichlich vorhandenen Konkurrenz zu. Dem betroffenen Unternehmen geht mehr als ein Auftrag verloren, denn alle möglichen Folgegeschäfte sind dann mit gefährdet. Unter Umständen werden auch entsprechende Presseberichte zu weiteren Imageschäden führen.

Obwohl eine exakte Bezifferung solcher Schäden schwierig ist, nennen Schätzungen außerordentliche Größenordnungen. Den Marktforschern der Gartner Group zufolge schlagen die durchschnittlichen Kosten für eine Stunde Ausfall je nach Branche zwischen einigen zehntausend und mehr als sechs Millionen Dollar zu Buche. Angesichts dessen erscheinen Überlegungen, die Verfügbarkeit der E-Commerce-Infrastruktur in die Unternehmensstrategie einzubeziehen, mehr als sinnvoll.

Auch 99 Prozent Verfügbarkeit sind zu wenigDie meisten Firmen sind zwar bemüht, die Ausfallzeiten ihrer Systeme so gering wie möglich zu halten, jedoch reichen klassische Maßnahmen wie die redundante Auslegung von Prozessoren, Netzwerkkarten und Lüftern oder der Einsatz von unterbrechungsfreier Stromversorgungen und RAID-Speicher nicht aus. Im Übrigen erhöhen auch routinemäßige Wartungsarbeiten das Risiko für die gewünschte Verfügbarkeit rund um die Uhr. Für viele Arbeiten an Hard- und Software ist es notwendig, das System herunterzufahren. Niemand wird ernsthaft annehmen, dass ein Server-System 364 Tage im Jahr permanent im Betrieb ist.

Untersuchungen der Gartner Group haben ergeben, dass Unix-Systeme immerhin mit den genannten Vorkehrungen eine Verfügbarkeit von bis zu 99 Prozent erreichen. Aber das bedeutet immer noch 88 Stunden Ausfall pro Jahr. Die Werte für NT-Systeme sind mit einer Verfügbarkeit von 97 Prozent, das sind 263 Stunden Ausfallzeit, nochmals deutlich schlechter.

Es geht also darum, die Verfügbarkeit weiter zu erhöhen und sie etwa in den Bereich von 99,99 Prozent zu bringen, was einer kumulierten Ausfallzeit von 53 Minuten pro Jahr entspricht. Dazu müssen zusätzliche Vorkehrungen wie der Einsatz einer geeigneten Cluster-Software getroffen werden. Cluster erlauben es, die Verfügbarkeit eines Dienstes, wie beispielsweise eines Web-Servers oder einer Datenbank, zu erhöhen, indem Instanzen desselben Dienstes auf mindestens zwei unterschiedlichen Systemen ausgeführt werden.

Die Cluster-Software überwacht dabei die einzelnen Knoten und sorgt für eine Übernahme der Dienste eines ausgefallenen Rechners durch die verbleibenden Systeme. Eine minimale Cluster-Konfiguration besteht aus minimal zwei Servern, ist jedoch entsprechend den Anforderungen auch auf mehrere Knoten ausdehnbar, die für Notfälle, wie Brände, auch noch in unterschiedlichen Gebäuden untergebracht sind.

Für die Realisierung eines Clusters kommen gegenwärtig zwei verschiedene Modelle zum Einsatz: das Shared-Storage- und das Shared-Nothing-Modell. Bei ersterem hat jeder Knoten zu jeder Zeit Zugriff auf alle verfügbaren Ressourcen. Dies erfordert einen so genannten Distributed-Lock-Manager (DLM), der Zugriffe auf gemeinsame Datenbereiche serialisiert und synchronisiert, um so die Konsistenz der Daten sicherzustellen.

Beim Shared-Nothing-Modell hingegen ist jeder Knoten im exklusiven Besitz eines Teils der Ressourcen des Clusters. Erst beim Ausfall eines Knotens - oder auf Wunsch bei Wartungsarbeiten - übernimmt ein anderer die Ressourcen und stellt sie wieder für den Zugriff bereit. Dieses Failover gewährleistet die Konsistenz der Daten und erhöht die Verfügbarkeit. Eine Ressource besteht dabei aus einer virtuellen IP-Adresse, einer oder mehreren Applikationen und einem von allen Knoten des Clusters gemeinsam nutzbaren Plattenspeicherbereich.

Die bisher dargestellten Cluster-Funktionalitäten sind mehr oder weniger von allen gängigen Anbietern erhältlich. Diese Lösungen haben jedoch in der Regel den Nachteil, auf eine bestimmte Plattform eines Hardwareherstellers oder ein spezifisches Betriebssystem, etwa Solaris oder AIX, beschränkt zu sein. Zudem sind sie meist sehr komplex, was Design und Implementierung einer fertigen Lösung anbelangt. Somit bleibt die in vielen Unternehmen bestehende Heterogenität unberücksichtigt, und es gibt in der Regel keine Möglichkeit, dieselbe Cluster-Software auch unter True 64, Linux oder HP-UX zu betreiben.

Des Weiteren ist ein Failover nicht immer und in jeder Situation sinnvoll, so beispielsweise, wenn ein Datenbankausfall durch einen einfachen Neustart des Datenbankdienstes lokal behebbar ist. Von Vorteil ist hier ein auf offenen Programmier-Schnittstellen (API) basierender Ansatz. Dieser sollte nicht nur nahezu alle gängigen Unix-Derivate unterstützen, besser auch noch Windows NT, sondern es dem Administrator auch ermöglichen, seinen Cluster in eine Art Expertensystem zu verwandeln, das auf spezifische Fehlersituationen zu reagieren vermag. Voraussetzung dafür ist die Fähigkeit, beliebige Programme in den Ablauf der Problemerkennung und Behebung zu integrieren und so auch bei komplexen E-Commerce-Produkten die Verfügbarkeit zu erhöhen.

Eine Open-API basiert auf zwei Schnittstellen, nämlich dem Shared-Storage-API und dem Object-API. Diese beiden Schnittstellen in Verbindung mit geeigneten Programmen oder Skripten versetzen den Administrator in die Lage, nahezu jedes beliebige System in einen Cluster-Verbund einzubinden.

Das Shared-Storage-API erlaubt dabei die Einbeziehung fast aller gängigen Speichersubsysteme, solange sie vom Betriebssystem ansteuerbar sind und eine exklusive Reservierung unterstützen, wodurch sichergestellt ist, dass nur ein Knoten auf den Speicher zugreift. Über offene Share-Storage-API ist auch die Einbindung beliebiger Volume-Management-Software, zum Bei-spiel "Solstice Disk Suite", möglich.

Das Object-API verschafft dem Systemverwalter die erforderliche Flexibilität, um nahezu jede denkbare Fehlersituation abzufangen und darauf zu reagieren. Dazu erstellt der Administrator für jedes abzusichernde Objekt ein Programm oder Skript, das eine Überprüfung kritischer Funktionen durchführt und je nach Erfolg oder Misserfolg einen entsprechenden Rückgabewert liefert. Bei Eintritt eines Fehlers wird eine Routine aufgerufen, die versucht, das Problem entsprechend der Fehlernummer zu behandeln und zu beheben. Ist das nicht möglich, wird das Failover der Ressource eingeleitet und, falls erwünscht, der Knoten, auf dem das Problem entstanden ist, neu gestartet, um das System wieder in einen definierten Zustand zu versetzen.

Der Open-API-Ansatz bringt also in mehrfacher Hinsicht Vorteile. Einerseits ist dieselbe Cluster-Software auf allen gängigen Plattformen einsetzbar und macht ein Unternehmen damit von den proprietären Lösungen einzelner Betriebssystem-Anbieter unabhängig. Andererseits bietet sie die Möglichkeit, durch einfache Adaptierung an die jeweiligen Anforderungen beinahe jede Anwendung, sei es ein Web-, Datenbank-, E-Mail- oder sonstiges System, hoch verfügbar zu machen.

* Jörg Lehrke ist Chefentwickler der Wizard Software GmbH in Ismaning bei München.

Abb.1: Verfügbarkeit der Systeme

Anfällige Betriebssysteme sind teuer. Die Angaben der Merit Advisory Group beziehen sich auf eine Umfrage unter 1800 IT-Fachleuten. Die Kalkulation der Gartner Group zeigt auf, dass selbst scheinbar geringfügige Verbesserung der prozentualen Ausfallsicherheit in den Nachkommastellen enorme Kosteneinsparungen nach sich ziehen. Quelle: Untersuchungen der Gartner Group und der Merit Advisory Group

Abb.2: Schlappmachen ist teuer

Den Preis jedes IT-Ausfalls muss man über einzelne Geschäftsaktivitäten kalkulieren. Mit überraschend hohen Verlusten ist zu rechnen. Quelle: Gartner Group