Neukonfiguration des Homelab Setup (Proxmox/Nappit)

hoyohayo

Profi
Thread Starter
Mitglied seit
02.02.2017
Beiträge
45
Hallo liebe Luxxer,

Ich bin jetzt schon ein Weilchen auf der Suche nach der "Optimal-Lösung" für mein Heimnetzwerk und komme noch nicht auf einen grünen Zweig. Ich bräuchte da vielleicht ein wenig Hilfestellung.

Zum Ausgangszustand:

Als Netzwerk steht parat:

  • Unifi Security Gateway [Keller]
  • Unifi 24x POE+ Switch, 2xSFP+ [Keller]
  • Unifi AC AP Lite [Wohnung]
  • Draytek Vigor 130 Modem [Wohnung]
  • Diverse 1Gbit/s unmanaged Switches [Wohnung]

Als Clients habe ich hier:

  • Gaming Kiste, Anbindung 1Gbit/s, CAT6
  • 2 Laptops, AC Wlan
  • 3 Pi's, 1 Odroid C2, Anbindung 1Gbit/s, CAT6
  • Diverse mobile Abnehmer

Mein aktueller Server steht auf Proxmox Basis im Keller und ist über den NIC mit LACP über 4 Ports mit dem Unifi Switch verbunden.
Im Server verbaut sind an Hardware:

  • Fujitsu D3417-B2
  • Intel G4560
  • 32GB RAM
  • 2x 8TB HGST Deskstar
  • 2x 4TB WD Red
  • 500GB NVME M2 SSD Samsung 960 EVO
  • Intel I350-T4 NIC

Auf dem Server laufen virtualisiert als Filer ein OMV, welches den Sata Controller des Mainboards durchgereicht bekommen hat.
Hier laufen alle HDDs im Moment ohne Raid und soweit ich das feststellen kann, laufen Sie leider auch 24/7 ohne Sleep was dem Stromverbrauch nicht gerade dienlich ist. Die SSD dient natürlich der Proxmox Installation und als Installationsplatz der VMs, die dann zusätzlichen Speicherplatz durch OMV per NFS bekommen.
Backups werden im Moment nicht automatisch erstellt sondern die wichtigen Daten werden manuell auf einer externen Festplatte gesichert. Das geschieht allerdings über den PC in der Wohnung, der auf die Daten über SMB zugreift (Win10 Client).
Auf dem Hypervisor liegen noch diverse VMs bzw. LXC, die leider derzeit kein Backup erfahren, die ich aber gerne sichern würde. Außerdem ist eine APC Back-UPS Pro 900VA vorhanden, die per apcupsd auf der Proxmox Installation angesprochen wird.

Unter anderem wird eine Nextcloud Installation (Ubuntu LXC Nr.1) betrieben, sowie der Unifi-Controller (Ubuntu LXC Nr.2) (nicht so wichtig für ein Backup), ein Pi-hole (Debian LXC Nr.3)und eine halbwegs produktive Win10-VM, die über eine VPN Verbindung zum UnifiSG und dann per RDP ansprechbar ist.


Ich würde nun gerne die Grundlegende Struktur des Servers ändern.
Das Ganze steht aktuell in einem Fractal Design R5, soll aber umziehen in ein Intertech IPC 4U-4410.
Ich habe derzeit noch 2 weitere WD Red à 4TB in meiner Gaming Kiste untergebracht, diese sollen ebenfalls in den Server umziehen.



Mein Ziel am Ende ist es, dass ich ein ZFS (RaidZ2?) in einer VM via OmniOS(?) -> napp-it erstelle um als Filer zu dienen. Die M2 soll weiterhin als Proxmox Basis dienen und Installationsmedium für die VMs.
Hier wird also weiterhin der Sata Controller des Mainboards durchgereicht?

Am schönsten wäre es dann, wenn ich von dem Storage einfach per SMB (Multichannel möglich?) mit fast allen Clients darauf zugreifen kann.
Wobei NFS für die Kodi Installationen, sowie die Proxmox Einbindung unentbehrlich ist.
Über Proxmox habe ich dann die Möglichkeit regelmäßige Backups der VMs/LXC zu machen und diese dann auf der Napp-it VM zu speichern.

Was passiert wenn die Proxmox Installation einen Defekt aufweist? Sind dann die Daten der Napp-it VM ebenfalls ad acta?

Wäre es dann sinnvoller einen zweiten Server als reinen Filer zu bauen, der dann in das Intertech zieht und diesen über eine 10Gbit/s NIC an den Switch zu hängen, genauso wie den Hypervisor, der dann eine 10Gbit/s NIC bräuchte für den SFP+?

Ich würde mich sehr freuen über Empfehlungen, die ihr aus eigenen Erfahrungen aussprechen könnt.
Vielleicht habe ich auch schon bei der Hardware ein paar Fehler eingebaut, die ich noch nicht bemerkt habe (ECC Unterstützung des G4560?).
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mein Ziel am Ende ist es, dass ich ein ZFS (RaidZ2?) in einer VM via OmniOS(?) -> napp-it erstelle um als Filer zu dienen.

Wahrscheinlich war es eigenes Unvermögen, aber ich bin mit einem ähnlichen Ansatz gescheitert. Solaris oder OmniOS habe ich unter Proxmox nicht wirklich vernünftig zum Laufen bekommen. Ich bin dann (wieder zurück) auf ESXi gegangen...
 
Ich sehe bei der Anforderung auch keinen wirklichen Bedarf für eine Storage VM. Proxmox bringt passablen ZFS Support mit, diesen würde ich auch nutzen.
 
Naja. VMs und LXCs würde ich evtl auch auf dem Proxmox ZFS Pool ablegen. Aber für Content finde ich eine dedizierte Storage VM mit eigenen Platten ebenfalls geschickt. Die WebGUI von Proxmox ist nicht dafür ausgelegt, vernünftig Samba, NFS Freigaben usw. zu erstellen. Und auch eine Trennung von Hypervisor und Content halte ich für geschickt.
 
Ich würde schon gerne den Content (Filme/Bilder für Kodi, FHEM-Backups, Storage für die Nextcloud) auf eine vernünftige Verwaltung packen. Ist jetzt die Frage ob man das trennen kann/sollte, oder ob eben der Ansatz Napp-it/Proxmox funktioniert. Außerdem stellt sich mir noch die Frage ob es überhaupt möglich ist, einen ZFS Pool auf einer einzelnen SSD anzulegen? Ich dachte das wäre sowohl quatsch als auch nicht machbar, da dann immer noch keine Redundanz gegeben ist oder?

Oder soll sich der ZFS Pool über die SSD und alle HDDs erstrecken? Dann wäre hier allerdings die Storage VM nicht mehr machbar und ich glaube die Performance der einzelnen VMs geht auch in die Knie, wenn Sie nicht die SSD nutzen oder?

Belehrt mich bitte eines besseren, sollte ich hier falsche Annahmen treffen!
 
Bei zfs geht es nicht (nur) um Redundanz
Ein Pool kann natürlich auch nur aus einer Disk bestehen.
Pool über SSD und HDDs ist Mist, wie du schon erkannt hast.
 
Das du Backups auf Cold Storage legen möchtest ist klar. Aber um wieviel Daten geht es denn z. B. bei NextCloud oder dem Rest?
Vor allem was ist eine Anforderung an die Verwaltung der möglichen Freigaben? Wenn es ein "set-and-forget" ist, braucht man m. M. n. nicht unbedingt eine GUI. Zumal der lerneffekt, wenn dieser überhaupt gewünscht ist, ohne GUI wesentlich höher ist.

Gea hatte vor Monaten (wenn nicht gar Jahren) mal geschrieben, dass Napp-IT theoretisch unter Linux läuft, allerdings viele Befehle auf Solaris abgestimmt sind. Heißt es wird nicht alles funktionieren. Ob es mittlerweile einen richten Linux port/fork gibt weiß ich nicht.
 
Es dreht sich insgesamt um einen Bereich von ca. 4-6TB die an Filmen, Bildern, Doks und Nextcloudspace bereitgestellt werden sollen. Erweiterbar soll es bleiben und ich würde gerne ebenfalls mindestens einen RaidZ1 bauen wollen um einem Hardwarefail vorzubeugen.

