5.0 High Availability

5.0.1. Inleiding

Toepassingen altijd actief houden is een belangrijke prioriteit voor veel systeembeheerders en Windows Server 2016 bevat functies waarmee u redundante serveroplossingen kunt maken die op bijna elk type ramp kunnen anticiperen. Failover-clusters stellen u in staat om servers te creëren die gegevens delen, wat ervoor zorgt dat een applicatie ondanks meerdere storingen wordt uitgevoerd. Met Network Load Balancing-clusters kunt u een applicatie leveren met zowel fouttolerantie als schaalbaarheid.

5.1. Implementeer HA en DR opties in Hyper-V

Met Hyper-V kunnen beheerders meerdere fysieke servers in één Hyper-V-server consolideren. Een van de voordelen van het op deze manier virtualiseren van servers is dat u deze virtuele machines (VM’s) eenvouding kunt verplaatsen van de ene Hyper-V-host naar de andere. Of het voor is fouttolerantie of load balancing is, biedt Hyper-V verschillende technologieën om VM’s te repliceren en te migreren.

5.1.1. Implementeer Hyper-V Replica

Hyper-V-replica is een functie van de Hyper-V-rol waarmee u een replica van virtuele machines kunt maken op een Hyper-V-server naar een andere server, lokaal of op een externe locatie. De replicatie is asynchroon en het failover-proces naar de replica is niet automatisch.

Hyper-V Replica is echter eenvoudig in te stellen en vereist geen geavanceerde netwerk functies, zoals gedeelde opslag of een failover-cluster. Het is een eenvoudige manier om een replica te maken van een Hyper-V-server die u kunt opstarten wanneer de primaire server niet beschikbaar is.

Hyper-V-replica is gebaseerd op controlepunten, dus nadat de eerste replicatie is voltooid, worden alleen de wijzigingen die zijn aangebracht in de primaire server gecontroleerd en gerepliceerd. Dit minimaliseert de hoeveelheid gegevens die via het netwerk worden verzonden en stelt de replica-server in staat om de virtuele machine te laden en toegang te krijgen tot zijn controlepunten.

Hyper-V Replica heeft veel opties. Het vereist geen failover-cluster, maar het werkt op een. Het vereist geen certificaten voor gecodeerde transmissies, maar het kan ze gebruiken. Zo kunnen beheerders een eenvoudige of complexe configuratie maken als ze dit nodig hebben.

5.1.1.1. Plannen van de replica omgeving

Op de eenvoudigde manier gebruikt een Hyper-V Replica-implementatie twee servers:

• Hyper-V geïnstalleerd op beide servers
• Servers bevinden zich achter dezelfde firewall
• Servers maken geen deel uit van een cluster
• Servers zijn verbonden met hetzelfde Active Directory Domain Services-domein (AD DS) of domeinen met wederzijdse vertrouwensrelaties
• Servers gebruiken Kerberos-geverifieerde, niet-gecodeerde communicatie

Uitzonderingen op dit beleid vereisen aanvullende installatieprocedures, zoals de volgend:

• Als de servers zich op verschillende locaties bevinden, moet u het de firewalls configureren om het replicatieverkeer toe te laten.
• Als het replicatieverkeer moet worden gecodeerd, moet u een beveiligingscertificaat verkrijgen van een geschikte certificeringsinstantie (of gebruik een zelfondertekend certificaat).
• Als de servers deel uitmaken van een failover-cluster, moet u de Hyper-V-replica Broker rol configureren en de naam van het clienttoegangspunt noteren.
• Als u een derde server wilt gebruiken om een extra replica te maken, moet u Hyper-V-replica configureren om uitgebreide replicatie te gebruiken.

5.1.1.2. Hyper-V Servers configureren

Als u replicatie in één richting wilt configureren, moet u Hyper-V Replica configureren op de doelserver, ook wel de replicaserver genoemd. Om Hyper-V Replica als een failover-oplossing te gebruiken, is de aanbevolen methode om beide servers te configureren als replica-servers. Op deze manier kunt u na een failover-incident waarbij u een replicaserver activeert, kunt u de wijzigingen repliceren die tussentijds worden aangebracht in de oorspronkelijke server zodra deze weer online is.

Gebruik de volgende procedure om een Hyper-V-server als een replicaserver met Hyper-V Manager te configureren:

1. Open Hyper-V Manager, selecteer de server en klik in het deelvenster Acties op Hyper-V Instellingen om het dialoogvenster Hyper-V-instellingen weer te geven.
2. Selecteer op de pagina Replicatieconfiguratie de optie Deze computer als A inschakelen Replica Server-selectievakje.
   
3. Selecteer een van de volgende opties in het vak Verificatie en Poorten:
   • Gebruik Kerberos (HTTP) – Replica verkeer wordt niet gecodeerd, en de servers moeten lid zijn van hetzelfde domein (of vertrouwde domeinen).
   • Op certificaat gebaseerde verificatie gebruiken (HTTPS) – Klik op Certificaat selecteren om specificeer het certificaat dat moet worden gebruikt voor replica verkeercodering.
4. Selecteer een van de volgende opties in het vak Autorisatie en Opslag:
   
   • Replicatie toestaan van elke geverifieerde server – Hiermee kan replicatie van elke willekeurige server worden ingeschakeld server en slaat replica’s op de door u opgegeven locatie op.
   • Toegestane replicatie van de opgegeven servers – Klik op Toevoegen om de Toevoegen te openen Dialoogvenster Autorisatie-invoer, waarin u een server opgeeft naam, een locatie voor de replica’s van die server en een vertrouwensgroep waarnaar deze verwijst behoort.
5. Klik OK.

U kunt de configuratie-instellingen van een server ook configureren met behulp van de Set-VmReplicationServer-cmdlet voor Windows PowerShell. Deze cmdlet is opgenomen in de Hyper-V-module, dus u moet de Hyper-V-managementtools geïnstalleerd hebben om deze te kunnen gebruiken. De opdracht voor een eenvoudige Hyper-V Replica-configuratie verschijnt als volgt:

Set-VMReplicationServer -replicationenabled $true -allowedauthenticationtype kerberos -replicationallowedfromanyserver $true -defaultstoragelocation D:\replicas

U moet ook de Windows firewall van de replica server configureren om binnenkomend verkeer toe te laten van de primaire server. Hiertoe opent u Windows Firewall met Geavanceerd Beveiligingsconsole en schakelt u op de pagina Inkomende regels, een van de in volgende regels, op basis van uw selecties op de pagina Replicatieconfiguratie:

• Als u de optie Kerberos gebruiken (HTTP) hebt geselecteerd, schakelt u Hyper-V Replica HTTP in Listener (TCP-In) regel.
• Als u de optie Gebruik certificaatgebaseerde authenticatie (HTTPS) hebt geselecteerd, schakelt u de optie in Hyper-V Replica HTTPS Listener-regel (TCP-In).

Om de firewallregel te configureren met PowerShell, gebruikt u de Enable-NetFirewallRule cmdlet, zoals in de volgende voorbeelden:

Enable-NetFirewallRule -Displayname "hyper-v replica http listener (tcp-in)"
Enable-NetFirewallRule -Displayname "hyper-v replica https listener (tcp-in)"

Zoals eerder vermeld, is dit configuratieproces alleen vereist op de replicaserver, maar u kunt overwegen om de primaire server op dezelfde manier te configureren, in anticipatie op herstel van een failover-situatie.

5.1.1.3. Configureren van virtuele machines

Nadat de replicaserver is geconfigureerd, kunt u doorgaan met het configureren van de virtuele machines op de primaire server die u wilt repliceren. Gebruik hiervoor de volgende procedure.

1. Klik in Hyper-V Manager met de rechtermuisknop op een virtuele machine en selecteer in het contextmenu Replicatie inschakelen om de wizard Replicatie inschakelen te starten.
2. Typ op de pagina Specify Replica Server de naam van de replica-server die u hebt geconfigureerd, of klik op Bladeren om een dialoogvenster Computer selecteren te openen.
3. Geef op de pagina Verbindingsparameters opgeven in het vak Verificatietype op of u Kerberos of op certificaten gebaseerde verificatie wilt gebruiken met dezelfde instelling u hebt gekozen op de replicaserver. U kunt ook opgeven of u de replicatiegegevens wilt comprimeren.
4. Schakel op de pagina Replicatie-VHD’s kiezen de selectievakjes uit voor eventuele VHD’s op de virtuele machine die u niet wilt repliceren.
5. Geef op de pagina Replicatiefrequentie configureren op hoe vaak de primaire server moet wijzigingen naar de replicaserver verzenden – elke 30 seconden, 5 minuten of 15 minutes.
6. Selecteer een van de volgende opties op de pagina Extra herstelpunten configureren opties:
   • Behoud alleen het nieuwste herstelpunt – Met deze optie wordt een replica gemaakt met alleen de status van de primaire VM op het moment van de laatste replicatiegebeurtenis.
   • Extra herstelpunten per uur maken – Met deze optie kunt u repliceren tot 24 uur herstelpunten en tot 12 uur volumeschaduwkopie Service snapshots.
7. Geef op de pagina Kies initiële replicatiemethode, op of u de initiële replicatie wilt uitvoeren door via het netwerk te verzenden, tegen met de hand te dragen op externe media, of door zelf een virtuele machine op de replica server te maken. Met deze opties kunt u voorkomen dat een hele VM wordt gerepliceerd relatief langzame of dure WAN-verbindingen (wide area network).
   
8. Geef in het vak Initiële replicatie plannen op wanneer het replicatieproces moet worden uitgevoerd start, onmiddellijk of op een tijdstip dat u opgeeft.
9. Klik op Voltooien.

Zodra het replicatieproces begint, verschijnt een contextmenu Replicatie wanneer u met de rechtermuisknop op de VM klikt, waarmee u een geplande failover kunt initiëren, kunt u de replicatie onderbreken, verwijderen, verwerken en een dialoogvenster Replication Heath weergeven.

5.1.2. Implementeer Live Migration

Een van de belangrijkste voordelen van servervirtualisatie, zo niet het belangrijkste voordeel, is de mogelijkheid om meerdere fysieke servers te consolideren in één Hyper-V-server met meerdere virtuele machine servers. Omdat de VM’s allemaal op hetzelfde gevirtualiseerde hardwareplatform draaien, is het eenvoudig om ze naar verschillende Hyper-V-hosts te verplaatsen, voor taakverdeling of fouttolerantie doeleinden. Live Migration is een Hyper-V-functie die het mogelijk maakt om een virtuele te verplaatsen machine van de ene Hyper-V-host naar de andere terwijl deze draait, met vrijwel geen onderbreking van dienst.

Live Migration is geen alternatief voor Hyper-V Replica; het verplaatst de virtuele machine gegevensbestanden niet. Live Migration is ontworpen voor omgevingen waarin virtuele machines toegang hebben tot gedeelde gegevensopslag; wat wordt gemigreerd is de systeemstatus en de inhoud van het live geheugen. Als u bijvoorbeeld een Hyper-V failover-cluster hebt waarop een webserver wordt uitgevoerd, waarbij de clusterknooppunten allemaal toegang hebben tot dezelfde opslagarray met de websitebestanden, kan Live Migration een VM van een Hyper-V-host naar een andere verplaatsen zonder onderbreking van de lopende clienttransacties.

Oorspronkelijk ontworpen voor gebruik op failover-clusters met fysieke gedeelde opslag subsystemen, kan Live migratie in Windows Server 2016 nu werken met niet-geclusterde systemen, systemen in verschillende domeinen of helemaal geen domeinen, en systemen die bijna alle types gedeelde opslag gebruiken, fysiek of virtueel.

Een typische livemigratie van een virtuele machine vindt als volgt plaats:

1. De bronserver brengt een verbinding tot stand met de doelserver, die maakt een niet-bewerkte virtuele machine en bevestigt dat deze over de middelen beschikt om de bron-VM te recreëeren, zoals voldoende geheugen en toegang tot de gedeelde opslag met de VM-bestanden.
2. De bestemming wijst geheugen en andere bronnen toe aan de nieuwe VM in wezen het opnieuw maken van de virtuele hardwareconfiguratie van de bron-VM.
3. De bronserver begint de geheugenpagina’s van de VM te verzenden naar de doel-VM. De bron-VM functioneert op dit moment nog steeds en onderhoudt clients op de gebruikelijke manier. Tijdens de geheugenoverdracht begint Hyper-V op de bronserver met het markeren van alle pagina’s in het geheugen die zijn gewijzigd sinds de overdracht is begonnen.
4. Nadat de eerste geheugenoverdracht is voltooid, begint het proces opnieuw, met de bronserver die geheugenpagina’s overbrengt die sinds de initiële overdracht zijn gewijzigd. Dit proces herhaalt zich door verschillende iteraties, totdat de servers een kritiek punt bereiken waarop hun geheugentoestanden identiek zijn.
5. Op dit moment wordt de verwerking en I/O op de bron-VM opgeschort en de controle van de opslagbronnen overgedragen naar de doel-VM.
6. De doel-VM heeft nu een bijgewerkte “werkset” van geheugeninhoud, CPU staat en opslagbronnen, en kan de functionaliteit van de VM overnemen.
7. Terwijl de bestemmings-VM in bedrijf is, meldt Hyper-V de netwerkswitch van wijziging, waardoor het de MAC-adressen van de bestemmings-VM registreert en associeert ze met zijn IP-adres, zodat netwerkverkeer wordt omgeleid naar de nieuwe virtuele machine.

Ondanks al deze activiteiten wordt een livemigratie meestal in minder tijd voltooid dan de VM’s TCP time-to-live interval. De omschakeling is daarom onzichtbaar, zowel voor de clients en naar de software die op de virtuele machine draait. Er zijn veel factoren die van invloed kunnen zijn de snelheid van een live migratie, inclusief de hoeveelheid over te dragen geheugen, de beschikbare bandbreedte op het netwerk en de werklast op de bron en de bestemming servers. Elke waarneembare vertraging die zich voordoet, wordt meestal veroorzaakt door de benodigde tijd zodat het netwerk de bestemmingswijziging doorgeeft.

5.1.2.1. Live migration in een cluster

Wanneer u de functie Failover Clustering in Windows Server 2016 gebruikt om een Hyper-V cluster te maken, gebruikt u de Failover Cluster Manager-console om de Nieuwe Virtuele Machine Wizard te starten . De wizard zelf is dezelfde als degene waartoe u toegang hebt via de Hyper-V Manager, maar nadat de VM is gemaakt, Failover Cluster Manager start de High Availability Wizard, die de VM configureert om Live Migration te ondersteunen. In de PowerShell-equivalent, gebruikt u de standaard-cmdlets om de VM te maken en voert u vervolgens de Add-ClusterVirtualMachineRole-cmdlet om de virtuele machine high available te maken.

5.1.2.2. Live migration zonder cluster

Het is mogelijk om in Windows Server 2016 live migraties tussen Hyper-V servers uit te voeren die niet zijn geclusterd, hoewel ze lid moeten zijn van hetzelfde domein (of vertrouwde domeinen). Voordat u dit kunt doen, moet u echter de Live Migration instellingen configureren, zowel in de bron- als de doelserver.

Om dit te doen met behulp van Hyper-V Manager, opent u het dialoogvenster Hyper-V-instellingen en selecteert u Pagina Live migratie en selecteer de inkomende en uitgaande live migratie inschakelen selectievakje.

Configureer vervolgens de volgende instellingen op die pagina en Live Migrations / Advanced Functies pagina:

• Gelijktijdige livemigraties – Hiermee kunt u opgeven hoeveel livemigraties de server kan tegelijkertijd presteren op basis van de bandbreedte en verkeersniveaus van uw netwerk en de werklast op de server. De standaardinstelling is 2.
• Inkomende livemigraties – Als de server is verbonden met meer dan één netwerk, kunt u met deze instelling opgeven welk netwerk de server moet gebruiken voor live migratie verkeer en de volgorde waarin meerdere netwerken moeten worden gebruikt. Wanneer mogelijk, is de beste praktijk om live migratieverkeer te scheiden van standaard lokaal gebied netwerkverkeer (LAN).
• Authentication Protocol – Hiermee kunt u opgeven of CredSSP of moet worden gebruikt Kerberos voor authenticatie tussen de servers. Kerberos vereist extra configuratie van beperkte overdracht in Active Directory.
• Prestatie-opties – Hiermee kunt u opgeven of TCP/IP of Server moet worden gebruikt Message Block (SMB) -protocollen voor de overdracht van live migratiegegevens. Als u een specifiek netwerk heb voor opslagverkeer, of een netwerk dat datacenter bridging gebruikt om LAN- en opslagverkeer te scheiden, is SMB waarschijnlijk een betere keuze. Op een standaard LAN-verbinding, gebruikt u TCP/IP.

Om deze instellingen met PowerShell te configureren, gebruikt u opdrachten zoals de volgende:

Enable-VMMmigration
Set-VMMigrationNetwork 192.168.4.0
Set-VMHost -VirtualMachineMigrationAuthenticatiuonType kerberos
Set-VMHost -VirtualMachineMigrationPerformanceOption Smbtransport

Nadat de servers zijn geconfigureerd, start u een livemigratie met behulp van de wizard Verplaatsen, waartoe u toegang hebt door een VM in Hyper-V Manager te selecteren en Verplaatsen te kiezen uit de Acties deelvenster. Op de pagina Kies Verplaatsings Type van de wizard, laat de Verplaats de Virtuele Machine optie u toe een live migratie uit te voeren.

Wanneer u Verplaats De Virtuele machine selecteert, wordt de pagina Verplaatsopties kiezen weergegeven en biedt het de volgende opties:

• Verplaats de gegevens van de virtuele machine naar één locatie – Zorgt ervoor dat de wizard de virtuele machine en de opslag naar de standaardlocatie op de bestemming Server verplaats.
• Verplaats de gegevens van de virtuele machine door te selecteren waar de items naartoe moeten worden verplaatst – Zorgt ervoor dat de wizard de virtuele machine en de opslag naar een locatie verplaatst die op de doelserver opgeeft.
• Verplaats alleen de virtuele machine – Zorgt ervoor dat de wizard de virtuele machine naar de doelserver verplaatst zonder opslag. Deze optie bood de niet-geclusterde equivalent van een live migratie.

Om een live migratie met PowerShell uit te voeren, gebruikt u de cmdlet Move-VM, zoals in de volgend voorbeeld:

Move-VM -vm server1 -destinationhost hyper2

5.1.3. Implementeer shared nothing live migration

Live Migration was oorspronkelijk een tool met zeer restrictieve vereisten. Uw servers moesten deel uit maken van een cluster en de virtuele machines moesten toegang hebben tot gedeelde opslag. Windows Server 2016 maakt het mogelijk om virtuele machines te migreren tussen Hyper-V hosts met geen van beide vereisten, met behulp van een functie die bekend staat als Shared Nothing Live Migratie.

Shared Nothing Live Migration is in wezen een combinatie van een live migratie en een opslagmigratie. Op het eerste gezicht is de procedure in wezen hetzelfde als die beschreven voor een live migratie, behalve dat de bronserver naast geheugen en systeemstatus de opslag van de VM kopieert naar de bestemming. Uiteraard duurt het migratieproces veel langer dan die van een standaard live migratie, afhankelijk van de hoeveelheid betrokken opslag en de beschikbare bandbreedte van het netwerk, maar zoals bij een live migratie, blijft de bron-VM actief totdat de gegevensoverdracht is voltooid.

Een gedeelde nothing live migratie heeft de volgende voorwaarden:

• De bron- en doel-VM’s moeten lid zijn van hetzelfde AD DS-domein (of vertrouwde domeinen).
• De bron- en domeinservers moeten dezelfde processorfamilie gebruiken (Intel of AMD).
• De bron- en doelservers moeten verbonden zijn door een actief Ethernet-netwerk van minimaal 1 gigabit per seconde (Gbps).
• De bron- en doelservers moeten identieke virtuele switches hebben met dezelfde naam. Als dit niet het geval is, wordt het migratieproces onderbroken om de melding te geven om een switch op de doelserver te selecteren.

Net als bij een niet-geclusterde live migratie, moet u Live migratie inschakelen in de Hyper-V Dialoogvenster Instellingen en de verschillende instellingen voor Live Migrations en Advanced Features pagina’s zijn hier ook van toepassing. De procedure voor het uitvoeren van een gedeelde niets live migratie is hetzelfde, met behulp van de wizard Verplaatsen, behalve dat u de virtuele verplaatsen selecteert Gegevens van machine naar één locatie op de pagina Opties voor verplaatsen kiezen.

5.1.4. Configureer CredSSP of Kerberos authenticatie protocol voor Live Migration

Wanneer u Live migratie op een Hyper-V-server inschakelt, hebt u de keuze tussen twee authenticatieprotocollen:

• Credential Security Support Provider (CredSSP) – CredSSP is een authenticatie protocol waarmee een client de inloggegevens van een gebruiker kan delegeren voor authenticatie op een externe server. In Hyper-V is CredSSP het standaard authenticatieprotocol voor Live Migratie. Het protocol vereist geen speciale configuratie, maar het vereist wel een gebruiker om u aan te melden bij de bronserver voordat u een live migratie uitvoert.
• Kerberos – Het standaard authenticatieprotocol voor Active Directory doet Kerberos u hoeft zich niet aan te melden, zoals CredSSP, maar u moet het wel configureren ombeperkte delegatie te gebruiken voordat u live migraties kunt uitvoeren.

Afgedwongen delegatie is een element van het Kerberos-protocol dat een server toelaat namens een gebruiker te handelen, maar alleen voor specifieke services. Om beperkte overdracht te configureren, moet u aangemeld zijn als domeinbeheerder en de volgende procedure volgen.

1. Open de console Active Directory: gebruikers en computers.
2. Blader naar de container Computers en zoek het computerobject voor de Live Migratie bronserver.
3. Open het eigenschappenvenster voor het computerobject van de bronserver en selecteer de Delegatietabblad.
   
4. Selecteer Alleen deze computer vertrouwen voor overdracht aan de opgegeven services optie en laat de optie Alleen Kerberos gebruiken geselecteerd.
5. Klik op Toevoegen en klik in het dialoogvenster Services toevoegen op Gebruikers of Computers.
6. Typ in het dialoogvenster Gebruikers of computers selecteren de naam van de doelserver en klik op OK.
7. Selecteer in het vak Beschikbare services een of beide van de volgende services, zoals nodig en klik op OK.
   • cifs – Hiermee kan de computergebruiker de opslag van virtuele machines verplaatsen, met of zonder de virtuele machine zelf.
   • Microsoft Virtual System Migration Service – Hiermee kan de computer worden verplaatst virtuele machines.
8. Klik op OK om het eigenschappenvenster te sluiten.
9. Herhaal de procedure voor de Live Migration-doelcomputer en geef de naam van de broncomputer in het dialoogvenster Gebruikers of computers selecteren.

5.1.5. Implementeer storage migration

Live Migration is ontworpen om een virtuele machine van één Hyper-V-hostserver naar een andere te verplaatsen, zonder de bestanden aan te raken, waarvan aangenomen wordt dat ze toegankelijk zijn op gedeelde opslag. Opslagmigratie (soms enigszins onnauwkeurig aangeduid als Live Opslag Migratie) is precies het tegenovergestelde; het verplaatst de bestanden van de virtuele machine naar een andere locatie, terwijl de VM zelf op zijn plaats blijft.

U kunt opslagmigratie gebruiken om de bestanden, inclusief configuratiebestanden, controlepunten en Smart Paging-bestanden van een virtuele machine te verplaatsen naar elke locatie waarvan die de gebruiker toegangsrechten heeft, inclusief een andere schijf of map op dezelfde computer of op een andere computer. Net als bij Live Migratie kunnen opslagmigraties plaatsvinden terwijl de virtuele machine draait, of gestopt is.

In vergelijking met een live migratie, gebruikt opslagmigratie een relatief eenvoudig proces:

1. Wanneer u een opslagmigratie initieert, maakt de doelserver nieuwe virtuele hard schijfbestanden van grootte en type die overeenkomen met die op de bronserver.
2. De VM op de bronserver blijft werken met de lokale bestanden, maar Hyper-V begint met het spiegelen van schijfschrijven naar de doelserver.
3. Terwijl het schrijven naar de spiegel wordt voortgezet, start Hyper-V op de bronserver een enkele doorgang kopie van de bronschijven naar de bestemming. Blokken die al zijn geweest geschreven naar de bestemming door het spiegelproces worden overgeslagen.
4. Wanneer de kopie met één doorgang is voltooid en het gespiegelde schrijven doorgaat, werkt Hyper-V de VM-configuratie bij en begint het te werken vanuit de bestanden op de doelserver.
5. Zodra de VM met succes wordt uitgevoerd vanuit de gemigreerde bestanden, verwijdert Hyper-V de bronbestanden.

Als de bron-VM is uitgeschakeld, is er geen speciale procedure nodig. Hyper-V kopieert eenvoudig de bestanden van de bron naar de bestemming, configureert de VM opnieuw om de te gebruiken doelbestanden en verwijdert vervolgens de bronbestanden.

Er zijn nauwelijks speciale vereisten voor het uitvoeren van een opslagmigratie, behalve dat u geen VM’s kunt migreren die pass-through-schijven gebruiken voor hun opslag. De bestanden moeten zijn opgeslagen op virtuele harde schijf (VHD of VHDX) bestanden.

Om een opslagmigratie uit te voeren, gebruikt u dezelfde Verplaatsingswizard als voor niet-geclusterde live migraties en shared nothing live migraties. Op de wizard pagina Type Verplaatsing Kiezen, selecteert u de optie Opslag van de Virtuele Machine Verplaatsen. De pagina opties Kiezen voor Opslag Verplaatsen wordt weergegeven met de volgende opties:

• Verplaats alle gegevens van de virtuele machine naar een enkele locatie – Hiermee kunt u één bestemming opgeven voor alle bestanden van de bron-VM.
• Verplaats alle gegevens van de virtuele machine naar verschillende locaties – Voegt meerdere toe scherm toe aan de wizard, waarop u de te migreren bestandstypen kunt selecteren en de bestemming voor elk type kunt opgeven.
• Verplaats alleen de virtuele harde schijven van de virtuele machine – Hiermee kunt u selecteren welke VHD / VHDX-bestanden moeten worden gemigreerd en voor elk een bestemming opgeven.

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.

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

5.3. Implementeer Storage Spaces Direct

Storage Spaces Direct (S2D) is de volgende stap in de evolutie van software-defined opslagtechnologie die voor het eerst op servers verscheen als opslagruimten in Windows Server 2012. Storage Spaces maakt het mogelijk om pools te creëren die de ruimte uit meerdere

fysieke schijfstations bevatten en er vervolgens virtuele schijven uit de gepoolde opslag van maakt, ongeacht de fysieke schijfgrenzen. Storage Spaces Direct biedt hetzelfde type services in een geclusterde omgeving, waardoor het mogelijk wordt om gedeelde opslagpools te maken met behulp van de standaard lokale SAS-, SATA- of NVMe-schijven in de clusterknooppunten. Voor de eerste keer is is het niet nodig om dure externe opslagarrays aan te schaffen om een failover-cluster te implementeren.

5.3.1. Bepaal scenariovereisten voor het implementeren van Storage Spaces Direct

Storage Spaces Direct biedt veel van dezelfde voordelen als Storage Spaces, zoals data redundantie en gelaagde opslag, en doet dit met behulp van software door gebruik te maken van standaard schijven en gemeenschappelijke netwerkcomponenten. Dit wil echter niet zeggen dat S2D geen speciale vereisten heeft. In de volgende secties worden enkele van de factoren uitgelegd waarmee u rekening moet houden, voordat u een S2D-cluster implementeert.

Opmerking Beschikbaarheid van Storage Spaces Direct

Storage Spaces Direct is alleen opgenomen in de Datacenter-editie van Windows Server 2016, niet de Standard-editie. U kunt S2D gebruiken op een Datacenter server met behulp van een van de installatie-opties, inclusief Server Core en Nano Server, evenals de volledige desktopervaring.

5.3.1.1. Servers

Een Storage Spaces Direct-cluster kan uit maar liefst 16 knooppunten bestaan, met maximaal 400 schijven. Ondanks het vermogen van S2D om te functioneren met standaard componenten, moeten de servers in het cluster in staat zijn om grote aantallen schijven en meerdere netwerkinterfaces te ondersteunen.

5.3.1.2. Disk drives

De aanbevolen schijfconfiguratie voor een knooppunt in een S2D-cluster is minimaal zes schijven, met ten minste twee solid-state schijven (SSD’s) en ten minste vier harde schijven (HDD’s). Wat de vormfactor van de schijfbehuizing ook is, intern of extern, er moet geen RAID of andere intelligentie zijn die niet kan worden uitgeschakeld. S2D biedt fouttolerantie en hoge prestaties, concurrerende hardware zal een negatief effect hebben op de algemene functionaliteit van het cluster.

Om S2D ze te laten detecteren en gebruiken, moeten de schijven worden geïnitialiseerd (meestal met behulp van GPT), maar ze mogen niet worden opgedeeld. Schijven met partities of volumes erop komen niet in aanmerking voor gebruik door Storage Spaces Direct.

5.3.1.3. Networking

De sleutel tot Storage Spaces Direct is de software-opslagbus, een logisch netwerkkanaal die de lokale datadrives in alle clusterknooppunten verbindt. Deze bus valt theoretisch tussen de servers en de harde schijven erin, zoals weergegeven in onderstaande figuur.

Omdat S2D een pool maakt van de interne opslag op verschillende computers, wordt al het opslagverkeer wordt overgebracht via standaard Ethernet-netwerken met behulp van SMB3 en RDMA. Er is geen traditionele storage-netwerkstructuur, zoals SAS of Fibre Channel, waardoor afstandsbeperkingen en de behoefte aan verschillende soorten bekabeling geëlimineerd worden. Verkeersmanagement is een cruciaal onderdeel van elke implementatie van S2D-productieclusters.

De fysieke realisatie van de logische software-opslagbus moet gegevens overdragen alsof de schijven een enkele entiteit in de verschillende clusterknooppunten vormen. Bovendien moeten de netwerken de redundante gegevens meetransporteren die gegenereerd worden door de in de pool gemaakte spiegeling- en pariteitsregelingen zijn gemaakt. Voor efficiënte S2D-prestaties is dus intra-node Ethernet  communicatie vereist die zowel een hoge bandbreedte als een lage latentie biedt.

Op de fysieke laag raadt Microsoft het gebruik van ten minste twee 10 Gbps Ethernet adapters per node aan, bij voorkeur adapters die RDMA gebruiken, zodat ze een deel van de processorbelasting van de servers kunnen ontlasten. S2D gebruikt Server Message Block versie 3 (SMB3) voor communicatie tussen clustersknooppunten, die waar mogelijk gebruik maken van de geavanceerde functies van het protocol, zoals SMB Direct en SMB Multichannel.

5.3.2. Schakel Storage Spaces direct in met behulp van Windows PowerShell

Het grootste deel van het implementatieproces voor een cluster met Storage Spaces Direct is bijna het hetzelfde als dat voor elk ander cluster. U installeert Windows Server 2016 op de clusterknooppunten, update ze identiek, voeg de functie Failover Clustering en het Hyper-V-knooppunt toe, en maak het cluster.

Hier vindt u een belangrijke afwijking van de standaard procedure. Terwijl u het cluster kan creeëren met behulp van de grafische Create Cluster Wizard in Failover Cluster Manager, moet u voorkomen dat het systeem automatisch opslagruimte zoekt en toevoegt. Daarom moet u het cluster in Windows PowerShell maken met een opdracht als de volgende:

New-Cluster -Name cluster1 -Node server1, server2, server3, server4 -Nostorage

De parameter NoStorage is belangrijk en het gebrek aan opslag genereert een fout tijdens het maken van het cluster. De opslag wordt toegevoegd wanneer u Storage Spaces Direct inschakelt. Om dit te doen, voert u de cmdlet Enable-ClusterStorageSpacesDirect zonder parameters uit, zoals volgt:

Enable-ClusterStorageSpacesDirect

Deze cmdlet voert verschillende taken uit die cruciaal zijn voor de S2D-implementatie, waaronder het volgende:

• Lokaliseer schijven – Het systeem scant alle knooppunten in het cluster op lokale, niet-gepartitioneerde schijven.
• Creëer caches – Het systeem classificeert de schijven in elk knooppunt volgens hun respectieve bus en mediatypen en brengt bindingen tussen hen tot stand om partnerschappen in elk te creëren server die de snellere schijven gebruikt voor lees- en schrijfcaching.
• Creëer een pool – Het systeem voegt alle beschikbare schijven in alle knooppunten toe aan een één clusterbrede opslagpool.

Nadat de opslagpool is gemaakt, kunt u doorgaan met het maken van virtuele schijven (net als u doet in Opslagruimten in Serverbeheer op een zelfstandige server). In Failover-cluster Manager, selecteert u de opslagpool, zoals weergegeven in volgende afbeelding en start u de nieuwe virtuele Schijfwizard (Storage Spaces Direct). In de wizard specificeert u een grootte, en het maakt een schijf met de standaard bidirectionele spiegelresiliency-instelling.

S2D virtuele schijven kunnen echter ondersteuning bieden voor eenvoudige, mirror- en parity-resiliency-typen, zoals evenals aangepaste opslaglagen. Voor meer flexibiliteit bij het maken van virtuele schijven, kunt u de cmdlet New-Volume in Windows PowerShell gebruiken. Deze cmdlet kan in één stap taken uitvoeren die verschillende afzonderlijke bewerkingen vereisten, waaronder het maken, partitioneren en het formatteren van de virtuele schijf, het converteren naar het CSVFS-bestandssysteem en het toevoegen aan het cluster.

Als u bijvoorbeeld een virtuele schijf wilt maken die gebruikmaakt van pariteitsstabiliteit en twee lagen, met de standaard beschrijvende namen van Prestaties voor SSD’s en Capaciteit voor HDDS, kunt u een opdracht zoals het volgende gebruiken:

New-Volume -Storagepool "s2d*" -Friendlyname vdisk1 -Filesystem csvfs_refs -Resiliencysettingname parity -Storagetiersfriendlynames performance, capacity -Storagetiers 10GB, 100GB

Nadat u de virtuele schijven heeft gemaakt, kunt u ze toevoegen aan gedeelde clustervolumes, ze toegankelijk maken in elk knooppunt.

5.3.3. Implementeer een gedesaggregeerd Storage Spaces Direct-scenario in een cluster

De aangewezen applicatie voor Storage Spaces Direct, zoals gedefinieerd in de twee implementatiescenario’s van Microsoft, is om een Hyper-V-cluster te ondersteunen. In het eerste scenario een gedesaggregeerde of geconvergeerde implementatie genaamd, zijn er twee verschillende clusters. De eerste is een Scale-out bestandsservercluster die Storage Spaces Direct gebruikt om de opslag het tweede Hyper-V-cluster te voorzien dat virtuele machines host, zoals weergegeven in volgende afbeelding.

In dit scenario is de functie van het S2D-cluster om de opslag te bieden die het Hyper-V cluster nodig heeft voor zijn virtuele machines. Als zodanig is S2D in wezen een vervanging voor een SAN. Omdat het twee afzonderlijke clusters vereist, vereist dit model meer servers en is daarom duurder om te implementeren. Het voordeel van dit type implementatie is dat het S2D-cluster en Hyper-V-cluster onafhankelijk opgeschaald kunnen worden.

Storage Spaces Direct creëert een zeer schaalbare omgeving waarin u schijven aan de knooppunten kunt toevoegen of knooppunten kunt toevoegen aan het cluster. Hoe dan ook, S2D zal elke nieuwe gedetecteerd opslag in de pool assimileren. In een niet-geaggregeerde implementatie kunt u opslagruimte toevoegen aan het S2D-cluster zonder het Hyper-V-cluster te beïnvloeden. Op dezelfde manier kunt u knooppunten toevoegen aan het Hyper-V-cluster zonder de opslaginfrastructuur te beïnvloeden.

Om het gedesaggregeerde scenario te implementeren, gaat u verder zoals eerder beschreven om een cluster te maken, S2D inschakelen, virtuele schijven maken en ze toevoegen aan CSV’s. Vervolgens voegt u de Scale-out bestandsserverrol toe, om de configuratie van het opslagcluster te voltooien. Het tweede cluster is een standaard Hyper-V-cluster dat de shares gebruikt die door het SoFS-cluster wordt geleverd om zijn virtuele machines op te slaan.

5.3.4. Implementeer een hypergeconvergeerd Storage Spaces Direct-scenario in een cluster

De tweede Storage Spaces Direct-scenario’s worden hypergeconvergeerd genoemd omdat het Storage Services Direct met Hyper-V in één cluster combineert, zoals weergegeven in de volgende afbeelding. Er is minder hardware bij deze oplossing betrokken, het genereert zeker minder netwerk verkeer, het is ook veel minder duur en vereist minder onderhoud. Het is niet nodig bestandsservermachtigingen te configureren of om de twee clusters te bewaken.

Examen Tip

Met Windows Server 2016 is het mogelijk om een hypergeconvergeerde S2D cluster op een enkele Hyper-V-server voor test- en educatieve doeleinden te creëren. Nadat u de Failover Clustering en Hyper-V installeert, kunt u twee of meer virtuele machines met verschillende VHDX-bestanden op elk creeëren, ze clusteren en Storage Spaces Direct inschakelen. Nadat u de virtualisatie-extensies van de hostserver heeft vrijgegeven, kunt u Hyper-V op de VM’s installeren, geneste VM’s maken en deze clusteren. Het zal niet snel zijn, en de storm van schijfverzoeken die door de fysieke schijven van de hostserver worden afgehandeld zullen chaotisch zijn als je ze zou kunnen zien, maar het werkt wel.

Het nadeel van dit scenario is dat u de SoFS- en Hyper-V-services niet onafhankelijk kunt schalen. Als u een server wilt toevoegen om meer opslagruimte aan de pool te bieden, moet u ook een node aan het Hyper-V-cluster toevoegen.

De inzet van een hypergeconvergeerde Storage Spaces Direct-cluster is niet veel anders dan die van een standaard Hyper-V-cluster, behalve dat u S2D moet inschakelen nadat u het cluster hebt gemaakt. Een van de aspecten van S2D is dat het gebruik maakt van bepaalde vaardigheden. Als u voorheen met Windows-failoverclusters heeft gewerkt zou er niet veel nieuw voor u moeten zijn in een S2D-implementatie. In feite, in vergelijking met het opzetten van een SAN is Storage Spaces Direct veel eenvoudiger.

5.4. Beheer Failover-Clustering

Nadat u een failovercluster hebt geïnstalleerd en geconfigureerd, moeten er doorlopende onderhouds- en beheertaken worden uitgevoerd met behulp van hulpprogramma’s zoals Failover Cluster Manager en Windows PowerShell-cmdlets in de FailoverClusters-module.

5.4.1. Configureer rolspecifieke instellingen, inclusief continu beschikbare shares

Elke clusterrol die u installeert in Failover Cluster Manager of met behulp van een PowerShell-cmdlet heeft zijn eigen instellingen die specifiek zijn voor de functie van de rol. Wanneer u op de pagina Rollen in Failover Cluster Manager een van uw rollen selecteert, wordt er een sectie voor weergegeven in de Acties paneel, zoals weergegeven in de volgende afbeelding. Sommige acties in het deelvenster zijn rolspecifiek en sommige zijn generieke acties die in elk rolvenster verschijnen.

5.4.1.1. Rolinstellingen voor virtuele machines

In dit voorbeeld zijn er voor de rol Virtuele machine acties zoals die in Hyper-V Manager, waarmee u de VM kunt starten, stoppen en verbinden, en het dialoogvenster Instellingen kunt openen. Met het menu Verplaatsen kunt u live migraties en snelle migraties uitvoeren en opslag van virtuele machines migreren, met behulp van de interface die wordt weergegeven in de volgende afbeelding.

5.4.1.2. Continu beschikbare instellingen voor delen

Wanneer u de clusterrol Bestandsserver installeert, hebt u de keuze tussen het maken van een bestandsserver voor algemeen gebruik of een uitschaalbare bestandsserver die is ontworpen om opslag te bieden aan toepassingen, zoals Hyper-V en SQL Server. Met beide rollen kunt u shares maken die continu beschikbaar zijn door het gebruik van het SMB 3.0-protocol.

Versie 3.0 van het SMB-protocol bevat verbeteringen die met name handig zijn in een geclusterde omgeving, waaronder de volgende:

• SMB Transparent Failover – Hiermee kan een clientsessie zonder onderbreking van het ene clusterknooppunt naar het andere worden overgedragen. Dit wordt standaard geïmplementeerd op alle bestandsservershares van Failover Cluster. Zowel de client als de server moeten SMB 3.0 (Windows Server 2012 of Windows 8) ondersteunen.
• SMB Scale-out – Maakt het mogelijk dat shares tegelijkertijd toegankelijk zijn voor clients vanaf alle knooppunten in het cluster. Dit verhoogt effectief de beschikbare bandbreedte van de share tot de gecombineerde bandbreedte van de knooppunten. Scale-out shares zijn alleen toegankelijk voor clients met SMB-versies 2 en 3.
• SMB Multichannel – Stelt bestandsservers in staat om de bandbreedte van meerdere netwerkinterface-adapters te combineren, om een verbeterde door- en fouttolerantie te bereiken. SMB kan automatisch het bestaan van meerdere adapters detecteren en zichzelf configureren om maak er gebruik van.
• SMB Direct – Gebruikt Remote Direct Memory Access (RDMA) om directe geheugen-naar-geheugen gegevensoverdrachten tussen externe systemen uit te voeren, waardoor het gebruik van de systeemprocessor wordt geminimaliseerd. Zowel de client als de server moeten SMB 3.0 gebruiken.
• SMB Versleuteling – Biedt end-to-end AES-codering tussen servers en clients met behulp van SMB 3.0.

Wanneer u een bestandsservershare maakt of wijzigt in Failover Cluster Manager, presenteert de New Share Wizard een pagina Share Settings configureren, zoals weergegeven in de onderstaande afbeelding. Het selectievakje Doorlopende beschikbaarheid inschakelen, standaard geselecteerd, activeert de SMB-transparante failover-functie en het selectievakje Gegevenstoegang versleutelen schakelt SMB-versleuteling in.

5.4.2. Configureer Vm-bewaking

Een van de voordelen van het uitvoeren van Hyper-V in een cluster is dat het cluster in staat is om specifieke services op de virtuele machines te bewaken, te rapporteren wanneer zich een probleem voordoet en actie te ondernemen die u kunt configureren. Op deze manier kunt u de service selecteren die is gekoppeld aan een kritieke toepassing op de VM en de VM configureren om deze opnieuw op te starten of een failover naar een ander knooppunt uit te voeren wanneer zich een probleem voordoet.

Om VM-bewaking in Failover Clustering te gebruiken, moet de virtuele machine aan de volgende vereisten voldoen:

• De VM moet zich in hetzelfde domein bevinden als de Hyper-V-host.
• Voor Windows Firewall op de VM moeten de inkomende regels in de Virtual Machine Monitoring-groep zijn ingeschakeld.
• De Hyper-V-clusterbeheerder moet lid zijn van de lokale groep Administrators op de virtuele machine.

Gebruik de volgende procedure om bewaking voor een specifieke virtuele machine te configureren.

1. Open Failover Cluster Manager en klik op Rollen om de pagina Rollen weer te geven.
2. Selecteer de rol van de virtuele machine die u wilt bewaken en selecteer in het deelvenster Acties Meer acties, Controle configureren.
3. In het dialoogvenster Services selecteren verschijnt, zoals weergegeven in de volgende afbeelding, schakelt u het selectievakje in voor de service die u wilt controleren en klikt u op OK.
   

U kunt bewaking ook configureren met behulp van de cmdlet Add-ClusterVMMonitoredItem in een Windows PowerShell-venster, zoals in het volgende voorbeeld:

Add-ClusterVMMonitorEditItem –VirtualMachine clustervm3 -Service spooler

Wanneer een service die u hebt geselecteerd problemen ondervindt, worden deze eerst afgehandeld door de Service Control Manager op de VM, die de eigenschappen van de individuele service gebruikt om zijn acties te regelen, zoals weergegeven in de volgende afbeelding. U kunt deze eigenschappen wijzigen om te specificeren welke acties de Service Control Manager moet ondernemen en hoe vaak.

Als de inspanningen van de Service Control Manager mislukken en de service nog steeds niet goed werkt, neemt het cluster het over en voert het zijn eigen herstelacties uit, als volgt:

• Het cluster maakt een vermelding in het systeemlogboek van de host met de gebeurtenis-ID 1250.
• Het cluster wijzigt de status van de virtuele machine in toepassing in VM Critical.
• Het cluster start de virtuele machine opnieuw op hetzelfde knooppunt. Als de service blijft mislukken, geeft het cluster de rol over aan een ander knoop punt.

U kunt deze standaard herstartactiviteiten wijzigen door het blad Virtual Machine Cluster WMI Properties te openen, zoals weergegeven in de onderstaande afbeelding. Deze bevindt zich op de hoofdpagina van het cluster, in het vak Cluster Core Resources.

5.4.3. Configureer failover- en voorkeursinstellingen

Een failover is wanneer een rol die op een clusterknooppunt wordt uitgevoerd, niet langer kan worden uitgevoerd en het cluster deze naar een ander knooppunt verplaatst. Er zijn een aantal redenen waarom een failover kan optreden: er kan een stroomstoring zijn, de software kan niet goed werken of een beheerder moet het knooppunt mogelijk afsluiten voor onderhoud. Een failback is wanneer het cluster de rol terugzet naar het oorspronkelijke knooppunt, nadat het probleem dat de failover heeft veroorzaakt, is verholpen.

Beheerders kunnen het gedrag van het cluster met betrekking tot knooppuntselecties en failover-gedrag voor een specifieke rol bepalen door de eigenschappen ervan te wijzigen. In failovercluster Manager, op de pagina Rollen, selecteert u een rol en klikt u op Eigenschappen in het deelvenster Acties om het eigenschappenvenster van de rol weer te geven, zoals weergegeven in de volgende afbeelding.

Op het tabblad Algemeen kunt u het knooppunt opgeven waarvan u de rol wilt uitvoeren. Het zou niet uit moeten maken, aangezien de knooppunten functioneel identiek zijn, maar u kunt dit doen door het selectievakje voor een van de knooppunten te selecteren en de knoppen Omhoog en Omlaag te gebruiken om de volgorde van voorkeur te wijzigen.

In de vervolgkeuzelijst Prioriteit kunt u de waarden Hoog, Gemiddeld of Laag opgeven om aan te geven wanneer de rol moet beginnen, in verhouding tot de andere rollen in het cluster. De waarden zijn alleen relatief ten opzichte van die van de andere rollen en er is ook een No Auto Start-instelling om te voorkomen dat het knooppunt met het cluster begint. U moet het dan handmatig starten, als u wilt dat het wordt uitgevoerd.

Op het tabblad Failover, weergegeven in de volgende afbeelding, kunt u het maximum aantal keren opgeven dat het cluster moet proberen een rol opnieuw te starten of een failover naar een ander knooppunt te laten uitvoeren gedurende het tijdsinterval dat is opgegeven door de instelling Periode. U kunt ook opgeven of de rol moet terugkeren naar het voorkeursknooppunt en of dit moet gebeuren zodra het voorkeursknooppunt weer online komt, of dat er een interval moet worden gewacht dat u opgeeft.

5.4.4. Implementeer stretch- en sitebewuste failoverclusters

Fouttolerantie heeft te maken met het plannen voor elke eventualiteit, en failoverclusters zijn een manier om te anticiperen op hardware- en softwarefouten. Soms treden storingen echter op grotere schaal op, waarbij niet de harde schijven en servers worden getroffen, maar gebouwen en steden. Om deze reden kunnen organisaties die hun applicaties in alle gevallen draaiende willen houden, uitgerekte (of uitgerekte) clusters maken.

Een stretchcluster is een cluster waarvan de knooppunten zijn verdeeld over verschillende locaties, vaak in verschillende steden. Op deze manier kan het cluster, als zich een ramp voordoet, zoals een orkaan of aardbeving, zijn rollen overdragen aan knooppunten die zich ver van het probleem bevinden.

Stretch-clustering stelt beheerders echter voor lastige problemen, zoals hoe ervoor te zorgen dat clusterknooppunten in verschillende steden met dezelfde gegevens werken en hoe het failover-gedrag te controleren in een situatie waarin de knooppunten niet uitwisselbaar zijn.

Omdat het meestal niet praktisch is om een gedeelde opslagoplossing te maken die alle knooppunten in een stretchcluster kan verbinden met dezelfde schijfstations, gebruiken veel stretchclusters asymmetrische opslag, waarbij elke site zijn eigen gedeelde opslag-oplossing heeft. Beheerders kunnen vervolgens de functie Opslagreplica in Windows Server 2016 gebruiken om de gegevens tussen sites te synchroniseren, zoals weergegeven in de volgende afbeelding.

Zelfs als het probleem met de gedeelde gegevens is opgelost, zijn er echter nog andere problemen bij stretch-clustering. Hoe moet het cluster bijvoorbeeld in een failover-situatie onderscheid maken tussen de knooppunten in New York en de knooppunten in San Francisco? Windows Server 2016 Failover Clustering lost dit probleem op door de mogelijkheid te bieden om site-aware failover-clusters te maken.

Een site-aware failovercluster is een cluster dat foutdomeinen bevat op basis van de waarden van een site-eigenschap die voor elk knooppunt is geconfigureerd. Het cluster gebruikt deze foutdomeinen om het gedrag ervan te bepalen tijdens failovers en andere roloverdrachten. Als u een sitebewust cluster wilt maken, gebruikt u eerst de New-ClusterFaultDomain PowerShell-cmdlet om de sites te definiëren. Vervolgens gebruikt u de cmdlet Set-ClusterFaultDomain om de clusterknooppunten toe te wijzen aan de sites die u hebt gemaakt.

Als u bijvoorbeeld sites wilt maken voor kantoren in New York en San Francisco, kunt u opdrachten als de volgende gebruiken:

New-ClusterFaultDomain -Name ny -Type site -Description "primary" -Location "new york ny"
New-ClusterFaultDomain -Name sf -Type site -Description "secondary" -Location "san francisco ca"

Vervolgens wijst u voor een cluster met vier knooppunten met twee knooppunten op elke site de knooppunten toe aan de sites met behulp van opdrachten als de volgende:

Set-ClusterFaultDomain Name node1 -Parent ny
Set-ClusterFaultDomain Name node2 -Parent ny
Set-ClusterFaultDomain Name node3 -Parent sf
Set-ClusterFaultDomain Name node4 -Parent sf

Zodra deze eigenschappen zijn geconfigureerd, gebruikt het cluster de site-informatie om activiteiten te beheren met bronoverdrachten tussen knooppunten. Wanneer een knooppunt uitvalt, bijvoorbeeld de cluster probeert eerst een failover naar een ander knooppunt op dezelfde site uit te voeren. Alleen wanneer wordt vastgesteld dat alle knooppunten op die site niet beschikbaar zijn, wordt er een failover uitgevoerd naar een knooppunt op een andere site. Dit staat bekend als failover-affiniteit.

Op dezelfde manier, wanneer een beheerder een knooppunt van zijn rollen leegmaakt voordat het wordt uitgeschakeld voor onderhoud, verplaatst het cluster de rollen naar een knooppunt op dezelfde site. Gedeelde cluster volumes distribueren waar mogelijk ook verbindingen tussen knooppunten op dezelfde site.

Het is ook mogelijk om de hartslaginstellingen te configureren die een cluster gebruikt om te bepalen of knooppunten functioneel zijn. In een stretch-cluster zijn er ongetwijfeld langere latentievertragingen in communicatie tussen sites dan tussen subnetten, dus kunt u de volgende instellingen wijzigen om te voorkomen dat knooppunten ten onrechte worden aangemerkt als mislukt:

• CrossSiteDelay – Specificeert de hoeveelheid tijd (in milliseconden) tussen hartslagen die naar knooppunten op verschillende sites worden verzonden. De standaardinstelling is 1000.
• CrossSiteThreshold – Specificeert het aantal gemiste hartslagen dat moet plaatsvinden voordat een knooppunt op een andere locatie als mislukt wordt beschouwd. De standaardinstelling is 20.

Om deze instellingen te configureren, gebruikt u PowerShell-opdrachten zoals de volgende:

(Get-Cluster).CrossSiteDelay = 2000
(Get-Cluster).CrossSiteThreshold = 30

U kunt ook een van de sites die u hebt gemaakt, configureren als voorkeurssite voor het cluster, met behulp van een opdracht als de volgende:

(Get-Cluster).PreferredSite = ny

Wanneer u dit doet, beginnen de rollen op de voorkeurssite tijdens een koude start van het cluster, en de voorkeurssite krijgt voorrang tijdens quorumonderhandelingen, waardoor de voorkeurssite, indien nodig, in leven blijft ten koste van de andere sites.

5.4.5. Schakel de everedigheid van knooppunten in en configureer deze

Onderhoud, failovers en andere activiteiten kunnen ertoe leiden dat virtuele machines op een Hyper-V-cluster zodanig worden gemigreerd dat sommige knooppunten overbelast raken, terwijl andere nauwelijks worden gebruikt. Windows Server 2016 bevat een functie genaamd node fairness, die de verdeling tussen de knooppunten in evenwicht probeert te brengen.

Eerlijkheid van knooppunten werkt door de geheugen- en CPU-belastingen op elk knooppunt in de loop van de tijd te evalueren, in een poging de overbelaste knooppunten te identificeren. Wanneer het cluster een overbelast knooppunt detecteert, wordt de belasting in evenwicht gehouden door VM’s live naar andere knooppunten te migreren die inactief zijn, terwijl er gelet wordt op  foutdomeinen en voorkeurseigenaren.

Eerlijkheid van knooppunten is standaard ingeschakeld, maar u kunt configureren of het wordt uitgevoerd en wanneer taakverdeling plaatsvindt. U kunt ook de agressiviteit configureren van de taakverdeling die optreedt. U doet dit in het eigenschappenblad van het cluster, op het tabblad Balancer, zoals weergegeven in de volgende afbeelding.

U kunt deze instellingen ook configureren met Windows PowerShell, met behulp van de volgende opdrachten:

De volgende opdracht specificeert of node fairness moet worden uitgevoerd en hoe vaak de belasting moet worden verdeeld, met behulp van de volgende waarden:

(Get-Cluster).AutoBalancerMode

• 0 – Knooppunt eerlijkheid is uitgeschakeld
• 1 – Load balancing vindt plaats wanneer een knooppunt lid wordt van het cluster
• 2 – Taakverdeling vindt plaats wanneer een knooppunt zich bij het cluster voegt en daarna elke 30 minuten. Dit is de standaardinstelling.

De volgende opdracht geeft de agressiviteit op waarmee de eerlijkheid van het knooppunt de belasting op elk knooppunt moet evalueren, met behulp van de volgende waarden:

(Get-Cluster).AutoBalancerLevel

• 1 – Laag. Migreert VM’s wanneer de host voor meer dan 80 procent is geladen. Dit is de standaardinstelling.
• 2 – Gemiddeld. Migreert VM’s wanneer de host voor meer dan 70 procent is geladen.
• 3 – Hoog. Migreert VM’s wanneer de host voor meer dan 60 procent is geladen.

5.5. Beheer VM verplaatsingen in geclusterde knooppunten

Zodra u een cluster hebt geïnstalleerd, geconfigureerd en operationeel hebt, zult u waarschijnlijk situaties tegenkomen waarin het nodig is om de distributie van virtuele machines over de clusterknooppunten te wijzigen. Windows Server 2016 biedt verschillende methoden voor het verplaatsen van VM’s en het controleren van hun gedrag wanneer ze worden verplaatst.

5.5.1. Voer een live migratie uit

Wanneer u een virtuele-machinerol op een cluster maakt, maakt u de virtuele machine zelf en configureert u deze voor hoge beschikbaarheid. Deze laatste actie, die u uitvoert met de wizard Hoge beschikbaarheid of de cmdlet Add-ClusterVirtualMachineRole in PowerShell, schakelt Live migratie in voor de rol. Het is niet nodig om de Hyper-V-server handmatig te configureren om Live Migration in te schakelen of een authenticatieprotocol te selecteren.

Zodra de virtuele machine in het cluster is gemaakt, is het uitvoeren van een livemigratie een kwestie van met de rechtermuisknop op de VM op de pagina Rollen klikken en in het contextmenu Verplaatsen | Live migratie. U kunt het cluster het beste knooppunt laten kiezen of een van de knooppunten in het cluster als doel selecteren, zoals weergegeven in de volgende afbeelding.

Om een livemigratie in PowerShell te starten, gebruikt u de Move-ClusterVirtualMachineRole-cmdlet, zoals in het volgende voorbeeld:

Move-ClusterVirtualMachineRole -Name clustervm1 -Node server2

5.5.2. Voer een snelle migratie uit

Quick Migration is de voorloper van Live Migration en was het oorspronkelijke hulpmiddel om een virtuele machine van het ene clusterknooppunt naar het andere te verplaatsen. Deze is grotendeels vervangen door Live Migration op Windows Server 2012, Quick Migration is nog steeds opgenomen in Windows Server 2016, omdat er situaties zijn waarin het nog steeds nuttig is.

Vergeleken met Live Migration, waarbij de overdracht van een VM van het ene knooppunt naar het andere in de meeste gevallen bijna onmiddellijk gebeurt, omvat snelle migratie wat gewoonlijk een korte pauze is. Net als bij een live migratie worden de databestanden niet verplaatst tijdens een snelle migratie.U kunt echter een snelle migratie uitvoeren op VM’s die actief of gestopt zijn. Voor een livemigratie moeten de VM’s actief zijn. In de praktijk gebruiken beheerders meestal alleen snelle migratie als ze geen live migratie kunnen uitvoeren.

Een typische snelle migratie van een actieve rol van een virtuele machine verloopt als volgt:

