vzDump - CEPH - 40G Ethernet

Quickly · Jul 8, 2019

Hallo.

Bei mir ist das vzDump per NFS extrem lahm geworden seit der Umstellung auf Cluster/HA und CEPH.
Kann mir dazu jemand was sagen?

# Umgebung
Ich habe für CEPH ein 40G LAN und habe gerade in Enterprise SSD´s investiert. Die generelle Geschwindigkeit ist gut. Aber das Backup per vzDump dauert "Ewigkeiten".
Bemerkung: Die Sicherung geht auf eine NAS (ist gleich geblieben) und hat 10G Anbindung. Der Lastmonitor der NAS zeigt extreme Schwankungen, es kommt bei der NAS nix an! Es schwankt von einigen kB bis 120MB/s. Mehr kommt nicht.
Selbst wenn ich bedenke, das die NAS mit der Anzeige wohl nicht so ganz richtig ist... trotzdem ist es extrem lahm.

# Zahlen
Wenn ich jetzt 500GB vzDump mache (Stop -> NFS -> NAS), dann läuft der Job 6,5 Stunden!

# Vorher
Vorher hatte ich 10G LAN + einen Proxmox (Desktop SSD´s) ohne CEPH. Und da hat es 2,5 Stunden gedauert bis die 500GB per vzDump weggesichert waren.

Hat da jemand eine Idee?

Vielen Dank, Lars

Alwin · Jul 8, 2019

Quickly said:
Hat da jemand eine Idee?

Viele.

Wie sind die Werte eines 'rados bench' , insbesondere von einem 'seq' Test?
Die genauen Befehle dafür stehen im Ceph Benchmark Paper.
https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2018-02.41761/

Code:

fio --ioengine=libaio –filename=/mnt/pve/<storage>/test.fio --direct=0 --sync=1 --rw=write --bs=64K
--numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=fio

Was schafft den das NAS, wenn du einen FIO test von einer Node darauf machst?

Was für ein Backup Mode wird den verwendet?

Quickly · Jul 9, 2019

Hallo Alvin. Erst mal vielen Dank für die schnelle Antwort. Die geforderten Info´s kommen gleich Unten.
Hier jetzt erst mal die Antwort die Du bestimmt lieben wirst: Das ging ja vorher auch!

# Alte Umgebung
3x ProxMox 5.x (neuste Version) Cluster -> Ein ProxMox hatte 18x 1TB Consumer SSD. Diese Festplatten waren ext4 und per NFS freigegeben. Alle ProxMox haben per LAN/NFS/10G auf diese ext4 zugegriffen. Das vzDump ging auf die identische NAS (4 VM´s) in 2,5 Stunden. Es sind ca. 600GB.

# NEUE Umgebung
3x ProxMox 5.x (neuste Version) Cluster -> alle ProxMox haben 4x 960GB Samsung Enterprise SSD (CEPH) = 12x 960GB. LAN für CEPH ist jetzt bei 40G (die Teile hatte ich noch).
Alles weitere ist geblieben wie gehabt. NAS ist geblieben, CPU, RAM, alle ProxMox sind HP DL380 G8, usw.

# Fazit
Sinn oder Unsinn von 40G... die Enterprise SSD´s haben reichlich Speed im Betrieb gebracht. CEPH stellt die Redundanz sicher. Hier würde ich sagen: Redundanz kostet Speed, ok. Aber von 2,5 Stunden auf 6,5 Stunden... das ist heftig.
Es muss also irgendwo an vzDump/CEPH liegen. Denn hier hat die einzige wirkliche Änderung stattgefunden.

# Vielleicht...
Und hier kann ich echt nix sagen... deswegen schreibe ich hier. Ich habe bzgl. vzDump absolut keine Anpassungen vorgenommen, OutOfTheInstallISOBox.
Irgendwo habe ich gelesen, das CEPH mit 4MB Blöcken arbeitet. Kann es sein, dass hier der Hase im Pfeffer liegt? Muss man vzDump vielleicht auch sagen: Rechne in 4MB Blöcken???

# Nicht...
Ich habe Versucht... MTU 1500 & MTU 9000 & wieder 10G für CEPH & Bond raus, Bond rein... usw. Keinerlei Änderungen. Ich bin hier ratlos.

# RADOS

Code:

rados -p rbd_ssd bench 60 write -b 4M -t 16 --no-cleanup

Code:

Total time run:         60.066653
Total writes made:      15899
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     1058.76
Stddev Bandwidth:       48.5287
Max bandwidth (MB/sec): 1148
Min bandwidth (MB/sec): 948
Average IOPS:           264
Stddev IOPS:            12
Max IOPS:               287
Min IOPS:               237
Average Latency(s):     0.060438
Stddev Latency(s):      0.0287365
Max latency(s):         0.339246
Min latency(s):         0.0208683

# FIO

Code:

fio --ioengine=libaio -filename=/mnt/pve/BackupDaily/test.fio --direct=0 --sync=1 --rw=write --bs=64K --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=fio --size=4G

Code:

root@proxmox67:/tmp# fio --ioengine=libaio -filename=/mnt/pve/BackupDaily/test.fio --direct=0 --sync=1 --rw=write --bs=64K --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=fio --size=4G
fio: (g=0): rw=write, bs=64K-64K/64K-64K/64K-64K, ioengine=libaio, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/127.1MB/0KB /s] [0/2047/0 iops] [eta 00m:00s]
fio: (groupid=0, jobs=1): err= 0: pid=2236275: Tue Jul  9 15:29:19 2019
  write: io=7125.9MB, bw=121612KB/s, iops=1900, runt= 60001msec
    slat (usec): min=243, max=79419, avg=511.28, stdev=395.92
    clat (usec): min=2, max=441, avg= 4.96, stdev= 3.18
     lat (usec): min=246, max=79427, avg=516.24, stdev=395.98
    clat percentiles (usec):
     |  1.00th=[    4],  5.00th=[    4], 10.00th=[    4], 20.00th=[    4],
     | 30.00th=[    4], 40.00th=[    5], 50.00th=[    5], 60.00th=[    5],
     | 70.00th=[    5], 80.00th=[    5], 90.00th=[    7], 95.00th=[    7],
     | 99.00th=[    8], 99.50th=[    8], 99.90th=[   21], 99.95th=[   25],
     | 99.99th=[   39]
    lat (usec) : 4=0.08%, 10=99.75%, 20=0.05%, 50=0.11%, 100=0.01%
    lat (usec) : 250=0.01%, 500=0.01%
  cpu          : usr=2.33%, sys=24.55%, ctx=342129, majf=0, minf=103
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=114013/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: io=7125.9MB, aggrb=121611KB/s, minb=121611KB/s, maxb=121611KB/s, mint=60001msec, maxt=60001msec

# Was für ein Backup Mode wird den verwendet?
Ich habe Snapshot & Stop versucht. Beides mit nur geringen Unterschieden.
Es sollte normal als vzDump - Snapshot laufen.

Alwin · Jul 9, 2019

Könntest Du bitte noch den Rados 'seq' (read) Benchmark und die 'qm config <vmid>' der VM posten?
Bitte beschreibe auch deine Hardware genauer, was für Modelle sind den CPU, Disk, RAM, HBA/RAID, etc? Wie sind die SSDs angeschlossen?

Das vzdump arbeitet zum Teil im Qemu und muss im Snapshot Mode alle Blöcke die neu geschrieben werden sollen erst ins Backup schreiben und auf das eigentliche Disk Image. Damit hängt die Geschwindigkeit von vielen Faktoren ab.

fireon · Jul 9, 2019

Quickly said:
alle ProxMox sind HP DL380 G8, usw.

Passt jetzt nicht ganz zum Thema... aber ich hoffe du hast den Controller gegen einen echten HBA getauscht. Denn sonst kann das ungeahnte Folgen haben. Der HBAmode was diese Controller haben, ist kein echtest HBA sonder wieder Software, und das mag Ceph/ZFS gar nicht. Ich spreche da aus Erfahrung, nach einem Servercrash aus heiterem Himmel.

Quickly · Jul 10, 2019

Alwin said:
qm config <vmid>

Diese VM´s laufen auf Node ProxMox64.mydom.lan
Es ist ein vzBackup-Job vorhanden der diese Maschinen nacheinander sichert.
Zu dieser Zeit laufen keine weiteren Jobs

Code:

root@proxmox64:~# qm config 503
agent: 1
boot: c
bootdisk: scsi0
cores: 4
cpu: host
ide0: none,media=cdrom
memory: 8192
name: ad01.mydom.de
net0: virtio=32:8C:72:1E:B1:CB,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: win10
scsi0: rbd_ssd:vm-503-disk-0,cache=unsafe,size=96G
scsihw: virtio-scsi-pci
smbios1: uuid=bc6efdc8-7e63-46aa-bbb3-ff5b69654515
sockets: 1
startup: order=503,up=10,down=60

root@proxmox64:~# qm config 504
agent: 1
boot: c
bootdisk: scsi0
cores: 4
cpu: host
ide0: none,media=cdrom
memory: 16384
name: sql01.mydom.de
net0: virtio=22:14:86:59:22:61,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: win10
scsi0: rbd_ssd:vm-504-disk-0,cache=unsafe,size=96G
scsi1: rbd_ssd:vm-504-disk-1,cache=unsafe,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=170d980f-6b54-4654-af79-94be580acf86
sockets: 2
startup: order=504,up=30,down=60

root@proxmox64:~# qm config 505
agent: 1
boot: c
bootdisk: scsi0
cores: 10
cpu: host
ide0: none,media=cdrom
memory: 65536
name: ex01.mydom.de
net0: virtio=DA:D0:F6:A2:AD:0A,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: win10
scsi0: rbd_ssd:vm-505-disk-0,cache=unsafe,size=128G
scsi1: rbd_ssd:vm-505-disk-1,cache=unsafe,size=128G
scsi2: rbd_ssd:vm-505-disk-2,cache=unsafe,size=480G
scsi3: rbd_ssd:vm-505-disk-3,cache=unsafe,size=128G
scsi4: rbd_ssd:vm-505-disk-4,cache=unsafe,size=64G
scsi5: rbd_ssd:vm-505-disk-5,cache=unsafe,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=e3c02003-304f-4562-b578-a99f014803bc
sockets: 2
startup: order=505,up=30,down=60

root@proxmox64:~# qm config 531
boot: c
bootdisk: scsi0
cores: 2
cpu: host
ide2: none,media=cdrom
memory: 4096
name: archiv01.mydom.lan
net0: virtio=32:19:93:B5:D9:3C,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: l26
scsi0: rbd_ssd:vm-531-disk-0,cache=unsafe,size=224G
scsi1: rbd_ssd:vm-531-disk-1,cache=unsafe,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=a7391625-10ff-44f9-9f9b-2e7d7a164705
sockets: 1
startup: order=531,up=10,down=60

root@proxmox64:~# qm config 551
boot: c
bootdisk: scsi0
cores: 1
cpu: host
ide2: none,media=cdrom
memory: 2048
name: postgate01.mydom.de
net0: virtio=E2:DA:02:BD:9B:AC,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: l26
scsi0: rbd_ssd:vm-551-disk-0,cache=unsafe,size=32G
scsi1: rbd_ssd:vm-551-disk-1,cache=unsafe,size=4G
scsihw: virtio-scsi-pci
smbios1: uuid=2e244795-5b65-4b89-afd1-940034f7705f
sockets: 1
startup: order=551,up=10,down=60

nano /etc/vzdump.conf
# vzdump default settings

#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
#pigz: N

Quickly · Jul 10, 2019

Alwin said:
Bitte beschreibe auch deine Hardware genauer

Bond0 = nur Ring0
Bond1 = den Servern zugeordnet
Bond2 = nur CEPH

Code:

# Hardware - 3 identische Nodes
ProLiant DL380p Gen8 - 8 Bay (native Lane, ohne Expander)
2x Intel(R) Xeon(R) CPU E5-2670v2 @ 2.50GHz 10-Core
192GB RAM HPE SmartMemory 1600Mhz
1x Smart Array P420i
  ProxMox/root = 2x 120GB M.2 SSD > Raid1
1x Smart Array P430
  CEPH = 4x Samsung PM1643 SSD MZILT960HAHQ > HBA > CEPH
1x Intel I350 1G Network > bond0 > Ring0
1x Intel X520-DA2 Dual 10G - bond1 mtu 1500 - WorkLAN
1x Mellanox ConnectX-3 Dual 40G - bond2 - mtu 9000 - CEPH + Ring1

Code:

# vzdump default settings

#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
#pigz: N

Quickly · Jul 10, 2019

Alwin said:
Rados 'seq' (read) Benchmark

Diesen Befehl habe ich lt. PDF nicht genau hinbekommen! Deswegen...

Code:

rbd -p rbd_ssd bench bench --io-type read --io-size 8192 --io-threads 256 --io-total 10G --io-pattern seq

Code:

elapsed:   201  ops:  1310720  ops/sec:  6507.29  bytes/sec: 53307703.31

Quickly · Jul 10, 2019

fireon said:
Passt jetzt nicht ganz zum Thema... aber ich hoffe du hast den Controller gegen einen echten HBA getauscht. Denn sonst kann das ungeahnte Folgen haben... ... ist kein echtest HBA sonder wieder Software...

Bzgl. Software stimme ich zu.
Jedoch haben wir bei uns und auch bei anderen Umgebungen bisher absolut keine Probleme. Jedoch lerne ich gerne dazu... wie hat sich das Problem geäußert? Kannst Du mir dazu näheres sagen?

Für die HP G8 & G9 gibt es keine alternative für den HBA mode sonst gibt es kein iLO mehr und die HDD LEDs arbeiten nicht.
Was ein evtl das herausfinden einer defekten HDD erschwert. Wenn man sich mit alternativen anfreunden kann gibt es den LSI 9200i&e /9300i&e 6/12G Controller. Wir haben einige Kunden die mit HP G8 24-Bay Servern einen Ceph erstellt betreibt.
Mit P420i HBA haben wir noch nichts negatives gehört.

Alwin · Jul 10, 2019

Quickly said:
scsi0: rbd_ssd:vm-503-disk-0,cache=unsafe,size=96G

I glaube nicht das der Cache Mode 'unsafe', den librbd cache verwendet. Unabhängig davon das nie ein flush gemacht wird, sollte nicht die Anwendung einen verlangen. Ich empfehle den Cache Mode für alle Disks einer VM auf 'writeback' zu stellen, damit werden die Daten raus geschrieben und der Cache von Ceph verwendet (default 25 MB).

Quickly said:
1x Smart Array P430

Wie schon oben erwähnt wurde, HBA ist der Controller der Wahl.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition

Quickly said:
rbd -p rbd_ssd bench bench --io-type read --io-size 8192 --io-threads 256 --io-total 10G --io-pattern seq

Leider ist der Test nicht vergleichbar, 8K mit 256 Threads, ist weit weg vom rados bench (4M mit 16 Tthreads).

Quickly said:
Diesen Befehl habe ich lt. PDF nicht genau hinbekommen! Deswegen...

Der 'seq' Test braucht einen 'write' Test mit --no-cleanup zuvor. Dann kann der Test wie im PDF verwendet werden.

Quickly · Jul 10, 2019

Alwin said:
Rados 'seq' (read) Benchmark

Der Parameter read, ist kein gültiger Parameter (mehr).

Code:

bench <seconds> write|seq|rand [-t concurrent_operations] [--no-cleanup] [--run-name run_name] [--no-hints]
default is 16 concurrent IOs and 4 MB ops
default is to clean up after write benchmark
default run-name is 'benchmark_last_metadata'

# Test 01

Code:

rados -p rbd_ssd bench 60 write -b 4M -t 16 --no-cleanup

Code:

2019-07-10 15:09:05.120283 min lat: 0.0199918 max lat: 0.342566 avg lat: 0.0627447
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
   60      16     15307     15291   1019.23       924   0.0862387   0.0627447
Total time run:         60.067146
Total writes made:      15308
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     1019.39
Stddev Bandwidth:       70.3457
Max bandwidth (MB/sec): 1156
Min bandwidth (MB/sec): 868
Average IOPS:           254
Stddev IOPS:            17
Max IOPS:               289
Min IOPS:               217
Average Latency(s):     0.0627744
Stddev Latency(s):      0.0341338
Max latency(s):         0.342566
Min latency(s):         0.0199918

# Test 02

Code:

rados -p rbd_ssd bench 60 seq -t 16

Code:

2019-07-10 15:10:22.350064 min lat: 0.0119738 max lat: 0.153168 avg lat: 0.0297774
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
   20      15     10316     10301   2059.15      2288   0.0276266   0.0297774
   21      16     10854     10838   2063.33      2148   0.0296132   0.0297143
   22      16     11400     11384    2068.8      2184   0.0262471   0.0296374
   23      15     11914     11899   2068.36      2060   0.0269593   0.0296402
   24      16     12439     12423   2069.49      2096   0.0241259   0.0296249
   25      15     12941     12926   2067.17      2012   0.0253283   0.0296508
   26      15     13468     13453   2068.71      2108   0.0282671   0.0296293
   27      15     13980     13965   2067.76      2048    0.020542   0.0296399
   28      16     14537     14521   2073.16      2224   0.0233892   0.0295652
   29      15     15072     15057    2075.5      2144   0.0328003   0.0295301
Total time run:       29.506072
Total reads made:     15308
Read size:            4194304
Object size:          4194304
Bandwidth (MB/sec):   2075.23
Average IOPS:         518
Stddev IOPS:          19
Max IOPS:             572
Min IOPS:             486
Average Latency(s):   0.0295331
Max latency(s):       0.153168
Min latency(s):       0.0119738

Das sollten dann die Test´s sein?!? Und somit alle Fragen vollständig.

Alwin · Jul 10, 2019

Der Lesetest schaut gut aus, ~ 2GB/s. Am Ceph selber wird es da eher weniger liegen. Bitte teste mal mit den Caches Modes, das könnte schon Verbesserung bringen.

Da vzdump im Qemu arbeitet, ist auch bei VMs mit viel IO das Backup langsamer, da es ja jeden Block zweimal schreiben muss. Mit einem verteilten System wie Ceph fällt das mehr ins Gewicht.

Quickly · Jul 10, 2019

Alwin said:
Bitte teste mal mit den Caches Modes

Erledigt. Die letzte Maschine gerade umgestellt. Bericht folgt Morgen. In der Nacht läuft wieder das Backup.

Als Beispiel - VM 505

Code:

root@proxmox64:~# qm config 505
agent: 1
boot: c
bootdisk: scsi0
cores: 10
cpu: host
ide0: none,media=cdrom
memory: 65536
name: ex01.mydom.de
net0: virtio=DA:D0:F6:A2:AD:0A,bridge=vmbr0,tag=124
numa: 0
onboot: 1
ostype: win10
scsi0: rbd_ssd:vm-505-disk-0,cache=writeback,size=128G
scsi1: rbd_ssd:vm-505-disk-1,cache=writeback,size=128G
scsi2: rbd_ssd:vm-505-disk-2,cache=writeback,size=480G
scsi3: rbd_ssd:vm-505-disk-3,cache=writeback,size=128G
scsi4: rbd_ssd:vm-505-disk-4,cache=writeback,size=64G
scsi5: rbd_ssd:vm-505-disk-5,cache=writeback,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=e3c02003-304f-4562-b578-a99f014803bc
sockets: 2
startup: order=505,up=30,down=60

fireon · Jul 11, 2019

Quickly said:
Kannst Du mir dazu näheres sagen?

Absolut. Es waren zwei Maschinen. Wir hatten keine andere Möglichkeit als diese mit ZFS auf zu setzen. Beide Maschinen hatten das selbe Problem, und ja wir waren auch mit dem HP Support und später auch mit dem Proxmoxsupport drauf. Der Controller schrieb aus was für Gründe auch immer Blödsinn auf die Platten, somit war alles hinüber. Seitdem, nur richtiges HBA! Das war uns eine Lehre.

Quickly · Jul 11, 2019

Alwin said:
Bitte teste mal mit den Caches Modes, das könnte schon Verbesserung bringen.

Hallo Alwin.
Verbesserung: Ja
Gut: Nicht wirklich.
Zumindest sind wir nun bei 5 Stunden.
Es wäre schön wenn wir, trotz Verbesserung" weiter suchen könnten.
Hier mal Log-Start und Log-Ende - Gesamt

Code:

INFO: starting new backup job: vzdump 503 504 505 531 551 591 --compress lzo --quiet 1 --mailto server1@mydom.de --mode snapshot --storage BackupMyDomDaily --mailnotification failure
INFO: Starting Backup of VM 503 (qemu)
INFO: Backup started at 2019-07-11 00:30:03
INFO: status = running
INFO: update VM 503: -lock backup
INFO: VM Name: ad01.mydom.de
INFO: include disk 'scsi0' 'rbd_ssd:vm-503-disk-0' 96G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/BackupMyDomDaily/dump/vzdump-qemu-503-2019_07_11-00_30_03.vma.lzo'
INFO: started backup task '129eb2aa-eca9-40aa-8da5-4ecfe0404ea5'
INFO: status: 0% (671088640/103079215104), sparse 0% (89640960), duration 3, read/write 223/193 MB/s
INFO: status: 1% (1094713344/103079215104), sparse 0% (93880320), duration 13, read/write 42/41 MB/s
INFO: status: 2% (2164260864/103079215104), sparse 0% (102916096), duration 26, read/write 82/81 MB/s
INFO: status: 3% (3120562176/103079215104), sparse 0% (115781632), duration 39, read/write 73/72 MB/s
INFO: status: 4% (4135583744/103079215104), sparse 0% (143609856), duration 54, read/write 67/65 MB/s
INFO: status: 5% (5207490560/103079215104), sparse 0% (162742272), duration 69, read/write 71/70 MB/s
INFO: status: 6% (6210977792/103079215104), sparse 0% (180768768), duration 82, read/write 77/75 MB/s
INFO: status: 7% (7271481344/103079215104), sparse 0% (208502784), duration 98, read/write 66/64 MB/s
INFO: status: 8% (8271167488/103079215104), sparse 0% (228589568), duration 112, read/write 71/69 MB/s
INFO: status: 9% (9298771968/103079215104), sparse 0% (254562304), duration 125, read/write 79/77 MB/s
INFO: status: 10% (10330570752/103079215104), sparse 0% (287170560), duration 143, read/write 57/55 MB/s
...
INFO: status: 94% (65062043648/68719476736), sparse 32% (22349942784), duration 715, read/write 510/0 MB/s
INFO: status: 96% (66299363328/68719476736), sparse 34% (23587262464), duration 718, read/write 412/0 MB/s
INFO: status: 98% (67549265920/68719476736), sparse 36% (24837165056), duration 721, read/write 416/0 MB/s
INFO: status: 100% (68719476736/68719476736), sparse 37% (26007371776), duration 724, read/write 390/0 MB/s
INFO: transferred 68719 MB in 724 seconds (94 MB/s)
INFO: archive file size: 27.22GB
INFO: delete old backup '/mnt/pve/BackupMyDomDaily/dump/vzdump-qemu-591-2019_07_06-07_00_02.vma.lzo'
INFO: Finished Backup of VM 591 (00:12:16)
INFO: Backup finished at 2019-07-11 05:08:31
INFO: Backup job finished successfully
TASK OK

Und noch beispielhaft die dicke VM:

Code:

INFO: Starting Backup of VM 505 (qemu)
INFO: Backup started at 2019-07-11 01:11:44
INFO: status = running
INFO: update VM 505: -lock backup
INFO: VM Name: ex01.mydom.de
INFO: include disk 'scsi0' 'rbd_ssd:vm-505-disk-0' 128G
INFO: include disk 'scsi1' 'rbd_ssd:vm-505-disk-1' 128G
INFO: include disk 'scsi2' 'rbd_ssd:vm-505-disk-2' 480G
INFO: include disk 'scsi3' 'rbd_ssd:vm-505-disk-3' 128G
INFO: include disk 'scsi4' 'rbd_ssd:vm-505-disk-4' 64G
INFO: include disk 'scsi5' 'rbd_ssd:vm-505-disk-5' 8G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/BackupMyDomDaily/dump/vzdump-qemu-505-2019_07_11-01_11_44.vma.lzo'
INFO: started backup task '79f1528b-091d-4219-ba82-da620efc98eb'
INFO: status: 0% (557842432/1005022347264), sparse 0% (100478976), duration 3, read/write 185/152 MB/s
INFO: status: 1% (10072883200/1005022347264), sparse 0% (229613568), duration 139, read/write 69/69 MB/s
INFO: status: 2% (20145766400/1005022347264), sparse 0% (368136192), duration 267, read/write 78/77 MB/s
INFO: status: 3% (30207377408/1005022347264), sparse 0% (474382336), duration 403, read/write 73/73 MB/s
INFO: status: 4% (40211709952/1005022347264), sparse 0% (575922176), duration 534, read/write 76/75 MB/s
INFO: status: 5% (50285510656/1005022347264), sparse 0% (650715136), duration 681, read/write 68/68 MB/s
INFO: status: 6% (60327067648/1005022347264), sparse 0% (699346944), duration 817, read/write 73/73 MB/s
INFO: status: 7% (70388809728/1005022347264), sparse 0% (718471168), duration 948, read/write 76/76 MB/s
INFO: status: 8% (80455139328/1005022347264), sparse 0% (721534976), duration 1077, read/write 78/78 MB/s
INFO: status: 9% (90496303104/1005022347264), sparse 0% (724955136), duration 1209, read/write 76/76 MB/s
INFO: status: 10% (101015617536/1005022347264), sparse 0% (4400193536), duration 1316, read/write 98/63 MB/s
INFO: status: 11% (110733819904/1005022347264), sparse 1% (14118391808), duration 1330, read/write 694/0 MB/s
INFO: status: 12% (120884035584/1005022347264), sparse 2% (24268607488), duration 1354, read/write 422/0 MB/s
INFO: status: 13% (130925199360/1005022347264), sparse 3% (34309771264), duration 1372, read/write 557/0 MB/s
INFO: status: 14% (140718899200/1005022347264), sparse 4% (40841449472), duration 1423, read/write 192/63 MB/s
INFO: status: 15% (150808166400/1005022347264), sparse 4% (41129754624), duration 1553, read/write 77/75 MB/s
INFO: status: 16% (160851558400/1005022347264), sparse 4% (41147084800), duration 1675, read/write 82/82 MB/s
INFO: status: 17% (170919723008/1005022347264), sparse 4% (41179484160), duration 1799, read/write 81/80 MB/s
INFO: status: 18% (180933885952/1005022347264), sparse 4% (41180016640), duration 1907, read/write 92/92 MB/s
INFO: status: 19% (191004409856/1005022347264), sparse 4% (41193988096), duration 2033, read/write 79/79 MB/s
INFO: status: 20% (201024339968/1005022347264), sparse 4% (41206054912), duration 2161, read/write 78/78 MB/s
INFO: status: 21% (211070615552/1005022347264), sparse 4% (41220325376), duration 2296, read/write 74/74 MB/s
INFO: status: 22% (221151100928/1005022347264), sparse 4% (41223159808), duration 2420, read/write 81/81 MB/s
INFO: status: 23% (231538163712/1005022347264), sparse 4% (43053166592), duration 2531, read/write 93/77 MB/s
INFO: status: 24% (241453498368/1005022347264), sparse 5% (52968497152), duration 2556, read/write 396/0 MB/s
INFO: status: 25% (251423358976/1005022347264), sparse 6% (62938357760), duration 2573, read/write 586/0 MB/s
INFO: status: 26% (262030753792/1005022347264), sparse 7% (73545752576), duration 2595, read/write 482/0 MB/s
INFO: status: 27% (271652487168/1005022347264), sparse 8% (83167485952), duration 2613, read/write 534/0 MB/s
INFO: status: 28% (281508577280/1005022347264), sparse 8% (86901624832), duration 2704, read/write 108/67 MB/s
INFO: status: 29% (291459825664/1005022347264), sparse 8% (87014948864), duration 2847, read/write 69/68 MB/s
INFO: status: 30% (301536509952/1005022347264), sparse 8% (87041630208), duration 2987, read/write 71/71 MB/s
INFO: status: 31% (311632592896/1005022347264), sparse 8% (87073157120), duration 3126, read/write 72/72 MB/s
INFO: status: 32% (321636663296/1005022347264), sparse 8% (87181848576), duration 3267, read/write 70/70 MB/s
INFO: status: 33% (331732353024/1005022347264), sparse 8% (87235072000), duration 3408, read/write 71/71 MB/s
INFO: status: 34% (341739307008/1005022347264), sparse 8% (87284293632), duration 3544, read/write 73/73 MB/s
INFO: status: 35% (351830802432/1005022347264), sparse 8% (87299149824), duration 3686, read/write 71/70 MB/s
INFO: status: 36% (361842606080/1005022347264), sparse 8% (87315488768), duration 3829, read/write 70/69 MB/s
INFO: status: 37% (371883245568/1005022347264), sparse 8% (87384367104), duration 3966, read/write 73/72 MB/s
INFO: status: 38% (381987848192/1005022347264), sparse 8% (87438331904), duration 4112, read/write 69/68 MB/s
INFO: status: 39% (392008040448/1005022347264), sparse 8% (87456256000), duration 4254, read/write 70/70 MB/s
INFO: status: 40% (402052481024/1005022347264), sparse 8% (87476936704), duration 4394, read/write 71/71 MB/s
INFO: status: 41% (412117762048/1005022347264), sparse 8% (87502336000), duration 4534, read/write 71/71 MB/s
INFO: status: 42% (422114623488/1005022347264), sparse 8% (87508320256), duration 4677, read/write 69/69 MB/s
INFO: status: 43% (432172302336/1005022347264), sparse 8% (87568760832), duration 4815, read/write 72/72 MB/s
INFO: status: 44% (442259996672/1005022347264), sparse 8% (87605338112), duration 4965, read/write 67/67 MB/s
INFO: status: 45% (452309549056/1005022347264), sparse 8% (87626719232), duration 5113, read/write 67/67 MB/s
INFO: status: 46% (462394753024/1005022347264), sparse 8% (87649394688), duration 5259, read/write 69/68 MB/s
INFO: status: 47% (472403017728/1005022347264), sparse 8% (87661142016), duration 5398, read/write 72/71 MB/s
INFO: status: 48% (482445623296/1005022347264), sparse 8% (87683305472), duration 5536, read/write 72/72 MB/s
INFO: status: 49% (492507758592/1005022347264), sparse 8% (87707463680), duration 5685, read/write 67/67 MB/s
INFO: status: 50% (502553116672/1005022347264), sparse 8% (87734071296), duration 5819, read/write 74/74 MB/s
INFO: status: 51% (512611057664/1005022347264), sparse 8% (87747108864), duration 5968, read/write 67/67 MB/s
INFO: status: 52% (522660610048/1005022347264), sparse 8% (87890288640), duration 6110, read/write 70/69 MB/s
INFO: status: 53% (532676870144/1005022347264), sparse 8% (87964897280), duration 6251, read/write 71/70 MB/s
INFO: status: 54% (542753554432/1005022347264), sparse 8% (88001314816), duration 6399, read/write 68/67 MB/s
INFO: status: 55% (552779907072/1005022347264), sparse 8% (88138641408), duration 6537, read/write 72/71 MB/s
INFO: status: 56% (562833653760/1005022347264), sparse 8% (88149815296), duration 6691, read/write 65/65 MB/s
INFO: status: 57% (572891594752/1005022347264), sparse 8% (88159842304), duration 6832, read/write 71/71 MB/s
INFO: status: 58% (582966312960/1005022347264), sparse 8% (88165634048), duration 6974, read/write 70/70 MB/s
INFO: status: 59% (593015865344/1005022347264), sparse 8% (88184651776), duration 7104, read/write 77/77 MB/s
INFO: status: 60% (603036057600/1005022347264), sparse 8% (88348622848), duration 7245, read/write 71/69 MB/s
INFO: status: 61% (613066080256/1005022347264), sparse 8% (88363704320), duration 7395, read/write 66/66 MB/s
INFO: status: 62% (623189688320/1005022347264), sparse 8% (88380612608), duration 7531, read/write 74/74 MB/s
INFO: status: 63% (633215647744/1005022347264), sparse 8% (88749957120), duration 7678, read/write 68/65 MB/s
INFO: status: 64% (643221684224/1005022347264), sparse 8% (88851554304), duration 7817, read/write 71/71 MB/s
INFO: status: 65% (653292208128/1005022347264), sparse 8% (89867325440), duration 7958, read/write 71/64 MB/s
INFO: status: 66% (663597613056/1005022347264), sparse 9% (96002256896), duration 8033, read/write 137/55 MB/s
INFO: status: 67% (673563279360/1005022347264), sparse 10% (105967923200), duration 8053, read/write 498/0 MB/s
INFO: status: 68% (683499585536/1005022347264), sparse 11% (115904229376), duration 8072, read/write 522/0 MB/s
INFO: status: 69% (693729492992/1005022347264), sparse 12% (126134132736), duration 8092, read/write 511/0 MB/s
INFO: status: 70% (703871320064/1005022347264), sparse 13% (136275959808), duration 8107, read/write 676/0 MB/s
INFO: status: 71% (713581133824/1005022347264), sparse 14% (145985773568), duration 8125, read/write 539/0 MB/s
INFO: status: 72% (723920093184/1005022347264), sparse 15% (156324728832), duration 8149, read/write 430/0 MB/s
INFO: status: 73% (733835427840/1005022347264), sparse 16% (166240063488), duration 8164, read/write 661/0 MB/s
INFO: status: 74% (744203747328/1005022347264), sparse 17% (176608382976), duration 8185, read/write 493/0 MB/s
INFO: status: 75% (754022612992/1005022347264), sparse 18% (186427248640), duration 8199, read/write 701/0 MB/s
INFO: status: 76% (763900198912/1005022347264), sparse 19% (196304834560), duration 8218, read/write 519/0 MB/s
INFO: status: 77% (774159990784/1005022347264), sparse 20% (206564626432), duration 8241, read/write 446/0 MB/s
INFO: status: 78% (784288710656/1005022347264), sparse 21% (216693346304), duration 8258, read/write 595/0 MB/s
INFO: status: 79% (794036273152/1005022347264), sparse 22% (222740860928), duration 8322, read/write 152/57 MB/s
INFO: status: 80% (804039688192/1005022347264), sparse 22% (222810382336), duration 8470, read/write 67/67 MB/s
INFO: status: 81% (814136033280/1005022347264), sparse 22% (223106347008), duration 8612, read/write 71/69 MB/s
INFO: status: 82% (824163958784/1005022347264), sparse 22% (223181717504), duration 8767, read/write 64/64 MB/s
INFO: status: 83% (834209316864/1005022347264), sparse 22% (223252701184), duration 8915, read/write 67/67 MB/s
INFO: status: 84% (844252053504/1005022347264), sparse 22% (223492403200), duration 9060, read/write 69/67 MB/s
INFO: status: 85% (854316810240/1005022347264), sparse 22% (223560081408), duration 9207, read/write 68/68 MB/s
INFO: status: 86% (864324419584/1005022347264), sparse 22% (223855091712), duration 9347, read/write 71/69 MB/s
INFO: status: 87% (874409885696/1005022347264), sparse 22% (224564760576), duration 9476, read/write 78/72 MB/s
INFO: status: 88% (884423524352/1005022347264), sparse 22% (225185607680), duration 9605, read/write 77/72 MB/s
INFO: status: 89% (894502436864/1005022347264), sparse 22% (227852673024), duration 9720, read/write 87/64 MB/s
INFO: status: 90% (904543600640/1005022347264), sparse 23% (237394849792), duration 9745, read/write 401/19 MB/s
INFO: status: 91% (915364904960/1005022347264), sparse 24% (248216154112), duration 9765, read/write 541/0 MB/s
INFO: status: 92% (925053747200/1005022347264), sparse 25% (257904996352), duration 9780, read/write 645/0 MB/s
INFO: status: 93% (934733152256/1005022347264), sparse 26% (264195866624), duration 9846, read/write 146/51 MB/s
INFO: status: 94% (944905388032/1005022347264), sparse 26% (268869148672), duration 9948, read/write 99/53 MB/s
INFO: status: 95% (955198210048/1005022347264), sparse 27% (279161970688), duration 9973, read/write 411/0 MB/s
INFO: status: 96% (965071601664/1005022347264), sparse 28% (289035362304), duration 9995, read/write 448/0 MB/s
INFO: status: 97% (974953381888/1005022347264), sparse 29% (298151792640), duration 10030, read/write 282/21 MB/s
INFO: status: 98% (984931631104/1005022347264), sparse 30% (308130041856), duration 10054, read/write 415/0 MB/s
INFO: status: 99% (995216064512/1005022347264), sparse 31% (318414475264), duration 10076, read/write 467/0 MB/s
INFO: status: 100% (1005022347264/1005022347264), sparse 32% (326767939584), duration 10118, read/write 233/34 MB/s
INFO: transferred 1005022 MB in 10118 seconds (99 MB/s)
INFO: archive file size: 429.39GB
INFO: delete old backup '/mnt/pve/BackupMyDomDaily/dump/vzdump-qemu-505-2019_07_06-15_35_43.vma.lzo'
INFO: Finished Backup of VM 505 (02:48:56)
INFO: Backup finished at 2019-07-11 04:00:40

Alwin · Jul 11, 2019

INFO: transferred 68719 MB in 724 seconds (94 MB/s)
INFO: Finished Backup of VM 591 (00:12:16)
INFO: Backup finished at 2019-07-11 05:08:31

INFO: Starting Backup of VM 505 (qemu)
INFO: Backup started at 2019-07-11 01:11:44
INFO: transferred 1005022 MB in 10118 seconds (99 MB/s)
INFO: Finished Backup of VM 505 (02:48:56)
INFO: Backup finished at 2019-07-11 04:00:40

vzdump sichert auf der Node die VMs, 503, 504, 505, 531, 551 und 591 in Serie. Die beiden Backups machen jeweils ~100 MB/s, also fast die 120 MB/s die bei FIO gemessen wurden.

Sollte auf den anderen Nodes auch ein Backup laufen, dann müssen alle Nodes von Ceph lesen und dann auf das NAS schreiben. Da vermute ich, wird die Schreibgeschwindigkeit des NAS voll ausgenutzt. Das ist natürlich im Unterschied mit einer Node und lokalem Speicher langsamer.

INFO: status: 97% (974953381888/1005022347264), sparse 29% (298151792640), duration 10030, read/write 282/21 MB/s
INFO: status: 98% (984931631104/1005022347264), sparse 30% (308130041856), duration 10054, read/write 415/0 MB/s
INFO: status: 99% (995216064512/1005022347264), sparse 31% (318414475264), duration 10076, read/write 467/0 MB/s
INFO: status: 100% (1005022347264/1005022347264), sparse 32% (326767939584), duration 10118, read/write 233/34 MB/s

In diesen Zeilen sieht man, wie viel gelesen und im Anschluss dann wirklich raus geschrieben wurde, da Blöcke auch Leer sein können.

Quickly · Jul 11, 2019

Alwin said:
Sollte auf den anderen Nodes auch ein Backup laufen, dann müssen alle Nodes von Ceph lesen und dann auf das NAS schreiben.

Das Backup läuft in der Nacht, also kein Traffic und es läuft definitiv nur ein vzDump-Job von diesem einen Node. Und auch alle genannten Maschinen, logisch, nacheinander. Auch das vor vorher so damit Quelle und (besonders) das Ziel, die NAS, nicht überansprucht werden.

Alwin said:
Das ist natürlich im Unterschied mit einer Node und lokalem Speicher langsamer.

Nur nochmals zum Verständnis: Auch vorher waren es 3 Nodes. Jeoch mit einem Shared-NFS-Speicher auf Node 3.

Die Hardware hat sich nur Verändert indem die SSD´s schneller geworden sind. Und die Konfig hat sich geändert, dass statt NFS-Share für die VM-Container nun CEPH vorhanden ist.

Es erschließt sich mir nicht. Besonders nicht wenn ich bedenke, dass viele kleine Umgebungen mit dieser generellen Konstellation arbeiten.
Es ist bestimmt ein Fehler in der Konfig von meiner Seite vorhanden. Nur wo?

Alwin · Jul 11, 2019

Quickly said:
Das Backup läuft in der Nacht, also kein Traffic und es läuft definitiv nur ein vzDump-Job von diesem einen Node.

Also ein Job und nur auf einer Node?

Quickly said:
Die Hardware hat sich nur Verändert indem die SSD´s schneller geworden sind. Und die Konfig hat sich geändert, dass statt NFS-Share für die VM-Container nun CEPH vorhanden ist.

Das macht sehr wohl einen Unterschied. NFS hat nur einen Entpunkt und schreibt lokal auf seine Platten. Ceph is ein vereiltes Speichersystem und die Daten müssen mehrere male über as Netzwerk bis sie als geschrieben gelten. Damit kann ein Backup langsamer werden.

Ein weiterer Punkt, auf dem weiter oben bereits eingegangen wurde, ist der Smart Array P430. RAID Controller (auch wenn im IT-Mode) funktionieren mit Ceph nur bedingt. Daher ist generell die Empfehlung einen HBA einzusetzen. Dieser kann natürlich bei länger laufenden Lese/Schreiboperationen mit hinein spielen.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition

Auch läuft meist in der Nacht noch ein (Deep-)Scrub, der das Cluster zusätzlich unter Last stellt. Hierbei werden alle Objekte mit ihrer Checksumme verglichen. Bei einem Deep-Scrub werden alle Kopien eines Objektes miteinander verglichen.

Wie verhält sich das Backup einer VM die einen lokalen Storage verwendet?

Quickly · Jul 13, 2019

Alwin said:
Das macht sehr wohl einen Unterschied. NFS hat nur einen Entpunkt und schreibt lokal auf seine Platten. Ceph is ein vereiltes Speichersystem und die Daten müssen mehrere male über as Netzwerk bis sie als geschrieben gelten. Damit kann ein Backup langsamer werden.

Das ist mir klar. Jedoch ist, beim Backup, doch wohl dieser extreme Zeitanstieg nicht gewollt?!?! Bzw. hoffe ich da auf einen Lösungsansatz?!?!

Alwin said:
Ein weiterer Punkt, auf dem weiter oben bereits eingegangen wurde, ist der Smart Array P430. RAID Controller (auch wenn im IT-Mode) funktionieren mit Ceph nur bedingt

Ok, das habe ich gelesen und bin der Meinung, dass auch dieser Punkt nicht diese bescheidene Performance beim Backup auslösen kann.
Sei es drum... bevor wir uns an diesem Punkt aufhängen... ich habe Gestern (Express) entsprechende LSI-Controller senden lassen.
Eingebaut, ausgeführt... > es gibt keine Verbesserung mit einem LSI HBA.

Alwin said:
Auch läuft meist in der Nacht noch ein (Deep-)Scrub, der das Cluster zusätzlich unter Last stellt.

Sorry... alle Test´s/Test-Backup´s, hier auf Problemsuche, lasse ich am Tag laufen. Das kann es also auch nicht sein. Außer Scrub läuft 24 Stunden. Nein, es ist keine übermäßige Last am späten Nachmittag vorhanden.

Alwin said:
Wie verhält sich das Backup einer VM die einen lokalen Storage verwendet?

Ich habe in den Servern kein lokales Storage. Aber auch das werde ich noch einbauen und diesen Test machen.

Verstehen wir uns nicht falsch. Ich halte ProxMox mit CEPH für eine Super-Kombination, geiles Konzept.
Jedoch...
Wie machen das denn die anderen ProxMox-User? Meine Konstellation ist ja nix neues.
3x ProxMox Node mit jeweils 4x SSD Enterprise (ab Dienstag je 6x SSD) + 10G LAN + vzDump per NFS.
Die CEPH-Werte, ich behaupte das mal, sind doch echt super. Die NAS ist auch nicht gerade lahmarschig.

Bitte um HILFE!

Alwin · Jul 15, 2019

Quickly said:
Das ist mir klar. Jedoch ist, beim Backup, doch wohl dieser extreme Zeitanstieg nicht gewollt?!?! Bzw. hoffe ich da auf einen Lösungsansatz?!?!

Das ist leider Systembedingt. Alternativ könnte ein Export aus dem Ceph direkt gemacht werden, das geht aber vorbei an vzdump.

Eine detailiertere Beschreibung gibt's in unten stehendem Link.
https://git.proxmox.com/?p=pve-qemu.git;a=blob;f=backup.txt

1.) read old data before it gets overwritten
2.) write that data into the backup archive
3.) write new data (VM write)

Quickly said:
Sorry... alle Test´s/Test-Backup´s, hier auf Problemsuche, lasse ich am Tag laufen. Das kann es also auch nicht sein. Außer Scrub läuft 24 Stunden. Nein, es ist keine übermäßige Last am späten Nachmittag vorhanden.

Kann je nach Einstellung auch sein. Mit den Einzeilern kann das leicht herausgefunden werden.
https://ceph.com/geen-categorie/deep-scrub-distribution/

Quickly said:
Verstehen wir uns nicht falsch. Ich halte ProxMox mit CEPH für eine Super-Kombination, geiles Konzept.
Jedoch...
Wie machen das denn die anderen ProxMox-User? Meine Konstellation ist ja nix neues.
3x ProxMox Node mit jeweils 4x SSD Enterprise (ab Dienstag je 6x SSD) + 10G LAN + vzDump per NFS.
Die CEPH-Werte, ich behaupte das mal, sind doch echt super. Die NAS ist auch nicht gerade lahmarschig.

Es geht dabei eher um die Latenz als um die Bandbreite und dadurch (wie oben im Link beschrieben) das viele Schreib-/Lesezugriffe über das Netzwerk passieren, steigt die Zeit. Es könnte helfen, mehrere Backups nebeneinander laufen zu lassen, dazu bräuchte es zwei oder mehr. gleichzeitig laufende Jobs.

vzDump - CEPH - 40G Ethernet

Renowned Member

Proxmox Retired Staff

Renowned Member

Proxmox Retired Staff

Distinguished Member

Renowned Member

Renowned Member

Renowned Member

Renowned Member

Proxmox Retired Staff

Renowned Member

Proxmox Retired Staff

Renowned Member

Distinguished Member

Renowned Member

Proxmox Retired Staff

Renowned Member

Proxmox Retired Staff

Renowned Member

Proxmox Retired Staff