Een SAP-implementatie plannen en implementeren in Azure

  • Artikel

In Azure kunnen organisaties de cloudresources en -services ophalen die ze nodig hebben zonder een lange inkoopcyclus te voltooien. Maar het uitvoeren van uw SAP-workload in Azure vereist kennis van de beschikbare opties en zorgvuldige planning om de Azure-onderdelen en -architectuur te kiezen om uw oplossing te activeren.

Azure biedt een uitgebreid platform voor het uitvoeren van uw SAP-toepassingen. PaaS-aanbiedingen (Infrastructure as a Service) en Platform as a Service (PaaS) van Azure bieden u optimale keuzes voor een succesvolle implementatie van uw hele SAP Enterprise-landschap.

Dit artikel vormt een aanvulling op SAP-documentatie en SAP Notes, de primaire bronnen voor informatie over het installeren en implementeren van SAP-software op Azure en andere platforms.

Definities

In dit artikel gebruiken we de volgende termen:

  • SAP-onderdeel: een afzonderlijke SAP-toepassing zoals SAP S/4HANA, SAP ECC, SAP BW of SAP Solution Manager. Een SAP-onderdeel kan worden gebaseerd op traditionele ABAP-technologieën (Advanced Business Application Programming) of Java-technologieën, of het kan een toepassing zijn die niet is gebaseerd op SAP NetWeaver, zoals SAP BusinessObjects.
  • SAP-omgeving: meerdere SAP-onderdelen die logisch zijn gegroepeerd om een bedrijfsfunctie uit te voeren, zoals ontwikkeling, kwaliteitscontrole, training, herstel na noodgevallen of productie.
  • SAP-landschap: de volledige set SAP-assets in het IT-landschap van een organisatie. Het SAP-landschap bevat alle productie- en niet-productieomgevingen.
  • SAP-systeem: de combinatie van een databasebeheersysteemlaag (DBMS) en een toepassingslaag. Twee voorbeelden zijn een SAP ERP-ontwikkelsysteem en een SAP BW-testsysteem. In een Azure-implementatie kunnen deze twee lagen niet worden gedistribueerd tussen on-premises en Azure. Een SAP-systeem moet on-premises of in Azure worden geïmplementeerd. U kunt echter verschillende systemen in een SAP-landschap in Azure of on-premises gebruiken.

Resources

Het toegangspunt voor documentatie waarin wordt beschreven hoe u een SAP-workload in Azure host en uitvoert, is Aan de slag met SAP op een virtuele Azure-machine. In het artikel vindt u koppelingen naar andere artikelen die betrekking hebben op:

  • SAP-workloadspecifieke opties voor opslag, netwerken en ondersteunde opties.
  • SAP DBMS-handleidingen voor verschillende DBMS-systemen in Azure.
  • SAP-implementatiehandleidingen, zowel handmatig als geautomatiseerd.
  • Details over hoge beschikbaarheid en herstel na noodgevallen voor een SAP-workload in Azure.
  • Integratie met SAP in Azure met andere services en toepassingen van derden.

Belangrijk

Voor vereisten, het installatieproces en details over specifieke SAP-functionaliteit is het belangrijk om de SAP-documentatie en handleidingen zorgvuldig te lezen. In dit artikel worden alleen specifieke taken behandeld voor SAP-software die is geïnstalleerd en beheerd op een virtuele Azure-machine (VM).

De volgende SAP-notities vormen de basis van de Azure-richtlijnen voor SAP-implementaties:

Notitienummer Title
1928533 SAP-toepassingen in Azure: ondersteunde producten en grootte
2015553 SAP op Azure: ondersteuningsvereisten
2039619 SAP-toepassingen in Azure met behulp van de Oracle Database
2233094 DB6: SAP-toepassingen in Azure met IBM Db2 voor Linux, UNIX en Windows
1999351 Problemen met verbeterde Azure-bewaking voor SAP oplossen
1409604 Virtualisatie in Windows: Verbeterde bewaking
2191498 SAP op Linux met Azure: Verbeterde bewaking
2731110 Ondersteuning van virtuele netwerkapparaten (NVA) voor SAP in Azure

Zie azure-abonnements- en servicelimieten, quota en beperkingen voor algemene standaard- en maximumlimieten voor Azure-abonnementen en -resources.

Scenario's

SAP-services worden vaak beschouwd als een van de meest essentiële toepassingen in een onderneming. De architectuur en bewerkingen van de toepassingen zijn complex en het is belangrijk om ervoor te zorgen dat aan alle vereisten voor beschikbaarheid en prestaties wordt voldaan. Een onderneming denkt doorgaans zorgvuldig na over welke cloudprovider moet kiezen om dergelijke bedrijfskritieke bedrijfsprocessen uit te voeren.

Azure is het ideale openbare cloudplatform voor bedrijfskritieke SAP-toepassingen en bedrijfsprocessen. De meest recente SAP-software, waaronder SAP NetWeaver- en SAP S/4HANA-systemen, kan tegenwoordig worden gehost in de Azure-infrastructuur. Azure biedt meer dan 800 CPU-typen en VM's met veel terabytes geheugen.

Zie SAP op azure-VM's voor beschrijvingen van ondersteunde scenario's en sommige scenario's die niet worden ondersteund. Controleer deze scenario's en de voorwaarden die worden aangegeven als niet ondersteund wanneer u de architectuur plant die u wilt implementeren in Azure.

Als u SAP-systemen in Azure IaaS of iaaS in het algemeen wilt implementeren, is het belangrijk om inzicht te hebben in de belangrijke verschillen tussen de aanbiedingen van traditionele privéclouds en IaaS-aanbiedingen. Een traditionele host of uitbesteeder past infrastructuur (netwerk, opslag en servertype) toe aan de workload die een klant wil hosten. In een IaaS-implementatie is het de verantwoordelijkheid van de klant of partner om hun potentiële workload te evalueren en de juiste Azure-onderdelen van VM's, opslag en netwerk te kiezen.

Als u gegevens wilt verzamelen voor het plannen van uw implementatie naar Azure, is het belangrijk om:

  • Bepaal welke SAP-producten en -versies worden ondersteund in Azure.
  • Evalueer of het besturingssysteem dat u wilt gebruiken, wordt ondersteund met de Azure-VM's die u zou kiezen voor uw SAP-producten.
  • Bepaal welke DBMS-releases op specifieke VM's worden ondersteund voor uw SAP-producten.
  • Evalueer of het upgraden of bijwerken van uw SAP-landschap nodig is om te worden afgestemd op het vereiste besturingssysteem en DBMS-releases voor het bereiken van een ondersteunde configuratie.
  • Evalueer of u naar verschillende besturingssystemen moet gaan om te implementeren in Azure.

Details over ondersteunde SAP-onderdelen in Azure, Azure-infrastructuureenheden en gerelateerde besturingssysteemreleases en DBMS-releases worden uitgelegd in SAP-software die wordt ondersteund voor Azure-implementaties. De kennis die u krijgt van het evalueren van ondersteuning en afhankelijkheden tussen SAP-releases, besturingssysteemreleases en DBMS-releases heeft een aanzienlijke invloed op uw inspanningen om uw SAP-systemen naar Azure te verplaatsen. U leert of belangrijke voorbereidingsinspanningen betrokken zijn, bijvoorbeeld of u uw SAP-release moet upgraden of wilt overschakelen naar een ander besturingssysteem.

Eerste stappen voor het plannen van een implementatie

De eerste stap in de implementatieplanning is niet om te zoeken naar VM's die beschikbaar zijn om SAP-toepassingen uit te voeren.

De eerste stappen voor het plannen van een implementatie zijn om te werken met compliance - en beveiligingsteams in uw organisatie om te bepalen wat de grensvoorwaarden zijn voor het implementeren van welk type SAP-werkbelasting of bedrijfsproces in een openbare cloud. Het proces kan tijdrovend zijn, maar het is essentieel om het proces te voltooien.

Als uw organisatie al software in Azure heeft geïmplementeerd, is het proces mogelijk eenvoudig. Als uw bedrijf meer aan het begin van het traject staat, kunnen er grotere discussies nodig zijn om de grensvoorwaarden, beveiligingsvoorwaarden en bedrijfsarchitectuur te bepalen waarmee bepaalde SAP-gegevens en SAP-bedrijfsprocessen kunnen worden gehost in een openbare cloud.

Plannen voor naleving

Zie Microsoft-nalevingsaanbiedingen voor een lijst met Microsoft-complianceaanbiedingen die u kunnen helpen bij het plannen van uw nalevingsbehoeften.

Beveiliging plannen

Zie het overzicht van Azure-versleuteling en beveiliging voor uw SAP-landschap voor informatie over SAP-specifieke beveiligingsproblemen, zoals gegevensversleuteling voor data-at-rest of andere versleuteling in een Azure-service.

Azure-resources ordenen

Als u deze taak nog niet hebt uitgevoerd, plant u samen met de beveiligings- en nalevingsbeoordeling hoe u uw Azure-resources organiseert. Het proces omvat het nemen van beslissingen over:

  • Een naamconventie die u voor elke Azure-resource gebruikt, zoals voor VM's en resourcegroepen.
  • Een abonnements- en beheergroepontwerp voor uw SAP-workload, zoals of er per workload, per implementatielaag of voor elke bedrijfseenheid meerdere abonnementen moeten worden gemaakt.
  • Bedrijfsbreed gebruik van Azure Policy voor abonnementen en beheergroepen.

Om u te helpen bij het nemen van de juiste beslissingen, worden veel details van bedrijfsarchitectuur beschreven in het Azure Cloud Adoption Framework.

Onderschat de initiële fase van het project niet in uw planning. Alleen wanneer u overeenkomsten en regels hebt voor naleving, beveiliging en Azure-resourceorganisatie, moet u uw implementatieplanning vooruitgaan.

De volgende stappen zijn het plannen van geografische plaatsing en de netwerkarchitectuur die u in Azure implementeert.

Geografische gebieden en regio's voor Azure

Azure-services zijn beschikbaar in afzonderlijke Azure-regio's. Een Azure-regio is een verzameling datacenters. De datacenters bevatten de hardware en infrastructuur die de Azure-services hosten en uitvoeren die beschikbaar zijn in de regio. De infrastructuur bevat een groot aantal knooppunten die fungeren als rekenknooppunten of opslagknooppunten, of die netwerkfunctionaliteit uitvoeren.

Zie Azure-geografische gebieden voor een lijst met Azure-regio's. Zie de globale Infrastructuur van Azure voor een interactieve kaart.

Niet alle Azure-regio's bieden dezelfde services. Afhankelijk van het SAP-product dat u wilt uitvoeren, uw groottevereisten en het besturingssysteem en DBMS dat u nodig hebt, is het mogelijk dat een bepaalde regio niet de VM-typen biedt die vereist zijn voor uw scenario. Als u bijvoorbeeld SAP HANA uitvoert, hebt u meestal VM's van de verschillende VM-serie M-serie nodig. Deze VM-families worden alleen geïmplementeerd in een subset van Azure-regio's.

Wanneer u begint te plannen en na te denken over welke regio's u wilt kiezen als primaire regio en uiteindelijk secundaire regio, moet u onderzoeken of de services die u nodig hebt voor uw scenario's beschikbaar zijn in de regio's die u overweegt. U kunt precies zien welke VM-typen, Azure-opslagtypen en andere Azure-services beschikbaar zijn in elke regio in Producten die per regio beschikbaar zijn.

Gekoppelde Azure-regio's

In een gekoppelde Azure-regio wordt replicatie van bepaalde gegevens standaard ingeschakeld tussen de twee regio's. Zie replicatie tussen regio's in Azure: Bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie.

Gegevensreplicatie in een regiopaar is gekoppeld aan typen Azure-opslag die u kunt configureren om te repliceren naar een gekoppelde regio. Zie Opslagredundantie in een secundaire regio voor meer informatie.

De opslagtypen die ondersteuning bieden voor gekoppelde regiogegevensreplicatie zijn opslagtypen die niet geschikt zijn voor SAP-onderdelen en een DBMS-workload. De bruikbaarheid van de Azure-opslagreplicatie is beperkt tot Azure Blob Storage (voor back-updoeleinden), bestandsshares en volumes en andere scenario's voor opslag met hoge latentie.

Wanneer u controleert op gekoppelde regio's en de services die u wilt gebruiken in uw primaire of secundaire regio's, is het mogelijk dat de Azure-services of VM-typen die u in uw primaire regio wilt gebruiken, niet beschikbaar zijn in de gekoppelde regio die u als secundaire regio wilt gebruiken. U kunt ook bepalen dat een gekoppelde Azure-regio vanwege redenen van gegevensnaleving niet acceptabel is voor uw scenario. Voor deze scenario's moet u een niet-geairede regio gebruiken als secundaire regio of regio voor herstel na noodgevallen en moet u zelf een deel van de gegevensreplicatie instellen.

Beschikbaarheidszones

Veel Azure-regio's gebruiken beschikbaarheidszones om locaties binnen een Azure-regio fysiek te scheiden. Elke beschikbaarheidszone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Een voorbeeld van het gebruik van een beschikbaarheidszone om de tolerantie te verbeteren, is het implementeren van twee VM's in twee afzonderlijke beschikbaarheidszones in Azure. Een ander voorbeeld is het implementeren van een framework voor hoge beschikbaarheid voor uw SAP DBMS-systeem in één beschikbaarheidszone en het implementeren van SAP (A)SCS in een andere beschikbaarheidszone, zodat u de beste SLA in Azure krijgt.

Raadpleeg de nieuwste versie van SLA's voor virtuele machines voor meer informatie over VM-SLA's in Azure. Omdat Azure-regio's zich snel ontwikkelen en uitbreiden, ontwikkelt de topologie van de Azure-regio's, het aantal fysieke datacenters, de afstand tussen datacenters en de afstand tussen Azure-beschikbaarheidszones zich. Netwerklatentie verandert naarmate de infrastructuur verandert.

Volg de richtlijnen in SAP-workloadconfiguraties met Azure-beschikbaarheidszones wanneer u een regio kiest met beschikbaarheidszones. Bepaal ook welk zonegebonden implementatiemodel het meest geschikt is voor uw vereisten, de regio die u kiest en uw workload.

Foutdomeinen

Foutdomeinen vertegenwoordigen een fysieke eenheid van fouten. Een foutdomein is nauw gerelateerd aan de fysieke infrastructuur die zich in datacenters bevindt. Hoewel een fysieke blade of rek kan worden beschouwd als een foutdomein, is er geen directe een-op-een-toewijzing tussen een fysiek computerelement en een foutdomein.

Wanneer u meerdere VM's implementeert als onderdeel van één SAP-systeem, kunt u indirect invloed hebben op de Azure-infrastructuurcontroller om uw VM's te implementeren in verschillende foutdomeinen, zodat u aan de vereisten voor beschikbaarheids-SLA's kunt voldoen. U hebt echter geen directe controle over de distributie van foutdomeinen via een Azure-schaaleenheid (een verzameling van honderden rekenknooppunten of opslagknooppunten en netwerken) of de toewijzing van VM's aan een specifiek foutdomein. Als u de Azure-infrastructuurcontroller wilt om een set virtuele machines te implementeren via verschillende foutdomeinen, moet u een Azure-beschikbaarheidsset toewijzen aan de VM's tijdens de implementatie. Zie Beschikbaarheidssets voor meer informatie.

Updatedomeinen

Updatedomeinen vertegenwoordigen een logische eenheid waarmee wordt ingesteld hoe een VIRTUELE machine in een SAP-systeem dat uit meerdere VM's bestaat, wordt bijgewerkt. Wanneer een platformupdate plaatsvindt, doorloopt Azure het proces van het bijwerken van deze updatedomeinen één voor één. Door VM's tijdens de implementatie over verschillende updatedomeinen te spreiden, kunt u uw SAP-systeem beschermen tegen mogelijke downtime. Net als bij foutdomeinen is een Azure-schaaleenheid onderverdeeld in meerdere updatedomeinen. Als u de Azure-infrastructuurcontroller wilt manoeuvreren om een set vm's te implementeren via verschillende updatedomeinen, moet u een Azure-beschikbaarheidsset toewijzen aan de VM's tijdens de implementatie. Zie Beschikbaarheidssets voor meer informatie.

Diagram that depicts update domains and failure domains.

Beschikbaarheidssets

Virtuele Azure-machines binnen één Azure-beschikbaarheidsset worden gedistribueerd door de Azure-infrastructuurcontroller over verschillende foutdomeinen. De distributie over verschillende foutdomeinen is om te voorkomen dat alle VM's van een SAP-systeem worden afgesloten tijdens onderhoud van de infrastructuur of als er een fout optreedt in één foutdomein. VM's maken standaard geen deel uit van een beschikbaarheidsset. U kunt een VIRTUELE machine alleen toevoegen in een beschikbaarheidsset tijdens de implementatie of wanneer een VIRTUELE machine opnieuw wordt geïmplementeerd.

Zie Azure-beschikbaarheidssets voor meer informatie over Azure-beschikbaarheidssets en hoe beschikbaarheidssets betrekking hebben op foutdomeinen.

Belangrijk

Beschikbaarheidszones en beschikbaarheidssets in Azure sluiten elkaar wederzijds uit. U kunt meerdere VM's implementeren in een specifieke beschikbaarheidszone of in een beschikbaarheidsset. Maar niet zowel de beschikbaarheidszone als de beschikbaarheidsset kunnen worden toegewezen aan een virtuele machine.

U kunt beschikbaarheidssets en beschikbaarheidszones combineren als u nabijheidsplaatsingsgroepen gebruikt.

Wanneer u beschikbaarheidssets definieert en verschillende VM's van verschillende VM-families in één beschikbaarheidsset probeert te combineren, kunnen er problemen optreden waardoor u geen specifiek VM-type in een beschikbaarheidsset kunt opnemen. De reden hiervoor is dat de beschikbaarheidsset is gebonden aan een schaaleenheid die een specifiek type rekenhost bevat. Een specifiek type rekenhost kan alleen worden uitgevoerd op bepaalde typen VM-families.

U maakt bijvoorbeeld een beschikbaarheidsset en implementeert de eerste virtuele machine in de beschikbaarheidsset. De eerste VM die u aan de beschikbaarheidsset toevoegt, bevindt zich in de Edsv5-VM-serie. Wanneer u een tweede VIRTUELE machine probeert te implementeren, mislukt deze implementatie, een VM die zich in de M-serie. De reden hiervoor is dat Edsv5-familie-VM's niet worden uitgevoerd op dezelfde hosthardware als de VM's in de M-familie.

Hetzelfde probleem kan optreden als u de grootte van VM's wijzigt. Als u probeert een virtuele machine uit de Edsv5-serie te verplaatsen en naar een VM-type in de M-serie te gaan, mislukt de implementatie. Als u het formaat wijzigt in een VM-familie die niet kan worden gehost op dezelfde hosthardware, moet u alle VM's die zich in uw beschikbaarheidsset bevinden, afsluiten en de grootte ervan wijzigen zodat ze allemaal kunnen worden uitgevoerd op het andere hostcomputertype. Zie Sla's voor virtuele machines die zijn geïmplementeerd in een beschikbaarheidsset voor meer informatie over SLA's van VM's.

Virtuele-machineschaalsets met flexibele indeling

Virtuele-machineschaalsets met flexibele indeling bieden een logische groepering van door het platform beheerde virtuele machines. U hebt een optie om een schaalset te maken binnen een regio of deze over meerdere beschikbaarheidszones te strekken. Bij het maken wordt de flexibele schaalset binnen een regio met platformFaultDomainCount>1 (FD>1) gedistribueerd over het opgegeven aantal foutdomeinen in dezelfde regio. Aan de andere kant, het maken van de flexibele schaalset in beschikbaarheidszones met platformFaultDomainCount=1 (FD=1) distribueert VM's over de opgegeven zone en de schaalset distribueert ook VM's over verschillende foutdomeinen binnen de zone op basis van de beste inspanning.

Voor SAP-werkbelasting wordt alleen flexibele schaalset met FD=1 ondersteund. Het voordeel van het gebruik van flexibele schaalsets met FD=1 voor zoneoverschrijdende implementatie, in plaats van traditionele implementatie van beschikbaarheidszones is dat de VM's die met de schaalset zijn geïmplementeerd, op een optimale manier over verschillende foutdomeinen binnen de zone worden verdeeld. Zie de flexibele implementatiehandleiding voor virtuele-machineschaal voor meer informatie over de implementatie van SAP-werkbelastingen met een schaalset.

Bij het implementeren van een SAP-workload met hoge beschikbaarheid in Azure is het belangrijk om rekening te houden met de verschillende beschikbare implementatietypen en hoe ze kunnen worden toegepast in verschillende Azure-regio's (zoals in meerdere zones, in één zone of in een regio zonder zones). Zie Implementatieopties voor hoge beschikbaarheid voor SAP-werkbelasting voor meer informatie.

Fooi

Momenteel is er geen directe manier om SAP-werkbelasting te migreren die is geïmplementeerd in beschikbaarheidssets of beschikbaarheidszones om flexibel te schalen met FD=1. Als u de overstap wilt maken, moet u de VIRTUELE machine en schijf opnieuw maken met zonebeperkingen van bestaande resources. Een opensource-project bevat PowerShell-functies die u als voorbeeld kunt gebruiken om een VM te wijzigen die is geïmplementeerd in een beschikbaarheidsset of beschikbaarheidszone naar flexibele schaalset met FD=1. Een blogbericht laat zien hoe u een HA- of niet-HA SAP-systeem wijzigt dat is geïmplementeerd in een beschikbaarheidsset of beschikbaarheidszone naar flexibele schaalset met FD=1.

Nabijheidsplaatsingsgroepen

Netwerklatentie tussen afzonderlijke SAP-VM's kan aanzienlijke gevolgen hebben voor de prestaties. De retourtijd van het netwerk tussen SAP-toepassingsservers en dbMS kan met name aanzienlijke gevolgen hebben voor zakelijke toepassingen. Optimaal bevinden alle rekenelementen die uw SAP-VM's uitvoeren zich zo dicht mogelijk. Deze optie is niet mogelijk in elke combinatie en Azure weet mogelijk niet welke VM's u bij elkaar wilt houden. In de meeste situaties en regio's voldoet de standaardplaatsing aan de latentievereisten voor netwerkrondes.

Wanneer standaardplaatsing niet voldoet aan de vereisten voor netwerkrondes binnen een SAP-systeem, kunnen nabijheidsplaatsingsgroepen aan deze behoefte voldoen. U kunt nabijheidsplaatsingsgroepen gebruiken met de locatiebeperkingen van de Azure-regio, de beschikbaarheidszone en de beschikbaarheidsset om de tolerantie te vergroten. Met een nabijheidsplaatsingsgroep is het mogelijk om zowel de beschikbaarheidszone als de beschikbaarheidsset te combineren en verschillende update- en foutdomeinen in te stellen. Een nabijheidsplaatsingsgroep mag slechts één SAP-systeem bevatten.

Hoewel implementatie in een nabijheidsplaatsingsgroep kan resulteren in de meest latentie geoptimaliseerde plaatsing, heeft implementatie met behulp van een nabijheidsplaatsingsgroep ook nadelen. Sommige VM-families kunnen niet worden gecombineerd in één nabijheidsplaatsingsgroep of u ondervindt problemen als u het formaat tussen VM-families wijzigt. De beperkingen van VM-families, -regio's en beschikbaarheidszones bieden mogelijk geen ondersteuning voor colocatie. Zie Scenario's voor nabijheidsplaatsingsgroepen voor meer informatie en voor meer informatie over de voordelen en potentiële uitdagingen van het gebruik van een nabijheidsplaatsingsgroep.

VM's die geen nabijheidsplaatsingsgroepen gebruiken, moeten de standaardimplementatiemethode zijn in de meeste situaties voor SAP-systemen. Deze standaardwaarde geldt met name voor zonegebonden implementaties (één beschikbaarheidszone) en cross-zoneele implementaties (VM's die worden gedistribueerd tussen twee beschikbaarheidszones) van een SAP-systeem. Het gebruik van nabijheidsplaatsingsgroepen moet worden beperkt tot SAP-systemen en Azure-regio's, indien vereist om prestatieredenen.

Azure-netwerken

Azure heeft een netwerkinfrastructuur die is toegewezen aan alle scenario's die u mogelijk wilt implementeren in een SAP-implementatie. In Azure hebt u de volgende mogelijkheden:

  • Toegang tot Azure-services en toegang tot specifieke poorten in VM's die toepassingen gebruiken.
  • Directe toegang tot VM's via Secure Shell (SSH) of Windows Remote Desktop (RDP) voor beheer en beheer.
  • Interne communicatie en naamomzetting tussen VM's en Azure-services.
  • On-premises connectiviteit tussen een on-premises netwerk en Azure-netwerken.
  • Communicatie tussen services die zijn geïmplementeerd in verschillende Azure-regio's.

Zie Azure Virtual Network voor gedetailleerde informatie over netwerken.

Het ontwerpen van netwerken is meestal de eerste technische activiteit die u uitvoert wanneer u implementeert in Azure. Het ondersteunen van een centrale bedrijfsarchitectuur zoals SAP maakt vaak deel uit van de algemene netwerkvereisten. In de planningsfase moet u de voorgestelde netwerkarchitectuur zo gedetailleerd mogelijk documenteer. Als u later een wijziging aanbrengt, zoals het wijzigen van een subnetnetwerkadres, moet u geïmplementeerde resources mogelijk verplaatsen of verwijderen.

Virtuele netwerken van Azure

Een virtueel netwerk is een fundamentele bouwsteen voor uw privénetwerk in Azure. U kunt het adresbereik van het netwerk definiëren en het bereik scheiden in netwerksubnetten. Een netwerksubnet kan beschikbaar zijn voor een SAP-VM die kan worden gebruikt of kan worden toegewezen aan een specifieke service of doel. Voor sommige Azure-services, zoals Azure Virtual Network en Azure-toepassing Gateway, is een toegewezen subnet vereist.

Een virtueel netwerk fungeert als een netwerkgrens. Een deel van het ontwerp dat nodig is wanneer u uw implementatie plant, is het definiëren van het adresbereiken van het virtuele netwerk, subnetten en privénetwerk. U kunt de toewijzing van het virtuele netwerk niet wijzigen voor resources zoals netwerkinterfacekaarten (NIC's) voor VM's nadat de VM's zijn geïmplementeerd. Als u een wijziging aanbrengt in een virtueel netwerk of in een subnetadresbereik , moet u mogelijk alle geïmplementeerde resources naar een ander subnet verplaatsen.

Uw netwerkontwerp moet voldoen aan verschillende vereisten voor SAP-implementatie:

  • Er worden geen virtuele netwerkapparaten, zoals een firewall, in het communicatiepad geplaatst tussen de SAP-toepassing en de DBMS-laag van SAP-producten via de SAP-kernel, zoals S/4HANA of SAP NetWeaver.
  • Netwerkrouteringsbeperkingen worden afgedwongen door netwerkbeveiligingsgroepen (NSG's) op subnetniveau. Groeps-IP's van VM's in toepassingsbeveiligingsgroepen (ASG's) die worden onderhouden in de NSG-regels en die rol-, laag- en SID-groeperingen van machtigingen bieden.
  • SAP-toepassings- en database-VM's worden uitgevoerd in hetzelfde virtuele netwerk, binnen dezelfde of verschillende subnetten van één virtueel netwerk. Gebruik verschillende subnetten voor toepassings- en database-VM's. U kunt ook toegewezen toepassing en DBMS ASG's gebruiken om regels te groeperen die van toepassing zijn op elk workloadtype binnen hetzelfde subnet.
  • Versneld netwerken is ingeschakeld op alle netwerkkaarten van alle VM's voor SAP-workloads, waar technisch mogelijk.
  • Zorg voor beveiligde toegang voor afhankelijkheid van centrale services, waaronder voor naamomzetting (DNS), identiteitsbeheer (Windows Server Active Directory-domeinen/Microsoft Entra-id) en beheerderstoegang.
  • Geef indien nodig toegang tot en door openbare eindpunten. Voorbeelden zijn onder andere voor Azure-beheer voor ClusterLabs Pacemaker-bewerkingen met hoge beschikbaarheid of voor Azure-services zoals Azure Backup.
  • Gebruik alleen meerdere NIC's als ze nodig zijn om aangewezen subnetten te maken die hun eigen routes en NSG-regels hebben.

Zie de volgende artikelen voor voorbeelden van netwerkarchitectuur voor SAP-implementatie:

Overwegingen voor virtuele netwerken

Sommige configuraties voor virtuele netwerken hebben specifieke overwegingen om rekening mee te houden.

  • Het configureren van virtuele netwerkapparaten in het communicatiepad tussen de SAP-toepassingslaag en de DBMS-laag van SAP-onderdelen met behulp van de SAP-kernel, zoals S/4HANA of SAP NetWeaver, wordt niet ondersteund.

    Virtuele netwerkapparaten in communicatiepaden kunnen eenvoudig de netwerklatentie tussen twee communicatiepartners verdubbelen. Ze kunnen ook de doorvoer beperken in kritieke paden tussen de SAP-toepassingslaag en de DBMS-laag. In sommige scenario's kunnen virtuele netwerkapparaten ertoe leiden dat Pacemaker Linux-clusters mislukken.

    Het communicatiepad tussen de SAP-toepassingslaag en de DBMS-laag moet een direct pad zijn. De beperking bevat geen ASG- en NSG-regels als de ASG- en NSG-regels een direct communicatiepad toestaan.

    Andere scenario's waarin virtuele netwerkapparaten niet worden ondersteund, zijn:

  • Het scheiden van de SAP-toepassingslaag en de DBMS-laag in verschillende virtuele Azure-netwerken wordt niet ondersteund. U wordt aangeraden de SAP-toepassingslaag en de DBMS-laag te scheiden met behulp van subnetten binnen hetzelfde virtuele Azure-netwerk in plaats van door verschillende virtuele Netwerken van Azure te gebruiken.

    Als u een niet-ondersteund scenario instelt dat twee SAP-systeemlagen in verschillende virtuele netwerken scheidt, moeten de twee virtuele netwerken wordengekoppeld.

    Netwerkverkeer tussen twee gekoppelde virtuele Azure-netwerken is onderhevig aan overdrachtskosten. Elke dag wordt een enorme hoeveelheid gegevens die bestaat uit veel terabytes uitgewisseld tussen de SAP-toepassingslaag en de DBMS-laag. Er kunnen aanzienlijke kosten in rekening worden gebracht als de SAP-toepassingslaag en de DBMS-laag worden gescheiden tussen twee gekoppelde virtuele Azure-netwerken.

Naamomzetting en domeinservices

Het omzetten van hostnaam naar IP-adres via DNS is vaak een cruciaal element voor SAP-netwerken. U hebt veel opties voor het configureren van naam- en IP-omzetting in Azure.

Vaak heeft een onderneming een centrale DNS-oplossing die deel uitmaakt van de algehele architectuur. Verschillende opties voor het implementeren van naamomzetting in Azure, in plaats van door uw eigen DNS-servers in te stellen, worden beschreven in naamomzetting voor resources in virtuele Azure-netwerken.

Net als bij DNS-services is er mogelijk een vereiste dat Windows Server Active Directory toegankelijk is voor de SAP-VM's of -services.

IP-adrestoewijzing

Een IP-adres voor een NIC blijft geclaimd en gebruikt gedurende het bestaan van de NIC van een virtuele machine. De regel is van toepassing op zowel dynamische als statische IP-toewijzing. Het blijft waar of de VIRTUELE machine wordt uitgevoerd of wordt afgesloten. Dynamische IP-toewijzing wordt vrijgegeven als de NIC wordt verwijderd, als het subnet wordt gewijzigd of als de toewijzingsmethode wordt gewijzigd in statisch.

Het is mogelijk om vaste IP-adressen toe te wijzen aan VM's binnen een virtueel Azure-netwerk. IP-adressen worden vaak opnieuw toegewezen voor SAP-systemen die afhankelijk zijn van externe DNS-servers en statische vermeldingen. Het IP-adres blijft toegewezen, totdat de VM en de bijbehorende NIC worden verwijderd of totdat het IP-adres niet is toegewezen. U moet rekening houden met het totale aantal virtuele machines (uitgevoerd en gestopt) wanneer u het bereik van IP-adressen voor het virtuele netwerk definieert.

Zie Een virtuele machine met een statisch privé-IP-adres maken voor meer informatie.

Notitie

U moet kiezen tussen de toewijzing van statische en dynamische IP-adressen voor Virtuele Azure-machines en hun NIC's. Het gastbesturingssysteem van de VIRTUELE machine verkrijgt het IP-adres dat aan de NIC is toegewezen wanneer de VM wordt opgestart. U mag geen statische IP-adressen in het gastbesturingssysteem toewijzen aan een NIC. Sommige Azure-services zoals Azure Backup zijn afhankelijk van het feit dat ten minste de primaire NIC is ingesteld op DHCP en niet op statische IP-adressen in het besturingssysteem. Zie Problemen met back-ups van Azure-VM's oplossen voor meer informatie.

Secundaire IP-adressen voor SAP-hostnaamvirtualisatie

Aan de NIC van elke Azure-VM kunnen meerdere IP-adressen zijn toegewezen. Een secundair IP-adres kan worden gebruikt voor een virtuele SAP-hostnaam, die is toegewezen aan een DNS A-record of DNS PTR-record. Er moet een secundair IP-adres worden toegewezen aan de IP-configuratie van de Azure NIC. Een secundair IP-adres moet ook statisch worden geconfigureerd binnen het besturingssysteem, omdat secundaire IP-adressen vaak niet worden toegewezen via DHCP. Elk secundair IP-adres moet afkomstig zijn van hetzelfde subnet waaraan de NIC is gebonden. Een secundair IP-adres kan worden toegevoegd aan en verwijderd uit een Azure-NIC zonder de VM te stoppen of de toewijzing ervan ongedaan te maken. Als u het primaire IP-adres van een NIC wilt toevoegen of verwijderen, moet de toewijzing van de VIRTUELE machine ongedaan worden gemaakt.

Notitie

Bij secundaire IP-configuraties wordt het zwevende IP-adres van de Azure Load Balancer niet ondersteund. De Azure Load Balancer wordt gebruikt door SAP-architecturen met hoge beschikbaarheid met Pacemaker-clusters. In dit scenario schakelt de load balancer de namen van de virtuele SAP-host in. Zie SAP Note 962955 voor algemene richtlijnen over het gebruik van namen van virtuele hosts.

Azure Load Balancer met VM's waarop SAP wordt uitgevoerd

Een load balancer wordt doorgaans gebruikt in architecturen met hoge beschikbaarheid om zwevende IP-adressen te bieden tussen actieve en passieve clusterknooppunten. U kunt ook een load balancer voor één virtuele machine gebruiken om een virtueel IP-adres voor een virtuele SAP-hostnaam te bewaren. Het gebruik van een load balancer voor één virtuele machine is een alternatief voor het gebruik van een secundair IP-adres op een NIC of het gebruik van meerdere NIC's in hetzelfde subnet.

De standaard load balancer wijzigt het standaardpad voor uitgaande toegang , omdat de architectuur standaard beveiligd is. VM's die zich achter een standard load balancer bevinden, kunnen mogelijk niet langer dezelfde openbare eindpunten bereiken. Enkele voorbeelden zijn een eindpunt voor een opslagplaats voor besturingssysteemupdates of een openbaar eindpunt van Azure-services. Zie Openbare eindpuntconnectiviteit voor VM's met behulp van de Standaard load balancer van Azure voor opties voor uitgaande connectiviteit.

Fooi

De basic load balancer mag niet worden gebruikt met een SAP-architectuur in Azure. De basic load balancer is gepland om buiten gebruik te worden gesteld.

Meerdere vNIC's per VM

U kunt meerdere virtuele netwerkinterfacekaarten (vNIC's) definiëren voor een Azure-VM, waarbij elke vNIC is toegewezen aan elk subnet in hetzelfde virtuele netwerk als de primaire vNIC. Met de mogelijkheid om meerdere vNIC's te hebben, kunt u zo nodig netwerkverkeersscheiding instellen. Clientverkeer wordt bijvoorbeeld gerouteerd via de primaire vNIC en sommige beheerders- of back-endverkeer wordt gerouteerd via een tweede vNIC. Afhankelijk van het besturingssysteem en de installatiekopieën die u gebruikt, moeten verkeersroutes voor NIC's binnen het besturingssysteem mogelijk worden ingesteld voor de juiste routering.

Het type en de grootte van een VIRTUELE machine bepaalt hoeveel vNIC's een VIRTUELE machine kan hebben toegewezen. Zie Meerdere IP-adressen toewijzen aan VM's met behulp van Azure Portal voor meer informatie over functionaliteit en beperkingen.

Als u vNIC's toevoegt aan een virtuele machine, wordt de beschikbare netwerkbandbreedte niet verhoogd. Alle netwerkinterfaces delen dezelfde bandbreedte. U wordt aangeraden alleen meerdere NIC's te gebruiken als VM's toegang nodig hebben tot privésubnetten. We raden een ontwerppatroon aan dat afhankelijk is van NSG-functionaliteit en die de netwerk- en subnetvereisten vereenvoudigt. Het ontwerp moet zo weinig mogelijk netwerkinterfaces gebruiken en optimaal één netwerkinterface gebruiken. Een uitzondering is uitschalen van HANA, waarbij een secundaire vNIC is vereist voor het interne HANA-netwerk.

Waarschuwing

Als u meerdere vNIC's op een virtuele machine gebruikt, raden we u aan om het subnet van een primaire NIC te gebruiken voor het afhandelen van gebruikersnetwerkverkeer.

Versneld netwerken

Als u de netwerklatentie tussen Azure-VM's verder wilt verminderen, raden we u aan te bevestigen dat versnelde Azure-netwerken zijn ingeschakeld op elke VIRTUELE machine waarop een SAP-workload wordt uitgevoerd. Hoewel versneld netwerken standaard is ingeschakeld voor nieuwe VM's, moet u volgens de controlelijst voor implementatie de status controleren. De voordelen van versneld netwerken zijn aanzienlijk verbeterde netwerkprestaties en latentie. Gebruik deze wanneer u Azure-VM's implementeert voor SAP-workloads op alle ondersteunde VM's, met name voor de SAP-toepassingslaag en de SAP DBMS-laag. De gekoppelde documentatie bevat ondersteuningsafhankelijkheden voor besturingssysteemversies en VM-exemplaren.

On-premises connectiviteit

SAP-implementatie in Azure gaat ervan uit dat een centrale, bedrijfsbrede netwerkarchitectuur en communicatiehub aanwezig zijn om on-premises connectiviteit mogelijk te maken. On-premises netwerkconnectiviteit is essentieel om gebruikers en toepassingen toegang te geven tot het SAP-landschap in Azure voor toegang tot andere centrale organisatieservices, zoals de centrale DNS- en domein- en patchbeheerinfrastructuur.

U hebt veel opties om on-premises connectiviteit te bieden voor uw SAP on Azure-implementatie. De netwerkimplementatie is meestal een sternetwerktopologie of een uitbreiding van de hub-spoke-topologie, een wereldwijd virtueel WAN.

Voor on-premises SAP-implementaties wordt u aangeraden een privéverbinding via Azure ExpressRoute te gebruiken. Voor kleinere SAP-workloads, externe regio's of kleinere kantoren is vpn on-premises connectiviteit beschikbaar. Het gebruik van ExpressRoute met een VPN-site-naar-site-verbinding als failoverpad is een mogelijke combinatie van beide services.

Uitgaande en binnenkomende internetverbinding

Uw SAP-landschap vereist connectiviteit met internet, of het nu gaat om het ontvangen van updates van de opslagplaats van het besturingssysteem, om een verbinding tot stand te brengen met de SAP SaaS-toepassingen op hun openbare eindpunten of om toegang te krijgen tot een Azure-service via het openbare eindpunt. Op dezelfde manier is het mogelijk dat u toegang moet verlenen aan uw clients voor SAP Fiori-toepassingen, met internetgebruikers die toegang hebben tot services die worden geleverd door uw SAP-landschap. Voor uw SAP-netwerkarchitectuur moet u het pad naar internet en voor binnenkomende aanvragen plannen.

Beveilig uw virtuele netwerk met behulp van NSG-regels, met behulp van netwerkservicetags voor bekende services en door routering en IP-adressering tot stand te brengen voor uw firewall of ander virtueel netwerkapparaat. Al deze taken of overwegingen maken deel uit van de architectuur. Resources in privénetwerken moeten worden beveiligd door firewalls van netwerklaag 4 en Laag 7.

Communicatiepaden met internet zijn de focus van een architectuur met best practices.

Azure-VM's voor SAP-workloads

Sommige Azure VM-families zijn met name geschikt voor SAP-workloads en nog specifieker voor een SAP HANA-workload. De manier om het juiste VM-type en de mogelijkheid te vinden om uw SAP-workload te ondersteunen, wordt beschreven in Welke SAP-software wordt ondersteund voor Azure-implementaties. Sap Note 1928533 bevat ook alle gecertificeerde Azure-VM's en hun prestatiemogelijkheden, zoals gemeten door de SAPS-benchmark (SAPS) (Application Performance Standard) en beperkingen, indien van toepassing. De VM-typen die zijn gecertificeerd voor een SAP-workload, maken geen gebruik van overinrichting voor CPU- en geheugenresources.

Naast het alleen bekijken van de selectie van ondersteunde VM-typen, moet u controleren of deze VM-typen beschikbaar zijn in een specifieke regio op basis van producten die per regio beschikbaar zijn. Minstens zo belangrijk is om te bepalen of de volgende mogelijkheden voor een VM passen bij uw scenario:

  • CPU- en geheugenbronnen
  • Bandbreedte voor invoer-/uitvoerbewerkingen per seconde (IOPS)
  • Netwerkmogelijkheden
  • Aantal schijven dat kan worden gekoppeld
  • Mogelijkheid om bepaalde Azure-opslagtypen te gebruiken

Zie Grootten voor virtuele machines in Azure voor informatie over een specifieke FM-familie en -type.

Prijsmodellen voor Virtuele Azure-machines

Voor een VM-prijsmodel kunt u kiezen welke optie u wilt gebruiken:

  • Een prijsmodel voor betalen per gebruik
  • Een gereserveerd of spaarplan van één jaar
  • Een gereserveerd of spaarplan van drie jaar
  • Een spot-prijsmodel

Zie prijzen voor virtuele machines voor gedetailleerde informatie over vm-prijzen voor verschillende Azure-services, -besturingssystemen en -regio's.

Zie de volgende artikelen voor meer informatie over de prijzen en flexibiliteit van een-jaar- en driejarige spaarplannen en gereserveerde instanties:

Zie Azure Spot Virtual Machines voor meer informatie over spotprijzen.

Prijzen voor hetzelfde VM-type kunnen verschillen tussen Azure-regio's. Sommige klanten profiteren van de implementatie in een goedkopere Azure-regio, zodat informatie over prijzen per regio nuttig kan zijn tijdens het plannen.

Azure biedt ook de mogelijkheid om een toegewezen host te gebruiken. Met behulp van een toegewezen host hebt u meer controle over patchingcycli voor Azure-services. U kunt patching plannen om uw eigen planning en cycli te ondersteunen. Deze aanbieding is specifiek bedoeld voor klanten die een workload hebben die niet de normale cyclus van een workload volgt. Zie Toegewezen Azure-hosts voor meer informatie.

Het gebruik van een toegewezen Azure-host wordt ondersteund voor een SAP-workload. Verschillende SAP-klanten die meer controle willen hebben over patches en onderhoudsplannen voor infrastructuur, maken gebruik van toegewezen Azure-hosts. Zie Onderhoud voor virtuele machines in Azure voor meer informatie over hoe Microsoft de Azure-infrastructuur onderhoudt en patcht die als host fungeert voor VM's.

Besturingssysteem voor VM's

Wanneer u nieuwe VM's implementeert voor een SAP-landschap in Azure, is het belangrijk dat u het juiste besturingssysteem voor uw workload kiest om een SAP-systeem te installeren of te migreren. Azure biedt een grote selectie van installatiekopieën van besturingssystemen voor Linux en Windows en veel geschikte opties voor SAP-systemen. U kunt ook aangepaste afbeeldingen maken of uploaden vanuit uw on-premises omgeving, of u kunt afbeeldingen gebruiken of generaliseren vanuit galerieën met afbeeldingen.

Voor meer informatie over de beschikbare opties:

Plan indien nodig een infrastructuur voor het bijwerken van een besturingssysteem en de bijbehorende afhankelijkheden voor uw SAP-workload. Overweeg het gebruik van een faseringsomgeving voor opslagplaatsen om alle lagen van een SAP-landschap (sandbox, ontwikkeling, preproductie en productie) gesynchroniseerd te houden met dezelfde versies van patches en updates tijdens de updateperiode.

Vm's van generatie 1 en generatie 2

In Azure kunt u een VIRTUELE machine implementeren als generatie 1 of 2. Ondersteuning voor vm's van de tweede generatie in Azure bevat de Azure VM-families die u als generatie 2 kunt implementeren. Het artikel bevat ook functionele verschillen tussen vm's van de eerste en tweede generatie in Azure.

Wanneer u een VIRTUELE machine implementeert, bepaalt de installatiekopieën van het besturingssysteem die u kiest, of de virtuele machine een generatie 1 of een virtuele machine van de tweede generatie is. De nieuwste versies van alle installatiekopieën van besturingssystemen voor SAP die beschikbaar zijn in Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux en Windows of Oracle Enterprise Linux) zijn beschikbaar in zowel generatie 1 als generatie 2. Het is belangrijk om zorgvuldig een installatiekopieën te selecteren op basis van de beschrijving van de installatiekopieën om de juiste generatie vm's te implementeren. Op dezelfde manier kunt u aangepaste installatiekopieën van besturingssystemen maken als generatie 1 of 2, en deze hebben invloed op de generatie van de virtuele machine wanneer de VIRTUELE machine wordt geïmplementeerd.

Notitie

U wordt aangeraden vm's van de tweede generatie te gebruiken in al uw SAP-implementaties in Azure, ongeacht de VM-grootte. Alle nieuwste Azure-VM's voor SAP zijn geschikt voor de tweede generatie of zijn beperkt tot alleen generatie 2. Sommige VM-families ondersteunen momenteel alleen VM's van de tweede generatie. Sommige VM-families die binnenkort beschikbaar zijn, ondersteunen mogelijk alleen generatie 2.

U kunt bepalen of een virtuele machine generatie 1 of slechts generatie 2 is op basis van de geselecteerde installatiekopieën van het besturingssysteem. U kunt een bestaande VIRTUELE machine niet wijzigen van de ene generatie in de andere generatie.

Het wijzigen van een geïmplementeerde VM van generatie 1 naar generatie 2 is niet mogelijk in Azure. Als u de generatie van de VIRTUELE machine wilt wijzigen, moet u een nieuwe VIRTUELE machine implementeren die de gewenste generatie is en uw software opnieuw installeren op de nieuwe generatie van de VIRTUELE machine. Deze wijziging is alleen van invloed op de basis-VHD-installatiekopieën van de virtuele machine en heeft geen invloed op de gegevensschijven of gekoppelde NFS-shares (Network File System) of SMB-shares (Server Message Block). Gegevensschijven, NFS-shares of SMB-shares die oorspronkelijk zijn toegewezen aan een virtuele machine van de eerste generatie, kunnen worden gekoppeld aan een nieuwe VM van de tweede generatie.

Sommige VM-families, zoals de Mv2-serie, ondersteunen alleen generatie 2. Dezelfde vereiste geldt mogelijk voor nieuwe VM-families in de toekomst. In dat scenario kan het formaat van een bestaande VM van de 1e generatie niet worden gewijzigd om te werken met de nieuwe VM-serie. Naast de vereisten van de tweede generatie van het Azure-platform hebben uw SAP-onderdelen mogelijk vereisten die betrekking hebben op de generatie van een virtuele machine. Zie SAP Note 1928533 voor meer informatie over de vereisten van de tweede generatie voor de VM-familie die u kiest.

Prestatielimieten voor Virtuele Azure-machines

Als openbare cloud is Azure afhankelijk van het delen van infrastructuur op een beveiligde manier in het hele klantenbestand. Voor het inschakelen van schalen en capaciteit worden prestatielimieten gedefinieerd voor elke resource en service. Aan de rekenzijde van de Azure-infrastructuur is het belangrijk om rekening te houden met de limieten die zijn gedefinieerd voor elke VM-grootte.

Elke VIRTUELE machine heeft een ander quotum op schijf- en netwerkdoorvoer, het aantal schijven dat kan worden gekoppeld, of deze lokale tijdelijke opslag heeft met een eigen doorvoer- en IOPS-limiet, geheugengrootte en hoeveel vCPU's er beschikbaar zijn.

Notitie

Wanneer u beslissingen neemt over de VM-grootte voor een SAP-oplossing in Azure, moet u rekening houden met de prestatielimieten voor elke VM-grootte. De quota die in de documentatie worden beschreven, vertegenwoordigen de theoretische maximaal haalbare waarden. De prestatielimiet van IOPS per schijf kan worden bereikt met kleine I/O-waarden (invoer/uitvoer) (bijvoorbeeld 8 kB), maar kan niet worden bereikt met grote I/O-waarden (bijvoorbeeld 1 MB).

Net als vm's bestaan dezelfde prestatielimieten voor elk opslagtype voor een SAP-workload en voor alle andere Azure-services.

Houd rekening met de volgende factoren wanneer u van plan bent om VM's te gebruiken in uw SAP-implementatie en deze te gebruiken:

  • Begin met de vereisten voor geheugen en CPU. Scheid de SAPS-vereisten voor CPU-energie in het DBMS-onderdeel en de SAP-toepassingsonderdelen. Voor bestaande systemen kunnen de SAPS met betrekking tot de hardware die u vaak gebruikt, worden bepaald of geschat op basis van bestaande SAP Standard Application Benchmarks. Voltooi voor nieuw geïmplementeerde SAP-systemen een formaatoefening om de SAPS-vereisten voor het systeem te bepalen.

  • Voor bestaande systemen moeten de I/O-doorvoer en IOPS op de DBMS-server worden gemeten. Voor nieuwe systemen moet de grootteoefening voor het nieuwe systeem u ook een algemeen beeld geven van de I/O-vereisten aan de DBMS-zijde. Als u niet zeker weet, moet u uiteindelijk een proof of concept uitvoeren.

  • Vergelijk de SAPS-vereiste voor de DBMS-server met de SAPS die de verschillende VM-typen van Azure kunnen bieden. De informatie over de SAPS van de verschillende Typen Virtuele Azure-machines wordt beschreven in SAP Note 1928533. De focus moet eerst op de DBMS-VM liggen, omdat de databaselaag de laag is in een SAP NetWeaver-systeem dat niet in de meeste implementaties wordt uitgeschaald. De SAP-toepassingslaag kan daarentegen worden uitgeschaald. In afzonderlijke DBMS-handleidingen worden de aanbevolen opslagconfiguraties beschreven.

  • Uw bevindingen samenvatten voor:

    • Het aantal Azure-VM's dat u verwacht te gebruiken.
    • Afzonderlijke VM-familie- en VM-SKU's voor elke SAP-laag: DBMS, (A)SCS en toepassingsserver.
    • I/O-doorvoermetingen of vereisten voor berekende opslagcapaciteit.

HANA Large Instances-service

Azure biedt rekenmogelijkheden voor het uitvoeren van een grootschalige of uitschalende grote HANA-database op een speciaal aanbod met de naam SAP HANA in Azure Large Instances. Met deze aanbieding worden de VM's uitgebreid die beschikbaar zijn in Azure.

Notitie

De HANA Large Instances-service bevindt zich in de zonsondergangmodus en accepteert geen nieuwe klanten. Het leveren van eenheden voor bestaande HANA Large Instances-klanten is nog steeds mogelijk.

Opslag voor SAP in Azure

Azure-VM's maken gebruik van verschillende opslagopties voor persistentie. In eenvoudige termen kunnen de VM's worden onderverdeeld in permanente en tijdelijke of niet-permanente opslagtypen.

U kunt kiezen uit meerdere opslagopties voor SAP-workloads en voor specifieke SAP-onderdelen. Zie Azure Storage voor SAP-workloads voor meer informatie. Het artikel behandelt de opslagarchitectuur voor elk onderdeel van SAP: besturingssysteem, binaire toepassingsbestanden, configuratiebestanden, databasegegevens, logboek- en traceringsbestanden en bestandsinterfaces met andere toepassingen, ongeacht of deze zijn opgeslagen op schijf of worden geopend op bestandsshares.

Tijdelijke schijf op VM's

De meeste Virtuele Azure-machines voor SAP bieden een tijdelijke schijf die geen beheerde schijf is. Gebruik alleen een tijdelijke schijf voor betrouwbare gegevens. De gegevens op een tijdelijke schijf kunnen verloren gaan tijdens onvoorziene onderhoudsgebeurtenissen of tijdens het opnieuw implementeren van vm's. De prestatiekenmerken van de tijdelijke schijf maken ze ideaal voor wissel-/paginabestanden van het besturingssysteem.

Er moeten geen toepassings- of niet-betrouwbare besturingssysteemgegevens worden opgeslagen op een tijdelijke schijf. In Windows-omgevingen wordt het tijdelijke station doorgaans geopend als station D. In Linux-systemen is het koppelpunt vaak /dev/sdb-apparaat, /mnt of /mnt/resource.

Sommige VM's bieden geen tijdelijk station. Als u van plan bent om deze VM-grootten voor SAP te gebruiken, moet u mogelijk de grootte van de besturingssysteemschijf vergroten. Zie SAP Note 1928533 voor meer informatie. Voor VM's met een tijdelijke schijf krijgt u informatie over de tijdelijke schijfgrootte en de IOPS- en doorvoerlimieten voor elke VM-serie in Grootten voor virtuele machines in Azure.

U kunt het formaat niet rechtstreeks wijzigen tussen een VM-serie met tijdelijke schijven en een VM-serie die geen tijdelijke schijven heeft. Op dit moment mislukt de grootte tussen twee dergelijke VM-families. Een oplossing is het opnieuw maken van de virtuele machine die geen tijdelijke schijf in de nieuwe grootte heeft met behulp van een momentopname van de besturingssysteemschijf. Bewaar alle andere gegevensschijven en de netwerkinterface. Meer informatie over het wijzigen van de grootte van een VM-grootte met een lokale tijdelijke schijf naar een VM-grootte die dat niet doet.

Netwerkshares en -volumes voor SAP

SAP-systemen vereisen meestal een of meer netwerkbestandsshares. De bestandsshares zijn doorgaans een van de volgende opties:

  • Een SAP-transportmap (/usr/sap/trans of TRANSDIR).
  • SAP-volumes of gedeelde sapmnt - of saploc-volumes om meerdere toepassingsservers te implementeren.
  • Architectuurvolumes met hoge beschikbaarheid voor SAP (A)SCS, SAP ERS of een database (/hana/shared).
  • Bestandsinterfaces waarop toepassingen van derden worden uitgevoerd voor het importeren en exporteren van bestanden.

In deze scenario's wordt u aangeraden een Azure-service te gebruiken, zoals Azure Files of Azure NetApp Files. Als deze services niet beschikbaar zijn in de regio's die u kiest of als ze niet beschikbaar zijn voor uw oplossingsarchitectuur, zijn alternatieven voor het leveren van NFS- of SMB-bestandsshares van zelfbeheerde, VM-toepassingen of van services van derden. Zie SAP Note 2015553 over beperkingen voor SAP-ondersteuning als u services van derden gebruikt voor opslaglagen in een SAP-systeem in Azure.

Vanwege de vaak kritieke aard van netwerkshares en omdat ze vaak een single point of failure zijn in een ontwerp (voor hoge beschikbaarheid) of proces (voor de bestandsinterface), raden we u aan om te vertrouwen op elke systeemeigen Azure-service voor zijn eigen beschikbaarheid, SLA en tolerantie. In de planningsfase is het belangrijk om rekening te houden met deze factoren:

  • NFS- of SMB-shareontwerp, waaronder welke shares moeten worden gebruikt per SAP-systeem-id (SID), per liggend en per regio.
  • Subnetgrootte, inclusief de IP-vereiste voor privé-eindpunten of toegewezen subnetten voor services zoals Azure NetApp Files.
  • Netwerkroutering naar SAP-systemen en verbonden toepassingen.
  • Gebruik van een openbaar of privé-eindpunt voor Azure Files.

Zie Hoge beschikbaarheid voor informatie over vereisten en het gebruik van een NFS- of SMB-share in een scenario met hoge beschikbaarheid.

Notitie

Als u Azure Files gebruikt voor uw netwerkshares, raden we u aan een privé-eindpunt te gebruiken. In het onwaarschijnlijke geval van een zonefout wordt uw NFS-client automatisch omgeleid naar een gezonde zone. U hoeft de NFS- of SMB-shares niet opnieuw te koppelen op uw VM's.

Beveiliging voor uw SAP-landschap

Als u uw SAP-workload in Azure wilt beveiligen, moet u meerdere aspecten van beveiliging plannen:

  • Netwerksegmentatie en de beveiliging van elk subnet en elke netwerkinterface.
  • Versleuteling op elke laag binnen het SAP-landschap.
  • Identiteitsoplossing voor eindgebruikers- en beheerderstoegang en services voor eenmalige aanmelding.
  • Bewaking van bedreigingen en bewerkingen.

De onderwerpen in dit hoofdstuk zijn geen volledige lijst met alle beschikbare services, opties en alternatieven. Er worden verschillende aanbevolen procedures vermeld die in aanmerking moeten worden genomen voor alle SAP-implementaties in Azure. Er zijn andere aspecten die moeten worden behandeld, afhankelijk van de vereisten voor uw onderneming of workload. Zie de volgende resources voor algemene Azure-richtlijnen voor meer informatie over het beveiligingsontwerp:

Virtuele netwerken beveiligen met behulp van beveiligingsgroepen

Het plannen van uw SAP-landschap in Azure moet enige mate van netwerksegmentatie bevatten, waarbij virtuele netwerken en subnetten alleen zijn toegewezen aan SAP-workloads. Aanbevolen procedures voor subnetdefinities worden beschreven in Netwerken en in andere Azure-architectuurhandleidingen. We raden u aan NSG's te gebruiken met ASG's binnen NSG's om binnenkomende en uitgaande connectiviteit mogelijk te maken. Wanneer u ASG's ontwerpt, kan elke NIC op een VIRTUELE machine worden gekoppeld aan meerdere ASG's, zodat u verschillende groepen kunt maken. Maak bijvoorbeeld een ASG voor DBMS-VM's, die alle databaseservers in uw landschap bevat. Maak een andere ASG voor alle VM's (toepassing en DBMS) van één SAP-SID. Op deze manier kunt u één NSG-regel definiëren voor de algemene database-ASG en een andere, specifiekere regel alleen voor de SID-specifieke ASG.

NSG's beperken de prestaties niet met de regels die u definieert voor de NSG. Voor het bewaken van de verkeersstroom kunt u eventueel NSG-stroomlogboekregistratie activeren met logboeken die worden geëvalueerd door een SIEM (Information Event Management) of inbraakdetectiesysteem (IDS) van uw keuze om verdachte netwerkactiviteiten te bewaken en erop te reageren.

Fooi

Activeer NSG's alleen op subnetniveau. Hoewel NSG's kunnen worden geactiveerd op zowel het subnetniveau als het NIC-niveau, is activering op beide zeer vaak een belemmering bij het oplossen van problemen bij het analyseren van netwerkverkeersbeperkingen. Gebruik NSG's alleen op NIC-niveau in uitzonderlijke situaties en indien nodig.

Privé-eindpunten voor services

Veel Azure PaaS-services worden standaard geopend via een openbaar eindpunt. Hoewel het communicatie-eindpunt zich in het Azure-back-endnetwerk bevindt, wordt het eindpunt blootgesteld aan het openbare internet. Privé-eindpunten zijn een netwerkinterface in uw eigen virtuele privénetwerk. Via Azure Private Link projecteert het privé-eindpunt de service in uw virtuele netwerk. Geselecteerde PaaS-services worden vervolgens privé geopend via het IP-adres in uw netwerk. Afhankelijk van de configuratie kan de service mogelijk alleen worden ingesteld om te communiceren via een privé-eindpunt.

Het gebruik van een privé-eindpunt verhoogt de beveiliging tegen gegevenslekken en vereenvoudigt vaak de toegang vanuit on-premises en gekoppelde netwerken. In veel situaties wordt de netwerkroutering en het proces voor het openen van firewallpoorten, die vaak nodig zijn voor openbare eindpunten, vereenvoudigd. De resources bevinden zich al in uw netwerk, omdat ze worden geopend door een privé-eindpunt.

Zie Private Link beschikbare services voor meer informatie over welke Azure-services de mogelijkheid bieden om een privé-eindpunt te gebruiken. Voor NFS of SMB met Azure Files raden we u aan altijd privé-eindpunten te gebruiken voor SAP-workloads. Zie prijzen voor privé-eindpunten voor meer informatie over kosten die worden gemaakt met behulp van de service. Sommige Azure-services kunnen eventueel de kosten voor de service bevatten. Deze informatie is opgenomen in de prijsinformatie van een service.

Versleuteling

Afhankelijk van uw bedrijfsbeleid is versleuteling buiten de standaardopties in Azure mogelijk vereist voor uw SAP-workloads.

Versleuteling voor infrastructuurbronnen

Beheerde schijven en blobopslag in Azure worden standaard versleuteld met een door het platform beheerde sleutel (PMK). Bovendien wordt BYOK-versleuteling (Bring Your Own Key) voor beheerde schijven en blobopslag ondersteund voor SAP-workloads in Azure. Voor versleuteling van beheerde schijven kunt u kiezen uit verschillende opties, afhankelijk van de beveiligingsvereisten van uw bedrijf. Azure-versleutelingsopties zijn onder andere:

  • Versleuteling aan de opslagzijde (SSE) PMK (SSE-PMK)
  • Door de klant beheerde SSE-sleutel (SSE-CMK)
  • Dubbele versleuteling-at-rest
  • Versleuteling op basis van host

Zie een vergelijking van Azure-versleutelingsopties voor meer informatie, waaronder een beschrijving van Azure Disk Encryption.

Notitie

Gebruik momenteel geen versleuteling op basis van een host op een VM die zich in de M-serie VM-serie bevindt wanneer u met Linux werkt vanwege een mogelijke prestatiebeperking. Het gebruik van SSE-CMK-versleuteling voor beheerde schijven wordt niet beïnvloed door deze beperking.

Gebruik azure Disk Encryption niet voor SAP-implementaties op Linux-systemen. Azure Disk Encryption omvat versleuteling die wordt uitgevoerd binnen de SAP-VM's met behulp van CMK's uit Azure Key Vault. Voor Linux biedt Azure Disk Encryption geen ondersteuning voor de installatiekopieën van het besturingssysteem die worden gebruikt voor SAP-workloads. Azure Disk Encryption kan worden gebruikt op Windows-systemen met SAP-workloads, maar combineer Azure Disk Encryption niet met systeemeigen databaseversleuteling. U wordt aangeraden systeemeigen databaseversleuteling te gebruiken in plaats van Azure Disk Encryption. Zie de volgende sectie voor meer informatie.

Net als bij versleuteling van beheerde schijven is Azure Files-versleuteling at rest (SMB en NFS) beschikbaar met PMK's of CMK's.

Controleer voor SMB-netwerkshares zorgvuldig Azure Files en besturingssysteemafhankelijkheden met SMB-versies omdat de configuratie van invloed is op ondersteuning voor in-transit-versleuteling.

Belangrijk

Het belang van een zorgvuldig plan om de versleutelingssleutels op te slaan en te beveiligen als u door de klant beheerde versleuteling gebruikt, kan niet worden overschreven. Zonder versleutelingssleutels zijn versleutelde resources zoals schijven niet toegankelijk en kunnen ze leiden tot gegevensverlies. Overweeg zorgvuldig de sleutels en toegang tot de sleutels te beveiligen voor alleen bevoegde gebruikers of services.

Versleuteling voor SAP-onderdelen

Versleuteling op SAP-niveau kan worden onderverdeeld in twee lagen:

  • DBMS-versleuteling
  • Transportversleuteling

Voor DBMS-versleuteling ondersteunt elke database die wordt ondersteund voor een SAP NetWeaver- of SAP S/4HANA-implementatie systeemeigen versleuteling. Transparante databaseversleuteling is volledig onafhankelijk van alle infrastructuurversleuteling die aanwezig is in Azure. U kunt SSE en databaseversleuteling tegelijkertijd gebruiken. Wanneer u versleuteling gebruikt, is de locatie, opslag en bewaring van versleutelingssleutels van cruciaal belang. Verlies van versleutelingssleutels leidt tot gegevensverlies omdat u uw database niet kunt starten of herstellen.

Sommige databases hebben mogelijk geen databaseversleutelingsmethode of vereisen mogelijk geen toegewezen instelling om in te schakelen. Voor andere databases kunnen DBMS-back-ups impliciet worden versleuteld wanneer databaseversleuteling wordt geactiveerd. Raadpleeg de volgende SAP-documentatie voor meer informatie over het inschakelen en gebruiken van transparante databaseversleuteling:

Neem contact op met SAP of uw DBMS-leverancier voor ondersteuning over het inschakelen, gebruiken of oplossen van problemen met softwareversleuteling.

Belangrijk

Het kan niet worden overdreven hoe belangrijk het is om een zorgvuldig plan te hebben om uw versleutelingssleutels op te slaan en te beveiligen. Zonder versleutelingssleutels is de database of SAP-software mogelijk niet toegankelijk en verliest u mogelijk gegevens. Overweeg zorgvuldig hoe u de sleutels beveiligt. Toegang tot de sleutels alleen toestaan door bevoegde gebruikers of services.

Transport- of communicatieversleuteling kan worden toegepast op SQL Server-verbindingen tussen SAP-engines en de DBMS. Op dezelfde manier kunt u verbindingen versleutelen vanaf de SAP-presentatielaag (SAPGui-beveiligde netwerkverbinding of SNC) of een HTTPS-verbinding met een webfront-end. Raadpleeg de documentatie van de leverancier van toepassingen om versleuteling in te schakelen en te beheren tijdens overdracht.

Bedreigingsbewaking en -waarschuwingen

Als u oplossingen voor bedreigingsbewaking en waarschuwingen wilt implementeren en gebruiken, begint u met de architectuur van uw organisatie. Azure-services bieden beveiliging tegen bedreigingen en een beveiligingsweergave die u kunt opnemen in uw algemene SAP-implementatieplan. Microsoft Defender voor Cloud voldoet aan de vereisten voor beveiliging tegen bedreigingen. Defender voor Cloud maakt doorgaans deel uit van een algemeen governancemodel voor een volledige Azure-implementatie, niet alleen voor SAP-onderdelen.

Zie Microsoft Sentinel-oplossingen voor SAP-integratie voor meer informatie over SECURITY Information Event Management (SIEM) en SOAR-oplossingen (Security Orchestration Automated Response).

Beveiligingssoftware binnen SAP-VM's

SAP Note 2808515 voor Linux en SAP Note 106267 voor Windows beschrijven vereisten en aanbevolen procedures wanneer u virusscanners of beveiligingssoftware op SAP-servers gebruikt. U wordt aangeraden de SAP-aanbevelingen te volgen wanneer u SAP-onderdelen implementeert in Azure.

Hoge beschikbaarheid

SAP hoge beschikbaarheid in Azure heeft twee onderdelen:

  • Hoge beschikbaarheid van Azure-infrastructuur: hoge beschikbaarheid van Azure Compute (VM's), netwerk- en opslagservices en hoe ze de beschikbaarheid van SAP-toepassingen kunnen verhogen.

  • Hoge beschikbaarheid van SAP-toepassingen: hoe deze kan worden gecombineerd met de hoge beschikbaarheid van de Azure-infrastructuur met behulp van serviceherstel. Een voorbeeld waarin hoge beschikbaarheid wordt gebruikt in SAP-softwareonderdelen:

    • Een SAP (A)SCS- en SAP ERS-exemplaar
    • De databaseserver

Zie de volgende artikelen voor meer informatie over hoge beschikbaarheid voor SAP in Azure:

Pacemaker in Linux en Windows Server-failoverclustering zijn de enige frameworks voor hoge beschikbaarheid voor SAP-workloads die rechtstreeks worden ondersteund door Microsoft op Azure. Elk ander framework voor hoge beschikbaarheid wordt niet ondersteund door Microsoft en heeft ontwerp-, implementatiedetails en operationele ondersteuning van de leverancier nodig. Zie Ondersteunde scenario's voor SAP in Azure voor meer informatie.

Herstel na noodgeval

Sap-toepassingen behoren vaak tot de meest bedrijfskritieke processen in een onderneming. Op basis van hun belang en de tijd die nodig is om opnieuw operationeel te zijn na een onvoorziene onderbreking, moeten bcdr-scenario's (bedrijfscontinuïteit en herstel na noodgevallen) zorgvuldig worden gepland.

Zie Overzicht van herstel na noodgevallen en richtlijnen voor infrastructuur voor SAP-werkbelasting voor meer informatie over het oplossen van deze vereiste.

Backup

Als onderdeel van uw BCDR-strategie moet back-up voor uw SAP-workload een integraal onderdeel zijn van elke geplande implementatie. De back-upoplossing moet alle lagen van een SAP-oplossingsstack omvatten: VM, besturingssysteem, SAP-toepassingslaag, DBMS-laag en een gedeelde opslagoplossing. Back-up voor Azure-services die worden gebruikt door uw SAP-workload en voor andere cruciale resources, zoals versleuteling en toegangssleutels, moeten ook deel uitmaken van uw back-up- en BCDR-ontwerp.

Azure Backup biedt PaaS-oplossingen voor back-ups:

  • VM-configuratie, besturingssysteem en SAP-toepassingslaag (grootte wijzigen van gegevens op beheerde schijven) via Azure Backup voor VM. Controleer de ondersteuningsmatrix om te controleren of uw architectuur deze oplossing kan gebruiken.
  • SQL Server - en SAP HANA-databasegegevens en logboekback-up. Het bevat ondersteuning voor databasereplicatietechnologieën, zoals HANA-systeemreplicatie of SQL AlwaysOn, en ondersteuning voor meerdere regio's voor gekoppelde regio's.
  • Back-up van bestandsshares via Azure Files. Controleer de ondersteuning voor NFS of SMB en andere configuratiegegevens.

Als u Azure NetApp Files implementeert, zijn er ook back-upopties beschikbaar op volumeniveau, waaronder SAP HANA- en Oracle DBMS-integratie met een geplande back-up.

Azure Backup-oplossingen bieden een optie voor voorlopig verwijderen om schadelijke of onbedoelde verwijdering te voorkomen en gegevensverlies te voorkomen. Voorlopig verwijderen is ook beschikbaar voor bestandsshares die u implementeert met behulp van Azure Files.

Back-upopties zijn beschikbaar voor een oplossing die u zelf maakt en beheert, of als u software van derden gebruikt. Een optie is het gebruik van de services met Azure Storage, waaronder het gebruik van onveranderbare opslag voor blobgegevens. Deze zelfbeheerde optie is momenteel vereist als een DBMS-back-upoptie voor sommige databases, zoals SAP ASE of IBM Db2.

Gebruik de aanbevelingen in best practices van Azure om ransomware-aanvallen te beveiligen en te valideren .

Fooi

Zorg ervoor dat uw back-upstrategie het beveiligen van uw implementatieautomatisering, versleutelingssleutels voor Azure-resources en transparante databaseversleuteling omvat, indien gebruikt.

Back-up tussen regio's

Voor elke back-upvereiste in meerdere regio's bepaalt u de RTO (Recovery Time Objective) en RPO (Recovery Point Objective) die door de oplossing wordt aangeboden en of deze overeenkomt met uw BCDR-ontwerp en -behoeften.

SAP-migratie naar Azure

Het is niet mogelijk om alle migratiemethoden en -opties te beschrijven voor de grote verscheidenheid aan SAP-producten, versieafhankelijkheden en systeemeigen besturingssysteem en DBMS-technologieën die beschikbaar zijn. Het projectteam voor uw organisatie en vertegenwoordigers van de zijde van uw serviceprovider moet rekening houden met verschillende technieken voor een soepele SAP-migratie naar Azure.

  • Test de prestaties tijdens de migratie. Een belangrijk onderdeel van sap-migratieplanning is het testen van technische prestaties. Het migratieteam moet voldoende tijd en beschikbaarheid bieden voor belangrijke medewerkers om toepassingen en technische tests van het gemigreerde SAP-systeem uit te voeren, inclusief verbonden interfaces en toepassingen. Voor een geslaagde SAP-migratie is het essentieel om de premigratie en postmigratieruntime en nauwkeurigheid van belangrijke bedrijfsprocessen in een testomgeving te vergelijken. Gebruik de informatie om de processen te optimaliseren voordat u de productieomgeving migreert.

  • Azure-services gebruiken voor SAP-migratie. Sommige vm-workloads worden gemigreerd zonder over te schakelen naar Azure met behulp van services zoals Azure Migrate of Azure Site Recovery of een hulpprogramma van derden. Controleer zorgvuldig of de versie van het besturingssysteem en de SAP-workload die wordt uitgevoerd, worden ondersteund door de service.

    Vaak wordt elke databaseworkload opzettelijk niet ondersteund omdat een service geen databaseconsistentie kan garanderen. Als het DBMS-type wordt ondersteund door de migratieservice, is de databasewijziging of het verloop vaak te hoog. De meeste bezet SAP-systemen voldoen niet aan de wijzigingssnelheid die migratiehulpprogramma's toestaan. Problemen worden mogelijk pas weergegeven of gedetecteerd nadat de productiemigratie is uitgevoerd. In veel situaties zijn sommige Azure-services niet geschikt voor het migreren van SAP-systemen. Azure Site Recovery en Azure Migrate hebben geen validatie voor een grootschalige SAP-migratie. Een bewezen SAP-migratiemethodologie is om te vertrouwen op DBMS-replicatie of SAP-migratiehulpprogramma's.

    Een implementatie in Azure in plaats van een eenvoudige VM-migratie is beter en eenvoudiger dan een on-premises migratie. Met geautomatiseerde implementatieframeworks zoals Azure Center voor SAP-oplossingen en het Azure Deployment Automation-framework kunnen geautomatiseerde taken snel worden uitgevoerd. Voor het migreren van uw SAP-landschap naar een nieuwe geïmplementeerde infrastructuur met behulp van systeemeigen DBMS-replicatietechnologieën zoals HANA-systeemreplicatie, DBMS-back-up en herstel of sap-migratiehulpprogramma's maakt gebruik van gevestigde technische kennis van uw SAP-systeem.

  • Infrastructuur omhoog schalen. Tijdens een SAP-migratie kunt u met meer infrastructuurcapaciteit sneller implementeren. Het projectteam moet overwegen om de VM-grootte omhoog te schalen om meer CPU en geheugen te bieden. Het team moet ook overwegen om de geaggregeerde opslag en netwerkdoorvoer van vm's omhoog te schalen. Op vm-niveau kunt u ook opslagelementen zoals afzonderlijke schijven overwegen om de doorvoer te verhogen met bursting op aanvraag en prestatielagen voor Premium SSD v1. Verhoog IOPS en doorvoerwaarden als u Premium SSD v2 boven de geconfigureerde waarden gebruikt. Vergroot NFS- en SMB-bestandsshares om de prestatielimieten te verhogen. Houd er rekening mee dat Azure schijven niet kan verkleinen en dat de grootte, prestatielagen en doorvoer-KPI's verschillende afkoeltijden kunnen hebben.

  • Netwerk- en gegevenskopie optimaliseren. Het migreren van een SAP-systeem naar Azure omvat altijd het verplaatsen van een grote hoeveelheid gegevens. De gegevens kunnen database- en bestandsback-ups of replicatie zijn, een toepassings-naar-toepassingsgegevensoverdracht of een SAP-migratieexport. Afhankelijk van het migratieproces dat u gebruikt, moet u het juiste netwerkpad kiezen om de gegevens te verplaatsen. Voor veel bewerkingen voor gegevensverplaatsing is het gebruik van internet in plaats van een privénetwerk het snelste pad om gegevens veilig naar Azure Storage te kopiëren.

    Het gebruik van ExpressRoute of een VPN kan leiden tot knelpunten:

    • De migratiegegevens gebruiken te veel bandbreedte en verstoren de toegang van gebruikers tot workloads die worden uitgevoerd in Azure.
    • Netwerkknelpunten on-premises, zoals een firewall of doorvoerbeperking, worden vaak alleen gedetecteerd tijdens de migratie.

    Ongeacht de netwerkverbinding die wordt gebruikt, zijn de netwerkprestaties van één stream voor een gegevensverplaatsing vaak laag. Als u de snelheid van de gegevensoverdracht via meerdere TCP-streams wilt verhogen, gebruikt u hulpprogramma's die meerdere streams kunnen ondersteunen. Optimalisatietechnieken toepassen die worden beschreven in SAP-documentatie en in veel blogberichten over dit onderwerp.

Fooi

In de planningsfase is het belangrijk om rekening te houden met specifieke migratienetwerken die u gaat gebruiken voor grote gegevensoverdrachten naar Azure. Voorbeelden hiervan zijn back-ups of databasereplicatie of het gebruik van een openbaar eindpunt voor gegevensoverdracht naar Azure Storage. De impact van de migratie op netwerkpaden voor uw gebruikers en toepassingen moet worden verwacht en beperkt. Houd rekening met alle fasen van de migratie en de kosten van een gedeeltelijk productieve workload in Azure tijdens de migratie als onderdeel van uw netwerkplanning.

Ondersteuning en bewerkingen voor SAP

Enkele andere gebieden zijn belangrijk om rekening mee te houden vóór en tijdens de SAP-implementatie in Azure.

Azure VM-extensie voor SAP

Azure Monitoring Extension, Enhanced Monitoring en Azure Extension voor SAP verwijzen allemaal naar een VM-extensie die u moet implementeren om enkele basisgegevens over de Azure-infrastructuur naar de SAP-hostagent te bieden. SAP-notities kunnen verwijzen naar de extensie als Bewakingsuitbreiding of Uitgebreide bewaking. In Azure wordt deze Azure-extensie voor SAP genoemd. Voor ondersteuningsdoeleinden moet de extensie worden geïnstalleerd op alle Azure-VM's waarop een SAP-workload wordt uitgevoerd. Zie de Azure VM-extensie voor SAP voor meer informatie.

SAProuter voor SAP-ondersteuning

Voor het uitvoeren van een SAP-landschap in Azure is connectiviteit met en van SAP vereist voor ondersteuningsdoeleinden. Normaal gesproken heeft de connectiviteit de vorm van een SAProuter-verbinding, ofwel via een versleutelingsnetwerkkanaal via internet of via een privé-VPN-verbinding met SAP. Zie uw architectuurscenario in binnenkomende en uitgaande internetverbindingen voor SAP in Azure voor aanbevolen procedures en voor een voorbeeld van een implementatie van SAProuter in Azure.

Volgende stappen