Verwenden von Georedundanz zum Entwerfen von hochverfügbaren Anwendungen

Ein Feature von cloudbasierten Infrastrukturen wie Azure Storage ist, dass sie eine hochverfügbare und permanente Plattform zum Hosten von Daten und Anwendungen bereitstellen. 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 georedundanten Speicher, um Hochverfügbarkeit auch bei einem regionalen Ausfall zu gewährleisten. Speicherkonten, die für die georedundante Replikation konfiguriert sind, werden synchron in die primäre Region und dann asynchron in eine sekundäre Region repliziert, die Hunderte von Kilometern entfernt ist.

Azure Storage bietet zwei Optionen für georedundante Replikation. Der einzige Unterschied zwischen diesen beiden Optionenbesteht in der Art, wie Daten in der primären Region repliziert werden:

  • Geozonenredundanter Speicher (GZRS): Die Daten werden synchron über drei Azure-Verfügbarkeitszonen in die primären Region mithilfe von zonenredundantem Speicher (ZRS) repliziert und anschließend asynchron in die sekundäre Region repliziert. Aktivieren Sie für den Lesezugriff auf Daten in der sekundären Region den geozonenredundanten Speicher mit Lesezugriff (RA-GZRS).

    Microsoft empfiehlt die Verwendung von GZRS/RA-GZRS für Szenarien, die eine maximale Verfügbarkeit und Dauerhaftigkeit erfordern.

  • Georedundanter Speicher (GRS): Die Daten werden in der primären Region unter Verwendung von lokal redundantem Speicher (LRS) drei Mal synchron repliziert und dann asynchron in die sekundäre Region repliziert. Aktivieren Sie für den Lesezugriff auf die Daten in der sekundären Region den georedundanten Speicher mit Lesezugriff (RA-GRS).

In diesem Artikel wird gezeigt, wie Sie Ihre Anwendung so entwerfen, dass sie einen Ausfall in der primären Region verarbeiten kann. Wenn die primäre Region nicht mehr verfügbar ist, kann sich Ihre Anwendung anpassen, um stattdessen Lesevorgänge in der sekundären Region durchzuführen. Stellen Sie sicher, dass Ihr Speicherkonto für RA-GRS oder RA-GZRS konfiguriert ist, bevor Sie beginnen.

Überlegungen zum Anwendungsentwurf beim Lesen aus der sekundären Region

Der Zweck dieses Artikels ist, zu veranschaulichen, wie Sie eine Anwendung entwerfen, die auch im Fall eines schwerwiegenden Zwischenfalls im primären Rechenzentrum weiterhin funktioniert (wenn auch nur mit begrenzter Kapazität). Sie können Ihre Anwendung so entwerfen, dass vorübergehende oder länger andauernde Probleme mittels Lesen aus der sekundären Region behandelt werden, wenn eine Störung 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 beim Entwerfen Ihrer Anwendung für RA-GRS oder RA-GZRS folgende wichtige Punkte:

  • Azure Storage verwaltet eine schreibgeschützte Kopie der Daten, die Sie in Ihrer primären Region speichern, in einer sekundären Region. Wie oben bereits erwähnt, bestimmt der Speicherdienst den Speicherort der sekundären Region.

  • Die schreibgeschützte Kopie ist letztendlich konsistent mit den Daten in der primären Region.

  • Für Blobs, Tabellen und Warteschlangen können Sie den Wert für den Zeitpunkt der letzten Synchronisierung von der sekundären Region abfragen, der anzeigt, wann die letzte Replikation von der primären zur sekundären Region ausgeführt wurde. (Dies wird für Azure Files nicht unterstützt, da RA-GRS-Redundanz zum aktuellen Zeitpunkt dort nicht verfügbar ist.)

  • Sie können die Speicherclientbibliothek zum Lesen und Schreiben von Daten in der primären oder sekundären Region verwenden. Sie können Anforderungen auch automatisch an die sekundäre Region leiten, wenn bei einer Leseanforderung an die primäre Region eine Zeitüberschreitung auftritt.

  • 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, möglicherweise veraltete Daten an die aufrufende Anwendung zurückzugeben. Da die Daten in der sekundären Region letztendlich konsistent sind, ist es möglich, dass erst dann auf die primäre Region zugegriffen werden kann, wenn die Replikation eines Updates in die sekundäre Region fertig gestellt 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. Beim Entwurf Ihrer Anwendung müssen Sie entscheiden, ob dies akzeptabel ist, und wenn ja, wie Sie den Kunden darüber informieren möchten.

Weiter unten in diesem Artikel wird dargestellt, wie Sie den Zeitpunkt der letzten Synchronisierung der sekundären Daten überprüfen, um festzustellen, ob die sekundäre Region auf dem neuesten Stand ist.

Einzelnes oder gemeinsames Verarbeiten von Services

Auch wenn es unwahrscheinlich ist, kann es vorkommen, dass ein Dienst nicht mehr verfügbar ist, während die anderen Dienste weiterhin voll funktionsfähig sind. Sie können die Wiederholungen und den schreibgeschützten Modus für jeden Dienst (Blobs, Warteschlangen, Tabellen) einzeln verarbeiten, oder Sie können Wiederholungen generisch für alle Speicherdienste zusammen verarbeiten.

Wenn Sie beispielsweise Warteschlangen und Blobs in Ihrer Anwendung verwenden, können Sie sich dazu entschließen, separaten Code für die Verarbeitung von Wiederholungen nach einem Fehler für jeden Fehler hinzufügen. Bei einem Wiederholungsversuch des Blob-Diensts, während der Warteschlangendienst weiterhin funktioniert, wird nur der Teil der Anwendung beeinflusst, der Blobs verarbeitet. Wenn alle Speicherdienstwiederholungen verarbeitet werden sollen und ein Aufruf an den Blob-Dienst einen wiederholbaren Fehler zurückgibt, werden Anforderungen an den Blob-Dienst und den Warteschlangendienst beeinflusst.

Dies hängt letztendlich von der Komplexität Ihrer Anwendung ab. Sie können sich dazu entschließen, die Fehler nicht nach Dienst zu verarbeiten, sondern stattdessen Leseanforderungen für alle Speicherdienste an die sekundäre Region umzuleiten und die Anwendung im schreibgeschützten Modus auszuführen, wenn ein Problem mit dem Speicherdienst in der primären Region auftritt.

Weitere Überlegungen

Dies sind die weiteren Überlegungen, die im weiteren Verlauf dieses Artikels beschrieben werden.

  • Verarbeiten von Wiederholungen von Leseanforderungen mit dem Trennschalter-Muster

  • Letztendlich konsistente Daten und Zeitpunkt der letzten Synchronisierung

  • Testen

Ausführen der Anwendung im schreibgeschützten Modus

Um sich effektiv auf einen Ausfall in der primären Region vorzubereiten, müssen Sie in der Lage sein, sowohl Leseanforderungen als auch Aktualisierungsanforderungen mit Fehlern zu verarbeiten (Aktualisierungen sind in diesem Fall Einfügungen, Aktualisierungen und Löschungen). Wenn in der primären Region ein Fehler auftritt, können Leseanforderungen an die sekundäre Region umgeleitet werden. Aktualisierungsanforderungen können jedoch nicht in den sekundären Speicher umgeleitet werden, da dieser schreibgeschützt ist. Aus diesem Grund müssen Sie Ihre Anwendung so entwerfen, dass sie im schreibgeschützten Modus ausgeführt wird.

Sie können beispielsweise ein Flag festlegen, das vor dem Übermitteln von Aktualisierungsanforderungen an Azure Storage geprüft wird. Wenn eine der Aktualisierungsanforderungen übermittelt wird, können Sie sie überspringen und eine entsprechende Antwort an den Kunden zurückgeben. Sie können auch bestimmte Features insgesamt deaktivieren, bis das Problem gelöst ist, und die Benutzer darüber benachrichtigen, dass diese Funktionen vorübergehend nicht verfügbar sind.

Wenn Sie sich entscheiden, Fehler für jeden Dienst einzeln zu verarbeiten, müssen Sie auch die Möglichkeit zum Ausführen der Anwendung im schreibgeschützten Modus nach Dienst verarbeiten. Beispielsweise haben Sie möglicherweise Schreibschutzflags für jeden Dienst, die aktiviert und deaktiviert werden können. Dann können Sie das Flag an den entsprechenden Stellen im Code verwenden.

Ein weiterer Vorteil der Anwendungsausführung im schreibgeschützten Modus liegt in der Möglichkeit, während eines umfangreichen Anwendungsupgrades eingeschränkte Funktionalität sicherzustellen. 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. Dies wird hier nicht umfassend beschrieben, aber es gibt im Allgemeinen eine Reihe von Mustern, die Sie berücksichtigen sollten.

  • Sie können auf Ihren Benutzer reagieren und ihm erläutern, dass derzeit keine Aktualisierungen akzeptiert werden. Mit einem Kontaktverwaltungssystem könnten Kunden beispielsweise auf Kontaktinformationen zugreifen, jedoch keine Aktualisierungen vornehmen.

  • Sie können die Aktualisierungen in einer anderen Region der Warteschlange hinzufügen. In diesem Fall schreiben Sie die ausstehende Aktualisierungsanforderung in eine Warteschlange einer anderen Region und haben dadurch eine Möglichkeit, diese Anforderungen zu verarbeiten, wenn das primäre Rechenzentrum wieder online geschaltet wird. In diesem Szenario sollten Sie den Kunden darüber informieren, dass sich die angeforderte Aktualisierung für die spätere Verarbeitung in der Warteschlange befindet.

  • Sie können Ihre Aktualisierungen in ein Speicherkonto in einer anderen Region schreiben. Wenn das primäre Rechenzentrum wieder online geschaltet wird, haben Sie die Möglichkeit, diese Aktualisierungen je nach Datenstruktur mit den primären Daten zusammenzuführen. Wenn Sie beispielsweise separate Dateien mit einem Datums-/Zeitstempel im Namen erstellen, können Sie die Dateien zur primären Region kopieren. Dies funktioniert für einige Workloads wie z.B. Protokollierung und IoT-Daten.

Verarbeiten von Wiederholungsversuchen

Mit der Azure Storage-Clientbibliothek können Sie feststellen, für welche Fehler Wiederholungsversuche ausgeführt werden können. Für einen 404-Fehler (Ressource nicht gefunden) wird beispielsweise kein Wiederholungsversuch ausgeführt, da eine Wiederholung wahrscheinlich nicht erfolgreich ist. Andererseits kann für einen 500-Fehler ein Wiederholungsversuch ausgeführt werden, da es sich um einen Serverfehler handelt und möglicherweise einfach ein vorübergehendes Problem vorliegt. Weitere Informationen finden Sie im Open-Source-Code für die ExponentialRetry-Klasse in der Speicherclientbibliothek für .NET. (Suchen Sie nach der ShouldRetry-Methode.)

Leseanforderungen

Leseanforderungen können in den sekundären Speicher umgeleitet werden, wenn ein Problem mit dem primären Speicher vorliegt. Wie oben unter Verwenden von letztendlich konsistenten Daten beschrieben, muss Ihre Anwendung das Lesen möglicherweise veralteter Daten zulassen. Wenn Sie die Speicherclientbibliothek für den Zugriff auf Daten aus der sekundären Region verwenden, können Sie das Wiederholungsverhalten einer Leseanforderung angeben, indem Sie einen der folgenden Werte für die LocationMode-Eigenschaft festlegen:

  • PrimaryOnly (Standard)

  • PrimaryThenSecondary

  • SecondaryOnly

  • SecondaryThenPrimary

Wenn Sie LocationMode auf PrimaryThenSecondary festlegen und bei der ursprünglichen Leseanforderung an den primären Endpunkt ein Fehler auftritt, für den ein Wiederholungsversuch ausgeführt werden kann, führt der Client automatisch eine weitere Leseanforderung an den sekundären Endpunkt aus. Wenn es sich beim Fehler um ein Servertimeout handelt, muss der Client warten, bis das Timeout abläuft, bevor er einen wiederholbaren Fehler vom Dienst empfängt.

Es gibt im Grunde zwei zu berücksichtigende Szenarien bei der Reaktion auf einen wiederholbaren Fehler:

  • Dies ist ein isoliertes Problem, und nachfolgende Anforderungen an den primären Endpunkt geben keinen wiederholbaren Fehler zurück. Dies kann beispielsweise vorkommen, wenn ein vorübergehender Netzwerkfehler vorliegt.

    In diesem Szenario entstehen keine signifikanten Leistungseinbußen dadurch, dass LocationMode auf PrimaryThenSecondary festgelegt wird, da dies nur selten vorkommt.

  • Es handelt sich um ein Problem mit mindestens einem der Speicherdienste in der primären Region, und alle nachfolgenden Anforderungen an diesen Dienst in der primären Region geben wahrscheinlich für eine bestimmte Zeit einen wiederholbaren Fehler zurück. Dies kann beispielsweise vorkommen, wenn auf die primäre Region absolut nicht zugegriffen werden kann.

    In diesem Szenario treten Leistungseinbußen auf, da alle Leseanforderungen zunächst auf dem primären Endpunkt ausgeführt werden, dann warten, bis das Timeout abläuft, und anschließend zum sekundären Endpunkt wechseln.

Für diese Szenarien sollten Sie feststellen, ob es ein fortlaufendes Problem mit dem primären Endpunkt gibt, und alle Leseanforderungen direkt an den sekundären Endpunkt senden, indem Sie die LocationMode-Eigenschaft auf SecondaryOnly festlegen. Zu diesem Zeitpunkt sollten Sie die Anwendung auch auf die Ausführung im schreibgeschützten Modus festlegen. Dieser Ansatz wird als Trennschalter-Muster bezeichnet.

Aktualisieren von Anforderungen

Das Trennschalter-Muster kann auch auf Aktualisierungsanforderungen angewendet werden. Aktualisierungsanforderungen können jedoch nicht in den sekundären Speicher umgeleitet werden, da dieser schreibgeschützt ist. Sie sollten für diese Anforderungen den LocationMode-Eigenschaftensatz auf PrimaryOnly (Standard) belassen. Um diese Fehler zu verarbeiten, können Sie eine Metrik auf diese Anforderungen anwenden – z.B. 10 Fehler hintereinander – und wenn der Schwellenwert erreicht wird, überführen Sie die Anwendung in den schreibgeschützten Modus. Sie können die im nächsten Abschnitt über Trennschalter-Muster beschriebenen Methoden auch zum Zurückkehren in den Aktualisierungsmodus verwenden.

Trennschalter-Muster

Durch die Verwendung eines Trennschalter-Musters in Ihrer Anwendung können Sie verhindern, dass ein Vorgang wiederholt wird, bei dem vermutlich erneut ein Fehler auftritt. Die Anwendung kann weiterhin ausgeführt werden, anstatt Zeit in Anspruch zu nehmen, während der Vorgang fortlaufend exponentiell wiederholt wird. Außerdem erkennt das Muster, wenn der Fehler behoben wurde. Zu diesem Zeitpunkt kann die Anwendung den Vorgang erneut versuchen.

So implementieren Sie das Trennschalter-Muster

Um festzustellen, ob ein fortlaufendes Problem mit einem primären Endpunkt vorliegt, können Sie überwachen, wie häufig der Client Fehlerwiederholungen erkennt. Da jeder Fall unterschiedlich ist, müssen Sie den Schwellenwert für den Wechsel zum sekundären Endpunkt und zum Ausführen der Anwendung im schreibgeschützten Modus festlegen. Beispielsweise können Sie den Wechsel ausführen, wenn 10 Fehler hintereinander aufgetreten sind. Ein weiteres Beispiel ist, zu wechseln, wenn bei 90 % der Anforderungen in einem Zeitraum von 2 Minuten Fehler auftreten.

Für das erste Szenario können Sie einfach die Anzahl der Fehler verwenden. Bei einem Erfolg vor Erreichen des Maximalwerts wird der Zähler auf null zurückgesetzt. Für das zweite Szenario besteht die Möglichkeit zur Implementierung des MemoryCache-Objekts (in .NET). Für jede Anforderung fügen Sie dem Cache ein CacheItem hinzu, bestimmen den Wert für Erfolg (1) oder Fehler (0) und legen die Ablaufzeit auf 2 Minuten ab dem jetzigen Zeitpunkt fest (je nach gewünschter Zeiteinschränkung). Wenn ein Eintrag abläuft, wird der Eintrag automatisch entfernt. Dadurch erhalten Sie ein laufendes 2-Minuten-Fenster. Jedes Mal, wenn Sie eine Anforderung an den Speicherdienst übermitteln, stellen Sie zuerst eine Linq-Abfrage an das MemoryCache-Objekt, um den Erfolg in Prozent zu berechnen, indem die Werte addiert und die Summe durch die Anzahl geteilt wird. Wenn der Erfolg in Prozent unter einen Schwellenwert (z.B. 10 %) fällt, legen Sie die LocationMode-Eigenschaft für Leseanforderungen auf SecondaryOnly fest und überführen die Anwendung in den schreibgeschützten Modus, bevor Sie fortfahren.

Die Fehlerschwellenwerte, die zum Bestimmen des Wechsels verwendet werden, unterscheiden sich je nach den Diensten Ihrer Anwendung. Daher sollten Sie in Erwägung ziehen, diese zu konfigurierbaren Parametern zu machen. An dieser Stelle entscheiden Sie auch, ob wiederholbare Fehler von jedem Dienst getrennt oder gemeinsam verarbeitet werden, wie zuvor erläutert.

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? Wenn in einer Instanz Probleme auftreten, möchten Sie die Reaktion auf nur eine Instanz beschränken, oder sollen alle Instanzen gleichartig reagieren? Die getrennte Verarbeitung von Instanzen ist deutlich einfacher als eine koordinierte Reaktion. Die Vorgehensweise hängt jedoch von der Architektur Ihrer Anwendung ab.

Optionen zur Überwachung der Fehlerhäufigkeit

Sie haben drei Hauptoptionen für die Überwachung der Fehlerhäufigkeit in der primären Region, mit denen Sie bestimmen können, wann der Wechsel zur sekundären Region und in den schreibgeschützten Modus der Anwendung stattfindet.

  • Fügen Sie dem OperationContext-Objekt, das Sie an die Speicheranforderungen übergeben, einen Handler für das Wiederholungsereignis hinzu dies ist die Methode, die in diesem Artikel erläutert und im zugehörigen Beispiel verwendet wird. Diese Ereignisse werden ausgelöst, wenn der Client eine Anforderung wiederholt. Dadurch können Sie verfolgen, wie oft der Client wiederholbare Fehler auf einem primären Endpunkt feststellt.

    Wir arbeiten derzeit daran, Codeausschnitte für Version 12.x der Azure Storage-Clientbibliotheken zu erstellen. Weitere Informationen finden Sie unter Ankündigung der Azure Storage v12-Clientbibliotheken.

  • In der Methode Evaluieren in einer benutzerdefinierten Wiederholungsrichtlinie können Sie benutzerdefinierten Code ausführen, sobald ein erneuter Versuch stattfindet. Zusätzlich zur Erfassung des Zeitpunkts einer Wiederholung erhalten Sie auch die Möglichkeit, das Wiederholungsverhalten zu ändern.

    Wir arbeiten derzeit daran, Codeausschnitte für Version 12.x der Azure Storage-Clientbibliotheken zu erstellen. Weitere Informationen finden Sie unter Ankündigung der Azure Storage v12-Clientbibliotheken.

  • Der dritte Ansatz besteht darin, eine benutzerdefinierte Komponente in der Anwendung zu implementieren, die fortlaufend Ping-Nachrichten mit leeren Leseanforderungen (z.B. das Lesen eines kleinen Blobs) an den primären Speicherendpunkt sendet, um den Systemzustand zu ermitteln. Dies nimmt zwar einige Ressourcen in Anspruch, jedoch in einem unerheblichen Maß. Wenn ein Problem festgestellt wird, durch das der Schwellenwert erreicht wird, führen Sie einen Wechsel in den schreibgeschützten Modus SecondaryOnly durch.

