IO Performance auf VMs auf Ceph ist extrem schlecht

Ich glaube, dass man den CEPH Cluster mit ein paar Handgriffen durchaus optimieren kann:
  1. Ordentliche Enterprise Switches mit LACP, MLAG und geringer Latenz (z.B. Arista Switches oder Juniper QFX5100) und mind. 10 GbE Interfaces
  2. Jumboframes auf dem Switch und den Nodes aktivieren
  3. LACP auf L3+4 (alles andere ist für CEPH nicht cool)
  4. Nur Enterprise SSDs / NVMes verwenden (keine Consumer oder "Prosumer")
  5. BIOS Power Einstellungen auf Performance und Turbo rein (alles was die Hardware drosselt ist schlecht)
  6. PGs erhöhen, die 32 sind deutlich zu wenig, eher 128 - 256 PGs pro Pool
  7. FIO Befehl anpassen (siehe z. B. den unten verlinkten Blog Artikel [0])
  8. VM Config auf CEPH optimieren (am besten mal die Config hier posten qm config VMID)

Weitere Hinweise:
Die Micron MTFDDAK7T6TDS macht lt. Datenblatt nur 11k IOPS bei 4k Schreiben, die PM883 macht aber schon 28k. Wenn möglich empfehle ich mind. auf PM883 umzustellen.
Es fehlen auch noch ein paar genauere Details zu der Hardware, ich vermisse z.B. die Info ob und welcher HBA genutzt wird.

Vielleicht liest du dir auch mal den folgenden Beitrag durch, da bekommst du vielleicht hier und da neue Ansätze und Ideen: [0] https://croit.io/blog/ceph-performance-test-and-optimization

@Stefan_Malte_Schumacher vielleicht kannst du ja mal auf meine Punkten oben eingehen ob dies bereits durchgeführt wurde oder nicht. Deine Benchmarkwerte sind aus meiner Sicht so auf jeden Fall weit unter dem, was du von CEPH bekommen und erwarten können solltest.
 
Also die PM883 nutze ich gern für Backups aber ist mir für Ceph schon zu langsam. Das SATA Interface limitiert schon stark.
Außerdem ist 10GBit schon das untere Limit für den Einstieg. Produktiv mache ich nichts mehr unter 25GBit und meistens 100GBit.
Auch das ist nicht teuer. Meine 3 Node Cluster bekommen 2x 4 Port 100G Switches für je 800€ und mit DAC Kabel hat man für 2k ein redundantes und performantes Ceph Netzwerk. Mit Enterprise NVMe kommt richtig was raus und ein DELL Storage ist dann deutlich teurer und weniger flexibel/redundant.
 
@Falk R. Kann ich so nicht bestätigen. Kenne ausreichend Cluster die nur mit SATA SSDs und 2x 10 G arbeiten. Dauerbelastung mit 100k IOPS gar kein Problem (ja ist halt kein 5 Node Cluster mehr).
Auch ein Cluster mit 4x 1 GbE, 5 Nodes und paar SSDs läuft sehr stabil. Es ist nicht so, dass das nicht nutzbar wäre, es ist aber halt auch kein High Performance Cluster. Wenn man dabei noch ehrlich ist, dann ist man bei CEPH eh falsch wenn man höchste Performance will, dafür ist CEPH ja auch in erster Linie gar nicht gedacht.

Insofern kann ich aus Erfahrung heraus und ruhigen Gewissens auch 10G und SATA SSDs für den produktiven Einsatz empfehlen. Ich selbst würde damit auch jederzeit Cluster aufbauen, da es auch für normales vermieten von VMs mehr als ausreichend ist, da braucht man keine teuren NVMe die eh kein Endverbraucher zahlen will.
Besser und schneller geht immer, am besten direkt nen CEPH mit ScaleFlux aufbauen und 800 G Switches, dann fliegen die IOPS nur so :)
Aber man kann eben auch für den Anwendungsfall einfach den Storage passend skalieren.
 
Für ein paar Homeuser , VMs hosten, macht ja nicht viel Traffic und da guckt auch keiner auf Latenzen.
Ich betreue Mittelständische Unternehmen, da gibt es in jeder Umgebung mindestens eine VM die viel I/O produziert oder zumindest sehr Latenzempfindlich ist. Klar funktioniert das auch mit 10 GBit, aber das würde ich nicht für eine Neuinstallation nutzen, da die ja mindestens 5 Jahre halten soll und du für minimalen Aufpreis mit 25 GBit wesentlich weniger Latenzen hast.

Für deinen Anwendungsfall ist ja 10 GBit OK und du baust da bestimmt auch schneller mal aus oder um. Hier lesen auch Leute mit, die bei Dienstleistern arbeiten. Die sollen ja bei ihren Benchmarks für ihre Kunden was vernünftiges raus bekommen, sonst kommt so eine Meinung wie bei @Stefan_Malte_Schumacher raus, dass ein klassisches Storage eine bessere Lösung ist.
 
Also wir hosten nicht nur für ein paar Homeuser und die Latenz ist auch nicht egal. Wir hosten teils mehrere VMs von mittelständischen Unternehmen mit verschiedenen Anwendungsfällen, es gibt auch Kunden die Trading über uns betreiben oder Windows VMs nutzen. Keiner hat sich jemals über Latenz oder Performance beschwert.

Wir bauen die Infrastruktur so um und aus, wie es wirtschaftlich und nötig ist. Der Mittelstand haut auch keine 3 Mio für 100k IOPS raus wenn es nicht benötigt wird.
Ich schäme mich auch definitiv nicht Managed Kunden ein CEPH auf 10G und SSD anzubieten, denn wir haben das Augenmaß zwischen Kosten / Nutzen nicht verloren. Die wenigsten wissen einfach wie viele IOPS sie tatsächlich benötigen. Da steht der Dienstleister in der Pflicht eine solche Auswertung für den Kunden zu machen und nicht einfach nen Storage mit 100k IOPS hinzuknallen.
Einer meiner letzten Benchmakrs auf so einem Cluster (SATA SSD und 10G) brachte rund 16k IOPS schreibend und rund 50k IOPS lesend. Die Latenz liegt da bei 2 - 3ms. Der Cluster hat nicht mal 10k gekostet, das war vor 2 - 3 Jahren mit deutlich höheren Preisen. Vielleicht kannst du hier ja mal einwerfen wie vielen deiner Kunden diese Leistung potenziell ausreichen würde? Würde mich durchaus auch interessieren.

Wir betreiben das Zeug aber eben auch im Rechenzentrum unter dem Aspekt hoher Verfügbarkeit und hoher dichte. Da bekomme ich für 2k EUR definitiv kein MLAG aus 2x 100 G Switches, dass ich mit 25 G arbeiten könnte. Alleine für solche Switche kann ich sicherlich 10k einplanen. Für 10 G oder 40 G zahle ich nicht mal 1k. Ja, wir reden nicht von neuen Geräten.
 
Im RZ, würde ich das auch differenzierter betrachten, weil da auch viel mehr Dynamik dahinter steckt.
Beim Mittelständler size ich die aktuellen Anforderungen (da reichen sicherlich oft 10GBit) mit einem geplanten Wachstum. In 5 Jahren würden einige deutlich über dem 10 GBit Limit liegen, außerdem soll die Umgebung nicht am Limit arbeiten. Als ich letztens einen defekten Server tauschen musste und das Ceph innerhalb von 1,5 Stunden die kompletten Daten gesynct hat (3 Node) ohne das ein User etwas gemerkt hat, war der Kunde sehr glücklich.
Der Cluster hat mit 25GBit LAN und 100GBit Ceph auch nur 32k gekostet und nur die Hardware des Gegenangebot HyperV Cluster lag bei 50k. Da fragt der Kunde nicht ob das eventuell für 25k gegangen wäre. Ja das hätte man machen können, aber halt von Anfang an am Limit.
 
Cool, gute Arbeit sage ich da mal!

Ja, das sind auch keine wirklich hohen Kosten, so dass es hierbei sicherlich gerechtfertigt ist.
Kannst / magst du mal aufführen, was du da so an Hardware verbaut hast?
 
sb-jw said:
Ja, das sind auch keine wirklich hohen Kosten, so dass es hierbei sicherlich gerechtfertigt ist.
Kannst / magst du mal aufführen, was du da so an Hardware verbaut hast?
Click to expand...
Server sind ASUS mit AMD Epyc, die lasse ich mir passend von primeLine Solutions bauen.
Dort sind Broadcom NICs drin und Kioxia NVMe's.

Die Switches für Ceph sind Mikrotik CRS504 und für das LAN habe ich Switches von FS.com, bei dem Kunden die s5860-20sq.
Alles soweit möglich mit DAC Kabeln, das spart auch einige €.

Bei gößeren Clustern nutze ich für Ceph dann gern die fs.com S5850er Switches, oft die 24x oder 48x 25G und manchmal 32x 100G.
 
sb-jw said:
Einer meiner letzten Benchmakrs auf so einem Cluster (SATA SSD und 10G) brachte rund 16k IOPS schreibend und rund 50k IOPS lesend. Die Latenz liegt da bei 2 - 3ms.
Click to expand...
Wie habt ihr die IOPS gemessen, falls du das noch weißt?
 
wow, vielen Dank für Eure sehr wertvollen insights zu diesem Thema. Ich hoffe, @Stefan_Malte_Schumacher hat nichts dagegen, dass wir seinen Thread... erweitern. :)

aaron said:
Wie habt ihr die IOPS gemessen, falls du das noch weißt?
Click to expand...
Hier würde ich auch gerne einhaken. Stefans ursprüngliches Problem war ja, dass er in einer Linux-VM mit
Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
gemessen und schlappe 400 IOPS rausgekriegt hat. Da sich das in unserer Infrastruktur, die hardwareseitig durchaus gut aufgestellt ist, auch so darstellt, bin ich interessiert, ob wir da Chancen auf signifikante Verbesserung haben. Wegen 5 oder 10% Performance-Gewinn würde ich keinen großen Aufwand betreiben, aber wenn mir jemand sagt, dass mit ein paar Tricks Faktor 10 oder mehr drin ist, würde ich's gerne versuchen.
 
@aaron habe ich nicht mehr genau im Kopf, aber eine VM ist ja schnell deployed und ein fio auch schnell gemacht. Anbei meine Ergebnisse:

Code: 
root@deployvm:~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
benchmark: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
benchmark: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=159MiB/s,w=53.0MiB/s][r=40.8k,w=13.6k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1363: Tue Jan  9 16:17:09 2024
  read: IOPS=39.4k, BW=154MiB/s (161MB/s)(3070MiB/19943msec)
   bw (  KiB/s): min=145344, max=168432, per=100.00%, avg=158944.41, stdev=4816.53, samples=39
   iops        : min=36336, max=42108, avg=39736.00, stdev=1204.17, samples=39
  write: IOPS=13.2k, BW=51.4MiB/s (53.9MB/s)(1026MiB/19943msec); 0 zone resets
   bw (  KiB/s): min=48744, max=56528, per=100.00%, avg=53129.44, stdev=1596.11, samples=39
   iops        : min=12186, max=14132, avg=13282.36, stdev=399.03, samples=39
  cpu          : usr=17.72%, sys=47.96%, ctx=170623, majf=0, minf=17
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=154MiB/s (161MB/s), 154MiB/s-154MiB/s (161MB/s-161MB/s), io=3070MiB (3219MB), run=19943-19943msec
  WRITE: bw=51.4MiB/s (53.9MB/s), 51.4MiB/s-51.4MiB/s (53.9MB/s-53.9MB/s), io=1026MiB (1076MB), run=19943-19943msec

Disk stats (read/write):
  sda: ios=782934/261767, merge=0/18, ticks=1046688/89232, in_queue=1136006, util=99.65%

Code: 
root@deployvm:~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randread
benchmark: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [r(1)][100.0%][r=215MiB/s][r=54.9k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1370: Tue Jan  9 16:17:32 2024
  read: IOPS=68.8k, BW=269MiB/s (282MB/s)(4096MiB/15250msec)
   bw (  KiB/s): min=179352, max=303640, per=100.00%, avg=276570.93, stdev=25611.80, samples=30
   iops        : min=44838, max=75910, avg=69142.67, stdev=6402.93, samples=30
  cpu          : usr=23.60%, sys=56.74%, ctx=58838, majf=0, minf=81
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=1048576,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=269MiB/s (282MB/s), 269MiB/s-269MiB/s (282MB/s-282MB/s), io=4096MiB (4295MB), run=15250-15250msec

Disk stats (read/write):
  sda: ios=1042902/36, merge=0/7, ticks=853403/29, in_queue=853441, util=99.47%

Code: 
root@deployvm:~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
benchmark: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=84.4MiB/s][w=21.6k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1373: Tue Jan  9 16:18:35 2024
  write: IOPS=17.6k, BW=68.9MiB/s (72.3MB/s)(4096MiB/59410msec); 0 zone resets
   bw (  KiB/s): min=48992, max=117416, per=99.94%, avg=70557.22, stdev=12547.35, samples=118
   iops        : min=12248, max=29354, avg=17639.34, stdev=3136.83, samples=118
  cpu          : usr=5.25%, sys=12.99%, ctx=220727, majf=0, minf=17
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=0,1048576,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
  WRITE: bw=68.9MiB/s (72.3MB/s), 68.9MiB/s-68.9MiB/s (72.3MB/s-72.3MB/s), io=4096MiB (4295MB), run=59410-59410msec

Disk stats (read/write):
  sda: ios=0/1047972, merge=0/23, ticks=0/3602293, in_queue=3610638, util=99.95%
 
@sherminator ich habe es auch direkt mal mit ausgeführt und auch noch zum Vergleich einen mit 4k Blocksize gemacht.

BS = 512B
Code: 
root@deployvm:~# 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=741KiB/s,w=720KiB/s][r=1483,w=1440 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=1385: Tue Jan  9 16:22:11 2024
  read: IOPS=1413, BW=707KiB/s (724kB/s)(5129KiB/7256msec)
    slat (nsec): min=3697, max=75202, avg=9078.70, stdev=5113.99
    clat (usec): min=528, max=26311, avg=5608.54, stdev=2010.54
     lat (usec): min=541, max=26316, avg=5617.62, stdev=2010.64
    clat percentiles (usec):
     |  1.00th=[ 2180],  5.00th=[ 3163], 10.00th=[ 3589], 20.00th=[ 4146],
     | 30.00th=[ 4621], 40.00th=[ 4948], 50.00th=[ 5276], 60.00th=[ 5669],
     | 70.00th=[ 6128], 80.00th=[ 6652], 90.00th=[ 7767], 95.00th=[ 9372],
     | 99.00th=[12256], 99.50th=[13435], 99.90th=[19268], 99.95th=[24773],
     | 99.99th=[26346]
   bw (  KiB/s): min=  658, max=  760, per=100.00%, avg=710.36, stdev=32.00, samples=14
   iops        : min= 1316, max= 1520, avg=1420.71, stdev=63.99, samples=14
  write: IOPS=1408, BW=704KiB/s (721kB/s)(5111KiB/7256msec); 0 zone resets
    slat (usec): min=71, max=15056, avg=693.58, stdev=870.96
    clat (usec): min=255, max=24769, avg=5017.69, stdev=1784.54
     lat (usec): min=387, max=26750, avg=5711.27, stdev=1943.07
    clat percentiles (usec):
     |  1.00th=[ 1844],  5.00th=[ 2769], 10.00th=[ 3294], 20.00th=[ 3720],
     | 30.00th=[ 4047], 40.00th=[ 4424], 50.00th=[ 4752], 60.00th=[ 5080],
     | 70.00th=[ 5473], 80.00th=[ 5997], 90.00th=[ 7046], 95.00th=[ 8455],
     | 99.00th=[10945], 99.50th=[11994], 99.90th=[16712], 99.95th=[16909],
     | 99.99th=[24511]
   bw (  KiB/s): min=  684, max=  747, per=100.00%, avg=709.50, stdev=18.22, samples=14
   iops        : min= 1368, max= 1494, avg=1419.00, stdev=36.43, samples=14
  lat (usec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=1.01%, 4=22.04%, 10=73.89%, 20=2.97%, 50=0.05%
  cpu          : usr=1.24%, sys=4.65%, ctx=15290, 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=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=707KiB/s (724kB/s), 707KiB/s-707KiB/s (724kB/s-724kB/s), io=5129KiB (5252kB), run=7256-7256msec
  WRITE: bw=704KiB/s (721kB/s), 704KiB/s-704KiB/s (721kB/s-721kB/s), io=5111KiB (5234kB), run=7256-7256msec

Disk stats (read/write):
  sda: ios=10095/10094, merge=0/10, ticks=10350/931, in_queue=11293, util=98.76%

BS = 4k
Code: 
root@deployvm:~# fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=10mb --direct=1 --bs=4k --iodepth=16
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process

test: (groupid=0, jobs=1): err= 0: pid=1389: Tue Jan  9 16:22:20 2024
  read: IOPS=3626, BW=14.2MiB/s (14.9MB/s)(5048KiB/348msec)
    slat (nsec): min=3424, max=47987, avg=9598.96, stdev=5277.56
    clat (usec): min=262, max=12673, avg=4259.57, stdev=2725.10
     lat (usec): min=275, max=12677, avg=4269.17, stdev=2724.98
    clat percentiles (usec):
     |  1.00th=[  359],  5.00th=[ 1012], 10.00th=[ 1385], 20.00th=[ 1811],
     | 30.00th=[ 2311], 40.00th=[ 2900], 50.00th=[ 3589], 60.00th=[ 4424],
     | 70.00th=[ 5211], 80.00th=[ 6652], 90.00th=[ 8455], 95.00th=[ 9634],
     | 99.00th=[11469], 99.50th=[12387], 99.90th=[12649], 99.95th=[12649],
     | 99.99th=[12649]
  write: IOPS=3729, BW=14.6MiB/s (15.3MB/s)(5192KiB/348msec); 0 zone resets
    slat (nsec): min=3666, max=40858, avg=9979.14, stdev=5285.81
    clat (usec): min=46, max=3559, avg=116.64, stdev=116.29
     lat (usec): min=52, max=3579, avg=126.62, stdev=116.42
    clat percentiles (usec):
     |  1.00th=[   61],  5.00th=[   74], 10.00th=[   78], 20.00th=[   83],
     | 30.00th=[   88], 40.00th=[   93], 50.00th=[  100], 60.00th=[  110],
     | 70.00th=[  118], 80.00th=[  133], 90.00th=[  157], 95.00th=[  178],
     | 99.00th=[  498], 99.50th=[  668], 99.90th=[  865], 99.95th=[ 3556],
     | 99.99th=[ 3556]
  lat (usec)   : 50=0.12%, 100=25.08%, 250=24.65%, 500=1.13%, 750=1.05%
  lat (usec)   : 1000=1.09%
  lat (msec)   : 2=8.91%, 4=15.98%, 10=20.08%, 20=1.91%
  cpu          : usr=3.17%, sys=8.36%, ctx=1519, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.3%, 16=99.4%, 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=1262,1298,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=14.2MiB/s (14.9MB/s), 14.2MiB/s-14.2MiB/s (14.9MB/s-14.9MB/s), io=5048KiB (5169kB), run=348-348msec
  WRITE: bw=14.6MiB/s (15.3MB/s), 14.6MiB/s-14.6MiB/s (15.3MB/s-15.3MB/s), io=5192KiB (5317kB), run=348-348msec

Disk stats (read/write):
  sda: ios=546/607, merge=0/0, ticks=2066/67, in_queue=2134, util=59.02%

Und noch eines auf BS = 4k und mit 4G Test-Datei anstelle von 10 MB:
Code: 
root@deployvm:~# fio --direct=1 --ioengine=libaio --rw=randrw --name=benchmark --filename=benchmark --size=4G --direct=1 --bs=4k --iodepth=16
benchmark: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=30.7MiB/s,w=31.3MiB/s][r=7863,w=8010 IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1405: Tue Jan  9 16:26:51 2024
  read: IOPS=11.1k, BW=43.4MiB/s (45.5MB/s)(2049MiB/47269msec)
    slat (usec): min=3, max=1651, avg=11.54, stdev= 8.06
    clat (usec): min=227, max=217648, avg=1243.55, stdev=2802.07
     lat (usec): min=242, max=217653, avg=1255.09, stdev=2802.06
    clat percentiles (usec):
     |  1.00th=[   457],  5.00th=[   506], 10.00th=[   529], 20.00th=[   570],
     | 30.00th=[   603], 40.00th=[   627], 50.00th=[   660], 60.00th=[   701],
     | 70.00th=[   758], 80.00th=[   898], 90.00th=[  1696], 95.00th=[  4752],
     | 99.00th=[ 11338], 99.50th=[ 14353], 99.90th=[ 22152], 99.95th=[ 27395],
     | 99.99th=[132645]
   bw (  KiB/s): min=24160, max=49768, per=100.00%, avg=44574.64, stdev=4710.84, samples=94
   iops        : min= 6040, max=12442, avg=11143.66, stdev=1177.74, samples=94
  write: IOPS=11.1k, BW=43.3MiB/s (45.4MB/s)(2047MiB/47269msec); 0 zone resets
    slat (usec): min=3, max=351, avg=12.21, stdev= 7.90
    clat (usec): min=5, max=9785, avg=170.49, stdev=58.45
     lat (usec): min=47, max=9790, avg=182.71, stdev=58.97
    clat percentiles (usec):
     |  1.00th=[   82],  5.00th=[   99], 10.00th=[  111], 20.00th=[  127],
     | 30.00th=[  139], 40.00th=[  151], 50.00th=[  163], 60.00th=[  178],
     | 70.00th=[  192], 80.00th=[  210], 90.00th=[  237], 95.00th=[  265],
     | 99.00th=[  326], 99.50th=[  359], 99.90th=[  469], 99.95th=[  553],
     | 99.99th=[  898]
   bw (  KiB/s): min=24992, max=49408, per=100.00%, avg=44518.38, stdev=4687.42, samples=94
   iops        : min= 6248, max=12352, avg=11129.60, stdev=1171.86, samples=94
  lat (usec)   : 10=0.01%, 50=0.01%, 100=2.66%, 250=43.73%, 500=5.71%
  lat (usec)   : 750=32.24%, 1000=7.11%
  lat (msec)   : 2=4.05%, 4=1.56%, 10=2.20%, 20=0.64%, 50=0.06%
  lat (msec)   : 100=0.01%, 250=0.01%
  cpu          : usr=10.91%, sys=28.89%, ctx=480876, majf=0, minf=75
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=524625,523951,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=43.4MiB/s (45.5MB/s), 43.4MiB/s-43.4MiB/s (45.5MB/s-45.5MB/s), io=2049MiB (2149MB), run=47269-47269msec
  WRITE: bw=43.3MiB/s (45.4MB/s), 43.3MiB/s-43.3MiB/s (45.4MB/s-45.4MB/s), io=2047MiB (2146MB), run=47269-47269msec

Disk stats (read/write):
  sda: ios=524143/523683, merge=0/39, ticks=639015/70546, in_queue=710001, util=99.89%
 
@sb-jw danke für die Benchmarks! Ich komme bei den meisten ungefähr bei der Hälfte Deiner Ergebnisse raus. Ich würde jetzt mal faul annehmen, dass das Hardware-Unterschiede sind und grundsätzlich passt. Und ich muss ehrlich sagen, dass ich nicht wirklich eine Ahnung habe, was wir nun genau gemessen haben, weil ich die fio-Optionen zum Teil nicht kenne/verstehe.

@Stefan_Malte_Schumacher Dein Benchmarkt mit den ca. 400 IOPS - was war da ungefähr Deine Erwartung, bzw. was liefert dieser Benchmark auf dem Storage-Backend, für das ihr Euch entschieden habt?
 
sherminator said:
Ich würde jetzt mal faul annehmen, dass das Hardware-Unterschiede sind und grundsätzlich passt.
Click to expand...
Ich beschreibe mal kurz das Setup, dann kannst du es womöglich auch besser bewerten.

Server:
5x Dell PowerEdge R630:
- 2x Intel Xeon E5-2620 v4
- 256 GB DDR4-2133 ECC
- HBA330
- 6x Samsung PM863a oder PM883 immer mit 960 GB
- 2x 10GBASE-T im LACP mit L3+4 Hashing und Jumboframes (Dell NDC 2P X540/2P I350 z.B. 99GTM)
- 2x 750W PSU

Die Server sind alle im Performance Modus konfiguriert, die CPUs laufen in der Regel mit 2,3 GHz und nicht mit 2,1 GHz. Der Turbo kann genutzt werden, wurde er aber beim Benchmark nicht.

Netzwerk:
Als Switches kommen 2 Arista DCS-7050T-52-R im MLAG zum Einsatz. Der MLAG ist mit 2x 10 GbE DAC Kabel realisiert und die Server mit jeweils 2x CAT 5e 1,5m Kabel angeschlossen.

CEPH:
Der CEPH verfügt über 30 OSDs, darauf läuft noch ein CephFS (jeweils 32 PGs), ein größerer Pool mit 1024 PGs, ein kleinerer mit 256 PGs und der .mgr mit 1 PG. Gesamt daher 1345 PGs auf dem Cluster verteilt in 5 Pools. Alle Pools sind mit Replicated 3/2 erstellt.

Es sind also 5 Storage Nodes als HCI Setup und auf 1-3 läuft der Mon bzw. MDS Service. Die OSDs haben ein Memory Target von 6 GB bekommen.
 
Hier unsere Umgebung:

3x SuperMicro Thomas Krenn "2HE AMD Dual-CPU RA2224 Server"
- 2x AMD EPYC 7351
- 512 GB DDR4 2666 ECC RAM
- Broadcom HBA 9300-8i
- 10x Samsung SM883 1,92 TB
- Broadcom P425G

Das Ceph-Netzwerk ist ein Full Mesh über die genannten 25G-Netzwerkkarten.
Der Pool, um den es geht, beinhaltet alle 30 SSDs, hat ca. 18 TB nutzbaren Speicher und 1024 PGs.
Grundsätzlich ist das ganze Ding recht nah an einer PVE/Ceph-Standardinstallation.

Im BIOS der Server habe ich bislang keine Konfigurationsänderungen vorgenommen, lediglich ein paar Mal die Firmware aktualisiert.
 
sherminator said:
Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=10mb --direct=1 --bs=512B  -iodepth=16
gemessen und schlappe 400 IOPS rausgekriegt
Click to expand...
Ich habe mal etwas getestet, wenn ich eine kleine VM mit 2 vCPUs nehme, bekomme ich immer die gleichen ergebnisse, egal ob auf meiner Bastelumgebung mit billig Consumer SSDs oder Enterprise NVMe. Bei mir sind es keine 400 I/Os aber immer um die 1270 I/Os.
Also wenn ich Performance aus einer VM bekommen will, sollte man den Test nicht auf der OS Disk machen, mind. 8 vCPUs typ host und ein klein wenig RAM geben.

Ich habe mal einen Test mit ner kleinen 8Core VM gemacht. Gerade Write bricht bei kleinen IOs extrem ein: bei 4k habe ich noch knapp 20k und bei 512B nur noch 8k IO.
Bei 1MB Blöcken war bei mir bei 1,4GB/s Schluss, da ist das keine Limitierung der IOs mehr sondern Bandbreite.
 
Falk R. said:
Also wenn ich Performance aus einer VM bekommen will, sollte man den Test nicht auf der OS Disk machen, mind. 8 vCPUs typ host und ein klein wenig RAM geben.
Click to expand...
Das kann ich für unsere Umgebung nicht bestätigen. Egal ob die VM 1GB RAM und 2 vCPUs hat, oder 16 GB RAM und 8 vCPUs, die Werte für
Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=1G --direct=1 --bs=4K  -iodepth=16
sind die gleichen, ungefähr 5000 IOPS.
Übrigens, damit das nicht falsch rüberkommt: Wir sind nicht unzufrieden mit unseren aktuellen Werten. Ich möchte lediglich in Hinblick auf Hardware-Neuanschaffungen verstehen, was in Sachen Ceph-Performance die wichtigen Stellschrauben sind.
 
sherminator said:
Das kann ich für unsere Umgebung nicht bestätigen. Egal ob die VM 1GB RAM und 2 vCPUs hat, oder 16 GB RAM und 8 vCPUs, die Werte für
Code: 
fio --direct=1 --ioengine=libaio --rw=randrw --name=test --size=1G --direct=1 --bs=4K  -iodepth=16
sind die gleichen, ungefähr 5000 IOPS.
Übrigens, damit das nicht falsch rüberkommt: Wir sind nicht unzufrieden mit unseren aktuellen Werten. Ich möchte lediglich in Hinblick auf Hardware-Neuanschaffungen verstehen, was in Sachen Ceph-Performance die wichtigen Stellschrauben sind.
Click to expand...
Da passt aber irgend etwas nicht. Ich habe bei jedem Benchmark unterschiede, wenn ich vCPUs hoch schraube. Welchen CPU Typ nutzt du und welchen Controller Typ in der VM?
 
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
Back