Azure Virtual Machines en implementatie voor SAP NetWeaver

Microsoft Azure stelt bedrijven in staat om in minimale tijd reken- en opslagbronnen te verkrijgen zonder lange inkoopcycli. Met de Azure Virtual Machine-service kunnen bedrijven klassieke toepassingen, zoals SAP NetWeaver-toepassingen, implementeren in Azure en hun betrouwbaarheid en beschikbaarheid uitbreiden zonder dat er meer resources on-premises beschikbaar zijn. Azure Virtual Machine Services ondersteunt ook cross-premises connectiviteit, waardoor bedrijven Azure Virtual Machines actief kunnen integreren in hun on-premises domeinen, hun privé clouds en hun SAP-systeemlandschap. In dit technische document worden de grondbeginselen van Microsoft Azure Virtual Machine beschreven en worden overwegingen voor planning en implementatie voor SAP NetWeaver-installaties in Azure beschreven. Dit document moet als zodanig het document zijn dat moet worden gelezen voordat u werkelijke implementaties van SAP NetWeaver in Azure start. Het document vormt een aanvulling op de SAP-installatiedocumentatie en SAP-notities, die de primaire resources vertegenwoordigen voor installaties en implementaties van SAP-software op bepaalde platforms.

Samenvatting

CloudComputing is een veelgebruikte term, die steeds belangrijker wordt binnen de IT-branche, van kleine bedrijven tot grote en internationale bedrijven.

Microsoft Azure is het Cloud Services Platform van Microsoft, dat een breed scala aan nieuwe mogelijkheden biedt. Klanten kunnen nu snel toepassingen inrichten en de inrichting van toepassingen als een service in de cloud inrichten en de inrichting van toepassingen op de lange termijn inrichten, zodat ze zich niet beperken tot technische of budgetbeperkingen. In plaats van tijd en geld te investeren in hardware-infrastructuur, kunnen bedrijven zich richten op de toepassing, bedrijfsprocessen en de voordelen ervan voor klanten en gebruikers.

Met Microsoft Azure-services voor virtuele machines biedt Microsoft een uitgebreid IaaS-platform (Infrastructure as a Service). SAP NetWeaver-toepassingen worden ondersteund op virtuele Azure-machines (IaaS). In dit whitepaper wordt beschreven hoe u op SAP NetWeaver gebaseerde toepassingen binnen Microsoft Azure kunt plannen en implementeren als het platform van uw keuze.

Het document zelf is gericht op twee belangrijke aspecten:

• In het eerste deel worden twee ondersteunde implementatiepatronen voor SAP NetWeaver-toepassingen in Azure beschreven. Het beschrijft ook de algemene verwerking van Azure met SAP-implementaties in het achterhoofd.
• Het tweede deel beschrijft de implementatie van de verschillende scenario's die in het eerste deel worden beschreven.

Zie het hoofdstuk Resources in dit document voor aanvullende resources.

Definities vooraf

In het hele document gebruiken we de volgende termen:

• IaaS: Infrastructure as a Service
• PaaS: Platform as a Service
• SaaS: Software as a Service
• SAP-onderdeel: een afzonderlijke SAP-toepassing, zoals ECC, BW, Solution Manager of S/4HANA. SAP-onderdelen kunnen worden gebaseerd op traditionele ABAP java-technologieën of een niet-NetWeaver-toepassing zoals bedrijfsobjecten.
• SAP-omgeving: een of meer SAP-onderdelen die logisch zijn gegroepeerd om een bedrijfsfunctie uit te voeren, zoals Ontwikkeling, QAS, Training, DR of Productie.
• SAP Landscape: Deze term verwijst naar de volledige SAP-assets in het IT-landschap van een klant. Het SAP-landschap omvat alle productie- en niet-productieomgevingen.
• SAP-systeem: De combinatie van DBMS-laag en toepassingslaag van, bijvoorbeeld een SAP ERP-ontwikkelsysteem, SAP BW testsysteem, SAP CRM-productiesysteem, enzovoort. In Azure-implementaties wordt het niet ondersteund om deze twee lagen te verdelen tussen on-premises en Azure. Dit betekent dat een SAP-systeem on-premises wordt geïmplementeerd of in Azure wordt geïmplementeerd. U kunt echter de verschillende systemen van een SAP-landschap implementeren in Azure of on-premises. U kunt bijvoorbeeld de SAP CRM-ontwikkel- en testsystemen implementeren in Azure, maar in het on-premises SAP CRM-productiesysteem.
• Cross-premises of hybride: beschrijft een scenario waarin VM's worden geïmplementeerd in een Azure-abonnement met site-naar-site-, multi-site- of ExpressRoute-connectiviteit tussen de on-premises datacenter(s) en Azure. In algemene Azure-documentatie worden dit soort implementaties ook beschreven als cross-premises of hybride scenario's. De reden voor de verbinding is om on-premises domeinen, on-premises Active Directory/OpenLDAP en on-premises DNS uit te breiden naar Azure. Het on-premises landschap wordt uitgebreid naar de Azure-assets van het abonnement. Met deze extensie kunnen de VM's deel uitmaken van het on-premises domein. Domeingebruikers van het on-premises domein hebben toegang tot de servers en kunnen services uitvoeren op deze VM's (zoals DBMS-services). Communicatie en naamom oplossing tussen VM's die on-premises zijn geïmplementeerd en door Azure geïmplementeerde VM's is mogelijk. Dit is de meest voorkomende en bijna exclusieve case voor het implementeren van SAP-assets in Azure. Zie dit artikel en dit voor meer informatie.
• Azure Monitoring Extension, Enhanced Monitoring en Azure Extension for SAP: beschrijf één item en hetzelfde item. Er wordt een VM-extensie beschreven die door u moet worden geïmplementeerd om enkele basisgegevens over de Azure-infrastructuur aan de SAP-hostagent op te geven. Sap in SAP-notities kunnen hier naar verwijzen als Bewakingsextensie of Uitgebreide bewaking. In Azure verwijzen we hier naar als Azure-extensie voor SAP.

Resources

Het toegangspunt voor sap-workloads in Azure vindt u in Aan de slag SAP on Azure VM's. Vanaf dit toegangspunt vindt u veel artikelen die betrekking hebben op de volgende onderwerpen:

• SAP NetWeaver en Business One in Azure
• SAP DBMS-handleidingen voor verschillende DBMS-systemen in Azure
• Hoge beschikbaarheid en herstel na noodherstel voor SAP-workload in Azure
• Specifieke richtlijnen voor het uitvoeren SAP HANA in Azure
• Richtlijnen die specifiek zijn voor Azure HANA Large Instances voor de SAP HANA DBMS

De volgende SAP-opmerkingen zijn gerelateerd aan het onderwerp van SAP on Azure:

Lees ook de SCN-wiki die alle SAP-notities voor Linux bevat.

Algemene standaardbeperkingen en maximumbeperkingen van Azure-abonnementen vindt u in dit artikel.

Mogelijke scenario's

SAP wordt vaak gezien als een van de meest essentiële toepassingen binnen ondernemingen. De architectuur en bewerkingen van deze toepassingen zijn meestal complex en het is belangrijk om ervoor te zorgen dat u voldoet aan de vereisten voor beschikbaarheid en prestaties.

Ondernemingen moeten daarom zorgvuldig nadenken over welke cloudprovider moet worden gekozen voor het uitvoeren van dergelijke bedrijfskritieke bedrijfsprocessen. Azure is het ideale openbare cloudplatform voor bedrijfskritieke SAP-toepassingen en bedrijfsprocessen. Gezien de grote verscheidenheid aan Azure-infrastructuur kunnen momenteel bijna alle bestaande SAP NetWeaver- en S/4HANA-systemen worden gehost in Azure. Azure biedt VM's met veel Terabytes aan geheugen en meer dan 200 CPU's. Daarnaast biedt Azure HANA Large Instances,waarmee HANA-implementaties van maximaal 24 TB en SAP HANA tot 120 TB kunnen worden geschaald. U kunt tegenwoordig stellen dat bijna alle on-premises SAP-scenario's ook in Azure kunnen worden uitgevoerd.

Zie voor een ruwe beschrijving van de scenario's en een aantal niet-ondersteunde scenario's het document SAP workload on Azure virtual machine supported scenarios (Ondersteunde scenario's voor SAP-workload op virtuele Azure-machines).

Controleer deze scenario's en enkele van de voorwaarden die zijn genoemd als niet ondersteund in de documentatie waarnaar wordt verwezen tijdens de planning en de ontwikkeling van uw architectuur die u in Azure wilt implementeren.

Over het algemeen is het meest voorkomende implementatiepatroon een cross-premises scenario zoals weergegeven

Reden voor veel klanten om een cross-premises implementatiepatroon toe te passen, is dat het voor alle toepassingen het meest transparant is om on-premises uit te breiden naar Azure met behulp van Azure ExpressRoute en Azure als virtueel datacenter te behandelen. Naarmate er steeds meer assets naar Azure worden verplaatst, worden de infrastructuur en netwerkinfrastructuur die door Azure geïmplementeerd, groter en nemen de on-premises assets dienovereenkomstig af. Alles is transparant voor gebruikers en toepassingen.

Als u SAP-systemen met succes wilt implementeren in Azure IaaS of IaaS in het algemeen, is het belangrijk om inzicht te krijgen in de aanzienlijke verschillen tussen het aanbod van traditionele outsourcers of hosters en IaaS-aanbiedingen. Waar de traditionele hoster of outsourcer infrastructuur (netwerk, opslag en servertype) aanpast aan de workload die een klant wil hosten, is het in plaats daarvan de verantwoordelijkheid van de klant of partner om de workload te karakteriseren en de juiste Azure-onderdelen van VM's, opslag en netwerk te kiezen voor IaaS-implementaties.

Als u gegevens wilt verzamelen voor de planning van uw implementatie in Azure, is het belangrijk om:

• Evalueren welke SAP-producten worden ondersteund voor het uitvoeren in azure-VM's
• Evalueren welke specifieke besturingssysteemreleases worden ondersteund met specifieke Azure-VM's voor deze SAP-producten
• Evalueren welke DBMS-releases worden ondersteund voor uw SAP-producten met specifieke Azure-VM's
• Evalueer of voor sommige van de vereiste OS/DBMS-releases SAP-release, ondersteuningspakketupgrade en kernelupgrades moeten worden uitgevoerd om een ondersteunde configuratie te krijgen
• Evalueer of u naar verschillende besturingssystemen moet gaan om in Azure te kunnen implementeren.

Meer informatie over ondersteunde SAP-onderdelen in Azure, ondersteunde Azure-infrastructuureenheden en gerelateerde versies van besturingssystemen en DBMS-releases wordt beschreven in het artikel Welke SAP-software wordt ondersteund voor Azure-implementaties. Resultaten die zijn verkregen uit de evaluatie van geldige SAP-releases, besturingssysteem en DBMS-releases hebben een grote invloed op de inspanningen om SAP-systemen naar Azure te verplaatsen. Resultaten van deze evaluatie bepalen of er aanzienlijke voorbereidingsinspanningen kunnen zijn in gevallen waarin SAP-release-upgrades of wijzigingen van besturingssystemen nodig zijn.

Azure-regio's

De Azure-services van Microsoft worden verzameld in Azure-regio's. Een Azure-regio is een of een verzameling van datacenters die de hardware en infrastructuur bevatten die de verschillende Azure-services uitvoeren en hosten. Deze infrastructuur bevat een groot aantal knooppunten die fungeren als rekenknooppunten of opslagknooppunten, of netwerkfunctionaliteit uitvoeren.

Raadpleeg het artikel Azure-geografieën voor een lijst met de verschillende Azure-regio's. Niet alle Azure-regio's bieden dezelfde services. Afhankelijk van het SAP-product dat u wilt uitvoeren en het besturingssysteem en DBMS dat daaraan is gerelateerd, kunt u in een situatie komen dat een bepaalde regio niet de VM-typen aanbiedt die u nodig hebt. Dit geldt met name voor het uitvoeren SAP HANA, waar u meestal VM's van de M/Mv2 VM-serie nodig hebt. Deze VM-families worden alleen geïmplementeerd in een subset van de regio's. Met behulp van de site Producten beschikbaar per regio kunt u na gaan welke exacte VM's, typen, Azure-opslagtypen of andere Azure-services beschikbaar zijn in welke regio's. Wanneer u begint met de planning en u bepaalde regio's in gedachten hebt als primaire en uiteindelijke secundaire regio, moet u eerst onderzoeken of de benodigde services beschikbaar zijn in deze regio's.

Beschikbaarheidszones

Verschillende Azure-regio's hebben een concept met de naam Beschikbaarheidszones. Beschikbaarheidszones fysiek gescheiden locaties binnen een Azure-regio. Elke beschikbaarheidszone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Als u bijvoorbeeld twee VM's implementeert op twee Beschikbaarheidszones van Azure en een framework voor hoge beschikbaarheid implementeert voor uw SAP DBMS-systeem of sap central services, krijgt u de beste SLA in Azure. Voor deze specifieke SLA voor virtuele machines in Azure raadpleegt u de nieuwste versie van de SLA's voor virtuele machines. Omdat Azure-regio's de afgelopen jaren snel zijn ontwikkeld en uitgebreid, kunnen de topologie van de Azure-regio's, het aantal fysieke datacenters, de afstand tussen deze datacenters en de afstand tussen Azure-beschikbaarheidszones verschillen. En daarmee de netwerklatentie.

Het principe van Beschikbaarheidszones is niet van toepassing op de HANA-specifieke service van HANA Large Instances. Serviceovereenkomsten voor grote HANA-exemplaren vindt u in het artikel SLA voor SAP HANA on Azure Large Instances

Foutdomeinen

Foutdomeinen vertegenwoordigen een fysieke fouteenheid, die nauw verband houdt met de fysieke infrastructuur in datacenters. Hoewel een fysieke blade of rek kan worden beschouwd als een foutdomein, is er geen directe een-op-een-toewijzing tussen de twee.

Wanneer u meerdere Virtual Machines als onderdeel van één SAP-systeem in Microsoft Azure Virtual Machine Services implementeert, kunt u de Azure Fabric Controller beïnvloeden om uw toepassing te implementeren in verschillende foutdomeinen, waardoor wordt voldaan aan hogere beschikbaarheids-SLA's. De distributie van foutdomeinen over een Azure-schaaleenheid (verzameling van honderden rekenknooppunten of Storage-knooppunten en netwerken) of de toewijzing van VM's aan een specifiek foutdomein is echter iets waarover u geen directe controle hebt. Als u wilt dat de Azure-fabriccontroller een set VM's implementeert via verschillende foutdomeinen, moet u tijdens de implementatie een Azure-beschikbaarheidsset toewijzen aan de VM's. Zie het hoofdstuk Azure-beschikbaarheidssets in dit document voor meer informatie over Azure-beschikbaarheidssets.

Domeinen upgraden

Upgradedomeinen vertegenwoordigen een logische eenheid waarmee u kunt bepalen hoe een VM binnen een SAP-systeem, die bestaat uit SAP-exemplaren die worden uitgevoerd op meerdere VM's, wordt bijgewerkt. Wanneer er een upgrade plaatsvindt, Microsoft Azure het proces van het bijwerken van deze upgradedomeinen één voor één doorlopen. Door VM's tijdens de implementatie te spreiden over verschillende upgradedomeinen, kunt u uw SAP-systeem gedeeltelijk beschermen tegen mogelijke downtime. Als u wilt forceren dat Azure de VM's van een SAP-systeem implementeert die zijn verdeeld over verschillende upgradedomeinen, moet u een specifiek kenmerk instellen tijdens de implementatie van elke VM. Net als bij foutdomeinen is een Azure-schaaleenheid onderverdeeld in meerdere upgradedomeinen. Als u wilt dat de Azure-fabriccontroller een set VM's implementeert via verschillende upgradedomeinen, moet u tijdens de implementatie een Azure-beschikbaarheidsset toewijzen aan de VM's. Zie het hoofdstuk Azure-beschikbaarheidssets hieronder voor meer informatie over Azure-beschikbaarheidssets.

Azure-beschikbaarheidssets

Azure Virtual Machines binnen één Azure-beschikbaarheidsset worden gedistribueerd door de Azure Fabric-controller over verschillende fout- en upgradedomeinen. Het doel van de distributie over verschillende fout- en upgradedomeinen is om te voorkomen dat alle VM's van een SAP-systeem worden afgesloten in het geval van onderhoud van de infrastructuur of een storing binnen één foutdomein. Standaard maken VM's geen deel uit van een beschikbaarheidsset. De deelname van een VM aan een beschikbaarheidsset wordt gedefinieerd tijdens de implementatie of later door een herconfiguratie en herimplementatie van een VM.

Lees dit artikel voor meer informatie over het concept van Azure-beschikbaarheidssets en de manier waarop beschikbaarheidssets betrekking hebben op fout- en upgradedomeinen.

Wanneer u beschikbaarheidssets definieert en verschillende VM's van verschillende VM-families binnen één beschikbaarheidsset probeert te combineren, kunnen er problemen ontstaan waardoor u geen bepaald VM-type in een dergelijke beschikbaarheidsset kunt opnemen. De reden hiervoor is dat de beschikbaarheidsset is gebonden aan een schaaleenheid die een bepaald type rekenhosts bevat. En een bepaald type rekenhost kan alleen bepaalde typen VM-families uitvoeren. Als u bijvoorbeeld een beschikbaarheidsset maakt en de eerste VM in de beschikbaarheidsset implementeert en u een VM-type van de Esv3-familie kiest en vervolgens probeert als tweede VM een VM van de M-familie te implementeren, wordt u geweigerd bij de tweede toewijzing. Reden is dat de VM's van de Esv3-familie niet worden uitgevoerd op dezelfde hosthardware als de virtuele machines van de M-familie. Hetzelfde probleem kan optreden wanneer u de VM's probeert te iseren en een VM uit de Esv3-familie naar een VM-type van de M-familie probeert te verplaatsen. In het geval van het formaat van een VM-familie die niet op dezelfde hosthardware kan worden gehost, moet u alle VM's in uw beschikbaarheidsset afsluiten en het formaat ervan instellen om te kunnen worden uitgevoerd op het andere type hostmachine. Raadpleeg het artikel SLA's voor virtuele machines voor SLA's van VM'sdie in de beschikbaarheidsset zijn geïmplementeerd.

Het principe van beschikbaarheidsset en het bijbehorende update- en foutdomein is niet van toepassing op de specifieke HANA-service van HANA Large Instances. Serviceovereenkomsten voor grote HANA-exemplaren vindt u in het artikel SLA voor SAP HANA on Azure Large Instances.

Gekoppelde Azure-regio's

Azure biedt Azure-regioparen waar replicatie van bepaalde gegevens tussen deze vaste regioparen is ingeschakeld. De regio koppelen wordt beschreven in het artikel Bedrijfscontinuïteit en herstel na nood gevallen (BCDR): gekoppelde Azure-regio's. Zoals in het artikel wordt beschreven, is de replicatie van gegevens gekoppelde Azure-opslagtypen die u kunt configureren om te repliceren naar de gekoppelde regio. Zie ook het artikel Storage redundantie in een secundaire regio. De opslagtypen die een dergelijke replicatie toestaan, zijn opslagtypen die niet geschikt zijn voor DBMS-workloads. Daarom is de bruikbaarheid van de Azure-opslagreplicatie beperkt tot Azure Blob Storage (zoals voor back-updoeleinden) of andere opslagscenario's met hoge latentie. Wanneer u controleert op gekoppelde regio's en de services die u wilt gebruiken als uw primaire of secundaire regio, kunnen er situaties ontstaan waarin Azure-services en/of VM-typen die u wilt gebruiken in uw primaire regio niet beschikbaar zijn in de gekoppelde regio. Of er kan een situatie zijn waarin de gekoppelde Azure-regio niet acceptabel is vanwege de nalevingsredenen van gegevens. In deze gevallen moet u een niet-gekoppelde regio gebruiken als secundaire/noodherstelregio. In dat geval moet u rekening houden met de replicatie van een deel van de gegevens die Azure zelf zou hebben gerepliceerd. Een voorbeeld van het repliceren van uw Active Directory en DNS naar uw regio voor herstel na noodherstel wordt beschreven in het artikel Herstel na noodherstel instellen voor Active Directory en DNS

Services voor virtuele Azure-machines

Azure biedt een groot aantal virtuele machines die u kunt selecteren om te implementeren. Het is niet nodig om technologie en infrastructuur van te voren te kopen. De Azure VM-service vereenvoudigt het onderhouden en gebruiken van toepassingen door on-demand rekenkracht en opslag te bieden voor het hosten, schalen en beheren van webtoepassingen en verbonden toepassingen. Infrastructuurbeheer wordt geautomatiseerd met een platform dat is ontworpen voor hoge beschikbaarheid en dynamische schaalbaarheid om te voldoen aan de gebruiksbehoeften met de optie van verschillende prijsmodellen.

Met virtuele Azure-machines stelt Microsoft u in staat om aangepaste serverafbeeldingen te implementeren in Azure als IaaS-exemplaren. U kunt ook kiezen uit een uitgebreide selectie verbruikbare installatie afbeeldingen van besturingssystemen uit de Azure Marketplace.

Vanuit operationeel oogpunt biedt de Azure Virtual Machine Service vergelijkbare ervaringen als virtuele machines die on-premises zijn geïmplementeerd. U bent verantwoordelijk voor het beheer, de bewerkingen en ook de patching van het specifieke besturingssysteem, dat wordt uitgevoerd op een Azure-VM en de toepassingen ervan in die VM. Microsoft biedt geen services meer dan het hosten van die VM op de Azure-infrastructuur (Infrastructure as a Service - IaaS). Voor SAP-workloads die u als klant implementeert, heeft Microsoft geen aanbiedingen buiten de IaaS-aanbiedingen.

Het Microsoft Azure platform is een platform met meerdere tenants. Als gevolg hiervan worden opslag-, netwerk- en rekenbronnen die azure-VM's hosten, gedeeld tussen tenants, met een paar uitzonderingen. Intelligente beperkings- en quotumlogica worden gebruikt om te voorkomen dat één tenant de prestaties van een andere tenant (ruis) op een drastische manier beïnvloedt. Met name voor het certificeren van het Azure-platform voor SAP HANA moet Microsoft de isolatie van resources bewijzen voor gevallen waarin meerdere VM's regelmatig op dezelfde host kunnen worden uitgevoerd voor SAP. Hoewel de logica in Azure probeert afwijkingen in de bandbreedte klein te houden, introduceren sterk gedeelde platforms vaak grotere verschillen in resource-/bandbreedtebeschikbaarheid dan klanten mogelijk ervaren in hun on-premises implementaties. Er moet rekening worden gehouden met de kans dat een SAP-systeem in Azure grotere afwijkingen kan ervaren dan in een on-premises systeem.

Virtuele Azure-machines voor SAP-workload

Voor SAP-workload hebben we de selectie beperkt tot verschillende VM-families die geschikt zijn voor SAP-workloads en SAP HANA specifiekere workload. De manier waarop u het juiste VM-type en de mogelijkheid om via de SAP-workload te werken vindt, wordt beschreven in het document Welke SAP-software wordt ondersteund voor Azure-implementaties.

Naast de selectie van uitsluitend ondersteunde VM-typen, moet u ook controleren of deze VM-typen beschikbaar zijn in een specifieke regio op basis van de site Producten beschikbaar per regio. Maar belangrijker is dat u moet evalueren of:

• CPU- en geheugenbronnen van verschillende VM-typen
• IOPS-bandbreedte van verschillende VM-typen
• Netwerkmogelijkheden van verschillende VM-typen
• Aantal schijven dat kan worden gekoppeld
• Mogelijkheid om gebruik te maken van bepaalde Azure-opslagtypen

aan uw behoefte. De meeste van die gegevens vindt u hier (Linux) en hier (Windows) voor een bepaald VM-type.

Als prijsmodel hebt u verschillende prijsopties die worden vermeld zoals:

• Betalen per gebruik
• Eén jaar gereserveerd
• Drie jaar gereserveerd
• Spotprijzen

De prijzen van elk van de verschillende aanbiedingen met verschillende serviceaanbiedingen voor besturingssystemen en verschillende regio's zijn beschikbaar op de site Linux Virtual Machines prijzen en Windows Virtual Machines prijzen. Raadpleeg de volgende artikelen voor meer informatie over en flexibiliteit van gereserveerde instanties voor één jaar en drie jaar:

• Wat zijn Azure-reserveringen?
• Flexibiliteit van de VM-grootte met gereserveerde VM-instanties
• Toepassing van de reserveringskorting op virtuele machines

Lees het artikel Azure Spot Virtual Machines voor meer informatie over spotprijzen. De prijzen van hetzelfde VM-type kunnen ook verschillen tussen verschillende Azure-regio's. Voor sommige klanten was het de moeite waard om te implementeren in een minder dure Azure-regio.

Daarnaast biedt Azure de concepten van een toegewezen host. Het toegewezen hostconcept biedt u meer controle over patchcycli die worden uitgevoerd door Azure. U kunt het patchen volgens uw eigen schema's timen. Deze aanbieding is specifiek gericht op klanten met een workload die mogelijk niet de normale werkbelastingcyclus volgt. Lees het artikel over de concepten van Azure Dedicated Host-aanbiedingen voor meer informatie Azure Dedicated Host. Het gebruik van deze aanbieding wordt ondersteund voor SAP-workloads en wordt gebruikt door verschillende SAP-klanten die meer controle willen over het patchen van infrastructuur en uiteindelijke onderhoudsplannen van Microsoft. Lees het artikel Onderhoud voor virtuele machines in Azure voor meer informatie over hoe Microsoft de Azure-infrastructuur onderhoudt en patcht die als host voor virtuele machines wordt gebruikt.

Virtuele machines van de 1e en 2e generatie

De hypervisor van Microsoft kan twee verschillende generaties van virtuele machines verwerken. Deze indelingen worden Generatie 1 en Generatie 2 genoemd. Generatie 2 is geïntroduceerd in het jaar 2012 met Windows Server 2012 hypervisor. Azure is begonnen met het gebruik van virtuele machines van de eerste generatie. Wanneer u virtuele Azure-machines implementeert, wordt standaard nog steeds gebruik gemaakt van de generatie 1-indeling. Ondertussen kunt u ook VM-indelingen van de tweede generatie implementeren. In het artikel Ondersteuning voor VM's van de tweede generatie in Azure worden de Azure VM-families vermeld die kunnen worden geïmplementeerd als VM van de tweede generatie. Dit artikel bevat ook een overzicht van de belangrijke functionele verschillen van virtuele machines van de tweede generatie, omdat ze kunnen worden uitgevoerd in de Hyper-V-privécloud en Azure. Belangrijker in dit artikel zijn ook functionele verschillen tussen virtuele machines van de eerste generatie en virtuele machines van de tweede generatie, omdat deze worden uitgevoerd in Azure.

Het is niet mogelijk om een bestaande VM van de ene generatie naar de andere te verplaatsen. Als u de generatie van de virtuele machine wilt wijzigen, moet u een nieuwe virtuele machine van de generatie die u wilt implementeren en de software die u gebruikt opnieuw installeren op de virtuele machine van de generatie. Deze wijziging is alleen van invloed op de basis-VHD-afbeelding van de VM en heeft geen invloed op de gegevensschijven of gekoppelde NFS- of SMB-shares. Gegevensschijven, NFS- of SMB-shares die oorspronkelijk zijn toegewezen aan, bijvoorbeeld op een VM van de eerste generatie.

Storage: Microsoft Azure Storage en gegevensschijven

Microsoft Azure Virtual Machines verschillende opslagtypen gebruiken. Bij het implementeren SAP on Azure Virtual Machine Services is het belangrijk om de verschillen tussen deze twee hoofdtypen opslag te begrijpen:

• Niet-persistente, vluchtige opslag.
• Permanente opslag.

Azure-VM's bieden niet-permanente schijven nadat een VM is geïmplementeerd. Als een VM opnieuw wordt opgestart, wordt alle inhoud op die stations gewist. Daarom is het een gegeven dat gegevensbestanden en logboek-/redo-bestanden van databases zich onder geen enkele omstandigheden op deze niet-persistente stations mogen bevinden. Er kunnen uitzonderingen zijn voor sommige databases, waarbij deze niet-persistente schijven geschikt kunnen zijn voor tempdb- en temp tablespaces. Vermijd echter het gebruik van deze stations voor VM's uit de A-serie, omdat deze niet-persistente stations een beperkte doorvoer hebben bij die VM-serie. Lees het artikel Understanding the temporary drive on Windows VMs in Azure (Inzicht in het tijdelijke station op virtuele Windows in Azure) voor meer informatie.

Windows

Station D:\ in een Azure-VM is een niet-persistent station, dat wordt gebacked door een aantal lokale schijven op het Azure-reken knooppunt. Omdat deze niet persistent is, betekent dit dat wijzigingen in de inhoud op de D:\ station gaat verloren wanneer de VM opnieuw wordt opgestart. Door 'eventuele wijzigingen', zoals opgeslagen bestanden, gemaakte mappen, geïnstalleerde toepassingen, enzovoort.

Linux

Virtuele Linux Azure-VM's worden automatisch aan een station in /mnt/resource bevestigd dat een niet-persistent station is dat wordt back-by-by-local disks op het Azure-reken knooppunt. Omdat deze niet persistent is, betekent dit dat alle wijzigingen in de inhoud in /mnt/resource verloren gaan wanneer de VM opnieuw wordt opgestart. Door wijzigingen, zoals opgeslagen bestanden, gemaakte mappen, geïnstalleerde toepassingen, enzovoort.

Azure Storage-accounts

Bij het implementeren van services of VM's in Azure, worden de implementatie van VHD's en VM-installatie installatie afbeeldingen georganiseerd in eenheden die Azure Storage worden genoemd. Azure-opslagaccounts hebben beperkingen in IOPS, doorvoer of grootten die deze kunnen bevatten. In het verleden zijn deze beperkingen beschreven in:

• Schaalbaarheidsdoelen voor standaardopslagaccounts
• Schaalbaarheidsdoelen voor Premium Page Blob Storage-accounts

heeft een belangrijke rol gespeeld bij het plannen van een SAP-implementatie in Azure. Het was aan u om het aantal persistente schijven binnen een opslagaccount te beheren. U moest de opslagaccounts beheren en uiteindelijk nieuwe opslagaccounts maken om meer persistente schijven te maken.

In de afgelopen jaren is de introductie van azure managed disks u ontdaan van deze taken. De aanbeveling voor SAP-implementaties is om gebruik te maken van beheerde Azure-schijven in plaats van zelf Azure-opslagaccounts te beheren. Azure Managed Disks distribueert schijven over verschillende opslagaccounts, zodat de limieten van de afzonderlijke opslagaccounts niet worden overschreden.

Binnen een opslagaccount hebt u een type mapconcept met de naam 'containers' dat kan worden gebruikt om bepaalde schijven in specifieke containers te groeperen.

Binnen Azure volgt een schijf-/VHD-naam de volgende naamgevingsverbinding die een unieke naam moet bieden voor de VHD in Azure:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

De bovenstaande tekenreeks moet de schijf/VHD uniek identificeren die is opgeslagen op Azure Storage.

Persistente opslagtypen in Azure

Azure biedt diverse opties voor persistente opslag die kunnen worden gebruikt voor SAP-workloads en specifieke SAP-stackonderdelen. Lees het document Azure Storage voor SAP-workloads voor meer informatie.

Microsoft Azure Networking

Microsoft Azure biedt een netwerkinfrastructuur waarmee alle scenario's kunnen worden toegewezen die we willen realiseren met SAP-software. De mogelijkheden zijn:

• Toegang van buitenaf, rechtstreeks naar de VM's via Windows Terminal Services of ssh/VNC
• Toegang tot services en specifieke poorten die worden gebruikt door toepassingen binnen de VM's
• Interne communicatie en naamom oplossing tussen een groep VM's die zijn geïmplementeerd als Azure-VM's
• Cross-premises connectiviteit tussen het on-premises netwerk van een klant en het Azure-netwerk
• Connectiviteit tussen Azure-regio's of datacenters tussen Azure-sites

Meer informatie vindt u hier: https://azure.microsoft.com/documentation/services/virtual-network/

Er zijn veel verschillende mogelijkheden voor het configureren van naam- en IP-resolutie in Azure. Er is ook een Azure DNS service, die kan worden gebruikt in plaats van uw eigen DNS-server in te stellen. Meer informatie vindt u in dit artikel en op deze pagina.

Voor cross-premises of hybride scenario's vertrouwen we op het feit dat de on-premises AD/OpenLDAP/DNS is uitgebreid via VPN of een privéverbinding met Azure. Voor bepaalde scenario's zoals hier wordt beschreven, kan het nodig zijn om een AD/OpenLDAP-replica te installeren in Azure.

Omdat netwerk- en naamomleiding een essentieel onderdeel is van de database-implementatie voor een SAP-systeem, wordt dit concept uitgebreider besproken in de DBMS Deployment Guide.

Virtuele netwerken van Azure

Door een Azure-Virtual Network, kunt u het adresbereik definiëren van de privé-IP-adressen die zijn toegewezen door azure DHCP-functionaliteit. In cross-premises scenario's wordt het gedefinieerde IP-adresbereik nog steeds toegewezen met dhcp door Azure. Domeinnaamom oplossing wordt echter on-premises uitgevoerd (ervan uitgaande dat de VM's deel uitmaken van een on-premises domein) en kunnen adressen daarom buiten verschillende Azure Cloud Services.

Elke virtuele machine in Azure moet zijn verbonden met een Virtual Network.

Meer informatie vindt u in dit artikel en op deze pagina.

Het MAC-adres van de virtuele netwerkkaart kan worden gewijzigd, bijvoorbeeld nadat het bereik is gewijzigd en het Windows- of Linux-gast besturingssysteem de nieuwe netwerkkaart oppipt en in dit geval automatisch DHCP gebruikt om de IP- en DNS-adressen toe te wijzen.

Statische IP-toewijzing

Het is mogelijk vaste of gereserveerde IP-adressen toe te wijzen aan VM's binnen een Azure-Virtual Network. Het uitvoeren van de VM's in een Azure-Virtual Network biedt een grote mogelijkheid om deze functionaliteit te gebruiken, indien nodig of vereist voor sommige scenario's. De IP-toewijzing blijft geldig gedurende het bestaan van de VM, ongeacht of de VM wordt uitgevoerd of afgesloten. Als gevolg hiervan moet u rekening houden met het totale aantal VM's (VM's die worden uitgevoerd en gestopt) bij het definiëren van het bereik van IP-adressen voor de Virtual Network. Het IP-adres blijft toegewezen totdat de VM en de netwerkinterface worden verwijderd of totdat het IP-adres opnieuw wordt toegewezen. Lees dit artikel voor meer informatie.

Secundaire IP-adressen voor SAP-hostnaamvirtualisatie

Aan de netwerkinterfacekaart van elke virtuele Azure-machine kunnen meerdere IP-adressen worden toegewezen. Dit secundaire IP-adres kan worden gebruikt voor virtuele SAP-hostnamen die indien nodig worden toegewezen aan een DNS A/PTR-record. De secundaire IP-adressen moeten worden toegewezen aan azure vNICs IP-configuratie volgens dit artikel en ook worden geconfigureerd binnen het besturingssysteem als secundaire IP-adressen niet worden toegewezen via DHCP. Elk secundair IP-adres moet afkomstig zijn van hetzelfde subnet waar de vNIC aan is gebonden. Het gebruik van het zwevende IP-adres van Azure Load Balancer wordt niet ondersteund voor secundaire IP-configuraties, zoals Pacemaker-clusters. In dit geval schakelt het IP-adres van de Load Balancer de virtuele SAP-hostnamen in. Zie ook de opmerking van SAP 962955 algemene richtlijnen voor het gebruik van namen van virtuele hosten.

Meerdere NIC's per VM

U kunt meerdere virtuele netwerkinterfacekaarten (vNIC) definiëren voor een virtuele Azure-machine. Met de mogelijkheid om meerdere vNIC's te hebben, kunt u beginnen met het instellen van netwerkverkeerscheiding waarbij bijvoorbeeld clientverkeer wordt gerouteerd via één vNIC en back-endverkeer wordt gerouteerd via een tweede vNIC. Afhankelijk van het type VM zijn er verschillende beperkingen voor het aantal vNIC's dat aan een VM kan worden toegewezen. Exacte details, functionaliteit en beperkingen vindt u in deze artikelen:

• Een virtuele Windows met meerdere NIC's maken
• Een linux-VM met meerdere NIC's maken
• Virtuele VM's met meerdere NIC's implementeren met behulp van een sjabloon
• Virtuele VM's met meerdere NIC's implementeren met Behulp van PowerShell
• Virtuele VM's met meerdere NIC's implementeren met behulp van de Azure CLI

Site-naar-site-connectiviteit

Cross-premises zijn Azure-VM's en on-premises gekoppeld met een transparante en permanente VPN-verbinding. Het wordt naar verwachting het meest voorkomende SAP-implementatiepatroon in Azure. De veronderstelling is dat operationele procedures en processen met SAP-exemplaren in Azure transparant moeten werken. Dit betekent dat u deze systemen moet kunnen afdrukken en het SAP Transport Management System (TMS) moet kunnen gebruiken om wijzigingen van een ontwikkelsysteem in Azure te transporteren naar een testsysteem dat on-premises is geïmplementeerd. Meer documentatie over site-naar-site vindt u in dit artikel

VPN-Tunnel apparaat

Als u een site-naar-site-verbinding (on-premises datacenter met Azure-datacenter) wilt maken, moet u een VPN-apparaat verkrijgen en configureren of RRAS (Routing and Remote Access Service) gebruiken dat is geïntroduceerd als een softwareonderdeel met Windows Server 2012.

• Een virtueel netwerk met een site-naar-site-VPN-verbinding maken met Behulp van PowerShell
• Informatie over VPN-apparaten voor verbinding met site-naar-site-VPN-gateways
• Veelgestelde vragen VPN-gateways

In de bovenstaande afbeelding ziet u dat twee Azure-abonnementen IP-adressubranges hebben die zijn gereserveerd voor gebruik in virtuele netwerken in Azure. De connectiviteit van het on-premises netwerk naar Azure wordt tot stand gebracht via VPN.

Punt-naar-site-VPN

Punt-naar-site-VPN vereist dat elke clientmachine verbinding maakt met een eigen VPN in Azure. Voor de SAP-scenario's kijken we naar punt-naar-site-connectiviteit is niet praktisch. Er worden daarom geen verdere verwijzingen gegeven naar punt-naar-site-VPN-connectiviteit.

Meer informatie vindt u hier

• Een punt-naar-site-verbinding met een VNet configureren met Azure Portal
• Een punt-naar-site-verbinding met een VNet configureren met behulp van PowerShell

VPN voor meerdere site

Azure biedt tegenwoordig ook de mogelijkheid om multi-site VPN-connectiviteit te maken voor één Azure-abonnement. Voorheen was één abonnement beperkt tot één site-naar-site-VPN-verbinding. Deze beperking is weggehaald met MULTI-Site VPN-verbindingen voor één abonnement. Dit maakt het mogelijk om meer dan één Azure-regio te gebruiken voor een specifiek abonnement via cross-premises configuraties.

Zie dit artikel voor meer documentatie

VNet-naar-VNet-verbinding

Als u VPN met meerdere site gebruikt, moet u een afzonderlijke Azure-Virtual Network in elk van de regio's. Vaak hebt u echter de vereiste dat de softwareonderdelen in de verschillende regio's met elkaar moeten communiceren. In het ideale ideale moment moet deze communicatie niet worden gerouteerd van de ene Azure-regio naar on-premises en van daar naar de andere Azure-regio. Als snelkoppeling biedt Azure de mogelijkheid om een verbinding te configureren van de ene Azure-Virtual Network in de ene regio naar een andere Azure-Virtual Network gehost in een andere regio. Deze functionaliteit wordt VNet-naar-VNet-verbinding genoemd. Meer informatie over deze functionaliteit vindt u hier: https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ .

Privéverbinding met Azure ExpressRoute

Microsoft Azure ExpressRoute maakt het mogelijk om privéverbindingen te maken tussen Azure-datacenters en de on-premises infrastructuur van de klant of in een co-locatieomgeving. ExpressRoute wordt aangeboden door verschillende MPLS(packet switched) VPN-providers of andere netwerkserviceproviders. ExpressRoute-verbindingen gaan niet via het openbare internet. ExpressRoute-verbindingen bieden een hogere beveiliging, meer betrouwbaarheid via meerdere parallelle circuits, hogere snelheden en lagere latentie dan gewone verbindingen via internet.

Meer informatie over Azure ExpressRoute en aanbiedingen vindt u hier:

• https://azure.microsoft.com/documentation/services/expressroute/
• https://azure.microsoft.com/pricing/details/expressroute/
• https://azure.microsoft.com/documentation/articles/expressroute-faqs/

Express Route maakt meerdere Azure-abonnementen mogelijk via één ExpressRoute-circuit, zoals hier wordt beschreven

• https://azure.microsoft.com/documentation/articles/expressroute-howto-linkvnet-arm/
• https://azure.microsoft.com/documentation/articles/expressroute-howto-circuit-arm/

Geforceerd tunnelen in het geval van cross-premises

Voor VM's die lid worden van on-premises domeinen via site-naar-site, punt-naar-site of ExpressRoute, moet u ervoor zorgen dat de internetproxy-instellingen ook worden geïmplementeerd voor alle gebruikers in deze VM's. Software die wordt uitgevoerd op deze VM's of gebruikers die een browser gebruiken voor toegang tot internet, gaat standaard niet via de proxy van het bedrijf, maar maakt rechtstreeks via Azure verbinding met internet. Maar zelfs de proxy-instelling is geen 100% oplossing om het verkeer via de proxy van het bedrijf te leiden, omdat het de verantwoordelijkheid van software en services is om te controleren op de proxy. Als software die wordt uitgevoerd op de VM dat niet doet of als een beheerder de instellingen bewerkt, kan verkeer naar internet opnieuw rechtstreeks via Azure naar internet worden omleiding.

Als u een dergelijke directe internetverbinding wilt voorkomen, kunt u Geforceerd tunnelen configureren met site-naar-site-connectiviteit tussen on-premises en Azure. De gedetailleerde beschrijving van de functie Geforceerd tunnelen wordt hier gepubliceerd https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm/

Geforceerd tunnelen met ExpressRoute wordt ingeschakeld door klanten die een standaardroute adverteren via de ExpressRoute BGP-peeringsessies.

Samenvatting van Azure-netwerken

Dit hoofdstuk bevatte veel belangrijke punten over Azure-netwerken. Hier volgt een samenvatting van de belangrijkste punten:

• Met Azure Virtual Networks kunt u een netwerkstructuur in uw Azure-implementatie plaatsen. VNets kunnen tegen elkaar worden geïsoleerd of met behulp van netwerkbeveiligingsgroepen kan verkeer tussen VNets worden beheerd.
• Virtuele Azure-netwerken kunnen worden gebruikt om IP-adresbereiken toe te wijzen aan VM's of vaste IP-adressen toe te wijzen aan VM's
• Als u een site-naar-site- of punt-naar-site-verbinding wilt instellen, moet u eerst een Azure-Virtual Network
• Zodra een virtuele machine is geïmplementeerd, is het niet meer mogelijk om de Virtual Network die aan de VM is toegewezen, te wijzigen

Quota in azure-services voor virtuele machines

We moeten duidelijk zijn over het feit dat de opslag- en netwerkinfrastructuur worden gedeeld tussen VM's met verschillende services in de Azure-infrastructuur. Net als in de eigen datacenters van de klant vindt over-inrichting van sommige infrastructuurbronnen in zekere mate plaats. Het Microsoft Azure Platform maakt gebruik van schijf-, CPU-, netwerk- en andere quota om het resourceverbruik te beperken en consistente en deterministische prestaties te behouden. De verschillende VM-typen (A5, A6, enzovoort) hebben verschillende quota voor het aantal schijven, CPU, RAM en netwerk.

Bij het plannen en in grootte SAP on Azure oplossingen, moet rekening worden gehouden met de quota voor elke grootte van de virtuele machine. De VM-quota worden hier beschreven (Linux) en hier (Windows).

De quota die worden beschreven, vertegenwoordigen de theoretische maximumwaarden. De limiet van IOPS per schijf kan worden bereikt met kleine I/O's (8 kB), maar mogelijk niet met grote I/O's (1 MB). De IOPS-limiet wordt afgedwongen op de granulariteit van één schijf.

Als een ruwe beslissingsstructuur om te bepalen of een SAP-systeem in Azure Virtual Machine Services en de mogelijkheden ervan past of dat een bestaand systeem anders moet worden geconfigureerd om het systeem in Azure te implementeren, kan de onderstaande beslissingsstructuur worden gebruikt:

1. De belangrijkste informatie om mee te beginnen is de SAPS-vereiste voor een bepaald SAP-systeem. De SAPS-vereisten moeten worden gescheiden in het DBMS-onderdeel en het SAP-toepassingsgedeelte, zelfs als het SAP-systeem al on-premises is geïmplementeerd in een configuratie met twee lagen. Voor bestaande systemen kan de SAPS die is gerelateerd aan de hardware die in gebruik is, vaak worden bepaald of geschat op basis van bestaande SAP-benchmarks. De resultaten vindt u op de pagina About SAP Standard Application Benchmarks (Over SAP Standard-toepassingsbenchmarks). Voor nieuw geïmplementeerde SAP-systemen moet u een formaatoefening hebben gemaakt om de SAPS-vereisten van het systeem te bepalen.
2. Voor bestaande systemen moeten het I/O-volume en de I/O-bewerkingen per seconde op de DBMS-server worden gemeten. Voor nieuw geplande systemen moet de formaatoefening voor het nieuwe systeem ook ruwe ideeën geven over de I/O-vereisten aan de dbms-zijde. Als u het niet zeker weet, moet u uiteindelijk een Proof of Concept uitvoeren.
3. Vergelijk de SAPS-vereiste voor de DBMS-server met de SAPS die de verschillende VM-typen van Azure kunnen bieden. De informatie over SAPS van de verschillende typen Azure-VM's wordt beschreven in SAP Note 1928533. De focus moet eerst op de DBMS-VM zijn, omdat de databaselaag de laag in een SAP NetWeaver-systeem is die niet in de meeste implementaties wordt uitschalen. Daarentegen kan de SAP-toepassingslaag worden uitschalen. Als geen van de door SAP ondersteunde Azure VM-typen de vereiste SAPS kan leveren, kan de workload van het geplande SAP-systeem niet worden uitgevoerd in Azure. U moet het systeem on-premises implementeren of u moet het werkbelastingvolume voor het systeem wijzigen.
4. Zoals hier wordt beschreven (Linux) en hier (Windows)dwingt Azure een IOPS-quotum per schijf af, ongeacht of u Standard Storage of Premium Storage. Afhankelijk van het VM-type varieert het aantal gegevensschijven dat kan worden bevestigd. Als gevolg hiervan kunt u een maximumaantal IOPS berekenen dat kan worden bereikt met elk van de verschillende VM-typen. Afhankelijk van de indeling van het databasebestand kunt u schijven stripen om één volume in het gastbesturingssysteem te worden. Als het huidige IOPS-volume van een geïmplementeerd SAP-systeem echter de berekende limieten van het grootste VM-type van Azure overschrijdt en als er geen kans is om te compenseren met meer geheugen, kan de werkbelasting van het SAP-systeem ernstig worden beïnvloed. In dergelijke gevallen kunt u een punt bereikt waarop u het systeem niet in Azure moet implementeren.
5. Met name in SAP-systemen, die on-premises zijn geïmplementeerd in configuraties met twee lagen, is de kans groot dat het systeem in Azure moet worden geconfigureerd in een configuratie met drie lagen. In deze stap moet u controleren of er een onderdeel in de SAP-toepassingslaag is, dat niet kan worden geschaald en niet in de CPU- en geheugenbronnen past die de verschillende Azure VM-typen bieden. Als er inderdaad een dergelijk onderdeel is, kunnen het SAP-systeem en de workload ervan niet worden geïmplementeerd in Azure. Maar als u de SAP-toepassingsonderdelen kunt uitschalen naar meerdere Azure-VM's, kan het systeem worden geïmplementeerd in Azure.

Als de onderdelen van de DBMS- en SAP-toepassingslaag kunnen worden uitgevoerd in Azure-VM's, moet de configuratie worden gedefinieerd met betrekking tot:

• Aantal Azure-VM's
• VM-typen voor de afzonderlijke onderdelen
• Aantal VHD's in DBMS-VM om voldoende IOPS te bieden

Azure-assets beheren

Azure Portal

De Azure Portal is een van de drie interfaces voor het beheren van azure-VM-implementaties. De basisbeheertaken, zoals het implementeren van VM's vanuit afbeeldingen, kunnen worden uitgevoerd via de Azure Portal. Daarnaast zijn het maken van Storage-accounts, virtuele netwerken en andere Azure-onderdelen ook taken die Azure Portal goed kunnen verwerken. Functionaliteit zoals het uploaden van VHD's van on-premises naar Azure of het kopiëren van een VHD binnen Azure zijn taken, waarvoor hulpprogramma's van derden of beheer via PowerShell of CLI zijn vereist.

Beheer- en configuratietaken voor het exemplaar van de virtuele machine zijn mogelijk vanuit de Azure Portal.

Naast het opnieuw opstarten en afsluiten van een virtuele machine kunt u ook gegevensschijven voor het exemplaar van de virtuele machine koppelen, loskoppelen en maken om het exemplaar vast te leggen voor de voorbereiding van de afbeelding en de grootte van het exemplaar van de virtuele machine te configureren.

De Azure Portal biedt basisfunctionaliteit voor het implementeren en configureren van VM's en vele andere Azure-services. Niet alle beschikbare functionaliteit wordt echter gedekt door de Azure Portal. In de Azure Portal is het niet mogelijk om taken uit te voeren zoals:

• VHD's uploaden naar Azure
• VM's kopiëren

Beheer via Microsoft Azure PowerShell-cmdlets

Windows PowerShell is een krachtig en uitgebreid framework dat veel wordt gebruikt door klanten die grotere aantallen systemen in Azure implementeren. Na de installatie van PowerShell-cmdlets op een desktopcomputer, laptop of toegewezen beheerstation, kunnen de PowerShell-cmdlets op afstand worden uitgevoerd.

Het proces voor het inschakelen van een lokale desktop/laptop voor het gebruik van Azure PowerShell-cmdlets en het configureren van deze voor het gebruik met de Azure-abonnementen wordt beschreven in dit artikel.

Meer gedetailleerde stappen voor het installeren, bijwerken en configureren van de Azure PowerShell-cmdlets vindt u ook in De module Azure PowerShell installeren. De klantervaring was tot nu toe dat PowerShell zeker het krachtigere hulpprogramma is voor het implementeren van VM's en het maken van aangepaste stappen in de implementatie van VM's. Alle klanten die SAP-exemplaren in Azure uitvoeren, gebruiken PowerShell-cmdlets als aanvulling op de beheertaken die ze in de Azure Portal uitvoeren of maken zelfs uitsluitend gebruik van PowerShell-cmdlets om hun implementaties in Azure te beheren. Aangezien de azure-specifieke cmdlets dezelfde naamconventie delen als de meer dan 2000 Windows-gerelateerde cmdlets, is het voor Windows-beheerders een eenvoudige taak om deze cmdlets te gebruiken.

Hier ziet u een voorbeeld: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

Implementatie van de Azure-extensie voor SAP (zie hoofdstuk Azure Extension for SAP in dit document) is alleen mogelijk via PowerShell of CLI. Daarom is het verplicht om PowerShell of CLI in te stellen en te configureren bij het implementeren of beheren van een SAP NetWeaver-systeem in Azure.

Omdat Azure meer functionaliteit biedt, worden er nieuwe PowerShell-cmdlets toegevoegd die een update van de cmdlets vereisen. Daarom is het zinvol om de Azure Download-site ten minste eenmaal per maand te controleren op https://azure.microsoft.com/downloads/ een nieuwe versie van de cmdlets. De nieuwe versie wordt geïnstalleerd boven op de oudere versie.

Voor een algemene lijst met Azure-gerelateerde PowerShell-opdrachten raadpleegt u hier: Azure PowerShell documentatie.

Beheer via Microsoft Azure CLI-opdrachten

Voor klanten die Linux gebruiken en Azure-resources willen beheren, is PowerShell mogelijk geen optie. Microsoft biedt Azure CLI als alternatief. De Azure CLI biedt een aantal open source platformoverschrijdende opdrachten voor het werken met het Azure-platform. De Azure CLI biedt vrijwel dezelfde functionaliteit als in de Azure Portal.

Zie voor meer informatie over de installatie, configuratie en het gebruik van CLI-opdrachten om Azure-taken uit te voeren

• De klassieke Azure CLI installeren
• Azure CLI 2.0 installeren
• Virtuele machines implementeren en beheren met behulp van Azure Resource Manager-sjablonen en de Azure CLI
• Gebruik de klassieke Azure CLI voor Mac, Linux en Windows met Azure Resource Manager

Eerste stappen voor het plannen van een implementatie

De eerste stap in de implementatieplanning is NIET om te controleren op VM's die beschikbaar zijn om SAP uit te voeren. De eerste stap kan tijdrovend zijn, maar het belangrijkste is om samen met nalevings- en beveiligingsteams in uw bedrijf te werken aan de grensvoorwaarden voor het implementeren van welk type SAP-workload of bedrijfsproces in de openbare cloud. Als uw bedrijf eerder andere software in Azure heeft geïmplementeerd, kan het proces eenvoudig zijn. Als uw bedrijf meer aan het begin van het traject staat, zijn er mogelijk grotere discussies nodig om te bepalen wat de grensvoorwaarden en beveiligingsvoorwaarden zijn, waardoor bepaalde SAP-gegevens en SAP-bedrijfsprocessen kunnen worden gehost in de openbare cloud.

Als nuttige hulp kunt u naar Nalevingsaanbiedingen van Microsoft wijzen voor een lijst met nalevingsaanbiedingen die Microsoft kan bieden.

Andere punten van zorg, zoals gegevensversleuteling voor data-at-rest of andere versleuteling in de Azure-service, worden beschreven in Overzicht van Azure-versleuteling.

Vergeet deze fase van het project niet in uw planning. Alleen wanneer u een overeenkomst en regels voor dit onderwerp hebt, moet u naar de volgende stap gaan. Dit is de planning van de netwerkarchitectuur die u in Azure implementeert.

Verschillende manieren om VM's voor SAP in Azure te implementeren

In dit hoofdstuk leert u de verschillende manieren om een VM in Azure te implementeren. In dit hoofdstuk worden aanvullende voorbereidingsprocedures en de verwerking van VHD's en VM's in Azure behandeld.

Implementatie van VM's voor SAP

Microsoft Azure biedt meerdere manieren om VM's en gekoppelde schijven te implementeren. Het is dus belangrijk om de verschillen te begrijpen, omdat de voorbereidingen van de VM's afhankelijk van de implementatiemethode kunnen verschillen. In het algemeen bekijken we de volgende scenario's:

Een VM verplaatsen van on-premises naar Azure met een niet-ge generaliseerde schijf

U bent van plan om een specifiek SAP-systeem van on-premises naar Azure te verplaatsen. U kunt dit doen door de VHD te uploaden die het besturingssysteem, de binaire SAP-bestanden en DBMS-bestanden bevat, plus de VHD's met de gegevens en logboekbestanden van de DBMS naar Azure. In tegenstelling tot scenario 2hieronder bewaarde u de hostnaam, SAP SID en SAP-gebruikersaccounts in de Azure-VM zoals deze zijn geconfigureerd in de on-premises omgeving. Daarom is het niet nodig om de afbeelding te generaliseren. Zie de hoofdstukken Voorbereiding voor het verplaatsen van een VM van on-premises naar Azure met een niet-ge generaliseerde schijf van dit document voor on-premises voorbereidingsstappen en het uploaden van niet-ge generaliseerde VM's of VHD's naar Azure. Hoofdstuk Scenario 3 lezen: Een VM van on-premises verplaatsen met behulp van een niet-ge generaliseerde Azure-VHD met SAP in de implementatiehandleiding voor gedetailleerde stappen voor het implementeren van een dergelijke installatie afbeelding in Azure.

Een andere optie die we in deze handleiding niet in detail zullen bespreken, is het gebruik van Azure Site Recovery om SAP NetWeaver-toepassingsservers en SAP NetWeaver Central-services te repliceren naar Azure. We raden u niet aan om Azure Site Recovery databaselaag te gebruiken en in plaats van databasespecifieke replicatiemechanismen te gebruiken, zoals HANA-systeemreplicatie. Zie het hoofdstuk SAP beveiligen van de handleiding Over herstel na noodherstel voor on-premises apps voor meer informatie.

Een VM implementeren met een klantspecifieke afbeelding

Vanwege specifieke patchvereisten van uw besturingssysteem- of DBMS-versie, voldoen de geleverde afbeeldingen in de Azure Marketplace mogelijk niet aan uw behoeften. Daarom moet u mogelijk een VM maken met behulp van uw eigen VM-afbeelding voor het besturingssysteem/dbms, die enkele keren later kan worden geïmplementeerd. Om een dergelijke persoonlijke afbeelding voor te bereiden op duplicatie, moeten de volgende items worden overwogen:

Windows

Lees voor meer informatie Upload een gegeneraliseerde Windows-VHD en gebruik deze om nieuwe VM's te maken in Azure De Windows-instellingen (zoals Windows SID en hostnaam) moeten worden geabstraheerd/gegeneraliseerd op de on-premises VM via de sysprep-opdracht.

Linux

Volg de stappen in deze artikelen voor SUSE, Red Hat of Oracle Linuxom een VHD voor te bereiden die moet worden geüpload naar Azure.

Als u AL SAP-inhoud hebt geïnstalleerd op uw on-premises VM (met name voor systemen met twee lagen), kunt u de SAP-systeeminstellingen aanpassen na de implementatie van de Azure-VM via de procedure voor het wijzigen van de exemplaarnaam die wordt ondersteund door sap Software Provisioning Manager (SAP Note [1619720).] Zie de hoofdstukken Preparation for deploying a VM with a customer-specific image for SAP (Voorbereiding voor het implementeren van een VM met een klantspecifieke afbeelding voor SAP) en Uploading a VHD from on-premises to Azure (Een VHD uploaden van on-premises naar Azure) van dit document voor on-premises voorbereidingsstappen en het uploaden van een ge generaliseerde VM naar Azure. Lees het hoofdstuk Scenario 2: Een VM implementeren met een aangepaste installatier voor SAP in de implementatiehandleiding voor gedetailleerde stappen voor het implementeren van een dergelijke installatielijn in Azure.

Een VM buiten de VM Azure Marketplace

U wilt een door Microsoft of derden geleverde VM-afbeelding van de Azure Marketplace om uw VM te implementeren. Nadat u uw VM in Azure hebt geïmplementeerd, volgt u dezelfde richtlijnen en hulpprogramma's voor het installeren van de SAP-software en/of DBMS in uw VM als in een on-premises omgeving. Zie het hoofdstuk Scenario 1: Een VM implementeren buiten de Azure Marketplace voor SAP in de implementatiehandleidingvoor een gedetailleerde beschrijving van de implementatie.

VM's voorbereiden met SAP voor Azure

Voordat u VM's uploadt naar Azure, moet u ervoor zorgen dat de VM's en VHD's voldoen aan bepaalde vereisten. Er zijn kleine verschillen, afhankelijk van de implementatiemethode die wordt gebruikt.

Voorbereiding voor het verplaatsen van een VM van on-premises naar Azure met een niet-ge generaliseerde schijf

Een veelgebruikte implementatiemethode is het verplaatsen van een bestaande VM waarop een SAP-systeem wordt uitgevoerd van on-premises naar Azure. Deze VM en het SAP-systeem in de VM moeten alleen worden uitgevoerd in Azure met dezelfde hostnaam en waarschijnlijk dezelfde SAP SID. In dit geval mag het gast-besturingssysteem van de VM niet worden ge generaliseerd voor meerdere implementaties. Als het on-premises netwerk is uitgebreid naar Azure, kunnen zelfs dezelfde domeinaccounts binnen de VM worden gebruikt als voorheen on-premises.

Vereisten bij het voorbereiden van uw eigen Azure VM-schijf zijn:

• Oorspronkelijk kon de VHD met het besturingssysteem alleen een maximale grootte van 127 GB hebben. Deze beperking is eind maart 2015 opgehefd. Nu kan de VHD met het besturingssysteem maximaal 1 TB groot zijn, net als elke andere Azure Storage gehoste VHD.
• Deze moet de vaste VHD-indeling hebben. Dynamische VHD's of VHD's in VHDx-indeling worden nog niet ondersteund in Azure. Dynamische VHD's worden geconverteerd naar statische VHD's wanneer u de VHD uploadt met PowerShell-commandlets of CLI
• VHD's, die aan de VM zijn bevestigd en opnieuw moeten worden bevestigd in Azure, moeten ook een vaste VHD-indeling hebben. Lees dit artikel voor de groottelimieten van gegevensschijven. Dynamische VHD's worden geconverteerd naar statische VHD's wanneer u de VHD uploadt met PowerShell-commandlets of CLI
• Voeg nog een lokaal account met beheerdersbevoegdheden toe, dat kan worden gebruikt door Microsoft Ondersteuning of dat kan worden toegewezen als context voor het uitvoeren van services en toepassingen totdat de VM is geïmplementeerd en meer geschikte gebruikers kunnen worden gebruikt.
• Voeg andere lokale accounts toe, aangezien deze mogelijk nodig zijn voor het specifieke implementatiescenario.

Windows

In dit scenario is geen generalisatie (sysprep) van de VM vereist voor het uploaden en implementeren van de VM in Azure. Zorg ervoor dat station D:\ wordt niet gebruikt. Stel schijfautomount in voor gekoppelde schijven, zoals beschreven in hoofdstuk Setting automount for attached disks in dit document.

Linux

In dit scenario is geen generalisatie (waagent -deprovision) van de VM vereist voor het uploaden en implementeren van de VM in Azure. Zorg ervoor dat /mnt/resource niet wordt gebruikt en dat ALLE schijven zijn bevestigd via uuid. Zorg er voor de besturingssysteemschijf voor dat de bootloader-vermelding ook de op uuid gebaseerde mount weerspiegelt.

Voorbereiding voor het implementeren van een VM met een klantspecifieke afbeelding voor SAP

VHD-bestanden die een ge generaliseerd besturingssysteem bevatten, worden opgeslagen in containers op Azure Storage-accounts of als managed disk-afbeeldingen. U kunt een nieuwe VM implementeren op basis van een dergelijke installatie afbeelding door te verwijzen naar de VHD- of Managed Disk-installatier als bron in uw implementatiesjabloonbestanden, zoals beschreven in het hoofdstuk Scenario 2: Een VM implementeren met een aangepaste installatie afbeelding voor SAP van de implementatiehandleiding .

Vereisten bij het voorbereiden van uw eigen Azure VM-afbeelding zijn:

• Oorspronkelijk kon de VHD met het besturingssysteem alleen een maximale grootte van 127 GB hebben. Deze beperking is eind maart 2015 opgehefd. Nu kan de VHD met het besturingssysteem maximaal 1 TB groot zijn, net als elke andere Azure Storage gehoste VHD.
• Deze moet de vaste VHD-indeling hebben. Dynamische VHD's of VHD's in VHDx-indeling worden nog niet ondersteund in Azure. Dynamische VHD's worden geconverteerd naar statische VHD's wanneer u de VHD uploadt met PowerShell-commandlets of CLI
• VHD's, die aan de VM zijn bevestigd en opnieuw moeten worden bevestigd in Azure, moeten ook een vaste VHD-indeling hebben. Lees dit artikel voor de groottelimieten van gegevensschijven. Dynamische VHD's worden geconverteerd naar statische VHD's wanneer u de VHD uploadt met PowerShell-commandlets of CLI
• Voeg andere lokale accounts toe, aangezien deze mogelijk nodig zijn voor het specifieke implementatiescenario.
• Als de installatiekopie een installatie van SAP NetWeaver bevat en het wijzigen van de naam van de hostnaam van de oorspronkelijke naam op het moment van de Azure-implementatie waarschijnlijk is, is het raadzaam om de nieuwste versies van de SAP Software Provisioning Manager-dvd naar de sjabloon te kopiëren. Hiermee kunt u eenvoudig de door SAP geleverde functie voor naamswijziging gebruiken om de gewijzigde hostnaam aan te passen en/of de SID van het SAP-systeem in de geïmplementeerde VM-installatiekopie te wijzigen zodra een nieuwe kopie is gestart.

Windows

Zorg ervoor dat station D:\ wordt niet gebruikt Schijf automatisch koppelen instellen voor gekoppelde schijven, zoals beschreven in het hoofdstuk Setting automount for attached disks in dit document.

Linux

Zorg ervoor dat /mnt/resource niet wordt gebruikt en dat ALLE schijven zijn bevestigd via uuid. Voor de besturingssysteemschijf moet u ervoor zorgen dat de bootloader-vermelding ook de op uuid gebaseerde mount weerspiegelt.

• SAP GUI (voor administratieve en installatiedoeleinden) kan vooraf worden geïnstalleerd in een dergelijke sjabloon.
• Andere software die nodig is om de VM's in cross-premises scenario's uit te voeren, kan worden geïnstalleerd zolang deze software kan werken met de naam van de VM.

Als de VM voldoende is voorbereid om algemeen te zijn en uiteindelijk onafhankelijk is van accounts/gebruikers die niet beschikbaar zijn in het beoogde Azure-implementatiescenario, wordt de laatste voorbereidingsstap voor het generaliseren van een dergelijke installatie afbeelding uitgevoerd.

Een VM generaliseren

Windows

De laatste stap is het aanmelden bij een VM met een beheerdersaccount. Open als Windows een opdrachtvenster. Ga naar %windir%\windows\system32\sysprep en voer de sysprep.exe. Er wordt een klein venster weergegeven. Het is belangrijk om de optie Generaliseren in te stellen (de standaardinstelling is uitgeschakeld) en de optie Afsluiten te wijzigen van de standaardwaarde 'Opnieuw opstarten' in 'afsluiten'. In deze procedure wordt ervan uitgenomen dat het sysprep-proces on-premises wordt uitgevoerd in het gast-besturingssysteem van een VM. Als u de procedure wilt uitvoeren met een VM die al wordt uitgevoerd in Azure, volgt u de stappen die in dit artikel worden beschreven.

Linux

Een virtuele Linux-machine vastleggen om deze als Resource Manager-sjabloon te gebruiken

VM's en VHD's overdragen tussen on-premises naar Azure

Omdat het uploaden van VM-afbeeldingen en -schijven naar Azure niet mogelijk is via de Azure Portal, moet u Azure PowerShell cmdlets of CLI gebruiken. Een andere mogelijkheid is het gebruik van het hulpprogramma 'AzCopy'. Het hulpprogramma kan VHD's kopiëren tussen on-premises en Azure (in beide richtingen). Het kan ook VHD's kopiëren tussen Azure-regio's. Raadpleeg deze documentatie voor het downloaden en gebruiken van AzCopy.

Een derde alternatief is het gebruik van verschillende GUI-hulpprogramma's van derden. Zorg er echter voor dat deze hulpprogramma's Ondersteuning bieden voor Azure Page Blobs. Voor onze doeleinden moeten we Azure Page Blob Store gebruiken (de verschillen worden beschreven in Understanding block blobs, append blobs, and page blobs(Inzicht in blok-blobs, blobs toevoegen en pagina-blobs). De hulpprogramma's van Azure zijn ook efficiënt in het comprimeren van de VM's en VHD's, die moeten worden geüpload. Dit is belangrijk omdat deze efficiëntie in compressie de uploadtijd vermindert (wat toch varieert, afhankelijk van de uploadkoppeling naar internet van de on-premises faciliteit en de doelregio van de Azure-implementatie). Het is een goede veronderstelling dat het uploaden van een VM of VHD van de Europese locatie naar de Amerikaanse Azure-datacenters langer duurt dan het uploaden van dezelfde VM's/VHD's naar de Europese Azure-datacenters.

Een VHD van on-premises uploaden naar Azure

Als u een bestaande VM of VHD wilt uploaden vanuit het on-premises netwerk, moet een dergelijke VM of VHD voldoen aan de vereisten zoals vermeld in het hoofdstuk Voorbereiding voor het verplaatsen van een VM van on-premises naar Azure met een niet-ge generaliseerde schijf van dit document.

Een dergelijke VM hoeft NIET te worden ge generaliseerd en kan worden geüpload in de status en vorm die deze heeft na het afsluiten aan de on-premises zijde. Hetzelfde geldt voor extra VHD's, die geen besturingssysteem bevatten.

Een VHD uploaden en er een Azure-schijf van maken

In dit geval willen we een VHD uploaden, met of zonder besturingssysteem, en deze als een gegevensschijf aan een VM monteren of als besturingssysteemschijf gebruiken. Dit is een proces met meerdere stappen

PowerShell

• Meld u aan bij uw abonnement met Verbinding maken-AzAccount
• Stel het abonnement van uw context in met Set-AzContext en de parameter SubscriptionId of SubscriptionName. Zie Set-AzContext
• Upload VHD met Add-AzVhd toevoegen aan een Azure Storage-account - zie Add-AzVhd
• (Optioneel) Een beheerde schijf maken op de VHD met New-AzDisk - zie New-AzDisk
• Stel de besturingssysteemschijf van een nieuwe VM-configuratie in op de VHD of beheerde schijf met Set-AzVMOSDisk - zie Set-AzVMOSDisk
• Een nieuwe VM maken op de VM-configuratie met New-AzVM - zie New-AzVM
• Een gegevensschijf toevoegen aan een nieuwe VM met Add-AzVMDataDisk - zie Add-AzVMDataDisk

Azure-CLI

• Meld u aan bij uw abonnement met az login
• Selecteer uw abonnement met az <subscription name or id > account set --subscription
• Upload de VHD met az storage blob upload - zie De Azure CLI gebruiken met Azure Storage.
• (Optioneel) Maak een beheerde schijf van de VHD met az disk create - zie az disk.
• Maak een nieuwe VM die de geüploade VHD of beheerde schijf opgeeft als besturingssysteemschijf met az vm create en parameter --attach-os-disk
• Een gegevensschijf toevoegen aan een nieuwe VM met az vm disk attach en parameter --new

Sjabloon

• Upload VHD maken met PowerShell of Azure CLI
• (Optioneel) Een beheerde schijf maken op de VHD met PowerShell, Azure CLI of de Azure Portal
• Implementeer de VM met een JSON-sjabloon die verwijst naar de VHD, zoals wordt weergegeven in dit voorbeeld van een JSON-sjabloon of met behulp van Managed Disks, zoals wordt weergegeven in deze JSON-voorbeeldsjabloon.

Implementatie van een VM-installatie afbeelding

Als u een bestaande VM of VHD wilt uploaden vanuit het on-premises netwerk om deze te kunnen gebruiken als een Azure VM-afbeelding, moet een dergelijke VM of VHD voldoen aan de vereisten die worden vermeld in het hoofdstuk Voorbereiding voor het implementeren van een VM met een klantspecifieke afbeelding voor SAP van dit document.

• Gebruik sysprep op Windows of waagent -deprovision in Linux om uw VM te generaliseren. Zie Technische naslag voor Sysprep voor Windows of Een virtuele Linux-machine vastleggen om te gebruiken als een Resource Manager-sjabloon voor Linux
• Meld u aan bij uw abonnement met Verbinding maken-AzAccount
• Stel het abonnement van uw context in met Set-AzContext en de parameter SubscriptionId of SubscriptionName. Zie Set-AzContext
• Upload VHD met Add-AzVhd toevoegen aan een Azure Storage-account - zie Add-AzVhd
• (Optioneel) Een beheerde-schijfafbeelding maken op de VHD met New-AzImage - zie New-AzImage
• Stel de besturingssysteemschijf van een nieuwe VM-configuratie in op de
  • VHD met Set-AzVMOSDisk -SourceImageUri -CreateOption fromImage - zie Set-AzVMOSDisk
  • Managed Disk Image Set-AzVMSourceImage - zie Set-AzVMSourceImage
• Een nieuwe VM maken op de VM-configuratie met New-AzVM - zie New-AzVM

Azure-CLI

• Gebruik sysprep op Windows of waagent -deprovision in Linux om uw VM te generaliseren. Zie Technische naslag voor Sysprep voor Windows of Een virtuele Linux-machine vastleggen om te gebruiken als een Resource Manager-sjabloon voor Linux
• Meld u aan bij uw abonnement met az login
• Selecteer uw abonnement met az <subscription name or id > account set --subscription
• Upload de VHD met az storage blob upload - zie De Azure CLI gebruiken met Azure Storage.
• (Optioneel) Maak een beheerde-schijfafbeelding van de VHD met az image create - zie az image.
• Maak een nieuwe VM die de geüploade VHD of managed disk-afbeelding opgeeft als besturingssysteemschijf met az vm create en parameter --image

Sjabloon

• Gebruik sysprep op Windows of waagent -deprovision in Linux om uw VM te generaliseren. Zie Technische naslag voor Sysprep voor Windows of Een virtuele Linux-machine vastleggen om te gebruiken als een Resource Manager-sjabloon voor Linux
• Upload VHD maken met PowerShell of Azure CLI
• (Optioneel) Een beheerde-schijfafbeelding maken op de VHD met PowerShell, Azure CLI of de Azure Portal
• Implementeer de VM met een JSON-sjabloon die verwijst naar de VHD van de afbeelding, zoals wordt weergegeven in deze JSON-voorbeeldsjabloon of met behulp van de managed disk-afbeelding, zoals wordt weergegeven in dit voorbeeld van een JSON-sjabloon.

VHD's of Managed Disks downloaden naar on-premises

Azure Infrastructure as a Service is geen eenstrate waar alleen VHD's en SAP-systemen kunnen worden geüpload. U kunt SAP-systemen ook vanuit Azure terug verplaatsen naar de on-premises wereld.

Tijdens het downloaden kunnen de VHD's of Managed Disks niet actief zijn. Zelfs bij het downloaden van schijven die aan VM's zijn bevestigd, moet de VM worden afgesloten en moet de toewijzing van de VM worden verbreed. Als u alleen de inhoud van de database wilt downloaden, die vervolgens moet worden gebruikt om een nieuw systeem on-premises in te stellen en als het acceptabel is dat u tijdens de download en de installatie van het nieuwe systeem dat het systeem in Azure nog steeds operationeel kan zijn, lange downtime kunt voorkomen door een gecomprimeerde databaseback-up naar een schijf uit te voeren en alleen die schijf te downloaden in plaats van het besturingssysteem te downloaden basis-VM.

PowerShell

• Een beheerde schijf downloaden U moet eerst toegang krijgen tot de onderliggende blob van de beheerde schijf. Vervolgens kunt u de onderliggende blob kopiëren naar een nieuw opslagaccount en de blob downloaden uit dit opslagaccount.

  $access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
  $key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
  $destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
  Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
  # Wait for blob copy to finish
  Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
  Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
  # Wait for download to finish
  Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>
  

• Een VHD downloaden Zodra het SAP-systeem is gestopt en de VM is afgesloten, kunt u de PowerShell-cmdlet op het on-premises doel gebruiken om de VHD-schijven weer te downloaden naar de Save-AzVhd on-premises wereld. Daarvoor hebt u de URL van de VHD nodig. Deze vindt u in de sectie Opslag van de Azure Portal (moet naar het Storage-account en de opslagcontainer waar de VHD is gemaakt) en u moet weten waar de VHD naartoe moet worden gekopieerd.

  Vervolgens kunt u de opdracht gebruiken door de parameter SourceUri te definiëren als de URL van de te downloaden VHD en het LocalFilePath als de fysieke locatie van de VHD (inclusief de naam). De opdracht kan er als volgende uitzien:

  Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
  

  Zie Save-AzVhdSave-AzVhd meer informatie over de cmdlet .

Azure CLI

• Een beheerde schijf downloaden U moet eerst toegang krijgen tot de onderliggende blob van de beheerde schijf. Vervolgens kunt u de onderliggende blob kopiëren naar een nieuw opslagaccount en de blob downloaden uit dit opslagaccount.

  az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
  az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
  az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"
  

• Een VHD downloaden Zodra het SAP-systeem is gestopt en de VM is afgesloten, kunt u de Azure CLI-opdracht op het on-premises doel gebruiken om de VHD-schijven weer te downloaden naar de _azure storage blob download_ on-premises wereld. Als u dit wilt doen, hebt u de naam en de container van de VHD nodig, die u kunt vinden in de sectie 'Storage' van de Azure Portal (moet naar het Storage-account en de opslagcontainer waar de VHD is gemaakt) vinden en moet u weten waar de VHD naartoe moet worden gekopieerd.

  Vervolgens kunt u de opdracht gebruiken door de parameters blob en container van de VHD te definiëren die u wilt downloaden en de bestemming als de fysieke doellocatie van de VHD (inclusief de naam). De opdracht kan er als volgende uitzien:

  az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
  

VM's en schijven overdragen binnen Azure

SAP-systemen kopiëren in Azure

Een SAP-systeem of zelfs een toegewezen DBMS-server die een SAP-toepassingslaag ondersteunt, bestaat waarschijnlijk uit verschillende schijven die het besturingssysteem met de binaire bestanden of de gegevens en logboekbestanden van de SAP-database bevatten. Noch de Azure-functionaliteit voor het kopiëren van schijven, noch de Azure-functionaliteit voor het opslaan van schijven op een lokale schijf heeft een synchronisatiemechanisme waarmee op een consistente manier momentopnamen worden gemaakt van meerdere schijven. Daarom is de status van de gekopieerde of opgeslagen schijven anders, zelfs als deze aan dezelfde VM zijn bevestigd. Dit betekent dat in het concrete geval dat er verschillende gegevens en logboekbestanden in de verschillende schijven zijn opgenomen, de database uiteindelijk inconsistent zou zijn.

Conclusie: Als u schijven wilt kopiëren of opslaan die deel uitmaken van een SAP-systeemconfiguratie, moet u het SAP-systeem stoppen en ook de geïmplementeerde VM afsluiten. Alleen dan kunt u de set schijven kopiëren of downloaden om een kopie van het SAP-systeem te maken in Azure of on-premises.

Gegevensschijven kunnen worden opgeslagen als VHD-bestanden in een Azure Storage-account en kunnen rechtstreeks worden gekoppeld aan een virtuele machine of worden gebruikt als een afbeelding. In dit geval wordt de VHD gekopieerd naar een andere locatie voordat deze aan de virtuele machine wordt gekoppeld. De volledige naam van het VHD-bestand in Azure moet uniek zijn binnen Azure. Zoals eerder vermeld, is de naam een driedelige naam die eruitziet als:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Gegevensschijven kunnen ook worden Managed Disks. In dit geval wordt de beheerde schijf gebruikt om een nieuwe beheerde schijf te maken voordat deze aan de virtuele machine wordt gekoppeld. De naam van de beheerde schijf moet uniek zijn binnen een resourcegroep.

PowerShell

U kunt de Azure PowerShell gebruiken om een VHD te kopiëren, zoals wordt weergegeven in dit artikel. Als u een nieuwe beheerde schijf wilt maken, gebruikt New-AzDiskConfig en New-AzDisk zoals wordt weergegeven in het volgende voorbeeld.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config

Azure CLI

U kunt Azure CLI gebruiken om een VHD te kopiëren. Als u een nieuwe beheerde schijf wilt maken, gebruikt u az disk create, zoals wordt weergegeven in het volgende voorbeeld.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>

Azure Storage hulpprogramma's

• https://storageexplorer.com/

Professional-edities van Azure Storage Explorers vindt u hier:

• https://www.cerebrata.com/
• https://clumsyleaf.com/products/cloudxplorer

De kopie van een VHD zelf binnen een opslagaccount is een proces dat slechts enkele seconden duurt (vergelijkbaar met SAN-hardware voor het maken van momentopnamen met luie kopie en kopie bij schrijven). Nadat u een kopie van het VHD-bestand hebt, kunt u het koppelen aan een virtuele machine of deze gebruiken als een afbeelding om kopieën van de VHD aan virtuele machines te koppelen.

PowerShell

# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM

Azure CLI

# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Schijven kopiëren tussen Azure Storage Accounts

Deze taak kan niet worden uitgevoerd op de Azure Portal. U kunt Azure PowerShell cmdlets, Azure CLI of een opslagbrowser van derden gebruiken. Met de PowerShell-cmdlets of CLI-opdrachten kunt u blobs maken en beheren, waaronder de mogelijkheid om blobs asynchroon te kopiëren tussen Storage-accounts en tussen regio's binnen het Azure-abonnement.

PowerShell

U kunt ook VHD's kopiëren tussen abonnementen. Lees dit artikel voor meer informatie.

De basisstroom van de PowerShell-cmdlet-logica ziet er als volgende uit:

• Een opslagaccountcontext maken voor het bronopslagaccount met New-AzStorageContext - zie New-AzStorageContext
• Een opslagaccountcontext maken voor het doelopslagaccount met New-AzStorageContext - zie New-AzStorageContext
• Start de kopie met

Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>

• Controleer de status van de kopie in een lus met

Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>

• Koppel de nieuwe VHD aan een virtuele machine zoals hierboven wordt beschreven.

Zie dit artikel voor voorbeelden.

Azure CLI

• Start de kopie met

az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>

• Controleer de status als de kopie zich nog steeds in een lus met

az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>

• Koppel de nieuwe VHD aan een virtuele machine zoals hierboven wordt beschreven.

Schijfverwerking

VM-/schijfstructuur voor SAP-implementaties

In het ideale voorbeeld is de verwerking van de structuur van een VM en de bijbehorende schijven eenvoudig. In on-premises installaties hebben klanten veel manieren ontwikkeld om een serverinstallatie te structureren.

• Eén basisschijf, die het besturingssysteem en alle binaire bestanden van de DBMS en/of SAP bevat. Sinds maart 2015 kan deze schijf maximaal 1 TB groot zijn in plaats van eerdere beperkingen die de schijf beperken tot 127 GB.
• Een of meer schijven, die het DBMS-logboekbestand van de SAP-database en het logboekbestand van het tijdelijke opslaggebied van DBMS bevatten (als de DBMS dit ondersteunt). Als de IOPS-vereisten voor het databaselogboek hoog zijn, moet u meerdere schijven stripen om het vereiste IOPS-volume te bereiken.
• Een aantal schijven met een of twee databasebestanden van de SAP-database en de tijdelijke DBMS-gegevensbestanden (als de DBMS dit ondersteunt).

Windows

Bij veel klanten hebben we configuraties gezien waarbij bijvoorbeeld binaire SAP- en DBMS-bestanden niet zijn geïnstalleerd op de c:\ station waar het besturingssysteem is geïnstalleerd. Er zijn verschillende redenen hiervoor, maar toen we terug gingen naar de hoofdmap, was het meestal dat de stations klein waren en dat er 10-15 jaar geleden extra ruimte nodig was voor upgrades van het besturingssysteem. Beide voorwaarden zijn tegenwoordig niet meer van toepassing. Vandaag de c:\ station kan worden gebruikt op grote volumeschijven of VM's. Om implementaties eenvoudig in hun structuur te houden, is het raadzaam om het volgende implementatiepatroon te volgen voor SAP NetWeaver-systemen in Azure

Het Windows besturingssysteembestand moet zich op het station D: (niet-permanente schijf)

Linux

Plaats het Linux-wisselbestand onder /mnt /mnt/resource in Linux, zoals beschreven in dit artikel. Het wisselbestand kan worden geconfigureerd in het configuratiebestand van de Linux-agent /etc/waagent.conf. Voeg de volgende instellingen toe of wijzig deze:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Als u de wijzigingen wilt activeren, moet u de Linux-agent opnieuw starten met

sudo service waagent restart

Lees SAP Note 1597355 voor meer informatie over de aanbevolen wisselbestandsgrootte

Het aantal schijven dat wordt gebruikt voor de DBMS-gegevensbestanden en het type Azure Storage deze schijven worden gehost, moet worden bepaald door de IOPS-vereisten en de vereiste latentie. Exacte quota worden beschreven in dit artikel (Linux) en dit artikel (Windows).

De ervaring met SAP-implementaties in de afgelopen twee jaar heeft ons enkele lessen geleerd, die als volgt kunnen worden samengevat:

• IOPS-verkeer naar verschillende gegevensbestanden is niet altijd hetzelfde, omdat bestaande klantsystemen mogelijk gegevensbestanden van verschillende grootte hebben die de SAP-database(s) vertegenwoordigen. Als gevolg hiervan bleek het beter te zijn met behulp van een RAID-configuratie over meerdere schijven om de gegevensbestanden te plaatsen die LUN's uit deze bestanden halen. Er waren situaties, met name met Azure Standard Storage waarbij een IOPS-snelheid het quotum van één schijf heeft bereikt ten opzichte van het DBMS-transactielogboek. In dergelijke scenario's wordt het gebruik van Premium Storage aanbevolen of het samenvoegen van meerdere Standard Storage schijven met een softwarestree.

Windows

• Aanbevolen procedures voor prestaties voor SQL Server op virtuele machines van Azure

Linux

• Software RAID configureren in Linux
• Een LVM configureren op een virtuele Linux-machine in Azure

• Premium Storage prestaties zijn aanzienlijk beter, met name voor kritieke schrijf schrijftransacties in transactielogboek. Voor SAP-scenario's die naar verwachting productie leveren, zoals prestaties, is het raadzaam om gebruik te maken van VM-Series die gebruik kunnen maken van Azure Premium Storage.

Houd er rekening mee dat de schijf, die het besturingssysteem bevat, en zoals aanbevolen, ook de binaire bestanden van SAP en de database (basis-VM) niet meer beperkt zijn tot 127 GB. Het kan nu maximaal 1 TB groot zijn. Dit moet voldoende ruimte zijn om alle benodigde bestanden te behouden, inclusief bijvoorbeeld SAP-batch-taaklogboeken.

Raadpleeg de DBMS-implementatiehandleiding voor meer suggesties en meer informatie, met name voor DBMS-VM's

Schijfverwerking

In de meeste scenario's moet u extra schijven maken om de SAP-database in de VM te implementeren. We hebben het gehad over de overwegingen voor het aantal schijven in hoofdstuk VM/schijfstructuur voor SAP-implementaties van dit document. Met Azure Portal kunt u schijven koppelen en loskoppelen zodra een basis-VM is geïmplementeerd. De schijven kunnen worden gekoppeld/losgekoppeld wanneer de VM actief is en wordt uitgevoerd en wanneer deze is gestopt. Bij het koppelen van een schijf biedt Azure Portal aan om een lege schijf of een bestaande schijf te koppelen, die op dit moment niet is gekoppeld aan een andere VM.

Opmerking: schijven kunnen op elk moment slechts aan één VM worden gekoppeld.

Tijdens de implementatie van een nieuwe virtuele machine kunt u beslissen of u Managed Disks of uw schijven op uw Azure Storage plaatsen. Als u een Premium Storage wilt gebruiken, raden we u aan om Managed Disks.

Vervolgens moet u beslissen of u een nieuwe en lege schijf wilt maken of dat u een bestaande schijf wilt selecteren die eerder is geüpload en nu moet worden gekoppeld aan de VM.

BELANGRIJK: U wilt Host-Caching niet gebruiken met Azure Standard Storage. Laat de hostcachevoorkeur op de standaardwaarde GEEN staan. Met Azure Premium Storage moet u Read Caching inschakelen als het I/O-kenmerk voornamelijk wordt gelezen als typisch I/O-verkeer voor databasegegevensbestanden. In het geval van een databasetransactielogboekbestand wordt geen caching aanbevolen.

Windows

Een gegevensschijf koppelen in de Azure Portal

Als er schijven zijn gekoppeld, moet u zich aanmelden bij de VM om de Windows schijfbeheer te openen. Als automount niet is ingeschakeld zoals aanbevolen in het hoofdstuk Automountinstellen voor gekoppelde schijven, moet het zojuist gekoppelde volume online worden gezet en worden initialiseerd.

Linux

Als er schijven zijn gekoppeld, moet u zich aanmelden bij de VM en de schijven initialiseren zoals beschreven in dit artikel

Als de nieuwe schijf een lege schijf is, moet u de schijf ook formatteren. Voor opmaak, met name voor DBMS-gegevens en logboekbestanden, gelden dezelfde aanbevelingen als voor bare-metalimplementaties van de DBMS.

Een Azure Storage biedt geen oneindige resources op het gebied van I/O-volume, IOPS en gegevensvolume. Dit wordt meestal het meest beïnvloed door dbms-VM's. U kunt het beste een afzonderlijk Storage-account gebruiken voor elke VM als u enkele VM's met een hoog I/O-volume wilt implementeren om binnen de limiet van het Azure Storage-accountvolume te blijven. Anders moet u zien hoe u deze VM's kunt in balans brengen tussen verschillende Storage-accounts zonder de limiet van elk account Storage bereiken. Meer informatie wordt besproken in de DBMS-implementatiehandleiding. Houd ook rekening met deze beperkingen voor pure sap-toepassingsserver-VM's of andere VM's, waarvoor uiteindelijk extra VHD's nodig kunnen zijn. Deze beperkingen zijn niet van toepassing als u Managed Disk gebruikt. Als u van plan bent om Premium Storage te gebruiken, raden we u aan Beheerde schijf te gebruiken.

Een ander onderwerp, dat relevant is voor Storage-accounts, is of de VHD's in een Storage-account geo-replicatie krijgen. Geo-replicatie wordt ingeschakeld of uitgeschakeld op Storage accountniveau en niet op VM-niveau. Als geo-replicatie is ingeschakeld, worden de VHD's binnen het Storage-account gerepliceerd naar een ander Azure-datacenter binnen dezelfde regio. Voordat u hier een beslissing over neemt, moet u nadenken over de volgende beperking:

Geo-replicatie van Azure werkt lokaal op elke VHD in een VM en repliceert de I/O's niet in chronologische volgorde over meerdere VHD's in een VM. Daarom worden de VHD die de basis-VM vertegenwoordigt en eventuele extra VHD's die aan de VM zijn gekoppeld, onafhankelijk van elkaar gerepliceerd. Dit betekent dat er geen synchronisatie is tussen de wijzigingen in de verschillende VHD's. Het feit dat de I/O's onafhankelijk van de volgorde waarin ze zijn geschreven worden gerepliceerd, betekent dat geo-replicatie niet van waarde is voor databaseservers met hun databases die zijn gedistribueerd over meerdere VHD's. Naast de DBMS kunnen er ook andere toepassingen zijn waarbij processen gegevens schrijven of bewerken in verschillende VHD's en waar het belangrijk is om de volgorde van wijzigingen te houden. Als dat een vereiste is, moet geo-replicatie in Azure niet worden ingeschakeld. Afhankelijk van of u geo-replicatie nodig hebt of wilt hebben voor een set VM's, maar niet voor een andere set, kunt u VM's en de bijbehorende VHD's al categoriseren in verschillende Storage-accounts met geo-replicatie ingeschakeld of uitgeschakeld.

Automatisch koppelen instellen voor gekoppelde schijven

Windows

Voor VM's, die zijn gemaakt van eigen afbeeldingen of schijven, is het nodig om de parameter automount te controleren en mogelijk in te stellen. Als u deze parameter instelt, kan de VM na opnieuw opstarten of opnieuw implementeren in Azure de gekoppelde/gekoppelde stations automatisch opnieuw koppelen. De parameter wordt ingesteld voor de afbeeldingen die microsoft in de Azure Marketplace.

Als u automount wilt instellen, raadpleegt u de documentatie van het uitvoerbare opdrachtregeluitvoerbare bestand diskpart.exe hier:

• DiskPart Command-Line opties
• Automount

Het Windows opdrachtregelvenster moet worden geopend als beheerder.

Als er schijven zijn gekoppeld, moet u zich aanmelden bij de VM om de Windows disk manager te openen. Als automount niet is ingeschakeld zoals aanbevolen in het hoofdstuk Automountinstellen voor gekoppelde schijven, moet de zojuist gekoppelde >online worden gezet en worden initialiseerd.

Linux

U moet een zojuist gekoppelde lege schijf initialiseren, zoals beschreven in dit artikel. U moet ook nieuwe schijven toevoegen aan de /etc/fstab.

Definitieve implementatie

Raadpleeg de Implementatiehandleiding voor de uiteindelijke implementatie en de exacte stappen,met name de implementatie van de Azure-extensie voor SAP.

Toegang tot SAP-systemen die worden uitgevoerd binnen Azure-VM's

Voor scenario's waarin u via SAP GUI verbinding wilt maken met deze SAP-systemen via het openbare internet, moeten de volgende procedures worden toegepast.

Later in het document bespreken we het andere belangrijke scenario, verbinding maken met SAP-systemen in cross-premises implementaties, die een site-naar-site-verbinding (VPN-tunnel) of Azure ExpressRoute-verbinding tussen de on-premises systemen en Azure-systemen hebben.

Externe toegang tot SAP-systemen

Met Azure Resource Manager zijn er geen standaard eindpunten meer zoals in het vorige klassieke model. Alle poorten van een Azure Resource Manager VM zijn geopend zolang:

1. Er is geen netwerkbeveiligingsgroep gedefinieerd voor het subnet of de netwerkinterface. Netwerkverkeer naar Azure-VM's kan worden beveiligd via zogenaamde 'netwerkbeveiligingsgroepen'. Zie voor meer informatie Wat is een netwerkbeveiligingsgroep (NSG)?
2. Er Azure Load Balancer gedefinieerd voor de netwerkinterface

Zie het architectuurverschil tussen het klassieke model en ARM zoals beschreven in dit artikel.

Configuratie van de SAP-systeem- en SAP GUI-connectiviteit via internet

Zie dit artikel, waarin de details van dit onderwerp worden beschreven: SAP GUI-verbinding gesloten bij het verbinden met het SAP-systeem in Azure

Firewall-Instellingen binnen VM wijzigen

Het kan nodig zijn om de firewall op uw virtuele machines te configureren om inkomende verkeer naar uw SAP-systeem toe te staan.

Windows

De standaardinstelling is Windows firewall binnen een door Azure geïmplementeerde VM is ingeschakeld. U moet nu toestaan dat de SAP-poort wordt geopend, anders kan de SAP-GUI geen verbinding maken. Om dit te doen:

• Open Configuratiescherm\System and Security\Windows Firewall naar Advanced Instellingen.
• Klik nu met de rechtermuisknop op Regels voor binnenkomende verkeer en kies Nieuwe regel.
• In de volgende wizard hebt u ervoor gekozen om een nieuwe poortregel te maken.
• Laat in de volgende stap van de wizard de instelling op TCP staan en typ het poortnummer dat u wilt openen. Omdat onze SAP-exemplaar-id 00 is, hebben we er 3200 gebruikt. Als uw exemplaar een ander exemplaarnummer heeft, moet de poort die u eerder hebt gedefinieerd op basis van het exemplaarnummer worden geopend.
• In het volgende deel van de wizard moet u het item Verbinding toestaan ingeschakeld laten.
• In de volgende stap van de wizard moet u definiëren of de regel van toepassing is op Domein, Privé en Openbaar netwerk. Pas deze indien nodig aan uw behoeften aan. Als u echter van buiten via het openbare netwerk verbinding maakt met SAP GUI, moet u de regel toepassen op het openbare netwerk.
• Noem de regel in de laatste stap van de wizard en sla deze op door op Voltooien te drukken.

De regel wordt onmiddellijk van kracht.

Linux

Met de Linux-installatie Azure Marketplace standaard de firewall iptables niet ingeschakeld en moet de verbinding met uw SAP-systeem werken. Als u iptables of een andere firewall hebt ingeschakeld, raadpleegt u de documentatie van iptables of de gebruikte firewall voor het toestaan van inkomende TCP-verkeer naar poort 32xx (waarbij xx het systeemnummer van uw SAP-systeem is).

Aanbevelingen voor beveiliging

De SAP-GUI maakt niet onmiddellijk verbinding met een van de SAP-exemplaren (poort 32xx) die worden uitgevoerd, maar maakt eerst verbinding via de poort die is geopend met het SAP-berichtenserverproces (poort 36xx). In het verleden werd dezelfde poort gebruikt door de berichtenserver voor de interne communicatie met de toepassings instances. Om te voorkomen dat on-premises toepassingsservers per ongeluk communiceren met een berichtenserver in Azure, kunnen de interne communicatiepoorten worden gewijzigd. Het wordt ten zeerste aanbevolen om de interne communicatie tussen de SAP-berichtenserver en de exemplaren van de toepassing te wijzigen in een ander poortnummer op systemen die zijn gekloond van on-premises systemen, zoals een kloon van ontwikkeling voor projecttests, enzovoort. U kunt dit doen met de standaardprofielparameter:

rdisp/msserv_internal

zoals beschreven in Security Instellingen for the SAP Message Server (Beveiliging van de SAP-berichtenserver)

Eén VM met SAP NetWeaver-demo/trainingsscenario

In dit scenario implementeren we een typisch systeemscenario voor training/demo waarbij het volledige trainings-/demoscenario is opgenomen in één VM. We gaan ervan uit dat de implementatie wordt uitgevoerd via VM-installatie afbeeldingssjablonen. We gaan er ook van uit dat meerdere van deze demo/trainings-VM's moeten worden geïmplementeerd met de VM's met dezelfde naam. De hele trainingssystemen hebben geen verbinding met uw on-premises assets en zijn een tegenovergestelde van een hybride implementatie.

De veronderstelling is dat u een VM-afbeelding hebt gemaakt, zoals beschreven in sommige secties van het hoofdstuk VM's voorbereiden met SAP voor Azure in dit document.

De volgorde van de gebeurtenissen voor het implementeren van het scenario ziet er als volgende uit:

PowerShell

• Een nieuwe resourcegroep maken voor elk trainings-/demolandschap

$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"

• Maak een nieuw opslagaccount als u deze niet wilt Managed Disks

$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"

• Maak een nieuw virtueel netwerk voor elk trainings-/demolandschap om het gebruik van dezelfde hostnaam en IP-adressen mogelijk te maken. Het virtuele netwerk wordt beveiligd door een netwerkbeveiligingsgroep die alleen verkeer naar poort 3389 toestaat om toegang Extern bureaublad en poort 22 voor SSH.

# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig

• Maak een nieuw openbaar IP-adres dat kan worden gebruikt voor toegang tot de virtuele machine via internet

# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic

• Een nieuwe netwerkinterface voor de virtuele machine maken

# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip

• Hiermee maakt u een virtuele machine. Voor dit scenario heeft elke VM dezelfde naam. De SAP SID van de SAP NetWeaver-exemplaren in deze VM's is ook hetzelfde. Binnen de Azure-resourcegroep moet de naam van de VM uniek zijn, maar in verschillende Azure-resourcegroepen kunt u VM's met dezelfde naam uitvoeren. Het standaardaccount 'Administrator' van Windows of 'root' voor Linux is niet geldig. Daarom moet een nieuwe gebruikersnaam van de beheerder samen met een wachtwoord worden gedefinieerd. De grootte van de VM moet ook worden gedefinieerd.

#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

• Voeg eventueel extra schijven toe en herstel de benodigde inhoud. Alle blobnamen (URL's voor de blobs) moeten uniek zijn binnen Azure.

# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM

CLI

De volgende voorbeeldcode kan worden gebruikt in Linux. Gebruik Windows PowerShell zoals hierboven beschreven of pas het voorbeeld aan om %rgName% te gebruiken in plaats van $rgName en stel de omgevingsvariabele in met behulp van de Windows opdrachtset.

• Een nieuwe resourcegroep maken voor elk trainings-/demolandschap

rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"

• Een nieuw opslagaccount maken

az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower

• Maak een nieuw virtueel netwerk voor elk trainings-/demolandschap om het gebruik van dezelfde hostnaam en IP-adressen mogelijk te maken. Het virtuele netwerk wordt beveiligd door een netwerkbeveiligingsgroep die alleen verkeer naar poort 3389 toestaat om toegang Extern bureaublad en poort 22 voor SSH.

az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG

• Maak een nieuw openbaar IP-adres dat kan worden gebruikt voor toegang tot de virtuele machine via internet

az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic

• Een nieuwe netwerkinterface voor de virtuele machine maken

az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet

• Hiermee maakt u een virtuele machine. Voor dit scenario heeft elke VM dezelfde naam. De SAP SID van de SAP NetWeaver-exemplaren in deze VM's is ook hetzelfde. Binnen de Azure-resourcegroep moet de naam van de VM uniek zijn, maar in verschillende Azure-resourcegroepen kunt u VM's met dezelfde naam uitvoeren. Het standaardaccount 'Administrator' van Windows of 'root' voor Linux is niet geldig. Daarom moet een nieuwe gebruikersnaam van de beheerder samen met een wachtwoord worden gedefinieerd. De grootte van de VM moet ook worden gedefinieerd.

#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id> --authentication-type password

• Voeg eventueel extra schijven toe en herstel de benodigde inhoud. Alle blobnamen (URL's voor de blobs) moeten uniek zijn binnen Azure.

# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new

Sjabloon

U kunt de voorbeeldsjablonen gebruiken in de opslagplaats Azure-quickstart-templates op GitHub.

• Eenvoudige Linux-VM
• Eenvoudige Windows-VM
• VM van de afbeelding

Een set VM's implementeren die communiceren binnen Azure

Dit niet-hybride scenario is een typisch scenario voor trainings- en demodoeleinden waarbij de software die het demo-/trainingsscenario vertegenwoordigt, is verspreid over meerdere VM's. De verschillende onderdelen die in de verschillende VM's zijn geïnstalleerd, moeten met elkaar communiceren. Ook in dit scenario is er geen on-premises netwerkcommunicatie of cross-premises scenario nodig.

Dit scenario is een uitbreiding van de installatie die wordt beschreven in het hoofdstuk Single VM with SAP NetWeaver demo/training scenario van dit document. In dit geval worden er meer virtuele machines toegevoegd aan een bestaande resourcegroep. In het volgende voorbeeld bestaat het trainingslandschap uit een SAP ASCS/SCS-VM, een VM met een DBMS en een SAP Application Server-exemplaar-VM.

Voordat u dit scenario bouwt, moet u nadenken over de basisinstellingen die al in het scenario eerder zijn gebruikt.

Naamgeving van resourcegroep en virtuele machine

Alle resourcegroepnamen moeten uniek zijn. Ontwikkel uw eigen naamgevingsschema van uw resources, zoals <rg-name>-achtervoegsel.

De naam van de virtuele machine moet uniek zijn binnen de resourcegroep.

Netwerk instellen voor communicatie tussen de verschillende VM's

Als u naamscondingen met klonen van dezelfde trainings-/demo-landschappen wilt voorkomen, moet u een Azure-Virtual Network voor elk landschap. DNS-naamresolutie wordt geleverd door Azure of u kunt uw eigen DNS-server buiten Azure configureren (dit wordt hier verder niet besproken). In dit scenario configureren we niet onze eigen DNS. Voor alle virtuele machines binnen één Azure-Virtual Network communicatie via hostnamen ingeschakeld.

De redenen voor het scheiden van trainings- of demo-landschappen door virtuele netwerken en niet alleen resourcegroepen kunnen zijn:

• Het SAP-landschap zoals ingesteld heeft een eigen AD/OpenLDAP nodig en een domeinserver moet deel uitmaken van elk landschap.
• Het SAP-landschap zoals ingesteld heeft onderdelen die moeten werken met vaste IP-adressen.

Meer informatie over Azure Virtual Networks en hoe u deze definieert vindt u in dit artikel.

SAP-VM's implementeren met bedrijfsnetwerkconnectiviteit (cross-premises)

U hebt een SAP-landschap en u wilt de implementatie verdelen tussen bare-metalimplementaties voor high-end DBMS-servers, on-premises gevirtualiseerde omgevingen voor toepassingslagen en kleinere geconfigureerde SAP-systemen met twee lagen en Azure IaaS. De basisveronderstelling is dat SAP-systemen binnen het ene SAP-landschap met elkaar moeten communiceren en met veel andere softwareonderdelen die in het bedrijf zijn geïmplementeerd, onafhankelijk van hun implementatieformulier. Er mogen ook geen verschillen zijn geïntroduceerd in het implementatieformulier voor de eindgebruiker die verbinding maakt met SAP GUI of andere interfaces. Aan deze voorwaarden kan alleen worden voldaan wanneer de on-premises Active Directory/OpenLDAP- en DNS-services zijn uitgebreid naar de Azure-systemen via site-naar-site-/multi-site-connectiviteit of privéverbindingen zoals Azure ExpressRoute.

Scenario van een SAP-landschap

Het cross-premises of hybride scenario kan grofweg worden beschreven zoals in de onderstaande afbeeldingen:

De minimale vereiste is het gebruik van beveiligde communicatieprotocollen zoals SSL/TLS voor browsertoegang of VPN-verbindingen voor systeemtoegang tot de Azure-services. De veronderstelling is dat bedrijven de VPN-verbinding tussen hun bedrijfsnetwerk en Azure op een andere manier afhandelen. Sommige bedrijven kunnen alle poorten leeg openen. Sommige andere bedrijven willen wellicht nauwkeurig zijn in welke poorten ze moeten openen, enzovoort.

In de onderstaande tabel worden typische SAP-communicatiepoorten vermeld. In principe is het voldoende om de SAP-gatewaypoort te openen.

*) nn = SAP-exemplaarnummer

**) sid = SAP-System-ID

Meer gedetailleerde informatie over poorten die vereist zijn voor verschillende SAP-producten of -services van SAP-producten vindt u https://scn.sap.com/docs/DOC-17124 hier. Met dit document moet u toegewezen poorten kunnen openen in het VPN-apparaat dat nodig is voor specifieke SAP-producten en -scenario's.

Andere beveiligingsmaatregelen bij het implementeren van VM's in een dergelijk scenario kunnen zijn het maken van een netwerkbeveiligingsgroep om toegangsregels te definiëren.

Afdrukken op een lokale netwerkprinter vanuit een SAP-exemplaar in Azure

Afdrukken via TCP/IP in cross-premises scenario

Het instellen van uw on-premises netwerkprinters op basis van TCP/IP in een Azure-VM is in het algemeen hetzelfde als in uw bedrijfsnetwerk, ervan uitgaande dat u wel een VPN-site-naar-site-tunnel of ExpressRoute-verbinding tot stand hebt gebracht.

Windows

Om dit te doen:

• Sommige netwerkprinters worden uitgevoerd met een configuratiewizard waarmee u uw printer eenvoudig kunt instellen in een Azure-VM. Als er geen wizardsoftware is gedistribueerd met de printer, de handmatige manier om in te stellen van de printer is het maken van een nieuwe TCP/IP-printerpoort.
• Open Configuratiescherm -> Devices and Printers -> Add a printer
• Kies Een printer toevoegen met een TCP/IP-adres of hostnaam
• Typ het IP-adres van de printer
• Printerpoort standard 9100
• Installeer indien nodig het juiste printerstuurprogramma handmatig.

Linux

• net als voor Windows volgt u de standaardprocedure voor het installeren van een netwerkprinter
• volg gewoon de openbare Linux-handleidingen voor SUSE of Red Hat en Oracle Linux over het toevoegen van een printer.

Hostgebaseerde printer via SMB (gedeelde printer) in cross-premises scenario

Hostprinters zijn niet compatibel met het netwerk. Maar een hostprinter kan worden gedeeld tussen computers in een netwerk zolang de printer is verbonden met een ingeschakelde computer. Verbinding maken uw bedrijfsnetwerk site-naar-site of ExpressRoute en deel uw lokale printer. Het SMB-protocol gebruikt NetBIOS in plaats van DNS als naamservice. De NetBIOS-hostnaam kan verschillen van de DNS-hostnaam. De standaardnaam is dat de NetBIOS-hostnaam en de DNS-hostnaam identiek zijn. Het DNS-domein is niet logisch in de NetBIOS-naamruimte. De volledig gekwalificeerde DNS-hostnaam die bestaat uit de DNS-hostnaam en het DNS-domein, mag daarom niet worden gebruikt in de NetBIOS-naamruimte.

De printer share wordt geïdentificeerd door een unieke naam in het netwerk:

• Hostnaam van de SMB-host (altijd nodig).
• Naam van de share (altijd nodig).
• Naam van het domein als de printer share zich niet in hetzelfde domein als SAP-systeem.
• Daarnaast zijn mogelijk een gebruikersnaam en wachtwoord vereist voor toegang tot de printer share.

Procedure:

Windows

Deel uw lokale printer. Open in de Azure-VM de Windows Explorer en typ de sharenaam van de printer. Een wizard printerinstallatie begeleidt u door het installatieproces.

Linux

Hier zijn enkele voorbeelden van documentatie over het configureren van netwerkprinters in Linux of een hoofdstuk met betrekking tot afdrukken in Linux. Het werkt op dezelfde manier in een Virtuele Linux-azure-VM zolang de VM deel uitmaakt van een VPN:

• SLES https://en.opensuse.org/SDB:Printing_via_SMB_(Samba)_Share_or_Windows_Share
• RHEL of Oracle Linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Starting_Print_Settings_Config

USB-printer (printer doorsturen)

In Azure is de mogelijkheid van Extern bureaublad-services om gebruikers toegang te geven tot hun lokale printerapparaten in een externe sessie niet beschikbaar.

Windows

Meer informatie over afdrukken met Windows vindt u hier: https://technet.microsoft.com/library/jj590748.aspx .

Integratie van SAP Azure-systemen in Correction and Transport System (TMS) in Cross-Premises

Het SAP Change and Transport System (TMS) moet worden geconfigureerd voor het exporteren en importeren van transportverzoeken in verschillende systemen in het landschap. We gaan ervan uit dat de ontwikkelings-exemplaren van een SAP-systeem (DEV) zich in Azure bevinden, terwijl de kwaliteitscontrole (QA) en productieve systemen (PRD) on-premises zijn. Bovendien gaan we ervan uit dat er een centrale transportmap is.

Het transportdomein configureren

Configureer uw transportdomein op het systeem dat u hebt aangewezen als de Domeincontroller transport zoals beschreven in De domeincontroller transport configureren. Er wordt een systeemgebruiker TMSADM gemaakt en de vereiste RFC-bestemming wordt gegenereerd. U kunt deze RFC-verbindingen controleren met behulp van de transactie SM59. Hostnaam resolutie moet worden ingeschakeld in uw transportdomein.

Procedure:

• In ons scenario hebben we besloten dat het on-premises QAS-systeem de CTS-domeincontroller wordt. Transactie-STMS aanroepen. Het dialoogvenster TMS wordt weergegeven. Het dialoogvenster Transportdomein configureren wordt weergegeven. (Dit dialoogvenster wordt alleen weergegeven als u nog geen transportdomein hebt geconfigureerd.)
• Zorg ervoor dat de automatisch gemaakte gebruiker TMSADM is geautoriseerd (SM59 -> ABAP Connection -> TMSADM@E61.DOMAIN_E61 -> Details -> Utilities(M) -> Authorization Test). In het eerste scherm van transactie STMS moet worden weergegeven dat dit SAP-systeem nu functioneert als controller van het transportdomein, zoals hier wordt weergegeven:

SAP-systemen in het transportdomein toevoegen

De volgorde van het toevoegen van een SAP-systeem in een transportdomein ziet er als volgt uit:

• Ga op het DEV-systeem in Azure naar het transportsysteem (Client 000) en roep transactie STMS aan. Kies Andere configuratie in het dialoogvenster en ga door met Systeem opnemen in domein. Geef de domeincontroller op als doelhost (inclusief SAP-systemen in het transportdomein). Het systeem wacht nu om te worden opgenomen in het transportdomein.
• Uit veiligheidsoverwegingen moet u vervolgens teruggaan naar de domeincontroller om uw aanvraag te bevestigen. Kies Systeemoverzicht en Keur het wachtende systeem goed. Bevestig vervolgens de prompt en de configuratie wordt gedistribueerd.

Dit SAP-systeem bevat nu de benodigde informatie over alle andere SAP-systemen in het transportdomein. Tegelijkertijd worden de adresgegevens van het nieuwe SAP-systeem verzonden naar alle andere SAP-systemen en wordt het SAP-systeem ingevoerd in het transportprofiel van het transportbeheerprogramma. Controleer of RPC's en toegang tot de transportmap van het domein werken.

Ga verder met de configuratie van uw transportsysteem zoals gewoonlijk wordt beschreven in de documentatie Change and Transport System.

Procedure:

• Zorg ervoor dat uw STMS on-premises correct is geconfigureerd.
• Zorg ervoor dat de hostnaam van de transportdomeincontroller kan worden opgelost door uw virtuele machine in Azure en vice-vice- .
• Transactie STMS aanroepen -> Andere configuratie -> Systeem opnemen in domein.
• Bevestig de verbinding in het on-premises TMS-systeem.
• Configureer transportroutes, groepen en lagen zoals gebruikelijk.

In cross-premises scenario's met een site-naar-site-verbinding kan de latentie tussen on-premises en Azure nog steeds aanzienlijk zijn. Als we de volgorde van het transport van objecten via ontwikkel- en testsystemen naar productie volgen of als we nadenken over het toepassen van transporten of ondersteuningspakketten op de verschillende systemen, realiseert u zich dat sommige systemen afhankelijk van de locatie van de centrale transportmap, te maken krijgen met hoge latentie bij het lezen of schrijven van gegevens in de centrale transportmap. De situatie is vergelijkbaar met SAP-liggende configuraties waarbij de verschillende systemen zijn verspreid over verschillende datacenters met aanzienlijke afstand tussen de datacenters.

Als u een dergelijke latentie wilt voorkomen en de systemen snel wilt laten werken bij het lezen of schrijven naar of van de transportmap, kunt u twee STMS-transportdomeinen instellen (één voor on-premises en één met de systemen in Azure en de transportdomeinen koppelen. Raadpleeg deze documentatie,waarin de principes achter dit concept in SAP TMS worden uitgelegd.

Procedure:

• Een transportdomein instellen op elke locatie (on-premises en Azure) met behulp van transactie STMS
• Koppel de domeinen aan een domeinkoppeling en bevestig de koppeling tussen de twee domeinen.
• Distribueren van de configuratie naar het gekoppelde systeem.

RFC-verkeer tussen SAP-exemplaren in Azure en on-premises (cross-premises)

RFC-verkeer tussen systemen, on-premises en in Azure, moet werken. Als u een verbindingsoproeptransactie SM59 wilt instellen in een bronsysteem waarin u een RFC-verbinding naar het doelsysteem moet definiëren. De configuratie is vergelijkbaar met de standaardinstallatie van een RFC-verbinding.

We gaan ervan uit dat in het cross-premises scenario de VM's, die SAP-systemen uitvoeren die met elkaar moeten communiceren, zich in hetzelfde domein hebben. De installatie van een RFC-verbinding tussen SAP-systemen verschilt daarom niet van de installatiestappen en invoer in on-premises scenario's.

Toegang tot lokale bestandsshares vanuit SAP-exemplaren die zich in Azure bevinden of vice versa

SAP-exemplaren die zich in Azure bevinden, moeten toegang hebben tot bestands shares, die zich binnen de bedrijfs-premises bevinden. Daarnaast moeten on-premises SAP-exemplaren toegang hebben tot bestands shares, die zich in Azure bevinden. Als u de bestands shares wilt inschakelen, moet u de machtigingen en opties voor delen op het lokale systeem configureren. Zorg ervoor dat u de poorten op de VPN- of ExpressRoute-verbinding tussen Azure en uw datacenter opent.

Ondersteuning

Azure-extensie voor SAP

Als u een deel van de Azure-infrastructuurgegevens van essentiële SAP-systemen wilt in de SAP Host Agent-exemplaren, geïnstalleerd op VM's, moet er een Azure-extensie (VM) voor SAP worden geïnstalleerd voor de geïmplementeerde VM's. Aangezien de eisen van SAP specifiek zijn voor SAP-toepassingen, heeft Microsoft besloten om de vereiste functionaliteit niet algemeen te implementeren in Azure, maar laat het klanten over om de benodigde VM-extensies en configuraties te implementeren op hun Virtual Machines die in Azure worden uitgevoerd. Implementatie- en levenscyclusbeheer van de Azure VM-extensie voor SAP wordt echter voornamelijk geautomatiseerd door Azure.

Ontwerp van de oplossing

De oplossing die is ontwikkeld om sap-hostagent in staat te stellen de vereiste informatie op te vragen, is gebaseerd op de architectuur van de Azure VM-agent en het extensie-framework. Het idee van het Azure VM Agent and Extension-framework is om de installatie toe te staan van softwaretoepassing(en) die beschikbaar zijn in de galerie met Azure VM-extensies binnen een VM. Het belangrijkste idee achter dit concept is het toestaan (in gevallen zoals de Azure-extensie voor SAP), de implementatie van speciale functionaliteit in een VM en de configuratie van dergelijke software tijdens de implementatie.

De Azure VM-agent die het verwerken van specifieke Azure VM-extensies binnen de VM mogelijk maakt, wordt standaard bij het maken van de virtuele Windows-VM's in de Azure Portal. In het geval van SUSE, Red Hat of Oracle Linux maakt de VM-agent al deel uit van de Azure Marketplace maken. In het geval dat er een Linux-VM van on-premises naar Azure wordt geüpload, moet de VM-agent handmatig worden geïnstalleerd.

De basisbouwstenen van de oplossing voor het verstrekken van informatie over de Azure-infrastructuur aan de SAP Host-agent in Azure ziet er als volgende uit:

Zoals u in het bovenstaande blokdiagram kunt zien, wordt één deel van de oplossing gehost in de Azure VM-afbeelding en azure-extensiegalerie. Dit is een globaal gerepliceerde opslagplaats die wordt beheerd door Azure Operations. Het is de verantwoordelijkheid van het gezamenlijke SAP/MS-team dat aan de Azure-implementatie van SAP werkt om samen met Azure Operations nieuwe versies van de Azure-extensie voor SAP te publiceren.

Wanneer u een nieuwe virtuele Windows implementeert, wordt de Azure VM-agent automatisch toegevoegd aan de VM. De functie van deze agent is het coördineren van het laden en configureren van de Azure-extensies van de VM's. Voor linux-VM's maakt de Azure VM-agent al deel uit van de Azure Marketplace-besturingssysteem.

Er is echter een stap die nog steeds moet worden uitgevoerd door de klant. Dit is de in- en configuratie van de prestatieverzameling. Het proces met betrekking tot de configuratie wordt geautomatiseerd door een PowerShell-script of CLI-opdracht. Het PowerShell-script kan worden gedownload in Microsoft Azure Script Center, zoals beschreven in de implementatiehandleiding.

De algehele architectuur van de Azure-extensie voor SAP ziet er als volgende uit:

Volg de instructies in de implementatiehandleiding voor de exacte instructies en voor gedetailleerde stappen voor het gebruik van deze PowerShell-cmdlets of CLI-opdracht tijdens implementaties.

Integratie van een in Azure gevonden SAP-exemplaar in SAProprogramm

SAP-exemplaren die worden uitgevoerd in Azure, moeten ook toegankelijk zijn vanuit SAProprogramm.

Met een SAProsturingssystemen wordt de TCP/IP-communicatie tussen de deelnemende systemen mogelijk als er geen directe IP-verbinding is. Dit biedt het voordeel dat er geen end-to-end-verbinding tussen de communicatiepartners nodig is op netwerkniveau. De SAPropper luistert standaard op poort 3299. Als u SAP-exemplaren wilt verbinden via een SAProatrice, moet u de SAPro string en hostnaam opgeven bij elke poging om verbinding te maken.

SAP NetWeaver AS Java

Tot nu toe ligt de focus van het document op SAP NetWeaver in het algemeen of de SAP NetWeaver-ABAP stack. In deze kleine sectie worden specifieke overwegingen voor de SAP Java-stack vermeld. Een van de belangrijkste, uitsluitend op SAP NetWeaver Java gebaseerde toepassingen is de SAP Enterprise Portal. Andere SAP NetWeaver-toepassingen, zoals SAP PI en SAP Solution Manager, maken gebruik van de SAP NetWeaver-ABAP en Java-stacks. Daarom is het zeker nodig om ook rekening te houden met specifieke aspecten met betrekking tot de SAP NetWeaver Java-stack.

SAP Enterprise Portal

De installatie van een SAP-portal in een virtuele Azure-machine verschilt niet van een on-premises installatie als u implementeert in cross-premises scenario's. Omdat de DNS on-premises wordt uitgevoerd, kunnen de poortinstellingen van de afzonderlijke exemplaren worden uitgevoerd zoals on-premises is geconfigureerd. De aanbevelingen en beperkingen die tot nu toe in dit document worden beschreven, zijn van toepassing op een toepassing zoals SAP Enterprise Portal of de SAP NetWeaver Java-stack in het algemeen.

Een speciaal implementatiescenario van sommige klanten is de directe blootstelling van de SAP Enterprise Portal aan internet terwijl de host van de virtuele machine is verbonden met het bedrijfsnetwerk via een site-naar-site VPN-tunnel of ExpressRoute. Voor een dergelijk scenario moet u ervoor zorgen dat specifieke poorten zijn geopend en niet worden geblokkeerd door een firewall of netwerkbeveiligingsgroep.

De initiële portal-URI is http(s): <Portalserver>:5XX00/irj, waarbij de poort wordt gevormd zoals beschreven door SAP in https://help.sap.com/saphelp_nw70ehp1/helpdata/de/a2/f9d7fed2adc340ab462ae159d19509/frameset.htm .

Als u de URL en/of poorten van uw SAP-Enterprise Portal wilt aanpassen, raadpleegt u deze documentatie:

• Portal-URL wijzigen
• Standaardpoortnummers, portalpoortnummers wijzigen

Hoge beschikbaarheid (HA) en herstel na noodherstel (DR) voor SAP NetWeaver die wordt uitgevoerd op Azure Virtual Machines

Definitie van terminologieën

De term hoge beschikbaarheid (HA) is over het algemeen gerelateerd aan een set technologieën die IT-onderbrekingen minimaliseert door bedrijfscontinuïteit van IT-services te bieden via redundante, fouttolerante of met failover beveiligde onderdelen binnen hetzelfde datacenter. In ons geval binnen één Azure-regio.

Noodherstel (DR) is ook gericht op het minimaliseren van onderbrekingen van IT-services en hun herstel, maar in verschillende datacenters, die zich meestal honderden kilometers verderop bevinden. In ons geval meestal tussen verschillende Azure-regio's binnen dezelfde geopolitieke regio of zoals door u als klant tot stand is gebracht.

Overzicht van hoge beschikbaarheid

We kunnen de discussie over sap met hoge beschikbaarheid in Azure in twee delen opdelen:

• Azure-infrastructuur met hoge beschikbaarheid, bijvoorbeeld hoge beschikbaarheid van rekenkracht (VM's), netwerk, opslag, enzovoort, en de voordelen ervan voor het vergroten van de beschikbaarheid van SAP-toepassingen.
• Hoge beschikbaarheid van SAP-toepassingen, bijvoorbeeld hoge beschikbaarheid van SAP-softwareonderdelen:
  • SAP-toepassingsservers
  • SAP ASCS/SCS-exemplaar
  • DB-server

en hoe dit kan worden gecombineerd met de ha van de Azure-infrastructuur.

Hoge beschikbaarheid van SAP in Azure kent enkele verschillen ten opzichte van SAP Hoge beschikbaarheid in een on-premises fysieke of virtuele omgeving. In het volgende artikel van SAP worden standaardconfiguraties voor SAP hoge beschikbaarheid in gevirtualiseerde omgevingen op Windows: https://scn.sap.com/docs/DOC-44415 . Er is geen sapinst-geïntegreerde SAP-HA-configuratie voor Linux zoals deze bestaat voor Windows. Met betrekking tot SAP HA on-premises voor Linux vindt u hier meer informatie: https://scn.sap.com/docs/DOC-8541 .

Hoge beschikbaarheid van Azure-infrastructuur

Er is momenteel een SLA voor één VM van 99,9%. Als u een idee wilt krijgen van hoe de beschikbaarheid van één VM eruit kan zien, kunt u het product bouwen van de verschillende beschikbare Azure-SLA's: https://azure.microsoft.com/support/legal/sla/ .

De basis voor de berekening is 30 dagen per maand of 43200 minuten. Daarom komt 0,05% downtime overeen met 21,6 minuten. Zoals gebruikelijk wordt de beschikbaarheid van de verschillende services op de volgende manier vermenigvuldigd:

(Beschikbaarheidsservice #1/100) * (Beschikbaarheidsservice 2/100) * (Beschikbaarheidsservice 3/100)

Als:

(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 of een algemene beschikbaarheid van 99,75%.

Hoge beschikbaarheid van virtuele machine (VM)

Er zijn twee soorten Gebeurtenissen van het Azure-platform die van invloed kunnen zijn op de beschikbaarheid van uw virtuele machines: gepland onderhoud en ongepland onderhoud.

• Geplande onderhoudsgebeurtenissen zijn periodieke updates die door Microsoft worden uitgevoerd op het onderliggende Azure-platform om de algehele betrouwbaarheid, prestaties en beveiliging te verbeteren van de platforminfrastructuur waarop uw virtuele machines worden uitgevoerd.
• Niet-gepland onderhoud vindt plaats wanneer de hardware of de fysieke infrastructuur die uw virtuele machine ondersteunt defect raakt. Voorbeelden hiervan zijn lokale netwerkproblemen, lokale schijfdefecten of andere defecten op rack-niveau. Wanneer een dergelijke fout wordt gedetecteerd, migreert het Azure-platform automatisch uw virtuele machine van de defecte fysieke server waarop uw virtuele machine wordt gehost naar een gezonde fysieke server. Dergelijke gebeurtenissen zijn zeldzaam, maar kunnen er ook toe leiden dat uw virtuele machine opnieuw moet opstarten.

Zie Beschikbaarheid van virtuele Windows machines in Azure en Beschikbaarheid van virtuele Linux-machines in Azure voor meer informatie.

Azure Storage Redundantie

De gegevens in uw Microsoft Azure Storage-account worden altijd gerepliceerd om duurzaamheid en hoge beschikbaarheid te garanderen, en voldoen aan de Azure Storage SLA, zelfs bij tijdelijke hardwarefouten.

Omdat Azure Storage standaard drie afbeeldingen van de gegevens bewaarde, zijn RAID5 of RAID1 op meerdere Azure-schijven niet nodig.

Zie redundantie voor Azure Storage meer informatie.

Azure Infrastructure VM Restart gebruiken om een hogere beschikbaarheid van SAP-toepassingen te bereiken

Als u besluit geen gebruik te maken van functies zoals Windows Server Failover Clustering (WSFC) of Pacemaker op Linux (momenteel alleen ondersteund voor SLES 12 en hoger), wordt Azure VM Restart gebruikt om een SAP-systeem te beschermen tegen geplande en ongeplande downtime van de fysieke serverinfrastructuur van Azure en het algehele onderliggende Azure-platform.

Een ander belangrijk infrastructuurelement voor hoge beschikbaarheid is opslag. De SLA Azure Storage bijvoorbeeld 99,9% beschikbaarheid. Als u alle VM's met de schijven in één Azure Storage-account implementeert, is het mogelijk dat Azure Storage niet beschikbaar zijn voor alle VM's die in dat Azure Storage-account zijn geplaatst, en ook alle SAP-onderdelen die binnen deze VM's worden uitgevoerd.

In plaats van alle VM's in één Azure Storage-account te plaatsen, kunt u ook toegewezen opslagaccounts voor elke VM gebruiken en op deze manier de algehele beschikbaarheid van VM's en SAP-toepassingen verhogen met behulp van meerdere onafhankelijke Azure Storage-accounts.

Beheerde Azure-schijven worden automatisch in het foutdomein geplaatst van de virtuele machine waar ze aan zijn gekoppeld. Als u twee virtuele machines in een beschikbaarheidsset plaats en Managed Disks gebruikt, zorgt het platform er ook voor dat de Managed Disks naar verschillende foutdomeinen worden gedistribueerd. Als u van plan bent om Premium Storage gebruiken, raden we u ten zeerste aan ook Schijven beheren te gebruiken.

Een voorbeeldarchitectuur van een SAP NetWeaver-systeem dat gebruikmaakt van de ha- en opslagaccounts van de Azure-infrastructuur, kan er als volgende uitzien:

Een voorbeeldarchitectuur van een SAP NetWeaver-systeem dat gebruikmaakt van de ha- en Managed Disks azure-infrastructuur, kan er als volgende uitzien:

Voor kritieke SAP-onderdelen hebben we het volgende tot nu toe bereikt:

• Hoge beschikbaarheid van SAP-toepassingsservers (AS)

  Exemplaren van SAP-toepassingsservers zijn redundante onderdelen. Elk SAP AS-exemplaar wordt geïmplementeerd op een eigen VM die wordt uitgevoerd in een ander Fout- en upgradedomein van Azure (zie de hoofdstukken Foutdomeinen en Upgradedomeinen). Dit wordt gegarandeerd met behulp van Azure-beschikbaarheidssets (zie het hoofdstuk Azure-beschikbaarheidssets). Mogelijke geplande of niet-geplande onbeschikbaarheid van een Azure-fout- of upgradedomein zorgt ervoor dat een beperkt aantal VM's met hun SAP AS-exemplaren niet beschikbaar is.

  Elk SAP AS-exemplaar wordt in een eigen Azure Storage-account geplaatst. Als één Azure Storage-account mogelijk niet beschikbaar is, is slechts één VM met het SAP AS-exemplaar niet beschikbaar. Er geldt echter een limiet voor het aantal Azure Storage binnen één Azure-abonnement. Om ervoor te zorgen dat het (A)SCS-exemplaar automatisch wordt gestart nadat de VM opnieuw is opgestart, moet u de parameter Autostart instellen in het startprofiel van het (A)SCS-exemplaar dat wordt beschreven in het hoofdstuk Autostart gebruiken voor SAP-exemplaren. Lees ook het hoofdstuk Hoge beschikbaarheid voor SAP-toepassingsservers voor meer informatie.

  Zelfs als u Managed Disks gebruikt, worden deze schijven ook opgeslagen in een Azure Storage-account en kunnen ze niet beschikbaar zijn in het geval van een opslagstoring.

• Hoger Beschikbaarheid van SAP (A)SCS-exemplaar

  Hier gebruiken we Azure VM Restart om de VM te beveiligen met een geïnstalleerd SAP (A)SCS-exemplaar. In het geval van geplande of ongeplande downtime van Azure-servers, worden VM's opnieuw opgestart op een andere beschikbare server. Zoals eerder vermeld, beschermt Azure VM Restart voornamelijk VM's en NOT-toepassingen, in dit geval het (A)SCS-exemplaar. Via het opnieuw opstarten van de VM bereiken we indirect hogere beschikbaarheid van het SAP (A)SCS-exemplaar. Als u automatische start van het (A)SCS-exemplaar na het opnieuw opstarten van de VM wilt voorkomen, moet u de parameter Autostart instellen in het startprofiel van het (A)SCS-exemplaar dat wordt beschreven in het hoofdstuk Autostart gebruiken voor SAP-exemplaren. Dit betekent dat de (A)SCS-instantie als spof (Single Point of Failure) die wordt uitgevoerd in één VM de determinatieve factor is voor de beschikbaarheid van het hele SAP-landschap.

• Hoger Beschikbaarheid van DBMS-server

  Hier maken we, net als bij de use-case van het SAP (A)SCS-exemplaar, gebruik van Azure VM Restart om de VM te beveiligen met geïnstalleerde DBMS-software en bereiken we een hogere beschikbaarheid van DBMS-software via het opnieuw opstarten van de VM. DBMS dat wordt uitgevoerd in één VM is ook een SPOF en is de determinatieve factor voor de beschikbaarheid van het hele SAP-landschap.

Hoge beschikbaarheid van SAP-toepassing in Azure IaaS

Voor een volledige hoge beschikbaarheid van het SAP-systeem moeten we alle essentiële SAP-systeemonderdelen beveiligen, bijvoorbeeld redundante SAP-toepassingsservers, en unieke onderdelen (bijvoorbeeld Single Point of Failure), zoals een SAP (A)SCS-exemplaar en DBMS.

Hoge beschikbaarheid voor SAP-toepassingsservers

Voor de SAP-toepassingsservers/dialoogvensters is het niet nodig om na te denken over een specifieke oplossing voor hoge beschikbaarheid. Hoge beschikbaarheid wordt bereikt door redundantie en daardoor voldoende redundantie te hebben op verschillende virtuele machines. Ze moeten allemaal in dezelfde Azure-beschikbaarheidsset worden geplaatst om te voorkomen dat de VM's op hetzelfde moment worden bijgewerkt tijdens geplande uitvaltijd voor onderhoud. De basisfunctionaliteit, die is gebaseerd op verschillende upgrade- en foutdomeinen binnen een Azure-schaaleenheid, is al geïntroduceerd in het hoofdstuk Upgradedomeinen. Azure-beschikbaarheidssets zijn in het hoofdstuk Azure-beschikbaarheidssets van dit document gepresenteerd.

Er is geen oneindig aantal fout- en upgradedomeinen dat kan worden gebruikt door een Azure-beschikbaarheidsset binnen een Azure-schaaleenheid. Dit betekent dat het plaatsen van een aantal VM's in één beschikbaarheidsset, vroeg of laat meer dan één VM in hetzelfde fout- of upgradedomein belandt.

Als u een paar exemplaren van de SAP-toepassingsserver implementeert in hun toegewezen VM's en ervan uitgaande dat er vijf upgradedomeinen zijn, ziet u aan het einde de volgende afbeelding. Het werkelijke maximum aantal fout- en updatedomeinen binnen een beschikbaarheidsset kan in de toekomst veranderen:

Hoge beschikbaarheid voor SAP Central-services in Azure

Raadpleeg voor architectuur met hoge beschikbaarheid van SAP Central-services in Azure het artikel Architectuur voor hoge beschikbaarheid en scenario's voor SAP NetWeaver als informatie over invoer. Het artikel wijst naar meer gedetailleerde beschrijvingen voor de specifieke besturingssystemen.

Hoge beschikbaarheid voor het SAP-database-exemplaar

De typische SAP DBMS HA-installatie is gebaseerd op twee DBMS-VM's waarbij dbms-functionaliteit voor hoge beschikbaarheid wordt gebruikt om gegevens van het actieve DBMS-exemplaar te repliceren naar de tweede VM naar een passieve DBMS-instantie.

Hoge beschikbaarheid en functionaliteit voor herstel na noodherstel voor DBMS in het algemeen en specifieke DBMS worden beschreven in de DBMS-implementatiehandleiding.

End-to-end hoge beschikbaarheid voor het volledige SAP-systeem

Hier zijn twee voorbeelden van een volledige SAP NetWeaver HA-architectuur in Azure: één voor Windows en één voor Linux.

Alleen niet-beherende schijven: de onderstaande concepten moeten mogelijk een beetje worden aangetast wanneer u veel SAP-systemen implementeert en het aantal geïmplementeerde VM's de maximumlimiet van Storage-accounts per abonnement overschrijdt. In dergelijke gevallen moeten VHD's van VM's worden gecombineerd binnen één Storage account. Meestal doet u dit door VHD's van SAP-toepassingslaag-VM's van verschillende SAP-systemen te combineren. We hebben ook verschillende VHD's van verschillende DBMS-VM's van verschillende SAP-systemen gecombineerd in één Azure Storage account. Hiermee houdt u de IOPS-limieten van Azure Storage accounts in gedachten ( https://azure.microsoft.com/documentation/articles/storage-scalability-targets )

Ha op Windows

De volgende Azure-constructies worden gebruikt voor het SAP NetWeaver-systeem om de impact van infrastructuurproblemen en hostpatching te minimaliseren:

• Het volledige systeem wordt geïmplementeerd in Azure (vereist : DBMS-laag, (A)SCS-exemplaar en de volledige toepassingslaag moet op dezelfde locatie worden uitgevoerd.
• Het volledige systeem wordt uitgevoerd binnen één Azure-abonnement (vereist).
• Het volledige systeem wordt uitgevoerd binnen één Azure Virtual Network (vereist).
• De scheiding van de VM's van één SAP-systeem in drie beschikbaarheidssets is mogelijk, zelfs met alle VM's die tot dezelfde Virtual Network.
• Elke laag (bijvoorbeeld DBMS, ASCS, toepassingsservers) moet een toegewezen beschikbaarheidsset gebruiken.
• Alle VM's met DBMS-exemplaren van één SAP-systeem staan in één beschikbaarheidsset. We gaan ervan uit dat er meer dan één VM met DBMS-exemplaren per systeem is, omdat systeemeigen DBMS-functies met hoge beschikbaarheid worden gebruikt, zoals SQL Server AlwaysOn of Oracle Data Guard.
• Alle VM's met DBMS-exemplaren gebruiken hun eigen opslagaccount. DBMS-gegevens en logboekbestanden worden van het ene opslagaccount naar een ander opslagaccount gerepliceerd met behulp van DBMS-functies voor hoge beschikbaarheid die de gegevens synchroniseren. Als één opslagaccount niet beschikbaar is, is één SQL Windows clusterknooppunt niet beschikbaar, maar niet de hele SQL Server service.
• Alle VM's met een (A)SCS-exemplaar van één SAP-systeem staan in één beschikbaarheidsset. Een Windows Server Failover Cluster (WSFC) wordt geconfigureerd in deze VM's om het (A)SCS-exemplaar te beveiligen.
• Alle VM's met (A)SCS-exemplaren gebruiken hun eigen opslagaccount. (A) SCS-exemplaarbestanden en de globale SAP-map worden gerepliceerd van het ene opslagaccount naar het andere met behulp van SIOS DataKeeper-replicatie. Als één opslagaccount niet beschikbaar is, is één (A)SCS Windows-clusterknooppunt niet beschikbaar, maar niet voor de hele (A)SCS-service.
• ALLE VM's die de SAP-toepassingsserverlaag vertegenwoordigen, maken deel uit van een derde beschikbaarheidsset.
• ALLE VM's waarop SAP-toepassingsservers worden uitgevoerd, gebruiken hun eigen opslagaccount. Wanneer één opslagaccount niet beschikbaar is, is één SAP-toepassingsserver niet beschikbaar, waar andere SAP-toepassingsservers nog steeds worden uitgevoerd.

In de volgende afbeelding ziet u hetzelfde landschap met behulp van Managed Disks.

Ha in Linux

De architectuur voor SAP HA op Linux in Azure is in principe hetzelfde als voor Windows zoals hierboven wordt beschreven. Raadpleeg SAP Note 1928533 voor een lijst met ondersteunde oplossingen voor hoge beschikbaarheid.

Autostart gebruiken voor SAP-exemplaren

SAP bood de functionaliteit aan om SAP-exemplaren direct na de start van het besturingssysteem op de VM te starten. De exacte stappen zijn beschreven in SAP Knowledge Base Article 1909114. SAP raadt echter niet aan om de instelling meer te gebruiken, omdat er geen controle is in de volgorde van het opnieuw opstarten van exemplaren, ervan uitgaande dat meer dan één VM is getroffen of meerdere exemplaren per VM worden gestart. Ervan uitgaande dat een typisch Azure-scenario van één SAP-toepassingsserver-exemplaar in een VM en het geval van één VM uiteindelijk opnieuw wordt opgestart, is de Autostart niet essentieel en kan deze worden ingeschakeld door deze parameter toe te voegen:

Autostart = 1

In het beginprofiel van het SAP-ABAP en/of Java-exemplaar.

Meer informatie over autostart voor SAP-exemplaren vindt u hier:

• SAP starten/stoppen samen met het starten/stoppen van uw Unix-server
• SAP NetWeaver-beheeragents starten en stoppen
• Automatisch starten van HANA-database inschakelen

Grotere SAP-systemen met drie lagen

High-Availability aspecten van SAP-configuraties met drie lagen zijn al in eerdere secties besproken. Maar hoe zit het met systemen waarbij de DBMS-serververeisten te groot zijn om deze in Azure te kunnen plaatsen, maar de SAP-toepassingslaag kan worden geïmplementeerd in Azure?

Locatie van SAP-configuraties met drie lagen

Het splitsen van de toepassingslaag zelf of de toepassings- en DBMS-laag tussen on-premises en Azure wordt niet ondersteund. Een SAP-systeem is volledig on-premises of in Azure geïmplementeerd. Het wordt ook niet ondersteund om sommige toepassingsservers on-premises en andere in Azure uit te voeren. Dat is het beginpunt van de discussie. We ondersteunen ook niet om de DBMS-onderdelen van een SAP-systeem en de SAP-toepassingsserverlaag in twee verschillende Azure-regio's te implementeren. Bijvoorbeeld DBMS in VS - west en SAP-toepassingslaag in VS - centraal. Reden voor het niet ondersteunen van dergelijke configuraties is de latentiegevoeligheid van de SAP NetWeaver-architectuur.

In de loop van het afgelopen jaar hebben datacenterpartners echter co-locaties ontwikkeld voor Azure-regio's. Deze co-locaties bevinden zich vaak dicht bij de fysieke Azure-datacenters binnen een Azure-regio. De korte afstand en de verbinding van assets op de co-locatie via ExpressRoute naar Azure kunnen resulteren in een latentie van minder dan 2 milliseconden. In dergelijke gevallen is het mogelijk om de DBMS-laag (inclusief opslag-SAN/NAS) op een dergelijke co-locatie en de SAP-toepassingslaag in Azure te vinden. HANA Large Instances.

Offline back-up van SAP-systemen

Afhankelijk van de gekozen SAP-configuratie (2-laag of 3-laag) moet u mogelijk een back-up maken. De inhoud van de VM zelf plus een back-up van de database. De DBMS-gerelateerde back-ups worden naar verwachting uitgevoerd met databasemethoden. Een gedetailleerde beschrijving voor de verschillende databases vindt u in DBMS Guide ( DBMS-handleiding). Aan de andere kant kunnen er offline back-up van de SAP-gegevens worden gemaakt (inclusief de database-inhoud), zoals beschreven in deze sectie of online, zoals beschreven in de volgende sectie.

De offline back-up vereist in principe het afsluiten van de VM via de Azure Portal en een kopie van de basis-VM-schijf plus alle gekoppelde schijven op de VM. Hiermee behoudt u een point in time-afbeelding van de VM en de bijbehorende schijf. Het is raadzaam om de back-ups te kopiëren naar een Azure Storage account. Daarom is de procedure die in het hoofdstuk Schijven kopiëren tussen Azure Storage accounts van dit document van toepassing.

Een herstel van die status bestaat uit het verwijderen van de basis-VM, evenals de oorspronkelijke schijven van de basis-VM en de opgeslagen schijven, het terug kopiëren van de opgeslagen schijven naar het oorspronkelijke Storage-account of de resourcegroep voor beheerde schijven en vervolgens het systeem opnieuw te deployeren. In dit artikel ziet u een voorbeeld van het uitvoeren van scripts voor dit proces in PowerShell: https://www.westerndevs.com/_/azure-snapshots/

Zorg ervoor dat u een nieuwe SAP-licentie installeert omdat er een nieuwe hardwaresleutel wordt gemaakt nadat u een back-up van een VM hebt hersteld zoals hierboven is beschreven.

Online back-up van een SAP-systeem

Back-up van de DBMS wordt uitgevoerd met DBMS-specifieke methoden, zoals beschreven in de DBMS-handleiding.

Van andere VM's in het SAP-systeem kan een back-up worden gemaakt met behulp van de Azure Virtual Machine Backup-functionaliteit. Azure Virtual Machine Backup is een standaardmethode voor het maken van een back-up van een volledige virtuele machine in Azure. Azure Backup slaat de back-ups op in Azure en staat een herstel van een VM opnieuw toe.

Azure als DR-site voor PRODUCTIE-SAP-landschappen

Sinds half 2014 maken extensies voor verschillende onderdelen rond Hyper-V, System Center en Azure het gebruik van Azure als DR-site mogelijk voor VM's die on-premises worden uitgevoerd op basis van Hyper-V.

Hier wordt een blog met gedetailleerde informatie over het implementeren van deze oplossing beschreven: SAP-oplossingen beveiligen met Azure Site Recovery.

Samenvatting voor hoge beschikbaarheid voor SAP-systemen

De belangrijkste punten van hoge beschikbaarheid voor SAP-systemen in Azure zijn:

• Op dit moment kan het SAP Single Point of Failure niet precies op dezelfde manier worden beveiligd als in on-premises implementaties. De reden hiervoor is dat clusters met gedeelde schijven nog niet kunnen worden gebouwd in Azure zonder het gebruik van software van derden.
• Voor de DBMS-laag moet u de DBMS-functionaliteit gebruiken die niet afhankelijk is van clustertechnologie voor gedeelde schijven. Details worden beschreven in de DBMS-handleiding.
• Gebruik Azure-beschikbaarheidssets om de impact van problemen binnen foutdomeinen in de Azure-infrastructuur of het onderhoud van de host te minimaliseren:
  • Het is raadzaam om één beschikbaarheidsset te hebben voor de SAP-toepassingslaag.
  • Het is raadzaam om een afzonderlijke beschikbaarheidsset te hebben voor de SAP DBMS-laag.
  • Het wordt NIET aanbevolen om dezelfde beschikbaarheidsset toe te passen op VM's van verschillende SAP-systemen.
  • Het is raadzaam om de Premium Managed Disks.
• Raadpleeg de DBMS-handleiding voor Back-updoeleinden van de SAP DBMS-laag.
• Het maken van een back-up van SAP-dialoogvensters is weinig zinvol, omdat het meestal sneller is om eenvoudige dialoogvensters opnieuw teploeeren.
• Het maken van een back-up van de VM, die de globale map van het SAP-systeem en alle profielen van de verschillende exemplaren bevat, is logisch en moet worden uitgevoerd met Windows Back-up of, bijvoorbeeld tar op Linux. Omdat er verschillen zijn tussen Windows Server 2008 (R2) en Windows Server 2012 (R2), waardoor het eenvoudiger is om een back-up te maken met behulp van recentere Windows Server-releases, raden we u aan om Windows Server 2012 (R2) uit te Windows gastbesturingssysteem.

Volgende stappen

Lees de artikelen:

• Azure Virtual Machines-implementatie voor SAP NetWeaver
• Overwegingen voor azure Virtual Machines DBMS-implementatie voor SAP-workload
• Configuraties en bewerkingen van SAP HANA-infrastructuur in Azure