Affärskontinuitet och haveriberedskap för en SAP-migrering

Den här artikeln bygger på överväganden och rekommendationer i designområdet för Azure-landningszoner för BCDR. Den artikeln beskriver unika begränsningar för landningszoner som stöder en SAP-plattform. SAP är en verksamhetskritisk plattform, så du bör även inkludera andra verksamhetskritiska riktlinjer i din design.

Scenario och omfång

Införliva principer i din arkitektur som hanterar lokala scenarier för affärskontinuitet och haveriberedskap (BCDR). Dessa principer gäller även för Azure. Azure kan dock ha mer maskinvarukapacitet än din lokala miljö för att kompensera för ett värdfel. Om du vill återställa även de största virtuella Azure-datorerna automatiskt kan du konfigurera dem att starta om på en annan server. Konfigurera dina Azure-distributioner så att de använder samma villkor som dina lokala distributioner. Om du använder konfigurationer av automatiska redundanskluster för att distribuera lokala system eller maskinvara utan operativsystem distribuerar du dem på samma sätt i Azure. SAP-program som kör organisationens mest kritiska affärsprocesser kräver:

• Tjänst- och affärsprocesstillgänglighet.

• Mål för återställningstid (RTO) för felscenarier eller katastrofscenarier.

• Mål för återställningspunkter för felscenarier.

• Drift- och livscykelhanteringsuppgifter och teknik som körs under felscenarier. Dessa hanteringsuppgifter omfattar korrigering av gästoperativsystem och databashanteringssystem, kloning och uppdatering av SAP-system.

Den här artikeln beskriver följande aspekter av BCDR för ett SAP-scenario i företagsskala:

• Hög tillgänglighet i en Azure-region

• Överväganden för säkerhetskopiering och återställning

• Kriterier för att avgöra mellan regional och regional haveriberedskap

Hög tillgänglighet i en Azure-region

Följande avsnitt innehåller designöverväganden och rekommendationer för hög tillgänglighet i en Azure-region för ett SAP-företagsscenario.

Designöverväganden för hög tillgänglighet

När du implementerar hög tillgänglighet är målet att tillhandahålla tillgänglighet för SAP-programvarans enda felpunkt, till exempel:

• Databashanteringssystem.

• Enskilda felpunkter i ett program, till exempel SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) och SAP Central Services (SCS). Exempel på hög tillgänglighet är SAP NetWeaver och SAP S/4HANA-arkitekturen.

• Andra verktyg, till exempel SAP Web Dispatcher.

I andra scenarier ska du inte begränsa tillgängligheten till infrastrukturfel eller programvarufel. Tillämpa tillgänglighet för alla nödvändiga livscykelhanteringsuppgifter. Du kan till exempel korrigera operativsystemet på de virtuella datorerna, databashanteringssystemet (DBMS) och SAP-programvaran. För att minimera avbrott som kan inträffa under planerade driftstopp och livscykelhanteringsåtgärder använder du vanliga verktyg som hjälper dig att skydda dina system mot oplanerade avbrott i tjänsten.

SAP- och SAP-databaser stöder automatiska redundanskluster. I Windows stöder redundansklusterfunktionen för Windows Server 2022 redundans. I Linux stöder Linux Pacemaker eller partnerverktyg som SIOS Protection Suite och Veritas InfoScale redundansväxling. I Azure kan du bara distribuera en konfiguration med hög tillgänglighet i en delmängd i ditt eget datacenter.

Mer information finns i Scenarier som stöds för SAP-arbetsbelastningar på virtuella Azure-datorer och scenarier som stöds för stora SAP HANA-instanser.

För DBMS-lagret är det vanliga arkitekturmönstret att replikera databaser samtidigt och med andra lagringsstackar än de som de primära virtuella datorerna och de sekundära virtuella datorerna använder. Azure stöder inte arkitekturer där de primära virtuella datorerna och de sekundära virtuella datorerna delar lagring för DBMS-data. Azure stöder inte heller transaktionsloggar eller gör om loggar. Den vägledande principen är att använda två oberoende lagringsstackar, även om de baseras på NFS-resurser (Network File System). Dessa begränsningar är uteslutande för Azure-lösningar och inte lokala lösningar.

Azure tillhandahåller andra alternativ eftersom det stöder delning av NFS- och servermeddelandeblock. Du kan använda delade Azure-diskar i Windows för ASCS- och SCS-komponenter och specifika scenarier med hög tillgänglighet. Konfigurera redundanskluster separat för SAP-programnivåkomponenter och DBMS-lagret. Azure har inte stöd för arkitekturer med hög tillgänglighet som kombinerar SAP-programnivåkomponenter och DBMS-lagret till ett redundanskluster.

De flesta redundanskluster för SAP-programnivåkomponenter och DBMS-lagret kräver en virtuell IP-adress för ett redundanskluster. Ett vanligt undantag är när du använder Oracle Data Guard, som inte kräver någon virtuell IP-adress. Azure Load Balancer ska hantera den virtuella IP-adressen för alla andra fall. Du kan använda en lastbalanserare för varje klusterkonfiguration. Vi rekommenderar att du använder standardversionen av lastbalanseraren. Mer information finns i Offentlig slutpunktsanslutning för virtuella datorer med hjälp av Standard Azure Load Balancer i SAP-scenarier med hög tillgänglighet.

Mer information finns i arkitektur och scenarier med hög tillgänglighet för SAP NetWeaver.

I följande tabell visas serviceavtal på plattformsnivå (SLA) för olika distributionsalternativ med hög tillgänglighet. De partner som tillhandahåller de hanterade tjänsterna tillhandahåller även serviceavtalet på programnivå.

Azure-tillgänglighetsuppsättningar jämfört med tillgänglighetszoner

Innan du distribuerar infrastrukturen för hög tillgänglighet ska du avgöra om du vill distribuera med en Azure-tillgänglighetsuppsättning eller en tillgänglighetszon beroende på vilken region du väljer. De största skillnaderna för virtuella datorer som du distribuerar med en tillgänglighetsuppsättning är:

• De virtuella datorerna är inte spridda över olika tillgänglighetszoner.

• Den typ av virtuella datorer som du kan distribuera via en enda tillgänglighetsuppsättning är begränsad eftersom den första virtuella datorn som du distribuerar i uppsättningen definierar värden. Du kan till exempel inte kombinera virtuella datorer i M-serien och virtuella datorer i E-serien till en tillgänglighetsuppsättning.

När du distribuerar arkitekturen för hög tillgänglighet i olika tillgänglighetszoner kan du ha ett högre serviceavtal för de virtuella datorerna. Mer information finns i Serviceavtal för virtuella Azure-datorer. Beroende på Azure-regionen kan du identifiera olika nätverksfördröjningsvillkor i nätverkstrafiken mellan virtuella datorer. Mer information finns i SAP-arbetsbelastningskonfigurationer med Azure-tillgänglighetszoner.

Om du väljer en zonindelad distributionsmetod kan du överväga hur svarstid mellan zoner för den valda Azure-regionen kan påverka designvalen för prestanda och arkitektur. Överväg svarstiden mellan programservern och databasen och mellan de två databasnoderna.

Om du använder en aktiv/passiv zonindelad distribution för programservernivån där programservrar måste ansluta till databasen i samma tillgänglighetszon, konfigurerar du automatisering och skapar en SOP för att möjliggöra snabb och automatiserad återställning om en databas redundansväxling sker.

Om du använder tillgänglighetszoner i din SAP-lösning kan du utforma alla andra Azure-tjänster och infrastrukturkomponenter i SAP-liggandet för zonredundans så att du kan uppnå redundans i den sanna zonen. Exempel på tjänster och komponenter som ska beaktas är Azure ExpressRoute-gatewayer, Load Balancer, Azure Files, Azure NetApp Files, omvända proxyservrar, brandväggar, antivirustjänster och infrastruktur för säkerhetskopiering.

Designrekommendationer för hög tillgänglighet

• Azure har flera alternativ som hjälper dig att uppfylla programmets serviceavtal för infrastruktur. Du bör välja samma alternativ för alla tre SAP-komponenterna: centrala tjänster, programservern och databasen. Mer information om serviceavtal för virtuella datorer, tillgänglighetsuppsättningar och tillgänglighetszoner finns i Serviceavtal för usluge na mreži.

