Megosztás:

Rendelkezésre állás redundancián keresztül – Azure SQL Database

A következőkre vonatkozik:Azure SQL DatabaseSQL Database a Fabric-ben

Ez a cikk az Azure SQL Database és a Fabricben található SQL Database architektúráját ismerteti, amely helyi redundanciával és magas rendelkezésre állással érhető el a zónaredundancián keresztül.

Overview

Az Azure SQL Database és az SQL Database in Fabric egyaránt az SQL Server adatbázismotor legújabb stabil verzióján fut a Windows operációs rendszeren az összes vonatkozó javítással. Az SQL Database automatikusan kezeli a kritikus karbantartási feladatokat, például javításokat, biztonsági mentéseket, Windows- és SQL-motorfrissítéseket, valamint nem tervezett eseményeket, például a mögöttes hardvereket, szoftvereket vagy hálózati hibákat. Ha az SQL Database-ben egy adatbázist vagy rugalmas készletet kijavítanak vagy átváltanak, az állásidő nem lesz hatással a működésre, ha újrapróbálkozási logikát alkalmaz az alkalmazásban. Az SQL Database a legkritikusabb körülmények között is gyorsan helyreállhat, biztosítva, hogy az adatok mindig elérhetők legyenek. A felhasználók többsége nem veszi észre, hogy a frissítések végrehajtása folyamatosan történik.

Alapértelmezés szerint az Azure SQL Database helyi redundanciával éri el a rendelkezésre állást , biztosítva, hogy az adatbázis kezelje az olyan fennakadásokat, mint például:

  • Az ügyfél által kezdeményezett menedzsment műveletek rövid állásidőt eredményeznek
  • Szolgáltatáskarbantartási műveletek
  • A következőkkel kapcsolatos problémák:
    • állvány, ahol a szolgáltatást működtető gépek futnak
    • az SQL-adatbázismotort üzemeltető fizikai gép
  • Az SQL-adatbázismotor egyéb problémái
  • Egyéb lehetséges nem tervezett helyi kimaradások

Az alapértelmezett rendelkezésre állási megoldás úgy lett kialakítva, hogy a véglegesített adatok soha ne vesszenek el hibák miatt, hogy a karbantartási műveletek minimális hatással legyenek a számítási feladatra, és hogy az adatbázis ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában.

Azonban a zónaredundancia engedélyezésével magas rendelkezésre állást érhet el, ezzel minimalizálva az adatokra gyakorolt hatást egy teljes zóna kimaradása esetén. Zónaredundancia nélkül a feladatátvételek helyileg, ugyanabban az adatközpontban történnek, ami azt eredményezheti, hogy az adatbázis a kimaradás feloldásáig nem érhető el – a helyreállítás egyetlen módja egy vészhelyreállítási megoldás, például az aktív georeplikáció geo-feladatátvételenkeresztül, a feladatátvételi csoportokhasználata, vagy a georedundáns biztonsági mentés geo-visszaállítása. Ha többet szeretne megtudni, tekintse át az üzletmenet folytonosság áttekintését.

Három rendelkezésre állási architektúramodell létezik:

  • távoli tárolási modell, amely a számítás és a tárolás szétválasztásán alapul. A távoli tárolási modell a távoli tárolási szint rendelkezésre állására és megbízhatóságára támaszkodik. Ez az architektúra olyan költségvetés-orientált üzleti alkalmazásokat céloz meg, amelyek a karbantartási tevékenységek során képesek némi teljesítménycsökkenést elviselni.
  • helyi tárolási modell, amely adatbázismotor-folyamatok fürtöjén alapul. A helyi tárolási modell arra a tényre támaszkodik, hogy az adatbázismotor-csomópontok mindig kvórumban vannak. Ez az architektúra olyan kritikus fontosságú alkalmazásokat céloz meg, amelyek magas I/O-teljesítménnyel, magas tranzakciós sebességgel és minimális teljesítménybeli hatással vannak a számítási feladatokra a karbantartási tevékenységek során.
  • rugalmas skálázású modell, amely magas rendelkezésre állású összetevők, például számítási csomópontok, lapkiszolgálók, naplószolgáltatás és állandó tárterület elosztott rendszerét használja. A rugalmas skálázású adatbázist támogató minden összetevő saját redundanciát és rugalmasságot biztosít a hibákhoz. A számítási csomópontok, lapkiszolgálók és naplószolgáltatás az Azure Service Fabricen futnak, amely szabályozza az egyes összetevők állapotát, és szükség esetén feladatátvételt végez az elérhető kifogástalan állapotú csomópontokra. Az állandó tár a natív magas rendelkezésre állási és redundancia-képességekkel rendelkező Azure Storage-t használja. További információ: rugalmas skálázású architektúra.

A három rendelkezésre állási modell mindegyikében az SQL Database támogatja a helyi redundancia és a zónaredundancia beállításait. A helyi redundancia rugalmasságot biztosít az adatközponton belül, míg a helyi redundancia tovább javítja a rugalmasságot azáltal, hogy védelmet nyújt egy régión belüli rendelkezésre állási zóna kimaradása ellen.

Az alábbi táblázat a szolgáltatási szinteken alapuló rendelkezésre állási lehetőségeket mutatja be:

Szolgáltatási szint Magas rendelkezésre állási modell Helyileg redundáns rendelkezésre állás Zónaredundáns rendelkezésre állás
Általános célú (vCore) Távoli tárolás Yes Yes
Üzletkritikus (vMag) Helyi tároló Yes Yes
Rugalmas skálázás (virtuális mag) rugalmas skálázás Yes Yes
Alapszintű (DTU) Távoli tárolás Yes No
Standard (DTU) Távoli tárolás Yes No
Prémium (DTU) Helyi tároló Yes Yes

A különböző szolgáltatási szintekhez tartozó speciális SLA-kkal kapcsolatos további információkért tekintse át az Azure SQL Database SLA-ját.

Rendelkezésre állás helyi redundancián keresztül

A helyi redundanciával biztosított rendelkezésre állást az adja, hogy az adatbázisa helyileg redundáns tárolásba (LRS) kerül, amely háromszor másolja az adatokat az elsődleges régió egyik adatközpontján belül. Ez védi az adatokat helyi meghibásodás esetén, például kisebb hálózati vagy áramellátási hiba esetén. Az LRS a legalacsonyabb költségű redundancia lehetőség, és a többi lehetőséghez képest a legkevésbé tartósságot biztosítja. Ha egy régióban nagy méretű katasztrófa, például tűz vagy áradás történik, előfordulhat, hogy egy LRS-t használó tárfiók összes replikája elveszik vagy helyreállíthatatlan lesz. A helyileg redundáns rendelkezésre állási lehetőség használata esetén az adatok további védelme érdekében érdemes lehet rugalmasabb tárolási lehetőséget használni a adatbázis biztonsági mentéseihez. Ez nem vonatkozik a rugalmas skálázású adatbázisokra, ahol ugyanazt a tárterületet használják adatfájlokhoz és biztonsági másolatokhoz is.

A helyileg redundáns rendelkezésre állás az összes szolgáltatási szinten lévő összes adatbázis számára elérhető, és a helyreállítási pont célkitűzése (RPO), amely azt jelzi, hogy az adatvesztés mennyisége nulla.

Alapszintű, standard és általános célú szolgáltatási szintek

A DTU-alapú vásárlási modell áttekintésének alapszintű és standard szolgáltatási szintjei, valamint a virtuális magalapú vásárlási modell általános célú szolgáltatási szintje a távoli tároló rendelkezésre állási modelljét használja a kiszolgáló nélküli és a kiépített számításhoz is. Az alábbi ábra a különálló számítási és tárolási rétegekkel rendelkező csomópontokat mutatja be.

a számítás és a tárolás elkülönítését ábrázoló diagram.

A távoli tár rendelkezésre állási modellje két réteget tartalmaz:

  • Egy állapot nélküli számítási réteg, amely az adatbázismotor folyamatát futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz, például a csatolt SSD-n lévő tempdb és model adatbázisokat, valamint a gyorsítótárat, a pufferkészletet és az oszloptárkészletet a memóriában. Ezt az állapot nélküli csomópontot az Azure Service Fabric üzemelteti, amely inicializálja az adatbázismotort, szabályozza a csomópont állapotát, és szükség esetén feladatátvételt hajt végre egy másik csomópontra.

  • Állapotalapú adatréteg az Azure Blob Storage-ban tárolt adatbázisfájlokkal (.mdf és .ldf). Az Azure Blob Storage beépített adat rendelkezésre állási és redundanciafunkciókkal rendelkezik. Garantálja, hogy az adatfájl naplófájljának vagy lapjának minden rekordja megmarad, még akkor is, ha az adatbázismotor folyamata összeomlik.

Az adatbázismotor vagy az operációs rendszer frissítésekor vagy hiba észlelésekor az Azure Service Fabric áthelyezi az állapot nélküli adatbázismotor-folyamatot egy másik, megfelelő szabad kapacitással rendelkező állapot nélküli számítási csomópontra. Az Azure Blob Storage-ban lévő adatokat nem befolyásolja az áthelyezés, és az adatok/naplófájlok az újonnan inicializált adatbázismotor folyamatához vannak csatolva. Ez a folyamat garantálja a magas rendelkezésre állást, de a nagy számítási feladatok teljesítménycsökkenést tapasztalhatnak az átmenet során, mivel az új adatbázismotor-folyamat hideg gyorsítótárral kezdődik.

Prémium és üzleti szempontból kritikus szolgáltatási szint

A DTU-alapú vásárlási modell prémium szolgáltatási szintje és a virtuális magalapú vásárlási modell üzletileg kritikus szolgáltatási szintje a helyi tárolási rendelkezésre állási modellt használja, amely egyetlen csomóponton integrálja a számítási erőforrásokat (adatbázismotor-folyamatot) és a tárolást (helyileg csatlakoztatott SSD). A magas rendelkezésre állás úgy érhető el, hogy a számítást és a tárolást további csomópontokra replikálja.

Egy adatbázismotor csomópontokból álló fürt diagramja.

A mögöttes adatbázisfájlokat (.mdf/.ldf) a csatolt SSD-tárolóba helyezi a rendszer, hogy nagyon alacsony késésű IO-t biztosítson a számítási feladat számára. Az SQL Server Always On rendelkezésre állási csoportoktechnológiájához hasonló megoldással valósítják meg a magas rendelkezésre állást. A fürt egyetlen elsődleges replikát tartalmaz, amely olvasási-írási ügyfélfeladatokhoz érhető el, és legfeljebb három másodlagos replikát (számítást és tárolást) tartalmaz, amelyek adatmásolatokat tartalmaznak. Az elsődleges replika folyamatosan leküldi a módosításokat a másodlagos replikákra, és biztosítja, hogy az adatok elegendő számú másodlagos replikán megmaradjanak az egyes tranzakciók véglegesítése előtt. Ez a folyamat garantálja, hogy ha az elsődleges replika vagy egy olvasható másodlagos replika bármilyen okból összeomlik, mindig van egy teljesen szinkronizált replika, amelyhez át tud állni. A feladatátvételt az Azure Service Fabric kezdeményezi. Amikor egy másodlagos replika válik új primer replikává, létrehoznak egy másik másodlagos replikát annak biztosítására, hogy a fürt elégséges számú replikával rendelkezzen a kvórum fenntartása érdekében. A feladatátvétel befejezése után a rendszer automatikusan átirányítja az Azure SQL-kapcsolatokat az új elsődleges replikára vagy olvasható másodlagos replikára.

További előny, hogy a helyi tárolási rendelkezésre állási modell lehetővé teszi az írásvédett Azure SQL-kapcsolatok átirányítását az egyik másodlagos replikára. Ezt a funkciót Olvasási skálázásnaknevezzük.% százalékkal több számítási kapacitást biztosít felár nélkül, hogy a csak olvasható műveletek, például az elemzői munkaterhelések, átirányításra kerüljenek az elsődleges replikáról.

Rugalmas skálázású szolgáltatási szint

A rugalmas skálázású szolgáltatásréteg architektúráját az Elosztott függvények architektúrája ismerteti, amely részletes diagramot is bemutat.

A rugalmas skálázású rendelkezésre állási modell négy réteget tartalmaz:

  • Állapot nélküli számítási réteg, amely az adatbázismotor folyamatait futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz, mint például a nem teljes RBPEX gyorsítótár, a tempdb és model adatbázisok stb. a csatolt SSD-n, valamint a tervgyorsítótár, a pufferkészlet és az oszloptárkészlet a memóriában. Ez az állapot nélküli réteg tartalmazza az elsődleges számítási replikát, és opcionálisan több másodlagos számítási replikát is, amelyek feladatátvételi célként szolgálhatnak.

  • Lapkiszolgálók által létrehozott állapot nélküli tárolási réteg. Ez a réteg a számítási replikákon futó adatbázismotor-folyamatok elosztott tárolómotorja. Minden lapkiszolgáló csak átmeneti és gyorsítótárazott adatokat tartalmaz, például az RBPEX gyorsítótár lefedése a csatolt SSD-n, és a memóriában gyorsítótárazott adatoldalak. Minden lapkiszolgáló rendelkezik egy párosított lapkiszolgálóval egy aktív-aktív konfigurációban, amely terheléselosztást, redundanciát és magas rendelkezésre állást biztosít.

  • Állapotalapú tranzakciónapló-tárolási réteg, amelyet a naplószolgáltatás-folyamatot, a tranzakciónapló kezdőzónát és a tranzakciónapló hosszú távú tárolását futtató számítási csomópont hoz létre. A leszállási zóna és a hosszú távú tárolás az Azure Storage-t használja, amely rendelkezésre állást és redundanciát biztosít a naplófájlhoz, biztosítva az adatok tartósságát a véglegesített tranzakciók esetén.

  • Állapotalapú adattárolási réteg az Azure Storage-ban tárolt és lapkiszolgálók által frissített adatbázisfájlokkal (.mdf/.ndf). Ez a réteg az Azure Storage adat-hozzáférési és redundancia funkcióit használja. Garantálja, hogy az adatfájlok minden oldala megmarad, még akkor is, ha a rugalmas skálázású architektúra más rétegeiben lévő folyamatok összeomlanak, vagy ha a számítási csomópontok meghibásodnak.

Az összes rugalmas skálázási réteg számítási csomópontjai az Azure Service Fabricen futnak, amely szabályozza az egyes csomópontok állapotát, és szükség esetén feladatátvételt végez az elérhető kifogástalan állapotú csomópontokra.

A Hyperscale magas rendelkezésre állásáról további információért lásd a Hyperscale adatbázis magas rendelkezésre állásacímű részt.

Magas rendelkezésre állás zónaredundancián keresztül

Zónaredundáns üzemelő példányok esetén az Azure SQL Database egy adott régióban az Azure rendelkezésre állási zónáinak számát használja, két vagy több gyakran három. A számítási és tárolási összetevők az Azure SQL által az optimális rugalmasság érdekében kiválasztott két vagy három zónára terjednek ki, különálló fizikai helyeken, független tápellátással, hűtéssel és hálózatkezeléssel. Az Azure SQL automatikusan kiválasztja a zónák számát a regionális rendelkezésre állás és a szolgáltatásoptimalizálás alapján. Az üzembe helyezés nem fog kevesebb zónát használni, mint amennyi szükséges a rugalmasság érdekében.

A zónaredundáns rendelkezésre állás az vCore-alapú vásárlási modell Üzletileg Kritikus, Általános Célú és Hiperskálázást szolgáltatási szintjeibenérhető el adatbázisok számára, és csak a DTU-alapú vásárlási modell Prémium szolgáltatási szintjében érhető el — az alapszintű és a standard szolgáltatási szintek nem támogatják a zónaredundanciát.

Bár minden szolgáltatási szint eltérően valósítja meg a zónaredundanciát, minden implementáció biztosítja a helyreállítási pont célkitűzését (RPO), amely a feladatátvételkor nem veszíti el a véglegesített adatokat, ha egy Azure-régió egyetlen rendelkezésre állási zónája elérhetetlenné válik.

Az Azure SQL automatikusan optimalizálja a zónaelhelyezést az üzembe helyezéshez. A két vagy három zónát használó összes rendelkezésreállási zóna konfigurációja ugyanazokat a magas rendelkezésre állási SLA-t és rugalmassági garanciákat biztosítja.

Általános célú szolgáltatási szint

Az általános rendeltetésű szolgáltatási szint zónaredundáns konfigurációja a szerver nélküli és kiépített számítási lehetőségekhez is elérhető, a vCore alapú vásárlási modell szerint az adatbázisok számára. Ez a konfiguráció Azure rendelkezésre állási zónákat használ az adatbázisok azure-régión belüli több fizikai helyre történő replikálásához. A zónaredundancia kiválasztásával az új és meglévő kiszolgáló nélküli és kiépített általános célú önálló adatbázisokat és rugalmas készleteket rugalmassá teheti sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül.

Az Általános célú szint zónaredundáns konfigurációja két rétegből áll:

  • Állapotalapú adatréteg a ZRS-ben (zónaredundáns tárolás) tárolt adatbázisfájlokkal (.mdf/.ldf). A ZRS használatával az adatok és a naplófájlok szinkron módon lesznek átmásolva az elsődleges régió több Azure rendelkezésre állási zónájába. Ez az Azure SQL által az optimális rugalmasság érdekében kiválasztott két vagy három zónára terjed ki.
  • A sqlservr.exe folyamatot futtató állapot nélküli számítási réteg, amely csak átmeneti és gyorsítótárazott adatokat tartalmaz, például a csatolt SSD tempdb és model adatbázisait, valamint a memória gyorsítótárát, pufferkészletét és oszlopkészletét. Ezt az állapot nélküli csomópontot az Azure Service Fabric üzemelteti, amely inicializálja sqlservr.exe, szabályozza a csomópont állapotát, és szükség esetén feladatátvételt hajt végre egy másik csomópontra. Zónaredundáns kiszolgáló nélküli és kiépített általános célú adatbázisok esetén a tartalék kapacitással rendelkező csomópontok könnyen elérhetők más rendelkezésre állási zónákban a feladatátvételhez.

Az Általános célú szolgáltatási szint magas rendelkezésre állású architektúrájának zónaredundáns verzióját a következő diagramok szemléltetik két- vagy háromzónás régióban:

Kétzónás régió Háromzónás régió
Az általános célú zónaredundáns konfiguráció diagramja kétzónás régióban. Az általános célú zónaredundáns konfiguráció diagramja egy háromzónás régióban.

  • Ha a számítás két rendelkezésre állási zónában van kiépítve:

    • A biztonsági mentés és a tárolás továbbra is szinkronizálva van a régió három rendelkezésre állási zónájában.
    • A zónaredundáns tárolás, mint mindig, három rendelkezésre állási zónában van szinkronizálva.

  • Ha a számítás három rendelkezésre állási zónában van kiépítve:

    • A biztonsági mentés és a tárolás a régió három rendelkezésre állási zónájában szinkronizálva van.

  • A rendelkezésre állási zónával rendelkező összes Azure-régió támogatja a zónaredundáns általános adatbázisokat.

  • Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kijelölt régiókban érhető el. További információ: Karbantartási időszak rendelkezésre állása régiónként az Azure SQL Database.

  • A zónaredundancia nem érhető el a DTU vásárlási modell alapszintű és standard szolgáltatási szintjeihez.

Prémium és üzleti szempontból kritikus szolgáltatási szintek

Ha a zónaredundancia engedélyezve van a prémium vagy az üzleti szempontból kritikus szolgáltatási szinten, a replikák ugyanabban a régióban különböző rendelkezésre állási zónákba kerülnek. Egy meghibásodási pont kiküszöbölése érdekében a vezérlőgyűrű három átjárógyűrűként (GW) is duplikálva van több zónában. Az adott átjárógyűrűhöz való útválasztást Azure Traffic Managerszabályozza. Mivel a prémium vagy üzleti szempontból kritikus szolgáltatási szintek zónaredundáns konfigurációja a meglévő replikáit használja a különböző rendelkezésre állási zónákba való helyezéshez, további költségek nélkül engedélyezheti azt. Zónaredundáns konfiguráció kiválasztásával rugalmassá teheti prémium vagy üzleti szempontból kritikus adatbázisait és rugalmas készleteit a sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül. Bármely meglévő prémium vagy üzleti szempontból kritikus adatbázist vagy rugalmas készletet zónaredundáns konfigurációvá alakíthat.

Az üzletileg kritikus szolgáltatási szint magas rendelkezésre állású architektúrájának zónaredundáns verzióját a következő diagramok szemléltetik két- vagy háromzónás régióban:

Kétzónás régió Háromzónás régió
Az üzletileg kritikus szolgáltatási szint zónaredundáns konfigurációjának diagramja egy kétzónás régióban. Az üzletileg kritikus szolgáltatási szint zónaredundáns konfigurációjának diagramja egy háromzónás régióban.

  • Ha a számítás két rendelkezésre állási zónában van kiépítve:

    • Az üzletileg kritikus fontosságú tárolás esetében az adatok és naplófájlok helyileg redundáns rendelkezésre állási tárolója két rendelkezésre állási zónában szinkronizálódik.
    • Más szintek esetében a biztonsági mentés és a tárolás a régió három rendelkezésre állási zónájában szinkronizálva van.
    • A zónaredundáns tárolás, mint mindig, három rendelkezésre állási zónában van szinkronizálva.

  • Ha a számítás három rendelkezésre állási zónában van kiépítve:

    • Az üzletileg kritikus fontosságú tárolás esetében az adatok és naplófájlok helyileg redundáns rendelkezésre állási tárolója három rendelkezésre állási zónában szinkronizálódik.
    • Más szintek esetében a biztonsági mentés és a tárolás a régió három rendelkezésre állási zónájában szinkronizálva van.

Vegye figyelembe a következőket, amikor zónaredundanciával konfigurálja prémium vagy üzleti szempontból kritikus fontosságú adatbázisait:

Rugalmas skálázású szolgáltatási szint

A rugalmas skálázási szolgáltatási szinten lévő adatbázisok zónaredundanciája konfigurálható. További információ: Zónaredundáns rugalmas skálázású adatbázis létrehozása.

A konfiguráció engedélyezése zónaszintű rugalmasságot biztosít a rendelkezésre állási zónák közötti replikáció révén az összes rugalmas skálázási réteg esetében. A zónaredundancia kiválasztásával rugalmassá teheti a rugalmas skálázású adatbázisokat sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül.

A zónaredundáns rendelkezésre állás támogatott a Hyperscale önálló adatbázisokban és a Hyperscale rugalmas készletekben. További információ: Rugalmas rugalmas készletek rugalmas készleteinek áttekintése az Azure SQL Database-ben.

Az alábbi diagramok a zónaredundáns rugalmas skálázású adatbázisok mögöttes architektúráit mutatják be két- vagy háromzónás régióban:

Kétzónás régió Háromzónás régió
Kétzónás redundáns rugalmas skálázású adatbázisok mögöttes architektúráját bemutató ábra. Háromzónás redundáns rugalmas skálázású adatbázisok mögöttes architektúráját bemutató ábra.

  • Ha a számítás két rendelkezésre állási zónában van kiépítve:

    • A biztonsági mentés és a tárolás a régió három rendelkezésre állási zónájában szinkronizálva van.
    • A zónaredundáns tárolás, mint mindig, három rendelkezésre állási zónában van szinkronizálva.

  • Ha a számítás három rendelkezésre állási zónában van kiépítve:

    • A biztonsági mentés és a tárolás a régió három rendelkezésre állási zónájában szinkronizálva van.

Vegye figyelembe a következő korlátozásokat:

  • A rendelkezésre állási zónával rendelkező összes Azure-régió támogatja a zónaredundáns rugalmas skálázási adatbázist.

  • Zónaredundáns konfiguráció csak az adatbázis létrehozásakor adható meg. Ez a beállítás nem módosítható az erőforrás kiépítése után. Az Adatbázis-másolás, időponthoz kötött visszaállítás, vagy hozzon létre egy georeplikát a meglévő Hyperscale adatbázis zónaredundáns konfigurációjának frissítéséhez. Ezen frissítési beállítások egyikének használatakor, ha a céladatbázis más régióban van, mint a forrás, vagy ha az adatbázis biztonsági mentési tárolójának redundanciái eltérnek a forrásadatbázistól, a másolási művelet adatművelet mérete lesz.

  • Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kijelölt régiókban érhető el. További információ: Karbantartási időszak rendelkezésre állása régiónként az Azure SQL Database.

  • Jelenleg nincs lehetőség zónaredundancia megadására, ha egy adatbázist rugalmas skálázásba migrál az Azure Portal használatával. A zónaredundancia azonban megadható az Azure PowerShell, az Azure CLI vagy a REST API használatával, amikor egy meglévő adatbázist egy másik Azure SQL Database szolgáltatási szintről Hyperscale-re migrál. Íme egy példa az Azure CLI-vel:

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`

  • A rugalmas skálázás zónaredundáns konfigurációjának engedélyezéséhez legalább egy magas rendelkezésre állású számítási replika és zónaredundáns vagy georedundáns biztonsági mentési tár használata szükséges.

Az adatbázis zónák redundanciájával biztosított rendelkezésre állás

Az Azure SQL Database-ben a kiszolgálói egy logikai szerkezet, amely központi felügyeleti pontként szolgál az adatbázisok gyűjteményéhez. A kiszolgáló szintjén kezelheti a bejelentkezéseket, a hitelesítési módszert, a tűzfalszabályokat, a naplózási szabályokat, a fenyegetésészlelési szabályzatokat és a feladatátvételi csoportokat. Ezen funkciók némelyikével kapcsolatos adatokat, például a bejelentkezéseket és a tűzfalszabályokat a master adatbázis tárolja. Hasonlóképpen, egyes DMV-k adatai, például sys.resource_stats, szintén a master adatbázisban vannak tárolva.

Ha egy logikai kiszolgálón zónaredundáns konfigurációval rendelkező adatbázis jön létre, a kiszolgálóhoz társított master adatbázis is automatikusan zónaredundánssá válik. Ez biztosítja, hogy egy zónakimaradás esetén az adatbázist használó alkalmazások ne legyenek hatással, mivel a master adatbázistól függő funkciók, például a bejelentkezések és a tűzfalszabályok továbbra is elérhetők. A master adatbázis zónaredundánssá tétele aszinkron folyamat, és némi időt vesz igénybe a háttérben.

Ha a kiszolgálón lévő adatbázisok egyike sem zónaredundáns, vagy ha üres kiszolgálót hoz létre, akkor a kiszolgálóhoz társított master adatbázis nem zónaredundáns . Ha az Azure SQL Database-t zónaredundancia használatára szeretné migrálni, kövesse az Azure SQL Database migrálásával kapcsolatos lépéseket a rendelkezésre állási zónák támogatásához.

Az ZoneRedundant adatbázis tulajdonságának ellenőrzéséhez használja az master Azure PowerShellt, az Azure CLI-t vagy a REST API lépéseit az Azure SQL Database rendelkezésre állási zónájának állapotának ellenőrzéséhez.

Az alkalmazások hibatűrésének tesztelése

A magas rendelkezésre állás az SQL Database platform alapvető része, amely transzparens módon működik az adatbázis-alkalmazás számára. Felismerjük azonban, hogy érdemes lehet tesztelni, hogy a tervezett vagy nem tervezett események során indított automatikus feladatátvételi műveletek hogyan befolyásolnák az alkalmazást, mielőtt éles környezetben üzembe helyezné. A feladatátvételt manuálisan is aktiválhatja, ha egy speciális API-t hív meg egy adatbázis vagy egy rugalmas készlet újraindításához. Zónaredundáns kiszolgáló nélküli vagy kiépített általános célú adatbázis vagy rugalmas készlet esetén az API-hívás az ügyfélkapcsolatokat a régi elsődleges rendelkezésre állási zónától eltérő rendelkezésre állási zónában lévő új elsődlegesre irányítaná át. Így a feladatátvétel a meglévő adatbázis-munkamenetekre gyakorolt hatásának tesztelése mellett azt is ellenőrizheti, hogy a teljes körű teljesítményt módosítja-e a hálózati késés változása miatt. Mivel az újraindítási művelet tolakodó, és nagy számban stresszelhetik a platformot, minden adatbázis vagy rugalmas készlet esetében 15 percenként csak egy feladatátvételi hívás engedélyezett.

Az Azure SQL Database magas rendelkezésre állásával és vészhelyreállításával kapcsolatos további információkért tekintse át az Azure SQL Database magas rendelkezésre állási és vészhelyreállítási ellenőrzőlistát.

A feladatátvétel a PowerShell, a REST API vagy az Azure CLI használatával kezdeményezhető:

Üzembe helyezés típusa PowerShell REST API Azure CLI Portál (előzetes verzió)
Database Invoke-AzSqlDatabaseFailover Adatbázis átkapcsolás az rest használható REST API-hívás meghívására az Azure CLI-ből Beállítások > Karbantartás > Újraindítás
Rugalmas erőforrás-készlet Invoke-AzSqlElasticPoolFailover Rugalmas készlet átkapcsolás az rest használható REST API-hívás meghívására az Azure CLI-ből Beállítások > Karbantartás > Újraindítás

Important

A feladatátvételi parancs nem érhető el a rugalmas skálázású adatbázisok olvasható másodlagos replikáihoz.

Conclusion

Az Azure SQL Database beépített magas rendelkezésre állású megoldást tartalmaz, amely mélyen integrálva van az Azure-platformmal. A szolgáltatás a Service Fabrictől függ a hibák észleléséhez és helyreállításához, az Azure Blob Storage-hoz az adatvédelemhez, valamint a rendelkezésre állási zónáktól a nagyobb hibatűrés érdekében. Az SQL Database emellett az SQL Server Always On rendelkezésre állási csoport technológiáját használja adatszinkronizáláshoz és feladatátvételhez. Ezeknek a technológiáknak a kombinációja lehetővé teszi az alkalmazások számára, hogy teljes mértékben kihasználják a vegyes tárolási modell előnyeit, és támogatják a legigényesebb SLA-kat.

Következő lépés

Az Azure SQL Database migrálása a rendelkezésre állási zónák támogatásába

Kapcsolódó tartalom

  • Last updated on