SAP S/4HANA in Linux in Azure

Deze handleiding bevat een set bewezen procedures voor het uitvoeren van S/4HANA en Suite op HANA in een omgeving met hoge beschikbaarheid die ondersteuning biedt voor herstel na noodgevallen in Azure. De Fiori-informatie is alleen van toepassing op S/4HANA-toepassingen.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

In deze handleiding wordt een gemeenschappelijk productiesysteem beschreven. Deze architectuur wordt geïmplementeerd met VM-grootten (virtuele machines) die u kunt wijzigen om tegemoet te komen aan de behoeften van uw organisatie. U kunt deze configuratie beperken tot één virtuele machine om aan uw zakelijke behoeften te voldoen.

In deze handleiding is de netwerkindeling aanzienlijk vereenvoudigd om architectuurprincipes te demonstreren. Het is niet bedoeld om een volledig bedrijfsnetwerk te beschrijven.

De architectuur maakt gebruik van de volgende onderdelen. Sommige gedeelde services zijn optioneel.

Azure Virtual Network. De Virtual Network-service verbindt Azure-resources veilig met elkaar. In deze architectuur maakt een virtueel netwerk verbinding met een on-premises omgeving via een 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.

Peering van virtuele netwerken. Deze architectuur maakt gebruik van meerdere virtuele netwerken die aan elkaar zijn gekoppeld. Deze topologie biedt netwerksegmentatie en isolatie voor services die zijn geïmplementeerd in Azure. Peering verbindt netwerken transparant via het Backbone-netwerk van Microsoft en brengt geen prestatiestraf in rekening als deze binnen één regio wordt geïmplementeerd. Afzonderlijke subnetten worden gebruikt voor elke laagtoepassing (SAP NetWeaver), database en voor gedeelde services, zoals de jumpbox en Windows Server Active Directory.

VM's. Deze architectuur maakt gebruik van VM's waarop Linux wordt uitgevoerd voor de toepassingslaag en databaselaag, gegroepeerd op de volgende manier:

• Toepassingslaag. Deze architectuurlaag omvat de front-endservergroep Fiori, de SAP Web Dispatcher-pool, de groep toepassingsserver en het SAP Central Services-cluster. Voor hoge beschikbaarheid van Central Services in Azure die wordt uitgevoerd in Linux-VM's, is een maximaal beschikbare service voor netwerkbestandsshares vereist, zoals NFS-bestandsshares in Azure Files, Azure NetApp Files, geclusterde NFS-servers (Network File System) of SIOS Protection Suite voor Linux. Als u een maximaal beschikbare bestandsshare wilt instellen voor het Central Services-cluster op Red Hat Enterprise Linux (RHEL), kunt u GlusterFS configureren op Azure-VM's waarop RHEL wordt uitgevoerd. Op SUSE Linux Enterprise Server (SLES) 15 SP1 en latere versies of SLES voor SAP-toepassingen kunt u gedeelde Azure-schijven op een Pacemaker-cluster gebruiken om hoge beschikbaarheid te bereiken.

• SAP HANA. De databaselaag maakt gebruik van twee of meer Linux-VM's in een cluster om hoge beschikbaarheid te bereiken in een opschaalimplementatie. HANA-systeemreplicatie (HSR) wordt gebruikt voor het repliceren van inhoud tussen primaire en secundaire HANA-systemen. Linux-clustering wordt gebruikt om systeemfouten te detecteren en automatische failover te vergemakkelijken. Er moet een opslag- of cloudgebaseerd fencingmechanisme worden gebruikt om ervoor te zorgen dat het mislukte systeem wordt geïsoleerd of afgesloten om te voorkomen dat het cluster split-brain condition is. In uitschaalimplementaties van HANA kunt u hoge beschikbaarheid van databases bereiken met behulp van een van de volgende opties:

  • Configureer HANA stand-byknooppunten met behulp van Azure NetApp Files zonder het Linux-clusteringonderdeel.
  • Uitschalen zonder stand-byknooppunten met behulp van Azure Premium Storage. Gebruik Linux-clustering voor failover.

• Azure Bastion. Met deze service kunt u verbinding maken met een virtuele machine met behulp van uw browser en Azure Portal, of via de systeemeigen SSH- of RDP-client die al op uw lokale computer is geïnstalleerd. Als alleen RDP en SSH worden gebruikt voor beheer, is Azure Bastion een uitstekende oplossing. Als u andere beheerhulpprogramma's gebruikt, zoals SQL Server Management Studio of een SAP-front-end, 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, wordt u aangeraden Azure Standard Load Balancer te gebruiken. Standaard biedt Standard Load Balancer een beveiligingslaag. VM's die zich achter Standard Load Balancer bevinden, hebben geen uitgaande internetverbinding. Als u uitgaand internet op de VM's wilt inschakelen, moet u de Standard Load Balancer-configuratie bijwerken. U kunt ook Azure NAT Gateway gebruiken om uitgaande connectiviteit te krijgen. 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).

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

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

Deze twee onderdelen kunnen een load balancer delen om de oplossing te vereenvoudigen.

Standard Load Balancer biedt ook ondersteuning voor SAP-clusters met meerdere systeem-id's (multi-SID). Met andere woorden, meerdere SAP-systemen op SLES of RHEL kunnen een gemeenschappelijke infrastructuur voor hoge beschikbaarheid delen om de kosten te verlagen. U wordt aangeraden de kostenbesparingen te evalueren en te voorkomen dat er te veel systemen in één cluster worden geplaatst. 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). S/4HANA biedt webtoepassingsservices via Fiori. U kunt taken verdelen over deze Fiori-front-end, die bestaat uit web-apps, met behulp van Application Gateway.

Gateway. Een gateway verbindt afzonderlijke netwerken en breidt uw on-premises netwerk uit naar een virtueel Azure-netwerk. Azure ExpressRoute is de aanbevolen Azure-service voor het maken van privéverbindingen die niet via het openbare internet gaan, maar u kunt ook een site-naar-site-verbinding gebruiken. Om de latentie te verminderen, zijn ExpressRoute Global Reach en ExpressRoute FastPath connectiviteitsopties die verderop in dit artikel worden besproken.

Zone-redundante gateway. U kunt ExpressRoute- of VPN-gateways (Virtual Private Network) implementeren tussen zones om te voorkomen dat er zonefouten optreden. Deze architectuur maakt gebruik van zone-redundante virtuele netwerkgateways voor tolerantie in plaats van een zonegebonden implementatie die is gebaseerd op dezelfde beschikbaarheidszone.

Nabijheidsplaatsingsgroep. Deze logische groep plaatst een beperking op VM's die zijn geïmplementeerd in een beschikbaarheidsset of een virtuele-machineschaalset. Een nabijheidsplaatsingsgroep is gunstig voor co-locatie, waardoor VM's in hetzelfde datacenter worden geplaatst om de latentie van toepassingen te minimaliseren.

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

Toepassingsbeveiligingsgroepen. Gebruik toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen om nauwkeurig netwerkbeveiligingsbeleid te definiëren dat is gebaseerd op workloads en gecentreerd op toepassingen. U kunt VM's groeperen op naam en toepassingen beveiligen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

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 variëren 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 de plannings- en implementatiehandleiding voor Azure Virtual Machines voor gedetailleerde informatie over het uitvoeren van SAP NetWeaver op VM's. De handleiding is ook van toepassing op SAP S/4HANA-implementaties.

Zie SAP Note 1928533 voor meer informatie over SAP-ondersteuning voor typen Azure-VM's en voor metrische gegevens over doorvoer (SAPS). Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig. Zie SAP Certified and Supported SAP HANA Hardware Directory (SAP Certified and Supported SAP HANA Hardware Directory) voor een lijst met gecertificeerde Azure-VM's voor de HANA-database.

SAP-webdispatcher

Het onderdeel Web Dispatcher wordt gebruikt voor taakverdeling van SAP-verkeer tussen de SAP-toepassingsservers. Voor een hoge beschikbaarheid van SAP Web Dispatcher implementeert Azure Load Balancer een failovercluster of de parallelle Web Dispatcher-installatie. Voor internetgerichte communicatie is een zelfstandige oplossing in het perimeternetwerk de aanbevolen architectuur 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.

Fiori front-endserver (FES)

Deze architectuur voldoet aan veel vereisten en gaat ervan uit dat het ingesloten Fiori FES-model wordt gebruikt. Alle technologieonderdelen worden geïnstalleerd op het S/4-systeem zelf, wat betekent dat elk S/4-systeem een eigen Fiori launchpad heeft. De installatie van hoge beschikbaarheid voor dit implementatiemodel is dat van het S/4-systeem. Er zijn geen extra clustering of VM's vereist. Daarom wordt in het architectuurdiagram het FES-onderdeel niet weergegeven.

Zie SAP Fiori-implementatieopties en aanbevelingen voor systeemlandschap voor een beschrijving van de primaire implementatieopties (ingesloten of hub), afhankelijk van de scenario's. Voor het gemak en de prestaties zijn de softwarereleases tussen de onderdelen van de Fiori-technologie en de S/4-toepassingen nauw gekoppeld. Deze installatie maakt een hub-implementatie die slechts enkele, smalle gebruiksvoorbeelden past.

Als u de FES-hubimplementatie gebruikt, is de FES een invoegtoepassingsonderdeel voor de klassieke SAP NetWeaver ABAP-stack. Stel een hoge beschikbaarheid op dezelfde manier in als u een ABAP-toepassingsstack met drie lagen beveiligt met geclusterde of multi-hostmogelijkheden: gebruik een stand-byserverdatabaselaag, een geclusterde ASCS-laag met hoge beschikbaarheid NFS voor gedeelde opslag en ten minste twee toepassingsservers. Verkeer wordt verdeeld via een paar Web Dispatcher-exemplaren die kunnen worden geclusterd of parallel. Voor internetgerichte Fiori-apps raden we een FES-hubimplementatie aan in het perimeternetwerk. Gebruik Azure Web Application Firewall in Application Gateway als een essentieel onderdeel om bedreigingen te deflecteren. Gebruik Microsoft Entra ID met SAML voor gebruikersverificatie en eenmalige aanmelding voor SAP Fiori.

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

Groep toepassingsservers

Voor het beheren van aanmeldingsgroepen voor ABAP-toepassingsservers is het gebruikelijk om de SMLG-transactie te gebruiken om aanmeldingsgebruikers te verdelen, SM61 te gebruiken voor batchservergroepen, om RZ12 te gebruiken voor RFC-groepen (Remote Function Call), enzovoort. Deze transacties maken gebruik van de taakverdelingsfunctie die zich op de berichtenserver van Central Services bevindt om binnenkomende sessies of werkbelastingen te distribueren tussen de groep SAP-toepassingsservers die SAP GUIs- en RFC-verkeer verwerken.

SAP Central Services-cluster

U kunt Central Services implementeren op één VIRTUELE machine wanneer de Azure SLA (Service Level Agreement) voor beschikbaarheid van vm's met één exemplaar voldoet aan uw behoeften. De VM wordt echter een potentieel single point of failure (SPOF) voor de SAP-omgeving. Voor een maximaal beschikbare Central Services-implementatie gebruikt u NFS via Azure Files of de Azure NetApp Files-service en een Central Services-cluster.

Een andere optie is om gedeelde Azure-schijven te gebruiken om hoge beschikbaarheid te bereiken. Op SLES 15 SP1 en hoger of SLES voor SAP-toepassingen kunt u een Pacemaker-cluster instellen met behulp van gedeelde Azure-schijven voor Linux.

U kunt ook een NFS-bestandsshare gebruiken voor de gedeelde opslag van het Linux-cluster.

Bij een Azure-implementatie maken de toepassingsservers verbinding met de maximaal beschikbare Central Services via de namen van de virtuele hostnamen van de Central Services 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 (VIP's) van Central Services als ERS kunnen worden geconfigureerd voor één load balancer.

Ondersteuning voor Linux-clusters voor ascs-installatie met meerdere SID's in Azure is nu algemeen beschikbaar. Het delen van een beschikbaarheidscluster tussen meerdere SAP-systemen vereenvoudigt het SAP-landschap.

Netwerken

Deze architectuur maakt gebruik van een stertopologie, waarbij 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. U kunt de spokes gebruiken om workloads te isoleren. Verkeer stroomt tussen het on-premises datacenter en de hub via een gatewayverbinding.

Netwerkinterfacekaarten (NIC's)

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. Daarom is het gebruik van meerdere NIC's niet nodig voor prestatieoverwegingen. Als uw organisatie echter verkeer moet scheiden, kunt u meerdere NIC's per VM implementeren, elke NIC verbinden met een ander subnet en vervolgens netwerkbeveiligingsgroepen gebruiken om verschillende beleidsregels voor toegangsbeheer af te dwingen.

Azure NIC's ondersteunen meerdere IP-adressen. Deze ondersteuning is afgestemd op de praktijk die SAP aanbeveelt om virtuele hostnamen voor installaties te gebruiken, zoals wordt beschreven in SAP-opmerking 962955. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

Subnetten en netwerkbeveiligingsgroepen

Deze architectuur verdeelt de adresruimte van het virtuele netwerk 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-circuits bevat, kan ExpressRoute Global Reach u helpen bij het verminderen van netwerkhops en lagere latentie. Deze technologie is een BGP-routepeering (Border Gateway Protocol) die is ingesteld tussen twee of meer ExpressRoute-circuits om twee ExpressRoute-routeringsdomeinen te overbruggingen. Global Reach verlaagt de latentie wanneer netwerkverkeer meer dan één ExpressRoute-circuit doorkruist. Deze is momenteel alleen beschikbaar voor persoonlijke peering op ExpressRoute-circuits.

Er zijn momenteel 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 implementeert Microsoft Edge-uitwisselingen op het toegangspunt van het Azure-netwerk. FastPath vermindert netwerkhops voor de meeste gegevenspakketten. Hierdoor verlaagt FastPath de netwerklatentie, verbetert de toepassingsprestaties en is dit de standaardconfiguratie voor nieuwe ExpressRoute-verbindingen met Azure.

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.

Load balancers

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

Load Balancer is een netwerktransmissielaagservice (laag 4) waarmee verkeer wordt verdeeld met behulp van een hash van vijf tuples uit gegevensstromen. De hash is gebaseerd op bron-IP, bronpoort, doel-IP, doelpoort en protocoltype. Load Balancer wordt gebruikt in clusterconfiguraties om verkeer naar het primaire service-exemplaar of het gezonde knooppunt te leiden als er een fout optreedt. U wordt aangeraden Azure Standard Load Balancer te gebruiken voor alle SAP-scenario's. Het is belangrijk te weten dat Standard Load Balancer standaard veilig is en dat er geen VM's achter Standard Load Balancer een uitgaande internetverbinding hebben. Als u uitgaand internet in de VM's wilt inschakelen, moet u de standard load balancer-configuratie aanpassen.

Voor verkeer van SAP GUI-clients die via het DIAG-protocol of RFC verbinding maken met een SAP-server, wordt de belasting verdeeld via aanmeldingsgroepen voor SAP-toepassingsservers. Er is geen extra load balancer nodig.

Storage

Sommige klanten gebruiken standaardopslag voor hun toepassingsservers. Omdat standaard beheerde schijven niet worden ondersteund, zoals vermeld in SAP-notitie 1928533, raden we u aan om premium beheerde Azure-schijven of Azure NetApp Files in alle gevallen 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.

Omdat toepassingsservers geen zakelijke gegevens hosten, kunt u ook de kleinere P4- en P6 Premium-schijven gebruiken om de kosten te beheren. Als u wilt weten hoe het opslagtype van invloed is op de SLA voor vm-beschikbaarheid, raadpleegt u de SLA voor virtuele machines. Voor scenario's met hoge beschikbaarheid zijn azure-functies voor gedeelde schijven beschikbaar op Azure Premium SSD en Azure Ultra Disk Storage. Zie Beheerde Azure-schijven voor meer informatie.

U kunt gedeelde Azure-schijven gebruiken met Windows Server, SLES 15 SP 1 en hoger of SLES voor SAP. Wanneer u een gedeelde Azure-schijf in Linux-clusters gebruikt, fungeert de gedeelde Azure-schijf als een STONITH-blokapparaat (SBD). Het biedt een quorumstem in een clusternetwerkpartitioneringssituatie. Deze gedeelde schijf heeft geen bestandssysteem en biedt geen ondersteuning voor gelijktijdige schrijfbewerkingen van meerdere clusterlid-VM's.

Azure NetApp Files heeft ingebouwde functies voor het delen van bestanden voor NFS en SMB.

Voor scenario's met NFS-shares biedt Azure NetApp Files beschikbaarheid voor NFS-shares die kunnen worden gebruikt voor /hana/shared, /hana/dataen /hana/log volumes. Zie SLA voor Azure NetApp Files voor de beschikbaarheidsgarantie. Als u NFS-shares op basis van Azure NetApp Files gebruikt voor de /hana/data en /hana/log volumes, moet u het NFS v4.1-protocol gebruiken. Voor het /hana/shared volume wordt het NFS v3-protocol ondersteund.

Voor het back-upgegevensarchief raden we u aan om statische azure- en archieftoegangslagen te gebruiken. Deze opslaglagen zijn rendabele manieren om gegevens met een lange levensduur op te slaan die niet vaak worden geopend. U kunt ook overwegen om de Standard-laag van Azure NetApp Files te gebruiken als back-updoel of azure NetApp Files-back-upoptie. Voor een beheerde schijf is de aanbevolen back-upgegevenslaag de statische azure- of archieftoegangslaag.

Ultra Disk Storage en De ultraprestatielaag van Azure NetApp Files verminderen de schijflatentie aanzienlijk en profiteren van prestatiekritieke toepassingen en de SAP-databaseservers.

Azure Premium SSD v2 is ontworpen voor prestatiekritieke workloads zoals SAP. Zie Een Premium SSD v2 implementeren voor informatie over de voordelen van deze opslagoplossing en de huidige beperkingen.

Prestatieoverwegingen

SAP-toepassingsservers communiceren voortdurend met de databaseservers. Voor prestatiekritieke toepassingen die worden uitgevoerd op elk databaseplatform, inclusief SAP HANA, schakelt u Write Accelerator in voor het logboekvolume als u Premium SSD v1 gebruikt. Hierdoor kan de latentie van logboekschrijfbewerkingen worden verbeterd. Premium SSD v2 maakt geen gebruik van Write Accelerator. 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.

Zie SAP Note 1943937 - Hulpprogramma voor hardwareconfiguratiecontrole voor meer informatie over de prestatievereisten van SAP HANA. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

Voor een hoge IOPS- en schijfbandbreedtedoorvoer zijn de algemene procedures voor optimalisatie van opslagvolumeprestaties van toepassing op uw opslagindeling. Als u bijvoorbeeld meerdere schijven combineert om een gestreept schijfvolume te maken, kunt u de I/O-prestaties verbeteren. Door de leescache in te schakelen voor opslaginhoud die niet vaak wordt gewijzigd, kunt u de snelheid van het ophalen van gegevens verbeteren. Zie voor aanbevelingen over opslagconfiguraties voor verschillende VM-grootten wanneer u SAP HANA uitvoert, opslagconfiguraties voor virtuele machines van SAP HANA in Azure.

Azure Premium SSD v2 is ontworpen voor prestatiekritieke workloads zoals SAP. Zie Azure Managed Disk-typen voor meer informatie over de voordelen en beperkingen en optimale gebruiksscenario's.

Ultra Disk Storage is een nieuwe generatie opslag die voldoet aan intensieve IOPS en de overdrachtsbandbreedtevereisten van toepassingen zoals SAP HANA. U kunt de prestaties van ultraschijven dynamisch wijzigen en onafhankelijk metrische gegevens configureren, zoals IOPS en MB/s, zonder de VIRTUELE machine opnieuw op te starten. Wanneer Ultra Disk Storage beschikbaar is, raden we Ultra Disk Storage aan in plaats van Write Accelerator.

Voor sommige SAP-toepassingen is regelmatig communicatie met de database vereist. Netwerklatentie tussen de toepassings- en databaselagen, vanwege afstand, kan de prestaties van de toepassing nadelig beïnvloeden. Azure-nabijheidsplaatsingsgroepen stellen een plaatsingsbeperking in voor VM's die zijn geïmplementeerd in beschikbaarheidssets. Binnen de logische constructie van een groep zijn co-locatie en prestaties gunstig voor schaalbaarheid, beschikbaarheid en kosten. Nabijheidsplaatsingsgroepen kunnen de gebruikerservaring voor de meeste SAP-toepassingen aanzienlijk verbeteren.

De plaatsing van een virtueel netwerkapparaat (NVA) tussen de toepassing en de databaselagen van een SAP-toepassingsstack wordt niet ondersteund. De NVA vereist een aanzienlijke hoeveelheid tijd om gegevenspakketten te verwerken. Hierdoor worden de prestaties van toepassingen onaanvaardbaar vertraagd.

We raden u ook aan om prestaties te overwegen wanneer u resources implementeert met beschikbaarheidszones, waardoor de beschikbaarheid van de service kan worden verbeterd, zoals verderop in dit artikel wordt beschreven. Overweeg om een duidelijk netwerklatentieprofiel te maken tussen alle zones van een doelregio. Deze aanpak helpt u bij het bepalen van de plaatsing van resources voor minimale latentie tussen zones. Als u dit profiel wilt maken, voert u een test uit door kleine VM's in elke zone te implementeren. Aanbevolen hulpprogramma's voor de test zijn PsPing en Iperf. Verwijder deze VM's na het testen. Zie de testtest beschikbaarheidszone voor een testhulpprogramma voor netwerklatentie in een openbaar domein dat u in plaats daarvan kunt gebruiken.

Azure NetApp Files heeft unieke prestatiefuncties die realtime afstemming mogelijk maken die voldoet aan de behoeften van de meest veeleisende SAP-omgevingen. Zie Sizing for HANA database on Azure NetApp Files(Sizing for HANA database on Azure NetApp Files) voor prestatieoverwegingen die u in gedachten moet houden wanneer u Azure NetApp Files gebruikt.

Schaalbaarheidsoverwegingen

Op de SAP-toepassingslaag biedt Azure een breed scala aan VM-grootten voor omhoog en uitschalen. Zie 'SAP-toepassingen in Azure: ondersteunde producten en typen Azure-VM's' in SAP Note 1928533 voor een inclusieve lijst. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig. Er worden voortdurend meer VM-typen gecertificeerd, zodat u omhoog of omlaag kunt schalen in dezelfde cloudimplementatie.

Op de databaselaag voert deze architectuur SAP HANA S/4-toepassingen uit op Virtuele Azure-machines die in één instantie maximaal 24 terabytes (TB) kunnen schalen. Als uw workload de maximale VM-grootte overschrijdt, kunt u een configuratie met meerdere knooppunten gebruiken voor maximaal 96 TB's (4 x 24) voor OLTP-toepassingen (Online Transaction Processing). Zie Certified and Supported SAP HANA Hardware Directory (Gecertificeerde en ondersteunde SAP HANA-hardwaremap) voor meer informatie.

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 verhogen, implementeert u VM-resources met virtuele-machineschaalsets met flexibele indeling, beschikbaarheidszones of beschikbaarheidssets.

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.

Implementatiemethoden

In 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 de 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).

Web Dispatcher in de toepassingsserverlaag

U kunt hoge beschikbaarheid bereiken met behulp van redundante Web Dispatcher-exemplaren. Zie SAP Web Dispatcher in de SAP-documentatie voor meer informatie. Het beschikbaarheidsniveau is afhankelijk van de grootte van de toepassing achter Web Dispatcher. In kleine implementaties met weinig schaalbaarheidsproblemen kunt u Web Dispatcher samen zoeken met de ASCS-VM's. Op deze manier bespaart u op onafhankelijk besturingssysteemonderhoud en krijgt u tegelijkertijd hoge beschikbaarheid.

Central Services in de toepassingsserverlaag

Gebruik voor hoge beschikbaarheid van Central Services op Virtuele Linux-machines van Azure de juiste extensie voor hoge beschikbaarheid voor de geselecteerde Linux-distributie. Het is gebruikelijk om de gedeelde bestandssystemen op maximaal beschikbare NFS-opslag te plaatsen met behulp van SUSE DRBD of Red Hat GlusterFS. Als u een maximaal beschikbare NFS wilt bieden en de noodzaak van een NFS-cluster wilt elimineren, kunt u in plaats daarvan andere rendabele of robuuste oplossingen gebruiken, zoals NFS via Azure Files of Azure NetApp Files . Als kanttekening kunnen Azure NetApp Files-shares de SAP HANA-gegevens en logboekbestanden hosten. Met deze installatie kan het HANA-implementatiemodel worden uitgeschaald met stand-byknooppunten , terwijl NFS via Azure Files geschikt is voor maximaal beschikbare niet-databasebestandsdeling.

NFS via Azure Files ondersteunt nu de maximaal beschikbare bestandsshares voor zowel SLES als RHEL. Deze oplossing werkt goed voor maximaal beschikbare bestandsshares zoals die van /sapmnt, /saptrans in SAP-installaties.

Azure NetApp Files ondersteunt hoge beschikbaarheid van ASCS op SLES. Zie SIOS Protection Suite voor Linux voor gedetailleerde informatie over ASCS op hoge beschikbaarheid van RHEL.

De verbeterde Azure Fence Agent is beschikbaar voor zowel SUSE als Red Hat en biedt aanzienlijk snellere servicefailover dan de vorige versie van de agent.

Een andere optie is om gedeelde Azure-schijven te gebruiken om hoge beschikbaarheid te bereiken. Op SLES 15 SP 1 en hoger of SLES voor SAP kunt u een Pacemaker-cluster instellen met behulp van gedeelde Azure-schijven om hoge beschikbaarheid te bereiken.

In Azure Standard Load Balancer kunt u de poort voor hoge beschikbaarheid inschakelen en voorkomen dat u taakverdelingsregels voor veel SAP-poorten hoeft te configureren. Als u de functie Direct Server Return (DSR) inschakelt wanneer u een load balancer instelt, kunnen serverreacties op clientvragen de load balancer omzeilen. Deze functie wordt ook wel zwevend IP-adres genoemd. De load balancer kan on-premises of in Azure zijn. Met deze directe verbinding blijft de load balancer het knelpunt in het pad van gegevensoverdracht. Voor de ASCS- en HANA DB-clusters raden we u aan DSR in te schakelen. Als vm's in de back-endpool openbare uitgaande connectiviteit vereisen, is er meer configuratie vereist.

Voor verkeer van SAP GUI-clients die via het DIAG-protocol of RFC verbinding maken met een SAP-server, wordt de belasting verdeeld met behulp van aanmeldingsgroepen voor SAP-toepassingsservers. Er is geen extra load balancer nodig.

Toepassingsservers in de toepassingsserverlaag

U kunt hoge beschikbaarheid bereiken door verkeer in een groep toepassingsservers te verdelen.

ASCS-laag

Net als bij de toepassingsserverlaag is de veelgebruikte oplossing voor hoge beschikbaarheid van HANA voor Linux Pacemaker.

Databaselaag

De architectuur in deze handleiding toont een maximaal beschikbaar SAP HANA-databasesysteem dat bestaat uit twee Virtuele Azure-machines. De systeemeigen systeemreplicatiefunctie van de databaselaag biedt handmatige of automatische failover tussen gerepliceerde knooppunten:

• Voor handmatige failover implementeert u meer dan één HANA-exemplaar en gebruikt u HSR.
• Voor automatische failover gebruikt u zowel HSR als hoge beschikbaarheidsextensie (HAE) voor uw Linux-distributie. Linux HAE biedt de clusterservices aan de HANA-resources, het detecteren van foutgebeurtenissen en het organiseren van de failover van foutieve services naar het gezonde knooppunt.

VM's implementeren in beschikbaarheidszones

Beschikbaarheidszones kunnen de beschikbaarheid van de service verbeteren. Zones verwijzen naar fysiek gescheiden locaties binnen een specifieke Azure-regio. Ze verbeteren de beschikbaarheid van workloads en beschermen toepassingsservices en VM's tegen datacentrumstoringen. VM's in één zone worden behandeld alsof ze zich in één update- of foutdomein bevinden. Wanneer zonegebonden implementatie is geselecteerd, worden VM's in dezelfde zone gedistribueerd naar fout- en upgradedomeinen op basis van best effort.

In Azure-regio's die deze functie ondersteunen, zijn er ten minste drie zones beschikbaar. De maximale afstand tussen datacenters in deze zones is echter niet gegarandeerd. Als u een SAP-systeem met meerdere lagen tussen zones wilt implementeren, moet u de netwerklatentie binnen een zone en in de doelzones kennen en 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/passieve 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 database worden verdeeld over twee zones. Als zone 1 mislukt, worden Central Services en databaseservices uitgevoerd in zone 2. De passieve toepassingsservers in zone 2 worden geactiveerd. Omdat alle onderdelen van dit SAP-systeem zich 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. In elke zone zijn twee toepassingsservers in elke set inactief of worden afgesloten. Als gevolg hiervan zijn er actieve toepassingsservers in beide zones in normale bewerkingen.

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

Als zone 1 offline gaat, voert de ascs- en databaseservices een failover uit naar zone 2. De slapende toepassingsservers kunnen online worden gebracht om volledige capaciteit te bieden voor de verwerking van toepassingen.

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.

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.

VM's

Deze architectuur maakt gebruik van VM's waarop Linux wordt uitgevoerd voor de beheer-, SAP-toepassings- en databaselagen.

Er zijn verschillende betalingsopties voor VM's in het algemeen:

• Voor workloads zonder voorspelbare voltooiingstijd of resourceverbruik 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 is vereist binnen een vooraf bepaald tijdsbestek of SLA. 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 over deze aanbieding.

Zie Prijzen voor virtuele Linux-machines voor een overzicht van prijzen.

Load Balancer

In dit scenario worden Azure Load Balancers 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. 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.

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 de 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.

Backup

U kunt op veel manieren een back-up maken van SAP HANA-gegevens. Nadat u naar Azure bent gemigreerd, kunt u doorgaan met het gebruik van bestaande back-upoplossingen die u hebt. Azure biedt twee systeemeigen benaderingen voor back-ups. U kunt een back-up maken van SAP HANA op VM's of Azure Backup gebruiken op bestandsniveau. Azure Backup is BackInt gecertificeerd door SAP. Zie veelgestelde vragen en ondersteuningsmatrix voor Azure Backup voor het maken van back-ups van SAP HANA-databases op Virtuele Azure-machines voor meer informatie.

Identiteitsbeheer

Gebruik een gecentraliseerd identiteitsbeheersysteem om de toegang tot resources op alle niveaus te beheren:

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

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

• Ondersteuning voor toegang binnen de apps zelf via de services die SAP biedt of OAuth 2.0 en Microsoft Entra ID gebruiken.

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 beschikbaarheid en prestaties van SAP-services.

Beveiligingsoverwegingen

SAP heeft een eigen UME (Users Management Engine) voor het beheren van op rollen gebaseerde toegang en autorisatie binnen de SAP-toepassing en -databases. Zie SAP HANA-beveiliging: een overzicht voor meer informatie.

Als u de netwerkbeveiliging wilt verbeteren, kunt u overwegen een perimeternetwerk te gebruiken dat gebruikmaakt van een NVA om een firewall te maken vóór het subnet voor Web Dispatcher en de front-endservergroepen Fiori. De kosten van gegevensoverdracht zijn een reden om actieve front-endservers te plaatsen waarop Fiori-apps worden uitgevoerd in hetzelfde virtuele netwerk als de S/4-systemen. Het alternatief is om ze in het perimeternetwerk te plaatsen en ze te verbinden met S/4 via peering van een virtueel netwerk.

Voor infrastructuurbeveiliging worden gegevens versleuteld tijdens overdracht en at-rest. De sectie Beveiligingsoverwegingen van SAP NetWeaver op Azure Virtual Machines- Planning en Implementatiehandleiding bevat informatie over netwerkbeveiliging die van toepassing is op S/4HANA. Deze handleiding geeft ook de netwerkpoorten op die moeten worden geopend op de firewalls om toepassingscommunicatie toe te staan.

Als u Linux-VM-schijven wilt versleutelen, hebt u verschillende opties, zoals beschreven in het overzicht van schijfversleuteling. Voor SAP HANA-versleuteling van data-at-rest wordt u aangeraden de systeemeigen SAP HANA-versleutelingstechnologie te gebruiken. Zie Azure-schijfversleuteling voor Linux-VM's voor ondersteuning van Azure-schijfversleuteling voor specifieke Linux-distributies, versies en installatiekopieën.

Voor SAP HANA-versleuteling van data-at-rest wordt u aangeraden de systeemeigen SAP HANA-versleutelingstechnologie te gebruiken.

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 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:

• SAP S/4HANA of BW/4HANA implementeren in Azure
• 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