• När du distribuerar virtuella datorer i en tillgänglighetsuppsättning förhindrar justeringen med fel- och uppdateringsdomäner att de virtuella datorerna finns på samma värdmaskinvara, vilket ger skydd mot maskinvarufel. När du distribuerar virtuella datorer via tillgänglighetszoner och använder olika zoner skapar du de virtuella datorerna på olika fysiska platser. Den här konfigurationen ger extra skydd mot problem med ström, kylning eller nätverk som påverkar zonens datacenter som helhet. Men du kan inte distribuera Azure-tillgänglighetsuppsättningar i en Azure-tillgänglighetszon om du inte använder närhetsplaceringsgrupper.

  Om du väljer en zonindelad distributionsmetod körs SAP DBMS, centrala tjänster och programlager i olika tillgänglighetszoner. Men varje tillgänglighetszon har troligen flera programservrar. I det här scenariot drar programservrarna i varje zon inte automatiskt nytta av feldomäner och uppdateringsdomäner. Du kan använda tillgänglighetsuppsättningar för att få dessa fördelar. Mer information finns i Närhetsplaceringsgrupper i Azure för optimal nätverksfördröjning med SAP.

• När du skapar tillgänglighetsuppsättningar använder du det maximala antalet feldomäner och uppdateringsdomäner som är tillgängliga. Om du till exempel distribuerar fler än två virtuella datorer i en tillgänglighetsuppsättning använder du det maximala antalet feldomäner (tre). Och använd tillräckligt många uppdateringsdomäner för att begränsa effekten av potentiella fysiska maskinvarufel, nätverksavbrott eller strömavbrott utöver planerat underhåll i Azure. Standardantalet feldomäner är två och du kan inte ändra det online senare.

• I en distribution av tillgänglighetsuppsättningar måste varje komponent i ett SAP-system finnas i en egen tillgänglighetsuppsättning. SAP:s centrala tjänster, databasen och de virtuella programdatorerna bör finnas i sina egna tillgänglighetsuppsättningar.

• När du använder Azure närhetsplaceringsgrupper i en distribution av tillgänglighetsuppsättningar kontrollerar du att alla tre SAP-komponenterna (centrala tjänster, programservern och databasen) finns i samma närhetsplaceringsgrupp.

• Om du använder närhetsplaceringsgrupper använder du en för varje SAP System Identification (SID). Grupper sträcker sig inte över tillgänglighetszoner eller Azure-regioner.

• När du använder Azure närhetsplaceringsgrupper i en distribution av tillgänglighetszoner kontrollerar du att de två SAP-komponenterna (centrala tjänster och programservern) finns i samma närhetsplaceringsgrupp. De virtuella databasdatorerna i de två zonerna är inte längre en del av närhetsplaceringsgrupperna. Närhetsplaceringsgrupperna för varje zon är begränsade med distributionen av den virtuella datorn som kör SAP ASCS- och SCS-instanserna. Fördelen med den här konfigurationen är att du har större flexibilitet för att ändra storlek på virtuella datorer. Du kan också enkelt växla till nya typer av virtuella datorer i antingen DBMS-lagret eller programskiktet i SAP-systemet.

• Azure har inte stöd för att kombinera hög tillgänglighet för ASCS och databaser i ett enda Linux Pacemaker-kluster. Dela upp dem i enskilda kluster. Du kan kombinera så många som fem kluster för centrala tjänster i ett par virtuella datorer.

• Använd Standard Load Balancer framför ASCS- och databaskluster.

• Kör alla produktionssystem på Azure Premium SSD och använd Azure NetApp Files eller Azure Ultra Disk Storage. Kontrollera minst att OS-disken är på Premium-nivån så att du kan förbättra prestanda och få det bästa serviceavtalet.

• Distribuera båda de virtuella datorerna i paret med hög tillgänglighet i en tillgänglighetsuppsättning eller i tillgänglighetszoner. Kontrollera att dessa virtuella datorer har samma storlek och har samma lagringskonfiguration.

• Använd intern databasreplikeringsteknik för att synkronisera databasen i ett par med hög tillgänglighet.

• Använd någon av följande tjänster för att köra SAP-kluster för centrala tjänster, beroende på operativsystemet:

  • Ett SUSE Linux Enterprise Server Pacemaker-kluster stöder en Azure-stängselagent och så många som tre nodisoleringsenheter.

  • Ett Red Hat Enterprise Linux Pacemaker-kluster stöder en Azure-stängselagent och stöder inte nodisoleringsenheter.

  • Ett Windows-kluster.

  • SAP-certifierad icke-Microsoft-klusterprogramvara.

• Konfigurera parametrarna för klustertimeout enligt rekommendationerna i dokumentationen för centrala tjänster och databaskluster.

Lagring för SAP-arbetsbelastningar

• Välj rätt lagringsalternativ när du utformar för återhämtning i DIN SAP-arbetsbelastning. Korrekt Azure Storage-design för SAP-arbetsbelastningar kan minimera svarstiden och maximera dataflödet. Överväg implementeringen och hur följande vägledning kan hjälpa dig att fatta arkitektoniska beslut för din SAP om Azure-implementering. Mer information finns i Azure-lagringstyper för SAP-arbetsbelastningar.

• Du bör endast köra SAP HANA på Azure på SAP-certifierade lagringstyper. Du måste köra vissa volymer på vissa diskkonfigurationer. Konfigurationer kan till exempel aktivera skrivaccelerator eller använda Premium SSD-lagring. Du måste också se till att filsystemet som körs på lagringen är kompatibelt med DBMS som körs på datorn. Mer information finns i Lagringskonfigurationer för SAP HANA.

• Förutom Azure-hanterade datadiskar som är anslutna till virtuella datorer kör olika Azure-inbyggda delade lagringslösningar SAP-program på Azure. Konfigurationen för hög tillgänglighet kan skilja sig eftersom Azure Site Recovery inte stöder vissa lagringstjänster som är tillgängliga i Azure. Använd följande lagringstyper för SAP-arbetsbelastningar.

  Lagringstyp	Konfigurationsstöd för hög tillgänglighet
  Delade Azure-diskar (lokalt redundant lagring (LRS) eller zonredundant lagring (ZRS))	Windows Server 2022-redundanskluster. Konfigurationsinformation finns i Designa SAP-hög tillgänglighet med Windows Server 2022-redundanskluster.
  NFS på Azure Files (LRS eller ZRS)	Pacemakerbaserat kluster i Linux-miljöer. Kontrollera tillgängligheten för NFS i olika regioner.
  NFS på Azure NetApp Files	Pacemakerbaserat kluster i Linux-miljöer. Mer information finns i Azure NetApp Files för virtuella SAP-datorer.
  SMB på Azure Files (LRS eller ZRS)	Windows Server 2022-redundanskluster. Konfigurationsinformation finns i Installera SAP NetWeaver med hög tillgänglighet med Azure Files SMB.
  SMB på Azure NetApp Files	Windows Server 2022-redundanskluster. Konfigurationsinformation finns i Hög tillgänglighet för SAP NetWeaver med Azure NetApp Files (SMB) för SAP-program.

• I stället för Azure-inbyggda delade lagringstjänster kan du använda traditionella NFS-kluster (baserat på replikering av distribuerade replikerade blockenheter), GlusterFS eller en klusterdelad volym med Lagringsdirigering som en alternativ lösning för delad lagring för att köra SAP-arbetsbelastningar på Azure. De här alternativen är särskilt användbara när Azure-inbyggda delade lagringstjänster antingen inte är tillgängliga i den riktade Azure-regionen eller inte stöder målarkitekturen. Mer information om tillgänglighet för lagringstjänsten finns i Azure-produkter per region.

• Information om lagringsalternativ som är tillgängliga för SAP-arbetsbelastningar i Azure finns i rekommendationer och riktlinjer för lagring för att konfigurera haveriberedskap.

Säkerhetskopiering och återställning

I följande avsnitt beskrivs designöverväganden och rekommendationer för säkerhetskopiering och återställning i ett SAP-scenario.

Även om säkerhetskopiering och återställning vanligtvis inte anses vara en lämplig lösning med hög tillgänglighet för en SAP-arbetsbelastning för produktion, ger tekniken andra fördelar. De flesta företag som använder SAP-program måste följa efterlevnadsregler som kräver långsiktig lagring av säkerhetskopior. I andra scenarier måste du också ha en säkerhetskopia som du kan återställa från. Den här vägledningen förutsätter att du redan har upprättat säkerhetskopiering och återställning och följer metodtipsen för SAP-program, vilket innebär att du kan:

• Utför en återställning till tidpunkt för dina produktionsdatabaser när som helst, inom en tidsram som uppfyller din RTO. Återställning till tidpunkt ger vanligtvis skydd mot operatorfel som att ta bort data, antingen på DBMS-lagret eller via SAP.

• Underhålla ett lager för att behålla dina långsiktiga säkerhetskopior för att uppfylla efterlevnadsreglerna.

• Använd databassäkerhetskopior för att klona SAP-systemet och återställa säkerhetskopiorna mot en annan server eller virtuell dator.

• Använd produktionsdatabasdata från databassäkerhetskopior för att uppdatera icke-produktionssystem.

• Säkerhetskopiera SAP-programservrar och virtuella datorer, diskar eller vm-ögonblicksbilder.

• Säkerhetskopiera ett SAP HANA-system med replikering aktiverat.

• Säkerhetskopiera ögonblicksbilder av SAP HANA-databasinstanser.

Om du säkerhetskopierar och återställer lokalt måste du ta med de här funktionerna till SAP-system i Azure. Om du gillar din aktuella lösning kontrollerar du om din leverantör för säkerhetskopiering stöder Azure-distributioner eller om den har en SaaS-lösning (programvara som en tjänst) för Azure.

Azure tillhandahåller en SaaS-säkerhetskopieringstjänst med namnet Azure Backup, som tar ögonblicksbilder av virtuella datorer och hanterar strömmande SQL Server- och SAP HANA-säkerhetskopior. Om du använder Azure NetApp Files för att lagra dina SAP HANA-databaser kan du köra säkerhetskopior baserat på HANA-konsekventa lagringsögonblicksbilder.

Du kan också använda Azure Backup för att säkerhetskopiera databaser som har SAP HANA-systemreplikering (HSR) aktiverat. Azure Backup hanterar automatiskt säkerhetskopieringar när en redundansväxling inträffar och eliminerar behovet av manuella åtgärder. Säkerhetskopiering ger också:

• Omedelbart skydd utan fullständiga säkerhetskopior, så att du kan skydda HANA-instanser eller HSR-installationsnoder som en enda HSR-container.

• Fördelen med omedelbar säkerhetskopiering och omedelbar återställning.

• En HANA-konsekvent, ögonblicksbildsbaserad metod som integreras med Backint för SAP HANA. Du kan använda Backup som en enda produkt för hela HANA-landskapet och för valfri databasstorlek.

Mer information finns i SAP HANA-databassystem med replikering aktiverat och säkerhetskopiering av ögonblicksbilder för SAP HANA-instanser.

Utforma rekommendationer för säkerhetskopiering och återställning

• Du kan använda Azure Backup för att säkerhetskopiera de virtuella datorerna för SAP-programservern och de centrala tjänsterna.

• Du kan använda en SAP HANA-säkerhetskopiering för HANA-distributioner som är upp till 8 TB. Mer information finns i Supportmatris för säkerhetskopiering av SAP HANA-databaser på virtuella Azure-datorer.

• Om du använder en infrastruktur som en tjänstsäkerhetskopieringslösning, storleksanpassar du säkerhetskopieringsinfrastrukturen så att den kan säkerhetskopiera alla system i produktionsstorlek samtidigt eller, som i ett verkligt scenario, inom förväntade tidsramar. Använd en produktionskonfiguration eller en liknande konfiguration för områden som nätverk och säkerhet.

• Testa säkerhetskopierings- och återställningstiderna för att kontrollera att de uppfyller dina RTO-krav för att återställa alla system samtidigt efter en katastrof.

• Undvik att hämta dina säkerhetskopior från Azure till din lokala infrastruktur för säkerhetskopiering, särskilt för stora databaser. Den här metoden kan påverka hur mycket bandbredd ExpressRoute-kretsarna använder.

• Belastningstesta säkerhetskopierings- och återställningsverktygen som en del av prestandatestplanen.

Haveriberedskap

I följande avsnitt beskrivs designöverväganden och rekommendationer för haveriberedskap i ett SAP-scenario.

Designöverväganden för haveriberedskap

Azure-regionkartan innehåller fler än 65 Azure-regioner och alla kör inte samma tjänster. För större SAP-programvarudistributioner, särskilt de som använder SAP HANA, letar du efter Azure-regioner som erbjuder virtuella Datorer i Azure M-serien eller virtuella datorer i Mv2-serien. Azure Storage parkopplar också olika regioner för att replikera en mindre delmängd av lagringstyper till en annan region. Mer information finns i Översikt över länkade Azure-regioner.

De största utmaningarna med att koppla ihop Azure-regioner för SAP-arbetsbelastningar är:

• Paren är inte alltid konsekventa med vm-tjänster i M-serien eller Mv2-serien. Många organisationer som distribuerar sina SAP-system använder inte azure-kopplade regioner. I stället väljer de regioner baserat på tillgängligheten för nödvändiga typer av virtuella datorer.

• Du kan replikera standardlagring mellan parkopplade regioner, men du kan inte använda standardlagring för att lagra dina databaser eller virtuella hårddiskar. Du kan bara replikera säkerhetskopior mellan parkopplade regioner som du använder. Kör replikeringen för alla andra data med hjälp av inbyggda DBMS-funktioner som SQL Server AlwaysOn eller SAP HANA-systemreplikering. Använd en kombination av Site Recovery, verktyg som eller robocopyoch annan programvara som rsync inte kommer från Microsoft för SAP-programskiktet.

• Om en katastrof inträffar redundansväxlar flera berörda kunder i en Azure-region till motsvarande kopplade haveriberedskapsregion. Den här situationen leder till konkurrens om resurser för att ta upp vilande virtuella datorer i haveriberedskapsregionen. Lösningen är att köra icke-produktionssystem i haveriberedskapsregionen och använda samma resurser som värdar för haveriberedskapsrepliker av produktionssystem. Den här dubbla användningen av Azure-infrastrukturer i haveriberedskapsregionen hjälper dig att undvika resurskapacitetsbegränsningar.

En annan viktig faktor är att skydda den nödvändiga driftkapaciteten i katastrofregionen. Om ett haveri inträffar kan du behöva köra SAP-programmet under en minimal tidsperiod med minimal IT-kapacitet och endast kritiska personalresurser medan du arbetar för att återställa normal drift i den primära regionen. Den här strategin kräver att du har minimal IT-infrastruktur tillgänglig i haveriberedskapsregionen.

När du har definierat dina Azure-regioner måste du välja ett distributionsmönster:

• Kommer du att distribuera produktionssystem till din primära region?

• Kommer du att distribuera SAP-system som inte är produktionsprodukter till haveriberedskapsregionen?

• Kommer du att använda en arkitektur som grupperar alla SAP-system i den primära regionen? Den här konfigurationen säkerställer att haveriberedskapsregionen endast används för haveriberedskap.

De flesta organisationer använder båda regionerna för att hantera SAP-system. Organisationer som kör fullständiga kopior av produktionssystem som testsystem för affärsregression planerar vanligtvis att använda SAP-produktlinjens testsystem för affärsregression som haveriberedskapsmål.

När du väljer en haveriberedskapsregion måste du ha ExpressRoute-anslutning till den regionen. Om du har flera ExpressRoute-kretsar som ansluter till Azure måste minst en av dessa kretsar ansluta till den primära Azure-regionen. De andra bör ansluta till haveriberedskapsregionen. Den här typen av arkitektur ansluter dig till Azure-nätverket i ett annat geografiskt eller geopolitiskt område och hjälper dig att skydda anslutningen om en katastrof påverkar någon av Azure-regionerna.

