Närhetsplaceringsgrupper i Azure för optimal svarstid för nätverk med SAP-program

SAP-program som baseras på SAP NetWeaver- eller SAP S/4HANA-arkitekturen är känsliga för nätverksfördröjning mellan SAP-programnivån och SAP-databasnivån. Den här känsligheten är resultatet av den mesta av affärslogiken som körs i programlagret. Eftersom SAP-programlagret kör affärslogiken utfärdar det frågor till databasnivån med hög frekvens, med en hastighet på tusentals eller tiotusentals per sekund. I de flesta fall är frågorna enkla. De kan ofta köras på databasnivån på 500 mikrosekunder eller mindre.

Den tid som läggs på nätverket för att skicka en sådan fråga från programnivån till databasnivån och ta emot resultatet som skickas tillbaka har en stor inverkan på den tid det tar att köra affärsprocesser. Den här känsligheten för nätverksfördröjning är anledningen till att du kanske vill uppnå en viss minsta nätverksfördröjning i SAP-distributionsprojekt. Se SAP Note #1100926 – Vanliga frågor och svar: Nätverksprestanda för riktlinjer om hur du klassificerar nätverksfördröjningen.

I många Azure-regioner har antalet datacenter ökat. Samtidigt använder kunder, särskilt för avancerade SAP-system, mer särskilda VM-familjer som M- eller Mv2-familj, eller i sällsynta fall HANA – stora instanser. Dessa typer av virtuella Azure-datorer är inte alltid tillgängliga i vart och ett av de datacenter som samlas in i en Azure-region. Dessa fakta kan skapa möjligheter att optimera nätverksfördröjningen mellan SAP-programlagret och SAP DBMS-lagret.

För att du ska kunna optimera nätverksfördröjningen erbjuder Azure närhetsplaceringsgrupper. Närhetsplaceringsgrupper kan användas för att tvinga gruppering av olika typer av virtuella datorer under ett enda nätverk som ger tillräckligt med kort nätverksfördröjning mellan dessa olika VM-typer där det ännu inte har tillhandahållits. När den första virtuella datorn distribueras till en sådan närhetsplaceringsgrupp binds den virtuella datorn till ett specifikt nätverk. Eftersom alla andra virtuella datorer som ska distribueras till samma närhetsplaceringsgrupp grupperas de virtuella datorerna under samma nätverk. Som tilltalande som denna potentiell kund låter, introducerar användningen av konstruktionen även vissa begränsningar och fallgropar:

• Du kan inte anta att alla typer av virtuella Azure-datorer är tillgängliga i alla Azure-datacenter eller under varje nätverk. Därför kan kombinationen av olika typer av virtuella datorer i en närhetsplaceringsgrupp vara mycket begränsad. Dessa begränsningar uppstår eftersom den värdmaskinvara som behövs för att köra en viss typ av virtuell dator kanske inte finns i datacentret eller i nätverket som närhetsplaceringsgruppen har tilldelats
• När du ändrar storlek på delar av de virtuella datorer som finns i en närhetsplaceringsgrupp kan du inte automatiskt anta att den nya VM-typen alltid är tillgänglig i samma datacenter eller under nätverket via närhetsplaceringsgruppen som tilldelades till
• När Azure inaktiverar maskinvara kan det tvinga vissa virtuella datorer i en närhetsplaceringsgrupp till ett annat Azure-datacenter eller ett annat nätverk. Mer information om det här fallet finns i dokumentet Närhetsplaceringsgrupper

Scenarierna där du har använt närhetsplaceringsgrupper hittills var:

• Distribuera SAP-arbetsbelastning med tillgänglighetsuppsättningar. Där SAP-databasnivån, SAP-programnivån och virtuella ASCS/SCS-datorer grupperades i tre olika tillgänglighetsuppsättningar. I sådana fall ville du se till att tillgänglighetsuppsättningarna inte sprids över hela Azure-regionen eftersom detta, beroende på Azure-regionen, kan resultera i nätverksfördröjning som kan påverka SAP-arbetsbelastningen negativt
• Du ville distribuera de kritiska resurserna för din SAP-arbetsbelastning över olika Tillgänglighetszoner och å andra sidan se till att de virtuella datorerna på programnivån i var och en av zonerna sprids över olika feldomäner med hjälp av tillgänglighetsuppsättningar. I det här fallet, som beskrivs senare i dokumentet, är närhetsplaceringsgrupper det lim som behövs
• Du använde närhetsplaceringsgrupper för att gruppera virtuella datorer för att uppnå optimal nätverksfördröjning mellan de tjänster som finns på de virtuella datorerna

När det gäller distributionsscenario nr 1 är nätverksfördröjningen oberoende av var de virtuella datorerna landar i i många regioner, särskilt i regioner utan Tillgänglighetszoner och de flesta regioner med Tillgänglighetszoner. Även om det finns vissa Azure-regioner som inte kan ge en tillräckligt bra upplevelse utan att placera de tre olika tillgänglighetsuppsättningarna tillsammans med användningen av tillgänglighetsuppsättningar. Från och med distributionsscenario nr 2 rekommenderar vi ett annat sätt att använda närhetsplaceringsgrupper i följande avsnitt i det här dokumentet.

Vad är närhetsplaceringsgrupper?

En närhetsplaceringsgrupp i Azure är en logisk konstruktion. När en närhetsplaceringsgrupp definieras är den bunden till en Azure-region och en Azure-resursgrupp. När virtuella datorer distribueras refereras en närhetsplaceringsgrupp till av:

• Den första virtuella Azure-datorn som distribueras under ett nätverk med många Azure-beräkningsenheter och låg nätverksfördröjning. Ett sådant nätverk matchar ofta ett enda Azure-datacenter. Du kan tänka på den första virtuella datorn som en "virtuell omfångsdator" som distribueras till en beräkningsskalningsenhet baserat på Azure-allokeringsalgoritmer som så småningom kombineras med distributionsparametrar.
• Alla efterföljande virtuella datorer som distribueras som refererar till närhetsplaceringsgruppen kommer att distribueras under samma nätverk som den första virtuella datorn.

En enda Azure-resursgrupp kan ha flera tilldelade närhetsplaceringsgrupper. Men en närhetsplaceringsgrupp kan bara tilldelas en Azure-resursgrupp.

Närhetsplaceringsgrupper med SAP-system som endast använder virtuella Azure-datorer

I det här avsnittet går vi igenom de distributionsarkitekturer som har använts hittills och nya rekommendationer

Närhetsplaceringsgrupper med zonindeala distributioner

För distributioner som inte använder stora HANA-instanser är det viktigt att tillhandahålla en någorlunda låg nätverksfördröjning mellan SAP-programnivån och DBMS-nivån. För att möjliggöra en sådan någorlunda låg nätverksfördröjning för en begränsad uppsättning scenarier kan en Azure-närhetsplaceringsgrupp definieras för ett sådant SAP-system.

Undvik att paketering av flera SAP-produktionssystem eller icke-produktionssystem i en enda närhetsplaceringsgrupp. Undvik paket med SAP-system eftersom ju fler system du grupperar i en närhetsplaceringsgrupp, desto högre är sannolikheten:

• Att du behöver en typ av virtuell dator som inte är tillgänglig under nätverket som närhetsplaceringsgruppen har tilldelats till.
• Resurserna för icke-vanliga virtuella datorer, till exempel virtuella datorer i M-serien, kan så småningom bli ouppfyllda när du behöver utöka antalet virtuella datorer till en närhetsplaceringsgrupp över tid.

Användningen av närhetsplaceringsgruppen som vi har rekommenderat hittills ser ut som på den här bilden

Du har skapat en närhetsplaceringsgrupp (PPG) i var och en av de Tillgänglighetszoner som du distribuerade SAP-systemet till. Alla virtuella datorer i en viss zon är en del av den enskilda närhetsplaceringsgruppen för den specifika zonen. Du började i varje zon med att distribuera den virtuella DBMS-datorn för att begränsa PPG:n och distribuerade sedan den virtuella ASCS-datorn till samma zon och PPG. I ett tredje steg skapade du en Azure-tillgänglighetsuppsättning, tilldelade tillgänglighetsuppsättningen till den begränsade PPG:en och distribuerade SAP-programlagret till den. Fördelen med den här konfigurationen var att alla komponenter var snyggt justerade under samma nätverk. Den stora nackdelen är att din flexibilitet vid storleksändring av virtuella datorer kan begränsas.

Baserat på många förbättringar som distribuerats av Microsoft i Azure-regionerna för att minska nätverksfördröjningen i en Azure-tillgänglighetszon ser den nya distributionsvägledningen för zonindelade distributioner ut så här:

Skillnaden jämfört med rekommendationen hittills är att de virtuella databas datorerna i de två zonerna inte längre är en del av närhetsplaceringsgrupperna. Närhetsplaceringsgrupper per zon är nu begränsade till distributionen av den virtuella dator som kör SAP ASCS/SCS-instanserna. Det innebär också att för de regioner där Tillgänglighetszoner samlas in av flera datacenter kan ASCS/SCS-instansen och programnivån köras under ett nätverk och de virtuella databasdatorerna kan köras under ett annat nätverk. Även om nätverksförbättringarna har gjorts bör nätverksfördröjningen mellan SAP-programnivån och DBMS-nivån fortfarande vara tillräcklig för tillräckligt bra prestanda och dataflöde. Fördelen med den här nya konfigurationen är att du har mer flexibilitet när det gäller att ändra storlek på virtuella datorer eller flytta till nya VM-typer med antingen DBMS-lagret eller/och sap-systemets programlager.

