referenční architektury pro Oracle Database edice Enterprise v Azure

Platí pro: : Heavy_check_mark: virtuální počítače se systémem Linux

V této příručce najdete informace o nasazení databáze Oracle s vysokou dostupností v Azure. Kromě toho tato příručka komentáře na požadavky na zotavení po havárii. Tyto architektury se vytvořily na základě zákaznického nasazení. tato příručka platí jenom pro Oracle Database edice Enterprise.

Pokud vás zajímá více o maximalizaci výkonu vaší databáze Oracle, přečtěte si téma architekt a Oracle DB.

Předpoklady

  • Rozumíte různým konceptům Azure, jako jsou zóny dostupnosti .
  • spouštíte Oracle Database edice Enterprise 12c nebo novější.
  • Víte, že máte na paměti vliv na 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. Microsoft Azure nabízí zóny dostupnosti a skupiny dostupnosti (budou použity v oblastech, kde jsou zóny dostupnosti k dispozici). Přečtěte si další informace o správě dostupnosti virtuálních počítačů pro návrh pro Cloud.

Kromě nativních nástrojů a nabídek cloudu poskytuje Oracle řešení pro vysokou dostupnost, jako je Oracle data Guard, Ochrana dat s FSFO, horizontálního dělenía GoldenGate , která se dají nastavit v Azure. Tento průvodce popisuje referenční architektury pro každé z těchto řešení.

Nakonec při migraci nebo vytváření aplikací pro Cloud je důležité upravit kód aplikace a přidat vzory nativní pro Cloud, jako je vzor opakování a vzor přerušení okruhu. Další vzory definované v Průvodci návrhem cloudových vzorů můžou přispět k vyšší odolnosti vaší aplikace.

Oracle RAC v cloudu

Oracle Real Application cluster (RAC) je řešení od Oracle, které zákazníkům umožňuje dosáhnout vysoké propustnosti tím, že má mnoho instancí přístup k jednomu úložišti databáze (Shared-All Pattern). I když se dá Oracle RAC použít i pro místní vysokou dostupnost, nedá se samotný Oracle RAC použít k zajištění vysoké dostupnosti v cloudu, protože chrání jenom proti selháním na úrovni instance a ne proti selháním na úrovni skříně nebo datového centra. Z tohoto důvodu Oracle doporučuje použít pro vysokou dostupnost databáze Oracle data Guard (bez ohledu na to, jestli jde o jedinou instanci nebo certifikát RAC). Zákazníci obecně vyžadují vysokou smlouvu SLA pro provozování důležitých aplikací. Oracle RAC není v současné době v Azure certifikovaný ani podporovaný. Azure ale nabízí funkce, jako je Azure, nabízí Zóny dostupnosti a plánovaná časová období údržby, která chrání před selháním na úrovni instance. Kromě toho můžou zákazníci využívat technologie, jako je Oracle data Guard, Oracle GoldenGate a Oracle horizontálního dělení pro zajištění vysokého výkonu a odolnosti díky ochraně jejich databází před rackem a i geograficky neznámým selháním.

Při spouštění databází Oracle v různých zónách dostupnosti ve spojení s Oracle data Guard nebo GoldenGate můžou zákazníci získat smlouvu SLA o provozu 99,99%. V oblastech Azure, kde se ještě nevyskytují zóny dostupnosti, můžou zákazníci používat skupiny dostupnosti a získat smlouvu SLA pro dobu provozu 99,95%.

Poznámka: je možné, že máte cíl provozu, který je mnohem vyšší než smlouva SLA pro dobu provozu poskytovanou společností Microsoft.

Zotavení po havárii pro databáze Oracle

Při hostování důležitých podnikových aplikací v cloudu je důležité navrhovat pro vysokou dostupnost a zotavení po havárii.

pro Oracle Database edice Enterprise je pro zotavení po havárii užitečná funkce Oracle Data Guard. Můžete nastavit pohotovostní instanci databáze v spárované oblasti Azure a nastavit převzetí služeb při selhání pro ochranu dat pro zotavení po havárii. U nulových ztrát dat doporučujeme kromě aktivní ochrany dat použít i nasazovat instanci Oracle data Guard Far Sync.

Zvažte nastavení instance data Guard Far Sync v jiné zóně dostupnosti než v primární databázi Oracle, pokud vaše aplikace povoluje latenci (vyžaduje se důkladné testování). Použijte režim maximální dostupnosti k nastavení synchronního přenosu vašich souborů opětovného navýšení na instanci synchronizace. Tyto soubory se pak přenesou asynchronně do pohotovostní databáze.

Pokud vaše aplikace nedovolí ztrátě výkonu při nastavování daleko synchronizované instance v jiné zóně dostupnosti v režimu maximální dostupnosti (synchronní), můžete nastavit skupinu ve stejné zóně dostupnosti jako primární databázi. V případě, že máte k dispozici dostupnost, zvažte nastavení více instancí s úzkým synchronním přechodem na primární databázi a alespoň jednu instanci blízko do pohotovostní databáze (Pokud se role přecházejí). Přečtěte si další informace o Oracle data Guard – Far Sync v tomto dokumentu White paper pro Oracle Active Data Guard – na nejvyšší synchronizaci.

pokud používáte databáze Oracle edice Standard, je k dispozici řešení ISV, jako je například pohotovostní DBVisit, které vám umožní nastavit vysokou dostupnost a zotavení po havárii.

Referenční architektury

Oracle Data Guard

Oracle data Guard zajišťuje vysokou dostupnost, ochranu dat a zotavení po havárii pro podniková data. Ochrana dat uchovává pohotovostní databáze jako transakční konzistentní kopie primární databáze. V závislosti na vzdálenosti mezi primárními a sekundárními databázemi a odolností aplikace pro latenci můžete nastavit synchronní nebo asynchronní replikaci. Pokud je primární databáze nedostupná z důvodu plánovaného nebo neplánovaného výpadku, může ochrana dat přepnout všechny pohotovostní databáze na primární roli a minimalizovat prostoje.

Pokud používáte Oracle data Guard, můžete také otevřít sekundární databázi pro účely jen pro čtení. Tato konfigurace se nazývá aktivní ochrana dat. Oracle Database 12c zavedl funkci nazvanou data Guard – instance synchronizace. Tato instance umožňuje nastavit nulovou konfiguraci ztráty dat vaší databáze Oracle bez nutnosti narušit výkon.

Poznámka

Aktivní ochrana dat vyžaduje další licencování. Tato licence je také nutná k použití funkce Far Sync. Připojte se k vašemu zástupci Oracle a proberte případné důsledky k licencování.

Oracle data Guard s FSFO

Oracle data Guard s Fast-Start převzetí služeb při selhání (FSFO) může poskytovat další odolnost tím, že na samostatném počítači Nastaví zprostředkovatele. Zprostředkovatel ochrany dat a sekundární databáze spouštějí pozorovatele a sledují primární databázi za výpadky. To umožňuje také redundanci v instalaci pozorovatele data Guard.

U Oracle Database verze 12,2 a vyšší je také možné nakonfigurovat více pozorovatelů s jednou konfigurací zprostředkovatele ochrany dat Oracle. Tato instalace poskytuje dodatečnou dostupnost v případě výpadku jednoho pozorovatele a sekundárního databázového prostředí. Zprostředkovatel ochrany dat je odlehčený a může být hostovaný na relativně malém virtuálním počítači. Další informace o zprostředkovateli ochrany dat a jeho výhodách najdete v dokumentaci k Oracle v tomto tématu.

Následující diagram je doporučená architektura pro používání ochrany dat Oracle v Azure se zónami dostupnosti. Tato architektura umožňuje získat smlouvu SLA pro dobu provozu virtuálního počítače 99,99%.

Diagram, který zobrazuje doporučenou architekturu pro používání ochrany dat Oracle v Azure se zónami dostupnosti.

V předchozím diagramu klientský systém přistupuje k vlastní aplikaci pomocí back-endu Oracle přes web. Webový front-end je nakonfigurovaný v nástroji pro vyrovnávání zatížení. Webový front-end provede volání příslušného aplikačního serveru za účelem zpracování práce. Aplikační server se dotazuje na primární databázi Oracle. Databáze Oracle byla nakonfigurovaná pomocí virtuálního počítače optimalizovaného pro paměť ve vlákně s omezeným jádrem vCPU , který šetří náklady na licencování a maximalizuje výkon. Pro výkon a vysokou dostupnost se používá několik disků Premium nebo Ultra (Managed Disks).

Databáze Oracle jsou umístěné 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í. Aby se zajistila odolnost, ve všech povolených oblastech se nastaví minimálně tři samostatné zóny. Fyzické oddělení zón dostupnosti v rámci oblasti chrání data před selháními datových center. Kromě toho se dva FSFO pozorovatelé nastavují ve dvou zónách dostupnosti, aby se při výpadku databáze nastavily a přestaly při selhání.

Další pozorovatele nebo pohotovostní databáze můžete nastavit v jiné zóně dostupnosti (AZ 1, v tomto případě), než je zóna uvedená v předchozí architektuře. od oracle Enterprise manageru (OEM) se nakonec monitorují databáze oracle pro dobu provozu a výkon. Výrobce OEM také umožňuje vygenerovat různé sestavy o výkonu a využití.

V oblastech, kde se zóny dostupnosti nepodporují, můžete použít skupiny dostupnosti k nasazení Oracle Database 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 je referenční architektura tohoto použití:

Oracle Database používání skupin dostupnosti s zprostředkovatelem data Guard – FSFO

Poznámka

  • virtuální počítač Oracle Enterprise manageru není potřeba umístit do skupiny dostupnosti, protože je nasazená jenom jedna instance OEM.
  • V konfiguraci skupiny dostupnosti se aktuálně nepodporují disky Ultra.

Oracle data Guard – Far synchronizace

Oracle data Guard – Far Synchronization poskytuje pro databáze Oracle nulovou možnost ochrany před únikem informací. Tato funkce umožňuje chránit před ztrátou dat v případě, že se databázový počítač nezdařil. Oracle data Guard – Far Sync se musí nainstalovat na samostatný virtuální počítač. Odlehčená synchronizace je odlehčená instance Oracle, která má pouze řídicí soubor, soubor hesla, SPFile a pohotovostní protokoly. Neexistují žádné datové soubory ani soubory protokolu Rego.

Pro zajištění nulové ochrany před únikem informací musí existovat synchronní komunikace mezi vaší primární databází a instancí daleko synchronizace. Instance s nastarší synchronizací přijímá v synchronním režimu opakování z primárního serveru a okamžitě ho přesměruje do všech záložních databází. Tato instalace také snižuje režijní náklady na primární databázi, protože je nutné pouze odeslat znovu do instance Far synchronizace, nikoli pro všechny pohotovostní databáze. Pokud se neúspěšná instance synchronizace nezdařila, ochrana dat automaticky používá asynchronní přenos do sekundární databáze z primární databáze za účelem zachování téměř nulové ochrany před únikem informací. Pro zvýšení odolnosti můžou zákazníci nasazovat víc instancí služby Sync na každou instanci databáze (primární a sekundární).

Následující diagram představuje architekturu s vysokou dostupností s využitím nástroje Oracle data Guard – Far Sync:

Databáze Oracle využívající zóny dostupnosti s data Guard – & Broker – FSFO

V předchozí architektuře je k dispozici daleko synchronizovaná instance, která je nasazená ve stejné zóně dostupnosti jako instance databáze, aby se snížila latence mezi nimi. V případech, kdy je aplikace citlivá na latenci, zvažte nasazení databáze a daleko synchronizovaných instancí nebo instancí ve skupině umístění blízkosti.

Následující diagram je architektura, která využívá Oracle data Guard FSFO a Far Sync k zajištění vysoké dostupnosti a zotavení po havárii:

Oracle Database použití zón dostupnosti pro zotavení po havárii s nástrojem data Guard – & Broker – FSFO

Oracle GoldenGate

GoldenGate umožňuje výměnu a manipulaci s daty na úrovni transakcí mezi několika heterogenními platformami v celém podniku. Přesouvá potvrzené transakce s integritou transakcí a minimální režií na stávající infrastruktuře. Jeho modulární architektura poskytuje flexibilitu pro extrakci a replikaci vybraných záznamů dat, transakčních změn a změny v jazyce DDL (Data Definition Language) v nejrůznějších topologiích.

Oracle GoldenGate umožňuje konfiguraci databáze pro zajištění vysoké dostupnosti díky obousměrné replikaci. To vám umožní nastavit konfiguraci s více hlavními servery nebo aktivní-aktivní. Následující diagram je doporučovanou architekturou pro Oracle GoldenGate Active-Active Setup v Azure. V následující architektuře byla databáze Oracle nakonfigurovaná pomocí virtuálního počítače optimalizovaného pro paměť ve vlákně s omezeným jádrem vCPU , který šetří náklady na licencování a maximalizuje výkon. K výkonu a dostupnosti se používá několik disků Premium nebo Ultra (spravované disky).

Oracle Database použití zón dostupnosti s zprostředkovatelem ochrany dat – FSFO

Poznámka

Podobnou architekturu je možné nastavit pomocí skupin dostupnosti v oblastech, kde zóny dostupnosti nejsou aktuálně dostupné.

Oracle GoldenGate má procesy, jako je například extrakce, pumpa a replikace, 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, aby se zajistila vysoká dostupnost databáze v případě výpadku na úrovni zóny dostupnosti. V předchozím diagramu proces extrakce běží na stejném serveru jako vaše databáze Oracle, zatímco procesy datového čerpadla a replikace se spouštějí na samostatném serveru ve stejné zóně dostupnosti. Proces replikace slouží k přijímání dat z databáze v jiné zóně dostupnosti a k potvrzení dat do databáze Oracle v příslušné zóně dostupnosti. Podobně proces datového čerpadla odesílá data extrahovaná procesem extrakce do procesu replikace v jiné zóně dostupnosti.

I když v předchozím diagramu architektury vidíte proces datového čerpadla a replikace nakonfigurovaný na samostatném serveru, můžete na stejném serveru nastavit všechny procesy Oracle GoldenGate na základě kapacity a využití vašeho serveru. Pro pochopení způsobu použití serveru si vždy Projděte sestavu AWR a metriky v Azure.

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 byla latence mezi různými součástmi pro vaši aplikaci přijatelná. Latence mezi zónami a oblastmi dostupnosti se může lišit a závisí na několika faktorech. Doporučuje se nastavit testy výkonu mezi aplikační vrstvou a vaší databázovou vrstvou v různých zónách dostupnosti a/nebo oblastech, abyste ověřili, že vyhovují vašim požadavkům na výkon vaší aplikace.

Aplikační vrstvu lze nastavit ve vlastní podsíti a databázová vrstva může být rozdělena do vlastní podsítě. Pokud je to možné, zvažte použití Azure Application Gateway k vyrovnávání zatížení provozu mezi aplikačními servery. Azure Application Gateway je robustní nástroj pro vyrovnávání zatížení webového provozu. Poskytuje spřažení relací na základě souborů cookie, které udržuje relaci uživatele na stejném serveru, čímž minimalizuje konflikty v databázi. k Application Gateway jsou Azure Load Balancer a Azure Traffic Manageralternativy.

Oracle horizontálního dělení

Horizontálního dělení je vzor datové vrstvy, který byl představený v Oracle 12,2. Umožňuje horizontálně rozdělit a škálovat data napříč nezávislými databázemi. Nejedná se o architekturu bez sdílené složky, ve které je každá databáze hostovaná na vyhrazeném virtuálním počítači, což umožňuje vysokou propustnost čtení a zápisu kromě odolnosti a zvýšené dostupnosti. Tento model eliminuje jednotlivé body selhání, zajišťuje izolaci chyb a umožňuje provádět průběžné upgrady bez výpadků. Výpadek jednoho horizontálních oddílů 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ího dělení je vhodný pro aplikace s vysokou propustností OLTP, které nemůžou dovolit žádné výpadky. Všechny řádky se stejným klíčem horizontálního dělení jsou vždycky zaručené na stejném horizontálních oddílů, což zvyšuje výkon, který zajišťuje vysokou konzistenci. Aplikace, které používají horizontálního dělení, musí mít dobře definovaný datový model a strategii distribuce dat (konzistentní hodnota hash, rozsah, seznam nebo složený), která primárně přistupuje k datům pomocí horizontálního dělení klíče (například customerId nebo accountNum). Horizontálního dělení také umožňuje ukládat konkrétní sady dat blíže koncovým zákazníkům, což vám pomůže splnit požadavky na výkon a dodržování předpisů.

Doporučuje se replikovat horizontálních oddílů pro zajištění vysoké dostupnosti a zotavení po havárii. Tuto instalaci můžete provést pomocí technologie Oracle, jako je Oracle data Guard nebo Oracle GoldenGate. Jednotkou replikace může být horizontálních oddílů, součást horizontálních oddílů nebo skupina horizontálních oddílů. Dostupnost databáze horizontálně dělené není ovlivněná výpadkem ani zpomalením jednoho nebo více horizontálních oddílů. Pro zajištění vysoké dostupnosti je možné pohotovostní horizontálních oddílů umístit do stejné zóny dostupnosti, kde je umístěn primární horizontálních oddílů. V případě zotavení po havárii může být pohotovostní horizontálních oddílů umístěno v jiné oblasti. Pro obsluhu provozu v těchto oblastech můžete také nasadit horizontálních oddílů v několika oblastech. Přečtěte si další informace o konfiguraci vysoké dostupnosti a replikaci databáze horizontálně dělené v dokumentaci Oracle horizontálního dělení.

Oracle horizontálního dělení se primárně skládá z následujících součástí. Další informace o těchto součástech najdete v dokumentaci k Oracle horizontálního dělení:

  • Horizontálních oddílů Catalog – speciální databáze Oracle pro zvláštní účely, která je trvalé úložiště pro všechna data konfigurace 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 iniciují v katalogu horizontálních oddílů. Katalog horizontálních oddílů obsahuje také hlavní kopii všech duplicitních tabulek v SDB.

    Katalog horizontálních oddílů používá materializovaná zobrazení k automatické replikaci změn do duplikovaných tabulek ve všech horizontálních oddílů. Databáze katalogu horizontálních oddílů funguje taky jako koordinátor dotazů, který se používá ke zpracování dotazů a dotazů multi-horizontálních oddílů, které neurčují klíč horizontálního dělení.

    Použití ochrany dat Oracle ve spojení se zónami dostupnosti nebo skupinami dostupnosti pro vysokou dostupnost katalogu horizontálních oddílů je doporučeným osvědčeným postupem. Dostupnost katalogu horizontálních oddílů nemá žádný vliv na dostupnost databáze horizontálně dělené. Výpadek katalogu horizontálních oddílů má vliv jenom na operace údržby a dotazy multishard v krátké době, kdy se převzetí služeb při selhání dokončí. Online transakce budou i nadále směrovány a spouštěny v rámci SDB a nejsou ovlivněny výpadkem katalogu.

  • Horizontálních oddílů ředitelé – odlehčené služby, které je potřeba nasadit v každé oblasti nebo zóně dostupnosti, ve které se nachází vaše horizontálních oddílů. Horizontálních oddílů ředitelé mají v kontextu Oracle horizontálního dělení nasazené globální správce služeb. Pro zajištění vysoké dostupnosti doporučujeme nasadit alespoň jednoho horizontálních oddílů ředitele v každé zóně dostupnosti, ve které horizontálních oddílů existuje.

    Při prvním připojení k databázi se informace o směrování nastaví pomocí horizontálních oddílů ředitele a ukládají se do mezipaměti pro následné žádosti a obcházejí horizontálních oddílůho ředitele. jakmile je relace navázána s horizontálních oddílů, jsou všechny dotazy SQL a dml v oboru daného horizontálních oddílů podporovány a provedeny. Toto směrování je rychlé a používá se pro všechny OLTP úlohy, které provádějí transakce uvnitř horizontálních oddílů. Doporučuje se používat přímé směrování pro všechny OLTP úlohy, které vyžadují nejvyšší výkon a dostupnost. Mezipaměť směrování se automaticky aktualizuje, když se horizontálních oddílů změní na nedostupný 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 databázi horizontálně dělené použít fond připojení. Fondy připojení Oracle, knihovny specifické pro jazyk a ovladače podporují Oracle horizontálního dělení. Další podrobnosti najdete v dokumentaci k Oracle horizontálního dělení .

  • Globální služba – služba Global Service je podobná běžné databázové službě. Kromě všech vlastností databázové služby má globální služba vlastnosti pro databáze horizontálně dělené, jako je spřažení oblastí mezi klienty a horizontálních oddílů a tolerance prodlevy replikace. Pro čtení a zápis dat do/z databáze horizontálně dělené je potřeba vytvořit jenom jednu globální službu. Při použití Active Data Guard a nastavení replik horizontálních oddílů jen pro čtení můžete vytvořit další službu gGobal pro úlohy jen pro čtení. Klient může tyto globální služby používat pro připojení k databázi.

  • Databáze horizontálních oddílů – databáze horizontálních oddílů jsou databáze Oracle. Každá databáze se replikuje pomocí Oracle data Guard v konfiguraci zprostředkovatele s povoleným Fast-Start převzetí služeb při selhání (FSFO). Pro každou horizontálních oddílů není nutné nastavovat převzetí služeb při selhání ochrany dat a replikaci. Tato konfigurace se automaticky nakonfiguruje a nasadí při vytvoření sdílené databáze. Pokud se konkrétní horizontálních oddílů nepovede, sdílení Oracle při převzetí služeb při selhání připojení databáze z primárního serveru do úsporného režimu automaticky nefunguje.

databáze oracle horizontálně dělené můžete nasadit a spravovat pomocí dvou rozhraní: oracle Enterprise Manager Cloud Control GUI a/nebo GDSCTL nástroj příkazového řádku. Můžete dokonce monitorovat různé horizontálních oddílů pro dostupnost a výkon pomocí řízení cloudu. GDSCTL DEPLOYPříkaz automaticky vytvoří horizontálních oddílů a jejich příslušné naslouchací procesy. Tento příkaz kromě toho automaticky nasadí konfiguraci replikace použitou pro vysokou dostupnost na úrovni horizontálních oddílů určenou správcem.

Existují různé způsoby, jak horizontálních oddílů databázi:

  • Horizontálního dělení spravovaná systémem – automaticky distribuuje mezi horizontálních oddílů pomocí dělení.
  • Uživatelsky definované horizontálního dělení – umožňuje určit mapování dat na horizontálních oddílů, které funguje i v případě, že existují regulativní předpisy nebo požadavky na lokalizaci dat.)
  • Kompozitní horizontálního dělení – kombinace systému spravovaného systémem a uživatelsky definované horizontálního dělení pro různé shardspaces
  • Pododdíly tabulky – podobné jako u běžné dělené tabulky.

Přečtěte si další informace o různých metodách horizontálního dělení v dokumentaci Oracle.

I když může databáze horizontálně dělené vypadat jako jediná databáze pro aplikace a vývojáře při migraci z jiné databáze než horizontálně dělené do databáze horizontálně dělené, je potřeba pečlivé plánování, které určuje, které tabulky budou duplikovány versus horizontálně dělené.

Duplicitní tabulky jsou uloženy ve všech horizontálních oddílů, zatímco tabulky horizontálně dělené jsou distribuovány napříč různými horizontálních oddílů. Doporučení je duplikovat malé a dimenzionální tabulky a distribuovat/horizontálních oddílů tabulky faktů. Data se dají do databáze horizontálně dělené načíst pomocí katalogu horizontálních oddílů jako centrálního koordinátora nebo spuštěním datového čerpadla na každém horizontálních oddílů. Přečtěte si další informace o migraci dat do databáze horizontálně dělené v dokumentaci Oracle.

Oracle horizontálního dělení s ochranou dat

Oracle data Guard se dá použít pro horizontálního dělení se systémem spravované, uživatelsky definovanými a složenými horizontálního dělení metodami.

Následující diagram je referenční architektura pro Oracle horizontálního dělení s ochranou dat Oracle, která se používá pro vysokou dostupnost každého horizontálních oddílů. Diagram architektury znázorňuje složenou metodu horizontálního dělení. Diagram architektury se pravděpodobně bude lišit pro aplikace s různými požadavky na lokalitu dat, vyrovnávání zatížení, vysokou dostupnost, zotavení po havárii atd. a může pro shardování používat jinou metodu. Oracle Sharding vám umožní splnit tyto požadavky a zajistit horizontální a efektivní škálování díky těmto možnostem. Podobnou architekturu je možné nasadit i pomocí Oracle GoldenGate.

Oracle Database horizontálního dělení pomocí zón dostupnosti s využitím zprostředkovatele ochrany Data Guard – FSFO

I když se shardování spravované systémem nejsnadněji konfiguruje a spravuje, uživatelem definované horizontální dělení nebo složené horizontální dělení je vhodné pro scénáře, kdy jsou vaše data a aplikace geograficky distribuované nebo ve scénářích, kdy 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 škálování aplikačních vrstev. Složené horizontální dělení je kombinací shardování spravovaného systémem a uživatelem definovaného horizontálního dělení, a proto poskytuje výhody obou metod. V předchozím scénáři se data nejprve shardují napříč několika prostory horizontálních oddílů oddělenými podle oblasti. Pak se data dále rozdělují pomocí konzistentní hodnoty hash mezi několik horizontálních oddílů v prostoru horizontálních oddílů. Každý shardspace obsahuje několik skupin horizontálních oddílů. Každá skupina horizontálních oddílů má více horizontálních oddílů a v tomto případě je to "jednotka" replikace. Každá skupina horizontálních oddílů obsahuje všechna data v prostoru horizontálních oddílů. Skupiny horizontálních oddílů 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 zvolit, aby jednotlivé horizontální oddíly místo skupiny horizontálních oddílů byly jednotkou replikace.

V předchozí architektuře se v každé zóně dostupnosti kvůli vysoké dostupnosti nasadí ředitel PROC/shard. Doporučujeme nasadit alespoň jeden ředitel HORIZONTÁLNÍCH oddílů na jedno datové centrum nebo oblast. Kromě toho je instance aplikačního serveru nasazená v každé zóně dostupnosti, která obsahuje skupinu horizontálních oddílů. Toto nastavení umožňuje aplikaci zachovat nízkou latenci mezi aplikačním serverem a databází nebo skupinou horizontálních oddílů. Pokud databáze selže, může aplikační server ve stejné zóně jako pohotovostní databáze zpracovávat požadavky, jakmile dojde k přechodu databázové role. Azure Application Gateway a ředitel horizontálních oddílů udržují přehled o latenci požadavků a odpovědí a odpovídajícím způsobem směruje požadavky.

Z hlediska aplikace klientský systém vytvoří požadavek na službu Azure Application Gateway (nebo jiné technologie vyrovnávání zatížení v Azure), která požadavek přesměruje do oblasti, která je nejblíže klientovi. Azure Application Gateway podporuje také přichycené relace, takže všechny požadavky přicházející ze stejného klienta se směruje na stejný aplikační server. Aplikační server používá sdružování připojení v ovladačích pro přístup k datům. Tato funkce je dostupná v ovladačích, jako jsou JDBC, ODP.NET, OCI atd. Ovladače znají klíče horizontálního dělení zadané jako součást požadavku. Nástroj Oracle Universal Connection Pool (UCP) pro klienty JDBC může povolit klientům aplikací jiných než Oracle, jako jsou Apache Tomcat a IIS, práci s horizontálním dělením Oracle.

Během počátečního požadavku se aplikační server připojí k řediteli horizontálního oddílu ve své oblasti, aby si vyžádal informace o směrování pro horizontální oddíl, na který se má požadavek směrovat. Na základě předaového klíče horizontálního dělení směruje ředitel aplikační server do příslušného horizontálního oddílu. Aplikační server ukládá tyto informace do mezipaměti vytvořením mapy a pro následné požadavky obchází správce horizontálních oddílů a směruje požadavky přímo do horizontálního oddílu.

Oracle Sharding s goldengate

Následující diagram je referenční architekturou pro Oracle Sharding s Oracle GoldenGate pro vysokou dostupnost jednotlivých horizontálních oddílů v oblastech. Na rozdíl od předchozí architektury tato architektura vystupuje pouze jako vysoká dostupnost v rámci jedné oblasti Azure (více zón dostupnosti). K nasazení shardované databáze s vysokou dostupností ve více oblastech (podobně jako v předchozím příkladu) můžete použít Oracle GoldenGate.

Oracle Database horizontálního dělení s využitím zón dostupnosti s využitím 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 se provádí na úrovni bloků dat, může se polovina dat replikovaných do jednoho horizontálního oddílu replikovat do jiného horizontálního oddílu. Druhá polovina se může replikovat do jiného horizontálního oddílu.

Způsob replikace dat závisí na faktoru replikace. S faktorem replikace 2 budete mít dvě kopie každého bloku dat napříč třemi horizontálními oddíly ve skupině horizontálních oddílů. Podobně s faktorem replikace 3 a třemi horizontálními oddíly ve skupině horizontálních oddílů se všechna data v každém horizontálním oddílu replikují do všech ostatních horizontálních oddílů 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 skupina horizontálních oddílů A i skupina horizontálních oddílů B obsahují stejná data, ale nacházejí se v různých zónách dostupnosti. Pokud má skupina horizontálních oddílů A i skupina horizontálních oddílů B stejný faktor replikace 3, každý řádek nebo blok vaší shardované tabulky se 6krát replikuje mezi dvěma skupinami horizontálních oddílů. Pokud má skupina horizontálních oddílů A faktor replikace 3 a skupina horizontálních oddílů B má faktor replikace 2, každý řádek nebo blok se v těchto dvou skupinách horizontálních oddílů replikuje 5krát.

Toto nastavení zabraňuje ztrátě dat v případě selhání na úrovni instance nebo zóny dostupnosti. Aplikační vrstva dokáže číst z jednotlivých horizontálních oddílů a zapisovat do nich. 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 budou směrovat na odpovídající blok dat. Kromě toho Oracle GoldenGate poskytuje automatické zjišťování a řešení konfliktů pro zpracování případných konfliktů. Další informace a omezení implementace GoldenGate s Oracle Shardingem najdete v dokumentaci Oracle týkající se použití Oracle GoldenGate s dělenější databází.

V předchozí architektuře se v každé zóně dostupnosti kvůli vysoké dostupnosti nasadí ředitel PROC/shard. Doporučujeme nasadit alespoň jeden ředitel HORIZONTÁLNÍCH oddílů na jedno datové centrum nebo oblast. Kromě toho je instance aplikačního serveru nasazená v každé zóně dostupnosti, která obsahuje skupinu horizontálních oddílů. Toto nastavení umožňuje aplikaci zachovat nízkou latenci mezi aplikačním serverem a databází nebo skupinou horizontálních oddílů. Pokud databáze selže, může aplikační server ve stejné zóně jako pohotovostní databáze zpracovávat požadavky po přechodu databázové role. Azure Application Gateway a ředitel horizontálních oddílů udržují přehled o latenci požadavků a odpovědí a odpovídajícím způsobem směruje požadavky.

Z hlediska aplikace klientský systém vytvoří požadavek na službu Azure Application Gateway (nebo jiné technologie vyrovnávání zatížení v Azure), která požadavek přesměruje do oblasti, která je nejblíže klientovi. Azure Application Gateway podporuje také přichycené relace, takže všechny požadavky přicházející ze stejného klienta se směruje na stejný aplikační server. Aplikační server používá sdružování připojení v ovladačích pro přístup k datům. Tato funkce je dostupná v ovladačích, jako jsou JDBC, ODP.NET, OCI atd. Ovladače znají klíče horizontálního dělení zadané jako součást požadavku. Nástroj Oracle Universal Connection Pool (UCP) pro klienty JDBC může povolit klientům aplikací jiných než Oracle, jako jsou Apache Tomcat a IIS, práci s horizontálním dělením Oracle.

Během počátečního požadavku se aplikační server připojí k řediteli horizontálního oddílu ve své oblasti, aby si vyžádal informace o směrování pro horizontální oddíl, na který se má požadavek směrovat. Na základě předaového klíče horizontálního dělení směruje ředitel aplikační server do příslušného horizontálního oddílu. Aplikační server ukládá tyto informace do mezipaměti vytvořením mapy a pro následné požadavky obchází správce horizontálních oddílů a směruje požadavky přímo do horizontálního oddílu.

Opravy a údržba

Při nasazování úloh Oracle do Azure se Microsoft postará o všechny opravy na úrovni operačního systému hostitele. Veškeré plánované údržby na úrovni operačního systému se zákazníkům sdělí předem, aby bylo možné zákazníkovi tuto plánovanou údržbu povolit. Dva servery ze dvou různých Zóny dostupnosti nejsou nikdy opraveny současně. Další podrobnosti o údržbě a opravách virtuálních počítačů najdete v tématu Správa dostupnosti virtuálních počítačů.

Opravy operačního systému virtuálního počítače je možné automatizovat pomocí 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 minimalizovat prostoje. Informace o tom, jak je možné je použít v kontextu databází Oracle, najdete v tématu Průběžné doručování a modré/zelené nasazení.

Aspekty architektury a návrhu

  • Zvažte použití virtuálního počítače optimalizovaného pro hyperthreaded memory s virtuálními procesory s omezenými jádry pro virtuální počítač Oracle Database, abyste ušetřili náklady na licence a maximalizovali výkon. Pro výkon a dostupnost použijte několik disků Úrovně Premium nebo Ultra (spravované disky).
  • Při použití spravovaných disků se název disku nebo zařízení může při restartování změnit. Doporučuje se místo názvu použít UUID zařízení, abyste zajistili zachování připojení mezi restartováními. Další informace najdete v tématu Konfigurace softwarového pole RAID na virtuálním počítači s Linuxem.
  • Pomocí zón dostupnosti můžete dosáhnout vysoké dostupnosti v oblasti.
  • Zvažte použití disků Ultra (pokud jsou k dispozici) nebo disků Premium pro databázi Oracle.
  • Zvažte nastavení pohotovostní databáze Oracle v jiné oblasti Azure pomocí Oracle Data Guard.
  • Zvažte použití skupin umístění bezkontaktní blízkosti, abyste snížili latenci mezi vaší aplikací a databázová vrstva.
  • Nastavte Oracle Enterprise Manager pro správu, monitorování a protokolování.
  • Zvažte použití Oracle Automatic Storage Management (ASM) pro zjednodušenou správu úložiště pro vaši databázi.
  • Pomocí Azure Pipelines můžete spravovat opravy a aktualizace databáze bez jakýchkoli výpadků.
  • Vyladěním kódu aplikace přidáte nativní cloudové vzory, jako je model opakování,model jističe a další vzory definované v průvodci vzory návrhu cloudu, které můžou vaší aplikaci pomoct být odolnější.

Další kroky

Prohlédněte si následující referenční články Oracle, které se vztahují k vašemu scénáři.