Herstel na een serviceonderbreking in de gehele regio

Artikel
05/25/2024

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

Onder zeldzame omstandigheden is het mogelijk dat faciliteiten in een hele beschikbaarheidszone of regio ontoegankelijk kunnen worden, bijvoorbeeld vanwege netwerkfouten. Of faciliteiten kunnen volledig verloren gaan, bijvoorbeeld vanwege 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 één zone of regio van invloed kan zijn op andere zones of regio's.

Cloudservices

Resourcebeheer

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

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

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 het verdelen van verkeer tussen regio's is een oplossing voor verkeersbeheer vereist. Azure biedt Azure Traffic Manager. U kunt ook profiteren van services van derden die vergelijkbare mogelijkheden voor verkeersbeheer bieden.

Strategieën

Er zijn veel alternatieve strategieën beschikbaar voor het implementeren van gedistribueerde rekenkracht in verschillende 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 noodgeval: Bij deze benadering wordt de toepassing opnieuw geïmplementeerd op het moment van noodgeval. Dit is geschikt voor niet-kritieke toepassingen waarvoor geen gegarandeerde hersteltijd is vereist.
Warme reserve (actief/passief): er wordt een secundaire gehoste service gemaakt in een alternatieve regio en rollen worden geïmplementeerd om minimale capaciteit te garanderen. De rollen ontvangen echter geen productieverkeer. Deze aanpak is handig voor toepassingen die niet zijn ontworpen om verkeer over 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 vereist is voor herstel na noodgevallen. De cloudservices kunnen ook zo nodig worden uitgeschaald op het moment van een noodgeval en failover. Deze aanpak vereist aanzienlijke investeringen in het toepassingsontwerp, maar heeft aanzienlijke voordelen. Deze omvatten lage en gegarandeerde hersteltijd, continue tests 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-toepassing s voor meer informatie.

Virtuele machines

Herstel van iaaS-VM's (Infrastructure as a Service) is vergelijkbaar met PaaS-rekenherstel (Platform as a Service). Er zijn echter belangrijke verschillen, omdat een IaaS-VM bestaat uit zowel de VM als de VM-schijf.

Gebruik Azure Backup om back-ups voor meerdere regio's te maken die toepassingsconsistent zijn. Met Azure Backup kunnen klanten toepassingsconsistente back-ups maken op meerdere VM-schijven en ondersteuning bieden voor replicatie van back-ups in verschillende regio's. U kunt dit doen door ervoor te kiezen om de back-upkluis te repliceren op het moment van maken. De replicatie van de back-upkluis moet worden geconfigureerd op het moment van maken. Het kan later niet worden ingesteld. Als een regio verloren gaat, maakt 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 VIRTUELE machine opnieuw te maken. Dit is geen probleem als uw herstelstrategie na een noodgeval opnieuw moet worden geïmplementeerd. Het kan echter een probleem zijn als u de methode Warm Spare gebruikt om capaciteit te reserveren. Als u dit correct wilt implementeren, moet de juiste besturingssysteemschijf zijn geïmplementeerd op zowel de primaire als de secundaire locaties en moeten de toepassingsgegevens op een afzonderlijk station worden opgeslagen. Gebruik indien mogelijk een standaardconfiguratie van het besturingssysteem die op beide locaties kan worden geleverd. Na een failover moet u het gegevensstation koppelen aan uw bestaande IaaS-VM's in de secundaire DC. 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 kenmerk voor geo-replicatie. 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 op schijven. Dit kan in sommige gevallen problemen veroorzaken (bijvoorbeeld in het geval van schijfstriping).
Gebruik Azure Site Recovery om toepassingen in verschillende 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 vanaf 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 keren naar een operationele status. Nadat de primaire locatie is hersteld, kunnen klanten vervolgens een failback uitvoeren. Ze kunnen eenvoudig repliceren met behulp van herstelpunten met toepassingsconsistente momentopnamen. Met deze momentopnamen worden schijfgegevens, alle in-memory gegevens en alle in-process transacties vastgelegd. Met Azure Site Recovery kunnen klanten hersteltijddoelstellingen (RTO) en beoogde herstelpunten (RPO) 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 machines groeperen in een herstelplan en eventueel 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 zijn blobs, tabellen, wachtrijen en VM-schijven standaard allemaal geografisch gerepliceerd. Dit wordt aangeduid als geografisch redundante opslag (GRS). GRS repliceert opslaggegevens naar een gekoppeld datacenter dat honderden kilometers uit elkaar ligt binnen een specifieke geografische regio. GRS is ontworpen om extra duurzaamheid te bieden voor het geval er zich een grote datacenterramp voordoet. Microsoft bepaalt wanneer de 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 een paar minuten gerepliceerd, hoewel het synchronisatie-interval nog niet wordt gedekt door een service level agreement.

Als er een geo-failover optreedt, verandert er geen wijziging in hoe het account wordt geopend (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, kan de latentie tussen datacenters aantrekkelijke redenen zijn om verkeer tijdelijk naar de failoverregio te verplaatsen. Dit kan rekening houden met een algemene strategie voor herstel na noodgevallen.

Naast 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 zowel GRS- als RA-GRS-opslag.

Regiotoewijzingen voor geo-replicatie

Het is belangrijk om te weten waar uw gegevens geografisch worden gerepliceerd om te weten waar de andere exemplaren van uw gegevens moeten worden geïmplementeerd waarvoor regionale affiniteit met uw opslag is vereist. Zie Gekoppelde Azure-regio's voor meer informatie.

Prijzen van geo-replicatie

Geo-replicatie is opgenomen 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 gereduceerde prijs vergeleken met GRS.

Bepalen of er een geo-failover is opgetreden

Als er een geo-failover optreedt, wordt dit geplaatst op het Azure Service Health-dashboard. Toepassingen kunnen echter een geautomatiseerde detectiewijze implementeren door de geografische regio voor hun opslagaccount te bewaken. Dit kan worden gebruikt om andere herstelbewerkingen te activeren, zoals de activering van rekenresources in de geografische regio waarnaar de opslag is verplaatst.

Database

SQL Database

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

Geo-herstel

Geo-herstel is ook beschikbaar voor Basic-, Standard- en Premium-databases. Het biedt de standaardhersteloptie wanneer de database niet beschikbaar is vanwege een incident in de regio waar 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 geografisch gerepliceerde back-upkopie en is daarom tolerant voor de opslagstoringen in de primaire regio. Zie Een Azure SQL Database herstellen of failover naar een secundaire database herstellen voor meer informatie.

Actieve geo-replicatie

Actieve geo-replicatie is beschikbaar voor alle databaselagen. Het is ontworpen voor toepassingen die agressievere herstelvereisten hebben dan geo-herstel kan bieden. Met actieve geo-replicatie kunt u maximaal vier leesbare secundaire 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 toepassingsupgrade- of herlocatiescenario's, evenals taakverdeling voor alleen-lezen workloads. Zie Actieve geo-replicatie configureren voor Azure SQL Database en failover initiëren voor meer informatie. Raadpleeg Het ontwerpen van wereldwijd beschikbare services met behulp van Azure SQL Database en het beheren van rolling upgrades van cloudtoepassingen met behulp van actieve geo-replicatie van SQL Database 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 virtuele Azure-machines. Zie Voor meer informatie hoge beschikbaarheid en herstel na noodgevallen voor SQL Server in Azure Virtual Machines.

Andere Azure-platformservices

Wanneer u uw cloudservice probeert 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 in een alternatief Azure-datacenter moet gebruiken. Dit omvat zowel configuratie- als gegevensreplicatietaken.

Notitie

In sommige gevallen kunnen deze stappen helpen bij het beperken van een servicespecifieke storing in plaats van een hele datacentergebeurtenis. Vanuit het perspectief van de toepassing is een servicespecifieke storing mogelijk net zo beperkt 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 in 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 hebben die beschikbaar is voor publicatie. Als de storing niet betrekking heeft op het hele Azure-datacenter, is het mogelijk 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 eventueel benodigde configuratiewijzigingen aan. Deze wijzigingen kunnen database-verbindingsreeks s of andere regiospecifieke instellingen bevatten. 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 URL van de Azure-web-app.

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 moet bevinden 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 waar de gegevens zijn gerepliceerd en deze blijven verwerken.

SQL Reporting

Op dit moment vereist het herstellen van het verlies van een Azure-regio meerdere SQL-rapportage-exemplaren in verschillende Azure-regio's. Deze SQL-rapportage-exemplaren 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 dit voor te bereiden, moet u een Media Services-account in twee verschillende Azure-regio's hebben. 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 bereid zijn taken in te dienen bij een alternatief datacenter tijdens storingen.

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 van 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 met het nieuwe virtuele netwerk te werken.
Er zijn VNET-gerelateerde resources waarmee we rekening moeten houden (bijvoorbeeld NSG, DNS, routetabellen). De methode die in Infrastructuur als code wordt beschreven, is een manier om elke keer dezelfde omgeving te genereren en u kunt in een nieuwe regio implementeren.

Controlelijsten voor herstel na noodgevallen

Controlelijst voor Cloud Services

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

Controlelijst voor virtuele machines

Bekijk de sectie Virtuele machines van dit document.
Gebruik Azure Backup om toepassingsconsistente back-ups te maken tussen regio's.

Controlelijst voor opslag

Bekijk de sectie Opslag van dit document.
Schakel geo-replicatie van opslagresources niet uit.
Meer informatie over alternatieve regio's voor geo-replicatie als er een failover plaatsvindt.
Maak aangepaste back-upstrategieën 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 SQL Server op virtuele machines

Raadpleeg de sectie SQL Server op virtuele machines van dit document.
Gebruik AlwaysOn-beschikbaarheidsgroepen of databasespiegeling in meerdere regio's.
U kunt ook back-up en herstel naar blobopslag gebruiken.

Service Bus-controlelijst

Bekijk de Service Bus-sectie 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.
Siteback-ups buiten de primaire regio onderhouden.
Als de storing gedeeltelijk is, probeert u de huidige site op te halen met FTP.
Plan de site te implementeren op een nieuwe of bestaande site in een alternatieve regio.
Plan configuratiewijzigingen voor zowel toepassings- als DNS CNAME-records.

Controlelijst voor HDInsight

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

Controlelijst voor SQL-rapportage

Bekijk de sectie SQL-rapportage van dit document.
Onderhoud een alternatief SQL-rapportage-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 om streamingfailover te ondersteunen.
Verzend coderingstaken naar een alternatieve regio als er een serviceonderbreking optreedt.

Controlelijst voor virtueel netwerk

Bekijk de sectie Virtual Network van dit document.
Gebruik geëxporteerde instellingen voor het virtuele netwerk om het opnieuw te maken in een andere regio.

Delen via