Sdílet prostřednictvím

Architektury pro databázi Oracle ve službě Azure Virtual Machines

  • Článek

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. Tyto architektury byly vytvořeny na základě zákaznických nasazení. 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
  • Definované požadavky RPO a RTO

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.

Pro replikaci dat s dlouhou vzdáleností se doporučuje využít Far Sync. Far Sync je funkce Oracle Active Data Guard.

Poznámka:

Pokud povolíte Far Sync, potřebujete licenci Active Data Guard. Obraťte se na zástupce Oracle a prodiskutujte důsledky licencování.

Oracle Far Sync řeší dlouhou vzdálenost mezi primární a sekundární databází tím, že zavádí zprostředkující server známý jako instance Far Sync. Tento server přijímá znovu data z primární databáze a pak je předá do pohotovostní databáze. Instance Far Sync je tedy umístěna blíže k primární instanci, aby se zkrátila doba komunikace. Server Far Sync pak asynchronně přenese data znovu do sekundární databáze.

Poznámka:

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 nebo Tessell.

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.

Oracle Data Guard s rychlým spuštěním převzetí služeb při selhání

Ochranu Data Guard je možné nasadit pomocí rychlého spuštění převzetí služeb při selhání (FSFO). Rychlé spuštění převzetí služeb při selhání je funkce poskytovaná v rámci konfigurace zprostředkovatele Data Guard. Tato funkce umožňuje automatické převzetí služeb při selhání v případě selhání. Výchozí čas, kdy zákazníci používají, jsou 30 sekund, ale můžete je upravit podle vašich požadavků. To se nazývá OperationTimeout je součástí vlastností ochrany Data Guard, které definujete během nasazení.

Jak ochrana Data Guard funguje s touto vlastností

Úkolem Ochrany dat je monitorovat nepřetržitě stav a stav primární a sekundární databáze. Jakmile povolíte službu FSFO (Fast-Start-Failover), aktivuje se proces pozorovatele a v pravidelných intervalech zkontroluje stav, aby se zajistila vysoká dostupnost v daném okamžiku.

Pokud se primární databáze stane nedostupnou, pozorovatel a zprostředkovatel ochrany Data Guard toto přerušení zjistí. Parametr OperationTimeout 30 sekund tedy určuje, jak dlouho má Zprostředkovatel čekat na odpověď z primární databáze před provedením jakékoli další akce.

Výsledkem je, že pokud primární nereaguje v rámci tohoto 30sekundového okna, pozorovatel předpokládá, že primární je nedostupný a zahájí proces převzetí služeb při selhání.

Zprostředkovatel okamžitě propaguje pohotovostní databázi na primární stav, přepne role a zajistí, aby aplikace rychle pokračovala v pohotovostním režimu.

Během této doby Zprostředkovatel také zajišťuje, že transakce jsou aktuální v pohotovostním režimu. V režimu, který nakonfigurujete, může být maximální dostupnost nebo maximální ochrana, synchronní replikace by poskytovala minimální až nulovou ztrátu dat. 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 v případě selhání zahájili převzetí služeb při selhání sekundární databázi. Jakmile dojde k převzetí služeb při selhání a vaše předchozí primární databáze bude opět dostupná, můžete ji znovu obnovit. Tento proces usnadňuje zprostředkovatel ochrany Data Guard.

Pokud je primární databáze nakonec nedostupná kvůli plánovanému nebo neplánovanému výpadku, přepne data Guard do pohotovostní databáze nebo převezme služby při selhání.

Tato funkce může poskytovat další odolnost nastavením pozorovatele na samostatném virtuálním počítači. Tím nasadíte pozorovatele na jednoduchý virtuální počítač. Tento přístup umožňuje vysokou dostupnost a odolnost.

S Oracle Database verze 12.2 a vyšší je také možné nakonfigurovat více pozorovatelů s jedinou konfigurací zprostředkovatele Oracle Data Guard. Poskytuje dodatečnou dostupnost v případě výpadku jednoho pozorovatele a sekundární databáze. 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 znázorňuje instalaci Oracle Data Guard bez vzdálené synchronizace s dobou obnovení kratší než 5 minut.

Diagram znázorňující architekturu Oracle Data Guard

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 v případě selhání zahájili převzetí služeb při selhání sekundární databázi.

Poznámka:

Pokud plánujete nasazení symetrické ochrany Data Guard, mějte na paměti, že v zóně dostupnosti budete potřebovat jednoho dalšího pozorovatele.

Kromě toho důrazně doporučujeme nasadit Oracle Enterprise Manager, abyste měli přehled o databázové vrstvě. Azure Monitor se doporučuje nasadit s následujícími metrikami: Monitorujte disky:

  • Procento spotřebovaného počtu vstupně-výstupních operací disku s operačním systémem
  • Procento spotřebovaného počtu vstupně-výstupních operací za sekundu datového disku
  • Bajty čtení datového disku za sekundu
  • Datový disk zapisuje bajty za sekundu
  • Hloubka fronty disku
  • Šířka pásma disku v % na logickou jednotku

Kromě výše uvedených možností důrazně doporučujeme povolit také přehledy virtuálních počítačů.

Virtuální počítač se vybere na základě vašeho posouzení AWR. Další informace najdete v tématu Plánování kapacity Oracle. Důrazně doporučujeme využít omezené virtuální procesory jádra, abyste ušetřili náklady na licencování a maximalizovali výkon.

Volba typu disku závisí na výstupu posouzení AWR.

Jak už bylo zmíněno výše, Je to funkce, která se převážně používá ve scénářích, kdy replikujete mezi oblastmi, které překračují dlouhé vzdálenosti. Odkazem na tento scénář poskytuje Oracle Active Data Guard Far Sync funkci nulové ochrany dat pro databáze Oracle. Instance Oracle Far Sync musí být nainstalovaná na samostatném virtuálním počítači.

Ssd úrovně Premium v2 nejsou podporovány pro soubory odkazující na operační systém. Další informace najdete v tématu Nasazení SSD úrovně Premium v2.

Jak se používá cíl služby Azure Premium Files pro zálohování. Toto řešení je nejvýkonnější. Jako cíl zálohování můžete použít také Azure Blob Storage. Vždy se ujistěte, že otestujete, která možnost vám nejlépe vyhovuje. Navštivte také strategie zálohování databáze Oracle.

Oracle Data Guard Far Sync

Jak už bylo zmíněno výše, Je to funkce, která se převážně používá ve scénářích, kdy replikujete mezi oblastmi, které překračují dlouhé vzdálenosti. Při odkazování na tento scénář poskytuje Oracle Far Sync funkci ochrany bez ztráty dat pro databáze Oracle. Instance Oracle Far Sync musí být nainstalovaná na samostatném virtuálním počítači.

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, služba Active Data Guard automaticky použije asynchronní přenos do sekundární databáze z primární databáze, aby zachovala téměř nulovou ochranu před 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, která používá Oracle Active Data Guard FSFO a Far Sync k dosažení vysoké dostupnosti a zotavení po havárii:

Diagram znázorňující Databázi Oracle využívající Far Sync v konfiguraci Active Data Guard napříč oblastmi

Poznámka:

Pokud plánujete nasazení symetrické far sync, mějte na paměti, že ve druhé oblasti budete potřebovat jednu další instanci Far Sync.

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 vícesměrovou nebo aktivní konfiguraci, která vyžaduje povědomí na úrovni aplikace. Následující diagram představuje doporučenou architekturu pro nastavení Oracle GoldenGate active-active v Azure. V následující architektuře byla 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.

Diagram znázorňující databázi Oracle Database využívající zóny dostupnosti s nástrojem Data Guard Broker – FSFO

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 hlavní 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řipojování 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ího dělení. 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.

Diagram znázorňující horizontální dělení Oracle Database pomocí zón dostupnosti s nástrojem Data Guard Broker – FSFO

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 geodistribuci dat a horizontálně horizontálně navyšovat kapacitu 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.

Diagram znázorňující horizontální dělení Oracle Database pomocí zón dostupnosti se 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.
  • Úvod do Oracle Data Guardu
  • 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ář.