Herstel na noodgevallen voor virtuele Azure Stack Hub-machines

In dit artikel worden de architectuur- en ontwerpoverwegingen beschreven van een oplossing die een geoptimaliseerde benadering biedt voor het herstel na noodgevallen van workloads die worden uitgevoerd op virtuele machines (VM's) die worden gehost in Azure Stack Hub.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Workflow

De cloudonderdelen van de voorgestelde oplossing omvatten de volgende services:

• Een Azure-abonnement dat als host fungeert voor alle cloudresources die deel uitmaken van deze oplossing.

• Een Microsoft Entra ID-tenant die is gekoppeld aan het Azure-abonnement dat verificatie biedt van Microsoft Entra-beveiligingsprinciplen om toegang tot Azure-resources te autoriseren.

• Een Azure Recovery Services-kluis in de Azure-regio die zich het dichtst bij een on-premises datacenter bevindt waarop de Azure Stack Hub-implementatie wordt gehost.

  Notitie

  De keuze van de Azure-regio die zich het dichtst bij het on-premises datacenter bevindt, is specifiek voor het voorbeeldscenario dat in dit artikel is opgenomen. Vanuit het oogpunt van herstel na noodgevallen is het beter om een Azure-regio te selecteren die zich verder van de locatie bevindt waarop de productieomgeving wordt gehost. De beslissing kan echter afhankelijk zijn van andere factoren, zoals de noodzaak om de latentie van regionale gegevensfeeds te minimaliseren of om te voldoen aan de vereisten voor gegevenslocatie.

• Een Azure ExpressRoute-circuit dat de on-premises datacenters verbindt met de Azure-regio die als host fungeert voor de Azure Recovery Services-kluis, geconfigureerd met persoonlijke peering en Microsoft-peering. De eerste zorgt ervoor dat aan latentievereisten wordt voldaan na een failover. Het doel van deze laatste is om de hoeveelheid tijd die nodig is om wijzigingen tussen de on-premises workloads en de failoversite in Azure te repliceren, te minimaliseren.

• Een Azure Storage-account met blobs die de VHD-bestanden bevatten die zijn gemaakt door replicatie van het besturingssysteem en gegevensvolumes van beveiligde Azure Stack Hub-VM's. Deze VHD-bestanden fungeren als de bron voor de beheerde schijven van Azure-VM's die automatisch worden ingericht na een failover.

• Een virtueel Azure-netwerk dat als host fungeert voor de omgeving voor herstel na noodgevallen. Het is geconfigureerd op een manier die de omgeving van het virtuele netwerk in de Azure Stack Hub weerspiegelt die als host fungeert voor de productieworkloads, inclusief onderdelen zoals load balancers en netwerkbeveiligingsgroepen. Dit virtuele netwerk is doorgaans verbonden met het virtuele Azure Stack Hub-netwerk via een ExpressRoute-verbinding om herstel op workloadniveau te vergemakkelijken.

  Notitie

  Soms volstaat een site-naar-site-VPN-verbinding in scenario's waarin RPO-vereisten (Recovery Point Objective) minder streng zijn.

• Een geïsoleerd virtueel Azure-netwerk dat is bedoeld voor testfailovers, geconfigureerd op een manier die de omgeving van het virtuele netwerk in Azure Stack Hub weerspiegelt die als host fungeert voor de productieworkloads, inclusief onderdelen zoals load balancers en netwerkbeveiligingsgroepen.

De on-premises onderdelen van de voorgestelde oplossing omvatten de volgende services:

• Een geïntegreerd Azure Stack Hub-systeem in het verbonden implementatiemodel. Het systeem voert de huidige update (2002 vanaf 9/20) uit en bevindt zich in het on-premises datacenter van de klant.

• Een Azure Stack Hub-abonnement en een virtueel netwerk, of meerdere gekoppelde virtuele netwerken, die als host fungeert voor alle on-premises VM's voor deze oplossing.

• Azure Site Recovery-configuratie- en processervers die worden uitgevoerd op Virtuele Machines van Windows Server 2016 of 2012 R2 Azure Hub Stack. De servers beheren communicatie met de Azure Recovery Services-kluis en de routering, optimalisatie en versleuteling van replicatieverkeer.

  Notitie

  Standaard fungeert een configuratieserver als host voor één processerver. U kunt toegewezen processervers implementeren voor een groter volume replicatieverkeer.

• De Azure Stack Hub-VM's die moeten worden beveiligd. Ze voeren ondersteunde versies van de besturingssystemen Windows Server, CentOS en Ubuntu uit.

• De Site Recovery-Mobility-service (ook wel mobiliteitsagent genoemd) die wordt uitgevoerd op beveiligde VM's. Hiermee worden wijzigingen in lokale schijven bijgehouden, worden de wijzigingen in replicatielogboeken vastgelegd en worden de logboeken gerepliceerd naar de processerver. De processerver stuurt deze naar het Azure-doelopslagaccount. De logboeken worden gebruikt om herstelpunten te maken voor beheerde schijven die worden geïmplementeerd met behulp van blobs die zijn opgeslagen in het Azure-opslagaccount dat u aanwijst.

Onderdelen

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob-opslag
• Azure Stack Hub

Alternatieven

De aanbevolen oplossing die in dit artikel wordt beschreven, is niet de enige manier om functionaliteit voor herstel na noodgevallen te bieden voor azure Stack Hub VM-workloads. Klanten hebben andere opties, waaronder:

• Een failover naar een andere Azure Stack Hub-zegel. Gebruikers die moeten beveiligen tegen een storing in een datacenter of site, kunnen mogelijk een andere Azure Stack Hub-implementatie gebruiken om voorzieningen voor herstel na noodgevallen te implementeren. Met primaire en secundaire locaties kunnen gebruikers toepassingen implementeren in een actieve/passieve configuratie in twee omgevingen. Voor minder kritieke workloads is het mogelijk acceptabel om ongebruikte capaciteit op de secundaire locatie te gebruiken om toepassingen op aanvraag te herstellen van back-ups. U kunt ook een herstelsite implementeren in een ander datacenter, dat op zijn beurt Site Recovery gebruikt voor het inrichten van een replica van de herstelsite in Azure. Verschillende factoren bepalen of het gebruik van Site Recovery met Azure fungeert als failoversite een haalbare oplossing is. Deze factoren omvatten overheidsvoorschriften, bedrijfsbeleid en latentievereisten.

  Notitie

  Vanaf juli 2020 biedt Site Recovery geen ondersteuning voor dit scenario, wat betekent dat de implementatie een partner of interne oplossing moet gebruiken.

• Maak een back-up en herstel. Als u een back-up maakt van uw toepassingen en gegevenssets, kunt u snel herstellen van downtime die het gevolg is van beschadiging van gegevens, onbedoelde verwijderingen of gelokaliseerde storingen. Voor azure Stack Hub VM-toepassingen kunt u een in-guest agent gebruiken om toepassingsgegevens, configuraties van het besturingssysteem en gegevens die zijn opgeslagen op volumes te beveiligen. Het maken van een back-up van een VIRTUELE machine met behulp van een gastbesturingssysteemagent omvat doorgaans het vastleggen van besturingssysteemconfiguraties, bestanden, mappen, volumes, binaire toepassingsbestanden en toepassingsgegevens. Voor het herstellen van een toepassing van een agent is recreatie van de VM vereist, gevolgd door de installatie van het besturingssysteem en de gastagent. Op dat moment kunt u gegevens herstellen in het gastbesturingssystemen.

• Back-up van momentopnamen van schijven. Het is mogelijk om momentopnamen te gebruiken om een Azure Stack Hub VM-configuratie vast te leggen en de schijven die zijn gekoppeld aan een gestopte VM. Voor dit proces zijn back-upproducten vereist die kunnen worden geïntegreerd met Azure Stack Hub-API's om vm-configuratie vast te leggen en momentopnamen van schijven te maken.

  Notitie

  Vanaf juli 2020 wordt het gebruik van schijfmomentopnamen voor een actieve VM niet ondersteund. Het maken van een momentopname van een schijf die is gekoppeld aan een actieve VM kan de prestaties verminderen of de beschikbaarheid van het besturingssysteem of van de toepassing in de VIRTUELE machine beïnvloeden.

• Maak een back-up van vm's en herstel deze met behulp van een externe back-upoplossing in hetzelfde datacenter en repliceer de back-ups vervolgens naar een andere locatie. Op deze manier kunt u azure Stack Hub-VM's herstellen naar hetzelfde Azure Stack Hub-exemplaar of naar een ander exemplaar of naar Azure.

Scenariodetails

Azure Stack Hub bevat zelfherstelfunctionaliteit, waardoor automatisch herstel mogelijk is in een reeks scenario's waarbij gelokaliseerde fouten van de onderdelen zijn betrokken. Grootschalige fouten, waaronder storingen die van invloed zijn op serverrekken of rampen op siteniveau, vereisen echter aanvullende overwegingen. Deze overwegingen moeten deel uitmaken van de strategie voor bedrijfscontinuïteit en herstel na noodgevallen voor op VM's gebaseerde gebruikersworkloads. Deze strategie moet ook rekening houden met het herstel van de Azure Stack-infrastructuur, die losstaat van het herstel van workloads.

Traditionele hersteloplossingen voor on-premises workloads zijn complex om te configureren, duur en arbeidsintensief te onderhouden en moeilijk te automatiseren, met name wanneer u een andere on-premises locatie als failoversite gebruikt. Microsoft raadt een alternatieve oplossing aan die afhankelijk is van een combinatie van cloud- en on-premises onderdelen om robuuste, op prestaties gebaseerde, zeer geautomatiseerde en eenvoudige manieren te bieden om een kostenefficiënte strategie voor herstel na noodgevallen te implementeren, beveiligen en beheren. Het belangrijkste element van deze oplossing is Site Recovery, waarbij de failoversite zich in Azure bevindt.

Potentiële gebruikscases

Site Recovery met Azure als failoversite elimineert alle bovengenoemde nadelen. U kunt de mogelijkheden ervan gebruiken om zowel fysieke als virtuele servers te beveiligen, inclusief servers die worden uitgevoerd op Microsoft Hyper-V- of VMware ESXi-virtualisatieplatforms. U kunt ook dezelfde mogelijkheden gebruiken om het herstel van workloads die worden uitgevoerd op azure Stack Hub-VM's te vergemakkelijken.

Kernfunctionaliteit

Site Recovery is een oplossing voor herstel na noodgevallen die de beveiliging van fysieke en virtuele computers mogelijk maakt door twee sets functies te bieden:

• Replicatie van wijzigingen in computerschijven die zich tussen de productie- en herstellocaties na noodgevallen bevinden
• Indeling van failover en failback tussen deze twee locaties

Site Recovery biedt drie typen failovers:

• Test de failover. Deze failover biedt u de mogelijkheid om uw Site Recovery-configuratie te valideren in een geïsoleerde omgeving, zonder gegevensverlies of impact op de productieomgeving.
• Geplande failover. Deze failover biedt u de mogelijkheid om herstel na noodgevallen te starten zonder gegevensverlies, meestal als onderdeel van geplande downtime.
• Niet-geplande failover. Deze failover fungeert als laatste redmiddel in het geval van een niet-geplande storing die van invloed is op de beschikbaarheid van de primaire site en mogelijk leidt tot gegevensverlies.

Site Recovery ondersteunt verschillende scenario's, zoals failover en failback tussen twee on-premises sites, failover en failback tussen twee Azure-regio's en migratie van clouds van externe providers. In de context van dit artikel ligt de focus echter op replicatie van lokale schijven van Azure Stack Hub-VM's naar Azure Storage, en op VM-failover en failback tussen een Azure Stack Hub-stack en een Azure-regio.

Details van de Site Recovery-architectuur en de bijbehorende onderdelen zijn afhankelijk van een aantal criteria, waaronder:

• De typen computers die moeten worden beveiligd (fysiek versus virtueel).
• Voor gevirtualiseerde omgevingen is het type hypervisor dat als host fungeert voor de virtuele machines die moeten worden beveiligd (Hyper-V versus VMware ESXi).
• Voor Hyper-V-omgevingen gebruikt u System Center Virtual Machine Manager (SCVMM) voor het beheer van Hyper-V-hosts.

Met Azure Stack Hub komt de architectuur overeen met de architectuur die van toepassing is op fysieke computers. Dit is niet bijzonder verrassend, omdat Site Recovery in beide gevallen niet kan profiteren van directe toegang tot een hypervisor. In plaats daarvan wordt het mechanisme waarmee wijzigingen in lokale schijven worden bijgehouden en gerepliceerd, geïmplementeerd in het beveiligde besturingssysteem.

Om dit te bereiken, is Site Recovery afhankelijk van de Site Recovery-Mobility-service (ook wel mobiliteitsagent genoemd), die automatisch wordt geïmplementeerd op afzonderlijke VM's terwijl u ze inschrijft voor het bereik van op Site Recovery gebaseerde beveiliging. Op elke beveiligde VM controleert en stuurt het lokaal geïnstalleerde exemplaar van de mobility-agent voortdurend wijzigingen in het besturingssysteem en de gegevensschijven door naar de processerver. Site Recovery implementeert echter een extra set onderdelen die worden uitgevoerd op een afzonderlijke VIRTUELE machine, ook wel de configuratieserver genoemd, om de stroom van replicatieverkeer te optimaliseren en te beheren dat afkomstig is van beveiligde VM's.

De configuratieserver coördineert de communicatie met de Site Recovery-kluis en beheert de gegevensreplicatie. Bovendien fungeert de configuratieserver als host voor een onderdeel dat wordt aangeduid als de processerver, die fungeert als een gateway, replicatiegegevens ontvangt, deze optimaliseert via caching en compressie, versleutelt het en ten slotte doorstuurt naar Azure Storage. In feite fungeert de configuratieserver als het integratiepunt tussen Site Recovery en beveiligde VM's die worden uitgevoerd op Azure Stack Hub. U implementeert deze integratie door de configuratieserver te implementeren en te registreren bij de Azure Recovery Services-kluis.

Als onderdeel van de Site Recovery-configuratie definieert u de beoogde omgeving voor herstel na noodgevallen, waaronder infrastructuuronderdelen zoals virtuele netwerken, load balancers of netwerkbeveiligingsgroepen op de manier die de productieomgeving spiegelt. De configuratie bevat ook een replicatiebeleid, dat herstelmogelijkheden bepaalt en bestaat uit de volgende parameters:

• RPO-drempelwaarde. Deze instelling vertegenwoordigt de gewenste herstelpuntdoelstelling die u wilt implementeren en bepaalt de frequentie waarin Site Recovery crashconsistente momentopnamen van herstelpunten genereert. De waarde heeft geen invloed op de replicatiefrequentie omdat deze replicatie continu is. Site Recovery genereert een waarschuwing en eventueel een e-mailmelding als de huidige effectieve RPO van Site Recovery de drempelwaarde overschrijdt die u opgeeft. Site Recovery genereert om de vijf minuten crashconsistente herstelpuntmomentopnamen.

  Notitie

  Een crashconsistente momentopname legt gegevens vast die zich op de schijf bevinden toen de momentopname werd gemaakt. Het bevat geen geheugeninhoud. In feite garandeert een crashconsistente momentopname geen gegevensconsistentie voor het besturingssysteem of lokaal geïnstalleerde apps.

• Bewaarperiode van herstelpunt. Deze instelling vertegenwoordigt de duur (in uren) van het bewaarvenster voor elke momentopname van het herstelpunt. Beveiligde VM's kunnen worden hersteld naar elk herstelpunt in een bewaarvenster. Site Recovery ondersteunt maximaal 24 uur retentie voor VM's die zijn gerepliceerd naar Azure Storage-accounts met de premium-prestatielaag. Er is een retentielimiet van 72 uur bij het gebruik van Azure Storage-accounts met de standard-prestatielaag.

• Frequentie van app-consistente momentopnamen. Deze instelling bepaalt de frequentie (in uren) waarin Site Recovery toepassingsconsistente momentopnamen genereert. Een app-consistente momentopname vertegenwoordigt een momentopname van toepassingen die worden uitgevoerd op een beveiligde VM. Er geldt een limiet van 12 app-consistente momentopnamen. Voor VM's met Windows Server gebruikt Site Recovery Volume Shadow Copy Service (VSS). Site Recovery biedt ook ondersteuning voor app-consistente momentopnamen voor Linux, maar hiervoor moeten aangepaste scripts worden geïmplementeerd. De scripts worden door de Mobility-agent gebruikt bij het toepassen van een app-consistente momentopname.

  Notitie

  Raadpleeg algemene vragen over Site Recovery voor meer informatie over het implementeren van app-consistente momentopnamen op Azure Stack Hub-VM's waarop Linux wordt uitgevoerd.

Voor elke schijf van een beveiligde Azure Stack Hub-VM die u aanwijst, worden gegevens gerepliceerd naar een bijbehorende beheerde schijf in Azure Storage. De schijf slaat de kopie van de bronschijf en alle crash-consistente en app-consistente momentopnamen van het herstelpunt op. Als onderdeel van een failover kiest u een crash-consistent herstelpunt of app-consistente momentopname die moet worden gebruikt bij het koppelen van de beheerde schijf aan de Azure-VM, die fungeert als een replica van de beveiligde Azure Stack Hub-VM.

Tijdens normale bedrijfsactiviteiten worden beveiligde workloads uitgevoerd op Azure Stack Hub-VM's, waarbij wijzigingen in hun schijven continu worden gerepliceerd via interacties tussen de mobility-agent, processerver en configuratieserver naar het aangewezen Azure Storage-account. Wanneer u een test, geplande of ongeplande failover start, richt Site Recovery automatisch Azure-VM's in met behulp van de replica's van schijven van de bijbehorende Azure Stack Hub-VM's.

U kunt een failover organiseren door herstelplannen te maken die handmatige en geautomatiseerde stappen bevatten. Als u dit laatste wilt implementeren, kunt u Azure Automation-runbooks gebruiken, die bestaan uit aangepaste PowerShell-scripts, PowerShell-werkstromen of Python 2-scripts.

Nadat de primaire site weer beschikbaar is, ondersteunt Site Recovery het omkeren van de richting van replicatie, zodat u een failback kunt uitvoeren met minimale downtime en zonder gegevensverlies. Met Azure Stack Hub is deze benadering echter niet beschikbaar. Als u een failback wilt uitvoeren, moet u Azure VM-schijfbestanden downloaden, uploaden naar Azure Stack Hub en deze koppelen aan bestaande of nieuwe VM's.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Azure Stack Hub helpt de beschikbaarheid van workloads te verhogen via tolerantie die inherent is aan de infrastructuur. Deze tolerantie biedt hoge beschikbaarheid voor Azure Stack Hub-VM's die worden beveiligd door Site Recovery en essentiële onderdelen van de on-premises Site Recovery-infrastructuur, waaronder de configuratie- en processervers.

Op dezelfde manier hebt u de mogelijkheid om tolerantie te gebruiken van cloudonderdelen van de Site Recovery-infrastructuur. Azure Recovery Services is standaard geografisch redundant, wat betekent dat de configuratie automatisch wordt gerepliceerd naar een Azure-regio die deel uitmaakt van een vooraf gedefinieerd regiopaar. U kunt de replicatie-instellingen wijzigen in lokaal redundant als dat voldoende is voor uw tolerantiebehoeften. Houd er rekening mee dat u deze optie niet kunt wijzigen als de kluis beveiligde items bevat. Dezelfde tolerantieoptie is beschikbaar voor alle Azure Storage-accounts met de standaardprestatielaag, hoewel het op elk moment mogelijk is om deze te wijzigen.

U kunt de mate van deze tolerantie verder verbeteren door oplossingen te ontwerpen en te implementeren die het bereik van workloadbeveiliging uitbreiden. Dit is de toegevoegde waarde van Site Recovery. In de context van Site Recovery die wordt uitgevoerd op Azure Stack Hub, zijn er twee belangrijke aspecten van de beschikbaarheid van workloads die in meer detail moeten worden verkend:

• Failover naar Azure
• Failback naar Azure Stack Hub

U moet rekening houden met het ontwikkelen van een strategie voor herstel na noodgevallen, gebaseerd op beoogde herstelpunten (RPO's) en beoogde hersteltijd (RPO's). RTO en RPO vertegenwoordigen continuïteitsvereisten die zijn bepaald door afzonderlijke bedrijfsfuncties binnen een organisatie. RPO wijst een periode aan die het maximale acceptabele gegevensverlies vertegenwoordigt na een incident dat de beschikbaarheid van die gegevens heeft beïnvloed. RTO wijst de maximaal acceptabele tijdsduur aan die nodig is om bedrijfsfuncties opnieuw in te stellen na een incident dat de beschikbaarheid van deze functies heeft beïnvloed.

Failover naar Azure

Failover naar Azure vormt de kern van overwegingen voor beschikbaarheid in de context van site recovery-gebaseerde beveiliging van azure Stack Hub-VM's. Om de beschikbaarheid van workloads te maximaliseren, moet de failoverstrategie zowel de noodzaak aanpakken om mogelijk gegevensverlies (RPO) te minimaliseren en de failovertijd (RTO) te minimaliseren.

Als u mogelijk gegevensverlies wilt minimaliseren, kunt u het volgende overwegen:

• De doorvoer maximaliseren en latentie van het replicatieverkeer minimaliseren door rekening te houden met schaalbaarheid en prestatieoverwegingen. Raadpleeg de volgende sectie van dit artikel voor meer informatie.
• Verhoog de frequentie van app-consistente herstelpunten voor databaseworkloads (maximaal één herstelpunt per uur). App-consistente herstelpunten worden gemaakt op basis van app-consistente momentopnamen. App-consistente momentopnamen leggen app-gegevens vast op schijf en in het geheugen. Hoewel deze aanpak potentiële gegevensverlies minimaliseert, heeft deze een belangrijk nadeel. App-consistente momentopnamen vereisen het gebruik van Volume Shadow Copy Service in Windows of aangepaste scripts in Linux om lokaal geïnstalleerde apps stil te zetten. Het opnameproces kan de prestaties schaden, met name als het resourcegebruik hoog is. Het is niet raadzaam om lage frequentie te gebruiken voor app-consistente momentopnamen voor niet-databaseworkloads.

De primaire methode voor het minimaliseren van de failovertijd omvat het gebruik van Site Recovery-herstelplannen. Een herstelplan organiseert een failover tussen de primaire en secundaire sites en definieert de volgorde waarin beveiligde servers een failover uitvoeren. U kunt een plan aanpassen door handmatige instructies en geautomatiseerde taken toe te voegen. Het doel is om het proces consistent, nauwkeurig, herhaalbaar en geautomatiseerd te maken.

Wanneer u een herstelplan maakt, wijst u beveiligde servers toe aan herstelgroepen voor failover. Servers in elke groep voeren een failover uit. Dit helpt u om het failoverproces te verdelen in kleinere, eenvoudiger te beheren eenheden, die sets servers vertegenwoordigen die een failover kunnen uitvoeren zonder afhankelijk te zijn van externe afhankelijkheden.

Als u de failovertijd wilt minimaliseren, moet u het volgende doen als onderdeel van het maken van een herstelplan:

• Definieer groepen azure Stack Hub-VM's waarvoor een failover moet worden uitgevoerd.
• Definieer afhankelijkheden tussen groepen azure Stack Hub-VM's om de optimale volgorde van een failover te bepalen.
• Automatiseer indien mogelijk failovertaken.
• Voeg indien nodig aangepaste handmatige acties toe.

U definieert een herstelplan en maakt herstelgroepen om app-specifieke eigenschappen vast te leggen. Laten we eens kijken naar een traditionele app met drie lagen met een back-end op basis van SQL Server, een middlewareonderdeel en een webfront-end. Wanneer u een herstelplan maakt, kunt u de opstartvolgorde van servers in elke laag beheren, waarbij de servers waarop SQL Server-exemplaren worden uitgevoerd eerst online komen, gevolgd door die in de middleware-laag en daarna worden toegevoegd door servers die als host fungeren voor de webfront-end. Deze volgorde zorgt ervoor dat de app werkt op het moment dat de laatste server wordt gestart. Als u dit wilt implementeren, kunt u gewoon een herstelplan maken met drie herstelgroepen, met servers in de respectieve lagen.

Naast het beheren van de failover- en opstartvolgorde hebt u ook de mogelijkheid om acties toe te voegen aan een herstelplan. Over het algemeen zijn er twee soorten acties:

• Geautomatiseerde. Deze actie is gebaseerd op Azure Automation-runbooks, waarbij een van de volgende twee typen taken is vereist:
  • Azure-resources inrichten en configureren, zoals het maken van een openbaar IP-adres en het koppelen aan de netwerkinterface die is gekoppeld aan een Azure-VM.
  • Het wijzigen van de configuratie van het besturingssysteem en de toepassingen die worden uitgevoerd binnen een Azure-VM die is ingericht na een failover.
• Handmatig. Deze actie biedt geen ondersteuning voor automatisering en wordt voornamelijk opgenomen in een herstelplan voor documentatiedoeleinden.

Failback naar Azure Stack Hub

In scenario's op basis van Site Recovery is failback, indien correct geïmplementeerd, geen gegevensverlies betrokken. Dit betekent dat de focus van de failoverstrategie is om de failbacktijd (RTO) te minimaliseren. Zoals eerder vermeld, kunt u echter niet vertrouwen op uw herstelplannen wanneer u een failback naar Azure Stack Hub uitvoert. In plaats daarvan omvat de failback de volgende reeks stappen:

1. Stop en maak de toewijzing van Virtuele Azure-machines ongedaan in de omgeving voor herstel na noodgevallen.
2. Identificeer de URI-parameter van elk van de beheerde schijven die zijn gekoppeld aan de VM's die u wilt downloaden.
3. Download de VHD-bestanden (virtuele harde schijf) die zijn geïdentificeerd door de URI-parameters die u in de vorige stap hebt geïdentificeerd naar uw on-premises omgeving.
4. Upload de VHD-bestanden naar Azure Stack Hub.
5. Koppel de geüploade VHD's aan nieuwe of bestaande Azure Stack Hub-VM's.
6. Start de Azure Stack Hub-VM's.

De optimale benadering voor het minimaliseren van de failbacktijd is om deze te automatiseren.

Overwegingen voor workloadspecifieke

Site Recovery kan worden geïntegreerd met Windows Server-apps en -rollen, waaronder SharePoint, Exchange, SQL Server en Active Directory-domein Services (AD DS). Hiermee kunt u de volgende mogelijkheden gebruiken om beveiliging en herstel op app-niveau te implementeren:

• Integratie met replicatietechnologieën op app-niveau, zoals SQL Server AlwaysOn-beschikbaarheidsgroepen, EXCHANGE Database Availability Groups (DAG's) en AD DS-replicatie
• App-consistente momentopnamen voor toepassingen met één of meerdere lagen
• Een uitgebreide automatiseringsbibliotheek met toepassingsspecifieke scripts die gereed zijn voor productie en die kunnen worden gedownload en geïntegreerd met herstelplannen

U kunt ook workloadspecifieke replicatiemechanismen gebruiken om tolerantie op siteniveau te bieden. Dit is een veelgebruikte optie bij het implementeren van herstel na noodgevallen voor AD DS-domeincontrollers, SQL Server of Exchange, die allemaal systeemeigen ondersteuning bieden voor replicatie. Hoewel hiervoor azure-VM's moeten worden ingericht die als host fungeren voor deze workloads in de omgeving voor herstel na noodgevallen, waardoor de kosten worden verhoogd, biedt dit de volgende voordelen:

• Vermindert de tijd die nodig is voor failover en failback
• Vereenvoudigt failover op workloadniveau, geschikt voor scenario's waarin failover op siteniveau niet vereist is

Beveiliging

Het beheren van herstel na noodgevallen van workloads op basis van gebruikers-VM's in hybride scenario's rechtvaardigt aanvullende beveiligingsoverwegingen. Deze overwegingen kunnen worden gegroepeerd in de volgende categorieën:

• Versleuteling tijdens overdracht. Dit omvat communicatie tussen beveiligde Azure Stack Hub-VM's, on-premises Site Recovery-onderdelen en site recovery-onderdelen in de cloud:

  • De Mobility-agent die op de beveiligde VM's is geïnstalleerd, communiceert altijd met de processerver via TLS 1.2 (Transport Layer Security).
  • Het is mogelijk voor communicatie van de configuratieserver naar Azure en van de processerver naar Azure om TLS 1.1 of 1.0 te gebruiken. Als u het beveiligingsniveau voor hybride connectiviteit wilt verhogen, moet u overwegen het gebruik van TLS 1.2 af te dwingen.

  Notitie

  Voor meer informatie over het configureren van TLS 1.2-gebaseerde versleuteling raadpleegt u registerinstellingen voor Transport Layer Security (TLS) en Update om TLS 1.1 en TLS 1.2 in te schakelen als standaard beveiligde protocollen in WinHTTP in Windows

• Versleuteling-at-rest. Dit omvat Azure Storage- en Azure-VM's op de site voor herstel na noodgevallen.

  • Azure Storage is versleuteld at rest voor alle opslagaccounts met 256-bits Advanced Encryption Standard-versleuteling en is compatibel met Federal Information Processing Standard 140-2. Versleuteling wordt automatisch ingeschakeld en kan niet worden uitgeschakeld. Versleuteling maakt standaard gebruik van door Microsoft beheerde sleutels, maar klanten hebben de mogelijkheid om hun eigen sleutels te gebruiken die zijn opgeslagen in een Azure Key Vault.
  • Beheerde schijven van Azure-VM's worden automatisch versleuteld met behulp van versleuteling aan de serverzijde van beheerde Azure-schijven, die ook van toepassing zijn op hun momentopnamen, door te vertrouwen op het gebruik van door platform beheerde versleutelingssleutels.

Daarnaast kunt u beperkte toegang afdwingen tot de Azure Storage-accounts die inhoud hosten van door Site Recovery gerepliceerde schijven. Hiervoor schakelt u de beheerde identiteit voor de Recovery Services-kluis in en wijst u deze toe aan de beheerde identiteit met de volgende Azure RBAC-rollen (op rollen gebaseerd toegangsbeheer) op het niveau van het Azure Storage-account:

• Op Resource Manager gebaseerde opslagaccounts (standaardprestatielaag):
  • Inzender
  • Inzender voor opslagblobgegevens
• Op Resource Manager gebaseerde opslagaccounts (premium-prestatielaag):
  • Inzender
  • Opslag-blobgegevens eigenaar

De Azure Recovery Services-kluis biedt mechanismen voor het verder beveiligen van de inhoud, met inbegrip van de volgende beveiligingen:

• Azure RBAC. Dit maakt delegatie en scheiding van verantwoordelijkheden mogelijk volgens het beginsel van minimale bevoegdheden. Er zijn drie ingebouwde rollen voor Site Recovery waarmee de toegang tot Site Recovery-bewerkingen wordt beperkt:
  • Site Recovery-inzender. Deze rol heeft alle machtigingen die nodig zijn voor het beheren van Site Recovery-bewerkingen in een Azure Recovery Services-kluis. Een gebruiker met deze rol kan de kluis echter niet maken of verwijderen of toegangsrechten toewijzen aan andere gebruikers. Deze rol is het meest geschikt voor beheerders van herstel na noodgevallen die herstel na noodgevallen kunnen inschakelen en beheren voor een Azure Stack Hub-tenant.
  • Site Recovery-operator. Deze rol heeft machtigingen voor het uitvoeren en beheren van failover- en failbackbewerkingen. Een gebruiker met deze rol kan replicatie niet in- of uitschakelen, geen kluizen maken of verwijderen, en geen nieuwe infrastructuur registreren of toegangsrechten toewijzen aan andere gebruikers. Deze rol is het meest geschikt voor een operator voor herstel na noodgevallen die een failover van Azure Stack Hub-VM's kan uitvoeren wanneer dit wordt geïnstrueerd door toepassingseigenaren en IT-beheerders in een werkelijk of gesimuleerd noodscenario.
  • Site Recovery-lezer. Deze rol heeft machtigingen om alle beheerbewerkingen van Site Recovery bij te houden. Deze rol is het meest geschikt voor IT-medewerkers die verantwoordelijk zijn voor het bewaken van de status van beveiligde Azure Stack Hub-VM's en indien nodig ondersteuningstickets indienen.
• Azure-resourcevergrendelingen. U hebt de mogelijkheid om alleen-lezen- en verwijdervergrendelingen te maken en toe te wijzen aan een Site Recovery-kluis om het risico te beperken dat de kluis per ongeluk wordt gewijzigd of verwijderd.
• Voorlopig verwijderen. Het doel van voorlopig verwijderen is om de kluis en de bijbehorende gegevens te beschermen tegen onbedoelde of schadelijke verwijderingen. Met voorlopig verwijderen wordt alle verwijderde inhoud gedurende 14 extra dagen bewaard, waardoor deze gedurende die periode kan worden opgehaald. Voor de extra 14-daagse retentie van kluisinhoud worden geen kosten in rekening gebracht. Voorlopig verwijderen is standaard ingeschakeld.
• Beveiliging van beveiligingsgevoelige bewerkingen. Met de Azure Recovery Services-kluis kunt u een extra verificatielaag inschakelen wanneer een beveiligingsgevoelige bewerking, zoals het uitschakelen van beveiliging, wordt geprobeerd. Deze extra validatie zorgt ervoor dat geautoriseerde gebruikers dergelijke bewerkingen uitvoeren.
• Bewaking en waarschuwingen van verdachte activiteiten. Azure Recovery Services biedt ingebouwde bewaking en waarschuwingen over beveiligingsgevoelige gebeurtenissen met betrekking tot de kluisbewerkingen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Wanneer u rekening houdt met de kosten van de op Site Recovery gebaseerde oplossing voor herstel na noodgevallen die in dit artikel worden beschreven, moet u rekening houden met zowel on-premises als cloudonderdelen. Het prijsmodel van Azure Stack Hub bepaalt de prijzen van on-premises onderdelen. Net als bij Azure biedt Azure Stack Hub een regeling voor betalen per gebruik, die beschikbaar is via enterprise-overeenkomsten en het Cloud Solution Provider-programma. Deze regeling omvat een maandelijkse prijs voor elke Virtuele Windows Server-machine. Als u de mogelijkheid hebt om bestaande Windows Server-licenties te gebruiken, kunt u de kosten aanzienlijk verlagen voor de prijzen van basis-VM's. Met Site Recovery hebt u echter meestal slechts één Azure Stack Hub-VM per tenant nodig. Dit is vereist voor het implementeren van de tenantspecifieke configuratieserver.

Azure-gerelateerde kosten zijn gekoppeld aan het gebruik van de volgende resources:

• Azure Recovery Services. De prijzen worden bepaald door het aantal beveiligde exemplaren. Het is de moeite waard om te vermelden dat voor elke beveiligde instantie geen Site Recovery-kosten in rekening worden gebracht voor de eerste 31 dagen.

• Azure Storage. De prijzen weerspiegelen een combinatie van de volgende factoren:

  • Prestatielaag
  • Volume van opgeslagen gegevens
  • Volume van uitgaande gegevensoverdracht
  • Aantal en typen uitgevoerde bewerkingen (alleen voor de standard-prestatielaag)
  • Gegevensredundantie (alleen voor de standard-prestatielaag)

• Azure ExpressRoute. De prijzen zijn gebaseerd op een van de twee modellen:

  • Onbeperkt gegevensverkeer. Dit model bevat een maandelijks bedrag met alle inkomende en uitgaande gegevensoverdrachten.
  • Naar gebruik. Dit model omvat een maandelijks bedrag waarbij alle binnenkomende gegevensoverdrachten gratis en uitgaande gegevensoverdrachten per GB in rekening worden gebracht.

  Notitie

  Deze evaluatie omvat niet de kosten van fysieke verbindingen die worden geleverd door connectiviteitsproviders van derden.

• Virtuele Azure-machines. De prijzen van Virtuele Azure-machines weerspiegelen een combinatie van twee onderdelen:

  • Rekenkosten. De VM-grootte, de uptime en het licentiemodel van het besturingssysteem bepalen de kosten.
  • Kosten voor beheerde schijven. De schijfgrootte en de prestatielaag bepalen de kosten.

  Notitie

  Het is de moeite waard om te weten dat hydratatie de noodzaak elimineert om Azure-VM's uit te voeren tijdens normale bedrijfsactiviteiten, met workloads die worden uitgevoerd op Azure Stack Hub, waardoor de rekenkosten van op Site Recovery gebaseerde implementaties aanzienlijk worden verminderd, met name in vergelijking met traditionele oplossingen voor herstel na noodgevallen.

  Notitie

  De prijzen van resources verschillen per Azure-regio.

  Notitie

  Raadpleeg Azure-prijzen voor meer informatie over prijzen.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

De belangrijkste overwegingen met betrekking tot de beheerbaarheid van herstel na noodgevallen op basis van Site Recovery van azure Stack Hub-VM's zijn onder andere:

• Implementatie van Site Recovery in Azure Stack Hub
• Procedures voor failover en failback
• Delegatie van rollen en verantwoordelijkheden
• DevOps

Implementatie van Site Recovery in Azure Stack Hub

Als u Site Recovery in Azure Stack Hub wilt implementeren in een kleine tot middelgrote omgeving met één tenant, kunt u het handmatige inrichtingsproces volgen dat wordt aangestuurd door de grafische interface van Recovery Services Vault in Azure Portal. Voor implementaties met meerdere tenants kunt u overwegen om onderdelen van het implementatieproces te automatiseren, omdat u doorgaans een afzonderlijke VM met een configuratieserver en een afzonderlijke Recovery Services-kluis voor elke tenant moet instellen. U hebt ook de mogelijkheid om de implementatie van de mobility-agent te automatiseren door de procedure te volgen die wordt beschreven in de bronmachine voorbereiden voor pushinstallatie van de Mobility-agent.

Procedures voor failover en failback

U kunt het beheer van failover vereenvoudigen door herstelplannen voor alle beveiligde workloads te implementeren. Raadpleeg de sectie Betrouwbaarheid eerder in dit artikel voor meer informatie. U vindt ook aanbevelingen voor het optimaliseren van het beheer van de failbackprocedure.

Delegatie van rollen en verantwoordelijkheden

Het plannen en implementeren van noodherstel van op VM's gebaseerde workloads van Azure Stack Hub met behulp van Site Recovery omvat doorgaans interactie van belanghebbenden:

• Azure Stack Hub-operators beheren de Azure Stack Hub-infrastructuur, zodat er voldoende reken-, opslag- en netwerkresources zijn die nodig zijn voor het implementeren van een uitgebreide oplossing voor herstel na noodgevallen en het beschikbaar maken van deze resources voor tenants. Ze werken ook samen met eigenaren van toepassingen en gegevens om de optimale benadering te bepalen voor het implementeren van hun workloads in Azure Stack Hub.
• Azure-beheerders beheren Azure-resources die nodig zijn voor het implementeren van hybride noodhersteloplossingen.
• Microsoft Entra-beheerders beheren Microsoft Entra-resources, waaronder gebruikers- en groepsobjecten die worden gebruikt voor het inrichten, configureren en beheren van Azure-resources.
• It-medewerkers van Azure Stack Hub-tenants ontwerpen, implementeren en beheren Site Recovery, inclusief failover en failback.
• Azure Stack Hub-gebruikers moeten RPO- en RTO-vereisten opgeven en aanvragen indienen om herstel na noodgevallen voor hun workloads te implementeren.

Zorg ervoor dat er duidelijk inzicht is in de rollen en verantwoordelijkheden die zijn toegewezen aan toepassingseigenaren en -operators in de context van beveiliging en herstel. Gebruikers zijn verantwoordelijk voor het beveiligen van VM's. Operators zijn verantwoordelijk voor de operationele status van de Azure Stack Hub-infrastructuur.

DevOps

Hoewel het configureren van herstel op VM-niveau met behulp van Site Recovery voornamelijk verantwoordelijk is voor IT-bewerkingen, zijn er enkele DevOps-specifieke overwegingen die moeten worden opgenomen in een uitgebreide strategie voor herstel na noodgevallen. Azure Stack Hub faciliteert het implementeren van Infrastructure-as-Code (IaC), dat de geautomatiseerde implementatie van verschillende workloads omvat, waaronder VM-toepassingen en -services. U kunt deze mogelijkheid gebruiken om het inrichten van scenario's voor herstel na noodgevallen op basis van Site Recovery te stroomlijnen, wat de eerste installatie in meerdere tenantscenario's vereenvoudigt.

U kunt bijvoorbeeld dezelfde Azure Resource Manager-sjablonen gebruiken om alle netwerkresources in te richten die nodig zijn voor vm-workloads in een Azure Stack Hub-stempel voor uw toepassing in één, gecoördineerde bewerking. U kunt dezelfde sjabloon gebruiken om een overeenkomende set resources in Te richten in Azure om een site voor herstel na noodgevallen in te richten. Als u rekening wilt houden met eventuele verschillen tussen de twee omgevingen, kunt u in elk geval verschillende waarden van sjabloonparameters opgeven.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Bij de implementatie van Site Recovery in Azure Stack Hub moet u rekening houden met de hoeveelheid verwerking, opslag en netwerkbronnen die zijn toegewezen aan de configuratie- en processervers. Mogelijk moet u de geschatte grootte van de Azure Stack Hub-VM aanpassen die als host fungeert voor de Site Recovery-onderdelen na de implementatie om te voldoen aan wijzigingen in de verwerkings- of opslagvereisten. U hebt drie basisopties om de grootte aan te passen:

• Verticale schaalaanpassing implementeren. Dit omvat het wijzigen van de hoeveelheid processor- en geheugen- en schijfbronnen van de Azure Stack Hub-VM die als host fungeert voor de configuratieserver, inclusief de processerver. Als u de resourcevereisten wilt schatten, kunt u de informatie in de volgende tabel gebruiken:

  Tabel 1: Vereisten voor de grootte van de configuratie- en processerver

  CPU	Geheugen	Cacheschijf	Frequentie van gegevenswijzigingen	Beveiligde machines
  8 vCPU's 2 sockets * 4 kernen @ 2,5 GHz	16 GB	300 GB	500 GB of minder	< 100 machines
  12 vCPU's 2 sockets * 6 kernen @ 2,5 GHz	18 GB	600 GB	500 GB - 1 TB	100 - 150 computers
  16 vCPU's 2 sockets * 8 kernen @ 2,5 GHz	32 GB	1 TB	1-2 TB	150-200 machines

• Horizontaal schalen implementeren. Dit omvat het inrichten of ongedaan maken van de inrichting van Azure Stack Hub-VM's met de processerver die is geïnstalleerd om te voldoen aan de verwerkingsvereisten van beveiligde Azure Stack Hub-VM's. Als u uw implementatie moet schalen naar meer dan 200 bronmachines of als u een totale dagelijkse verloopsnelheid van meer dan twee terabytes (TB) hebt, hebt u extra processervers nodig om replicatieverkeer te verwerken. Als u het aantal en de configuratie van aanvullende processervers wilt schatten, raadpleegt u Aanbevelingen voor grootte voor de processerver.

• Replicatiebeleid wijzigen. Dit omvat het wijzigen van parameters van het replicatiebeleid, met de focus op app-consistente momentopnamen.

Vanuit het oogpunt van netwerken zijn er verschillende methoden om de bandbreedte die beschikbaar is voor replicatieverkeer aan te passen:

• Vm-grootte wijzigen. De grootte van azure Stack Hub-VM's bepaalt de maximale netwerkbandbreedte. Het is echter belangrijk om te weten dat er geen bandbreedtegaranties zijn. In plaats daarvan kunnen VM's gebruikmaken van de hoeveelheid beschikbare bandbreedte tot de limiet die wordt bepaald door hun grootte.

• Schakelopties voor uplinks vervangen. Azure Stack Hub-systemen ondersteunen een reeks hardwareswitches, die verschillende opties van uplinksnelheden bieden. Elk Azure Stack Hub-clusterknooppunt heeft twee uplinks naar de bovenkant van rackswitches voor fouttolerantie. Het systeem wijst de helft van de uplinkcapaciteit toe voor kritieke infrastructuur. De rest is gedeelde capaciteit voor Azure Stack Hub-services en al het gebruikersverkeer. Systemen die zijn geïmplementeerd met snellere snelheden, hebben meer bandbreedte beschikbaar voor replicatieverkeer.

  Notitie

  Hoewel het mogelijk is om netwerkverkeer te scheiden door een tweede netwerkadapter te koppelen aan een server, met Azure Stack Hub-VM's, deelt al het VM-verkeer naar internet dezelfde uplink. Een tweede, virtuele netwerkadapter zal het verkeer niet scheiden op het niveau van het fysieke transport.

• Wijzig de doorvoer van de netwerkverbinding met Azure. Voor grotere hoeveelheden replicatieverkeer kunt u Overwegen Om Azure ExpressRoute te gebruiken met Microsoft-peering voor verbindingen tussen virtuele netwerken van Azure Stack Hub en Azure Storage. Azure ExpressRoute breidt on-premises netwerken uit naar de Microsoft-cloud via een privéverbinding die wordt geleverd door een connectiviteitsprovider. U kunt ExpressRoute-circuits kopen voor een breed scala aan bandbreedten, van 50 megabits per seconde (Mbps) tot 100 gigabits per seconde.

  Notitie

  Raadpleeg voor meer informatie over het implementeren van Azure ExpressRoute in Azure Stack Hub-scenario's Verbinding maken Azure Stack Hub naar Azure met behulp van Azure ExpressRoute.

• Beperking van replicatieverkeer op de processerver wijzigen. U kunt bepalen hoeveel bandbreedte wordt gebruikt door het replicatieverkeer op de VM's die als host fungeren voor processervers vanuit de grafische interface van de Microsoft Azure Recovery Services-agent. De ondersteunde mogelijkheden omvatten het instellen van de limieten voor werk- en niet-werkuren, waarbij de bandbreedtewaarden variëren van 512 kilobits per seconde tot 1023 Mbps. U kunt ook dezelfde configuratie toepassen met behulp van de PowerShell-cmdlet Set-OBMachineSetting .

• Wijzig de netwerkbandbreedte die is toegewezen per beveiligde VIRTUELE machine op de processerver. Hiervoor wijzigt u de waarde van de uploadThreadsPerVM-vermelding in de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication-sleutel. De waarde is standaard ingesteld op 4, maar u kunt deze verhogen naar 32 als er voldoende netwerkbandbreedte beschikbaar is.

Dit scenario implementeren

Vereisten

De implementatie van de aanbevolen oplossing is afhankelijk van de volgende vereisten:

• Toegang tot een Azure-abonnement, met machtigingen die voldoende zijn om alle cloudonderdelen van de Site Recovery-onderdelen in te richten en te beheren, waaronder:

  • Azure Recovery Services-kluis in de Azure-regio die is aangewezen als de site voor herstel na noodgevallen voor de Azure Stack Hub-productieomgeving.
  • Een Azure Storage-account dat inhoud host van gerepliceerde schijven van Azure Stack Hub-VM's.
  • Een virtueel Azure-netwerk dat de omgeving voor herstel na noodgevallen vertegenwoordigt waarmee gehydrateerde Azure-VM's worden verbonden na een geplande of niet-geplande failover.
  • Een geïsoleerd virtueel Azure-netwerk dat de testomgeving vertegenwoordigt waarmee gehydrateerde Azure-VM's worden verbonden na een testfailover.
  • Een connectiviteit op basis van Azure ExpressRoute tussen de on-premises omgeving, virtuele Azure-netwerken en het Azure-opslagaccount dat wordt gebruikt voor het hosten van kopieën van VHD-bestanden met inhoud die is gerepliceerd vanaf schijven met beveiligde Azure Stack Hub-VM's.

• Een Azure Stack Hub-gebruikersabonnement. Alle Azure Stack Hub-VM's die worden beveiligd door een afzonderlijke Site Recovery-configuratieserver, moeten deel uitmaken van hetzelfde Azure Stack Hub-gebruikersabonnement.

• Een virtueel Azure Stack Hub-netwerk. Alle beveiligde VM's moeten directe connectiviteit hebben met de VM's die als host fungeren voor het processerveronderdeel (standaard is dit de configuratieserver-VM).

• Een Windows Server-VM van Azure Stack Hub die als host fungeert voor de configuratieserver en een processerver. De VIRTUELE machine moet deel uitmaken van hetzelfde abonnement en worden gekoppeld aan hetzelfde virtuele netwerk als de Azure Stack Hub-VM's die moeten worden beveiligd. Daarnaast moet de VIRTUELE machine het volgende doen:

  • Voldoen aan de software- en hardwarevereisten van de Site Recovery-configuratieserver
  • Voldoen aan de documentatie voor netwerkvereisten voor externe connectiviteit.

  Notitie

  Aanvullende overwegingen voor opslag en prestaties voor de configuratie- en processervers worden verderop in deze architectuur uitgebreider beschreven.

  • Voldoen aan de vereisten voor interne connectiviteit. Met name virtuele Azure Stack Hub-machines die u wilt beveiligen, moeten kunnen communiceren met:

    • De configuratieserver via TCP-poort 443 (HTTPS) binnenkomend voor replicatiebeheer
    • De processerver via TCP-poort 9443 om replicatiegegevens te leveren.

    Notitie

    U kunt de poort wijzigen die door de processerver wordt gebruikt voor zowel externe als interne connectiviteit als onderdeel van de configuratie bij het uitvoeren van geïntegreerde Installatie van Site Recovery.

• Azure Stack Hub-VM's die moeten worden beveiligd door een van de ondersteunde besturingssystemen uit te voeren om Azure Stack Hub-VM's met Windows Server-besturingssystemen te beveiligen, moet u het volgende doen:

  • Maak een Windows-account met beheerdersrechten. U kunt dit account opgeven wanneer u Site Recovery inschakelt op deze VM's. De processerver gebruikt dit account om de Site Recovery-Mobility-service te installeren. Zorg ervoor dat u in een werkgroepomgeving extern toegangsbeheer voor gebruikers op windows Server-doelbesturingssystemen uitschakelt door de waarde van de registervermelding LocalAccountTokenFilterPolicyDWORD in te stellen in de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System-sleutel op 1.
  • Schakel regels voor bestands- en printerdeling en Windows Management Instrumentation in in de Microsoft Defender-firewall.

• Als u virtuele Machines van Azure Stack Hub wilt beveiligen waarop Linux-besturingssystemen worden uitgevoerd, moet u het volgende doen:

  • Maak een hoofdgebruikersaccount. U kunt dit account opgeven wanneer u Site Recovery inschakelt op deze VM's. De processerver gebruikt dit account om de Site Recovery-Mobility-service te installeren.
  • Installeer de nieuwste openssh, openssh-server en openssl-pakketten.
  • Schakel SSH-poort (Secure Shell) in en voer deze uit.
  • Schakel secure FTP-subsysteem en wachtwoordverificatie in.

Implementatiestappen op hoog niveau

Op hoog niveau bestaat de implementatie van herstel na noodgevallen op basis van Site Recovery in Azure Stack Hub uit de volgende fasen:

1. Bereid azure Stack Hub-VM's voor om te worden beveiligd door Site Recovery. Zorg ervoor dat de VM's voldoen aan de vereisten van Site Recovery die in de vorige sectie worden vermeld.

2. Een Azure Recovery Services-kluis maken en configureren. Stel een Azure Recovery Services-kluis in en geef op wat u wilt repliceren. Site Recovery-onderdelen en -activiteiten worden geconfigureerd en beheerd met behulp van de kluis.

3. Stel de bronreplicatieomgeving in. Richt een Site Recovery-configuratieserver en -processerver in door binaire bestanden van Site Recovery Unified Setup te installeren en te registreren bij de kluis.

   Notitie

   U kunt de geïntegreerde installatie van Site Recovery opnieuw uitvoeren om extra processervers te implementeren op Azure Stack Hub-VM's.

4. Stel de doelreplicatieomgeving in. Maak of selecteer een bestaand Azure-opslagaccount en een virtueel Azure-netwerk in de Azure-regio die als host fungeert voor de site voor herstel na noodgevallen. Tijdens de replicatie wordt de inhoud van de schijven voor de beveiligde Azure Stack Hub-VM's gekopieerd naar het Azure Storage-account. Tijdens een failover richt Site Recovery automatisch Azure-VM's in die fungeren als replica's van beveiligde Azure Stack Hub-VM's en worden deze verbonden met het virtuele Azure-netwerk.

5. Schakel replicatie in. Configureer de replicatie-instelling en schakel replicatie in voor Azure Stack Hub-VM's. De Mobility-service wordt automatisch geïnstalleerd op elke Azure Stack Hub-VM waarvoor replicatie is ingeschakeld. Site Recovery initieert replicatie van elke Azure Stack Hub-VM, volgens de beleidsinstellingen die u hebt gedefinieerd.

6. Voer een testfailover uit. Nadat de replicatie tot stand is gebracht, controleert u of de failover werkt zoals verwacht door een testfailover uit te voeren.

7. Een geplande of niet-geplande failover uitvoeren. Na een geslaagde testfailover bent u klaar om een geplande of niet-geplande failover naar Azure uit te voeren. U hebt de mogelijkheid om aan te geven welke Azure Stack Hub-VM's moeten worden opgenomen in de failover.

8. Voer een failback uit. Wanneer u klaar bent om een failback uit te voeren, stopt u de Azure-VM's die overeenkomen met de Azure Stack Hub-VM's die u hebt mislukt, downloadt u de schijfbestanden naar on-premises opslag, uploadt u deze naar Azure Stack Hub en koppelt u deze aan een bestaande of nieuwe VIRTUELE machine.

Samenvatting

Tot slot is Azure Stack Hub een unieke aanbieding, die verschilt in veel aspecten van andere virtualisatieplatforms. Daarom rechtvaardigt het speciale overwegingen met betrekking tot de strategie voor bedrijfscontinuïteit voor de workloads. Met behulp van Azure-services kunt u het ontwerpen en implementeren van deze strategie vereenvoudigen. In dit naslagartikel over architectuur hebben we het gebruik van Microsoft Site Recovery verkend voor het beveiligen van azure Stack Hub VM-workloads in het verbonden implementatiemodel. Met deze aanpak kunnen klanten profiteren van tolerantie en beheerbaarheid van Azure Stack Hub en van de hyperscale en wereldwijde aanwezigheid van de Azure-cloud.

Het is belangrijk te weten dat de oplossing voor herstel na noodgevallen die hier wordt beschreven, uitsluitend is gericht op vm-workloads van Azure Stack Hub. Dit is slechts een onderdeel van een algemene strategie voor bedrijfscontinuïteit die rekening moet houden met andere typen Azure Stack Hub-werkbelastingen en -scenario's die van invloed zijn op hun beschikbaarheid.

Volgende stappen

Productdocumentatie:

• Over siteherstel
• Overzicht van Azure Stack Hub
• Wat is Microsoft Entra ID?
• Wat is Azure Blob Storage?
• Wat is Azure ExpressRoute?
• Wat is Azure Virtual Network?

Microsoft Learn-modules:

• Azure Stack Hub
• Microsoft Entra-id configureren
• Opslagaccounts configureren
• Virtuele netwerken configureren
• Azure ExpressRoute ontwerpen en implementeren
• Uw sitehersteloplossing ontwerpen in Azure

Verwante resources

• Hybride architectuurontwerp
• Back-ups maken van bestanden en toepassingen in Azure Stack Hub
• Hybride verbindingen
• Hybride bestandsshare met herstel na noodgevallen voor externe en lokale vertakkingsmedewerkers