Megosztás:

Pacemaker rendelkezésre állási csoportokhoz és feladatátvevő fürtpéldányokhoz Linuxon

A következőkre vonatkozik:SQL Server Linux rendszeren

Az SQL Server 2017 -től (14.x) kezdve az SQL Server linuxos és Windows rendszeren is támogatott. 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.

A HA bővítmények/bővítmények alapjai

Az összes jelenleg támogatott disztribúció magas rendelkezésre állású bővítményt/bővítményt szállít, amely a Pacemaker-fürtözési veremen 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.

Megjegyzés:

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.

A magas rendelkezésre állás alapjainak diagramja.

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.

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:

Megjegyzés:

Az SQL Server 2025 -től (17.x) kezdődően a SUSE Linux Enterprise Server (SLES) nem 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.

Megjegyzés:

Ebben a cikkben szerepel a slave (alárendelt) kifejezés, amelyet a 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.

AG létrehozásakor egy többállapotú úgynevezett klónerőforrás speciális formáját igényli. Bár egy AG csak egy elsődleges replikával rendelkezik, maga az AG fut az összes olyan csomóponton, amelyen konfigurálva van, és lehetővé teheti például az írásvédett hozzáférést. Mivel ez a csomópont "élő" használata, az erőforrások két állapottal rendelkeznek: Feloldott (korábban Elsődleges) és Nemelőléptetett (korábban Másodlagos). 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ó.

Megszorítások

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.

Megjegyzés:

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 a 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, az SQL Servert futtató virtuális gépek soha nem futhatnak ugyanazon a hipervizor-gazdagépen. 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

Hálózat

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 az SQL Server AG- vagy FCI-specifikus üzemelő példányaival kapcsolatosak.

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

Interoperabilitás

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:

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.

Kapcsolódó tartalom

  • Last updated on