Project Rebel Homebase: Teil 1

Warum ich mir mein eigenes Mini-ARM-Rechenzentrum baue

Ich sag’s direkt am Anfang: Ich bin kein Linux- oder Infrastruktur-Spezialist. Ich komme nicht aus der Sysadmin-Ecke und ich habe nicht jahrelang Rechenzentren gebaut. Aber ich habe Freude daran, Systeme zu verstehen und selbst zu bauen. Und genau diese Freude ist der Motor für dieses Projekt.
Am Anfang stand eine Idee, die viele als übertrieben, nerdig oder „unnötig komplex“ bezeichnen würden. Aber die Wahrheit ist: Ich mache das nicht, weil es pragmatisch ist. Das ist es so gar nicht. Sondern weil es mich begeistert. Weil ich es kann. Und weil es am Ende ein Lernprojekt in digitaler Souveränität ist.

Willkommen in der Rebel Homebase.

Der „Stormtrooper“ auf meinem Schreibtisch

Vor mir stehen aktuell sechs kleine Maschinen, sauber verpackt in ein selbst gedrucktes 10-Zoll-Rack im strikten Schwarz-Weiß-Design. Wer genau hinsieht, erkennt, dass hier keine „Bastel-Lösung“ steht, sondern eine strukturierte Micro-Infrastruktur:

• Die Worker: vier Raspberry Pi 5 Compute-Module (CM5) mit 16 GB RAM und 16 GB Flash und zwei Raspberry Pi 4 Compute-Module (CM4) mit 4 GB RAM und 8 GB Flash
• Die Basis: montiert auf den genialen Compute Blades von Uptime Industries alle mit eigener 256 GB NVMe direkt am PCIe-Bus
• Der Storage: Ganz oben im Rack thront ein ZimaBlade (x86), fast unsichtbar hinter einer Custom-Frontblende mit zwei 2,5-Zoll-Einschüben. Er läuft als dedizierter Server unter Ubuntu (pandolin-mcp-storage) und liefert die Daten von einer 2 TB Crucial BX500 SSD via NFS an den Cluster.
• Das Netzwerk: Hier gibt es keinen Kabelsalat. Alles ist sauber über ein Keystone-Patchpanel auf einen Ubiquiti PoE-Switch im Boden des Racks gepatcht.
• Das Backup: Flankiert wird das Ganze von einem externen Proxmox-Server (pandolinium), der die letzte Verteidigungslinie bildet.

Das ist kein „Spielzeug“. Und ja, es ist nicht perfekt. Aber es ist echte Infrastruktur im Kleinen. Ein funktionaler, hochgradig modularer, souveräner (sowas von souverän) Compute-Cluster. Und ich lerne dabei mehr, als man durch reines Konsumieren von irgendwelchen abstrakten Services je lernen würde.

Warum nicht einfach virtuell?

Hier kommt der Standardspruch vieler resignierter IT-Profis:

„Mach das doch einfach in einer VM. Oder in mehreren. Ist doch viel effizienter!“ oder „Die ganze Hardware ist doch komplett overengineered.“

Aber hier ist meine Gegenposition: Virtuelle Umgebungen simulieren verteilte Systeme. Meine Umgebung ist ein verteiltes System.

Jeder Pi hat seinen eigenen Stromverbrauch, sein eigenes thermisches Verhalten, sein eigenes Boot-Verhalten, seine eigene MAC-Adresse, seine eigene Latenz im Netzwerk.

Und ich lerne Dinge, die in VMs nicht vorkommen:

• was passiert, wenn ein Node physikalisch ausfällt
• warum mein Node plötzlich so langsam wird (Thermik? Software?)
• wie das Cluster reagiert, wenn ein Device hart rebootet
• wie Netzwerk-Topologie die Performance beeinflusst
• wie Storage-Traffic über echte NFS-Wege vom ZimaBlade zu den Pi's fließt
• wie SSH-Traffic zwischen realen Geräten funktioniert
• wie sich Skalierung richtig fühlbar anfühlt, statt nur theoretische Simulation zu sein
• wenn Load-Spitzen anstehen, höre ich Lüfter und sehe nicht nur Warnungen auf einem Dashboard

In VMs kann ich Kubernetes benutzen, ja. Hier in meinem physischen Cluster kann ich Kubernetes voll verstehen. Und ich habe mir bewusst ein Problem ins Haus geholt, vor dem viele zurückschrecken: Ein Multi-Architektur-Cluster. Meine Worker-Nodes sind ARM-basiert (Pi's), mein Storage Server (ZimaBlade) wie auch mein Backup Server (MinisForum NAS Pro) ist x86. Das bedeutet: Ich muss im Zweifelsfall Container-Images für verschiedene CPU-Architekturen managen. In der Cloud klickt man das weg. Hier muss ich es lösen. Genau das ist der Punkt. Das Ganze ist ein praktisches Lehrstück in verteilter Realität, nicht in Virtualisierung oder abstrahierten Layern auf Admin-Konsolen.

Warum macht man sowas?

Ich sage es offen:

Weil ich mir damit meine eigene, unabhängige, durchaus Infrastruktur aufbaue.
Weil ich es liebe, Systeme zu verstehen nicht nur zu benutzen und weil ich im Gegensatz zu vielen hochdotierten "Architekten" nicht nur Admin-Konsolen-Basteleien möchte.
Weil ich Dingen vertraue, die ich selbst besitze und kontrolliere.

Weil ich mir Unabhängigkeit von Hyperscalern schaffe, im Know How, im Kleinen.
Es geht mir um digitale Souveränität als handbares Konzept. Politiker sprechen oft über Souveränität als etwas, das durch Milliarden-Investitionen und staatliche Lenkung entsteht. Das stimmt auch. Aber es ist nur die halbe Wahrheit. Echte Souveränität ist auch ein „Bottom-up“-Ansatz.

Weil ich in solchen Diensten (ja, bei guten lokalen Partnern wie Hetzner, Ionos, United Cloud, mediaBeam, Sohnix, und so vielen mehr) eine bessere Zukunft für uns alle sehe als bei chinesischen und amerikanischen BigTech-Unternehmen.

Und fast noch wichtiger, Hand aufs Herz:
Weil es Freude macht und unheimlich viel Befriedigung verschafft, wenn man versteht.

Lego Duplo vs. Fischertechnik

Ich sage es mal etwas ketzerisch: Hyperscaler-Clouds (AWS, Azure & Co.) sind wie Lego Duplo. Bunt, sicher, man kommt schnell zu einem Ergebnis – aber die Formen sind vorgegeben. Man baut das, was der Hersteller vorgesehen hat.

Echte, eigene IT ist wie Fischertechnik oder die alten Metallbaukästen. Es ist komplexer, man braucht Werkzeug, man kann sich die Finger klemmen. Aber am Ende baut man exakt das, was man braucht – und nicht das, was der Baukasten erlaubt.

Das selbstgedruckte Gehäuse

Der Cluster steckt in einem 10-Zoll-Rack, das ich selbst gedruckt habe (leider nicht selbst entworfen) . Es folgt einer klaren Struktur: Oben der Storage-Kopf mit den Drive-Bays, in der Mitte die Rechen-Power, unten die Netzwerk-Verteilung via Patchpanel.

Die Wabenstruktur (Honeycomb) sorgt nicht nur für Airflow, sondern gibt dem Ganzen einen industriellen Look. Und ja: Oben drauf wacht ein kleiner LEGO-Pinguin vom Linux Professional Institute (LPI) und nickt das Setup ab. 😉

Kein Designer-Schnickschnack.
Kein Hochglanz-Industriecase.
Nur maßgeschneiderte Realität.
Es ist leicht, funktional, und erfüllt genau das, was ich brauche. Nicht mehr, nicht weniger.

Man lernt dabei mehr über:

• Modulare Bauweise/ Zugänglichkeit, daraus folgt
• Reparierbarkeit
• Kabelmanagement
• Vibrationsverhalten
• Luftführung / Wärmestau / Kühlung
• und die Lautstärke (und die ist im Arbeitszimmer immer das härteste Kriterium).

als jemals im virtuellen Raum.

Und vielleicht, ganz vielleicht, wird daraus einmal etwas Größeres

Heute ist es ein Homelab. Ein Spielplatz. Ein Lernsystem. Ein Experiment.

Aber:

• Die Architektur ist modular und offen.
• Der Ansatz ist nahezu unbegrenzt skalierbar.
• Die Rollen der Nodes sind scharf trennbar.
• Storage- und Backup-Pfade sind professionell gelöst.
• Der Cluster ist jederzeit reproduzierbar und erweiterbar.
• Es ist ein potentielles komplettes Ökosystem, kein impulsives Bastelprojekt.

Ein erster Ausblick

Das hier ist erst der Anfang. Die Hardware steht, die LEDs blinken grün. Aber der Weg dorthin war voll von geschmolzenem Plastik, Lötkolben-Einsätzen für Gewinde und schwierigen Hardware-Entscheidungen.

In den kommenden Kapiteln möchte ich folgendes (nicht notwendigerweise in dieser Reihenfolge) dokumentieren:

• wie der Storage-Node aufgebaut wurde und wie die ZFS-Backups funktionieren (sollen)
• wie Backups vom Storage-Node auf pandolinium repliziert werden
• wie Hostnames, Keys und Authentifizierung zum Leben erwachen (und da sind so viel böhmische Dörfer für mich drin...)
• wie K3s auf die sechs physischen Nodes kommt
• wie sich erste Services und Applikationen im Cluster bewegen
• wie sich Ausfälle verhalten
• wie ich Monitoring aufbaue, Temperaturen, CPU-Lasten, Storage-Anzeigen, Netzwerkspitzen
• wie das Ganze sich „nach Cloud“ anfühlt. Nur so ganz ohne BigTech-Cloud.

Das hier ist ein Experiment im besten Sinne: ein Weg zur souveränen, selbst kontrollierten IT. Im Kleinen. Bevor man sie im Großen denkt. Und vielleicht umsetzt :-)

Und genau deshalb ist echte Hardware so wertvoll. Sie zwingt einen zum echten Verständnis. Zum tatsächlichen Begreifen. Zum handfesten Ansatz statt zur Simulation.

Der Cluster ist der Anfang. Die Reise ist noch lang. Das sehe ich von Kommandozeile zu Kommandozeile. Und die Erkenntnisse werden viele sein, sind es jetzt schon.
Lasst sie uns doch gemeinsam gehen.

Nicht als „perfekt orchestrierte Anleitung“, sondern als reales Erfahrungsprotokoll. Mit Fehlern.
Mit Erkenntnissen. Und - mit Freude am Tun - nicht an "Cloud-Consumption".