Entwerfen einer geografisch verteilten Datenarchitektur
Im letzten Schritt des Architekturentwurfs für die Anwendung müssen Sie die Datenspeicherebene mit einbeziehen. Sie müssen sicherstellen, dass die Daten nach einem regionalen Ausfall lesbar, schreibbar und voll funktionsfähig sind.
Im Portal zur Sendungsnachverfolgung haben wir Azure Front Door für das Senden von Anforderungen an App Service-Instanzen in der Region „USA, Osten“ ausgewählt. Wenn die Region „USA, Osten“ ausfällt, erkennt Front Door den Fehler und sendet Anfragen an Duplikate der App Service-Komponenten in der Region „USA, Westen“. In der ursprünglichen Architektur mit einer Region wurden relationale Daten in Azure SQL-Datenbank und teilweise strukturierte Daten in Cosmos DB gespeichert. Jetzt möchten wir wissen, wie sichergestellt werden kann, dass beide Datenbanken verfügbar bleiben, falls die Region „USA, Osten“ ausfällt.
Hier erfahren Sie, wie Sie Daten regionsübergreifend replizieren, und wie Sie sicherstellen können, dass ein Failover so schnell wie möglich ausgeführt wird.
Azure SQL-Datenbank
Wenn Sie eine multiregionale Implementierung von Azure SQL-Datenbank für die Speicherung relationaler Daten erstellen möchten, können Sie folgende Methoden anwenden:
- Aktive Georeplikation
- Autofailover-Gruppen
Aktive Georeplikation
Azure SQL-Datenbank kann mithilfe des Features für die aktive Georeplikation automatisch eine Datenbank und alle zugehörigen Änderungen in eine andere Datenbank replizieren. Nur der primäre logische Server hostet eine beschreibbare Kopie der Datenbank. Sie können bis zu vier weitere logische Server erstellen, auf denen schreibgeschützte Kopien der Datenbank gehostet werden.
Erstellen Sie für das Sendungsverfolgungsportal eine sekundäre Datenbank in der Region „USA, Westen“, und konfigurieren Sie die Georeplikation aus der Region „USA, Osten“. Wenn es zu einem regionalen Ausfall kommt, leitet Front Door Benutzeranforderungen an App Services-Instanzen in der Region „USA, Westen“ um. App Services und Azure Functions können auf die relationalen Daten zugreifen, da bereits eine Kopie für die Region „USA, Westen“ repliziert wurde.
Diese Änderung erfolgt zwar automatisch, aber bedenken Sie, dass die sekundäre Datenbank in der Region „USA, Westen“ schreibgeschützt ist. Wenn ein Benutzer versucht, Daten zu ändern, z. B. indem er eine neue Sendung erstellt, können Fehler auftreten. Sie können manuell ein Failover auf die Region „USA, Westen“ initiieren, sobald Sie ein Problem im Azure-Portal bemerken. Zur Automatisierung dieses Prozesses können Entwickler Code schreiben, der die Methode failover in der Rest-API für Azure SQL-Datenbank aufruft.
Hinweis
Verwaltete Instanzen von Azure SQL-Datenbank unterstützen die aktive Georeplikation nicht. Verwaltete Instanzen sind so konzipiert, dass sie die Migration von Daten aus einer lokalen SQL Server-Instanz vereinfachen und gleichzeitig die Sicherheit bewahren. Wenn Sie eine verwaltete Instanz verwenden, sollten Sie stattdessen in Erwägung ziehen, Failovergruppen einzusetzen.
Autofailover-Gruppen
Eine Autofailover-Gruppe ist eine Datenbankgruppe, in der Daten automatisch von einem primären auf mindestens einen sekundären Server repliziert werden. Es handelt sich dabei um einen ähnlichen Vorgang wie bei der aktiven Georeplikation, und es wird dieselbe Methode zur Datenreplikation verwendet. Sie können den Vorgang automatisieren, mit dem auf Ausfälle reagiert werden soll, indem Sie eine Richtlinie festlegen.
Erstellen Sie für das Sendungsverfolgungsportal eine sekundäre Datenbank in der Region „USA, Westen“. Fügen Sie anschließend eine Richtlinie hinzu, die ein Failover des primären Replikats der Datenbank auf die Region „USA, Westen“ ausführt, wenn es zu einem katastrophenbedingten Ausfall in der Region „USA, Osten“ kommen sollte. In diesem Fall wird das Replikat in der Region „USA, Westen“ automatisch zur beschreibbaren primären Datenbank, und die volle Funktionalität bleibt erhalten.
Wenn Sie den Failovervorgang für die beschreibbare Datenbank automatisieren möchten, ohne benutzerdefinierten Code schreiben zu müssen, der diesen auslöst, können Sie Autofailover-Gruppen verwenden. Außerdem eignen sich Autofailover-Gruppen, wenn die Datenbank in einer verwalteten Instanz von Azure SQL-Datenbank ausgeführt wird.
Wichtig
Replikationen, die sowohl auf aktiver Georeplikation als auch auf Autofailover-Gruppen basieren, verlaufen asynchron. Wenn eine Änderung auf das primäre Replikat angewendet wird, wird eine Bestätigung an den Client gesendet. Damit gilt die Transaktion als abgeschlossen, und es erfolgt eine Replikation. Sollte es zu einem Ausfall kommen, kann es sein, dass Änderungen, die vor Kurzem an der primären Datenbank vorgenommen wurden, noch nicht auf die sekundäre Datenbank repliziert worden sind. Bedenken Sie, dass bei einem Notfall die letzten Änderungen an der Datenbank verloren gehen können.
Azure Cosmos DB
Unsere Konfiguration ist mit Azure Cosmos DB weniger komplex, da sie als multiregionales Clouddatenbanksystem konzipiert ist. Bei Cosmos DB handelt es sich um eine Datenbank mit mehreren Modellen, in der Sie relationale Daten, teilweise strukturierte Daten und andere Arten von Daten speichern können. Auch wenn Cosmos DB in einer einzelnen Region ausgeführt wird, werden die Daten auf mehrere Instanzen über verschiedene Fehlerdomänen hinweg repliziert, um für optimale Verfügbarkeit zu sorgen.
Wenn Sie ein multiregionales Cosmos DB-Konto erstellen, können Sie einen der folgenden Modi auswählen:
Multiregionale Konten mit mehreren Schreibregionen:
In diesem Modus sind alle Kopien der Datenbank jederzeit beschreibbar. Wenn es in einer Region zu einem Ausfall kommt, ist kein Failover erforderlich.
Multiregionale Konten mit einer einzelnen Schreibregion:
In diesem Modus enthält nur die primäre Region beschreibbare Datenbanken. Die Daten, die für die sekundären Regionen repliziert werden, sind schreibgeschützt. Aktualisierungen werden standardmäßig deaktiviert, wenn die primäre Region ausfällt. Sie können jedoch die Option Automatisches Failover aktivieren auswählen, damit Cosmos DB automatisch ein Failover für die primäre beschreibbare Kopie der Datenbank auf eine andere Region ausführt.
Wichtig
In Cosmos DB erfolgt die Datenreplikation synchron. Wenn eine Änderung vorgenommen wird, gilt die Transaktion erst als abgeschlossen, nachdem sie auf ein Quorum von Replikaten repliziert wurde. Anschließend wird eine Bestätigung an den Client gesendet. Sollte es zu einem Ausfall kommen, gehen dann auch die letzten Änderungen nicht verloren, da die Daten bereits repliziert worden sind.