Herstel na een serviceonderbreking in de gehele regio

Artikel
03/21/2023

Azure is fysiek en logisch onderverdeeld in eenheden die regio's worden genoemd. Een regio bestaat uit een of meer datacenters in de buurt. Veel regio's en services ondersteunen ook beschikbaarheidszones, die kunnen worden gebruikt om meer tolerantie te bieden tegen storingen in één datacenter. Overweeg het gebruik van regio's met beschikbaarheidszones om de beschikbaarheid van uw oplossing te verbeteren.

In zeldzame gevallen is het mogelijk dat faciliteiten in een volledige beschikbaarheidszone of regio ontoegankelijk worden, bijvoorbeeld door netwerkstoringen. Of faciliteiten kunnen volledig verloren gaan, bijvoorbeeld door een natuurramp. Azure biedt mogelijkheden voor het maken van toepassingen die zijn verdeeld over zones en regio's. Een dergelijke distributie helpt de kans te minimaliseren dat een storing in de ene zone of regio invloed kan hebben op andere zones of regio's.

Cloud services

Resourcebeheer

U kunt rekenprocessen verdelen over regio's door een afzonderlijke cloudservice in elke doelregio te maken en vervolgens het implementatiepakket naar elke cloudservice te publiceren. Het distribueren van verkeer over cloudservices in verschillende regio's moet echter worden geïmplementeerd door de ontwikkelaar van de toepassing of met een verkeersbeheerservice.

Het bepalen van het aantal reserverolinstanties dat vooraf moet worden geïmplementeerd voor herstel na noodgevallen is een belangrijk aspect van capaciteitsplanning. Het hebben van een volledige secundaire implementatie zorgt ervoor dat capaciteit al beschikbaar is wanneer dat nodig is; Dit verdubbelt echter effectief de kosten. Een veelvoorkomend patroon is om een kleine, secundaire implementatie te hebben, net groot genoeg om kritieke services uit te voeren. Deze kleine secundaire implementatie is een goed idee, zowel om capaciteit te reserveren als om de configuratie van de secundaire omgeving te testen.

Notitie

Het abonnementsquotum is geen capaciteitsgarantie. Het quotum is gewoon een kredietlimiet. Om capaciteit te garanderen, moet het vereiste aantal rollen worden gedefinieerd in het servicemodel en moeten de rollen worden geïmplementeerd.

Taakverdeling

Voor een taakverdeling tussen regio's is een oplossing voor verkeerbeheer vereist. Azure biedt Azure Traffic Manager. U kunt ook profiteren van services van derden die vergelijkbare mogelijkheden voor verkeerbeheer bieden.

Strategieën

Er zijn veel alternatieve strategieën beschikbaar voor het implementeren van gedistribueerde rekenkracht tussen regio's. Deze moeten worden afgestemd op de specifieke bedrijfsvereisten en -omstandigheden van de toepassing. Op hoog niveau kunnen de benaderingen worden onderverdeeld in de volgende categorieën:

Opnieuw implementeren bij een noodgeval: In deze benadering wordt de toepassing opnieuw geïmplementeerd op het moment van een noodgeval. Dit is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.
Warm Spare (actief/passief): een secundaire gehoste service wordt gemaakt in een alternatieve regio en rollen worden geïmplementeerd om minimale capaciteit te garanderen; De rollen ontvangen echter geen productieverkeer. Deze benadering is handig voor toepassingen die niet zijn ontworpen om verkeer tussen regio's te verdelen.
Hot Spare (actief/actief): de toepassing is ontworpen om productiebelasting in meerdere regio's te ontvangen. De cloudservices in elke regio kunnen worden geconfigureerd voor een hogere capaciteit dan nodig is voor herstel na noodgevallen. De cloudservices kunnen ook zo nodig worden uitgeschaald op het moment van een noodgeval en een failover uitvoeren. Deze aanpak vereist aanzienlijke investeringen in het ontwerp van toepassingen, maar het heeft aanzienlijke voordelen. Deze omvatten lage en gegarandeerde hersteltijd, doorlopend testen van alle herstellocaties en efficiënt gebruik van capaciteit.

Een volledige bespreking van gedistribueerd ontwerp valt buiten het bereik van dit document. Zie Herstel na noodgevallen en hoge beschikbaarheid voor Azure-toepassingen voor meer informatie.

Virtuele machines

