Proxmox VE 8 auf 9 Upgrade
Einleitung
Dieses Dokument beschreibt Performance-Probleme, die nach dem Upgrade eines Proxmox VE Clusters von Version 8.x auf 9.x beobachtet wurden. Obwohl das Upgrade selbst erfolgreich war, führte es zu kritischen Stabilitätsproblemen bei virtuellen Maschinen (VMs) während der Ausführung von Backup-Jobs.
1. Problembeschreibung
Nach dem Update wurden Dienste, die in den virtuellen Maschinen liefen, während der Ausführung von Backup-Jobs im Snapshot-Modus nicht mehr verfügbar. Die Symptome umfassten:
- Anwendungsunterbrechungen und Zeitüberschreitungen bei Verbindungen.
- Kritische Kernel-Fehler in den Logs der virtuellen Maschinen:
BUG: soft lockup - CPU#X stuck for XXs!rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
- Meldungen über hohe Last auf dem Proxmox-Host:
perf: interrupt took too long (...)
Wichtig ist, dass vor dem Upgrade auf Proxmox 9 dieselben Backup-Jobs auf derselben Infrastruktur keine derartigen Probleme verursachten.
2. Wichtige Systemkonfiguration
- Hypervisor: Proxmox VE 9.x (aktualisiert von 8.x)
- Storage:
LVMauf einem Hardware-RAID-Controller. - Gastsysteme: Debian 12, Gentoo, CentOS 9.
- Backup-Modus:
Snapshot. - Backup-Architektur: Backups werden lokal auf dem Proxmox-Host erstellt und dann per
rsyncauf einen NAS-Server im Büronetzwerk übertragen. - QEMU Guest Agent: Auf allen virtuellen Maschinen installiert, aktualisiert und aktiv.
3. Diagnose der Hauptursache
Die Hauptursache des Problems ist eine Performance-Regression in der Interaktion zwischen Proxmox 9 und LVM-Snapshots. LVM-Snapshots arbeiten im "Copy-on-Write" (CoW)-Modus, was einen erheblichen Overhead und eine hohe I/O-Last erzeugt. Der neuere Kernel oder QEMU in Proxmox 9 verwaltet diese Operationen auf eine Weise, die empfindlicher auf Latenz reagiert. Dies führt in Kombination mit der Last des Gastsystems zu einem vorübergehenden I/O-Engpass für die VM und zu deren "Einfrieren" (Stun).
4. Angewandte Lösungen
Standardmethoden wie ein Rate Limit für das Backup erwiesen sich als unzureichend. Das Problem wurde letztendlich durch die folgenden Schritte gelöst:
Schritt 1: Setzen der I/O-Priorität für Backup-Jobs (Effektivste Lösung)
Der wichtigste Schritt war die Herabsetzung der I/O-Priorität für den Backup-Prozess (vzdump). Dies wurde global auf jedem Proxmox-Host durch Bearbeiten der Datei /etc/vzdump.conf und Hinzufügen der Zeile festgelegt:
ionice: 8
Der Wert 8 entspricht der niedrigsten Priorität (der "Idle"-Klasse), was bewirkt, dass der Backup-Prozess die Festplatte nur dann nutzt, wenn andere Prozesse sie nicht benötigen.
Schritt 2: Deaktivieren von Transparent Huge Pages (THP) in Gast-VMs
Als Optimierung und zur Beseitigung von soft lockup- und rcu stall-Fehlern wurden Transparent Huge Pages in den Gast-Betriebssystemen deaktiviert. Dies wurde durch Hinzufügen des Kernel-Parameters transparent_hugepage=never zur GRUB-Konfiguration erreicht.
Schritt 3: Zeitplan der Backups ändern
Zusätzlich wurden die Backup-Jobs in die Nachtstunden (2:00-5:00 Uhr) verlegt, um Ressourcenkonflikte zu minimieren, wenn die Aktivität auf den virtuellen Maschinen am geringsten ist.