Dies & Das

Hinweis Dieser Artikel ist nicht vollständig und wir vermutlich über die Zeit wachsen.

Ziel

Das Homelab soll einerseits meinen Spieltrieb befriedigen und andererseits auch einen produktiven Nutzen haben, indem es die Bestrebungen nach digitaler Souveränität unterstützt. Daher versuche ich, so viel wie möglich selbst zu betreiben.

Was läuft im Homelab?

Homeassistant

Der Kern war Homeassistant. Ursprünglich lief es auf einem Rapsberry Pi, dann einem Homeassistant Blue und jetzt eben auf Proxmox. Die ganze Idee, Proxmox aufzusetzen stammt aus dem Wunsch, Homeassistant irgendwie ausfallsicherer zu machen.

Immich

Der nächste offensichtliche Schritt war das eigenen Hosting von Bildern und Videos. Immich ist perfekt dafür geeignet.

Matrix

Irgendwie habe ich das Gefühl, dass Matrix selbst gehostet werden muss. Also mache ich das.

Paperless

Irgendwann wurde mir der Papierkrieg zuviel und ich habe eine Paperless-Instanz aufgesetzt. Die tut und hilft doch sehr.

Seafile und OpenCloud

Das ist ein bisschen die Achillesferse im ganzen Setup. Ursprünglich habe ich mal Owncloud, später Nextcloud benutzt – aber beide halte ich für Bloatware, die massiv unter Featuritis leiden – zu Lasten der Stabilität. Ich habe dann erst mit Syncthing und schlussendlich mit Seafile eine Lösung gefunden, die stabil läuft. Aber das ist Software aus China und damit auch nicht ideal. Nach großem Aufräumen (Von knapp 3 TB runter auf 300 GB) und entsprechend weniger Daten probiere ich es jetzt nochmal mit OpenCloud, in der Hoffnung, dass es damit stabiler funktioniert.

Vaultwarden

Das ist mein Passwortsafe, den ich jetzt selbst hoste. Funktioniert genauso problemlos wie Bitwarden vorher – nur dass ich jetzt die volle Kontrolle habe.

Was läuft nicht im Homelab?

Email

Alles hängt irgendwie an meinem Emailaccount. Deswegen will ich den nicht selbst betreiben und habe das ausgelagert an inbox.eu.

DNS

Aus dem gleichen Grunde wie Email läuft das ausgelagert.

Wie sieht das Setup aus?

Ich nutze Proxmox. Das ist eine freie Lösung, die für ein Homelab (aber auch sehr viel größere Installationen) ideal ist: Komplett frei und stabil. Ursprünglich bin ich mit 3 Nodes mit MiniPCs mit Intel N95-Prozessor und 32 bzw. 16 GB RAM gestartet. Inzwischen ist noch ein weiterer Node (ebenfalls MiniPC) mit Ryzen 7 dazu gekommen und mein alter PC (48 GB RAM und Intel Core i7) komplettieren das Setup auf nun insgesamt 5 Nodes. Die Workloads (zusätzlich zu den oben beschrieben Diensten läuft noch ein Haufen Kleinkram drum herum) können theoretisch beliebig zwischen den Nodes migrieren. Das meiste läuft auf LXC und einige wenige Dienste auf VMs.

Storage

Es gibt 2 Storage-Systeme, die auf (fast) allen Nodes verfügbar sind: external – das ursprünglich eingerichtete System mit ca. 4 TB Speicher auf jedem Node filestore – das zusätzlich eingeführte Storage-System für noch größere Datenmengen mit 10 TB an (fast) jedem Node Die Festplatten dazu sind via USB angebunden (jeweils 3,5” HDD von Seagate und Western Digital in externen enclosures). Bis auf 2 alte Platten, die demnächst auszutauschen sind, läuft alles auf Enterprise Platten o.ä. Qualitäten. Ursprünglich wollte ich alle Systeme durchgängi mit einem RAID 1 ausstatten, bin aber mittlerweile davon abgekommen, weil ich mir denken, dass ich dir mindestens 3-fache Replikation auf anderen Nodes bereits mehr Redundanz als nötig habe und nicht noch weiter in Platten investieren muss. Fällt eine Platte doch mal aus, ist der Storage auf dem einen Node halt nicht verfügbar und die Systeme können auf einem anderen Node weiterlaufen, bis ich die Platte ersetzt habe. Grundsätzlich sind die Systeme so augestattet, dass ich den Verlust von 2 Nodes vertragen kann, ohne dass ich signifikante Einschränkungen in Kauf nehmen muss.

Filesystem

Das Filesystem ist durchgängig zfs. Das ist zwingend notwendig, damit die oben beschriebene Replikation und Migration zwischen den Nodes reibungslos funktioniert. Grundsätzlich wird im 15-Minuten-Takt repliziert. D.h., ich verliere im schlimmsten Falle die Daten der letzten Viertel- bis halben Stunde. Das ist für mich akzeptabel.

Backup

Vor Proxmox gab es natürlich auch schon ein Backup und das lief mit restic. Genauer: backrest Das hat auch eine Weile noch den Job getan, als ich schon Proxmox am laufen hatte, war aber nicht sonderlich komfortabel.

Daher bin ich vor einigen Monaten auf den Proxmox Backup Server (PBS) umgestiegen.

Der läuft selbst als VM auf einem Proxmox-Node, hat aber als Datastore eine dedizierte Platte, die von Proxmox direkt an die VM durchgereicht wird. Auf die Weise kann der PBS zwar nicht beliebig migrieren – aber im Notfall (falls der Node, auf dem PBS läuft ausfallen sollte) kann ich einfach die Platte umstecken, an die mirgrierte VM durchreichen und bin nach wenigen Minuten wieder zurück.

Auch der Datastore läuft nur auf einer einzelnen Disk – was natürlich nicht sicher genug ist, da die Daten nicht repliziert werden. Daher gab es bisher noch ein offsite-Backup mittels Jottacloud. Das lief ok – aber ist eben ein proprietärer Dienst jenseits meiner Kontrolle und außerdem nicht nativ nutzbar.

Daher habe ich vor kurzem einen weiteren Datastore an PBS angebunden: S3 via Datalix (Affiliate-Link: https://datalix.de/a/blog ) Dort habe ich derzeit 5 TB Storage gebucht, von denen inzwischen gut 2,5 TB belegt sind. Bis auf Seafile (das wird gerade auf OpenCloud migriert) sind dort bereits alle Dienste mindestens 2x gesichert worden. Der größte Brocken war dabei Immich, was mit ca. 2 TB den Löwenanteil beansprucht. Da ich alles über HDD mache (auch die Cache-Disk für den S3 mit 128 GB läuft als Volume auf dem external-Laufwerk) bin ich lokal IO-bound und das das erste Backup hat weit über 24 Stunden gedauert. Da aber alle weiteren Durchläufe inkrementell sind, dauern die einzelnen Backups nun nur noch einige Minuten, was völlig ok ist.

Derzeit ist das Setup so eingerichtet, dass ich das lokale Backup als einen großen Job um 0:01 Uhr starte und dieses dann sequentiell auf allen Nodes gleichzeitig eine Workload nach der anderen sichert. Um 1:00 Uhr, 2:00, etc. starte ich dann zeitversetzt für jeden Node einzeln das Backup auf den externen S3 Storage.

Mit einer SSD könnte ich den Vorgang natürlich erheblich beschleunigen – sehe aber keinen allzu großen Nutzen darin, da ich mit der Laufzeit der inkrementellen Backups absolut zufrieden bin.

Netzwerkanbindung

Mein Homelab ist vie FritzBox an eine Glasfaserleitung der Telekom angebunden, die mir 600/300 Mbit bietet. Das reicht im Normalfall locker aus.

Lokal sind die Nodes über 1 Gbit miteinander verbunden.

Todos

lokales S3

Ceph

Ich habe in der Vergangenheit schon 2x mit Ceph experimentiert – kann aber für ein Homelab mit einem Setup meiner Dimension davon nur abraten. 1 Gbit und HDD reichen einfach nicht aus.

Garage

Ich möchte demnächst mal Garage testen, da das mit weit weniger Ressourcen auskommen soll. Ob es funktioniert, kann ich natürlich erst danach sagen. Falls ja, eröffnet das neue Möglichkeiten. Mehr dazu, wenn es dazu kommen sollte ...

Staged Backup

Das offsite Backup ist verschlüsselt, das lokale (noch nicht). Daher kann ich derzeit noch keine simple Replikation des Backups durchführen, sondern muss das offsite Backup als vollständig eigenen Dienst laufen lassen. Das erzeugt natürlich zusätzliche Last (IO) auf dem System.

Sobald der offsite S3-Datastore hinreichend viele Versionen gesichert hat, werde ich das Backup so umstellen, dass das lokale Backup ebenfalls verschlüsselt ist (hätte ich eigentlich von Anfang an so machen können/sollen) und dann der offsite S3-Datastore nur aus diesem bedient wird.

Das wars für den ersten Wurf. Bei Fragen bitte einfach via Fediverse an https://gruene.social/@thoralf wenden.

Edit: Beschreibung des Backups erweitert und zugehöriges todo hinzugefügt.