Delen via

SAP S/4HANA in Linux op Azure

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

Architectuur

Architectuurdiagram met SAP S/4HANA voor virtuele Linux-machines in een Azure-beschikbaarheidsset.

Een Visio-bestand van deze architectuur downloaden.

Opmerking

Als u deze architectuur wilt implementeren, moet u ervoor zorgen dat u over de benodigde licenties beschikt voor SAP-producten en andere niet-Microsoft-technologieën.

In deze handleiding wordt een typisch productiesysteem beschreven. Deze architectuur maakt gebruik van verschillende VM-grootten (virtuele machines). Als u aan de behoeften van uw organisatie wilt voldoen, kunt u de grootten aanpassen of deze configuratie beperken tot één virtuele machine.

In deze handleiding is de netwerkindeling vereenvoudigd om architectuurprincipes te demonstreren. Het vertegenwoordigt geen volledig bedrijfsnetwerk.

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

Azure Virtual Network. De Virtual Network-service verbindt Azure-resources met elkaar met verbeterde beveiliging. 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 hub-spoke topologie. De spoke is het virtuele netwerk dat wordt gebruikt voor de SAP-toepassingen en de databaselagen.

Virtuele netwerkpeering. 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 met zich mee als deze binnen één regio wordt geïmplementeerd. Afzonderlijke subnetten worden gebruikt voor elke laag, inclusief de toepassingslaag (SAP NetWeaver) en de databaselaag, en voor gedeelde onderdelen, zoals de jumpbox en Windows Server Active Directory.

VM's. Met deze architectuur worden VM's die Linux uitvoeren in groepen voor de toepassingslaag en de databaselaag op de volgende manieren ingedeeld:

  • 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 worden uitgevoerd in Linux-VM's, is een maximaal beschikbare service voor netwerkbestandsshares vereist, zoals NFS-bestandsshares (Network File System) in Azure Files, Azure NetApp Files, geclusterde NFS-servers 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 in een Pacemaker-cluster inzetten als een fencings-apparaat om hoge beschikbaarheid (HA) 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. U moet een op opslag of cloud gebaseerd fencingmechanisme gebruiken om ervoor te zorgen dat het mislukte systeem wordt geïsoleerd of afgesloten om een gepartitioneerd cluster te voorkomen. In uitschaalimplementaties van HANA kunt u database-HA 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 via uw browser en Azure Portal of met behulp van de systeemeigen Secure Shell-client (SSH) of RDP-client (Remote Desktop Protocol) die op uw lokale computer is geïnstalleerd. Als alleen RDP en SSH worden gebruikt voor beheer, kunt u Overwegen Om Azure Bastion te gebruiken. 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 om de beschikbaarheid te vergroten, gebruikt u Azure Standard Load Balancer. Standard Load Balancer biedt standaard 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. Gebruik de ingebouwde SAP-webverzender of een andere commercieel beschikbare load balancer voor SAP-webtoepassingen. Baseer uw selectie op:

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

Standard Load Balancer ondersteunt meerdere virtuele IP-adressen van de front-end. Deze ondersteuning is ideaal voor cluster-implementaties die de volgende onderdelen bevatten:

  • Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)
  • Replicatieserver in de wachtrij plaatsen

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

Standard Load Balancer ondersteunt ook SAP-clusters met meerdere systeem-id's (multi-SID). Met deze functie kunnen meerdere SAP-systemen op SLES of RHEL een gemeenschappelijke HA-infrastructuur 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. Azure ondersteunt maximaal 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, ook wel OSI-laag (Open Systems Interconnect) genoemd, met behulp van Transmission Control Protocol en User Datagram Protocol. 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 extra kenmerken van een HTTP-aanvraag, zoals het uniforme resourcepad of de hostheaders. Dit type routering wordt toepassingslaag of OSI-laag 7 genoemd, taakverdeling. 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. Als u openbare IP-adressen gebruikt, moet u ervoor zorgen dat deze de standaard-IP-adres-SKU gebruiken. Vermijd de basis-IP-adres-SKU omdat deze is gepland voor afschaffing op 30 september 2025.

Toegangspoort. 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. U kunt ook een site-naar-site-verbinding gebruiken. Gebruik ExpressRoute Global Reach of ExpressRoute FastPath om de latentie te verminderen.

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 legt een restrictie op virtuele machines die zijn geïmplementeerd in een beschikbaarheidsset of een schaalset voor virtuele machines. Een nabijheidsplaatsingsgroep helpt bij het afdwingen van colocatie door ervoor te zorgen dat VM's in hetzelfde datacenter worden geïmplementeerd. Deze configuratie vermindert de fysieke afstand tussen resources om de latentie van toepassingen te minimaliseren.

Opmerking

Zie Configuratieopties voor het minimaliseren van netwerklatentie met SAP-toepassingen voor een bijgewerkte configuratiestrategie. In dit artikel worden de mogelijke afwegingen in implementatieflexibiliteit beschreven wanneer u een SAP-systeem optimaliseert voor netwerklatentie.

Netwerkbeveiligingsgroepen (NSG's). Als u inkomend, uitgaand en intrasubnetverkeer in een virtueel netwerk wilt beperken, kunt u NSG's 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. U wordt aangeraden beheerde Azure-schijven te gebruiken.

Aanbevelingen

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

Vms

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 meer informatie over het uitvoeren van SAP NetWeaver op VM's. De handleiding is ook van toepassing op SAP S/4HANA-implementaties.

Zie SAP-opmerking 1928533 voor meer informatie over SAP-ondersteuning voor typen Azure-VM's en voor metrische gegevens over doorvoer. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig. Zie sap-gecertificeerde en ondersteunde SAP HANA-hardwaremap 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 de beveiligingsvereisten. Embedded Web Dispatcher op ASCS is een geavanceerd configuratie. Als u deze configuratie gebruikt, kunt u overwegen de juiste grootte te bepalen vanwege de extra werkbelasting op ASCS.

Fiori front-endserver (FES)

Deze architectuur voldoet aan meerdere vereisten en gaat ervan uit dat u het ingesloten Fiori FES-model gebruikt. Alle technologieonderdelen worden rechtstreeks op het S/4-systeem geïnstalleerd, dus elk S/4-systeem heeft een eigen Fiori launchpad. Het S/4-systeem beheert de ha-configuratie voor dit implementatiemodel. Met deze methode hoeft u geen extra clustering of VM's meer te maken. Daarom bevat het architectuurdiagram niet het FES-onderdeel.

Zie SAP Fiori-implementatieopties en aanbevelingen voor systeemlandschap voor meer informatie over implementatieopties. 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 geschikt voor slechts enkele specifieke gebruiksvoorbeelden.

Als u de FES-hubimplementatie gebruikt, is de FES een invoegtoepassingsonderdeel voor de klassieke SAP NetWeaver ABAP-stack. Stel HA in op dezelfde manier als waarmee u een drie-lagen ABAP-toepassingsstack beveiligt die geclusterd is of meerdere hosts ondersteunt. Gebruik een stand-byserverdatabaselaag, een geclusterde ASCS-laag met HA 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 Security Assertion Markup Language voor gebruikersverificatie en eenmalige aanmelding voor SAP Fiori.

Architectuurdiagram met de gegevensstroom tussen internet en twee virtuele netwerken, één met SAP Fiori en één met SAP S/4HANA.

Een Visio-bestand van deze architectuur downloaden.

Zie Inkomende en uitgaande internetverbinding voor SAP in Azure voor meer informatie.

Groep toepassingsservers

Gebruik de volgende transactiecodes om aanmeldingsgroepen voor ABAP-toepassingsservers te beheren:

  • SMLG: Taakverdeling voor aanmeldingsgebruikers.
  • SM61: Batch-servergroepen beheren.
  • RZ12: RFC-groepen (Remote Function Call) beheren.

Deze transacties zijn afhankelijk van de taakverdelingsfunctie op de berichtenserver van Central Services om binnenkomende sessies en workloads te distribueren over de groep SAP-toepassingsservers die SAP GUI- en RFC-verkeer beheren.

SAP Central Services-cluster

De SAP Central Services bevatten één exemplaar van de berichtserver en de reeksvolgorde-replicatieservice. In tegenstelling tot de werkprocessen van toepassingsservers, vormen deze onderdelen enkele punten van falen in de SAP-toepassingsstack. U kunt Central Services implementeren op één virtuele machine wanneer de Azure service-level agreement (SLA) voor de beschikbaarheid van vm's met een enkele instantie aan uw vereisten voldoet. Als voor uw SLA een hogere beschikbaarheid is vereist, moet u deze services implementeren op een HA-cluster. Zie Central Services in de toepassingsserverlaag voor meer informatie.

Netwerken

Deze architectuur maakt gebruik van een hub-spoke-topologie waarbij het virtuele hubnetwerk fungeert als een centraal punt van connectiviteit met een on-premises netwerk. De "spokes" zijn virtuele netwerken die verbinding maken met de hub. U kunt de spaken gebruiken om workloads te isoleren. Verkeer stroomt tussen het on-premises datacenter en de hub via een gatewayverbinding.

Netwerkinterfacekaarten

Traditionele on-premises SAP-implementaties implementeren meerdere netwerkinterfacekaarten (NIC's) per computer om beheerverkeer van bedrijfsverkeer te scheiden. In Azure is het virtuele netwerk een softwaregedefinieerde netwerk waarmee al het verkeer via één netwerkinfrastructuur wordt gerouteerd. Als gevolg hiervan hebt u niet meerdere NIC's nodig om prestaties te verbeteren. Als uw organisatie verkeer moet scheiden, kunt u meerdere NIC's voor elke VM implementeren, elke NIC verbinden met een ander subnet en vervolgens NSG's 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 te gebruiken voor installaties in SAP-notitie 962955.

Subnetten en NSGs

Deze architectuur verdeelt de adresruimte van het virtuele netwerk in subnetten. U kunt elk subnet koppelen aan een NSG waarmee het toegangsbeleid voor het subnet wordt gedefinieerd. Plaats toepassingsservers op een afzonderlijk subnet. Deze aanpak maakt het eenvoudiger om toepassingsservers te beveiligen door het subnetbeveiligingsbeleid te beheren in plaats van de afzonderlijke servers.

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

ExpressRoute Global Reach

Als uw netwerkomgeving twee of meer ExpressRoute-circuits bevat, kunt u met ExpressRoute Global Reach netwerkhops verminderen en latentie verminderen. Deze technologie is een Border Gateway Protocol-routepeering die is ingesteld tussen twee of meer ExpressRoute-circuits om twee ExpressRoute-routeringsdomeinen te overbruggen. Global Reach vermindert de latentie wanneer netwerkverkeer meer dan één ExpressRoute-circuit doorkruist. Deze is alleen beschikbaar voor persoonlijke peering op ExpressRoute-circuits.

Global Reach biedt geen ondersteuning voor wijzigingen in lijsten met netwerktoegangsbeheer of andere kenmerken. Alle routes die een ExpressRoute-circuit leert, of deze nu van on-premises of Azure komen, worden via circuitpeering geadverteerd naar andere ExpressRoute-circuits. Het is aan te raden dat u netwerkverkeer lokaal filtert om de toegang tot middelen te beperken.

FastPath

FastPath implementeert Microsoft Edge-uitwisselingen op het toegangspunt van het Azure-netwerk. FastPath vermindert netwerkhops voor de meeste gegevenspakketten. Hierdoor vermindert 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 een virtueel netwerk dat verbonden is met ExpressRoute gekoppeld is met andere virtuele netwerken, wordt het verkeer van uw on-premises netwerk naar de andere virtuele spoke-netwerken gerouteerd via de virtuele netwerk-gateway. U kunt dit probleem oplossen door alle virtuele netwerken rechtstreeks met het ExpressRoute-circuit te verbinden.

Verdelers

SAP Web Dispatcher verwerkt taakverdeling van HTTP- en HTTPS-verkeer naar een groep SAP-toepassingsservers. Deze software load balancer biedt toepassingslaagservices, ook wel laag 7 genoemd in het ISO-netwerkmodel, 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 een bron-IP-adres, bronpoort, doel-IP-adres, 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 Standard Load Balancer te gebruiken voor alle SAP-scenario's. Standard Load Balancer is standaard beveiligd en er zijn geen VM's achter Standard Load Balancer met een uitgaande internetverbinding. 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 verbinding maken met een SAP-server via het DIAG-protocol (Dynamic Information and Action Gateway) of RFC, verdeelt de Central Services-berichtserver de belasting via aanmeldingsgroepen voor SAP-toepassingsservers. Er is geen extra load balancer nodig.

Opslag

Sommige klanten gebruiken standaardopslag voor hun toepassingsservers. Omdat standaard beheerde schijven niet worden ondersteund, raden we u aan om Azure Premium SSD of Azure NetApp Files in alle scenario's te gebruiken. Een recente update van SAP-opmerking 2015553 sluit het gebruik van Azure Standard HDD-opslag en Azure 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. Voor SAP-toepassingen raden we u ten zeerste aan Azure SSD v1, SSD v2 of Ultra Disks te gebruiken. Zie SLA's voor onlineservices om te begrijpen hoe het opslagtype van invloed is op de SLA voor vm-beschikbaarheid. Voor ha-scenario's zijn gedeelde azure-schijffuncties beschikbaar op Azure Premium SSD en Azure Ultra Disk Storage. Zie Azure Managed Disks en Azure Managed Disk Types voor meer informatie.

U kunt gedeelde Azure-schijven gebruiken met Windows Server, SLES 15 SP1 en hoger of SLES voor SAP. Wanneer u een gedeelde Azure-schijf in Linux-clusters gebruikt, fungeert de gedeelde Azure-schijf als een afscherming van een mislukt knooppuntblokapparaat. Het biedt een quorum-stem in een situatie van clusternetwerkpartitionering. 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 HA voor NFS-shares die kunnen worden gebruikt voor /hana/shared, /hana/data en /hana/log volumes. Voor de beschikbaarheidsgarantie, zie SLA's voor online services. 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 de back-upgegevensopslag raden we u aan om Azure koele en archieftoegangslagen te gebruiken. Deze opslaglagen zijn rendabele manieren om gegevens met een lange levensduur op te slaan die niet vaak worden geopend. Overweeg ook het gebruik van de Azure NetApp Files Standard-laag als back-updoel of de back-upoptie van Azure NetApp Files. Voor een beheerde schijf is de aanbevolen back-upgegevenslaag de Azure koele of archieftoegangsniveau.

Ultra Disk Storage en Azure NetApp Files Ultra-laag verminderen de schijflatentie aanzienlijk en verbeteren de prestaties van kritieke toepassingen en SAP-databaseservers.

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

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. Deze methode kan de latentie van logboekschrijfbewerkingen verbeteren. 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.

U moet de Linux TCP/IP-stack en buffers in de netwerkinterface optimaliseren om consistente prestaties te bereiken. Volg de aanbevolen instellingen van Microsoft. U past bijvoorbeeld items aan, zoals:

  • Kernelparameters voor het optimaliseren van geheugenbuffers voor lezen en schrijven
  • Knelpuntbandbreedte en retourdoorgiftetijd (BBR) congestieregeling
  • TCP-parameters aanpassen om betere consistentie en doorvoer te krijgen
  • NIC-ringbuffers voor TX/RX

Zie SAP Note 1943937 voor meer informatie over de prestatievereisten van SAP HANA.

Volg de algemene procedures voor optimalisatie van de prestaties van opslagvolumes om hoge invoer-/uitvoerbewerkingen per seconde (IOPS) en doorvoer van schijfbandbreedte te bereiken. Als u bijvoorbeeld meerdere schijven combineert om een gestreept schijfvolume te maken, kunt u de prestaties van uw invoer/uitvoer (I/O) verbeteren. Als u de leescache inschakelt voor opslaginhoud die niet vaak wordt gewijzigd, kan het ophalen van gegevens ook worden versneld. Zie opslagconfiguraties voor virtuele AZURE-machines in SAP HANA voor meer informatie.

Premium SSD v2 is ontworpen voor prestatiekritieke workloads zoals SAP. Zie Azure Managed Disk Types voor meer informatie over de voordelen, 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 MBps, zonder de VM opnieuw op te starten. U wordt aangeraden Ultra Disk Storage te gebruiken in plaats van Write Accelerator, indien mogelijk.

Voor sommige SAP-toepassingen is regelmatig communicatie met de database vereist. Vanwege afstand kan netwerklatentie tussen de toepassings- en databaselagen de prestaties van de toepassing negatief 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 colocatie 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. 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 beschikbaarheidszone latentietest voor een testhulpprogramma voor netwerklatentie voor openbaar gebruik dat u kunt gebruiken als alternatief.

Azure NetApp Files heeft unieke prestatiefuncties waarmee realtime afstemming mogelijk is om te voldoen aan de behoeften van de meest veeleisende SAP-omgevingen. Voor prestatieoverwegingen bij het gebruik van Azure NetApp Files, raadpleegt u Dimensionering van HANA-database op Azure NetApp Files.

Overwegingen voor schaalbaarheid

Op de SAP-toepassingslaag biedt Azure een breed scala aan VM-grootten voor omhoog schalen en uitschalen. Zie SAP-toepassingen in Azure voor een inclusieve lijst: Ondersteunde producten en Typen Azure-VM's in SAP-notitie 1928533. Meer VM-typen worden voortdurend gecertificeerd, zodat u omhoog of omlaag kunt schalen in dezelfde cloudimplementatie.

Op de databaselaag voert deze architectuur SAP S/4HANA-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 (vier exemplaren van 24 TB) voor online transactieverwerkingstoepassingen. Zie gecertificeerde en ondersteunde SAP HANA-hardwaremap voor meer informatie.

Overwegingen voor beschikbaarheid

Resourceredundantie is het algemene thema in maximaal beschikbare infrastructuuroplossingen. Zie SLA's voor onlineservices voor beschikbaarheids-SLA's voor virtuele machines met één instantie voor verschillende opslagtypen. Als u de beschikbaarheid van services in Azure wilt vergroten, implementeert u VM-resources met behulp van Azure Virtual Machine Scale Sets, dat flexibele indeling, beschikbaarheidszones en beschikbaarheidssets biedt.

Het implementatiemodel voor regionale beschikbaarheidssets van Azure is een ondersteunde optie. We raden u echter aan de virtuele-machineschaalsets te gebruiken met het model voor beschikbaarheidszones voor nieuwe SAP-implementaties om de beschikbaarheid te verbeteren en de implementatieflexibiliteit te vergroten.

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 HA-ontwerp.

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 Virtuele-machineschaalsets met flexibele indeling (één foutdomeinconfiguratie), beschikbaarheidszones en beschikbaarheidssets, om de beschikbaarheid van de resources te verbeteren.

Naarmate de implementaties van klanten in Azure in de loop der jaren zijn toegenomen, heeft Microsoft verbeterde Azure VM-implementatiemodellen om virtuele-machineschaalsets op te nemen om de elasticiteit en tolerantie van de cloud te waarborgen. Gezien de beschikbare implementatieopties raden we u ten zeerste aan om zonegebonden implementatie van Azure flexibele schaalsets te gebruiken voor alle nieuwe implementaties. Zie de ha-architectuur en scenario's voor SAP NetWeaver voor meer informatie over implementatie tussen zones, binnen één zone en in regio's zonder zones.

Web Dispatcher in de toepassingsserverlaag

U kunt hoge beschikbaarheid (HA) bereiken door gebruik te maken van redundante Web Dispatcher-exemplaren. Zie SAP Web Dispatcher voor meer informatie. Het beschikbaarheidsniveau is afhankelijk van de grootte van de toepassing achter Web Dispatcher. In kleine implementaties met weinig schaalbaarheidsproblemen kunt u de Web Dispatcher samenvoegen met de ASCS-VM's. Deze aanpak helpt u om onafhankelijk onderhoud van besturingssystemen te besparen en tegelijkertijd hoge beschikbaarheid te verkrijgen.

Central Services in de toepassingsserverlaag

Gebruik voor hoge beschikbaarheid van Central Services op Virtuele Linux-machines van Azure de juiste HA-extensie voor de geselecteerde Linux-distributie. Het is gebruikelijk om de gedeelde bestandssystemen op maximaal beschikbare NFS-opslag te plaatsen met behulp van het SUSE Distributed Replicated Block Device of Red Hat GlusterFS. Als u een maximaal beschikbare NFS wilt bieden en de noodzaak van een NFS-cluster wilt elimineren, kunt u andere rendabele of robuuste oplossingen gebruiken, zoals NFS via Azure Files of Azure NetApp Files. Azure NetApp Files-shares kunnen 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 /sapmnt en /saptrans in SAP-installaties.

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

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

Een andere afschermingsoptie is het gebruik van gedeelde Azure-schijven voor het fencing-apparaat. Op SLES 15 SP1 of SLES voor SAP 15 SP1 en hoger kunt u een Pacemaker-cluster instellen met behulp van gedeelde Azure-schijven. Deze optie is eenvoudig en vereist geen open netwerkpoort zoals de Azure Fence-agent.

Een recent ondersteunde en eenvoudigere Pacemaker-configuratie op SLES 15 en hoger is HA SAP NetWeaver met eenvoudige koppeling en NFS op SLES voor VM's van SAP-toepassingen. In deze configuratie worden de SAP-bestandsshares uit het clusterbeheer gehaald, waardoor het eenvoudiger is om te werken. Gebruik deze HA-configuratie voor alle nieuwe implementaties.

Om de kosten van een groot SAP-landschap verder te beheren, ondersteunt het Linux-cluster ASCS-installatie met meerdere SID's in Azure. Het delen van een beschikbaarheidscluster tussen meerdere SAP-systemen vereenvoudigt het SAP-landschap en vermindert de operationele kosten.

In Standard Load Balancer kunt u de ha-poort inschakelen en voorkomen dat u taakverdelingsregels voor veel SAP-poorten moet 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 wordt de load balancer niet het knelpunt in het pad van gegevensoverdracht. Voor de ASCS- en HANA-databaseclusters wordt u aangeraden DSR in te schakelen. Als virtuele machines in de back-endpool openbare uitgaande connectiviteit vereisen, is verdere 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 binnen een pool van applicatieservers te verdelen.

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 Linux HA-extensie (HAE) voor uw Linux-distributie. Linux HAE biedt clusterservices voor HANA-resources, detecteert foutgebeurtenissen en organiseert de failover van defecte services naar een gezond 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 minimaal drie zones beschikbaar. De maximale afstand tussen datacenters in deze zones is niet gegarandeerd. Als u een SAP-systeem met meerdere lagen tussen zones wilt implementeren, moet u de netwerklatentie binnen een zone en in verschillende 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 of VM-typen in de gekozen zones

Opmerking

We raden geen beschikbaarheidszones aan voor herstel na noodgevallen. Een DR-site moet ten minste 100 mijl van de primaire site zijn om rekening te houden met natuurrampen. De exacte afstand tussen datacenters kan niet worden gegarandeerd.

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 dat nodig is.

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. Als 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 actief. 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 ascs en databaseservices vanwege de fysieke afstand tussen de 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 DR-overzicht en infrastructuurrichtlijnen voor SAP-workloads en DR-richtlijnen voor SAP-toepassingen voor DR-strategieën en implementatie-informatie.

Opmerking

Als er sprake is van een regionale ramp die een massafailovergebeurtenis veroorzaakt voor veel Azure-klanten in één regio, wordt de resourcecapaciteit van de doelregio niet gegarandeerd. Net als bij alle Azure-services blijft Site Recovery functies en mogelijkheden toevoegen. Zie de ondersteuningsmatrix voor de meest recente informatie over Azure-naar-Azure-replicatie.

Gebruik een capaciteitsreservering op aanvraag om ervoor te zorgen dat de beschikbare resourcecapaciteit voor een DR-regio beschikbaar is. Met Azure kunt u korting op uw reserve-exemplaar combineren met uw capaciteitsreservering om de kosten te verlagen.

Kostenoverwegingen

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

Zie Azure Well-Architected Framework-kostenoptimalisatie voor meer informatie.

Vms

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:

  • Voor workloads die geen voorspelbare tijd van voltooiing of hulpbronnenverbruik hebben, kunt u de afreken-optie per gebruik overwegen.

  • Overweeg om Azure-reserveringen te gebruiken als u een VM gedurende een periode van één jaar of drie jaar kunt gebruiken. VM-reserveringen kunnen de kosten aanzienlijk verlagen. U kunt maximaal 72% besparen in vergelijking met opties voor betalen na 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 bepaalde periode of SLA. Azure implementeert spot-VM's wanneer er beschikbare capaciteit is en verwijdert ze wanneer de capaciteit weer nodig is. De kosten voor spot-VM's zijn lager dan 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 kunt beheren voor voorspelbare en variabele workloads. Zie Azure Reserved Virtual Machine Instances voor meer informatie.

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

Ladingsverdelaar

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 netwerkadresomzetting 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 ExpressRoute voor meer informatie.

Overwegingen voor beheer en bewerkingen

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

Azure Center voor SAP-oplossingen

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. De begeleide implementatie-ervaring van Azure Center voor SAP-oplossingen maakt 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.

Reservekopie

U kunt op veel manieren een back-up maken van SAP HANA-gegevens. Nadat u naar Azure bent gemigreerd, kunt u alle bestaande back-upoplossingen blijven gebruiken 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.

Opmerking

Alleen HANA-implementaties als een enkele container of als scale-up ondersteunen Azure Storage-snapshots.

Identiteitsbeheer

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

Controle

Gebruik Azure Monitor om de beschikbaarheid en prestaties van toepassingen en services in Azure te maximaliseren. Azure Monitor is 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 engine voor gebruikersbeheer voor het beheren van op rollen gebaseerde toegang en autorisatie binnen de SAP-toepassing en -databases. Zie sap HANA-beveiligingsoverzicht 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. Als u de kosten voor gegevensoverdracht wilt minimaliseren, implementeert u actieve front-endservers die toepassingen hosten binnen hetzelfde virtuele netwerk als de S/4-systemen. U kunt deze front-endservers ook configureren in het perimeternetwerk, dat gebruikmaakt van peering van virtuele netwerken om verbinding te maken met de S/4-systemen.

Voor infrastructuurbeveiliging worden gegevens versleuteld tijdens overdracht en at-rest. Zie Beveiliging voor uw SAP-landschap voor informatie over netwerkbeveiliging die van toepassing is op S/4HANA.

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

Opmerking

Gebruik geen HANA-versleuteling voor data-at-rest en Azure Disk Encryption op hetzelfde opslagvolume. Voor HANA gebruikt u HANA-gegevensversleuteling via Versleuteling aan de serverzijde van Azure Disk Storage. Het gebruik van door de klant beheerde sleutels kan van invloed zijn op I/O-doorvoer.

Community's

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

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

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: