Sdílet prostřednictvím

Osvědčené postupy pro konfiguraci HADR (SQL Server na virtuálních počítačích Azure)

Platí pro:SQL Server na virtuálním počítači Azure

Windows Server Failover Cluster se používá pro vysokou dostupnost a zotavení po havárii (HADR) s SQL Serverem na Azure virtuálních počítačích (VMs).

Tento článek obsahuje osvědčené postupy konfigurace clusteru pro instance clusteru s podporou přepnutí služeb při selhání (FCIs) a skupiny dostupnosti, pokud je používáte se SQL Serverem na virtuálních počítačích Azure.

Další informace najdete v dalších článcích v této sérii: kontrolní seznam, velikost virtuálního počítače, úložiště, zabezpečení, konfigurace HADR, shromažďování standardních hodnot.

Kontrolní seznam

V následujícím kontrolním seznamu najdete stručný přehled osvědčených postupů HADR, které zbývající část článku podrobněji popisuje.

Funkce vysoké dostupnosti a zotavení po havárii (HADR), jako je skupina dostupnosti Always On a instance clusteru s podporou převzetí služeb při selhání, závisí na základní technologii Windows Server Failover Clusteru. Projděte si osvědčené postupy pro úpravu nastavení HADR, abyste mohli lépe podporovat cloudové prostředí.

Pro váš cluster s Windows zvažte tyto osvědčené postupy:

  • Nasaďte virtuální počítače s SQL Serverem do několika podsítí, kdykoli je to možné, abyste se vyhnuli závislosti na Azure Load Balanceru nebo názvu distribuované sítě (DNN) pro směrování provozu do vašeho řešení HADR.
  • Změňte cluster na méně agresivní parametry, abyste se vyhnuli neočekávaným výpadkům v přechodných selháních sítě nebo údržbě platformy Azure. Další informace najdete v části Nastavení heartbeat a prahových hodnot. Pro Windows Server 2012 a novější použijte následující doporučené hodnoty:
    • SameSubnetDelay: 1 sekunda
    • SameSubnetThreshold: 40 heartbeatů
    • CrossSubnetDelay: 1 sekunda
    • CrossSubnetThreshold: 40 pulzy
  • Umístěte virtuální počítače do skupiny dostupnosti nebo do různých zón dostupnosti. Další informace najdete v tématu Nastavení dostupnosti virtuálního počítače.
  • Použijte jednu síťovou kartu pro každý uzel clusteru.
  • Nakonfigurujte hlasování kvóra clusteru tak, aby používalo 3 nebo více liché počty hlasů. Nepřiřazujte hlasy do DR oblastí.
  • Pečlivě monitorujte limity prostředků, abyste se vyhnuli neočekávaným restartům nebo přepnutí kvůli omezeným prostředkům.
    • Ujistěte se, že operační systém, ovladače a SQL Server mají nejnovější sestavení.
    • Optimalizujte výkon SQL Serveru na virtuálních počítačích Azure. Další informace najdete v dalších částech tohoto článku.
    • Omezte nebo rozložte úlohu, abyste se vyhnuli omezením prostředků.
    • Přesuňte se na virtuální počítač nebo disk s vyššími limity, abyste se vyhnuli omezením.

Pro vaši skupinu dostupnosti SQL Serveru nebo instanci vysokodostupnostního clusteru zvažte tyto osvědčené postupy:

  • Pokud dochází k častým neočekávaným selháním, postupujte podle osvědčených postupů pro výkon popsaných ve zbývající části tohoto článku.
  • Pokud optimalizace výkonu virtuálního počítače s SQL Serverem nevyřeší neočekávané přepnutí při selhání, zvažte uvolnění monitorování pro skupinu dostupnosti nebo instanci clusteru s podporou převzetí služeb. To však nemusí řešit základní zdroj problému a mohl by maskovat příznaky snížením pravděpodobnosti selhání. Možná budete muset prozkoumat a vyřešit původní příčinu. Pro Windows Server 2012 nebo novější použijte následující doporučené hodnoty:
    • Časový limit zapůjčení: Tuto rovnici použijte k výpočtu maximální hodnoty časového limitu zapůjčení:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Začněte 40 sekundami. Pokud používáte uvolněné hodnoty SameSubnetThreshold a SameSubnetDelay doporučené dříve, nepřesáhejte pro časový limit zapůjčení 80 sekund.
    • Maximální počet selhání v zadaném období: Nastavte tuto hodnotu na hodnotu 6.
  • Při použití názvu virtuální sítě (VNN) a Azure Load Balanceru pro připojení k řešení HADR zadejte MultiSubnetFailover = true v připojovací řetězec, i když váš cluster pokrývá pouze jednu podsíť.
    • Pokud klient nepodporuje MultiSubnetFailover = True , možná budete muset nastavit RegisterAllProvidersIP = 0 a HostRecordTTL = 300 uložit přihlašovací údaje klienta do mezipaměti po kratší dobu. To ale může způsobit další dotazy na server DNS.
  • Pokud se chcete připojit k řešení HADR pomocí názvu distribuované sítě (DNN), zvažte následující:
    • Musíte použít klientský ovladač, který podporuje MultiSubnetFailover = True, a tento parametr musí být v připojovacím řetězci.
    • Při připojování ke sluchátku DNN pro skupinu dostupnosti použijte jedinečný port DNN v připojovacím řetězci.
  • Použijte připojovací řetězec pro zrcadlení databáze pro základní skupinu dostupnosti k obejití potřeby nástroje pro vyrovnávání zatížení nebo sítě DNN.
  • Před nasazením řešení s vysokou dostupností ověřte velikost sektoru virtuálních pevných disků, abyste se vyhnuli nesprávnému zarovnání vstupně-výstupních operací. Další informace najdete v KB3009974 .
  • Pokud je databázový stroj SQL Serveru, poslech skupiny dostupnosti Always On nebo sonda stavu instance clusteru při selhání nakonfigurována tak, aby používala port mezi 49 152 a 65 536 (výchozí dynamický rozsah portů pro TCP/IP), přidejte pro každý port vyloučení. Tím zabráníte dynamickému přiřazování stejného portu jiným systémům. Následující příklad vytvoří vyloučení pro port 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Pokud chcete porovnat kontrolní seznam HADR s dalšími osvědčenými postupy, podívejte se na úplný kontrolní seznam osvědčených postupů pro výkon.

Nastavení dostupnosti virtuálního počítače

Pokud chcete snížit dopad výpadků, zvažte následující nastavení nejlepší dostupnosti virtuálního počítače:

  • Používejte skupiny pro blízké umístění společně se zrychleným síťovým připojením pro nejnižší latenci.
  • Umístěte uzly clusteru virtuálních počítačů do samostatných zón dostupnosti, aby se chránily před selháním na úrovni datacentra nebo v jedné skupině dostupnosti pro zajištění redundance s nižší latencí v rámci stejného datacentra.
  • Pro virtuální počítače ve skupině dostupnosti používejte disky s operačním systémem a datovými disky spravovanými premium.
  • Nakonfigurujte každou aplikační vrstvu do samostatných skupin dostupnosti.

Quorum

I když cluster se dvěma uzly může fungovat bez quorum prostředku, zákazníci jsou povinni použít quorum prostředek, aby měli podporu produkčního prostředí. Ověření clusteru neprojde žádným clusterem bez prostředku kvora.

Z technického hlediska může cluster se třemi uzly přežít ztrátu jednoho uzlu (na dva uzly) bez zdroje kvora, ale po snížení počtu uzlů v clusteru na dva, pokud dojde ke ztrátě dalšího uzlu nebo selhání komunikace, hrozí, že clusterované prostředky přejdou do režimu offline, aby se zabránilo rozštěpení clusteru. Konfigurace prostředku kvora umožňuje clusteru zůstat v provozu, i když je online pouze jeden uzel.

Diskový svědek je nejodolnější možností kvora, ale pokud chcete použít diskový svědek na SQL Serveru na virtuálním počítači Azure, musíte použít Azure Shared Disk, což ukládá určitá omezení v řešení vysoce dostupnosti. Pokud tedy konfigurujete instanci clusteru s podporou převzetí služeb při selhání se sdílenými disky Azure, použijte diskový svědek, jinak použijte cloudového svědka vždy, když je to možné.

Následující tabulka uvádí možnosti kvora dostupné pro SQL Server na virtuálních počítačích Azure:

Cloudový svědek Diskový svědek Úložiště sdílené složky (File Share Witness)
Podporovaný operační systém Windows Server 2016+ Vše Vše
  • Cloudový svědek je ideální pro nasazení ve více lokalitách, zónách a regionech. Pokud nepoužíváte řešení clusteru se sdíleným úložištěm, použijte cloudového svědka, kdykoli je to možné.
  • Diskový svědek je nejodolnější možností kvora a je preferovanou volbou pro každý cluster, který používá sdílené disky Azure (nebo jakékoli řešení sdíleného disku, jako je sdílené rozhraní SCSI, iSCSI nebo fibre channel SAN). Clusterovaný sdílený svazek nelze použít jako diskový svědek.
  • Sdílená složka svědka je vhodná pro případy, kdy diskový svědek a cloudový svědek nejsou dostupné možnosti.

Pokud chcete začít, viz Konfigurace kvora clusteru.

Hlasování kvora

Je možné změnit hlasování o kvóru uzlu, který se účastní clusteru s podporou při selhání služby Windows Server.

Při úpravě nastavení hlasu uzlu postupujte podle těchto pokynů:

Pravidla hlasování kvorum
Začněte s každým uzlem, který nemá ve výchozím nastavení žádné hlasy. Každý uzel by měl mít pouze hlas s explicitním odůvodněním.
Povolte hlasy pro uzly clusteru, které hostují primární repliku dostupnostní skupiny, nebo pro preferované vlastníky instance převzetí služeb při selhání clusteru.
Povolte hlasování pro vlastníky automatického převzetí při selhání. Každý uzel, který může být hostitelem primární repliky nebo FCI v případě automatického failoveru, by měl mít hlas.
Pokud má skupina dostupnosti více než jednu sekundární repliku, povolte hlasy jenom pro repliky, které mají automatické přepnutí.
Zakažte hlasy pro uzly, které jsou v sekundárních lokalitách zotavení po havárii. Uzly v sekundárních lokalitách by neměly přispívat k rozhodnutí o offline režimu clusteru, pokud není nic špatného s primární lokalitou.
Mějte lichý počet hlasů, minimálně tři hlasy kvorum. V případě potřeby přidejte svědka kvora pro další hlas v clusteru se dvěma uzly.
Přehodnoťte hlasy po selhání. Nechcete přepnout do konfigurace clusteru, která nepodporuje zdravý kvorum.

Připojení

Pokud chcete odpovídat místnímu prostředí pro připojení k naslouchacímu procesu skupiny dostupnosti nebo instanci clusteru s podporou převzetí služeb při selhání, nasaďte virtuální počítače s SQL Serverem do několika podsítí ve stejné virtuální síti. Mít několik podsítí odstraňuje potřebu další závislosti na Azure Load Balanceru nebo distribuovaném názvu sítě pro přenášení provozu k vašemu posluchači.

Pokud chcete zjednodušit řešení HADR, nasaďte virtuální počítače s SQL Serverem do několika podsítí, kdykoli je to možné. Další informace najdete v tématu Skupina dostupnosti s více podsítěmi a FCI s více podsítěmi.

Pokud jsou virtuální počítače s SQL Serverem v jedné podsíti, je možné nakonfigurovat buď virtuální název sítě (VNN) a Azure Load Balancer, nebo distribuovaný název sítě (DNN), a to jak pro instance clusteru s podporou převzetí služeb při selhání, tak i pro naslouchací procesy skupiny dostupnosti.

Název distribuované sítě je doporučenou možností připojení, pokud je k dispozici:

  • Řešení end-to-end je robustnější, protože už nemusíte udržovat zdroj prostředku pro vyrovnávání zatížení.
  • Eliminování sond nástroje pro vyrovnávání zatížení minimalizuje dobu trvání převzetí služeb při selhání.
  • Systém DNN zjednodušuje zřizování a správu instance clusteru s podporou převzetí služeb při selhání nebo listeneru skupiny dostupnosti pro SQL Server na virtuálních počítačích Azure.

Berte v úvahu následující omezení:

Další informace najdete v přehledu clusteru převzetí služeb při selhání Windows Server.

Informace o konfiguraci připojení najdete v následujících článcích:

Většina funkcí SQL Serveru funguje transparentně s FCI a skupinami dostupnosti při používání sítě DNN, ale existují určité funkce, které mohou vyžadovat zvláštní pozornost. Další informace naleznete v tématech interoperabilita FCI a DNN a interoperabilita skupin dostupnosti a DNN.

Návod

Nastavte parametr MultiSubnetFailover = true v připojovacím řetězci i pro HADR řešení, která zasahují pouze do jedné podsítě, a tím podpořila budoucí rozšíření přes více podsítí, aniž by bylo nutné aktualizovat připojovací řetězec.

Prezenčních signálů a prahových hodnot

Změňte nastavení heartbeat signálu a prahových hodnot clusteru k uvolněným nastavením. Výchozí nastavení heartbeatů a prahových hodnot clusteru jsou navržena pro vysoce vyladěné místní sítě a neberou v úvahu možnost zvýšené latence v cloudovém prostředí. Síť srdečního tepu se udržuje pomocí UDP 3343, což je tradičně méně spolehlivé než TCP a náchylnější k neúplným přenosům.

Proto při spouštění uzlů clusteru pro SQL Server na virtuálních počítačích Azure s vysokou dostupností změňte nastavení clusteru na uvolněnější stav monitorování, abyste se vyhnuli přechodným selháním kvůli zvýšené možnosti latence sítě nebo selhání, údržby Azure nebo dosažení kritických bodů prostředků.

Nastavení zpoždění a prahové hodnoty mají kumulativní účinek na celkovou detekci stavu. Například nastavení CrossSubnetDelay pro odesílání heartbeat každé 2 sekundy a nastavení CrossSubnetThreshold na 10 zmeškaných heartbeatů před zahájením obnovení znamená, že cluster může mít celkovou síťovou toleranci 20 sekund, než bude provedena akce obnovení. Obecně platí, že se upřednostňují časté heartbeat signály, ale s vyššími prahovými hodnotami.

Pokud chcete zajistit obnovení během legitimních výpadků a současně zajistit větší odolnost vůči přechodným problémům, uvolněte nastavení zpoždění a prahové hodnoty na doporučené hodnoty popsané v následující tabulce:

Nastavení Windows Server 2012 nebo novější Windows Server 2008 R2
ZpožděníStejnéPodsítě 1 sekunda 2 sekundy
Prahová hodnota pro stejnou podsíť 40 tepů srdce 10 tepů (max)
Zpoždění mezi podsítěmi 1 sekunda 2 sekundy
HranicePropojeníMezisubnety 40 tepů srdce 20 srdečních tepů (max)

Pomocí PowerShellu můžete změnit parametry clusteru:

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

Pomocí PowerShellu ověřte změny:

get-cluster | fl *subnet*

Zvažte použití těchto zdrojů:

  • Tato změna je okamžitá, restartování clusteru nebo jakýchkoli prostředků se nevyžaduje.
  • Stejné hodnoty podsítě by neměly být větší než hodnoty napříč podsítěmi.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay <= CrossSubnetDelay

Zvolte uvolněné hodnoty na základě toho, kolik času výpadku je tolerovatelné a jak dlouho by se mělo provést nápravná akce v závislosti na vaší aplikaci, obchodních potřebách a vašem prostředí. Pokud nemůžete překročit výchozí hodnoty Windows Serveru 2019, zkuste je alespoň spárovat, pokud je to možné:

Následující tabulka obsahuje podrobnosti o výchozích hodnotách:

Nastavení Windows Server 2019 Windows Server 2016 Windows Server 2008 – 2012 R2
ZpožděníStejnéPodsítě 1 sekunda 1 sekunda 1 sekunda
Prahová hodnota pro stejnou podsíť 20 tepů 10 srdečních tepů 5 srdečních tepů
Zpoždění mezi podsítěmi 1 sekunda 1 sekunda 1 sekunda
HranicePropojeníMezisubnety 20 tepů 10 srdečních tepů 5 srdečních tepů

Další informace najdete v tématu Ladění prahových hodnot sítě clusteru s podporou převzetí služeb při selhání.

Uvolněné monitorování

Pokud ladění nastavení prezenčních signálů a prahových hodnot clusteru podle doporučení nezajišťuje dostatečnou toleranci a stále dochází k převzetí služeb při selhání kvůli přechodným problémům namísto skutečných výpadků, můžete nakonfigurovat monitorování skupiny dostupnosti nebo FCI tak, aby bylo méně přísné. V některých scénářích může být užitečné dočasně uvolnit monitorování po určitou dobu vzhledem k úrovni aktivity. Můžete například chtít uvolnit monitorování, když provádíte úlohy náročné na vstupně-výstupní operace, jako jsou zálohy databází, údržba indexů, DBCC CHECKDB atd. Po dokončení aktivity nastavte monitorování na méně uvolněné hodnoty.

Varování

Změna těchto nastavení může zamaskovat základní problém a měla by se použít jako dočasné řešení pro snížení, nikoli odstranění pravděpodobnosti selhání. Základní problémy by měly být stále prošetřeny a vyřešeny.

Začněte zvýšením následujících parametrů z výchozích hodnot pro uvolněné monitorování a podle potřeby upravte:

Parametr Výchozí hodnota Uvolněná hodnota Popis
Časový limit kontroly stavu 30000 60000 Určuje stav primární repliky nebo uzlu. Knihovna DLL sp_server_diagnostics prostředků clusteru vrátí výsledky v intervalu, který se rovná 1/3 prahové hodnotě časového limitu kontroly stavu. Pokud je sp_server_diagnostics pomalé nebo nevrací informace, knihovna DLL prostředků počká celý interval prahové hodnoty časového limitu kontroly stavu, než určí, že prostředek nereaguje. Pokud je to nakonfigurováno, automaticky spustí převzetí služby při selhání.
Úroveň podmínky selhání 3 2 Podmínky, které aktivují automatický failover. Existuje pět úrovní stavu selhání, které se liší od nejnižší omezující úrovně (úroveň 1) po nejvíce omezující (úroveň pět).

Pomocí jazyka Transact-SQL (T-SQL) můžete upravit kontrolu stavu a podmínky selhání pro skupiny AG i FCI.

Pro skupiny dostupnosti:

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

Pro instance clusteru pro převzetí služeb při selhání:

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

Specifické pro skupiny dostupnosti, začněte s následujícími doporučenými parametry a podle potřeby je upravte.

Parametr Výchozí hodnota Uvolněná hodnota Popis
Časový limit zapůjčení 20 000 40000 Zabraňuje rozdělení mozku.
Vypršení platnosti relace 10 000 20 000 Kontroluje problémy s komunikací mezi replikami. Časový limit relace je vlastnost repliky, která určuje, jak dlouho (v sekundách) replika dostupnosti čeká na odpověď ping z připojené repliky, než bude spojení považováno za selhalé. Ve výchozím nastavení replika čeká 10 sekund na odpověď ping. Tato vlastnost repliky se vztahuje pouze na připojení mezi danou sekundární replikou a primární replikou skupiny dostupnosti.
Maximální počet selhání v zadaném období 2 6 Používá se k zabránění nekontrolovanému přesunu clusterovaného prostředku v rámci selhání více uzlů. Příliš nízká hodnota může vést k tomu, že skupina dostupnosti je ve stavu selhání. Zvyšte hodnotu, abyste zabránili krátkým přerušením problémů s výkonem, protože příliš nízká hodnota může vést k tomu, že Skupina dostupnosti je ve stavu selhání.

Před provedením jakýchkoli změn zvažte následující:

  • Nesnižujte žádné hodnoty časového limitu pod jejich výchozí hodnoty.
  • Pomocí této rovnice můžete vypočítat maximální hodnotu časového limitu zapůjčení: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Začněte 40 sekundami. Pokud používáte uvolněné hodnoty SameSubnetThreshold a SameSubnetDelay doporučené dříve, nepřesáhejte pro časový limit zapůjčení 80 sekund.
  • U replik se synchronním potvrzením může změnou časového limitu relace na vyšší hodnotu dojít ke zvýšení čekání na HADR_sync_commit.

Časový limit zapůjčení

Pomocí Správce clusteru převzetí služeb při selhání můžete upravit nastavení časového limitu pronájmu pro vaši skupinu dostupnosti. Podrobné kroky najdete v dokumentaci ke kontrole stavu zapůjčení skupiny dostupnosti SQL Serveru.

Vypršení platnosti relace

Pomocí jazyka Transact-SQL (T-SQL) upravte časový limit relace pro skupinu vysoké dostupnosti:

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

Maximální počet selhání v zadaném období

Ke změně hodnoty maximální počet selhání v zadaném období použijte Správce clusteru pro převzetí služeb při selhání:

  1. V navigačním podokně vyberte Role .
  2. V části Role klikněte pravým tlačítkem myši na clusterovaný prostředek a zvolte Vlastnosti.
  3. Vyberte kartu Převzetí služeb při selhání a zvyšte hodnotu Maximální počet selhání v určeném období podle potřeby.

Omezení prostředků

Omezení virtuálních počítačů nebo disků mohou vést k úzkým místům v prostředcích, které ovlivňují stav clusteru a brání provádění kontroly stavu. Pokud máte problémy s limity prostředků, zvažte následující možnosti:

  • K identifikaci problémů s výkonem disku, které můžou způsobit převzetí služeb při selhání, použijte analýzu vstupně-výstupních operací na webu Azure Portal.
  • Ujistěte se, že operační systém, ovladače a SQL Server mají nejnovější sestavení.
  • Optimalizace SQL Serveru na virtuálním počítači Azure, jak je popsáno v pokynech k výkonu SQL Serveru na virtuálních počítačích Azure
  • Používání
  • Snižte nebo rozložte úlohy za účelem snížení využití bez překročení limitů prostředků.
  • Pokud existuje nějaká příležitost, vylaďte úlohu SQL Serveru, například
    • Přidejte nebo optimalizujte indexy.
    • V případě potřeby aktualizujte statistiky a pokud je to možné, proveďte úplný sken.
    • Funkce, jako je správce prostředků (počínaje SQL Serverem 2014, jenom edice Enterprise), použijte k omezení využití prostředků během konkrétních úloh, jako jsou zálohy nebo údržba indexů.
  • Přejděte na virtuální počítač nebo disk s vyššími limity, které splňují nebo překračují požadavky vaší úlohy.

Sítě

Nasaďte virtuální počítače s SQL Serverem do několika podsítí, kdykoli je to možné, abyste se vyhnuli závislosti na Azure Load Balanceru nebo názvu distribuované sítě (DNN) pro směrování provozu do vašeho řešení HADR.

Použijte jednu síťovou kartu na každý server (uzel clusteru). Sítě Azure mají fyzickou redundanci, což znamená, že v clusteru hostů virtuálních počítačů Azure nejsou potřebné další síťové karty. Sestava ověření clusteru vás upozorní, že uzly jsou dosažitelné pouze na jediné síti. Toto upozornění můžete ignorovat u clusterů pro převzetí služeb při selhání hosta ve virtuálních počítačích Azure.

Omezení šířky pásma pro konkrétní virtuální počítač se sdílí mezi síťovými kartami a přidáním další síťové karty nezlepšíte výkon skupiny dostupnosti pro SQL Server na virtuálních počítačích Azure. Proto není potřeba přidat druhou síťovou kartu.

Nestandardní DHCP služba v Azure, která není kompatibilní s dokumentem RFC, může způsobit selhání při vytváření určitých konfigurací clusteru pro převzetí služeb při selhání. K této chybě dochází, protože název sítě clusteru má přiřazenou duplicitní IP adresu, například stejnou IP adresu jako jeden z uzlů clusteru. Jedná se o problém při použití skupin dostupnosti, které závisí na funkci clusteru pro podporu převzetí služeb při selhání systému Windows.

Představte si scénář vytvoření clusteru se dvěma uzly a přeneste ho do režimu online:

  1. Cluster se spustí a uzel NODE1 požádá o dynamicky přidělenou IP adresu pro síťový název clusteru.
  2. Služba DHCP neposkytuje žádnou IP adresu jinou než vlastní IP adresu NODE1, protože služba DHCP rozpozná, že požadavek pochází ze samotného uzlu 1.
  3. Windows zjistí, že duplicitní adresa je přiřazena jak k NODE1, tak k názvu sítě převzetí služeb při selhání, a výchozí skupina klastru se nepodaří aktivovat.
  4. Výchozí skupina clusteru se přesune na UZEL2. NODE2 považuje IP adresu NODE1 za IP adresu clusteru a přenese výchozí skupinu clusteru do režimu online.
  5. Když se node2 pokusí navázat připojení k uzlu 1, pakety směrované na NODE1 nikdy neopustí NODE2, protože přeloží IP adresu NODE1 na sebe. NODE2 nemůže navázat připojení k uzlu NODE1 a pak ztratí kvorum a vypne cluster.
  6. NODE1 může posílat pakety do NODE2, ale NODE2 nemůže odpovědět. UZEL1 ztratil kvorum a vypnul klastr.

Tomuto scénáři se můžete vyhnout přiřazením nepoužívané statické IP adresy k názvu sítě clusteru, aby se název sítě clusteru přenesl do režimu online a přidal IP adresu do Azure Load Balanceru.

Konfigurace portu sondy

Pokud používáte Azure Load Balancer k podpoře prostředku názvu virtuální sítě (VNN), musíte cluster nakonfigurovat tak, aby odpovídal na požadavky sondy stavu pro posluchače skupiny dostupnosti Always On nebo instanci clusteru s podporou převzetí služeb při selhání. Pokud sonda stavu nezískne odpověď z instance back-endu, nebudou do této instance back-endu odeslána žádná nová připojení, dokud sonda stavu nebude úspěšná.

Konfigurace vyloučení portů

Pokud používáte prostředek virtuální sítě (VNN) s Nástrojem pro vyrovnávání zatížení Azure, při použití portu sondy stavu mezi 49 152 a 65 536 ( výchozí dynamický rozsah portů pro TCP/IP), musíte nakonfigurovat vyloučení portů pro naslouchací proces skupiny dostupnosti AlwaysOn nebo instanci clusteru s podporou převzetí služeb při selhání.

Konfigurace vyloučení portů zabraňuje událostem, jako je ID události: 1069 se stavem 10048, které může být způsobeno interním procesem využívajícím port definovaný jako port sondy.

Následující příklad ukazuje ID události 1069 se stavem 10048 v protokolech clusteru:

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**

Stav 10048 se stane, pokud se aplikace pokusí vytvořit vazbu soketu na IP adresu nebo port, který již byl použit pro existující soket.

Známé problémy

Projděte si řešení některých běžně známých problémů a chyb.

Konflikt prostředků (zejména u vstupně-výstupních operací) způsobuje selhání.

Vyčerpání kapacity V/V nebo procesoru virtuálního počítače může způsobit přepnutí vaší skupiny dostupnosti. Identifikace kolizí, ke které dochází přímo před převzetím služeb při selhání, je nejspolehlivější způsob, jak zjistit, co způsobuje automatické převzetí služeb při selhání.

Použití vstupně-výstupní analýzy

K identifikaci problémů s výkonem disku, které můžou způsobit převzetí služeb při selhání, použijte analýzu vstupně-výstupních operací na webu Azure Portal.

Monitorování s využitím metrik vstupně-výstupních operací úložiště virtuálních počítačů

Monitorujte virtuální počítače Azure a podívejte se na metriky využití vstupně-výstupních operací úložiště, abyste porozuměli latenci na úrovni virtuálního počítače nebo disku.

Postupujte podle těchto kroků pro kontrolu události celkového vyčerpání IO virtuálního počítače Azure:

  1. Přejděte na svůj virtuální počítač v Azure portálu, ne na SQL virtuálních počítačích.

  2. Vyberte Metriky pod Monitorování pro otevření stránky Metriky.

  3. Vyberte Místní čas a určete časový rozsah, který vás zajímá, a časové pásmo, buď místní pro virtuální počítač, nebo UTC/GMT.

    Snímek obrazovky se stránkou Metriky na webu Azure Portal a výběrem změny časového rámce grafu

  4. Výběrem možnosti Přidat metriku přidejte následující dvě metriky, abyste viděli graf:

    • Procento spotřebované šířky pásma v mezipaměti virtuálního počítače
    • Procento šířky pásma mimo mezipaměť využité virtuálním počítačem

Snímek obrazovky se stránkou Metriky na webu Azure Portal

HostEvents Azure VM způsobí převzetí služeb při selhání.

Je možné, že hostEvent virtuálního počítače Azure způsobí převzetí služeb při selhání vaší skupiny dostupnosti. Pokud se domníváte, že Azure VM HostEvent způsobil převzetí služeb při selhání, můžete zkontrolovat protokol aktivit služby Azure Monitor a přehled služby Azure VM Resource Health.

Protokol aktivit služby Azure Monitor je protokol platformy v Azure, který poskytuje přehled o událostech na úrovni subskripce. Protokol aktivit obsahuje informace, jako je například změna prostředku nebo spuštění virtuálního počítače. Protokol aktivit můžete zobrazit na webu Azure Portal nebo načíst položky pomocí PowerShellu a Azure CLI.

Pokud chcete zkontrolovat protokol aktivit služby Azure Monitor, postupujte takto:

  1. Přechod na virtuální počítač na webu Azure Portal

  2. Výběr protokolu aktivit v podokně Virtuální počítač

  3. Vyberte Časový rozsah a pak zvolte časové období, kdy došlo k přepnutí vaší skupiny dostupnosti při selhání. Vyberte Použít.

    Snímek obrazovky webu Azure Portal zobrazující protokol aktivit

Pokud má Azure další informace o původní příčině nedostupnosti iniciované platformou, můžou se tyto informace publikovat na stránce přehledu služby Azure Resource Health až 72 hodin po počáteční nedostupnosti. Tyto informace jsou v současné době k dispozici jen pro virtuální počítače.

  1. Přechod na virtuální počítač na webu Azure Portal
  2. V podokně Stav vyberte Resource Health.

Snímek obrazovky se stránkou Resource Health na webu Azure Portal

Můžete také nakonfigurovat výstrahy na základě zdravotních událostí přímo z této stránky.

Uzel clusteru odebraný z členství

Pokud jsou nastavení heartbeat a prahových hodnot pro cluster Windows ve vašem prostředí příliš agresivní, může se v systémovém protokolu událostí často zobrazovat následující zpráva.

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.

Další informace najdete v tématu Řešení potíží s clusterem s ID události 1135.

Platnost zapůjčení vypršela / Zapůjčení už není platné.

Pokud je monitorování pro vaše prostředí příliš agresivní, může docházet k častým restartům skupiny dostupnosti nebo FCI, selháním nebo převzetí služeb při selhání. U skupin dostupnosti se navíc můžou v protokolu chyb SQL Serveru zobrazit následující zprávy:

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.

Časový limit připojení vypršel

Pokud je časový limit relace ve vašem prostředí skupiny dostupnosti příliš agresivní, můžou se často zobrazovat následující zprávy:

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.

Skupina nepřepíná při selhání

Pokud je maximální počet selhání v zadané hodnotě období příliš nízký a dochází k přerušovaným selháním kvůli přechodným problémům, může vaše skupina dostupnosti končit stavem selhání. Zvyšte tuto hodnotu, abyste tolerovali více přechodných selhání.

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

Událost 1196 – Prostředek názvu sítě selhal registrací přidruženého názvu DNS

  • Zkontrolujte nastavení síťových karet jednotlivých uzlů clusteru a ujistěte se, že neobsahují žádné externí záznamy DNS.
  • Ujistěte se, že na vašich interních serverech DNS existuje záznam A pro váš cluster. Pokud ne, vytvořte na serveru DNS ručně nový záznam A pro objekt řízení přístupu ke clusteru a zaškrtněte políčko Povolit všem ověřeným uživatelům aktualizovat záznamy DNS se stejným názvem vlastníka.
  • Převeďte prostředek "Cluster Name" s IP prostředkem do režimu offline a opravte ho.

Událost 157 – Disk byl neočekávaně odebrán.

K tomu může dojít v případě, že je pro prostředí AG nastavená vlastnost úložných prostor AutomaticClusteringEnabled na hodnotu True. Změňte ji na hodnotu False. Také spuštění ověřovací zprávy s možností úložiště může vyvolat událost resetování disku nebo neočekávaného odebrání. Událost neočekávaného odebrání disku může být také spuštěna jednotkou Throttling systému úložiště.

Událost 1206 – Prostředek názvu sítě clusteru nejde převést do režimu online.

Objekt počítače přidružený k prostředku nelze v doméně aktualizovat. Ujistěte se, že máte příslušná oprávnění k doméně.

Chyby clusteringu Windows

Při nastavování clusteru s podporou převzetí služeb při selhání systému Windows nebo jeho připojení může dojít k problémům, pokud nemáte otevřené porty služby clusteru pro komunikaci.

Pokud používáte Windows Server 2019 a nakonfigurovali jste název distribuované sítě, což je podporováno pouze na SQL Serveru 2019, nevidíte IP adresu clusteru Windows. Pokud máte starší verzi SQL Serveru, můžete cluster odebrat a vytvořit ho znovu s použitím názvu sítě.

Projděte si další události systémového protokolu služby Windows Failover Clustering a jejich řešení.

Další kroky

Další informace najdete v následujících tématech:

  • Last updated on