SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner

  • Artikel

Utöver distributionen av de olika SAP-arkitekturskikten i Azure-tillgänglighetsuppsättningar kan Azure Tillgänglighetszoner även användas för SAP-arbetsbelastningsdistributioner. En Azure-tillgänglighetszon definieras som: "Unika fysiska platser i en region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk". Azure Tillgänglighetszoner är inte tillgängligt i alla regioner. För Azure-regioner som tillhandahåller Tillgänglighetszoner kontrollerar du azure-regionkartan. Den här kartan visar vilka regioner som tillhandahåller eller meddelas för att tillhandahålla Tillgänglighetszoner.

Från och med den typiska SAP NetWeaver- eller S/4HANA-arkitekturen måste du skydda tre olika lager:

  • SAP-programlager, som kan vara en till några dussin virtuella datorer. Du vill minimera risken för att virtuella datorer distribueras på samma värdserver. Du vill också att de virtuella datorerna ska vara i en acceptabel närhet till DBMS-lagret för att hålla nätverksfördröjningen i ett acceptabelt fönster
  • SAP ASCS/SCS-lager som representerar en enskild felpunkt i SAP NetWeaver- och S/4HANA-arkitekturen. Du tittar vanligtvis på två virtuella datorer som du vill täcka med ett redundansramverk. Därför bör dessa virtuella datorer allokeras i olika infrastrukturfeldomäner
  • SAP DBMS-lagret, som också representerar en enskild felpunkt. I vanliga fall består den av två virtuella datorer som omfattas av ett redundansramverk. Därför bör dessa virtuella datorer allokeras i olika infrastrukturfeldomäner. Undantag är SAP HANA-utskalningsdistributioner där fler än två virtuella datorer kan användas

De största skillnaderna mellan att distribuera kritiska virtuella datorer via tillgänglighetsuppsättningar eller Tillgänglighetszoner är:

  • Distribution med en tillgänglighetsuppsättning är att rada upp de virtuella datorerna i uppsättningen i en enda zon eller ett datacenter (vad som än gäller för den specifika regionen). Det innebär att distributionen via tillgänglighetsuppsättningen inte skyddas av problem med ström, kylning eller nätverk som påverkar datakällorna i zonen som helhet. På plussidan är de virtuella datorerna justerade med uppdaterings- och feldomäner i zonen eller datacentret. Specifikt för SAP ASCS- eller DBMS-lagret där vi skyddar två virtuella datorer per tillgänglighetsuppsättning förhindrar justeringen med feldomäner att båda de virtuella datorerna hamnar på samma värdmaskinvara.
  • När du distribuerar virtuella datorer via Azure Tillgänglighetszoner och väljer olika zoner (högst tre möjliga), kommer de virtuella datorerna att distribueras på olika fysiska platser och med det läggs skydd mot problem med ström, kylning eller nätverk som påverkar datakällorna i zonen som helhet. Men eftersom du distribuerar mer än en virtuell dator i samma VM-familj till samma tillgänglighetszon finns det inget skydd mot att de virtuella datorerna hamnar på samma värd eller samma feldomän. Därför är distribution via Tillgänglighetszoner perfekt för SAP ASCS- och DBMS-lagret där vi vanligtvis tittar på två virtuella datorer var. För SAP-programskiktet, som kan vara drastiskt fler än två virtuella datorer, kan du behöva återgå till en annan distributionsmodell (se senare)

Din motivation för en distribution i Azure Tillgänglighetszoner bör vara att du, utöver att täcka fel på en enskild kritisk virtuell dator eller möjlighet att minska stilleståndstiden för programkorrigering inom en kritisk, vill skydda mot större infrastrukturproblem som kan påverka tillgängligheten för ett eller flera Azure-datacenter.

Som en annan funktion för återhämtningsdistribution introducerade Azure vm-skalningsuppsättningar med flexibel orkestrering för SAP-arbetsbelastningar. Vm-skalningsuppsättning ger logisk gruppering av plattformshanterade virtuella datorer. Den flexibla orkestreringen av VM-skalningsuppsättningen ger möjlighet att skapa skalningsuppsättningen inom en region eller sträcka sig över tillgänglighetszoner. När du skapar den flexibla skalningsuppsättningen i en region med platformFaultDomainCount>1 (FD>1) distribueras de virtuella datorerna i skalningsuppsättningen över det angivna antalet feldomäner i samma region. Å andra sidan skulle skapandet av den flexibla skalningsuppsättningen mellan tillgänglighetszoner med platformFaultDomainCount=1 (FD=1) distribuera de virtuella datorerna mellan olika zoner och skalningsuppsättningen skulle också distribuera virtuella datorer mellan olika feldomäner inom varje zon på bästa sätt. För SAP-arbetsbelastning stöds endast flexibel skalningsuppsättning med FD=1. Fördelen med att använda flexibla skalningsuppsättningar med FD=1 för distribution mellan zonindelningar, i stället för traditionell distribution av tillgänglighetszoner är att de virtuella datorer som distribueras med skalningsuppsättningen distribueras över olika feldomäner i zonen på bästa sätt. Mer information finns i distributionsguiden för flexibel skalningsuppsättning för SAP-arbetsbelastning.

Överväganden för att distribuera över Tillgänglighetszoner

Tänk på följande när du använder Tillgänglighetszoner:

  • Den maximala svarstiden för nätverksrundan mellan Azure Tillgänglighetszoner anges i dokumentet Regioner och tillgänglighetszoner.
  • Den erfarna svarstiden för nätverksrundan är inte nödvändigtvis ett tecken på det verkliga geografiska avståndet för de datacenter som utgör de olika zonerna. Svarstiden för nätverksrundan påverkas också av kabelanslutningarna och kablarnas routning mellan dessa olika datacenter.
  • Tillgänglighetszoner är inte en idealisk DR-lösning. Naturkatastrofer kan orsaka omfattande skador i världsregioner, inklusive stora skador på elinfrastrukturer. Avstånden mellan olika zoner kanske inte är tillräckligt stora för att utgöra en lämplig DR-lösning.
  • Nätverksfördröjningen i Tillgänglighetszoner är inte densamma i alla Azure-regioner. I vissa fall kan du distribuera och köra SAP-programskiktet över olika zoner eftersom nätverksfördröjningen från en zon till den aktiva virtuella DBMS-datorn är acceptabel. Men i vissa Azure-regioner är svarstiden mellan den aktiva virtuella dbms-datorn och SAP-programinstansen, när den distribueras i olika zoner, inte acceptabel för SAP-affärsprocesser. I dessa fall måste distributionsarkitekturen vara annorlunda, med en aktiv/aktiv arkitektur för programmet eller en aktiv/passiv arkitektur där nätverksfördröjningen mellan zoner är för hög.
  • När du bestämmer var du ska använda Tillgänglighetszoner ska du basera ditt beslut på nätverksfördröjningen mellan zonerna. Nätverksfördröjning spelar en viktig roll inom två områden:
    • Svarstid mellan de två DBMS-instanserna som behöver synkron replikering. Ju högre nätverksfördröjning, desto mer sannolikt påverkar det skalbarheten för din arbetsbelastning.
    • Skillnaden i nätverksfördröjning mellan en virtuell dator som kör en SAP-dialoginstans i zonen med den aktiva DBMS-instansen och en liknande virtuell dator i en annan zon. När den här skillnaden ökar ökar även påverkan på körningstiden för affärsprocesser och batchjobb, beroende på om de körs i zonen med DBMS eller i en annan zon.

När du distribuerar virtuella Azure-datorer över Tillgänglighetszoner och upprättar redundanslösningar i samma Azure-region gäller vissa begränsningar:

  • Du måste använda Azure Managed Disks när du distribuerar till Azure Tillgänglighetszoner.
  • Mappningen av zonuppräkningar till de fysiska zonerna är fast på azure-prenumerationsbasis. Om du använder olika prenumerationer för att distribuera dina SAP-system måste du definiera de perfekta zonerna för varje prenumeration. Om du vill jämföra den logiska mappningen för dina olika prenumerationer bör du överväga skriptet Avzone-Mapping
  • Du kan inte distribuera Azure-tillgänglighetsuppsättningar i en Azure-tillgänglighetszon om du inte använder Azure Proximity Placement Group. Hur du kan distribuera SAP DBMS-lagret och de centrala tjänsterna mellan zoner och samtidigt distribuera SAP-programskiktet med hjälp av tillgänglighetsuppsättningar och ändå uppnå nära närhet till de virtuella datorerna finns i artikeln Azure Närhetsplaceringsgrupper för optimal nätverksfördröjning med SAP-program. Om du inte använder Närhetsplaceringsgrupper i Azure måste du välja det ena eller det andra som ett distributionsramverk för virtuella datorer.
  • Du kan inte använda en Azure Basic Load Balancer för att skapa redundansklusterlösningar baserade på Windows Server-redundanskluster eller Linux Pacemaker. I stället måste du använda SKU:n för Azure Standard Load Balancer.

