Foto: Libelle GmbH
Business Continuity wird häufig auf Desaster Recovery reduziert, mit dem externe Störungen aufgefangen werden. In der Tat treten interne Störungen in IT-Systemen häufiger auf, doch per Desaster Recovery lassen sie sich nur unzureichend beheben. Hier sind andere Lösungen gefragt.
von Ulrich Lenz (aktualisiert)
"Schadensereignisse", wie es im Versicherungsdeutsch ein wenig euphemistisch heißt, kommen meist so über die IT, wie man es nicht erwartet hat, und oft zeigt sich dabei, dass auch gute Vorkehrungen vergebens waren. So hatte sich im US-Staat New York erst mit dem verheerenden Wirbelsturm Sandy herausgestellt, dass die Idee, Notstromaggregate platzsparend im Keller aufzustellen, doch nicht so gut war. Fatal, wenn beispielweise die IT eines Buchungssystems auf den Strom dieser Anlage angewiesen ist.
Bei solchen Großereignissen rechnet wohl jeder Kunde und jeder Geschäftspartner damit, dass die Systeme nicht funktionieren. Bei den täglichen kleinen, auf ein Unternehmen begrenzten Schadensfällen jedoch ist mit einem solchen Verständnis kaum zu rechnen. Fällt beispielweise ein Online-Buchungssystem für Hotelreservierungen oder Flüge aus, so besteht der Schaden nicht nur in den Buchungen, die dann nicht vorgenommen werden können, sondern auch im möglichen Abwandern der Kunden auf andere Buchungsportale. Wenn die Systeme nicht ausreichend abgesichert sind, können auch bereits bestätigte Buchungen verloren gehen, betroffene Kunden werden dann möglicherweise Regressansprüche stellen. Die Kosten für derartige ungeplante Systemausfälle können enorm sein und in einer Welt, in der alles von der IT abhängt, durchaus die Existenz eines Unternehmens gefährden.
Über die Notwendigkeit von Backups muss man heute nicht mehr diskutieren, die klassische Datensicherung mittels Backup und Restore mit Band oder Plattenspeicher ist die Grundlage eines jeden Desaster Recovery. Die fortschreitende Digitalisierung aller Prozesse hat allerdings die Anforderungen erheblich hinaufgeschraubt: Allein die Dauer eines Backup-Laufs und der meist noch zeitraubendere Recovery-Lauf setzten einer Verkürzung von RPO (Recovery Point Objective) und RTO (Recovery Time Objective) Grenzen. Für Unternehmen mit hochkritischen Prozessen, beispielsweise in der Fertigung, oder Unternehmen mit hohem Anspruch an die Verfügbarkeit, wie Notdienste, reichen Backup und Restore daher in der Regel nicht aus.
Update: Desaster-Recovery-Lösungen
Die genannten Grenzen lassen sich hinausschieben, wenn die Datensicherung kontinuierlich erfolgt, wenn also jede Veränderung im Datenbestand zeitnah (asynchron) oder zeitgleich (synchron) in einem zweiten Speichersystem erfasst wird.
Beim asynchronen Verfahren werden im primären, produktiven System Veränderungen von der Anwendung in den Datenbestand geschrieben, und die Verarbeitung geht verzögerungsfrei weiter. Mit einer je nach Lösungsansatz mehr oder weniger geringen zeitlichen Verzögerung wird die Änderung zwischengespeichert und dann in ein sekundäres Speichersystem geschrieben. Bei einem ungeplanten Ausfall des primären Systems stehen relativ aktuelle Daten im sekundären Speicher zur Verfügung. Den Reisenden, dessen Flugbuchung sich beim Störfall noch im Zwischenspeicher befand und der nun mit "ziemlich aktuellen Daten" konfrontiert wird, dürfte das jedoch nicht zufriedenstellen.
Für solche weitergehenden Anforderungen bieten synchrone Verfahren mehr Schutz. Veranlasst hier nämlich eine Anwendung eine Änderung des Datenbestandes - zum Beispiel eine Buchung -, so erhält sie erst dann die Rückmeldung einer erfolgreichen Änderung, wenn die Daten sowohl im primären als auch im sekundären Speicher abgelegt wurden. Dabei können durch längere Signallaufzeiten allerdings Verzögerungen bei der Verarbeitung auftreten, je nach Entfernung zum Standort des sekundären Speichers und der verwendeten Übertragungstechnologie. Deshalb wird bei solchen Übertagungsstrecken besonders auf kurze Latenzzeiten geachtet. Das ist besonders bei zeitkritischen Transaktionen wichtig.
Ausfallsichere System im Überblick
Wichtig ist natürlich neben der Sicherung der Daten auch die Methode zur Bereitstellung der gesicherten Daten auf einem funktionierenden System. Dafür bieten sich mehrere Alternativen an:
• Cold-Stand-by-Systeme: Die benötigten Anwendungen und die gesicherten Datenbestände werden auf ein Reservesystem übertragen - eine Lösung, die allerdings zahlreiche Schwachpunkte aufweist: Es ist viel Administrationstätigkeit erforderlich, und es dauert meist auch einige Zeit, ehe der Betrieb fortgesetzt werden kann. Außerdem passen erfahrungsgemäß die Firmware-Release-Stände nicht zur aktuell benötigten Betriebssystemversion, und notwendige Anwendungs-Patches sind nicht nachgepflegt. Diese Lösungsvariante reicht in einer modernen, auf kontinuierliche Verfügbarkeit ausgerichteten IT-Landschaft nicht einmal mehr für unkritische Anwendungen.
• Hot-Stand-by-System: Hier wird das Ersatzsystem ständig auf dem gleichen Release- und Firmware-Stand gehalten wie das primäre Produktionssystem. Tools helfen im Desaster-Fall, das Umschalten zumindest teilweise zu automatisieren. Dennoch muss man mit mehr oder weniger langen Ausfallspausen rechnen, sodass diese Lösung nur für unkritische Anwendungen infrage kommt.
• Cluster und Virtualisierung: Eine Weiterentwicklung des Hot-Stand-by-Konzepts stellt der High Availability Cluster (HA-Cluster) dar. Hier ist die Überwachung des primären Produktionssystems in der Cluster-Management-Software untergebracht. Fällt die primäre Seite aus, findet ein Wechsel auf das sekundäre System statt. Allerdings werden dabei laufende Transaktionen unterbrochen, sie müssen im sekundären System bereinigt und dann neu aufgesetzt werden. Der aktuelle Hauptspeicherinhalt des primären Systems geht so komplett verloren. Ein sicherer Betrieb eines Cluster-Systems lässt sich durch ein sehr gut ausgebildetes und diszipliniertes Bedienpersonal verbessern.
• Hybrid-Lösung zwischen Hot-Stand-by und Cluster: Mit der zunehmenden Verbreitung von Virtualisierungslösungen stehen auch neue Verfahren zur Erhöhung der Verfügbarkeit zur Verfügung. Da ein virtueller Computer nichts anderes ist als eine Ansammlung von Dateien in einem Speichersystem, kann diese virtuelle Maschine mit geeigneten Datensicherungsmethoden (mindestens asynchron) auf einem zweiten Standort gesichert werden. Fällt der primäre physische Rechner aus, werden durch die entsprechenden Management- und Überwachungs-Tools virtuelle Maschinen auf einem sekundären physischen Rechner neu gestartet. Allerdings kommt das System im sogenannten Crash-Status hoch, es muss also eine Bereinigung des Systemzustandes erfolgen, zum Beispiel die Überprüfung des Dateisystems oder auch ein komplettes Rollback der Datenbank - also alle Vorgänge, die nach dem Absturz eines Rechners und Wiederanschalten typischerweise ausgeführt werden. Das kann unter Umständen natürlich einige Zeit dauern.
• Fehlertolerante Systeme: Die bisher betrachteten Methoden gehen von einem Störfall aus und wollen ihn überwinden, um den Betrieb möglichst schnell wieder aufzunehmen. Es gibt jedoch Anwendungen, die eine kontinuierliche Verfügbarkeit benötigen, beim Ausfall einer einzelnen Komponente also eine Wiederherstellungszeit von tatsächlich Null Sekunden erfordern, eine Betriebsunterbrechung also gar nicht erst zulassen. Das kann auch ein HA-Cluster nicht leisten; hier ist der Einsatz fehlertoleranter Systeme erforderlich. Sie gehen nicht mit den aufgetretenen Fehlern um, sondern sind so konstruiert, dass sie das Entstehen von Fehlern gleich ganz unterbinden. Dazu sind bei fehlertoleranten Systemen sämtliche Komponenten doppelt ausgelegt, und diese werden permanent synchronisiert. Fällt eine Komponente aus, so läuft die jeweilige Partnerkomponente einfach weiter. Mit dem Anspruch der Fehlertoleranz ist auch verbunden, dass Betriebssystem und Treiber rigorosen Kompatibilitäts- und Stabilitätstests unterzogen werden, um hier ebenfalls eine maximale Verfügbarkeit zu garantieren.
Update: kontinuierliche IT-Verfügbarkeit richtig planen
Obwohl Verfügbarkeit heute eine der zentralen Anforderungen an die IT ist, setzen viele Unternehmen Lösungen ein, die die dabei gesteckten Ziele nicht erreichen können. So stehen beispielsweise synchron arbeitende Desaster-Recovery-Lösungen mit aufwendigen Backup-Rechenzentren an entfernten Standorten hoch im Kurs. Betrachtet man jedoch die Häufigkeit der Ursachen für Systemausfälle, so zeigt sich, dass nicht die durch derartige Architekturen primär abgefangenen externen Störungsursachen, sondern vor allem Software- und Bedienungsfehler vorherrschen.
Foto: Libelle GmbH
In der Praxis sind etwa 95 Prozent der Ausfälle auf lokale Ursachen zurückzuführen, die mittels einer Desaster-Lösung, die ja nur externe Ursachen wie Feuer, Wasser oder Stromausfall abdeckt, überhaupt nicht verhindert werden können. Ein simpler Hardwarefehler - beispielsweise der Ausfall eines Speicherbausteins oder einer CPU - führt dabei zu einem Desaster-Fall, das heißt zum kompletten Umschalten des Betriebes auf das sekundäre System mit entsprechendem Daten-Restore. Die Folgen sind dann beispielweise Datenverlust und eine Betriebsunterbrechung mit entsprechend hohen Kosten.
Solche Folgeprobleme treten bei fehlertoleranten Systemen nicht auf. In dieser Architektur werden Ausfälle durch Hardwarefehler schon im Entstehen abgefangen. Außerdem sind fehlertolerante Systeme in der Bedienung wesentlich einfacher, insbesondere im Vergleich zu Cluster-Lösungen, und vermindern auf diese Weise das Risiko von Administrator- und Anwenderfehlern - im Alltag des Rechenzentrums immer noch eine der Hauptfehlerursachen. Berücksichtigt man die laufenden Kosten eines Systems inklusive des Betreuungsaufwands, so sind fehlertolerante Systeme auch wirtschaftlich vorteilhaft. Die Kombination aus fehlertoleranten Servern und geeigneten Datensicherungslösungen stellt daher eine sehr effiziente Möglichkeit zur Vorsorge gegen allfällige Schadensereignisse dar. Und je nach geogrfhischer Lage sollte man auch dieses System vielleicht nicht gerade im Keller aufstellen.
(hal / rb)