Bedrijfscontinuïteit en herstel na noodgevallen voor een SAP-migratie

Dit artikel is gebaseerd op de overwegingen en aanbevelingen in het ontwerpgebied van de Azure-landingszone voor BCDR. In dit artikel worden unieke beperkingen beschreven voor landingszones die ondersteuning bieden voor een SAP-platform. SAP is een bedrijfskritiek platform, dus u moet ook andere bedrijfskritieke richtlijnen opnemen in uw ontwerp.

Scenario en bereik

Neem principes op in uw architectuur die betrekking hebben op bcdr-scenario's (on-premises bedrijfscontinuïteit en herstel na noodgevallen). Deze principes zijn ook van toepassing op Azure. Maar Azure heeft mogelijk meer hardwarecapaciteit dan uw on-premises omgeving om te compenseren voor een hostfout. Als u zelfs de grootste virtuele Azure-machines (VM's) automatisch wilt herstellen, kunt u ze zo configureren dat ze opnieuw worden opgestart op een andere server. Stel uw Azure-implementaties in om dezelfde voorwaarden te gebruiken als uw on-premises implementaties. Als u automatische failoverclusterconfiguraties gebruikt om on-premises systemen of bare-metalhardware te implementeren, implementeert u deze op dezelfde manier in Azure. Voor SAP-toepassingen die de meest kritieke bedrijfsprocessen van uw organisatie uitvoeren, is het volgende vereist:

• Beschikbaarheid van services en bedrijfsprocessen.

• Beoogde hersteltijd (RPO's) voor foutscenario's of noodscenario's.

• Beoogde herstelpunten (RPO's) voor foutscenario's.

• Operationele en levenscyclusbeheertaken en technologie die wordt uitgevoerd tijdens foutscenario's. Deze beheertaken omvatten het patchen van gastbesturingssystemen en databasebeheersystemen, klonen en vernieuwen van SAP-systemen.

Tip

Bepaal een HADR-oplossing (hoge beschikbaarheid en herstel na noodgevallen) voor elk van de archetypen in uw SAP-landschap vroeg. Zorg ervoor dat de oplossing alle SAP-onderdelen omvat.

Configureer een HADR-oplossing in Azure vroeg, in ten minste één landschap en houd deze actief. Vervolgens kunnen uw teams ervaring krijgen met de technologieën van de oplossing, die mogelijk verschillen van bestaande technologieën. Configureer HADR vroeg om te helpen bij het ontwikkelen en ontwikkelen van uw standaardbedrijfsprocedures (SOP's).

Plan om volledige hoge beschikbaarheid, herstel na noodgevallen en back-upbeveiliging voor productieworkloads te hebben zodra het systeem live is.

In dit artikel worden de volgende aspecten van BCDR behandeld voor een SAP-scenario op ondernemingsniveau:

• Hoge beschikbaarheid binnen een Azure-regio

• Overwegingen voor back-up en herstel

• Criteria om te bepalen tussen herstel na noodgevallen tussen regio's en regio's

Hoge beschikbaarheid binnen een Azure-regio

De volgende secties bevatten ontwerpoverwegingen en aanbevelingen voor hoge beschikbaarheid binnen een Azure-regio voor een SAP Enterprise-scenario.

Ontwerpoverwegingen voor hoge beschikbaarheid

Wanneer u hoge beschikbaarheid implementeert, is het doel om beschikbaarheid te bieden voor het single point of failure van SAP-software, zoals:

• Databasebeheersystemen.

• Single points of failure in an application, like SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) en SAP Central Services (SCS). Voorbeelden van hoge beschikbaarheid zijn SAP NetWeaver en de SAP S/4HANA-architectuur.

• Andere hulpprogramma's, zoals SAP Web Dispatcher.

Voor andere scenario's kunt u de beschikbaarheid van infrastructuurfouten of softwarefouten niet beperken. Pas beschikbaarheid toe op alle benodigde taken voor levenscyclusbeheer. U kunt bijvoorbeeld het besturingssysteem patchen op de VM's, het databasebeheersysteem (DBMS) en de SAP-software. Als u storingen wilt minimaliseren die kunnen optreden tijdens geplande downtime en levenscyclusbeheerbewerkingen, gebruikt u veelgebruikte hulpprogramma's waarmee u uw systemen kunt beschermen tegen niet-geplande serviceonderbrekingen.

SAP- en SAP-databases ondersteunen automatische failoverclusters. In Windows ondersteunt de functie failoverclustering van Windows Server 2022 failover. In Linux ondersteunen Linux Pacemaker of partnerhulpprogramma's zoals SIOS Protection Suite en Veritas InfoScale failover. In Azure kunt u alleen een configuratie voor hoge beschikbaarheid van een subset implementeren in uw eigen datacenter.

Zie Ondersteunde scenario's voor SAP-workloads op Azure-VM's en ondersteunde scenario's voor SAP HANA Large Instances voor meer informatie.

Voor de DBMS-laag is het algemene architectuurpatroon het tegelijkertijd repliceren van databases en met verschillende opslagstacks dan de stacks die de primaire VM's en secundaire VM's gebruiken. Azure biedt geen ondersteuning voor architecturen waarin de primaire VM's en secundaire VM's opslag delen voor DBMS-gegevens. Azure biedt ook geen ondersteuning voor transactielogboeken of opnieuw uitvoeren van logboeken. Het leidende principe is het gebruik van twee onafhankelijke opslagstacks, zelfs als ze zijn gebaseerd op NFS-shares (Network File System). Deze beperkingen zijn exclusief voor Azure-oplossingen en niet on-premises oplossingen.

Azure biedt andere opties omdat het delen van NFS en Server Message Block ondersteunt. U kunt gedeelde Azure-schijven gebruiken in Windows voor ASCS- en SCS-onderdelen en specifieke scenario's voor hoge beschikbaarheid. Stel uw failoverclusters afzonderlijk in voor SAP-toepassingslaagonderdelen en de DBMS-laag. Azure biedt geen ondersteuning voor architecturen voor hoge beschikbaarheid die SAP-toepassingslaagonderdelen en de DBMS-laag combineren tot één failovercluster.

De meeste failoverclusters voor SAP-toepassingslaagonderdelen en de DBMS-laag vereisen een virtueel IP-adres voor een failovercluster. Een veelvoorkomende uitzondering is wanneer u Oracle Data Guard gebruikt, waarvoor geen virtueel IP-adres is vereist. Azure Load Balancer moet het virtuele IP-adres voor alle andere gevallen verwerken. U kunt één load balancer gebruiken voor elke clusterconfiguratie. U wordt aangeraden de standaardversie van de load balancer te gebruiken. Zie Openbare eindpuntconnectiviteit voor VM's met behulp van Standard Azure Load Balancer in scenario's met hoge beschikbaarheid van SAP voor meer informatie.

Zie architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver voor meer informatie.

In de volgende tabel ziet u de SLA's (Service Level Agreements) op platformniveau voor verschillende implementatieopties voor hoge beschikbaarheid. De partners die de beheerde services bieden, bieden ook de SLA op toepassingsniveau.

Laag	Scenario voor hoge beschikbaarheid	Platform SLA
1	Availability zone	99,99%
2	Beschikbaarheidsset	99,95%
3	Eén VIRTUELE machine (zelfherstel)	99.90%

Azure-beschikbaarheidssets versus beschikbaarheidszones

Voordat u uw infrastructuur voor hoge beschikbaarheid implementeert, moet u bepalen of u wilt implementeren met een Azure-beschikbaarheidsset of een beschikbaarheidszone , afhankelijk van de regio die u kiest. De belangrijkste verschillen voor VM's die u implementeert met een beschikbaarheidsset zijn:

• De VM's worden niet verdeeld over verschillende beschikbaarheidszones.

• Het type VM's dat u kunt implementeren via één beschikbaarheidsset, is beperkt omdat de eerste VM die u in de set implementeert, de host definieert. U kunt bijvoorbeeld vm's uit de M-serie en vm's uit de E-serie niet combineren in één beschikbaarheidsset.

Wanneer u uw architectuur voor hoge beschikbaarheid implementeert in verschillende beschikbaarheidszones, kunt u een hogere SLA voor de VM's hebben. Zie Sla's voor Azure-VM's voor meer informatie. Afhankelijk van de Azure-regio kunt u verschillende netwerklatentievoorwaarden detecteren in netwerkverkeer tussen VM's. Zie SAP-workloadconfiguraties met Azure-beschikbaarheidszones voor meer informatie.

Als u een zonegebonden implementatiemethode kiest, kunt u overwegen hoe latentie tussen zones voor de gekozen Azure-regio van invloed kan zijn op de ontwerpopties voor prestaties en architectuur. Houd rekening met de latentie tussen de toepassingsserver en de database en tussen de twee databaseknooppunten.

Als u een actieve/passieve zone-implementatie gebruikt voor de toepassingsserverlaag waarin toepassingsservers verbinding moeten maken met de database in dezelfde beschikbaarheidszone, configureert u automatisering en maakt u een SOP om snel en geautomatiseerd herstel mogelijk te maken als er een databasefailover optreedt.

Als u beschikbaarheidszones in uw SAP-oplossing gebruikt, ontwerpt u ook alle andere Azure-services en infrastructuuronderdelen in uw SAP-landschap voor zoneredundantie, zodat u echte zoneredundantie kunt bereiken. Voorbeelden van services en onderdelen om rekening mee te houden zijn Azure ExpressRoute-gateways, Load Balancer, Azure Files, Azure NetApp Files, omgekeerde proxy's, firewalls, antivirusservices en back-upinfrastructuur.

Ontwerpaanvelingen voor hoge beschikbaarheid

• Azure biedt verschillende opties om te voldoen aan de SLA's voor de infrastructuur van uw toepassing. U moet dezelfde optie kiezen voor alle drie de SAP-onderdelen: centrale services, de toepassingsserver en de database. Zie SLA's voor onlineservices voor meer informatie over SLA's voor VM's, beschikbaarheidssets en beschikbaarheidszones.

• Wanneer u VM's in een beschikbaarheidsset implementeert, voorkomt de uitlijning met fout- en updatedomeinen dat de VM's zich op dezelfde hosthardware bevinden, wat bescherming biedt tegen hardwarefouten. Wanneer u VM's implementeert via beschikbaarheidszones en verschillende zones gebruikt, maakt u de VM's op verschillende fysieke locaties. Deze configuratie biedt extra bescherming tegen energie-, koelings- of netwerkproblemen die van invloed zijn op de datacenters van de zone als geheel. Maar u kunt Azure-beschikbaarheidssets niet implementeren binnen een Azure-beschikbaarheidszone, tenzij u nabijheidsplaatsingsgroepen gebruikt.

  Als u een zonegebonden implementatiebenadering kiest, worden de SAP DBMS-, centrale services en toepassingslagen uitgevoerd in verschillende beschikbaarheidszones. Maar elke beschikbaarheidszone heeft waarschijnlijk meerdere toepassingsservers. In dit scenario profiteren de toepassingsservers in elke zone niet automatisch van foutdomeinen en updatedomeinen. U kunt beschikbaarheidssets gebruiken om deze voordelen te verkrijgen. Zie Azure-nabijheidsplaatsingsgroepen voor optimale netwerklatentie met SAP voor meer informatie.

• Wanneer u beschikbaarheidssets maakt, gebruikt u het maximum aantal foutdomeinen en updatedomeinen die beschikbaar zijn. Als u bijvoorbeeld meer dan twee VM's in één beschikbaarheidsset implementeert, gebruikt u het maximum aantal foutdomeinen (drie). En gebruik voldoende updatedomeinen om het effect van mogelijke fysieke hardwarestoringen, netwerkstoringen of stroomonderbrekingen te beperken, naast gepland Onderhoud van Azure. Het standaardaantal foutdomeinen is twee en u kunt het later niet online wijzigen.

• In een implementatie van een beschikbaarheidsset moet elk onderdeel van een SAP-systeem zich in een eigen beschikbaarheidsset bevinden. SAP-centrale services, de database en toepassings-VM's moeten zich in hun eigen beschikbaarheidssets bevinden.

• Wanneer u Azure Proximity-plaatsingsgroepen gebruikt in een implementatie van een beschikbaarheidsset, moet u ervoor zorgen dat alle drie de SAP-onderdelen (centrale services, de toepassingsserver en de database) zich in dezelfde nabijheidsplaatsingsgroep bevinden.

• Als u nabijheidsplaatsingsgroepen gebruikt, gebruikt u er een voor elke SAP System Identification (SID). Groepen omvatten geen beschikbaarheidszones of Azure-regio's.

• Wanneer u Azure-nabijheidsplaatsingsgroepen gebruikt in een implementatie van beschikbaarheidszones, moet u ervoor zorgen dat de twee SAP-onderdelen (centrale services en de toepassingsserver) zich in dezelfde nabijheidsplaatsingsgroep bevinden. De database-VM's in de twee zones maken geen deel meer uit van de nabijheidsplaatsingsgroepen. De nabijheidsplaatsingsgroepen voor elke zone zijn afgestemd op de implementatie van de VIRTUELE machine waarop de SAP ASCS- en SCS-exemplaren worden uitgevoerd. Het voordeel van deze configuratie is dat u meer flexibiliteit hebt om het formaat van VM's te wijzigen. U kunt ook eenvoudig overschakelen naar nieuwe VM-typen in de DBMS-laag of de toepassingslaag van het SAP-systeem.

• Azure biedt geen ondersteuning voor het combineren van ASCS en hoge beschikbaarheid van databases in één Linux Pacemaker-cluster. Scheid ze in afzonderlijke clusters. U kunt maximaal vijf centrale servicesclusters combineren in een paar vm's.

• Gebruik Standard Load Balancer vóór ASCS- en databaseclusters.

• Voer alle productiesystemen uit op Azure Premium SSD's en gebruik Azure NetApp Files of Azure Ultra Disk Storage. Zorg er minimaal voor dat de besturingssysteemschijf zich op de Premium-laag bevindt, zodat u de prestaties kunt verbeteren en de beste SLA kunt krijgen.

• Implementeer beide VM's in het paar met hoge beschikbaarheid in een beschikbaarheidsset of in beschikbaarheidszones. Zorg ervoor dat deze VM's dezelfde grootte hebben en dezelfde opslagconfiguratie hebben.

• Gebruik systeemeigen databasereplicatietechnologie om de database te synchroniseren in een paar met hoge beschikbaarheid.

• Gebruik een van de volgende services om SAP Central-servicesclusters uit te voeren, afhankelijk van het besturingssysteem:

  • Een SUSE Linux Enterprise Server Pacemaker-cluster ondersteunt een Azure fence-agent en maximaal drie knooppuntisolatieapparaten.

  • Een Red Hat Enterprise Linux Pacemaker-cluster ondersteunt een Azure Fence-agent en biedt geen ondersteuning voor knooppuntisolatieapparaten.

  • Een Windows-cluster.

  • SAP-gecertificeerde niet-Microsoft-clustersoftware.

• Stel de time-outparameters van het cluster in zoals wordt aanbevolen in de documentatie voor centrale services en databaseclusters.

Opslag voor SAP-workloads

• Kies de juiste opslagopties wanneer u ontwerpt voor tolerantie in uw SAP-workload. Het juiste Azure Storage-ontwerp voor SAP-workloads kan latentie minimaliseren en doorvoer maximaliseren. Houd rekening met uw implementatie en hoe de volgende richtlijnen u kunnen helpen bij het nemen van architectuurbeslissingen voor uw SAP op Azure-implementatie. Zie Azure-opslagtypen voor SAP-workloads voor meer informatie.

• U moet SAP HANA alleen uitvoeren in Azure op SAP-gecertificeerde typen opslag. U moet bepaalde volumes uitvoeren op bepaalde schijfconfiguraties. Configuraties kunnen bijvoorbeeld Write Accelerator inschakelen of Premium SSD-opslag gebruiken. U moet er ook voor zorgen dat het bestandssysteem dat wordt uitgevoerd op opslag compatibel is met de DBMS die op de computer wordt uitgevoerd. Zie Opslagconfiguraties voor SAP HANA voor meer informatie.

• Naast door Azure beheerde gegevensschijven die zijn gekoppeld aan VM's, worden sap-toepassingen in Azure uitgevoerd in verschillende systeemeigen gedeelde opslagoplossingen van Azure. Uw configuratie voor hoge beschikbaarheid kan verschillen omdat Azure Site Recovery geen ondersteuning biedt voor sommige opslagservices die beschikbaar zijn in Azure. Gebruik de volgende opslagtypen voor SAP-workloads.

  Opslagtype	Ondersteuning voor configuratie met hoge beschikbaarheid
  Gedeelde Azure-schijven (lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS))	Windows Server 2022-failovercluster. Zie Sap-hoge beschikbaarheid ontwerpen met Failoverclustering van Windows Server 2022 voor configuratiedetails.
  NFS in Azure Files (LRS of ZRS)	Pacemaker-cluster in Linux-omgevingen. Controleer de beschikbaarheid van NFS in verschillende regio's.
  NFS in Azure NetApp Files	Pacemaker-cluster in Linux-omgevingen. Zie Azure NetApp Files voor SAP-VM's voor meer informatie.
  SMB in Azure Files (LRS of ZRS)	Windows Server 2022-failovercluster. Zie Sap NetWeaver met hoge beschikbaarheid installeren met Azure Files SMB voor configuratiedetails.
  SMB in Azure NetApp Files	Windows Server 2022-failovercluster. Zie Hoge beschikbaarheid voor SAP NetWeaver met Azure NetApp Files (SMB) voor SAP-toepassingen voor configuratiedetails.

• In plaats van azure-systeemeigen gedeelde opslagservices kunt u traditionele NFS-clusters (op basis van replicatie van gedistribueerd gerepliceerde blokapparaten), GlusterFS of een gedeeld clustervolume gebruiken met Opslagruimten Direct als een alternatieve oplossing voor gedeelde opslag om SAP-workloads uit te voeren in Azure. Deze opties zijn met name handig wanneer azure-systeemeigen gedeelde opslagservices niet beschikbaar zijn in de doelregio van Azure of geen ondersteuning bieden voor de doelarchitectuur. Zie Azure-producten per regio voor meer informatie over de beschikbaarheid van opslagservices.

• Zie storage-aanbevelingen en richtlijnen voor het instellen van herstel na noodgevallen voor meer informatie over opslagopties die beschikbaar zijn voor SAP-workloads in Azure.

Back-ups en herstellen

In de volgende secties worden ontwerpoverwegingen en aanbevelingen voor back-up en herstel in een SAP-scenario beschreven.

Hoewel back-up en herstel doorgaans niet worden beschouwd als een adequate oplossing voor hoge beschikbaarheid voor een SAP-productieworkload, biedt de technologie andere voordelen. De meeste bedrijven die SAP-toepassingen gebruiken, moeten voldoen aan de nalevingsregels waarvoor langetermijnopslag van back-ups is vereist. In andere scenario's moet u ook een back-up hebben waaruit u kunt herstellen. In deze richtlijnen wordt ervan uitgegaan dat u al back-ups en herstel hebt gemaakt en de aanbevolen procedures voor SAP-toepassingen hebt gevolgd. Dit betekent dat u het volgende kunt doen:

• Voer op elk moment een herstel naar een bepaald tijdstip uit voor uw productiedatabases, in een tijdsbestek dat voldoet aan uw RTO. Herstel naar een bepaald tijdstip biedt doorgaans bescherming tegen operatorfouten, zoals het verwijderen van gegevens, op de DBMS-laag of via SAP.

• Onderhoud een archief om uw langetermijnback-ups te bewaren om te voldoen aan de nalevingsvoorschriften.

• Gebruik databaseback-ups om het SAP-systeem te klonen en de back-ups te herstellen op een andere server of VM.

• Gebruik productiedatabasegegevens van databaseback-ups om niet-productiesystemen te vernieuwen.

• Back-ups maken van SAP-toepassingsservers en VM's, schijven of VM-momentopnamen.

• Maak een back-up van een SAP HANA-systeem waarvoor replicatie is ingeschakeld.

• Maak een back-up van momentopnamen van SAP HANA-database-exemplaren.

Als u een back-up maakt en on-premises herstelt, moet u deze mogelijkheden overbrengen naar SAP-systemen in Azure. Als u tevreden bent over uw huidige oplossing, controleert u of uw back-upleverancier Ondersteuning biedt voor Azure-implementaties of of deze een SaaS-oplossing (Software as a Service) voor Azure heeft.

Azure biedt een Back-up-SaaS-service met de naam Azure Backup, die VM-momentopnamen maakt en streaming SQL Server - en SAP HANA-back-ups beheert. Als u Azure NetApp Files gebruikt om uw SAP HANA-databases op te slaan, kunt u back-ups uitvoeren op basis van HANA-consistente opslagmomentopnamen.

U kunt ook Azure Backup gebruiken om back-ups te maken van databases waarvoor SAP HANA-systeemreplicatie (HSR) is ingeschakeld. Azure Backup beheert automatisch back-ups wanneer er een failover plaatsvindt en elimineert de noodzaak van handmatige interventie. Back-up biedt ook:

• Onmiddellijke beveiliging zonder herstel volledige back-ups, zodat u HANA-exemplaren of HSR-installatieknooppunten kunt beveiligen als één HSR-container.

• Het voordeel van directe back-up en direct herstellen.

• Een op HANA consistente, momentopname gebaseerde benadering die kan worden geïntegreerd met Backint voor SAP HANA. U kunt Backup gebruiken als één product voor uw hele HANA-landschap en voor elke databasegrootte.

Zie sap HANA-databasesysteem met replicatie ingeschakeld en back-up van momentopnamen van SAP HANA-exemplaren voor meer informatie.

Aanbevelingen voor back-up en herstel ontwerpen

• U kunt Azure Backup gebruiken om een back-up te maken van de SAP-toepassingsserver en centrale services-VM's.

• U kunt een SAP HANA-back-up gebruiken voor HANA-implementaties die maximaal 8 TB zijn. Zie ondersteuningsmatrix voor back-ups van SAP HANA-databases op Virtuele Azure-machines voor meer informatie.

• Als u een oplossing voor infrastructuur als een serviceback-up gebruikt, moet u de back-upinfrastructuur zo groot mogelijk maken dat er tegelijkertijd een back-up kan worden uitgevoerd van alle systemen in productiegrootte of, zoals in een praktijkscenario, binnen de verwachte tijdsbestekken. Gebruik een productie-installatie of een vergelijkbare installatie voor gebieden zoals netwerken en beveiliging.

• Test de back-up- en hersteltijden om te controleren of ze voldoen aan uw RTO-vereisten om alle systemen tegelijkertijd te herstellen na een noodgeval.

• Vermijd in het ideale gevallen het ophalen van uw back-ups uit Azure in uw on-premises back-upinfrastructuur, met name voor grote databases. Deze aanpak kan van invloed zijn op de bandbreedte die de ExpressRoute-circuits gebruiken.

• Laad de back-up- en herstelhulpprogramma's als onderdeel van het prestatietestplan.

Herstel na noodgeval

In de volgende secties worden ontwerpoverwegingen en aanbevelingen voor herstel na noodgevallen in een SAP-scenario beschreven.

Ontwerpoverwegingen voor herstel na noodgevallen

De Azure-regiokaart bevat meer dan 65 Azure-regio's en niet allemaal dezelfde services. Voor grotere SAP-software-implementaties, met name voor implementaties van SAP HANA, zoekt u naar Azure-regio's die VM's uit de Azure M-serie of vm's uit de Mv2-serie bieden. Azure Storage koppelt ook verschillende regio's om een kleinere subset van opslagtypen te repliceren naar een andere regio. Zie Overzicht van gekoppelde Azure-regio's voor meer informatie.

De belangrijkste uitdagingen voor het koppelen van Azure-regio's voor SAP-workloads zijn:

• De paren zijn niet altijd consistent met VM-services uit de M-serie of mv2-serie. Veel organisaties die hun SAP-systemen implementeren, maken geen gebruik van gekoppelde Azure-regio's. In plaats daarvan kiezen ze regio's op basis van de beschikbaarheid van vereiste VM-typen.

• U kunt standaardopslag tussen gekoppelde regio's repliceren, maar u kunt geen standaardopslag gebruiken om uw databases of virtuele harde schijven op te slaan. U kunt back-ups alleen repliceren tussen gekoppelde regio's die u gebruikt. Voor alle andere gegevens voert u uw replicatie uit met behulp van systeemeigen DBMS-functies, zoals SQL Server Always On of SAP HANA-systeemreplicatie. Gebruik een combinatie van Site Recovery, hulpprogramma's zoals rsync of robocopyandere niet-Microsoft-software voor de SAP-toepassingslaag.

• Als zich een noodgeval voordoet, worden meerdere betrokken klanten in een Azure-regio een failover uitgevoerd naar de bijbehorende gekoppelde regio voor herstel na noodgevallen. Deze situatie leidt tot concurrentie van resources om slapende VM's in de regio voor noodherstel weer te geven. De tijdelijke oplossing is het uitvoeren van niet-productiesystemen in de regio voor herstel na noodgevallen en het gebruik van dezelfde resources voor het hosten van replica's voor herstel na noodgevallen van productiesystemen. Dit gebruik van twee doelen van Azure-infrastructuren in de regio voor herstel na noodgevallen helpt u bij het voorkomen van beperkingen voor resourcecapaciteit.

Een andere belangrijke overweging is om de vereiste operationele capaciteit in de noodregio te beveiligen. Als zich een noodgeval voordoet, moet u de SAP-toepassing mogelijk gedurende een minimale periode uitvoeren met minimale IT-capaciteit en door kritieke human resources alleen terwijl u werkt om de normale werking in de primaire regio te herstellen. Deze strategie vereist dat u een minimale IT-infrastructuur hebt die beschikbaar is in de regio voor herstel na noodgevallen.

Nadat u uw Azure-regio's hebt gedefinieerd, moet u een implementatiepatroon kiezen:

• Implementeert u productiesystemen in uw primaire regio?

• Implementeert u niet-productie SAP-systemen in de regio voor herstel na noodgevallen?

• Gebruikt u een architectuur die alle SAP-systemen in de primaire regio groepeert? Deze configuratie zorgt ervoor dat de regio voor herstel na noodgevallen alleen wordt gebruikt voor herstel na noodgevallen.

De meeste organisaties gebruiken beide regio's voor besturingssystemen. Organisaties die volledige kopieën van productiesystemen uitvoeren als bedrijfsregressietestsystemen, zijn doorgaans van plan het bedrijfsregressietestsysteem van SAP te gebruiken als doel voor herstel na noodgevallen.

Wanneer u een regio voor herstel na noodgevallen kiest, moet u expressRoute-connectiviteit met die regio hebben. Als u meerdere ExpressRoute-circuits hebt die verbinding maken met Azure, moet ten minste één van deze circuits verbinding maken met de primaire Azure-regio. De anderen moeten verbinding maken met de regio voor herstel na noodgevallen. Dit type architectuur verbindt u met het Azure-netwerk in een ander geografisch of geopolitieke gebied en beschermt uw verbinding als een ramp een van de Azure-regio's beïnvloedt.

Sommige organisaties gebruiken een combinatie van architectuur voor hoge beschikbaarheid en herstel na noodgevallen, waarbij hoge beschikbaarheid wordt gegroepeerd met herstel na noodgevallen in dezelfde Azure-regio. Maar het groeperen van hoge beschikbaarheid met herstel na noodgevallen is niet ideaal. Azure-beschikbaarheidszones ondersteunen deze architectuur. De afstand tussen beschikbaarheidszones binnen één Azure-regio is niet zo groot als de afstand tussen twee Azure-regio's, zodat een natuurramp de toepassingsservices in gevaar kan brengen in de regio waar deze zich voordoet. U moet ook rekening houden met de latentie tussen SAP-toepassingsservers en databaseservers. Volgens SAP-opmerking 1100926 is een retourtijd van minder dan of gelijk aan 0,3 ms een goede waarde en is een tijd van minder dan of gelijk aan 0,7 ms een gemiddelde waarde. Voor zones met hoge latentie moet u dus operationele procedures hebben om ervoor te zorgen dat SAP-toepassingsservers en databaseservers altijd in dezelfde zone worden uitgevoerd. Organisaties kiezen deze architectuur om de volgende redenen:

• Naleving is voldoende met configuraties die ondersteuning bieden voor kleinere afstanden tussen productie-implementatie en een doel voor herstel na noodgevallen.

• Gegevenssoevereine is een factor.

• Geopolitieke factoren zijn betrokken.

• Het is een goedkope optie die zonegebonden fouten ondersteunt, soms gecombineerd met back-upoverdracht naar de secundaire regio voor natuurrampen die van invloed zijn op een grote straal.

Een andere factor die u moet overwegen wanneer u uw regio voor herstel na noodgevallen kiest, is de RPO en RTO voor failover naar de site voor herstel na noodgevallen. Hoe groter de afstand tussen de productieregio en regio's voor herstel na noodgevallen, hoe hoger de netwerklatentie. U repliceert asynchroon tussen Azure-regio's, maar netwerklatentie kan van invloed zijn op de doorvoer die u kunt repliceren en het RPO-doel. Als u uw RPO wilt minimaliseren, kunt u een gecombineerde architectuur voor hoge beschikbaarheid en herstel na noodgevallen gebruiken. Deze configuratie vormt echter een potentieel hoger risico op grootschalige natuurrampen.

Aanbevelingen voor herstel na noodgevallen ontwerpen

• Zorg ervoor dat de ciDR (classless inter-domain routing) voor het primaire virtuele netwerk niet conflicteren of overlapt met de CIDR van het virtuele netwerk van de herstelsite na noodgevallen.

• ExpressRoute-verbindingen van on-premises instellen naar de primaire en secundaire Azure-regio's voor herstel na noodgevallen.

• Overweeg om VPN-verbindingen van on-premises naar de primaire en secundaire Azure-regio's voor herstel na noodgevallen in te stellen. Gebruik deze methode als alternatief voor het gebruik van ExpressRoute.

• Gebruik Site Recovery om een toepassingsserver te repliceren naar een site voor herstel na noodgevallen. Site Recovery kan u ook helpen bij het repliceren van vm's van het centrale servicescluster naar de site voor herstel na noodgevallen. Wanneer u herstel na noodgevallen aanroept, moet u het Linux Pacemaker-cluster opnieuw configureren op de site voor herstel na noodgevallen. U moet bijvoorbeeld het virtuele IP-adres of de SBD vervangen of corosync.conf uitvoeren.

• Repliceer de inhoud van de sleutelkluis, zoals certificaten, geheimen of sleutels in verschillende regio's, zodat u gegevens in de regio voor herstel na noodgevallen kunt ontsleutelen.

• Gebruik replicatie tussen regio's in Azure NetApp Files om bestandsvolumes te synchroniseren tussen de primaire regio en de regio voor herstel na noodgevallen.

• Gebruik systeemeigen databasereplicatie in plaats van Site Recovery om gegevens te synchroniseren met de site voor herstel na noodgevallen.

• Peer de primaire en virtuele netwerken voor herstel na noodgevallen. Voor HANA-systeemreplicatie moet u bijvoorbeeld een virtueel SAP HANA DB-netwerk koppelen aan het virtuele SAP HANA DB-netwerk van de SITE voor herstel na noodgevallen.

• Als u Azure NetApp Files-opslag gebruikt voor uw SAP-implementaties, maakt u minimaal twee Azure NetApp Files-accounts in de Premium-laag, in twee regio's.

• Overweeg systemen te groeperen op basis van hun bedrijfsbelang en nabijheidsafhankelijkheid op basis van toepassingsprestaties. Als u het bedrijfseffect van een regionale storing wilt minimaliseren, implementeert u elke groep in een afzonderlijke regio in een gekoppelde regioconstructie. Als u bijvoorbeeld het effect van een regionale storing wilt minimaliseren, kunt u twee kritieke ERP Central Component-systemen implementeren die twee verschillende bedrijfseenheden bedienen, in HET VK - zuid en VK - west.

Volgende stap

Implementatieopties voor SAP in Azure