Riktlinjer för haveriberedskap för SAP-program

  • Artikel

För att konfigurera haveriberedskap (DR) för SAP-arbetsbelastning i Azure måste du testa, finjustera och uppdatera processen regelbundet. Genom att testa haveriberedskap kan du identifiera sekvenser av beroende tjänster som krävs innan du kan utlösa REDUNDANSväxling för SAP-arbetsbelastning eller starta systemet på den sekundära platsen. Organisationer har vanligtvis sina SAP-system anslutna till Active Directory-tjänster (AD) och DNS-tjänster (Domain Name System) för att fungera korrekt. När du konfigurerar DR för din SAP-arbetsbelastning kontrollerar du att AD- och DNS-tjänsterna fungerar innan du återställer SAP och andra icke-SAP-system för att säkerställa att programmet fungerar korrekt. Information om hur du skyddar Active Directory och DNS finns i hur du skyddar Active Directory och DNS. Dr-rekommendationen för SAP-programmet som beskrivs i det här dokumentet är på abstrakt nivå. Du måste utforma din DR-strategi baserat på din specifika konfiguration och dokumentera scenariot från slutpunkt till slutpunkt.

DR-rekommendation för SAP-arbetsbelastningar

Vanligtvis i distribuerade SAP NetWeaver-system; centrala tjänster, databas och delad lagring (NFS/SMB) är en enda felpunkt (SPOF). För att minska effekten av olika SPOF:er är det nödvändigt att konfigurera redundans för dessa komponenter. Redundansen för dessa SPOF-komponenter i den primära regionen uppnås genom att konfigurera hög tillgänglighet. Konfigurationen av hög tillgänglighet för komponenten skyddar SAP-systemet mot lokala fel eller haverier. Men för att skydda SAP-program från geografiska spridda katastrofer bör dr-strategin implementeras för alla SAP-komponenter.

För SAP-system som körs på virtuella datorer kan du använda Azure Site Recovery för att skapa en haveriberedskapsplan. Följande är den rekommenderade haveriberedskapsmetoden för varje komponent i ett SAP-system. Fristående icke-NetWeaver SAP-motorer som TREX- och icke-SAP-program beskrivs inte i det här dokumentet.

Komponenter Rekommendation
SAP Web Dispatcher Replikera virtuell dator med Azure Site Recovery
SAP Central Services Replikera virtuell dator med Azure Site Recovery
SAP-programserver Replikera virtuell dator med Azure Site Recovery
SAP Database Använd replikeringsmetod som erbjuds av databasen
Delad lagring Replikera innehåll med lämplig metod per lagringstyp

SAP Web Dispatcher

SAP Web Dispatcher-komponenten fungerar som lastbalanserare för SAP-trafik mellan SAP-programservrar. Du har olika alternativ för att uppnå hög tillgänglighet för SAP Web Dispatcher-komponenten i den primära regionen. Mer information om det här alternativet finns i Hög tillgänglighet för konfigurationen av SAP Web Dispatcher och SAP Web Dispatcher HA på Azure.

  • Alternativ 1: Hög tillgänglighet med klusterlösning.
  • Alternativ 2: Hög tillgänglighet med parallella SAP Web Dispatchers.

Om du vill uppnå DR för konfiguration av SAP Web Dispatcher med hög tillgänglighet i den primära regionen kan du använda Azure Site Recovery. För parallella webbsändare (alternativ 2) som körs i den primära regionen kan du konfigurera Azure Site Recovery för att uppnå DR. Men om du har konfigurerat SAP Web Dispatcher med alternativ 1 i den primära regionen måste du göra några ytterligare ändringar efter redundansväxlingen för att ha liknande HA-konfiguration i DR-regionen. Eftersom konfigurationen av SAP Web Dispatcher med hög tillgänglighet med klusterlösningen är konfigurerad på liknande sätt som SAP Central Services. Följ samma riktlinjer som anges för SAP Central Services.

SAP Central Services

SAP:s centrala tjänster innehåller enqueue- och meddelandeserver, som är en av SPOF:erna för ditt SAP-program. I ett SAP-system kan det bara finnas en sådan instans och den kan konfigureras för hög tillgänglighet. Läs Hög tillgänglighet för SAP Central Service för att förstå de olika lösningarna med hög tillgänglighet för SAP-arbetsbelastningar i Azure.

När du konfigurerar hög tillgänglighet för SAP Central Services skyddas resurser och processer från lokala incidenter. För att uppnå DR för SAP Central Services kan du använda Azure Site Recovery. Azure Site Recovery replikerar virtuella datorer och anslutna hanterade diskar, men det finns ytterligare överväganden för DR-strategin. Mer information finns i avsnittet nedan, baserat på vilket operativsystem som används för SAP:s centrala tjänster.

För SAP-system uppnås redundansen för SPOF-komponenten i den primära regionen genom att konfigurera hög tillgänglighet. För att uppnå liknande konfiguration av hög tillgänglighet i haveriberedskapsregionen efter redundansväxlingen måste du överväga ytterligare punkter som omkonfiguration av kluster, tillgänglighet för SAP-delade kataloger, tillsammans med replikering av virtuella datorer och ansluten hanterad disk till dr-plats med Azure Site Recovery. I Linux kan den höga tillgängligheten för SAP-programmet uppnås med hjälp av pacemakerklusterlösningen. Diagrammet nedan visar de olika komponenter som ingår i konfigurationen av hög tillgänglighet för CENTRALA SAP-tjänster med Pacemaker. Varje komponent måste beaktas för att ha liknande hög tillgänglighet konfigurerad på dr-platsen. Om du har konfigurerat SAP Web Dispatcher med hjälp av pacemakerklusterlösningen skulle liknande överväganden också gälla.

LINUX-arkitektur för SAP-system

Intern lastbalanserare

Azure Site Recovery replikerar virtuella datorer till dr-platsen, men den replikerar inte Azure-lastbalanseraren. Du måste skapa en separat intern lastbalanserare på DR-platsen i förväg eller efter redundansväxlingen. Om du skapar en intern lastbalanserare i förväg skapar du en tom serverdelspool och lägger till virtuella datorer efter redundanshändelsen.

Pacemakerklusterlösning

Konfigurationerna av ett pacemakerkluster finns i lokala filer med virtuella datorer, som replikeras till dr-platsen med Azure Site Recovery. Konfigurationen av pacemakerkluster fungerar inte som den ska på de virtuella datorerna efter redundansväxlingen. Ytterligare omkonfiguration av kluster krävs för att lösningen ska fungera.

Läs de här bloggarna om du vill veta mer om omkonfigurationen av pacemakerklustret i dr-regionen, baserat på typen av lagrings- och fäktningsmekanism.

DELADE SAP-kataloger för Linux

Konfigurationen av hög tillgänglighet för SAP NetWeaver eller ABAP-plattformen använder enqueue-replikeringsserver för att uppnå redundans på programnivå för den köande tjänsten för SAP-system med Pacemaker-klusterkonfiguration. Konfigurationen av hög tillgänglighet för SAP Central Services (ASCS och ERS) använder NFS-monteringar. Därför måste du se till att SAP-binärfiler och data i dessa NFS-monteringar replikeras till DR-platsen. Azure Site Recovery replikerar virtuella datorer och anslutna lokala hanterade diskar, men de replikerar inte NFS-monteringar. Baserat på vilken typ av NFS-lagring som du har konfigurerat för installationen måste du kontrollera att data replikeras och är tillgängliga på DR-platsen. Metoden för replikering mellan regioner för varje lagring presenteras på abstrakt nivå. Du måste bekräfta exakta steg för att replikera lagring och utföra testning.

DELADE SAP-kataloger Replikering mellan regioner
NFS på Azure-filer Anpassad (som rsync)
NFS på ANF Ja (replikering mellan regioner)
NFS-kluster Anpassat

Tips

Vi rekommenderar att du distribuerar en av NFS-tjänsterna från första part i Azure: NFS på Azure Files- eller NFS ANF-volymer för lagring av delade data i ett SAP-system med hög tillgänglighet. Tänk på att vi de-betonar SAP-referensarkitekturer och använder NFS-kluster.

Fäktningsmekanism

Oavsett operativsystemet (SLES eller RHEL) och dess version kräver pacemakern en giltig stängselmekanism för att hela lösningen ska fungera korrekt. Baserat på vilken typ av fäktningsmekanism som du hade konfigurerat i din primära region måste du se till att samma stängselmekanism har konfigurerats på dr-platsen efter redundansväxlingen.

Fäktningsmekanism Dr-rekommendation mellan regioner
SBD med iSCSI-målserver Replikera iSCSI-målservern med Azure Site Recovery.
På virtuella DR-datorer identifierar du iSCSI-disken igen.
Azure Fence-agent Aktivera hanterade systemidentiteter (MSI) på virtuella DR-datorer.
Tilldela anpassade roller.
Uppdatera stängselagentresursen i klustret.
SBD med delad Azure-disk* Konfigurera en ny delad Azure-disk i dr-regionen. Koppla en delad Azure-disk till virtuella DR-datorer efter redundansväxlingen.
Konfigurera en SBD-enhet med delad Azure-disk.

*ZRS för en delad Azure-disk är tillgänglig i begränsade regioner.

Anteckning

Vi rekommenderar att du har samma stängselmekanism för både den primära regionen och dr-regionen för enkel drift och redundans. Det rekommenderas inte att ha en annan stängselmekanism efter redundansväxling till dr-platsen.

SAP-programservrar

I den primära regionen uppnås redundansen för SAP-programservrarna genom att installera instanser på flera virtuella datorer. Om du vill ha dr för SAP-programservrar kan Azure Site Recovery konfigureras för varje virtuell programserverdator. För delade lagringsenheter (transportfilsystem, gränssnittsdatafilsystem) som är anslutna till programservrarna följer du lämplig DR-metod baserat på typen av delad lagring.

SAP-databasservrar

För databaser som kör SAP-arbetsbelastningar använder du den inbyggda DBMS-replikeringstekniken för att konfigurera HAVER. Användning av Azure Site Recovery för databaser rekommenderas inte eftersom det inte garanterar db-konsekvens och har dataomsättningsbegränsning. Replikeringstekniken för varje databas är olika, så följ respektive databasriktlinjer. I tabellen nedan visas en lista över databaser som används för SAP-arbetsbelastningar och motsvarande dr-rekommendation.

Databas DR-rekommendation
SAP HANA HANA-systemreplikering (HSR)
Oracle Oracle Data Guard (FarSync)
IBM DB2 Haveriberedskap med hög tillgänglighet (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR AlwaysOn
SAP MaxDB Standby-databas

För kostnadsoptimerad lösning kan du till och med använda säkerhetskopierings- och återställningsalternativet för databasens DR-strategi.

Säkerhetskopiera och återställa

Säkerhetskopiering och återställning är en annan lösning som du kan använda för att uppnå haveriberedskap för dina SAP-arbetsbelastningar om företagets RTO och RPO inte är kritiska. Du kan använda Azure Backup, en molnbaserad säkerhetskopieringstjänst för att ta kopior av olika komponenter i din SAP-arbetsbelastning, till exempel virtuella datorer, hanterade diskar och databaser som stöds. Mer information om allmänna supportinställningar och begränsningar för Azure Backup scenarier och distributioner finns i Azure Backup supportmatris.

Tjänster Komponent Azure Backup support
Compute Virtuella Azure-datorer Stöds
Storage Azure Managed Disks inklusive delade diskar Stöds
Storage Azure-filresurs – SMB (Standard eller Premium) Stöds
Storage Azure-blobbar Stöds
Storage Delad Azure-fil – NFS (Standard eller Premium) Stöds inte
Storage Azure NetApp Files Stöds inte
Databas SAP HANA-databas på virtuella Azure-datorer Stöds
Databas SQL Server på virtuella Azure-datorer Stöds
Databas Oracle Stöds*
Databas IBM DB2, SAP ASE Stöds inte

Anteckning

*Azure Backup har stöd för Oracle-databaser med azure VM-säkerhetskopiering för databassekventa ögonblicksbilder.

Azure Backup stöder inte alla Azure-lagringar och databaser som används för SAP-arbetsbelastningar.

Azure Backup lagrar säkerhetskopior i Recovery Service-valvet, som replikerar dina data baserat på den valda replikeringstypen (LRS, ZRS eller GRS). För geo-redundant lagring (GRS) replikeras dina säkerhetskopierade data till en länkad sekundär region. När funktionen för återställning mellan regioner är aktiverad kan du återställa data av den hanteringstyp som stöds i den sekundära regionen.

Säkerhetskopiering och återställning är en mer traditionell kostnadsoptimerad metod men medför en kompromiss med högre RTO. Eftersom du behöver återställa alla program från säkerhetskopian om det sker en redundansväxling till dr-regionen. Därför måste du analysera ditt affärsbehov och utforma en DR-strategi.

Referenser