Übung: Erweitern Ihres Entwurfs auf mehrere Regionen

30 Minuten

Contoso Shoes braucht eine Möglichkeit, um regionale Ausfälle zu überstehen. Sie möchten den aktuellen Stempel in einer Aktiv-Aktiv-Topologie für mehrere Regionen und mit gemeinsam genutzten Zustand bereitstellen. Die Architektur muss so konzipiert sein, dass der Datenverkehr zu einer anderen Region umgeleitet wird, falls eine Region ausfällt.

Aktueller Zustand und Problem

Eine einzelne Region hat für die Anwendung ausgereicht. Ein kürzlich aufgetretener regionaler Ausfall, der sich auf das Netzwerk auswirkte, führte jedoch dazu, dass das System aus Sicht des Benutzers offline war. Eine horizontale Skalierung innerhalb der Region oder sogar die Bereitstellung eines neuen Stempels in dieser Region hätte die Anwendung nicht vor dem Ausfall bewahren können.

Die DNS wird von einem bestehenden Registrar für api.contososhoes.com gehalten. Der DNS-Eintrag wird in den App Services-Back-End-Endpunkt (apicontososhoes.azurewebsites.net) mit einer Gültigkeitsdauer (TTL) von zwei Tagen aufgelöst. Wenn die Lösung in mehreren Regionen bereitgestellt wird, muss das DNS migriert werden.

Spezifikation

Erweitern Sie die Architektur so, dass sie in einer Aktiv-Aktiv-Topologie in mehreren Regionen funktioniert.
Ändern Sie das Modell des Bereitstellungsstempels so, dass Sie bei Bedarf dynamisch Regionen hinzufügen und entfernen können, anstatt eine Liste mit hartcodierten Ressourcen für zwei Regionen zu erstellen.
Bei einem regionalen Ausfall muss der Datenverkehr in die nicht ausgefallene Region umgeleitet werden, ohne dass die Clients, die sich bereits in der nicht ausgefallenen Region befinden, nennenswert beeinträchtigt werden.
Clients sollten nicht an eine Region gebunden sein.
Clients sollten die URLs für die Kontaktaufnahme mit der API nicht ändern müssen. Das DNS sollte auf den globalen Router migriert werden.

Empfohlene Vorgehensweise

Wir empfehlen Ihnen, die folgenden Schritte zu befolgen, um mit Ihrem Entwurf zu beginnen:

1. Topologie für mehrere Regionen

Die Architektur muss auf zwei oder mehr Azure-Regionen verteilt werden, um vor regionalen Ausfällen zu schützen. Berücksichtigen Sie diese Faktoren bei der Auswahl einer Region:

Die Region muss in der Lage sein, Ausfälle von Rechenzentren in dieser Region zu überstehen.
Die in der Architektur verwendeten Azure-Dienste und -Funktionen müssen in der Region unterstützt werden.
Die Region und die in der Region bereitgestellten Ressourcen müssen sich in der Nähe der Benutzer und abhängigen Systeme befinden, um die Wartezeit im Netzwerk zu minimieren.

Überlegen Sie sich ein Fehlerszenario. Nehmen wir an, Region 1 erhält 75 % des Datenverkehrs, und die neu hinzugefügte Region 2 erhält den restlichen Datenverkehr. Sie sind beide entsprechend skaliert, um diese Last zu bewältigen. Es gibt einen regionalen Ausfall in Region 1, und der gesamte Datenverkehr wird jetzt an Region 2 weitergeleitet. Können Sie diesen Übergang reibungslos gestalten? Kann die Region 2 diese erhöhte Datenverkehrslast bewältigen?

Überprüfen Sie Ihren Fortschritt: Globale Verteilung

2: Globales Routing

Damit die Clients transparent zu einer der beiden Arbeitsregionen weitergeleitet werden, fügen Sie einen globalen Lastenausgleich hinzu. Der Lastenausgleich sollte die Integritätsprüfungen verwenden, die Sie in der vorherigen Übung hinzugefügt haben, um zu ermitteln, ob ein Stempel fehlerfrei ist. Können Sie sich vorstellen, wie Sie häufige und ähnliche Anforderungen erfüllen können, ohne das Back-End zu erreichen?

Wählen Sie einen nativen Azure-Dienst aus, der sich in die vorhandene Architektur integriert und schnell einen Failover ausführen kann.
Stellen Sie sicher, dass der Eingangsdatenpfad des Netzwerks über Kontrollen verfügt, um nicht autorisierten Datenverkehr zu unterbinden.
Minimieren Sie die Netzwerklatenz, indem Sie Endbenutzer von einem Edgecache aus versorgen.
Migrieren Sie das vorhandene DNS, ohne bestehende Clients zu beeinträchtigen.
Sorgen Sie für eine automatische Möglichkeit, einen regionalen Ausfall zu melden, um sicherzustellen, dass der Datenverkehr nicht in die fehlerhafte Region umgeleitet wird. Lassen Sie sich außerdem benachrichtigen, wenn die Region wieder verfügbar ist, sodass der Lastenausgleich das Routing zu dieser Region wieder aufnehmen kann.

Überprüfen Sie Ihren Fortschritt: Globales Routing des Datenverkehrs

3: Änderungen des Bereitstellungsstempels

Der ideale Zustand ist eine Aktiv-Aktiv-Konfiguration, die kein manuelles Failover erfordert und bei der Anforderungen von Clients aus jeder Region behandelt werden können. Denken Sie darüber nach, was das für Ihre Architektur bedeutet. Verfügen Sie z. B. über einen Zustand, der im regionalen Stempel gespeichert ist?

Bestimmte Dienste in der aktuellen Architektur verfügen über Georeplikationsfunktionen. Ziehen Sie in Erwägung, die Dienste in verschiedene Stempel aufzuteilen: einen Stempel, der globale Ressourcen enthält, und einen anderen regionalen Stempel, der die Ressourcen mit dem globalen Stempel teilt. Einer der entscheidenden Faktoren sollte der Lebenszyklus dieser Ressourcen sein. Wie hoch ist die erwartete Lebensdauer der Ressource im Vergleich zu anderen Ressourcen in der Architektur? Sollte die Ressource eine länger oder dieselbe Lebensdauer wie das gesamte System oder die gesamte Region haben, oder sollte sie nur vorübergehend sein?

Erkunden Sie die Zuverlässigkeitsfeatures der in der Architektur verwendeten Azure-Dienste. Sie können mit diesen Features beginnen und weitere erforschen, um die Zuverlässigkeit zu maximieren.

Azure-Dienst	Funktion
Azure Cosmos DB	Schreiben in mehreren Regionen
Azure Container Registry	Georeplikation
Azure App Service-Plan	Unterstützung für Verfügbarkeitszonen

Überprüfen Sie Ihren Fortschritt: Anwendungsplattform | Datenplattform

Arbeit überprüfen

Hier sind die Entwurfsoptionen für Anwendung und Daten, die Sie für eine ähnliche Architektur auswählen können. Haben Sie bei Ihrem Entwurf alle Aspekte berücksichtigt?

Welche andere Azure-Region haben Sie für Ihre Topologie mit mehreren Regionen ausgewählt und warum?
Haben Sie zwei oder mehr Azure-Verfügbarkeitszonen in jeder Azure-Region aktiviert, um sich vor Ausfällen des Rechenzentrums zu schützen?
Haben Sie eine Web Application Firewall zur Kontrolle des eingehenden Datenverkehrs einbezogen? Welche Routingregeln haben Sie aufgestellt und warum?
Wie unterstützt der Lastenausgleich Ihren bestehenden DNS-Eintrag?
Wie haben Sie Ihre Integritätsprüfungs-API aus der vorherigen Übung verwendet?
Haben Sie die Anwendung vor DDoS-Angriffen geschützt und insbesondere verhindert, dass böswillige Clients den Lastenausgleich umgehen und regionale Instanzen erreichen?
Wie sind Sie bei der DNS-Migration vorgegangen?
Haben Sie SKU-Änderungen an der bestehenden Komponente vorgenommen, um die Topologie für mehrere Regionen zu unterstützen?
Welche Azure-Dienste haben Sie als Singletons belassen? Wie haben Sie Ihre Wahl für die einzelnen Dienste begründet? Haben Sie Konfigurationsänderungen vorgenommen?
Protokollieren Sie Ressourcen? Glauben Sie, dass sich das auf Ihre Fähigkeit auswirkt, die Protokolle für das gesamte System zu überprüfen?