Dela via

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

  • Artikel

Den här artikeln bygger på några av de överväganden och rekommendationer som definieras i designområdet för Azure-landningszoner för BCDR. Artikeln kan hjälpa dig att förstå de unika begränsningarna för alla landningszoner som stöder en SAP-plattform. Eftersom SAP är en verksamhetskritisk plattform bör du även läsa den andra vägledningen som presenteras i avsnittet Designområden för Azure-landningszoner i den här dokumentationen och införliva den i din design.

Scenario och omfång

Din arkitektur måste innehålla principer som hanterar lokala affärskontinuitets- och haveriberedskapsscenarier (BCDR). Dessa principer gäller även för Azure. Den största skillnaden är att Azure kan ha mer maskinvarukapacitet än din lokala miljö för att kompensera för ett värdfel. Du kan återställa automatiskt även de största virtuella Azure-datorerna genom att konfigurera dem så att de startas om på en annan server. Konfigurera dina Azure-distributioner så att de använder samma villkor som dina lokala distributioner. Om du har distribuerat lokala system eller maskinvara utan operativsystem med hjälp av konfigurationer för automatiskt redundanskluster distribuerar du dem på samma sätt i Azure. SAP-program som kör en organisations mest kritiska affärsprocesser kräver:

  • Tjänst- och affärsprocesstillgänglighet.
  • Mål för återställningstid (RTO) för fel- eller katastrofscenarier.
  • Mål för återställningspunkter för felscenarier.
  • Drift- och livscykelhanteringsuppgifter och teknik som fylls i under felscenarier. Dessa hanteringsuppgifter omfattar korrigering av gästoperativsystem och databashanteringssystem, kloning och uppdatering av SAP-system.

Tips

Kom överens om en HADR-lösning (hög tillgänglighet och haveriberedskap) för var och en av arketyperna i SAP-landskapet tidigt. Se till att alla SAP-komponenter omfattas av en lämplig lösning.

Konfigurera HADR på Azure tidigt, i minst ett landskap, och fortsätt köra det där. Detta ger dina team möjlighet att skaffa sig erfarenhet av de tekniker som ingår, vilket kan skilja sig från befintliga tekniker. Att konfigurera HADR tidigt kan också hjälpa dig att utveckla och utveckla dina standarddriftsprocedurer (SOP).

Planera att ha fullständig hög tillgänglighet, haveriberedskap och säkerhetskopieringsskydd för produktionsarbetsbelastningar så snart systemet är aktivt.

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

För hög tillgänglighet är fokus att tillhandahålla tillgänglighet för SAP-programvarans enskilda felpunkt, till exempel:

  • Databashanteringssystem.
  • Enskilda felpunkter i programmet, till exempel SAP ABAP och ASCS + SCS. Exempel ä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 infrastruktur- eller programvarufel. Tillämpa tillgänglighet för alla nödvändiga uppgifter för livscykelhantering, till exempel korrigering av operativsystemet på de virtuella datorerna, 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 skyddar dina system mot oplanerade avbrott i tjänsten.

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

Mer information om hur Azure stöder SAP 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 och sekundära virtuella datorerna använder. Azure stöder inte arkitekturer där de primära och sekundära virtuella datorerna delar lagring för DBMS-data. Det Azure Support inte heller transaktions- eller omloggar. Den vägledande principen är att använda två oberoende lagringsstackar, även om de baseras på NFS-resurser (Network File System). Den här metoden är den största begränsningen när du jämför vad som är möjligt lokalt med vad som är möjligt i Azure.

Azure tillhandahåller andra alternativ eftersom det stöder delning av NFS eller Server Message Block. Du kan använda delade Azure-diskar i Windows för ASCS + SCS-komponenter och specifika scenarier med hög tillgänglighet. Konfigurera dina redundanskluster separat för SAP-programlagerkomponenter och DBMS-lagret. Azure stöder för närvarande inte arkitekturer med hög tillgänglighet som kombinerar KOMPONENTER i SAP-programlager och DBMS-lagret till ett redundanskluster.

De flesta redundanskluster för SAP-programlagerkomponenter 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. Det krävs ingen virtuell IP-adress. Azure Load Balancer ska hantera den virtuella IP-adressen för alla andra fall. En designprincip är att använda en lastbalanserare per klusterkonfiguration. Vi rekommenderar att du använder standardversionen av lastbalanseraren. Mer information finns i Offentliga slutpunktsanslutningar för virtuella datorer som använder Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.

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

Nedan visas serviceavtal på plattformsnivå för olika distributionsalternativ med hög tillgänglighet. De partner som tillhandahåller de hanterade tjänsterna tillhandahåller serviceavtalet på programnivå.

Nivå HA-scenario Serviceavtal för plattform
Nivå 1 Tillgänglighetszon 99,99 %
Nivå 2 Tillgänglighetsuppsättning 99,95 %
Nivå 3 Enskild virtuell dator (självåterställning) 99,9 %

Mer information finns i nästa avsnitt.

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

Innan du distribuerar infrastrukturen för hög tillgänglighet och beroende på vilken region du väljer ska du bestämma om du vill distribuera med en Azure-tillgänglighetsuppsättning eller en tillgänglighetszon. De största skillnaderna för virtuella datorer som distribueras 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 värden definieras av den första virtuella datorn som distribueras i uppsättningen. Ett exempel på detta är att du inte kan kombinera virtuella datorer i M-serien och E-serien till en tillgänglighetsuppsättning.

En fördel med att distribuera arkitekturen med hög tillgänglighet mellan olika tillgänglighetszoner är att serviceavtalet (SLA) för de virtuella datorerna kan vara högre. 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 bör du överväga effekterna av svarstider mellan zoner för den valda Azure-regionen, mellan programservern och databasen och mellan de två databasnoderna, på designvalen för prestanda och arkitektur.

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

Om du använder tillgänglighetszoner i din SAP-lösning utformar du även alla andra Azure-tjänster och infrastrukturkomponenter i SAP-landskapet för zonredundans så att du kan uppnå redundans för verklig zon. Exempel på tjänster och komponenter att ta hänsyn till är Azure ExpressRoute-gatewayer, Azure Load Balancer, Azure Files, Azure NetApp Files, omvänd proxy, brandväggar, antivirus- och säkerhetskopieringsinfrastruktur.

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, programserver och databas. Information om serviceavtal för virtuella datorer, tillgänglighetsuppsättningar och tillgänglighetszoner finns i SLA för Virtual Machines.

  • 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 skapas de virtuella datorerna på olika fysiska platser. Den här konfigurationen ger ytterligare skydd mot problem med ström, kylning eller nätverk som påverkar datacenter i zonen som helhet. Du kan dock 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. Varje tillgänglighetszon kommer dock troligen att ha flera programservrar. I det här scenariot drar programservrarna i varje zon inte automatiskt nytta av feldomäner och uppdateringsdomäner. Du kan uppnå dessa fördelar genom att använda tillgänglighetsuppsättningar enligt beskrivningen 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 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. De centrala SAP-tjänsterna, databasen och de virtuella programdatorerna bör finnas i sina egna tillgänglighetsuppsättningar.

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

  • Om du använder närhetsplaceringsgrupper använder du en per SAP SID. Grupper sträcker sig inte över tillgänglighetszoner eller Azure-regioner.

  • När du använder Närhetsplaceringsgrupper i Azure i en distribution av tillgänglighetszoner ska de två SAP-komponenterna (centrala tjänster och programservern) finnas i samma närhetsplaceringsgrupp. De virtuella databasdatorerna i de två zonerna ingår inte längre i närhetsplaceringsgrupperna. Närhetsplaceringsgrupperna per zon är begränsade till distributionen av den virtuella dator som kör SAP ASCS + SCS-instanserna. Fördelen med den här konfigurationen är att du har större flexibilitet när det gäller att ändra storlek på virtuella datorer. Det är också enklare att flytta till nya typer av virtuella datorer i dbms-lagret eller programskiktet i SAP-systemet.

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

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

  • Kör alla produktionssystem på Premium-hanterade SSD och använd Azure NetApp Files eller Ultra Disk Storage. Os-disken bör åtminstone vara på Premium-nivån så att du kan uppnå bättre prestanda och 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. Dessa virtuella datorer ska ha samma storlek och ha 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:

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

Lagring för SAP-arbetsbelastningar

  • Att välja rätt lagringsalternativ är en del av utformningen av återhämtning för din SAP-arbetsbelastning. Designen för SAP-arbetsbelastningar i Azure Storage är avsedd att hålla svarstiden till ett minimum och maximera dataflödet. Överväg din implementering och hur följande vägledning kan hjälpa dig att fatta arkitektoniska beslut för din SAP om Azure-implementering. Information om de olika typerna av lagring och deras kompatibilitet med SAP-arbetsbelastningar och komponenter finns i Azure Storage-typer för SAP-arbetsbelastningar.

  • Du bör endast köra SAP HANA på Azure på de typer av lagring som är certifierade av SAP. Observera att vissa volymer måste köras på vissa diskkonfigurationer, om tillämpligt. Dessa konfigurationer omfattar aktivering av skrivningsaccelerator och användning av Premium-lagring. Du måste också se till att filsystemet som körs på lagring ä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 används olika Azure-inbyggda delade lagringslösningar för att köra SAP-program på Azure. Konfigurationen för hög tillgänglighet kan variera eftersom vissa lagringstjänster som är tillgängliga i Azure inte stöds av Azure Site Recovery. Följande lagringstyper används vanligtvis för SAP-arbetsbelastningar.

    Lagringstyp Konfigurationsstöd för hög tillgänglighet
    Delade Azure-diskar (LRS eller ZRS) Windows Server-redundanskluster. Konfigurationsinformation finns i Designa SAP HA med Windows Server-redundansklustring .
    NFS på Azure Files (LRS eller ZRS) Pacemakerbaserat kluster i Linux-miljöer. Se till att 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-redundanskluster. Konfigurationsinformation finns i Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer i Windows med Azure Files Premium SMB för SAP-program.
    SMB på Azure NetApp Files Windows Server-redundanskluster. Konfigurationsinformation finns i Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer i Windows med Azure NetApp Files (SMB) för SAP-program.

  • I stället för Azure-interna delade lagringstjänster kan du använda traditionella NFS-kluster (baserat på DRBD-replikering), GlusterFS eller klusterdelade volymer 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-interna delade lagringstjänster antingen inte är tillgängliga i den aktuella Azure-regionen eller inte stöder målarkitekturen. Information om tillgänglighet för lagringstjänsten finns i Azure-produkter efter region.

  • Mer information om lagringsalternativ som är tillgängliga för SAP-arbetsbelastningar i Azure finns i lagringsrekommendationerna och riktlinjerna 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 i produktion, ger tekniken andra fördelar. De flesta företag som använder SAP-program måste följa efterlevnadsregler som kräver lagring av säkerhetskopior i många år. Det är också viktigt att ha en säkerhetskopia och kunna återställa från den i andra scenarier. Antagandet är att du redan har upprättat och följer metodtipsen för säkerhetskopiering och återställning 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 operatörsfel som att ta bort data, antingen på DBMS-lagret eller via SAP.

  • Behåll en lagringsplats 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.

När du säkerhetskopierar och återställer lokalt måste du använda dessa funktioner i SAP-system i Azure.

Om du är nöjd med din aktuella lösning kontrollerar du om leverantören av säkerhetskopior 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, Azure Backup, som tar ögonblicksbilder av virtuella datorer och hanterar SQL Server ochSAP HANA-säkerhetskopieringar. 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.

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

  • Du kan använda Azure Backup för att säkerhetskopiera virtuella SAP-programservrar och virtuella datorer med centrala tjänster.

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

  • Om du använder en IaaS-säkerhetskopieringslösning ska du ändra storleken på säkerhetskopieringsinfrastrukturen så att den kan säkerhetskopiera alla system i produktionsstorlek samtidigt eller som i ett verkligt scenario, inom förväntade tidsramar och genom att använda en produktionskonfiguration eller en liknande konfiguration när det gäller nätverk, säkerhet och så vidare.

  • 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. Detta påverkar 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 visar 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 Mv2-serien . Azure Storage parkopplar också olika regioner för att replikera en mindre delmängd av lagringstyperna 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 länkade Azure-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 länkade 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 länkade regioner som du använder. För alla dina andra data kör du replikeringen med hjälp av inbyggda DBMS-funktioner som SQL Server AlwaysOn eller SAP HANA System Replication. Använd en kombination av Site Recovery, rsync eller robocopy, och annan programvara från tredje part för SAP-programlagret.

  • Om en katastrof inträffar vill flera berörda kunder i en Azure-region redundansväxla till motsvarande länkade DR-region. Den här situationen leder till konkurrens om resurser för att få upp vilande virtuella datorer i DR-regionen. Lösningen är att köra icke-produktionssystem i DR-regionen och använda samma resurser som värd för DR-repliker av produktionssystem. Den här dubbla användningen av Azure-infrastrukturer i DR-regionen hjälper dig att undvika resurskapacitetsbegränsningar.

Ett annat viktigt övervägande är att skydda den nödvändiga driftskapaciteten i katastrofregionen. Om en katastrof 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. Detta kräver att du har minimal IT-infrastruktur tillgänglig i DR-regionen.

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/geopolitiskt område och hjälper dig att skydda din anslutning om en katastrof påverkar en av Azure-regionerna.

Vissa organisationer använder en kombination av arkitektur med 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. Eftersom avståndet mellan tillgänglighetszoner inom en Azure-region inte är lika stort som avståndet mellan två Azure-regioner kan en naturkatastrof äventyra programtjänsterna i den region där den inträffar. Du måste också ta hänsyn till svarstiden mellan SAP-programservrar och databasservrar. Enligt SAP Note 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. För zoner med hög fördröjning måste därför operativa procedurer finnas på plats 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 haveriberedskapsmål.
  • Datasuveränitet är en faktor.
  • Geopolitiska faktorer är inblandade.
  • Det är ett billigt alternativ som stöder zonfel, som ibland kombineras med säkerhetskopieringsöverföring till den sekundära regionen för naturkatastrofer som har en stor radie av påverkan.

En annan faktor att tänka på när du väljer din haveriberedskapsregion är återställningspunktmål och återställningspunkt för återställning till haveriberedskapsplatsen. Ju större avstånd mellan produktions- och haveriberedskapsregionerna, desto högre nätverksfördröjning. Även om du replikerar asynkront mellan Azure-regioner kan nätverksfördröjningen påverka det dataflöde som du kan replikera och RPO-målet. Du kan ofta minimera ditt återställningspunktpunktobjekt genom att 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 för storskaliga naturkatastrofer.

Utforma rekommendationer för haveriberedskap

  • Se till att den klasslösa routningen mellan domäner (CIDR) för det primära virtuella nätverket inte ä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-haveriberedskapsregionerna.
  • Som ett alternativ till att använda ExpressRoute kan du överväga att konfigurera VPN-anslutningar från en lokal plats till de primära och sekundära Azure-katastrofåterställningsregionerna.
  • 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 måste till exempel ersätta VIP eller SBD, köra corosync.conf och så vidare.
  • Replikera nyckelvalvsinnehåll som certifikat, hemligheter eller nycklar mellan regioner så att du kan dekryptera data i DR-regionen.
  • Använd replikering mellan regioner i Azure NetApp Files (för närvarande i offentlig förhandsversion) för att synkronisera filvolymer mellan den primära regionen och haveriberedskapsregionen.
  • Använd intern databasreplikering i stället för att Site Recovery för att synkronisera data till haveriberedskapsplatsen.
  • Peerkoppla de primära och virtuella nätverken för haveriberedskap. För HANA-systemreplikering måste till exempel ett virtuellt SAP HANA DB-nätverk peerkopplas 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å programprestanda. Distribuera varje grupp till en separat region i en länkad regionkonstruktion för att minimera påverkan på verksamheten vid ett regionalt avbrott. Två kritiska ECC-system som betjänar två olika affärsenheter kan till exempel distribueras i Storbritannien, södra och Storbritannien, västra för att minimera effekten av ett regionalt avbrott.

Nästa steg

Distributionsalternativ för SAP i Azure