[Sammelthread] Proxmox Stammtisch

(Nicht sicher, ob das hierher gehört oder in den ZFS-Faden.)

Habe 2x Exos X18 16 GB und 2x PM883/893 480 GB (+ MC12-LE0, 5600X, 64 GB ECC, sollt aber egal sein). Daraus soll ein Backupserver auf Proxmox-Basis werden. Proxmox hauptsächlich deshalb, weil's im Gegensatz zu einem nackerten Debian stable gleich mit ZFS daherkommt, und ohne jedes Theater davon bootet. Ganz abgesehen davon hasse ich bare metal backup / restore, VMs sind da einfach komfortabler. Und wenn's einmal sein muss kann ich auch die ein oder andere VM (container), die nichts mit Backup zu tun hat, auf dem Ding laufen lassen, bis das primäre System wieder funzt.

Die Kiste soll ZFS backups von den (File-)Servern via zfs receive, BTRFS backups von den Desktops via btrfs receive (notgedrungen via BTRFS-on-ZVOL), PVE backups via PBS (in einer VM), und mehr oder minder konventionelle Dateibackups (schaut momentan nach restic aus) annehmen, das wichtigste Zeug auch noch zu Hetzner verfrachten (schaut auch nach restic aus), und die Daten ansonsten sicher begraben, bis ich sie hoffentlich nie brauch.
Das Ding fährt in der Nacht hoch, pullt Backups von allem was wach ist, und schläft wieder ein (oder fährt ganz runter).

Frage 1 – Pool-Setup

N.B. Alle vdevs mirrored.
  1. Dem Proxmox-Installer den Großteil der zwei SSDs für den RPOOL lassen, Rest special vdev für einen Pool aus den beiden Platten.
    Contra: Lange hieß es, dass auf dem root pool wirklich nur das System liegen sollte, u. a. weil der gerade unter Linux Einschränkungen unterliege. Abgesehen davon möchte ich den Platz auf den SSDs nicht nur für Proxmox und seine VMs nutzen; k. A., ob man auf einem pool, den Proxmox als "seinen" Systempool ansieht, gefahrlos andere Datasets/ZVOLs anlegen kann.
    oder
  2. Noch kleinerer RPOOL (per Installer), dahinter ein kleiner, manuell angelegter SSD-Pool, dahinter special vdev für den HDD-Pool. Kann ja immer noch ein Dataset auf dem SSD-Pool anlegen und in Proxmox als Datastore einbinden.
    Contra: Komplexer, und man müsste es schaffen, den Platzbedarf der drei Partitionen richtig abzuschätzen.
Frage 2 – BTRFS-on-ZVOL
  • Mir ist klar, dass das weit jenseits von ideal ist – irgendwelche Tipps, wie man den Schaden zumindest minimieren kann? So schnell muss es ja nicht sein, ist ja nur für Backups, aber einserseits möcht ich keine Performance liegen lassen, andererseits ist die write amplification für die SSDs auch nicht gerade lebensverlängernd.
  • Das Einzige, was mir ausser Filesystemtuning auf ZFS- und BTRFS-Seite eingefallen ist, ist die Anzahl der Snapshots klein zu halten und "alte" Snapshots in ein restic repo zu verfrachten. So ist die Versionierung noch etwas länger möglich ohne BTRFS mit hunderten Snapshots zu belasten (was es schon bare metal gar nicht mag).
Frage 3 – ZFS-Replikation
  • Was nimmt man heutzutage als Frontend für zfs send/receive? PBS selbst kommt für PVE-fremde Datasets ja wohl nicht in Frage. Gut, ich hab meine alten Skripte, aber wenn's was bewährtes Fertiges gibt, nehm ich das gerne.
Frage 4 – PBS
  • Für den PBS wird ja dringend empfohlen, ihn auf SSDs laufen zu lassen – gilt das auch dann, wenn er nur von einem remote pullt? Hab nämlich Zweifel, dass der Platz auf den SSDs reicht, und für ruhende Daten isser mir auch zu schade.
  • Kann man da irgendwas optimieren? Z. B. Metadaten (der PBS-Backups) auf den SSD-Pool, Chunks auf den HDD-Pool?
Frage 5 – Sleep
  • Grundsätzlich sollte systemctl suspend normal funktionieren, gibt's irgendetwas zu beachten?
Frage 6 – Virtualise everything
  • Würdet ihr in dem Fall das, was es halt sonst noch so braucht (btrfs-tools, btrbk, restic, ...) auf dem Host installieren oder in Container? (PBS kommt fix in eine VM.)
