Verwenden von Georedundanz zum Entwerfen von hochverfügbaren Anwendungen

Artikel
06/01/2023

Cloudbasierte Infrastrukturen wie Azure Storage bieten eine hochverfügbare und langlebige Plattform zum Hosten von Daten und Anwendungen. Entwickler von cloudbasierten Anwendungen müssen genau überlegen, wie sie diese Plattform nutzen, um diese Vorteile für ihre Benutzer zu maximieren. Azure Storage bietet Optionen für Georedundanz, um Hochverfügbarkeit auch bei einem regionalen Ausfall zu gewährleisten. 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). Wenn Sie die Georedundanzoptionen von Azure Storage nutzen möchten, muss Ihr Speicherkonto für georedundanten Speicher mit Lesezugriff (RA-GRS) oder für geozonenredundanten Speicher mit Lesezugriff (RA-GZRS) konfiguriert sein. Sollte dies nicht der Fall sein, erfahren Sie hier, wie Sie den Replikationstyp Ihres Speicherkontos ändern.

In diesem Artikel wird gezeigt, wie Sie eine Anwendung entwerfen, die auch im Falle eines signifikanten Ausfalls in der primären Region weiterhin funktioniert (wenn auch eingeschränkt). Ist die primäre Region nicht mehr verfügbar, kann Ihre Anwendung Lesevorgänge nahtlos in der sekundären Region durchführen, bis die primäre Region wieder reagiert.

Überlegungen zum Anwendungsentwurf

Sie können Ihre Anwendung so gestalten, dass vorübergehende Fehler oder länger andauernde Ausfälle durch Lesen aus der sekundären Region ausgeglichen werden, wenn ein Problem das Lesen aus der primären Region behindert. Wenn die primäre Region wieder verfügbar ist, kann Ihre Anwendung das Lesen aus der primären Region wieder aufnehmen.

Berücksichtigen Sie die folgenden wichtigen Aspekte, wenn Sie Ihre Anwendung für Verfügbarkeit und Resilienz mit RA-GRS oder RA-GZRS entwerfen:

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 eine letztliche Konsistenz zwischen der schreibgeschützten Kopie in der sekundären Region und den Daten in der primären Region. Der Speicherdienst bestimmt den Ort der sekundären Region.
Sie können die Azure Storage-Clientbibliotheken verwenden, um Lese- und Aktualisierungsanforderungen für den Endpunkt der primären Region auszuführen. Ist die primäre Region nicht verfügbar, können Leseanforderungen automatisch an die sekundäre Region umgeleitet werden. Falls gewünscht, können Sie 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 einleiten. Wenn Sie ein Failover auf die sekundäre Region ausführen, werden die DNS-Einträge, die auf die primäre Region verweisen, so geändert, dass sie auf die sekundäre Region verweisen. Nachdem das Failover abgeschlossen ist, wird der Schreibzugriff für GRS und RA-GRS-Konten wiederhergestellt. Weitere Informationen finden Sie unter Notfallwiederherstellung und Failover des Speicherkontos.

Verwenden von letztendlich konsistenten Daten

Die vorgeschlagene Lösung setzt voraus, dass es akzeptabel ist, potenziell veraltete Daten an die aufrufende Anwendung zurückzugeben. Aufgrund der letztlichen Konsistenz der Daten in der sekundären Region kann es vorkommen, dass nicht mehr auf die primäre Region zugegriffen werden kann und die Replikation einer Aktualisierung für die sekundäre Region noch nicht abgeschlossen ist.

Nehmen Sie beispielsweise an, dass Ihr Kunde erfolgreich ein Update sendet, aber die primäre Region ausfällt, bevor das Update an die sekundäre Region weitergegeben wird. Wenn der Kunde dann das Zurücklesen der Daten anfordert, empfängt er in diesem Fall statt der aktualisierten Daten die veralteten Daten aus der sekundären Region. Bei der Gestaltung Ihrer Anwendung müssen Sie entscheiden, ob dieses Verhalten akzeptabel ist. Falls ja, müssen Sie sich auch überlegen, wie Sie den Benutzer benachrichtigen.

Im weiteren Verlauf dieses Artikels erfahren Sie mehr über das Verarbeiten von letztendlich konsistenten Daten sowie dazu, wie Sie die Eigenschaft Letzte Synchronisierung überprüfen, um Abweichungen zwischen Daten in der primären und sekundären Region zu bewerten.

Einzelnes oder gemeinsames Verarbeiten von Services

In seltenen Fällen kann es vorkommen, dass ein einzelner Dienst (Blobs, Warteschlangen, Tabellen oder Dateien) nicht mehr verfügbar ist, während die anderen Dienste weiterhin voll funktionsfähig sind. Die Wiederholungen können entweder für jeden Dienst separat oder generisch für alle Speicherdienste behandelt werden.

Wenn Sie beispielsweise Warteschlangen und Blobs in Ihrer Anwendung verwenden, können Sie sich dazu entschließen, für jeden Dienst separaten Code zur Behandlung wiederholbarer Fehler hinzufügen. Dadurch wirkt sich ein Blobdienstfehler nur auf den Teil Ihrer Anwendung aus, der mit Blobs zusammenhängt, und Warteschlangen können weiterhin ganz normal ausgeführt werden. Falls Sie dagegen 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.

Diese Entscheidung hängt letztendlich von der Komplexität Ihrer Anwendung ab. Möglicherweise möchten Sie Fehler lieber pro Dienst behandeln, um die Auswirkungen von Wiederholungen zu begrenzen. Sie können aber auch Leseanforderungen für alle Speicherdienste an die sekundäre Region umleiten, wenn Sie ein Problem mit einem Speicherdienst in der primären Region feststellen.

Ausführen der Anwendung im schreibgeschützten Modus

Zur effektiven Vorbereitung auf einen Ausfall in der primären Region muss Ihre Anwendung sowohl nicht erfolgreiche Leseanforderungen als auch nicht erfolgreiche Aktualisierungsanforderungen behandeln können. Wenn in der primären Region ein Fehler auftritt, können Leseanforderungen an die sekundäre Region umgeleitet werden. Aktualisierungsanforderungen 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 beispielsweise ein Flag festlegen, das vor dem Übermitteln von Aktualisierungsanforderungen an Azure Storage geprüft wird. Wenn eine Aktualisierungsanforderung übermittelt wird, können Sie die Anforderung überspringen und eine entsprechende Antwort an den Benutzer zurückgeben. Sie können auch bestimmte Features gänzlich deaktivieren, bis das Problem gelöst ist, und die Benutzer darüber 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 Anwendungsausführung im schreibgeschützten Modus auslösen, auf das sekundäre Rechenzentrum verweisen und damit sicherstellen, dass niemand auf die Daten in der primären Region zugreift, während Sie Upgrades vornehmen.

Verarbeiten von Aktualisierungen bei der Ausführung im schreibgeschützten Modus

Es gibt viele Möglichkeiten, Aktualisierungsanforderungen bei der Ausführung im schreibgeschützten Modus zu verarbeiten. Dieser Abschnitt konzentriert sich auf einige mögliche allgemeine Muster.

Sie können dem Benutzer antworten und ihn darüber informieren, dass Aktualisierungsanforderungen derzeit nicht verarbeitet werden. Ein Beispiel wäre etwa ein Kontaktverwaltungssystem, bei dem Benutzer zwar auf Kontaktinformationen zugreifen, aber keine Aktualisierungen vornehmen können.
Sie können die Aktualisierungen in einer anderen Region der Warteschlange hinzufügen. In diesem Fall werden die ausstehenden Aktualisierungsanforderungen in eine Warteschlange in einer anderen Region geschrieben und erst verarbeitet, wenn das primäre Rechenzentrum wieder online ist. Informieren Sie in diesem Szenario den Benutzer darüber, dass sich die Aktualisierungsanforderung in der Warteschlange befindet und erst später verarbeitet wird.
Sie können Ihre Aktualisierungen in ein Speicherkonto in einer anderen Region schreiben. Wenn die primäre Region wieder online ist, können Sie diese Aktualisierungen je nach Datenstruktur mit den primären Daten zusammenführen. Wenn Sie beispielsweise separate Dateien mit einem Datums-/Zeitstempel im Namen erstellen, können Sie die Dateien wieder in die primäre Region kopieren. Diese Lösung kann auf Workloads wie Protokollierung und IoT-Daten angewendet werden.

Verarbeiten von Wiederholungsversuchen

Anwendungen, die mit Diensten kommunizieren, die in der Cloud ausgeführt werden, müssen auf ungeplante Ereignisse und mögliche Fehler vorbereitet sein. Diese Fehler können vorübergehend oder dauerhaft sein und reichen von einem kurzzeitigen Konnektivitätsverlust bis hin zu einem signifikanten Ausfall aufgrund einer Naturkatastrophe. Es ist wichtig, Cloudanwendungen mit einer geeigneten Wiederholungsbehandlung zu entwerfen, um die Verfügbarkeit zu maximieren und die allgemeine Anwendungsstabilität zu verbessern.

Leseanforderungen

Wenn die primäre Region nicht mehr verfügbar ist, können Leseanforderungen an sekundären Speicher umgeleitet werden. Wie bereits erwähnt, muss für Ihre Anwendung das Lesen potenziell veralteter Daten akzeptabel sein. Die Azure Storage-Clientbibliothek bietet Optionen zur Behandlung von Wiederholungen und zur Umleitung von Leseanforderungen an eine sekundäre Region.

In diesem Beispiel ist die Wiederholungsbehandlung für Blobspeicher in der Klasse BlobClientOptions konfiguriert und gilt für das Objekt BlobServiceClient, das unter Verwendung dieser Konfigurationsoptionen erstellt wird. Bei dieser Konfiguration handelt es sich um einen Ansatz vom Typ erst primär, dann sekundär. Das bedeutet, dass Wiederholungen für Leseanforderungen aus der primären Region an die sekundäre Region umgeleitet werden. Dieser Ansatz eignet sich am besten, wenn davon auszugehen ist, dass Fehler in der primären Region vorübergehend sind.

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);

Ist die primäre Region wahrscheinlich länger nicht verfügbar, können Sie alle Leseanforderungen so konfigurieren, dass sie auf die sekundäre Region zeigen. Bei dieser Konfiguration handelt es sich um einen rein sekundären Ansatz. Wie bereits erwähnt, benötigen Sie eine Strategie für die Behandlung von Updateanforderungen während dieser Zeit sowie eine Möglichkeit, Benutzer darüber zu informieren, dass nur Leseanforderungen verarbeitet werden. In diesem Beispiel wird eine neue Instanz von BlobServiceClient erstellt, die den Endpunkt der sekundären Region 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.

Aktualisieren von Anforderungen

Aktualisierungsanforderungen können nicht an den sekundären Speicher umgeleitet werden, da dieser schreibgeschützt ist. Wie bereits beschrieben, muss Ihre Anwendung Updateanforderungen behandeln können, wenn die primäre Region nicht verfügbar ist.

Das Trennschalter-Muster kann auch auf Aktualisierungsanforderungen angewendet werden. Zur Behandlung von Aktualisierungsanforderungsfehlern können Sie im Code einen Schwellenwert (z. B. zehn aufeinander folgende Fehler) festlegen und die Anzahl von Fehlern für Anforderungen nachverfolgen, die für die primäre Region bestimmt sind. Bei Erreichen des Schwellenwerts kann die Anwendung in den schreibgeschützten Modus versetzt werden, sodass keine Aktualisierungsanforderungen mehr für die primäre Region ausgegeben werden.

Implementieren des Trennschalter-Musters

Die Behandlung von Fehlern, deren Behebung unterschiedlich lange dauern kann, ist Teil eines Architekturentwurfsmusters, das als Trennschalter-Muster bezeichnet wird. Die ordnungsgemäße Implementierung dieses Musters kann verhindern, dass eine Anwendung wiederholt versucht, einen Vorgang auszuführen, der wahrscheinlich nicht erfolgreich ist. Dies trägt zur Verbesserung der Anwendungsstabilität und -resilienz bei.

Ein Aspekt des Trennschalter-Musters ist die Ermittlung, ob ein fortlaufendes Problem mit einem primären Endpunkt vorliegt. Hierzu können Sie überwachen, wie häufig der Client wiederholbare Fehler erkennt. Da jedes Szenario anders ist, müssen Sie einen geeigneten Schwellenwert für die Entscheidung bestimmen, wann zum sekundären Endpunkt gewechselt und die Anwendung im schreibgeschützten Modus ausgeführt werden soll.

Sie können beispielsweise entscheiden, dass der Wechsel erfolgen soll, wenn in der primären Region zehn aufeinander folgende Fehler aufgetreten sind. Hierzu können Sie im Code die Anzahl von Fehler nachverfolgen. Im Falle eines Erfolgs vor Erreichen des Schwellenwerts wird der Zähler wieder auf null zurückgesetzt. Erreicht die Anzahl den Schwellenwert, verwendet die Anwendung die sekundäre Region für Leseanforderungen.

Alternativ können Sie eine benutzerdefinierte Überwachungskomponente in Ihrer Anwendung implementieren. 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. Bei diesem Ansatz wird eine unerhebliche Menge an Ressourcen beansprucht. Wird ein Problem festgestellt, das den festgelegten Schwellenwert erreicht, wird zu rein sekundären Leseanforderungen und zum schreibgeschützten Modus gewechselt. In diesem Szenario gilt: Wenn der primäre Speicherendpunkt wieder erfolgreich gepingt werden kann, können Sie wieder zur primären Region wechseln und Aktualisierungen zulassen.

Die Fehlerschwellenwerte für die Entscheidung, wann der Wechsel erfolgen soll, sind je nach Dienst in Ihrer Anwendung unterschiedlich. Daher empfiehlt es sich gegebenenfalls, sie zu konfigurierbaren Parametern zu machen.

Ein weiterer Aspekt ist, wie mehrere Instanzen einer Anwendung verarbeitet werden und wie vorgegangen wird, wenn in den einzelnen Instanzen wiederholbare Fehler erkannt werden. Gehen wir beispielsweise davon aus, dass 20 VMs mit der gleichen geladenen Anwendung ausführen. Verarbeiten Sie jede Instanz separat? Soll die Reaktion im Falle von Problemen bei einer einzelnen Instanz auf diese einzelne Instanz beschränkt werden? Oder sollen alle Instanzen auf die gleiche Weise reagieren? Die getrennte Behandlung von Instanzen ist deutlich einfacher als eine koordinierte Reaktion. Der zu verwendende Ansatz hängt jedoch von der Architektur Ihrer Anwendung ab.

Verarbeiten von letztendlich konsistenten Daten

Georedundanter Speicher funktioniert durch die Replikation von Transaktionen von der primären zur sekundären Region. Der Replikationsprozess garantiert die letztliche Konsistenz der Daten in der sekundären Region. Das bedeutet, dass alle Transaktionen in der primären Region letztlich in der sekundären Region verfügbar werden, wenn auch ggf. mit Verzögerung. Außerdem gibt es keine Garantie dafür, dass die Transaktionen in der sekundären Region in der gleichen Reihenfolge eintreffen, in der sie ursprünglich in der primären Region angewendet wurden. Wenn die Transaktionen nicht in der richtigen Reihenfolge in der sekundären Region eintreffen, können Sie möglicherweise davon ausgehen, dass die Daten in der sekundären Region inkonsistent sind, bis der Dienst auf dem aktuellen Stand ist.

Das folgende Beispiel für Azure Table Storage zeigt, was passieren kann, wenn Sie die Details eines Mitarbeiters aktualisieren, um ihn der Administratorrolle hinzuzufügen. Für dieses Beispiel müssen Sie die Mitarbeiterentität und eine Administratorrollenentität mit der Gesamtanzahl der Administratoren aktualisieren. Beachten Sie, dass die Aktualisierungen in der sekundären Region in falscher Reihenfolge angewendet werden.

Time	Transaktion	Replikation	Zeitpunkt der letzten Synchronisierung	Ergebnis
T0	Transaktion A: Mitarbeiterentität in primäre Region einfügen			Transaktion A in primäre Region eingefügt, noch nicht repliziert.
T1		Transaktion A in sekundäre Region repliziert	T1	Transaktion A in sekundäre Region repliziert. Zeitpunkt der letzten Synchronisierung aktualisiert.
T2	Transaktion B: Aktualisieren Mitarbeiterentität in primärer Region		T1	Transaktion B in primäre Region geschrieben, noch nicht repliziert.
T3	Transaktion C: Aktualisieren administrator Rollenentität in primary		T1	Transaktion C in primäre Region geschrieben, noch nicht repliziert.
T4		Transaktion C in sekundäre Region repliziert	T1	Transaktion C in sekundäre Region repliziert. LastSyncTime nicht aktualisiert, da Transaktion B noch nicht repliziert wurde.
T5	Entitäten aus sekundärer Region gelesen		T1	Sie erhalten den veralteten Wert für die Mitarbeiterentität, da die Transaktion B noch nicht repliziert wurde. Sie erhalten den neuen Wert für die Administratorrollenentität, da C repliziert wurde. Zeitpunkt der letzten Synchronisierung wurde noch nicht aktualisiert, da die Transaktion B noch nicht repliziert wurde. Sie können erkennen, dass die Administratorrollenentität inkonsistent ist, da Datum und Uhrzeit der Entität nach dem Zeitpunkt der letzten Synchronisierung liegen.
T6		Transaktion B in sekundäre Region repliziert	T6	T6 – alle Transaktionen bis C wurden repliziert, Zeitpunkt der letzten Synchronisierung wurde aktualisiert.

In diesem Beispiel wird davon ausgegangen, dass der Client bei T5 zum Lesen aus der sekundären Region wechselt. Zu diesem Zeitpunkt kann er die Administratorrollenentität zwar erfolgreich lesen, die Entität enthält jedoch einen Wert für die Anzahl von Administratoren, der nicht mit der Anzahl von Mitarbeiterentitäten konsistent ist, die zu diesem Zeitpunkt in der sekundären Region als Administratoren gekennzeichnet sind. Der Client kann diesen Wert anzeigen, die Angabe ist jedoch möglicherweise inkonsistent. Wahlweise kann der Client versuchen, festzustellen, ob die Administratorrolle möglicherweise inkonsistent ist, da die Aktualisierungen nicht in der richtigen Reihenfolge vorliegen, und anschließend können die Benutzer über diese Tatsache informiert werden.

Um zu ermitteln, ob ein Speicherkonto potenziell inkonsistente Daten enthält, kann der Client den Wert der Eigenschaft Letzte Synchronisierung überprüfen. Letzte Synchronisierung gibt Aufschluss über den Zeitpunkt, zu dem die Daten in der sekundären Region zuletzt konsistent waren und alle Transaktionen vor diesem Zeitpunkt angewendet wurden. Im Beispiel oben wird nach dem Einfügen der Mitarbeiterentität in der sekundären Region durch den Dienst der Zeitpunkt der letzten Synchronisierung auf T1 festgelegt. Der Wert bleibt T1, bis der Dienst die Mitarbeiterentität in der sekundären Region aktualisiert. Dann wird der Wert auf T6 festgelegt. Wenn der Client den Zeitpunkt der letzten Synchronisierung beim Lesen der Entität bei T5 abruft, kann dieser ihn mit dem Zeitstempel der Entität vergleichen. Wenn der Zeitstempel der Entität nach dem Zeitpunkt der letzten Synchronisierung liegt, ist die Entität möglicherweise inkonsistent, und Sie können die entsprechende Aktion ausführen. Die Verwendung dieses Felds erfordert, dass Sie wissen, wann die letzte Aktualisierung des primären Replikats abgeschlossen wurde.

Informationen, wie Sie die letzte Synchronisierungszeit überprüfen, finden Sie unter Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto.

Testen

Es ist wichtig, zu testen, ob Ihre Anwendung sich erwartungsgemäß verhält, wenn wiederholbare Fehler auftreten. Beispielsweise müssen Sie testen, ob die Anwendung zur sekundären Region wechselt, wenn ein Problem erkannt wird, und ob sie wieder zurückwechselt, wenn die primäre Region wieder verfügbar ist. Um dieses Verhalten ordnungsgemäß testen zu können, müssen Sie wiederholbare Fehler simulieren und deren Auftrittshäufigkeit erfassen.

Eine Option hierfür ist das Abfangen und Ändern von HTTP-Antworten in einem Skript mithilfe von Fiddler. Dieses Skript kann Antworten vom primären Endpunkt identifizieren und den HTTP-Statuscode in einen Statuscode ändern, den die Speicherclientbibliothek als wiederholbaren Fehler erkennt. Dieser Codeausschnitt zeigt ein einfaches Beispiel eines Fiddler-Skripts, das Antworten auf Leseanforderungen an die employeedata-Tabelle abfängt, um einen 502-Status 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önnten dieses Beispiel erweitern, um ein größeres Spektrum an Anforderungen abzufangen, und nur den responseCode für einige Anforderungen ändern, um ein realistischeres Szenario zu simulieren. Weitere Informationen zum Anpassen von Fiddler-Skripts finden Sie unter Modifying a Request or Response (Ä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 Transaktionsvolumen außerhalb von Produktionsumgebungen zu testen.

Nächste Schritte

Ein vollständiges Beispiel zur Erläuterung des Wechsels zwischen den primären und sekundären Endpunkten finden Sie unter Beispiele für Azure – Verwenden des Trennschalter-Musters mit RA-GRS-Speicher.