A magas rendelkezésre állás és a vészhelyreállítási lehetőségek megismerése

15 perc

A virtuális gépek (VM-ek) megoldásának létrehozásához először ismernie kell az IaaS-alapú üzemelő példányok rendelkezésre állási lehetőségeit.

Szolgáltatásként nyújtott infrastruktúra és szolgáltatásként nyújtott platform

A rendelkezésre állás szempontjából az IaaS vagy a PaaS kiválasztása sokat számít. Az IaaS-ben van egy virtuális gépe, ami azt jelenti, hogy van egy operációs rendszer az SQL Server telepítésével. Az SQL Serverért felelős rendszergazdának vagy csoportnak számos magas rendelkezésre állású és vészhelyreállítási (HADR) megoldással kellene rendelkeznie, és nagy mértékben szabályozná a megoldás konfigurálásának módját.

PaaS-alapú üzemelő példányokkal, például az Azure SQL Database-zel a HADR-megoldások beépítettek a szolgáltatásba, és gyakran csak engedélyezni kell őket. Vannak minimális beállítások, amelyek konfigurálhatók.

E különbségek miatt az IaaS vagy a PaaS kiválasztása befolyásolhatja a HADR-megoldás végleges kialakítását.

SQL Server HADR-funkciók azure-beli virtuális géphez

Az IaaS használatakor az SQL Server által biztosított funkciókkal növelheti a rendelkezésre állást. Bizonyos esetekben kombinálhatók Azure-szintű funkciókkal, hogy még tovább növeljék a rendelkezésre állást.

Az SQL Serverben elérhető funkciók az alábbi táblázatban láthatók

Szolgáltatásnév	Védi
Always On Feladatátvevő fürtpéldány (FCI)	Példány
Always On Rendelkezésre állási csoport (AG)	Database
Naplóátvitel	Database

Az SQL Server egy példánya az SQL Server teljes telepítése (bináris fájlok, a példányon belüli összes objektum, beleértve a bejelentkezéseket, az SQL Server-ügynök feladatait és az adatbázisokat). A példányszintű védelem azt jelenti, hogy a rendelkezésre állási funkció a teljes példányt figyelembe veszi.

Az SQL Server egyik adatbázisa tartalmazza a végfelhasználók és alkalmazások által használt adatokat. Vannak olyan rendszeradatbázisok, amelyekre az SQL Server támaszkodik, valamint a végfelhasználók és alkalmazások által használatra létrehozott adatbázisok. Az SQL Server egy példánya mindig rendelkezik saját rendszeradatbázisokkal. Az adatbázisszintű védelem azt jelenti, hogy a rendelkezésre állási funkció részeként minden, az adatbázisban található, vagy a felhasználói vagy alkalmazásadatbázis tranzakciónaplójában rögzítve van. Minden, az adatbázison kívül található vagy a tranzakciónapló részeként nem rögzített, például az SQL Server-ügynök feladatait és a csatolt kiszolgálókat manuálisan kell kezelni, hogy a célkiszolgáló úgy működjön, mint az elsődleges, ha tervezett vagy nem tervezett feladatátvételi esemény történik.

Az FCI-k és az AG-k egyaránt igényelnek egy mögöttes fürtmechanizmust. A Windows Serveren futó SQL Server-üzemelő példányok esetében ez egy Windows Server feladatátvevő fürt (WSFC), Linux esetén pedig Pacemaker.

Always On Feladatátvevő fürtpéldányok

Az FCI konfigurálva van az SQL Server telepítésekor. Az SQL Server önálló példánya nem konvertálható FCI-vé. Az FCI-hez egyedi név, valamint a fürtben részt vevő mögöttes kiszolgálóktól vagy csomópontoktól eltérő IP-cím van hozzárendelve. A névnek és az IP-címnek is különböznie kell a mögöttes fürt mechanizmusától. Az alkalmazások és a végfelhasználók az FCI egyedi nevét használják a hozzáféréshez. Ez az absztrakció lehetővé teszi, hogy az alkalmazásoknak ne kelljen tudniuk, hol fut a példány. Az Azure-alapú FCI-k és a helyszíni FCI-k közötti egyik fő különbség az, hogy az Azure-hoz belső terheléselosztóra (ILB) van szükség. Az ILB segítségével biztosítható, hogy az alkalmazások és a végfelhasználók csatlakozni tudjanak az FCI egyedi nevéhez.

Ha egy FCI feladatátvételt ad át egy fürt egy másik csomópontjának, függetlenül attól, hogy manuálisan indítják el, vagy probléma miatt történik, a teljes példány újraindul egy másik csomóponton. Ez azt jelenti, hogy a feladatátvételi folyamat az SQL Server teljes leállítása és elindítása. Az FCI-hez csatlakozó alkalmazások vagy végfelhasználók a feladatátvétel során megszakadnak, és csak azok az alkalmazások csatlakozhatnak újra automatikusan, amelyek képesek kezelni és helyreállítani ezt a megszakítást.

A másik csomóponton való indításkor a példány végighalad a helyreállítási folyamaton. Az FCI konzisztens lesz a meghibásodási ponttal, így technikailag nem lesz adatvesztés, de a visszaállítás részeként minden olyan tranzakció, amelyet vissza kell állítani. Mint fentebb említettük, mivel ez a példányszintű védelem, minden szükséges (bejelentkezés, SQL Server Agent-feladat stb.) már létezik, így az adatbázisok készenlétben a szokásos módon folytathatják az üzleti munkát.

Az FCI-knek egy adatbázispéldányra van szükségük, de ez egyben az egyetlen meghibásodási pontjuk is. Annak érdekében, hogy egy másik csomópont hozzáférhessen az adatbázishoz, az FCI-k valamilyen megosztott tárterületet igényelnek. A Windows Server-alapú architektúrák esetében ez az Azure Premium-fájlmegosztás, az iSCSI, az Azure Shared Disk, a Tárolóhelyek Direct (S2D) vagy egy támogatott külső megoldás, például az SIOS DataKeeper segítségével érhető el. Az SQL Server Standard kiadás használó FCI-k legfeljebb két csomóponttal rendelkezhetnek. Az FCI-k megkövetelik a Active Directory tartományi szolgáltatások (AD DS) és a Domain Name Services (DNS) használatát is, ami azt jelenti, hogy az AD DS-t és a DNS-t valahol az Azure-ban kell implementálnia ahhoz, hogy az FCI működjön.

A Windows Server 2016 vagy újabb verziók használatával az FCI-k a Tárreplika használatával natív vészhelyreállítási megoldást hozhatnak létre az FCI-k számára anélkül, hogy más funkciót, például a naplószállítást vagy az AG-ket kellene használniuk.

AlwaysOn rendelkezésreállási csoportok

Az AG-k az SQL Server 2012 Enterprise kiadás és az SQL Server 2016-ban is Standard kiadás találhatók. A Standard kiadás egy AG egy adatbázist tartalmazhat, míg Enterprise kiadás egy AG több adatbázissal is rendelkezhet. Bár az AG-k hasonlóságot tapasztalnak az FCI-kkel, a legtöbb módon különböznek.

Az FCI és az AG között a legnagyobb különbség az, hogy az AG-k adatbázisszintű védelmet nyújtanak. Az elsődleges replika az írási/olvasási adatbázisokat tartalmazó AG-ben részt vevő példány. A másodlagos replika az, ahol az elsődleges tranzakciókat küld a naplóátvitelen, hogy szinkronizálva maradjon. Az elsődleges replika közötti adatáthelyezés lehet szinkron vagy aszinkron. A másodlagos replikák adatbázisai betöltési állapotban vannak, ami azt jelenti, hogy fogadhatnak tranzakciókat, de nem lehetnek teljesen írható példányok, amíg ez a replika nem lesz az elsődleges. A Standard kiadás AG legfeljebb két replikával (egy elsődleges, egy másodlagos) rendelkezhet, míg Enterprise kiadás legfeljebb kilenc (egy elsődleges, nyolc másodlagos) replikával rendelkezhet. A másodlagos replika inicializálva van az adatbázis biztonsági másolatából, vagy az SQL Server 2016-tól használhatja az "automatikus vetés" nevű funkciót. Az automatikus vetés a naplóstream-átvitel használatával streameli a biztonsági másolatot a rendelkezésre állási csoport egyes adatbázisainak másodlagos replikájába a konfigurált végpontok használatával.

Az AG absztrakciót biztosít a figyelő számára. A figyelő úgy működik, mint az FCI-hez rendelt egyedi név, és saját neve és IP-címe különbözik minden mástól (WSFC, csomópont stb.). A figyelőnek ILB-t is kell igényelnie, és meg kell állítania és el kell kezdenie. Az alkalmazások és a végfelhasználók használhatják a figyelőt a csatlakozáshoz, de az FCI-től eltérően, ha szükséges, a figyelőt nem kell használni. Csatlakozás közvetlenül a példányhoz. A Enterprise kiadás a másodlagos replikák Enterprise kiadás igény szerint írásvédett hozzáférésre is konfigurálhatók, és más funkciókhoz, például adatbázis-konzisztencia-ellenőrzésekhez (DBCC-khez) és biztonsági másolatokhoz is használhatók.

Az AG-k gyorsabb feladatátvételi idővel rendelkezhetnek az FCI-hez képest, ami az egyik oka annak, hogy vonzóak. Bár az AG-k nem igényelnek megosztott tárolást, minden replika rendelkezik az adatok egy-egy példányával, ami növeli az adatbázis másolatainak teljes számát és a teljes tárolási költségeket. A tárterület minden replikához helyi. Ha például az elsődleges replikán lévő adatbázisok adatlábnyoma 1 TB, minden replika ugyanazzal a módszerrel fog rendelkezni. Ha öt replika van, az azt jelenti, hogy 5 TB-ra van szükség.

Ne feledje, hogy az adatbázison kívül található vagy az adatbázis tranzakciónaplójában nem rögzített objektumokat manuálisan kell létrehozni és elszámolni bármely más SQL Server-példányon, ha az adott példánynak az új elsődleges replikává kell válnia. Ilyen objektumok lehetnek például az SQL Server Agent-feladatok, a példányszintű bejelentkezések és a csatolt kiszolgálók. Ha Windows-hitelesítést használhat, vagy tartalmazott adatbázisokat használhat az AG-kkel, az egyszerűbbé teszi a hozzáférést.

Számos szervezet szembesülhet a magas rendelkezésre állású architektúrák implementálásával kapcsolatos kihívásokkal, és előfordulhat, hogy csak az Azure platform által biztosított magas rendelkezésre állásra van szüksége, vagy egy PaaS-megoldás, például a felügyelt Azure SQL-példány használatával. Mielőtt áttekintenénk az Azure platformmegoldásait, van egy másik SQL Server-funkció, amiről tudnia kell: naplók szállításáról.

Log shipping

A naplók szállítása az SQL Server korai napjai óta tart. A funkció a biztonsági mentésen, másoláson és visszaállításon alapul, és az SQL Server HADR-jének elérésének egyik legegyszerűbb módja. A naplószállítást elsősorban vészhelyreállításra használják, de a helyi rendelkezésre állás javítására is használható.

A naplók, például az AG-k, adatbázisszintű védelmet nyújtanak, ami azt jelenti, hogy továbbra is figyelembe kell vennie az SQL Server Agent-feladatokat, a társított kiszolgálókat, a példányszintű bejelentkezéseket stb. A naplószállítás nem biztosít natív absztrakciót, ezért a naplószállításban részt vevő másik kiszolgálóra való váltásnak képesnek kell lennie a névváltoztatásra. Ha ez nem lehetséges, léteznek olyan módszerek, mint a DNS-alias, amelyek a hálózati rétegben konfigurálhatók a névváltoztatási problémák megoldására.

A naplószállítási mechanizmus egyszerű: először készítsen teljes biztonsági másolatot a forrásadatbázisról az elsődleges kiszolgálón, állítsa vissza betöltési állapotban (STANDBY vagy NORECOVERY) egy másik, másodlagos kiszolgálóként vagy meleg készenléti állapotban. Az adatbázis új példányát másodlagos adatbázisnak nevezzük. Az SQL Serverbe beépített automatizált folyamat ezután automatikusan biztonsági másolatot készít az elsődleges adatbázis tranzakciónaplóról, átmásolja a biztonsági másolatot a készenléti kiszolgálóra, és végül visszaállítja a biztonsági mentést a készenléti kiszolgálóra.