Üzletmenet-folytonosság és vészhelyreállítás az Oracle on Azure Virtual Machines célzóna-gyorsítójához

Ez a cikk az Azure-beli kezdőlap üzletmenet-folytonossági és vészhelyreállítási (BCDR) tervezési területén meghatározott szempontokra és javaslatokra épül. Ez a cikk ezt az útmutatást követi, és ismerteti az Oracle számítási feladatok Azure-beli infrastruktúrájú virtuális gépeken való üzembe helyezésének BCDR-lehetőségeivel kapcsolatos tervezési szempontokat és ajánlott eljárásokat.

Az Azure olyan szolgáltatásokat biztosít, amelyek segítségével magas rendelkezésre állású és rugalmas architektúrákat tervezhet. Ez az útmutató különböző lehetőségeket és ajánlott eljárásokat ismertet, amelyek segítenek az Oracle-adatbázisok magas rendelkezésre állásának és vészhelyreállításának megtervezésében az Azure Virtual Machines kezdőlap-gyorsítón. Azt is ismerteti, hogyan konfigurálhatja a kísérő Azure-szolgáltatásokat a megoldás magas szintű rendelkezésre állásának eléréséhez.

Kezdj hozzá

A számítási feladatok környezetének rugalmas architektúrájának létrehozásához határozza meg a megoldás rendelkezésre állási követelményeit a helyreállítási időre vonatkozó célkitűzés (RTO) és a helyreállítási pont célkitűzése (RPO) alapján a különböző meghibásodási szintek esetén. Az RTO az a maximális idő, ameddig egy alkalmazás nem érhető el egy incidens bekövetkezése után. Az RPO a katasztrófa során bekövetkező adatvesztés maximális mennyisége. Miután meghatározta a megoldás követelményeit, tervezze meg az architektúrát úgy, hogy a rugalmasság és a rendelkezésre állás meghatározott szintjeit biztosítsa.

Az Azure-beli számítási feladatokon futó Oracle elsősorban az Oracle Data Guardot használja, amely egy beépített Oracle Database Enterprise Edition szolgáltatás, amely replikációs technológiát használ. A Data Guard használatával magas rendelkezésre állási és vészhelyreállítási igényeket is kielégíthet. A Data Guard három védelmi módot kínál: maximális teljesítményt, maximális rendelkezésre állást és maximális védelmet. Válassza ki a védelmi módot az architekturális terv, valamint az adott RPO- és RTO-követelmények alapján.

A számítási feladat konfigurálása magas rendelkezésre állásra

Az Oracle számítási feladatokat futtató Azure Virtual Machines-példányok kihasználhatják az Azure Virtual Machine Scale Sets architektúrát, különösen a rugalmas vezénylési módot. A magas rendelkezésre állású konfiguráció közel valós idejű adatreplikációt biztosít potenciálisan gyors feladatátvételi képességekkel. A magas rendelkezésre állású konfiguráció nem nyújt védelmet az Azure-adatközpont vagy régió szintű hibák ellen.

Válassza ki a megfelelő magas rendelkezésre állási lehetőséget

Az alábbi folyamatábrán kiválaszthatja az Oracle-adatbázis legjobb magas rendelkezésre állási lehetőségét.

A Data Guard használata maximális rendelkezésre állási módban a magas rendelkezésre állás érdekében

A Data Guard maximális rendelkezésre állási módban biztosítja a legmagasabb rendelkezésre állást nulla adatvesztési ígérettel (RPO=0) a normál műveletekhez. A Virtual Machine Scale Sets rugalmas vezénylésén belül létrehozott két Oracle-adatbázis-kiszolgáló magas rendelkezésre állású konfigurációjához az Azure 99,95% szolgáltatás rendelkezésre állását biztosítja egy szolgáltatói szerződéshez (SLA) a tartalék tartományok között elosztott példányokhoz. Az Azure 99,99% szolgáltatás rendelkezésre állását biztosítja a rendelkezésre állási zónák között elosztott példányok számára. További információ: Virtuálisgép-méretezési csoportok magas rendelkezésre állása.

A Data Guard Azure-beli részletes konfigurációját lásd: Oracle Data Guard implementálása Linux-alapú Azure-beli virtuális gépen.

A Data Guard használata maximális védelmi módban a magas rendelkezésre állás érdekében

Ha tranzakciósan konzisztens másolatra van szüksége az adatbázisról, fontolja meg a Data Guard maximális védelmi módban való használatát. A maximális védelmi mód azonban nem teszi lehetővé a tranzakciók folytatását, ha a készenléti adatbázis nem érhető el. Ezért a Virtual Machines méretezési csoportok rugalmas vezénylésének használata ellenére az SLA 99,9 x 99,9%% = 99,8%-re csökken maximális védelmi mód használata esetén. Ez a konfiguráció biztosítja az adatok konzisztens másolását, de nem feltétlenül növeli a rendelkezésre állást.

Az architektúra egyéb attribútumai megegyeznek a maximális rendelkezésre állási móddal. Például az RPO nulla, az RTO pedig legfeljebb két perc.

Fontolja meg a magas rendelkezésre állás megvalósításának egyéb módjait

A következő szakaszok a magas rendelkezésre állással kapcsolatos speciális szempontokat ismertetik.

Rendelkezésre állási zónák használata a magasabb rendelkezésre állás javításához

Az Azure rendelkezésre állási zónái olyan Azure-adatközpontok, amelyek ugyanabban az Azure-régióban találhatók. A rendelkezésre állási zónák kétezredmásodpercnél kisebb oda-vissza késéssel rendelkeznek. A rendelkezésre állási zónákat általában vészhelyreállítási célokra használja, de a magas rendelkezésre állás javítására is használhatja őket. Ha igen, meg kell győződnie arról, hogy a megoldás a rendelkezésre állási zónák által biztosított késéssel és átviteli sebességgel futtatható.

A Virtual Machine Scale Sets rugalmas vezényléssel rendelkező rendelkezésre állási zónák előnye, hogy a virtuális gépek rendelkezésre állási SLA-ja 99,99%-re nő.

Megosztott tárolófürtözés használata a magas rendelkezésre állás érdekében

A megosztott tárolófürtözési technológiák egyedi attribútumokat biztosítanak, amelyek segíthetnek az üzleti célok elérésében. Megvalósíthat például egy Pacemaker és Corosync (PCS) fürtöt megosztott tárolóval. Felügyelt lemezeket vagy Azure NetApp Files használhat megosztott tárolóként a PCS-fürtpéldányokhoz. A PCS-fürtök nem duplikálják az adatokat. Statikus IP-címmel vagy IP-hálózatnévvel rendelkező virtuális IP-szolgáltatást biztosít, amely nem változik a feladatátvételek között.

Megjegyzés:

A PCS-fürt nem Oracle-tanúsítvánnyal rendelkező megoldás. Tartsa szem előtt ezt a tényezőt a magas rendelkezésre állású architektúra kiválasztásakor.

Közelségi elhelyezési csoportok használata

A lehető legkisebb késés érdekében helyezze a virtuális gépeket a lehető legközelebb. Ezeket egy közelségi elhelyezési csoporton belül is üzembe helyezheti. A közelségi elhelyezési csoport egy logikai csoportosítás, amely biztosítja, hogy az Azure számítási erőforrásai fizikailag közel legyenek egymáshoz. A közelségi elhelyezési csoportok az alacsony késést igénylő számítási feladatokhoz hasznosak.

A számítási feladat konfigurálása vészhelyreállításhoz

A vészhelyreállítási architektúra rugalmasságot biztosít az Azure-adatközpontokat vagy -régiókat érintő hibák, illetve az alkalmazások működését akadályozó hibák ellen egy teljes régióban. Ilyen esetben a teljes számítási feladatot át kell helyeznie egy másik adatközpontba vagy régióba.

