[Sammelthread] Proxmox Stammtisch

[bernix88]

Warum nicht einfach Proxmox mit ZFS und als VM OpenMediaVault? dann hast quasi ZFS mit schicken Webinterface?

 

[klaustaler]

Warum nicht einfach Proxmox mit ZFS und als VM OpenMediaVault? dann hast quasi ZFS mit schicken Webinterface?

Proxmox mit ZFS (pool besteht schon) ist das Ziel. OMV habe ich mir angeschaut, kann aber als VM nicht auf den drarunterliegenden Pool "schauen" wenn ich einen Container verwende. Controller habe ich keine mehr zum durchreichen (wäre bei KVM der Fall - hatte diese Lösung zu ESXi-Zeiten). Oder ist mir bei OMV etwas entgangen?

Eigentlich möchte ich nur meinen Proxmox-ZFS pool um ein Cache-Device erweitern. Idealerweise /dev/sda3 (nach /boot und /swap)

 

[trendco]

Vielleicht mal an diesen Thread hängen und fragen wie man das macht: install without LVM

Oder bei der Installation auswählen, dass Proxmox auf ZFS installiert wird, dann kann ja auch kein LVM da sein

Warum nicht einfach Proxmox mit ZFS und als VM OpenMediaVault? dann hast quasi ZFS mit schicken Webinterface?

Wie meinst jetzt das? OMV sieht den Proxmox POOL ja gar nicht.
Meine Idee ist ja, das Dataset per NFS in die VM einzubinden, mit N4F geht das, bei OMV hatte ich das mal probiert vor ein paar Monaten habs aber nicht hinbekommen, weil OMV das intern anders handhabt wie N4F.

 

[klaustaler]

Den "alten" Thread habe ich auch gesehen. Natürlich kann ich ZFS wählen, aber dann wird die gesamte SSD für den ZFS-Boot-Pool verwendet. Das möchte ich nicht. Es soll einfach ext4 bleiben und die leere partition als cache dienen.

Sowohl Proxmox als auch OMV basiert auf Debian. Wenn ich OMV als CT oder VM in Proxmox installiere, ist das ZFS1 von Debian eben unsichtbar. Per NFS könnte ich einbinden - mach ich sogar in VMs, aber da fehlen alle netten zpool/zfs/zdb-Befehle.

 

[bernix88]

OMV muss den ZFS-Pool ja nicht sehen, einfach eine VM-Disk(.raw) auf dem ZFS-Pool erstellen in OMV einbinden und über diese den Share bereitstellen?

 

[trendco]

Aber dann hast eben noch mal eine Filesystem Schicht dazwischen, OMV legt ja dann auf der RAD-Disk ein ext4 an.

 

[bernix88]

ja das ist mir klar, nur über NFS wird die Netzwerklast auch ziemlich hoch - ZFS <-> NFS <-> Linux Bridge <-> NFS <-> SMB
müsste man mal testen was schneller ist, über Netzwerk oder über Disk Schichten (ZFS <-> RAW <-> EXT4 <-> SMB)
Falls ich das so richtig sehe?

 

[trendco]

Also mir ginge das weniger um die Geschwindigkeit als vielmehr um die Datensicherheit.

 

[bigghost]

Die Final 4.0 ist raus.

 

[morph027]

Und läuft bei mir zu Hause und auf Arbeit im Lab super....demnächst steht sowieso ein Umzug an, da werden dann auch neue Server angeschafft und ich mach mich mal an die Migration.

 

[bernix88]

Was mir immer noch nicht ganz klar ist, was ist wirklich die "beste/sicherste" Variante einen Fileserver auf Proxmox(zfs) zu betreiben?
Das man für die VM/Container-daten den ZFS Pool direkt am Proxmox erstellt ist klar, aber Fileserver Daten mit mehreren TB?
HBA per PCI Passthrough zu einer FreeNas/Nas4Free/OMV/XPenology durchschleifen? (OmniOS mit Napp-it scheint ja nicht zu funktionieren zumindestens vor Proxmox 4.0 nicht)
ZFS Pool direkt am Proxmox und dort dann eben .raw VM-Disk erstellen?
ZFS Pool per NFS an die Fileserver VM und dann weiter per SAMBA/AFP/NFS?

