Ceph Storage und Public Netzwerk Traffic geht falsch

H

Haithabu84

Well-Known Member
Oct 19, 2016
119
4
58
32
Hallo,

ich bin gerade dabei ein neues Ceph Cluster aufzusetzen, aber stelle da paar Probleme fest. Beim Benchmark fiel mir auf das die Werte weit weg von dem sind, was die Hardware eigentlich leisten sollte.

Zum Setup:

Drei Nodes
Epyc 7543P
512Gb RAM
Mellanox ConnectX6 100Gbit
Broadcom P225P 10/25Gbit
4x Samsung PM9A3

Die beiden Ports der Mellanox sind jeweils mit einem Switch verbunden per LACP-LAG. Beim Benchmark mit Rados Bench kam ich teilweise beim Schreiben nicht mal auf 200IOPS. Bei der Überprüfung mit bmon kam heraus das der OSD-Traffic den falschen Weg nimmt und zwar über den LAN-Link und 10Gbit. Das würde die schwache Performance erklären.

Ich hatte während der Installation über das WebGUI das Public und Storage Network gesplittet, weil wir eventuell externe Bare-Metal Hosts Zugriff auf CephFS gewären wollen und dies einfach komfortabel per VLAN Routen wollen. So sieht erstmal die Ceph-Config aus:

Code: 
[global]
     auth_client_required = cephx
     auth_cluster_required = cephx
     auth_service_required = cephx
     cluster_network = 10.255.255.50/24
     mon_allow_pool_delete = true
     mon_host = 10.255.253.50 10.255.253.51 10.255.253.52
     ms_bind_ipv4 = true
     ms_bind_ipv6 = false
     osd_pool_default_min_size = 2
     osd_pool_default_size = 3
     public_network = 10.255.253.50/24

[client]
     keyring = /etc/pve/priv/$cluster.$name.keyring

[mon.pve0]
     public_addr = 10.255.253.50

[mon.pve1]
     public_addr = 10.255.253.51

[mon.pve2]
     public_addr = 10.255.253.52

Cluster_network ist in diesem Fall richtigerweise das Subnetz der 100Gbit Mellanox-Karten, aber die OSD-Replication geht über das Public_Network 10.255.253.0/24...

Wenn ich Ceph richtig verstanden habe, sollte das Cluster_network eigentlich ausschließlich für den OSD-Replikation sein. Aber da geht derzeit nichts drüber, als würde es völlig ignoriert werden. Woran liegt das?

Gruß
 
Auf welchen Ports lauschen die OSDs? Entweder ss -tulpn | grep osd oder in der GUI die OSD Details anschauen. Wenn sie nicht am Cluster netz lauschen, versuch die OSds mal neu zu starten.
 
Die lauschen sowohl im Public als auch im Cluster Network...

Screenshot 2024-02-09 114555.png

Screenshot 2024-02-09 114457.png

Back Address und Heatbeat sind richtig. Allerdings wird der Traffic für geschriebene Daten von den Hosts nicht über dieses Netzwerk geleitet.
 
Ich habe jetzt in der ceph.conf das Netzwerk nochmal angepasst, da mir aufgefallen war, das dort z.B.10.255.255.50/24 statt 10.255.255.0/24 stand. Danach die Hosts alle nochmal durchgestartet, jetzt scheint die Replikation den richtigen Weg zu nehmen. Zumindest laut bmon. Ergebnis der Bandbreite war prompt besser:

Code: 
Total time run:         100.03
Total writes made:      29849
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     1193.6
Stddev Bandwidth:       82.6319
Max bandwidth (MB/sec): 1408
Min bandwidth (MB/sec): 1028
Average IOPS:           298
Stddev IOPS:            20.658
Max IOPS:               352
Min IOPS:               257
Average Latency(s):     0.0536151
Stddev Latency(s):      0.038296
Max latency(s):         0.214474
Min latency(s):         0.00518791

Allerdings immer noch schwach. Cstates sind gesetzt, Cache für die Schnittstellen auf Max erhöht, Kernel auf Performance. Einzige was jetzt noch fehlt ist MTU9000. Aber das hat meist nicht mehr soviel ausgemacht. Hat sich im Gegensatz zu Quincy etwas grundlegend in der Performance geändert?
 
Haithabu84 said:
Allerdings immer noch schwach. Cstates sind gesetzt, Cache für die Schnittstellen auf Max erhöht, Kernel auf Performance. Einzige was jetzt noch fehlt ist MTU9000. Aber das hat meist nicht mehr soviel ausgemacht. Hat sich im Gegensatz zu Quincy etwas grundlegend in der Performance geändert?
Click to expand...
Eigentlich gibts nur Performance Verbesserungen. Warum machst du denn den Public und Cluster Traffic nicht beides über die 100G Verbindung? Auch da kannst du ja VLANs zur Trennung nutzen und eventuell andere Verbraucher in das Public Netz connecten lassen.
Bei deinem Benchmark hast du mit den 1193 MB/s ja die 10G voll ausgelastet. Mehr kann man da nicht erwarten.
 
Falk R. said:
Eigentlich gibts nur Performance Verbesserungen. Warum machst du denn den Public und Cluster Traffic nicht beides über die 100G Verbindung? Auch da kannst du ja VLANs zur Trennung nutzen und eventuell andere Verbraucher in das Public Netz connecten lassen.
Bei deinem Benchmark hast du mit den 1193 MB/s ja die 10G voll ausgelastet. Mehr kann man da nicht erwarten.
Click to expand...
Weil ich den OSD-Traffic unbeeinflusst vom Client-Traffic halten wollte. Aber ich scheine etwas nicht zu verstehen:

Bei 100.000Mbits wären es doch ca 12500MB/s, oder nicht? Der Traffic passiert nun auch auf der 100Gbit Schnittstelle, das kann ich per Bmon nachvollziehen.

Siehe hier:

Screenshot 2024-02-09 121922.png

Bond2 sind die 100G und Bond1 die 10G. Wie man sieht geht alles über die 100G-Schnittstelle. Nur mal zum Vergleich: In einem Mesh habe ich mit diesem Setup schon locker über 1100IOPS und eine Bandbreite von fast 5000MB/s hinbekommen. Der einzige Unterschied ist hier nun, das es über einen Switch geht per LACP. Das dort ein gewisser Performance-Verlust entsteht, ist verschmerzbar im Anbetracht der Tatsache das ich besser skalieren kann, aber das es soviel ausmachen soll? Glaube ich eher weniger...
 
Komisch das dies irgendwie in Bmon nicht angezeigt wird, weil dort stand der Traffic teilweise nur auf 1.21MiB und auf der Bond2 eben auf 906MiB.

Aber dann bedeutet es also, durch die Wahl der Konfiguration beschneidet man sich also selbst? Dann war das mein Denkfehler. Ich werde das mal beides, Public und Cluster, auf die 100er nehmen und nochmal testen.
 
Haithabu84 said:
Komisch das dies irgendwie in Bmon nicht angezeigt wird, weil dort stand der Traffic teilweise nur auf 1.21MiB und auf der Bond2 eben auf 906MiB.

Aber dann bedeutet es also, durch die Wahl der Konfiguration beschneidet man sich also selbst? Dann war das mein Denkfehler. Ich werde das mal beides, Public und Cluster, auf die 100er nehmen und nochmal testen.
Click to expand...
Dein bmon zeigt doch auf vmbr0 866MiB Traffic an auf VLAN 1501
 
Falk R. said:
Dein bmon zeigt doch auf vmbr0 866MiB Traffic an auf VLAN 1501
Click to expand...
Oh Gott. Tatsächlich. Völlig überlesen. Dann ist alles klar.

Aber nochmal eine andere Sache: Wie macht man das bei Ceph generell, wenn ich mich nach dieser Grafik hier richte...

https://docs.ceph.com/en/quincy/_images/ditaa-3bf285dacff79a5fe5eea8dd9ca2bd41baa26061.png

...und ich habe schon viele Setups (Kein Proxmox) gesehen, wo das Public-Network nur auf 10Gbit lief und das Storage getrennt mit 100Gbit. Da hatte das diesen Impact nicht. Wie kann ich Proxmox dazu bringen die Daten nicht erst auf die langsame 10Gbit zu schieben und trotzdem eine Trennung zwischen Public und Cluster Storage zu bekommen? Das macht für mich bis hierhin keinen Sinn.
 
Du hast ein Public Netz definiert, auf welchem die Clients sich verbinden sollen. Das Cluster Netz ist nur für die CEPH internen geschichten (z.B. Backfill oder replication). Es kann also in deinem Setup nicht so funktionieren, dass die Clients die Daten schneller einliefern als über 10 GbE. Was du hier gemacht hast ist ja eine physische Netztrennung. Wenn du von den 100 G profitieren willst, musst du 4x 100 G am Server haben oder über die 2x 100 G eben zwei VLANs legen. Dann hast du den Traffic immer noch getrennt, aber es läuft alles auf einem physischen Link, heißt also auch, dass ein DDoS Angriff beides lahmlegen kann.

Aber kannst du noch mal im Detail definieren, was hier für dich der Impact ist?
Die Performance kann an verschiedenen Konfigurationen hängen, beispielsweise die MTU, das Hashing-Verfahren des LACP, der PGs des Pools und Replication. Wenn du also diese magere Performance meinst, dann ja, dann würde ich dir grundsätzlich recht geben, dass auch ich hier mehr erwarten würde.

Ich glaube aber auch nicht, dass das Problem hier tatsächlich an der Netztrennung liegt.
 
Haithabu84 said:
Oh Gott. Tatsächlich. Völlig überlesen. Dann ist alles klar.

Aber nochmal eine andere Sache: Wie macht man das bei Ceph generell, wenn ich mich nach dieser Grafik hier richte...

https://docs.ceph.com/en/quincy/_images/ditaa-3bf285dacff79a5fe5eea8dd9ca2bd41baa26061.png

...und ich habe schon viele Setups (Kein Proxmox) gesehen, wo das Public-Network nur auf 10Gbit lief und das Storage getrennt mit 100Gbit. Da hatte das diesen Impact nicht. Wie kann ich Proxmox dazu bringen die Daten nicht erst auf die langsame 10Gbit zu schieben und trotzdem eine Trennung zwischen Public und Cluster Storage zu bekommen? Das macht für mich bis hierhin keinen Sinn.
Click to expand...
Client ist deine VM oder dein CephFS Gateway. Der schickt seine Anfragen immer über das Public Network zur nächsten OSD, die die gewünschte PG hält. Beim lesen liefert der Deamon die Daten direkt zurück. Beim Schreiben verteilt die OSD die Daten je nachdem ob Replication oder EC über das Cluster Network zu den anderen OSD.
 
Ok. Es ist wieder völlig eigenartig. Ich habe jetzt zwei VLANs auf dem 100Gbit Netzwerk und anfangs waren die ersten Benchmarks sehr vielverprechend, nach einigen Optimierungen hatte ich so annährend zufriedenstellende Ergebnisse. Average IOPS lagen bei 1200 und Bandbreite im Schreiben bei knapp 5000MB/s. Soweit so gut.

Dann habe ich die RX und TX Buffer angehoben und ein ifreload ausgeführt und dann brachen die Ergebnisse wieder ein nach erneutem Benchmarks. Wieder so maximal 1200MB/s und um die 350IOPS.

Dann Reboot ausgeführt. Wieder gute Ergebnisse gehabt. Nach einiger Zeit zweiten Test gemacht, wieder absolute schlechte Ergebnisse. Als würde irgendwas drosseln.

Wie kann das sein?
 
Last edited:
Es wird immer schlechter:

Screenshot 2024-02-09 180257.png