Herstel van IaaS-vm's (Infrastructure as a Service) is in veel opzichten vergelijkbaar met PaaS-rekenproces (Platform as a Service). Er zijn echter belangrijke verschillen vanwege het feit dat een IaaS-VM bestaat uit zowel de VM als de VM-schijf.

Gebruik Azure Backup om regiooverschrijdende back-ups te maken die toepassingsconsistent zijn. Azure Backup stelt klanten in staat om toepassingsconsistente back-ups te maken op meerdere VM-schijven en replicatie van back-ups tussen regio's te ondersteunen. U kunt dit doen door te kiezen voor geo-replicatie van de back-upkluis op het moment van maken. De replicatie van de back-upkluis moet worden geconfigureerd op het moment van het maken. Dit kan later niet worden ingesteld. Als een regio verloren gaat, stelt Microsoft de back-ups beschikbaar voor klanten. Klanten kunnen herstellen naar een van hun geconfigureerde herstelpunten.
Scheid de gegevensschijf van de besturingssysteemschijf. Een belangrijke overweging voor IaaS-VM's is dat u de besturingssysteemschijf niet kunt wijzigen zonder de VM opnieuw te maken. Dit is geen probleem als uw herstelstrategie is om na een noodgeval opnieuw te implementeren. Het kan echter een probleem zijn als u de Warm Spare-benadering gebruikt om capaciteit te reserveren. Als u dit correct wilt implementeren, moet de juiste besturingssysteemschijf zijn geïmplementeerd op zowel de primaire als secundaire locatie en moeten de toepassingsgegevens op een afzonderlijk station worden opgeslagen. Gebruik indien mogelijk een standaardconfiguratie van het besturingssysteem die op beide locaties kan worden opgegeven. Na een failover moet u het gegevensstation koppelen aan uw bestaande IaaS-VM's in de secundaire domeincontroller. Gebruik AzCopy om momentopnamen van de gegevensschijven naar een externe site te kopiëren.
Houd rekening met mogelijke consistentieproblemen na een geo-failover van meerdere VM-schijven. VM-schijven worden geïmplementeerd als Azure Storage-blobs en hebben hetzelfde geo-replicatiekenmerk. Tenzij Azure Backup wordt gebruikt, zijn er geen garanties voor consistentie tussen schijven, omdat geo-replicatie asynchroon is en onafhankelijk wordt gerepliceerd. Afzonderlijke VM-schijven hebben gegarandeerd een crashconsistente status na een geo-failover, maar niet consistent tussen schijven. Dit kan in sommige gevallen problemen veroorzaken (bijvoorbeeld in het geval van schijfstriping).
Gebruik Azure Site Recovery om toepassingen tussen regio's te repliceren. Met Azure Site Recovery hoeven klanten zich geen zorgen te maken over het scheiden van gegevensschijven van besturingssysteemschijven of over mogelijke consistentieproblemen. Azure Site Recovery repliceert workloads die worden uitgevoerd op fysieke en virtuele machines van een primaire site (on-premises of in Azure) naar een secundaire locatie (in Azure). Wanneer er een storing optreedt op de primaire site van de klant, kan een failover worden geactiveerd om de klant snel terug te brengen naar een operationele status. Nadat de primaire locatie is hersteld, kunnen klanten een failback uitvoeren. Ze kunnen eenvoudig repliceren met behulp van herstelpunten met toepassingsconsistente momentopnamen. Met deze momentopnamen worden schijfgegevens, alle gegevens in het geheugen en alle transacties in het proces vastgelegd. Met Azure Site Recovery kunnen klanten de beoogde hersteltijd (RTO) en RPO (Recovery Point Objectives) binnen de organisatielimieten houden. Klanten kunnen ook eenvoudig noodherstelanalyses uitvoeren zonder dat dit van invloed is op toepassingen in productie. Met behulp van herstelplannen kunnen klanten de failover en het herstel van toepassingen met meerdere lagen die op meerdere VM's worden uitgevoerd, sequentieren. Ze kunnen computers groeperen in een herstelplan en desgewenst scripts en handmatige acties toevoegen. Herstelplannen kunnen worden geïntegreerd met Azure Automation runbooks.

Storage

Herstel met behulp van geografisch redundante opslag van blob-, tabel-, wachtrij- en VM-schijfopslag

In Azure worden blobs, tabellen, wachtrijen en VM-schijven standaard geo-gerepliceerd. Dit wordt geografisch redundante opslag (GRS) genoemd. MET GRS worden opslaggegevens gerepliceerd naar een gekoppeld datacenter dat zich honderden kilometers van elkaar bevindt binnen een specifieke geografische regio. GRS is ontworpen om extra duurzaamheid te bieden in het geval van een groot noodgeval in een datacenter. Microsoft bepaalt wanneer een failover plaatsvindt en failover is beperkt tot grote rampen waarbij de oorspronkelijke primaire locatie binnen een redelijke tijd als onherstelbaar wordt beschouwd. In sommige scenario's kan dit enkele dagen duren. Gegevens worden doorgaans binnen enkele minuten gerepliceerd, hoewel het synchronisatie-interval nog niet wordt gedekt door een serviceovereenkomst.

Als er een geo-failover optreedt, is er geen wijziging in de toegang tot het account (de URL en accountsleutel worden niet gewijzigd). Het opslagaccount bevindt zich echter in een andere regio na een failover. Dit kan van invloed zijn op toepassingen waarvoor regionale affiniteit met hun opslagaccount is vereist. Zelfs voor services en toepassingen waarvoor geen opslagaccount in hetzelfde datacenter is vereist, kunnen de kosten voor latentie en bandbreedte tussen datacenters dwingende redenen zijn om verkeer tijdelijk naar de failoverregio te verplaatsen. Dit kan rekening houden met een algemene strategie voor herstel na noodgevallen.

Naast de automatische failover van GRS heeft Azure een service geïntroduceerd waarmee u leestoegang krijgt tot de kopie van uw gegevens op de secundaire opslaglocatie. Dit wordt geografisch redundante opslag met leestoegang (RA-GRS) genoemd.

Zie Azure Storage-replicatie voor meer informatie over GRS- en RA-GRS-opslag.

Regiotoewijzingen voor geo-replicatie

Het is belangrijk om te weten waar uw gegevens geografisch worden gerepliceerd, zodat u weet waar u de andere exemplaren van uw gegevens moet implementeren waarvoor regionale affiniteit met uw opslag is vereist. Zie Gekoppelde Azure-regio's voor meer informatie.

Prijzen van geo-replicatie

Geo-replicatie is inbegrepen in de huidige prijzen voor Azure Storage. Dit wordt geografisch redundante opslag (GRS) genoemd. Als u niet wilt dat uw gegevens geografisch worden gerepliceerd, kunt u geo-replicatie uitschakelen voor uw account. Dit wordt lokaal redundante opslag (LRS) genoemd en wordt in rekening gebracht tegen een kortingsprijs in vergelijking met GRS.

Bepalen of er een geo-failover is opgetreden

Als er een geo-failover optreedt, wordt deze gepost op het Azure Service Health-dashboard. Toepassingen kunnen echter een geautomatiseerde methode implementeren om dit te detecteren door de geo-regio voor hun opslagaccount te bewaken. Dit kan worden gebruikt om andere herstelbewerkingen te activeren, zoals het activeren van rekenresources in de geografische regio waarnaar de opslag is verplaatst. U kunt hiervoor een query uitvoeren vanuit de servicebeheer-API met behulp van Opslagaccounteigenschappen ophalen. De relevante eigenschappen zijn:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

Database

SQL Database

Azure SQL Database biedt twee soorten herstel: geo-herstel en actieve geo-replicatie.

Geo-herstel

Geo-herstel is ook beschikbaar met Basic-, Standard- en Premium-databases. Het biedt de standaardhersteloptie wanneer de database niet beschikbaar is vanwege een incident in de regio waarin uw database wordt gehost. Net als bij herstel naar een bepaald tijdstip is geo-herstel afhankelijk van databaseback-ups in geografisch redundante Azure-opslag. Het herstelt vanuit de geo-gerepliceerde back-up en is daarom bestand tegen opslagstoringen in de primaire regio. Zie Een Azure SQL database herstellen of failover naar een secundaire database voor meer informatie.

Actieve geo-replicatie

Actieve geo-replicatie is beschikbaar voor alle databaselagen. Het is ontworpen voor toepassingen met agressievere herstelvereisten dan geo-herstel kan bieden. Met actieve geo-replicatie kunt u maximaal vier leesbare secundaire bestanden maken op servers in verschillende regio's. U kunt een failover naar een van de secundaire databases initiëren. Daarnaast kan actieve geo-replicatie worden gebruikt ter ondersteuning van de scenario's voor het upgraden of verplaatsen van toepassingen, evenals taakverdeling voor alleen-lezen workloads. Zie Actieve geo-replicatie configureren voor Azure SQL Database en failover initiëren voor meer informatie. Raadpleeg Wereldwijd beschikbare services ontwerpen met Azure SQL Database en Rolling upgrades van cloudtoepassingen beheren met behulp van SQL Database actieve geo-replicatie voor meer informatie over het ontwerpen en implementeren van toepassingen en toepassingen zonder uitvaltijd.

SQL Server op virtuele machines in Azure

Er zijn verschillende opties beschikbaar voor herstel en hoge beschikbaarheid voor SQL Server 2012 (en hoger) die worden uitgevoerd in Azure Virtual Machines. Zie Hoge beschikbaarheid en herstel na noodgevallen voor SQL Server in Azure Virtual Machines voor meer informatie.

Andere Azure-platformservices

Wanneer u probeert uw cloudservice uit te voeren in meerdere Azure-regio's, moet u rekening houden met de gevolgen voor elk van uw afhankelijkheden. In de volgende secties wordt in de servicespecifieke richtlijnen ervan uitgegaan dat u dezelfde Azure-service moet gebruiken in een alternatief Azure-datacenter. Dit omvat zowel configuratie- als gegevensreplicatietaken.

Notitie

In sommige gevallen kunnen deze stappen helpen om een servicespecifieke storing te beperken in plaats van een hele datacentrumgebeurtenis. Vanuit het perspectief van de toepassing kan een servicespecifieke storing net zo beperkend zijn en moet de service tijdelijk worden gemigreerd naar een alternatieve Azure-regio.

Service Bus

Azure Service Bus maakt gebruik van een unieke naamruimte die geen Azure-regio's omvat. De eerste vereiste is dus het instellen van de benodigde Service Bus-naamruimten in de alternatieve regio. Er zijn echter ook overwegingen voor de duurzaamheid van de berichten in de wachtrij. Er zijn verschillende strategieën voor het repliceren van berichten tussen Azure-regio's. Zie Best practices voor het isoleren van toepassingen tegen Service Bus-storingen en -noodgevallen voor meer informatie over deze replicatiestrategieën en andere strategieën voor herstel na noodgevallen.

App Service

Als u een Azure App Service toepassing, zoals Web Apps of Mobile Apps, wilt migreren naar een secundaire Azure-regio, moet u een back-up van de website beschikbaar hebben voor publicatie. Als de storing niet het hele Azure-datacenter omvat, is het mogelijk om FTP te gebruiken om een recente back-up van de site-inhoud te downloaden. Maak vervolgens een nieuwe app in de alternatieve regio, tenzij u dit eerder hebt gedaan om capaciteit te reserveren. Publiceer de site naar de nieuwe regio en breng de benodigde configuratiewijzigingen aan. Deze wijzigingen kunnen databaseverbindingsreeksen of andere regiospecifieke instellingen omvatten. Voeg indien nodig het SSL-certificaat van de site toe en wijzig de DNS CNAME-record zodat de aangepaste domeinnaam verwijst naar de opnieuw geïmplementeerde Azure Web App-URL.

HDInsight

De gegevens die zijn gekoppeld aan HDInsight, worden standaard opgeslagen in Azure Blob Storage. HDInsight vereist dat een Hadoop-cluster dat MapReduce-taken verwerkt, zich in dezelfde regio bevindt als het opslagaccount dat de gegevens bevat die worden geanalyseerd. Op voorwaarde dat u de functie voor geo-replicatie gebruikt die beschikbaar is voor Azure Storage, hebt u toegang tot uw gegevens in de secundaire regio waar de gegevens zijn gerepliceerd als de primaire regio om een of andere reden niet meer beschikbaar is. U kunt een nieuw Hadoop-cluster maken in de regio waarin de gegevens zijn gerepliceerd en doorgaan met het verwerken ervan.

SQL Reporting

Op dit moment zijn voor het herstellen van het verlies van een Azure-regio meerdere SQL Reporting instanties in verschillende Azure-regio's vereist. Deze SQL Reporting instanties moeten toegang hebben tot dezelfde gegevens en die gegevens moeten een eigen herstelplan hebben in het geval van een noodgeval. U kunt ook externe back-upkopieën van het RDL-bestand voor elk rapport onderhouden.

Media Services

Azure Media Services heeft een andere herstelbenadering voor codering en streaming. Streaming is doorgaans belangrijker tijdens een regionale storing. Om u hierop voor te bereiden, moet u een Media Services-account hebben in twee verschillende Azure-regio's. De gecodeerde inhoud moet zich in beide regio's bevinden. Tijdens een fout kunt u het streamingverkeer omleiden naar de alternatieve regio. Codering kan worden uitgevoerd in elke Azure-regio. Als codering tijdgevoelig is, bijvoorbeeld tijdens het verwerken van livegebeurtenissen, moet u voorbereid zijn om tijdens fouten taken naar een alternatief datacenter te verzenden.

Virtueel netwerk

Configuratiebestanden bieden de snelste manier om een virtueel netwerk in een alternatieve Azure-regio in te stellen. Nadat u het virtuele netwerk in de primaire Azure-regio hebt geconfigureerd, exporteert u de instellingen voor het virtuele netwerk voor het huidige netwerk naar een netwerkconfiguratiebestand. Als er een storing optreedt in de primaire regio, herstelt u het virtuele netwerk vanuit het opgeslagen configuratiebestand. Configureer vervolgens andere cloudservices, virtuele machines of cross-premises instellingen om te werken met het nieuwe virtuele netwerk.
Er zijn VNET-gerelateerde resources waarmee we rekening moeten houden (bijvoorbeeld NSG, DNS, routeringstabellen). De methode die wordt beschreven in Infrastructuur als een code is een manier om elke keer dezelfde omgeving te genereren en u kunt implementeren in een nieuwe regio.

Controlelijsten voor herstel na noodgevallen

controlelijst voor Cloud Services

Bekijk de sectie Cloud Services van dit document.
Maak een strategie voor herstel na noodgevallen voor meerdere regio's.
Inzicht in de afwegingen bij het reserveren van capaciteit in alternatieve regio's.
Gebruik hulpprogramma's voor verkeersroutering, zoals Azure Traffic Manager.

controlelijst voor Virtual Machines

Bekijk de sectie Virtual Machines van dit document.
Gebruik Azure Backup om toepassingsconsistente back-ups te maken in verschillende regio's.

Controlelijst voor opslag

Bekijk de sectie Opslag van dit document.
Schakel geo-replicatie van opslagresources niet uit.
Informatie over alternatieve regio's voor geo-replicatie als er een failover optreedt.
Aangepaste back-upstrategieën maken voor door de gebruiker beheerde failoverstrategieën.

controlelijst voor SQL Database

Bekijk de sectie SQL Database van dit document.
Gebruik geo-herstel of geo-replicatie indien van toepassing.

controlelijst voor Virtual Machines SQL Server

Bekijk de SQL Server in Virtual Machines sectie van dit document.
Gebruik AlwaysOn-beschikbaarheidsgroepen in meerdere regio's of databasespiegeling.
U kunt ook back-ups maken en herstellen naar blob-opslag.

Controlelijst voor Service Bus

Bekijk de sectie Service Bus van dit document.
Configureer een Service Bus-naamruimte in een alternatieve regio.
Overweeg aangepaste replicatiestrategieën voor berichten in verschillende regio's.

controlelijst voor App Service

Bekijk de sectie App Service van dit document.
Back-ups van sites onderhouden buiten de primaire regio.
Als de storing gedeeltelijk is, probeert u de huidige site op te halen met FTP.
Plan de implementatie van de site naar een nieuwe of bestaande site in een alternatieve regio.
Plan configuratiewijzigingen voor zowel toepassings- als DNS CNAME-records.

Controlelijst voor HDInsight

Bekijk de sectie HDInsight van dit document.
Maak een nieuw Hadoop-cluster in de regio met gerepliceerde gegevens.

controlelijst voor SQL Reporting

Bekijk de sectie SQL Reporting van dit document.
Onderhoud een alternatief SQL Reporting-exemplaar in een andere regio.
Onderhoud een afzonderlijk plan om het doel naar die regio te repliceren.

Controlelijst voor Media Services

Bekijk de sectie Media Services van dit document.
Maak een Media Services-account in een alternatieve regio.
Codeer dezelfde inhoud in beide regio's ter ondersteuning van streamingfailover.
Verzend coderingstaken naar een alternatieve regio als er een serviceonderbreking optreedt.

controlelijst voor Virtual Network

Bekijk de sectie Virtual Network van dit document.
Gebruik geëxporteerde virtuele netwerkinstellingen om deze opnieuw te maken in een andere regio.