Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
Moin liebe Hyper-V Freunde,
ich möchte euch mit diesem Beitrag eindringlich vor der Benutzung von ReFS bei ClusterShared Volumes (CSV), die von SANs bereitgestellt werden, warnen.
Nur den wenigsten Admins und oder Systemintegratoren ist bewusst, dass man damit in eine ganz gemeine Falle reintritt, die je nach Topologie zu extremen Performanceeinbussen führt.
Der Hintergrund ist der folgende, ein NTFS formatiertes Volume läuft bei der richtigen Implementierung meistens in dem Direct Mode, wie folgt abgebildet.
In diesem Modus kann jeder Hyper-V Node für Lese- und Schreibanforderungen direkt per SAS, FC, iSCSI & Co auf den bereitgestellten Speicher per Block Level von jedem HV-Node aus zugreifen. Das stellt stand heute, die effizienteste Methode dar, wie ein Hyper-V Cluster auf ein SAN zugreifen kann, da von einer VM ausgelöste Schreib- und Leseprozesse hocheffektiv im Blocklevel von der VM bis zum SAN abgearbeitet werden.
Verwendet man in einem solchen Hardwareszenarios jedoch ReFS, dann sieht die Sache komplett anders aus, in diesem Fall wird das SAN vom HV-Cluster nicht im „Direct Mode“ angesprochen, sondern in dem folgend abgebildeten „File System Redirected Mode“.
Der „File System Redirected Mode“ ist wie auf der Abbildung oben zu sehen, jedoch keineswegs auch nur annähernd so effizient wie der Direct Mode, da hier aus dem gesamten Cluster nur noch ein HV-Node, der sogenannte Coordinator-Node, den direkten Zugriff per SAS, FC, iSCSI & Co auf das SAN hat. Die restlichen Nodes greifen auf dieses CSV in diesem Szenario per SMB & LAN (Corelink) über den Coordinator-Node zu.
In diesem Fall wird z.B. eine blockbasierte Schreib-Leseanforderung einer VM, auf dem entsprechenden HV-Node zuerst vom Blocklevel in Filelevel (Overhead 1) umgewandelt. Dann muss diese über das LAN (Overhead 2) zum Coordinator-Node übermittelt werden, dieser wiederum muss die per LAN ankommende SMB Anfrage wieder auf Blocklevel umwandeln (Overhead 3), bevor er sie dann schlussendlich an das SAN weiterleiten kann. Das ist im direkten Vergleich zu dem Direct Mode somit mehr als nur ineffizient.
Weitere Infos zu diesem Thema findet Ihr über den folgenden Link.
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
Nun kommen wir zu dem meiner Ansicht nach fatalsten Punkt an dieser Geschichte.
In keiner der offiziellen Microsoft Dokumentationen wird auch nur ein Wort darüber verloren, dass es so ist!
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
Ganz im Gegenteil, es gibt mindestens zwei Dokumentationen, die eigentlich besagen, dass ein ReFS formatiertes Volume, auch im Direct Mode laufen müsste.
https://techcommunity.microsoft.com/t5/failover-clustering/cluster-share ...
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
Es gibt bei der Einrichtung des CSV auch keine aktive Warnmeldung, die einen Admin z.B. darauf hinweisen würde, dass das Anlegen der CVS auf einem ReFS formatierten Volume nur in dem suboptimalen „File System Redirected Mode“ möglich ist.
Daher bin auch ich am Anfang schon mehrfach in diese Falle gedappt und habe einige Systeme mit ReFS formatierten CSV in die Welt entlassen, da ich schlichtweg nichts von diesem Verhalten wusste und man von Microsoft auch nicht aktiv darauf hingewiesen wird.
Nachdem ich von einigen Kunden das Feedback bekommen habe, dass die Performance nach der Umstellung von einem älteren NTFS basierten System auf ein neueres ReFS basiertes System eher zur nachteiligen Applikationsperformance führte, obwohl die neueren Systeme deutlich leistungsfähiger waren, habe ich mich auf die Suche gemacht und bin nach einiger Zeit auf den oberen Sachverhalt gestossen. Zuerst dachte ich an einen Konfigurationsfehler und habe daher akribisch diverse Systeme darauf abgesucht. Aber auch nach tagelanger Analyse fand ich keinen plausiblen Grund, der es erklären würde, weshalb sich die entsprechenden Volumes nur im „File System Redirected Mode“ betreiben liessen.
Somit war der nächste logische Gedanke, dass es sich um einen Bug handeln muss.
Der nächste logische Schritt war es nun ein Support Ticket bei Microsoft zu eröffnen, was schon für sich gesehen, im Nachgang, ein eigenständiges Kapitel des Grauens dargestellt hat, aber darauf möchte ich in diesem Beitrag nicht näher eingehen. Da schreibe ich vielleicht die Tage eine eigene Story dazu. Auf jeden Fall habe ich es nach Monaten der Anstrengung und duzenden Anrufen bei den diversesten (für) Microsoft (arbeitende) Hotlines es endlich geschafft, dass ich nun, die mir eigentlich Vertraglich zugesicherten Support Calls tatsächlich auch nutzen kann.
Und so machte ich am 17.07.2020 einen Support Call bei Microsoft auf, mit einer sehr detaillierten Beschreibung des Sachverhalts. Noch am selben Tag kam eine Mail von dem zugewiesenen Supportmitarbeiter, ich möge doch bitte den angehängte Standardfragekatalog (23 Fragen) ausfüllen, damit die das Problem besser klassifizieren kann. Ich ärgerte mich über die Mail, da ich in der einleitenden schon alle Details genannt habe, bin dann aber der nutzlosen Aufforderung nachgekommen und habe annähernd dasselbe wie auch beim eröffnen des Tickets zurückgeschrieben.
Am 22.07 kam prompt die folgende Antwort.
---
Hello Mr. Alexander,
Thank you for the answers.
This issue exist from long time. I will need to consult with my Technical Leaders what can be done or is there a fix available yet.
I will let you know as soon as I have an update.
---
Volltreffer dachte ich mir an diesem Tag, da kannst du noch lange bei dem System selbst nach dem Grund suchen.
Also schrieb ich noch am selben Tag eine Mail in der ich mich unter anderem auch darüber aufgeregt habe das der Bug schon länger existieren würde, dieser bisher aber nirgends offiziell erwähnt wird. Daher bat ich um eine detaillierte Aufklärung, da uns und auch unseren Kunden durch diesen ein nicht unbeträchtlicher Schaden entstanden ist. Ferner Fragte ich nach einem Termin an, bis zu dem Microsoft gedenkt diesen Bug zu beseitigen.
Und schon am nächsten Tag bekam ich die folgende Antwort.
---
Hello Mr. Alexander,
I would like to note that this is not a BUG.
Below is the official statement from our Technical Advisor. I also asked if it will be possible to update any of the related articles with that information:
“This is an expected behavior. When you use ReFS on a CSV it will be ALWAYS File System Redirected, even when the GUI sometimes states that it’s not as follows.
This is a bit misleading that “No” in the File System Redirected Access refers the driver not being block redirected. ReFS works/best implemented with S2D as it does a real time tiering that is movement of data from cache to the actual capacity disk. With shared storage you should work with NTFS as you would get Direct IO from multiple nodes rather than file system re-directed . With NTFS you only redirect the metadata traffic to the coordinator. Therefore, if they want Direct IO they should be really switching from ReFS to NTFS on the mentioned scenario.
It makes sense as how Storage Spaces, CSV, NTFS and ReFS are designed. There is a quite old article by Elder Christensen which has some words about this:
https://techcommunity.microsoft.com/t5/failover-clustering/cluster-share ...;
---
Ich war erstaunt, wie jetzt doch kein Bug sondern ein gewolltes Verhalten … 🤨
Angefressen öffnete ich den angehängten Link und fing an akribisch den Inhalt zu studieren.
Mein Puls stieg jedoch fast mit jeder Zeile des Artikels, am Ende war dieser gefüllt bei ~ 300 angekommen. Der verlinkte Artikel enthält nämlich absolut keine Informationen darüber, dass ReFS generell nicht im Direct Mode laufen kann, im Gegenteil, dieser Artikel bestätigt wie ich schon weiter oben geschrieben habe eher, dass es funktionieren müsste. Und genau das schrieb ich dem Supportmitarbeiter auch wieder zurück.
Am 03.08 bekam ich die nächste Antwort.
---
The information provided on the previous email was indeed provided by the PM Elden, who wrote the article back in 2014.
He also wrote that this is not going to be exposed officially as there is no consideration to go into low level details from the ReFS PMs end.
This is a specific condition for SAN storage. This article explains which conditions are needed to have Direct IO but SAN is not contemplated there since this is from March 2014 and SAN support for ReFS started some years later, now the documentation doesn’t mention it but old threads can be referred to confirm this.
https://social.technet.microsoft.com/Forums/windows/en-US/6b2dcc4f-e735- ...
Therefore, our recommendation (without going into low level details) is that for CSVs:
NTFS should be used for CSV in top of SAN’s
ReFS should be used for CS in top of S2D
As there are many different scenarios for such deployments and at the moment the PM consider that going into low level details could be even more misleading we cannot change the article. After all, even when our recommendation is using NTFS for CSV in top of SANs, there could be some scenarios where ReFS performs better even without Direct IO and we cannot specify all single scenario in the documentation.
---
Darauf schrieb ich zurück, dass unsere Umgebung durchaus der offiziellen Spezifikation entspricht, bei der, der Direct Mode eigentlich funktionieren müsste und war zudem sehr erstaun darüber, dass Microsoft genau sagen kann, dass mein System nicht supportet ist, ohne auch einen einzigen Blick auf dieses geworfen zu haben. 🤨
Ich verwies bei meiner Antwort darauf, dass laut der offiziellen Spezifikation Direct Mode in meinem Szenario funktionieren muss und dass mich die Aussage von dritten nur begrenzt interessiert, zumal dort auch nur erwähnt wird, dass es nicht funktioniert, aber es wird mit keiner Zeile begründet, warum es so ist.
Am 11.08 kam die nächste folgende Antwort.
---
Thank you for the provided information. I understand your goal and I do my best. I have a new feedback received before your last email.
Here is the last information provided by per Mr. Elden:
“When you use ReFS with CSV volumes, the CSV volume will always run in file system redirection mode, which means that all the I/O operations are sent through the coordinator node. This can lead to severe performance impacts.
ReFS is only recommended for use with Storage Spaces Direct (S2D). With S2D, RDMA network adapters are a requirement.”
Reference articles:
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ....
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
---
So langsam kam ich mir richtig verarscht vor.
Die oberen Zeilen die angeblich von einem der ReFS Entwickler selbst stammen sollten, kommen in Wahrheit aus dem in der Mail selbst verlinkten Artikel der aber von einem Brandon Lee verfasst wurde und nicht vom Eldon! Und auch in dem Zweiten Link steht absolut nichts darüber, was das Fehlverhalten erklären würde.
Ich schrieb erneut eine Antwort in der ich nun deutlich meinen Unmut über den witzlosen Verlauf äusserte und bat darum mich nicht mehr mit Aussagen dritter abzuspeisen, sondern um eine offizielle Stellungnahme seitens des Herstellers selbst. Ferner bat ich darum, das betreffende Ticket an ein kompetenteres Support Team zu transferieren und auch die Priorität wieder auf den Level zu setzten wie ich auch bei der Eröffnung angegeben habe.
Am 21.08 bekam ich die bisher letzte folgende Antwort.
---
Hello Mr. Fuchs,
I really understand you. But let me inform you that there is no support team that will change the article and complete your request. I can change the severity to B, but this won’t make any change either.
I have tried to be really useful, pushed my Technical Leader a lot to get feedback from Mr. Eldon and others, but unfortunately result is the same. I could keep trying, but I know that it will again result in the same.
I will speak with my Leader last time and I will let you know with the final answer.
---
Zusammenfassung:
1. Laut der offiziellen Dokumentation von Microsoft muss auch ein ReFS formatiertes Volume bei CSV im Direct Mode laufen können.
2. Laut der Aussage des Supports kann ein ReFS formatiertes Volume in Verbindung mit CVS und einem SAN dahinter gar nicht im Derict Mode laufen.
3. Gemäss Punk 2 sind somit die offiziellen Dokumentationen falsch und oder unvollständig, aber diese Fehler möchte man offiziell auch nicht beseitigen.
Ich würde dieses Verhalten vielleicht bei einer 0815 Pommesbude noch halbwegs verstehen, aber bei einem milliardenschweren Unternehmen ist dies einfach nur erbärmlich und weit ab jeglichen Pflichtbewusstseins gegenüber dem (normalen) Kunden.
Sollte sich noch was ergeben, so werde ich diesen Beitrag auf jeden fall Zeitnah aktualisieren, aber so wie es momentan aussieht sollte jeder der eine Hyper-V Umgebung in verbindung mit einem SAN betreibt, möglichst die Finger von ReFS weg lassen.
Ups, fast vergessen, Ihr könnt den Status eurer CSV's ganz einfach mit dem folgenden Befehl abfragen.
Grüsse aus BaWü
Alex
ich möchte euch mit diesem Beitrag eindringlich vor der Benutzung von ReFS bei ClusterShared Volumes (CSV), die von SANs bereitgestellt werden, warnen.
Nur den wenigsten Admins und oder Systemintegratoren ist bewusst, dass man damit in eine ganz gemeine Falle reintritt, die je nach Topologie zu extremen Performanceeinbussen führt.
Der Hintergrund ist der folgende, ein NTFS formatiertes Volume läuft bei der richtigen Implementierung meistens in dem Direct Mode, wie folgt abgebildet.
In diesem Modus kann jeder Hyper-V Node für Lese- und Schreibanforderungen direkt per SAS, FC, iSCSI & Co auf den bereitgestellten Speicher per Block Level von jedem HV-Node aus zugreifen. Das stellt stand heute, die effizienteste Methode dar, wie ein Hyper-V Cluster auf ein SAN zugreifen kann, da von einer VM ausgelöste Schreib- und Leseprozesse hocheffektiv im Blocklevel von der VM bis zum SAN abgearbeitet werden.
Verwendet man in einem solchen Hardwareszenarios jedoch ReFS, dann sieht die Sache komplett anders aus, in diesem Fall wird das SAN vom HV-Cluster nicht im „Direct Mode“ angesprochen, sondern in dem folgend abgebildeten „File System Redirected Mode“.
Der „File System Redirected Mode“ ist wie auf der Abbildung oben zu sehen, jedoch keineswegs auch nur annähernd so effizient wie der Direct Mode, da hier aus dem gesamten Cluster nur noch ein HV-Node, der sogenannte Coordinator-Node, den direkten Zugriff per SAS, FC, iSCSI & Co auf das SAN hat. Die restlichen Nodes greifen auf dieses CSV in diesem Szenario per SMB & LAN (Corelink) über den Coordinator-Node zu.
In diesem Fall wird z.B. eine blockbasierte Schreib-Leseanforderung einer VM, auf dem entsprechenden HV-Node zuerst vom Blocklevel in Filelevel (Overhead 1) umgewandelt. Dann muss diese über das LAN (Overhead 2) zum Coordinator-Node übermittelt werden, dieser wiederum muss die per LAN ankommende SMB Anfrage wieder auf Blocklevel umwandeln (Overhead 3), bevor er sie dann schlussendlich an das SAN weiterleiten kann. Das ist im direkten Vergleich zu dem Direct Mode somit mehr als nur ineffizient.
Weitere Infos zu diesem Thema findet Ihr über den folgenden Link.
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
Nun kommen wir zu dem meiner Ansicht nach fatalsten Punkt an dieser Geschichte.
In keiner der offiziellen Microsoft Dokumentationen wird auch nur ein Wort darüber verloren, dass es so ist!
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
Ganz im Gegenteil, es gibt mindestens zwei Dokumentationen, die eigentlich besagen, dass ein ReFS formatiertes Volume, auch im Direct Mode laufen müsste.
https://techcommunity.microsoft.com/t5/failover-clustering/cluster-share ...
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
Es gibt bei der Einrichtung des CSV auch keine aktive Warnmeldung, die einen Admin z.B. darauf hinweisen würde, dass das Anlegen der CVS auf einem ReFS formatierten Volume nur in dem suboptimalen „File System Redirected Mode“ möglich ist.
Daher bin auch ich am Anfang schon mehrfach in diese Falle gedappt und habe einige Systeme mit ReFS formatierten CSV in die Welt entlassen, da ich schlichtweg nichts von diesem Verhalten wusste und man von Microsoft auch nicht aktiv darauf hingewiesen wird.
Nachdem ich von einigen Kunden das Feedback bekommen habe, dass die Performance nach der Umstellung von einem älteren NTFS basierten System auf ein neueres ReFS basiertes System eher zur nachteiligen Applikationsperformance führte, obwohl die neueren Systeme deutlich leistungsfähiger waren, habe ich mich auf die Suche gemacht und bin nach einiger Zeit auf den oberen Sachverhalt gestossen. Zuerst dachte ich an einen Konfigurationsfehler und habe daher akribisch diverse Systeme darauf abgesucht. Aber auch nach tagelanger Analyse fand ich keinen plausiblen Grund, der es erklären würde, weshalb sich die entsprechenden Volumes nur im „File System Redirected Mode“ betreiben liessen.
Somit war der nächste logische Gedanke, dass es sich um einen Bug handeln muss.
Der nächste logische Schritt war es nun ein Support Ticket bei Microsoft zu eröffnen, was schon für sich gesehen, im Nachgang, ein eigenständiges Kapitel des Grauens dargestellt hat, aber darauf möchte ich in diesem Beitrag nicht näher eingehen. Da schreibe ich vielleicht die Tage eine eigene Story dazu. Auf jeden Fall habe ich es nach Monaten der Anstrengung und duzenden Anrufen bei den diversesten (für) Microsoft (arbeitende) Hotlines es endlich geschafft, dass ich nun, die mir eigentlich Vertraglich zugesicherten Support Calls tatsächlich auch nutzen kann.
Und so machte ich am 17.07.2020 einen Support Call bei Microsoft auf, mit einer sehr detaillierten Beschreibung des Sachverhalts. Noch am selben Tag kam eine Mail von dem zugewiesenen Supportmitarbeiter, ich möge doch bitte den angehängte Standardfragekatalog (23 Fragen) ausfüllen, damit die das Problem besser klassifizieren kann. Ich ärgerte mich über die Mail, da ich in der einleitenden schon alle Details genannt habe, bin dann aber der nutzlosen Aufforderung nachgekommen und habe annähernd dasselbe wie auch beim eröffnen des Tickets zurückgeschrieben.
Am 22.07 kam prompt die folgende Antwort.
---
Hello Mr. Alexander,
Thank you for the answers.
This issue exist from long time. I will need to consult with my Technical Leaders what can be done or is there a fix available yet.
I will let you know as soon as I have an update.
---
Volltreffer dachte ich mir an diesem Tag, da kannst du noch lange bei dem System selbst nach dem Grund suchen.
Also schrieb ich noch am selben Tag eine Mail in der ich mich unter anderem auch darüber aufgeregt habe das der Bug schon länger existieren würde, dieser bisher aber nirgends offiziell erwähnt wird. Daher bat ich um eine detaillierte Aufklärung, da uns und auch unseren Kunden durch diesen ein nicht unbeträchtlicher Schaden entstanden ist. Ferner Fragte ich nach einem Termin an, bis zu dem Microsoft gedenkt diesen Bug zu beseitigen.
Und schon am nächsten Tag bekam ich die folgende Antwort.
---
Hello Mr. Alexander,
I would like to note that this is not a BUG.
Below is the official statement from our Technical Advisor. I also asked if it will be possible to update any of the related articles with that information:
“This is an expected behavior. When you use ReFS on a CSV it will be ALWAYS File System Redirected, even when the GUI sometimes states that it’s not as follows.
This is a bit misleading that “No” in the File System Redirected Access refers the driver not being block redirected. ReFS works/best implemented with S2D as it does a real time tiering that is movement of data from cache to the actual capacity disk. With shared storage you should work with NTFS as you would get Direct IO from multiple nodes rather than file system re-directed . With NTFS you only redirect the metadata traffic to the coordinator. Therefore, if they want Direct IO they should be really switching from ReFS to NTFS on the mentioned scenario.
It makes sense as how Storage Spaces, CSV, NTFS and ReFS are designed. There is a quite old article by Elder Christensen which has some words about this:
https://techcommunity.microsoft.com/t5/failover-clustering/cluster-share ...;
---
Ich war erstaunt, wie jetzt doch kein Bug sondern ein gewolltes Verhalten … 🤨
Angefressen öffnete ich den angehängten Link und fing an akribisch den Inhalt zu studieren.
Mein Puls stieg jedoch fast mit jeder Zeile des Artikels, am Ende war dieser gefüllt bei ~ 300 angekommen. Der verlinkte Artikel enthält nämlich absolut keine Informationen darüber, dass ReFS generell nicht im Direct Mode laufen kann, im Gegenteil, dieser Artikel bestätigt wie ich schon weiter oben geschrieben habe eher, dass es funktionieren müsste. Und genau das schrieb ich dem Supportmitarbeiter auch wieder zurück.
Am 03.08 bekam ich die nächste Antwort.
---
The information provided on the previous email was indeed provided by the PM Elden, who wrote the article back in 2014.
He also wrote that this is not going to be exposed officially as there is no consideration to go into low level details from the ReFS PMs end.
This is a specific condition for SAN storage. This article explains which conditions are needed to have Direct IO but SAN is not contemplated there since this is from March 2014 and SAN support for ReFS started some years later, now the documentation doesn’t mention it but old threads can be referred to confirm this.
https://social.technet.microsoft.com/Forums/windows/en-US/6b2dcc4f-e735- ...
Therefore, our recommendation (without going into low level details) is that for CSVs:
NTFS should be used for CSV in top of SAN’s
ReFS should be used for CS in top of S2D
As there are many different scenarios for such deployments and at the moment the PM consider that going into low level details could be even more misleading we cannot change the article. After all, even when our recommendation is using NTFS for CSV in top of SANs, there could be some scenarios where ReFS performs better even without Direct IO and we cannot specify all single scenario in the documentation.
---
Darauf schrieb ich zurück, dass unsere Umgebung durchaus der offiziellen Spezifikation entspricht, bei der, der Direct Mode eigentlich funktionieren müsste und war zudem sehr erstaun darüber, dass Microsoft genau sagen kann, dass mein System nicht supportet ist, ohne auch einen einzigen Blick auf dieses geworfen zu haben. 🤨
Ich verwies bei meiner Antwort darauf, dass laut der offiziellen Spezifikation Direct Mode in meinem Szenario funktionieren muss und dass mich die Aussage von dritten nur begrenzt interessiert, zumal dort auch nur erwähnt wird, dass es nicht funktioniert, aber es wird mit keiner Zeile begründet, warum es so ist.
Am 11.08 kam die nächste folgende Antwort.
---
Thank you for the provided information. I understand your goal and I do my best. I have a new feedback received before your last email.
Here is the last information provided by per Mr. Elden:
“When you use ReFS with CSV volumes, the CSV volume will always run in file system redirection mode, which means that all the I/O operations are sent through the coordinator node. This can lead to severe performance impacts.
ReFS is only recommended for use with Storage Spaces Direct (S2D). With S2D, RDMA network adapters are a requirement.”
Reference articles:
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ....
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
---
So langsam kam ich mir richtig verarscht vor.
Die oberen Zeilen die angeblich von einem der ReFS Entwickler selbst stammen sollten, kommen in Wahrheit aus dem in der Mail selbst verlinkten Artikel der aber von einem Brandon Lee verfasst wurde und nicht vom Eldon! Und auch in dem Zweiten Link steht absolut nichts darüber, was das Fehlverhalten erklären würde.
Ich schrieb erneut eine Antwort in der ich nun deutlich meinen Unmut über den witzlosen Verlauf äusserte und bat darum mich nicht mehr mit Aussagen dritter abzuspeisen, sondern um eine offizielle Stellungnahme seitens des Herstellers selbst. Ferner bat ich darum, das betreffende Ticket an ein kompetenteres Support Team zu transferieren und auch die Priorität wieder auf den Level zu setzten wie ich auch bei der Eröffnung angegeben habe.
Am 21.08 bekam ich die bisher letzte folgende Antwort.
---
Hello Mr. Fuchs,
I really understand you. But let me inform you that there is no support team that will change the article and complete your request. I can change the severity to B, but this won’t make any change either.
I have tried to be really useful, pushed my Technical Leader a lot to get feedback from Mr. Eldon and others, but unfortunately result is the same. I could keep trying, but I know that it will again result in the same.
I will speak with my Leader last time and I will let you know with the final answer.
---
Zusammenfassung:
1. Laut der offiziellen Dokumentation von Microsoft muss auch ein ReFS formatiertes Volume bei CSV im Direct Mode laufen können.
2. Laut der Aussage des Supports kann ein ReFS formatiertes Volume in Verbindung mit CVS und einem SAN dahinter gar nicht im Derict Mode laufen.
3. Gemäss Punk 2 sind somit die offiziellen Dokumentationen falsch und oder unvollständig, aber diese Fehler möchte man offiziell auch nicht beseitigen.
Ich würde dieses Verhalten vielleicht bei einer 0815 Pommesbude noch halbwegs verstehen, aber bei einem milliardenschweren Unternehmen ist dies einfach nur erbärmlich und weit ab jeglichen Pflichtbewusstseins gegenüber dem (normalen) Kunden.
Sollte sich noch was ergeben, so werde ich diesen Beitrag auf jeden fall Zeitnah aktualisieren, aber so wie es momentan aussieht sollte jeder der eine Hyper-V Umgebung in verbindung mit einem SAN betreibt, möglichst die Finger von ReFS weg lassen.
Ups, fast vergessen, Ihr könnt den Status eurer CSV's ganz einfach mit dem folgenden Befehl abfragen.
Get-ClusterSharedVolumeState
Grüsse aus BaWü
Alex
Please also mark the comments that contributed to the solution of the article
Content-ID: 599333
Url: https://administrator.de/contentid/599333
Printed on: December 3, 2024 at 05:12 o'clock
15 Comments
Latest comment
Das ist ja echt doof, was Microsoft da verzapft.
Wie du ja in dem anderen Thread schon angemerkt hast, ist unser Hauptstoragebereich davon auch betroffen.
Da die Clusterschnittstelle aber auch 10G hat, würde ich das jetzt erstmal nicht anfassen. Es sei denn, ich habe mal übergangsweise ein kleines 16TB Storage übrig und verschiebe an einem Feiertag alle Maschinen...
Wie du ja in dem anderen Thread schon angemerkt hast, ist unser Hauptstoragebereich davon auch betroffen.
Da die Clusterschnittstelle aber auch 10G hat, würde ich das jetzt erstmal nicht anfassen. Es sei denn, ich habe mal übergangsweise ein kleines 16TB Storage übrig und verschiebe an einem Feiertag alle Maschinen...
Japp, hatte mich auch erwischt:
ISCSI Traffic für CSVFS geht über falsche NIC im Hyper-V-Cluster
Learning: ReFS macht nur mit S2D oder auf einem Windows Server SMB 3 Storage für die HVs Sinn...
ISCSI Traffic für CSVFS geht über falsche NIC im Hyper-V-Cluster
Learning: ReFS macht nur mit S2D oder auf einem Windows Server SMB 3 Storage für die HVs Sinn...
Moin Alex,
Du hast Recht. Es sind nur schnuckelige 8G.
Und ja: Alle Shares haben den Status "FileSystemRedirected".
Innerhalb des Clusters laufen 10GBit (soweit ich weiß - ich hab ihn nicht eingerichtet).
Meinst Du, dass da eine Performancesteigerung zu erwarten ist?
Nochmals Danke für Deinen Artikel. Ich halte sowas für unschätzbar wertvoll.
Grüße aus dem Saarland
Andreas
Du hast Recht. Es sind nur schnuckelige 8G.
Und ja: Alle Shares haben den Status "FileSystemRedirected".
Innerhalb des Clusters laufen 10GBit (soweit ich weiß - ich hab ihn nicht eingerichtet).
Meinst Du, dass da eine Performancesteigerung zu erwarten ist?
Nochmals Danke für Deinen Artikel. Ich halte sowas für unschätzbar wertvoll.
Grüße aus dem Saarland
Andreas