înțelegerea cvorumului grupului și grupului

• 01/18/2019
• 11 minute de citit
• • a
  • e
  • v
  • C
  • J
  • +3

se aplică la: Windows Server 2019, Windows Server 2016

Windows Server Failover Clustering oferă disponibilitate ridicată pentru sarcini de lucru. Aceste resurse sunt considerate foarte disponibile dacă nodurile care resursele gazdă sunt sus; cu toate acestea, clusterul necesită, în general, mai mult de jumătate din noduri să ruleze, ceea ce este cunoscut ca având cvorum.

cvorumul este conceput pentru a preveni scenarii split-creier care se poate întâmpla atunci când există o partiție în rețea și subseturi de noduri nu pot comunica între ele. Acest lucru poate determina ambele subseturi de noduri să încerce să dețină volumul de lucru și să scrie pe același disc, ceea ce poate duce la numeroase probleme. Cu toate acestea, acest lucru este împiedicat cu Failover Clustering ‘ conceptul de Cvorum care forțează doar unul dintre aceste grupuri de noduri să continue să ruleze, deci doar unul dintre aceste grupuri va rămâne online.

Cvorumul determină numărul de eșecuri pe care clusterul le poate susține în timp ce rămâne încă online. Quorum este conceput pentru a gestiona scenariul atunci când există o problemă cu comunicarea între subseturi de noduri de cluster, astfel încât mai multe servere să nu încerce să găzduiască simultan un grup de resurse și să scrie pe același disc în același timp. Având acest concept de cvorum, clusterul va forța serviciul cluster să se oprească într-unul din subseturile de noduri pentru a se asigura că există un singur proprietar adevărat al unui anumit grup de resurse. Odată ce nodurile care au fost oprite pot comunica din nou cu grupul principal de noduri, acestea se vor alătura automat clusterului și vor începe serviciul lor de cluster.

în Windows Server 2019 și Windows Server 2016, există două componente ale sistemului care au propriile mecanisme de cvorum:

• Cvorumul clusterului: acesta funcționează la nivelul clusterului (adică. puteți pierde noduri și aveți clusterul să rămână în sus)
• Cvorumul bazinului: acesta funcționează la nivelul bazinului atunci când spațiile de stocare Direct sunt activate (adică puteți pierde noduri și unități și aveți piscina să rămână în sus). Bazinele de depozitare au fost concepute pentru a fi utilizate atât în scenarii grupate, cât și în scenarii ne-grupate, motiv pentru care au un mecanism de cvorum diferit.

prezentare generală a Cvorumului Cluster

tabelul de mai jos oferă o prezentare generală a rezultatelor Cvorumului Cluster pe scenariu:

nodurile serverului	pot supraviețui unui eșec al nodului serverului	pot supraviețui unui eșec al nodului serverului, apoi un alt	poate supraviețui două eșecuri simultane ale nodului serverului
2	50/50	nu	nu
2 + martor	Da	nu	nu
3	Da	50/50	nu
3 + martor	Da	Da	nu
4	Da	Da	50/50
4 + martor	Da	Da	Da
5 și mai sus	Da	Da	Da

recomandări Cluster cvorum

• dacă aveți două noduri, este necesar un martor.
• dacă aveți trei sau patru noduri, martorul este recomandat cu tărie.
• dacă aveți acces la Internet, utilizați un martor cloud
• dacă vă aflați într-un mediu IT cu alte mașini și partajări de fișiere, utilizați un martor partajare de fișiere

cum funcționează cvorumul cluster

când nodurile eșuează sau când un subset de noduri pierde contactul cu un alt subset, nodurile supraviețuitoare trebuie să verifice dacă acestea constituie majoritatea clusterului pentru a rămâne online. Dacă nu pot verifica asta, se vor deconecta.

dar conceptul de majoritate funcționează curat numai atunci când numărul total de noduri din cluster este impar (de exemplu, trei noduri dintr-un cluster cu cinci noduri). Deci, ce zici de clustere cu un număr par de noduri (să zicem, un cluster cu patru noduri)?

există două moduri în care clusterul poate face numărul total de voturi ciudat:

1. în primul rând, poate crește unul adăugând un martor cu un vot suplimentar. Acest lucru necesită configurarea utilizatorului.
2. sau, se poate merge în jos unul prin reducerea la zero vot un nod ghinionist lui (se întâmplă în mod automat după cum este necesar).

ori de câte ori nodurile supraviețuitoare verifică cu succes că sunt majoritatea, definiția majorității este actualizată pentru a fi doar printre supraviețuitori. Acest lucru permite clusterului să piardă un nod, apoi altul, apoi altul și așa mai departe. Acest concept al numărului total de voturi care se adaptează după eșecuri succesive este cunoscut sub numele de cvorum dinamic.

martor dinamic

martor dinamic comută votul martorului pentru a se asigura că numărul total de voturi este impar. Dacă există un număr impar de voturi, martorul nu are un vot. Dacă există un număr par de voturi, martorul are un vot. Dynamic witness reduce semnificativ riscul ca clusterul să scadă din cauza eșecului martorului. Clusterul decide dacă să utilizeze votul martorilor pe baza numărului de noduri de vot care sunt disponibile în cluster.

Cvorumul dinamic lucrează cu martori dinamici în modul descris mai jos.

comportament dinamic al Cvorumului

• dacă aveți un număr par de noduri și niciun martor, un nod își aduce votul la zero. De exemplu, doar trei dintre cele patru noduri obțin voturi, deci numărul total de voturi este de trei, iar doi supraviețuitori cu voturi sunt considerați majoritari.
• dacă aveți un număr impar de noduri și niciun martor, toți primesc voturi.
• dacă aveți un număr par de noduri plus martor, martorul votează, deci totalul este impar.
• dacă aveți un număr impar de noduri plus martor, martorul nu votează.

Cvorumul dinamic permite posibilitatea de a atribui un vot unui nod dinamic pentru a evita pierderea majorității voturilor și pentru a permite clusterului să ruleze cu un singur nod (cunoscut sub numele de Last-man standing). Să luăm ca exemplu un cluster cu patru noduri. Să presupunem că cvorumul necesită 3 voturi.

în acest caz, clusterul ar fi scăzut dacă ați pierdut două noduri.

cu toate acestea, cvorumul dinamic împiedică acest lucru. Numărul total de voturi necesare pentru cvorum este acum determinat pe baza numărului de noduri disponibile. Deci, cu dynamic quorum, clusterul va rămâne ridicat chiar dacă pierdeți trei noduri.

scenariul de mai sus se aplică unui cluster general care nu are spații de stocare direct activate. Cu toate acestea, atunci când spațiile de stocare Direct este activat, cluster poate suporta doar două eșecuri nod. Acest lucru este explicat mai mult în secțiunea cvorum pool.

Exemple

două noduri fără martor.

votul unui nod este zero, deci votul majorității este determinat dintr-un total de 1 vot. Dacă nodul fără vot coboară în mod neașteptat, supraviețuitorul are 1/1 și clusterul supraviețuiește. Dacă nodul de vot coboară în mod neașteptat, supraviețuitorul are 0/1 și clusterul coboară. Dacă nodul de vot este alimentat cu grație, votul este transferat către celălalt nod, iar clusterul supraviețuiește. Acesta este motivul pentru care este esențial să configurați un martor.

• poate supraviețui unui eșec al serverului: cincizeci la sută șansă.
• poate supraviețui unui eșec al serverului, apoi altul: nu.
• poate supraviețui două eșecuri de server simultan: nu.

două noduri cu un martor.

ambele noduri votează, plus voturile martorilor, astfel încât majoritatea este determinată dintr-un total de 3 voturi. Dacă oricare nod coboară, supraviețuitorul are 2/3 și clusterul supraviețuiește.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: nu.
• poate supraviețui două eșecuri de server simultan: nu.

trei noduri fără martor.

toate nodurile votează, deci majoritatea este determinată dintr-un total de 3 voturi. Dacă vreun nod coboară, supraviețuitorii sunt 2/3 și clusterul supraviețuiește. Clusterul devine două noduri fără un martor – în acel moment, sunteți în scenariul 1.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: cincizeci la sută șansă.
• poate supraviețui două eșecuri de server simultan: nu.

trei noduri cu un martor.

toate nodurile votează, deci martorul nu votează inițial. Majoritatea este determinată dintr-un total de 3 voturi. După un eșec, clusterul are două noduri cu un martor-care se întoarce la scenariul 2. Deci, acum cele două noduri și votul martorului.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: Da.
• poate supraviețui două eșecuri de server simultan: nu.

patru noduri fără martor

votul unui nod este zero, deci majoritatea este determinată dintr-un total de 3 voturi. După un eșec, clusterul devine trei noduri și sunteți în scenariul 3.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: Da.
• poate supraviețui două eșecuri de server dintr-o dată: cincizeci la sută șansă.

patru noduri cu un martor.

toate nodurile votează și martorul votează, deci majoritatea este determinată dintr-un total de 5 voturi. După un eșec, ești în scenariul 4. După două eșecuri simultane, treceți la scenariul 2.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: Da.
• poate supraviețui două eșecuri de server simultan: Da.

cinci noduri și mai mult.

toate nodurile votează, sau toate, cu excepția unui vot, orice face ca totalul să fie impar. Spațiile de depozitare Direct nu pot gestiona mai mult de două noduri în jos, Deci în acest moment, nu este nevoie sau util niciun martor.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: Da.
• poate supraviețui două eșecuri de server simultan: Da.

acum, că înțelegem cum funcționează cvorumul, Să analizăm tipurile de martori ai Cvorumului.

tipuri de martori ai Cvorumului

gruparea în caz de eșec susține trei tipuri de martori ai Cvorumului:

• Cloud martor – stocare Blob în Azure accesibil de către toate nodurile clusterului. Menține gruparea informațiilor într-un martor.fișier jurnal, dar nu stochează o copie a bazei de date cluster.
• File Share Witness – o partajare de fișiere SMB care este configurată pe un server de fișiere care rulează Windows Server. Menține gruparea informațiilor într-un martor.fișier jurnal, dar nu stochează o copie a bazei de date cluster.
• Disk Witness – un disc mic grupat care se află în grupul de stocare disponibil Cluster. Acest disc este foarte disponibil și poate failover între noduri. Acesta conține o copie a bazei de date cluster. Un martor disc nu este acceptat cu spații de stocare Direct.

Pool quorum overview

tocmai am vorbit despre Cluster Quorum, care funcționează la nivel de cluster. Acum, să ne scufundăm în Pool Quorum, care funcționează la nivelul piscinei (adică puteți pierde noduri și unități și puteți face piscina să rămână ridicată). Bazinele de depozitare au fost concepute pentru a fi utilizate atât în scenarii grupate, cât și în scenarii ne-grupate, motiv pentru care au un mecanism de cvorum diferit.

tabelul de mai jos oferă o prezentare generală a rezultatelor Cvorumului grupului pe scenariu:

nodurile serverului	pot supraviețui unui eșec al nodului serverului	pot supraviețui unui eșec al nodului serverului, apoi un alt	poate supraviețui două eșecuri simultane ale nodului serverului
2	nu	nu	nu
2 + martor	Da	nu	nu
3	Da	nu	nu
3 + martor	Da	nu	nu
4	Da	nu	nu
4 + martor	Da	Da	Da
5 și mai sus	Da	Da	Da

cum funcționează pool quorum

când unitățile eșuează sau când un subset de unități pierde contactul cu un alt subset, unitățile supraviețuitoare trebuie să verifice dacă acestea constituie majoritatea grupului pentru a rămâne online. Dacă nu pot verifica asta, se vor deconecta. Piscina este entitatea care merge offline sau rămâne online în funcție de faptul dacă are suficiente discuri pentru cvorum (50% + 1). Proprietarul resursei pool (nodul cluster activ) poate fi +1.

dar cvorumul grupului funcționează diferit de cvorumul grupului în următoarele moduri:

• piscina folosește un nod în cluster ca martor ca un tie-breaker pentru a supraviețui jumătate din unități plecat (acest nod care este proprietarul resurselor piscină)
• piscina nu are cvorum dinamic
• piscina nu pune în aplicare propria versiune de a scoate un vot

Exemple

patru noduri cu aspect simetric.

fiecare dintre cele 16 unități are un vot, iar nodul doi are și un vot (deoarece este proprietarul resursei pool). Majoritatea este determinată dintr-un total de 16 voturi. Dacă nodurile trei și patru coboară, subsetul supraviețuitor are 8 unități și proprietarul resursei piscinei, care este de 9/16 voturi. Deci, piscina supraviețuiește.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: Da.
• poate supraviețui două eșecuri de server simultan: Da.

patru noduri cu un aspect simetric și eșec unitate.

fiecare dintre cele 16 unități are un vot, iar nodul 2 are și un vot (deoarece este proprietarul resursei pool). Majoritatea este determinată dintr-un total de 16 voturi. În primul rând, unitatea 7 coboară. Dacă nodurile trei și patru coboară, subsetul supraviețuitor are 7 unități și proprietarul resursei piscinei, care este de 8/16 voturi. Deci, piscina nu are majoritate și se duce în jos.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: nu.
• poate supraviețui două eșecuri de server simultan: nu.

patru noduri cu un aspect nesimetric.

fiecare dintre cele 24 de unități are un vot, iar nodul doi are și un vot (deoarece este proprietarul resursei pool). Majoritatea este determinată dintr-un total de 24 de voturi. Dacă nodurile trei și patru coboară, subsetul supraviețuitor are 8 unități și proprietarul resursei piscinei, care este de 9/24 voturi. Deci, piscina nu are majoritate și se duce în jos.

• poate supraviețui unui eșec al serverului: Da.
• poate supraviețui unui eșec al serverului, apoi altul: **depinde * * (nu poate supraviețui dacă ambele noduri trei și patru coboară, dar pot supraviețui tuturor celorlalte scenarii.
• poate supraviețui două eșecuri de server la o dată: ** Depinde * * (nu poate supraviețui dacă ambele noduri trei și patru coboară, dar pot supraviețui tuturor celorlalte scenarii.

recomandări de cvorum Pool

• asigurați-vă că fiecare nod din cluster este simetric (fiecare nod are același număr de unități)
• activați oglinda cu trei căi sau paritatea duală, astfel încât să puteți tolera eșecurile unui nod și să păstrați discurile virtuale online. Consultați pagina noastră de orientare a volumului pentru mai multe detalii.
• dacă mai mult de două noduri sunt în jos sau două noduri și un disc de pe un alt nod sunt în jos, este posibil ca volumele să nu aibă acces la toate cele trei copii ale datelor lor și, prin urmare, să fie luate offline și să nu fie disponibile. Este recomandat să aduceți serverele înapoi sau să înlocuiți discurile rapid pentru a asigura cea mai mare rezistență pentru toate datele din volum.