SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner

  • Artikel
  • 17 minuter för att läsa

Utöver distributionen av de olika SAP-arkitekturskikten i Azure-tillgänglighetsuppsättningar kan de nyligen Azure-tillgänglighetszoner även användas för SAP-arbetsbelastningsdistributioner. En Azure-tillgänglighetszon definieras som: "Unika fysiska platser inom 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ängliga 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 tillkännagivits 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 ett par 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-lagret som representerar en enskild felpunkt i SAP NetWeaver- och S/4HANA-arkitekturen. Vanligtvis tittar du på två virtuella datorer som du vill täcka med ett ramverk för redundans. Därför bör dessa virtuella datorer allokeras i olika fel- och uppdateringsdomäner för infrastrukturen
  • SAP DBMS-lagret, som även representerar en enskild felpunkt. I vanliga fall består den av två virtuella datorer som omfattas av ett ramverk för redundans. Därför bör dessa virtuella datorer allokeras i olika fel- och uppdateringsdomäner för infrastrukturen. Undantag 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 upprättar de virtuella datorerna i uppsättningen i en enda zon eller ett datacenter (oavsett vad som gäller för den specifika regionen). Därför skyddas inte distributionen via tillgänglighetsuppsättningen av strömförsörjnings-, kylnings- eller nätverksproblem som påverkar dataceter för zonen som helhet. På plussidan är de virtuella datorerna justerade med uppdaterings- och feldomäner inom den zonen eller datacentret. Mer specifikt för SAP ASCS- eller DBMS-lagret där vi skyddar två virtuella datorer per tillgänglighetsuppsättning förhindrar justeringen med fel- och uppdateringsdomäner att båda virtuella datorerna hamnar på samma värdmaskinvara
  • Distribution av virtuella datorer via en Azure-tillgänglighetszoner och val av olika zoner (högst tre möjliga hittills) kommer att distribuera de virtuella datorerna på de olika fysiska platserna och med det ytterligare skydd mot ström-, kylnings- eller nätverksproblem som påverkar dataceter i zonen som helhet. Men när du distribuerar fler än en virtuell dator i samma VM-familj i samma tillgänglighetszon finns det inget skydd mot att de virtuella datorerna hamnar på samma värd. Därför är distribution via Tillgänglighetszoner perfekt för SAP ASCS- och DBMS-skiktet där vi vanligtvis tittar på två virtuella datorer vardera. För SAP-programlagret, som kan vara mycket mer än två virtuella datorer, kan du behöva gå tillbaka till en annan distributionsmodell (se senare)

Din motivering för en distribution över Azure-tillgänglighetszoner bör vara att du, utöver att täcka fel på en enskild kritisk virtuell dator eller möjligheten 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.

Att tänka på när du distribuerar Tillgänglighetszoner

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

  • Det finns inga garantier avseende avstånden mellan olika Tillgänglighetszoner i en Azure-region.
  • Tillgänglighetszoner är inte en perfekt DR-lösning. Naturkatastrofer kan orsaka omfattande skador i världsregioner, inklusive tunga skador på energiinfrastrukturer. 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 mellan Tillgänglighetszoner är inte densamma i alla Azure-regioner. I vissa fall kan du distribuera och köra SAP-programlagret ö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 Tillgänglighetszoner bör du basera ditt beslut på nätverksfördröjningen mellan zonerna. Nätverksfördröjning spelar en viktig roll inom två områden:
    • Svarstiden mellan de två DBMS-instanserna som behöver ha synkron replikering. Ju högre nätverksfördröjning, desto troligare kommer det att påverka 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 Tillgänglighetszoner och upprättar redundanslösningar inom 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 zonrä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.
  • 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-programlagret med hjälp av tillgänglighetsuppsättningar och fortfarande uppnå nära de virtuella datorerna finns dokumenterat i artikeln Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program. Om du inte använder närhetsplaceringsgrupper i Azure måste du välja den ena eller den andra som ett distributionsramverk för virtuella datorer.
  • Du kan inte använda en Azure Basic-Load Balancer för att skapa redundansklusterlösningar baserat på Windows Server Failover Clustering eller Linux Pacemaker. I stället måste du använda Azure Standard Load Balancer SKU.

