Share via

SAP-workload in scenario's met virtuele Azure-machines

  • Artikel

Het ontwerpen van SAP NetWeaver, Hybris Business one of S/4HANA-systeemarchitectuur in Azure biedt veel verschillende mogelijkheden voor verschillende architecturen en hulpprogramma's die u kunt gebruiken om een schaalbare, efficiënte en maximaal beschikbare implementatie te krijgen. Hoewel dit afhankelijk is van het gebruikte besturingssysteem of DBMS, gelden er beperkingen. Bovendien worden niet alle scenario's die on-premises worden ondersteund, op dezelfde manier ondersteund in Azure. Dit document leidt door de ondersteunde configuraties voor niet-hoge beschikbaarheid en configuraties en architecturen met hoge beschikbaarheid die uitsluitend gebruikmaken van Azure-VM's.

Notitie

De HANA Large Instance-service bevindt zich in de zonsondergangmodus en accepteert geen nieuwe klanten meer. Het leveren van eenheden voor bestaande HANA Large Instance-klanten is nog steeds mogelijk. Bekijk voor alternatieven de aanbiedingen van door HANA gecertificeerde Azure-VM's in de HANA-hardwaremap. Voor scenario's die wel en nog steeds worden ondersteund voor bestaande HANA Large Instance-klanten met HANA Large Instances, raadpleegt u het artikel Ondersteunde scenario's voor HANA Large Instances.

Algemene platformbeperkingen

Azure heeft verschillende platforms, naast systeemeigen Azure-VM's die worden aangeboden als first party-service. HANA Large Instances, die zich in de zonsondergangmodus bevindt, is een van deze platforms. Azure VMware Services is een van deze eigen services. Azure VMware Services in het algemeen wordt niet ondersteund door SAP voor het hosten van SAP-workload. Raadpleeg de sap-ondersteuningsnotitie #2138865 - SAP-toepassingen in VMware Cloud: ondersteunde producten en VM-configuraties voor meer informatie over VMware-ondersteuning op verschillende platforms.

Naast de on-premises Active Directory biedt Azure een beheerde Active Directory SaaS-service met Microsoft Entra Domain Services (traditioneel AD beheerd door Microsoft) en Microsoft Entra ID. SAP-onderdelen die worden gehost op het Windows-besturingssysteem zijn vaak afhankelijk van het gebruik van Windows Active Directory. In dit geval is de traditionele Active Directory die on-premises wordt gehost door u of Microsoft Entra Domain Services (nog steeds in testfase). Deze SAP-onderdelen kunnen echter niet werken met de systeemeigen Microsoft Entra-id. Reden is dat er nog steeds grotere hiaten in functionaliteit zijn tussen Active Directory in de on-premises vorm of het SaaS-formulier (Microsoft Entra Domain Services) en de systeemeigen Microsoft Entra-id. Deze afhankelijkheid is de reden waarom Microsoft Entra-accounts niet worden ondersteund voor toepassingen op basis van SAP NetWeaver en S/4 HANA in het Windows-besturingssysteem. Traditionele Active Directory-accounts moeten in dergelijke scenario's worden gebruikt.

AD-service Ondersteunde toepassingen op basis van SAP NetWeaver en S/4 HANA in het Windows-besturingssysteem
On-premises Windows Active Directory Ondersteund
Microsoft Entra Domain Services. Ondersteund
Microsoft Entra ID Niet ondersteund

Het bovenstaande heeft geen invloed op het gebruik van Microsoft Entra-accounts voor scenario's met eenmalige aanmelding (SSO) met SAP-toepassingen.

Configuratie met twee lagen

Een SAP 2-laag-configuratie wordt beschouwd als opgebouwd uit een gecombineerde laag van de SAP DBMS en toepassingslaag die op dezelfde server of VM-eenheid worden uitgevoerd. De tweede laag wordt beschouwd als de gebruikersinterfacelaag. Voor een configuratie met twee lagen delen de DBMS- en SAP-toepassingslaag de resources van de Azure-VM. Als gevolg hiervan moet u de verschillende onderdelen zodanig configureren dat deze onderdelen niet concurreren voor resources. U moet er ook voor zorgen dat u de resources van de virtuele machine niet overschrijft. Een dergelijke configuratie biedt geen hoge beschikbaarheid, buiten de Azure Service Level Agreements van de verschillende Betrokken Azure-onderdelen.

Een grafische weergave van een dergelijke configuratie kan er als volgt uitzien:

Eenvoudige configuratie met twee lagen

Dergelijke configuraties worden ondersteund met Windows, Red Hat, SUSE en Oracle Linux voor de DBMS-systemen van SQL Server, Oracle, Db2, maxDB en SAP ASE voor productie- en niet-productiecases. Voor SAP HANA als DBMS ondersteunt SAP een dergelijk scenario, zoals aangegeven in SAP-opmerking #1953429. Tot nu toe heeft geen van de Linux-distributies voldoende documentatie over hoge beschikbaarheid verstrekt om een Pacemaker-cluster in een dergelijke configuratie in te stellen en te gebruiken. Als gevolg hiervan wordt een dergelijk type configuraties alleen ondersteund in Azure voor niet-productiecases waarvoor geen failovercluster met hoge beschikbaarheid is vereist.

Voor alle combinaties van het besturingssysteem/DBMS die worden ondersteund in Azure, wordt dit type configuratie ondersteund. Het is echter verplicht dat u de configuratie van de DBMS en de SAP-onderdelen instelt op een manier waarop DBMS- en SAP-onderdelen niet concurreren voor geheugen- en CPU-resources en waarmee de fysieke beschikbare resources worden overschreden. Dit moet worden gedaan door het geheugen te beperken dat de DBMS mag toewijzen. U moet ook het uitgebreide SAP-geheugen voor toepassingsexemplaren beperken. U moet ook het CPU-verbruik van de VM in het algemeen bewaken om ervoor te zorgen dat de onderdelen de CPU-resources niet maximaliseren.

Notitie

Voor SAP-productiesystemen raden we extra configuraties voor hoge beschikbaarheid en uiteindelijk herstel na noodgevallen aan, zoals verderop in dit document wordt beschreven

Configuratie met drie lagen

In dergelijke configuraties scheidt u de SAP-toepassingslaag en de DBMS-laag in verschillende VM's. Meestal doet u dat voor grotere systemen en uit redenen om flexibeler te zijn op de resources van de SAP-toepassingslaag. In de eenvoudigste installatie is er geen hoge beschikbaarheid buiten de Azure Service Level Agreements van de verschillende Betrokken Azure-onderdelen.

De grafische weergave ziet er als volgt uit:

Diagram met een eenvoudige configuratie met drie lagen.

Dit type configuratie wordt ondersteund in Windows, Red Hat, SUSE en Oracle Linux voor de DBMS-systemen van SQL Server, Oracle, Db2, SAP HANA, maxDB en SAP ASE voor productie- en niet-productiecases. Ter vereenvoudiging hebben we geen onderscheid gemaakt tussen SAP Central Services en SAP-dialoogvensterexemplaren in de SAP-toepassingslaag. In deze eenvoudige configuratie met drie lagen is er geen beveiliging met hoge beschikbaarheid voor SAP Central Services.

Notitie

Voor SAP-productiesystemen raden we extra configuraties voor hoge beschikbaarheid en uiteindelijk herstel na noodgevallen aan, zoals verderop in dit document wordt beschreven

Meerdere DBMS-exemplaren per VM

In dit configuratietype host u meerdere DBMS-exemplaren per Azure-VM. De motivatie kan zijn om minder besturingssystemen te hebben om te onderhouden en met die lagere kosten. Andere redenen zijn om meer flexibiliteit en efficiëntie te hebben door resources van een grotere VM of HANA Large Instance-eenheid te delen tussen meerdere DBMS-exemplaren. Tot nu toe werden deze configuraties voornamelijk weergegeven voor niet-productiesystemen.

Een configuratie die er als volgt uit kan zien:

Meerdere DBMS-exemplaren in één eenheid

Dit type DBMS-implementatie wordt ondersteund voor:

Als u meerdere database-exemplaren uitvoert op één host, moet u ervoor zorgen dat de verschillende exemplaren niet concurreren voor resources en zo de fysieke resourcelimieten van de VIRTUELE machine overschrijden. Dit geldt met name voor geheugen waar u het geheugen moet beperken dat iedereen van de exemplaren die de VIRTUELE machine delen, kan toewijzen. Dit geldt mogelijk ook voor de CPU-resources die de verschillende database-exemplaren kunnen verbruiken. Alle vermelde databasesystemen hebben configuraties waarmee geheugentoewijzing en CPU-resources op exemplaarniveau kunnen worden beperkt. Als u ondersteuning wilt hebben voor een dergelijke configuratie voor Virtuele Azure-machines, wordt verwacht dat de schijven of volumes die worden gebruikt voor de gegevens en logboek-/logboekbestanden van de databases die door de verschillende exemplaren worden beheerd, gescheiden zijn. Of met andere woorden gegevens of logboek-/opnieuw logboekbestanden van databases die worden beheerd door een ander DBMS-exemplaar, mogen niet dezelfde schijven of volumes delen.

