Betrouwbaarheid in Azure App Configuration

Azure App Configuration slaat configuratie-instellingen en functievlagmen centraal op en beheert deze, waardoor configuratiebestanden die rechtstreeks in toepassingen zijn ingesloten, worden vervangen. Met deze aanpak kunt u dynamische updates, versiebeheer van configuratiewaarden en historisch bijhouden van configuratiewijzigingen in de loop van de tijd. De beschikbaarheid en betrouwbaarheid van App Configuration zijn belangrijke overwegingen, omdat het gedrag van de toepassing direct afhankelijk kan zijn van de toegang tot configuratiegegevens tijdens runtime.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt de betrouwbaarheidsarchitectuur van Azure App Configuration beschreven en wordt uitgelegd hoe de service is ontworpen om beschikbaar te blijven tijdens tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Houd rekening met de volgende aanbevelingen voor de meeste productie-implementaties van App Configuration:

• SKU: Gebruik de Standard- of Premium-SKU.
• Bescherming tegen voorlopig verwijderen en opschonen: Schakel voorlopig verwijderen en opschonen in om bescherming te bieden tegen gegevensverwijdering.
• Voor bedrijfskritieke scenario's: Gebruik de Premium-SKU en configureer de opgenomen replica om replicatie in meerdere regio's mogelijk te maken om hoge beschikbaarheid en tolerantie voor storingen in regio's te verbeteren.

Zie Toepassingen bouwen met hoge tolerantie voor een lijst met aanbevolen procedures en configuratie voor productieworkloads.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u App Configuration implementeert, implementeert u een winkel. Uw winkel bevat verschillende typen instellingen die uw toepassing kan gebruiken, inclusief sleutels en waarden en functievlagmen. De service bevat ook ingebouwde mogelijkheden voor het organiseren, beveiligen, versiebeheer en veilig implementeren van configuratiewijzigingen in omgevingen. Voor meer informatie, zie Wat is Azure App Configuration?

App Configuration is een volledig beheerde service. Microsoft is verantwoordelijk voor het opslaan en beheren van uw instellingen en het uitvoeren van onderhoud op de service.

Wanneer u clienttoepassingen bouwt die verbinding maken met Azure App Configuration, kunt u eventueel App Configuration gebruiken met Azure Front Door (preview) om caching en globale verkeersversnelling in te schakelen. Deze configuratie introduceert andere overwegingen voor geo-replicatie, die waar van toepassing in dit artikel zijn gemarkeerd.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Wanneer u Azure App Configuration gebruikt, moet u rekening houden met de volgende aanbevolen procedures om het effect van tijdelijke fouten bij configuratietoegang te minimaliseren, met name binnen kritieke codepaden.

• Configuratieproviders: Gebruik de App Configuration-configuratieproviders met ingebouwde mogelijkheden voor opnieuw proberen en opslaan in cache, samen met vele andere tolerantiefuncties.
• Azure SDK's: Gebruik App Configuration SDK's als uw toepassing schrijfaanvragen moet verzenden. SDKs proberen automatisch opnieuw bij HTTP-statuscode 429-antwoorden en andere tijdelijke fouten.
• Logica voor opnieuw proberen: Neem logica voor opnieuw proberen op in aangepaste clients als u geen app-configuratieproviders of SDK's kunt gebruiken. De retry-after-ms header in het antwoord biedt een voorgestelde wachttijd in milliseconden voordat u de aanvraag opnieuw probeert.
• Caching: Cache-instellingen in het geheugen indien mogelijk om directe aanvragen naar uw winkel te verminderen.

Zie de veelgestelde vragen over Azure App Configuration voor andere richtlijnen voor toepassingsconfiguratie.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

App Configuration biedt automatisch zoneredundantie in regio's die beschikbaarheidszones ondersteunen. Deze redundantie biedt hoge beschikbaarheid binnen een regio zonder dat hiervoor een specifieke configuratie is vereist.

Wanneer een beschikbaarheidszone niet beschikbaar is, stuurt App Configuration uw aanvragen automatisch om naar andere gezonde beschikbaarheidszones om hoge beschikbaarheid te garanderen.

Requirements

Ondersteuning voor regio's: Winkels die in de volgende regio's zijn geïmplementeerd, zijn automatisch zone-redundant:

Americas	Europa	Midden-Oosten	Afrika	Azië en Stille Oceaan
Brazilië Zuid	Centraal Frankrijk	Israël Centraal		Australia East
Canada Central	West-Centraal Duitsland	Qatar Central		Centraal-India
Central US	Italy North	VAE Noord		China - noord 3
East US	Europa - noord			Oost-Azië
Oostelijke Verenigde Staten 2	Norway East			Oost-Japan
Mexico Central	Centraal Polen			Korea Central
Zuid-Centraal Verenigde Staten	Spain Central			Zuidoost-Azië
VS overheid Virginia	Zweden - centraal
Westelijke Verenigde Staten 2	Switzerland North
Westelijke VS 3	UK South
	West Europe

Kosten

Er zijn geen extra kosten verbonden aan zoneredundantie voor Azure App Configuration.

Ondersteuning voor beschikbaarheidszones configureren

Microsoft schakelt automatisch zoneredundantie in voor een winkel wanneer deze zich in een regio bevindt die beschikbaarheidszones ondersteunt.

Als App Configuration ondersteuning voor beschikbaarheidszones toevoegt aan een bestaande regio, hoeft u niets te doen om te profiteren van de ondersteuning voor de beschikbaarheidszone. Uw winkel profiteert van de ondersteuning voor de beschikbaarheidszone die beschikbaar is geworden voor App Configuration-winkels in de regio.

Gedrag wanneer alle zones in orde zijn

Wanneer een winkel zich in een regio bevindt die zoneredundantie ondersteunt en alle beschikbaarheidszones operationeel zijn, kunt u het volgende gedrag verwachten:

• Bewerking tussen zones: App Configuration beheert automatisch verkeersroutering tussen beschikbaarheidszones. Tijdens normale bewerkingen worden aanvragen transparant verdeeld over zones.

• Replicatie van gegevens in meerdere zones: In regio's die zones ondersteunen, repliceert App Configuration synchroon gegevens over beschikbaarheidszones. Deze replicatie zorgt ervoor dat uw instellingen consistent en beschikbaar blijven, zelfs als een zone niet beschikbaar is.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een winkel zich in een regio bevindt die zoneredundantie ondersteunt en een beschikbaarheidszone niet beschikbaar is:

• Detectie en reactie: De App Configuration-service detecteert zonefouten en reageert er automatisch op. U hoeft geen actie te ondernemen tijdens een zonefout.

• Bekendmaking: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Tijdens een zonefout kan de getroffen zone mogelijk geen aanvragen tijdens de vlucht verwerken. Hiervoor moeten clienttoepassingen deze opnieuw proberen. Clienttoepassingen moeten de tijdelijke procedures voor foutafhandeling volgen om ervoor te zorgen dat ze aanvragen opnieuw kunnen proberen als er een zonefout optreedt.

• Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht tijdens een zonefout vanwege de synchrone replicatie tussen zones.

• Verwachte downtime: Er wordt geen downtime verwacht.

• Herverdeling: App Configuration routeert verkeer automatisch van de betrokken zone naar zones die in orde zijn zonder tussenkomst van de klant.

Zoneherstel

Wanneer een zone die eerder niet beschikbaar was herstelt, herstelt App Configuration automatisch de normale werking in alle beschikbaarheidszones. U hoeft geen actie te ondernemen om te herstellen van een zonefout.

Testen op zonefouten

Het Azure App Configuration-platform beheert verkeersroutering, failover en zoneherstel voor zone-redundante winkels. Omdat dit proces volledig wordt beheerd door Microsoft, hoeft u de foutprocessen van de beschikbaarheidszone niet te valideren.

Tolerantie voor storingen in de hele regio

Azure App Configuration biedt systeemeigen mogelijkheden voor geo-replicatie ter ondersteuning van tolerantie tijdens regiostoringen. Met geo-replicatie kunnen configuratiegegevens worden gerepliceerd tussen regio's als een functie voor beheerde services.

Geo-replicatie

Met geo-replicatie kan een archief worden gerepliceerd in meerdere Azure-regio's. Elke winkel kan meerdere replica's in verschillende regio's hebben. De oorspronkelijke winkel is ook een replica. Met deze mogelijkheid kunt u toepassingen beschermen tegen regiobrede onderbrekingen.

Requirements

• Regioondersteuning: U kunt replica's maken in elke Azure-regio die wordt ondersteund door Azure App Configuration, zelfs als de regio's geen gekoppelde Azure-regio's zijn.

• Tier: Het configuratiearchief moet een ondersteunde laag gebruiken om geo-replicatie in te schakelen. Zie Geo-replicatie inschakelen voor meer informatie.

Overwegingen

Houd rekening met de volgende factoren wanneer u geo-replicatie inschakelt:

• Zone-redundante replica's: Elke replica die u maakt in een regio waarin App Configuration beschikbaarheidszones ondersteunt, is automatisch zone-redundant.

• Azure Front Door: Als u geografisch redundante configuratielevering met Azure Front Door wilt inschakelen, configureert u App Configuration-replica's als oorsprong binnen een oorsprongsgroep. Met de juiste oorsprongsconfiguratie kan Azure Front Door op status gebaseerde routering, taakverdeling en automatische failover tussen regio's beheren. Zie Verkeersrouteringsmethoden voor oorsprong voor meer informatie.

Kosten

Elke geografisch gerepliceerde regio wordt afzonderlijk gefactureerd op basis van de prijzen voor de respectieve laag en regio. Er zijn geen gegevensuitvoer kosten van toepassing op replicatie tussen regio's. Zie prijzen voor Azure App Configuration voor meer informatie.

Ondersteuning voor meerdere regio's configureren

Zie Geo-replicatie inschakelen om replicatie in te stellen voor een nieuw configuratiearchief.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een App Configuration-archief configureert voor geo-replicatie en alle regio's operationeel zijn.

• Bewerking tussen zones: Elke replica kan afzonderlijk worden adresseerbaar en heeft een eigen DNS-naam. Alle replica's kunnen zowel lees- als schrijfbewerkingen accepteren.

  Azure App Configuration routeert niet automatisch verkeer tussen regio's. Wanneer u App Configuration-configuratieproviders gebruikt, kan uw toepassing desgewenst automatische replicadetectie gebruiken. U kunt ook een lijst met replica's met prioriteit opgeven en App Configuration selecteert de eerste goede replica. Hierdoor kan uw toepassing bepalen welke replica wordt gebruikt.

  Opmerking

  Als u Azure Front Door gebruikt, verschilt het gedrag van verkeersroutering. Voor meer informatie, zie Failover en taakverdeling.

• Replicatie van gegevens in meerdere zones: Gegevens worden asynchroon gerepliceerd en zijn uiteindelijk consistent. U kunt de metrische replicatielatentie in Azure Monitor gebruiken om de huidige replicatielatentie tussen replica's te bewaken.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een App Configuration-opslag configureert voor geo-replicatie en er een storing optreedt in een van de replicaregio's.

• Detectie en reactie: Microsoft is verantwoordelijk voor het detecteren van regio- of replicafouten en het initiëren van herstelprocessen.

  Wanneer u App Configuration-configuratieproviders gebruikt en automatische replicadetectie uitvoert of met een lijst met meerdere replica's, voert uw toepassing automatisch een failover uit naar een andere goede replica.

  Als u geen App Configuration-providers gebruikt, bent u verantwoordelijk voor het overschakelen van uw toepassing naar een goede replica.

• Kennisgeving: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve aanvragen voor een replica in de regio kunnen worden verwijderd. Clienttoepassingen moeten de aanvragen opnieuw proberen op een andere replica.

• Verwachte gegevensverlies: Als een replica mislukt, worden recente wijzigingen die zijn aangebracht op die replica mogelijk nog niet gerepliceerd naar andere replica's. Deze wijzigingen kunnen niet beschikbaar blijven totdat de replica wordt hersteld. Als u potentiële gegevensverlies wilt schatten, controleert u de metrische replicatielatentie in Azure Monitor.

• Verwachte downtime: Wanneer een replica niet meer beschikbaar is, blijft deze offline totdat de regio wordt hersteld. Andere replica's blijven aanvragen verwerken. Toepassingen kunnen korte downtime ondervinden tijdens het detecteren van de fout en overschakelen naar een goede replica. De duur is afhankelijk van hoe snel elke toepassing deze detectie en failover uitvoert.

• Herverdeling: Toepassingen moeten verkeer routeren naar een goede replica wanneer er een fout optreedt.

  Als u App Configuration-configuratieproviders gebruikt, verwerken de providers automatisch replicaselectie en failover.

  Als u Azure Front Door vóór uw gegevensarchief plaatst en de oorspronkelijke groep met meerdere replica's configureert als oorsprong voor failover, stuurt Azure Front Door aanvragen automatisch om naar een goede replica.

Herstel van de regio

Nadat de regio is hersteld, synchroniseert App Configuration de replica met de andere replica's zonder uw tussenkomst.

U bent verantwoordelijk voor het opnieuw configureren van uw toepassing om verkeer terug te sturen naar het herstelde regio-exemplaar. Toepassingen die app-configuratieproviders gebruiken, beginnen automatisch opnieuw met het gebruik van de replica.

Test voor regiofouten

U kunt momenteel geen replicafailover rechtstreeks simuleren in App Configuration. Omdat toepassingen echter de selectie van replica's beheren, kunt u het failovergedrag testen door de toepassing af te dwingen in een status waarin replica's moeten worden gewijzigd.

Als u het failovergedrag van de replica van uw toepassing wilt valideren, kunt u een gecontroleerde connectiviteitsfout in een niet-productieomgeving introduceren en zien hoe de toepassing reageert.

Een benadering is het gebruik van uw lokale computer of een andere omgeving waar u beheerderstoegang hebt. Volg deze stappen:

1. Uitgebreide logboekregistratie inschakelen voor de Azure SDK. Gebruik in .NET de AzureEventSourceListener klasse om een logboekregistratie te configureren. Zie Zelfstudie: Dynamische configuratie gebruiken in een .NET-app - Logboekregistratie en bewaking voor meer informatie.

2. Configureer het hosts bestand handmatig zodat aanvragen naar het App Configuration-archief worden doorgestuurd naar een IP-adres dat ze niet kan ontvangen, zoals 127.0.0.1 (localhost).

   Waarschuwing

   Deze stap blokkeert effectief de toegang van uw computer naar uw App Configuration-archief. Volg deze stappen alleen in een niet-productieomgeving.

3. Bewaak de logboeken voor een bericht dat er ongeveer als volgt uit ziet:

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   Dit bericht geeft aan dat de toepassing met succes is overgeschakeld naar een andere replica van uw opslag.

4. Nadat u de test hebt voltooid, moet u de wijzigingen in het hosts bestand ongedaan maken.

Backups en herstel

Met Azure App Configuration kunt u configuratiegegevens exporteren uit een archief en deze gebruiken als onderdeel van een bredere back-upstrategie.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

Veerkracht tegen onbedoeld verwijderen

App Configuration biedt twee belangrijke herstelfuncties om onbedoelde of schadelijke verwijdering te voorkomen:

• Voorlopig verwijderen: Wanneer deze optie is ingeschakeld, kunt u verwijderde archieven en instellingen herstellen tijdens een configureerbare bewaarperiode. Denk aan tijdelijke verwijdering als een prullenbak voor uw App Configuration-resources.

• Opschoningsbeveiliging: Wanneer deze optie is ingeschakeld, voorkomt opschoningsbeveiliging dat uw winkel en de bijbehorende instellingen permanent worden verwijderd totdat de bewaarperiode is verstreken. Deze beveiliging voorkomt dat kwaadwillende actoren uw instellingen permanent vernietigen.

Gebruik beide functies voor productieomgevingen. Zie Beveiliging tegen voorlopig verwijderen en opschonen voor meer informatie.

Tolerantie voor serviceonderhoud

Microsoft voert regelmatig service-updates en ander onderhoud uit. De service verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u bent geadviseerd via gepland onderhoud van Azure Service Health.

Tolerantie voor configuratieproblemen

Onjuiste of onbedoelde configuratiewijzigingen kunnen leiden tot uitvaltijd van toepassingen. Gebruik configuratiemomentopnamen om wijzigingen in de configuratie veilig uit te rollen. Controleer de status van uw toepassing na eventuele configuratiewijzigingen en ga terug naar de laatst bekende goede configuratiemomentopname als de wijzigingen een probleem veroorzaken.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

• Betrouwbaarheid in Azure
• documentatie voor Azure App Configuration