Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen

2025-05-03

Cloudinfrastructuren zoals Azure Storage bieden een maximaal beschikbaar en duurzaam platform voor het hosten van gegevens en toepassingen. Ontwikkelaars van cloudtoepassingen moeten zorgvuldig nadenken over het gebruik van dit platform om deze voordelen voor hun gebruikers te maximaliseren. Azure Storage biedt opties voor georedundantie om hoge beschikbaarheid te garanderen, zelfs tijdens een regionale storing. Opslagaccounts die zijn geconfigureerd voor geografisch redundante replicatie, worden synchroon gerepliceerd in de primaire regio en asynchroon gerepliceerd naar een secundaire regio die honderden kilometers verderop ligt.

Azure Storage biedt twee opties voor geografisch redundante replicatie: Geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS). Als u de geografisch redundantieopties van Azure Storage wilt gebruiken, moet u ervoor zorgen dat uw opslagaccount is geconfigureerd voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). Als dat niet het probleem is, kunt u meer informatie vinden over het wijzigen van het replicatietype van uw opslagaccount.

In dit artikel wordt beschreven hoe u een toepassing ontwerpt die blijft functioneren, zij het in een beperkte capaciteit, zelfs als er een aanzienlijke storing is in de primaire regio. Als de primaire regio niet beschikbaar is, kan uw toepassing naadloos overschakelen om leesbewerkingen uit te voeren op de secundaire regio totdat de primaire regio weer reageert.

Overwegingen voor applicatieontwerp

U kunt uw toepassing ontwerpen voor het afhandelen van tijdelijke fouten of aanzienlijke storingen door te lezen vanuit de secundaire regio wanneer er een probleem is dat het lezen van de primaire regio beïnvloedt. Wanneer de primaire regio weer beschikbaar is, kan uw toepassing terugkeren naar lezen vanuit de primaire regio.

Houd rekening met deze belangrijke overwegingen bij het ontwerpen van uw toepassing voor beschikbaarheid en tolerantie met behulp van RA-GRS of RA-GZRS:

Een alleen-lees kopie van uw opgeslagen gegevens in de primaire regio wordt asynchroon gerepliceerd naar een secundaire regio. Deze asynchrone replicatie betekent dat de alleen-lezen kopie in de secundaire regio uiteindelijk consistent is met de gegevens in de primaire regio. De opslagservice bepaalt de locatie van de secundaire regio.
U kunt de Azure Storage-clientbibliotheken gebruiken om lees- en updateaanvragen uit te voeren op het eindpunt van de primaire regio. Als de primaire regio niet beschikbaar is, kunt u leesaanvragen automatisch omleiden naar de secundaire regio. U kunt uw app ook zo configureren dat leesaanvragen rechtstreeks naar de secundaire regio worden verzonden, zelfs wanneer de primaire regio beschikbaar is.
Als de primaire regio niet meer beschikbaar is, kunt u een failover van een account initiëren. Wanneer u een failover naar de secundaire regio uitvoert, worden de DNS-vermeldingen die naar de primaire regio verwijzen, gewijzigd zodat deze verwijzen naar de secundaire regio. Nadat de failover is voltooid, wordt schrijftoegang hersteld voor GRS- en RA-GRS-accounts. Zie Herstel na noodgevallen en failover van opslagaccounts voor meer informatie.

Werken met uiteindelijk consistente gegevens

In de voorgestelde oplossing wordt ervan uitgegaan 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 een update naar de secundaire regio is gerepliceerd.

Stel dat uw klant een update heeft ingediend, maar dat 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 uit de secundaire regio in plaats van de bijgewerkte gegevens. Bij het ontwerpen van uw toepassing moet u beslissen of dit gedrag acceptabel is. Als dat zo is, moet u ook overwegen hoe u de gebruiker op de hoogte brengt.

Verderop in dit artikel leert u meer over het verwerken van uiteindelijk consistente gegevens en het controleren van de eigenschap Last Sync Time om verschillen tussen gegevens in de primaire en secundaire regio's te evalueren.

Services afzonderlijk of allemaal afhandelen

