Geo-redundantie gebruiken om toepassingen met hoge beschikbare gegevens te ontwerpen

Een veelvoorkomende functie van cloudinfrastructuren zoals Azure Storage is dat ze een zeer beschikbaar en duurzaam platform bieden voor het hosten van gegevens en toepassingen. Ontwikkelaars van cloudtoepassingen moeten zorgvuldig overwegen hoe ze dit platform kunnen gebruiken om deze voordelen voor hun gebruikers te maximaliseren. Azure Storage biedt geografisch redundante opslag om hoge beschikbaarheid te garanderen, zelfs in het geval van een regionale storing. Storage accounts die zijn geconfigureerd voor geografisch redundante replicatie, worden synchroon gerepliceerd in de primaire regio en vervolgens asynchroon gerepliceerd naar een secundaire regio die honderden kilometers verderop ligt.

Azure Storage biedt twee opties voor geografisch redundante replicatie. Het enige verschil tussen deze twee opties is hoe gegevens worden gerepliceerd in de primaire regio:

• Geografisch zone-redundante opslag (GZRS): gegevens worden synchroon gerepliceerd in drie Azure-beschikbaarheidszones in de primaire regio met behulp van zone-redundante opslag (ZRS) en vervolgens asynchroon gerepliceerd naar de secundaire regio. Voor leestoegang tot gegevens in de secundaire regio schakelt u geografisch zone-redundante opslag met lees toegang (RA-GZRS) in.

  Microsoft raadt het gebruik van GZRS/RA-GZRS aan voor scenario's waarvoor maximale beschikbaarheid en duurzaamheid is vereist.

• Geografisch redundante opslag (GRS): gegevens worden synchroon drie keer gerepliceerd in de primaire regio met behulp van lokaal redundante opslag (LRS) en vervolgens asynchroon gerepliceerd naar de secundaire regio. Voor leestoegang tot gegevens in de secundaire regio schakelt u geografisch redundante opslag met leestoegang (RA-GRS) in.

In dit artikel wordt beschreven hoe u uw toepassing ontwerpt voor het afhandelen van een storing in de primaire regio. Als de primaire regio niet meer beschikbaar is, kan uw toepassing zich aanpassen om leesbewerkingen uit te voeren op de secundaire regio. Zorg ervoor dat uw opslagaccount is geconfigureerd voor RA-GRS of RA-GZRS voordat u aan de slag gaat.

Overwegingen bij het ontwerpen van toepassingen bij het lezen van de secundaire

Het doel van dit artikel is om u te laten zien hoe u een toepassing ontwerpt die blijft functioneren (zij het in een beperkte capaciteit), zelfs in het geval van een grote ramp in het primaire datacentrum. U kunt uw toepassing ontwerpen voor het afhandelen van tijdelijke of langlopende problemen door te lezen vanuit de secundaire regio wanneer er een probleem is dat het lezen van de primaire regio verstoort. Wanneer de primaire regio weer beschikbaar is, kan uw toepassing terugkeren naar het lezen van de primaire regio.

Houd rekening met deze belangrijke punten bij het ontwerpen van uw toepassing voor RA-GRS of RA-GZRS:

• Azure Storage onderhoudt een alleen-lezen kopie van de gegevens die u in uw primaire regio in een secundaire regio opgeslagen. Zoals hierboven vermeld, bepaalt de opslagservice de locatie van de secundaire regio.

• De alleen-lezen kopie is uiteindelijk consistent met de gegevens in de primaire regio.

• Voor blobs, tabellen en wachtrijen kunt u een query uitvoeren in de secundaire regio voor een waarde voor de laatste synchronisatietijd die u vertelt wanneer de laatste replicatie van de primaire naar de secundaire regio heeft plaatsgevonden. (Dit wordt niet ondersteund voor Azure Files, die op dit moment geen RA-GRS-redundantie heeft.)

• U kunt de Storage gebruiken om gegevens te lezen en te schrijven in de primaire of secundaire regio. U kunt leesaanvragen ook automatisch omleiden naar de secundaire regio als er een times-out is voor een leesaanvraag naar de primaire regio.

• Als de primaire regio niet meer beschikbaar is, kunt u een account-failover initiëren. Wanneer u een fail over naar de secundaire regio gaat, worden de DNS-vermeldingen die naar de primaire regio wijzen, gewijzigd om te wijzen naar de secundaire regio. Nadat de failover is voltooid, wordt schrijftoegang hersteld voor GRS- en RA-GRS-accounts. Zie Herstel na noodherstel en failover van opslagaccount voor meer informatie.

Uiteindelijk consistente gegevens gebruiken

Bij de voorgestelde oplossing wordt ervan uitgenomen dat het acceptabel is om mogelijk verouderde gegevens te retourneren naar de aanroepende toepassing. Omdat gegevens in de secundaire regio uiteindelijk consistent zijn, is het mogelijk dat de primaire regio ontoegankelijk wordt voordat het repliceren van een update naar de secundaire regio is voltooid.

Stel bijvoorbeeld dat uw klant een update indient, maar de primaire regio mislukt voordat de update wordt doorgegeven aan de secundaire regio. Wanneer de klant vraagt om de gegevens terug te lezen, ontvangen ze de verouderde gegevens van de secundaire regio in plaats van de bijgewerkte gegevens. Bij het ontwerpen van uw toepassing moet u beslissen of dit acceptabel is en zo ja, hoe u de klant een bericht stuurt.

Verder in dit artikel laten we zien hoe u de laatste synchronisatietijd voor de secundaire gegevens kunt controleren om te controleren of de secundaire gegevens up-to-date zijn.

Services afzonderlijk of allemaal samen verwerken

Hoewel dit onwaarschijnlijk is, is het mogelijk dat de ene service niet meer beschikbaar is terwijl de andere services nog volledig functioneel zijn. U kunt de nieuwe en alleen-lezenmodus voor elke service afzonderlijk verwerken (blobs, wachtrijen, tabellen), of u kunt nieuwe nieuwe proberen algemeen voor alle opslagservices samen verwerken.

Als u bijvoorbeeld wachtrijen en blobs in uw toepassing gebruikt, kunt u besluiten om afzonderlijke code in te voeren om voor elk van deze fouten nieuwe fouten af te handelen. Als u vervolgens een nieuwe poging krijgt van de blobservice, maar de wachtrijservice nog steeds werkt, wordt alleen het deel van uw toepassing dat blobs verwerkt, beïnvloed. Als u besluit om alle nieuwe opslagservice-aanvragen algemeen af te handelen en een aanroep naar de blobservice een fout retourneert die opnieuw kan worden proberen, worden aanvragen naar zowel de blobservice als de wachtrijservice beïnvloed.

Uiteindelijk is dit afhankelijk van de complexiteit van uw toepassing. U kunt besluiten de fouten niet per service af te handelen, maar in plaats daarvan leesaanvragen voor alle opslagservices om te leiden naar de secundaire regio en de toepassing uit te voeren in de alleen-lezenmodus wanneer u een probleem met een opslagservice in de primaire regio detecteert.

Andere overwegingen

Dit zijn de andere overwegingen die we in de rest van dit artikel bespreken.

• Nieuwe aanvragen voor leesaanvragen verwerken met behulp van het circuit breaker-patroon

• Uiteindelijk consistente gegevens en de laatste synchronisatietijd

• Testen

Uw toepassing uitvoeren in de alleen-lezenmodus

Als u zich effectief wilt voorbereiden op een storing in de primaire regio, moet u zowel mislukte leesaanvragen als mislukte updateaanvragen kunnen verwerken (in dit geval betekent dit dat u moet worden toegevoegd, bijgewerkt en verwijderd). Als de primaire regio uitvalt, kunnen leesaanvragen worden omgeleid naar de secundaire regio. Updateaanvragen kunnen echter niet worden omgeleid naar de secundaire omdat de secundaire alleen-lezen is. Daarom moet u uw toepassing zo ontwerpen dat deze wordt uitgevoerd in de alleen-lezenmodus.

U kunt bijvoorbeeld een vlag instellen die wordt gecontroleerd voordat er updateaanvragen naar de Azure Storage. Wanneer een van de updateaanvragen binnenkomt, kunt u deze overslaan en een passende reactie naar de klant retourneren. Mogelijk wilt u bepaalde functies zelfs helemaal uitschakelen totdat het probleem is opgelost en gebruikers op de hoogte stellen dat deze functies tijdelijk niet beschikbaar zijn.

Als u besluit om fouten voor elke service afzonderlijk af te handelen, moet u ook de mogelijkheid om uw toepassing uit te voeren in de alleen-lezenmodus per service afhandelen. U kunt bijvoorbeeld alleen-lezenvlaggen hebben voor elke service die kan worden ingeschakeld en uitgeschakeld. Vervolgens kunt u de vlag op de juiste plaatsen in uw code verwerken.

De mogelijkheid om uw toepassing uit te voeren in de alleen-lezenmodus heeft een ander voordeel: het biedt u de mogelijkheid om beperkte functionaliteit te garanderen tijdens een grote upgrade van de toepassing. U kunt ervoor zorgen dat uw toepassing wordt uitgevoerd in de alleen-lezenmodus en naar het secundaire datacenter wijzen, zodat niemand toegang heeft tot de gegevens in de primaire regio tijdens het uitvoeren van upgrades.

Updates verwerken bij het uitvoeren in de alleen-lezenmodus

Er zijn veel manieren om updateaanvragen te verwerken wanneer deze worden uitgevoerd in de modus alleen-lezen. We gaan hier niet uitgebreid op in, maar over het algemeen zijn er een aantal patronen die u overweegt.

• U kunt reageren op uw gebruiker en hen vertellen dat u momenteel geen updates accepteert. Een beheersysteem voor contactpersonen kan klanten bijvoorbeeld in staat stellen om toegang te krijgen tot contactgegevens, maar geen updates door te voeren.

• U kunt uw updates in een andere regio in dequeet laten. In dit geval schrijft u uw in behandeling zijnde updateaanvragen naar een wachtrij in een andere regio en hebt u vervolgens een manier om deze aanvragen te verwerken nadat het primaire datacenter weer online is. In dit scenario moet u de klant laten weten dat de aangevraagde update in de wachtrij staat voor latere verwerking.

• U kunt uw updates schrijven naar een opslagaccount in een andere regio. Wanneer het primaire datacenter weer online komt, kunt u deze updates samenvoegen in de primaire gegevens, afhankelijk van de structuur van de gegevens. Als u bijvoorbeeld afzonderlijke bestanden maakt met een datum-/tijdstempel in de naam, kunt u deze bestanden terug kopiëren naar de primaire regio. Dit werkt voor sommige workloads, zoals logboekregistratie en iOT-gegevens.

Nieuwe handelingen verwerken

De Azure Storage-clientbibliotheek helpt u te bepalen welke fouten opnieuw kunnen worden proberen. Een 404-fout (resource niet gevonden) wordt bijvoorbeeld niet opnieuw proberen, omdat het opnieuw proberen waarschijnlijk niet tot een succes zal leiden. Aan de andere kant kan een 500-fout opnieuw worden uitgevoerd omdat het een serverfout is en het probleem gewoon een tijdelijk probleem kan zijn. Bekijk voor meer informatie de open source code voor de klasse ExponentialRetry in de .NET-opslagclientbibliotheek. (Zoek naar de methode ShouldRetry.)

Aanvragen lezen

Leesaanvragen kunnen worden omgeleid naar secundaire opslag als er een probleem is met de primaire opslag. Zoals hierboven vermeld in Uiteindelijk consistente gegevens gebruiken,moet het acceptabel zijn voor uw toepassing om mogelijk verouderde gegevens te lezen. Als u de opslagclientbibliotheek gebruikt voor toegang tot gegevens van de secundaire locatie, kunt u het gedrag voor opnieuw proberen van een leesaanvraag opgeven door een waarde voor de eigenschap LocationMode in te stellen op een van de volgende opties:

• PrimaryOnly (de standaardinstelling)

• PrimaryThenSecondary

• SecondaryOnly

• SecondaryThenPrimary

Wanneer u LocationMode instelt op PrimaryThenSecondary, als de eerste leesaanvraag naar het primaire eindpunt mislukt met een fout die opnieuw kan worden ingediend, doet de client automatisch nog een leesaanvraag naar het secundaire eindpunt. Als de fout een time-out voor de server is, moet de client wachten tot de time-out is verlopen voordat er een foutmelding van de service wordt weergegeven die opnieuw kan worden uitgevoerd.

Er zijn in principe twee scenario's die u moet overwegen wanneer u besluit te reageren op een fout die opnieuw kan worden proberen:

• Dit is een geïsoleerd probleem en volgende aanvragen naar het primaire eindpunt retourneren geen fout die opnieuw kan worden proberen. Een voorbeeld van waar dit kan gebeuren, is wanneer er een tijdelijke netwerkfout is.

  In dit scenario is er geen aanzienlijke prestatiestraf als LocationMode is ingesteld op PrimaryThenSecondary, omdat dit slechts zelden gebeurt.

• Dit is een probleem met ten minste één van de opslagservices in de primaire regio en alle volgende aanvragen naar die service in de primaire regio retourneren waarschijnlijk nieuwe fouten voor een bepaalde periode. Een voorbeeld hiervan is als de primaire regio volledig niet toegankelijk is.

  In dit scenario is er sprake van een prestatiestraf omdat al uw leesaanvragen eerst het primaire eindpunt proberen, wachten tot de time-out is verlopen en vervolgens overschakelen naar het secundaire eindpunt.

Voor deze scenario's moet u vaststellen dat er een lopend probleem is met het primaire eindpunt en alle leesaanvragen rechtstreeks naar het secundaire eindpunt verzenden door de eigenschap LocationMode in te stellen op SecondaryOnly. Op dit moment moet u ook de toepassing zo wijzigen dat deze wordt uitgevoerd in de modus alleen-lezen. Deze methode wordt het circuit breaker-patroon genoemd.

Aanvragen bijwerken

Het circuit breaker patroon kan ook worden toegepast op aanvragen bijwerken. Updateaanvragen kunnen echter niet worden omgeleid naar secundaire opslag, die alleen-lezen is. Laat voor deze aanvragen de eigenschap LocationMode ingesteld op PrimaryOnly (de standaardinstelling). Als u deze fouten wilt afhandelen, kunt u een metrische gegevens toepassen op deze aanvragen, zoals 10 fouten op een rij. Wanneer aan uw drempelwaarde wordt voldaan, schakelt u de toepassing over naar de modus alleen-lezen. U kunt dezelfde methoden gebruiken om terug te keren naar de updatemodus als de methoden die hieronder worden beschreven in de volgende sectie over het circuitonderbrekerpatroon.

Patroon Circuitonderbreker

Het gebruik van het circuit breaker-patroon in uw toepassing kan voorkomen dat deze een bewerking opnieuw onderbreekt die waarschijnlijk herhaaldelijk mislukt. Hierdoor kan de toepassing blijven worden uitgevoerd in plaats van tijd in te nemen terwijl de bewerking exponentieel opnieuw wordt uitgevoerd. Ook wordt gedetecteerd wanneer de fout is verholpen. Op dat moment kan de toepassing de bewerking opnieuw proberen.

Het circuit breaker-patroon implementeren

Als u wilt vaststellen dat er een doorlopend probleem is met een primair eindpunt, kunt u controleren hoe vaak de client nieuwe fouten tegenkomt. Omdat elk geval anders is, moet u beslissen over de drempelwaarde die u wilt gebruiken voor de beslissing om over te schakelen naar het secundaire eindpunt en de toepassing uit te voeren in de modus alleen-lezen. U kunt bijvoorbeeld besluiten om de switch uit te voeren als er 10 fouten in een rij zijn zonder succes. Een ander voorbeeld is om over te schakelen als 90% van de aanvragen in een periode van 2 minuten mislukt.

Voor het eerste scenario kunt u gewoon het aantal fouten houden. Als er een succes is voordat het maximum wordt bereikt, stelt u het aantal weer in op nul. Voor het tweede scenario kunt u dit implementeren door het MemoryCache-object (in .NET) te gebruiken. Voeg voor elke aanvraag een CacheItem toe aan de cache, stel de waarde in op geslaagd (1) of mislukken (0) en stel de verlooptijd in op 2 minuten vanaf nu (of wat uw tijdsbeperking ook is). Wanneer de vervaltijd van een vermelding is bereikt, wordt de vermelding automatisch verwijderd. Hiermee krijgt u een doorrollend venster van 2 minuten. Telkens wanneer u een aanvraag bij de opslagservice maakt, gebruikt u eerst een Linq-query in het MemoryCache-object om het succes percentage te berekenen door de waarden op te tellen en te delen door het aantal. Wanneer het percentage geslaagd onder een bepaalde drempelwaarde (zoals 10%) zakt, stelt u de eigenschap LocationMode voor leesaanvragen in op SecondaryOnly en zet u de toepassing over naar de modus alleen-lezen voordat u doorgaat.

De drempelwaarde voor fouten die worden gebruikt om te bepalen wanneer de switch moet worden gemaakt, kan per service in uw toepassing verschillen, dus u moet overwegen om deze configureerbare parameters te maken. Dit is ook waar u besluit om nieuwe fouten van elke service afzonderlijk of als één te verwerken, zoals eerder is besproken.

Een andere overweging is hoe u meerdere exemplaren van een toepassing verwerkt en wat u moet doen wanneer u in elk exemplaar nieuwe fouten detecteert. U kunt bijvoorbeeld 20 VM's uitvoeren met dezelfde toepassing geladen. Verwerkt u elk exemplaar afzonderlijk? Als één exemplaar problemen gaat krijgen, wilt u dan de reactie beperken tot slechts die ene instantie, of wilt u alle exemplaren op dezelfde manier laten reageren wanneer één exemplaar een probleem heeft? Het afzonderlijk verwerken van de exemplaren is veel eenvoudiger dan het coördineren van de reactie tussen de exemplaren, maar hoe u dit doet, is afhankelijk van de architectuur van uw toepassing.

Opties voor het bewaken van de foutfrequentie

U hebt drie hoofdopties voor het bewaken van de frequentie van nieuwe nieuwe aanvragen in de primaire regio om te bepalen wanneer u moet overschakelen naar de secundaire regio en de toepassing moet wijzigen zodat deze wordt uitgevoerd in de modus alleen-lezen.

• Voeg een handler toe voor de gebeurtenis Opnieuw proberen in het OperationContext-object dat u door geeft aan uw opslagaanvragen. Dit is de methode die in dit artikel wordt weergegeven en die wordt gebruikt in het bijbehorende voorbeeld. Deze gebeurtenissen worden steeds wanneer de client een aanvraag opnieuw onderneemt, zodat u kunt bijhouden hoe vaak de client nieuwe fouten tegenkomt op een primair eindpunt.

  • .NET v12 SDK
  • .NET v11 SDK

  We werken momenteel aan het maken van codefragmenten die versie 12.x van de Azure Storage clientbibliotheken weerspiegelen. Zie Announcing the Azure Storage v12 Client Libraries (Aankondiging van de Azure Storage v12-clientbibliotheken) voor meer informatie.

• In de methode Evaluate in een aangepast beleid voor opnieuw proberen kunt u aangepaste code uitvoeren wanneer een nieuwe poging wordt uitgevoerd. Naast het vastleggen wanneer een nieuwe poging zich voor doet, biedt dit u ook de mogelijkheid om uw gedrag voor opnieuw proberen te wijzigen.

  • .NET v12 SDK
  • .NET v11 SDK

  We werken momenteel aan het maken van codefragmenten die versie 12.x van de Azure Storage clientbibliotheken weerspiegelen. Zie Announcing the Azure Storage v12 Client Libraries (Aankondiging van de Azure Storage v12-clientbibliotheken) voor meer informatie.

• De derde aanpak is het implementeren van een aangepast bewakingsonderdeel in uw toepassing dat voortdurend uw primaire opslag-eindpunt pingt met dummy-leesaanvragen (zoals het lezen van een kleine blob) om de status ervan te bepalen. Dit zou een aantal resources kosten, maar niet een aanzienlijk bedrag. Wanneer er een probleem wordt ontdekt dat uw drempel bereikt, voert u vervolgens de overgang naar de modus SecondaryOnly en de modus Alleen-lezen uit.

Op een bepaald moment wilt u weer overschakelen naar het primaire eindpunt en updates toestaan. Als u een van de eerste twee hierboven vermelde methoden gebruikt, kunt u gewoon teruggaan naar het primaire eindpunt en de updatemodus inschakelen nadat een willekeurig geselecteerde hoeveelheid tijd of het aantal bewerkingen is uitgevoerd. Vervolgens kunt u de logica voor opnieuw proberen opnieuw laten lopen. Als het probleem is opgelost, blijft het primaire eindpunt gebruiken en updates toestaan. Als er nog steeds een probleem is, wordt er opnieuw overschakelt naar het secundaire eindpunt en de modus alleen-lezen na het mislukken van de criteria die u hebt ingesteld.

Voor het derde scenario, wanneer het pingen van het primaire opslag-eindpunt weer lukt, kunt u de switch terug naar PrimaryOnly activeren en doorgaan met het toestaan van updates.

Uiteindelijk consistente gegevens verwerken

Geografisch redundante opslag werkt door transacties van de primaire naar de secundaire regio te repliceren. Dit replicatieproces garandeert dat de gegevens in de secundaire regio uiteindelijk consistent zijn. Dit betekent dat alle transacties in de primaire regio uiteindelijk worden weergegeven in de secundaire regio, maar dat er mogelijk vertraging is voordat ze worden weergegeven en dat er geen garantie is dat de transacties in de secundaire regio binnenkomen in dezelfde volgorde als waarin ze oorspronkelijk zijn toegepast in de primaire regio. Als uw transacties niet in de volgorde van de secundaire regio binnenkomen, kunt u uw gegevens in de secundaire regio als inconsistent beschouwen totdat de service een inlek neemt.

In de volgende tabel ziet u een voorbeeld van wat er kan gebeuren wanneer u de details van een werknemer bijwerkt om hen lid te maken van de rol administrators. In dit voorbeeld moet u hiervoor de entiteit Werknemer bijwerken en een entiteit met beheerdersrol bijwerken met een telling van het totale aantal beheerders. U ziet hoe de updates niet op volgorde worden toegepast in de secundaire regio.

In dit voorbeeld wordt ervan uitgenomen dat de client overschakelt naar lezen vanuit de secundaire regio op T5. De entiteit administratorrol kan op dit moment worden gelezen, maar de entiteit bevat een waarde voor het aantal beheerders dat op dit moment niet consistent is met het aantal werknemersentiteiten dat is gemarkeerd als administrators in de secundaire regio. Uw client kan deze waarde gewoon weergeven, met het risico dat het inconsistente informatie is. De client kan ook proberen te bepalen of de beheerdersrol mogelijk inconsistent is omdat de updates niet in de juiste volgorde zijn uitgevoerd en de gebruiker vervolgens op de hoogte stellen van dit feit.

Om te herkennen dat deze mogelijk inconsistente gegevens bevatten, kan de client de waarde van de laatste synchronisatietijd gebruiken die u op elk moment kunt krijgen door een query uit te voeren op een opslagservice. Dit geeft aan wanneer de gegevens in de secundaire regio voor het laatst consistent waren en wanneer de service alle transacties vóór dat moment had toegepast. In het bovenstaande voorbeeld wordt, nadat de service de entiteit Werknemer in de secundaire regio invoegt, de laatste synchronisatietijd ingesteld op T1. Deze blijft op T1 totdat de service de entiteit Werknemer in de secundaire regio bijwerkt wanneer deze is ingesteld op T6. Als de client de laatste synchronisatietijd op haalt wanneer deze de entiteit op T5 leest, kan deze de entiteit vergelijken met de tijdstempel van de entiteit. Als de tijdstempel van de entiteit later is dan de laatste synchronisatietijd, heeft de entiteit een mogelijk inconsistente status en kunt u de juiste actie ondernemen voor uw toepassing. Als u dit veld gebruikt, moet u weten wanneer de laatste update naar de primaire is voltooid.

Zie De eigenschap Laatste synchronisatietijd controleren voor een opslagaccount voor meer informatie over het controleren van de laatste synchronisatietijd.

Testen

Het is belangrijk om te testen of uw toepassing zich gedraagt zoals verwacht wanneer er nieuwe fouten optreden. U moet bijvoorbeeld testen of de toepassing overschakelt naar de secundaire en naar de alleen-lezenmodus wanneer er een probleem wordt gedetecteerd en terugschakelt wanneer de primaire regio weer beschikbaar wordt. Hiervoor hebt u een manier nodig om nieuwe fouten te simuleren en te bepalen hoe vaak ze optreden.

U kunt Fiddler gebruiken om HTTP-antwoorden in een script te onderscheppen en te wijzigen. Met dit script kunt u antwoorden identificeren die afkomstig zijn van uw primaire eindpunt en de HTTP-statuscode wijzigen in een code die door de Storage-clientbibliotheek wordt herkend als een fout die opnieuw kan worden proberen. Dit codefragment toont een eenvoudig voorbeeld van een Fiddler-script dat reacties op leesaanvragen onderschept op basis van de tabel employeedata om de status 502 te retourneren:

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

Volgende stappen

Zie Azure Samples – Using the Circuit Breaker Pattern with RA-GRS storage (Azure-voorbeelden: het circuit breakerpatroon gebruiken met RA-GRS-opslag) voor een volledig voorbeeld waarin wordt getoond hoe u heen en weer kunt schakelen tussen de primaire en secundaire eindpunten.