Hintergrund
Ich habe einen Server, auf dem virtuelle Maschinen gehostet werden, und ein älteres NAS Synology DS1512+, das als Sicherungsziel für diese virtuellen Maschinen verwendet wird. Der Server verwendet ZFS, erstellt Snapshots und überträgt die Dateien der Snapshots auf das NAS. Das NAS verwendet BTRFS mit aktivierter Komprimierung und unterstützt ebenfalls Snapshots. Das ultimative Ziel wäre, dass der Server wirklich nur DELTAs mit RSYNC sendet, um die Menge der vom NAS empfangenen geänderten Daten zu minimieren und auch hier Snapshots effizient zu nutzen.
Problem
Die Verwendung von RSYNC mit DELTAs funktioniert in meinem Fall jedoch nicht, da die Übertragung der Daten einfach dauertzu viel Zeit. Wenn RSYNC mit verwendet wird --inplace --whole-file, dauert die Übertragung der Daten ca. 2 Stunden. Beim Entfernen --whole-filezur Nutzung von DELTAs dauert derselbe Sicherungsvorgang viel länger. Ich habe den Vorgang oft abgebrochen, nachdem er bereits 12+ Stunden gelaufen war. Aus historischen Gründen muss ich verschiedene Sicherungen in viel kleinere Zeitfenster einpassen.
Der einzige sinnvolle Engpass ist das NAS, da der Server viel leistungsstärker ist und die meiste Zeit im Leerlauf ist. Das NAS hingegen hat während der Sicherung eine ziemlich hohe CPU- und I/O-Last. Die Zahlen sind allerdings auch gar nicht so schlecht, sie sind nur schlechter als bei Verwendung von --whole-file. Damit schreibt das NAS einfach ~100+ MiB/s, während es mit DELTAs die meiste Zeit langsamer liest und zwischen ~50 und 100 MiB/s liegt. Ich dachte, dass die Datenmenge, die aufgrund von DELTAs NICHT geschrieben werden muss, die Tatsache des langsameren NAS leicht übertreffen würde, aber das scheint nicht der Fall zu sein. Und die geänderte Datenmenge auf den VMs ist meistens nicht zu hoch.
Überwachung
Was mir auf dem NAS aufgefallen ist, ist, dass RSYNC an einem bestimmten Punkt zwei Dateien gleichzeitig zu verarbeiten scheint. Das sieht nach einer Art Read-Ahead oder so ähnlich aus:
root@amds1512-01:~# lsof | grep [d]asi_
rsync 6883 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6883 root 0r REG 0,33 2142633984 580 /volume1/[...]/[...]-s024.vmdk
rsync 6884 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6884 root 1r REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
rsync 6884 root 3w REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
HTOP zeigt deutlich, dass beide Instanzen von RSYNC lesen. Ignorieren Sie einfach die anderen RSYNC-Prozesse, diese haben nichts damit zu tun und das Problem besteht weiterhin, selbst wenn ein Backup exklusiv ausgeführt wird.
Fragen
Was ist also der Zweck dieser beiden laufenden RSYNCs mit unterschiedlichen Dateien auf dem Sicherungsziel? Gibt es eine Möglichkeit, RSYNC anzuweisen, nur eine Datei nach der anderen zu verarbeiten?
Das könnte die Gesamtverarbeitungszeit bei geringerer gleichzeitiger Belastung erhöhen. Ich konnte in der Manpage nichts wie Read Ahead oder Ähnliches finden. Falls es einen Unterschied macht, werden die folgenden Optionen verwendet:
--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials
Danke!
Antwort1
Schauen Sie sich anSo funktioniert Rsync. Genauer gesagt gibt es einen Generatorprozess und einen Senderprozess, die als Pipeline fungieren. Der Sender liest die Datei, die an die Gegenstelle gesendet werden soll. Der Generator ist für die Generierung der Liste der zu sendenden Dateien verantwortlich. Außerdem werden „Blockprüfsummen für die Basisdatei erstellt und unmittelbar nach der Indexnummer der Datei an den Sender gesendet.“
Das klingt definitiv so, als ob es das Potenzial hat, ein Dateisystem-Thrashing zu verursachen, wenn Sie --inplacemehrere große Dateien sendenund nicht genügend RAM für den Kernel zur Verfügung steht, um zwei aufeinanderfolgende Dateien im Cache zu halten.
Sie können zum Test einzelne Dateien mit übertragen rsync --inpaceund prüfen, ob die Leistung deutlich besser ist. (So etwas wie for i in *.vmdk; do rsync [...]; done.) So sollten Sie feststellen können, ob Ihr Leistungsproblem tatsächlich durch zwei separate Lesegeräte verursacht wird.
Wenn mehrere LeserIstDas Leistungsproblem verursacht wird, dann wäre eine Möglichkeit, die Fähigkeit des Kernels zum Zwischenspeichern der Lesevorgänge zu verbessern, entweder indem dem Host-Kernel mehr RAM zur Verfügung gestellt wird oder indem Sie Ihre einzelnen VMDK-Dateien verkleinern.
Leider sehe ich keine offensichtliche Möglichkeit, das Verhalten der Generator-/Sender-Pipeline in rsync zu ändern, außer ein eigenes Skript zu schreiben, das rsync einmal für jede Datei aufruft. Sie können hierzu auf derrsync-Mailingliste.