So. Kommen sicher noch viel mehr Fragen, aber ich denke, fürs Erste wars das. Noch hab ich ja Zeit zum Planen, is noch nicht die ganze Hardware da. (Und richtig ans Eingemachte geht's eh erst, wenn der neue kugelsichere Backupserver steht und bespielt ist. Dann gibt's entweder Ceph oder zumindest einen 2+1 PVE-Cluster mit ZFS-Replikation.)

Jegliche Anregungen willkommen.
Beitrag automatisch zusammengeführt:

Harddisk ist eh suboptimal, SSDs kosten nichts mehr.

Also ich weiß nicht. Die Seagate Exos (günstigste ordentliche HDD lt. GH) gibt's ab ~€15/TB, SSDs fangen bei €95/TB an, wobei wir da von €700–800/Disk reden. Die Samsung PM883 1 TB liegt bei €114. Also immer noch gut das 7-fache. Natürlich kann man auch Consumer-SSDs nehmen, bei denen darf man dann wie ein Haftelmacher aufpassen, dass man nicht zu viel schreibt, und bei jeglichen sync writes steht das Ding dann. Und wehe es ist voll. Nein, HDDs haben durchaus noch eine Daseinsberechtigung, und nicht nur als Datengrab.

Wenn Firewall = OPNsense, dann go HA

Tell me more. Hat OPNsense eingebaute HA-Unterstützung, oder wie? Wenn das günstig realisierbar ist, wärs ein Grund, meine Eigenbaulösung aufzugeben.

andernfalls sind deine Datenbanken unter Umständen nach einem restore nicht konsistent.

Das sagen alle, also wird es schon stimmen, aber verstehen tu ich's nicht. So ein Backup im laufenden Betrieb ist auch nicht schlimmer als wenn der Kübel den Strom verliert. Sind halt die letzten paar Transaktionen nicht mehr drin, aber konsistent sollte die DB immer sein. Oder verwenden die Leut heutzutage nur noch non-ACID-Datenbanken?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
N.B. Alle vdevs mirrored.
  1. Dem Proxmox-Installer den Großteil der zwei SSDs für den RPOOL lassen, Rest special vdev für einen Pool aus den beiden Platten.
    Contra: Lange hieß es, dass auf dem root pool wirklich nur das System liegen sollte, u. a. weil der gerade unter Linux Einschränkungen unterliege. Abgesehen davon möchte ich den Platz auf den SSDs nicht nur für Proxmox und seine VMs nutzen; k. A., ob man auf einem pool, den Proxmox als "seinen" Systempool ansieht, gefahrlos andere Datasets/ZVOLs anlegen kann.
ich hab meinem proxmox mit 2*2TB NVME einfach einen z mirror erstellen lassen bei install und ein paar MB frei gelassen als spare space

die sind eh overkill an I/O
 
@Weltherrscher
Sehr cool. 👍🏻 Bin gespannt, ob du alle CUDA Features in den VMs auch sauber ans Laufen bekommst. Keep us posted, please. ;-)
 
Kernel 6.8 läuft, aber weils Maxwells sind, bin ich auf Treiber 535.184 begrenzt.
CUDA will ich als nächstes mal mit Immich und / oder Nextcloud probieren.
Momentan muss ich zusehen, dass die Karte ins PL12 geht, aktuell hängt sie in PL8 fest, was 70 W mehr im Leerlauf sind. :fresse:
 
Hast du den 6.8er anpassen müssen oder läuft das ohne Anpassung out of the box?
 
Ja, dann so rum. Du musstest auf jeden Fall etwas patchen 😊 Das kann ich hier produktiv eher nicht machen. Dann bleibt es erstmal beim Kernel 6.5.
 
Wenn ihr neuere Karten als Pascal habt: der 550 ging ohne zu patchen mit dem 6.8er Kernel zu installieren.
Der hat aber keine Profile für die M60 gefunden (logisch, weil ja Support nur bis 535).

//Edith:
1729110273682.png
1729110379039.png

Wischtisch!
iommu von Intel auf virtio stellen, sonst gibts Fehler im Kernel der VM und nvidia-smi findet in der VM nix.
Alter.

//Edith2:
Aha.
Zwar vGPU, aber Maxwell ist nicht preemptive.
-> einzig das 8Q-Profil ist für CUDA verfügbar.
Damit kann die M60 genau ZWEI VMs mit CUDA betreiben (je eine pro GM204).
*NARF*
CUDA mit kleineren Profilen geht erst ab Pascal.

Jetzt fluppt zumindest mal Immich mit CUDA:
1729116406813.png
1729116445796.png
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh