Ein Ausfall großer Teile der IT bedeutet oft, dass das betroffene Unternehmen handlungsunfähig wird. ZDNet zeigt Wege auf, wie man die IT-Infrastruktur verfügbar hält, selbst wenn es zu hardwareseitigen Ausfällen kommt.
Wenn man in der IT auf gut Englisch von einem "Disaster" spricht, so ist häufig ein Ausfall des IT-Betriebes in seiner Gesamtheit oder wesentlicher Teile davon gemeint. Dabei gilt es zu bedenken, dass IT-Dienste heutzutage stark miteinander verzahnt sind. Fällt beispielsweise der interne LDAP-[1] oder DNS-[2]Dienst aus, so ist es Benutzern praktisch nicht mehr möglich, File- und Print-Sharing sowie E-Mail zu nutzen, da die Server nicht mehr erreichbar sind, obwohl sie einwandfrei funktionieren.
Aus der Sicht des Anwenders stellen sich Hardwarefehler oder ein softwaremäßiger Ausfall eines Dienstes zunächst identisch dar. Der einzige Unterschied ist, dass der DNS-Dienst meist schneller wiederhergestellt werden kann als eine durch Fehler im SAN[3] hervorgerufene Inkonsistenz im Filesystem, die den Restore eines Backups erforderlich macht.
Aus diesem Grund spricht man heute meist von Business Continuity Planning[4]. Der Ausfall eines Dienstes auf einem Server soll nach Möglichkeit keine Einschränkung des Betriebes hervorrufen. Ist dies trotzdem der Fall, müssen Planungen erfolgen, die den Betrieb in akzeptabler Zeit wieder herstellen.
Der Begriff "Disaster" ist in der IT nicht eindeutig spezifiziert. Das wäre auch nicht sinnvoll, da jede Organisation eigene Definitionen erstellen muss, wann ein Ausfall ein "Disaster" ist.
Wichtig ist dabei immer die Dauer eines Ausfalls zu berücksichtigen. In vielen Firmen ist ein Ausfall der gesamten Internetverbindung für 15 Minuten nicht gleich eine Katastrophe. Ein Ausfall, der den ganzen Tag dauert, kann schon gravierendere Folgen haben. Diese Sichtweise wird ein Aktienbroker, der Daytrading[5] betreibt, nicht teilen, wenn er Wertpapiere innerhalb von 15 Minuten verkaufen muss.
Grundlage für jede Form von Disaster Recovery sind Backup und Restore. Auch wenn moderne Storage-Lösungen, etwa SAN- oder NAS[6]-Systeme, hohe Ausfallsicherheit bieten, können sich Inkonsistenzen im Dateisystem einschleichen, die unter Umständen dazu führen, dass große Teile einer Partition unbrauchbar werden. Nicht zu unterschätzen ist dabei die Gefahr der Korruption von ganzen Partitionen durch Malware[7].
Nach wie vor ist das Active Directory[8] von Microsoft ein großer Schwachpunkt. Das Active Directory ist eine verteilte Datenbank mit Schreibmöglichkeiten für den gesamten Datenbestand auf allen Servern. Diese sogenannte Multimaster-Replikation ist fehleranfällig. Ein Korruption der Datenbank tritt relativ häufig auf. Die Wahrscheinlichkeit steigt mit der Anzahl der Benutzer und der Anzahl der Domain Controller[9] in einem Netzwerk. Das Active Directory muss daher besonders häufig gesichert werden.
Bei der Auswahl einer Backup-Lösung bleibt es nicht aus, den Wiederherstellungsfall zu testen. Zu so einem Test gehört immer die Wiederherstellung auf einer nackten Hardware ohne installiertes Betriebssystem. Viele Backup-Lösungen können einzelne Dateien oder Verzeichnisse komfortabel wiederherstellen. Ist das Betriebssystem selbst betroffen, so ist eine Wiederherstellung mittels Boot-Medium oft schwierig oder mangels Treiber unmöglich.
Bei Ausfall von Rechner und Daten, beispielsweise durch einen Brand, muss ferner beachtet werden, dass identische oder sehr ähnliche Hardware zum Restore verwendet werden muss. Selbst wenn ein Restore funktioniert, kann ein anderer Chipsatz oder ein ein anderer Prozessor dazu führen, dass das Restore nicht bootfähig ist.
Klassische Backup-Systeme sichern Daten auf Bändern, die heute allerdings meist als Festplatten realisiert sind. Die Platten stellen sich über eigene Treiber als Bandlaufwerke dar. In diesem Fall spricht man von Virtual-Tape-Libraries[10].Die klassischen Backup-Lösungen werden heute zunehmend durch modernere auf der Snapshot-Technologie basierende Lösungen verdrängt. Mit Continous Data Protection[11] (CDP) lassen sich Partitionen komplett auf den Stand eines Snapshots zurücksetzen. Bei einer CDP-Lösung werden alle Daten permanent auf ein Zweitsystem gesichert. Ein "Backupfenster" in der Nacht wird damit hinfällig. So wird ein ernsthafter 24x7-Betrieb erst möglich. Hat ein Benutzer während eines Backupfensters eine Datei exklusiv im Zugriff, so muss sie von der Sicherung ausgeschlossen werden.
Beim Backup mittels eines CDP-Systems müssen zwei grundsätzliche Methoden unterschieden werden: synchron und asynchron. Bei einer synchronen Lösung wird jede Änderung unmittelbar auf das Backupsystem mitgeschrieben. Eine Schreiboperation gilt erst abgeschlossen, wenn sie auf dem Primärserver und auf dem Backupsystem durchgeführt wurde. Diese Methode kostet einiges an Performance. Die bekanntesten Lösungen sind DoubleTake[12], everRun FT[13], Neverfail[14] und WANSync[15].
Bei einem asynchronen System werden Änderungen an einer Datei zunächst protokolliert. Das Backupsystem kopiert die geänderten Dateien je nach Auslastung mit einer Verzögerung von wenigen Sekunden bis hin zu einigen Minuten. Diese verzögerten Systeme werden oft als Add-on für klassische Backup-Lösungen, etwa von CA[16], Symantec[17] oder Microsoft[18], angeboten.
Vom Standpunkt der Wiederherstellung haben CDP-Systeme eindeutig Vorteile. So schnell die Snapshots erzeugt sind, so schnell sind sie auch wieder zurückzuholen. Statt umständlicher Suche nach den Sicherungsbändern und deren Rücksicherung wird ein Snapshot kurzerhand wiederhergestellt.
Gute Backup-Lösungen bieten für den Endanwender die Möglichkeit, selbst Dateien zu einem beliebigen Zeitpunkt wiederherzustellen. Einige erlauben sogar die Nutzung des in Vista bereitgestellten Benutzerinterfaces. Das Prinzip ist identisch zu Apples Time Machine[19] - nur mit schlichterem Dialog.
Einige CDP-Lösungen erlauben die Nutzung des Vista-Benutzerinterfaces.
Wenngleich CDP-Systeme einen enormen Vorteil gegenüber einer Bandsicherung aufweisen, wird dieses Verfahren dennoch nicht überflüssig. Für die langfristige Archivierung von Daten über viele Jahrzehnte sind bislang nur Bänder geeignet.Häufig besteht die Anforderung, Daten an einem zweiten Standort vorzuhalten. Hier kommen Replikationstechniken zum Einsatz. Viele Storagesystemhersteller bieten heute Lösungen für eine Replikation zu verschiedenen Standorten an.
Die Replikationsmechanismen sorgen dann selbständig für eine Replikation der Daten auf ein zweites Speichersystem. Eine separate Softwarelösung entfällt. Fast immer ist es dazu erforderlich, an beiden Standorten ein Storagesystem vom selben Hersteller zu verwenden.
Auch bei der Replikation unterscheidet man synchrone und asynchrone Lösungen. Die synchrone Replikation sichert die Daten immer aktuell, sie benötigt dazu aber meist teure Fibre-Channel-Systeme und ist damit auch in der Entfernung begrenzt. Durch die asynchrone Replikation lassen sich auch weite Distanzen überbrücken. Einigermaßen schnelle IP-Strecken sind ausreichend. Je nach Geschwindigkeit der Strecke können Verzögerungen von bis zu mehreren Stunden auftreten.
Will man sich nicht an einen Storage-Systemhersteller binden, bieten sich auch Softwarelösungen an. Windows-Server bieten mit dem Distributed File System[20] (DFS) eine ähnliche Technologie, die allerdings dateibasiert ist. Da sich keine Registry-Einträge[21] und Bootsektoren replizieren lassen, ist es nicht möglich, ein bootfähiges Image zu replizieren. Die Replikation ist auf Daten beschränkt.
Replikationstechniken dürfen auf keinen Fall als Ersatz für Backups verwendet werden. Löscht ein Administrator versehentlich einen ganzen Verzeichnisbaum, so wird der Löschbefehl in Bruchteilen von Sekunden auf das replizierte Stroagesystem übertragen. Ein zweiter Standort muss immer mit einer CDP-Lösung separat abgesichert werden.Die Sicherung von Daten, Installationen und Konfigurationen stellt einen wichtigen Teil der Disaster-Recovery-Strategie dar. Mindestens genauso wichtig ist die ausfallsichere Bereitstellung von Diensten.
Alle Dienste sollten so konfiguriert sein, dass sie bei einem Absturz neu starten. In den meisten Fällen behebt ein Neustart das Problem. Für die verbleibenden Fälle, die auch einen Hardwareausfall am Server einschließen, sollten alle Dienste redundant bereitgestellt werden. Sofern keine identische Ersatzhardware unmittelbar an ein funktionierendes Storagesystem angeschlossen werden kann, dauert ein Restore auch bei perfekter Planung immer mehrere Stunden.
Relativ einfach ist das für Basisdienste, etwa DNS, WINS[22] oder Active Directory. Sie sind bereits für den redundanten Betrieb konzipiert. Schwieriger wird es schon bei DHCP[23]. Die meisten DHCP-Server, beispielsweise der Microsoft-DHCP-Server, beherrschen keinen Austausch über vergebene IP-Adressen. Fällt ein DHCP-Server aus, so müssen die verbleibenden Server über einen Adressraum verfügen, der ausreicht, alle Clients im Firmennetz mit IP-Adressen zu versorgen.
File-, Print, Mail- und Datenbankserver lassen sich nicht so einfach redundant betreiben. Hier müssen Failover-Systeme[24] herangezogen werden. Dabei steht meist neben dem aktiven Server ein zweites Gerät als passiver Standby-Server. Dieser springt immer dann ein, wenn der primäre Server ausfällt.
Failover-Systeme im Aktiv/Passiv-Verfahren reduzieren somit die Ausfallzeit auf wenige Minuten. Die Ausfallzeit hängt in erster Linie davon ab, wie schnell der Administrator benachrichtigt wird und den Umschaltvorgang einleitet. Da die automatische Erkennung eines Serverausfalls nicht perfekt ist, wählt man meist eine Konfiguration, die den Administrator manuell umschalten lässt.
Failover-Lösungen sind heute für die meisten Dienste verfügbar. Sie bedingen jedoch immer, dass ein Server vorgehalten wird, der im normalen Betrieb keine Funktion erfüllt. Aktiv/Aktiv-Cluster-Lösungen[25] erlauben die produktive Nutzung aller Hardware-Ressourcen.
Nicht alle Dienste lassen sich so leicht im Aktiv/Aktiv-Verfahren zu einem Cluster verbinden. Relativ einfach ist eine solche Lösung für File- und Print-Sharing realisierbar. Fällt ein Server aus, so kann ein zweiter die LUNs[26] eines Storagesystems übernehmen und das Filesharing für den ausgefallenen Server kurzfristig weiterführen.
Webserver können über eine Load-Balancing-Lösung zu einer Farm verbunden werden. Zu beachten ist, dass die Load-Balancing-Lösung wiederum redundant ausgelegt werden muss.
Mail- und Datenbankserver müssen in der Lage sein, ihre Daten über mehrere Server zu partitionieren, so dass Schreiboperationen immer nur von einem Server ausgeführt werden. Fällt eine Hardware aus, so kann ein anderer Server die Aufgaben übernehmen.Da Failover- und Clusterlösungen teilweise sehr kompliziert zu realisieren sind, setzt man als Alternative immer häufiger Virtualisierungslösungen ein. In einer virtuellen Maschine laufende Server können mit Technologien wie VMotion[27] von VMware[28] im laufenden Betrieb ohne Reboot auf eine andere physikalische Hardware gebracht werden.
Moderne Virtualisierungslösungen, beispielweise VMware ESX-Server 3i[29], lassen sich von einem USB-Stick mit 32 MByte Speicher booten und innerhalb weniger Minuten installieren. Virtuelle bootfähige Disks laufen unter jeder Hardware, da alle Komponenten von der Virtualisierungslösung emuliert werden. Die Zeit für die Wiederherstellung eines ausgefallenen Servers reduziert sich drastisch.
Aus Virtualisierung resultieren aber noch andere Vorteile: Teilweise komplizierte Failover- oder Cluster-Konfigurationen entfallen vollständig. Signalisiert eine Hardware, dass ein Ausfall kurz bevor steht, beispielsweise wegen eines defekten Lüfters, so kann der gesamte virtuelle Server ohne Betriebsunterbrechung auf eine andere Hardware gebracht werden. Ferner lassen sich außerhalb normaler Geschäftszeiten mehrere virtuelle Server auf eine Hardware zusammenfassen. Nicht genutzte Server werden ausgeschaltet.
Ihr großer Nachteil ist allerdings, dass Virtualisierung beim heutigen Stand der Technik eine Menge an I/O-Performance kostet. Insbesondere die I/O-Latenz nimmt stark zu. Performancekritische Datenbankanwendungen lassen sich mit aktueller Technologie meist nicht virtualisieren.
Schaut man ein wenig in die Zukunft, so werden virtuelle Server Failover- und Cluster-Lösungen fast vollständig ersetzten. Intel kann bereits mit VT-d[30] eine Technologie liefern, die virtuellen Maschinen direkten Zugriff auf die I/O-Hardware erlaubt. Die Integration in gängige Virtualisierungslösungen steht kurz bevor.
Clustering und Load-Balancing werden dann relevant bleiben, wenn die Leistung eines Rechners nicht ausreicht und ein Serverdienst über mehrere physikalische Rechner skaliert wird. Für die Ausfallsicherheit der Hardware gibt es einfacher zu verwaltende Lösungen.Eine ideale IT-Umgebung ist so konzipiert, dass der Benutzer den Eintritt eines Katastrophenfalles gar nicht bemerkt. Fällt ein Storagesystem oder ein Server in seiner Gesamtheit aus, so gibt es durchaus Lösungen, die dies ohne jegliche Betriebsunterbrechung auffangen können.
Solche Lösungen sind allerdings mit hohen Kosten verbunden. Geht man die Themen Disaster Recovery und Business Continuity Planning rational an, so sollte man sich Gedanken über die Anforderungen machen.
Die wichtigste Fragestellung ist dabei immer: Was sind die Konsequenzen, wenn ein Dienst für einen bestimmten Zeitraum nicht verfügbar ist? Diese Konsequenzen müssen gegen die Kosten für eine Business-Continuity-Lösung abgewogen werden.
Anstelle einer Failover-Lösung, mit einem zweiten Server "on hold" kann beispielsweise ein Blade-System kostengünstiger sein. Fällt ein Blade aus, so kann schnell ein Ersatzblade in das Rack eingeschoben werden. Verwendet man ein Blade-System mit sechs Blades, so reicht meist ein siebtes Blade aus, um die übrigen sechs ausreichend abzusichern. Blade-Systeme, beispielsweise der Intel Modular Server[31], sind heute nicht länger nur Großunternehmen vorbehalten, sondern werden gezielt auch für den Mittelstand[32] konzipiert.
Das größte Risiko besteht heute meist darin, dass das Restore eines Backups möglicherweise nicht funktioniert. Muss ein Server, der von Direct Attached Storage[33] (DAS) bootet, wegen eines Totalausfalls komplett aus einem Backup neu aufgebaut werden, so sollte man diesen Fall explizit testen. Wird eine Ersatzhardware verwendet, so kann bereits eine andere BIOS-Version trotz identischer Hardware dazu führen, dass der Server nach dem Restore nicht hochfährt.
URLs in diesem Artikel:[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/
[26] = http:/
[27] = http:/
[28] = http:/
[29] = http:/
[30] = http:/
[31] = http:/
[32] = http:/
[33] = http:/