Sdílet prostřednictvím

Principy kvora clusteru a fondu

Platí pro: Azure Stack HCI, verze 22H2 a 21H2; Windows Server 2022, Windows Server

Převzetí služeb při selhání Windows Serveru poskytuje vysokou dostupnost pro úlohy spuštěné v clusterech Azure Stack HCI a Windows Server. Tyto prostředky jsou považovány za vysoce dostupné, pokud jsou uzly, které je hostují, v provozu; Cluster ale obecně vyžaduje, aby běželo více než polovina uzlů, což se označuje jako kvorum.

Kvorum je navržené tak, aby zabránilo split-brain scénářům, ke kterým může dojít, když dojde k rozdělení sítě a podmnožiny uzlů nedokáží mezi sebou komunikovat. To může způsobit, že se obě podmnožina uzlů pokusí vlastnit úlohu a zapisovat na stejný disk, což může vést k mnoha problémům. Tomu ale brání koncept kvora v rámci převzetí služeb při selhání využívajícího clustering, který vynutí, že v provozu zůstane pouze jedna z těchto skupin uzlů, aby pouze jedna z těchto skupin zůstala online.

Kvorum určuje počet selhání, které může cluster zachovat, i když zůstane online. Kvorum je navržené tak, aby zpracovával scénář, kdy došlo k problému s komunikací mezi podmnožinami uzlů clusteru, aby se více serverů nepokoušal současně hostovat skupinu prostředků a zapisovat na stejný disk současně. Díky tomuto konceptu kvora cluster vynutí zastavení služby clusteru v jedné z podmnožin uzlů, aby bylo zajištěno, že je pouze jeden skutečný vlastník určité skupiny prostředků. Uzly, které byly zastaveny, můžou znovu komunikovat s hlavní skupinou uzlů a automaticky se znovu připojí ke clusteru a spustí jejich službu clusteru.

V Azure Stack HCI a Windows Serveru 2019 existují dvě komponenty systému, které mají vlastní mechanismy kvora:

  • Kvorum clusteru: Funguje to na úrovni clusteru (tj. můžete ztratit uzly a nechat cluster zůstat vzhůru).
  • Kvorum fondu: Funguje na úrovni fondu (tj. můžete ztratit uzly a jednotky, a fond zůstane funkční). Fondy úložiště byly navrženy tak, aby se používaly v clusterovaných i ne clusterových scénářích, což je důvod, proč mají jiný mechanismus kvora.

Přehled kvora clusteru

Následující tabulka poskytuje přehled výsledků kvora clusteru pro jednotlivé scénáře:

Uzly serveru Může přežít selhání jednoho uzlu serveru Může přežít selhání jednoho uzlu serveru a pak druhý Dokáže přežít dvě selhání souběžných uzlů serveru.
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 vyšší Ano Ano Ano

Doporučení pro kvórum clusteru

  • Pokud máte dva uzly, je vyžadován svědek.
  • Pokud máte tři nebo čtyři uzly, důrazně se doporučuje svědek.
  • Pokud máte pět nebo více uzlů, svědek není potřeba a neposkytuje další odolnost.
  • Pokud máte přístup k internetu, použijte cloud witness.
  • Pokud jste v IT prostředí s jinými počítači a sdílenými složkami, použijte určující sdílenou složku.

Jak funguje kvorum clusteru

Pokud uzly selžou nebo když některé podmnožina uzlů ztratí kontakt s jinou podmnožinou, musí přeživší uzly ověřit, že tvoří většinu clusteru, aby zůstaly online. Pokud to nemůžou ověřit, přejdou do režimu offline.

Koncept většiny ale funguje čistě pouze v případě, že je celkový počet uzlů v clusteru lichý (například tři uzly v clusteru s pěti uzly). Co tedy clustery s sudým počtem uzlů (například cluster se čtyřmi uzly)?

Cluster může dvěma způsoby učinit celkový počet hlasů lichým:

  1. Za prvé, to může jít nahoru tím, že přidá svědka s dodatečným hlasem. To vyžaduje nastavení uživatele.
  2. Nebo se může snížit o jeden tím, že vynuluje hlasovací právo jednoho nešťastného uzlu (stane se automaticky podle potřeby).

Pokaždé, když přeživší uzly úspěšně ověří, že jsou většinou, definice většiny se aktualizuje tak, aby byla mezi pouze přeživšími. To umožňuje clusteru ztratit jeden uzel, pak druhý, pak jiný atd. Tento koncept celkového počtu hlasů , které se adaptují po následných selháních, se označuje jako dynamické kvorum.

Dynamický svědek

Dynamický svědek přepíná svůj hlas, aby zajistil, že celkový počet hlasů je lichý. Pokud existuje lichý počet hlasů, svědek nemá hlas. Pokud existuje sudý počet hlasů, má svědek hlas. Dynamický svědek výrazně snižuje riziko, že cluster spadne kvůli selhání svědka. Klastr se rozhodne, zda použije věřitelský hlas na základě počtu hlasovacích uzlů, které jsou v klastru dostupné.

Dynamické kvorum funguje 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, bude jednomu uzlu odebrán jeho hlas. Hlasy mají například jenom tři ze čtyř uzlů, takže celkový počet hlasů je tři a dva přeživší s hlasy se považují za většinu.
  • Pokud máte lichý počet uzlů a žádného svědka, všichni dostanou hlasy.
  • Pokud máte sudý počet uzlů plus svědka, svědek hlasuje, takže celkový počet je lichý.
  • Pokud máte lichý počet uzlů plus svědka, svědek nehlasuje.

Dynamické kvorum umožňuje dynamicky přiřadit hlas uzlu, aby se předešlo ztrátě většiny hlasů a aby cluster mohl běžet s jedním uzlem (známý jako poslední přežívající). Jako příklad si vezmeme cluster se čtyřmi uzly. Předpokládejme, že kvorum vyžaduje 3 hlasy.

V tomto případě by cluster spadl, pokud byste ztratili dva uzly.

Diagram znázorňující čtyři uzly clusteru, z nichž každý získá hlas

Dynamické kvorum ale brání tomu, aby k tomuto problému došlo. Celkový počet hlasů požadovaných pro kvorum se teď určuje na základě počtu dostupných uzlů. S dynamickým kvorem tedy cluster zůstane vzhůru, i když ztratíte tři uzly.

Diagram znázorňující čtyři uzly clusteru, přičemž uzly selhávají po jednom a počet požadovaných hlasů se upraví po každé chybě.

Výše uvedený scénář platí pro obecný cluster, který nemá povolený Storage Spaces Direct. Pokud je však povolené Storage Spaces Direct, cluster může podporovat pouze dvě selhání uzlů. Podrobněji je to vysvětleno v části kvora fondu.

Příklady

Dva uzly bez svědka

Hlas jednoho uzlu je nulový, takže většina hlasů je určena z celkového počtu 1 hlasů. Pokud neočekávaně dojde k výpadku nehlasujícího uzlu, přeživší má 1/1 a klastr přežije. Pokud dojde k neočekávanému výpadku hlasovacího uzlu, přeživší má 0/1 a cluster se vypne. Pokud je hlasovací uzel řádně vypnutý, hlas se přenese do druhého uzlu a cluster přežije. Proto je kritické nakonfigurovat svědka.

Kvorum vysvětleno v případě dvou uzlů bez svědka.

  • Dokáže přežít jedno selhání serveru: padesát procent pravděpodobnosti.
  • Může přežít selhání jednoho serveru a pak druhý: Ne.
  • Může přežít dvě selhání serveru najednou: Ne.

Dva uzly se svědkem

Oba uzly hlasují, plus hlasy svědků, takže většina je určena z celkového počtu 3 hlasů. Pokud některý z uzlů přestane fungovat, přeživší má 2/3 a cluster přežije.

Kvorum v případě dvou uzlů se svědkem bylo vysvětleno.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: 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 celkového počtu 3 hlasů. Pokud některý uzel přestane fungovat, dvě třetiny uzlů zůstanou funkční a clustr přežije. Cluster se změní na dva uzly bez svědka – v tomto okamžiku jste ve scénáři 1.

Kvorum v případě tří uzlů bez svědka je vysvětleno.

  • Může přežít jedno selhání serveru: Ano.
  • Dokáže přežít selhání jednoho serveru a pak druhý: padesát procent pravděpodobnosti.
  • Může přežít dvě selhání serveru najednou: Ne.

Tři uzly s uzlem svědka

Všechny uzly hlasují, takže svědek na začátku nehlasuje. Většina je určena z celkového počtu 3 hlasů. Po jedné chybě má cluster dva uzly se svědkem, což znamená návrat ke scénáři 2. Takže teď dva uzly a svědek hlasují.

Kvorum je vysvětleno v případě tří uzlů se svědkem.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ano.
  • Může přežít dvě selhání serveru najednou: Ne.

Čtyři uzly bez svědka

Hlas jednoho uzlu je nulový, takže většina je určena z celkového počtu 3 hlasů. Po jednom selhání se cluster stane třemi uzly a vy jste ve scénáři 3.

Kvorum vysvětleno v případě čtyř uzlů bez svědka.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ano.
  • Dokáže přežít dvě selhání serveru najednou: padesát procent pravděpodobnosti.

Čtyři uzly se svědkem

Všechny uzly hlasují a také hlasují svědci, takže většina je určena z celkového počtu 5 hlasů. Po jednom selhání jste ve scénáři 4. Po dvou souběžných selháních přejdete na scénář 2.

Kvorum je vysvětleno na příkladu čtyř uzlů se svědkem.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ano.
  • Může přežít dvě selhání serveru najednou: Ano.

Pět uzlů a mimo ni

Všechny uzly hlasují, nebo všechny kromě jednoho hlasují, za předpokladu, že to dává lichý součet. Služba Storage Spaces Direct nemůže fungovat, když jsou více než dva uzly mimo provoz, takže v tuto chvíli není potřeba žádný svědek a ani by nebyl užitečný.

Vysvětlení kvoru pro pět uzlů a více.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ano.
  • Může přežít dvě selhání serveru najednou: Ano.

Teď se, když rozumíme tomu, jak kvorum funguje, podíváme na typy svědků kvora.

Typy kvórum svědků

Cluster s podporou převzetí služeb při selhání podporuje tři typy kvórových svědků:

  • Cloudový svědek – Úložiště objektů blob v Azure přístupné pro všechny uzly clusteru Uchovává informace o clusteringu v souboru witness.log, ale neukládá kopii databáze clusteru.
  • File Share Witness – sdílená složka SMB nakonfigurovaná na souborovém serveru se systémem Windows Server. Uchovává informace o clusteringu v souboru witness.log, ale neukládá kopii databáze clusteru.
  • Svědek disku – malý clusterovaný disk, který je ve skupině dostupného úložiště clusteru. Tento disk je vysoce dostupný a může přepnout mezi uzly při selhání. Obsahuje kopii databáze clusteru. Disk s kopií clusteru není podporovaný v Prostorech úložiště s přímým přístupem.

Přehled kvóra poolu

Právě jsme mluvili o kvoru clusteru, který funguje na úrovni clusteru. Teď se pojďme ponořit do kvora fondu, který funguje na úrovni fondu (tj. můžete ztratit uzly a jednotky a nechat fond zůstat vzhůru). Fondy úložiště byly navrženy tak, aby se používaly v clusterovaných i ne clusterových scénářích, což je důvod, proč mají jiný mechanismus kvora.

Tabulka níže poskytuje přehled výsledků kvora skupiny pro jednotlivé scénáře.

Uzly serveru Může přežít selhání jednoho uzlu serveru Může přežít selhání jednoho uzlu serveru a pak druhý Dokáže přežít dvě selhání souběžných uzlů serveru.
2 Ano 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 vyšší Ano Ano Ano

Jak funguje kvorum poolu

Pokud dojde k selhání jednotek, nebo pokud nějaká podmnožina jednotek ztratí kontakt s jinou podmnožinou, musí jednotky s přeživšími metadaty ověřit, že tvoří většinu fondu, aby zůstaly online. Pokud to nemůžou ověřit, přejdou do režimu offline. Fond je entita, která přejde do režimu offline nebo zůstane online podle toho, jestli má dostatek disků pro kvorum (50% + 1). Databáze clusteru může být +1, pokud je samotný cluster usnášeníschopný.

Kvorum fondu ale funguje jinak než kvorum clusteru následujícími způsoby:

  • Pool vybere podmnožinu disků pro každý uzel pro hostování metadat.
  • Fond používá k přerušení vazeb databázi clusteru.
  • Pool nemá dynamické kvorum.
  • Pool neimplementuje vlastní verzi odebrání hlasu.

Příklady

Čtyři uzly se symetrickým rozložením

Každý z 16 disků má jeden hlas a uzel dva má také jeden hlas (protože se jedná o vlastníka zdroje fondu). Většina je určena z celkového počtu 16 hlasů. Pokud uzly tři a čtyři selžou, přeživší podmnožina má 8 disků a vlastník prostředků fondu má 9/16 hlasů. Takže bazén přežije.

Kvorum fondu 1.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ano.
  • Může přežít dvě selhání serveru najednou: Ano.

Čtyři uzly se symetrickým rozložením a selháním disku

Každý z 16 disků má jeden hlas a uzel 2 má také jeden hlas (protože je vlastníkem zdroje fondu). Většina je určena z celkového počtu 16 hlasů. Nejprve se vypne disk 7. Pokud uzly tři a čtyři selžou, přeživší podmnožina má 7 disků a vlastník zdrojů fondu má 8 z 16 hlasů. Takže pool nemá většinu a klesá.

Kvorum skupiny 2.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít selhání jednoho serveru a pak druhý: Ne.
  • Může přežít dvě selhání serveru najednou: Ne.

Doporučení kvora poolu

  • Ujistěte se, že je každý uzel v klastru symetrický (každý uzel má stejný počet disků).
  • Povolte trojcestné zrcadlení nebo duální paritu, abyste mohli tolerovat selhání dvou uzlů a zachovat virtuální disky online.
  • Pokud je mimo provoz více než dva uzly nebo dva uzly a disk na jiném uzlu jsou mimo provoz, svazky nemusí mít přístup ke všem třem kopiím dat, a proto jsou převezměny do offline režimu a nejsou dostupné. Doporučuje se rychle přenést servery nebo nahradit disky, aby byla zajištěna maximální odolnost všech dat ve svazku.

Další kroky