Quantcast
Channel: Petra Lipp, Autor auf Hyper-V Server Blog
Viewing all 47 articles
Browse latest View live

Live Migration – Error 21502

$
0
0

Eine altbekannte Fehlermeldung in neuer Umgebung.
Bei Tests mit der VMGroup im FailoverCluster 2016 bin ich einmal mehr bei der Live Migration einer VM auf dem Error 21502 gestoßen.

Die VM hatte ich vor der Live Migration der VMGroup “Hyper-V Collection” hinzugefügt und auch wieder entfernt. Bei der Abfrage ob die VM einer VMGroup angehört wurde mir keine VMGroup angezeigt.

Dennoch schlägt die Live Migration fehl und zeigt an, dass die VM noch einer VMGruop angehört. Jetzt ist guter Rat teuer – wo steht diese Info hab ich mich gefragt. Bei den Eigenschaften der VM finde ich ja dazu nichts mehr. Nun, so dachte ich mir ich nehme die VM mal aus dem Failover Cluster und schau was der Hyper-V Manager bei der Live Migration macht. Gedacht getan und wie so oft ist hier das Verhalten ein anderes wie im Failover Cluster.
Ich rufe über den Hyper-V Manager den Wizard für die Live Migration auf und klicke die einzelnen Schritte durch – verschiebe die VM – wähle meinen Zielserver aus – verschiebe nur die VM ………
hier die Zusammenfassung der ausgewählten Optionen:

Es dauert kurz und dann zeigt mit der Hyper-V Manager ebenfalls an, dass hier noch verweise VMGroup Mitgliedschaften vorhanden sind, doch jetzt kann ich auswählen, dass diese verwaisten VMGroup Mitgliedschaften entfernt werden sollen.

Wieder wird eine kurze Zusammenfassung angezeigt und im Anschluss funktioniert die Live Migration der VM wieder einwandfrei – auch nachdem ich die VM wieder im Failover Cluster hochverfügbar gemacht habe.
Viel Spaß und weiterhin viel Erfolg

Der Beitrag Live Migration – Error 21502 erschien zuerst auf Hyper-V Server Blog.


SCOM 2016 – Management Pack für Storage Spaces Direct

$
0
0

Zu den vielen Neuerungen im Windows Server 2016 gehört auch Storage Spaces Direct. Nun werden wir in Kunden Projekten immer wieder gefragt wie sich diese Umgebung Monitoren lässt. Ich möchte euch die Möglichkeit des Monitorings der Storage Spaces Direct Umgebung anhand des neuen Manangement Pack für Storage Spaces Direct für den System Center Operations Manager 2016 (SCOM) vorstellen.

Über diesen Link könnt ihr das Management Pack für Storage Spaces Direct herunterladen. Das Download enthält zwei Dateien:

  • “Microsoft System Center 2016 MP for Storage Spaces Direct.msi” “
  • “MS Server 2016 Storage Spaces Direct MP Guide.docx”

Die aktuelle Version des Management Packs ist:

Werfen wir noch einen Blick in das Worddokument und vergewissern uns, dass alle Voraussetzungen für die Installation das Storage Spaces Direct Management Pack erfüllt sind.

In unserer Umgebung setzen wir einen System Center Operations Management Server 2016 mit Update Rollup 2 und den akutellen Windows Patches ein. Mit diesem Management Pack für Storage Spaces Direct möchten wir unseren 2 Knoten Storage Spaces Direct Hyper-converged Cluster überwachen.

Wir installieren die .MSI – Datei auf unserem System Center Operations Management Server. Im Anschluss importieren wir den Storage Spaces Direct Management Pack in der System Center Operations Management Konsole wie folgt:

 

Der Management Pack für Storage Spaces besteht aus vier Management Pack Dateien die wir alle markieren und importieren.

Sollten Management Packs fehlen, die für diesen Management Pack benötigt werden,  wird dies durch das System angezeigt und die fehlenden Management Packs können mit installiert werden.  Nach erfolgreicher Installation können wir uns nun anschauen, was der Management Pack für die Storage Spaces Direct alles beinhaltet.

Im Bereich des Monitoring unter der Gruppe “Storage” wurde die neue Gruppe “Storage Spaces Direct 2016” angelegt. Diese Gruppe enthält bereits nützliche Tools um einen schnellen Überblick über den Zustand unserer Storage Spaces Direct Umgebung zu bekommen. Wir werden uns diese jetzt im Einzelnen näher anschauen. Doch hier einmal die Übersicht.

Unter  “Active Alerts” werden alle Meldungen angezeigt die durch dem Management Pack für Storage Spaces Direct 2016 erzeugt werden. Um Alerts zu erhalten habe ich mal einen der S2D-Knoten heruntergefahren.

Nun welche Meldungen werden uns hier angezeigt?

unter “Critical” wird uns gezeigt dass der Server S2D1 nicht erreichbar ist  – genau diesen habe ich für unser Beispiel herunter gefahren. Diese Meldung wird geschlossen sobald der Server wieder erreichbar ist.

bei “Warning” werden wir darüber informiert, dass auf unseren drei Cluster Shared Volumes nicht alle Daten voll redundant sind. Auch das ist korrekt, da durch das herunterfahren des S2D1 Servers die lokalen Festplatten des Server, die ja auch dem Storage Pool “S2D-Cluster” zugewiesen wurden im Moment nicht zur Verfügung stehen. Auch diese Warnmeldungen werden nachdem die Daten wieder voll redundant sind automatisch geschlossen.

bei “Information” bekommen wir mitgeteilt, dass für den Restore der bis dahin erzeugten Daten, bereits drei Jobs (für jedes CSV einer) darauf warten die Daten auf die dann wieder zur Verfügung stehenden Festplatten zu schreiben. Diese Informationsmeldungen bleiben stehen und müssen manuell geschlossen werden.

Als nächstes werfen wir einen kurzen Blick in die “Active Faults” – wie der Name schon sagt, werden uns hier nur die aktiven Fehler des überwachten Storage Spaces Direct Clusters angezeigt.

Es sind die gleichen Meldungen, die wir bereits bei den “Active Alerts” gesehen haben mit dem Unterschied, dass die Informations Meldungen fehlen – klar das sind ja keine Fehler.

Für alle, die die Alerts Sammlung anpassen möchten, das geht per rechts Klick über die Properties bzw. Eigenschaften. Ich zeige euch kurz was als Standard bei den “Active Faults” eingestellt ist. Über den Punkt “Display” können die Spalten ausgewählt werden, deren Informationen im Überblick mit angezeigt werden sollen.

Unter “File Shares”  werden die Freigaben angezeigt die bei einem Storage Spaces Direct System mit der SOFS-Rolle angelegt wurden. Da wir ein Hyper-converged System haben – d. h. die Hyper-V Rolle ist direkt auf diesem System installiert – können wir keine SOFS-Freigaben anlegen und somit ist diese Ansicht bei uns leer.

“Ongoing Jobs” ist der nächste Punkt auf unserer Übersicht – wir können uns hier schnell einen Überblick verschaffen, ob auf unserem Storage Spaces Direct System Restore Jobs anstehen bzw. gelaufen sind – den wie bereits unter “Active Alerts” beschrieben, werden diese Infos nicht automatisch geschlossen, wenn die Jobs abgearbeitet wurden.

Unter “Performance” können jede Menge Performance Counter ausgewählt werden – die uns je nach Anforderung Auskunft über den Zustand des Storage Spaces Direct System geben können. Als Beispiel habe ich mal die IOPS Total und IOPS Write für die Darstellung ausgewählt. Im zweiten Bild sind alle Performance Counter aufgelistet die zur Verfügung stehen. Die Performance Counter für das Volume steht natürlich für jedes angelegt CSV Volume zur Verfügung.

Beim Blick auf das Dashboard “Storage Spaces Direct 2016” bekommen wir einen guten Überblick über den Zustand der Storage Spaces Direct Umgebung – im Augenblick ist alles auf “Critical”. Der weitere Bildausschnitt zeigt noch einen detaillierteren Überblick über das System.

Im Detailüberblick werden uns unter Monitoring auch Performance Werte mit angezeigt. Ich habe in der  Zwischenzeit den S2D Node  wieder gestart und so können wir uns die Werte ansehen, wenn alles im grünen Bereich liegt :-) .

Unter “Storage Subsystems” wird uns der Zustand des Storage Pools angezeigt. Leider nicht mehr  – so bekommen wir keine Informationen darüber, welche Festplatten dem Pool zugeordnet sind (Typ, Fabrikat, Größe usw.), noch in welchem Status sich die Festplatten befinden. All diese Daten stehen im Failover Cluster Manager zur Verfügung. Da bedarf es wohl noch einiger Erweiterungen des Management Packs oder man muss auf Management Packs der Hardware Hersteller zurück greifen.

“Volumes” ist der letzte Punkt in unserer Übersicht – hier wird uns der Status unser Cluster Shared Volumes (CSV) angezeigt.  Auch hier fehlt jede weitere Info, z.B. wie viel Speicherplatz steht noch zur Verfügung usw.

Damit wären wir am Ende der Übersicht – ich denke wir bekommen schon eine ganze Menge angezeigt über diesen neuen Management Pack für Storage Spaces Direct – doch einige wichtige Punkte fehlen mir noch in dem Monitoring. So werden gerade in unserer Umgebung auch die Virtuellen Maschinen nicht mit überwacht. Wir erinnern uns beim Storage Spaces Cluster musste der System Center Virtual Machine Manger dazwischen geschaltet werden damit dieser überwacht werden konnte. Das fällt bei dem neuen Storage Spaces Direct Management Pack weg.

Ich werde mich bei Gelegenheit auf die Suche machen, mit welchen weiteren Management Packs das Storage Spaces Direct Cluster noch besser überwacht werden kann. Bis dahin

Viel Spaß

Der Beitrag SCOM 2016 – Management Pack für Storage Spaces Direct erschien zuerst auf Hyper-V Server Blog.

Umzug eines bestehenden Storage Spaces Direct Clusters mit Daten in eine neue Domain

$
0
0

​In Vorbereitung für unseren S2D Powerkurs, sahen wir uns vor der Aufgabe unser bestehendes Storage Spaces Direct Hyper-converged Cluster ​von unserer Rachfahl Domain in die Powerkurs Domain umzuziehen. Natürlich sollten die Daten, heißt die VMs die bereits auf dem Storage Spaces Direct Hyper-converged Cluster liefen mit umziehen. Das war der Plan und der Wunsch. Ich möchte nun beschreiben wie wir vorgegangen sind um dieses Ziel zu erreichen.

  • ​​Alle VMs werden heruntergefahren und aus dem Failover Cluster entfernt. Dadurch werden die VMs nicht gelöscht, wir löschen lediglich die Hochverfügbarkeit der VMs durch diesen Schritt.


  • ​​Die Cluster Shared Volumes (CSVs)  werden aus dem Failover Cluster entfernt. In unserem Fall sind es drei Cluster Shared Volumes (CSVs) die entfernt werden müssen.

Danach werden die Disks im Failover Cluster Manager "nur noch" als Verfügbarer Speicher angezeigt und können auch aus dem Cluster entfernt werden. 

  • ​Im nächsten Schritt müssen die "Cluster Virtual Disks" aus dem Failover Cluster entfernt werden, das kann über die GUI oder mit folgendem PowerShell Befehl erfolgen. Mit dem ersten PowerShell Befehl zeigen wir uns die Cluster Festplatten an. "Get-ClusterResource | where ResourceType -eq 'Physical Disk' "  und mit dem zweiten PowerShell Befehl löschen wir die Cluster Festplatten. " Get-ClusterResource | where ResourceType -eq 'Physical Disk' | Remove-ClusterResource -Force "  ​


  • ​Mit dem PowerShell Befehl "Disable-ClusterS2D -Confirm:$false -verbose" ​ entfernen wir den SoftwareStorageBus und können im nachfolgenden Schritt das Failover Cluster abbauen. Es bleiben die Daten und die StoragePool Informationen die auf den Festplatten gespeichert sind, erhalten.


  • ​Jetzt müssen wir den Failover-Cluster abbauen. Das geht am schnellsten über die PowerShell. Wir ​lassen uns das Failover-Cluter mit "Get-Cluster" anzeigen, um sicher zu sein, dass wir das richtige Failover-Cluster löschen und mit "Get-Cluster | Remove-Cluster -force" löschen wir das Failover-Cluster.


  • ​Mit dem PowerShell Befehl  "Get-StoragePool" ​bekommen wir den StoragePool angezeigt. Dieser wird  jetzt als  "Read-only" angezeigt und ​ein Blick auf die Festplatten - dies geht mit dem  PowerShell Befehl "Get-PhysicalDisk" ​zeigt, dass wir nur noch Zugriff auf die lokalen Festplatten des Servers haben, die Festplatten des zweiten Clusterkontens werden ​mit "Lost Communication" angezeigt.
 Get-ClusterResource | where ResourceType -eq 'Physical Disk' | Remove-ClusterResource
  • Wir entfernen die Server aus der Rachfahl Domain. Nach dem Reboot und den notwendigen Netzwerkanpassungen können wir die Server in die Powerkurs Domain aufnehmen.


  • ​In den nächsten Schritten können wir das Storage Spaces Direct hyper-converged Cluster wieder aufbauen. ​Dazu führen wir einen Cluster Test durch. Der PowerShell Befehl hierfür lautet: "$ClusterNodes = @('DellS2D1';'DellS2D2')"   "Test-Cluster -node $ClusterNodes -Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration" -Verbose"  Mit dem Parameter "Verbose" bekommen wir eine detailierte Auflistung aller Schritte, die mit dem PowerShell Befehl ausgeführt werden, dies kann bei Fehlern sehr hilfreich sein. In unserem Falle ​sind alle Tests erfolgreich bis auf dem "Software Update Level", dieser wird mit einer Warnung abgeschlossen, damit steht dem Neuaufbau des Failover Clusters nichts mehr im Wege.
$ClusterNodes = @('DellS2D1';'DellS2D2')
  • ​Wir bauen unser Failover Cluster über PowerShell auf. Dazu führen wir folgenden PowerShell Befehl aus: "New-Cluster -Name 'DellS2DCluster' -NoStorage -StaticAddress '​192.168.209.80' -IgnoreNetwork '192.168.207.0/24' , '192.168.206.0/24' -Verbose" ​. Die beiden Netzwerke die wir ignorieren, sind bei uns die SMB Netze.
  • Nachdem wir das Failover-Cluster erfolgreich konfiguriert haben, sehen wir jetzt bereits ​unseren StoragePool und die Cluster Festplatten, können aber noch nicht darauf zugreifen. Daher müssen wir jetzt den SoftwareStorageBus wieder installieren. Wir erinnern uns, den haben wir bei Abbau des Clusters ​über den PowerShell Befehl "Disable-ClusterS2D" deinstalliert. Nun müssen wir​ diesen ​wieder installieren um auf alle Festplatten in beiden Servern zugreifen zu können. Dies ​erfolg​t mit dem PowerShell Befehl: "​Enable-ClusterS2D -Autoconfig $false -Verbose". Den Parameter "Autoconfig" setzen wir auf $false, weil wir in diesem Schritt nur den SoftwareStorageBus installieren möchten, die Konfiguration ist ja noch da. ​


  • ​ In unserem Falle, möchten wir dem StoragePool einen neuen Namen geben, daher führen wir folgenden PowerShell Befehl aus. "Set-StoragePool -newFriendlyName 'S2D on DellS2DCluster' -Friendlyname 'S2D on S2DCluster' " ​
Enable-ClusterS2D -Autoconfig $false -Verbose
  • ​Wir müssen die Cluster Festplatten noch zu in Cluster Shared Volumes umwandeln, das geht mit folgendem PowerShell Befehl "Get-ClusterResource | Where ResourceType -eq 'Physical Disk' | Add-ClusterSharedVolume"​ aber natürlich auch über die GUI im Failover Cluster Manager.
  • Über den Failover Cluster Manager passen wir jetzt noch die Namen der Cluster Shared Volumes an. Wir benennen die CSV genau gleich wie in der vorherigen Installation.
  • ​​Es fehlt jetzt nur noch, dass wir auch den Namen des MountPoints unter C:ClusterStorage.... für das Cluster Shared Volume anpassen. Dieser Name ​sollte wieder genauso heißen, wie in unser vorherigen Umgebung, damit wir unsere VMs ohne Probleme​ starten können. Wir können den Namen des MountPoints über den DateiExplorer anpassen oder ​mit der PowerShell. ​Zuerst fragen wir die CSVs ab  "$CSVs=Get-ClusterSharedVolume"  und im Anschluss benennen wir die MountPoints in einer Schleife so, wie wir die CSVs im Failover Cluster Manager benannt haben. "ForEach ($CSV in $CSVs) { Rename-Item -Path ($CSV.SharedVolumeInfo.FriendlyVolumeName) -NewName $CSV.Name}

Mit den beschriebenen Schritten haben wir unser Storage Spaces Direct Hyper-convered Cluster erfolgreich in die PowerKurs Domain umgezogen. Es versteht sich von selbst, dass ​ vorher immer eine Sicherung der VMs erfolgen sollte und solche Aktionen nur mit äußerster Vorsicht durch zuführen sind. Jeder ist selbst dafür verantwortlich und wir übernehmen keine Gewähr dafür, dass dieser Umzug auch bei ​dir erfolgreich ist.

[…]

Der Beitrag Umzug eines bestehenden Storage Spaces Direct Clusters mit Daten in eine neue Domain erschien zuerst auf Hyper-V Server Blog.

Vorsicht beim Oktober Patch 2017 KB4041691

$
0
0

​Bitte den Oktober Patch 2017 KB4041691 nur nach intensiven Tests installieren. Es häufen sich gerade die Berichte, dass es beim Booten der VMs mit Windows 10 und Windows Server 2016 zu Problemen kommt. Sobald wir näheres wissen werden wir es an dieser Stelle veröffentlichen.

​Update:

Unser MVP Kollege Didier Van Hoye hat auf seinem Blog einen ausführliche Analyse des Problems und eine Fehlerbehebung gepostet!

Der Beitrag Vorsicht beim Oktober Patch 2017 KB4041691 erschien zuerst auf Hyper-V Server Blog.

SCVMM 2016 – Probleme beim Erstellen eines Switch Embedded Teams

$
0
0

​In eine Kundenprojekt sollte ich mit dem SCVMM 2016 ein SET Team an den Hyper-V Hosts eines Failover Clusters erstellen. Eigentlich eine einfache Sache - doch dann waren im SCVMM 2016 plötzlich die NICs die zum SET Team gehör​ten ​verschwunden........

​​Für das SET Team habe ich folgenden Uplink Port im SCVMM 2016 konfiguriert.

​.... und im Anschluß daran ​den logischen Switch mit den folgenden Einstellungen.

​In nächsten Schritt, habe ich das Uplink Portprofil für das SET Team ausgewählt und die in unserer Umgebung erforderlichen vNICs erstellt.

​unser Hyper-V Failover Cluster ist bereits im SCVMM 2016 importiert und so können wir direkt über die Eigenschaften des Hyper-V Hosts unter "Virtual Switches" das SET Team mit den vNICs anlegen.

​das hat auch alles ohne Fehlermeldung geklappt, doch sobald der SCVMM 2016 die Konfiguration der Hyper-V Hosts neu einliest, fehlen pötzlich die Netzwerkkarten im SET Team.

​beim Blick auf den Hyper-V Host ist alles okay, dort sind die NICs dem SET Team zugewiesen. Warum also hat der SCVMM 2016 in seiner Konfiguration keine Netzwerkkarten mehr?

​Es hat mich einige Zeit gekostet bis ich es gesehen habe, dass die Netzwerkkarten die der Powershell Befehl

"Get-VMSwitchTeam"

anzeigt, ​nicht den gleichen Namen haben, wie ​in der Netzwerk Umgebung der "Device Name" der Netzwerkkarten. Das genau ist das Probelm, denn der SCVMM 2016 arbeitet mit dem "Device Name" und verliert so die Netzwerkkarten nach der Aktualisierung, da er diese über den "Device Name" nicht mehr findet​. Dieses Problem ist mir bei den HP Servern ​aufgetreten und es gibt hierzu auch von HP einen Hinweis unter folgenden Link. Wir haben in unserem Projekt die Netzwerkkarten in Mellanox Karten getauscht, bei denen trat das Problem nicht auf.

Vielleicht hilft ja Betroffenen mit Qlogic Netzerkkarten der folgende ​Link weiter. Ich habe die Empfehlungen dort allerdings nicht getestet und kann nur hoffen, dass die Treiber das Probelm beheben.

​dann viel Erfolg und bis bald wieder

Petra

[…]

Den Pfad zu einer Parent Disk anpassen

$
0
0

Vorlage-Button-WinServ2012R2_thumb.jpgVor Kurzem stand ich vor der Aufgabe, die Pfade der Parent Disk für die Differencing Disks von VMs, anpassen zu müssen.

Warum ich das machen musste ist einfach erklärt, ich hatte ein PDT Testdeployment lokal auf einem Hyper-V Host installiert. Im Anschluss daran sollten alle VMs in ein Hyper-V 2012 R2 Failovercluster aufgenommen werden. Nun lag aber die Parent Disk der VMs auf der lokalen Festplatte des Hyper-V Hosts. Aus diesem Grund musste ich auch die ParentDisk auf das CSV kopieren und den Pfad zur Parent Disk bei den VMs anpassen.

Mein erster Gedanke war – das müsste unter den VM-Settings\Hard Drive\…. möglich sein.

Doch “Edit” ist deaktiviert und bei “Inspect” konnte ich mir zwar die Verknüpfungen zu der Parent Disk anschauen, jedoch existierte keine Möglichkeit etwas anzupassen.

Meine nächste Idee war die Konfigdatei der VM. Hier möchte ich anmerken, dass diese nie manuell angepasst werden sollte! Aber in meiner Testumgebung wollte ich zumindest ausprobieren, ob es möglich ist. Ich durchsuchte die ganze Datei, aber auch hier konnte ich keinen Pfad oder Hinweis auf die Parent Disk finden. Zugegeben, so langsam gingen mir die Ideen aus. Es musste doch möglich sein diesen Pfad anzupassen!

Die einzige Möglichkeit die mir noch einfiel, war das Laufwerk auf dem die Parent Disk lag offline zu schalten und zu schauen was passiert. Gedacht, getan; ich schaltete das Laufwerk im Diskmanager offline und sah mir die Settings der VM an.

Und siehe da, jetzt wurde ein “Reconnect” Button angezeigt. Super, nun war ich in der Lage den neuen Pfad für die Parent Disk einzugeben. Dazu waren die folgenden Schritte notwendig:

An dieser Stelle konnte nun der neue Pfad für die Parent Disk eingegeben werden.

Hier unbedingt darauf achten, dass es die richtige Parent Disk ist, die Ihr hinzufügt. Sonst kann es passieren, dass die VM nicht mehr startet.

So erledigt – jetzt war ich in der Lage meine VMs wie gewünscht ins Failovercluster aufzunehmen.

Der Beitrag Den Pfad zu einer Parent Disk anpassen erschien zuerst auf Hyper-V Server Blog.

Live Migration schlägt mit Event ID: 21502 fehl

$
0
0

Vorlage-Button-WinServ2012R2_thumb.jpgWir hatten heute bei unserem Hyper-V 2012 R2 Failovercluster das Problem, dass wir die Live Migration nur noch von einem Host aus durchführen konnten, beim zweiten Hyper-v Host bekamen wir folgende Fehlermeldung:

Unsere VMs liegen auf einem Scale Out File Server Cluster (SOFS) Share.

Die Live Migration Settings sind: Kerberos und SMB.

 

Im ersten Schritt habe ich die Live Migration Settings auf Kerberos und Kompression umgestellt, um ein Problem im SMB Netzwerk auszuschließen. Die Fehlermeldung bei der Live Migration war dieselbe.

Bei meiner weiteren Fehlersuche habe ich folgenden Blogbeitrag gefunden,

http://blogs.technet.com/b/roplatforms/archive/2012/10/16/shared-nothing-migration-fails-0x8007274c.aspx

diesen bin ich Schritt für Schritt durchgegangen und bei dem Hinweis auf den Port 6600 fündig geworden.

Nach dem Aufruf des Befehls netstat –a auf dem betroffenen Hyper-V Host, wurde der Port 6600 nicht aufgeführt. Daraufhin habe ich an beiden Hyper-V Knoten den Dienst Hyper-V Virtual Machine Management (vmms) neu gestartet und siehe da, der wiederholte Aufruf von netstat – a zeigt, dass der Port 6600 jetzt bei den beiden SMB Netzen und am Management Netz auf Listening steht.

Die Live Migration funktionierte danach wieder in beide Richtungen. Das Ganze habe ich noch mit den ursprünglichen Live Migration Settings getestet; der Fehler ist nicht mehr aufgetreten. Auch ein Neustart der beiden Hyper-V Hosts blieb ohne negative Auswirkungen.

Der Beitrag Live Migration schlägt mit Event ID: 21502 fehl erschien zuerst auf Hyper-V Server Blog.

Scale-Out File Server zum SCVMM 2012 R2 hinzufügen

$
0
0

images1

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

Der Beitrag Scale-Out File Server zum SCVMM 2012 R2 hinzufügen erschien zuerst auf Hyper-V Server Blog.


Bechtle-Workshop – MVP-Day Meet the Experts – Carsten spricht zum Thema S2D

$
0
0

Der kostenlose MVP-Day Meet Experts findet in drei Städten statt:

Da heißt es schnell sein, wer Interesse an diesen interessanten und informativen Workshop Tag hat kann sich hier anmelden

das sind die Workshop-Inhalte:

  • Windows Server 2016 Datacenter als Plattform für hyperkonvergente Infrastrukturen.
  • Windows Server Software-defined – die PRIMEFLEX Lösungen von Fujitsu.
  • Storage Spaces Direct – Planung, Konfiguration, Ausfallszenarien, Monitoring und Lizenzierung.
  • Aus der Praxis für die Praxis.

hier haben Sie die Möglichkeit Carsten zum Thema Storage Spaces Direct zu hören und ihn im Anschluss daran auch in einem persönlichen Gespräch ihre Fragen zu stellen. 

Der Beitrag Bechtle-Workshop – MVP-Day Meet the Experts – Carsten spricht zum Thema S2D erschien zuerst auf Hyper-V Server Blog.

Teil 1 – Was ist Storage Spaces Direct?

$
0
0

Hallo Zusammen,


wir haben beschlossen eine Blogpostserie über Storage Spaces Direct (S2D) zu schreiben. Ziel der Serie soll es sein euch alle Infos über Storage Spaces Direct in kompakter Form aufzubereiten. Teil 1 beginnt mit einer kurzen Erläuterung was ist Storage Spaces Direct.

Bisher erschienene Beträge zu dieser Serie:


Storage Spaces wurde erstmals von Microsoft mit Windows Server 2012 eingeführt und zwar mit der Scale Out File (SOFS) Server Rolle. Die Anbindung des Storage kann über SAS, iSCSI oder FibreChanel erfolgen. Die Scale Out File Serverrolle stellt über Dateifreigaben, die speziell für Hyper-V und SQL Server Daten entwickelt wurden, den Speicherplatz zur Verfügung. Die Kommunikation zum Hyper-V Failover Cluster bzw. zum SQL Server erfolgt über Ethernet mit dem SBM 3 Multichannel Protokoll. Bei Storage Spaces Direct wird das Storage mit lokalen Festplatten zur Verfügung gestellt. Dies wird durch den neu entwickelten Software Storage Bus ermöglicht.


Was ist Storage Spaces Direct?

  • Storage Spacaes Direct ist eine Software-defined, Shared-nothing Storage Lösung auf Basis von Windows Server 2016.
  • sie ist Hochverfügbar durch die Nutzung des Failover Cluster Features im Windows Server 2016.
  • Nutzt Industrie Standard Server Hardware
    • Unterstütze Festplatten Typen: SAS, SATA, NVMe
  • kann gut skaliert werden, indem einfach ein weiterer Server hinzugefügt wird (Scale-Out).
  • es wurde für Hyper-V und SQL -Server Daten entwickelt

Welche Einsatzmöglichkeiten gibt es? 

Für Storage Spaces Direct gibt es zwei Deployment Szenarien entweder hyper-converged oder converged. wir müssen uns bei der Planung für eines der beiden unterstützen Deployment Szenario entscheiden, beides zusammen kann nicht auf der selben Hardware betrieben werden. 

Hyper-converged:

beim hyper-converged Ansatz wird das Storage Spaces Direct Failover Cluster zusammen mit der Hyper-V Rolle betrieben. Das heißt:

  • Storage und Hypervisor nutzen die gleichen Ressourcen
  • VMs werden auf dem lokalen Storage System abgespeichert. „C:\ClusterStorage\..."
  • Einfaches Management und Deployment
  • Die notwendige Windows Server 2016 DataCenter Edition Lizenz kann sowohl für Storage wie auch für die VMs genutzt werden
Converged:

beim converged Ansatz werden das Storage Spaces Direct Failover Cluster in Verbindung mit der Scale Out File Server Rolle betrieben. 

  • Für die Virtualisierung und für das Storage muss jeweils ein separater Failover Cluster aufgebaut werden. Die VM Daten werden dann auf dem Storage Spaces Direct Failover Cluster in sogenannten Applikations Freigaben abgelegt.
  • Storage und Hypervisor Ressourcen können je nach Anforderung unabhängig voneinander erweitert werden.
  • Die notwendigen Windows Server 2016 Datacenter Lizenzen werden hier sowohl für den Storage Spaces Direct Failover Cluster als auch für den Hyper-V Failover Cluster benötigt

Wie funktioniert Storage Spaces Direct?

Storage Spaces Direct ist eine Weiterentwicklung der Storage Spaces, die bereits mit Windows Server 2012 als Feature zur Verfügung gestellt wurden. Storage Spaces Direct nutzt seit langem bekannte Features wie Failover Clustering, Cluster Shared Volume (CSV), SMB 3 und SMB Direct, Storage Spaces und beinhaltet viele neue Technologien wie z.B. den Software Storage Bus.

Der Software Storage Bus erstellt innerhalb des Failover Clusters eine software-defined Storage Fabric, die es dem Cluster ermöglicht, die lokalen Festplatten jedes einzelnen Clusterknotens zu sehen.

Dies erfordert hohe Sicherheits- und Performanceansprüche an die Netzwerkkommunikation zwischen den einzelnen Failover Clusterknoten. Storage Spaces Direct nutzt das SMB3 Protokoll - beinhaltet SMB Direct und SMB Multichannel -  für die Kommunikation zwischen den Storage Spaces Direct Clusterknoten (Ost-West Traffic)  und bei dem converged Design (Nord-Süd Traffic) auch zu den Hyper-V Failover Cluster. 

Die geeigneten lokalen Festplatten der einzelnen Failover Clusterknoten (außer die OS Festplatten) werden bei der Installation des Storage Spaces Direct Clusters in einem Storage Pool zusammen gefasst. Es werden alle geeigneten Festplatten automatisch erkannt und hinzugefügt. Es wird empfohlen nur einen Storage Pool pro Storage Spaces Direct Cluster anzulegen.

Durch das Anlegen des Storage Pools steht dem Failover Cluster nun Storage Speicher (Storage Spaces) zur Verfügung, über den wir virtual Disks für CSVs (Cluster Shared Volume) anlegen können. Für die Ausfallsicherheit der Daten stehen unterschiedliche Fehlertoleranz Modis zur Verfügung (z.B. zwei- und drei Wege Spiegel) (mehr dazu später).

Die virtual Disks können mit CSV-ReFS (empfohlen) oder CSV-NTFS formatiert werden. Resilient File System (ReFS) zeigt seine Stärken besonders in einer Storage Spaces Direct Umgebung. Es ermöglicht schnellere .vhdx-Daiteioperationen wie Erstellung, Erweiterung und Checkpoint Zusammenführung. Es integriert Prüfsummen zum erkennen und korrigieren von Bit-Fehlern. Des weiteren wurden Echtzeit-Tiers eingeführt, die "heiße" und "kalte" Daten in Echtzeit umorganisieren können.

Hier grafisch der schematische Aufbau von Storage Spaces Direct. (Quelle)

Im Teil 2 geht es um „Grundlegene Anforderungen für Storage Spaces Direct“

gutes Gelingen und bis zum nächsten Mal 

Petra

Der Beitrag Teil 1 – Was ist Storage Spaces Direct? erschien zuerst auf Hyper-V Server Blog.

Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct

$
0
0

Bisher erschienene Teile der Blogpostserie

In diesem Teil möchte ich ein besonderes Augenmerk auf die Hardwareanforderungen für Storage Spaces Direct legen.

Es ist für den produktiven Betrieb unerlässlich, dass alle Systeme, Komponenten, Geräte und Treiber für Storage Spaces Direct durch Microsoft für den Windows Server 2016 zertifiziert sind.

Unter folgendem Link findet Ihr sogenannte WDDS (Windows Server Software-Defined) Systeme  von verschiedenen Herstellern für Storage Spaces Direct. Die dort aufgeführten Hersteller haben ausgewählte Konfigurationen für Storage Spaces Direct bei Microsoft zertifiziert. Vorteil dieser zertifizierten Systeme ist, diese Server sind getestet und zertifiziert, die Hersteller supporten diese Systeme bei Problemen. Nachteil, es stehen nur bestimmte Konfigurationen zur Verfügung, die nur sehr eingeschränkt, wenn überhaupt angepasst werden können. 

Passt die WDDS Hardware für eure Anforderungen nicht, müsst Ihr die Serversysteme selbst zusammenstellen, dabei ist einiges zu beachten. Oberstes Gebot, alle ausgewählten Komponenten müssen für Windows Server 2016 im Server Catalog und am besten für Software-Defined Data Center (SDDC) Premium oder Standard zertifiziert sein. Die Hersteller müssen die ausgewählten HBAs, Festplatten, NICs usw. in ihren Systemen unterstützen. 

hier zwei Beispiele aus dem Windows Server Catalog mit entsprechender Zertifizierung: 

Im Folgenden möchte ich die einzelnen Komponenten näher betrachten.

Server:

Es können Standard Server mit bis zu max. 100 TB  Devices in einem Server verwendet werden. Storage Spaces Direct kann mit 2 bis max. 16 Servern betrieben werden.

2-Knoten Storage Spaces Direct Failover Cluster:
  • Nur 2-Wege Spiegel
  • 1 Knoten kann ausfallen
3-Knoten Storage Spaces Direct Failover Cluster:
  • 2- Wege und 3-Wege Spiegel (unsere Empfehlung ist immer ein 3 Wege Spiegel einzurichten)
  • 1 Knoten und mehrere Festplatte in einem weiteren Knoten können ausfallen
  • es dürfen gleichzeitig nicht mehr als die Hälfte aller Festplatten (ohne OS Disks) ausfallen. (Diskmajority)
4-Knoten - 16-Knoten Storage Spaces Direct Failover Cluster:
  • 2-Wege und 3-Wege Spiegel (unsere Empfehlung ist immer ein 3 Wege Spiegel einzurichten)
  • Single und Double Parity (auch hier ist unsere Empfehlung mit der Double Parity zu arbeiten)
  • Hybrid Disk (Mirror und Parity)
  • bis zu 2 Knoten können ausfallen oder 2 unterschiedliche Festplatten in unterschiedlichen Servern.
CPU:
  • Mindestanforderung ist eine Intel Nehalem CPU oder ein höherer kompatibler Prozessor. Eine AMD EPYC CPU oder ein höherer kompatibler Prozessor
  • Bei einer Storage Spaces Direct hyper-converged Lösung sollte darauf geachtet werden, dass die CPU den Anforderungen gemäß größer gewählt wird, da hier der Server nicht nur für die Virtualisierung sondern auch für das Storage genügend Performance benötigt.
Arbeitsspeicherbedarf:
  • Pro 1 TB Caching Device müssen 4 GB RAM pro Server zur Verfügung stehen
  • Beispielrechnung:
    2x 3,2 TB Caching Devices => 2 x 3,2 x 4 GB = 25,6 GB RAM
  • Zusätzlich muss der Arbeitsspeicherbedarf für die Server, für die VMs oder SQL Workloads berechnet werden. Beachten Sie bitte auch, dass die Server noch genügend Arbeitsspeicher Reserve haben, um beim Ausfall von Failover Clusterknoten die Workloads dieser Server aufnehmen zu können.
Storage Device Anbindung:

Für Storage Spaces Direct benötigen wir zwingend einen Hostbus Adapter (HBA)

  • Einfacher Pass-Through SAS HBA für SAS und SATA Devices
  • SCSI Enclousure Services (SES) für SAS und SATA Devices
  • Jedes Direct-Attached Storage Enclosure muss eine Unique ID präsentieren.
Nicht unterstützt:
  • RAID Controller oder SAN (Fibre Channel, iSCSI, FCoE) Laufwerke
  • Multipath IO (MPIO) oder physische über mehrere Pfade angebundene Laufwerke
Laufwerke:
Voraussetzungen:
  • Jedes Laufwerk muss lokal in einem Server angeschlossen sein
  • Als Laufwerkstypen werden SAS, SATA und NVMe unterstützt
  • In jedem Server sollten die selben Laufwerke (Typ, Größe, Anzahl, Modell, Firmware) verbaut sein. Ausführliche Infos hierzu findet ihr unter Drive symmetry considerations for Storage Spaces 
  • Bei den SSDs müssen Enterprise SSDs verwendet werden, die „Power-loss Protection“ unterstützen. Außerdem sollte bei der Auswahl der SSDs genau darauf geachtet werden für welches Einsatzszenario diese benötigt werden. Schreibintensiv, Leseintensiv oder eine Mischung aus Beiden
  • Wir werden immer  wieder gefragt ob für Storage Spaces Direct nicht auch Consumer SSDs verwendet werden können - ein ganz klares NEIN!!! Es gibt hierzu von Dan Lovinger einen sehr guten Blogbeitrag dazu mit dem Titel:  "Don't do it: consumer-grade solid-state drives (SSD) in Storage Spaces Direct" 
  • Bei den Cache Laufwerken ist folgendes zu beachten:
    die SSDs oder NVMe’s sollten einen DWPD (Drive Write per Day) Wert von mindesten 3 haben oder mit  4TB pro Tag beschrieben (TBW) werden können, dieser Wert muss auf die Lebensdauer (meist 5 Jahre) der SSD oder der NVMe berechnet sein. Wie wir anhand der Hersteller Angaben berechnen können, ob die gewünschte SSD oder NVMe den Anforderungen entspricht, darüber mehr in Teil 3.
  • Wer nicht solange warten möchte, kann hier schon mal Infos dazu finden.
  • Das Betriebssystem sollte auf einem Laufwerk mit Raid1 installiert sein. Vorzugsweise auch auf SSDs. Microsoft gibt 200GB Größe als Empfehlung an.
Unterstütze Laufwerke:

HDD für Kapazität

  • 2,5“ und 3,5“ Formfaktor
  • Langsam (80 – 200 IOPS) bis 200MB/s Datentransfer
  • Günstig

SSD für Performance oder als Cache

  • 2,5“ und 3,5“ Formfaktor
  • Schnell (Read and Write > 10.000 IOPS) bis 750MB/s Datentransfer
  • Teuer

NVMe als Cache oder für Performance

  • 2,5“ und PCIe Slot Formfaktor
  • Schnell (Reads > 100.000 IOPS) bis 5.000MB/s Datentransfer
  • Teuer
Minimunanzahl Laufwerke pro Knoten (ohne die Betriebssystem Festplatten):
  • 2 Cache Laufwerke und 
  • 4 Kapazität Laufwerke
  • hier einige Beispiele für die Mindestanforderung der Laufwerke:

Laufwerkstpyen:

  • nur NVMe (gleiches Modell)
  • nur SSDs (gleiches Modell)
  • NVMe + SSD
  • SSD + HDD
  • NVMe + SSD + HDD

Minimal Anzahl pro Knoten:

  • 4 NVMe
  • 4 SSD
  • 2 NVMe + 4 SSD
  • 2 SSD + 4 HDD
  • 2 NVMe + 4 Andere
Maximums:
  • 100 TB (brutto) Festplattenkapazität pro S2D Knoten
  • 1 PB (Petabyte) Brutto Kapazität pro Storage Pool

Erweiterung durch JBODs:

  • wird grundsätzlich von Microsoft unterstützt.
  • Unsere Empfehlung ist: keine JBODS zu verwenden, da diese nur über einen Single Pfad angebunden werden können. Microsoft unterstützt bei Storage Spaces Direct kein MPIO!
  • Ein JBOD pro S2D Knoten - kein shared JBOD.

Netzwerk:

  • Minimum 10 Gbit für die interne Clusterkommunikation (Ost-West Traffic). Für Performance und Ausfallsicherheit empfiehlt Microsoft hierfür zwei NICs a 10 Gbit zu verwenden.
  • Die Netzwerkkarten sollten RDMA (remote direct memory access) mit dem Protokoll RoCE oder iWARP unterstützen.
  • Bei einem 2 Knoten Storage Spaces Direct Failover Cluster ist es von Microsoft supported die SMB NICs direkt miteinander zu verbinden (ohne Switche). Bei den ​WDDS (Windows Server Software-Defined) Systemen muss jedoch darauf geachtet werden, dass auch der Hardware Hersteller dies unterstützt.
  • Für die RoCE Konfiguration müssen VLANs angelegt werden, da die Infos zu RoCE im VLAN Header übertragen werden.
  • bei den eingesetzten Switche ist eine Unterstützung von PFC (Priority Flow Control) erforderlich , ETS (Enhanced Transmission Selection) wünschenswert .

Im Teil 3 geht es um „​​SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen

gutes Gelingen und bis zum nächsten Mal 

Petra

Der Beitrag Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct erschien zuerst auf Hyper-V Server Blog.

Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen

$
0
0

Bisher veröffentlichten Teile der Blogpostserie

Die Lebensdauer einer SSD oder einer NVMe kann in DWPD (Drive writes per day) , in TBW (Terabytes written) oder PBW (Petabyte written) angeben werden.

DWPD (drive write per day) gibt an, wie häufig eine SSD oder NVMe pro Tag  auf ihre Lebensdauer gesehen, komplett überschrieben werden kann. Der DWPD Wert basiert auf der Größe des Laufwerkes.

​Unten seht ihr am Beispiel der Samsung PM1725a den DWPD-Wert aller Größen.


TBW (Terabytes written) bzw. PBW (Petabytes written) gibt an, wieviel Daten auf eine SSD oder NVMe gemessen auf  ihre Lebensdauer geschrieben werden kann.  Der TBW und PBW Wert berücksichtig nicht die Größe des Laufwerks.


Am Beispiel der Intel Optane DC P4800X Series könnt ihr das gut sehen.


Wir erinnern uns, Microsoft gibt für Caching Devices in den Hardware Requirements folgendes vor: 

  • DWPD von 3 und höher  oder
  • 4 TBW pro Tag - auf 5 Jahre wären das 4 TB * 5 Jahre * 365 Tage = 7.300 TBW = ca. 7,3 PBW

Mit den folgenden Formeln, können wir die unterschiedlichen Herstellerangaben umrechnen und miteinander vergleichen. Die Formel geht von einer Festplattengröße in GB aus, solltet ihr eine TB Größenangabe haben, so könnt ihr die Multiplikation/Division mit 1024 weg lassen. 

  • DWPD = TBW * 1024 / (Capacity GB * Lebensdauer in Jahre * 365) 
  • DWPD = PBW * 1024 * 1024 / (Capacity GB * Lebensdauer in Jahre * 365)
  • TBW = (DWPD * Lebensdauer in Jahre * 365 * Capacity GB)/1024
  • PBW = TBW / 1024

Ob jetzt mit 1024 oder mit 1000 gerechnet wird, ist von Hersteller zu Hersteller unterschiedlich. Ich habe mich hier bei unseren Beispielen dafür entschieden mit 1024 zu rechnen. Doch ihr könnt auch mit 1000 rechnen.

Was bedeutet dies nun für uns im Bezug auf die Cache Laufwerke von Storage Spaces Direct?

​Es ​​muss ein Cache Anteil von mindestens 10 % oder höher gemessen an der Brutto Festplattenkapazität berücksichtigt werden. Wenn wir die Gesamtgröße des Cachebedarfs so ermittelt haben, können wir bestimmen welche Anzahl und Größe wir für die Cache Laufwerke benötigen. 

Beispiel:

wir planen 32 TB Bruttokapazität pro Knoten - somit benötigen wir mind. 3,2 TB (10 %) Caching Devices je Knoten - das könnten 2 x 1,6 TB oder 4 x 800 GB Caching Devices sein. Bei einem DWPD von 3 oder höher würden wir ein Caching Device mit mind. folgenden TWB bzw. PBW Werten benötigen.

  • 800 GB / 1024 * 3 DWPD * 5 Jahre * 365 Tage = 4.277 TBW oder ca. 4,3 PBW
  • 1,6 TB * 3 DWPD * 5 Jahre * 365 Tage =  8.760  TBW oder ca. 8,7 PBW 

bei dem 1,6 TB großen Caching Devices sind wir bei 3 DWPD auch über den 4 TB pro Tag auf die 5 Jahre gesehen (entspricht 7,3 PBW ). ​

​Microsoft sagt, dass ihr wählen könnt, nach welchem Wert ihr die Caching Devices auswählt. ​Carsten und wir sind da viel konservativer und möchten mindestens einen DWPD von 3 oder höher für Caching Devices haben.

Die Performance des Storage Spaces Direct Clusters wird unter anderem durch die ausgewählten Cache Laufwerke beeinflusst, daher sollten hier nur NVMe und SSD die write optimiert oder mixed used optimiert sind, zum Einsatz kommen. 

Im Teil 4 geht es um "​​Netzw​​​​​erkdesign bei Storage Spaces Direct​"

gutes Gelingen und bis zum nächsten Mal 

Petra

Der Beitrag Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen erschien zuerst auf Hyper-V Server Blog.

Teil 4 – Netzwerkdesign bei Storage Spaces Direct

$
0
0

Bisher veröffentlichten Teile der Blogpostserie

In diesem Teil der Blogpost Serie möchte ich euch die verschiedenen Möglichkeiten für das Netzwerkdesign bei einem Storage Spaces Direct Failover Cluster aufzeigen.

Mit dem Windows Server 2016 stehen uns  zwei unterschiedliche ​Teaming Modi zur Verfügung, die ich hier kurz vorstellen möchte.

Einmal der ​das LBFO Team.  LBFO steht für Load Balancing and Failover. Das LBFO Team wurde mit Windows Server 2012 eingeführt. 

Das LBFO Team unterstützt alle verfügbaren Teaming Modi. Hier können bis zu 32 Netzwerkkarten zu einem Team hinzugefügt werden. Es kann unabhängig von einem Hyper-V Switch angelegt werden.

Ein Hyper-V Switch der auf Basis des LBFO Teams angelegt wurde, unterstützt alle verfügbaren Switch Extensions. Eine virtuelle Netzwerkkarte (vNIC) die auf Basis des LBFO Teams angelegt wird, verfügt nicht über RDMA und RSS. Das LBFO Team kann über den Server Manager erzeugt werden. Mit folgendem PowerShell Beispiel kann ein LBFO Team angelegt werden.

New-NetLBFOTeam -Name "TEAM LAN" -TeamNICName 'TEAM LAN' -TeamMembers 'LAN1','LAN2' -TeamingModeSwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Der zweite Teaming Mode ist der SET Switch. SET steht für Switch Embedded Teaming. Wie der Name schon sagt, ist hier die NIC-Teaming Logik im Hyper-V Switch integriert. D. h. es wird ein Hyper-V Switch erzeugt, dem dann Netzwerkkarten zugewiesen werden. Dieser Teaming Mode wurde mit Windows Server 2016 neu eingeführt. Ein SET Switch kann nur über die PowerShell oder dem SCVMM 2016 angelegt werden. Der SET Switch unterstützt nur Microsoft SDN (Software Defined Network) Extensions und Switch Independent Teaming. Ein Vorteil des SET Switches, vNICs unterstützen RDMA und RSS. Ganz ausführlich hat mein Kollege Jan Kappen in folgenden Blogpost  dem SET Switch beschrieben. Mit folgendem PowerShell Beispiel kann ein SET Switch angelegt werden.

New-VMSwitch -Name 'vSwitch' -NetAdaperName 'LAN1','Lan2' -EnableEmbeddedTeaming $true -AllowManagementOS $false

Einige Grundsatzregeln vorweg:

Optimal ist es, wenn wir unsere Netzwerke ausfallsicher, entweder im Team oder wie beim SMB Netzwerk, mit mind. 2 SMB Netzwerken einplanen. Optimal wäre es zu dem, wenn wir die Netzwerke über zwei Netzwerkkarten verteilen könnten, so dass auch eine Netzwerkkarte ausfallen kann, ohne dass ein Netzwerk komplett wegbricht.

Die Netzwerkkarten für den SMB Traffic werden nicht geteamt. Wir benötigen immer separate NICs. Microsoft empfiehlt für den SMB Traffic mind. 2 x 10 Gbps. Das erhöht die Ausfallsicherheit und die Performance. Sollten NVMe als Cache Laufwerke vorgesehen werden, so empfiehlt es sich, nach unserer Erfahrung, für den SMB Traffic auf 25 Gbps pro NIC zu gehen. Ab Windows Server 2016 können SMB Direct Netze im selben Subnetz liegen. Wir empfehlen dennoch, dass die SMB Netze jeweils in einem separaten IP Segment betrieben werden. RDMA benötigt zusätzlich eine VLAN ID. 

Auch bei den weiteren Netzwerken ist genügend Bandbreite einzuplanen z.B. fürs Backup.

S2D Converged Networking Stack:

Die erste Frage, die wir uns nun stellen sollten ist: Welche Netzwerke benötigen wir?

  • Server (Domain) Lan (MGMT) 
  • Cluster Traffic (Livemigration, Heartbeat)
  • SMB Traffic 

für das converged Deployment benötigen wir keinen virtuellen Switch, der die Kommunikation mit den VMs ermöglicht.  

Designvariante  -  mit 2x MGMT-LAN Ports und 2x SMB Direct Ports

Beschreibung:

  • Ein Team fürs MGMT-LAN  
  • Der Ost-West SMB Traffic (zwischen den Clusterknoten) erfolgt über SMB1 + SMB2
  • Der Nord-Süd SMB Traffic (zu den Hyper-V Hosts) erfolgt ebenfalls über SMB1 + SMB2
  • Cluster Traffic erfolgt auch über die SMB Adpater

Vorteil:


Nachteil:

  • ​Es wird nur eine Dual Port RDMA NIC benötigt. 
  • Einfache Konfiguration
  • Sowohl der Ost-West, wie auch der Nord-Süd SMB Traffic gehen über den gleichen Adapter.
  • Keine saubere Trennung des SMB Traffics und keine Ausfallsicherheit des RDMA Adapters.
Designvariante - mit 2x MGMT-LAN Ports und 4x SMB Direct Ports

​​​​Beschreibung:

  • MGMT Traffic über das MGMT-Team
  • Ost-West SMB Traffic über SMB1 + SMB2
  • Cluster Traffic erfolgt über SMB1 + SBM2
  • Nord-Süd SMB Traffic über SMB3 + SMB4


Vorteil:




Nachteil:

  • Der Nord-Süd SMB Traffic und Ost-West SMB Traffic ist über separate SMB Netze sauber voneinander getrennt
  • Es werden zwei Dualport RDMA NICs benötigt. Die SMB Netze können ausfallsicher über die beiden Netzwerkkarten verteilt werden.
  • Die von uns bevorzugte Variante
  • Mehr Hardware durch eine weitere Dualport RDMA NIC
  • komplexeres Setup

S2D Hyper-Converged Networking Stack:

beim hyper-converged Deployment benötigen wir zu den bereits unter dem converged Deployment aufgeführten Netzwerken, zusätzlich noch einen Hyper-V Switch für die Kommunikation der VMs.

Designbeispiel - SMB Direct und LBFO Team

Beschreibung:

  •  2 NIC Ports im LBFO Team für:
    • Hyper-V Switch (für die VMs)
    • vNIC für das MGMT-LAN
  • SMB1 und SMB2 für:
    • Livemigration
    • Clusterkommunikation
    • Ost-West SMB Traffic

Vorteil:




Nachteil:

  • Das LBFO Team ist ein seit 2012 bekanntes und stabiles Design.
  • Beim LBFO Team werden alle Teaming Modi unterstützt.
  • Der Hyper-V Switch auf Basis vom LBFO Team unterstützt alle Extensions
  • Ausfallsicherheit durch mehrere Netzwerk Adapter
  • Die von uns bevorzugte Variante
  • vNIC  (MGMT-LAN) unterstützt kein RDMA und RSS
Designbeispiel - Switch Embedded Teaming (SET)

Beschreibung:

eine DualPort RDMA Netzwerkkarte verbunden über einen SET Switch

  • Hyper-V Switch für VMs
  • eine vNIC für das MGMT-LAN
  • 2 vNICs für das SMB1 + SMB2  Direct  LAN
  • das SMB Direct LAN w​ird genutzt für
    • Livemigration
    • Clusterkommunikation
    • Ost-West SMB Traffic 

Vorteil:


Nachteil:

  • vNICs unterstützen RDMA und RSS
  • einfaches und günstiges Design
  • SET Switch unterstützt nur Microsoft SDN Extensions und Switchindepended Teaming
  • der gesamte Netzwerktraffic des hyper-converged S2D Clusters geht über eine Netzwerkkarte - keine Ausfallsicherheit.
  • SMB und VM Traffic laufen über die selbe Switch Infrastruktur - keine Trennung des Storage Traffic vom übrigen LAN Traffic.
  • SET Switch Technologie ist noch nicht so ausgereift wie das LBFO Team

​Mein Fazit ​aus unseren Erfahrungen in den Storage Spaces Direct Projekten ist, ein gut geplantes Netzwerk kann die Performance steigern und trägt viel zur Stabilität der Umgebung bei. 

Im Teil 5 geht es um "SMB 3 und SMB Direct"

gutes Gelingen und bis zum nächsten Mal

Petra

Der Beitrag Teil 4 – Netzwerkdesign bei Storage Spaces Direct erschien zuerst auf Hyper-V Server Blog.

Performance Probleme bei Intel NVMe’s mit aktuellem Intel Treiber 4.0

$
0
0
​In den vergangenen Wochen hatte ich zwei Storage Spaces Direct Implemtierungen mit Intel NVMe DC P4600 als Cache Devices. ​Unsere Kunden hatten unterschiedliche Serverhardware einmal waren es 4 DataOn Server und ​einmal waren es 4 Fujitsu Server.
​Bei den DataOn Server​ ​war Windows Server 2016 DataCenter Edition bereits durch den Hersteller installiert worden. Außerdem waren für die NVMe's die aktuellen Inteltreiber ebenfalls bereits installiert.

Da ich in der Vergangenheit immer mal wieder Probleme hatte, dass die Intel NVMe mit dem Windowstreiber nicht sauber erkannt wurden (gleiche Seriennummern), habe ich ​​die Treiber so belassen wie vom Hersteller vorinstalliert. 

Normalerweise, müssen bei Storage Spaces Direct für die NVMe's keine Hersteller Treiber ​installiert werden. Microsoft emfpiehlt die Windows eigenen Treiber zu verwenden. 
​​Die Firmware wurde bei allen NVMe's ​aktualisiert.
​Für die SMB Netzwerke ​kamen Mellanox ConnectX-4 25 Gbit Netzwerkkarten ​zum Einsatz.
​Die RoCE Konfiguration wurde sowohl an den Netzwerkkarten als auch an den Switchen durchgeführt.

Der nachfolgende LiveMigration Test, mit dem wir die RoCE Konfiguration testen, zeigte keine Auffälligkeiten. Bis dahin alles soweit gut.

​Performance Tests mit Intel NVMe und Inteltreiber 4.0

​​Der Performance Test mit der VMFleet sah dennoch nicht so aus wie erwartet.
Für ​alle nachfolgenden Tests mit der VMFleet habe ich ​folgende Einstellungen gewählt:
buffer size/alighment; threads/target; outstanding/thread; write%
$b = 8; $t = 8;​ $o = 20​; $w = 30
​Hohe Schreib- und Leselatenzen und schlechte IOP Werte, eines war sofort klar, da stimmt was nicht. Zuerst hatte ich die Netzwerkswitche in Verdacht, diese wurden dann aktualisiert - leider ohne spürbaren Erfolg.
Am darauffolgenden Tag war ich bei meinem zweiten Kunden. ​Auch hier zeigte der Performance Test mit der VMFleet ein ähnlich schlechtes Ergebnis. Jetzt war klar, es muss an den NVMe's liegen. 
Wir haben die NVMe Treiber deinstalliert und nach dem Neustart aller Cluster Knoten die vorherige Version der NVMe Treiber installiert und getestet.

Performance Tests mit Intel NVMe und Inteltreiber 3.2

​Dieser Performance Test mit der VMFleet wurde mit den gleichen Settings wie oben ausgeführt. 
Und siehe da, die Schreib- und Leselatenzen sind ​jetzt super und die IOPs haben sich verdoppelt, bei diesen Systemen ist jetzt die CPU der bremsende Faktor.

Jetzt wollte ich natürlich wissen, wie die Test mit den Windows Treibern aussehen. Also wieder alle Treiber deinstalliert und alle Cluster Server neu gestartet.

Performance Tests mit Intel NVMe und Mircosofttreiber

​Nachdem die Windowstreiber ähnlich gute Werte beim Performance Test mit der VMFleet gebracht haben und die NVMe's mit der aktuellen Firmware in Windows auch problemlos erkannt wurden, haben wir die Windowstreiber wie von Microsoft empfohlen beibehalten.

Es ist immer wieder spannend aber auch erschreckend zu sehen, welchen Einfluss die ​eingesetzten Treiber auf die Systeme haben. 
Daher testen, testen, testen.......

viel Spaß bei eurer Arbeit und bis zum nächsten Mal 
Petra

Der Beitrag Performance Probleme bei Intel NVMe’s mit aktuellem Intel Treiber 4.0 erschien zuerst auf Hyper-V Server Blog.

Teil 5 – SMB 3 und SMB Direct

$
0
0

Bisher veröffentlichten Teile der Blogpostserie

​​​SMB 3 und SMB Direct spielen​ bei Storage Spaces Direct eine wichtige Rolle. Daher möchte ich mich in diesem Blogpost näher mit diesen Protokollen beschäftigen. 

Man könnte sagen, das der Vorläufer des SMB (Server Messaging Block) Protokoll seine Wurzel bereits im Windows für Workgroups 3.11 hat. Dessen Netzwerk basiert wiederum auf Technologie von IBM entwickelt. Im Laufe der Jahre wurde das SMB Protokoll in den verschiedenen Betriebssystemversionen von Micrsoft weiterentwickelt. Bis mit Windows Server 2012 das SMB Protokoll mit der Version 3.0 zur Verfügung steht.

​Mit Einführung von Windows Server 2012 bekam das SMB Protokoll einige sehr interessante ​​Verbesserungen wie

  • SMB Multichannel
  • SMB Direct
  • ​SMB ​Verschlüsselung
  • SMB Transparent Failover
  • usw..

​Diese Verbessungerungen spielen ​auch bei Storage Spaces Direct eine große Rolle, daher möchte ​an dieser Stelle auf die einzelnen Punkte eingehen.

​SMB Multichannel

​SMB Multichannel ermöglicht ​die Zusammenfassung von Netzwerkbandbreite und Netzwerkfehlertoleranz, wenn zwischen dem SMB 3.x Client und dem SMB 3.x Server mehrere Netzwerkpfade verfügbar sind.

  • Geschwindigkeit
    • Bandbreiten-Aggregation durch Nutzung mehrer Kanäle
    • Standard für Netzwekkarten mit RSS Support sind 4 Kanäle
    • Verteilung der Prozessor-Belastung auf mehrere Cores (RSS Support)
  • Failover
    • Implementiert Ende-zu-Ende Ausfall Erkennung
    • Benutzung von NIC-Teaming möglich
  • Automatische Konfiguration
    • SMB erkennt automatisch das Vorhandensein mehrerer verfügbarer Netzwerkpfade  und ​fügt diese Verbindung bei Bedarf dynamisch dazu
    • Für NICs abschaltbar

​Beispiele für SMB Multichannel

Einzelne Netzwerkkarte mit RSS Support

​Eine typische Konfiguration besteht aus einem SMB Client und einen SMB Server, die z.B. jeweils mit einer 10 Gbit Netzwerkkarte ausgestattet sind. Ohne SMB Multichannel wird nur ein TCP/IP Kanal aufgebaut, diesen nutzt das SMB​ Protokoll. ​Dieser TCP/IP Kanal wird ​einem CPU-Kern zugewiesen. Dies ist standardmäßig der Core 0, der auch vom Betriebssystem genutzt wird. Hier kann es leicht zu einer Auslastung der CPU-Kerns kommen. Ein ​CPU-Kern ist in der Lage ca. 3 Gbit Netzwerk Traffic zu verarbeiten. ​Dadurch kann die Bandbreite der 10 Gbit Netzwerkkarte ohne SMB Multichannel und RSS nicht genutzt werden.
Verwenden wir SMB Mulitchannel ​in Verbindung mit einer RSS (Receive Side Scaling) fähigen Netzwerkkarte können ​mehrere TCP/IP Kanäle aufgebaut und vom SMB Protokoll genutzt werden. Jeder TCP/IP Kanal wird einem CPU​-Kern zugewiesen. Somit ist die Last auf ​mehrere CPU-Kerne ​verteilt, dadurch kann ein Engpass auf einem einzigen CPU-Kern vermieden werden. Die Bandbreite der Netzwerkkarte kann voll genutzt werden.

​Mehrere Netzwerkkarten

​wird in einer Umgebung mit mehreren Netzwerkkarten kein SMB Multichannel genutzt, so ​kann nur ein TCP/IP Kanal auf einer Netzwerkkarte aufgebaut werden, der dann vom SBM Protokoll genutzt ​wird.​ In diesem Fall ist es nicht möglich die Bandbreite der verfügbaren NIC zusammenzufassen. Bei Ausfall dieser Netzwerkkarte wird die Verbindung getrennt.
​Mit RSS (Receive Side Scaling) ​Support für die Netzwerkkarten in Verbindung mit SMB Multichannel ermöglicht es, über alle ​Netzwerkkarten der gleichen Geschwindigkeit, mehrere TCP/IP Kanäle, die verschiedenen CPU-Kernen zugewiesen werden, gemeinsam zu nutzen. Dies verteilt die Last auf mehrere CPU-Kerne und ermöglicht es die volle Bandbreite der verfügbaren Netzwerkkarten zu nutzen.
Bei Netzwerkkarten ohne RSS Support kann mit SMB Multichannel nur jeweils ein TCP/IP Kanal pro Netzwerkkarte aufgebaut werden.
Bei SMB Multichannel Nutzung kann eine Netzwerkkarte ausfallen, ​der Traffic ​geht über die verbliebene Netzwerkkarte. Es können auch dynamisch Netzwerkkarten der gleichen Geschwindigkeit zugeschaltet werden.
​Netzwerkkarten Team

​Beim Netzwerkkartenteams ohne SMB Multichannel sehen wir in der Abbildung untern nur einen TCP/IP Kanal. Warum ist das so? Nun für den SMB Client und dem SMB Server ist der Team-Adapter eine NIC und über diese kann er nur eine TCP/IP Verbindung aufbauen. Einziger Vorteil hierbei, fällt der eine Team-Adapter aus, so kann die Verbindung über den zweiten Team Adapter neu aufgebaut werden.
​Steht dem Netzwerkkartenteam SMB Mulitchannel und RSS zur Verfügung, ​können, wie hier im Beispiel aufgezeigt, bei den 10 Gbit Karten nur insgesamt 4 TCP/IP Kanäle aufgebaut werden. ​Auch hier ​sieht der SMB Client und SMB Server​ nur eine NIC. Da wir bei SMB Multichannel auch ohne Team einen transparenten Failover haben, macht das Netzwerkkartenteam für reine SMB Anwendungen keinen Sinn. Denn ohne das Netzwerkkartenteam könnten wir bei den 2 10 Gbit NICs imsgesamt 8 TCP/IP Kanäle aufbauen. Ein weiterer Nachteil des Netzwerkkartenteams ist, dass die RDMA Funktionalität der Netzwerkkarten für den Team-Adapter nicht mehr zur Verfügung steht.

Unsere Empfehlung:
​Bei SMB Multichannel Anwendungen wie Storage Spaces Direct kein Netzadapterteam für den SMB Traffic.
​Mehrere RDMA Netzwerkkarten

​Ohne SMB Multichannel, kann nur eine TCP/IP Verbindung aufgebaut werden.
Mit SMB Multichannel plus der RDMA Fähigkeit der Netzwekkarte können sehr hohe Bandbreiten übertragen werden, ohne das die CPU der Server dadurch belastet wäre. Pro Netzwerkkarte werden zwei RDMA Verbindungen erstellt.

​SMB Direct (SMB über RDMA)

Vorteile von SMB Direct:
  • schnelle Netzewrkkommunikation aus dem HPC (High-Performance Computing)
  • SMB Direct nutzt RDMA um Daten zwischen Hosts zu übertragen
    • hoher Durchsatz
    • geringe Latenz
    • geringe Prozessorbelastung
  • alle Möglichkeiten von SMB Multichannel
  • Implementierungen
    • Infiniband - bis 100 Gbit auf Infiniband Switchen
    • RoCE - 100 Gbit mit Ethernet Switche die DCB unterstützen
    • iWarp - 100 Gbit mit Ethernet Switche
  • Für Storage Spaces Direct wird von Microsoft RoCE und iWarp supportet.

​SMB Verschlüsselung

  • Ende-zu-Ende Verschlüsselung der SMB Daten
    • Schützt die Daten auf der Leitung
    • Nutzt vorhandene SMB Session Schlüssel um Schlüssel abzuleiten
  • Nutzt den AES-CCM Algorithums
  • keine Deploymentkosten
    • keine spezielle Hardware notwendig
    • keine iPSec Infrastruktur notwendig
  • Konfigurierbar pro Share oder für den ganzen Server

​SMB Transparentes Failover

  • Der Failover ist transparent für die Anwendungen
    • zero downtime
    • kurzzeitiger I/O-Delay während des Failovers
  • ​Unterstützt geplante und ungeplante Faiovers
    • Hardware/Software Wartung
    • Hardware/Software Ausfälle
    • Load Balancing / Client Redirection
  • Resilierend für Datei- und Verzeichnisoperationen
  • Funktioniert mit beiden Typen des Dateiservers im Cluster
    • Scale-Out File Server
    • "Classic" File Server
  • Anforderungen:
    • ab Windows Server 2012 Failover Cluster
    • SMB Client mit SMB 3.0
    • Dateifreigaben sind mit "Continuously Availability" Eigenschaften konfiguriert
​So, das soll es für heute gewesen sein, in meinem nächsten Blog Teil 6 zu dieser Serie wird es um die 
RDMA Einstellungen für Storage Spaces Direct gehen.

Viel Spass bis dahin
​Petra

Der Beitrag Teil 5 – SMB 3 und SMB Direct erschien zuerst auf Hyper-V Server Blog.


Aus der Praxis: Austausch einer defekten NVMe in einem S2D Cluster

$
0
0

​Bei einem Kunden von uns hat eine NVMe einen IO Error angezeigt und musste daraufhin ​ausgetauscht werden. Die NVMe war als Caching Device in einen 4 Knoten S2D Cluster verbaut. Ich möchte euch hier kurz schildern, wie wir auf den Fehler aufmerksam wurden und welche Schritte notwendig waren, um die NVMe ​zu ersetzen.

​Kurz zur Hardware, es sind 4 Fujitsu Server mit je 4 x Intel P3700 800GB NVMe's und 20 Seagate 2TB HDDs für den Storage Spaces Direct Pool.

Fehlersuche:

​Als ersten Indiz haben wir festgestellt, dass Repairjobs laufen, ohne dass einer der Server neu gestartet wurde. Daraufhin habe ich ​mit  "​Get-PhysicalDisk" die Festplatten überprüft und musste feststellen, dass ein Caching Device und wechselnde Festplatten IO Errors anzeigen. ​​​​Unten ein kurzes Beispiel der Ausgabe.

​Anhand der Seriennummern konnten alle fehlerhaften Festplatten ​einem Host ​zugeordnet werden. Die NVMe zeigte dauerhaft den I​O Error an, bei den HDDs  ​tauchte der Fehler sporadisch auf. Aber ich konnte die IO Errors auf den HDDs auf 5 Stück eingrenzen und damit war mir klar, dass diese Festplatten alle der defekten NVMe zugeordnet waren. ​Auf der Suche nach weiteren Infos zur Usache, ​​bin ich auch noch auf folgende Eventlog Einträge ge​stoßen.

Austausch der NVMe:

Vor dem Austauch, wurden alle Rollen ​von dem betroffenen Host verschoben und der Host auf "Pause" gesetzt und heruntergefahren.

Der Fujitsu Support hat sich entschlossen, den Controller für die NVMe's und die fehlerhafte NVMe auszutauschen. ​Nachdem der Server wieder hochgefahren war, ergab ein weiterer  "​Get-PhysicalDisk" Befehl dass nun 2 NVMe und 10 HDDs auf "Lost Communication" standen. Die neue NVMe war nicht zu sehen.  Alle Festplatten befinden sich in dem Server, bei dem gerade die Komponenten ​getauscht wurden.

​Was war die Ursache für die fehlen der Festplatten? Es musste ja etwas mit dem Tausch der Komponenten zu tun haben. Letztlich hat sich herausgestellt, dass zwei der vier NVMe's nicht richtig gesteckt waren. Als dieser Mangel beseitigt war, wurden alle NVMe (die alte und auch die neue) korrekt angezeigt. Bei den HDDs waren nach wie vor 5 Festplatten auf "Lost Communication"

​Wir sehen, die defekte NVMe wird mit "Lost Communication" angezeigt und die neue NVMe ist noch nicht im Storagepool. An dieser Stelle ein dickes Danke schön für den sehr hilfreichen Blogpost von Jan-Tore Pedersen der genau beschreibt, welche weiteren Schritte nun zu tun sind. 

​Als nächster Schritt muss die ​defekte NVMe auf "retired" gesetzt werden.

​Jan-Tore Pedersen beschreibt ​in seinem Blogpost, dass die neue NVMe nun per PowerShell Befehl zum StoragePool hinzugefügt werden muss. Das habe ich versucht, doch ich bekam daraufhin folgenden Fehler angezeigt.

​Die neue NVMe war bereits als Caching Device im Storagepool. Das erfolgte wohl automatisch nachdem ich die d​efekte NVMe auf "retired" gesetzt hatte.

​Eine weitere Überprüfung der Festplatten mit "​Get-PhysicalDisk"  zeigt, dass die 5 HDDs, die der ​defekten NVMe zugeordnet waren, ​immer noch mit "Lost Communication anzeigten werden. ​Die HDDs müssen in einem weiteren Schritt der neuen NVMe zugeordnet werden.

​Es dauerte ein paar Minuten, bis alle Festplatten wieder mit "OK" und "Healthy" angezeigt werden. Jetzt muss nur noch die ​defekte NVMe aus dem StoragePool entfernt werden.

​Zum Abschluss überprüfen wir mit "Get-StorageJob" , ​ob die Repair Jobs angelaufen sind. Es kann einige Zeit dauern, bis alle Repair Jobs abgearbeitet wurden, aber das soll uns nicht daran hintern, den Knoten wieder aus dem Pause Modus ​zu nehmen und ihm seine Rollen ​zu übertragen.

So, ich hoffe, ich konnte euch mit dieses Blogpost zeigen, wie eine NVMe aus einem S2D Cluster getauscht werden kann und welche Probleme dabei auftreten können. Bedenkt immer, dass all diese Befehle mit Vorsicht und Bedacht ausgeführt werden müssen, da ja meist ein Produktivsystem davon betroffen ist.

Viel Erfolg bei eurer Arbeit und bis zum nächsten Mal

Petra

Der Beitrag Aus der Praxis: Austausch einer defekten NVMe in einem S2D Cluster erschien zuerst auf Hyper-V Server Blog.

How to: Backup und Restore eines S2D Nodes mit Veeam Agent for Windows

$
0
0


​In meinem S2D Projekten ​kommt häufig die Frage auf, "Wie soll ich meine S2D Hosts sicher?" Daher möchte ich euch heute am Beispiel ​des Veeam Agent for Windows beschreiben, wie ihr eure S2D Hosts sichern könnt und welche Schritte für die Wiederherstellung ​eines Hosts unternommen werden müssen.

​Ich habe dies in einer Kunden Umgebung getestet. Die S2D Hosts waren mit Windows Server 2019 installiert und der Veeam Backup Server hatte die Version 9.5 Update 4 und dem passenden Veeam Agent dazu.

​Folgende Schritte sind dafür notwendig:

​1. Installation des Veeam Agent für Windows auf den S2D Host


​​Die aktuelle Version des Veeam Agent für Windows ​könnt hier euch bei Veeam herunterladen, dafür müsst ihr euch bei Veeam registrieren. Nach erfolgreichem Download könnt ihr auch schon starten. Ich habe den Veeam Agent für Windows direkt auf den S2D Hosts installiert.

​weiter müssen wir am S2D Host nichts konfigurieren, das machen wir in den nächsten Schritten über dem Veeam Backup & Replication Server. Solltet ihr keinen Veeam Backup & Replication Server zur Verfügung haben, so könnt ihr den Agent auch direkt am Server konfigurieren. 

2. S2D Hosts zum Veeam Backup & Replication Server hinzufügen


​Wir öffnen die Veeam Backup & Replication Konsole und wählen Backup Infrastructure aus.

​3. Backup Job erstellen und ausführen


​Sind die S2D Hosts erfolgreich am Veeam Server hinzugefügt, können wir im nächsten Schritt die Backup Jobs erstellen. Hierfür wechseln wir auf "Home" und rufen den Wizard für "Backup Jobs" auf.

create Veeam Agent for windows Backup job

​Im nächsten Schritt müssen die zu sichernden Server dem Backup Job hinzugefügt werden.

​Zum Abschluß muss noch das Scheduling eingerichtet werden. Danach können unsere S2D Hosts gesichert werden.

​4. ​Veeam Recovery Media für die S2D Hosts erstellen


​Um einen S2D Hosts wiederherstellen zu können, benötigen wir noch das Veeam Recovery Media

Voraussetzung zum Erstellen des Veeam Recovery Medias:

  • ​Installation des Windows Assessment and Deployment Kit (MS ADK) auf dem Backup Server
  • Windows-Installationsmedien, damit Veeam Agent für Windows die erforderlichen Komponenten von dort laden kann

Ich würde vor der Erstellung des Veeam Recovery Medias auf dem jeweiligen S2D Host die CSVs auf einen anderen Knoten verschieben. ​In der Veeam Konsole unter "Inventory" wählen wir den gewünschten S2D Hosts aus und ​klicken dann auf "Recovery Media"  

​Im nächsten Schritt geben wir den Pfad an, ​auf dem die ISO Datei gespeichter werden soll. Wir sollten uns hier einen Pfad überlegen, der in jedem Fall zugänglich ist,​ auch wenn das S2D Cluster z. B. nicht zur Verfügung stehen sollte. 

​Dieser Vorgang muss für alle S2D Hosts wiederholt werden. Das Veeam Recovery Media, muss gegebenenfalls nach einem Agent Update neu erstellt werden. Bitte haltet das Veeam Recovery Media immer kompatibel mit den Agent Versionen. Es wäre doch ärgerlich wenn ihr ein Backup für den Host habt und im Anwendungsfalle das Veeam Recovery Media mit dem Agent nicht kompatibel ist und ihr somit euren Host nicht wiederherstellen könnt.

​5. Restore eines S2D Hosts


​Die als Veeam Recovery Media erstellte ISO-Datei, mounten wir nun in der iDRAC Console (bei unserem Test arbeiten wir mit Dell Servern) um von der ISO den Server zu booten.

​Wenn ihr auf die zu restorenden Laufwerke klickt, bekommt hier eine detailierte Darstellung angezeigt, was von den Laufwerken wiederhergestellt wird. 

​Es ist für mich immer wieder faszinierend zu sehen, wie schnell so ein Restore durchläuft. Jetzt muss der Server noch neu gestartet werden und der Host steht dem Cluster wieder zur Verfügung.​

​Zum Abschluß müsst ihr noch die Storage Jobs kontollieren, dass diese auch wieder sauber abgearbeitet werden. Ich würde auch noch die Treiberstände kontollieren um sicher zu gehen, dass auch hier alles passt.

​Ihr solltet die Schritte unbedingt einmal in der Parxis durchgehen - vielleicht an einem nicht kritischen System um zu überprüfen, ob es auch in eurer Umgebung so läuft wie hier beschrieben. Wenn ihr das erst im Erstfall tut, können sich fatale Fehler einschleichen, die euch dann sehr viel Zeit und Nerven kosten. In diesem Sinne viel Erfolg

Eure Petra​

Der Beitrag How to: Backup und Restore eines S2D Nodes mit Veeam Agent for Windows erschien zuerst auf Hyper-V Server Blog.

Veeam Backup & Replication 9.5 Update 4b steht zum Download bereit

Langsame Performance nach Festplatten Erweiterung beim S2D Cluster

$
0
0

​da wir nun schon mehrfach ​Kundenanfragen hatten,​ die nach einer Festplattenerweiterungen im S2D Cluster ​Performanceprobleme festgestellt haben, möchte ich euch hier kurz aufzeigen, wie ihr überprüfen könnt, ob die Festplatten korrekt zum Storagepool hinzugefügt wurden.

Die Performance Probleme entstehen dadurch, dass die hinzugefügten Festplatten ​keine korrekte Bindung zu den Cache Laufwerken erhalten. Natürlich nur, wenn ihr auch Cache Laufwerke in eurem System habt. Erfolgt die Bindung zu den Cache Laufwerken nicht, so werden die hinzugefügten Festplatten direkt (ohne Cache) angesprochen. ​Ihr könnt euch sicher vorstellen, wie sich das auf die Performance eures Storage Spaces Direct System auswirkt, wenn plötzlich die z.B. hinzugefügten HDDs direkt angesprochen werden. ​​​

​Wenn Ihr euer Storage Spaces Direct System durch weitere Festplatten erweitern wollt, dann empfehlen wir euch, den Server dafür herunter zu fahren, die Festplatten zu stecken und im Anschluß den Server wieder zu starten.

Diese Vorgehensweise mag zwar etwas länger dauern, denn ihr müsst ja nach jedem Neustart zunächst einmal die Storagejobs abwarten bis ihr mit dem nächsten System fortfahren könnt, aber mit dieser Vorgehensweise hatte ich bisher nie die oben beschriebene Problematik.

​Wie könnt ihr nun überprüfen, ob die Festplatten wie gewünscht eurem Pool hinzugefügt wurden.

​Nachdem euer Server wieder hochgefahren ist, solltet ihr mit ​get-physicaldisk  überprüfen ob alle Festplatten vom System erkannt wurden. Idealerweise seht Ihr die hinzugefügten Festplatten mit dem Flag 'CanPool' True - d.h. die Festplatten wurden noch nicht dem Storagepool hinzugefügt. Es dauert etwas, bis Windows die hinzugefügten Festplatten automatisch in den Storagepool aufnimmt - also etwas Geduld. 

​Ich lasse bei solchen Arbeiten immer folgende Dauerabfrage in einer administrativen PowerShell laufen

do{get-storagejob | ft; sleep 5; get-virtualdisk | ft; sleep5;}while(1)

​damit sehe ich genau, welche Storagejob gerade laufen und auch wann ein AddPhysicalDisk Job gestartet bzw. abgeschlossen wurde.

​Jetzt stellt sich die Frage, wie kann ich überprüfen, ob die Festplatten korrekt in den Storagepool hinzugefügt wurden. Zunächst zählen wir die für das S2D System sichtbaren PhysicalDisks am besten per PowerShell. Damit können wir überprüfen, ob auch wirklich alle Festplatten korrekt von Server erkannt wurden.

Get-PhysicalDisk | group model -NoElement

​Um die Bindung der Festplatten an die Caching Device zu überprüfen, gibt es verschiedene Möglichkeiten.

  • Ihr könnt euch die Performance Counter von "Cluster Storage Hybrid Disks" ansehen.

​In diesem Beispiel hat der Server 4 Caching Devices 0-3. Alle Storagepool Festplatten sollten hier eine 1 zu 1 Bindung haben, wenn ihr die Bindings durchzählt und auf die Anzahl eurer Festplatten pro Server kommt passt alles.

​Mit folgenden PowerShellbefehlen könnt ihr das pro S2D Knoten abfragen

$perfcount= New-Object System.Diagnostics.PerformanceCounterCategory('Cluster Storage Hybrid Disks')
$CacheDrive = New-Object System.Diagnostics.PerformanceCounterCategory('Cluster Storage cache stores')
​$Hybriddiks=$perfcount.GetInstanceNames()
foreach($CD in $CacheDrive.GetInstanceNames()){
    $Hybriddiks -match ":$CD"
    $i=($Hybriddiks -match ":$CD").Count
    Write-Output " Es sind $i Zuordnungen für das Cache Device $CD"
}

  • ​Ihr könnt ​die Clusterlogs überprüfen

​​ Get-ClusterLog -TimeSpan 2 erzeugt unter "c:\windows\cluster\reports" eine "Cluster.log" Datei. 

Im Abschnitt [=== SBL Disks ===] findet ihr die gewünschte Infos. Microsoft hat in seinen DOCs zu Storage Spaces Direct​ unter der Überschrift "Langsame EA-Leistung" die unterschiedlichen Stati beschrieben.

Wenn ihr ein Storage Spaces Direct System mit Cache Laufwerken habt, müssen alle Festplatten mit dem Status "cachediskstateinitializedandbound" aufgeführt sein. Die Clusterlog muss natürlich auf jedem Host erzeugt werden. ​In dem unteren Bild seht ihr den Auszug aus einer Clusterlog Datei, bei der zwei Festplatten keine Bindung zu den Cache Devices haben.

​Wem es zuviel Arbeit ist, auf jedem Server ein Clusterlog zu erstellen und dieses auszuwerten, der kann sich das PowerShell Script von Darryl van der Peijl "Get-CacheDiskStauts.ps1" herunterladen und ausführen. An dieser Stelle ein dickes Dankeschön an Darryl für seine tolle Communityarbeit rund um das Thema Storage Spaces Direct.

​Ich empfehle euch, die hier beschriebenen Schritte nach dem hinzufügen von Festplatten immer ​durch zu führen. Solange ihr den neu gewonnen Festplattenplatz noch keiner VirtualDisk zugewiesen habt, ist es relativ einfach diese Festplatten aus dem Storagepool zu entfernen und nochmals hinzu zufügen. Sind die Festplatten bereits einer VirtualDisk zugewiesen, müsst ihr erst dafür sorgen genügend freiverfügbaren Festplattenplatz ​ zu haben, bevor eine Festplatte entfernt werden kann. 

In diesem Sinne weiterhin erfolgreiches Arbeiten. Eure Petra

Der Beitrag Langsame Performance nach Festplatten Erweiterung beim S2D Cluster erschien zuerst auf Hyper-V Server Blog.

How to: Firmwareupdate von NVMe’s oder SSDs mit PowerShell

$
0
0

​Heute möchte ich euch ​zeigen, wie ihr bei eurem Storage Spaces Direct Cluster mit der PowerShell, ​die Firmware eurer NVMe's und SSDs aktualisieren könnt.

​In meinem Beispiel handelt es sich um ein ​3 Node Azure Stack HCI Cluster von HPE auf Basis Windows Server 2019  mit ​je ​24 SSDs vom Type MO001600JWTBT pro Server.

Überprüfen der aktuellen Firmware

​Zuerst überprüfen wir, welche Firmware ist aktuell installiert und unterstützen unsere NVMe's oder SSDs ​das aktualisieren per PowerShell. ​​Einen Überblick über alle Festplatten erhalten wir mit folgenden PowerShell Befehl.

 Get-PhysicalDisk  | Get-StorageFirmwareInformation

steht  "SupportsUpdate" auf "True" können wir grundsätzlich die Firmware der SSDs per PowerShell aktualisieren.

Download der Firmware Datei beim Hersteller

​​Zum Einsatz kommen nur vom Hersteller supportete Firmwareversionen. In meinem Beispiel ​war dies die Firmwareversion "HPD7" die unter folgendem Link heruntergeladen werden kann.

​​Die heruntergeladene .EXE Datei entpacken. ​In ​meinem Beispiel handelt es sich bei der  "TAPM5ALLHPD/.rel" um die Image Datei für das Firmwarupdate. Wenn ihr nicht schon auf dem Server seid, müsst ihr diese in ein Verzeichnis auf dem Server kopieren.

S2DNode und Festplatten in den Maintanence Mode setzen

​Der S2D Node muss vor der Firmwareaktualisierung  "Angehalten" und die Rollen verschoben werden. Im Anschluss müssen die Festplatten des ​S2D Nodes in den "Maintanence Mode" gesetzt werden. Dies könnt ihr über folgende PowerShell Befehle ​erreichen.

# Node anhalten und Rollen verschieben
$Node = <NodeName>
Suspend-ClusterNode -Name $Node -Drain -Wait -Verbose

# Festplatten des Hosts werden in den Maintenance Mode gesetzt
$S2DStorage=Get-StorageFaultDomain -type StorageScaleUnit | Where-Object {$_.FriendlyName -eq $Node}
Enable-StorageMaintenanceMode -InputObject $S2DStorage

Firmwareupdate Installieren

​​​Das Firmwareupdate ​muss lokal auf dem jeweiligen Server ausführt werden. ​Überprüft bitte vor dem Firmwareupate, ob die Festplatten tatsächlich im Maintanence Mode sind. Das könnt ihr z.B. mit folgenden PowerShell Befehl machen.

Get-PhysicalDisk -PhysicallyConnected -StorageNode(Get-StorageNode -Name "$Node*")[1] ​| ft DeviceId, FriendlyName,SerialNumber, Firmwareversion, MediaType,OperationalStatus

​Jetzt kann die neue Firmwareversion ​installiert werden.

$Disks = Get-PhysicalDisk | ? Operationalstatus -eq 'In Maintenance Mode'

foreach($Disk in $Disks) {
    $Disk | Update-StorageFirmware -ImagePath 'C:\install\Firmware für SSD MO001600JWTBT\cp040482\TAPM5ALLHPD7.rel' -SlotNumber 0 -Verbose
}

​Danach muss der ​S2DNode neu gestartet werden. ​​​Nach dem Neustart die Firmwareversion der SSDs kontrollieren, die Festplatten und den ​S2DNode aus dem Maintanence Mode nehmen.

S2DNode und Festplatten ​aus dem Maintanence Mode ​nehmen

# Festplatten des Hosts werden ​aus den Maintenance Mode ​genommen

$Node = <NodeName>
$S2DStorage=Get-StorageFaultDomain -type StorageScaleUnit | Where-Object {$_.FriendlyName -eq $Node}
Disable-StorageMaintenanceMode -InputObject $S2DStorage

# Festplatten kontrollieren
Get-PhysicalDisk

​# Clusterknoten "Fortsetzen und Rollen zurückholen
Resume-ClusterNode -Name $S2DNode -Failback Immediate -Verbose


​Denk bitte daran, dass ihr den Abschluss der Storagejobs abwartet, bis ihr mit den nächsten Knoten forffahrt. Mit

Get-StorageJob

könnt ihr die Storagejobs überwachen.

So, das war es schon.

An dieser Stelle sei darauf hingewiesen, dass ihr solche ​Aktionen nach Möglichkeit nie erstmals an einen Produktivsystem testen solltet. Außerdem ist mit großer Sorgfalt darauf zu achten, dass ihr die richtige Firmwaredatei installiert. Solltet ihr in eurem System NVMe's und SSDs haben, so kann es sein, dass ihr die hier gezeigten PowerShell Befehle anpassen müsst. Ich wünsche euch ganz viel Erfolg dabei und verbleibe bis zum nächsten Mal 

Eure Petra

Der Beitrag How to: Firmwareupdate von NVMe’s oder SSDs mit PowerShell erschien zuerst auf Hyper-V Server Blog.

Viewing all 47 articles
Browse latest View live