Pochopení clusteru a bazén kvora

• 01/18/2019
• 11 minut číst
• • 
  • e
  • v
  • C
  • J
  • +3

Platí pro: Windows Server 2019, Windows Server 2016

Windows Server Failover Clustering poskytuje vysokou dostupnost pro pracovní vytížení. Tyto zdroje jsou považovány za vysoce dostupné, pokud jsou uzly, které hostují zdroje; klastr však obecně vyžaduje, aby byla spuštěna více než polovina uzlů, což se nazývá kvorum.

kvorum je navržen tak, aby zabránil scénářům rozděleného mozku, ke kterým může dojít, když je v síti oddíl a podmnožiny uzlů nemohou vzájemně komunikovat. To může způsobit, že se obě podmnožiny uzlů pokusí vlastnit pracovní zátěž a zapsat na stejný disk, což může vést k mnoha problémům. Tomu je však zabráněno konceptem Kvora klastrů při selhání, který nutí pokračovat v provozu pouze jednu z těchto skupin uzlů, takže pouze jedna z těchto skupin zůstane online.

kvorum určuje počet poruch, které může cluster udržet, zatímco zůstane online. Kvorum je navržen tak, aby zvládnout scénář, když to je problém s komunikací mezi podmnožiny uzlů clusteru tak, aby více serverů nesnažte se současně hostit skupinu zdrojů a napište stejný disk ve stejnou dobu. Tím, že má tento koncept kvora, cluster donutí clusterovou službu zastavit se v jedné z podmnožin uzlů, aby se zajistilo, že existuje pouze jeden skutečný vlastník konkrétní skupiny zdrojů. Jakmile uzly, které byly zastaveny, mohou znovu komunikovat s hlavní skupinou uzlů, automaticky se znovu připojí k clusteru a spustí svou službu clusteru.

V systému Windows Server 2019 a Windows Server 2016, jsou tam dva komponenty systému, které mají své vlastní mechanismy kvora:

• Cluster Quorum: To působí na úrovni clusteru (tj. můžete ztratit uzly a clusteru zůstat up)
• Bazén Usnášeníschopnost: Tohle funguje na bazén úroveň, když se Storage Spaces Direct je aktivní (tj. můžete přijít uzlů a disků a máme bazénu zůstat up). Fondy úložišť byly navrženy tak, aby byly použity jak v seskupených, tak v neklasifikovaných scénářích, a proto mají odlišný mechanismus kvora.

přehled kvora klastru

níže uvedená tabulka uvádí přehled výsledků Kvora klastru podle scénáře:

Serveru uzly	Může přežít jeden server selhání uzlu	Může přežít jeden server selhání uzlu, pak další	Může přežít dva simultánní server selhání uzlu
2	50/50	Ne	Ne
2 + Svědek	Ano	Ne	Ne
3	Ano	50/50	Ne
3 + Svědek	Ano	Ano	Ne
4	Ano	Ano	50/50
4 + Svědek	Ano	Ano	Ano
5 a výše	Ano	Ano	Ano

Clusteru kvora doporučení

• Pokud máte dva uzly, svědka je nutné.
• pokud máte tři nebo čtyři uzly, svědka důrazně doporučujeme.
• Pokud máte přístup k Internetu, použijte cloud svědek
• Pokud jste v prostředí s jinými stroji a sdílených souborů, použijte sdílení souborů svědek

Jak clusteru kvora funguje

Když uzly selžou, nebo když nějakou podmnožinu uzlů ztrácí kontakt s jinou podmnožinu, přežívající uzly je třeba ověřit, že představují většinu clusteru zůstane online. Pokud to nemohou ověřit, přejdou do režimu offline.

ale koncept většiny funguje čistě pouze tehdy, když je celkový počet uzlů v klastru lichý (například tři uzly v klastru pěti uzlů). A co klastry se sudým počtem uzlů (řekněme čtyř uzlový klastr)?

Existují dva způsoby, jak clusteru může udělat celkový počet hlasů liché:

1. První, to může jít nahoru, jeden po přidání svědka, s extra hlasování. To vyžaduje nastavení uživatele.
2. nebo, to může jít dolů jeden vynulováním jednoho nešťastného uzlu hlas (stane se automaticky podle potřeby).

kdykoli přežívající uzly úspěšně ověří, že jsou většinou, definice většiny je aktualizována tak, aby byla mezi přeživšími. To umožňuje clusteru ztratit jeden uzel, pak další, pak další a tak dále. Tento koncept celkového počtu hlasů, který se přizpůsobuje po následných neúspěších, je znám jako dynamické kvorum.

dynamický svědek

dynamický svědek přepíná hlas svědka, aby se ujistil, že celkový počet hlasů je lichý. Pokud je lichý počet hlasů, svědek nemá hlas. Pokud je sudý počet hlasů, svědek má hlas. Dynamický svědek výrazně snižuje riziko, že shluk půjde dolů kvůli selhání svědka. Klastr rozhodne, zda použije hlasování svědků na základě počtu hlasovacích uzlů, které jsou v klastru k dispozici.

dynamické kvorum pracuje s dynamickým svědkem způsobem popsaným níže.

dynamické chování kvora

• pokud máte sudý počet uzlů a žádného svědka, jeden uzel vynuluje svůj hlas. Například pouze tři ze čtyř uzlů získat hlasy, takže celkový počet hlasů je tři, a dva přeživší s hlasy jsou považovány za většinu.
• pokud máte lichý počet uzlů a žádný svědek, všichni získají hlasy.
• pokud máte sudý počet uzlů plus svědek, svědek hlasuje, takže součet je lichý.
• pokud máte lichý počet uzlů plus svědek, svědek nehlasuje.

Dynamické quorum umožňuje schopnost přiřadit hlas k uzlu dynamicky, aby se zabránilo ztrátě většiny hlasů a umožňují clusteru spustit s jedním uzlem (známý jako poslední muž stojící). Vezměme si jako příklad čtyř uzlový cluster. Předpokládejme, že kvorum vyžaduje 3 hlasy.

v tomto případě by cluster šel dolů, pokud byste ztratili dva uzly.

dynamické kvorum tomu však brání. Celkový počet hlasů potřebných pro usnášeníschopnost je nyní stanoven na základě počtu dostupných uzlů. Takže s dynamickým kvorem zůstane cluster vzhůru, i když ztratíte tři uzly.

výše uvedený scénář platí pro obecný cluster, který nemá přímo povolené úložné prostory. Je-li však povoleno Storage Spaces Direct, cluster může podporovat pouze dvě selhání uzlu. To je vysvětleno více v sekci pool quorum.

příklady

dva uzly bez svědka.

hlas jednoho uzlu je vynulován, takže většinový hlas je určen z celkového počtu 1 Hlasů. Pokud nehlasovací uzel neočekávaně klesne, přeživší má 1/1 a shluk přežije. Pokud hlasovací uzel neočekávaně klesne, přeživší má 0/1 a shluk klesá. Pokud je hlasovací uzel elegantně vypnutý, hlas se přenese do druhého uzlu a cluster přežije. To je důvod, proč je důležité nakonfigurovat svědka.

• může přežít jedno selhání serveru: padesát procent šance.
• může přežít jedno selhání serveru, pak další: ne.
• může přežít dvě selhání serveru najednou: ne.

dva uzly se svědkem.

hlasují oba uzly plus hlasy svědků, takže většina je určena z celkem 3 hlasů. Pokud některý uzel klesne, přeživší má 2/3 a cluster přežije.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: ne.
• může přežít dvě selhání serveru najednou: ne.

tři uzly bez svědka.

všechny uzly hlasují, takže většina je určena z celkem 3 hlasů. Pokud některý uzel klesne, přeživší jsou 2/3 a cluster přežije. Cluster se stává dvěma uzly bez svědka – v tu chvíli jste ve scénáři 1.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: padesát procent šance.
• může přežít dvě selhání serveru najednou: ne.

tři uzly se svědkem.

hlasují všechny uzly, takže svědek zpočátku nehlasuje. Většina je určena z celkem 3 hlasů. Po jednom selhání má cluster dva uzly se svědkem-což je zpět ke scénáři 2. Takže teď dva uzly a svědek hlasují.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: Ano.
• může přežít dvě selhání serveru najednou: ne.

čtyři uzly bez svědka

hlas jednoho uzlu je vynulován, takže většina je určena z celkem 3 hlasů. Po jednom selhání se cluster stane třemi uzly a jste ve scénáři 3.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: Ano.
• může přežít dvě selhání serveru najednou: padesát procent šance.

čtyři uzly se svědkem.

Všechny uzly hlasů a svědka, hlasy, takže většina se určuje z celkem 5 hlasů. Po jednom neúspěchu jste ve scénáři 4. Po dvou současných selháních přeskočíte na scénář 2.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: Ano.
• může přežít dvě selhání serveru najednou: Ano.

pět uzlů a dále.

všechny uzly hlasují, nebo všechny kromě jednoho hlasu, ať už je celkový lichý. Storage Spaces Direct stejně nemůže zpracovat více než dva uzly dolů, takže v tomto okamžiku není potřeba ani užitečný žádný svědek.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: Ano.
• může přežít dvě selhání serveru najednou: Ano.

Nyní, když chápeme, jak kvorum funguje, podívejme se na typy kvorum svědků.

typy svědků Kvora

Clustering Failover podporuje tři typy svědků Kvora:

• Cloud Witness-úložiště Blob v Azure přístupné všem uzlům clusteru. Udržuje informace o shlukování u svědka.soubor protokolu, ale neukládá kopii databáze clusteru.
• File Share Witness – sdílení souborů SMB, které je nakonfigurováno na souborovém serveru se systémem Windows Server. Udržuje informace o shlukování u svědka.soubor protokolu, ale neukládá kopii databáze clusteru.
• disk Witness-malý seskupený disk, který je ve skupině clusteru dostupné úložiště. Tento disk je vysoce dostupný a může převzít převzetí služeb při selhání mezi uzly. Obsahuje kopii clusterové databáze. Diskový svědek není podporován přímo úložnými prostory.

přehled Kvora fondu

právě jsme hovořili o kvoru klastru, který funguje na úrovni klastru. Nyní se pojďme ponořit do Pool Quorum, který pracuje na úrovni bazénu (tj. můžete ztratit uzly a jednotky a nechat bazén zůstat nahoře). Fondy úložišť byly navrženy tak, aby byly použity jak v seskupených, tak v neklasifikovaných scénářích, a proto mají odlišný mechanismus kvora.

níže uvedená tabulka poskytuje přehled výsledků Kvora fondu podle scénáře:

Serveru uzly	Může přežít jeden server selhání uzlu	Může přežít jeden server selhání uzlu, pak další	Může přežít dva simultánní server selhání uzlu
2	Ne	Ne	Ne
2 + Svědek	Ano	Ne	Ne
3	Ano	Ne	Ne
3 + Svědek	Ano	Ne	Ne
4	Ano	Ne	Ne
4 + Svědek	Ano	Ano	Ano
5 a výše	Ano	Ano	Ano

Jak bazén kvorum funguje

Když disky selžou, nebo když nějakou podmnožinu disky ztrácí kontakt s jinou podmnožinu, přežívající jednotky je třeba ověřit, že představují většinu bazén zůstat on-line. Pokud to nemohou ověřit, přejdou do režimu offline. Fond je entita, která je offline nebo zůstává online na základě toho, zda má dostatek disků pro kvorum (50% + 1). Vlastníkem prostředků fondu (aktivní uzel clusteru) může být +1.

ale pool quorum funguje odlišně od clusteru quorum následujícími způsoby:

• bazén používá jeden uzel v clusteru jako svědek, jako tie-breaker přežít půl disky pryč (tento uzel se, že je zdroj majitel)
• bazén, nemá dynamické quorum
• bazénu NENÍ implementovat vlastní verze odstraňování hlasování

Příklady

Čtyři uzly s symetrické uspořádání.

Každý z 16 jednotky má jeden hlas a uzel dva má také jeden hlas (protože je to zdroj majitel). Většina je určena z celkem 16 hlasů. Pokud uzly tři a čtyři klesnou, přežívající podmnožina má 8 jednotek a vlastníka prostředků fondu, což je 9/16 hlasů. Takže bazén přežije.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: Ano.
• může přežít dvě selhání serveru najednou: Ano.

čtyři uzly se symetrickým uspořádáním a selháním pohonu.

Každý z 16 jednotky má jeden hlas a uzel 2 má také jeden hlas (protože je to zdroj majitel). Většina je určena z celkem 16 hlasů. Za prvé, drive 7 jde dolů. Pokud uzly tři a čtyři klesnou, přežívající podmnožina má 7 jednotek a vlastníka prostředků fondu, což je 8/16 hlasů. Takže bazén nemá většinu a jde dolů.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: ne.
• může přežít dvě selhání serveru najednou: ne.

čtyři uzly s nesymetrickým uspořádáním.

Každý z 24 jednotky má jeden hlas a uzel dva má také jeden hlas (protože je to zdroj majitel). Většina je určena z celkem 24 hlasů. Pokud uzly tři a čtyři jdou dolů, přežívající podmnožina má 8 jednotek a vlastníka prostředků fondu, což je 9/24 hlasů. Takže bazén nemá většinu a jde dolů.

• může přežít jedno selhání serveru: Ano.
• může přežít jedno selhání serveru, pak další: **závisí **(nemůže přežít, pokud oba uzly tři a čtyři jdou dolů, ale mohou přežít všechny ostatní scénáře.
• může přežít dvě selhání serveru najednou: **Závisí * * (nemůže přežít, pokud oba uzly tři a čtyři jít dolů, ale může přežít všechny ostatní scénáře.

Bazén kvora doporučení

• Zajistit, že každý uzel v clusteru je symetrické (každý uzel má stejný počet jednotek)
• Povolit tři-way zrcadlo nebo dual parity tak, že můžete tolerovat selhání uzlu a udržet virtuální disky online. Další podrobnosti najdete na naší stránce s pokyny pro svazek.
• pokud jsou dole více než dva uzly nebo dva uzly a disk v jiném uzlu, svazky nemusí mít přístup ke všem třem kopiím svých dat,a proto mohou být offline a nedostupné. Doporučuje se vrátit servery zpět nebo rychle vyměnit disky, aby byla zajištěna maximální odolnost pro všechna data ve svazku.