VMware-Forum

Hallo zusammen

wir haben ca. 10 physikalische Raw device mit 2TB pro Stück nun haben wir ein paar neue Platten bekommen und ich würde die alten RAW device gerne abschaffen und auf dem neuen Speicher VMDK's daraus machen.

Die Raw device sind alle an Windows Server 2008 vmware's gebunden und dort sind unsere Fileserver, was bedeutet, dass Sie sehr voll mit Daten sind.

Daher darf dort keine zu große Downtime entstehen.

Was wäre eure Empfehlung für die Migration?
Und wie mache ich am besten die Migration, Storage vMotion geht ja nicht bei phys. Raw device so wie ich gelesen habe.

Viele Grüße
Bert

Einfach Kopieren?
1. Neue Platten einbinden
2. Daten kopieren (was nicht geht überspringen)
3. Alles was auf die alten Platten zugreift stoppen
4. Daten kopieren (nur geänderte / neue)
5. Laufwerk/Freigabe wechseln


evtl. ginge es auch automatisch mit DFS.

Neue Platten (evtl. neue Fileserver) mit in DFS Verbund, Daten werden repliziert, alte Server aus DFS Verbund, fertig, ohne Downtime. Da ich das aber noch nie verwendet hab, ist das reine Theorie und ich weiß nicht wie groß der initiale Aufwand ist das DFS aufzusetzen.

oder du baust ein Software Raid 1 drauf und machst den Spiegel dann kaputt, aber dann musst du (soweit ich weiß) für immer mit nem defekten Raid leben und das ich denke ich auch nicht gut.

kopieren stelle ich mir bei knapp 2TB Daten schwer vor, es handelt sich hier um 1000000 Excel, Word, Powerpoint Dateien und all diese Sachen die die Kollegen halt so speichern.
Außerdem sind es ca. 10 Raw device mit 2TB das wird ja das ganze Jahr dauern bis das fertig ist.

Gibt es da keine Lösung die ein wenig einfacher und schneller ist. Macht der VMware converter sowas nicht auch?

Ich mache das leider auch zum ersten mal daher will ich schon den schnellsten und sichersten Weg gehen.

Gruß
Bert

Hallo Bert,

kopieren mußt du eh, ob das nun das OS innerhalb der VM oder ein anderes Tool macht ist relativ egal.

RoboCopy oder RichCopy von Microsoft haben mehrere Vorteile.

• Es werden nur die benötigten Daten kopiert und nicht die kompletten 2 TB.
• Die Fragmentierung der Daten könnte sich deutlich reduzieren.
• Falls deine NTFS Filesysteme nicht aligned sind, kriegts du das damit behoben.
• RoboCopy/Richcopy erlaubt ein "zweistufiges" Kopieren, im ersten Lauf wird der Verzeichnisbaum erzeugt und danach die Daten kopiert. Das beschleunigt das Suchen im Verzeichnisbaum immens, da der Directory Tree dann an einem Stück auf der LUN liegt.
• Es besteht die Möglichkeit, das online zu machen und auf Änderungen während des Copy Jobs zu reagieren.
• Die Vorgehensweise ist dir als Windows Admin sicherlich vertrauter als andere Verfahren.

Alternativ könntest du das auch mit dem vmkfstools Befehl von ESXi machen.
vmkfstools -i <kompletter Pfad zur p/vRDM vmdk> <kompletter Pfad zur Ziel vmdk auf einem VMFS Datastore>

Damit kopierst du die Daten einer p/vRDM's in eine vmdk.

Gruß,
Ralf

Etwas OT @Bert:

Wenn ich das richtig verstehe, wollt ihr einen Filer mit 20TB erstellen / ablösen.
Wie macht ihr das mit der Hochverfügbarkeit?
Wie viele VMDKs sind geplant? Wieder 10 Stück?

Wir stehen vor ähnlichem Problem. Ca. 10TB zur Zeit noch auf Novell, die auf Windows 2012 R2 migriert werden müssen.
Auf einen Windows Cluster würde ich gerne verzichten, da man dann wieder Raw Devices nehmen muss.

Danke!

@stahly
Im Moment sind die Fileserver alle Windows 2008 R2 und C:\ ist VMDK
Leider sind die D:\ (Datenlaufwerke) alle Raw device und diese Raw device soll aus mehren Gründen abgelöst werden, durch normale VMDK Laufwerken. Die Server bleiben wie sie sind, es bleibt Windows 2008 R2 und DFS (ohne Replikation)

Im Grunde bleibt es für den User wie es ist, Hochverfügbarkeit ist nicht so das Thema, da es sich ja um ca. 10 Server handelt und sollte da mal einer wegbrechen können immer noch 90% der Mitarbeiter arbeiten weil Ihre Daten nicht betroffen sind.

Ich werde mal versuchen mich in die Geschichte mit dem vmkfstools einzulesen, da ich es gerne ohne direkten copy job im Windows machen würde, ansonsten wird es wohl Robocopy werden, habe da schon häufiger mit gearbeitet nur dauert das natürlich bei der Anzahl an Dateien ewig bis alles kopiert ist und danach nochmal syncronisiert wird.

Ich hoffe das hilft dir ein wenig.

Gruß
Bert

Hallo Bert,

wenn du z.B. RichCopy einsetzt, kannst du die Anzahl der parallellen Copy Jobs einstellen.

Habe damit erst vor kurzem ca. 14 TB von einer pRDM auf einem SAN Array über 2 GBit FC auf das andere geschoben.
Transferraten lagen bei über 100MB/s, viel schneller dürften andere Tools auch nicht sein.

Gruß,
Ralf

Tools:
emcopy
SecureCopy

Gruss
Joerg

Danke!

10 Server mit DFS wäre natürlich ne alternative Lösung.
Geplant ist bis jetzt ein dicker Filserver.

Mein Senf dazu:
Eine schnellere Methode wie Robocopy dürfte nur eine SAN-Copy sein.

Ein Robocopy Mirror-Abgleich ist relativ zackig durch wenn man eine identische Kopie des Stores irgendwo vorhalten möchten, damit eine Freigabe sehr schnell wieder Online ist.
--> Noch besser wenn via DFS Zugegriffen wird. Ich erstelle z.B. in der Regel ein zweites, aber deaktiviertes Ziel im DFS/Stamm. Entweder per Robocopy oder mit DFS-Replication. Robocopy ist in aller Regel etwas pflegeleichter als DFS, dafür nicht unbedingt zeitnah und erfordert auch eine gewisse Laufzeit. Um wirklich auch alle geöffneten Files zu sichern, muss mit VSS ein Snapshot in einem Ordner oder Laufwerk erstellt werden und diesen als Ground genommen werden. Dann bekommt auch Robocopy immer Zugriff.

Ein solches DFS-Ziel ist im Falle eines Ausfalle mit wenigen Klicks oder einem automatisierbaren Powershell-Script innerhalb kürzester Zeit umgehängt.


Mit Server 2012 /R2 hättest Du ein gutes Dedupe. SAN-Zugriffe werden unter Umständen schneller für vielverwendete Blöcke. Wäre zumindest der benötigte Festplattenplatz deutlichst kleiner. Aktuell noch nicht bei Kopiervorgängen sondern nur Storageverbrauch.

Den Gedanken hatten wir erst auch alles auf einen riesen Fileserver zu packen.
Da hätten wir aber Probleme bekommen, sobald der Server mal ausfällt ist alles weg
Außerdem hätte es so auch Probleme beim Backup gegeben, ein Server kann gar nicht die ganzen Daten an einem Wochenende wegschreiben auf Band/Platte daher war die Lösung mit mehreren Server die besser und wie gesagt sollte einer mal abbrauchen trifft es nur einen kleinen Teil der Firma.

Durch DFS haben aber alle den selben einstieg daher ist das O.K. zusätzlich könnten wir bei einem Server Tot schnell die Platte an einen anderen Fileserver hängen im DFS die Sache einstellen und schon wären die Daten wieder da.
Auch der Restore geht im Notfall so viel schneller wenn kleinere Server zurück gesichert werden als wenn ein Großer komplett neu eingespielt werden müsste.

Bis jetzt haben wir noch keine bessere Lösung dafür gefunden, daher gehen wir den Weg...

Gruß
Bert

Ein Backup mit Veeam und dann ein Restore. Bei der letzten Rücksicherung ist das mit ca. 250 MB/sec.über die Bühne gegangen.

Ich hatte neulich einen Fall da war ghost32.exe Version 11.5 mit grossem Abstand das schnellste Tool - 4-5 so schnell wie robocopy und teracopy
Wenn vmkfstools -i benutzt wird - könnte man das Kopieren im Hintergrund machen indem man vorher snapshots für die raw-devices erstellt

continuum hat geschrieben:Ich hatte neulich einen Fall da war ghost32.exe Version 11.5 mit grossem Abstand das schnellste Tool - 4-5 so schnell wie robocopy und teracopy
Wenn vmkfstools -i benutzt wird - könnte man das Kopieren im Hintergrund machen indem man vorher snapshots für die raw-devices erstellt

Aber nicht bei pRDMs.

Du meinst Snapshots ?

Wieso denn nicht ?
Ich nutze zB auch Snapshots und vmkfstools -i um P2V Importe bei sehr grossen physikalischen Platten zu machen - wenn die erlaubte Dowtime nicht ausreichen würde um die kompletten Daten zu kopieren.
Dafür boote ich eine LiveCD die die Platten via iSCSI bereitstellt. Die iSCSI-targets werden dann als RDM einer neuen VM bereitgestellt bei der ich dann sofort einen Snapshot erstelle.
In dem Snapshot werden dann die Treiberanpassungen gemacht und der neu importierte Gast kann schon nach einer Stunde den Betrieb aufnehmen - bevor alle Daten kopiert sind.

Man hat dann performance Einbussen solange die Basis-vmdk noch über iSCSI eingebunden ist - dafür spielt es abere keine Rolle mehr ob das Kopieren ein paar Stunden oder Tage dauert.

Vielleicht stehe ich auf dem Schlauch, aber Snapshots sind bei pRDMs doch nicht möglich.

Ja - so stehts im Handbuch.

Verwendet man die pRDM jetzt in einer VM die diese wiederum via iSCSI bereitstellt sieht die Sache wieder anders aus.
Das steht dann auch nicht mehr im Handbuch

Klingt für mich wie durch die Brust zur Hand ins Auge und könnte Thema beim nächsten Telefonat werden.

Was ich bei Robocopy noch vergessen habe: Unter den neuen OS gibts den Flag /J welcher den Buffer umgeht und grosse Files wie eben unsere virtuellen Discs deutlich schneller kopiert werden.

Ansonsten: Ein auch sehr schnelles Tool soll Eseutil von Exchange sein. Ursprünglich mal dazu gedacht Exchange-DB's zu defragmentieren. Kann aber auch als File-Copy-Tool verwendet werden. Bei Files über 10GB angeblich schneller als Robocopy. Wirkliche Performance-Vergleiche habe ich aber noch nie gemacht.