Proxmox

VE VergessenBest SiePractices nicht– wichtige Tipps für Installation und Betrieb

Hinweis zum Alter des Beitrags: Diese Sammlung ist über mehrere Jahre aus unserer täglichen Arbeit mit Proxmox VE, ZFS, Backup, Storage und Virtualisierung entstanden. Einzelne Hinweise stammen daher ursprünglich aus älteren Proxmox-Versionen.

Die grundlegenden Empfehlungen und Erfahrungen sind weiterhin aktuell. Wo sich Proxmox VE technisch weiterentwickelt hat, sollte die jeweilige Konfiguration mit der aktuell eingesetzten PVE-Version abgeglichen werden.

Beim Aufbau einer Proxmox VE Infrastruktur gibt es zahlreiche Details, die über eine reine Standardinstallation hinausgehen. Viele Probleme zeigen sich erst im produktiven Betrieb – beispielsweise beim Austausch einer Festplatte, bei ZFS, Backup, Replikation, Updates oder nach einem Boot-Disk-Ausfall.

Die folgenden Punkte basieren auf unseren Erfahrungen aus realen Proxmox-Installationen und Kundenumgebungen.

Festplatten und Hardware dokumentieren

Seriennummern der PlattenFestplatten dokumentieren

Notiert bei der Installation die Seriennummern der Festplatten und deren Position in den Einschüben.

Bei einem späteren Ausfall muss eindeutig erkennbar sein, welche physische Disk zu notieren,einem sonstausgefallenen mussZFS-Gerät mangehört. Fehlt diese Dokumentation, kann im dümmstenungünstigsten Fall deneine Serverzusätzliche herunterfahrenPrüfung oder sogar ein Herunterfahren des Servers notwendig werden, bevor mandie richtige Festplatte sicher einegetauscht Diskwerden tauschenkann.

kann

Hardware-RAID

LVMund bringtZFS imnicht Vergleichvermischen

Wichtig bei ZFS: Hardware-RAID-Controller sollten nicht dadurch als vermeintlicher HBA verwendet werden, dass für jede einzelne Festplatte ein eigenes RAID0 angelegt wird.

Andere haben mit solchen Konstruktionen schlechte Erfahrungen bis hin zu Datenverlust gemacht.

Für ZFS nursollte Nachteileein geeigneter HBA bzw. JBOD-Modus verwendet werden, bei dem ZFS möglichst direkten Zugriff auf die einzelnen Datenträger erhält.

ZFS statt LVM für viele Proxmox-Szenarien

Wir bevorzugen bei unseren Proxmox-Installationen in vielen Fällen ZFS gegenüber klassischem LVM.

ZFS bietet unter anderem Prüfsummen, Snapshots, Replikation, Kompression, Mirrors und RAID-Z sowie umfangreiche Möglichkeiten zur Überwachung des Storage.

Das bedeutet allerdings nicht, dass LVM technisch grundsätzlich ungeeignet ist. Die Wahl des Storage-Systems sollte wegenzum demjeweiligen gernigenEinsatzzweck Leistungsumfangpassen.

vermieden werden Hardware Raid Controller als HBA missbrauchen und einzelne Platten als Raid0 definieren im ZFS Verbund führt zu Datenverlust, nachweislich! Raid 5/6, bzw. ZFS RaidZ1+2 ist

RAID-Z für virtuelle Maschinen nursorgfältig planen

RAID5/RAID6 bzw. ZFS RAIDZ1 und RAIDZ2 sind nicht automatisch die beste Wahl für lazy Daten geeignet

ZFS im EinsatzStorage mit RaidZ1+Z2vielen führtvirtuellen Maschinen.

Bei I/O-intensiven VMs sind Mirrors häufig interessanter. RAID-Z eignet sich dagegen besonders für Workloads, bei einerdenen BlockgrößeKapazität und sequenzielle Zugriffe wichtiger als maximale IOPS sind.

Achtung: Bei ZFS RAIDZ1/RAIDZ2 können Blockgröße, ZVOL-Konfiguration und der Workload erheblichen Einfluss auf Speicherbedarf und Performance haben. Eine unpassende Kombination kann zu deutlichem Overhead führen.

Insbesondere die Einstellungen von defaultvolblocksize, 8kZFS-Pool, aufRAID-Z-Geometrie local-zfsund DatastoreVM-Workload sollten deshalb gemeinsam betrachtet werden.

Proxmox Updates und Repositories prüfen

Bei Proxmox VE sollte geprüft werden, welche Proxmox-Repositories tatsächlich konfiguriert sind.

Je nach Subscription und gewünschtem Update-Kanal stehen unterschiedliche Repositories zur Verfügung. Wer keine Subscription verwendet, muss darauf achten, dass ein geeigneter Proxmox-No-Subscription-Kanal korrekt konfiguriert ist.

Es reicht nicht aus, lediglich die zugrunde liegenden Debian-Paketquellen zu einem Overheadaktualisieren und Verlangsamungdavon vonauszugehen, 50-100%

damit Updatesautomatisch sämtliche Proxmox-Komponenten aktuell zu halten.

SSH mit Public-Key-Authentifizierung absichern

Für administrative SSH-Zugänge sollte nach Möglichkeit Public-Key-Authentifizierung anstelle eines reinen Passwort-Logins verwendet werden.

Zusätzlich sollte geprüft werden, ob Passwort-Login für administrative Benutzer vollständig deaktiviert werden kann.

Proxmox Webinterface mit Zwei-Faktor-Authentifizierung schützen

Ein administrativer Zugang zum Proxmox VE Webinterface ohne SubskriptionZwei-Faktor-Authentifizierung (2FA) erhöht unnötig das Risiko eines Account-Missbrauchs.

Für administrative Konten empfehlen wir daher grundsätzlich die Einrichtung eines zweiten Faktors.

Bootloader und alte Proxmox-Installationen prüfen

Bei älteren Proxmox-Installationen sollte bekannt sein, ob das System über GRUB oder PVE-NO-SUBSCRIPTIONsystemd-boot/EFI Maßnahmegestartet machtwird keineund Proxmox,wie lediglichdie UbuntuBoot-Partitionen Updates

verwaltet SSHwerden. Passwort

Insbesondere Loginnach Upgrades über mehrere Proxmox-Versionen sollte durchkontrolliert Publicwerden, Keyob LoginKernel, ersetztEFI-Systempartitionen werden

und WebloginBootloader ohnekorrekt 2fagepflegt istwerden. riskant alte Installation aktualisieren den Kernel

ZFS nicht mehr auf der nicht gebooteten Version, also Efi Boot macht nur noch EFI Updates, Grub Boot macht nur noch Grub Updates!

ZFS ist zu komplex um es nur über die PVEProxmox KonsoleGUI aufüberwachen Platz

Die Proxmox-Oberfläche allein reicht unserer Erfahrung nach nicht aus, um den Zustand eines produktiven ZFS-Storage vollständig zu beurteilen.

Zusätzlich sollten regelmäßig unter anderem folgende Bereiche überwacht werden:

ZPOOL-Status SMART-Werte der Datenträger Kapazität und Funktiontatsächliche zuPool-Auslastung prüfen,ZFS-Fehler wasund Checksum Errors Scrub-Ergebnisse SSD-Verschleiß Temperaturen ARC und Speicherverbrauch

SSD TRIM konfigurieren und überwachen

Bei SSD-basierten ZFS-Systemen sollte die verwendete TRIM-Strategie bewusst festgelegt und überprüft werden.

Ob kontinuierliches ZFS-Autotrim oder ein zeitgesteuerter Trim sinnvoller ist, hängt auch für Smart gilt

Automatisches Trimmingvon der SSDseingesetzten istHardware und dem WöchentlichenWorkload vorzuziehenab. Die wöchentlichen Trimming

Scrub und ScrubTRIM Jobs sollten auf Verträglichkeitnicht mit ArbeitBackup-Zeiten kollidieren lassen

Automatische ZFS-Scrubs, TRIM-Vorgänge und Backups geprüftsollten werden

zeitlich Deraufeinander primäreabgestimmt werden.

Bei größeren Storage-Systemen können diese Prozesse erhebliche I/O-Last erzeugen. Sie sollten daher möglichst nicht gleichzeitig mit großen Backups oder besonders I/O-intensiven produktiven Arbeiten laufen.

ZFS Cache ARC solltebewusst viadimensionieren

unserem

Der PostinstallerZFS manuellARC festgelegtverwendet werden,Arbeitsspeicher daals 50%Cache. Die optimale Größe hängt stark vom Einsatzzweck des Servers ab.

Ein Proxmox-Host mit vielen virtuellen Maschinen benötigt eine andere Speicheraufteilung als ein dediziertes Storage-System.

Wir empfehlen deshalb, den ARC nicht einfach aufgrund pauschaler Prozentwerte zu vieldimensionieren, sondern anhand von RAM-Ausstattung, VM-Bedarf, Storage-Größe und tatsächlichem Workload festzulegen und anschließend zu überwachen.

Ausfall einer Proxmox Boot-Disk vorbereiten

Bei gespiegelten Proxmox-Bootlaufwerken reicht es im Fehlerfall nicht immer aus, lediglich die defekte Festplatte physisch zu ersetzen.

Die neue Disk muss passend partitioniert, in den ZFS-Pool eingebunden und gegebenenfalls wieder bootfähig gemacht werden.

Der Ablauf für VMseinen istBoot-Disk-Ausfall sollte deshalb bereits vor dem Ernstfall dokumentiert und fürgetestet SANsein.

zu wenig Bootfestplatten müssen bei Ausfall vorpartitioniert und mit Boot-Tool und ZFS gefüllt werden

/etc/pve läuftzusätzlich aussichern

einer

Das DatenbankVerzeichnis /etc/pve ist kein gewöhnliches lokales Konfigurationsverzeichnis. Proxmox stellt die Cluster-Konfiguration über pmxcfs bereit.

Wichtige Proxmox-Konfigurationen sollten deshalb zusätzlich regelmäßig und sollte versioniert gesichert werden

werden. KVM

KVM- und Remote-Konsolen regelmäßig testen

Remote-Konsolen sollten aufnicht erst getestet werden, wenn der Server nicht mehr über das Netzwerk erreichbar ist.

Wir empfehlen insbesondere:

Tastaturbelegung und Sonderzeichen beim Login geprüft werdenprüfen Passwörter mit Sonderzeichen testen Browser- und Client-Kompatibilität kontrollieren Remote-KVM Konsolenbzw. IPMI/iLO/iDRAC regelmäßig testen

Eine jährliche Funktionsprüfung kann verhindern, dass die Notfallkonsole ausgerechnet im Ernstfall nicht verwendbar ist.

E-Mail und Benachrichtigungen testen

Ein Proxmox-System sollte wichtige Ereignisse und Fehler zuverlässig melden können.

Die konkrete Einrichtung des Mailversands hat sich über die verschiedenen Proxmox-Versionen weiterentwickelt. Entscheidend ist deshalb weniger die konkrete Versandmethode als ein regelmäßig getesteter Benachrichtigungsweg.

Testet insbesondere, ob Warnungen tatsächlich einen Administrator erreichen.

ZFS-Mountpoints und Directory Storage beachten

Vorsicht bei ZFS und Directory Storage: Ein Verzeichnis sollte nicht unkontrolliert als Storage verwendet werden, wenn an dieser Stelle eigentlich ein ZFS-Dataset gemountet werden soll.

Ist das Dataset nicht gemountet und wird das Verzeichnis trotzdem verwendet, können Daten versehentlich auf dem darunterliegenden Dateisystem landen. Mountpoints und Storage-Verfügbarkeit sollten jährlichdeshalb überwacht werden.

Proxmox ZFS Replication ersetzt keine Backup-Historie

Die integrierte Proxmox ZFS Replication ist eine praktische Möglichkeit, VM-Daten auf Clientkompatibilitäteinen geprüftanderen werden

Mailversand muss mühselig über Postfix eingerichtet werden, ist nicht zuverläsig ZFS Directory Datastores sindProxmox-Node zu vermeiden,replizieren. da PVE im dümmstem fall den Ordner schneller anlegt als ZFS. Dann erscheint der Ordner leer Die eingebaute ZFS

Eine Replikation ist simpeljedoch kein Ersatz für ein Backup mit Historie. Fehler oder unerwünschte Änderungen können ebenfalls repliziert werden.

Für eine belastbare Datensicherung empfehlen wir zusätzlich ein separates Backup-System, beispielsweise Proxmox Backup Server.

ZFS Snapshots sinnvoll einsetzen

Regelmäßige ZFS-Snapshots sind eine sinnvolle Ergänzung für Storage und bautWiederherstellung.

keine

Snapshots Historiebenötigen auf

zunächst ZFS-Auto-Snapshotwenig unbedingtzusätzlichen nutzen,Speicher, können bei vielen Änderungen jedoch erheblich wachsen. Die tatsächliche Pool-Auslastung muss deshalb überwacht werden.

ZFS-Pools nicht 80%vollständig Plattenplatzfüllen: vomFür ZPOOLproduktive überschreiten

Systeme CEPHsollte ausreichend freier Speicher vorhanden bleiben. Sehr hohe Pool-Auslastungen können Performance und administrativen Handlungsspielraum erheblich verschlechtern.

Ceph nur mit passender Infrastruktur einsetzen

Ceph ist eine nichtsleistungsfähige Lösung für Anfängerverteilten Storage, aber kein Selbstzweck.

Für kleine Installationen kann ein sauber aufgebautes ZFS-Konzept einfacher, wirtschaftlicher und kleineleichter Firmen

zu Imbetreiben Idealfallsein. CPU

Ceph erfordert Erfahrung sowie eine passende Anzahl an Nodes, Datenträgern, Netzwerkbandbreite und Monitoring. Vor einer Ceph-Einführung sollten deshalb Anforderungen und vorhandene Infrastruktur genau geprüft werden.

CPU-Typ Hostvirtueller inMaschinen VMsbewusst auswählen,auswählen

da

Der sonstCPU-Typ nichteiner alleKVM-VM beeinflusst, welche Funktionen der physischen CPU innerhalb der virtuellen Maschine zur Verfügung stehen

stehen. Guest

host kann eine hohe CPU-Feature-Abdeckung und Performance ermöglichen. Bei Clustern und insbesondere bei Live-Migration zwischen unterschiedlichen CPU-Generationen muss die Auswahl jedoch sorgfältig geplant werden.

Für Cluster kann ein gemeinsamer CPU-Typ sinnvoller sein als pauschal host für jede VM zu verwenden.

VirtIO- und Windows-Gasttreiber

Bei produktiven Windows-VMs empfehlen wir, stabile und getestete VirtIO-Treiber immereinzusetzen.

nur

Neue 'stable'Treiberversionen verwenden,sollten nichtvor 'latest'

einem flächendeckenden Rollout zunächst getestet werden.

Backups niemals ausschließlich auf dem Proxmox-Host speichern

Ein Backup auf demselben Server ist kein ausreichendes Backup-Konzept.

Backups sollten nicht ausschließlich auf local Storebzw. ausführen,auf dademselben diesphysischen Proxmox-Host gespeichert werden, auf dem die produktiven VMs laufen.

Bei einem Defekt, Dateisystemproblem oder vollständigen Ausfall des Hosts wären ansonsten sowohl Produktivsystem als auch Backup betroffen.

Für produktive Umgebungen empfehlen wir einen getrennten Proxmox Backup Server oder ein anderes physisch getrenntes Backup-Ziel.

Video: Proxmox VE Praxistipps

Zu diesen Erfahrungen haben wir auch ein Video veröffentlicht:

 Proxmox VE Praxistipps auf YouTube ansehen

Proxmox Tools und Postinstaller auf GitHub

Viele unserer Werkzeuge für Proxmox VE stellen wir als Open Source zur Verfügung. Dazu gehört unter anderem unser Proxmox VE Post Install Script.

 bashclub – Proxmox Tools und Postinstaller auf GitHub

---

 Stand der PVEDokumentation: Diese Seite ist

aus einer

UnserSammlung Videounserer zumProxmox-Praxiserfahrungen Beitrag