Provozní kontinuita a zotavení po havárii pro Akcelerátor cílových zón Azure Virtual Machines pro Oracle

Tento článek vychází z aspektů a doporučení definovaných v oblasti návrhu cílové zóny Azure pro provozní kontinuitu a zotavení po havárii (BCDR). Tento článek se řídí pokyny a popisuje aspekty návrhu a osvědčené postupy týkající se možností BCDR pro nasazení úloh Oracle na virtuálních počítačích infrastruktury Azure.

Azure poskytuje služby, které můžete použít k návrhu vysoce dostupných a odolných architektur. Tato příručka popisuje různé možnosti a osvědčené postupy, které vám pomůžou navrhnout vysokou dostupnost a zotavení po havárii pro databáze Oracle na akcelerátoru cílových zón virtuálních počítačů Azure. Popisuje také, jak nakonfigurovat doprovodné služby Azure, které vám pomůžou dosáhnout vysoké kompletní dostupnosti pro vaše řešení.

Začínáme

Pokud chcete vytvořit odolnou architekturu pro vaše prostředí úloh, určete požadavky na dostupnost vašeho řešení na základě cíle doby obnovení (RTO) a cíle bodu obnovení (RPO) pro různé úrovně selhání. RtO je maximální doba, po kterou aplikace zůstane nedostupná po výskytu incidentu. RPO je maximální množství ztráty dat během havárie. Jakmile určíte požadavky na řešení, navrhněte architekturu tak, aby poskytovala stanovené úrovně odolnosti a dostupnosti.

Oracle v úlohách Azure primárně používají Oracle Data Guard, což je integrovaná funkce Oracle Database edice Enterprise, která používá technologii replikace. Data Guard můžete použít ke splnění požadavků na vysokou dostupnost a zotavení po havárii. Ochrana Data Guard nabízí tři režimy ochrany: maximální výkon, maximální dostupnost a maximální ochranu. V závislosti na návrhu architektury a konkrétních požadavcích bodu obnovení a RTO zvolte režim ochrany.

Konfigurace úloh pro zajištění vysoké dostupnosti

Instance virtuálních počítačů Azure, které spouštějí úlohy Oracle, využívají architekturu Škálovací sady virtuálních počítačů Azure, konkrétně flexibilní režim orchestrace. Konfigurace vysoké dostupnosti poskytuje replikaci dat téměř v reálném čase s potenciálně rychlými možnostmi převzetí služeb při selhání. Konfigurace vysoké dostupnosti neposkytuje ochranu pro selhání na úrovni datacentra nebo oblasti Azure.

Volba správné možnosti vysoké dostupnosti

Pomocí následujícího vývojového diagramu vyberte nejlepší možnost vysoké dostupnosti pro vaši databázi Oracle.

Použití ochrany Data Guard v režimu maximální dostupnosti pro zajištění vysoké dostupnosti

Ochrana Data Guard v režimu maximální dostupnosti poskytuje nejvyšší dostupnost s příslibem nulové ztráty dat (RPO=0) pro běžné operace. Pro vysoce dostupnou konfiguraci dvou databázových serverů Oracle vytvořených v rámci flexibilní orchestrace škálovací sady virtuálních počítačů poskytuje Azure 99,95% dostupnost služby pro smlouvu o úrovni služeb (SLA) pro instance, které jsou rozložené mezi domény selhání. Azure poskytuje 99,99% dostupnost služby pro instance, které jsou rozložené mezi zóny dostupnosti. Další informace najdete v tématu Vysoká dostupnost pro škálovací sady virtuálních počítačů.

Podrobné konfigurace ochrany Data Guard v Azure najdete v tématu Implementace Oracle Data Guard na virtuálním počítači Azure založeném na Linuxu.

Použití ochrany Data Guard v režimu maximální ochrany pro zajištění vysoké dostupnosti

Pokud potřebujete transakční konzistentní kopii databáze, zvažte použití ochrany Data Guard v režimu maximální ochrany. Režim maximální ochrany však neumožňuje, aby transakce pokračovaly, pokud není k dispozici pohotovostní databáze. Navzdory flexibilní orchestraci škálovacích sad virtuálních počítačů se proto vaše smlouva SLA sníží na 99,9 % x 99,9 % = 99,8 % při použití režimu maximální ochrany. Tato konfigurace zajišťuje konzistentní kopii dat, ale nemusí nutně zvýšit dostupnost.

Další atributy této architektury jsou stejné jako režim maximální dostupnosti. Cíl bodu obnovení je například nula a rtO je menší nebo roven dvěma minutě.

Zvažte další způsoby implementace vysoké dostupnosti.

Následující části popisují zvláštní aspekty vysoké dostupnosti.

Použití zón dostupnosti pro lepší vysokou dostupnost

Zóny dostupnosti Azure jsou datacentra Azure, která jsou ve stejné oblasti Azure. Zóny dostupnosti mají latenci odezvy menší než dvě milisekundy. Zóny dostupnosti obvykle používáte pro účely zotavení po havárii, ale můžete je použít ke zlepšení vysoké dostupnosti. Pokud to uděláte, musíte se ujistit, že vaše řešení může běžet s latencí a propustností, kterou vaše zóny dostupnosti poskytují.

Výhodou zón dostupnosti s flexibilní orchestrací škálovacích sad virtuálních počítačů je, že se smlouva SLA o dostupnosti virtuálního počítače zvýší na 99,99 %.

Použití clusteringu sdíleného úložiště pro zajištění vysoké dostupnosti

Technologie clusteringu sdílených úložišť poskytují jedinečné atributy, které vám pomůžou dosáhnout vašich obchodních cílů. Můžete například implementovat cluster Pacemaker a Corosync (PCS) se sdíleným úložištěm. Spravované disky nebo Azure NetApp Files můžete použít jako sdílené úložiště pro instance clusteru PCS. Cluster PCS nezdvojuje data. Poskytuje virtuální IP službu se statickou IP adresou nebo názvem sítě IP, která se nemění napříč převzetím služeb při selhání.

Poznámka:

Cluster PCS není řešení certifikované oraclem. Mějte na paměti, když zvolíte architekturu s vysokou dostupností.

Použití skupin umístění bezkontaktní komunikace

Pokud chcete zajistit nejnižší možnou latenci, umístěte virtuální počítače co nejblíže. Můžete je nasadit ve skupině umístění bezkontaktní komunikace. Skupina umístění bezkontaktní komunikace je logické seskupení, které zajišťuje, že se výpočetní prostředky Azure fyzicky nacházejí blízko sebe. Skupiny umístění bezkontaktní komunikace jsou užitečné pro úlohy, které vyžadují nízkou latenci.

Konfigurace úlohy pro zotavení po havárii

Architektura zotavení po havárii poskytuje odolnost proti selháním, která ovlivňují datacentra Nebo oblasti Azure nebo selhání, která brání fungování aplikace v celé oblasti. V takovém scénáři byste měli přesunout celou úlohu do jiného datacentra nebo oblasti.

Zvolte architekturu zotavení po havárii na základě požadavků vašeho řešení. Na základě rto a cíle bodu obnovení určíte své požadavky. Architektury zotavení po havárii jsou pro výjimečné případy selhání, takže procesy převzetí služeb při selhání jsou ruční. V návrhu vysoké dostupnosti jsou procesy převzetí služeb při selhání automatické. V architektuře zotavení po havárii byste měli mít uvolněnější požadavky na RTO a RPO, což šetří peníze.

Tento článek se zaměřuje na scénáře, ve kterých jsou primární i sekundární servery v Azure. Pro účely zotavení po havárii můžete mít také místní primární server a sekundární server v Azure. Další informace najdete v tématu Místní primární lokalita a lokalita zotavení po havárii v Azure.

Volba správné možnosti zotavení po havárii

Pomocí následujícího vývojového diagramu zvolte nejlepší možnost zotavení po havárii pro vaši databázi Oracle.

Použití ochrany Data Guard pro zotavení po havárii

Data Guard můžete použít k replikaci dat do lokality pro zotavení po havárii. Tuto lokalitu použijte jako jinou zónu dostupnosti ve stejné oblasti nebo v jiné oblasti v závislosti na vašich požadavcích na ochranu dat. Vaše konfigurace také závisí na struktuře zóny dostupnosti v produkční lokalitě. Implementace ochrany Data Guard ve scénáři zotavení po havárii se podobá scénáři s vysokou dostupností, který jsme probírali dříve, s několika důležitými rozdíly. Příklad:

• Při převzetí služeb při selhání sekundární replikou ve scénáři s vysokou dostupností nakonfigurujete Azure Load Balancer tak, aby přesměrovává požadavky na novou primární instanci databáze.

• Při převzetí služeb při selhání do lokality pro zotavení po havárii převezmete služby při selhání celého řešení do nové lokality. Abyste se vyhnuli problémům s latencí, obvykle potřebujete nakonfigurovat převzetí služeb při selhání pro aplikační služby.

Pokud je lokalita zotavení po havárii v jiné oblasti, musíte lokalitu navrhnout pro převzetí služeb při selhání v závislosti na vašich požadavcích.

Latence v rámci jednoho datacentra je menší než latence mezi datovými centry oddělená daleko od sebe a mnohem menší než latence mezi různými oblastmi. Proto je nejmenší a nejméně náročná možnost použít ochranu Data Guard v režimu maximálního výkonu pro účely zotavení po havárii. Pokud je potenciální ztráta dat v režimu maximálního výkonu příliš vysoká, můžete použít režim maximální dostupnosti pomocí mechanismu Oracle Data Guard Far Sync. Instance Far Sync ale aktivuje licencování Active Data Guard v primárním prostředí a pohotovostním prostředí. Další informace najdete v tématu Podrobnosti o licenci Oracle.

Kromě toho platíte při odesílání dat mezi oblastmi Nebo datacentry Azure náklady na výchozí přenos dat, jako jsou protokoly opětovného odeslání do lokality pro zotavení po havárii. Pokud nepotřebujete replikovat všechna data v databázi, můžete replikaci založenou na Oracle Golden Gate použít k replikaci pouze částečných dat podle potřeby, což snižuje náklady na výchozí přenos dat.

Podrobné konfigurace ochrany Data Guard v Azure najdete v tématu Implementace ochrany Dat Guard na virtuálním počítači Azure s Linuxem založeném na Linuxu.

Použití Golden Gate pro zotavení po havárii

Golden Gate je logický software pro replikaci, filtrování a transformaci dat ze zdrojové databáze do cílové databáze nebo mezi několika primárními databázemi v reálném čase. Tato funkce zajišťuje, aby se změny ve zdrojové databázi replikovaly téměř v reálném čase, aby cílová databáze byla aktuální s nejnovějšími daty.

Golden Gate můžete použít k replikaci dat z primární databáze do sekundární databáze v konfiguraci zotavení po havárii. Golden Gate je obzvláště praktický, pokud potřebujete chránit jenom některá data. Abyste se vyhnuli replikaci nepotřebných dat, použijte Golden Gate k selektivní replikaci tabulek a k vyfiltrování řádků tabulky během replikace.

Podrobný průvodce implementací Golden Gate v Azure najdete v tématu Implementace Golden Gate na virtuálním počítači Azure založeném na Linuxu.

Použití zálohování pro zotavení po havárii

Zálohování a obnovení je tradiční metoda architektury zotavení po havárii. Existují dvě hlavní komponenty pro zálohování jako metodu zotavení po havárii pro databáze Oracle v Azure:

• Extrahujte a přesuňte zálohu dat z databáze, abyste zajistili, že lokalita zotavení po havárii obsahuje aktuální data.

• Ujistěte se, že je v lokalitě pro zotavení po havárii aktuální nasazení. Pokud chcete lokalitu aktualizovat, replikujte stejné nasazení všech síťových komponent, aplikačních serverů a konfigurací do lokality pro zotavení po havárii.

Existuje několik možností zálohování, které můžete použít k replikaci dat. Další informace najdete v tématu Strategie zálohování pro Oracle Database v Azure.

Zvažte použití jednoho z následujících přístupů k údržbě lokality pro zotavení po havárii:

Přístup 1: Abyste se vyhnuli dodatečné údržbě a nákladům, neudržujte žádné fyzické nasazení v lokalitě zotavení po havárii. Infrastrukturu můžete použít jako postupy přípravy kódu a spolehlivosti lokality k vývoji a údržbě úložiště. Toto úložiště může replikovat nasazení jako konfiguraci do lokality pro zotavení po havárii v době převzetí služeb při selhání. Tato metoda optimalizuje náklady, protože nepoužívá žádné fyzické prostředky, dokud nedojde k převzetí služeb při selhání.

