Rendelkezésre állás helyi és zónaredundancián keresztül – Felügyelt Azure SQL-példány

A következőkre vonatkozik: Azure SQL Kezelt Példány

• Azure SQL-adatbázis
• felügyelt Azure SQL-példány

Ez a cikk a felügyelt Azure SQL-példány architektúráját ismerteti, amely helyi redundanciával és magas rendelkezésre állással érhető el a zónaredundancián keresztül.

Fontos

A zónaredundáns konfiguráció nyilvános előzetes verzióban érhető el az Általános célú szolgáltatási szinthez, és általánosan elérhető az üzletileg kritikus szolgáltatási szinthez.

Áttekintés

A felügyelt SQL-példány az SQL Server adatbázismotor legújabb stabil verzióján fut a Windows operációs rendszeren az összes vonatkozó javítással. A felügyelt SQL-példány automatikusan kezeli a kritikus karbantartási feladatokat, például javításokat, biztonsági mentéseket, Windows- és SQL-adatbázismotor-frissítéseket, valamint nem tervezett eseményeket, például a mögöttes hardvereket, szoftvereket vagy hálózati hibákat. Ha egy példányt kijavítanak vagy meghiúsulnak, az állásidő nem lesz hatással, ha újrapróbálkozási logikát alkalmazni az alkalmazásban. A felügyelt SQL-példány még 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 a felügyelt Azure SQL-példány helyi redundancia révén rendelkezésre állási érhető el, így a példány elérhetővé válik a következő időszakban:

• Az ügyfél menedzsment műveleteket kezdeményezett, amelyek rövid leállást eredményeznek.
• Szolgáltatáskarbantartási műveletek
• Problémák és adatközpont-kimaradások a következőkkel:
  • Állvány, ahol a szolgáltatást működtető gépek futnak.
  • Az SQL-adatbázismotort futtató virtuális gépet üzemeltető fizikai gép.
  • Az SQL-adatbázismotort futtató virtuális 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 ne befolyásolják a számítási feladatokat, és hogy a példány ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában.

A zónaredundancia engedélyezésével azonban nagy rendelkezésre állást érhet el, így minimalizálhatja az adatokra gyakorolt hatást egy teljes zóna áramszünetének esetén. Zónaredundancia nélkül a feladatátvételek helyileg, ugyanabban az adatközpontban történnek, ami azt eredményezheti, hogy a példány 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 egy feladatátvételi csoportvagy egy georedundáns biztonsági mentés georestore. A további információért tekintse meg az üzletmenet-folytonosság áttekintésidokumentumát.

A magas rendelkezésre állás növeli a szolgáltatás megbízhatóságát azáltal, hogy megvédi Önt a következő hatásoktól:

• Az adatközpontot formázó rendelkezésre állási zóna

A szolgáltatási szint alapján két különböző rendelkezésre állási architektúramodell létezik:

• A távoli tárolási modell a Általános célú és Következő generációs általános célú szolgáltatásszintek elkülönítésén alapul, amelyek a távoli tárolási rendelkezésre állására és megbízhatóságára, valamint az Azure Service Fabric által felügyelt számítási fürtök rendelkezésre állására támaszkodnak. Ez a rendelkezésre állási modell 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.
• A helyi tárolási modell olyan adatbázismotor-folyamatok egy fürtjére épül, amelyek az üzletileg kritikus szolgáltatási szinten, elérhető adatbázismotor-csomópontokból álló kvórumra támaszkodnak, és ezek helyi tárolóval rendelkeznek. Ez a helyi tárolási modell olyan kritikus fontosságú alkalmazásokat céloz meg, amelyek tranzakciós sebessége magas, és magas I/O-teljesítményt igényelnek. A magas rendelkezésre állású architektúra minimális teljesítménycsökkenést garantál a terhelésedre a karbantartási tevékenységek során.

A különböző szolgáltatási szintekhez tartozó konkrét SLA-kkal kapcsolatos további információkért tekintse át az Azure SQL felügyelt példány SLA-ját .

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

A helyileg redundáns rendelkezésre állás azon alapul, hogy a számítási csomópontokat és az adatokat egyetlen adatközpontban tárolja az elsődleges régióban, és védi az adatokat helyi hiba esetén, például kis léptékű hálózat vagy áramkimaradás esetén. Ha nagy méretű katasztrófa, például tűz vagy áradás történik egy régióban, előfordulhat, hogy egy tárfiók vagy a számítási csomópont adatainak ö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.

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

Az Általános célú szolgáltatási szint a távoli tár rendelkezésre állási architektúrát használja. Az alábbi ábra négy különböző csomópontot mutat be a különálló számítási és tárolási rétegekkel.

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 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 végez 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. A helyileg redundáns rendelkezésre állás lényege, hogy az adatokat helyileg redundáns tárolással (LRS) tárolják, amely háromszor másolja az adatokat egyetlen adatközpontban az elsődleges régióban. 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.

Következő generációs általános célú szolgáltatási szint

Jegyzet

Az általános célú következő generációs szolgáltatásszint-frissítési jelenleg előzetes verzióban érhető el.

A Következő generációs általános célú szolgáltatás a meglévő Általános célú szolgáltatási szint architektúrafrissítése, amely egy frissített távoli tárolási réteget használ, amely a példányadatokat és naplófájlokat felügyelt lemezeken tárolja lapblobok helyett, és helyben tartja karban.

Üzletileg kritikus szolgáltatási szint

Az üzletileg kritikus szolgáltatási szint 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.

A mögöttes adatbázisfájlok (.mdf/.ldf) a csatolt SSD-tárolóba kerülnek, így nagyon alacsony késésű IO-t biztosítanak a számítási feladathoz. A magas rendelkezésre állás az SQL Serverhez hasonló technológiával történik, Always On rendelkezésre állási csoportok. A fürt egyetlen elsődleges replikát tartalmaz, amely elérhető az ügyfelek olvasási-írási munkaterheléséhez, valamint legfeljebb három másodlagos replikát, amelyek számítási és tárolási adatmásolatokat tartalmaznak. Az elsődleges replika folyamatosan küld módosításokat a másodlagos replikáknak, hogy az adatok elegendő számú másodlagos replikán legyenek megőrzve 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 elérhetetlenné válik, a teljes mértékben szinkronizált replika mindig elérhető a feladatátvételhez. Az átállást Azure Service Fabrickezdeményezi. Amikor egy másodlagos replika válik az új elsődleges replikává, létrehoznak egy új másodlagos replikát annak érdekében, 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 a kapcsolati sztring alapján 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ásinéven nevezzük. 100% további számítási kapacitást biztosít felár nélkül az elsődleges replikából származó írásvédett műveletek( például elemzési számítási feladatok) betöltéséhez.

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

A zóna-redundáns rendelkezésre állás alapja a replikák elhelyezése három Azure rendelkezésre állási zónában az elsődleges régióban. Minden rendelkezésre állási zóna egy különálló fizikai hely, amely független energiaellátással, hűtéssel és hálózatkezeléssel rendelkezik.

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. A Azure rendelkezésre állási zónákbevezetésével a felügyelt SQL-példány különböző replikákat helyez el különböző rendelkezésre állási zónákban ugyanabban a régióban. Egy hibapont kiküszöbölése érdekében a vezérlőgyűrű több zónában is duplikálva lesz. A vezérlősík forgalmát ezután a rendszer egy terheléselosztóhoz irányítja, amely a rendelkezésre állási zónákban is üzembe van helyezve. A vezérlősíktól a terheléselosztóig tartó forgalomirányítást Azure Traffic Manager (ATM)vezérli.

Zónaredundáns konfigurációval az üzletileg kritikus vagy általános célú példányokat 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. A meglévő üzletileg kritikus vagy általános célú példányokat zónaredundáns konfigurációvá alakíthatja.

Mivel a zónaredundáns példányok különböző adatközpontokban rendelkeznek replikákkal, amelyek között van némi távolság, a megnövekedett hálózati késés növelheti a tranzakció véglegesítési idejét, és így hatással lehet egyes OLTP-számítási feladatok teljesítményére. A zónaredundancia beállítás letiltásával bármikor visszatérhet az egyzónás konfigurációhoz. Ez a folyamat egy olyan online művelet, amely hasonló a normál szolgáltatási szint célkitűzésének frissítéséhez. A folyamat végén a példány egy zónaredundáns gyűrűből egy egyzónás gyűrűbe migrálódik, vagy fordítva.

A felügyelt SQL-példány zónaredundanciájával kapcsolatos első lépésekért tekintse át Zónaredundancia konfigurálása.

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

Az Általános célú szolgáltatási szinten a zónaredundancia úgy érhető el, hogy állapot nélküli számítási csomópontokat helyez el különböző rendelkezésre állási zónákban, majd egy állapotalapú zónaredundáns tárolásra (ZRS) támaszkodik, amely a jelenleg aktív SQL Database Engine-folyamatot tartalmazó csomóponthoz van csatolva. Kimaradás esetén az SQL Database Engine-folyamat aktívvá válik az egyik állapot nélküli csomóponton, amely ezután hozzáfér az állapotalapú tárolóban lévő adatokhoz.

Az alábbi ábra az Általános célú szolgáltatási szint zónaredundancia-architektúráit mutatja be:

Jegyzet

A zónaredundancia jelenleg előzetes verzióban érhető el az Általános célú szolgáltatási szint esetében.

Üzletileg kritikus szolgáltatási szint

Az üzletileg kritikus szolgáltatási szinten a zónaredundancia úgy érhető el, hogy számítási és tárolási replikákat helyez el különböző rendelkezésre állási zónákban, majd az alapul szolgáló Always On rendelkezésre állási csoport technológiával replikálja az adatváltozásokat az elsődleges példányról a készenléti replikákra más rendelkezésre állási zónákban. Kimaradás esetén automatikus átkapcsolás történik, amely zökkenőmentesen az egyik készenléti replikát elsődleges replikává váltja.

Az alábbi ábra az üzletileg kritikus szolgáltatási szint zónaredundancia-architektúrájának bemutatását mutatja be:

Alkalmazás hibatűrésének tesztelése

A rendelkezésre állás az SQL Managed Instance 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 egy speciális API meghívásával, amely újraindít egy felügyelt példányt. Mivel az újraindítási művelet tolakodó, és nagy számban stresszelhetik a platformot, minden felügyelt példány esetében 15 percenként csak egy feladatátvételi hívás engedélyezett.

A valódi feladatátvétel során a példányhoz való kapcsolatok meghiúsulnak, miközben az SQL-szolgáltatás elsődlegessé válik egy másik csomóponton. Feladatátvétel szimulálásához hívja meg azt a parancsot, amely újraindítja az SQL-folyamatot a szolgáltatás elindításának szimulálásához, mintha feladatátvétel történt volna. A kapcsolatok azonban hosszabb ideig is meghiúsulhatnak egy valódi feladatátvétel során a szimulált feladatátvételhez képest, mivel egy valódi feladatátvétel során az SQL-folyamat az elsődleges folyamattá válik a fürt egy másik virtuális gépén (akár helyileg, akár egy másik zónában, ha a zónaredundancia engedélyezett), míg egy szimulált feladatátvétel során az SQL-folyamat újraindul a meglévő virtuális gépen.

Az ebben a szakaszban található manuális feladatátvételi parancs általában ugyanúgy viselkedik helyileg redundáns és zónaredundáns konfigurációkban is – csak helyileg indítja újra az SQL-folyamatot, és nem kezdeményez feladatátvételt egy másik csomópontra, bár néhány kivétel. Ez a helyi feladatátvétel eltér a feladatátvételi csoportban bekövetkező feladatátvételtől.

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

PowerShell	REST API	Azure CLI
Invoke-AzSqlInstanceFailover	felügyelt SQL-példány – Feladatátvételi	az sql mi feladatátvétel REST API-hívás meghívására használható az Azure CLI-ből

Következtetés

Az Azure SQL Managed Instance 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 adatok védelméhez, valamint a rendelkezésre állási zónáktól a nagyobb hibatűrés érdekében. Az üzletileg kritikus szolgáltatási szint esetében a felügyelt SQL-példány az SQL Server Always On rendelkezésre állási csoport technológiáját használja az adatbázis-replikációhoz és a 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

• Zónaredundancia engedélyezése felügyelt Azure SQL-példányhoz.
• Ismerje meg az Azure rendelkezésre állási zónákat
• Ismerje meg a Service Fabric
• Ismerje meg az Azure Traffic Manager
• Ismerje meg, hogyan kezdeményezhet manuális feladatátvételt felügyelt SQL-példány esetén
• A magas rendelkezésre állással és katasztrófa utáni helyreállítással kapcsolatos további lehetőségekért lásd üzletmenet-folytonossági megoldásokat