Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 5
Generelle Informationen
Dieser Blogpost ist der fünfte 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 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 Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 5
Die Nutzung von iSCSI oder Fibre Channel Storage
Kommen statt SMB3 Shares LUNs zum Einsatz, so sind diese erfahrungsgemäß per iSCSI oder per Fibre Channel angeschlossen. Dieser Teilbereich geht auf die Änderungen und Anpassungen ein, die bei der Nutzung von solch einem SAN-System zu beachten ist.
Die Anbindung an das Storage-System
Kommt Fibre Channel zum Einsatz, so müssen die Server mindestens einen FC HBA besitzen, meist ist ein Dual Port-Controller oder zwei Controller im Einsatz. Installieren Sie die aktuellste Firmware sowie den aktuellsten Treiber vor der Einrichtung.
Bei der Nutzung von iSCSI sollten Sie ebenfalls auf die aktuellsten Treiber und Firmware-Stände achten, weiterhin sollten die Netzwerkkarten (ich gehe einfach mal davon aus, dass grundsätzlich eine Redundanz besteht) ausschließlich eine IPv4 oder IPv6-Bindung haben:
Weiterhin sollten DNS- und NetBIOS-Einstellungen angepasst werden:
MPIO
Als nächstes müssen wir, egal ob iSCSI oder FC, die Multipath-Funktion (MPIO) aktivieren. Dieses geschieht über den Server-Manager und benötigt seit Windows Server 2016 einen Neustart, bisher war die Installation ohne einen Neustart möglich, erst die Aktivierung brauchte einen Neustart. Nun dürfen wir zwei Mal einen neuen Kaffee holen :)
Kein Teaming bei iSCSI
Ich sehe immer wieder Installationen, bei denen die iSCSI-Karten zu einem Team zusammengefasst wurden. Diese Art von Betrieb ist nicht unterstützt, die iSCSI-Karten müssen und dürfen ausschließlich per MPIO betrieben werden. Wir haben schon die unterschiedlichsten Verhalten und Fehler gesehen, wenn iSCSI-Karten geteamt betrieben werden.
Wir beginnen nun mit der Installation von MPIO und dem Neustart der Server:
Install-WindowsFeature -Name Multipath-IO
Ist der Server wieder da, können wir MPIO konfigurieren. Dies geschieht entweder über den Server-Manager im Reiter Tools, über das Startmenü oder über die Systemsteuerung. Beim ersten Aufruf sehen wir im ersten der vier Reiter den einzigen und immer enthaltenen Eintrag:Vendor 8Product 16.
Wechseln Sie auf den zweiten Reiter (Discover Multi-Paths) und wählen Sie hier die benötigte Konfiguration. Bei iSCSI markieren Sie Add Support for iSCSI devices, bei Fibre Channel haben Sie im oberen oder unteren Bereich einen Eintrag, den Sie markieren müssen. Danach müssen Sie die Auswahl mit Add bestätigen, NICHT mit OK das Fenster wieder schließen!
Wenn alles korrekt ist, bekommen Sie eine Rückfrage, ob Sie den Server erneut durchstarten möchten. Beantworten Sie die Frage mit Ja, wird der sofort augenblicklich neu gestartet und wir können uns erneut einen Kaffee holen :)
Enable-MSDSMAutomaticClaim -BusType SAS
Hat die Installation geklappt, sehen wir nach dem Neustart einen weiteren Eintrag im MPIO-Manager:
Warum eigentlich MPIO
MPIO wird benötigt, um mehrere Wege (Ihre Netzwerkkarten oder FC HBAs) zu einem Ziel (z.B. eine LUN) zu verstehen. Nutzen Sie zwei Netzwerkkarten und verbinden sich über beide Karten mit einer LUN, taucht diese LUN in Ihrem Windows ohne eine aktive MPIO-Nutzung doppelt auf. Hätten Sie vier Verbindungen zum gleichen Datenträger, so würde der Datenträger vier Mal auftauchen. Durch die Installation und Konfiguration von MPIO versteht Ihr Betriebssystem, dass es sich bei den „zwei“ oder „vier“ LUNs um das gleiche Objekt handelt und zeigt es nur noch einmal an. Sie können weiterhin unterschiedliche Einstellungen vornehmen, wie mit dem Datenträger kommuniziert wird: Eine Round-Robin-Einstellung verteilt die Kommunikation mit der LUN über die verfügbaren Netzwerkkarten, eine Failover-Only-Konfiguration zum Beispiel nutzt nur eine Karte und weicht auf eine andere aus, falls die erste mal nicht zur Verfügung steht. Least-Queue-Depth als weitere Möglichkeit sucht sich immer die Karte mit der geringsten Warteschlagen aus. Kontaktieren Sie den Hersteller von Ihrem SAN bzw. schauen Sie im Admin-Guide nach, welche Einstellung für Ihr Gerät empfohlen wird. Die meisten Hersteller geben eine Empfehlung raus für den optimalen Betrieb.
Die Einrichtung der iSCSI-Verbindungen
Öffnen Sie, z.B. über den Server-Manager und den Reiter Tools, den iSCSI Initiator. Beim ersten Aufruf bekommen Sie eine Frage, ob der iSCSI-Dienst in Zukunft immer automatisch starten soll. Beantworten Sie diese Frage auf jeden Fall mit Ja, sonst wird der Dienst nach einem Neustart nicht automatisch gestartet und die Storage-Verbindungen können nicht aufgebaut werden.
Nun können wir die Verbindung zu unserem Storage aufbauen. Vermeiden Sie hier eine Verbindung per Quick Connect, da Sie bei dieser Variante zu wenig Einfluss auf die Verbindungen haben. Eine Ausnahme bildet hier ein eigener MPIO-Treiber vom Hersteller des SAN-Storage, ich habe teilweise schon mit Treibern gearbeitet, die alle verfügbaren Pfade automatisch erkennen und eintragen. In meinem Fall ist dies aber nicht möglich, daher der manuelle Weg.
Wir beginnen damit, dass wir im Reiter Discovery mit der Option Discover Portal… die IP-Adressen von unserem SAN hinzufügen.
In meinem Fall sind dies zwei IP-Adressen, 192.168.207.33 und 192.168.206.33. Weitere Optionen müssen hier erstmal nicht ausgewählt werden, es reicht, wenn die IP-Adressen eingetragen sind.
Nutzen Sie mehrere Subnetze
Nutzen Sie nach Möglichkeit unterschiedliche Subnetze für Ihre iSCSI-Netzwerkkarten in den Hyper-V Hosts und in Ihrem SAN. Dies erhöht die Übersicht bei der Einrichtung der Verbindungen, weiterhin erhalten Sie im Failover Cluster mehrere Cluster-Netzwerke, die entsprechend dem Bedarf eingerichtet werden können.
Wenn die Verbindung innerhalb einer Sekunde eingetragen ist, sieht das häufig nach einer erfolgreichen Verbindung aus. Je länger der Manager braucht, um die IP-Adresse einzutragen, desto wahrscheinlicher haben Sie einen Fehler und können nicht auf das Storage-System zugreifen. Das Resultat sieht bei mir wie folgt aus:
Wir wechseln nun in den Reiter Targets, um die Verbindung mit unseren LUNs aufzubauen. Vor der Einrichtung sehen wir (in meinem Fall) eine inaktive Verbindung. Je nach SAN können sich die einzelnen Controller auch als eigenes Ziel zeigen, in diesem Fall haben Sie dann zwei oder mehr Einträge.
Nun beginnt der aufwändigste Teil der Konfiguration: Die Einrichtung der Verbindungen zu unserem Storage. Ziel ist es, von jeder Netzwerkkarte mindestens eine Verbindung zu unserem Ziel aufzubauen. Haben Sie zwei Karten und zwei Ziel-IPs auf Ihrem SAN, so brauchen Sie in Summe zwei Verbindungen. Hat auf dem SAN jeder Controller zwei IP-Adressen, so sind es schon vier Verbindungen usw.
Beginnen Sie mit einem Klick auf das erkannte Ziel (in meinem Fall iqn.1991-05.com.microsoft:fscluster-san1-target) und wählen Sie Connect. Im nächsten Fenster aktivieren Sie beide Optionen (die erste ist für eine Wiederverbindung nach einem Neustart, Wichtig! und die zweite Option ist eine aktive Nutzung der Multi-Pfad-Option) und wählen dann den Button Advanced….
Stellen Sie in den erweiterten Optionen den lokalen Adapter auf Microsoft iSCSI Initiator, die Initiator-IP auf den ersten iSCSI-Adapter in Ihrem lokalen Server und die Target portal IP auf die entsprechende Adresse in dem gleichen IP-Subnetz.
Drücken Sie nun OK und bestätigen das dahinterliegende Fenster ebenfalls, haben Sie die erste Verbindung mit Ihrem SAN aufgebaut. Die Verbindung sollte nun auf Connected umspringen. Diesen Schritt müssen wir nun für jede Verbindung erneut durchführen. Die zweite Verbindung in meinem Fall sieht wie folgt aus:
In der Datenträgerverwaltung sollten nun, wenn Sie die Zugriffsrechte auf dem Storage korrekt vergeben haben, die LUNs auftauchen.
Zurück im iSCSI-Initiator tauchen nun im dritten Reiter, den bevorzugten Zielen, zwei neue Einträge auf:
Nun müssen wir noch eine letzte Einstellung vornehmen, bevor wir mit der Anbindung der LUNs fertig sind. Wechseln Sie in den vierten Reiter (Volumes und Devices) und bestätigen Sie die Option Auto Configure. Diese Option sorgt dafür, dass die Datenträger bei einem Reboot zu einem früheren Zeitpunkt gemappt werden und schneller zur Verfügung stehen.
Damit sind wir mit der Konfiguration des ersten Servers durch, nun werden die gleichen Einstellungen auf dem zweiten Host gesetzt.
Formatierung der Datenträger
Bevor wir die Datenträger im Failover Cluster nutzen können, müssen wir sie natürlich noch mit einem Dateisystem ausstatten. Dies geht am einfachsten über die Datenträgerverwaltung auf einem der Hosts. Nehmen Sie die Datenträger online und formatieren Sie die Datenträger mit NTFS. Achten Sie bei der Blockgröße darauf, welche Empfehlungen der SAN-Hersteller hier vorgibt. Diese Informationen finden sich meist, wie auch die MPIO-Einstellungen, in den Hersteller-Guides. Vergeben Sie KEINE Buchstaben für die Volumes, wir nutzen die Datenträger später als Cluster Shared Volumes, dort arbeiten wir mit Mount Points, nicht mit Buchstaben. Das Ergebnis sieht folgendermaßen aus:
Test der Datenträger im Failover Cluster
Wenn Sie noch kein Failover Cluster besitzen, können Sie nun einen Test der Konfiguration durchführen, in diesem Fall werden die Datenträger auf Ihre Tauglichkeit im Failover Cluster getestet. Ich in meinem Fall besitze bereits ein aktives Failover Cluster, daher starte ich den Test manuell. Dieses Mal, gegenüber dem Test vorher mit der Anbindung an die SMB3-Shares, kann man die Tests der Datenträger sehen und auch, ob diese erfolgreich sind oder nicht.
Als nächstes können die Datenträger im Bereich Storage – Disks hinzugefügt und als Cluster Shared Volume eingebunden werden. Der kleine Datenträger mit einer Größe von 10 GB wird als Quorum verwendet.
Per PowerShell geht das natürlich auch :)
Get-ClusterAvailableDisk | Add-ClusterDisk
Da die Datenträger nach einem Standard-Schema benannt werden, passe ich die Namen ebenfalls auf sprechende Namen an. Das folgende Skript zur Umbenennung der Cluster-Datenträger in Abhängigkeit von dem Namen der Partition hat uns einige Zeit gekostet. Es gibt leider keinen direkten Befehl, daher mussten wir den Umweg gehen und mit WMI ein bisschen in die Trickkiste greifen :)
$disks = Get-ClusterResource | where-object {$_.ResourceType -ilike „Physical Disk“}
foreach ($disk in $disks) {
$DiskResource = gwmi MSCLuster_Resource -Namespace root/mscluster | ?{$_.Name -eq $disk}
$DiskLabel = (gwmi -Namespace root/mscluster -Query „ASSOCIATORS OF {$DiskResource} Where ResultClass=MSCluster_DiskPartition“).VolumeLabel
$disk.Name = $DiskLabel
}
Hier zwei Screenshots, einer vor der Ausführung und einer danach:
Nun können wir die Datenträger als Quorum einbinden bzw. als Cluster Shared Volumes hinzufügen. Ist dies geschehen, nenne ich die Mount Points unter C:Clusterstorage noch um, so dass diese genau so heißen wie die LUNs.
Set-ClusterQuorum -NodeAndDiskMajority „Quorum“
Get-ClusterResource | ? OwnerGroup -eq „available storage“ | Add-ClusterSharedVolume
$LUNs = Get-ClusterSharedVolume
foreach ($LUN in $LUNs) {
$Name = $LUN.Name
$LUN = $LUN.SharedVolumeInfo
$Path = $LUN[0].FriendlyVolumeName
Rename-Item -path $Path -newName $Name }
Nach dieser Anpassung können wir nun beginnen, VMs in unser Cluster aufzunehmen bzw. neue VMs zu erstellen. Falls Sie die Standard-Einstellungen der Pfade für neue VMs noch anpassen möchten, so können Sie dies ebenfalls per PowerShell realisieren.
Set-VMHost -VirtualHardDiskPath C:ClusterStorageLUN1VMs -VirtualMachinePath C:ClusterStorageLUN1VMs
Der CSV Block Cache
Wenn Sie in Ihrem Hyper-V Failover Cluster CSV Datenträger verwenden, können Sie den CSV Block Cache nutzen. Bei dieser Technik nutzen Sie einen Teil Ihres RAMs in den Hyper-V Hosts als Lese-Cache. Eingeführt wurde diese Technik unter Windows Server 2012, hier musste sie noch explizit eingeschaltet und konfiguriert werden. Die Aktivierung muss nicht mehr gemacht werden, ab Server 2012 R2 muss „nur noch“ die Menge an RAM definiert werden, die genutzt wird. Je identischer Ihre VMs sind, desto mehr profitieren Sie von dieser Technik. VDI Farmen mit hunderten oder tausenden von VMs sind hier optimal, aber auch kleinere Umgebungen mit unterschiedlichen VMs können von dieser Cache-Technik profitieren.
Microsoft selbst hat die Technik in einem VDI-Szenario im Jahr 2012 getestet, die Werte und Ergebnisse finden Sie unter https://blogs.technet.microsoft.com/josebda/2012/11/14/windows-server-2012-file-server-tip-enable-csv-caching-on-scale-out-file-server-clusters/
Auslesen können Sie den aktuellen Wert per Windows PowerShell.
Get-Cluster | ft Name, BlockCacheSize
Nach der Einrichtung eines Failover Cluster steht dieser Wert immer auf 0, wenn diese Technik genutzt werden soll, muss er angepasst werden.
Der Wert wird in MB angegeben und wird global für das Failover Cluster definiert, nicht pro Knoten. Grundsätzlich können Sie 64 GB und mehr verwenden, diese Zahlen sind aber in den meisten Fällen viel zu hoch. Die Konfiguration von vier bis acht GB ist völlig ausreichend, in den wenigsten Fällen wird mehr RAM genutzt. In dem oben verlinkten Beispiel haben 8 GB pro Server schon signifikante Auswirkungen.
Nützliche Information: Egal wie viel Sie einstellen, es wird immer nur so viel RAM auch wirklich belegt, wie benötigt wird. Konfigurieren Sie einen CSV Block Cache von 24 GB, tut sich an dem belegten RAM im ersten Moment nichts, wenn Sie vorher und nachher einen Blick auf den Task Manager werfen.
Anpassen können Sie den Wert mit dem folgenden Befehl.
(Get-Cluster).BlockCacheSize = 8192