Zu einem späteren Zeitpunkt möchten Sie wahrscheinlich zum primären Endpunkt zurückwechseln und Aktualisierungen wieder zulassen. Wenn Sie eine der ersten beiden oben aufgeführten Methoden verwenden, können Sie einfach zurück zum primären Endpunkt wechseln und den Aktualisierungsmodus nach einem beliebig gewählten Zeitraum oder einer Anzahl von Vorgängen aktivieren. Anschließend können Sie die Wiederholungslogik erneut ausführen lassen. Wenn das Problem behoben wurde, wird der primäre Endpunkt weiterhin verwendet, und Aktualisierungen werden zugelassen. Wenn weiterhin ein Problem vorliegt, wird erneut zum sekundären Endpunkt und in den schreibgeschützten Modus gewechselt, nachdem die festgelegten Fehlerkriterien nicht erfüllt wurden.

Wenn im dritten Szenario die Ping-Nachricht an den primären Speicherendpunkt erfolgreich ist, können Sie den Wechsel zurück zu PrimaryOnly auslösen und weiterhin Aktualisierungen zulassen.

Verarbeiten von letztendlich konsistenten Daten

Georedundanter Speicher funktioniert durch die Replikation von Transaktionen von der primären zur sekundären Region. Dieser Replikationsprozess garantiert, dass die Daten in der sekundären Region letztendlich konsistent sind. Das heißt, dass alle Transaktionen in der primären Region letztendlich in der sekundären Region angezeigt werden, wobei jedoch möglicherweise eine Verzögerung vor der Anzeige auftritt, und es gibt keine Garantie dafür, dass die Transaktionen in der sekundären Region in der gleichen Reihenfolge wie in der ursprünglichen Reihenfolge der primären Region eintreffen. 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.

Die folgende Tabelle zeigt ein Beispiel dafür, was passieren kann, wenn Sie die Details einer Mitarbeiterin aktualisieren, um sie zu einem Mitglied der Rolle Administratoren zu machen. 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. Er kann die Administratorrollenentität zu diesem Zeitpunkt erfolgreich lesen, die Entität enthält jedoch einen Wert für die Anzahl der Administratoren, die nicht konsistent mit der Anzahl der Mitarbeiterentitäten ist, die zu diesem Zeitpunkt in der sekundären Region als Administratoren gekennzeichnet sind. Der Client konnte diesen Wert anzeigen, es besteht jedoch das Risiko, dass es sich um inkonsistente Informationen handelt. 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 möglicherweise inkonsistente Daten zu erkennen, kann der Client den Wert des Zeitpunkts der letzten Synchronisierung verwenden, den Sie jederzeit durch eine Abfrage eines Speicherdiensts abrufen können. Dadurch können Sie den Zeitpunkt der letzten Datenkonsistenz in der sekundären Region und den Zeitpunkt feststellen, zu dem der Dienst alle Transaktionen vor diesem Zeitpunkt angewendet hat. 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, sobald sie auf T6 festgelegt wird. 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 für Ihre Anwendung 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 und in den schreibgeschützten Modus wechselt, wenn ein Problem entdeckt wird, und zurückwechselt, wenn die primäre Region wieder verfügbar ist. Zu diesem Zweck benötigen Sie eine Möglichkeit zum Simulieren von wiederholbaren Fehlern und deren Auftrittshäufigkeit.

Sie können Fiddler zum Abfangen und Bearbeiten von HTTP-Antworten in einem Skript verwenden. 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:

Wir arbeiten derzeit daran, Codeausschnitte für Version 12.x der Azure Storage-Clientbibliotheken zu erstellen. Weitere Informationen finden Sie unter Ankündigung der Azure Storage v12-Clientbibliotheken.

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.