Wie in Teil 1 bereits beschrieben, bietet die von Azure integrierte Lösung für SQL-Datenbanken bereits eine Verfügbarkeit von 99,99%.

Stellen wir uns vor, dass das Rechenzentrum, in dem unsere Datenbank liegt, von einer Naturkatastrophe komplett lahmgelegt wird. Zugegeben, das ist recht unwahrscheinlich. Aber angenommen es passiert und die Hochverfügbarkeitsstruktur reicht nicht mehr aus. Sind unsere Daten dann verloren?
Sogar für diesen ungewöhnlichen Fall kann man seine Azure SQL-Datenbanken eigenhändig vorbereiten und sekundäre Datenbanken für ein mögliches Failover einrichten. Hierfür gibt es zwei Lösungen: Aktive Georeplikation und Failovergruppen.

 

Aktive Georeplikation

Mit dieser Funktion können lesbare sekundäre Instanzen für einzelne Datenbanken auf einem SQL-Datenbank-Server im selben oder in einem anderen Rechenzentrum (also in einer anderen Region) erstellt werden.
Aktive Georeplikation nutzt die sogenannte Always On-Technologie, um Transaktionen mit ausgeführtem Commit in der primären Datenbank asynchron mit Momentaufnahmeisolation in eine sekundäre Datenbank zu replizieren.
Das Einrichten ist einfach über Azure Portal möglich: Gehen sie zu Ihrer Datenbank -> Einstellungen -> Georeplikation.

Es werden bis zu vier sekundäre Datenbanken unterstützt.
Das Failover muss durch die Anwendung oder den Benutzer manuell(!) eingeleitet werden. In diesem Fall tauschen die ursprünglich primäre und die ausgewählte sekundäre Datenbank ihre Rollen. Hierbei werden die anderen sekundären Datenbanken automatisch mit der neuen primären verknüpft.

Zusätzlich zur Wiederherstellung im Notfall kann aktive Georeplikation in folgenden Szenarien verwendet werden:

  • Datenbankmigration: Sie können die aktive Georeplikation zur Onlinemigration einer Datenbank von einem Server auf einen anderen mit minimalen Ausfallzeiten nutzen.
  • Anwendungsupgrades: Sie können bei Anwendungsupgrades eine zusätzliche sekundäre Datenbank als Failbackkopie erstellen.

 

Failovergruppen

Failovergruppen basieren auf der Methode der aktiven Georeplikation.
Um eine Failovergruppe einzurichten, gehen Sie zu ihrem Server, auf dem sich die SQL-Datenbank befindet, zum Menüpunkt Failovergruppen -> Gruppe hinzufügen und geben Sie den Gruppennamen, sowie den sekundären Server an, auf den die Datenbanken repliziert werden sollen.

Zu jeder Datenbank, die Sie auf dem primären Server hinzufügen, wird automatisch ein Replikat auf dem sekundären Server mit identischem Namen erstellt.

Im Falle eines Fehlers, der nicht durch die Hochverfügbarkeitslösung behoben werden kann, wird nun ein automatisiertes Failover für alle in der Gruppe enthaltenen Datenbankenpaare durchgeführt. Hierbei können allerdings noch nicht synchronisierte Daten verloren gehen. Zusätzlich kann jederzeit ein manuelles Failover mit vollständiger Datensynchronisierung initiiert werden.

Aus der vergleichenden Tabelle wird ein Nachteil der aktiven Georeplikation schnell deutlich: Das Failover muss manuell eingeleitet werden. Dabei kann es in der Zeit zwischen Ausfall und Initiierung des Failovers zu einem Verlust von Daten kommen.
Außerdem muss die Verbindungszeichenfolge nach einem Failover aktualisiert werden, da die Endpunkte bei der aktiven Georeplikation direkt auf die Datenbanken zeigen. Auch dies ist bei einer Failovergruppe automatisiert, da der Endpunkt, über den die Verbindung aufgebaut wird, selbst im Hintergrund entscheidet, auf welche Datenbank er physisch verweist (standardmäßig immer die primäre Datenbank). Dadurch wird ein Failover für den User vollständig transparent.
Zwar kann man seine Datenbank in einer Failovergruppe nur einmal direkt replizieren, jedoch ist es kein Problem einfach ein weiteres Pärchen zu der Gruppe hinzuzufügen. So kann eine Datenbank in beliebig viele Regionen repliziert werden.

Klingt so, als wäre die Failovergruppe das Maß der Dinge… oder?

Ja, aber wie man sich schon denken kann, läuft es auch wieder auf die Frage des Preises hinaus. Denn für jedes Replizieren einer Datenbank in der Failovergruppe wird eine identische Datenbank auf dem sekundären Server angelegt, mit den gleichen Kosten wie die primäre. Bei der Aktiven Georeplikation wird dies zwar auch empfohlen, theoretisch könnten aber auch sekundäre Datenbanken mit geringerer Performance und niedrigeren Preisen eingerichtet werden. Ohne großartig zu rechnen, kann man sich denken, dass dies schnell ins Geld geht.

Wie in Teil 1 bereits gesagt, reicht die integrierte Hochverfügbarkeitslösung in den allermeisten Fällen aus. Nur wer wirklich sichergehen möchte, kann sich eine Failovergruppe mit jeweiligen Datenbankpaaren einrichten. Die Aktive Georeplikation ist eher für eine Datenbankmigration oder bei Anwendungsupgrades einzusetzen.