Důležité

Pokud během převzetí služeb při selhání vytvoříte celé nasazení úplně od začátku, musíte zajistit, aby vaše nasazení splňovalo požadavky rto řešení. Aby se zajistilo, že kód nasazení není poškozený, musíte rutinně simulovat a otestovat scénář zotavení po havárii.

Přístup 2: Nasazení a údržba škálované verze produkčního prostředí Máte verzi, která může správně fungovat pro malou úlohu a která můžete potenciálně vertikálně navýšit podle potřeby během převzetí služeb při selhání, aby sloužila pro produkční zatížení. Tato metoda se běžně používá, zejména u složitých nasazení, ve kterých nechcete riskovat vytvoření celého prostředí nebo pokud chcete provést převzetí služeb při selhání rychle, abyste získali nízkou hodnotu RTO.

Přístup 3: Nasaďte a udržujte celé řešení v lokalitě pro zotavení po havárii za nejrychlejší dobu OBNOVENÍ a převzetí služeb při selhání. Tato metoda zvyšuje náklady kvůli provozování plně redundantní infrastruktury.

Zvažte další způsoby implementace zotavení po havárii.

Následující části popisují zvláštní aspekty zotavení po havárii.

Použití vzdálené synchronizace

Far Sync nezlepší možnosti vysoké dostupnosti, ale můžete ho použít k dosažení nulových možností ochrany dat pro databáze Oracle. Pokud vaše primární databáze selže, může vaše úloha vyžadovat nulovou ztrátu dat. Další informace najdete v referenčních architekturách Oracle v Azure.

Volba správné technologie replikace dat

Kromě technologií v tomto článku můžete použít libovolnou technologii, která usnadňuje replikaci dat mezi dvěma databázemi Oracle, aby se zachovala replika s vysokou dostupností a replika zotavení po havárii pro databáze Oracle v Azure. Technologie, kterou zvolíte, musí odpovídat požadavkům vašeho řešení napříč těmito kategoriemi.

Latence: Doba potřebná k replikaci aktualizace z primární databáze do sekundárních databází pro zajištění vysoké dostupnosti a zotavení po havárii by měla splňovat požadavky vašeho řešení.

Šířka pásma: Množství a náklady na šířku pásma, které potřebujete k replikaci dat do sekundárních databází pro zajištění vysoké dostupnosti a zotavení po havárii. Azure poskytuje vysokorychlostní síťovou infrastrukturu mezi zónami dostupnosti. Při zvažování replikace do jiných oblastí Azure pro účely zotavení po havárii zvažte šířku pásma a náklady na výchozí přenos dat, která opustí datacentra Azure.

Dopad: Úroveň dopadu, který má replikace na zpracování transakcí v primární databázi, by měla splňovat požadavky vašeho řešení.

Ztráta dat: Velikost ztráty dat, kterou očekáváte během náhlého selhání primární databáze, by měla vyhovovat požadavkům vašeho řešení.

Celkové náklady na vlastnictví: Vezměte v úvahu náklady na pořízení řešení replikace jiné společnosti než Microsoft a množství úsilí, které potřebujete ke konfiguraci a údržbě řešení replikace. Ověřte, že tyto faktory vyhovují požadavkům vašeho řešení.

Optimalizace instance převzetí služeb při selhání

Pokud používáte ochranu Data Guard v režimu vysoké dostupnosti nebo v režimu vysoké ochrany, můžete nakonfigurovat automatické převzetí služeb při selhání, aby se při selhání primárního serveru automaticky vyvolal sekundární server. Při správné konfiguraci aplikačních serverů můžete zajistit, že během převzetí služeb při selhání nemáte téměř žádný výpadek aplikace.

V této implementaci musí databáze běžet stejně po převzetí služeb při selhání. Proto musíte nakonfigurovat sekundární server se stejnou kapacitou procesoru, paměti a vstupu a výstupu (V/V) jako primární server. Potřebujete udržovat vysokou kapacitu se sekundárním serverem, což zvyšuje náklady na Azure a náklady na licence Oracle Database. Sekundární server obvykle nezpracuje požadavky uživatelů.

Azure poskytuje 99,9% dostupnost virtuálních počítačů v zóně dostupnosti. Další informace najdete ve sla dostupnosti virtuálního počítače. Pokud používáte technologii replikace dat k údržbě sekundární repliky databáze ve stejné zóně dostupnosti, jiné zóně dostupnosti nebo jiné oblasti, můžete sekundární kapacitu optimalizovat.

Díky tomuto přístupu je sekundární databáze nakonfigurovaná s kapacitou, kterou potřebuje, aby zůstala aktuální. Pokud dojde k selhání, sekundární databáze se změní na stejnou kapacitu jako primární databáze. K této operaci dochází pouze v případě, že dojde k chybě. Během normálního provozu tedy platíte jenom za zlomek nákladů na primární server. Primární databáze není během selhání funkční, takže nepotřebujete další databázové licence Oracle.

Kapacita, kterou potřebujete k provozu sekundární databáze jako cíle replikace, závisí na technologii replikace, kterou používáte. Úloha, která je v systému OLTP (TransactionAl Online Transaction Processing), má v podstatě především požadavky na čtení. Například 90 % operací čtení a 10 % operací zápisu nebo 95 % operací čtení a 5 % zápisu jsou běžné v aplikacích OLTP. Replikace dat v podstatě replikuje výsledek zápisu požadavků ve zdrojové databázi. Při tomto nastavení můžete očekávat, že sekundární databáze bude fungovat s 1/10. (pokud máte 90% poměr čtení a 10% zápisu) kapacity primární databáze.

Automatizujte postupy převzetí služeb při selhání, abyste zajistili, že během procesu převzetí služeb při selhání splňujete podnikové standardy. Postupy převzetí služeb při selhání můžete nakonfigurovat tak, aby zahrnovaly operace změny velikosti serveru, které zjednodušují komplexní proces.

Konfigurace síťové topologie pro ochranu služeb a ochranu dat

Pokud chcete dosáhnout vysoké dostupnosti a zotavení po havárii, musíte učinit finanční a obchodní rozhodnutí, která vyrovnává dobu obnovení nebo plánovanou dobu obnovení a potenciální ztrátu dat nebo cíl bodu obnovení (RPO) oproti jiným nákladům na licencování Oracle, údržbu virtuálních počítačů a náklady na přenos dat. Když hostujete úlohu na jednom virtuálním počítači Azure, získáte základní ochranu pro běžné selhání hardwaru s nízkými náklady. Selhání jednoho virtuálního počítače ale pravděpodobně způsobí výpadky a ztrátu dat. Proto v produkčních prostředích zahrnují aspoň jednu sekundární databázi Oracle hostované na samostatném virtuálním počítači se sadou Data Guard. V závislosti na vašich požadavcích použijte pro replikaci dat jednu nebo více následujících konfigurací Ochrany dat:

• Optimální RTO a RPO. Pokud chcete minimalizovat latenci, začleníte sekundární databázi Oracle do samostatného virtuálního počítače v rámci stejné flexibilní orchestrace škálovacích sad virtuálních počítačů a do stejné zóny dostupnosti jako primární databáze. Tato konfigurace poskytuje vysokou dostupnost a ochranu proti selhání jedné instance.

• Ochrana dat před selháním datacentra Umístěte sekundární databázi Oracle do druhé zóny dostupnosti, která zajistí nastavení vysoké dostupnosti a zajistí ochranu v případě selhání celé zóny dostupnosti. Tato konfigurace může mít až dvě milisekundy latence mezi primární a sekundární databází, což může mít vliv na výkon, RTO a RPO.

• Ochrana dat před regionálním selháním Pokud chcete pomoct chránit před potenciální ztrátou dat v důsledku selhání oblasti Azure, můžete sekundární databázi umístit do jiné oblasti. Tato konfigurace může mít mezi oblastmi latenci 30 milisekund až 300 milisekund, takže možná nesplníte cíle RTO a RPO. Toto řešení je nejvhodnější pro regionální zotavení po havárii místo vysoké dostupnosti.

Kontinuita podnikových procesů vyžaduje integrovaný přístup, který zahrnuje všechny komponenty úlohy. Síťová infrastruktura je primární komponentou pro všechny úlohy v Azure. Vaše síťová infrastruktura musí být v souladu s vaší vysokou dostupností nebo architekturou zotavení po havárii. Zvažte následující faktory síťové infrastruktury:

• Data Guard poskytuje vysokou dostupnost a ve většině scénářů poskytuje dostatečnou podporu běžných selhání. Virtuální počítače můžete umístit do flexibilní orchestrace škálovacích sad virtuálních počítačů. Aby se snížila latence sítě, měly by se všechny služby v jednom řešení nacházet ve stejné zóně dostupnosti a služby by měly sdílet stejnou virtuální síť.

  Pro další ochranu můžete strategicky umístit virtuální počítače do samostatných zón dostupnosti místo jedné zóny dostupnosti. Tento přístup může zabránit výpadkům během selhání datacentra.

• Pro maximální ochranu můžete umístit sekundární databázi do jiné oblasti Azure než primární oblast databáze. Pokud chcete použít průběžné aktualizace, můžete použít ochranu Data Guard k implementaci globálního partnerského vztahu virtuálních sítí. Tento přístup použijte k použití aktualizací dat v sekundární oblasti soukromě prostřednictvím páteřní sítě Microsoftu. Prostředky komunikují přímo bez bran, dalších segmentů směrování nebo přenosu přes veřejný internet.

  Tato možnost sítě poskytuje připojení s vysokou šířkou pásma s nízkou latencí mezi partnerskými virtuálními sítěmi v různých oblastech. Pomocí globálního partnerského vztahu virtuálních sítí můžete připojit primární lokalitu k lokalitě pro zotavení po havárii v jiné oblasti prostřednictvím vysokorychlostní sítě.

Shrnutí odolnosti proti různým typům selhání

Scénář selhání	Scénář vysoké dostupnosti nebo zotavení po havárii Oracle v Azure	RPO/RTO
Selhání jedné komponenty, jako je hostitel, rack, chlazení, sítě nebo selhání napájení	Data Guard se dvěma uzly ve stejné flexibilní orchestraci škálovacích sad virtuálních počítačů ve stejném datacentru: – Chrání před selháním jedné instance. – Způsobí výpadek, pokud selže celé datové centrum.	Pokud použijete Pozorovatel pro rychlé převzetí služeb při selhání a MAX_AVAILABILITY nebo MAX_PROTECTION režim ochrany Data Guard: - RPO je nula. - RTO je menší než nebo rovno 2 min.
Selhání datacentra	Data Guard se dvěma uzly v samostatných zónách dostupnosti: – Chrání před selháním datacentra. – Způsobí výpadek, pokud selže celá oblast. – Vyžaduje více konfigurace převzetí služeb při selhání pro aplikační servery ke správě latence sítě.	– Cíl bodu obnovení je menší nebo roven 5 min. – RTO je menší než nebo rovno 5 min. Pokud používáte režim MAX_PERFORMANCE a režim MAX_AVAILABILITY pro ochranu Data Guard: - RPO je nula. – RTO je menší než nebo rovno 5 min.
Regionální selhání	Data Guard se dvěma uzly v samostatných oblastech Azure: - Chrání před regionálními selháními. – Vyžaduje více konfigurace převzetí služeb při selhání pro aplikační servery ke správě latence sítě.	Pokud používáte MAX_PERFORMANCE režim ochrany Data Guard: – Cíl bodu obnovení je větší nebo roven 10 min. – RTO je větší nebo rovno 15 min.
Všechny scénáře: selhání jedné komponenty, datacentra a oblasti	Zálohy, které se odesílají do jiné oblasti Azure: - Chraňte se před regionálními selháními. – Během převzetí služeb při selhání vyžaduje nastavení celého prostředí Azure v cílové oblasti.	- Cíl bodu obnovení je větší nebo roven 24 h. - RTO je větší nebo roven 4 h.

Další krok

Seznamte se s aspekty návrhu akcelerátoru cílových zón Oracle na virtuálních počítačích v podnikovém měřítku.

Pokyny zabezpečení pro akcelerátor cílových zón Oracle na virtuálních počítačích