Verwenden von Georedundanz zum Entwerfen hoch verfügbarer Anwendungen

2025-05-08

Cloudbasierte Infrastrukturen wie Azure Storage bieten eine hochverwendbare und dauerhafte Plattform zum Hosten von Daten und Anwendungen. Entwickler von cloudbasierten Anwendungen müssen sorgfältig prüfen, wie Sie diese Plattform nutzen können, um diese Vorteile für ihre Benutzer zu maximieren. Azure Storage bietet Georedundanzoptionen, um eine hohe Verfügbarkeit auch während eines regionalen Ausfalls sicherzustellen. Speicherkonten, die für die georedundante Replikation konfiguriert sind, werden synchron in der primären Region und asynchron in einer sekundären Region repliziert, die mehrere hundert Kilometer entfernt ist.

Azure Storage bietet zwei Optionen für die georedundante Replikation: georedundanter Speicher (GRS) und geozonenredundanter Speicher (GZRS). Um die Georedundanzoptionen von Azure Storage zu nutzen, stellen Sie sicher, dass Ihr Speicherkonto für georedundanten Speicher mit Lesezugriff (RA-GRS) oder geozonenredundanten Speicher mit Lesezugriff (RA-GZRS) konfiguriert ist. Wenn dies nicht zutrifft, erfahren Sie mehr darüber, wie Sie den Replikationstyp Ihres Speicherkontos ändern können.

In diesem Artikel wird gezeigt, wie Sie eine Anwendung entwerfen, die weiterhin funktioniert, wenn auch in einer begrenzten Kapazität, auch wenn es einen erheblichen Ausfall in der primären Region gibt. Wenn die primäre Region nicht verfügbar ist, kann Ihre Anwendung nahtlos wechseln, um Lesevorgänge für die sekundäre Region auszuführen, bis die primäre Region erneut reagiert.

Überlegungen zum Anwendungsentwurf

Sie können Ihre Anwendung so entwerfen, dass vorübergehende Fehler oder erhebliche Ausfälle verarbeitet werden, indem Sie aus der sekundären Region lesen, wenn ein Problem vorliegt, das das Lesen aus dem primären Bereich beeinträchtigt. Wenn die primäre Region wieder verfügbar ist, kann Ihre Anwendung wieder aus der primären Region lesen.

Beachten Sie diese wichtigen Überlegungen beim Entwerfen Ihrer Anwendung für Verfügbarkeit und Resilienz mithilfe von RA-GRS oder RA-GZRS:

Eine schreibgeschützte Kopie der Daten, die Sie in Ihrer primären Region speichern, wird asynchron in einer sekundären Region repliziert. Diese asynchrone Replikation bedeutet, dass die schreibgeschützte Kopie in der sekundären Region letztendlich mit den Daten in der primären Region konsistent ist. Der Speicherdienst bestimmt den Standort der sekundären Region.
Sie können die Azure Storage-Clientbibliotheken verwenden, um Lese- und Aktualisierungsanforderungen für den primären Regionsendpunkt auszuführen. Wenn die primäre Region nicht verfügbar ist, können Sie Leseanforderungen automatisch an die sekundäre Region umleiten. Sie können Ihre App auch so konfigurieren, dass Leseanforderungen direkt an die sekundäre Region gesendet werden, auch wenn die primäre Region verfügbar ist.
Wenn die primäre Region nicht verfügbar ist, können Sie ein Kontofailover initiieren. Wenn Sie zur sekundären Region überwechseln, werden die DNS-Einträge, die auf die primäre Region zeigen, so geändert, dass sie auf die sekundäre Region zeigen. Nach Abschluss des Failovers wird der Schreibzugriff für GRS- und RA-GRS-Konten wiederhergestellt. Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Arbeiten mit letztendlich konsistenten Daten

Die vorgeschlagene Lösung geht davon aus, dass es akzeptabel ist, potenziell veraltete Daten an die aufrufende Anwendung zurückzugeben. Da die Daten in der sekundären Region letztendlich konsistent sind, kann es vorkommen, dass die primäre Region nicht mehr zugänglich ist, bevor eine Aktualisierung in der sekundären Region vollständig repliziert wurde.

Angenommen, Ihr Kunde sendet ein Update erfolgreich, aber der primäre Bereich schlägt fehl, bevor das Update an die sekundäre Region weitergegeben wird. Wenn der Kunde die Daten zurücklesen möchte, erhalten sie die veralteten Daten aus der sekundären Region anstelle der aktualisierten Daten. Beim Entwerfen Ihrer Anwendung müssen Sie entscheiden, ob dieses Verhalten akzeptabel ist. Wenn dies der Fall ist, müssen Sie auch überlegen, wie der Benutzer benachrichtigt wird.

Später in diesem Artikel erfahren Sie mehr über die Verarbeitung von letztendlich konsistenten Daten und darüber, wie Sie die Eigenschaft "Letzte Synchronisierungszeit " überprüfen, um Abweichungen zwischen Daten in den primären und sekundären Regionen auszuwerten.

Getrennte oder gemeinsame Handhabung von Diensten

Es ist zwar unwahrscheinlich, dass ein Dienst (Blobs, Warteschlangen, Tabellen oder Dateien) nicht verfügbar ist, während die anderen Dienste weiterhin voll funktionsfähig sind. Sie können die Wiederholungen für jeden Dienst separat behandeln, oder Sie können Wiederholungen für alle Speicherdienste gemeinsam behandeln.

Wenn Sie z. B. Warteschlangen und Blobs in Ihrer Anwendung verwenden, können Sie sich entscheiden, separaten Code für die Behandlung von wiederholungsfähigen Fehlern für jeden Dienst einzufügen. Auf diese Weise wirkt sich ein Blobdienstfehler nur auf den Teil Ihrer Anwendung aus, der sich mit Blobs befasst, sodass Warteschlangen normal weiterlaufen. Falls Sie hingegen beschließen, alle Speicherdienstwiederholungen gemeinsam zu behandeln, werden Anforderungen für Blob- und Warteschlangendienste beeinträchtigt, wenn einer der Dienste einen wiederholbaren Fehler zurückgibt.

Letztendlich hängt diese Entscheidung von der Komplexität Ihrer Anwendung ab. Sie könnten es vorziehen, Fehler pro Dienst zu behandeln, um die Auswirkungen von Wiederholungen zu begrenzen. Oder Sie können Leseanforderungen für alle Speicherdienste an die sekundäre Region umleiten, wenn Sie ein Problem mit einem beliebigen Speicherdienst in der primären Region erkennen.

Ihre Anwendung im schreibgeschützten Modus ausführen

Um sich effektiv auf einen Ausfall in der primären Region vorzubereiten, muss Ihre Anwendung in der Lage sein, fehlgeschlagene Leseanforderungen und fehlgeschlagene Updateanforderungen zu verarbeiten. Wenn der primäre Bereich fehlschlägt, können Leseanforderungen an die sekundäre Region umgeleitet werden. Updateanforderungen können jedoch nicht umgeleitet werden, da die replizierten Daten in der sekundären Region schreibgeschützt sind. Aus diesem Grund müssen Sie Ihre Anwendung so gestalten, dass sie im schreibgeschützten Modus ausgeführt werden kann.

Sie können z. B. ein Kennzeichen festlegen, das überprüft wird, bevor Aktualisierungsanforderungen an Azure Storage übermittelt werden. Wenn eine Aktualisierungsanforderung erfolgt, können Sie die Anforderung überspringen und eine entsprechende Antwort an den Benutzer zurückgeben. Sie können sogar bestimmte Features vollständig deaktivieren, bis das Problem behoben ist, und Benutzer benachrichtigen, dass die Features vorübergehend nicht verfügbar sind.

Wenn Sie sich entscheiden, Fehler für jeden Dienst einzeln zu behandeln, müssen Sie auch die Möglichkeit, die Anwendung im schreibgeschützten Modus auszuführen, pro Dienst behandeln. Sie können beispielsweise Schreibschutzflags für jeden Dienst einrichten. Anschließend können Sie die Flags im Code nach Bedarf aktivieren oder deaktivieren.

Die Möglichkeit, die Anwendung im schreibgeschützten Modus auszuführen, ermöglicht es auch, während eines umfangreichen Anwendungsupgrades eine eingeschränkte Funktionalität zu gewährleisten. Sie können die Ausführung Ihrer Anwendung im schreibgeschützten Modus auslösen und auf das sekundäre Rechenzentrum verweisen, um sicherzustellen, dass niemand auf die Daten in der primären Region zugreift, während Sie Upgrades durchführen.

Verarbeiten von Updates bei Ausführung im schreibgeschützten Modus

Es gibt viele Möglichkeiten, mit Updateanforderungen umzugehen, wenn man im schreibgeschützten Modus arbeitet. Dieser Abschnitt konzentriert sich auf einige allgemeine Muster, die sie berücksichtigen sollten.

Sie können auf den Benutzer reagieren und sie benachrichtigen, dass Aktualisierungsanforderungen derzeit nicht verarbeitet werden. Beispielsweise könnte ein Kontaktverwaltungssystem Benutzern den Zugriff auf Kontaktinformationen ermöglichen, aber keine Aktualisierungen vornehmen.
Sie können Ihre Updates in einer anderen Region in die Warteschlange stellen. In diesem Fall würden Sie Ihre ausstehenden Updateanforderungen in eine Warteschlange in einer anderen Region schreiben und diese Anforderungen dann verarbeiten, nachdem das primäre Rechenzentrum wieder online ist. In diesem Szenario sollten Sie dem Benutzer mitteilen, dass die Updateanforderung zur späteren Verarbeitung in die Warteschlange gestellt wird.
Sie können Ihre Updates in ein Speicherkonto in einer anderen Region schreiben. Wenn die primäre Region wieder online ist, können Sie diese Aktualisierungen abhängig von der Struktur der Daten in die primären Daten zusammenführen. Wenn Sie beispielsweise separate Dateien mit einem Datums-/Uhrzeitstempel im Namen erstellen, können Sie diese Dateien wieder in den primären Bereich kopieren. Diese Lösung kann auf Workloads wie Protokollierung und IoT-Daten angewendet werden.

Umgang mit Wiederholversuchen

Anwendungen, die mit Diensten kommunizieren, die in der Cloud ausgeführt werden, müssen sensibel für ungeplante Ereignisse und Fehler sein, die auftreten können. Diese Fehler können vorübergehend oder dauerhaft sein, von einem vorübergehenden Verbindungsverlust bis zu einem erheblichen Ausfall aufgrund einer Naturkatastrophe. Es ist wichtig, Cloudanwendungen mit geeigneter Wiederholungsbehandlung zu entwerfen, um die Verfügbarkeit zu maximieren und die gesamte Anwendungsstabilität zu verbessern.

Leseanforderungen

Wenn der primäre Bereich nicht verfügbar ist, können Leseanforderungen an sekundären Speicher umgeleitet werden. Wie bereits erwähnt, muss es für Ihre Anwendung akzeptabel sein, veraltete Daten zu lesen. Die Azure Storage-Clientbibliothek bietet Optionen zum Behandeln von Wiederholungsversuchen und zum Umleiten von Leseanforderungen an eine sekundäre Region.

In diesem Beispiel wird die Wiederholungsbehandlung für BLOB-Speicher in der BlobClientOptions Klasse konfiguriert und auf das Objekt angewendet, das BlobServiceClient wir mithilfe dieser Konfigurationsoptionen erstellen. Diese Konfiguration folgt einem Primär-dann-Sekundär Ansatz, bei dem Leseanforderungen aus der primären Region an die sekundäre Region umgeleitet werden. Dieser Ansatz ist am besten geeignet, wenn Fehler in der primären Region vorübergehend sein werden.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for 
    // GET or HEAD requests during retries.
    // If the status of the response from the secondary Uri is a 404, then subsequent retries
    // for the request will not use the secondary Uri again, as this indicates that the resource 
    // may not have propagated there yet.
    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Wenn Sie feststellen, dass die primäre Region für einen langen Zeitraum wahrscheinlich nicht verfügbar ist, können Sie alle Leseanforderungen so konfigurieren, dass sie auf die sekundäre Region verweisen. Diese Konfiguration ist ein nur sekundärer Ansatz. Wie bereits erwähnt, benötigen Sie eine Strategie zum Behandeln von Updateanforderungen während dieser Zeit und eine Möglichkeit, Benutzer darüber zu informieren, dass nur Leseanforderungen verarbeitet werden. In diesem Beispiel erstellen wir eine neue Instanz von BlobServiceClient, die den sekundären Regionsendpunkt verwendet.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Create a BlobServiceClient object pointed at the secondary Uri
// Use blobServiceClientSecondary only when issuing read requests, as secondary storage is read-only
BlobServiceClient blobServiceClientSecondary = new BlobServiceClient(secondaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Die Entscheidung, wann zum schreibgeschützten Modus und zu rein sekundären Anforderungen gewechselt wird, ist Teil eines Architekturentwurfsmusters namens Trennschalter, das in einem späteren Abschnitt erläutert wird.

Aktualisierungsanfragen

Updateanforderungen können nicht auf den Sekundärspeicher umgeleitet werden, da dieser schreibgeschützt ist. Wie bereits beschrieben, muss Ihre Anwendung Updateanforderungen verarbeiten können, wenn die primäre Region nicht verfügbar ist.

Das Circuit Breaker-Muster kann auch für Aktualisierungsanforderungen verwendet werden. Um Aktualisierungsanforderungsfehler zu behandeln, können Sie einen Schwellenwert im Code festlegen, z. B. 10 aufeinander folgende Fehler, und die Anzahl der Fehler für Anforderungen an die primäre Region nachverfolgen. Sobald der Schwellenwert erreicht ist, können Sie die Anwendung in den schreibgeschützten Modus wechseln, sodass Aktualisierungsanforderungen an die primäre Region nicht mehr ausgegeben werden.

Wie man das Circuit Breaker-Muster implementiert

Die Behandlung von Fehlern, deren Behebung eine variable Zeit in Anspruch nehmen kann, ist Teil eines architektonischen Entwurfsmusters, das als Circuit Breaker-Muster bezeichnet wird. Die ordnungsgemäße Implementierung dieses Musters kann verhindern, dass eine Anwendung wiederholt versucht, einen Vorgang auszuführen, der wahrscheinlich fehlschlägt, wodurch die Anwendungsstabilität und Resilienz verbessert wird.

Ein Aspekt des Trennschalter-Musters ist die Ermittlung, ob ein fortlaufendes Problem mit einem primären Endpunkt vorliegt. Um diese Bestimmung zu treffen, können Sie überwachen, wie häufig der Client auf wiederholungsfähige Fehler stößt. Da jedes Szenario anders ist, müssen Sie einen geeigneten Schwellenwert ermitteln, der für die Entscheidung verwendet werden soll, zum sekundären Endpunkt zu wechseln und die Anwendung im schreibgeschützten Modus auszuführen.

Sie könnten sich zum Umschalten entscheiden, wenn in der primären Region 10 aufeinander folgende Fehler auftreten. Sie können dies nachverfolgen, indem Sie die Anzahl der Fehler im Code beibehalten. Wenn es vor Erreichen des Schwellenwerts einen Erfolg gibt, setzen Sie die Anzahl wieder auf Null zurück. Wenn die Anzahl den Schwellenwert erreicht, wechseln Sie die Anwendung, um die sekundäre Region für Leseanforderungen zu verwenden.

Als alternativer Ansatz können Sie sich für die Implementierung einer benutzerdefinierten Überwachungskomponente in Ihrer Anwendung entscheiden. Diese Komponente kann Ihren primären Speicherendpunkt kontinuierlich mit trivialen Leseanforderungen (beispielsweise für ein kleines Blob) pingen, um die Integrität des Endpunkts zu bestimmen. Dieser Ansatz würde einige Ressourcen, aber keine erhebliche Menge in Anspruch nehmen. Wird ein Problem festgestellt, das den festgelegten Schwellenwert erreicht, wird zu rein sekundären Leseanforderungen und zum schreibgeschützten Modus gewechselt. In diesem Szenario können Sie, sobald das Pingen des primären Speicherendpunkts wieder erfolgreich ist, zur primären Region zurückwechseln und weiterhin Updates zulassen.

Der Fehlerschwellenwert, der verwendet wird, um zu bestimmen, wann der Wechsel erfolgen soll, kann von Dienst zu Dienst innerhalb Ihrer Anwendung variieren, daher sollten Sie erwägen, diese konfigurierbaren Parameter zu erstellen.

Ein weiterer Aspekt ist, wie sie mehrere Instanzen einer Anwendung behandeln und was zu tun ist, wenn Sie in jeder Instanz wiederholte Fehler erkennen. Beispielsweise können 20 VMs mit derselben geladenen Anwendung ausgeführt werden. Behandeln Sie jede Instanz separat? Wenn eine Instanz Probleme hat, möchten Sie die Antwort auf diese einzige Instanz beschränken? Oder möchten Sie, dass alle Instanzen auf die gleiche Weise reagieren, wenn eine Instanz ein Problem hat? Die getrennte Behandlung der Instanzen ist wesentlich einfacher als der Versuch, die Antwort darauf zu koordinieren, aber Ihr Ansatz hängt von der Architektur Ihrer Anwendung ab.

Verarbeitung von letztendlich konsistenten Daten

Georedundanter Speicher funktioniert, indem Transaktionen von der primären in die sekundäre Region repliziert werden. Der Replikationsprozess garantiert, dass die Daten in der sekundären Region letztendlich konsistent sind. Dies bedeutet, dass alle Transaktionen in der primären Region letztendlich in der sekundären Region angezeigt werden, aber es kann zu einem Verzögerung kommen, bevor sie angezeigt werden. Es gibt auch keine Garantie dafür, dass Transaktionen in der sekundären Region in derselben Reihenfolge eingehen, wie sie ursprünglich in der primären Region angewendet wurden. Wenn Ihre Transaktionen in der sekundären Region außerhalb der Reihenfolge ankommen, können Sie ihre Daten in der sekundären Region in einem inkonsistenten Zustand betrachten, bis der Dienst nachholt.

Das folgende Beispiel für den Azure-Tabellenspeicher zeigt, was passieren kann, wenn Sie die Details eines Mitarbeiters aktualisieren, um sie zu einem Mitglied der Administratorrolle zu machen. Für dieses Beispiel müssen Sie die Mitarbeiterentität aktualisieren und eine Administratorrollenentität mit der Gesamtzahl der Administratoren aktualisieren. Beachten Sie, wie die Updates in der sekundären Region nicht in der Reihenfolge angewendet werden.

Zeit	Transaktion	Replikation	Letzte Synchronisierungszeit	Ergebnis
T0	Transaktion A: Mitarbeiter einfügen Entität in primärer Instanz			Transaktion A wurde in die Primärdatenbank eingefügt. noch nicht repliziert.
T1		Transaktion A repliziert nach sekundär	T1	Transaktion A wurde auf die sekundäre Instanz repliziert. Uhrzeit der letzten Synchronisierung aktualisiert.
T2	Transaktion B: Aktualisierung Mitarbeiterentität in der Primarstufe		T1	Transaktion B im Primärsystem gespeichert. noch nicht repliziert.
T3	Transaktion C: Aktualisierung Administrator Rollenentität in primär		T1	Transaktion C wurde im Primärsystem geschrieben. noch nicht repliziert.
T4		Transaktion C repliziert nach sekundär	T1	Die Transaktion C wurde auf das Sekundärsystem repliziert. LastSyncTime nicht aktualisiert, weil Die Transaktion B wurde noch nicht repliziert.
T5	Lesen von Entitäten aus der Sekundarstufe		T1	Sie erhalten den veralteten Wert für Mitarbeiterdaten. Entität, da Transaktion B nicht abgeschlossen ist noch nicht repliziert. Sie erhalten den neuen Wert für Administratorrollenentität, weil C hat dupliziert. Letzte Synchronisierungszeit hat noch nicht stattgefunden. Es wurde aktualisiert, da Transaktion B ist nicht repliziert worden. Sie können die Die Administratorrollenentität ist inkonsistent. da der Zeitpunkt der Entität nach dem vorgesehenen Zeitpunkt liegt die letzte Synchronisierungszeit.
T6		Transaktion B repliziert nach sekundär	T6	T6 – Alle Transaktionen über C haben Wurde repliziert, Zeitpunkt der letzten Synchronisierung Wird aktualisiert.

In diesem Beispiel wird davon ausgegangen, dass der Client bei T5 zum Lesen aus der sekundären Region wechselt. Sie kann die Administratorrollenentität zu diesem Zeitpunkt erfolgreich lesen, aber die Entität enthält einen Wert für die Anzahl der Administratoren, die nicht mit der Anzahl der Mitarbeiterentitäten konsistent sind, die derzeit als Administratoren in der sekundären Region gekennzeichnet sind. Ihr Client könnte diesen Wert mit dem Risiko anzeigen, dass die Informationen inkonsistent sind. Alternativ kann der Client versuchen, festzustellen, ob sich die Administratorrolle in einem potenziell inkonsistenten Zustand befindet, da die Updates nicht ordnungsgemäß ausgeführt wurden, und dann den Benutzer über diese Tatsache informieren.

Um festzustellen, ob ein Speicherkonto potenziell inkonsistente Daten enthält, kann der Client den Wert der Eigenschaft "Letzte Synchronisierungszeit " überprüfen. Die Uhrzeit der letzten Synchronisierung informiert Sie, wann die Daten in der sekundären Region zuletzt konsistent waren und wann der Dienst alle Transaktionen vor diesem Zeitpunkt angewendet hatte. Im obigen Beispiel wird nach dem Einfügen der Mitarbeiterentität in die sekundäre Region die letzte Synchronisierungszeit auf T1 festgelegt. Er verbleibt bei T1 , bis der Dienst die Mitarbeiterentität in der sekundären Region aktualisiert, wenn er auf T6 festgelegt ist. Wenn der Client beim Lesen der Entität bei T5 die letzte Synchronisierungszeit abruft, kann er sie mit dem Zeitstempel der Entität vergleichen. Wenn der Zeitstempel für die Entität später als die letzte Synchronisierungszeit ist, befindet sich die Entität in einem potenziell inkonsistenten Zustand, und Sie können die entsprechende Aktion ausführen. Wenn Sie dieses Feld verwenden, müssen Sie wissen, wann die letzte Aktualisierung der primären Datei abgeschlossen wurde.

Informationen zum Überprüfen der letzten Synchronisierungszeit finden Sie unter "Überprüfen der Eigenschaft "Letzte Synchronisierungszeit" für ein Speicherkonto.

Testen

Es ist wichtig, zu testen, ob sich Die Anwendung erwartungsgemäß verhält, wenn sie auf wiederholungsfähige Fehler stößt. Sie müssen z. B. testen, ob die Anwendung zu der sekundären Region wechselt, wenn ein Problem erkannt wird, und dann wieder zurückwechseln, wenn der primäre Bereich wieder verfügbar wird. Um dieses Verhalten ordnungsgemäß zu testen, benötigen Sie eine Möglichkeit, retryable Fehler zu simulieren und zu steuern, wie oft sie auftreten.

Eine Möglichkeit besteht darin, Fiddler zum Abfangen und Ändern von HTTP-Antworten in einem Skript zu verwenden. Dieses Skript kann Antworten identifizieren, die von Ihrem primären Endpunkt stammen, und den HTTP-Statuscode in einen code ändern, der von der Speicherclientbibliothek als wiederholter Fehler erkannt wird. Dieser Codeausschnitt zeigt ein einfaches Beispiel für ein Fiddler-Skript, das Antworten auf Leseanforderungen für die Mitarbeiterdatentabelle abfangen kann, um einen Status von 502 zurückzugeben:

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[YOURSTORAGEACCOUNTNAME\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

Sie können dieses Beispiel erweitern, um einen größeren Bereich von Anforderungen abzufangen und nur den responseCode für einige davon zu ändern, um ein reales Szenario besser zu simulieren. Weitere Informationen zum Anpassen von Fiddler-Skripts finden Sie unter Ändern einer Anforderung oder Antwort in der Fiddler-Dokumentation.

Wenn Sie konfigurierbare Schwellenwerte eingerichtet haben, um Ihre Anwendung in den schreibgeschützten Modus zu versetzen, ist es einfacher, das Verhalten mit nicht-produktiven Transaktionsvolumen zu testen.

Nächste Schritte

Ein vollständiges Beispiel, in dem gezeigt wird, wie sie zwischen den primären und sekundären Endpunkten hin- und herwechseln können, finden Sie unter Azure Samples – Using the Circuit Breaker Pattern with RA-GRS storage.