Business Continuity - Anforderungen an die IT
Geschäftsfortbestand und Betriebsfortbestand sind zwei Übersetzungen, die man für den Ausdruck Business Continuity (BC) findet. BC ist ein sehr umfassender Begriff, der auf den ersten Blick wenig mit der Informationstechnologie zu tun hat. Wir werden aber sehen, dass
- die generischen Anforderungen an eine gute BC Lösung auch auf die IT im Unternehmen angewandt werden können und
- die Notfallvorsorge im IT-Bereich ein wesentlicher Bestandteil eines vernünftigen BC Plans sind (vorausgesetzt, das Unternehmen, das diesen Plan umsetzt, nutzt IT).
Dieser Artikel wird zu Beginn sehr allgemein das Thema Business Continuity behandeln, dann aber die IT-Aspekte einer BC-Lösung betrachten und schließlich eine detaillierte Diskussion über kritische Fehlersituationen, mögliche Gegenmaßnahmen und die beiden wesentlichen Anforderungen führen.
Betriebsfortbestand in der Industrie
Vor einigen Jahren habe ich bei einem Besuch im Ruhrgebiet die Zeche Zollverein in Essen besucht. Der Höhepunkt war eine von einem ehemaligen Betriebsleiter geführte Besichtigung der Kokerei, die seit vielen Jahren nicht mehr in Betrieb ist. Was mich am meisten beeindruckt hat – neben dem Blick durch einen 100m hohen Schornstein von unten in den nachtklaren Himmel – war die Erklärung, wie diese Kokerei 7x24x365 betrieben wurde, und zwar vom Zeitpunkt der Inbetriebnahme bis zum Ende nach vielen Jahren ohne Unterbrechung. Der Hintergrund sind technische Anforderungen: die (Schamott)-Steine, aus denen die Innenwände der Anlage gebaut sind, dürfen, wenn sie einmal auf ca. 1200° aufgeheizt sind, nicht mehr unter einen noch immer sehr hohen Wert fallen, da sonst die Steine reißen und damit die gesamte Anlage unbrauchbar würde [1]. Man könnte auch in moderner IT-Terminologie sagen, dass die Verfügbarkeitsanforderung gleich 100% ist, und zwar ohne Wartungsintervalle; das wäre ein Alptraum für jeden IT-Verantwortlichen.
Wie erreichte man nun bei dieser Kokerei eine solch hohe Verfügbarkeit? Unter anderem waren immer(!) kompetente, gut ausgebildete Mitarbeiter vor Ort, die diese Anlage betreuten. Zum anderen gab es Werkstätten, die in der Lage waren, defekte Komponenten entweder auszutauschen oder sogar selbst nachzubauen. Natürlich waren auch sehr ausgeklügelte Prozesse notwendig, um für alle Fehlerfälle gewappnet zu sein.
Offensichtlich sind die Ähnlichkeiten zu den Anforderungen an eine höchstverfügbare IT-Umgebung. Auch dort braucht man:
- engagierte, gut ausgebildete Mitarbeiter
- gut definierte und trainierte Prozesse
- Ersatzteile vor Ort (oder die Fähigkeit, sie zu erstellen)
- usw.
In beiden Fällen, in der IT-Umgebung und der Kokerei, braucht man eine resiliente Umgebung mit Mitarbeitern mit hoher Kontrollüberzeugung! Diese beiden Begriffe sollen im folgenden Abschnitt erklärt werden.
Resilienz und hohe Kontrollüberzeugung
Das Wort Resilienz (abgeleitet aus dem lateinischen resilire: zurückspringen, abprallen; wahrscheinlicher aber eingedeutscht aus dem englischen „resilience“ (u.a. Ausfallsicherheit)) beschreibt „die Toleranz eines Systems gegenüber Störungen“ [2]. Jedes Unternehmen, das auch in und nach Störfällen überleben möchte, sollte resilient sein. Ein schönes Beispiel für ein resilientes Unternehmen gibt Eberhard Huber in seinem Vortrag „Resilienz vor Effizienz“, den er im Juni 2014 gehalten hat [3]. Er zeigt auf, warum die Resilienz eines Unternehmens nicht seiner Effizienz geopfert werden sollte. Hier hat ein Unternehmen in Form einer Instandhaltungs-Abteilung Vorkehrungen getroffen: Sie sollen helfen, in geplanten und ungeplanten Störungsfällen für einen Weiterbetrieb ohne oder mit minimaler Unterbrechung zu sorgen. In einer kritischen Situation – der Bagger hatte die Stromversorgung unterbrochen – waren die Mitarbeiter dieser Abteilung in der Lage, dieses Problem zu beheben. Inzwischen gibt es in diesem Unternehmen diese Abteilung nicht mehr und es ist fraglich, ob es beim nächsten Störfall wieder so schnell und einfach weiterarbeiten kann.
Als entscheidendes Merkmal für die Mitarbeiter eines solchen resilienten Unternehmens nennt Huber eine „hohe Kontrollüberzeugung“. Diese bewirkt, dass Menschen sich zutrauen, auch in schwierigen Situationen ihre Aufgaben zu erfüllen, vielleicht sogar über sich hinauswachsen. Genau diese Eigenschaft macht in einer Katastrophensituation den Unterschied zu Unternehmen, in denen alle warten, dass ihnen gesagt wird, was zu tun ist, und in denen das Management dann hinter diesen Menschen steht und fragt: „Warum geht das nicht schneller?“.
Dieser Vortrag hat mich sofort an die unterschiedlichen Betriebsmannschaften in der IT erinnert, mit denen ich seit mehr als 30 Jahren zu tun habe. Da gibt es die exzellenten Techniker, Analytiker und Macher, die mit dem notwendigen Selbstvertrauen ausgestattet sind, in einer Krise auch mal selbst eine Entscheidung zu treffen und zu handeln. Und da gibt es die, die da sitzen und auf Anweisungen warten.
Resilienz und hohe Kontrollüberzeugung sind also wesentliche Eigenschaften, die in Unternehmen, die Katastrophen überleben wollen, vorhanden sein müssen.
Hochverfügbarkeit vs. K-Fall-Vorsorge
Um jetzt den Bogen zu spannen von den sehr allgemeinen Anforderungen an Unternehmen und Mitarbeiter hin zu IT-spezifischen Anforderungen, sollen typische Fehlersituationen betrachtet und kategorisiert werden. Fehler, Störungen, Ausfälle passieren – in der Hardware, in der Software, im Betrieb und in der Umgebung. Viele dieser Fehler sind statistisch vorhersagbar, z.B. Festplattenausfälle oder Hauptspeicherfehler (wobei das Verständnis für statistische Zusammenhänge in der Regel eher dünn ist). Für solche immer wiederkehrenden Fehler sind deshalb Mechanismen vorhanden, die sie automatisch erkennen und „reparieren“ sollen, so dass die Komponenten, die diese nutzen, dies gar nicht oder sehr marginal beeinträchtigt.
Sind die Fehler komplexer, z.B. Ausfall eines kompletten Rechners oder Netzwerks, werden andere Mechanismen genutzt wie z.B. Cluster-Technologien, um diese Fehler zu beherrschen. Wieder ist das Ziel, die Beeinträchtigung aller Komponenten, die die fehlerhaften nutzen, zu minimieren.
Leider gibt es aber Fehler, die noch komplexer sind und nicht durch Automatismen zu beheben sind: Katastrophen. Das folgende Flussdiagramm soll die unterschiedlichen Fehlerklassen und die notwendigen Sicherungsmaßnahmen grafisch darstellen.
Wenn ein Fehler in einem fehlerfrei laufenden System auftritt, kann dieser, wenn er einzeln auftritt und hinreichend einfach ist, durch Automatismen behoben werden, ohne dass ein manueller Eingriff mit seinen potentiell negativen Folgen (Transaktionsverluste, Dienstunterbrechungen, usw.) notwendig ist.
Wenn dieser Fehler nicht einzeln, sondern mehrfach auftritt oder nicht einfach, sondern komplex ist und noch nicht antizipiert wurde und es somit auch keinen Automatismus gibt, mit dem diesem Fehler begegnet werden könnte, ist es zunächst notwendig, die Fehlerursache zu finden. Dies kann, muss aber nicht lange dauern. Ist nun der Fehler einfach/lokal behebbar, ist das System – relativ – schnell und problemlos wieder verfügbar. Ist entweder die Analyse langwierig oder das Ergebnis deutet auf eine Katastrophe hin, ist in der Regel ein Schwenk auf ein K-Fall-System oder sogar in ein K-Fall- Rechenzentrum notwendig. Schon zu Beginn der Fehleranalyse müssen wohldefinierte Prozesse greifen, die den Analyse-Prozess treiben, aber auch die notwendigen Benachrichtigungsketten starten.
Interessant ist, dass der Begriff Katastrophe noch gar nicht genauer definiert wurde. Stattdessen wurde sie implizit erklärt als ein komplexer oder ein Mehrfach-Fehler. Ich bin sicher, dass genau hier ein großes Problem in den IT-Abteilungen herrscht. Man betrachtet die alltäglichen, von den Nachrichten verbreiteten Katastrophen und meint, diese können einen nicht treffen und damit sei man in den allermeisten Fällen auf der sicheren Seite. Überlegt man aber einmal, welche komplexen oder Mehrfach-Fehlersituationen auftreten können, ändert sich das Bild.
Schauen wir uns solche Fehler einmal näher an:
Mehrfachfehler:
- gleichzeitiger Ausfall redundanter Storage Area Networks
- gleichzeitiger Ausfall zweier Rechner in einem 2-Knoten-Cluster
- gleichzeitiger Ausfall zwei aufeinander gespiegelter Platten
- usw.
(Natur-) und andere Katastrophen:
- Feuer im RZ
- großräumiger Stromausfall
- Flugzeugabstürze
- usw.
komplexe Fehler:
- Datenkorruption
- nicht mehr bootende Cluster
- nicht mehr bootende Betriebssysteme
- massive, nicht einfach zu behebende Softwarefehler
- usw.
Es ist offensichtlich, dass solche Fehler mit normalen Mitteln, d.h. auch mit Redundanz und Hochverfügbarkeitstechnologie nicht beherrschbar sind.
Betrachtet man Mehrfachfehler, so sind diese statistisch zwar weniger wahrscheinlich als einfache Fehler, aber sie können auftreten. Und wenn sie auftreten, haben sie sehr schwerwiegende Folgen.
Eine einfache Abwehrmaßnahme mag sein, die Redundanz zu erhöhen, z.B. Hinzufügen eines weiteren Spiegels, Erweitern eines 2-Knoten-Clusters zu einem 3-Knoten-Cluster, usw.. Jetzt ist die statistische Wahrscheinlichkeit eines Fehlers, der die gesamte Redundanz betrifft, zwar noch kleiner geworden, aber sie ist nicht Null. Ein Restrisiko besteht, das beherrscht werden muss.
(Umwelt-)Katastrophen sind am einfachsten zu verstehen; und es gibt viele Mittel, sie zu verhindern: redundante Stromanbindung an mehrere Versorger und eigene Stromaggregate, Rechenzentren unter der Erde, in Bunkern, in der Wüste, usw. Damit lassen sich einige dieser Risiken minimieren, aber nicht beseitigen.
Die komplexen Fehler sind die schwierigsten und gefährlichsten. Eine komplette Ursachenforschung (root cause analysis) ist schwierig und u.U. langwierig und die Behebung solcher Fehler noch langwieriger. (Hat man z.B. erkannt, dass eine Datenkorruption vorliegt, muss analysiert werden, was die Ursache war. Hat man die erkannt, muss jemand (der Hersteller der Software) den Fehler in der Software beheben, qualitätssichern und wieder ausliefern. Das kann Monate dauern.)
In bestimmten Fällen kann es einfach sein, die Fehlersituation zu beherrschen, z.B. durch den Einsatz von Technologien, die ein schnelles Zurückspielen alter, konsistenter Daten erlaubt. In vielen Fällen ist allerdings die einzige Chance, auf ein Ausweichsystem mit konsistenten Daten zu schwenken und den Produktionsbetrieb von dort wieder aufzunehmen.
Das Problem der Datenkorruption wird dadurch verschärft, dass sie in der Regel nicht einfach zu erkennen ist. Bei dem Versuch, mein Foto (s. Abb. 2) sichtbar, d.h. durch Bildbetrachter erkennbar, in einen inkonsistenten Zustand zu bringen, musste ich eine ganze Menge Daten verändern und löschen, bevor die Datenkorruption sichtbar wurde. D.h. Datenkorruption kann vorhanden sein, ohne dass sie bemerkt wird.
Aus meinen Erfahrungen halte ich Datenkorruption und nicht mehr startbare Betriebssysteme und Cluster für die häufigsten Katastrophen. Deshalb muss die Absicherung gegen ihre Folgen an oberster Stelle stehen. Eine DR-Lösung muss solche Probleme beherrschbar machen!
Anforderungen an eine Disaster-Recovery-Lösung
Wenn ein Unternehmen gegen alle Eventualitäten gewappnet sein will oder wegen gesetzlicher Vorschriften gewappnet sein muss, ist eine Disaster Recovery Lösung notwendig. Diese DR-Lösung muss unter allen möglichen Umständen sicherstellen, dass der (Geschäfts-)Betrieb eines Unternehmens selbst unter widrigsten Umständen weiter geführt werden kann.
Wenn eine DR-Lösung nicht nur eine Wiederherstellung (Recovery), sondern sogar einen unterbrechungsfreien Betrieb auch im K-Fall ermöglicht (oder besser: ermöglichen soll), umso besser. Aber auch solche Lösungen sind anfällig gegen die oben diskutierten Fehlersituationen und müssen mit der gebotenen Sorgfalt ausgewählt und getestet werden.
Die zentrale Frage ist also: wie implementiert man DR-Lösungen?
Die wichtigsten beiden Anforderungen sind:
- die DR-Umgebung muss unter allen Aspekten so unabhängig wie möglich von der Produktionsumgebung sein und
- die Umgebungen dürfen keinen Single Point of Failure enthalten!
Diese Anforderung bis zur letzten Konsequenz umzusetzen, ist unmöglich. Aber man sollte zunächst bei den einfachen Dingen beginnen. Es ist klar, und jeder macht es, die beiden Spiegelhälften eines RAID-Sets auf verschiedenen Platten abzulegen. Aber wenn beide Platten doch noch im selben Rechner oder Gehäuse stecken und vielleicht sogar über denselben Controller angesprochen werden, sind sie nicht so unabhängig, wie sie sein könnten. Also würde ein deutscher IT-Verantwortlicher die beiden Spiegelhälften in Storage-Systemen in unterschiedlichen Rechenzentren konfigurieren. Reicht das aus? Nun, „it depends“. Wenn beide Systeme am selben SAN (Storage Area Network) hängen, sind sie nicht unabhängig. Also redundante SANs über zwei Rechenzentren. Ausreichend? Sind die SANs wirklich gefeit gegen Fehler? In vielen SANs stehen SAN Switches desselben Herstellers, häufig auch vom selben Typ. Es hat Fälle gegeben, in denen Software-Updates in diesen Switches dazu geführt haben, dass das SAN ausfiel und nicht mehr gestartet werden konnte – beide SANs. Ist es also notwendig, die wichtigsten Komponenten mit unterschiedlichen Komponenten mit unterschiedlichen Softwareständen zu betreiben? Wieder: „It depends.“ Häufig schreibt der Hersteller ja vor, dass nur einheitliche Stände unterstützt sind. Also hat man keine Wahl. Das Risiko bleibt. Also braucht man eine K-Fall-Umgebung, die völlig getrennte SANs hat und in der man auch andere Software-Versionen fahren kann. Das sollte aber ausreichen. Nun, man kann argumentieren, dass SAN als Technologie ein SPOF sei und man am anderen Standort besser eine andere Technologie betreiben solle, die nichts mit Fibre Channel und SANs zu tun habe. Es gibt Unternehmen, die betreiben am alternativen Standort NAS-Systeme (Network Attached Storage) statt eines SANs. Sollte es jetzt zu einem fundamentalen Problem im SAN-Bereich kommen, kann man ja die Systeme in der K-Fall-Umgebung produktiv betreiben und die alten Systeme mit SANs als K-Fall-Systeme nutzen, sobald sie wieder verfügbar sind. Diese Argumentationskette kann man weiter treiben. Jeder Verantwortliche merkt, dass er bis zu einem bestimmten Punkt gehen muss und nicht weiter. Vielleicht hilft das folgende Beispiel aus dem Maschinenbau, die Problematik besser zu verstehen: Um die Anforderung der weitestgehenden Unabhängigkeit an einem Beispiel aus dem Maschinenbau zu erläutern, schaue man sich einen kurzen Ausschnitt aus einem Vortrag von Hans Bonfigt an (schlechter Ton, wichtig ist die Zeichnung ab 6:15):
Ein Kompressor befüllt einen Drucktank. Damit dieser nicht explodiert, hat er oben einen Sensor, der bei Erreichen eines Schwellwertes den Kompressor ausschaltet. Frage: Was passiert, wenn der Sensor defekt ist? Gute Frage, aber hier unterscheiden sich die Antworten von Maschinenbauern von denen von Informatikern. Der Informatiker würde sagen: bauen wir einen zweiten Sensor ein; der Maschinenbauer würde sich an die Regel der Prinzipverschiedenheit erinnern und einen zweiten, völlig verschiedenen und unabhängigen Mechanismus einbauen, ein Überdruckventil. Es ist ganz offensichtlich, dass eine doppelte Sicherung notwendig, aber nicht hinreichend ist. Erst der Einsatz eines im Prinzip unterschiedlichen Mechanismus macht die gesamte „Architektur“ sicher. Die Redundanz allein könnte an einem grundsätzlichen Problem in den Sensoren scheitern. Dieses Beispiel sollte man immer vor Augen haben, wenn man eine sichere K-Fall-Absicherung implementieren will. Die Diskussion über unterschiedliche und unabhängige Technologien kann man auch über die Anwendungssoftware führen. Es hat Fälle gegeben, in denen eine Anwendungssoftware wegen eines Programmierfehlers ausgefallen ist und nicht mehr gestartet werden konnte. Könnte man jetzt seine Daten mit einer alternativen Software weiter verarbeiten, dann …
Replizierung kompletter virtueller Umgebungen
Betreibt man eine IT-Umgebung, die in einer Katastrophen-Situtation den Betrieb übernehmen soll, müssen die Daten möglichst aktuell in dieser Ausweich-Umgebung vorhanden sein. Zwei Fragen stellen sich: welche Daten und wie werden diese repliziert?
Seitdem virtuelle Maschinen in den Produktionsbetrieb großer Unternehmen Einzug gehalten haben, werden solche Umgebungen als sehr geeignet für einfache DR-Umgebungen gepriesen. So schreibt IBM in seinem Whitepaper „Resilience in the era of enterprise cloud computing“ [4]:
„Virtualization techniques enable organizations to improve their recovery time objectives (RTO) and recovery point objectives (RPO) by allowing system images, associated configuration specifications, and all applications and data to be encapsulated and transmitted to a remote site for use in recovery.“
Diese Aussage ist nicht grundsätzlich falsch, aber unvollständig. Natürlich können Replikas virtueller Maschinen heute problemlos auch in weit entfernten Storagesystemen erstellt werden. Und sie können auch in vielen Fehlerfällen einigermaßen problemlos gestartet und in Betrieb genommen werden. In der Regel ist es zwar nicht mit dem Start einer VM getan und es muss noch viel mehr Infrastruktur richtig konfiguriert werden, damit ein Geschäftsprozess in einem entfernten RZ auch richtig funktioniert. Aber das ist nicht der Punkt.
Die wichtige Frage ist: ist eine Kopie einer virtuellen Maschine weitestgehend unabhängig von der Original-VM, die produktiv arbeitet? Um diese Frage zu beantworten, muss man betrachten, wie die Kopie erstellt wurde oder wird. Grundsätzlich gibt es mehrere Möglichkeiten:
- Kontinuierliche Replikation der Daten – Vorteil: die Daten sind immer aktuell; Nachteil: es können auch Fehler mit repliziert werden, die die Kopie der VM unbrauchbar machen; z.B. kann ein Administrator einen fehlerhaften Patch einspielen, der dann unmittelbar auch in der replizierten VM vorhanden ist.
- Kopie von „Snapshots“ – Vorteil: Dateninkonsistenzen und Fehlkonfigurationen können u.U. vor einer Replikation erkannt werden; Nachteil: je nach Häufigkeit der Replikation kann es beim Ausfall der produktiven VM zu Datenverlust kommen.
- Völlig unabhängig erstellte und administrierte VM – Vorteil: vollständig unabhängig. Fehler in der Produktion schlagen nicht auf die entfernte Kopie durch; Nachteil: Mehraufwand für die Erstellung und Verwaltung.
Eine kontinuierliche Replikation erfüllt nicht die Anforderung, möglichst unabhängig zu sein. Stattdessen sind Quelle und Ziel der Replikation immer identisch, was in vielen Fehlerfällen dazu führt, dass die replizierte VM ebenso unbrauchbar wird wie die Quelle. Damit ist das Ziel der DR-Lösung, eine unabhängige Umgebung für den K-Fall bereit zu stellen, nicht erfüllt. Auch ist die Replizierung von Snapshots nicht ungefährlich, da auch Inkonsistenzen repliziert werden können.
Meine Empfehlung ist es, virtuelle Maschinen überhaupt nicht zu replizieren, sondern unabhängig aufzusetzen und zu verwalten. Damit ist die volle Unabhängigkeit von Quell- und Ziel-VM gewährleistet. Der Mehraufwand, die beiden Kopien (mehr oder weniger) synchron zu halten (was vielleicht sogar wünschenswert oder sogar technisch notwendig ist), lässt sich in gut administrierten Umgebungen, die über ein gutes Change Management verfügen, vernachlässigen. Was nicht vernachlässigt werden darf, sind: gutes Training für die Mitarbeiter, die im K-Fall schnell und fehlerlos agieren müssen, und regelmäßige Schwenkübungen.
Was natürlich repliziert werden muss, sind die Nutzdaten, die für den produktiven Betrieb notwendig sind.
Replikation von Daten
Die für die Replikation virtueller Maschinen beschriebene Problematik existiert auch für die Replikation von Nutzdaten. Wie sollen z.B. Daten einer Datenbank vom Produktiv- ins Ausweich-RZ repliziert werden? Lange Zeit war eine storage-basierte Replikation das Maß aller Dinge, vor allen Dingen gepusht von den Herstellern solcher Systeme und der dazugehörigen Software.
Storage basierte Replikation, die in der Regel jeden geänderten Block auf der Quell-Seite auf die Ziel-Seite kopiert (block basiert), bringt aber genau das oben geschilderte Problem mit sich: eventuell existierende Datenkorruption wird unbemerkt mit repliziert und macht damit die Datenkopie wertlos. Der Einsatz der Sicherungsbänder, die hoffentlich konsistent sind und wieder eingespielt werden können, ist dann die letzte Rettung.
Was ist die sinnvolle Alternative? Eine anwendungsspezifische Replikationstechnologie zu verwenden, die die Strukturen der zu replizierenden Daten kennt und deshalb Datenkorruptionen direkt erkennen kann. Von Oracle gibt es zu diesem Thema ein schönes Whitepaper, das diese Problematik sehr gut erklärt: „Oracle Active Data Guard vs. Storage Remote Mirroring“ [5].
Zusammenfassung
Unternehmen, die sicherstellen wollen, dass sie auch nach einer Katastrophe ihre Geschäftsprozesse weiterhin erfolgreich betreiben können, müssen einen Business Continuity Plan haben und umsetzen. Im IT-Umfeld, das wichtige Teile eines Geschäftsprozesses zur Verfügung stellt, ist eine Disaster Recovery Umgebung notwendig, die weitestgehend unabhängig von der primären, produktiven Umgebung ist. Wie die Bedrohungslage für ein Unternehmen aussieht, gegen welche potenziellen Probleme man sich absichern will, wie weit diese „weitestgehende“ Unabhängigkeit tatsächlich implementiert wird, ist eine individuelle und sorgfältig zu analysierende Aufgabe. Auf keinen Fall sollen Gefahren unterschätzt werden, die nicht als klassische Katastrophe gelten: Datenkorruption und nicht mehr startbare Systeme.
Quellen:
[1] s. https://de.wikipedia.org/wiki/Kokerei
[2] s. https://de.wikipedia.org/wiki/Resilienz
[3] s. http://www.youtube.com/watch?v=OMC3D58IN-s
[4] s. IBM, 2014: Resilience in the era of enterprise cloud computing
[5] s. Oracle, 2014: Oracle Active Data Guard vs Storage Remote Mirroring
