Übersicht über die Georeplikation

Für Anwendungsentwickler und IT-Ingenieure ist ein gemeinsames Ziel, robuste Anwendungen zu erstellen und auszuführen. Resilienz wird als Fähigkeit Ihrer Anwendung definiert, auf Fehler zu reagieren und weiterhin funktionsfähig zu bleiben. Um resilienz angesichts regionaler Fehler in der Cloud zu erreichen, besteht der erste Schritt darin, Redundanzen zu erstellen, um einen einzelnen Fehlerpunkt zu vermeiden. Diese Redundanz kann mit der Georeplikation erreicht werden.

Mit der Georeplikation der App-Konfiguration können Sie Ihren Konfigurationsspeicher nach Belieben in die Regionen Ihrer Wahl replizieren. Jedes neue Replikat befindet sich in einer anderen Region und erstellt einen neuen Endpunkt für Ihre Anwendungen, an die Anforderungen gesendet werden sollen. Der ursprüngliche Endpunkt Ihres Konfigurationsspeichers wird als Origin bezeichnet. Der Ursprung kann nicht entfernt werden, verhält sich aber anders wie jedes Replikat.

Das Ändern oder Aktualisieren ihrer Schlüsselwerte kann in jedem Replikat erfolgen. Diese Änderungen werden nach einem eventuellen Konsistenzmodell mit allen anderen Replikaten synchronisiert.

Das Replizieren Ihres Konfigurationsspeichers bietet die folgenden Vorteile:

• Resilienz für Azure-Ausfälle hinzugefügt: Im Falle eines regionalen Ausfalls sind Replikate individuell betroffen. Wenn eine Region über einen Ausfall verfügt, sind alle Replikate, die sich in nicht betroffenen Regionen befinden, weiterhin zugänglich und kontinuierlich synchronisiert. Nachdem der Ausfall entschärft wurde, werden alle betroffenen Replikate mit dem neuesten Zustand synchronisiert. Beachten Sie, dass die Georeplikation nur Funktionen für ein automatisches Failover über Konfigurationsanbieter von App Configuration bietet. Andernfalls können Sie auch eigene benutzerdefinierte Failovermechanismen in der Konfiguration Ihrer Anwendung erstellen, um zwischen verschiedenen Replikatendpunkten zu wechseln, um die Auswirkungen eines Azure-Ausfalls zu verringern.
• Umverteilung von Anforderungsbeschränkungen: Sie können in Code anpassen, welchen Replikatendpunkt Ihre Anwendung verwendet, sodass Sie Ihre Anforderungslast verteilen können, um die Ausschöpfung von Anforderungsgrenzwerten zu vermeiden. Wenn Ihre Anwendungen beispielsweise in mehreren Regionen ausgeführt werden und nur Anforderungen an eine Region senden, können Sie mit der Erschöpfung der App-Konfigurationsanforderungsbeschränkungen beginnen. Sie können diese Last weiterverteilen, indem Sie Replikate in den Regionen erstellen, in denen Ihre Anwendungen ausgeführt werden. Jedes Replikat weist isolierte Anforderungsgrenzwerte auf, gleich der Größe der Anforderungsgrenzwerte des Ursprungs. Das Ausschöpfen der Anforderungsgrenzwerte in einem Replikat hat keine Auswirkungen auf die Anforderungsgrenzwerte in einem anderen Replikat.
• Regionale Kompartimentierung: Der Zugriff auf mehrere Regionen kann die Latenz zwischen Ihrer Anwendung und dem Konfigurationsspeicher verbessern, was zu schnelleren Antwortzeiten bei Anforderungen und einer besseren Leistung führt, wenn eine Anwendung Anfragen an die nächstgelegene Replika sendet. Durch die Angabe des Replikatzugriffs können Sie außerdem die Datenspeicherung und den Datenfluss zwischen verschiedenen Regionen basierend auf Ihren Einstellungen einschränken.

Um dieses Feature in Ihrem Store zu aktivieren, verweisen Sie auf die Vorgehensweise zum Aktivieren des Georeplikationsdokuments.

Beispielanwendungsfall

Ein Entwicklerteam erstellt ein System, das aus mehreren Anwendungen besteht und derzeit über einen Azure App Configuration Store in der Region West US verfügt. Die Nutzung ihres Systems wächst schnell, und sie sind auf der Suche nach Skalierung und Erfüllung ihrer Kundenanforderungen in: Schweden Mittel-, West-, Nordeuropa- und Ostasien. Alle Anwendungen, über die sie verfügen, verwenden derzeit den Konfigurationsspeicher "West US", wodurch ein einzelner Fehlerpunkt entsteht. Wenn es einen regionalen Ausfall in den USA gab und sie keine anderen Failovermechanismen oder Standardverhaltensweisen hatten, wäre ihr System für Kunden nicht verfügbar. Darüber hinaus sind global alle Anwendungen derzeit durch den Anforderungsgrenzwert eines Konfigurationsspeichers eingeschränkt. Da das Team auf mehr Regionen skaliert wird, wird diese Grenze nicht nachhaltig sein.

Dieses Team würde von der Georeplikation profitieren. Sie können ein Replikat ihres Konfigurationsspeichers in jeder Region erstellen, in der ihre Anwendung ausgeführt wird. Dann können ihre Anwendungen Anforderungen an ein Replikat in derselben Region senden, anstatt dass alle Anwendungen Anforderungen an die Region West-US senden. Dies bietet zwei Vorteile: verbesserte Anforderungslatenz und bessere Lastverteilung. Eine gute Verteilung der Anforderungslast trägt dazu bei, die Erschöpfung des Anforderungskontingents zu vermeiden. Die Verfügbarkeit mehrerer Replikate ermöglicht dem Team außerdem, Anwendungen so zu konfigurieren, dass im Fall eines regionalen Ausfalls ein Failover ausgeführt wird. Beispielsweise kann das Team Anwendungen konfigurieren, die in Schweden Central ausgeführt werden, um die Konfiguration aus dieser Region abzurufen, aber auf Nordeuropa zurückgreifen, wenn Schweden Central einen Ausfall erleidet. Auch wenn die App-Konfiguration in einer bestimmten Region nicht verfügbar ist, ist das System des Teams nicht betroffen.

Überlegungen

• Die Georeplikation ist in den Stufen "Kostenlos" und "Entwickler" nicht verfügbar.
• Jedes Replikat weist Beschränkungen auf, wie auf der Seite "Preise für die App-Konfiguration" beschrieben. Diese Grenzwerte sind pro Replikat isoliert.
• Die Azure-App-Konfiguration unterstützt auch Azure-Verfügbarkeitszonen, um einen ausfallsicheren und hoch verfügbaren Store in einer Azure-Region zu erstellen. Die Unterstützung von Verfügbarkeitszonen steht automatisch für Replikate zur Verfügung, wenn deren Region Verfügbarkeitszonen unterstützt. Die Kombination von Verfügbarkeitszonen für Redundanz innerhalb einer Region und Georeplikation in mehreren Regionen verbessert sowohl die Verfügbarkeit als auch die Leistung eines Konfigurationsspeichers.

Kosten und Abrechnung

Jedes erstellte Replikat fügt zusätzliche Gebühren hinzu. Weitere Informationen finden Sie auf der Seite "Preise für die App-Konfiguration ". Wenn es sich bei Ihrem Ursprung also beispielsweise um einen Konfigurationsspeicher im Standard-Tarif handelt und fünf Replikate vorhanden sind, werden Ihnen für Ihr System sechs Konfigurationsspeicher im Standard-Tarif in Rechnung gestellt. In dieser Gebühr sind allerdings bereits die isolierten Kontingente und Anforderungen der einzelnen Replikate enthalten.

Überwachung

Um Einblicke in die Merkmale des Georeplikationsfeatures zu erhalten, stellt die App-Konfiguration eine Metrik mit dem Namen Replikationslatenz bereit. Die Metrik für die Replikationslatenz beschreibt, wie lange es dauert, bis Daten aus einem Bereich in einen anderen repliziert werden.

Weitere Informationen zur Replikationslatenzmetrik und anderen App-Konfigurationsmetriken finden Sie unter Monitoring App Configuration data reference.

Nächste Schritte

Ausfallsicherheit und Notfallwiederherstellung