Hoewel het onwaarschijnlijk is dat één service (blobs, wachtrijen, tabellen of bestanden) niet beschikbaar is terwijl de andere services nog steeds volledig functioneel zijn. U kunt de herhalingen voor elke service afzonderlijk afhandelen, of u kunt de herhalingen generiek verwerken voor alle opslagservices samen.

Als u bijvoorbeeld wachtrijen en blobs in uw toepassing gebruikt, kunt u besluiten om afzonderlijke code in te voeren voor het afhandelen van fouten die opnieuw kunnen worden geprobeerd voor elke service. Op die manier heeft een blobservicefout alleen invloed op het deel van uw toepassing dat blobs behandelt, zodat wachtrijen gewoon blijven werken. Als u echter besluit om alle nieuwe pogingen voor opslagsdiensten gezamenlijk te beheren, worden verzoeken voor zowel blob-services als wachtrijservices beïnvloed als een van beide diensten een fout retourneert die voor een nieuwe poging in aanmerking komt.

Uiteindelijk is deze beslissing afhankelijk van de complexiteit van uw toepassing. U kunt ervoor kiezen om fouten per dienst te verwerken om de impact van herhalingspogingen te beperken. Ofwel kunt u besluiten om leesaanvragen voor alle opslagservices om te leiden naar de secundaire regio wanneer u een probleem met een opslagservice in de primaire regio detecteert.

Uw toepassing uitvoeren in de modus Alleen-lezen

Als u zich effectief wilt voorbereiden op een storing in de primaire regio, moet uw toepassing zowel mislukte leesaanvragen als mislukte updateaanvragen kunnen verwerken. Als de primaire regio mislukt, kunnen leesaanvragen worden omgeleid naar de secundaire regio. Updateaanvragen kunnen echter niet worden omgeleid omdat de gerepliceerde gegevens in de secundaire regio alleen-lezen zijn. Daarom moet u uw toepassing ontwerpen om in de modus Alleen-lezen te kunnen worden uitgevoerd.

U kunt bijvoorbeeld een vlag instellen die wordt gecontroleerd voordat er updateaanvragen naar Azure Storage worden verzonden. Wanneer een updateaanvraag binnenkomt, kunt u de aanvraag overslaan en een geschikt antwoord retourneren aan de gebruiker. U kunt er zelfs voor kiezen om bepaalde functies helemaal uit te schakelen totdat het probleem is opgelost en gebruikers op de hoogte te stellen dat de functies tijdelijk niet beschikbaar zijn.

Als u besluit om fouten voor elke service afzonderlijk af te handelen, moet u ook de mogelijkheid afhandelen om uw toepassing in de modus Alleen-lezen per service uit te voeren. U kunt bijvoorbeeld alleen-lezen markeringen instellen voor elke dienst. Vervolgens kunt u de vlaggen in de code in- of uitschakelen, indien nodig.

Als u uw toepassing in de modus Alleen-lezen kunt uitvoeren, hebt u ook de mogelijkheid om beperkte functionaliteit te garanderen tijdens een grote upgrade van de toepassing. U kunt uw toepassing activeren om uit te voeren in de modus Alleen-lezen en naar het secundaire datacenter te verwijzen, zodat niemand toegang heeft tot de gegevens in de primaire regio terwijl u upgrades uitvoert.

Updates verwerken tijdens het draaien in de modus Alleen-lezen

Er zijn veel manieren om bijwerkaanvragen af te handelen wanneer deze worden uitgevoerd in de modus Alleen-lezen. Deze sectie is gericht op een aantal algemene patronen die u kunt overwegen.

U kunt reageren op de gebruiker en hen laten weten dat er momenteel geen updateaanvragen worden verwerkt. Met een beheersysteem voor contactpersonen kunnen gebruikers bijvoorbeeld toegang krijgen tot contactgegevens, maar geen updates aanbrengen.
U kunt uw updates in een andere regio in de wachtrij zetten. In dit geval schrijft u uw in behandeling zijnde updateaanvragen naar een wachtrij in een andere regio en verwerkt u deze aanvragen nadat het primaire datacenter weer online is. In dit scenario moet u de gebruiker laten weten dat de updateaanvraag in de wachtrij wordt geplaatst voor latere verwerking.
U kunt uw updates schrijven naar een opslagaccount in een andere regio. Wanneer de primaire regio 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. Deze oplossing kan van toepassing zijn op workloads zoals logboekregistratie en IoT-gegevens.

Omgaan met herhalingen

Toepassingen die communiceren met services die in de cloud worden uitgevoerd, moeten gevoelig zijn voor niet-geplande gebeurtenissen en fouten die kunnen optreden. Deze fouten kunnen tijdelijk of permanent zijn, variërend van een tijdelijk verlies van connectiviteit tot een aanzienlijke storing vanwege een natuurramp. Het is belangrijk om cloudtoepassingen te ontwerpen met de juiste verwerking van nieuwe pogingen om de beschikbaarheid te maximaliseren en de algehele stabiliteit van toepassingen te verbeteren.

Leesaanvragen

Als de primaire regio niet beschikbaar is, kunnen leesaanvragen worden omgeleid naar secundaire opslag. Zoals eerder vermeld, moet het acceptabel zijn voor uw toepassing om verouderde gegevens mogelijk te lezen. De Azure Storage-clientbibliotheek biedt opties voor het verwerken van nieuwe pogingen en het omleiden van leesaanvragen naar een secundaire regio.

In dit voorbeeld wordt de verwerking van nieuwe pogingen voor Blob Storage geconfigureerd in de BlobClientOptions klasse en wordt deze toegepast op het BlobServiceClient object dat we maken met behulp van deze configuratieopties. Deze configuratie is een primaire en secundaire benadering, waarbij nieuwe pogingen van leesaanvragen vanuit de primaire regio worden omgeleid naar de secundaire regio. Deze aanpak is het beste wanneer fouten in de primaire regio naar verwachting tijdelijk zijn.

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

Als u vaststelt dat de primaire regio waarschijnlijk lange tijd niet beschikbaar is, kunt u alle leesaanvragen zo configureren dat deze verwijzen naar de secundaire regio. Deze configuratie is een alleen secundaire benadering. Zoals eerder is besproken, hebt u een strategie nodig voor het afhandelen van updateaanvragen gedurende deze tijd en een manier om gebruikers te informeren dat alleen leesaanvragen worden verwerkt. In dit voorbeeld maken we een nieuw exemplaar BlobServiceClient waarvan het eindpunt van de secundaire regio wordt gebruikt.

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

Weten wanneer u moet overschakelen naar de modus Alleen-lezen en secundaire aanvragen maakt deel uit van een architectuurontwerppatroon, het circuitonderbrekerpatroon genoemd, dat in een latere sectie wordt besproken.

Aanvragen bijwerken

Updateaanvragen kunnen niet worden omgeleid naar secundaire opslag, die alleen-lezen is. Zoals eerder beschreven, moet uw toepassing updateaanvragen kunnen verwerken wanneer de primaire regio niet beschikbaar is.

Het circuitonderbrekerpatroon kan ook worden toegepast op updateaanvragen. Als u bijwerkaanvraagfouten wilt afhandelen, kunt u een drempelwaarde instellen in de code, zoals 10 opeenvolgende fouten, en het aantal fouten voor aanvragen naar de primaire regio bijhouden. Zodra aan de drempelwaarde is voldaan, kunt u de toepassing overschakelen naar de modus Alleen-lezen, zodat er geen updateaanvragen meer worden uitgegeven naar de primaire regio.

Hoe implementeer je het circuitonderbrekerpatroon

Het verwerken van fouten die een variabele tijd in beslag nemen om van te herstellen, maakt deel uit van een architectuurontwerppatroon dat het circuitonderbrekerpatroon wordt genoemd. De juiste implementatie van dit patroon kan voorkomen dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt, waardoor de stabiliteit en tolerantie van toepassingen worden verbeterd.

