5.2 Implementeer Failover-Clustering

Een failover-cluster is een groep van twee of meer computers, fysiek of virtueel en dezelfde applicatie uitvoeren, die functioneert als een enkele entiteit om een zeer beschikbaar, schaalbaar en fouttolerante service te bieden voor clients in het netwerk. Geclusterde applicaties bieden doorgaans essentiële gebruikersservices, zoals database- en e-mailservertoepassingen of infrastructuurdiensten, zoals Hyper-V en bestandsservers. Met meerdere computers, knooppunten genoemd, met dezelfde applicatie, de zijn services altijd beschikbaar, zelfs wanneer een knoop faalt. Wanneer de vraag naar de service toeneemt, kunnen beheerders eenvoudig meer nodes aan het cluster toevoegen, waardoor de algehele capaciteit wordt vergroot.

In Windows Server 2016 biedt de Failover Clustering-functie de benodigde hulpmiddelen om een cluster te maken van maar liefst 64 computers met ondersteuning voor maximaal 8.000 virtuele machinesen maximaal 1.024 VM’s per knooppunt. De functie bevat een grafische managementtool, de Failover Cluster Manager-console, plus een Windows PowerShell-module met een uitgebreide verzameling cmdlets.

Hoewel het mogelijk is om in een laboratoriumomgeving een eenvoudig cluster met twee knooppunten te maken, zelfs op een enkele Hyper-V-server, hebben failover-clusters doorgaans geavanceerde hardware en softwarevereisten, vooral wanneer ze in een productieomgeving vitale services aanbieden aan veel clients. Hardware- en softwarevereisten omvatten het volgende:

  • Servers – De computers die functioneren als clusterknooppunten zijn bedoeld om uitwisselbaar te zijn, dus ze moeten qua hardwarconfiguratie zo veel mogelijk identiek zijn. De ideale situatie is er een waarin elke clusterknoop hetzelfde aantal en type processors en dezelfde hoeveelheid geheugen heeft. De netwerkadapters op alle computers moeten identiek worden geconfigureerd. Voor ondersteuning van Microsoft, moeten alle hardware- en softwarecomponenten in de clusterknooppunten voldoen aan de kwalificaties voor het Certified for Windows Server 2016-logo.
  • Besturingssysteem – Op alle servers in een cluster moet dezelfde versie en editie van het besturingssysteem draaien, waarop dezelfde updates zijn toegepast.
  • Storage – Failover-clusters gebruiken meestal een implementatie voor gedeelde opslag, zoals een Storage Area Network (SAN) of Network Attached Storage (NAS), zodat alle knooppunten toegang hebben tot dezelfde gegevensbestanden. Ooit vereiste dit uitgebreide, en specifieke opslag hardware-infrastructuur, zelfs als de clusterknooppunten virtueel zouden zijn, maar technologieën zoals iSCSI hebben het nu mogelijk gemaakt om gedeelde opslag subsystemen te creëren die gebruik maken van kant-en-klare componenten en virtuele schijfinfrastructuren.
  • Netwerk –  Failover-clusters wisselen hun eigen sturingsverkeer uit tussen de knooppunten, en bij een grote implementatie wordt aanbevolen dat er een apart netwerk wordt gewijd aan clusterverkeer. Bovendien moet de gedeelde opslaginfrastructuur meestal ook een eigen netwerk hebben. Dus een failover-cluster implementatie kan drie of meer netwerkinterfaces per knoop hebben, die verschillende soorten verkeer ondersteunen, evenals de extra switches, bekabeling en andere componenten die nodig zijn om de aanvullende netwerken te ondersteunen. Voor missiekritiek toepassingen, kan het ook nodig zijn om de netwerkimplementaties met redundante adapters, switches en bekabeling samen te stellen om afzonderlijke storingspunten te voorkomen. Voor kleinere implementaties, zoals in een laboratoriumomgeving, is ook het mogelijk om Qualty of Service technologieën, te gebruiken zoals Datacenter Bridging, om bandbreedte op een netwerk te reserveren voor de verschillende soorten verkeer.
  • Toepassingen – Naast de hardwarevereisten voor het cluster zelf, moet u ook rekening houden met de vereisten voor de toepassing die op de cluster knooppunten wordt uitgevoerd. De knooppunten in een Hyper-V-cluster moeten bijvoorbeeld voldoen aan de virtualisatie hardwarevereisten gespecificeerd voor de Hyper-V-rol.

Omdat de hardwareconfiguratie zo’n integraal onderdeel is van het bouwen van een cluster, bevat de Failover Cluster Manager een Validate Cluster Wizard die een reeks tests die u selecteert om te bepalen of deze in aanmerking komen voor lidmaatschap van een cluster die u op de servers uitvoert. U kan ook de Test-Cluster PowerShell-cmdlet gebruiken om deze tests te starten. Het validateringsproces genereert een gedetailleerd rapport.

Nadat de hardwareconfiguratie van het cluster met succes is gevalideerd, kunt u verder gaan met het maken van het cluster met behulp van de wizard Cluster maken of de cmdlet New-Cluster. Hiertoe geeft u de naam op van de servers die u als knooppunten in het cluster wilt toevoegen. U geeft ook een naam op voor het cluster, dit is hoe het wordt geadresseerd op het netwerk, zoals getoond in het volgende voorbeeld:

New-Cluster -name cluster1-node server1, server2

Het cluster is een afzonderlijke entiteit, met een eigen naam en IP-adres. Als er een DHCP server beschikbaar is op het netwerk, zal het cluster daar een IP-adres verkrijgen. Als niet, dan moet u het cluster een statisch adres toewijzen, zoals in het volgende voorbeeld:

New-Cluster -name cluster1 -node server1, server2 -staticaddress 10.0.0.3

Het cluster heeft ook een eigen computerobject in Active Directory, een cluster naam object (CNO) genoemd. Zodra de toepassing op de clusterknooppunten wordt uitgevoerd, zullen de clients zich richten tot het cluster en niet naar de individuele nodes.

5.2.1 Implementeer werkgroep-, enkele en multidomeinclusters

Voorafgaand aan Windows Server 2016 moesten alle servers in een failover-cluster toegevoegd worden aan hetzelfde AD DS-domein. Dit wordt nu een enkel domeincluster genoemd. Zoals eerder genoemd maakt de wizard Cluster Maken en de cmdlet New-Cluster een AD DS-object die standaard het cluster vertegenwoordigt.

Vanaf Windows Server 2016 is het echter mogelijk om een cluster te maken met servers die verbonden zijn met verschillende domeinen, wat een multi-domeincluster wordt genoemd, of servers die helemaal niet verbonden zijn met een domein, dat een werkgroepcluster wordt genoemd.

Failover Clustering maakt gebruik van Active Directory voor verschillende services, niet in de laatste plaats om het cluster zelf te lokaliseren. Zonder ondersteuning van Active Directory is het voor het cluster noodzakelijk om DNS te gebruiken om een beheertoegangspunt te registreren, ook bekend als het clusternetwerk naam.

Er zijn ook Active Directory-problemen met sommige toepassingen die verhinderen te worden uitgevoerd op een multi-domein of werkgroepcluster. Microsoft SQL Server functioneert goed zonder Active Directory omdat het een eigen authenticatiemechanisme heeft. Echter een bestandsservercluster zonder Active Directory-verificatie vereist dat een gebruikeraccounts op elk knooppunt in het cluster maakt.

Voordat u een multi-domein- of werkgroepcluster kunt maken, moet u de volgende taken voltooien.

5.2.1.1 Maak een lokaal account aan

In een enkel domeincluster kan een domeingebruikersaccount toegang bieden tot alle nodes. Zonder Active Directory is toegang tot de nodes voor clustercommunicatie een probleem. Daarom moet u op elke node een lokale gebruikersaccount maken met dezelfde gebruikersnaam en hetzelfde wachtwoord. Vervolgens moet u de gebruiker aan de lokale groep Administrators toevoegen.

U kunt hiervoor het ingebouwde beheerdersaccount gebruiken, dat al een lid van de groep Administrators, als u hetzelfde wachtwoord op elk knooppunt toewijst. Als u echter geen beheerdersaccount gebruikt, moet u op op elke node een registersleutel instellen LocalAccountTokenFilterPolicy, met volgende opdracht in een PowerShell-sessie met beheerdersrechten:

New-ItemProperty -path hklm:\Software\Microsoft\Windows\CurrentVersion\policies\system\ -name localaccounttokenfilterpolicy -value 1

5.2.1.2 Voeg DNS suffiuxes toe

Zonder Active Directory moet een cluster DNS gebruiken om de clusterknooppunten en de cluster zelf te vinden. U moet daarom een primair DNS-achtervoegsel opgeven wanneer u een naam aan elk knooppunt toewijst.

Er is geen directe manier om het primaire DNS-achtervoegsel met PowerShell te configureren, maar u kan dit doen met behulp van Groepsbeleid, door te bladeren naar de computer Configuration\Policies\Administrative Templates\Network\DNS Client folder en het primaire DNS-suffixbeleid inschakelen.

Voor een multi-domeincluster moet u ook de Geavanceerde TCP/IP-instellingen in elk knooppunt configureren met de DNS-achtervoegsels voor alle domeinen die in het cluster worden weergegeven.

U kunt dit ook doen met behulp van de Set-DnsClientGlobalSettings PowerShell-cmdlet, als getoond in het volgende voorbeeld:

Set-DnsClientGlobalSettings -suffixsearchlist @("adatum.com", "corp.adatum.com", "paris.adatum.com "," rome.adatum.com ")

5.2.1.3 Creeër een werkgroep of meervoudig-domein cluster

Met deze instellingen kunt u doorgaan met het maken van het cluster. Wanneer u PowerShell gebruikt, gebruikt u de New-Cluster-cmdlet, net zoals u zou doen voor een enkel domeincluster, maar u moet de parameter AdministrativeAccessPoint bevatten met de DNS-waarde, zoals weergegeven in volgend voorbeeld:

New-Cluster -Name cluster1 -node server1, server2, server3 -AdministrativeAccesspoint dns

De parameter AdministrativeAccessPoint zorgt ervoor dat de cmdlet een DNS-naam gebruikt voor de cluster en voorkomt dat een computerobject in Active Directory wordt gemaakt. Je kan ook de Failover Cluster Manager gebruik om het cluster te maken, als de computer die u gebruikt niet is aangesloten bij een AD DS-domein.

5.2.2 Configureer quorum

De functie van quorum bij failover-clustering is om te voorkomen dat een cluster wordt opgesplitst twee, met beide helften blijven lopen. Dit wordt een split-brain situatie genoemd. Als bijvoorbeeld een netwerkfout het splitsen veroorzaakt van een cluster met zes nodes in twee drie-node clusters, zouden beide kunnen blijven werken als er geen quorum was. Als het cluster waarop een database-applicatie actief was zou dit betekenen dat er twee afzonderlijke kopieën van de database zijn en tegelijkertijd kunnen worden benaderd en bijgewerkt door verschillende sets van clients. Dit zou rampzalig kunnen zijn voor de integriteit van de informatie in de database.

Een quorum geeft elke node in het cluster een stem en in veel gevallen is er een getuige-schijf die nog een stem toevoegt om potentiële banden te verbreken. Alle knooppunten bewaken voortdurend het stemmen van de andere knooppunten en de getuige. Als een knooppunt detecteert dat de stemming klopt en onder 50 procent +1 daalt, verwijdert het zichzelf uit het cluster. In het geval van de zes-node cluster eerder in de helft gesplitst zoals eerder vermeld, zouden alle knooppunten het aantal stemmen terugbrengen van 6 naar 3. Omdat 3 minder dan 50 procent +1 is, zouden alle knooppunten zichzelf verwijderen en beide helften van het cluster afsluiten.

Als er ergens in dit cluster een getuigenis-schijf was, kan de helft die contact kan maken met de getuige-schijf een stemnummer van 4 hebben, dat is 50 procent +1 van het oorspronkelijke cluster. Daarom zou de helft met de getuige-schijf blijven functioneren, terwijl de knooppunten in de andere helft, met een telling van 3 stemmen, zichzelf zou verwijderen.

5.2.2.1 Quorum-getuigen

Wanneer u een failover-cluster maakt met de wizard Cluster maken of de cmdlet New-Cluster maakt het een quorumconfiguratie die in de meeste gevallen geschikt is voor het cluster op basis van het aantal knooppunten en de beschikbare opslagbronnen. Standaard krijgt elk knooppunt een stem, en als er een even aantal knooppunten is, probeert de wizard of cmdlet om een getuige te maken, om als een tie-breaker te functioneren. Net als de knooppunten krijgt de getuige één stem.

Een getuige is een bron dat, door zijn bestaan, een stem uitbrengt voor de voortgezette werking van het cluster. Failover-clustering in Windows Server 2016 ondersteunt drie soorten getuigen, als volgt:

  • Disk Witness – Een speciale schijf in de gedeelde opslag van het cluster die een kopie van de clusterdatabase bevat. Dit is de typische optie voor een cluster op een enkele site.
  • File Share Witness – Een SMB-bestandsdeling op een Windows-server met een Witness.log-bestand met informatie over het cluster. Dit is de typische optie voor clusters verdeeld over meerdere sites met gerepliceerde opslag.
  • Cloud Witness – Een blob opgeslagen in de cloud met behulp van standaard Microsoft Azure-services. Dit is een nieuwe optie in Windows Server 2016, ontworpen voor het splitsen van stretched clusters tussen meerdere datacenters op externe locaties, die een getuige willen behouden onafhankelijk van alle datacenters.

5.2.2.2 Dynamisch quorum beheer

De standaardquorumconfiguratie in Windows Server 2016 bevat ook dynamisch quorum beheer, een functie die is ontworpen om een cluster in situaties te laten draaien waar het in eerdere versies van de Failover Clustering functie zou worden gestopt .

Wanneer een knooppunt het cluster verlaat, verwijdert het dynamisch quorumbeheer automatisch zijn stem, zodat de functionaliteit van het cluster gebaseerd is op het quorum van de resterende stemmen. Bijvoorbeeld in een cluster met vijf knooppunten zonder dynamisch quorumbeheer, als drie knooppunten falen, zakt de quorumstemming naar twee van de vijf en de resterende twee knooppunten verwijderden zichzelf, om het cluster af te sluiten. In hetzelfde cluster met dynamisch quorum beheer, wordt de stem van elk falend knooppunt automatisch uit de telling verwijderd, wat resulteert in een quorumstemming van twee op twee, zodat het cluster blijft functioneren. Deze functie kan daarom een cluster laten functioneren, zelfs wanneer alle knooppunten op één na zijn mislukt.

5.2.2.3. Quorum configuratie aanpassen

Gewoonlijk is de quorumconfiguratie gemaakt door de wizard Cluster maken of de New-Cluster cmdlet geschikt voor het cluster en hoeft niet te worden aangepast. U kunt echter de quorumconfiguratie, door de wizard Cluster Quorum configureren in het Failover Cluster beheer uit te voeren, of met behulp van de Set-ClusterQuorum-cmdlet in Windows PowerShell. Door deze te gebruiken kunt u een getuige toevoegen of wijzigen en opgeven welke knooppunten stemmen moeten hebben in het quorum.

Als u de wizard Clusterquorum configureren wilt uitvoeren, selecteert u het cluster in Failover-cluster Manager en selecteert u in het deelvenster Acties Meer Acties | Cluster Quorum Instellingen Configureren. Op de pagina Select Quorum Configuration Option, weergegeven in onderstaande afbeelding hebt u de volgende opties.

  • Standaardquorumconfiguratie gebruiken – Hiermee kan de wizard een geschikte quorumconfiguratie voor het cluster configureren zonder handmatige invoer.
  • Selecteer The Quorum Witness – Hiermee kunt u een getuige toevoegen, als er geen getuige is, een bestaande getuige verwijderen en het type en de locatie van de getuige die het quorum moet gebruiken opgeven, zoals weergegeven in onderstaande afbeelding.
  • Geavanceerde quorumconfiguratie – Hiermee kunt u opgeven welke knooppunten stemmen in het quorum moeten hebben, zoals weergegeven in onderstaande afbeelding. Het configureert ook dezelfde getuige instellingen als de optie Selecteer de Quorum Witness.

Om de quorumconfiguratie met Windows PowerShell te configureren gebruik u volgende opdrachten.

Om het quorum te configureren om een knooppunt-meerderheid te gebruiken, zonder getuige:

Set-ClusterQuorum -Cluster cluster1 -NodeMajority

Om het quorum te configureren met stemmen van elk knooppunt en een schijfgetuige:

Set-ClusterQuorum -Cluster cluster1 -NodeAndDiskMajority "clusterschijf 1"

Om een clusterknoop configureren om geen quorumstem te hebben:

(get-clusternode clusternode1).nodeweight=0

Opmerking Clustering Cmdlets uitvoeren

Veel PowerShell-cmdlets in de FailoverClusters-module werken niet goed vanaf een externe locatie. Probeer het indien mogelijk om de cmdlets op een clusterknooppunt uit te voeren.

5.2.2.4 Configureren van een getuige

In de meeste gevallen creëert Failover Clustering een getuige wanneer het cluster een even nummer van knooppunten heeft . Er kan slechts één getuige in een cluster zijn en het wordt aanbevolen dat niet te doen in een situatie waarin het creeëren van een getuige zou leiden tot een even aantal stemmen in de quorum.

Wanneer alle knooppunten in een cluster toegang hebben tot dezelfde gedeelde opslag, dan is een schijf-getuige de aanbevolen configuratie. De pagina Configure Storage Witness in de Configurere Cluster Quorum Wizard, zoals weergegeven in onderstaande afbeedling, kunt u de schijf selecteren dat als getuige zou moeten functioneren. De getuige-schijf mag slechts een kleine hoeveelheid gegevens bevatten, dus moet u voor dit doel een NTFS-schijf van minimaal 512 MB maken.

De opties voor het maken van een file-share-getuige of een cloud-getuige zijn vergelijkbaar, zodat u de locatie voor de getuige kunt opgeven en in het geval van een getuige in de cloud, de naam en de sleutel voor uw Azure-opslagaccount.

5.2.2.5 Quorumstemming wijzigen

In de meeste gevallen moet elk knooppunt in het cluster een stem hebben. Het is mogelijk om een cluster zonder stemknooppunten te configureren met slechts een getuigenstem en dit lijkt in eerste instantie misschien een haalbare optie. Als er een knooppunt beschikbaar is dat toegang heeft tot opslag, kan het cluster worden uitgevoerd. In deze configuratie wordt de getuige echter een enkel punt van mislukking. Als de getuige ontoegankelijk wordt, gaat het cluster neer, zelfs als alle knooppunten en de rest van de opslag functioneel is.

Er zijn situaties waarin u mogelijk de stemmen van specifieke knooppunten van het cluster wilt intrekken. U kunt bijvoorbeeld clusterknooppunten op een externe site hebben die er enkel zijn als back-up, voor handmatige failover in geval van een ramp. Je kunt hun stem intrekken stemmen zodat ze geen deel uitmaken van de quorumberekeningen.

Opmerking Niet-Stemmende knooppunten

Of een node een quorumstemming heeft, heeft geen invloed op de functionaliteit ervan in het cluster. Knopen die niet deelnemen aan het quorum zijn nog steeds volledig actief in het cluster.

5.2.3 Configureer clusternetwerken

De netwerkverbindingen zijn essentieel om de hoge beschikbaarheid van een failover cluster te behouden. Verkeer scheiden in verschillende netwerken en redundante verbindingen bij alle punten in het netwerkpad helpen om de voortdurende functionaliteit van het cluster te garanderen.

Afhankelijk van de rol die door het cluster wordt vervuld, wilt u mogelijk een afzonderlijk netwerk voor elk van het volgende soort verkeer:

  • Client Communications – Clienttoegang tot de toepassing die op het cluster wordt uitgevoerd, is de hoogste prioriteit. Dit is meestal het standaard gedeelde netwerk dat voor andere wordt gebruik client/server-communicatie, maar waar mogelijk worden de andere soorten verkeer vermeld hier moet buiten dit netwerk worden gehouden.
  • Clustercommunicatie – De hartslagen en andere communicatie tussen clusters knooppunten zijn essentieel voor de voortdurende functionaliteit van het cluster.
  • iSCSI – iSCSI en andere Storage Area Network-communicatie moet worden gescheiden van alle andere soorten netwerkverkeer.
  • Live-migratie – Op een Hyper-V-cluster is live-migratie van cruciaal belang voor virtuele machines om te blijven functioneren, en de netwerkprestaties zijn van cruciaal belang voor Live Migratie om efficiënt te kunnen functioneren.

5.2.3.1 Netwerkhardware selecteren

Voor de netwerkhardware moet het doel zijn om zoveel mogelijk redundantie te bieden en om een enkel punt van mislukking te vermijden. Enkele van de aanbevelingen voor hardware-inrichting zijn als volgt:

  • Gebruik afzonderlijke netwerkadapters in plaats van adapters met meerdere interfaces om  de adapterkaart als een enkel storingspunt te vermijden.
  • Gebruik indien mogelijk verschillende merken netwerkadapters om problemen met stuurprogramma’s met betrekking tot meerdere adapters  te voorkomen.
  • Gebruik afzonderlijke fysieke switches in plaats van VLAN’s op één grote switch te configureren, om te voorkomen dat de switch een enkel storingspunt is.
  • Creëer waar mogelijk redundante netwerkverbindingen, vooral voor het client communicatie netwerk.
  • Voor netwerken zonder redundante verbindingen, zoals die voor clustercommunicatie en Live Migration, bied NIC Teaming failover-mogelijkheden in het geval van een netwerkadapter defect.

5.2.3.2 Netwerkstandaarden wijzigen

Wanneer u een cluster maakt, evalueert het systeem elk van de verbonden netwerken en wijst hen deze verkeersrollen toe op basis van de volgende criteria:

  • Elk netwerk met iSCSI-verkeer wordt uitgeschakeld voor clustercommunicatie.
  • Netwerken zonder een standaard gateway-adres worden geconfigureerd voor alleen cluster-communicatie.
  • Netwerken met een standaard gateway-adres worden geconfigureerd voor zowel client als cluster communicatie.

De huidige status van de gedetecteerde netwerken wordt weergegeven op de pagina Netwerken van Failover Cluster Manager, zoals weergegeven in volgende afbeelding, of door het Get-ClusterNetwork PowerShell cmdlet uit te voeren.

Het is mogelijk om de standaard netwerkinstellingen die met het cluster zijn gemaakt, te wijzigen met Failoverclusterbeheer of de Get-ClusterNetwork PowerShell-cmdlet. Om het netwerk in Failover Cluster Manager te configureren, gebruikt u de volgende procedure.

  1. Open Failoverclusterbeheer en blader naar de pagina Netwerken.
  2. Selecteer een netwerk en klik in het deelvenster Acties op Eigenschappen.
  3. Kies uit de volgende opties op het eigenschappenblad zoals weergeven in de volgende afbeelding:
    • Clustercommunicatie op dit Netwerk Toestaan – Hiermee kan het netwerk worden gebruikt voor enkel clustercommunicatie.
    • Toestaan dat Clients Verbinding maken via dit Netwerk – Hiermee wordt het netwerk ingeschakeld gebruikt voor clientcommunicatie, evenals clustercommunicatie.
    • Clustercommunicatie Niet Toestaan op dit Netwerk – Voorkomt dat het netwerk niet kan worden gebruikt voor clustercommunicatie.
  4. Klik Ok

Om deze instellingen in Windows PowerShell te configureren, gebruikt u het Get-ClusterNetwork cmdlet, zoals in het volgende voorbeeld:

(Get-ClusterNetwork "netwerk1").Role = 1

De waarden voor de Role eigenschap zijn als volgt:

  • 0 Uitgeschakeld voor clustercommunicatie
  • 1 Alleen ingeschakeld voor clustercommunicatie
  • 3 Ingeschakeld voor client- en clustercommunicatie

Opmerking Failover-cluster-cmdlets

In veel gevallen zijn de cmdlets in de FailoverClusters PowerShell-module minder intuïtief dan die in andere modules. Zelfs ervaren PowerShell-gebruikers vinden het misschien handiger om Failover Cluster Manager voor veel clusters configuratietaken te gebruiken.

5.2.4 Herstel een enkele knooppunt of clusterconfiguratie

Failover-clusters bieden mogelijk fouttolerantie, maar ontheffen u niet van de noodzaak om een back-up van uw servers te maken. Welke gedeelde opslagoplossing u voor een failover-cluster ook gebruikt, zou u een back-upstrategie moeten hebben, zelfs als deze mirrors redundantie op pariteit gebaseerde gegevens bevat. Het andere probleem met back-ups is echter de clusterconfiguratie zelf.

Windows Server Backup is beperkt in zijn vermogen om back-ups van Cluster Shared Volumes (CSV’s) uit te voeren als onderdeel van de serverback-up, maar het kan een back-up maken van de clusterdatabase, zoals weergegeven in de volgende afbeelding.

De clusterdatabase wordt op elk knooppunt van een cluster opgeslagen, evenals op een schijfgetuige, indien er er een bestaat. De Cluster-service die op elk knooppunt wordt uitgevoerd, is verantwoordelijk dat het toeziet dat de meest recente versie van de clusterdatabase naar elk knooppunt gerepliceerd wordt. Wanneer u een herstelactie vanaf een back-up op een clusterknooppunt uitvoert, moet u overwegen of u een authoratief herstel van de clusterdatabase wil uitvoeren.

Een van de meest waarschijnlijke rampsituaties voor een failover-clusteromgeving is het verlies van een enkel knooppunt. Als één knooppunt uitvalt en de rest van het cluster functioneert, kunt u waarschijnlijk een volledig herstel van dat knooppunt uitvoeren vanaf een back-up. De versie van de clusterdatabase in het back-up zal verouderd zijn en de Cluster-service zal deze overschrijven met de nieuwste versie zodra het knooppunt als onderdeel van het cluster verschijnt. Dit wordt een niet-authoratieve back-up genoemd.

De andere situatie is wanneer u een authoratief herstel van de cluster database wilt uitvoeren, dat wil zeggen dat u wilt dat het cluster de versie van de database uit de back-up gebruikt, niet degene die het momenteel gebruikt. Om dit te doen met Windows Server Backup, moet u het herstel vanaf de opdrachtprompt uitvoeren met behulp van het programma Wbadmin.exe. U kan hiervoor de GUI niet gebruiken.

Wanneer u de volgende Wbadmin-opdracht uitvoert, worden de back-ups weergegeven die beschikbaar zijn voor restauratie. Het resultaat wordt getoond in de volgende afbeelding.

Met behulp van de versie-identificatie die in de lijst is opgegeven, kunt u nu de herstelbare inhoud in de back-up weergeven, inclusief de clusterdatabase, met een opdracht als volgt.

wbadmin get items -version: 11/14/2016:05:09

Om het authoratief herstel uit te voeren, gebruikt u een opdracht als het volgende.

wbadmin start recovery -itemtype:app -items:cluster -version:01/01/2008-00:00

De resultaten, weergegeven in de volgende afbeelding, geven aan dat de database met succes is hersteld  en voorziet het instructies voor het opnieuw opstarten van het cluster.

U kunt de Cluster-service op de andere knooppunten op afstand starten door ze in Failoverclusterbeheer te markeren en in de acties paneel Meer Acties | Start Cluster Service te selecteren.

5.2.5 Configureer de cluster opslag

Om een failover-cluster met een toepassing met hoge beschikbaarheid te laten hosten, moeten alle clusterknooppunten toegang hebben tot de toepassingsgegevens. Daarom moet het cluster een of andere vorm van geddelde opslag hebben. Gedeelde opslag is een vereiste voor de functie Failover Clustering in Windows Server 2016. Voordat u opslag aan het cluster kunt toevoegen, moet u ervoor zorgen dat alle servers die clusterknooppunten worden, toegang hebben tot de opslag met de toepassingsgegevens.

Windows Server 2016 ondersteunt verschillende technologieën voor gedeelde opslag, waaronder:

  • Fibre Channel – Een van de eerste SAN-protocollen (Storage Area Network). Fibre Channel, is een toegewijd glasvezelnetwerk dat, op het moment van de introductie, op hoge snelheden hebben, maar waarvoor gespecialiseerde apparatuur en expertise nodig was, waardoor beide extreem duur waren. Er is nu een Fibre Channel-variant over standaard Ethernet (Fibre Channel over Ethernet of FCoE) loopt, dat goedkoper is, maar nog steeds de esoterische high-end van SAN-technologieën is.
  • Serial Attached SCSI (SAS) – Small Computer System Interface (SCSI) is een busgebaseerde opslagbijlageprotocol dat, in zijn parallelle vorm, ooit de industriestandaard was voor lokale opslag met hoge prestaties. De SAS-variant maakt gebruik van seriële communicatie om de maximale lengte van de bus te vergroten, terwijl er kleinere kabels en connectoren worden gebruikt dan de originele, parallelle apparaten.
  • Internet SCSI (iSCSI) – Een andere variant van het SCSI-protocol dat hetzelfde SCSI-opdrachttaal via een standaard IP-netwerk verzendt. Net als bij SAS duidt iSCSI de opslagapparaten aan als targets en servers en andere apparaten die toegang hebben tot de opslag als initiators. Een server met Windows Server 2016 kan functioneren als zowel een iSCSI target en initiator, waardoor het mogelijk is om een iSCSI SAN volledig in software te implementeren.

Elk van deze technologieën is minder duur dan de voorgaande, iSCSI SAN’s zijn nu realiseerbaar voor weinig meer dan de kosten van een eenvoudige disk-array. Terwijl sommige high-end opslagapparaten verschillende niveaus van intelligentie, fouttolerantie, en hoge beschikbaarheid verzendt, zijn er ook opslagarrays die bekend staan als JBOD’s (Just a Bunch of Disks), wat goedkope apparaten zijn die weinig meer zijn dan standaard harde schijven in een kast met een gemeenschappelijke voeding.

Examen Tip

Met Hyper-V en iSCSI is het mogelijk om een failover-cluster te implementeren op een enkele fysieke server, voor evaluatie-, test- en educatieve doeleinden. De prestatieniveau van het cluster is waarschijnlijk extreem beperkt, maar een arrangement zoals dit stelt u in staat om de Failover Clustering functie van Windows Server 2016 te verkennen.

Nadat u het cluster hebt gemaakt, moeten alle schijven die hiervoor in aanmerking komen, worden weergegeven in het failovercluster Manager. Wanneer u Schijven Toevoegen selecteert op de pagina Opslag\Schijven, zoals weergegeven in onderstaande afbeelding. Zodra u een schijf toevoegt, wordt deze aangeduid als Beschikbare Opslag.

U kunt ook de opslag op de schijven gebruiken om een geclusterde opslagpool te maken. Het proces is als dat van het maken van een pool met behulp van Opslagruimten op een enkele Windows-server, behalve dat de opslag wordt gedeeld door alle knooppunten in het cluster.

Een geclusterde Opslagpool vereist minimaal drie schijven met een capaciteit van minimaal 4 GB elk, die met behulp van SAS of iSCSI verbonden moet worden met alle clusterknooppunten. Om een geclusterde opslagpool te maken, gebruikt u de volgende procedure.

  1. Blader in Failover Cluster Manager naar de Storage\Pools-pagina en klikt u op Nieuwe Opslagpool in het deelvenster Acties om de wizard Nieuwe Opslagpool te starten.
  2. Op de pagina Een naam en Subsysteem voor een Opslagpool Specificeren typt u een naam voor de pool en selecteert u de primordiale pool met de schijven die u wilt gebruiken.
  3. Selecteer op de pagina Fysieke Schijven voor de Opslagpool Selecteren  de gewenste schijven, voeg deze toe aan de pool en specificeer voor elke van deze Automatisch, Hot Spare of Handmatig , zoals weergegeven in de volgende afbeelding.
  4. Klik op Maken.

5.2.6 Implementeer Cluster-Aware updaten

Een van de belangrijkste vereisten voor Failover Clustering in Windows Server 2016 is dat voor alle potentiële clusterknooppunten dezelfde versie van het besturingssysteem wordt uitgevoerd, met allemaal dezelfde updates die op hen zijn toegepast. De wizard Cluster Valideren geeft waarschuwingen wanneer het vaststelt dat de servers die het controleert, niet identiek zijn bijgewerkt. Wat doe u dan om uw knooppunten up-to-date te houden zodra het cluster operationeel is? Cluster Aware Updating (CAU) is een tool die geleverd wordt met Failover Clustering waarmee clusterknooppunten systematisch kunnen worden bijgewerkt met een minimum aan uitvaltijd.

CAU past updates toe op een cluster op een round-robin-manier, een zogenaamde Updating Run, met behulp van de volgende procedure:

  1. Selecteert een knooppunt om bij te werken.
  2. Verplaatst bestaande rollen van het geselecteerde knooppunt naar andere knooppunten in het cluster met behulp van Live-migratie of andere technieken die onderbrekingen van de client services tot een minimum beperken.
  3. Plaatst het geselecteerde knooppunt in de knooppuntonderhoudsmodus.
  4. Installeert de vereiste updates op het geselecteerde knooppunt en start het indien nodig opnieuw op.
  5. Haalt het geselecteerde knooppunt uit de onderhoudsmodus.
  6. Gaat verder naar het volgende knooppunt in het cluster en herhaalt de procedure.

Op deze manier wordt elk knooppunt op zijn beurt tijdelijk uit dienst genomen en bijgewerkt, totdat het op het hele cluster dezelfde updates zijn toegepast.

CAU heeft een computer nodig om te functioneren als de updatecoördinator, die de update activiteiten voor het cluster leidt. De vraag welke computer deze functie uitvoert, is het primair onderscheid tussen de twee bedrijfsmodi van de CAU:

  • Zelf-updatemodus – In deze modus heeft een van de clusterknooppunten de CAU geclusterd rol geïnstalleerd, waardoor het kan functioneren als de updatecoördinator. De update Coördinatorknooppunt voert Updating-runs uit volgens een schema dat is geconfigureerd door een beheerder, waardoor updates op elk van de andere knooppunten worden geactiveerd. Wanneer alle andere knooppunten zijn bijgewerkt, faalt de CAU-rol op de Update-coördinator naar een ander knooppunt, waardoor het de rol van updatecoördinator kan aannemen. De originele coördinator kan dan zelf worden bijgewerkt. In deze modus is het volledige updateproces automatisch uitgevoerd.
  • Modus voor extern updaten – In deze modus wordt een computer buiten het cluster geconfigureerd om te functioneren als de Update Coördinator. Vanaf deze computer kan een beheerder handmatig een update-run op het cluster activeren. De Update Coordinator-computer is zelf niet bijgewerkt, en het proces kan niet worden geautomatiseerd.

Om CAU in zelf-updatemodus te gebruiken, moet elk knooppunt in het cluster de Failover hebben Clustering tools geïnstalleerd. De hulpprogramma’s worden standaard geïnstalleerd wanneer u de failover Clustering-functie toevoegt met behulp van Server Manager. Als u de functie echter installeert met PowerShell, moet u de parameter includeManagementTools toevoegen aan de Install-WindowsFeature-opdracht.

Voor de updatemodus op afstand moet de updatecoördinator de failoverclustering hebben tools geïnstalleerd, maar de functie Failover Clustering is niet vereist. De tools zelf bevinden zich onder Hulpprogramma’s voor extern serverbeheer in de wizard Rollen en Onderdelen Toevoegen. Ze staan bekend als RSAT-Clustering in Windows PowerShell.

De CAU-tools bevatten een Cluster-Aware Updating-console, zoals weergegeven in volgende afbeelding, en een ClusterAwareUpdating-module voor Windows PowerShell, die cmdlets voor het beheren van de service.

Er zijn nog andere voorwaarden voor het gebruik van CAU, waarvan de meeste al vervuld zijn in een correct geïnstalleerd Windows Server 2016-failovercluster. Het klikken van Analyseer Cluster Gereedheid Bijwerken in de lijst met clusteracties van de console of de Test-CauSetup cmdlet in PowerShell op een clusterknooppunt voert een reeks tests uit die de gereedheid voor het hele cluster bepaalt, zoals weergegeven in volgende figuur.

Als u de modus voor zelf bijwerken wilt gebruiken, installeert u het CAU-geclusterde rol door te klikken op Configureer Cluster Self-Updating Options in de console. Hierdoor wordt de wizard Opties voor Zelfupdate Configureren gestart, die de geclusterde rol toevoegt en een schema voor de zelfupdates maakt, zoals weergegeven in de volgende afbeelding. U kan ook geavanceerde update-opties configureren, zoals het maximum aantal toegestane nieuwe pogingen per knooppunt en de volgorde waarin knooppunten moeten worden bijgewerkt. U kunt deze dingen ook doen met de Add-CauClusterRole cmdlet in PowerShell, zoals in het volgende voorbeeld:

Add-CauClusterrole -Clustername "cluster1" -Daysofweek sunday -Weeksinterval 3 -Maxretriesperiode -Nodeorder node2, node1, node3

Zodra het schema is ingesteld, kunt u wachten tot het wordt uitgevoerd of een update-run uitvoeren onmiddellijk, zoals weergegeven in de volgende afbeelding, door te klikken op Updates toepassen op dit cluster of wordt uitgevoerd de Invoke-CauRun cmdlet.

5.2.7 Implementeer Cluster besturingssysteem rolling upgrade

Voorafgaand aan Windows Server 2016, vereiste het upgraden van het besturingssysteem op een failover-cluster dat u het hele cluster offline haalde, u het nieuwe besturingssysteem op alle knooppunten installeerde en in wezen het cluster helemaal opnieuw opbouwde. Vanaf Windows Server 2016 wordt een techniek ondersteunt genaamd Cluster Operating System Rolling Upgrade die het mogelijk maakt om een Hyper-V- of Scale-Out File Server-cluster te upgraden vanaf Windows Server 2012 R2 naar Windows Server 2016 zonder het cluster omlaag te halen.

Clusterbesturingssysteem Rolling Upgrade is geen tool of wizard, er is geen geautomatiseerd proces voor het upgraden van het cluster. Het is eerder een techniek waarbij je elk clusterknooppunt op zijn beurt neerhaalt, een schone upgrade van het besturingssysteem uitvoert en het weer aan het cluster toevoegt. De functie die dit mogelijk maakt, is een nieuwe operationele modus voor Failover Clustering genaamd mixed-OS-modus. In tegenstelling tot clusters in eerdere Windows-versies, is mogelijk dat een cluster tijdelijk met knooppunten die op een andere systeemversies werken, met name Windows Server 2012 R2 en Windows Server 2016.

Het proces voor het upgraden van elk Windows Server 2012 R2-knooppunt in het cluster is als volgt:

  1. Pauzeer het knooppunt.
  2. Maak het knooppunt leeg door de werklast naar de andere knooppunten te migreren.
  3. Verwijder het knooppunt uit het cluster.
  4. Formatteer het systeemstation opnieuw en voer een schone installatie uit van Windows Server 2016.
  5. Configureer netwerk- en opslagverbindingen.
  6. Installeer de functie Failover Clustering.
  7. Voeg het nieuw geïnstalleerde knooppunt weer toe aan het cluster.
  8. Implementeer de clusterwerkbelasting opnieuw.

Wanneer een nieuw geïnstalleerd Windows Server 2016-knooppunt weer aan het cluster wordt toegevoegd, draait het in een compatibiliteitsmodus waardoor het kan samenwerken met de overige Windows Server 2012 R2-knooppunten. Het cluster blijft werken op het Windows Server 2012 R2 functioneel niveau totdat alle knooppunten zijn geüpgraded. Eender welke nieuwe failoverclustering functie van Windows Server 2016 is niet beschikbaar. Tijdens deze hele periode, die dagen of weken kan duren, kan het hele proces indien nodig ongedaan worden gemaakt. U kunt Windows Server 2012 R2 opnieuw op uw knooppunten installeren en het cluster indien nodig terugbrengen naar de oorspronkelijke staat.

Opmerking De upgrades voltooien

Microsoft raadt aan om alle knooppunten in een cluster binnen een maand te upgraden. Mixed-OS-modus is niet bedoeld als een permanente oplossing voor een failover-cluster.

Wanneer de upgrades op alle knooppunten zijn voltooid, rondt u het proces af door het uitvoeren van de cmdlet Update-ClusterFunctionalLevel. Dit is een ‘point of no return’, wanneer het functionele niveau permanent verhoogd is naar Windows Server 2016. Op dit punt zijn de nieuwe functies beschikbaar en er is geen terugkeer meer mogelijk naar de vorige versie.

5.2.8 Configureer en optimaliseer geclusterde gedeelde volumes (CSV’s)

Als u voorwaarde voor gedeelde opslag voor failoverclustering overweegt, bent u aan het praten over delen op hardwareniveau. Elk knooppunt in het cluster kan de gedeelde schijven zien, maar het gebruik ervan is een ander probleem. U kunt schijven aan een cluster toevoegen in Failover Cluster Manager, of door de cmdlet Add-ClusterDisk te gebruiken en worden ze weergegeven als Beschikbare opslag, als Clusterschijf 4 en Clusterschijf 5, weergegeven in onderstaande afbeelding.

Deze twee schijven hebben een knooppunt (SVR-11) dat vermeld wordt als hun aangewezen eigenaar. Als je naar  dat knooppunt toegaat en de module Schijfbeheer opent, verschijnen die schijven met stationsletters en volumenamen, gezond en klaar voor gebruik, zoals weergegeven in onderstaande afbeelding.

Als u naar een ander knooppunt gaat en dezelfde module opent, hebben diezelfde twee schijven geen station letters en de status Gereserveerd, zoals weergegeven in de volgende afbeelding. Als u ze online probeert te brengen, dat kan je dit niet. Als dit gedeelde opslag zou moeten zijn, waarom zijn deze schijven dan niet toegankelijk op beide knooppunten?

Het probleem is niet iSCSI, of welk gedeeld opslagprotocol u ook op uw SAN gebruikt, maar het bestandssysteem. NTFS is niet ontworpen om te worden geopend en gebruikt door meer dan één besturingssysteeminstantie tegelijk. Die twee schijven zijn aangekoppeld op het eigenaarsknooppunt, en daar zijn ze ook bruikbaar. Om ze op een ander knooppunt te gebruiken, moet u ze op de knooppunt ontkoppelen en opnieuw koppelen op de nieuwe. Dit is mogelijk; maar het kost tijd.

In de originele versie van Hyper-V in Windows Server 2008, was dit ontkoppelen en de vertraging bij het opnieuw koppelen het grootste obstakel voor een efficiënt gebruik van virtuele machines in een cluster. Bovendien kan slechts één knooppunt tegelijk toegang krijgen tot een schijf. Als u een VM naar een andere server wilde migreren, moest u ook alle andere VM’s migreren die dezelfde schijf gebruikten.

De oplossing voor dit probleem zijn gedeelde clustervolumes (CSV’s). Cluster gedeelde volumes creëeren in wezen een pseudo-bestandssysteem is (genaamd CSVFS) dat gelaagd is bovenop het NTFS-bestandssysteem. Het probleem met meerdere knooppunten die tegelijkertijd toegang hebben tot een NTFS-station is toegang tot de metadata die de structuur van de schijf en de bestanden besturen erop opslaan. Wanneer twee systemen die metadata tegelijkertijd proberen te wijzigen, doet corruptie zich voor en gaan gegevens verloren. CSVFS is in wezen een filter waarmee meerdere knooppunten data-I/O-bewerkingen op de schijf kunnen uitvoeren, maar beperkt de toegang tot metagegevens tot de aangewezen eigenaar (ook bekend als de coördinator).

U kunt dit zien door naar CSV’s te kijken in de module Schijfbeheer, zoals u eerder deed met beschikbare opslagschijven. Op het eigenaarknooppunt, weergegeven in onderstaande afbeelding, wordt de iscsi3-schijf weergegeven als gebruikmakend van het CSVFS-bestandssysteem, en het contextmenu toont de gebruikelijke bedieningselementen voor het volume formatteren, verkleinen en verwijderen.

Op een ander knooppunt, niet de eigenaar, weergegeven in volgende afbeelding, ziet dezelfde iscsi3-schijf eruit even toegankelijk, met hetzelfde CSVFS-bestandssysteem, maar het contextmenu is volledig grijs weergegeven. Dit komt doordat die opdrachten voor het opmaken, verkleinen en verwijderen van de volume zijn de taak is van de metadata, en enkel de eigenaar heeft daar toegang toe.

5.2.8.1 Schijven toevoegen aan CSV’s

Failover Clustering in Windows Server 2016 bevat standaard ondersteuning voor CSV’s. Wanneer u een schijf aan een cluster toevoegt, wordt deze in Failoverclusterbeheer weergegeven als Beschikbare opslag.

U kunt vervolgens een beschikbare opslagschijf selecteren en in het deelvenster Acties op Toevoegen aan klikken Cluster gedeelde volumes.

Gebruik de Add-ClusterSharedVolume om beschikbare opslag toe te voegen aan een CSV met PowerShell cmdlet, zoals in het volgende voorbeeld:

Add-ClusterSharedVolume -Name "cluster disk 5"

Zodra u dit doet, wordt de CSV op alle cluster knooppunten gekoppeld in de map C:\ClusterStorage. U kunt ook in de module Schijfbeheer zien dat de schijf nu op alle knooppunten van het cluster beschikbaar is. U kunt ook de CSV in Failover Cluster Manager selecteren en klikken op Verplaatsen | Best Mogelijke Knoop. Kijk hoe het eigendom van de CSV in een kwestie van seconden van eigenaar verandert. Dit is wat het mogelijk maakt dat Hyper-V Live-migraties zo snel plaatsvinden. Vóór CSV’s was het ontkoppelen en opnieuw koppelen van NTFS-schijven de bottleneck in het proces.

5.2.8.2 CSV’s optimaliseren

CSV’s bevatten een cache die ontworpen is om de prestaties van leesintensieve I/O operaties te verbeteren. De cache gebruikt een hoeveelheid ysteemgeheugen die u opgeeft als write-through cache, wat ten goede kan komen aan clusters met de Hyper-V- en Scale-Out File Server-rollen.

In Windows Server 2016 Failover Clustering bestaat de cache als standaard, maar de standaard cachegrootte is 0, waardoor deze effectief is uitgeschakeld. De maximale grootte van de cache is 80% van het systeemgeheugen. Om de CSV-cache in te schakelen, moet u er een hoeveelheid geheugen voor specificeren, in megabytes, met behulp van de volgende PowerShell-opdracht:

(Get-Cluster).Blockcachesize = 512

5.2.9 Configureer clusters zonder netwerknamen

Failover-clusters vertrouwen op Active Directory Domain Services voor verificatie en naamgevings diensten. Door een cluster te maken, maakt AD DS standaard een computerobject met de naam een clusternaamobject (CNO), om het cluster zelf te vertegenwoordigen. Dit is het cluster administratief toegangspunt. Sommige geclusterde toepassingen maken ook AD Ds-objecten, voorstellend als clienttoegangspunten, zogenaamde virtuele computerobjecten (VCO’s).

Het is echter mogelijk om een cluster te maken die deze AD DS-objecten niet gebruiken, hoewel de clusterknooppunten zelf lid zijn van een domein. Dit wordt een Active Directory losgekoppeld cluster genoemd. Omdat er geen objecten zijn gemaakt in Active Directory, is dit niet het geval nodig voor de persoon die het cluster maakt om de benodigde machtigingen te hebben om objecten te maken of de computerobjecten te laten voorbereiden in AD DS.

In een cluster dat is losgekoppeld van Active Directory, zijn de naam van het cluster en eventuele namen die voor clienttoegangspunten geregistreerd in de DNS in plaats van in Active Directory. Echter moeten de knooppunten nog steeds lid zijn van een AD DS-domein en het cluster gebruikt nog steeds Kerberos voor het authenticeren van clustercommunicatie tussen de knooppunten. Verificatie voor de clusternaam gebruikt NTLM.

Vanwege deze wijzigingen zullen sommige applicaties niet correct werken wanneer u ze implementeert ze op een cluster dat losgekoppeld is van Active Directory. Hyper-V vertrouwt bijvoorbeeld op Kerberos authenticatie voor Live Migration, dus is het geen geschikte kandidaat voor dit type cluster.

U kunt BitLocker-stationsversleuteling of Cluster-Aware Updating ook niet gebruiken bij de zelfupdates modus. Microsoft SQL Server heeft zijn eigen interne authenticatiemechanisme, waardoor het echter correct kan functioneren op een cluster dat is losgekoppeld van Active Directory.

Als u een cluster wilt maken dat is losgekoppeld van Active Directory, moet u het New-Cluster PowerShell-cmdlet gebruiken en de parameter AdministrativeAccessPoint opgeven, waarbij u een waarde van DNS in plaats van de standaard ActiveDirectoryAndDns-waarde, zoals in het volgende voorbeeld:

New-Cluster cluster1 -node node1, node2 -staticaddress 10.0.0.1 -nostarage - administrativeaccesspoint dns

Deze parameterinstelling zorgt ervoor dat de cmdlet de netwerknaam van het cluster en de netwerknamen op alle geclusterde rollen maakt die u later installeert, in DNS in plaats van in Active Directory.

Let op Clusters zonder naam

Het is ook mogelijk om een cluster te maken zonder beheerderstoegangspunt door de waarde None op te geven voor AdministrativeAccessPoint parameter in de opdracht New-Cluster. Als u dit echter doet, kunt u geen gebruik maken van de Failover Cluster Manager om het cluster te beheren en de functionaliteit van sommige clusterrollen zijn mogelijk aangetast.

5.2.10 Implementeer Scale-Out bestandsserver (SoFS)

Scale-out File Server is een geclusterde rol die ontworpen is om hoge opslagbeschikbaarheid te bieden voor applicaties, zoals Hyper-V en SQL Server. In tegenstelling tot een bestandsserver, bedoeld voor algemeen gebruik, maakt een SoFS shares die toegankelijk zijn op alle clusterknooppunten op het hetzelfde moment. Dit staat bekend als een actief/actief (of duaal actief) systeem, in tegenstelling tot een actief/passief systeem, waarbij één knooppunt toegankelijke shares biedt en de andere blijven slapen totdat er een failover optreedt.

Een SoFS zorgt voor de continue beschikbaarheid van data voor applicaties die continuïteit nodig hebben. Wanneer een knooppunt uitvalt, als gevolg van een hardwarefout, een onderhoudscyclus of een of andere reden blijven de gegevens beschikbaar via de shares op de andere knooppunten. Zelfs als een knooppunt de toegang tot het SAN verliest, kan CSV het I/O-verkeer via het netwerk naar een ander knooppunt omleiden.

Opmerking Cluster Network Metrics

Een cluster wijst metrische waarden toe aan de beschikbare netwerken, op basis van hun snelheden en andere kenmerken, zoals aangetoond door het Get-ClusterNetwork commando in Afbeelding 5-36. CSV gebruikt het netwerk met de laagste metrische waarde voor zijn omleidingsverkeer. In sommige situaties kan het nodig zijn om de metrics aan te passen, om ervoor te zorgen dat het CSV-omleidingsverkeer voor een SoFS een specifiek netwerk gebruikt. Om de netwerkstatistieken handmatig te wijzigen, gebruikt u de volgende opdracht:

(Get-ClusterNetwork -Name "cluster network 3").metric = 30000

SoFS verhoogt ook de efficiëntie van het cluster door de gecombineerde bandbreedte van alle knooppunten voor het I/O bestandssysteem  te gebruiken. Om de beschikbare bandbreedte te vergroten, kunnen beheerders meer knooppunten aan het cluster toevoegen. Ten slotte brengt SoFS verbindingen automatisch opnieuw in evenwicht om ervoor te zorgen dat elke cliënt wordt omgeleid naar het knooppunt met de beste toegang tot de gevraagde gegevens.

De vereisten voor het maken van een scale-out bestandsserver zijn in wezen dezelfde als die voor Failover Clustering. De hardwareconfiguratie van de clusterknooppunten moet zijn als vrijwel identiek mogelijk, en alle knooppunten zouden toegang moeten hebben tot gedeelde opslag met behulp van iSCSI, SAS, Fibre Channel of een vergelijkbare technologie. Omdat SoFS een geclusterde rol is, moet u installeer de functie Failover Clustering op al uw knooppunten en maak het cluster voor u kan SoFS installeren. U moet ook uw beschikbare opslagruimte toewijzen als gedeelde clustervolumes, aangezien deze vereist zijn voor een scale-out bestandsserver.

Zodra het cluster op zijn plaats en operationeel is, installeert u SoFS met behulp van het volgende procedure.

  1. Open Failoverclusterbeheer en selecteer de pagina Rollen.
  2. Klik op Rol configureren om de wizard Hoge Beschikbaarheid te starten.
  3. Selecteer op de pagina Type Bestandsserver de Scale-Out Bestandsserver voor Toepassingsgegevens optie, zoals weergegeven in onderaande afbeelding.
  4. Geef op de pagina Clienttoegangspunt een naam op die clients zullen gebruiken om toegang te krijgen tot de rol. De wizard maakt een AD DS-computerobject met deze naam.
  5. Klik op Voltooien. De Scale-out File Server wordt weergegeven op de pagina Rollen.

Opmerking PowerShell gebruiken

Om de Scale-out File Server-rol met Windows PowerShell te installeren, voert u de cmdlet Add-ClusterScaleOutFileServer zonder parameters.

Met de Scale-out File Server-rol geïnstalleerd, kunt u doorgaan met het maken van een bestandsshare, met behulp van de volgende procedure.

  1. Selecteer in Failoverclusterbeheer op de pagina Rollen de rol Bestandsserver uitschalen die u zojuist hebt gemaakt en selecteer in het deelvenster Acties Bestandsshare toevoegen om het nieuwe Deel Wizard.
  2. Selecteer op de pagina Selecteer het profiel voor deze Share de optie SMB Share – Toepassingen
  3. Merk op dat ondanks de gelijkenis van deze wizard met de New Share Wizard in Server Manager, moet u Failover Cluster Manager of de New-SmbShare cmdlet gebruiken om SoFS-bestandsshares maken.
  4. Selecteer op de pagina Selecteer de Server en het Pad voor deze Gedeelde Map de Scale-Out bestandsserverrol die u hebt gemaakt, zoals weergegeven in volgende afbeelding.
  5. Selecteer in het vak Gedeelde Map ocatie een gedeeld clustervolume.
  6. Typ op de pagina Share-naam opgeven een naam en optioneel een beschrijving voor het delen.
  7. Zorg ervoor dat op de pagina Share-instellingen configureren de optie Continu Beschikbaar Inschakelen is geselecteerd en dat het op toegang gebaseerde inventarisatie inschakelen selectievakje is uitgeschakeld.
  8. Klik op de pagina Machtigingen voor toegangscontrole opgeven op Machtigingen aanpassen en zorg ervoor dat de AD DS-computerobjecten voor het cluster en de knooppunten de SoFS-share gebruiken en dat die allemaal de machtiging Volledig beheer hebben.
  9. Klik op Maken.

Om een SoFS-share met PowerShell te maken, gebruikt u de cmdlet New-SmbShare om gedeelde map te maken, zoals in het volgende voorbeeld. De cmdlet Set-SmbPathAcl configureert de bestand-systeemmachtigingen van de map die overeenkomt met die van de gedeelde map.

New-Smbshare -Name share1 -Path c:\clusterstorsge\volume1 -Fullaccess adatum\cluster1, adatum\node1, adatum\node2 -continiuouslyavailable
Set-Smbpathacl -Sharename share1

5.2.11 Bepaal verschillende scenario’s voor het gebruik van SoFS vs. Geclusterde bestandsserver

Op de pagina Type bestandsserver in de wizard Hoge Beschikbaarheid kunt u kiezen tussen de standaard bestandsserverclusterrol, bedoeld voor algemeen gebruik, en de scale-out bestandsserver rol, die bedoeld is voor gebruik door geclusterde applicaties. In sommige gevallen is dit misschien niet zo duidelijk welke de beste keuze is voor een bepaalde werklast.

SoFS-shares bevinden zich op gedeelde clustervolumes en de onderliggende aard van CSV’s bepaalt grotendeels welke rollen en applicaties het meest geschikt zijn voor een scale-out bestandsserver. SoFS stelt zijn shares beschikbaar op alle knooppunten van het cluster, wat betekent dat elk knooppunt lees- en schrijfverzoeken op de schijf kan verwerken. Het onderliggende CSVFS-bestandssysteem vereist is echter nog steeds de schijfcoördinator (dat wil zeggen, het knooppunt dat de schijf bezit) om alle metagegevens  geralateerde activiteiten uit te voeren. Dit betekent dat alle verzoeken om bestanden te openen, sluiten, maken en hernoemen op een SoFS-share, ongeacht welk knooppunt ze ontvangt, moet worden doorgestuurd naar het coördinator knooppunt.

Dit maakt het gemakkelijker om te begrijpen waarom de SoFS-rol specifiek wordt aanbevolen voor gebruik op Hyper-V- en SQL Server-clusters. Beide applicaties openen routinematig groot aantal bestanden,  VHD’s en databases en laat ze gedurende lange tijd open staan. Metadata verzoeken zijn zeldzaam in dit type applicatie, waardoor de last voor de coördinator van het schijf knooppunt geminimaliseerd blijft.

Voor veel andere toepassingen, inclusief de algemene bestandsserveractiviteiten uitgevoerd door typische gebruikers en beheerders, kan de belasting van het schijfcoördinatorknooppunt een bottleneck worden. Dit komt doordat er veel meer verzoeken zijn waarvoor toegang tot de metagegevens van het bestandssysteem vereist is, inclusief algemene beheerdersactiviteiten van de bestandsserver, zoals het wijzigen van NTFS-machtigingen en andere bestandssysteemkenmerken.

De continue beschikbaarheid van SoFS-shares kan ook de algehele prestaties van een bestandsserver beïnvloeden. Om de integriteit van de gegevens te waarborgen, worden schrijfverzoeken rechtstreeks naar de schijf gestuurd in plaatst van in het cachegeheugen van het knooppunt te plaatsen. Op deze manier is er minder kans dat er gegevens door cachefout. verloren gaan als een knooppunt uitvalt.

Daarom moet u rekening houden met de aard van de werklast van uw cluster voordat u een beslissing neemt welke optie u moet selecteren op de pagina Type bestandsserver. Hoe groter het aandeel van het bestand management die de aanvraag genereert, hoe kleiner de kans dat het een geschikte kandidaat is voor een scale-out bestandsserver.

5.2.12 Bepaal gebruiksscenario’s voor  de implementatie van gast clustering

Een guest-failovercluster is een cluster dat uitsluitend bestaat uit virtuele machines die op een enkele Hyper-V-hostserver draait. U kunt twee of meer identieke VM’s maken en op alle de failover cluster-functie installeren en er een cluster van maken, net alsof ze fysieke computers waren. In feite heeft u met een guest cluster minder kans op clustervalidatieproblemen, omdat de (virtuele) hardwareconfiguratie van elke node identiek is. Voor de gedeelde opslag die een gastcluster nodig heeft, kunt u elk van de standaard netwerk opslaggebied technologiën gebruiken, zoals Fibre Channel, SAS of iSCSI, als pass-through-schijven.

Het bouwen van een gastcluster is een geweldige manier om meer te weten te komen over Failover Clustering en een handig tool voor het evalueren van geclusterde applicaties, zonder dat er veel hardware moet worden geïnvesteerd. Voor onderwijs- en testdoeleinden kunt u een gastcluster maken met een gevirtualiseerde SAN, door de iSCSI-doelmogelijkheid in Windows Server 2016 te gebruiken om een virtuele harde schijf te koppelen, waartoe uw VM’s toegang hebben met behulp van de iSCSI-initiator. Prestatieniveaus zullen waarschijnlijk niet geschikt zijn voor productietoepassingen, maar het cluster zal functioneren.

Bovendien kunt u met de geneste virtualisatiemogelijkheden die zijn ingebouwd in Windows Server 2016, zelfs een gastcluster maken door Hyper-V op een enkele virtuele machine te installeren en geneste VM’s clusteren.

Gastclusters hebben ook praktische functies, waaronder de volgende:

  • Knooppuntbewaking – Clusters kunnen bronnen bewaken, zoals het opslagsubsysteem, het netwerkconnectiviteit, en de geclusterde applicatie zelf, en neemt automatisch actie wanneer zich een probleem voordoet, door de rol naar een ander knooppunt te migreren of er een failover uit te voeren.
  • Applicatiemigratie – Door een applicatie te implementeren als een rol op een gastcluster, kunt u kan de beschikbaarheid behouden door de applicatie naar verschillende knooppunten in het cluster te migreren. Bijvoorbeeld, in plaats van een applicatie op een enkele netwerkserver te implementeren, kunt u kan de server configureren als een Hyper-V-host en een cluster maken waar de toepassing draait. Op die manier kan als de VM faalt of als onderhoud vereist is de applicatie overschakelen naar een ander knooppunt.
  • Hostbeschikbaarheid – U kunt een gastcluster maken van virtuele machines die zich op verschillende Hyper-V-hosts bevinden. Als een host een storing ondervindt, zullen de knooppunten op andere hosts de afwezigheid van hun VM’s detecteren en de geclusterde applicaties daar online brengen.
  • VM-migratie – Als u meerdere Hyper-V-hosts beschikbaar heeft, kunt u machines tussen hosts virtueel migreren om zo nodig onderhoudstaken op de host uit te voeren waarvoor het nodig deze tijdelijk offline te halen.
  • Geneste clustering – Het is mogelijk om een ‘gastcluster binnen een cluster’ te maken, door het samenvoegen van twee of meer fysieke servers in een Hyper-V-cluster en vervolgens het gastclusteren van virtuele machines die op de Hyper-V-hostknooppunten draaien. Hierdoor kan het systeem automatisch reageren op het falen van een Hyper-V-host door zijn virtuele machines te migreren naar de andere gastheren; of het falen van een VM, door de geclusterde applicaties te migreren.

5.2.13 Implementeer geclusterde Storage Spaces met behulp van gedeelde SAS opslag enclosures

Storage Spaces is de Windows Server 2016-tool die u toelaat gegevensopslag toe te voegen die door meerdere fysieke schijven aan een opslagpool wordt geleverd. U kunt dan gebruik maken van de opslag in de pool om virtuele schijven van elke grootte te maken, ongeacht de grenzen tussen de fysieke schijven. Door Storage Spaces te combineren met Failover Clustering, kunt u een oplossing creëren die zeer beschikbaar en bestand zijn tegen zowel harde schijf- als serverstoringen. Deze oplossing is algemeen bekend als geclusterde opslagruimten.

Een Clustered Storage Spaces-oplossing begint met een of meer Serial-Attached SCSI (SAS) disk-arrays, simple just-a-bunch-of-disks (JBOD) behuizingen die geen extra functies bieden, zoals Redundant Array of Independent Disks (RAID). In een Storeage Spaces implementatie, wordt datafouttolerantie geboden in de software; deze functies wilt u niet dupliceren in de hardware. Als de disk-arrays deze functies bevatten, moet u ze uitschakelen om de schijven met opslagruimten te kunnen gebruiken.

Storage Spaces bieden data-veerkracht in de vorm van data-mirroring, waarbij twee of drie exemplaren van alle bestanden naar verschillende schijven worden geschreven; of pariteit, een bit-level techniek, die de mogelijkheid biedt om te herstellen van een schijfstoring door de verloren gegevens te reconstrueren met pariteitsbits.

Het tweede element van de oplossing is het failover-cluster, meestal een groep van twee tot vier servers die met redundante hardware op de schijfbehuizingen zijn aangesloten. Om een echt betrouwbare oplossing voor bedrijfsproductiviteit te maken, moet er hardware-redundantie zijn op alle niveaus, inclusief meerdere hostbusadapters in elke server, redundante voedingen in de schijfbehuizingen, en zelfs overtollige schijfbehuizingen.

Met de hardware op zijn plaats, bestaat de rest van de oplossing uit een opslagpool die redundante gegevensopslag biedt, de failover-cluster die redundante servers biedt, Cluster Shared Volumes, die een uniforme naamruimte bieden in het hele cluster, en in hoge mate beschikbare bestandsshares, waarmee gebruikers toegang krijgen tot de gegevens. De hele oplossing wordt getoond in volgende figuur.

Zodra de hardwarecomponenten aanwezig zijn en u Windows Server 2016 op alle servers geïnstalleerd hebt moet u bevestigen dat de opslag toegankelijk is vanaf alle servers. Vervolgens kunt u op twee manieren doorgaan met het bouwen van een Clustered Storage Spaces-oplossing:

  • Storage Pool First – Als u een bestaande opslagpool heeft, of als u een cluster helemaal opnieuw, kunt u de opslagpool maken met Server Manager of het New-StoragePool cmdlet voordat u het cluster maakt. Zodra u het cluster, zal de opslagpool ervoor beschikbaar zijn.
  • Failover Cluster First – Als u een bestaand cluster heeft, kunt u de opslagpool maken in Failover Cluster Manager.

Gebruik de volgende procedure om geclusterde opslagruimten in een bestaand cluster met Failover Cluster Manager te maken.

  1. Selecteer in Failoverclusterbeheer Opslag | Pools, om de Pools-pagina weer te geven.
  2. Klik op Opslagpool toevoegen om de wizard Nieuwe opslagpool te starten.
  3. Geef op de pagina Geef een naam en Subsysteem voor een Opslagpool op een naam op voor de pool en selecteer de primordiale pool met schijven die u wilt toevoegen.
  4. Schakel op de pagina Fysieke schijven Selecteren voor de Opslagpool de selectievakjes in voor de schijven die u aan de pool wilt toevoegen. Om een geclusterde opslagpool te maken, moet u minimaal drie schijven selecteren; voor driewegspiegeling moet u minimaal vijf schijven selecteren.
  5. Klik op Maken.
  6. Selecteer op de pagina Resultaten bekijken het selectievakje Een Virtuele Schijf maken Wanneer deze Wizard Sluit en klik op Sluiten. De wizard Nieuwe Virtuele Schijf wordt weergegeven.
  7. Selecteer op de pagina Selecteer de Opslagpool de pool die u zojuist hebt gemaakt.
  8. Typ op de pagina Geef de Naam van de Virtuele Schijf een naam voor de schijf.
  9. Selecteer op de pagina Selecteer de Opslaglay-out de optie Eenvoudig, Spiegel of Pariteit. Als u Mirror selecteert, en er vijf schijven in de pool zijn , verschijnt een pagina Configure The Resiliency Settings die u vraagt om Two-Way Mirror of Three-Way Mirror te kiezen.
  10. Typ op de pagina De Grootte van de Virtuele Schijf opgeven een grootte in MB, GB of TB, of schakel het selectievakje Maximale Grootte in.
  11. Klik op Maken.
  12. Selecteer op de pagina Resultaten Bekijken het selectievakje Een Volume maken wanneer deze Wizard wordt gesloten en klik op Sluiten. De wizard Nieuw Volume wordt weergegeven.
  13. Selecteer op de pagina De Server en Schijf Selecteren uw cluster en de virtuele schijf die u gebruikt zojuist gemaakt.
  14. Typ op de pagina De Grootte van het Volume opgeven een volumegrootte.
  15. Selecteer op de pagina Toewijzen aan een Stationsletter of Map een stationsletter of een map waar u het volume wilt monteren.
  16. Selecteer op de pagina Bestandssysteeminstellingen Selecteren het NTFS- of ReFS-bestandssysteem, specificeer een Allocation Unit Size, en typ een volumelabel.
  17. Klik op Maken. Klik vervolgens op Sluiten.

De veerkrachtige opslag voor het cluster is nu beschikbaar. U kunt er CSV’s van maken om er hoog beschikbare shares van te maken met behulp van één uniforme naamruimte.

5.2.14 Implementeer Opslag Replica

Storage Replica is een functie van Windows Server 2016 waarmee u volumes synchroon of asynchroon kunt repliceren, voor rampenparaatheid en herstel. U kan replicaties uitvoeren tussen opslagapparaten die zich op dezelfde computer bevinden, in het hetzelfde datacenter, of in remote sites.

Met Storage Replica kunt u een stretch-cluster maken, een cluster dat is gesplitst tussen twee of meer sites, zonder gedeelde opslag die de sites met elkaar verbindt. Bijvoorbeeld, misschien heeft u een cluster met vier knooppunten met één gegevensset, maar twee van de knooppunten bevinden zich in het New York bijkantoor en twee zijn in het hoofdkantoor van San Francisco. Het idee is dat de knooppunten in de site in New York functioneert als een failover-back-up, mocht het kantoor in San Francisco een ramp ondervinden.

Elke site heeft gedeelde opslag voor zijn twee knooppunten, maar ze hebben geen toegang tot de opslag op de tegenoverliggende locaties. Dit wordt asymmetrische opslag genoemd. Echter, voor de twee sites om te functioneren als een echt failover-cluster, moeten ze dezelfde gegevens hebben. Opslagreplica kan de gegevens repliceren tussen de twee sites, synchroon of asynchroon.

Meer informatie over Opslagreplica

Voor meer informatie over het implementeren van Storage Replica in een cluster omgeving, zie het hoofdstuk opslagoplossingen.

5.2.15 Implementeer Cloud Witness

Een cloud-Witness is een nieuw type quorum-Witness voor een failover-cluster. In plaats van de getuige op een schijf of een bestandsshare op te slaan, wordt deze in de cloud, een Windows Azure Storage Account opgeslagen. De functie van een Cloud Witness is om een cluster draaiend te houden, zelfs als de helft van de knooppunten zijn uitgevallen of in een gespleten breintoestand bevinden.

Wanneer een cluster gelijkmatig over twee sites is verdeeld, dwingen eerdere versies van Failover Clustering om de getuige op de ene of de andere site op te slaan, waardoor je effectief één site de primaire site verklaart en de andere secundaire site. De enige andere optie is om een derde site op een andere locatie te maken, met een server om enkel de getuige op te slaan, wat een duur voorstel is.

De reden hiervoor is dat de ene helft van het cluster kan blijven draaien als de andere de helft aan een stroomstoring of een andere ramp ondergaat. Als de getuige op een van de locaties is opgeslagen, zoals weergegeven in de volgende afbeelding, dan heeft die site de meeste quorumstemmen.

Als de minderheidssite uitviel, blijft het cluster op de meerderheidssite draaien, omdat het een quorum heeft. Als de meerderheidssite echter uitvalt, moet de minderheidssite ook stoppen, omdat het geen quorum had. In Windows Server 2016 Failover Clustering kan de getuige opgeslagen worden in de cloud. Als het overgebleven cluster verbinding kan maken met het internet om de stem van de getuige te verkrijgen, kan een van de van de clusterhelften doorgaan als de andere mislukt. Microsoft raadt het gebruik van een cloud-Witness aan voor elke failover cluster waarin alle knooppunten toegang hebben tot internet.

Een cloudgetuige wordt in de cloud opgeslagen met behulp van een Microsoft Azure Storage-account, dat een goedkope manier is om kleine hoeveelheden gegevens in de cloud op te slaan, zonder dat u voor enkel dat doel een virtuele server moet onderhouden. De getuige wordt opgeslagen als een binair bestandsobject (een blob genoemd).

Om een cloud-Witness aan te maken, moet u eerst een Storage Account aanmaken in Microsoft Azure, en vervolgens de cloud-Witness voor het cluster configureren om dat account te gebruiken. Om het opslagaccount aan te maken, gebruikt u de volgende procedure.

  1. In het Azure-portal, Selecteer Nieuw | Opslag | Opslagaccount, zoals weergegeven in de volgende afbeelding.
  2. Typ in het veld Naam een naam voor de account.
  3. Selecteer Blob Storage in de vervolgkeuzelijst Accountsoort.
  4. Selecteer in de vervolgkeuzelijst Replicatie Lokaal Redundante Opslag (LRS).
  5. Klik op Maken.
  6. Wanneer het opslagaccount is gemaakt, selecteert u het op het Azure-dashboard en klikt u op sleutels pictogram.
  7. Let op de informatie die op de volgende pagina verschijnt, welke u nodig heeft om de getuige te configureren:
    • Naam opslagaccount
    • Sleutel
    • BLOB-service-eindpunt

Met deze informatie in de hand, kunt u doorgaan met het configureren van uw cluster met een cloud getuige, met behulp van de volgende procedure.

  1. Selecteer in Failoverclusterbeheer op de hoofdpagina van uw cluster Meer acties | Configureer Cluster Quorum-instellingen om de wizard Clusterquorum configureren te starten.
  2. Selecteer in het deelvenster Quorumconfiguratie selecteren de optie Selecteer het quorum Getuige optie.
  3. Selecteer op de pagina Quorum-witness Selecteren de optie Cloud Witness Configureren.
  4. Typ de informatie die u hebt verzameld uit de Azure-portal op de pagina Cloud Witness configureren, weergegeven in volgende afbeelding.
  5. Klik op Voltooien.

Om een cloud-Witness met PowerShell te configureren, gebruikt u een opdracht zoals het volgende:

Set-ClusterQuorum -cloudwitness -accountname clusterstorage1 -accesskey oyhmhpi1x9q5htonrcxhcnpz0xzw2zgf49lgdwmexn5lr7xcdrenuxtlxujdpfwcqcknzea8xx12ye25g8jdxw

5.2.16 Implementeer VM-resiliency

Het hele idee achter clustering is om diensten te verlenen die kunnen blijven functioneren ondanks rampzalige gebeurtenissen. In het huidige klimaat treden echter plaatselijke tijdelijke storingen vaker op dan grote rampen. Om deze reden bevat de Windows Server 2016 Failover Clustering-release toevoegingen die de veerkracht van individuele virtuele machines op verschillende manieren verbeterd.

Clusterknooppunten communiceren constant – ze worden tenminste verondersteld constant te communiceren. Het komt echter vaak voor dat een enkele virtuele machine het contact met het cluster tijdelijk verliest. Hiervoor zijn veel mogelijke oorzaken: bijvoorbeeld de Cluster Service op een VM kan worden afgesloten vanwege een geheugen- of softwareprobleem; de communicatie van het netwerk kan worden verstoord als gevolg van een probleem met de driver of IP-adressen; of een netwerk kabel is mogelijk beschadigd of gewoon losgekoppeld.

Om beheerders te helpen bij het aanpakken van dit soort problemen, heeft Windows Server 2016 nieuwe Vm-statussen geïntroduceerd, die in de Failover Cluster Manager worden weergegeven als de status van een rol of knooppunt.

Deze statussen omvatten de volgende:

  • Unmonitored – Geeft aan dat de virtuele machine die eigenaar is van een rol die niet wordt gecontroleerd door het Cluster-service.
  • Geïsoleerd – Geeft aan dat het knooppunt momenteel geen actief lid van het cluster is, maar wel nog steeds in het bezit van een rol. Tijdens een tijdelijke storing wordt een virtuele machine eerst in de Geïsoleerde status geplaatst, en gaat vervolgens over naar de status Niet-bewaakt wanneer deze wordt verwijderd uit het actieve cluster.
  • Quarantaine – Geeft aan dat het knooppunt een van zijn rollen is ontdaan en uit het cluster is verwijderd voor een bepaalde tijd na het verlaten en voor drie keer in het voorgaande uur opnieuw terugkomen in het cluster.

U kunt ook de manier configureren waarop het cluster deze statussen gebruikt, met behulp van de volgende instellingen in Windows PowerShell:

  • ResiliencyLevel – Een waarde van 1 maakt het gebruik van de geïsoleerde status alleen mogelijk als het knooppunt een bekende reden geeft voor het verbreken van de verbinding met het cluster. Anders mislukt het knooppunt direct. Een waarde van 2 (wat de standaard is) maakt het vrije gebruik van de Isolated state en geeft het knooppunt de tijd om te herstellen.
    (get-cluster).resiliencylevel = 2
  • ResiliencyDefaultPeriod – Geeft aan hoe lang de knooppunten in het gehele cluster zijn toegestaan om in de geïsoleerde toestand te blijven (in seconden). De standaardwaarde is 240.
    (get-cluster).resiliencydefaultperiod = 240
  • ResiliencyPeriod – Specificeert hoe lang de knooppunten in een bepaalde groep zijn toegestaan om in de geïsoleerde status te blijven (in seconden). Een waarde van -1 zorgt ervoor dat de groep terugkeert naar de instelling ResiliencyDefaultPeriod. De standaardwaarde is 240.
    (get-clustergroup "group1"). resiliencyperiod = 240
  • QuarantineThreshold – Specificeert het aantal fouten die een knooppunt kan optreden in een periode van één uur voordat ze in quarantainestatus worden geplaatst. De standaardwaarde is 3.
    (get-cluster).quarantinethreshold = 3
  • QuarantineDuration – Specificeert de tijdsduur (in seconden) waarin een knooppunt blijft quarantaine. De standaardwaarde is 7200.
    (get-cluster).quarantineduration = 7200

5.2.17 Implementeer VHDX als een opslag oplossing voor gast clusters

Het maken van een gastcluster op een bestaand failovercluster kan het probleem van gedeelde opslag bemoeilijken. Het is echter mogelijk om de gedeelde opslag van een fysiek cluster te gebruiken voor het maken van een gedeeld VHDX-bestand voor het gastcluster.

In dit scenario heeft u twee of meer fysieke Hyper-V-servers die als knooppunten in een failover-cluster dienen. Deze fysieke servers zijn verbonden met hardware voor gedeelde opslag, met behulp van iSCSI, SAS of Fibre Channel, zoals weergegeven in onderstaande afbeelding. De gedeelde opslag is geconfigureerd als gedeelde clustervolumes of SMB 3.0-shares.

Om het gastcluster te maken, host elk van de Hyper-V-servers een virtuele machine. Om de gedeelde opslag te maken die voor het gastcluster nodig is, kunt u een gedeeld VHDX-bestand maken op de CSV’s van het fysieke cluster, zoals weergegeven in de volgende afbeelding.

Windows Server 2016 ondersteunt twee soorten gedeelde virtuele harde-schijfbestanden, als volgt:

  • VHDX – Geïntroduceerd in Windows Server 2012 R2, VHDX-bestanden gemaakt op een gedeelde opslaginfrastructuur kan tussen virtuele machines in een gastcluster worden gedeeld. Gedeelde VHDX-bestanden worden nog steeds ondersteund in Windows Server 2016 om achterwaartse compatibiliteit voor bestaande clusters, maar Microsoft raadt aan om VHD Sets voor nieuwe bestanden te maken.
  • VHD-set – Geïntroduceerd in Windows Server 2016, bestaat een VHD-set uit 260 KB VHDS-bestand, dat metagegevens bevat, en een AVHDX-bestand, dat daadwerkelijke gegevens bevat. VHD-sets bieden mogelijkheden voor online formaataanpassing en voor host-based back-ups die VHDX-bestanden missen.

Opmerking VHD-indelingen converteren

U kunt een VHDX-bestand converteren naar het nieuwe VHD Set-formaat met behulp van de Convert-VHD-cmdlet in Windows PowerShell. De cmdlet werkt door een nieuw bestand met de juiste indeling en de gegevens erin kopiëren vanuit het origineel bestand. Het formaat van de bestemming wordt gespecificeerd door de bestandsnaam extensie, die voor een VHD-set VHDS is. Een typische opdracht wordt als volgt weergegeven:

Convert-VHD -Path disk.vhdx -Destinationpath disk.vhds

Om een nieuw gedeeld VHDX- of VHD Set-bestand voor een gastcluster te maken, opent u de Instellingen dialoogvenster in Failover Cluster Manager, selecteer de SCSI-controller, selecteer Gedeelde schijf, en klik op Toevoegen. U kunt vervolgens de wizard Nieuwe virtuele harde schijf starten en uitvoeren, net als u zou doen op een niet-geclusterde Hyper-V-server. Het enige verschil is een Kies schijfindeling pagina, weergegeven in de volgende afbeelding, waarop u specificeert of u een VHDX- of VHD-set bestand wilt maken.