Principy kvora clusteru a fondu

  • Článek

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

Clustering s podporou 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 se považují za vysoce dostupné, pokud jsou uzly, které hostují prostředky, spuštěné. cluster však obecně vyžaduje, aby byla spuštěná více než polovina uzlů, což se označuje jako kvorum.

Kvorum je navržené tak, aby se zabránilo scénářům rozdělení mozku , ke kterým může dojít, když je v síti oddíl a podmnožina uzlů nemůže vzájemně 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 clusteringu s podporou převzetí služeb při selhání, který vynutí, aby nadále běžela jenom jedna z těchto skupin uzlů, takže online zůstane jenom jedna z těchto skupin.

Kvorum určuje počet selhání, která cluster může utrpět, když zůstane online. Kvorum je navržené tak, aby zvládlo situaci, kdy dojde k potížím s komunikací mezi podmnožinami uzlů clusteru, aby se několik serverů nepokoušlo současně hostovat skupinu prostředků a zapisovat na stejný disk současně. Díky tomuto konceptu kvora cluster vynutí, aby se clusterová služba zastavila v jedné z podmnožinou uzlů, aby se zajistilo, že konkrétní skupina prostředků bude mít pouze jednoho skutečného vlastníka. Zastavené uzly můžou znovu komunikovat s hlavní skupinou uzlů a automaticky se znovu připojí ke clusteru a spustí se jejich clusterová služba.

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

  • Kvorum clusteru: Funguje na úrovni clusteru (tj. můžete ztratit uzly a nechat cluster zůstat v provozu).
  • Kvorum fondu: Funguje na úrovni fondu (tj. můžete ztratit uzly a jednotky a nechat fond zůstat v provozu). Fondy úložiště byly navrženy tak, aby se používaly v clusterových i ne clusterových scénářích, a proto 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, pak jiného Může přežít dvě souběžná selhání uzlu serveru
2 50/50 No No
2 + svědek Yes No No
3 Yes 50/50 No
3 + Svědek Yes Yes No
4 Yes Yes 50/50
4 + Svědek Yes Yes Yes
5 a vyšší Yes Yes Yes

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ět nebo více uzlů, není určující kopie nutná a neposkytuje další odolnost.
  • 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žívající uzly ověřit, že tvoří většinu clusteru, aby zůstaly online. Pokud to nemůžou ověřit, přejdou do offline režimu.

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 se sudým počtem uzlů (řekněme cluster se čtyřmi uzly)?

Existují dva způsoby, jak může cluster nastavit , aby byl celkový počet hlasů lichý :

  1. Za prvé, může jít o jeden nahoru přidáním svědka s dodatečným hlasem. To vyžaduje nastavení uživatele.
  2. Nebo může jít o jednu dolů tak, že vynuluje hlas jednoho nešťastníka uzlu (probíhá automaticky podle potřeby).

Kdykoli přeživší uzly úspěšně ověří, že jsou většinou, aktualizuje se definice většiny tak, aby byla jen mezi pozůstalými. Díky tomu může cluster ztratit jeden uzel, pak další, další 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á určující kopie

Dynamická určující složka přepíná hlas svědka, aby se zajistilo, že celkový počet hlasů je lichý . Pokud existuje lichý počet hlasů, svědek hlas nemá. Pokud existuje sudý počet hlasů, má svědek hlas. Dynamická s kopií clusteru výrazně snižuje riziko, že cluster přestane fungovat kvůli selhání určující složky. Cluster se rozhodne, jestli se má použít hlas s kopií clusteru na základě počtu hlasovacích uzlů, které jsou v clusteru dostupné.

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

Dynamické chování kvora

  • Pokud máte sudý počet uzlů a žádná kopie clusteru, jeden uzel získá svůj hlas nulový. Například pouze tři ze čtyř uzlů získají hlasy, takže celkový počet hlasů je tři a dva pozůstalí s hlasy jsou považováni za většinu.
  • Pokud máte lichý počet uzlů a žádný svědek, všechny získají hlasy.
  • Pokud máte sudý počet uzlů plus s kopií clusteru, určující složka hlasuje, takže součet je lichý.
  • Pokud máte lichý počet uzlů plus s kopií clusteru, určující kopie hlasovat nebude.

Dynamické kvorum umožňuje dynamicky přiřadit hlas uzlu, aby nedošlo ke ztrátě většiny hlasů a umožnilo clusteru spustit s jedním uzlem (označovaným jako poslední stojící). Vezměme si jako příklad cluster se čtyřmi uzly. Předpokládejme, že kvorum vyžaduje 3 hlasy.

V takovém případě by se cluster ztratil, pokud byste ztratili dva uzly.

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

Dynamické kvorum tomu ale brání. Celkový počet hlasů požadovaných pro kvorum se teď určuje na základě počtu dostupných uzlů. Díky dynamickému kvoru 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í postupně a počet požadovaných hlasů se upravuje po každém selhání

Výše uvedený scénář se vztahuje na obecný cluster, který nemá povolené Prostory úložiště s přímým přístupem. Pokud je ale Prostory úložiště s přímým přístupem povolená, cluster může podporovat pouze dvě selhání uzlů. Další informace najdete v části kvora fondu.

Příklady

Dva uzly bez určujícího prvku

Hlas jednoho uzlu je nulový, takže většina hlasů je určena z celkového počtu 1 hlasu. Pokud neočekávaně dojde k výpadku nehlasujícího uzlu, pozůstalý má 1/1 a cluster přežije. Pokud se hlasovací uzel neočekávaně vypne, pozůstalý 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 důležité nakonfigurovat určující kopii.

Vysvětlení kvora v případě se dvěma uzly bez určujícího prvku

  • Může přežít jedno selhání serveru: Padesátiprocentní pravděpodobnost.
  • 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 s kopií clusteru

Hlasují oba uzly plus hlasy svědka, takže většina je určena z celkového počtu 3 hlasů. Pokud některý z uzlů přestane fungovat, pozůstalý bude 2/3 a cluster přežije.

Vysvětlení kvora v případě dvou uzlů s kopií clusteru

  • 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 určujícího prvku

Hlasují všechny uzly, takže většina je určena z celkového počtu 3 hlasů. Pokud dojde k výpadku některého uzlu, pozůstalí jsou 2/3 a cluster přežije. Cluster se změní na dva uzly bez určující složky – v tomto okamžiku jste ve scénáři 1.

Vysvětlení kvora v případě se třemi uzly bez určujícího prvku

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít jeden selhání serveru, pak další: Padesátiprocentní pravděpodobnost.
  • 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 zpočátku nehlasuje. Většina je určena z celkového počtu 3 hlasů. Po jednom selhání má cluster dva uzly s kopií clusteru – což je zpět ke scénáři 2. Takže teď hlasují dva uzly a svědek.

Vysvětlení kvora v případě se třemi uzly s kopií clusteru

  • 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 určujícího prvku

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 změní na tři uzly a vy jste ve scénáři 3.

Vysvětlení kvora v případě čtyř uzlů bez určujícího prvku

  • 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átiprocentní pravděpodobnost.

Čtyři uzly s kopií clusteru

Hlasuje všechny uzly a hlasuje svědek, 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řeskočíte na Scénář 2.

Vysvětlení kvora v případě čtyř uzlů s kopií clusteru

  • 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 více

Hlasují všechny uzly nebo všechny kromě jednoho hlasu, bez ohledu na to, co činí celkový výsledek lichým. Prostory úložiště s přímým přístupem stejně nezvládnou více než dva uzly mimo provoz, takže v tomto okamžiku není žádný určující nebo užitečný.

Vysvětlení kvora v případě s pěti uzly a dále

  • 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.

Teď, když rozumíme fungování kvora, se podíváme na typy svědků kvora.

Typy určujících souborů kvora

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

  • Cloudová kopie clusteru – Ú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.
  • Určující sdílená složka – sdílená složka SMB, která je 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.
  • Disk s kopií clusteru – malý clusterovaný disk, který je ve skupině úložiště k dispozici v clusteru. Tento disk je vysoce dostupný a může převzít služby při selhání mezi uzly. Obsahuje kopii databáze clusteru. Disk s kopií clusteru není v Prostory úložiště s přímým přístupem podporovaný.

Přehled kvora fondu

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 v provozu). Fondy úložiště byly navrženy tak, aby se používaly v clusterových i ne clusterových scénářích, a proto mají jiný mechanismus kvora.

Následující tabulka poskytuje 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, pak jiného Může přežít dvě souběžná selhání uzlu serveru
2 Yes No No
2 + svědek Yes No No
3 Yes No No
3 + Svědek Yes No No
4 Yes No No
4 + Svědek Yes Yes Yes
5 a vyšší Yes Yes Yes

Jak funguje kvorum fondu

Pokud jednotky selžou nebo když některá podmnožina jednotek ztratí kontakt s jinou podmnožinou, musí zbývající jednotky hostující metadata ověřit, že tvoří většinu fondu, aby zůstaly online. Pokud to nemůžou ověřit, přejdou do offline režimu. 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). Databáze clusteru může mít +1, pokud je samotný cluster poměrrate.

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

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

Příklady

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

Každá ze 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 uzly tři a čtyři budou mimo provoz, má přeživší podmnožina 8 jednotek a vlastníka prostředku fondu, což je 16 hlasů 9/16. 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 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á ze 16 jednotek má jeden hlas a uzel 2 má také jeden hlas (protože je vlastníkem prostředku fondu). Většina je určena z celkového počtu 16 hlasů. Za prvé, jednotka 7 jede dolů. Pokud uzly tři a čtyři budou mimo provoz, má přeživší podmnožina 7 jednotek a vlastníka prostředku fondu, což je 8/16 hlasů. Takže fond nemá většinu a dojde k poklesu.

Kvorum fondu 2.

  • Může přežít jedno selhání serveru: Ano.
  • Může přežít jedno selhání serveru, pak jiné: Ne.
  • Může přežít dvě selhání serveru najednou: Ne.

Doporučení kvora fondu

  • Ujistěte se, že jsou všechny uzly v clusteru symetrické (každý uzel má stejný počet jednotek).
  • Povolte třícestné zrcadlení nebo duální paritu, abyste mohli tolerovat selhání dvou uzlů a virtuální disky zůstaly online.
  • Pokud jsou mimo provoz více než dva uzly nebo dva uzly a disk na jiném uzlu jsou mimo provoz, nemusí mít svazky přístup ke všem třem kopiím svých dat, a proto budou převezmou do režimu offline a nebudou k dispozici. Doporučujeme rychle vrátit servery nebo vyměnit disky, aby byla zajištěna maximální odolnost všech dat na svazku.

Další kroky