.shock - Fotolia

Warum ein Failover-Plan wichtig und sinnvoll ist

Ein Failover zu einem anderen RZ kann sich als schwierig erweisen. Ein Plan mit wichtigen Punkten hilft, ein erfolgreiches Failover zu realisieren.

Dieser Artikel behandelt

Disaster Recovery

Große Unternehmen investieren im großen Stil in Technologien, die ihnen helfen sollen, während eines Rechenzentrumsausfalls geschäftsfähig und betriebsbereit zu bleiben. Natürlich hofft der Anwender, dass solch ein Fall nie eintritt; was aber, wenn es doch zu einem Katastrophenszenario dieser Art kommt? Was, wenn das RZ schon morgen einem Brand zum Opfer fällt? Verfügen Sie oder Ihre IT-Abteilung über einen Failover-Plan? Wissen die Verantwortlichen, was in solch einem Fall zu tun ist, um den Betrieb aufrecht zu erhalten?

Im besten Fall hat das Unternehmen einen Failover auf ein anderes Rechenzentrum mehrfach geübt und geplant. Falls nicht, so sollten Firmen einige Dinge beachten, wenn sie einen Failover-Plan erstellen wollen.

Bestimmen Sie das Ausmaß des Desasters

Stellen Sie zunächst fest, ob die Situation wirklich so schlimm ist, dass sie einen RZ-Failover rechtfertigt. Prüfen Sie, ob noch einige Systeme funktionieren und ob die verantwortlichen Mitarbeiter für den Failover verfügbar sind. Mit diesen Randdaten lässt sich die weitere Vorgehensweise bestimmen.

Achten Sie auf Applikations-Abhängigkeiten

Ein Failover-Plan umfasst sehr viel mehr als nur die Anleitung, wie man virtuelle Maschinen in einem externen Rechenzentrum wieder in Betrieb nimmt und online stellt. Das wichtigste Ziel ist es, geschäftskritische Anwendungen verfügbar und funktionsfähig zu halten. VMs sind die Infrastrukturkomponenten, auf denen die Applikationen laufen. Nichtsdestotrotz kommt es auf die Anwendungen an. Alle VMs im Failover-RZ in Betrieb zu nehmen, garantiert nicht, dass die Anwendungen dort reibungslos funktionieren. Oftmals müssen Abhängigkeiten der Applikationen adressiert werden, bevor sie wieder läuft.

Zu den häufigsten Abhängigkeiten zählen das Domain Name System (DNS), das Active Directory oder eine Datenbank. Microsoft Exchange Server funktioniert nicht ohne Active Directory; und das Active Directory operiert nicht ohne DNS. Es kann sein, dass einige VMs neu konfiguriert werden müssen, damit sie einen anderen DNS-Server ansprechen. Erst danach lassen sich das Active Directory oder davon abhängige Anwendungen nutzen.

Anwendungen im Primärrechenzentrum und die Folgen

Falls das primäre RZ nur noch ein Aschehaufen darstellt oder ein Loch im Boden, so lassen sich auch keine Dienste mehr ausführen. Ist der Schaden weniger katastrophal, so lassen sich wahrscheinlich einige Ressourcen weiter nutzen. Das hört sich gut an, kann aber zu Problemen führen, wenn man nur einen Teil der Anwendungen im primären Standort operieren lässt, den Rest aber aus dem Failover-RZ heraus.

So nutzen Mailbox-Server wie Exchange Server 2013 beispielsweise ein Active/Passive-Verfügbarkeitsmodell. Sollte nun einer oder mehrere Server im Primär-RZ operieren, so kann es zu Problemen führen, wenn Exchange-bezogene Services zwischen den RZs verschoben werden. Microsoft selbst empfiehlt, alle Exchange-Server-Services im primären RZ abzuschalten.

Anwendungsspezifische Anforderungen

Nachdem die virtuellen Anwendungsserver ins zweite RZ transferiert wurden, müssen oft noch anwendungsspezifische Anforderungen erfüllt werden, um die Applikation wieder in einen funktionierenden Status zu bringen. Im Falle des Exchange Servers gibt es einen manuellen Aktivierungsprozess, der genutzt werden muss, um Mailbox-Server und Client-Access-Server wieder zu aktivieren. Andere verteilte Applikations-Server verfügen über ähnliche Prozesse.

Workloads in ein sekundäres RZ zu verschieben kann ein komplizierter Prozess sein. Deswegen ist es wichtig, einen Failover-Plan zu erstellen und den Prozess zu verstehen, bevor eine Katastrophe eintritt. Bei einem Failover geht es um mehr als um das Wiederherstellen von Services. Sind die Anwendungen wieder in Betrieb, so muss der Verantwortliche die Systeme auf potenzielle Probleme hin prüfen und einen Mechanismus aufsetzen, der die Anwendungen und Daten schützt, falls es zu einem weiteren Ausfall kommt, während der Primärstandort noch nicht wieder online ist.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Januar 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Disaster Recovery

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close