Provozní kontinuita a zotavení po havárii pro migraci SAP
Tento článek vychází z aspektů a doporučení v oblasti návrhu cílové zóny Azure pro BCDR. Tento článek popisuje jedinečná omezení cílových zón, které podporují platformu SAP. SAP je kritická platforma, takže do návrhu byste měli zahrnout i další klíčové pokyny .
Scénář a rozsah
Začleňte do své architektury principy, které řeší scénáře provozní kontinuity a zotavení po havárii (BCDR). Tyto principy platí také v Azure. Azure ale může mít větší kapacitu hardwaru než vaše místní prostředí, které může kompenzovat selhání hostitele. Pokud chcete automaticky obnovit i největší virtuální počítače Azure, můžete je nakonfigurovat tak, aby se restartovaly na jiném serveru. Nastavte nasazení Azure tak, aby používala stejné podmínky jako vaše místní nasazení. Pokud k nasazení místních systémů nebo holého hardwaru používáte konfigurace clusteru s automatickým převzetím služeb při selhání, nasaďte je stejným způsobem v Azure. Aplikace SAP, které provozují nejdůležitější obchodní procesy vaší organizace, vyžadují:
Dostupnost služeb a obchodních procesů
Cíle doby obnovení (RTO) pro scénáře selhání nebo scénáře havárie
Cíle bodu obnovení (RPO) pro scénáře selhání
Provozní úlohy a úlohy správy životního cyklu a technologie, které se spouští ve scénářích selhání Mezi tyto úlohy správy patří opravy hostujících operačních systémů a systémů pro správu databází, klonování a aktualizace systémů SAP.
Tip
Určete řešení vysoké dostupnosti a zotavení po havárii (HADR) pro každý z archetypů v prostředí SAP v rané fázi. Ujistěte se, že řešení pokrývá všechny komponenty SAP.
Nakonfigurujte řešení HADR v Azure na začátku, nejméně v jedné krajině a zachovejte ho aktivní. Vaše týmy pak můžou získat zkušenosti s technologiemi řešení, které se můžou lišit od stávajících technologií. Konfigurace HADR v rané fázi, která pomáhá vyvíjet a vyvíjet standardní provozní postupy (SOP).
Jakmile bude systém aktivní, naplánujte si úplnou vysokou dostupnost, zotavení po havárii a ochranu před zálohováním pro produkční úlohy.
Tento článek popisuje následující aspekty BCDR pro scénář SAP na podnikové úrovni:
Vysoká dostupnost v rámci oblasti Azure
Důležité informace o zálohování a obnovení
Kritéria pro rozhodování mezi oblastmi a regionálním zotavením po havárii
Vysoká dostupnost v rámci oblasti Azure
Následující části obsahují aspekty návrhu a doporučení pro vysokou dostupnost v rámci oblasti Azure pro podnikový scénář SAP.
Aspekty návrhu pro vysokou dostupnost
Při implementaci vysoké dostupnosti je cílem zajistit dostupnost pro kritický bod selhání softwaru SAP, například:
Systémy pro správu databází.
Jediné body selhání v aplikaci, jako je SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) a SAP Central Services (SCS). Příklady vysoké dostupnosti zahrnují SAP NetWeaver a architekturu SAP S/4HANA.
Další nástroje, jako je SAP Web Dispatcher
V jiných scénářích neomezovat dostupnost na selhání infrastruktury nebo selhání softwaru. Využijte dostupnost pro všechny nezbytné úlohy správy životního cyklu. Operační systém můžete například opravit ve virtuálních počítačích, v systému pro správu databází (DBMS) a softwaru SAP. Pokud chcete minimalizovat výpadky, ke kterým může dojít během plánovaných výpadků a operací správy životního cyklu, použijte běžné nástroje, které pomáhají chránit vaše systémy před neplánovaným přerušením služeb.
Databáze SAP a SAP podporují automatické clustery s podporou převzetí služeb při selhání. Ve Windows podporuje funkce clusteringu s podporou převzetí služeb při selhání Windows Server 2022 převzetí služeb při selhání. V Linuxu podporují převzetí služeb při selhání linuxové nástroje Pacemaker nebo partnerské nástroje, jako je SIOS Protection Suite a Veritas InfoScale. V Azure můžete nasadit pouze konfiguraci vysoké dostupnosti podmnožinu ve vlastním datacentru.
Další informace najdete v tématu Podporované scénáře pro úlohy SAP na virtuálních počítačích Azure a podporované scénáře pro velké instance SAP HANA.
V případě vrstvy DBMS je běžným vzorem architektury replikace databází současně a s různými zásobníky úložiště, než které používají primární virtuální počítače a sekundární virtuální počítače. Azure nepodporuje architektury, ve kterých primární virtuální počítače a sekundární virtuální počítače sdílejí úložiště pro data DBMS. Azure také nepodporuje protokoly transakcí ani znovu protokoly. Hlavním principem je použití dvou nezávislých zásobníků úložiště, i když jsou založené na sdílených složkách systému souborů NFS (Network File System). Tato omezení platí výhradně pro řešení Azure, nikoli pro místní řešení.
Azure nabízí další možnosti, protože podporuje sdílení souborů NFS a Server Message Block. Sdílené disky Azure ve Windows můžete použít pro komponenty ASCS a SCS a konkrétní scénáře s vysokou dostupností. Nastavte clustery s podporou převzetí služeb při selhání samostatně pro komponenty aplikační vrstvy SAP a vrstvu DBMS. Azure nepodporuje architektury vysoké dostupnosti, které kombinují komponenty aplikační vrstvy SAP a vrstvu DBMS do jednoho clusteru s podporou převzetí služeb při selhání.
Většina clusterů s podporou převzetí služeb při selhání pro komponenty aplikační vrstvy SAP a vrstva DBMS vyžaduje pro cluster s podporou převzetí služeb při selhání virtuální IP adresu. Běžnou výjimkou je, když používáte Oracle Data Guard, což nevyžaduje virtuální IP adresu. Azure Load Balancer by měl zpracovávat virtuální IP adresu pro všechny ostatní případy. Pro každou konfiguraci clusteru můžete použít jeden nástroj pro vyrovnávání zatížení. Doporučujeme používat standardní verzi nástroje pro vyrovnávání zatížení. Další informace najdete v tématu Připojení k veřejnému koncovému bodu pro virtuální počítače pomocí služby Azure Load Balancer úrovně Standard ve scénářích s vysokou dostupností SAP.
Další informace najdete v architektuře a scénářích s vysokou dostupností pro SAP NetWeaver.
Následující tabulka ukazuje smlouvy o úrovni služeb (SLA) na úrovni platformy pro různé možnosti nasazení s vysokou dostupností. Partneři, kteří poskytují spravované služby, také poskytují smlouvu SLA na úrovni aplikace.
| Úroveň | Scénář vysoké dostupnosti | Smlouva SLA platformy |
|---|---|---|
| 0 | Availability zone | 99,99 % |
| 2 | Skupina dostupnosti | 99,95 % |
| 3 | Jeden virtuální počítač (samoopravení) | 99.90% |
Skupiny dostupnosti Azure vs. zóny dostupnosti
Před nasazením infrastruktury vysoké dostupnosti určete, jestli se má nasadit se sadou dostupnosti Azure nebo zónou dostupnosti v závislosti na zvolené oblasti. Hlavní rozdíly pro virtuální počítače, které nasazujete se sadou dostupnosti, jsou:
Virtuální počítače se nerozprostírají mezi různé zóny dostupnosti.
Typ virtuálních počítačů, které můžete nasadit prostřednictvím jedné skupiny dostupnosti, jsou omezené, protože první virtuální počítač, který v sadě nasadíte, definuje hostitele. Nemůžete například kombinovat virtuální počítače řady M a virtuální počítače řady E-series do jedné skupiny dostupnosti.
Když nasadíte architekturu s vysokou dostupností napříč různými zónami dostupnosti, můžete pro virtuální počítače mít vyšší smlouvu SLA. Další informace najdete v tématu Sla virtuálních počítačů Azure. V závislosti na oblasti Azure můžete zjistit různé podmínky latence sítě v síťovém provozu mezi virtuálními počítači. Další informace najdete v tématu Konfigurace úloh SAP se zónami dostupnosti Azure.
Pokud zvolíte přístup k zónovému nasazení, zvažte, jak latence napříč zónami pro zvolenou oblast Azure může ovlivnit volby návrhu výkonu a architektury. Zvažte latenci mezi aplikačním serverem a databází a mezi dvěma databázovými uzly.
Pokud pro vrstvu aplikačního serveru, ve které se aplikační servery musí připojit k databázi ve stejné zóně dostupnosti, použijete aktivní/pasivní zónové nasazení, nakonfigurujte automatizaci a vytvořte SOP, aby bylo možné rychlé a automatizované obnovení, pokud dojde k převzetí služeb při selhání databáze.
Pokud ve svém řešení SAP používáte zóny dostupnosti, navrhněte všechny ostatní služby Azure a komponenty infrastruktury v prostředí SAP pro redundanci zón také tak, abyste mohli dosáhnout skutečné redundance zón. Mezi příklady služeb a komponent, které je potřeba vzít v úvahu, patří brány Azure ExpressRoute, Load Balancer, Azure Files, Azure NetApp Files, reverzní proxy servery, brány firewall, antivirové služby a infrastruktura zálohování.
Doporučení návrhu pro vysokou dostupnost
Azure nabízí několik možností, které vám pomůžou splnit smlouvy SLA infrastruktury vaší aplikace. Pro všechny tři komponenty SAP byste měli zvolit stejnou možnost: centrální služby, aplikační server a databázi. Další informace o smlouváchSLAch online služby ch
Když nasadíte virtuální počítače ve skupině dostupnosti, zarovnání s doménami selhání a aktualizací zabrání tomu, aby virtuální počítače byly na stejném hostitelském hardwaru, který poskytuje ochranu před selháním hardwaru. Když nasadíte virtuální počítače prostřednictvím zón dostupnosti a použijete různé zóny, vytvoříte virtuální počítače napříč různými fyzickými umístěními. Tato konfigurace poskytuje dodatečnou ochranu proti problémům s napájením, chlazením nebo sítí, které ovlivňují datacentra zóny jako celku. Nemůžete ale nasadit skupiny dostupnosti Azure v rámci zóny dostupnosti Azure, pokud nepoužíváte skupiny umístění bezkontaktní komunikace.
Pokud zvolíte přístup k zónovým nasazením, vrstvy SAP DBMS, centrální služby a aplikační vrstvy běží v různých zónách dostupnosti. Každá zóna dostupnosti ale s největší pravděpodobností má několik aplikačních serverů. V tomto scénáři aplikační servery v každé zóně automaticky nevyužívají domény selhání a aktualizační domény. Tyto výhody můžete získat pomocí skupin dostupnosti. Další informace najdete v tématu Skupiny umístění bezkontaktní komunikace Azure pro zajištění optimální latence sítě pomocí SAP.
Při vytváření skupin dostupnosti použijte maximální počet domén selhání a dostupných aktualizačních domén. Pokud například nasadíte více než dva virtuální počítače do jedné skupiny dostupnosti, použijte maximální počet domén selhání (tři). Navíc k plánované údržbě Azure využijte dostatek aktualizačních domén, abyste omezili dopad potenciálních selhání fyzického hardwaru, výpadků sítě nebo přerušení napájení. Výchozí počet domén selhání je dva a později ho nemůžete změnit online.
V nasazení skupiny dostupnosti musí být každá komponenta systému SAP ve vlastní skupině dostupnosti. Centrální služby SAP, databáze a aplikační virtuální počítače by měly být ve vlastních skupinách dostupnosti.
Při použití skupin umístění bezkontaktní komunikace Azure v nasazení skupiny dostupnosti se ujistěte, že všechny tři komponenty SAP (centrální služby, aplikační server a databáze) jsou ve stejné skupině umístění bezkontaktní komunikace.
Pokud používáte skupiny umístění bezkontaktní komunikace, použijte jednu pro každou identifikaci systému SAP (SID). Skupiny se nepřesahují mezi zónami dostupnosti ani oblastmi Azure.
Pokud v nasazení zón dostupnosti používáte skupiny umístění bezkontaktní komunikace Azure, ujistěte se, že jsou dvě komponenty SAP (centrální služby a aplikační server) ve stejné skupině umístění bezkontaktní komunikace. Databázové virtuální počítače ve dvou zónách už nejsou součástí skupin umístění bezkontaktní komunikace. Skupiny umístění bezkontaktní komunikace pro každou zónu jsou vymezeny nasazením virtuálního počítače, na kterém běží instance SAP ASCS a SCS. Výhodou této konfigurace je, že máte větší flexibilitu při změně velikosti virtuálních počítačů. Můžete také snadno přepnout na nové typy virtuálních počítačů ve vrstvě DBMS nebo aplikační vrstvě systému SAP.
Azure nepodporuje kombinování služby ASCS a vysoké dostupnosti databází v jednom clusteru Pacemaker s Linuxem. Rozdělte je do jednotlivých clusterů. V páru virtuálních počítačů můžete kombinovat až pět clusterů centrálních služeb.
Před službami ASCS a databázovými clustery používejte Load Balancer úrovně Standard.
Spusťte všechny produkční systémy na discích SSD Úrovně Premium a použijte Azure NetApp Files nebo Azure Ultra Disk Storage. Minimálně se ujistěte, že je disk s operačním systémem na úrovni Premium, abyste mohli zlepšit výkon a získat nejlepší smlouvu SLA.
Nasaďte oba virtuální počítače ve dvojici s vysokou dostupností ve skupině dostupnosti nebo v zónách dostupnosti. Ujistěte se, že tyto virtuální počítače mají stejnou velikost a mají stejnou konfiguraci úložiště.
K synchronizaci databáze ve dvojici s vysokou dostupností použijte nativní technologii replikace databáze.
Pomocí jedné z následujících služeb můžete spouštět clustery centrálních služeb SAP v závislosti na operačním systému:
Nastavte parametry časového limitu clusteru podle doporučení v dokumentaci pro centrální služby a databázové clustery.
Úložiště pro úlohy SAP
Při návrhu odolnosti v úloze SAP zvolte správné možnosti úložiště. Správný návrh úložiště Azure pro úlohy SAP může minimalizovat latenci a maximalizovat propustnost. Zvažte implementaci a způsob, jakým vám následující pokyny můžou pomoct při rozhodování o architektuře pro implementaci SAP v Azure. Další informace najdete v tématu Typy úložiště Azure pro úlohy SAP.
SAP HANA byste měli spouštět jenom na typech úložiště certifikovaných pro SAP. Na určitých konfiguracích disků musíte spouštět určité svazky. Například konfigurace můžou povolit akcelerátor zápisu nebo použít úložiště SSD úrovně Premium. Musíte také zajistit, aby systém souborů, který běží v úložišti, byl kompatibilní s DBMS, který běží na počítači. Další informace najdete v tématu Konfigurace úložiště pro SAP HANA.
Kromě spravovaných datových disků Azure, které jsou připojené k virtuálním počítačům, spouští různá řešení sdíleného úložiště nativní pro Azure aplikace SAP v Azure. Vaše konfigurace vysoké dostupnosti se může lišit, protože Azure Site Recovery nepodporuje některé služby úložiště, které jsou dostupné v Azure. Pro úlohy SAP použijte následující typy úložiště.
Typ úložiště Podpora konfigurace vysoké dostupnosti Sdílené disky Azure (místně redundantní úložiště (LRS) nebo zónově redundantní úložiště (ZRS) Cluster s podporou převzetí služeb při selhání systému Windows Server 2022 Podrobnosti o konfiguraci najdete v tématu Návrh vysoké dostupnosti SAP pomocí clusteringu s podporou převzetí služeb při selhání s Windows Serverem 2022. NFS ve službě Azure Files (LRS nebo ZRS) Cluster založený na Pacemakeru v linuxových prostředích. Nezapomeňte zkontrolovat dostupnost systému souborů NFS v různých oblastech. NFS ve službě Azure NetApp Files Cluster založený na Pacemakeru v linuxových prostředích. Další informace najdete v tématu Azure NetApp Files pro virtuální počítače SAP. SMB ve službě Azure Files (LRS nebo ZRS) Cluster s podporou převzetí služeb při selhání systému Windows Server 2022 Podrobnosti o konfiguraci najdete v tématu Instalace vysoké dostupnosti SAP NetWeaver se službou Azure Files SMB. SMB v Azure NetApp Files Cluster s podporou převzetí služeb při selhání systému Windows Server 2022 Podrobnosti o konfiguraci najdete v tématu Vysoká dostupnost pro SAP NetWeaver se službou Azure NetApp Files (SMB) pro aplikace SAP. Místo služeb sdíleného úložiště nativních pro Azure můžete použít tradiční clustery NFS (založené na replikaci distribuovaných blokových zařízení), GlusterFS nebo sdílený svazek clusteru s Prostory úložiště s přímým přístupem jako alternativní řešení sdíleného úložiště ke spouštění úloh SAP v Azure. Tyto volby jsou užitečné zejména v případech, kdy služby sdíleného úložiště nativní pro Azure nejsou dostupné v cílové oblasti Azure nebo nepodporují cílovou architekturu. Další informace o dostupnosti služby úložiště najdete v produktech Azure v jednotlivých oblastech.
Informace o možnostech úložiště, které jsou k dispozici pro úlohy SAP v Azure, najdete v doporučeních a pokynech k nastavení zotavení po havárii.
Zálohování a obnovení
Následující části popisují aspekty návrhu a doporučení pro zálohování a obnovení ve scénáři SAP.
I když se zálohování a obnovení obvykle nepovažuje za odpovídající řešení vysoké dostupnosti pro produkční úlohu SAP, poskytuje tato technologie další výhody. Většina společností, které používají aplikace SAP, musí dodržovat předpisy dodržování předpisů, které vyžadují dlouhodobé ukládání záloh. V jiných scénářích musíte mít také zálohu, ze které můžete provést obnovení. V těchto doprovodných materiálech se předpokládá, že jste již vytvořili zálohování a obnovení, a dodržujete osvědčené postupy pro aplikace SAP, což znamená, že můžete:
Proveďte obnovení k určitému bodu v čase pro produkční databáze v libovolném okamžiku v časovém rámci, který splňuje rtO. Obnovení k určitému bodu v čase obvykle poskytuje ochranu před chybami operátorů, jako je odstranění dat, a to buď ve vrstvě DBMS, nebo prostřednictvím SAP.
Udržujte úložiště, abyste si zachovali dlouhodobé zálohy, aby bylo možné vyhovět předpisům dodržování předpisů.
Pomocí záloh databází naklonujte systém SAP a obnovte zálohy na jiný server nebo virtuální počítač.
K aktualizaci neprodukčních systémů použijte produkční data databáze ze záloh databází.
Zálohujte aplikační servery SAP a virtuální počítače, disky nebo snímky virtuálních počítačů.
Zálohujte systém SAP HANA s povolenou replikací.
Zálohujte snímky instancí databáze SAP HANA.
Pokud zálohujete a obnovujete místně, musíte tyto funkce přenést do systémů SAP v Azure. Pokud se vám aktuální řešení líbí, zkontrolujte, jestli dodavatel zálohování podporuje nasazení Azure, nebo jestli má řešení SaaS (software jako služba) pro Azure.
Azure poskytuje zálohovanou službu SaaS s názvem Azure Backup, která přebírá snímky virtuálních počítačů a spravuje streamované zálohy SQL Serveru a SAP HANA . Pokud k ukládání databází SAP HANA používáte Azure NetApp Files , můžete spouštět zálohy na základě snímků úložiště konzistentních s HANA.
Službu Azure Backup můžete použít také k zálohování databází s povolenou replikací systému SAP HANA (HSR). Azure Backup automaticky spravuje zálohy, když dojde k převzetí služeb při selhání, a eliminuje potřebu ručního zásahu. Zálohování také poskytuje:
Okamžitá ochrana bez nápravných úplných záloh, takže můžete chránit instance HANA nebo uzly nastavení HSR jako jeden kontejner HSR.
Výhoda okamžitého zálohování a okamžitého obnovení.
Přístup založený na snímcích založený na HANA, který se integruje s Backintem pro SAP HANA. Zálohování můžete použít jako jeden produkt pro celou oblast HANA a pro libovolnou velikost databáze.
Další informace najdete v databázovém systému SAP HANA s povolenou replikací a zálohováním snímků instancí SAP HANA.
Návrh doporučení pro zálohování a obnovení
Azure Backup můžete použít k zálohování aplikačního serveru SAP a virtuálních počítačů centrálních služeb.
Můžete použít zálohu SAP HANA pro nasazení HANA, která mají až 8 TB. Další informace najdete v tématu Matice podpory pro zálohování databází SAP HANA na virtuálních počítačích Azure.
Pokud jako řešení zálohování služeb používáte infrastrukturu, nastavte velikost infrastruktury zálohování, abyste zajistili, že dokáže zálohovat všechny systémy v produkčním prostředí současně nebo podobně jako ve scénáři reálného života v očekávaném časovém rámci. Pro oblasti, jako jsou sítě a zabezpečení, použijte produkční nastavení nebo podobné nastavení.
Otestujte dobu zálohování a obnovení a ověřte, že splňují vaše požadavky RTO na obnovení všech systémů současně po havárii.
V ideálním případě se vyhněte načítání záloh z Azure do místní infrastruktury zálohování, zejména pro velké databáze. Tento přístup může ovlivnit, jakou šířku pásma okruhy ExpressRoute používají.
Zátěžový test nástrojů pro zálohování a obnovení v rámci plánu testu výkonnosti.
Zotavení po havárii
Následující části popisují aspekty návrhu a doporučení pro zotavení po havárii ve scénáři SAP.
Aspekty návrhu pro zotavení po havárii
Mapa oblastí Azure zahrnuje více než 65 oblastí Azure a ne všechny spouštějí stejné služby. U větších nasazení softwaru SAP, zejména těch, které používají SAP HANA, hledejte oblasti Azure, které nabízejí virtuální počítače řady Azure M nebo virtuální počítače řady Mv2. Azure Storage také spáruje různé oblasti a replikuje menší podmnožinu typů úložiště do jiné oblasti. Další informace najdete v tématu Přehled spárovaných oblastí Azure.
Hlavní výzvy párování oblastí Azure pro úlohy SAP jsou:
Tyto páry nejsou vždy konzistentní se službami virtuálních počítačů řady Mv2 nebo Mv2. Řada organizací, které nasazují své systémy SAP, nepoužívají spárované oblasti Azure. Místo toho vyberou oblasti na základě dostupnosti požadovaných typů virtuálních počítačů.
Můžete replikovat standardní úložiště mezi spárovanými oblastmi, ale nemůžete použít standardní úložiště k ukládání databází nebo virtuálních pevných disků. Zálohy můžete replikovat pouze mezi spárovanými oblastmi, které používáte. Pro všechna ostatní data spusťte replikaci pomocí nativních funkcí DBMS, jako je SQL Server AlwaysOn nebo replikace systému SAP HANA. Pro aplikační vrstvu SAP použijte kombinaci Site Recovery, nástrojů
rsyncjako neborobocopya dalších softwaru jiných společností než Microsoft.Pokud dojde k havárii, několik ovlivněných zákazníků v oblasti Azure převezme služby při selhání do odpovídající spárované oblasti zotavení po havárii. Tato situace vede k konkurenci prostředků, aby se v oblasti zotavení po havárii vyvolaly neaktivní virtuální počítače. Alternativním řešením je spouštět neprodukční systémy v oblasti zotavení po havárii a používat stejné prostředky k hostování replik zotavení po havárii produkčních systémů. Toto duální použití infrastruktury Azure v oblasti zotavení po havárii pomáhá vyhnout se omezením kapacity prostředků.
Dalším důležitým aspektem je zabezpečení požadované provozní kapacity v oblasti havárie. Pokud dojde k havárii, možná budete muset aplikaci SAP spustit po dobu minimálního časového intervalu s minimální kapacitou IT a důležitými lidskými prostředky jenom v době, kdy pracujete na obnovení normálního provozu v primární oblasti. Tato strategie vyžaduje, abyste v oblasti zotavení po havárii měli k dispozici minimální infrastrukturu IT.
Po definování oblastí Azure je potřeba zvolit model nasazení:
Nasadíte produkční systémy do primární oblasti?
Nasadíte neprodukční systémy SAP do oblasti zotavení po havárii?
Použijete architekturu, která seskupuje všechny systémy SAP do primární oblasti? Tato konfigurace zajišťuje, aby oblast zotavení po havárii byla použita pouze pro zotavení po havárii.
Většina organizací používá obě oblasti pro operační systémy SAP. Organizace, které spouštějí úplné kopie produkčních systémů jako testovací systémy pro obchodní regresi, obvykle plánují používat testovací systém obchodní regrese produktové řady SAP jako cíl zotavení po havárii.
Pokud zvolíte oblast zotavení po havárii, ujistěte se, že máte k této oblasti připojení ExpressRoute. Pokud máte více okruhů ExpressRoute, které se připojují k Azure, musí se alespoň jeden z těchto okruhů připojit k primární oblasti Azure. Ostatní by se měli připojit k oblasti zotavení po havárii. Tento typ architektury vás připojí k síti Azure v jiné geografické nebo geopolitické oblasti a pomáhá chránit vaše připojení, pokud katastrofa ovlivní jednu z oblastí Azure.
Některé organizace používají kombinaci vysoké dostupnosti a architektury zotavení po havárii, která seskupuje vysokou dostupnost s zotavením po havárii ve stejné oblasti Azure. Seskupení vysoké dostupnosti s zotavením po havárii ale není ideální. Tuto architekturu podporují zóny dostupnosti Azure. Vzdálenost mezi zónami dostupnosti v jedné oblasti Azure není tak velká jako vzdálenost mezi dvěma oblastmi Azure, takže přírodní katastrofa by mohla ohrozit aplikační služby v oblasti, ve které k ní dojde. Musíte také zvážit latenci mezi aplikačními servery SAP a databázovými servery. Podle sap poznámka 1100926, doba odezvy menší než nebo rovna 0,3 ms je dobrá hodnota a čas menší než nebo roven 0,7 ms je střední hodnota. Pro zóny s vysokou latencí tedy máte provozní postupy, které zajistí, aby aplikační servery SAP a databázové servery vždy běžely ve stejné zóně. Organizace volí tuto architekturu z následujících důvodů:
Dodržování předpisů je dostatečné u konfigurací, které podporují menší vzdálenosti mezi produkčním nasazením a cílem zotavení po havárii.
Suverenita dat je faktor.
Jsou zapojeny geopolitické faktory.
Jedná se o nízkonákladovou možnost, která podporuje zónová selhání, někdy v kombinaci s přenosem záloh do sekundární oblasti pro přírodní katastrofy, které ovlivňují velký poloměr.
Dalším faktorem, který je potřeba vzít v úvahu, když zvolíte oblast zotavení po havárii, je cíl bodu obnovení (RPO) a RTO pro převzetí služeb při selhání do lokality pro zotavení po havárii. Čím větší je vzdálenost mezi produkční oblastí a oblastmi zotavení po havárii, tím vyšší je latence sítě. Asynchronně replikujete mezi oblastmi Azure, ale latence sítě může ovlivnit propustnost, kterou můžete replikovat, a cíl bodu obnovení. Pokud chcete minimalizovat cíl bodu obnovení, můžete použít kombinovanou architekturu vysoké dostupnosti a zotavení po havárii. Tato konfigurace ale představuje potenciálně vyšší riziko před rozsáhlými přírodními katastrofami.
Doporučení návrhu pro zotavení po havárii
Ujistěte se, že směrování CIDR (Classless Inter-Domain Routing) pro primární virtuální síť není v konfliktu nebo se nepřekrývá s CIDR virtuální sítě lokality pro zotavení po havárii.
Nastavte připojení ExpressRoute z místního prostředí k primárním a sekundárním oblastem zotavení po havárii Azure.
Zvažte nastavení připojení VPN z místního prostředí do primárních a sekundárních oblastí zotavení po havárii Azure. Tuto metodu použijte jako alternativu k používání ExpressRoute.
Pomocí Site Recovery replikujte aplikační server do lokality pro zotavení po havárii. Site Recovery vám také může pomoct replikovat virtuální počítače clusteru centrálních služeb do lokality pro zotavení po havárii. Při vyvolání zotavení po havárii je potřeba překonfigurovat cluster Pacemaker pro Linux v lokalitě pro zotavení po havárii. Může být například potřeba nahradit virtuální IP adresu nebo SBD nebo spustit corosync.conf.
Replikujte obsah trezoru klíčů, jako jsou certifikáty, tajné kódy nebo klíče napříč oblastmi, abyste mohli dešifrovat data v oblasti zotavení po havárii.
Replikace mezi oblastmi ve službě Azure NetApp Files slouží k synchronizaci svazků souborů mezi primární oblastí a oblastí zotavení po havárii.
K synchronizaci dat do lokality pro zotavení po havárii použijte nativní replikaci databáze místo Site Recovery.
Vytvoření partnerského vztahu mezi primárními virtuálními sítěmi a virtuálními sítěmi pro zotavení po havárii Například pro replikaci systému HANA potřebujete vytvořit partnerský vztah virtuální sítě SAP HANA DB, která potřebuje lokalitu pro zotavení po havárii s virtuální sítí SAP HANA DB.
Pokud pro nasazení SAP používáte úložiště Azure NetApp Files, vytvořte minimálně dva účty Azure NetApp Files ve dvou oblastech.
Zvažte seskupení systémů na základě jejich obchodní důležitosti a závislosti na blízkosti na základě výkonu aplikace. Pokud chcete minimalizovat obchodní efekt oblastního výpadku, nasaďte každou skupinu do samostatné oblasti v konstruktoru spárované oblasti. Pokud chcete například minimalizovat dopad regionálního výpadku, můžete nasadit dva kritické systémy ERP Central Component, které slouží dvěma různým obchodním jednotkám v oblasti Velká Británie – jih a Velká Británie – západ.