Dela via

SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner

  • Artikel

Distribution av de olika SAP-arkitekturskikten i Azure Tillgänglighetszoner är den rekommenderade arkitekturen för SAP-arbetsbelastningsdistributioner i Azure. 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. I artikeln visas vilka regioner som tillhandahåller Tillgänglighetszoner. De flesta Azure-regioner som är utrustade för att hantera större SAP-arbetsbelastningar tillhandahåller Tillgänglighetszoner. Nya Azure-regioner tillhandahåller Tillgänglighetszoner från början. Vissa av de äldre regionerna håller på att efteranpassas eller håller på att eftermonteras med Tillgänglighetszoner.

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

  • SAP-programlagret, som kan vara ett till några dussin virtuella datorer (VM). Du vill minimera risken för att virtuella datorer distribueras på samma värdserver. Du vill också att de virtuella datorerna i en acceptabel närhet till databaslagret ska hålla nätverksfördröjningen i ett acceptabelt fönster
  • SAP ASCS/SCS-lagret 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-databasskiktet, 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). Därför skyddas distributionen via tillgänglighetsuppsättningen inte av problem med ström, kylning eller nätverk som påverkar zonens datacenter som helhet. Med tillgänglighetsuppsättningar finns det inte heller någon tvingad justering mellan en virtuell dator och dess diskar. Innebär att diskarna kan finnas i valfritt datacenter i Azure-regionen, oberoende av regionens zonstruktur. På plussidan är de virtuella datorerna justerade med uppdaterings- och feldomäner i zonen eller datacentret. Specifikt för SAP ASCS eller databasskiktet 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), distribuerar de virtuella datorerna på olika fysiska platser och med det läggs skydd mot problem med ström, kylning eller nätverk som påverkar datacenter i zonen som helhet. Virtuella datorer och deras relaterade diskar är också samlokaliserade i samma tillgänglighetszon. 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 databasskiktet där vi vanligtvis tittar på två virtuella datorer vardera. 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 ett angivet antal 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:

  • Mer information om Azure Tillgänglighetszoner finns 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.
  • Om du använder Tillgänglighetszoner som dr-lösning på små avstånd bör du tänka på att vi har upplevt naturkatastrofer som orsakar omfattande skador i olika delar av världen, inklusive stora och omfattande skador på kraftinfrastrukturer. Avstånden mellan olika zoner kanske inte alltid är tillräckligt stora för att kompensera för sådana större naturkatastrofer.
  • Nätverksfördröjningen i Tillgänglighetszoner är inte densamma i alla Azure-regioner. Även inom en Azure-region kan nätverksfördröjningarna mellan de olika zonerna variera. Även i värsta fall fungerar synkron replikering på databasnivå baserat på HANA System Replication eller SQL Server Always On utan att påverka arbetsbelastningens skalbarhet.
  • 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å databasinstanser som behöver synkron replikering. Baserat på mycket lyckade åtgärder i de största NetWeaver- och S/4HANA-systemen mellan zoner med högre nätverksfördröjningar (mindre än 1,5 millisekunder) kan detta övervägas försummas
    • Skillnaden i nätverksfördröjning mellan en virtuell dator som kör en SAP-dialoginstans i zonen med den aktiva databasinstansen 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 databasen eller i en annan zon (se senare i den här artikeln).
  • Nätverksfördröjningen med Azure Tillgänglighetszoner, även i de största zonerna, är tillräckligt låg för att köra SAP-affärsprocesser. Hittills har vi bara sett några undantagsfall där kunderna behövde samlokalisera SAP-programskiktet och databasskiktet under ett enda datacenternätverk.

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-databaslagret och de centrala tjänsterna mellan zoner och samtidigt distribuera SAP-programskiktet med hjälp av tillgänglighetsuppsättningar och ändå uppnå 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.
  • Du måste distribuera zonindelad version av ExpressRoute Gateway, VPN Gateway och offentliga IP-standardadresser för att få det zonskydd du vill ha.

Den perfekta Tillgänglighetszoner kombination

