Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In een failovercluster is een quorumwitness een onderdeel dat helpt de hoge beschikbaarheid van het cluster te behouden door deel te nemen aan het quorumstemproces. Het quorum is een concept dat wordt gebruikt om het aantal fouten te bepalen dat het cluster kan verduren terwijl het nog operationeel blijft.
In een cluster krijgt elk knooppunt een stem en kan de quorumwitness ook stemmen. Het totale aantal stemmen bepaalt het quorum. Als het cluster operationeel is, moet meer dan de helft van de stemmen actief zijn. Als het aantal stemmen onder deze drempelwaarde valt, stopt het cluster om split-brain-scenario's te voorkomen, waarbij twee delen van het cluster denken dat ze het actieve deel zijn, wat leidt tot datacorruptie.
De rol van de quorumgetuige is om een extra stem te geven om een meerderheid te bereiken of te behouden wanneer er een even aantal knooppunten is, of als bepaalde knooppunten uitvallen. Als het aantal actieve stemmen lager is dan de vereiste meerderheid, stopt het cluster met activiteiten om split-brain-situaties te voorkomen. Split-brain is een scenario waarbij afzonderlijke secties van het cluster elk geloven dat ze onafhankelijk functioneren, wat kan leiden tot inconsistenties of beschadiging van gegevens.
Soorten quorumgetuigen
Er zijn drie verschillende soorten quorumgetuigen die geconfigureerd kunnen worden om hoge beschikbaarheid te waarborgen en situaties van 'split-brain' te voorkomen. Elk element fungeert als een onpartijdige stem in de gezondheid van het quorum van het cluster.
- Cloud witness - een clouddienst zoals Azure Blob Storage
- Schijfwitness - een gedeelde schijf die toegankelijk is voor alle knooppunten
- file share witness - Een gedeelde map die toegankelijk is voor alle knooppunten
Om continue werking en gegevensintegriteit te garanderen, bieden deze quorum getuigen elk een unieke methode om een meerderheidsstem voor clusterbewerkingen te bereiken. Configureer het quorum als best practice om een oneven aantal stemelementen te hebben. Als het cluster een even aantal stemknooppunten heeft, voegt u een schijfwitness of een bestandssharewitness toe. Met deze configuratie kan het cluster één extra knooppuntfout tolereren. Bovendien zorgt het toevoegen van een witness-stem ervoor dat het cluster kan blijven werken, zelfs als de helft van de clusterknooppunten uitvalt of de connectiviteit tegelijkertijd verliest. Afhankelijk van de quorumconfiguratie die u kiest, wordt het cluster geconfigureerd in een van de volgende quorummodi:
Wijze | Beschrijving |
---|---|
Knooppuntmeerderheid (geen getuige) | Alleen knooppunten hebben stemmen. Er is geen quorum-witness geconfigureerd. Het clusterquorum is afhankelijk van de meerderheidsstemmen van de actieve clusterknooppunten. |
Knooppuntmeerderheid met getuige (schijf of bestandsdeling) | Knooppunten hebben stemmen. Daarnaast heeft een quorumwitness een stem. Het clusterquorum is afhankelijk van de meerderheidsstemmen van de actieve clusterknooppunten, inclusief eventuele getuigenstemmen. Een quorumgetuige kan een aangewezen schijfgetuige of een aangewezen bestandssharesgetuige zijn. |
Geen meerderheid (alleen schijfgetuige) | Er zijn geen knooppunten die stemmen hebben. Alleen een disk-witness heeft een stem. Het clusterquorum is afhankelijk van de status van de schijfgetuige. Over het algemeen wordt deze modus niet aanbevolen en moet deze niet worden geselecteerd omdat er een single point of failure voor het cluster wordt gemaakt. |
Opmerking
Als u een bestandssharewitness of een cloudwitness gebruikt, vergeet dan niet om de clusterservice op het laatste actieve knooppunt opnieuw op te starten voordat u alle clusterknooppunten afsluit voor onderhoud. Dit zorgt ervoor dat het cluster de bewerkingen soepel kan hervatten wanneer het weer online wordt gebracht. Witness-typen zoals deze slaan de meest recente clusterdatabase niet op, wat kan leiden tot fouten tijdens het opstarten van het apparaat. Zie Gebeurtenis 1561 voor meer informatie.
Hint
U kunt de dynamische stem controleren die is toegewezen aan een knooppunt door de eigenschap DynamicWeight van het clusterknooppunt te controleren met behulp van de cmdlet Get-ClusterNode . Een DynamicWeight-waarde van 0 betekent dat het knooppunt geen quorumstem heeft, terwijl een waarde van 1 aangeeft dat het knooppunt een quorumstem heeft.
Cloud-getuige
Cloudwitness verschilt van traditionele clusterquorumwitnessconfiguraties, omdat deze een virtuele Azure-machine (VM) in de cloud gebruikt als quorumwitness in plaats van een fysiek datacenter. Cloudwitness maakt gebruik van Azure Blob Storage om een blobbestand te lezen en te schrijven dat het systeem gebruikt als de beslissingsstem om quorum te bereiken. In het volgende diagram ziet u een voorbeeldconfiguratie die gebruikmaakt van cloudwitness.
Cloudwitnessconfiguraties vereisen geen derde afzonderlijk datacenter en geven een extra stem om totale uitval te voorkomen als een van de andere datacenters uitvalt. Er is geen extra site nodig voor het opslaan van de quorumwitness en heeft ook niet het reguliere fysieke onderhoud nodig dat nodig is voor een on-site datacenter.
Naast redundantie zijn er andere voordelen voor het gebruik van de cloudwitness-functie:
Als u Azure Blob Storage gebruikt, wordt extra onderhoudsoverhead verwijderd die normaal gesproken nodig is voor het hosten van VM's in de openbare cloud.
U kunt hetzelfde Azure Storage-account gebruiken voor meerdere clusters. De enige vereisten zijn dat u slechts één blob per cluster gebruikt en de naam van het blobbestand achter de unieke id van het cluster noemt.
Verlaag de lopende kosten voor uw opslagaccount omdat het blobbestand niet veel gegevens nodig heeft en alleen wordt bijgewerkt wanneer de status van het clusterknooppunt verandert.
Azure beschikt over een ingebouwd cloud witness-resourcetype.
Een cloudwitness slaat geen kopie van de clusterdatabase op.
Schijfgetuige
Een schijfwitness is een type quorumwitness dat wordt gebruikt in een failovercluster om de hoge beschikbaarheid van het cluster te behouden. Een schijfwitness is een gedeelde schijf waartoe alle knooppunten in het cluster toegang hebben. De schijfgetuige bevat een kleine hoeveelheid opslagruimte die wordt gebruikt om de clusterconfiguratiedatabase op te slaan. Deze opslagruimte bevat belangrijke informatie over het cluster, zoals de status van elk knooppunt en het eigendom van clusterbronnen. Dit werkt als volgt:
De schijfwitness is geconfigureerd als een gedeelde opslag waartoe alle knooppunten toegang hebben, maar slechts één knooppunt schrijft op elk gewenst moment.
Wanneer de clusterservice wordt gestart, communiceert elk knooppunt met de schijfwitness om de meest recente clusterconfiguratie te lezen.
De schijfgetuige neemt deel aan het quorumstemproces. Als een knooppunt uitvalt, biedt het disk witness een extra stem, wat kan helpen bij het voorkomen van een split-brainscenario.
Als er een netwerkpartitie is, blijft de zijde van de partitie met toegang tot de schijfwitness met de meeste stemmen actief, waardoor de integriteit van het cluster behouden blijft.
De schijfgetuige is handig in clusters met een even aantal knooppunten, waar het kan fungeren als een tiebreaker zodat er altijd een meerderheidsstem is. Het is ook nuttig bij scenario's waarin meerdere knooppunten tegelijkertijd uitvallen, omdat de schijfwitness kan helpen het quorum te behouden.
Het belangrijkste voordeel van het gebruik van een schijfwitness is dat het een consistente en betrouwbare methode biedt voor alle knooppunten om akkoord te gaan met de huidige status van het cluster. Consistentie is essentieel voor het waarborgen van de goede werking van een failovercluster. Het is belangrijk te weten dat de schijfwitness geen gebruikers- of toepassingsgegevens opslaat; hij wordt uitsluitend gebruikt voor de clusterconfiguratiedatabase en het stemmen binnen het quorum.
Getuige voor bestandsshares
Wanneer een cluster een even aantal stemknooppunten bevat, moet u een witness configureren. Door een witness-stem toe te voegen, kan het cluster blijven werken als de helft van de clusterknooppunten tegelijkertijd uitvalt of de verbinding wordt verbroken. Een bestandshare-witness is een type quorum-witness dat gebruikmaakt van een bestandshare van het type Server Message Block (SMB) om clustergegevens in een logboekbestand te onderhouden. Deze bestandsshare kan worden gehost op een server, USB-opslag of NAS (Network Attached Storage).
De bestandsshare-witness is ook nuttig voor clusters met meerdere locaties met gerepliceerde opslag. U kunt een getuige voor bestandssharing gebruiken wanneer:
Een cloudwitness kan niet worden gebruikt omdat uw clusterknooppunten geen betrouwbare internetverbinding of een internetverbinding hebben.
Een schijfgetuige kan niet worden ingezet omdat er geen gedeelde stations zijn om te gebruiken voor een schijfgetuige. Bijvoorbeeld een Storage Spaces Direct-cluster, SQL Server AlwaysOn-beschikbaarheidsgroepen (AG) of Exchange Database Availability Group (DAG). Geen van deze typen clusters maken gebruik van gedeelde schijven.
Dit voorbeeld is een vereenvoudigde configuratie met twee knooppunten in twee on-site datacenters. In typische clusters heeft elk knooppunt één stem, een -bestanddeelgenoot, die één extra stem geeft aan de quorumgetuige. Met deze extra stem kan het cluster actief blijven, zelfs als een van de datacenters wordt uitgeschakeld. In het voorbeeld heeft het clusterquorum vijf mogelijke stemmen en heeft het slechts drie stemmen nodig om verder te blijven draaien.
Naast de twee datacenters is er ook een derde datacenter dat fungeert als de bestandsshaargetuige. Dit datacenter wordt gescheiden gehouden van de andere twee sites en fungeert als host voor een bestandsserver die een back-up maakt van de systeembestandsshare. De bestandssharewitness fungeert als de quorum-witness in deze clusterquorumconfiguratie, zodat het systeem nog steeds blijft draaien, zelfs als een van de datacentra onverwacht wordt afgesloten.
Als u een bestandssharewitness hebt, beschikt u over voldoende redundantie om uw bestandsserver maximaal beschikbaar te houden. Houd er echter rekening mee dat het hosten van de file share witness op een andere, afzonderlijke locatie installatie, regelmatig onderhoud en onafhankelijke connectiviteit met de andere locaties vereist.
Witness-configuratie
Configureer het quorum als best practice om een oneven aantal stemelementen te hebben. Als het cluster een even aantal stemknooppunten heeft, voegt u een schijfwitness of een bestandssharewitness toe om hoge beschikbaarheid te garanderen. Met deze configuratie kan het cluster de fout van één extra knooppunt tolereren. Bovendien zorgt het toevoegen van een witness-stem ervoor dat het cluster kan blijven werken, zelfs als de helft van de clusterknooppunten mislukt of de connectiviteit tegelijkertijd verliest.
Een schijfwitness wordt normaal gesproken aanbevolen wanneer alle clusterknooppunten toegang hebben tot de gedeelde schijf. Aan de andere kant heeft een bestandssharewitness de voorkeur voor scenario's voor herstel na noodgevallen op meerdere locaties met gerepliceerde opslag. Het configureren van een schijfwitness met gerepliceerde opslag is alleen mogelijk als de opslagoplossing lees-schrijftoegang van alle sites naar de gerepliceerde opslag ondersteunt. Zie Een quorumwitness implementeren voor meer informatie over witness-configuratietypen.
Knooppunt stemtoewijzing
In geavanceerde quorumconfiguraties kunt u quorumstemmen toewijzen of verwijderen voor afzonderlijke knooppunten. Standaard wordt aan elk knooppunt in het cluster een stem toegewezen. Zelfs als de stem van een knooppunt wordt verwijderd, neemt het nog steeds deel aan het cluster, ontvangt het updates voor de clusterdatabase en kan het toepassingen hosten.
In specifieke scenario's voor herstel na noodgevallen kunt u overwegen stemmen van bepaalde knooppunten te verwijderen. In een cluster met meerdere locaties kunt u bijvoorbeeld stemmen verwijderen uit de knooppunten die zich op een back-upsite bevinden om te voorkomen dat ze quorumberekeningen beïnvloeden. Deze methode wordt doorgaans alleen aanbevolen wanneer u handmatige failover tussen sites plant. Knooppuntstemtoewijzing wordt niet aanbevolen om een oneven aantal stemknooppunten af te dwingen. In plaats daarvan moet u een schijfwitness of bestandsdeelwitness configureren.
Dynamisch quorumbeheer
Dynamisch quorumbeheer is een geavanceerde configuratieoptie waarmee het cluster de vereisten voor quorummeerderheid dynamisch kan aanpassen. Met deze functie kan het cluster operationeel blijven, zelfs als knooppunten opeenvolgend worden afgesloten, zodat het cluster kan worden uitgevoerd op het laatste overlevende knooppunt.
Dynamisch quorumbeheer biedt verbeterde flexibiliteit en veerkracht voor failoverclusters, waardoor het een waardevolle functie is voor het onderhouden van hoge beschikbaarheid in dynamische omgevingen. Als dynamisch quorumbeheer is ingeschakeld, kan het cluster de stemmen die zijn toegewezen aan knooppunten automatisch aanpassen op basis van de huidige clusterstatus, zodat het cluster knooppuntfouten kan doorstaan of geplande uitschakelingen kan uitvoeren terwijl het quorum behouden blijft. Als dynamisch quorumbeheer is ingeschakeld, kunnen alleen de knooppunten die zijn geconfigureerd om knooppuntstemmen toegewezen te hebben, dynamisch hun stemmen toegewezen of verwijderd.
Belangrijke overwegingen:
- Dynamisch quorumbeheer staat het cluster niet toe om de gelijktijdige fout van de meeste stemleden te overleven. Op het moment van een storing in het knooppunt of het afsluiten moet het cluster nog steeds een quorummeerderheid hebben om door te kunnen gaan.
- Als de stem van een knooppunt expliciet wordt verwijderd, kan het cluster die stem niet dynamisch toevoegen of verwijderen.
- In clusters waarvoor Opslagruimten Direct is ingeschakeld, kan het cluster maximaal twee knooppuntfouten tolereren.
Algemene aanbevelingen voor quorumconfiguratie
De clustersoftware bepaalt automatisch de quorumconfiguratie voor een nieuw cluster op basis van het aantal knooppunten en de beschikbaarheid van gedeelde opslag. Deze standaardconfiguratie is doorgaans het meest geschikt voor het cluster. U wordt aangeraden de quoruminstellingen te controleren nadat het cluster is gemaakt en voordat u het implementeert in een productieomgeving.
Als u de gedetailleerde quorumconfiguratie wilt bekijken, kunt u de wizard Configuratie valideren of de cmdlet Test-Cluster gebruiken om de test Quorumconfiguratie valideren uit te voeren. In Failoverclusterbeheer wordt de basisquorumconfiguratie weergegeven in de overzichtssectie voor het geselecteerde cluster. U kunt ook gedetailleerde informatie over quorumresources ophalen door de cmdlet Get-ClusterQuorum uit te voeren.
U kunt op elk gewenst moment de test Quorumconfiguratie valideren uitvoeren om ervoor te zorgen dat de quoruminstellingen optimaal zijn voor uw cluster. De testresultaten geven aan of een configuratiewijziging wordt aanbevolen en de optimale instellingen biedt. Als er aanpassingen nodig zijn, kunt u de aanbevolen wijzigingen toepassen met behulp van de wizard Clusterquorum configureren. Zodra het cluster in productie is, vermijdt u het wijzigen van de quorumconfiguratie, tenzij u de wijziging grondig evalueert en bevestigt dat de wijziging nodig is voor de specifieke vereisten van uw cluster. U kunt overwegen om de quorumconfiguratie in de volgende situaties te wijzigen:
- Knooppunten toevoegen of uitzetten
- Opslag toevoegen of verwijderen
- Een langdurige knooppunt- of getuigefout
- Een cluster herstellen in een scenario voor herstel na noodgevallen voor meerdere locaties