Een aspect van het circuit breaker-patroon is het identificeren van wanneer er een doorlopend probleem is met een primair eindpunt. Om deze beslissing te nemen, kunt u controleren hoe vaak de client fouten ondervindt die opnieuw kunnen worden geprobeerd. Omdat elk scenario verschillend is, moet u een geschikte drempelwaarde bepalen die moet worden gebruikt voor de beslissing om over te schakelen naar het secundaire eindpunt en de toepassing uitvoeren in de modus Alleen-lezen.

U kunt bijvoorbeeld besluiten om te schakelen bij 10 opeenvolgende fouten in de primaire regio. U kunt dit bijhouden door het aantal fouten in de code bij te houden. Als er een succes is voordat de drempelwaarde wordt bereikt, stelt u het aantal terug op nul. Als het aantal de drempelwaarde bereikt, schakelt u de toepassing over naar het gebruik van de secundaire regio voor leesaanvragen.

Als alternatief kunt u besluiten om een aangepast bewakingsonderdeel in uw toepassing te implementeren. Dit onderdeel kan uw primaire opslageindpunt continu pingen met triviale leesaanvragen (zoals het lezen van een kleine blob) om de status ervan te bepalen. Deze benadering neemt een aantal resources in beslag, maar niet een aanzienlijk bedrag. Wanneer er een probleem wordt gedetecteerd dat uw drempelwaarde bereikt, schakelt u over naar alleen secundaire leesaanvragen en de alleen-lezenmodus. Voor dit scenario kunt u bij het pingen van het primaire opslageindpunt weer terugkeren naar de primaire regio en doorgaan met het toestaan van updates.

De foutdrempel die wordt gebruikt om te bepalen wanneer de switch moet worden gemaakt, kan variëren van service naar service binnen uw toepassing. Overweeg daarom om deze configureerbare parameters te maken.

Een andere overweging is het afhandelen van meerdere exemplaren van een toepassing en wat u moet doen wanneer u fouten detecteert die opnieuw kunnen worden geprobeerd in elk exemplaar. U kunt bijvoorbeeld 20 VM's hebben die worden uitgevoerd terwijl dezelfde toepassing is geladen. Verwerkt u elk exemplaar afzonderlijk? Als één exemplaar problemen ondervindt, wilt u het antwoord beperken tot slechts die ene instantie? Of wilt u dat alle exemplaren op dezelfde manier reageren wanneer één exemplaar een probleem heeft? Het afzonderlijk verwerken van de exemplaren is veel eenvoudiger dan het coördineren van het antwoord in de verschillende exemplaren, maar uw benadering is afhankelijk van de architectuur van uw toepassing.

Uiteindelijk consistente gegevens verwerken

Geografisch redundante opslag werkt door transacties van de primaire naar de secundaire regio te repliceren. Het 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 een vertraging is voordat ze worden weergegeven. Er is ook geen garantie dat transacties in de secundaire regio in dezelfde volgorde worden uitgevoerd als ze oorspronkelijk zijn toegepast in de primaire regio. Als uw transacties in de secundaire regio in de verkeerde volgorde aankomen, kunt u overwegen dat uw gegevens in de secundaire regio in een inconsistente status verkeren totdat de service is bijgewerkt.

In het volgende voorbeeld voor Azure Table Storage ziet u wat er kan gebeuren wanneer u de details van een werknemer bijwerkt om deze lid te maken van de beheerdersrol. In dit voorbeeld moet u de entiteit werknemer bijwerken en een beheerdersrolentiteit bijwerken met een telling van het totale aantal beheerders. Let op hoe de updates in de secundaire regio in een andere volgorde worden toegepast.

Tijd	Transactie	Replicatie	Laatste synchronisatietijd	resultaat
T0	Transactie A: Werknemer invoegen entiteit in primaire			Transactie A ingevoegd naar primair systeem. nog niet gerepliceerd.
T1		Transactie A gerepliceerd naar tweede	T1	Transactie A gerepliceerd naar secundaire locatie. Laatste synchronisatietijd bijgewerkt.
T2	Transactie B: bijwerken werknemerentiteit in primaire		T1	Transactie B geschreven naar primair systeem. nog niet gerepliceerd.
T3	Transactie C: Bijwerken administrateur rolentiteit in primair		T1	Transactie C geschreven naar primaire, nog niet gerepliceerd.
T4		Transactie C gerepliceerd naar tweede	T1	Transactie C gerepliceerd op de secundaire locatie. LastSyncTime niet bijgewerkt omdat transactie B is nog niet gerepliceerd.
T5	Entiteiten lezen vanaf middelbaar		T1	U krijgt de verouderde waarde voor werknemer entiteit omdat transactie B nog niet is gedaan nog niet gerepliceerd. U krijgt de nieuwe waarde voor entiteit met beheerdersrol omdat C Gerepliceerd. Laatste synchronisatietijd is nog steeds niet bijgewerkt. Het is bijgewerkt vanwege transactie B. is niet gerepliceerd. U kunt het volgende vertellen: entiteit met beheerdersrol is inconsistent omdat de entiteitsdatum/-tijd later is de laatste synchronisatietijd.
T6		Transactie B gerepliceerd naar tweede	T6	T6 – Alle transacties via C hebben gerepliceerd, laatste synchronisatietijd wordt bijgewerkt.

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

Om te bepalen of een opslagaccount mogelijk inconsistente gegevens bevat, kan de client de waarde van de eigenschap Laatste synchronisatietijd controleren. De laatste synchronisatietijd geeft aan wanneer de gegevens in de secundaire regio voor het laatst consistent waren en wanneer de service alle transacties vóór dat tijdstip had toegepast. In het bovenstaande voorbeeld wordt de laatste synchronisatietijd ingesteld op T1 nadat de service de werknemersentiteit in de secundaire regio heeft ingevoegd. Het blijft op T1 totdat de service de werknemersentiteit in de secundaire regio bijwerkt wanneer deze is ingesteld op T6. Als de client de laatste synchronisatietijd ophaalt wanneer de entiteit op T5 wordt gelezen, kan deze worden vergeleken met de tijdstempel van de entiteit. Als de tijdstempel op de entiteit later is dan de laatste synchronisatietijd, heeft de entiteit een mogelijk inconsistente status en kunt u de juiste actie ondernemen. Als u dit veld gebruikt, moet u weten wanneer de laatste update naar de primaire server is voltooid.

Zie De eigenschap Laatste synchronisatietijd voor een opslagaccount controleren 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 fouten optreden die opnieuw kunnen worden geprobeerd. U moet bijvoorbeeld testen of de toepassing overschakelt naar de secundaire regio wanneer er een probleem wordt gedetecteerd en vervolgens wordt teruggeschakeld wanneer de primaire regio weer beschikbaar is. Als u dit gedrag correct wilt testen, hebt u een manier nodig om fouten te simuleren die opnieuw kunnen worden geprobeerd en te bepalen hoe vaak ze optreden.

Een optie is fiddler te gebruiken om HTTP-antwoorden in een script te onderscheppen en te wijzigen. Dit script kan antwoorden identificeren die afkomstig zijn van uw primaire eindpunt en de HTTP-statuscode wijzigen in een fout die door de Storage-clientbibliotheek wordt herkend als een fout die opnieuw kan worden geprobeerd. Dit codefragment toont een eenvoudig voorbeeld van een Fiddler-script waarmee reacties op leesaanvragen tegen de tabel employeedata worden onderschept om een 502-status terug te geven.

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

U kunt dit voorbeeld uitbreiden om een breder scala aan aanvragen te onderscheppen en alleen de responseCode op sommige aanvragen te wijzigen om een praktijkscenario beter te simuleren. Zie Een aanvraag of antwoord wijzigen in de Fiddler-documentatie voor meer informatie over het aanpassen van Fiddler-scripts.

Als u configureerbare drempelwaarden hebt ingesteld voor het overschakelen van uw toepassing naar alleen-lezen, is het eenvoudiger om het gedrag te testen met niet-productietransactievolumes.

Volgende stappen

Zie Azure Samples - Using the Circuit Breaker Pattern with RA-GRS storage voor een volledig voorbeeld waarin wordt getoond hoe u kunt schakelen tussen de primaire en secundaire eindpunten.