Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 2
Generelle Informationen
Dieser Blogpost ist der zweite von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich vor kurzem geschrieben habe und welches exklusiv für Newsletter-Abonnenten zur Verfügung steht. Sie können das vollständige Whitepaper als PDF weiterhin erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.
Alle fünf Teile
Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 1
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 2
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 3
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 4
Installation und Einrichtung des Betriebssystems
Die Einrichtung startet mit einer Grundinstallation von Windows Server 2016 in der Datacenter Edition. Für diesen Beitrag nutze ich die Evaluation Version von Microsoft, die kostenlos verfügbar ist und 180 Tage zu Testzwecken genutzt werden kann.
Nun muss als erstes eine feste IP-Adresse konfiguriert werden, hierfür wird ein Team aus den beiden 1 Gbps Adaptern benötigt. Ich starte mit der Umbenennung der Karten in der Systemsteuerung.
Get-NetAdapter | where InterfaceDescription -eq „Intel(R) 82574L Gigabit Network Connection“ | Rename-NetAdapter -NewName „Mgmt#1“
Get-NetAdapter | where InterfaceDescription -eq „Intel(R) 82574L Gigabit Network Connection #2“ | Rename-NetAdapter -NewName „Mgmt#2“
Get-NetAdapter | where InterfaceDescription -eq „Intel(R) Ethernet Converged Network Adapter X540-T2“ | Rename-NetAdapter -NewName „VM#1“
Get-NetAdapter | where InterfaceDescription -eq „Intel(R) Ethernet Converged Network Adapter X540-T2 #2“ | Rename-NetAdapter -NewName „VM#2“
Get-NetAdapter | where InterfaceDescription -eq „Emulex OneConnect OCe14102-NT, NIC“ | Rename-NetAdapter -NewName „SMB#1“
Get-NetAdapter | where InterfaceDescription -eq „Emulex OneConnect OCe14102-NT, NIC #2“ | Rename-NetAdapter -NewName „SMB#2“
Ein Wort zur Windows Firewall
Wir erleben häufig bei Kunden, dass die Windows Firewall sofort deaktiviert werden soll oder sogar schon ist, begründet wird dieses Verhalten häufig mit "Wir haben eine super Firewall Richtung Internet" oder "Das haben wir schon immer so gemacht" oder mit "die stört eh nur". Falls nicht bereits geschehen, sollten Sie dieses Verhalten dringend überdenken. Deaktivieren Sie die lokale Firewall, steht das System in Ihrem Netzwerk mit heruntergelassener Hose da. Der Betrieb der Firewall ist nicht im Ansatz hinderlich, wenn man sich einmal 10 Minuten damit befasst und die entsprechenden Regeln konfiguriert bzw. konfigurieren lässt, z.B. per GPO. Die meisten Dienste und MS-Applikationen schalten sich selbst in der Windows Firewall frei, spontan fällt mir nur die Hyper-V Replikation ein, die nicht automatisch eingeschaltet wird - hier muss ich allerdings nur eine bzw. zwei vordefinierte Regeln mit einem Klick einschalten. Bringt jemand (mit oder ohne Absicht) Schadcode in Ihr Netzwerk und dieser versucht sich per Netzwerk zu verteilen, kann er Systeme ohne aktivierte Firewall deutlich leichter übernehmen und attackieren als Systeme mit eingeschalteter Firewall. Lassen Sie die Firewall eingeschaltet.
Die Nutzung von einem Anti-Virus-Agent auf dem Hyper-V Host
Wenn Sie auf ihrem Hyper-V Host einen Anti-Virus-Agenten betreiben wollen oder müssen, müssen Sie unbedingt darauf achten, dass Sie für den Agenten Ausnahmen definieren. Tun Sie dies nicht, so laufen Sie Gefahr, dass die Anti-Virus-Lösung Prozesse unterbindet und es zu Fehlermeldungen oder Problemen im Betrieb kommt. Microsoft hat im TechNet eine Liste der Pfade, Prozesse oder Programme aufgeführt, die Sie unbedingt ausschließen müssen. Sie finden die Liste hier:
Recommended antivirus exclusions for Hyper-V hosts
Wichtig: In dem Artikel wird die Dateiendung .bin nicht erwähnt. Diese wird, je nach Version von Hyper-V, ebenfalls genutzt. Setzen Sie Hosts mit Windows Server 2012 R2 oder früher ein, nehmen Sie diese Endung auch mit auf.
Grundsätzlich stellt sich die Frage, ob ein Hyper-V Host einen Anti-Virus-Agenten haben sollte. Windows Server 2016 bringt den Microsoft-eigenen Defender mit, dieser ist völlig ausreichend. Schon mit vorherigen Versionen von Windows haben wir für uns entschieden, auf einen Virenschutz auf dem Host zu verzichten. Stellen Sie das System nicht direkt ans Internet, nutzen Sie den Host nicht zum Surfen und Herunterladen von Software, Treiber usw. und (wer hätte es gedacht ;)) lassen Sie die Windows Firewall eingeschaltet. Damit fahren Sie schon ziemlich gut, unter anderem auch deshalb, weil auf dem Hyper-V im Management OS nix betrieben werden sollte außer die Virtualisierung, ein Backup und ein Monitoring.
Die Erstellung des Management Teams
Nachdem nun alle Karten den von uns gewünschten Namen haben, können wir mit der Vergabe der IP-Adressen und der Erstellung der benötigten Teams fortfahren. Das Team auf dem Management-Adapter ist sehr wichtig, über dieses Netzwerk erfolgt eine Kommunikation mit der Active Directory, ein Management über ein anderes System und zusätzlich ein Heartbeat der Server untereinander. In dem folgenden Skript setze ich direkt die korrekte IP-Adresse, Subnetzmaske sowie den DNS Server. Ein Standardgateway könnte ebenfalls noch eingetragen werden, in meinem Fall arbeite ich aber ohne.
New-NetLBFOTeam -Name „Mgmt-Team“ -TeamNICName „Mgmt-Team“ -TeamMembers Mgmt#1, Mgmt#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false
sleep 5
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 23 -InterfaceAlias „Mgmt-Team“ -IPAddress 192.168.209.17
Set-DnsClientServerAddress -InterfaceAlias „Mgmt-Team“ -ServerAddresses („192.168.209.2“)
Hinweis: Das sleep in der zweiten Zeile ist notwendig, wenn die Befehle zusammen ausgeführt werden. Dies liegt daran, dass nach der Erstellung von dem Team noch kurz eine Installation des Teaming-Adapters gemacht wird. Dies dauert einen kurzen Moment. Würde Zeile 3 direkt danach ausgeführt kann es vorkommen, dass der Teaming-Adapter noch nicht zur Verfügung steht und daher schlägt die Adressvergabe fehl.
Tipp: Versuchen Sie, in den unterschiedlichen Netzwerken die gleiche Endadresse zu benutzen. Dies macht ein Management deutlich einfacher und vereinfacht die Verwaltung und die "Erkennung" von einem Server bzw. einer Adresse.
Die Erstellung des Teams für die Hyper-V Switch
Um eine redundante und hochverfügbare Anbindung der VMs zu ermöglichen, benötigen wir noch ein weiteres Team für die Hyper-V Switch, die wir im späteren Verlauf erzeugen. Anders als bei dem Management-Team setzen wir keine IP-Adresse auf diesen Team-Adapter, er wird später ausschließlich für die VMs genutzt.
New-NetLBFOTeam -Name „VM-Team“ -TeamNICName „VM-Team“ -TeamMembers VM#1, VM#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false
Aufnahme in die Active Directory und Update der Systeme
Nachdem wir nun Adressen vergeben haben, können wir die Server in die Domäne "powerkurs.local" aufnehmen und einen neuen Namen konfigurieren. Nach der Aufnahme müssen wir die Server einmal durchstarten, danach können wir mit der Installation der Updates beginnen.
Tipp: Bekommen Sie bei der Änderung des Namens oder bei der Aufnahme des Systems in die Active Directory einen "allgemeinen Fehler" bzw. einen „generic error“, so müssen Sie das System einmal durchbooten. Gerade bei der "RTM"-Version kommt mir dieser Fehler sehr häufig entgegen, gelöst wird es dann durch einen erneuten Reboot des Systems. Danach ist ein Umbenennen oder ein Domänenbeitritt problemlos möglich.
Der PowerShell-Befehl zur Aufnahme des Systems in die Active Directory sieht wie folgt aus:
Add-Computer -Domain „powerkurs.local“ -NewName „Hyperv17“ -Credential powerkursadmin17 -Restart
Nun beginnt die Installation der Updates, dies kann teilweise mehr als eine Stunde dauern, abhängig von der verfügbaren Bandbreite und der Leistung der Server.
Nach einem Update des Windows Betriebssystems selbst müssen häufig noch weitere Komponenten geupdatet werden, unter anderem Netzwerkkarten-Treiber, Netzwerkkarten-Firmware, Controller, BIOS und noch vieles mehr. Machen Sie sich an dieser Stelle die Arbeit und installieren Sie alle verfügbaren Treiber, Updates und sonstiges, wer weiß wann Sie nach einer Inbetriebnahme noch einmal die Gelegenheit dazu haben.
Ich muss auf unseren Systemen noch die Emulex-Treiber sowie den Manager zur Administration der Karten installieren, dies geht per PowerShell in einer "silent installation" ohne eine Abfrage der Einstellungen.
Start-Process -FilePath „C:SystemEmulexbrcmdrvr-nic-11.2.1153.13-4.exe“ -ArgumentList „/q1“ -Wait
Start-Process -FilePath „C:SystemEmulexbrcmOneInstall-Setup-11.2.1153.25.exe“ -ArgumentList „/q1“ -Wait
Nach der Installation ist der Manager auf dem System und in den Eigenschaften der Emulex-Karten sind einige Optionen hinzugekommen:
Die Konfiguration der SMB Netzwerkkarten
Die beiden verbleibenden Netzwerkkarten mit den Namen SMB#1 und SMB#2 müssen vor einer Überprüfung durch den Failovercluster-Manager noch konfiguriert werden. In meinem Fall benötige ich ein VLAN auf den beiden Karten und eine IP-Adresse. Die End-Adresse der Karten ist jeweils die gleiche (z.B. 17 beim Hyperv17), nur die logischen Subnetze ändern sich (Ich nutze in meinem Fall 192.168.207.0/24 und 192.168.206.0/24).
Set-NetAdapter -Name SMB#1 -VlanID 812 -Confirm:$false
Set-NetAdapter -Name SMB#2 -VlanID 812 -Confirm:$false
Set-NetIPInterface -InterfaceAlias “SMB#1” -dhcp Disabled
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias „SMB#1“ -IPAddress 192.168.207.17
Set-NetIPInterface -InterfaceAlias “SMB#2” -dhcp Disabled
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias „SMB#2“ -IPAddress 192.168.206.17
Die Bindungen und Einstellungen der Karten sehen wie folgt aus:
Hinweis zu IPv6
Wenn Sie sich bei dem obigen Screenshot fragen, warum IPv6 nicht deaktiviert wurde: Es tut nicht weh :) Wir hatten noch keinerlei Probleme bei aktiviertem IPv6, laut Microsoft sollte es auch eingeschaltet bleiben. Wenn Sie unbedingt möchten können Sie hier den Haken entfernen, was aber gar nicht geht ist eine Deaktivierung per Registry, davon sollten Sie unbedingt Abstand nehmen!
Im nächsten Teil der Reihe geht es um die Einrichtung von RDMA (RoCE), die Installation der benötigten Rollen und Features sowie die Einrichtung des Failover Clusters.