Den perfekta Tillgänglighetszoner kombination

Om du vill distribuera ett SAP NetWeaver- eller S/4HANA-system mellan zoner finns det två arkitekturmönster som du kan distribuera:

  • Aktiv/aktiv: Paret med virtuella datorer som kör ASCS/SCS och paret vms som kör DBMS-lagret distribueras över två zoner. Antalet virtuella datorer som kör SAP-programskiktet distribueras i jämna tal i samma två zoner. Om en virtuell DBMS- eller ASCS/SCS-dator redviktar kan vissa av de öppna och aktiva transaktionerna återställas. Men användarna är fortfarande inloggade. Det spelar egentligen ingen roll i vilka av zonerna den aktiva virtuella DBMS-datorn och programinstanserna körs. Den här arkitekturen är den arkitektur som du föredrar att distribuera mellan zoner.
  • Aktiv/passiv: Det par med virtuella datorer som kör ASCS/SCS och paret med VMS som kör DBMS-lagret distribueras över två zoner. Antalet virtuella datorer som kör SAP-programlagret distribueras till en av de Tillgänglighetszoner. Du kör programskiktet i samma zon som den aktiva ASCS/SCS- och DBMS-instansen. Du använder den här distributionsarkitekturen om nätverksfördröjningen mellan de olika zonerna är för hög för att köra programskiktet som är distribuerat mellan zonerna. I stället måste SAP-programlagret köras i samma zon som den aktiva ASCS/SCS- och/eller DBMS-instansen. Om en virtuell ASCS-/SCS- eller DBMS-dator redundansväxlar till den sekundära zonen kan du stöta på högre nätverksfördröjning och därmed minska dataflödet. Och du måste återställa den tidigare redundansväxla virtuella datorn så snart som möjligt för att komma tillbaka till tidigare dataflödesnivåer. Om ett zonindelad avbrott inträffar måste programlagret redundansväxas till den sekundära zonen. En aktivitet som användarna upplever som fullständig systemavstängning. I vissa Azure-regioner är den här arkitekturen den enda livskraftiga arkitekturen när du vill använda Tillgänglighetszoner. Om du inte kan acceptera den potentiella effekten av att en ASCS/SCS- eller DBMS VMS reder över till den sekundära zonen kan det vara bättre att hålla dig till distributioner av tillgänglighetsuppsättningar

Så innan du bestämmer dig för hur du ska använda Tillgänglighetszoner måste du bestämma:

  • Nätverksfördröjningen mellan de tre zonerna i en Azure-region. Genom att känna till nätverksfördröjningen mellan zonerna i en region kan du välja de zoner som har minst nätverksfördröjning i nätverkstrafik mellan zoner.
  • Skillnaden mellan svarstid för virtuell dator till virtuell dator inom någon av de zoner som du väljer och nätverksfördröjningen mellan två zoner som du väljer.
  • En bestämning av om de vm-typer som du behöver distribuera är tillgängliga i de två zoner som du har valt. Med vissa SKU:er för virtuella datorer kan det uppstå situationer där vissa SKU:er endast är tillgängliga i två av de tre zonerna.

Nätverksfördröjning mellan och inom zoner

För att fastställa svarstiden mellan de olika zonerna måste du:

  • Distribuera den vm-SKU som du vill använda för din DBMS-instans i alla tre zonerna. Kontrollera att Azure Accelerated Networking är aktiverat när du utför den här mätningen. Accelererat nätverk är standardinställningen sedan några år. Kontrollera dock om den är aktiverad och fungerar
  • När du hittar de två zonerna med minst nätverksfördröjning distribuerar du ytterligare tre virtuella datorer av den virtuella dator-SKU:n som du vill använda som den virtuella programnivådatorn i de tre Tillgänglighetszoner. Mät nätverksfördröjningen mot de två virtuella DBMS-datorerna i de två DBMS-zoner som du har valt.
  • Använd niping som mätverktyg. Det här verktyget från SAP beskrivs i SAP-supportanteckningarna #500235 och #1100926. Fokusera på kommandona som dokumenterats för svarstidsmätningar. Eftersom ping inte fungerar via kodsökvägarna för Azure Accelerated Networking rekommenderar vi inte att du använder den.

Du behöver inte utföra dessa tester manuellt. Du hittar en PowerShell-procedur för svarstidstest för tillgänglighetszoner som automatiserar de svarstidstester som beskrivs.

Baserat på dina mått och tillgängligheten för dina VM-SKU:er i Tillgänglighetszoner måste du fatta några beslut:

  • Definiera de idealiska zonerna för DBMS-lagret.
  • Avgör om du vill distribuera ditt aktiva SAP-programlager över en, två eller alla tre zoner, baserat på skillnader i nätverksfördröjning i zonen jämfört med mellan zoner.
  • Avgör om du vill distribuera en aktiv/passiv konfiguration eller en aktiv/aktiv konfiguration ur programsynpunkt. (Dessa konfigurationer beskrivs senare i den här artikeln.)

När du fattar dessa beslut bör du även ta hänsyn till SAP:s rekommendationer för nätverksfördröjning, enligt beskrivningen i SAP-kommentaren #1100926.

Viktigt!

De mått och beslut du fattar är giltiga för den Azure-prenumeration som du använde när du utförde måtten. Om du använder en annan Azure-prenumeration kan mappningen av uppräknade zoner vara annorlunda för en annan Azure-prenumeration. Därför måste du upprepa måtten eller ta reda på mappningen av den nya prenumerationen i den gamla prenumerationen med verktyget Avzone-Mapping-skriptet.

Viktigt!

Måtten som beskrevs tidigare förväntas ge olika resultat i varje Azure-region som stöder Tillgänglighetszoner. Även om kraven på nätverksfördröjning är desamma kan du behöva använda olika distributionsstrategier i olika Azure-regioner eftersom nätverksfördröjningen mellan zoner kan skilja sig åt. I vissa Azure-regioner kan nätverksfördröjningen mellan de tre olika zonerna vara mycket olika. I andra regioner kan nätverksfördröjningen mellan de tre olika zonerna vara mer enhetlig. Påståendet att det alltid finns en nätverksfördröjning mellan 1 och 2 millisekunder är inte korrekt. Nätverksfördröjningen för Tillgänglighetszoner i Azure-regioner kan inte generaliseras.

Aktiv/aktiv distribution

Den här distributionsarkitekturen kallas aktiv/aktiv eftersom du distribuerar dina aktiva SAP-programservrar över två eller tre zoner. SAP Central Services-instansen som använder köreplikering distribueras mellan två zoner. Detsamma gäller för DBMS-lagret, som kommer att distribueras över samma zoner som SAP Central Service. När du överväger den här konfigurationen måste du hitta de två Tillgänglighetszoner i din region som erbjuder nätverksfördröjning mellan zoner som är acceptabel för din arbetsbelastning och din synkrona DBMS-replikering. Du vill också vara säker på att deltat mellan nätverksfördröjningen inom de zoner som du har valt och att nätverksfördröjningen mellan zoner inte är för stor.

Sap-arkitekturens natur är att om du inte konfigurerar den på ett annat sätt kan användare och batchjobb köras i de olika programinstanserna. Bieffekten av det här faktumet med den aktiva/aktiva distributionen är att batchjobb kan köras av alla SAP-programinstanser oberoende av om de körs i samma zon med den aktiva DBMS eller inte. Om skillnaden i nätverksfördröjning mellan olika zoner är liten jämfört med nätverksfördröjningen i en zon kanske skillnaden i körningstider för batchjobb inte är betydande. Men ju större skillnaden mellan nätverksfördröjningar i en zon är, jämfört med nätverkstrafik mellan zoner, kan körningstiden för batchjobb påverkas mer om jobbet kördes i en zon där DBMS-instansen inte är aktiv. Det är upp till dig som kund att bestämma vilka godtagbara skillnader i körningstiden som är. Och med det vad den tolerabla nätverksfördröjningen för trafik mellan zoner är för din arbetsbelastning.

Azure-regioner där en sådan aktiv/aktiv distribution kan vara möjlig utan betydande stora skillnader i körningstid och dataflöde i programskiktet som distribueras över olika Tillgänglighetszoner, lista som:

  • Australien, östra (två av de tre zonerna)
  • Brasilien, södra (alla tre zonerna)
  • Indien, centrala (alla tre zonerna)
  • USA, centrala (alla tre zonerna)
  • Asien, östra (alla tre zonerna)
  • USA, östra (två av de tre zonerna)
  • USA, östra 2 (alla tre zonerna)
  • Tyskland, västra centrala (alla tre zonerna)
  • Israel Central (alla tre zonerna)
  • Italien, norra (två av de tre zonerna)
  • Korea Central (alla tre zonerna)
  • Polens centrala (alla tre zonerna)
  • Qatar Central (alla tre zonerna)
  • Europa, norra (alla tre zonerna)
  • Norge, östra (två av de tre zonerna)
  • Sydafrika, norra (två av de tre)
  • USA, södra centrala (alla tre zonerna)
  • Sydostasien (alla tre zonerna)
  • Sweden Central (alla tre zonerna)
  • Schweiz, norra (alla tre zonerna)
  • Uae North (alla tre zoner)
  • Storbritannien, södra (två av de tre zonerna)
  • Europa, västra (två av de tre zonerna)
  • USA, västra 2 (alla tre zonerna)
  • USA, västra 3 (alla tre zonerna)

Den angivna regionlistan hjälper dig inte som kund att testa din arbetsbelastning för att avgöra om en aktiv/aktiv distributionsarkitektur är möjlig.

Azure-regioner där den aktiva/aktiva SAP-distributionsarkitekturen mellan zoner kanske inte är möjlig, lista som:

  • Kanada, centrala
  • Frankrike, centrala
  • Japan, östra

Men för din enskilda arbetsbelastning kan det fungera. Därför bör du testa innan du bestämmer dig för en arkitektur. Azure arbetar ständigt för att förbättra kvaliteten och svarstiden för sina nätverk. Mätningar som utförts för flera år sedan kanske inte längre återspeglar de aktuella förhållandena.

Beroende på vad du är villig att tolerera på körningsskillnader kan även andra regioner som inte anges kvalificera sig.

Ett förenklat schema för en aktiv/aktiv distribution i två zoner kan se ut så här:

Active/Active zone deployment

Följande överväganden gäller för den här konfigurationen:

Viktigt!

I det här aktiva/aktiva scenariot gäller avgifter för trafik mellan zoner. Kontrollera prisinformationen för bandbredd i dokumentet. Dataöverföringen mellan SAP-programskiktet och SAP DBMS-lagret är ganska intensiv. Därför kan det aktiva/aktiva scenariot bidra till kostnaderna.

Aktiv/passiv distribution

Om du inte kan hitta ett acceptabelt delta mellan nätverksfördröjningen i en zon och svarstiden för nätverkstrafik mellan zoner kan du distribuera en arkitektur som har ett aktivt/passivt tecken från SAP-programnivåpunkten. Du definierar en aktiv zon, som är den zon där du distribuerar det fullständiga programskiktet och där du försöker köra både den aktiva DBMS- och SAP Central Services-instansen. Med en sådan konfiguration måste du se till att du inte har extrema körningstidsvariationer, beroende på om ett jobb körs i zonen med den aktiva DBMS-instansen eller inte, i affärstransaktioner och batchjobb.

Azure-regioner där den här typen av distributionsarkitektur mellan olika zoner kan vara att föredra är:

  • Kanada, centrala
  • Frankrike, centrala
  • Japan, östra
  • Norge, östra
  • Sydafrika, norra

Arkitekturens grundläggande layout ser ut så här:

Active/Passive zone deployment

Följande överväganden gäller för den här konfigurationen:

Kombinerad konfiguration av hög tillgänglighet och haveriberedskap

Microsoft delar ingen information om geografiska avstånd mellan de anläggningar som är värdar för olika Azure-Tillgänglighetszoner i en Azure-region. Vissa kunder använder dock zoner för en kombinerad KONFIGURATION av hög tillgänglighet och dr som utlovar ett mål för återställningspunkt (RPO) på noll. Ett RPO på noll innebär att du inte ska förlora några incheckade databastransaktioner även i haveriberedskapsfall.

Kommentar

Vi rekommenderar att du använder en konfiguration som den här endast under vissa omständigheter. Du kan till exempel använda den när data inte kan lämna Azure-regionen av säkerhets- eller efterlevnadsskäl.

Här är ett exempel på hur en sådan konfiguration kan se ut:

Combined high-availability DR in zones

Följande överväganden gäller för den här konfigurationen:

Nästa steg

Här följer några nästa steg för att distribuera i Azure Tillgänglighetszoner: