Overzicht van herstel na noodgevallen en richtlijnen voor infrastructuur voor SAP-workload

  • Artikel

Veel organisaties die kritieke bedrijfstoepassingen uitvoeren in Azure, hebben strategie voor hoge beschikbaarheid (HA) en herstel na noodgevallen (DR) ingesteld. Het doel van hoge beschikbaarheid is om de SLA van bedrijfssystemen te verhogen door single points of failure in de onderliggende systeeminfrastructuur te elimineren. Technologieën met hoge beschikbaarheid verminderen het effect van niet-geplande infrastructuurstoringen en helpen bij gepland onderhoud. Herstel na noodgevallen wordt gedefinieerd als beleid, hulpprogramma's en procedures om het herstel of de voortzetting van essentiële technologie-infrastructuur en -systemen mogelijk te maken na een geografisch wijdverspreide natuurlijke of door de mens geïnduceerde ramp.

Virtuele machines worden doorgaans geïmplementeerd in een beschikbaarheidsset, beschikbaarheidszones of in flexibele schaalsets om toepassingen te beschermen tegen infrastructuuronderhoud of storingen in een regio om hoge beschikbaarheid te bereiken voor SAP-werkbelasting in Azure. Maar de implementatie beschermt toepassingen niet tegen wijdverspreide rampen binnen regio's. Om toepassingen te beschermen tegen regionale noodgeval, moet er dus een strategie voor herstel na noodgevallen voor de toepassingen worden geïmplementeerd. Herstel na noodgevallen is een gedocumenteerde en gestructureerde benadering die is ontworpen om een organisatie te helpen bij het uitvoeren van de herstelprocessen als reactie op een noodgeval en om it-services te beschermen of te minimaliseren en herstel te bevorderen.

Dit document bevat informatie over het beveiligen van SAP-workloads tegen grootschalige rampen door een gestructureerde dr-aanpak te implementeren. De details in dit document worden op abstract niveau gepresenteerd op basis van verschillende Azure-services en SAP-onderdelen. De exacte herstelstrategie en de volgorde van herstel voor uw SAP-workload moeten regelmatig worden getest, gedocumenteerd en nauwkeurig worden afgestemd. Het document is ook gericht op de strategie voor herstel na noodgeval van Azure naar Azure voor SAP- workload.

Algemene overwegingen voor herstel na noodgevallen

SAP-workload in Azure wordt uitgevoerd op virtuele machines in combinatie met verschillende Azure-services om verschillende lagen (centrale services, toepassingsservers, databaseservers) van een typische SAP NetWeaver-toepassing te implementeren. Over het algemeen moet een DR-strategie worden gepland voor het hele IT-landschap dat wordt uitgevoerd in Azure, wat betekent dat er ook rekening moet worden gehouden met niet-SAP-toepassingen. De bedrijfsoplossing die wordt uitgevoerd in SAP-systemen kan niet als geheel worden uitgevoerd, als de afhankelijke services of assets niet worden hersteld op de DR-site. U moet dus een goed gedefinieerd uitgebreid noodherstelplan opstellen dat rekening houdt met alle onderdelen en systemen.

Voor herstel na noodgevallen in Azure moeten organisaties rekening houden met verschillende scenario's die failover kunnen activeren.

  • Beschikbaarheid van SAP-toepassingen of bedrijfsprocessen.
  • Azure-services (zoals virtuele machines, opslag, load balancer, enzovoort) zijn niet beschikbaar binnen een regio vanwege een wijdverspreide fout.
  • Mogelijke bedreigingen en beveiligingsproblemen voor de toepassing (bijvoorbeeld DDoS-aanval op de toepassingslaag)
  • Bedrijfsnaleving vereist operationele taken om dr-strategie te testen (bijvoorbeeld dr-foutoefening die elk jaar moet worden uitgevoerd op basis van naleving).

Om het hersteldoel voor verschillende scenario's te bereiken, moet de organisatie een overzicht van RTO (Recovery Time Objective) en RPO (Recovery Point Objective) voor hun workload maken op basis van de bedrijfsvereisten. RTO beschrijft de hoeveelheid tijd die de toepassing kan uitgevallen zijn, meestal gemeten in uren, minuten of seconden. Terwijl RPO de hoeveelheid transactionele gegevens beschrijft die door het bedrijf acceptabel is om normale bewerkingen te hervatten. Het identificeren van RTO en RPO van uw bedrijf is van cruciaal belang, omdat u hiermee uw DR-strategie optimaal kunt ontwerpen. De onderdelen (compute, opslag, database enzovoort) die betrokken zijn bij sap-werkbelasting, worden gerepliceerd naar de DR-regio met behulp van verschillende technieken (systeemeigen Azure-services, systeemeigen DB-replicatietechnologie, aangepaste scripts). Elke techniek biedt verschillende RPO's, waarvoor rekening moet worden gehouden bij het ontwerpen van een DR-strategie. In Azure kunt u enkele systeemeigen Azure-services gebruiken, zoals Azure Site Recovery, Azure Backup waarmee u kunt voldoen aan RTO en RPO van uw SAP-workloads. Raadpleeg de SLA van Azure Site Recovery en Azure Backup om optimaal af te stemmen op uw RTO en RPO.

Ontwerpoverwegingen voor herstel na noodgevallen in Azure

Er zijn verschillende elementen die u moet overwegen bij het ontwerpen van een oplossing voor herstel na noodgevallen in Azure. De principes en concepten die worden overwogen om on-premises oplossingen voor herstel na noodgevallen te ontwerpen, zijn ook van toepassing op Azure. Maar in Azure is regioselectie een belangrijk onderdeel van de ontwerpstrategie voor herstel na noodgevallen. Houd dus rekening met de volgende punten bij het kiezen van een DR-regio in Azure.

  • Nalevingsvereisten voor bedrijven of regelgeving kunnen een afstandsvereiste opgeven tussen een primaire en noodherstelsite. Een afstandsvereiste helpt om beschikbaarheid te bieden als er een natuurramp optreedt in een breder geografisch gebied. In dat geval kan een organisatie een andere Azure-regio kiezen als de site voor herstel na noodgevallen. Azure-regio's worden vaak gescheiden door een grote afstand die honderden of zelfs duizenden kilometers kan zijn, zoals in de Verenigde Staten. Vanwege de afstand is de latentie van de netwerkronde hoger, wat kan leiden tot een hogere RPO.

  • Klanten die hun on-premises strategie voor metroherstel in Azure willen nabootsen, kunnen beschikbaarheidszones gebruiken voor herstel na noodgevallen. Maar de strategie voor herstel na noodgeval voor zone-naar-zone kan niet voldoen aan de tolerantievereiste als er geografisch wijdverspreide natuurrampen zijn.

  • In Azure wordt elke regio gekoppeld aan een andere regio binnen dezelfde geografie (met uitzondering van Brazilië - zuid). Met deze benadering kunt u platformreplicatie van resources in verschillende regio's mogelijk maken. Het voordeel van het kiezen van gekoppelde regio's vindt u in het document regioparen. Wanneer een organisatie ervoor kiest om gekoppelde Azure-regio's te gebruiken, moet rekening worden gehouden met verschillende extra punten voor een SAP-workload:

    • Niet alle Azure-services bieden cross-regionale replicatie in gekoppelde regio's.

    • De Azure-services en -functies in gekoppelde Azure-regio's zijn mogelijk niet symmetrisch. Azure NetApp Files, VM-SKU's zoals M-serie die beschikbaar zijn in de primaire regio, zijn bijvoorbeeld mogelijk niet beschikbaar in de gekoppelde regio. Als u wilt controleren of het Azure-product of de azure-services beschikbaar zijn in een regio, raadpleegt u Azure-producten per regio.

    • De GRS-optie is beschikbaar voor het opslagaccount met het standaardopslagtype waarmee gegevens worden gerepliceerd naar een gekoppelde regio. Standaardopslag is echter niet geschikt voor SAP DBMS of virtuele gegevensschijven.

    • De Azure Backup-service die wordt gebruikt voor het maken van back-ups van ondersteunde oplossingen , kan alleen back-ups tussen gekoppelde regio's repliceren. Voer voor al uw andere gegevens uw eigen replicaties uit met systeemeigen DBMS-functies, zoals SQL Server Always On, SAP HANA-systeemreplicatie en andere services. Gebruik een combinatie van Azure Site Recovery, rsync of robocopy en andere software van derden voor de SAP-toepassingslaag.

Sap-workloadimplementatie raadplegen

Nadat u een DR-regio hebt geïdentificeerd, is het belangrijk dat de breedte van Azure-kernservices (zoals netwerk, rekenkracht, opslag) die u hebt geconfigureerd in de primaire regio beschikbaar is en kan worden geconfigureerd in de regio herstel na noodgeval. Organisatie moet een DR-implementatiepatroon ontwikkelen voor SAP-werkbelasting. Het implementatiepatroon varieert en moet overeenkomen met de behoeften van de organisatie.

  • Implementeer de SAP-workload voor productie in uw primaire regio en niet-productieworkload in de regio voor herstel na noodgevallen.
  • Implementeer alle SAP-werkbelastingen (productie en niet-productie) in uw primaire regio. Regio voor herstel na noodgevallen wordt alleen gebruikt als er een failover is.

In de volgende referentiearchitectuur ziet u een typisch SAP NetWeaver-systeem dat wordt uitgevoerd in Azure, samen met hoge beschikbaarheid in de primaire regio. De secundaire site die hieronder wordt weergegeven, is de site voor herstel na noodgevallen waar de SAP-systemen worden hersteld na een noodgeval. Zowel primaire als noodherstelregio's maken deel uit van hetzelfde abonnement. Als u herstel na noodgevallen voor SAP-werkbelasting wilt bereiken, moet u de herstelstrategie voor elke SAP-laag identificeren, samen met de verschillende Azure-services die door de toepassing worden gebruikt.

Organisaties moeten een DR-strategie plannen en ontwerpen voor hun hele IT-landschap. Sap-systemen die worden uitgevoerd in een productieomgeving, worden meestal geïntegreerd met verschillende services en interfaces, zoals Active Directory, DNS, toepassing van derden, enzovoort. U moet dus ook de niet-SAP-systemen en andere services opnemen in uw planning voor herstel na noodgevallen. Dit document is gericht op de herstelplanning voor SAP-toepassingen. Maar u kunt de grootte en het bereik van de planning voor noodherstel voor afhankelijke onderdelen uitbreiden om aan uw vereisten te voldoen.

Disaster Recovery reference architecture for SAP workload

Infrastructuuronderdelen van dr-oplossing voor SAP-workload

Een SAP-workload die op Azure wordt uitgevoerd, maakt gebruik van verschillende infrastructuuronderdelen om een bedrijfsoplossing uit te voeren. Als u herstel na noodgeval wilt plannen voor een dergelijke oplossing, is het essentieel dat alle infrastructuuronderdelen die zijn geconfigureerd in de primaire regio beschikbaar zijn en ook kunnen worden geconfigureerd in de REGIO voor herstel na noodgeval. De volgende infrastructuuronderdelen moeten worden meegerekend bij het ontwerpen van dr-oplossing voor SAP-werkbelasting in Azure.

  • Netwerk
  • Compute
  • Storage

Netwerk

  • ExpressRoute breidt uw on-premises netwerk uit naar de Microsoft-cloud via een privéverbinding met behulp van een connectiviteitsprovider. Bij het ontwerpen van architectuur voor herstel na noodgevallen moet u rekening houden met het bouwen van een robuuste back-endnetwerkconnectiviteit met behulp van een geografisch redundant ExpressRoute-circuit. Het is raadzaam om ten minste één ExpressRoute-circuit van on-premises naar de primaire regio in te stellen. En de andere(en) moeten verbinding maken met de regio voor herstel na noodgevallen. Raadpleeg het artikel Ontwerpen van Azure ExpressRoute voor herstel na noodgevallen, waarin verschillende scenario's worden beschreven voor het ontwerpen van herstel na noodgevallen voor ExpressRoute.

    Notitie

    U kunt een site-naar-site-VPN (S2S) instellen als back-up van Azure ExpressRoute. Zie S2S VPN gebruiken als back-up voor persoonlijke Peering van Azure ExpressRoute voor meer informatie.

  • Virtuele netwerken en subnetten omvatten alle beschikbaarheidszones in een regio. Voor herstel na noodgeval tussen twee regio's moet u afzonderlijke virtuele netwerken en subnetten configureren in de regio voor herstel na noodgevallen. Raadpleeg Over netwerken in herstel na noodgevallen van Azure-VM's voor meer informatie over de netwerkinstallatie in de dr-regio.

  • Azure Standard Load Balancer biedt netwerkelementen voor het ontwerp van hoge beschikbaarheid van uw SAP-systemen. Voor geclusterde systemen biedt Standard Load Balancer het virtuele IP-adres voor de clusterservice, zoals ASCS/SCS-exemplaren en databases die worden uitgevoerd op VM's. Als u een maximaal beschikbaar SAP-systeem wilt uitvoeren op de dr-site, moet er een afzonderlijke load balancer worden gemaakt en moet de clusterconfiguratie dienovereenkomstig worden aangepast.

  • Azure-toepassing Gateway is een load balancer voor webverkeer. Met de Web Application Firewall-functionaliteit is de goed geschikte service om webtoepassingen beschikbaar te maken op internet met verbeterde beveiliging. Azure-toepassing Gateway kan openbare (internet) of privéclients of beide gebruiken, afhankelijk van de configuratie. Na een failover moet een afzonderlijke Azure-toepassing Gateway worden geconfigureerd in de dr-regio om vergelijkbare binnenkomende HTTP(s) verkeer te accepteren.

  • Aangezien netwerkonderdelen (zoals virtueel netwerk, firewall, enzovoort) afzonderlijk worden gemaakt in de regio dr, moet u ervoor zorgen dat de SAP-werkbelasting in dr-regio is aangepast aan de netwerkwijzigingen zoals DNS-update, firewall, enzovoort.

  • Virtuele netwerken in beide regio's zijn onafhankelijk en om communicatie tussen de twee tot stand te brengen, moet u peering van virtuele netwerken tussen de twee regio's inschakelen.

Virtuele machines

  • In Azure worden verschillende onderdelen van één SAP-systeem uitgevoerd op virtuele machines met verschillende SKU-typen. Voor herstel na noodgevallen kan de beveiliging van een toepassing (SAP NetWeaver en niet-SAP) die worden uitgevoerd op Azure-VM's worden ingeschakeld door onderdelen te repliceren met behulp van Azure Site Recovery naar een andere Azure-regio of -zone. Met Azure Site Recovery worden Azure-VM's continu gerepliceerd van primaire naar site voor herstel na noodgevallen. Afhankelijk van de geselecteerde Azure DR-regio is het vm-SKU-type mogelijk niet beschikbaar op de DR-site. U moet ervoor zorgen dat de vereiste VM-SKU-typen ook beschikbaar zijn in de Azure DRregion. Controleer Azure-producten per regio om te zien of het vereiste SKU-type VM-serie beschikbaar is of niet.

    Belangrijk

    Als het SAP-systeem is geconfigureerd met flexibele schaalset met FD=1, moet u PowerShell gebruiken om Azure Site Recovery in te stellen voor herstel na noodgevallen. Op dit moment is dit de enige methode die beschikbaar is voor het configureren van herstel na noodgevallen voor VM's die zijn geïmplementeerd in een schaalset.

  • Voor databases die worden uitgevoerd op virtuele Azure-machines, is het raadzaam om systeemeigen databasereplicatietechnologie te gebruiken om gegevens te synchroniseren met de site voor herstel na noodgevallen. De grote VM's waarop de databases worden uitgevoerd, zijn mogelijk niet beschikbaar in alle regio's. Als u beschikbaarheidszones gebruikt voor herstel na noodgevallen, moet u controleren of de respectieve VM-SKU's beschikbaar zijn in de zone van uw site voor herstel na noodgevallen.

    Notitie

    Het wordt afgeraden Om Azure Site Recovery te gebruiken voor databases, omdat het geen db-consistentie garandeert en een beperking voor gegevensverloop heeft.

  • Wanneer productietoepassingen op de primaire regio altijd worden uitgevoerd, worden gereserveerde instanties doorgaans gebruikt om Azure-kosten te besparen. Als u gereserveerde instanties gebruikt, moet u zich registreren voor een looptijd van 1 jaar of drie jaar die mogelijk niet rendabel zijn voor dr-site. Het instellen van Azure Site Recovery biedt geen garantie voor de capaciteit van de vereiste VM-SKU tijdens uw failover. Als u ervoor wilt zorgen dat de CAPACITEIT van de VM-SKU beschikbaar is, kunt u een optie overwegen om capaciteitsreservering op aanvraag in te schakelen. Het reserveert rekencapaciteit in een Azure-regio of een Azure-beschikbaarheidszone voor elke tijdsduur zonder toezegging. Azure Site Recovery is geïntegreerd met capaciteitsreservering op aanvraag. Met deze integratie kunt u de kracht van capaciteitsreservering met Azure Site Recovery gebruiken om rekencapaciteit te reserveren op de DR-site en uw failovers te garanderen. Lees beperkingen en beperkingen voor capaciteitsreservering op aanvraag voor meer informatie.

  • Een Azure-abonnement heeft quota voor VM-families (bijvoorbeeld Mv2-serie) en andere resources. Soms willen organisaties een ander Azure-abonnement gebruiken voor herstel na noodgevallen. Aan elk abonnement (primair en herstel na noodgevallen) kunnen verschillende quota's zijn toegewezen voor elke VM-familie. Zorg ervoor dat het abonnement dat wordt gebruikt voor de DR-site voldoende rekenquota beschikbaar heeft.

Storage

  • Bij het inschakelen van Azure Site Recovery voor een VIRTUELE machine voor het instellen van herstel na noodgeval, worden het besturingssysteem en de lokale gegevensschijven die zijn gekoppeld aan VM's gerepliceerd naar de DR-site. Tijdens de replicatie worden schrijfbewerkingen van de VM-schijf verzonden naar een cache-opslagaccount in de bronregio. Er worden gegevens naar de doelregio verzonden en er worden herstelpunten gegenereerd op basis van de gegevens. Wanneer u een failover uitvoert voor een VIRTUELE machine tijdens herstel na noodgeval, wordt een herstelpunt gebruikt om de VIRTUELE machine in de doelregio te herstellen. Azure Site Recovery biedt echter geen ondersteuning voor alle typen opslag die beschikbaar zijn in Azure. Zie azure Site Recovery-ondersteuningsmatrix voor opslag voor meer informatie.

  • Naast door Azure beheerde gegevensschijven die zijn gekoppeld aan VM's, worden verschillende systeemeigen Azure-opslagoplossingen gebruikt voor het uitvoeren van SAP-toepassingen in Azure. De dr-benadering voor elke Azure-opslagoplossing kan verschillen, omdat niet alle beschikbare opslagservices in Azure worden ondersteund met Azure Site Recovery. Hieronder vindt u de lijst met opslagtypen die doorgaans worden gebruikt voor SAP-werkbelasting.

    Opslagtype Aanbeveling voor dr-strategie
    Beheerde schijf Azure Site Recovery
    NFS in Azure-bestanden (LRS of ZRS) Aangepast script voor het repliceren van gegevens tussen twee sites (bijvoorbeeld rsync)
    NFS in Azure NetApp Files Replicatie tussen regio's van Azure NetApp Files-volumes gebruiken
    Gedeelde Azure-schijf (LRS of ZRS) Aangepaste oplossing voor het repliceren van gegevens tussen twee sites
    SMB in Azure-bestanden (LRS of ZRS) RoboCopy gebruiken om bestanden tussen twee sites te kopiëren
    SMB in Azure NetApp Files Replicatie tussen regio's van Azure NetApp Files-volumes gebruiken

  • Voor aangepaste, gebouwde opslagoplossingen zoals NFS-cluster moet u ervoor zorgen dat de juiste DR-strategie aanwezig is.

  • Verschillende systeemeigen Azure-opslagservices (zoals Azure Files, Azure NetApp Files, Azure Shared Disk) zijn mogelijk niet beschikbaar in alle regio's. Zorg er dus voor dat de respectieve opslagservice wordt aangeboden op de DR-site om na een failover vergelijkbare SAP-installatie in de DR-regio te hebben. Raadpleeg Azure-producten per regio voor meer informatie.

  • Als u beschikbaarheidszones gebruikt voor herstel na noodgevallen, moet u rekening houden met de volgende punten:

    • De functie Azure NetApp Files is nog niet zonebewust. Momenteel wordt de functie Azure NetApp Files niet geïmplementeerd in alle beschikbaarheidszones in een Azure-regio. Het kan dus gebeuren dat de Azure NetApp Files-service niet beschikbaar is in de gekozen beschikbaarheidszone voor uw DR-strategie.
    • Replicatie tussen regio's van Azure NetApp-bestandsvolumes is alleen beschikbaar in paren van vaste regio's, niet in meerdere zones.

  • Als u uw opslag hebt geconfigureerd met Active Directory-integratie, moet dezelfde installatie ook worden uitgevoerd op het opslagaccount van de DR-site.

  • Voor gedeelde Azure-schijven is clustersoftware vereist, zoals Windows Server Failover Cluster (WSFC) die communicatie tussen clusterknooppunten en schrijfvergrendeling afhandelt. Dus als u een dr-strategie voor een gedeelde Azure-schijf wilt hebben, moet u ook een gedeelde schijf hebben die wordt beheerd door clustersoftware op de DR-site. U kunt vervolgens script gebruiken om gegevens te kopiëren van een gedeelde schijf die is gekoppeld aan een cluster in de primaire regio naar de gedeelde schijf die is gekoppeld aan een ander cluster in dr-regio.

Volgende stappen