Schwer fassbare "Performance" Probleme mit virtualisiertem Server

[Ingo S]

Moin alle zusammen

Wir haben hier in unserem Cluster ein sehr schwer dingfest zu machendes Problem.

Spoiler: Technische Infos zur Systemumgebung:

PVE Umgebung (wo das Problem bestand)

• 6 Server
• Heterogene Landschaft mit versch. Xeon E5 v4, 8 bis 48 Kerne, 2,1-3,5GHz
• 128GB RAM / Node
• Ceph Storage via 10Gbit Ethernet auf Kioxia SAS SSDs
• 10GBit Ethernet Usernetz

Ersatz/Test PVE Host (Wo es jetzt läuft):

• Single Server
• Xeon E5 v4, 8 Core, 3,5GHz
• 48GB RAM
• RAID 10 HDD Storage
• 10GB Ethernet Usernetz

vServer:

• 8 Kerne
• 24GB RAM
• 10GBit Ethernet
• Ubuntu 20.04
• Postgresql Datenbanksystem

Internet:

• 100Mbit synchron Glasfaser
• RTT zu fiskal.cloud ca. 7-9ms
• Erreichbarkeit fiskal.cloud in den letzten Wochen: 100%, nicht ein Paket ist verloren gegangen.

Wir hatten einen Server für ein komplexes Kassen/Warenwirtschaftssystem auf Baremetal. Diesen haben wir vor einigen Wochen mithilfe des Herstellers der Software auf unsere PVE Plattform migriert.
Aufgrund gesetzlicher Vorschriften müssen Zahlungsvorgänge in Bar manipulationssicher gespeichert werden. Dies erledigt ein Dienst, den der Hersteller in Zusammenarbeit mit "deutsche Fiskal" auf unserem Server eingerichtet hat.
Der Ablauf ist folgender:
Barvorgang findet statt -> System erzeugt Beleg -> Belegt geht zur fiskal.cloud -> fiskal.cloud signiert und speichert -> Antwort geht an System zurück -> Kundenbeleg wird gedruckt.

Das Problem:
Seit dem Umzug vom Blech auf PVE haben wir sporadisch Probleme mit den Antwortzeiten der deutsche Fiskal.
Seit dem Umzug gibt es immer wieder Zufällig Vorgänge, bei denen die Antwort von der deutsche Fiskal erheblich länger dauert, bis sie beim System eingeht. ich habe Statistiken geführt. 20% aller Vorgänge bekommen erst nach mehr als 3s eine Antwort, und 10% aller Vorgänge werden sogar gar nicht beantwortet.

Unser Monitoring zeigt KEINE Aussetzer der Internetverbindung. Es zeigen sich keine Auffälligkeiten bei der Dauer des Verbindungsaufbaus zur fiskal.cloud. Diese liegen im Bereich von wenigen hundert Millisekunden.
Dennoch bekommen die Mitarbeiter an den Kassen oft Fehlermeldungen, weil die Signatur nicht geklappt hat, oder sie warten mal 10s oder 25 oder bis zum Timeout von 30s auf den Bon. Das ist im Kundenverkehr natürlich untragbar.

Eine Rückfrage bei der deutschen Fiskal hat ergeben, dass die zur Zeit keinerlei Auffälligkeiten haben, konnten aber unsere Logdaten bestätigen und vermuten Probleme mit dem Netzwerk. Diese kann ich aber aufgrund des Monitorings ausschließen.

Und jetzt kommts, weshalb hier Hier danach frage:
Erstmal sieht ja alles nach Internetproblemen oder einem Problem bei der deutsche Fiskal aus. Ich habe aber trotz dessen das wir keine Probleme mit anderen VMs haben, die VM von dem Cluster weg auf einen anderen provisorisch eingerichteten PVE Server außerhalb des Clusters umgezogen und seitdem sind die Probleme weg!

Ich habe so viel getestet und Statistiken erstellt, aber ich habe keine Idee, warum der Server auf dem Cluster so merkwürdige Aussetzer hat.
Hat jemand von euch vielleicht schon mal etwas ähnliches Erlebt? Irgend einen Ansatz wie ich das weiter untersuchen kann?

 

[Falk R.]

Hi Ingo,

monitorst du auch die Laufzeiten zu der VM im LAN? Treten da auch höhere Pinglaufzeiten auf?
Was sagt dein Ceph Netzwerk? 10GBit bei 6 Servern ist nicht so üppig.
Nutzt du LACP auf den Hosts? Wenn ja, was hast du auf Switchseite, Stack, MLAG oder ähnliche Protokolle?
Ich habe schon ganz komische Fehler mit Dell VLT und Cisco VPC gesehen.
Mit mehr Details können wir das bestimmt eingrenzen.

 

[Ingo S]

Moin Falk

Thx für den Input

• Ping Laufzeiten im internen Netz liegen unter 1ms, sowohl zum Gateway als auch zwischen verschiedenen Netzsegmenten über die Firewall. Allerdings habe ich da kein Monitoring drauf. Das könnte ich mal gezielt prüfen. Es wäre aber vermutlich aufgefallen, da wir mit keinen anderen Anwendungen, wie Datenbanken, Webservern etc. Probleme mit sporadischen langen Ladezeiten haben.
• Unser Ceph funktioniert eigentlich zuverlässig. Wir haben 1x 10Gbit für Ceph, 1x 10Gbit User LAN über einen Dual Port Intel X540 SFP Netzwerkadapter und 1x 1Gbit Onboard LAN für Corosync
• Kein LACP oder ähnliches, es ist ein einfacher VLAN Trunk fürs User Netz (darüber gehts auch ins Internet) und ein Access Port für das Ceph Netz.
• Der provisorische Host verwendet den gleichen Netzwerkadapter und ist über den gleichen Switch am Netz angeschlossen.

Vom Gefühl her halte ich Netzwerk für unwahrscheinlich.
Es wird hoffentlich dieses Jahr noch ein neuer Cluster kommen, bei dem wir ein neues Netz bauen und auf 25Gbit upgraden, eben weil es uns nicht ganz reicht, insbesondere was IO angeht.
Aber IO halte ich auch nicht für das Problem, da es auf dem Raid 10 HDD Array jetzt läuft. Der Server wartet ja außerdem scheinbar auf die Antwort von der Fiskal Cloud.

Mein Verdacht ist, das der Server die Antwort zügig bekommt, diese aber in dem Moment nicht verarbeitet bekommt und sie daher auch teilweise erst spät oder gar nicht im Log auftaucht.

Gibt es Phänomene, wo sich verschiedene VMs auf dem selben Node gegenseitig (CPU-)Ressourcen blockieren? Also nicht für µs oder ms, sondern für viele viele Sekunden?
Aufgefallen ist nämlich parallel dazu, dass auch andere Vorgänge auf diesem Server relativ unzuverlässig funktioniert haben. Manchmal kam es vor, dass die ein oder andere Kasse immer mal wieder auf Antwort vom Server wartete. Ist ne Web Anwendung, daher ziemlich robust gegenüber längeren Paketlaufzeiten und nicht ganz so arg auffällig.

 

[Falk R.]

Was unter Linux und Proxmox ganz schlecht zu monitoren ist, sind die CPU Latenzen der VMs (Bei VMware Ready Zeiten).
Eine Überbuchung der CPU ist potentiell gern mal Ursache für ganz komische Probleme.
Wie stark sind denn die Hosts derzeit überbucht? vCores zu physicalCores

 

[Falk R.]

Mal zum Verständnis wie es zu Wartezeiten bei den CPUs kommt:
Angenommenes Setup: 1x Quad Core CPU, 4 VMs 2x2Core, 2x1Core
VM 2vCPU rechnet und reserviert 2 Cores
VM 1vCPU rechnet und reserviert 1 Core
VM 2vCPU will rechnen (10 MHz) braucht aber 2 Cores, da Virtualisierung und keine Emulation - Landet in der Warteschlange da nur 1 Core frei
VM 1vCPU will rechnen, kommt aber 1ns später und hängt dahinter in der Warteschlange

Das ist mal ein mega simples Setup, aber VMs mit viele vCores reservieren nun einmal die pCores. Um so mehr VMs mit vielen vCores auf einem Host sind um so schneller wachsen die Warteschlangen. Ganz schlimm ist auch, dass die Warteschlangen ganz schnell expotentiell anwachsen.

 

[Ingo S]

Uff, ja, das ergibt durchaus Sinn. Je nach Node sind die Maschinen unterschiedlich überbucht. Leider ist unser Cluster sehr heterogen was die Hardware angeht, da die Maschinen damals gar nicht für sowas angeschafft wurden. Gewachsene Strukturen quasi.

2 Nodes haben 48 Threads, die sind auch nicht überbucht, da haben wir ca 0,8v:1p, bei anderen Nodes ist das eher 5v:1p

Aber kann es dann tatsächlich passieren, dass eine VM derart "außer gefecht" ist weil sie auf die Zuteilung von Cores wartet, das Daten verloren gehen? Werden die Prozesse nicht vom Scheduler immer wieder neu zugeteilt udn Netzwerk Traffic gebuffert etc? Ich meine, nur weil eine VM gerade alle pCores verwendet und vll 100% CPU Last erzeugt, reagieren die anderen VMs ja trotzdem noch, ich kann da per SSH drauf etc.

Allerdings passt das Verhalten durchaus dazu.

 

[aaron]

Wie schaut denn die Load Average aus? Ist die ziemlich nahe an den physischen Kernen oder sogar ein wenig darüber?

Was wir hin und wieder im Support sehen, sind ältere Server, bei denen manche Tasks in ein Timeout laufen. Da sind die CPUs dann durchaus ziemlich überbucht. Man darf auch nicht unterschätzen, wie viel Leistung zu viele Kontextwechsel verbraten.
Dass dadurch Netzwerktraffic eine hohe Latenz bekommt, wäre mir noch nicht aufgefallen, aber wer weiß.

Hast du auch mal mit ip -details -statistics address geschaut, ob es irgendwo packet loss gibt?

 

[Falk R.]

Hi Ingo,
die reine CPU Last muss gar nicht so hoch sein. Selbst wenn eine VM mit 8 vCPU nur ein Log schreiben will und 100MHz Last erzeugt, werden natürlich 8 Cores blockiert. Die Aussetzer sind in der Regel auch nicht auf dem Host zu sehen sondern zuerst in den VMs.
Ein ganz typischer Effekt ist bei Terminalservern, der User tippt etwas, aber die Buchstaben erscheinen erst 1-2 Sekunden später. Natürlich sind die Server ansprechbar und reagieren, aber die Anwendungen reagieren ganz unterschiedlich darauf.

Ein 5:1 ist eher ungünstig. Ich habe früher viele Tests auf vSphere gemacht, aber diese sind auch auf HyperV oder KVM übertragbar, da alle nur virtualisieren.
Meine Tests mit einer 16 Core CPU:
64 VMs mit 1 vCPU (1:4) läuft gut
bei VMs mit 8 VCPUs hatte ich mit 3 VMs (1:1,5) die gleichen Latenzen wie bei den 64 Single, bei 4 VMs gingen die CPU Latenzen schon deutlich hoch.

Deshalb versuche ich immer die Physikalischen CPUs mit vielen Cores und bei den VMs die Cores reduzieren auf das tatsächlich benötigte.
Viele machen auch nur 1, 2, 4, 8 cores. Man kann aber auch 3 oder 5 Cores nehmen wenn 2 oder 4 nicht ausreichen.

Bei einigen Kunden habe ich die Epyc 64Core CPUs im Einsatz, durch die vielen Cores skaliert das deutlich besser und man kann da gern mal 80 VMs auf einem Single Socket Server laufen lassen.

P.S: ich würde niemals das Ceph Netzwerk ohne Redundanz betreiben, aber ich bin immer ein Freund von Redundanzen.

 

[Ingo S]

Wie schaut denn die Load Average aus? Ist die ziemlich nahe an den physischen Kernen oder sogar ein wenig darüber?

Die durchschnittliche Load auf den Servern ist weit unterhalb der Core Anzahl. Der Langzeit Wert liegt bei 1,3 auf dem 8 Core Node.

Was wir hin und wieder im Support sehen, sind ältere Server, bei denen manche Tasks in ein Timeout laufen. Da sind die CPUs dann durchaus ziemlich überbucht. Man darf auch nicht unterschätzen, wie viel Leistung zu viele Kontextwechsel verbraten.
Dass dadurch Netzwerktraffic eine hohe Latenz bekommt, wäre mir noch nicht aufgefallen, aber wer weiß.

Es ist ja auch nicht nur hohe Latenz, sondern teilweise (10%) sogar packet loss. Bzw. eigentlich weiß ich nicht ob es packet loss ist. Ich sehe nur, das in den Logs die Antworten aus der Cloud auf den Request einfach fehlen.

Hast du auch mal mit ip -details -statistics address geschaut, ob es irgendwo packet loss gibt?

Muss ich das auf dem Node gucken oder in der VM? In der VM kann ich nicht mehr gucken, da die ja nun schon auf den provisorischen Host umgezogen und daher neu gestartet ist. Auf dem Host wird auf der Schnittstelle vmbr0 angezeigt, das es 0 Fehlerhafte Pakete gab.

RX: bytes           packets      errors  dropped  missed  mcast  
    171167469945    635559443    0       4823740  0       167322104
TX: bytes           packets      errors  dropped  carrier collsns
    45583190119155  878974424    0       0        0       0

Allerdings haben wir unsere Switches im Monitoring. Wenn da auf nem Port viel packet Loss wäre, bekämen wir das auch mit. Den Packetlos auf der virtuellen Bridge zur VM allerdings natürlich nicht.

@Falk R.
Für mich klingt das tatsächlich so, als wäre das das Problem. Zumal auf dem Node auch verhältnismäßig aktive Server zusammen gewerkelt haben, z.B. DB Server, weil das der Node mit der höchsten CPU Clock im Cluster ist.

Wegen Ceph: Ja, im Grunde richtig. In den alten Servern ist leider nicht genug Platz für ein redundantes CEPH Netz gewesen. Im neuen Cluster wird das aber berücksichtigt.

 

[Falk R.]

RX: bytes           packets      errors  dropped  missed  mcast
    171167469945    635559443    0       4823740  0       167322104
TX: bytes           packets      errors  dropped  carrier collsns
    45583190119155  878974424    0       0        0       0

Was wird denn da so viel gedroppt?

Ich sehe gerade, bei mir sind da auch einige dropped pakete.

 

[Ingo S]

Ich gehe davon aus, das sind L2 Broadcast Pakete, die nicht für die Maschine gedacht sind, z.B. VTP, ARP, BPDU etc.

 

[Falk R.]

Eventuell solltest du im Cluster mal besser verteilen.
Ist natürlich leicht gesagt, VMware hat das DRS mit vSphere7 deutlich verbessert und nutzt als Metrik auch die CPU Latenz der VMs.
Dadurch gibt es Hosts die von der CPU Last deutlich höher sind als andere und andere haben deutlich mehr RAM Verbrauch. Aber die VMs laufen alle deutlich besser als bis vSphere6, weil die CPU Latenzen recht ähnlich sind.
Das CRS von Proxmox wird das Problem in der nächsten Version bestimmt noch nicht adressieren können, daher am besten nach vCPU/pCPU ratio verteilen und die dicken VMs möglichst nicht zusammen auf einem Host sondern auch schön verteilen. So entsteht eine Flexiblere Mischung wo der CPU Scheduler der Hosts besser verteilen kann. Dann sollten die Probleme eigentlich schon verschwinden.
Bei viele Kunden habe ich auch Empfehlungen für VM Downsizings gemacht, da die VMs sehr oft nicht so viele Cores benötigen, wie sie haben.
Das entlastet die Hosts auch ganz gut.
Da die VM ja jetzt exklusiv läuft und du keine Probleme hast, könntest du ja zuerst einmal versuchen die VM auf den Host ohne Überbuchung migrieren, da müsste ja auch alles stabil laufen.

 

[Ingo S]

Ja, das werde ich bei Gelegenheit mal Testen. Leider dauert der Umzug des Servers vom Provisorium zum Cluster oder umgekehrt jeweils insgesamt ca 3h. Alles runterfahren, Backups sicherstellen etc. und dann migrieren... Und das alles nach Dienstschluss. Ist daher schwierig, damit zu experimentieren.
Unser Cluster ist leider was RAM etc. angeht relativ ausgereizt. Wir haben noch genug Luft um nen Node frei zu räumen für Wartungsarbeiten.
Von daher ist die Auswahl relativ schwierig, wie die Maschinen verteilt werden können damit die alle noch in den RAM passen. Tatsächlich eine ziemlich tricky Angelegenheit. Insgesamt haben wir 190 vCores zu 126 pCores.

Ich plane daher eigentlich schon mit dem neuen Cluster. Wird Zeit, dass wir den endlich anschaffen, 6 Nodes a 32pCore (64Threads)

 

[Falk R.]

Ich hoffe mal 32core Single CPU, NUMA bringt auch noch Latenzen mit.

 

[Ingo S]

Japp, SIngle CPU. Wir gehen da wohl auf AMD Epyc. Allerdings haben die EPYC auch pro Socket schon mehrere NUMA Nodes.
Z.B. der Epyc 7313 16C/32T hat wohl 4. Das sind dann 4 Cores per Node.
Da würde ich dann dazu tendieren, VMs multiple von 4 als Kerne zuzuweisen und der VM dann z.B. bei 8 Kernen auch 2 NUMA Nodes zu konfigurieren, damit das OS weiß, das da 2 Nodes sind.

Ich weiß nicht wie groß der Performance hit ist. In einem Dokument hatte ich was von wenigen Prozent gesehen. ich glaube die NUMA Topologie ist nicht soooo entscheidend für das Problem hier. Das OS kümmert sich ja auch um eine sinnvolle Zuweisung, so lange genug Kerne zur Verfügung stehen.


( Virtualisierungscluster sind echt nicht einfach im Detail zu verstehen... )
Wieder was gelernt.

 

[Falk R.]

Innerhalb der CPU ist das nicht so tragisch wie wenn man den UPI oder QPI Link nutzen muss.