SAP netweave uitvoeren in Windows op Azure

Backup
Bastion
ExpressRoute
Load Balancer
Monitor
SAP HANA on Azure Large Instances
Storage
Virtual Machines
Virtual Network

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

In het eerste diagram ziet u SAP NetWeaver in een Windows-omgeving in een scenario met beschikbaarheidssets. De architectuur gebruikt Azure NetApp Files voor de gedeelde bestandslaag en een nabijheidsplaatsingsgroep voor betere prestaties:

Diagram met een referentiearchitectuur voor SAP NetWeaver in Windows. De database is AnyDB op Azure-VM's met beschikbaarheidssets.

Download een Visio-bestand met deze architectuur.

In het tweede diagram ziet u SAP NetWeaver in een Windows-omgeving. Beschikbaarheidszones worden gebruikt voor verbeterde tolerantie:

Diagram met een referentiearchitectuur voor SAP NetWeaver in Windows. De database is AnyDB op Azure-VM's met Beschikbaarheidszones.

Download een Visio-bestand met deze architectuur.

Notitie

Als u deze referentiearchitectuur wilt implementeren, hebt u de juiste licenties voor SAP-producten en andere niet-Microsoft-technologieën nodig.

Architectuur

Deze referentiearchitectuur beschrijft een productiesysteem. Het wordt geïmplementeerd met specifieke VM-grootten (virtuele machines) die kunnen worden gewijzigd om aan de behoeften van uw organisatie te voldoen. Dit kan worden teruggebracht tot één VM. De netwerkindeling is aanzienlijk vereenvoudigd om de architectuur-principals te demonstreren. Het is niet bedoeld om een volledig bedrijfsnetwerk te beschrijven.

Deze onderdelen zijn vereist:

Virtuele netwerken. De Azure Virtual Network-service verbindt Azure-resources met elkaar met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met een on-premises omgeving via een VPN-gateway (virtual private network) 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.

Peering voor virtuele netwerken. Deze architectuur maakt gebruik van een hub-and-spoke-netwerktopologie met meerdere virtuele netwerken die aan elkaar zijn ge peerd. Deze topologie biedt netwerksegmentatie en isolatie voor services die zijn geïmplementeerd in Azure. Peering maakt transparante connectiviteit mogelijk tussen virtuele peernetwerken via het Backbone-netwerk van Microsoft. Er wordt geen prestatiestraf toegepast als deze wordt geïmplementeerd binnen één regio. Het virtuele netwerk is onderverdeeld in afzonderlijke subnetten voor elke laagtoepassing (SAP NetWeaver), de database en gedeelde services (zoals Jumpbox en Active Directory).

Virtuele machines. Deze architectuur maakt gebruik van virtuele machines voor de toepassingslaag en databaselaag, gegroepeerd als:

  • SAP NetWeaver. De toepassingslaag maakt gebruik van virtuele Windows-machines om SAP Central Services en SAP-toepassingsservers uit te voeren. De VM's met Central Services worden geconfigureerd als een Windows Server-failovercluster voor hoge beschikbaarheid. Ze worden ondersteund door Windows Scale-Out-bestandsserver met Opslagruimten Direct of gedeelde Azure-schijven.

  • AnyDB. In de databaselaag wordt AnyDB uitgevoerd als de database, zoals Microsoft SQL Server, Oracle of IBM Db2.

  • Jump box (ook wel een bastionhost genoemd). Beheerders gebruiken deze verbeterde virtuele machine om verbinding te maken met de andere virtuele machines. Het maakt doorgaans deel uit van gedeelde services, zoals domeincontrollers en back-upservices. Als Secure Shell Protocol (SSH) en Remote Desktop Protocol (RDP) de enige services zijn die worden gebruikt voor serverbeheer, is een Azure Bastion-host een alternatief. Maar als u andere beheerhulpprogramma's gebruikt, zoals SQL Server Management Studio of SAP Front End, gebruikt u een traditionele, zelf geïmplementeerde jumpbox.

  • Windows Server Active Directory domeincontrollers. De domeincontrollers worden gebruikt voor identiteitsbeheer van alle virtuele machines en gebruikers in het domein.

Load balancers. Load balancers worden gebruikt om verkeer te distribueren naar virtuele machines in het subnet van de toepassingslaag. Gebruik voor hoge beschikbaarheid de ingebouwde SAP-webverdeler, Azure Load Balancerof netwerkapparaten. Uw keuze is afhankelijk van het verkeerstype (zoals HTTP of SAP GUI) of de vereiste netwerkservices, zoals Secure Sockets Layer (SSL)-beëindiging.

Beschikbaarheidssets. VM's voor alle pools en clusters (web-dispatcher, SAP-toepassingsservers, centrale services en databases) worden gegroepeerd in afzonderlijke beschikbaarheidssets. Per rol worden ten minste twee virtuele machines ingericht. Beschikbaarheidssets verhogen de beschikbaarheid van de toepassingen en VM's. Ze doen dit via het beheer van hostsysteemfouten of onderhoudsgebeurtenissen door rol-exemplaren naar meerdere hosts te distribueren. Een alternatief is het gebruik van Beschikbaarheidszones om de beschikbaarheid van workloads te verbeteren, zoals verder in dit artikel wordt beschreven.

Zone-redundante gateway. Azure ExpressRoute- of VPN-gateways kunnen worden geïmplementeerd in meerdere zones om bescherming te krijgen tegen zonefouten. Zie Zone-redundante virtuele netwerkgateways voor meer inzicht in de verschillen tussen een zone-redundante implementatie en een zone-redundante implementatie.

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 collocatie, wat betekent dat virtuele machines zich in hetzelfde datacenter bevinden om de latentie van toepassingen te minimaliseren.

Netwerkbeveiligingsgroepen. Als u binnenkomend, uitgaand en intrasubnetverkeer in het virtuele netwerk wilt beperken, maakt u netwerkbeveiligingsgroepen.

Toepassingsbeveiligingsgroepen. Als u een fijnfinieerd netwerkbeveiligingsbeleid wilt definiëren op basis van workloads die zijn gecentreerd op toepassingen, gebruikt u toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen. U kunt VM's groeperen op naam en u helpen toepassingen te beveiligen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

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

Azure Storage. Azure Storage biedt gegevens persistentie voor een virtuele machine in de vorm van een virtuele harde schijf (VHD). We raden beheerde Azure-schijven aan.

Aanbevelingen

Deze architectuur beschrijft een kleine implementatie op productieniveau. Uw implementatie verschilt op basis van uw zakelijke vereisten, dus houd rekening met deze aanbevelingen als uitgangspunt.

Virtuele machines

Pas in groepen en clusters van toepassingsservers het aantal virtuele machines aan op basis van uw vereisten. De azure Virtual Machines plannings- en implementatiehandleiding bevat informatie over het uitvoeren van SAP NetWeaver op virtuele machines.

Zie SAP-notitie 1928533voor meer informatie over SAP-ondersteuning voor typen virtuele Azure-machines en metrische gegevens over doorvoer (SAPS). (Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.)

SAP Web Dispatcher (SWD)

Het onderdeel Web dispatcher wordt gebruikt als een load balancer sap-verkeer tussen de SAP-toepassingsservers. Voor hoge beschikbaarheid voor het onderdeel Web Dispatcher wordt Azure Load Balancer gebruikt om het failovercluster van SWD's of de parallelle SWD-installatie te implementeren. Zie Hoge beschikbaarheid van de SAP-webverdeler voor een gedetailleerde beschrijving van de oplossing.

Groep toepassingsservers

De SAP SMLG-transactie wordt vaak gebruikt voor het beheren van aanmeldingsgroepen voor ABAP-toepassingsservers en voor het laden van de balans tussen aanmeldingsgebruikers. Andere transacties, zoals SM61 voor batchservergroepen en RZ12 voor RFC-groepen, bieden ook een load balance voor aanmeldingsgebruikers. Deze transacties maken gebruik van de taakverdelingsfunctie binnen de berichtenserver van SAP Central Services om binnenkomende sessies of werkbelastingen te verdelen over de SAP-toepassingsservergroep voor SAP GU's en RFC-verkeer.

SAP Central Services-cluster

Deze referentiearchitectuur voert Central Services uit op VM's in de toepassingslaag. Central Services is een potentieel SpOF (Single Point of Failure) wanneer deze wordt geïmplementeerd op één virtueleM. Als u een oplossing met hoge beschikbaar wilt implementeren, gebruikt u een bestandsdeelcluster of een cluster met gedeelde schijven.

Voor bestandsdeelclusters zijn er verschillende opties. We raden u aan om Azure Files shares te gebruiken als volledig beheerde, cloudeigen SMB- of NFS-shares. Een alternatief voor Azure Files is Azure NetApp Files, die krachtige NFS- en SMB-shares biedt.

U kunt de bestands share met hoge beschikbaarheid ook implementeren op de Central Services-exemplaren met behulp van WSFC met Scale-out bestandsserver en de functie Opslagruimten Direct in Windows Server 2016 en hoger. Deze oplossing biedt ook ondersteuning voor Windows-clusters door een bestands share te gebruiken die wordt Scale-Out bestandsserver als het gedeelde clustervolume (CSV).

Als u liever gedeelde schijven gebruikt, raden we u aan gedeelde Azure-schijven te gebruiken om een Windows Server-failoverclusterin te stellen voor SAP Central Services Cluster.

Er zijn ook producten van derden, zoals SIOS DataKeeper Cluster Edition van SIOS Technology Corp. Met deze invoegversie wordt inhoud gerepliceerd van onafhankelijke schijven die zijn gekoppeld aan de ASCS-clusterknooppunten en worden de schijven vervolgens als een CSV aan de clustersoftware aangeboden.

Microsoft ondersteunt meerdere ASCS-exemplaren met verschillende systeem-ID's (SID's) geïmplementeerd op één Windows-cluster via meerdere bestands shares die worden aangeboden door hetzelfde Scale-out bestandsserver cluster. Deze configuratie kan u helpen de infrastructuurkosten te verlagen.

In het geval van clusternetwerkpartities gebruikt de clustersoftware stemmen om te bepalen welk segment van het netwerk en de bijbehorende services als het brein van het nu gefragmenteerde cluster zullen fungeren. Windows biedt een aantal quorummodellen. Deze oplossing maakt gebruik van Azure Cloud Witness omdat deze eenvoudiger is en meer beschikbaarheid biedt dan een reken-knooppunt-witness. De Azure-bestandsdeelwit witness is een ander alternatief om een clusterquorumstem te bieden.

In een Azure-implementatie maken de toepassingsservers verbinding met de centrale services met hoge beschikbare services via de namen van virtuele servers van de ASCS- of ERS-services. Deze hostnamen worden toegewezen aan de front-end-IP-configuratie van het cluster van de load balancer. Azure Load Balancer ondersteuning voor meerdere front-end-IP's, zodat zowel de ASCS- als ERS-VP's (VIP's) kunnen worden gebonden aan één load balancer.

Beschikbaarheidssets

Beschikbaarheidssets distribueren servers naar verschillende fysieke infrastructuren en updategroepen om de beschikbaarheid van de service te verbeteren. Als u wilt voldoen aan serviceovereenkomsten(SLA's),moet u virtuele machines die dezelfde rol uitvoeren, in een beschikbaarheidsset zetten. Dit helpt u te beschermen tegen geplande en ongeplande downtime die wordt veroorzaakt door onderhoud van de Azure-infrastructuur of als gevolg van hardwarefouten. Als u een hogere SLA wilt krijgen, moet u twee of meer virtuele machines per beschikbaarheidsset hebben.

Alle virtuele machines in een set moeten dezelfde rol uitvoeren. Combineer geen servers met verschillende rollen in dezelfde beschikbaarheidsset. Plaats bijvoorbeeld geen ASCS-knooppunt in dezelfde beschikbaarheidsset met de toepassingsservers.

U kunt Azure-beschikbaarheidssets in Azure-beschikbaarheidszones wanneer u een nabijheidsplaatsingsgroep gebruikt.

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 peeren met de hub en de SAP-workloads isoleren. Verkeer stroomt tussen het on-premises datacenter en de hub via een gatewayverbinding.

Netwerkinterfacekaarten (NIC's)

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

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

Azure NIC's ondersteunen meerdere IP's. Deze ondersteuning voldoet aan de aanbevolen SAP-praktijk voor het gebruik van virtuele hostnamen voor installaties. Zie SAP-notitie 962955voor een volledig overzicht. (Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.)

Subnetten en netwerkbeveiligingsgroepen

Deze architectuur subdiveert 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 gemakkelijker beveiligen door het beveiligingsbeleid van het subnet te beheren in plaats van de afzonderlijke servers.

Wanneer een netwerkbeveiligingsgroep is gekoppeld aan een subnet, is deze van toepassing op alle servers binnen het subnet en biedt deze een fijnf bericht over de servers. Stel deze in met behulp van de Azure Portal, PowerShellof Azure CLI.

ExpressRoute Global Reach

Als uw netwerkomgeving twee of meer ExpressRoute-verbindingen bevat, kunnen ExpressRoute-Global Reach u helpen netwerkhops en -latentie te verminderen. Deze technologie is een BGP-route-peering die is ingesteld tussen twee of meer ExpressRoute-verbindingen om twee ExpressRoute-routeringsdomeinen te overbruggen. Global Reach vermindert de latentie wanneer netwerkverkeer meer dan één ExpressRoute-verbinding passeert. Deze is momenteel alleen beschikbaar voor persoonlijke peering op ExpressRoute-circuits.

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

ExpressRoute FastPath

FastPath, ook wel Microsoft Edge Exchange (MSEE) v2 genoemd, implementeert MSEE op het toegangspunt van het Azure-netwerk. Het vermindert netwerkhops voor de meeste gegevenspakketten.

Voor alle nieuwe ExpressRoute-verbindingen met Azure is FastPath de standaardconfiguratie. Voor bestaande ExpressRoute-circuits kunt u contact opnemen ondersteuning voor Azure FastPath te activeren.

FastPath biedt geen ondersteuning voor peering voor virtuele netwerken. Als andere virtuele netwerken zijn gekoppeld aan een netwerk dat is verbonden met ExpressRoute, blijft het netwerkverkeer van uw on-premises netwerk naar de andere virtuele spoke-netwerken naar de virtuele netwerkgateway worden verzonden. De tijdelijke oplossing is om alle virtuele netwerken rechtstreeks te verbinden met het ExpressRoute-circuit.

Load balancers

De SAP-webverdeler verwerkt de taakverdeling van HTTP(S)-verkeer naar een groep SAP-toepassingsservers. Deze software load balancer services voor toepassingslagen (laag 7 genoemd in het ISO-netwerkmodel) die SSL-beëindiging en andere offloading-functies kunnen uitvoeren.

Azure Load Balancer is een netwerkoverdrachtlaagservice (laag 4) die verkeer in balans brengen met behulp van een hash met vijf tuples uit de gegevensstromen. (De hash is gebaseerd op bron-IP, bronpoort, doel-IP, doelpoort en protocoltype.) In SAP-implementaties in Azure wordt Load Balancer gebruikt in clusterinstellingen om verkeer om te leiden naar het primaire service-exemplaar of naar het knooppunt met een goede status als er een fout is.

U wordt aangeraden Azure-Standard Load Balancer voor alle SAP-scenario's. Als voor virtuele machines in de back-endpool openbare uitgaande connectiviteit is vereist, of als ze worden gebruikt in een implementatie in een Azure-zone, vereisen de standaard load balancers standaard meer configuraties nadat ze zijn beveiligd. Er wordt geen uitgaande connectiviteit toegestaan, tenzij u deze expliciet configureert.

Voor verkeer van SAP GUI-clients die verbinding maken met een SAP-server via het DIAG-protocol of Externe functie-aanroepen (RFC), wordt de belasting verdeeld via aanmeldingsgroepen van de SAP-toepassingsserver. U hebt geen andere load balancer.

Azure Storage

Sommige organisaties gebruiken standaardopslag voor hun toepassingsservers. Standaard beheerde schijven worden niet ondersteund. Zie SAP-notitie 1928533. (SAP Service Marketplace-account vereist.) U wordt aangeraden premium beheerde Azure-schijven in alle gevallen te gebruiken. Houd er rekening mee dat een recente update voor SAP-notitie 2015553 het gebruik van Standard - HDD-opslag en Standard - SSD-opslag voor een paar specifieke use cases uitsluit.

Toepassingsservers hosten geen bedrijfsgegevens. U kunt dus ook de kleinere P4- en P6 Premium-schijven gebruiken om de kosten te minimaliseren. Als u dit doet, kunt u ook profiteren van de SLA met één VM met één exemplaar als u een centrale sap stack-installatie hebt.

Voor scenario's met hoge beschikbaarheid zijn gedeelde Azure-schijven beschikbaar op Premium - SSD en Ultra - SSD beheerde Azure-schijven. U kunt gedeelde Azure-schijven gebruiken met Windows Server, SUSE Linux Enterprise Server 15 SP1 en hoger en SUSE Linux Enterprise Server Voor SAP.

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

Voor het gegevensarchief voor back-ups raden we azure cool en archive access tiers aan. Deze opslaglagen bieden een rendabele manier om langdende gegevens op te slaan die niet regelmatig worden gebruikt.

Ultraschijven verminderen de schijflatentie aanzienlijk en profiteren van prestatiekritische toepassingen zoals de SAP-databaseservers. Vergelijk opties voor blokopslag in Azure.

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

Prestatieoverwegingen

SAP-toepassingsservers communiceren voortdurend met de databaseservers. Voor prestatiekritieke toepassingen die worden uitgevoerd op databaseplatforms, moet Write Accelerator voor het logboekvolume. Dit kan de latentie voor het schrijven van logboeken verbeteren. Write Accelerator is beschikbaar voor VM's uit de M-serie. Gebruik versneld netwerken om communicatie tussen servers te optimaliseren. Versneld netwerken is alleen beschikbaar voor ondersteunde VM-reeksen, waaronder D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 en Ms/Mms. Zie VM-prestaties maximaliseren met versneld netwerken voor meer informatie.

Voor een hoge IOPS- en schijfbandbreedtedoorvoer zijn de algemene procedures voor optimalisatie van opslagvolumeprestaties van toepassing op de Azure-opslagindeling. U kunt bijvoorbeeld meerdere schijven combineren om een striped schijfvolume te maken om de I/O-prestaties te verbeteren. Door de leescache in te schakelen voor Storage-inhoud die veelvuldig wordt gewijzigd, wordt de snelheid van het ophalen van gegevens verhoogd.

Ultraschijven zijn nu beschikbaar voor I/O-veeleisende toepassingen. Waar ze beschikbaar zijn, raden we ze aan via Write Accelerator Premium Storage. U kunt metrische prestatiegegevens, zoals IOPS en MBps, afzonderlijk verhogen of verlagen zonder dat u opnieuw hoeft op te starten.

Voor SAP on Azure biedt Azure Virtual Machines planning en implementatie voor SAP NetWeaver uitstekend advies over het optimaliseren van Azure-opslag voor SAP-workloads op SQL Server.

Het is niet raadzaam om voor elke SAP-toepassingsstack een virtueel netwerkapparaat (NVA) tussen de toepassing en de databaselagen te plaatsen. Deze praktijk introduceert een aanzienlijke verwerkingstijd voor gegevenspakketten, wat leidt tot onaanacceptabele toepassingsprestaties.

Nabijheidsplaatsingsgroepen

Sommige SAP-toepassingen vereisen regelmatige communicatie met de database. De fysieke nabijheid van de toepassing en de databaselagen is van invloed op de netwerklatentie, wat de prestaties van de toepassing nadelig kan beïnvloeden.

Als u de netwerklatentie wilt optimaliseren, kunt u nabijheidsplaatsingsgroepen gebruiken,waarmee een logische beperking wordt ingesteld voor de virtuele machines die zijn geïmplementeerd in beschikbaarheidssets. Nabijheidsplaatsingsgroepen zijn gunstig voor collocatie en prestaties boven schaalbaarheid, beschikbaarheid of kosten. Ze kunnen de gebruikerservaring voor de meeste SAP-toepassingen sterk verbeteren. Scripts zijn beschikbaar op GitHub.

Beschikbaarheidszones

Beschikbaarheidszones kunt u virtuele machines implementeren in zones. Dat wil zeggen, fysiek gescheiden locaties binnen een specifieke Azure-regio. Het doel is om de beschikbaarheid van de service te verbeteren, maar houd rekening met de prestaties wanneer u resources met zones implementeert.

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 virtuele machines in elke zone om te testen. Aanbevolen hulpprogramma's voor deze tests zijn PsPing en Iperf. Wanneer de tests zijn uitgevoerd, verwijdert u de virtuele machines die u hebt gebruikt voor het testen.

Schaalbaarheidsoverwegingen

Voor de SAP-toepassingslaag biedt Azure een breed scala aan grootten voor virtuele machines voor omhoog schalen en uitschalen. Zie SAP-notitie 1928533 - SAP-toepassingen in Azure: Ondersteundeproducten 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 Central Services-clusters omhoog, omlaag of uit schalen door meer exemplaren toe te voegen. De AnyDB-database kan omhoog en omlaag worden geschaald, maar niet uitschalen. De SAP-databasecontainer voor AnyDB biedt geen ondersteuning voor sharding.

Beschikbaarheidsoverwegingen

Resource-redundantie is het algemene thema in infrastructuuroplossingen met hoge beschikbaarheid. Voor ondernemingen die een minder strenge SLA hebben, bieden virtuele Azure-machines met één exemplaar met Premium-schijven een SLA voor uptime. Wanneer u redundante resources implementeert in een beschikbaarheidsset of Beschikbaarheidszones, wordt de beschikbaarheid van de service verhoogd.

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.

Webverdeler in de laag toepassingsservers

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

Voor internetcommunicatie raden we een stand-alone oplossing aan in het perimeternetwerk (ook wel DMZ genoemd) om te voldoen aan beveiligingsproblemen.

Ingesloten web-dispatcher op ASCS is een speciale optie. U moet rekening houden met de juiste formaatsing vanwege extra werkbelasting op ASCS.

Central Services in de laag toepassingsservers

Hoge beschikbaarheid van de Central Services wordt geïmplementeerd met Windows Server Failover Cluster (WSFC). Wanneer de clusteropslag voor het failovercluster wordt geïmplementeerd in Azure, kunt u deze op twee manieren configureren: als een geclusterd gedeeld volume of als een bestands share.

We raden u aan om Azure Files volledig beheerde, cloudeigen SMB- of NFS-shares te gebruiken. Een alternatief voor Azure Files is Azure NetApp Files,die hoogwaardige, hoogwaardige NFS- en SMB-shares biedt.

WSFC ondersteunt het gebruik van bestands shares die worden gebruikt door de Scale-out bestandsserver als clusteropslag. Scale-Out bestandsserver biedt flexibele bestands shares die u kunt gebruiken als een CSV (Cluster Shared Volume) voor het Windows-cluster. U kunt een Scale-Out bestandsservercluster delen tussen meerdere SAP Central Services-exemplaren.

Vanaf dit schrijven wordt Scale-Out-bestandsserver alleen gebruikt voor ontwerp met hoge beschikbaarheid binnen één Azure-zone. (Implementatie tussen zones wordt niet ondersteund.) Voor noodherstel (DR) ondersteunt Azure Site Recovery replicatie van het hele Scale-Out bestandsservercluster naar een externe regio.

Er zijn twee manieren om clusters met gedeelde schijven in Azure in te stellen. Eerst raden we u aan gedeelde Azure-schijven te gebruiken om een Windows Server-failoverclusterin te stellen voor SAP Central Services Cluster.

U kunt ook SIOS DataKeeper gebruiken voor het volgende:

  • Repliceer de inhoud van onafhankelijke schijven die zijn gekoppeld aan de clusterknooppunten.
  • Abstractie van de stations als een CSV voor het clusterbeheer.

Zie Clustering SAP ASCS on Azure (SAP ASCS-clustering op Azure) voor meer details over de implementatie.

Met de introductie van de Azure Standard Load Balancer kunt u nu eenvoudig de poort voor hoge beschikbaarheid inschakelen. Hierdoor kunt u voorkomen dat u taakverdelingsregels configureert voor veel SAP-poorten. Wanneer u load balancers in het algemeen in het algemeen in stelt, zowel on-premises als in Azure, moet u ook de functie Direct Server Return inschakelen (ook wel zwevend IP of DSR genoemd). Als u dit doet, kunnen serverreacties de load balancer. Deze directe verbinding voorkomt dat load balancer een knelpunt wordt in het pad van gegevensoverdracht. Voor de SAP ASCS- en databaseclusters raden we u aan DSR in te schakelen.

Toepassingsservices in de laag toepassingsservers

Hoge beschikbaarheid voor de SAP-toepassingsservers wordt bereikt door verkeer binnen een groep toepassingsservers te taakverdeling.

Databaselaag

Voor deze referentiearchitectuur is ervan uitgegaan dat de brondatabase wordt uitgevoerd op AnyDB. Dat wil zeggen: een DBMS zoals SQL Server, SAP ASE, IBM Db2 of Oracle. De systeemeigen replicatiefunctie van de databaselaag biedt handmatige of automatische failover tussen gerepliceerde knooppunten.

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

Virtuele machines die zijn geïmplementeerd in Beschikbaarheidszones

Beschikbaarheidszones zijn een logische constructie die is ontworpen om de beschikbaarheid van workloads te verbeteren en toepassingsservices en virtuele machines te beschermen tegen uitval van datacenters. Virtuele machines in één zone worden behandeld alsof ze zich in één update- of foutdomein bevindt. Wanneer u zonelijke implementatie selecteert, worden virtuele machines in dezelfde zone op best effort-basis gedistribueerd naar fout- en upgradedomeinen.

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

U moet rekening houden met deze overwegingen wanneer u besluit om resources te implementeren in Beschikbaarheidszones:

  • Latentie tussen virtuele machines in één zone.

  • Latentie tussen virtuele machines in de gekozen zones.

  • Beschikbaarheid van dezelfde Azure-services (typen virtuele machines) in de gekozen zones.

Notitie

Beschikbaarheidszones hoge beschikbaarheid ondersteunen, maar ze zijn niet effectief voor dr. De afstanden tussen zones zijn te kort. Typische DR-regio's moeten ten minste 100 mijl van de primaire regio verwijderd zijn.

Voorbeeld van een actieve/inactieve implementatie

In deze voorbeeldimplementatie verwijst de status actief/passief naar de status van de toepassingsservice binnen de zones. In de toepassingslaag zijn alle vier de actieve toepassingsservers van het SAP-systeem in zone 1. Een andere set van vier passieve toepassingsservers is ingebouwd in zone 2, maar wordt afgesloten. Ze worden alleen geactiveerd wanneer dat nodig is.

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

Voorbeeld van actieve/actieve implementatie

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

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

Als zone 1 offline gaat, worden Central Services en de databaseservices overgeslagen naar zone 2. U kunt de inactief toepassingsservers online brengen om volledige capaciteit voor toepassingsverwerking te bieden.

Overwegingen voor herstel na noodgeval

Elke laag in de SAP-toepassingsstack gebruikt een andere DR-strategie.

Laag toepassingsservers

SAP-toepassingsservers bevatten geen bedrijfsgegevens. In Azure is een eenvoudige dr-strategie om SAP-toepassingsservers te maken in de secundaire regio en deze vervolgens af te sluiten. Als er configuratiewijzigingen of kernelupdates op de primaire toepassingsserver zijn, moet u dezelfde wijzigingen toepassen op de virtuele machines in de secundaire regio. Kopieer bijvoorbeeld de uitvoerbare SAP-kernelbestanden naar de virtuele machines voor dr.

Voor automatische replicatie van toepassingsservers naar een secundaire regio raden we u Azure Site Recovery. U kunt ook een Azure Site Recovery voor het instellen van een SAP NetWeaver-toepassingsimplementatie met meerderelaags.

Central Services

Met dit onderdeel van de SAP-toepassingsstack worden geen bedrijfsgegevens persistent. Voor dr-beveiliging repliceert u de /sapmnt-inhoud naar een stand-by virtuele machine in de dr-regio of gebruikt u Azure Site Recovery om zowel het cluster Central Services als het Scale-Out-bestandsservercluster te repliceren. U kunt ook Site Recovery om het Central Services-cluster te repliceren met behulp van SIOS DataKeeper-schijven.

U kunt een virtuele machine bouwen in de DR-regio om de rol en inhoud van Central Services te repliceren. De enige inhoud van het primaire Central Services-knooppunt dat moet worden gesynchroniseerd, is de /sapmnt-share. Als de configuratiewijzigingen of kernelupdates plaatsvinden op de primaire Central Services-servers, moet u de wijzigingen op de virtuele machine in de DR-regio herhalen. Download SAP NetWeaver: Building a Hyper-V and Microsoft Azure-based Disaster Recovery Solutionvoor meer informatie over het failoverproces van deze replicatiemethode. Zie 4.3. SAP SPOF-laag (ASCS).

Bij het implementeren van hoge beschikbaarheid voor Central Services met behulp van Scale-Out File Server of SIOS, ondersteunt Site Recovery de replicatie en het herstel van zowel het Cluster Central Services als het Scale-Out File Server/Storage Space Direct-cluster. U kunt het Central Services-cluster ook repliceren en herstellen met behulp van SIOS DataKeeper-schijven.

Databaselaag

Het is het beste om de geïntegreerde replicatietechnologie van een database te gebruiken voor dr. Voor een SQL Server raden we u bijvoorbeeld aan AlwaysOn-beschikbaarheidsgroepen te gebruiken om een replica in een externe regio tot stand te brengen en transacties asynchroon te repliceren met behulp van handmatige failover. Asynchrone replicatie voorkomt een impact op de prestaties van interactieve workloads op de primaire site. Wanneer u een handmatige failover gebruikt, kunt u vervolgens de impact op het dr-systeem evalueren en bepalen of het werken vanaf de dr-site gerechtvaardigd is.

Als u een Azure NetApp Files voor uw databaseopslag gebruikt, kunt u mogelijk replicatie tussen regio's gebruiken om gegevens te repliceren naar een secundaire regio. Deze functie is momenteel in preview, dus evalueer of deze voldoet aan uw vereisten voor productieworkloads.

DR voor gedeelde services

Veel IT-services, zoals administratieve jumpboxs, cloudgebaseerde adreslijstservices, back-up- en bewakingsservices, worden gedeeld door al uw geïmplementeerde cloudactiva. Repliceer uw gedeelde services naar de DR-regio met behulp van de middelen die de services bieden.

Geautomatiseerde DR met Azure Site Recovery

Als u Azure Site Recovery om automatisch een volledig gerepliceerde productiesite van uw oorspronkelijke configuratie te bouwen, moet u aangepaste implementatiescripts uitvoeren. Zo implementeert Site Recovery eerst de virtuele machines in beschikbaarheidssets. Vervolgens worden uw aangepaste scripts uitgevoerd om de bestaande (vooraf gedefinieerde) load balancer, waarin de back-endpool al is gedefinieerd, te koppelen aan de NIC van de virtuele failovermachines. Een voorbeeld van het aangepaste Site Recovery Automation Runbooks-script is beschikbaar op GitHub.

Notitie

In het geval van een regionale ramp die een grootschalige failover veroorzaakt voor veel Azure-klanten in één regio, wordt de resourcecapaciteit van de doelregio niet gegarandeerd. Net als alle Azure-services blijven Site Recovery functies en mogelijkheden verbeteren. Zie de meest recente ondersteuningsmatrix voor herstel na noodherstel van virtuele Azure-machines van de ene Azure-regio naar de andere.

Overwegingen voor beheer en bewerkingen

Backup

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

  • Voor SAP on SQL Server is één benadering het gebruik van Azure Backup back-up te SQL Server databases die worden uitgevoerd op virtuele machines. Een andere optie is het gebruik van Azure Files momentopnamen om een back-up te maken van SQL Server databasebestanden.

  • Zie de sectie Back-up/herstellen in Azure VM DBMS Deployment for SAPvoor SAP.

  • Zie de back-upaanbevelingen voor uw databaseprovider voor andere databases. Als de database ondersteuning biedt voor Windows Volume Shadow Copy Service (VSS), worden toepassings-consistente back-ups gemaakt met behulp van VSS-momentopnamen

Identiteitsbeheer

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

Ondersteuning voor toegang binnen de toepassingen zelf met behulp van de services die SAP biedt. Of gebruik OAuth 2.0 en Azure Active Directory.

Bewaking

Azure Monitor biedt geavanceerde hulpprogramma's voor het verzamelen en analyseren van telemetrie. Met deze hulpprogramma's kunt u de prestaties en beschikbaarheid van uw cloud- en on-premises resources en toepassingen maximaliseren. (Azure Monitor bevat nu Log Analytics en Application Insights.) U kunt Azure Monitor om afwijkingen in de infrastructuur en toepassingen te bewaken, beheerders te waarschuwen en reacties op vooraf gedefinieerde voorwaarden te automatiseren.

Gebruik de extensie Verbeterde bewaking van Azure SAP om op SAP gebaseerde bewaking van resources en serviceprestaties van de SAP-infrastructuur te bieden. Met deze extensie worden Azure-controlestatistieken in de SAP-toepassing gevoerd voor het controleren van het besturingssysteem en de DBA Cockpit-functies. Sap Enhanced Monitoring is vereist voor het uitvoeren van SAP on Azure. Zie SAP note 2191498, "SAP on Linux with Azure: Enhanced Monitoring" voor meer informatie. (Voor toegang tot SAP-notities hebt u een SAP Service Marketplace-account nodig.)

Azure Monitor for SAP Solutions is de toekomstige richting voor een systeemeigen, end-to-end bewakingsoplossing van Azure voor SAP NetWeaver. Deze oplossing is momenteel beschikbaar als preview-versie en is alleen beschikbaar in een beperkt aantal regio's. U moet zorgvuldig evalueren of het voldoet aan uw vereisten.

Azure Monitor for SAP Solutions biedt een uitgebreide eerste set metrische gegevens en telemetrie voor bewaking. De metrische definities worden opgeslagen als SQL-query's in JSON. U kunt deze wijzigen om te voldoen aan uw vereisten. U kunt de startset met metrische gegevens op GitHub bekijken.

Beveiligingsoverwegingen

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

Voor extra netwerkbeveiliging kunt u overwegen een perimeternetwerk te gebruiken dat gebruikmaakt van een virtueel netwerkapparaat (NVA) om een firewall te maken vóór het subnet voor de webverzender.

U kunt een NVA implementeren om verkeer tussen virtuele netwerken te filteren, maar niet tussen de SAP-toepassing en de database plaatsen. Controleer ook de routeringsregels die zijn geconfigureerd op het subnet en voorkom dat verkeer wordt omgeleid naar een NVA met één exemplaar. Dit kan leiden tot uitvaltijd voor onderhoud en fouten in het netwerk of geclusterde knooppunt.

Voor de beveiliging van de infrastructuur worden gegevens tijdens de overdracht en at-rest versleuteld. De sectie Beveiligingsaanbevelingen in Azure Virtual Machines planning en implementatie voor SAP NetWeaver-adressen netwerkbeveiliging. In dit artikel worden ook de netwerkpoorten opgegeven die u op de firewalls moet openen om toepassingscommunicatie toe te staan.

U kunt de Azure Disk Encryption voor het versleutelen van schijven van virtuele Windows-machines. Het maakt gebruik van de BitLocker-functie van Windows om volumeversleuteling te bieden voor het besturingssysteem en de gegevensschijven. De oplossing werkt ook met Azure Key Vault u de schijfversleutelingssleutels en -geheimen in uw key vault-abonnement kunt beheren en beheren. Inactieve gegevens op de virtuele-machineschijven zijn versleuteld in uw Azure-opslag.

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

Zorg er zoals altijd voor dat u beveiligingsupdates en patches beheert om uw gegevensactiva te beveiligen. Overweeg het gebruik van een end-to-end automatiseringsbenadering voor deze taak.

Kostenoverwegingen

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

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

Als uw workload meer geheugen en minder CPU's nodig heeft, kunt u een van de beperkte vCPU-VM-grootten gebruiken om de kosten voor softwarelicenties per vCPU te verlagen.

Virtuele machines

Deze architectuur maakt gebruik van virtuele machines voor de toepassingslaag en de databaselaag. De SAP NetWeaver-laag maakt gebruik van virtuele Windows-machines om SAP-services en -toepassingen uit te voeren. In de databaselaag wordt AnyDB uitgevoerd als de database, SQL Server, Oracle of IBM DB2. Virtuele machines worden ook gebruikt als jumpbox voor beheer.

Er zijn verschillende betalingsopties voor virtuele machines in het algemeen:

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

  • Overweeg het gebruik van Azure Reservations als u een virtuele machine gedurende een periode van één of drie jaar kunt gebruiken. VM-reserveringen kunnen de kosten tot wel 72 procent verlagen in vergelijking met betalen per gebruik-prijzen.

Gebruik Azure Spot Virtual Machines om workloads uit te voeren die kunnen worden onderbroken en waarvoor geen voltooiing is vereist binnen een vooraf bepaald tijdsbestek of een SLA. Azure implementeert spot-virtuele machines wanneer er capaciteit beschikbaar is en maakt ze beschikbaar wanneer de capaciteit weer nodig is. De kosten voor spot-virtuele machines zijn lager. Overweeg spot-VM's voor deze workloads:

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

Als u meer controle nodig hebt over onderhoudsgebeurtenissen of hardware-isolatie, voor prestaties of naleving, kunt u overwegen om uw virtuele machines te implementeren op toegewezen hosts.

Virtuele machines en beschikbaarheidssets

Voor alle pools en clusters (Web Dispatcher, SAP-toepassingsservers, Central Services en de database) worden de virtuele machines gegroepeerd in afzonderlijke beschikbaarheidssets. Er zijn geen kosten verbonden aan een beschikbaarheidsset. U betaalt alleen voor elk VM-exemplaar dat u maakt.

Als u een workload implementeert in Beschikbaarheidszones, zijn beschikbaarheidssets niet vereist.

Azure Load Balancer

In dit scenario wordt Azure Load Balancer gebruikt om verkeer te distribueren naar virtuele machines in het subnet van de toepassingslaag.

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdeling en uitgaande regels. Inkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening 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 Azure ExpressRoute prijzen voor meer informatie.

Community's

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

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