Code: 
auto lo
iface lo inet loopback

auto enp1s0f0np0
iface enp1s0f0np0 inet manual

auto enp1s0f1np1
iface enp1s0f1np1 inet manual

auto eno1np0
iface eno1np0 inet manual

auto eno2np1
iface eno2np1 inet manual

auto enp197s0f0np0
iface enp197s0f0np0 inet manual

auto enp197s0f1np1
iface enp197s0f1np1 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp1s0f0np0 enp1s0f1np1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3
#lan bond

auto bond1
iface bond1 inet static
        address 10.255.254.50/24
        bond-slaves eno1np0 eno2np1
        bond-miimon 100
        bond-mode broadcast
#corosync

auto bond2
iface bond2 inet static
        address 10.255.255.50/24
        bond-slaves enp197s0f0np0 enp197s0f1np1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3
        pre-up /sbin/ethtool -G enp197s0f0np0 rx 8192 tx 8192
        pre-up /sbin/ethtool -G enp197s0f1np1 rx 8192 tx 8192
        pre-up /sbin/ethtool -C enp197s0f0np0 adaptive-rx on adaptive-tx on
        pre-up /sbin/ethtool -C enp197s0f1np1 adaptive-rx on adaptive-tx on
#ceph cluster storage

auto bond2.1501
iface bond2.1501 inet static
        address 10.255.253.50/24
#ceph public

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#lan bridge

auto vmbr0.20
iface vmbr0.20 inet static
        address 10.255.1.50/24
        gateway 10.255.1.254
#management

source /etc/network/interfaces.d/*

Ansonsten ist noch tuned installiert mit Profile network-latency

Und auch:

Code: 
cpupower idle-set -D 11
cpupower frequency-set -g performance

Alles so Standard-Sachen. Damit sollten eigentlich ohne Probleme 1000IOPS möglich sein. Ich habe hier schon etliche 3-node-Cluster mit Mesh Network im Einsatz und bei allen ging das ohne Probleme.
 
Adaptive-tx/rx mochte er überhaupt nicht. Habe ich wieder rausgeschmissen. Die Ergebnisse blieben dennoch schlecht. Dann nach einer halben Stunde nochmal getestet, plötzlich wieder solche Ergebnisse hier:

Code: 
Total time run:         100.031
Total writes made:      93002
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     3718.94
Stddev Bandwidth:       1016.26
Max bandwidth (MB/sec): 5196
Min bandwidth (MB/sec): 1700
Average IOPS:           929
Stddev IOPS:            254.066
Max IOPS:               1299
Min IOPS:               425
Average Latency(s):     0.0172072
Stddev Latency(s):      0.0185803
Max latency(s):         0.165058
Min latency(s):         0.00488377

Sind hier irgendwelche Automatiken oder Caches die mir hier mein Tests beeinflussen?
 
Last edited:
Also ich habe dem ganzen "tuning" abgeschworen, das war vielleicht früher mal nötig, aber heute? Bisher habe ich damit nie Probleme gehabt, lasse mich aber gerne vom Gegenteil überzeugen. Schau dir auch gerne mal diesen Artikel von Croit an: https://croit.io/blog/ceph-performance-test-and-optimization

Ich setze lediglich die MTU auf 9000 und nutze immer layer3+4 Hashing für das CEPH. Ansonsten setze ich im BIOS das Performance Profil, damit erübrigt sich in der Regel auch das setzen mit cpupower. Du kannst noch das Memory Target der OSDs auf 6 oder 8 GB erhöhen.

Was hast du denn für Switches und wie sind die konfiguriert? Sieht denn unter cat /proc/net/bonding/bond2 alles sauber aus?
 
Und einfach noch mal zum einfacheren Verständnis zu den Ceph Netzwerken - so für die Allgemeinheit, weil das oft kommt.
Mag jetzt nicht so detailliert perfekt erklärt sein, aber vielleicht doch tauglich als "Explain like i'm 5years old", zumindest habe ich es selbst so verstanden, bin selbst Anfänger :)


Ceph ist in Proxmox ja einfach eine Storage-Schicht, die man sich mal völlig vom PVE losgelöst vorstellen muss.
Denke dir, CEPH wäre komplett separate Hardware.

(User-/VM-Traffic kommt unten!)
Ceph Frontend: Hierüber greift der einzelne Hypervisor-Node auf CEPH zu - also das, was die QEMU-VMs in ihre virtuellen Disks schreiben oder lesen wollen.
Ceph Backend: Hier halt die Ceph-interne Replication etc.

Wenn du also IN einer VM Writes erzeugst, werden sie über das Ceph Frontend an ein OSD geliefert.
Das wiederum macht dann z.B. die Replication über das Backend-Netz.

Die Performance der VM ist also durch das CEPH Frontend und damit die Benchmarks schon mal auf 10/25Gbit limitiert während das Backend mit 100Gbit arbeitet.
Daher der Einwand von Falk R, das Ceph Frontend auch auf 100G laufen zu lassen - auch hierauf greifen erst mal nur die Proxmox-Nodes zu. Das VLAN kannst du ja routen lassen, so dass die externen Nodes mit CephFS drankommen (oder den externen Nodes direkt Uplinks an den gleichen Switch direkt ins VLAN...)

Das User- bzw "VMs untereinander"-Netz, also der Weg, wie man überhaupt von Remote Daten in eine VM schiebt:
Die 10/25G Ports kannst du dann ganz normal für deine VMs verwenden, also den Weg wie VMs untereinander reden oder User vom Arbeitsplatz aus drauf zugreifen.


Das Bild von oben: https://docs.ceph.com/en/quincy/_images/ditaa-3bf285dacff79a5fe5eea8dd9ca2bd41baa26061.png
Der Ceph Client ganz oben ist der QEMU-VM-Prozess; das User-Netz wäre quasi noch weiter oben drüber
 
  • Like
Reactions: aaron
Ich habe ein Stack aus zwei Ruckus ICX7850-48F. Die Werte mit 100Gbit hauen haargenau hin, wie ich es erwarten würde. Mal als Beispiel:

Code: 
qperf -t 60 -v 10.255.255.51 tcp_bw tcp_lat
tcp_bw:
    bw              =  2.94 GB/sec
    msg_rate        =  44.9 K/sec
    time            =    60 sec
    send_cost       =   245 ms/GB
    recv_cost       =   666 ms/GB
    send_cpus_used  =  72.2 % cpus
    recv_cpus_used  =   196 % cpus
tcp_lat:
    latency        =  11.8 us
    msg_rate       =  84.7 K/sec
    time           =    60 sec
    loc_cpus_used  =   126 % cpus
    rem_cpus_used  =   129 % cpus

Code: 
[ ID] Interval       Transfer     Bandwidth
[  5] 0.0000-9.9989 sec  22.9 GBytes  19.7 Gbits/sec
[  2] 0.0000-10.0011 sec  20.5 GBytes  17.6 Gbits/sec
[  1] 0.0000-10.0057 sec  22.9 GBytes  19.7 Gbits/sec
[  3] 0.0000-10.0001 sec  20.5 GBytes  17.6 Gbits/sec
[  4] 0.0000-9.9997 sec  22.8 GBytes  19.5 Gbits/sec
[SUM] 0.0000-10.0059 sec   110 GBytes  94.1 Gbits/sec

Ich würde mich auch nicht als blutigen Anfänger bezeichnen. Das mit dem Split von Public und Cluster Network ist tatsächlich eine Premiere, da es so noch nie gebraucht wurde. War aber eine Anforderung. 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.

Auf jeden Fall werde ich diese Sachen vorerst wieder rückgängig machen und mich auf MTU9000 und den Hash-Algorithm beim LACP anpassen. Bisher habe ich immer Layer2+3 verwendet, mal schauen ob Layer3+4 einen Unterschied macht. 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.
 
  • Like
Reactions: Falk R.
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