Performance Probleme

[OnkelD0m]

Hallo liebe Community,

ich habe derzeit das Probleme, dass ich teils bis zu 5 Sekunden Verzögerung auf den VMs habe und finde keinen Fehler. Erst dachten wir, dass es am Netzwerk liegt. Dort allerdings haben wir im Schnitt weniger als 20MB/s an Traffic und die Proxmox Server sind einen 10G Switch mit zwei strängen per LACP verbunden.

Wir haben ein 3 Node Cluster. Davon sind zwei Hosts HPE Server und ein alter Supermicro als Mirror und eine VM mit dem Backup Server.
Die beiden HPE haben folgende Ausstattung:
Typ:
CPU: AMD EPYC 7313 16-Core Processor (2 Sockets)
RAM: 512 GB
OS: 2x 250GB SSD Hardware Raid-1 (proxmox setup)
DATA: 6x 4TB NVMe Hardware Raid-5 (vms, container)

Der Supermicro Server hat einen alten XEON mit 8 Kernen und 16 GB Ram. Hier läuft proxmox ebenfalls auf einem SSD-Raid1 und für die VM's ein Software Raid-5 mit 4x6TB SSD.

Das Netzwerk ist wie folgt angebunden:
2x1G (LACP) für vmbr1 (management)
2x10G (LACP) für alle anderen bridges. Auch das Cluster VLAN

Als Netzwerk Hardware wird Unifi Pro mit einer UDM Pro als Firewall verwendet. Die Systeme hängen alle an einem USW Aggregation 10G Switch.

Proxmox läuft auf 8.2.2

Derzeit liegt meine Vermutung auf dem Hardware Raid-5. Zum einen wurde alles andere schon mehrfach durchleuchtet und ich habe heute herausgefunden, dass jedes mal, wenn wir etwas mehr Daten verschieben, danach auf dem Host massive Performance Probleme bei den VMs auftreten und der Host anfängt zu swappen. Auch schaffen wir bei Migrationen zwischen den HPE's nur maximal 280MB/s.

Hat dieses Phänomen schon einer von euch gehabt und kann mir helfen, irgendwie das Problem besser zu identifizieren?

 

[Falk R.]

Hi ist doch ganz einfach.
Ihr habt garantiert die Standardeinstellungen der Smart Array Controller genommen. Da macht er bei Raid mit SSDs immer SmartPath aktiv. Bei Raid0 oder Raid1 kann man das machen. Bei Raid5 oder 6 bitte auf dem Array Smartpath deaktivieren und dann das Volume mit in den Controllercache aufnehmen. Dann bekommst du auch bis zu 3GB/s aus dem Controller.

 

[OnkelD0m]

Guten Morgen @Falk R. ,

vielen Dank für die schnelle Antwort. Wir werden das heute Abend direkt mal umstellen und testen.
Ist das möglich, ohne das wir den RAID neu aufbauen müssen?

Mein Kollege und ich haben noch nicht so viel mit Hardware Raid Controllern gemacht.

 

[Falk R.]

Das geht natürlich ohne impact und kann man auch im laufenden Betrieb machen, wenn man die HPE SSACLI installiert hat.

 

[OnkelD0m]

Hallo @Falk R. ,

ich habe mir das nette Tool jetzt auf beiden Servern installiert. Da wir leider nur die beiden Produktivsysteme haben, macht es mich etwas Nervös. Ich bin gut in Linux und kann ein wenig Windows und Netzwerk. Die Hardware Ebene habe ich nur selten zu Gesicht bekommen.

Folgendes habe ich jetzt herausbekommen:

Über das ILO habe ich mir über die Infos die Storage Konfiguration angeschaut und dann für das (in meinem Fall) zweite Laufwerk die Daten gezogen.

ctrl slot=12 array B show

HPE SR416i-a Gen10+ in Slot 12
Array: B
Interface Type: NVMe SSD
Unused Space: 1 MB (0.00%)
Used Space: 20.96 TB (100.00%)
Status: OK
MultiDomain Status: OK
Array Type: Data
Smart Path: enable

ctrl slot=12 logicaldrive 2 show

HPE SR416i-a Gen10+ in Slot 12
Array B
Logical Drive: 2
Size: 17.47 TB
Fault Tolerance: 5
Heads: 255
Sectors Per Track: 32
Cylinders: 65535
Strip Size: 128 KB
Full Stripe Size: 640 KB
Status: OK
Unrecoverable Media Errors: None
MultiDomain Status: OK
Caching: Disabled
Parity Initialization Status: Initialization Completed
Last Surface Scan Completed: False
Unique Identifier: 600508B1001C03128F25173858971F6B
Disk Name: /dev/sdb
Mount Points: None
Logical Drive Label: Logical Drive 2
Drive Type: Data
LD Acceleration Method: Smart Path

