Kann Ceph Flaschenhals nicht finden

[illumina7]

Moin,
Ich habe einen relativ kleinen PVE HCI Ceph Cluster im Einsatz und irgendwo bleibt massiv Performance auf der Strecke, ich kann den Fehler leider nicht finden.

Kurz zum Setup:
- 2x Supermicro Server Dual Epyc 7302, 384GB Ram
- 1x HPE DL360 G9 V4 Dual E5-2640v4, 192GB Ram
- 1x Fujitsu RX200 oder so, Dual E5-2690, 256GB Ram
- 56 VMs (Linux+Win), 10 LXCs gesamt

Alle mit Intel 10G Netzwerkkarten ausgestattet (denke X540, X550 und X710), Backend/Storage Netzwerk mit einem Qnap QSW-M1208-8C Switch (in der Pandemie angeschafft, war nichts anderes in der Preisklasse lieferbar), Backend Netzwerk mit LACP L2+3 und Jumbo Frames konfiguriert.
Frontend Netzwerk mit einem Unifi USW EnterpriseXG 24, alle PVE Hosts auch hier mit Dual 10G LACP L2+3 verbunden, diverse VLANs, 25G Uplink zu einer pfsense, hier läuft auch der VM Traffic.
Insgesamt 33 OSDs über die 4 Hosts verteilt mit Enterprise SSDs (Samsung, Toshiba und Intel).

Folgendes Problem:
Die Performance ist mies, immer wieder brich die Leistung tagsüber ein und die VMs werden sehr träge. Wenn ich innerhalb der VMs Daten kopiere, dann komme ich selten über 1G Geschwindigkeit, selbst wenn es mal mit höherer Geschwindigkeit laufen sollte, bricht diese dann rapide auf weit unter 1G ein.

Gefühlt läuft der Storage irgendwie mit angezogener Handbremse und ich kann diese nicht ausfindig machen.

rados bench -p small_ssd_storage 30 write --no-cleanup

Total time run:         30.1799
Total writes made:      2833
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     375.482
Stddev Bandwidth:       42.5316
Max bandwidth (MB/sec): 468
Min bandwidth (MB/sec): 288
Average IOPS:           93
Stddev IOPS:            10.6329
Max IOPS:               117
Min IOPS:               72
Average Latency(s):     0.169966
Stddev Latency(s):      0.122672
Max latency(s):         0.89363
Min latency(s):         0.0194953

rados bench -p testpool 30 rand

Total time run:       30.1634
Total reads made:     11828
Read size:            4194304
Object size:          4194304
Bandwidth (MB/sec):   1568.52
Average IOPS:         392
Stddev IOPS:          36.6854
Max IOPS:             454
Min IOPS:             322
Average Latency(s):   0.0399157
Max latency(s):       1.45189
Min latency(s):       0.00244933

-> auffällig: hier fehlen irgendwie die IOPS?

root@pve00:~# ceph osd df tree
ID  CLASS      WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME     
-1             48.03107         -   48 TiB   32 TiB   32 TiB   26 MiB   85 GiB   16 TiB  65.76  1.00    -          root default 
-3             14.84592         -   15 TiB  8.7 TiB  8.7 TiB  8.9 MiB   26 GiB  6.1 TiB  58.92  0.90    -              host pve00
 2  large_ssd   6.98630   1.00000  7.0 TiB  3.0 TiB  3.0 TiB  5.5 MiB  6.6 GiB  4.0 TiB  43.06  0.65  442      up          osd.2
 0  small_ssd   0.87329   1.00000  894 GiB  636 GiB  634 GiB  689 KiB  2.6 GiB  258 GiB  71.14  1.08  132      up          osd.0
 1  small_ssd   0.87329   1.00000  894 GiB  650 GiB  647 GiB  154 KiB  2.7 GiB  245 GiB  72.64  1.10  139      up          osd.1
 4  small_ssd   0.87329   1.00000  894 GiB  637 GiB  635 GiB  179 KiB  2.0 GiB  257 GiB  71.28  1.08  136      up          osd.4
 6  small_ssd   0.87329   1.00000  894 GiB  648 GiB  646 GiB  181 KiB  2.2 GiB  246 GiB  72.49  1.10  137      up          osd.6
 9  small_ssd   0.87329   1.00000  894 GiB  677 GiB  675 GiB  179 KiB  1.8 GiB  217 GiB  75.71  1.15  141      up          osd.9
12  small_ssd   0.87329   1.00000  894 GiB  659 GiB  657 GiB  184 KiB  1.9 GiB  235 GiB  73.72  1.12  137      up          osd.12
15  small_ssd   0.87329   1.00000  894 GiB  674 GiB  672 GiB  642 KiB  2.2 GiB  220 GiB  75.40  1.15  141      up          osd.15
17  small_ssd   0.87329   1.00000  894 GiB  650 GiB  648 GiB  188 KiB  1.6 GiB  244 GiB  72.70  1.11  137      up          osd.17
19  small_ssd   0.87329   1.00000  894 GiB  645 GiB  643 GiB  1.0 MiB  2.2 GiB  249 GiB  72.13  1.10  138      up          osd.19
-5              8.73291         -  8.7 TiB  6.7 TiB  6.7 TiB  6.2 MiB   21 GiB  2.0 TiB  77.20  1.17    -              host pve01
 3  small_ssd   0.87329   1.00000  894 GiB  690 GiB  689 GiB  1.1 MiB  1.5 GiB  204 GiB  77.17  1.17  138      up          osd.3
 7  small_ssd   0.87329   1.00000  894 GiB  668 GiB  665 GiB  181 KiB  2.5 GiB  227 GiB  74.66  1.14  138      up          osd.7
10  small_ssd   0.87329   1.00000  894 GiB  699 GiB  697 GiB  839 KiB  2.0 GiB  195 GiB  78.17  1.19  144      up          osd.10
13  small_ssd   0.87329   1.00000  894 GiB  700 GiB  697 GiB  194 KiB  2.4 GiB  195 GiB  78.25  1.19  148      up          osd.13
16  small_ssd   0.87329   1.00000  894 GiB  695 GiB  693 GiB  1.2 MiB  1.7 GiB  199 GiB  77.72  1.18  140      up          osd.16
18  small_ssd   0.87329   1.00000  894 GiB  701 GiB  700 GiB  184 KiB  1.6 GiB  193 GiB  78.42  1.19  142      up          osd.18
20  small_ssd   0.87329   1.00000  894 GiB  697 GiB  695 GiB  173 KiB  2.4 GiB  197 GiB  77.95  1.19  146      up          osd.20
21  small_ssd   0.87329   1.00000  894 GiB  675 GiB  673 GiB  684 KiB  2.5 GiB  219 GiB  75.52  1.15  140      up          osd.21
22  small_ssd   0.87329   1.00000  894 GiB  688 GiB  686 GiB  821 KiB  2.1 GiB  206 GiB  76.93  1.17  139      up          osd.22
23  small_ssd   0.87329   1.00000  894 GiB  691 GiB  689 GiB  918 KiB  2.2 GiB  203 GiB  77.25  1.17  142      up          osd.23
-7             13.97266         -   14 TiB  8.2 TiB  8.2 TiB  8.8 MiB   22 GiB  5.7 TiB  58.94  0.90    -              host pve02
32  large_ssd   6.98630   1.00000  7.0 TiB  3.0 TiB  3.0 TiB  4.7 MiB  7.4 GiB  4.0 TiB  43.00  0.65  442      up          osd.32
 5  small_ssd   0.87329   1.00000  894 GiB  693 GiB  691 GiB  1.2 MiB  2.2 GiB  201 GiB  77.53  1.18  140      up          osd.5
 8  small_ssd   0.87329   1.00000  894 GiB  654 GiB  651 GiB  157 KiB  2.7 GiB  240 GiB  73.15  1.11  136      up          osd.8
11  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  338 KiB  2.7 GiB  471 GiB  73.64  1.12  275      up          osd.11
14  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  336 KiB  2.4 GiB  428 GiB  76.05  1.16  280      up          osd.14
24  small_ssd   0.87329   1.00000  894 GiB  697 GiB  695 GiB  1.2 MiB  2.3 GiB  197 GiB  77.98  1.19  148      up          osd.24
25  small_ssd   0.87329   1.00000  894 GiB  635 GiB  633 GiB  1.0 MiB  1.9 GiB  260 GiB  70.96  1.08  134      up          osd.25
-9             10.47958         -   10 TiB  7.9 TiB  7.8 TiB  2.0 MiB   17 GiB  2.6 TiB  75.02  1.14    -              host pve05
26  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  345 KiB  3.2 GiB  441 GiB  75.35  1.15  278      up          osd.26
27  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  341 KiB  2.2 GiB  446 GiB  75.04  1.14  275      up          osd.27
28  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  337 KiB  2.5 GiB  443 GiB  75.23  1.14  274      up          osd.28
29  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  342 KiB  3.6 GiB  445 GiB  75.12  1.14  279      up          osd.29
30  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  348 KiB  3.0 GiB  440 GiB  75.41  1.15  279      up          osd.30
31  small_ssd   1.74660   1.00000  1.7 TiB  1.3 TiB  1.3 TiB  324 KiB  2.8 GiB  466 GiB  73.95  1.12  270      up          osd.31
                            TOTAL   48 TiB   32 TiB   32 TiB   26 MiB   85 GiB   16 TiB  65.76                                   
MIN/MAX VAR: 0.65/1.19  STDDEV: 10.88

ceph -s

  cluster:
    id:     ceed1fee-9c7a-4150-a9b1-8739848993a9
    health: HEALTH_WARN
            2 daemons have recently crashed
            3 mgr modules have recently crashed
 
  services:
    mon: 4 daemons, quorum pve00,pve01,pve02,pve05 (age 23h)
    mgr: pve00(active, since 47h), standbys: pve01, pve05, pve02
    mds: 1/1 daemons up, 3 standby
    osd: 33 osds: 33 up (since 15h), 33 in (since 5M)
 
  data:
    volumes: 1/1 healthy
    pools:   5 pools, 2113 pgs
    objects: 2.98M objects, 11 TiB
    usage:   32 TiB used, 16 TiB / 48 TiB avail
    pgs:     2113 active+clean
 
  io:
    client:   32 MiB/s rd, 18 MiB/s wr, 2.07k op/s rd, 1.52k op/s wr

Anmerkung: Ich habe gestern die OSDs nach einem Ceph Update neugestartet, die beiden großen Disks haben sehr lange gebraucht und tauchen deshalb als gecrasht auf, selbes gilt für die mgr.

ceph osd pool ls detail