Lerneffekt ist durchaus gewünscht, allerdings ist die Zeit die ich in sicheren Storage investieren möchte auch begrenzt. Deshalb war ich am Anfang bei GUI, da einem doch viele Aufgaben abgenommen werden. Da hätte ich wohl sonst noch eine Menge mit Begrifflichkeiten zu tun.

Ist es denn sinnvoll einen einzelnen ZFS Pool auf der SSD aufzuspannen? Soweit ich das verstanden habe, werden mit Hilfe der Prüfsummen einfach Fehlern im Dateisystem vorgebeugt. Geht es dann nicht schon arg auf die Performance bei den 32 GB Ram, wenn ich nen ZFS auf die SSD packe und noch ein ZFS auf eine Storage-VM?

Anforderungen an die Verwaltung, sind hauptsächlich Backups, die versioniert werden sollen und nach Alter dann gelöscht werden können. Es soll eine Rechteverteilung geben, wer Zugreifen/Lesen/Schreiben kann und eben gegen den Ausfall von maximal 2 Platten gesichert sein. Ansonsten ist es denke ich eher so, dass ich die Verwaltung einmal vornehme und dann nicht mehr viel drüber nachdenken möchte. Sie sollte Umzugsfähig/HotSwapfähig sein, wenn das ein Anhaltspunkt ist. Im Sinne von evtl auf ein neues Motherboard bzw. vorerst nur ein neues Gehäuse.
 
Zuletzt bearbeitet:
Der (reine) ZFS-Teil funzt bei Nappit auf Linux nach meiner Erinnerung durchaus. Was halt nicht damit über die GUI geht, ist die ganze Netzwerk-Verwaltung rund um Samba-Freigaben, iSCSI & Co. weil es bei Linux hierzu eben keine 1:1 Entsprechung wie bei Solarish gibt. Auch das mit den Rechten/ACLs lässt sich über nappit auf Linux wahrscheinlich nicht (so gut) steuern. Ist bei mir aber auch schon eine Weile her, Versuch macht kluch (oder gea :d ).

Mach dir wegen RAM mal keine so großen Sorgen, für das Abspielen eines Films brauchst Du eh keinen Read-Cache (bringt auch nix, es sei denn z.B. mehrere schauen parallel den gleichen Film). Und wenn du mit 32GB baremetal fährst, reicht das sowieso dicke für so ziemlich alles @home.
 
Die Linux Version von napp-it unterstützt das was plattformübergreifend zwischen Solaris und Linux gleich ist. Das ist alles um die Befehle zpool, zfs und die Automatismen die auf Perl basieren, also Disk und ZFS Management, Replikation und Jobmanagement (Autosnap, Autoscrub, Replikation)

Die wesentlichen sonstigen Komponenten von napp-it basieren auf den Solarish Projekten kernelbasierter SMB Server, Comstar (FC/iSCSI), Crossbow (Netzwerkvirtualisierung), SMF (Servicemanagement) sowie der einheitlichen Art der Plattenidentifizierung über eindeutige WWN Nummern. All das steht unter Linux nicht zur Verfügung bzw wird durch andere Projekte abgedeckt - manchmal je Linux Distribution was anderes. Auch gibt Linux mit ZFS nicht die OS Setup und alles tut Erfahrung wie unter Solarish. Alles ist bei jeder Distri etwas anders und schon ein einfaches Update kann das ganze zum Nicht-Funktionieren bringen. Die volle Linux Unterstützung würde eine komplette Neuentwicklung von napp-it für eine ausgewählte Linux Distribution bedeuten da selbst bei sehr ähnlichen Distributionen wie Debian und Ubuntu erhebliche Unterschiede bestehen. Da sind die verschiedenen Solarish Distributionen um Welten ähnlicher. Da ich napp-it primär für meine eigenen Installationen entwickelt habe (alles ESXi und Solarish) wird es so eine Full-Featured Version von napp-it für Linux absehbar nicht geben. Für reines ZFS und Job Management kann man napp-it aber durchaus nehmen. Wer will könnte auch das Fehlende über eigene Menüs ergänzen (eines der Features von napp-it).

Gefühlt hat die Linux Version allenfalls 30% des Funktionsumfangs der Solarish Version.
 
Zuletzt bearbeitet:
Hmm okay, das bedeutet entweder sattel ich auf einen anderen Hypervisor um oder ich muss mir alternative Gedanken machen um ein anderes Dateisystem bzw. Storage-VM. Hat denn jemand dort eine alternative im Angebot?

FreeNAS auf BSD ist wohl etwas zu überdimensioniert bzw. teilweise auch einfach das Falsche an der Stelle oder?

Hat jemand schon Erfahrung mit ZFSonLinux bei OMV? Gibt es dort ja als plugin. Ist das dann ebenfalls mit GUI Support?

Ist denn ZFS hier wirklich das beste oder kann ich mit BTRFS ähnliches erreichen, was vielleicht dann auch einen GUI Support hat?

Erstmal danke ich euch aber noch für eure Antworten.

Am Ende könnte man dann wahrscheinlich überlegen zwei Systeme hinzustellen, einen als puren Filer auf zB. OmniOS Basis mit Napp-it und dann Proxmox als zweiten Rechner ins gleiche Rack und dann mit 1Gbit/s oder sogar 10Gbit/s Uplink (wobei mir aufgefallen ist, dass der vorhandene Switch nur SFP und nicht SFP+ hat und daher nur 1Gbit/s).
 
Wie du schon selbst erkannt hast, in einem Home Setup macht man idR nur eine Handvoll User/Freigaben und dann läuft der Kram über Jahre. Von daher würde ich die Freigaben am Host anlegen:

zfs set sharesmb=on rpool-daten/documents


Die Freigaben sind im Pool gespeichert, der Umzug auf einen anderen Server ist entsprechend einfach. Natürlich hat eine Trennung den Vorteil das es einfacher ist die Daten Hochverfügbar zu machen. Sofern du jedoch keinen zweiten Host mit der entsprechenden Kapazität aufbaust, würde ich mir darüber keine großen Gedanken machen.
 
Das bedeutet, dass ich in Proxmox einfach zwei zpools anlege, einen über die SSD, einen über die HDDs und dann die Proxmox GUI bzw Shell dafür nutze um die Freigaben einrichten zu können richtig?
Das wäre die einfachste Variante wenn ZFS gewollt ist.
 
Hmm, das macht mich noch nicht wirklich glücklich.
Ist denn ZFS hier das Non-Plus-Ultra oder bieten andere Datei-Systeme nicht vielleicht ähnlich gute Features, die man dann mit Hilfe einer Storage VM realisieren könnte?
 
Wenn du eine Webgui willst, kannst du jede beliebige Lösung verwenden. ZFS Support ist nicht erforderlich, den Part kann der Host übernehmen.
 
Für mich nicht schlüssig. Ich weiß, dass Du, Virtuguy, ein Proxmox Verfechter bist. Ich setze Proxmox seit ca sieben Jahren sehr gerne ein, aber als Storage-Server-Ersatz macht das für mich null Sinn.
Installiere Dir eine gute Storage VM, reiche der die Platten/Controller für den Content durch und lass die VMs auf den SSD ZFS Pools von Proxmox.
 
Für mich nicht schlüssig. Ich weiß, dass Du, Virtuguy, ein Proxmox Verfechter bist. Ich setze Proxmox seit ca sieben Jahren sehr gerne ein, aber als Storage-Server-Ersatz macht das für mich null Sinn.
Installiere Dir eine gute Storage VM, reiche der die Platten/Controller für den Content durch und lass die VMs auf den SSD ZFS Pools von Proxmox.

Ich bin eigentlich eher ein ESX/Hyper-V Mensch, Proxmox ist für mich eher eine Low-Cost Lösung. Vielleicht ein wenig mehr Hintergrund zu "meiner" Überlegung:

Egal ob du die Daten nun am Host oder auf eine VM mit durchgereichten Platten lagerst - in beiden Fällen bist du an die Hardware gebunden. In dem Fall sehe ich keinen Unterschied wenn die Freigaben gleich direkt am Host laufen. Die ganzen Überlegungen zwecks passenden HBA den man durchreichen kann, die Storage VM, die manuelle Einbindung der Freigaben in den Host,.. - das sind alles Dinge die in einem simplen Setup für mich keinen Sinn mehr ergeben. Nutze ich den Host, kann ich bei einem HW Tausch die Platten einfach umstecken und die SMB/NFS Freigaben werden vom neuen Proxmox Host automatisch übernommen. Den einzigen Aufwand den ich habe, ist die manuelle Anlage der User/Gruppen. Aus meiner Sicht ist der Aufwand dafür bei Home-Use(!) zumeist recht überschaubar, speziell im Vergleich zum Aufwand eine Storage VM einzubinden.

Schlüssiger wäre wohl eine File Service VM ohne Bindung an die Hardware des Hosts. Diese ist im Fall hat man weiterhin auch alle Vorteile einer VM, inkl PVE Backup/Migration/Replikation in Laufzeit.
 
So ähnlich habe ich das mangels Passtrough Unterstützung meiner HW gemacht.

Solaris/Napp-It als Host und Storage für die Daten und VMs.
Die VM laufen in Virtual Box auf Solaris.

Und dank VNC brauche ich weder eine Weboberfläche(vBox) noch mich mit der Shell Syntax für vBox rumschlagen ^^

In wie fern hier dann eine "live" migration via ZFS send möglich ist, habe ich aber nicht getestet.
 
Zuletzt bearbeitet:
Okay, danke für eure Tipps.

Dann wirds entweder irgendwann hardwaretechnisch getrennt (Hypervisor und Filer sind dann zwei Maschinen, da kann der Hypervisor ja auch in nem kleinen u/itx Case sitzen, wo ne 1gbit/s Karte rein kommt und der Filer kann größer werden.

Oder ich experimentiere mit ESXi ein wenig und gucke ob ich das wirklich so haben möchte.

Wahrscheinlich kann ich dann aber auch weiterhin meine OMV-VM nutzen und dort mit ZFSonLinux experimentieren.

Wenn sonst noch jemand Tipps/Anregungen/Vorschläge hat, gerne immer her damit.
 
Oder ich experimentiere mit ESXi ein wenig und gucke ob ich das wirklich so haben möchte.

Kann ich nur empfehlen.Ist ja schnell auf nen USB Stick etc installiert.Hatte vorher auch ESXi aber bin wie oben erwähnt dann auf Bare Metal Solaris umgestiegen, weil ich RDM nicht (mehr) nutzen wollte.
Und dank meinem gelangweiltem Pi und etwas experiementier Laune läuft der aktuell wieder in der VmWare Workstation und bootet über iSCSI vom Pi ^^
 
ESXi und RDM für Sata Platten ist auch eine Fummelei.

Wenn man einen SAS HBA hat ist das ganz anders.
Den kann man entweder komplett per pass-through an eine VM durchreichen oder aber daran angeschlossene Einzelplatten per Web-UI komfortabel einer VM hinzufügen. Die wird dann direkt inkl Smartunterstützung durchgereicht.
 
Auch wenn es deine Sätze schon implizieren, will ich doch mal nachfragen.
Es müssen auch SAS HDDs am SAS HBA sein und nicht nur ein SAS HBA mit SATA HDDs, oder ?
 
Es gehen auch Sata Platten.
Bei SAS Platten wird lediglich zusätzlich der Produktname angezeigt.
 
D.h ich kann mit meinem H310 (nennen wir es mal) offizielles RDM (Da ja über Web-UI möglich)mit SATA Platten nutzen oder ist das auch auf pass-trough (VT-x) angewiesen (ähnliches splitting wie bei PCIe Bifurcation) ?

Ich musste da jetzt nochmal nachhacken.
 
Zuletzt bearbeitet:
Das Durchreichen einer kompletten PCI-e Karte erfordert nicht nur vt-x sondern zusätzlich vt-d.
RDM reicht einzelne Platten durch und arbeitet über den SAS Treiber von ESXi, geht also ohne vt-d.
Getestet habe ich direktes RDM ohne Console-Fummelei mit ESXi 6.7 (Einstellungen, Disk hinzufügen)

ps
Die PCI Lanes werden bei pass-through nicht gesplittet sondern der komplette Adapter mit allen Lanes durchgereicht. Bifurkation braucht man z.B. um mehrere 2x oder 4x NVMe in einem 8x oder 16x Slot per Adapter zu betreiben.
 
Das Durchreichen einer kompletten PCI-e Karte erfordert nicht nur vt-x sondern zusätzlich vt-d.
Danke, die verwechsle ich immer.

Die PCI Lanes werden bei pass-through nicht gesplittet sondern der komplette Adapter mit allen Lanes durchgereicht. Bifurkation braucht man z.B. um mehrere 2x oder 4x NVMe in einem 8x oder 16x Slot per Adapter zu betreiben.
Diente auch nur als Beispiel, um meinen Gedankengang zu verdeutlichen.Hat aber am Ende vlt. mehr verwirrt.


Jedenfalls gut zu wissen, da ich ESXi eigentlich mag, auch wenn ich so akut nicht direkt Bedarf habe meine Lösung wieder auf ESXi zu drehen.
 
Zuletzt bearbeitet:
FreeNAS auf BSD ist wohl etwas zu überdimensioniert bzw. teilweise auch einfach das Falsche an der Stelle oder?
Die Alternative zu FreeNAS heist NAS4Free und richtet sich eher an die Puristen <> nicht ganz soviel "KlickiBunti", hat aber auch etwas weniger Features (aka "Überflüssige" nicht NAS bezogene Dienste) von Haus aus
 
Es ist jetzt einige zeit ins Land gegangen, es haben sich noch ein paar Daten angehäuft und aufgrund der Tatsache, dass sich mein Hardware Pool auf insgesamt 4x4TB und 2x8TB erweitert hat, würde ich das Projekt gerne nochmal angehen.

Allerdings werde ich glaub ich die von den meisten usern hier verwendete Art der Virtualisierung über ESXi und der Napp-It Vm bevorzugen. (Muss ich den Thread jetzt verschieben?)

Wenn ich das richtig verstanden habe, sollte ich mit der Konfig die auf der ersten Seite steht einen passablen Hypervisor vorweisen können inklusive VT-d, VT-x, AMT und eigentlich auch ECC vorrausgesetzt die Riegel unterstützen es?
(Meine aber das hab ich gecheckt, da laufen einmal: Samsung 16GB DIMM und einmal: Kingston 16GB DIMM außerdem zeigt mir zumindest ein lshw ein errordetection = ecc und dmidecode ein single-bit ecc an.)

Jetzt fehlt mir, um das Ganze korrekt anzubinden und kein RDM in einem ESXi frickeln zu müssen, nur ein HBA. Da hab ich mich jetzt auch belesen und ich habe es so verstanden, dass wenn ich mir z.B. IBM M1015 kaufe, den flashe auf einen LSI 9211-8i mit IT-Mode, dann habe ich alles was ich brauche um die Platten direkt an eine VM zu reichen, dort napp-in-one aufzusetzen und fertig ist der Spaß.

Ist das mit dem D3417-B2 möglich? Ich hab in einigen Foren gelesen, dass der HBA bei der Wahl des Boards zum flashen etwas picky ist.

Habe ich nun etwas vergessen, wasvielleicht noch wichtig sein könnte? Ich müsste doch nach dem Einbau einfach ein ESXi auf der NVMe platzieren können, und dort ebenfalls später die VMs ablegen. Außerdem kann ich den Storage dann über Napp-it an die VMs weiterreichen per SMB/NFS/iSCSI(nur bedingt) usw.

Ich hoffe ihr könnt mir die Vermutungen bestätigen oder mich auf etwas hinweisen, dass ich vergessen habe!
 
Du sprichst im OP an, dass du gerne Strom sparen würdest.

Wie sieht es denn mit unRAID aus? Hast du darüber schon mal nachgedacht? Die Software ist zwar nicht kostenlos, aber ich finde die Lösung für ein Datengrab recht charmant. Docker ala NextCloud sind dort auch verfügbar. Der große Vorteil ist hier, dass die Dateien nicht über mehrere HDDs aufgeteilt werden. Somit fährt nur 1 HDD hoch und der Rest bleibt im Spindown.
Vielleicht hat @gea dazu noch ein paar gute Anmerkungen.
 
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