joedevlin
Goto Top

Virtualisierung eines Fileservers

Guten Morgen!

Wir haben zurzeit einen physikalischen Windows 2003 R2 Fileserver, dieser hat eine 1,2 TB große Partition D: auf der einige Freigaben für Anwender liegen (Benutzer- und Gruppen- bzw. Projektverzeichnisse). Die Partition D: ist keine Festplatte im lokalen Server sondern eine LUN in unserem SAN.

Wir möchten den Fileserver nun als virtuelle Maschine in unserer ESX-Umgebung laufen lassen, da es sich zurzeit um ein angepasstes 2003 R2 mit Branding handelt (keine Virtualisierung mit Converter erlaubt/möglich), wird eine neue Installation mit 2008 R2 als VM vorgenommen.

Es geht nun darum, dass die Daten der Partition D: über den neuen Server bereitgestellt werden müssen, hierzu habe ich mir folgende Schritte überlegt:

1. Installation der VM mit 2008 R2 (nur Partition Cface-smile
2. Abschaltung des alten Fileservers
3. Hinzufügen der LUN des alten Fileservers als vRDM am neuen Fileserver mit Laufwerksbuchstaben D:

Der Zugriff auf die Daten erfolgt fast ausschließlich über ActiveDirectory Benutzer und Gruppen, der neue Fileserver bekommt den gleichen Namen und die gleiche IP-Adresse wie der alte Fileserver. Die NTFS-Berechtigungen sollten hier also weiterhin greifen.

Es gibt für einige Maschinen zwei lokale Benutzer, diese müssten neu angelegt werden und die Berechtigungen in den entsprechenden Verzeichnissen gesetzt werden.

Ich habe das ganze bereits mit einem Snapshot der LUN getestet, hier hat alles wie gewünscht funktioniert.

Spricht etwas gegen diese Vorgehensweise oder gibt es eine "bessere" Lösung?

Die Alternative für den neuen Server eine LUN in gleicher Größe anzulegen und die Daten z.B. mit Robocopy zu kopieren scheidet leider aus, da nicht genügend Speicherplatz im SAN bereitsteht. Ich denke aber, dass das zu meiner Lösung auch keinen Unterschied macht.

Viele Grüße & Danke für wertvolle Tipps!

Content-ID: 226084

Url: https://administrator.de/contentid/226084

Ausgedruckt am: 22.11.2024 um 19:11 Uhr

CopyPaste
CopyPaste 08.01.2014 um 10:35:09 Uhr
Goto Top
Guten Morgen Redhorse

ich habe vor kurzer Zeit auch einen solchen Umzug eines FS auf Win2k8R2 durchgeführt, bei uns war es allerdings eine NTFS Platte und wir haben den Weg über Robocopy gewählt. Alle Dateien und Berechtigungen wurden sauber übernommen.
Es waren auf einer Partition sogar Roaming Profiles (da hatte ich echt ein bisschen Schiss^^ ), die dann auch auf dem neuen FS weiter von den Usern genutzt werden konnten.
Bei uns hat der neue FS auch den gleichen Namen/IP.

Also viel Erfolg, ist kein Hexenwerk face-wink
Chonta
Chonta 09.01.2014 um 08:31:00 Uhr
Goto Top
Hallo,

die Freigaben musst Du aber auch noch so einrichten wie auf dem alten Server.
Wenn möglich auf Server 2012 gehen wegen SMB3.


Gruß

Chonta
goscho
goscho 09.01.2014 um 09:59:58 Uhr
Goto Top
Moin redhose,

Der Zugriff auf die Daten erfolgt fast ausschließlich über ActiveDirectory Benutzer und Gruppen, der neue Fileserver bekommt den gleichen Namen und die gleiche IP-Adresse wie der alte Fileserver. Die NTFS-Berechtigungen sollten hier also weiterhin greifen.
Wie denn, wenn die Freigaben alle weg sind?

Du musst die Freigaben neu erstellen.

Schau dir mal das File Server Mogration Toolkit von MS an. Das ist genau für deine Zwecke (Wechsel des Filservers) gemacht worden.
JoeDevlin
JoeDevlin 09.01.2014 um 10:23:56 Uhr
Goto Top
Die Freigaben müssen natürlich neu eingerichtet werden, ebenso die lokalen Benutzer sowie die damit verbundenen NTFS-Berechtigungen. Es handelt sich aber nur um 5 Freigaben sowie 4 lokale Benutzer, das sollte kein Problem darstellen.

Danke für den Hinweis auf das Microsoft File Server Migration Toolkit 1.2, da wir kein DFS verwenden und IP und Hostnamen behalten und nur die LUN an den neuen Server anbinden, wird das Tool aus meiner Sicht nicht benötigt. Es gibt doch kein Tool, dass die lokalen Benutzer samt SID migriert, oder?
loonydeluxe
loonydeluxe 09.01.2014 um 21:53:32 Uhr
Goto Top
Die Freigaben kannst du auch aus der Registry exportieren (HKLM\SYSTEM\CurrentControlSet\Services\LanManServer) und wieder importieren. Die Pfade kannst du in der Reg-Datei oder auch nach Import anpassen. Danach nochmal neustarten.

Die Berechtigungen sind im Sub-Schlüssel "Security". Sofern die passen ist alles gut.

Hast du dir das mit der Latenz zum Storage auch überlegt? Immerhin werden die Clients die Requests an den virtualisierten Fileserver stellen, der wiederrum die Daten vom LUN abrufen muss. Falls dort noch andere Dienste laufen, die intensiv auf dem Storage rumeiern, kann das die Datenübertragung doch deutlich verlangsamen.
JoeDevlin
JoeDevlin 09.01.2014 um 22:12:22 Uhr
Goto Top
Danke für den Tipp mit den Freigaben!

Ich habe eine Performance-Analyse des physikalischen Fileservers durchgeführt, mit der Virtualisierung ansich sollte es garkeine Probleme geben, zumal wir ein neues Storage anschaffen das nochmal deutlich mehr iops schafft. Für die vRDM entscheide ich mich vorerst auf Grund der einfachen Umsetzung, im zweiten Schritt soll die vRDM dann in eine VMDK gewandelt werden.

Bezüglich der Leistung der vRDM gegenüber VMDK gibt es wohl keine größeren Unterschiede mehr:
http://blogs.vmware.com/vsphere/2013/01/vsphere-5-1-vmdk-versus-rdm.htm ...
loonydeluxe
Lösung loonydeluxe 09.01.2014 aktualisiert um 22:23:42 Uhr
Goto Top
Auch wenn du ein performantes Storage hast... durch die VM (und der Last auf dem Host) mit angebundenem Storge und deren Netzwerkverbindungen (und wiederum deren Last auf dem Host bzw. dem Storage) und den Switches und den anderen Geräten, die noch dazwischenhängen könnten, entsteht dann die Latenz, die der Nutzer zu spüren bekommt. Sind denn die Komponenten zwischen VM und Storage hinreichend performant?
JoeDevlin
JoeDevlin 09.01.2014 um 22:23:45 Uhr
Goto Top
Ich denke schon, da der physikalische Server aktuell über die gleichen Switche auf das gleiche Storage zugreift, nach der Virtualisierung erfolgt der Zugriff über die ESX-Hosts, die aber noch sehr viel Luft haben. Die Virtuelle Maschine sowie die LUN liegen auf dem gleichen Storage.
JoeDevlin
JoeDevlin 18.01.2014 um 22:28:05 Uhr
Goto Top
Ich kann nun nach einer Woche sagen, dass meine ursprüngliche Planung voll funktioniert hat.