pool 1 '.mgr' replicated size 3 min_size 2 crush_rule 1 object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change 17265 flags hashpspool stripe_width 0 pg_num_max 32 pg_num_min 1 application mgr read_balance_score 30.00
pool 2 'ceph-vm-storage00' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 1024 pgp_num 1024 autoscale_mode on last_change 17489 lfor 0/0/15521 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd read_balance_score 5.80
pool 3 'ceph-fs_data' replicated size 2 min_size 1 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 17217 lfor 0/5323/5321 flags hashpspool stripe_width 0 application cephfs read_balance_score 4.85
pool 4 'ceph-fs_metadata' replicated size 3 min_size 2 crush_rule 1 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 17274 flags hashpspool stripe_width 0 pg_autoscale_bias 4 pg_num_min 16 recovery_priority 5 application cephfs read_balance_score 3.89
pool 5 'small_ssd_storage' replicated size 3 min_size 2 crush_rule 1 object_hash rjenkins pg_num 1024 pgp_num 1024 autoscale_mode on last_change 17198 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd read_balance_score 2.15

2 Pools: einmal mit den beiden 7TB SSDs und einmal ohne, über 2 verschiedene crushmaps. "Performantere VMs (RDSH, SQL, Application, etc) laufen auf dem Pool "small_ssd_storage", der weniger performancehungrige Rest auf dem "ceph-vm-storage00"; Grund: die beiden großen SSDs halten im Verhältnis viel mehr Daten und haben dann erhöhte Latenzen beim Zugriff.


Die Host sind alle auf dem gleichen Patchlevel (via Ansible):

proxmox-ve: 8.3.0 (running kernel: 6.8.12-1-pve)
pve-manager: 8.3.0 (running version: 8.3.0/c1689ccb1065a83b)
proxmox-kernel-helper: 8.1.0
pve-kernel-5.15: 7.4-11
proxmox-kernel-6.8: 6.8.12-4
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.8.12-1-pve-signed: 6.8.12-1
proxmox-kernel-6.8.8-4-pve-signed: 6.8.8-4
proxmox-kernel-6.8.8-1-pve-signed: 6.8.8-1
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
pve-kernel-5.15.143-1-pve: 5.15.143-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
ceph: 18.2.4-pve3
ceph-fuse: 18.2.4-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.2.9
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.0-1
proxmox-backup-file-restore: 3.3.0-1
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.2
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-1
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.0
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1

Vielleicht hat ja jemand zufällig einen Tipp für mich wo mein Fehler liegt oder meine Konfig Murks ist (optimal ist diese natürlich nicht, das ist mir auch bekannt).

 

[Falk R.]

Naja, wo wollen wir anfangen? Die verschiedenen Hosts sind schon mal nicht optimal.
Ceph mit 10 GBit ist per Design keine Rakete.
LACP L2+3 bringt bei Ceph gar nix. Du brauchst L3+4 und der/die Switches müssen das auch mitmachen.
Wenn die OSD lange zum starten brauchen, ist auf dem Host etwas faul, liegt gern auch mal an CPU Überbuchung oder ähnlichem.
Die ungleichmäßige Verteilung der OSDs ist auch sehr suboptimal.

 

[gurubert]

Du hast auch nur zwei OSDs in der Device-Class "large_ssd". Wie soll das funktionieren?

 

[illumina7]

Die ungleiche Verteilung der OSDs hatte ich auch schon in Verdacht und mir schon Gedanken gemacht die über die hosts zu ändern.

Also würde es anstatt LACP L2+L3 mehr Sinn machen Ceph Storage und Public Netz jeweils an eine NIC zu binden und LACP aufzulösen? (Oder einen Switch der L3+L4 kann einzusetzen, dafür habe ich dieses Jahr aber kein Budget mehr).

Die beiden Pools sind auf allen OSDs verteilt, ceph_vm_storage00 umfasst die default group und damit large und small, die andere crushmap umfasst ausschließlich die small_ssds devices.

Edit: cpus sind auf den beiden supermicro maschinen (pve00 und pve01) tatsächlich 1:1,5 überbucht, im Durchschnitt haben die tagsüber so 60-80% Auslastung.

 

[Falk R.]

60-80% Auslastung ist schon sehr ungewöhnlich. Soetwas sehr ich eigentlich nur bei Clustern mit ganz vielen Terminalservern oder VDIs. Wenn du deine Cores tatsächlich nur 1:1,5 überbuchst und so hohe Auslastung hast, wer zieht denn die ganze Performance? Ceph braucht natürlich auch CPU Leistung, obwohl das schon einiges weniger ist als bei ZFS. Ceph performt aber gar nicht mehr, wenn die CPU Latenzen hochgehen. Wie hoch ist denn so der I/O Wait bei dir?
Eventuell auch mal cat /proc/pressure/cpu posten.

 

[illumina7]

Gut geraten, unsere 12 RDSH für ca. 150 User brauchen die Rechenzeit. Wobei 80% der Peak nach oben ist und nicht dauerhaft erreicht wird, da bewegen die sich dauerhaft eher bei 60-70%. I/O Wait im Bereich bis 0,4%, Morgens auch mal bis 0,8% wenn die Userprofile (FSLogix) geladen werden.

Edit:

root@pve00:~# cat /proc/pressure/cpu

some avg10=0.00 avg60=0.00 avg300=0.00 total=135028778174
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Jetzt ist aber auch nichts mehr los, die letzten User arbeiten noch und CPU Auslastung bewegt sich so bei 5-10%. Kann das Morgen nochmal posten wenn Betrieb ist.

 

[itNGO]

Hi,
ich würde mal folgendes in betracht ziehen.

- C-States im Bios abschalten
- mal Gedanken über neuere CPUs machen... Takt (Single-Thread)-Leistung geht bei RDSH immer über Anzahl Cores also evtl. über nen 9274F nachdenken
- Bei der Anzahl OSDs mindestens 25GBe für den Storage-Traffic.. eher 2x25GBe
- Die Samsung SSDs in Rente schicken... die können immer noch kein Datacenter und das merkt man bei RDSH durchaus, wo Werte auf dem Papier nichts mehr bedeuten...

Aber nur eins nach dem anderen testen....

 

[illumina7]

Abend @itNGO,
danke für deine Tipps.
- C States sollten deaktiviert sein, ich prüfe das die Tage nochmal
- Die beiden Supermicro Server sind erst 3 Jahre alt und haben auch noch 2 Jahre Support, die werden uns noch ein Stück erhalten bleiben. Unsere IT ist unerwartet viel gewachsen und war ursprünglich für die Hälfte der aktuellen User konzipiert. Wir sind allerdings eine öffentliche Einrichtung und haben jetzt kein Budget für IT frei im Haushalt (zumindest in der Dimension zwei neue Server zu kaufen), zumal ich eben erst 90 neue Notebooks + USB-C Docks fertig ausgerollt habe.
- 25G Backend Netzwerk könnte ich vielleicht nächstes Jahr durch bekommen, bei 4 25G NICs + passender 25G Switch sind wir ja auch ganz schnell wieder bei 4-5000€. Mein Chef knausert zwar nicht zwingend bei der IT, aber wenn der Haushalt aufgebraucht ist kann er das Budget auch nicht herzaubern, Stichwort: Zweckgebunden.
- Ist mir neu? Magst du das bezüglich Samsung SSD etwas ausführen? Insgesamt sind 4 OSDs Samsung SSDs, darunter auch die beiden 7,68TB Disks PM893 (und 2x 1TB PM883).

 

[itNGO]

Abend @itNGO,
danke für deine Tipps.
- C States sollten deaktiviert sein, ich prüfe das die Tage nochmal
- Die beiden Supermicro Server sind erst 3 Jahre alt und haben auch noch 2 Jahre Support, die werden uns noch ein Stück erhalten bleiben. Unsere IT ist unerwartet viel gewachsen und war ursprünglich für die Hälfte der aktuellen User konzipiert. Wir sind allerdings eine öffentliche Einrichtung und haben jetzt kein Budget für IT frei im Haushalt (zumindest in der Dimension zwei neue Server zu kaufen), zumal ich eben erst 90 neue Notebooks + USB-C Docks fertig ausgerollt habe.
- 25G Backend Netzwerk könnte ich vielleicht nächstes Jahr durch bekommen, bei 4 25G NICs + passender 25G Switch sind wir ja auch ganz schnell wieder bei 4-5000€. Mein Chef knausert zwar nicht zwingend bei der IT, aber wenn der Haushalt aufgebraucht ist kann er das Budget auch nicht herzaubern, Stichwort: Zweckgebunden.
- Ist mir neu? Magst du das bezüglich Samsung SSD etwas ausführen? Insgesamt sind 4 OSDs Samsung SSDs, darunter auch die beiden 7,68TB Disks PM893 (und 2x 1TB PM883).

Zusätzlicher Tipp: Überwachung mit Zabbix
Ein Zabbix-LXC (Linux Container) und ein Zabbix-Proxy, der die Metriken aus den PVEs (Proxmox Virtual Environments) sammelt, könnten dir wertvolle Einblicke geben, wohin die Last deines Systems geht. Falls du noch nichts Derartiges eingerichtet hast, empfiehlt es sich, dies nachzuholen. Mit diesen Tools kannst du die Daten grafisch aufbereiten, um:
• Lastverteilung zu analysieren: Erkennen, welche Komponenten die meiste Last erzeugen.
• Leistungsschwankungen zu identifizieren: Feststellen, ab wann die Last das System in die „iowait-Hölle“ treibt.

Budgetplanung und Personalaufstockung
Zum Thema Budget kann ich leider keine konkreten Aussagen treffen. Allerdings möchte ich betonen, dass bei einer Erweiterung der Personaldecke auch die damit verbundenen Nebenkosten berücksichtigt werden müssen. Mehr IT-Mitarbeiter bedeuten:

• Erhöhte Personalkosten: Diese sollten im Budget eingeplant werden.
• Zusätzliche Ressourcen: Infrastruktur, Softwarelizenzen und andere Kostenfaktoren steigen entsprechend.

Dies ist lediglich meine persönliche Einschätzung und hilft dir nicht weiter.

CEPH und CPU-Ressourcenmanagement
Bei der Nutzung von CEPH erzeugt jeder OSD (Object Storage Daemon) einen Prozess, der die Auslastung eines CPU-Kerns verursacht. Wenn du viele OSDs hast und CEPH horizontal skalieren möchte, klingt das zunächst gut. Allerdings haben wir folgende Erfahrungen gemacht:

• Optimale Anzahl der OSDs: Weniger, aber leistungsstärkere OSDs bieten oft einen besseren Kompromiss in hyperkonvergierten Systemen.
• CPU-Ressourcen der VMs: Deine virtuellen Maschinen benötigen ebenfalls CPU-Kapazitäten. Beispielsweise, wenn du pro VM 1 bis 1,5 vCPUs zuweist, stellt sich die Frage:
• Verfügbare CPU-Kerne für OSDs: Wo bleiben die Ressourcen für die OSD-Prozesse?
• Überbuchung der CPU-Kerne: Eine höhere Anzahl an OSDs kann zu einer Überbuchung führen, die die Systemleistung beeinträchtigt

Samsung SSDs und RDSH (Remote Desktop Session Host)
Bezüglich Samsung SSDs und RDSH möchte ich Folgendes anmerken:

• RDSH-User-Sessions: Diese erzeugen viele kleine, zeitkritische Transaktionen. Benutzer nehmen die Performance hier anders wahr als beispielsweise bei einem Mail-Server.
• Leistung von Samsung SSDs:
• Paralleler Zugriff: Samsung SSDs sind nicht besonders effizient bei parallelen Zugriffen durch mehrere Benutzer.
• Benchmark vs. Realität: Standard-Benchmarks spiegeln diese spezifischen Nutzungsszenarien nicht wider. Tatsächlich zeigt sich die Leistungsfähigkeit erst im realen Einsatz mit VMs.

Ich würde mir den Zoo tatsächlich ganz gerne mal ansehen wenn so ein Moment mit schlechter Performance ansteht....

 

[Falk R.]

Also noch mal meine Meinung zum Thema.
Die CPU sah am Abend gut aus, check den Pressure mal wenn was los ist.
Wenige Leistungsfähige SSDs finde ich auch besser. z.B. 4x 7,6 TB Pro Host ist ganz gut.
Die Samsung sind nicht alle schlecht. Die U.2 Modelle sind schon OK, nur die m.2 Modelle sind nicht so prickelnd.

Beim nächsten Mal schnelles Netzwerk und hoch getaktete CPUs, die helfen auch bei ceph, um die Latenz zu senken.

Zu thema parallele Zugriffe. Bei vielen VMs und Ceph, hast du eh ganz viele kleine Random I/Os, da ja auch jedes OS ständig logs schreibt. Da müssen die SSDs eh immer abliefern, nicht nur bei RDSH.

 

[illumina7]

Moin, gestern hatte ich leider keine Zeit zu Antworten.

Also vorgestern Abend habe ich noch die LACP Interfaces aufgelöst und jeweils eine NIC im Backend für Ceph Pub/Cluster konfiguriert.
Zusätzlich habe ich manuell einen Deep Scrub durchlaufen lassen.
Nochmal auf Jumbo Frames geprüft, hat auf einem Node tatsächlich nicht funktioniert, macht aber im Ergebnis keinen Unterschied.
Das hat mehrere Auswirkungen:
- Ceph Seq Reads sind um ca. 400MB/s eingebrochen
- Ceph Seq Writes um 3-400MB/s gestiegen
- IOPS unverändert niedrig

Ich habe jetzt schon des öfteren gelesen, dass ein Ceph Cluster ab 5 Nodes nochmal einen ordentlichen Boost bekommt, 2-4 Nodes läuft vergleichsweise eher so Meh. Kann das jemand bestätigen? Ich könnte noch einen 5. Node in den Cluster hängen, müsste nur vorher die OSDs etwas umverteilen.

Nochmal unter typischer Last alle 4 Nodes:

root@pve00:~# cat /proc/pressure/cpu
some avg10=4.41 avg60=4.58 avg300=4.95 total=137504671811
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

root@pve01:~# cat /proc/pressure/cpu
some avg10=4.37 avg60=4.49 avg300=5.06 total=71661051585
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

root@pve02:~# cat /proc/pressure/cpu
some avg10=0.81 avg60=1.10 avg300=1.11 total=518682841409
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

root@pve05:~# cat /proc/pressure/cpu
some avg10=0.07 avg60=0.07 avg300=0.02 total=38708257613
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Auszug aus CheckMK (35 Tage):


pve00 steht immer exemplarisch auch für pve01, da deren Last praktisch identisch ist. Die beiden kleinen Nodes fallen eigentlich kaum ins Gewicht, da die sehr wenig Last haben.

 

[itNGO]

Moin, gestern hatte ich leider keine Zeit zu Antworten.

Also vorgestern Abend habe ich noch die LACP Interfaces aufgelöst und jeweils eine NIC im Backend für Ceph Pub/Cluster konfiguriert.
Zusätzlich habe ich manuell einen Deep Scrub durchlaufen lassen.
Nochmal auf Jumbo Frames geprüft, hat auf einem Node tatsächlich nicht funktioniert, macht aber im Ergebnis keinen Unterschied.
Das hat mehrere Auswirkungen:
- Ceph Seq Reads sind um ca. 400MB/s eingebrochen
- Ceph Seq Writes um 3-400MB/s gestiegen
- IOPS unverändert niedrig

Ich habe jetzt schon des öfteren gelesen, dass ein Ceph Cluster ab 5 Nodes nochmal einen ordentlichen Boost bekommt, 2-4 Nodes läuft vergleichsweise eher so Meh. Kann das jemand bestätigen? Ich könnte noch einen 5. Node in den Cluster hängen, müsste nur vorher die OSDs etwas umverteilen.

Nochmal unter typischer Last alle 4 Nodes:





Auszug aus CheckMK (35 Tage):
View attachment 78733

pve00 steht immer exemplarisch auch für pve01, da deren Last praktisch identisch ist. Die beiden kleinen Nodes fallen eigentlich kaum ins Gewicht, da die sehr wenig Last haben.

Hi,

du kannst natürlich am Symptom rumm-popeln, entschuldige den Ausdruck, und da mehr Nodes anhängen und die OSDs "breiter" verteilen. Das wird dich aber mit 10GBe nicht wirklich weiter bringen.... Wir benutzen im Datacenter "tonnen" von 3-Node-Hyper-Converged PVE-Ceph-Cluster.... die fackeln tausende von ERP-Nutzern gemütlich ab. Die Nodes sind dann immer "ver-meshed" für CEPH mit minimum 25GBe bei SSDs oder teils mit 100GBe und NVMEs. Da bencht crazy schnell....

Cephs IO-Performance steht und fällt mit der Netzwerklatenz. Ceph kann kein RDMA, zumindest in PVE nicht ohne erhebliche "Anpassungen". Da heisst jede kleinste "varianz" im Storage-Netz kostet Performance. Und dann sind deine IOPS halt im Keller unterhalb der Bodenplatte.... ;-)

Ein Versuch wäre, wenn du mit 3 Nodes auskommst, diese 3 Nodes im Storage-Bereich per MESH zu verdrahten und so etwaige "gammel-switche" aus der Logik zu entfernen. (https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server)

Ich vermute aber bei der Menge der OSDs und 10GBe eh wenig chancen, zumal deine CPUs halt auch nicht sonderlich "Takt-freudig" sind...

Evtl. könnte es noch etwas bringen die VMs mit CPU-Limit zu versehen... Beispiel 4vCPUs und max 6 Host-CPUs. Dann bleibt etwas mehr für die Ceph-Dienste. Das kann unter umständen eher was bringen als den VMs unnötig viele CPU-Kerne zu geben die dann eh nur "iowait"-idlen....

Gruß

 

[illumina7]

Danke wieder mal für deine fachliche Einschätzung, du hast ja deutlich mehr Erfahrung und Wissen zu Ceph/HCI Clustern.

Ich habe nur mir der Argumentation bezüglich 25G Netzwerk ein Problem: auf unserem Backend/Storage Netz passiert den ganzen Tag nicht viel, es ist jetzt nicht so, dass das die ganze Zeit 100% ausgelastet ist, es sieht eher so aus:

Public Network pve00:


Cluster Cluster pve00:


Also da passiert aus mir unbekannten Gründen nicht viel.
Klar habe ich jetzt einen eher suboptimalen Switch im Einsatz, aber auch die Latenz ist jetzt nicht ultra schlecht:


Deswegen vermute ich eigentlich, dass ich irgendwo die Nadel im Heuhaufen suche aber nicht finden kann.

Edit:
Ich möchte an der Stelle nochmal die Problematik zusammenfassen:
- Kein io wait
- Kein cpu wait
- Netzwerk praktisch ungenutzt
- 2/4 hosts idlen annähernd
- benchmark read schnell, am 10G Limit
- benchmark write langsam, sehr wenig IOPS
- Bei den VMs kommt praktisch keine Storage Performance an
- Beim Rebalancing ist die volle Performance da, durchgehend am 10G Limit
- was übersehe ich?

 

[itNGO]

Danke wieder mal für deine fachliche Einschätzung, du hast ja deutlich mehr Erfahrung und Wissen zu Ceph/HCI Clustern.

Ich habe nur mir der Argumentation bezüglich 25G Netzwerk ein Problem: auf unserem Backend/Storage Netz passiert den ganzen Tag nicht viel, es ist jetzt nicht so, dass das die ganze Zeit 100% ausgelastet ist, es sieht eher so aus:

Public Network pve00:
View attachment 78739

Cluster Cluster pve00:
View attachment 78740

Also da passiert aus mir unbekannten Gründen nicht viel.
Klar habe ich jetzt einen eher suboptimalen Switch im Einsatz, aber auch die Latenz ist jetzt nicht ultra schlecht:
View attachment 78741

Deswegen vermute ich eigentlich, dass ich irgendwo die Nadel im Heuhaufen suche aber nicht finden kann.

Edit:
Ich möchte an der Stelle nochmal die Problematik zusammenfassen:
- Kein io wait
- Kein cpu wait
- Netzwerk praktisch ungenutzt
- 2/4 hosts idlen annähernd
- benchmark read schnell, am 10G Limit
- benchmark write langsam, sehr wenig IOPS
- Bei den VMs kommt praktisch keine Storage Performance an
- Beim Rebalancing ist die volle Performance da, durchgehend am 10G Limit
- was übersehe ich?

Technische Analyse und Empfehlungen zur Systemoptimierung

Es tut mir leid, aber ich muss einige kritische Punkte ansprechen. Lass uns diese im Detail betrachten.

Grundprinzipien der IT

In der IT arbeiten wir grundsätzlich mit den binären Zuständen 0 und 1. Es gibt wenig Raum für Vermutungen, da alles auf klaren Fakten basiert. Abweichungen davon, wie der Glaube an einen “Geist in der Maschine” oder die Nutzung von Quantenprozessoren, liegen außerhalb unseres aktuellen Kontextes.

Monitoring und Datenabruf

Fakt: Wie oft holt dein Monitoring-System die SNMP-Daten vom Switch? Alle 10, 30 oder 60 Sekunden?

Analyse: Eine solche Abfragefrequenz ist nur begrenzt aussagekräftig. Sie eignet sich gut für Durchschnittswerte, jedoch erfasst du damit Peaks nur zufällig. Ein 8 GBit Peak wird bei der Datenglättung leicht untergehen, da nicht die Dauerlast, sondern die kurzfristigen Spitzen die Gesamtleistung beeinflussen.

Netzwerklatenz und I/O-Performance

Fakt: Dein Ping-Test zeigt eine ausreichende Latenz für ein Storage-Netzwerk, das über einen 10GBe-Switch verbunden ist. Die gemessene Zeit beeinflusst jede einzelne I/O-Operation. Das bedeutet, dass deine SSDs, die bereits eine gute Latenz bieten, zusätzlich die Paketlaufzeit berücksichtigen müssen. Hinzu kommen die Anzahl der OSDs und PGs (Placement Groups), die an einer Operation beteiligt sind.

Ergebnis: Dies führt schnell zu einer erheblichen Belastung des Systems.

Beispiel für hohe Latenzen im Demo-Cluster

root@RZA-GENOA1:~# ping 10.255.190.12
PING 10.255.190.12 (10.255.190.12) 56(84) bytes of data.
64 bytes from 10.255.190.12: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 10.255.190.12: icmp_seq=2 ttl=64 time=0.055 ms
64 bytes from 10.255.190.12: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 10.255.190.12: icmp_seq=4 ttl=64 time=0.047 ms
64 bytes from 10.255.190.12: icmp_seq=5 ttl=64 time=0.048 ms
64 bytes from 10.255.190.12: icmp_seq=6 ttl=64 time=0.047 ms
64 bytes from 10.255.190.12: icmp_seq=7 ttl=64 time=0.052 ms
64 bytes from 10.255.190.12: icmp_seq=8 ttl=64 time=0.051 ms

Hardware-Konfiguration der OSDs

Fakt: Du betreibst OSDs auf gemischten Hardware-Nodes. Eine I/O-Operation kann niemals schneller sein als die langsamste Komponente innerhalb der beteiligten OSDs oder PGs.

Fazit: Diese Konfiguration ist im Standardbetrieb oder für Testumgebungen akzeptabel. Für den produktiven Einsatz empfehlen Proxmox, Microsoft mit Hyper-V oder VMware den Einsatz identischer Server für Cluster, um eine konsistente Leistung zu gewährleisten. Intermixed-Hardware stellt einen suboptimalen Kompromiss dar.

Herausforderungen bei der Netzwerk- und CPU-Zuweisung

Es ist unklar, wie die NICs am jeweiligen PCIe-Bus angebunden sind, welche CPUs oder RSS-Nodes den jeweiligen Boards zugewiesen sind und ob dies möglicherweise auf einzelnen Nodes unterschiedlich konfiguriert ist. Wenn man die Kommunikation über alle PGs, OSDs und Nodes betrachtet, um die Datenherkunft zu bestimmen, kann dies unter Last zu erheblichen Leistungseinbußen führen.

Empfehlungen zur Problemlösung

1. Reduzierung der Switch-Komplexität:
• Entferne den Switch aus der kritischen Logik und konzentriere dich auf die drei leistungsstärksten Nodes.
• Weise diese Nodes ausschließlich für Storage- und Ceph-Cluster-Kommunikation zu und implementiere Routing.
• Messe, teste und beobachte die Leistung erneut.


2. Anpassung der MTU:
• Erhöhe die MTU auf 9000, sofern deine NICs dies korrekt unterstützen.
• Messe, teste und beobachte die Auswirkungen dieser Änderung.


3. Optimierung der OSDs:
• Reduziere die Anzahl der SSDs bzw. OSDs auf die schnellsten und größten Einheiten mit 10 GBe-Anbindung.
• Drei SSDs können theoretisch bis zu 1,2 GB/s leisten. Bei 7 bis 9 OSDs pro Node über 4 Nodes ist die Auslastung problematisch.
• Ein Sizing von 3 bis 4 OSDs oder 6 bis 8 OSDs auf 3 bis 4 leistungsstarken SSDs wäre realistischer und könnte im Benchmark etwa 25k IOPS erreichen.

4. Feinabstimmung der BlueStore-Parameter:
• Justiere die BlueStore-Parameter in der ceph.conf vorsichtig, um die Leistung weiter zu optimieren.

Zusammenfassung:

Um die Performance und Stabilität deines Ceph-Clusters zu verbessern, empfehle ich eine Reduzierung der Komplexität in der Hardware-Konfiguration, eine Optimierung der Netzwerkparameter sowie eine gezielte Auswahl und Reduzierung der OSDs. Diese Maßnahmen sollten helfen, die Belastung des Systems zu verringern und eine konsistentere Leistung zu gewährleisten.

Falls du weitere Fragen hast oder Unterstützung bei der Umsetzung benötigst, stehe ich dir gerne zur Verfügung.

Besten Gruß

 

[Falk R.]

Nochmal unter typischer Last alle 4 Nodes:

root@pve00:~# cat /proc/pressure/cpu
some avg10=4.41 avg60=4.58 avg300=4.95 total=137504671811
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Bei dem CPU Pressure haben auch automatisch die OSD Deamons mehr Latenz, was bei deinem Setup nicht zuträglich ist.

root@pve01:~# cat /proc/pressure/cpu
some avg10=4.37 avg60=4.49 avg300=5.06 total=71661051585
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

root@pve02:~# cat /proc/pressure/cpu
some avg10=0.81 avg60=1.10 avg300=1.11 total=518682841409
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Bei den beiden sieht das gut aus.

root@pve05:~# cat /proc/pressure/cpu
some avg10=0.07 avg60=0.07 avg300=0.02 total=38708257613
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Ich empfehle aus Latenzgründen immer 25/100G. 40G ist auch nur 4x10G und von der Latenz nicht so gut.
Ceph profitiert auch von CPUs mit hoher Taktrate, damit hast du auch geringere Latenzen.
Also wenn das Budget 4 GHz CPUs zulässt, dann lieber die als 2 GHz.

 

[illumina7]

Moin, danke nochmal für eure umfangreichen Ausführungen, ich denke ich habe jetzt den Zusammenhang zwischen Ceph/OSDs/Bandbreite/IOPS verstanden. Bin nur die Tage nicht dazu gekommen mich damit zu beschäftigen

Ich könnte jetzt noch bisschen Hardware bestellen, aber bevor ich jetzt wieder Mist bestelle frage ich hier nochmal nach, zwei mögliche Optionen:
- Pro Server auf 2x25G Ceph/Backend Netzwerk wechseln oder
- Pro Server auf 1x100G Ceph/Backend Netzwerk wechseln?

