[Aufmachergrafik: heller, corporate design] Spitzentechnik und Basisarbeit Ganzheitliche Planung von Hochverfügbarkeit

Ordnungsmerkmale

erschienen in: <kes> 2005#1, Seite 64

Rubrik: Management und Wissen

Schlagwort: Unternehmenskritische IT-Infrastruktur

Zusammenfassung: Über Auswahl, Installation und Betrieb von High-Tech-Sicherheitsmaßnahmen geraten die "Basics" zur ganzheitlichen Planung von Hochverfügbarkeit schon einmal ins Hintertreffen. Da die Vermeidung von Ausfallzeiten für viele Unternehmen buchstäblich zur Überlebensfrage geworden ist, lohnt sich eine kurze Besinnung.

Autor: Von Hardo G. Hase, Zweibrücken

In vielen Unternehmen klafft zwischen Anspruch und Wirklichkeit der Notfallvorsorge und Hochverfügbarkeitsplanung noch immer eine erschreckend breite Lücke. Während in der Theorie nahezu 100-prozentige Verfügbarkeit herrscht – Stichwort: High Availability Cluster mit Failover und Scalable Service –, mangelt es in der Praxis gerade an der konsequenten Umsetzung von grundlegenden Maßnahmen, beispielsweise für den reibungslosen Wiederanlauf.

Entscheidend ist vor allem eine ganzheitliche Notfallvorsorge, die jeweils unternehmensspezifische "Real-World"-Szenarien berücksichtigt und alle Abhängigkeiten und Kausalitäten gleichermaßen miteinander in Bezug stellt. Notfallmanagement beginnt damit weit vor dem Katastrophenfall. Entscheidend sind besonders diejenigen Abhängigkeiten und Kausalitäten, die in der Praxis als "Basics" auch schon mal vernachlässigt werden. Das bedeutet ebenfalls, Risiken nicht nur aufgrund der bekannten, teilweise rudimentären Szenarien und Ansätze zu bewerten.

Erst im zweiten Schritt kommt es auf "High-Level-Technologien" an, die dann allerdings auch die Single Points of Failure (SPOF) – weitestgehend – verlässlich schützen sollten. Denn IT-Infrastrukturen von Unternehmen haben sich mittlerweile zu hochgradig anfälligen, unternehmenskritischen "Lebensadern" entwickelt. Speziell besonders sensitive Branchen mit hochkomplexen Geschäftsprozessen (etwa Banken, Versorger oder Transport und Verkehr) sind verstärkt in Abhängigkeit von verlässlichen Systemen geraten.

Zugleich steigt in den Augen vieler IT-Verantwortlicher die Eintrittswahrscheinlichkeit der hinlänglich bekannten Krisen- und Bedrohungszenarien dramatisch an. Die Folge: In Sachen unternehmenskritischer IT-Infrastrukturen besteht erheblicher Schutz- und Handlungsbedarf. Detaillierte Notfallpläne und Crash-Recovery-Konzepte gehören heute zum unerlässlichen Handwerkszeug, wenn komplexe IT-Infrastrukturen verlässlich abgesichert und "überlebensfähig" gemacht werden sollen.

----------Anfang Textkasten----------

Business Critisec 2005

Am 26. April 2005 findet in Köln erstmals die Konferenz "Business Critisec – Praxisforum Schutz unternehmenskritischer IT-Infrastrukturen" statt. Namhafte Referenten aus Wirtschaft, Forschung und öffentlicher Hand beleuchten dort umfassende und praxisnahe Lösungsansätze zum Thema. Im Rahmen einer umfassenden Gesamtkonzeption von Sicherheits- und Notfallmanagement werden unter anderem folgende Einzelthemen erläutert:

Kooperationspertner der Business Critisec 2005 sind der TeleTrusT e.V. und die <kes>. Weitere Informationen zu Programm und Anmeldung gibt es unter [externer Link] www.business-critisec.de

----------Ende Textkasten----------

Basis Grundschutz

Das IT-Grundschutzhandbuch des BSI bietet im Regelfall eine erste belastbare Basis für die Planung. So beschreibt der Maßnahmenkatalog M6 detailliert die wichtigsten Schritte zur Erstellung eines Wiederanlaufplans. Eine strukturierte Umsetzung und Beachtung der dort beschriebenen Aspekte reicht den meisten Unternehmen als besonders effiziente Vorgehensweise völlig aus.

Doch die Stabilität der Systeme ist auch in vielen Fällen – zum Beispiel in besonders sensitiven Branchen – mit ungleich höheren Anforderungen verbunden. Während woanders Ausfallzeiten im Minutenbereich als tolerierbar gelten, stellen diese bei unternehmenskritischen Anwendungen unter Umständen bereits einen Super-GAU für die Geschäftsprozesse dar.

Bei der praktischen Herangehensweise stellt sich dann schnell die Frage nach Wiederbeschaffungsmöglichkeiten: Wie sind zum Beispiel Serviceverträge über entsprechende Reaktionszeiten mit dem Hardwarehersteller gestaltet? Schon bei Abschluss von Serviceverträgen mit dem jeweiligen Lieferanten ist auf Reaktions- und Verfügbarkeitszeiten zu achten, die den unternehmenseigenen Notfallplänen entsprechen, um böse Überraschungen zu vermeiden. Denn eine vereinbarte Reaktionszeit von zwei Stunden kann in der Praxis möglicherweise gerade einmal die telefonische Rückmeldung eines Technikers bedeuten. Keine große Hilfe, wenn es im IT-Betrieb "brennt". Die gleiche Aufmerksamkeit muss ebenso dem Grad der Verfügbarkeit gelten, der im Rahmen der Serviceverträge zugesichert wird.

Eine einheitliche Hardwareplattform für Produktion, Test und Entwicklung ist ebenfalls entscheidend, um einen eventuellen Hardwareaustausch reibungslos zu ermöglichen. Von Vorteil sind standardisierte Komponenten, eine umfassende Hardwaredokumentation und aktuell gehaltene Betriebshandbücher. Letztere umfassen die Dokumentation der Hard- und Software sowie Ablaufpläne zum Starten und Stoppen von Applikationen sowie Zuständigkeiten und Rufnummern für Notfälle, Seriennummern der Hardware und Vertragsnummern der Wartungsverträge sowie Verfahrensanweisungen für Fehlermeldungen.

In- und extern

Bei in- und externen Ausweichmöglichkeiten lässt sich bestenfalls ein Backup-Rechenzentrum in einem getrennten Gebäude einrichten; zumindest sollte das eigentliche Rechenzentrum in mehrere Brandschutzabschnitte aufgeteilt sein. Redundante Komponenten für Energie, Netzwerk, Rechner und Datenhaltung stellen genauso wie regelmäßige und geprüfte Backups wesentliche Basisanforderungen an die Verfügbarkeit dar.

Ausweich-Netzverbindungen stellen in Notfällen oftmals die Achillesferse dar, denn Anbindungen über mehrere Wege sind längst noch nicht selbstverständlich oder limitieren womöglich im Krisenfall als Flaschenhals den Datendurchsatz unerträglich stark. Erst die Verwendung verschiedener Technologien wie Glasfaser oder Funkstrecke bietet verlässliche Rückfallmöglichkeiten – nicht nur für den Fall, dass die klassischen Leitungen wegbrechen, sondern zunehmend auch als grundsätzliche Alternative mit zunehmender Bandbreite (Stichwort: Satellitenkommunikation).

Kommt es schließlich zum Ernstfall, also (mindestens) zum eingeschränkten IT-Betrieb, so gilt es auch auf Applikationsseite eine Priorisierung vorzunehmen. Test- und Entwicklungssysteme müssen sich unverzüglich stoppen lassen, um ihre Ressourcen für die Produktion bereitzustellen.

Auch beim System-Start von IT-Komponenten hapert es nicht selten an Basics: So werden häufig weder aktuelle Betriebshandbücher vorgehalten, noch verfügen viele Unternehmen über ausreichende Applikationsdokumentationen. Die Erstellung von Ablaufplänen für das Operating ist jedoch unerlässlich. Eine lückenlos dokumentierte, getestete und festgelegte Vorgehensweise zur Wiederherstellung einer Produktionsumgebung nach einem Totalausfall ist ein entscheidender Erfolgsfaktor, wird in der Praxis aber meist nicht konsequent umgesetzt. Dazu gehört neben einer strikten Festlegung der Zuständigkeiten des Personals auch eine detaillierte Eskalationsplanung. Auch hier gilt es rechtzeitig (oft nur vermeintliche) Selbstverständlichkeiten wie aktuelle und verfügbare Telefonlisten vorzuhalten.

Continuous Availability

Weitergehende Anforderungen an die unternehmenseigene Notfallplanung erfordern neben einer systematischen individuellen Risikoanalyse vor allem auch eine realistische Einschätzung der mit vertretbarem Aufwand erreichbaren Verfügbarkeit. High-Availability-Umgebungen, die Ausfallsicherheit und Fehlertoleranz erhöhen, können die Anzahl der SPOF nur möglichst gering halten und versuchen ihren Ausfall zu vermeiden, der ansonsten einen Ausfall des gesamten Services nach sich zöge. "Echte" Hochverfügbarkeit hieße hingegen, alle SPOF durchgängig auszuschließen.

Erhöhte Ausfall- und Fehlertoleranz als Vermeidung von SPOF ist in einem System tendenziell durch mehrfache Ausführung seiner Komponenten umsetzbar (Redundanz), zum Beispiel mehrere Netzwerkschnittstellen, mehrpfadige Anbindung von Storage-Komponenten und eine redundante Datenhaltung (RAID-Systeme).

Die Erhöhung der Verfügbarkeit ist demnach zuallererst eine Frage der Organisation von IT-Infrastrukturen. Im Sinne von Clustern muss ein redundanter Aufbau der Hardware und Einsatz einer Verwaltungssoftware zum automatischen Failover einer Applikation erfolgen (Failover Service). Eine Applikation wird dazu nur auf einem einzelnen Cluster-Node betrieben. Ist der Betrieb der Anwendung auf dem aktuellen Knoten nicht mehr möglich, wird sie von der Cluster-Software dort gestoppt und anschließend auf einem anderen Knoten wieder online gebracht.

Redundant und parallel

Bei einem skalierbaren Service (Scalable Service) wird eine Applikation parallel auf mehreren Knoten des Cluster betrieben. Ist ihr Betrieb auf einem Knoten nicht mehr möglich, wird der Dienst auf diesem Knoten von der Cluster-Software gestoppt. Der Betrieb läuft jedoch fast unterbrechungsfrei auf den anderen Cluster-Knoten weiter. Allerdings lassen sich nur wenige Applikationen im Cluster skalierbar betreiben. Parallel laufende Systeme erfordern zudem – quasi als flankierende Maßnahme – eine entsprechende Storage-Architektur (Volume-Management), die eine verlässliche Synchronisation der Datenbestände und Geschäftsprozesse gewährleistet.

Das Idealziel der Hochverfügbarkeit lautet letztlich "Continuous Availability". Doch der unterbrechungsfreie Betrieb eines Service lässt sich in der Praxis bislang nur eingeschränkt umsetzen. Eine möglichst dichte und zugleich pragmatische Annäherung daran ist durch Einsatz fehlertoleranter Hard- und Software sowie den Einsatz von Cluster-Software erreichbar.

Vom verstärkten Organisationsaufwand sollte sich dabei kein Unternehmen davon abschrecken lassen, Continuous Availability zumindest als ehrgeiziges Ziel anzustreben. Bis dahin ist ansonsten nur eines ganz sicher: der nächste Systemausfall.

Hardo G. Hase ist Geschäftsführer der Hase IT GmbH und Mitglied im Board der Business Critisec 2005 (siehe Kasten).