SAP NetWeaver uitvoeren in Windows op Azure

In deze handleiding worden bewezen procedures beschreven voor het uitvoeren van SAP NetWeaver in een Windows-omgeving in Azure. De architectuur biedt hoge beschikbaarheid. De database maakt gebruik van AnyDB. Dit is de SAP-term voor elk ondersteund databasebeheersysteem (DBMS) anders dan SAP HANA.

Architectuur

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

Een Visio-bestand van deze architectuur downloaden.

Deze architectuur implementeert een productiesysteem met specifieke VM-grootten (virtuele machines) die u kunt aanpassen aan de behoeften van uw organisatie. U kunt de implementatie zelfs beperken tot één virtuele machine. De netwerkindeling is vereenvoudigd om de belangrijkste architectuurprincipes te demonstreren in plaats van een volledige bedrijfsnetwerkconfiguratie.

Werkproces

De volgende werkstroom komt overeen met het vorige diagram:

1. SAP-databaselaag: De database vormt de kern van elke SAP-installatie en slaat toepassingsgegevens en -programma's op. In dit geval wordt de database gerepliceerd om hoge beschikbaarheid te bieden.

2. Externe SAP-invoerbestanden: Externe niet-SAP-systemen bieden gegevens die door het SAP-systeem worden verwerkt. Deze gegevens worden gerepliceerd voor hoge beschikbaarheid.

3. SAP-toepassingsserverlaag: Deze laag bevat de centrale toepassingsonderdelen en verwerkt toepassingsgegevens. Azure Site Recovery, een Windows Server-failovercluster en meerdere toepassingsservers beveiligen deze laag om lokale en externe redundantie te garanderen.

4. Azure-netwerkgateway in een hubnetwerk: Deze gateway is het toegangspunt van het on-premises netwerk naar de Azure-cloud. Het hubnetwerk bevat beveiligingsmaatregelen.

5. On-premises netwerkverbinding met Azure: Deze verbinding breidt uw lokale on-premises netwerk uit naar Azure via Azure ExpressRoute of een VPN via internet.

Components

• Azure Virtual Machines is een rekenservice die on-demand schaalbare rekenresources biedt waarop het Windows- of Linux-besturingssysteem wordt uitgevoerd. In deze architectuur ondersteunen VM's zowel de toepassingslaag als de databaselaag.

• Databases zijn systemen waarmee gestructureerde gegevens voor toepassingen worden opgeslagen en beheerd. In deze architectuur voert de databaselaag een SAP-gecertificeerde database uit, zoals SQL Server, Oracle of IBM Db2.

• SAP NetWeaver is een toepassingsplatform met SAP Central Services en toepassingsservers voor het uitvoeren van SAP-bedrijfstoepassingen. In deze architectuur gebruikt de toepassingslaag Windows-VM's om deze onderdelen uit te voeren. Voor hoge beschikbaarheid worden de VM's met SAP Central Services ingesteld in een Windows Server-failovercluster. WSFC ondersteunt Azure-bestandssharing of Azure-schijven voor gedeeld gebruik.

  Het cluster bevat twee exemplaren:

  • ABAP SAP Central Services (ASCS)
  • Enqueue-replicatieserver (ERS)

  De Standard-SKU ondersteunt ook SAP-clusters met meerdere systemen (multi-SID). 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. Azure ondersteunt maximaal vijf SID's per cluster.

  Er zijn ook partnerproducten zoals SIOS DataKeeper Cluster Edition van SIOS Technology Corp. Deze software repliceert inhoud van onafhankelijke schijven die zijn gekoppeld aan de ASCS-clusterknooppunten en presenteert vervolgens de schijven als een gedeeld clustervolume aan de clustersoftware.

• Azure Storage is een cloudopslagservice die permanente, duurzame opslag biedt voor VM-schijven. In deze architectuur biedt Storage gegevenspersistentie voor VM's in de vorm van virtuele harde schijven. Azure Managed Disks wordt aangeraden.

• Azure Virtual Network is een netwerkservice die Azure-resources met elkaar verbindt met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met een on-premises netwerk via een Azure ExpressRoute-gateway in de hub van een hub-spoke topologie. De spoke fungeert als het virtuele netwerk voor de SAP-toepassingen en -databaselagen. Het virtuele hubnetwerk biedt gedeelde services zoals Azure Bastion en back-upservices.

• Virtuele netwerk-peering is een netwerkfunctie die transparante connectiviteit biedt tussen virtuele netwerken via het Microsoft-backbone-netwerk. Het voorkomt prestatiestraffen wanneer u deze in één regio implementeert. In deze architectuur verbindt peering meerdere virtuele netwerken in een hub-and-spoke-topologie. Deze topologie biedt netwerksegmentatie en isolatie voor services die zijn geïmplementeerd in Azure. Het virtuele netwerk is onderverdeeld in afzonderlijke subnetten voor de toepassingslaag (SAP NetWeaver), de databaselaag en gedeelde services zoals Azure Bastion en een niet-Microsoft-back-upoplossing.

• Een netwerkgateway is een hybride connectiviteitsservice die afzonderlijke netwerken verbindt en uw on-premises netwerk uitbreidt naar virtuele Azure-netwerken. In deze architectuur raden we ExpressRoute aan om privéverbindingen te maken die niet via het openbare internet gaan, maar u kunt ook een site-naar-site-VPN-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 beschreven.

• Een bastionhost of jumpbox is een veilige toegangsoplossing die beheerderstoegang biedt tot VM's in een virtueel netwerk. In deze architectuur maken beheerders verbinding met VM's via een bastionhost die is geïmplementeerd als onderdeel van gedeelde services. Als Secure Shell (SSH) en Remote Desktop Protocol (RDP) uw enige serverbeheerprotocollen zijn, gebruikt u een Azure Bastion-host . Als u andere beheerhulpprogramma's zoals SQL Server Management Studio of SAP Frontend gebruikt, gebruikt u een traditionele, zelf geïmplementeerde jumpbox.

• Netwerkbeveiligingsgroepen (NSG's) zijn netwerkbeveiligingsfuncties die netwerkverkeer naar en van Azure-resources in een virtueel netwerk filteren met behulp van beveiligingsregels. Maak in deze architectuur NSG's om binnenkomend, uitgaand en intrasubnetverkeer te beperken.

  Toepassingsbeveiligingsgroepen (ASG's) bieden gedetailleerd netwerkbeveiligingsbeleid op basis van workloads dat is gericht op toepassingen. In deze architectuur kunt u ASG's gebruiken om VM's te groeperen op naam en toepassingen te beveiligen door verkeer van vertrouwde netwerksegmenten te filteren.

• Privé-DNS van Azure is een DNS-service (Domain Name System) die naamomzetting biedt en domeinnamen in een virtueel netwerk beheert en oplost. In deze architectuur verwerkt privé-DNS van Azure naamomzetting zonder dat u een aangepaste DNS-oplossing hoeft in te stellen.

• Load balancers zijn netwerkservices die binnenkomend netwerkverkeer verdelen over meerdere servers om hoge beschikbaarheid en betrouwbaarheid te garanderen. In deze architectuur raden we Azure Standard Load Balancer aan om verkeer te distribueren naar VM's in het subnet van de SAP-toepassingslaag. Een standard load balancer biedt standaard beveiliging en blokkeert uitgaande internetverbinding vanaf VM's. Voor uitgaande internettoegang op de VM's werkt u de standaardconfiguratie van de load balancer bij. Voor hoge beschikbaarheid van SAP-webtoepassingen gebruikt u de ingebouwde SAP Web Dispatcher of een andere commercieel beschikbare load balancer.

  Baseer uw selectie op de volgende details:

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

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

  Standard Load Balancer ondersteunt meerdere virtuele IP-adressen van de front-end.

• Azure Application Gateway is een load balancer voor webverkeer die op de toepassingslaag (OSI-laag 7) werkt en routeringsbeslissingen kan nemen op basis van HTTP-aanvraagkenmerken, zoals URI-pad (Uniform Resource Identifier) of hostheaders. In deze architectuur kunt u Application Gateway gebruiken om verkeer naar uw webtoepassingen te beheren met geavanceerdere routering dan traditionele transportlaag load balancers (OSI-laag-4) die alleen worden gerouteerd op basis van bron-IP-adres, bronpoort, doel-IP-adres en doelpoort.

Aanbevelingen

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

Netwerken

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

Netwerkinterfacekaarten

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

In Azure verzendt het virtuele netwerk al het verkeer via dezelfde netwerkinfrastructuur. U hoeft dus niet meerdere NIC's te gebruiken voor prestatiedoeleinden. Maar als uw organisatie verkeer moet scheiden, kunt u meerdere NIC's per VM implementeren, elke NIC verbinden met een ander subnet en NSG's gebruiken om verschillende beleidsregels voor toegangsbeheer af te dwingen.

Azure-NIC's ondersteunen meerdere IP-adressen, die overeenkomen met de sap-aanbevolen procedure voor het gebruik van virtuele hostnamen voor installaties. Zie SAP-notitie 962955 voor een volledig overzicht. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.

Subnetten en NSGs

Met deze architectuur wordt de adresruimte van het virtuele netwerk onderverdeeld 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 vereenvoudigt de beveiliging door 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-verbindingen bevat, gebruikt u ExpressRoute Global Reach om netwerkhops en latentie te verminderen. Deze technologie biedt een BGP-routepeering (Border Gateway Protocol) 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.

Global Reach heeft geen netwerktoegangsbeheerlijsten (ACL's) of andere kenmerken die u kunt wijzigen. Als gevolg hiervan worden alle routes die zijn geleerd door een ExpressRoute-circuit van on-premises en Azure geadverteerd via de circuitpeering naar het andere ExpressRoute-circuit. Het wordt aanbevolen om netwerkverkeer lokaal te filteren om de toegang tot IT-bronnen te beperken.

ExpressRoute FastPath

ExpressRoute FastPath verbetert de prestaties van het gegevenspad tussen uw on-premises netwerk en uw virtuele netwerk. Peering van virtuele netwerken via FastPath wordt ondersteund. Wanneer u FastPath activeert, wordt netwerkverkeer rechtstreeks naar VM's in het virtuele netwerk verzonden en wordt de gateway omzeild.

Alle nieuwe ExpressRoute-verbindingen met Azure gebruiken FastPath als de standaardconfiguratie. Neem voor bestaande ExpressRoute-circuits contact op met Azure support om FastPath te activeren.

ExpressRoute-providercircuits bieden geen ondersteuning voor peering van virtuele netwerken via FastPath.

Wanneer u extra virtuele netwerken koppelt aan het virtuele netwerk dat verbinding maakt met ExpressRoute, wordt verkeer van uw on-premises netwerk naar die peered spoke virtuele netwerken gerouteerd via de virtuele netwerkgateway in plaats van via FastPath. Om deze beperking te voorkomen, verbindt u elk virtueel netwerk rechtstreeks met het ExpressRoute-circuit.

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 OSI-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 uit gegevensstromen. De hash is gebaseerd op bron-IP-adres, bronpoort, doel-IP-adres, doelpoort en protocoltype. In SAP-clusterimplementaties in Azure stuurt Load Balancer verkeer naar het primaire service-exemplaar of naar een gezond knooppunt wanneer er een fout optreedt.

U wordt aangeraden een interne load balancer te gebruiken voor alle SAP-scenario's. Als virtuele machines in de back-endpool openbare uitgaande connectiviteit vereisen of als u deze gebruikt in een Azure-zone-implementatie, hebt u extra configuraties nodig voor een interne load balancer. Het is standaard beveiligd en blokkeert uitgaande connectiviteit, tenzij u deze expliciet toestaat.

Voor verkeer van SAP GUI-clients die verbinding maken met een SAP-server via het DIAG-protocol (Dynamic Information and Action Gateway) of RFC (Remote Function Call), verdeelt de SAP Central Services-message server de belasting via aanmeldingsgroepen van SAP-toepassingsservers. Voor dit type installatie hebt u geen andere load balancer nodig.

Storage

Sommige organisaties gebruiken standaardopslag voor hun toepassingsservers. SAP biedt geen ondersteuning voor standaard beheerde schijven. Zie SAP-notitie 1928533 voor meer informatie. Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig. U wordt aangeraden in alle gevallen Azure Premium SSD-opslag te gebruiken. Een recente update van SAP-opmerking 2015553 bevat specifieke use cases die Azure Standard HDD-opslag en Azure Standard SSD-opslag uitsluiten.

Toepassingsservers hosten geen zakelijke gegevens. U kunt dus kleinere P4- en P6 Premium-schijven gebruiken om de kosten te minimaliseren. Premium-schijven bieden de SLA (Service Level Agreement) voor VM's met enkelvoudige instantie als u een centrale SAP-stack-installatie hebt.

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

Cloud Witness maakt ook gebruik van opslag om quorum te onderhouden via een apparaat in een externe Azure-regio, gescheiden van de primaire regio waarin het cluster zich bevindt.

Voor de back-upgegevensopslag raden we Azure cool- en archieftoegangsniveaus aan. Deze opslaglagen bieden een rendabele manier om gegevens met een lange levensduur op te slaan voor onregelmatige toegang.

Premium SSD v2 ondersteunt prestatiekritieke workloads, zoals OLTP-systemen (Online Transaction Processing), die consistent een latentie van submilliseconden nodig hebben in combinatie met hoge invoer/uitvoer per seconde (IOPS) en doorvoer.

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

Gebruik Azure NetApp Files voor een hoogwaardige gedeelde gegevensopslag met hoge beschikbaarheid. Azure NetApp Files is handig voor Oracle-databaselagen en voor het hosten van toepassingsgegevens.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.

Reliability

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Ontwerp controlelijst voor betrouwbaarheid voor meer informatie.

Maximaal beschikbare infrastructuuroplossingen zijn afhankelijk van resourceredundantie. Zie voor beschikbaarheid SLA's voor VM's met één instantie voor verschillende opslagtypen SLA voor VM's. Als u de beschikbaarheid van services in Azure wilt verhogen, implementeert u VM-resources met behulp van Azure Virtual Machine Scale Sets met flexibele indeling (FD=1), beschikbaarheidszones of beschikbaarheidssets.

U kunt SAP-workloads regionaal of zonegebonden implementeren in Azure, afhankelijk van de beschikbaarheids- en tolerantievereisten van de SAP-toepassingen. Zie architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver voor meer informatie over de beschikbare implementatieopties en hun toepasbaarheid in verschillende Azure-regio's, waaronder zones, binnen één zone of in een regio zonder zones.

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

SAP Web Dispatcher in de toepassingsserverlaag

Het SAP Web Dispatcher-onderdeel fungeert 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 installatie van SAP Web Dispatcher.

Voor internetgerichte communicatie raden we een zelfstandige oplossing aan in het perimeternetwerk (ook wel DMZ, gedemilitariseerde zone en gescreend subnet genoemd) om te voldoen aan beveiligingsproblemen.

Ingesloten SAP Web Dispatcher op ASCS is een alternatieve optie. Als u deze optie gebruikt, overweeg dan het ASCS-exemplaar op de juiste manier te dimensioneren vanwege de extra werkbelasting.

SAP Central Services in de toepassingsserverlaag

Een Windows Server-failovercluster implementeert hoge beschikbaarheid voor SAP Central Services. Wanneer de clusteropslag voor het failovercluster wordt geïmplementeerd in Azure, kunt u deze instellen als een geclusterde gedeelde schijf of als een geclusterde bestandsshare.

• U wordt aangeraden Azure Files te gebruiken als volledig beheerde, cloudeigen SMB-shares (Server Message Block) of Network File System (NFS). U kunt ook Azure NetApp Files gebruiken, dat krachtige NFS- en SMB-shares van enterprise-klasse biedt.

• Als u clusters wilt instellen met behulp van gedeelde schijven in Azure, raden we u aan om gedeelde Azure-schijven te gebruiken om een Windows Server-failovercluster in te stellen voor SAP Central Services. Zie Azure-infrastructuur voorbereiden voor een ASCS-cluster met behulp van gedeelde Azure-schijven voor een implementatievoorbeeld.

Als u een interne load balancer gebruikt, kunt u de poort voor hoge beschikbaarheid activeren. Deze poort voorkomt dat u taakverdelingsregels voor meerdere SAP-poorten hoeft te definiëren. Wanneer u Azure Load Balancers instelt, activeert u Direct Server Return (DSR), ook wel Zwevend IP-adres genoemd. DSR biedt een manier voor serverreacties om de load balancer te omzeilen. Met deze directe verbinding voorkomt men dat de load balancer een knelpunt wordt in het pad van gegevensoverdracht. U wordt aangeraden DSR te activeren voor ascs- en databaseclusters.

Toepassingsservices in de toepassingsserverlaag

Taakverdeling voor verkeer binnen een groep toepassingsservers om hoge beschikbaarheid te bereiken voor de SAP-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 met behulp van transactie-SMLG.

Databaselaag

In deze architectuur wordt de brondatabase uitgevoerd op AnyDB, die verwijst naar alle DOOR SAP ondersteunde 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 DBMS-implementatie voor virtuele machines voor SAP NetWeaver voor meer informatie over het implementeren van specifieke databasesystemen.

VM's die zijn geïmplementeerd in beschikbaarheidszones

Een beschikbaarheidszone bestaat uit een of meer datacenters. Dit ontwerp verbetert de beschikbaarheid van workloads en beveiligt toepassingsservices en VM's 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 de doelzones kennen. U moet ook weten wat de gevoeligheid van uw geïmplementeerde toepassingen is voor netwerklatentie.

Houd rekening met de volgende factoren wanneer u resources implementeert in beschikbaarheidszones:

• 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 wordt geïmplementeerd in zone 2, maar wordt afgesloten. Deze servers worden alleen geactiveerd wanneer ze nodig zijn.

De clusters met twee knooppunten voor SAP Central Services en de databaseservices worden in twee zones geïmplementeerd. Als zone 1 mislukt, worden SAP Central Services en de databaseservices uitgevoerd in zone 2. De passieve toepassingsservers in zone 2 worden geactiveerd. Alle onderdelen van dit SAP-systeem bevinden zich nu in dezelfde zone, waardoor de netwerklatentie wordt verminderd.

Voorbeeld van actieve/actieve implementatie

In een actieve/actieve implementatie worden twee sets toepassingsservers geïmplementeerd in twee zones. Binnen elke zone zijn twee toepassingsservers in elke set servers inactief omdat ze worden afgesloten. Als gevolg hiervan draaien in beide zones actieve toepassingsservers tijdens normale bedrijfsvoering.

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

Als zone 1 offline gaat, voert SAP Central Services en de 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

In dit verband betekent herstel na noodgevallen (DR) dat een hele regio niet meer beschikbaar is, voornamelijk door natuurrampen zoals brand of overstroming. Elke laag in de SAP-toepassingsstack maakt gebruik van een andere benadering om DR-beveiliging te bieden. Zie voor meer informatie over noodherstelstrategieën en implementatie het DR-overzicht en de infrastructuurrichtlijnen voor SAP-workloads en de DR-richtlijnen voor SAP-toepassingen.

Backup

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

• Voor SAP op SQL Server kunt u Azure Backup gebruiken om een back-up te maken van SQL Server-databases die worden uitgevoerd op VM's. Als de databasebestanden zijn opgeslagen in Azure Blob Storage, kunt u back-ups van momentopnamen van bestanden gebruiken voor databasebestanden in Azure.

• Voor SAP met Oracle in Windows raadpleegt u Back-up en herstel voor Azure-VM's oracle-database-implementatie voor SAP-workloads.

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

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Ontwerpcontrolelijst voor beveiliging voor meer informatie.

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 meer informatie over richtlijnen voor toepassingsbeveiliging.

Als u de netwerkbeveiliging wilt verbeteren, kunt u overwegen een perimeternetwerk toe te passen dat gebruikmaakt van een virtueel netwerkapparaat (NVA) als een firewall voor het SAP Web Dispatcher-subnet.

U kunt een NVA implementeren om verkeer tussen virtuele netwerken te filteren, maar plaats deze niet tussen de SAP-toepassing en de database. Controleer de routeringsregels die zijn gedefinieerd op het subnet en vermijd het omleiden van verkeer naar een enkele instantie NVA. Routing via een NVA met één enkele instantie kan leiden tot onderhoudsdowntime en netwerk- of geclusterde knooppuntstoringen.

Voor infrastructuurbeveiliging versleutelt Azure gegevens in transit en at rest. Zie Beveiliging voor uw SAP-landschap voor meer informatie over netwerkbeveiliging. Dit artikel bevat ook de netwerkpoorten die u moet openen op de firewalls om toepassingscommunicatie te ondersteunen.

Versleuteling

Voor SAP-workloads raadt Microsoft de volgende benaderingen aan:

• Databaseeigen versleuteling, bijvoorbeeld SAP HANA-gegevens, logboek- en back-upversleuteling, om SAP-databaseinhoud te beveiligen

• Versleuteling op host, eventueel gecombineerd met Azure Storage-serviceversleuteling en door de klant beheerde sleutels, voor beveiliging op VM-niveau

Voor data-at-rest-versleuteling versleutelt SQL Server transparent data encryption (TDE) SQL Server- en Azure SQL Database-gegevensbestanden. Zie SQL Server 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 implementeren. Deze oplossing biedt continue detectie en analyse van bedreigingen voor SAP-systemen die zijn geïmplementeerd in Azure met behulp van een gegevensconnector zonder agent. Zie Het implementatieoverzicht voor meer informatie.

Beveiligingsupdates en patches beheren om uw gegevensassets te beschermen. Overweeg het gebruik van een holistische automatiseringsbenadering voor deze taak.

Identiteitsbeheer

Als u de toegang tot resources op alle niveaus wilt beheren, gebruikt u een gecentraliseerd identiteitsbeheersysteem zoals Microsoft Entra ID en Active Directory Domain Services (AD DS):

• Geef toegang tot Azure resources met behulp van Azure op rollen gebaseerd toegangsbeheer (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 SAP-toepassingen met behulp van door SAP geleverde services of OAuth 2.0 met Microsoft Entra-id.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

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

VMs

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 fungeren ook als jumpboxen voor beheer.

VM's hebben verschillende betalingsopties:

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

• Overweeg om Azure VM-reserveringen te gebruiken als u een termijn van één of drie jaar kunt doorvoeren. VM-reserveringen kunnen de kosten aanzienlijk verlagen.

Gebruik spot-VM's van Azure voor workloads die kunnen worden onderbroken en waarvoor geen voltooiing binnen een vooraf bepaald tijdsbestek of een SLA is vereist. Azure implementeert spot-VM's wanneer de capaciteit beschikbaar is en verwijdert ze wanneer de capaciteit weer nodig is. Spot-VM's kosten minder dan andere VM's. Overweeg spot-VM's in deze architectuur te gebruiken om de kosten voor de volgende onderdelen te verlagen:

• Toepassingsservers in productieomgevingen die geen serviceniveaudoelstelling (SLO) hebben

• Toepassingsservers in niet-productieomgevingen, waaronder ondersteunende rekenkracht zoals CI/CD-agents (continue integratie en continue levering)

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

Als voor uw databaselaag meer geheugen en minder CPU's nodig zijn, gebruikt u een van de beperkte vm-grootten voor virtuele CPU (vCPU) om de licentiekosten per vCPU-software te verlagen.

Lastverdeler

In dit scenario distribueert Load Balancer verkeer naar VM's in het subnet van de toepassingslaag.

Azure brengt alleen kosten in rekening voor het aantal gedefinieerde taakverdelings- en uitgaande regels en de gegevens die via de load balancer worden verzonden. Regels voor binnenkomende nat-adresomzetting (Network Address Translation) zijn gratis. Standard Load Balancer heeft geen kosten per uur als u geen regels maakt.

ExpressRoute

In deze architectuur gebruikt u ExpressRoute om privéverbindingen te maken tussen een on-premises netwerk en virtuele Azure-netwerken.

Alle binnenkomende gegevensoverdracht is gratis. Azure rekent voor alle uitgaande gegevensoverdracht op basis van een vooraf bepaald tarief. Zie prijzen voor ExpressRoute voor meer informatie.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Voor meer informatie, zie Controlelijst voor ontwerpevaluatie voor Operational Excellence.

Azure Center voor SAP-oplossingen

Met Azure Center voor SAP-oplossingen kunt u SAP-systemen maken en uitvoeren als een uniforme workload in Azure. De begeleide implementatie configureert de benodigde reken-, opslag- en netwerkonderdelen die u nodig hebt om uw SAP-systeem te draaien. U kunt deze ook gebruiken om de installatie van SAP-software te 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 voor prestaties of naleving, kunt u overwegen uw VM's te implementeren op toegewezen hosts.

Toezicht

Gebruik Azure Monitor om de beschikbaarheid en prestaties van toepassingen en services op Azure te maximaliseren. Azure Monitor verzamelt, analyseert en handelt op telemetrie vanuit uw cloud- en on-premises omgevingen. Het laat zien hoe toepassingen presteren en identificeert proactief problemen die van invloed zijn op deze toepassingen en de resources waarvan ze afhankelijk zijn.

Zie Azure Monitor voor SAP-oplossingen voor meer informatie over SAP-specifieke bewakingsmogelijkheden. Gebruik deze richtlijnen voor het beheren van de beschikbaarheid en prestaties van SAP-services die worden uitgevoerd op databases zoals SAP HANA.

Gemeenschappen

Community's kunnen vragen beantwoorden en u helpen bij het instellen van een geslaagde implementatie:

• SAP-toepassingen uitvoeren op het Microsoft-platformblog
• SAP-community

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

SAP-toepassingsservers communiceren continu met de databaseservers. Voor prestatiekritieke toepassingen die worden uitgevoerd op databaseplatforms, activeert u Write Accelerator voor het logboekvolume als u Premium SSD v1 gebruikt. Write Accelerator verbetert de latentie van logboek-schrijfbewerkingen en 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-exemplaren 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 bij elkaar plaatsen om een gestreept schijfvolume te maken om de prestaties van invoer/uitvoer (I/O) te verbeteren. Als u de snelheid van het ophalen van gegevens wilt verbeteren, activeert u de leescache voor opslaginhoud die zelden wordt gewijzigd.

Premium SSD v2 biedt meer controle over prestatie-instellingen dan Premium SSD's. U kunt een Premium SSD v2-schijf instellen op elke ondersteunde grootte en gedetailleerde aanpassingen aan de prestaties aanbrengen zonder uitvaltijd.

Ultra Disk Storage ondersteunt I/O-intensieve toepassingen. We raden Ultra Disk Storage aan boven Write Accelerator premium-opslag, indien mogelijk. U kunt prestatiegegevens zoals IOPS en MBps afzonderlijk verhogen of verlagen zonder dat u opnieuw hoeft op te starten.

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

De plaatsing van een 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.

Proximiteitsplaatsingsgroepen

SAP-toepassingsservers vereisen meestal frequente communicatie met de database. De fysieke nabijheid van de toepassingsserverlaag 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 zijn gunstig voor colocatie en prestaties ten opzichte van schaalbaarheid, beschikbaarheid of kosten. Ze kunnen de gebruikerservaring voor de meeste SAP-toepassingen verbeteren. Zie Scripts op GitHub voor meer informatie over scripts die de latentie helpen meten.

Beschikbaarheidszones

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

Beheerders hebben een duidelijk netwerklatentieprofiel nodig tussen alle zones van een doelregio voordat ze de plaatsing van resources kunnen bepalen met minimale latentie tussen zones. 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.

Overwegingen voor schaalbaarheid

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

U kunt SAP-toepassingsservers en de SAP 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.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzender heeft dit artikel geschreven.

Hoofdauteur:

• Ben Trinh | Hoofdarchitect

Andere bijdrager:

• Steffen Mueller | Senior Architect

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-werkbelastingen die gebruikmaken van technologieën in deze architectuur:

• Planning en implementatie van virtuele machines voor SAP NetWeaver
• Gebruik Azure voor het hosten en uitvoeren van SAP-workloadscenario's

Gerelateerde resource

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