Sind MikroTik Cloud Router Switches ausreichend für Ceph?
z.B. https://www.omg.de/mikrotik/cloud-r...-cloud-router-switch-crs504-4xq-in_25856_5236
oder für 25G: https://www.omg.de/mikrotik/cloud-r...ud-router-switch-crs510-8xs-2xq-in_27314_5500
(bräuchte halt jeweils 2 Stück, aber das ist kein Problem, andere 25G oder 100G Switches sind ja deutlichst teurer)

Als 100G Netzwerkkarten würde ich zu diesen greifen:
https://www.servershop24.de/hpe-mcx515a-ccat-100g-netzwerkkarte/a-131758/

Hab schon paar Mellanox NICs problemlos im Einsatz, sollte ich bei den Kabeln noch etwas spezielles beachten?

 

[itNGO]

Moin, danke nochmal für eure umfangreichen Ausführungen, ich denke ich habe jetzt den Zusammenhang zwischen Ceph/OSDs/Bandbreite/IOPS verstanden. Bin nur die Tage nicht dazu gekommen mich damit zu beschäftigen

Ich könnte jetzt noch bisschen Hardware bestellen, aber bevor ich jetzt wieder Mist bestelle frage ich hier nochmal nach, zwei mögliche Optionen:
- Pro Server auf 2x25G Ceph/Backend Netzwerk wechseln oder
- Pro Server auf 1x100G Ceph/Backend Netzwerk wechseln?

Sind MikroTik Cloud Router Switches ausreichend für Ceph?
z.B. https://www.omg.de/mikrotik/cloud-r...-cloud-router-switch-crs504-4xq-in_25856_5236
oder für 25G: https://www.omg.de/mikrotik/cloud-r...ud-router-switch-crs510-8xs-2xq-in_27314_5500
(bräuchte halt jeweils 2 Stück, aber das ist kein Problem, andere 25G oder 100G Switches sind ja deutlichst teurer)

Als 100G Netzwerkkarten würde ich zu diesen greifen:
https://www.servershop24.de/hpe-mcx515a-ccat-100g-netzwerkkarte/a-131758/

Hab schon paar Mellanox NICs problemlos im Einsatz, sollte ich bei den Kabeln noch etwas spezielles beachten?

Ein Ceph-Netzwerk ohne Redundanz zu betreiben, ist für mich inakzeptabel. Daher empfehle ich entweder den Einsatz von Netzwerkkarten mit zwei 100 GBit Ports oder, falls das Budget begrenzt ist, mit zwei 25 GBit Ports zu arbeiten.

Mellanox gilt als der De-facto-Standard in puncto Zuverlässigkeit und Performance. Bei den “gelabelten” Karten bin ich stets vorsichtig, da sie häufig mit eigener Firmware versehen werden, was zu unvorhersehbaren Ergebnissen führen kann – von einwandfreier Funktion bis hin zu schwerwiegenden Problemen. Es ist daher ratsam, Original-Stock-Karten zu verwenden.

Einen Router für die Anbindung würde ich hingegen nicht empfehlen, selbst wenn er als Switch fungieren kann. Solche Geräte bringen oft unnötige Software mit sich, die potenziell weitere Probleme verursachen könnte.

 

[illumina7]

Soweit mir bekannt kann man die MikroTik Cloud Router Switches wahlweise entweder mit dem SwitchOS oder RouterOS booten, da gibts dann jeweils keine Einschränkungen. Hab den ein oder anderen MikroTik schon länger im Einsatz und absolut noch nie Probleme oder Schwierigkeiten damit gehabt.
Ist die Frage ob die Latenzen passen, Arista, FS, Dell usw. sind alle raus, da zu teuer. Ich habe jetzt noch ein kleines Budget raushandeln können, wie schon geschrieben ist das in öffentlichen Einrichtungen nicht immer so einfach, da sind unserer GF dann auch die Hände gebunden, da hängen ja noch mehr Gremien an einer Budgetierung.

Dann werde ich lieber mit der 2x25G Variante fahren, da die 2x100G Variante leider mein Budget sprengt.

Thema Kabel? Was ist zu Beachten?

 

[itNGO]

Thema Kabel? Was ist zu Beachten?

Ich mach jetzt keine Werbung, aber die tun es bei uns ganz gut....
https://eu.store.ui.com/eu/en/categ.../uacc-dac-qsfp28?variant=uacc-dac-qsfp28-0.5m

Aber im Prinzip geht wohl jedes qsfp28 100GBe.... oder der 25gbe pendant.... (hatte überlesen das du ja jetzt doch 25GBe nimmst)

 

[Falk R.]

Hi, hier gibts wieder ganz viele Vermutungen zu den MikroTik Switches.
Den CRS 504 habe ich auch zuhause und allgemein nutze ich die CRS5xx Switches gern für Ceph.
Die großen gibts nur mit RouterOS, also man könnte die von der Software her theoretisch zum Router machen, aber macht keinen Sinn, da die Switches nur einen Highspeed Switch Chip haben. Für Routing gibts ja extra CCR (Router). Der Name Cloud Router Switch bedeutet nur, dass du einen Layer3 Fähigen Switch kaufst.

Ohne Redundanz geht aber mal gar nicht, die MikroTik können auch MLAG. Nicht stressen lassen, dass einige Leute im Netz, das MikroTik MLAG als instabil bezeichnen. In Komplexen Netzwerken, kann MLAG echt Probleme machen, aber das liegt am protokoll und nicht an MikroTik. Wenn du die CRS dediziert als Storage Switches betreibst, läuft das super Stabil.