Wie macht das ihr? oder habt ihr einen dezidierten Fileserver?

 

[morph027]

Aktuell gibt der PVE bei mir seinen ZFS Pool selbst als NFS readonly an die ganzen XBMC's im Haus aus (die RPis sind mit NFS irgendwie performanter als mit CIFS). Für alle restlichen Clients ist ein LXC mit Samba4 drauf, der das Verzeichnis als mount bind rein bekommt und mit Authentifizierung dann auch read-write erlaubt.

 

[GuNa]

Warum installierst du nicht einfach ein Debian und machst Dein Partitionslayout so wie du es möchtest und installierst anschließend Proxmox?
Schau mal hier.

PS. Hier ein Blog wie PVE als File Server installiert wird . Vielleicht das was Du suchst?

 

[bernix88]

LXC mount bind - kannte ich noch nicht, liest sich aber gut - werde das die tage mal antesten.
@morph027 - hat man starke performance einbußen mit mount bind?
@GuNa - danke für den Tipp - den Blog kannte ich bereits, möchte aber Hypervisor und Fileserver irgendwie "getrennt" haben.

 

[morph027]

Frisst nicht wirklich was. Der LXC läuft ja letztenlich nativ auf dem bare metal host, bekommt nur separate Prozess- und Netzwerknamespaces (das macht der Kernel ohne viel Overhead) und etwas Schutz/Gefängnis mit Apparmor. Ich bekomme zumindest mit nativem NFS das gleiche heraus wie mit CIFS. Da limitiert dann eher CPU (LUKS) und RAM (ZFS) plus das, was die Disks eigentlich an I/O hergeben.

 

[luckyspiff]

Ich habe mit ZFS unter Proxmox 4 das Problem, dass beim Booten der zfs-mount.service nicht gestartet werden kann, was sich so äußert:

root@ml10:~# systemctl status zfs-mount
● zfs-mount.service - Mount ZFS filesystems
   Loaded: loaded (/lib/systemd/system/zfs-mount.service; static)
   Active: failed (Result: exit-code) since Sat 2015-10-17 20:20:23 CEST; 31min ago
 Main PID: 825 (code=exited, status=1/FAILURE)

Oct 17 20:20:22 ml10 zfs[825]: cannot mount '/pool1': directory is not empty
Oct 17 20:20:22 ml10 zfs[825]: cannot mount '/pool1/pve': directory is not empty
Oct 17 20:20:22 ml10 zfs[825]: cannot mount '/pool1/pve/images': directory is not empty
Oct 17 20:20:23 ml10 systemd[1]: zfs-mount.service: main process exited, code=exited, status=1/FAILURE
Oct 17 20:20:23 ml10 systemd[1]: Failed to start Mount ZFS filesystems.
Oct 17 20:20:23 ml10 systemd[1]: Unit zfs-mount.service entered failed state.

Auf meinem System ist ZFS nicht das Root/System-Filesystem, ich hab Proxmox 4 mit ext4 auf die Boot-SSD installiert und den ZFS Pool anschließend mit den HDDs daneben angelegt.

Das Verzeichnis /pool1/pve/images wurde aus irgendwelchen Gründen offenbar im (ext3) Filesystem angelegt, sollte aber eigentlich im ZFS-Pool liegen (der unter /pool1 gemountet ist). Nun kann ZFS das Verzeichnis nicht mounten, da es nicht leer ist.

Ich denke es hängt möglicherweise mit einer Race-Condition beim Booten zusammen, für die hier ein Workaround beschrieben ist. Leider kann man mit dem Workaround unter systemd nichts anfangen (/etc/init.d/zfs-mount ja nicht mehr).

Hat hier schon jemand das gleiche Problem gehabt und gelöst oder weiß anderweitig Rat?

EDIT: Ich hab Ursache und Lösung gerade hier gefunden. Mein Fehler ist, dass ich in Proxmox Storage vom Type 'dir' im ZFS angelegt hab statt vom Typ 'zfspool'. Dann tritt dieser Bug (oder Feature?) auf.

 

[luckyspiff]

Ich möchte Proxmox von einer Boot-SSD starten, auf der sich dann natürlich auch das (ext4) root-Filesystem befindet. Alle VMs, Container usw. will ich im ZFS-Pool speichern, allerdings befindet sich dann die Knoten-Konfiguration unterhalb /etc/pve nicht im ZFS-Pool, d.h. beim SSD-Ausfall geht mir das verloren. Ich würde jetzt regelmäßig Kopien des /etc/pve in ein Verzeichnis auf den ZFS-Pool machen, damit ich ohne größere Probleme alles vom Pool aus restaurieren kann.

Gibt es neben dem Verzeichnis /etc/pve noch weitere Verzeichnisse, in denen Proxmox Daten abspeichert? (Die eigentlichen VM/Container-Daten habe ich ja ohnehin im ZFS-Pool.)

 

[bigghost]

Du brauchst nur in /etc/pve/qemuserver die X.conf Dateien sichern.
Besser wäre es direkt ein Backup job anzulegen für alle VM´s.In den gepackten Backup´s ist alles enthalten für eine Wiederherstellung.

 

[luckyspiff]

Du brauchst nur in /etc/pve/qemuserver die X.conf Dateien sichern.
Besser wäre es direkt ein Backup job anzulegen für alle VM´s.In den gepackten Backup´s ist alles enthalten für eine Wiederherstellung.

Danke! Gut zu wissen, die Sache mit dem Backup-Archiv...

 

[tobis72]

Hi luckyspiff,

Dein Vorhaben ähnelt sehr dem, das ich mir gerne wünsche. Wie hast du das mit dem Cache gelöst für den ZFSpool. Geht das den gleichzeitig auf der Boot-SSD (sep. Partition) zu betreiben? und welche Einstellungen wären da nötig.

 

[morph027]

Partition geht. Der Proxmox Installer krallt sich halt alles beim Setup, was er kriegen kann. Ich war zu faul, das im nachhinein anzupassen, hab auf eine 16GB SSD installiert, die dann per DD auf eine 80er kopiert und den Rest für ZIL / L2ARC genutzt

 

[tobis72]

Bin immer noch hin- und hergerissen. Proxmox 4.0 mit ZFS-Mirror vs. ESXI5.5 und HP Raidcontroller. Wie läuft das bei ZFS mit dem Rebuild bei einem Plattendefekt und braucht man unbedingt einen Cache. Ist das mit dem Cache eher ein Sicherheits- oder Performancefeature?

 

[luckyspiff]

Dein Vorhaben ähnelt sehr dem, das ich mir gerne wünsche. Wie hast du das mit dem Cache gelöst für den ZFSpool

Noch gar nicht, ich mach das ohnehin mehr aus Interesse als dass es notwendig wäre, mein alter FreeNAS Server mit ZFS hat nur halb so viel RAM und weniger CPU/IO-Leistung, da hatte ich eigentlich selten Probleme mit der Performance.

Geht das den gleichzeitig auf der Boot-SSD (sep. Partition) zu betreiben? und welche Einstellungen wären da nötig.

Prinzipiell müsste man auch in eine Partition auf der Boot-SSD cachen können, ob das eine gute Idee ist, wage ich zu bezweifeln, denn:
- im Cache-Betrieb altert eine SSD schneller und die gefahr eines "sudden death" steigt, das brauch ich nicht auf der Boot-Platte
- es dürfte mit dem Proxmox-Installer schon nicht so einfach sein vom vorgegebenen Partitions-Schema abzuweichen, da alles über LVM eingerichtet wird. Man kann natürlich erst Debian und anschließend Proxmox mit apt-get installieren, aber das ist deutlich aufwendiger
- die heutigen SSDs stoßen allesamt an die Grenze dessen was mit SATA III übertragbar ist, daher sollte man die Anbindung der Cache-SSD nicht noch mit anderen Aufgaben belasten

Ich spiele mit dem Gedanken mit ein eine neue M.2 NVMe SSD incl. passendem PCIe Adapter als Cache zuzulegen, die Schafft sesend > 2GB/s, lesend 1,2GB/s, das wäre als Cache ideal! Da ich von der Platte nicht booten will, sollte das auch ohne BIOS-Support funktionieren, Linux und FreeBSD hat wohl schon lange NVMe Treiber im Kernel. Momentan warte ich aber noch, bis die Preise fallen und idealerweise jemand das vor mir gemacht hat, dann weiß ich, dass es nicht nur theoretisch sondern auch praktisch funktioniert

 

[morph027]

Cache ist Performance lesend und nicht schlimm, wenn's wegfällt.ZIL (SLOG) ist für performance schreibend, aber bei weitem nicht so krass. Geht auch ohne gut, wenn man keine schnarchlahmen Platten drunter hat. ZFS braucht sowieso lieber RAM.

Rebuild (Resilvern) läuft super. Bricht halt wie bei jedem RAID die Performance ein (kann man auch via procfs steuern, wie schnell, etc.) bis es fertig ist. Es lohnt sich ab und an mal per Cron einen Scrub anzustoßen, der prüft die Daten (mach ich einmal monatlich). Ich bin großer ZFS Fan (bedingt auch durch beruflichen Umgang). Raid Controller können sterben*, Software lebt immer


* Wir hatten mal den krassen Fall, ein Controller kaputt, genau den gleichen in einem anderen Server gehabt. Andere Firmware, ging trotzdem nicht mehr zu lesen. Auch ein Downgrade half nicht. Alle Daten aus dem Tape wieder rausholen nervt ZFS steckst an irgendeinen anderen Rechner und das geht.

 

[luckyspiff]

Bin immer noch hin- und hergerissen. Proxmox 4.0 mit ZFS-Mirror vs. ESXI5.5 und HP Raidcontroller.

- ZFS bietet IMHO mehr als RAID, selbst mit teuren Controllern (und ich meine nicht nur Sicherheit gegen "Bitfäule", alleine die Snapshots sind genial)

- ESXi bietet (wie ich es kenne) nur "volle" Virtualisierung, Proxmox eben noch die leichtgewichtigen Container. Bei voller Virtualisierung wird immer ein komplettes OS gebootet, Du hast relativ hohen Resourcenverbrauch (z.B. schon mal eine "Grundlast" weil ein zweites Set an OS-Tasks laufen), außerdem ist es mit Containern sehr einfach und effizient möglich ein Verzeichnis vom Host-Storage im Container zu "mounten".

- ESXi kann nur über eine Windows-Konsole gemanaged werden, bei Proxmox funktioniert alles im Browser, sogar den Boot-Bildschirm oder einen Windows-Desktop kann man in einem Browser-Fenster öffnen.

Wie läuft das bei ZFS mit dem Rebuild bei einem Plattendefekt

Eigentlich total simpel, der Pool-Status (zpool status) sagt "state: DEGRADED" und zeigt Dir an, welche Platte defekt ist. Die tauschst Du aus und sagst ZFS dann mit "zpool replace poolname kaputte-platten-id /dev/disk/by-id/neue-platte" dass er die neue Platte nehmen soll, dann läuft das Resivern und alles ist wieder gut.

Kannst Du auch prima mal durchspielen (z.B. mit VirtualBox), da man in ZFS einen Pool nicht nur mit Festplatten sondern auch Dateien anlegen kann.

In FreeNAS kann man das auch über die GUI erledigen, aber auch in der CLI ist das kein Hexenwerk und ich finde fast einfacher als GUIs.

braucht man unbedingt einen Cache. Ist das mit dem Cache eher ein Sicherheits- oder Performancefeature?

Cache brauchst Du nicht zwingend, das ist ausschließlich ein Performance-Gewinn. ZFS cached von sich aus schon ins RAM (daher sollte man da nicht sparen und auch ECC-RAM haben) man kann nur zusätzlich noch eine SSD als Cache dazuschalten. In alten ZFS Versionen zwar es sogar so, dass mit dem Cache die Sicherheit gesunken ist, da beim Ausfall der ZIL-Cache-SSD der Pool korrumpiert werden konnte. Das ist zum Glück Vergangenheit, heute führt eine sterbende ZIL-SSD nur dazu, dass nichts mehr gecached wird, aber solange der Strom nicht in der gleichen Sekunde ausfällt (sehr unwahrscheinlich und mit einer USV vermeidbar), passiert Deine Daten nix.

 

[tobis72]

..ok, danke für Deine sehr ausführliche und gute Beschreibung

-

In FreeNAS kann man das auch über die GUI erledigen, aber auch in der CLI ist das kein Hexenwerk und ich finde fast einfacher als GUIs.

d.h. das Managment über die ZFS-pools ist nicht über das Proxmox Web Gui administrierbar?

 

[morph027]

Dem kann ich in allen Punkten nur zustimmen. Habe schon ewig ZFS auf BSD im Einsatz gehabt und bin froh, dass die Proxmox Jungs sich trauen, das quasi als produktiv nutzbar zu verkaufen (wenn man den Support nutzt). Das gibt das richtige Signal, denn auch ZFS on Linux ist schon lange stabil.

Und gerade zu Hause sind die Container genial. So hab ich keine Dienstseuche auf einer VM, sondern schön Webserver/Datenbank/Samba4-AD/.../ voneinander getrennt und das frisst erst mal kaum Overhead.

Auf Arbeit mit 200+ VMs auf einem Server noch viel besser...vor allem, wenn die meist nur idlen und/oder einfache Funktionen, diese aber abgeschottet bereitstellen sollen.

d.h. das Managment über die ZFS-pools ist nicht über das Proxmox Web Gui administrierbar?

Nope..aber auf der CLI nicht schwer und meiner Meinung nach besser für die Lernkurve....Mehr Info dann hier im ZFS Stammtisch

 

[luckyspiff]

Ich "spiele" jetzt seit einigen Tagen mit Proxmox herum, da ich überlege meinen bestehenden FreeNAS Server auf Proxmox umzustellen. Dieser wird hauptsächlich als "Home-NAS" genutzt wird (im wesentlichen Fileserver mit NFS und Samba, zwei SqueezeboxMediaServer für Musik, ein PlexMediaServer) . Die Verlockung KVM Virtualisierung zu nutzen zu können, ist einfach sehr groß und würde es mich auch verschmerzen lassen, dass ich keine Web-GUI zum Verwalten von ZFS, Benutzern/Gruppen, NFS-, Samba-Freigaben, S.M.A.R.T.-Monitoring usw. nutzen kann. Dies "von Hand" zu verwalten, habe ich vor FreeNAS jahrelang (natürlich ohne ZFS) mit Debian auf einem PC Server gemacht (außerdem entsteht der Aufwand vor allem am Anfang, die spätere Pflege ist eh nicht so schlimm).

Was mich stört, ist der Gedanke, all diese Dienste direkt im Proxmox-Debian ("ganz unten") laufen zu lassen. Bei FreeNAS ist die eigentliche NAS-Funktion zwar auch im Host-OS implementiert, aber relativ sicher: einerseits, da man nicht direkt in Konfig-Dateien (/etc) herumbastelt sondern alles über die GUI einstellt. Aber auch, weil das Root-Filesystem (auf USB-Stick oder SSD) nur read-only gemountet ist, Schreibzugriffe also ohne weiteres gar nicht möglich sind. So kann man das System nicht versehentlich kaputt machen und ist auch gegen Angriffe von außen etwas besser geschützt.

Klar, man kann vermutlich SAMBA in einem LXC-Container laufen lassen, in den man alle zu exportierenden Verzeichnisse "mountet", mit NFS geht das vermutlich auch. Aber ich vermute, so etwas wie S.M.A.R.T.-Monitoring wird schon schwierig (wg. Zugriff auf die Raw-Devices unter /dev) und die Benutzerverwaltung muss man auch "ganz unten" machen (bzw. vielleicht kann man für die eigentliche User/Gruppenanlage sogar Proxmox nutzen, das hab ich mir noch nicht angesehen).

Jetzt würde mich interessieren, ob und welche Lösungen und "best practices" es hier unter Proxmox gibt, um möglichst viele der erwähnten Dienste in einem Container zu verlagern, ohne einen riesen Overhead zu produzieren. Ziel ist wie gesagt ein Home-Server, kein HA-Datacenter mit 99,999% Verfügbarkeit. Datenintegrität geht hier vor Ausfallsicherheit oder Cluster-Features.

Eine Möglichkeit ist es natürlich auch, ein komplettes FreeNAS in einer VM laufen zu lassen (man müsste die HD-Platten irgendwie durchreichen und würde dann ZFS, Benutzer und Freigaben in FreeNAS verwalten). Aber dann kann ich den Pool ja nur über NFS oder iSCSI an Proxmox "nach unten" weitergeben, das erscheint mir dann auch mit ziemlich viel Overhead behaftet und zerbrechlich.

Sicher verwenden hier doch einige Proxmox auch als "Home Server", wie habt Ihr das gelöst?

Eine ganz andere Frage ist noch, ob es prinzipiell möglich und/oder vorgesehen ist, ist die Proxmox-GUI (z.B. durch Plugins) zu erweitern. Das würde es erlauben Funktionalität wie Netzwerkfreigaben oder Backup-Lösungen in die GUI "einzubauen". Gibt es hier entsprechende Schnittstellen die stabil und dokumentiert sind?

 

[Fischje]

wenn ich das alles so lese - vielleicht kehre ich ja doch nochmal zurück....

momentan läuft wohl alles sehr rund unter debian 6.0, aber ich komm irgendwie nicht so ganz aus der bequemen xpenology-ecke weg. debian ist für mich zwar eher ein alter bekannter als diese bootloader-geschichte jetzt, aber mit zfs und alles auf der konsole, dazu noch boot und cache auf einer disk - puuh. da grübel ich schon

 

[luckyspiff]

Die Denke ist eine andere...: Nicht Proxmox fungiert als Heimserver, sondern die Heimserver laufen virtuell unter Proxmox. Derer sind es bei mir viele für einzelne Zwecke. Den von Dir befürchteten 'Super Overhead' sehe ich nicht, da aktuelle Hardware und Massenspeicher das locker bringen. Bei mir teilen sich ein bis zwei virtuelle Maschinen jeweils eine SSD. Die Performance für heimische Zwecke ist mehr als nur ausreichend. Automatisierte Backups und Snapshots passieren auf einem separaten FreeNAS, welches nicht virtualisiert bzw. bare metal auf eigener Hardware läuft.

Und bitte: Nichts 'ganz unten' im Debian von Proxmox laufen lassen. Eine Todsünde wäre das und keineswegs im Sinne des Erfinders.

Das ist ja genau mein Anliegen, aber welche Lösungsmöglichkeiten gibt es hier konkret. FreeNAS virtualisiert ist aber wohl keine so gute Idee, auch wenn man es irgendwie zum laufen kriegt.

Wie hast Du das dann aufgesetzt, wer macht z.B. NFS- und SMB-Shares und wo liegt das freigegebene Filesystem? Ich finde die Idee charmant nur einen zentralen ZFS-Pool für all meine Daten im Haus zu haben und mir nur für diesen eine Backup-Strategie auszudenken, hätte also ungern ein paar Platten nur an an eine VM durchgereicht, die ich in anderen VMs dann nicht nutzen kann.

Mehr als einen Server wollte ich eigentlich nicht 24/7 laufen lassen, den alten Server hätte ich hin- und wieder für Backups (ZFS-Inkrementell über Snapshots) eingeschaltet und ansonsten ist er ein "cold standby". Meine Versuche mit simplesnap ein Backup von FreeNAS 9.2 auf Proxmox ZFS zu spielen waren wenig erfolgreich (initiales Backup klappt, aber irgendwie legt er die Snapshots für die Inkrementellen Backups nicht auf beiden Seiten identisch an, an der Stelle, an er das macht, bricht die SSH-Pipe auseinander).