Share via

Üzletmenet-folytonosság és vészhelyreállítás áttekintése

  • Cikk

Az Üzletmenet folytonossága és vészhelyreállítás az Azure-ban Data Explorer lehetővé teszi, hogy vállalkozása a fennakadások miatt továbbra is működjön. Ez a cikk a rendelkezésre állást (régión belüli) és a vészhelyreállítást ismerteti. Ismerteti a rugalmas Azure-Data Explorer üzembe helyezés natív képességeit és architekturális szempontjait. Részletesen ismerteti az emberi hibák utáni helyreállítást, a magas rendelkezésre állást, majd a vészhelyreállítási konfigurációkat. Ezek a konfigurációk olyan rugalmassági követelményektől függnek, mint a helyreállítási pont célkitűzése (RPO) és a helyreállítási időkorlát (RTO), a szükséges erőfeszítés és a költségek.

Zavaró események enyhítése

Emberi hiba

Az emberi hibák elkerülhetetlenek. A felhasználók véletlenül elvethetnek egy fürtöt, adatbázist vagy táblát.

Fürt vagy adatbázis véletlen törlése

A fürt vagy adatbázis véletlen törlése helyreállíthatatlan művelet. Az Azure Data Explorer erőforrás tulajdonosaként az Azure-erőforrásszinten elérhető törlési zárolási képesség engedélyezésével megakadályozhatja az adatvesztést.

Tábla véletlen törlése

A tábla rendszergazdai engedélyekkel vagy magasabb szintű engedélyekkel rendelkező felhasználók elvethetik a táblákat. Ha az egyik felhasználó véletlenül elvet egy táblát, az paranccsal helyreállíthatja .undo drop table azt. Ahhoz, hogy ez a parancs sikeres legyen, először engedélyeznie kell a helyreállíthatósági tulajdonságot a megőrzési szabályzatban.

Külső tábla véletlen törlése

A külső táblák olyan Kusto-lekérdezési sémaentitások, amelyek az adatbázison kívül tárolt adatokra hivatkoznak. Egy külső tábla törlése csak a tábla metaadatait törli. Helyreállításához futtasd újra a táblalétrehozási parancsot. Használja a helyreállítható törlési képességet a fájl/blob véletlen törlése vagy felülírása ellen a felhasználó által konfigurált ideig.

Az Azure Data Explorer magas rendelkezésre állása

A magas rendelkezésre állás az Azure-Data Explorer, összetevőinek és mögöttes függőségeinek hibatűrésére utal egy Azure-régióban. Ez a hibatűrés kiküszöböli az egyetlen meghibásodási pontot (SPOF) a megvalósításban. Az Azure Data Explorer magas rendelkezésre állása magában foglalja a megőrzési réteget, a számítási réteget és a vezető követő konfigurációt.

Adatmegőrzési réteg

Az Azure Data Explorer az Azure Storage-t használja tartós adatmegőrzési rétegként. Az Azure Storage automatikusan biztosítja a hibatűrést, és az alapértelmezett beállítás helyileg redundáns tárolást (LRS) kínál egy adatközponton belül. A rendszer három replikát őriz meg. Ha használat közben elveszik egy replika, a rendszer egy másik példányt is üzembe helyez, megszakítás nélkül. A zónaredundáns tárolás (ZRS) további rugalmasságot biztosít, amely intelligensen helyezi el a replikákat az Azure regionális rendelkezésreállási zónáiban a maximális hibatűrés érdekében, további költségek mellett. A ZRS-kompatibilis tároló automatikusan konfigurálva lesz, amikor az Azure Data Explorer-fürtöt üzembe helyezi a Availability Zones.

Számítási réteg

Az Azure Data Explorer egy elosztott számítástechnikai platform, amely a méretezéstől és a csomópontszerepkulátor típusától függően két-több csomópontot tartalmazhat. A kiépítéskor válassza ki a rendelkezésre állási zónákat a csomópont üzembe helyezésének elosztásához a zónák között a régión belüli maximális rugalmasság érdekében. A rendelkezésre állási zóna meghibásodása nem eredményez teljes leállást, hanem a teljesítménycsökkenést a zóna helyreállításáig.

Vezetőkövető fürtkonfiguráció

Az Azure Data Explorer opcionális követői képességet biztosít a vezetőfürthöz, amelyet más követőfürtök követnek a vezető adataihoz és metaadataihoz való írásvédett hozzáféréshez. A vezető módosításai, például createa , appendés drop automatikusan szinkronizálódnak a követővel. Bár a vezetők az Azure-régiókra is kiterjedhetnek, a követő fürtöket ugyanabban a régióban kell üzemeltetni, mint a vezető. Ha a vezetőfürt leállt, vagy az adatbázisok vagy táblák véletlenül el lettek dobva, a követő fürtök elveszítik a hozzáférést, amíg helyre nem áll a hozzáférés a vezetőben.

Azure-beli rendelkezésre állási zóna kimaradása

Az Azure rendelkezésre állási zónák egyedi fizikai helyek ugyanabban az Azure-régióban. Megvédhetik az Azure Data Explorer-fürt számításait és adatait a részleges régióhiba ellen. A zónahiba egy rendelkezésre állási forgatókönyv, mivel régión belüli.

Kitűzhet egy Azure-Data Explorer-fürtöt a többi csatlakoztatott Azure-erőforrással megegyező zónába. A rendelkezésre állási zónák engedélyezésével kapcsolatos további információkért lásd: Fürt létrehozása.

Megjegyzés

A rendelkezésre állási zónákba való üzembe helyezés fürt létrehozásakor lehetséges, vagy később migrálható.

Azure-adatközpont kimaradása

Az Azure rendelkezésre állási zónái költségekkel járnak, és egyes ügyfelek úgy döntenek, hogy zónaredundancia nélkül telepítik azokat. Egy ilyen Azure-Data Explorer üzembe helyezés esetén az Azure-adatközpont kimaradása fürtkimaradást eredményez. Az Azure-adatközpont kimaradásának kezelése tehát megegyezik az Azure-régió kimaradásának kezelésével.

Azure-régió kimaradása

Az Azure Data Explorer nem biztosít automatikus védelmet egy teljes Azure-régió kimaradása ellen. Az üzleti hatás minimalizálása érdekében, ha ilyen kimaradás történik, több Azure-Data Explorer-fürt az Azure párosított régióiban. A helyreállítási idő célkitűzése (RTO), a helyreállítási pont célkitűzése (RPO), valamint a munkamennyiség és a költség szempontjai alapján több vészhelyreállítási konfiguráció is létezik. A költség- és teljesítményoptimalizálás az Azure Advisor javaslataival és az automatikus skálázás konfigurálásával lehetséges.

Vészhelyreállítási konfigurációk

Ez a szakasz a rugalmassági követelményektől (RPO és RTO), a szükséges erőfeszítésektől és költségektől függően több vészhelyreállítási konfigurációt ismertet.

A helyreállítási idő célkitűzése (RTO) a megszakítás utáni helyreállítás idejét jelenti. A 2 órás RTO például azt jelenti, hogy az alkalmazásnak a megszakítást követő két órán belül működőképesnek kell lennie. A helyreállítási pont célkitűzése (RPO) azt az időintervallumot jelenti, amely a megszakítások során előfordulhat, mielőtt az adott időszakban elveszett adatok mennyisége meghaladja az engedélyezett küszöbértéket. Ha például az RPO 24 óra, és egy alkalmazás 15 évvel ezelőtti adatokkal rendelkezik, azok továbbra is az elfogadott RPO paraméterein belül vannak.

A betöltési, feldolgozási és curii folyamatainak gondos tervezésre van szükségük a vészhelyreállítás tervezésekor. A betöltés az Azure-Data Explorer különböző forrásokból származó adataira vonatkozik; a feldolgozás átalakításokra és hasonló tevékenységekre utal; a kurálás a materializált nézetekre, a data lake-be irányuló exportálásokra stb. utal.

Az alábbiakban a népszerű vészhelyreállítási konfigurációkat ismertetjük, amelyekről az alábbiakban olvashat részletesen.

Aktív-aktív-aktív konfiguráció

Ezt a konfigurációt "always-on"-nak is nevezik. A kritikus fontosságú alkalmazástelepítések esetében, amelyek nem tűrik a kimaradást, több Azure-Data Explorer-fürtöt kell használnia az Azure párosított régióiban. Az összes fürttel párhuzamosan állítsa be a betöltést, a feldolgozást és a fürtöt. A fürt termékváltozatának a régiók között azonosnak kell lennie. Az Azure biztosítja, hogy a frissítéseket az Azure párosított régióiban is bevezetik és átszűrik. Az Azure-régió kimaradása nem okoz alkalmazáskimaradást. Előfordulhat, hogy késést vagy teljesítménycsökkenést tapasztal.

Active-active-active-n konfiguráció.

Konfigurálás RPO RTO Erőfeszítés Költségek
Active-Active-Active-n 0 óra 0 óra Alacsonyabb Legmagasabb

Active-Active konfiguráció

Ez a konfiguráció megegyezik az aktív-aktív-aktív konfigurációval, de csak két Azure-párosított régiót érint. Konfigurálja a kettős betöltést, a feldolgozást és a gyógyítást. A felhasználók a legközelebbi régióba lesznek irányítva. A fürt termékváltozatának azonosnak kell lennie a régiók között.

Aktív-aktív konfiguráció.

Konfigurálás RPO RTO Erőfeszítés Költségek
Aktív-aktív 0 óra 0 óra Alacsonyabb Magas

készenléti konfiguráció Active-Hot

A Active-Hot konfiguráció hasonló az Aktív-Aktív konfigurációhoz kettős betöltés, feldolgozás és cur esetén. Bár a készenléti fürt online állapotban van a betöltéshez, a feldolgozáshoz és a gondnoksághoz, nem érhető el a lekérdezéshez. A készenléti fürtnek nem kell ugyanabban a termékváltozatban lennie, mint az elsődleges fürtnek. Lehet kisebb termékváltozatú és skálázású, ami azt eredményezheti, hogy kevésbé teljesít. Vészhelyzet esetén a rendszer átirányítja a felhasználókat a készenléti fürtre, amely igény szerint vertikálisan felskálázható a teljesítmény növelése érdekében.

Aktív-gyakori elérésű készenléti konfiguráció.

Konfigurálás RPO RTO Erőfeszítés Költségek
Aktív–gyakori elérésű készenlét 0 óra Alacsony Közepes Közepes

Igény szerinti adat-helyreállítási konfiguráció

Ez a megoldás a legkisebb rugalmasságot (legmagasabb RPO és RTO) kínálja, a legalacsonyabb költséggel és a legnagyobb erőfeszítéssel. Ebben a konfigurációban nincs adat-helyreállítási fürt. Konfigurálja a válogatott adatok folyamatos exportálását (kivéve, ha nyers és köztes adatokra is szükség van) egy GRS (Georedundáns tárolás) konfigurált tárfiókba. Vészhelyreállítási forgatókönyv esetén az adat-helyreállítási fürtök felgyülemlnek. Ekkor a rendszer DLL-eket, konfigurációkat, szabályzatokat és folyamatokat alkalmaz. A rendszer a kustoCreationTime betöltési tulajdonsággal betölti az adatokat a tárolóból, hogy túlterhelje az alapértelmezett betöltési időt a rendszeridőre.

Igény szerinti adat-helyreállítási fürtkonfiguráció.

Konfigurálás RPO RTO Erőfeszítés Költségek
Igény szerinti adat-helyreállítási fürt Legmagasabb Legmagasabb Legmagasabb Legalacsonyabb

A vészhelyreállítás konfigurációs lehetőségeinek összefoglalása

Konfigurálás Rugalmasság RPO RTO Erőfeszítés Költségek
Active-Active-Active-n Legmagasabb 0 óra 0 óra Alacsonyabb Legmagasabb
Aktív-aktív Magas 0 óra 0 óra Alacsonyabb Magas
Aktív–gyakori elérésű készenlét Közepes 0 óra Alacsony Közepes Közepes
Igény szerinti adat-helyreállítási fürt Legalacsonyabb Legmagasabb Legmagasabb Legmagasabb Legalacsonyabb

Ajánlott eljárások

Függetlenül attól, hogy melyik vészhelyreállítási konfigurációt választotta, kövesse az alábbi ajánlott eljárásokat:

  • Minden adatbázis-objektumot, szabályzatot és konfigurációt meg kell őrizni a verziókövetésben, hogy a kiadásautomatizálási eszközből ki lehessen őket adni a fürtnek. További információ: Az Azure DevOps támogatása az Azure Data Explorer.
  • Ellenőrzési rutinokat tervezhet, fejleszthet és implementálhat, hogy az összes fürt szinkronban legyen az adatok szempontjából. Az Azure Data Explorer támogatja a fürtök közötti csatlakozásokat. A táblák egyszerű darabszáma vagy sorai segíthetnek az ellenőrzésben.
  • A kiadási eljárásoknak olyan irányítási ellenőrzéseket és egyenlegeket kell magukban foglalnia, amelyek biztosítják a fürtök tükrözését.
  • Legyen teljes mértékben ismerője annak, hogy mire van szükség a fürtök alapoktól való létrehozásához.
  • Hozzon létre egy ellenőrzőlistát az üzembehelyezési egységekről. A lista egyedi lesz az igényeinek megfelelően, de tartalmaznia kell a következőket: üzembehelyezési szkriptek, betöltési kapcsolatok, BI-eszközök és egyéb fontos konfigurációk.

Következő lépés

Üzletmenet-folytonossági és vészhelyreállítási megoldások létrehozása