Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure App Configuration speichert und verwaltet zentrale Anwendungskonfigurationseinstellungen und Featurekennzeichnungen und ersetzt damit direkt in Anwendungen eingebettete Konfigurationsdateien. Mit diesem Ansatz können Sie Konfigurationswerte dynamisch aktualisieren, den Versionsverlauf nachverfolgen und eine Aufzeichnung von Konfigurationsänderungen im Laufe der Zeit verwalten. Die Verfügbarkeit und Zuverlässigkeit der App-Konfiguration sind wichtige Überlegungen, da das Anwendungsverhalten direkt vom Zugriff auf Konfigurationsdaten zur Laufzeit abhängig sein kann.
Wenn Sie Azure verwenden, ist zustellbarkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.
In diesem Artikel wird die Zuverlässigkeitsarchitektur der App-Konfiguration beschrieben und beschrieben, wie der Dienst während vorübergehender Fehler, Verfügbarkeitszonenfehler und Regionsausfälle verfügbar bleiben soll.
Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit
Berücksichtigen Sie für die meisten Produktionsbereitstellungen der App-Konfiguration die folgenden Empfehlungen:
SKU: Verwenden Sie die Standard- oder Premium-SKU.
Sanftes Löschen und Schutz vor endgültigem Löschen: Aktivieren Sie das sanfte Löschen und den Schutz vor endgültigem Löschen, um das versehentliche Löschen von Daten zu verhindern.
Für unternehmenskritische Szenarien: Verwenden Sie die Premium-SKU, und konfigurieren Sie das enthaltene Replikat so, dass es in mehreren Regionen repliziert wird. Dieser Ansatz verbessert hohe Verfügbarkeit und Resilienz gegenüber Regionsausfällen.
Eine Liste der empfohlenen Methoden und Konfigurationen für Produktionsworkloads finden Sie unter Erstellen von Anwendungen mit hoher Resilienz.
Übersicht über die Zuverlässigkeitsarchitektur
Wenn Sie die App-Konfiguration bereitstellen, stellen Sie einen Store bereit. Ihr Store enthält verschiedene Arten von Einstellungen, die Ihre Anwendung verwenden kann, einschließlich Schlüssel und Werte sowie Featurekennzeichnungen. Der Dienst umfasst auch integrierte Funktionen zum Organisieren, Sichern, Versionsverwaltung und sicheren Rollout von Konfigurationsänderungen in allen Umgebungen. Weitere Informationen finden Sie unter Was ist die App-Konfiguration?
Die App-Konfiguration ist ein vollständig verwalteter Dienst. Microsoft ist für die Wartung des Diensts und das Speichern und Verwalten Ihrer Einstellungen verantwortlich.
Wenn Sie Clientanwendungen erstellen, die eine Verbindung mit der App-Konfiguration herstellen, können Sie optional anwendungskonfiguration mit Azure Front Door (Vorschau) verwenden, um zwischenspeichern und globale Datenverkehrsbeschleunigung zu ermöglichen. Diese Konfiguration führt zu weiteren Überlegungen zur Georeplikation, die in diesem Artikel an geeigneten Stellen hervorgehoben werden.
Resilienz für vorübergehende Fehler
Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.
Alle in der Cloud gehosteten Anwendungen sollten den Azure richtlinien für die vorübergehende Fehlerbehandlung befolgen, wenn sie mit allen in der Cloud gehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.
Berücksichtigen Sie bei der Verwendung der App-Konfiguration die folgenden bewährten Methoden, um die Auswirkungen vorübergehender Fehler auf den Konfigurationszugriff zu minimieren, insbesondere innerhalb kritischer Codepfade.
Konfigurationsanbieter: Verwenden Sie App-Konfigurationsanbieter, die integrierte Wiederholungs- und Zwischenspeicherungsfunktionen und andere Resilienzfeatures aufweisen.
Azure SDKs: Verwenden Sie App-Konfigurations-SDKs, wenn Ihre Anwendung Schreibanforderungen senden muss. SDKs führen beim Auftreten des HTTP-Statuscodes 429 und anderer vorübergehender Fehler automatisch einen Wiederholungsversuch durch.
Wiederholungslogik: Fügen Sie Wiederholungslogik in benutzerdefinierte Clients ein, wenn Sie keine App-Konfigurationsanbieter oder SDKs verwenden können. Der
retry-after-msHeader in der Antwort stellt eine vorgeschlagene Wartezeit in Millisekunden bereit, bevor der Client die Anforderung erneut abruft.Zwischenspeichern: Einstellungen für das Caching im Arbeitsspeicher, wenn möglich, um direkte Anfragen an Ihren Shop zu reduzieren.
Weitere Anleitungen zur Anwendungskonfiguration finden Sie in den häufig gestellten Fragen zur App-Konfiguration.
Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen
Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.
Die App-Konfiguration bietet automatisch Zonenredundanz in Regionen, die Verfügbarkeitszonen unterstützen. Diese Redundanz bietet hohe Verfügbarkeit innerhalb einer Region, ohne dass eine bestimmte Konfiguration erforderlich ist.
Das Diagramm zeigt die Verfügbarkeitszonen 1, 2 und 3. Der App-Konfigurationsspeicher umfasst alle drei Zonen in der Region.
Wenn eine Verfügbarkeitszone nicht verfügbar ist, leitet die App-Konfiguration Ihre Anforderungen automatisch an andere fehlerfreie Verfügbarkeitszonen weiter, um eine hohe Verfügbarkeit sicherzustellen.
Anforderungen
Regionsunterstützung: In den folgenden Regionen bereitgestellte Stores sind automatisch zonenredundant.
| Amerika | Europa | Naher Osten | Afrika | Asien-Pazifik |
|---|---|---|---|---|
| Brasilien Süd | Frankreich, Mitte | Israel Central | Australien (Osten) | |
| Canada Central | Deutschland West Central | Qatar Central | Zentralindien | |
| Central US | Italy North | Vereinigte Arabische Emirate, Norden | China, Norden 3 | |
| East US | Nordeuropa | Ostasien | ||
| Ost-USA 2 | Norwegen, Osten | Japan, Osten | ||
| Mexiko Zentral | Poland Central | Korea Central | ||
| Süd-Mittel-USA | Spain Central | Südostasien | ||
| US-Regierung Virginia | Schweden, Mitte | |||
| Westliches USA 2 | Switzerland North | |||
| Westliches USA 3 | UK South | |||
| West Europe |
Kosten
Es gibt keine zusätzlichen Kosten für Zonenredundanz für die App-Konfiguration.
Konfigurieren der Unterstützung von Verfügbarkeitszonen
Microsoft konfiguriert Zonenredundanz für einen Speicher automatisch, wenn es sich in a-Region befindet, die Verfügbarkeitszonen unterstützt.
Wenn die App-Konfiguration einer vorhandenen Region Unterstützung für Verfügbarkeitszonen hinzufügt, müssen Sie keine Maßnahmen ergreifen, um von der Verfügbarkeitszonenunterstützung zu profitieren. Ihr Store profitiert von der Verfügbarkeitszonenunterstützung, die für App-Konfigurationsspeicher in der Region verfügbar wird.
Verhalten, wenn alle Zonen fehlerfrei sind
In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie über einen zonenredundanten App-Konfigurationsspeicher verfügen und alle Zonen betriebsbereit sind.
Zonenübergreifender Vorgang: App Configuration verwaltet automatisch das Verkehrs-Routing zwischen Verfügbarkeits-Zonen. Während normaler Vorgänge verteilt sie Anforderungen transparent über Zonen hinweg.
Zonenübergreifende Datenreplikation: In Regionen, die Zonen unterstützen, repliziert die App-Konfiguration synchron Daten über Verfügbarkeitszonen hinweg. Diese Replikation stellt sicher, dass Ihre Einstellungen konsistent und verfügbar bleiben, auch wenn eine Zone nicht verfügbar ist.
Verhalten bei einem Zoneausfall
In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie über einen zonenredundanten App-Konfigurationsspeicher verfügen, und es gibt einen Ausfall in einer der Zonen.
- Erkennung und Reaktion: Der App-Konfigurationsdienst erkennt Zonenfehler und reagiert automatisch darauf. Während eines Zonenfehlers müssen Sie keine Maßnahmen ergreifen.
- Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.
Aktive Anforderungen: Während eines Zonenfehlers kann die betroffene Zone möglicherweise keine In-Flight-Anforderungen verarbeiten, was erfordert, dass Clientanwendungen sie erneut versuchen. Clientanwendungen sollten vorübergehende Fehlerbehandlungsmethoden befolgen, um sicherzustellen, dass sie Anforderungen wiederholen können, wenn ein Zonenfehler auftritt.
Erwarteter Datenverlust: Aufgrund der synchronen Replikation zwischen Zonen wird kein Datenverlust während eines Zonenfehlers erwartet.
Erwartete Ausfallzeiten: Es wird keine Ausfallzeit erwartet.
Umverteilung: Die App-Konfiguration umgeleitet den Datenverkehr automatisch von der betroffenen Zone zu fehlerfreien Zonen, ohne dass ein Kundeneingriff erforderlich ist.
Zonenwiederherstellung
Wenn eine zuvor nicht verfügbare Zone wiederhergestellt wird, stellt die App-Konfiguration automatisch normale Vorgänge in allen Verfügbarkeitszonen wieder her. Sie müssen keine Maßnahmen ergreifen, um sich von einem Zonenfehler zu erholen.
Test auf Zonenfehler
Die App-Konfigurationsplattform verwaltet Datenverkehrsrouting, Failover und Zonenwiederherstellung für zonenredundante Speicher. Microsoft diesen Prozess vollständig verwaltet, sodass Sie keine Fehlerprozesse der Verfügbarkeitszone überprüfen müssen.
Widerstandsfähigkeit bei regionalen Ausfällen
Die App-Konfiguration bietet systemeigene Georeplikationsfunktionen zur Unterstützung der Resilienz während Regionsausfällen. Die Georeplikation ermöglicht die Replikation von Konfigurationsdaten über Regionen hinweg als feature für verwaltete Dienste.
Georeplikation
Mit der Georeplikation können Sie einen Speicher in mehreren Azure Regionen replizieren. Jeder Store kann über mehrere Replikas in verschiedenen Regionen verfügen. Der ursprüngliche Laden ist auch ein Replikat. Diese Funktion schützt Anwendungen vor regionsweiten Unterbrechungen.
Anforderungen
Region support: Sie können Replikate in einer beliebigen Azure Region erstellen, die von der App-Konfiguration unterstützt wird, auch wenn die Regionen nicht Azure gekoppelten Regionen sind.
Rang: Der Konfigurationsspeicher muss eine unterstützte Ebene verwenden, um die Georeplikation zu aktivieren. Weitere Informationen finden Sie unter Aktivieren der Georeplikation.
Überlegungen
Berücksichtigen Sie beim Aktivieren der Georeplikation die folgenden Faktoren:
Zonenredundante Replikate: Jedes Replikat, das Sie in einer Region erstellen, in der die App-Konfiguration Verfügbarkeitszonen unterstützt, ist automatisch zonenredundant.
Azure Front Door: Um die georedundante Konfiguration mit Azure Front Door zu aktivieren, konfigurieren Sie App-Konfigurationsreplikate als Ursprünge innerhalb einer Ursprungsgruppe. Korrekt konfigurierte Quellen sind für Azure Front Door erforderlich, um integritätsbasiertes Routing, Lastenausgleich und automatisches Failover über alle Regionen hinweg zu ermöglichen. Weitere Informationen finden Sie unter Datenverkehrsroutingmethoden zum Ursprung.
Kosten
Jede geo-replizierte Region wird separat gemäß den Preisen für die jeweilige Stufe und Region in Rechnung gestellt. Für die regionsübergreifende Replikation gelten keine Datenausgangsgebühren. Details zu den Preisen finden Sie unter App-Konfigurationspreise.
Konfigurieren der Unterstützung für mehrere Regionen
Informationen zum Einrichten der Replikation für einen neu erstellten Konfigurationsspeicher finden Sie unter Aktivieren der Georeplikation.
Verhalten, wenn alle Regionen funktionsfähig sind
In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen App-Konfigurationsspeicher für die Georeplikation konfigurieren, und alle Regionen sind betriebsbereit.
Zonenübergreifender Vorgang: Jedes Replikat ist einzeln adressierbar und verfügt über einen eigenen DNS-Namen (Domain Name System). Alle Replikate können Lese- und Schreibvorgänge akzeptieren.
Die App-Konfiguration leitet den Datenverkehr nicht automatisch zwischen Regionen weiter. Wenn Sie App-Konfigurationsanbieter verwenden, kann Ihre Anwendung optional die automatische Replikatermittlung verwenden. Alternativ können Sie eine priorisierte Liste von Replikaten angeben, und die App-Konfiguration wählt das erste fehlerfreie Replikat aus. Mit diesem Ansatz kann Ihre Anwendung steuern, welches Replikat sie verwendet.
Hinweis
Wenn Sie Azure Front Door verwenden, unterscheidet sich das Datenverkehrsroutingverhalten. Weitere Informationen finden Sie unter Failover und Lastenausgleich.
Zonenübergreifende Datenreplikation: Daten werden asynchron repliziert und sind schließlich konsistent. Sie können die Replizierungslatenzmetrik in Azure Monitor verwenden, um die aktuelle Replikationslatenz zwischen Replikaten zu überwachen.
Verhalten während eines Regionenausfalls
In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen App-Konfigurationsspeicher für die Georeplikation konfigurieren, und es gibt einen Ausfall in einer der Replikatregionen.
Erkennung und Reaktion: Microsoft ist für das Erkennen von Region- oder Replikatfehlern und das Initiieren von Wiederherstellungsverfahren verantwortlich.
Wenn Sie App-Konfigurationsanbieter mit automatischer Replikatermittlung oder einer Liste mehrerer Replikate verwenden, erkennt Ihre Anwendung automatisch Fehler und schaltet auf ein fehlerfreies Replikat um.
Wenn Sie keine App-Konfigurationsanbieter verwenden, sind Sie dafür verantwortlich, Ihre Anwendung in ein fehlerfreies Replikat zu wechseln.
Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um den allgemeinen Status des Diensts zu verstehen, einschließlich regionsfehlern, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.
Aktive Anforderungen: Aktive Anforderungen für ein Replikat in der Region können fehlschlagen. Clientanwendungen sollten die Anfragen bei einem anderen Replikat erneut versuchen.
Erwarteter Datenverlust: Wenn ein Replikat fehlschlägt, werden die letzten Änderungen, die an diesem Replikat vorgenommen wurden, möglicherweise noch nicht in andere Replikate repliziert. Diese Änderungen können bis zur Wiederherstellung des Replikats nicht verfügbar bleiben. Um potenzielle Datenverluste zu schätzen, überwachen Sie die Metrik Replizierungslatenz in Azure Monitor.
Erwartete Ausfallzeiten: Wenn ein Replikat nicht verfügbar ist, bleibt es offline, bis seine Region wiederhergestellt wird. Andere Replikas bearbeiten weiterhin Anfragen. Anwendungen können kurze Ausfallzeiten feststellen, während sie den Fehler erkennen und zu einem fehlerfreien Replikat wechseln. Die Dauer hängt davon ab, wie schnell jede Anwendung diese Erkennung und dieses Failover durchführt.
Umverteilung: Anwendungen müssen Datenverkehr an ein fehlerfreies Replikat weiterleiten, wenn ein Fehler auftritt.
Wenn Sie App-Konfigurationsanbieter verwenden, behandeln die Anbieter die Replikatauswahl und das Failover automatisch.
Wenn Sie Azure Front Door vor Ihrem Datenspeicher platzieren und die Ursprungsgruppe mit mehreren Replikaten als Ursprünge für Failover konfigurieren, werden Anfragen von Azure Front Door automatisch an ein gesundes Replikat umgeleitet.
Region-Wiederherstellung
Nachdem die Region wiederhergestellt wurde, synchronisiert die App-Konfiguration das Replikat ohne Eingreifen mit den anderen Replikaten.
Sie sind für die Neukonfiguration Ihrer Anwendung verantwortlich, um den Datenverkehr zurück zur wiederhergestellten Regionsinstanz weiterzuleiten. Anwendungen, die App-Konfigurationsanbieter verwenden, beginnen automatisch erneut, das Replikat zu verwenden.
Test auf Regionsfehler
Sie können in App Configuration ein Replikatfailover nicht direkt simulieren. Da Anwendungen jedoch die Replikatauswahl steuern, können Sie das Failoververhalten testen, indem Sie die Anwendung in einen Zustand erzwingen, in dem Replikate gewechselt werden müssen.
Um das Replikatfailoververhalten Ihrer Anwendung zu überprüfen, können Sie einen kontrollierten Konnektivitätsfehler in einer Nichtproduktionsumgebung einführen und beobachten, wie die Anwendung reagiert.
Ein Ansatz besteht darin, Ihren lokalen Computer oder eine andere Umgebung zu verwenden, in der Sie über Administratorzugriff verfügen. Folgen Sie diesen Schritten:
Aktivieren Sie die ausführliche Protokollierung für das Azure SDK. Verwenden Sie in .NET die klasse
AzureEventSourceListener, um einen Logger zu konfigurieren. Weitere Informationen finden Sie unter Protokollierung und Überwachung.Konfigurieren Sie Ihre
hosts-Datei manuell so, dass Anforderungen an Ihren App Configuration Store an eine IP-Adresse weitergeleitet werden, die sie nicht empfangen kann, wie127.0.0.1(localhost).Warnung
Dieser Schritt blockiert effektiv den Zugriff von Ihrem Computer auf Ihren App-Konfigurationsspeicher. Führen Sie diese Schritte nur in einer Nichtproduktionsumgebung aus.
Überwachen Sie die Protokolle auf eine Nachricht ähnlich dem folgenden Beispiel:
[Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh: Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.Diese Meldung zeigt an, dass die Anwendung erfolgreich auf eine andere Replik Ihres Shops umgeschaltet wurde.
Nachdem Sie den Test abgeschlossen haben, können Sie die Änderungen an Ihrer
hostsDatei rückgängig machen.
Sichern und Wiederherstellen
Sie können die App-Konfiguration verwenden, um Konfigurationsdaten aus einem Speicher zu exportieren und als Teil einer umfassenderen Sicherungsstrategie zu verwenden.
Für die meisten Lösungen sollten Sie sich nicht ausschließlich auf Sicherungen verlassen. Verwenden Sie stattdessen die in diesem Handbuch beschriebenen anderen Funktionen, um Ihre Resilienzanforderungen zu unterstützen. Sicherungen schützen jedoch vor einigen Risiken, die andere Ansätze nicht vermeiden. Weitere Informationen finden Sie unter Was sind Redundanz, Replikation und Sicherung?.
Widerstandsfähigkeit bei versehentlichem Löschen
Die App-Konfiguration bietet zwei wichtige Wiederherstellungsfeatures, um versehentliche oder böswillige Löschungen zu verhindern:
Vorläufiges Löschen: Wenn Sie das vorläufige Löschen aktivieren, können Sie gelöschte Speicher und Einstellungen während eines konfigurierbaren Aufbewahrungszeitraums wiederherstellen. Soft Delete funktioniert ähnlich wie ein Papierkorb für Ihre Ressourcen in der App-Konfiguration.
Löschschutz: Wenn Sie den Löschschutz aktivieren, verhindert der Dienst das dauerhafte Löschen Ihres Stores und seiner Einstellungen, bis der Aufbewahrungszeitraum abgelaufen ist. Dadurch wird verhindert, dass böswillige Akteure Ihre Einstellungen dauerhaft zerstören.
Verwenden Sie beide Features für Produktionsumgebungen. Weitere Informationen finden Sie unter Soft-Delete und Löschschutz.
Resilienz gegenüber Wartungsarbeiten an Diensten
Microsoft führt regelmäßig Dienstupdates und andere Wartungen durch. Der Dienst verarbeitet diese Aktivitäten automatisch, wodurch Sie die Wartung nahtlos und transparent gestalten. Bei Wartungsereignissen wird keine Ausfallzeit erwartet, es sei denn, Azure Service Health stellt eine geplante Wartungsbenachrichtigung bereit.
Resilienz bei Konfigurationsproblemen
Falsche oder versehentliche Konfigurationsänderungen können zu Ausfallzeiten der Anwendung führen. Verwenden Sie Konfigurationsmomentaufnahmen, um Änderungen an der Konfiguration sicher vorzunehmen. Überwachen Sie die Gesundheit Ihrer Anwendung nach Konfigurationsänderungen und stellen Sie die letzte bekannte funktionierende Konfigurationsversion wieder her, wenn die Änderungen ein Problem verursachen.
Service-Level-Vereinbarung
Der ServiceLevel-Vertrag (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit der einzelnen Dienste und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Online-Dienste.