Üzletmenet-folytonosság az Azure SQL Database-ben

A következőkre vonatkozik:Azure SQL Database

Üzletmenet-folytonossági az Azure SQL Database-ben olyan mechanizmusokra, szabályzatokra és eljárásokra utal, amelyek lehetővé teszik, hogy a vállalat továbbra is zavartalanul működjön a rendelkezésre állás, a magas rendelkezésre állás és a vészhelyreállítás biztosításával.


A rendelkezésre állás maximalizálására és a nagyobb üzletmenet-folytonosság elérésére vonatkozó előíró javaslatokért lásd:

Az SQL Database a legtöbb esetben olyan zavaró eseményeket kezel, amelyek felhőkörnyezetben fordulhatnak elő, és az alkalmazásokat és az üzleti folyamatokat folyamatosan futtatja. Vannak azonban olyan zavaró események, amelyekben a kockázatcsökkentés eltarthat egy ideig, például:

  • A felhasználó véletlenül töröl vagy frissít egy sort egy táblában.
  • A rosszindulatú támadó sikeresen törli az adatokat, vagy elvet egy adatbázist.
  • A katasztrofális természeti katasztrófaesemény egy adatközpontot vagy rendelkezésre állási zónát vagy régiót foglal le.
  • Ritka adatközpont, rendelkezésre állási zóna vagy régiószintű kimaradás konfigurációváltozás, szoftverhiba vagy hardverhiba miatt.

Magas rendelkezésre állás

Az Azure SQL Database alapvető rugalmassági és megbízhatósági ígérettel rendelkezik, amely védelmet nyújt a szoftver- vagy hardverhibák ellen. Az adatbázis biztonsági mentései automatikusan védik az adatokat a sérüléstől vagy a véletlen törléstől. Szolgáltatásként nyújtott platformként (PaaS) az Azure SQL Database szolgáltatás rendelkezésre állását egy nagyvállalati szintű rendelkezésre állási SLA-val rendelkező, polcon kívüli szolgáltatásként biztosítja.

Ha magas rendelkezésre állást szeretne elérni az Azure-felhőkörnyezetben, engedélyezze a zónaredundanciát. A zónaredundanciával az adatbázis vagy a rugalmas készlet azure-beli rendelkezésre állási zónákat használ a zónahibákkal szembeni rugalmasság biztosításához.

  • Számos Azure-régió biztosít rendelkezésre állási zónákat, amelyek különálló adatközpont-csoportok egy régión belül, amelyek független energiaellátással, hűtéssel és hálózati infrastruktúrával rendelkeznek.
  • A rendelkezésre állási zónák úgy vannak kialakítva, hogy regionális szolgáltatásokat, kapacitást és magas rendelkezésre állást biztosítsanak a fennmaradó zónákban, ha egy zóna kimaradást tapasztal.

A zónaredundancia engedélyezésével az adatbázis vagy a rugalmas készlet rugalmasan alkalmazkodik a zóna hardver- és szoftverhibáihoz, és a helyreállítás átlátható az alkalmazások számára. Ha a magas rendelkezésre állás engedélyezve van, az Azure SQL Database szolgáltatás képes magasabb rendelkezésre állású SLA-t biztosítani.

Katasztrófa-helyreállítás

A régiók közötti nagyobb rendelkezésre állás és redundancia érdekében engedélyezheti a vészhelyreállítási képességeket az adatbázis gyors helyreállításához egy katasztrofális regionális hiba miatt. Az Azure SQL Database vészhelyreállítási lehetőségei a következők:

  • aktív georeplikációs lehetővé teszi, hogy egy folyamatosan szinkronizálható, olvasható másodlagos adatbázist hozzon létre az elsődleges adatbázis bármely régiójában.
  • feladatátvételi csoportok, az elsődleges és a másodlagos adatbázis közötti folyamatos szinkronizálás mellett, lehetővé teszik, hogy a logikai kiszolgálón lévő adatbázisok néhányát vagy az összeset replikálhassuk és feladatátvételt hajtsunk végre egy másik régióban lévő másodlagos logikai kiszolgálóra. A feladatátvételi csoportok olvasásra-írásra és csak olvasásra szolgáló hallgatói végpontokat biztosítanak, amelyek változatlanok maradnak, így a feladatátvétel után nem szükséges frissíteni az alkalmazáskapcsolati karakterláncokat.
  • Geo-visszaállítás lehetővé teszi, hogy regionális kimaradások esetén helyreállítson a georeplikált biztonsági másolatokból. Ha nem fér hozzá az adatbázishoz az elsődleges régióban, létrehozhat egy új adatbázist bármely Azure-régió meglévő kiszolgálóján.

Az alábbi táblázat az aktív georeplikációs és feladatátvételi csoportokat hasonlítja össze, az Azure SQL Database két vészhelyreállítási lehetőségét:

Aktív georeplikáció Átváltási csoportok
Folyamatos adatszinkronizálás az elsődleges és másodlagos között Igen Igen
Több adatbázis egyidejű feladatátvétele Nem Igen
A kapcsolati lánc változatlan marad átállás után Nem Igen
Támogatja az olvasás skálázását Igen Igen
Több replika Igen Nem
Ugyanabban a régióban lehet, mint az elsődleges Igen Nem

RTO és RPO

Az üzletmenet-folytonossági terv kidolgozása során ismerje meg a maximális elfogadható időt, mielőtt az alkalmazás teljes mértékben helyreáll a zavaró esemény után. A vészhelyreállítással kapcsolatos üzleti követelmények számszerűsítésének két gyakori módja:

  • Helyreállítási idő célkitűzése (RTO):Az alkalmazás teljes helyreállításához szükséges idő egy nem tervezett zavaró esemény után.
  • Helyreállítási pont célkitűzése (RPO):A nem tervezett zavaró eseményből elviselhető adatvesztés időmennyisége.

Az alábbi táblázat az egyes üzletmenet-folytonossági lehetőségek RPO-ját és RTO-ját hasonlítja össze:

üzletmenet-folytonossági lehetőség RTO (állásidő) RPO (adatvesztés)
Magas rendelkezésre állású
(Zónaredundancia használata)
Általában kevesebb, mint 30 másodperc 0
Vészhelyreállítás
(Feladatátvételi csoportok használata ügyfél által felügyelt feladatátvételi szabályzattal vagy aktív georeplikáció)
Általában kevesebb, mint 60 másodperc Legalább 0
(a nem replikált zavaró esemény előtti adatváltozásoktól függ)
Vészhelyreállítás
(geo-visszaállítás használata)
Általában percek vagy órák, az Azure Storage replikációjától függően Általában percek vagy órák, az adatbázis biztonsági mentésének méretétől függően

Üzletmenet-folytonosságot biztosító funkciók

Adatbázis szempontjából négy fő lehetséges fennakadási forgatókönyv létezik. Az alábbi táblázat az SQL Database üzletmenet-folytonossági funkcióit sorolja fel, amelyekkel enyhítheti az üzletmenet esetleges zavarait:

Üzleti fennakadási forgatókönyv Üzletmenet-folytonossági funkció
Az adatbáziscsomópontot érintő helyi hardver- vagy szoftverhibák. A helyi hardver- és szoftverhibák mérséklése érdekében az Azure SQL Database rendelkezésre állási architektúrát tartalmaz, amely garantálja a hibák automatikus helyreállítását egy nagyvállalati szintű SLA-val.
Az adatok sérülését vagy törlését általában egy alkalmazáshiba vagy emberi hiba okozza. Az ilyen hibák alkalmazásspecifikusak, és az adatbázis-szolgáltatás általában nem képes észlelni. A vállalat adatvesztés elleni védelme érdekében az SQL Database automatikusan heti rendszerességgel készít teljes adatbázis-biztonsági mentéseket, 12 vagy 24 óránként különbségi adatbázis biztonsági mentést, a tranzakciónaplók biztonsági mentését pedig 5–10 percenként. Alapértelmezés szerint a biztonsági másolatok georedundáns tárolóban hét napig vannak tárolva az összes szolgáltatási szint esetében. Az alapszintű kivételével minden szolgáltatási szint támogatja időponthoz kötött visszaállítás (PITR) legfeljebb 35 napos konfigurálható biztonsági mentési megőrzési időtartamát. A törölt adatbázisokat visszaállíthatja arra a pontra, ahol a kiszolgálót nem törölték, vagy ha hosszú távú megőrzési (LTR)konfigurálta.
Ritka adatközpont- vagy rendelkezésreállási zónakimaradás, amelyet természeti katasztrófa, konfigurációváltozás, szoftverhiba vagy hardverhiba okozhat. Az adatközpont vagy a rendelkezésre állási zóna szintű kimaradásának mérséklése érdekében engedélyezze a zónaredundanciát az adatbázis vagy a rugalmas készlet számára, hogy Azure rendelkezésre állási zónákat használva biztosítson redundanciát egy Azure-régió több fizikai zónájában. A zónaredundancia engedélyezése biztosítja, hogy az adatbázis vagy a rugalmas készlet rugalmas legyen az alapértelmezett vállalati SLA-t meghaladó mértékű zónahibákkal szemben.
Ritka regionális kimaradás , amely az összes rendelkezésre állási zónát és az azt alkotó adatközpontokat érinti, valószínűleg katasztrofális természeti katasztrófa esemény okozta. A régiószintű leállások enyhítéséhez engedélyezze a vészhelyreállítást a következő lehetőségek egyikével:
– Folyamatos adatszinkronizálási lehetőségek, például feladatátvételi csoportok (ajánlott) vagy aktív georeplikációs, amelyek lehetővé teszik replikák létrehozását egy másodlagos régióban feladatátvételhez.
– A biztonsági mentési tároló redundanciájának beállítása georedundáns biztonsági mentési tárolóra a geo-visszaállítás használatához.

Felkészülés régiókimaradásra

Függetlenül attól, hogy milyen üzletmenet-folytonossági funkciókat használ, elő kell készítenie a másodlagos adatbázist egy másik régióban. Ha nem készül fel megfelelően, az alkalmazások online állapotba helyezése feladatátvétel vagy helyreállítás után további időt vesz igénybe, és valószínűleg hibaelhárítást is igényel, ami késleltetheti az RTO-t. Kövesse a ellenőrzőlistát a másodlagos rendszer előkészítéséhez egy régió kimaradása esetére.

Adatbázis visszaállítása ugyanabban az Azure-régióban

Az automatikus adatbázis-biztonsági mentések használatával visszaállíthatja az adatbázist egy adott időpontra a múltban. Így helyreállíthatja az emberi hibák által okozott adatsérüléseket. Az időponthoz kötött visszaállítás (PITR) lehetővé teszi, hogy egy új adatbázist hozzon létre ugyanazon a kiszolgálón, amely a sérült esemény előtt az adatok állapotát jelöli. A helyreállítási időkről az RTO és az RPOrészben olvashat.

Ha a maximálisan támogatott biztonsági mentési megőrzési időtartam az időponthoz kötött visszaállításhoz nem elegendő az alkalmazás számára, hosszabb távú adatmegőrzési (LTR) szabályzat konfigurálásával meghosszabbíthatja azt. További információ: Hosszú távú megőrzés.

Alkalmazás frissítése minimális állásidővel

Előfordulhat, hogy egy alkalmazást karbantartás, például alkalmazásfrissítés miatt offline állapotba kell helyezni. A felhőalkalmazások gördülő frissítéseit az SQL Database aktív georeplikációja segítségével kezelheti. A georeplikációs szolgáltatás helyreállítási útvonalat is biztosít, ha valami hiba történik.

Költségmegtakarítás készenléti replikával

Ha a másodlagos replikát csak vészhelyreállításhoz (DR) használják, és nem rendelkezik olvasási vagy írási számítási feladatokkal, az új aktív georeplikációs kapcsolat konfigurálásakor az adatbázis készenléti állapotba történő kiosztásával csökkentheti a licencelési költségeket.

További információért tekintse át licencmentes készenléti replikát.

Következő lépés