Gehe ich dann richtig der Annahme, dass ich mit folgendem Befehl den Smart Path deaktiviere?

ctrl slot=12 array B modify ssdsmartpath=disable

Und mit dem folgenden den Cache aktiviere?

ctrl slot=12 logicaldrive 2 modify caching=enable

Muss ich an der Cacheratio etwas ändern? (aus der manpage kopiert)

ctrl slot=12 logicaldrive 2 modify cacheratio=85/15

Als jetzt Frage, muss ich das commiten, oder zieht das sofort an?

Für alle andere, die das Problem mal mit Proxmox haben, hier noch wie ich ssacli isntalliert habe:
echo "deb http://downloads.linux.hpe.com/SDR/repo/mcp bookworm/current non-free" | sudo tee /etc/apt/sources.list.d/hp-mcp.list
sudo apt update
sudo apt install -y ssacli

Es tut mir auch etwas leider, dass ich jetzt so penetrant nerve.

 

[Falk R.]

Hi,
die CLI Kommandos müsste ich erst nachschauen, aber das bekommst du ja anscheinend auch sehr gut alleine hin.
Das Smartpath muss auf dem Array deaktiviert werden.
Der Cache dann wie du geschrieben hast, auf dem logical drive.
Cache setze ich gern auf 90% Write, aber 75/25 ist auch OK.

 

[OnkelD0m]

Vielen Dank,
ich werde heute Abend berichten, ob alles funktioniert hat

Ich habe schon den Anspruch, soweit ich es kann, mich selbst mit den Dingen die ich nutzen muss zu befassen und zu verstehen. Einfach nur Copy&Paste ist nicht ganz so befriedigend.

 

[OnkelD0m]

Ich möchte noch das versprochene Feedback geben.

Leider hat sich auf der Proxmox Ebene selbst nichts verändert. Die Migrationen sind immer noch bei 250-300MB/s. Allerdings hat ein Schreibtest mit DD auf den RAID5 erhebliche Verbesserungen gebracht. Vorher lagen wir bei etwa 1,5 GB/s. Jetzt sieht das ganze so aus:

sudo dd if=/dev/zero of=/tmp/mount/test1.img bs=50M status=progress
36385587200 bytes (36 GB, 34 GiB) copied, 8 s, 4.5 GB/s
761+0 records in
761+0 records out
39898316800 bytes (40 GB, 37 GiB) copied, 8.76001 s, 4.6 GB/s

Danke dafür. Ich hoffe, dass dadurch die Performance probleme besser werden.

 

[Falk R.]

Was für Migrationen meinst du denn? Was genau machst du?

 

[OnkelD0m]

Wir haben auf dein beiden dicken Kisten jeweils lokal ein Raid5 laufen. Wenn ich jetzt eine VM von pve01 zu pve02 migrieren ist bei 300MB/s Ende.
Heute Nacht hab ich aber noch von einer Vermutung geträumt. Dummerweise ist das migrations Netz ein geroutetes Netz. Das ist natürlich sinnfrei.

 

[Falk R.]

Das Migrationsnetzwerk sollte immer Layer2 sein und manchmal hilft es auch das Netzwerk auf insecure zu setzen. Dann wird der Migrationstraffic nicht verschlüsselt. Bei einem abgeschotteten Netz kann man das beruhigt machen.

 

[a.kasper]

Hallo zusammen, @OnkelD0m meint das live migration Feature.

Ich bin gerade im Upgrade von der 8.1.4 zur 8.2.2 und habe auch dasselbe Problem. Zuvor konnte ich mit 3GB/s migrieren (10Gbit/s waren reserviert für anderweite Kommunikation) auf einem 40 Gbit Link (2x40 LACP, ohne Routing) und nun sind es auch nur noch ~300MB/s. Da scheint es ein Problem im aktuellen Release zu geben.

Ich habe die Migration auch extra einmal auf insecure getestet, das macht keinen Unterschied.

Edit: scheint nur ein Anzeigeproblem zu sein. 32GB in 14 Sekunden (Limit für Migrationen waren 3GB/s). Siehe Anhang...

 

[OnkelD0m]

Das werde ich mir die Tage dann auch nochmal genauer anschauen. Danke für den Hinweis.

 

[a.kasper]

Bin heute weiterhin am Cluster Upgrade und stelle fest, dass es doch zu den Limitierungen von ~300Mbit/s kommt bei der Migration. Anscheinend war das eine Log gerade eines das "aus der Reihe " gefallen ist.

Hier ein Auszug aus einer aktuellen Migration:

2024-06-18 10:48:37 migration active, transferred 30.0 GiB of 32.0 GiB VM-state, 302.6 MiB/s
2024-06-18 10:48:37 xbzrle: send updates to 62911 pages in 100.9 MiB encoded memory, cache-miss 20.55%, overflow 806
2024-06-18 10:48:37 auto-increased downtime to continue migration: 200 ms
2024-06-18 10:48:37 average migration speed: 254.1 MiB/s - downtime 40 ms
2024-06-18 10:48:37 migration status: completed
2024-06-18 10:48:41 migration finished successfully (duration 00:02:17)

EDIT: Proxmox hat anscheinend Probleme mit der 40Gbit Karte mit dem neuen Kernel. Hier iperf3 mit Proxmox

[  5] local 10.30.22.35 port 47118 connected to 10.30.22.43 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   278 MBytes  2.33 Gbits/sec    1    324 KBytes
[  5]   1.00-2.00   sec   286 MBytes  2.41 Gbits/sec    1    337 KBytes
[  5]   2.00-3.00   sec   296 MBytes  2.48 Gbits/sec    3    348 KBytes
[  5]   3.00-4.00   sec   284 MBytes  2.38 Gbits/sec    1    348 KBytes
[  5]   4.00-5.00   sec   281 MBytes  2.36 Gbits/sec    0    351 KBytes

Hier Iperf3 innerhalb meines separaten CEPH Clusters:

[  5] local 192.168.100.112 port 55874 connected to 192.168.100.102 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.81 GBytes  24.1 Gbits/sec  105    814 KBytes
[  5]   1.00-2.00   sec  2.94 GBytes  25.3 Gbits/sec  678   1.44 MBytes
[  5]   2.00-3.00   sec  2.83 GBytes  24.3 Gbits/sec  159   1.56 MBytes
[  5]   3.00-4.00   sec  3.03 GBytes  26.0 Gbits/sec   92   1.54 MBytes
[  5]   4.00-5.00   sec  3.07 GBytes  26.4 Gbits/sec   99   1.62 MBytes

 

[Falk R.]

Bin heute weiterhin am Cluster Upgrade und stelle fest, dass es doch zu den Limitierungen von ~300Mbit/s kommt bei der Migration. Anscheinend war das eine Log gerade eines das "aus der Reihe " gefallen ist.

Hier ein Auszug aus einer aktuellen Migration:

2024-06-18 10:48:37 migration active, transferred 30.0 GiB of 32.0 GiB VM-state, 302.6 MiB/s
2024-06-18 10:48:37 xbzrle: send updates to 62911 pages in 100.9 MiB encoded memory, cache-miss 20.55%, overflow 806
2024-06-18 10:48:37 auto-increased downtime to continue migration: 200 ms
2024-06-18 10:48:37 average migration speed: 254.1 MiB/s - downtime 40 ms
2024-06-18 10:48:37 migration status: completed
2024-06-18 10:48:41 migration finished successfully (duration 00:02:17)

EDIT: Proxmox hat anscheinend Probleme mit der 40Gbit Karte mit dem neuen Kernel. Hier iperf3 mit Proxmox

[  5] local 10.30.22.35 port 47118 connected to 10.30.22.43 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   278 MBytes  2.33 Gbits/sec    1    324 KBytes
[  5]   1.00-2.00   sec   286 MBytes  2.41 Gbits/sec    1    337 KBytes
[  5]   2.00-3.00   sec   296 MBytes  2.48 Gbits/sec    3    348 KBytes
[  5]   3.00-4.00   sec   284 MBytes  2.38 Gbits/sec    1    348 KBytes
[  5]   4.00-5.00   sec   281 MBytes  2.36 Gbits/sec    0    351 KBytes

Hier Iperf3 innerhalb meines separaten CEPH Clusters:

[  5] local 192.168.100.112 port 55874 connected to 192.168.100.102 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.81 GBytes  24.1 Gbits/sec  105    814 KBytes
[  5]   1.00-2.00   sec  2.94 GBytes  25.3 Gbits/sec  678   1.44 MBytes
[  5]   2.00-3.00   sec  2.83 GBytes  24.3 Gbits/sec  159   1.56 MBytes
[  5]   3.00-4.00   sec  3.03 GBytes  26.0 Gbits/sec   92   1.54 MBytes
[  5]   4.00-5.00   sec  3.07 GBytes  26.4 Gbits/sec   99   1.62 MBytes

Die Werte sehen aber alle nicht gut aus.
Ich habe zuhause auch die alten Mellanox Connect-X3, und da komme ich mit iPerf bei MTU1500 auf 30,5 GBit und bei MTU9000 auf 31,7 GBit.
Die PCI Anbindung der Karten limitiert das auf 32 GBit.
Auslastung eines Kerns spielt da keine Rolle, iPerf macht auch 100 GBit dicht ohne das viel Last auf der CPU entsteht.

Welche Karte hast du und welche Firmware ist da drauf?

 

[a.kasper]

Ich habe bedingt durch die Anschaffung über längerem Zeitraum verschiedene Karten in Betrieb. Die MTU ist überall 1500 auf den public interfaces.

CEPH Knoten 1-8:

           *-network:0
                description: Ethernet interface
                product: MT27700 Family [ConnectX-4]
                vendor: Mellanox Technologies
                physical id: 0
                bus info: pci@0000:43:00.0
                logical name: enp67s0f0np0
                logical name: /dev/fb0
                version: 00
                serial: b8:59:9f:c3:c5:87
                size: 40Gbit/s
                capacity: 40Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pciexpress vpd msix pm bus_master cap_list rom ethernet physical 1000bx-fd 10000bx-fd 25000bx-fd 40000bx-fd autonegotiation fb
                configuration: autonegotiation=on broadcast=yes depth=32 driver=mlx5_core driverversion=5.14.21-150400.24.60-default duplex=full firmware=12.27.4000 (MT_2130110027) latency=0 link=yes mode=1024x768 multicast=yes slave=yes speed=40Gbit/s visual=truecolor xres=1024 yres=768
                resources: iomemory:2800-27ff irq:109 memory:2807e000000-2807fffffff memory:b4400000-b44fffff

CEPH Knoten 9-13:

           *-network:0
                description: Ethernet interface
                product: Ethernet Controller XL710 for 40GbE QSFP+
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:81:00.0
                logical name: enp129s0f0
                version: 02
                serial: 3c:ec:ef:b7:e0:d5
                size: 40Gbit/s
                capacity: 40Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi msix pciexpress vpd bus_master cap_list rom ethernet physical fibre 40000bx-fd autonegotiation
                configuration: autonegotiation=off broadcast=yes driver=i40e driverversion=5.14.21-150400.24.60-default duplex=full firmware=8.30
0x8000b78d 1.3106.0 latency=0 link=yes multicast=yes slave=yes speed=40Gbit/s

Proxmox Knoten 1-2

           *-network:0
                description: Ethernet interface
                product: MT27700 Family [ConnectX-4]
                vendor: Mellanox Technologies
                physical id: 0
                bus info: pci@0000:c5:00.0
                logical name: enp197s0f0np0
                version: 00
                serial: 04:3f:72:e6:9b:be
                capacity: 56Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pciexpress vpd msix pm bus_master cap_list rom ethernet physical 1000bt-fd 10000bt-fd 25000bt-fd 40000bt-fd 56000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=mlx5_core driverversion=6.8.4-3-pve duplex=full firmware=12.28.1002 (MT_2130110027) latency=0 link=yes multicast=yes slave=yes
                resources: iomemory:1000-fff irq:367 memory:10072000000-10073ffffff memory:b6100000-b61fffff memory:10076000000-100767fffff

Proxmox Knoten 3

           *-network:1
                description: Ethernet interface
                product: Ethernet Controller XL710 for 40GbE QSFP+
                vendor: Intel Corporation
                physical id: 0.1
                bus info: pci@0000:c5:00.1
                logical name: enp197s0f1np1
                version: 02
                serial: 3c:ec:ef:32:e3:f8
                capacity: 40Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi msix pciexpress vpd bus_master cap_list rom ethernet physical fibre 40000bt-fd autonegotiation
                configuration: autonegotiation=off broadcast=yes driver=i40e driverversion=6.8.4-3-pve duplex=full firmware=7.20 0x80008322 1.2585.0 latency=0 link=yes multicast=yes slave=yes
                resources: iomemory:1000-fff iomemory:1000-fff irq:91 memory:10022000000-100227fffff memory:10023008000-1002300ffff memory:b7300000-b737ffff memory:10022c00000-10022ffffff memory:10023110000-1002320ffff

Proxmox Knoten 4-5

          *-network:0
                description: Ethernet interface
                product: Ethernet Controller XL710 for 40GbE QSFP+
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:c5:00.0
                logical name: enp197s0f0
                version: 02
                serial: 3c:ec:ef:b7:d5:64
                capacity: 40Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi msix pciexpress vpd bus_master cap_list rom ethernet physical fibre 40000bt-fd autonegotiation
                configuration: autonegotiation=off broadcast=yes driver=i40e driverversion=6.5.13-1-pve duplex=full firmware=8.30 0x8000b78d 1.2926.0 latency=0 link=yes multicast=yes slave=yes
                resources: iomemory:1000-fff iomemory:1000-fff irq:73 memory:10071800000-10071ffffff memory:10073000000-10073007fff memory:b7380000-b73fffff memory:10072800000-10072bfffff memory:10073010000-1007310ffff

Knoten 5 ist noch auf Kernel Version 6.5.13 da nicht upgegraded, Firmware ist gleich bei 4 und 5

Alle Systeme sind auf je zwei Arista Switchen redundant über LACP angebunden. Der neuere Teil des CEPH Clusters steht in einem zweiten Rack - also ist da nochmals ein Hop zwischen den zwei Arista Stacks.

Messungen (auf dem CEPH Cluster ist allerdings Last drauf)

CEPH
- am selben Arista Stack

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  30.1 GBytes  25.8 Gbits/sec  2115             sender
[  5]   0.00-10.00  sec  30.1 GBytes  25.8 Gbits/sec                  receiver

- über den weiteren Hop

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  32.1 GBytes  27.5 Gbits/sec  2940             sender
[  5]   0.00-10.00  sec  32.1 GBytes  27.5 Gbits/sec                  receiver

Proxmox als Client zu CEPH

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.91 GBytes  2.50 Gbits/sec    0             sender
[  5]   0.00-10.03  sec  2.91 GBytes  2.49 Gbits/sec                  receiver

Proxmox nach Proxmox

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.86 GBytes  2.46 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  2.86 GBytes  2.46 Gbits/sec                  receiver

 

[Falk R.]

Also etwas läuft da tatsächlich nicht richtig.
Was mir zuerst auffällt, bei PVE1+2 hast du 56 GBit stehen. Da hast du die Karten garantiert im Infiniband Modus. Ich empfehle die Karten auf Ethernet Modus umzustellen. Bei den 40G Mellanox müsstest du das mal von Hand prüfen.
Wie hast du denn die Ceph Nodes installiert? Welches OS und welche Paketquelle für Ceph?

Ist das alles in einem Layer2 Netz?

 

[a.kasper]

Also - es sind alle Systeme in einem Layer2 Netz. Zuvor ging alles problemlos mit der 7er Version und auch mit der 6er Version. Ceph rennt seit 5 Jahren mit Croit. Da ist mittlerweile ein SuSE am rennen (zuvor Debian).

Ich habe nun einmal testweise zwei Systeme mit dem 5.15-143-pve Kernel am rennen. Wenn ich zischen diesen beiden Systemen migriere passt de r Speed auch wieder mit reiner Migrationszeit für traffic mit ~4-5 Sekunden bei 16 GB Memory. Die Berechnung ist allerdings anscheinend kaputt (siehe Log).

2024-06-20 12:57:40 start migrate command to tcp:10.30.22.34:60000
2024-06-20 12:57:41 migration active, transferred 397.4 MiB of 16.0 GiB VM-state, 543.8 MiB/s
2024-06-20 12:57:42 migration active, transferred 876.2 MiB of 16.0 GiB VM-state, 466.4 MiB/s
2024-06-20 12:57:43 migration active, transferred 1.3 GiB of 16.0 GiB VM-state, 497.6 MiB/s
2024-06-20 12:57:45 migration active, transferred 1.8 GiB of 16.0 GiB VM-state, 337.5 MiB/s
2024-06-20 12:57:45 average migration speed: 3.2 GiB/s - downtime 134 ms
2024-06-20 12:57:45 migration status: completed
2024-06-20 12:57:49 migration finished successfully (duration 00:00:12)

Hier dann noch der iperf Test der wiederum nicht dasselbe Ergebnis gibt.

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.61 GBytes  4.82 Gbits/sec   92             sender
[  5]   0.00-10.00  sec  5.61 GBytes  4.82 Gbits/sec                  receiver

Das ganze ist irgendwie sehr seltsam und nicht konsistent. Gerade mehrfach dieselbe VM migriert und nun ist wieder alles langsam.

 

[Falk R.]

Da das iperf auch so unterirdisch performt, müsste man das komplette Netzwerksetup unter die Lupe nehmen. Wenn iperf schon mal nicht performt, dann Ceph natürlich auch nicht.