Om du inte konfigurerar affärsprocesstilldelningen med SAP-funktioner som inloggningsgrupper, RFC Server-grupper, Batch Server-grupper och liknande, kan affärsprocesser köras i de olika programinstanserna i ditt SAP-programlager. Bieffekten av det här faktumet är att batchjobb kan köras av alla SAP-programinstanser oberoende av om de körs i samma zon med den aktiva databasinstansen 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 i zonen, kan körningstiden för batchjobb påverkas mer om jobbet kördes i en zon där databasinstansen 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. Rent tekniskt fungerar nätverksfördröjningarna mellan Azure Tillgänglighetszoner i en Azure-region för arkitekturen i NetWeaver, S/4HANA eller andra SAP-program. Det är också upp till dig som kund att minimera sådana skillnader med hjälp av SAP-begreppen inloggningsgrupper, RFC-servergrupper, Batch Server-grupper och liknande när du bestämmer dig för något av de distributionskoncept som vi introducerar i den här artikeln.

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

  • Aktiv/aktiv: De virtuella datorer som kör ASCS/SCS och de virtuella datorer som kör databasskiktet distribueras över två zoner. De virtuella datorer som kör SAP-programlagret distribueras i jämna tal i samma två zoner. Om en databas eller en virtuell ASCS/SCS-dator redviktar kan vissa öppna och aktiva transaktioner återställas. Men användarna är fortfarande inloggade. Det spelar egentligen ingen roll i vilka av zonerna den aktiva virtuella databasdatorn och programinstanserna körs. Den här arkitekturen är den arkitektur som du föredrar att distribuera mellan zoner. I fall där nätverksfördröjningar mellan zoner orsakar större skillnader vid körning av affärsprocesser kan du använda funktioner som SAP-inloggningsgrupper, RFC-servergrupper, Batch Server-grupper och liknande för att dirigera körningen av affärsprocesserna till specifika dialoginstanser som finns i samma zon med den aktiva databasinstansen
  • Aktiv/passiv: De virtuella datorer som kör ASCS/SCS och de virtuella datorer som kör databaslagret distribueras över två zoner. De 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 databasinstansen. Du kan använda den här distributionsarkitekturen om du anser att nätverksfördröjningen i de olika zonerna är för hög. Och med det orsakar oacceptablande skillnader i körningen av dina affärsprocesser. Eller om du vill använda distributioner i tillgänglighetszonen som distributioner av kortdistans-DR. zonerna. Om en virtuell ASCS/SCS- eller databasdator redundansväxlar till den sekundära zonen kan det uppstå 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.

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 databasinstansen 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 databasdatorerna i de två 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. Behandla klassificeringen av nätverkssvarstid i SAP Note #1100926 som grov vägledning. Nätverksfördröjningar som är större än 0,7 millisekunder innebär inte att systemet inte kommer att fungera tekniskt eller att affärsprocesser inte uppfyller dina enskilda serviceavtal. Anteckningen är inte avsedd att ange vad som stöds eller inte stöds av SAP och/eller Microsoft. 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 databaslagret.
  • 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.)

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 enqueue-replikering distribueras mellan två zoner. Detsamma gäller för databaslagret, som distribueras i 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. 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 är acceptabel för din arbetsbelastning.

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

Aktiv/aktiv zondistribution

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-databaslagret är ganska intensiv. Därför kan det aktiva/aktiva scenariot bidra till kostnaderna.

Aktiv/passiv distribution

Om du inte hittar en konfiguration som minskar risken för delta i körningen av SAP-affärsprocesser eller om du vill distribuera en konfiguration för haveriberedskap på kort avstånd kan du distribuera en arkitektur som har ett aktivt/passivt tecken från SAP-programnivåsynpunkt. 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 databasinstansen och SAP Central Services-instansen. Med en sådan konfiguration måste du se till att du inte har extrema variationer i körningstiden, beroende på om ett jobb körs i zonen med den aktiva databasinstansen eller inte, i affärstransaktioner och batchjobb.

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

Aktiv/passiv zondistribution

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

  • Tillgänglighetsuppsättningar kan inte distribueras i Azure Tillgänglighetszoner. För att minimera kan du använda Närhetsplaceringsgrupper i Azure enligt beskrivningen i artikeln Azure Närhetsplaceringsgrupper för optimal nätverksfördröjning med SAP-program.
  • När du använder den här arkitekturen måste du övervaka statusen noga och försöka behålla den aktiva databasinstansen och SAP Central Services-instanserna i samma zon som det distribuerade programskiktet. Om det uppstod en redundansväxling av SAP Central Service eller databasinstansen vill du se till att du manuellt kan växla tillbaka till zonen med SAP-programskiktet distribuerat så snabbt som möjligt.
  • För lastbalanserare för redundanskluster i SAP Central Services och databasskiktet måste du använda Standard SKU Azure Load Balancer. Basic Load Balancer fungerar inte mellan zoner.
  • Du måste distribuera zonindelad version av ExpressRoute Gateway, VPN Gateway och offentliga IP-standardadresser för att få det zonskydd du vill ha.
  • Det virtuella Azure-nätverk som du distribuerade som värd för SAP-systemet, tillsammans med dess undernät, sträcker sig över zoner. Du behöver inte separata virtuella nätverk för varje zon.
  • För alla virtuella datorer som du distribuerar måste du använda Azure Managed Disks. Ohanterade diskar stöds inte för zonindelade distributioner.
  • Azure Premium SSD v2, Ultra SSD-lagring eller Azure NetApp Files stöder inte synkron lagringsreplikering mellan zoner. För databasdistributioner förlitar vi oss på databasmetoder för att replikera data mellan zoner.
  • Premium SSD v1 som stöder synkron zonreplikering över Tillgänglighetszoner inte har testats med SAP-databasarbetsbelastningen. Därför måste den konfigurerbara zonindelade synkrona replikeringen av Azure Premium SSD v1 betraktas som inte stöds för SAP-databasarbetsbelastningar.
  • För SMB- och NFS-resurser baserade på Azure Premium Files erbjuds zonredundans med synkron replikering. I det här dokumentet finns tillgänglighet för ZRS för Azure Premium Files i den region som du vill distribuera till. Användningen av zonindelade replikerade NFS- och SMB-resurser stöds fullt ut med distributioner av SAP-programlager och redundanskluster med hög tillgänglighet för NetWeaver- eller S/4HANA-centraltjänster. Dokument som täcker dessa fall är:
  • Den tredje zonen används som värd för SBD-enheten om du skapar ett SUSE Linux Pacemaker-kluster och använder SBD-enheter i stället för Azure Fencing Agent. Eller för ytterligare programinstanser.
  • Du bör distribuera vilande virtuella datorer i den passiva zonen (från databassynpunkt) så att du kan starta programresurser vid ett zonfel. En annan möjlighet kan vara att använda Azure Site Recovery, som kan replikera aktiva virtuella datorer till vilande virtuella datorer mellan zoner.
  • Du bör investera i automatisering som gör att du automatiskt kan starta SAP-programskiktet i den andra zonen om ett zonavbrott inträffar.

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 (kortdistans-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

Om du använder Tillgänglighetszoner som dr-lösning på små avstånd, eep i åtanke att vi upplevt naturkatastrofer som orsakar omfattande skador i diferent regioner i världen, inklusive tunga och omfattande skador på kraftinfrastrukturer. Avstånden mellan olika zoner kanske inte alltid är tillräckligt stora för att kompensera för sådana större naturkatastrofer.

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

Kombinerad dr med hög tillgänglighet i zoner

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

  • Du antar antingen att det finns ett betydande avstånd mellan de anläggningar som är värdar för en tillgänglighetszon. Eller så tvingas du stanna inom en viss Azure-region. Tillgänglighetsuppsättningar kan inte distribueras i Azure Tillgänglighetszoner. För att kompensera för detta kan du använda Närhetsplaceringsgrupper i Azure enligt beskrivningen i artikeln Azure Proximity Placement Groups för optimal nätverksfördröjning med SAP-program.
  • När du använder den här arkitekturen måste du övervaka statusen noga och försöka behålla den aktiva databasinstansen och SAP Central Services-instanserna i samma zon som det distribuerade programskiktet. Om det uppstod en redundansväxling av SAP Central Service eller databasinstansen vill du se till att du manuellt kan växla tillbaka till zonen med SAP-programskiktet distribuerat så snabbt som möjligt.
  • Du bör ha produktionsprograminstanser förinstallerade på de virtuella datorer som kör de aktiva QA-programinstanserna.
  • I ett zonindelningsfel stänger du av QA-programinstanserna och startar produktionsinstanserna i stället. Du måste använda virtuella namn för programinstanserna för att det ska fungera.
  • För lastbalanserare för redundanskluster i SAP Central Services och databasskiktet måste du använda Standard SKU Azure Load Balancer. Basic Load Balancer fungerar inte mellan zoner.
  • Du måste distribuera zonindelad version av ExpressRoute Gateway, VPN Gateway och offentliga IP-standardadresser för att få det zonskydd du vill ha.
  • Det virtuella Azure-nätverk som du distribuerade som värd för SAP-systemet, tillsammans med dess undernät, sträcker sig över zoner. Du behöver inte separata virtuella nätverk för varje zon.
  • För alla virtuella datorer som du distribuerar måste du använda Azure Managed Disks. Ohanterade diskar stöds inte för zonindelade distributioner.
  • Azure Premium SSD v2, Ultra SSD-lagring eller Azure NetApp Files stöder inte synkron lagringsreplikering mellan zoner. För databasdistributioner förlitar vi oss på databasmetoder för att replikera data mellan zoner.
  • Premium SSD v1 som stöder synkron zonreplikering över Tillgänglighetszoner inte har testats med SAP-databasarbetsbelastningen. Därför måste den konfigurerbara zonindelade synkrona replikeringen av Azure Premium SSD v1 betraktas som inte stöds för SAP-databasarbetsbelastningar.
  • För SMB- och NFS-resurser baserade på Azure Premium Files erbjuds zonredundans med synkron replikering. I det här dokumentet finns tillgänglighet för ZRS för Azure Premium Files i den region som du vill distribuera till. Användningen av zonindelade replikerade NFS- och SMB-resurser stöds fullt ut med distributioner av SAP-programlager och redundanskluster med hög tillgänglighet för NetWeaver- eller S/4HANA-centraltjänster. Dokument som täcker dessa fall är:
  • Den tredje zonen används som värd för SBD-enheten om du skapar ett SUSE Linux Pacemaker-kluster och använder SBD-enheter i stället för Azure Fencing Agent.

Nästa steg

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