Vorstellung aktueller Home-Server für Vorschläge/Diskussion zur Verbesserung

Shutterfly

Enthusiast
Thread Starter
Mitglied seit
30.01.2016
Beiträge
1.521
Moin moin,

in diesem Beitrag würde ich gerne meinen Heim-Server samt aktuellem und zukünftigem Einsatzzweck darlegen um mir von euch Vorschläge und Ideen zu holen, da ich hin und wieder nicht ganz zufrieden mit dem System bin bzw. das Gefühl habe, dass es sehr stark nach Bastellösung schmeckt - was nun aber grundsätzlich nicht schlecht sein muss.

Ziel ist, dass ich möglichst viele Dienste lokal zuhause betreibe um meine Daten nicht überall im Netz zu verteilen.

Aktueller Einsatzzweck:
- NAS-Funktionalität per CIFS/SMB
- Virtualisierungsumgebung (aktuell nur pfsense)
- Firewall, DNS, openVPN per pfsense
- Media-Server per emby
- nginy reverse proxy mit LetsEncrypt Wildcard Zertifikat
- GitLab und Mattermost

Aktuelle Hardware:
- Intel i3 6100
- Super Micro X11SSH-LN4F
- 16GB ECC DDR4
- 4x 2TB Werstern Digital Red (für NAS-Funktionalität)
- 1x 500GB Samsung NVMe SSD (für OS)
- Zusätzlich Dual Gigabit HP LAN-Karte (für pfsense)

Aktuelle Software:
- Arch Linux als OS
- KVM für pfsense als Firewall mit dedizierter HP LAN-Karte
- Docker mit Container für nginx, GitLab und Mattermost
- NAS-Funktionalität über SnapRAID und mergerfs (1 Platte für Parität) sowie Samba für CIFS/SMB
- Alle Festplatten und SSD sind per LUKS/dmcrypt verschlüsselt

Zusätzlich geplante Dienste:
- Lokaler Dropbox-Ersatz (Tendenz zu Seafile als Docker-Container)
- Heim-Automatisierung (Tendenz zu iobroker als VM)

Zusätzlich geplante Hardware:
- ggf. Upgrade auf 32GB oder 48GB RAM

Der Software-Stack ist von mir selbst aufgesetzt und wird Großteils von Hand bzw. eigenes erstellten Scripten verwaltet. Grundsätzlich funktioniert alles zufriedenstellend, jedoch kommt mir - wie gesagt - hin und wieder das Gefühl einer Frickellösung in den Sinn.

Für die, die es nicht kennen: Ich habe mich vor drei Jahren für die Nutzung von SnapRAID und mergerfs und gegen bekannte Lösungen wie FreeNAS, OMV etc. entschieden. Der Grund dafür war, dass ich noch nicht abschätzen konnte, wie sich das Projekt entwickelt, ob 6TB an Platz reichen und für wie lange. Nach gut 3 Jahren sind nun 60% vom Storage belegt.

Was ich mit SnapRAID und mergerfs erreichen konnte: Ich war komplett frei in der Erweiterung meines Storage-Pools. Hätte ich mal mehr Platz gebraucht, hätte ich eine HDD gegen eine größere austauschen können oder einfach eine zusätzlich mit dranhängen. SnapRAID hätte ich diese einfach zur Paritätsberechnung bekannt gemacht und mergerfs hätte mir die Platte einfach mit in den einheitlichen Mount-Point gemerged. Ich unterliege nicht den harten Strukturen wie RAID-Z bei ZFS oder ein klassischer RAID vorsieht. Zusätzlich besitze ich durch die Parität die Möglichkeit verlorene Dateien begrenzt zurückzuholen, sofern ein Sync auf die Paritätsplatte durchgeführt wurde (läuft jede Nacht). Auch charmant fand ich das Scrubbing, welches jeden Dienstag 8% aller Daten zwischen normalen Platten und Parität abgleicht und so etwas Sicherheit vor ungesehen Bit-Flips liefern soll.

Auf der Negativ-Seite habe ich keine erhöhten Geschwindigkeiten, da die Daten stets von einer Platte gelesen bzw. auf eine Platte geschrieben werden. Da die LAN-Anbindung mit Gigabit stattfindet und hier der NIC die Festplatte limitiert fällt dies nicht wirklich ins Gewicht. Ebenfalls kann ich natürlich nicht mit Snapshots aufwarten um Dateien über mehr als eine Iteration zu rekonstruieren.

Ich habe es für mich als gute Lösung bzgl. Sicherheit und Geschwindigkeit gesehen, welches natürlich in allen Disziplinen ZFS oder RAID unterliegt, dafür viel flexibler ist.

Im Moment überlege ich, ob ich die Storage-Lösung gegen FreeNAS tauschen möchte oder eine andere ZFS-Lösung. Ich möchte Arch Linux als Host nicht aufgeben, wegen ich diese Lösung in einer VM sehen würde und die Festplatten per Passthrough direkt an die VM übergeben würde. Hier müsste ich mich jedoch noch einmal ausführlich in die Vor- und Nachteile von ZFS einlesen, sofern von euch nicht jmd. gerade etwas sagen möchte. Aufgrund der Erfahrung mit der Entwicklung der Festplatten-Nutzung sehe ich ein Tausch der Platten in 1-2 Jahren. RAID wäre mir persönlich zu unsicher bzgl. Bit-Flips, auch wenn man nun argumentieren könnte "aber wie oft passiert so etwas schon". Vielleicht nie, vielleicht morgen ;)

Nun ja, nun habe ich das hier geschrieben und frage mich, wie ich das Thema abschließen will und was ich mir davon erwarte. Vielleicht wäre es schön, wenn ihr mal eure Meinung zum Setup nennen könntet.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe meinen homeserver lange unter Arch laufen lassen (ca. 2012-2018), musste aber immer wieder was frickeln weil ein rolling update Probleme gemacht hat. Daher käme gerade Arch für mich nicht in Frage als Host-OS (wohl aber als VM/Desktop). - Your mileage obviously varies.

RAID wäre mir persönlich zu unsicher bzgl. Bit-Flips,
*Gerade dagegen* schützt doch ein ZFS-RAID besonders gut?! Durchweg checksum-Prüfung, Selbstheilung, regelmäßige scrubs und snapshots möglich...?!
 
Ich habe meinen homeserver lange unter Arch laufen lassen (ca. 2012-2018), musste aber immer wieder was frickeln weil ein rolling update Probleme gemacht hat.

Ich nutze Arch inzwischen auf mehreren Maschinen über viele Jahre hinweg und nie groß Probleme gehabt. Ich favorisiere lieber aktuelle Software.

*Gerade dagegen* schützt doch ein ZFS-RAID besonders gut?!

Damit meinte ich klassische RAIDs wie RAID5 oder RAID6, so wie sie z.B. OMV anbietet.
 
Hi,
ich habe etwas ähnliches vor. Ebenfalls mit I3-6100 aber anderem Mainboard (P10S-E-4L). Super Prozessor für den Anwendungsfall.
Ich werde wieder Proxmox mit ZFS benutzen. Damit bin ich ganz zufrieden. Das läuft sehr stabil und Proxmox hat ein gutes Forum.
Die NAS Sachen laufen dann direkt auf dem Host und der Rest in Containern und VMs. Wird ein Mirror und evtl. SSD Cache. Host und Container/VMs liegen dann hauptsächlich auch auf einer SSD damit die HDD in den Spindown können.
Am Ende hat jeder seine eigenen Präferenzen und wenn deine Lösung funktioniert - warum nicht.

Achso: du brauchst DDR4 RAM ;)
 
Mit dem DDR4 vertue ich mich jedes mal. Irgendwie kommt es mir schon so alt vor, dass ich nie glauben kann, dass es DDR4 ist.

Was mich an Sachen wie Proxmox, ESXI etc. stört ist: Ich bin großteils an das GUI gebunden. Bei Proxmox weniger als bei ESXI, auch da gäbe es die Konsole, jedoch kommt das System mit Paketen und Stand XYZ dahinter und daran ist erst einmal nichts zu rütteln.

Kernel in Version X
Samba in Version X
usw.

Ich schätze an Arch Linux gerade das Rolling Release Prinzip und die durchaus aktuelle Software. Ich könnte - unabhängig davon ob ich will - im ernstfall praktisch alles unter der Haube regeln. Da es keine Haube gibt. Es gibt kein UI wie Proxmox. Ich habe mich vor einigen Jahren schon mit Proxmox auseinandergesetzt und hab dann oft fragen gelesen: "Wie mache ich dies?", "Kann ich das machen?" usw.

Und oft habe ich mir gedacht: "Klar, trage X in die XML der VM über virsh ein", "Klar, führe den Befehl usw." und am Ende fühlte sich so eine Maske bzw. so ein System irgendwie immer limitierend. Zumindest für meinen Anwendungsfall. Natürlich gibt es Dinge in diesen fertigen Lösungen, welche ich nicht abbilden kann. HA wäre so ein Problem.

Daher habe ich es erst einmal selbst gestrickt. Und ja, es funktioniert. Stabil, schnell, verlässlich. Dennoch muss das für mich nicht heißen, dass es gut oder das Beste ist. Wenn ich eine alternative finde, welche all dies bietet und zusätzlich - on top praktisch - mir eine Absicherung liefert, dass es einem gewissen Anspruch und Standard folgt, dann schaue ich es mir gerne an.

Aus dem Grund verwende ich auf pfsense für Firewall, DNS, VPN etc. Einfach weil ich da weiß, dass es erprobt ist und eine gewisse Brisanz hat. Und eigentlich hat der Bereich Storage dies für mich auch. Und dann denke ich darüber nach und der Frickelgedanke erzeugt ein etwas unangenehmes Gefühl.
 
Mir gefällt da gea's AiO Lösung. Am ESXi musst du da natürlich nicht festhalten, da geht es hauptsächlich darum, ein stabiles Grundgerüst zu haben. Da wüsste ich, außer der neuesten Hardware/Features der HW auch keinen Grund, das ständig auf dem allerneusten Stand halten zu müssen.
 
Wozu noch eine zusätzlich Dual Gigabit HP LAN-Karte (für pfsense)? Hast doch bei deinem Board schon Quad dabei?
 
Nenn mich Paranoid aber ich wollte die Firewall nicht über eine virtuelle Bridge schicken. War mir zu unsicher bzw. hatte nicht so ein gutes Gefühl bei.

Daher hatte ich mir eine gebrauchte Dual Gigabit Netzwerk-Karte aus dem Serverbereich geholt, wo die Garantie abgelaufen war. Die reiche ich per Passthrough an die VM.

Ob nun wirklich notwendig oder sinnvoll, darüber lässt sich streiten. War hauptsächlich fürs gute Gefühl.
 
Da du ja irgendwie Meinungen hoeren willst, schreibe ich auch noch mal meine zwei cents dazu:

Dass du kein WebGui gebundes Zeugs haben willst kann ich voll verstehen, ich mache selber meine Server mit Ubuntu. Allerdings kann ich absolut nicht verstehen wie rolling Release und Server zusammen passen sollen. Nur weil du bislang keine Probleme damit hattest, heisst es nicht dass es sie nicht gibt. Es hat schon einen Grund warum die Server im Internet, die mit Linux laufen alle auf LTS releases (centos/ rhel/ ubuntu) basieren. Du koenntest eine Stabiles relase nehmen, guckst dir tolle neue Features in Arch auffem Desktop oder in VM an und guckst im wirklichen Zweifelsfall, wie du sie auf den Server gebackportet bekommst.

Ansonsten wuerde ich noch empfehlen Docker Container auch in eine VM zu stopfen, es ist einfach soviel bequemer (Snapshots, Backups) und kann nicht das Host-OS (und vorallem Networking -.-) kaputt machen.

Ansonsten als Storage-Fs gibts momentan nix besseres (also sagen wir mal fuer den usecase, #Ceph :d) als ZFS wenn man mit der eingeschraenkten Flexibilitaet leben kann.
 
Moin moin,

in diesem Beitrag würde ich gerne meinen Heim-Server samt aktuellem und zukünftigem Einsatzzweck darlegen um mir von euch Vorschläge und Ideen zu holen, da ich hin und wieder nicht ganz zufrieden mit dem System bin bzw. das Gefühl habe, dass es sehr stark nach Bastellösung schmeckt - was nun aber grundsätzlich nicht schlecht sein muss.

Vielleicht von den selbst geschriebenen Scripts + händischer Einrichtung weg, hin zu cm Tools die dir die Einrichtung von neuen VMs/Containern abnehmen können?
Wenn du mit dem Einsatz von z.b Ansible deine VMs/Container jedes mal auf die selbe Weise einrichten kannst bekommst du schon mal ein gutes Grundgerüst., mehr "Stabilität" in der eigenen Infrastruktur..
Das wäre auch eine Änderung die dich erstmal nur Zeit kostet.. :P
 
Allerdings kann ich absolut nicht verstehen wie rolling Release und Server zusammen passen sollen. Nur weil du bislang keine Probleme damit hattest, heisst es nicht dass es sie nicht gibt. Es hat schon einen Grund warum die Server im Internet, die mit Linux laufen alle auf LTS releases (centos/ rhel/ ubuntu) basieren. Du koenntest eine Stabiles relase nehmen, guckst dir tolle neue Features in Arch auffem Desktop oder in VM an und guckst im wirklichen Zweifelsfall, wie du sie auf den Server gebackportet bekommst.

Grundsätzlich gebe ich dir recht. Würden wir hier von einer Unternehmung oder kritischen Geschäftsprozessen reden, dann wäre Stable und LTS das Mittel der Wahl. Aber folgende Gründe führe ich dagegen an:

1. Wir sprechen hier von einem Heim-Server und eben nicht von einer Unternehmung. Wenn die Maschine mal durch ein Update nicht laufen sollte, dann habe ich keine finanziellen Ausfälle oder einen Image-Schaden. Natürlich würde es mich ankotzen aber es wäre kein Weltuntergang.

2. Zum Zeitpunkt als ich den Server initial gebaut habe, war der die 6000er Serie und Intel neu. Kein Kernel konnte mit den neuen Steppings der CPU richtig umgehen und es kam zu Problemen, dass Energiesparmodis nicht genutzt werden konnten etc. Als Privatperson war mir Stromverbrauch jedoch immer ein Thema. Nun kam gerade der neue Linux-Kernel raus, welcher diese Steppings beherrschte und die CPU nicht permanent zu stark befeuerte. Fedora und Arch hatten diese, Ubuntu, Debian etc. würden noch Ewigkeiten brauchen. Und da ich über Jahre immer nur gute Erfahrungen mit Arch gemacht hatte, kams auf den Server.

3. Wieso soll oder muss ich mich mit Backports rumschlagen, wenn es auch ohne geht? Wieso soll ich mir, wenn ich ein Feature möchte, erst Gedanken machen, wie ich es irgendwie ins System geflickt bekomme?

4. Ich weiß, dass Rolling Release eigentlich Probleme bedeutet. Als ich vor gut vllt. 6-7 Jahren jedoch mein erstes Gerät auf Arch Linux umgestellt habe, hatte ich noch nie eine so reibungslose Erfahrung mit Linux. Ubuntu, Debian, Suse, Gentoo etc. haben dies davor nie geschafft. Und das hat mich begeistert. Und seitdem hatte ich - und inzwischen betreibe ich einen Desktop, ein Laptop und besagten Server mit Arch - noch nie (!) ein Problem mit Arch, welches nicht in 5 Minuten erledigt war. Und selbst diese Probleme habe ich einmal im halben Jahr. Ich weiß, dass Rolling Release immer böse klingt und ich würde das Risiko nie in einer Unternehmung eingehen, jedoch hatte ich mit Versionsupdates bei Debian oder Ubuntu bislang immer schlimmere Erfahrungen. Durch die dort teilweise riesigen Versionssprünge in der Software muss ich bei Konfigurationen teilweise Monate an Release-Logs durchgehen und schauen, wieso etwas nicht geht. Und aus meiner beruflichen Erfahrung in der Zusammenarbeit mit inzwischen fünf großen nationalen und internationalen Hosting-Anbieter von Kunden kann ich sagen: Diese Updates liefen bislang nie vollkommen problemlos. Es war immer etwas, was irgendwo nicht klappte. Und am Ende ging dann bei diesem einem Stichtag der Umstellung mit Testen, Analyse etc. mindestens genau so viel Zeit drauf, wie ich mit Arch über den Zeitraum insgesamt aufgebracht habe.

5. Ich nutze dieses System um zu lernen, Ideen auszuprobieren. Und gerade beim Aspekt lernen ist für mich die Aktualität der Software wichtig. Und da bin ich bei Arch Linux einfach besser aufgehoben.

Alles in allem sind dies natürlich oft nur persönliche Erfahrungen. Ich muss diesem "Oh rolling release ist so gefährlich, es könnte jederzeit was passieren" aber schon gewisse Einhalt gebieten. Auf meine Erfahrung bezogen kann ich hier nur widersprechen, ausschließen für die Zukunft kann ich es nicht und müsste ich 50 Server betreuen wäre mir der Aufwand und die Gefahr vermutlich auch zu hoch. Aber für mich hier mit einer Maschine? Ich bin mit Arch als Host sehr zufrieden und würde es auch empfehlen.

Erfahrungsgemäß kommen solche Bedenken oft von Leuten, welche Arch nie wirklich über längere Zeit gewissenhaft genutzt haben oder die Sache zu sehr aus Unternehmersicht sehen. Was nun nicht schlecht sein muss. Hier wird mir aber zu viel negatives reininterpretiert.

Ansonsten wuerde ich noch empfehlen Docker Container auch in eine VM zu stopfen, es ist einfach soviel bequemer (Snapshots, Backups) und kann nicht das Host-OS (und vorallem Networking -.-) kaputt machen.

Könnte ich mal überlegen. Das Problem bzw. der negative Beigeschmack welchen ich bei diesen Konstruktionen aber immer habe ist, dass dadurch ein gewisser Overhead entsteht. Letztendlich könnte ich aber mal austesten wie hoch dieser ist. Auch administrativ, weil ich dann zwei Linux-Distros pflegen müsste. Hier würde ich dann vermutlich ein Debian wählen aber selbst da müssen ja hier und da updates eingespielt werden.

Wenn du mit dem Einsatz von z.b Ansible deine VMs/Container jedes mal auf die selbe Weise einrichten kannst bekommst du schon mal ein gutes Grundgerüst

Kenne ich noch nicht, schaue ich mir mal an. Danke.
 
Zuletzt bearbeitet:
4. Ich weiß, dass Rolling Release eigentlich Probleme bedeutet. Als ich vor gut vllt. 6-7 Jahren jedoch mein erstes Gerät auf Arch Linux umgestellt habe, hatte ich noch nie eine so reibungslose Erfahrung mit Linux. Ubuntu, Debian, Suse, Gentoo etc. haben dies davor nie geschafft.

Erfahrungsgemäß kommen solche Bedenken oft von Leuten, welche Arch nie wirklich über längere Zeit gewissenhaft genutzt haben oder die Sache zu sehr aus Unternehmersicht sehen. Was nun nicht schlecht sein muss. Hier wird mir aber zu viel negatives reininterpretiert.
Dito. Oder du hast Gentoo nie wirklich benutzt.

+1 für maxpowers Vorschlag, mit Ansible/Chef/Puppet/Terraform/... erschlägst du Vieles mit einer Klappe. Ich sichere bei mir zuhause nur noch Daten (Bilder/Filme/Videos/Dokumente usw.) sowie den Git samt Ansible Playbooks. Die restlichen Maschinen samt Shellskripten/Files in /etc usw. können ruhig abnippeln, ein Playbook-Run und schon ist ein neues System fertig.
 
Okay, Gentoo hätte ich nie so aufnehmen dürfen. Letztendlich war vor 15 Jahren bei Gentoo das Problem bzw. die Umständlichkeit mit den ganzen Flags beim kompilieren.

Ich streiche es, weil nicht fair (da anderer Kontext) und vor allem zu lange her.
 
Die USE-Flags gibts immer noch, man muss schon wissen, was man tut. Aber im Grunde ist Gentoo wie Arch, nur das man sich eben alles selbst kompiliert.
Gibt auch noch andere, nette "RR" Alternativen, CoreOS z.B. :)
 
Genau und dieses "Wissen was man tut" hat die Sache dann sehr anstrengend gemacht.

CoreOS hatte ich 2014 mal angesehen als es noch ganz frisch war. Hatte es danach aus den Augen verloren und gar nicht verfolgt, ob es auf dem Markt überhaupt überlebt. Offenbar hat es das. Werde mir mal ansehen was es so kann.
 
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