Mount Volume im Windows FileServer - Warum?

[maxmad]

Mahlzeit zusammen!

Ich habe in einer historisch gewachsenen Systemumgebung ,die ich übernommen habe, auf einem Windows Fileserver (Version 2016) ein Konstrukt gefunden wo ich mir nicht richtig erklären kann aus welchem Grund man das so gemacht hat. Vielleicht findet sich hier jemand der weiß ob diese Konfiguration mal von Microsoft empfohlen wurde oder welche anderen Gründe es geben könnte das so aufzusetzen. Dazu habe ich unten mal ein Bild angehängt damit es etwas anschaulicher wird.

Die Shares liegen alle auf Disk 2 (siehe Bild). Disk 2 hängt aber nicht direkt mit einem eigenen Laufwerksbuchstaben im System sondern wird über das Mount-Volume 'E' im Server verfügbar gemacht. Dort ist Disk 2 dann über einen eigenen Ordner eingehangen und darunter liegen dann die einzelnen Shares. Der Fileserver selbst ist eine virtuelle Maschine unter Hyper-V.

Könnte es, da es sich hier ja um eine VM und kein Blech handelt, zu unnötigem Overhead bei hohen Zugriffszahlen auf die Shares kommen der durch diese Konfiguration vielleicht verursacht wird? Sprich, wäre es für die Performance vorteilhafter das Mount-Volume rauszunehmen und Disk 2 unter einem eigenen Laufwerksbuchstaben direkt verfügbar zu machen?

Danke schon mal für sachdienliche Hinweise ;-)

 

[kartoffelpü]

Für die Performance sollte das egal sein, ob da nun über einen LW-Buchstaben oder einen Mountpoint auf ner anderen Disk zugegriffen wird.

 

[Schongewusst99]

Performance-Nachteile wirst du davon eher nicht haben.

Die einfachste Antwort: du bist unabhängig von Laufwerksbuchstaben. Sollten Sie dir mal ausgehen...

Das passende Dokument von Microsoft findest du hier: https://docs.microsoft.com/de-de/tr...st-practices-when-you-use-volume-mount-points

 

[cloudman]

Damit kann man E einfach vergrößern. Das gemountete Volumen kann eben irgendwo im Verzeichnis eingebunden werden.
Wenn du z.b dein Download Verzeichnis nicht auf der System Platte haben willst sondern auf einer anderen Platte kannst du diese Platte unter c:\users\cloudman mounten.

 

[maxmad]

Performance-Nachteile wirst du davon eher nicht haben.

Die einfachste Antwort: du bist unabhängig von Laufwerksbuchstaben. Sollten Sie dir mal ausgehen...

Das passende Dokument von Microsoft findest du hier: https://docs.microsoft.com/de-de/tr...st-practices-when-you-use-volume-mount-points

Den Punkt kann ich nachvollziehen. Über dieses Konstrukt könnte ich als mehr einzelne Disk's in das System bringen als das Alphabet Buchstaben für einzelne Laufwerke über hat.

Mal angenommen das habe ich aber nicht vor um komme mit der maximal möglichen Anzahl an Laufwerksbuchstaben auch langfristig aus. Dann gibt es doch eigentlich keinen Grund das so zu bauen?

Da es sich ja um ein virtuelles System handelt kann ich ohnehin die zugrundeliegenden virtuellen Disk einfach nach Bedarf vergrößern wenn der Platz knapp wird. Zumindest solange ich noch Ressourcen auf dem Storage habe wo die zugehörige *.vhdx liegt. Das würde also in meinen Augen als Argument für diese Lösung nicht mehr ziehen.

Passt oder gibt's dazu Gegenstimmen? ;-)

 

[cloudman]

Keine Ahnung wie der Server verwendet wird. Die Performance könnte besser sein wenn die vhdx auf unterschiedlichen Laufwerken liegen und die Benutzer könnten einen Referenz auf Dateien haben die dort liegen.
Ansonsten spricht nichts dagegen es anders zu machen (aber auch nichts dafür 😀)

Your call

 

[maxmad]

Es gibt ein zentrales SAN das ausschließlich mit SSD's bestückt ist.

Mir fehlt mit dem Thema Fileserver leider etwas die Praxiserfahrung aber wenn ich sehe welche Menge an Shares auf einer einzigen 10 TB Disk liegt und dann alle Zugriffe nur über eine einzige virtuelle Netzwerkkarte gehen, dann behaupte ich mal dass diese Konfiguration alles andere als ideal ist. Kollegen möchten an der Kiste festhalten, meine Meinung ist ehr dass die Kiste anders strukturiert werden muss und das einmal mit einer komplett neuen VM. Man ist sich hier nur in den Details uneinig wie die neue VM genau konfiguriert sein soll ;-)

 

[Schongewusst99]

Technischer Ansatz:
Also für die vhdx ist es unerheblich woher der I/O Traffic kommt. WinSrv 2016 macht in diesem Fall auch kein großen Unterschied zwischen. Für Performance Engpässe auf der virtuellen NIC, solltest du am besten belastbare Zahlen von deinen VMware Spezialisten einholen.

Organisatorischer Ansatz:
Ein nicht zu vernachlässigendes Argument kann auch sein: dass die Infra so wie sie nun jetzt übernommen werden soll, ggf. zu viele Grauzonen mangels ausreichender Doku aufweist. Sprich du die Infra so nicht vertrauenvoll unter deine Obhut nehmen kannst. Dann kann durchaus eine Migration auf eine "saubere" Infra Sinn ergeben. Alleine für das Troubleshooting, weil bspw. dann eine vollständige Doku erstellt wurde.

Nichts ist bescheidener als ein Ausfall beim Kunden den man als Admin nicht schnell in den Griff bekommt, weil der Kolleg:in der es Jahre lang betreut hat in Rente ist und die Dokumentation im Kopf hat.

"vertraglich/gewährleistender" Ansatz:
Und Support: wenn man ein Dienstleister beauftragen muss und der auch nicht dafür gerade stehen kann/will.
---
Letzlich eine Frage der Verbindlichkeiten und Verantwortung. Übernehmen die Kollegen beides, wenn Ihr an dem System festhaltet oder du? Bei letzterem solltest du dann auch eine Infrastruktur wählen dürfen, mit der du deine Arbeit am effektivsten gestalten kannst. Für deinen Kunden zählt eh nur das Ergebnis. Und es gibt viele Wege bei WinSrv 2016 FileClustern dieses zu erreichen.

Kommentar: es macht natürlich am Anfang weit aus weniger Arbeit, einfach die gleiche Konfiguration wie immer aufzuspielen. Ich vertrete eher die Auffassung, einmal ordentlich/mehr Arbeit und dafür später Ruhe.