Dela via

Riktlinjer för haveriberedskap för SAP-program

  • Artikel

För att konfigurera Haveriberedskap (DR) för SAP-arbetsbelastningar i Azure måste du testa, finjustera och uppdatera processen regelbundet. Genom att testa haveriberedskap kan du identifiera sekvensen med beroende tjänster som krävs innan du kan utlösa DR-redundansväxling för SAP-arbetsbelastningar 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. Mer 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 komponenten med hög tillgänglighet skyddar SAP-systemet från lokala fel eller katastrofer. 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 metoden för haveriberedskap för varje komponent i ett SAP-system. Fristående SAP-motorer som inte är NetWeaver-motorer som TREX- och icke-SAP-program omfattas 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-databas Använd replikeringsmetoden som erbjuds av databasen
Delad lagring Replikera innehåll med lämplig metod per lagringstyp

SAP Web Dispatcher

Komponenten SAP Web Dispatcher 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 för SAP Web Dispatcher som konfigurerats 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:s centrala tjänster. Följ samma riktlinjer som nämnts för SAP Central Services.

SAP Central Services

DE CENTRALA SAP-tjänsterna 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 för hög tillgänglighet för SAP-arbetsbelastningar i Azure.

Att konfigurera hög tillgänglighet för SAP Central Services skyddar 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 följande avsnitt, 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 en redundansväxling måste du överväga ytterligare punkter. Det handlar bland annat om att konfigurera om klustret, se till att delade SAP-kataloger är tillgängliga och replikera virtuella datorer och deras hanterade diskar till DR-platsen med Azure Site Recovery. I Linux kan den höga tillgängligheten för SAP-programmet uppnås med hjälp av en pacemakerklusterlösning. Diagrammet nedan visar de olika komponenter som ingår i konfigurationen av hög tillgänglighet för SAP:s centrala 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

Interna 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 i befintligt format 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.

SAP-delade 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 med 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 konfigurerats för installationen måste du kontrollera att data replikeras och är tillgängliga på DR-platsen. Metoden för gränsöverskridande replikering 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

Dricks

Vi rekommenderar att du distribuerar en av Azures NFS-tjänster från första part: 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 operativsystem (SLES eller RHEL) och dess version kräver pacemakern en giltig fäktningsmekanism för att hela lösningen ska fungera korrekt. Baserat på vilken typ av fäktningsmekanism du hade konfigurerat i den primära regionen måste du se till att samma fäktningsmekanism 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 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 delad Azure-disk är tillgänglig i begränsade regioner.

Kommentar

Vi rekommenderar att du har samma fäktningsmekanism för både den primära regionen och dr-regionen för enkel drift och redundans. Det rekommenderas inte att ha en annan fäktningsmekanism 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. För att ha DR för SAP-programservrar kan Azure Site Recovery konfigureras för varje virtuell programserver. För delade lagringar (transportfilsystem, gränssnittsdatafilsystem) som är anslutet 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 interna DBMS-replikeringstekniken för att konfigurera DR. Användning av Azure Site Recovery för databaser rekommenderas inte eftersom det inte garanterar db-konsekvens och har dataomsättningsbegränsningar. Replikeringstekniken för varje databas är olika, så följ respektive databasriktlinjer. Följande tabell visar listan över databaser som används för SAP-arbetsbelastningar och motsvarande DR-rekommendation.

Databas DR-rekommendation
SAP HANA HANA System Replication (HSR)
Oracle Oracle Data Guard (FarSync)
IBM DB2 Haveriberedskap med hög tillgänglighet (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR Always On
SAP MaxDB Väntelägesdatabas

För kostnadsoptimerad lösning kan du till och med använda alternativet för säkerhetskopiering och återställning för databas-DR-strategi.

Säkerhetskopiera och återställ

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 affärs-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 Scenarier och distributioner i Azure Backup finns i Supportmatris för Azure Backup.

Tjänster Komponent Stöd för Azure Backup
Compute Virtuella Azure-datorer Stöds
Lagring Azure Managed Disks inklusive delade diskar Stöds
Lagring Azure-filresurs – SMB (Standard eller Premium) Stöds
Lagring Azure-blobbar Stöds
Lagring Delad Azure-fil – NFS (Standard eller Premium) Stöds inte
Lagring 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

Kommentar

*Azure Backup stöder Oracle-databas med azure VM-säkerhetskopiering för databas konsekventa ö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. Med funktionen för återställning mellan regioner 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 den medför en kompromiss med högre RTO. Eftersom du behöver återställa alla program från säkerhetskopian om det sker redundansväxling till DR-regionen. Därför måste du analysera ditt affärsbehov och utforma en DR-strategi.

Referenser