Skupiny SQL Server Always On Availability Groups jsou nejnovější technologií společnosti Microsoft pro řešení potřeb vysoké dostupnosti a obnovy po havárii organizací, které používají SQL Server. Jednou velkou výhodou AlwaysOn je schopnost řešit HA i DR v jedné implementaci. Zažili jsme následující klíčové výhody AlwaysOn:
Související databáze můžeme seskupit jako součást jedné skupiny dostupnosti a v případě potřeby je převzít společně. To je užitečné zejména pro aplikace, které jsou závislé na více než jedné databázi, jako je Microsoft Office SharePoint, Microsoft Lync a Sage.
Ve srovnání s instancemi clusteru s podporou převzetí služeb při selhání serveru SQL Server jsme zjistili, že úložiště jako jediný bod selhání bylo eliminováno, protože každá instance, která představuje repliku má přiděleno vlastní úložiště.
S AlwaysOn je možné konfigurovat HA a DR najednou. Toho je dosaženo vytvořením vícemístných Windows Failover Clusters jako základů vaší konfigurace AlwaysOn. Provedení přepnutí role při použití AlwaysOn je výrazně jednodušší než při použití Transaction Log Shipping.
Počítačové objekty
Active Directory (AD) je rozsáhlé téma a v tomto článku se nebudeme ponořit do podrobností. Jak můžete hádat, Active Directory je adresářová služba společnosti Microsoft. Z hlediska počítačových sítí je adresářová služba zařízení, které nám umožňuje centrálně registrovat, identifikovat a spravovat všechny objekty v síti. Položky v adresářových službách mapují názvy síťových zařízení na odpovídající IP adresy a další vlastnosti v adresáři. Nejběžnějšími objekty v adresářové službě (a v Microsoft AD) jsou uživatelé a počítače. Stejně jako každý uživatel v doméně může být registrován a spravován z Active Directory, každý počítač v doméně může být také spravován z Active Directory. Stejně jako se očekává, že každý uživatel bude mít jedinečný účet ve službě Active Directory, tak je tomu i u každého počítače.
V Active Directory se ne všechny počítačové objekty mapují na fyzický počítač. Počítačový objekt může představovat fyzický počítač (pracovní stanici nebo server), ale může také představovat něco, co funguje jako počítač, jako je reprezentativní název pro cluster Windows nebo virtuální název pro clusterovou službu (role). Takové reprezentace jsou také jedinečné v Active Directory, stejně jako běžné názvy počítačů.
CNO a VNO ve WSFC
Při instalaci clusteru Windows Failover Cluster vytvoří instalační program ve službě Active Directory entitu nazvanou Objekt názvu počítače (CNO). Tento CNO je primární entita vytvořená ve službě Active Directory pro cluster a představuje „Název serveru“ celého clusteru. Následně další objekty známé jako Objekty virtuálních jmen jsou vytvářeny CNO při provádění takových činností, jako je vytváření rolí klastru, skupin dostupnosti nebo Posluchače skupiny dostupnosti . Tyto CNO a VNO mají přiřazené IP adresy. Tyto adresy můžete zadat při instalaci klastru nebo vytváření nové role klastru nebo naslouchacího modulu. Pro každý cluster, roli a posluchač, který vytvoříte, potřebujete jedinečný název počítače a jedinečnou IP adresu. Obr. 1 ukazuje krok, během kterého specifikujete Cluster Name Object a jeho IP adresu při konfiguraci clusteru.
Názvy, které používáte při konfiguraci clusteru, jsou zcela libovolné. Jen musí být jedinečné. Při vytváření CNO nebo VNO se však doporučuje dodržovat konvence pojmenování běžných počítačů vaší organizace – to pomáhá zjednodušit správu. Má také smysl používat specifický blok IP adres, který pokryje všechny potřeby adresování pro celý váš cluster – CNO a všechny VNO (role), které hodláte vytvořit.
>Obr. 1 Mapování názvu na adresu v clusteru
Klíčová oprávnění domény
DBA nebo správce systému provádějící instalaci clusteru musí mít oprávnění k vytváření počítačových objektů v doméně Active Directory. Po vytvoření objektu názvu počítače musí správce domény udělit objektu názvu počítače následující oprávnění, aby bylo možné v clusteru úspěšně vytvořit role (které vedou k objektům virtuálních jmen):
Vytvoření počítačových objektů
Přečíst všechny vlastnosti
Bez těchto oprávnění se při pokusu o vytvoření role pravděpodobně zobrazí chybové zprávy podobné té níže (v případě AlwaysOn FCI ) nebo Listener (v případě AlwaysOn AG). ):
Chyba během instalace MS SQL Server Cluster:
Prostředku síťového názvu clusteru 'Název sítě SQL (EUK-SCCM-01)' se nepodařilo vytvořit přidružený počítačový objekt v doméně 'název_domény.com' z následujícího důvodu:Nelze vytvořit účet počítače.
Text souvisejícího chybového kódu je:Přístup byl odepřen.
Tato chybová zpráva se zobrazuje v prohlížeči událostí, protože SQL Server by v tuto chvíli nebyl dostupný. Budete to také moci vidět, pokud přejdete do souborů protokolu chyb SQL ve složce LOG, která se nachází v instalačním adresáři serveru SQL Server. Klíčová fráze je „Přístup odepřen “.
Další požadavky
Měl bych zmínit koncept řadiče domény. Řadič domény, nebo přesněji, sada řadičů domény poskytuje klíčové služby pro Active Directory, jako je registrace objektů a ověřování uživatelů a počítačů. Aby bylo možné úspěšně nakonfigurovat cluster nebo AlwaysOn Listener, musí být řadič domény dostupný z počítače, kde konfiguraci provádíte. To znamená, že komunikace z počítače do řadiče domény musí být otevřena na řadě portů TCP a UDP. Microsoft to velmi podrobně dokumentuje v tomto článku . Ve většině případů to může být samozřejmé, ale při řešení problémů s připojením pomůže vědět, co je vlastně potřeba.
V předchozím článku , také jsem zmínil, že při konfiguraci kvora pro sdílení souborů je nutné udělit oprávnění CNO clusteru.
>Obr. 2 Oprávnění ke sdílení souborů
Poznámka k rozlišení názvů
CNO a VNO, protože se jedná o počítačové objekty, závisí na službě názvů domén při překladu názvu uvedeného při instalaci clusteru, vytváření role nebo vytváření AlwaysOn Listener. Klienti obvykle dostávají tyto názvy počítačů, aby navázali připojení ke clusteru. Jinými slovy, IP adresa je pro ně transparentní, což zjednodušuje konfiguraci klienta a odstraňuje výpadky od koncových uživatelů.
>Obr. 3 Vlastnosti AG Listener pro Listener se dvěma IP adresami
V předchozím článku jsem zmínil případ, kdy tento scénář může způsobit problémy. V našem clusteru s více místy jsme měli jeden posluchač pro naši skupinu AlwaysOn Availability Group. Tento posluchač byl nakonfigurován pro překlad na dvě IP adresy. To je nezbytné pro cluster s více lokalitami zahrnující více podsítí. V takové konfiguraci názvový server po vydání nslookup vrátí obě IP adresy mapované na posluchače. zkontrolujte (viz obr. 4). Při připojování však můžete přistupovat pouze k jedné z těchto IP adres současně. Správce clusteru zobrazí druhou IP adresu jako Offline (viz obr. 5).
>Obr. 4 Vlastnosti AG Listener pro Listener se dvěma IP adresami
>Obr. 5 vlastností pro roli klastru se dvěma IP adresami v samostatných podsítích
To je normální. Pokud dojde k převzetí služeb při selhání na alternativní lokalitu, server DNS začne po několika minutách řešit alternativní adresu IP. Z toho vyplývá, že komunikace klientů s alternativním webem musí být možná. Obr. 6 a obr. 7 to dále zdůrazňují.
>Obr. 6 Komunikační cesta s primární replikou v Dakaru
Podívejme se dobře na cestu, kterou pakety projdou z klientských počítačů do clusteru. Když je primární replika v Dakaru, jméno posluchače SQL-SVR-LNR se přeloží na IP adresu 192.168.1.20 a WFCS zase přesměruje požadavek na server 192.168.1.22 (všimněte si, že tento server má také svůj vlastní název počítače). V případě selhání do Nairobi vedeme komunikační cestu přes 192.168.2.20 a poté na 192.168.2.22. Z toho vyplývá, že pro bezproblémovou zákaznickou zkušenost musí mít všichni klienti ve všech datových centrech povolenu komunikaci na všech zúčastněných firewallech pomocí portu 1433.
>Obr. 7 Komunikační cesta s primární replikou v Nairobi
Závěr
I když Windows Failover Clustering, Active Directory a Domain Name Service mohou být mimo roli správce databáze, vyplatí se mít základní znalosti o tom, jak tyto technologie fungují, abyste mohli vytvářet a odstraňovat problémy AlwaysOn Instance clusteru převzetí služeb při selhání a skupiny dostupnosti AlwaysOn. Některé organizace mají striktně oddělené povinnosti mezi správce systému a správce databází, ale tam, kde tomu tak není, musí být správce databáze schopen obejmout tyto koncepty Windows, aby uspěl jako DBA.
Odkazy
Přehled skupin dostupnosti AlwaysOn
Windows Failover Clustering s SQL Server
Přehled služeb a požadavky na síťový port pro Windows
Správa počítačových objektů