Översikt över haveriberedskap och riktlinjer för infrastruktur för SAP-arbetsbelastning

  • Artikel

Många organisationer som kör kritiska affärsprogram i Azure konfigurerar både strategi för hög tillgänglighet (HA) och Haveriberedskap (DR). Syftet med hög tillgänglighet är att öka serviceavtalet för affärssystem genom att eliminera enskilda felpunkter i den underliggande systeminfrastrukturen. Tekniker med hög tillgänglighet minskar effekten av oplanerade infrastrukturfel och hjälper till med planerat underhåll. Haveriberedskap definieras som principer, verktyg och procedurer för att möjliggöra återställning eller fortsättning av viktig teknikinfrastruktur och system efter en geografiskt utbredd naturkatastrof eller katastrof som orsakas av människor.

För att uppnå hög tillgänglighet för SAP-arbetsbelastningar i Azure distribueras virtuella datorer vanligtvis i en tillgänglighetsuppsättning, tillgänglighetszoner eller i flexibel skalningsuppsättning för att skydda program från infrastrukturunderhåll eller fel inom regionen. Distributionen skyddar dock inte program från omfattande katastrofer inom regionen. Så för att skydda program från regionala katastrofer bör haveriberedskapsstrategin för programmen finnas på plats. Haveriberedskap är en dokumenterad och strukturerad metod som är utformad för att hjälpa en organisation att utföra återställningsprocesser som svar på en katastrof, samt för att skydda eller minimera avbrott i IT-tjänster och främja återställning.

Det här dokumentet innehåller information om hur du skyddar SAP-arbetsbelastningar från storskaliga katastrofer genom att implementera strukturerad DR-metod. Informationen i det här dokumentet presenteras på abstrakt nivå, baserat på olika Azure-tjänster och SAP-komponenter. Exakt DR-strategi och återställningsordningen för DIN SAP-arbetsbelastning måste testas, dokumenteras och finjusteras regelbundet. Dokumentet fokuserar också på Azure-till-Azure DR-strategin för SAP-arbetsbelastning.

Allmänna överväganden för haveriberedskapsplan

SAP-arbetsbelastningen i Azure körs på virtuella datorer i kombination med olika Azure-tjänster för att distribuera olika lager (centrala tjänster, programservrar, databasserver) i ett typiskt SAP NetWeaver-program. I allmänhet bör en DR-strategi planeras för hela IT-landskapet som körs i Azure, vilket innebär att även ta hänsyn till icke-SAP-program. Affärslösningen som körs i SAP-system kanske inte körs som helhet, om de beroende tjänsterna eller tillgångarna inte återställs på DR-platsen. Så du måste komma med en väldefinierad omfattande DR-plan med tanke på alla komponenter och system.

För dr på Azure bör organisationer överväga olika scenarier som kan utlösa redundans.

  • TILLGÄNGLIGHET för SAP-program eller affärsprocesser.
  • Azure-tjänster (till exempel virtuella datorer, lagring, lastbalanserare osv.) är otillgängliga i en region på grund av omfattande fel.
  • Potentiella hot och sårbarheter för programmet (till exempel DDoS-attack på programnivå)
  • Affärsefterlevnad krävde operativa uppgifter för att testa DR-strategin (till exempel dr-felövning som ska utföras varje år enligt efterlevnad).

För att uppnå återställningsmålet för olika scenarier måste organisationen beskriva mål för återställningstid (RTO) och mål för återställningspunkt (RPO) för sin arbetsbelastning baserat på affärskraven. RTO beskriver hur lång tid programmet kan vara nere, vanligtvis mätt i timmar, minuter eller sekunder. RPO beskriver mängden transaktionsdata som är acceptabel för företag att förlora för att normala åtgärder ska återupptas. Att identifiera RTO och RPO för din verksamhet är avgörande, eftersom det skulle hjälpa dig att utforma din DR-strategi optimalt. Komponenterna (beräkning, lagring, databas osv.) som ingår i SAP-arbetsbelastningen replikeras till DR-regionen med hjälp av olika tekniker (inbyggda Azure-tjänster, intern DB-replikeringsteknik, anpassade skript). Varje teknik ger olika RPO, som måste tas med i beräkningen när du utformar en DR-strategi. I Azure kan du använda några av de inbyggda Azure-tjänsterna som Azure Site Recovery, Azure Backup som kan hjälpa dig att uppfylla RTO och RPO för dina SAP-arbetsbelastningar. Se serviceavtalet för Azure Site Recovery och Azure Backup för optimal anpassning till din RTO och RPO.

Designövervägande för haveriberedskap i Azure

Det finns olika element att tänka på när du utformar en haveriberedskapslösning i Azure. De principer och begrepp som anses utforma lokala lösningar för haveriberedskap gäller även för Azure. Men i Azure är regionval en viktig del i designstrategin för haveriberedskap. Tänk därför på följande när du väljer DR-region i Azure.

  • Krav på affärs- eller regelefterlevnad kan ange ett avståndskrav mellan en primär plats och en haveriberedskapsplats. Ett avståndskrav hjälper till att tillhandahålla tillgänglighet om en naturkatastrof inträffar i ett större geografiskt område. I sådana fall kan en organisation välja en annan Azure-region som haveriberedskapsplats. Azure-regioner avgränsas ofta med ett stort avstånd som kan vara hundratals eller till och med tusentals kilometer som i USA. På grund av avståndet kan svarstiden för nätverkets tur och retur vara högre, vilket kan leda till högre RPO.

  • Kunder som vill efterlikna sin lokala dr-strategi för metro i Azure kan använda tillgänglighetszoner för haveriberedskap. Men dr-strategin från zon till zon kan misslyckas med motståndskraftskravet om det finns en geografiskt utbredd naturkatastrof.

  • I Azure paras varje region ihop med en annan region inom samma geografi (förutom Brasilien, södra). Den här metoden möjliggör plattformsbaserad replikering av resurser i hela regionen. Fördelen med att välja länkad region finns i dokumentet regionpar. Om en organisation väljer att använda Azure-kopplade regioner måste flera ytterligare punkter för en SAP-arbetsbelastning beaktas:

    • Alla Azure-tjänster erbjuder inte gränsöverskridande replikering i en parad region.

    • Azure-tjänsterna och funktionerna i kopplade Azure-regioner kanske inte är symmetriska. Azure NetApp Files, VM-SKU:er som M-Series som är tillgängliga i den primära regionen kanske inte är tillgängliga i den kopplade regionen. Information om hur du kontrollerar om Azure-produkten eller tjänsterna är tillgängliga i en region finns i Azure-produkter efter region.

    • GRS-alternativet är tillgängligt för lagringskonto med standardlagringstyp som replikerar data till en länkad region. Standardlagring är dock inte lämpligt för SAP DBMS eller virtuella datadiskar.

    • Azure Backup-tjänsten som används för att säkerhetskopiera lösningar som stöds kan endast replikera säkerhetskopior mellan parkopplade regioner. Kör dina egna replikeringar med inbyggda DBMS-funktioner som SQL Server Always On, SAP HANA System Replication och andra tjänster för alla dina andra data. Använd en kombination av Azure Site Recovery, rsync eller robocopy och annan programvara från tredje part för SAP-programlagret.

Referensdistribution av SAP-arbetsbelastning

När du har identifierat en DR-region är det viktigt att den bredd av Azure-kärntjänster (som nätverk, beräkning, lagring) som konfigurerats i den primära regionen är tillgänglig och kan konfigureras i DR-regionen. Organisationen måste utveckla ett dr-distributionsmönster för SAP-arbetsbelastningen. Distributionsmönstret varierar och måste överensstämma med organisationens behov.

  • Distribuera SAP-arbetsbelastningen för produktion till din primära region och icke-produktionsarbetsbelastning i haveriberedskapsregionen.
  • Distribuera alla SAP-arbetsbelastningar (produktion och icke-produktion) till din primära region. Haveriberedskapsregionen används endast om det finns en redundansväxling.

