Magas rendelkezésre állás az Azure SQL Database-hez

  • Cikk

A következőre vonatkozik: Azure SQL Database

Ez a cikk az Azure SQL Database magas rendelkezésre állású architektúrájának leírását ismerteti.

Áttekintés

Az Azure SQL Database magas rendelkezésre állású architektúrájának célja, hogy minimalizálja a szolgáltatáskarbantartási műveletek és kimaradások által az ügyfelek számítási feladataira gyakorolt hatást. A különböző szolgáltatási szintekhez tartozó speciális SLA-kkal kapcsolatos információkért lásd az Azure SQL Database SLA-ját.

Az SQL Database 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 meghiúsulnak, az állásidő nem lesz hatással, 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éseket folyamatosan hajtják végre.

A magas rendelkezésre állású 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 ne befolyásolják a számítási feladatokat, és hogy az adatbázis ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában.

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

  • Távoli tárolási modell , amely a számítás és a tárolás elkülönítésén alapul. A távoli tárolási szint magas rendelkezésre állására és megbízhatóságára támaszkodik. Ez az architektúra költséghatékony üzleti alkalmazásokhoz ideális, amelyek esetében elfogadható bizonyos mértékű teljesítménycsökkenés a karbantartási műveletek során.
  • Adatbázismotor-folyamatok fürtjén alapuló helyi tárolási modell . Ennek a lényege, hogy mindig rendelkezésre áll az elérhető adatbázismotor-csomópontok egy kvóruma. 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ási modell , amely magas rendelkezésre állású összetevők elosztott rendszerét használja, például számítási csomópontokat, lapkiszolgálókat, naplószolgáltatást és állandó tárterületet. 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ú (virtuális mag) Távoli tárolás Igen Igen
üzletileg kritikus (virtuális mag) Helyi tároló Igen Igen
Rugalmas skálázás (virtuális mag) Rugalmas skálázás Igen Igen
Alapszintű (DTU) Távoli tárolás Igen Nem
Standard (DTU) Távoli tárolás Igen Nem
Prémium (DTU) Helyi tároló Igen Igen

Helyileg redundáns rendelkezésre állás

A helyileg redundáns rendelkezésre állás azon alapul, hogy az adatbázist helyileg redundáns tárolásra (LRS) tárolja, amely háromszor másolja az adatokat az elsődleges régió egyetlen adatközpontjában, és helyi hiba esetén védi az adatokat, például kis méretű hálózat vagy áramkimaradás 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 nagy méretű katasztrófa, például tűz vagy áradás történik egy régión belül, előfordulhat, hogy egy tárfiók LRS-t használó replikái elvesznek vagy helyreállíthatatlanok lesznek. Így a helyileg redundáns rendelkezésre állási lehetőség használatakor az adatok további védelme érdekében érdemes lehet rugalmasabb tárolási lehetőséget használni az 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

Az alapszintű, a standard és az általános célú szolgáltatásszintek a távoli tárterület rendelkezésre állási modelljét használják kiszolgáló nélküli és kiépített számításhoz is. A következő ábrán négy különböző csomópont látható az elkülönített számítási és tárolási rétegekkel.

Diagram showing separation of compute and storage.

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

  • Á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 tempdb csatolt SSD-n lévő adatbázisokat és model 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.

Amikor az adatbázismotort vagy az operációs rendszert frissítik, vagy hiba észlelhető, az Azure Service Fabric áthelyezi az állapot nélküli adatbázismotor-folyamatot egy másik, elegendő 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 üzletileg kritikus szolgáltatási szint

A prémium és üzletileg kritikus szolgáltatási szintek a helyi tárolási rendelkezésre állási modellt használják, 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.

Diagram of a cluster of database engine nodes.

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. A magas rendelkezésre állás az SQL Server Always On rendelkezésre állási csoportjaihoz hasonló technológiával valósul meg. 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, amelybe a feladatátvétel történik. A feladatátvételt az Azure Service Fabric kezdeményezi. Ha egy másodlagos replika lesz az új elsődleges replika, létrejön egy másik másodlagos replika, amely biztosítja, hogy a fürt elegendő számú replikával rendelkezzen a kvórum fenntartásához. 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 felskálázásnak nevezzük. 100%-kal több számítási kapacitást biztosít felár nélkül az elsődleges replikából származó írásvédett terhelés nélküli műveletekhez, például az elemzési számítási feladatokhoz.

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.

Diagram showing Hyperscale functional architecture.

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, például nem lefedett RBPEX-gyorsítótárat és tempdbmodel adatbázisokat stb. a csatolt SSD-n, valamint a memória gyorsítótárát, pufferkészletét és oszlopkészletét. 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 célzó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 tranzakciónaplóhoz, biztosítva az adatok tartósságát a véglegesített tranzakciók esetében.
  • Á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-rendelkezésre állá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 rugalmas skálázás magas rendelkezésre állásáról további információt a Rugalmas skálázású adatbázis magas rendelkezésre állása című témakörben talál.

Zónaredundáns rendelkezésre állás

A zónaredundáns rendelkezésre állás az adatbázis zónaredundáns tárolóba (ZRS) való tárolásán alapul, amely az adatokat az elsődleges régió három Azure rendelkezésre állási zónájában másolja át. Minden rendelkezésreállási zóna egy fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely.

A zónaredundáns rendelkezésre állás a virtuálismag-vásárlási modell általános célú, prémium, üzletileg kritikus és rugalmas skálázású szolgáltatási szintjeiben lévő adatbázisok számára érhető el, a DTU-alapú vásárlási modell alapszintű és standard szolgáltatási szintjei helyett. A zónaredundáns rendelkezésre állás biztosítja a helyreállítási pont célkitűzését (RPO), amely azt jelzi, hogy az adatvesztés mennyisége nulla.

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

Az általános célú szolgáltatási szint zónaredundáns konfigurációja kiszolgáló nélküli és kiépített számítási feladatokhoz is elérhető a virtuálismag-vásárlási modellben lévő adatbázisokhoz. Ez a konfiguráció az Azure Rendelkezésre állási zónák segítségével replikálja az adatbázisokat egy Azure-régió több fizikai helyére. 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 három fizikailag elkülönített Azure rendelkezésre állási zónába.
  • Állapot nélküli számítási réteg, amely a sqlservr.exe folyamatot futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz, például a tempdb csatolt SSD-n lévő adatbázisokat és model 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 a 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 az alábbi ábra szemlélteti:

Diagram of Zone redundant configuration for General Purpose.

Az általános célú adatbázisok zónaredundáns konfigurálásakor vegye figyelembe az alábbiakat:

  • Általános célú szint esetén a zónaredundáns konfiguráció általánosan elérhető a következő régiókban:
    • (Afrika) Észak-Afrika déli régiója
    • (Ázsia és a csendes-óceáni térség) Ausztrália keleti régiója
    • (Ázsiai-csendes-óceáni térség) Kelet-Ázsia
    • (Ázsia és a Csendes-óceáni térség) Kelet-Japán
    • (Ázsiai-csendes-óceáni térség) Korea középső régiója
    • (Ázsiai-csendes-óceáni térség) Délkelet-Ázsia
    • (Ázsia és a Csendes-óceáni térség) Közép-India
    • (Ázsiai-csendes-óceáni térség) Észak-Kína 3
    • (Ázsiai-csendes-óceáni térség) Egyesült Arab Emírségek északi régiója
    • (Európa) Közép-Franciaország
    • (Európa) Németország nyugati középső régiója
    • (Európa) Észak-Olaszország
    • (Európa) Észak-Európa
    • (Európa) Kelet-Norvégia
    • (Európa) Lengyelország középső régiója
    • (Európa) Nyugat-Európa
    • (Európa) Egyesült Királyság déli régiója
    • (Európa) Észak-Svájc
    • (Európa) Svédország középső régiója
    • (Közel-Kelet) Izrael középső régiója
    • (Közel-Kelet) Qatar Central
    • (Észak-Amerika) Közép-Kanada
    • (Észak-Amerika) USA keleti régiója
    • (Észak-Amerika) USA 2. keleti régiója
    • (Észak-Amerika) USA déli középső régiója
    • (Észak-Amerika) USA 2. nyugati régiója
    • (Észak-Amerika) USA 3. nyugati régiója
    • (Dél-Amerika) Dél-Brazília
  • Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kiválasztott régiókban érhető el.
  • A zónaredundáns konfiguráció csak akkor érhető el az SQL Database-ben, ha standard sorozatú (Gen5) hardver van kiválasztva.
  • A zónaredundancia nem érhető el a DTU vásárlási modell alapszintű és standard szolgáltatási szintjeihez.

Prémium és üzletileg kritikus szolgáltatási szintek

Alapértelmezés szerint a helyi tárolási rendelkezésre állási modell csomópontfürtje ugyanabban az adatközpontban jön létre. Az Azure Rendelkezésre állási zónák bevezetésével az SQL Database egy Prémium vagy üzletileg kritikus-adatbázis különböző replikáit helyezheti el ugyanabban a régióban különböző rendelkezésre állási zónákban. 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 az Azure Traffic Manager vezérli. Mivel a prémium vagy üzletileg kritikus szolgáltatási szintek zónaredundáns konfigurációja nem hoz létre további adatbázis-redundanciát, további költségek nélkül engedélyezheti. Zónaredundáns konfiguráció kiválasztásával rugalmassá teheti prémium vagy üzletileg 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 üzletileg kritikus-adatbázist vagy rugalmas készletet zónaredundáns konfigurációvá alakíthat.

A magas rendelkezésre állású architektúra zónaredundáns verzióját az alábbi ábra szemlélteti:

Diagram of the zone-redundant high availability architecture.

A prémium szintű vagy üzletileg kritikus-adatbázisok zónaredundanciával történő konfigurálásakor vegye figyelembe az alábbiakat:

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. Minden olyan Azure-régió, amely rendelkezik rendelkezésre állási zónákkal, támogatja a zónaredundáns rugalmas skálázási adatbázist.

Az alábbi ábra a zónaredundáns rugalmas skálázású adatbázisok mögöttes architektúráit mutatja be:

Diagram showing the underlying architecture of zone redundant Hyperscale databases.

Ügyeljen a következő korlátozásokra:

  • 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. Adatbázis-másolás, időponthoz kötött visszaállítás vagy georeplika létrehozása egy meglévő rugalmas skálázású 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éretű 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 kiválasztott régiókban érhető el.

  • A nevesített replikák jelenleg nem támogatottak.

  • 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 rugalmas skálázásra 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 1 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ónaredundáns rendelkezésre állása

Az Azure SQL Database-ben a kiszolgáló egy logikai szerkezet, amely egy adatbázisgyűjtemény központi felügyeleti pontjaként működik. 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, például a bejelentkezésekkel és a tűzfalszabályokkal kapcsolatos adatok az master adatbázisban vannak tárolva. Hasonlóképpen, egyes DMV-k adatai, például sys.resource_stats is az 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 master kiszolgálóhoz társított 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 az 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 maradnak. Az 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 master kiszolgálóhoz társított adatbázis nem zónaredundáns.

Az Adatbázis tulajdonságának ellenőrzéséhez használhatja az Azure PowerShellt, az Azure CLI-t vagy a REST API-tmaster:ZoneRedundant

Az alábbi példaparancs segítségével ellenőrizze az adatbázis "ZoneRedundant" tulajdonságának master értékét.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Alkalmazáshibák rugalmasságának 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. Felismertük azonban, hogy érdemes lehet tesztelnie, hogy a tervezett vagy nem tervezett események során kezdeményezett automatikus feladatátvételi műveletek milyen hatással lennének az alkalmazásokra, mielőtt üzembe helyezné őket az éles környezetben. 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 a HA/DR ellenőrzőlistát.

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

Üzemelő példány típusa PowerShell REST API Azure CLI
Adatbázis Invoke-AzSqlDatabaseFailover Adatbázis feladatátvétele az rest használható REST API-hívás meghívására az Azure CLI-ből
Rugalmas készlet Invoke-AzSqlElasticPoolFailover Rugalmas készlet feladatátvétele az rest használható REST API-hívás meghívására az Azure CLI-ből

Fontos

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

Összegzés

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 adatvédelemhez használt Azure Blob Storage-on és a rendelkezésre állási zónákon 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ések

  • Az Azure rendelkezésre állási zónáinak ismertetése
  • Tudnivalók a Service Fabricről
  • Az Azure Traffic Manager ismertetése
  • A magas rendelkezésre állás és a vészhelyreállítás további lehetőségeiért lásd: Üzletmenet-folytonosság