Válassza ki a vészhelyreállítási architektúrát a megoldás követelményei alapján. A követelményeket az RTO és az RPO alapján határozza meg. A vészhelyreállítási architektúrák kivételes meghibásodási esetekre szolgálnak, így a feladatátvételi folyamatok manuálisak. A magas rendelkezésre állású kialakításban a feladatátvételi folyamatok automatikusak. A katasztrófa utáni helyreállítási architektúrában lazább követelményekkel kell rendelkeznie az RTO-ra és az RPO-ra, ami pénzt takarít meg.

Ez a cikk olyan forgatókönyvekre összpontosít, amelyekben az elsődleges és a másodlagos kiszolgálók is az Azure-ban vannak. Vészhelyreállítási célokra egy helyszíni elsődleges kiszolgálóval és egy másodlagos kiszolgálóval is rendelkezhet az Azure-ban. További információ: Elsődleges helyszíni hely és vészhelyreállítási hely az Azure-ban.

Válassza ki a megfelelő katasztrófa utáni helyreállítási lehetőséget

Az alábbi folyamatábra segítségével válassza ki az Oracle-adatbázis legjobb vészhelyreállítási lehetőségét.

A Data Guard használata vészhelyreállításhoz

A Data Guard használatával replikálhatja az adatokat a vészhelyreállítási helyre. Használja ezt a webhelyet egy másik rendelkezésre állási zónaként ugyanabban a régióban vagy egy másik régióban az adatvédelmi követelményektől függően. A konfiguráció az éles hely rendelkezésre állási zóna struktúrájától is függ. A Data Guard vészhelyreállítási forgatókönyvben való implementációja hasonló a korábban tárgyalt magas rendelkezésre állási forgatókönyvhöz, néhány fontos különbséggel. Például:

• Ha a magas rendelkezésre állási forgatókönyvben feladatátvételt végez egy másodlagos replikára, a Azure Load Balancer úgy konfigurálja, hogy átirányítsa a kéréseket az új elsődleges adatbázispéldányra.

• Amikor feladatátvételt végez a vészhelyreállítási helyen, a teljes megoldást átadja az új helyre. A késési kihívások elkerülése érdekében általában konfigurálnia kell a feladatátvételt az alkalmazásszolgáltatásokhoz.

Ha a vészhelyreállítási hely egy másik régióban található, a követelményeknek megfelelően meg kell terveznie a feladatátvétel helyét.

Az egyetlen adatközponton belüli késés kisebb, mint az egymástól távol elkülönülő adatközpontok közötti késés, és sokkal kisebb, mint a különböző régiók közötti késés. Ezért a legkevésbé összetett és legolcsóbb megoldás a Data Guard maximális teljesítményű módban való használata vészhelyreállítási célokra. Ha a maximális teljesítmény módban túl nagy az adatvesztés lehetősége, használhatja a maximális rendelkezésre állási módot az Oracle Data Guard Far Sync mechanizmussal. A Far Sync-példány azonban aktiválja az Active Data Guard licencelést az elsődleges környezetben és a készenléti környezetben. További információ: Oracle-licenc részletei.

Emellett amikor Azure-régiók vagy adatközpontok között küld adatokat, kimenő költségeket kell fizetnie a vészhelyreállítási helyre küldött adatokért, például a naplók újraindításáért. Ha nem kell replikálnia az adatbázis összes adatát, az Oracle Golden Gate-alapú replikációval szükség szerint csak részleges adatokat replikálhat, ami csökkenti a kimenő forgalom költségeit.

Az Azure-beli Data Guard részletes konfigurációját lásd: Data Guard implementálása Linux-alapú Azure Linux rendszerű virtuális gépen.

A Golden Gate használata vészhelyreállításhoz

A Golden Gate egy logikai replikációs szoftver, amely valós idejű replikációra, szűrésre és adatok átalakítására használható egy forrásadatbázisból egy céladatbázisba vagy több elsődleges adatbázis között. Ez a funkció biztosítja, hogy a forrásadatbázis módosításai közel valós időben replikálódjanak, így a céladatbázis naprakész lesz a legújabb adatokkal.

A Golden Gate használatával adatokat replikálhat egy elsődleges adatbázisból egy másodlagos adatbázisba vészhelyreállítási konfigurációban. A Golden Gate különösen praktikus, ha csak az adatok egy részét kell megvédenie. A szükségtelen adatok replikálásának elkerülése érdekében a Golden Gate használatával szelektíven replikálhatja a táblákat, és kiszűrheti a táblasorokat a replikáció során.

A Golden Gate Azure-ban való implementálásával kapcsolatos részletes útmutatóért lásd: Golden Gate implementálása Linux-alapú Azure-beli virtuális gépen.

Biztonsági mentés használata vészhelyreállításhoz

A biztonsági mentés és visszaállítás a vészhelyreállítási architektúra hagyományos módszere. Az Azure-beli Oracle-adatbázisok vészhelyreállítási módszereként való biztonsági mentésnek két fő összetevője van:

• Bontsa ki és helyezze át az adatok biztonsági másolatát egy adatbázisból, hogy a vészhelyreállítási hely up-todátummal rendelkezzen.

• Biztosítsa a up-todátumú üzembe helyezést a vészhelyreállítási helyen. A hely frissítéséhez replikálja az összes hálózati összetevő, alkalmazáskiszolgáló és konfiguráció ugyanazt a központi telepítését a vészhelyreállítási helyre.

Az adatok replikálására számos biztonsági mentési lehetőség használható. További információ: Biztonsági mentési stratégiák az Oracle Database-hez az Azure-ban.

Fontolja meg az alábbi módszerek egyikét a vészhelyreállítási hely karbantartásához:

1. megközelítés: A további karbantartási erőfeszítések és költségek elkerülése érdekében ne tartson fenn fizikai üzembe helyezést a vészhelyreállítási helyen. Az infrastruktúrát kódként és helymegbízhatósági mérnöki eljárásokként használhatja adattárak fejlesztéséhez és karbantartásához. Ez az adattár konfigurációként replikálhatja a központi telepítést egy vészhelyreállítási helyre a feladatátvételkor. Ez a módszer optimalizálja a költségeket, mert nem használ fizikai erőforrásokat a feladatátvételig.

Fontos

Ha a feladatátvétel során teljesen teljesen létrehoz egy központi telepítést, meg kell győződnie arról, hogy az üzemelő példány megfelel a megoldás RTO-követelményeinek. Annak érdekében, hogy az üzembe helyezési kód ne legyen megszakadva, rutinszerűen szimulálnia és tesztelnie kell a vészhelyreállítási forgatókönyvet.

2. megközelítés: Az éles környezet skálázott verziójának üzembe helyezése és karbantartása. Olyan verzióval kell rendelkeznie, amely megfelelően működik egy kis számítási feladathoz, és amely szükség szerint felskálázható a feladatátvétel során az éles terhelés kiszolgálásához. Ezt a módszert gyakran használják, különösen olyan összetett üzemelő példányok esetén, amelyekben nem szeretné kockáztatni a teljes környezet létrehozását, vagy ha gyorsan szeretne feladatátvételt végezni az alacsony RTO biztosítása érdekében.

3. megközelítés: A teljes megoldást a vészhelyreállítási helyen helyezheti üzembe és tarthatja karban a leggyorsabb RTO- és feladatátvételi idők érdekében. Ez a módszer növeli a költségeket a teljesen redundáns infrastruktúra futtatása miatt.

Fontolja meg a vészhelyreállítás megvalósításának egyéb módjait

A következő szakaszok a vészhelyreállítással kapcsolatos speciális szempontokat ismertetik.

A Távoli szinkronizálás használata

A Far Sync nem javítja a magas rendelkezésre állási képességeket, de az Oracle-adatbázisok adatvesztés-védelmi képességeinek elérésére használható. Előfordulhat, hogy a számítási feladat nulla adatvesztést igényel, ha az elsődleges adatbázis meghibásodik. További információ: Oracle-referenciaarchitektúrák az Azure-ban.

Válassza ki a megfelelő adatreplikációs technológiát

A cikkben ismertetett technológiák mellett bármilyen technológiát használhat, amely megkönnyíti az adatreplikációt két Oracle-adatbázis között, hogy magas rendelkezésre állású replikát és vészhelyreállítási replikát tartson fenn az Azure-beli Oracle-adatbázisokhoz. A választott technológiának ki kell szolgálnia a megoldási követelményeket ezekben a kategóriákban.

Lappangás: A frissítések elsődleges adatbázisból másodlagos adatbázisokba való replikálásához szükséges időnek meg kell felelnie a megoldás követelményeinek.

Sávszélesség: Az adatok másodlagos adatbázisokba való replikálásához szükséges sávszélesség mennyisége és költsége a magas rendelkezésre állás és a vészhelyreállítás érdekében. Az Azure nagy sebességű hálózati infrastruktúrát biztosít a rendelkezésre állási zónák között. Ha vészhelyreállítási célokra más Azure-régiókba való replikációt fontolgatja, vegye figyelembe az Azure-adatközpontot elhagyó adatok sávszélességének mennyiségét és kimenő költségeit.

Ütközik: A replikáció elsődleges adatbázison történő tranzakciófeldolgozásra gyakorolt hatásának meg kell felelnie a megoldás követelményeinek.

Adatvesztés: Az elsődleges adatbázis hirtelen meghibásodása során várható adatvesztés mennyiségének meg kell felelnie a megoldás követelményeinek.

Teljes tulajdonlási költség: Vegye figyelembe a nem Microsoft által gyártott replikációs megoldások beszerzési költségeit, valamint a replikációs megoldás konfigurálásához és karbantartásához szükséges erőfeszítést. Ellenőrizze, hogy ezek a tényezők megfelelnek-e a megoldás követelményeinek.

Feladatátvételi példány optimalizálása

Ha a Data Guardot magas rendelkezésre állási módban vagy magas védelmi módban használja, konfigurálhatja az automatikus feladatátvételt, hogy az elsődleges kiszolgáló meghibásodása esetén a másodlagos kiszolgáló automatikusan létrejöjjön. Ha megfelelően konfigurálja az alkalmazáskiszolgálókat, biztosíthatja, hogy a feladatátvétel során szinte ne legyen alkalmazásállás.

Ebben az implementációban az adatbázisnak ugyanúgy kell futnia a feladatátvétel után. Ezért konfigurálnia kell egy másodlagos kiszolgálót, amely ugyanazzal a processzorral, memóriával és bemeneti/kimeneti (I/O) kapacitással rendelkezik, mint az elsődleges kiszolgáló. Nagy kapacitást kell fenntartania egy másodlagos kiszolgálóval, ami növeli az Azure-költségeket és az Oracle Database licencköltségeit. A másodlagos kiszolgáló általában nem dolgozza fel a felhasználói kéréseket.

Az Azure 99,9% rendelkezésre állást biztosít a rendelkezésre állási zónában lévő virtuális gépek számára. További információ: Virtuális gépek üzemidejére vonatkozó SLA. Ha adatreplikációs technológiával tartja fenn az adatbázis másodlagos replikáját ugyanabban a rendelkezésre állási zónában, egy másik rendelkezésre állási zónában vagy egy másik régióban, optimalizálhatja a másodlagos kapacitást.

Ezzel a megközelítéssel a másodlagos adatbázis a naprakész állapothoz szükséges kapacitással van konfigurálva. Hiba esetén a másodlagos adatbázis átméretezése az elsődleges adatbázissal megegyező kapacitásra lesz átméretezve. Ez a művelet csak hiba esetén történik. Tehát normál működés közben az elsődleges szerver költségének csak töredékét kell fizetnie. Az elsődleges adatbázis nem működik a hiba során, ezért nincs szükség más Oracle-adatbázis-licencekre.

A másodlagos adatbázis replikációs célként való üzemeltetéséhez szükséges kapacitás a használt replikációs technológiától függ. Lényegében a tranzakciós online tranzakciófeldolgozási (OLTP) rendszeren található számítási feladatok főként olvasási kérésekkel rendelkeznek. Az OLTP-alkalmazásokban gyakoriak például a 90% olvasási és 10% írási művelet vagy a 95% olvasási és 5% írási művelet. Az adatreplikáció lényegében a forrásadatbázisba írt kérések eredményét replikálja. Ezzel a beállítással a másodlagos adatbázis az elsődleges adatbázis kapacitásának 1/10-ével (ha 90% olvasási és 10% írási aránnyal rendelkezik) fog működni.

Automatizálja a feladatátvételi eljárásokat, hogy a feladatátvételi folyamat során megfeleljen a vállalati szabványoknak. A feladatátvételi eljárásokat úgy konfigurálhatja, hogy olyan kiszolgáló-átméretezési műveleteket tartalmazzanak, amelyek leegyszerűsítik a végpontok közötti folyamatot.

A hálózati topológia konfigurálása szolgáltatásvédelemhez és adatvédelemhez

A magas rendelkezésre állás és a vészhelyreállítás eléréséhez olyan pénzügyi és üzleti döntéseket kell hoznia, amelyek egyensúlyt teremtenek a helyreállítási idő és a lehetséges adatvesztés vagy RPO között az Oracle licencelési, virtuálisgép-karbantartási és adatátviteli költségeivel. Ha egyetlen Azure-beli virtuális gépen üzemeltet számítási feladatot, alacsony költséggel alapszintű védelmet kap a gyakori hardverhibák ellen. Egyetlen virtuális gép meghibásodása azonban valószínűleg leállást és adatvesztést okoz. Így az éles környezetekben tartalmazzon legalább egy másodlagos Oracle-adatbázist, amely egy külön virtuális gépen van üzemeltetve a Data Guard. A követelményektől függően használja az alábbi Data Guard-konfigurációk egyikét vagy többet az adatreplikációhoz:

• Optimális RTO és RPO. A késés minimalizálása érdekében építsen be egy másodlagos Oracle-adatbázist egy külön virtuális gépre ugyanazon a Virtual Machine Scale Sets rugalmas vezénylésen belül, és ugyanabban a rendelkezésre állási zónában, mint az elsődleges adatbázis. Ez a konfiguráció magas rendelkezésre állást és védelmet nyújt az egypéldányos hibák ellen.

• Adatvédelem az adatközpont meghibásodása ellen. Helyezze a másodlagos Oracle-adatbázist egy második rendelkezésre állási zónába, hogy magas rendelkezésre állási beállítást biztosítson, és védelmet nyújtson egy teljes rendelkezésre állási zóna meghibásodása esetén. Ez a konfiguráció akár két ezredmásodperces késéssel is rendelkezhet az elsődleges és a másodlagos adatbázis között, ami hatással lehet a teljesítményre, az RTO-kra és az RPO-kra.

• Adatvédelem regionális meghibásodás esetén. Az Azure regionális hibái miatti esetleges adatvesztés elleni védelem érdekében a másodlagos adatbázist egy másik régióban helyezheti el. Ez a konfiguráció 30 ezredmásodperc és 300 ezredmásodperc közötti késéssel rendelkezhet a régiók között, így előfordulhat, hogy nem felel meg az RTO- és RPO-céloknak. Ez a megoldás a regionális vészhelyreállításhoz a legjobb a magas rendelkezésre állás helyett.

Az üzletmenet-folytonosság integrált megközelítést igényel, amely a számítási feladat összes összetevőjét magában foglalja. A hálózati infrastruktúra az Azure-beli számítási feladatok elsődleges összetevője. A hálózati infrastruktúrának igazodnia kell a magas rendelkezésre álláshoz vagy a vészhelyreállítási architektúrához. Vegye figyelembe a következő hálózati infrastruktúra-tényezőket:

• A Data Guard magas rendelkezésre állást biztosít, és a legtöbb esetben elegendő támogatást nyújt a gyakori hibákhoz. A virtuális gépeket rugalmas vezénylésben helyezheti el. A hálózati késés csökkentése érdekében egyetlen megoldásban lévő összes szolgáltatásnak ugyanabban a rendelkezésre állási zónában kell lennie, és a szolgáltatásoknak ugyanazt a virtuális hálózatot kell megosztaniuk.

  A további védelem érdekében a virtuális gépeket stratégiailag külön rendelkezésre állási zónákban helyezheti el, nem pedig egyetlen rendelkezésre állási zónában. Ez a megközelítés megakadályozhatja az adatközpont meghibásodása során fellépő állásidőt.

• A maximális védelem érdekében egy másodlagos adatbázist az elsődleges adatbázis-régiótól eltérő Azure-régióban helyezhet el. A folyamatos frissítések alkalmazásához a Data Guard használatával valósíthatja meg a globális virtuális hálózatok közötti társviszony-létesítést. Ezzel a módszerrel privát módon alkalmazhatja az adatfrissítéseket a másodlagos régióra a Microsoft gerinchálózatán keresztül. Az erőforrások közvetlenül kommunikálnak átjárók, extra ugrások vagy a nyilvános interneten keresztüli átvitel nélkül.

  Ez a hálózati beállítás nagy sávszélességű, kis késésű kapcsolatot biztosít a különböző régiókban lévő társviszonyban lévő virtuális hálózatok között. A globális virtuális hálózatok közötti társviszony-létesítéssel nagy sebességű hálózaton keresztül csatlakoztathatja az elsődleges helyet egy másik régióban található vészhelyreállítási helyhez.

A különböző hibatípusokkal szembeni rugalmasság összefoglalása

Hibaforgatókönyv	Oracle az Azure-ban magas rendelkezésre állás vagy vészhelyreállítási forgatókönyv	RPO/RTO
Egykomponensű hiba, például gazdagép, állvány, hűtés, hálózat vagy áramkimaradás	Data Guard két csomóponttal ugyanabban a Virtual Machine Scale Sets rugalmas vezényléssel ugyanabban az adatközpontban: - Egyetlen példány meghibásodása ellen véd. - Állásidőt okoz, ha egy teljes adatközpont meghibásodik.	Ha az Observert használja a gyors indítású feladatátvételhez, valamint a Data Guard MAX_AVAILABILITY vagy MAX_PROTECTION módjához: - Az RPO nulla. - Az RTO legfeljebb 2 perc.
Adatközpont meghibásodása	Data Guard két csomóponttal külön rendelkezésre állási zónákban: - Védelmet nyújt az adatközpont meghibásodása ellen. - Állásidőt okoz, ha egy teljes régió meghibásodik. - Több feladatátvételi konfigurációt igényel az alkalmazáskiszolgálókhoz a hálózati késés kezeléséhez.	- Az RPO legfeljebb 5 perc. - Az RTO legfeljebb 5 perc. Ha MAX_PERFORMANCE módot és MAX_AVAILABILITY módot használ a Data Guardhoz: - Az RPO nulla. - Az RTO legfeljebb 5 perc.
Regionális hiba	Data Guard két csomóponttal külön Azure-régiókban: - Védelmet nyújt a regionális hibák ellen. - Több feladatátvételi konfigurációt igényel az alkalmazáskiszolgálókhoz a hálózati késés kezeléséhez.	Ha MAX_PERFORMANCE módot használ a Data Guardhoz: - Az RPO 10 perc vagy annál nagyobb. - Az RTO legfeljebb 15 perc.
Minden forgatókönyv: egyetlen összetevő, adatközpont és régió meghibásodása	Másik Azure-régióba szállított biztonsági másolatok: - Védelem a regionális hibák ellen. - Feladatátvétel során egy teljes Azure-környezet beállítása a célrégióban.	- Az RPO nagyobb vagy egyenlő, mint 24 óra. - Az RTO nagyobb vagy egyenlő, mint 4 óra.

Következő lépés

Ismerje meg az Oracle on Virtual Machines célzónagyorsító biztonságának tervezési szempontjait nagyvállalati szintű forgatókönyvben.

Biztonsági irányelvek az Oracle on Virtual Machines célzónagyorsítójához