Oracle-adatbázis architektúrái azure-beli virtuális gépeken

  • Cikk

A következőkre vonatkozik: ✔️ Linux rendszerű virtuális gépek

Ez a cikk egy magas rendelkezésre állású Oracle-adatbázis Azure-on való üzembe helyezéséről tartalmaz információkat. Ez az útmutató emellett a vészhelyreállítással kapcsolatos szempontokat is ismerteti. Ezek az architektúrák az ügyféltelepítések alapján lettek létrehozva. Ez az útmutató csak az Oracle Database Enterprise kiadás vonatkozik.

Ha többet szeretne megtudni az Oracle-adatbázis teljesítményének maximalizálásáról, tekintse meg az Oracle-adatbázis tervezését és implementálását az Azure-ban.

Előfeltételek

Oracle-adatbázisok magas rendelkezésre állása

A magas rendelkezésre állás elérése a felhőben fontos része minden szervezet tervezésének és tervezésének. Az Azure rendelkezésre állási zónákat és rendelkezésre állási csoportokat kínál azokban a régiókban, ahol a rendelkezésre állási zónák nem érhetők el. A felhő tervezésével kapcsolatos további információkért tekintse meg az Azure-beli virtuális gépek rendelkezésre állási lehetőségeit.

A natív felhőbeli eszközök és ajánlatok mellett az Oracle olyan megoldásokat is kínál a magas rendelkezésre álláshoz, amelyek beállíthatók az Azure-ban:

Ez az útmutató az egyes megoldások referenciaarchitektúráit ismerteti.

Ha migrál vagy hoz létre alkalmazásokat a felhőhöz, javasoljuk, hogy natív felhőbeli mintákat használ, például újrapróbálkozási mintát és megszakító mintát. További minták, amelyek segíthetnek az alkalmazás rugalmasságának kialakításában, tekintse meg a Felhőtervezési minták útmutatóját.

Oracle RAC a felhőben

Az Oracle valós alkalmazásfürtje (RAC) egy olyan megoldás, amellyel az ügyfelek nagy átviteli sebességet érhetnek el azáltal, hogy számos példány fér hozzá egy adatbázis-tárolóhoz. Ez a minta egy megosztott architektúra. Bár az Oracle RAC a helyszíni magas rendelkezésre álláshoz használható, az Oracle RAC önmagában nem használható magas rendelkezésre álláshoz a felhőben. Az Oracle RAC csak a példányszintű hibák ellen véd, nem pedig az állványszintű vagy adatközpontszintű hibák ellen. Ezért az Oracle azt javasolja, hogy a magas rendelkezésre állás érdekében használja az Oracle Data Guardot az adatbázissal, akár egyetlen példányt, akár RAC-t.

Az ügyfelek általában magas SLA-t igényelnek a kritikus fontosságú alkalmazások futtatásához. Az Oracle jelenleg nem minősíti vagy támogatja az Oracle RAC-t az Azure-ban. Az Azure azonban olyan funkciókat kínál, mint a rendelkezésre állási zónák és a tervezett karbantartási időszakok a példányszintű hibák elleni védelem érdekében. Ezen ajánlatok mellett az Oracle Data Guard, az Oracle GoldenGate és az Oracle Sharding is használható a nagy teljesítmény és a rugalmasság érdekében. Ezek a technológiák segítenek megvédeni az adatbázisokat az állványszintű, adatközponti és geopolitikai hibáktól.

Ha az Oracle Databasest több rendelkezésre állási zónán futtatja az Oracle Data Guard vagy a GoldenGate használatával, 99,99%-os üzemidejű SLA-t kaphat. AzOkban az Azure-régiókban, ahol még nincsenek rendelkezésre állási zónák, rendelkezésre állási csoportokat használhat, és 99,95%-os üzemidejű SLA-t érhet el.

Feljegyzés

A Microsoft által biztosított üzemidő-SLA-nál sokkal magasabb üzemidejű célértéket is használhat.

Oracle-adatbázisok vészhelyreállítása

Amikor kritikus fontosságú alkalmazásokat üzemeltet a felhőben, fontos a magas rendelkezésre állás és a vészhelyreállítás tervezése.

Az Oracle Database Enterprise kiadás esetében az Oracle Data Guard hasznos funkció a vészhelyreállításhoz. Beállíthat egy készenléti adatbázispéldányt egy párosított Azure-régióban , és beállíthatja a Data Guard feladatátvételét vészhelyreállításhoz. Nulla adatvesztés esetén javasoljuk, hogy az Active Data Guard mellett telepítsen egy Oracle Data Guard Far Sync-példányt is.

Ha az alkalmazás engedélyezi a késést, fontolja meg a Data Guard Far Sync-példány beállítását egy másik rendelkezésre állási zónában, mint az Oracle elsődleges adatbázisa. Alaposan tesztelje a konfigurációt. A Maximális rendelkezésre állás mód használatával beállíthatja a fájlok szinkron átvitelét a Távoli szinkronizálás példányba. Ezek a fájlok ezután aszinkron módon kerülnek át a készenléti adatbázisba.

Előfordulhat, hogy az alkalmazás nem engedélyezi a teljesítménycsökkenést, amikor a Távoli szinkronizálási példányt egy másik rendelkezésre állási zónában állítja be maximális rendelkezésre állási módban (szinkron). Ha nem, előfordulhat, hogy egy Távoli szinkronizálási példányt az elsődleges adatbázissal megegyező rendelkezésre állási zónában állít be. A hozzáadott rendelkezésre állás érdekében érdemes lehet több Távoli szinkronizálási példányt beállítani az elsődleges adatbázishoz közel, és legalább egy, a készenléti adatbázishoz közeli példányt, ha a szerepkör áttűnéseit. További információ: Oracle Active Data Guard Far Sync.

Oracle-Standard kiadás-adatbázisok használatakor vannak olyan ISV-megoldások, amelyek lehetővé teszik a magas rendelkezésre állás és vészhelyreállítás beállítását, például a DBVisit Standbyet.

Referenciaarchitektúrák

Oracle Data Guard

Az Oracle Data Guard magas rendelkezésre állást, adatvédelmet és vészhelyreállítást biztosít a vállalati adatokhoz. A Data Guard az elsődleges adatbázis tranzakciós konzisztens másolataként kezeli a készenléti adatbázisokat. Az elsődleges és a másodlagos adatbázisok közötti távolságtól és az alkalmazás késési tűrésétől függően beállíthatja a szinkron vagy aszinkron replikációt. Ha az elsődleges adatbázis tervezett vagy nem tervezett kimaradás miatt nem érhető el, a Data Guard bármilyen készenléti adatbázist átválthat az elsődleges szerepkörre, minimalizálva az állásidőt.

Az Oracle Data Guard használatakor a másodlagos adatbázist írásvédett célokra is megnyithatja. Ezt a konfigurációt Active Data Guard-nak nevezzük. Az Oracle Database 12c bevezetett egy Data Guard Far Sync Instance nevű funkciót. Ez a példány lehetővé teszi, hogy nulla adatveszteség-konfigurációt állítson be az Oracle-adatbázishoz anélkül, hogy a teljesítményt veszélyeztetnie kellene.

Feljegyzés

Az Active Data Guard további licencelést igényel. Ez a licenc a Távoli szinkronizálás funkció használatához is szükséges. Lépjen kapcsolatba oracle-képviselőjével a licencelési következmények megvitatása érdekében.

Oracle Data Guard gyors üzembe helyezési feladatátvétellel

Az Oracle Data Guard és a Fast-Start Feladatátvétel (FSFO) nagyobb rugalmasságot biztosíthat a közvetítő külön gépen való beállításával. A Data Guard-közvetítő és a másodlagos adatbázis egyaránt futtatja a megfigyelőt, és figyeli az elsődleges adatbázist állásidőre. Ez a megközelítés lehetővé teszi a redundanciát a Data Guard megfigyelőjének beállításában is.

Az Oracle Database 12.2-es és újabb verziójával több megfigyelőt is konfigurálhat egyetlen Oracle Data Guard-közvetítő konfigurációval. Ez a beállítás további rendelkezésre állást biztosít, ha egy megfigyelő és a másodlagos adatbázis állásidőt tapasztal. A Data Guard Broker egyszerű, és viszonylag kis méretű virtuális gépen üzemeltethető. További információ a Data Guard Brokerről és előnyeiről: Oracle Data Guard Broker Concepts.

Az alábbi ábra egy ajánlott architektúra az Oracle Data Guard Azure-beli rendelkezésre állási zónákkal való használatához. Ez az architektúra lehetővé teszi a virtuális gépek 99,99%-os üzemidejű SLA-jának beszerzését.

Diagram that shows a recommended architecture for using Oracle Data Guard on Azure with availability zones.

Az előző ábrán az ügyfélrendszer egy egyéni alkalmazást ér el az Oracle háttérrendszerével a weben. A webes előtér egy terheléselosztóban van konfigurálva. A webes előtérbeli rendszer meghívja a megfelelő alkalmazáskiszolgálót a munka kezeléséhez. Az alkalmazáskiszolgáló lekérdezi az elsődleges Oracle-adatbázist. Az Oracle-adatbázis hyperthreaded memóriaoptimalizált virtuális géppel lett konfigurálva korlátozott alapszintű virtuális processzorokkal a licencelési költségek csökkentése és a teljesítmény maximalizálása érdekében. A teljesítmény és a magas rendelkezésre állás érdekében több prémium vagy ultralemezt (felügyelt lemezt) használnak.

Az Oracle-adatbázisok több rendelkezésre állási zónában vannak elhelyezve a magas rendelkezésre állás érdekében. Minden zóna egy vagy több, független energiaellátással, hűtéssel és hálózatkezeléssel felszerelt adatközpontból áll. A rugalmasság biztosítása érdekében legalább három különálló zóna van beállítva az összes engedélyezett régióban. A rendelkezésre állási zónák régión belüli fizikai elkülönítése védi az adatokat az adatközpont hibáitól. Emellett két FSFO-megfigyelő is be van állítva két rendelkezésre állási zónában, hogy elindítsa és átvehesse az adatbázist a másodlagosra, amikor leállás történik.

Ebben az esetben más megfigyelőket vagy készenléti adatbázisokat is beállíthat egy másik rendelkezésre állási zónában, az AZ 1-ben, mint az előző architektúra által megjelenített zónában. Végül az Oracle Enterprise Manager (OEM) figyeli az Oracle-adatbázisokat az üzemidő és a teljesítmény szempontjából. Az OEM segítségével különböző teljesítmény- és használat-jelentések is generálhatók.

Azokban a régiókban, ahol a rendelkezésre állási zónák nem támogatottak, rendelkezésre állási csoportokat használhat az Oracle Database magas rendelkezésre állású üzembe helyezéséhez. A rendelkezésre állási csoportok lehetővé teszik a virtuális gépek 99,95%-os üzemidejének elérését. A következő diagram a használat referenciaarchitektúrája:

Diagram that shows Oracle Database using availability sets with Data Guard Broker - FSFO.

Feljegyzés

  • Mivel az OEM-nek csak egy példánya van üzembe helyezve, nem kell az Oracle Enterprise Manager virtuális gépet rendelkezésre állási csoportban elhelyeznie.
  • Az ultralemezek jelenleg nem támogatottak a rendelkezésre állási csoport konfigurációjában.

Oracle Data Guard Far Sync

Az Oracle Data Guard Far Sync zéró adatveszteség-védelmi képességet biztosít az Oracle Database-ekhez. Ez a funkció lehetővé teszi az adatvesztés elleni védelmet, ha az adatbázis-gép meghibásodik. Az Oracle Data Guard Far Syncet külön virtuális gépen kell telepíteni. A Far Sync egy egyszerűsített Oracle-példány, amely csak vezérlőfájllal, jelszófájllal, spfile-val és készenléti naplókkal rendelkezik. Nincsenek adatfájlok, és nem is kell naplófájlokat ismételnie.

A nulla adatvesztés elleni védelemhez szinkron kommunikációnak kell lennie az elsődleges adatbázis és a Távoli szinkronizálás példány között. A Távoli szinkronizálás példány szinkron módon kapja meg az újraműveletet az elsődlegestől, és azonnal továbbítja az összes készenléti adatbázisnak aszinkron módon. Ez a beállítás csökkenti az elsődleges adatbázis többletterhelését is, mivel az összes készenléti adatbázis helyett csak a Távoli szinkronizálás példánynak kell elküldenie az ismétlést. Ha egy Távoli szinkronizálási példány meghiúsul, a Data Guard automatikusan aszinkron átvitelt használ a másodlagos adatbázisba az elsődleges adatbázisból a közel nulla adatveszteség-védelem fenntartása érdekében. A rugalmasság növelése érdekében az ügyfelek adatbázispéldányonként több Távoli szinkronizálási példányt is üzembe helyezhetnek, beleértve az elsődleges és a másodpéldányokat is.

Az alábbi ábra egy magas rendelkezésre állású architektúra az Oracle Data Guard Far Sync használatával:

Diagram that shows Oracle database using availability zones with Data Guard Far Sync & Broker - FSFO.

Az előző architektúrában egy Távoli szinkronizálási példány van üzembe helyezve ugyanabban a rendelkezésre állási zónában, mint az adatbázispéldány, hogy csökkentse a kettő közötti késést. Azokban az esetekben, amikor az alkalmazás késésre érzékeny, fontolja meg az adatbázis és a Távoli szinkronizálás példány vagy példányok üzembe helyezését egy közelségi elhelyezési csoportban.

Az alábbi diagram egy architektúra, amely az Oracle Data Guard FSFO és a Far Sync használatával biztosítja a magas rendelkezésre állást és a vészhelyreállítást:

Diagram that shows Oracle Database using availability zones for disaster recovery with Data Guard Far Sync and Broker - FSFO.

Oracle GoldenGate

A GoldenGate lehetővé teszi az adatok tranzakciós szinten történő cseréjét és kezelését a vállalat több heterogén platformja között. Tranzakcióintegritással és minimális többletterheléssel mozgatja a véglegesített tranzakciókat a meglévő infrastruktúrán. Moduláris architektúrája rugalmasságot biztosít a kiválasztott adatrekordok, tranzakciós módosítások és adatdefiníciós nyelv (DDL) változásainak kinyeréséhez és replikálásához különböző topológiákban.

Az Oracle GoldenGate lehetővé teszi az adatbázis magas rendelkezésre állásra való konfigurálását kétirányú replikáció biztosításával. Ezzel a módszerrel több főkiszolgálós vagy aktív-aktív konfigurációt állíthat be. Az alábbi ábra egy ajánlott architektúra az Oracle GoldenGate aktív-aktív beállításához az Azure-ban. Az alábbi architektúrában az Oracle-adatbázis egy hipertengelizált memóriaoptimalizált virtuális géppel lett konfigurálva korlátozott alapszintű virtuális processzorokkal a licencelési költségek csökkentése és a teljesítmény maximalizálása érdekében. Az architektúra több prémium vagy ultralemezt (felügyelt lemezt) használ a teljesítmény és a rendelkezésre állás érdekében.

Diagram that shows Oracle Database using availability zones with Data Guard Broker - FSFO.

Feljegyzés

Hasonló architektúra állítható be rendelkezésre állási csoportok használatával olyan régiókban, ahol a rendelkezésre állási zónák jelenleg nem érhetők el.

Az Oracle GoldenGate olyan folyamatokkal rendelkezik, mint a Kinyerés, a Szivattyú és a Replika, amelyek segítenek az adatok aszinkron replikálásában az Egyik Oracle-adatbáziskiszolgálóról a másikra. Ezek a folyamatok lehetővé teszik kétirányú replikáció beállítását az adatbázis magas rendelkezésre állása érdekében, ha rendelkezésre állási zónaszintű állásidő áll rendelkezésre.

Az előző ábrán a kinyerési folyamat ugyanazon a kiszolgálón fut, mint az Oracle-adatbázis. Az adatszivattyú- és replikafolyamatok egy különálló kiszolgálón futnak ugyanabban a rendelkezésre állási zónában. A replikafolyamat a másik rendelkezésre állási zónában lévő adatbázis adatainak fogadására és az adatoknak a rendelkezésre állási zónában lévő Oracle-adatbázisra való véglegesítésére szolgál. Hasonlóképpen, az adatszivattyús folyamat adatokat küld, amelyeket a kinyerési folyamat kinyer a replika folyamatba a másik rendelkezésre állási zónában.

Bár az előző architektúradiagram egy külön kiszolgálón konfigurált adatszivattyú- és replikafolyamatokat mutatja be, a kiszolgáló kapacitása és kihasználtsága alapján beállíthat minden Oracle GoldenGate-folyamatot ugyanazon a kiszolgálón. A kiszolgáló használati mintájának megismeréséhez mindig tekintse meg az AWR-jelentést és az Azure-beli metrikákat.

Ha az Oracle GoldenGate kétirányú replikációját különböző rendelkezésre állási zónákban vagy különböző régiókban állítja be, fontos biztosítani, hogy a különböző összetevők közötti késés elfogadható legyen az alkalmazás számára. A rendelkezésre állási zónák és régiók közötti késés eltérő lehet. A késés több tényezőtől függ. Javasoljuk, hogy állítson be teljesítményteszteket az alkalmazásszint és az adatbázisszint között különböző rendelkezésre állási zónákban vagy régiókban. A tesztek megerősítik, hogy a konfiguráció megfelel az alkalmazás teljesítményére vonatkozó követelményeknek.

Az alkalmazásszint a saját alhálózatában állítható be, az adatbázisszint pedig külön alhálózatra osztható. Ha lehetséges, fontolja meg az Azure-alkalmazás Gateway használatát az alkalmazáskiszolgálók közötti forgalom terheléselosztásához. Az Application Gateway egy robusztus webes forgalom terheléselosztója. Cookie-alapú munkamenet-affinitást biztosít, amely egy felhasználói munkamenetet ugyanazon a kiszolgálón tart, minimalizálva az adatbázis ütközéseit. Az Application Gateway alternatívái az Azure Load Balancer és az Azure Traffic Manager.

Oracle-horizontális skálázás

A horizontális skálázás az Oracle 12.2-ben bevezetett adatréteg-minta. Lehetővé teszi az adatok horizontális particionálását és skálázását független adatbázisokban. Ez egy share-nothing architektúra, amelyben minden adatbázis egy dedikált virtuális gépen van tárolva. Ez a minta a rugalmasság és a nagyobb rendelkezésre állás mellett magas olvasási és írási átviteli sebességet is lehetővé tesz.

Ez a minta kiküszöböli az egyes meghibásodási pontokat, hibaelkülönítést biztosít, és állásidő nélkül engedélyezi a működés közbeni frissítéseket. Az egyik szegmens állásideje vagy egy adatközpontszintű hiba nem befolyásolja a többi adatközpont többi szegmensének teljesítményét vagy rendelkezésre állását.

A horizontális skálázás olyan nagy átviteli sebességű OLTP-alkalmazásokhoz alkalmas, amelyek nem engedhetik meg maguknak az állásidőt. Az azonos skálázási kulccsal rendelkező sorok mindig ugyanazon a szegmensen vannak. Ez a tény növeli a teljesítményt, és magas konzisztenciát biztosít. A horizontális skálázást használó alkalmazásoknak jól meghatározott adatmodellel és adatelosztási stratégiával kell rendelkezniük, például konzisztens kivonatokkal, tartományokkal, listával vagy összetettel. A stratégia elsősorban egy skálázási kulccsal, például customerId vagy accountNum használatával fér hozzá az adatokhoz. A horizontális skálázás lehetővé teszi bizonyos adathalmazok közelebbi tárolását a végfelhasználókhoz, így segít megfelelni a teljesítmény- és megfelelőségi követelményeknek.

Javasoljuk, hogy replikálja a szegmenseket a magas rendelkezésre állás és a vészhelyreállítás érdekében. Ez a beállítás olyan Oracle-technológiákkal végezhető el, mint az Oracle Data Guard vagy az Oracle GoldenGate. A replikációs egység lehet szegmens, szegmensrész vagy szegmenscsoport. Egy vagy több szegmens kimaradása vagy lassulása nem befolyásolja a szegmenses adatbázisok rendelkezésre állását.

A magas rendelkezésre állás érdekében a készenléti szegmensek ugyanabban a rendelkezésre állási zónában helyezhetők el, ahol az elsődleges szegmensek vannak elhelyezve. Vészhelyreállítás esetén a készenléti szegmensek egy másik régióban is elhelyezhetők. A szegmenseket több régióban is üzembe helyezheti, hogy kiszolgálja a forgalmat ezekben a régiókban. A horizontálisan elosztott adatbázis magas rendelkezésre állásának és replikációjának konfigurálásáról további információt a szegmensszintű magas rendelkezésre állásról szóló cikkben talál.

Az Oracle-horizontális skálázás elsősorban a következő összetevőkből áll. További információkért tekintse meg az Oracle horizontális skálázásának áttekintését:

  • Szegmenskatalógus. Speciális célú Oracle-adatbázis, amely az összes Shard-adatbázis konfigurációs adatának állandó tárolója. A szegmenskatalógus minden konfigurációs módosítást kezdeményez, például szegmensek hozzáadását vagy eltávolítását, az adatok leképezését és a szegmensadatbázisban található DLL-eket. A szegmenskatalógus az SDB összes duplikált táblájának mesterpéldányát is tartalmazza.

    A szegmenskatalógus materializált nézetekkel automatikusan replikálja a módosításokat a duplikált táblákra az összes szegmensben. A szegmenskatalógus-adatbázis lekérdezéskoordinátorként is működik, amely több szegmenses lekérdezések és olyan lekérdezések feldolgozására szolgál, amelyek nem adnak meg szegmenskulcsot.

    Ajánlott eljárásként ajánlott az Oracle Data Guard használata rendelkezésre állási zónákkal vagy rendelkezésre állási csoportokkal a szegmenskatalógus magas rendelkezésre állásához. A szegmenskatalógus rendelkezésre állása nincs hatással a szegmenses adatbázis rendelkezésre állására. A szegmenskatalógus állásideje csak a Data Guard feladatátvételének rövid időtartama alatt befolyásolja a karbantartási műveleteket és a többrétegű lekérdezéseket. Az SDB továbbra is online tranzakciókat irányít és futtat. A katalóguskimaradás nincs hatással rájuk.

  • Shard-igazgatók. Egyszerűsített szolgáltatások, amelyeket minden olyan régióban/rendelkezésre állási zónában üzembe kell helyezni, amelyben a szegmensek találhatók. A szegmensmenedzserek az Oracle Sharding kontextusában üzembe helyezett globális szolgáltatásmenedzserek. A magas rendelkezésre állás érdekében javasoljuk, hogy helyezzen üzembe legalább egy szegmensigazgatót minden rendelkezésre állási zónában, amelyben a szegmensek léteznek.

    Amikor először csatlakozik az adatbázishoz, a szegmens-igazgató beállítja az útválasztási információkat, és gyorsítótárazza az adatokat a későbbi kérésekhez, amelyek megkerülik a szegmensrendezőt. Miután a munkamenet létrejött egy szegmenssel, a rendszer minden SQL-lekérdezést és DLL-t támogat és végrehajt az adott szegmens hatókörében. Ez az útválasztás gyors, és minden OLTP-számítási feladathoz használható, amely szegmensen belüli tranzakciókat hajt végre. Javasoljuk, hogy minden olyan OLTP-számítási feladathoz használjon közvetlen útválasztást, amely a legmagasabb teljesítményt és rendelkezésre állást igényli. Az útválasztási gyorsítótár automatikusan frissül, ha egy szegmens elérhetetlenné válik, vagy a szegmenstopológia megváltozik.

    A nagy teljesítményű, adatfüggő útválasztáshoz az Oracle azt javasolja, hogy használjon kapcsolatkészletet a szegmenses adatbázisban lévő adatok elérésekor. Az Oracle-kapcsolatkészletek, a nyelvspecifikus kódtárak és az illesztőprogramok támogatják az Oracle-horizontális skálázást. További információkért tekintse meg az Oracle horizontális skálázásának áttekintését.

  • Globális szolgáltatás. A globális szolgáltatás hasonló a normál adatbázis-szolgáltatáshoz. Az adatbázis-szolgáltatás összes tulajdonsága mellett a globális szolgáltatás skálázott adatbázisokhoz is rendelkezik tulajdonságokkal. Ezek a tulajdonságok magukban foglalják az ügyfelek és a szegmensek közötti régió affinitást, valamint a replikáció késési tűrését. Csak egy globális szolgáltatást kell létrehozni az adatok szilánkos adatbázisokba való olvasásához/írásához. Az Active Data Guard használatakor és a szegmensek írásvédett replikáinak beállításakor létrehozhat egy másik globális szolgáltatást az írásvédett számítási feladatokhoz. Az ügyfél ezeket a globális szolgáltatásokat használhatja az adatbázishoz való csatlakozáshoz.

  • Szegmens-adatbázisok. A szegmensadatbázisok az Oracle-adatbázisok. A rendszer minden adatbázist az Oracle Data Guard használatával replikál egy közvetítőkonfigurációban, amelyen engedélyezve van az FSFO. Nem kell beállítania a Data Guard feladatátvételét és replikációját az egyes szegmenseken. Ezt a szempontot a rendszer automatikusan konfigurálja és telepíti a megosztott adatbázis létrehozásakor. Ha egy adott szegmens meghibásodik, az Oracle-megosztás az elsődleges és a készenléti adatbázis kapcsolatain keresztül meghiúsul.

Az Oracle szegmenses adatbázisait két felülettel helyezheti üzembe és kezelheti: az Oracle Enterprise Manager cloud control GUI-val és a GDSCTL parancssori segédprogrammal. Akár a különböző szegmenseket is monitorozhatja a rendelkezésre állás és a teljesítmény szempontjából a felhővezérlővel. A GDSCTL DEPLOY parancs automatikusan létrehozza a szegmenseket és a hozzájuk tartozó figyelőket. Emellett ez a parancs automatikusan telepíti a rendszergazda által megadott szegmensszintű magas rendelkezésre álláshoz használt replikációs konfigurációt.

Az adatbázisok horizontális felosztásának különböző módjai vannak:

  • Rendszer által felügyelt szegmensek: Particionálással automatikusan elosztja a szegmenseket
  • Felhasználó által definiált horizontális skálázás: Lehetővé teszi az adatok szegmensekre való leképezésének megadását, ami akkor működik jól, ha szabályozási vagy adat-honosítási követelmények vannak
  • Összetett horizontális skálázás: Rendszer által felügyelt és felhasználó által definiált szegmensek kombinációja a különböző szegmensterekhez
  • Táblázat részrészei: Hasonló egy normál particionált táblához

További információ: Horizontális skálázási módszerek.

A szegmenses adatbázisok egyetlen adatbázisnak tűnnek az alkalmazások és fejlesztők számára. Ha szilánkos adatbázisba migrál, gondosan tervezze meg, hogy mely táblák duplikálódnak és szilánkosak.

A duplikált táblák az összes szegmensen vannak tárolva, míg a szilánkos táblák különböző szegmensek között vannak elosztva. Javasoljuk, hogy duplikálja a kis és dimenziós táblákat, és ossza el/szilánkossá a ténytáblákat. Az adatok betölthetők a szegmenses adatbázisba a szegmenskatalógus használatával központi koordinátorként, vagy az egyes szegmenseken futó Data Pump használatával. További információ: Adatok migrálása szilánkos adatbázisba.

Oracle-horizontális skálázás a Data Guard használatával

Az Oracle Data Guard rendszer által felügyelt, felhasználó által definiált és összetett horizontális skálázási módszerekkel skálázható.

Az alábbi ábra egy referenciaarchitektúra az Oracle-beli horizontális skálázáshoz az Egyes szegmensek magas rendelkezésre állásához használt Oracle Data Guard használatával. Az architektúradiagram egy összetett horizontális skálázási módszert mutat be. Az architektúradiagram valószínűleg különbözik az adathelyességre, a terheléselosztásra, a magas rendelkezésre állásra és a vészhelyreállításra vonatkozó különböző követelményekkel rendelkező alkalmazások esetében. Az alkalmazások eltérő módszert használhatnak a horizontális skálázáshoz. Az Oracle Sharding lehetővé teszi ezeknek a követelményeknek a teljesítését, és horizontálisan és hatékonyan skálázhatja ezeket a lehetőségeket. Hasonló architektúra az Oracle GoldenGate használatával is üzembe helyezhető.

Diagram that shows Oracle Database Sharding using availability zones with Data Guard Broker - FSFO.

A rendszer által felügyelt horizontális skálázás a legegyszerűbben konfigurálható és kezelhető. A felhasználó által definiált szegmensek vagy összetett szegmensek jól alkalmazhatók olyan helyzetekben, ahol az adatok és az alkalmazások földrajzilag elosztottak, vagy olyan helyzetekben, ahol szabályoznia kell az egyes szegmensek replikációját.

Az előző architektúrában az összetett skálázás az adatok geodiszribúcionálására és az alkalmazásszintek horizontális felskálázására szolgál. Az összetett horizontális skálázás a rendszer által felügyelt és a felhasználó által definiált horizontális skálázás kombinációja, így mindkét módszer előnyeit biztosítja. Az előző forgatókönyvben az adatok először több régióval elválasztott szegmenstérre lesznek osztva. Ezután az adatok további particionálására a rendszer konzisztens kivonatot használ a szegmenstér több szegmensén.

Minden szegmenstér több szegmenscsoportot tartalmaz. Minden szegmenscsoport több szegmensből áll, és replikációs egység. Minden szegmenscsoport tartalmazza a szegmenstér összes adatát. Az A1 és B1 szegmenscsoportok elsődleges szegmenscsoportok, míg az A2 és a B2 szegmenscsoportok készenléti jellegűek. Dönthet úgy, hogy az egyes szegmensek nem szegmenscsoportként, hanem replikációs egységként működnek.

Az előző architektúrában egy Global Service Manager (GSM)/shard director van üzembe helyezve minden rendelkezésre állási zónában a magas rendelkezésre állás érdekében. Javasoljuk, hogy adatközpontonként/régiónként legalább egy GSM/szegmensrendezőt telepítsen. Emellett az alkalmazáskiszolgáló egy példánya minden rendelkezésre állási zónában üzembe lesz helyezve, amely szegmenscsoportot tartalmaz. Ezzel a beállítással az alkalmazás alacsonyan tarthatja az alkalmazáskiszolgáló és az adatbázis/szegmenscsoport közötti késést. Ha egy adatbázis meghibásodik, az alkalmazáskiszolgáló a készenléti adatbázissal azonos zónában képes kezelni a kéréseket az adatbázis-szerepkör áttűnése után. Azure-alkalmazás átjáró és a szegmens igazgatója ennek megfelelően nyomon követi a kérések és válaszok késését, valamint a kérelmek átirányítását.

Alkalmazás szempontjából az ügyfélrendszer kérést intéz Azure-alkalmazás Átjáróhoz vagy más terheléselosztási technológiákhoz az Azure-ban, amely átirányítja a kérést az ügyfélhez legközelebbi régióba. Azure-alkalmazás Átjáró a ragadós munkameneteket is támogatja, így az ugyanabból az ügyfélből érkező kérések ugyanarra az alkalmazáskiszolgálóra lesznek irányítva. Az alkalmazáskiszolgáló kapcsolatkészletezést használ az adatelérési illesztőprogramokban. Ez a funkció olyan illesztőprogramokban érhető el, mint a JDBC, a ODP.NET és az OCI. Az illesztőprogramok felismerhetik a kérés részeként megadott szegmenskulcsokat. A JDBC-ügyfelekhez készült Oracle Univerzális Csatlakozás ion-készlet (UCP) lehetővé teszi a nem Oracle-alkalmazás-ügyfelek, például az Apache Tomcat és az IIS számára az Oracle Sharding használatát. További információ: A megosztott UCP-készlet áttekintése az adatbázis-skálázáshoz.

A kezdeti kérés során az alkalmazáskiszolgáló a régió szegmensigazgatójához csatlakozik, hogy lekérje annak a szegmensnek az útválasztási adatait, amelyhez a kérést irányítani kell. Az átadott skálázási kulcs alapján a rendező az alkalmazáskiszolgálót a megfelelő szegmenshez irányítja. Az alkalmazáskiszolgáló egy térkép létrehozásával gyorsítótárazza ezeket az információkat, és a későbbi kérések esetében átadja a szegmens-igazgatónak, és a kérelmeket egyenesen a szegmensre irányítja.

Oracle-horizontális skálázás a GoldenGate-lel

Az alábbi ábra egy referenciaarchitektúra az Oracle Sharding és az Oracle GoldenGate számára az egyes szegmensek régión belüli magas rendelkezésre állásához. Az előző architektúrával ellentétben ez az architektúra csak egyetlen Azure-régióban jeleníti meg a magas rendelkezésre állást, több rendelkezésre állási zónával. Az Oracle GoldenGate használatával az előző példához hasonlóan többrégiós, magas rendelkezésre állású, szegmenses adatbázist is üzembe helyezhet.

Diagram that shows Oracle Database Sharding using availability zones with GoldenGate.

Az előző referenciaarchitektúra a rendszer által felügyelt horizontális skálázási módszerrel szilánkozza az adatokat. Mivel az Oracle GoldenGate-replikáció egy adattömb szintjén történik, az egyik szegmensbe replikált adatok fele replikálható egy másik szegmensbe. A másik fele egy másik szegmensbe replikálható.

Az adatok replikálásának módja a replikációs tényezőtől függ. Két replikációs tényezővel a szegmenscsoportban lévő három szegmens mindegyik adattömbjének két példánya van. Hasonlóképpen, a szegmenscsoportban három és három szegmensből álló replikációs tényező esetén az egyes szegmensekben lévő összes adat replikálva lesz a szegmenscsoport minden többi szegmensére. A szegmenscsoport egyes szegmensei eltérő replikációs tényezővel rendelkezhetnek. Ez a beállítás segít hatékonyan meghatározni a magas rendelkezésre állási és vészhelyreállítási tervet egy szegmenscsoporton belül és több szegmenscsoportban.

Az előző architektúrában az A szegmenscsoport és a B szegmenscsoport is ugyanazokat az adatokat tartalmazza, de különböző rendelkezésre állási zónákban található. Ha az A és a B szegmenscsoport is azonos replikációs tényezővel rendelkezik, a rendszer a szegmenses tábla minden sorát/adattömbjét hatszor replikálja a két szegmenscsoportra. Ha az A szegmenscsoport replikációs tényezője három, a B szegmenscsoport pedig két replikációs tényezővel rendelkezik, minden sor/adattömb ötször replikálódik a két szegmenscsoportban.

Ez a beállítás megakadályozza az adatvesztést, ha példányszintű vagy rendelkezésre állási zónaszintű hiba történik. Az alkalmazásréteg képes olvasni és írni az egyes szegmensekbe. Az ütközések minimalizálása érdekében az Oracle Sharding egy fő adattömbet jelöl ki az egyes kivonatértékek tartományaihoz. Ez a funkció biztosítja, hogy egy adott adattömb írási kérelmei a megfelelő adattömbhöz legyenek irányítva. Az Oracle GoldenGate emellett automatikus ütközésészlelést és -feloldást is biztosít az esetleges ütközések kezeléséhez. A GoldenGate Oracle-skálázással való implementálásával kapcsolatos további információkért és korlátozásokért lásd: Az Oracle GoldenGate használata szilánkos adatbázissal.

Az előző architektúrában a magas rendelkezésre állás érdekében minden rendelkezésre állási zónában egy GSM/shard director van üzembe helyezve. Javasoljuk, hogy adatközpontonként vagy régiónként legalább egy GSM/shard directort telepítsen. Az alkalmazáskiszolgáló egy példánya minden rendelkezésre állási zónában üzembe van helyezve, amely szegmenscsoportot tartalmaz. Ezzel a beállítással az alkalmazás alacsonyan tarthatja az alkalmazáskiszolgáló és az adatbázis/szegmenscsoport közötti késést. Ha egy adatbázis meghibásodik, az alkalmazáskiszolgáló a készenléti adatbázissal azonos zónában képes kezelni a kéréseket az adatbázis-szerepkör áttűnése után. Azure-alkalmazás átjáró és a szegmens igazgatója ennek megfelelően nyomon követi a kérések és válaszok késését, valamint a kérelmek átirányítását.

Alkalmazás szempontjából az ügyfélrendszer kérést intéz Azure-alkalmazás Átjáróhoz vagy más terheléselosztási technológiákhoz az Azure-ban, amely átirányítja a kérést az ügyfélhez legközelebbi régióba. Azure-alkalmazás Átjáró a ragadós munkameneteket is támogatja, így az ugyanabból az ügyfélből érkező kérések ugyanarra az alkalmazáskiszolgálóra lesznek irányítva. Az alkalmazáskiszolgáló kapcsolatkészletezést használ az adatelérési illesztőprogramokban. Ez a funkció olyan illesztőprogramokban érhető el, mint a JDBC, a ODP.NET és az OCI. Az illesztőprogramok felismerhetik a kérés részeként megadott szegmenskulcsokat. A JDBC-ügyfelekhez készült Oracle Univerzális Csatlakozás ion-készlet (UCP) lehetővé teszi a nem Oracle-alkalmazás-ügyfelek, például az Apache Tomcat és az IIS számára az Oracle Sharding használatát.

A kezdeti kérés során az alkalmazáskiszolgáló a régió szegmensigazgatójához csatlakozik, hogy lekérje annak a szegmensnek az útválasztási adatait, amelyhez a kérést irányítani kell. Az átadott skálázási kulcs alapján a rendező az alkalmazáskiszolgálót a megfelelő szegmenshez irányítja. Az alkalmazáskiszolgáló egy térkép létrehozásával gyorsítótárazza ezeket az információkat, és a későbbi kérések esetében átadja a szegmens-igazgatónak, és a kérelmeket egyenesen a szegmensre irányítja.

Javítás és karbantartás

Amikor oracle számítási feladatokat helyez üzembe az Azure-ban, a Microsoft gondoskodik az összes gazdagép operációsrendszer-szintű javításáról. A Microsoft előre közli az operációs rendszer tervezett karbantartását az ügyfelekkel. Két kiszolgáló két különböző rendelkezésre állási zónából soha nem lesz egyszerre javítva. A virtuális gépek karbantartásával és javításával kapcsolatos további információkért tekintse meg az Azure-beli virtuális gépek rendelkezésre állási lehetőségeit.

A virtuális gép operációs rendszerének javítása automatizálható az Azure Automation Update Management használatával. Az Oracle-adatbázis javítása és karbantartása automatizálható és ütemezhető az Azure Pipelines vagy az Azure Automation Update Management használatával az állásidő minimalizálása érdekében. A folyamatos teljesítésről és a kék/zöld üzemelő példányokról további információt a progresszív expozíciós technikákban talál.

Architektúra és tervezési szempontok

  • Fontolja meg a hyperthreaded memóriaoptimalizált virtuális gép használatát korlátozott alapszintű virtuális processzorokkal az Oracle Database virtuális géphez a licencelési költségek megtakarítása és a teljesítmény maximalizálása érdekében. Több prémium vagy ultralemez (felügyelt lemez) használata a teljesítményhez és a rendelkezésre álláshoz.
  • Felügyelt lemezek használata esetén előfordulhat, hogy a lemez/eszköz neve újrainduláskor megváltozik. Javasoljuk, hogy a név helyett az eszköz UUID azonosítóját használja, hogy a csatlakoztatások az újraindítás sprite-jében is megmaradjanak. További információ: Az új fájlrendszer hozzáadása a /etc/fstab fájlhoz.
  • A rendelkezésre állási zónák használatával magas rendelkezésre állást érhet el a régióban.
  • Fontolja meg az ultralemezek használatát, ha elérhető vagy prémium szintű lemezeket használ az Oracle-adatbázishoz.
  • Fontolja meg egy készenléti Oracle-adatbázis beállítását egy másik Azure-régióban az Oracle Data Guard használatával.
  • Fontolja meg a közelségi elhelyezési csoportok használatát az alkalmazás és az adatbázisszint közötti késés csökkentése érdekében.
  • Az Azure-beli virtuális gépek maximális hálózati sávszélessége (általában) magasabb, mint a lemez maximális átviteli sebessége ugyanazon termékváltozaton. Nagyobb átviteli sebességet érhet el ugyanazon a virtuálisgép-termékváltozaton, vagy kisebb virtuálisgép-termékváltozatot is használhat nagy teljesítményű, alacsony késésű hálózati tárolók, például az Azure NetApp Files használatával. adatbázishoz.
  • Az Oracle Enterprise Manager beállítása felügyelethez, monitorozáshoz és naplózáshoz.
  • Fontolja meg az Oracle Automatic Storage Management használatát az adatbázis egyszerűsített tárolókezeléséhez.
  • Az Azure Pipelines használatával állásidő nélkül kezelheti az adatbázis javításait és frissítéseit.
  • Módosítsa az alkalmazáskódot úgy, hogy natív felhőbeli mintákat adjon hozzá, amelyek segíthetnek az alkalmazás rugalmasságában. Fontolja meg az olyan mintákat, mint az újrapróbálkozási minta, az áramkör-megszakító minta és a felhőtervezési minták útmutatójában meghatározott egyéb minták.

Következő lépések

Tekintse át a forgatókönyvre vonatkozó alábbi Oracle-referenciacikkeket.