voor het eerst gepubliceerd op MSDN op 27 mei 2011
Hi Cluster Fans,

deze blogpost zal planningsoverwegingen rond
quorum
in een Failover Cluster verduidelijken en enkele van de meest voorkomende vragen beantwoorden die we horen.

de quorumconfiguratie in een failover-cluster bepaalt het aantal storingen dat het cluster kan doorstaan terwijl het nog steeds online blijft. Als er een extra fout optreedt boven deze drempel, wordt het cluster niet meer uitgevoerd. Een veel voorkomende perceptie is dat de reden waarom het cluster stopt met draaien als er te veel fouten optreden, is om te voorkomen dat de resterende knooppunten te veel workloads op zich nemen en dat de hosts overcommitted worden. In feite kent het cluster uw capaciteitsbeperkingen niet of u bereid bent een prestatieslag te nemen om het online te houden. Eerder quorum is ontwerp om het scenario af te handelen wanneer er een probleem is met de communicatie tussen reeksen clusterknooppunten, zodat twee servers niet proberen om tegelijkertijd een brongroep te hosten en tegelijkertijd naar dezelfde schijf te schrijven. Dit staat bekend als een” gespleten hersenen ” en we willen dit voorkomen om eventuele corruptie te voorkomen op een schijf die ik heb twee gelijktijdige groepseigenaren. Door dit quorumconcept te hanteren, dwingt het cluster de clusterservice om te stoppen in een van de subsets van knooppunten om ervoor te zorgen dat er slechts één echte eigenaar van een bepaalde brongroep is. Zodra knooppunten die zijn gestopt opnieuw kunnen communiceren met de hoofdgroep van knooppunten, zullen zij zich automatisch opnieuw aansluiten bij het cluster en hun clusterservice starten.

voor meer informatie over quorum in een cluster, bezoek:
http://technet.microsoft.com/en-us/library/cc731739.aspx
.

stemmen in de richting van Quorum

het hebben van quorum, of een meerderheid van de kiezers, is gebaseerd op stemalgoritme waarbij meer dan de helft van de kiezers online moet zijn en met elkaar moet kunnen communiceren. Omdat een bepaald cluster een specifieke set knooppunten en een specifieke quorumconfiguratie heeft, weet het cluster hoeveel “stemmen” een meerderheid van stemmen of quorum vormt. Als het aantal kiezers daalt tot onder de meerderheid, stopt de clusterservice op de knooppunten in die groep. Deze knooppunten zullen nog steeds luisteren naar de aanwezigheid van andere knooppunten, in het geval dat er weer een ander knooppunt op het netwerk verschijnt, maar de knooppunten zullen niet beginnen te functioneren als een cluster totdat het quorum weer bestaat.

het is belangrijk te beseffen dat het cluster
meer dan
de helft van de totale stemmen vereist om het quorum te bereiken. Dit is om te voorkomen dat het aantal stemmen in een partitie gelijkloopt, omdat de meerderheid altijd betekent dat de andere partitie minder dan de helft van de stemmen heeft. In een cluster van 5 knooppunten moeten 3 kiezers online zijn; maar in een 4-knooppunt cluster, 3 kiezers moeten ook online om de meerderheid te hebben. Vanwege deze logica, is het raadzaam om altijd een oneven aantal totale kiezers in het cluster. Dit betekent niet noodzakelijk dat er een oneven aantal knooppunten nodig is, omdat zowel een schijf als een bestandsdeling een stem kunnen bijdragen, afhankelijk van het quorummodel.

een kiezer kan:

  • Een node
    • 1 Stemmen
    • Elk knooppunt in het cluster heeft 1 stem
  • Een “Schijf Getuige” of “File Share Witness”
    • 1 Stemmen
    • 1 Disk Getuige of 1 File Share Witness kunnen hebben een stem in het cluster, maar niet meerdere schijven, meerdere bestanden aandelen of een combinatie van de twee

Quorum Types

Er zijn vier quorum vormen. Deze informatie is ook hier beschikbaar:
http://technet.microsoft.com/en-us/library/cc731739.aspx#BKMK_choices
.

Knooppuntmeerderheid

Dit is het gemakkelijkst te begrijpen quorumtype en wordt aanbevolen voor clusters met een oneven aantal knooppunten (3-knooppunten, 5-knooppunten, enz.). In deze configuratie heeft elk knooppunt 1 stem, dus er is een oneven aantal stemmen in het cluster. Als er een partitie is tussen twee subsets van knooppunten, behoudt de subset met meer dan de helft van de knooppunten het quorum. Als een cluster met 5 knooppunten bijvoorbeeld wordt verdeeld in een subset met 3 knooppunten en een subset met 2 knooppunten, blijft de subset met 3 knooppunten online en de subset met 2 knooppunten offline totdat deze opnieuw verbinding kan maken met de andere 3 knooppunten.

Node & Schijfmeerderheid

deze quorumconfiguratie wordt het meest gebruikt omdat het goed werkt met 2-node en 4-node clusters die de meest voorkomende implementaties zijn. Deze configuratie wordt gebruikt wanneer er een even aantal knooppunten in het cluster zijn. In deze configuratie krijgt elk knooppunt 1 stem, en bovendien krijgt 1 schijf 1 stem, dus er is over het algemeen een oneven aantal totale stemmen.

deze schijf wordt de Disk Witness genoemd (soms aangeduid als de ‘quorum disk’) en is gewoon een kleine geclusterde schijf die zich in de Cluster beschikbare opslaggroep bevindt. Deze schijf is zeer beschikbaar en kan failover tussen nodes. Het wordt beschouwd als onderdeel van de groep Clusterkernbronnen, maar wordt over het algemeen niet weergegeven in Failoverclusterbeheer, omdat er geen interactie met nodig is.

omdat er een even aantal knooppunten en 1 toevoeging Disk Witness stem, in totaal zal er een oneven aantal stemmen. Als er een partitie is tussen twee subsets van knooppunten, behoudt de subset met meer dan de helft van de stemmen het quorum. Als een cluster met 4 knooppunten met een Schijfwitness bijvoorbeeld partities maakt in een subset met 2 knooppunten en een andere subset met 2 knooppunten, is de Schijfwitness ook eigendom van een van die subsets, zodat het 3 totale stemmen heeft en online blijft. De 2-knooppunt subset zal offline totdat het opnieuw kan verbinden met de andere 3 kiezers. Dit betekent dat het cluster de communicatie met twee kiezers kan verliezen, of ze nu 2 knooppunten zijn, of 1 knooppunt en de Witness-schijf.

Node & Bestandsdeelmeerderheid

deze quorumconfiguratie wordt gewoonlijk gebruikt in clusters met meerdere locaties. Deze configuratie wordt gebruikt wanneer er een even aantal knooppunten in het cluster is, zodat het door elkaar kan worden gebruikt met de quorummodus voor Knooppunt-en Schijfmeerderheid. In deze configuratie elk knooppunt krijgt 1 stem, en bovendien 1 remote file share krijgt 1 stem.

deze file Share wordt de File Share Witness (FSW) genoemd en is gewoon een file share op elke server in hetzelfde AD Forest waartoe alle clusterknooppunten toegang hebben. Een knooppunt in het cluster zal een vergrendeling plaatsen op de file share om het te beschouwen als de ‘eigenaar’ van die file share, en een ander knooppunt zal het slot grijpen als de oorspronkelijke eigenaar knooppunt faalt. Op een zelfstandige server is de file share op zichzelf niet erg beschikbaar, maar de file share kan ook op een geclusterde file share op een onafhankelijk cluster zetten, waardoor de FSW geclusterd wordt en deze de mogelijkheid krijgt om tussen knooppunten te falen. Het is belangrijk dat u deze stemming niet plaatst op een knooppunt in hetzelfde cluster, noch binnen een VM op hetzelfde cluster, omdat als u dat knooppunt verliest, u de FSW-stemming verliest, waardoor twee stemmen verloren gaan bij een enkele storing. Een enkele bestandsserver kan meerdere FSWs hosten voor meerdere clusters.

over het algemeen hebben clusters van meerdere locaties twee sites met een gelijk aantal knooppunten op elke site, wat een even aantal knooppunten oplevert. Door deze extra stem toe te voegen aan een 3
rd
site, is er een oneven aantal stemmen in het cluster, tegen zeer weinig kosten in vergelijking met het inzetten van een 3
rd
site met een actief clusterknooppunt en beschrijfbare DC. Dit betekent dat ofwel site of de FSW kan worden verloren en het cluster kan nog steeds quorum handhaven. Bijvoorbeeld, in een multi-site cluster met 2 knooppunten op Site1, 2 knooppunten op Site2 en een FSW op Site3, zijn er 5 totale stemmen. Als er een partitie is tussen de sites, zal een van de knooppunten op een site eigenaar zijn van het slot van de FSW, zodat de site 3 totale stemmen heeft en online blijft. De 2-knooppunt site zal offline totdat het opnieuw kan verbinden met de andere 3 kiezers.

Legacy: Disk Only

belangrijk:
dit quorumtype wordt niet aanbevolen omdat het een enkel foutpunt heeft.

het quorumtype alleen op schijf was beschikbaar in Windows Server 2003 en is onderhouden om compatibiliteitsredenen, maar het wordt ten zeerste aanbevolen om deze modus nooit te gebruiken, tenzij deze wordt gestuurd door een opslagvender. In deze modus bevat alleen de Schijfgetuige een stem en zijn er geen andere kiezers in het cluster. Dit betekent dat als de schijf niet beschikbaar is, het hele cluster offline zal zijn, dus dit wordt beschouwd als een enkel punt van mislukking. Sommige klanten kiezen er echter voor om deze configuratie te implementeren om een “last man standing” – configuratie te krijgen waarbij het cluster online blijft, zolang een knooppunt nog operationeel is en toegang heeft tot de clusterschijf. Met deze implementatiedoelstelling is het echter belangrijk om te overwegen of dat laatste overgebleven knooppunt zelfs de capaciteit aankan van alle workloads die vanuit andere knooppunten naar het knooppunt zijn verplaatst.

standaard Quorum selectie

wanneer het cluster wordt gemaakt met behulp van Failoverclusterbeheer, Cluster.exe of PowerShell, selecteert het cluster automatisch het beste quorumtype voor u om de implementatie te vereenvoudigen. Deze keuze is gebaseerd op het aantal knooppunten en beschikbare opslag. De logica is als volgt:

  • oneven aantal knooppunten-gebruik Knooppuntmeerderheid
    • Even aantal knooppunten
      • beschikbare clusterschijven – gebruik knooppunt & Schijfmeerderheid
      • geen beschikbare clusterschijf – gebruik Knooppuntmeerderheid

het cluster zal nooit Knooppunt-en Bestandsdeelmeerderheid of Legacy selecteren: alleen schijf. Het quorumtype is nog steeds volledig configureerbaar door de beheerder als de standaard selecties niet de voorkeur hebben.

Quorumtypen wijzigen

het quorumtype wijzigen is eenvoudig via Failoverclusterbeheer. Klik met de rechtermuisknop op de naam van het cluster, selecteer Meer acties… en selecteer vervolgens Clusterquoruminstellingen configureren… om de wizard Clusterquorum configureren te starten. Vanuit de wizard is het mogelijk om alle 4 quorumtypen te configureren, de Schijfwitness of File Share Witness te wijzigen. De wizard zal u zelfs het aantal storingen vertellen dat kan worden gehandhaafd op basis van uw configuratie.

voor een stap-voor-stap handleiding voor het instellen van quorum, ga naar:
http://technet.microsoft.com/en-us/library/cc733130.aspx
.

bedankt!
Symon Perriman
Technical Evangelist
Private Cloud Technologies
Microsoft

Bijgewerkt: November 6th, 2019 by Rob Hindman

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.

lg