Principy kvora clusteru a fondu

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

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

Kvorum je navržené tak, aby zabránilo rozděleným scénářům mozku , ke kterým může dojít v případě, že existuje oddíl v síti a podmnožině uzlů nemůže vzájemně komunikovat. To může způsobit, že se obě podmnožina uzlů pokusí o vlastnictví úlohy a zápis na stejný disk, což může vést k mnoha problémům. To se ale brání s konceptem clusteringu s podporou převzetí služeb při selhání, které vynutí, aby běžela jenom jedna z těchto skupin uzlů, takže jenom jedna z těchto skupin zůstane online.

Kvorum určuje počet selhání, které může cluster zachovat, i když zůstane online. Kvorum je navržené tak, aby zvládlo scénář, kdy dochází k potížím s komunikací mezi podmnožinou 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í, aby se služba clusteru zastavila v jedné z podmnožinou uzlů, aby se zajistilo, že existuje pouze jeden skutečný vlastník konkrétní skupiny prostředků. Jakmile uzly, které byly zastavené, můžou znovu komunikovat s hlavní skupinou uzlů, automaticky se znovu připojí ke clusteru a spustí svou 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 mít cluster stále vzhůru).
  • Kvorum fondu: Funguje to na úrovni fondu (tj. můžete ztratit uzly a jednotky a mít fond stále vzhůru). Storage fondy byly navrženy tak, aby se používaly v clusterovaných i neskupených scénářích, což je důvod, proč mají jiný mechanismus kvora.

Přehled kvora clusteru

Následující tabulka obsahuje přehled výsledků kvora clusteru podle 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 další Můž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í kvora clusteru

  • Pokud máte dva uzly, je vyžadována kopie clusteru.
  • Pokud máte tři nebo čtyři uzly, důrazně se doporučuje kopie clusteru.
  • Pokud máte pětuzlůch
  • Pokud máte přístup k internetu, použijte cloudovou kopii clusteru.
  • 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, budou offline.

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

Existuje dva způsoby, jak může cluster nastavit celkový počet hlasů lichý :

  1. Za prvé, 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 to může jít dolů tak, že nuluje jeden nechutný uzel hlas (stane se automaticky podle potřeby).

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

Dynamická kopie clusteru

Dynamický svědek přepíná hlas určujícího, aby se zajistilo, ž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á kopie clusteru výrazně snižuje riziko, že cluster dojde kvůli selhání s kopií. Cluster se rozhodne, jestli se má použít hlas určující kopie na základě počtu hlasovacích uzlů, které jsou v clusteru k dispozici.

Dynamické kvorum funguje s dynamickým kopií clusteru způsobem popsaným níže.

Dynamické chování kvora

  • Pokud máte sudý počet uzlů a žádný s kopií, jeden uzel získá svůj hlas nula. Například pouze tři ze čtyř uzlů získávají hlasy, 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ý svědek, všichni dostanou hlasy.
  • Pokud máte sudý početuzlůch
  • Pokud máte lichý početuzlůch

Dynamické kvorum umožňuje dynamicky přiřadit hlas uzlu, aby nedocházelo ke ztrátě většiny hlasů a aby cluster mohl běžet s jedním uzlem (označovaným jako poslední muž). Pojďme jako příklad vzít cluster se čtyřmi uzly. Předpokládejme, že kvorum vyžaduje 3 hlasy.

V takovém případě by cluster zmizel, pokud jste ztratili dva uzly.

Diagram showing four cluster nodes, each of which gets a vote

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

Diagram showing four cluster nodes, with nodes failing one at a time, and the number of required votes adjusting after each failure.

Výše uvedený scénář platí pro obecný cluster, který nemá povolené Prostory úložiště s přímým přístupem. Pokud je ale povolená Prostory úložiště s přímým přístupem, cluster může podporovat pouze dvě selhání uzlů. To je vysvětleno více v části kvora fondu.

Příklady

Dva uzly bez určující kopie

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 ne hlasovacího uzlu, přeživší má 1/1 a cluster přežije. Pokud hlasovací uzel neočekávaně klesne, přeživší má 0/1 a cluster zmizí. Pokud je hlasovací uzel elegantně vypnutý, hlas se přenese do druhého uzlu a cluster přežije. Proto je důležité nakonfigurovat určující kopii.

Quorum explained in the case with two nodes without a witness

  • Může přežít jedno selhání serveru: Padesát procent šance.
  • Může přežít jedno selhání serveru a pak další: Ne.
  • Může přežít dvě selhání serveru najednou: Ne.

Dva uzly s kopií clusteru

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ý uzel klesne, přeživší má 2/3 a cluster přežije.

Quorum explained in the case with two nodes with a witness

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

Tři uzly bez určující kopie

Všechny uzly hlasují, takže většina je určena z celkového počtu 3 hlasů. Pokud některý uzel klesne, přeživší jsou 2/3 a cluster přežije. Cluster se stane dvěma uzly bez určující kopie – v tomto okamžiku jste ve scénáři 1.

Quorum explained in the case with three nodes without a witness

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

Tři uzly s kopií clusteru

Hlasují všechny uzly, takže svědek na začátku hlasuje. Většina je určena z celkového počtu 3 hlasů. Po jednom selhání má cluster dva uzly se určující kopií clusteru, což je zpět ke scénáři 2. Takže teď dva uzly a hlas určující.

Quorum explained in the case with three nodes with a witness

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

Čtyři uzly bez určující kopie

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 jste ve scénáři 3.

Quorum explained in the case with four nodes without a witness

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít jedno selhání serveru a pak další: Ano.
  • Může přežít dvě selhání serveru najednou: Padesát procent pravděpodobnosti.

Čtyři uzly s kopií clusteru

Všechny uzly hlasují a hlasy svědků, 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.

Quorum explained in the case with four nodes with a witness

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

Pět uzlů a dalších

Všechny uzly hlasují nebo hlasují jen jeden hlas, ať už je celkový počet lichý. Prostory úložiště s přímým přístupem stejně nemůže zpracovat více než dva uzly, takže v tomto okamžiku není potřeba ani užitečný žádný svědek.

Quorum explained in the case with five nodes and beyond

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

Když teď chápeme, jak kvorum funguje, podívejme se na typy svědků kvora.

Typy kopií kvora

Clustering s podporou převzetí služeb při selhání podporuje tři typy svědků kvora:

  • CloudOvá kopie – Úložiště objektů blob v Azure přístupné všemi uzly clusteru Udržuje informace o clusteringu v souboru witness.log, ale neukládá kopii databáze clusteru.
  • Sdílená složka – sdílená složka SMB, která je nakonfigurovaná na souborovém serveru se systémem Windows Server. Udržuje informace o clusteringu v souboru witness.log, ale neukládá kopii databáze clusteru.
  • Disková kopie – malý clusterovaný disk, který je ve skupině k dispozici Storage clusteru. Tento disk je vysoce dostupný a může převzetí služeb při selhání mezi uzly. Obsahuje kopii databáze clusteru. U Prostory úložiště s přímým přístupem se nepodporuje disková kopie.

Přehled kvora fondu

Právě jsme mluvili o kvoru clusteru, který funguje na úrovni clusteru. Teď se podíváme na kvorum fondu, které funguje na úrovni fondu (tj. můžete ztratit uzly a jednotky a mít fond stále vzhůru). Storage fondy byly navrženy tak, aby se používaly v clusterovaných i neskupených scénářích, což je důvod, proč mají jiný mechanismus kvora.

Následující tabulka obsahuje přehled výsledků kvora fondu 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 další Může přežít dvě selhání souběžných uzlů serveru.
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 vyšší Ano Ano Ano

Jak funguje kvorum fondu

Pokud jednotky selžou nebo když některá podmnožina jednotek ztratí kontakt s jinou podmnožinou, musí přeživší jednotky ověřit, že tvoří většinu fondu, aby zůstaly online. Pokud to nemůžou ověřit, budou offline. Fond je entita, která přejde do režimu offline nebo zůstane online na základě toho, jestli má dostatek disků pro kvorum (50 % + 1). Vlastník prostředku fondu (aktivní uzel clusteru) může být +1.

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

  • fond používá jeden uzel v clusteru jako určující klíč jako jistič pro přežití poloviny jednotek pryč (tento uzel, který je vlastníkem prostředku fondu).
  • fond nemá dynamické kvorum
  • fond neimplementuje vlastní verzi odebrání hlasování.

Příklady

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

Každý z 16 jednotek má jeden hlas a dva uzly mají také jeden hlas (protože je vlastníkem zdroje fondu). Většina je určena z celkového počtu 16 hlasů. Pokud jsou uzly tři a čtyři dolů, má přeživší podmnožina 8 jednotek a vlastník zdroje fondu, což je 9/16 hlasů. Takže bazén přežije.

Pool Quorum 1

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít jedno selhání serveru a pak další: 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 jednotky

Každý z 16 jednotek 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ů. Za prvé, jednotka 7 zmizí. Pokud jsou uzly tři a čtyři dolů, má přeživší podmnožina 7 jednotek a vlastník zdroje fondu, což je 8/16 hlasů. Takže fond nemá většinu a jde dolů.

Pool Quorum 2

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

Čtyři uzly s nesymetrickým rozložením

Každý z 24 jednotek má jeden hlas a dva uzly mají také jeden hlas (protože je vlastníkem zdroje fondu). Většina je určena z celkového počtu 24 hlasů. Pokud uzly tři a čtyři půjdou dolů, má přeživší podmnožina 8 jednotek a vlastník zdroje fondu, což je 9/24 hlasů. Takže fond nemá většinu a jde dolů.

Pool Quorum 3

  • 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 pojdou 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 pojdou dolů, ale mohou přežít všechny ostatní scénáře.

Doporučení kvora fondu

  • Ujistěte se, že je každý uzel v clusteru symetrický (každý uzel má stejný počet jednotek).
  • Povolte trojcestné zrcadlení nebo duální paritu, abyste mohli tolerovat selhání uzlů a udržovat 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 jejich dat, a proto se převedou do offline režimu a nebudou k dispozici. Doporučujeme rychle přenést servery zpět nebo nahradit disky, abyste zajistili maximální odolnost všech dat ve svazku.

Další kroky

Další informace najdete v následujících článcích: