Megbízhatóság az Azure DocumentDB-ben

Ez a cikk részletes információkat tartalmaz a rendelkezésre állási zónákkal , valamint a régiók közötti vészhelyreállítással és az Azure DocumentDB üzletmenet-folytonosságával kapcsolatos regionális rugalmasságról.

Az Azure megbízhatóságának architekturális áttekintéséért tekintse meg az Azure megbízhatóságát.

Rendelkezésre állási zóna támogatása

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

A rendelkezésre állási zónák támogatásának megszerzéséhez engedélyeznie kell a magas rendelkezésre állást (HA).

A HA a fürt minden szegmensének készenléti replikáinak karbantartásával elkerüli az adatbázis állásidejét. Ha egy szegmens leáll, az Azure DocumentDB a sikertelen szegmensből a készenléti replikára váltja a bejövő kapcsolatokat.

Ha a HA engedélyezve van egy olyan régióban, amely támogatja a rendelkezésre állási zónákat, a HA replika szegmensei az elsődleges szegmensektől eltérő rendelkezésre állási zónában vannak kiépítve. A HA-replikák csak akkor kapnak kéréseket az ügyfelektől, ha az elsődleges szeletük meghibásodik.

Ha a HA le van tiltva, minden szegmens saját helyileg redundáns tárolóval (LRS) rendelkezik az Azure Storage szolgáltatás által karbantartott három szinkron replikával. Egyetlen replikahiba esetén az Azure Storage szolgáltatás észleli a hibát, és transzparensen újra létrehozza a releváns adatokat. Az LRS-tároló tartósságáról a Redundancia beállításainak összegzése című részben tájékozódhat. Ha azonban egy régió meghibásodik, nagy mértékű állásidő és lehetséges adatvesztés kockázata is fennáll.

Erőforrás létrehozása engedélyezett rendelkezésre állási zónákkal

A rendelkezésre állási zónák engedélyezéséhez engedélyeznie kell a magas szintű rendelkezésre állást (HA) a fürt létrehozásakor vagy egy meglévő fürt Méretezés szakaszában az Azure portálon.

Régiók közötti vészhelyreállítás és üzletmenet-folytonosság

A vészhelyreállítás (DR) olyan gyakorlatokra utal, amelyeket a szervezetek a nagy hatású események, például természeti katasztrófák vagy sikertelen üzembe helyezések helyreállítására használnak, amelyek állásidőt és adatvesztést eredményeznek. A katasztrófa okától függetlenül a legjobb megoldás egy jól definiált és tesztelt DR-terv, valamint egy olyan alkalmazásterv, amely aktívan támogatja a DR-t. A vészhelyreállítási terv létrehozása előtt tekintse meg vészhelyreállítási stratégiatervezésére vonatkozó javaslatokat.

A DR esetében a Microsoft a megosztott felelősségi modellt használja. Ebben a modellben a Microsoft biztosítja, hogy az alapinfrastruktúra és a platformszolgáltatások elérhetők legyenek. Számos Azure-szolgáltatás azonban nem replikálja automatikusan az adatokat, és nem esik vissza egy meghibásodott régióból egy másik engedélyezett régióba történő keresztreplikáláshoz. Ezeknél a szolgáltatásoknál Ön a felelős a számítási feladatokhoz használható vészhelyreállítási terv beállításáért. Az Azure platformszolgáltatásként (PaaS) futó alkalmazások többsége funkciókkal és útmutatással segíti a katasztrófaelhárítást. A szolgáltatásspecifikus funkciókat használva támogathatja a gyors helyreállítást, hogy segítse a katasztrófa utáni helyreállítási terv (DR-terv) fejlesztését.

Azure DocumentDB támogatja a többrégiós fürtök szolgáltatás által felügyelt automatikus feladatátvételét. Az egyrégiós üzemelő példányok esetében a magas rendelkezésre állás és a vészhelyreállítás tervezése kritikus lépés a megoldás skálázása során.

Vészhelyreállítás egyrégiós földrajzi területen

Az üzemidő maximalizálása érdekében tervezze meg előre az üzletmenet folytonosságát, és készüljön fel a vészhelyreállításra az Azure DocumentDB-vel.

Bár az Azure-szolgáltatások úgy vannak kialakítva, hogy maximalizálják az üzemidőt, előfordulhatnak nem tervezett szolgáltatáskimaradások. A vészhelyreállítási terv biztosítja, hogy rendelkezik a regionális szolgáltatáskimaradások kezelésére vonatkozó stratégiával.

Az Azure DocumentDB rendszeres időközönként automatikusan biztonsági másolatot készít az adatokról. Az automatikus biztonsági mentések az adatbázis-műveletek teljesítményét vagy rendelkezésre állását nem befolyásolják. A rendszer automatikusan elvégzi az összes biztonsági mentést a háttérben, és a tárolási szolgáltatás forrásadataitól elkülönítve tárolja őket. Ezek az automatikus biztonsági mentések akkor hasznosak, ha véletlenül törli vagy módosítja az erőforrásokat, és később szükség van az eredeti verziókra.

Az automatikus biztonsági mentések különböző időközönként kerülnek megőrzésre attól függően, hogy a klaszter jelenleg aktív vagy nemrégiben lett törölve.

Megőrzési időszak
Aktív klaszterek 35 nap
Törölt klaszterek 7 nap

Tervezés magas rendelkezésre álláshoz

A magas rendelkezésre állást (HA) engedélyezni kell az éles számítási feladatokat futtató kritikus Azure DocumentDB-fürtök esetében. Ha-kompatibilis fürtökben minden szegmens elsődlegesként szolgál, valamint egy másik rendelkezésre állási zónában kiépített készenléti szegmenst. Az elsődleges és a másodlagos szegmens közötti replikáció alapértelmezés szerint szinkron. Az adatbázis minden módosítása az elsődleges és a másodlagos (készenléti) szegmensen is megmarad, mielőtt az adatbázis válasza érkezik.

A szolgáltatás állapotellenőrzéseket és szívveréseket tart fenn a fürt minden elsődleges és másodlagos szegmensében. Ha egy elsődleges szegmens zóna vagy regionális kimaradás miatt elérhetetlenné válik, a rendszer automatikusan előlépteti a másodlagos szegmenst az új elsődlegesként, és egy későbbi másodlagos szegmenst hoz létre az új elsődleges számára. Ezenkívül ha egy másodlagos szegmens elérhetetlenné válik, a szolgáltatás automatikusan létrehoz egy új másodlagos szegmenst az elsődleges adatok teljes másolatával.

Ha a szolgáltatás feladatátvételt indít el az elsődlegesről a másodlagos shardra, a rendszer zökkenőmentesen és automatikusan irányítja át a kapcsolatokat az új elsődleges shardra.

Az elsődleges és a másodlagos szegmensek közötti szinkron replikáció nem garantálja az adatvesztést feladatátvétel esetén.

Következő lépések

  • Last updated on