Bewerken

Delen via

SAP-implementatie in Azure met behulp van een Oracle-database

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Deze referentiearchitectuur toont een set bewezen procedures voor het uitvoeren van een SAP NetWeaver met hoge beschikbaarheid met Oracle Database in Azure. De architectuurprincipes zijn echter os-agnostisch, tenzij anders opgegeven, wordt ervan uitgegaan dat de architectuur is gebaseerd op Linux.

In het eerste diagram ziet u een referentiearchitectuur voor SAP in Oracle in Azure. We raden u aan om te implementeren in twee beschikbaarheidszones.

Diagram van de architectuur van een PRODUCTIE-SAP-systeem in Oracle in Azure.

Download een Visio-bestand van deze architectuur en gerelateerde architecturen.

Notitie

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

Onderdelen

Deze referentiearchitectuur beschrijft een typisch SAP-productiesysteem dat wordt uitgevoerd op Oracle Database in Azure, in een maximaal beschikbare implementatie om de beschikbaarheid van het systeem te maximaliseren. De architectuur en de bijbehorende onderdelen kunnen worden aangepast op basis van bedrijfsvereisten (hersteltijddoelstelling (RTO), herstelpuntdoelstelling (RPO), verwachtingen voor uptime, systeemrol) en mogelijk beperkt tot één VM. De netwerkindeling is vereenvoudigd om de architectuurprincipals van een dergelijke SAP-omgeving te demonstreren en niet bedoeld om een volledig bedrijfsnetwerk te beschrijven.

Netwerken

Virtuele netwerken. De Azure Virtual Network-service verbindt Azure-resources met elkaar met verbeterde beveiliging. In deze architectuur maakt het virtuele netwerk verbinding met on-premises via een VPN-gateway (virtual private network) die is geïmplementeerd in de hub van een hub-spoke-topologie. SAP-toepassingen en -databases bevinden zich in hun eigen virtuele spoke-netwerk. De virtuele netwerken zijn onderverdeeld in afzonderlijke subnetten voor elke laag: toepassing (SAP NetWeaver), de database en gedeelde services (zoals Azure Bastion).

Met deze architectuur wordt de adresruimte van het virtuele netwerk onderverdeeld in subnetten. Plaats toepassingsservers op een afzonderlijk subnet en databaseservers op een andere. Hierdoor kunt u ze eenvoudiger beveiligen door het subnetbeveiligingsbeleid te beheren in plaats van de afzonderlijke servers en de beveiligingsregels die van toepassing zijn op databases van toepassingsservers schoon te scheiden.

Peering van virtuele netwerken. Deze architectuur maakt gebruik van een sternetwerktopologie met meerdere virtuele netwerken die aan elkaar zijn gekoppeld. Deze topologie biedt netwerksegmentatie en isolatie voor services die zijn geïmplementeerd in Azure. Peering maakt transparante connectiviteit mogelijk tussen gekoppelde virtuele netwerken via het Microsoft backbone-netwerk.

Zone-redundante 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. Gebruik zone-redundante Azure ExpressRoute- of VPN-gateways om te voorkomen dat er zonefouten optreden. Zie zone-redundante virtuele netwerkgateways om inzicht te hebben in de verschillen tussen een zonegebonden implementatie en een zone-redundante implementatie. Het is de moeite waard hier te vermelden dat de IP-adressen die worden gebruikt, van standard-SKU moeten zijn voor een zone-implementatie van de gateways.

Netwerkbeveiligingsgroepen. Als u inkomend, uitgaand en intrasubnetverkeer in het virtuele netwerk wilt beperken, maakt u netwerkbeveiligingsgroepen (NSG's) die op hun beurt zijn toegewezen aan specifieke subnetten. DB- en toepassingssubnetten worden beveiligd met workloadspecifieke NSG's.

Toepassingsbeveiligingsgroepen. Gebruik toepassingsbeveiligingsgroepen in plaats van expliciete IP-adressen om nauwkeurig netwerkbeveiligingsbeleid binnen uw NSG's te definiëren op basis van workloads die zijn gericht op toepassingen. Hiermee kunt u VM's op naam groeperen en u helpen bij het beveiligen van toepassingen door verkeer van vertrouwde segmenten van uw netwerk te filteren.

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

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

Azure NIC's ondersteunen meerdere IP-adressen. Deze ondersteuning voldoet aan de aanbevolen SAP-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.)

Virtuele machines

Deze architectuur maakt gebruik van virtuele machines (VM). Voor sap-toepassingslaag worden VM's geïmplementeerd voor alle exemplaarrollen - webdispatcher en toepassingsservers - zowel centrale services SAP (A)SCS als ERS en toepassingsservers (PAS, AAS). Pas het aantal virtuele machines aan op basis van uw vereisten. De plannings- en implementatiehandleiding voor Azure Virtual Machines bevat informatie over het uitvoeren van SAP NetWeaver op virtuele machines.

Op dezelfde manier worden voor alle virtuele Oracle-doeleinden virtuele machines gebruikt, zowel voor de Oracle-database als voor Oracle-waarnemers-VM's. Waarnemers-VM's in deze architectuur zijn kleiner dan de werkelijke databaseservers.

  • Beperkte vCPU-VM's. Als u kosten voor Oracle-licenties wilt besparen, kunt u overwegen om beperkte vCPU-VM's te gebruiken
  • Gecertificeerde VM-families voor SAP. Zie SAP Note 1928533 voor 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.)

Nabijheidsplaatsingsgroepen (PPG). Wanneer virtuele machines worden geïmplementeerd in beschikbaarheidszones, is latentie binnen de zone meestal ideaal voor SAP-toepassingen. In zeldzame situaties waarin latentie tussen de database en virtuele machines van toepassingen moet worden verlaagd, kunt u nabijheidsplaatsingsgroepen gebruiken. In dergelijke situaties zorgen PPG's voor collocatie, wat betekent dat virtuele machines zich in hetzelfde datacenter bevinden om de latentie van toepassingen te minimaliseren. Vanwege mogelijke beperkingen met PPG's, moet het toevoegen van de database AvSet aan de PPG van het SAP-systeem sparseerd worden uitgevoerd en alleen wanneer dat nodig is. Zie de gekoppelde documentatie voor meer informatie over de gebruiksscenario's voor PPG's.

Virtuele machines van de tweede generatie (Gen2). Azure biedt de keuze bij het implementeren van VM's als ze generatie 1 of 2 moeten zijn. Vm's van de tweede generatie ondersteunen belangrijke functies die niet beschikbaar zijn voor VM's van de eerste generatie. Met name voor zeer grote Oracle-databases is dit van belang omdat sommige VM-families, zoals Mv2 of Mdsv2, alleen worden ondersteund als Gen2-VM's. Op dezelfde manier vereist SAP op Azure-certificering voor sommige nieuwere VM's mogelijk dat ze alleen Gen2 zijn voor volledige ondersteuning, zelfs als Azure beide toestaat. Zie de details in SAP Note 1928533 - SAP-toepassingen in Microsoft Azure: ondersteunde producten en azure-VM-typen.

Omdat alle andere VM's die SAP ondersteunen, de keuze van alleen Gen2 of Gen1+2 selectief toestaan, is het raadzaam om alle SAP-VM's als Gen2 te implementeren, zelfs als de geheugenvereisten erg laag zijn. Zelfs de kleinste VM's die als Gen2 zijn geïmplementeerd, kunnen worden geschaald naar het grootste dat beschikbaar is met een eenvoudige toewijzing en het formaat ervan wijzigen. Gen1-VM's kunnen alleen worden gewijzigd in VM-families die gen1-VM's mogen uitvoeren.

Storage

Deze architectuur maakt gebruik van door Azure beheerde schijven voor virtuele machines en Azure-bestandsshares of Azure NetApp Files voor NFS-volumes (Network File System) voor gedeelde opslag, zoals sapmnt- en SAP-transport-NFS-volumes. Richtlijnen voor opslagimplementatie met SAP in Azure worden uitgebreid beschreven in de Azure Storage-typen voor SAP-workloadhandleiding

Hoge beschikbaarheid

In de voorgaande architectuur wordt een maximaal beschikbare implementatie weergegeven, waarbij elke toepassingslaag zich op twee of meer virtuele machines bevindt. De volgende onderdelen worden gebruikt.

In Azure kan de implementatie van SAP-workloads regionaal of zonegebonden zijn, afhankelijk van de beschikbaarheids- en tolerantievereisten van de SAP-toepassingen en de geselecteerde regio. Azure biedt verschillende implementatieopties, zoals Virtuele-machineschaalsets met flexibele indeling (FD=1), beschikbaarheidszones en beschikbaarheidssets om de beschikbaarheid van resources te vergroten. Zie architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver voor een uitgebreid begrip van de implementatieopties en de toepasbaarheid ervan in verschillende Azure-regio's (inclusief zones, binnen één zone of in een regio zonder zones).

Load balancers. Azure Load Balancer wordt gebruikt om verkeer te distribueren naar virtuele machines in de SAP-subnetten. Wanneer u Azure Load Balancer opneemt in een zonegebonden implementatie van SAP, moet u de Standard SKU-load balancer selecteren. De Basic SKU balancer biedt geen ondersteuning voor zonegebonden redundantie.

Houd rekening met de beslissingsfactoren bij het implementeren van VM's tussen beschikbaarheidszones voor SAP. Het gebruik van nabijheidsplaatsingsgroepen met een implementatie van een beschikbaarheidszone moet alleen worden geëvalueerd en alleen worden gebruikt voor VM's in de toepassingslaag.

Notitie

Beschikbaarheidszones ondersteuning bieden voor hoge beschikbaarheid binnen regio's, maar ze zijn niet effectief voor herstel na noodgevallen (DR). De afstanden tussen zones zijn te kort. Typische DR-regio's moeten zich ten minste 100 mijl van de primaire regio bevinden.

Oracle-specifieke onderdelen. Oracle Database-VM's worden geïmplementeerd in een beschikbaarheidsset of in verschillende beschikbaarheidszones. Elke VIRTUELE machine bevat een eigen installatie van de databasesoftware en de opslag van de VM-lokale database. Stel synchrone databasereplicatie in via Oracle Data Guard tussen de databases om consistentie te garanderen en lage RTO- en RPO-servicetijden toe te staan in het geval van afzonderlijke fouten. Naast de database-VM's zijn extra VM's met Oracle Data Guard-waarnemer nodig voor het instellen van een Fast Start-failover van Oracle Data Guard. De Oracle-waarnemers-VM's bewaken de database- en replicatiestatus en faciliteren databasefailover op een geautomatiseerde manier, zonder dat er clusterbeheer nodig is. Databasereplicatiebeheer kan vervolgens worden uitgevoerd met Oracle Data Guard Broker voor gebruiksgemak.

Zie de Oracle Data Guard-documentatie over Azure voor meer informatie over de implementatie van Oracle Data Guard.

Deze architectuur maakt gebruik van systeemeigen Oracle-hulpprogramma's zonder echte clustersoftware of de behoefte aan een load balancer in de databaselaag. Met de Fast-Start-failover en SAP-configuratie van Oracle Data Guard wordt het failoverproces geautomatiseerd en maken SAP-toepassingen opnieuw verbinding met de nieuwe primaire database als er een failover plaatsvindt. Er bestaan verschillende clusteroplossingen van derden als alternatief, zoals SIOS Protection Suite of Veritas InfoScale, waarin wordt beschreven welke implementatie te vinden is in respectievelijk de documentatie van de leverancier van de desbetreffende leverancier.

Oracle RAC. Oracle Real Application Cluster (RAC) is momenteel niet gecertificeerd of ondersteund door Oracle in Azure. Oracle Data Guard-technologieën en -architectuur voor hoge beschikbaarheid kunnen echter zeer tolerante SAP-omgevingen bieden met bescherming tegen rack-, datacenter- of regionale onderbrekingen van de service.

NFS-laag. Voor alle maximaal beschikbare SAP-implementaties moet een flexibele NFS-laag worden gebruikt, waarbij NFS-volumes worden verstrekt voor SAP-transportmap, sapmntvolume voor binaire SAP-bestanden en verdere volumes voor (A)SCS- en ERS-exemplaren. Opties voor het opgeven van een NFS-laag zijn

SAP Central Services-cluster. Deze referentiearchitectuur voert Central Services uit op afzonderlijke VM's. Central Services is een potentieel single point of failure (SPOF) wanneer deze wordt geïmplementeerd op één VIRTUELE machine. Voor het implementeren van een maximaal beschikbare oplossing is clusterbeheersoftware nodig waarmee failover van (A)SCS- en ERS-exemplaren naar de betreffende VM wordt geautomatiseerd. Omdat dit sterk is gekoppeld aan de gekozen NFS-oplossing

Voor een gekozen clusteroplossing is een mechanisme vereist om te beslissen in geval van software of infrastructuur die niet beschikbaar is voor de betreffende services. Met SAP in Azure zijn er twee opties beschikbaar voor implementatie op basis van Linux van STONITH: omgaan met niet-reagerende VM's of toepassingen

  • SUSE-Linux-only SBD (STONITH Block Device) - met behulp van een of drie extra VM's die fungeren als iSCSI-exports van een klein blokapparaat, dat regelmatig wordt geopend door de daadwerkelijke clusterlid-VM's, twee (A)SCS/ERS-VM's in deze clustergroep. De VM's gebruiken deze SBD-koppels om stemmen uit te brengen en zo quorum te bereiken voor clusterbeslissingen. De architectuur op deze pagina bevat niet de 1 of 3 extra SBD-VM's.
  • Azure Fence Agent. Zonder extra VM's te gebruiken, wordt de Azure Management-API gebruikt voor regelmatige controles op beschikbaarheid van vm's.

Handleidingen die zijn gekoppeld in de sectie NFS-laag bevatten de benodigde stappen en het ontwerp voor de respectieve clusterkeuze. Externe azure-gecertificeerde clusterbeheerders kunnen ook worden gebruikt om hoge beschikbaarheid van de centrale SAP-services te bieden.

GROEP SAP-toepassingsservers. Twee of meer toepassingsservers waar hoge beschikbaarheid wordt bereikt door taakverdelingsaanvragen via SAP-berichtenserver of webverzenders. Elke toepassingsserver is onafhankelijk en er is geen netwerktaakverdeling vereist voor deze groep vm's.

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

Embedded Web Dispatcher op (A)SCS is een speciale optie. U moet rekening houden met de juiste grootte vanwege extra werkbelasting op (A)SCS.

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

Windows-implementaties. Dit document, zoals voorafgegaan in het begin, is voornamelijk gericht op implementaties op basis van Linux. Voor gebruik met Windows gelden dezelfde architectuurprincipes en zijn er geen architecturale verschillen met Oracle tussen Linux en Windows.

Zie de details in de architectuurhandleiding SAP NetWeaver uitvoeren in Windows in Azure voor het sap-toepassingsonderdeel.

Overwegingen

Herstel na noodgeval

In het volgende diagram ziet u de architectuur van een PRODUCTIE-SAP-systeem in Oracle in Azure. De architectuur biedt herstel na noodgevallen en maakt gebruik van beschikbaarheidszones.

Diagram met een architectuur van een productie-SAP-systeem in Oracle in Azure.

Download een Visio-bestand van deze architectuur en gerelateerde architecturen.

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

Backup

Back-up voor Oracle in Azure kan op verschillende manieren worden bereikt:

Voor niet-database-VM's wordt Azure Backup voor VM aanbevolen om VM's van SAP-toepassingen te beveiligen en infrastructuur zoals SAP Web Dispatcher te plaatsen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Volgende stappen

Community's

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

Zie het volgende artikel voor meer informatie en voorbeelden van SAP-workloads die gebruikmaken van een aantal van dezelfde technologieën: