15
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-ClusterSharedVolumeStateGrüsse aus BaWü
Alex
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: 599333
Url: https://administrator.de/tutorial/warum-ihr-keine-refs-formatierung-fuer-csvs-verwenden-solltet-die-von-einem-san-bereitgestellt-werden-599333.html
Ausgedruckt am: 26.12.2024 um 11:12 Uhr
15 Kommentare
Neuester Kommentar
Moin Kollege,
vielen Dank für diesen Artikel.
Ich prüfe das mal bei mir, da ich trotz 100 Festplatten auf 6 LUNs und CSVs verteilt, da einen immensen Flaschenhals vermute.
Gruß
bdmvg
vielen Dank für diesen Artikel.
Ich prüfe das mal bei mir, da ich trotz 100 Festplatten auf 6 LUNs und CSVs verteilt, da einen immensen Flaschenhals vermute.
Gruß
bdmvg
Moin Bdmvg,
Der Neugierde halber, wie sieht deine Storagetopologie (SAN-Typ, Anbindungstechnik) aus?
Wie viele Nodes hast du im Einsatz und wie schnell ist der Core Link zwischen diesen?
Grüsse aus BaWü
Alex
Ich prüfe das mal bei mir, da ich trotz 100 Festplatten auf 6 LUNs und CSVs verteilt, da einen immensen Flaschenhals vermute.
Der Neugierde halber, wie sieht deine Storagetopologie (SAN-Typ, Anbindungstechnik) aus?
Wie viele Nodes hast du im Einsatz und wie schnell ist der Core Link zwischen diesen?
Grüsse aus BaWü
Alex
1
Ich hab ein HP BladeCenter c7000, drei VHosts und über Glasfaser-Switche zwei HP MSAs mit je einer Erweiterungseinheit dran.
Jeder VHost hat zwei redundante Pfade à 6GBit.
Grüße
bdmvg
Jeder VHost hat zwei redundante Pfade à 6GBit.
Grüße
bdmvg
Moin Bdmvg,
Uiii, ein c7000 davon habe ich auch schon einige implementiert, ist aber schon eine Weile her.
Das mit den 6G und Glasfaser-Switche haut aber nicht ganz hin, entweder meintest du 8G oder SAS.
Ist aber auch egal, wenn deine CSVs ReFS formatiert sind, dann bist du von diesem Problem definitiv auch betroffen,
da es sowohl bei SAS als auch FC und auch bei iSCSI Anbindengen auftritt.
Wie schnell ist dein Netzwerkschnittstelle über die das Cluster untereinander kommuniziert?
Grüsse aus BaWü
Alex
Ich hab ein HP BladeCenter c7000, drei VHosts und über Glasfaser-Switche zwei HP MSAs mit je einer Erweiterungseinheit dran.
Jeder VHost hat zwei redundante Pfade à 6GBit.
Jeder VHost hat zwei redundante Pfade à 6GBit.
Uiii, ein c7000 davon habe ich auch schon einige implementiert, ist aber schon eine Weile her.
Das mit den 6G und Glasfaser-Switche haut aber nicht ganz hin, entweder meintest du 8G oder SAS.
Ist aber auch egal, wenn deine CSVs ReFS formatiert sind, dann bist du von diesem Problem definitiv auch betroffen,
da es sowohl bei SAS als auch FC und auch bei iSCSI Anbindengen auftritt.
Wie schnell ist dein Netzwerkschnittstelle über die das Cluster untereinander kommuniziert?
Grüsse aus BaWü
Alex
1
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...
Moin Christian,
wenn du deine NICs sauber getrimmt hast, dann merkt man den Murks mit einem 10G Core-Link schon nicht ganz so arg wie z.B. bei 1G, aber dennoch ist der Unterschied zum Teil sehr gravierend. Das kannst du am Besten mit unter bei einer Veeam Sicherung sehen. Es ist ein riesen Unterschied, ob ich eine Vollsicherung einer VM über den Coordinator-Node fahre oder über einen Non-Coordinator-Node, da liegen zum Teil Faktoren dazwischen.
Ferner ist auch die IO Leistung auf dem Non-Coordinator-Node prinzipbedingt geringer und auch eine höhere Latenz muss man im Vergleich zum Coordinator-Node in Kauf nehmen. Der einzige Vorteil den man von ReFS in einem solchen Fall hat, ist das schnellere erstellen einer Fixen vhdx oder das rasante klonen dieser, aber dann war es das auch.
Wir fahren unsere SANs z.B. mit zum Teil bis zu 96G pro Node per SAS an, da bring mir selbst ein 40G Core-Link keinen adäquaten Ausgleich dazu.
Grüsse aus BaWü
Alex
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...
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...
wenn du deine NICs sauber getrimmt hast, dann merkt man den Murks mit einem 10G Core-Link schon nicht ganz so arg wie z.B. bei 1G, aber dennoch ist der Unterschied zum Teil sehr gravierend. Das kannst du am Besten mit unter bei einer Veeam Sicherung sehen. Es ist ein riesen Unterschied, ob ich eine Vollsicherung einer VM über den Coordinator-Node fahre oder über einen Non-Coordinator-Node, da liegen zum Teil Faktoren dazwischen.
Ferner ist auch die IO Leistung auf dem Non-Coordinator-Node prinzipbedingt geringer und auch eine höhere Latenz muss man im Vergleich zum Coordinator-Node in Kauf nehmen. Der einzige Vorteil den man von ReFS in einem solchen Fall hat, ist das schnellere erstellen einer Fixen vhdx oder das rasante klonen dieser, aber dann war es das auch.
Wir fahren unsere SANs z.B. mit zum Teil bis zu 96G pro Node per SAS an, da bring mir selbst ein 40G Core-Link keinen adäquaten Ausgleich dazu.
Grüsse aus BaWü
Alex
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 ETESTS,
wenn Microsoft es schaffen würde seine Dokumentationen sauber und vollständig zu schreiben, dann könnten wir uns alle, die schmerzhaften und zum Teil sehr zeit- und kostenintensiven Learnings auch sparen und vielleicht Sinnvolleres mit diesen Kapazitäten anstellen.
Du hast den Murks zum Glück gemerkt und hast auch eine überschaubare Umgebung (Homelab), wo du das Problem relativ gut und ohne grössere Schmerzen beheben kannst.
Wir haben einige >50 TB AllFlash SANs und viele kleinere in den Produktivbetrieb genommen und haben erst im Nachgang gemerkt, dass die Dinger effektiv nur einbeinig halbwegs gut laufen. Das ist begrenzt lustig und hat mich persönlich dieses Jahr schon diverse Wochenenden gekostet, um Storages umzuschaufeln, neu konfigurieren und wieder zurück zuschaufeln, bevor die Belegschaft des Kunden aus dem WE erwacht und sich dann über die wahre Performance der Biester freuen durfte.
Die nächste Umschaufelaktion steht bereits in 14 Tagen an, sind zwar nur ~12 TB, aber trotzdem 🤢🤮
Grüsse aus BaWü
Alex
Learning: ReFS macht nur mit S2D oder auf einem Windows Server SMB 3 Storage für die HVs Sinn...
wenn Microsoft es schaffen würde seine Dokumentationen sauber und vollständig zu schreiben, dann könnten wir uns alle, die schmerzhaften und zum Teil sehr zeit- und kostenintensiven Learnings auch sparen und vielleicht Sinnvolleres mit diesen Kapazitäten anstellen.
Du hast den Murks zum Glück gemerkt und hast auch eine überschaubare Umgebung (Homelab), wo du das Problem relativ gut und ohne grössere Schmerzen beheben kannst.
Wir haben einige >50 TB AllFlash SANs und viele kleinere in den Produktivbetrieb genommen und haben erst im Nachgang gemerkt, dass die Dinger effektiv nur einbeinig halbwegs gut laufen. Das ist begrenzt lustig und hat mich persönlich dieses Jahr schon diverse Wochenenden gekostet, um Storages umzuschaufeln, neu konfigurieren und wieder zurück zuschaufeln, bevor die Belegschaft des Kunden aus dem WE erwacht und sich dann über die wahre Performance der Biester freuen durfte.
Die nächste Umschaufelaktion steht bereits in 14 Tagen an, sind zwar nur ~12 TB, aber trotzdem 🤢🤮
Grüsse aus BaWü
Alex
Ich bin auch schon im Gedankenspiel, wie ich 16TB umgeschaufelt kriege.... Ach ist das doof.. mich wurmt sowas. Und es dann einfach so zu lassen geht bei mir nicht. 
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
Moin Christian,
Ich schaufle die SANs meistens über das Backup NAS/SAN des Kunden um, die sind von der Kapazität um ein vielfaches grösser wie die Primärspeicher und sind bei vielen unserer Kunden schon per 10G angebunden. Ist aber trotzdem nervig, du musst alle VMs erstmal runterfahren, von dem zu konvertierenden CSV runterkopieren. Dann muss das bisherige CSV neu eingerichtet werden (!!! NTFS 4K !!!). Anschliessend müssen alle VMs wieder zurück kopiert und wieder gestartet werden.
OK, unter dem Strich ist es keine zu komplexe Angelegenheit, aber wie auch immer, das hätte absolut nicht sein müssen.
Nu Microsoft, nu pagadi! 😡🤬👿
Wenn deine Server schon über USB3 verfügen, so kannst du die 16TB eigentlich auch über externe HDDs umschaufeln, habe ich auch schon gemacht. Ist aber umständlicher, da ich aus Sicherheitsgründen in einem solchen Fall, die gleichen VMs immer auf zwei externe HDDs runterkopiere. Sollte mir eine HDD dazwischen drauf gehen, so habe ich noch die andere zur Verfügung.
Bei einer guten externen HDD kannst du mit ~ 200MB/s beim schreiben rechnen, das sind ~700GB/h. Für deine 16T würdest du zum runterkopieren somit etwa 23,5 Stunden benötigen. Das Neueinrichten des CSV dauert im Normallfall nur wenige Minuten. Dann benötigst du < 23,5 Stunden um die VMs wieder zurück zu kopieren und noch etwas Zeit um die VMs wieder hoch zu fahren.
Freitag Abends beginnen, wenn nichts schief geht, dann ist die Sache am Sonntag Abends überstanden.
Grüsse aus BaWü
Alex
Ich bin auch schon im Gedankenspiel, wie ich 16TB umgeschaufelt kriege.... Ach ist das doof.. mich wurmt sowas. Und es dann einfach so zu lassen geht bei mir nicht.
Ich schaufle die SANs meistens über das Backup NAS/SAN des Kunden um, die sind von der Kapazität um ein vielfaches grösser wie die Primärspeicher und sind bei vielen unserer Kunden schon per 10G angebunden. Ist aber trotzdem nervig, du musst alle VMs erstmal runterfahren, von dem zu konvertierenden CSV runterkopieren. Dann muss das bisherige CSV neu eingerichtet werden (!!! NTFS 4K !!!). Anschliessend müssen alle VMs wieder zurück kopiert und wieder gestartet werden.
OK, unter dem Strich ist es keine zu komplexe Angelegenheit, aber wie auch immer, das hätte absolut nicht sein müssen.
Nu Microsoft, nu pagadi! 😡🤬👿
Wenn deine Server schon über USB3 verfügen, so kannst du die 16TB eigentlich auch über externe HDDs umschaufeln, habe ich auch schon gemacht. Ist aber umständlicher, da ich aus Sicherheitsgründen in einem solchen Fall, die gleichen VMs immer auf zwei externe HDDs runterkopiere. Sollte mir eine HDD dazwischen drauf gehen, so habe ich noch die andere zur Verfügung.
Bei einer guten externen HDD kannst du mit ~ 200MB/s beim schreiben rechnen, das sind ~700GB/h. Für deine 16T würdest du zum runterkopieren somit etwa 23,5 Stunden benötigen. Das Neueinrichten des CSV dauert im Normallfall nur wenige Minuten. Dann benötigst du < 23,5 Stunden um die VMs wieder zurück zu kopieren und noch etwas Zeit um die VMs wieder hoch zu fahren.
Freitag Abends beginnen, wenn nichts schief geht, dann ist die Sache am Sonntag Abends überstanden.
Grüsse aus BaWü
Alex
Moin Andreas,
Wenn deine 10G NICs sauber eingestellt sind, dann ist das auf jeden Fall schon mal nicht schlecht.
Jedoch laufen nur die wenigsten 10G mit Ihrer tatsächlich möglichen Performance, da hier auch so gut wie bei jedem Hersteller bei den Treibern Murks getrieben wird.
Siehe dazu:
Hyper V Server 2019, Gast Server 2016, Intel X722, langsame ext. Netzwerkanbindung
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
(das ist mit 17 Seiten, glaube ich der bisher längste Spiceworks Beitrag, den es je gab)
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Definitiv, aber ich kann dir pauschal absolut nicht sagen im welchem Bereich die Verbesserung liegen wird.
Das ist sehr stakt von deiner Systemtopologie und auch den Anwendungen abhängig. Kann sein, dass manche Dinge nur ein bisschen
schneller laufen, kann aber auch sein, dass sich dir Performance in machen Bereichen um Faktoren verbessert.
Grüsse aus BaWü
Alex
Innerhalb des Clusters laufen 10GBit (soweit ich weiß - ich hab ihn nicht eingerichtet).
Wenn deine 10G NICs sauber eingestellt sind, dann ist das auf jeden Fall schon mal nicht schlecht.
Jedoch laufen nur die wenigsten 10G mit Ihrer tatsächlich möglichen Performance, da hier auch so gut wie bei jedem Hersteller bei den Treibern Murks getrieben wird.
Siehe dazu:
Hyper V Server 2019, Gast Server 2016, Intel X722, langsame ext. Netzwerkanbindung
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
(das ist mit 17 Seiten, glaube ich der bisher längste Spiceworks Beitrag, den es je gab)
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Meinst Du, dass da eine Performancesteigerung zu erwarten ist?
Definitiv, aber ich kann dir pauschal absolut nicht sagen im welchem Bereich die Verbesserung liegen wird.
Das ist sehr stakt von deiner Systemtopologie und auch den Anwendungen abhängig. Kann sein, dass manche Dinge nur ein bisschen
schneller laufen, kann aber auch sein, dass sich dir Performance in machen Bereichen um Faktoren verbessert.
Grüsse aus BaWü
Alex
Warum 4k? Dann geht ja nicht mehr wie 16TB... Oder damit es passend zu den Blöcken der HDD ist?
Für HyperV kann doch unter Umständen auch 64kb genommen werden oder nicht?
Hatte auch schon überlegt, das Backup als iSCSI einzubinden und die VMs Live zu verschieben. Nimmt den Zeit Stress Faktor.
Für HyperV kann doch unter Umständen auch 64kb genommen werden oder nicht?
Hatte auch schon überlegt, das Backup als iSCSI einzubinden und die VMs Live zu verschieben. Nimmt den Zeit Stress Faktor.
Moin Christian,
Jap, aber nicht wegen den Physikalischen HDDs, da ist die Blockgrösse der einzelnen HDD eh irrelevant wenn ein RAID dazwischen hängt, da zählt eher die Stripesize des RAIDs. Eher wegen den VHDX, die intern mit 4K angesprochen werden.
Ja, das kannst du beim Hyper-V und vor allem bei einem SAN dahinter ruhig machen, mit den pauschalen 4K bei NTFS war ich etwas zu voreilig.
Die meisten SANs die ich bisher gesehen habe, arbeiten intern eh mit mindestens >= 64K, lediglich die Infortrend's gehen bis auf 16K runter.
Stimmt, auch eine gute Möglichkeit. 👍
Grüsse aus BaWü
Alex
Warum 4k? Dann geht ja nicht mehr wie 16TB... Oder damit es passend zu den Blöcken der HDD ist?
Jap, aber nicht wegen den Physikalischen HDDs, da ist die Blockgrösse der einzelnen HDD eh irrelevant wenn ein RAID dazwischen hängt, da zählt eher die Stripesize des RAIDs. Eher wegen den VHDX, die intern mit 4K angesprochen werden.
Für HyperV kann doch unter Umständen auch 64kb genommen werden oder nicht?
Ja, das kannst du beim Hyper-V und vor allem bei einem SAN dahinter ruhig machen, mit den pauschalen 4K bei NTFS war ich etwas zu voreilig.
Die meisten SANs die ich bisher gesehen habe, arbeiten intern eh mit mindestens >= 64K, lediglich die Infortrend's gehen bis auf 16K runter.
Hatte auch schon überlegt, das Backup als iSCSI einzubinden und die VMs Live zu verschieben. Nimmt den Zeit Stress Faktor.
Stimmt, auch eine gute Möglichkeit. 👍
Grüsse aus BaWü
Alex
Moin Zusammen,
habe am Dienstag die wohl letzte Nachricht von dem Microsoft Support bez. des betreffenden Support-Calls bekommen.
---
Das ist einfach nur bitter …
Aha, die bisherige Dokumentation in der absolut nichts davon steht, dass man ReFS nicht in Verbindung mit CSVs und SANs verwenden soll, möchte man also nicht ändern.
Uii, und die Kundenempfehlung lautet ebenfalls, dass man NTFS bei CSV und SANs dahinter benutzen sollte, interessant. Aber wo genau soll diese Empfehlung den bitte stehen?
Ich habe bei Support schon mehrfach nach einem offiziellen Dokument gefragt, wo genau das geschrieben stehen soll, habe von diesem aber bis heute nicht ein einziges offizielles Dokument von Microsoft bekommen, welches seine Aussage unterstreichen könnte. Stattdessen versucht mir der Support ständig Informationen von dritten als offizielle Aussage zu verkaufen. 😡
In allen offiziellen Dokumenten steht geschrieben, dass ich sowohl ReFS als auch NTFS benutzen kann und absolut nichts davon, dass ich bei SANs nur NTFS nutzen soll!
https://docs.microsoft.com/de-de/windows-server/failover-clustering/fail ...
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
😲 … moment wie war das nochmals.
Ihr seid jetzt auch etwas verwirrt, aber laut dem Support
Ist doch alles klar und deutlich dargestellt. 😵
Zusammenfassend, es gibt keine offizielle Dokumentation von Microsoft die darauf hinweist, dass man bei SAN gestützten CSV unbedingt NTFS benutzen muss, damit Direct IO funktioniert. Im Gegenteil, laut der aktuellen Dokumentation (s.O.) muss es eigentlich auch bei ReFS funktionieren. Somit ist die Argumentation des Supports meiner Ansicht nach, bisher einfach nur für den Hintern gewesen.
Dabei arbeitet der Techniker gar nicht bei Microsoft, sondern bei irgendeinem Call-Center welches lediglich von Microsoft bezahlt wird.
Und schon wieder eine Aussage von Dritten. 🤮🤮🤮
Ganz im Ernst, mittlerweile komme ich mir mehr als nur verarscht vor. Die Dokumentation sagt das Eine, der Support behauptet komplett etwas Anderes und geht gar nicht auf die „eigene“ Dokumentation ein, sondern verweist ständig nur auf Aussagen dritter, die das Problemverhalten zwar grundsätzlich bestätigen aber absolut nicht begründen.
Das ist alles ein riesengrosser Blödsinn, den es so, rein rechtlich, eigentlich gar nicht geben dürfte.
---
https://www.gesetze-im-internet.de/uwg_2004/__5.html
Gesetz gegen den unlauteren Wettbewerb (UWG) § 5 Irreführende geschäftliche Handlungen
(1) Unlauter handelt, wer eine irreführende geschäftliche Handlung vornimmt, die geeignet ist, den Verbraucher oder sonstigen Marktteilnehmer zu einer geschäftlichen Entscheidung zu veranlassen, die er andernfalls nicht getroffen hätte. Eine geschäftliche Handlung ist irreführend, wenn sie unwahre Angaben enthält oder sonstige zur Täuschung geeignete Angaben über folgende Umstände enthält:
1. die wesentlichen Merkmale der Ware oder Dienstleistung wie Verfügbarkeit, Art, Ausführung, Vorteile, Risiken, Zusammensetzung, Zubehör, Verfahren oder Zeitpunkt der Herstellung, Lieferung oder Erbringung, Zwecktauglichkeit, Verwendungsmöglichkeit, Menge, Beschaffenheit, Kundendienst und Beschwerdeverfahren, geographische oder betriebliche Herkunft, von der Verwendung zu erwartende Ergebnisse oder die Ergebnisse oder wesentlichen Bestandteile von Tests der Waren oder Dienstleistungen;
7. Rechte des Verbrauchers, insbesondere solche auf Grund von Garantieversprechen oder Gewährleistungsrechte bei Leistungsstörungen.
---
Grüsse aus BaWü
Alex
habe am Dienstag die wohl letzte Nachricht von dem Microsoft Support bez. des betreffenden Support-Calls bekommen.
Hello Mr. Fuchs,
Thank you for understanding.
But I am not able to help here anymore nor my TLs or PTAs. I need to close the SR since per last information we cannot do any change to the article.
The customer guidance is that we recommend using NTFS with CSV on top of SAN’s. That’s the clean customer statement, we don’t need to get into all the low level details.
What customers are experiencing is by design and as we already suggested for CSVs on top of SANs, NTFS is highly recommended due to the
same reason. Refs will be always at FileSystemRedirected.
We are the Microsoft CSS, our statement is Microsoft official.
This is also a good reference:
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ...
If you want DirectIO the only way is NTFS.
Since we are a break/fix team MS documentation is not CSS responsibility. I could only advise you to go to the feedback hub and also article rate feedbacks.
Thank you for understanding.
But I am not able to help here anymore nor my TLs or PTAs. I need to close the SR since per last information we cannot do any change to the article.
The customer guidance is that we recommend using NTFS with CSV on top of SAN’s. That’s the clean customer statement, we don’t need to get into all the low level details.
What customers are experiencing is by design and as we already suggested for CSVs on top of SANs, NTFS is highly recommended due to the
same reason. Refs will be always at FileSystemRedirected.
We are the Microsoft CSS, our statement is Microsoft official.
This is also a good reference:
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ...
If you want DirectIO the only way is NTFS.
Since we are a break/fix team MS documentation is not CSS responsibility. I could only advise you to go to the feedback hub and also article rate feedbacks.
---
Das ist einfach nur bitter …
since per last information we cannot do any change to the article.
Aha, die bisherige Dokumentation in der absolut nichts davon steht, dass man ReFS nicht in Verbindung mit CSVs und SANs verwenden soll, möchte man also nicht ändern.
The customer guidance is that we recommend using NTFS with CSV on top of SAN’s.
Uii, und die Kundenempfehlung lautet ebenfalls, dass man NTFS bei CSV und SANs dahinter benutzen sollte, interessant. Aber wo genau soll diese Empfehlung den bitte stehen?
Ich habe bei Support schon mehrfach nach einem offiziellen Dokument gefragt, wo genau das geschrieben stehen soll, habe von diesem aber bis heute nicht ein einziges offizielles Dokument von Microsoft bekommen, welches seine Aussage unterstreichen könnte. Stattdessen versucht mir der Support ständig Informationen von dritten als offizielle Aussage zu verkaufen. 😡
In allen offiziellen Dokumenten steht geschrieben, dass ich sowohl ReFS als auch NTFS benutzen kann und absolut nichts davon, dass ich bei SANs nur NTFS nutzen soll!
https://docs.microsoft.com/de-de/windows-server/failover-clustering/fail ...
https://techcommunity.microsoft.com/t5/failover-clustering/understanding ...
😲 … moment wie war das nochmals.
we cannot do any change to the article.
Refs will be always at FileSystemRedirected
Refs will be always at FileSystemRedirected
Ihr seid jetzt auch etwas verwirrt, aber laut dem Support
That’s the clean customer statement, we don’t need to get into all the low level details.
Ist doch alles klar und deutlich dargestellt. 😵
Zusammenfassend, es gibt keine offizielle Dokumentation von Microsoft die darauf hinweist, dass man bei SAN gestützten CSV unbedingt NTFS benutzen muss, damit Direct IO funktioniert. Im Gegenteil, laut der aktuellen Dokumentation (s.O.) muss es eigentlich auch bei ReFS funktionieren. Somit ist die Argumentation des Supports meiner Ansicht nach, bisher einfach nur für den Hintern gewesen.
We are the Microsoft CSS, our statement is Microsoft official.
Dabei arbeitet der Techniker gar nicht bei Microsoft, sondern bei irgendeinem Call-Center welches lediglich von Microsoft bezahlt wird.
This is also a good reference:
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ...
https://4sysops.com/archives/windows-server-2019-cluster-shared-volumes- ...
Und schon wieder eine Aussage von Dritten. 🤮🤮🤮
Ganz im Ernst, mittlerweile komme ich mir mehr als nur verarscht vor. Die Dokumentation sagt das Eine, der Support behauptet komplett etwas Anderes und geht gar nicht auf die „eigene“ Dokumentation ein, sondern verweist ständig nur auf Aussagen dritter, die das Problemverhalten zwar grundsätzlich bestätigen aber absolut nicht begründen.
Das ist alles ein riesengrosser Blödsinn, den es so, rein rechtlich, eigentlich gar nicht geben dürfte.
---
https://www.gesetze-im-internet.de/uwg_2004/__5.html
Gesetz gegen den unlauteren Wettbewerb (UWG) § 5 Irreführende geschäftliche Handlungen
(1) Unlauter handelt, wer eine irreführende geschäftliche Handlung vornimmt, die geeignet ist, den Verbraucher oder sonstigen Marktteilnehmer zu einer geschäftlichen Entscheidung zu veranlassen, die er andernfalls nicht getroffen hätte. Eine geschäftliche Handlung ist irreführend, wenn sie unwahre Angaben enthält oder sonstige zur Täuschung geeignete Angaben über folgende Umstände enthält:
1. die wesentlichen Merkmale der Ware oder Dienstleistung wie Verfügbarkeit, Art, Ausführung, Vorteile, Risiken, Zusammensetzung, Zubehör, Verfahren oder Zeitpunkt der Herstellung, Lieferung oder Erbringung, Zwecktauglichkeit, Verwendungsmöglichkeit, Menge, Beschaffenheit, Kundendienst und Beschwerdeverfahren, geographische oder betriebliche Herkunft, von der Verwendung zu erwartende Ergebnisse oder die Ergebnisse oder wesentlichen Bestandteile von Tests der Waren oder Dienstleistungen;
7. Rechte des Verbrauchers, insbesondere solche auf Grund von Garantieversprechen oder Gewährleistungsrechte bei Leistungsstörungen.
---
Grüsse aus BaWü
Alex
