Wir haben bei unserem Scale Out Fileserver (SOFS) vor kurzem einen Tausch der Server-Hardware durchgeführt. Die alten Systeme werden in Zukunft für unseren Hyper-V PowerKurs genutzt, daher wurden für das Produktivsystem zwei neue Server sowie neue SAS-HBAs angeschafft. Nach einer kurzen Überlegung haben wir festgestellt, dass ein Tausch der Hardware auch im Betrieb möglich sein sollte. Um dies zu verifizieren habe ich den Vorgang dann auch in der Praxis durchgeführt und nachgeschaut, ob dies wirklich so einfach und zuverlässig funktioniert.

Grundsätzlich besteht das Failovercluster zur Bereitstellung der Dateiserver-Rolle aus zwei Knoten, die mit jeweils zwei SAS-Kabeln an einem DataOn-JBOD angeschlossen sind. In diesem JBOD stecken sowohl SAS-HDDs als auch SAS-SSDs, diese werden zur Speicherung unserer produktiven VMs genutzt.

Begonnen habe ich mit der Installation von einem der beiden neuen Knoten. Nach dem Update-Vorgang und der Treiber-Installation von SAS-HBA und 10GBit-Karte wurde der Server in das Rack gehängt, aber noch nicht mit dem JBOD verbunden. Im Failovercluster (mit der Dateiserver-Rolle, es geht hier grundsätzlich nicht um das Hyper-V Failovercluster) habe ich nun einen der beiden Produktiv-Systeme in den Wartungsmodus versetzt und überprüft, ob ein Zugriff über den zweiten Knoten noch möglich ist. Nachdem ich dies verifiziert habe, konnte der inaktive Knoten komplett aus dem Failovercluster entfernt und heruntergefahren werden. Zu diesem Zeitpunkt bestand das SOFS-Konstrukt nur aus einem Server. Anschließend wurden die SAS-Kabel des ausgeschalteten Servers entfernt und gleichzeitig wurde der dritte, neu installierte Server angeschlossen. Bevor der neue Server nun hinzugefügt wurde, habe ich den Cluster-Validierungsassistent gestartet um zu überprüfen, ob die Konfiguration in Ordnung ist. Die Überprüfung lief ohne Fehler durch. Es wurden zwar diverse Warnungen angezeigt; diese konnten jedoch alle ignoriert werden (unterschiedliche CPUs, unterschiedlicher Patchlevel usw.). Nachdem nun der dritte Server Mitglied des SOFS war, wurde der zweite ältere Server in den Wartungsmodus versetzt, aus dem Failovercluster und vom JBOD entfernt. Nun wurde der zweite neue Server mit dem JBOD verbunden und nach einem erneuten Test zum Failovercluster hinzugefügt. Die Migration war an dieser Stelle abgeschlossen, der komplette Vorgang lief fehler- und ausfallfrei durch. Ich habe letztlich noch überprüft, ob die beiden CSV-Datenträger an jeden der beiden neuen Server verschoben werden konnten und ob bei einer gleichmäßigen Verteilung über beide Server Daten laufen. Dies war der Fall, seitdem laufen die Systeme problemlos und verrichten ihre Aufgabe.

Ich befinde mich aktuell in München bei einem unserer Kunden, hier haben wir diese Schritte erneut durchgeführt, um die SOFS-Knoten zu tauschen. Hier gab es ebenfalls keine Probleme oder Ausfälle.

Dieser Artikel behandelt die Installation eines Failover Cluster unter Windows Server 2012 R2, welches zur Ausführung von Hyper-V VMs genutzt wird. Gegenüber den vorherigen Artikeln zur Einrichtung unter Windows Server 2008 R2 und Windows Server 2012 hat sich teilweise etwas geändert, das “Grundrauschen” ist allerdings gleich geblieben. Die größte Änderung liegt darin, dass durch unterschiedliche Techniken die Anzahl der Möglichkeiten enorm gestiegen sind. Dadurch gibt es nicht mehr “die eine” optimale Lösung, es muss nun anhand der jeweiligen Hardware entschieden werden, was die beste Lösung in diesem einen Fall ist. Zusätzlich habe ich an einigen Stellen noch die genutzten PowerShell-Befehle mit aufgeführt. Diese hier beschriebene Konfiguration eignet sich primär bei der Nutzung eines Scale-Out File Servers. Dieser ist bereits eingerichtet und in diesem Artikel wird nicht auf die Einrichtung eingegangen, dies wird komplett im zweiten Teil der Serie gemacht.

Egal was Sie einsetzen möchten, was Sie bereits haben oder wo Sie ansetzen: Sprechen Sie uns an, wir können diese Konfiguration gerne an Ihre Bedürfnisse anpassen.

Die genutzte Hardware

Die Demoumgebung

Die hier genutzte Hardware sind zwei Rechner aus unserem Hyper-V Powerkurs und einem Scale-Out Fileserver unter Windows Server 2012 R2 als SMB3-Ziel. Die Rechner besitzen zwei 1Gbit NICs und vier 10Gbit NICs, 24 GB RAM und eine Quadcore-CPU. Beide Server sind Mitglied der Active Directory powerkurs.local. Der Scale-Out File Server hat jeweils zwei 10Gbit-Ports für SMB3 und zwei 1Gbit-Ports zur Anbindung an die Active Directory pro Knoten.

Ein paar Worte zu der Hardware, den Verbesserungs- und den Sparmöglichkeiten

Diese hier beschriebene Konfiguration entsprecht von den Eckdaten her dem, was wir empfehlen und was wir bereits in Projekten mehrfach erfolgreich eingesetzt haben. Natürlich sollte als Server ein wirklicher Server zum Einsatz kommen, der für den 24/7-Betrieb geeignet ist. Von einer Nutzung von PCs oder Workstations ist natürlich absolut abzuraten, wegen der Verfügbarkeit habe ich diese Systeme aber als Demoumgebung genutzt.

Wir geben Ihnen als Empfehlung zwei 10Gbit-Adapter mit jeweils zwei Ports vor, d.h. jeder Hyper-V Host ist mit 40 Gbit angebunden, hinzu kommen noch zwei oder mehr 1 Gbit-Adapter. Diese Anbindung könnte theoretisch noch erhöht werden auf sechs 10 Gbit-Adapter, prinzipiell spricht hier nichts gegen. Dies bewirkt eine Erhöhung der Gesamtbandbreite, ändert aber nichts an der Performance der einzelnen Adapter. Hier kommen RDMA bzw. SMB Direct-Karten ins Spiel. Mit Hilfe dieser Technik können Sie eine deutliche Steigerung der Performance bei sehr geringer Latenz erreichen. Wenn alle Netzwerk-Komponenten diese Technik beherrschen haben Sie eine enorm hohe Bandbreite zwischen Hyper-V Failover Cluster und Scale-Out File Server. Informationen zu dem Thema gibt es unter anderem im Hyper-V Podcast Folge 35 von meinem Kollegen Carsten Rachfahl.

Wenn Sie nicht den Bedarf von 40 Gbit pro Knoten haben oder die Hardware bereits vorhanden ist, können Sie den Betrieb auch mit einer 10 Gbit DualPort-Karte realisieren. In diesem Fall wären die VMs mit zwei oder mehr 1 Gbit-Karten angebunden, die 20 Gbit ständen dann exklusiv für die Anbindung an den Storage zur Verfügung.

Die Installation und Einrichtung des Betriebssystems

Die Einrichtung beginnt mit einer frischen Installation eines Windows Server 2012 R2 in der Datacenter Edition auf beiden Hosts. Nach der Grundinstallation werden die Netzwerkkarten umbenannt und teilweise zu einem Team konfiguriert.

Beide 1Gbit-Adapter werden zu einem Team zusammengefasst, zusätzlich werden zwei 10Gbit-Adapter (jeweils auf einem der beiden Adapter) zu einem Team zusammengefasst. Das 2Gbit-Team wird als Management-Netzwerk genutzt, das 20Gbit-Team wird zur Anbindung der VMs an das Netzwerk genutzt. Insgesamt existieren vier Netzwerke, auf drei der Karten hat der Host eine eigene IP-Adresse. Das VM-Netzwerk wird exklusiv für die virtuellen Computer genutzt.

Die Konfiguration per PowerShell wäre wie folgt:

New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

New-NetLBFOTeam -Name "VM-Team" -TeamNICName "VM-Team" -TeamMembers 10GBit#1, 10GBit#3 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Die Karte Management-Team wird mit einer IP-Adresse im Bereich 192.168.209.0/24 konfiguriert. In meinem Fall arbeite ich mit den Systemen Hyperv10 und Hyperv15, daher bekommt Hyperv10 die Adresse 192.168.209.10 und Hyperv15 die Adresse 192.168.209.15. Die Endadresse bleibt in allen Netzen gleich, so kann eine eindeutige Zuordnung erfolgen. Eine gleichmäßige Zuweisung von Adressen sowie eine durchgängige Benamung machen den Betrieb und die Administration an vielen Stellen einfacher. Die Karte VM-Team wird zu diesem Zeitpunkt nicht konfiguriert, sie wird später als Hyper-V Netzwerk genutzt. Bei der Wahl der Adapter wird jeweils ein Adapter pro Hardware-Karte gewählt, dies ermöglicht einen Betrieb auch dann, wenn einer der beiden Hardware-Karten ausfallen würde. Die Bindungen der Karte werden nicht geändert und sehen wie folgt aus:

Die beiden 10Gbit-Adapter, die nicht Mitglied des Teams sind, werden mit einer IP-Adresse aus den Storage-Bereichen versehen. Hierbei achten wir ebenfalls darauf, dass die End-Adresse jeweils identisch ist mit der Adresse im Management-Netz. Nach der korrekten Konfiguration sehen die Eigenschaften der Karten wie folgt aus:

Unter IP-Einstellungen werden keine Änderungen vorgenommen, die Einstellungen der Karte 10GBit#2 (die zweite Storage-Karte) sind bis auf die IP-Adresse identisch.

Die Konfiguration per PowerShell:

Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#2" -IPAddress 192.168.208.10
Set-DnsClientServerAddress -InterfaceAlias "10GBit#2" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#4" -IPAddress 192.168.207.10
Set-DnsClientServerAddress -InterfaceAlias "10GBit#4" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

Beide Server werden nun auf den aktuellen Patchlevel geupdatet.

Nach der Installation und dem anschließenden Neustart kann die Einrichtung mit der Installation der Hyper-V Rolle fortgesetzt werden.

Über den Server-Manager oder per PowerShell kann nun die Hyper-V Rolle installiert werden. Bei der während der Installation durchgeführten Konfiguration wählen wir keine der Karten für das Hyper-V Netzwerk aus, dies wird im späteren Verlauf manuell konfiguriert. Die Livemigration wird nicht konfiguriert, bei der Wahl der Pfade wird ebenfalls an dieser Stelle keine Änderung vorgenommen. Das System startet nun zwei Mal durch und steht danach wieder zur Verfügung.

Alternativ kann die Installation natürlich auch per PowerShell gemacht werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart

Wenn der Parameter –ComputerName noch mit angegeben wird können sogar alle Server fast gleichzeitig installiert werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart -ComputerName Hyperv10

Die Einrichtung von Hyper-V zur Vorbereitung auf den Betrieb als Failover Cluster-Knoten

Nach der Installation von Hyper-V müssen noch ein paar lokale Einstellungen vorgenommen werden, bevor das Failover Cluster eingerichtet werden kann. Im Hyper-V-Manager werden auf beiden Systemen unter dem Manager für virtuelle Switches eine neue externe Switch erstellt und auf den VM-Team-Adapter gebunden. Achten Sie darauf, den korrekten Adapter auszuwählen.

Wie Sie die virtuelle Switch nennen ist Ihnen überlassen, wichtig ist das sie auf allen Hyper-V Hosts gleich heißt. Achten Sie zusätzlich unbedingt darauf, nicht die gemeinsame Verwendung zu aktivieren. Bei Nutzung der gemeinsamen Verwendung bekommt der Host eine weitere, virtuelle Netzwerkkarte, die nicht benötigt und nicht gewollt ist. Der PowerShell-Befehl hierzu ist:

New-VMSwitch -Name "VM" -NetAdapterName VM -AllowManagementOS 0 -ComputerName Hyperv10

Danach kann Hyperv10 durch den Namen des zweiten Knoten ersetzt werden.

Die Installation und Einrichtung des Failover Cluster

Nachdem nun die Vorbereitungen abgeschlossen sind können wir mit der Installation und Einrichtung des Failover Cluster beginnen.

Die Installation der benötigten Features

Für die Einrichtung eines Failover Cluster wird das Feature Failoverclustering benötigt

Wenn Sie das System lokal administrieren möchten oder müssen sollten Sie die Failovercluster-Verwaltungstools sowie das Failoverclustermodul für Windows PowerShell ebenfalls installieren

Per PowerShell:

Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –IncludeManagementTools -ComputerName Hyperv10

Die Einrichtung des Failover Cluster

Nach der Installation öffnen Sie den Failovercluster-Manager und beginnen mit dem Menüpunkt Konfiguration überprüfen….

Im Assistenten fügen Sie die Server hinzu, die überprüft werden sollen (Tipp: das lokale System kann mit einem Punkt ( . ) oder “localhost” hinzugefügt werden)

Danach können Sie auswählen, welche Tests durchgeführt werden sollen. Falls dies der erste Durchlauf ist sollten Sie unbedingt alle Tests auswählen, falls Sie nur einen oder mehrere spezielle Tests durchführen möchten (z.B. bei einem erneuten Durchlauf) können Sie diese manuell auswählen.

Es werden nun alle Tests durchgeführt, dies dauert je nach Anzahl der Server.

Nach dem Durchlauf erhalten Sie eine Übersicht der Tests und haben die Möglichkeit, sich den kompletten Bericht anzeigen zu lassen.

Schauen Sie sich unbedingt die Warnungen und Fehler an. Je nach Art der Fehler können diese entweder ignoriert werden oder sie müssen aktiv korrigiert werden. In meinem Fall steckte ein Kabel in einem falschen VLAN, wodurch die folgende Meldung in dem Bericht auftaucht:

Solche Fehler werden meist durch den Assistenten erkannt und angemerkt, eine Behebung vor der Erstellung und Nutzung des Failover Cluster macht deutlich mehr Spaß als die nachträgliche Suche.

Andere Warnungen können ggf. ignoriert werden, z.B. ein fehlender Datenträger oder eine permanente SCSI-3-Reservierung. Da wir mit SMB3-Shares arbeiten sind keine Datenträger im Failover Cluster vorhanden.

Wenn keine Fehler während der Überprüfung auftauchen aktiviert der Assistent direkt die Möglichkeit, den Failover Cluster mit den überprüften Knoten zu erstellen

Während der Erstellung werden wir nach dem Namen des Failover Cluster und der IP-Adresse gefragt, unter der eine Administration möglich ist. Die Frage nach dem Netzwerk erscheint nur, weil keine der Netzwerkkarten ein Gateway eingetragen hat. Sobald ein Gateway vorhanden ist wird automatisch dieses Netzwerk als Zugriffspunkt definiert.

Wir benötigen in unserem Fall eine IP-Adresse im Netzwerk 192.168.209.0/24 und einen eindeutigen Namen

Nach einem Klick auf Weiter wird überprüft, ob Name und IP-Adresse bereits vorhanden bzw. belegt sind, falls dies nicht der Fall ist erscheint eine Übersicht über die getätigten Einstellungen.

Die Option Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden bewirkt an dieser Stelle keine Änderung, da keine Datenträger hinzugefügt wurden. Wir haben uns angewöhnt diese Option grundsätzlich zu deaktivieren, da wir den Speicher manuell zuweisen wollen. Nach einem Klick auf Weiter wird der Cluster erstellt, danach verbindet sich der Failovercluster-Manager automatisch mit dem gerade erstellten Cluster. In der Zusammenfassung bekommen wir noch einen Hinweis angezeigt, dass kein geeigneter Datenträgerzeuge vorhanden ist. Um diese Einstellungen kümmern wir uns später.

Die Konfiguration des Netzwerks

Die ersten Anpassungen im gerade erstellten Cluster werden im Netzwerk gemacht. Die Netze werden automatisch durchnummeriert, diese Namen ändern wir auf die Funktion des einzelnen Netzwerks.

Um welches Netz es sich handelt können Sie sehen, wenn Sie auf das Netzwerk klicken und im unteren Teil auf den Reiter Netzwerkverbindungen wechseln.

Das Ergebnis sind drei vollständig benannte Netzwerke. Die Eigenschaften der Karten sehen wie folgt aus:

In den Einstellungen für Livemigration muss nun die Reihenfolge der Netzwerke definiert werden, über die eine Livemigration gemacht wird.

Hier werden die beiden Storage-Karten als primäre Karten definiert und in der Reihenfolge nach oben geschoben, falls dies nicht automatisch der Fall ist. Der Adapter Management bleibt ebenfalls aktiviert, wird aber ganz nach unten verschoben.

Als nächstes muss die Metrik der Netzwerke im Failover Cluster definiert werden. Die Metrik bestimmt, über welches Netzwerk die Daten während eines umgeleiteten Modus zwischen den einzelnen Knoten laufen. Diese Einstellung kann ausschließlich per PowerShell ausgelesen und gesetzt werden, eine Administration per GUI ist nicht möglich. Öffnen Sie eine administrative PowerShell oder die PowerShell ISE und nutzen Sie die folgenden Befehle zum Auslesen und manuellen Setzen der Werte.

Get-ClusterNetwork | ft Name, Metric, AutoMetric

Je kleiner die Metrik, desto höher ist die Priorität. Standardmäßig wird in dem oberen Screenshot das Netzwerk Storage2 genutzt, da die Metrik 30240 die kleinste der drei ist. Grundsätzlich ist diese Reihenfolge (Erst Storage2, dann Storage1 und dann Management) in Ordnung, wir möchten aber gerne die Prioritäten manuell auf die folgenden Werte setzen:

Die entsprechenden Befehle dazu sind

(Get-ClusterNetwork "Storage1").Metric = 100
(Get-ClusterNetwork "Storage2").Metric = 101
(Get-ClusterNetwork "Management").Metric = 110

Diese Einstellungen müssen nur auf einem der Knoten gemacht werden, da hier clusterweite Einstellungen verändert und konfiguriert werden.

Die folgende Einstellung muss auf jedem Cluster-Knoten gesetzt werden, da es sich um eine lokale Einstellung handelt. Wechseln Sie in die Netzwerkverbindungen und wählen Sie in der Menüleiste (Falls nicht sichtbar “Alt” drücken) unter Erweitert die Option Erweiterte Einstellungen….

Schieben Sie dort den Adapter Management-Team ganz nach oben.

An dieser Stelle sind wir mit der Konfiguration des Netzwerks lokal und im Cluster fertig.

Die Einrichtung des Datenträgerzeugen / Quorum

Ganz wichtige Änderung unter Windows Server 2012 R2 in Bezug auf das Quorum: Erstellen Sie immer (egal welche Anzahl von Knoten und ob gerade oder ungerade) ein Quorum und weisen Sie dieses auch immer! zu. Das Failover Cluster verwendet dieses Quorum dynamisch, und zwar immer nur dann wenn es eins benötigt. Weitere Informationen und eine Bestätigung seitens Microsoft finden Sie im Technet: What’s New in Failover Clustering in Windows Server 2012 R2.

Da wir bei der Nutzung eines Scale-Out File Server keine CSV-Datenträger in unserem Failover Cluster haben müssen wir eine Dateifreigabe verwenden. Es existieren zu diesem Zeitpunkt drei Freigaben auf dem Scale-Out File Server. Die Freigabe HVQuorum wird für den Hyper-V Failover Cluster genutzt.

Wechseln Sie im Hauptmenü des Failover Cluster unter Weitere Aktionen auf Clusterquorumeinstellungen konfigurieren….

Es öffnet sich ein Assistent, der Sie bei der Einrichtung unterstützt. Nach der Vorbemerkung werden Sie nach der Art der Einrichtung gefragt. Die erste Option Standardquorumkonfiguration verwenden ist in diesem Fall nicht möglich, dies führt dazu das kein Quorum verwendet wird. Wir nutzen daher die zweite Option Quorumzeugen auswählen.

Im nächsten Schritt werden Sie nach der Art des Quorum gefragt, hier wählen Sie die Option Dateifreigabezeuge konfigurieren.

Schreiben oder Kopieren Sie nun den Pfad der Freigabe in den Assistenten.

Bestätigen Sie die Einstellungen und schließen Sie den Assistenten ab.

Nachdem Sie die Einrichtung abgeschlossen haben können Sie sehen, dass an besagtem Ort nun ein Ordner erstellt wurde, in dem eine Textdatei liegt.

Kurze Zeit später erscheint eine zweite Datei

Die Konfiguration ist nun abgeschlossen.

Die Einrichtung von Bandbreitenmanagement für SMB-Traffic

Wenn, wie in unserem Fall, die Livemigration und der Storage-Traffic über eine Leitung laufen, könnte dies ungewünschte Folgen bei vielen gleichzeitigen Livemigrationen haben. Zusätzlich werden Daten zwischen den einzelnen Hosts ebenfalls über diese Netze gesendet (Metric-Konfiguration weiter oben, bei der Storage1 die geringste Metric besitzt. In solch einem Fall können wir ein Bandbreitenmanagement für SMB-Traffic einführen. Die Installation kann auf Wunsch per Server-Manager gemacht werden, die Konfiguration muss allerdings zwingend per PowerShell gemacht werden. Das Feature versteckt sich hinter dem Namen SMB Bandwidth Limit.

Die Installation per PowerShell erfolgt mit dem Befehl

Add-WindowsFeature FS-SMBBW

Nach der Installation erfolgt die Einrichtung per PowerShell. Um die Livemigration auf z.B. 8 Gbit/s zu begrenzen, kann der folgende Befehl angewendet werden

Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 1000MB

Als Kategorie steht neben LiveMigration noch VirtualMachine und Default zur Verfügung.

Die Nutzung von SMB Multi Channel

Wir nutzen in unserem Fall mehrere Wege zu unserem Scale-Out File Server, daher haben wir beim Netzwerk-Design und bei der Einrichtung weiter oben zwei Storage-Karten konfiguriert. Grundsätzliches zum Thema SMB3 hat Carsten unter anderem in diesem Video gezeigt und erklärt: Hyper-V-Server.de: Videocast rund um Hyper-V auf SMB. Damit die Multi Channel-Funktionalität in einem Failover Cluster (egal ob Hyper-V oder Scale-Out File Server) greift, müssen sich die Storage-Karten in unterschiedlichen Subnetzen befinden. Multi Channel in einem Subnetz funktioniert nur bei Konfigurationen, in dem das Failover Cluster-Feature noch nicht installiert ist.

Im zweiten Teil unserer Serie möchten wir den Aufbau und die Einrichtung eines Scale-Out File Server unter Windows Server 2012 R2 zeigen. Wir nutzen für diesen Aufbau zwei Server und ein JBOD, welches mit HDDs und SSDs bestückt ist. Die Server sind HP DL360 Gen8-Systeme und haben jeweils eine CPU, 20 GB RAM und zwei lokale Festplatten für das Betriebssystem. Die Anbindung an das JBOD erfolgt per SAS, hier kommt ein Adapter von LSI zum Einsatz. Jeder Server besitzt vier 1 Gbit-Karten und zwei 10 Gbit-Karten zur Anbindung der Systeme an das Netzwerk. Als Betriebssystem kommt ein Windows Server 2012 R2 Standard zum Einsatz.

Update 04. November 2014: Wir haben diesen Artikel auf einen aktuellen Stand gebracht. Durch die Installation einiger Systeme, einigen Problemen mit gewissen Konfigurationen und weiteren Informationen, die wir erst später bekommen haben, ändert sich die Einrichtung in einigen Punkten. Alle geänderten Punkte sind in diesem Artikel farblich markiert und an der jeweiligen Stelle dazugekommen.

Update 30. Juni 2015: Ich habe den Artikel erneut geupdatet. Hinzugekommen ist eine Erweiterung des Bereichs Quorum im SOFS Cluster.

Falls Sie generell Interesse an diesem Thema haben, können wir Ihnen unseren Hyper-V PowerKurs empfehlen. Hier tauchen wir eine Woche in die Virtualisierung ein, der Aufbau und die Nutzung von SMB 3-Shares (sowohl Standalone als auch per Scale-Out File Server) spielen hier ebenfalls eine große Rolle. Mehr Informationen unter www.hyper-v-server.de/powerkurs .

Weitere Informationen zur aufgeführten Hardware

Zu der weiter oben schon kurz beschriebenen Hardware gibt es ein paar Dinge zu sagen. Zum einen möchte ich die Hardware näher und detaillierter auflisten, zum anderen ein paar Worte zu der Anzahl der jeweiligen Komponenten sagen. Das genutzte Equipment bietet zwar die Möglichkeit einen Scale-Out File Server aufzubauen, bietet aber an einigen Stellen keine Redundanz und daher nur eine bedingte Hochverfügbarkeit. Da uns momentan “nur” diese Hardware zu Demozwecken zur Verfügung steht können wir die Best-Practice-Vorgehensweise nur bedingt in Screenshots zeigen, die Beschreibung zeigt aber die optimale Einrichtung. Lesen Sie diesen Bereich unbedingt komplett, er enthält einige Informationen zu strategischen Entscheidungen und begründet einige der Best-Practice-Vorschläge.

Die genutzte Hardware

Als Hardware kommen die folgenden Komponenten zum Einsatz:

HP DL360e Gen8

• Intel E5-2403 CPU
• 20 GB RAM
• Zwei HDDs im RAID1 für das WS2012R2 Standard Betriebssystem
• LSI 9207-8e SAS HBA
• Intel X540-T2 10GBaseT Netzwerkadapter

DataOn DNS-1640 JBOD mit Platz für 24 2.5” HDDs

Seagate 1200 SSD mit einer Kapazität von 200 GB

Seagate Enterprise Capacity 2.5 HDD mit einer Kapazität von 1 TB

Der optimale Aufbau

Wie bereits erwähnt ist die Anzahl der einzelnen Komponenten für eine Hochverfügbarkeit sehr wichtig. Achten Sie unbedingt auf eine Zertifizierung der Hardware, eine Liste der von Microsoft zertifizierten Komponenten ist auf www.windowsservercatalog.com aufgeführt. Der hier beschriebene Scale-Out File Server ist die Basis für einen großen Teil Ihrer IT-Infrastruktur. Wackelt dieser Teil, wackelt auch alles oben drüber. Diese Zertifizierung ist kein “nice to have”, es ist absolute Pflicht!

Die Anzahl der JBODs

Die Anzahl der JBODs, die Sie einsetzen, steht im direkten Zusammenhang mit der Verfügbarkeit und dem Verhalten beim Ausfall solch eines Geräts. Um den kompletten Ausfall eines JBODs abfangen zu können benötigen Sie insgesamt drei Stück. Dies liegt daran, dass immer mehr als 50% aller Festplatten verfügbar sein müssen. Bei zwei JBODs mit gleicher Bestückung sind bei einem Ausfall eines Geräts genau die Hälfte aller Festplatten nicht mehr verfügbar, der Scale-Out File Server ist in diesem Moment nicht mehr funktionstüchtig. Sie könnten in eins der Gehäuse mehr Festplatten/SSDs stecken wie in das andere, aber wir kennen das Problem wahrscheinlich alle: Fällt in diesem Szenario etwas aus, ist es fast immer das Gehäuse mit der größeren Anzahl an Festplatten. Ihnen hilft zu einer echten Verfügbarkeit nur ein Betrieb eines dritten (oder noch mehr, dies geht natürlich auch) JBODs. Bei drei Gehäusen sollten Sie jeweils ein Drittel aller Festplatten und SSDs in einem der Gehäuse betreiben.

Die Art des JBODs

Achten Sie bei der Auswahl Ihrer JBODs auf eine Freigabe von Microsoft. Technisch werden JBODs mit den SCSI Enclosure Services (SES) benötigt, dies bedeutet das JBOD kann den Standort der Datenträger an den bzw. die Server melden. Nur diese Funktion ermöglicht eine Speicherung von Daten auf unterschiedlichen Datenträgern in unterschiedlichen JBODs. Weiß der Server nicht, wo welche Festplatte steckt, kann er hier keinen Schutz einbringen.

Enclosure Awareness

Damit Ihre Daten bei dem Betrieb von drei oder mehr JBODs vor einem Ausfall geschützt sind, müssen Sie eine Enclosure Awareness aktivieren. Dies bedeutet bei der Ablage von Daten auf Ihren Festplatten wird darauf geachtet, das die gespiegelten Daten nicht im gleichen JBOD gespeichert werden. Diese Funktion kann entweder für einen kompletten Storage Pool konfiguriert werden oder Sie setzen diese Eigenschaft bei der Erstellung Ihrer virtuellen Datenträger. Da diese Funktion nur per PowerShell aktiviert werden kann empfiehlt sich eine Erstellung von Datenträgern per PowerShell. Im späteren Verlauf des Artikels wird auf diesen Punkt erneut eingegangen. (TechNet Wiki: Enclosure Awareness Support – Tolerating an Entire Enclosure Failing)

Die Verkabelung der JBODs

Wir empfehlen eine direkte Verkabelung der JBODs pro Server, kein Schleifen der Verbindung (Chaining) über das vorherige JBOD. Technisch ist dies natürlich möglich, Sie bauen sich aber einen möglichen Engpass und eine potentielle Fehlerquelle ein. Binden Sie jedes JBOD direkt per SAS an. Wir selbst empfehlen und konfigurieren bei unseren Kunden die Systeme so, dass jedes JBOD doppelt an jeden Server angebunden ist.

Im folgenden Bild ist ein Scale-Out File Server Knoten mit insgesamt drei Dual-Port SAS HBAs an drei JBODs angeschlossen. Mit diesem Aufbau könnte ein kompletter Controller, ein Kabel oder ein JBOD ausfallen, ohne dass die Kommunikation abbrechen würde. Der zweite Knoten wird auf die gleiche Weise verbunden. Bei Vier-Port SAS HBAs reduziert sich die Anzahl der Karten auf zwei, um alle sechs Verbindungen zu realisieren.

Die Anzahl und Größe der Datenträger

Achten Sie bei der Anzahl der Datenträger in Ihrem Failover Cluster darauf, dass Sie mindestens genau so viele Datenträger wie Knoten besitzen. Da seit Windows Server 2012 R2 eine Verbindung pro Share und nicht mehr pro Dateiserver aufgebaut wird können Sie so erreichen, dass alle Cluster-Knoten aktiv genutzt werden und nicht die gesamte Last über einen Knoten verarbeitet wird, während die anderen auf einen Ausfall warten, um übernehmen zu können. Positiv hinzu kommt, dass unter 2012 R2 eine automatische Verteilung der CSV-Datenträger im Failover Cluster passiert. Sie müssen sich nicht aktiv um die Verteilung kümmern, die Datenträger werden automatisch an unterschiedliche Knoten zugewiesen.

Achten Sie bei der Größe der Datenträger darauf, dass Sie ausreichend freien Speicherplatz im Storage Pool lassen. Nur so erreichen Sie eine schnelle Wiederherstellung der Daten beim Ausfall eines Datenträgers. Mehr Informationen dazu und wie Sie den freien Speicherplatz berechnen können finden Sie ein paar Zeilen weiter unten.

Hot-Spare-Datenträger vs. Automatische Wiederherstellung

Oft wird beim Design von einem Scale-Out File Server mit Hot-Spare Festplatten kalkuliert. Diese sind beim Einsatz von Storage Spaces zwar möglich, seitens Microsoft aber nicht vorgesehen und nicht empfohlen (Microsoft TechNet: What’s New in Storage Spaces in Windows Server 2012 R2). Die empfohlene Variante ist die Nicht-Nutzung eines gewissen Prozenzsatzes des verfügbaren Speicherplatzes, was technisch auf ein ähnliches Resultat herausläuft, allerdings auf ein deutlich schnelleres. Ein kleines Rechenbeispiel:

Sie nutzen in Ihrem Scale-Out File Server mehrere SSDs und HDDs, die HDDs haben eine Größe von 4 TB. Sie haben eine weitere 4 TB Festplatte als Hot-Spare Datenträger konfiguriert. Ihnen fällt nun eine 4 TB Festplatte aus und die Daten auf der ausgefallenen Festplatte müssen nun auf den Hot-Spare Datenträger übertragen werden, damit der Spiegel wieder intakt ist. Bei einer Transferrate von 100 MegaByte pro Sekunde haben Sie eine Wiederherstellungszeit von 40000 Sekunden bzw. 11,1 Stunden. Diese Zeit wird natürlich nur benötigt, wenn die kompletten 4 TB beschrieben sind, bei einer geringeren Datenmenge nimmt die Dauer ab.

Microsoft hat bei Nutzung der Storage Spaces ein etwas anderes Verfahren genutzt, um die Daten beim Ausfall eines Datenträgers wiederherzustellen. Falls ausreichend Platz vorhanden ist werden die Daten, die auf der defekten Festplatte lagen, auf alle anderen verfügbaren Datenträger kopiert. Dies bedeutet es müssen nicht 4 TB auf eine Festplatte allein zurückgeschrieben werden, sondern eine gewisse Anzahl an Festplatten bekommt jeweils z.B. 100 GB. Da alle Festplatten gemeinsam “ihre” 100 GB speichern müssen ist der Gesamtzeitraum der Wiederherstellung deutlich geringer als bei der Wiederherstellung auf einer Festplatte.

Bei der Berechnung des freien Speicherplatzes gehen wir davon aus, dass alle Festplatten und alle SSDs die gleiche Kapazität haben. Die Berechnung muss separat für HDDs und SSDs gemacht werden, jeder Speicher muss einen eigenen freien Speicherplatz haben. Den freien Speicherplatz errechnen Sie wie folgt:

((Gesamter Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

Diesen freien Speicherplatz ziehen Sie von Ihrem Gesamt-Brutto-Speicherplatz ab. Im späteren Verlauf der Einrichtung sehen Sie, wie diese Formel bei der Berechnung des freien Speicherplatzes genutzt wird, um sowohl freien HDD- als auch freien SSD-Speicherplatz zu berechnen.

Update: Wir haben bei der Nutzung von freiem Speicherplatz zur Ausfallsicherheit einige Probleme gehabt. Während einer Wiederherstellung der Daten sind die Datenträger in dem entsprechenden Pool so stark beschäftigt, das dies die gesamte Performance des Storage negativ beeinflusst. Dies liegt daran, dass ein Storage Pool ohne Anpassung mit der RepairPolicy auf Parallel steht.

Dies bewirkt zwar eine sehr schnelle Wiederherstellung, allerdings auch eine sehr hohe Belastung. Man könnte an dieser Stelle die RepairPolicy umstellen auf Sequential, dies käme dann aber eher dem HotSpare-Gedanken nahe. Aus diesem Grund haben wir uns entschieden, in unseren Projekten aktuell ausschließlich auf HotSpare-Datenträger zu setzen, nicht auf freien Speicherplatz. Dies beeinflusst wieder die Anzahl an Datenträgern, die benötigt werden, um auf eine gewisse Anzahl an Coloums zu kommen. Mehr dazu etwas weiter unten.

Die Art der Spiegelung

Sie können grundsätzlich zwischen drei Arten Datenträgern wählen: Simple, Mirror oder Parity. Simple ist eine einfache Speicherung der Daten ohne Schutz vor einem Ausfall, bei Mirror werden die Daten gespiegelt und bei Parity nutzen Sie eine Parität ähnlich einem RAID5, um die Daten bei einem Ausfall von einem Datenträger trotzdem noch lesen zu können. Bei der Nutzung von Storage Spaces inkl. Tiering (wird etwas weiter unten erklärt) können Sie nur Simple oder Mirror wählen, Parity ist hier nicht möglich. Da Simple in den wenigsten Fällen zum Einsatz kommen wird konzentrieren wir uns in unserem Fall ausschließlich auf Mirror. Seit dem Windows Server 2012 R2 können Sie neben einem Zwei-Wege-Spiegel (Ein Block wird auf einem Datenträger abgespeichert und gleichzeitig auf einen weiteren gespiegelt) auch einen Drei-Wege-Spiegel aufbauen. Hierbei wird ein Block auf einem Datenträger gespeichert und zusätzlich auf zwei weitere Datenträger gespiegelt.

Nutzen Sie nach Möglichkeit immer einen Drei-Wege-Spiegel. Dies mag auf den ersten Blick als Verschwendung gelten, es gibt aber einen äußerst guten Grund für diese Art der Spiegelung: In einem Storage Space werden die Blöcke nicht wie bei einem RAID1 immer nur auf zwei Datenträgern abgespeichert, sondern die Daten liegen auf allen Festplatten verteilt. Dies führt dazu, dass im schlimmsten Fall in einem Zwei-Wege-Spiegel der Ausfall von zwei Datenträgern ausreicht, um einen Datenverlust zu erzeugen. Wird eine Enclosure Awareness genutzt können theoretisch alle Datenträger in einem JBOD ausfallen, danach aber kein weiterer mehr in einem der anderen JBODs. Wir empfehlen ausdrücklich die Einrichtung eines Drei-Wege-Spiegel, da hier zumindest zwei Festplatten ausfallen können, ohne das es zu Datenverlust kommt! (TechNet Wiki: What are the resiliency levels provided by Enclosure Awareness?)

Die Blocksize / Interleave der virtuellen Datenträger

Achten Sie bei der Erstellung und Formatierung der virtuellen Datenträger (bei der Nutzung als Ablage für Hyper-V VMs) darauf, dass Sie eine Blockgröße (im englischen Interleave genannt) von 64k verwenden. Dieser Wert ist optimal bei Nutzung als Ziel für Hyper-V VMs. Wie genau Sie diesen Wert konfigurieren zeigen wir Ihnen im späteren Verlauf bei der Konfiguration der virtuellen Datenträger.

Die Anzahl der Columns / Spalten

Die Anzahl der Colums bestimmt, über wie viele Datenträger die Daten gleichzeitig pro Verbindung weggeschrieben werden. Egal ob Sie nur HDDs, nur SSDs oder eine Mischung aus beidem haben, es gibt pro virtuellem Datenträger nur einen Column-Wert. Ein paar Beispiele:

• Sie haben zwei Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben einen Column-Wert von 1, d.h. Sie können pro Vorgang 64KB abspeichern (diese werden dann auf beide Festplatten geschrieben).
• Sie haben vier Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben somit einen Column-Wert von 2, d.h. Sie können pro Vorgang 2x 64KB abspeichern (zwei Festplatten nehmen jeweils 64KB an, zwei weitere speichern eine Kopie dieser Daten).
• Sie haben 22 Festplatten und zwei SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben in dieser Konfiguration einen Column-Wert von eins, da der kleinste Wert pro Datenträger-Typ diesen Wert bestimmt. Pro Vorgang können maximal 64KB abgespeichert werden.
• Sie haben 18 Festplatten und sechs SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben somit eine Column-Anzahl von 3 und können pro Vorgang 3x 64KB abspeichern.

Diese Beispiele sollen Ihnen aufzeigen, dass nicht die Größe der SSDs bzw. HDDs ausschlaggebend sind, sondern die Anzahl. Teilweise sehen wir Konfigurationsvorschläge mit zwei 800 GB SSDs und vielen HDDs. Hier wären acht 200 GB SSDs deutlich besser. Die Column-Anzahl von eins bedeutet nicht, dass immer nur zwei Datenträger genutzt werden. Pro Vorgang werden zwei Datenträger genutzt, d.h. wenn Sie acht VMs betreiben kann jede auf jeweils zwei Datenträger schreiben (wenn der Spiegel mit kalkuliert wird, es können trotzdem nur 64KB geschrieben werden).

Bei einem Drei-Wege-Spiegel ändert sich die Berechnung ein wenig, dies kommt daher das pro Interleave drei HDDs bzw. SSDs benötigt werden. Zwei weitere Beispiele:

• Die haben neun HDDs und drei SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben eine Column-Anzahl von 1, da die drei SSDs diese Zahl erwirken. Gleichzeitig können 64KB verarbeitet werden pro Vorgang.
• Sie haben 24 HDDs und 12 SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Mit diesem Aufbau erreichen Sie einen Column-Wert von 4, bedingt durch die geringere Anzahl an SSDs.

Bei einer automatischen Erstellung der Datenträger ist die maximale Anzahl an Coloums der Wert 8, mehr werden nicht automatisch genommen. Bei der Erstellung der Datenträger per PowerShell können Sie auch einen höheren Wert auswählen. Sie müssen nicht grundsätzlich immer 8 oder mehr erreichen, Column-Werte ab 3 sind OK, falls möglich sollten Sie 4 erreichen. Alles über vier ist super, rechtfertigt aber meist nicht der erhöhten Preis für weitere SSDs (da diese in den meisten Fällen die geringe Anzahl in der Gesamtmenge ausmachen, aktuell noch bedingt durch den Preis).

Auf den Seiten von Microsoft ist eine Grafik abgebildet, die den Performance-Unterschied zwischen 2 und 4 Columns zeigt:

Quelle: TechNet Wiki: Storage Spaces – Designing for Performance

(TechNet Wiki: What are columns and how does Storage Spaces decide how many to use?)

Die Nutzung von Tiering

In der vorherigen Kapiteln wurde häufig von der Nutzung von HDDs und SSDs gleichzeitig gesprochen, hier folgt nun eine Erklärung dieser als Tiering bezeichneten Möglichkeit, die seit Windows Server 2012 R2 existiert.

Ein Pool kann unter 2012 R2 aus zwei unterschiedlichen Arten von Datenträgern bestehen, HDDs und SSDs. Hierbei ist es egal wie schnell die Festplatten sind, alle SAS-Festplatten werden als HDD behandelt. Grundsätzlich macht nur der Betrieb von Festplatten der gleichen Geschwindigkeit Sinn (z.B. immer NearLine-SAS HDDs mit 7.2k rpm). Neben HDDs können noch SSDs eingebunden werden, hier funktionieren ebenfalls nur SAS-SSDs, keine Consumer-Produkte.

Die Daten in den virtuellen Datenträgern werden vom Scale-Out File Server analysiert und je nach Nutzung entweder auf die SSDs verlagert (wenn festgestellt wird, dass die Daten häufig in Nutzung sind) oder auf den HDDs gespeichert (wenn festgestellt wird, dass die Daten nicht häufig benutzt werden). Das Betriebssystem arbeitet hier grundsätzlich mit 1 MB großen Blöcken, d.h. es werden nicht immer komplette Dateien verschoben, sondern nur 1 MB große Stücke der Datei.

Standardmäßig werden die Daten nachts um ein Uhr umsortiert, Grund hierfür ist ein Task auf den Datei Server-Knoten:

Weitere Informationen über den technischen Hintergrund finden Sie in den folgenden Beiträgen:

TechNet Blog: KeithMayer.com – Why R2? Step-by-Step: Automated Tiered Storage with Windows Server 2012 R2

TechNet Blog: Ask Premier Field Engineering (PFE) – Storage Spaces: How to configure Storage Tiers with Windows Server 2012 R2

Die Zusammenlegung von HDDs sowie SSDs führt zu der folgenden Situation: Mehrere große Festplatten, die nicht unbedingt schnell sind (z.B. 7.2k NL-SAS Festplatten mit 4 oder 6 TB) sorgen dafür, dass ausreichend Speicherplatz zur Verfügung steht. Mehrere SAS-SSDs sorgen dafür, dass der gesamte Pool ausreichend Performance bekommt.

Weiterer Vorteil bei der Nutzung von SSDs: Sie können einen Teil der SSDs als Write-Back Cache nutzen, ähnlich dem Cache auf einem RAID-Controller. Standardmäßig wird bei einem Storage Pool mit SSDs 1 GB an Speicherplatz für diese Caching-Technik genutzt. Aidan Finn hat zu diesem Thema einen Benchmark gemacht und auf seinem Blog veröffentlicht:

Aidan Finn – The Effects Of WS2012 R2 Storage Spaces Write-Back Cache

Bessere Performance-Werte um den Faktor 11 in einer (laut seiner Aussage) recht schnell aufgebauten Demo-Umgebung zeigen den unglaublichen Performanceschub bei Nutzung dieser Technik.

Lassen Sie den Standard-Wert von 1 GB auf diesem Wert stehen, dies ist laut Aussage der Produktgruppe ein optimaler Wert.

Die Vorbereitung der Server

Das Netzwerk

Nach der Grundinstallation und einem Update auf den aktuellsten Patchlevel beginnt die Einrichtung mit der Konfiguration der Netzwerkkarten. Es werden insgesamt drei Netze genutzt:

• Management – In diesem Netz befindet sich die Active Directory
• Storage1 – Eines der beiden SMB-Netze
• Storage2 – Das zweite SMB-Netz

In optimalen Fall besitzen die Server mindestens zwei Gbit-Adapter und vier 10 Gbit-Adapter. Dies ermöglicht die Nutzung von zwei Teams über beide 10 Gbit-Adapter. Dies ist notwendig, da SMB MultiChannel in einem Failover Cluster nur dann funktioniert, wenn sich alle Adapter in einem unterschiedlichen Subnetz befinden. Wenn wir davon ausgehen, dass die Hyper-V Hosts nur zwei Adapter im Storage-Netzwerk besitzen, können die SOFS-Knoten ebenfalls nur IP-Netze nutzen. Sollten die Hyper-V Hosts ebenfalls vier Adapter für SMB besitzen muss kein Team erstellt werden.

Die einzelnen Adapter werden in der Systemsteuerung umbenannt, um hier eine bessere Übersicht zu haben. Das Resultat sieht wie folgt aus:

Falls Sie mehrere Server konfigurieren möchten lässt sich diese Benennung per PowerShell ein wenig automatisieren:

Get-NetAdapter -InterfaceDescription "Intel(R) I350 Gigabit Network Connection" | Rename-NetAdapter -NewName 1GBit#1 –PassThru

Das Management-Netzwerk wird über Gbit-Karten abgebildet. Zur Redundanz werden hier zwei der vier onboard-Adapter zu einem Team zusammengeschlossen und konfiguriert. Dies kann entweder per GUI oder per PowerShell erfolgen:

New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Danach werden die Karten mit IP-Adressen versehen. Das Resultat sieht wie folgt aus:

Management

Storage1

Storage2

Diese Karte hat bis auf die IP-Adresse die exakt gleichen Einstellungen wie Storage1 bzw. 10GBit#1. Diese Karte enthält die folgende IP-Adresse

Die Storage-Karten werden übrigens nicht geteamt, SMB3 ermöglicht eine Nutzung beider Adapter gleichzeitig (SMB Multichannel).

Die Konfiguration per PowerShell

Die oben gezeigte Konfiguration lässt sich komplett per PowerShell realisieren.

# Abfrage der IP-Adresse
$IP = Read-Host "Geben Sie das letzte Oktett der IP-Adresse eine"

# Team erstellen
New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers `
    1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

# IP-Konfiguration
Set-NetIPInterface -InterfaceAlias "Management-Team" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "Management-Team" `
    -IPAddress 192.168.209.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias "Management-Team" -ServerAddresses 192.168.209.1

Set-NetIPInterface -InterfaceAlias "10GBit#1" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#1" `
    -IPAddress 192.168.208.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias "10GBit#1" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#1" -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#2" `
    -IPAddress 192.168.207.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias "10GBit#2" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

Nehmen Sie die Systeme nun in die Active Directory auf und vergeben Sie einen aussagekräftigen Namen. In unserem Fall heißen die Systeme FSNode1 und FSNode2.

Als letzten Punkt der Netzwerk-Konfiguration setzen wir auf den Systemen in den erweiterten Einstellungen innerhalb der Netzwerkverbindungen das Management-Team an die vorderste Stelle.

Die Installation der benötigten Rollen und Features

Auf den beiden Systemen werden die folgenden Rollen und Features benötigt

Der Dateiserver wird benötigt, da dieser später als Rolle im Failover Cluster installiert und eingerichtet wird. Um eine Sicherung der VM-Daten machen zu können wird ebenfalls der VSS Agent Service benötigt. Einen Schritt weiter bei den Features wird das Failover Cluster-Feature inkl. den Verwaltungstools sowie MPIO (Multipfad E/A im deutschen) benötigt. Die Installation per PowerShell sieht wie folgt aus:

Install-WindowsFeature -Name FS-Fileserver, FS-VSS-Agent, Failover-Clustering, `
    Multipath-IO -IncludeManagementTools

Wenn der Parameter –Computername noch mit angegeben wird kann die Installation auch remote durchgeführt werden.

Falls Sie noch weitere Rollen oder Features benötigen, hier ein Befehl zur Auflistung aller vorhandenen Rollen und Features:

Get-WindowsFeature | Select-Object -ExpandProperty Name | Write-Host

Die Einrichtung von MPIO

Dieser Schritt muss nur gemacht werden, wenn HDDs bzw. SSDs in einem oder mehreren JBODs verwendet werden, die mit mehr als einem SAS-Kabel angeschlossen sind. In unserem Fall hat jeder Server zwei Verbindungen pro JBOD, daher muss auf unseren Servern MPIO aktiviert werden. Die Aktivierung kann entweder per GUI oder per PowerShell gemacht werden und bedingt einen Neustart, der nach der Bestätigung des Neustarts auch direkt gemacht wird.

Per PowerShell funktioniert es mit dem folgenden Befehl

Enable-MSDSMAutomaticClaim -BusType SAS

Ein Neustart wird an dieser Stelle nicht eingefordert, ist aber auf jeden Fall sinnvoll

Restart-Computer

Die Überprüfung der Disks

Wenn Sie mehrere HDDs bzw. SSDs nutzen, kann es zu unterschiedlichen Performance-Werten bei eigentlich gleichen Datenträgern kommen. Bei einem Scale-Out File Server kann es zu sehr starken Einschränkungen bei der Gesamtperformance kommen, wenn ein oder mehrere Datenträger langsamer arbeiten wie andere. Aus diesem Grund sollten Sie vor der Nutzung Ihrer HDDs und SSDs einen Test machen, der Ihnen die Performance aller Datenträger ermittelt und aufführt. Sie benötigen ein PowerShell-Skript und die aktuellste Version des SQLIO-Tools:

Technet Script Center: Storage Spaces Physical Disk Validation Script

Microsoft Download Center: SQLIO Disk Subsystem Benchmark Tool

Technet Script Center: Completely Clearing an Existing Storage Spaces Configuration

Falls die HDDs oder SSDs bereits für etwas genutzt wurden benötigen Sie das unterste Skript zur kompletten Entfernung aller Informationen auf den Datenträgern. Achten Sie darauf, dass mit diesem Skript die Datenträger gelöscht werden. Falls Sie Daten auf den Disks noch benötigen, fertigen Sie ein Backup an!

Führen Sie das Skript aus und warten Sie darauf, dass alle Datenträger gelöscht wurden

Installieren Sie SQLIO auf dem Server und kopieren Sie die sqlio.exe-Datei an den Standort, an dem das Validation-Skript liegt. Alternativ kopieren Sie das Skript in das Installationsverzeichnis.

Führen Sie den folgenden Befehl aus und überprüfen Sie, ob die korrekten Datenträger aufgeführt werden

Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

Speichern Sie nun diese Datenträger in der Variablen $physicaldisks_to_pool mit dem Befehl

$physicaldisks_to_pool = Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

Starten Sie nun den Test mit dem folgenden Befehl

.\Validate-StoragePool.ps1 -PhysicalDisks $physicaldisks_to_pool

Der Test beginnt und listet Ihnen auf, wie viele HDDs und SSDs vorhanden sind. In meinem Fall sind es fünf SSDs und 19 HDDs. Der Test läuft nun einige Stunden, daher empfiehlt es sich diesen zu einem Zeitpunkt zu starten, an dem noch andere Aufgaben erledigt werden müssen oder der Feierabend winkt.

Als Ausgabe nach dem erfolgreichen Test erscheint der folgende Bericht

Schauen Sie sich die Warnungen und ggf. Fehler an, um potentiell schlechte Datenträger auszutauschen. In meinem Fall werden vier Datenträger bei der Leselatenz sowie drei Datenträger bei der Schreiblatenz angemerkt. Die ersten Werte liegen mit 830, 768, 776 und 801 ms nur wenig über dem Durchschnittswert von 620, bei den Schreiblatenzen könnte PhysikalDisk19 mit einer maximalen Latenz von knapp unter dem doppelten des Durchschnitts (1008 ms bei durchschnittlich 634 ms) evtl. getauscht werden. Führen Sie den Test evtl. ein zweites Mal durch und vergleichen Sie die Ergebnisse, um zufällige hohe Latenzen auszumerzen.

Die Erstellung des Failover Cluster

Wir sind nun an der Stelle angelangt, an dem das Failover Cluster erstellt und konfiguriert werden kann. Öffnen Sie dazu den Failover Cluster Manager und wählen Sie den Punkt Konfiguration überprüfen bzw. Validate Configuration….

Wählen Sie die beiden Server aus, die Mitglied des Failover Cluster werden sollen und führen Sie alle Tests aus.

Der Test versucht nun, alle Festplatten an allen Knoten zu erreichen. Sollte es hier zu Problemen kommen, wird Ihnen dies an dieser Stelle direkt angemerkt, nicht erst zu einem späteren Zeitpunkt während der Erstellung bzw. Konfiguration.

Sie können diesen Test natürlich auch per PowerShell starten, der Befehl hierzu lautet

Test-Cluster -Node FSNode1,FSNode2

Sie können jederzeit sehen, an welchem Punkt der Test sich gerade befindet

Nach Beendigung sehen Sie ein Ergebnis sowie den Pfad zu dem kompletten Bericht des Tests.

Schauen Sie sich diesen Test unbedingt an und korrigieren Sie potentielle Fehler. Sie können auch mit dem Parameter –ReportName einen Namen und einen Speicherort für den Bericht angeben, das macht die Suche einfacher.

Nachdem die Konfiguration nun überprüft wurde können Sie den Failover Cluster erstellen. Beenden Sie dazu den Überprüfungs-Assistenten und wechseln Sie in den Cluster erstellen-Assistenten. Fügen Sie die beiden Knoten hinzu

und wählen Sie einen Namen und eine IP-Adresse für das Failover Cluster. Da ich in meinem Fall kein Gateway gesetzt habe werde ich für alle Netze nach einer Adresse gefragt. An dieser Stelle deaktiviere ich alle Netze bis auf das Management-Netzwerk und setze nur in diesem Netzwerk eine IP-Adresse.

Achten Sie im nächsten Schritt unbedingt darauf, dass Sie den gesamten verfügbaren Speicher nicht automatisch hinzufügen lassen!

Nach einem Klick auf Weiter wird das Failover Cluster erstellt. Die Alternative per PowerShell wäre

New-Cluster –Name FSCluster1 –Node FSNode1,FSNode2 –StaticAddress `
    192.168.209.110 -IgnoreNetwork 192.168.207.0/24,192.168.208.0/24 –NoStorage

Nach der Erstellung können Sie das Failover Cluster über den Failover Cluster Manager administrieren und benutzen.

Die Konfiguration des Failover Cluster zur Nutzung als Scale-Out File Server

Nach der Erstellung müssen noch ein paar Einstellungen angepasst werden, bevor die Erstellung des hochverfügbaren Dateiservers beginnen kann.

Das Netzwerk

Die Netzwerke sind aktuell in einer recht unsagenden Reihenfolge benannt, dies möchten wir gerne ändern und sprechende Namen verwenden. Wechseln Sie im linken Menü auf Netzwerk und setzen Sie die Namen der Netzwerke so, wie sie auch auf den lokalen Hosts konfiguriert sind.

Per Hand geht dies über die Eigenschaften der einzelnen Netzwerke, per PowerShell mit den folgenden drei Zeilen

(Get-ClusterNetwork | where-object {$_.Address -eq "192.168.209.0"}).Name = "Management"
(Get-ClusterNetwork | where-object {$_.Address -eq "192.168.208.0"}).Name = "Storage1"
(Get-ClusterNetwork | where-object {$_.Address -eq "192.168.207.0"}).Name = "Storage2"

Nach der Umbenennung sehen die Netzwerke wie folgt aus

Neben dem Netzwerk sollte noch die Metrik der einzelnen Karten überprüft werden. Dies geht ausschließlich per PowerShell

Get-ClusterNetwork | ft Name, Metric, AutoMetric -AutoSize

In meinem Fall hat Storage2 die kleinste Metric, dies bedeutet diese Karte hat im Failover Cluster die höchste Priorität (Je kleiner die Metric, desto höher die Priorität; allerdings immer abhängig von den anderen Karten). Die hier automatisch gesetzten Werte sind in Ordnung, falls diese geändert werden sollen geht dies mit den folgenden Befehlen

(Get-ClusterNetwork "Management").Metric = 200
(Get-ClusterNetwork "Storage1").Metric = 100
(Get-ClusterNetwork "Storage2").Metric = 101

In diesem Beispiel wird Storage1 die Karten mit der höchsten Priorität, gefolgt von Storage2.

Ein Livemigration-Netzwerk müssen wir in dieser Art von Failover Cluster nicht aktiv konfigurieren, da keine VMs betrieben werden und somit auch kein RAM übertragen werden muss.

Zur Nutzung der beiden Storage-Karten für den Dateiserver später muss die Nutzung im Cluster umgestellt werden. Aktuell stehen die Netzwerke auf “Cluster only”, dies muss korrigiert werden auf “Cluster and Client”, da sonst kein Zugriff auf die Freigaben über diese Karten möglich ist. Setzen Sie die Option über die Gui

oder per PowerShell:

(Get-ClusterNetwork "Storage1").Role = 3

(Get-ClusterNetwork "Storage2").Role = 3

Die Rolle 1 bedeutet “Nur Cluster”, 3 bedeutet “Cluster und Client”.

Der Datenträgerpool

Um mit den Datenträgern in unserem JBOD arbeiten zu können wird ein Pool benötigt. Dieser Pool enthält alle HDDs und SSDs, die Erstellung kann per GUI oder per PowerShell vorgenommen werden.

Im Failover Cluster Manager wechseln Sie unter Speicher auf Pools und erstellen mit dem Menüpunkt Neuer Storage Pool eine neue Ansammlung von Datenträgern.

Im nächsten Schritt können Sie die Datenträger wählen, die Mitglied des Pools werden sollen. Sie sehen hier bereits die Größe, den Steckplatz, den Typ und weitere Informationen.

Unter Zuordnung bzw. Allocation belassen Sie alle Datenträger auf Automatisch, außer Sie wollen an dieser Stelle eine oder mehrere HotSpare-Datenträger definieren. Nach einem Klick auf Weiter sehen Sie eine Zusammenfassung, danach kann die Erstellung beginnen.

Per PowerShell können Sie den Pool wie folgt einrichten:

Suchen Sie im ersten Schritt nach allen verfügbaren Datenträgern

Get-PhysicalDisk | ft FriendlyName, CanPool, PhysicalLocation –AutoSize

Dieser Befehl listet Ihnen alle physischen Datenträger auf und zeigt Ihnen sowohl die Fähigkeit, einem Pool beizutreten als auch den Ort, an dem der Datenträger verbunden ist. In meinem Fall sehen wir auf dem System insgesamt 26 Datenträger, wovon 24 in meinem JBOD stecken

Datenträger 0 und 25 haben keine Informationen über den Aufenthaltsort, bei den anderen 24 Datenträgern erkennt man das JBOD. Mit der folgenden Zeile können Sie alle Festplatten zum Pool hinzufügen, achten Sie aber darauf die Seriennummer an Ihre eigene PhysicalLocation anzupassen.

New-StoragePool -FriendlyName Pool01 -StorageSubSystemFriendlyName *Spaces* `
    -PhysicalDisks (Get-PhysicalDisk | where PhysicalLocation -like *500093D001CEC000*)

Falls mehrere JBODs eingesetzt werden, sollte an dieser Stelle die Enclosure Awareness eingeschaltet werden. Dies geht ausschließlich per PowerShell und wird mit dem folgenden Befehl erreicht:

Get-StoragePool -FriendlyName Pool01 | Set-StoragePool -EnclosureAwareDefault $true

Überprüfen können Sie den Wert mit dem folgenden Befehl:

Get-StoragePool -FriendlyName Pool01 | ft FriendlyName, EnclosureAwareDefault -AutoSize

Nun haben wir einen Pool, der im nächsten Schritt als Grundlage für unsere virtuellen Datenträger genutzt werden kann.

Die Erstellung der virtuellen Datenträger

Bei der Erstellung der Datenträger sollten Sie (wie bereits in den Vorbemerkungen weiter oben angesprochen) darauf achten, dass Sie ausreichend Platz lassen, damit der Rebuild bei einem Ausfall schnell funktionieren kann. Ich nutze in diesem Aufbau insgesamt 24 Datenträger, wovon fünf SSDs mit jeweils 200 GB und 19 HDDs mit jeweils 1 TB Speicherplatz sind.

Rein theoretisch habe ich nun die folgenden Werte in meinem Scale-Out File Server:

• Anzahl JBODs: 1
• Coloums: 5, da insgesamt fünf SSDs vorhanden sind
• Freier HDD-Speicherplatz: ((19TB/19+ 8GB) * 1 = 1,008 TB
• Freier SSD-Speicherplatz: ((1000GB/5) + 8GB) * 1 = 208 GB

Wir erinnern uns, die Formel zur Berechnung ist

((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

Da wir ja alle seit der Erfindung von calc.exe eher weniger im Kopf rechnen möchten hier ein kleines Skript, welches die genaue Anzahl des freien Speicherplatz ausrechnet und in entsprechender Form ausgibt:

# j.kappen@rachfahl.de, 23.04.2014, Kalkulation des freien Speicherplatzes in einem StoragePool
# Ausgabe der vorhandenen Pools
Get-StoragePool
Write-Host ""
Write-Host ""

# Abfrage der Enclosure und des Pool-Namen
$anzahlenclosure = Read-Host "Geben Sie die Anzahl der Enclosure an"
$poolname = Read-Host "Geben Sie den Namen des Pools an, bei dem die Groessen berechnet werden sollen"

# Berechnung des SSD-Speichers
$disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq SSD
$ssdSpace = 0
$ssddiskCount = 0
foreach ($disk in $disks)
{
if ($disk.MediaType -eq "SSD")
{
$ssdSpace += $disk.Size
$ssddiskCount++
}
}

# Berechnung des HDD-Speichers
$disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq HDD
$hddSpace = 0
$hdddiskCount = 0
foreach ($disk in $disks)
{
if ($disk.MediaType -eq "HDD")
{
$hddSpace += $disk.Size
$hdddiskCount++
}
}

#Berechnung
$ssdSpaceinGB = $ssdSpace / 1024 / 1024 / 1024
$hddSpaceinGB = $hddSpace / 1024 / 1024 / 1024
$hddSpaceinTB = $hddSpace / 1024 / 1024 / 1024 / 1024
# ((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure
$freessdspace = (($ssdSpaceinGB / $ssddiskCount) + 8) * $anzahlenclosure
$freehddspace = (($hddSpaceinGB / $hdddiskCount) + 8) * $anzahlenclosure

# Ausgabe der Ergebnisse
Write-Host -ForegroundColor Green "Kalkulation der empfohlenen Groessen"
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green "Anzahl der SSDs:" $ssddiskCount
Write-Host -ForegroundColor Green "Gesamter SSD-Speicherplatz"
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green $ssdSpace "Byte =>" $ssdSpaceinGB "GB"
Write-Host ""
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green "Freier benoetigter SSD-Speicherplatz"
Write-Host -ForegroundColor Green $freessdspace "GB"
Write-Host ""
Write-Host ""
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green "Anzahl der HDDs:" $hdddiskCount
Write-Host -ForegroundColor Green "Gesamter HDD-Speicherplatz"
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green $hddSpace "Byte =>" $hddSpaceinGB "GB =>" $hddSpaceinTB "TB"
Write-Host ""
Write-Host -ForegroundColor Green "————————————–"
Write-Host -ForegroundColor Green "Freier benoetigter HDD-Speicherplatz"
Write-Host -ForegroundColor Green $freehddspace "GB"

Download: Berechnung_Freier_Speicherplatz_SOFS.txt

Das Skript fragt die Anzahl der Enclosure und den Namen des Pools ab und errechnet danach sowohl für SSDs als auch für HDDs den freien Speicherplatz.

Da wir nun den Speicherplatz ausgerechnet haben können wir mit der Erstellung der Datenträger fortfahren. Dies geht entweder per Failover Cluster Manager oder per PowerShell. Die GUI erlaubt ziemlich wenig Anpassungen gegenüber den Standardwerten, der wichtigste Punkt ist die Konfiguration der Blockgröße / des Interleave. Aus diesem Grund nehme ich die komplette Erstellung innerhalb der PowerShell vor.

Bei der Anzahl der Datenträger benötigen wir mindestens so viele Datenträger wie Cluster Knoten, in meinem Fall zwei. Zusätzlich kommt noch ein Quorum-Datenträger hinzu mit einer Größe von fünf GB. Dieser wird seit Server 2012 R2 immer benötigt, da immer ein Quorum zugewiesen wird und das Failover Cluster dynamisch mit dem Quorum arbeitet oder nicht, je nach Anzahl der Knoten. Da wir in diesem Aufbau zwei Server haben wir sowieso ein Quorum benötigt.

Die Erstellung des Quorum

Zur Erstellung des Quorum wird der folgende Befehl verwendet

Get-StoragePool Pool01 | New-VirtualDisk -FriendlyName "FSQuorum" -ResiliencySettingName "Mirror" -NumberOfDataCopies 3 -Size 5GB -Interleave 64KB

Dies bewirkt, dass im Storage Pool Pool01 ein neuer Datenträger mit dem Namen FSQuorum angelegt wird. Die Datensicherheit (Resiliency) ist ein Spiegel (Mirror), die Anzahl der Kopien sind 3 (d.h. es ist ein Drei-Wege-Spiegel). Die Größe wird mit 5 GB angegeben und die Interleave-Größe beträgt 64KB. Nach der Erstellung sieht der Datenträger im Failover Cluster Manager bzw. in der PowerShell wie folgt aus

Man erkennt, dass der Datenträger 8 GB groß geworden ist, trotz dem Befehl mit 5 GB. Dies liegt vermutlich an der Aufteilung der Daten auf den unterschiedlichen Festplatten, 8 GB scheint in diesem Fall die kleinste Größe zu sein. Bei knapp 20 TB an Speicherplatz ist dies aber nicht weiter tragisch.

Da ich bei der Erstellung nichts von einem Tiering angegeben habe, wurde dieser Datenträger komplett auf HDDs angelegt. Dies ist nicht weiter schlimm, auf dem Quorum-Datenträger wird sehr wenig geschrieben und gelesen, daher ist hier Tiering absolut nicht notwendig.

Damit ich das Laufwerk nutzen kann muss es nun noch formatiert werden. Dies geht entweder manuell über den Failover Cluster Manager (und auch nur, wenn der Wartungsmodus für den Datenträger aktiviert ist) oder ebenfalls per PowerShell. Achten Sie bei der Formatierung per GUI darauf, dass der Datenträger auf dem Host liegt, auf dem Sie die Formatierung machen möchten. In meinem Fall ist dies FSNode1.

# Datenträger auflisten
Get-VirtualDisk
Write-Host ""
Write-Host -ForegroundColor Red "Achtung, diese Aktion formatiert einen oder mehrere Datenträger!"
Write-Host ""
# Name abfragen
$vdName = Read-Host "Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten"
# Lokalen Computernamen herausfinden und speichern
$ComputerName = $env:COMPUTERNAME
# Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
Move-ClusterGroup “Available Storage” –Node $ComputerName
# Cluster-Ressourcen auflisten und einlesen
$clusterResource = Get-ClusterResource | where Name -like *$vdName*
# Wartungsmodus aktivieren
Suspend-ClusterResource $clusterResource
# Datenträger formatieren
Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume `
    –FileSystem NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
#unset VirtualDisk Maintance Mode
Resume-ClusterResource $clusterResource

Download: Formatierung_Datentraeger_FailoverCluster.txt

Nach der Formatierung sieht der Datenträger im Failover Cluster Manager wie folgt aus

Die Erstellung der weiteren CSV-Datenträger

Im zweiten Schritt werden nun die CSV-Datenträger erstellt, in denen letztendlich die Daten der VMs gespeichert werden. Ich habe zwei Server, daher erstelle ich zwei virtuelle Datenträger. Um die korrekte Größe inkl. dem bereits erstellten Quorum zu setzen, hier ein weiteres Skript, welches auf die Daten aufbaut, die das vorherige Skript ausgeworfen hat.

$gesamtHDDSpace = Read-Host "Geben sie die gesamte HDD-Größe in GB ein"
$gesamtSSDSpace = Read-Host "Geben sie die gesamte SSD-Größe in GB ein"
$freierHDDSpace = Read-Host "Geben sie Reserve-Speicherplatz der HDDs in GB ein"
$freierSSDSpace = Read-Host "Geben sie Reserve-Speicherplatz der SSDs in GB ein"
$mirrorlevel = Read-Host "Geben Sie den Spiegel an, den Sie nutzen möchten (2 oder 3)"
$anzahlvdisks = Read-Host "Geben Sie die Anzahl der CSV-Datenträger ein"
Write-Host ""
$hddcsvsize = ($gesamtHDDSpace – $freierHDDSpace) / $mirrorlevel / $anzahlvdisks
$ssdcsvsize = ($gesamtSSDSpace – $freierSSDSpace) / $mirrorlevel / $anzahlvdisks
Write-Host -ForegroundColor Green "Größe des SSD-Speicherplatz:" $ssdcsvsize
Write-Host -ForegroundColor Green "Größe des HDD-Speicherplatz:" $hddcsvsize

Zur Erstellung werden die folgenden Zeilen Code genutzt:

# Storage-Tiers entfernen
Get-StorageTier | Remove-StorageTier

# Definiton
$poolName = "Pool01"
$ssdTierName = "SSD-Tier"+ $poolName
$hddTierName = "HDD-Tier"+ $poolName
$dataCopies = 3
$columnCount = 1

New-StorageTier -StoragePoolFriendlyName $poolName `
-FriendlyName $ssdTierName -MediaType SSD
New-StorageTier -StoragePoolFriendlyName $poolName `
-FriendlyName $hddTierName -MediaType HDD

$ssd_tier = Get-StorageTier | where FriendlyName -eq $ssdTierName
$hdd_tier = Get-StorageTier | where FriendlyName -eq $hddTierName
$ssdTierSize = 122GB
$hddTierSize = 2791GB

# Erstellung der Datenträger
New-VirtualDisk -StoragePoolFriendlyName $poolName `
-StorageTiers @($ssd_tier,$hdd_tier) `
-StorageTierSizes $ssdTierSize,$hddTierSize `
-ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
-NumberOfColumns $columnCount -ProvisioningType Fixed `
-FriendlyName vDisk1 -Interleave 64KB -IsEnclosureAware:$true

New-VirtualDisk -StoragePoolFriendlyName $poolName `
-StorageTiers @($ssd_tier,$hdd_tier) `
-StorageTierSizes @($ssdTierSize,$hddTierSize) `
-ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
-NumberOfColumns $columnCount -ProvisioningType Fixed `
-FriendlyName vDisk2 -Interleave 64KB -IsEnclosureAware:$true

Auf Wunsch können diese Datenträger nun auch noch per PowerShell formatiert werden. Hierzu wird das gleiche Verfahren wie bei dem Quorum-Datenträger genutzt.

# Datenträger auflisten
Get-VirtualDisk
Write-Host ""
Write-Host -ForegroundColor Red "Achtung, diese Aktion formatiert einen oder mehrere Datenträger!"
Write-Host ""
# Name abfragen
$vdName = Read-Host "Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten"
# Lokalen Computernamen herausfinden und speichern
$ComputerName = $env:COMPUTERNAME
# Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
Move-ClusterGroup “Available Storage” –Node $ComputerName
# Cluster-Ressourcen auflisten und einlesen
$clusterResource = Get-ClusterResource | where Name -like *$vdName*
# Wartungsmodus aktivieren
Suspend-ClusterResource $clusterResource
# Datenträger formatieren
Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume –FileSystem `
    NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
#unset VirtualDisk Maintance Mode
Resume-ClusterResource $clusterResource

Nun sind zwei neue Datenträger vorhanden, jeweils mit einer Größe von 2,84 TB. Die Formatierung ist ebenfalls gemacht worden, die Blockgröße von 64KB wurde hierbei beachtet. In meinem Fall kann ich nur eine Coloum-Zahl von 1 verwenden, da fünf SSDs durch drei 1,66 sind. Alles nach dem Komma zählt nicht, die Coloum-Zahl beträgt 1. Um auf 2 zu kommen würde noch eine weitere SSD benötigt, für jede weitere Zahl drei weitere SSDs.

Damit diese Datenträger später als Speicher des Scale-Out File Server genutzt werden können müssen sie zu den Cluster Shared Volumes hinzugefügt werden. Dies geschieht entweder über den entsprechenden Punkt im Kontext-Menü oder per PowerShell:

Get-VirtualDisk
Write-Host ""
$vdName = Read-Host "Geben Sie den Namen des Datenträgers ein, der als CSV-Datenträger konfiguriert werden soll"
$clusterResource = Get-ClusterResource -Name "*$vdName*"
Add-ClusterSharedVolume -InputObject $clusterResource

Die Konfiguration der Quorum-Einstellungen

Als nächstes muss der 8 GB große Datenträger als Quorum-Datenträger konfiguriert werden. Dies geht über den Failover Cluster Manager über die erweiterten Befehle und dem Punkt Clusterquorumeinstellungen konfigurieren

Die Alternative per PowerShell:

Set-ClusterQuorum -NodeAndDiskMajority "Cluster Virtual Disk (FSQuorum)"

Mit diesem Schritt ist die Konfiguration schon beendet.

Die Erstellung und Konfiguration der Dateiserver-Rolle

Im nächsten Schritt müssen wir die Dateiserver-Rolle installieren und einrichten. Per GUI wird dies über Rollen – Rolle konfigurieren gemacht.

Wählen Sie den Dateiserver aus und bestätigen Sie die Auswahl mit Weiter.

Der nächste Schritt ist der wichtigste, an dieser Stelle wird die Art des Dateiserver ausgewählt. Der obere Punkt ist ein gewöhnlicher Dateiserver, der für die Ablage von Dateien genutzt werden kann. Dies wird in unserem Fall nicht benötigt, wir benötigen die untere Art von Dateiserver (im englischen als Scale-Out File Server bezeichnet, im deutschen als Dateiserver mit horizontaler Skalierung).

Unter Clientzugriffspunkt müssen Sie einen Namen für den Dateiserver eingeben. Unter diesem Namen ist der Server im Netzwerk erreichbar und ansprechbar. In meinem Fall nenne ich den Zugriffspunkt SOFS, d.h. mein Scale-Out File Server ist im Netzwerk unter \\SOFS\Share1 erreichbar.

Nach einer Überprüfung der AD auf ein evtl. schon vorhandenes Objekt mit diesem Namen bekommen Sie eine Zusammenfassung der Einstellungen, Sie sehen hier direkt die drei Subnetze, die von der Rolle genutzt werden.

Nach einem Klick auf Weiter beginnt die Erstellung der Rolle. Die Installation per PowerShell kann mit dem folgenden Befehl durchgeführt werden:

Add-ClusterScaleOutFileServerRole -Name "SOFS"

Als nächster Schritt kommt nun die Erstellung mehrerer Freigaben, auf die unsere Hyper-V Hosts zugreifen können. Wählen Sie im Kontextmenü der Dateiserver-Rolle den Punkt Freigabe hinzufügen.

Wenn Sie die folgende Meldung erhalten

haben Sie zwei Möglichkeiten. Entweder Sie holen sich jetzt einen Kaffee und versuchen es später erneut, oder Sie verschieben die Dateiserver-Rolle auf den Host, auf dem Sie gerade angemeldet sind. Falls dies immer noch nichts bringt und Ihr Failover Cluster-Manager Fehler bringt, die ein Berechtigungsproblem in Ihrem DNS anmerken (dies war bei mir der Fall, da die Objekte im DNS bereits vorhanden waren und nicht überschrieben werden konnten), gehen Sie wie folgt vor: Löschen Sie im DNS alle Einträge mit dem Namen des Scale-Out File Server. Erstellen Sie danach ein neues Objekt mit dem Namen und einer IP. Fügen Sie danach in den Sicherheitseinstellungen des DNS-Objekt das Computerobjekt hinzu und geben Sie ihm die Rechte zur Änderung des Eintrags:

Bestätigen Sie die Einstellungen und verschieben Sie die Dateiserver-Rolle erneut. Nun sollten keine Fehler mehr auftauchen und die Erstellung einer neuen Freigabe sollte ebenfalls funktionieren. Weiterhin werden alle IPs im DNS unter dem Namen der Rolle angelegt.

Es öffnet sich ein Assistent, der Sie durch die Erstellung der Freigabe führt. Als erstes müssen Sie ein Profil auswählen, um welche Art von Freigabe es sich handelt. Da wir VMs speichern möchten sollte das Profil Anwendungen gewählt werden

Im nächsten Schritt können Sie den Server wählen, hier ist direkt unsere Dateiserver-Rolle angewählt. im mittleren Bereich können Sie sehen, dass Sie hier nur die beiden CSVs auswählen können, keinen lokalen Pfad. Wir beginnen mit Volume1 und fahren im Assistenten fort.

Vergeben Sie nun einen Namen für die Freigabe. Ich habe sie in meinem Fall Share1 genannt. Sie können erkennen, wie sich der Name im unteren Bereich einträgt. An dieser Stelle können Sie bereits den kompletten Pfad sehen, über den Sie später Ihre VMs speichern.

Nach einem Klick auf Weiter sehen Sie, dass die erhöhte Verfügbarkeit eingeschaltet ist und auch nicht entfernt werden kann. Diese Option ermöglicht einen nahtlosen Betrieb der VMs, auch bei einem Ausfall oder einem Neustart eines der Datei Server-Knoten

Nun kommen wir zu einer sehr wichtigen Stelle: Die Konfiguration der Berechtigungen für diese Freigabe

Passen Sie diese Einstellungen wie folgt an: Wählen Sie Berechtigungen anpassen im unteren Bereich und deaktivieren Sie als erstes die Vererbung. Danach entfernen Sie die Benutzer-Berechtigungen auf dieser Freigabe, Benutzer haben an dieser Stelle nichts zu suchen. Fügen Sie danach die Computerkonten aller Hyper-V Hosts hinzu, die auf diese Freigabe zugreifen sollen. Zusätzlich fügen Sie das bzw. die Cluster-Objekte hinzu der Hyper-V Failover Cluster (falls Sie einen oder mehrere Hyper-V Failover Cluster betreiben). Zuletzt geben Sie den AD-Admins noch eine Berechtigung auf diese Freigabe.

Das Ergebnis sieht wie folgt aus

Nach einem Klick auf Weiter bekommen Sie eine kurze Zusammenfassung der Einstellungen, wenn diese korrekt sind können Sie die Freigabe erstellen.

Erstellen Sie eine zweite Freigabe, die auf dem Volume2 erstellt wird. Die Einstellungen bleiben die gleichen, nur der Name ändert sich. Das Resultat sieht wie folgt aus

Die Einrichtung per PowerShell sieht wie folgt aus:

# Konfiguration_NTFS_Berechtigungen.ps1 – Jan Kappen – j.kappen@rachfahl.de
# Erstellung einer neuen Freigabe für die SOFS-Rolle und Anpassung
# der Rechte. Eine Anpassung ist notwendig an den markierten Stellen
#
# Konfiguration des Namen
# Anpassung notwendig!
$Sharename = "Share6"
$Volumename = "Volume1"
# Erstellen des neuen Ordners
New-Item -Name $Sharename -ItemType Directory
mkdir C:\ClusterStorage\$Volumename\Shares\$Sharename
# Erstellung eines neuen Shares mit HA und ohne Caching
#
# Falls die Quorum-Freigabe erstellt werden soll, kann der Parameter
# -ContiniousAvailable auf $false angepasst werden
#
New-SmbShare -Name $Sharename -Path C:\ClusterStorage\$Volumename\Shares\$Sharename `
-CachingMode None -FullAccess "everyone" -ContinuouslyAvailable $true
# Anzeige der Berechtigungen
Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename" | fl
# Benutzer aus den Rechten entfernen
$colRights = [System.Security.AccessControl.FileSystemRights]"Read"
$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None
$objType =[System.Security.AccessControl.AccessControlType]::Allow
$objUser = New-Object System.Security.Principal.NTAccount("BUILTIN\Users")
$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)
$objACL = Get-ACL "C:\ClusterStorage\$Volumename\Shares\$Sharename"
$objACL.RemoveAccessRuleAll($objACE)
Set-ACL "C:\ClusterStorage\$Volumename\Shares\$Sharename" $objACL
# Anzeige der Berechtigungen
Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename" | fl
# Besitzer konfigurieren
$acl = Get-Acl "C:\ClusterStorage\$Volumename\Shares\$Sharename"
$acl.SetOwner([System.Security.Principal.NTAccount] "Administrators")
Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
#
$acl = Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename
$acl.SetAccessRuleProtection($True, $False)
#
# Anpassung der Systemnamen sowie des Failover Cluster-Objekts notwendig!
#
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("Powerkurs\Hyperv14$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("Powerkurs\Hyperv15$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("Powerkurs\powercluster1$","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("Powerkurs\domain admins","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("SYSTEM","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
("CREATOR OWNER","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
# Erneute Anzeige der Einstellungen
Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename  | Format-List

Download: PowerShell Skript: Konfiguration_NTFS_Berechtigungen

Die Erstellung einer Freigabe zur Nutzung als Quorum

An dieser Stelle müssen wir noch eine weitere Freigabe erstellen, die als Quorum für unser Hyper-V Failover Cluster genutzt wird. Bei dieser Freigabe gibt es eine kleine Besonderheit: Sie sollte nicht dauerhaft zur Verfügung stehen, heißt wir konfigurieren diese Freigabe ein wenig anders. Diese Konfiguration kann allerdings erst nach der Erstellung gemacht werden, die Erstellung ist gleich wie bei den beiden Shares oben. In welchem Volume Sie die Freigabe erstellen ist grundsätzlich egal, ich lege sie in meinem Fall auf Volume1.

Nach der Erstellung sehen Sie einen weiteren Share:

An dieser Stelle wechseln wir in die Eigenschaften von dieser Freigabe und konfigurieren in den Einstellungen die erhöhte Verfügbarkeit so, dass diese nicht markiert ist

Update 30. Juni 2015: Wir haben festgestellt, dass diese Einstellung (trotz Empfehlung seitens Microsoft) nicht optimal ist, da es zu Fehlern im Eventlog auf den Hyper-V Hosts bzw. im Hyper-V Cluster kommt. Wird der Share im CA-Modus (also mit Haken) betrieben, tauchen keine Fehler auf. Laut Best-Practice-Empfehlung erfolgt der Schwenk des Quorum bei einem Ausfall eines SOFS-Knoten schneller. Beide Varianten sind transparent, ob es nun schneller oder langsamer geht ist somit auch zu vernachlässigen. Mit eingeschalteter CA erscheinen keine Fehler, dies erleichtert das Monitoring.

Nun kann die Einstellung übernommen werden und die Freigabe ist korrekt konfiguriert.

Quelle: Failover Clustering and Network Load Balancing Team Blog – Configuring a File Share Witness on a Scale-Out File Server

Dieser Vorgang funktioniert auch mit dem oben verlinkten Skript, im oberen Teil bei der Erstellung der Freigabe müssen Sie eine Anpassung bei dem Parameter –ContiniouslyAvailable machen (weitere Infos im Skript), danach wird eine passende Freigabe erstellt.

Nach dieser Anpassung ist der Aufbau im groben komplett. Sie können nun per \\sofs\Share1 oder \\sofs\Share2 auf die beiden Freigaben zugreifen, zusätzlich kann die dritte Freigabe als Quorum-Ablage genutzt werden.

Noch ein paar Worte zu Zugriffszeiten, Benchmarks usw…

Wenn Sie das erste Mal auf die neu erstellten Freigaben zugreifen, kann es einige Zeit dauern, bis das Verzeichnis aufgerufen werden kann und Sie durch die Ordner navigieren können. Dies ist normal, es braucht einen kleinen Moment bis die Verzeichnisse erstmals aufgerufen werden können. Lassen Sie sich hier nicht beunruhigen. Wenn Sie während der Einrichtungs- bzw. Test-Phase das komplette Cluster herunterfahren oder alle Server gleichzeitig neustarten kann es nach dem Start ebenfalls einige Zeit dauern, bis alle Zugriffe wieder problemlos und ohne Verzögerung passieren. Planen Sie hier bitte ebenfalls ein paar Minuten ein, bis alles wieder flüssig und sauber läuft. Im Betrieb sind diese kompletten Ausschaltungen eher selten, daher passiert dies meist bei Simulationen von Problemen oder der kompletten Abschaltung des Dateiserver Cluster.

Wenn Sie einen Performance-Test Ihres neu erstellten Scale-Out File Server machen möchten, fällt Ihnen wahrscheinlich als erstes die Kopie einer Datei auf einen der beiden Shares ein. Dies können Sie zwar machen, lassen Sie sich aber nicht von den Werten abschrecken, die sie während des Kopiervorgangs bekommen. Ein Scale-Out File Server speichert alle Blöcke ungepuffert. Dies wirkt sich bei Datei-Kopier-Operationen negativ aus, bei dem eigentlichen Betrieb des Speichers (der Ablage von VM-Daten) ist dies aber notwendig, damit alle Dateien und Blöcke immer definitiv auf den Platten landen, und nicht in irgendeinem Cache, der bei einem Stromausfall verfallen würde. Ein besserer Benchmark-Test wäre der Betrieb von einigen VMs, in denen mit Hilfe von Last- oder Benchmark-Tools I/O erzeugt wird. Selbst bei diesem Test gibt es wiederum einige Dinge, die beachtet werden sollten. Eine VM alleine reicht nicht, erst die Summe einiger VMs erzeugt (vielleicht) die Art von Last, die im späteren Betrieb auch auf dem System anliegt. Die Tiering-Funktion greift erst dann, wenn eine Umsortierung der Blöcke stattgefunden hat. Dies passiert, wie weiter oben erwähnt, standardmäßig täglich um 1:00 Uhr nachts. Eine Verbesserung der Benchmark-Werte (z.B. bei einem dauerhaften Benchmark) zeigt sich somit erst nach frühestens einem Tag.

Die Nutzung eines Skripts zur kompletten Failover Cluster-Erstellung

Die in diesem Beitrag genutzten Skripte sind fast alles Teilbereiche eines Skripts, welches mein Kollege Carsten Rachfahl bereits in einem Video genutzt und für unsere Zwecke angepasst hat. Das Skript kann ein komplettes Failover-Cluster inkl. Berechnung der Größen, Aufteilung und Erstellung der Datenträger usw. erstellen. Das Skript sowie das ziemlich sehenswerte Video finden Sie hier: Hyper-V-Server.de: Einen bestehenden Scale-Out Fileserver um SSDs erweitern

An diese Stelle ist die Einrichtung im großen und ganzen abgeschlossen. Je nach Umgebung stehen nun noch weitere Schritte an, spontan fällt mir hier noch das Thema Backup ein.

Bei Fragen, der Suche nach Unterstützung oder der Durchführung solch eines Projekts stehen wir Ihnen natürlich gerne zur Verfügung.

In diesem Beitrag geht es darum, wie man mit recht einfachen Mitteln einen oder mehrere Scale-Out File Server überwachen kann. Voraussetzung ist, dass Sie einen Scale-Out File Server mit JBODs betreiben. Ein Aufbau mit einem oder mehreren SANs kann zwar auch überwacht werden, hier können aber weniger Informationen ausgelesen werden. Grundlage ist das von Jose Barreto geschriebene PowerShell-Skript Test-StorageHealth. Das Skript verbindet sich mit einem Scale-Out File Server Cluster und überprüft ziemlich viele Dinge, unter Anderem den Status von Festplatten, Enclosures, Volumes usw. Ich habe mit einem zweiten Skript das Verhalten dahingehend ein wenig verändert, dass der Status, der sonst in dem PowerShell-Fenster oder in einer Datei auf dem Server selbst liegt, per Mail an einen Empfänger oder einen Verteiler gesendet werden kann. So kann z.B. jeden Morgen die Mail überprüft werden, ohne das jedes Mal eine Verbindung zu dem Failover Cluster-Knoten aufgebaut werden muss. Aber beginnen wir erst einmal mit dem Skript an sich:

Das Test-StorageHealth-Skript

Das Skript selbst kann direkt aus der TechNet-Gallery bezogen werden:

Test-StorageHealth.ps1 – Storage Cluster Health Test

Nach dem Download kann das Skript direkt ohne weitere Informationen oder Parameter aufgerufen werden. Dieser Aufruf (ohne Parameter) beginnt einige Informationen über den Failover Cluster zu sammeln. Bedingung ist, dass das Skript auf einem der Knoten direkt ausgeführt wird. Die Daten werden nach Beendigung des Skripts im Ordner “HealthStatus” im Profil des aktiven Benutzers gespeichert. In den wenigsten Fällen werden die überprüften Werte in dem Skript automatisch passen, daher sollten diese vor dem ersten Aufruf angepasst werden. Öffnen Sie die Datei Test-StorageHealth.ps1 in einem Editor (z.B. der PowerShell ISE) und passen Sie die Werte in den Zeilen 60 bis 116 an. Angepasst werden sollten:

• Zeile 83:  [int] $ExpectedNodes = 4, => Hier tragen Sie die Anzahl der Hardware-Knoten ein
• Zeile 87: [int] $ExpectedNetworks = 2, => Die Anzahl der Netzwerke in Ihrem Cluster
• Zeile 91: [int] $ExpectedVolumes = 33, => Die Anzahl an Datenträgern im Cluster
• Zeile 95: [int] $ExpectedDedupVolumes = 16, => Die Anzahl an Datenträgern mit aktivem Dedup
• Zeile 99: [int] $ExpectedPhysicalDisks = 240,=> Die Anzahl an Datenträgern (HDDs und SSDs)
• Zeile 103: [int] $ExpectedPools = 3,=> Die Anzahl an Datenträgerpools
• Zeile 107: [int] $ExpectedEnclosures = 4, => Die Anzahl an Enclosures

Die Einstellungen müssen nicht unbedingt in der Datei gemacht werden, Sie können das Skript auch bei jedem Aufruf mit Hilfe von zusätzlichen Parametern anpassen. Ein Aufruf des Skripts sähe dann z.B. wie folgt aus:

.\Test-StorageHealth.ps1 -ExpectedNodes 2 -ExpectedNetworks 3 -ExpectedVolumes 3 -ExpectedDedupVolumes 0 -ExpectedPhysicalDisks 24 -ExpectedPools 1 -ExpectedEnclosures 1 -HoursOfEvents 12

Weitere Erklärungen finden Sie in dem folgenden Beitrag: How to use the Test-StorageHealth.ps1 PowerShell script with different configurations

Die von dem Skript erzeugte Datei kann nachträglich erneut aufgerufen werden. Hierzu rufen Sie das Skript mit dem Parameter –ReadFromPath C:\Datei.zip auf.

Der automatische Mail-Versand des Skripts

Das Skript generell ist ein echt cooles Stück PowerShell-Code, allerdings kann standardmäßig keine Email erzeugt werden, die die Ausgabe an einen oder mehrere Empfänger sendet. Ich habe diesen Teil mal übernommen und ein kleines Skript “drum herum” gebaut, welches die Ausgabe, die man oben in den PowerShell-Fenstern sieht, automatisch per Mail zugesandt bekommt. Grundlage hiervon war das Autotiering-Skript von Carsten, ich habe letztendlich “nur” die einzelnen Pfade angepasst und das neue Skript lauffähig gemacht.

Download: Task_Test-StorageHealth.zip

In dem Zip-Archiv ist ein eigenes kleines Skript enthalten, welches den Aufruf des eigentlichen Überprüfung-Skripts übernimmt und die Ausgabe automatisch per Email sendet. Dazu sind innerhalb des Skripts ein paar Anpassungen notwendig.

Mail-Server:

Kommentieren Sie die Zeilen 6-8 aus und nehmen Sie die Auskommentierung von Zeile 9-11 weg. Tragen Sie in Zeile 9 Ihren Mail-Server ein, definieren Sie in Zeile 10 den Empfänger und bei Bedarf können Sie in der Zeile 11 noch den Absender der Email-anpassen.

Logfile:

In Zeile 14 können Sie den Ort des Logfiles anpassen, an dem der Mail-Inhalt ebenfalls nochmal abgelegt wird.

Das Test-StorageHealth-Skript

In Zeile 22 müssen Sie den Pfad zu dem eigentlichen Skript anpassen. Alternativ können Sie natürlich auch das Skript unter C:\tools ablegen, in diesem Fall muss keine Anpassung mehr vorgenommen werden. Falls Sie den Pfad, an dem die .zip-Datei mit dem Ergebnis abgelegt wird, ebenfalls anpassen wollen, müssen Sie die Zeile 22 auskommentieren und die Zeile 21 nutzen. Der Parameter –zipPrefix definiert, wo die Datei gespeichert wird. Achten Sie unbedingt darauf, dass der Pfad mit einem “\” abgeschlossen wird!

Speichern Sie die Änderungen und testen Sie das Skript einem Aufruf der Datei über eine administrative PowerShell. Wenn dies erfolgreich ist und im besten Fall direkt eine Email ankommt, können Sie mit der Einrichtung des Tasks fortfahren.

Erstellen Sie über die Aufgabenplanung einen neuen Task mit den folgenden Einstellungen:

Die Zeit ist natürlich egal, Sie können das Skript auch alle sechs Stunden oder nur einmal in der Woche ausführen, je nach Bedarf.

Unter Aktionen tragen Sie bei Programm/Skript C:\Windows\system32\windowspowershell\v1.0\powershell.exe ein, unter Argumente hinzufügen tragen Sie den Pfad zu der Datei Task_Test-StorageHealth.ps1 ein.

Vergeben Sie ein Konto und ein Kennwort, unter dem der Task ausgeführt werden soll. Fertig ist die Erstellung, nun wird zu der definierten Zeit das Skript ausgeführt und meldet die Ausgabe per Email.

Diesen Task könnte man nun auch noch auf den anderen Knoten im Failover Cluster einstellen. Der Bericht meldet das gleiche, allerdings kommt auch bei dem Ausfall von Knoten A ein Bericht, in dem der Ausfall von einem Node vermeldet wird. Alternativ lassen Sie das Skript auf einem Server außerhalb des Failover Cluster laufen, hierzu müssen Sie allerdings den Namen des Failover Cluster noch mit angeben. Dies muss in der Datei Test-StorageHealth.ps1-Datei gemacht werden (Zeile 67: [string] $ClusterName = “.”,).

Ich habe für die November-Ausgabe des IT-Administrator einen eigenen Artikel beigesteuert, in dem ich den Test einer Violin 6000 beschreibe. Das Gerät ist ein Storage-System, welches ausschließlich mit Flash Speicher arbeitet. Der Artikel beschreibt das Gerät, die durchgeführten Tests und natürlich die Ergebnisse, die in diesem Test ermittelt wurden.

Die November-Ausgabe ist seit dem 04. November erhältlich und kann eigentlich überall dort erworben werden, wo es Zeitschriften gibt. Alternativ kann das Heft natürlich auch direkt bestellt werden: IT-Administrator: Ausgabe November 2014 Storage & Datenmanagement.

Wer einen hohen Bedarf an IOPS, niedrigen Latenzen und/oder Performance im Bereich Netzwerkspeicher hat, kommt um ein System mit flashbasiertem Speicher kaum herum. Es gibt unterschiedliche Ansätze, wie die benötigte Leistung erbracht werden kann. In diesem Test geht es um ein System der Firma Violin Memory, die mit der Violin 6000 All Flash Arrays ein Speichersystem anbietet, welches ausschließlich auf Flash-Speicher basierend und mit zu einer Million IOPS bei einer äußerst geringen Latenz eine High-End Lösung bereit stellt. Welche Performance dieses System im Bereich der Virtualisierung mit Hyper-V bietet schauen wir uns in diesem Artikel an.

Dieser Artikel ist im November 2014 bereits im IT-Administrator Magazin erschienen.

6100, 6200 oder 6600?

Innerhalb der Violin 6000 Serie gibt es mehrere Varianten, die sich in der Art des Flash Speichers, der Größe, der maximalen Performance und natürlich dem Preis unterscheiden.

*) Dieses Modell gibt es nicht als Windows Flash Array, sondern nur mit dem Violin-eigenen Betriebssystem vMOS.

**) die Nutzkapazität ist abhängig von der Formatierung. Die Werte beziehen sich auf ein Formatierungslevel von 84%.

Das in diesem Test genutzte Modell trägt die Bezeichnung Violin 6264 und bietet eine Brutto-Speicherkapazität von 70 TB, wovon 44 TB nutzbar sind. Die Anzahl der IOPS, die mit diesem Modell erreicht werden können, liegen laut Datenblatt des Herstellers bei 750.000.

Der technische Aufbau

Neben dem reinen Flash-Speicher enthält das Gerät unter anderen noch zwei Server (vom Hersteller als Memory Gateways, abgekürzt MG, bezeichnet), die mit Windows Server 2012 R2 in der Storage Edition betrieben werden. Die Lizenzen für diese Server sind bereits enthalten, auf jedem der beiden Server-Einheiten befindet sich ein Lizenzaufkleber. Beide Server sind intern mehrfach redundant an den Flash-Speicher angebunden, dies wird über vier aktiv/aktiv RAID-Controller (vRAID Control Modules, abgekürzt VCM) erreicht. Von diesen vier VCMs könnten bis zu drei ausfallen, der Betrieb würde (wenn auch verständlicherweise mit Leistungseinbußen) weiterhin funktionieren. Der Speicher in dem Testgerät besteht aus einzelnen Modulen mit einer Größe von jeweils 1 TB, diese werden als Violin Intelligent Memory Modules bezeichnet (im weiteren Verlauf mit VIMM abgekürzt). Fünf dieser VIMMs werden jeweils zu einem Verbund (vom Hersteller wird dieser Verbund als VIMM Protection Group bezeichnet) zusammengefasst. Eingehende Daten werden grundsätzlich in 4KB großen Blöcken abgespeichert. In jedes VIMM einer VIMM Protection Group werden 1 KB geschrieben, in das fünfte VIMM werden zusätzlich 1KB Paritätsinformationen geschrieben. Vorweg geschaltete Array Control Module (ACM) sorgen dafür, dass eingehende Daten nur in Speicher geschrieben werden, der gerade nicht durch einen anderen Prozess beeinflusst wird. Diese Technik umgeht Performance-Einbrüche durch anstehende oder gerade aktive Lösch-Aktionen oder durch eine aktive Garbage Collection und sorgt für eine durchgehend hohe Performance.

Für den Ausfall eines VIMMs stehen insgesamt vier Hot Spare-VIMMs zur Verfügung. Sollte es zu einem Ausfall kommen, können alle Komponenten (VIMMs, VCMs, Netzteile, …) im Betrieb getauscht werden.

Eine Anbindung der Server per Netzwerk nach „außen“ wird je nach Konfiguration über Fibre Channel (acht Ports mit je 4 oder 8 Gb/s), Ethernet (acht Ports mit je 10 Gb/s) oder Infiniband (vier Ports mit je 40 Gb/s) erreicht, wobei die Fibre Channel-Variante ausschließlich bei dem vMOS-System zum Einsatz kommt. Bei den Windows Flash Array-Modellen haben Sie „nur“ die Wahl zwischen Ethernet oder Infiniband. Das uns zur Verfügung stehende Gerät besitzt die bereits erwähnte Anbindung per Ethernet, d.h. es stehen insgesamt 80 Gb/s zur Verfügung. Verbaut sind vier Karten der Firma Chelsio mit jeweils zwei Interfaces (Chelsio T-520CR Dual-Port 10 Gigabit Ethernet Adapter). Jeder der beiden Server bekommt zwei dieser Karten zugewiesen und kommt somit auf eine Bandbreite von 40 Gb/s. Die Karten unterstützen Remote Direct Memory Access (RDMA), auf diese Funktionalität gehen wir später erneut ein und schauen uns die Vorteile dieser Technik an.

Zusätzlich zur Anbindung über 40 Gb/s besitzt jeder Server noch einen Intel 82579LM- sowie zwei Intel I350-Adapter mit einer Bandbreite von jeweils 1 Gb/s.

Beide Server verfügen über 24 GB RAM (die Anzahl an RAM könnte bei Bedarf auf bis zu 48 GB erhöht werden) sowie zwei Intel Xeon E5-2448L CPUs mit jeweils 20 MB L3 Cache. Jede CPU besitzt acht Cores, dank Hyperthreading käme jeder Server somit auf 32 logische Prozessoren.

Die Speicherbereitstellung

Die beiden in dem Storage verbauten Server werden nicht direkt zur Virtualisierung genutzt, sondern stellen den Flash-Speicher über SMB 3 im Netzwerk zur Verfügung. Die beiden Systeme werden zu einem Failover Cluster konfiguriert, innerhalb dieses Clusters wird eine hochverfügbare Dateiserver-Rolle betrieben. Diese Art von Dateiserver wird als Scale-Out File Server bezeichnet. Sollte einer der beiden Server ausfallen, übernimmt der zweite Server den kompletten Betrieb alleine. Dieser Vorgang ist vollständig transparent, es kommt zu keiner Kommunikationsunterbrechung zwischen dem Dateiserver und den angeschlossenen Hyper-V Hosts. Voraussetzung für die Nutzung dieser Technik auf Seiten der Virtualisierungs-Hosts ist mindestens ein Windows Server 2012, absolut empfohlen ist allerdings die Nutzung von Windows Server 2012 R2, da hier einige Änderungen und Verbesserungen in das Produkt eingeflossen sind.

Die Installation der beiden Server wird über einen kleinen Wizard gestartet, hier werden grundsätzliche Informationen wie Name, Kennwort und IP-Adresse abgefragt. Nach der Installation sind beide Systeme per Remote Desktop zu erreichen und können entweder manuell oder über den im Betriebssystem enthaltenen Assistenten administriert werden.

Der Storage kann über das Violin Control Utility administriert werden. Das Programm selbst hat wenig Konfigurationsmöglichkeiten, Sie können lediglich vorhandene LUNs löschen oder neue anlegen. Sichtbar sind noch weitere Informationen über die Controller und die Art von Speicher, hier können aber keine Änderungen vorgenommen werden. Alle erstellten LUNs sind immer beiden Servern zugewiesen, nach dem Anlegen können Sie die Datenträger in der Datenträgerverwaltung sehen und verwalten. Negativ fällt auf, dass keine Möglichkeit zur Größenänderung der LUNs vorhanden ist.

Einen generellen Überblick über das gesamte System erhalten Sie über die Weboberfläche. Diese ist über einen Webbrowser erreichbar und zeigt einige Informationen über das System an.

Zusätzlich können über den Bereich Administration noch weitere Aufgaben ausgeführt werden, z.B. ein Neustart des Systems, eine Anpassung von IP-Adressen oder die Anzeige der Logdatei.

Die Konsole macht einen sehr aufgeräumten Eindruck und zeigt sehr schnell einige Informationen über den aktuellen Betriebsstatus an.

SMB Direct

Die in dem Testsystem verbauten 10 GbE-Karten sind RDMA-fähig. Dies bedeutet, dass bei einer Kommunikation zwischen dem SMB-Server (in diesem Fall einer der beiden Scale-Out File Server Knoten) und einem SMB-Client (Verwechseln Sie Client nicht mit einem „normalen“ Client, in diesem Fall ist mit SMB-Client ein Hyper-V Host gemeint) eine sehr hohe Bandbreite bei einer sehr geringen Latenz erreicht werden kann. Dies liegt daran, dass ein SMB-Client die Daten auf dem Datei-Server direkt in seinen Arbeitsspeicher liest. Da bei dieser Aktion weder die CPU des Datei-Servers noch die CPU des SMB-Clients (in diesem Fall des Hyper-V Hosts) genutzt werden muss, stehen beiden Systemen diese Ressourcen für andere Aufgaben zur Verfügung. Auf Seiten des Dateiservers ist dies z.B die Bearbeitung von Nicht-RDMA-Traffic, auf Seiten des Hypervisor führt dies unter anderem zu einer Erhöhung der VM-Anzahl, die Sie auf diesem System betreiben können.

Die hier genutzten Karten nutzen die iWARP-Technik. Vorteil dieser RDMA-Variante (z.B. gegenüber der RoCE-Variante) ist, dass auf Seiten der Switches keine weitere Konfiguration vorgenommen werden muss. Bei der Einrichtung ist darauf zu achten, dass für die 10 GbE-Karten kein Team konfiguriert werden darf. Sobald ein Adapter Mitglied in einem Team ist, steht die RDMA-Funktionalität nicht mehr zur Verfügung. Da in den Hyper-V Hosts jeweils nur zwei Ports mit iWARP-Technik zur Verfügung stehen, werden im Dateiserver-Failover Cluster ebenfalls nur zwei der vier möglichen Ports pro Server genutzt.

Das System unter Last

Um die Performance des Systems unter Last zu sehen, wurde ein Scale-Out File Server mit insgesamt fünf Datenträgern angelegt. Drei der Datenträger spielen bei der Betrachtung der Leistung keine Rolle, da einer dieser Datenträger ausschließlich als Datenträgerzeuge im Quorum verwendet wurde und die anderen beiden nicht benötigt werden (Anmerkung: Zwei jeweils 10 TB große Datenträger reichen aus, um pro Datenträger über 1200 Instanzen der Benchmark-VM zu speichern). Die anderen beiden Datenträger wurden als Cluster Shared Volume konfiguriert, jeder dieser Datenträger bietet ebenfalls eine Speicherkapazität von 10 TB.

Auf Seite der Hyper-V Hosts wurden acht Systeme ohne RDMA-Karten sowie zwei Systeme mit RDMA-Karten genutzt, um Last auf dem Storage zu erzeugen. Pro Host laufen VMs, in denen das SQLIO-Programm von Microsoft für eine Belastung sorgt. Zeitweise sorgen insgesamt 440 dieser VMs für eine Belastung von Netzwerk und Storage. Die Nicht-RDMA-Systeme sind Schulungsrechner mit einem Intel Core i5-2400S bzw. einem Intel Core i7-3770, 24 bzw. 32 GB RAM, zwei 1 Gb/s Karten sowie einer Intel X540-T2 Karte mit zwei 10 Gb/s-Ports. Bei den RDMA-Systemen handelt es sich um Cisco Server mit zwei Intel E5-2650 CPUs, 128 GB RAM, vier 1 Gb/s Ports sowie einer Chelsio T420-BT Karte mit zwei 10 Gb/s-Ports.

In jeder VM wird nach dem Start automatisiert eine SQLIO-Instanz gestartet, die von einer zentralen Freigabe eine Konfigurations-Datei herunterlädt und mit den konfigurierten Werten startet. Pro Durchlauf werden jeweils 60 Sekunden lang die Tests Random Read, Random Write, Sequential Read und Sequential Write durchgeführt. Jeder Durchlauf beinhaltet zwei Schleifen. Nach diesem Durchlauf wartet das Programm eine beliebige Zeit zwischen 0 und 60 Sekunden, bevor der nächste Durchlauf startet. Vor jedem Durchlauf wird die Konfiguration erneut von der zentralen Freigabe heruntergeladen, falls in dieser Zeit Änderungen vorgenommen wurden (z.B. eine Änderung der Block-Größe) werden diese nun angewandt. In dem folgenden Screenshot sehen Sie eine VM, in der ein Test mit einer Blockgröße von 8KB durchgeführt wird.

Laufen alle VMs einige Zeit, verschieben sich durch die Zufalls-Wartezeiten zwischen den einzelnen Durchläufen die Tests so, dass die Belastung nicht immer parallel anliegt, sondern variiert und so eine möglichst reale Umgebung versucht nachzustellen. Durch die Messung einiger aussagekräftiger Leistungsindikatoren in der Windows Leistungsüberwachung über einen gewissen Zeitraum lassen sich so einige Werte ermitteln, die die Performance des Geräts zeigen.

Die Tests in Zahlen

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Die ermittelten Werte zeigen, dass in Summe durchschnittlich fast 180.000 IOPS realisiert werden konnten. Die maximalen Werte liegen sogar noch deutlich höher, hier konnten über 250.000 IOPS gemessen werden. Die gemessenen Größen pro Anfrage zeigen sehr deutlich, dass das SQLIO-Tool wie gewünscht 4KB große Blöcke erzeugt und verarbeitet hat. Die durchschnittliche Zeit pro Anfrage liegt laut Anzeige durchschnittlich bei 1 ms, was bei der großen Anzahl an IOPS und der großen Menge an Anfragen sehr gut ist. Die Höhe des Datendurchsatzes spielt hier eher weniger eine Rolle, trotzdem sind die Daten auch in der Tabelle zu finden.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Bei einer Erhöhung der Blockgröße des SQLIO-Tests auf 8KB zeigt sich, dass die IOPS nur leicht steigen gegenüber den Tests mit 4KB großen Blöcken. Bei diesem und allen anderen Werten (außer den 4K-Werten) muss allerdings zusätzlich beachtet werden, dass die Messung auf den Dateiserver-Knoten in 8KB IOPS durchgeführt werden. Auf dem Violin-System selbst werden die IOPS durchgehend in 4KB gemessen und angezeigt, da hier ausschließlich 4KB große Blöcke verarbeitet werden. Auf Seiten des Storage müssen die hier aufgeführten Werte verdoppelt werden, um einen direkten Vergleich gegenüber dem vorherigen Benchmark mit 4KB zu haben.

Die erreichten Transferraten steigen ebenfalls um knapp das doppelte, hier kann logischerweise mit einer größeren Blockgröße und einer fast gleichen IOPS-Anzahl auch ein höherer Durchsatz erreicht werden. Die Verarbeitungszeit der Daten bleibt weiterhin konstant bei (gerundet) 1ms.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 64KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Durch die Erhöhung der Blockgrößen auf 64 KB zeigt sich eine weitere Verringerung der IOPS auf durchschnittlich knapp 45.000, aber auch eine deutliche Steigerung der Transferraten. Durchschnittlich konnten über beide Freigaben kontinuierlich 2 Gigabyte pro Sekunde verarbeitet werden (sowohl schreibend als auch lesend), zu Spitzenzeiten stieg die Bandbreite auf knapp 3 Gigabyte. Da die Verarbeitung von solch großen Blöcken seine Zeit braucht, stieg die durchschnittliche Bearbeitungszeit pro Paket auf durchschnittlich 15 ms.

Probleme bei der Erzeugung von Last und Grenzen der Testumgebung

Bei der Erzeugung einer möglichst hohen Belastung auf dem Flash-Storage sind wir bei der Menge der VMs (trotz Nutzung von RDMA) an Grenzen gestoßen. Die Nicht-RDMA-fähigen Hyper-V Hosts waren bei der Ausführung von jeweils 20 VMs fast an der Grenze ihrer CPU-Leistung, diese lag durchschnittlich zwischen 80 und 95%. Insgesamt acht Hosts konnten so insgesamt 160 VMs betreiben.

Auf Seiten der Cisco Server mit den verbauten Chelsio T420-BT Karten mussten wir feststellen, dass 50 VMs den Server zu knapp 50% auslasten und je nach Blockgröße für eine Bandbreite zwischen 16 und 18 Gb/s pro Hyper-V Host sorgen. Zwei dieser Systeme konnten so mit 100 VMs Tests auf dem Violin Storage durchführen. Weitere Hyper-V Hosts mit RDMA-fähigen Netzwerkkarten hätten so noch mehr VMs betreiben können, bei denen die Messwerte wahrscheinlich noch weiter gestiegen wären. Hierbei wäre dann allerdings zu beachten, dass die beiden NICs in den Memory Gateways um weitere Karten erweitert werden müssen, da sonst die Anbindung mit 20 Gb/s der Flaschenhals in dem Aufbau ist. Da die Karten logisch in jeweils einem eigenen Subnetz liegen müssen (SMB Multi Channel in einem Failover Cluster funktioniert nur, wenn die Karten logisch getrennt sind), werden auf Seiten der Hyper-V Hosts ebenfalls weitere Karten benötigt. Dies ist einer der vielen Dinge, die während der Planungsphase berücksichtigt werden muss, damit es im späteren Betrieb nicht an „nur“ 20 Gb/s hängt.

Während der Tests hat sich gezeigt, dass ein Betrieb von VMs mit dynamisch erweiterbarer Festplatte die Performance sehr stark (negativ) beeinflusst. VMs sollten ausschließlich mit VHDX-Dateien in einer festen Größe betrieben werden, um hier von vorn herein mögliche Engpässe auszuschließen. Zum Zeitpunkt der Erstellung dieses Tests arbeitet der Hersteller gemeinsam mit Microsoft bereits an einer Best Practise-Beschreibung, die unter anderem diesen Punkt beinhaltet. Weiterhin werden einige weitere Empfehlungen ausgesprochen, die einen Betrieb mit Hyper-V möglichst optimal vorbereiten.

Neben den reinen Messwerten gibt es ja immer auf Seiten des Administrators (bzw. in meinem Fall des Testers) ein Gefühl für den Betrieb, die „gefühlte Geschwindigkeit“. Bei der Arbeit mit dem Violin System habe ich zu keinem Zeitpunkt auf Seiten der Hyper-V Hosts oder der VMs ein Problem in Bezug auf die Performance gehabt. Selbst während einer Belastung des Storage mit 260 VMs, in denen alle die SQLIO-Tests liefen, gab es keine Hänger bei der Arbeit mit einer VM. Alle durchgeführten Aktionen waren gewohnt schnell, z.B. der Start von Programmen, einer Auflistung aller Dateien auf dem Laufwerk C: oder dem Kopieren von Dateien auf ein Netzlaufwerk oder von einem Netzlaufwerk in die entsprechende VM.

Die Nutzung des CSV Block Cache

Ab dem Windows Server 2012 gibt es die Funktion des CSV Block Cache. Bei dieser Technik kann bei der Nutzung von CSV-Datenträgern in einem Failover Cluster ein gewisser Teil des RAMs als Lese-Cache genutzt werden. Unter Windows Server 2012 mussten zur Aktivierung dieser Funktion die Datenträger offline und wieder online genommen wurden. Dies bedeutet, dass die Funktion entweder direkt bei der Installation eingeschaltet werden musste oder im späteren Betrieb eine Downtime geplant werden musste, damit die Funktion nachträglich aktiviert werden konnte. Nach der Aktivierung kann bis zu 20% des verfügbaren Speichers genutzt werden. Die Empfehlung von Microsoft lautet bei Hyper-V Hosts, die Größen allerdings sehr moderat zu setzen und gibt hier Größen von 512MB bis maximal 2GB vor. Bei Scale-Out File Server-Systemen kann eine größere Menge an RAM genutzt werden, hier können problemlos 4GB oder mehr genutzt werden. (Quelle: http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx)

Unter Windows Server 2012 R2 hat sich die Aktivierung und Nutzung dieser Funktion verbessert, dies liegt unter anderem daran, dass die Funktion schon direkt bei der Installation und Einrichtung aktiviert ist, die Größe des zu nutzenden Speichers allerdings bei 0MB liegt. Sie müssen hier nur noch die Größe des Speichers anpassen, ein offline und wieder online schalten und somit ein Ausfall der Systeme auf diesem Volume muss nicht mehr berücksichtigt werden. Bei einem hochverfügbaren Dateiserver unter Windows Server 2012 R2 müssen Sie allerdings beachten, dass die gleichzeitige Nutzung von Tiering und einem CSV Block Cache nicht möglich ist. Sie können diese Funktion zwar aktivieren, es wird allerdings kein RAM als Lesecache genutzt.

Warum erzähle ich Ihnen all diese Informationen? Ganz einfach, in unserem Fall setzen wir mit der Violin einen Scale-Out File Server ein, der nur über eine Art von Speicher verfügt und somit kein Tiering (im deutschen als Speicherebenen bezeichnet) nutzt. Die verbauten VIMMs sind zwar schon unglaublich schnell und haben eine sehr geringe Latenz, allerdings dürfte der in den beiden Servern verbaute RAM noch deutlich schneller sein. Wir aktivieren nun in beiden Systemen jeweils 8GB RAM, starten die Systeme durch und schauen uns an, welche Veränderungen der Benchmark zeigt.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Fazit zur Nutzung des CSV Block Cache

Nach der Aktivierung des CSV Block Cache zeigte sich ein interessantes Verhalten: Bei Blockgrößen von 4KB und 8KB sanken die Daten fast komplett ein, nahezu alle Messwerte waren mit aktiviertem CSV Block Cache deutlich schlechter als ohne. Bei einer Blockgröße von 64KB waren die Unterschiede nicht mehr messbar, beide Tests zeigten annährend gleiche Werte. Interessant sind auch die Zugriffszeiten mit und ohne aktivierten CSV Block Cache: Während bei deaktiviertem Cache die Zugriffszeiten (bei 4KB und 8KB) konstant bei 1ms liegen, variieren diese mit aktiviertem Cache bei zwischen 0ms (bzw. nicht messbar durch den Performance Monitor) und 8ms.

Der Vergleich der jeweiligen Benchmarks zeigt direkt eine absolute Empfehlung: Schalten Sie den CSV Block Cache nicht ein. Die Aktivierung verschlechtert die Leistung signifikant.

Quellen:

http://blogs.technet.com/b/storageserver/archive/2014/04/22/violin-and-microsoft-jointly-develop-a-high-performance-all-flash-enterprise-storage-appliance-powered-by-windows-storage-server-2012-r2.aspx

http://www.chelsio.com/nic/t5-unified-wire-adapters/t520-cr/

http://pull.vmem.com/wp-content/uploads/techoverview-federal.pdf

http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx (CSV Block Cache)

Wir haben in letzter Zeit einige Erfahrungen beim Aufbau und Betrieb von diversen Scale-Out File Server Failover Clustern sammeln können. Ich habe im Mai letzten Jahres bereits einen Artikel über die Best Practises beim Aufbau eines Scale-Out File Server beschrieben (Unsere Best Practise-Erfahrungen – Teil 2 – Die Installation und Einrichtung eines Scale-Out Fileserver unter Windows Server 2012 R2), hier kommen nun noch einmal ein paar Dinge hinzu. Wir haben die folgenden Informationen teilweise direkt von Microsoft erhalten, teilweise sind es Erfahrungen die wir in Projekten gesammelt haben und manchmal ist es eine Mischung aus beidem.

Die SAS MPIO Policy

Wenn Sie einen Scale-Out File Server mit JBODs betreiben, sollten diese redundant per SAS angebunden sein. Damit die unterschiedlichen Wege zu den einzelnen Datenträgern nicht jeweils einen Datenträger pro Verbindung anzeigen, ist die Installation und Aktivierung von MPIO für SAS Pflicht. Wenn Sie Festplatten in Ihren JBODs verbaut haben (d.h. drehende Speichermedien, keine SSDs ausschließlich) sollten Sie die MPIO-Policy für SAS umstellen. Mit dem PowerShell-Befehl

Get-MSDSMGlobalDefaultLoadBalancePolicy

können Sie den aktuellen Status abrufen. Dieser steht bei einer Konfiguration, an der keine Änderungen vorgenommen wurden, auf None. Dies sollte umkonfiguriert werden, da es teilweise bei der Nutzung der automatischen Einstellung (None bedeutet, dass die Standard-Policy genutzt wird, in den allermeisten Fällen RoundRobin) zu erheblichen Performance-Einbrüchen kommt. Setzen Sie die Policy auf jedem Server (mit der RTM-Version von Windows Server 2012 R2 war dies noch eine clusterweite Einstellung, dies hat sich geändert) um auf den Wert FOO (FailOverOnly). Der komplette Befehl hierzu lautet

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy FOO

Überprüfen Sie die Einstellung erneut mit dem Befehl weiter oben.

Verwenden Sie immer die aktuellsten Treiber und Firmware-Stände

Wir haben festgestellt, das neuere Firmware-Stände von SAS HBAs, SSDs oder Enclosures sowie aktuellere Treiber enormen Einfluss auf den Betrieb und die Performance haben. Dies liegt vermutlich daran, dass die Komponenten noch nicht allzu lange verfügbar sind und daher noch Optimierungen und Anpassungen vorgenommen werden, die deutlichen Einfluss haben. Überprüfen Sie in regelmäßigen Abständen, ob es neue Treiber/Firmware/Software für Ihre Umgebung gibt. Dies gilt besonders für die Firmware der SSDs, falls Sie einen getierten Storage betreiben.

Achten Sie auf die Performance-Einstellungen Ihrer Server

In den meisten BIOS-Einstellungen von Hardware-Systemen gibt es die Möglichkeit, die Performance-Einstellungen der Hardware (insbesondere die der CPU) über Profile zu konfigurieren. Achten Sie darauf, dass Ihre Scale-Out File Server Hosts auf “Full Performance”, “Maximum Performance” oder wie der Hersteller Ihres Servers es auch immer nennt, betreiben. In einem Fall hat sich diese Einstellung bei Hosts (vermutlich durch ein BIOS-Update) auf einen Mixed-Mode zurückgestellt. Das Ergebnis war eine deutliche Erhöhung der Zeit, die für nächtlich Aufgaben benötigt wurden. Achten Sie sehr genau auf diese Einstellung, hier geht es im schlimmsten Fall um eine Erhöhung der Zeit um 250%. Bei eigentlich fünf Stunden macht sich diese Einstellung schon deutlich bemerkbar.

Deaktivieren Sie TRIM auf Ihren Systemen

Wenn Sie neben Festplatten noch SSDs oder ausschließlich SSDs in Ihrem Storage Cluster nutzen, sollten Sie die “TRIM und Unmap”-Funktion deaktivieren. In diesem Dokument, welches sich leider nur sehr schwer finden lässt, wird beschrieben, dass die Performance bei aktiver “TRIM und Unmap”-Nutzung sinken kann.

Deaktivieren können Sie die Funktion mit dem Befehl

fsutil behavior set disabledeletenotify 1

Nach dem Setzen der Einstellung (auf jedem SOFS Cluster-Knoten) müssen die Server neugestartet werden. Teilweise wird diese Funktion direkt in den SSDs bereit deaktiviert, je nach Firmware-Version. Seagate hat vor kurzem Version 006 der SSD-Firmware (für unsere SSDs z.B.) veröffentlicht, hier ist TRIM von Haus aus deaktiviert. SanDisk hat mit der Version 326 ebenfalls eine Firmware veröffentlicht, in der TRIM deaktiviert ist.

Installieren Sie benötigte Hotfixes

Microsoft hat ein Hotfix veröffentlicht, welches eine neue Version der TCPIP.sys einspielt. Ein Kunde hatte das Problem, das vereinzelt Bluescreens in der Umgebung aufgetreten sind mit der Meldung

UNEXPECTED_KERNEL_MODE_TRAP (7f)

Der Hotfix ist hier zu finden: Crash on Windows 8.1 or Windows Server 2012 R2 when a WPF driver calls the FwpsConstructIpHeaderForTransportPacket0 function

Heute erreichte mich eine ganz besondere Email, seit der es schwer ist, nicht mit einem Grinsen durch die Welt zu laufen. Ich bin heute zum ersten Mal zum Microsoft MVP ernannt worden, und zwar im Bereich File System Storage. Grundlage für diese Auszeichnung ist die Arbeit, die wir (Carsten und ich) gemeinsam in das Thema Scale-Out File Server und hochverfügbare Datei-Dienste stecken. Wir nutzen diese Art der File Services nun schon weit mehr als ein Jahr selbst und haben schon in einigen Projekten Scale-Out File Server installiert. Ich persönlich bin ziemlich begeistert von der Möglichkeit, wie man mit recht wenig Aufwand einen hochverfügbaren Dateiserver aufbauen kann, der in Form von Leistung und Kosten andere System weit in den Schatten stellt.

Ich möchte mich an dieser Stelle bei meinem Kollegen und Freund Carsten bedanken, ohne den diese Nominierung definitiv nicht funktioniert hätte. Carsten hat einen großen Anteil an dem Wissen, das ich habe und das ich in den letzten Jahren gewinnen konnte. Weiterhin habe ich an meiner Arbeit die Freiheiten und Möglichkeiten, all dies so machen zu können, damit ich so etwas wie einen MVP Titel erreiche. Dies ist nicht selbstverständlich oder normal, auch hierfür möchte ich mich bedanken.

Das war mein erster April 2015, mein erster MVP-Titel, und nun werde ich mit einem Lächeln einschlafen :)

Da ich aktuell bei einem Kunden sitze und einen Scale-Out File Server konfiguriere ist mir aufgefallen, dass wir noch keinen Beitrag bzgl. den Repair-Einstellungen in einem Storage Pool und besonders die Änderungen durch das November-Update 2014 (Update2 für Server 2012 R2, KB3000850) geschrieben haben. Durch die Installation bekommt man mehr Möglichkeiten, um den Fast Rebuild / Quick Rebuild-Vorgang anzupassen. Dies wirkt sich auf die Performance aus, die Sie während einem Rebuild-Prozess haben.

Beim Einsatz von hochverfügbaren Storage Spaces gibt es zwei Möglichkeiten, den Ausfall von einem Datenträger möglichst zeitnah abzufangen: Der Einsatz von Hot Spare-Datenträgern oder die Nutzung der Fast Rebuild-Technik. Beim Einsatz einer oder mehreren Hot Spare-Datenträgern ist die Nutzung so wie bei RAID-Controllern, Block-Storage-Systemen usw: Es stehen ungenutzte Datenträger zur Verfügung, die bei Ausfall einer Produktiv-Festplatte einspringen und an Stelle von dem ausgefallenen Datenträger genutzt werden. Diese Variante hat den Nachteil, dass bei dem Ausfall von einem Datenträger die Daten von diesem auf die Hot Spare-Festplatte geschrieben werden müssen, damit die Redundanz wieder zur Verfügung steht. Dieser Vorgang kann recht lange dauern (abhängig von Größe, Geschwindigkeit und Menge der Daten) und im dümmsten Fall fällt dieser Datenträger, der lange Zeit entweder nicht lief oder nicht produktiv genutzt wurde, aus.

Microsoft setzt bei den Storage Spaces auf eine andere Technik. Alle Datenträger werden zu einem Pool hinzugefügt (eine logische Zusammenfassung aller Datenträger, die genutzt werden sollen inkl. den Festplatten, die eigentlich als Hot Spare-Datenträger genutzt werden sollen). Nun werden basierend auf dem Pool virtuelle Datenträger erzeugt. Bei der Erstellung dieser Datenträger nutzt man nicht den kompletten Speicherplatz, der in dem Pool zur Verfügung steht, sondern man lässt einen gewissen Bereich frei. Wie viel genau man freilassen muss ist nicht in direkten Zahlen festgestellt, sondern wird von Microsoft wie folgt beschrieben:

You need to keep sufficient unallocated disk space available to enable the repairs. Under-provision your storage pool (that is, limit the total capacity that you allocate to all storage spaces in the pool) so that the pool can tolerate multiple disk failures without degraded health. If you’re using storage tiers, keep the total free space in each of the storage pools equivalent to one HDD plus 8 GB (for storage pool and storage spaces overhead) and one SSD plus 8 GB per enclosure. For a space that does not have tiers, under-provision as though you have a single tier.

Quelle: https://technet.microsoft.com/en-us/library/dn782852.aspx

Theoretisch werden nun die physischen Datenträger in dem Pool nicht komplett mit Daten beschrieben, sondern man kann sich visuell vorstellen, dass auf jeder Festplatte noch ein gewisser freier Speicherplatz vorhanden ist. Fällt nun ein Datenträger aus, werden nun von allen restlichen Festplatten die fehlenden Blöcke auf alle anderen Datenträger geschrieben. Dieser Prozess dauert wesentlich kürzer als die Kopie von allen Daten auf eine einzelne Festplatte (der Hot Spare-Datenträger).

In den Standard-Einstellungen kann es vorkommen, dass der Repair-Vorgang bei freiem Speicherplatz innerhalb des Pools eine so hohe Priorität hat und somit so viele I/Os erzeugt, dass für die VMs in diesem Pool kaum noch Ressourcen übrig bleiben. Dies macht sich darin bemerkbar, dass die Performance teilweise extrem stark sinkt.

In kleineren Umgebungen mit 20 – 40 VMs habe ich bisher einen nicht so starken Impact erlebt, in größeren Umgebungen bei mehr als 100 oder mehr als 1000 VMs waren die Auswirkungen deutlich zu spüren. Aus diesem Grund hat Microsoft mit dem Update2 (November-Update 2014) eine Möglichkeit eingebracht, dieses Verhalten ein wenig zu steuern und die Priorität der Wiederherstellung zu senken, damit es nicht mehr zu einer Beeinflussung der Produktiv-Umgebung kommt.

Wie bereits angesprochen, achten Sie auf das installierte Update2. Sie können auf einem Server recht einfach herausfinden, ob dieses installiert ist. Geben Sie einfach in der PowerShell die folgende Zeile ein:

Get-Hotfix | where hotfixID –like KB3000850

tl;dr

Um die Einstellungen zu setzen, müssen Sie ein paar Zeilen PowerShell auf jedem! SOFS Knoten ausführen:

Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters 
     -Name ReallocationsPerInterval 32
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters 
     -Name ReallocationInterval 15
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters 
     -Name RepairQueueDepth 4
Set-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters 
     -Name RepairQueueWidth 8
Get-ClusterResourceType "Storage Pool" | 
Set-ClusterParameter -Name ReEvaluatePlacementTimeout -Value $([uint32]300) –create

Prüfen kann man die Einstellungen mit den folgenden Zeilen:

Get-ItemProperty hklm:\System\CurrentControlSet\Services\Spaceport\Parameters | Select-Object ReallocationsPerInterval,ReallocationInterval,RepairQueueDepth,RepairQueueWidth | Format-List
Get-ClusterResourceType ‘Storage Pool’ | Get-ClusterParameter

Die Ausgabe sollte wie folgt aussehen:

ReallocationsPerInterval : 32
ReallocationInterval     : 15
RepairQueueDepth         : 4
RepairQueueWidth         : 8

Object       Name                       Value Type  
------       ----                       ----- ----  
Storage Pool ReEvaluatePlacementTimeout 300   UInt32

Die Beschreibung von Microsoft zu diesen Werten ist im TechNet zu finden:

https://technet.microsoft.com/en-us/library/dn858079.aspx

P.S. Aktive Repair-Vorgänge können Sie mit dem PowerShell-Befehl

Get-StorageJob

beobachten.

Wir betreiben unsere Hyper-V Schulung mit dem Namen Hyper-V Powerkurs nun schon einige Jahre.

Angefangen haben wir mit Hyper-V unter Windows Server 2008 R2 im Jahr 2011. Seitdem haben wir den Kurs mehrfach erweitert, die großen Änderungen sind natürlich die Updates auf Windows Server 2012 und danach auf Windows Server 2012 R2. Im Laufe der Zeit hat sich selbstverständlich nicht nur der Kurs in Form der Themen geändert, sondern es ist auch neue und erweiterte Hardware hinzugekommen. Angefangen haben wir damals mit acht Schulungssystemen, die ich hier im Blog ja bereits mehrfach beschrieben habe.

Später hinzugekommen sind vier weitere Systeme, somit haben wir aktuell die Möglichkeit unsere Schulung mit bis zu zwölf Teilnehmern bei uns im Hause durchzuführen.

Die Hardware in den Anfängen

Die Rechner hatten von Anfang an einen Vier-Kern-Prozessor, 24 GB Arbeitsspeicher, drei SSDs und sechs 1GbE Ports. Die Anbindung erfolgte per Gigabit Ethernet-Verbindung, als Storage wurde eine NetApp 6040 als iSCSI-Storage genutzt. In diesem Aufbau haben wir im Laufe der fünf Tage mit jeweils zwei oder drei Teilnehmern, je nachdem ob wir eine gerade oder ungerade Anzahl an Teilnehmern hatten, ein Failover Cluster aufgebaut. Jedes Failover Cluster hatte mehrere iSCSI LUNs, die als Quorum und als CSV-Datenträger genutzt wurden.

Weg mit iSCSI, herbei mit SMB3

Mit dem Release von Windows Server 2012 und der Einführung von SMB3 haben wir dann über einen längeren Zeitraum überlegt, in welcher Form wir den Storage für unsere Failover Cluster anbinden. Nach einem Update der NetApp-Firmware war auch die Nutzung von SMB3 möglich, allerdings nicht mit allen Funktionen und Möglichkeiten. Neben dieser Überlegung hatten wir den zusätzlichen Wunsch, dass die Geschwindigkeit im Storage-Netzwerk auf 10 GbE angehoben wird.

Unser Anspruch an den Kurs ist ein möglichst realistisches und optimiertes Szenario zeigen zu können. Da zu diesem Zeitpunkt schon einige Kunden mit 10 Gb/s gearbeitet haben oder eine Migration auf diese Geschwindigkeit andachten, mussten wir an dieser Stelle ebenfalls optimieren. Aus diesem Grund haben wir in jedes der Systeme eine Intel X540-T2 NIC eingebaut. Diese Dual-Port-Karte bietet zwei 10 GbE Ports, somit standen für jeden Rechner eine Bandbreite von 2x 10 Gb/s plus 6x 1 Gb/s zur Verfügung. 

Mit Hilfe von teilweise bis zu 30m langen Cat6a – Kabeln haben wir die PCs dann an zwei 24-Port 10 Gb/s-Switches angebunden. Für alle Rechner zusammen hätte auch eine Switch ausgereicht, dann hätten wir allerdings keine weiteren Systeme (Storage, AD-Controller, Dateiserver) mehr einbinden können. Somit also direkt zwei, so lässt sich auch eine Redundanz über beide Geräte zeigen und konfigurieren. Da 10 GbE-Switches jedoch recht laut sind, wurde ein Teil vom kompletten Schulungsraum abgetrennt und isoliert. Und da wir schon dabei waren, haben wir auch direkt den restlichen Schulungsraum gepimpt. Begonnen bei der Ausstattung mit neuen, eigens für unsere speziellen Bedürfnisse vom Schreiner angepassten Tische. Nun hat jeder Teilnehmer ausreichend Platz zum arbeiten und lernen, jeweils eine Steckdose auf dem Tisch — für das Handyladergerät oder ein Notebook-Netzteil. Zusätzlich hat jeder sein eigenes Schulungssystem (Monitor, Maus und Tastatur, der eigentliche PC steht unterm Tisch). Nachdem wir sowohl unseren Schulungsraum als auch die PCs aufgerüstet haben, war der Storage an der Reihe.

Da wir ja bereits seit Windows Server 2012 auf den Scale-Out File Server setzen war ziemlich schnell klar, dass wir solch einen Aufbau ebenfalls in unsere Schulung aufnehmen. Wir haben zwei Server und ein JBOD mit Festplatten angeschafft; welches nun während des Kurses gemeinsam mit den Teilnehmern direkt ab Neuinstallation eingerichtet und installiert wird.

Nach der Einrichtung, die meist gegen Mitte der Woche stattfindet, wird dieses System für den restlichen Kurs als hochverfügbarer Speicher genutzt. Die Server hatten zum damaligen Zeitpunkt ebenfalls jeweils eine Intel X540-T2 NIC, zwei 1 GbE NICs und einen Quad

-Port-SAS HBA zur Anbindung des JBODs. In dem JBOD befanden sich 15x 1TB große NLSAS Festplatten. Mit diesem Aufbau haben wir schon einige Kurse durchgeführt.

Bereits in der Preview-Phase von Windows Server 2012 R2 haben wir unseren Kurs auf die Version 3 geupdatet und die Neuerungen mit aufgenommen, die gegenüber des ersten Releases eingebracht wurden. Zu diesem Zeitpunkt hat sich an der Ausstattung der PC-Hardware nicht viel geändert (Ein Mainboard ist kaputt gegangen und musste getauscht werden; außerdem haben wir vier 1GbE in Form einer Quad-Port-Karte ausgebaut, da wir diese in unserer aktuellen Konfiguration nicht mehr benötigen); da die Voraussetzungen nahezu die gleichen sind. Was sich allerdings geändert hat, ist die Ausstattung unseres JBODs. Da mit Windows Server 2012 R2 die Mischung von SSDs und HDDs zur Steigerung der Performance eingeführt wurde (Tiering), haben wir unseren Scale-Out File Server um insgesamt fünf 200 GB große SAS SSDs erweitert.

Die Einführung von RDMA

Da wir bereits in der Preview-Phase von Windows Server 2016 sind und vermutlich in den kommenden Monaten unseren Hyper-V Powerkurs auf seine vierte Version updaten, haben wir erneut eine Anpassung der Hardware vorgenommen. Jedes Schulungssystem hat eine weitere NIC bekommen: Eine Dual-Port 10 GbE Netzwerkkarte von Emulex, welche unter Anderem RDMA (Remote Direct Memory Access) beherrscht. Dank dieser Technik haben wir die Möglichkeit Daten zwischen den Hyper-V Hosts und dem Scale-Out File Server performant, mit einer sehr geringen Latenz und ohne eine Belastung der CPU zu übertragen. Diese Eigenschaften machen sich übrigens auch bei einer Migration von VMs zwischen den Hosts positiv bemerkbar.

Für alle, die gerne mehr technische Details zu den Karten haben möchten:

Es handelt sich um die Karte OCE14102-NT von Emulex, der Hersteller listet die Karte hier auf. Die Karte unterstützt RDMA in der RoCE (RDMA over Converged Ethernet) – Variante, weitere hilfreiche Features sind: Unterstützung von dVMQ, VLAN-Support (was übrigens Pflicht bei der Nutzung von RDMA ist), bis zu 512 Hardware Queues, SR-IOV mit bis zu 63 VF (Virtual Functions) und noch einiges mehr. Für uns von Vorteil ist, dass die Karte (so wie die Intel-Karten auch) mit Kupferkabeln verarbeitet sind und wir so die vorhandene Verkabelung nicht austauschen müssen.

Die Karte selbst wird bei der Installation des Windows Server nicht direkt vollständig mit Treibern ausgestattet, sondern es müssen die Emulex-Treiber in der aktuellen Version noch eingespielt werden. Nach der Installation stehen alle Funktionen und Konfigurationsmöglichkeiten zur Verfügung, die Erweiterungen seitens Emulex in den Eigenschaften der Karte machen einen sehr aufgeräumten Eindruck, so dass die gewünschten Einstellungen schnell gefunden werden.

Zukunftssicher auch mit Windows Server 2016

Wir arbeiten bereits in unserer eigenen Test-Umgebung mit der Preview-Version des Windows Server 2016, teilweise haben wir auch schon Präsentationen gehalten (z.B. auf unserem System Center Universe Satellite-Event im Juni haben Carsten und ich über die Neuerungen in WS2016 gesprochen), bei dem die Preview-Version zum Einsatz kam. Sobald wir unseren Kurs auf eine neue Version und somit dem Thema Hyper-V unter Windows Server 2016 aktualisieren, sind unsere Schulungsrechner schon perfekt ausgestattet. Für jeden Rechner stehen insgesamt 42 Gb/s zur Verfügung: 2x 1 Gb/s, 2x 10 Gb/s non-RDMA und 2x 10 Gb/s RDMA.

Mehr Informationen zu unserem Hyper-V Powerkurs gibt es auf unserer neu gestalteten Kurs-Webseite www.powerkurs.net:

Wir betreiben unseren Hyper-V Powerkurs nun schon seit einigen Jahren und haben auch immer mal wieder darüber hier im Blog geschrieben. Angefangen hat alles mit einem Kurs über Hyper-V unter Windows Server 2008 R2. Nach einer Aktualisierung der Inhalte über Windows Server 2012 befinden wir uns aktuell in der dritten Version des Kurses: Hyper-V unter Windows Server 2012 R2. Diesen haben nun schon einige Teilnehmer absolviert, allerdings kam auch immer öfters die Anfrage nach einem Kurs, der die Unterschiede und Verbesserungen der aktuellen Version gegenüber den vorherigen Versionen aufzeigt. Aus diesem Grund haben wir uns entschlossen, einen eigenen Kurs anzubieten, in dem es primär um die Änderungen von Hyper-V zwischen Windows Server 2008 R2 und Windows 2012 gegenüber Hyper-V in der vierten Version geht: Der Hyper-V Powerkurs Refresher!

In einem Zeitraum von drei Tagen werden wir uns gemeinsam die Neuerungen und Verbesserungen anschauen, die eingeflossen sind. Wie auch in unserem Hyper-V Powerkurs können wir Ihnen einiges aus der Praxis erzählen, zusätzlich können Sie das erlernte direkt an und mit eigener Kurs-Hardware anwenden und umsetzen. Pro Teilnehmer steht ein Schulungsrechner mit drei SSDs, sechs Netzwerkkarten mit einer Gesamt-Bandbreite von 42 Gb/s (inkl. zwei RDMA NICs) sowie 24 bzw. 32 GB RAM zur Verfügung.

Der erste Tag beschäftigt sich primär mit den Änderungen zwischen Hyper-V unter Windows Server 2008 R2 gegenüber Windows Server 2012. Hier werden unter anderem die Themen Netzwerk-Teaming, Converged Networking, Shared Nothing Live Migrationen sowie PowerShell behandelt.

An den nächsten beiden Tagen sprechen wir als erstes über das SMB3-Protokoll inkl. aller Möglichkeiten, die diese neue Version bietet. Nach diesem kurzem theoretischen Teil werden wir gemeinsam einen Scale-Out File Server mit einer Kapazität von ca. 15 TB Speicherplatz (verteilt auf HDDs und SSDs) von Grund auf konfigurieren, um diesen im weiteren Verlauf des Kurses als hochverfügbaren Speicher einzusetzen. Wir zeigen Ihnen, was für eine Konfiguration von RDMA-Netzwerkkarten und Switches notwendig ist und welche enormen Vorteile Ihnen diese Technik im täglichen Betrieb bringt. Nach diesem Aufbau werden wir in kleinen Gruppen mehrere Hyper-V Failover Cluster erstellen, die für den hochverfügbaren Betrieb Ihrer VMs genutzt werden. Die optimale Konfiguration dieser Failover Cluster, die Einrichtung von Hyper-V Replica über mehrere Cluster, die Nutzung von Cluster Aware Updating, die Migrationsmöglichkeiten von vorherigen Failover Cluster sowie ein Überblick über Backup-Möglichkeiten runden den dritten Tag ab.

Dieser Kurs richtet sich nicht nur an Besucher von unserem Hyper-V Powerkurs. Wenn Sie ein fundiertes Grundwissen im Betrieb von Hyper-V unter Windows Server 2008 oder Windows Server 2008 R2 haben, ist dieser Kurs ebenfalls für Sie geeignet. Falls Sie noch keinen Umgang mit Hyper-V hatten und erst damit beginnen oder vor kurzem begonnen haben sollten Sie unseren Hyper-V Powerkurs besuchen.

Weitere Informationen, die Termine und eine Möglichkeit zur Anmeldung finden Sie auf unserer neuen Webseite, die wir exklusiv für unsere Schulungsangebote neu erstellt haben: www.PowerKurs.net

Wir stoßen bei unserer Arbeit immer wieder auf die Situation, dass der Kunde bereits ein Hyper-V Failover Cluster und einen Scale-Out Files Server im Einsatz hat und diese beiden Systeme jetzt über den Virtual Machine Manager 2012 R2 verwalten möchte. Daher habe ich mich mit der Frage beschäftigt, welche Voraussetzungen  notwendig sind, um einen bereits existierenden Scale-Out File Server (SOFS) im Virtual Machine Manager 2012 R2 hinzuzufügen und was dabei zu beachten ist.

Hier die Voraussetzungen, die bei uns in der Labor- und Produktivumgebung notwendig waren.

1. Wir benötigen einen Domain Account der als RunAsAccount im Virtual Machine Manager 2012 R2 angelegt wird – er heißt z.b. SVMM-Admin. Es reichen hierfür die normalen Domain-Benutzer Berechtigungen im Active Directory aus.
   
2. Dieser SCVMM-Admin darf nicht mit dem Service Account für den “System Center Virtual Machine Manager” Dienst identisch sein.
   
3. Der SCVMM-Admin muss auf allen Hyper-V Hosts und auf allen Scale-Out File Server Knoten lokaler Administrator sein.
   
4. Mit dem RunAsAccount des SCVMM-Admin muss das Hyper-V Failovercluster in den Virtual Machine Manager 2012 R2 hinzugefügt werden.
   
5. Bei den SOFS-Freigaben müssen alle Hyper-V Hosts + das Hyper-V Clusterkonto einzeln (Gruppenberechtigungen funktionieren an dieser Stelle nicht) mit Vollzugriffsrechten berechtigt sein und auch der SCVMM-Admin benötigt Vollzugriffsrechte auf die SOFS-Freigaben.
   
6. Die SMB Netze des Scale-Out File Servers sollten sie nicht in den DNS eintragen, da es sonst im Virtual Machine Manager 2012 R2 zu Problemen mit der Namesauflösung kommt.
   

Sind diese Voraussetzungen alle gegeben, können wir das Scale-Out File Server Cluster im Virtual Machine Manager 2012 R2 hinzufügen.

Dies kann über “Add Resources” oder aber  unter “Fabric” “Storage” Rechtsklick “Add Storage Devices” erfolgen.

Hier wählen wir “Windows-based file Server” aus

An dieser Stelle wird der FQDN des Scale-Out File Server Clusters eingegeben und der RunAsAccount ausgewählt, mit dem auch der Hyper-V Failover Cluster in den SCVMM hinzugefügt worden ist. In unsrem Fall der SCVMM-Admin.

Für den Pool müssen wir eine Storage Classification angeben – diese können wir unter “Create classification” erstellen.

Es werden nur SOFS-Freigaben vom Virtual Machine Manager 2012 R2 verwaltet, wenn diese beim Hinzufügen auch ausgewählt werden. ACHTUNG!!! beim Entfernen des SOFS aus dem Virtual Machine Manager 2012 R2 – löscht der VMM bei allen verwalteten SOFS-Freigaben die Freigabe. Wenn dies nicht gewünscht ist, muss in den Eigenschaften jeder verwalteten SOFS-Freigabe der Hacken bei

entfernt werden.

Umgekehrt gilt, wenn Sie am SOFS weitere Applikationsfreigaben anlegen, werden diese nicht automatisch vom Virtual Machine Manager 2012 R2 verwaltet. Sondern erst, wenn in den Eigenschaften der Freigabe der Hacken bei “File share managed by Virtual Machine Manager” gesetzt wird. Erst dann kann diese SOFS-Freigabe auch dem Hyper-V Failover Cluster und jedem anderen Hyper-V Host zugeordnet werden.
Hier können Sie überprüfen welche SOFS-Freigabe durch den Virtual Machine Manager 2012 R2 verwaltet wird.

Jetzt kann den Hyper-V Hosts das Storage zugewiesen werden.
Handelt es sich hierbei um ein Hyper-V Failover Cluster, erfolgt dies in den Eigenschaften des Failover Clusters.
Bei den einzelnen Cluster Hosts ist die Möglichkeit unter Storage den File Share hinzu zufügen ausgegraut

Wir wählen also in den Hyper-V Failovercluster Eigenschaften “File Share Storage” aus und fügen die gewünschten SOFS-Freigaben hinzu. Es werden an dieser Stelle nur die SOFS-Freigaben angezeigt, die auch durch den VMM verwaltet werden!

Soll einem einzelnen Hyper-V Host die SOFS-Freigabe zur Verfügung gestellt werden, so rufen Sie die Eigenschaften am Hyper-V Host auf und wählen “Storage” aus.

Hier kann über “Add” “Add File Share” aufgerufen werden. Jetzt kann rechts der Freigabe Pfad ausgewählt werden, mit “OK” bestätigen und schon steht auch diesem Hyper-V Host der Speicherplatz zur Verfügung – Voraussetzung hierfür ist, dass dieser Hyper-V Host im SBM Netz ist.

Wenn alles erfolgreich war, werden in den Hyper-V Failover Cluster Properties unter File Share Storage die Fileshares angezeigt

und auch an jedem Hyper-V Cluster Knoten unter Properties\Storage – File Shares.

Hier noch als Ergänzung die Powershell Befehle, mit denen eine SOFS-Freigabe als verwaltete Freigabe im Virtual Machine Manager 2012 R2 hinzugefügt werden kann.

$FileServer = Get-SCStorageFileServer -Name “FileServer01.Contoso.com”
$FileShare = Get-SCStorageFileShare -Name “FileShare01″
Set-SCStorageFileServer -StorageFileServer $FileServer -AddStorageFileShareToManagement $FileShare

Und wenn SOFS-Freigaben im Virtual Machine Manager nicht mehr verwaltet werden sollen, dann können folgende Powershell Kommandos abgesetzt werden.

$FileServer = Get-SCStorageFileServer -Name “FileServer01.Contoso.com”
$FileShare = Get-SCStorageFileShare -Name “FileShare01″
Set-SCStorageFileServer -StorageFileServer $FileServer -RemoveStorageFileShareFromManagement $FileShare

Quelle: Set-SCStorageFileServer

In einem aktuellen Projekt bin ich dabei, einen Scale-Out File Server aufzubauen. Dieses Mal werden als Speicher keine JBODs mit Festplatten und SSDs genutzt; im Hintergrund steht stattdessen ein per Fibre Channel angeschlossenes SAN. Bisher wurden die LUNs im Hyper-V Failover Cluster direkt an alle zwölf Hyper-V Hosts angebunden, dies bedingt jeweils FC-Adapter in den Hosts. In dem aktuellen Projekt werden zwischen die Hypervisor und dem SAN zwei Server gebaut, die eine hochverfügbare Dateiserver-Rolle im Failover Cluster betreiben (ein Scale-Out File Server, kurz SOFS).

Um das Thema dieses Beitrags zu erklären, muss ich etwas weiter ausholen.

Wird ein Scale-Out File Server betrieben, existiert zwischen den Hyper-V Hosts oder dem Hyper-V Cluster und dem SOFS Cluster eine Verbindung über eine, oder besser, mehrere SMB3-Verbindungen. Häufig werden hier zwei 10 GbE Karten pro Server genutzt, teilweise kommen aber auch Karten mit 40 bzw. 56 Gb/s oder höher zum Einsatz. Alle Daten der VMs werden in einem oder mehreren Shares gespeichert, die von dem SOFS Cluster zur Verfügung gestellt werden. Die SOFS-Rolle steht im Netzwerk unter einem Namen und mehreren IP-Adressen zur Verfügung. Häufig heißt die Rolle einfach nur SOFS.domain.local, die IP-Adressen sind hierbei die der Cluster-Knoten.

Baut ein Hypervisor nun eine Verbindung zu seinem Storage auf, erfolgt eine Auflösung des Namens und eine Verbindung zu einer IP-Adresse. Welche IP-Adresse genutzt wird kann nicht bestimmt werden, da DNS Round Robin genutzt wird.

An dieser Stelle gibt es zwei Möglichkeiten:

1. Es kommen JBODs mit HDDs und ggf. SSDs zum Einsatz, die mit Hilfe der Storage Spaces zu einem Pool zusammengefasst werden. Aus diesem Pool werden dann vDisks erstellt, die wiederum im SOFS Cluster als Cluster Shared Volume-Datenträger genutzt werden. Auf diesen Datenträgern werden die Daten gespeichert.
2. Es kommt ein oder mehrere SAN-Systeme zum Einsatz. Dieser Blockstorage wird per iSCSI oder Fibre Channel an die SOFS Knoten angebunden, die LUNs werden als Cluster Shared Volume genutzt und die Daten werden auf diesen Datenträgern gespeichert.

In beiden Fällen gibt es für jeden Datenträger einen Besitzer. Dieser Besitzer kann wechseln. Standardmäßig pendelt Windows Server 2012 R2 die Datenträger jedoch aus, so dass (wenn möglich) auf jedem Server mindestens ein Datenträger zur Verfügung steht und dieser der Besitzer des Datenträgers ist. Werden im SOFS Cluster zwei Knoten betrieben, sollten auch mindestens zwei Datenträger genutzt werden, alternativ das Mehrfache der Anzahl der Knoten (vier, sechs, acht, usw.).

Die SMB-Clients, also unsere Hyper-V Hosts, verhalten sich bei den beiden oben angesprochenen Typen von CSVs/Freigaben anders. Schauen wir uns die beiden Möglichkeiten einmal an:

1. Da wir in dem ersten Beispiel Storage Spaces nutzen, erfolgt eine Verbindung auf die vDisks nur über den Besitzer der entsprechenden Disk. Dies bedeutet, dass alle anderen SOFS Knoten im Failover Cluster keinen direkten Zugriff auf die vDisk haben und bei entsprechendem Bedarf die Daten über den Besitzer schicken. Wenn Sie jetzt denken “Hoppla, das hört sich aber nach einem umgeleiteten Modus (Redirected Mode) an”: Ja, das ist so, kommt allerdings praktisch fast nie vor. Dies liegt daran, dass die SMB Clients (in Form unserer Hyper-V Hosts) ab Windows Server 2012 R2 immer zu dem Server eine Verbindung aufbauen, der Besitzer der vDisk ist. Bietet nun SOFS Knoten A einen Share an, der auf vDisk A gespeichert ist, werden alle Verbindungen zu dieser Freigabe über den SOFS Knoten A abgewickelt. Eine Verbindung zu Share B auf SOFS Knoten B läuft über Knoten B usw.
   Wird nun die vDisk A von SOFS Knoten A auf Knoten B verschoben, werden ebenfalls die Verbindungen der SMB Clients auf Knoten B geschwenkt. Dieses Verhalten stellt sich, dass kein großer SMB Traffic zwischen den SOFS Knoten herrscht. Je nach Anbindung würde dies die Kommunikation verlangsamen.
   
2. Im zweiten Fall, nämlich der Anbindung von LUNs an einen Scale-Out File Server, verhält sich alles etwas anders. Grundsätzlicher Unterschied von LUNs gegenüber vDisks: LUNs können von allen SOFS Knoten gleichzeitig genutzt werden, d.h. alle Server können gleichzeitig auf den Datenträger zugreifen. Das Cluster Shared Volume File System, kurz CSVFS, sorgt während dieser gleichzeitigen Nutzung dafür, dass es keine defekten Daten durch gleichzeitigen Zugriff gibt.
   Dieser technische Unterschied kann dazu führen, dass die SMB Clients auf einen Share zugreifen über Server A, während die LUN aber momentan von Server B verwaltet wird (Server B ist der momentane Besitzer). Die Daten laufen in diesem Fall von Hyper-V Host zu SOFS Knoten A und von dort direkt auf die LUN. Es erfolgt kein Redirect über den SOFS Knoten B als Besitzer der LUN.
   

Wir gehen nun weiter auf die zweite Variante ein, da dies in dem Kundenprojekt genau so der Fall war:

Auf dem SAN gab es zu Demo-Zwecken zwei LUNs, zwei SOFS Knoten, zwei Freigaben (jeweils eine auf einer LUN) und zwei Hyper-V Hosts. Nach dem Aufbau des SOFS Cluster wurden die ersten Hyper-V Benchmark-VMs verteilt, um ein bisschen Last zu erzeugen. Jeder Hyper-V Host hat 40 VMs bekommen, die immer im Wechsel auf die beiden Shares des SOFS verteilt wurden. Nach dem Start der VMs und dem Beginn der SQLIO-Worker zeigten beide SOFS Knoten eine Bandbreite zwischen 4 und 5 Gb/s auf den vier 10 GbE NICs. Alles lief gut, es erfolgte die gewünschte Verteilung der Bandbreite auf beide SOFS Knoten und die VMs haben auf dem SAN ordentlich IOPS erzeugt.

Nun wurde zu Testzwecken einer der beiden SOFS Knoten stromlos gemacht, um einen Ausfall zu simulieren. Kurz nach dem Ausfall gab es einen kleinen Freeze der IOPS auf den beiden Shares – gefühlt eine Sekunde, danach ging es direkt weiter. Auf dem zweiten SOFS Knoten lagen nun auf allen 10 GbE NICs knapp 9 Gb/s an. Auch hier lief Alles wie gewünscht. Der überlebende SOFS Knoten war Besitzer der Rolle und aller Datenträger.

Nun wurde der zweite Knoten wieder eingeschaltet, bootete, meldete sich wieder am Failover Cluster an und durch den Ausgleich der Datenträger war er kurze Zeit später auch wieder der Besitzer von einem der beiden CSV Datenträger. Was zu diesem Zeitpunkt auffällig war: Die Daten der VMs gingen komplett über den Knoten, der nicht stromlos gemacht wurde. Auch ein mehrfacher Wechsel des Besitzers änderte nichts an dem Verhalten, der zweite SOFS Knoten schien nicht genutzt zu werden.

Technisch liegt dies daran, dass ein Wechsel der Verbindung (in diesem Szenario mit LUNs) von Hyper-V zu SOFS Knoten nicht notwendig ist. Egal wer Besitzer der LUN bzw. des CSV-Datenträgers ist, alle Server können direkt zugreifen. Trotz der nicht vorhandenen Notwendigkeit wäre es natürlich trotzdem schön, wenn sich die Last der Verbindungen auf die SOFS Knoten aufteilen würde. Das kann über mehrere Wege manuell erreicht werden:

• Ein Reboot der Hyper-V Hosts
  Diese Variante ist eher unschön, da ein Reboot eines oder mehrerer Hyper-V Hosts recht lange dauert und auch gar nicht notwendig ist, wenn man die zweite Möglichkeit kennt. Bei einem Reboot und dem erneuten Beitritt zum Failover Cluster macht der Hypervisor erneut einen Aufruf des SOFS-DNS-Namens. In diesem Fall kann es sein (muss aber nicht), dass er durch das DNS Round Robin eine Adresse nutzt, die dem zweiten und bisher ungenutzten SOFS Knoten gehört. Ab diesem Moment konnten wir beobachten, dass die Verbindungen und Daten sich wieder über beide SOFS Knoten verteilen. Dies kann so sein, muss aber nicht zwingend.
• Die Ausbalancierung der Verbindungen per PowerShell
  Die zweite Möglichkeit, um einen Ausgleich der Verbindungen hinzubekommen, ist die Verwendung von PowerShell. Diese Variante funktioniert erfahrungsgemäß sehr gut und kann sogar im laufenden Betrieb durchgeführt werden. Somit sparen Sie sich einen Neustart der Hosts und das “Glücksspiel”, ob die Verbindungen danach wirklich wieder aufgeteilt werden.

Sie können sich die Verbindungen, die auf den Scale-Out File Server aufgebaut werden, mit dem Befehl

Get-SmbWitnessClient

auf den SOFS Knoten anschauen. Als Ausgabe erhalten Sie eine Auflistung der Server, die eine Verbindung aufgebaut haben. Zusätzlich sehen Sie, wohin diese Verbindung aufgebaut wurde.

Diese Verteilung können Sie bei Bedarf auch manuell umsetzen, indem Sie folgenden Befehl benutzen

Move-SmbWitnessClient -ClientName Hyperv11 -DestinationNode FSNode2

Das Resultat sieht wie folgt aus:

Diesen Vorgang müssen Sie natürlich nicht bei jedem Neustart der SOFS Knoten (z.B. bei dem Update der Systeme) manuell durchführen. Sie können ein Skript verwenden, welches Jose Barreto geschrieben und in seinem Blog veröffentlicht hat: File Server Tip: How to rebalance a Scale-Out File Server using a little PowerShell

Dieses kleine Skript sorgt für eine automatische Verteilung im SOFS Cluster. Wenn Sie das Skript speichern und z.B. einmal täglich ausführen lassen können Sie sicher sein, dass Ihr SOFS Cluster nach spätestens 24 Stunden wieder mit allen Systemen aktiv betrieben wird.

Diesen Sonntag, 20. März 2016, endet die Möglichkeit, Karten für unsere erste eigene Konferenz vergünstigt zu bekommen. Wie ihr bestimmt mitbekommen habt, veranstalten wir am 12. Mai in Düsseldorf die “Cloud & Datacenter Management Germany” Konferenz, kurz CDC. Bis Sonntag gibt es hier die Möglichkeit, vergünstigt eine oder mehrere Eintrittskarten zu erwerben. Die Nachfrage ist aktuell schon ziemlich groß, lassen Sie sich diese einmalige Chance in diesem Jahr nicht entgehen. Wir haben eine große Anzahl hochkarätiger Sprecher eingeladen, die diesen Tag gemeinsam mit uns zu einem ganz besonderen Highlight machen werden.

Weitere Informationen zu den Sprechern, den Themen und dem Ablauf finden Sie unter CDC-Germany.de

Wir haben bei unserem Scale Out Fileserver (SOFS) vor kurzem einen Tausch der Server-Hardware durchgeführt. Die alten Systeme werden in Zukunft für unseren Hyper-V PowerKurs genutzt, daher wurden für das Produktivsystem zwei neue Server sowie neue SAS-HBAs angeschafft. Nach einer kurzen Überlegung haben wir festgestellt, dass ein Tausch der Hardware auch im Betrieb möglich sein sollte. Um dies zu verifizieren habe ich den Vorgang dann auch in der Praxis durchgeführt und nachgeschaut, ob dies wirklich so einfach und zuverlässig funktioniert.

Grundsätzlich besteht das Failovercluster zur Bereitstellung der Dateiserver-Rolle aus zwei Knoten, die mit jeweils zwei SAS-Kabeln an einem DataOn-JBOD angeschlossen sind. In diesem JBOD stecken sowohl SAS-HDDs als auch SAS-SSDs, diese werden zur Speicherung unserer produktiven VMs genutzt.

Begonnen habe ich mit der Installation von einem der beiden neuen Knoten. Nach dem Update-Vorgang und der Treiber-Installation von SAS-HBA und 10GBit-Karte wurde der Server in das Rack gehängt, aber noch nicht mit dem JBOD verbunden. Im Failovercluster (mit der Dateiserver-Rolle, es geht hier grundsätzlich nicht um das Hyper-V Failovercluster) habe ich nun einen der beiden Produktiv-Systeme in den Wartungsmodus versetzt und überprüft, ob ein Zugriff über den zweiten Knoten noch möglich ist. Nachdem ich dies verifiziert habe, konnte der inaktive Knoten komplett aus dem Failovercluster entfernt und heruntergefahren werden. Zu diesem Zeitpunkt bestand das SOFS-Konstrukt nur aus einem Server. Anschließend wurden die SAS-Kabel des ausgeschalteten Servers entfernt und gleichzeitig wurde der dritte, neu installierte Server angeschlossen. Bevor der neue Server nun hinzugefügt wurde, habe ich den Cluster-Validierungsassistent gestartet um zu überprüfen, ob die Konfiguration in Ordnung ist. Die Überprüfung lief ohne Fehler durch. Es wurden zwar diverse Warnungen angezeigt; diese konnten jedoch alle ignoriert werden (unterschiedliche CPUs, unterschiedlicher Patchlevel usw.). Nachdem nun der dritte Server Mitglied des SOFS war, wurde der zweite ältere Server in den Wartungsmodus versetzt, aus dem Failovercluster und vom JBOD entfernt. Nun wurde der zweite neue Server mit dem JBOD verbunden und nach einem erneuten Test zum Failovercluster hinzugefügt. Die Migration war an dieser Stelle abgeschlossen, der komplette Vorgang lief fehler- und ausfallfrei durch. Ich habe letztlich noch überprüft, ob die beiden CSV-Datenträger an jeden der beiden neuen Server verschoben werden konnten und ob bei einer gleichmäßigen Verteilung über beide Server Daten laufen. Dies war der Fall, seitdem laufen die Systeme problemlos und verrichten ihre Aufgabe.

Ich befinde mich aktuell in München bei einem unserer Kunden, hier haben wir diese Schritte erneut durchgeführt, um die SOFS-Knoten zu tauschen. Hier gab es ebenfalls keine Probleme oder Ausfälle.

Der Beitrag Austausch von Scale Out Fileserver-Knoten im Betrieb erschien zuerst auf Hyper-V Server Blog.

Dieser Artikel behandelt die Installation eines Failover Cluster unter Windows Server 2012 R2, welches zur Ausführung von Hyper-V VMs genutzt wird. Gegenüber den vorherigen Artikeln zur Einrichtung unter Windows Server 2008 R2 und Windows Server 2012 hat sich teilweise etwas geändert, das “Grundrauschen” ist allerdings gleich geblieben. Die größte Änderung liegt darin, dass durch unterschiedliche Techniken die Anzahl der Möglichkeiten enorm gestiegen sind. Dadurch gibt es nicht mehr “die eine” optimale Lösung, es muss nun anhand der jeweiligen Hardware entschieden werden, was die beste Lösung in diesem einen Fall ist. Zusätzlich habe ich an einigen Stellen noch die genutzten PowerShell-Befehle mit aufgeführt. Diese hier beschriebene Konfiguration eignet sich primär bei der Nutzung eines Scale-Out File Servers. Dieser ist bereits eingerichtet und in diesem Artikel wird nicht auf die Einrichtung eingegangen, dies wird komplett im zweiten Teil der Serie gemacht.

Egal was Sie einsetzen möchten, was Sie bereits haben oder wo Sie ansetzen: Sprechen Sie uns an, wir können diese Konfiguration gerne an Ihre Bedürfnisse anpassen.

Die genutzte Hardware

Die Demoumgebung

Die hier genutzte Hardware sind zwei Rechner aus unserem Hyper-V Powerkurs und einem Scale-Out Fileserver unter Windows Server 2012 R2 als SMB3-Ziel. Die Rechner besitzen zwei 1Gbit NICs und vier 10Gbit NICs, 24 GB RAM und eine Quadcore-CPU. Beide Server sind Mitglied der Active Directory powerkurs.local. Der Scale-Out File Server hat jeweils zwei 10Gbit-Ports für SMB3 und zwei 1Gbit-Ports zur Anbindung an die Active Directory pro Knoten.

Ein paar Worte zu der Hardware, den Verbesserungs- und den Sparmöglichkeiten

Diese hier beschriebene Konfiguration entsprecht von den Eckdaten her dem, was wir empfehlen und was wir bereits in Projekten mehrfach erfolgreich eingesetzt haben. Natürlich sollte als Server ein wirklicher Server zum Einsatz kommen, der für den 24/7-Betrieb geeignet ist. Von einer Nutzung von PCs oder Workstations ist natürlich absolut abzuraten, wegen der Verfügbarkeit habe ich diese Systeme aber als Demoumgebung genutzt.

Wir geben Ihnen als Empfehlung zwei 10Gbit-Adapter mit jeweils zwei Ports vor, d.h. jeder Hyper-V Host ist mit 40 Gbit angebunden, hinzu kommen noch zwei oder mehr 1 Gbit-Adapter. Diese Anbindung könnte theoretisch noch erhöht werden auf sechs 10 Gbit-Adapter, prinzipiell spricht hier nichts gegen. Dies bewirkt eine Erhöhung der Gesamtbandbreite, ändert aber nichts an der Performance der einzelnen Adapter. Hier kommen RDMA bzw. SMB Direct-Karten ins Spiel. Mit Hilfe dieser Technik können Sie eine deutliche Steigerung der Performance bei sehr geringer Latenz erreichen. Wenn alle Netzwerk-Komponenten diese Technik beherrschen haben Sie eine enorm hohe Bandbreite zwischen Hyper-V Failover Cluster und Scale-Out File Server. Informationen zu dem Thema gibt es unter anderem im Hyper-V Podcast Folge 35 von meinem Kollegen Carsten Rachfahl.

Wenn Sie nicht den Bedarf von 40 Gbit pro Knoten haben oder die Hardware bereits vorhanden ist, können Sie den Betrieb auch mit einer 10 Gbit DualPort-Karte realisieren. In diesem Fall wären die VMs mit zwei oder mehr 1 Gbit-Karten angebunden, die 20 Gbit ständen dann exklusiv für die Anbindung an den Storage zur Verfügung.

Die Installation und Einrichtung des Betriebssystems

Die Einrichtung beginnt mit einer frischen Installation eines Windows Server 2012 R2 in der Datacenter Edition auf beiden Hosts. Nach der Grundinstallation werden die Netzwerkkarten umbenannt und teilweise zu einem Team konfiguriert.

Beide 1Gbit-Adapter werden zu einem Team zusammengefasst, zusätzlich werden zwei 10Gbit-Adapter (jeweils auf einem der beiden Adapter) zu einem Team zusammengefasst. Das 2Gbit-Team wird als Management-Netzwerk genutzt, das 20Gbit-Team wird zur Anbindung der VMs an das Netzwerk genutzt. Insgesamt existieren vier Netzwerke, auf drei der Karten hat der Host eine eigene IP-Adresse. Das VM-Netzwerk wird exklusiv für die virtuellen Computer genutzt.

Die Konfiguration per PowerShell wäre wie folgt:

New-NetLBFOTeam -Name “Management-Team” -TeamNICName “Management-Team” -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

New-NetLBFOTeam -Name “VM-Team” -TeamNICName “VM-Team” -TeamMembers 10GBit#1, 10GBit#3 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Die Karte Management-Team wird mit einer IP-Adresse im Bereich 192.168.209.0/24 konfiguriert. In meinem Fall arbeite ich mit den Systemen Hyperv10 und Hyperv15, daher bekommt Hyperv10 die Adresse 192.168.209.10 und Hyperv15 die Adresse 192.168.209.15. Die Endadresse bleibt in allen Netzen gleich, so kann eine eindeutige Zuordnung erfolgen. Eine gleichmäßige Zuweisung von Adressen sowie eine durchgängige Benamung machen den Betrieb und die Administration an vielen Stellen einfacher. Die Karte VM-Team wird zu diesem Zeitpunkt nicht konfiguriert, sie wird später als Hyper-V Netzwerk genutzt. Bei der Wahl der Adapter wird jeweils ein Adapter pro Hardware-Karte gewählt, dies ermöglicht einen Betrieb auch dann, wenn einer der beiden Hardware-Karten ausfallen würde. Die Bindungen der Karte werden nicht geändert und sehen wie folgt aus:

Die beiden 10Gbit-Adapter, die nicht Mitglied des Teams sind, werden mit einer IP-Adresse aus den Storage-Bereichen versehen. Hierbei achten wir ebenfalls darauf, dass die End-Adresse jeweils identisch ist mit der Adresse im Management-Netz. Nach der korrekten Konfiguration sehen die Eigenschaften der Karten wie folgt aus:

Unter IP-Einstellungen werden keine Änderungen vorgenommen, die Einstellungen der Karte 10GBit#2 (die zweite Storage-Karte) sind bis auf die IP-Adresse identisch.

Die Konfiguration per PowerShell:

Set-NetIPInterface -InterfaceAlias “10GBit#2” -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias “10GBit#2” -IPAddress 192.168.208.10
Set-DnsClientServerAddress -InterfaceAlias “10GBit#2” -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name “10GBit#2” -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias “10GBit#2” -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias “10GBit#4” -IPAddress 192.168.207.10
Set-DnsClientServerAddress -InterfaceAlias “10GBit#4” -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name “10GBit#2” -ComponentID ms_tcpip6 -Enabled $False

Beide Server werden nun auf den aktuellen Patchlevel geupdatet.

Nach der Installation und dem anschließenden Neustart kann die Einrichtung mit der Installation der Hyper-V Rolle fortgesetzt werden.

Über den Server-Manager oder per PowerShell kann nun die Hyper-V Rolle installiert werden. Bei der während der Installation durchgeführten Konfiguration wählen wir keine der Karten für das Hyper-V Netzwerk aus, dies wird im späteren Verlauf manuell konfiguriert. Die Livemigration wird nicht konfiguriert, bei der Wahl der Pfade wird ebenfalls an dieser Stelle keine Änderung vorgenommen. Das System startet nun zwei Mal durch und steht danach wieder zur Verfügung.

Alternativ kann die Installation natürlich auch per PowerShell gemacht werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart

Wenn der Parameter –ComputerName noch mit angegeben wird können sogar alle Server fast gleichzeitig installiert werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart -ComputerName Hyperv10

Die Einrichtung von Hyper-V zur Vorbereitung auf den Betrieb als Failover Cluster-Knoten

Nach der Installation von Hyper-V müssen noch ein paar lokale Einstellungen vorgenommen werden, bevor das Failover Cluster eingerichtet werden kann. Im Hyper-V-Manager werden auf beiden Systemen unter dem Manager für virtuelle Switches eine neue externe Switch erstellt und auf den VM-Team-Adapter gebunden. Achten Sie darauf, den korrekten Adapter auszuwählen.

Wie Sie die virtuelle Switch nennen ist Ihnen überlassen, wichtig ist das sie auf allen Hyper-V Hosts gleich heißt. Achten Sie zusätzlich unbedingt darauf, nicht die gemeinsame Verwendung zu aktivieren. Bei Nutzung der gemeinsamen Verwendung bekommt der Host eine weitere, virtuelle Netzwerkkarte, die nicht benötigt und nicht gewollt ist. Der PowerShell-Befehl hierzu ist:

New-VMSwitch -Name “VM” -NetAdapterName VM -AllowManagementOS 0 -ComputerName Hyperv10

Danach kann Hyperv10 durch den Namen des zweiten Knoten ersetzt werden.

Die Installation und Einrichtung des Failover Cluster

Nachdem nun die Vorbereitungen abgeschlossen sind können wir mit der Installation und Einrichtung des Failover Cluster beginnen.

Die Installation der benötigten Features

Für die Einrichtung eines Failover Cluster wird das Feature Failoverclustering benötigt

Wenn Sie das System lokal administrieren möchten oder müssen sollten Sie die Failovercluster-Verwaltungstools sowie das Failoverclustermodul für Windows PowerShell ebenfalls installieren

Per PowerShell:

Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –IncludeManagementTools -ComputerName Hyperv10

Die Einrichtung des Failover Cluster

Nach der Installation öffnen Sie den Failovercluster-Manager und beginnen mit dem Menüpunkt Konfiguration überprüfen….

Im Assistenten fügen Sie die Server hinzu, die überprüft werden sollen (Tipp: das lokale System kann mit einem Punkt ( . ) oder “localhost” hinzugefügt werden)

Danach können Sie auswählen, welche Tests durchgeführt werden sollen. Falls dies der erste Durchlauf ist sollten Sie unbedingt alle Tests auswählen, falls Sie nur einen oder mehrere spezielle Tests durchführen möchten (z.B. bei einem erneuten Durchlauf) können Sie diese manuell auswählen.

Es werden nun alle Tests durchgeführt, dies dauert je nach Anzahl der Server.

Nach dem Durchlauf erhalten Sie eine Übersicht der Tests und haben die Möglichkeit, sich den kompletten Bericht anzeigen zu lassen.

Schauen Sie sich unbedingt die Warnungen und Fehler an. Je nach Art der Fehler können diese entweder ignoriert werden oder sie müssen aktiv korrigiert werden. In meinem Fall steckte ein Kabel in einem falschen VLAN, wodurch die folgende Meldung in dem Bericht auftaucht:

Solche Fehler werden meist durch den Assistenten erkannt und angemerkt, eine Behebung vor der Erstellung und Nutzung des Failover Cluster macht deutlich mehr Spaß als die nachträgliche Suche.

Andere Warnungen können ggf. ignoriert werden, z.B. ein fehlender Datenträger oder eine permanente SCSI-3-Reservierung. Da wir mit SMB3-Shares arbeiten sind keine Datenträger im Failover Cluster vorhanden.

Wenn keine Fehler während der Überprüfung auftauchen aktiviert der Assistent direkt die Möglichkeit, den Failover Cluster mit den überprüften Knoten zu erstellen

Während der Erstellung werden wir nach dem Namen des Failover Cluster und der IP-Adresse gefragt, unter der eine Administration möglich ist. Die Frage nach dem Netzwerk erscheint nur, weil keine der Netzwerkkarten ein Gateway eingetragen hat. Sobald ein Gateway vorhanden ist wird automatisch dieses Netzwerk als Zugriffspunkt definiert.

Wir benötigen in unserem Fall eine IP-Adresse im Netzwerk 192.168.209.0/24 und einen eindeutigen Namen

Nach einem Klick auf Weiter wird überprüft, ob Name und IP-Adresse bereits vorhanden bzw. belegt sind, falls dies nicht der Fall ist erscheint eine Übersicht über die getätigten Einstellungen.

Die Option Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden bewirkt an dieser Stelle keine Änderung, da keine Datenträger hinzugefügt wurden. Wir haben uns angewöhnt diese Option grundsätzlich zu deaktivieren, da wir den Speicher manuell zuweisen wollen. Nach einem Klick auf Weiter wird der Cluster erstellt, danach verbindet sich der Failovercluster-Manager automatisch mit dem gerade erstellten Cluster. In der Zusammenfassung bekommen wir noch einen Hinweis angezeigt, dass kein geeigneter Datenträgerzeuge vorhanden ist. Um diese Einstellungen kümmern wir uns später.

Die Konfiguration des Netzwerks

Die ersten Anpassungen im gerade erstellten Cluster werden im Netzwerk gemacht. Die Netze werden automatisch durchnummeriert, diese Namen ändern wir auf die Funktion des einzelnen Netzwerks.

Um welches Netz es sich handelt können Sie sehen, wenn Sie auf das Netzwerk klicken und im unteren Teil auf den Reiter Netzwerkverbindungen wechseln.

Das Ergebnis sind drei vollständig benannte Netzwerke. Die Eigenschaften der Karten sehen wie folgt aus:

In den Einstellungen für Livemigration muss nun die Reihenfolge der Netzwerke definiert werden, über die eine Livemigration gemacht wird.

Hier werden die beiden Storage-Karten als primäre Karten definiert und in der Reihenfolge nach oben geschoben, falls dies nicht automatisch der Fall ist. Der Adapter Management bleibt ebenfalls aktiviert, wird aber ganz nach unten verschoben.

Als nächstes muss die Metrik der Netzwerke im Failover Cluster definiert werden. Die Metrik bestimmt, über welches Netzwerk die Daten während eines umgeleiteten Modus zwischen den einzelnen Knoten laufen. Diese Einstellung kann ausschließlich per PowerShell ausgelesen und gesetzt werden, eine Administration per GUI ist nicht möglich. Öffnen Sie eine administrative PowerShell oder die PowerShell ISE und nutzen Sie die folgenden Befehle zum Auslesen und manuellen Setzen der Werte.

Get-ClusterNetwork | ft Name, Metric, AutoMetric

Je kleiner die Metrik, desto höher ist die Priorität. Standardmäßig wird in dem oberen Screenshot das Netzwerk Storage2 genutzt, da die Metrik 30240 die kleinste der drei ist. Grundsätzlich ist diese Reihenfolge (Erst Storage2, dann Storage1 und dann Management) in Ordnung, wir möchten aber gerne die Prioritäten manuell auf die folgenden Werte setzen:

Die entsprechenden Befehle dazu sind

(Get-ClusterNetwork "Storage1").Metric = 100
(Get-ClusterNetwork "Storage2").Metric = 101
(Get-ClusterNetwork "Management").Metric = 110

Diese Einstellungen müssen nur auf einem der Knoten gemacht werden, da hier clusterweite Einstellungen verändert und konfiguriert werden.

Die folgende Einstellung muss auf jedem Cluster-Knoten gesetzt werden, da es sich um eine lokale Einstellung handelt. Wechseln Sie in die Netzwerkverbindungen und wählen Sie in der Menüleiste (Falls nicht sichtbar “Alt” drücken) unter Erweitert die Option Erweiterte Einstellungen….

Schieben Sie dort den Adapter Management-Team ganz nach oben.

An dieser Stelle sind wir mit der Konfiguration des Netzwerks lokal und im Cluster fertig.

Die Einrichtung des Datenträgerzeugen / Quorum

Ganz wichtige Änderung unter Windows Server 2012 R2 in Bezug auf das Quorum: Erstellen Sie immer (egal welche Anzahl von Knoten und ob gerade oder ungerade) ein Quorum und weisen Sie dieses auch immer! zu. Das Failover Cluster verwendet dieses Quorum dynamisch, und zwar immer nur dann wenn es eins benötigt. Weitere Informationen und eine Bestätigung seitens Microsoft finden Sie im Technet: What’s New in Failover Clustering in Windows Server 2012 R2.

Da wir bei der Nutzung eines Scale-Out File Server keine CSV-Datenträger in unserem Failover Cluster haben müssen wir eine Dateifreigabe verwenden. Es existieren zu diesem Zeitpunkt drei Freigaben auf dem Scale-Out File Server. Die Freigabe HVQuorum wird für den Hyper-V Failover Cluster genutzt.

Wechseln Sie im Hauptmenü des Failover Cluster unter Weitere Aktionen auf Clusterquorumeinstellungen konfigurieren….

Es öffnet sich ein Assistent, der Sie bei der Einrichtung unterstützt. Nach der Vorbemerkung werden Sie nach der Art der Einrichtung gefragt. Die erste Option Standardquorumkonfiguration verwenden ist in diesem Fall nicht möglich, dies führt dazu das kein Quorum verwendet wird. Wir nutzen daher die zweite Option Quorumzeugen auswählen.

Im nächsten Schritt werden Sie nach der Art des Quorum gefragt, hier wählen Sie die Option Dateifreigabezeuge konfigurieren.

Schreiben oder Kopieren Sie nun den Pfad der Freigabe in den Assistenten.

Bestätigen Sie die Einstellungen und schließen Sie den Assistenten ab.

Nachdem Sie die Einrichtung abgeschlossen haben können Sie sehen, dass an besagtem Ort nun ein Ordner erstellt wurde, in dem eine Textdatei liegt.

Kurze Zeit später erscheint eine zweite Datei

Die Konfiguration ist nun abgeschlossen.

Die Einrichtung von Bandbreitenmanagement für SMB-Traffic

Wenn, wie in unserem Fall, die Livemigration und der Storage-Traffic über eine Leitung laufen, könnte dies ungewünschte Folgen bei vielen gleichzeitigen Livemigrationen haben. Zusätzlich werden Daten zwischen den einzelnen Hosts ebenfalls über diese Netze gesendet (Metric-Konfiguration weiter oben, bei der Storage1 die geringste Metric besitzt. In solch einem Fall können wir ein Bandbreitenmanagement für SMB-Traffic einführen. Die Installation kann auf Wunsch per Server-Manager gemacht werden, die Konfiguration muss allerdings zwingend per PowerShell gemacht werden. Das Feature versteckt sich hinter dem Namen SMB Bandwidth Limit.

Die Installation per PowerShell erfolgt mit dem Befehl

Add-WindowsFeature FS-SMBBW

Nach der Installation erfolgt die Einrichtung per PowerShell. Um die Livemigration auf z.B. 8 Gbit/s zu begrenzen, kann der folgende Befehl angewendet werden

Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 1000MB

Als Kategorie steht neben LiveMigration noch VirtualMachine und Default zur Verfügung.

Die Nutzung von SMB Multi Channel

Wir nutzen in unserem Fall mehrere Wege zu unserem Scale-Out File Server, daher haben wir beim Netzwerk-Design und bei der Einrichtung weiter oben zwei Storage-Karten konfiguriert. Grundsätzliches zum Thema SMB3 hat Carsten unter anderem in diesem Video gezeigt und erklärt: Hyper-V-Server.de: Videocast rund um Hyper-V auf SMB. Damit die Multi Channel-Funktionalität in einem Failover Cluster (egal ob Hyper-V oder Scale-Out File Server) greift, müssen sich die Storage-Karten in unterschiedlichen Subnetzen befinden. Multi Channel in einem Subnetz funktioniert nur bei Konfigurationen, in dem das Failover Cluster-Feature noch nicht installiert ist.

Der Beitrag Unsere Best Practice-Erfahrungen – Teil 1 – Die Installation eines Hyper-V Failover Cluster unter Windows Server 2012 R2 erschien zuerst auf Hyper-V Server Blog.

Im zweiten Teil unserer Serie möchten wir den Aufbau und die Einrichtung eines Scale-Out File Server unter Windows Server 2012 R2 zeigen. Wir nutzen für diesen Aufbau zwei Server und ein JBOD, welches mit HDDs und SSDs bestückt ist. Die Server sind HP DL360 Gen8-Systeme und haben jeweils eine CPU, 20 GB RAM und zwei lokale Festplatten für das Betriebssystem. Die Anbindung an das JBOD erfolgt per SAS, hier kommt ein Adapter von LSI zum Einsatz. Jeder Server besitzt vier 1 Gbit-Karten und zwei 10 Gbit-Karten zur Anbindung der Systeme an das Netzwerk. Als Betriebssystem kommt ein Windows Server 2012 R2 Standard zum Einsatz.

Update 04. November 2014: Wir haben diesen Artikel auf einen aktuellen Stand gebracht. Durch die Installation einiger Systeme, einigen Problemen mit gewissen Konfigurationen und weiteren Informationen, die wir erst später bekommen haben, ändert sich die Einrichtung in einigen Punkten. Alle geänderten Punkte sind in diesem Artikel farblich markiert und an der jeweiligen Stelle dazugekommen.

Update 30. Juni 2015: Ich habe den Artikel erneut geupdatet. Hinzugekommen ist eine Erweiterung des Bereichs Quorum im SOFS Cluster.

Update 14. Dezember 2015: Anpassung des Berechnung-Skripts, danke an Mike für den Hinweis

Falls Sie generell Interesse an diesem Thema haben, können wir Ihnen unseren Hyper-V PowerKurs empfehlen. Hier tauchen wir eine Woche in die Virtualisierung ein, der Aufbau und die Nutzung von SMB 3-Shares (sowohl Standalone als auch per Scale-Out File Server) spielen hier ebenfalls eine große Rolle. Mehr Informationen unter www.hyper-v-server.de/powerkurs .

Weitere Informationen zur aufgeführten Hardware

Zu der weiter oben schon kurz beschriebenen Hardware gibt es ein paar Dinge zu sagen. Zum einen möchte ich die Hardware näher und detaillierter auflisten, zum anderen ein paar Worte zu der Anzahl der jeweiligen Komponenten sagen. Das genutzte Equipment bietet zwar die Möglichkeit einen Scale-Out File Server aufzubauen, bietet aber an einigen Stellen keine Redundanz und daher nur eine bedingte Hochverfügbarkeit. Da uns momentan “nur” diese Hardware zu Demozwecken zur Verfügung steht können wir die Best-Practice-Vorgehensweise nur bedingt in Screenshots zeigen, die Beschreibung zeigt aber die optimale Einrichtung. Lesen Sie diesen Bereich unbedingt komplett, er enthält einige Informationen zu strategischen Entscheidungen und begründet einige der Best-Practice-Vorschläge.

Die genutzte Hardware

Als Hardware kommen die folgenden Komponenten zum Einsatz:

HP DL360e Gen8

• Intel E5-2403 CPU
• 20 GB RAM
• Zwei HDDs im RAID1 für das WS2012R2 Standard Betriebssystem
• LSI 9207-8e SAS HBA
• Intel X540-T2 10GBaseT Netzwerkadapter

DataOn DNS-1640 JBOD mit Platz für 24 2.5” HDDs

Seagate 1200 SSD mit einer Kapazität von 200 GB

Seagate Enterprise Capacity 2.5 HDD mit einer Kapazität von 1 TB

Der optimale Aufbau

Wie bereits erwähnt ist die Anzahl der einzelnen Komponenten für eine Hochverfügbarkeit sehr wichtig. Achten Sie unbedingt auf eine Zertifizierung der Hardware, eine Liste der von Microsoft zertifizierten Komponenten ist auf www.windowsservercatalog.com aufgeführt. Der hier beschriebene Scale-Out File Server ist die Basis für einen großen Teil Ihrer IT-Infrastruktur. Wackelt dieser Teil, wackelt auch alles oben drüber. Diese Zertifizierung ist kein “nice to have”, es ist absolute Pflicht!

Die Anzahl der JBODs

Die Anzahl der JBODs, die Sie einsetzen, steht im direkten Zusammenhang mit der Verfügbarkeit und dem Verhalten beim Ausfall solch eines Geräts. Um den kompletten Ausfall eines JBODs abfangen zu können benötigen Sie insgesamt drei Stück. Dies liegt daran, dass immer mehr als 50% aller Festplatten verfügbar sein müssen. Bei zwei JBODs mit gleicher Bestückung sind bei einem Ausfall eines Geräts genau die Hälfte aller Festplatten nicht mehr verfügbar, der Scale-Out File Server ist in diesem Moment nicht mehr funktionstüchtig. Sie könnten in eins der Gehäuse mehr Festplatten/SSDs stecken wie in das andere, aber wir kennen das Problem wahrscheinlich alle: Fällt in diesem Szenario etwas aus, ist es fast immer das Gehäuse mit der größeren Anzahl an Festplatten. Ihnen hilft zu einer echten Verfügbarkeit nur ein Betrieb eines dritten (oder noch mehr, dies geht natürlich auch) JBODs. Bei drei Gehäusen sollten Sie jeweils ein Drittel aller Festplatten und SSDs in einem der Gehäuse betreiben.

Die Art des JBODs

Achten Sie bei der Auswahl Ihrer JBODs auf eine Freigabe von Microsoft. Technisch werden JBODs mit den SCSI Enclosure Services (SES) benötigt, dies bedeutet das JBOD kann den Standort der Datenträger an den bzw. die Server melden. Nur diese Funktion ermöglicht eine Speicherung von Daten auf unterschiedlichen Datenträgern in unterschiedlichen JBODs. Weiß der Server nicht, wo welche Festplatte steckt, kann er hier keinen Schutz einbringen.

Enclosure Awareness

Damit Ihre Daten bei dem Betrieb von drei oder mehr JBODs vor einem Ausfall geschützt sind, müssen Sie eine Enclosure Awareness aktivieren. Dies bedeutet bei der Ablage von Daten auf Ihren Festplatten wird darauf geachtet, das die gespiegelten Daten nicht im gleichen JBOD gespeichert werden. Diese Funktion kann entweder für einen kompletten Storage Pool konfiguriert werden oder Sie setzen diese Eigenschaft bei der Erstellung Ihrer virtuellen Datenträger. Da diese Funktion nur per PowerShell aktiviert werden kann empfiehlt sich eine Erstellung von Datenträgern per PowerShell. Im späteren Verlauf des Artikels wird auf diesen Punkt erneut eingegangen. (TechNet Wiki: Enclosure Awareness Support – Tolerating an Entire Enclosure Failing)

Die Verkabelung der JBODs

Wir empfehlen eine direkte Verkabelung der JBODs pro Server, kein Schleifen der Verbindung (Chaining) über das vorherige JBOD. Technisch ist dies natürlich möglich, Sie bauen sich aber einen möglichen Engpass und eine potentielle Fehlerquelle ein. Binden Sie jedes JBOD direkt per SAS an. Wir selbst empfehlen und konfigurieren bei unseren Kunden die Systeme so, dass jedes JBOD doppelt an jeden Server angebunden ist.

Im folgenden Bild ist ein Scale-Out File Server Knoten mit insgesamt drei Dual-Port SAS HBAs an drei JBODs angeschlossen. Mit diesem Aufbau könnte ein kompletter Controller, ein Kabel oder ein JBOD ausfallen, ohne dass die Kommunikation abbrechen würde. Der zweite Knoten wird auf die gleiche Weise verbunden. Bei Vier-Port SAS HBAs reduziert sich die Anzahl der Karten auf zwei, um alle sechs Verbindungen zu realisieren.

Die Anzahl und Größe der Datenträger

Achten Sie bei der Anzahl der Datenträger in Ihrem Failover Cluster darauf, dass Sie mindestens genau so viele Datenträger wie Knoten besitzen. Da seit Windows Server 2012 R2 eine Verbindung pro Share und nicht mehr pro Dateiserver aufgebaut wird können Sie so erreichen, dass alle Cluster-Knoten aktiv genutzt werden und nicht die gesamte Last über einen Knoten verarbeitet wird, während die anderen auf einen Ausfall warten, um übernehmen zu können. Positiv hinzu kommt, dass unter 2012 R2 eine automatische Verteilung der CSV-Datenträger im Failover Cluster passiert. Sie müssen sich nicht aktiv um die Verteilung kümmern, die Datenträger werden automatisch an unterschiedliche Knoten zugewiesen.

Achten Sie bei der Größe der Datenträger darauf, dass Sie ausreichend freien Speicherplatz im Storage Pool lassen. Nur so erreichen Sie eine schnelle Wiederherstellung der Daten beim Ausfall eines Datenträgers. Mehr Informationen dazu und wie Sie den freien Speicherplatz berechnen können finden Sie ein paar Zeilen weiter unten.

Hot-Spare-Datenträger vs. Automatische Wiederherstellung

Oft wird beim Design von einem Scale-Out File Server mit Hot-Spare Festplatten kalkuliert. Diese sind beim Einsatz von Storage Spaces zwar möglich, seitens Microsoft aber nicht vorgesehen und nicht empfohlen (Microsoft TechNet: What’s New in Storage Spaces in Windows Server 2012 R2). Die empfohlene Variante ist die Nicht-Nutzung eines gewissen Prozenzsatzes des verfügbaren Speicherplatzes, was technisch auf ein ähnliches Resultat herausläuft, allerdings auf ein deutlich schnelleres. Ein kleines Rechenbeispiel:

Sie nutzen in Ihrem Scale-Out File Server mehrere SSDs und HDDs, die HDDs haben eine Größe von 4 TB. Sie haben eine weitere 4 TB Festplatte als Hot-Spare Datenträger konfiguriert. Ihnen fällt nun eine 4 TB Festplatte aus und die Daten auf der ausgefallenen Festplatte müssen nun auf den Hot-Spare Datenträger übertragen werden, damit der Spiegel wieder intakt ist. Bei einer Transferrate von 100 MegaByte pro Sekunde haben Sie eine Wiederherstellungszeit von 40000 Sekunden bzw. 11,1 Stunden. Diese Zeit wird natürlich nur benötigt, wenn die kompletten 4 TB beschrieben sind, bei einer geringeren Datenmenge nimmt die Dauer ab.

Microsoft hat bei Nutzung der Storage Spaces ein etwas anderes Verfahren genutzt, um die Daten beim Ausfall eines Datenträgers wiederherzustellen. Falls ausreichend Platz vorhanden ist werden die Daten, die auf der defekten Festplatte lagen, auf alle anderen verfügbaren Datenträger kopiert. Dies bedeutet es müssen nicht 4 TB auf eine Festplatte allein zurückgeschrieben werden, sondern eine gewisse Anzahl an Festplatten bekommt jeweils z.B. 100 GB. Da alle Festplatten gemeinsam “ihre” 100 GB speichern müssen ist der Gesamtzeitraum der Wiederherstellung deutlich geringer als bei der Wiederherstellung auf einer Festplatte.

Bei der Berechnung des freien Speicherplatzes gehen wir davon aus, dass alle Festplatten und alle SSDs die gleiche Kapazität haben. Die Berechnung muss separat für HDDs und SSDs gemacht werden, jeder Speicher muss einen eigenen freien Speicherplatz haben. Den freien Speicherplatz errechnen Sie wie folgt:

((Gesamter Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

Diesen freien Speicherplatz ziehen Sie von Ihrem Gesamt-Brutto-Speicherplatz ab. Im späteren Verlauf der Einrichtung sehen Sie, wie diese Formel bei der Berechnung des freien Speicherplatzes genutzt wird, um sowohl freien HDD- als auch freien SSD-Speicherplatz zu berechnen.

Update: Wir haben bei der Nutzung von freiem Speicherplatz zur Ausfallsicherheit einige Probleme gehabt. Während einer Wiederherstellung der Daten sind die Datenträger in dem entsprechenden Pool so stark beschäftigt, das dies die gesamte Performance des Storage negativ beeinflusst. Dies liegt daran, dass ein Storage Pool ohne Anpassung mit der RepairPolicy auf Parallel steht.

Dies bewirkt zwar eine sehr schnelle Wiederherstellung, allerdings auch eine sehr hohe Belastung. Man könnte an dieser Stelle die RepairPolicy umstellen auf Sequential, dies käme dann aber eher dem HotSpare-Gedanken nahe. Aus diesem Grund haben wir uns entschieden, in unseren Projekten aktuell ausschließlich auf HotSpare-Datenträger zu setzen, nicht auf freien Speicherplatz. Dies beeinflusst wieder die Anzahl an Datenträgern, die benötigt werden, um auf eine gewisse Anzahl an Coloums zu kommen. Mehr dazu etwas weiter unten.

Die Art der Spiegelung

Sie können grundsätzlich zwischen drei Arten Datenträgern wählen: Simple, Mirror oder Parity. Simple ist eine einfache Speicherung der Daten ohne Schutz vor einem Ausfall, bei Mirror werden die Daten gespiegelt und bei Parity nutzen Sie eine Parität ähnlich einem RAID5, um die Daten bei einem Ausfall von einem Datenträger trotzdem noch lesen zu können. Bei der Nutzung von Storage Spaces inkl. Tiering (wird etwas weiter unten erklärt) können Sie nur Simple oder Mirror wählen, Parity ist hier nicht möglich. Da Simple in den wenigsten Fällen zum Einsatz kommen wird konzentrieren wir uns in unserem Fall ausschließlich auf Mirror. Seit dem Windows Server 2012 R2 können Sie neben einem Zwei-Wege-Spiegel (Ein Block wird auf einem Datenträger abgespeichert und gleichzeitig auf einen weiteren gespiegelt) auch einen Drei-Wege-Spiegel aufbauen. Hierbei wird ein Block auf einem Datenträger gespeichert und zusätzlich auf zwei weitere Datenträger gespiegelt.

Nutzen Sie nach Möglichkeit immer einen Drei-Wege-Spiegel. Dies mag auf den ersten Blick als Verschwendung gelten, es gibt aber einen äußerst guten Grund für diese Art der Spiegelung: In einem Storage Space werden die Blöcke nicht wie bei einem RAID1 immer nur auf zwei Datenträgern abgespeichert, sondern die Daten liegen auf allen Festplatten verteilt. Dies führt dazu, dass im schlimmsten Fall in einem Zwei-Wege-Spiegel der Ausfall von zwei Datenträgern ausreicht, um einen Datenverlust zu erzeugen. Wird eine Enclosure Awareness genutzt können theoretisch alle Datenträger in einem JBOD ausfallen, danach aber kein weiterer mehr in einem der anderen JBODs. Wir empfehlen ausdrücklich die Einrichtung eines Drei-Wege-Spiegel, da hier zumindest zwei Festplatten ausfallen können, ohne das es zu Datenverlust kommt! (TechNet Wiki: What are the resiliency levels provided by Enclosure Awareness?)

Die Blocksize / Interleave der virtuellen Datenträger

Achten Sie bei der Erstellung und Formatierung der virtuellen Datenträger (bei der Nutzung als Ablage für Hyper-V VMs) darauf, dass Sie eine Blockgröße (im englischen Interleave genannt) von 64k verwenden. Dieser Wert ist optimal bei Nutzung als Ziel für Hyper-V VMs. Wie genau Sie diesen Wert konfigurieren zeigen wir Ihnen im späteren Verlauf bei der Konfiguration der virtuellen Datenträger.

Die Anzahl der Columns / Spalten

Die Anzahl der Colums bestimmt, über wie viele Datenträger die Daten gleichzeitig pro Verbindung weggeschrieben werden. Egal ob Sie nur HDDs, nur SSDs oder eine Mischung aus beidem haben, es gibt pro virtuellem Datenträger nur einen Column-Wert. Ein paar Beispiele:

• Sie haben zwei Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben einen Column-Wert von 1, d.h. Sie können pro Vorgang 64KB abspeichern (diese werden dann auf beide Festplatten geschrieben).
• Sie haben vier Festplatten in einem Zwei-Wege-Spiegel und ein Interleave von 64KB. Sie haben somit einen Column-Wert von 2, d.h. Sie können pro Vorgang 2x 64KB abspeichern (zwei Festplatten nehmen jeweils 64KB an, zwei weitere speichern eine Kopie dieser Daten).
• Sie haben 22 Festplatten und zwei SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben in dieser Konfiguration einen Column-Wert von eins, da der kleinste Wert pro Datenträger-Typ diesen Wert bestimmt. Pro Vorgang können maximal 64KB abgespeichert werden.
• Sie haben 18 Festplatten und sechs SSDs in einem Zwei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben somit eine Column-Anzahl von 3 und können pro Vorgang 3x 64KB abspeichern.

Diese Beispiele sollen Ihnen aufzeigen, dass nicht die Größe der SSDs bzw. HDDs ausschlaggebend sind, sondern die Anzahl. Teilweise sehen wir Konfigurationsvorschläge mit zwei 800 GB SSDs und vielen HDDs. Hier wären acht 200 GB SSDs deutlich besser. Die Column-Anzahl von eins bedeutet nicht, dass immer nur zwei Datenträger genutzt werden. Pro Vorgang werden zwei Datenträger genutzt, d.h. wenn Sie acht VMs betreiben kann jede auf jeweils zwei Datenträger schreiben (wenn der Spiegel mit kalkuliert wird, es können trotzdem nur 64KB geschrieben werden).

Bei einem Drei-Wege-Spiegel ändert sich die Berechnung ein wenig, dies kommt daher das pro Interleave drei HDDs bzw. SSDs benötigt werden. Zwei weitere Beispiele:

• Die haben neun HDDs und drei SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Sie haben eine Column-Anzahl von 1, da die drei SSDs diese Zahl erwirken. Gleichzeitig können 64KB verarbeitet werden pro Vorgang.
• Sie haben 24 HDDs und 12 SSDs in einem Drei-Wege-Spiegel mit einem Interleave von 64KB. Mit diesem Aufbau erreichen Sie einen Column-Wert von 4, bedingt durch die geringere Anzahl an SSDs.

Bei einer automatischen Erstellung der Datenträger ist die maximale Anzahl an Coloums der Wert 8, mehr werden nicht automatisch genommen. Bei der Erstellung der Datenträger per PowerShell können Sie auch einen höheren Wert auswählen. Sie müssen nicht grundsätzlich immer 8 oder mehr erreichen, Column-Werte ab 3 sind OK, falls möglich sollten Sie 4 erreichen. Alles über vier ist super, rechtfertigt aber meist nicht der erhöhten Preis für weitere SSDs (da diese in den meisten Fällen die geringe Anzahl in der Gesamtmenge ausmachen, aktuell noch bedingt durch den Preis).

Auf den Seiten von Microsoft ist eine Grafik abgebildet, die den Performance-Unterschied zwischen 2 und 4 Columns zeigt:

Quelle: TechNet Wiki: Storage Spaces – Designing for Performance

(TechNet Wiki: What are columns and how does Storage Spaces decide how many to use?)

Die Nutzung von Tiering

In der vorherigen Kapiteln wurde häufig von der Nutzung von HDDs und SSDs gleichzeitig gesprochen, hier folgt nun eine Erklärung dieser als Tiering bezeichneten Möglichkeit, die seit Windows Server 2012 R2 existiert.

Ein Pool kann unter 2012 R2 aus zwei unterschiedlichen Arten von Datenträgern bestehen, HDDs und SSDs. Hierbei ist es egal wie schnell die Festplatten sind, alle SAS-Festplatten werden als HDD behandelt. Grundsätzlich macht nur der Betrieb von Festplatten der gleichen Geschwindigkeit Sinn (z.B. immer NearLine-SAS HDDs mit 7.2k rpm). Neben HDDs können noch SSDs eingebunden werden, hier funktionieren ebenfalls nur SAS-SSDs, keine Consumer-Produkte.

Die Daten in den virtuellen Datenträgern werden vom Scale-Out File Server analysiert und je nach Nutzung entweder auf die SSDs verlagert (wenn festgestellt wird, dass die Daten häufig in Nutzung sind) oder auf den HDDs gespeichert (wenn festgestellt wird, dass die Daten nicht häufig benutzt werden). Das Betriebssystem arbeitet hier grundsätzlich mit 1 MB großen Blöcken, d.h. es werden nicht immer komplette Dateien verschoben, sondern nur 1 MB große Stücke der Datei.

Standardmäßig werden die Daten nachts um ein Uhr umsortiert, Grund hierfür ist ein Task auf den Datei Server-Knoten:

Weitere Informationen über den technischen Hintergrund finden Sie in den folgenden Beiträgen:

TechNet Blog: KeithMayer.com – Why R2? Step-by-Step: Automated Tiered Storage with Windows Server 2012 R2

TechNet Blog: Ask Premier Field Engineering (PFE) – Storage Spaces: How to configure Storage Tiers with Windows Server 2012 R2

Die Zusammenlegung von HDDs sowie SSDs führt zu der folgenden Situation: Mehrere große Festplatten, die nicht unbedingt schnell sind (z.B. 7.2k NL-SAS Festplatten mit 4 oder 6 TB) sorgen dafür, dass ausreichend Speicherplatz zur Verfügung steht. Mehrere SAS-SSDs sorgen dafür, dass der gesamte Pool ausreichend Performance bekommt.

Weiterer Vorteil bei der Nutzung von SSDs: Sie können einen Teil der SSDs als Write-Back Cache nutzen, ähnlich dem Cache auf einem RAID-Controller. Standardmäßig wird bei einem Storage Pool mit SSDs 1 GB an Speicherplatz für diese Caching-Technik genutzt. Aidan Finn hat zu diesem Thema einen Benchmark gemacht und auf seinem Blog veröffentlicht:

Aidan Finn – The Effects Of WS2012 R2 Storage Spaces Write-Back Cache

Bessere Performance-Werte um den Faktor 11 in einer (laut seiner Aussage) recht schnell aufgebauten Demo-Umgebung zeigen den unglaublichen Performanceschub bei Nutzung dieser Technik.

Lassen Sie den Standard-Wert von 1 GB auf diesem Wert stehen, dies ist laut Aussage der Produktgruppe ein optimaler Wert.

Die Vorbereitung der Server

Das Netzwerk

Nach der Grundinstallation und einem Update auf den aktuellsten Patchlevel beginnt die Einrichtung mit der Konfiguration der Netzwerkkarten. Es werden insgesamt drei Netze genutzt:

• Management – In diesem Netz befindet sich die Active Directory
• Storage1 – Eines der beiden SMB-Netze
• Storage2 – Das zweite SMB-Netz

In optimalen Fall besitzen die Server mindestens zwei Gbit-Adapter und vier 10 Gbit-Adapter. Dies ermöglicht die Nutzung von zwei Teams über beide 10 Gbit-Adapter. Dies ist notwendig, da SMB MultiChannel in einem Failover Cluster nur dann funktioniert, wenn sich alle Adapter in einem unterschiedlichen Subnetz befinden. Wenn wir davon ausgehen, dass die Hyper-V Hosts nur zwei Adapter im Storage-Netzwerk besitzen, können die SOFS-Knoten ebenfalls nur IP-Netze nutzen. Sollten die Hyper-V Hosts ebenfalls vier Adapter für SMB besitzen muss kein Team erstellt werden.

Die einzelnen Adapter werden in der Systemsteuerung umbenannt, um hier eine bessere Übersicht zu haben. Das Resultat sieht wie folgt aus:

Falls Sie mehrere Server konfigurieren möchten lässt sich diese Benennung per PowerShell ein wenig automatisieren:

Get-NetAdapter -InterfaceDescription “Intel(R) I350 Gigabit Network Connection” | Rename-NetAdapter -NewName 1GBit#1 –PassThru

Das Management-Netzwerk wird über Gbit-Karten abgebildet. Zur Redundanz werden hier zwei der vier onboard-Adapter zu einem Team zusammengeschlossen und konfiguriert. Dies kann entweder per GUI oder per PowerShell erfolgen:

New-NetLBFOTeam -Name “Management-Team” -TeamNICName “Management-Team” -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Danach werden die Karten mit IP-Adressen versehen. Das Resultat sieht wie folgt aus:

Management

Storage1

Storage2

Diese Karte hat bis auf die IP-Adresse die exakt gleichen Einstellungen wie Storage1 bzw. 10GBit#1. Diese Karte enthält die folgende IP-Adresse

Die Storage-Karten werden übrigens nicht geteamt, SMB3 ermöglicht eine Nutzung beider Adapter gleichzeitig (SMB Multichannel).

Die Konfiguration per PowerShell

Die oben gezeigte Konfiguration lässt sich komplett per PowerShell realisieren.

# Abfrage der IP-Adresse
$IP = Read-Host “Geben Sie das letzte Oktett der IP-Adresse eine”

# Team erstellen
New-NetLBFOTeam -Name “Management-Team” -TeamNICName “Management-Team” -TeamMembers `
1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

# IP-Konfiguration
Set-NetIPInterface -InterfaceAlias “Management-Team” -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias “Management-Team” `
-IPAddress 192.168.209.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias “Management-Team” -ServerAddresses 192.168.209.1

Set-NetIPInterface -InterfaceAlias “10GBit#1” -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias “10GBit#1” `
-IPAddress 192.168.208.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias “10GBit#1” -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name “10GBit#1” -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias “10GBit#2” -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias “10GBit#2” `
-IPAddress 192.168.207.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias “10GBit#2” -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name “10GBit#2” -ComponentID ms_tcpip6 -Enabled $False

Nehmen Sie die Systeme nun in die Active Directory auf und vergeben Sie einen aussagekräftigen Namen. In unserem Fall heißen die Systeme FSNode1 und FSNode2.

Als letzten Punkt der Netzwerk-Konfiguration setzen wir auf den Systemen in den erweiterten Einstellungen innerhalb der Netzwerkverbindungen das Management-Team an die vorderste Stelle.

Die Installation der benötigten Rollen und Features

Auf den beiden Systemen werden die folgenden Rollen und Features benötigt

Der Dateiserver wird benötigt, da dieser später als Rolle im Failover Cluster installiert und eingerichtet wird. Um eine Sicherung der VM-Daten machen zu können wird ebenfalls der VSS Agent Service benötigt. Einen Schritt weiter bei den Features wird das Failover Cluster-Feature inkl. den Verwaltungstools sowie MPIO (Multipfad E/A im deutschen) benötigt. Die Installation per PowerShell sieht wie folgt aus:

Install-WindowsFeature -Name FS-Fileserver, FS-VSS-Agent, Failover-Clustering, `
Multipath-IO -IncludeManagementTools

Wenn der Parameter –Computername noch mit angegeben wird kann die Installation auch remote durchgeführt werden.

Falls Sie noch weitere Rollen oder Features benötigen, hier ein Befehl zur Auflistung aller vorhandenen Rollen und Features:

Get-WindowsFeature | Select-Object -ExpandProperty Name | Write-Host

Die Einrichtung von MPIO

Dieser Schritt muss nur gemacht werden, wenn HDDs bzw. SSDs in einem oder mehreren JBODs verwendet werden, die mit mehr als einem SAS-Kabel angeschlossen sind. In unserem Fall hat jeder Server zwei Verbindungen pro JBOD, daher muss auf unseren Servern MPIO aktiviert werden. Die Aktivierung kann entweder per GUI oder per PowerShell gemacht werden und bedingt einen Neustart, der nach der Bestätigung des Neustarts auch direkt gemacht wird.

Per PowerShell funktioniert es mit dem folgenden Befehl

Enable-MSDSMAutomaticClaim -BusType SAS

Ein Neustart wird an dieser Stelle nicht eingefordert, ist aber auf jeden Fall sinnvoll

Restart-Computer

Die Überprüfung der Disks

Wenn Sie mehrere HDDs bzw. SSDs nutzen, kann es zu unterschiedlichen Performance-Werten bei eigentlich gleichen Datenträgern kommen. Bei einem Scale-Out File Server kann es zu sehr starken Einschränkungen bei der Gesamtperformance kommen, wenn ein oder mehrere Datenträger langsamer arbeiten wie andere. Aus diesem Grund sollten Sie vor der Nutzung Ihrer HDDs und SSDs einen Test machen, der Ihnen die Performance aller Datenträger ermittelt und aufführt. Sie benötigen ein PowerShell-Skript und die aktuellste Version des SQLIO-Tools:

Technet Script Center: Storage Spaces Physical Disk Validation Script

Microsoft Download Center: SQLIO Disk Subsystem Benchmark Tool

Technet Script Center: Completely Clearing an Existing Storage Spaces Configuration

Falls die HDDs oder SSDs bereits für etwas genutzt wurden benötigen Sie das unterste Skript zur kompletten Entfernung aller Informationen auf den Datenträgern. Achten Sie darauf, dass mit diesem Skript die Datenträger gelöscht werden. Falls Sie Daten auf den Disks noch benötigen, fertigen Sie ein Backup an!

Führen Sie das Skript aus und warten Sie darauf, dass alle Datenträger gelöscht wurden

Installieren Sie SQLIO auf dem Server und kopieren Sie die sqlio.exe-Datei an den Standort, an dem das Validation-Skript liegt. Alternativ kopieren Sie das Skript in das Installationsverzeichnis.

Führen Sie den folgenden Befehl aus und überprüfen Sie, ob die korrekten Datenträger aufgeführt werden

Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

Speichern Sie nun diese Datenträger in der Variablen $physicaldisks_to_pool mit dem Befehl

$physicaldisks_to_pool = Get-PhysicalDisk |? {($_.CanPool) -and (!$_.IsPartial)}

Starten Sie nun den Test mit dem folgenden Befehl

.\Validate-StoragePool.ps1 -PhysicalDisks $physicaldisks_to_pool

Der Test beginnt und listet Ihnen auf, wie viele HDDs und SSDs vorhanden sind. In meinem Fall sind es fünf SSDs und 19 HDDs. Der Test läuft nun einige Stunden, daher empfiehlt es sich diesen zu einem Zeitpunkt zu starten, an dem noch andere Aufgaben erledigt werden müssen oder der Feierabend winkt.

Als Ausgabe nach dem erfolgreichen Test erscheint der folgende Bericht

Schauen Sie sich die Warnungen und ggf. Fehler an, um potentiell schlechte Datenträger auszutauschen. In meinem Fall werden vier Datenträger bei der Leselatenz sowie drei Datenträger bei der Schreiblatenz angemerkt. Die ersten Werte liegen mit 830, 768, 776 und 801 ms nur wenig über dem Durchschnittswert von 620, bei den Schreiblatenzen könnte PhysikalDisk19 mit einer maximalen Latenz von knapp unter dem doppelten des Durchschnitts (1008 ms bei durchschnittlich 634 ms) evtl. getauscht werden. Führen Sie den Test evtl. ein zweites Mal durch und vergleichen Sie die Ergebnisse, um zufällige hohe Latenzen auszumerzen.

Die Erstellung des Failover Cluster

Wir sind nun an der Stelle angelangt, an dem das Failover Cluster erstellt und konfiguriert werden kann. Öffnen Sie dazu den Failover Cluster Manager und wählen Sie den Punkt Konfiguration überprüfen bzw. Validate Configuration….

Wählen Sie die beiden Server aus, die Mitglied des Failover Cluster werden sollen und führen Sie alle Tests aus.

Der Test versucht nun, alle Festplatten an allen Knoten zu erreichen. Sollte es hier zu Problemen kommen, wird Ihnen dies an dieser Stelle direkt angemerkt, nicht erst zu einem späteren Zeitpunkt während der Erstellung bzw. Konfiguration.

Sie können diesen Test natürlich auch per PowerShell starten, der Befehl hierzu lautet

Test-Cluster -Node FSNode1,FSNode2

Sie können jederzeit sehen, an welchem Punkt der Test sich gerade befindet

Nach Beendigung sehen Sie ein Ergebnis sowie den Pfad zu dem kompletten Bericht des Tests.

Schauen Sie sich diesen Test unbedingt an und korrigieren Sie potentielle Fehler. Sie können auch mit dem Parameter –ReportName einen Namen und einen Speicherort für den Bericht angeben, das macht die Suche einfacher.

Nachdem die Konfiguration nun überprüft wurde können Sie den Failover Cluster erstellen. Beenden Sie dazu den Überprüfungs-Assistenten und wechseln Sie in den Cluster erstellen-Assistenten. Fügen Sie die beiden Knoten hinzu

und wählen Sie einen Namen und eine IP-Adresse für das Failover Cluster. Da ich in meinem Fall kein Gateway gesetzt habe werde ich für alle Netze nach einer Adresse gefragt. An dieser Stelle deaktiviere ich alle Netze bis auf das Management-Netzwerk und setze nur in diesem Netzwerk eine IP-Adresse.

Achten Sie im nächsten Schritt unbedingt darauf, dass Sie den gesamten verfügbaren Speicher nicht automatisch hinzufügen lassen!

Nach einem Klick auf Weiter wird das Failover Cluster erstellt. Die Alternative per PowerShell wäre

New-Cluster –Name FSCluster1 –Node FSNode1,FSNode2 –StaticAddress `
192.168.209.110 -IgnoreNetwork 192.168.207.0/24,192.168.208.0/24 –NoStorage

Nach der Erstellung können Sie das Failover Cluster über den Failover Cluster Manager administrieren und benutzen.

Die Konfiguration des Failover Cluster zur Nutzung als Scale-Out File Server

Nach der Erstellung müssen noch ein paar Einstellungen angepasst werden, bevor die Erstellung des hochverfügbaren Dateiservers beginnen kann.

Das Netzwerk

Die Netzwerke sind aktuell in einer recht unsagenden Reihenfolge benannt, dies möchten wir gerne ändern und sprechende Namen verwenden. Wechseln Sie im linken Menü auf Netzwerk und setzen Sie die Namen der Netzwerke so, wie sie auch auf den lokalen Hosts konfiguriert sind.

Per Hand geht dies über die Eigenschaften der einzelnen Netzwerke, per PowerShell mit den folgenden drei Zeilen

(Get-ClusterNetwork | where-object {$_.Address -eq “192.168.209.0”}).Name = “Management”
(Get-ClusterNetwork | where-object {$_.Address -eq “192.168.208.0”}).Name = “Storage1”
(Get-ClusterNetwork | where-object {$_.Address -eq “192.168.207.0”}).Name = “Storage2”

Nach der Umbenennung sehen die Netzwerke wie folgt aus

Neben dem Netzwerk sollte noch die Metrik der einzelnen Karten überprüft werden. Dies geht ausschließlich per PowerShell

Get-ClusterNetwork | ft Name, Metric, AutoMetric -AutoSize

In meinem Fall hat Storage2 die kleinste Metric, dies bedeutet diese Karte hat im Failover Cluster die höchste Priorität (Je kleiner die Metric, desto höher die Priorität; allerdings immer abhängig von den anderen Karten). Die hier automatisch gesetzten Werte sind in Ordnung, falls diese geändert werden sollen geht dies mit den folgenden Befehlen

(Get-ClusterNetwork “Management”).Metric = 200
(Get-ClusterNetwork “Storage1”).Metric = 100
(Get-ClusterNetwork “Storage2”).Metric = 101

In diesem Beispiel wird Storage1 die Karten mit der höchsten Priorität, gefolgt von Storage2.

Ein Livemigration-Netzwerk müssen wir in dieser Art von Failover Cluster nicht aktiv konfigurieren, da keine VMs betrieben werden und somit auch kein RAM übertragen werden muss.

Zur Nutzung der beiden Storage-Karten für den Dateiserver später muss die Nutzung im Cluster umgestellt werden. Aktuell stehen die Netzwerke auf “Cluster only”, dies muss korrigiert werden auf “Cluster and Client”, da sonst kein Zugriff auf die Freigaben über diese Karten möglich ist. Setzen Sie die Option über die Gui

oder per PowerShell:

(Get-ClusterNetwork “Storage1”).Role = 3

(Get-ClusterNetwork “Storage2”).Role = 3

Die Rolle 1 bedeutet “Nur Cluster”, 3 bedeutet “Cluster und Client”.

Der Datenträgerpool

Um mit den Datenträgern in unserem JBOD arbeiten zu können wird ein Pool benötigt. Dieser Pool enthält alle HDDs und SSDs, die Erstellung kann per GUI oder per PowerShell vorgenommen werden.

Im Failover Cluster Manager wechseln Sie unter Speicher auf Pools und erstellen mit dem Menüpunkt Neuer Storage Pool eine neue Ansammlung von Datenträgern.

Im nächsten Schritt können Sie die Datenträger wählen, die Mitglied des Pools werden sollen. Sie sehen hier bereits die Größe, den Steckplatz, den Typ und weitere Informationen.

Unter Zuordnung bzw. Allocation belassen Sie alle Datenträger auf Automatisch, außer Sie wollen an dieser Stelle eine oder mehrere HotSpare-Datenträger definieren. Nach einem Klick auf Weiter sehen Sie eine Zusammenfassung, danach kann die Erstellung beginnen.

Per PowerShell können Sie den Pool wie folgt einrichten:

Suchen Sie im ersten Schritt nach allen verfügbaren Datenträgern

Get-PhysicalDisk | ft FriendlyName, CanPool, PhysicalLocation –AutoSize

Dieser Befehl listet Ihnen alle physischen Datenträger auf und zeigt Ihnen sowohl die Fähigkeit, einem Pool beizutreten als auch den Ort, an dem der Datenträger verbunden ist. In meinem Fall sehen wir auf dem System insgesamt 26 Datenträger, wovon 24 in meinem JBOD stecken

Datenträger 0 und 25 haben keine Informationen über den Aufenthaltsort, bei den anderen 24 Datenträgern erkennt man das JBOD. Mit der folgenden Zeile können Sie alle Festplatten zum Pool hinzufügen, achten Sie aber darauf die Seriennummer an Ihre eigene PhysicalLocation anzupassen.

New-StoragePool -FriendlyName Pool01 -StorageSubSystemFriendlyName *Spaces* `
-PhysicalDisks (Get-PhysicalDisk | where PhysicalLocation -like *500093D001CEC000*)

Falls mehrere JBODs eingesetzt werden, sollte an dieser Stelle die Enclosure Awareness eingeschaltet werden. Dies geht ausschließlich per PowerShell und wird mit dem folgenden Befehl erreicht:

Get-StoragePool -FriendlyName Pool01 | Set-StoragePool -EnclosureAwareDefault $true

Überprüfen können Sie den Wert mit dem folgenden Befehl:

Get-StoragePool -FriendlyName Pool01 | ft FriendlyName, EnclosureAwareDefault -AutoSize

Nun haben wir einen Pool, der im nächsten Schritt als Grundlage für unsere virtuellen Datenträger genutzt werden kann.

Die Erstellung der virtuellen Datenträger

Bei der Erstellung der Datenträger sollten Sie (wie bereits in den Vorbemerkungen weiter oben angesprochen) darauf achten, dass Sie ausreichend Platz lassen, damit der Rebuild bei einem Ausfall schnell funktionieren kann. Ich nutze in diesem Aufbau insgesamt 24 Datenträger, wovon fünf SSDs mit jeweils 200 GB und 19 HDDs mit jeweils 1 TB Speicherplatz sind.

Rein theoretisch habe ich nun die folgenden Werte in meinem Scale-Out File Server:

• Anzahl JBODs: 1
• Coloums: 5, da insgesamt fünf SSDs vorhanden sind
• Freier HDD-Speicherplatz: ((19TB/19+ 8GB) * 1 = 1,008 TB
• Freier SSD-Speicherplatz: ((1000GB/5) + 8GB) * 1 = 208 GB

Wir erinnern uns, die Formel zur Berechnung ist

((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure

Da wir ja alle seit der Erfindung von calc.exe eher weniger im Kopf rechnen möchten hier ein kleines Skript, welches die genaue Anzahl des freien Speicherplatz ausrechnet und in entsprechender Form ausgibt:

# j.kappen@rachfahl.de, 23.04.2014, Kalkulation des freien Speicherplatzes in einem StoragePool
# Ausgabe der vorhandenen Pools
Get-StoragePool
Write-Host “”
Write-Host “”

# Abfrage der Enclosure und des Pool-Namen
$anzahlenclosure = Read-Host “Geben Sie die Anzahl der Enclosure an”
$poolname = Read-Host “Geben Sie den Namen des Pools an, bei dem die Groessen berechnet werden sollen”

# Berechnung des SSD-Speichers
$disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq SSD
$ssdSpace = 0
$ssddiskCount = 0
foreach ($disk in $disks)
{
if ($disk.MediaType -eq “SSD”)
{
$ssdSpace += $disk.Size
$ssddiskCount++
}
}

# Berechnung des HDD-Speichers
$disks = Get-StoragePool -FriendlyName $poolname | Get-PhysicalDisk | where MediaType -eq HDD
$hddSpace = 0
$hdddiskCount = 0
foreach ($disk in $disks)
{
if ($disk.MediaType -eq “HDD”)
{
$hddSpace += $disk.Size
$hdddiskCount++
}
}

#Berechnung
$ssdSpaceinGB = $ssdSpace / 1024 / 1024 / 1024
$hddSpaceinGB = $hddSpace / 1024 / 1024 / 1024
$hddSpaceinTB = $hddSpace / 1024 / 1024 / 1024 / 1024
# ((Freier Speicherplatz/Anzahl der Datenträger) + 8GB) * Anzahl der Enclosure
$freessdspace = (($ssdSpaceinGB / $ssddiskCount) + 8GB) * $anzahlenclosure
$freehddspace = (($hddSpaceinGB / $hdddiskCount) + 8GB) * $anzahlenclosure

# Ausgabe der Ergebnisse
Write-Host -ForegroundColor Green “Kalkulation der empfohlenen Groessen”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green “Anzahl der SSDs:” $ssddiskCount
Write-Host -ForegroundColor Green “Gesamter SSD-Speicherplatz”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green $ssdSpace “Byte =>” $ssdSpaceinGB “GB”
Write-Host “”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green “Freier benoetigter SSD-Speicherplatz”
Write-Host -ForegroundColor Green $freessdspace “GB”
Write-Host “”
Write-Host “”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green “Anzahl der HDDs:” $hdddiskCount
Write-Host -ForegroundColor Green “Gesamter HDD-Speicherplatz”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green $hddSpace “Byte =>” $hddSpaceinGB “GB =>” $hddSpaceinTB “TB”
Write-Host “”
Write-Host -ForegroundColor Green “————————————–”
Write-Host -ForegroundColor Green “Freier benoetigter HDD-Speicherplatz”
Write-Host -ForegroundColor Green $freehddspace “GB”

Download: Berechnung_Freier_Speicherplatz_SOFS.txt

Das Skript fragt die Anzahl der Enclosure und den Namen des Pools ab und errechnet danach sowohl für SSDs als auch für HDDs den freien Speicherplatz.

Da wir nun den Speicherplatz ausgerechnet haben können wir mit der Erstellung der Datenträger fortfahren. Dies geht entweder per Failover Cluster Manager oder per PowerShell. Die GUI erlaubt ziemlich wenig Anpassungen gegenüber den Standardwerten, der wichtigste Punkt ist die Konfiguration der Blockgröße / des Interleave. Aus diesem Grund nehme ich die komplette Erstellung innerhalb der PowerShell vor.

Bei der Anzahl der Datenträger benötigen wir mindestens so viele Datenträger wie Cluster Knoten, in meinem Fall zwei. Zusätzlich kommt noch ein Quorum-Datenträger hinzu mit einer Größe von fünf GB. Dieser wird seit Server 2012 R2 immer benötigt, da immer ein Quorum zugewiesen wird und das Failover Cluster dynamisch mit dem Quorum arbeitet oder nicht, je nach Anzahl der Knoten. Da wir in diesem Aufbau zwei Server haben wir sowieso ein Quorum benötigt.

Die Erstellung des Quorum

Zur Erstellung des Quorum wird der folgende Befehl verwendet

Get-StoragePool Pool01 | New-VirtualDisk -FriendlyName “FSQuorum” -ResiliencySettingName “Mirror” -NumberOfDataCopies 3 -Size 5GB -Interleave 64KB

Dies bewirkt, dass im Storage Pool Pool01 ein neuer Datenträger mit dem Namen FSQuorum angelegt wird. Die Datensicherheit (Resiliency) ist ein Spiegel (Mirror), die Anzahl der Kopien sind 3 (d.h. es ist ein Drei-Wege-Spiegel). Die Größe wird mit 5 GB angegeben und die Interleave-Größe beträgt 64KB. Nach der Erstellung sieht der Datenträger im Failover Cluster Manager bzw. in der PowerShell wie folgt aus

Man erkennt, dass der Datenträger 8 GB groß geworden ist, trotz dem Befehl mit 5 GB. Dies liegt vermutlich an der Aufteilung der Daten auf den unterschiedlichen Festplatten, 8 GB scheint in diesem Fall die kleinste Größe zu sein. Bei knapp 20 TB an Speicherplatz ist dies aber nicht weiter tragisch.

Da ich bei der Erstellung nichts von einem Tiering angegeben habe, wurde dieser Datenträger komplett auf HDDs angelegt. Dies ist nicht weiter schlimm, auf dem Quorum-Datenträger wird sehr wenig geschrieben und gelesen, daher ist hier Tiering absolut nicht notwendig.

Damit ich das Laufwerk nutzen kann muss es nun noch formatiert werden. Dies geht entweder manuell über den Failover Cluster Manager (und auch nur, wenn der Wartungsmodus für den Datenträger aktiviert ist) oder ebenfalls per PowerShell. Achten Sie bei der Formatierung per GUI darauf, dass der Datenträger auf dem Host liegt, auf dem Sie die Formatierung machen möchten. In meinem Fall ist dies FSNode1.

# Datenträger auflisten
Get-VirtualDisk
Write-Host “”
Write-Host -ForegroundColor Red “Achtung, diese Aktion formatiert einen oder mehrere Datenträger!”
Write-Host “”
# Name abfragen
$vdName = Read-Host “Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten”
# Lokalen Computernamen herausfinden und speichern
$ComputerName = $env:COMPUTERNAME
# Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
Move-ClusterGroup “Available Storage” –Node $ComputerName
# Cluster-Ressourcen auflisten und einlesen
$clusterResource = Get-ClusterResource | where Name -like *$vdName*
# Wartungsmodus aktivieren
Suspend-ClusterResource $clusterResource
# Datenträger formatieren
Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume `
–FileSystem NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
#unset VirtualDisk Maintance Mode
Resume-ClusterResource $clusterResource

Download: Formatierung_Datentraeger_FailoverCluster.txt

Nach der Formatierung sieht der Datenträger im Failover Cluster Manager wie folgt aus

Die Erstellung der weiteren CSV-Datenträger

Im zweiten Schritt werden nun die CSV-Datenträger erstellt, in denen letztendlich die Daten der VMs gespeichert werden. Ich habe zwei Server, daher erstelle ich zwei virtuelle Datenträger. Um die korrekte Größe inkl. dem bereits erstellten Quorum zu setzen, hier ein weiteres Skript, welches auf die Daten aufbaut, die das vorherige Skript ausgeworfen hat.

$gesamtHDDSpace = Read-Host “Geben sie die gesamte HDD-Größe in GB ein”
$gesamtSSDSpace = Read-Host “Geben sie die gesamte SSD-Größe in GB ein”
$freierHDDSpace = Read-Host “Geben sie Reserve-Speicherplatz der HDDs in GB ein”
$freierSSDSpace = Read-Host “Geben sie Reserve-Speicherplatz der SSDs in GB ein”
$mirrorlevel = Read-Host “Geben Sie den Spiegel an, den Sie nutzen möchten (2 oder 3)”
$anzahlvdisks = Read-Host “Geben Sie die Anzahl der CSV-Datenträger ein”
Write-Host “”
$hddcsvsize = ($gesamtHDDSpace – $freierHDDSpace) / $mirrorlevel / $anzahlvdisks
$ssdcsvsize = ($gesamtSSDSpace – $freierSSDSpace) / $mirrorlevel / $anzahlvdisks
Write-Host -ForegroundColor Green “Größe des SSD-Speicherplatz:” $ssdcsvsize
Write-Host -ForegroundColor Green “Größe des HDD-Speicherplatz:” $hddcsvsize

Zur Erstellung werden die folgenden Zeilen Code genutzt:

# Storage-Tiers entfernen
Get-StorageTier | Remove-StorageTier

# Definiton
$poolName = “Pool01”
$ssdTierName = “SSD-Tier”+ $poolName
$hddTierName = “HDD-Tier”+ $poolName
$dataCopies = 3
$columnCount = 1

New-StorageTier -StoragePoolFriendlyName $poolName `
-FriendlyName $ssdTierName -MediaType SSD
New-StorageTier -StoragePoolFriendlyName $poolName `
-FriendlyName $hddTierName -MediaType HDD

$ssd_tier = Get-StorageTier | where FriendlyName -eq $ssdTierName
$hdd_tier = Get-StorageTier | where FriendlyName -eq $hddTierName
$ssdTierSize = 122GB
$hddTierSize = 2791GB

# Erstellung der Datenträger
New-VirtualDisk -StoragePoolFriendlyName $poolName `
-StorageTiers @($ssd_tier,$hdd_tier) `
-StorageTierSizes $ssdTierSize,$hddTierSize `
-ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
-NumberOfColumns $columnCount -ProvisioningType Fixed `
-FriendlyName vDisk1 -Interleave 64KB -IsEnclosureAware:$true

New-VirtualDisk -StoragePoolFriendlyName $poolName `
-StorageTiers @($ssd_tier,$hdd_tier) `
-StorageTierSizes @($ssdTierSize,$hddTierSize) `
-ResiliencySettingName Mirror -NumberOfDataCopies $dataCopies `
-NumberOfColumns $columnCount -ProvisioningType Fixed `
-FriendlyName vDisk2 -Interleave 64KB -IsEnclosureAware:$true

Auf Wunsch können diese Datenträger nun auch noch per PowerShell formatiert werden. Hierzu wird das gleiche Verfahren wie bei dem Quorum-Datenträger genutzt.

# Datenträger auflisten
Get-VirtualDisk
Write-Host “”
Write-Host -ForegroundColor Red “Achtung, diese Aktion formatiert einen oder mehrere Datenträger!”
Write-Host “”
# Name abfragen
$vdName = Read-Host “Geben Sie einen Namen des Datenträger an, den Sie formatieren möchten”
# Lokalen Computernamen herausfinden und speichern
$ComputerName = $env:COMPUTERNAME
# Neuen, verfügbaren Datenträger auf den lokalen Knoten verschieben
Move-ClusterGroup “Available Storage” –Node $ComputerName
# Cluster-Ressourcen auflisten und einlesen
$clusterResource = Get-ClusterResource | where Name -like *$vdName*
# Wartungsmodus aktivieren
Suspend-ClusterResource $clusterResource
# Datenträger formatieren
Get-VirtualDisk $vdName | Get-Disk | New-Partition –UseMaximumSize | Format-Volume –FileSystem `
NTFS –AllocationUnitSize 64KB –NewFileSystemLabel $vdName –Confirm:$false
#unset VirtualDisk Maintance Mode
Resume-ClusterResource $clusterResource

Nun sind zwei neue Datenträger vorhanden, jeweils mit einer Größe von 2,84 TB. Die Formatierung ist ebenfalls gemacht worden, die Blockgröße von 64KB wurde hierbei beachtet. In meinem Fall kann ich nur eine Coloum-Zahl von 1 verwenden, da fünf SSDs durch drei 1,66 sind. Alles nach dem Komma zählt nicht, die Coloum-Zahl beträgt 1. Um auf 2 zu kommen würde noch eine weitere SSD benötigt, für jede weitere Zahl drei weitere SSDs.

Damit diese Datenträger später als Speicher des Scale-Out File Server genutzt werden können müssen sie zu den Cluster Shared Volumes hinzugefügt werden. Dies geschieht entweder über den entsprechenden Punkt im Kontext-Menü oder per PowerShell:

Get-VirtualDisk
Write-Host “”
$vdName = Read-Host “Geben Sie den Namen des Datenträgers ein, der als CSV-Datenträger konfiguriert werden soll”
$clusterResource = Get-ClusterResource -Name “*$vdName*”
Add-ClusterSharedVolume -InputObject $clusterResource

Die Konfiguration der Quorum-Einstellungen

Als nächstes muss der 8 GB große Datenträger als Quorum-Datenträger konfiguriert werden. Dies geht über den Failover Cluster Manager über die erweiterten Befehle und dem Punkt Clusterquorumeinstellungen konfigurieren

Die Alternative per PowerShell:

Set-ClusterQuorum -NodeAndDiskMajority “Cluster Virtual Disk (FSQuorum)”

Mit diesem Schritt ist die Konfiguration schon beendet.

Die Erstellung und Konfiguration der Dateiserver-Rolle

Im nächsten Schritt müssen wir die Dateiserver-Rolle installieren und einrichten. Per GUI wird dies über Rollen – Rolle konfigurieren gemacht.

Wählen Sie den Dateiserver aus und bestätigen Sie die Auswahl mit Weiter.

Der nächste Schritt ist der wichtigste, an dieser Stelle wird die Art des Dateiserver ausgewählt. Der obere Punkt ist ein gewöhnlicher Dateiserver, der für die Ablage von Dateien genutzt werden kann. Dies wird in unserem Fall nicht benötigt, wir benötigen die untere Art von Dateiserver (im englischen als Scale-Out File Server bezeichnet, im deutschen als Dateiserver mit horizontaler Skalierung).

Unter Clientzugriffspunkt müssen Sie einen Namen für den Dateiserver eingeben. Unter diesem Namen ist der Server im Netzwerk erreichbar und ansprechbar. In meinem Fall nenne ich den Zugriffspunkt SOFS, d.h. mein Scale-Out File Server ist im Netzwerk unter \\SOFS\Share1 erreichbar.

Nach einer Überprüfung der AD auf ein evtl. schon vorhandenes Objekt mit diesem Namen bekommen Sie eine Zusammenfassung der Einstellungen, Sie sehen hier direkt die drei Subnetze, die von der Rolle genutzt werden.

Nach einem Klick auf Weiter beginnt die Erstellung der Rolle. Die Installation per PowerShell kann mit dem folgenden Befehl durchgeführt werden:

Add-ClusterScaleOutFileServerRole -Name “SOFS”

Als nächster Schritt kommt nun die Erstellung mehrerer Freigaben, auf die unsere Hyper-V Hosts zugreifen können. Wählen Sie im Kontextmenü der Dateiserver-Rolle den Punkt Freigabe hinzufügen.

Wenn Sie die folgende Meldung erhalten

haben Sie zwei Möglichkeiten. Entweder Sie holen sich jetzt einen Kaffee und versuchen es später erneut, oder Sie verschieben die Dateiserver-Rolle auf den Host, auf dem Sie gerade angemeldet sind. Falls dies immer noch nichts bringt und Ihr Failover Cluster-Manager Fehler bringt, die ein Berechtigungsproblem in Ihrem DNS anmerken (dies war bei mir der Fall, da die Objekte im DNS bereits vorhanden waren und nicht überschrieben werden konnten), gehen Sie wie folgt vor: Löschen Sie im DNS alle Einträge mit dem Namen des Scale-Out File Server. Erstellen Sie danach ein neues Objekt mit dem Namen und einer IP. Fügen Sie danach in den Sicherheitseinstellungen des DNS-Objekt das Computerobjekt hinzu und geben Sie ihm die Rechte zur Änderung des Eintrags:

Bestätigen Sie die Einstellungen und verschieben Sie die Dateiserver-Rolle erneut. Nun sollten keine Fehler mehr auftauchen und die Erstellung einer neuen Freigabe sollte ebenfalls funktionieren. Weiterhin werden alle IPs im DNS unter dem Namen der Rolle angelegt.

Es öffnet sich ein Assistent, der Sie durch die Erstellung der Freigabe führt. Als erstes müssen Sie ein Profil auswählen, um welche Art von Freigabe es sich handelt. Da wir VMs speichern möchten sollte das Profil Anwendungen gewählt werden

Im nächsten Schritt können Sie den Server wählen, hier ist direkt unsere Dateiserver-Rolle angewählt. im mittleren Bereich können Sie sehen, dass Sie hier nur die beiden CSVs auswählen können, keinen lokalen Pfad. Wir beginnen mit Volume1 und fahren im Assistenten fort.

Vergeben Sie nun einen Namen für die Freigabe. Ich habe sie in meinem Fall Share1 genannt. Sie können erkennen, wie sich der Name im unteren Bereich einträgt. An dieser Stelle können Sie bereits den kompletten Pfad sehen, über den Sie später Ihre VMs speichern.

Nach einem Klick auf Weiter sehen Sie, dass die erhöhte Verfügbarkeit eingeschaltet ist und auch nicht entfernt werden kann. Diese Option ermöglicht einen nahtlosen Betrieb der VMs, auch bei einem Ausfall oder einem Neustart eines der Datei Server-Knoten

Nun kommen wir zu einer sehr wichtigen Stelle: Die Konfiguration der Berechtigungen für diese Freigabe

Passen Sie diese Einstellungen wie folgt an: Wählen Sie Berechtigungen anpassen im unteren Bereich und deaktivieren Sie als erstes die Vererbung. Danach entfernen Sie die Benutzer-Berechtigungen auf dieser Freigabe, Benutzer haben an dieser Stelle nichts zu suchen. Fügen Sie danach die Computerkonten aller Hyper-V Hosts hinzu, die auf diese Freigabe zugreifen sollen. Zusätzlich fügen Sie das bzw. die Cluster-Objekte hinzu der Hyper-V Failover Cluster (falls Sie einen oder mehrere Hyper-V Failover Cluster betreiben). Zuletzt geben Sie den AD-Admins noch eine Berechtigung auf diese Freigabe.

Das Ergebnis sieht wie folgt aus

Nach einem Klick auf Weiter bekommen Sie eine kurze Zusammenfassung der Einstellungen, wenn diese korrekt sind können Sie die Freigabe erstellen.

Erstellen Sie eine zweite Freigabe, die auf dem Volume2 erstellt wird. Die Einstellungen bleiben die gleichen, nur der Name ändert sich. Das Resultat sieht wie folgt aus

Die Einrichtung per PowerShell sieht wie folgt aus:

# Konfiguration_NTFS_Berechtigungen.ps1 – Jan Kappen – j.kappen@rachfahl.de
# Erstellung einer neuen Freigabe für die SOFS-Rolle und Anpassung
# der Rechte. Eine Anpassung ist notwendig an den markierten Stellen
#
# Konfiguration des Namen
# Anpassung notwendig!
$Sharename = “Share6”
$Volumename = “Volume1”
# Erstellen des neuen Ordners
New-Item -Name $Sharename -ItemType Directory
mkdir C:\ClusterStorage\$Volumename\Shares\$Sharename
# Erstellung eines neuen Shares mit HA und ohne Caching
#
# Falls die Quorum-Freigabe erstellt werden soll, kann der Parameter
# -ContiniousAvailable auf $false angepasst werden
#
New-SmbShare -Name $Sharename -Path C:\ClusterStorage\$Volumename\Shares\$Sharename `
-CachingMode None -FullAccess “everyone” -ContinuouslyAvailable $true
# Anzeige der Berechtigungen
Get-Acl “C:\ClusterStorage\$Volumename\Shares\$Sharename” | fl
# Benutzer aus den Rechten entfernen
$colRights = [System.Security.AccessControl.FileSystemRights]”Read”
$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None
$objType =[System.Security.AccessControl.AccessControlType]::Allow
$objUser = New-Object System.Security.Principal.NTAccount(“BUILTIN\Users”)
$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)
$objACL = Get-ACL “C:\ClusterStorage\$Volumename\Shares\$Sharename”
$objACL.RemoveAccessRuleAll($objACE)
Set-ACL “C:\ClusterStorage\$Volumename\Shares\$Sharename” $objACL
# Anzeige der Berechtigungen
Get-Acl “C:\ClusterStorage\$Volumename\Shares\$Sharename” | fl
# Besitzer konfigurieren
$acl = Get-Acl “C:\ClusterStorage\$Volumename\Shares\$Sharename”
$acl.SetOwner([System.Security.Principal.NTAccount] “Administrators”)
Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
#
$acl = Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename
$acl.SetAccessRuleProtection($True, $False)
#
# Anpassung der Systemnamen sowie des Failover Cluster-Objekts notwendig!
#
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“Powerkurs\Hyperv14$”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“Powerkurs\Hyperv15$”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“Powerkurs\powercluster1$”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“Powerkurs\domain admins”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“SYSTEM”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule `
(“CREATOR OWNER”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$acl.AddAccessRule($rule)
Set-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename $acl
# Erneute Anzeige der Einstellungen
Get-Acl C:\ClusterStorage\$Volumename\Shares\$Sharename  | Format-List

Download: PowerShell Skript: Konfiguration_NTFS_Berechtigungen

Die Erstellung einer Freigabe zur Nutzung als Quorum

An dieser Stelle müssen wir noch eine weitere Freigabe erstellen, die als Quorum für unser Hyper-V Failover Cluster genutzt wird. Bei dieser Freigabe gibt es eine kleine Besonderheit: Sie sollte nicht dauerhaft zur Verfügung stehen, heißt wir konfigurieren diese Freigabe ein wenig anders. Diese Konfiguration kann allerdings erst nach der Erstellung gemacht werden, die Erstellung ist gleich wie bei den beiden Shares oben. In welchem Volume Sie die Freigabe erstellen ist grundsätzlich egal, ich lege sie in meinem Fall auf Volume1.

Nach der Erstellung sehen Sie einen weiteren Share:

An dieser Stelle wechseln wir in die Eigenschaften von dieser Freigabe und konfigurieren in den Einstellungen die erhöhte Verfügbarkeit so, dass diese nicht markiert ist

Update 30. Juni 2015: Wir haben festgestellt, dass diese Einstellung (trotz Empfehlung seitens Microsoft) nicht optimal ist, da es zu Fehlern im Eventlog auf den Hyper-V Hosts bzw. im Hyper-V Cluster kommt. Wird der Share im CA-Modus (also mit Haken) betrieben, tauchen keine Fehler auf. Laut Best-Practice-Empfehlung erfolgt der Schwenk des Quorum bei einem Ausfall eines SOFS-Knoten schneller. Beide Varianten sind transparent, ob es nun schneller oder langsamer geht ist somit auch zu vernachlässigen. Mit eingeschalteter CA erscheinen keine Fehler, dies erleichtert das Monitoring.

Nun kann die Einstellung übernommen werden und die Freigabe ist korrekt konfiguriert.

Quelle: Failover Clustering and Network Load Balancing Team Blog – Configuring a File Share Witness on a Scale-Out File Server

Dieser Vorgang funktioniert auch mit dem oben verlinkten Skript, im oberen Teil bei der Erstellung der Freigabe müssen Sie eine Anpassung bei dem Parameter –ContiniouslyAvailable machen (weitere Infos im Skript), danach wird eine passende Freigabe erstellt.

Nach dieser Anpassung ist der Aufbau im groben komplett. Sie können nun per \\sofs\Share1 oder \\sofs\Share2 auf die beiden Freigaben zugreifen, zusätzlich kann die dritte Freigabe als Quorum-Ablage genutzt werden.

Noch ein paar Worte zu Zugriffszeiten, Benchmarks usw…

Wenn Sie das erste Mal auf die neu erstellten Freigaben zugreifen, kann es einige Zeit dauern, bis das Verzeichnis aufgerufen werden kann und Sie durch die Ordner navigieren können. Dies ist normal, es braucht einen kleinen Moment bis die Verzeichnisse erstmals aufgerufen werden können. Lassen Sie sich hier nicht beunruhigen. Wenn Sie während der Einrichtungs- bzw. Test-Phase das komplette Cluster herunterfahren oder alle Server gleichzeitig neustarten kann es nach dem Start ebenfalls einige Zeit dauern, bis alle Zugriffe wieder problemlos und ohne Verzögerung passieren. Planen Sie hier bitte ebenfalls ein paar Minuten ein, bis alles wieder flüssig und sauber läuft. Im Betrieb sind diese kompletten Ausschaltungen eher selten, daher passiert dies meist bei Simulationen von Problemen oder der kompletten Abschaltung des Dateiserver Cluster.

Wenn Sie einen Performance-Test Ihres neu erstellten Scale-Out File Server machen möchten, fällt Ihnen wahrscheinlich als erstes die Kopie einer Datei auf einen der beiden Shares ein. Dies können Sie zwar machen, lassen Sie sich aber nicht von den Werten abschrecken, die sie während des Kopiervorgangs bekommen. Ein Scale-Out File Server speichert alle Blöcke ungepuffert. Dies wirkt sich bei Datei-Kopier-Operationen negativ aus, bei dem eigentlichen Betrieb des Speichers (der Ablage von VM-Daten) ist dies aber notwendig, damit alle Dateien und Blöcke immer definitiv auf den Platten landen, und nicht in irgendeinem Cache, der bei einem Stromausfall verfallen würde. Ein besserer Benchmark-Test wäre der Betrieb von einigen VMs, in denen mit Hilfe von Last- oder Benchmark-Tools I/O erzeugt wird. Selbst bei diesem Test gibt es wiederum einige Dinge, die beachtet werden sollten. Eine VM alleine reicht nicht, erst die Summe einiger VMs erzeugt (vielleicht) die Art von Last, die im späteren Betrieb auch auf dem System anliegt. Die Tiering-Funktion greift erst dann, wenn eine Umsortierung der Blöcke stattgefunden hat. Dies passiert, wie weiter oben erwähnt, standardmäßig täglich um 1:00 Uhr nachts. Eine Verbesserung der Benchmark-Werte (z.B. bei einem dauerhaften Benchmark) zeigt sich somit erst nach frühestens einem Tag.

Die Nutzung eines Skripts zur kompletten Failover Cluster-Erstellung

Die in diesem Beitrag genutzten Skripte sind fast alles Teilbereiche eines Skripts, welches mein Kollege Carsten Rachfahl bereits in einem Video genutzt und für unsere Zwecke angepasst hat. Das Skript kann ein komplettes Failover-Cluster inkl. Berechnung der Größen, Aufteilung und Erstellung der Datenträger usw. erstellen. Das Skript sowie das ziemlich sehenswerte Video finden Sie hier: Hyper-V-Server.de: Einen bestehenden Scale-Out Fileserver um SSDs erweitern

An diese Stelle ist die Einrichtung im großen und ganzen abgeschlossen. Je nach Umgebung stehen nun noch weitere Schritte an, spontan fällt mir hier noch das Thema Backup ein.

Bei Fragen, der Suche nach Unterstützung oder der Durchführung solch eines Projekts stehen wir Ihnen natürlich gerne zur Verfügung.

Der Beitrag Unsere Best Practise-Erfahrungen – Teil 2 – Die Installation und Einrichtung eines Scale-Out Fileserver unter Windows Server 2012 R2 erschien zuerst auf Hyper-V Server Blog.

In diesem Beitrag geht es darum, wie man mit recht einfachen Mitteln einen oder mehrere Scale-Out File Server überwachen kann. Voraussetzung ist, dass Sie einen Scale-Out File Server mit JBODs betreiben. Ein Aufbau mit einem oder mehreren SANs kann zwar auch überwacht werden, hier können aber weniger Informationen ausgelesen werden. Grundlage ist das von Jose Barreto geschriebene PowerShell-Skript Test-StorageHealth. Das Skript verbindet sich mit einem Scale-Out File Server Cluster und überprüft ziemlich viele Dinge, unter Anderem den Status von Festplatten, Enclosures, Volumes usw. Ich habe mit einem zweiten Skript das Verhalten dahingehend ein wenig verändert, dass der Status, der sonst in dem PowerShell-Fenster oder in einer Datei auf dem Server selbst liegt, per Mail an einen Empfänger oder einen Verteiler gesendet werden kann. So kann z.B. jeden Morgen die Mail überprüft werden, ohne das jedes Mal eine Verbindung zu dem Failover Cluster-Knoten aufgebaut werden muss. Aber beginnen wir erst einmal mit dem Skript an sich:

Das Test-StorageHealth-Skript

Das Skript selbst kann direkt aus der TechNet-Gallery bezogen werden:

Test-StorageHealth.ps1 – Storage Cluster Health Test

Nach dem Download kann das Skript direkt ohne weitere Informationen oder Parameter aufgerufen werden. Dieser Aufruf (ohne Parameter) beginnt einige Informationen über den Failover Cluster zu sammeln. Bedingung ist, dass das Skript auf einem der Knoten direkt ausgeführt wird. Die Daten werden nach Beendigung des Skripts im Ordner “HealthStatus” im Profil des aktiven Benutzers gespeichert. In den wenigsten Fällen werden die überprüften Werte in dem Skript automatisch passen, daher sollten diese vor dem ersten Aufruf angepasst werden. Öffnen Sie die Datei Test-StorageHealth.ps1 in einem Editor (z.B. der PowerShell ISE) und passen Sie die Werte in den Zeilen 60 bis 116 an. Angepasst werden sollten:

• Zeile 83:  [int] $ExpectedNodes = 4, => Hier tragen Sie die Anzahl der Hardware-Knoten ein
• Zeile 87: [int] $ExpectedNetworks = 2, => Die Anzahl der Netzwerke in Ihrem Cluster
• Zeile 91: [int] $ExpectedVolumes = 33, => Die Anzahl an Datenträgern im Cluster
• Zeile 95: [int] $ExpectedDedupVolumes = 16, => Die Anzahl an Datenträgern mit aktivem Dedup
• Zeile 99: [int] $ExpectedPhysicalDisks = 240,=> Die Anzahl an Datenträgern (HDDs und SSDs)
• Zeile 103: [int] $ExpectedPools = 3,=> Die Anzahl an Datenträgerpools
• Zeile 107: [int] $ExpectedEnclosures = 4, => Die Anzahl an Enclosures

Die Einstellungen müssen nicht unbedingt in der Datei gemacht werden, Sie können das Skript auch bei jedem Aufruf mit Hilfe von zusätzlichen Parametern anpassen. Ein Aufruf des Skripts sähe dann z.B. wie folgt aus:

.\Test-StorageHealth.ps1 -ExpectedNodes 2 -ExpectedNetworks 3 -ExpectedVolumes 3 -ExpectedDedupVolumes 0 -ExpectedPhysicalDisks 24 -ExpectedPools 1 -ExpectedEnclosures 1 -HoursOfEvents 12

Weitere Erklärungen finden Sie in dem folgenden Beitrag: How to use the Test-StorageHealth.ps1 PowerShell script with different configurations

Die von dem Skript erzeugte Datei kann nachträglich erneut aufgerufen werden. Hierzu rufen Sie das Skript mit dem Parameter –ReadFromPath C:\Datei.zip auf.

Der automatische Mail-Versand des Skripts

Das Skript generell ist ein echt cooles Stück PowerShell-Code, allerdings kann standardmäßig keine Email erzeugt werden, die die Ausgabe an einen oder mehrere Empfänger sendet. Ich habe diesen Teil mal übernommen und ein kleines Skript “drum herum” gebaut, welches die Ausgabe, die man oben in den PowerShell-Fenstern sieht, automatisch per Mail zugesandt bekommt. Grundlage hiervon war das Autotiering-Skript von Carsten, ich habe letztendlich “nur” die einzelnen Pfade angepasst und das neue Skript lauffähig gemacht.

Download: Task_Test-StorageHealth.zip

In dem Zip-Archiv ist ein eigenes kleines Skript enthalten, welches den Aufruf des eigentlichen Überprüfung-Skripts übernimmt und die Ausgabe automatisch per Email sendet. Dazu sind innerhalb des Skripts ein paar Anpassungen notwendig.

Mail-Server:

Kommentieren Sie die Zeilen 6-8 aus und nehmen Sie die Auskommentierung von Zeile 9-11 weg. Tragen Sie in Zeile 9 Ihren Mail-Server ein, definieren Sie in Zeile 10 den Empfänger und bei Bedarf können Sie in der Zeile 11 noch den Absender der Email-anpassen.

Logfile:

In Zeile 14 können Sie den Ort des Logfiles anpassen, an dem der Mail-Inhalt ebenfalls nochmal abgelegt wird.

Das Test-StorageHealth-Skript

In Zeile 22 müssen Sie den Pfad zu dem eigentlichen Skript anpassen. Alternativ können Sie natürlich auch das Skript unter C:\tools ablegen, in diesem Fall muss keine Anpassung mehr vorgenommen werden. Falls Sie den Pfad, an dem die .zip-Datei mit dem Ergebnis abgelegt wird, ebenfalls anpassen wollen, müssen Sie die Zeile 22 auskommentieren und die Zeile 21 nutzen. Der Parameter –zipPrefix definiert, wo die Datei gespeichert wird. Achten Sie unbedingt darauf, dass der Pfad mit einem “\” abgeschlossen wird!

Speichern Sie die Änderungen und testen Sie das Skript einem Aufruf der Datei über eine administrative PowerShell. Wenn dies erfolgreich ist und im besten Fall direkt eine Email ankommt, können Sie mit der Einrichtung des Tasks fortfahren.

Erstellen Sie über die Aufgabenplanung einen neuen Task mit den folgenden Einstellungen:

Die Zeit ist natürlich egal, Sie können das Skript auch alle sechs Stunden oder nur einmal in der Woche ausführen, je nach Bedarf.

Unter Aktionen tragen Sie bei Programm/Skript C:\Windows\system32\windowspowershell\v1.0\powershell.exe ein, unter Argumente hinzufügen tragen Sie den Pfad zu der Datei Task_Test-StorageHealth.ps1 ein.

Vergeben Sie ein Konto und ein Kennwort, unter dem der Task ausgeführt werden soll. Fertig ist die Erstellung, nun wird zu der definierten Zeit das Skript ausgeführt und meldet die Ausgabe per Email.

Diesen Task könnte man nun auch noch auf den anderen Knoten im Failover Cluster einstellen. Der Bericht meldet das gleiche, allerdings kommt auch bei dem Ausfall von Knoten A ein Bericht, in dem der Ausfall von einem Node vermeldet wird. Alternativ lassen Sie das Skript auf einem Server außerhalb des Failover Cluster laufen, hierzu müssen Sie allerdings den Namen des Failover Cluster noch mit angeben. Dies muss in der Datei Test-StorageHealth.ps1-Datei gemacht werden (Zeile 67: [string] $ClusterName = “.”,).

Der Beitrag Überprüfung und Überwachung eines Scale-Out File Server mit dem Test-StorageHealth Skript erschien zuerst auf Hyper-V Server Blog.

Ich habe für die November-Ausgabe des IT-Administrator einen eigenen Artikel beigesteuert, in dem ich den Test einer Violin 6000 beschreibe. Das Gerät ist ein Storage-System, welches ausschließlich mit Flash Speicher arbeitet. Der Artikel beschreibt das Gerät, die durchgeführten Tests und natürlich die Ergebnisse, die in diesem Test ermittelt wurden.

Die November-Ausgabe ist seit dem 04. November erhältlich und kann eigentlich überall dort erworben werden, wo es Zeitschriften gibt. Alternativ kann das Heft natürlich auch direkt bestellt werden: IT-Administrator: Ausgabe November 2014 Storage & Datenmanagement.

Der Beitrag Artikel im IT-Administrator–Test eines Violin 6000 All Flash Array erschien zuerst auf Hyper-V Server Blog.

Wer einen hohen Bedarf an IOPS, niedrigen Latenzen und/oder Performance im Bereich Netzwerkspeicher hat, kommt um ein System mit flashbasiertem Speicher kaum herum. Es gibt unterschiedliche Ansätze, wie die benötigte Leistung erbracht werden kann. In diesem Test geht es um ein System der Firma Violin Memory, die mit der Violin 6000 All Flash Arrays ein Speichersystem anbietet, welches ausschließlich auf Flash-Speicher basierend und mit zu einer Million IOPS bei einer äußerst geringen Latenz eine High-End Lösung bereit stellt. Welche Performance dieses System im Bereich der Virtualisierung mit Hyper-V bietet schauen wir uns in diesem Artikel an.

Dieser Artikel ist im November 2014 bereits im IT-Administrator Magazin erschienen.

6100, 6200 oder 6600?

Innerhalb der Violin 6000 Serie gibt es mehrere Varianten, die sich in der Art des Flash Speichers, der Größe, der maximalen Performance und natürlich dem Preis unterscheiden.

*) Dieses Modell gibt es nicht als Windows Flash Array, sondern nur mit dem Violin-eigenen Betriebssystem vMOS.

**) die Nutzkapazität ist abhängig von der Formatierung. Die Werte beziehen sich auf ein Formatierungslevel von 84%.

Das in diesem Test genutzte Modell trägt die Bezeichnung Violin 6264 und bietet eine Brutto-Speicherkapazität von 70 TB, wovon 44 TB nutzbar sind. Die Anzahl der IOPS, die mit diesem Modell erreicht werden können, liegen laut Datenblatt des Herstellers bei 750.000.

Der technische Aufbau

Neben dem reinen Flash-Speicher enthält das Gerät unter anderen noch zwei Server (vom Hersteller als Memory Gateways, abgekürzt MG, bezeichnet), die mit Windows Server 2012 R2 in der Storage Edition betrieben werden. Die Lizenzen für diese Server sind bereits enthalten, auf jedem der beiden Server-Einheiten befindet sich ein Lizenzaufkleber. Beide Server sind intern mehrfach redundant an den Flash-Speicher angebunden, dies wird über vier aktiv/aktiv RAID-Controller (vRAID Control Modules, abgekürzt VCM) erreicht. Von diesen vier VCMs könnten bis zu drei ausfallen, der Betrieb würde (wenn auch verständlicherweise mit Leistungseinbußen) weiterhin funktionieren. Der Speicher in dem Testgerät besteht aus einzelnen Modulen mit einer Größe von jeweils 1 TB, diese werden als Violin Intelligent Memory Modules bezeichnet (im weiteren Verlauf mit VIMM abgekürzt). Fünf dieser VIMMs werden jeweils zu einem Verbund (vom Hersteller wird dieser Verbund als VIMM Protection Group bezeichnet) zusammengefasst. Eingehende Daten werden grundsätzlich in 4KB großen Blöcken abgespeichert. In jedes VIMM einer VIMM Protection Group werden 1 KB geschrieben, in das fünfte VIMM werden zusätzlich 1KB Paritätsinformationen geschrieben. Vorweg geschaltete Array Control Module (ACM) sorgen dafür, dass eingehende Daten nur in Speicher geschrieben werden, der gerade nicht durch einen anderen Prozess beeinflusst wird. Diese Technik umgeht Performance-Einbrüche durch anstehende oder gerade aktive Lösch-Aktionen oder durch eine aktive Garbage Collection und sorgt für eine durchgehend hohe Performance.

Für den Ausfall eines VIMMs stehen insgesamt vier Hot Spare-VIMMs zur Verfügung. Sollte es zu einem Ausfall kommen, können alle Komponenten (VIMMs, VCMs, Netzteile, …) im Betrieb getauscht werden.

Eine Anbindung der Server per Netzwerk nach „außen“ wird je nach Konfiguration über Fibre Channel (acht Ports mit je 4 oder 8 Gb/s), Ethernet (acht Ports mit je 10 Gb/s) oder Infiniband (vier Ports mit je 40 Gb/s) erreicht, wobei die Fibre Channel-Variante ausschließlich bei dem vMOS-System zum Einsatz kommt. Bei den Windows Flash Array-Modellen haben Sie „nur“ die Wahl zwischen Ethernet oder Infiniband. Das uns zur Verfügung stehende Gerät besitzt die bereits erwähnte Anbindung per Ethernet, d.h. es stehen insgesamt 80 Gb/s zur Verfügung. Verbaut sind vier Karten der Firma Chelsio mit jeweils zwei Interfaces (Chelsio T-520CR Dual-Port 10 Gigabit Ethernet Adapter). Jeder der beiden Server bekommt zwei dieser Karten zugewiesen und kommt somit auf eine Bandbreite von 40 Gb/s. Die Karten unterstützen Remote Direct Memory Access (RDMA), auf diese Funktionalität gehen wir später erneut ein und schauen uns die Vorteile dieser Technik an.

Zusätzlich zur Anbindung über 40 Gb/s besitzt jeder Server noch einen Intel 82579LM- sowie zwei Intel I350-Adapter mit einer Bandbreite von jeweils 1 Gb/s.

Beide Server verfügen über 24 GB RAM (die Anzahl an RAM könnte bei Bedarf auf bis zu 48 GB erhöht werden) sowie zwei Intel Xeon E5-2448L CPUs mit jeweils 20 MB L3 Cache. Jede CPU besitzt acht Cores, dank Hyperthreading käme jeder Server somit auf 32 logische Prozessoren.

Die Speicherbereitstellung

Die beiden in dem Storage verbauten Server werden nicht direkt zur Virtualisierung genutzt, sondern stellen den Flash-Speicher über SMB 3 im Netzwerk zur Verfügung. Die beiden Systeme werden zu einem Failover Cluster konfiguriert, innerhalb dieses Clusters wird eine hochverfügbare Dateiserver-Rolle betrieben. Diese Art von Dateiserver wird als Scale-Out File Server bezeichnet. Sollte einer der beiden Server ausfallen, übernimmt der zweite Server den kompletten Betrieb alleine. Dieser Vorgang ist vollständig transparent, es kommt zu keiner Kommunikationsunterbrechung zwischen dem Dateiserver und den angeschlossenen Hyper-V Hosts. Voraussetzung für die Nutzung dieser Technik auf Seiten der Virtualisierungs-Hosts ist mindestens ein Windows Server 2012, absolut empfohlen ist allerdings die Nutzung von Windows Server 2012 R2, da hier einige Änderungen und Verbesserungen in das Produkt eingeflossen sind.

Die Installation der beiden Server wird über einen kleinen Wizard gestartet, hier werden grundsätzliche Informationen wie Name, Kennwort und IP-Adresse abgefragt. Nach der Installation sind beide Systeme per Remote Desktop zu erreichen und können entweder manuell oder über den im Betriebssystem enthaltenen Assistenten administriert werden.

Der Storage kann über das Violin Control Utility administriert werden. Das Programm selbst hat wenig Konfigurationsmöglichkeiten, Sie können lediglich vorhandene LUNs löschen oder neue anlegen. Sichtbar sind noch weitere Informationen über die Controller und die Art von Speicher, hier können aber keine Änderungen vorgenommen werden. Alle erstellten LUNs sind immer beiden Servern zugewiesen, nach dem Anlegen können Sie die Datenträger in der Datenträgerverwaltung sehen und verwalten. Negativ fällt auf, dass keine Möglichkeit zur Größenänderung der LUNs vorhanden ist.

Einen generellen Überblick über das gesamte System erhalten Sie über die Weboberfläche. Diese ist über einen Webbrowser erreichbar und zeigt einige Informationen über das System an.

Zusätzlich können über den Bereich Administration noch weitere Aufgaben ausgeführt werden, z.B. ein Neustart des Systems, eine Anpassung von IP-Adressen oder die Anzeige der Logdatei.

Die Konsole macht einen sehr aufgeräumten Eindruck und zeigt sehr schnell einige Informationen über den aktuellen Betriebsstatus an.

SMB Direct

Die in dem Testsystem verbauten 10 GbE-Karten sind RDMA-fähig. Dies bedeutet, dass bei einer Kommunikation zwischen dem SMB-Server (in diesem Fall einer der beiden Scale-Out File Server Knoten) und einem SMB-Client (Verwechseln Sie Client nicht mit einem „normalen“ Client, in diesem Fall ist mit SMB-Client ein Hyper-V Host gemeint) eine sehr hohe Bandbreite bei einer sehr geringen Latenz erreicht werden kann. Dies liegt daran, dass ein SMB-Client die Daten auf dem Datei-Server direkt in seinen Arbeitsspeicher liest. Da bei dieser Aktion weder die CPU des Datei-Servers noch die CPU des SMB-Clients (in diesem Fall des Hyper-V Hosts) genutzt werden muss, stehen beiden Systemen diese Ressourcen für andere Aufgaben zur Verfügung. Auf Seiten des Dateiservers ist dies z.B die Bearbeitung von Nicht-RDMA-Traffic, auf Seiten des Hypervisor führt dies unter anderem zu einer Erhöhung der VM-Anzahl, die Sie auf diesem System betreiben können.

Die hier genutzten Karten nutzen die iWARP-Technik. Vorteil dieser RDMA-Variante (z.B. gegenüber der RoCE-Variante) ist, dass auf Seiten der Switches keine weitere Konfiguration vorgenommen werden muss. Bei der Einrichtung ist darauf zu achten, dass für die 10 GbE-Karten kein Team konfiguriert werden darf. Sobald ein Adapter Mitglied in einem Team ist, steht die RDMA-Funktionalität nicht mehr zur Verfügung. Da in den Hyper-V Hosts jeweils nur zwei Ports mit iWARP-Technik zur Verfügung stehen, werden im Dateiserver-Failover Cluster ebenfalls nur zwei der vier möglichen Ports pro Server genutzt.

Das System unter Last

Um die Performance des Systems unter Last zu sehen, wurde ein Scale-Out File Server mit insgesamt fünf Datenträgern angelegt. Drei der Datenträger spielen bei der Betrachtung der Leistung keine Rolle, da einer dieser Datenträger ausschließlich als Datenträgerzeuge im Quorum verwendet wurde und die anderen beiden nicht benötigt werden (Anmerkung: Zwei jeweils 10 TB große Datenträger reichen aus, um pro Datenträger über 1200 Instanzen der Benchmark-VM zu speichern). Die anderen beiden Datenträger wurden als Cluster Shared Volume konfiguriert, jeder dieser Datenträger bietet ebenfalls eine Speicherkapazität von 10 TB.

Auf Seite der Hyper-V Hosts wurden acht Systeme ohne RDMA-Karten sowie zwei Systeme mit RDMA-Karten genutzt, um Last auf dem Storage zu erzeugen. Pro Host laufen VMs, in denen das SQLIO-Programm von Microsoft für eine Belastung sorgt. Zeitweise sorgen insgesamt 440 dieser VMs für eine Belastung von Netzwerk und Storage. Die Nicht-RDMA-Systeme sind Schulungsrechner mit einem Intel Core i5-2400S bzw. einem Intel Core i7-3770, 24 bzw. 32 GB RAM, zwei 1 Gb/s Karten sowie einer Intel X540-T2 Karte mit zwei 10 Gb/s-Ports. Bei den RDMA-Systemen handelt es sich um Cisco Server mit zwei Intel E5-2650 CPUs, 128 GB RAM, vier 1 Gb/s Ports sowie einer Chelsio T420-BT Karte mit zwei 10 Gb/s-Ports.

In jeder VM wird nach dem Start automatisiert eine SQLIO-Instanz gestartet, die von einer zentralen Freigabe eine Konfigurations-Datei herunterlädt und mit den konfigurierten Werten startet. Pro Durchlauf werden jeweils 60 Sekunden lang die Tests Random Read, Random Write, Sequential Read und Sequential Write durchgeführt. Jeder Durchlauf beinhaltet zwei Schleifen. Nach diesem Durchlauf wartet das Programm eine beliebige Zeit zwischen 0 und 60 Sekunden, bevor der nächste Durchlauf startet. Vor jedem Durchlauf wird die Konfiguration erneut von der zentralen Freigabe heruntergeladen, falls in dieser Zeit Änderungen vorgenommen wurden (z.B. eine Änderung der Block-Größe) werden diese nun angewandt. In dem folgenden Screenshot sehen Sie eine VM, in der ein Test mit einer Blockgröße von 8KB durchgeführt wird.

Laufen alle VMs einige Zeit, verschieben sich durch die Zufalls-Wartezeiten zwischen den einzelnen Durchläufen die Tests so, dass die Belastung nicht immer parallel anliegt, sondern variiert und so eine möglichst reale Umgebung versucht nachzustellen. Durch die Messung einiger aussagekräftiger Leistungsindikatoren in der Windows Leistungsüberwachung über einen gewissen Zeitraum lassen sich so einige Werte ermitteln, die die Performance des Geräts zeigen.

Die Tests in Zahlen

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Die ermittelten Werte zeigen, dass in Summe durchschnittlich fast 180.000 IOPS realisiert werden konnten. Die maximalen Werte liegen sogar noch deutlich höher, hier konnten über 250.000 IOPS gemessen werden. Die gemessenen Größen pro Anfrage zeigen sehr deutlich, dass das SQLIO-Tool wie gewünscht 4KB große Blöcke erzeugt und verarbeitet hat. Die durchschnittliche Zeit pro Anfrage liegt laut Anzeige durchschnittlich bei 1 ms, was bei der großen Anzahl an IOPS und der großen Menge an Anfragen sehr gut ist. Die Höhe des Datendurchsatzes spielt hier eher weniger eine Rolle, trotzdem sind die Daten auch in der Tabelle zu finden.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Bei einer Erhöhung der Blockgröße des SQLIO-Tests auf 8KB zeigt sich, dass die IOPS nur leicht steigen gegenüber den Tests mit 4KB großen Blöcken. Bei diesem und allen anderen Werten (außer den 4K-Werten) muss allerdings zusätzlich beachtet werden, dass die Messung auf den Dateiserver-Knoten in 8KB IOPS durchgeführt werden. Auf dem Violin-System selbst werden die IOPS durchgehend in 4KB gemessen und angezeigt, da hier ausschließlich 4KB große Blöcke verarbeitet werden. Auf Seiten des Storage müssen die hier aufgeführten Werte verdoppelt werden, um einen direkten Vergleich gegenüber dem vorherigen Benchmark mit 4KB zu haben.

Die erreichten Transferraten steigen ebenfalls um knapp das doppelte, hier kann logischerweise mit einer größeren Blockgröße und einer fast gleichen IOPS-Anzahl auch ein höherer Durchsatz erreicht werden. Die Verarbeitungszeit der Daten bleibt weiterhin konstant bei (gerundet) 1ms.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 64KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Durch die Erhöhung der Blockgrößen auf 64 KB zeigt sich eine weitere Verringerung der IOPS auf durchschnittlich knapp 45.000, aber auch eine deutliche Steigerung der Transferraten. Durchschnittlich konnten über beide Freigaben kontinuierlich 2 Gigabyte pro Sekunde verarbeitet werden (sowohl schreibend als auch lesend), zu Spitzenzeiten stieg die Bandbreite auf knapp 3 Gigabyte. Da die Verarbeitung von solch großen Blöcken seine Zeit braucht, stieg die durchschnittliche Bearbeitungszeit pro Paket auf durchschnittlich 15 ms.

Probleme bei der Erzeugung von Last und Grenzen der Testumgebung

Bei der Erzeugung einer möglichst hohen Belastung auf dem Flash-Storage sind wir bei der Menge der VMs (trotz Nutzung von RDMA) an Grenzen gestoßen. Die Nicht-RDMA-fähigen Hyper-V Hosts waren bei der Ausführung von jeweils 20 VMs fast an der Grenze ihrer CPU-Leistung, diese lag durchschnittlich zwischen 80 und 95%. Insgesamt acht Hosts konnten so insgesamt 160 VMs betreiben.

Auf Seiten der Cisco Server mit den verbauten Chelsio T420-BT Karten mussten wir feststellen, dass 50 VMs den Server zu knapp 50% auslasten und je nach Blockgröße für eine Bandbreite zwischen 16 und 18 Gb/s pro Hyper-V Host sorgen. Zwei dieser Systeme konnten so mit 100 VMs Tests auf dem Violin Storage durchführen. Weitere Hyper-V Hosts mit RDMA-fähigen Netzwerkkarten hätten so noch mehr VMs betreiben können, bei denen die Messwerte wahrscheinlich noch weiter gestiegen wären. Hierbei wäre dann allerdings zu beachten, dass die beiden NICs in den Memory Gateways um weitere Karten erweitert werden müssen, da sonst die Anbindung mit 20 Gb/s der Flaschenhals in dem Aufbau ist. Da die Karten logisch in jeweils einem eigenen Subnetz liegen müssen (SMB Multi Channel in einem Failover Cluster funktioniert nur, wenn die Karten logisch getrennt sind), werden auf Seiten der Hyper-V Hosts ebenfalls weitere Karten benötigt. Dies ist einer der vielen Dinge, die während der Planungsphase berücksichtigt werden muss, damit es im späteren Betrieb nicht an „nur“ 20 Gb/s hängt.

Während der Tests hat sich gezeigt, dass ein Betrieb von VMs mit dynamisch erweiterbarer Festplatte die Performance sehr stark (negativ) beeinflusst. VMs sollten ausschließlich mit VHDX-Dateien in einer festen Größe betrieben werden, um hier von vorn herein mögliche Engpässe auszuschließen. Zum Zeitpunkt der Erstellung dieses Tests arbeitet der Hersteller gemeinsam mit Microsoft bereits an einer Best Practise-Beschreibung, die unter anderem diesen Punkt beinhaltet. Weiterhin werden einige weitere Empfehlungen ausgesprochen, die einen Betrieb mit Hyper-V möglichst optimal vorbereiten.

Neben den reinen Messwerten gibt es ja immer auf Seiten des Administrators (bzw. in meinem Fall des Testers) ein Gefühl für den Betrieb, die „gefühlte Geschwindigkeit“. Bei der Arbeit mit dem Violin System habe ich zu keinem Zeitpunkt auf Seiten der Hyper-V Hosts oder der VMs ein Problem in Bezug auf die Performance gehabt. Selbst während einer Belastung des Storage mit 260 VMs, in denen alle die SQLIO-Tests liefen, gab es keine Hänger bei der Arbeit mit einer VM. Alle durchgeführten Aktionen waren gewohnt schnell, z.B. der Start von Programmen, einer Auflistung aller Dateien auf dem Laufwerk C: oder dem Kopieren von Dateien auf ein Netzlaufwerk oder von einem Netzlaufwerk in die entsprechende VM.

Die Nutzung des CSV Block Cache

Ab dem Windows Server 2012 gibt es die Funktion des CSV Block Cache. Bei dieser Technik kann bei der Nutzung von CSV-Datenträgern in einem Failover Cluster ein gewisser Teil des RAMs als Lese-Cache genutzt werden. Unter Windows Server 2012 mussten zur Aktivierung dieser Funktion die Datenträger offline und wieder online genommen wurden. Dies bedeutet, dass die Funktion entweder direkt bei der Installation eingeschaltet werden musste oder im späteren Betrieb eine Downtime geplant werden musste, damit die Funktion nachträglich aktiviert werden konnte. Nach der Aktivierung kann bis zu 20% des verfügbaren Speichers genutzt werden. Die Empfehlung von Microsoft lautet bei Hyper-V Hosts, die Größen allerdings sehr moderat zu setzen und gibt hier Größen von 512MB bis maximal 2GB vor. Bei Scale-Out File Server-Systemen kann eine größere Menge an RAM genutzt werden, hier können problemlos 4GB oder mehr genutzt werden. (Quelle: http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx)

Unter Windows Server 2012 R2 hat sich die Aktivierung und Nutzung dieser Funktion verbessert, dies liegt unter anderem daran, dass die Funktion schon direkt bei der Installation und Einrichtung aktiviert ist, die Größe des zu nutzenden Speichers allerdings bei 0MB liegt. Sie müssen hier nur noch die Größe des Speichers anpassen, ein offline und wieder online schalten und somit ein Ausfall der Systeme auf diesem Volume muss nicht mehr berücksichtigt werden. Bei einem hochverfügbaren Dateiserver unter Windows Server 2012 R2 müssen Sie allerdings beachten, dass die gleichzeitige Nutzung von Tiering und einem CSV Block Cache nicht möglich ist. Sie können diese Funktion zwar aktivieren, es wird allerdings kein RAM als Lesecache genutzt.

Warum erzähle ich Ihnen all diese Informationen? Ganz einfach, in unserem Fall setzen wir mit der Violin einen Scale-Out File Server ein, der nur über eine Art von Speicher verfügt und somit kein Tiering (im deutschen als Speicherebenen bezeichnet) nutzt. Die verbauten VIMMs sind zwar schon unglaublich schnell und haben eine sehr geringe Latenz, allerdings dürfte der in den beiden Servern verbaute RAM noch deutlich schneller sein. Wir aktivieren nun in beiden Systemen jeweils 8GB RAM, starten die Systeme durch und schauen uns an, welche Veränderungen der Benchmark zeigt.

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 4KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Konfiguration:

· Anzahl der VMs: 260 (160 Stück auf Nicht-RDMA-Hosts, 100 auf zwei RDMA-Host)

· Anzahl der Hosts: 10

· SQLIO-Einstellungen

o Loops: 2

o Laufzeit: 60 Sekunden

o Blocksize: 8KB

o Threads: 2

o Queue Depth: 8

Ergebnisse (Messung der Performance über 30 Minuten auf beiden Systemen des Dateiserver-Failover Cluster):

Fazit zur Nutzung des CSV Block Cache

Nach der Aktivierung des CSV Block Cache zeigte sich ein interessantes Verhalten: Bei Blockgrößen von 4KB und 8KB sanken die Daten fast komplett ein, nahezu alle Messwerte waren mit aktiviertem CSV Block Cache deutlich schlechter als ohne. Bei einer Blockgröße von 64KB waren die Unterschiede nicht mehr messbar, beide Tests zeigten annährend gleiche Werte. Interessant sind auch die Zugriffszeiten mit und ohne aktivierten CSV Block Cache: Während bei deaktiviertem Cache die Zugriffszeiten (bei 4KB und 8KB) konstant bei 1ms liegen, variieren diese mit aktiviertem Cache bei zwischen 0ms (bzw. nicht messbar durch den Performance Monitor) und 8ms.

Der Vergleich der jeweiligen Benchmarks zeigt direkt eine absolute Empfehlung: Schalten Sie den CSV Block Cache nicht ein. Die Aktivierung verschlechtert die Leistung signifikant.

Quellen:

http://blogs.technet.com/b/storageserver/archive/2014/04/22/violin-and-microsoft-jointly-develop-a-high-performance-all-flash-enterprise-storage-appliance-powered-by-windows-storage-server-2012-r2.aspx

http://www.chelsio.com/nic/t5-unified-wire-adapters/t520-cr/

http://pull.vmem.com/wp-content/uploads/techoverview-federal.pdf

http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx (CSV Block Cache)

Der Beitrag Test: Violin 6000 All Flash Array erschien zuerst auf Hyper-V Server Blog.