Architektury pro databázi Oracle ve službě Azure Virtual Machines
Platí pro: ✔️ Virtuální počítače s Linuxem
Tento článek obsahuje informace o nasazení vysoce dostupné databáze Oracle v Azure. Tento průvodce se navíc podrobně seznámí s aspekty zotavení po havárii. Architektury popsané v tomto článku byly vytvořeny na základě nasazení zákazníků. Tato příručka platí jenom pro edice Enterprise Oracle Database.
Pokud se chcete dozvědět více o maximalizaci výkonu databáze Oracle, přečtěte si téma Návrh a implementace databáze Oracle v Azure.
Požadavky
- Znalost různých konceptů Azure, jako jsou zóny dostupnosti
- Oracle Database edice Enterprise 12c nebo novější
- Povědomí o dopadech licencování při používání řešení v tomto článku
Vysoká dostupnost pro databáze Oracle
Dosažení vysoké dostupnosti v cloudu je důležitou součástí plánování a návrhu každé organizace. Azure nabízí zóny dostupnosti a skupiny dostupnosti, které se mají použít v oblastech, kde nejsou zóny dostupnosti k dispozici. Další informace o tom, jak navrhnout cloud, najdete v tématu Možnosti dostupnosti pro Azure Virtual Machines.
Kromě nástrojů a nabídek nativních pro cloud poskytuje Oracle řešení pro vysokou dostupnost, která je možné nastavit v Azure:
Tato příručka popisuje referenční architektury pro každé z těchto řešení.
Při migraci nebo vytváření aplikací pro cloud doporučujeme používat vzory nativní pro cloud, jako je model opakování a model jističe. Další vzory, které by mohly pomoct zajistit větší odolnost aplikace, najdete v průvodci vzory návrhu cloudu.
Oracle RAC v cloudu
Oracle Real Application Cluster (RAC) je řešení, které zákazníkům pomáhá dosáhnout vysoké propustnosti díky tomu, že má mnoho instancí přistupující k jednomu úložišti databáze. Tento model představuje sdílenou architekturu. I když oracle RAC je možné použít pro vysokou dostupnost místně, samotný Oracle RAC se nedá použít k zajištění vysoké dostupnosti v cloudu. Oracle RAC chrání pouze před selháními na úrovni instance a ne proti selháním na úrovni racku nebo datacentra. Z tohoto důvodu Oracle doporučuje používat Oracle Data Guard s databází, ať už pro vysokou dostupnost, jednu instanci nebo RAC.
Zákazníci obecně vyžadují vysokou smlouvu SLA ke spouštění důležitých aplikací. Oracle v současné době necertifikuje ani nepodporuje Oracle RAC v Azure. Azure ale nabízí funkce, jako jsou zóny dostupnosti a časová období plánované údržby, které pomáhají chránit před selháními na úrovni instance. Kromě těchto nabídek můžete použít Oracle Data Guard, Oracle GoldenGate a Oracle Sharding pro zajištění vysokého výkonu a odolnosti. Tyto technologie můžou pomoct chránit databáze před selháními na úrovni racku, na úrovni datacentra a před geograficky politickými selháními.
Při spouštění databází Oracle v několika zónách dostupnosti pomocí Oracle Data Guard nebo GoldenGate můžete získat smlouvu SLA o dostupnosti 99,99 %. V oblastech Azure, kde ještě nejsou zóny dostupnosti, můžete použít skupiny dostupnosti a dosáhnout doby provozuschopnosti 99,95 %.
Poznámka:
Můžete mít cíl doby provozu, který je mnohem vyšší než smlouva SLA dostupnosti poskytovaná Microsoftem.
Zotavení po havárii pro databáze Oracle
Při hostování důležitých aplikací v cloudu je důležité navrhnout vysokou dostupnost a zotavení po havárii.
Pro oracle Database edice Enterprise je Oracle Data Guard užitečnou funkcí pro zotavení po havárii. Můžete nastavit pohotovostní instanci databáze ve spárované oblasti Azure a nastavit převzetí služeb při selhání ochrany Data Guard pro zotavení po havárii. Pro nulovou ztrátu dat doporučujeme nasadit kromě aktivní ochrany Data Guard instanci Oracle Data Guard Far Sync.
Pokud vaše aplikace povoluje latenci, zvažte nastavení instance Data Guard Far Sync v jiné zóně dostupnosti než primární databáze Oracle. Důkladně otestujte konfiguraci. Pomocí režimu maximální dostupnosti nastavte synchronní přenos souborů znovu do instance Far Sync. Tyto soubory se pak asynchronně přenesou do pohotovostní databáze.
Aplikace nemusí při nastavování instance Far Sync v jiné zóně dostupnosti v režimu maximální dostupnosti (synchronní) umožnit ztrátu výkonu . Pokud ne, můžete nastavit instanci Far Sync ve stejné zóně dostupnosti jako primární databázi. Pokud chcete přidat dostupnost, zvažte nastavení více instancí Far Sync blízko primární databáze a alespoň jednu instanci blízko pohotovostní databáze, pokud se role přepojuje.
Pokud používáte databáze Oracle edice Standard, existují řešení nezávislých výrobců softwaru, která umožňují nastavit vysokou dostupnost a zotavení po havárii, jako je pohotovostní režim DBVisit.
Referenční architektury
Oracle Data Guard
Oracle Data Guard zajišťuje vysokou dostupnost, ochranu dat a zotavení po havárii pro podniková data. Data Guard udržuje pohotovostní databáze jako transakční konzistentní kopie primární databáze. V závislosti na vzdálenosti mezi primární a sekundární databází a tolerance aplikace pro latenci můžete nastavit synchronní nebo asynchronní replikaci. Pokud primární databáze není dostupná kvůli plánovanému nebo neplánovanému výpadku, může Služba Data Guard přepnout libovolnou pohotovostní databázi na primární roli, což minimalizuje výpadky.
Při použití Oracle Data Guard můžete také otevřít sekundární databázi pro účely jen pro čtení. Tato konfigurace se nazývá Active Data Guard. Oracle Database 12c zavedl funkci nazvanou Instance Far Sync služby Data Guard. Tato instance umožňuje nastavit konfiguraci nulové ztráty dat databáze Oracle, aniž byste museli ohrozit výkon.
Poznámka:
Aktivní ochrana Data Guard vyžaduje další licencování. Tato licence se také vyžaduje pro použití funkce Far Sync. Obraťte se na zástupce Oracle a proberte důsledky licencování.
Oracle Data Guard s rychlým spuštěním převzetí služeb při selhání
Oracle Data Guard s rychlým spuštěním převzetí služeb při selhání (FSFO) může zajistit větší odolnost nastavením zprostředkovatele na samostatném počítači. Zprostředkovatel Data Guard i sekundární databáze spouští pozorovatele a sleduje výpadky primární databáze. Tento přístup umožňuje také redundanci v nastavení pozorovatele ochrany Data Guard.
S Oracle Database verze 12.2 a vyšší je také možné nakonfigurovat více pozorovatelů s jedinou konfigurací zprostředkovatele Oracle Data Guard. Toto nastavení poskytuje dodatečnou dostupnost v případě výpadku jednoho pozorovatele a sekundární databáze. Data Guard Broker je jednoduchý a dá se hostovat na relativně malém virtuálním počítači. Další informace o službě Data Guard Broker a jejích výhodách najdete v tématu Koncepty zprostředkovatele Oracle Data Guard.
Následující diagram představuje doporučenou architekturu pro použití Oracle Data Guard v Azure se zónami dostupnosti. Tato architektura umožňuje získat smlouvu SLA o provozu virtuálního počítače 99,99 %.
V předchozím diagramu klientský systém přistupuje k vlastní aplikaci s back-endem Oracle pomocí webu. Webový front-end je nakonfigurovaný v nástroji pro vyrovnávání zatížení. Webový front-end volá příslušný aplikační server pro zpracování práce. Aplikační server se dotazuje na primární databázi Oracle. Databáze Oracle se konfiguruje pomocí hyperthreaded paměti optimalizovaného pro virtuální počítač s omezenými virtuálními procesory jádra, aby se ušetřily náklady na licencování a maximalizoval výkon. Pro zajištění výkonu a vysoké dostupnosti se používá více disků úrovně Premium nebo Ultra (Spravované disky).
Databáze Oracle jsou umístěny v několika zónách dostupnosti pro zajištění vysoké dostupnosti. Každá zóna se skládá z jednoho nebo více datových center vybavených nezávislým napájením, chlazením a sítěmi. Aby se zajistila odolnost, nastaví se minimálně tři samostatné zóny ve všech povolených oblastech. Fyzické oddělení zón dostupnosti v rámci oblasti chrání data před selháními datového centra. Kromě toho jsou dva pozorovatelé FSFO nastaveni ve dvou zónách dostupnosti, aby zahájili databázi a převzali služby při selhání sekundární, když dojde k výpadku.
V tomto případě můžete nastavit jiné pozorovatele nebo pohotovostní databáze v jiné zóně dostupnosti AZ 1, než je zóna zobrazená v předchozí architektuře. Oracle Enterprise Manager (OEM) nakonec monitoruje databáze Oracle pro dobu provozu a výkon. Výrobce OEM také umožňuje generovat různé sestavy výkonu a využití.
V oblastech, kde nejsou zóny dostupnosti podporované, můžete pomocí skupin dostupnosti nasadit databázi Oracle vysoce dostupným způsobem. Skupiny dostupnosti umožňují dosáhnout doby provozu virtuálního počítače 99,95 %. Následující diagram představuje referenční architekturu tohoto použití:
Poznámka:
- Vzhledem k tomu, že se nasazuje jenom jedna instance OEM, nemusíte virtuální počítač Oracle Enterprise Manageru umístit do skupiny dostupnosti.
- Disky Úrovně Ultra se v současné době nepodporují v konfiguraci skupiny dostupnosti.
Oracle Data Guard Far Sync
Oracle Data Guard Far Sync poskytuje nulovou ochranu před únikem informací pro databáze Oracle. Tato funkce umožňuje chránit před ztrátou dat v případě selhání databázového počítače. Oracle Data Guard Far Sync je potřeba nainstalovat na samostatný virtuální počítač. Far Sync je jednoduchá instance Oracle, která má pouze řídicí soubor, soubor hesla, spfile a pohotovostní protokoly. Neexistují žádné datové soubory ani soubory protokolu znovu.
Pro nulovou ochranu před ztrátou dat musí existovat synchronní komunikace mezi primární databází a instancí Far Sync. Instance Far Sync přijímá znovu z primárního synchronním způsobem a okamžitě ji předá všem pohotovostním databázím asynchronním způsobem. Toto nastavení také snižuje režijní náklady na primární databázi, protože musí odesílat znovu pouze do instance Far Sync, nikoli do všech pohotovostních databází. Pokud instance Far Sync selže, data Guard automaticky použije asynchronní přenos do sekundární databáze z primární databáze, aby zachoval ochranu před téměř nulovou ztrátou dat. Kvůli větší odolnosti můžou zákazníci nasadit pro každou instanci databáze několik instancí Far Sync, včetně primárních a sekundárních instancí.
Následující diagram je architektura vysoké dostupnosti využívající Oracle Data Guard Far Sync:
V předchozí architektuře je instance Far Sync nasazená v jiné zóně dostupnosti jako instance databáze, která zajistí nulovou ztrátu dat a automatické převzetí služeb při selhání, pokud dojde k selhání zóny dostupnosti. V případech, kdy je aplikace citlivá na latenci, zvažte nasazení databáze a instance nebo instancí Far Sync ve stejné zóně dostupnosti ve skupině umístění bezkontaktní komunikace.
Následující diagram je architektura, která používá Oracle Data Guard FSFO a Far Sync k dosažení vysoké dostupnosti a zotavení po havárii:
Oracle GoldenGate
GoldenGate umožňuje výměnu a manipulaci s daty na úrovni transakcí mezi několika heterogenními platformami v rámci podniku. Přesouvá potvrzené transakce s integritou transakcí a minimální režií na stávající infrastrukturu. Její modulární architektura poskytuje flexibilitu při extrakci a replikaci vybraných záznamů dat, transakčních změn a změn jazyka DDL (Data Definition Language) v různých topologiích.
Oracle GoldenGate umožňuje nakonfigurovat databázi pro vysokou dostupnost tím, že poskytuje obousměrnou replikaci. Tento přístup umožňuje nastavit konfiguraci s více hlavními servery nebo aktivní-aktivní. Následující diagram představuje doporučenou architekturu pro nastavení Oracle GoldenGate active-active v Azure. V následující architektuře je databáze Oracle nakonfigurovaná pomocí virtuálního počítače optimalizovaného pro hyperthreaded paměť s omezenými virtuálními procesory jádra, aby se ušetřily náklady na licence a maximalizoval výkon. Architektura používá více disků Úrovně Premium nebo Ultra (spravovaných disků) k zajištění výkonu a dostupnosti.
Poznámka:
Podobnou architekturu je možné nastavit pomocí skupin dostupnosti v oblastech, kde nejsou aktuálně dostupné zóny dostupnosti.
Oracle GoldenGate má procesy, jako je extrakce, pumpa a replika , které vám pomůžou asynchronně replikovat data z jednoho databázového serveru Oracle do jiného. Tyto procesy umožňují nastavit obousměrnou replikaci, která zajistí vysokou dostupnost databáze, pokud dojde k výpadku na úrovni zóny dostupnosti.
V předchozím diagramu se proces extrakce spustí na stejném serveru jako databáze Oracle. Procesy datového čerpadla a repliky běží na samostatném serveru ve stejné zóně dostupnosti. Proces repliky se používá k příjmu dat z databáze v jiné zóně dostupnosti a potvrzení dat do databáze Oracle v její zóně dostupnosti. Podobně proces datového čerpadla odesílá data, která proces extrakce extrahuje do procesu Replikt v jiné zóně dostupnosti.
Zatímco předchozí diagram architektury znázorňuje procesy datového čerpadla a repliky nakonfigurované na samostatném serveru, můžete nastavit všechny procesy Oracle GoldenGate na stejném serveru na základě kapacity a využití serveru. Vždy si projděte sestavu AWR a metriky v Azure, abyste porozuměli vzoru využití vašeho serveru.
Při nastavování obousměrné replikace Oracle GoldenGate v různých zónách dostupnosti nebo v různých oblastech je důležité zajistit, aby latence mezi různými komponentami byla pro vaši aplikaci přijatelná. Latence mezi zónami dostupnosti a oblastmi se může lišit. Latence závisí na několika faktorech. Doporučujeme nastavit testy výkonu mezi vaší aplikační vrstvou a databázovou vrstvou v různých zónách dostupnosti nebo oblastech. Testy můžou potvrdit, že konfigurace splňuje požadavky na výkon vaší aplikace.
Aplikační vrstvu je možné nastavit ve vlastní podsíti a databázovou vrstvu je možné rozdělit do vlastní podsítě. Pokud je to možné, zvažte použití Aplikace Azure lication Gateway k vyrovnávání zatížení provozu mezi aplikačními servery. Application Gateway je robustní nástroj pro vyrovnávání zatížení webového provozu. Poskytuje spřažení relace založené na souborech cookie, které udržuje uživatelskou relaci na stejném serveru a minimalizuje konflikty v databázi. Alternativy ke službě Application Gateway jsou Azure Load Balancer a Azure Traffic Manager.
Shardování Oracle
Horizontální dělení je model datové vrstvy, který byl zaveden v Oracle 12.2. Umožňuje horizontálně rozdělit a škálovat data napříč nezávislými databázemi. Jedná se o architekturu typu share-nothing, kde je každá databáze hostovaná na vyhrazeném virtuálním počítači. Tento model umožňuje vysokou propustnost čtení a zápisu kromě odolnosti a vyšší dostupnosti.
Tento model eliminuje jednotlivé body selhání, zajišťuje izolaci chyb a umožňuje postupné upgrady bez výpadků. Výpadek jednoho horizontálního oddílu nebo selhání na úrovni datového centra nemá vliv na výkon ani dostupnost ostatních horizontálních oddílů v jiných datových centrech.
Horizontální dělení je vhodné pro aplikace OLTP s vysokou propustností, které si nemůžou dovolit žádné výpadky. U všech řádků se stejným klíčem horizontálního dělení je vždy zaručeno, že budou ve stejném horizontálním oddílu. Tato skutečnost zvyšuje výkon a poskytuje vysokou konzistenci. Aplikace, které používají horizontální dělení, musí mít dobře definovaný datový model a strategii distribuce dat, jako je konzistentní hodnota hash, rozsah, seznam nebo složená data. Strategie primárně přistupuje k datům pomocí klíče horizontálního dělení, například customerId nebo accountNum. Horizontální dělení také umožňuje ukládat konkrétní sady dat blíže ke koncovým zákazníkům, což pomáhá vyhovět vašim požadavkům na výkon a dodržování předpisů.
Doporučujeme replikovat horizontální oddíly pro zajištění vysoké dostupnosti a zotavení po havárii. Toto nastavení lze provést pomocí technologií Oracle, jako jsou Oracle Data Guard nebo Oracle GoldenGate. Jednotkou replikace může být horizontální oddíl, část horizontálního oddílu nebo skupina horizontálních oddílů. Výpadek nebo zpomalení jednoho nebo více horizontálních oddílů nemá vliv na dostupnost horizontálně dělené databáze.
V případě vysoké dostupnosti je možné horizontální oddíly pohotovostního režimu umístit do stejné zóny dostupnosti, ve které jsou umístěné primární horizontální oddíly. V případě zotavení po havárii můžou být pohotovostní horizontální oddíly umístěny v jiné oblasti. Můžete také nasadit horizontální oddíly ve více oblastech, které budou obsluhovat provoz v těchto oblastech. Další informace o konfiguraci vysoké dostupnosti a replikace horizontálně dělené databáze najdete v tématu Vysoká dostupnost na úrovni horizontálních oddílů.
Shardování Oracle se primárně skládá z následujících komponent. Další informace najdete v tématu Přehled horizontálního dělení Oracle:
Katalog horizontálních oddílů. Speciální databáze Oracle, která je trvalým úložištěm pro všechna konfigurační data databáze horizontálních oddílů. Všechny změny konfigurace, jako je přidání nebo odebrání horizontálních oddílů, mapování dat a DDLs v databázi horizontálních oddílů, se inicialují v katalogu horizontálních oddílů. Katalog horizontálních oddílů také obsahuje primární kopii všech duplicitních tabulek v databázi SDB.
Katalog horizontálních oddílů používá materializovaná zobrazení k automatické replikaci změn duplicitních tabulek ve všech horizontálních oddílech. Databáze katalogu horizontálních oddílů funguje také jako koordinátor dotazů používaný ke zpracování dotazů a dotazů s více horizontálními oddíly, které nezadávají klíč horizontálního dělení.
Jako osvědčený postup doporučujeme používat Oracle Data Guard se zónami dostupnosti nebo skupinami dostupnosti pro vysokou dostupnost katalogu horizontálních oddílů. Dostupnost katalogu horizontálních oddílů nemá žádný vliv na dostupnost horizontálně dělené databáze. Výpadek v katalogu horizontálních oddílů má vliv pouze na operace údržby a dotazy s více horizontálními oddíly během krátkého období, kdy se převzetí služeb při selhání služby Data Guard dokončí. SDB nadále směruje a spouští online transakce. Výpadek katalogu na ně nemá vliv.
Ředitelé horizontálních oddílů. Zjednodušené služby, které je potřeba nasadit v každé oblasti nebo zóně dostupnosti, ve které se nacházejí horizontální oddíly. Ředitelé horizontálních oddílů jsou globální správci služeb nasazení v kontextu shardování Oracle. Pro zajištění vysoké dostupnosti doporučujeme nasadit alespoň jeden adresář horizontálních oddílů v každé zóně dostupnosti, ve které existují horizontální oddíly.
Při počátečním připojení k databázi nastaví adresář horizontálních oddílů informace o směrování a ukládá informace do mezipaměti pro následné požadavky, které obcházejí adresář horizontálních oddílů. Po vytvoření relace s horizontálním oddílem se všechny dotazy SQL a dynamické správy podporují a spouštějí v oboru daného horizontálního oddílu. Toto směrování je rychlé a používá se pro všechny úlohy OLTP, které provádějí transakce uvnitř horizontálních oddílů. Doporučujeme použít přímé směrování pro všechny úlohy OLTP, které vyžadují nejvyšší výkon a dostupnost. Mezipaměť směrování se automaticky aktualizuje, když se horizontální oddíl stane nedostupným nebo dojde ke změnám topologie horizontálního dělení.
Pro vysoce výkonné směrování závislé na datech oracle doporučuje při přístupu k datům v horizontálně dělené databázi použít fond připojení. Fondy připojení Oracle, knihovny specifické pro jazyk a ovladače podporují shardování Oracle. Další informace najdete v tématu Přehled horizontálního dělení Oracle.
Globální služba. Globální služba se podobá běžné databázové službě. Kromě všech vlastností databázové služby má globální služba vlastnosti pro horizontálně dělené databáze. Mezi tyto vlastnosti patří spřažení oblastí mezi klienty a horizontálními oddíly a tolerance prodlevy replikace. Ke čtení a zápisu dat do a z horizontálně dělené databáze je potřeba vytvořit pouze jednu globální službu. Při použití služby Active Data Guard a nastavení replik horizontálních oddílů jen pro čtení můžete vytvořit další globální službu pro úlohy jen pro čtení. Klient se může k databázi připojit pomocí těchto globálních služeb.
Databáze horizontálních oddílů. Databáze horizontálních oddílů jsou vaše databáze Oracle. Každá databáze se replikuje pomocí Oracle Data Guard v konfiguraci zprostředkovatele s povolenou funkcí FSFO. U každého horizontálního oddílu nemusíte nastavovat převzetí služeb při selhání a replikaci služby Data Guard. Tento aspekt se automaticky nakonfiguruje a nasadí při vytvoření sdílené databáze. Pokud konkrétní horizontální oddíl selže, sdílení Oracle převezme služby při selhání připojení k databázi z primárního do pohotovostního režimu.
Horizontálně dělené databáze Oracle můžete nasadit a spravovat pomocí dvou rozhraní: grafické uživatelské rozhraní cloudového ovládacího prvku Oracle Enterprise Manager a nástroj příkazového GDSCTL řádku. Pomocí řízení cloudu můžete dokonce monitorovat různé horizontální oddíly pro zajištění dostupnosti a výkonu. Příkaz GDSCTL DEPLOY automaticky vytvoří horizontální oddíly a příslušné naslouchací procesy. Kromě toho tento příkaz automaticky nasadí konfiguraci replikace použitou pro vysokou dostupnost horizontálních oddílů určenou správcem.
Existují různé způsoby horizontálního dělení databáze:
- Horizontální dělení spravované systémem: Automatické distribuce napříč horizontálními oddíly pomocí dělení
- Uživatelem definované horizontální dělení: Umožňuje určit mapování dat na horizontální oddíly, které dobře fungují, pokud existují zákonné požadavky nebo požadavky na lokalizaci dat.
- Složené horizontální dělení: Kombinace shardování spravovaného systémem a uživatelem definovaného horizontálního dělení pro různé horizontální prostory
- Podčásti tabulky: Podobá se běžné dělené tabulce
Další informace naleznete v tématu Metody horizontálního dělení.
Horizontálně dělené databáze vypadá jako jednoúčelová databáze pro aplikace a vývojáře. Při migraci na horizontálně dělenou databázi pečlivě naplánujte, abyste pochopili, které tabulky se duplikují a které horizontálně dělené.
Duplicitní tabulky jsou uložené ve všech horizontálních oddílech, zatímco horizontálně dělené tabulky se distribuují napříč různými horizontálními oddíly. Doporučujeme duplikovat malé a dimenzionální tabulky a distribuovat nebo horizontálně rozdělit tabulky faktů. Data je možné načíst do horizontálně dělené databáze buď pomocí katalogu horizontálních oddílů jako centrálního koordinátora, nebo spuštěním datového čerpadla v každém horizontálním oddílu. Další informace naleznete v tématu Migrace dat do horizontálně dělené databáze.
Shardování Oracle pomocí ochrany Data Guard
Oracle Data Guard lze použít k horizontálnímu dělení pomocí metod spravovaných systémem, definovaných uživatelem a složených horizontálních oddílů.
Následující diagram je referenční architektura pro horizontální dělení Oracle s Oracle Data Guard, která se používá k zajištění vysoké dostupnosti jednotlivých horizontálních oddílů. Diagram architektury znázorňuje složenou metodu horizontálního dělení. Diagram architektury se pravděpodobně liší pro aplikace s různými požadavky na umístění dat, vyrovnávání zatížení, vysokou dostupnost a zotavení po havárii. Aplikace můžou pro horizontální dělení použít jinou metodu. Shardování Oracle umožňuje tyto požadavky splnit a škálovat horizontálně a efektivně díky těmto možnostem. Podobnou architekturu je možné nasadit i pomocí Oracle GoldenGate.
Shardování spravované systémem je nejjednodušší konfigurovat a spravovat. Uživatelem definované horizontální dělení nebo složené horizontální dělení jsou vhodné pro scénáře, kdy jsou vaše data a aplikace geograficky distribuované nebo ve scénářích, kde potřebujete mít kontrolu nad replikací jednotlivých horizontálních oddílů.
V předchozí architektuře se složené horizontální dělení používá k geografické distribuci dat a horizontálnímu horizontálnímu navýšení kapacity aplikačních vrstev. Složené horizontální dělení je kombinací systémově spravovaného a uživatelem definovaného horizontálního dělení a poskytuje tak výhodu obou metod. V předchozím scénáři se data nejprve horizontálně rozdělují mezi více prostorů horizontálních oddílů oddělených oblastí. Pak se data dále rozdělí pomocí konzistentní hodnoty hash napříč několika horizontálními oddíly v prostoru horizontálních oddílů.
Každý shardspace obsahuje více skupin horizontálních oddílů. Každá skupina horizontálních oddílů má více horizontálních oddílů a je jednotkou replikace. Každá skupina horizontálních oddílů obsahuje všechna data v prostoru horizontálních oddílů. Shardgroups A1 a B1 jsou primární skupiny horizontálních oddílů, zatímco skupiny horizontálních oddílů A2 a B2 jsou pohotovostní. Můžete se rozhodnout, že jednotlivé horizontální oddíly budou jednotkou replikace, nikoli skupinu horizontálních oddílů.
V předchozí architektuře je globální správce služeb (GSM)/shardový adresář nasazený ve všech zónách dostupnosti pro zajištění vysoké dostupnosti. Doporučujeme nasadit alespoň jeden adresář GSM/shard na datové centrum nebo oblast. Kromě toho se instance aplikačního serveru nasadí do každé zóny dostupnosti, která obsahuje skupinu horizontálních oddílů. Toto nastavení umožňuje aplikaci zachovat latenci mezi aplikačním serverem a nízkou úrovní skupiny horizontálních oddílů. Pokud databáze selže, aplikační server ve stejné zóně jako pohotovostní databáze může zpracovávat požadavky, jakmile dojde k přechodu role databáze. Aplikace Azure lication Gateway a adresář horizontálních oddílů sledují latenci požadavků a odpovědí a odpovídajícím způsobem směrují požadavky.
Z hlediska aplikace klientský systém odešle požadavek na Aplikace Azure lication Gateway nebo jiné technologie vyrovnávání zatížení v Azure, které požadavek přesměruje do oblasti, která je nejblíže klientovi. Aplikace Azure lication Gateway také podporuje rychlé relace, takže všechny požadavky přicházející ze stejného klienta se směrují na stejný aplikační server. Aplikační server používá sdružování připojení v ovladačích přístupu k datům. Tato funkce je dostupná v ovladačích, jako jsou JDBC, ODP.NET a OCI. Ovladače můžou rozpoznávat klíče horizontálního dělení zadané v rámci požadavku. Fond univerzálního připojení Oracle (UCP) pro klienty JDBC umožňuje klientům aplikací, jako jsou Apache Tomcat a IIS, pracovat s horizontálním dělením Oracle. Další informace najdete v tématu Přehled sdíleného fondu UCP pro horizontální dělení databáze.
Během počátečního požadavku se aplikační server připojí k adresáři horizontálních oddílů ve své oblasti, aby získal informace o směrování pro horizontální oddíl, do kterého je potřeba požadavek směrovat. Na základě předaného klíče horizontálního dělení směruje adresář aplikační server do příslušného horizontálního oddílu. Aplikační server tyto informace ukládá do mezipaměti sestavením mapy a pro následné požadavky obchází adresář horizontálních oddílů a směruje požadavky přímo do horizontálního oddílu.
Shardování Oracle pomocí GoldenGate
Následující diagram je referenční architektura pro shardování Oracle s Oracle GoldenGate pro vysokou dostupnost jednotlivých horizontálních oddílů v jednotlivých oblastech. Na rozdíl od předchozí architektury tato architektura zobrazuje vysokou dostupnost pouze v jedné oblasti Azure s několika zónami dostupnosti. Horizontálně dělenou databázi s více oblastmi můžete nasadit podobně jako v předchozím příkladu pomocí Oracle GoldenGate.
Předchozí referenční architektura používá metodu horizontálního dělení spravovanou systémem k horizontálnímu dělení dat. Vzhledem k tomu, že replikace Oracle GoldenGate probíhá na úrovni bloků dat, je možné polovinu dat replikovaných do jednoho horizontálního oddílu replikovat do jiného horizontálního oddílu. Druhá polovina se dá replikovat do jiného horizontálního oddílu.
Způsob replikace dat závisí na faktoru replikace. S faktorem replikace dvou máte ve skupině horizontálních oddílů dvě kopie každého bloku dat ve třech horizontálních oddílech. Podobně s faktorem replikace tří a tří horizontálních oddílů ve skupině horizontálních oddílů se všechna data v každém horizontálním oddílu replikují do každého druhého horizontálního oddílu ve skupině horizontálních oddílů. Každý horizontální oddíl ve skupině horizontálních oddílů může mít jiný faktor replikace. Toto nastavení vám pomůže efektivně definovat návrh vysoké dostupnosti a zotavení po havárii v rámci skupiny horizontálních oddílů a napříč několika skupinami horizontálních oddílů.
V předchozí architektuře obě skupiny horizontálních oddílů A a shardgroup B obsahují stejná data, ale nacházejí se v různých zónách dostupnosti. Pokud obě skupiny horizontálních oddílů A i shardgroup B mají stejný faktor replikace ze tří, každý řádek nebo blok horizontální tabulky se replikuje šestkrát napříč dvěma skupinami horizontálních oddílů. Pokud má skupina horizontálních oddílů A faktor replikace tři a skupina horizontálních oddílů B má faktor replikace dvou, každý řádek nebo blok dat se replikuje pětkrát napříč dvěma skupinami horizontálních oddílů.
Toto nastavení zabraňuje ztrátě dat, pokud dojde k selhání na úrovni instance nebo zóny dostupnosti. Aplikační vrstva dokáže číst a zapisovat do každého horizontálního oddílu. Aby se minimalizovaly konflikty, oracle Sharding určuje hlavní blok dat pro každý rozsah hodnot hash. Tato funkce zajišťuje, že se požadavky na zápis pro konkrétní blok dat směrují na odpovídající blok dat. Oracle GoldenGate navíc poskytuje automatické zjišťování konfliktů a řešení problémů, které by mohly nastat. Další informace a omezení implementace GoldenGate s Oracle Sharding naleznete v tématu Použití Oracle GoldenGate s horizontálně dělenou databází.
V předchozí architektuře se do každé zóny dostupnosti nasadí adresář GSM/shard pro zajištění vysoké dostupnosti. Doporučujeme nasadit alespoň jeden adresář GSM/shard na datové centrum nebo oblast. Instance aplikačního serveru se nasadí do každé zóny dostupnosti, která obsahuje skupinu horizontálních oddílů. Toto nastavení umožňuje aplikaci zachovat latenci mezi aplikačním serverem a nízkou úrovní skupiny horizontálních oddílů. Pokud databáze selže, aplikační server ve stejné zóně jako pohotovostní databáze může zpracovávat požadavky po přechodu role databáze. Aplikace Azure lication Gateway a adresář horizontálních oddílů sledují latenci požadavků a odpovědí a odpovídajícím způsobem směrují požadavky.
Z hlediska aplikace klientský systém odešle požadavek na Aplikace Azure lication Gateway nebo jiné technologie vyrovnávání zatížení v Azure, které požadavek přesměruje do oblasti, která je nejblíže klientovi. Aplikace Azure lication Gateway také podporuje rychlé relace, takže všechny požadavky přicházející ze stejného klienta se směrují na stejný aplikační server. Aplikační server používá sdružování připojení v ovladačích přístupu k datům. Tato funkce je dostupná v ovladačích, jako jsou JDBC, ODP.NET a OCI. Ovladače můžou rozpoznávat klíče horizontálního dělení zadané v rámci požadavku. Fond univerzálního připojení Oracle (UCP) pro klienty JDBC umožňuje klientům aplikací, jako jsou Apache Tomcat a IIS, pracovat s horizontálním dělením Oracle.
Během počátečního požadavku se aplikační server připojí k adresáři horizontálních oddílů ve své oblasti, aby získal informace o směrování pro horizontální oddíl, do kterého je potřeba požadavek směrovat. Na základě předaného klíče horizontálního dělení směruje adresář aplikační server do příslušného horizontálního oddílu. Aplikační server tyto informace ukládá do mezipaměti sestavením mapy a pro následné požadavky obchází adresář horizontálních oddílů a směruje požadavky přímo do horizontálního oddílu.
Opravy a údržba
Když nasadíte úlohy Oracle do Azure, Microsoft se postará o všechny opravy na úrovni operačního systému hostitele. Společnost Microsoft předem sdělí zákazníkům veškerou plánovanou údržbu na úrovni operačního systému. Dva servery ze dvou různých zón dostupnosti nejsou nikdy opraveny současně. Další informace o údržbě a opravách virtuálních počítačů najdete v tématu Možnosti dostupnosti pro virtuální počítače Azure.
Opravy operačního systému virtuálního počítače je možné automatizovat pomocí služby Azure Automation Update Management. Opravy a údržba databáze Oracle je možné automatizovat a naplánovat pomocí Azure Pipelines nebo azure Automation Update Management, aby se minimalizovaly výpadky. Další informace o průběžném doručování a modrých/zelených nasazeních najdete v tématu Techniky progresivní expozice.
Aspekty architektury a návrhu
- Zvažte použití hyperthreaded paměti optimalizovaného pro virtuální počítač s omezenými jádrovými virtuálními procesory pro virtuální počítač Oracle Database, abyste ušetřili náklady na licencování a maximalizovali výkon. Pro zajištění výkonu a dostupnosti použijte více disků Úrovně Premium nebo Ultra (spravované disky).
- Když používáte spravované disky, název disku nebo zařízení se může při restartování změnit. Místo názvu doporučujeme místo názvu použít UUID zařízení, abyste zajistili, že připojení potrvají v spritu restartování. Další informace naleznete v tématu Přidání nového systému souborů do /etc/fstab.
- K dosažení vysoké dostupnosti v oblasti použijte zóny dostupnosti.
- Zvažte použití disků úrovně Ultra, pokud jsou dostupné nebo prémiové disky pro vaši databázi Oracle.
- Zvažte nastavení pohotovostní databáze Oracle v jiné oblasti Azure pomocí Oracle Data Guardu.
- Zvažte použití skupin umístění bezkontaktní komunikace, abyste snížili latenci mezi vaší aplikací a databázovou vrstvou.
- Maximální šířka pásma sítě virtuálních počítačů Azure je (obvykle) vyšší než maximální propustnost disku ve stejné SKU. Vyšší propustnost můžete dosáhnout u stejné skladové položky virtuálního počítače nebo použít menší skladovou položku virtuálního počítače pomocí vysoce výkonného síťového úložiště s nízkou latencí, jako je Azure NetApp Files. pro databázi.
- Nastavte Oracle Enterprise Manager pro správu, monitorování a protokolování.
- Zvažte použití automatické správy úložiště Oracle pro zjednodušenou správu úložiště pro vaši databázi.
- Využijte Azure Pipelines ke správě oprav a aktualizací databáze bez jakýchkoli výpadků.
- Upravte kód aplikace přidáním nativních cloudových vzorů, které můžou vaší aplikaci pomoct být odolnější. Zvažte vzory, jako je vzor opakování, model jističe a další definované v průvodci vzory návrhu cloudu.
Další kroky
Projděte si následující referenční články Oracle, které platí pro váš scénář.