0

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

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

More…