Notitie

Voor SAP-systemen voor productie raden we extra configuraties voor hoge beschikbaarheid en uiteindelijk herstel na noodgevallen aan, zoals verderop in dit document wordt beschreven. VM's met meerdere DBMS-exemplaren worden niet ondersteund met de configuraties voor hoge beschikbaarheid die verderop in dit document worden beschreven.

Meerdere SAP-dialoogvensterexemplaren in één VIRTUELE machine

In veel gevallen zijn meerdere dialoogvensterexemplaren geïmplementeerd op bare-metalservers of zelfs op VM's die worden uitgevoerd in privéclouds. Reden voor dergelijke configuraties was om bepaalde SAP-dialoogvensterexemplaren aan te passen aan bepaalde werkbelastingen, bedrijfsfunctionaliteit of workloadtypen. Reden voor het niet isoleren van deze exemplaren in afzonderlijke VM's was de inspanning van onderhoud en bewerkingen van het besturingssysteem. Of in talloze gevallen de kosten voor het geval de hoster of operator van de VIRTUELE machine vraagt om een maandelijks bedrag per vm dat wordt beheerd en beheerd. In Azure wordt een scenario van het hosten van meerdere SAP-dialoogvensterexemplaren binnen één VIRTUELE machine ondersteund voor productie- en niet-productiedoeleinden op de besturingssystemen van Windows, Red Hat, SUSE en Oracle Linux. De SAP-kernelparameter PHYS_MEMSIZE, beschikbaar op Windows- en moderne Linux-kernels, moet worden ingesteld als meerdere SAP Application Server-exemplaren worden uitgevoerd op één VIRTUELE machine. Het wordt ook aangeraden de uitbreiding van SAP Extended Memory op besturingssystemen te beperken, zoals Windows waar automatische groei van het uitgebreide SAP-geheugen wordt geïmplementeerd. Dit kan worden gedaan met de sap-profielparameter em/max_size_MB.

Bij een configuratie met drie lagen waarin meerdere SAP-dialoogvensterexemplaren worden uitgevoerd binnen Azure-VM's, kan dit er als volgt uitzien:

Diagram met een configuratie met drie lagen waarin meerdere SAP-dialoogvensterexemplaren worden uitgevoerd binnen azure-VM's.

Ter vereenvoudiging hebben we geen onderscheid gemaakt tussen SAP Central Services en SAP-dialoogvensterexemplaren in de SAP-toepassingslaag. In deze eenvoudige configuratie met drie lagen is er geen beveiliging met hoge beschikbaarheid voor SAP Central Services. Voor productiesystemen is het niet raadzaam om SAP Central Services onbeveiligd te laten. Zie latere secties van dit document voor specifieke informatie over zogenaamde multi-SID-configuraties rond SAP Central Instances en hoge beschikbaarheid van dergelijke multi-SID-configuraties.

Hoge beschikbaarheidsbeveiliging voor de SAP DBMS-laag

Naarmate u SAP-productiesystemen wilt implementeren, moet u rekening houden met het hot standby-type configuraties voor hoge beschikbaarheid. Met name met SAP HANA, waarbij gegevens in het geheugen moeten worden geladen voordat de volledige prestaties en schaalbaarheid kunnen worden hersteld, is azure-serviceherstel geen ideale meting voor hoge beschikbaarheid.

Over het algemeen ondersteunt Microsoft alleen configuraties met hoge beschikbaarheid en softwarepakketten die worden beschreven in de SAP-workloadscenario's. U kunt dezelfde instructie lezen in SAP-notitie #1928533. Microsoft biedt geen ondersteuning voor andere softwareframeworks van derden met hoge beschikbaarheid die niet worden gedocumenteerd door Microsoft met SAP-workload. In dergelijke gevallen is de externe leverancier van het framework voor hoge beschikbaarheid de ondersteunende partij voor de configuratie met hoge beschikbaarheid die door u als klant moet worden betrokken bij het ondersteuningsproces. Uitzonderingen worden vermeld in dit artikel.

Over het algemeen ondersteunt Microsoft een beperkte set configuraties voor hoge beschikbaarheid op Azure-VM's of HANA Large Instances-eenheden.

Voor Azure-VM's worden de volgende configuraties met hoge beschikbaarheid ondersteund op DBMS-niveau:

Belangrijk

Voor geen van de hierboven beschreven scenario's ondersteunen we configuraties van meerdere DBMS-exemplaren in één VM. In elk van de gevallen kan slechts één database-exemplaar per VM worden geïmplementeerd en beveiligd met de beschreven methoden voor hoge beschikbaarheid. Het beveiligen van meerdere DBMS-exemplaren onder hetzelfde Windows- of Pacemaker-failovercluster wordt op dit moment niet ondersteund. Oracle Data Guard wordt ook alleen ondersteund voor één exemplaar per VM-implementatie.

Verschillende databasesystemen staan het hosten van meerdere databases toe onder één DBMS-exemplaar. Net als bij SAP HANA kunnen meerdere databases worden gehost in meerdere databasecontainers (MDC). Voor gevallen waarin deze configuraties voor meerdere databases binnen één failoverclusterresource werken, worden deze configuraties ondersteund. Configuraties die niet worden ondersteund, zijn gevallen waarin meerdere clusterbronnen vereist zijn. Net als bij configuraties waarin u meerdere SQL Server-beschikbaarheidsgroepen zou definiëren, onder één SQL Server-exemplaar.

DBMS HA-configuratie

Afhankelijk van de DBMS een/of besturingssystemen zijn onderdelen zoals Azure Load Balancer mogelijk of niet vereist als onderdeel van de oplossingsarchitectuur.

Met name voor maxDB moet de opslagconfiguratie anders zijn. Met maxDB moeten de gegevens en logboekbestanden zich in gedeelde opslag bevinden voor configuraties met hoge beschikbaarheid. Alleen voor maxDB wordt gedeelde opslag ondersteund voor hoge beschikbaarheid. Voor alle andere DBMS zijn afzonderlijke opslagstacks per knooppunt de enige ondersteunde schijfconfiguraties.

Andere frameworks voor hoge beschikbaarheid zijn bekend en worden ook uitgevoerd in Microsoft Azure. Microsoft heeft deze frameworks echter niet getest. Als u uw configuratie voor hoge beschikbaarheid met deze frameworks wilt bouwen, moet u samenwerken met de provider van die software om:

  • Een implementatiearchitectuur ontwikkelen
  • Implementatie van de architectuur
  • Ondersteuning van de architectuur

Belangrijk

Microsoft Azure Marketplace biedt diverse zachte apparaten die opslagoplossingen bieden boven op systeemeigen Azure-opslag. Deze zachte apparaten kunnen worden gebruikt om NFS-shares te maken en die theoretisch kunnen worden gebruikt in de sap HANA-uitschaalimplementaties waar een stand-byknooppunt vereist is. Om verschillende redenen wordt geen van deze opslag soft appliances ondersteund voor een van de DBMS-implementaties door Microsoft en SAP in Azure. Implementaties van DBMS op SMB-shares worden op dit moment helemaal niet ondersteund. Implementaties van DBMS op NFS-shares zijn beperkt tot NFS 4.1-shares in Azure NetApp Files.

Hoge beschikbaarheid voor SAP Central-service

SAP Central Services is een tweede single point of failure van uw SAP-configuratie. Als gevolg hiervan moet u deze Central Services-processen ook beveiligen. De aanbieding die wordt ondersteund en gedocumenteerd voor SAP-werkbelasting, leest als:

Van de vermelde oplossingen hebt u een ondersteuningsrelatie met SIOS nodig om het Datakeeper product te ondersteunen en om rechtstreeks contact op te nemen met SIOS als er problemen optreden. Afhankelijk van de manier waarop u het Windows-, Red Hat- en/of SUSE-besturingssysteem hebt gelicentieerd, kunt u ook een ondersteuningscontract met uw besturingssysteemprovider hebben om volledige ondersteuning te bieden voor de vermelde configuraties voor hoge beschikbaarheid.

De configuratie kan ook worden weergegeven als:

DBMS- en ASCS HA-configuratie

Aan de rechterkant van de afbeeldingen worden de maximaal beschikbare SAP Central Services weergegeven. Naast het beveiligen van de SAP Central-services met een failoverclusterframework dat failover in foutscenario's kan uitvoeren. Er is een noodzaak voor een maximaal beschikbare NFS- of SMB-share, of een gedeelde Windows-schijf om ervoor te zorgen dat de sapmnt- en globale transportmap beschikbaar zijn, onafhankelijk van het bestaan van één virtuele machine. Voor sommige van de oplossingen, zoals Windows Failover Cluster Server en Pacemaker, is een Azure-load balancer vereist om verkeer om te leiden of om te leiden naar een gezond knooppunt.

In de lijst die wordt weergegeven, is er geen vermelding van het Oracle Linux-besturingssysteem. Oracle Linux biedt geen ondersteuning voor Pacemaker als clusterframework. Als u uw SAP-systeem wilt implementeren in Oracle Linux en u een framework voor hoge beschikbaarheid voor Oracle Linux nodig hebt, moet u samenwerken met externe leveranciers. Een van de leveranciers is SIOS met hun Protection Suite voor Linux die wordt ondersteund door SAP in Azure. Lees SAP-opmerking #1662610 - Ondersteuningsdetails voor SIOS Protection Suite voor Linux voor meer informatie.

Ondersteunde opslag met de hierboven vermelde SAP Central Services-scenario's

Omdat slechts een subset van Azure-opslagtypen maximaal beschikbare NFS- of SMB-shares biedt die kwaliteit voor het gebruik in onze SAP Central Services-clusterscenario's een lijst met ondersteunde opslagtypen

  • Windows Failover Cluster Server met Windows Scale-out Bestandsserver kan worden geïmplementeerd op alle systeemeigen Azure-opslagtypen, met uitzondering van Azure NetApp Files. Aanbeveling is echter om Premium Storage te gebruiken vanwege superieure serviceovereenkomsten in doorvoer en IOPS.
  • Windows Failover Cluster Server met SMB in Azure NetApp Files wordt ondersteund in Azure NetApp Files. SMB-shares die worden gehost in Azure Premium File-services worden ook ondersteund voor dit scenario. Azure Standard Files wordt niet ondersteund
  • Windows Failover Cluster Server met windows gedeelde schijf op basis van SIOS Datakeeper kan worden geïmplementeerd op alle systeemeigen Azure-opslagtypen, met uitzondering van Azure NetApp Files. Aanbeveling is echter om Premium Storage te gebruiken vanwege superieure serviceovereenkomsten in doorvoer en IOPS.
  • SUSE of Red Hat Pacemaker met behulp van NFS-shares in Azure NetApp Files wordt ondersteund.
  • SUSE of Red Hat Pacemaker met behulp van NFS-shares in Azure Premium Files met behulp van LRS of ZRS s die worden ondersteund. Azure Standard Files wordt niet ondersteund
  • SUSE Pacemaker met behulp van een drdb configuratie tussen twee VM's wordt ondersteund met systeemeigen Azure-opslagtypen, met uitzondering van Azure NetApp Files. We raden u echter aan een van de services van de eerste partijen te gebruiken met Azure Premium Files of Azure NetApp Files.
  • Red Hat Pacemaker die gebruikt glusterfs voor het leveren van NFS-share wordt ondersteund met systeemeigen Azure-opslagtypen, met uitzondering van Azure NetApp Files. We raden u echter aan een van de services van de eerste partijen te gebruiken met Azure Premium Files of Azure NetApp Files.

Belangrijk

Microsoft Azure Marketplace biedt diverse zachte apparaten die opslagoplossingen bieden boven op systeemeigen Azure-opslag. Deze voorlopig opslagapparaten kunnen ook worden gebruikt om NFS- of SMB-shares te maken die theoretisch kunnen worden gebruikt in de failoverclusters van SAP Central Services. Deze oplossingen worden niet rechtstreeks ondersteund voor SAP-werkbelasting door Microsoft. Als u besluit om een dergelijke oplossing te gebruiken om uw NFS- of SMB-share te maken, moet de ondersteuning voor de SAP Central-serviceconfiguratie worden geleverd door de derde partij die eigenaar is van de software in het soft-apparaat voor opslag.

Multi-SID SAP Central Services-failoverclusters

Om het aantal VM's dat nodig is in grote SAP-landschappen te verminderen, maakt SAP het mogelijk om SAP Central Services-exemplaren van meerdere verschillende SAP-systemen uit te voeren in de failoverclusterconfiguratie. Stel dat u 30 of meer NetWeaver- of S/4HANA-productiesystemen hebt. Zonder clustering met meerdere SID's zijn voor deze configuraties 60 of meer VM's in 30 of meer Configuraties van Windows- of Pacemaker-failoverclusters vereist. Het implementeren van meerdere CENTRALE SAP-services op twee knooppunten in een failoverclusterconfiguratie kan het aantal VM's aanzienlijk verminderen. Het implementeren van meerdere SAP Central-servicesinstanties op één clusterconfiguratie met twee knooppunten heeft echter ook enkele nadelen. Problemen rond één VM in de clusterconfiguratie zijn van toepassing op meerdere SAP-systemen. Onderhoud van het gastbesturingssystem dat wordt uitgevoerd in de clusterconfiguratie vereist meer coördinatie omdat er meerdere SAP-productiesystemen worden beïnvloed. Hulpprogramma's zoals SAP LaMa ondersteunen geen clustering met meerdere SID's in hun systeemklonen.

In Azure wordt een clusterconfiguratie met meerdere SID's ondersteund voor het Windows-besturingssysteem met ENSA1 en ENSA2. Aanbeveling is niet om de oudere Enqueue Replication Service-architectuur (ENSA1) te combineren met de nieuwe architectuur (ENSA2) op één cluster met meerdere SID's. Details over een dergelijke architectuur worden beschreven in de artikelen

Voor SUSE wordt ook een cluster met meerdere SID's op basis van Pacemaker ondersteund. Tot nu toe wordt de configuratie ondersteund voor:

  • Maximaal vijf SAP ASCS/SCS-exemplaren
  • De oude replicatieserver ice architecture (ENSA1) in de wachtrij
  • Clusterconfiguraties van twee knooppunten in Pacemaker

De configuratie wordt gedocumenteerd in hoge beschikbaarheid voor SAP NetWeaver op Azure-VM's op SUSE Linux Enterprise Server voor SAP-toepassingen met meerdere SID-toepassingen

Een cluster met meerdere SID's met replicatieserver in de wachtrij ziet er als volgt uit

Diagram met een cluster met meerdere SID's met Dequeue Replication-server.

Uitschaalscenario's voor SAP HANA

Uitschaalscenario's voor SAP HANA worden ondersteund voor een subset van de door HANA gecertificeerde Azure-VM's, zoals vermeld in de SAP HANA-hardwaremap. Alle VM's die zijn gemarkeerd met Ja in de kolom Clustering, kunnen worden gebruikt voor OLAP- of S/4HANA-uitschalen. Configuraties zonder stand-by worden ondersteund met de Azure Storage-typen:

Uitschaalconfiguraties voor SAP HANA voor OLAP of S/4HANA met stand-byknooppunten worden exclusief ondersteund met NFS-gedeelde NFS die worden gehost in Azure NetApp Files.

Raadpleeg de artikelen voor meer informatie over exacte opslagconfiguraties met of zonder stand-byknooppunt:

Scenario voor herstel na noodgevallen

Er zijn verschillende scenario's voor herstel na noodgevallen die worden ondersteund. We definiëren architecturen voor noodgevallen als architecturen, die moeten compenseren voor een volledige Azure-regio die buiten het raster gaat. Dit betekent dat we het noodhersteldoel nodig hebben om een andere Azure-regio te zijn als doel om uw SAP-landschap uit te voeren. We scheiden methoden en configuraties in de DBMS-laag en niet-DBMS-laag.

DBMS-laag

Voor de DBMS-laag worden configuraties die gebruikmaken van de systeemeigen DBMS-replicatiemechanismen, zoals AlwaysOn, Oracle Data Guard, Db2 HADR, SAP ASE Always-On of HANA-systeemreplicatie ondersteund. het is verplicht dat de replicatiestroom in dergelijke gevallen asynchroon is, in plaats van synchroon te zijn als in typische scenario's met hoge beschikbaarheid die in één Azure-regio worden geïmplementeerd. Een typisch voorbeeld van een dergelijke ondersteunde DBMS-configuratie voor herstel na noodgevallen wordt beschreven in het artikel SAP HANA-beschikbaarheid in Azure-regio's. In de tweede afbeelding in die sectie wordt een scenario beschreven met HANA als voorbeeld. De belangrijkste databases die worden ondersteund voor SAP-toepassingen kunnen allemaal in een dergelijk scenario worden geïmplementeerd.

Het wordt ondersteund om een kleinere VIRTUELE machine te gebruiken als doelexemplaren in de regio voor herstel na noodgevallen, omdat deze VM geen volledig workloadverkeer ondervindt. Als u dit doet, moet u rekening houden met de volgende overwegingen:

  • Kleinere VM-typen staan niet toe dat veel schijven zijn gekoppeld dan kleinere VM's
  • Kleinere VM's hebben minder netwerk- en opslagdoorvoer
  • Het wijzigen van de grootte tussen VM-families kan een probleem zijn wanneer de verschillende VM's worden verzameld in één Azure-beschikbaarheidsset of wanneer de grootte moet worden gewijzigd tussen de M-serie en de Mv2-serie van VM's
  • CPU- en geheugenverbruik voor het database-exemplaar dat de stroom van wijzigingen kan ontvangen met minimale vertraging en voldoende CPU- en geheugenbronnen om deze wijzigingen met minimale vertraging toe te passen op de gegevens

Meer informatie over beperkingen van verschillende VM-grootten vindt u op de pagina VM-grootten

Een andere ondersteunde methode voor het implementeren van een DR-doel is het installeren van een tweede DBMS-exemplaar op een VIRTUELE machine waarop een niet-productie DBMS-exemplaar van een SAP-exemplaar zonder productie wordt uitgevoerd. Dit kan een beetje lastiger zijn, omdat u moet achterhalen wat er moet gebeuren met geheugen, CPU-resources, netwerkbandbreedte en opslagbandbreedte voor de specifieke doelexemplaren die als hoofdexemplaren in het dr-scenario moeten functioneren. Met name in HANA is het raadzaam om het exemplaar te configureren dat als DR-doel fungeert op een gedeelde host, zodat de gegevens niet vooraf in het dr-doelexemplaren worden geladen.

Notitie

Het gebruik van Azure Site Recovery is niet getest op DBMS-implementaties onder SAP-werkbelasting. Hierdoor wordt het op dit moment niet ondersteund voor de DBMS-laag van SAP-systemen. Andere replicatiemethoden van Microsoft en SAP die niet worden vermeld, worden niet ondersteund. Het gebruik van software van derden voor het repliceren van de DBMS-laag van SAP-systemen tussen verschillende Azure-regio's, moet worden ondersteund door de leverancier van de software en wordt niet ondersteund via Microsoft- en SAP-ondersteuningskanalen.

Niet-DBMS-laag

Voor de SAP-toepassingslaag en uiteindelijke shares of opslaglocaties die nodig zijn, worden de twee belangrijke scenario's gebruikt door klanten:

  • De doelen voor herstel na noodgevallen in de tweede Azure-regio worden niet gebruikt voor productie- of niet-productiedoeleinden. In dit scenario worden de VM's die fungeren als doel voor herstel na noodgevallen idealiter niet geïmplementeerd en worden de installatiekopie en wijzigingen in de installatiekopieën van de productie-SAP-toepassingslaag gerepliceerd naar de regio voor herstel na noodgevallen. Een functionaliteit die een dergelijke taak kan uitvoeren, is Azure Site Recovery. Azure Site Recovery biedt ondersteuning voor een replicatiescenario van Azure naar Azure, zoals dit.
  • De doelen voor herstel na noodgevallen zijn VM's die daadwerkelijk worden gebruikt door niet-productiesystemen. Het hele SAP-landschap is verspreid over twee verschillende Azure-regio's met productiesystemen meestal in één regio en niet-productiesystemen in een andere regio. In veel klantimplementaties heeft de klant een niet-productiesysteem dat gelijk is aan een productiesysteem. De klant heeft productietoepassingsexemplaren vooraf geïnstalleerd op de toepassingslaag niet-productiesystemen. In een failovergebeurtenis worden de niet-productie-exemplaren afgesloten, de virtuele namen van de productie-VM's verplaatst naar de niet-productie-VM's (na het toewijzen van nieuwe IP-adressen in DNS) en de vooraf geïnstalleerde productie-exemplaren worden gestart

SAP Central Services-clusters

SAP Central Services-clusters die gebruikmaken van gedeelde schijven (Windows), SMB-shares (Windows) of NFS-shares zijn iets moeilijker te repliceren. Aan de Windows-zijde is Windows Storage Replication een mogelijke oplossing. In Linux is rsync een levensvatbare oplossing. Replicatie tussen regio's van Azure NetApp Files is ook een haalbare oplossing.

Niet-ondersteund scenario

Er is een lijst met scenario's die niet worden ondersteund voor SAP-workload in Azure-architecturen. Niet ondersteund betekent dat SAP en Microsoft geen ondersteuning kunnen bieden voor deze configuraties en dat ze moeten worden uitgesteld naar een uiteindelijk betrokken derde partij die software heeft geleverd om dergelijke architecturen tot stand te brengen. Twee van de categorieën zijn:

  • Opslag soft appliances: Er zijn diverse opslag soft appliances in de markt. Sommige leveranciers bieden eigen documentatie over het gebruik van hun opslag soft appliances in Azure met betrekking tot SAP-software. Ondersteuning van configuraties of implementaties met betrekking tot dergelijke opslag soft appliances moet worden verstrekt door de leverancier van het opslag soft appliance. Dit feit wordt ook weergegeven in sap-ondersteuningsnotitie #2015553
  • Frameworks voor hoge beschikbaarheid: alleen Pacemaker en Windows Server-failovercluster worden frameworks voor hoge beschikbaarheid ondersteund voor SAP-workload in Azure. Zoals eerder vermeld, wordt de oplossing van SIOS Datakeeper beschreven en gedocumenteerd door Microsoft. Niettemin moeten de onderdelen van SIOS worden ondersteund via SIOS Datakeeper als de leverancier die deze onderdelen levert. SAP vermeldt ook andere gecertificeerde frameworks voor hoge beschikbaarheid in verschillende SAP-notities. Sommige zijn ook gecertificeerd door de externe leverancier voor Azure. Niettemin moet de productleverancier ondersteuning bieden voor configuraties die deze producten gebruiken. Verschillende leveranciers hebben verschillende integratie in de SAP-ondersteuningsprocessen. U moet verduidelijken welk ondersteuningsproces het beste werkt voor de specifieke leverancier voordat u besluit het product te gebruiken met SAP-configuraties die zijn geïmplementeerd in Azure.
  • Gedeelde schijfclusters waarin databasebestanden zich op de gedeelde schijven bevinden, worden niet ondersteund, met uitzondering van maxDB. Voor alle andere databases is de ondersteunde oplossing het hebben van afzonderlijke opslaglocaties in plaats van een SMB- of NFS-share of gedeelde schijf om scenario's met hoge beschikbaarheid te configureren

Andere scenario's, die niet worden ondersteund, zijn scenario's zoals:

  • Implementatiescenario's die een grotere netwerklatentie introduceren tussen de SAP-toepassingslaag en de SAP DBMS-laag, zoals in NetWeaver, S/4HANA en bijvoorbeeld Hybris. Dit omvat:
    • Een van de lagen on-premises implementeren, terwijl de andere laag wordt geïmplementeerd in Azure
    • De SAP-toepassingslaag van een systeem implementeren in een andere Azure-regio dan de DBMS-laag
    • Eén laag implementeren in datacenters die zich gezamenlijk in Azure bevinden en de andere laag in Azure, behalve wanneer een dergelijk architectuurpatroon wordt geleverd door een systeemeigen Azure-service
    • Virtuele netwerkapparaten implementeren tussen de SAP-toepassingslaag en de DBMS-laag
    • Opslag gebruiken die wordt gehost in datacenters die zich gezamenlijk in het Azure-datacenter bevinden voor de SAP DBMS-laag of de algemene transportmap van SAP
    • De twee lagen implementeren met twee verschillende cloudleveranciers. Bijvoorbeeld het implementeren van de DBMS-laag in Oracle Cloud Infrastructure en de toepassingslaag in Azure
  • Clusterconfiguraties met meerdere exemplaren van HANA Pacemaker
  • Windows-clusterconfiguraties met gedeelde schijven via SOFS of SMB op ANF voor SAP-databases die worden ondersteund in Windows. In plaats daarvan raden we het gebruik aan van systeemeigen replicatie van hoge beschikbaarheid van de specifieke databases en afzonderlijke opslagstacks te gebruiken
  • Implementatie van SAP-databases die worden ondersteund op Linux met databasebestanden die zich in NFS-shares op ANF bevinden, met uitzondering van SAP HANA, Oracle op Oracle Linux en Db2 op Suse en Red Hat
  • Implementatie van Oracle DBMS op een ander gast besturingssysteem dan Windows en Oracle Linux. Zie ook sap-ondersteuningsnotitie #2039619

Scenario('s) die we niet hebben getest en dus geen ervaring hebben met de lijst, zoals:

  • Azure Site Recovery repliceert DBMS-laag-VM's. Als gevolg hiervan raden we u aan om de systeemeigen asynchrone replicatiefunctionaliteit van de database te gebruiken voor mogelijke configuratie voor herstel na noodgevallen

Volgende stappen

Lees de volgende stappen in de planning en implementatie van Azure Virtual Machines voor SAP NetWeaver