Vissa organisationer använder en kombination av arkitektur för hög tillgänglighet och haveriberedskap, som grupperar hög tillgänglighet med haveriberedskap i samma Azure-region. Men att gruppera hög tillgänglighet med haveriberedskap är inte idealiskt. Azure-tillgänglighetszoner stöder den här arkitekturen. Avståndet mellan tillgänglighetszoner i en Azure-region är inte lika stort som avståndet mellan två Azure-regioner, så en naturkatastrof kan äventyra programtjänsterna i den region där den inträffar. Du måste också överväga svarstiden mellan SAP-programservrar och databasservrar. Enligt SAP-1100926 är en tur- och returtid på mindre än eller lika med 0,3 ms ett bra värde, och en tid på mindre än eller lika med 0,7 ms är ett måttligt värde. Så för zoner med höga svarstider, har operativa procedurer för att säkerställa att SAP-programservrar och databasservrar alltid körs i samma zon. Organisationer väljer den här arkitekturen av följande skäl:

• Efterlevnaden är tillräcklig med konfigurationer som stöder mindre avstånd mellan produktionsdistribution och ett mål för haveriberedskap.

• Datasuveränitet är en faktor.

• Geopolitiska faktorer är inblandade.

• Det är ett lågkostnadsalternativ som stöder zonfel, ibland kombinerat med säkerhetskopieringsöverföring till den sekundära regionen för naturkatastrofer som påverkar en stor radie.

En annan faktor att tänka på när du väljer din haveriberedskapsregion är RPO och RTO för växling till haveriberedskapsplatsen. Ju större avstånd mellan produktionsregionen och haveriberedskapsregionerna, desto högre nätverksfördröjning. Du replikerar asynkront mellan Azure-regioner, men nätverksfördröjning kan påverka det dataflöde som du kan replikera och RPO-målet. För att minimera ditt RPO kan du använda en kombinerad arkitektur för hög tillgänglighet och haveriberedskap. Men den här konfigurationen utgör en potentiellt högre risk vid storskaliga naturkatastrofer.

Designrekommendationer för haveriberedskap

• Kontrollera att den klasslösa routningen mellan domäner (CIDR) för det primära virtuella nätverket inte står i konflikt med eller överlappar CIDR för haveriberedskapsplatsens virtuella nätverk.

• Konfigurera ExpressRoute-anslutningar från en lokal plats till de primära och sekundära Azure-katastrofåterställningsregionerna.

• Överväg att konfigurera VPN-anslutningar från en lokal plats till de primära och sekundära Azure-katastrofåterställningsregionerna. Använd den här metoden som ett alternativ till att använda ExpressRoute.

• Använd Site Recovery för att replikera en programserver till en haveriberedskapsplats. Site Recovery kan också hjälpa dig att replikera virtuella datorer med centrala tjänstkluster till haveriberedskapsplatsen. När du anropar haveriberedskap måste du konfigurera om Linux Pacemaker-klustret på haveriberedskapsplatsen. Du kan till exempel behöva ersätta den virtuella IP-adressen eller SBD eller köra corosync.conf.

• Replikera nyckelvalvsinnehåll som certifikat, hemligheter eller nycklar mellan regioner så att du kan dekryptera data i haveriberedskapsregionen.

• Använd replikering mellan regioner i Azure NetApp Files för att synkronisera filvolymer mellan den primära regionen och haveriberedskapsregionen.

• Använd intern databasreplikering i stället för Site Recovery för att synkronisera data till haveriberedskapsplatsen.

• Peer-koppla de primära och haveriberedskaps-virtuella nätverken. För HANA-systemreplikering behöver du till exempel peer-koppla ett virtuellt SAP HANA DB-nätverk till haveriberedskapsplatsens virtuella SAP HANA DB-nätverk.

• Om du använder Azure NetApp Files-lagring för dina SAP-distributioner skapar du minst två Azure NetApp Files-konton på Premium-nivån i två regioner.

• Överväg att gruppera system baserat på deras affärsvikt och närhetsberoende baserat på programmets prestanda. För att minimera affärseffekten av ett regionalt avbrott distribuerar du varje grupp till en separat region i en länkad regionkonstruktion. För att minimera effekten av ett regionalt avbrott kan du till exempel distribuera två kritiska ERP Central Component-system som betjänar två olika affärsenheter, i Storbritannien, södra och Storbritannien, västra.

Gå vidare

Distributionsalternativ för SAP i Azure