Proxmox Ceph hohe Stddev Bandwidth

H

Haithabu84

Renowned Member
Oct 19, 2016
119
4
83
34
Hallo,

ich bin gerade dabei ein 3-Node-Cluster mit Ceph aufzubauen und zu testen. Folgende Hardware wird verwendet:

  • AMD Epyc 7543p
  • 256Gb DDR4-3200
  • pro Node 4x Samsung PN1733 TB MZWLJ1T9HBJR (als OSD)
  • Mellanox ConnectX-6 100Gbit
Nach anfänglichen Tests mit rados bench hatte ich leicht bessere Werte als das System aus dem Benchmark Papers. Hier mal ein Beispiel wie es ungefähr aussah:

Code: 
Total time run:         100.012
Total writes made:      96448
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     3857.47
Stddev Bandwidth:       800.572
Max bandwidth (MB/sec): 4312
Min bandwidth (MB/sec): 384
Average IOPS:           964
Stddev IOPS:            200.143
Max IOPS:               1078
Min IOPS:               96
Average Latency(s):     0.0165887
Stddev Latency(s):      0.0261776
Max latency(s):         1.18573
Min latency(s):         0.00493058

Das ist sogar noch einer der schlechteren. Ich hatte sogar einen mit bisschen mehr als 1164 IOPS. Leider nicht weg gesichert. Mit Fio sah es so aus, nach paar Optimierungen:

Code: 
fio --ioengine=rbd --pool=benchmark --rbdname=test_benchmark --direct=1 --fsync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=4k-sync-write-1

Code: 
4k-sync-write-1: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=rbd, iodepth=1
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=7867KiB/s][w=1966 IOPS][eta 00m:00s]
4k-sync-write-1: (groupid=0, jobs=1): err= 0: pid=3598016: Mon Feb  7 10:06:43 2022
  write: IOPS=1962, BW=7849KiB/s (8038kB/s)(460MiB/60001msec); 0 zone resets
    slat (nsec): min=1670, max=435085, avg=3444.69, stdev=1876.55
    clat (usec): min=6, max=8450, avg=19.71, stdev=24.93
     lat (usec): min=11, max=8535, avg=23.15, stdev=25.33
    clat percentiles (nsec):
     |  1.00th=[12992],  5.00th=[15168], 10.00th=[15552], 20.00th=[15936],
     | 30.00th=[16512], 40.00th=[18304], 50.00th=[19328], 60.00th=[20096],
     | 70.00th=[20864], 80.00th=[22144], 90.00th=[24960], 95.00th=[28544],
     | 99.00th=[31872], 99.50th=[33536], 99.90th=[39168], 99.95th=[41216],
     | 99.99th=[61184]
   bw (  KiB/s): min=  368, max= 8616, per=100.00%, avg=7921.42, stdev=971.49, samples=118
   iops        : min=   92, max= 2154, avg=1980.36, stdev=242.87, samples=118
  lat (usec)   : 10=0.05%, 20=59.56%, 50=40.37%, 100=0.02%, 250=0.01%
  lat (msec)   : 10=0.01%
  fsync/fdatasync/sync_file_range:
    sync (usec): min=48, max=1411.4k, avg=482.92, stdev=4113.19
    sync percentiles (usec):
     |  1.00th=[  416],  5.00th=[  429], 10.00th=[  437], 20.00th=[  445],
     | 30.00th=[  453], 40.00th=[  457], 50.00th=[  465], 60.00th=[  469],
     | 70.00th=[  474], 80.00th=[  482], 90.00th=[  494], 95.00th=[  506],
     | 99.00th=[  652], 99.50th=[  791], 99.90th=[ 2147], 99.95th=[ 2704],
     | 99.99th=[ 4883]
  cpu          : usr=2.07%, sys=1.28%, ctx=235623, majf=17, minf=9
  IO depths    : 1=200.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 rwts: total=0,117741,0,117741 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=7849KiB/s (8038kB/s), 7849KiB/s-7849KiB/s (8038kB/s-8038kB/s), io=460MiB (482MB), run=60001-60001msec

Qperf auf dem Storage-Netzwerk mit den Mellanox:

Code: 
root@pve2:~# qperf -vvs 10.255.244.50 tcp_lat
tcp_lat:
    latency         =    11.4 us
    msg_rate        =    87.5 K/sec
    loc_send_bytes  =    87.5 KB
    loc_recv_bytes  =    87.5 KB
    loc_send_msgs   =  87,518
    loc_recv_msgs   =  87,517
    rem_send_bytes  =    87.5 KB
    rem_recv_bytes  =    87.5 KB
    rem_send_msgs   =  87,518
    rem_recv_msgs   =  87,518

Ich habe dann die Pools gelöscht und nun final saubere Benchmarks zu erzeugen um diese zu dokumentieren. Nun habe ich diese Ergebnisse mit rados:

Code: 
Total time run:         100.257
Total writes made:      68783
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     2744.27
Stddev Bandwidth:       1201.76
Max bandwidth (MB/sec): 4296
Min bandwidth (MB/sec): 0
Average IOPS:           686
Stddev IOPS:            300.444
Max IOPS:               1074
Min IOPS:               0
Average Latency(s):     0.0232648
Stddev Latency(s):      0.147945
Max latency(s):         3.35392
Min latency(s):         0.00477104

Was hier auffällt sind die besonders hohen Werte für "Stddev Bandwith" die normalerweise vorher eher unter 100 lagen. Warum sind diese so hoch? Und warum bricht hier so die Bandbreite weg und IOPS ein?

Code: 
pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.13.19-4-pve)
pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe)
pve-kernel-helper: 7.1-10
pve-kernel-5.13: 7.1-7
pve-kernel-5.13.19-4-pve: 5.13.19-9
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph: 16.2.7
ceph-fuse: 16.2.7
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-2
libpve-guest-common-perl: 4.0-3
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.1-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-1
proxmox-backup-client: 2.1.5-1
proxmox-backup-file-restore: 2.1.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-5
pve-cluster: 7.1-3
pve-container: 4.1-3
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-5
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.1-1
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-1
spiceterm: 3.2-2
swtpm: 0.7.0~rc1+2
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1

Meine Optimierungen:

  • RX/TX Buffer bei den Mellanox Karten auf 8192
  • MTU 9000
  • cpupower frequency-set -g performance
  • cpupower idle-set -D 11
Ansonsten habe ich mich für das Broadcast-Bonding für das Ceph Cluster-Netzwerk entschieden. Corosync läuft auf separaten Schnittstellen. Public-Interface ebenfalls separat.

Jemand eine Idee woher die Performance-Einbuße herkommen?

Gruß
 
Last edited:
Hi,
ich kann dir keine Antwort geben, aber Broadcast-Bonding für CEPH würde ich nicht empfehlen.
Wenn du die 3 Nodes im MESH hast, dann haben wir die besten Erfahrungen mit entsprechendem Routing gemacht.
 
itNGO said:
Hi,
ich kann dir keine Antwort geben, aber Broadcast-Bonding für CEPH würde ich nicht empfehlen.
Wenn du die 3 Nodes im MESH hast, dann haben wir die besten Erfahrungen mit entsprechendem Routing gemacht.
Click to expand...
Ja, ich verwende Mesh-Network. Ich habe jeweils schon Broadcast und RSTP Loop gegeneinander antreten lassen. Beide haben sich nichts genommen. Der Broadcast Bond war sogar leicht besser in den Latenzen.

Routing ist auf jeden Fall performanter, ohne Frage, ich muss es aber einfach halten. Da später Leute das Cluster warten müssen, die nicht so tief in der Materie drin sind. Hört sich komisch an, ist aber so.

Das komische ist halt, das per Broadcast Bond erst hervorragende Werte geliefert werden und aus dem Nichts bricht die Performance ein. Obwohl weder etwas verstellt, neugestartet oder konfiguriert wurde.
 
Das sind doch "nur" 2 Zeilen in der Interface-Config. Einfacher geht es doch kaum noch.... ;-)
Code: 
up ip route add 10.255.177.11/32 dev enp1s0f0np0
 down ip route del 10.255.177.11/32
 
Haithabu84 said:
Das komische ist halt, das per Broadcast Bond erst hervorragende Werte geliefert werden und aus dem Nichts bricht die Performance ein. Obwohl weder etwas verstellt, neugestartet oder konfiguriert wurde.
Click to expand...
Kommt vor... Broadcast ist halt eine "Made"..... würde ich wirklich vermeiden wenn es anders geht....
 
Ich habe jetzt nochmal Routing eingebaut und der Unterschied ist wirklich verblüffend... ich wusste zwar das die Performance dort am besten ist, aber nicht das es so viel ausmacht. Ein Unterschied wie Tag und Nacht. Einzig die Sache mit der Fault-Tolerance ist ein bisschen heikel. Das kann man im Endeffekt bei jeweils einer Karte pro Node nur mit RSTP Loop lösen. Oder man muss halt Haufen Geld in die Hand nehmen.
 
  • Like
Reactions: itNGO
Haithabu84 said:
Ich habe jetzt nochmal Routing eingebaut und der Unterschied ist wirklich verblüffend... ich wusste zwar das die Performance dort am besten ist, aber nicht das es so viel ausmacht. Ein Unterschied wie Tag und Nacht. Einzig die Sache mit der Fault-Tolerance ist ein bisschen heikel. Das kann man im Endeffekt bei jeweils einer Karte pro Node nur mit RSTP Loop lösen. Oder man muss halt Haufen Geld in die Hand nehmen.
Click to expand...
Der MESH sieht ja eigentlich 2 Ports pro LOAD vor. Also 2 Ports für CEPH-Storage, 2 für CEPH-Client und ggf. dann 1 oder 2 für den VM-Traffic..... wenn es redundant sein soll, dann doch auch richtig oder?
 
You must log in or register to reply here.
Top Bottom