VM auf ceph storage

[skydiablo]

hallo,
ich habe diverse VMs auf meinem ceph storage am laufen (im grunde auch keine probleme). nun habe ich eine VM mit einer software (SCI) welche nun probleme macht. der hersteller sagt mein storage wäre zu langsam, jetzt bin ich mir nicht ganz sicher was ich davon halten soll. der hersteller sagt ich müsse mit folgenden command mindestens 500kb/s schaffen:

dd if=/dev/zero of=./file.tmp bs=1024 count=1000 oflag=dsync status=progress

leider komme ich nur unterirdische werte:

$ dd if=/dev/zero of=./file.tmp bs=1024 count=1000 oflag=dsync status=progress
419840 bytes (420 kB, 410 KiB) copied, 25 s, 16.8 kB/s
414+0 records in
414+0 records out
423936 bytes (424 kB, 414 KiB) copied, 25.2822 s, 16.8 kB/s

gehe ich mit dem `bs` parameter nach oben auf zB 4MB oder 32MB, schaut das wieder ganz anders aus:

$ dd if=/dev/zero of=./file.tmp bs=4MB count=1000 oflag=dsync status=progress
260000000 bytes (260 MB, 248 MiB) copied, 11 s, 23.6 MB/s
69+0 records in
69+0 records out
276000000 bytes (276 MB, 263 MiB) copied, 11.4777 s, 24.0 MB/s

$ dd if=/dev/zero of=./file.tmp bs=32MB count=1000 oflag=dsync status=progress
896000000 bytes (896 MB, 854 MiB) copied, 11 s, 79.6 MB/s
30+0 records in
30+0 records out
960000000 bytes (960 MB, 916 MiB) copied, 11.9299 s, 80.5 MB/s

mein storage ist mittels 10GB netzwerk angebunden (mittels iperf komme ich auf ~9,8GB/s), fährt aktuell aber auch noch mit einem 1500er MTU.

bei dem storage handelt es sich um 3 nodes a 10 platten (HUS726040AL5210 - HGST Ultrastar 7K6000 4TB 7200 RPM 512e SAS 12Gb/s 128MB Cache) und auf jeder platte läuft ein OSD mit.

ich habe auch direkte benchmarks gegen den storage gefahren (ohne VM) und bin dort auf weit über 600MB/s gekommen. aber eben dieses schreiben von 1kb packages macht dem ding doch etwas zu schaffen.

die VM nutzt als SCSI controller `virtIO SCSI` und der HDD cache ist zusätzlich auf "write through" gesetzt. nützt alles nix

ansonsten fahre ich ein Proxmox VE 6.2 und im grunde alles eine stock installation inkl. ceph. handelt es sich bei meinen zahlen um normale werte oder müsste da eigentlich viel mehr gehen?

PS:
auf meinem lokalen rechner mit einer SSD habe ich den gleichen befehl abgesetzt und komme da auch nicht weit über 200kb/s, denke also wenn ich dann übers netzwerk auf ein ceph mit ~20kb/s gar nicht so schlecht fahre????

greez & thx,
volker.

 

[Alwin]

die VM nutzt als SCSI controller `virtIO SCSI` und der HDD cache ist zusätzlich auf "write through" gesetzt. nützt alles nix

Setz den Cache mal auf writeback, sonst wird kein Schreibcache benutzt.

bei dem storage handelt es sich um 3 nodes a 10 platten (HUS726040AL5210 - HGST Ultrastar 7K6000 4TB 7200 RPM 512e SAS 12Gb/s 128MB Cache) und auf jeder platte läuft ein OSD mit.

Kleine Blockgrößen vertragen sich immer schlecht mit HDDs. Da Ceph dazu noch ein verteiltes System ist, wird's nicht besser.

ich habe auch direkte benchmarks gegen den storage gefahren (ohne VM) und bin dort auf weit über 600MB/s gekommen. aber eben dieses schreiben von 1kb packages macht dem ding doch etwas zu schaffen.

Was für einen Test hast du gemacht?

 

[skydiablo]

hier ein paar aktuelle ergebnisse welche direkt von einem der 3 nodes aus ausgeführt habe:

# ceph osd pool create scbench 128 128
pool 'scbench' created

# rados bench -p scbench 10 write --no-cleanup -t 16 -b 4MB
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_pve05_58272
  sec Cur ops   started  finished  avg MB/s  cur MB/s last lat(s)  avg lat(s)
    0       0         0         0         0         0           -           0
    1      16       110        94   375.978       376     0.16452     0.15758
    2      16       219       203   405.949       436   0.0725615    0.153238
    3      16       322       306   407.949       412    0.113752    0.152467
    4      16       413       397   396.953       364   0.0873191    0.155781
    5      16       516       500   399.952       412   0.0977255    0.156666
    6      16       611       595   396.617       380   0.0684116    0.159378
    7      16       708       692   395.378       388    0.123557    0.159913
    8      16       815       799    399.45       428   0.0748108    0.158622
    9      16       915       899   399.505       400    0.201467    0.159005
   10      16      1017      1001   400.348       408    0.143458     0.15813
Total time run:         10.1519
Total writes made:      1018
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     401.109
Stddev Bandwidth:       23.2054
Max bandwidth (MB/sec): 436
Min bandwidth (MB/sec): 364
Average IOPS:           100
Stddev IOPS:            5.80134
Max IOPS:               109
Min IOPS:               91
Average Latency(s):     0.159552
Stddev Latency(s):      0.066822
Max latency(s):         0.643856
Min latency(s):         0.0639728

# rados -p scbench cleanup
Removed 1018 objects

# ceph osd pool create rbdbench 128 128
pool 'rbdbench' created

# rbd create image01 --size 1024 --pool rbdbench

# sudo rbd map image01 --pool rbdbench --name client.admin
/dev/rbd0

# sudo /sbin/mkfs.ext4 -m0 /dev/rbd/rbdbench/image01
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done                           
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 94d15988-46d9-44bb-a17f-85f9c264e09a
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376

Allocating group tables: done                           
Writing inode tables: done                           
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

# sudo mkdir /mnt/ceph-block-device

# sudo mount /dev/rbd/rbdbench/image01 /mnt/ceph-block-device

# rbd bench-write image01 --pool=rbdbench
rbd: bench-write is deprecated, use rbd bench --io-type write ...
bench  type write io_size 4096 io_threads 16 bytes 1073741824 pattern sequential
  SEC       OPS   OPS/SEC   BYTES/SEC
    1     26736  26859.35  110015883.13
    2     49248  24388.04  99893395.11
    3     70320  23382.90  95776355.35
    4     92464  23027.81  94321910.51
    5    112912  22567.47  92436354.10
    6    138224  22244.14  91111990.42
    7    163008  22824.96  93491046.66
    8    180608  22110.59  90564978.50
    9    202736  22125.13  90624513.84
   10    228064  23030.32  94332197.84
   11    253040  23018.37  94283227.33
elapsed:    11  ops:   262144  ops/sec: 22874.62  bytes/sec: 93694430.63

dann nochmal mit `fio` drüber gebügelt, dafür folgende config verwendet:

[global]
ioengine=rbd
clientname=admin
pool=rbdbench
rbdname=image01
rw=randwrite
bs=4k
[rbd_iodepth32]
iodepth=32

und dann los:

# fio rbd.fio
rbd_iodepth32: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=rbd, iodepth=32
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=2510KiB/s][w=627 IOPS][eta 00m:00s]
rbd_iodepth32: (groupid=0, jobs=1): err= 0: pid=61067: Fri Dec 11 13:17:49 2020
  write: IOPS=476, BW=1904KiB/s (1950kB/s)(1024MiB/550606msec); 0 zone resets
    slat (nsec): min=1318, max=1296.4k, avg=10144.38, stdev=8984.31
    clat (msec): min=2, max=573, avg=67.20, stdev=75.83
     lat (msec): min=2, max=573, avg=67.21, stdev=75.83
    clat percentiles (msec):
     |  1.00th=[    7],  5.00th=[   10], 10.00th=[   11], 20.00th=[   14],
     | 30.00th=[   16], 40.00th=[   18], 50.00th=[   24], 60.00th=[   39],
     | 70.00th=[   77], 80.00th=[  142], 90.00th=[  201], 95.00th=[  226],
     | 99.00th=[  268], 99.50th=[  284], 99.90th=[  334], 99.95th=[  372],
     | 99.99th=[  451]
   bw (  KiB/s): min=  752, max= 3008, per=100.00%, avg=1904.32, stdev=299.90, samples=1101
   iops        : min=  188, max=  752, avg=476.07, stdev=74.97, samples=1101
  lat (msec)   : 4=0.07%, 10=6.35%, 20=39.92%, 50=17.70%, 100=9.70%
  lat (msec)   : 250=24.14%, 500=2.14%, 750=0.01%
  cpu          : usr=0.94%, sys=0.63%, ctx=189710, majf=0, minf=12936
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=1904KiB/s (1950kB/s), 1904KiB/s-1904KiB/s (1950kB/s-1950kB/s), io=1024MiB (1074MB), run=550606-550606msec

Disk stats (read/write):
    dm-1: ios=0/10212, merge=0/0, ticks=0/26400, in_queue=26400, util=1.01%, aggrios=0/6429, aggrmerge=0/4828, aggrticks=0/92705, aggrin_queue=88544, aggrutil=1.12%
  sdk: ios=0/6429, merge=0/4828, ticks=0/92705, in_queue=88544, util=1.12%

dann habe ich fio nochmal los geschickt mit `bs=1k`, dies aber vorzeitig abgebrochen, da es voll lange gedauert hätte:

# fio rbd.fio
rbd_iodepth32: (g=0): rw=randwrite, bs=(R) 1024B-1024B, (W) 1024B-1024B, (T) 1024B-1024B, ioengine=rbd, iodepth=32
fio-3.12
Starting 1 process
^Cbs: 1 (f=1): [w(1)][3.9%][w=229KiB/s][w=229 IOPS][eta 01h:06m:27s]
fio: terminating on signal 2
Jobs: 1 (f=1): [w(1)][3.9%][w=149KiB/s][w=149 IOPS][eta 01h:06m:37s]
rbd_iodepth32: (groupid=0, jobs=1): err= 0: pid=64599: Fri Dec 11 13:22:20 2020
  write: IOPS=252, BW=252KiB/s (258kB/s)(39.7MiB/161122msec); 0 zone resets
    slat (nsec): min=1002, max=111978, avg=14429.20, stdev=8712.71
    clat (msec): min=6, max=805, avg=126.88, stdev=98.20
     lat (msec): min=6, max=805, avg=126.89, stdev=98.20
    clat percentiles (msec):
     |  1.00th=[   27],  5.00th=[   34], 10.00th=[   40], 20.00th=[   52],
     | 30.00th=[   63], 40.00th=[   73], 50.00th=[   86], 60.00th=[  107],
     | 70.00th=[  146], 80.00th=[  213], 90.00th=[  279], 95.00th=[  330],
     | 99.00th=[  422], 99.50th=[  472], 99.90th=[  575], 99.95th=[  625],
     | 99.99th=[  701]
   bw (  KiB/s): min=   70, max=  334, per=100.00%, avg=252.13, stdev=40.29, samples=322
   iops        : min=   70, max=  334, avg=252.12, stdev=40.29, samples=322
  lat (msec)   : 10=0.03%, 20=0.20%, 50=18.33%, 100=39.11%, 250=28.01%
  lat (msec)   : 500=14.01%, 750=0.31%, 1000=0.01%
  cpu          : usr=0.72%, sys=0.54%, ctx=36276, majf=0, minf=3047
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,40628,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=252KiB/s (258kB/s), 252KiB/s-252KiB/s (258kB/s-258kB/s), io=39.7MiB (41.6MB), run=161122-161122msec

Disk stats (read/write):
    dm-1: ios=0/2929, merge=0/0, ticks=0/4552, in_queue=4552, util=0.93%, aggrios=0/1717, aggrmerge=0/1392, aggrticks=0/15769, aggrin_queue=14816, aggrutil=0.99%
  sdk: ios=0/1717, merge=0/1392, ticks=0/15769, in_queue=14816, util=0.99%

dann habe ich das filesystem für die VM auch nochmal auf "write back" gesetllt, macht es nicht wirklich besser:

$ sudo dd if=/dev/zero of=/storage/file.tmp bs=1024 count=1048756 oflag=dsync
533+0 records in
533+0 records out
545792 bytes (546 kB) copied, 40,5457 s, 13,5 kB/s

entweder ist mein cluster langsamer geworden oder ich hatte das mit den 600MB/s schreibend falsch im hinterkopf gehabt. wie man oben den tests entnehmen kann sind es wohl doch nur ~400MB/s ... sind die hier genannten werte für mein HDD cluster realisitsch oder habe ich noch irgendwo andere probleme?

 

[Alwin]

ioengine=rbd
clientname=admin
pool=rbdbench
rbdname=image01

fio's ioengine rbd spricht direkt mit Ceph, da brauchst kein rbd Image anlegen und mounten.

entweder ist mein cluster langsamer geworden oder ich hatte das mit den 600MB/s schreibend falsch im hinterkopf gehabt. wie man oben den tests entnehmen kann sind es wohl doch nur ~400MB/s ... sind die hier genannten werte für mein HDD cluster realisitsch oder habe ich noch irgendwo andere probleme?

Ein leeres und unbelastetes Cluster hat natürlich eine höhere Performance im Test, als im Betrieb. Und 400 MB/s sind nicht so schlecht mit HDDs. Was aber weit von einer 'small block' Performance weg ist.

sudo dd if=/dev/zero of=/storage/file.tmp bs=1024 count=1048756 oflag=dsync

Wenn die SCI Software wirklich viele Syncs rein schmeißt, dann müssen SSDs her. Oder die Syncs vom Storage ignorieren zu lassen, aber das kann zu Datenverlust führen.

 

[skydiablo]

Oder die Syncs vom Storage ignorieren zu lassen, aber das kann zu Datenverlust führen.

erzähl mir mehr die nodes haben 64GB ram, da sollte einiges weg gebufferd werden können... ganz nach dem motto: nachts ist ja nicht so viel los, da könnte das abgearbeitet werden

 

[Alwin]

erzähl mir mehr die nodes haben 64GB ram, da sollte einiges weg gebufferd werden können... ganz nach dem motto: nachts ist ja nicht so viel los, da könnte das abgearbeitet werden

Naja, nicht ganz so. Der Cache Mode writeback (unsafe) garantiert keine flushes mehr. Das könnte helfen, ist aber auch nur ein Notnagel.

Ansonsten wäre noch Caching in der VM zu betreiben. Aber am Ende muss darauf aufgepasst werden, dass nicht zu viel Caching die Performance wieder drückt (latency).

 

[skydiablo]

also mit "writeback (unsafe)" habe ich:

dd if=/dev/zero of=~/file.tmp bs=1024 count=1048756 oflag=dsync
31529+0 records in
31529+0 records out
32285696 bytes (32 MB, 31 MiB) copied, 12.0101 s, 2.7 MB/s

also schonmal um einiges schicker, ist die frage wie "unsafe" ist das am ende?

 

[Alwin]

also schonmal um einiges schicker, ist die frage wie "unsafe" ist das am ende?

Das ist eher nach dem Motto, wenn du deine Daten liebst, dann ist unsafe falsch.

 

[skydiablo]

okay, vielen dank für das feedback! hat mir sehr geholfen, insbesondere die einstufung dass mein reines HDD ceph cluster mit 4mb packages und ~400mb/s im speed so ganz in ordnung ist...