Följande referensarkitektur visar typiska SAP NetWeaver-system som körs på Azure tillsammans med hög tillgänglighet i den primära regionen. Den sekundära platsen som visas nedan är platsen för haveriberedskap där SAP-systemen återställs efter en katastrofhändelse. Både primära regioner och haveriberedskapsregioner ingår i samma prenumeration. För att uppnå DR för SAP-arbetsbelastning måste du identifiera återställningsstrategin för varje SAP-lager tillsammans med de olika Azure-tjänster som programmet använder.

Organisationer bör planera och utforma en DR-strategi för hela IT-landskapet. Vanligtvis är SAP-system som körs i produktionsmiljön integrerade med olika tjänster och gränssnitt som Active Directory, DNS, program från tredje part och så vidare. Därför måste du även inkludera icke-SAP-system och andra tjänster i planeringen för haveriberedskap. Det här dokumentet fokuserar på återställningsplaneringen för SAP-program. Men du kan utöka storleken och omfattningen för dr-planeringen för beroende komponenter så att de passar dina krav.

Referensarkitektur för haveriberedskap för SAP-arbetsbelastning

Infrastrukturkomponenter i DR-lösning för SAP-arbetsbelastning

En SAP-arbetsbelastning som körs i Azure använder olika infrastrukturkomponenter för att köra en affärslösning. För att planera dr för en sådan lösning är det viktigt att alla infrastrukturkomponenter som konfigurerats i den primära regionen är tillgängliga och kan konfigureras även i DR-regionen. Följande infrastrukturkomponenter bör beaktas när du utformar EN DR-lösning för SAP-arbetsbelastning i Azure.

  • Nätverk
  • Compute
  • Storage

Nätverk

  • ExpressRoute utökar ditt lokala nätverk till Microsoft-molnet via en privat anslutning med hjälp av en anslutningsleverantör. När du utformar haveriberedskapsarkitektur måste man ta hänsyn till att skapa en robust nätverksanslutning för serverdelen med hjälp av geo-redundant ExpressRoute-krets. Vi rekommenderar att du konfigurerar minst en ExpressRoute-krets från lokal till den primära regionen, och den andra bör ansluta till haveriberedskapsregionen. Se artikeln Designing of Azure ExpressRoute for disaster recovery (Utforma Azure ExpressRoute för haveriberedskap), som beskriver olika scenarier för att utforma haveriberedskap för ExpressRoute.

    Kommentar

    Överväg att konfigurera ett plats-till-plats-VPN (S2S) som en säkerhetskopia av Azure ExpressRoute. Mer information finns i Använda S2S VPN som en säkerhetskopia för privat Azure ExpressRoute-peering.

  • Virtuella nätverk och undernät omfattar alla tillgänglighetszoner i en region. För haveriberedskap i två regioner måste du konfigurera separata virtuella nätverk och undernät i haveriberedskapsregionen. Mer information om nätverkskonfigurationen i DR-regionen finns i Om nätverk i haveriberedskap för virtuella Azure-datorer.

  • Azure Standard Load Balancer tillhandahåller nätverkselement för design med hög tillgänglighet för dina SAP-system. För klustrade system tillhandahåller Standard Load Balancer den virtuella IP-adressen för klustertjänsten, till exempel ASCS/SCS-instanser och databaser som körs på virtuella datorer. Om du vill köra SAP-system med hög tillgänglighet på DR-platsen måste en separat lastbalanserare skapas och klusterkonfigurationen justeras i enlighet med detta.

  • Azure Application Gateway är en lastbalanserare för webbtrafik. Med sin webbaserade brandväggsfunktion är den väl lämpad för att exponera webbprogram för Internet med förbättrad säkerhet. Azure Application Gateway kan betjäna antingen offentliga (Internet) eller privata klienter, eller båda, beroende på konfigurationen. Om du vill acceptera liknande inkommande HTTPs-trafik i DR-regionen efter redundansväxlingen måste en separat Azure Application Gateway konfigureras i DR-regionen.

  • Eftersom nätverkskomponenter (till exempel virtuellt nätverk, brandvägg osv.) skapas separat i DR-regionen måste du se till att SAP-arbetsbelastningen i DR-regionen är anpassad till nätverksändringar som DNS-uppdatering, brandvägg osv.

  • Virtuella nätverk i båda regionerna är oberoende och för att upprätta kommunikation mellan de två måste du aktivera peering för virtuella nätverk mellan de två regionerna.

