emeriks
Goto Top

Robocopy Multithreading

Hi,
mir ist soeben aufgefallen:

Windows Server 2008 R2
Ein Ordner eines lokales Laufwerks mit vielen Ordnern (> 4 Millionen) und viele kleine Dateien (ca. 600.000) soll auf ein anderes lokales Laufwerk kopiert werden.
Der Server muss rund um die Uhr in Betrieb bleiben. Die Umschaltung der Software auf das neue Laufwerk kann nur in einem eingekündigten Wartungsfenster erfolgen.
Die Idee:
  1. Initial-Kopie erstellen mit Robocopy
  2. anschließend wiederkehrend Differenz-Kopien erstellen, ebenfalls mit Robocopy
  3. zur Wartung die Software aus
  4. letzte Differenz-Kopie
  5. Software auf neues Ziel anpassen

Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)

Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.

Wo ist mein Denkfehler?

Bsp. für Kommando:
robocopy D:\Quelle\3 F:\Ziel\3 /MIR /B /COPY:DAT /R:0 /W:0 /NP /MT:64 /NFL /NDL /LOG:E:\Robocopy\Logs\%date%\Robocopy_Diff_D_Quelle_3_%date%.log


Randinformationen:
AV-Scanner deaktiviert
Quell- und Ziel-LUN liegen auf einem SAN, welches mit 4-GB-FC angeschlossen ist.
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).


E.

Content-ID: 558022

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

Ausgedruckt am: 14.11.2024 um 11:11 Uhr

GrueneSosseMitSpeck
GrueneSosseMitSpeck 15.03.2020 um 18:41:54 Uhr
Goto Top
vielleicht die Kombination der Optionen... lt Robocopy Optionsliste bietet sich da /A-:A an was das Archiv-Flag an der Quelle zurücksetzt, dann würde /B auch Sinn machen. Eventuell überstimmt das /MIR das dann.
Lochkartenstanzer
Lochkartenstanzer 15.03.2020 aktualisiert um 19:02:48 Uhr
Goto Top
Moin,

Mit Robocopy kannst Du das vergessen.

Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.

Tools wie Robocopy oder rsync brauchen zu lange um jede einzelne Datei anzuschauen, selbst wenn sie nicht kopiert wird. Das Problem sind die Filesystemstrukturen von NTFS.

lks
SeaStorm
SeaStorm 15.03.2020 um 19:18:44 Uhr
Goto Top
Hi

ich denke nicht das man hier mit Robocopy weit kommt. Das muss ja immer alle Ordner und Dateien angucken.
Wenn es LUNs sind, warum hängst du sie nicht einfach um?

Wenn das keine Option ist, würde ich hier vielleicht probieren einen Filesystemwatcher zu starten und einfach alles was auf dem Original geschrieben wird auch auf B kopieren.
Evtl. könnte man ja mit Windows Replication arbeiten, also das ganze per DFSR erledigen lassen. Aber ich habe keine Ahnung wie das mit solchen Mengen an Ordnern zurecht kommt.
Penny.Cilin
Penny.Cilin 15.03.2020 um 19:59:31 Uhr
Goto Top
'n Abend emeriks,

Zitat von @emeriks:

Die Idee:
  1. Initial-Kopie erstellen mit Robocopy
  2. anschließend wiederkehrend Differenz-Kopien erstellen, ebenfalls mit Robocopy
  3. zur Wartung die Software aus
  4. letzte Differenz-Kopie
  5. Software auf neues Ziel anpassen

Die Differenz-Kopien dieses Ordnern dauern 8-9 Stunden(!), obwohl sich dort nur ca. 100 Dateien ändern. Das sind dann ein paar Megabyte.
Das Gros der Zeit geht wahrscheinlich beim Suchen nach den Änderungen drauf.
Diese extrem lange Dauer sprengt das Wartungsfenster, welches wir i.A. dafür bekommen (ca. 2-4 h max.)

Ich habe mit verschiedenen Werten für den /MT -Parameter experimentiert. Keine Änderung.
Und da ist mir aufgefallen:
Ich hatte bisher immer angenommen, dass der /MT Parameter tatsächlich steuert, in wieviel Threads der Prozess die Such- und Kopier-Vorgänge laufen lässt. Defacto ist es aber so, dass - egal was ich einstelle - im Taskmanager für den Robocopy-Prozess angezeigt wird, dass dieser immer nur in 2-3 Threads läuft.

Wo ist mein Denkfehler?

Bsp. für Kommando:
> robocopy D:\Quelle\3 F:\Ziel\3 /MIR /B /COPY:DAT /R:0 /W:0 /NP /MT:64 /NFL /NDL /LOG:E:\Robocopy\Logs\%date%\Robocopy_Diff_D_Quelle_3_%date%.log
> 
Wieviel Merne hat der Rechner auf dem Robocopy ausgeführt wird?
Meines Wissens nach ist dr parameter /MT abhängig von der Anzahl der Cores.
Ausserdem hast Du mal mit den Parameter /ZB bzw. /Z oder /B versucht?
Welche Robocopy Version wird verwendet?
Es gab eine Robocopy Version, welche mit einer GUI ausgeliefert wurde, welche fehlerhaft war.

Der Differential Copy sollte nicht so lange dauern. Ich habe 2010 einen Fileserver mit der damaligen Robocopy Version von W2K3 R2 migriert.
Der initial Copy dauerte lange, dafür war der Differential Copy recht fix.

Gruss Penny.
erikro
erikro 15.03.2020 aktualisiert um 22:10:45 Uhr
Goto Top
Moin,

Zitat von @emeriks:
Windows Server 2008 R2

Öffentlicher Dienst? face-wink

Ich würde das ganz anders machen:

Ein DFS,das mit dem neuen Server repliziert, einrichten und dreimal hingucken, ob da auch wirklich das richtige primäre Mitglied steht. Dann die erste Replikation abwarten. Das dürfte einige Zeit dauern.

Theoretisch müsstest Du dann sogar ganz ohne großartiges Wartungsfenster auskommen, da ja die Daten im DFS immer synchron sind. Software auf dem alten Server ab- und auf dem neuen anschalten. Fertig.

Wo ist mein Denkfehler?

Oder habe ich einen Denkfehler? Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht. face-wink

Liebe Grüße

Erik
emeriks
emeriks 15.03.2020, aktualisiert am 16.03.2020 um 09:46:40 Uhr
Goto Top
Zitat von @GrueneSosseMitSpeck:
/A-:A an was das Archiv-Flag an der Quelle zurücksetzt,
dann würde /B auch Sinn machen.
/B ist dabei. Oder meinst Du das in Kombination mit /A ? Falls ja, wo soll da ein Zusammenhang bestehen?
/A bedeutet ja nicht, dass er nicht auch das Ziel überprüft, was er löschen muss, wegen /MIR.
emeriks
emeriks 15.03.2020 um 22:57:35 Uhr
Goto Top
Zitat von @SeaStorm:
ich denke nicht das man hier mit Robocopy weit kommt. Das muss ja immer alle Ordner und Dateien angucken.
Ja, darum geht es ja.
Wenn es LUNs sind, warum hängst du sie nicht einfach um?
Ich kann die LUN nicht umhängen, weil wir aus einer RAW-LUN unter VMware eine VMDK machen müssen.

Wenn das keine Option ist, würde ich hier vielleicht probieren einen Filesystemwatcher zu starten und einfach alles was auf dem Original geschrieben wird auch auf B kopieren.
Das habe ich sogar flugs programmiert. Nur fliegt das selbst als x64-Programm immer wieder um die Ohren. Ich vermute, wegen der immensen Struktur.

Evtl. könnte man ja mit Windows Replication arbeiten, also das ganze per DFSR erledigen lassen.
Jain. Da war ich auch schon.
Erstmal ist es eine Kopie auf dem selben Server. DFS-R geht bloß zwischen Servern. Aber ich könnte die neue LUN (VMDK) temporär an eine andere VM hängen. Allerdings fürchte ich, würde DFS-R bei dieser großen Ordneranzahl ne Ewigkeit brauchen, um überhaupt erstmal die Erstsynchronisation fertig zu bekommen.
emeriks
emeriks 15.03.2020 um 23:04:17 Uhr
Goto Top
Zitat von @Penny.Cilin:
Wieviel Merne hat der Rechner auf dem Robocopy ausgeführt wird?
Meines Wissens nach ist dr parameter /MT abhängig von der Anzahl der Cores.
VMware VM mit 6 vCPU und 24 GB RAM

Ausserdem hast Du mal mit den Parameter /ZB bzw. /Z oder /B versucht?
Was würde /Z hier ändern?
Und ja, /B nutze ich bereits.

Welche Robocopy Version wird verwendet?
Original-Version vom Windows Server 2008 R2
Das verrät /? nicht.
Laut Dateieigenschaften: 5.1.10.1027, vom 21.11.2010

Es gab eine Robocopy Version, welche mit einer GUI ausgeliefert wurde, welche fehlerhaft war.
Ich weiß bloß, dass es Drittanbieter gibt, welche GUIs dafür anbieten. Diese machen aber nichts anderes, als die Kommandozeilen zusammenzubauen.

Der Differential Copy sollte nicht so lange dauern. Ich habe 2010 einen Fileserver mit der damaligen Robocopy Version von W2K3 R2 migriert.
Der initial Copy dauerte lange, dafür war der Differential Copy recht fix.
So kenne ich das auch. Bei Millionen von Dateien und ein paar Tausend an Ordnern. Aber hier sind es Millionen von Ordnern.

Aber meine Frage war ja eigentlich der Zusammenhang zwischen Parameter /MT und der Anzahl Threads, in welchen der Prozess läuft.
emeriks
emeriks 15.03.2020 aktualisiert um 23:08:37 Uhr
Goto Top
Zitat von @erikro:
Ein DFS,das mit dem neuen Server repliziert, ....
Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht. face-wink
He, he.
Aber siehe meine anderen Kommentare an @SeaStorm und @Penny.Cilin

Windows Server 2008 R2
Öffentlicher Dienst? face-wink
Nee, Krankenhaus.
Der Server wird demnächst ersetzt. Zuvor muss die VM die Hardware wechseln. Im konkreten Fall geht nur eine Replikation der VM über LAN. Aber dafür müssen wir zuerst die RAW-LUN los werden.
emeriks
emeriks 15.03.2020 um 23:11:46 Uhr
Goto Top
Zitat von @Lochkartenstanzer:
Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Das geht nur offline. Und bei 3 TB insgesamt wird das auch 8-9 h dauern. Wenn nicht gar länger.
Aber diese Idee ist nicht mal doof. Wenn schon solch ein langes Fenster, dann könnten wir die LUN auch gleich auf Blockebene 1:1 klonen.
livetosuffer
Lösung livetosuffer 16.03.2020 um 09:04:33 Uhr
Goto Top
Hi Emeriks,
versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
emeriks
emeriks 16.03.2020 um 09:05:05 Uhr
Goto Top
Ich habe jetzt ein altes 32bit-Tool von EMC ausgegraben: EMCopy 4.17
Das arbeitet bei meinem Test tatsächlich in 68 Threads, die CPU-Last des Prozess geht ordentlich hoch.
Mal sehen, wie lange dieses für den Abgleich benötigt.
emeriks
emeriks 16.03.2020 um 09:13:56 Uhr
Goto Top
Zitat von @livetosuffer:
versuchs mal mit der einer RC Version ab Server2012R2 ( 6.2.9200)- ich hatte das Problem auch schon. Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
Die Versionen von Windows Server 2012 R2 und 2016 laufen nicht unter 2008 R2. Jedenfalls bekomme ich da gemeldet, dass das keine gültige Win32-Anwendung wäre.
emeriks
emeriks 16.03.2020 um 09:16:49 Uhr
Goto Top
EMCopy scheint es zu richten! face-smile
Ein erster Test hat für die Differenz ca. 40 min benötigt, dabei 250 Dateien mit insgesamt(!) 1 MB kopiert, und 950 Verzeichnisse erstellt.
Lochkartenstanzer
Lochkartenstanzer 16.03.2020 aktualisiert um 09:18:29 Uhr
Goto Top
Zitat von @emeriks:

Zitat von @Lochkartenstanzer:
Da hilft nur, das komplette Filesystem zu kopieren, z.B. mit ntfsclone oder einem anderen Clone-Utility.
Das geht nur offline. Und bei 3 TB insgesamt wird das auch 8-9 h dauern. Wenn nicht gar länger.
Aber diese Idee ist nicht mal doof. Wenn schon solch ein langes Fenster, dann könnten wir die LUN auch gleich auf Blockebene 1:1 klonen.

Von welchen Datenmengen reden wir denn überhaupt?

Wenn Du sagst
Quell- und Ziel-LUN liegen auf einem SAN, welches mit 4-GB-FC angeschlossen ist.
SAN langweilt sich. Quell- und Ziel-LUNs liegen auf verschiedenen RAIDs. Antwortzeiten <5 ms. IOpS bei max. 1000. Das SAN kann aber > 10.000 je Controller und Aggregat (RAID).

Dann sollte eine Kopie mit ntfsclone, das nur die vom filesystem "benutzen" in sehr kurzer Zeit druch sein.

Bei der obigen Konfiguration würde ich für 4T "Blockdaten" ca 2,5h bis 3h erwarten.

lks

PS: 10.000 IOPS hört sich zwar viel an, aber sehr kleinen Dateien sind das bei 4k Blockgröße "nur" 40MB/s was immer noch mindestens Faktor 10 unter dem theoretisch möglichen Höchstwert liegt.
emeriks
emeriks 16.03.2020 um 09:34:37 Uhr
Goto Top
Zitat von @Lochkartenstanzer:
Von welchen Datenmengen reden wir denn überhaupt?
... Und bei 3 TB insgesamt ....
emeriks
emeriks 16.03.2020 aktualisiert um 09:40:59 Uhr
Goto Top
Zitat von @livetosuffer:
Eine Version zwischen 2008 und 2012R2 war buggy und hat den MT Schalter ignoriert.
Diese Aussage ist schon mal richtig!
Danke!
Habe soeben mal auf einem aktuellen Win2016 getestet, und da kann man sehrwohl im Taskmanager sehen, dass der Prozess bei /MT mit mehr als der in Parameter angegeben Threads läuft. Bei /MT:64 z.B. mit 68.

Danke an alle fürs Mitwirken! Ich hatte schon an mir selbst gezweifelt ...
Lochkartenstanzer
Lochkartenstanzer 16.03.2020 um 09:41:27 Uhr
Goto Top
Zitat von @emeriks:

Zitat von @Lochkartenstanzer:
Von welchen Datenmengen reden wir denn überhaupt?
... Und bei 3 TB insgesamt ....

Ups, habe ich übersehen, obwohl ich es oben sogar selbst zitiert habe. face-smile

Also bei Blockkopie etwas weniger als zwei Stunden., wenn man ein intelligentes Imageing-Programm wie ntfsclone nutzt.

lks
erikro
erikro 16.03.2020 um 10:22:34 Uhr
Goto Top
Moin,

Zitat von @emeriks:

Zitat von @erikro:
Ein DFS,das mit dem neuen Server repliziert, ....
Gerade bei Dir hätte ich das als erste Option erwartet oder eine Bemerkung, warum das nicht geht. face-wink
He, he.
Aber siehe meine anderen Kommentare an @SeaStorm und @Penny.Cilin

Jo, das erklärt es unmittelbar. face-wink

Windows Server 2008 R2
Öffentlicher Dienst? face-wink
Nee, Krankenhaus.

Knapp daneben. face-wink Ich habe im öffentlichen Dienst letzt noch einen XP-Rechner gesehen. Huh!

Der Server wird demnächst ersetzt. Zuvor muss die VM die Hardware wechseln. Im konkreten Fall geht nur eine Replikation der VM über LAN. Aber dafür müssen wir zuerst die RAW-LUN los werden.

Das kenne ich. Wir haben das gleiche Problem mit XEN-Maschinen, die auf einen neuen Server umgezogen werden sollen. Das ist gerade am WE gescheitert. 60 Stunden sollte das dauern. face-sad Also nächstes WE am Freitag anfangen und hoffen, dass es bis Sonntag nachmittag durch ist.

Liebe Grüße

Erik
Penny.Cilin
Penny.Cilin 16.03.2020 um 14:59:04 Uhr
Goto Top
Zitat von @emeriks:

Ich habe jetzt ein altes 32bit-Tool von EMC ausgegraben: EMCopy 4.17
Das arbeitet bei meinem Test tatsächlich in 68 Threads, die CPU-Last des Prozess geht ordentlich hoch.
Mal sehen, wie lange dieses für den Abgleich benötigt.
Du weißt, dapß es EMCopy auch als x64 Version gibt?
Dilbert-MD
Dilbert-MD 16.03.2020 um 15:13:26 Uhr
Goto Top
Hallo,

bei unserem Backup ist mir aufgefallen, dass das Einlesen bei einem zweiten Durchlauf deutlich schneller geht; ähnlich wie bei Windows die Abfrage von Ordner- oder Laufwerkseigenschaften.

Möglicerweise kannst Du noch etwas Zeit gewinnen, wenn wenn der vorletzte Durchlauf zeitlich nicht zu weit vom finalen Durchlauf entfernt ist.

Gruß
emeriks
emeriks 16.03.2020 um 15:17:00 Uhr
Goto Top
Du weißt, dapß es EMCopy auch als x64 Version gibt?
Schon gefunden face-smile