Betrouwbaarheid in Azure-app Service
In dit artikel wordt betrouwbaarheidsondersteuning in Azure-app Service beschreven en wordt zowel tolerantie binnen de regio behandeld als beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheidsprincipes in Azure.
Azure-app Service is een HTTP-service voor het hosten van webtoepassingen, REST API's en mobiele back-ends; en voegt de kracht van Microsoft Azure toe aan uw toepassing, zoals:
- Beveiliging
- Load balancing
- Automatisch schalen
- Geautomatiseerd beheer
Als u wilt weten hoe Azure-app Service de betrouwbaarheid en tolerantie van uw toepassingsworkload kan verbeteren, raadpleegt u Waarom App Service gebruiken?
Ondersteuning voor beschikbaarheidszone
Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.
Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.
Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie over zone-redundante architectuur en zone-redundante architectuur.
Azure-app Service kan worden geïmplementeerd in beschikbaarheidszones (AZ) om u te helpen bij het bereiken van tolerantie en betrouwbaarheid voor uw bedrijfskritieke workloads. Deze architectuur wordt ook wel zoneredundantie genoemd.
Wanneer u App Service configureert als zone-redundant, verspreidt het platform automatisch de exemplaren van het Azure-app Service-plan over drie zones in de geselecteerde regio.
Het verspreiden van exemplaren met een zone-redundante implementatie wordt bepaald binnen de volgende regels, zelfs als de app wordt ingeschaald en uitgeschaald:
- Het minimale aantal exemplaren van het App Service-plan is drie.
- Als u een capaciteit opgeeft die groter is dan drie en het aantal exemplaren deelbaar is door drie, worden de exemplaren gelijkmatig verdeeld.
- Alle exemplaren tellen meer dan 3*N zijn verspreid over de resterende één of twee zones.
Ondersteuning voor beschikbaarheidszones is een eigenschap van het App Service-plan. App Service-plannen kunnen worden gemaakt in een beheerde omgeving met meerdere tenants of toegewezen omgevingen met behulp van App Service Environment v3. Zie het overzicht van App Service Environment v3 voor meer informatie over App Service Environment v3.
Voor App Services die niet zijn geconfigureerd om zone-redundant te zijn, zijn VM-exemplaren niet zonebestendig en kunnen er downtime optreden tijdens een storing in een zone in die regio.
Zie Enterprise-implementatie met hoge beschikbaarheid met behulp van App Service Environment voor informatie over de architectuur voor bedrijfsimplementaties voor ondernemingen.
Vereisten
De huidige vereisten/beperkingen voor het inschakelen van beschikbaarheidszones zijn:
Zowel Windows als Linux worden ondersteund.
Beschikbaarheidszones worden alleen ondersteund voor de nieuwere App Service-footprint. Zelfs als u een van de ondersteunde regio's gebruikt, krijgt u een foutmelding als beschikbaarheidszones niet worden ondersteund voor uw resourcegroep. Om ervoor te zorgen dat uw workloads terechtkomen op een stempel die beschikbaarheidszones ondersteunt, moet u mogelijk een nieuwe resourcegroep, App Service-plan en App Service maken.
Uw App Services-plan moet een van de volgende abonnementen zijn die ondersteuning bieden voor beschikbaarheidszones:
- In een omgeving met meerdere tenants met behulp van App Service Premium v2- of Premium v3-abonnementen.
- In een toegewezen omgeving met App Service Environment v3, die wordt gebruikt met Geïsoleerde v2 App Service-plannen.
Voor toegewezen omgevingen moet uw App Service-omgeving v3 zijn.
Belangrijk
App Service Environment v2 en v1 wordt op 31 augustus 2024 buiten gebruik gesteld. App Service Environment v3 is eenvoudiger te gebruiken en wordt uitgevoerd op krachtigere infrastructuur. Zie het overzicht van App Service Environment voor meer informatie over App Service Environment v3. Als u momenteel App Service Environment v2 of v1 gebruikt en u een upgrade wilt uitvoeren naar v3, volgt u de stappen in dit artikel om naar de nieuwe versie te migreren.
Het minimumaantal exemplaren van drie zones wordt afgedwongen. Het platform dwingt dit minimale aantal achter de schermen af als u minder dan drie exemplaren opgeeft.
Beschikbaarheidszones kunnen alleen worden opgegeven bij het maken van een nieuw App Service-plan. Een bestaand App Service-plan kan niet worden geconverteerd om beschikbaarheidszones te gebruiken.
De volgende regio's ondersteunen Azure-app Services die worden uitgevoerd in omgevingen met meerdere tenants:
- Australië - oost
- Brazilië - zuid
- Canada - midden
- India - centraal
- Central US
- Azië - oost
- VS - oost
- VS - oost 2
- Frankrijk - centraal
- Duitsland - west-centraal
- Israël - centraal
- Italië - noord
- Japan - oost
- Korea - centraal
- Mexico - centraal
- Europa - noord
- Noorwegen - oost
- Polen - centraal
- Qatar - centraal
- Zuid-Afrika - noord
- VS - zuid-centraal
- Azië - zuidoost
- Centraal Spanje
- Zweden - centraal
- Zwitserland - noord
- VAE - noord
- Verenigd Koninkrijk Zuid
- Europa -west
- VS - west 2
- US - west 3
- Microsoft Azure beheerd door 21Vianet - China - Noord 3
- Azure Government - US Gov Virginia
Zie Regio's voor meer informatie over welke regio's beschikbaarheidszones ondersteunen voor App Service Environment v3.
Een resource maken waarvoor beschikbaarheidszone is ingeschakeld
Een zone-redundante App Service met meerdere tenants implementeren
Als u beschikbaarheidszones wilt inschakelen met behulp van de Azure CLI, neemt u de --zone-redundant parameter op wanneer u uw App Service-plan maakt. U kunt ook de --number-of-workers parameter opnemen om capaciteit op te geven. Als u geen capaciteit opgeeft, wordt het platform standaard ingesteld op drie. Capaciteit moet worden ingesteld op basis van de workloadvereiste, maar niet minder dan drie. Een goede vuistregel om capaciteit te kiezen, is ervoor te zorgen dat er voldoende exemplaren voor de toepassing zijn, zodat het verlies van één zone van exemplaren voldoende capaciteit overlaat om de verwachte belasting te verwerken.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Tip
Als u de capaciteit van het exemplaar wilt bepalen, kunt u de volgende berekening gebruiken:
Omdat het platform VM's verspreidt over drie zones en u rekening moet houden met ten minste de fout van één zone, vermenigvuldigt u het aantal piekwerkbelastingexemplaren met een factor zones/(zones-1) of 3/2. Als uw typische piekworkload bijvoorbeeld vier exemplaren vereist, moet u zes exemplaren inrichten: (2/3 * 6 exemplaren) = 4 exemplaren.
Een zoneredundante App Service implementeren met behulp van een toegewezen omgeving
Zie Een App Service Environment maken voor meer informatie over het maken van een App Service Environment v3 in het Geïsoleerde v2-plan.
Probleemoplossing
| Foutmelding | Beschrijving | Aanbeveling |
|---|---|---|
| Zoneredundantie is niet beschikbaar voor resourcegroep 'RG-NAME'. Implementeer het App Service-plan ASP-NAME in een nieuwe resourcegroep. | Beschikbaarheidszones worden alleen ondersteund voor de nieuwere App Service-footprint. Zelfs als u een van de ondersteunde regio's gebruikt, krijgt u een foutmelding als beschikbaarheidszones niet worden ondersteund voor uw resourcegroep. | Maak een nieuwe resourcegroep, een App Service-plan en App Service om ervoor te zorgen dat uw workloads terechtkomen op een stempel die beschikbaarheidszones ondersteunt. |
Fouttolerantie
Ter voorbereiding op een storing in de beschikbaarheidszone moet u de capaciteit van de service overschakelen om ervoor te zorgen dat de oplossing 1/3 verlies van capaciteit tolereert en blijft functioneren zonder verminderde prestaties tijdens storingen in de hele zone. Omdat het platform VM's verspreidt over drie zones en u rekening moet houden met ten minste de fout van één zone, vermenigvuldigt u het aantal piekwerkbelastingexemplaren met een factor zones/(zones-1) of 3/2. Als uw typische piekworkload bijvoorbeeld vier exemplaren vereist, moet u zes exemplaren inrichten: (2/3 * 6 exemplaren) = 4 exemplaren.
Zone-down-ervaring
Verkeer wordt doorgestuurd naar al uw beschikbare App Service-exemplaren. In het geval dat een zone uitvalt, detecteert het App Service-platform verloren exemplaren en probeert automatisch nieuwe vervangingsexemplaren te vinden en verkeer naar behoefte te verspreiden. Als u automatische schaalaanpassing hebt geconfigureerd en er meer exemplaren nodig zijn, geeft automatisch schalen ook een aanvraag aan App Service uit om meer exemplaren toe te voegen. Houd er rekening mee dat het gedrag van automatisch schalen onafhankelijk is van het gedrag van het App Service-platform en dat de specificatie voor het aantal exemplaren voor automatisch schalen geen veelvoud van drie hoeft te zijn.
Notitie
Er is geen garantie dat aanvragen voor extra exemplaren in een zone-down scenario slagen. De back-invulling van verloren exemplaren vindt plaats op basis van best effort. De aanbevolen oplossing is het maken en configureren van uw App Service-plannen om rekening te houden met het verliezen van een zone, zoals beschreven in de volgende sectie.
Toepassingen die zijn geïmplementeerd in een App Service-plan waarvoor beschikbaarheidszones zijn ingeschakeld, blijven actief en verwerken verkeer, zelfs als andere zones in dezelfde regio een storing ondervinden. Het is echter mogelijk dat niet-runtimegedrag, waaronder het schalen van Een App Service-plan, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen, nog steeds wordt beïnvloed door een storing in andere Beschikbaarheidszones. Zoneredundantie voor App Service-plannen zorgt alleen voor continue uptime voor geïmplementeerde toepassingen.
Wanneer het App Service-platform instanties toewijst aan een zoneredundant App Service-plan, wordt gebruikgemaakt van zoneverdeling met best effort die wordt aangeboden door de onderliggende virtuele-machineschaalsets van Azure. Een App Service-plan wordt 'evenwichtig' als elke zone hetzelfde aantal VM's heeft of +/- één VM in alle andere zones die door het App Service-plan worden gebruikt.
Migratie van beschikbaarheidszone
U kunt bestaande App Service-exemplaren of omgevingsbronnen niet migreren van ondersteuning voor niet-beschikbaarheidszones naar ondersteuning voor beschikbaarheidszones. Als u ondersteuning wilt krijgen voor beschikbaarheidszones, moet u uw resources maken waarvoor beschikbaarheidszones zijn ingeschakeld.
Prijzen
Voor omgevingen met meerdere tenants die gebruikmaken van App Service Premium v2- of Premium v3-abonnementen, zijn er geen extra kosten verbonden aan het inschakelen van beschikbaarheidszones zolang u drie of meer exemplaren in uw App Service-plan hebt. Er worden kosten in rekening gebracht op basis van de SKU van uw App Service-plan, de capaciteit die u opgeeft en eventuele instanties waarnaar u schaalt op basis van uw criteria voor automatisch schalen. Als u beschikbaarheidszones inschakelt, maar een capaciteit van minder dan drie opgeeft, dwingt het platform een minimumaantal exemplaren van drie af en brengt u kosten in rekening voor deze drie exemplaren. App Service Environment v3 heeft een ander prijsmodel voor beschikbaarheidszones. Zie Prijzen voor prijsinformatie voor App Service Environment v3.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
In deze sectie worden enkele algemene strategieën beschreven voor web-apps die zijn geïmplementeerd in App Service.
Wanneer u een web-app maakt in App Service en een Azure-regio kiest tijdens het maken van resources, is dit een app met één regio. Wanneer de regio niet meer beschikbaar is tijdens een noodgeval, is uw toepassing ook niet meer beschikbaar. Als u een identieke implementatie maakt in een secundaire Azure-regio met behulp van een geografiearchitectuur voor meerdere regio's, is uw toepassing minder vatbaar voor een noodgeval met één regio, wat bedrijfscontinuïteit garandeert. Met elke gegevensreplicatie in de regio's kunt u de laatste toepassingsstatus herstellen.
Voor IT worden bedrijfscontinuïteitsplannen grotendeels aangestuurd door RTO (Recovery Time Objective) en Recovery Point Objective (RPO). Zie Hersteldoelstellingen voor meer informatie over RTO en RPO.
Normaal gesproken is het onderhouden van een SLA rond RTO onpraktisch voor regionale rampen en zou u doorgaans alleen uw strategie voor herstel na noodgevallen rond RPO ontwerpen (dat wil bijvoorbeeld richten op het herstellen van gegevens en niet op het minimaliseren van onderbrekingen). Met Azure is het echter niet alleen praktisch, maar is het zelfs eenvoudig om App Service te implementeren voor automatische geo-failovers. Hierdoor kunt u uw toepassingen verder noodgevalbestendig maken door zowel RTO als RPO te verzorgen.
Afhankelijk van de gewenste RTO- en RPO-metrische gegevens, worden drie architecturen voor herstel na noodgevallen vaak gebruikt voor zowel App Service-multitenant- als App Service-omgevingen. Elke architectuur wordt beschreven in de volgende tabel:
| Metrische gegevens | Actief-actief | Actief-passief | Passief/koud |
|---|---|---|---|
| RTO | Realtime of seconden | Minuten | Uur |
| RPO | Realtime of seconden | Minuten | Uur |
| Kosten | $$$ | $$ | $ |
| Scenario's | Bedrijfskritieke apps | Apps met hoge prioriteit | Apps met lage prioriteit |
| Mogelijkheid om gebruikersverkeer voor meerdere regio's te bedienen | Ja | Ja/misschien | Nee |
| Implementatie van code | Voorkeurs-CI/CD-pijplijnen | Voorkeurs-CI/CD-pijplijnen | Back-ups en herstellen |
| Nieuwe App Service-resources maken tijdens downtime | Niet vereist | Niet vereist | Vereist |
Notitie
Uw toepassing is waarschijnlijk afhankelijk van andere gegevensservices in Azure, zoals Azure SQL Database- en Azure Storage-accounts. Het is raadzaam ook strategieën voor herstel na noodgevallen te ontwikkelen voor elk van deze afhankelijke Azure-services. Zie Actieve geo-replicatie voor Azure SQL Database voor SQL Database voor SQL Database. Zie Azure Storage-redundantie voor Azure Storage.
Herstel na noodgevallen in geografie in meerdere regio's
Er zijn meerdere manieren om inhoud en configuraties van uw web-apps te repliceren in Azure-regio's in een actief-actief- of actief-passieve architectuur, zoals het gebruik van back-up en herstel van App Service. Back-up en herstel maken echter momentopnamen van een bepaald tijdstip en leiden uiteindelijk tot problemen met versiebeheer van web-apps in verschillende regio's. Zie de volgende tabel hieronder voor een vergelijking tussen richtlijnen voor terugzetten en herstellen versus richtlijnen voor herstel van diaster:
Back-ups maken en herstellen versus herstel na noodgevallen
| Platform | Richtlijnen voor back-ups maken en herstellen | Richtlijnen voor herstel na noodgevallen |
|---|---|---|
| App Service-web-apps (Gratis en Gedeelde prijscategorieën) |
Als u webtoepassingen hebt geïmplementeerd in de gratis of gedeelde laag en toegang nodig hebt tot back-up- en herstelmogelijkheden voor deze web-apps, kunt u omhoog schalen naar de Basic-laag of hoger. | Breng App Service-resources weer online in een andere Azure-regio tijdens een regionale ramp. Vanaf 31 maart 2025 worden App Service-toepassingen niet in de modus voor herstel na noodgevallen geplaatst tijdens een noodgeval in een Azure-regio, zoals wordt uitgelegd in het artikel over herstel na een storing in de hele regio. We raden u aan veelgebruikte technieken voor herstel na noodgevallen te implementeren om downtime en gegevensverlies tijdens een regionaal noodgeval te voorkomen. |
| App Service-web-apps (Prijscategorieën Basic, Standard en Premium) |
In Azure-app Service kunt u aangepaste back-ups op aanvraag maken of automatische back-ups gebruiken. U kunt een back-up herstellen door een bestaande app te overschrijven of door deze te herstellen naar een nieuwe app of site. Raadpleeg Back-up en herstel uw app in Azure-app Service voor meer informatie. |
Huidige richtlijnen met betrekking tot het online brengen van App Service-resources in een andere Azure-regio tijdens een regionale noodgeval is beschikbaar bij Herstellen na een storing in de hele regio - Azure-app Service. Vanaf 31 maart 2025 worden Azure-app Service-webtoepassingen niet meer in de modus voor herstel na noodgevallen geplaatst tijdens een noodgeval in een Azure-regio, zoals wordt uitgelegd in het artikel over herstel na een storing in de hele regio. We raden u aan veelgebruikte technieken voor herstel na noodgevallen te implementeren om verlies van functionaliteit of gegevens voor uw web-apps te voorkomen als er sprake is van een regionaal noodgeval. |
| App Service Environment (V2 en V3) | In Azure-app Service Environment kunt u aangepaste back-ups op aanvraag maken of automatische back-ups gebruiken. Automatische back-ups kunnen worden hersteld naar een doel-app binnen dezelfde App Service-omgeving, niet in een andere App Service-omgeving. Aangepaste back-ups kunnen worden hersteld naar een doel-app in een andere App Service-omgeving (zoals van een V2 App Service-omgeving naar een V3 App Service-omgeving). Back-ups kunnen worden hersteld naar een doel-app van hetzelfde besturingssysteemplatform als de bron-app. Raadpleeg Back-ups maken en uw app herstellen in Azure-app Service voor meer informatie. |
We raden u aan richtlijnen voor herstel na noodgevallen te implementeren voor web-apps die zijn geïmplementeerd in App Service Environment met behulp van veelgebruikte technieken voor herstel na noodgevallen. |
| Azure Functions: Toegewezen abonnement |
Wanneer u uw functie-app uitvoert in een Toegewezen (App Service)-plan, wordt de vereiste inhoud van de functie-app onderhouden met behulp van ingebouwde opslag. In een Dedicated-abonnement kunt u aangepaste back-ups op aanvraag maken of automatische back-ups gebruiken. U kunt een back-up herstellen door een bestaande app te overschrijven of door deze te herstellen naar een nieuwe app of site. Zie Back-up maken en herstellen van uw app in Azure-app Service voor meer informatie. Azure Files wordt niet gebruikt door een Dedicated-abonnement, maar als u uw app onjuist hebt geconfigureerd met een Azure Files-verbinding, wordt back-up niet ondersteund. |
Huidige richtlijnen met betrekking tot het online brengen van functie-app-resources in een toegewezen plan in een andere Azure-regio tijdens een regionale ramp, is beschikbaar bij Herstellen na een storing in de hele regio- Azure-app Service. Vanaf 31 maart 2025 worden App Service-toepassingen niet in de modus voor herstel na noodgevallen geplaatst tijdens een noodgeval in een Azure-regio, zoals wordt uitgelegd in het artikel over herstel na een storing in de hele regio. U moet in plaats daarvan de betrouwbaarheid in uw functie-apps plannen. U kunt ook verwijzen naar veelgebruikte technieken voor herstel na noodgevallen voor functie-apps in een Dedicated-plan. |
| Azure Functions: Flexverbruik, Verbruiks- en Premium-abonnementen |
Functie-apps die worden uitgevoerd in een Flex Consumption-abonnement, in een Verbruiksabonnement of in een Premium-abonnement , kunnen geen aangepaste of automatische back-upfunctionaliteit gebruiken in App Service. In deze dynamische schaalplannen wordt inhoud van de functie-app onderhouden in Azure Storage. Gebruik redundantieopties voor Azure Storage om ervoor te zorgen dat uw opslagaccount voldoet aan de beschikbaarheids- en duurzaamheidsdoelen tijdens een storing. U kunt uw bestaande functie-app-project ook downloaden als een .zip-bestand vanuit Azure Portal. |
We raden u ten zeere aan om betrouwbaarheid in uw functie-apps te plannen. |
Als u de beperkingen van back-up- en herstelmethoden wilt voorkomen, configureert u uw CI/CD-pijplijnen om code te implementeren in beide Azure-regio's. Overweeg het gebruik van Azure Pipelines of GitHub Actions. Zie Continue implementatie naar Azure-app Service voor meer informatie.
Detectie, melding en beheer van storingen
Het is raadzaam om bewaking en waarschuwingen voor uw web-apps in te stellen voor tijdige meldingen tijdens een noodgeval. Zie Application Insights-beschikbaarheidstests voor meer informatie.
Als u uw toepassingsbronnen in Azure wilt beheren, gebruikt u een IaC-mechanisme (Infrastructure-as-Code). Voor een complexe implementatie in meerdere regio's is een voorspelbaar, testbaar en herhaalbaar proces nodig om de configuratie onafhankelijk te beheren en om de configuratie gesynchroniseerd te houden tussen regio's op een betrouwbare manier. Overweeg een IaC-hulpprogramma, zoals Azure Resource Manager-sjablonen of Terraform.
Herstel na noodgevallen en detectie van storingen instellen
Als u zich wilt voorbereiden op herstel na noodgevallen in een geografie met meerdere regio's, kunt u een actief-actief- of actief-passieve architectuur gebruiken.
Active-Active-architectuur
In architectuur voor actief-actief herstel na noodgevallen worden identieke web-apps geïmplementeerd in twee afzonderlijke regio's en wordt Azure Front door gebruikt om verkeer naar beide actieve regio's te routeren.
Met deze voorbeeldarchitectuur:
- Identieke App Service-apps worden geïmplementeerd in twee afzonderlijke regio's, waaronder de prijscategorie en het aantal exemplaren.
- Openbaar verkeer rechtstreeks naar de App Service-apps wordt geblokkeerd.
- Azure Front Door wordt gebruikt om verkeer naar beide actieve regio's te routeren.
- Tijdens een noodgeval wordt een van de regio's offline en routeert Azure Front Door verkeer uitsluitend naar de regio die online blijft. De RTO tijdens een dergelijke geo-failover is bijna nul.
- Toepassingsbestanden moeten worden geïmplementeerd in beide web-apps met een CI/CD-oplossing. Dit zorgt ervoor dat de RPO praktisch nul is.
- Als uw toepassing het bestandssysteem actief wijzigt, kunt u RPO het beste minimaliseren door alleen naar een gekoppelde Azure Storage-share te schrijven in plaats van rechtstreeks naar de /home-inhoudsshare van de web-app te schrijven. Gebruik vervolgens de Azure Storage-redundantiefuncties (GZRS of GRS) voor uw gekoppelde share, met een RPO van ongeveer 15 minuten.
Stappen voor het maken van een actief-actief-architectuur voor uw web-app in App Service worden als volgt samengevat:
Maak twee App Service-abonnementen in twee verschillende Azure-regio's. Configureer de twee App Service-abonnementen op dezelfde manier.
Maak twee exemplaren van uw web-app, met één in elk App Service-plan.
Maak een Azure Front Door-profiel met:
- Een eindpunt.
- Twee oorsprongsgroepen, elk met een prioriteit van 1. De gelijke prioriteit geeft Azure Front Door aan om verkeer naar beide regio's gelijkmatig te routeren (dus actief-actief).
- Een route.
Beperk netwerkverkeer alleen naar de web-apps vanuit het Azure Front Door-exemplaar.
Alle andere back-end-Azure-services, zoals databases, opslagaccounts en verificatieproviders, instellen en configureren.
Code implementeren in beide web-apps met continue implementatie.
Zelfstudie: Een maximaal beschikbare app voor meerdere regio's maken in Azure-app Service laat zien hoe u een actief-passieve architectuur instelt. Dezelfde stappen met minimale wijzigingen (prioriteit instellen op '1' voor beide origins in de oorspronkelijke groep in Azure Front Door) bieden u een actief-actief architectuur.
Actief-passieve architectuur
In deze aanpak voor herstel na noodgevallen worden identieke web-apps geïmplementeerd in twee afzonderlijke regio's en wordt Azure Front Door gebruikt om verkeer alleen naar één regio te routeren (de actieve regio).
Met deze voorbeeldarchitectuur:
Identieke App Service-apps worden geïmplementeerd in twee afzonderlijke regio's.
Openbaar verkeer rechtstreeks naar de App Service-apps wordt geblokkeerd.
Azure Front Door wordt gebruikt om verkeer naar de primaire regio te routeren.
Om kosten te besparen, is het secundaire App Service-plan zo geconfigureerd dat er minder exemplaren zijn en/of zich in een lagere prijscategorie bevinden. Er zijn drie mogelijke benaderingen:
Voorkeur het secundaire App Service-plan heeft dezelfde prijscategorie als de primaire, met hetzelfde aantal exemplaren of minder. Deze benadering zorgt voor pariteit in zowel functie- als VM-grootte voor de twee App Service-plannen. De RTO tijdens een geo-failover is alleen afhankelijk van de tijd die nodig is om de exemplaren uit te schalen.
Minder voorkeur Het secundaire App Service-plan heeft hetzelfde type prijscategorie (zoals PremiumV3), maar kleinere VM-grootten, met minder exemplaren. De primaire regio bevindt zich bijvoorbeeld in de P3V3-laag terwijl de secundaire regio zich in de P1V3-laag bevindt. Deze benadering zorgt nog steeds voor functiepariteit voor de twee App Service-plannen, maar het gebrek aan groottepariteit kan handmatig omhoog schalen vereisen wanneer de secundaire regio de actieve regio wordt. De RTO tijdens een geo-failover is afhankelijk van de tijd die nodig is om de exemplaren omhoog te schalen en uit te schalen.
Het secundaire App Service-plan heeft een andere prijscategorie dan de primaire en mindere instanties. De primaire regio bevindt zich bijvoorbeeld in de P3V3-laag terwijl de secundaire regio zich in de S1-laag bevindt. Zorg ervoor dat het secundaire App Service-plan alle functies bevat die uw toepassing nodig heeft om uit te voeren. Verschillen in de beschikbaarheid van functies tussen de twee kunnen leiden tot vertragingen in het herstel van uw web-app. De RTO tijdens een geo-failover is afhankelijk van de tijd die nodig is om de exemplaren omhoog te schalen en uit te schalen.
Automatische schaalaanpassing wordt geconfigureerd voor de secundaire regio in het geval dat de actieve regio inactief wordt. Het is raadzaam om vergelijkbare regels voor automatische schaalaanpassing te hebben in zowel actieve als passieve regio's.
Tijdens een noodgeval wordt de primaire regio inactief en ontvangt de secundaire regio verkeer en wordt de actieve regio.
Zodra de secundaire regio actief wordt, activeert de netwerkbelasting vooraf geconfigureerde regels voor automatisch schalen om de secundaire web-app uit te schalen.
Mogelijk moet u de prijscategorie voor de secundaire regio handmatig omhoog schalen als deze nog niet beschikt over de benodigde functies die moeten worden uitgevoerd als de actieve regio. Voor automatisch schalen is bijvoorbeeld een Standard-laag of hoger vereist.
Wanneer de primaire regio weer actief is, stuurt Azure Front Door automatisch verkeer terug naar de regio en wordt de architectuur teruggeleid naar actief-passief als voorheen.
Toepassingsbestanden moeten worden geïmplementeerd in beide web-apps met een CI/CD-oplossing. Dit zorgt ervoor dat de RPO praktisch nul is.
Als uw toepassing het bestandssysteem actief wijzigt, kunt u RPO het beste minimaliseren door alleen naar een gekoppelde Azure Storage-share te schrijven in plaats van rechtstreeks naar de /home-inhoudsshare van de web-app te schrijven. Gebruik vervolgens de Azure Storage-redundantiefuncties (GZRS of GRS) voor uw gekoppelde share, met een RPO van ongeveer 15 minuten.
Stappen voor het maken van een actief-passieve architectuur voor uw web-app in App Service worden als volgt samengevat:
- Maak twee App Service-abonnementen in twee verschillende Azure-regio's. Het secundaire App Service-plan kan worden ingericht met behulp van een van de eerder genoemde benaderingen.
- Configureer regels voor automatisch schalen voor het secundaire App Service-plan, zodat het wordt geschaald naar hetzelfde aantal exemplaren als de primaire wanneer de primaire regio inactief wordt.
- Maak twee exemplaren van uw web-app, met één in elk App Service-plan.
- Maak een Azure Front Door-profiel met:
- Een eindpunt.
- Een oorspronkelijke groep met een prioriteit van 1 voor de primaire regio.
- Een tweede oorsprongsgroep met een prioriteit van 2 voor de secundaire regio. Het verschil in prioriteit geeft Azure Front Door de voorkeur aan de primaire regio wanneer deze online is (dus actief-passief).
- Een route.
- Beperk netwerkverkeer alleen naar de web-apps vanuit het Azure Front Door-exemplaar.
- Alle andere back-end-Azure-services, zoals databases, opslagaccounts en verificatieproviders, instellen en configureren.
- Code implementeren in beide web-apps met continue implementatie.
Zelfstudie: Een maximaal beschikbare app voor meerdere regio's maken in Azure-app Service laat zien hoe u een actief-passieve architectuur instelt.
Passieve koude architectuur
Gebruik een passieve/koude architectuur om regelmatige back-ups van uw web-apps te maken en te onderhouden in een Azure Storage-account dat zich in een andere regio bevindt.
Met deze voorbeeldarchitectuur:
Eén web-app wordt geïmplementeerd in één regio.
Er wordt regelmatig een back-up van de web-app gemaakt naar een Azure Storage-account in dezelfde regio.
De replicatie tussen regio's van uw back-ups is afhankelijk van de configuratie van gegevensredundantie in het Azure-opslagaccount. Stel indien mogelijk uw Azure Storage-account in als GZRS . GZRS biedt zowel synchrone zoneredundantie binnen een regio als asynchroon in een secundaire regio. Als GZRS niet beschikbaar is, configureert u het account als GRS. Zowel GZRS als GRS hebben een RPO van ongeveer 15 minuten.
Om ervoor te zorgen dat u back-ups kunt ophalen wanneer de primaire regio van het opslagaccount niet meer beschikbaar is, schakelt u respectievelijk alleen-lezentoegang tot secundaire regio in (waardoor het opslagaccount RA-GZRS of RA-GRS wordt). Zie Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen voor meer informatie over het ontwerpen van uw toepassingen om gebruik te maken van georedundantie.
Tijdens een noodgeval in de regio van de web-app moet u handmatig alle vereiste App Service-afhankelijke resources implementeren met behulp van de back-ups van het Azure Storage-account, waarschijnlijk uit de secundaire regio met leestoegang. De RTO kan uren of dagen zijn.
Om RTO te minimaliseren, wordt het ten zeerste aanbevolen dat u een uitgebreid playbook hebt waarin alle stappen worden beschreven die nodig zijn om de back-up van uw web-app te herstellen naar een andere Azure-regio.
Stappen voor het maken van een passieve koude regio voor uw web-app in App Service worden als volgt samengevat:
Maak een Azure-opslagaccount in dezelfde regio als uw web-app. Kies de Standard-prestatielaag en selecteer redundantie als Geografisch redundante opslag (GRS) of Geografisch zone-redundante opslag (GZRS).
RA-GRS of RA-GZRS inschakelen (leestoegang voor de secundaire regio).
Configureer aangepaste back-up voor uw web-app . U kunt besluiten om een planning in te stellen voor back-ups van uw web-app, zoals elk uur.
Controleer of de back-upbestanden van de web-app de secundaire regio van uw opslagaccount kunnen worden opgehaald.
Tip
Naast Azure Front Door biedt Azure andere opties voor taakverdeling, zoals Azure Traffic Manager. Zie Opties voor taakverdeling - Azure Architecture Center voor een vergelijking van de verschillende opties.
Herstel na noodgevallen in geografie met één regio
Als de regio van uw web-app geen GZRS- of GRS-opslag heeft of als u zich in een Azure-regio bevindt die geen regionaal paar is, moet u zone-redundante opslag (ZRS) of lokaal redundante opslag (LRS) gebruiken om een vergelijkbare architectuur te maken. U kunt bijvoorbeeld als volgt handmatig een secundaire regio voor het opslagaccount maken:
Stappen voor het maken van een passieve koude regio zonder GRS en GZRS worden als volgt samengevat:
Maak een Azure-opslagaccount in dezelfde regio van uw web-app. Kies de Standard-prestatielaag en selecteer redundantie als zone-redundante opslag (ZRS).
Configureer aangepaste back-up voor uw web-app . U kunt besluiten om een planning in te stellen voor back-ups van uw web-app, zoals elk uur.
Controleer of de back-upbestanden van de web-app de secundaire regio van uw opslagaccount kunnen worden opgehaald.
Maak een tweede Azure-opslagaccount in een andere regio. Kies de Standard-prestatielaag en selecteer redundantie als lokaal redundante opslag (LRS).
Met behulp van een hulpprogramma zoals AzCopy repliceert u uw aangepaste back-up (Zip, XML en logboekbestanden) van primaire regio naar de secundaire opslag. Voorbeeld:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'U kunt Azure Automation gebruiken met een PowerShell Workflow-runbook om uw replicatiescript volgens een schema uit te voeren. Zorg ervoor dat het replicatieschema een vergelijkbaar schema volgt als de back-ups van de web-app.