4
Hyper-V-Cluster CSVs von ReFS zu NTFS konvertieren
###ffffff Guten Tag Kollegen,
weil ich selbst mit dem Problem zu kämpfen habe und ein bisschen Zeit brauchte, den richtigen Weg zu finden, dokumentiere ich das mal für jeden, der sich dafür interessiert:
Ausschlaggebend war diese Anleitung des Kollegen @MysticFoxDE.
Nochmals herzlichen Dank dafür.
Mein Cluster besteht aus 3 Hyper-Vs 2016. SCVMM ist nicht vorhanden. Der zentrale Speicher ist in 6 LUNs unterteilt. Alle haben dieses Phänomen, dass bei ReFS es zu einer FileSystemRedirected-Situation kommt, der Zugriff also nur über den Besitzerknoten möglich ist.
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
Die neue LUN zurück in den Cluster:
FOCM öffnen
Wechsel zu "Speicher" --> "Datenträger"
Klick auf "Datenträger hinzufügen". --> Datenträger auswählen und OK. (Wird dann in die Liste mit aufgenommen).
Rechtsklick auf den neuen Datenträger und korrekte Bezeichnung wiederherstellen.
Rechtsklick auf den neuen Datenträger und als CSV bereitstellen.
Dann auf den Einhängepunkt für CSVs im Dateisystem wechseln und auch dort die korrekte Bezeichnung wiederherstellen. ###
weil ich selbst mit dem Problem zu kämpfen habe und ein bisschen Zeit brauchte, den richtigen Weg zu finden, dokumentiere ich das mal für jeden, der sich dafür interessiert:
Ausschlaggebend war diese Anleitung des Kollegen @MysticFoxDE.
Nochmals herzlichen Dank dafür.
Mein Cluster besteht aus 3 Hyper-Vs 2016. SCVMM ist nicht vorhanden. Der zentrale Speicher ist in 6 LUNs unterteilt. Alle haben dieses Phänomen, dass bei ReFS es zu einer FileSystemRedirected-Situation kommt, der Zugriff also nur über den Besitzerknoten möglich ist.
1. Schritt:
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
2. Schritt:
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
3. Schritt:
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
4. Schritt
Die neue LUN zurück in den Cluster:
FOCM öffnen
Wechsel zu "Speicher" --> "Datenträger"
Klick auf "Datenträger hinzufügen". --> Datenträger auswählen und OK. (Wird dann in die Liste mit aufgenommen).
Rechtsklick auf den neuen Datenträger und korrekte Bezeichnung wiederherstellen.
Rechtsklick auf den neuen Datenträger und als CSV bereitstellen.
Dann auf den Einhängepunkt für CSVs im Dateisystem wechseln und auch dort die korrekte Bezeichnung wiederherstellen. ###
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 915165868
Url: https://administrator.de/contentid/915165868
Ausgedruckt am: 03.12.2024 um 17:12 Uhr
4 Kommentare
Neuester Kommentar
Moin beidermachtvongreyscull,
dein Problem und die Lösungsprozedur kommt mir irgendwie sehr bekannt vor. 🤪
Gern geschehen.
Ich hätte da noch ein paar Anmerkungen.
Ich schmeisse die VMs während der Konvertierungsphase auch aus dem FOCM raus und verschiebe diese über den Hyper-V Manager, da ich hier den Verschiebeprozess viel effizienter finde, wie über FOCM.
Nach Abschluss kann man die VM's ja ganz einfach wieder in FCOM "zurückimportieren".
Das offline nehmen ist nicht notwendig, du musst lediglich die CSV im FOCM löschen, dann sparst du dir im nächsten Schritt auch das online nehmen. 😉
Das kannst du übrigens auch über die Datenträgerverwaltung, sprich per GUI machen.
Mann sollte beim Formatierungsprozess lediglich KEINEN Laufwerksbuchstaben vergeben.
Die LUN würde ich übrigens aufgrund dessen, dass eine VHDX eine Sektorgrösse von 4K hat, ebenfalls passend mit 4K formatieren und nicht mit 64K.
Beste Grüsse aus BaWü
Alex
dein Problem und die Lösungsprozedur kommt mir irgendwie sehr bekannt vor. 🤪
Gern geschehen.
Ich hätte da noch ein paar Anmerkungen.
+ 1. Schritt:
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
Ich schmeisse die VMs während der Konvertierungsphase auch aus dem FOCM raus und verschiebe diese über den Hyper-V Manager, da ich hier den Verschiebeprozess viel effizienter finde, wie über FOCM.
Nach Abschluss kann man die VM's ja ganz einfach wieder in FCOM "zurückimportieren".
+ 2. Schritt:
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
Das offline nehmen ist nicht notwendig, du musst lediglich die CSV im FOCM löschen, dann sparst du dir im nächsten Schritt auch das online nehmen. 😉
+ 3. Schritt:
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
Das kannst du übrigens auch über die Datenträgerverwaltung, sprich per GUI machen.
Mann sollte beim Formatierungsprozess lediglich KEINEN Laufwerksbuchstaben vergeben.
Die LUN würde ich übrigens aufgrund dessen, dass eine VHDX eine Sektorgrösse von 4K hat, ebenfalls passend mit 4K formatieren und nicht mit 64K.
Beste Grüsse aus BaWü
Alex
Moin beidermachtvongreyscull,
Moin Alex,
dein Problem und die Lösungsprozedur kommt mir irgendwie sehr bekannt vor. 🤪
das glaube ich gerne. Du hast mir ja erst das Problem vor Augen geführt.
Ich hätte da noch ein paar Anmerkungen.
Ich schmeisse die VMs während der Konvertierungsphase auch aus dem FOCM raus und verschiebe diese über den Hyper-V Manager, da ich hier den Verschiebeprozess viel effizienter finde, wie über FOCM.
Nach Abschluss kann man die VM's ja ganz einfach wieder in FCOM "zurückimportieren".
+ 1. Schritt:
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
LUN freiräumen:
Mittels FOCM (Failover-Clustermanager) die betroffenen Maschinen von der LUN verschieben.
Ich schmeisse die VMs während der Konvertierungsphase auch aus dem FOCM raus und verschiebe diese über den Hyper-V Manager, da ich hier den Verschiebeprozess viel effizienter finde, wie über FOCM.
Nach Abschluss kann man die VM's ja ganz einfach wieder in FCOM "zurückimportieren".
Das kann ich auch mal versuchen. Ich hatte nur den Eindruck, dass er sowieso die Verschiebung über den Hyper-V-Manager triggert. Zumindest lässt sich da auch der Fortschritt verfolgen.
+ 2. Schritt:
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
LUN im Cluster offline nehmen, entfernen und Besitzerknoten identifizieren:
Mittels FOCM unter "Speicher" -> "Datenträger", die LUN erst offline nehmen, dann als CSV entfernen (wird dann zu freigegebener Speicher) und letztlich löschen.
Wichtig vor dem Löschen: Besitzerknoten im Auge behalten. Der kann sich vor dem Löschen nochmal ändern!
Das offline nehmen ist nicht notwendig, du musst lediglich die CSV im FOCM löschen, dann sparst du dir im nächsten Schritt auch das online nehmen. 😉
Ich stimme Dir zu. Ich arbeite lieber mit Netz und doppeltem Boden.
+ 3. Schritt:
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
Arbeit vom letzten Besitzerknoten der LUN aus.
diskmgmt.msc öffnen. Die LUN müsste als offline dort zu sehen sein. Mit Rechtsklick online nehmen. --> Datenträger-Nummer wird angezeigt
diskpart mit erhöhten Rechten und der Reihe nach folgende Befehle feuern!
list disk
sel disk (Nr der LUN_Disk)
clean
create partition primary
format fs=ntfs unit=64K label=LUNxx quick
exit
Die LUN sollte sauber gelabelt sein. Sonst verliert man schnell den Überblick.
Das kannst du übrigens auch über die Datenträgerverwaltung, sprich per GUI machen.
Mann sollte beim Formatierungsprozess lediglich KEINEN Laufwerksbuchstaben vergeben.
Da hab ich es probiert und wunderte mich, dass sogar bei GPT immer die LUN aufgeteilt wurde. Mehr als 2TB waren nicht drin. Bei diskpart hingegen hat er alles direkt sang und klanglos verwendet.
Die LUN würde ich übrigens aufgrund dessen, dass eine VHDX eine Sektorgrösse von 4K hat, ebenfalls passend mit 4K formatieren und nicht mit 64K.
Macht das was aus? Ich war mir ehrlich nicht sicher und jeder von mir zu Rate gezogene Artikel sagte eigentlich immer, dass je größer die Dateien (und VHDX sind da riesig) es besser sei, wenn die Zuordnungseinheiten ebenfalls sehr groß seien. Ich hatte mal gesehen, dass zwischen äußerer Fragmentierung einer VHDX und der Fragmentierung in ihrem Inneren kein direkter Zusammenhang zu bestehen scheint. Habe ich das Volume mit der VHDX offline defragmentiert, hatte sich in ihrem Inneren nichts am Fragmentierungsgrad geändert.
Beste Grüsse aus BaWü
Beste Grüße aus'm Saarland
Alex
Andreas
Moin Andreas,
das kommt daher, weil unter "Größe der Zordnungseinheiten:" wahrscheinlich "Standardgröße" ausgewählt war.
Dadurch hat das OS sich warum auch immer dafür entschieden eine Cluster Size von lediglich 512 Bytes zu benutzen und bei dieser Cluster Size ist die maximale Grösse einer LUN auf 2TB beschränkt.
Wenn du von Hand eine Cluster Size von 4K auswählst, dann kannst du LUN's bis 16TB erstellen, bei 8K sind bis max. 32TB möglich, u.s.w.
Siehe auch.
https://docs.microsoft.com/en-us/windows-server/storage/file-server/ntfs ...
Ist ganz einfach, wenn du viel random IO mit kleinen Datenmengen hast, wie es z.B. bei Datenbanken sehr oft der Fall ist, dann solltest du immer eine so klein wie mögliche Cluster Size fahren, da du sonst und insbesondere beim Schreiben nicht wirklich auf touren kommst. Wenn du überwiegend eher grössere Daten sequentiell durch die Gegend schiebst und die Latenz auch eher sekundär ist, dann kannst und solltest du eher zu einer grösseren Cluster Size greifen.
Gruss Alex
Da hab ich es probiert und wunderte mich, dass sogar bei GPT immer die LUN aufgeteilt wurde. Mehr als 2TB waren nicht drin. Bei diskpart hingegen hat er alles direkt sang und klanglos verwendet.
das kommt daher, weil unter "Größe der Zordnungseinheiten:" wahrscheinlich "Standardgröße" ausgewählt war.
Dadurch hat das OS sich warum auch immer dafür entschieden eine Cluster Size von lediglich 512 Bytes zu benutzen und bei dieser Cluster Size ist die maximale Grösse einer LUN auf 2TB beschränkt.
Wenn du von Hand eine Cluster Size von 4K auswählst, dann kannst du LUN's bis 16TB erstellen, bei 8K sind bis max. 32TB möglich, u.s.w.
Siehe auch.
https://docs.microsoft.com/en-us/windows-server/storage/file-server/ntfs ...
Macht das was aus? Ich war mir ehrlich nicht sicher und jeder von mir zu Rate gezogene Artikel sagte eigentlich immer, dass je größer die Dateien (und VHDX sind da riesig) es besser sei, wenn die Zuordnungseinheiten ebenfalls sehr groß seien. Ich hatte mal gesehen, dass zwischen äußerer Fragmentierung einer VHDX und der Fragmentierung in ihrem Inneren kein direkter Zusammenhang zu bestehen scheint. Habe ich das Volume mit der VHDX offline defragmentiert, hatte sich in ihrem Inneren nichts am Fragmentierungsgrad geändert.
Ist ganz einfach, wenn du viel random IO mit kleinen Datenmengen hast, wie es z.B. bei Datenbanken sehr oft der Fall ist, dann solltest du immer eine so klein wie mögliche Cluster Size fahren, da du sonst und insbesondere beim Schreiben nicht wirklich auf touren kommst. Wenn du überwiegend eher grössere Daten sequentiell durch die Gegend schiebst und die Latenz auch eher sekundär ist, dann kannst und solltest du eher zu einer grösseren Cluster Size greifen.
Gruss Alex
Zitat von @MysticFoxDE:
Moin Alex,
Macht das was aus? Ich war mir ehrlich nicht sicher und jeder von mir zu Rate gezogene Artikel sagte eigentlich immer, dass je größer die Dateien (und VHDX sind da riesig) es besser sei, wenn die Zuordnungseinheiten ebenfalls sehr groß seien. Ich hatte mal gesehen, dass zwischen äußerer Fragmentierung einer VHDX und der Fragmentierung in ihrem Inneren kein direkter Zusammenhang zu bestehen scheint. Habe ich das Volume mit der VHDX offline defragmentiert, hatte sich in ihrem Inneren nichts am Fragmentierungsgrad geändert.
Ist ganz einfach, wenn du viel random IO mit kleinen Datenmengen hast, wie es z.B. bei Datenbanken sehr oft der Fall ist, dann solltest du immer eine so klein wie mögliche Cluster Size fahren, da du sonst und insbesondere beim Schreiben nicht wirklich auf touren kommst. Wenn du überwiegend eher grössere Daten sequentiell durch die Gegend schiebst und die Latenz auch eher sekundär ist, dann kannst und solltest du eher zu einer grösseren Cluster Size greifen.
Ich hab noch eine LUN umzubauen. Da probiere ich es mal. Die anderen sind wie beschrieben bereits auf 64K-Clustergröße. Mal schauen, ob das bei den Maschinen einen messbaren Unterschied macht.
Gruss Alex
Addendum:
Ich hab gerade das hier gefunden: https://community.spiceworks.com/topic/2155510-storage-for-vhdx-benefits ...
Es scheint auf jeden Fall so zu sein, dass wenn die Cluster-Größe unterschiedlich ist (Storage der VHDX und Dateisystem innerhalb der VHDX), dass da eine Übersetzung erfolgen muss. Die scheint wohl auch notwendig zu sein, wenn das Betriebssystem kleinere Chunks als die vollen Cluster anfordert.
Gruß
Andreas