Virtuella datorer

  • I Azure körs olika komponenter i ett enda SAP-system på virtuella datorer med olika SKU-typer. För dr kan skydd av ett program (SAP NetWeaver och icke-SAP) som körs på virtuella Azure-datorer aktiveras genom att replikera komponenter med hjälp av Azure Site Recovery till en annan Azure-region eller -zon. Med Azure Site Recovery replikeras virtuella Azure-datorer kontinuerligt från den primära platsen till haveriberedskapsplatsen. Beroende på den valda Azure DR-regionen kanske den virtuella datorns SKU-typ inte är tillgänglig på DR-platsen. Du måste se till att de nödvändiga VM SKU-typerna även är tillgängliga i Azure DRregion. Kontrollera Azure-produkter efter region för att se om den nödvändiga SKU-typen för VM-familjen är tillgänglig eller inte.

    Viktigt!

    Om SAP-systemet har konfigurerats med flexibel skalningsuppsättning med FD=1 måste du använda PowerShell för att konfigurera Azure Site Recovery för haveriberedskap. För närvarande är det den enda tillgängliga metoden för att konfigurera haveriberedskap för virtuella datorer som distribuerats i skalningsuppsättningen.

  • För databaser som körs på virtuella Azure-datorer rekommenderar vi att du använder intern databasreplikeringsteknik för att synkronisera data till haveriberedskapsplatsen. De stora virtuella datorer som databaserna körs på kanske inte är tillgängliga i alla regioner. Om du använder tillgänglighetszoner för haveriberedskap bör du kontrollera att respektive VM-SKU:er är tillgängliga i zonen för haveriberedskapsplatsen.

    Kommentar

    Det rekommenderas inte att använda Azure Site Recovery för databaser eftersom det inte garanterar DB-konsekvens och har dataomsättningsbegränsningar.

  • Med produktionsprogram som körs i den primära regionen hela tiden används reservinstanser vanligtvis för att spara Azure-kostnader. Om du använder reserverade instanser måste du registrera dig för ett eller tre års åtagande som kanske inte är kostnadseffektivt för DR-webbplatsen. Att konfigurera Azure Site Recovery garanterar inte heller kapaciteten för den virtuella dator-SKU som krävs under redundansväxlingen. För att se till att den virtuella datorns SKU-kapacitet är tillgänglig kan du överväga ett alternativ för att aktivera kapacitetsreservation på begäran. Den reserverar beräkningskapacitet i en Azure-region eller en Azure-tillgänglighetszon under en tidsperiod utan åtagande. Azure Site Recovery är integrerat med kapacitetsreservation på begäran. Med den här integreringen kan du använda kapacitetsreservationen med Azure Site Recovery för att reservera beräkningskapacitet på DR-platsen och garantera dina redundansväxlingar. Mer information finns i begränsningar och begränsningar för kapacitetsreservation på begäran.

  • En Azure-prenumeration har kvoter för VM-familjer (till exempel Mv2-familj) och andra resurser. Ibland vill organisationer använda olika Azure-prenumerationer för DR. Varje prenumeration (primär och DR) kan ha olika kvoter tilldelade för varje VM-familj. Kontrollera att prenumerationen som används för DR-platsen har tillräckligt med beräkningskvoter tillgängliga.

