Cluster s podporou převzetí služeb při selhání Windows Serveru s SQL Serverem na virtuálních počítačích Azure

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

Tento článek popisuje rozdíly při použití funkce clusteru s podporou převzetí služeb při selhání s Windows Serverem na virtuálních počítačích Azure pro zajištění vysoké dostupnosti a zotavení po havárii (HADR), jako jsou skupiny dostupnosti AlwaysOn (AG) nebo instance clusteru s podporou převzetí služeb při selhání (FCI).

Další informace o samotné funkci Windows najdete v dokumentaci ke clusteru s podporou převzetí služeb při selhání systému Windows Server.

Přehled

Řešení vysoké dostupnosti SQL Serveru ve Windows, jako jsou skupiny dostupnosti AlwaysOn nebo instance clusteru s podporou převzetí služeb při selhání (FCI), závisí na základní službě clusteringu s podporou převzetí služeb při selhání Windows Serveru (WSFC).

Služba clusteru monitoruje síťová připojení a stav uzlů v clusteru. Toto monitorování je kromě kontrol stavu, které SQL Server provádí jako součást funkce instance clusteru s podporou převzetí služeb při selhání nebo skupiny dostupnosti. Pokud se služba clusteru nemůže spojit s uzlem nebo pokud je role skupiny dostupnosti nebo FCI v clusteru v pořádku, služba clusteru zahájí příslušné akce obnovení pro obnovení a přenese aplikace a služby do režimu online, a to buď na stejném nebo jiném uzlu v clusteru.

Monitorování stavu clusteru

Aby bylo možné zajistit vysokou dostupnost, musí cluster zajistit stav různých komponent, které tvoří clusterové řešení. Služba clusteru monitoruje stav clusteru na základě řady systémových a síťových parametrů, aby bylo možné detekovat selhání a reagovat na ně.

Nastavení prahové hodnoty pro deklarování selhání je důležité, aby bylo možné dosáhnout rovnováhy mezi okamžitou reakcí na selhání a vyhnout se nepravdivým selháním.

Monitorování se dá monitorovat dvěma strategiemi:

Monitorování	Popis
Agresivní	Poskytuje rychlou detekci selhání a obnovení pevných selhání, které přináší nejvyšší úroveň dostupnosti. Clusterová služba i SQL Server jsou méně zadržující přechodné selhání a v některých situacích můžou předčasně převzít služby při selhání prostředků, pokud dojde k přechodným výpadkům. Po zjištění selhání může nápravná akce, která následuje, trvat delší dobu.
Uvolněné	Poskytuje lepší detekci chyb s větší odolností vůči krátkým přechodným problémům se sítí. Vyhne se přechodným selháním, ale také představuje riziko zpoždění detekce skutečného selhání.

Agresivní nastavení v prostředí clusteru v cloudu můžou vést k předčasnému selhání a delším výpadkům, proto se pro clustery s podporou převzetí služeb při selhání na virtuálních počítačích Azure doporučuje uvolněná strategie monitorování. Pokud chcete upravit nastavení prahových hodnot, podívejte se na osvědčené postupy clusteru, kde najdete další podrobnosti.

Prezenčních signálů clusteru

Primární nastavení, která ovlivňují srdeční tep clusteru a detekci stavu mezi uzly:

Nastavení	Description
Zpoždění	Tím se definuje frekvence odesílání prezenčních signálů clusteru mezi uzly. Zpoždění je počet sekund před odesláním dalšího prezenčních signálu. V rámci stejného clusteru může existovat různá nastavení zpoždění nakonfigurovaná mezi uzly ve stejné podsíti a mezi uzly, které jsou v různých podsítích.
Mezní hodnota	Prahová hodnota je počet prezenčních signálů, které je možné zmeškat před provedením akce obnovení clusteru. V rámci stejného clusteru může být mezi uzly ve stejné podsíti nakonfigurovaná různá nastavení prahové hodnoty a mezi uzly, které jsou v různých podsítích.