1. Het cluster pauzeert de rol van de virtuele machine, waardoor de I/O- en CPU-functies van de VM worden onderbroken.
2. Het cluster slaat de geheugeninhoud en systeemstatus van de bron-VM op in gedeelde opslag en plaatst de VM in de status Opgeslagen.
3. Het cluster kopieert de symbolische koppeling die de locatie van de bestanden van de bron-VM specificeert naar het doelknooppunt en draagt het eigendom van de bestanden van de bron-VM over naar de doel-VM.
4. Het cluster verwijdert de symbolische koppeling van de bron-VM.
5. Het cluster hervat de rol vanuit de opgeslagen status en kopieert de geheugeninhoud en de systeemstatus van gedeelde opslag naar de doel-VM, die nu wordt uitgevoerd op het doelknooppunt.

Het fundamentele verschil tussen snelle migratie en live migratie is dat een snelle migratie het geheugen van de VM eerst naar schijf kopieert en vervolgens van schijf naar de bestemming, terwijl een live migratie het geheugen rechtstreeks van de bron naar de bestemming kopieert. De lengte van de pauze bij een snelle migratie hangt af van de grootte van het geheugen van de VM en de prestaties van het opslagsubsysteem. De enige gegevens die rechtstreeks van de bron naar de doel-VM worden gekopieerd, is de kleine symbolische link.

Opmerking Snelle migratie in gestopte VM’s

Wanneer de virtuele machine is gestopt, vereist een snelle migratie alleen de overdracht van de symbolische link van de bron naar de bestemming. In dit geval is het proces bijna onmiddellijk.

Het effect van de pauze op de geclusterde rol is afhankelijk van de toepassingen die op de virtuele machine worden uitgevoerd. Sommige applicaties kunnen gemakkelijk herstellen van een pauze van een paar seconden, terwijl andere dat misschien niet doen. De situatie was echter belangrijk genoeg voor de ontwikkelaars van Windows Server 2012 dat de creatie van een bijna onmiddellijke migratietool, Live Migration, een topprioriteit voor hen was.

Het proces van het uitvoeren van een snelle migratie is bijna identiek aan dat van een live migratie. U klikt met de rechtermuisknop op de VM op de pagina Rollen en selecteert in het contextmenu Verplaatsen | Snelle migratie en kies het gewenste bestemmingsknooppunt. als de migratie doorgaat, kunt u zien dat de rol de status Opgeslagen en vervolgens de status Start krijgt als de rol wordt hervat.

5.5.3. Voer een opslagmigratie uit

Live Migration en Quick Migration zijn ontworpen om de geheugeninhoud en de systeemstatus van de ene virtuele machine naar de andere te verplaatsen. Ze verplaatsen niet de virtuele harde schijfbestanden die de VM gebruikt om het besturingssysteem, toepassingsbestanden en gegevens op te slaan. In een failovercluster wordt verwacht dat deze bestanden zich op gedeelde opslag bevinden, zodat de doel-VM er al toegang toe heeft.

Opslagmigratie heeft het tegenovergestelde effect: het verplaatst de virtuele harde schijfbestanden van een VM, maar niet het geheugen en de systeemstatus. Er zijn relatief weinig beperkingen aan opslagmigratie. De virtuele machine hoeft geen onderdeel te zijn van een cluster, dus je ziet hem zowel in Hyper-V als in Failover Clustering geïmplementeerd.

Op een zelfstandige Hyper-V-server kunt u de bestanden verplaatsen naar elke bestemming waartoe u toegang hebt, inclusief een andere locatie op dezelfde computer. Dit is handig, omdat het de VM bijwerkt met de nieuwe locaties van de bestanden terwijl deze worden gemigreerd.

In Hyper-V gebruikt u de wizard Verplaatsen om opslagmigraties uit te voeren, maar er is een ander hulpmiddel in Failover Cluster Manager. Wanneer u een clusterrol voor virtuele machines selecteert en klikt op Verplaatsen | Opslag virtuele machine, het dialoogvenster Opslag virtuele machine verplaatsen verschijnt, zoals weergegeven in de volgende afbeelding.

Examentip

Houd er bij het voorbereiden van het 70-740-examen rekening mee dat Storage Migration en Live Migration afzonderlijke processen zijn. In Hyper-V Manager integreert de Move Wizard Live Migration en Storage Migration-mogelijkheden in één interface, wat verwarrend kan zijn. Met deze wizard kunt u een virtuele machine naar een andere Hyper-V-host verplaatsen; u kunt de opslag van een VM verplaatsen, terwijl u de VM op zijn plaats laat; of u kunt zowel de VM als de opslag ervan verplaatsen naar een verschillende host, waardoor Live Migration en Storage Migration effectief worden gecombineerd. Onthoud echter dat dit twee afzonderlijke hulpmiddelen en twee afzonderlijke procedures zijn, hoewel de wizard het lijkt alsof het één proces is.

In dit dialoogvenster kunt u alle opgeslagen bronnen van de virtuele machine selecteren, inclusief afzonderlijke VHD- en VHDX-bestanden, controlepunten en Smart Paging-bestanden, en deze slepen en neerzetten naar een locatie in de clusteropslag. Een nieuwe waarde voor bestemmingsmappad wordt weergegeven en geeft aan waar de tool het bestand naartoe zal verplaatsen. Wanneer u bestemmingen hebt geselecteerd voor alle bestanden die u wilt verplaatsen, kunt u op de knop Start klikken om het dialoogvenster te sluiten en het opslagmigratieproces te starten.

5.5.4. VM’s importeren, exporteren en kopiëren

In Hyper-V heeft de mogelijkheid om VM’s te exporteren en te importeren verschillende nuttige doelen. Het is een eenvoudige, maar vervelende manier om een VM van de ene host naar de andere te verplaatsen, compleet met al zijn virtuele harde schijf, checkpoint en Smart Paging-bestanden, zonder de vereisten die nodig zijn voor Live Migration of Quick Migration. Het is ook een manier om een virtuele machine te kopiëren of te klonen, met alle updates, configuratie-instellingen en applicaties intact.

Hyper-V Manager biedt toegang tot een dialoogvenster Virtuele machine exporteren en een wizard Virtuele machine importeren, zoals beschreven in het hoofdstuk Hyper-V, maar een dergelijke interface is niet toegankelijk in Failover Cluster Manager. U kunt echter de cmdlets Export-VM en Import-VM in Windows PowerShell gebruiken om een geclusterde virtuele machine effectief te klonen.

Om een virtuele machine te exporteren, actief of gestopt, gebruik je een opdracht zoals het volgende:

Export-VM -Name clustervm1 -Path d:\vm

U kunt de opdracht uitvoeren vanaf elk knooppunt in het cluster, maar als u een lokale, niet-gedeelde schijf opgeeft voor de parameter Path, wordt de VM geëxporteerd naar het opgegeven pad op het knooppunt waar deze wordt uitgevoerd. Het specificeren van gedeelde opslag voor de padwaarde is daarom wenselijk.

Om de virtuele machine in de Hyper-V-host te importeren, kopieert u de bestanden naar de standaardmappen van de host en genereert u een nieuwe beveiligings-ID (SID) voor de VM. Gebruik een opdracht als de volgende om conflicten te voorkomen:

Import-VM -Path "d:\vm\virtual machines\5ae40946-3a98-428e-8c83-081a3c68d18c.xml" -Copy -GenerateNewID

Zodra het proces is voltooid, hebt u een nieuwe virtuele machine op die host. Als de Hyper-V-host is geconfigureerd om VM-bestanden standaard op gedeelde opslag op te slaan, kunt u Failover Cluster Manager gebruiken om die virtuele machine toe te voegen als een virtuele machine-rol en deze te configureren voor hoge Beschik baarheid.

5.5.5. Configureer de bescherming van de VM-netwerkgezondheid

Netwerkgezondheidsbescherming is een functie die detecteert of een virtuele machine op een clusterknooppunt een functionele verbinding heeft met een aangewezen netwerk. Als dit niet het geval is, migreert het cluster automatisch de VM-rol naar een ander knooppunt dat wel een verbinding met dat netwerk heeft.

Zonder deze functie kunnen geclusterde virtuele machines het contact verliezen met het netwerk dat ze zouden moeten onderhouden, en blijven draaien alsof er niets aan de hand is. Als het probleem eenvoudig is, zoals een losgekoppelde kabel, hebben andere knooppunten in het cluster mogelijk nog steeds toegang tot dat netwerk, en door de VM naar een van die knooppunten te migreren, kan deze operationeel blijven totdat de netwerkfout is verholpen.

Netwerkgezondheidsbescherming is standaard ingeschakeld, maar er zijn situaties waarin een beheerder mogelijk niet wil dat een livemigratie automatisch plaatsvindt. Als de clusterknooppunten bijvoorbeeld zijn uitgerust met verbindingen met redundante netwerken, wilt u misschien niet dat er livemigraties plaatsvinden als reactie op een netwerkstoring, terwijl het knooppunt al toegang heeft tot andere.

Om te bepalen of netwerkgezondheidsbescherming wordt toegepast, opent u het dialoogvenster Instellingen voor de VM, hetzij in Failover Cluster Manager of Hyper-V Manager, vouwt u de netwerkadapter uit die de verbinding met het betreffende netwerk levert en geeft u de optie Geavanceerde Functies-pagina weer, zoals weergegeven in de volgende afbeelding. Wanneer u het selectievakje Beveiligd netwerk uitschakelt, voorkomt u dat er livemigraties plaatsvinden vanwege fouten die in dat specifieke netwerk zijn gedetecteerd.

1.5.6 . Configureer leegmaken bij afsluiten

Als u een clusterknooppunt met VM’s wilt afsluiten voor onderhoud of om een andere reden, is de juiste procedure om de rollen van het knooppunt af te voeren (dat wil zeggen, ze live naar andere knooppunten te migreren) voordat u de machine afsluit. In Failover Cluster Manager doet u dit door een knooppunt te selecteren en op Pauze | Rollen Leegmaken te klikken in het deelvenster Acties. Als u op het tabblad Rollen onder aan de pagina klikt, zou u ze allemaal live moeten zien migreren naar een ander knooppunt in het cluster.

In PowerShell kunt u een knoop punt leegmaken met behulp van de Suspend-ClusterNode cmdlet, zoals in het volgende voorbeeld:

Suspend-ClusterNode

Op een bepaald moment, als u het knooppunt niet leegmaakte en het gewoon afsluit terwijl de rollen actief waren, zouden de rollen in de status Opgeslagen worden geplaatst, waardoor de service uitvalt totdat de VM’s naar een ander knooppunt verplaatst kunnen worden en hervat worden. Nu, Windows Server 2016 Failover Clustering bevat een functie genaamd leegmaken bij afsluiten, die automatisch alle rollen op een knooppunt live migreert voordat het systeem wordt afgesloten. Het is echter vermeldenswaard dat Microsoft nog steeds aanbeveelt om een knooppunt te pauzeren en leeg te maken voordat het afsluiten wordt gestart.

Leegmaken bij afsluiten is standaard ingeschakeld, zoals u kunt zien door de opdracht (Get-Cluster).DrainOnShutdown uit te voeren, zoals weergegeven in de volgende afbeelding. Een waarde van 1 geeft aan dat de functie is ingeschakeld en 0 is uitgeschakeld.

Om leegmaken bij afsluiten uit te schakelen, gebruikt u daarom de volgende opdracht:

(Get-Cluster).DrainOnShutdown = 0

5.6. Implementeer Network Load Balancing (NLB)

De basisfilosofie van een failovercluster is er een van fouttolerantie, waarbij één computer een service uitvoert terwijl andere inactief blijven, wachtend om als vervanging te dienen in het geval van een storing. Netwerktaakverdeling daarentegen is gebaseerd op het idee dat veel computers allemaal tegelijkertijd dezelfde service bieden. Deze opstelling biedt ook fouttolerantie, maar het primaire doel is om de verkeersbelasting over veel computers te verdelen, zodat het cluster meer clients tegelijk kan bedienen dan een enkele computer ooit zou kunnen.

5.6.1. Configureer NLB-vereisten

Network Load Balancing (NLB)-cluster kan bestaan uit 2 tot 32 servers, hosts genaamd, die elk een afzonderlijke kopie van de gewenste toepassing uitvoeren. NLB gebruikt vervolgens TCP/IP-adressering om inkomende clientverzoeken naar de verschillende hosts te sturen, waarbij de belasting onderling wordt verdeeld. NLB is het meest geschikt voor staatloze toepassingen, zoals webservers, met variabele clientbelastingen. Naarmate het verkeer toeneemt, is het mogelijk om hosts aan het cluster toe te voegen, waardoor de capaciteit toeneemt. U kunt ook gemakkelijk hosts verwijderen wanneer de clientbelasting wordt verminderd.

Examentip

Failover Clustering-clusters bestaan uit knooppunten, terwijl Network Load Balancing-clusters uit hosts bestaan. Onthoud dit onderscheid voor het 70-740-examen.

De NLB-hosts in een cluster wisselen eenmaal per seconde berichten uit die heartbeats worden genoemd. Met deze berichten kunnen ze de voortdurende functionaliteit van de andere hosts volgen. Wanneer de hartslag van een enkele host voor een bepaalde tijd stopt, verwijderen de andere hosts deze uit het cluster. Telkens wanneer een host wordt toegevoegd of verwijderd, voert het NLB-cluster een proces uit dat bekend staat als convergentie, waarbij het het huidige clusterlidmaatschap evalueert en bepaalt hoe clientverzoeken over de hosts moeten worden verdeeld.

Net als bij Failover Clustering heeft een NLB-cluster zijn eigen virtuele identiteit op het netwerk, met een naam en IP-adres die clients gebruiken om verbinding te maken met de toepassing. Als u bijvoorbeeld verbinding maakt met een grote website op internet, maakt u verbinding met een clusteradres met een mechanisme zoals NLB dat uw verzoek doorstuurt naar een van de computers in een serverfarm. Je hebt geen idee tot welke server je toegang hebt, en dat maakt ook niet uit, want ze bieden allemaal dezelfde service.

Omdat de toepassing op alle hosts in het cluster draait, zijn veel van de gecompliceerde onderhandelingen die nodig zijn voor failover-clustering niet nodig. Er is geen quorum, en daar zijn geen vragen waarvan de server een specifieke rol vervult. Ze zijn allemaal actief.

Netwerktaakverdeling is dus veel eenvoudiger in te stellen en te beheren dan Failover Clustering en heeft minder vereisten.

5.6.1.1. Hardware vereisten

NLB-clusters kunnen maximaal 32 hosts ondersteunen. Over het algemeen is er geen gedeelde opslag of andere gespecialiseerde hardware vereist voor NLB. In tegenstelling tot een failovercluster mogen de computers die u gebruikt om NLB-hosts te maken niet identiek zijn. Ze moeten echter vergelijkbaar zijn in hun mogelijkheden, zodat sommige hosts niet aanzienlijk slechter presteren dan andere.

Alle hosts in een NLB-cluster moeten zijn verbonden met hetzelfde subnet en de netwerklatentie moet worden geminimaliseerd om het convergentieproces normaal te laten verlopen. De hosts hoeven zich niet in dezelfde serverkast of hetzelfde datacenter te bevinden, maar als de computers over lange afstanden worden verspreid, kunnen hosts uit het cluster worden verwijderd.

Opmerking Sitegebaseerde fouttolerantie voor NLB

Om site-gebaseerde fouttolerantie te bieden in het geval van een grootschalige ramp, is de beste praktijk om afzonderlijke NLB-clusters op verschillende locaties te maken en een ander mechanisme te gebruiken om clientverzoeken tussen de twee sites te verdelen. DNS-round robin is bijvoorbeeld een techniek waarmee de DNS-servers die de clusternaam oplossen, verschillende IP-adressen kunnen leveren aan opeenvolgende verzoeken. Dit zou het inkomende verkeer effectief verdelen over de sites, en NLB zou het opnieuw verdelen over de hosts op elke site.

De NLB-hosts kunnen zoveel netwerkinterfaceadapters hebben als nodig zijn voor andere doeleinden, maar de netwerkadapters die voor NLB worden gebruikt, moeten allemaal multicast- of unicast-transmissies gebruiken. De clusterparameters en specifiek de Cluster Operation Mode beïnvloeden de hardwareconfiguratie van uw netwerk. Omdat dit is geselecteerd bij het instellen van het NLB-cluster, moet u op dat moment rekening houden met dit punt.

5.6.1.2. Softwarevereisten

Netwerktaakverdeling heeft enkele softwareconfiguratievereisten waarmee u rekening moet houden voordat u een NLB-cluster maakt, waaronder de volgende:

• Besturingssysteem – Windows Server heeft netwerktaakverdeling in verschillende versies ondersteund en de implementaties sinds Windows Server 2008 zijn grotendeels hetzelfde. Het is echter het beste om alle hosts in een NLB-cluster dezelfde versie en dezelfde editie van Windows Server te laten uitvoeren.
• IP-adressen – Alle hosts in een NLB-cluster moeten statische IP-adressen hebben. NLB ondersteunt het gebruik van Dynamic Host Configuration Protocol (DHCP) niet en schakelt de DHCP-client uit op de computers die u als hosts configureert. Daarom moet u op de hoogte zijn van de IP-adressering die op het subnet wordt gebruikt en over de juiste IP-adressen beschikken die u aan de hosts en het cluster kunt toewijzen. Als het subnet DHCP gebruikt voor zijn andere computers, moet u adressen hebben die buiten het DHCP-bereik vallen.
• Lokale gebruikersaccounts – Alle hosts in een NLB-cluster moeten een identieke gebruikersaccount hebben, met lidmaatschap van de lokale groep Administrators, die de Network Load Balancing Manager zal gebruiken om ze te openen. Zonder identieke accounts moet u authenticatiegegevens opgeven voor elke host die u bezoekt. Hoewel lidmaatschap van een Active Directory Domain Services-domein niet vereist is voor een NLB-cluster, wordt het beheer eenvoudiger, omdat de AD DS-domeinbeheerdersgroep lid is van de lokale beheerdersgroep op elke aangesloten computer.

5.6.2. Installeer NLB-knooppunten

Netwerktaakverdeling, zoals Failover Clustering, is een functie die is opgenomen in Windows Server 2016. U moet de functie installeren op alle servers die als NLB-hosts zullen functioneren, met behulp van de wizard Rollen en functies toevoegen in Serverbeheer. Of u kunt deze functie installeren met behulp van de cmdlet Install-WindowsFeature in Windows PowerShell met de volgende opdracht:

Install-WindowsFeature -Name nlb -IncludeManagementTools

U kunt de hulpprogramma’s voor NLB-beheer ook zonder de functie NLB installeren om een cluster vanaf een extern werkstation te beheren met de volgende opdracht:

Install-WindowsFeature -Name rsat-nlb

Nadat de functie op alle servers is geïnstalleerd, kunt u doorgaan met het maken van een NLB-cluster met behulp van de volgende procedure.

1. Start de Network Load Balancing Manager-console, vanuit het menu Tools in Server Manager.
   
2. Klik in het menu Cluster op Nieuw.
3. Typ op de pagina Nieuw cluster: verbinding maken, in het tekstvak Host de naam van de eerste host die u aan het cluster wilt toevoegen (zelfs als dit de naam van de lokale computer is) en klik op Verbinden. De interface(s) en IP-adres(sen) van de computer verschijnen.
   
4. Selecteer de interface die de host voor het cluster zal gebruiken.
5. Geef op de pagina Nieuw cluster: Hostparameters een waarde voor Prioriteit (Unique Host Identifier) op met behulp van de vervolgkeuzelijst. Deze waarde moet uniek zijn op elke host die u installeert. Verkeer dat niet voldoet aan de poortregels die voor het cluster zijn geconfigureerd, wordt doorgestuurd naar de host met de laagste prioriteitswaarde.
6. Klik op de pagina Nieuw cluster: IP-adressen van clusters op Toevoegen.
7. Geef in het dialoogvenster IP-adres toevoegen, de waarden voor het IPv4-adres en het subnetmasker op die het cluster zal gebruiken en klik op OK. Hiermee wordt de virtuele identiteit voor het cluster gemaakt, die wordt toegevoegd aan de netwerkadapterconfiguratie van elke host in het cluster.
   
8. Geef op de pagina Nieuw cluster: Clusterparameters, de waarde Volledige internetnaam voor het cluster op. Dit is de naam die clients gebruiken om verbinding te maken met de toepassing die op het cluster wordt uitgevoerd. Voor een webservercluster is dit bijvoorbeeld de servernaam in de URL van de website.
   
9. Selecteer in het vak Clusterbewerkingsmodus een van de volgende waarden:
   • Unicast – Geeft aan dat het cluster een unicast Media Access Control (MAC)-adres moet gebruiken voor clustercommunicatie.
   • Multicast – Geeft aan dat het cluster een multicast-MAC-adres moet gebruiken voor clustercommunicatie.
   • IGMP Multicast – Geeft aan dat het cluster een multicast-MAC-adres moet gebruiken voor clustercommunicatie, met IGMP (Internet Group Messaging Protocol), om te voorkomen dat poorten vol raken.
10. Klik op de pagina Nieuw cluster: Poortregels, op Bewerken om de standaardpoortregel te wijzigen.
    
11. Wijzig in het dialoogvenster Poortregel toevoegen/bewerken, de poortbereikinstellingen om de poort(en) op te geven voor de toepassing die het cluster zal uitvoeren.
    
12. Selecteer in het vak Filtermodus een van de volgende opties en klik op OK om de instellingen in de poortregel te wijzigen.
    1. Multiple Host – Hiermee kan inkomend verkeer dat voldoet aan de poortregel worden afgehandeld door meerdere clusterhosts. Selecteer een Affiniteitsinstelling om op te geven hoe herhaald verkeer van clients over hosts wordt verdeeld.
    1. Single Host – Hiermee kan inkomend verkeer dat voldoet aan de poortregel, worden afgehandeld door een enkele clusterhost.
    1. Disable This Port Range – Zorgt ervoor dat het cluster al het verkeer blokkeert dat de poortregel bevestigt.
13. Klik op Voltooien.

U hebt nu een NLB-cluster gemaakt en de eerste host geconfigureerd. Om extra hosts aan de cluster toe te voegen, selecteert u deze in de console en klikt u op Cluster | Gastheer toevoegen. Voor elke host die u toevoegt, moet u alleen de pagina’s Verbinden, Hostparameters en Poortregels configureren. Terwijl u elke host toevoegt, convergeert het cluster totdat alle hosts zijn herkend en in het cluster zijn opgenomen, zoals weergegeven in de volgende afbeelding.

5.6.3. Configureer affiniteit

Wanneer u de instelling Filtermodus in een poortregel configureert, geeft u op hoe het cluster het verkeer afhandelt dat aan die poortregel voldoet. Als u Single selecteert, gebruikt u in wezen NLB als een failovercluster voor die regel, met fouttolerantie, maar zonder schaalbaarheid. Alleen de host met de laagste prioriteitswaarde zal verkeer voor die regel afhandelen. Als die host zou falen, zou de host met de volgende laagste prioriteit het overnemen.

Als u Uitschakelen selecteert, wordt voorkomen dat het cluster verkeer accepteert dat aan de regel voldoet. U gebruikt deze instelling om een regel te maken die verkeer blokkeert via een specifiek IP-adres of specifieke poort.

Wanneer u de optie Multiple Host selecteert, wordt het verkeer dat aan die regel voldoet, verdeeld over alle hosts van het cluster. Dit biedt zowel fouttolerantie als schaalbaarheid. Het potentiële probleem met deze opstelling is dat een client mogelijk de verbinding verbreekt en opnieuw verbinding maakt met het cluster, en naar een andere host wordt gestuurd.

Voor sommige toepassingen is dit geen probleem. Als u bijvoorbeeld een webserver gebruikt die alleen statische pagina’s biedt, maakt het niet uit of een client van de ene host naar de andere wordt verplaatst. Voor een e-commercewebsite zou het onderbreken van een sessie en het verplaatsen van de client naar een andere host de transactie echter onderbreken. De affiniteitsinstellingen voor de optie Meerdere hosts lossen dit probleem op.

De Affinity-instelling die u kiest, geeft aan hoe het cluster moet reageren op herhaalde verzoeken van dezelfde client. De beschikbare instellingen zijn als volgt:

• Geen – Zonder clientaffiniteit kunnen inkomende verzoeken van hetzelfde IP-adres door elke host worden afgehandeld. Vermijd deze instelling voor op transacties gebaseerde toepassingen die consistente verbindingen met één host vereisen. U moet deze instelling ook vermijden wanneer de regel UDP of Beide gebruikt voor de instelling Protocollen, zodat IP-fragmenten niet naar verschillende hosts worden verzonden.
• Single – Deze instelling zorgt ervoor dat al het verkeer dat van een enkel IP-adres komt, naar dezelfde host wordt gestuurd. Als een client de verbinding verbreekt, zal een nieuwe verbinding hetzelfde bron-IP-adres gebruiken, en NLB zal dit herkennen en het verkeer dienovereenkomstig doorsturen, zodat de sessie kan doorgaan.
• Netwerk – Met deze instelling kan al het verkeer dat afkomstig is van hetzelfde klasse C-netwerk naar dezelfde host worden verzonden. In sommige gevallen kunnen clients verschillende proxyservers op hetzelfde netwerk gebruiken wanneer ze verbinding maken met het cluster. Zolang die proxyservers zich op hetzelfde subnet bevinden, zal NLB herkennen dat het verkeer waarschijnlijk afkomstig is van dezelfde client en het naar een enkele host verzenden.

Schakel het selectievakje Time-out in om de maximale hoeveelheid tijd op te geven die tussen verbindingen mag verstrijken voordat de affiniteitsregel niet langer van toepassing is.

5.6.4. Configureer poortregels

Poortregels bepalen welke typen TCP/IP-verkeer het NLB-cluster moet afhandelen en hoe elk type moet worden verwerkt. Wanneer u voor het eerst een cluster maakt, staat de standaardpoortregel verkeer toe dat alle IP-adressen en alle poorten gebruikt. U kunt deze regel naar behoefte wijzigen en andere maken om verschillende instellingen voor verschillende soorten verkeer te specifiëren.

Naast de instellingen voor Filtermodus en Affiniteit die al zijn beschreven, zijn de beschikbare instellingen in een poortregel als volgt:

• Cluster IP-adres – Een cluster kan meerdere IP-adressen hebben, die verschillende services vertegenwoordigen, zoals verschillende websites die worden gehost door Internet Information Services (IIS). Door een specifiek adres te selecteren, kunt u voor elke service een andere regel maken. Door het selectievakje Alles in te schakelen, wordt een algemene regel gemaakt voor alle IP-adressen van het cluster.
• Poortbereik – Een cluster kan ook services leveren die verschillende poorten gebruiken. De bekende poort voor een webserver is bijvoorbeeld 80, maar de bekende poort voor een beveiligde webserver is 443. Als u NLB gebruikt om het verkeer te verdelen voor een webserver waarop meerdere sites worden uitgevoerd, kunt u een regel voor elke site door het IP-adres op te geven en/of het poortnummer. Een site die statische webpagina’s biedt, kan de filtermodus voor meerdere hosts gebruiken zonder clientaffiniteit, maar voor een veilige e-commercesite die op slechts één host wordt ondersteund, kunt u de filtermodus voor één host gebruiken.
• Protocollen – Geeft aan of de regel van toepassing moet zijn op TCP-, UDP-verkeer of beide. TCP wordt meestal gebruikt voor langere transacties waarvoor meerdere pakketten nodig zijn, terwijl UDP vaak wordt gebruikt voor snelle verzoek-/antwoordtransacties. Afhankelijk van de toepassing die u op het cluster uitvoert, wilt u mogelijk verschillende affiniteitsinstellingen configureren voor elk protocol.

Wanneer u de poortregels opent via het Eigenschappenblad voor een van de hosts, zoals weergegeven in onderstaande afbeelding, kunt u de eerder genoemde regelinstellingen niet wijzigen, maar er zijn twee hostspecifieke instellingen die u als volgt kunt configureren:

• Laadgewicht – Alleen toegankelijk in meervoudige hostmodus, specificeert hoeveel van het verkeer dat aan de regel voldoet, moet worden afgehandeld door de geselecteerde host. De standaardinstelling is om het verkeer gelijk te verdelen, maar u kunt een relatieve waarde van 0 tot 100 opgeven.
• Afhandelingsprioriteit – Alleen toegankelijk in de modus voor één host, specificeert een prioriteit voor de afhandeling door de host van het verkeer in overeenstemming met de regel. De host met de laagste waarde zal al het verkeer voor de regel afhandelen.

5.6.5. Configureer de clusterwerkingsmodus

De instelling Cluster Operation Mode specificeerde wat voor soort TCP/IP-verkeer de clusterhosts moesten gebruiken. Een unicast is een TCP/IP-transmissie die is geadresseerd aan een enkele bestemming. Een multicast is een verzending die naar meerdere bestemmingen wordt verzonden met behulp van een speciaal multicast-IP-adres.

Het MAC-adres is een unieke waarde van zes bytes die in de fabriek in netwerkinterfaceadapters is gecodeerd. Wanneer u de unicast-modus voor een cluster selecteert, vervangt NLB het hardware-MAC-adres op de interface die u voor elke host selecteert door het virtuele MAC-adres van het cluster. Dit zorgt ervoor dat verkeer dat is geadresseerd aan het cluster, naar al zijn hosts gaat. Deze praktijk verwart ook uw netwerkswitches, die niet kunnen bepalen tot welke poort het MAC-adres van het cluster behoort, en daarom het verkeer via al zijn poorten moeten doorsturen, waardoor het netwerk wordt overspoeld.

Unicast-modus voorkomt ook dat clusterhosts met elkaar communiceren via hun aangewezen clusteradapters. Omdat alle hosts hetzelfde MAC-adres gebruiken, loopt het uitgaand verkeer terug en bereikt het het netwerk nooit. U moet daarom in elke host een tweede netwerkadapter installeren als u van plan bent de unicast-modus te gebruiken en normale communicatie tussen de hosts nodig heeft.

Wanneer u de multicast-optie selecteert, voegt NLB een tweede MAC-adres toe aan de netwerkinterface op elke host. Dit is een multicast-MAC-adres dat het oorspronkelijke adres niet vervangt. Omdat elke host zijn unieke MAC-adres behoudt, is er geen tweede netwerkadapter nodig. De multicast-optie veroorzaakt standaard ook switch-flooding, maar daar zijn oplossingen voor. De IGMP-multicastoptie gebruikt het Internet Group Management Protocol om de switches te programmeren, zodat verkeer dat bestemd is voor het MAC-adres van het cluster alleen wordt doorgestuurd via de switchpoorten die zijn aangesloten op NLB-hosts. Beheerders kunnen ook een virtueel lokaal netwerk (VLAN) in de switch maken waarmee dezelfde resultaten worden bereikt.

Multicast-modus heeft de voorkeur, behalve in gevallen waarin uw netwerkhardware geen multicast-transmissies ondersteunt of het gebruik van multicasts de clusterprestaties ernstig vermindert.

5.6.6. Upgrade een NLB-cluster

Er zijn twee manieren om een bestaand Windows Server NLB-cluster te upgraden naar Windows Server 2016-versie:

• Gelijktijdige upgrade – Bij deze optie haalt u het hele NLB-cluster naar beneden, upgradet u alle hosts en brengt u het cluster weer omhoog. Dit brengt uiteraard een aanzienlijke hoeveelheid downtime met zich mee voor de geclusterde applicatie. Dit is alleen een haalbare optie als u het prettig vindt om uw toepassing een tijdje niet beschikbaar te houden, of als u een back-upcluster beschikbaar heeft om zijn plaats in te nemen.
• Doorlopende upgrade – Bij deze optie verwijdert u de hosts één voor één uit het cluster, voert u een upgrade uit en voegt u deze vervolgens weer toe aan het cluster. NLB is ontworpen om het toevoegen en verwijderen van hosts mogelijk te maken, zodat het cluster convergeert telkens wanneer u een van de servers verwijdert of toevoegt.

5.7. Samenvatting

• Hyper-V Replica is een functie die de opslag van virtuele machines kan dupliceren, synchroon of asynchroon.
• Live migratie is het proces waarbij het geheugen en de systeemstatus van een virtuele machine vrijwel onmiddellijk worden overgedragen van het ene clusterknooppunt naar het andere.
• Opslagmigratie is een proces waarbij de virtuele harde schijfbestanden van een VM van de ene naar de andere locatie worden verplaatst, op dezelfde of een andere Hyper-V-host.
• Windows Server 2016 ondersteunt failoverclusters met knooppunten in een enkel domein, in meerdere domeinen en in werkgroepen.
• Quorum is de stemprocedure die clusters gebruiken om te bepalen of het moet blijven draaien of afsluiten tijdens een storing.
• Failoverclusters vereisen gedeelde opslag, zodat de toepassingen die op de clusterknooppunten worden uitgevoerd, kunnen blijven functioneren, ondanks een knooppuntstoring.
• Clusterbewust bijwerken is een functie die ervoor zorgt dat alle knooppunten in een failovercluster tijdig dezelfde updates ontvangen.
• Cluster Operating System Rolling Upgrade is een nieuwe operationele modus waarmee clusterknooppunten met verschillende besturingssystemen tijdelijk naast elkaar kunnen bestaan.
• Gedeelde clustervolumes zijn gedeelde opslag die tegelijkertijd beschikbaar is op alle knooppunten van een cluster.
• Gastclustering is wanneer u een failovercluster maakt met behulp van virtuele machines op Hyper-V-servers.
• Een cloudgetuige is een stemquorumlid dat zich in Microsoft Azure bevindt en de beslissende stem geeft voor clusters met meerdere locaties.
• Met Storage Spaces Direct kunt u gedeelde clusteropslag maken met behulp van de lokale schijven in de knooppunten.
• Storage Spaces Direct kan gedeelde opslag bieden voor een afzonderlijk cluster of voor rollen die in hetzelfde cluster worden uitgevoerd.
• Met VM-bewaking kunt u een service opgeven die op een virtuele machine wordt uitgevoerd, zodat het cluster actie kan ondernemen als de service mislukt.
• Een stretchcluster is een cluster dat is verdeeld over twee of meer locaties. Sitebewustzijn is de mogelijkheid om clusterknooppunten met hun sites te configureren, om hun failover-gedrag te controleren.
• Om livemigraties en opslagmigraties uit te voeren, kunt u Failover Cluster Manager of Windows PowerShell-cmdlets gebruiken.
• Quick Migration, de voorloper van Live Migration, kopieert geheugeninhoud naar gedeelde opslag en vervolgens naar het bestemmingsknooppunt.
• Netwerkgezondheidsbeveiliging geeft automatisch een failover van een rol naar een ander knooppunt wanneer een netwerk niet toegankelijk is.
• Netwerktaakverdeling is een functie van Windows Server 2016 waarmee u clusters kunt maken waarin alle servers tegelijkertijd dezelfde toepassing uitvoeren.
• NLB-clusters hebben hun eigen identiteit, met namen en IP-adressen die clients gebruiken om toegang te krijgen.
• Als u een NLB-cluster wilt maken, gebruikt u Network Load Balancing Manager om elke host toe te voegen en de instellingen voor de hosts en het cluster te configureren.
• Met poortregels kunt u de typen verkeer identificeren die NLB-clusterhosts kunnen verwerken door IP-adressen, protocollen en poorten op te geven.