HADR configuration best practices (SQL Server on Azure VMs)

Cikk
07/31/2023

A következőre vonatkozik:SQL Server azure-beli virtuális gépen

A Windows Server feladatátvevő fürt a magas rendelkezésre álláshoz és vészhelyreállításhoz (HADR) használható az Azure-beli virtuális gépeken futó SQL Serverrel.

Ez a cikk ajánlott eljárásokat nyújt a fürtkonfigurációhoz a feladatátvevő fürtpéldányok (FCI-k) és a rendelkezésre állási csoportok számára az Azure-beli virtuális gépeken futó SQL Server használatakor.

További információkért tekintse meg a sorozat többi cikkét: Ellenőrzőlista, virtuális gép mérete, Tárolás, Biztonság, HADR-konfiguráció, Alapkonfiguráció összegyűjtése.

Checklist

Tekintse át az alábbi ellenőrzőlistát a HADR ajánlott eljárásainak rövid áttekintéséhez, amelyeket a cikk többi része részletesebben is bemutat.

A magas rendelkezésre állási és vészhelyreállítási (HADR) funkciók, például az Always On rendelkezésre állási csoport és a feladatátvevő fürtpéldány a Windows Server feladatátvételi fürt technológiájára támaszkodnak. Tekintse át a HADR-beállítások módosításának ajánlott eljárásait a felhőkörnyezet jobb támogatása érdekében.

A Windows-fürt esetében vegye figyelembe az alábbi ajánlott eljárásokat:

Ha lehetséges, helyezze üzembe az SQL Server virtuális gépeket több alhálózaton, hogy elkerülje az Azure Load Balancer vagy egy elosztott hálózati név (DNN) függőségét, hogy a forgalmat a HADR-megoldáshoz irányíthassa.
Módosítsa a fürtöt kevésbé agresszív paraméterekre, hogy elkerülje az átmeneti hálózati hibák vagy az Azure platformkarbantartás váratlan kimaradását. További információkért tekintse meg a szívverési és küszöbérték-beállításokat. Windows Server 2012 és újabb verziók esetén használja a következő ajánlott értékeket:
- SameSubnetDelay: 1 másodperc
- SameSubnetThreshold: 40 szívverés
- CrossSubnetDelay: 1 másodperc
- CrossSubnetThreshold: 40 szívverés
Helyezze a virtuális gépeket egy rendelkezésre állási csoportba vagy különböző rendelkezésre állási zónákba. További információkért tekintse meg a virtuális gépek rendelkezésre állási beállításait.
Fürtcsomópontonként egyetlen hálózati adaptert használjon.
Konfigurálja a fürt kvórumszavazását úgy, hogy 3 vagy több páratlan számú szavazatot használjon. Ne rendeljen szavazatokat dr. régiókhoz.
Gondosan monitorozza az erőforráskorlátokat , hogy elkerülje az erőforrás-korlátozások miatti váratlan újraindításokat vagy feladatátvételeket.
- Győződjön meg arról, hogy az operációs rendszer, az illesztőprogramok és az SQL Server a legújabb buildekben vannak.
- Optimalizálja az SQL Server teljesítményét Azure-beli virtuális gépeken. További információért tekintse át a cikk többi szakaszát.
- Csökkentse vagy elosztsa a számítási feladatokat az erőforráskorlátok elkerülése érdekében.
- Lépjen egy olyan virtuális gépre vagy lemezre, amelyet a korlátozások elkerülése érdekében a nagyobb korlátok szabnak meg.

Az SQL Server rendelkezésre állási csoportjához vagy feladatátvevő fürtpéldányához vegye figyelembe az alábbi ajánlott eljárásokat:

Ha gyakran tapasztal váratlan hibákat, kövesse a cikk további részében ismertetett ajánlott teljesítmény-ajánlott eljárásokat.
Ha az SQL Server virtuális gép teljesítményének optimalizálása nem oldja meg a váratlan feladatátvételeket, fontolja meg a rendelkezésre állási csoport vagy a feladatátvevő fürtpéldány figyelését . Ez azonban nem feltétlenül oldja meg a probléma forrását, és a hibák valószínűségének csökkentésével elfedheti a tüneteket. Előfordulhat, hogy továbbra is meg kell vizsgálnia és kezelnie kell a mögöttes kiváltó okot. Windows Server 2012 vagy újabb verziók esetén használja a következő ajánlott értékeket:
- Bérlet időtúllépése: Ezzel az egyenletel kiszámíthatja a bérlet maximális időtúllépési értékét:
  Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
  Kezdje 40 másodperccel. Ha a korábban javasolt nyugodt SameSubnetThreshold és SameSubnetDelay értékeket használja, a bérlet időtúllépési értéke ne haladja meg a 80 másodpercet.
- Hibák maximális értéke egy megadott időszakban: Állítsa ezt az értéket 6-ra.
Ha a virtuális hálózat nevét (VNN) és egy Azure Load Balancert használ a HADR-megoldáshoz való csatlakozáshoz, akkor is adja meg MultiSubnetFailover = true a kapcsolati sztring, ha a fürt csak egy alhálózatra terjed ki.
- Ha az ügyfél nem támogatja MultiSubnetFailover = True , előfordulhat, hogy rövidebb ideig kell beállítania RegisterAllProvidersIP = 0 és HostRecordTTL = 300 gyorsítótárazza az ügyfél hitelesítő adatait. Ez azonban további lekérdezéseket okozhat a DNS-kiszolgálónak.

Ha az elosztott hálózati névvel (DNN) szeretne csatlakozni a HADR-megoldáshoz, vegye figyelembe a következőket:
- Olyan ügyfélillesztőt kell használnia, amely támogatjaMultiSubnetFailover = True, és ennek a paraméternek a kapcsolati sztring kell lennie.
- A rendelkezésre állási csoport DNN-figyelőjéhez való csatlakozáskor használjon egy egyedi DNN-portot a kapcsolati sztring.
Egy alapszintű rendelkezésre állási csoport adatbázis-tükrözési kapcsolati sztring használatával megkerülheti a terheléselosztó vagy a DNN szükségességét.
A magas rendelkezésre állású megoldás üzembe helyezése előtt ellenőrizze a virtuális merevlemezek szektorméretét, hogy elkerülje a hibás I/OS-t. További információ: KB3009974 .
Ha az SQL Server adatbázismotorja, az Always On rendelkezésre állási csoport figyelője vagy a feladatátvevő fürtpéldány állapottesztje úgy van konfigurálva, hogy 49 152 és 65 536 közötti portot használjon (a TCP/IP alapértelmezett dinamikus porttartománya), adjon hozzá kivételt minden porthoz. Ez megakadályozza, hogy más rendszerek dinamikusan hozzárendelje ugyanazt a portot. Az alábbi példa egy kizárást hoz létre az 59999-s porton:
netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

A HADR-ellenőrzőlista és a többi ajánlott eljárás összehasonlításához tekintse meg a teljesítményre vonatkozó ajánlott eljárások átfogó ellenőrzőlistát.

Virtuális gép rendelkezésre állási beállításai

Az állásidő hatásának csökkentése érdekében vegye figyelembe a virtuális gép legjobb rendelkezésre állási beállításait:

A legkisebb késés érdekében használjon közelségi elhelyezési csoportokat gyorsított hálózatkezeléssel együtt.
Helyezze a virtuálisgép-fürtcsomópontokat külön rendelkezésre állási zónákba, hogy védelmet nyújtson az adatközpontszintű hibáktól, vagy egyetlen rendelkezésre állási készletben, amely alacsonyabb késésű redundanciát biztosít ugyanazon az adatközponton belül.
Prémium szintű felügyelt operációs rendszer és adatlemezek használata rendelkezésre állási csoportban lévő virtuális gépekhez.
Konfigurálja az egyes alkalmazásszinteket külön rendelkezésre állási csoportokba.

Határozatképesség

Bár egy kétcsomópontos fürt kvórumerőforrás nélkül működik, az ügyfeleknek szigorúan kvórumerőforrást kell használniuk az éles környezet támogatásához. A fürtérvényesítés nem ad át fürtöt kvórumerőforrás nélkül.

A háromcsomópontos fürtök gyakorlatilag kvórumerőforrás nélkül képesek túlélni egyetlen csomópont elvesztését (két csomópontig), de miután a fürt két csomópontra csökkent, ha egy másik csomópont elvesztése vagy kommunikációs hibája van, akkor fennáll annak a kockázata, hogy a fürtözött erőforrások offline állapotba kerülnek, hogy megakadályozzák a felosztási forgatókönyvet. A kvórumerőforrás konfigurálása lehetővé teszi, hogy a fürt csak egy csomóponttal legyen online állapotban.

A lemeztanúsítás a legrugalmasabb kvórumbeállítás, de ha lemeztanúsítást szeretne használni egy Azure-beli virtuális gépen futó SQL Serveren, egy Azure-beli megosztott lemezt kell használnia, amely bizonyos korlátozásokat ró a magas rendelkezésre állású megoldásra. Ezért használjon lemeztanúsítót, amikor a feladatátvevő fürtpéldányt Azure Shared Disks használatával konfigurálja, ellenkező esetben használjon felhőbeli tanúsítót, amikor csak lehetséges.

Az alábbi táblázat az Azure-beli virtuális gépeken futó SQL Serverhez elérhető kvórumbeállításokat sorolja fel:

	Felhőbeli tanúsító	Lemeztanúsuló	Fájlmegosztási tanúsító
Támogatott operációs rendszer	Windows Server 2016+	Mind	Mind

A felhőbeli tanúsító ideális több helyen, több zónában és több régióban történő üzembe helyezéshez. Ha lehetséges, használjon felhőbeli tanúsítót, kivéve, ha megosztott tárterületű fürtmegoldást használ.
A lemeztanúsítás a legrugalmasabb kvórumbeállítás, és minden olyan fürt esetében előnyben részesíti, amely Azure-beli megosztott lemezeket (vagy bármely megosztott lemezes megoldást, például megosztott SCSI-t, iSCSI-t vagy szálcsatornás SAN-t) használ. A fürtözött megosztott kötetek nem használhatók lemeztanúsításként.
A fileshare tanúsító akkor használható, ha a lemeztanúsítás és a felhőbeli tanúsító nem érhető el.

Első lépésként tekintse meg a fürt kvórumának konfigurálását ismertető témakört.

Kvórumszavazás

A Windows Server feladatátvevő fürtben részt vevő csomópont kvórumszavazata módosítható.

A csomópont szavazati beállításainak módosításakor kövesse az alábbi irányelveket:

Kvórumszavazási irányelvek
Kezdje azzal, hogy az egyes csomópontok alapértelmezés szerint nem szavaznak. Minden csomópontnak csak kifejezett indoklással rendelkező szavazattal kell rendelkeznie.
Szavazhat a rendelkezésre állási csoport elsődleges replikáját üzemeltető fürtcsomópontokra vagy egy feladatátvevő fürtpéldány előnyben részesített tulajdonosaira.
Engedélyezze a szavazatokat az automatikus feladatátvételi tulajdonosok számára. Minden olyan csomópontnak, amely egy automatikus feladatátvétel eredményeként elsődleges replikát vagy FCI-t üzemeltethet, szavazattal kell rendelkeznie.
Ha egy rendelkezésre állási csoport több másodlagos replikával rendelkezik, csak az automatikus feladatátvétellel rendelkező replikák szavazatait engedélyezze.
Letilthatja a másodlagos vészhelyreállítási helyeken lévő csomópontok szavazatait. A másodlagos helyek csomópontjai nem járulnak hozzá a fürt offline állapotba helyezésének döntéséhez, ha nincs semmi baj az elsődleges hellyel.
A szavazatok száma páratlan, legalább három kvórumszavazattal. Adjon hozzá egy kvórumtanúsulatot , ha szükséges, egy kétcsomópontos fürtben.
A feladatátvétel utáni szavazási hozzárendelések újraértékelése. Nem szeretne olyan fürtkonfigurációba feladatátvételt végezni, amely nem támogatja az kifogástalan kvórumot.

Kapcsolatok

A rendelkezésre állási csoport figyelőjéhez vagy feladatátvevőfürt-példányához való csatlakozás helyszíni élményének megfelelően helyezze üzembe az SQL Server virtuális gépeket ugyanazon a virtuális hálózaton belül több alhálózaton. Ha több alhálózattal rendelkezik, azzal nem szükséges az Azure Load Balancer extra függősége, vagy egy elosztott hálózati név, amely átirányítja a forgalmat a figyelőhöz.

A HADR-megoldás egyszerűsítése érdekében helyezze üzembe az SQL Server virtuális gépeket több alhálózaton, amikor csak lehetséges. További információ: Több alhálózati AG és több alhálózati FCI.

Ha az SQL Server virtuális gépei egyetlen alhálózatban találhatók, virtuális hálózatnevet (VNN) és Azure Load Balancert, illetve elosztott hálózati nevet (DNN) is konfigurálhat a feladatátvevő fürtpéldányok és a rendelkezésre állási csoport figyelői számára.

Ha elérhető, az elosztott hálózat neve az ajánlott kapcsolati lehetőség:

A végpontok közötti megoldás robusztusabb, mivel már nem kell fenntartania a terheléselosztó erőforrását.
A terheléselosztó mintavételeinek kiküszöbölése minimálisra csökkenti a feladatátvétel időtartamát.
A DNN leegyszerűsíti a feladatátvevő fürtpéldány vagy a rendelkezésre állási csoport figyelőjének kiépítését és kezelését az Azure-beli virtuális gépeken futó SQL Serverrel.

Ügyeljen a következő korlátozásokra:

Az ügyfélillesztőnek támogatnia kell a paramétert MultiSubnetFailover=True .
A DNN szolgáltatás az SQL Server 2016 SP3, az SQL Server 2017 CU25 és az SQL Server 2019 CU8 rendszertől kezdve érhető el Windows Server 2016 és újabb rendszereken.

További információkért tekintse meg a Windows Server feladatátvevő fürt áttekintését.

A kapcsolat konfigurálásához tekintse meg az alábbi cikkeket:

Rendelkezésre állási csoport: DNN konfigurálása, VNN konfigurálása
Feladatátvevő fürtpéldány: DNN konfigurálása, VNN konfigurálása.

A legtöbb SQL Server-funkció transzparensen működik az FCI-vel és a rendelkezésre állási csoportokkal a DNN használatakor, de vannak bizonyos funkciók, amelyek különös figyelmet igényelhetnek. További információ: FCI és DNN együttműködési,AG- és DNN-együttműködés .

Tipp.

Állítsa be a MultiSubnetFailover paramétert = igaz értékre a kapcsolati sztring még az egyetlen alhálózatra kiterjedő HADR-megoldások esetében is, hogy az alhálózatok jövőbeni átnyúlását támogassa anélkül, hogy frissítenie kellene kapcsolati sztring.

Szívverés és küszöbérték

Módosítsa a fürt szívverési és küszöbérték-beállításait a nyugodt beállításokra. Az alapértelmezett szívverési és küszöbérték-fürtbeállítások nagy mértékben hangolt helyszíni hálózatokhoz vannak kialakítva, és nem veszik figyelembe a felhőkörnyezetek megnövekedett késésének lehetőségét. A szívverési hálózatot az UDP 3343 tartja karban, amely hagyományosan sokkal kevésbé megbízható, mint a TCP, és hajlamosabb a hiányos beszélgetésekre.

Ezért ha fürtcsomópontokat futtat az SQL Serverhez az Azure-beli virtuális gépek magas rendelkezésre állási megoldásaihoz, módosítsa a fürtbeállításokat nyugodtabb monitorozási állapotra, hogy elkerülje az átmeneti hibákat a hálózati késés vagy a meghibásodás, az Azure karbantartása vagy az erőforrás szűk keresztmetszeteinek megnövekedett lehetősége miatt.

A késési és küszöbérték-beállítások kumulatív hatással vannak az állapot teljes észlelésére. Ha például a CrossSubnetDelayt úgy állítja be, hogy 2 másodpercenként küldjön szívverést, és a CrossSubnetThreshold 10 kihagyott szívverésre van állítva a helyreállítás előtt, akkor a fürt teljes hálózati tűréshatára 20 másodperc lehet a helyreállítási művelet végrehajtása előtt. Általánosságban elmondható, hogy a gyakori szívverések küldése továbbra is javasolt, de a küszöbértékek nagyobbak.

Annak érdekében, hogy a jogos kimaradások során a helyreállítás nagyobb tűrést biztosítson az átmeneti problémákhoz, lazítsa a késleltetési és küszöbérték-beállításokat az alábbi táblázatban ismertetett ajánlott értékekre:

Beállítás	Windows Server 2012 vagy újabb	Windows Server 2008 R2
SameSubnetDelay	1 másodperc	2 másodperc
SameSubnetThreshold	40 szívverés	10 szívverés (max.
CrossSubnetDelay	1 másodperc	2 másodperc
CrossSubnetThreshold	40 szívverés	20 szívverés (max.

A PowerShell használatával módosíthatja a fürt paramétereit:

Windows Server 2012-2019
Windows Server 2008/R2

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

(get-cluster).SameSubnetThreshold = 10
(get-cluster).CrossSubnetThreshold = 20
(get-cluster).SameSubnetDelay = 2000
(get-cluster).CrossSubnetDelay = 2000

A Módosítások ellenőrzése a PowerShell használatával:

get-cluster | fl *subnet*

Consider the following:

Ez a módosítás azonnali, újraindítja a fürtöt, vagy nincs szükség semmilyen erőforrásra.
Az alhálózati értékek nem lehetnek nagyobbak, mint az alhálózatok közötti értékek.
SameSubnetThreshold <= CrossSubnetThreshold
SameSubnetDelay <= CrossSubnetDelay

Válasszon nyugodt értékeket az alkalmazástól, az üzleti igényektől és a környezettől függően attól függően, hogy mennyi időt kell tűrni a leállási időtől, és mennyi ideig kell korrekciós műveletet elvégeznie. Ha nem tudja túllépni az alapértelmezett Windows Server 2019-értékeket, próbálja meg legalább azokat megfeleltetni, ha lehetséges:

Az alábbi táblázat az alapértelmezett értékeket ismerteti:

Beállítás	Windows Server 2019	Windows Server 2016	Windows Server 2008 – 2012 R2
SameSubnetDelay	1 másodperc	1 másodperc	1 másodperc
SameSubnetThreshold	20 szívverés	10 szívverés	5 szívverés
CrossSubnetDelay	1 másodperc	1 másodperc	1 másodperc
CrossSubnetThreshold	20 szívverés	10 szívverés	5 szívverés

További információ: Feladatátvevő fürt hálózati küszöbértékeinek finomhangolása.

Nyugodt monitorozás

Ha a fürt szívverési és küszöbérték-beállításainak javasolt finomhangolása nem elegendő tolerancia, és a valódi kimaradások helyett átmeneti problémák miatt továbbra is feladatátvételek jelennek meg, konfigurálhatja, hogy az AG- vagy FCI-monitorozás nyugodtabb legyen. Bizonyos esetekben hasznos lehet a monitorozás ideiglenes lazítása a tevékenység szintjének függvényében. Például érdemes lehet kikapcsolni a monitorozást, ha intenzív IO-számítási feladatokat végez, például adatbázis-biztonsági mentéseket, indexkarbantartást, DBCC CHECKDB-t stb. A tevékenység befejezése után állítsa a monitorozást kevésbé nyugodt értékekre.

Figyelmeztetés:

Ezeknek a beállításoknak a módosítása elfedheti a mögöttes problémát, és ideiglenes megoldásként kell használni a hiba valószínűségének csökkentése helyett. A mögöttes problémákat továbbra is ki kell vizsgálni és kezelni kell.

Először növelje a következő paramétereket az alapértelmezett értékekből a nyugodt monitorozás érdekében, és szükség szerint módosítsa őket:

Parameter	Alapértelmezett érték	Nyugodt érték	Leírás
Állapotellenőrzés időtúllépése	30000	60000	Meghatározza az elsődleges replika vagy csomópont állapotát. A fürterőforrás DLL-je `sp_server_diagnostics` olyan időközönként adja vissza az eredményeket, amely az állapot-ellenőrzési időkorlát 1/3-ával egyenlő. Ha `sp_server_diagnostics` lassú vagy nem ad vissza információt, az erőforrás DLL az állapot-ellenőrzési időtúllépési küszöbérték teljes intervallumára vár, mielőtt megállapítja, hogy az erőforrás nem válaszol, és ha erre van konfigurálva, automatikus feladatátvételt kezdeményez.
Hibaállapot szintje	3	2	Automatikus feladatátvételt kiváltó feltételek. Öt hibaállapot-szint létezik, amelyek a legkevésbé korlátozótól (1. szint) a legszigorúbbig (5. szint) terjednek.

A Transact-SQL (T-SQL) használatával módosíthatja mind az AG-k, mind az FCI-k állapot-ellenőrzési és hibafeltételét.

Rendelkezésre állási csoportok esetén:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Feladatátvevő fürtpéldányok esetén:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

A rendelkezésre állási csoportokra jellemzően kezdje a következő ajánlott paraméterekkel, és módosítsa szükség szerint:

Parameter	Alapértelmezett érték	Nyugodt érték	Leírás
Bérlet időtúllépése	20000	40 000	Megakadályozza a hasadt agyat.
Munkamenet időtúllépése	10000	20000	Ellenőrzi a replikák közötti kommunikációs problémákat. A munkamenet-időtúllépési időszak egy replikatulajdonság, amely azt szabályozza, hogy a rendelkezésre állási replika mennyi ideig (másodpercben) várja meg a pingválaszt egy csatlakoztatott replikától, mielőtt figyelembe venné, hogy a kapcsolat meghiúsult. Alapértelmezés szerint a replika 10 másodpercet vár a pingelésre adott válaszig. Ez a replikatulajdonság csak az adott másodlagos replika és a rendelkezésre állási csoport elsődleges replikája közötti kapcsolatra vonatkozik.
Hibák maximális kihasználása a megadott időszakban	2	6	A fürtözött erőforrások több csomóponton belüli határozatlan idejű áthelyezésének elkerülésére szolgál. Ha egy érték túl alacsony, az azt eredményezheti, hogy a rendelkezésre állási csoport hibás állapotban van. Növelje az értéket, hogy megelőzze a teljesítményproblémák rövid megszakításait, mivel egy érték túl alacsony, és az AG hibás állapotba kerülhet.

Mielőtt bármilyen módosítást végez, fontolja meg a következőket:

Ne csökkentse az időtúllépési értékeket az alapértelmezett értékek alatt.
Ez az egyenlet a bérlet maximális időtúllépési értékének kiszámításához használható: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
Kezdje 40 másodperccel. Ha a korábban javasolt nyugodt SameSubnetThreshold és SameSubnetDelay értékeket használja, a bérlet időtúllépési értéke ne haladja meg a 80 másodpercet.
A szinkron véglegesítésű replikák esetében a munkamenet-időtúllépés magas értékre való módosítása növelheti HADR_sync_commit várakozásokat.

Bérlet időtúllépése

A Feladatátvevőfürt-kezelővel módosíthatja a rendelkezésre állási csoport bérletének időtúllépési beállításait. A részletes lépésekért tekintse meg az SQL Server rendelkezésre állási csoport bérletének állapot-ellenőrzési dokumentációját.

Munkamenet időtúllépése

A Transact-SQL (T-SQL) használatával módosíthatja egy rendelkezésre állási csoport munkamenet-időtúllépését :

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);

Hibák maximális kihasználása a megadott időszakban

A Feladatátvevőfürt-kezelővel módosíthatja a maximális hibákat a megadott időszakértékben :

Válassza a Szerepkörök lehetőséget a navigációs panelen.
A Szerepkörök csoportban kattintson a jobb gombbal a fürtözött erőforrásra, és válassza a Tulajdonságok lehetőséget.
Válassza a Feladatátvétel lapot, és igény szerint növelje a megadott időszak maximális hibáit.

Resource limits

A virtuális gép vagy a lemez korlátai erőforrás-szűk keresztmetszetet okozhatnak, amely hatással van a fürt állapotára, és akadályozza az állapot-ellenőrzést. Ha erőforráskorlátokkal kapcsolatos problémákat tapasztal, vegye figyelembe az alábbiakat:

Győződjön meg arról, hogy az operációs rendszer, az illesztőprogramok és az SQL Server a legújabb buildekben vannak.
Az SQL Server optimalizálása Azure-beli virtuálisgép-környezetben az Azure-beli virtuális gépeken futó SQL Server teljesítményszabályainak megfelelően
A számítási feladat csökkentése vagy szétterjedése a kihasználtság csökkentése érdekében az erőforráskorlátok túllépése nélkül
Az SQL Server számítási feladatainak finomhangolása, ha van lehetőség, például
- Indexek hozzáadása/optimalizálása
- Szükség esetén és ha lehetséges, frissítse a statisztikákat a teljes vizsgálattal
- Az erőforrás-vezérlőhöz hasonló funkciók (az SQL Server 2014-től kezdve a nagyvállalati verzióig) használatával korlátozhatja az erőforrások kihasználtságát adott számítási feladatok, például biztonsági mentések vagy indexkarbantartás során.
Lépjen olyan virtuális gépre vagy lemezre, amely magasabb korlátokkal rendelkezik a számítási feladat igényeinek való megfeleléshez vagy túllépéséhez.

Networking

Ha lehetséges, helyezze üzembe az SQL Server virtuális gépeket több alhálózaton, hogy elkerülje az Azure Load Balancer vagy egy elosztott hálózati név (DNN) függőségét, hogy a forgalmat a HADR-megoldáshoz irányíthassa.

Kiszolgálónként (fürtcsomópontonként) egyetlen hálózati adapter használata. Az Azure-hálózatkezelés fizikai redundanciájú, ami további hálózati adaptereket szükségtelensé tesz egy Azure-beli virtuálisgép-vendégfürtön. A fürtérvényesítési jelentés figyelmezteti, hogy a csomópontok csak egyetlen hálózaton érhetők el. Ezt a figyelmeztetést figyelmen kívül hagyhatja az Azure-beli virtuális gépek vendég feladatátvételi fürtjeiben.

Egy adott virtuális gép sávszélességkorlátjai meg vannak osztva a hálózati adaptereken, és egy további hálózati adapter hozzáadása nem javítja a rendelkezésre állási csoport teljesítményét az Azure-beli virtuális gépeken futó SQL Server esetében. Ezért nincs szükség második hálózati adapter hozzáadására.

Az Azure nem RFC-kompatibilis DHCP-szolgáltatása bizonyos feladatátvevő fürtkonfigurációk létrehozását okozhatja. Ez a hiba azért fordul elő, mert a fürt hálózatának neve duplikált IP-címet kap, például ugyanazt az IP-címet, mint az egyik fürtcsomópont. Ez a probléma akkor merül fel, ha rendelkezésre állási csoportokat használ, amelyek a Windows feladatátvevő fürt funkciójától függnek.

Fontolja meg a kétcsomópontos fürt létrehozásakor és online állapotba hozásakor:

A fürt online állapotba kerül, majd a NODE1 dinamikusan hozzárendelt IP-címet kér a fürt hálózati nevéhez.
A DHCP-szolgáltatás nem ad meg más IP-címet, mint a NODE1 saját IP-címe, mivel a DHCP-szolgáltatás felismeri, hogy a kérés magáról a NODE1-ről származik.
A Windows azt észleli, hogy egy ismétlődő cím a NODE1-hez és a feladatátvevő fürt hálózati nevéhez is hozzá van rendelve, és az alapértelmezett fürtcsoport nem érhető el online állapotban.
Az alapértelmezett fürtcsoport a NODE2-be kerül. A NODE2 fürt IP-címeként kezeli a NODE1 IP-címét, és online állapotba hozza az alapértelmezett fürtcsoportot.
Amikor a NODE2 megpróbál kapcsolatot létesíteni a NODE1-vel, a NODE1-hez irányított csomagok soha nem hagyják el a NODE2-t, mert az feloldja a NODE1 IP-címét. A NODE2 nem tud kapcsolatot létesíteni a NODE1-zel, majd elveszíti a kvórumot, és leállítja a fürtöt.
A NODE1 csomagokat tud küldeni a NODE2-nek, de a NODE2 nem tud válaszolni. A NODE1 elveszíti a kvórumot, és leállítja a fürtöt.

Ezt a forgatókönyvet elkerülheti, ha egy nem használt statikus IP-címet rendel a fürthálózat nevéhez, hogy a fürthálózat nevét online állapotba hozza, és hozzáadja az IP-címet az Azure Load Balancerhez.

Ha az SQL Server adatbázismotorja, az Always On rendelkezésre állási csoport figyelője, a feladatátvevő fürtpéldány állapotadat-mintavétele, az adatbázis tükrözési végpontja, a fürtmag IP-erőforrása vagy bármely más SQL-erőforrás úgy van konfigurálva, hogy 49 152 és 65 536 közötti portot használjon (a TCP/IP alapértelmezett dinamikus porttartománya), adjon hozzá kivételt az egyes portokhoz. Ez megakadályozza, hogy más rendszerfolyamatok dinamikusan hozzárendelve legyenek ugyanahhoz a porthoz. Az alábbi példa egy kizárást hoz létre az 59999-s porton:

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Fontos konfigurálni a portkivételt, ha a port nincs használatban, ellenkező esetben a parancs a következő üzenettel meghiúsul: "A folyamat nem fér hozzá a fájlhoz, mert egy másik folyamat használja."

A kizárások helyes konfigurálásához használja a következő parancsot: netsh int ipv4 show excludedportrange tcp.

A rendelkezésre állási csoport szerepkör IP-mintavételi portjának kizárásának meg kell akadályoznia az olyan eseményeket, mint például az eseményazonosító: 1069 10048 állapotú. Ez az esemény a Windows feladatátvevő fürt eseményeiben látható a következő üzenettel:

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Ezt okozhatja egy belső folyamat, amely ugyanazt a portot használja, mint a mintavételi port. Ne feledje, hogy a mintavételi port egy háttérkészlet-példány állapotának ellenőrzésére szolgál az Azure Load Balancerből.
Ha az állapotadat-mintavétel nem kap választ egy háttérpéldánytól, akkor a rendszer nem küld új kapcsolatokat a háttérpéldánynak , amíg az állapotadat-mintavétel ismét sikeres nem lesz.

Ismert problémák

Tekintse át a megoldásokat néhány általánosan ismert probléma és hiba esetén.

Az erőforrás-versengés (különösen az IO) feladatátvételt okoz

A virtuális gép I/O- vagy CPU-kapacitásának kimerítése a rendelkezésre állási csoport feladatátvételét okozhatja. A feladatátvétel előtt közvetlenül a feladatátvétel előtt előforduló versengés azonosítása a legmegbízhatóbb módszer az automatikus feladatátvételt okozó adatok azonosítására. Az Azure-beli virtuális gépek monitorozása a tároló I/O-kihasználtsági metrikáinak megtekintéséhez a virtuális gép vagy a lemezszintű késés megértéséhez.

Kövesse az alábbi lépéseket az Azure-beli virtuális gépek teljes I/O-kimerülési eseményének áttekintéséhez:

Keresse meg a virtuális gépet az Azure Portalon – nem az SQL virtuális gépeken.
A Metrikák lap megnyitásához válassza a Figyelés területen a Metrikák lehetőséget.
Válassza a Helyi idő lehetőséget a kívánt időtartomány és az időzóna megadásához a virtuális gép helyi vagy UTC/GMT értékével.
Válassza a Metrika hozzáadása lehetőséget a következő két metrika hozzáadásához a gráf megtekintéséhez:
- A virtuális gép gyorsítótárazott sávszélességének felhasznált százalékos aránya
- VM nem gyorsítótárazott sávszélességének felhasznált százaléka

Screenshot of the Metrics page in the Azure portal.

Az Azure VM HostEvents feladatátvételt okoz

Lehetséges, hogy egy Azure-beli virtuális gép HostEventje a rendelkezésre állási csoport feladatátvételét okozza. Ha úgy véli, hogy egy Azure-beli virtuális gép hostEventje feladatátvételt okozott, ellenőrizheti az Azure Monitor tevékenységnaplót és az Azure-beli virtuális gépek erőforrás-állapotának áttekintését.

Az Azure Monitor tevékenységnaplója egy platformnapló az Azure-ban, amely betekintést nyújt az előfizetési szintű eseményekbe. A tevékenységnapló olyan információkat tartalmaz, mint például egy erőforrás módosítása vagy egy virtuális gép indítása. Megtekintheti a tevékenységnaplót az Azure Portalon, vagy beolvashat bejegyzéseket a PowerShell-lel és az Azure CLI-vel.

Az Azure Monitor tevékenységnaplójának ellenőrzéséhez kövesse az alábbi lépéseket:

Navigálás a virtuális gépre az Azure Portalon
Tevékenységnapló kiválasztása a Virtuális gép panelen
Válassza az Időkeret lehetőséget, majd válassza ki azt az időkeretet, amikor a rendelkezésre állási csoport feladatátvételt végzett. Válassza az Alkalmaz lehetőséget.

Ha az Azure-nak további információi vannak a platform által kezdeményezett elérhetetlenség kiváltó okáról, az adatok a kezdeti elérhetetlenség után legfeljebb 72 órával közzétehetők az Azure-beli virtuális gép – Resource Health áttekintési oldalon. This information is only available for virtual machines at this time.

Navigálás a virtuális gépre az Azure Portalon
Válassza a Resource Health (Erőforrás állapota ) lehetőséget az Állapot panelen.

Screenshot of the Resource Health page in the Azure portal.

Ezen a lapon állapotesemények alapján is konfigurálhat riasztásokat.

A fürtcsomópont el lett távolítva a tagságból

Ha a Windows-fürt szívverési és küszöbérték-beállításai túl agresszívak a környezethez, a rendszeresemény-naplóban gyakran jelenhet meg a következő üzenet.

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

További információkért tekintse át az 1135-ös eseményazonosítóval kapcsolatos fürtproblémák elhárítását.

Lejárt a bérlet/ A bérlet már nem érvényes

Ha a monitorozás túl agresszív a környezet számára, gyakori rendelkezésre állási csoport vagy FCI-újraindítások, hibák vagy feladatátvételek jelenhetnek meg. A rendelkezésre állási csoportok esetében a következő üzenetek is megjelenhetnek az SQL Server hibanaplójában:

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Kapcsolat időkorlátja

Ha a munkamenet időtúllépése túl agresszív a rendelkezésre állási csoport környezetéhez, gyakran a következő üzenetek jelenhetnek meg:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

A csoport nem működik át

Ha a megadott időszak értékének maximális hibái túl alacsonyak, és átmeneti problémák miatt időszakos hibákat tapasztal, a rendelkezésre állási csoport sikertelen állapotba kerülhet. Növelje ezt az értéket az átmenetibb hibák elviseléséhez.

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

1196-os esemény – A hálózati név erőforrása nem tudta regisztrálni a társított DNS-nevet

Ellenőrizze az egyes fürtcsomópontok NIC-beállításait, és gondoskodjon róla, hogy ne legyenek külső DNS-rekordok
Gondoskodjon róla, hogy a fürt A rekordja megtalálható legyen a belső DNS-kiszolgálókon. Ha nem létezik, hozzon létre manuálisan egy új A rekordot a DNS-kiszolgálón a Fürt hozzáférés-vezérlése objektumhoz, és jelölje be azt a beállítást, hogy bármely hitelesített felhasználó frissítheti azokat a DNS-rekordokat, amelyek azonos tulajdonosnévvel rendelkeznek.
Állítsa offline állapotba a „Fürt neve” erőforrást az IP-erőforrással, és javítsa ki.

157. esemény – A lemezt meglepték.

Ez akkor fordulhat elő, ha az AutomaticClusteringEnabled tárhelytulajdonság True értékre van beállítva egy rendelkezésreállási csoport környezete esetében. Módosítsa a következőre: False. A lemez alaphelyzetbe állítását vagy váratlan eltávolítását egy ellenőrzési jelentés tárterületi beállítással való futtatása is kiválthatja. A tárolórendszer szabályozása szintén okozhatja a lemez váratlan eltávolítását.

1206-os esemény – A fürt hálózatinév-erőforrása nem hozható online állapotba.

Az erőforráshoz társított számítógép-objektum nem frissíthető a tartományban. Győződjön meg arról, hogy rendelkezik a megfelelő engedélyekkel a tartományhoz

Windows-fürtözési hibák

Ha nincs megnyitva a fürtszolgáltatás portja a kommunikációhoz, problémák léphetnek fel a Windows feladatátvevő fürt vagy annak kapcsolatának beállítása során.

Ha Windows Server 2019-en van, és nem látja a Windows-fürt IP-címét, konfigurálta az elosztott hálózat nevét, amely csak az SQL Server 2019-ben támogatott. Ha az SQL Server korábbi verziójával rendelkezik, akkor eltávolíthatja és újból létrehozhatja a fürtöt a hálózatnév használatával.

Tekintse át a Windows feladatátvételi fürtszolgáltatás egyéb hibáit és megoldásait itt

Következő lépések

To learn more, see: