sql >> Databáze >  >> RDS >> Database

Skupiny dostupnosti AlwaysOn:Kvorum

Skupiny dostupnosti SQL Server AlwaysOn jsou nejnovější technologií společnosti Microsoft pro řešení potřeb vysoké dostupnosti a obnovy po havárii organizací používajících SQL Server. Jednou velkou výhodou AlwaysOn je schopnost řešit HA i DR v jedné implementaci. Klíčové výhody AlwaysOn, které jsme zažili, jsou následující:

  1. Související databáze můžeme seskupit jako součást jedné skupiny dostupnosti a v případě takové 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 nebo Sage.

  2. Ve srovnání s instancemi SQL Server Failover Cluster Instance jsme zjistili, že úložiště jako jediný bod selhání bylo eliminováno, protože každá instance, která tvoří repliku, má přiřazené vlastní úložiště.

  3. S AlwaysOn je možné konfigurovat HA a DR najednou. Toho je dosaženo vytvořením clusterů převzetí služeb při selhání systému Windows pro více stránek jako základu vaší konfigurace AlwaysOn. Provedení přepnutí role při použití AlwaysOn je výrazně jednodušší než při použití Transaction Log Shipping.

Závislost WSFC

Pokud používáte SQL Server AlwaysOn AG pro vysokou dostupnost a zotavení po havárii, musíte nejprve nakonfigurovat cluster Windows Failover Cluster. AlwaysOn AG závisí na WFCS při správě AlwaysOn AG jako role, která se skládá z takových zdrojů clusteru, jako je název skupiny dostupnosti, název sdíleného souboru, název posluchače a adresa IP.

>Obr. 1 AlwaysOn AG jako klastrový zdroj

Kvorum

Kvorum je minimální počet hlasů požadovaný pro většinu v seskupení převzetí služeb při selhání. Kvorum určuje, kolik selhání uzlů může cluster vydržet. Prostřednictvím privátní sítě na portu 3343 komunikují všechny uzly clusteru informace o stavu a monitorování zdrojů. V případě neúspěchu hlasování ukáže, které uzly mají stav „Nahoru“ a na kterých uzlových zdrojích musí být připojeny online.

Od systému Windows Server 2012 je maximální počet podporovaných uzlů clusteru šestnáct. Ve většině prostředí, která znám, jsou však klastry se dvěma uzly běžné. Cluster se dvěma uzly představuje malý problém, pokud jde o dosažení kvora, protože každý uzel má jeden hlas, a pokud mezi nimi dojde k problému s komunikací, každý z nich může předpokládat, že ten druhý není v pořádku. Tomu se říká scénář rozděleného mozku. Scénáře rozděleného mozku jsou důvodem pro konfiguraci rozhodovacího systému, jako je sdílení disku nebo souborů.

Pokud máte lichý počet uzlů, není nutné konfigurovat nerozhodný výsledek. Dynamická konfigurace kvora a Dynamic Witness byly představeny v systému Windows Server 2012 a Windows Server 2012 R2. Pomocí těchto technologií systém Windows automaticky přerozděluje hlasy v klastru, takže počet uzlů v klastru není při vytváření kvora důležitý. Hlas uzlu clusteru se odstraní nastavením vlastnosti clusteru „NodeWeight“ na 0. Tyto funkce jsou ve výchozím nastavení povoleny.

>Obr. 2 Získání všech vlastností clusteru pomocí prostředí PowerShell

>Obr. 3 přidělené hlasy ve dvouuzlovém clusteru

Použití prostředí PowerShell

Příkaz Get-Cluster PowerShell lze použít ke kontrole konfigurace kvora v clusteru Windows. Obr. 4 ukazuje, jak zkontrolovat všechny vlastnosti klastru související s Quorum na klastru a Obr. 5 znázorňuje vlastnosti File Share Witness. Existuje mnoho dalších příkazů PowerShell pro kontrolu a správu clusterů Windows.

Get-Cluster | Format-List –Property *Quorum*

>Obr. 4 Příkaz PowerShellu ke kontrole vlastností souvisejících s kvorem

Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter

>Obr. 5 Příkaz PowerShell ke kontrole podrobností vlastností File Share Witness

Režimy kvora

Windows Server Failover Cluster umožňuje konfiguraci až čtyř režimů. Režimy kvora jsou v podstatě možnosti, které si vyberete, abyste určili, jak bude cluster řešit selhání uzlů.

1. Většina uzlu

Tento režim kvora může vydržet selhání až (n/2)-1 uzlů. Doporučuje se pro clustery s lichým počtem uzlů. Například v klastru s pěti uzly by selhání klastru způsobilo selhání dvou uzlů.

2. Většina uzlu a disku

Může vydržet selhání až poloviny počtu uzlů clusteru, pokud bude pamětník disku (nazývaný také disk kvora) online.

3. Většina sdílení uzlů a souborů

Tento režim kvora může vydržet selhání až poloviny počtu uzlů clusteru, pokud je sdílená složka dostupná. Od systému Windows Server 2012 R2 společnost Microsoft doporučuje, aby při vytváření clusteru byl vždy nakonfigurován svědek (sdílení disku nebo souboru).

4. Žádná většina

Toto je režim Pouze disk. Tento režim může vydržet selhání všech uzlů kromě jednoho, pokud je disk online. Tento režim se nedoporučuje, protože disk se stává jediným bodem selhání.

Tipy pro konfiguraci většiny sdílených uzlů a souborů

Skupiny dostupnosti AlwaysOn podporují pouze dva z těchto režimů kvora:Většina uzlů a Většina sdílení uzlů a souborů. Při vytváření clusteru SQL Server AlwaysOn Availability Group je třeba mít na paměti několik bodů:

1. Používání fyzických serverů

Při konfiguraci dvouuzlového clusteru pro AlwaysOn musí být vaše uzly umístěny v různých fyzických stojanech. Server hostující vaši sdílenou složku musí být umístěn ve třetím stojanu.

2. Použití virtuálních serverů

Při konfiguraci dvouuzlového clusteru pro AlwaysOn musí být vaše virtuální počítače umístěny na samostatných hostitelích. Virtuální počítač hostující vaši sdílenou složku musí být umístěn na třetím hostiteli.

3. Shlukování více stránek

Při konfiguraci víceuzlového clusteru pro AlwaysOn napříč datovými centry musí být v ideálním případě souborový server hostující vaši sdílenou složku umístěn ve třetím datovém centru.

4. Oprávnění ke sdílení souborů

Objekt názvu clusteru by měl mít oprávnění ke sdílené složce používané jako svědek kvora. Bez toho by při pokusu o konfiguraci svědka kvora obvykle došlo k chybám.

>Obr. 6 Oprávnění ke sdílení souborů

5. Online konfigurace

Režimy kvora lze konfigurovat, když je cluster online. Takže v případě, že server pro sdílení souborů selže nebo je potřeba ho překonfigurovat, zajistěte, abyste jej rychle překonfigurovali, abyste zaručili, že nedojde k žádným neočekávaným selháním, zejména na clusteru se dvěma uzly.

Případ použití v reálném životě

Schéma na obr. 7 znázorňuje skutečný Multi-Site AlwaysOn AG Cluster. Jedná se o čtyřuzlový cluster se dvěma uzly na jednom místě a dvěma dalšími na vzdáleném místě DR. Souborový server hostující sdílení souborů používaný jako nerozhodný výsledek je hostován ve třetím datovém centru. V tomto případě se souborový server nachází ve stejném městě jako Primární datové centrum, ale pokud si to můžete dovolit, bylo by ideální mít souborový server v jiném městě. Komunikace mezi třemi stranami musí být kvalitní, aby se zabránilo falešným poplachům.

Například v naší počáteční implementaci tohoto clusteru jsme použili „Synchronou Replication with Automatic Failover“ na Live a DR webech. Při více než jedné příležitosti jsme zaznamenali závadu v komunikaci, která spustila automatické převzetí služeb při selhání na stránce DR a odhalila chybu v naší konfiguraci. To způsobilo, že se název posluchače přeložil na přidružené adresy IP na webu DR a klienti se již nemohli připojit, protože komunikace s touto novou adresou IP nebyla povolena na síťových firewallech. Jednoduše se nám nepodařilo vrátit se na primární místo, abychom problém zmírnili a změnili konfiguraci na „Asynchronní replikace s manuálním převzetím služeb při selhání“ pro uzly umístěné napříč datovými centry. Aspekt rozlišení názvu plánujeme pokrýt v našem dalším článku „AlwaysOn“.

>Obr. 7 Případ skutečného použití

Závěr

Funkce AlwaysOn Availability Groups byla představena v SQL Server 2012 a jde o nejnovější technologii společnosti Microsoft pro řešení potřeb vysoké dostupnosti a obnovy po havárii. Konfigurace skupin dostupnosti AlwaysOn silně závisí na Windows Failover Cluster Service. Failover Clustery zase hodně závisí na správné konfiguraci kvora. Při sestavování AlwaysOn na vícemístných clusterech opravdu záleží na latenci mezi vašimi uzly v různých lokalitách a na sdílení souborů používaném jako arbitr. Zajistěte, aby konfigurace vašeho kvora byla vždy v nejlepším stavu, abyste se vyhnuli neočekávanému chování se skupinami dostupnosti.

Odkazy

  1. Přehled skupin dostupnosti AlwaysOn

  2. Windows Failover Clustering s SQL Server

  3. Dokumentace PowerShell

  4. Porozumění kvoru clusteru převzetí služeb při selhání Windows Server


  1. Jak zkomprimovat a opravit databázi automaticky v Accessu 2016

  2. Jak zrušit dlouhotrvající operaci databáze?

  3. úloha cron k odstranění starých dat z postgresu na debianu

  4. Jak mohu jasně a rychle parametrizovat nulový řetězec pomocí DBNull.Value