Magas rendelkezésre állás felügyelt Azure SQL-példányhoz

  • Cikk

A következőre vonatkozik: Felügyelt Azure SQL-példány

Ez a cikk a felügyelt Azure SQL-példány magas rendelkezésre állását ismerteti.

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ő a üzletileg kritikus szolgáltatásszinthez.

Áttekintés

A felügyelt Azure SQL-példány magas rendelkezésre állási architektúrájának célja, hogy minimálisra csökkentse az ügyfél által kezdeményezett felügyeleti műveletek által az ügyfél számítási feladataira gyakorolt hatásokat, amelyek rövid állásidőt, szolgáltatáskarbantartási műveleteket és nem tervezett leállást eredményeznek. A különböző szolgáltatási szintekhez tartozó speciális SLA-kkal kapcsolatos további információkért tekintse át a felügyelt Azure SQL-példányt. A magas rendelkezésre állás az a fogalom, amely védelmet nyújt a

  • az adatközpontot alkotó rendelkezésre állási zóna (többzónás régió esetén),
  • az állványon, ahol a szolgáltatást működtető csomópontok futnak,
  • maga a csomópont,
  • alkalmazásréteg.

A regionális vagy nagyobb leállások hatásának minimalizálása érdekében használhatja az üzletmenet-folytonosság áttekintésével kapcsolatos elérhető technikák egyikét.

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-motorfrissí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 alkalmaz 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éseket folyamatosan hajtják végre.

A magas rendelkezésre állású megoldás célja annak biztosítása, 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 szolgáltatási szint alapján két különböző magas rendelkezésre állású architektúramodell létezik:

  • A távoli tárolási modell a számítás és a tárolás általános célú szolgáltatási szinten való elkülönítésén alapul, amely a távoli tároló magas 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 magas rendelkezésre állására támaszkodik. Ez a magas 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 fürtöjén alapul, amelyek a helyi tárolóval rendelkező üzletileg kritikus szolgáltatási szinten elérhető adatbázismotor-csomópontok kvórumán alapulnak. 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ényt biztosít a számítási feladatokra a karbantartási tevékenységek során.

Helyileg redundáns rendelkezésre állás

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. Í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.

Á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. 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. A helyileg redundáns rendelkezésre állás az adatok helyileg redundáns tároláson (LRS) való tárolásán alapul, amely háromszor másolja az adatokat egyetlen adatközpontba 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.

üzletileg kritikus szolgáltatási szint

A ü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.

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 feladathoz. 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 elérhető az olvasási-írási ügyfél számítási feladataihoz, valamint legfeljebb három másodlagos replikát (számítást és tárolást), amelyek 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. 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 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á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.

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

A zónaredundáns rendelkezésre állás alapja a számítási csomópontok és a tárrepliká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 fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely.

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 a felügyelt SQL-példány különböző replikákat helyezhet el egy üzletileg kritikus-példány különböző rendelkezésre állási zónáiban ugyanabban a régióban. Ugyanígy az általános célú szolgáltatási szint állapot nélküli számítási csomópontjai egy másik rendelkezésre állási zónába kerülnek, míg az állapotalapú tárolás zónaredundáns tárolási (ZRS) konfigurációt használ.

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 (ATM) vezérli. Zónaredundáns konfiguráció kiválasztásával a üzletileg kritikus vagy az Á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á is konvertálhatja.

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 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 zónaredundancia használatakor vegye figyelembe a következőket:

Támogatott régiók üzletileg kritikus példányokhoz

A felügyelt SQL-példány üzletileg kritikus zónaredundanciát a következő régiókban támogatjuk:

Észak-, Dél- és Közép-Amerika Európa Közel-Kelet Afrika Ázsia és a Csendes-óceáni térség
Dél-Brazília Közép-Franciaország Qatar Central South Africa North Australia East
Canada Central Észak-Olaszország Izrael középső régiója Central India
Central US Germany West Central Japan East
East US Norway East Korea Central
East US 2 North Europe Southeast Asia
South Central US UK South East Asia
West US 2 Sweden Central
West US 3 Switzerland North
Közép-Lengyelország

Általános célú példányok támogatott régiói

Megjegyzés:

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

Észak-, Dél- és Közép-Amerika Európa Közel-Kelet Afrika Ázsia és a Csendes-óceáni térség
Dél-Brazília Közép-Franciaország Qatar Central South Africa North Australia East
East US Észak-Olaszország Izrael középső régiója Central India
East US 2 Germany West Central Japan East
South Central US Norway East Korea Central
West US 2 North Europe Southeast Asia
West US 3 UK South East Asia
Sweden Central
Switzerland North
Közép-Lengyelország

Alkalmazáshibák rugalmasságának tesztelése

A magas 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 a felügyelt példányok újraindítására szolgáló speciális API meghívásával. Zónaredundáns példány 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 felügyelt példány esetében 15 percenként csak egy feladatátvételi hívás engedélyezett.

A 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étel az sql mi feladatátvétel rest API-hívás meghívására használható az Azure CLI-ből

Összefoglalá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. A üzletileg kritikus szolgáltatásszint 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.

További lépések