Überlegungen zu CPU und Speicher

CPU-Typen

Die Einstellung des CPU-Typs ermöglicht die Auswahl basierend auf CPU-Generation und Funktionen, um eine konsistente Funktionalität zu gewährleisten, selbst wenn die private Cloud-Infrastruktur unterschiedliche CPUs verwendet. Eine Live-Migration zwischen Intel- und AMD-CPUs ist jedoch nicht garantiert.

Die Auswahl von „host“ am Ende des Dropdown-Menüs verwendet dieselbe CPU wie der physische Host, was die Effizienz maximiert. Dies verhindert jedoch die Live-Migration zwischen Hosts unterschiedlicher Generationen, was Probleme verursachen kann, wenn in Zukunft neue HRPC-Einheiten zum virtuellen Rechenzentrum hinzugefügt werden.

Die meisten modernen Betriebssysteme funktionieren mit x86-64-v2, das Befehlssätze wie SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT und CMPXCHG16B unterstützt. Die Option x86-64-v2-aes umfasst AES-Verschlüsselungsbefehle, die eine schnellere Leistung für Verschlüsselungssoftware ermöglichen.

Die Auswahl von x86-64-v3 ermöglicht die Nutzung von AVX- und AVX2-Befehlen, während x86-64-v4 Unterstützung für AVX-512-Befehle hinzufügt.

Alle HRPC-Private-Cloud-Modelle ab 6Gt unterstützen x86-64-v4.

Die folgende Tabelle fasst diese Informationen zusammen:

Prozessor	x86-64-v1	x86-64-v2	x86-64-v2-aes	x86-64-v3	x86-64-v4
Unterstützte Befehle	Basissatz x86-64-Befehle	SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B	x86-64-v2 + AES	AVX, AVX2, BMI1, BMI2, FMA, MOVBE	AVX-512-Familie (AVX-512F, AVX-512CD, AVX-512DQ, AVX-512BW, AVX-512VL, etc.)
Intel Xeon	Intel Xeon 3000/5000/7000 Serie (1. Gen)	Intel Xeon 5500 Serie (Nehalem) und später	Intel Xeon 5600 Serie (Westmere) und später	Intel Xeon E3 v3 (Haswell) und später, Intel Xeon E5/E7 v3 (Haswell-EP/EX) und später, Intel Xeon Scalable Prozessoren 1. Gen (Skylake-SP) und später	Intel Xeon Scalable Prozessoren 2. Gen (Cascade Lake-SP) und später, Intel Xeon Scalable Prozessoren 3. Gen (Ice Lake-SP)
AMD Opteron	AMD Opteron 100/200/800 Serie (SledgeHammer)	AMD Opteron 4200/6200 Serie (Bulldozer) und später	AMD Opteron 4300/6300 Serie (Piledriver) und später	Nicht anwendbar	Nicht anwendbar
AMD EPYC	Nicht anwendbar	1. Gen AMD EPYC (Naples)	1. Gen AMD EPYC (Naples)	AMD EPYC 7002 Serie (Rome) und später	AMD EPYC 7003 Serie (Milan) und später

KVM-Speicherverwaltung und Ballooning-Treiber

Kurz gesagt, der Ballooning-Treiber ist in der HRPC-Infrastruktur nicht erforderlich und sollte deaktiviert werden.

In KVM scheint die Einstellung des „Minimalen Speichers“ gleich dem „Speicher“-Wert eine feste Speicherzuweisung zu erstellen. Aufgrund der Natur der Linux-Speicherverwaltung unterscheiden sich jedoch zugewiesener Speicher und tatsächliche Nutzung. Das System reserviert Speicher beim Start, aber er wird nur aktiv genutzt, wenn Daten hineingeschrieben werden, was die Speichernutzung effektiv dynamisch macht.

Dies kann im Abschnitt „Speicherverbrauch“ der Zusammenfassung des Hosts oder der virtuellen Maschine beobachtet werden. Zum Beispiel kann eine virtuelle Maschine, der 32 GiB Speicher zugewiesen wurden, tatsächlich nur 13,56 GiB nutzen.

In einem typischen Proxmox VE-System können virtuelle Maschinen erstellt werden, solange Speicher verfügbar ist. Wenn jedoch der angezeigte „Speicherverbrauch“ niedrig erscheint, könnten Administratoren mehr Speicher zuweisen, als physisch verfügbar ist, was zu einer Überbelegung des Speichers führt. Wenn virtuelle Maschinen plötzlich mehr Speicher benötigen, kann dies Instabilität verursachen und möglicherweise den Out-Of-Memory-Killer im Host-Betriebssystem auslösen, der zufällig kritische Systemprozesse beenden kann.

HRPC 6Gf ist für den Unternehmenseinsatz mit Fokus auf Isolation konzipiert und stellt sicher, dass keine virtuellen Maschinen über die verfügbare Speicherkapazität hinaus erstellt werden können.

Wenn dem Host-Maschine der Speicher ausgeht und das Ballooning-Gerät aktiviert ist, zwingt der Ballooning-Treiber das Gast-Betriebssystem, unnötigen Speicher (z. B. Festplattencaches, Dirty Pages) freizugeben und an das Host-Betriebssystem zurückzugeben. Dieser Prozess erhöht die CPU-Last und die E/A-Operationen, was zu Verzögerungen und Instabilität führt, insbesondere in hochverfügbaren (HA) Systemen, die empfindlich auf Latenz reagieren.

Wie bereits erwähnt, verhindert der benutzerdefinierte Hypervisor in HRPC 6Gf die unnötige Erstellung virtueller Maschinen, wodurch das Ballooning-Gerät in dieser Umgebung weitgehend überflüssig wird.