Betrouwbaarheid in Azure App Configuration

Azure App Configuration slaat de toepassingsconfiguratie-instellingen en functievlagmen centraal op en beheert deze, waardoor configuratiebestanden die rechtstreeks in toepassingen zijn ingesloten, worden vervangen. Met deze methode kunt u configuratiewaarden dynamisch bijwerken, versiegeschiedenis bijhouden en een record met configuratiewijzigingen in de loop van de tijd bijhouden. 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 App Configuration beschreven en hoe de service is ontworpen om beschikbaar te blijven tijdens tijdelijke fouten, storingen in beschikbaarheidszones 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 te voorkomen dat gegevens worden verwijderd.

  • Voor bedrijfskritieke scenario's: Gebruik de Premium-SKU en configureer de opgenomen replica om te repliceren in meerdere regio's. Deze aanpak verbetert de hoge beschikbaarheid en tolerantie voor storingen in regio's.

Zie Toepassingen bouwen met een hoge tolerantie voor een lijst met aanbevolen procedures en configuraties 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 App Configuration?

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

Wanneer u clienttoepassingen bouwt die verbinding maken met App Configuration, kunt u desgewenst 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 cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

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

  • Configuratieproviders: Gebruik App Configuration-providers met ingebouwde mogelijkheden voor opnieuw proberen en opslaan in cache en 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: Voeg logica voor opnieuw proberen toe aan aangepaste clients als u geen App Configuration-providers of SDK's kunt gebruiken. De retry-after-ms header in het antwoord biedt een voorgestelde wachttijd in milliseconden voordat de client de aanvraag opnieuw probeert uit te voeren.

  • Caching: Cache-instellingen in het geheugen indien mogelijk om directe aanvragen naar uw winkel te verminderen.

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

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke 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.

Diagram met een zoneredundant App Configuration-archief die drie zones in de regio omvat.

In het diagram ziet u beschikbaarheidszones 1, 2 en 3. Het App Configuration-archief omvat alle drie de zones in de regio.

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

Requirements

Regio-ondersteuning: 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 App Configuration.

Ondersteuning voor beschikbaarheidszones configureren

Microsoft configureert zoneredundantie automatisch voor een winkel wanneer deze zich in a-regio bevindt die ondersteuning biedt voor beschikbaarheidszones.

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

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een zone-redundante App Configuration-winkel hebt en alle zones operationeel zijn.

  • 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 u een zone-redundante App Configuration-opslag hebt en er een storing is in een van de zones.

  • Detectie en reactie: De App Configuration-service detecteert zonefouten en reageert er automatisch op. U hoeft geen actie te ondernemen tijdens een zonefout.
  • Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Service Health gebruiken om de algehele status van de service te begrijpen, inclusief eventuele zonefouten, en u kunt Servicestatuswaarschuwingen 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 eerder niet-beschikbare zone wordt hersteld, herstelt App Configuration automatisch normale bewerkingen in alle beschikbaarheidszones. U hoeft geen actie te ondernemen om te herstellen van een zonefout.

Testen op zonefouten

Het App Configuration-platform beheert het routeren van verkeer, failover en herstel op zone-niveau voor zone-redundante archieven. Omdat Microsoft dit proces volledig beheert, hoeft u de uitvalprocessen van beschikbaarheidszones niet te valideren.

Tolerantie voor storingen in de hele regio

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 kunt u een winkel repliceren 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

  • Regio-ondersteuning: U kunt replica's maken in elke Azure regio die door App Configuration wordt ondersteund, zelfs als de regio's niet Azure gekoppelde 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 origins binnen een oorsprongsgroep. Correct geconfigureerde oorsprongen zijn vereist voor Azure Front Door om statusgebaseerde routering, taakverdeling en automatische failover tussen regio's uit te voeren. 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 App Configuration-prijzen voor meer informatie over prijzen.

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 (Domain Name System). Alle replica's kunnen zowel lees- als schrijfbewerkingen accepteren.

    App Configuration routeert verkeer niet automatisch 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. Met deze methode 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 repliceren asynchroon 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.

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

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

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

  • Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt echter Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Statuswaarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Actieve aanvragen voor een replica in de regio kunnen mislukken. 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. Om potentieel gegevensverlies te schatten, controleert u de 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 plaatst vóór uw gegevensarchief en de oorsprongsgroep met meerdere replica's als oorsprong voor failover configureert, leidt Azure Front Door verzoeken automatisch om naar een gezonde 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 Configuration-providers gebruiken, beginnen automatisch opnieuw met het gebruik van de replica.

Test voor regiofouten

U kunt een replicafailover niet 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. Schakel uitgebreide logboekregistratie in voor de Azure SDK. Gebruik in .NET de klasse AzureEventSourceListener om een logboekregistratie te configureren. Zie 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 vergelijkbaar is met het volgende voorbeeld:

    [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

U kunt App Configuration gebruiken om configuratiegegevens uit een archief te exporteren en te 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 u voorlopig verwijderen inschakelt, kunt u verwijderde archieven en instellingen herstellen tijdens een configureerbare bewaarperiode. Functies voor voorlopig verwijderen, zoals een prullenbak voor uw App Configuration-resources.

  • Beveiliging tegen opschonen: Wanneer u beveiliging tegen opschonen inschakelt, voorkomt de service 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 regelmatig service-updates en ander onderhoud uitvoert. De service verwerkt deze activiteiten automatisch, waardoor onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsevenementen, tenzij Azure Service Health een kennisgeving over gepland onderhoud biedt.

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 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 SLAs voor onlineservices voor meer informatie.