2
Virtuelle Daten-Festplatte an virtuellen MS Fileserver anbinden
Hallo,
ich benötige einen "Best Practice" Ratschlag.
In einem VM Ware (ESXi 5.1) Cluster mit mehreren HP DL380 als Träger habe ich einen Windows Fileserver laufen.
Nun möchte ich einmal wissen, auf welchem Wege der 1,5 TB große Nutzdaten-Bereich (im SAN liegend) an das Windows System (VM im selben SAN) angeklemmt werden sollte.
Mir sind folgende Möglichkeiten bekannt:
1: Eine 1,5 TB VHD Datei im Datastorage erstellen und als weitere Festplatte in der Konfiguration der VM hinterlegen.
2: Eine 1,5 TB große LUN im SAN erstellen als RAW-Laufwerk in der VM-Config hinterlegen
3: Im Windowssystem über den iSCSI Dienst auf eine 1,5 TB große, im SAN zur Verfügung gestellte, LUN zugreifen.
1, 2 oder etwa 3?
Momentan wird Variante 1 verwendet. Allerdings finde ich Variante 2 deutlich charmanter. Wie läuft das bei euch?
ich benötige einen "Best Practice" Ratschlag.
In einem VM Ware (ESXi 5.1) Cluster mit mehreren HP DL380 als Träger habe ich einen Windows Fileserver laufen.
Nun möchte ich einmal wissen, auf welchem Wege der 1,5 TB große Nutzdaten-Bereich (im SAN liegend) an das Windows System (VM im selben SAN) angeklemmt werden sollte.
Mir sind folgende Möglichkeiten bekannt:
1: Eine 1,5 TB VHD Datei im Datastorage erstellen und als weitere Festplatte in der Konfiguration der VM hinterlegen.
2: Eine 1,5 TB große LUN im SAN erstellen als RAW-Laufwerk in der VM-Config hinterlegen
3: Im Windowssystem über den iSCSI Dienst auf eine 1,5 TB große, im SAN zur Verfügung gestellte, LUN zugreifen.
1, 2 oder etwa 3?
Momentan wird Variante 1 verwendet. Allerdings finde ich Variante 2 deutlich charmanter. Wie läuft das bei euch?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 232522
Url: https://administrator.de/forum/virtuelle-daten-festplatte-an-virtuellen-ms-fileserver-anbinden-232522.html
Ausgedruckt am: 09.04.2025 um 05:04 Uhr
2 Kommentare
Neuester Kommentar
Hi,
das ist fast Jacke wie Hose.
zu 2) Welche Technik? FC oder iSCSI
Falls iSCSI, dann sind 2 & 3 sind erstmal grundsätzlich gleich, weil beide mal RAW über iSCSI. Nur das der Host, dem die Platte präsentiert ist, verschieden ist.
Falls FC, dann würde ich V2 bevorzugen. Warum solltest Du dann damit Dein Ethernet belasten?
zu 3) iSCSI aus er VM raus ... Dann solltest Du aber dafür sorgen, dass dafür trotzdem ein separates Netz verendet wird.
Wenn Du Dir die Option offenhalten willst, die LUN mal an einen physischen Server zu hängen, dann solltest Du in jedem Fall eine RAW nehmen. Sonst würde ich es als VMDK aufbauen, weil die ESX dann gleich noch die IOpS optimieren.
E.
das ist fast Jacke wie Hose.
zu 2) Welche Technik? FC oder iSCSI
Falls iSCSI, dann sind 2 & 3 sind erstmal grundsätzlich gleich, weil beide mal RAW über iSCSI. Nur das der Host, dem die Platte präsentiert ist, verschieden ist.
Falls FC, dann würde ich V2 bevorzugen. Warum solltest Du dann damit Dein Ethernet belasten?
zu 3) iSCSI aus er VM raus ... Dann solltest Du aber dafür sorgen, dass dafür trotzdem ein separates Netz verendet wird.
Wenn Du Dir die Option offenhalten willst, die LUN mal an einen physischen Server zu hängen, dann solltest Du in jedem Fall eine RAW nehmen. Sonst würde ich es als VMDK aufbauen, weil die ESX dann gleich noch die IOpS optimieren.
E.
1
Grundsätzlich hatte ich bei den Varianten an iSCSI und nicht an FC gedacht.
Gibt es bei 2 & 3 tatsächlich keinen Unterschied? Ich hätte jetzt erwartet, dass es von Relevanz ist, von welchem Host der iSCSI Datenstrom entpackt wird.
Das mit der internen Optimierung vom ESX ist auch noch ein interessanter Punkt.
Wenn man iSCSI über ein separates Netz betreibt oder gleich FC nimmt, dürfte die Variante mit der zusätzlichen vmdk wohl die performanteste Lösung sein?
Gibt es bei 2 & 3 tatsächlich keinen Unterschied? Ich hätte jetzt erwartet, dass es von Relevanz ist, von welchem Host der iSCSI Datenstrom entpackt wird.
Das mit der internen Optimierung vom ESX ist auch noch ein interessanter Punkt.
Wenn man iSCSI über ein separates Netz betreibt oder gleich FC nimmt, dürfte die Variante mit der zusätzlichen vmdk wohl die performanteste Lösung sein?