Výchozí hodnoty těchto nastavení můžou být pro cloudová prostředí příliš nízké a můžou vést k zbytečným selháním kvůli přechodným problémům se sítí. Pokud chcete být odolnější, použijte uvolněné nastavení prahové hodnoty pro clustery s podporou převzetí služeb při selhání na virtuálních počítačích Azure. Další podrobnosti najdete v osvědčených postupech clusteru.

Kvora

I když cluster se dvěma uzly bude fungovat bez prostředku kvora, zákazníci musí výhradně použít prostředek kvora, aby měli podporu produkčního prostředí. Ověření clusteru nepředá žádný cluster bez prostředku kvora.

Technicky vzato může cluster se třemi uzly přežít ztrátu jednoho uzlu (až dva uzly) bez prostředku kvora. Jakmile je ale cluster mimo dva uzly, existuje riziko, že clusterované prostředky přejdou do režimu offline, aby se zabránilo situaci rozděleného mozku, pokud dojde ke ztrátě uzlu nebo dojde k selhání komunikace mezi uzly. Konfigurace prostředku kvora umožní prostředkům clusteru zůstat online pouze s jedním uzlem online.

Disk s kopií clusteru je nejodolnější možností kvora, ale pokud chcete použít určující disk na SQL Serveru na virtuálním počítači Azure, musíte použít sdílený disk Azure, který má určitá omezení pro řešení s vysokou dostupností. Pokud například konfigurujete instanci clusteru s podporou převzetí služeb při selhání se sdílenými disky Azure, použijte disk s kopií clusteru, jinak použijte cloudovou kopii clusteru, kdykoli 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:

	Určující cloud	Disk s kopií clusteru	Určující sdílená složka
Podporovaný operační systém	Windows Server 2016+	Vše	Vše
Popis	Cloudová kopie clusteru je typ určujícího clusteru s podporou převzetí služeb při selhání, který používá Microsoft Azure k poskytnutí hlasování o kvoru clusteru. Výchozí velikost je asi 1 MB a obsahuje pouze časové razítko. Cloudová kopie clusteru je ideální pro nasazení ve více lokalitách, více zónách a několika oblastech. Pokud nemáte řešení clusteru s podporou převzetí služeb při selhání se sdíleným úložištěm, použijte cluster s kopií cloudu, kdykoli je to možné.	Disk s kopií clusteru je malý clusterovaný disk ve skupině Úložiště k dispozici v clusteru. Tento disk je vysoce dostupný a může převzít služby při selhání mezi uzly. Obsahuje kopii databáze clusteru s výchozí velikostí menší než 1 GB. Určující disk je upřednostňovanou možností kvora 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 síť SAN s vlákny). Clusterovaný sdílený svazek nelze použít jako určující disk. Nakonfigurujte sdílený disk Azure jako určující disk.	Určující sdílená složka je sdílená složka SMB, která je obvykle nakonfigurovaná na souborovém serveru se systémem Windows Server. Udržuje informace clusteringu v souboru witness.log, ale neukládá kopii databáze clusteru. V Azure můžete nakonfigurovat sdílenou složku na samostatném virtuálním počítači ve stejné virtuální síti. Pokud disk s kopií clusteru nebo cloudový s kopií clusteru není ve vašem prostředí dostupný, použijte určující sdílenou složku.

Pokud chcete začít, přečtěte si téma Konfigurace kvora clusteru.

Název virtuální sítě (VNN)

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. Několik podsítí neguje potřebu další závislosti na Azure Load Balanceru ke směrování provozu do vašeho řešení HADR. Další informace najdete v tématu Skupina dostupnosti s více podsítěmi a FCI s více podsítěmi.

V tradičním místním prostředí clusterované prostředky, jako jsou instance clusteru s podporou převzetí služeb při selhání nebo skupiny dostupnosti AlwaysOn, spoléhají na název virtuální sítě ke směrování provozu do příslušného cíle – buď instance clusteru s podporou převzetí služeb při selhání, nebo naslouchací proces skupiny dostupnosti AlwaysOn. Virtuální název vytvoří vazbu IP adresy v DNS a klienti můžou použít virtuální název nebo IP adresu pro připojení k cíli vysoké dostupnosti bez ohledu na to, který uzel aktuálně vlastní prostředek. Síť VNN je název sítě a adresa spravovaná clusterem a služba clusteru během události převzetí služeb při selhání přesune síťovou adresu z uzlu na uzel. Během selhání se adresa přenese do režimu offline na původní primární replice a na nové primární replice se přenese do režimu online.

Na virtuálních počítačích Azure v jedné podsíti je potřeba další komponenta ke směrování provozu z klienta do názvu virtuální sítě clusterovaného prostředku (instance clusteru s podporou převzetí služeb při selhání nebo naslouchací proces skupiny dostupnosti). Nástroj pro vyrovnávání zatížení v Azure obsahuje IP adresu sítě VNN, na které clusterované prostředky SQL Serveru spoléhají a které jsou nezbytné ke směrování provozu do příslušného cíle s vysokou dostupností. Nástroj pro vyrovnávání zatížení také zjistí selhání síťových komponent a přesune adresu na nového hostitele.

Nástroj pro vyrovnávání zatížení distribuuje příchozí toky, které přicházejí na front-end, a pak tento provoz směruje do instancí definovaných back-endovým fondem. Tok provozu nakonfigurujete pomocí pravidel vyrovnávání zatížení a sond stavu. U FCI SQL Serveru jsou instance back-endového fondu virtuálními počítači Azure se systémem SQL Server a se skupinami dostupnosti je back-endový fond naslouchací proces. Při používání nástroje pro vyrovnávání zatížení dochází k mírnému zpoždění převzetí služeb při selhání, protože sonda stavu provádí kontroly naživu každých 10 sekund.

Začněte tím, že zjistíte, jak nakonfigurovat Azure Load Balancer pro instanci clusteru s podporou převzetí služeb při selhání nebo skupinu dostupnosti.

Podporovaný operační systém: Vše
Podporovaná verze SQL: Vše
Podporované řešení HADR: Instance clusteru s podporou převzetí služeb při selhání a skupina dostupnosti

Konfigurace sítě VNN může být těžkopádná, je to další zdroj selhání, může způsobit zpoždění detekce selhání a má režii a náklady spojené se správou dalšího prostředku. Sql Server zavedl podporu funkce Názvu distribuované sítě, která řeší některá z těchto omezení.

Název distribuované sítě (DNN)

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. Několik podsítí neguje potřebu další závislosti na síti DNN ke směrování provozu do vašeho řešení HADR. Další informace najdete v tématu Skupina dostupnosti s více podsítěmi a FCI s více podsítěmi.

U virtuálních počítačů s SQL Serverem nasazených do jedné podsítě nabízí funkce názvu distribuované sítě alternativní způsob, jak se klienti SQL Serveru připojit k instanci clusteru s podporou převzetí služeb při selhání SQL Serveru nebo naslouchacímu procesu skupiny dostupnosti bez použití nástroje pro vyrovnávání zatížení. Funkce DNN je dostupná od SQL Serveru 2016 SP3, SQL Serveru 2017 CU25, SQL Serveru 2019 CU8 ve Windows Serveru 2016 a novějším.

Po vytvoření prostředku DNN vytvoří cluster vazbu názvu DNS s IP adresami všech uzlů v clusteru. Klient se pokusí připojit ke každé IP adrese v tomto seznamu a zjistí, ke kterému prostředku se má připojit. Tento proces můžete urychlit zadáním MultiSubnetFailover=True v připojovacím řetězci. Toto nastavení říká poskytovateli, aby vyzkoušel všechny IP adresy paralelně, aby se klient mohl okamžitě připojit k FCI nebo naslouchacímu procesu.

Název distribuované sítě se doporučuje v nástroji pro vyrovnávání zatížení, pokud je to možné, protože:

• Ucelené řešení je robustnější, protože už nemusíte udržovat prostředek nástroje 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í.
• Síť DNN zjednodušuje zřizování a správu instance clusteru s podporou převzetí služeb při selhání nebo naslouchacího procesu skupiny dostupnosti s SQL Serverem na virtuálních počítačích Azure.

Většina funkcí SQL Serveru pracuje 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.

Podporovaný operační systém: Windows Server 2016 a novější
Podporovaná verze SQL: SQL Server 2019 CU2 (FCI) a SQL Server 2019 CU8 (AG)
Podporované řešení HADR: Instance clusteru s podporou převzetí služeb při selhání a skupina dostupnosti

Začněte tím, že zjistíte, jak nakonfigurovat prostředek názvu distribuované sítě pro instanci clusteru s podporou převzetí služeb při selhání nebo skupinu dostupnosti.

Při používání sítě DNN s dalšími funkcemi SQL Serveru je potřeba vzít v úvahu další aspekty. Další informace najdete v tématu Interoperabilita FCI a DNN a interoperabilita skupin dostupnosti a sítě DNN.

Akce obnovení

Služba clusteru provede nápravnou akci při zjištění selhání. To může restartovat prostředek na existujícím uzlu nebo převzít služby při selhání do jiného uzlu. Po zahájení nápravných opatření nějakou dobu trvá jejich dokončení.

Například restartovaná skupina dostupnosti je online podle následujícího pořadí:

1. IP adresa naslouchacího procesu je online
2. Síťový název naslouchacího procesu je online
3. Skupina dostupnosti je online
4. Jednotlivé databáze procházejí obnovením, což může nějakou dobu trvat v závislosti na řadě faktorů, jako je délka protokolu opakování. Připojení jsou směrována naslouchacím procesem pouze po úplném obnovení databáze. Další informace najdete v tématu Odhad doby převzetí služeb při selhání (RTO).

Vzhledem k tomu, že obnovení může nějakou dobu trvat, může agresivní sada monitorování zjistit selhání během 20 sekund způsobit výpadek minut, pokud dojde k přechodné události (například údržba virtuálního počítače Azure se zachováním paměti). Nastavení monitorování na uvolněnější hodnotu 40 sekund může pomoct vyhnout se delšímu přerušení služby.

Pokud chcete upravit nastavení prahových hodnot, podívejte se na osvědčené postupy clusteru, kde najdete další podrobnosti.

Umístění uzlu

Uzly v clusteru s Windows na virtuálních počítačích v Azure můžou být fyzicky oddělené ve stejné oblasti Azure nebo můžou být v různých oblastech. Vzdálenost může představovat latenci sítě, podobně jako když se uzly clusteru rozprostírají mezi umístěními ve vašich vlastních zařízeních. V cloudových prostředích je rozdíl v tom, že v rámci oblasti si možná nejste vědomi vzdálenosti mezi uzly. Kromě toho některé další faktory, jako jsou fyzické a virtuální komponenty, počet segmentů směrování atd. může také přispět ke zvýšení latence. Pokud je latence mezi uzly problém, zvažte umístění uzlů clusteru do skupiny umístění bezkontaktní komunikace, aby se zajistila síťová blízkost.

Omezení prostředků

Při konfiguraci virtuálního počítače Azure určíte limity výpočetních prostředků pro procesor, paměť a vstupně-výstupní operace. Úlohy, které vyžadují více prostředků než zakoupený virtuální počítač Azure, nebo limity disků můžou způsobit problémy s výkonem virtuálního počítače. Snížení výkonu může způsobit neúspěšnou kontrolu stavu služby clusteru nebo funkce vysoké dostupnosti SQL Serveru. Kritické body prostředků můžou usnadnit zobrazení uzlu nebo prostředku do clusteru nebo SQL Serveru.

Náročné operace vstupně-výstupních operací SQL nebo operace údržby, jako jsou zálohy, indexy nebo údržba statistik, můžou způsobit, že virtuální počítač nebo disk dosáhnou limitů propustnosti IOPS nebo MBPS , což může způsobit, že SQL Server nereaguje na kontrolu IsAlive/LooksAlive .

Pokud u SQL Serveru dochází k neočekávanému převzetí služeb při selhání, zkontrolujte, jestli splňujete všechny osvědčené postupy z hlediska výkonu, a monitorujte server pro omezování na úrovni disku nebo virtuálního počítače.

Údržba platformy Azure

Stejně jako jakákoli jiná cloudová služba Azure pravidelně aktualizuje svou platformu, aby zlepšila spolehlivost, výkon a zabezpečení hostitelské infrastruktury pro virtuální počítače. Účel těchto aktualizací sahá od oprav softwarových komponent v hostitelském prostředí až po upgrady síťových komponent nebo vyřazování hardwaru z provozu.

Většina aktualizací platformy nemá vliv na virtuální počítače zákazníků. Pokud aktualizace bez dopadu není možná, Azure zvolí mechanismus aktualizace, který má nejmenší dopad na virtuální počítače zákazníka. Většina nenulových dopadů na údržbu pozastaví virtuální počítač po dobu kratší než 10 sekund. V některých případech Azure používá mechanismy údržby pro zachování paměti. Tyto mechanismy pozastaví virtuální počítač po dobu až 30 sekund a zachová paměť v paměti RAM. Virtuální počítač se pak obnoví a jeho hodiny se automaticky synchronizují.

Údržba zachování paměti funguje pro více než 90 procent virtuálních počítačů Azure. Nefunguje pro řadu G, M, N a H. Azure stále častěji využívá technologie migrace za provozu a zlepšuje mechanismy údržby pro zachování paměti, aby se snížila doba pozastavení. Když je virtuální počítač migrovaný za provozu na jiného hostitele, můžou některé citlivé úlohy, jako je SQL Server, během několika minut zobrazit mírné snížení výkonu, což může vést k pozastavení virtuálního počítače.

Kritickým bodem prostředku během údržby platformy může být skupina dostupnosti nebo FCI zobrazená ve službě clusteru. Další informace najdete v části omezení prostředků v tomto článku.

Pokud používáte agresivní monitorování clusteru, může rozšířené pozastavení virtuálního počítače aktivovat převzetí služeb při selhání. Převzetí služeb při selhání často způsobí větší prostoje než pozastavení údržby, proto doporučujeme použít uvolněné monitorování, aby se zabránilo aktivaci převzetí služeb při selhání při pozastavení virtuálního počítače kvůli údržbě. Další informace o nastavení prahových hodnot clusteru na virtuálních počítačích Azure najdete v osvědčených postupech clusteru.

Omezení

Při práci s FCI nebo skupinami dostupnosti a SQL Serverem na virtuálních počítačích Azure zvažte následující omezení.

MSDTC

Virtuální počítače Azure podporují Microsoft Distributed Transaction Coordinator (MSDTC) ve Windows Serveru 2019 s úložištěm na clusterovaných sdílených svazcích (CSV) a Azure Standard Load Balancer nebo na virtuálních počítačích s SQL Serverem, které používají sdílené disky Azure.

Na virtuálních počítačích Azure se MSDTC nepodporuje pro Windows Server 2016 nebo starší s clusterovanými sdílenými svazky, protože:

• Clusterovaný prostředek MSDTC nelze nakonfigurovat tak, aby používal sdílené úložiště. Pokud ve Windows Serveru 2016 vytvoříte prostředek MSDTC, nezobrazí se žádné sdílené úložiště dostupné pro použití, i když je dostupné úložiště. Tento problém je opravený ve Windows Serveru 2019.
• Nástroj pro vyrovnávání zatížení úrovně Basic nezpracuje porty RPC.

Další kroky

Teď, když jste se seznámili s rozdíly při použití clusteru s podporou převzetí služeb při selhání s Windows s SQL Serverem na virtuálních počítačích Azure, se dozvíte o skupinách dostupnosti funkcí s vysokou dostupností nebo instancích clusteru s podporou převzetí služeb při selhání. Pokud jste připraveni začít, nezapomeňte si projít osvědčené postupy pro doporučení konfigurace.