Aktualizacja Proxmox VE

Aktualizacja Proxmox VE

Aktualizacja Proxmox VE z 8 do 9

Wprowadzenie

Ten dokument opisuje problemy z wydajnością zaobserwowane po aktualizacji klastra Proxmox VE z wersji 8.x do 9.x. Mimo że sama aktualizacja przebiegła pomyślnie, w jej wyniku pojawiły się krytyczne problemy ze stabilnością maszyn wirtualnych (VM) podczas wykonywania zadań backupu.

1. Opis Problemu

Po aktualizacji, w trakcie działania zadań backupu w trybie Snapshot, usługi działające wewnątrz maszyn wirtualnych stawały się niedostępne. Objawiało się to:

  • Przerwami w działaniu aplikacji i timeoutami połączeń.
  • Krytycznymi błędami kernela w logach maszyn wirtualnych:
    • BUG: soft lockup - CPU#X stuck for XXs!
    • rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
  • Komunikatami o wysokim obciążeniu na hoście Proxmox:
    • perf: interrupt took too long (...)

Co istotne, przed aktualizacją do Proxmox 9 te same zadania backupu na tej samej infrastrukturze nie powodowały żadnych problemów.

2. Kluczowa Konfiguracja Systemu

  • Hypervisor: Proxmox VE 9.x (zaktualizowany z 8.x)
  • Storage: LVM na kontrolerze Hardware RAID.
  • Systemy Gościa: Debian 12, Gentoo, CentOS 9.
  • Tryb Backupu: Snapshot.
  • Architektura Backupu: Backup jest tworzony lokalnie na hoście Proxmox, a następnie synchronizowany przez rsync na serwer NAS w sieci biurowej.
  • QEMU Guest Agent: Zainstalowany, zaktualizowany i działający na wszystkich maszynach wirtualnych.

3. Diagnoza Głównej Przyczyny

Główną przyczyną problemu jest regresja wydajnościowa w interakcji Proxmox 9 ze snapshotami LVM. Snapshoty LVM działają w trybie "Copy-on-Write" (CoW), co generuje znaczny narzut i obciążenie I/O. Nowszy kernel lub QEMU w Proxmox 9 zarządza tymi operacjami w sposób, który jest bardziej wrażliwy na opóźnienia, co w połączeniu z obciążeniem wewnątrz VM prowadzi do chwilowego "zagłodzenia" maszyny wirtualnej i jej "zamrożenia" (stun).

4. Zastosowane Rozwiązania

Standardowe metody, takie jak Rate Limit dla backupu, okazały się niewystarczające. Problem ostatecznie rozwiązano, stosując poniższe kroki:

Krok 1: Ustawienie Priorytetu I/O dla Zadań Backupu (Najskuteczniejsza Poprawka)

Najważniejszym krokiem było obniżenie priorytetu I/O dla procesu backupu (vzdump). Zostało to ustawione globalnie na każdym hoście Proxmox przez edycję pliku /etc/vzdump.conf i dodanie linii:

ionice: 8

Wartość 8 odpowiada najniższemu priorytetowi (klasa "Idle"), co sprawia, że proces backupu korzysta z dysku tylko wtedy, gdy inne procesy go nie potrzebują.

Krok 2: Wyłączenie Transparent Huge Pages (THP) w Maszynach Gościa

W ramach optymalizacji i eliminacji błędów soft lockup oraz rcu stall, w systemach operacyjnych maszyn wirtualnych wyłączono Transparent Huge Pages. Odbyło się to przez dodanie parametru transparent_hugepage=never do linii startowej kernela w konfiguracji GRUB.

Krok 3: Zmiana Harmonogramu Backupu

Dodatkowo, aby zminimalizować konflikt o zasoby, zadania backupu zostały przeniesione na godziny nocne (2:00-5:00), gdy aktywność na maszynach wirtualnych jest najniższa.