Närhetsplaceringsgrupper med distributioner av tillgänglighetsuppsättning

I det här fallet är syftet att använda närhetsplaceringsgrupper för att samla de virtuella datorer som distribueras via olika tillgänglighetsuppsättningar. I det här användningsscenariot använder du inte en kontrollerad distribution över Tillgänglighetszoner i en region. I stället vill du distribuera SAP-systemet med hjälp av tillgänglighetsuppsättningar. Därför har du minst en tillgänglighetsuppsättning för virtuella DBMS-datorer, virtuella ASCS/SCS-datorer och virtuella datorer på programnivå. Eftersom du inte kan ange en tillgänglighetsuppsättning OCH en tillgänglighetszon för en virtuell dator kan du inte styra var de virtuella datorerna i de olika tillgänglighetsuppsättningarna ska allokeras. Detta kan leda till att nätverksfördröjningen mellan olika virtuella datorer fortfarande kan vara för hög för att ge en tillräckligt bra prestandaupplevelse i vissa Azure-regioner. Så den resulterande arkitekturen skulle se ut så här:

I den här bilden skulle en enda närhetsplaceringsgrupp tilldelas till ett enda SAP-system. Denna PPG tilldelas till de tre tillgänglighetsuppsättningarna. Närhetsplaceringsgruppen definieras sedan genom att de första virtuella datorerna på databasnivå distribueras till DBMS-tillgänglighetsuppsättningen. Den här arkitekturrekommendationen kommer att samla alla virtuella datorer under samma nätverk. Den inför de begränsningar som nämnts tidigare i den här artikeln. Därför bör arkitekturen för närhetsplaceringsgruppen användas sparsamt.

Närhetsplaceringsgrupper och HANA – stora instanser

Om vissa av dina SAP-system förlitar sig på hana stora instanser för programlagret kan du uppleva betydande förbättringar av nätverksfördröjningen mellan enheten för stora HANA-instanser och virtuella Azure-datorer när du använder hana stora instansenheter som distribueras i Revision 4-rader eller -stämplar. En förbättring är att enheter för stora HANA-instanser distribueras med en närhetsplaceringsgrupp när de distribueras. Du kan använda den närhetsplaceringsgruppen för att distribuera dina virtuella datorer på programnivån. Därför distribueras dessa virtuella datorer i samma datacenter som är värd för enheten för stora HANA-instanser.

Om du vill ta reda på om enheten för stora HANA-instanser har distribuerats i en revision 4-stämpel eller rad läser du artikeln om kontroll av stora Azure HANA-instanser via Azure Portal. I attributöversikten för enheten för stora HANA-instanser kan du också fastställa namnet på närhetsplaceringsgruppen eftersom den skapades när enheten för stora HANA-instanser distribuerades. Namnet som visas i attributöversikten är namnet på närhetsplaceringsgruppen som du ska distribuera dina virtuella datorer på programnivån till.

Jämfört med SAP-system som endast använder virtuella Azure-datorer har du mindre flexibilitet när du använder stora HANA-instanser när du bestämmer hur många Azure-resursgrupper som ska användas. Alla stora HANA-instansenheter i en klientorganisation för stora HANA-instanser är grupperade i en enda resursgrupp, enligt beskrivningen i den här artikeln. Om du inte distribuerar till olika klienter för att separera, till exempel produktionssystem och icke-produktionssystem eller andra system, kommer alla dina hana stora instansenheter att distribueras i en enda klientorganisation för stora HANA-instanser. Den här klientorganisationen har en en-till-en-relation med en resursgrupp. Men en separat närhetsplaceringsgrupp definieras för var och en av de enskilda enheterna.

Det innebär att relationerna mellan Azure-resursgrupper och närhetsplaceringsgrupper för en enskild klientorganisation visas här:

Exempel på distribution med närhetsplaceringsgrupper

Nedan följer några PowerShell-kommandon som du kan använda för att distribuera dina virtuella datorer med Närhetsplaceringsgrupper i Azure.

Det första steget när du har loggat in på Azure Cloud Shellär att kontrollera om du är i den Azure-prenumeration som du vill använda för distributionen:

Get-AzureRmContext

Om du behöver ändra till en annan prenumeration kan du göra det genom att köra det här kommandot:

Set-AzureRmContext -Subscription "PPG test subscription"

Skapa en ny Azure-resursgrupp genom att köra det här kommandot:

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

Skapa den nya närhetsplaceringsgruppen genom att köra det här kommandot:

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

Distribuera din första virtuella dator till närhetsplaceringsgruppen med hjälp av ett kommando som det här:

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

Föregående kommando distribuerar en Windows-baserad virtuell dator. När distributionen av den virtuella datorn lyckas definieras närhetsplaceringsgruppens nätverksomfång i Azure-regionen. Alla efterföljande VM-distributioner som refererar till närhetsplaceringsgruppen, som visas i föregående kommando, distribueras under samma nätverk, så länge VM-typen kan finnas på maskinvara som placerats under nätverket och kapaciteten för den vm-typen är tillgänglig.

Kombinera tillgänglighetsuppsättningar och Tillgänglighetszoner med närhetsplaceringsgrupper

Ett av problemen med att Tillgänglighetszoner för SAP-systemdistributioner är att du inte kan distribuera SAP-programnivån med hjälp av tillgänglighetsuppsättningar inom den specifika tillgänglighetszonen. Du vill att SAP-programnivån ska distribueras i samma zoner som de virtuella SAP ASCS/SCS-datorerna. Det går inte att referera till en tillgänglighetszon och en tillgänglighetsuppsättning när du distribuerar en enskild virtuell dator just nu. Men om du bara distribuerar en virtuell dator som instruerar en tillgänglighetszon förlorar du möjligheten att se till att de virtuella datorerna på programnivån sprids över olika uppdaterings- och feldomäner.

Genom att använda närhetsplaceringsgrupper kan du kringgå den här begränsningen. Här är distributionssekvensen:

• Skapa en närhetsplaceringsgrupp.
• Distribuera din virtuella fästpunkts-VM, vilket rekommenderas som den virtuella ASCS/SCS-datorn, genom att referera till en tillgänglighetszon.
• Skapa en tillgänglighetsuppsättning som refererar till Azure-närhetsgruppen. (Se kommandot senare i den här artikeln.)
• Distribuera de virtuella datorerna på programnivån genom att referera till tillgänglighetsuppsättningen och närhetsplaceringsgruppen.

I stället för att distribuera den första virtuella datorn som visas i föregående avsnitt refererar du till en tillgänglighetszon och närhetsplaceringsgruppen när du distribuerar den virtuella datorn:

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

En lyckad distribution av den här virtuella datorn skulle vara värd för ASCS/SCS-instansen av SAP-systemet i en tillgänglighetszon. Omfånget för närhetsplaceringsgruppen är fast i ett av nätverken i den tillgänglighetszon som du definierade.

I nästa steg måste du skapa de tillgänglighetsuppsättningar som du vill använda för sap-systemets programlager.

Definiera och skapa närhetsplaceringsgruppen. Kommandot för att skapa tillgänglighetsuppsättningen kräver ytterligare en referens till närhetsplaceringsgruppens ID (inte namnet). Du kan hämta ID:t för närhetsplaceringsgruppen med hjälp av det här kommandot:

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

När du skapar tillgänglighetsuppsättningen måste du överväga ytterligare parametrar när du använder hanterade diskar (standard om inget annat anges) och närhetsplaceringsgrupper:

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

Vi rekommenderar att du använder tre feldomäner. Men antalet feldomäner som stöds kan variera från region till region. I det här fallet är det maximala antalet feldomäner som är möjliga för de specifika regionerna två. Om du vill distribuera dina virtuella datorer på programnivån måste du lägga till en referens till namnet på tillgänglighetsuppsättningen och närhetsplaceringsgruppens namn, som du ser här:

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

Resultatet av den här distributionen är:

• En central tjänst för ditt SAP-system som finns i en specifik tillgänglighetszon eller Tillgänglighetszoner.
• Ett SAP-programlager som finns via tillgänglighetsuppsättningar i samma nätverk som den virtuella SAP Central Services-datorn (ASCS/SCS) eller virtuella datorer.

Ändra närhetsplaceringsgruppkonfigurationer för ett befintligt system

Om du har implementerat närhetsplaceringsgrupper från och med de rekommendationer som har getts hittills, och du vill anpassa dig till den nya konfigurationen, kan du göra det med de metoder som beskrivs i dessa artiklar:

• Distribuera virtuella datorer till närhetsplaceringsgrupper med Azure CLI
• Distribuera virtuella datorer till närhetsplaceringsgrupper med PowerShell

Du kan också använda dessa kommandon för fall där du får allokeringsfel i fall där du inte kan flytta till en ny typ av virtuell dator med en befintlig virtuell dator i närhetsplaceringsgruppen.

Nästa steg

Läs dokumentationen:

• SAP-arbetsbelastningar i Azure: checklista för planering och distribution
• Distribuera virtuella datorer till närhetsplaceringsgrupper med Azure CLI
• Distribuera virtuella datorer till närhetsplaceringsgrupper med PowerShell
• Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastningar