Was ist ein Homelab

Homelab ist erstmal ein dehnbarer Begriff und beschreibt im Grunde einfach nur einen oder mehrere Server für die private Nutzung zu betreiben. Die Größer ist dabei sehr variable. In dem einen Lab steht nur ein alter Rechner der ein paar Dienste anbietet, in dem nächsten zwei oder gebrauchte Server und in manch einem Homelab gibt es komplette Netzwerke mit Switchen, Routern, Firewalls und mehreren virtualisierten Servern.

Wofür brauche ich ein Homelab

Die Intentionen hinter einem Homelab sind verschieden. Manchmal entsteht der Gedanke aus der Not, oder zumindest dem Bedarf nach einem bestimmten Dienst. Paradebeispiele dafür sind Cloud- und Media-Server mit denen sich Daten, Fotos und Videos von überall im Netzwerk erreichen lassen.

In anderen Fällen ist es einfach die Neugier. Man baut sich also eine Spielwiese um mit Betriebssystemen oder Softwarelösungen herum zu probieren. Das reicht dann von den ersten Versuchen ein Linux zu installieren, bis zu kompletten Kubernetes Clustern.

Nicht zu vergessen ist auch der Wunsch einen eigenen Gameserver zu hosten. Und da viele ITler auch Interesse am Gaming haben, ist bestimmt auch das ein oder andere Homelab mit dem ersten eigenen Minecraft Server entstanden.

Das Problem bei der Sache

Das große Problem an einem Homelab sind die Kosten. Auch wenn gebrauchte Hardware teilweise recht erschwinglich ist, darf man nicht unterschätzen wie viel Geld man für die Stromrechnung bereithalten muss. Denn viel Leistung braucht meist auch viel Strom. Insbesondere bei älteren und dadurch in der Anschaffung günstigeren Systemen.

Der ein oder andere mag sich jetzt denken „ich brauch mein lab eh nur wenn ich daran bastle, dann ist der Stromverbrauch nicht höher als bei einem normalen Rechner“. Das ist an sich auch richtig, aber sobald man die ersten Dienste installiert hat, kommt einem doch immer wieder in den Sinn, wie schön es wäre den Dienst auch wirklich nutzen zu können. Und das bedeutet er muss immer erreichbar sein.

Ein weiterer Punkt ist die Lautstärke. Da Server normalerweise in einem Rechenzentrum mit dicken Türen betrieben werden, wird auf die Lautstärke der Lüfter keinen Wert gelegt. Sie sollen lediglich effizient sein. Sobald man den Server aber das erste Mal im Wohnzimmer hochfährt, wir recht schnell deutlich, dass so kein Dauerbetrieb erträglich ist. Denn Server sind laut. Wirklich laut.

Meine Lösung: Der Raspberry Pi

Aber zum Glück gibt es eine Lösung für ein kleines günstiges Homelab, dass weder viel Lärm verursacht, noch viel Strom verbraucht. Der Raspberry Pi!

Für alle die ihn nicht kennen. Der Raspberry Pi ist ein kleiner Einplatienencomputer mit ARM Prozessor und 4 Kernen. Er besitzt HDMI, USB und LAN Anschlüsse und hat einen Stromverbrauch von ca. 5 Watt maximal. Die genauen Spezifikationen variieren je nach Modell.

Entwicklung meines Homelabs

Angefangen habe ich mit dem Raspberry Pi 3b mit dem Raspberry OS Betriebssystem. Für die ersten Gehversuche ist er super geeignet, aber sobald man Dienste mit etwas mehr CPU Last nutzen möchte wird der Pi 3b recht schnell zu klein. Außerdem ist der Arbeitsspeicher relativ klein bemessen, weshalb man sich überlegen sollte, ob man wirklich eine Desktop Umgebung benötigt oder nicht doch mit der Kommandozeile auskommt. Dafür ist der Pi 3b sehr günstig.

Abgelöst wurde der Pi 3b von dem Pi 4 mit 4GB Ram. Dieser ist zwar etwas teurer, ist aber deutlich schneller und außerdem bieten die 4GB Ram deutlich mehr Spielraum für Desktop Umgebungen. Ein weiterer Punkt ist, dass der Pi 4 einen USB 3.0 Anschluss hat. Das war in meinem Fall wichtig, weil ich eine Festplatte über USB anschließen und als Netzwerkspeicher zur Verfügung stellen wollte.

Aktuell betreibe ich einen Pi 4 mit 8GB Ram. Dieser unterscheidet sich aber nicht von dem zuvor beschriebenen Pi 4 mit 4GB bis auf die zusätzlichen 4 GB Ram.

Mein Setup

Herzstück meines aktuellen Setups ist wie gesagt, der Raspberry Pi 4 mit 8GB Ram. Als Betriebssystem nutze ich Ubuntu 20.10. Ich würde allerdings empfehlen 20.04 zu nutzen, oder die entsprechend aktuelle LTS Version, allerdings hatte ich zur Zeit der Installation mit Ubuntu 20.04 Probleme. Ich gehe aber davon aus, dass Canonical das mittlerweile gepatch hat.

Das Betriebssystem läuft bei mir nicht auf der SD Karte sondern auf einer 250 GB SSD, die ich über ein USB Dock an den Pi angeschlossen habe. Dadurch ist das Betriebssystem nicht nur deutlich schneller, sondern auch ein stückweit ausfallsicherer, da SSDs in meiner Erfahrung robuster als SD Karten sind.

Über das gleiche USB Dock habe ich außerdem eine 1TB HDD angeschlossen, die als Datenspeicher für meine Nextcloud und meinen Samba Server dient.

Um nicht bei jedem Software Update oder Installation eines Dienstes um das gesamte System bangen zu müssen, betreibe ich (fast) alle Dienste in Containern. Dazu nutz ich LXD (Beginners Guide). Dadurch kann ich für jeden Dienst und jede Software einen neuen Container erstellen. In diesem kann ich dann so viel probieren wie ich will. Und sollte ich irgendetwas kaputt machen, lösche ich den Container und erstelle einen neuen. Außerdem kann ich so ganze Container sichern oder migrieren. Der einzige Nachteil bei LXD ist, dass man ausschließlich über die Kommandozeile arbeiten muss. Andersherum lernt man dadurch aber auch Lösung für Probleme zu finden, die man sonst über eine GUI lösen würde.

Docker

Um den Raspberry bei der menge an Diensten ein wenig zu entlasten, habe ich begonnen die kleineren Webserver in Docker-Images zu konvertieren und als Docker Container zu betreiben. Dadurch kann ich die entsprechenden LXD Container abschalten und die Ressourcen wieder freigeben. Docker haben den Vorteil, dass sie im Vergleich zu LXD deutlich weniger vom Betriebssystem virtualisieren und dadurch viele Hintergrunddienste weg fallen. Eine Anleitung zur Docker Installation in einem LXD Container gibt es hier.

Netzwerk Aufbau

Netzwerktechnisch habe ich nicht viel vorzuweisen. Als Router dient eine FritzBox und der Raspberry Pi ist mit LAN verbunden. Die einzige Besonderheit ist, dass ich ein Klasse A Netz nutze und nicht wie in der Standardkonfiguration der FritzBox ein Klasse C Netz. Dadurch kann ich verschiedene Geräteklassen auf verschiedene „Subnetze“ verteilen. So sind meine Container in einem anderen IP Bereich als die Geräte, die eine DHCP Adresse erhalten haben. Allerdings handelt es sich streng genommen nicht um Subnetze, da der gesamte Bereich im gleichen Netz liegt und ohne separaten Router untereinander kommuniziert. Trotzdem ist es ganz schön nicht schauen zu müssen, ob die Adresse bereits über DHCP vergeben ist.

Dazu sei gesagt, dass Container standardmäßig die IP Adresse des Hosts nutzen und dort eine Port zugewiesen bekommen. Da ich meine Container Netzwerktechnisch aber gerne wie Virtuelle Maschinen mit eigener IP Adresse behandeln möchte, habe ich ein MacVLan Profil erstellt, wodurch jeder Container eine eigene IP Adresse bekommt. Die genauere Erklärung dazu gibt es in meinem Beitrag zu LXD.

Streng genommen bekommen die Container auch weiterhin eine DHCP Adresse. Allerdings weise ich in der FritzBox eine Adresse zu, die Außerhalb des normalen DHCP Bereichs liegt. Das hat zum einen den Vorteil, dass ich nicht über Terminal eine statische IP Adresse vergeben muss, sondern diese vom Router kommt. Außerdem muss ich bei einem neuen Container nicht darüber nachdenken, welche IP Adresse ich ihm vergebe. Es kommt sofort eine DHCP Adresse. Das ist besonders praktisch, wenn man keinen permanenten Dienst einrichten möchte, sondern nur kurz etwas ausprobiert. Möchte man dann doch eine feste IP, muss man nur in der FritzBox die Adresse ändern und den Container neustarten.

Der einzige Nachteil dabei ist, dass der DHCP Server der FritzBox verhältnismäßig langsam ist. So kann es wenn man mehrere Container neu startet schon mal ein paar Sekunden dauern, bis alle ihre IP Adresse erhalten haben, aber das stellt für mich kein Problem dar.

Backup

Wie immer in der IT ist es wichtig seine Daten zu sichern. Das geht nur mit einem guten Backup-Konzept. In meinem Fall habe ich dafür eine externe USB Festplatte angeschlossen, die ich allerdings nur einschalte, wenn ich sie brauche. Andernfalls besteht das Risiko, dass bei einem Systemausfall die Festplatte ebenfalls beschädigt wird und das Backup verloren geht.

Das Backup ist bei mir zu großen Teilen durch automatisiert. Dadurch ist es wenig aufwand für mich und schnell gemacht. Es ist aber auch nicht voll automatisiert, weil ich bei den manuellen Schritten bemerken würde, wenn etwas nicht funktioniert hat. Denn nichts ist schlimmer als erst im Ernstfall zu bemerken, dass das vermeintliche Backup nie funktioniert hat.

Der Ablauf ist bei mir wie folgt. Ich habe einen Cronjob erstellt, der immer Samstags nachts Images von allen wichtigen Containern erstellt. Mit diesem Image könnte ich im Ernstfall den Container im identischen Zustand auf einem anderen Server wiederherstellen. Eine Migration ist so auch relativ simple möglich. Danach schließe ich manuell die Backup-Festplatte an, mounte diese und starte ein weiteres Skript. Dieses kopiert mit Rsync alle Container Images auf die Backup-Festplatte.

Ausnahmen stellen bei diesem Konzept die Nextcloud und der Samba Server dar. Der Grund ist, dass bei diesen Container alle Daten in das Image gepackt werden würden und ich jede Woche ein Image mit über 500 GB kopieren müsste. Daher erstelle ich von diesen Containern kein Image, sondern kopiere nur die Daten. Von der Nextcloud lasse ich mir außerdem die Konfiguration und die gesamte Datenbank exportieren und sichere diese. Dadurch müsste ich im Ernstfall nur einen neuen Container erstellen, die Nextcloud per Snap-Packet installieren und die Datenbank und Konfiguration wieder importieren. Danach kann ich die Daten in das entsprechende Verzeichnis kopieren. Das gleiche gilt für den Samba Server.

Auf diesem Weg habe ich alle wichtigen Daten, mit wenig Aufwand, auf einer zweiten Festplatte gesichert.

Kühlung und Stromverbrauch

Durch den verhältnismäßig kleinen Prozessor ist sowohl die Abwärme als auch der Stromverbrauch gering. Daher ist es ausreichend einen kleine Lüfter zu montieren. Alternative dazu gibt es auch Gehäuse die bereits einen 40mm Lüfter verbaut haben.

Ich selber habe ein kleines „Mini-Rack“ mit dem 3D Drucker erstellt und dort einen 120mm Gehäuselüfter verbaut. Dieser wird mit einem Spannungswandler über den 5 Volt Pin des Raspberry Pi betrieben. Bei Bedarf kann ich die STL Datei gern veröffentlichen und hochladen.

Dadurch ist der Pi nie wirklich wärmer als 40 Grad Celsius und die Stromaufnahme minimal. Und das beste daran, wenn die Festplatte im Standby ist, ist das System kaum hörbar.

Berechtigungsverwaltung

Bei so vielen Containern und Diensten, kann es lästig sein, immer neue Nutzer und Passwörter anzulegen. Daher habe ich mir eine OpenLDAP für die Anmeldung in den Containern eingerichtete. Den Artikel dazu gibt es hier.

Meine Dienste

Das ist eine Liste aller Dienste, die momentan auf meinem Server laufen. Sollte es Fragen zu dem ein oder anderen Dienst geben, bin ich für Fragen per E-Mail immer offen.

• Confgen Website (Konfigurations-Generator)
• blog.jrehkemper.de (Ghost Blog)
• Docker (Primär für Websites genutzt)
• jrehkemper.de (NGINX Webserver)
• MySQL (Datenbank)
• Nextcloud (Cloudserver)
• OpenLDAP (Berechtigungsverwaltung)
• OpenVPN
• Reverse Proxy
• Samba (Storage Server)
• PiHole (Adblocker für das Netzwerk)
• Uptime Kuma (Monitoring System)

Abschluss

Ein Homelab muss also gar nicht teuer und laut sein. Mit einem Raspberry Pi 4 lässt sich eine Menge ausprobieren und viele Dienste auch "produktiv" betreiben. Daher ist und bleibt er meine Wahl für ein Homelab.