Richtlijnen voor herstel na noodgevallen voor SAP-toepassing
Als u herstel na noodgeval (DR) wilt configureren voor SAP-workload in Azure, moet u het proces regelmatig testen, afstemmen en bijwerken. Het testen van herstel na noodgevallen helpt bij het identificeren van de volgorde van afhankelijke services die vereist zijn voordat u dr-failover van SAP-werkbelasting kunt activeren of het systeem op de secundaire site kunt starten. Organisaties hebben meestal hun SAP-systemen verbonden met ACTIVE Directory -services (AD) en DOMAIN Name System (DNS) om correct te functioneren. Wanneer u DR instelt voor uw SAP-workload, moet u ervoor zorgen dat AD- en DNS-services werken voordat u SAP- en andere niet-SAP-systemen herstelt, om ervoor te zorgen dat de toepassing correct functioneert. Voor hulp bij het beveiligen van Active Directory en DNS leert u hoe u Active Directory en DNS beveiligt. De aanbeveling voor herstel na noodgevallen voor SAP-toepassingen die in dit document worden beschreven, is op abstract niveau. U moet uw strategie voor herstel na noodgevallen ontwerpen op basis van uw specifieke installatie en het end-to-end scenario documenteren.
Dr-aanbeveling voor SAP-workloads
Meestal in gedistribueerde SAP NetWeaver-systemen; centrale services, database en gedeelde opslag (NFS/SMB) zijn single point of failures (SPOF). Als u het effect van verschillende SPOF's wilt beperken, moet u redundantie van deze onderdelen instellen. De redundantie van deze SPOF-onderdelen in de primaire regio wordt bereikt door hoge beschikbaarheid te configureren. De installatie van hoge beschikbaarheid van het onderdeel beschermt SAP-systeem tegen lokale fouten of rampen. Maar om SAP-toepassingen te beschermen tegen geografisch verspreide noodgevallen, moet de DR-strategie worden geïmplementeerd voor alle SAP-onderdelen.
Voor SAP-systemen die worden uitgevoerd op virtuele machines, kunt u Azure Site Recovery gebruiken om een plan voor herstel na noodgevallen te maken. Hieronder vindt u de aanbevolen benadering voor herstel na noodgevallen voor elk onderdeel van een SAP-systeem. Zelfstandige niet-NetWeaver SAP-engines, zoals TREX en niet-SAP-toepassingen, worden niet behandeld in dit document.
| Onderdelen | Aanbeveling |
|---|---|
| SAP-webdispatcher | VM repliceren met Behulp van Azure Site Recovery |
| SAP Central Services | VM repliceren met Behulp van Azure Site Recovery |
| SAP-toepassingsserver | VM repliceren met Behulp van Azure Site Recovery |
| SAP-database | De replicatiemethode gebruiken die wordt aangeboden door de database |
| Gedeelde opslag | Inhoud repliceren met behulp van de juiste methode per opslagtype |
SAP-webdispatcher
Het SAP Web Dispatcher-onderdeel werkt als een load balancer voor SAP-verkeer tussen SAP-toepassingsservers. U hebt verschillende opties om een hoge beschikbaarheid van het SAP Web Dispatcher-onderdeel in de primaire regio te bereiken. Zie Hoge beschikbaarheid van de SAP Web Dispatcher- en SAP Web Dispatcher HA-installatie in Azure voor meer informatie over deze optie.
- Optie 1: Hoge beschikbaarheid met behulp van clusteroplossing.
- Optie 2: Hoge beschikbaarheid met parallelle SAP Web Dispatchers.
U kunt Azure Site Recovery gebruiken om dr te bereiken voor de maximaal beschikbare SAP Web Dispatcher-installatie in de primaire regio. Voor parallelle web-dispatchers (optie 2) die worden uitgevoerd in de primaire regio, kunt u Azure Site Recovery configureren voor herstel na noodgeval. Maar voor SAP Web Dispatcher die is geconfigureerd met optie 1 in de primaire regio, moet u na een failover enkele aanvullende wijzigingen aanbrengen om vergelijkbare hoge beschikbaarheidsconfiguratie in de dr-regio te hebben. Omdat de configuratie van hoge beschikbaarheid van SAP Web Dispatcher met clusteroplossing op dezelfde manier is geconfigureerd als SAP Central-services. Volg dezelfde richtlijnen als vermeld voor SAP Central Services.
SAP Central Services
De centrale SAP-services bevatten de server voor wachtrijen en berichten, een van de SPOF's van uw SAP-toepassing. In een SAP-systeem kan er slechts één exemplaar zijn en kan het worden geconfigureerd voor hoge beschikbaarheid. Lees hoge beschikbaarheid voor SAP Central Service om inzicht te hebben in de verschillende oplossing voor hoge beschikbaarheid voor SAP-werkbelasting in Azure.
Het configureren van hoge beschikbaarheid voor SAP Central Services beschermt resources en processen tegen lokale incidenten. Voor herstel na noodgevallen voor SAP Central Services kunt u Azure Site Recovery gebruiken. Azure Site Recovery repliceert VM's en de gekoppelde beheerde schijven, maar er zijn aanvullende overwegingen voor de DR-strategie. Raadpleeg de volgende sectie voor meer informatie, op basis van het besturingssysteem dat wordt gebruikt voor SAP Central-services.
Voor SAP-systeem wordt de redundantie van het SPOF-onderdeel in de primaire regio bereikt door hoge beschikbaarheid te configureren. Als u na een failover vergelijkbare instellingen voor hoge beschikbaarheid wilt instellen in de regio voor herstel na noodgevallen, moet u rekening houden met aanvullende punten. Dit omvat het opnieuw configureren van het cluster, het controleren of SAP-gedeelde mappen beschikbaar zijn en vm's en de beheerde schijven repliceren naar de DR-site met Azure Site Recovery. In Linux kan de hoge beschikbaarheid van sap-toepassingen worden bereikt met behulp van de pacemaker-clusteroplossing. In het onderstaande diagram ziet u de verschillende onderdelen die betrokken zijn bij het configureren van hoge beschikbaarheid voor SAP-centrale services met Pacemaker. Er moet rekening worden gehouden met elk onderdeel om vergelijkbare hoge beschikbaarheid in te stellen op de DR-site. Als u SAP Web Dispatcher hebt geconfigureerd met behulp van de pacemaker-clusteroplossing, zou dezelfde overweging ook van toepassing zijn.
Interne load balancer
Azure Site Recovery repliceert VM's naar de DR-site, maar repliceert azure load balancer niet. U moet vooraf of na een failover een afzonderlijke interne load balancer maken op de DR-site. Als u vooraf een interne load balancer maakt, maakt u een lege back-endpool en voegt u VM's toe na de failovergebeurtenis.
Pacemaker-clusteroplossing
De configuraties van een pacemakercluster bevinden zich in lokale bestanden van VM's, die worden gerepliceerd naar de DR-site met Azure Site Recovery. De configuratie van het pacemakercluster werkt niet direct op de VM's na een failover. Aanvullende clusterconfiguratie is vereist om de oplossing te laten werken.
Lees deze blogs voor meer informatie over de herconfiguratie van pacemakerclusters in de DR-regio, op basis van het type opslag- en afschermingsmechanisme.
- SAP ASCS/ERS HA-cluster met SBD-apparaat (met iSCSI-doelserver) failover naar dr-regio met behulp van Azure Site Recovery.
- FAILOVER van SAP ASCS HA-cluster (in Linux-besturingssysteem) naar dr-regio met behulp van Azure Site Recovery.
Gedeelde SAP-mappen voor Linux
De instelling voor hoge beschikbaarheid van het SAP NetWeaver- of ABAP-platform maakt gebruik van replicatieserver voor het bereiken van redundantie op toepassingsniveau voor de wachtrijservice van het SAP-systeem met de pacemaker-clusterconfiguratie. De instelling voor hoge beschikbaarheid van SAP Central-services (ASCS en ERS) maakt gebruik van NFS-koppelingen. U moet er dus voor zorgen dat binaire SAP-bestanden en -gegevens in deze NFS-koppelingen worden gerepliceerd naar de DR-site. Azure Site Recovery repliceert VM's en een lokale beheerde schijf die is gekoppeld, maar repliceert geen NFS-koppelingen. Op basis van het type NFS-opslag dat is geconfigureerd voor de installatie, moet u ervoor zorgen dat de gegevens worden gerepliceerd en beschikbaar zijn op de DR-site. De methodologie voor replicatie tussen regio's voor elke opslag wordt op abstract niveau gepresenteerd. U moet de exacte stappen voor het repliceren van opslag bevestigen en testen uitvoeren.
| Gedeelde SAP-mappen | Replicatie tussen regio's |
|---|---|
| NFS in Azure-bestanden | Aangepast (zoals rsync) |
| NFS op ANF | Ja (replicatie tussen regio's) |
| NFS-cluster | Aanpassen |
Tip
U wordt aangeraden een van de eigen NFS-services van Azure te implementeren: NFS in Azure Files of NFS ANF-volumes voor het opslaan van gedeelde gegevens in een maximaal beschikbaar SAP-systeem. Houd er rekening mee dat we SAP-referentiearchitecturen de nadruk leggen op het gebruik van NFS-clusters.
Fencing Mechanisme
Ongeacht het besturingssysteem (SLES of RHEL) en de bijbehorende versie, vereist pacemaker een geldig afschermingsmechanisme om de hele oplossing goed te laten werken. Op basis van het type fencingmechanisme dat u in uw primaire regio hebt ingesteld, moet u ervoor zorgen dat hetzelfde afschermingsmechanisme is ingesteld op de DR-site na een failover.
| Fencing Mechanisme | Aanbeveling voor herstel na noodgevallen in meerdere regio's |
|---|---|
| SBD met iSCSI-doelserver | ISCSI-doelserver repliceren met behulp van Azure Site Recovery. Op DR-VM's detecteert u de iSCSI-schijf opnieuw. |
| Azure Fence-agent | Schakel Managed System Identities (MSI) in op DR-VM's. Aangepaste rollen toewijzen. Werk de omheiningsagentresource in het cluster bij. |
| SBD met behulp van een gedeelde Azure-schijf* | Configureer de nieuwe gedeelde Azure-schijf in de dr-regio. Koppel Azure Shared Disk aan DR-VM's na een failover. Een gedeeld Azure-schijf-SBD-apparaat instellen. |
*ZRS voor gedeelde Azure-schijven is beschikbaar in beperkte regio's.
Notitie
We raden u aan om hetzelfde afschermingsmechanisme te hebben voor zowel de primaire als de DR-regio voor het gemak van de werking en failover. Het is niet raadzaam om na een failover naar dr-site een ander fencingmechanisme te hebben.
SAP-toepassingsservers
In de primaire regio wordt de redundantie van de SAP-toepassingsservers bereikt door exemplaren in meerdere VM's te installeren. Als u herstel na noodgevallen voor SAP-toepassingsservers wilt hebben, kan Azure Site Recovery worden ingesteld voor elke VM van de toepassingsserver. Voor gedeelde opslag (transportbestandssysteem, interfacegegevensbestandssysteem) die is gekoppeld aan de toepassingsservers, volgt u de juiste dr-procedure op basis van het type gedeelde opslag.
SAP-databaseservers
Gebruik voor databases met SAP-werkbelasting de systeemeigen DBMS-replicatietechnologie om DR te configureren. Het gebruik van Azure Site Recovery voor databases wordt niet aanbevolen, omdat het geen garantie biedt voor DB-consistentie en gegevensverloopbeperking heeft. De replicatietechnologie voor elke database is anders, dus volg de respectieve databaserichtlijnen. In de volgende tabel ziet u de lijst met databases die worden gebruikt voor SAP-workloads en de bijbehorende aanbeveling voor herstel na noodgevallen.
| Database | Aanbeveling voor herstel na noodgevallen |
|---|---|
| SAP HANA | HANA-systeemreplicatie (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Herstel na noodgevallen met hoge beschikbaarheid (HADR) |
| Microsoft SQL | Microsoft SQL AlwaysOn |
| SAP ASE | ASE HADR Always On |
| SAP MaxDB | Stand-bydatabase |
Voor een oplossing die is geoptimaliseerd voor kosten, kunt u zelfs de optie voor back-up en herstel gebruiken voor herstel na noodgeval.
Back-up maken en herstellen
Back-up en herstel is een andere oplossing die u kunt gebruiken voor herstel na noodgevallen voor uw SAP-workloads als de zakelijke RTO en RPO niet kritiek zijn. U kunt Azure Backup, een cloudgebaseerde back-upservice gebruiken om kopieën te maken van verschillende onderdelen van uw SAP-workload, zoals virtuele machines, beheerde schijven en ondersteunde databases. Zie de ondersteuningsmatrix van Azure Backup voor meer informatie over de algemene ondersteuningsinstellingen en -beperkingen voor Azure Backup-scenario's en -implementaties.
| Services | Onderdeel | Ondersteuning voor Azure Backup |
|---|---|---|
| Compute | Azure VM's | Ondersteund |
| Storage | Azure Managed Disks, inclusief gedeelde schijven | Ondersteund |
| Storage | Azure-bestandsshare - SMB (Standard of Premium) | Ondersteund |
| Storage | Azure-blobs | Ondersteund |
| Storage | Azure File Shared - NFS (Standard of Premium) | Niet ondersteund |
| Storage | Azure NetApp Files | Niet ondersteund |
| Database | SAP HANA-database in Virtuele Azure-machines | Ondersteund |
| Database | SQL-server in Azure-VM's | Ondersteund |
| Database | Oracle | Ondersteund* |
| Database | IBM DB2, SAP ASE | Niet ondersteund |
Notitie
*Azure Backup ondersteunt Oracle-database met behulp van Azure VM-back-up voor databaseconsistente momentopnamen.
Azure Backup biedt geen ondersteuning voor alle Azure-opslag en -databases die worden gebruikt voor SAP-werkbelasting.
Azure Backup slaat back-ups op in de Recovery Service-kluis, die uw gegevens repliceert op basis van het gekozen replicatietype (LRS, ZRS of GRS). Voor geografisch redundante opslag (GRS) worden uw back-upgegevens gerepliceerd naar een gekoppelde secundaire regio. Als de functie voor herstel in meerdere regio's is ingeschakeld, kunt u gegevens van het ondersteunde beheertype in de secundaire regio herstellen.
Back-up en herstel zijn meer traditionele kosten geoptimaliseerde benadering, maar wordt geleverd met een afweging van een hogere RTO. Als u alle toepassingen vanuit de back-up wilt herstellen als er een failover naar de regio herstel na noodgeval is. U moet dus uw bedrijfsbehoefte analyseren en dienovereenkomstig een DR-strategie ontwerpen.