Bedrijfscontinuïteit en herstel na noodgevallen voor Azure VMware Solution

Artikel
09/22/2023

Dit scenario op ondernemingsniveau helpt de bedrijfscontinuïteit en herstel na noodgevallen (BCDR) te verbeteren. Azure VMware Solution biedt privéclouds die VMware vSphere-clusters bevatten die zijn gebouwd op basis van een toegewezen bare-metal Azure-infrastructuur. De oplossing biedt minimaal drie ESXi-hosts, maximaal 16 hosts per cluster. Alle ingerichte privéclouds hebben VMware vCenter Server, VMware vSAN, VMware vSphere en VMware NSX-T Data Center. Zie SLA voor Azure VMware Solution voor meer informatie over de SERVICE Level Agreement (SLA) voor Azure VMware Solution.

Of u nu een on-premises of Azure VMware Solution hebt, u moet rekening houden met verschillende BCDR-factoren om u voor te bereiden op een noodgeval. Een robuust BCDR-plan is bedoeld om een bedrijf te beschermen tegen gegevensverlies, financieel verlies en downtime als er sprake is van een verstorende gebeurtenis. In de volgende beslissingsstructuur ziet u verschillende BCDR-opties die beschikbaar zijn voor Azure VMware Solution.

Notitie

Een testomgeving met licht is ingesteld met een minimale configuratie, met alleen kernonderdelen ter ondersteuning van een kritieke set toepassingen. Het kan echter meer hosts uitschalen en spawnen om het grootste deel van de belasting te nemen als er een failover optreedt. Voor herstel na noodgevallen van reken- en geheugenintensieve Azure VMware-oplossingsworkloads is dezelfde hoeveelheid opslag vereist op de secundaire site.

Ontwerpoverwegingen voor bedrijfscontinuïteit

VMware vSAN-opslagbeleidsregels in Azure VMware Solution worden geïmplementeerd met de beschikbaarheid van opslag in het achterhoofd. Wanneer het cluster tussen drie en vijf hosts heeft, is het aantal hostfouten dat kan worden getolereerd zonder dat gegevensverlies gelijk is aan één. Wanneer het cluster tussen 6 en 16 hosts heeft, kan het aantal hostfouten worden getolereerd voordat gegevensverlies gelijk is aan twee. VMware vSAN-opslagbeleid kan per VM worden toegepast. Hoewel deze beleidsregels de standaardinstelling zijn, kunt u het beleid aanpassen aan aangepaste vereisten. Zie Azure VMware Solution-opslagconcepten voor meer informatie.
Hoge beschikbaarheid van vSphere is standaard ingeschakeld in Azure VMware Solution. Het beleid voor hoge beschikbaarheid behoudt reken- en geheugencapaciteit voor één knooppunt. Deze reservering zorgt ervoor dat voldoende capaciteit is om workloads opnieuw op te starten in een ander knooppunt in een Azure VMware Solution-cluster.
Hoge beschikbaarheid met stretch-cluster: met Azure VMware Solution bevinden ESXi-hosts die traditioneel zijn geïmplementeerd in een standaard vSphere-cluster zich in één Azure-beschikbaarheidszone en worden beveiligd door hoge beschikbaarheid van vSphere. Workloads worden echter niet beschermd tegen een fout in de beschikbaarheidszone. Ter bescherming tegen fouten kan één vSAN-cluster twee afzonderlijke beschikbaarheidszones omvatten, een vSAN-stretched cluster genoemd. Zie VSAN-stretched clusters implementeren voor meer informatie.
Kies een gevalideerde back-upoplossing voor de virtuele VMware vSphere-machines (VM's), zoals Microsoft Azure Backup Server of een back-upoplossing van een partner.
Raadpleeg de desbetreffende partnerdocumentatie voor informatie over ondersteunde functies in back-upoplossingen van partners.

Notitie

Configuraties van Azure VMware Solution-privécloud vCenter Server en HCX Manager (indien ingeschakeld) staan op een dagelijks back-upschema en NSX-configuratie is volgens het schema voor het maken van een back-up per uur. De back-ups worden minimaal drie dagen bewaard.
Azure VMware Solution-onderdelen, zoals vCenter Server, NSX-T Manager of HCX Manager, zijn beheerde services waarvoor Azure back-ups beheert. Als u een back-up wilt herstellen, maakt u een Azure-ondersteuningsaanvraag.

Aanbevelingen voor ontwerp voor bedrijfscontinuïteit

Gebruik Azure Backup Server om een back-up te maken van de azure VMware Solution-privécloud. Zie Back-ups maken van VMware vSphere-VM's met Azure Backup voor meer informatie. Ondersteunde implementatietopologieën zijn marsagent en Data Protection Manager. Elke implementatietopologie heeft een eigen ondersteuningsmatrix, beperkingen en beperkingen.
Implementeer de Azure Backup-server in dezelfde Azure-regio als de azure VMware Solution-privécloud. Deze implementatiemethode vermindert de verkeerskosten, vereenvoudigt het beheer en behoudt de primaire/secundaire topologie. Zie de selectiehandleiding voor Azure-regio's voor best practices voor implementatie van Azure-regio's.
Azure Backup kan worden geïmplementeerd als een IaaS-VM (Infrastructure as a Service) of in de privécloud van Azure VMware Solution. Het wordt ten zeerste aanbevolen om deze buiten de privécloud van Azure VMware Solution te implementeren. Implementeer Back-up in een virtueel Azure-netwerk en zorg ervoor dat dit virtuele netwerk is verbonden met dezelfde ExpressRoute die is verbonden met de privécloud van Azure VMware Solution. Back-upserver uitvoeren buiten de privécloud van Azure VMware Solution helpt bij het verminderen van het vSAN-verbruik, omdat vSAN een beperkte capaciteitsresource is binnen de privécloud van Azure VMware Solution.

Azure Backup Server geïmplementeerd als een Azure IaaS-VM.

Azure Backup Server geïmplementeerd als een Azure VMware Solution-VM.
Gebruik de controlelijst voor toepassingsprestatievereisten om de juiste capaciteit en schijftype te bereiken, zoals HDD, SSD of Ultra. Overweeg de Azure IaaS VM-SKU die ondersteuning biedt voor het schijftype en de capaciteit voor back-upbewerkingen.
Gebruik azure Backup Server-capaciteitsplanner om het aantal servers, opslag en IOPS-vereisten voor elk ervan te bepalen. Wanneer u de waarde 'Totale grootte van de workload (GB)*' opgeeft in de capaciteitsplanner, gebruikt u de mediaanwaarde tussen 'gebruikte opslag' en 'toegewezen opslag' van alle virtuele machines in vCenter waarvan u een back-up wilt maken.
Gebruik opslaggroepen met Azure Backup Server voor verbeterde IOPS/doorvoer van schijven. Gebruik gelaagde opslag op Backup Server voor uitgebreide bewerkingen. Stel de configuratiewaarde DisableWriteAutoTiering in op 1 op MABS-volume, zodat de volledige prestatielaag beschikbaar is voor het opslaan van ReFS-metagegevens.
Identificeer het aantal parallelle back-uptaken en herstelbewerkingen die moeten worden uitgevoerd op de Azure Backup-server. Momenteel worden acht parallelle back-uptaken ondersteund. Meet de hoeveelheid tijd die nodig is om een back-up te maken van bedrijfskritieke workloads en deze te herstellen gedurende meerdere uitvoeringen. Controleer of back-up- en hersteltijden voldoen aan de RPO- en RTO-vereisten voor Azure Backup-server. Zorg ervoor dat het AVS vSAN-gegevensarchief voldoende capaciteit heeft om een herstelde back-up te bewaren.
Voeg de benodigde antivirusuitzondering toe voor Azure Backup Server-bestanden en -mappen, zoals hier wordt beschreven als er antivirus-/antimalwaresoftware wordt uitgevoerd op Azure Backup Server. Wanneer u een DPM-beveiligingsagent gebruikt op een Virtuele Machine van Azure VMware Solution voor toepassingsback-up (bijvoorbeeld SQL, Sharepoint, enzovoort), schakelt u realtime-bewaking van dpmra.exe uit.
Configureer de juiste NSG-regels (netwerkbeveiligingsgroep) voor subnetten die als host fungeren voor Azure Backup Server, zodat netwerkcommunicatie van de DPM-beveiligingsagent die wordt uitgevoerd op een beveiligde VIRTUELE machine in Azure VMware Solution is toegestaan. DPM-beveiligingsagent communiceert met Azure Backup Server op elke dynamische poort tussen 1024 en 65535.
Momenteel biedt Azure Backup Server geen ondersteuning voor herstel tussen regio's voor azure VMware Solution-privécloud. Raadpleeg de sectie Back-upoplossingen van partners en herstel na noodgevallen wanneer herstel tussen regio's van Azure VMware Solution is vereist.

Overwegingen bij het ontwerpen van herstel na noodgevallen

Afstemmen van bedrijfsvereisten met beoogde hersteltijd (RTO), capaciteits- en herstelpuntdoelstellingen (RPO) voor toepassingen. Plan en ontwerp dienovereenkomstig om deze doelstellingen te bereiken met behulp van de meest geschikte replicatietechnologie. U kunt bijvoorbeeld sql-databases systeemeigen repliceren met behulp van een SQL AlwaysOn-beschikbaarheidsgroep of een hulpprogramma voor herstel na noodgevallen gebruiken, zoals VMware Site Recovery Manager.
Bepaal de doelsite voor herstel na noodgevallen voor de beveiligde azure VMware Solution-privécloud. Deze site beïnvloedt welke hulpprogramma's voor herstel na noodgevallen geschikt zijn voor de omgeving. Als u bijvoorbeeld Azure VMware Solution-workloads wilt herstellen naar systeemeigen IaaS-vm's van Azure, kunt u Azure Site Recovery of Zerto overwegen.
Bepaal welke subset van Azure VMware Solution-workloads beveiliging vereist als er een noodherstel-gebeurtenis is. Overweeg om de workloads te categoriseren op basis van prioriteit: P0 voor bedrijfskritieke workloads en P1, P2, P3 voor andere workloads die belangrijk zijn, maar niet zo essentieel zijn voor het functioneren van het bedrijf. Het bedrijfscontinuïteitsplan van de klant definieert de prioriteitsniveaus, waarmee u de kosten kunt beheren die zijn gekoppeld aan de implementatie van noodherstel.
In de meeste gevallen hoeven niet-productieomgevingen, zoals dev, test of UAT, geen failover naar een secundaire site uit te voeren. U moet de testlamp op de secundaire locatie uitvoeren met verminderde capaciteit voor productie- en kritieke workloads om kosten te besparen. Voor meer capaciteit kunt u uitschalen om ESXi-hosts toe te voegen aan het cluster tijdens de gebeurtenis voor herstel na noodgevallen.
Voor testfase-implementaties, met name, moet u ervoor zorgen dat u al het hostquotum hebt beveiligd dat nodig is op de secundaire site, zodat u niet hoeft te wachten op de vereiste capaciteit tijdens het volledig uitschalen. Zie Hostquotum aanvragen voor Azure VMware Solution.
Functionele domeinrollen, zoals Active Directory-domeincontrollers, instellen in de secundaire omgeving.
Oplossingen van partners zoals JetStream en Zerto zijn algemeen beschikbaar en gevalideerd in Azure VMware Solution. Ze ondersteunen de meeste scenario's voor herstel na noodgevallen en kunnen sneller herstel mogelijk maken met bijna nul RPO.
VMware Site Recovery Manager, Jetstream en Zerto ondersteunen migratie van locaties van derden naar Azure VMware Solution.
VMware HCX is ook een rendabele oplossing voor herstel na noodgevallen. Het wordt echter niet aanbevolen voor grote productieworkloads vanwege handmatige indeling.
Voor herstel na noodgevallen tussen privéclouds van Azure VMware Solution in verschillende Azure-regio's moet u ExpressRoute Global Reach tussen beide Back-end ExpressRoute-circuits inschakelen. Deze circuits maken een primaire naar secundaire privécloudconnectiviteit wanneer dat nodig is voor oplossingen zoals VMware SRM en VMware HCX.
Voor herstel na noodgevallen tussen Azure VMware Solution-privéclouds in dezelfde Azure-regio moet u Azure VMware Solution Interconnect inschakelen. Er wordt een routeringskoppeling gemaakt tussen de beheer- en workloadnetwerken van de Privéclouds van Azure VMware Solution voor communicatie tussen de clouds. Zorg ervoor dat de gerouteerde IP-adresruimte in elke privécloud uniek is en niet overlapt.
Wanneer u met herstel na noodgevallen werkt, kunt u dezelfde bron-IP-adresruimte gebruiken in de primaire Azure-regio en de secundaire Azure-regio. Hiervoor zijn echter extra ontwerp- en technische inspanningen vereist.
- Dezelfde IP-adressen behouden: de virtuele machines op de secundaire Azure VMware Solution-site kunnen worden hersteld met hetzelfde bron-IP-adres als de primaire site. Voor deze methode maakt u geïsoleerde VLAN's of NSX-T-segmenten op de secundaire site en zorgt u ervoor dat geen van deze geïsoleerde VLAN's of segmenten zijn verbonden met de omgeving. Pas de routes voor herstel na noodgevallen aan om aan te geven dat het subnet is verplaatst naar de secundaire site en de locatie van de nieuwe IP-adressen. Hoewel deze methode werkt, creëert het ook technische overhead bij het streven naar volledig geautomatiseerd herstel na noodgevallen.
- Verschillende IP-adressen gebruiken: u kunt ook verschillende IP-adressen gebruiken voor herstelde VM's. Als de VIRTUELE machine naar een secundaire site wordt verplaatst, wordt in het herstelplan in VMware Site Recovery Manager de aangepaste IP-toewijzing weergegeven. Selecteer deze kaart voor de wijziging van het IP-adres. VM's worden weergegeven in de nieuwe NSX-T-segmenten en er worden nieuwe IP-adressen toegewezen. De hulpprogramma's kunnen verschillen voor verschillende oplossingen voor herstel na noodgevallen.
Belangrijke factoren voor scenario's voor gedeeltelijk en volledig herstel na noodgevallen:
- VMware Site Recovery Manager ondersteunt gedeeltelijk herstel, waardoor slechts een subset van virtuele machines wordt hersteld en volledig herstel na noodgevallen. Tussen twee Azure VMware Solution-sites in regio 1 en regio 2 kunnen alle of sommige vm's een failover uitvoeren.
- De vereiste van bron-IP-adresretentie voor herstelde VM's bepaalt of gedeeltelijk versus volledig herstel na noodgevallen mogelijk is.
- Als u het bron-IP-adres wilt behouden tijdens het uitvoeren van gedeeltelijk herstel na noodgevallen in Site Recovery Manager, moet de subnetgateway naar de secundaire site worden verplaatst.
Notitie

Voor herstel na noodgeval met actieve stand-by is laag 2 niet vereist.

Aanbevelingen voor ontwerp voor herstel na noodgevallen

Gebruik VMware Site Recovery Manager bij het werken met Azure VMware Solution op zowel primaire als secundaire sites. Primaire en secundaire sites worden ook wel beveiligde en herstelsites genoemd.

Overzicht op hoog niveau van continue vSphere-replicatie.

Gedetailleerd voorbeeld van continue vSphere-replicatie tussen primaire en secundaire sites.
Voor bedrijfskritieke toepassingen zijn Zerto en JetStream beschikbaar als oplossingen voor herstel na noodgevallen voor de privécloud van Azure VMware Solution. JetStream en Zerto zijn gebouwd op basis van continue gegevensbescherming (CDP), met behulp van VMware vSphere-API voor I/O-filterframework (VAIO), waardoor er minimaal of bijna geen gegevensverlies mogelijk is. Het maakt ook kosteneffectief herstel na noodgevallen mogelijk met behulp van minimale resources.
Gebruik Azure Site Recovery of Zerto als virtuele Azure IaaS-machines het doel voor herstel na noodgevallen zijn voor de privécloud van Azure VMware Solution.
Minimaliseer handmatige invoer met behulp van geautomatiseerde herstelplannen binnen elk van de respectieve oplossingen voor herstel na noodgevallen. Deze plannen zijn handig bij het werken met VMware Site Recovery Manager of partneroplossingen. Een herstelplan verzamelt machines in herstelgroepen voor failover. Het helpt vervolgens bij het definiëren van een systematisch herstelproces door onafhankelijke eenheden te maken die een failover kunnen uitvoeren.
Stel betrouwbaarheidstests of noodherstelanalyses ten minste één keer per jaar in om ervoor te zorgen dat herstelplannen werken zoals verwacht. De indelingsmogelijkheden van het gekozen hulpprogramma voor herstel na noodgevallen bepalen het inspanningsniveau dat betrokken is bij het uitvoeren van deze drills.
Gebruik geopolitieke regionale paren als de secundaire omgeving voor herstel na noodgevallen. Enkele van de voordelen van regionale paren zijn prioriteit voor regioherstel, sequentiële updates, fysieke isolatie en gegevenslocatie.
Houd adresruimten anders om overlappende IP-adressen tussen de twee sites te voorkomen. U kunt bijvoorbeeld gebruiken 192.168.0.0/16 voor regio 1 en 10.0.0.0/16 voor regio 2.
ExpressRoute Global Reach-connectiviteit tussen de primaire en secundaire privéclouds in verschillende regio's gebruiken. Bekijk meer netwerkoverwegingen en aanbevelingen in het relevante ontwerpgebied.

Volgende stappen

Meer informatie over overwegingen en aanbevelingen voor de eerste implementatie van Azure VMware Solution en richtlijnen voor operationele automatisering.

Platformautomatisering voor Azure VMware Solution

Share via