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

  • Artikel
  • 24 minuten om te lezen

Het ontwerpen van sap NetWeaver-, bedrijfs- of S/4HANA-systeemarchitectuur in Azure biedt veel verschillende mogelijkheden voor verschillende architecturen en hulpprogramma's om een schaalbare, efficiënte en zeer beschikbare implementatie te Hybris krijgen. Hoewel dit afhankelijk is van het gebruikte besturingssysteem of DBMS, zijn er beperkingen. Bovendien worden niet alle scenario's die on-premises worden ondersteund op dezelfde manier ondersteund in Azure. Dit document leidt uitsluitend door de ondersteunde configuraties voor niet-hoge beschikbaarheid en configuraties voor hoge beschikbaarheid en architecturen die uitsluitend gebruikmaken van Azure-VM's. Raadpleeg het artikel Ondersteunde scenario's voor HANA Large Instancesvoor scenario's die worden ondersteund met HANA Large Instances.

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. In het geval van 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 om resources. U moet er ook voor zorgen dat u de resources van de VM niet te veel toeschrijft. Een dergelijke configuratie biedt geen hoge beschikbaarheid, behalve de Azure-serviceovereenkomsten van de verschillende Betrokken Azure-onderdelen.

Een grafische weergave van een dergelijke configuratie kan er als volgende 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-productiegevallen. Voor SAP HANA dbms wordt dergelijke configuraties alleen ondersteund voor niet-productiegevallen. Dit omvat ook de implementatiecase van Grote exemplaren van Azure HANA. Voor alle OS/DBMS-combinaties die worden ondersteund in Azure, wordt dit type configuratie ondersteund. Het is echter verplicht om de configuratie van de DBMS en de SAP-onderdelen zo in te stellen dat DBMS- en SAP-onderdelen niet concurreren om geheugen- en CPU-resources en daarmee de fysieke beschikbare resources overschrijden. Dit moet worden gedaan door het geheugen te beperken dat de DBMS mag toewijzen. U moet ook het uitgebreide SAP-geheugen voor toepassings instances 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 aanvullende configuraties voor hoge beschikbaarheid en mogelijk herstel na noodherstel 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. Dit doet u meestal voor grotere systemen en uit redenen om flexibeler te zijn in de resources van de SAP-toepassingslaag. In de meest eenvoudige configuratie is er geen hoge beschikbaarheid buiten de Azure-serviceovereenkomsten van de verschillende Betrokken Azure-onderdelen.

De grafische weergave ziet er als volgende uit:

Diagram met een eenvoudige configuratie met drie lagen.

Dit type configuratie wordt ondersteund op 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-productiegevallen. Dit is de standaardimplementatieconfiguratie voor Azure HANA Large Instances. Ter vereenvoudiging hebben we geen onderscheid gemaakt tussen SAP Central Services en SAP-dialoogvensters 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 aanvullende configuraties voor hoge beschikbaarheid en mogelijk herstel na noodherstel aan, zoals verderop in dit document wordt beschreven

Meerdere DBMS-exemplaren per VM of HANA Large Instance-eenheid

In dit configuratietype host u meerdere DBMS-exemplaren per Azure-VM of HANA Large Instance-eenheid. De motivatie kan zijn om minder besturingssystemen te onderhouden en met die lagere kosten. Andere motivaties kunnen 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 vooral weergegeven voor niet-productiesystemen.

Een configuratie zoals deze kan er als volgende uitzien:

Meerdere DBMS-exemplaren in één eenheid

Dit type DBMS-implementatie wordt ondersteund voor:

Als u meerdere database-exemplaren op één host wilt uitvoeren, moet u ervoor zorgen dat de verschillende exemplaren niet concurreren om resources en daarmee de fysieke resourcelimieten van de VM overschrijden. Dit geldt met name voor geheugen waarbij u het geheugen moetlimieten die iedereen van de exemplaren die de VM delen, kan toewijzen. Dat kan ook waar zijn voor de CPU-resources die de verschillende database-exemplaren kunnen gebruiken. Alle vermelde DBMS's hebben configuraties waarmee geheugentoewijzing en CPU-resources op exemplaarniveau kunnen worden beperkt. Als u ondersteuning wilt bieden voor een dergelijke configuratie voor azure-VM's, wordt verwacht dat de schijven of volumes die worden gebruikt voor de gegevens en logboek-/redo-logboekbestanden van de databases die worden beheerd door de verschillende exemplaren, gescheiden zijn. Met andere woorden, gegevens of logboek-/redo-logboekbestanden van databases die worden beheerd door een ander DBMS-exemplaar, mogen niet dezelfde schijven of volumes delen.

De schijfconfiguratie voor grote HANA-exemplaren wordt geconfigureerd geleverd en wordt beschreven in Ondersteunde scenario's voor grote HANA-exemplaren.

Notitie

Voor SAP-productiesystemen raden we aanvullende configuraties voor hoge beschikbaarheid en mogelijk herstel na noodherstel 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-dialoogvensters in één VM

In veel gevallen zijn meerdere dialoogvensters geïmplementeerd op bare-metalservers of zelfs op VM's die worden uitgevoerd in privé clouds. De reden voor dergelijke configuraties was om bepaalde SAP-dialoogvensters aan te passen aan bepaalde workloads, bedrijfsfunctionaliteit of workloadtypen. Reden voor het niet isoleren van deze exemplaren in afzonderlijke VM's was de inspanning van besturingssysteemonderhoud en -bewerkingen. Of in talloze gevallen worden de kosten in rekening gebracht voor het geval de hoster of operator van de VM vraagt om een maandelijks bedrag per beheerde en beheerde VM. In Azure wordt een scenario voor het hosten van meerdere SAP-dialoogvensters binnen één VM ondersteund voor productie- en niet-productiedoeleinden op de besturingssystemen Windows, Red Hat, SUSE en Oracle Linux. De SAP-kernelparameter PHYS_MEMSIZE, beschikbaar op Windows en moderne Linux-kernels, moet worden ingesteld als er meerdere SAP Application Server-exemplaren worden uitgevoerd op één VM. Het is ook raadzaam om de uitbreiding van SAP Extended Memory op besturingssystemen te beperken, zoals Windows waar automatische groei van het sap uitgebreide geheugen wordt geïmplementeerd. U kunt dit doen met de SAP-profielparameter em/max_size_MB .

Bij een configuratie met drie lagen waarin meerdere SAP-dialoogvensters worden uitgevoerd binnen azure-VM's, kan dit er als volgende uitzien:

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

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

Beveiliging met hoge beschikbaarheid voor de SAP DBMS-laag

Bij het implementeren van SAP-productiesystemen moet u rekening houden met hot stand-byconfiguraties voor hoge beschikbaarheid. Met name met SAP HANA, waarbij gegevens in het geheugen moeten worden geladen voordat de volledige prestaties en schaalbaarheid kunnen worden teruggeschaald, is azure-serviceherstel geen ideale meting voor hoge beschikbaarheid.

In het algemeen ondersteunt Microsoft alleen configuraties voor hoge beschikbaarheid en softwarepakketten die worden beschreven in de sectie SAP-workload in docs.microsoft.com. U kunt dezelfde instructie lezen in SAP-notitie #1928533. Microsoft biedt geen ondersteuning voor andere softwarekaders van derden met hoge beschikbaarheid die niet zijn 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 van hoge beschikbaarheid die door u als klant moet worden betrokken bij het ondersteuningsproces. In dit artikel worden uitzonderingen genoemd.

In het algemeen ondersteunt Microsoft een beperkte set configuraties voor hoge beschikbaarheid op Virtuele Azure-apparaten of HANA Large Instances-eenheden. Lees het document Ondersteunde scenario's voor HANA Large Instances voor de ondersteunde scenario's van grote HANA-exemplaren.

Voor azure-VM's worden de volgende configuraties voor 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. Betekent dat in elk van de gevallen slechts één database-exemplaar kan worden geïmplementeerd per VM en kan worden 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.

Met verschillende databasesystemen kunnen meerdere databases onder één DBMS-exemplaar worden hosten. Net als bij SAP HANA kunnen meerdere databases worden gehost in meerdere databasecontainers (MDC). In gevallen waarin deze configuraties met 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 waarbij u meerdere SQL Server-beschikbaarheidsgroepen definieert, onder één SQL Server exemplaar.

DBMS HA-configuratie

Afhankelijk van de DBMS een/of besturingssystemen, zijn onderdelen zoals Azure load balancer al dan niet vereist als onderdeel van de oplossingsarchitectuur.

Specifiek voor maxDB moet de opslagconfiguratie anders zijn. In maxDB moeten de gegevens- en logboekbestanden zich in gedeelde opslag bevinden voor configuraties met hoge beschikbaarheid. Alleen in het geval van 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 op Microsoft Azure uitgevoerd. Microsoft heeft deze frameworks echter niet getest. Als u uw configuratie voor hoge beschikbaarheid wilt bouwen met deze frameworks, moet u samenwerken met de provider van die software om het volgende te doen:

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

Belangrijk

Microsoft Azure Marketplace biedt tal van zachte apparaten die opslagoplossingen bieden boven op de eigen Azure-opslag. Deze zachte apparaten kunnen ook worden gebruikt om NFS-shares te maken die theoretisch kunnen worden gebruikt in de SAP HANA-implementaties waarbij een stand-by-knooppunt is vereist. Om verschillende redenen wordt geen van deze zachte opslagapparaten ondersteund voor een van de DBMS-implementaties door Microsoft en SAP on Azure. Implementaties van DBMS op SMB-shares worden op dit moment nog niet ondersteund. Implementaties van DBMS op NFS-shares zijn beperkt tot NFS 4.1-shares op 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 processen van Central Services ook beveiligen. De aanbieding die wordt ondersteund en gedocumenteerd voor SAP-workloads, leest als:

Van de vermelde oplossingen hebt u een ondersteuningsrelatie met SIOS nodig om het product te ondersteunen en om rechtstreeks in contact te komen met Datakeeper SIOS in het geval van problemen. Afhankelijk van de manier waarop u een licentie voor het Windows-, Red Hat- en/of SUSE-besturingssysteem hebt gegeven, moet u mogelijk ook een ondersteuningscontract met uw provider van het besturingssysteem hebben om volledige ondersteuning te hebben 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 uiterst beschikbare SAP Central-services weergegeven. Naast het feit dat de SAP Central-services worden beveiligd met een failovercluster-framework dat een failover kan gebruiken in het geval van een probleem, is er een hoge beschikbare NFS- of SMB-share of een gedeelde Windows-schijf nodig om ervoor te zorgen dat de sapmnt- en globale transportmap beschikbaar zijn, onafhankelijk van het bestaan van één VM. Voor sommige van de oplossingen, zoals Windows Failoverclusterserver en Pacemaker, is een Azure-load balancer vereist om verkeer om te leiden of om te leiden naar een goed knooppunt.

In de lijst die wordt weergegeven, wordt het besturingssysteem Oracle Linux vermeld. Oracle Linux biedt geen ondersteuning voor Pacemaker als cluster-framework. Als u uw SAP-systeem wilt implementeren op 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 dat wordt ondersteund door SAP on Azure. Lees SAP Note #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 NFS- of SMB-shares met hoge beschikbare gegevens biedt voor het gebruik in onze SAP Central Services-clusterscenario's, is er een lijst met ondersteunde opslagtypen

  • Windows Failoverclusterserver met Windows scale-out bestandsserver kan worden geïmplementeerd op alle native Azure-opslagtypen, behalve Azure NetApp Files. Het wordt echter aanbevolen om Premium Storage te gebruiken vanwege hogere serviceovereenkomsten in doorvoer en IOPS.
  • Windows Failoverclusterserver met SMB op Azure NetApp Files wordt ondersteund op Azure NetApp Files. SMB-shares op Azure File-services worden op dit moment NIET ondersteund.
  • Windows Failoverclusterserver met gedeelde Windows-schijf op basis van SIOS kan worden geïmplementeerd op alle native Datakeeper Azure-opslagtypen, met uitzondering van Azure NetApp Files. Het wordt echter aanbevolen om Premium Storage te gebruiken vanwege hogere serviceovereenkomsten in doorvoer en IOPS.
  • SUSE of Red Hat Pacemaker met NFS-shares op Azure NetApp Files wordt ondersteund op Azure NetApp Files.
  • SUSE Pacemaker met behulp van drdb een configuratie tussen twee VM's wordt ondersteund met systeemeigen Azure-opslagtypen, behalve Azure NetApp Files. Het wordt echter aanbevolen om Premium Storage te gebruiken vanwege hogere serviceovereenkomsten in doorvoer en IOPS.
  • Red Hat Pacemaker met voor glusterfs het leveren van NFS-share wordt ondersteund met behulp van native Azure-opslagtypen, behalve Azure NetApp Files. Het wordt echter aanbevolen om Premium Storage te gebruiken vanwege hogere serviceovereenkomsten in doorvoer en IOPS.

Belangrijk

Microsoft Azure Marketplace biedt tal van zachte apparaten die opslagoplossingen bieden boven op de eigen Azure-opslag. Deze zachte apparaten kunnen ook worden gebruikt voor het maken van NFS- of SMB-shares die theoretisch ook kunnen worden gebruikt in de geclusterde SAP Central-services met failover. Deze oplossingen worden niet rechtstreeks ondersteund voor SAP-workloads door Microsoft. Als u besluit een dergelijke oplossing te gebruiken om uw NFS- of SMB-share te maken, moet ondersteuning voor de SAP Central-serviceconfiguratie worden geboden door de derde partij die eigenaar is van de software in het zachte opslagapparaat.

Failoverclusters voor SAP Central Services met meerdere SID's

Om het aantal VM's te verminderen dat nodig is in grote SAP-landschappen, staat SAP het uitvoeren van SAP Central Services-exemplaren van meerdere verschillende SAP-systemen in failoverclusterconfiguratie toe. Imagine gevallen waarin u 30 of meer NetWeaver- of S/4HANA-productiesystemen hebt. Zonder clustering met meerdere SID's zouden voor deze configuraties 60 of meer VM's in 30 of meer Windows- of Pacemaker-failoverclusterconfiguraties nodig zijn. Naast de DBMS-failoverclusters die nodig zijn. Het implementeren van meerdere SAP Central-services op twee knooppunten in een failoverclusterconfiguratie kan het aantal VM's aanzienlijk verminderen. Het implementeren van meerdere exemplaren van SAP Central-services op één clusterconfiguratie met twee knooppunt heeft echter ook nadelen. Problemen met betrekking tot één VM in de clusterconfiguratie zijn van toepassing op meerdere SAP-systemen. Voor onderhoud aan het gast-besturingssysteem dat in de clusterconfiguratie wordt uitgevoerd, is meer coördinatie vereist omdat meerdere SAP-productiesystemen worden beïnvloed. Hulpprogramma's zoals SAP LaMa ondersteunen geen clustering met meerdere SID's in het kloonproces van het systeem.

In Azure wordt een clusterconfiguratie met meerdere SID's ondersteund voor het Windows besturingssysteem met ENSA1 en ENSA2. Het wordt niet aanbevolen 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 ice-architectuur van de replicatieserver (ENSA1)
  • Pacemaker-clusterconfiguraties voor twee knooppunt

De configuratie wordt beschreven in de handleiding Hoge beschikbaarheid voor SAP NetWeaver op Virtuele Azure-SUSE Linux Enterprise Server voor SAP-toepassingen met meerdere SID's

Een cluster met meerdere SID's met enqueue replication-server ziet er schematisch uit als

Diagram met een cluster met meerdere SID's met enqueue replication-server.

SAP HANA scenario's voor uitschalen

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

SAP HANA scale-out configuraties voor OLAP of S/4HANA met stand-by-knooppunt(en) worden uitsluitend ondersteund met NFS gedeeld op Azure NetApp Files.

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

Voor meer informatie over HANA Large Instances ondersteunde HANA-uitschaalconfiguraties, is de volgende documentatie van toepassing:

Scenario voor herstel na noodherstel

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

DBMS-laag

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

Het gebruik van een kleinere VM als doel-exemplaar in de regio voor herstel na noodherstel wordt ondersteund, omdat die VM niet het volledige workloadverkeer ervaart. Als u dit doet, moet u rekening houden met de volgende overwegingen:

  • Kleinere VM-typen staan niet toe dat er veel schijven zijn gekoppeld dan kleinere VM's
  • Kleinere VM's hebben minder netwerk- en opslagdoorvoer
  • Het opnieuw instellen van de grootten voor verschillende VM-families kan een probleem zijn wanneer de verschillende VM's worden verzameld in één Azure-beschikbaarheidsset of wanneer het opnieuw instellen van de grootten moet plaatsvinden tussen de M-serie en de Mv2-serie VM's
  • CPU- en geheugenverbruik voor het database-exemplaar dat de stroom van wijzigingen met minimale vertraging en voldoende CPU- en geheugenbronnen kan ontvangen 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 VM waarop een NIET-productie DBMS-exemplaar van een SAP-exemplaar dat niet in productie is, wordt uitgevoerd. Dit kan een beetje lastiger zijn omdat u moet na te gaan wat er nodig is op het gebied van geheugen, CPU-resources, netwerkbandbreedte en opslagbandbreedte voor de specifieke doel-exemplaren die moeten fungeren als hoofd-exemplaar in het scenario voor noodscenario's. Met name in HANA wordt ten zeerste aanbevolen dat u het exemplaar configureert dat fungeert als dr-doel op een gedeelde host, zodat de gegevens niet vooraf worden geladen in het doel-dr-exemplaar.

Voor HANA Large Instance DR-scenario's raadpleegt u deze documenten:

Notitie

Het gebruik van Azure Site Recovery is niet getest voor DBMS-implementaties onder SAP-workload. Als gevolg hiervan 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 belangrijkste scenario's gebruikt door klanten:

  • De noodhersteldoelen in de tweede Azure-regio worden niet gebruikt voor productie- of niet-productiedoeleinden. In dit scenario worden de VM's die als doel voor herstel na noodherstel fungeren idealiter niet geïmplementeerd en worden de afbeelding en wijzigingen in de afbeeldingen van de SAP-productietoepassingslaag gerepliceerd naar de regio voor herstel na noodherstel. Een functionaliteit die een dergelijke taak kan uitvoeren, is Azure Site Recovery. Azure Site Recovery ondersteuning voor een azure-naar-Azure-replicatiescenario zoals dit.
  • De noodhersteldoelen 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 exemplaren van productie-toepassingen vooraf geïnstalleerd op niet-productiesystemen in de toepassingslaag. In het geval van een failover worden de niet-productie-exemplaren afgesloten, worden 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 worden de vooraf geïnstalleerde productie-exemplaren 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 is Windows Storage replicatie een mogelijke oplossing. Op Linux rsync is een levensvatbare oplossing.

Niet-ondersteund scenario

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

  • Storage: Er wordt een aantal zachte opslagapparaten aangeboden in Azure Marketplace. Sommige leveranciers bieden eigen documentatie over het gebruik van deze zachte opslagapparaten in Azure met betrekking tot SAP-software. Ondersteuning van configuraties of implementaties met betrekking tot dergelijke zachte opslagapparaten moet worden geleverd door de leverancier van deze zachte opslagapparaten. Dit feit wordt ook in sap-ondersteuningsnota's #2015553
  • Frameworks voor hoge beschikbaarheid: alleen Pacemaker en Windows Server-failovercluster worden ondersteunde frameworks voor hoge beschikbaarheid voor SAP-workloads in Azure. Zoals eerder vermeld, wordt de oplossing van SIOS Datakeeper beschreven en gedocumenteerd door Microsoft. De onderdelen van SIOS moeten echter worden ondersteund Datakeeper via SIOS als leverancier die deze onderdelen levert. SAP vermeldde ook andere gecertificeerde frameworks voor hoge beschikbaarheid in verschillende SAP-opmerkingen. Sommige zijn ook gecertificeerd door de externe leverancier voor Azure. De productleverancier moet echter wel ondersteuning bieden voor configuraties die deze producten gebruiken. Verschillende leveranciers hebben verschillende integraties in de SAP-ondersteuningsprocessen. U moet verduidelijken welk ondersteuningsproces het beste werkt voor de specifieke leverancier voordat u besluit het product te gebruiken in SAP-configuraties die in Azure zijn geïmplementeerd.
  • Gedeelde schijfclusters waarin databasebestanden zich op de gedeelde schijven opslaan, worden niet ondersteund, met uitzondering van maxDB. Voor alle andere databases is de ondersteunde oplossing om afzonderlijke opslaglocaties te hebben in plaats van een SMB- of NFS-share of gedeelde schijf om scenario's voor hoge beschikbaarheid te configureren

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

  • Implementatiescenario's die een grotere netwerklatentie tussen de SAP-toepassingslaag en de SAP DBMS-laag introduceren in de algemene architectuur van SAP, zoals wordt weergegeven 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 op dezelfde locatie bevinden als Azure en de andere laag in Azure, behalve waar een dergelijk architectuurpatroon wordt geleverd door een systeemeigen Azure-service
    • Virtuele netwerkapparaten implementeren tussen de SAP-toepassingslaag en de DBMS-laag
    • Gebruik te maken van opslag die wordt gehost in datacenters die zich op dezelfde locatie bevinden als het Azure-datacenter voor de SAP DBMS-laag of de SAP Global Transport Directory
    • De twee lagen implementeren met twee verschillende cloudleveranciers. Bijvoorbeeld het implementeren van de DBMS-laag in Oracle Cloud Infrastructure en de toepassingslaag in Azure
  • HANA Pacemaker-clusterconfiguraties met meerdere exemplaren
  • Windows Clusterconfiguraties met gedeelde schijven via SOFS of SMB op ANF voor SAP-databases die worden ondersteund op Windows. In plaats daarvan raden we het gebruik aan van de replicatie van de eigen hoge beschikbaarheid van de specifieke databases en het gebruik van afzonderlijke opslagstacks
  • Implementatie van SAP-databases die worden ondersteund in Linux met databasebestanden die zich op NFS-shares boven op ANF bevinden, met uitzondering van SAP HANA, Oracle op Oracle Linux en Db2 in Suse en Red Hat
  • Implementatie van Oracle DBMS op een ander gast-besturingssysteem dan Windows en Oracle Linux. Zie ook sap support note #2039619

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

  • Azure Site Recovery virtuele DBMS-laag-VM's repliceren. Als gevolg hiervan raden we u aan gebruik te maken van de systeemeigen asynchrone replicatiefunctionaliteit van de database voor mogelijke configuratie van herstel na noodherstel

Volgende stappen

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