Den Tillgänglighetszoner kombinationen

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

  • Aktiv/aktiv: De virtuella datorer som kör ASCS/SCS och de vms-par som kör DBMS-lagret distribueras mellan två zoner. Antalet virtuella datorer som kör SAP-programlagret distribueras till ett jämnt antal i samma två zoner. Om en DBMS- eller ASCS/SCS-VM misslyckas kan vissa öppna och aktiva transaktioner återställas. Men användarna är fortfarande inloggade. Det spelar egentligen ingen roll i vilken av zonerna som den aktiva virtuella DBMS-datorn och programinstanserna körs i. Den här arkitekturen är den föredragna arkitekturen att distribuera mellan zoner.
  • Aktiv/passiv: De virtuella datorer som kör ASCS/SCS och de vms-par som kör DBMS-lagret distribueras mellan två zoner. Antalet virtuella datorer som kör SAP-programlagret distribueras till en av Tillgänglighetszoner. Du kör programlagret 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 programlagret ska kunna distribueras 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 DATOR med ASCS/SCS eller DBMS går över till den sekundära zonen kan du stöta på högre nätverksfördröjning och med det en minskning av dataflödet. Och du måste växla tillbaka den tidigare redundansade virtuella datorn så snart som möjligt för att komma tillbaka till de tidigare dataflödesnivåerna. Om ett zonindeklarerat avbrott inträffar måste programlagret gå över 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 fungerande arkitekturen när du vill använda Tillgänglighetszoner. Om du inte kan acceptera den potentiella effekten av en ASCS/SCS- eller DBMS VMS-fel i den sekundära zonen kan det vara bättre att hålla dig kvar med distributioner av tillgänglighetsuppsättningen

Innan du bestämmer dig för hur du Tillgänglighetszoner måste du fastställa:

  • 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 zoner med kortast svarstid i nätverkstrafiken mellan zoner.
  • Skillnaden mellan svarstiden för virtuella datorer till virtuella datorer inom en av zonerna, vilket du väljer, och nätverksfördröjningen mellan två zoner som du väljer.
  • En bestämning av om de typer av virtuella datorer som du behöver distribuera är tillgängliga i de två zoner som du har valt. Med vissa virtuella datorer, särskilt virtuella datorer i M-serien, kan du stöta på 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 vm-SKU:n som du vill använda för DBMS-instansen i alla tre zoner. Kontrollera att Azures accelererade nätverk är aktiverat när du gör det här måttet.
  • När du hittar de två zonerna med minst nätverksfördröjning distribuerar du ytterligare tre virtuella datorer i DEN virtuella dator-SKU:n som du vill använda som virtuell dator på programlager över 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å de kommandon som dokumenteras 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 de här testerna manuellt. Du hittar en PowerShell-procedur för tillgänglighetszonsvarstidstest 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 perfekta 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, från ett program perspektiv. (De här konfigurationerna beskrivs senare i den här artikeln.)

När du fattar dessa beslut bör du även ta hänsyn till SAP:s rekommendationer om nätverksfördröjning, som beskrivs i SAP-anteckningen #1100926.

Viktigt

De mått och beslut som du fattar är giltiga för den Azure-prenumeration som du använde när du tog måtten. Om du använder en annan Azure-prenumeration måste du upprepa måtten. Mappningen av uppräknade zoner kan vara annorlunda för en annan Azure-prenumeration.

Viktigt

De mått som beskrivs ovan 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 vara annorlunda. 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. Kravet att det alltid finns en nätverksfördröjning mellan 1 och 2 millisekunder stämmer inte. Nätverksfördröjningen mellan 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 ifyllningsreplikering distribueras mellan två zoner. Samma sak gäller för DBMS-skiktet, som kommer att 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 och din synkrona DBMS-replikering. Du vill också vara säker på att delta mellan nätverksfördröjningen i de zoner som du har valt och nätverksfördröjningen mellan zoner inte är för stor.

