Azure-nabijheidplaatsingsgroepen voor optimale netwerklatentie met SAP-toepassingen

SAP-toepassingen op basis van de SAP NetWeaver- of SAP S/4HANA-architectuur zijn gevoelig voor netwerklatentie tussen de SAP-toepassingslaag en de SAP-databaselaag. Deze gevoeligheid is het resultaat van de meeste bedrijfslogica die wordt uitgevoerd in de toepassingslaag. Omdat op de SAP-toepassingslaag de bedrijfslogica wordt uitgevoerd, worden met een hoge frequentie query's naar de databaselaag uitgevoerd, met een snelheid van duizenden of tienduizenden per seconde. In de meeste gevallen is de aard van deze query's eenvoudig. Ze kunnen vaak in 500 microseconden of minder in de databaselaag worden uitgevoerd.

De tijd die in het netwerk wordt besteed aan het verzenden van een dergelijke query van de toepassingslaag naar de databaselaag en het ontvangen van het resultaat dat wordt teruggestuurd, heeft een grote invloed op de tijd die nodig is om bedrijfsprocessen uit te voeren. Deze gevoeligheid voor netwerklatentie is de reden waarom u misschien een bepaalde minimale netwerklatentie wilt bereiken in SAP-implementatieprojecten. Zie SAP Note #1100926 - FAQ: Netwerkprestaties voor richtlijnen over het classificeren van de netwerklatentie.

In veel Azure-regio's is het aantal datacenters toegenomen. Tegelijkertijd gebruiken klanten, met name voor hoogwaardige SAP-systemen, meer speciale VM-families, zoals de M- of Mv2-familie, of in zeldzame gevallen HANA Large Instances. Deze typen virtuele Azure-machines zijn niet altijd beschikbaar in elk van de datacenters die worden verzameld in een Azure-regio. Deze feiten kunnen mogelijkheden bieden om de netwerklatentie tussen de SAP-toepassingslaag en de SAP DBMS-laag te optimaliseren.

Azure biedt nabijheidsplaatsingsgroepen om u de mogelijkheid te bieden om de netwerklatentie te optimaliseren. Nabijheidsplaatsingsgroepen kunnen worden gebruikt om het groeperen van verschillende VM-typen af te dwingen onder één netwerksluis dat voldoende lage netwerklatentie biedt tussen deze verschillende VM-typen, waar dit tot nu toe nog niet is gedaan. Tijdens het implementeren van de eerste VM in een dergelijke nabijheidsplaatsingsgroep, wordt de VM gebonden aan een specifieke netwerkverbinding. Net als alle andere VM's die in dezelfde nabijheidsplaatsingsgroep worden geïmplementeerd, worden deze VM's gegroepeerd onder hetzelfde netwerk. Hoe aantrekkelijk dit perspectief ook klinkt, het gebruik van de constructie introduceert ook enkele beperkingen en valkuilen:

• U kunt er niet van uitgaan dat alle typen Azure-VM's beschikbaar zijn in alle Azure-datacenters of onder elke netwerkomgeving. Als gevolg hiervan kan de combinatie van verschillende VM-typen binnen één nabijheidsplaatsingsgroep ernstig worden beperkt. Deze beperkingen treden op omdat de hosthardware die nodig is om een bepaald VM-type uit te voeren mogelijk niet aanwezig is in het datacenter of onder het netwerknetwerk waaraan de nabijheidsplaatsingsgroep is toegewezen
• Wanneer u de omvang van delen van de VM's die zich binnen één nabijheidsplaatsingsgroep bevinden, kunt u er niet automatisch van uitgaan dat het nieuwe VM-type beschikbaar is in hetzelfde datacenter of onder het netwerk en dat de nabijheidsplaatsingsgroep is toegewezen aan
• Omdat Azure hardware uit bedrijf moet nemen, kunnen bepaalde VM's van een nabijheidsplaatsingsgroep worden geforceerd in een ander Azure-datacenter of een ander netwerk. Lees het document Nabijheidsplaatsingsgroepen voor meer informatie over dit geval

De scenario's waarin u tot nu toe nabijheidsplaatsingsgroepen hebt gebruikt, waren:

• SAP-workload implementeren met beschikbaarheidssets. Waar de SAP-databaselaag, de SAP-toepassingslaag en ASCS/SCS-VM's zijn gegroepeerd in drie verschillende beschikbaarheidssets. In dat geval wilde u er zeker van zijn dat de beschikbaarheidssets niet zijn verdeeld over de volledige Azure-regio, omdat dit afhankelijk van de Azure-regio kan leiden tot netwerklatentie die de SAP-workload negatief kan beïnvloeden
• U wilde de kritieke resources van uw SAP-workload implementeren in verschillende Beschikbaarheidszones en aan de andere kant wilt u er zeker van zijn dat de VM's van de toepassingslaag in elk van de zones over verschillende foutdomeinen worden verdeeld met behulp van beschikbaarheidssets. In dit geval zijn nabijheidsplaatsingsgroepen, zoals verder beschreven in het document, de benodigde lijm
• U hebt nabijheidsplaatsingsgroepen gebruikt om VM's te groepen voor een optimale netwerklatentie tussen de services die worden gehost in de VM's

Net als bij implementatiescenario 1 geldt dat in veel regio's, met name regio's zonder Beschikbaarheidszones en de meeste regio's met Beschikbaarheidszones, de netwerklatentie onafhankelijk is van waar de VM's worden gebruikt. Hoewel er bepaalde Azure-regio's zijn die geen voldoende goede ervaring kunnen bieden zonder de drie verschillende beschikbaarheidssets samen te stellen met het gebruik van beschikbaarheidssets. Vanaf implementatiescenario 2 raden we in de volgende secties van dit document een andere manier aan om nabijheidsplaatsingsgroepen te gebruiken.

Wat zijn nabijheidsplaatsingsgroepen?

Een azure-nabijheidsplaatsingsgroep is een logische constructie. Wanneer een nabijheidsplaatsingsgroep is gedefinieerd, is deze gebonden aan een Azure-regio en een Azure-resourcegroep. Wanneer VM's worden geïmplementeerd, wordt naar een nabijheidsplaatsingsgroep verwezen door:

• De eerste Azure-VM die is geïmplementeerd onder een netwerk, heeft veel Azure-rekeneenheden en lage netwerklatentie. Een dergelijke netwerkverbinding komt vaak overeen met één Azure-datacenter. U kunt de eerste virtuele machine zien als een 'scope-VM' die wordt geïmplementeerd in een rekenschaaleenheid op basis van Azure-toewijzingsalgoritmen die uiteindelijk worden gecombineerd met implementatieparameters.
• Alle volgende VM's die worden geïmplementeerd die verwijzen naar de nabijheidsplaatsingsgroep, worden geïmplementeerd onder hetzelfde netwerk als de eerste virtuele machine.

Aan één Azure-resourcegroep kunnen meerdere nabijheidsplaatsingsgroepen zijn toegewezen. Maar een nabijheidsplaatsingsgroep kan slechts aan één Azure-resourcegroep worden toegewezen.

Nabijheidsplaatsingsgroepen met SAP-systemen die alleen azure-VM's gebruiken

In deze sectie gaan we in op de implementatiearchitectarchitecten die tot nu toe zijn gebruikt en nieuwe aanbevelingen

Nabijheidsplaatsingsgroepen met zonale implementaties

Voor implementaties die geen HANA Large Instances gebruiken, is het belangrijk om een redelijk lage netwerklatentie te bieden tussen de SAP-toepassingslaag en de DBMS-laag. Als u een redelijk lage netwerklatentie wilt inschakelen voor een beperkt aantal scenario's, kan een Azure-nabijheidsplaatsingsgroep worden gedefinieerd voor een dergelijk SAP-systeem.

Vermijd het bundelen van verschillende SAP-productie- of niet-productiesystemen in één nabijheidsplaatsingsgroep. Vermijd bundels SAP-systemen, omdat hoe meer systemen u in een nabijheidsplaatsingsgroep groepeert, hoe groter de kans is:

• Dat u een VM-type nodig hebt dat niet beschikbaar is onder het netwerk waar de nabijheidsplaatsingsgroep aan is toegewezen.
• Die resources van niet-reguliere VM's, zoals VM's uit de M-serie, kunnen uiteindelijk niet worden voltooid wanneer u het aantal VM's na een periode moet uitbreiden naar een nabijheidsplaatsingsgroep.

Het gebruik van nabijheidsplaatsingsgroep dat we tot nu toe hebben aanbevolen, ziet eruit zoals in deze afbeelding

U hebt een nabijheidsplaatsingsgroep (PPG) gemaakt in elk van de twee Beschikbaarheidszones waarin u uw SAP-systeem hebt geïmplementeerd. Alle VM's van een bepaalde zone maken deel uit van de afzonderlijke nabijheidsplaatsingsgroep van die specifieke zone. U bent in elke zone begonnen met het implementeren van de DBMS-VM om het bereik van de PPG te bepalen en vervolgens de ASCS-VM geïmplementeerd in dezelfde zone en PPG. In een derde stap hebt u een Azure-beschikbaarheidsset gemaakt, de beschikbaarheidsset toegewezen aan de PPG met bereik en de SAP-toepassingslaag er in geïmplementeerd. Het voordeel van deze configuratie is dat alle onderdelen goed zijn uitgelijnd onder dezelfde netwerkverbinding. Het grote nadeel is dat uw flexibiliteit bij het formaat van virtuele machines kan worden beperkt.

Op basis van veel verbeteringen die door Microsoft zijn geïmplementeerd in de Azure-regio's om de netwerklatentie binnen een Azure-beschikbaarheidszone te verminderen, ziet de nieuwe implementatie-richtlijnen voor zonelijke implementaties er als volgende uit:

Het verschil met de aanbeveling die tot nu toe is gegeven, is dat de database-VM's in de twee zones geen deel meer uitmaken van de nabijheidsplaatsingsgroepen. De nabijheidsplaatsingsgroepen per zone zijn nu binnen het bereik van de implementatie van de VM met de SAP ASCS/SCS-exemplaren. Dit betekent ook dat voor de regio's waar Beschikbaarheidszones worden verzameld door meerdere datacenters, het ASCS/SCS-exemplaar en de toepassingslaag onder één netwerklaag kunnen worden uitgevoerd en de database-VM's kunnen worden uitgevoerd onder een ander netwerk. Hoewel de netwerkverbeteringen zijn aangebracht, moet de netwerklatentie tussen de SAP-toepassingslaag en de DBMS-laag nog steeds voldoende zijn voor voldoende goede prestaties en doorvoer. Het voordeel van deze nieuwe configuratie is dat u meer flexibiliteit hebt bij het formaat van VM's of het verplaatsen naar nieuwe VM-typen met ofwel de DBMS-laag of/en de toepassingslaag van het SAP-systeem.

Nabijheidsplaatsingsgroepen met implementaties van beschikbaarheidssets

In dit geval is het doel om nabijheidsplaatsingsgroepen te gebruiken om de VM's die via verschillende beschikbaarheidssets worden geïmplementeerd, samen te plaatsen. In dit gebruiksscenario gebruikt u geen beheerde implementatie voor verschillende Beschikbaarheidszones in een regio. In plaats daarvan wilt u het SAP-systeem implementeren met behulp van beschikbaarheidssets. Als gevolg hiervan hebt u ten minste een beschikbaarheidsset voor de DBMS-VM's, ASCS/SCS-VM's en de VM's van de toepassingslaag. Omdat u tijdens de implementatie van een VM geen beschikbaarheidsset en een beschikbaarheidszone kunt opgeven, kunt u niet bepalen waar de VM's in de verschillende beschikbaarheidssets worden toegewezen. Dit kan ertoe leiden dat in sommige Azure-regio's de netwerklatentie tussen verschillende VM's nog steeds te hoog is om een voldoende goede prestatie-ervaring te bieden. De resulterende architectuur ziet er dan als volgende uit:

In deze afbeelding wordt één nabijheidsplaatsingsgroep toegewezen aan één SAP-systeem. Deze PPG wordt toegewezen aan de drie beschikbaarheidssets. Het bereik van de nabijheidsplaatsingsgroep wordt vervolgens ingesteld door de eerste databaselaag-VM's te implementeren in de DBMS-beschikbaarheidsset. Met deze architectuuraanbeveling worden alle VM's onder dezelfde netwerkverbinding verzameld. De eerder genoemde beperkingen worden in dit artikel beschreven. Daarom moet de architectuur van de nabijheidsplaatsingsgroep verspreid worden gebruikt.

Nabijheidsplaatsingsgroepen en grote HANA-instanties

Als sommige van uw SAP-systemen afhankelijk zijn van HANA Large Instances voor de toepassingslaag, kunt u aanzienlijke verbeteringen ervaren in de netwerklatentie tussen de HANA Large Instances-eenheid en Azure VM's wanneer u HANA Large Instances-eenheden gebruikt die zijn geïmplementeerd in revisie 4 rijen of stempels. Een verbetering is dat HANA Large Instances-eenheden, terwijl ze worden geïmplementeerd, implementeren met een nabijheidsplaatsingsgroep. U kunt die nabijheidsplaatsingsgroep gebruiken om uw toepassingslaag-VM's te implementeren. Als gevolg hiervan worden deze VM's geïmplementeerd in hetzelfde datacenter dat als host voor uw HANA Large Instances-eenheid wordt gebruikt.

Raadpleeg het artikel Azure HANA Large Instances controlthrough Azure Portal om te bepalen of uw HANA Large Instances-eenheid is geïmplementeerd in een Revision 4-stempel of -rij. In het overzicht van kenmerken van uw HANA Large Instances-eenheid kunt u ook de naam van de nabijheidsplaatsingsgroep bepalen omdat deze is gemaakt toen uw HANA Large Instances-eenheid werd geïmplementeerd. De naam die wordt weergegeven in het overzicht van kenmerken is de naam van de nabijheidsplaatsingsgroep waarin u uw toepassingslaag-VM's moet implementeren.

In vergelijking met SAP-systemen die alleen virtuele Azure-machines gebruiken, hebt u, wanneer u HANA Large Instances gebruikt, minder flexibiliteit bij het bepalen hoeveel Azure-resourcegroepen u wilt gebruiken. Alle HANA Large Instances-eenheden van een HANA Large Instances-tenant worden gegroepeerd in één resourcegroep,zoals beschreven in dit artikel. Tenzij u implementeert in verschillende tenants om bijvoorbeeld productie- en niet-productiesystemen of andere systemen te scheiden, worden al uw HANA Large Instances-eenheden geïmplementeerd in één HANA Large Instances-tenant. Deze tenant heeft een een-op-een-relatie met een resourcegroep. Er wordt echter een afzonderlijke nabijheidsplaatsingsgroep gedefinieerd voor elk van de afzonderlijke eenheden.

Als gevolg hiervan worden de relaties tussen Azure-resourcegroepen en nabijheidsplaatsingsgroepen voor één tenant weergegeven zoals hier wordt weergegeven:

Voorbeeld van implementatie met nabijheidsplaatsingsgroepen

Hier volgen enkele PowerShell-opdrachten die u kunt gebruiken om uw VM's te implementeren met Azure-nabijheidsplaatsingsgroepen.

De eerste stap, nadat u zich hebt Azure Cloud Shell,is controleren of u zich in het Azure-abonnement hebt dat u wilt gebruiken voor de implementatie:

Get-AzureRmContext

Als u wilt wijzigen in een ander abonnement, kunt u dit doen door deze opdracht uit te voeren:

Set-AzureRmContext -Subscription "PPG test subscription"

Maak een nieuwe Azure-resourcegroep door deze opdracht uit te voeren:

New-AzResourceGroup -Name "ppgexercise" -Location "westus2"

Maak de nieuwe nabijheidsplaatsingsgroep door deze opdracht uit te voeren:

New-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate" -Location "westus2"

Implementeer uw eerste VM in de nabijheidsplaatsingsgroep met behulp van een opdracht als deze:

New-AzVm -ResourceGroupName "ppgexercise" -Name "ppgscopevm" -Location "westus2" -OpenPorts 80,3389 -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

Met de voorgaande opdracht wordt een virtuele Windows geïmplementeerd. Nadat deze VM-implementatie is geslaagd, wordt het bereik van het netwerkbereik van de nabijheidsplaatsingsgroep gedefinieerd binnen de Azure-regio. Alle volgende VM-implementaties die verwijzen naar de nabijheidsplaatsingsgroep, zoals weergegeven in de voorgaande opdracht, worden geïmplementeerd onder hetzelfde netwerknetwerk, zolang het VM-type kan worden gehost op hardware die onder dat netwerk wordt geplaatst en de capaciteit voor dat VM-type beschikbaar is.

Beschikbaarheidssets en Beschikbaarheidszones combineren met nabijheidsplaatsingsgroepen

Een van de problemen met het gebruik Beschikbaarheidszones voor SAP-systeemimplementaties is dat u de SAP-toepassingslaag niet kunt implementeren met behulp van beschikbaarheidssets binnen de specifieke beschikbaarheidszone. U wilt dat de SAP-toepassingslaag wordt geïmplementeerd in dezelfde zones als de SAP ASCS/SCS-VM's. Op dit moment is het niet mogelijk om te verwijzen naar een beschikbaarheidszone en een beschikbaarheidsset bij het implementeren van één VM. Maar als u alleen een VM implementeert die een beschikbaarheidszone instrueert, verliest u de mogelijkheid om ervoor te zorgen dat de toepassingslaag-VM's zijn verdeeld over verschillende update- en foutdomeinen.

Door nabijheidsplaatsingsgroepen te gebruiken, kunt u deze beperking omzeilen. Dit is de implementatiereeks:

• Maak een nabijheidsplaatsingsgroep.
• Implementeer uw anker-VM, aanbevolen als de ASCS/SCS-VM, door te verwijzen naar een beschikbaarheidszone.
• Maak een beschikbaarheidsset die verwijst naar de Azure-nabijheidsgroep. (Zie de opdracht verder in dit artikel.)
• Implementeer de toepassingslaag-VM's door te verwijzen naar de beschikbaarheidsset en de nabijheidsplaatsingsgroep.

In plaats van de eerste VM te implementeren zoals in de vorige sectie is gedemonstreerd, verwijst u naar een beschikbaarheidszone en de nabijheidsplaatsingsgroep wanneer u de VM implementeert:

New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"

Een geslaagde implementatie van deze virtuele machine zou het ASCS/SCS-exemplaar van het SAP-systeem in één beschikbaarheidszone hosten. Het bereik van de nabijheidsplaatsingsgroep is vastgesteld op een van de netwerkbeschikbaarheidsplaatsen in de beschikbaarheidszone die u hebt gedefinieerd.

In de volgende stap moet u de beschikbaarheidssets maken die u wilt gebruiken voor de toepassingslaag van uw SAP-systeem.

Definieer en maak de nabijheidsplaatsingsgroep. De opdracht voor het maken van de beschikbaarheidsset vereist een aanvullende verwijzing naar de id van de nabijheidsplaatsingsgroep (niet de naam). U kunt de id van de nabijheidsplaatsingsgroep op halen met behulp van deze opdracht:

Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"

Wanneer u de beschikbaarheidsset maakt, moet u aanvullende parameters overwegen wanneer u beheerde schijven gebruikt (standaard tenzij anders aangegeven) en nabijheidsplaatsingsgroepen:

New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2 

In het ideale moment moet u drie foutdomeinen gebruiken. Maar het aantal ondersteunde foutdomeinen kan per regio verschillen. In dit geval is het maximum aantal foutdomeinen dat mogelijk is voor de specifieke regio's twee. Als u uw toepassingslaag-VM's wilt implementeren, moet u een verwijzing toevoegen naar de naam van uw beschikbaarheidsset en de naam van de nabijheidsplaatsingsgroep, zoals hier wordt weergegeven:

New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

Het resultaat van deze implementatie is:

• Een centrale service voor uw SAP-systeem die zich in een specifieke beschikbaarheidszone of Beschikbaarheidszones.
• Een SAP-toepassingslaag die zich bevindt via beschikbaarheidssets in hetzelfde netwerk als de SAP Central-services -VM of -VM's (ASCS/SCS).

Configuraties van nabijheidsplaatsingsgroep van een bestaand systeem wijzigen

Als u nabijheidsplaatsingsgroepen hebt geïmplementeerd vanaf de aanbevelingen die tot nu toe zijn gegeven en u zich wilt aanpassen aan de nieuwe configuratie, kunt u dit doen met de methoden die worden beschreven in deze artikelen:

• VM's implementeren op nabijheidsplaatsingsgroepen met behulp van Azure CLI
• VM's implementeren in nabijheidsplaatsingsgroepen met behulp van PowerShell

U kunt deze opdrachten ook gebruiken voor gevallen waarin u toewijzingsfouten krijgt in gevallen waarin u niet naar een nieuw VM-type kunt gaan met een bestaande VM in de nabijheidsplaatsingsgroep.

Volgende stappen

Bekijk de documentatie:

• SAP-workloads in Azure: controlelijst voor planning en implementatie
• VM's implementeren op nabijheidsplaatsingsgroepen met behulp van Azure CLI
• VM's implementeren in nabijheidsplaatsingsgroepen met behulp van PowerShell
• Overwegingen voor azure Virtual Machines DBMS-implementatie voor SAP-workloads