Ceph Storage und Public Netzwerk Traffic geht falsch

[sb-jw]

Bisher habe ich immer Layer2+3 verwendet, mal schauen ob Layer3+4 einen Unterschied macht.

Hierzu eine kurze Erklärung, vielleicht war es dir klar vielleicht auch nicht.
Layer2+3 bedeutet, dass zum Verteilen der Daten die MAC- und IP-Adresse genutzt wird, beide Werte sind relativ statisch und lediglich einmal pro Link bzw. LACP vergeben. Die Wahrscheinlichkeit, dass du hierbei einen Link mehr oder ausschließlich benutzt, ist relativ hoch (aber auch geringer, als wenn nur Layer2 genutzt wird). Bei Layer3+4 wird die IP-Adresse und der Port genutzt. Da jede OSD (Object Storage Daemon) mit einem eigenen Port läuft, bietet layer3+4 dir eine höhere Chance, dass die Daten besser auf die bestehenden Links verteilt werden.

Es kommt hierbei natürlich darauf an wie viele Server miteinander kommunizieren. Aber bereits bei 2 Verbindungen pro Node, 3 Nodes im Cluster und jeweils 4 OSDs hast du eine deutlich bessere Verteilung des Traffics. Womöglich macht es aktuell auch noch keinen Unterschied, weil du eh nicht die 100 G ausgelastet hast, aber spätestens dann, wenn du mal ordentlich Traffic im Cluster hast, kann das einen Unterschied machen. Daher würde ich CEPH nicht mit layer2 oder layer2+3 betreiben, sondern immer direkt mit layer3+4.

Bisher beschränkt sich meine Erfahrung bis maximal Quincy mit Meshed Network und No-Subscription Repo. Bei diesen Setup ist das Enterprise-Repo aktiv und es ist gutmöglich das ich mir mein ganzes "Tuning" sparen kann, da es vermutlich schon weitestgehend von Proxmox optimiert wurde.

Das eine hat mit dem anderen nichts zu tun, du bekommst im no-subscription Repo exakt das gleiche Produkt wie im Enterprise. Der Unterschied liegt darin, dass du bei Enterprise eher getestete Pakete bekommst, dafür aber ggf. auch etwas länger warten musst. Ansonsten unterstützt du damit Proxmox selbst bei der Entwicklung der vielen Produkte.
Im CEPH selbst ist von Proxmox meines Wissens auch nichts optimiert. Es gibt womöglich gewisse Einstellungen auf OS-Ebene (aber eher nicht CEPH spezifisch), die angepasst wurden. Was aber z. B. derzeit immer noch ein Problem ist, sind die Filelimits, gerade mit CEPH und größeren VM Disks kann es sein, dass du hier ein Freeze läufst, daher erhöhe ich auch immer die Limits auf Maximum [0].
Im CEPH selbst gibt es eigentlich auch gar nicht so viel, was man wirklich tunen müsste, ich passe z. B. immer noch osd_memory_target [1] an und erhöhe es auf 6 GB (SSDs), bei einer NVMe bietet es sich an, hier mehr zu geben. Auch eben das Deaktivieren der Energiesparoptionen im BIOS hat einen positiven Einfluss auf die Performance. Ich hatte das mal getestet und konnte mit dem Deaktivieren der Energiesparoptionen die Latenz im Cluster ungefähr halbieren. Die Latenz spielt eine maßgebliche Rolle für die Gesamtperformance deines CEPH-Storages.
Die optimale Verteilung und Anzahl an PGs spielt auch noch eine größere Rolle, du solltest nicht zu wenig, aber auch nicht zu viele PGs pro OSD haben. Ich würde dir hierfür auf jeden Fall den Balancer empfehlen [2] und ggf. auch den Autoscaler [3].

Auch deine Hardware scheint grundsätzlich erst mal geeignet zu sein für CEPH. Bei deinen Disks ist immer wichtig, dass du einen HBA hast und die einzelnen Ports auch die Leistung des Datenträgers bringen können. Wenn du z. B. eine 24 Port Expander Backplane hast und die mit 24x SSDs vollmachst, kannst du davon ausgehen, dass die Backplane die Leistung der SSDs nicht ausreizen kann. Gleiches gilt aber auch für das Netzwerk Interface, wenn du nun tatsächlich eine Backplane hast, wo wirklich nur 4 SSDs pro Channel angeschlossen sind, dein Server aber nur 2x 10 GbE hat, hat er rein rechnerisch erst mal 44 GbE zu wenig an Bandbreite (16x 500 MB/s = 8.000 MB/s x 8 = 64 GbE). Dabei muss aber auch der RAM und die CPU entsprechend dimensioniert sein, du musst prüfen, dass die Netzwerkports die Leistung auch hergeben können (Stichwort PCIe Lanes).

Im Grunde gibt es daher im CEPH selbst nicht viel zu optimieren, es sind eher die Bedingungen außenrum bzw. die Einrichtung deiner Pools selbst. Du musst also für deine Anforderung das optimale Setup finden. Manche Anforderungen oder Einstellungen dabei sind womöglich etwas theoretischer und treten vielleicht im realen Betrieb niemals auf, dennoch können die später ein Bottleneck werden. Ich würde daher immer dazu raten, dass das Setup so konzipiert ist, dass keine Komponente blocken kann.

MTU konnte ich bisher nicht testen, weil dazu der Stack einmal durchgebootet werden muss, das ging bisher nicht, weil produktive Systeme drauf laufen. Ich werde dann nochmal berichten.

Wirklich? Bist du dir da sicher? Ich kann mich zumindest nicht daran erinnern, dass ich das tatsächlich mal bei z. B. Arista oder Juniper tun musste.

[0] https://forum.proxmox.com/threads/vm-disks-going-readonly.140543/#post-628986
[1] https://docs.ceph.com/en/latest/rados/configuration/bluestore-config-ref/#confval-osd_memory_target
[2] https://docs.ceph.com/en/latest/rados/operations/balancer/
[3] https://docs.ceph.com/en/latest/rados/operations/placement-groups/#autoscaling-placement-groups

 

[Falk R.]

Ich habe auch noch keine Ruckus Switches in der Hand gehabt, aber von Billig bis Teuer (Mikrotik bis Cisco) habe ich noch nie gesehen, dass man für eine MTU Änderung etwas booten muss.
Wie es klingt, mischt ihr das Storage-Netzwerk mit dem Client Netzwerk. Kann man machen, aber dann wenigstens noch ein getrenntes Netzwerk für Corosync nicht vergessen.
Ich trenne Storage Traffic lieber vom Client Netzwerk. Das ist weniger Fehleranfällig und du hast noch eine extra Redundanz für den Cluster, bzw wenn das Clientnetzwerk lahm gelegt wird, läuft der Cluster und das Storage noch. Das kann dir den Arsch retten.

 

[Haithabu84]

Ich habe auch noch keine Ruckus Switches in der Hand gehabt, aber von Billig bis Teuer (Mikrotik bis Cisco) habe ich noch nie gesehen, dass man für eine MTU Änderung etwas booten muss.
Wie es klingt, mischt ihr das Storage-Netzwerk mit dem Client Netzwerk. Kann man machen, aber dann wenigstens noch ein getrenntes Netzwerk für Corosync nicht vergessen.
Ich trenne Storage Traffic lieber vom Client Netzwerk. Das ist weniger Fehleranfällig und du hast noch eine extra Redundanz für den Cluster, bzw wenn das Clientnetzwerk lahm gelegt wird, läuft der Cluster und das Storage noch. Das kann dir den Arsch retten.

Da liegst du falsch. Selbst die Cisco Catalyst brauchen einen reload, was ein Neustart ist. Siehe:

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/24048-148.html

Das selbe gilt für Ruckus:

https://docs.ruckuswireless.com/fas...UID-193CBCDD-4080-443D-BACB-FBD3577D7B4A.html

Client und Storage laufen über die selben physischen Geräte. Die Switches haben genug Power um das zu stemmen. Sehe da kein Problem. Natürlich wird mit VLANs segmentiert. Für die Redundanz hast du beim Stack hitless failover. Sehe da kein Problem. Irgendwo muss ja die Kosteneffizienz herkommen. Lohnt sich nicht extra einen Switch nur für Storage laufen zu lassen, zumindest nicht bei diesem Setup. Selbst wenn ich einen günstigen 100Gbit-Switch von FS.com nehme, dann bin ich mal locker mehr als 10k los. Bei einem Ruckus/Commscope, Arista oder Cisco dann jenseits der 20k. Macht derzeit keinen Sinn und was in 7 Jahren ist (geplante Laufzeit des Clusters), weiß auch keiner.

Den Arsch rettet es mir auch nicht, wenn dann die Switches für das Storage-Netzwerk ausfallen. Für alles andere hat man hoffentlich ein Backup. Wir reden übrigens hier von einem Datacenter-Setup, zum hosten von Websites und Services. Da wird Client-technisch nicht großartig in die Breite skaliert. Der Traffic kommt da entweder per VPN oder über Port Forwarding zustande.

Corosync läuft derzeit über ein Broadcast-Bond im Mesh direkt. Sollte ein weiterer Cluster-Member dazu kommen, würde ich tatsächlich auftrennen und es über zwei separate Mini-Switches laufen lassen. Wahlweise dann mit bis zu drei link-Adressen.

 

[Haithabu84]

https://ceph.io/en/news/blog/2024/ceph-a-journey-to-1tibps/

hier war auch sowas "spooky" drin, dass es mal performanter und mal schlechter lief. Vielleicht ein Ansatz.
STRG+F "fix two" - IOMMU hatte einen wahnsinnigen Unterschied gemacht
-> https://ceph.io/en/news/blog/2024/c...xes_Validation_Tests_-_FIO_4MB_Throughput.svg

Um nochmal auf den Artikel zurückzukommen und IOMMU... habe ich das richtig verstanden das man das deaktivieren soll? Habe in Erinnerung das dies immer eher eine Empfehlung zur besseren Performance war.

 

[Haithabu84]

Ich habe jetzt mal alles so umgesetzt, wie es von euch empfohlen wurde, die Performance war anfangs wieder unterirdisch... mit teilweise sowas hier:

Total time run:         100.611
Total writes made:      41330
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     1643.15
Stddev Bandwidth:       915.089
Max bandwidth (MB/sec): 3580
Min bandwidth (MB/sec): 0
Average IOPS:           410
Stddev IOPS:            228.777
Max IOPS:               895
Min IOPS:               0
Average Latency(s):     0.0389432
Stddev Latency(s):      0.209953
Max latency(s):         3.15945
Min latency(s):         0.00494289

Aber dann auch wieder sowas:



Es hat sich dann zwischendurch wieder stabilisiert. Lesen ist komischerweise nie ein Problem gewesen, da bekomme ich ordentliche Werte mit um die 2000 IOPS und 8Gb/s Bandbreite.

Vor allem schwankt es extrem. Teilweise werden keine Pakete übertragen. Also irgendwo ist da noch der Wurm drin. Zusammengefasst folgende Sachen gemacht, alles andere wurde rückgängig gemacht oder deaktiviert:

• Bios: Determinism Slider auf Performance und IOMMU aktiviert. C-States deaktiviert und cTDP auf die maximal 225W gestellt. x2APIC verwendet
• Autoscaler im Testpool aktiv
• layer3+4 hash für LACP
• MTU9000

TX und RX Buffer brachte nur eine Glättung tatsächlich. Aber die Ausreißer nach oben waren dann auch nicht mehr so üppig. Ansonsten könnte ich jetzt noch osd_memory_target probieren. File Limits glaube ich nicht, das das bei uns ein Problem ist. Zumindest kenne ich derzeit keine VM die so groß ist, das es da an ein Limit kommt. TCP Limit in der sysctl könnte man ebenfalls noch anheben.

 

[Haithabu84]

osd_target_memory auf 6Gb angepasst. Aber läuft immer noch nicht wiederholgenau. Ungewöhnlich auch teilweise beim rados bench gesehen, das nichts übertragen wird...

 

[Haithabu84]

Wenn ich jeden einzelnen Node nochmal reboote und nichts verändere, erhalte ich danach diese Werte:





Das sind Werte die ich von dieser Hardware erwarte. Warum ich aber mit Laufzeit des Systems keine wiederholgenauen Ergebnisse erhalte, ist mir schleierhaft. Entweder schaltet sich hier eine Automatik ein oder ein Cache läuft voll. Ich werde morgen nochmals einen Test starten und schauen ob ich ähnliche Ergebnisse erhalte.

 

[sb-jw]

osd_target_memory auf 6Gb angepasst.

Wie erwähnt, bei NVMe würde ich eher mehr als 6 GB geben (auch wenn es in nachfolgendem Artikel anders steht).

Siehe auch: https://docs.ceph.com/en/quincy/start/hardware-recommendations/#memory

Ich persönlich teste aber auch die Performance nicht mit rados bench, sondern mit fio auf einer VM oder vom Host in einem Image. Für mich ist letztlich entscheidend was die VM an Leistung ziehen kann, daran orientiere ich mich und bekomme auch relativ gleiche Werte geliefert.

 

[Haithabu84]

Wie erwähnt, bei NVMe würde ich eher mehr als 6 GB geben (auch wenn es in nachfolgendem Artikel anders steht).

Siehe auch: https://docs.ceph.com/en/quincy/start/hardware-recommendations/#memory

Ich persönlich teste aber auch die Performance nicht mit rados bench, sondern mit fio auf einer VM oder vom Host in einem Image. Für mich ist letztlich entscheidend was die VM an Leistung ziehen kann, daran orientiere ich mich und bekomme auch relativ gleiche Werte geliefert.

Kannst du mir mal deine Parameter für fio mitteilen?

Dann würde ich das ebenfalls nochmal ausprobieren. Im Endeffekt ist so ein Benchmark nicht wirklich aussagekräftig weil er den wirklichen Workload nicht darstellt. Das ist ja nur sequentielles und plumpes Schreiben und Lesen. Es dient aber der Vergleichbarkeit. Wenn du mir die Parameter nennen kannst, dann kann ich testen und hier posten. Dies ließe Rückschlüsse zu, ob ich nun vergleichbar basierend auf meinen Setup plausible Ergebnisse bekomme oder ob ich irgendwo ein Problem habe.

fio hat aber tausend Parameter und alle führen zu teilweise unterschiedlichen Ergebnissen. Da wäre es eben hilfreich das direkt miteinander zu vergleichen.

 

[Haithabu84]

Teilweise birgt so ein Reboot wahre Wunder. Jetzt blieb das Ergebnis wiederholgenau.

osd_memory_target habe ich auf 8Gb angehoben und konnte nochmal etwas rausholen. Ich werde jetzt nochmal mit fio testen innerhalb einer VM.

 

[aaron]

weils zwar schon angesprochen wurde, aber glaub nicht im detail; wie viele PGs hast du pro OSD? ceph osd df tree
Hast du dem/den Pool(s) target_ratios/target_sizes zugewiesen damit der Autoscaler die pg_num besser abschätzen kann?

 

[Haithabu84]

weils zwar schon angesprochen wurde, aber glaub nicht im detail; wie viele PGs hast du pro OSD? ceph osd df tree
Hast du dem/den Pool(s) target_ratios/target_sizes zugewiesen damit der Autoscaler die pg_num besser abschätzen kann?

Nach welchen Gesichtspunkten stellt man denn ratio und sizes ein? Gibt es da irgendeine Richtlinie oder Hilfe? Wie soll man das herausfinden?

Autoscaler und Balancer ist aktiv. 128PG hatte er eingestellt und ich würde fast behaupten das jedes Mal wenn er auf 32 gegangen ist, die Performance einbrach.

Spoiler: ceph osd df tree

ceph osd df tree
ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP    META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME    
-1         20.95917         -   21 TiB  5.2 TiB  5.2 TiB  12 KiB  9.2 GiB   16 TiB  24.86  1.00    -          root default
-3          6.98639         -  7.0 TiB  1.7 TiB  1.7 TiB   4 KiB  3.3 GiB  5.2 TiB  24.99  1.01    -              host pve0
 0    ssd   1.74660   1.00000  1.7 TiB  574 GiB  573 GiB   1 KiB  999 MiB  1.2 TiB  32.08  1.29   40      up          osd.0
 1    ssd   1.74660   1.00000  1.7 TiB  412 GiB  411 GiB   1 KiB  824 MiB  1.3 TiB  23.01  0.93   30      up          osd.1
 2    ssd   1.74660   1.00000  1.7 TiB  407 GiB  407 GiB   1 KiB  609 MiB  1.3 TiB  22.76  0.92   29      up          osd.2
 3    ssd   1.74660   1.00000  1.7 TiB  395 GiB  394 GiB   1 KiB  945 MiB  1.4 TiB  22.11  0.89   30      up          osd.3
-5          6.98639         -  7.0 TiB  1.7 TiB  1.7 TiB   4 KiB  2.9 GiB  5.3 TiB  24.59  0.99    -              host pve1
 5    ssd   1.74660   1.00000  1.7 TiB  395 GiB  394 GiB   1 KiB  919 MiB  1.4 TiB  22.08  0.89   29      up          osd.5
 6    ssd   1.74660   1.00000  1.7 TiB  231 GiB  230 GiB   1 KiB  492 MiB  1.5 TiB  12.91  0.52   17      up          osd.6
 7    ssd   1.74660   1.00000  1.7 TiB  477 GiB  477 GiB   1 KiB  706 MiB  1.3 TiB  26.69  1.07   34      up          osd.7
 8    ssd   1.74660   1.00000  1.7 TiB  656 GiB  655 GiB   1 KiB  870 MiB  1.1 TiB  36.69  1.48   49      up          osd.8
-7          6.98639         -  7.0 TiB  1.7 TiB  1.7 TiB   4 KiB  3.0 GiB  5.2 TiB  25.00  1.01    -              host pve2
 9    ssd   1.74660   1.00000  1.7 TiB  533 GiB  532 GiB   1 KiB  974 MiB  1.2 TiB  29.82  1.20   39      up          osd.9
10    ssd   1.74660   1.00000  1.7 TiB  411 GiB  411 GiB   1 KiB  637 MiB  1.3 TiB  22.99  0.92   29      up          osd.10
11    ssd   1.74660   1.00000  1.7 TiB  219 GiB  218 GiB   1 KiB  633 MiB  1.5 TiB  12.22  0.49   16      up          osd.11
12    ssd   1.74660   1.00000  1.7 TiB  625 GiB  624 GiB   1 KiB  836 MiB  1.1 TiB  34.96  1.41   45      up          osd.12
                        TOTAL   21 TiB  5.2 TiB  5.2 TiB  14 KiB  9.2 GiB   16 TiB  24.86                                  
MIN/MAX VAR: 0.49/1.48  STDDEV: 7.37

 

[Haithabu84]

Also wenn ich das mit target_ratio und target_size richtig verstanden habe, ist das entweder oder Entscheidung, richtig? Also entweder setze ich die zu erwartenden Größe des Pools in MB als target_size oder ich setze ein relatives Verhältnis zu mehreren Pools mit target_ratio. Beides setzen, wird auch entsprechend mit einer Warnung quittiert. target_size scheint mir einfacher, auch deshalb weil vermutlich nicht soviele Pools zum Einsatz kommen werden.

 

[aaron]

Wenn wenige Pools zum Einsatz kommen, und du bei ein paar weißt, dass diese nur eine bestimmte maximale Größe erreichen werden, kannst du bei diesen eine target_size setzen. Bei den verbleibenden dann mit den Ratios arbeiten. Den .mgr kannst du bei den ganzen autoscaler Sachen ignorieren. Der will nur seine eine PG haben

Der Autoscaler rechnet dann die PGs für jeden Pool so aus, dass am Ende rund 100 PGs / OSD rauskommen.

Bei den Ratios bietet es sich an zwischen 0 und 100, oder 0.0 und 1.0 zu arbeiten. Dann fällt es leichter in Prozent zu denken.

 

[Haithabu84]

Mal als Beispiel, damit ich das richtig verstehe:

3 Pools alle um die 2Tb.

Pool1 1.0
Pool2 0.6
Pool3 0.4

Also würde folgenddessen Pool1 priorisiert behandelt und somit die bessere Performance erhalten? Kann man das so sehen?

 

[aaron]

Es geht nicht direkt um Performance, sondern darum, welche PG_Num jeder Pool bekommt. Je größer, desto mehr PGs sollte der Pool bekommen. Dadurch sind weniger Objekte in einer PG, und der Crush Algorithmus kann die Daten besser auf die OSDs verteilen.

Entsprechend sollten die Ratios/Sizes sich wirklich an der erwarteten Größe/Verbrauch orientieren.

Wenn du nichts vorgibst, kann sich der Autoscaler nur an dem aktuellen Füllstand orientieren, was gerade bei leeren Clustern zu wenigen PGs/OSD führt.

Zu wenige PGs/OSD kann dazu führen, dass die Daten nicht gut verteilt sind, womit manche OSDs deutlich voller sind als andere. Dadurch bekommen diese meist auch mehr IO ab und können zu einem Flaschenhals werden. Der andere Effekt ist, dass die vollste OSD vorgibt, wie viel freier Platz geschätzt wird.

Das hat auch Auswirkungen darauf wie gut die Last des Recovery verteilt werden kann: https://docs.ceph.com/en/quincy/rados/operations/placement-groups/#data-durability

 

[Haithabu84]

Es ist bei uns gar nicht so einfach da tatsächlich den zu erwartenden Bedarf zu ermitteln. Das Cluster ist im Prinzip zwar geplant anhand spezifischer Kritierien und für eine Laufzeit 7 Jahren. Aber ob da nun mit einem Mal 1Tb oder innerhalb von 2 Jahren nur 500Gb dazukommen, kann man nicht abschätzen. Es fiel mir tatsächlich auch nicht leicht da irgendeine Planung für Pools umzusetzen.

Vorher war es so, das einfach ein Pool mit Autoscaler aktiv gemacht wurde und dann alle Maschinen/Container dort drauf betrieben. Fertig.

Ich konnte jetzt mal vor ab eigentlich nur eine Struktur erkennen: Es gibt statische und variable Anwendungen, zusätzlich einen cephfs Pool für Auslagerung von Dumps oder Images. Letzteren habe ich per target_size auf 1000MB gesetzt. Den Pool Static auf 0.09 und die Variable auf 0.2. Im Endeffekt habe ich ungefähr geschätzt was in den nächsten Monaten zu erwarten sein könnte. Zum Beispiel für Variable 0.2 also 20% von 21Tb, was dann ungefähr bisschen mehr als 4Tb wären. Eventuell folgen dann mit der Zeit noch weitere Pools.

Ich habe außerdem einen Test mit fio innerhalb einer VM gemacht... da ich keine Vergleichsergebnisse finden konnte, habe ich einfach eine fio-Config per Google gefunden und verwendet:

Spoiler: fio

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 --max-jobs=16
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=214MiB/s,w=71.3MiB/s][r=54.8k,w=18.3k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=1334: Wed Feb 14 13:12:01 2024
  read: IOPS=58.4k, BW=228MiB/s (239MB/s)(3070MiB/13458msec)
   bw (  KiB/s): min=157672, max=257048, per=99.89%, avg=233341.23, stdev=24704.61, samples=26
   iops        : min=39418, max=64262, avg=58335.38, stdev=6176.21, samples=26
  write: IOPS=19.5k, BW=76.2MiB/s (79.9MB/s)(1026MiB/13458msec); 0 zone resets
   bw (  KiB/s): min=51376, max=85512, per=99.96%, avg=78032.00, stdev=8620.52, samples=26
   iops        : min=12844, max=21378, avg=19508.00, stdev=2155.13, samples=26
  cpu          : usr=8.38%, sys=29.74%, ctx=144761, majf=0, minf=8
  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=228MiB/s (239MB/s), 228MiB/s-228MiB/s (239MB/s-239MB/s), io=3070MiB (3219MB), run=13458-13458msec
  WRITE: bw=76.2MiB/s (79.9MB/s), 76.2MiB/s-76.2MiB/s (79.9MB/s-79.9MB/s), io=1026MiB (1076MB), run=13458-13458msec

Disk stats (read/write):
  sda: ios=783437/261843, merge=0/2, ticks=519285/299704, in_queue=819004, util=99.33%

Das war auf dem Pool mit target_ration 0.2... keine Ahnung ob das gut oder schlecht ist. Man findet leider keine aktuellen Vergleichswerte. Kann jemand mit dieser Config mal einen Test bei sich machen und mir das Ergebnis mitteilen, damit ich vergleichen kann?

 

[sb-jw]

Kannst du mir mal deine Parameter für fio mitteilen?

Da würde ich dich auch mal auf den Benchmark von Proxmox direkt verweisen: https://www.proxmox.com/en/download...cumentation/proxmox-ve-ceph-benchmark-2023-12
Ansonste benutze ich:

# Random Read/Write mixed
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

# Random Read
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randread

# Random Write
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=benchmark --filename=benchmark --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

Man findet leider keine aktuellen Vergleichswerte.

https://forum.proxmox.com/threads/i...ist-extrem-schlecht.134760/page-2#post-623175
https://forum.proxmox.com/threads/i...ist-extrem-schlecht.134760/page-2#post-623178

Mein Setup: https://forum.proxmox.com/threads/i...ist-extrem-schlecht.134760/page-2#post-623190

Das war auf dem Pool mit target_ration 0.2... keine Ahnung ob das gut oder schlecht ist.

Ich würde deine Ergebnisse jetzt auch nicht im Detail beurteilen wollen, da dein Befehl von meinen abweicht. Es könnte aber durchaus realistisch sein und für die Anzahl Server / OSDs auch im Rahmen sein. Du kannst ja aber einfach mal meine Befehle nutzen, dann kannst du zumindest gegen meinen SSD CEPH vergleichen und hast so zumindest eine grobe Indikation ob du auf einem gut weg bist.

 

[Haithabu84]

Vielen Dank. Ich habe die Tests mal genauso durchgeführt:

Spoiler: Random Read/Write mixed

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
Jobs: 1 (f=1): [m(1)][100.0%][r=246MiB/s,w=81.3MiB/s][r=63.0k,w=20.8k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1357: Wed Feb 14 13:56:08 2024
  read: IOPS=60.6k, BW=237MiB/s (248MB/s)(3070MiB/12968msec)
   bw (  KiB/s): min=182944, max=261720, per=100.00%, avg=242850.24, stdev=14748.99, samples=25
   iops        : min=45736, max=65430, avg=60712.56, stdev=3687.25, samples=25
  write: IOPS=20.3k, BW=79.1MiB/s (83.0MB/s)(1026MiB/12968msec); 0 zone resets
   bw (  KiB/s): min=59832, max=87056, per=100.00%, avg=81209.60, stdev=5192.63, samples=25
   iops        : min=14958, max=21764, avg=20302.40, stdev=1298.16, samples=25
  cpu          : usr=9.82%, sys=41.48%, ctx=155892, majf=0, minf=7
  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=237MiB/s (248MB/s), 237MiB/s-237MiB/s (248MB/s-248MB/s), io=3070MiB (3219MB), run=12968-12968msec
  WRITE: bw=79.1MiB/s (83.0MB/s), 79.1MiB/s-79.1MiB/s (83.0MB/s-83.0MB/s), io=1026MiB (1076MB), run=12968-12968msec

Disk stats (read/write):
  sda: ios=783134/261738, merge=0/2, ticks=490740/272735, in_queue=763489, util=99.31%

Spoiler: Random Read

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=426MiB/s][r=109k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1360: Wed Feb 14 13:58:20 2024
  read: IOPS=108k, BW=422MiB/s (443MB/s)(4096MiB/9697msec)
   bw (  KiB/s): min=377064, max=451136, per=100.00%, avg=433764.63, stdev=17365.87, samples=19
   iops        : min=94266, max=112784, avg=108441.26, stdev=4341.51, samples=19
  cpu          : usr=11.85%, sys=48.21%, ctx=124415, majf=0, minf=71
  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=422MiB/s (443MB/s), 422MiB/s-422MiB/s (443MB/s-443MB/s), io=4096MiB (4295MB), run=9697-9697msec

Disk stats (read/write):
  sda: ios=1045572/3, merge=0/1, ticks=578618/5, in_queue=578624, util=99.08%

Spoiler: Random Write

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=195MiB/s][w=49.9k IOPS][eta 00m:00s]
benchmark: (groupid=0, jobs=1): err= 0: pid=1364: Wed Feb 14 13:59:59 2024
  write: IOPS=46.6k, BW=182MiB/s (191MB/s)(4096MiB/22483msec); 0 zone resets
   bw (  KiB/s): min=29640, max=235608, per=100.00%, avg=187670.55, stdev=49989.99, samples=44
   iops        : min= 7410, max=58902, avg=46917.64, stdev=12497.50, samples=44
  cpu          : usr=5.48%, sys=28.68%, ctx=397654, majf=0, minf=9
  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=182MiB/s (191MB/s), 182MiB/s-182MiB/s (191MB/s-191MB/s), io=4096MiB (4295MB), run=22483-22483msec

Disk stats (read/write):
  sda: ios=0/1045836, merge=0/4, ticks=0/1383086, in_queue=1383171, util=99.64%

Ich würde sagen die Ergebnisse sind plausibel. Bei @sb-jw sind durch mehr OSDs und Nodes eine bessere Lastverteilung.

 

[Haithabu84]

Ich habe auch nochmal die Benchmarks aus dem Proxmox Paper durchgeführt:

Spoiler: Write

Total time run:         300.009
Total writes made:      317197
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     4229.16
Stddev Bandwidth:       651.679
Max bandwidth (MB/sec): 5260
Min bandwidth (MB/sec): 684
Average IOPS:           1057
Stddev IOPS:            162.92
Max IOPS:               1315
Min IOPS:               171
Average Latency(s):     0.015131
Stddev Latency(s):      0.0217906
Max latency(s):         2.07943
Min latency(s):         0.004489

Spoiler: Read

Total time run:       152.374
Total reads made:     317197
Read size:            4194304
Object size:          4194304
Bandwidth (MB/sec):   8326.82
Average IOPS:         2081
Stddev IOPS:          66.444
Max IOPS:             2216
Min IOPS:             1745
Average Latency(s):   0.00739323
Max latency(s):       0.213266
Min latency(s):       0.00273328

Im Lesen bin ich gleich auf, würde ich sagen oder sogar besser. im Schreiben scheint die Kioxia, auch laut Datenblatt, überlegen. Die hat bisschen mehr Bandbreite und dafür aber beim Schreiben fast doppelt soviele IOPS. Also ich denke jetzt sollte alles im Lot sein, zumindest wenn ich alles richtig gedeutet habe.