Storage

  • När du aktiverar Azure Site Recovery för en virtuell dator för att konfigurera dr replikeras de lokala hanterade diskarna som är anslutna till de virtuella datorerna till DR-regionen. Under replikeringen skickas de virtuella datordiskskrivningarna till ett cachelagringskonto i källregionen. Data skickas därifrån till målregionen och återställningspunkter genereras från data. När du redundansväxlar en virtuell dator under dr används en återställningspunkt för att återställa den virtuella datorn i målregionen. Men Azure Site Recovery stöder inte alla lagringstyper som är tillgängliga i Azure. Mer information finns i Stödmatris för Azure Site Recovery för lagring.

  • För SAP-system som körs på Windows med en delad Azure-disk kan du använda Azure Site Recovery med Azure Shared Disk (förhandsversion). Eftersom funktionen är i offentlig förhandsversion rekommenderar vi inte att du implementerar scenariot för de flesta kritiska SAP-produktionsarbetsbelastningar. Mer information om scenarier som stöds för Azure Shared Disk finns i Supportmatris för delade diskar i Haveriberedskap för virtuella Azure-datorer (förhandsversion)

  • Förutom Azure-hanterade datadiskar som är anslutna till virtuella datorer används olika azure-interna lagringslösningar för att köra SAP-program på Azure. Dr-metoden för varje Azure-lagringslösning kan skilja sig åt, eftersom inte alla lagringstjänster som är tillgängliga i Azure stöds med Azure Site Recovery. Nedan visas listan över lagringstyper som vanligtvis används för SAP-arbetsbelastningar.

    Lagringstyp Rekommendation om DR-strategi
    Hanterad disk Azure Site Recovery
    NFS på Azure-filer (LRS eller ZRS) Anpassat skript för att replikera data mellan två platser (till exempel rsync)
    NFS på Azure NetApp Files Använda replikering mellan regioner av Azure NetApp Files-volymer
    Azure Shared Disk (LRS eller ZRS) Azure Site Recovery med Delad Azure-disk (i förhandsversion)
    SMB på Azure-filer (LRS eller ZRS) Använda RoboCopy för att kopiera filer mellan två platser
    SMB på Azure NetApp Files Använda replikering mellan regioner av Azure NetApp Files-volymer

  • För anpassade lagringslösningar som NFS-kluster måste du se till att lämplig DR-strategi finns på plats.

  • Olika inbyggda Azure Storage-tjänster (till exempel Azure Files, Azure NetApp Files) kanske inte är tillgängliga i alla regioner. Så om du vill ha liknande SAP-konfiguration i DR-regionen efter redundansväxlingen kontrollerar du att respektive lagringstjänst erbjuds på DR-platsen. Mer information finns i Azure-produkter efter region.

  • Om du använder zonredundanslagring (ZRS) för Azure Files och Azure Shared Disk i din primära region och vill behålla samma ZRS-redundansalternativ i DR-regionen kan du läsa [Stöd för Premium-filresurser för ZRS](Stöd för zonredundant lagring i Azure Files (ZRS) för premiumfilresurser | Dokumentet Microsoft Learn) och ZRS för hanterade diskar för ZRS-stöd i Azure-regioner.

  • Tänk på följande om du använder tillgänglighetszoner för haveriberedskap:

    • Azure NetApp Files-funktionen är inte zonmedveten ännu. För närvarande distribueras inte Azure NetApp Files-funktionen i alla tillgänglighetszoner i en Azure-region. Det kan därför hända att Azure NetApp Files-tjänsten inte är tillgänglig i den valda tillgänglighetszonen för din DR-strategi.
    • Replikering mellan regioner av Azure NetApp-filvolymer är endast tillgängligt i par med fast region, inte mellan zoner.

  • Om du konfigurerar lagringen med Active Directory-integrering bör liknande installation även göras på DR-platslagringskontot.

Nästa steg