Was Sie über Failover und Failback wissen sollten

Wie wichtig sind Failover und Failback für Disaster Recovery?

Failover und Failback sind die essentiellen Komponenten eines Disaster-Recovery- (DR) oder Notfallwiederherstellungs-Plans. Unter der Annahme, dass Ihre DR-Infrastruktur adäquat konfiguriert ist (damit ist gemeint, dass Sie die aktuellen Systeme haben, die Sie brauchen, um Daten zu replizieren und einem zweiten Standort angemessen zu schützen), sind Failover und Failback die kritischsten Element bei der DR-Ausführung.

Wie stabil oder problematisch diese Operationen ablaufen steht und fällt normalerweise mit der Menge der Datenänderungen am primären Standort, der verfügbaren Bandbreite, und wie Ihre Daten kopiert und wie sie zum zweiten Standort gespiegelt oder repliziert werden.

Ein IT-Architekt sollte sich dafür interessieren, wie die Datenübertragung minimiert und gleichzeitig die Synchronisierung zwischen den Standorten maximiert werden kann. Dann ist es wichtig, sich darauf zu konzentrieren, wie ein Failover ausgelöst wird während man gleichzeitig die Zeit minimiert, die der Vorgang dauert. In diesem Bereich gibt es eine Reihe von Technologien, die sich teilweise stark unterscheiden. Aber die Technologie kann entscheidend sein, wie gut der Vorgang ausgeführt werden kann.

Es gibt einige Replikationstechnologien mittels Continuous Data Protection (CDP), das auch oft Continuous Backup oder Real Time Backup genannt wird und das die Daten fortlaufend, inkrementell sichert. Zu diesen Technologien gehört beispielsweise InMage, die zu Microsoft gehören: InMage minimiert die Datenübertragungen und maximiert die Synchronisation zwischen den Standorten.

Können Sie Failover und Failback definieren?

Bei Failover werden I/Os und die damit verbundenen Prozesse von einem Primärsystem auf ein sekundäres Backup- oder Standby-System verschoben. Dazu nutzt man typischerweise das Werkzeug eines Herstellers oder ein Drittanbieter-Tool eines bestimmten Typs. Dieses stoppt den Input/Output temporär und startet ihn am Standby-Standort neu.

Wie erwähnt wird der I/O vorübergehend angehalten, und das Kopieren von Daten und Spiegelungsaktivitäten an den zweiten Standort unterbrochen. Anwendungen und I/O-Aktivitäten werden dann auf die Remote Location hochgeladen.

Während Prozesse am Remote-Standort laufen, werden Änderungen in der Regel verfolgt, so dass ihr ursprünglicher Standort neu synchronisiert und wieder hergestellt werden kann. Dazu müssen nur die Daten repliziert werden, die zwischen dem Beginn und dem Ende des DR-Events angefallen sind. Wenn der primäre Server wieder in Betrieb genommen wird, werden diese Daten dann zurückgespiegelt. Bei diesem „Failback“ erfolgt also eine Re-Synchronisierung dieser Daten zurück an den primären Standort, das erneute Stoppen von I/O- und Anwendungsaktivität und das Zurückspiegeln an den ursprünglichen Speicherort.

Wie lange kann ein System im Failover-Betrieb laufen, wenn sich der Failback-Prozess verzögert?

Wie lange ein System oder eine Umgebung im Failover-Modus laufen kann, hängt von den Operationen ab, der Verfügbarkeit und dem Leistungsniveau des DR-Centers. Eine Rolle spielt auch, wie gut Mitarbeiter den laufenden Betrieb der Sekundärumgebung unterstützen können. Keiner dieser Aspekte sollte übersehen werden. Doch selbst wenn Sie einem Failover-Vorgang viel Zeit geben - seine möglichen Auswirkungen werden oft übersehen.

Organisationen sollten ihre DR-Funktionen immer zusammen mit den Auswirkungen auf die Mitarbeiter und die langfristige Verfügbarkeit des DR-Zentrums betrachten. Ein längerer Ausfall oder eine weit entfernte Anlage ist möglicherweise mit Ihrem vorhandenen Personal nicht zu bewältigen. Oder Ihre Mitarbeiter sind vielleicht gerade nicht verfügbar, wenn eine gravierende lokale Katastrophe eintritt.

Die entscheidende Frage ist: Wie viel kann automatisiert werden, um ein Failover einen längere Zeitraum zu überstehen? Wichtig ist natürlich auch, was das alles kostet.

Gibt es Best Practices für die Auswahl eines Recovery-Standorts? Wie wichtig ist dieser Schritt für den Gesamterfolg eines Failover-Vorgangs?

Es gibt heute viele IT-Einrichtungen. Ich denke, sie sind sich ziemlich ähnlich und liefern auch gleichartige Dienste. Sie werden immer nutzerfreundlicher und die Frage, was am besten geeignet ist, ist wohl immer mehr nur eine Kostenfrage. Achten Sie darauf, dass Sie während eines längeren Ausfalls Ihre Anforderungen einhalten können. Auch sollte Ihr Personal in der Lage sein, die Fernverwaltung der Failover-Anlage zu übernehmen.

Darüber hinaus sollten Sie auch prüfen, welche Service-Level-Agreements (SLAs) Sie derzeit im Einsatz haben. Diese müssen selbstverständlich auch während eines Failover-Zustands eingehalten werden. Insbesondere sollte die Backup-Einrichtung diese SLAs erfüllen können. Wenn wir eine DR-Anlage überprüfen, stellen wir ganz oft fest, dass zu kurzsichtig nur an Desaster-typische SLAs gedacht wird.

Leider vernachlässigen Anwender oft die betrieblichen SLAs, die sie intern verwenden und versäumen es, diese auf die DR-Infrastruktur zu übertragen. Denn auch dies kann von entscheidender Bedeutung sein, um das Business normal fortführen zu können. Sie tun sich nichts Gutes an, wenn Sie nur auf die Verfügbarkeit und den Betrieb achten und diesen aufrecht erhalten, aber die Leistung so schlecht wird, dass Sie Kunden oder Einnahmen verlieren.

Lohnen sich Failover-Operationen für Systeme, die fürs Tagesgeschäft unkritisch sind?

Wenn ich im Rahmen eines Projekts beurteilen müsste, welche Systeme ich in meinem Unternehmen schützen sollte, würde ich mir Gedanken um folgende Punkte machen:

• Die relativen Kosten von Systemausfällen für mein Unternehmen
• Die Kosten für den Schutz dieser Systeme
• Die Wahrscheinlichkeit für das Eintreten einer Katastrophe
• Die mögliche Ausfallzeit, die von einer Katastrophe verursacht wird

Ich würde diese Kriterien verwenden, um damit alle Systeme, die wichtige Geschäftsprozesse unterstützen, zu evaluieren. Das Gleiche würde ich mit allen Infrastruktursystemen machen. Dann würde ich sie auf ein Koordinatennetz legen, das mir die Kosten eines Ausfalls visualisiert und die Kosten für den Schutz jeder wichtigen Unternehmens-Anwendung.

Mit der Kostenschätzung eines Ausfalls und der Berücksichtigung dieser Kosten im Rahmen der Katastrophenvorsorge können Sie in Absprache mit dem Vorstand und der Geschäftsleitung einen Schwellenwert einführen. Was darüber liegt, muss unbedingt geschützt werden, was darunter liegt ist nicht unbedingt schützenswert. Auf diese Weise lässt sich beurteilen, ob Systeme fürs tägliche Business wirklich wichtig sind. Damit würde ich auch Systeme erfassen, die Unternehmen in der Regel als weniger kritisch einschätzen.

Nachdem diese Aufgabe erledigt ist, mach ich dasselbe für allgemeine operationale IT-Systeme wie E-Mail und allgemeine Infrastrukturdienste. Hier würde ich ein weiteres Element hinzuzufügen, nämlich die mögliche Anzahl von Systemen und Geschäftsprozessen, die von diesen Diensten abhängig sind.

Wie wichtig ist der Standort der Backup-Einrichtung, wenn eine Störung durch ein lokales Ereignis verursacht wird?

Aus meiner Sicht gibt es zwei Aspekte, auf die Anwender hier achten sollten: Ist Ihr Disaster-Recovery-Center im Falle einer lokalen Katastrophe, die Ihren primären Standort beeinflussen könnte, isoliert? Und ist Ihr Remote Center im Falle eines längeren Ausfalls leicht zugänglich? Ist das nicht der Fall, muss sich Ihr Team auf Remote-Management verlassen, und Sie sollten sicherstellen, dass alle Remote-Operationen mit Lights-Out-Technologie unterstützt werden.

Zunehmend ist es auch sinnvoll, DR-Lösungen in einer Cloud aufzubauen. Dies erfordert zwar für viele Organisationen eine größere Veränderung im Management, aber Cloud-Lösungen punkten damit, dass sie Ressourcen kosteneffizienter nutzen können und flexibler und besser skalierbar sind.

Ganz unproblematisch ist eine DR-Cloud-Lösung freilich auch nicht: Die Schwierigkeit liegt bei diesem Ansatz darin, dass Dienstleistungen mit Service Level Agreements nur mühsam zu garantieren sind. Zudem können diese Dienste bei einer großen Anzahl von Kunden im Fall eines Desasters zu einem massiven Leistungsabfall bis hin zu Komplettausfällen führen. In der Praxis kann sehr schwierig sein, mit der Infrastruktur eines Cloud-basierten Service-Providers adäquat umzugehen: Die Probleme reichen von einzelnen Sicherheitsanomalien bis zu Hürden bei branchenabhängigen Compliances und Regularien.

Dennoch gilt: DR in der Cloud ist sinnvoll. Die Cloud kann eine Menge Ihrer Bedenken auflösen, was die Lage eines Rechenzentrums betrifft. Denn der Cloud-Ansatz wird Sie zwingen, eine Menge Prozesse zu automatisieren. Und diese können dann remote mit jeder Art von Personal ausgeführt werden.

Wer sind die wichtigsten Akteure im Failover/Failback-Markt?

Alle großen Anbieter haben Lösungen im Angebot und einige davon gibt es sogar abseits der Betriebssystem-Ebene bei Backup-Anbietern. Ich würde bei Ihren wichtigsten Lösungsanbietern nachfragen und mit ihnen darüber sprechen, welche Ansätze sie empfehlen.

Ein anderer wichtiger Aspekt von Failover und Failback ist, zu prüfen, ob Ihre Services für die Synchronisierung und die vollständige Inbetriebnahme einer Recovery-Umgebung angemessen konfiguriert sind. Im Allgemeinen verlässt sich der IT-Praktiker sehr stark auf die manuelle Prüfung von Failover und Failback. Aber diese Prüfung basiert oft auf unrealistischen Annahmen.

Die meisten gehen davon aus, dass die Vorbereitungen für solche Tests helfen, die kritischen Punkte während einer unvorhersehbaren Katastrophe zu entschärfen. Meine Gespräche mit Endkunden haben jedoch gezeigt, dass diese Tests sehr löchrig sind und im schlimmsten Falle oft zu Ausfällen führen. Aktuell sehen wir eine wachsende Zahl von Anbietern, die ganzheitliche Lösungen auf den Markt bringen. Diese Lösungen managen und evaluieren die DR-Umgebung holistisch, und benutzen dafür zum Beispiel Continuity-Software. Die Software konzentriert sich auf die Verwaltung und Einrichtung Ihrer DR-Umgebung sowie die laufende Pflege. Sie zeigt insbesondere auf, welche Schwierigkeiten außerhalb der Spezifikation auftreten könnten, so dass Sie die möglichen Probleme schnell korrigieren oder die Problembehandlung automatisieren können.

Aus meiner Sicht bringen holistische Lösungen ziemlich viel Unruhe in den Markt. Sie kommen zwar bei den Endkunden sehr gut an und in lösen in großen Unternehmen einige wichtige Probleme lösen. Aber der Nutzen für kleinere Unternehmen ist relativ gering, weil sie in der Regel eine ziemlich komplexe Umgebung für das DR-Management haben.