Erfahrungsbericht: Vollvirtualisierung mit Proxmox 6.1

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Erfahrungsbericht: Vollvirtualisierung mit Proxmox 6.1

Beitrag von heisenberg » 14.05.2020 13:03:17

Allgemeines

Ich habe vor kurzem einen Proxmox-Cluster hier neu aufgesetzt und möchte darüber das eine oder andere schreiben: Wie ich es aufgebaut habe und was ich dabei gelernt habe. Die Motivation lag für mich darin, dass ich mit Citrix XenServer nicht zufrieden war in einigen Punkten. Das bessert sich zwar jetzt, da das Projekt mit XCP-NG deutlich an Fahrt aufnimmt, aber Proxmox ist immer noch deutlich weiter vorne aktuell.

Ziele
  • Server mit Vollvirtualisierung mittels qemu.
  • Niedrige Hardwarekosten
    • Gebrauchte Server
    • Unterschiedliche CPU-Typen (Intel). Wenn möglich(eher nicht empfohlen!) auch Intel/AMD-CPUs gemischt, weil AMD-CPUs bzgl. Preis-Leistungs-Verhältnis wesentlich besser sind. Allerdings sind hier ausschließlich Server mit Intel-CPUs vorhanden.
    • Lokales Storage (günstiger als zentrales Storage, Vermeidung von SPOF eines Shared-Storage, Vermeidung von Netzwerkanforderung >= 10 GbE)
    • Kosteneffizienter Redundanz-Ansatz.
  • Stabiler Betrieb
  • Stabile Live-Migration mit Storage
  • Failover(Bei Ausfall eines Clusterknotes Start der VM auf einem anderen Clusterknoten) nicht benötigt
  • Einfache Verwaltung
  • Thin Provisioning
  • Snapshots
Hardware

Als Hardware waren die folgenden Komponenten im Einsatz:
  • Server-RAM 144 GB - 256 GB
  • Server-CPU: Multicore Intel-CPU 8 - 20 (Mit Hyperthreading: 16 - 40 Cores)
  • Server-Controller unterschiedlich, Verwendung als HBA
  • Mindestens 4 Netzwerkschnittstellen 1 GBit pro Server
  • OS-SSD 2x 64 GB (8 GB hätte wahrscheinlich auch gereicht)
  • 3x - 11x 3,5" Festplatten (entweder SATA oder SAS) pro Server in einer Größe von 500 GB bis 4 TB, je nach Speicherbedarf
Software

Proxmox 6.1 mit Debian 10 Grundinstallation.

Einrichtung: Festplatten
  • Das Betriebssystem wurde auf ein Root-RAID-1 (Linux Software RAID) installiert. Der Grund dafür ist, dass ich mir die Möglichkeit offen halten will, einfach die Konfiguration der Daten-Festplatten später nochmal zu verändern(z. B. von RAIDZ auf RAIDZ2 oder HW-RAID-Controller-Array) ohne das Betriebssystem umfangreich anpassen zu müssen.
  • Die weiteren Festplatten wurden über ZFS als RAIDZ eingerichtet. Vorzugsweise sollte dabei eine gerade Anzahl von Datenfestplatten verwendet werden(Also RAIDZ(1 Parity Disk) mit 3, 5, 7, 9, 11, ... Festplatten). Die Information habe ich aus einem Forum, was auf eine Solaris-Seite verwies, die nicht mehr online ist. Wenn man dann den Gesamtverbund aus mehreren RAIDZ-Stripes zu je 3,5,7,... Platten verwendet, hat man ein Vielfaches der Schreibleistung eines einzelnen RAIDZ-VDEVs.
  • Das ZFS habe ich dabei direkt gemounted und nicht als ZVols verwendet(Gründe kommen unten).
  • ZFS RAIDZ habe ich statt Linux RAID-5 gewählt, da es in meinen Tests bisher wesentlich schneller war
  • Den onboard SATA-Controller habe ich nur teilweise für das OS verwendet, da dieser meist nur mit einer Lane an den PCI-Express Bus angebunden ist. (Siehe: https://www.unix.com/303045736-post8.html)
  • Den ZFS-ARC habe ich auf 1 GB RAM per 1 TB Nutzdaten begrenzt(z. B. : "options zfs zfs_arc_max=4294967296" in /etc/modprobe.d/zfs.conf)
Einrichtung: Netzwerk
  • 1. Port: Internes Clusternetzwerk
  • 2. Port: Storage- und Backupnetzwerk (2. Ring für das Clusternetzwerk wenn das primäre Netzwerk offline ist)
  • 3. + 4. Port: Public für Dienste nach außen als Linux-Bonding konfiguriert
Das Clusternetzwerk für Corosync ist für Proxmox sehr wichtig. Wenn es ausfällt, kann der Cluster nicht mehr verwaltet werden.(Kein Starten/Herunterfahren von VMs, kein Backup, keine Migration). Als Redundanz wird als 2. Ring das Storage- und Backupnetzwerk verwendet. D. h. fällt das erste aus, wird das zweite benutzt.

Sehr wichtig ist, dass das Clusternetzwerk 100% sauber funktioniert. Ich hatte zunächst einen Server über einen zweiten Switch(separates VLAN) geführt. Dabei habe ich dann Paketverluste bemerkt, was den Cluster deutlich gestört hat. D. h. der abgesetzte Knoten ist öfters mal aus dem Cluster geflogen. Auch Live-Migrationen hatten Störungen und sind abgebrochen bzw. die migrierte VM war dann auf einmal in gestoppten Zustand. Seit der Änderung, dass alle Server an einem Switch hängen und sich dadurch die Netzwerkqualität wesentlich verbessert hat, gibt es keine Störungen mehr.

Einrichtung: Proxmox - Storage

Beim Storage habe ich ein Problem festgestellt, dass bei Live-Migrationen Proxmox den Zielspeicher der VM mit maximaler I/O erst mal vollschreibt. Das führt dazu, dass der Zielserver überlastet wird und auf dem Zielserver laufende VMs abstürzen. Das betrifft LVM, LVM-thin sowie ZFS und ZFS-thin. Da es das "directory" - Storage-Plugin mit qcow2 Dateien nicht betrifft, habe ich das als Storage-Technologie gewählt.

Siehe: https://forum.proxmox.com/threads/usabl ... ode.68138/

qcow2 bietet darüberhinaus Thin-Provisioning und Snapshots.

Einrichtung: Proxmox - Netzwerk

Da ich anfangs noch Cluster- und Storagenetzwerk auf einem Interface gefahren habe, habe ich die Geschwindigkeit von Netzwerkoperationen global auf 50 MB/s begrenzt(/etc/pve/datacenter.conf: bwlimit: default=51200), so dass das 1 GBit Interface nur zur Hälfte ausgelastet wurde.

Dem Netzwerkproblem bin ich u. a. auf die Spur gekommen, indem ich dauerhaft 1 Ping pro Sekunde auf dem Clusternetzwerk zwischen den Servern gesendet und das per Monitoring ausgewertet habe.

Einrichtung: Proxmox - VMs

Als Einrichtung für die VMs ist folgendes wichtig:
  • Discard-Support immer einschalten(Thin-Provisioning!) auch wenn es eine VM aufgrund des Softwarestandes nicht unterstützt. Ggf. kann man die VM herunterfahren und vom Hostsystem aus den Trim ausführen. Windows hat ab Version 7 Discard-Support und regelmässiges Trimming aktiv. Der Trimm findet bei mir jede Nacht einmal statt.
  • Guest-Agent-Support immer einschalten. Das ist speziell für das saubere herunterfahren von Windows-VMs wichtig. Damit der Guest-Agent auch funktioniert, muss man in der VM auch noch eine Installation vornehmen.(Siehe: https://pve.proxmox.com/wiki/Qemu-guest-agent)
  • Als CPU-Variante habe ich immer kvm64 gewählt. Das ist der Basisbefehlssatz. Dabei geht etwas Performance verloren. Allerdings ist mir hier die problemlose Livemigration viel wichtiger. Wenn man maximale Performance haben möchte, dann nimmt man identische CPUs und kann überall den "Host-CPU"-Modus aktivieren. Wenn man den Host-CPU-Modus bei verschiedenen CPUs aktiviert, dann stürzt die VM nach Migration sehr wahrscheinlich ab, wenn sie CPU-Befehle benutzt, die die physikalische CPU nicht unterstützt. Wichtig wird das ganze, wenn man spezifische Anwendungen hat, die durch spezielle Features sehr stark profitieren. Z. B. VPN-Server die Hardware-Krypto-Fähigkeiten der CPU verwenden werden dadurch um Größenordnungen schneller.
Sonstiges

Toll bei Proxmox ist ja, dass direkt ein Backup als sauber Möglichekeit im Kern mit dabei ist. Ansonsten funktioniert das Webinterface einfach gut! Tolle API! mit verschiedenen Möglichkeiten des Zugriffs. Dadurch dass der Unterbau ein Standard-Debian ist, ist man auch sehr flexibel. Auch dist-upgrade ist die Methode zum Aktualisieren auf eine neue Proxmox-Version(Man sollte die Dokumentation zu den Aktualisierungen aber genau durchlesen). Ich bin sehr zufrieden im Moment.

Vorteil der Variante mit ZFS ist, dass, sollte ein Server sterben, dass ich die Platten einfach rausnehmen und in einen neuen Server einbauen und alles mit minimalen Anpassungen wieder hochfahren kann. Dabei gehe ich davon aus, dass das nur funktioniert, wenn ich dort auch wieder den gleichen Controller verwende.

Ich freue mich über konstruktive und/oder authentische Rückmeldungen.

Nachtrag-1

Ich habe an diversen Stellen gelesen, dass man Intel- und AMD-CPUs nicht unbedingt mischen sollte, um die Stabilität der Live-Migration nicht zu beeinträchtigen.

Nachtrag-2

Eigentlich wollte ich die 500 GB Platten schon entsorgen. Da es aber verschiedene Schwerpunkte bei den VMs gibt, kann ich auch die geringe Kapazität durchaus noch gebrauchen. Z. B. für Anwendungsfälle, wo es einfach um mehr I/O geht und weniger um Kapazität. Die Platten sind von der Geschwindigkeit durchaus noch im gleichen Leistungsbereich wie aktuelle Platten. Und grundsätzlich geht es ja darum, eine Balance herzustellen zwischen ausreichend Resourcen aus den Bereichen CPU-Performance, RAM, Storage-Kapazität und Storage-Bandbreite.

Nachtrag-3

Was das Cluster-Setup betrifft(Was hier beschrieben ist https://pve.proxmox.com/wiki/Cluster_Manager):

Nein. Man möchte einen Server nicht neu installieren, wenn man die Node aus dem Cluster entfernt. Ich habe das währen des Setups sehr oft gemacht und die nicht empfohlene Option ohne Neuinstallation durchgeführt. Hat keine Probleme verursacht. Es ist wahrscheinlich nur für Neulinge gedacht, die es nicht richtig machen und um demzufolge unnötigen Fragenaufwand in den Supportkanälen zu reduzieren.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Antworten