Backup von VM langsam

[informant]

Hallo, eine Frage zum Backup.
Wenn ich ein Backup fahre, zeigt er bei der Gescheindigkeit nur:
4132: 2017-08-20 00:15:07 INFO: status: 0% (174850048/128849018880), sparse 0% (133943296), duration 3, read/write 17/13 MB/s
4132: 2017-08-20 00:16:29 INFO: status: 1% (1288568832/128849018880), sparse 0% (187592704), duration 85, read/write 13/12 MB/s
4132: 2017-08-20 00:18:13 INFO: status: 2% (2577137664/128849018880), sparse 0% (328491008), duration 189, read/write 12/11 MB/s
4132: 2017-08-20 00:20:15 INFO: status: 3% (3873308672/128849018880), sparse 0% (337264640), duration 311, read/write 10/10 MB/s
4132: 2017-08-20 00:21:56 INFO: status: 4% (5161877504/128849018880), sparse 0% (463822848), duration 412, read/write 12/11 MB/s
4132: 2017-08-20 00:23:54 INFO: status: 5% (6484656128/128849018880), sparse 0% (497532928), duration 530, read/write 11/10 MB/s
4132: 2017-08-20 00:25:33 INFO: status: 6% (7742816256/128849018880), sparse 0% (593432576), duration 629, read/write 12/11 MB/s
...
an. Das ist etwas sehr langsam. Denn ich habe ein RAID 10 mit schnellen SSD festplatten sowie Cache und BBU am RAID Controller.
Sowie das Kopieren als auch das zippen geht lokal auf der Host-Maschine schnell. Warum ist dann das Backup einer VM so langsam? Was kann man hier tun damit dies schneller geht? Habe local getestet als auch auf eine nfs Storage. Beide mit selben Speedwerten im Backup. Freue mich auf Rückmeldung, wie man das beschleunigen kann, da es sonst eine Ewigkeit dauert.... Danke vorab.

 

[fireon]

Sieht nach nem 100Mbit Switch aus. Kontrolliere doch bitte mal die Anbindung. Wie wird denn gesichert? NFS/SMB ... GZIP?

 

[informant]

Hi, nein GBit HP Switch. Link beidseitig 1 Gbit/s Vollduplex. Wie geschrieben ist der Speed weder local mit gzip Backup noch per NFS gzip Backup anders.
-> 2017-08-20 20:34:27 INFO: transferred 26843 MB in 2064 seconds (13 MB/s)
Mache ich ein Backup direkt auf dem Host dieser VM, habe ich Vollspeed GBit auf local und NFS mit gzip.
Eine Idee?
MfG

 

[fireon]

Ok, ich komm da nicht mit. Du schreibst das der Speed local und NFS gleich schlecht. Machst du aber ein Backup direkt auf dem Host dieser VM dann mit Vollspeed, also dieser HOST ist ja LOCAL. Also was jetzt bitte genauer spezifizieren.

• pveversion -v
• Von wo nach wo wird gesichert? Von lokal zu einem anderen Host also remote, wie schnell? Auf dem gleichen Host gesichert wie schnell?
• Was für eine Komprimierung, Default oder Gzip, Gzip natürlich nur so schnell was deine Maschine berechnen kann, nimm also den Default, ist effizenter
• pveperf (NFSspeicher, lokaler Speicher, VM Speicher... was auch immer)
• Wo werden die VM's gespeichert?
• Was für ein Storageformat benutzt du?

 

[informant]

hi,

pveversion -v
proxmox-ve: 5.0-15 (running kernel: 4.10.15-1-pve)
pve-manager: 5.0-23 (running version: 5.0-23/af4267bf)
pve-kernel-4.10.15-1-pve: 4.10.15-15
libpve-http-server-perl: 2.0-5
lvm2: 2.02.168-pve2
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-10
qemu-server: 5.0-12
pve-firmware: 2.0-2
libpve-common-perl: 5.0-16
libpve-guest-common-perl: 2.0-11
libpve-access-control: 5.0-5
libpve-storage-perl: 5.0-12
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-2
pve-docs: 5.0-6
pve-qemu-kvm: 2.9.0-2
pve-container: 2.0-14
pve-firewall: 3.0-1
pve-ha-manager: 2.0-2
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.0.8-3
lxcfs: 2.0.7-pve2
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.6.5.9-pve16~bpo90

Gesichert wird von local auf eine nfs Storage (ext4) welche mit 1 Gbit/s angebunden ist. Kopiere ich Daten via gzip von local auf die Storage schaffe ich problemlos die Gbit. Mit dem Backup im Proxmox schafft er es nicht, da nur ~10 mb/s. Kompression keine schafft er 53-187 mb/s. Die vm liegt local. Das Proxmox System rennt auf 2 SSDs iM RAID 1.

pveperf
CPU BOGOMIPS: 383585.60
REGEX/SECOND: 579134
HD SIZE: 79.56 GB (/dev/mapper/pve-root)
BUFFERED READS: 249.78 MB/sec
AVERAGE SEEK TIME: 0.27 ms
FSYNCS/SECOND: 1445.20
DNS EXT: 48.17 ms
DNS INT: 58.47 ms

Auf einer reinen SSD RAID 10 Maschiene sieht das so aus:

pveperf
CPU BOGOMIPS: 134243.52
REGEX/SECOND: 2682382
HD SIZE: 93.99 GB (/dev/mapper/pve-root)
BUFFERED READS: 1939.80 MB/sec
AVERAGE SEEK TIME: 0.07 ms
FSYNCS/SECOND: 6316.28
DNS EXT: 46.52 ms
DNS INT: 52.68 ms

aber Backup zur Storage geht auch ohne Kompression nicht wirklich schneller... Scheinbar ist GBit hier am Ende mal auf 10 GB erhöhen.

Was aber komisch ist, ist das mit Kompression nur max 10mb/s erreicht werden... Und wenn man local etwas auf die Storage packt dies mit 100mb/s drauf geht. Jeweils mit GBit getestet,,, hier evtl. eine Idee? LZO ist bisl schneller 50-100mb/s, werd das mal damit laufen lassen statt mit gzip.

MfG

 

[Ralph]

Ganz dunkel erinnere ich mich, darüber schon mal etwas gelesen zu haben... vielleicht hilft ja dieser Post:

https://forum.proxmox.com/threads/vzdump-speed.3648/

Ralph

 

[fireon]

Danke für die Infos. Der Fsyncwert für dein SSD RAID 10 Maschine passt super. Der andere Fsyncwert... ist nicht die Welt, also so 3000+ solltest schon haben.

Naja also wie gesagt vergiss gzip, wenn dann müsstest schon pigz aktivieren, mit gzip wird ja immer nur ein Core verwendet. Gzip ist in effektiv. Ohne Komprimierung machts auch keinen Sinn. Das LZO finde ich ist wirklich am besten.

Was aber komisch ist, ist das mit Kompression nur max 10mb/s erreicht werden...

Da muss eben gerechnet werden. Wenn's unbedingt auf Gzip bestehst, aktiviere pigz, dann gehen alle Cores auf 100% beim sichern dann geht eben ja nach Maschinenstärke die Post ab, ist aber meistens trotzdem langsamer, da ist mir die bessere Komprimierung wohl egal.

 

[HBO]

Ich hänge mich hier mal dran, Setup wie folgt: VM Storage = ZFS Pool mit SAS 12G 7,2k rpm Platten mit NFS Backup per 10GE DAC auf ein Storage mit einem Raid 6. Allerdings habe ich während der Backups extrem schwankende Werte, dies sieht man vor allem ganz gut durch die letzte Meldung wie schnell die VM im Durchschnitt transferiert wurde:

INFO: transferred 107374 MB in 445 seconds (241 MB/s)
INFO: transferred 53687 MB in 758 seconds (70 MB/s)
INFO: transferred 107374 MB in 1927 seconds (55 MB/s)
INFO: transferred 53687 MB in 80 seconds (671 MB/s)

Das sind die Meldungen von 4 Backups die nacheinander durchgeführt worden sind. Ich habe langsam die Vermutung, dass umso aktueller das Betriebssystem in der VM und Discard bzw TRIM genutzt wird, desto schneller und effizienter das Backup. Wäre das tatsächlich möglich?
Ich habe hier zBsp so eine Debian 5 VM eines Kunden die auch tatsächlich seit Installation den Befehl "apt" nie wieder gesehen hat, diese VM kommt mit Glück auf 30MB/s Übertragung im Backup.

 

[fireon]

Es kommt auch drauf an ob die VM's laufen oder gestoppt sind. Probierts mal aus!

 

[HBO]

Ich darf nach Vorgabe nur Backups per Snapshot Mode machen. Da ich hier vor allem aus einem 36 Kern System ganze 30 VMs sichere wären die Downtimes gegen Ende nicht tragbar. Die Backups laufen derzeit um 0:00 Uhr an und sind zwischen 6 und 7 Uhr dann fertig.

 

[tom]

Ich darf nach Vorgabe nur Backups per Snapshot Mode machen. Da ich hier vor allem aus einem 36 Kern System ganze 30 VMs sichere wären die Downtimes gegen Ende nicht tragbar. Die Backups laufen derzeit um 0:00 Uhr an und sind zwischen 6 und 7 Uhr dann fertig.

Backups (qemu) im "Stop" mode bedeutet nicht, dass die VM während des Backups runtergefahren ist. Downtime ist lediglich die Zeit vom runterfahren und hochfahren, also höchstens ein paar minuten oder bei schlanken VMs, ein paar Sekunden.

https://pve.proxmox.com/wiki/Backup_and_Restore

 

[HBO]

Ok, werde ich dann mal testen (natürlich darf ich erstmal prüfen ob ein ACPI Shutdown von jeder VM möglich ist).
Würde es noch etwas bringen in der vzdump Konfiguration das "tmpdir" anzugeben? Wäre dies irgendwie möglich in einer Umgebung bei der kein lokaler Speicherplatz verfügbar ist aber ein ZFS Pool besteht auf dem VMs erstellt werden?

 

[informant]

Hi, danke für die Rückmeldung. Ja LZO geht gut. Nutzt LZO auch alle CPUs normal auch nur einen soweit ich weis... Ja, ohne Kompression ist nicht schön, da stimm ich dir zu. denn da kann man auch rsync direkt nehmen
MfG