Pokyny pro zotavení po havárii pro aplikaci SAP

  • Článek

Pokud chcete nakonfigurovat zotavení po havárii (DR) pro úlohy SAP v Azure, musíte tento proces pravidelně testovat, ladit a aktualizovat. Testování zotavení po havárii pomáhá identifikovat posloupnost závislých služeb, které jsou potřeba před aktivací převzetí služeb při selhání úlohy SAP nebo spuštěním systému v sekundární lokalitě. Organizace mají obvykle své systémy SAP připojené ke službám Active Directory (AD) a DNS (Domain Name System), aby správně fungovaly. Při nastavování zotavení po havárii pro vaši úlohu SAP se před obnovením SYSTÉMU SAP a jiných systémů, které nejsou SAP, ujistěte, že fungují služby AD a DNS, aby aplikace fungovala správně. Pokyny k ochraně služby Active Directory a DNS najdete v tématu Ochrana služby Active Directory a DNS. Doporučení k zotavení po havárii pro aplikaci SAP popsaná v tomto dokumentu jsou na abstraktní úrovni. Strategii zotavení po havárii musíte navrhnout na základě konkrétního nastavení a zdokumentovat kompletní scénář.

Doporučení k zotavení po havárii pro úlohy SAP

Obvykle v distribuovaných systémech SAP NetWeaver; centrální služby, databáze a sdílené úložiště (NFS/SMB) jsou kritickým bodem selhání (SPOF). Pokud chcete zmírnit účinek různých SPOF, je nutné nastavit redundanci těchto komponent. Redundance těchto komponent SPOF v primární oblasti se dosahuje konfigurací vysoké dostupnosti. Nastavení vysoké dostupnosti komponenty chrání systém SAP před místním selháním nebo katastrofou. V zájmu ochrany aplikací SAP před geografickou rozptýlenou havárií by se ale měla implementovat strategie zotavení po havárii pro všechny komponenty SAP.

Pro systémy SAP běžící na virtuálních počítačích můžete pomocí Azure Site Recovery vytvořit plán zotavení po havárii. Následuje doporučený přístup k zotavení po havárii pro každou komponentu systému SAP. Tento dokument neobsahuje samostatné moduly SAP, které nejsou netWeaver, jako jsou aplikace TREX a jiné než SAP.

Komponenty Doporučení
SAP Web Dispatcher Replikace virtuálního počítače s využitím Azure Site Recovery
Centrální služby SAP Replikace virtuálního počítače s využitím Azure Site Recovery
Aplikační server SAP Replikace virtuálního počítače s využitím Azure Site Recovery
Databáze SAP Použití metody replikace nabízené databází
Sdílené úložiště Replikace obsahu pomocí vhodné metody pro jednotlivé typy úložiště

SAP Web Dispatcher

Komponenta SAP Web Dispatcher funguje jako nástroj pro vyrovnávání zatížení pro provoz SAP mezi aplikačními servery SAP. Máte různé možnosti, jak dosáhnout vysoké dostupnosti komponenty SAP Web Dispatcher v primární oblasti. Další informace o této možnosti najdete v tématu Nastavení vysoké dostupnosti SAP Web Dispatcher a SAP Web Dispatcher v Azure.

  • Možnost 1: Vysoká dostupnost s využitím clusterových řešení
  • Možnost 2: Vysoká dostupnost s paralelními webovými dispečery SAP.

Pokud chcete dosáhnout zotavení po havárii pro nastavení sap Web Dispatcheru s vysokou dostupností v primární oblasti, můžete použít Azure Site Recovery. Pro paralelní webové dispečery (možnost 2) spuštěné v primární oblasti můžete nakonfigurovat Azure Site Recovery, abyste dosáhli zotavení po havárii. Pokud jste ale sap Web Dispatcher nakonfigurovali pomocí možnosti 1 v primární oblasti, budete muset po převzetí služeb při selhání provést nějaké další změny, abyste měli podobné nastavení vysoké dostupnosti v oblasti zotavení po havárii. Při konfiguraci SAP Web Dispatcheru se vysoká dostupnost s clusterovým řešením konfiguruje podobným způsobem jako centrální služby SAP. Postupujte podle stejných pokynů, které jsou uvedené pro centrální služby SAP.

Centrální služby SAP

Centrální služby SAP obsahují frontue a server zpráv, což je jeden z SPOF vaší aplikace SAP. V systému SAP může existovat pouze jedna taková instance, která se dá nakonfigurovat pro vysokou dostupnost. Přečtěte si téma Vysoká dostupnost pro službu SAP Central Service , kde najdete vysvětlení různých řešení vysoké dostupnosti pro úlohy SAP v Azure.

Konfigurace vysoké dostupnosti pro centrální služby SAP chrání prostředky a procesy před místními incidenty. Pokud chcete dosáhnout zotavení po havárii pro sap Central Services, můžete použít Azure Site Recovery. Azure Site Recovery replikuje virtuální počítače a připojené spravované disky, ale pro strategii zotavení po havárii existují další aspekty. Další informace v závislosti na operačním systému používaném pro centrální služby SAP najdete v následující části.

V systému SAP se redundance komponenty SPOF v primární oblasti dosahuje konfigurací vysoké dostupnosti. Pokud chcete dosáhnout podobného nastavení vysoké dostupnosti v oblasti zotavení po havárii po převzetí služeb při selhání, musíte zvážit další body, jako je rekonfigurace clusteru, dostupnost sdílených adresářů SAP a replikace virtuálních počítačů a připojených spravovaných disků k lokalitě zotavení po havárii pomocí Azure Site Recovery. V Linuxu je možné dosáhnout vysoké dostupnosti aplikace SAP pomocí clusterového řešení Pacemaker. Následující diagram znázorňuje různé komponenty, které se podílejí na konfiguraci vysoké dostupnosti pro centrální služby SAP pomocí Pacemakeru. Každá komponenta musí být vzata v úvahu, aby měla podobně nastavenou vysokou dostupnost v lokalitě zotavení po havárii. Pokud jste nakonfigurovali SAP Web Dispatcher pomocí clusteru řešení Pacemaker, platí to také.

Architektura systému SAP v Linuxu

Interní nástroj pro vyrovnávání zatížení

Azure Site Recovery replikuje virtuální počítače do lokality pro zotavení po havárii, ale nereplikuje nástroj pro vyrovnávání zatížení Azure. Na webu pro zotavení po havárii budete muset předem nebo po převzetí služeb při selhání vytvořit samostatný interní nástroj pro vyrovnávání zatížení. Pokud předem vytvoříte interní nástroj pro vyrovnávání zatížení, vytvořte prázdný back-endový fond a po události převzetí služeb při selhání přidejte virtuální počítače.

Řešení clusteru Pacemaker

Konfigurace clusteru Pacemakeru se nacházejí v místních souborech virtuálních počítačů, které se replikují do lokality zotavení po havárii pomocí Azure Site Recovery. Po převzetí služeb při selhání nebude na virtuálních počítačích fungovat konfigurace clusteru Pacemakeru tak, jak je. Aby řešení fungovalo, vyžaduje se další rekonfigurace clusteru.

Přečtěte si tyto blogy, kde se dozvíte o rekonfiguraci clusteru Pacemakeru v oblasti zotavení po havárii v závislosti na typu úložiště a mechanismu ohraničení.

Sdílené adresáře SAP pro Linux

Nastavení vysoké dostupnosti platformy SAP NetWeaver nebo ABAP používá server replikace fronty k dosažení redundance na úrovni aplikace pro službu zařazení systému SAP do fronty s konfigurací clusteru Pacemaker. Nastavení vysoké dostupnosti centrálních služeb SAP (ASCS a ERS) používá připojení NFS. Proto je potřeba zajistit, aby se binární soubory a data SAP v těchto připojeních NFS replikovaly do lokality pro zotavení po havárii. Azure Site Recovery replikuje virtuální počítače a připojené místně spravované disky, ale nereplikuje připojení NFS. V závislosti na typu úložiště NFS, které jste pro nastavení nakonfigurovali, se musíte ujistit, že jsou data replikovaná a dostupná v lokalitě zotavení po havárii. Metodologie replikace mezi oblastmi pro každé úložiště je prezentována na abstraktní úrovni. Musíte potvrdit přesný postup replikace úložiště a provedení testování.

Sdílené adresáře SAP Replikace mezi oblastmi
Nfs ve službě Azure Files Vlastní (například rsync)
NFS v ANF Ano (replikace mezi oblastmi)
Cluster NFS Vlastní

Tip

Pokud chcete ukládat sdílená data v systému SAP s vysokou dostupností, doporučujeme nasadit některou ze služeb NFS první strany v Azure: NFS na svazky Azure Files nebo NFS ANF. Mějte na paměti, že zdůrazňujeme referenční architektury SAP a využíváme clustery NFS.

Mechanismus oplocení

Bez ohledu na operační systém (SLES nebo RHEL) a jeho verzi vyžaduje kardiostimulátor platný mechanismus ohraničení, aby celé řešení fungovalo správně. Na základě typu mechanismu ohraničení, který jste nastavili v primární oblasti, se musíte ujistit, že je stejný mechanismus ohraničení nastavený i v lokalitě zotavení po havárii po převzetí služeb při selhání.

Mechanismus oplocení Doporučení k zotavení po havárii mezi oblastmi
SBD s využitím cílového serveru iSCSI Replikujte cílový server iSCSI pomocí Azure Site Recovery.
Na virtuálních počítačích zotavení po havárii znovu zjistěte disk iSCSI.
Agent ohraničení Azure Povolte identity spravovaného systému (MSI) na virtuálních počítačích pro zotavení po havárii.
Přiřaďte vlastní role.
Aktualizujte prostředek agenta ohraničení v clusteru.
SBD s využitím sdíleného disku Azure* Nakonfigurujte nový sdílený disk Azure v oblasti zotavení po havárii. Po převzetí služeb při selhání připojte sdílený disk Azure k virtuálním počítačům zotavení po havárii.
Nastavte zařízení Sbd se sdíleným diskem Azure.

*ZRS pro sdílený disk Azure je k dispozici v omezených oblastech.

Poznámka

Pro usnadnění provozu a převzetí služeb při selhání doporučujeme použít stejný mechanismus ohraničení jak pro primární oblast, tak pro oblast zotavení po havárii. Po převzetí služeb při selhání do lokality zotavení po havárii se nedoporučuje používat jiný mechanismus ohraničení.

Aplikační servery SAP

V primární oblasti se redundance aplikačních serverů SAP dosahuje instalací instancí do více virtuálních počítačů. Pokud chcete mít zotavení po havárii pro aplikační servery SAP, můžete azure Site Recovery nastavit pro každý virtuální počítač aplikačního serveru. Pro sdílená úložiště (systém souborů přenosu, datový systém rozhraní), která jsou připojená k aplikačním serverům, postupujte podle příslušného postupu zotavení po havárii na základě typu sdíleného úložiště.

Databázové servery SAP

Pro databáze, na kterých běží úloha SAP, použijte ke konfiguraci zotavení po havárii nativní replikační technologii DBMS. Použití Azure Site Recovery pro databáze se nedoporučuje, protože nezaručuje konzistenci databáze a má omezení četnosti změn dat. Technologie replikace pro každou databázi se liší, proto postupujte podle příslušných pokynů k databázi. Následující tabulka obsahuje seznam databází používaných pro úlohy SAP a odpovídající doporučení zotavení po havárii.

Databáze Doporučení zotavení po havárii
SAP HANA Replikace systému HANA (HSR)
Oracle Oracle Data Guard (FarSync)
IBM DB2 Zotavení po havárii s vysokou dostupností (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR AlwaysOn
SAP MaxDB Pohotovostní databáze

V případě řešení optimalizovaného pro náklady můžete dokonce použít možnost zálohování a obnovení pro strategii zotavení po havárii databáze.

Zálohování a obnovení

Zálohování a obnovení je další řešení, které můžete použít k dosažení zotavení po havárii pro úlohy SAP, pokud obchodní RTO a RPO nejsou kritické. Pomocí služby Azure Backup, cloudové služby zálohování, můžete pořizovat kopie různých komponent úloh SAP, jako jsou virtuální počítače, spravované disky a podporované databáze. Další informace o obecných nastaveních podpory a omezeních pro Azure Backup scénáře a nasazení najdete v tématu Azure Backup matice podpory.

Služby Součást podpora Azure Backup
Compute Virtuální počítače Azure Podporováno
Storage Azure Spravované disky včetně sdílených disků Podporováno
Storage Sdílená složka Azure – SMB (Standard nebo Premium) Podporováno
Storage Objekty blob Azure Podporováno
Storage Sdílené soubory Azure – NFS (Standard nebo Premium) Nepodporuje se
Storage Azure NetApp Files Nepodporuje se
Databáze Databáze SAP HANA na virtuálních počítačích Azure Podporováno
Databáze SQL Server na virtuálních počítačích Azure Podporováno
Databáze Oracle Podporuje se*
Databáze IBM DB2, SAP ASE Nepodporuje se

Poznámka

*Zálohování Azure podporuje databázi Oracle s využitím zálohování virtuálních počítačů Azure pro vytváření snímků konzistentních vzhledem k databázím.

Azure Backup nepodporuje všechna úložiště a databáze Azure, které se používají pro úlohy SAP.

Azure Backup ukládá zálohy do trezoru služby Recovery Services, který replikuje vaše data na základě zvoleného typu replikace (LRS, ZRS nebo GRS). V případě geograficky redundantního úložiště (GRS) se zálohovaná data replikují do spárované sekundární oblasti. Když je povolená funkce obnovení mezi oblastmi , můžete obnovit data podporovaného typu správy v sekundární oblasti.

Zálohování a obnovení je tradičnější přístup optimalizovaný z hlediska nákladů, ale přináší kompromis s vyšší plánovanou plánovanou obnovou( RTO). Pokud dojde k převzetí služeb při selhání do oblasti zotavení po havárii, potřebujete obnovit všechny aplikace ze zálohy. Proto potřebujete analyzovat své obchodní potřeby a podle toho navrhnout strategii zotavení po havárii.

Reference