Cold Standby als Alternative

Der Cold-Standby-Ansatz folgt einem anderen Ansatz. Hier besteht das Ziel meist darin, an einem anderen Standort eine Art Notbetrieb aufrechtzuerhalten, bis die ursprüngliche Site wieder zur Verfügung steht. Was im Klartext auch heißt: Weniger Hardware ist nötig und der größte Teil der benötigten Hardware muss nicht kontinuierlich laufen.

Zentrale Systemkonfiguration und Automation sollten freilich auch in Cold-Standby-Setups gegeben sein, um den zweiten Standort im Falle eines Falles schnell online zu bringen.

Weniger umständlich ist in solchen Umgebungen auch das Handling der Daten: Weil es eben keinen sofortigen Live-Gang beim Umschalten auf den anderen Standort gibt, ist es in der Regel ausreichend, ein aktuelles Backup am zweiten Standort zu haben. Dieses spielt der Admin ein, wenn der Katastrophenfall eintritt, um bestimmte Funktionen zu liefern.

Nota bene: Dieser Vorgang unterscheidet sich stark von der Replikation, die in Hot-Standby-Umgebungen zum Einsatz kommt. Cold-Standby-Setups sind üblicherweise nicht darauf ausgelegt, die Interaktion mit Daten zu ermöglichen - falls doch, läuft der Admin nach dem Umschalten ohne Replikation zwangsläufig in eine Split-Brain-Situation. Denn Site 2 hat ein (womöglich nur leicht) veraltetes Backup als Datenquelle und ändert dieses nach dem Go-Live der zweiten Site, während die ausgefallene erste Site neuere Daten hat als jene im letzten Backup. Geht die Haupt-Site wieder online, entscheidet der Admin händisch, welcher Datensatz dort wieder einzuspielen ist.

• 

BGP ist das zentrale Routing-Protokoll des Internets und sorgt dafür, dass die verschiedenen autonomen Systeme miteinander kommunizieren können (Bild: Wikipedia)

Cold-Standby-Lösungen bieten insofern den Vorteil, bei deutlich geringeren Kosten eine Disaster-Recovery-Option zu bieten. Der Funktionsumfang dieses Behelfs kann es mit der zuvor skizzierten Hot-Standby-Lösung allerdings nicht aufnehmen.

Verschlungene Pfade

Ganz gleich, ob ein Unternehmen für Disaster Recovery in kalt oder warm plant - eine Herausforderung ergibt sich in beiden Varianten: Wie finden Anwender nach dem Schwenk der Installation zu dieser? Technisch ist die Sache ja ganz simpel: Tippt ein Anwender in seinen Browser www.example.net ein, löst der Webbrowser diesen Hostname per DNS zu einer IP-Adresse auf und verbindet sich anschließend mit dieser. Die Art und Weise, wie das Internet funktioniert, macht es allerdings nicht ganz trivial, Anwender von einem hin zu einem anderen Standort umzuleiten. Praktisch ergeben sich zwei Optionen.

Option 1 ist, die DNS-Einträge für www.example.net zu ändern. Wie der erste Standort verfügt ja auch der zweite Standort über offizielle IP-Adressen, auf welche sich der DNS-Eintrag anpassen lässt. DNS-Updates dauern allerdings je nach Konfiguration eine Weile, und für den Betreiber einer Plattform gibt es keine Möglichkeit, ein Update auf der Client-Seite zu erzwingen. Wenn es ganz blöd läuft, spucken einem auch Caches der Provider noch in die Suppe. Diese Methode eignet sich insofern für Cold-Standby-Setups, die ohnehin eine gewisse Wiederanlaufzeit haben. Wer ein sofortiges Umschalten hin zu einem anderen Standort braucht, ist mit dieser Lösung aber nicht gut bedient.