Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőkre vonatkozik:SQL Server Linux rendszeren
A SQL Server 2017 (14.x) verziójától kezdve a SQL Server mind a Linux, mind a Windows rendszert támogatja. A Windows-alapú SQL Server-környezetekhez hasonlóan az SQL Server-adatbázisoknak és -példányoknak magas rendelkezésre állásúnak kell lenniük Linux alatt. Ez a cikk a Pacemaker corosync-nal való megismeréséhez, valamint az SQL Server-konfigurációkhoz való tervezéséhez és üzembe helyezéséhez szükséges alapvető információkat ismerteti.
HA kiegészítő és kiterjesztés alapjai
Minden jelenleg támogatott disztribúció magas rendelkezésre állású kiegészítőt vagy kiterjesztést tartalmaz, amely a Pacemaker klaszterezési stacken alapul. Ez a csomag két fő összetevőt tartalmaz: a Pacemakert és a Corosyncot. A verem összes összetevője a következő:
- Szívritmus-szabályozó. A fürtözött gépek közötti koordinációt végző alapvető összetevő.
- Corosync. Egy keretrendszer és API-k készlete, amely olyan dolgokat biztosít, mint a kvórum, a sikertelen folyamatok újraindításának lehetősége stb.
- libQB. Olyan dolgokat biztosít, mint a naplózás.
- Erőforrás-ügynök. Adott funkciók, amelyekkel az alkalmazások integrálhatók a Pacemakerrel.
- Kerítésügynök. Szkriptek/funkciók, amelyek segítenek a csomópontok elkülönítésében, és ha problémákat tapasztalnak, kezelik őket.
Note
A fürt vermet gyakran Pacemakernek nevezik a Linux-világon.
Ez a megoldás bizonyos szempontból hasonló, de sok szempontból különbözik a fürtözött konfigurációk Windows használatával történő üzembe helyezésétől. A Windows rendszerben a rendelkezésre állási forma, az úgynevezett Windows Server feladatátvevő fürt (WSFC), be van építve az operációs rendszerbe. Az a szolgáltatás, amely lehetővé teszi egy WSFC létrehozását, a feladatátvételi fürtszolgáltatás, alapértelmezés szerint le van tiltva. A Windowsban az AG-k és FCI-k egy WSFC-n alapulnak, és szoros integrációt biztosítanak az SQL Server által biztosított adott erőforrás-DLL miatt. Ez a szorosan összekapcsolt megoldás nagyrészt azért lehetséges, mert minden egy szállítótól származik.
Linux rendszeren, bár minden támogatott disztribúcióhoz elérhető a Pacemaker, minden disztribúció testre szabható, és némileg eltérő implementációkkal és verziókkal rendelkezik. A különbségek egy része a jelen cikkben szereplő utasításokban is megjelenik. A fürtözési réteg nyílt forráskódú, így annak ellenére, hogy a disztribúciókkal együtt szállítják, nem integrálódik olyan szorosan, mint ahogyan a WSFC a Windows alatt integrálódik. A Microsoft ezért biztosítja az mssql-server-ha szolgáltatást, hogy az SQL Server és a Pacemaker csomag közel, de nem teljesen ugyanazt a tapasztalatot kínálja az AG-k és FCI-k számára, mint a Windows alatt.
Az SQL Server 2025 (17.x) verzióban a Cumulative Update (CU) 3 és újabb verziókkal egy új Pacemaker HA agent v2 érhető el Red Hat Enterprise Linux (RHEL) és Ubuntu számára a mssql-server-ha csomagban.
A Pacemaker HA-ügynök v2-ben megbízhatósági és teljesítménybeli fejlesztések történtek az előző ügynökkel szemben, beleértve a következőket:
Továbbfejlesztett feladatátvételi teljesítmény a tervezett és a nem tervezett feladatátvételi idő csökkentése érdekében.
Rugalmas automatikus feladatátvételi szabályzatok támogatása, beleértve az állapot-ellenőrzési időtúllépés és a hibaállapot-szint konfigurálását.
A TLS 1.3 támogatása a Pacemaker-klaszter és az SQL Server közötti kommunikációhoz.
A Pacemaker HA-ügynök v2 jelenleg előzetes verzióban érhető el. A meglévő Pacemaker HA-ügynök (v1) továbbra is teljes mértékben támogatott a produkciós telepítésekhez.
A Pacemaker átfogó dokumentációjáért, ami tartalmaz egy részletesebb magyarázatot az összes referenciainformációval az RHEL-hez és az SLES-hez:
Note
Az SQL Server 2025 -től (17.x) kezdődően a SUSE Linux Enterprise Server (SLES) nem támogatott. Az SQL Server 2022 (16.x) és korábbi verziók esetében csak az SLES 15 támogatott.
További információért az egész stackről, nézze meg a Pacemaker hivatalos dokumentációs oldalát a ClusterLabs webhelyén.
Pacemaker fogalmak és terminológia
Ez a szakasz a Pacemaker implementációjának általános fogalmait és terminológiáit ismerteti.
Node
A csomópont egy klaszterben részt vevő kiszolgáló. A Pacemaker-fürtök natív módon legfeljebb 16 csomópontot támogatnak. Ez a szám túlléphető, ha a Corosync nem fut további csomópontokon, de az SQL Serverhez Corosync szükséges. Ezért egy fürt legfeljebb 16 csomópontból állhat bármely SQL Server-alapú konfiguráció esetén; ez a Pacemaker korlátja, és nincs köze az SQL Server által megszabott AG-k vagy FCI-k maximális korlátozásaihoz.
Erőforrás
A WSFC és a Pacemaker-fürt is rendelkezik egy erőforrás fogalmával. Az erőforrás a fürt kontextusában futó specifikus funkció, például egy lemez vagy egy IP-cím. A Pacemakerben például az FCI és az AG-erőforrások is létrehozhatók. Ez nem különbözik a WSFC-ben végzett műveletekkel, ahol egy FCI-hez vagy AG-erőforráshoz tartozó SQL Server-erőforrás jelenik meg az AG konfigurálásakor, de ez nem teljesen azonos az SQL Server pacemakerrel való integrálásának alapvető különbségei miatt.
A Pacemaker szabványos és klónozott erőforrásokkal rendelkezik. A klónozott erőforrások az összes csomóponton egyidejűleg futó erőforrások. Ilyen lehet például egy IP-cím, amely több csomóponton fut terheléselosztási célokra. Az FCI-k számára létrehozott erőforrások szabványos erőforrást használnak, mivel egy adott időpontban csak egy csomópont üzemeltethet FCI-t.
Note
Ez a cikk a rabszolga kifejezésre hivatkozik, amelyet Microsoft már nem használ. Ha a kifejezés el lesz távolítva a szoftverből, eltávolítjuk a jelen cikkből.
Egy újonnan létrehozott AG speciális klón erőforrás típust igényel, amelyet többállapotú erőforrásnak hívnak. Míg egy AG-nek csak egy elsődleges replikája van, a rendelkezésre állási csoport minden konfigurált csomóponton fut, és potenciálisan lehetővé teheti például csak olvasási hozzáférést. Mivel a csomópont ezen használata éles, az erőforrásoknak két állapota van: promotált és nem promotált. További információ: Többállapotú erőforrások: Több módú erőforrások.
Erőforráscsoportok/készletek
Hasonlóan a WSFC-szerepkörökhöz, a Pacemaker-fürtnek is van egy erőforráscsoport-koncepciója. Az erőforráscsoportok (úgynevezett SLES-csoportok ) olyan erőforrások gyűjteményei, amelyek együtt működnek, és egyetlen egységként feladatátvételt végezhetnek az egyik csomópontról a másikra. Az erőforráscsoportok nem tartalmazhatnak előléptetettként vagy nempromotáltként konfigurált erőforrásokat; ezért nem használhatók AG-khez. Bár az erőforráscsoport használható FCI-khez, ez általában nem ajánlott konfiguráció.
Constraints
A WSFC-k különböző paraméterekkel rendelkeznek az erőforrásokhoz és a függőségekhez, amelyek két különböző erőforrás közötti szülő-gyermek kapcsolatról tájékoztatják a WSFC-t. A függőség csak egy szabály, amely közli a WSFC-vel, hogy melyik erőforrásnak kell először online lennie.
A Pacemaker-fürtök nem rendelkeznek a függőségek fogalmával, de vannak korlátozások. Háromféle korlátozás létezik: a közös elhelyezés, a hely, és a sorrendes elrendezés.
- Egy közös elhelyezési kényszer meghatározza, hogy két erőforrás fut-e ugyanazon a csomóponton.
- A helymegkötés azt jelzi a Pacemaker-fürtnek, hogy egy erőforrás hol futhat (vagy nem).
- A sorrendi megkötés azt jelzi a Pacemaker-fürtnek, hogy milyen sorrendben kell elindítani az erőforrásokat.
Note
Az erőforráscsoportban lévő erőforrásokhoz nincs szükség áthelyezési korlátozásokra, mivel ezek mindegyike egyetlen egységnek tekinthető.
Kvórum, kerítésügynökök és STONITH
A Pacemaker alatti kvórum hasonló a WSFC koncepciójához. A fürt kvórummechanizmusának fő célja annak biztosítása, hogy a fürt működőképes maradjon. A Linux-disztribúciók WSFC és HA bővítményei is rendelkeznek a szavazás fogalmával, ahol minden csomópont a kvórum felé számít. Azt szeretné, hogy a szavazatok többsége támogató legyen, ha nem, a legrosszabb esetben a cluster leáll.
A WSFC-vel ellentétben nincs olyan tanúsító erőforrás, amely kvórummal dolgozik. A WSFC-hez hasonlóan a cél az, hogy a szavazók száma páratlan legyen. A kvórumkonfiguráció eltérő szempontokat vesz figyelembe az AG-k és az FCI-k esetében.
A WSFC-k figyelik a részt vevő csomópontok állapotát, és probléma esetén kezelik őket. A WSFC-k későbbi verziói olyan funkciókat kínálnak, mint a csomópontok karanténba helyezése, ha azok hibásan viselkednek vagy nem elérhetők (például a csomópont nincs bekapcsolva vagy a hálózati kommunikáció leállt stb.). Linux-oldalon ezt a funkciót egy kerítésügynök biztosítja. A koncepciót néha kerítésnek is nevezik. Ezek a kerítésügynökök azonban az üzembe helyezésre jellemzőek, és gyakran hardvergyártók és bizonyos szoftvergyártók, például hipervizorokat biztosítók biztosítják őket. A VMware például egy kerítésügynököt biztosít, amely a vSphere használatával virtualizált Linux rendszerű virtuális gépekhez használható.
A kvórum és a kerítés az úgynevezett STONITH (azaz „Lőjük fejbe a másik csomópontot”) nevű koncepcióhoz kapcsolódik. A STONITH-nak támogatnia kell a Pacemaker-fürtöt minden Linux-disztribúción. További információért lásd a Zárlat egy Red Hat magas rendelkezésre állású klaszterben (RHEL).
corosync.conf
A corosync.conf fájl a fürt konfigurációját tartalmazza. A következő helyen található: /etc/corosync. A normál napi műveletek során ezt a fájlt soha nem kell szerkeszteni, ha a fürt megfelelően van beállítva.
Klaszternapló helye
A Pacemaker-fürtök naplóhelyei az eloszlástól függően eltérőek.
- RHEL és SLES:
/var/log/cluster/corosync.log - Ubuntu:
/var/log/corosync/corosync.log
Az alapértelmezett naplózási hely megváltoztatásához módosítsa a corosync.conf.
Pacemaker-fürtök tervezése SQL Serverhez
Ez a szakasz a Pacemaker-fürt fontos tervezési pontjait ismerteti.
Linux-alapú Pacemaker-fürtök virtualizálása SQL Serverhez
Az AG-k és FCI-k Linux-alapú SQL Server-telepítéseinek virtuális gépeken való üzembe helyezésére ugyanazok a szabályok vonatkoznak, mint a Windows-alapú társaikra. A Microsoft által a hardvervirtualizálási környezetben futó Microsoft SQL Server-termékek támogatási szabályzatában szereplő virtualizált SQL Server-környezetek támogatásának alapvető szabályai vannak. A különböző hipervizorok, például Microsoft Hyper-V és a VMware ESXi-jének eltérő varianciái lehetnek ezen felül, a platformok közötti különbségek miatt.
Virtualizáció alatt álló AG-k és FCI-k esetében győződjön meg arról, hogy az anti-affinitás egy adott Pacemaker-fürt csomópontjaihoz van beállítva. Ha magas rendelkezésre állásra van konfigurálva egy AG- vagy FCI-konfigurációban, a SQL Server üzemeltető virtuális gépeknek soha nem kell ugyanazon a hipervizor-gazdagépen futniuk. Ha például egy kétcsomópontos FCI van üzembe helyezve, legalább három hipervizor-gazdagépnek kell lennie, hogy legyen valahol egy csomópontot üzemeltető virtuális gép, amely egy gazdagép meghibásodása esetén induljon el, különösen akkor, ha olyan funkciókat használ, mint az élő áttelepítés vagy a vMotion.
A Hyper-V dokumentációját lásd: Vendégklaszterezés használata magas rendelkezésre álláshoz
Network
A WSFC-vel ellentétben a Pacemaker nem igényli, hogy a Pacemaker-fürt rendelkezzen saját névvel vagy legalább egy dedikált IP-címmel. Az AG-knek és FCI-knek IP-címekre lesz szükségük (további információkért tekintse meg a dokumentációt), de neveket nem, mivel nincs hálózatinév-erőforrás. Az SLES lehetővé teszi egy IP-cím konfigurálását adminisztrációs célokra, de nem szükséges, ahogy az a Pacemaker-fürt létrehozásakor látható.
A WSFC-hez hasonlóan a Pacemaker is a redundáns hálózatkezelést részesíti előnyben, ami azt jelenti, hogy a különböző hálózati kártyák (hálózati adapterek vagy fizikai számítógépek) egyedi IP-címekkel rendelkeznek. A fürtkonfiguráció szempontjából minden IP-címnek saját gyűrűje lenne. A WSFC-khez hasonlóan azonban számos implementáció virtualizálva van, vagy a nyilvános felhőben, ahol csak egyetlen virtualizált hálózati adapter (vNIC) jelenik meg a kiszolgálón. Ha az összes számítógép és virtuális hálózati adapter ugyanahhoz a fizikai vagy virtuális kapcsolóhoz csatlakozik, a hálózati rétegben nincs valódi redundancia, így a több hálózati adapter konfigurálása kissé illúzió a virtuális gép számára. A hálózati redundancia általában a virtualizált telepítések hipervizorába van beépítve, és a nyilvános felhőben is biztosított.
Az egyik különbség a több hálózati adapter és a Pacemaker és a WSFC között az, hogy a Pacemaker több IP-címet engedélyez ugyanazon az alhálózaton, míg a WSFC nem. További információért a többszörös alhálózatokról és Linux-fürtökről lásd a cikket: Több alhálózatos Always On rendelkezésre állási csoportok és feladatátvevő fürtpéldányok konfigurálása.
Kvórum és SZTONITH
A kvórumkonfiguráció és a követelmények a SQL Server AG- vagy FCI-specifikus üzembe helyezéséhez kapcsolódnak.
A támogatott Pacemaker-fürthöz szükséges a STONITH. A STONITH konfigurálásához használja a disztribúció dokumentációját. Ilyen például az SLES-hez készült Storage-alapú kerítés . A VMware vCenterhez esXI-alapú megoldásokhoz egy STONITH-ügynök is rendelkezésre áll. További információ: Stonith beépülő modulügynök a VMware VM VCenter SOAP-kerítéshez (nem hivatalos).
Interoperability
Ez a szakasz azt ismerteti, hogy a Linux-alapú fürtök hogyan működhetnek közösen a WSFC-vel vagy Linux más elosztásaival.
WSFC
Jelenleg nincs közvetlen módja annak, hogy egy WSFC és egy Pacemaker klaszter együttműködjön. Ez azt jelenti, hogy nem lehet olyan AG-t vagy FCI-t létrehozni, amely működik a WSFC-ben és a Pacemakerben. Azonban két együttműködési megoldás létezik, amelyek mindegyike az AG-k számára lett kialakítva. Az FCI csak akkor vehet részt platformfüggetlen konfigurációkban, ha példányként vesz részt az alábbi két forgatókönyv egyikében:
- Nincs fürttípusú AG. További információkért tekintse meg a Windows rendelkezésre állási csoportok dokumentációját.
- Elosztott AG, amely egy speciális típusú rendelkezésre állási csoport, amely lehetővé teszi két különböző AG konfigurálását saját rendelkezésre állási csoportként. Az elosztott AG-kkel kapcsolatos további információkért tekintse meg az elosztott rendelkezésre állási csoportok dokumentációját.
Egyéb Linux-disztribúciók
Linuxon a Pacemaker-fürt összes csomópontjának azonos eloszlásúnak kell lennie. Ez például azt jelenti, hogy az RHEL-csomópontok nem lehetnek SLES-csomópontot tartalmazó Pacemaker-fürt részei. Ennek fő oka korábban az volt, hogy a disztribúciók különböző verziókkal és funkciókkal rendelkezhetnek, így a dolgok nem működnek megfelelően. A disztribúciók keverésének ugyanaz a története, mint a WSFC-k és a Linux keverése: a Nincs vagy az elosztott AG-k használata.