Pokyny pro zotavení po havárii pro aplikaci SAP
Pokud chcete nakonfigurovat zotavení po havárii (DR) pro úlohy SAP v Azure, musíte proces pravidelně testovat, vyladit 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 zotavení po havárii úloh 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. Když nastavíte zotavení po havárii pro úlohu SAP, ujistěte se, že služby AD a DNS fungují před obnovením systémů SAP a dalších systémů, které nejsou systémy SAP, a ujistěte se, že aplikace funguje správně. Pokyny k ochraně služby Active Directory a DNS najdete v tématu Ochrana služby Active Directory a DNS. Doporučení zotavení po havárii pro aplikaci SAP popsanou v tomto dokumentu je na abstraktní úrovni. Potřebujete navrhnout strategii zotavení po havárii na základě konkrétního nastavení a zdokumentovat kompletní scénář.
Doporučení 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 objektů 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. Pokud ale chcete chránit aplikace SAP před geograficky rozptýlenou havárií, měla by být pro všechny komponenty SAP implementována strategie zotavení po havárii.
V případě systémů SAP běžících 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 pro zotavení po havárii pro každou komponentu systému SAP. Tento dokument neobsahuje samostatné moduly SAP, jako jsou TREX a jiné aplikace než SAP.
Komponenty | Doporučení |
---|---|
SAP Web Dispatcher | Replikace virtuálního počítače pomocí Azure Site Recovery |
Centrální služby SAP | Replikace virtuálního počítače pomocí Azure Site Recovery |
Aplikační server SAP | Replikace virtuálního počítače pomocí Azure Site Recovery |
Databáze SAP | Použití metody replikace nabízené databází |
Sdílené úložiště | Replikace obsahu s použitím vhodné metody na typ ú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 Vysoká dostupnost instalace SAP Web Dispatcher a SAP Web Dispatcher v Azure.
- Možnost 1: Vysoká dostupnost s využitím řešení clusteru
- Možnost 2: Vysoká dostupnost s paralelními webovými dispečery SAP
Pokud chcete dosáhnout zotavení po havárii pro vysoce dostupnou instalaci SAP Web Dispatcheru v primární oblasti, můžete použít Azure Site Recovery. Pro paralelní webové dispečery (možnost 2) běžící v primární oblasti můžete nakonfigurovat Azure Site Recovery, aby dosáhla zotavení po havárii. U SAP Web Dispatcheru nakonfigurovaného pomocí možnosti 1 v primární oblasti ale musíte po převzetí služeb při selhání provést další změny, aby se podobná vysoká dostupnost nastavila v oblasti zotavení po havárii. Vzhledem k tomu, že konfigurace sap Web Dispatcheru s vysokou dostupností s řešením clusteru je nakonfigurovaná podobným způsobem jako centrální služby SAP. Postupujte podle stejných pokynů jako u centrálních služeb 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 a dá se nakonfigurovat pro zajištění vysoké dostupnosti. Přečtěte si informace o vysoké dostupnosti pro službu SAP Central Service a seznamte se s různými řešeními vysoké dostupnosti pro úlohy SAP v Azure.
Konfigurace vysoké dostupnosti pro SAP Central Services chrání prostředky a procesy před místními incidenty. K dosažení 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 na základě operačního systému používaného pro centrální služby SAP najdete v následující části.
V případě systému SAP se redundance komponenty SPOF v primární oblasti dosahuje konfigurací vysoké dostupnosti. Pokud chcete po převzetí služeb při selhání dosáhnout podobného nastavení vysoké dostupnosti v oblasti zotavení po havárii, musíte zvážit další body. Patří sem změna konfigurace clusteru, zajištění dostupnosti sdílených adresářů SAP a replikace virtuálních počítačů a jejich spravovaných disků do lokality zotavení po havárii pomocí Azure Site Recovery. V Linuxu je možné dosáhnout vysoké dostupnosti aplikace SAP pomocí řešení clusteru pacemaker. Následující diagram znázorňuje různé komponenty, které jsou součástí konfigurace vysoké dostupnosti pro centrální služby SAP pomocí Pacemakeru. Aby byla v lokalitě zotavení po havárii nastavena podobná vysoká dostupnost, je potřeba vzít v úvahu každou komponentu. Pokud jste nakonfigurovali SAP Web Dispatcher pomocí řešení clusteru pacemaker, platí i podobné aspekty.
Interní nástroj pro vyrovnávání zatížení
Azure Site Recovery replikuje virtuální počítače do lokality zotavení po havárii, ale nereplikuje nástroj pro vyrovnávání zatížení Azure. 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í v lokalitě zotavení po havárii. 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 pacemaker 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. Konfigurace clusteru pacemaker nefunguje po převzetí služeb při selhání na virtuálních počítačích. Aby řešení fungovalo, vyžaduje se další rekonfigurace clusteru.
Přečtěte si tyto blogy, kde se dozvíte o rekonfiguraci clusteru pacemaker v oblasti zotavení po havárii na základě typu úložiště a mechanismu oplocení.
- Cluster SAP ASCS/ERS HA se zařízením SBD (pomocí cílového serveru iSCSI) převzetí služeb při selhání do oblasti zotavení po havárii pomocí Azure Site Recovery
- Převzetí služeb při selhání clusteru SAP ASCS HA (v operačním systému Linux) do oblasti zotavení po havárii pomocí Azure Site Recovery
Sdílené adresáře SAP pro Linux
Nastavení vysoké dostupnosti platformy SAP NetWeaver nebo ABAP používá server replikace enqueue k dosažení redundance na úrovni aplikace pro službu enqueue systému SAP s konfigurací clusteru Pacemaker. Nastavení vysoké dostupnosti centrálních služeb SAP (ASCS a ERS) využí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 zotavení po havárii. Azure Site Recovery replikuje virtuální počítače a připojený místní spravovaný disk, ale nereplikuje připojení NFS. Na základě typu úložiště NFS nakonfigurovaného pro nastavení musíte zajistit, aby se data replikovala a byla dostupná v lokalitě zotavení po havárii. Metodologie replikace napříč oblastmi pro každé úložiště se prezentuje na abstraktní úrovni. Musíte potvrdit přesné kroky replikace úložiště a provést testování.
Sdílené adresáře SAP | Replikace mezi oblastmi |
---|---|
NFS ve službě Soubory Azure | Vlastní (například rsync) |
NFS v ANF | Ano (replikace mezi oblastmi) |
Cluster NFS | Vlastní |
Tip
Pro ukládání sdílených dat do vysoce dostupného systému SAP doporučujeme nasadit jednu ze služeb NFS první strany: NFS na svazcích Azure Files nebo NFS ANF. Mějte na paměti, že s využitím clusterů NFS de-emphasizujeme referenční architektury SAP.
Mechanismus šermingu
Bez ohledu na operační systém (SLES nebo RHEL) a jeho verzi vyžaduje pacemaker platný mechanismus šermování, aby celé řešení fungovalo správně. Na základě typu mechanismu šermování, který jste nastavili ve své primární oblasti, je potřeba zajistit, aby byl stejný mechanismus oplocení nastavený v lokalitě zotavení po havárii po převzetí služeb při selhání.
Mechanismus šermingu | Doporučení zotavení po havárii napříč oblastmi |
---|---|
SBD s využitím cílového serveru iSCSI | Replikace cílového serveru iSCSI pomocí Azure Site Recovery Na virtuálních počítačích zotavení po havárii znovu zjistěte disk iSCSI. |
Agent plotu Azure | Povolení identit spravovaného systému (MSI) na virtuálních počítačích zotavení po havárii Přiřaďte vlastní role. Aktualizujte prostředek agenta plotu v clusteru. |
SBD pomocí 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 sdíleného disku 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 mí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 pro ohraničení.
Aplikační servery SAP
V primární oblasti se redundance aplikačních serverů SAP dosahuje instalací instancí do několika virtuálních počítačů. Pokud chcete mít zotavení po havárii pro aplikační servery SAP, můžete pro každý virtuální počítač aplikačního serveru nastavit Azure Site Recovery . Pro sdílená úložiště (přenosový systém souborů, datový systém souborů rozhraní), který je 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 nativní replikační technologii DBMS ke konfiguraci zotavení po havárii. 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 uvádí 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 |
Pro řešení optimalizované pro náklady můžete dokonce použít možnost zálohování a obnovení pro strategii zotavení po havárii databáze.
Záloha a obnovení
Zálohování a obnovení je další řešení, které můžete použít k zotavení po havárii pro úlohy SAP, pokud jsou obchodní RTO a RPO nekritické. Pomocí služby Azure Backup, cloudové služby zálohování, můžete pořizovat kopie různých součástí úloh SAP, jako jsou virtuální počítače, spravované disky a podporované databáze. Další informace o obecných nastaveních a omezeních podpory pro scénáře a nasazení služby Azure Backup najdete v matici podpory služby Azure Backup.
Služby | Komponenta | Podpora služby Azure Backup |
---|---|---|
Compute | Virtuální počítače Azure | Podporováno |
Úložiště | Azure Spravované disky včetně sdílených disků | Podporováno |
Úložiště | Sdílená složka Azure – SMB (Standard nebo Premium) | Podporováno |
Úložiště | Objekty blob Azure | Podporováno |
Úložiště | Sdílené soubory Azure – NFS (Standard nebo Premium) | Nepodporuje se |
Úložiště | 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 pomocí zálohování virtuálních počítačů Azure pro snímky konzistentní 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 Service, 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 vaše zálohovaná data replikují do spárované sekundární oblasti. S povolenou funkcí 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ý pro náklady, ale přináší kompromis vyšší rto. Pokud dojde k převzetí služeb při selhání do oblasti zotavení po havárii, musíte obnovit všechny aplikace ze zálohy. Proto potřebujete analyzovat obchodní potřeby a odpovídajícím způsobem navrhnout strategii zotavení po havárii.