Sap-arkitekturen är att om du inte konfigurerar det på olika sätt kan användare och batchjobb köras i olika programinstanser. Sidoeffekten av detta faktum med aktiv/aktiv distribution ä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 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 på nätverksfördröjning i en zon jämfört med över zonnätverkstrafik är, kan körningstiden för batchjobb påverkas mer om jobbet har körts 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 detta är den acceptabel nätverksfördröjning för trafik mellan zoner.

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

  • USA, västra 2 (alla tre zoner)
  • USA, östra 2 (alla tre zoner)
  • USA, centrala (alla tre zoner)
  • Europa, norra (alla tre zoner)
  • Europa, västra (två av de tre zonerna)
  • USA, östra (två av de tre zonerna)
  • USA, södra centrala (två av de tre zonerna)
  • Storbritannien, södra (två av de tre zonerna)
  • Sydostasien

Azure-regioner där den här SAP-distributionsarkitekturen mellan zoner inte rekommenderas är:

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

Beroende på vad du är beredd att tolerera vid körningsskillnader kan även andra regioner som inte finns med i listan kvalificera sig.

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

Distribution i aktiv/aktiv zon

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

  • Om du inte använder Närhetsplaceringsgruppi Azure hanterar du Azure-tillgänglighetszoner som fel- och uppdateringsdomäner för alla virtuella datorer eftersom tillgänglighetsuppsättningar inte kan distribueras i Azure-tillgänglighetszoner.
  • Om du vill kombinera zonindelat distributioner för DBMS-lagret och centrala tjänster, men vill använda Azure-tillgänglighetsuppsättningar för programlagret, måste du använda Azure-närhetsgrupper enligt beskrivningen i artikeln Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.
  • För lastbalanserarna i redundansklustren för SAP Central Services och DBMS-lagret måste du använda standard-SKU:n Azure Load Balancer. Basic-Load Balancer fungerar inte mellan zoner.
  • 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 Storage, Ultra SSD storageeller ANF stöder inte någon typ av lagringsreplikering mellan zoner. Programmet (DBMS eller SAP Central Services) måste replikera viktiga data.
  • Samma sak gäller för den delade sapmnt-katalogen, som är en delad disk (Windows), en CIFS-resurs (Windows) eller en NFS-resurs (Linux). Du måste använda en teknik som replikerar dessa delade diskar eller resurser mellan zonerna. Dessa tekniker stöds:
  • 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.
  • För att uppnå konsekvens för körningstid för kritiska affärsprocesser kan du försöka dirigera vissa batchjobb och användare till programinstanser som är i zonen med den aktiva DBMS-instansen med hjälp av SAP-batchservergrupper, SAP-inloggningsgrupper eller RFC-grupper. Men om det gäller zonindela redundans måste du manuellt flytta dessa grupper till instanser som körs på virtuella datorer som är i zonen med den aktiva virtuella datorn i db.
  • Du kanske vill distribuera vilande dialoginstanser i var och en av zonerna.

Viktigt

I det här aktiva/aktiva scenariot tillkännagivits ytterligare avgifter för bandbredd av Microsoft från och med 2020-04-01. Läs dokumentet Prisinformation för bandbredd. Dataöverföringen mellan SAP-programlagret och SAP DBMS-lagret är ganska intensiv. Därför kan det aktiva/aktiva scenariot bidra till kostnader ganska mycket. Fortsätt att läsa den här artikeln för att få de exakta kostnaderna

Aktiv/passiv distribution

Om du inte hittar en acceptabel delta mellan nätverksfördröjningen inom en zon och svarstiden för nätverkstrafik mellan zoner kan du distribuera en arkitektur som har ett aktivt/passivt tecken från SAP-programlagrets synpunkt. Du definierar en aktiv zon, som är den zon där du distribuerar det fullständiga programlagret och där du försöker köra både den aktiva DBMS-instansen och SAP Central Services-instansen. Med en sådan konfiguration måste du se till att du inte har extrema körningsvariationer, 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 över olika zoner kan vara att föredra:

  • Australien, östra
  • Brasilien, södra
  • Tyskland, västra centrala
  • Sydafrika, norra
  • Frankrike, centrala
  • Kanada, centrala
  • Japan, östra

Den grundläggande layouten för arkitekturen ser ut så här:

Distribution i aktiv/passiv zon

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 kompensera för det kan du använda Närhetsplaceringsgrupper i Azure enligt dokumentationen i artikeln Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.

  • När du använder den här arkitekturen måste du övervaka statusen noggrant och försöka hålla de aktiva DBMS- och SAP Central Services-instanserna i samma zon som det distribuerade programlagret. Vid en redundans av SAP Central Service eller DBMS-instansen vill du se till att du manuellt kan växla tillbaka till zonen med SAP-programlagret distribuerat så snabbt som möjligt.

  • För lastbalanserarna i redundansklustren för SAP Central Services och DBMS-lagret måste du använda standard-SKU:n Azure Load Balancer. Basic-Load Balancer fungerar inte mellan zoner.

  • 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 Storage, Ultra SSD storageeller ANF stöder inte någon typ av lagringsreplikering mellan zoner. Programmet (DBMS eller SAP Central Services) måste replikera viktiga data.

  • Samma sak gäller för den delade sapmnt-katalogen, som är en delad disk (Windows), en CIFS-resurs (Windows) eller en NFS-resurs (Linux). Du måste använda en teknik som replikerar dessa delade diskar eller resurser mellan zonerna. Dessa tekniker stöds:

    För närvarande stöds inte lösningen som använder Microsoft Scale-Out File Server enligt dokumenten i Förbereda Azure-infrastrukturen för SAP med hög tillgänglighet med hjälp av ett Windows-redundanskluster och filresurs för SAP ASCS/SCS-instanseri flera zoner.

  • 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 en DBMS-vy) så att du kan starta programresurser för händelse av ett zonfel.

    • Azure Site Recovery kan för närvarande inte 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-programlagret i den andra zonen om ett zonindeligt avbrott inträffar.

Kombinerad konfiguration för 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 fortfarande zoner för en kombinerad HA- och DR-konfiguration som utlovar ett mål för återställningspunkt (RPO) på noll. Ett RPO på noll innebär att du inte bör förlora några intrigt databastransaktioner även i händelse av haveriberedskap.

Anteckning

Vi rekommenderar att du endast använder en konfiguration som den här i vissa fall. 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:

Kombinerad dr för hög tillgänglighet i zoner

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

  • Du förutsätter 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 dokumentationen i artikeln Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP-program.

  • När du använder den här arkitekturen måste du övervaka statusen noggrant och försöka hålla de aktiva DBMS- och SAP Central Services-instanserna i samma zon som det distribuerade programlagret. Vid en redundans av SAP Central Service eller DBMS-instansen vill du se till att du manuellt kan växla tillbaka till zonen med SAP-programlagret distribuerat så snabbt som möjligt.

  • Du bör ha förinstallerade instanser av produktionsprogram på de virtuella datorer som kör de aktiva QA-programinstanserna.

  • I ett zonindetalt fel 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 här ska fungera.

  • För lastbalanserarna i redundansklustren för SAP Central Services och DBMS-lagret måste du använda standard-SKU:n Azure Load Balancer. Basic-Load Balancer fungerar inte mellan zoner.

  • 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 Storage och Ultra SSD storage stöder inte någon typ av lagringsreplikering mellan zoner. Programmet (DBMS eller SAP Central Services) måste replikera viktiga data.

  • Samma sak gäller för den delade sapmnt-katalogen, som är en delad disk (Windows), en CIFS-resurs (Windows) eller en NFS-resurs (Linux). Du måste använda en teknik som replikerar dessa delade diskar eller resurser mellan zonerna. Dessa tekniker stöds:

    För närvarande stöds inte lösningen som använder Microsoft Scale-Out File Server enligt dokumenten i Förbereda Azure-infrastrukturen för SAP med hög tillgänglighet med hjälp av ett Windows-redundanskluster och filresurs för SAP ASCS/SCS-instanseri flera zoner.

  • 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 är några nästa steg för att distribuera Azure-tillgänglighetszoner: