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?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 232522
Url: https://administrator.de/contentid/232522
Printed on: April 25, 2024 at 01:04 o'clock
2 Comments
Latest comment
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?
