SAP NetWeaver uitvoeren in Windows op Azure

Deze handleiding bevat een set bewezen procedures voor het uitvoeren van SAP NetWeaver in een Windows-omgeving, in Azure, met hoge beschikbaarheid. De database is AnyDB, de SAP-term voor elk ondersteund databasebeheersysteem (DBMS) naast SAP HANA.

Architectuur

In het volgende diagram ziet u SAP NetWeaver in een Windows-omgeving.

Een Visio-bestand van deze architectuur downloaden.

In deze handleiding wordt een productiesysteem beschreven. Het systeem wordt geïmplementeerd met specifieke VM-grootten (virtuele machines) die u kunt wijzigen om tegemoet te komen aan de behoeften van uw organisatie. Het systeem kan worden gereduceerd tot één virtuele machine. In deze handleiding is de netwerkindeling aanzienlijk vereenvoudigd om architectuurprincipes te demonstreren. Het is niet bedoeld om een volledig bedrijfsnetwerk te beschrijven.

Workflow

Virtuele netwerken. De Azure Virtual Network-service verbindt Azure-resources met elkaar met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met een on-premises netwerk via een Azure ExpressRoute-gateway die is geïmplementeerd in de hub van een stertopologie. De spoke is het virtuele netwerk dat wordt gebruikt voor de SAP-toepassingen en de databaselagen. Het virtuele hubnetwerk wordt gebruikt voor gedeelde services, zoals Azure Bastion en back-up.

Peering van virtuele netwerken. Deze architectuur maakt gebruik van een sternetwerktopologie met meerdere virtuele netwerken die aan elkaar zijn gekoppeld. Deze topologie biedt netwerksegmentatie en isolatie voor services die zijn geïmplementeerd in Azure. Peering maakt transparante connectiviteit mogelijk tussen gekoppelde virtuele netwerken via het Microsoft backbone-netwerk. Er wordt geen prestatiestraf in rekening gebracht als deze binnen één regio wordt geïmplementeerd. Het virtuele netwerk is onderverdeeld in afzonderlijke subnetten voor elke laag: toepassing (SAP NetWeaver), de database en gedeelde services zoals Bastion en een back-upoplossing van derden.

VM's. In deze architectuur worden VM's gebruikt voor de toepassingslaag en databaselaag, gegroepeerd op de volgende manier:

• SAP NetWeaver. De toepassingslaag maakt gebruik van Windows-VM's om SAP Central Services en SAP-toepassingsservers uit te voeren. Voor hoge beschikbaarheid worden de VM's met Central Services geconfigureerd in een Windows-serverfailovercluster. Ze worden ondersteund door Azure-bestandsshares of gedeelde Azure-schijven.

• AnyDB. De databaselaag voert AnyDB uit als de database, die Microsoft SQL Server, Oracle of IBM Db2 kan zijn.

• Bastion-service. Beheer istrators maken gebruik van een verbeterde beveiligings-VM die een bastionhost wordt genoemd om verbinding te maken met andere VM's. Het maakt meestal deel uit van gedeelde services, zoals back-upservices. Als Secure Shell Protocol (SSH) en Remote Desktop Protocol (RDP) de enige services zijn die worden gebruikt voor serverbeheer, is een Azure Bastion-host een goede oplossing. Als u andere beheerhulpprogramma's gebruikt, zoals SQL Server Management Studio of SAP Frontend, gebruikt u een traditionele, zelf geïmplementeerde jumpbox.

Privé-DNS service.Azure Privé-DNS biedt een betrouwbare en beveiligde DNS-service voor uw virtuele netwerk. Azure Privé-DNS beheert en lost domeinnamen op in het virtuele netwerk, zonder dat u een aangepaste DNS-oplossing hoeft te configureren.

Load balancers. Als u verkeer wilt distribueren naar VM's in het subnet van de SAP-toepassingslaag voor hoge beschikbaarheid, raden we u aan een Azure Standard Load Balancer te gebruiken. Houd er rekening mee dat een standaard load balancer standaard een beveiligingsniveau biedt. VM's die zich achter een standard load balancer bevinden, hebben geen uitgaande internetverbinding. Als u uitgaand internet op de VM's wilt inschakelen, moet u de standaardconfiguratie van de load balancer bijwerken. Voor hoge beschikbaarheid van SAP-webtoepassingen gebruikt u de ingebouwde SAP Web Dispatcher of een andere commercieel beschikbare load balancer. Baseer uw selectie op:

• Uw verkeerstype, zoals HTTP of SAP GUI.
• De netwerkservices die u nodig hebt, zoals SSL-beëindiging (Secure Sockets Layer).

Zie Inkomende en uitgaande internetverbindingen voor SAP in Azure voor enkele voorbeelden van inkomende/uitgaande ontwerpen.

Standard Load Balancer ondersteunt meerdere front-end virtuele IP-adressen. Deze ondersteuning is ideaal voor cluster-implementaties die betrekking hebben op deze onderdelen:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Replicatieserver (ERS) in de wachtrij weergeven

De Standard-SKU biedt ook ondersteuning voor SAP-clusters met meerdere systemen (multi-SID). Met andere woorden, meerdere SAP-systemen in Windows kunnen een gemeenschappelijke infrastructuur voor hoge beschikbaarheid delen om kosten te besparen. Evalueer de kostenbesparingen en vermijd het plaatsen van te veel systemen in één cluster. ondersteuning voor Azure niet meer dan vijf SID's per cluster.

Toepassingsgateway. Azure-toepassing Gateway is een load balancer voor webverkeer die u kunt gebruiken om het verkeer naar uw webtoepassingen te beheren. Traditionele load balancers werken op de transportlaag (OSI-laag 4 - TCP en UDP). Ze routeren verkeer op basis van het bron-IP-adres en de poort naar een doel-IP-adres en -poort. Application Gateway kan routeringsbeslissingen nemen op basis van aanvullende kenmerken van een HTTP-aanvraag, zoals het URI-pad of hostheaders. Dit type routering staat bekend al taakverdeling op de toepassingslaag (OSI-laag 7).

Netwerkbeveiligingsgroepen. Als u inkomend, uitgaand en intrasubnetverkeer in een virtueel netwerk wilt beperken, maakt u netwerkbeveiligingsgroepen.

Toepassingsbeveiligingsgroepen. Gebruik toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen om gedetailleerd netwerkbeveiligingsbeleid op basis van workloads te definiëren dat is gericht op toepassingen. Toepassingsbeveiligingsgroepen bieden een manier om VM's op naam te groeperen en u te helpen toepassingen te beveiligen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

Gateway. Een gateway verbindt afzonderlijke netwerken en breidt uw on-premises netwerk uit naar het virtuele Azure-netwerk. U wordt aangeraden ExpressRoute te gebruiken om privéverbindingen te maken die niet via het openbare internet gaan, maar u kunt ook een site-naar-site-verbinding gebruiken. Als u de latentie wilt verminderen of de doorvoer wilt verhogen, kunt u ExpressRoute Global Reach en ExpressRoute FastPath overwegen, zoals verderop in dit artikel wordt besproken.

Azure Storage. Opslag biedt gegevenspersistentie voor een virtuele machine in de vorm van een virtuele harde schijf. Azure Managed Disks wordt aangeraden.

Aanbevelingen

In deze architectuur wordt een kleine implementatie op productieniveau beschreven. Implementaties verschillen op basis van bedrijfsvereisten, dus overweeg deze aanbevelingen als uitgangspunt.

VM's

Pas in toepassingsservergroepen en -clusters het aantal VM's aan op basis van uw vereisten. Zie Planning en implementatie van Azure Virtual Machines voor SAP NetWeaver voor gedetailleerde informatie over het uitvoeren van SAP NetWeaver op VM's.

Zie SAP-opmerking 1928533 voor meer informatie over SAP-ondersteuning voor typen azure-VM's en metrische gegevens over doorvoergegevens (SAPS). Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

SAP-webdispatcher

Het onderdeel Web Dispatcher wordt gebruikt voor taakverdeling van SAP-verkeer tussen de SAP-toepassingsservers. Voor een hoge beschikbaarheid voor het webdispatcheronderdeel wordt Load Balancer gebruikt voor het implementeren van het failovercluster van Web Dispatcher-exemplaren of de parallelle installatie van Web Dispatcher. Zie Hoge beschikbaarheid van SAP Web Dispatcher voor een gedetailleerde beschrijving van de oplossing.

Groep toepassingsservers

De SAP SMLG-transactie wordt vaak gebruikt voor het beheren van aanmeldingsgroepen voor ABAP-toepassingsservers en voor het verdelen van aanmeldingsgebruikers. Andere transacties, zoals SM61 voor batchservergroepen en RZ12 voor RFC-groepen (Remote Function Call), worden ook aanmeldingsgebruikers gelijkmatig verdeeld. Deze transacties maken gebruik van de taakverdelingsfunctie binnen de berichtserver van SAP Central Services om binnenkomende sessies of workloads te distribueren tussen de groep SAP-toepassingsservers voor SAP GUIs en RFC-verkeer.

SAP Central Services-cluster

Deze architectuur voert Central Services uit op VM's in de toepassingslaag. Central Services is een potentieel single point of failure (SPOF) wanneer deze wordt geïmplementeerd op één VIRTUELE machine. Als u een maximaal beschikbare oplossing wilt implementeren, gebruikt u een bestandssharecluster of een cluster met gedeelde schijven.

Voor maximaal beschikbare bestandsshares zijn er verschillende opties. U wordt aangeraden Azure Files-shares te gebruiken als volledig beheerde, cloudeigen SMB-shares (Server Message Block) of Network File System (NFS). Een alternatief voor Azure Files is Azure NetApp Files, dat krachtige NFS- en SMB-shares biedt.

U kunt ook de maximaal beschikbare bestandsshares implementeren op de Central Services-exemplaren met behulp van een Windows-serverfailovercluster met Azure Files. Deze oplossing ondersteunt ook een Windows-cluster met gedeelde schijven met behulp van een gedeelde Azure-schijf als het gedeelde clustervolume. Als u liever gedeelde schijven gebruikt, raden we u aan om gedeelde Azure-schijven te gebruiken om een Windows Server-failovercluster in te stellen voor SAP Central Services-cluster.

Er zijn ook partnerproducten zoals SIOS DataKeeper Cluster Edition van SIOS Technology Corp. Met deze invoegtoepassing wordt inhoud gerepliceerd van onafhankelijke schijven die zijn gekoppeld aan de ASCS-clusterknooppunten en worden de schijven vervolgens weergegeven als een gedeeld clustervolume aan de clustersoftware.

Als u clusternetwerkpartitionering gebruikt, gebruikt de clustersoftware quorumstemmen om een segment van het netwerk en de bijbehorende services te selecteren om te fungeren als de hersenen van het gefragmenteerde cluster. Windows biedt veel quorummodellen. Deze oplossing maakt gebruik van Cloud Witness omdat het eenvoudiger is en meer beschikbaarheid biedt dan een rekenknooppuntwitness. De Azure-bestandssharewitness is een ander alternatief voor het bieden van een clusterquorumstem.

Bij een Azure-implementatie maken de toepassingsservers verbinding met de maximaal beschikbare Central Services met behulp van de namen van de virtuele host van de ASCS- of ERS-services. Deze hostnamen worden toegewezen aan de front-end-IP-configuratie van het cluster van de load balancer. Load Balancer ondersteunt meerdere front-end-IP's, dus zowel de virtuele IP-adressen van ASCS als DE ERS (VIP's) kunnen worden gebonden aan één load balancer.

Netwerken

Deze architectuur maakt gebruik van een stertopologie. Het virtuele hubnetwerk fungeert als een centraal punt van connectiviteit met een on-premises netwerk. De spokes zijn virtuele netwerken die peeren met de hub en de SAP-workloads isoleren. Verkeer stroomt tussen het on-premises datacenter en de hub via een gatewayverbinding.

Netwerkinterfacekaarten (NIC's)

NIC's maken alle communicatie tussen VM's in een virtueel netwerk mogelijk. Traditionele on-premises SAP-implementaties implementeren meerdere NIC's per computer om beheerverkeer van bedrijfsverkeer te scheiden.

In Azure is het virtuele netwerk een softwaregedefinieerde netwerk waarmee al het verkeer via dezelfde netwerkinfrastructuur wordt verzonden. Het is dus niet nodig om meerdere NIC's te gebruiken om prestatieredenen. Maar als uw organisatie verkeer moet scheiden, kunt u meerdere NIC's per VM implementeren en elke NIC verbinden met een ander subnet. Vervolgens kunt u netwerkbeveiligingsgroepen gebruiken om verschillende beleidsregels voor toegangsbeheer af te dwingen.

Azure NIC's ondersteunen meerdere IP-adressen. Deze ondersteuning voldoet aan de praktijk die SAP aanbeveelt om virtuele hostnamen voor installaties te gebruiken. Zie SAP-notitie 962955 voor een volledig overzicht. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

Subnetten en netwerkbeveiligingsgroepen

Met deze architectuur wordt de adresruimte van het virtuele netwerk onderverdeeld in subnetten. U kunt elk subnet koppelen aan een netwerkbeveiligingsgroep die het toegangsbeleid voor het subnet definieert. Plaats toepassingsservers op een afzonderlijk subnet. Hierdoor kunt u ze eenvoudiger beveiligen door het subnetbeveiligingsbeleid te beheren in plaats van de afzonderlijke servers.

Wanneer u een netwerkbeveiligingsgroep koppelt aan een subnet, is de netwerkbeveiligingsgroep van toepassing op alle servers in het subnet en biedt een nauwkeurige controle over de servers. Stel netwerkbeveiligingsgroepen in met behulp van Azure Portal, PowerShell of De Azure CLI.

ExpressRoute Global Reach

Als uw netwerkomgeving twee of meer ExpressRoute-verbindingen bevat, kan ExpressRoute Global Reach u helpen bij het verminderen van netwerkhops en latentie. Deze technologie is een BGP-routepeering (Border Gateway Protocol) die is ingesteld tussen twee of meer ExpressRoute-verbindingen om twee ExpressRoute-routeringsdomeinen te overbrugmen. Global Reach vermindert de latentie wanneer netwerkverkeer meer dan één ExpressRoute-verbinding doorkruist. Deze is momenteel alleen beschikbaar voor persoonlijke peering op ExpressRoute-circuits.

Op dit moment zijn er geen lijsten met netwerktoegangsbeheer of andere kenmerken die kunnen worden gewijzigd in Global Reach. Alle routes die zijn geleerd door een bepaald ExpressRoute-circuit (van on-premises en Azure) worden dus geadverteerd via de circuitpeering naar het andere ExpressRoute-circuit. U wordt aangeraden on-premises netwerkverkeer te filteren om de toegang tot resources te beperken.

ExpressRoute FastPath

FastPath is ontworpen om de prestaties van het gegevenspad tussen uw on-premises netwerk en uw virtuele netwerk te verbeteren. Wanneer deze functie is ingeschakeld, verzendt FastPath netwerkverkeer rechtstreeks naar virtuele machines in het virtuele netwerk, waardoor de gateway wordt overgeslagen.

Voor alle nieuwe ExpressRoute-verbindingen met Azure is FastPath de standaardconfiguratie. Neem voor bestaande ExpressRoute-circuits contact op met ondersteuning voor Azure om FastPath te activeren.

FastPath biedt geen ondersteuning voor peering van virtuele netwerken. Als andere virtuele netwerken zijn gekoppeld aan een netwerk dat is verbonden met ExpressRoute, wordt het netwerkverkeer van uw on-premises netwerk naar de andere virtuele spoke-netwerken verzonden naar de gateway van het virtuele netwerk. De tijdelijke oplossing is om alle virtuele netwerken rechtstreeks te verbinden met het ExpressRoute-circuit. Deze functie is momenteel beschikbaar als openbare preview-versie.

Load balancers

SAP Web Dispatcher verwerkt taakverdeling van HTTP(S)-verkeer naar een groep SAP-toepassingsservers. Deze software load balancer biedt toepassingslaagservices (ook wel laag 7 genoemd in het ISO-netwerkmodel) die SSL-beëindiging en andere offloadingfuncties kunnen uitvoeren.

Azure Load Balancer is een netwerktransmissielaagservice (laag 4) waarmee verkeer wordt verdeeld met behulp van een hash van vijf tuples van de gegevensstromen. De hash is gebaseerd op bron-IP, bronpoort, doel-IP, doelpoort en protocoltype. In SAP-implementaties in Azure wordt Load Balancer gebruikt in clusterinstallatie om verkeer naar het primaire service-exemplaar of naar het gezonde knooppunt te leiden als er een fout optreedt.

U wordt aangeraden Standard Load Balancer te gebruiken voor alle SAP-scenario's. Als vm's in de back-endpool openbare uitgaande connectiviteit vereisen of als ze worden gebruikt in een Azure-zone-implementatie, vereist Standard Load Balancer aanvullende configuraties omdat ze standaard beveiligd zijn. Ze staan geen uitgaande connectiviteit toe, tenzij u deze expliciet configureert.

Voor verkeer van SAP GUI-clients die verbinding maken met een SAP-server via het DIAG-protocol of RFC, wordt de belasting verdeeld via aanmeldingsgroepen voor SAP-toepassingsservers. Voor dit type installatie hebt u geen andere load balancer nodig.

Storage

Sommige organisaties gebruiken standaardopslag voor hun toepassingsservers. Standaard beheerde schijven worden niet ondersteund. Zie SAP-notitie 1928533. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig. U wordt aangeraden in alle gevallen premium beheerde Azure-schijven te gebruiken. Een recente update van SAP-opmerking 2015553 sluit het gebruik van Standard HDD-opslag en Standard SSD-opslag uit voor enkele specifieke gebruiksscenario's.

Toepassingsservers hosten geen zakelijke gegevens. U kunt dus ook de kleinere P4- en P6 Premium-schijven gebruiken om de kosten te minimaliseren. Hierdoor kunt u profiteren van de SLA voor vm's met één exemplaar als u een centrale SAP-stackinstallatie hebt.

Voor scenario's met hoge beschikbaarheid kunt u Azure-bestandsshares en gedeelde Azure-schijven gebruiken. Beheerde Schijven van Azure Premium SSD en Azure Ultra Disk Storage zijn beschikbaar voor gedeelde Azure-schijven en Premium SSD is beschikbaar voor Azure-bestandsshares.

Opslag wordt ook gebruikt door Cloud Witness om quorum te onderhouden met een apparaat in een externe Azure-regio, weg van de primaire regio waar het cluster zich bevindt.

Voor het back-upgegevensarchief raden we azure cool- en archieftoegangslagen aan. Deze opslaglagen bieden een rendabele manier om gegevens met een lange levensduur op te slaan die niet vaak worden geopend.

Azure Premium SSD v2-schijfopslag is ontworpen voor prestatiekritieke workloads, zoals systemen voor onlinetransactieverwerking die consistent een latentie van minder dan milliseconden nodig hebben in combinatie met hoge IOPS en doorvoer.

Ultra Disk Storage vermindert de schijflatentie aanzienlijk. Als gevolg hiervan profiteert het van prestatiekritieke toepassingen zoals de SAP-databaseservers. Als u opties voor blokopslag in Azure wilt vergelijken, raadpleegt u De typen beheerde azure-schijven.

Gebruik Azure NetApp Files voor een hoogwaardige gedeelde gegevensopslag met hoge beschikbaarheid. Deze technologie is met name handig voor de databaselaag wanneer u Oracle gebruikt en ook wanneer u toepassingsgegevens host.

Prestatieoverwegingen

SAP-toepassingsservers communiceren voortdurend met de databaseservers. Voor prestatiekritieke toepassingen die worden uitgevoerd op databaseplatforms, schakelt u Write Accelerator in voor het logboekvolume als u Premium SSD v1 gebruikt. Hierdoor kan de latentie van logboekschrijfbewerkingen worden verbeterd. Write Accelerator is beschikbaar voor VM's uit de M-serie.

Gebruik Versneld netwerken om communicatie tussen servers te optimaliseren. De meeste voor algemeen gebruik en rekenkracht geoptimaliseerde VM-exemplaargrootten met twee of meer vCPU's bieden ondersteuning voor versneld netwerken. Op exemplaren die hyperthreading ondersteunen, ondersteunen VM-exemplaren met vier of meer vCPU's versneld netwerken.

Als u een hoge IOPS- en schijfdoorvoer wilt bereiken, volgt u de algemene procedures voor optimalisatie van de prestaties van opslagvolumes, die van toepassing zijn op de indeling van Azure-opslag. U kunt bijvoorbeeld meerdere schijven samen plaatsen om een gestreept schijfvolume te maken om de I/O-prestaties te verbeteren. Door de leescache in te schakelen voor Storage-inhoud die veelvuldig wordt gewijzigd, wordt de snelheid van het ophalen van gegevens verhoogd.

Premium SSD v2 biedt hogere prestaties dan Premium SSD's en is over het algemeen goedkoper. U kunt een Premium SSD v2-schijf instellen op elke ondersteunde grootte die u wilt gebruiken en gedetailleerde aanpassingen aan de prestaties aanbrengen zonder uitvaltijd.

Ultra Disk Storage is beschikbaar voor I/O-intensieve toepassingen. Waar deze schijven beschikbaar zijn, raden we deze aan via Write Accelerator Premium-opslag. U kunt prestatiegegevens zoals IOPS en MBps afzonderlijk verhogen of verlagen zonder dat u opnieuw hoeft op te starten.

Zie Azure Virtual Machines plannen en implementeren voor SAP NetWeaver voor hulp bij het optimaliseren van Azure Storage voor SAP-workloads op SQL Server.

De plaatsing van een virtueel netwerkapparaat (NVA) tussen de toepassing en de databaselagen voor een SAP-toepassingsstack wordt niet ondersteund. Deze procedure introduceert een aanzienlijke verwerkingstijd voor gegevenspakketten, wat leidt tot onaanvaardbare toepassingsprestaties.

Nabijheidsplaatsingsgroepen

Voor sommige SAP-toepassingen is regelmatig communicatie met de database vereist. De fysieke nabijheid van de toepassing en de databaselagen zijn van invloed op netwerklatentie, wat de prestaties van de toepassing nadelig kan beïnvloeden.

Als u de netwerklatentie wilt optimaliseren, kunt u nabijheidsplaatsingsgroepen gebruiken, die een logische beperking instellen op de VM's die in beschikbaarheidssets zijn geïmplementeerd. Nabijheidsplaatsingsgroepen geven de voorkeur aan co-locatie en prestaties ten opzichte van schaalbaarheid, beschikbaarheid of kosten. Ze kunnen de gebruikerservaring voor de meeste SAP-toepassingen aanzienlijk verbeteren. Zie Scripts voor scripts die beschikbaar zijn op GitHub vanuit het SAP-implementatieteam.

Beschikbaarheidszones

Beschikbaarheidszones bieden een manier om VM's te implementeren in datacenters, die fysiek gescheiden locaties zijn binnen een specifieke Azure-regio. Hun doel is om de beschikbaarheid van de service te verbeteren. Maar het implementeren van resources in meerdere zones kan de latentie verhogen, dus houd rekening met prestatieoverwegingen.

Beheer istrators hebben een duidelijk netwerklatentieprofiel nodig tussen alle zones van een doelregio voordat ze de plaatsing van resources met minimale latentie tussen zones kunnen bepalen. Als u dit profiel wilt maken, implementeert u kleine VM's in elke zone om te testen. Aanbevolen hulpprogramma's voor deze tests zijn PsPing en Iperf. Wanneer de tests zijn voltooid, verwijdert u de VM's die u hebt gebruikt voor het testen. Als alternatief kunt u overwegen om een azure-hulpprogramma voor latentiecontrole tussen zones te gebruiken.

Schaalbaarheidsoverwegingen

Voor de SAP-toepassingslaag biedt Azure een breed scala aan VM-grootten voor omhoog en uitschalen. Zie SAP-notitie 1928533 - SAP-toepassingen in Azure voor een inclusieve lijst : ondersteunde producten en Azure VM-typen. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

U kunt SAP-toepassingsservers en de Central Services-clusters omhoog en omlaag schalen. U kunt ze ook uitschalen of inschalen door het aantal exemplaren te wijzigen dat u gebruikt. De AnyDB-database kan omhoog en omlaag worden geschaald, maar wordt niet uitgeschaald. De SAP-databasecontainer voor AnyDB biedt geen ondersteuning voor sharding.

Beschikbaarheidsoverwegingen

Resourceredundantie is het algemene thema in maximaal beschikbare infrastructuuroplossingen. Zie sla voor virtuele machines voor sla's met één exemplaar voor vm-beschikbaarheid voor verschillende opslagtypen. Als u de beschikbaarheid van services in Azure wilt vergroten, implementeert u VM-resources met virtuele-machineschaalsets met flexibele indeling, beschikbaarheidszones of beschikbaarheidssets.

Met Azure kan de implementatie van SAP-workloads regionaal of zonegebonden zijn, afhankelijk van de beschikbaarheids- en tolerantievereisten van de SAP-toepassingen. Azure biedt verschillende implementatieopties, zoals Virtual Machine Scale Sets met Flexibele indeling (FD=1), beschikbaarheidszones en beschikbaarheidssets, om de beschikbaarheid van resources te verbeteren. Zie architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver voor een uitgebreid inzicht in de beschikbare implementatieopties en hun toepasbaarheid in verschillende Azure-regio's (inclusief zones, binnen één zone of in een regio zonder zones).

In deze gedistribueerde installatie van de SAP-toepassing wordt de basisinstallatie gerepliceerd om hoge beschikbaarheid te bereiken. Voor elke laag van de architectuur varieert het ontwerp voor hoge beschikbaarheid.

Web Dispatcher in de toepassingsserverlaag

Het onderdeel Web Dispatcher wordt gebruikt als een load balancer voor SAP-verkeer tussen de SAP-toepassingsservers. Voor een hoge beschikbaarheid van SAP Web Dispatcher implementeert Load Balancer het failovercluster of de parallelle Web Dispatcher-installatie.

Voor internetgerichte communicatie raden we een zelfstandige oplossing aan in het perimeternetwerk, ook wel DMZ genoemd, om te voldoen aan beveiligingsproblemen.

Embedded Web Dispatcher op ASCS is een speciale optie. Als u deze optie gebruikt, kunt u overwegen de juiste grootte te bepalen vanwege de extra werkbelasting op ASCS.

Central Services in de toepassingsserverlaag

Hoge beschikbaarheid van de Central Services wordt geïmplementeerd met een Windows-serverfailovercluster. Wanneer de clusteropslag voor het failovercluster wordt geïmplementeerd in Azure, kunt u deze op twee manieren configureren: als een geclusterde gedeelde schijf of als een geclusterde bestandsshare.

• U wordt aangeraden Azure Files te gebruiken als volledig beheerde, cloudeigen SMB- of NFS-shares. Een andere manier is om Azure NetApp Files te gebruiken, dat krachtige, hoogwaardige NFS- en SMB-shares biedt.

• Er zijn twee manieren om clusters in te stellen met gedeelde schijven in Azure. Ten eerste raden we u aan gedeelde Azure-schijven te gebruiken om een Windows-serverfailovercluster in te stellen voor SAP Central Services. Zie ASCS-cluster met behulp van gedeelde Azure-schijven voor een implementatievoorbeeld. Een andere manier om een geclusterde gedeelde schijf te implementeren, is door SIOS DataKeeper te gebruiken om de volgende taken uit te voeren:

  • Repliceer de inhoud van onafhankelijke schijven die zijn gekoppeld aan de clusterknooppunten.
  • Abstract de stations als een gedeeld clustervolume voor de clusterbeheerder.

  Zie Clustering SAP ASCS in Azure met SIOS voor implementatiedetails.

Als u Standard Load Balancer gebruikt, kunt u de poort voor hoge beschikbaarheid inschakelen. Hierdoor kunt u voorkomen dat u taakverdelingsregels voor meerdere SAP-poorten moet configureren. Wanneer u Azure Load Balancers instelt, schakelt u Direct Server Return (DSR) in, ook wel Zwevend IP-adres genoemd. Dit biedt een manier voor serverreacties om de load balancer te omzeilen. Met deze directe verbinding blijft de load balancer een knelpunt in het pad van gegevensoverdracht. U wordt aangeraden DSR in te schakelen voor de ASCS- en databaseclusters.

Toepassingsservices in de toepassingsserverlaag

Hoge beschikbaarheid voor de SAP-toepassingsservers wordt bereikt door taakverdeling van verkeer binnen een groep toepassingsservers. U hebt geen clustersoftware, SAP Web Dispatcher of de Azure Load Balancer nodig. De SAP-berichtserver kan het clientverkeer verdelen over de toepassingsservers die zijn gedefinieerd in een ABAP-aanmeldingsgroep door de transactie-SMLG.

Databaselaag

In deze architectuur wordt de brondatabase uitgevoerd op AnyDB: een DBMS zoals SQL Server, SAP ASE, IBM Db2 of Oracle. De systeemeigen replicatiefunctie van de databaselaag biedt handmatige of automatische failover tussen gerepliceerde knooppunten.

Zie de DBMS-implementatie van Azure Virtual Machines voor SAP NetWeaver voor implementatiedetails over specifieke databasesystemen.

VM's die zijn geïmplementeerd in beschikbaarheidszones

Een beschikbaarheidszone bestaat uit een of meer datacenters. Het is ontworpen om de beschikbaarheid van workloads te verbeteren en toepassingsservices en VM's te beschermen tegen storingen in datacenters. VM's in één zone worden behandeld alsof ze zich in één foutdomein bevinden. Wanneer u zonegebonden implementatie selecteert, worden VM's in dezelfde zone gedistribueerd naar foutdomeinen op basis van best effort.

In Azure-regio's die meerdere zones ondersteunen, zijn er ten minste drie zones beschikbaar. Maar de maximale afstand tussen datacenters in deze zones is niet gegarandeerd. Als u een sap-systeem met meerdere lagen in meerdere zones wilt implementeren, moet u de netwerklatentie binnen een zone en in verschillende doelzones kennen. U moet ook weten hoe gevoelig uw geïmplementeerde toepassingen zijn voor netwerklatentie.

Houd rekening met deze overwegingen wanneer u besluit om resources in beschikbaarheidszones te implementeren:

• Latentie tussen VM's in één zone
• Latentie tussen VM's in gekozen zones
• Beschikbaarheid van dezelfde Azure-services (VM-typen) in de gekozen zones

Voorbeeld van actieve/inactieve implementatie

In dit voorbeeld verwijst de actieve/passieve status naar de status van de toepassingsservice binnen de zones. In de toepassingslaag bevinden alle vier de actieve toepassingsservers van het SAP-systeem zich in zone 1. Een andere set van vier passieve toepassingsservers is gebouwd in zone 2, maar wordt afgesloten. Ze worden alleen geactiveerd wanneer ze nodig zijn.

De clusters met twee knooppunten voor Central Services en de databaseservices worden verdeeld over twee zones. Als zone 1 mislukt, worden Central Services en de databaseservices uitgevoerd in zone 2. De passieve toepassingsservers in zone 2 worden geactiveerd. Nu alle onderdelen van dit SAP-systeem zich nu samen in dezelfde zone bevinden, wordt de netwerklatentie geminimaliseerd.

Voorbeeld van actieve/actieve implementatie

In een actieve/actieve implementatie worden twee sets toepassingsservers gebouwd in twee zones. Binnen elke zone zijn twee toepassingsservers in elke set servers inactief, omdat ze worden afgesloten. Als gevolg hiervan zijn er actieve toepassingsservers in beide zones tijdens normale bewerkingen.

Central Services en de databaseservices worden uitgevoerd in zone 1. De toepassingsservers in zone 2 hebben mogelijk langere netwerklatentie wanneer ze verbinding maken met Central Services en de databaseservices vanwege de fysieke afstand tussen zones.

Als zone 1 offline gaat, voert Central Services en databaseservices een failover uit naar zone 2. U kunt de slapende toepassingsservers online brengen om volledige capaciteit te bieden voor toepassingsverwerking.

Overwegingen voor herstel na noodgevallen

Elke laag in de SAP-toepassingsstack maakt gebruik van een andere benadering om DR-beveiliging te bieden. Zie overzicht van herstel na noodgevallen en infrastructuurrichtlijnen voor SAP-workload en richtlijnen voor herstel na noodgevallen voor SAP-toepassingen voor herstel na noodgeval voor dr-strategieën en implementatiedetails.

Overwegingen voor beheer en bewerkingen

Houd rekening met de volgende punten om uw systeem in productie te houden.

Azure Center for SAP solutions

Azure Center voor SAP-oplossingen is een end-to-end-oplossing waarmee u SAP-systemen kunt maken en uitvoeren als een geïntegreerde workload in Azure en die een naadloze basis biedt voor innovatie. Bovendien maakt het Azure Center voor SAP-oplossingen begeleide implementatie de benodigde reken-, opslag- en netwerkonderdelen die u nodig hebt om uw SAP-systeem uit te voeren. Vervolgens kunt u de installatie van SAP-software automatiseren volgens de best practices van Microsoft. U kunt profiteren van de beheermogelijkheden voor zowel nieuwe als bestaande SAP-systemen op basis van Azure. Zie Azure Center voor SAP-oplossingen voor meer informatie.

Als u meer controle nodig hebt over onderhoudsgebeurtenissen of hardware-isolatie, kunt u overwegen om uw VM's te implementeren op toegewezen hosts.

Backup

Databases zijn kritieke workloads waarvoor een RPO (Low Recovery Point Objective) en langetermijnretentie is vereist.

• Voor SAP op SQL Server is het gebruik van Azure Backup om een back-up te maken van SQL Server-databases die worden uitgevoerd op VM's. Een andere optie is azure Files-momentopnamen te gebruiken om een back-up te maken van SQL Server-databasebestanden.

• Zie de sectie 'Back-up/herstel' in Azure VM DBMS Deployment voor SAP.

• Zie de aanbevelingen voor back-ups voor uw databaseprovider voor andere databases. Als de database ondersteuning biedt voor de Windows Volume Shadow Copy Service (VSS), gebruikt u VSS-momentopnamen voor toepassingsconsistente back-ups.

Identiteitsbeheer

Gebruik een gecentraliseerd identiteitsbeheersysteem zoals Microsoft Entra ID en Active Directory-domein Services (AD DS) om de toegang tot resources op alle niveaus te beheren:

• Toegang bieden tot Azure-resources met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC).

• Ververleent toegang tot Azure-VM's met behulp van Lightweight Directory Access Protocol (LDAP), Microsoft Entra ID, Kerberos of een ander systeem.

Ondersteuning voor toegang binnen de toepassingen zelf met behulp van de services die SAP biedt. Of gebruik OAuth 2.0 en Microsoft Entra-id.

Controleren

Als u de beschikbaarheid en prestaties van toepassingen en services in Azure wilt maximaliseren, gebruikt u Azure Monitor, een uitgebreide oplossing voor het verzamelen, analyseren en uitvoeren van telemetrie vanuit uw cloud- en on-premises omgevingen. Azure Monitor laat zien hoe toepassingen presteren en proactief problemen identificeren die van invloed zijn op deze toepassingen en de resources waarvoor ze afhankelijk zijn. Voor SAP-toepassingen die worden uitgevoerd op SAP HANA en andere belangrijke databaseoplossingen, raadpleegt u Azure Monitor voor SAP-oplossingen voor meer informatie over hoe Azure Monitor voor SAP u kan helpen bij het beheren van de beschikbaarheid en prestaties van SAP-services.

Beveiligingsoverwegingen

SAP heeft een eigen UME (User Management Engine) voor het beheren van op rollen gebaseerde toegang en autorisatie binnen de SAP-toepassing en -databases. Zie de SAP NetWeaver-beveiligingshandleiding voor gedetailleerde richtlijnen voor toepassingsbeveiliging.

Voor meer netwerkbeveiliging kunt u overwegen een perimeternetwerk te gebruiken dat gebruikmaakt van een NVA om een firewall te maken vóór het subnet voor Web Dispatcher.

U kunt een NVA implementeren om verkeer tussen virtuele netwerken te filteren, maar plaats deze niet tussen de SAP-toepassing en de database. Controleer ook de routeringsregels die zijn geconfigureerd op het subnet en vermijd verkeer naar een NVA met één exemplaar. Dit kan leiden tot uitvaltijd van onderhoud en storingen in het netwerk of geclusterde knooppunten.

Voor infrastructuurbeveiliging worden gegevens versleuteld tijdens overdracht en at-rest. Zie de sectie 'Aanbevelingen voor beveiliging' in Azure Virtual Machines plannen en implementeren voor SAP NetWeaver voor meer informatie over netwerkbeveiliging. In dit artikel worden ook de netwerkpoorten opgegeven die u moet openen op de firewalls om toepassingscommunicatie toe te staan.

U kunt Azure Disk Encryption gebruiken om Windows-VM-schijven te versleutelen. Deze service maakt gebruik van de BitLocker-functie van Windows om volumeversleuteling te bieden voor het besturingssysteem en de gegevensschijven. De oplossing werkt ook met Azure Key Vault om u te helpen bij het beheren van de schijfversleutelingssleutels en -geheimen in uw key vault-abonnement. Gegevens op de VM-schijven worden in rust versleuteld in uw Azure-opslag.

Voor data-at-rest-versleuteling versleutelt SQL Server Transparent Data Encryption (TDE) SQL Server-, Azure SQL Database- en Azure Synapse Analytics-gegevensbestanden. Zie SQL Server Azure Virtual Machines DBMS-implementatie voor SAP NetWeaver voor meer informatie.

Als u bedreigingen van binnen en buiten de firewall wilt bewaken, kunt u Microsoft Sentinel (preview) implementeren. De oplossing biedt continue detectie en analyse van bedreigingen voor SAP-systemen die zijn geïmplementeerd in Azure, in andere clouds of on-premises. Zie Bedreigingsbewaking implementeren voor SAP in Microsoft Sentinel voor implementatierichtlijnen.

Zoals altijd beheert u beveiligingsupdates en patches om uw gegevensassets te beschermen. Overweeg het gebruik van een end-to-end automatiseringsbenadering voor deze taak.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Als voor uw workload meer geheugen en minder CPU's nodig zijn, kunt u overwegen om een van de beperkte vm-grootten van vCPU's te gebruiken om de softwarelicentiekosten te verlagen die per vCPU in rekening worden gebracht.

VM's

Deze architectuur maakt gebruik van VM's voor de toepassingslaag en de databaselaag. De SAP NetWeaver-laag maakt gebruik van Windows-VM's om SAP-services en -toepassingen uit te voeren. De databaselaag voert AnyDB uit als de database, zoals SQL Server, Oracle of IBM DB2. VM's worden ook gebruikt als jumpboxen voor beheer.

Er zijn verschillende betalingsopties voor VM's:

• Voor workloads die geen voorspelbare voltooiingstijd of resourceverbruik hebben, kunt u de optie betalen per gebruik overwegen.

• Overweeg om Azure-reserveringen te gebruiken als u een VIRTUELE machine gedurende een periode van één jaar of drie jaar kunt gebruiken. VM-reserveringen kunnen de kosten aanzienlijk verlagen. U betaalt mogelijk maar liefst 72 procent van de kosten van een service voor betalen per gebruik.

Gebruik spot-VM's van Azure om workloads uit te voeren die kunnen worden onderbroken en waarvoor geen voltooiing binnen een vooraf bepaald tijdsbestek of een SLA is vereist. Azure implementeert spot-VM's wanneer er beschikbare capaciteit is en verwijdert ze wanneer de capaciteit weer nodig is. De kosten die zijn gekoppeld aan spot-VM's, zijn lager dan voor andere VM's. Overweeg vm's te herkennen voor deze werkbelastingen:

• High Performance Computing-scenario's, batchverwerkingstaken of visuele renderingtoepassingen
• Testomgevingen, waaronder continue integratie en workloads voor continue levering
• Grootschalige stateless toepassingen

Met azure Reserved Virtual Machine Instances kunt u de totale eigendomskosten verlagen door de tarieven voor azure Reserved Virtual Machine Instances te combineren met een betalen per gebruik-abonnement, zodat u kosten voor voorspelbare en variabele workloads kunt beheren. Zie Azure Reserved Virtual Machine Instances voor meer informatie.

Load Balancer

In dit scenario wordt Load Balancer gebruikt om verkeer te distribueren naar VM's in het subnet van de toepassingslaag.

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels, plus de gegevens die via de load balancer worden verwerkt. Regels voor binnenkomende nat-adresomzetting (Network Address Translation) zijn gratis. Er worden geen uurkosten in rekening gebracht voor Standard Load Balancer wanneer er geen regels zijn geconfigureerd.

ExpressRoute

In deze architectuur is ExpressRoute de netwerkservice die wordt gebruikt voor het maken van privéverbindingen tussen een on-premises netwerk en virtuele Azure-netwerken.

Alle binnenkomende gegevensoverdracht is gratis. Alle uitgaande gegevensoverdracht wordt in rekening gebracht op basis van een vooraf bepaald tarief. Zie prijzen voor Azure ExpressRoute voor meer informatie.

Community's

Community's kunnen vragen beantwoorden en helpen om een succesvolle implementatie in te stellen. Houd rekening met deze resources:

• SAP-toepassingen uitvoeren op het Microsoft Platform-blog
• Ondersteuning voor De Azure-community
• SAP-community
• Stack Overflow voor SAP

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzender.

Hoofdauteur:

• Ben Trinh | Hoofdarchitect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Zie de volgende artikelen voor meer informatie en voorbeelden van SAP-workloads die gebruikmaken van een aantal van dezelfde technologieën als deze architectuur:

• Azure Virtual Machines plannen en implementeren voor SAP NetWeaver
• Azure gebruiken om SAP-workloadscenario's te hosten en uit te voeren

Verwante resources

• SAP-productieworkloads uitvoeren met behulp van een Oracle Database in Azure