IO Performance auf VMs auf Ceph ist extrem schlecht

S

Stefan_Malte_Schumacher

Member
Proxmox Subscriber
May 4, 2021
91
2
13
43
Hallo,

wir sind gerade dabei uns von klassischen Storage-Lösungen wie lokalen RAID10 bzw. wenn HA gewünscht ist einem mit iSCSI angebundenen Dell SAN zu verabschieden. Im Moment laufen zwei Testcluster: Ein "großer", bei dem jede Node 2 x 18 Cores und 256GB RAM hat, und ein "kleiner", in dem in jeder Node eine CPU mit 8 Cores und 128GB RAM stecken. Die großen Nodes haben 3 x 7.68TB SATA-Enterprise-SSDs und die kleinen Nodes haben 3 x 960GB Corsair MP510 NVMe-SSDs. Für Ceph ist bei beiden Systemen ein dedizierter 10 Gbits Link mit LACP vorhanden. Alle Nodes sind frisch installiert PVE 8.0-Systeme.

Ich habe vorher verschiedene vorhandene Systeme mit fio gebenchmarkt um Vergleichswerte für die Tests zu bekommen. Dann habe ich mit fio auf einer VM auf dem großen Cluster - der war auch als erster aufgebaut, der NVMe-Cluster wurde erst nach den Ergebnisse des Benchmarks des SATA-SSD-Clusters zusammengebaut - verschiedene Benchmarks gemacht. Selbst mit kleinen Blocksizes haben ich nur Werte zwischen 3-400 IOPs bekommen. Der Schuldige war dann dann (vor)schnell gefunden, es mussten die SATA-SSDs gewesen sein. Schließlich liest man überall, daß man für Ceph NVMe verwenden soll. Dann haben wir den kleinen Cluster aufgebaut und auch dort Benchmarks mit fio auf den VMs gemacht. Ergebnis: Ebenfalls nur 300-400 IOPs, also keinerlei Verbesserung gegenüber SATA.

Als Konsequenz sind einen Schritt zurückgegangen und haben mit ceph rados bench Tests direkt auf RADOS gemacht und danach mit rbd bench auf einen für die Test angelegten Block Device. (Vorlage dafür war diese Anleitung auf ceph.com) Ergebnis: Sobald ich die Blockgrößen nach unten und die Number der Threads nach oben schraubte erhielt ich auf beiden Clustern und zwar sowohl mit "rbd bench" als auch mit "rados bench" Werte zwischen 40-60000 IOPs. Ein Unterschied zwischen SATA- und NVMe-SSDs war nicht festzustellen.

Wieso bekommen wir auf beiden Clustern auf den VMs so schlechte Werte? Wie kann man sich den großen Unterschied zwischen rbd bench und fio in der VM erklären? Schließlich schreiben beide auf ein Block Device im Ceph. Auch Fio scheint ja das richtige Tool zu sein, schließlich wird es auch im quasi offiziellen Benchmark verwendet, der hier oben im Forum angepinnt ist. Mich würden auch ein paar Vergleichswerte interessieren. Wieviel IOPs bekommt ihr auf den VMs auf euren Ceph-Clustern, unabhängig davon ob ihr SATA- oder NVMe-SSDs verwendet? Und wie kann ich diese Werte verbessern? Ceph hat viele für uns interessante Features bzgl. Datenverfügbarkeit- und Integrität. Aber mit einer so schlechten Performance können wir diese Systeme weder selbst verwenden noch unseren Kunden anbieten, was ich sehr bedauern würde.

Viele Grüße
Stefan
 
Kannst du ein paar Ergebnisse direkt posten? FIO Befehl und Ausgabe? Genauso für die anderen Benchmarks.

Wie schaut die Config der VMs die zum testen verwendet wurden aus?

Und mehr details zur Hardware wäre auch gut. CPU Modelle, Modelle der SATA SSDs.

Was sagen die folgenden Befehle?
  • ceph osd df tree
  • ceph -s
  • pveceph pool ls --noborder (bitte in einem breiten Terminal ausführen oder in eine Datei umleiten.
Die Ergebnisse bitte innerhalb von [CODE][/CODE] posten damit sie lesbar sind. Gut möglich, dass hier noch ein paar Dinge nicht gut konfiguriert sind.
 
Das ganze Thema Ceph ist eh etwas Komplexer als z.B. ein einfaches iSCSI Storage.
Ich merke große Unterschiede ob ich 40G (4Kanäle mit 10G) oder 25G/100G nutze. Die niedrigere Latenz wirkt sich schon deutlich aus.
Ceph macht auch viel mehr Netzwerktraffic. Im Clusternetz hast du in der Regel 3x so viel Traffic wie im Publich Netzwerk und wenn du nur einen 10G Link hast, bekommst du in der Regel maximal die Performance von 2,5G Netto.
SATA SSDs habe ich in meinem Ceph zuhause, da ist das OK, aber nicht gut. Mit echten NVMe (ich nutze meistens Kioxia 7,68TB U2 NVMe) da habe ich bei kleinen Clustern mit je 3 OSD Pro Node schon mal bis zu 60GBit Traffic. Mit kleinen Blöcken bekommst du bei Ceph eh nicht so viel raus, vor allem beim schreiben. Mit den NVMe ist es aber für den typischen Mittelständler vollkommen ausreichen.
 
Hallo Aaron, hallo Falk.

ich kopiere euch das mal zusammen. Ich versuche die Informationsüberflutung in Grenzen zu halten und werde das ganze vermutlich in zwei bis drei Posts aufteilen, damit es lesbar bleibt.

Hinweis: Ich habe bewußt so kleine Block Sizes gewählt, damit wir auch wirklich an die Grenzen der Systeme kommen. Bei meinen vergleichenden Tests verschiedener Systeme bin ich bin ich bei großen Dateien oft nur auf einen Bruchteil von einer IOPs gekommen.

großer SATA-SSD-Cluster

rados bench

Code: 
rados bench -p scbench 60 write --no-cleanup -b 512B -t 128
Total time run:         60.0065
Total writes made:      933045
Write size:             512
Object size:            512
Bandwidth (MB/sec):     7.59231
Stddev Bandwidth:       0.45628
Max bandwidth (MB/sec): 8.7373
Min bandwidth (MB/sec): 6.69336
Average IOPS:           15549
Stddev IOPS:            934.461
Max IOPS:               17894
Min IOPS:               13708
Average Latency(s):     0.00823007
Stddev Latency(s):      0.00767289
Max latency(s):         0.0604167
Min latency(s):         0.00131066

Code: 
rados bench -p scbench 60 seq --no-cleanup -t 128
Total time run:       14.5054
Total reads made:     933045
Read size:            512
Object size:          512
Bandwidth (MB/sec):   31.4081
Average IOPS:         64323
Stddev IOPS:          2957.07
Max IOPS:             71428
Min IOPS:             61175
Average Latency(s):   0.00198632
Max latency(s):       0.0179259
Min latency(s):       0.000118948

rbd bench

Code: 
rbd bench --io-type write --io-size 512B image01 --pool rbdbench
elapsed: 17   ops: 2097152   ops/sec: 121816   bytes/sec: 59 MiB/s

rbd bench --io-type read --io-size 512B image01 --pool rbdbench
elapsed: 28   ops: 2097152   ops/sec: 74368.3   bytes/sec: 36 MiB/s


kleiner NVMe-Cluster

rados bench

Code: 
rados bench -p scbench 60 write --no-cleanup -b 512B -t 128
Total time run:         60.0144
Total writes made:      889286
Write size:             512
Object size:            512
Bandwidth (MB/sec):     7.23529
Stddev Bandwidth:       0.535378
Max bandwidth (MB/sec): 8.15381
Min bandwidth (MB/sec): 6.4082
Average IOPS:           14817
Stddev IOPS:            1096.45
Max IOPS:               16699
Min IOPS:               13124
Average Latency(s):     0.00863486
Stddev Latency(s):      0.00546194
Max latency(s):         0.0655655
Min latency(s):         0.000695861

Code: 
rados bench -p scbench 60 seq --no-cleanup -t 128
Total time run:       12.8091
Total reads made:     889286
Read size:            512
Object size:          512
Bandwidth (MB/sec):   33.8995
Average IOPS:         69426
Stddev IOPS:          5392.72
Max IOPS:             76555
Min IOPS:             58971
Average Latency(s):   0.00183988
Max latency(s):       0.142355
Min latency(s):       0.000171672

rbd bench

Code: 
rbd bench --io-type write --io-size 512B image01 --pool rbdbench
elapsed: 24   ops: 2097152   ops/sec: 85415.8   bytes/sec: 42 MiB/s

rbd bench --io-type read --io-size 512B image01 --pool rbdbench
elapsed: 51   ops: 2097152   ops/sec: 40503.9   bytes/sec: 20 MiB/s
 
Und jetzt kommen die Anfragen zur Hardware

Großer Cluster

Hardware:

Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - 2 Sockets pro Node

SSDs:
- SAMSUNG MZ7L37T6HBLA-00A07
- SAMSUNG MZ7LH7T6HMLA-00005
- Micron_5300_MTFDDAK7T6TDS

Ceph-Konfiguration:

Code: 
ceph osd df tree
ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME           
-1         62.87668         -   63 TiB  2.2 TiB  2.2 TiB  115 KiB   13 GiB   61 TiB  3.47  1.00    -          root default       
-3         20.95889         -   21 TiB  745 GiB  741 GiB   42 KiB  4.5 GiB   20 TiB  3.47  1.00    -              host srv-243-111
 0    ssd   6.98630   1.00000  7.0 TiB  276 GiB  274 GiB   11 KiB  1.6 GiB  6.7 TiB  3.86  1.11   53      up          osd.0       
 1    ssd   6.98630   1.00000  7.0 TiB  296 GiB  294 GiB   18 KiB  1.8 GiB  6.7 TiB  4.13  1.19   70      up          osd.1       
 2    ssd   6.98630   1.00000  7.0 TiB  174 GiB  173 GiB   13 KiB  1.2 GiB  6.8 TiB  2.43  0.70   38      up          osd.2       
-5         20.95889         -   21 TiB  745 GiB  741 GiB   34 KiB  4.3 GiB   20 TiB  3.47  1.00    -              host srv-243-112
 3    ssd   6.98630   1.00000  7.0 TiB  212 GiB  210 GiB    8 KiB  1.5 GiB  6.8 TiB  2.96  0.85   50      up          osd.3       
 4    ssd   6.98630   1.00000  7.0 TiB  226 GiB  225 GiB   14 KiB  1.2 GiB  6.8 TiB  3.16  0.91   54      up          osd.4       
 5    ssd   6.98630   1.00000  7.0 TiB  307 GiB  306 GiB   12 KiB  1.6 GiB  6.7 TiB  4.30  1.24   57      up          osd.5       
-7         20.95889         -   21 TiB  745 GiB  741 GiB   39 KiB  4.5 GiB   20 TiB  3.47  1.00    -              host srv-403-11
 6    ssd   6.98630   1.00000  7.0 TiB  258 GiB  256 GiB   17 KiB  1.7 GiB  6.7 TiB  3.61  1.04   62      up          osd.6       
 7    ssd   6.98630   1.00000  7.0 TiB  273 GiB  271 GiB   13 KiB  1.6 GiB  6.7 TiB  3.82  1.10   51      up          osd.7       
 8    ssd   6.98630   1.00000  7.0 TiB  214 GiB  213 GiB    9 KiB  1.3 GiB  6.8 TiB  2.99  0.86   48      up          osd.8       
                        TOTAL   63 TiB  2.2 TiB  2.2 TiB  119 KiB   13 GiB   61 TiB  3.47                                         
MIN/MAX VAR: 0.70/1.24  STDDEV: 0.58

Code: 
ceph -s
  cluster:
    id:     fb46bed3-3bac-4708-82a8-de860db83f84
    health: HEALTH_WARN
            2 pool(s) do not have an application enabled
            1 pools have pg_num > pgp_num
 
  services:
    mon: 3 daemons, quorum srv-243-111,srv-243-112,srv-403-11 (age 5w)
    mgr: srv-403-11(active, since 5w), standbys: srv-243-112, srv-243-111
    mds: 1/1 daemons up, 2 standby
    osd: 9 osds: 9 up (since 2d), 9 in (since 5w)
 
  data:
    volumes: 1/1 healthy
    pools:   6 pools, 161 pgs
    objects: 2.37M objects, 758 GiB
    usage:   2.2 TiB used, 61 TiB / 63 TiB avail
    pgs:     161 active+clean
 
  io:
    client:   34 KiB/s wr, 0 op/s rd, 6 op/s wr

Code: 
pveceph pool ls --noborder
Name            Size Min Size PG Num min. PG Num Optimal PG Num PG Autoscale Mode PG Autoscale Target Size PG Autoscale Target Ratio Crush Rule Name               %-Used Used
.mgr               3        2      1           1              1 on                                                                   replicated_rule 1.24495261388802e-06 78065664
cephblk            3        2     32                         32 on                                                                   replicated_rule   0.0218644086271524 1401668809659
cephfs_data        3        2     32                         32 on                                                                   replicated_rule 9.04235421330668e-05 5670580224
cephfs_metadata    3        2     32          16             16 on                                                                   replicated_rule 9.53370182799063e-09 597817
rbdbench           3        2     32                         32 on                                                                   replicated_rule 5.13688137289137e-05 3221280516
scbench            3        2     32                         32 on                                                                   replicated_rule   0.0153163410723209 975360184320


Kleiner Cluster

Hardware:

Intel(R) Xeon(R) D-2141I CPU @ 2.20GHz - 1 Socket pro Node
SSDs:
- SAMSUNG MZQL2960HCJR-00A07
- Corsair Force MP510
- Corsair MP600 GS

Ceph-Konfiguration:

Code: 
ceph osd df tree
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP    META     AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME           
-1         7.89603         -  7.9 TiB  523 GiB  513 GiB  58 KiB   10 GiB  7.4 TiB  6.47  1.00    -          root default         
-3         2.61987         -  2.6 TiB  174 GiB  171 GiB  18 KiB  3.5 GiB  2.4 TiB  6.50  1.00    -              host pcluster3-01
 0    ssd  0.87329   1.00000  894 GiB   75 GiB   74 GiB   4 KiB  1.2 GiB  819 GiB  8.41  1.30   53      up          osd.0       
 1    ssd  0.87329   1.00000  894 GiB   60 GiB   59 GiB   5 KiB  1.4 GiB  834 GiB  6.73  1.04   60      up          osd.1       
 2    ssd  0.87329   1.00000  894 GiB   39 GiB   38 GiB   9 KiB  920 MiB  855 GiB  4.36  0.67   48      up          osd.2       
-5         2.61987         -  2.6 TiB  174 GiB  171 GiB  22 KiB  3.3 GiB  2.4 TiB  6.49  1.00    -              host pcluster3-02
 3    ssd  0.87329   1.00000  894 GiB   38 GiB   37 GiB   9 KiB  908 MiB  856 GiB  4.29  0.66   52      up          osd.3       
 4    ssd  0.87329   1.00000  894 GiB   61 GiB   60 GiB   7 KiB  1.3 GiB  833 GiB  6.87  1.06   56      up          osd.4       
 5    ssd  0.87329   1.00000  894 GiB   74 GiB   73 GiB   6 KiB  1.2 GiB  820 GiB  8.32  1.29   53      up          osd.5       
-7         2.65628         -  2.7 TiB  175 GiB  171 GiB  18 KiB  3.6 GiB  2.5 TiB  6.42  0.99    -              host pcluster3-03
 6    ssd  0.90970   1.00000  932 GiB   49 GiB   48 GiB   4 KiB  1.0 GiB  883 GiB  5.25  0.81   56      up          osd.6       
 7    ssd  0.87329   1.00000  894 GiB   71 GiB   70 GiB   5 KiB  1.4 GiB  823 GiB  7.93  1.23   51      up          osd.7       
 8    ssd  0.87329   1.00000  894 GiB   55 GiB   53 GiB   9 KiB  1.3 GiB  840 GiB  6.11  0.94   54      up          osd.8       
                       TOTAL  7.9 TiB  523 GiB  513 GiB  63 KiB   10 GiB  7.4 TiB  6.47                                         
MIN/MAX VAR: 0.66/1.30  STDDEV: 1.51

Code: 
ceph -s
  cluster:
    id:     2421dd57-b48f-4966-9777-b2018a6f2c55
    health: HEALTH_WARN
            2 pool(s) do not have an application enabled
 
  services:
    mon: 3 daemons, quorum pcluster3-01,pcluster3-02,pcluster3-03 (age 8d)
    mgr: pcluster3-01(active, since 8d), standbys: pcluster3-02, pcluster3-03
    mds: 1/1 daemons up, 2 standby
    osd: 9 osds: 9 up (since 2d), 9 in (since 8d)
 
  data:
    volumes: 1/1 healthy
    pools:   6 pools, 161 pgs
    objects: 2.00M objects, 165 GiB
    usage:   523 GiB used, 7.4 TiB / 7.9 TiB avail
    pgs:     161 active+clean
 
  io:
    client:   1023 B/s wr, 0 op/s rd, 0 op/s wr

Code: 
pveceph pool ls --noborder
Name            Size Min Size PG Num min. PG Num Optimal PG Num PG Autoscale Mode PG Autoscale Target Size PG Autoscale Target Ratio Crush Rule Name               %-Used Used
.mgr               3        2      1           1              1 on                                                                   replicated_rule 6.83228108755429e-07 5136384
cephblk            3        2     32                         32 on                                                                   replicated_rule  0.00225213775411248 16969364768
cephfs_data        3        2     32                         32 on                                                                   replicated_rule 0.000262290966929868 1972371456
cephfs_metadata    3        2     32          16             16 on                                                                   replicated_rule 5.10370554707151e-08 383687
rbdbench           3        2     32                         32 on                                                                   replicated_rule 0.000428301136707887 3221266883
scbench            3        2     32                         32 on                                                                   replicated_rule   0.0656279399991035 528032169984
 
Du hast recht wenige PGs, ich hätte mindestens 64 oder 128 genommen.
Mit 10 GBit und einem Single Task wirst du vermutlich nicht viel mehr raus bekommen. Read sollte eigentlich bei den NVMe etwas besser aussehen, aber die m.2 NVMe sind vermutlich Consumer-Ware und auch nicht so Leistungsstabil. Ich nutze nur Enterprise NVMe im 2,5" Format (U2) und die haben laut Datenblatt auch ganz andere Leistungen.
SATA SSDs und m.2 sind für mich nur zum Spielen geeignet. Für Produktive Cluster gibt es vernünftige Hardware und dann hat man auch gute Performance.
 
Ein kleiner Hinweis: Ich habe als nicht damit gerechnet, daß so umfangreiche Rückfragen kommen würden. Ich bin AFK und werde einige Tage keine Rückfragen beantworten können. Ich habe aber einem Kollegen gebeten sich den Thread und die Antworten regelmässig anzuschauen.



FIO-Ergebnisse

Alle VMs haben 16 vCPUs und 32GB RAM sowie ext4 als Dateisystem.

VM auf großem Cluster:

Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=randrw, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=200KiB/s,w=205KiB/s][r=401,w=410 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=35969: Thu Oct 12 14:26:34 2023
  read: IOPS=405, BW=203KiB/s (208kB/s)(5129KiB/25290msec)
    slat (usec): min=3, max=150, avg=17.01, stdev=11.04
    clat (usec): min=645, max=44672, avg=18682.50, stdev=4448.93
     lat (usec): min=663, max=44681, avg=18699.50, stdev=4450.08
    clat percentiles (usec):
     |  1.00th=[ 8094],  5.00th=[11076], 10.00th=[12911], 20.00th=[15008],
     | 30.00th=[16450], 40.00th=[17695], 50.00th=[18744], 60.00th=[19792],
     | 70.00th=[21103], 80.00th=[22414], 90.00th=[24511], 95.00th=[25822],
     | 99.00th=[28443], 99.50th=[29492], 99.90th=[32113], 99.95th=[36963],
     | 99.99th=[42206]
   bw (  KiB/s): min=  154, max=  253, per=99.60%, avg=202.32, stdev=18.78, samples=50
   iops        : min=  308, max=  506, avg=404.64, stdev=37.57, samples=50
  write: IOPS=404, BW=202KiB/s (207kB/s)(5111KiB/25290msec); 0 zone resets
    slat (usec): min=1573, max=12946, avg=2445.17, stdev=464.34
    clat (usec): min=669, max=41133, avg=18351.53, stdev=4310.60
     lat (usec): min=3102, max=44799, avg=20796.71, stdev=4360.93
    clat percentiles (usec):
     |  1.00th=[ 7963],  5.00th=[11076], 10.00th=[12649], 20.00th=[14746],
     | 30.00th=[16057], 40.00th=[17433], 50.00th=[18482], 60.00th=[19530],
     | 70.00th=[20841], 80.00th=[22152], 90.00th=[23987], 95.00th=[25035],
     | 99.00th=[27395], 99.50th=[28181], 99.90th=[31065], 99.95th=[37487],
     | 99.99th=[41157]
   bw (  KiB/s): min=  154, max=  214, per=99.95%, avg=202.06, stdev= 8.90, samples=50
   iops        : min=  308, max=  428, avg=404.12, stdev=17.81, samples=50
  lat (usec)   : 750=0.01%
  lat (msec)   : 4=0.05%, 10=2.76%, 20=59.98%, 50=37.20%
  cpu          : usr=0.60%, sys=2.59%, ctx=15290, majf=0, minf=14
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=10258,10222,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=203KiB/s (208kB/s), 203KiB/s-203KiB/s (208kB/s-208kB/s), io=5129KiB (5252kB), run=25290-25290msec
  WRITE: bw=202KiB/s (207kB/s), 202KiB/s-202KiB/s (207kB/s-207kB/s), io=5111KiB (5234kB), run=25290-25290msec

Disk stats (read/write):
  sda: ios=10175/10349, merge=0/38, ticks=6957/21930, in_queue=28893, util=99.69%

Ich merke, daß ich mich bei meinem Benchmarks zu sehr auf die gemischten Benchmarks, also --rw=randrw konzentriert habe. Mit read sieht es schon viel besser aus. Ich bleibe aber bei meiner Grundaussage: Wenn ich nicht mal 1000 IOPs im randrw bekomme, dann kann ich meine Kollegen und meinen Chef nicht von den Vorteilen von Ceph überzeugen. Klar geht auch ein Webserver mit 4-500 IOPs. Aber was mache ich dann wenn der Kunde ein Matomo oder eine anderen Datenbankapplikationen mit viel randrw haben will?


Code: 
fio --direct=1 --ioengine=libaio --rw=read --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=read, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process

test: (groupid=0, jobs=1): err= 0: pid=36006: Thu Oct 12 14:29:11 2023
  read: IOPS=38.1k, BW=18.6MiB/s (19.5MB/s)(10.0MiB/537msec)
    slat (nsec): min=3647, max=88761, avg=9335.81, stdev=4626.57
    clat (usec): min=196, max=1229, avg=408.77, stdev=99.26
     lat (usec): min=205, max=1233, avg=418.11, stdev=99.17
    clat percentiles (usec):
     |  1.00th=[  251],  5.00th=[  285], 10.00th=[  302], 20.00th=[  326],
     | 30.00th=[  347], 40.00th=[  367], 50.00th=[  392], 60.00th=[  416],
     | 70.00th=[  449], 80.00th=[  486], 90.00th=[  537], 95.00th=[  586],
     | 99.00th=[  685], 99.50th=[  766], 99.90th=[  988], 99.95th=[ 1020],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=18822, max=18822, per=98.71%, avg=18822.00, stdev= 0.00, samples=1
   iops        : min=37644, max=37644, avg=37644.00, stdev= 0.00, samples=1
  lat (usec)   : 250=0.97%, 500=82.30%, 750=16.20%, 1000=0.44%
  lat (msec)   : 2=0.08%
  cpu          : usr=16.23%, sys=42.72%, ctx=5311, majf=0, minf=12
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=20480,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=18.6MiB/s (19.5MB/s), 18.6MiB/s-18.6MiB/s (19.5MB/s-19.5MB/s), io=10.0MiB (10.5MB), run=537-537msec

Disk stats (read/write):
  sda: ios=14153/0, merge=0/0, ticks=5839/0, in_queue=5838, util=80.49%

Code: 
fio --direct=1 --ioengine=libaio --rw=write --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=write, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=262KiB/s][w=525 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=36017: Thu Oct 12 14:30:28 2023
  write: IOPS=510, BW=255KiB/s (261kB/s)(10.0MiB/40152msec); 0 zone resets
    slat (usec): min=1364, max=11369, avg=1953.18, stdev=258.45
    clat (usec): min=6, max=39334, avg=29398.01, stdev=1491.79
     lat (usec): min=1975, max=41165, avg=31351.19, stdev=1556.22
    clat percentiles (usec):
     |  1.00th=[26346],  5.00th=[27132], 10.00th=[27657], 20.00th=[28181],
     | 30.00th=[28705], 40.00th=[28967], 50.00th=[29492], 60.00th=[29754],
     | 70.00th=[30016], 80.00th=[30540], 90.00th=[31065], 95.00th=[31851],
     | 99.00th=[32900], 99.50th=[33817], 99.90th=[36963], 99.95th=[38011],
     | 99.99th=[38536]
   bw (  KiB/s): min=  231, max=  276, per=99.60%, avg=255.00, stdev= 8.18, samples=80
   iops        : min=  462, max=  552, avg=510.00, stdev=16.35, samples=80
  lat (usec)   : 10=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.02%, 50=99.95%
  cpu          : usr=0.59%, sys=2.05%, ctx=20485, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,20480,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=255KiB/s (261kB/s), 255KiB/s-255KiB/s (261kB/s-261kB/s), io=10.0MiB (10.5MB), run=40152-40152msec

Disk stats (read/write):
  sda: ios=0/20747, merge=0/42, ticks=0/41117, in_queue=41136, util=99.84%


VM auf kleinem Cluster:

Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=randrw, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process
test: Laying out IO file (1 file / 10MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=298KiB/s,w=293KiB/s][r=597,w=586 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=60070: Thu Oct 12 14:35:19 2023
  read: IOPS=566, BW=283KiB/s (290kB/s)(5129KiB/18105msec)
    slat (usec): min=4, max=120, avg=12.78, stdev= 8.51
    clat (usec): min=238, max=28634, avg=13360.03, stdev=3782.51
     lat (usec): min=250, max=28640, avg=13372.81, stdev=3783.14
    clat percentiles (usec):
     |  1.00th=[ 5342],  5.00th=[ 7504], 10.00th=[ 8586], 20.00th=[10159],
     | 30.00th=[11338], 40.00th=[12256], 50.00th=[13173], 60.00th=[14091],
     | 70.00th=[15139], 80.00th=[16450], 90.00th=[18220], 95.00th=[19792],
     | 99.00th=[23462], 99.50th=[24511], 99.90th=[27132], 99.95th=[27919],
     | 99.99th=[28443]
   bw (  KiB/s): min=  235, max=  331, per=99.54%, avg=282.47, stdev=22.22, samples=36
   iops        : min=  470, max=  662, avg=564.94, stdev=44.44, samples=36
  write: IOPS=564, BW=282KiB/s (289kB/s)(5111KiB/18105msec); 0 zone resets
    slat (usec): min=648, max=8077, avg=1748.82, stdev=686.51
    clat (usec): min=255, max=28636, avg=13153.12, stdev=3765.05
     lat (usec): min=1382, max=30136, avg=14901.93, stdev=3876.58
    clat percentiles (usec):
     |  1.00th=[ 5211],  5.00th=[ 7242], 10.00th=[ 8455], 20.00th=[10028],
     | 30.00th=[11076], 40.00th=[11994], 50.00th=[12911], 60.00th=[13960],
     | 70.00th=[15008], 80.00th=[16319], 90.00th=[17957], 95.00th=[19530],
     | 99.00th=[22938], 99.50th=[24511], 99.90th=[26608], 99.95th=[27132],
     | 99.99th=[28181]
   bw (  KiB/s): min=  258, max=  307, per=99.89%, avg=282.11, stdev=12.19, samples=36
   iops        : min=  516, max=  614, avg=564.22, stdev=24.39, samples=36
  lat (usec)   : 250=0.01%, 500=0.01%
  lat (msec)   : 2=0.04%, 4=0.19%, 10=19.14%, 20=76.23%, 50=4.40%
  cpu          : usr=1.00%, sys=2.25%, ctx=15288, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=10258,10222,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=283KiB/s (290kB/s), 283KiB/s-283KiB/s (290kB/s-290kB/s), io=5129KiB (5252kB), run=18105-18105msec
  WRITE: bw=282KiB/s (289kB/s), 282KiB/s-282KiB/s (289kB/s-289kB/s), io=5111KiB (5234kB), run=18105-18105msec

Disk stats (read/write):
  sda: ios=10140/10183, merge=0/17, ticks=4311/16817, in_queue=21162, util=99.54%

Code: 
fio --direct=1 --ioengine=libaio --rw=read --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=read, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process

test: (groupid=0, jobs=1): err= 0: pid=60075: Thu Oct 12 14:36:07 2023
  read: IOPS=35.1k, BW=17.2MiB/s (18.0MB/s)(10.0MiB/583msec)
    slat (nsec): min=4371, max=71905, avg=10044.24, stdev=4324.98
    clat (usec): min=204, max=1349, avg=443.89, stdev=113.04
     lat (usec): min=212, max=1361, avg=453.94, stdev=112.07
    clat percentiles (usec):
     |  1.00th=[  273],  5.00th=[  306], 10.00th=[  326], 20.00th=[  359],
     | 30.00th=[  379], 40.00th=[  404], 50.00th=[  424], 60.00th=[  445],
     | 70.00th=[  469], 80.00th=[  506], 90.00th=[  603], 95.00th=[  685],
     | 99.00th=[  799], 99.50th=[  840], 99.90th=[ 1090], 99.95th=[ 1237],
     | 99.99th=[ 1303]
   bw (  KiB/s): min=17113, max=17113, per=97.43%, avg=17113.00, stdev= 0.00, samples=1
   iops        : min=34226, max=34226, avg=34226.00, stdev= 0.00, samples=1
  lat (usec)   : 250=0.26%, 500=78.17%, 750=19.55%, 1000=1.88%
  lat (msec)   : 2=0.14%
  cpu          : usr=14.95%, sys=42.10%, ctx=4918, majf=0, minf=12
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=20480,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=17.2MiB/s (18.0MB/s), 17.2MiB/s-17.2MiB/s (18.0MB/s-18.0MB/s), io=10.0MiB (10.5MB), run=583-583msec

Disk stats (read/write):
  sda: ios=12898/0, merge=0/0, ticks=5856/0, in_queue=5857, util=80.49%
Code: 
fio --direct=1 --ioengine=libaio --rw=write --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
test: (g=0): rw=write, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=112KiB/s][w=224 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=60079: Thu Oct 12 14:37:38 2023
  write: IOPS=501, BW=251KiB/s (257kB/s)(10.0MiB/40817msec); 0 zone resets
    slat (usec): min=576, max=73962, avg=1988.07, stdev=7399.09
    clat (usec): min=6, max=113536, avg=29891.29, stdev=32816.26
     lat (usec): min=1881, max=115756, avg=31879.36, stdev=34158.67
    clat percentiles (msec):
     |  1.00th=[   10],  5.00th=[   11], 10.00th=[   11], 20.00th=[   11],
     | 30.00th=[   12], 40.00th=[   12], 50.00th=[   12], 60.00th=[   14],
     | 70.00th=[   30], 80.00th=[   34], 90.00th=[  103], 95.00th=[  105],
     | 99.00th=[  108], 99.50th=[  109], 99.90th=[  111], 99.95th=[  112],
     | 99.99th=[  113]
   bw (  KiB/s): min=   96, max=  695, per=100.00%, avg=251.83, stdev=233.92, samples=81
   iops        : min=  192, max= 1390, avg=503.65, stdev=467.84, samples=81
  lat (usec)   : 10=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=2.45%, 20=62.02%, 50=19.63%
  lat (msec)   : 100=1.35%, 250=14.54%
  cpu          : usr=0.46%, sys=1.15%, ctx=20481, majf=0, minf=12
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,20480,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=251KiB/s (257kB/s), 251KiB/s-251KiB/s (257kB/s-257kB/s), io=10.0MiB (10.5MB), run=40817-40817msec

Disk stats (read/write):
  sda: ios=0/20591, merge=0/32, ticks=0/44657, in_queue=44666, util=99.52%
 
Hey,

wenn Ceph / rados bench "o.k." ist und die Leistung in der VM nicht o.k. ist, dann ist auch die Anbindung der VM hier zu betrachten. Welchen Controller benutzt die virtuelle Disk, welche Cache Einstellungen, sowas.
 
Falk R. said:
Du hast recht wenige PGs, ich hätte mindestens 64 oder 128 genommen.
Click to expand...
Dies. Evtl. den Autoscaler für die Pools mal nur auf "warn" setzen. Wenn das ganze Produktiv gehen sollte, ist es gut dem Autoscaler zu sagen, wie sich die Pools circa verhalten werden was den Platzverbrauch angeht (target_ratio). Damit kann er dann die pg_num der Pools entsprechend ausrechnen, dass am Ende jede OSD circa 100 PGs hat. Zu wenig PGs kann sich deutlich auf die Performance auswirken, weil dann die Last auch nicht gut verteilt werden kann.

Ich bin mir auch nicht sicher, wie realitätsnah die 512B Benchmarks sind. RBD verwendet default 4 MiB Objekte. Um den Effekt von vielen kleinen Schreiboperationen abzufangen, ist es auch hilfreich für die VM Disks den Writeback Cache zu verwenden.
 
Wenn du niedrige Latenzen haben willst, solltest du lieber mind. 25GBit Netzwerk benutzen.
Da du kleine Blöcke auf große Objekte (wie aaron schon schrieb 4MB) schreibst, hast du einen großen Overhead. Bei SQL machst du ja eh normalerweise 64k. Mit schnellen NVMe die bis zu 1Mio Schreib-I/Os machen, fällt der Overhead dann nicht mehr so ins Gewicht.

Ich baue auch alle kleinen Cluster (unter 20k€) mit 100GBit NICs und Enterprise NVMe, da habe ich bei allen Benchmarks deutlich bessere Werte.
 
Hallo zusammen,

ich bedanke mich für die Rückmeldungen. Wir werden jetzt als ersten Schritt die Nodes mit 100Gbits anbinden. Die niedrigere Anzahl an PGs sind dem Autoscaler geschuldet, der diese nach dem Zusammenbau des Pools (Korrektur) nach und nach reduziert hat, bis der jetzige Wert erreicht war.

Viele Grüße
Stefan
 
Last edited:
Ich kann das auch öffentlich schreiben.
Am liebsten arbeite ich derzeit mit AMD Systemen (mehr Takt und bessere Performance bei Virtualisierung).
Vom Preis/Leistung Verhältnis gehen derzeit gut ASUS Server. Da konfiguriere ich nur CPU, RAM, NICs und Disks. Oft kommt das ganze mit guten Preisen von PrimeLine Solutions und ich nehme auch immer gleich 5 Jahre Support.
Für die kleinen Cluster MikroTik Switches und große gern mit den Datacenter Switches von FS.com

Du hast noch etwas von Filesystem geschrieben, ich hoffe du legst keine VMs auf CephFS.
 
P.S. bei den NVMe habe ich in letzter Zeit nur noch Kioxia genommen und nach 2 Jahren eine defekte NVMe bei über 100 verbauten.
 
verzeiht, dass ich diesen Thread nochmal nach oben hole. Da wir in den kommenden Monaten unter Umständen die Hardware unseres PVE/Ceph-Clusters erneuern werden, interessiert mich das Thema grundsätzlich. @Stefan_Malte_Schumacher, magst Du schreiben, wie die Geschichte weiterging?
Und so ins Blaue rein: Ist die relativ geringe Single Thread Performance der CPUs vielleicht ein Problem?
 
Last edited:
  • Like
Reactions: Stefan_Malte_Schumacher
Hi, ja schlechte Single Thread Performance ist schlecht wenn du Gute Performance auf einer vDisk brauchst. Wenn du gut verteilten Workload hast, ist das nicht ganz so dramatisch. Der typische Mittelständler hat das in der Regel nicht. Da gibts auch virtuelle DB Server, die auch mal richtig Gas geben. Daher nehme ich bei neuen Systemen gern AMD Epyc mit relativ hohem hohen Taktraten.
 
  • Like
Reactions: sherminator
Falk R. said:
Hi, ja schlechte Single Thread Performance ist schlecht wenn du Gute Performance auf einer vDisk brauchst. Wenn du gut verteilten Workload hast, ist das nicht ganz so dramatisch. Der typische Mittelständler hat das in der Regel nicht. Da gibts auch virtuelle DB Server, die auch mal richtig Gas geben. Daher nehme ich bei neuen Systemen gern AMD Epyc mit relativ hohem hohen Taktraten.
Click to expand...
Danke für dein Feedback! Ich glaube mittlerweile auch ganz stark, dass die CPU-Taktrate der meistunterschätzte Hebel in solchen Umgebungen ist. Falls wir dieses Jahr erneuern, werde ich das auf jeden Fall berücksichtigen. Dank AMD kann man mittlerweile ja sowohl hohe Taktraten, als auch viele Kerne in einer CPU bekommen.
 
Bei anderen Storagevirtualisierungen ist das sogar Sizingempfehlung, damit vernünftig was raus kommt. Wenn ich Ceph mit HDDs für Backup oder Archiv baue, ist das zu vernachlässigen. Bei VMs gibts nur noch 3+GHz und NVMe. Bitte auch das Netzwerk nicht vernachlässigen, lieber 25/100G statt 40G. Durch die höheren Frequenzen hast du niedrigere Latenzen.
 
  • Like
Reactions: sherminator
sherminator said:
verzeiht, dass ich diesen Thread nochmal nach oben hole. Da wir in den kommenden Monaten unter Umständen die Hardware unseres PVE/Ceph-Clusters erneuern werden, interessiert mich das Thema grundsätzlich. @Stefan_Malte_Schumacher, magst Du schreiben, wie die Geschichte weiterging?
Und so ins Blaue rein: Ist die relativ geringe Single Thread Performance der CPUs vielleicht ein Problem?
Click to expand...

Hallo Sherminator. Die Performance, die ich mit dem erreicht haben, was ich als "Commodity Hardware" bezeichnen würde - schließlich soll es darauf laufen - hat gegen die getesteten Alternativen haushoch verloren. Ich hätte wirklich gerne die die Features von Ceph was Datenintegrität und Ausfallsicherheit betrifft gehabt, aber mit den Werten konnte ich meine Kollegen nicht überzeugen. Wir bleiben jetzt weiter bei Proxmox-Clustern bei einer Kombination von zwei RAID10-Pools, einen mit SAS-Platten und einen mit SATA-SSDs. Wenn einer unserer Kunden explizit nach Hochverfügbarkeit fragt würden wir ihm ein iSCSI-Lösung über das das Dell/EMC-SAN anbieten. Ich finde Ceph weiterhin interessant und werde. Ich werde Ceph auf jeden Fall nochmal testen - und gerne auch hier darüber berichten - wenn wir neue, leistungsstärkere Hardware, d.h. vor allem 100Gbit-Netzwerk und U2-NVMEs angeschafft haben.

Viele Grüße
Stefan
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom