Proxmox mit "native" zfs als ersatz für Esxi + HBA + FreeNAS

[booyakasha]

ich brauche mal feedback ob dieser Plan aufgeht:
Use-cas: NAS mit zfs
Ursprünglicher Plan: Esxi als hypervisor, HBA im System verbaut und das wird direkt an eine VM weitergereicht. In der VM läuft FreeNAS

Alternativplan: Proxmox und zfs im hypervisor selbst umsetzen, diesen Storage dann an eine VM weiterreichen für den Remote Zugriff.

Was mir bis jetzt aufgefallen ist sind die folgenden Punkte
Nachteile:
* zfs routinen (scrubbing, snapshots, ...) nur als CLI und nicht über gui
* keine SMART infos?
* kein Spin down?
* das ganze klickibunti von FreeNAS entfällt?

Vorteile:
* HBA entfällt

Fallen euch weitere Punkte ein die dagegen sprechen?
Was sagt ihr zu dem Plan?

 

[konfetti]

Wenn Du schon Baremetall für den Storage in betracht ziehst, warum dann nicht FreeNAS oder Xigmanas direkt auf der Hardware installieren?
weitere kleinere VMs könntest Du ohne Probleme laufen lassen und kannst mit dem onboard-Ports auch ZFS mit den Disks nutzen.

Wenn Du natürlich nur den ESXi als Unterbau für eine NAS-VM ohne weitere VMs nutzen möchtest, würd ich das eh weglassen...

 

[gea]

Prinzipielll ist der Extra HBA nicht der entscheidende Unterschied, man kann auch bei Sata bleiben. Ein SAS HBA ist halt professioneller mit hotplug, Smart Erkennung und ausreichend Slots.

Die Optionen sind eher:
Man nimmt ein auf Storage optimiertes OS, egal ob Free-BSD (mit FreeNAS oder XigmaNAS als Web-UI) oder OmniOS/Oracle Solaris (mit napp-it als Web-UI). Darauf werden Dienste installiert (z.B. Webserver, Mediaserver), egal ob direkt auf dem OS oder via Virtualisierung (KVM, Linux Container oder Bhyve).

Nachteil: Sehr viele Abhängigkeiten. Wenn was hängt kann man gerne mal alles neu machen


Man nimmt ein auf Virtualisierung optimiertes OS wie ProxMox (Debian) oder SmartOS (Solaris Fork). Die haben beide ZFS. Für Storage ist man aber ganz schnell auf der Konsole.


ESXi trennt das.
Als Virtualisierungsplattform braucht es die wenigste Leistung für sich selber. Auch hat es die beste Unterstützung nicht nur für Linux sondern auch BSD, OSX, Solarish und Windows. Da es eigenständig ist, fast wie eine Mainboard Firmware bleibt es stabil auch wenn VMs Amok laufen. Da man darauf keine Dienste installieren kann, kommt man auch nicht in Versuchung komische Sachen zu machen und das mit Abhängigkeiten zu überladen. ESXi ist darauf ausgelegt mit externen SANs zu arbeiten - gerne auch virtualisiert unter ESXi. Damit hat man dann nicht nur den kommerziellen Marktführer was VMs angeht sondern auch State of the Art Storage (und die Storage VM macht da ausschließlich Storage)

 

[Stueckchen]

Naja du brauchst auch nicht unbedingt ben HBA, man kann auch den SATA-Controller des MB durchreichen.
Egal ob bei ESXi oder KVM/PVE hat es Vorteile Storage und Virtualisierung zu trennen.
PVE hat gegenuber esxi aber den Vorteil das man Container nicht in einer VM laufen lassen muss. So kann man VM und Container aus einer GUI verwalten.

 

[mauorrizze]

Ich finde das ist eine Frage der Prioritäten. Willst du Virtualisierung mit ein wenig Storage oder Storage mit ein bisschen Virtualisierung? Grundsätzlich sind beide Lösungsansätze ähnlich mächtig (mit Vorteil bei ESXi/Proxmox+Y), aber die GUI ist halt entsprechend priorisiert (IMHO mit Vorteilen bei Bedienung und geringeren Anfangshürden bei den Storage-GUIs)
Zum Lernen kann ich alles mal empfehlen, zum Dauereinsatz das am einfachsten zu wartende das mächtig genug ist.

Im Grunde möchte ich dem napp-it-/ESXi-Guru gea in nix widersprechen, aber auch noch mal ein Plädoyer für FreeNAS einlegen, das mit bhyve und (iocage) jails inzwischen auch gute Virtualisierungsoptionen bietet.

Vorteile mit Proxmox als Basis, egal ob natives ZFS oder in VM, liegen bei Linux & KVM (am wahrscheinlichsten schon etwas bekannter im Umgang, größere Hardwarekompatibilität, Möglichkeiten wie GPU-Passthrough von Consumer-Karten).
Vorteile ESXi ist der Enterprise-Einsatz und gea's all-in-one-Lösung mit langem Thread hier im Forum. Der SMB-Server von Solaris/SmartOS ist der einzige der Snapshots transparent durchreicht und dem Windows Client als Dateiversionen verfügbar macht.
Vorteile FreeNAS: am einfachsten eingerichtet, einfache Pflege, umfangreiche Storage-GUI und VM-GUI mit Grundfunktionen.

Zu den anderen Fragen:
Linux-Tool für SMART-Daten: smartctl/smartmontools
Spin-Down sollte überall gehen, ist nur je nach Umgebung schwierig den Zugriff ausreichend einzuschränken (cronjobs, laufende VMs, ...), kann große Wartezeiten beim Anlaufen nach sich ziehen (bis hin zu Timeouts, lässt sich aber alles konfigurieren) und die Lebenszeit der Platten könnte darunter leiden.

 

[27k1]

ESXi trennt das.
Als Virtualisierungsplattform braucht es die wenigste Leistung für sich selber. Auch hat es die beste Unterstützung nicht nur für Linux sondern auch BSD, OSX, Solarish und Windows. Da es eigenständig ist, fast wie eine Mainboard Firmware bleibt es stabil auch wenn VMs Amok laufen. Da man darauf keine Dienste installieren kann, kommt man auch nicht in Versuchung komische Sachen zu machen und das mit Abhängigkeiten zu überladen. ESXi ist darauf ausgelegt mit externen SANs zu arbeiten - gerne auch virtualisiert unter ESXi. Damit hat man dann nicht nur den kommerziellen Marktführer was VMs angeht sondern auch State of the Art Storage (und die Storage VM macht da ausschließlich Storage)

Der Stromverbrauch dürfte bei der Variante vermutlich auch höher liegen, sofern das relevant ist.

 

[konfetti]

Der Stromverbrauch dürfte bei der Variante vermutlich auch höher liegen, sofern das relevant ist.

Warum?
mit einem an die Storage-VM durchgereichten Controller, hat man alle Vorteile, die man auch Baremetall hätte - Nachteil, die VM hat fest zugewiesenen Speicher, der lässt sich auch nicht mal eben so erhöhen - und steht nicht per Ballooning anderen VMs zur Verfügung

 

[booyakasha]

danke für die vielen Antworten und Tipps

Stromverbrauch spielt eine Rolle. Mit einem HBA bin ich etwa bei +5 Watt

Baremetal FreeNAS kommt nicht in Frage wegen weiteren VMs. VMs innerhalb von FreeNAS sind ebenso keine option da ich dort dann zu stark an FreeNAS gekoppelt bin. Mir ist es wichtig die Storage VM auch mal abschalten zu können bzw. zu isolieren.

Das Durchreichen der Platten an eine Storage und dort ZFS laufen zu lassen entfällt da ich dann nicht die notwendigen Features habe.
SATA Controller des mainboards durchreichen entfällt auch, da ich dann kein Speicher für die VM images habe beziehungsweise hiefür wieder einen Controller bräuchte. Ich wäre also wieder auf am Start.

 

[Stueckchen]

SATA Controller des mainboards durchreichen entfällt auch, da ich dann kein Speicher für die VM images habe beziehungsweise hiefür wieder einen Controller bräuchte. Ich wäre also wieder auf am Start.

Hier gibt es einfache und sparsame Möglichkeiten.
Bei mir ist PVE auf einer SSD die am internen USB3.0 hängt. Auf der liegt dann nur die FreenasVM und noch die RouterVM. Der Rest liegt dann auf der storage VM, die Automatisch startet. Sonst ist auch noch eine PCIe SSD eine Option, sofern noch ein Steckplatz frei ist.

 

[gea]

Warum?
mit einem an die Storage-VM durchgereichten Controller, hat man alle Vorteile, die man auch Baremetall hätte - Nachteil, die VM hat fest zugewiesenen Speicher, der lässt sich auch nicht mal eben so erhöhen - und steht nicht per Ballooning anderen VMs zur Verfügung

Nur am Rande.
Feste Speicherzuweisung ist die einzige Variante bei der man mit ZFS glücklich wird. ZFS nimmt für den Schreib/Lesecache den Speicher der da ist. Es bleibt für ESXi kein Speicher den der variabel zuweisen könnte.

 

[konfetti]

Hi gea,

ja schon klar, deshalb: je mehr RAM, desto besser!

aber der Punkt, diesen nicht dynamisch erhöhen zu können bleibt!

 

[sch4kal]

Wenn Du schon Baremetall für den Storage in betracht ziehst, warum dann nicht FreeNAS oder Xigmanas direkt auf der Hardware installieren?
weitere kleinere VMs könntest Du ohne Probleme laufen lassen und kannst mit dem onboard-Ports auch ZFS mit den Disks nutzen.

Wenn Du natürlich nur den ESXi als Unterbau für eine NAS-VM ohne weitere VMs nutzen möchtest, würd ich das eh weglassen...

Naja, VMs unter bhyve laufen nicht "ohne Probleme", jedenfalls haben Sie es nicht bei meinen Versuchen getan. Manchmal startete die VM überhaupt nicht, endete im Kernel Panic des Gastsystems, etc.
Bhyve ist weit davon entfernt, so stabil und zuverlässig zu laufen wie ESXi.

 

[booyakasha]

Hier gibt es einfache und sparsame Möglichkeiten.
Bei mir ist PVE auf einer SSD die am internen USB3.0 hängt. Auf der liegt dann nur die FreenasVM und noch die RouterVM. Der Rest liegt dann auf der storage VM, die Automatisch startet. Sonst ist auch noch eine PCIe SSD eine Option, sofern noch ein Steckplatz frei ist.

Ist der on Board sata Controller dann voll für die vm verfügbar inklusive aller low Level zfs Funktionen und smart? Einen hba muss man ja extra als IT (den genauen Modus habe ich gerade nicht parat, ihr wisst es sicher 😄) flashen

 

[danielmayer]

Ja.

Hinweise: IT-Mode bzw. IR-Mode ist nur für RAID-Controller relevant, mir ist kein onboard-SATA-Controller bekannt, den das überhaupt treffen würde. Es gibt Addon-Karten mit SiL-Chip o.ä., die als SATA-RAID verkauft werden, da sollte man sich sicherlich schlauer machen.
edit: SIL-basierte Karten arbeiten aber nicht mit Firmware sondern mit Jumpern.

 

[00riddler]

Vorteile mit Proxmox als Basis, egal ob natives ZFS oder in VM, liegen bei Linux & KVM (am wahrscheinlichsten schon etwas bekannter im Umgang, größere Hardwarekompatibilität, Möglichkeiten wie GPU-Passthrough von Consumer-Karten).
Vorteile ESXi ist der Enterprise-Einsatz und gea's all-in-one-Lösung mit langem Thread hier im Forum. Der SMB-Server von Solaris/SmartOS ist der einzige der Snapshots transparent durchreicht und dem Windows Client als Dateiversionen verfügbar macht.
Vorteile FreeNAS: am einfachsten eingerichtet, einfache Pflege, umfangreiche Storage-GUI und VM-GUI mit Grundfunktionen.

So ganz stimmt das mit den Windows Dateiversionen und ZFS Snapshots nicht.
Bei mir macht das Freenas in der aktuellen Version out of the box. Mit welcher Version das eingeführt wurde kann ich dir allerdings nicht genau sagen.

 

[MisterY]

Warum nicht OMV (kommt auch mit ZFS) + Webvirt?

 

[VirtuGuy]

ShadowCopy ist ein Feature vom Samba/Cifs Server, nicht vom Filesystem:

[global]
shadow: snapdir = /hier-sind-meine-snapshots

 

[gea]

ShadowCopy ist ein Feature vom Samba/Cifs Server, nicht vom Filesystem:

[global]
shadow: snapdir = /hier-sind-meine-snapshots

Es gibt einen gravierenden Unterschied zwischen SAMBA und dem Solaris Kernel/ ZFS basierten SMB Server. Bei Solarish ist ein SMB Share eine Eigenschaft eines ZFS Dateisystems, genau wie Snapshots eine Eigenschaft eines Dateisystems sind.

Einem Share \\nas\data liegt immer ein Dateisystem data zugrunde. Die ZFS Snaps dieses Dateisystems liegen in \\nas\data\.zfs\snapshot. Liegt darunter ein weiteres Dateisystem data/a das als a geshart wird, so sind dessen Snaps in \\nas\a\.zfs\snapshot. Beim Zugriff auf ein Share findet Windows daher immer die ZFS Snaps - ohne dass man was beachten müsste.

SAMBA weiß nichts von ZFS. Es ist ein universeller SMB Server für alle X Plattformen - egal mit welchem Dateisystem. Ein Share ist ein beliebiger Pfad, egal ob das ein ZFS Dateisystem oder ein einfacher Ordner ist. Genau so verhält es sich mit Unterordnern. SAMBA unterscheidet nicht zwischen Dateisystem und Ordner.

Wenn SAMBA die ZFS Snaps sauber zuordnet, ist das damit die Ausnahme und nicht der Regelfall und klappt nur wenn man selber sich ausreichend Gedanken über die Struktur macht oder indem man eben nur ein einziges Dateisystem freigibt und darunter gibt es nur einfache Ordner. Nur dann hat man ein globales Snapverzeichnis.

 

[VirtuGuy]

Einem Share \\nas\data liegt immer ein Dateisystem data zugrunde. Die ZFS Snaps dieses Dateisystems liegen in \\nas\data\.zfs\snapshot. Liegt darunter ein weiteres Dateisystem data/a das als a geshart wird, so sind dessen Snaps in \\nas\a\.zfs\snapshot. Beim Zugriff auf ein Share findet Windows daher immer die ZFS Snaps - ohne dass man was beachten müsste.

Sprich, die Snapshots müssen an Ort und Stelle bleiben und ich müsste mit Symlinks o.ä. basteln damit ich diese verlagern kann?

Es gibt einen gravierenden Unterschied zwischen SAMBA und dem Solaris Kernel/ ZFS basierten SMB Server. Bei Solarish ist ein SMB Share eine Eigenschaft eines ZFS Dateisystems, genau wie Snapshots eine Eigenschaft eines Dateisystems sind.

SAMBA weiß nichts von ZFS. Es ist ein universeller SMB Server für alle X Plattformen - egal mit welchem Dateisystem. Ein Share ist ein beliebiger Pfad, egal ob das ein ZFS Dateisystem oder ein einfacher Ordner ist. Genau so verhält es sich mit Unterordnern. SAMBA unterscheidet nicht zwischen Dateisystem und Ordner.

Nutzt man die entsprechenden Tools wie sharesmb, werden unter ZoL die ZFS Eingeschaften für die Anlage eines Shares verwendet. Samba braucht nicht mehr zu wissen, es wäre auch eher hinderlich da nicht jeder Share rein an "lokale" Platten oder Filesysteme gebunden ist. Bei verteilten Dateisystemen werden Snapshots auf billigere Spindeln ausgelagert => in dem Fall möchte ich auch keine Bindung an ein lokales Dataset.

Wenn SAMBA die ZFS Snaps sauber zuordnet, ist das damit die Ausnahme und nicht der Regelfall und klappt nur wenn man selber sich ausreichend Gedanken über die Struktur macht oder indem man eben nur ein einziges Dateisystem freigibt und darunter gibt es nur einfache Ordner. Nur dann hat man ein globales Snapverzeichnis.

Bei einer 5-10 Jahre alten Samba Version, könnte ich dir durchaus rechtgeben. Heute läuft es aber Einwandfrei, egal ob auf einzelne Shares oder global verteilt auf einem verteilten Dateisystemen. Bitte bei deiner Betrachtung die Existenz anderer Lösungen abseits von ZFS beachten, ZoL ist immer noch eine eher exotische Lösung. Und genau da sind halt auch Probleme zu Erwarten wenn man abweichende Snapshotscripte nutzt.


Zu den restlichen Fragen:

* zfs routinen (scrubbing, snapshots, ...) nur als CLI und nicht über gui

=> korrekt, wird von den Entwicklern auch nicht mit prio behandelt.


* keine SMART infos?

=> am jeweiligen Node unter "Disks" => Button "show smart values"


* kein Spin down?

=> nein, der hat bei einer Lösung zur Virtualisierung von vielen Servern eher hinderlich. Du kannst es im Grunde recht einfach einbinden, aber ich würde davon eher abraten. Ein kleiner Fehler reicht dann schon und deine Platten werden laufend wieder geweckt => nicht förderlich.


* das ganze klickibunti von FreeNAS entfällt?

=> du kannst freenas ggf als VM einrichten

 

[gea]

Bei einer 5-10 Jahre alten Samba Version, könnte ich dir durchaus rechtgeben. Heute läuft es aber Einwandfrei, egal ob auf einzelne Shares oder global verteilt auf einem verteilten Dateisystemen. Bitte bei deiner Betrachtung die Existenz anderer Lösungen abseits von ZFS beachten, ZoL ist immer noch eine eher exotische Lösung. Und genau da sind halt auch Probleme zu Erwarten wenn man abweichende Snapshotscripte nutzt.

Bei der Frage ging es nur um ZFS bzw CopyonWrite Dateisysteme. Bei denen sind Snaps immer Teil des jeweiligen Dateisystems da hier Snaps nicht durch Kopieren erzeugt werden sondern den früheren Datenstand vor Änderung darstellen.

Natürlich kann man ZFS Snaps auch mit SAMBA abbilden insbesondere wenn man das Solarish Verhalten nachbildet (Share=Dateisystem). Ob man das mit symlinks tricksen kann habe ich nie versucht.

Man kann das eben sauber ninkriegen, muss man nicht, eine der vielen Optionen von SAMBA. Man muss auf jeden Fall Bescheid wissen und das beachten.

Bei Solarish SMB ist das ein Muss, man kann nichts falsch machen, tut einfach. Dafür fehlt manchmal Flexibilität die SAMBA bietet.

 

[booyakasha]

Sprich, die Snapshots müssen an Ort und Stelle bleiben und ich müsste mit Symlinks o.ä. basteln damit ich diese verlagern kann?





Nutzt man die entsprechenden Tools wie sharesmb, werden unter ZoL die ZFS Eingeschaften für die Anlage eines Shares verwendet. Samba braucht nicht mehr zu wissen, es wäre auch eher hinderlich da nicht jeder Share rein an "lokale" Platten oder Filesysteme gebunden ist. Bei verteilten Dateisystemen werden Snapshots auf billigere Spindeln ausgelagert => in dem Fall möchte ich auch keine Bindung an ein lokales Dataset.




Bei einer 5-10 Jahre alten Samba Version, könnte ich dir durchaus rechtgeben. Heute läuft es aber Einwandfrei, egal ob auf einzelne Shares oder global verteilt auf einem verteilten Dateisystemen. Bitte bei deiner Betrachtung die Existenz anderer Lösungen abseits von ZFS beachten, ZoL ist immer noch eine eher exotische Lösung. Und genau da sind halt auch Probleme zu Erwarten wenn man abweichende Snapshotscripte nutzt.


Zu den restlichen Fragen:

* zfs routinen (scrubbing, snapshots, ...) nur als CLI und nicht über gui

=> korrekt, wird von den Entwicklern auch nicht mit prio behandelt.


* keine SMART infos?

=> am jeweiligen Node unter "Disks" => Button "show smart values"


* kein Spin down?

=> nein, der hat bei einer Lösung zur Virtualisierung von vielen Servern eher hinderlich. Du kannst es im Grunde recht einfach einbinden, aber ich würde davon eher abraten. Ein kleiner Fehler reicht dann schon und deine Platten werden laufend wieder geweckt => nicht förderlich.


* das ganze klickibunti von FreeNAS entfällt?

=> du kannst freenas ggf als VM einrichten

mir scheint die vorgeschlagene Lösung, den onboard controller direkt an die freenas VM durchzureichen am besten.
ZFS features sind über FreeNAS gesichert.
Jetzt gilt es nur richtig zu zählen bei der Verfügbarkeit der USB Storages für den Boot von Promox und Storage der VMs

 

[Trambahner]

Was macht es für einen Sinn, innerhalb Proxmox, das selber ZFS (als ZoL) kann, eine weiteres OS für ZFS zu installieren und Controller an diese durchzureichen? Dann kann ich gleich ESXI hernehmen.
Nochdazu, wo FreeNAS nicht gerade für das Sparen bei den Ressourcen bekannt ist.

 

[booyakasha]

Was macht es für einen Sinn, innerhalb Proxmox, das selber ZFS (als ZoL) kann, eine weiteres OS für ZFS zu installieren und Controller an diese durchzureichen? Dann kann ich gleich ESXI hernehmen.
Nochdazu, wo FreeNAS nicht gerade für das Sparen bei den Ressourcen bekannt ist.

es ist wie immer ein Abwägung was man tut. Die Nachteile hast du gerade beschrieben.

Die Vorteile:
* ich habe ein isoliertes system
* anstelle proxmox zu booten (wenn ich proxmox zerschossen habe) kann ich mit einem stick und der config freenas booten und bin good to go
* alle zfs features inklusive alarmierungsmechanismen sind in freenas vorhanden und umgesetzt

 

[Stueckchen]

Was macht es für einen Sinn, innerhalb Proxmox, das selber ZFS (als ZoL) kann, eine weiteres OS für ZFS zu installieren und Controller an diese durchzureichen? Dann kann ich gleich ESXI hernehmen.
Nochdazu, wo FreeNAS nicht gerade für das Sparen bei den Ressourcen bekannt ist.

Naja mit diesem Argument kann man sogut wie jede Virtualisierung in Frage stellen. Fast jedes Linux kann ZFS, Storage und anderer Serverdienste, warum überhaut einen Hypervisor.

Also ich habe es auch mit PVE und Freenas gelöst, und kann booyaskash nur zustimmen. Hinzu kommt eine ansprechende GUI und leichte Bedienung. Wenn ich will kann ich leicht auf Esxi, Xen oder Blech umziehen mit der Storage VM.

Und der einzige richtigr Nachteil den Freenas in meinen Augen hat: man ist sehr auf die GUI fixiert. CLI ist irgendwie immer umständlich.