Hochverfügbare Webanwendungen für mehrere Regionen

App Service
Cosmos DB
Front Door
Storage
SQL-Datenbank

Diese Referenzarchitektur zeigt, wie Sie eine Azure App Service-Anwendung in mehreren Regionen ausführen, um Hochverfügbarkeit zu erzielen.

Referenzarchitektur für eine Webanwendung mit Hochverfügbarkeit

Laden Sie eine Visio-Datei dieser Architektur herunter.

Aufbau

Diese Architektur basiert auf der in Verbessern der Skalierbarkeit in einer Webanwendung gezeigten Architektur. Im Folgenden werden die Hauptunterschiede erläutert:

  • Primäre und sekundäre Regionen. Diese Architektur nutzt zwei Regionen, um eine höhere Verfügbarkeit zu erreichen. Die Anwendung wird in jeder Region bereitgestellt. Während des normalen Betriebs wird Netzwerkdatenverkehr an die primäre Region weitergeleitet. Wenn die primäre Region nicht verfügbar ist, wird der Datenverkehr an die sekundäre Region umgeleitet.
  • Front Door. Front Door leitet eingehende Anforderungen an die primäre Region weiter. Wenn die in dieser Region ausgeführte Anwendung nicht verfügbar ist, führt Front Door ein Failover zur sekundären Region aus.
  • Georeplikation von SQL-Datenbank und/oder Cosmos DB.

Eine Architektur mit mehreren Regionen kann eine höhere Verfügbarkeit als eine Bereitstellung in einer einzelnen Region bieten. Wenn ein regionaler Ausfall die primäre Region beeinträchtigt, können Sie mit Front Door ein Failover zur sekundären Region ausführen. Diese Architektur kann auch hilfreich sein, wenn bei einem einzelnen Subsystem der Anwendung ein Fehler auftritt.

Es gibt mehrere allgemeine Vorgehensweisen für das Erreichen von Hochverfügbarkeit mit mehreren Regionen:

  • Aktiv/passiv mit Hot Standby. Der Datenverkehr wird an eine Region weitergeleitet, während die andere im Hot Standby wartet. Hot Standby (unmittelbar betriebsbereit) bedeutet, dass die virtuellen Computer in der sekundären Region jederzeit zugeordnet sind und ausgeführt werden.
  • Aktiv/passiv mit Cold Standby. Der Datenverkehr wird an eine Region weitergeleitet, während die andere im Cold Standby wartet. Cold Standby (verzögert betriebsbereit) bedeutet, dass die virtuellen Computer in der sekundären Region erst zugewiesen werden, wenn sie für das Failover benötigt werden. Dieser Ansatz erfordert weniger Ausführungszeit, es dauert aber im Allgemeinen länger, bis bei einem Ausfall alle Komponenten online geschaltet sind.
  • Aktiv/aktiv. Beide Regionen sind aktiv, und Anforderungen werden per Lastenausgleich zwischen ihnen verteilt. Wenn eine Region nicht verfügbar ist, wird sie aus der Rotation entfernt.

In dieser Referenzarchitektur liegt der Fokus auf aktiv/passiv mit Hot Standby, wobei Front Door für das Failover verwendet wird.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die Empfehlungen in diesem Abschnitt als Ausgangspunkt.

Regionspaare

Jede Azure-Region ist mit einer anderen Region innerhalb desselben Gebiets gepaart. Sie wählen im Allgemeinen Regionen aus dem gleichen Regionspaar aus (z.B. „USA, Osten 2“ und „USA, Mitte“). Das bietet die folgenden Vorteile:

  • Bei einem umfassenden Ausfall wird die Wiederherstellung mindestens einer Region aus jedem Paar priorisiert.
  • Geplante Azure-Systemupdates werden in Regionspaaren nacheinander ausgeführt, um mögliche Ausfallzeiten zu minimieren.
  • In den meisten Fällen befinden sich Regionspaare innerhalb desselben geografischen Gebiets, um spezifische regionale Anforderungen zu erfüllen.

Sie sollten allerdings sicherstellen, dass beide Regionen alle Azure-Dienste, die für Ihre Anwendung erforderlich sind, unterstützen. Weitere Informationen finden Sie unter Dienste nach Region. Weitere Informationen zu Regionspaaren finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare.

Ressourcengruppen

Sie sollten die primäre Region, die sekundäre Region und Traffic Manager unterschiedlichen Ressourcengruppen zuordnen. So können Sie die in jeder Region bereitgestellten Ressourcen als Einzelsammlungen verwalten.

Front Door-Konfiguration

Routing: Front Door unterstützt verschiedene Routingmechanismen. Verwenden Sie für das in diesem Artikel beschriebene Szenario das Routing nach Priorität. Bei dieser Einstellung sendet Front Door alle Anforderungen an die primäre Region, bis der Endpunkt für diese Region nicht mehr erreichbar ist. Zu diesem Zeitpunkt wird automatisch ein Failover zur sekundären Region ausgeführt. Konfigurieren Sie den Back-End-Pool mit unterschiedlichen Prioritätswerten: 1 für die aktive Region und 2 oder höher für die Standbyregion oder passive Region.

Integritätstest: Front Door verwendet einen HTTP-Test (oder HTTPS-Test), um die Verfügbarkeit jedes Back-Ends zu überwachen. Der Test meldet Front Door seinen erfolgreichen oder fehlerhaften Abschluss, damit ggf. ein Failover zur sekundären Region ausgeführt werden kann. Dies erfolgt durch das Senden einer Anforderung an einen angegebenen URL-Pfad. Wenn der Test innerhalb des Zeitlimits eine andere Antwort als „200“ erhält, löst er einen Fehler aus. Sie können die Häufigkeit des Integritätstests, die Anzahl der erforderlichen Stichproben für die Bewertung sowie die Anzahl der erforderlichen Stichproben konfigurieren, die erforderlich sind, damit das Back-End als fehlerfrei markiert werden kann. Wenn Front Door das Back-End als beeinträchtigt kennzeichnet, wird ein Failover auf das andere Back-End ausgeführt. Einzelheiten hierzu finden Sie unter Integritätstests.

Es hat sich bewährt, einen Integritätstestpfad im Anwendungs-Back-End zu erstellen, der die Gesamtintegrität der Anwendung meldet. Von diesem Integritätstest sollten alle wichtigen Abhängigkeiten überprüft werden. Dazu gehören z. B. App Service-Apps, die Speicherwarteschlange und SQL-Datenbank. Andernfalls meldet der Test eventuell ein fehlerfreies Back-End, obwohl wichtige Teile der Anwendung fehlerhaft sind. Andererseits sollten Sie den Integritätstest nicht zum Überprüfen von Diensten mit einer niedrigeren Priorität verwenden. Wenn beispielsweise ein E-Mail-Dienst ausfällt, kann die Anwendung zu einem zweiten Anbieter wechseln oder die E-Mails einfach später senden. Weitere Informationen zu diesem Entwurfsmuster finden Sie unter Muster für Überwachung der Integrität von Endpunkten.

SQL-Datenbank

Verwenden Sie die aktive Georeplikation, um ein lesbares sekundäres Replikat in einer anderen Region zu erstellen. Sie können bis zu vier lesbare sekundäre Replikate nutzen. Führen Sie ein Failover zu einer sekundären Datenbank aus, wenn die primäre Datenbank ausfällt oder offline geschaltet werden muss. Die aktive Georeplikation kann für jede Datenbank in einem beliebigen Pool für elastische Datenbanken konfiguriert werden.

Cosmos DB

Cosmos DB unterstützt die regionsübergreifende Georeplikation mit Aktiv-Aktiv-Muster und mehreren Schreibregionen. Alternativ können Sie eine Region als die schreibbare Region und die andere als schreibgeschützte Replikate festlegen. Fällt eine Region aus, können Sie ein Failover ausführen, indem Sie eine andere Region als schreibbare Region festlegen. Das Client-SDK sendet Schreibanforderungen automatisch an die aktuell schreibbare Region, daher müssen Sie die Clientkonfiguration nach einem Failover nicht aktualisieren. Weitere Informationen finden Sie unter Globale Datenverteilung mit Azure Cosmos DB.

Hinweis

Alle Replikate gehören derselben Ressourcengruppe an.

Storage

Bei Azure Storage verwenden Sie RA-GRS (Read-Access Geo-Redundant Storage, georedundanter Speicher mit Lesezugriff). Mit RA-GRS werden die Daten in eine sekundäre Region repliziert. Sie haben über einen eigenen Endpunkt lediglich schreibgeschützten Zugriff auf die Daten in der sekundären Region. Tritt in einer Region ein Ausfall oder ein anderer Notfall ein, kann das Azure Storage-Team ein geografisches Failover zur sekundären Region ausführen. Für dieses Failover ist keine Kundenaktion erforderlich.

Erstellen Sie für Queue Storage eine Sicherungswarteschlange in der sekundären Region. Während des Failovers kann die App die Sicherungswarteschlange verwenden, bis die primäre Region wieder verfügbar ist. Auf diese Weise kann die Anwendung weiterhin neue Anforderungen verarbeiten.

Überlegungen zur Verfügbarkeit

Bedenken Sie die folgenden Punkte beim Entwerfen für Hochverfügbarkeit über mehrere Regionen hinweg:

Azure Front Door

Azure Front Door führt automatisch ein Failover aus, wenn die primäre Region nicht mehr verfügbar ist. Wenn Front Door ein Failover ausführt, können die Clients die Anwendung für eine bestimmte Zeit (normalerweise 20 bis 60 Sekunden) nicht erreichen. Die Dauer wird durch folgende Faktoren beeinflusst:

  • Häufigkeit der Integritätstests. Je häufiger die Integritätstests gesendet werden, desto schneller kann Front Door feststellen, dass ein Back-End ausfällt oder wieder in den fehlerfreien Zustand zurückkehrt.
  • Konfiguration des Stichprobenumfangs. Mit dieser Konfiguration wird gesteuert, wie viele Stichproben erforderlich sind, damit der Integritätstest feststellen kann, dass das primäre Back-End nicht erreichbar ist. Wenn dieser Wert zu niedrig ist, erhalten Sie möglicherweise falsch positive Meldungen zu zeitweiligen Problemen.

Front Door ist eine potenzielle Fehlerquelle im System. Wenn beim Dienst ein Fehler auftritt, können Clients während der Ausfallzeit nicht auf Ihre Anwendung zugreifen. In der Vereinbarung zum Servicelevel (SLA) für Front Door erfahren Sie, ob Ihre geschäftlichen Anforderungen für Hochverfügbarkeit mit Front Door allein erfüllt werden. Wenn dies nicht der Fall ist, erwägen Sie als Alternative eine andere Verwaltungslösung für den Datenverkehr. Wenn der Front Door-Dienst fehlerhaft ist, ändern Sie die kanonischen Namensdatensätze (CNAME) im DNS, sodass sie auf die andere Verwaltungslösung für den Datenverkehr verweisen. Dieser Schritt muss manuell durchgeführt werden. Bis die DNS-Änderungen weitergegeben wurden, ist die Anwendung nicht verfügbar.

SQL-Datenbank

Die Recovery Point Objective (RPO) und die geschätzte Wiederherstellungszeit (ERT) für SQL-Datenbank sind in Übersicht über die Geschäftskontinuität mit Azure SQL-Datenbank dokumentiert.

Cosmos DB

RPO und RTO (Recovery Time Objective) für Cosmos DB können über die verwendeten Konsistenzebenen konfiguriert werden, die Kompromisse zwischen Verfügbarkeit, Datenbeständigkeit und Durchsatz bieten. Cosmos DB bietet einen RTO-Mindestwert von 0 für eine gelockerte Konsistenzebene mit Multimaster oder einen RPO-Wert von 0 für hohe Konsistenz mit Einzelmaster. Weitere Informationen zu den Konsistenzebenen von Cosmos DB finden Sie unter Konsistenzebenen und Datendauerhaftigkeit.

Storage

RA-GRS stellt permanenten Speicher bereit. Trotzdem sollten Sie verstehen, was bei einem Ausfall passieren kann:

  • Tritt ein Speicherausfall auf, haben Sie für eine gewisse Zeit keinen Schreibzugriff auf die Daten. Sie können während des Ausfalls weiterhin vom sekundären Endpunkt lesen.

  • Wenn sich ein regionaler Ausfall oder Notfall auf den primären Standort auswirkt und die Daten nicht wiederhergestellt werden können, kann das Azure Storage-Team ein geografisches Failover zur sekundären Region ausführen.

  • Die Datenreplikation zur sekundären Region wird asynchron ausgeführt. Wenn ein geografisches Failover durchgeführt wird, ist daher ein Datenverlust möglich, wenn die Daten nicht aus der primären Region wiederhergestellt werden können.

  • Vorübergehende Fehler, etwa Netzwerkausfälle, lösen kein Speicherfailover aus. Entwerfen Sie Ihre Anwendung flexibel gegenüber vorübergehenden Fehlern. Beispiele für Risikominderungsoptionen:

    • Lesen aus der sekundären Region.
    • Wechseln Sie vorübergehend für neue Schreibvorgänge (z.B. in Warteschlangennachrichten) zu einem anderen Speicherkonto.
    • Kopieren Sie Daten aus der sekundären Region in ein anderes Speicherkonto.
    • Stellen Sie eine eingeschränkte Funktionalität bereit, bis das Failback für das System ausgeführt wurde.

Weitere Informationen finden Sie unter Vorgehensweise beim Ausfall von Azure Storage.

Kostenbetrachtung

Verwenden Sie den Preisrechner, um Ihre Kosten zu ermitteln. Die Empfehlungen in diesem Abschnitt helfen Ihnen dabei, die Kosten zu senken.

Azure Front Door

Die Azure Front Door-Abrechnung umfasst drei Tarife: ausgehende Datenübertragungen, eingehende Datenübertragungen und Routingregeln. Weitere Informationen finden Sie unter Azure Front Door – Preise. Die Preisübersicht beinhaltet keine Kosten für den Zugriff auf Daten aus den Back-End-Diensten und die Übertragung an Front Door. Diese Kosten werden basierend auf den Gebühren für die Datenübertragung abgerechnet, wie unter Preisübersicht Bandbreite beschrieben.

Azure Cosmos DB

Es gibt zwei Faktoren, die die Preise für Azure Cosmos DB bestimmen:

  • Der bereitgestellte Durchsatz oder die Anforderungseinheiten pro Sekunde (RU/s)

    Es gibt zwei Arten von Durchsatz, die in Cosmos DB bereitgestellt werden können: Standard und Autoskalierung. Beim Standarddurchsatz werden die Ressourcen zugewiesen, die für die festgelegten RU/s erforderlich sind. Bei der Autoskalierung stellen Sie den maximalen Durchsatz bereit, und Cosmos DB führt abhängig von der Auslastung sofort eine Hoch- oder Herunterskalierung durch, wobei mindestens 10 % des maximalen Durchsatz für die Autoskalierung genutzt werden. Der Standarddurchsatz wird stundenweise nach dem bereitgestellten Durchsatz in Rechnung gestellt. Der Durchsatz bei Autoskalierung wird stundenweise nach dem maximalen Durchsatz abgerechnet.

  • Speichernutzung. Für die Gesamtmenge des Speichers (GB), der für Daten und Indizes für eine bestimmte Stunde genutzt wird, wird eine Pauschale berechnet.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

Überlegungen zur Verwaltbarkeit

Wenn die primäre Datenbank fehlerhaft ist, führen Sie ein manuelles Failover zur sekundären Datenbank aus. Weitere Informationen finden Sie unter Wiederherstellen einer Azure SQL-Datenbank oder Failover auf eine sekundäre Datenbank. Die sekundäre Datenbank bleibt schreibgeschützt, bis Sie ein Failover ausführen.

Überlegungen zu DevOps

Für diese Architektur wurde die Empfehlung zur Bereitstellung in mehreren Regionen befolgt, die im DevOps-Abschnitt des Artikels zum Azure Well-Architected Framework beschrieben ist.

Diese Architektur basiert auf der unter Verbessern der Skalierbarkeit in einer Webanwendung veranschaulichten Architektur. Weitere Informationen finden Sie im Abschnitt mit den Überlegungen zu DevOps.