Hardware-Leitfaden für Home-Lab-Einsteiger

 (linuxblog.io)
2 Punkte von GN⁺ 2024-03-09 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Home Lab ist eine Sandbox-Umgebung, in der sich Netzwerk- und Serverkonfigurationen zu Hause sicher ausprobieren lassen – von Remote-Backups und Monitoring bis zu Gerätetests, ohne den Druck einer Produktionsumgebung
  • Vor der Installation sollte man zuerst die physischen Bedingungen wie Temperatur, Belüftung, Stromversorgung, Lärm, Staub und Kabelwege prüfen und eine Netzwerkdiagramm passend zur eigenen Wohnsituation zeichnen
  • Die Wahl zwischen Rack und Cabinet hängt von Gerätetiefe und Abwärme ab; wer flache Netzwerkgeräte und tiefe Server nach denselben Kriterien auswählt, riskiert Probleme bei Kühlung und Zugänglichkeit
  • ISP-Modem, Router·Switch, UPS, Patchpanel, Kabel und Server müssen nicht alle auf einmal gekauft werden; realistischer ist es, klein anzufangen und Strombedarf sowie Erweiterbarkeit schrittweise anzupassen
  • Eine Konfiguration, die 2020 mit einem 12U-Rack begann, wurde in sechs Jahren bis auf 10G-Uplink und 2.5G-LAN ausgebaut – entscheidend sind jedoch weniger teure Geräte als eine betrieblich sinnvolle Anordnung und Stromverwaltung

Zweck und Betriebsumfang eines Home Labs

  • Ein Home Lab ist eine Testumgebung für sicheres Experimentieren zu Hause und reduziert das Risiko, neue Konfigurationen direkt auf Produktionsgeräte anzuwenden
  • Beispiele für den Betrieb sind:
    • Remote-Backups
    • Netzwerk-Monitoring und Benachrichtigungen für entfernte Server
    • verkabelte UAP APs
    • Experimente mit verschiedenen Geräten und Services
  • Diese Konfiguration wurde erstmals 2020 veröffentlicht und seitdem fortlaufend aktualisiert; sie enthält den Stand vom März 2026 sowie eine Zeitleiste über sechs Jahre

Kriterien für die Wahl des Installationsorts

  • Beim Standort eines Home Labs sollte man Temperatur und Belüftung, Kabelverlegung, Zugänglichkeit, Stromversorgung, Lärm, Staub und Laufwege gemeinsam betrachten
  • Die Vor- und Nachteile der einzelnen Orte sind klar unterscheidbar
    • Homeoffice: kurze Kabelwege, weil Schreibtisch und Geräte nah beieinander sind, aber nicht jeder hat ein Homeoffice oder möchte zusätzliche Technik in einem Raum, in dem man ohnehin lange bleibt
    • Wohnzimmer: meist kühl und mit Platz, aber mit höherem Durchgangsverkehr und Beschädigungsrisiko
    • Kleiderschrank: leicht zugänglich und gut zu verstecken, aber oft mit schlechter Belüftung und wenig Platz
    • Keller: meist kühl, aber potenziell problematisch wegen Überflutung oder schlechter Zugänglichkeit
    • Dachboden: wenig Lärm und teils einfache Kabelverlegung, aber je nach Region mit Hitze-, Leckage- oder Feuchtigkeitsproblemen
    • Garage: reduziert den Lärm im Haus und fällt weniger auf, birgt aber Risiken durch Insekten, Hitze, Staub, lange Kabel und mögliche Fahrzeugschäden
  • Die reale Konfiguration wurde im Homeoffice aufgebaut, wo Laptop, Desktop, Server und weitere Geräte im selben Raum stehen und dadurch kurze Kabelwege möglich waren
  • Vor der Installation ist es sinnvoll, ein Heimnetz-Diagramm zu zeichnen oder ein Netzwerkplanungstool zu verwenden, um Kabelwege und Grundriss zuerst zu prüfen

Racks, Cabinets und Unterbringung der Hardware

  • Netzwerk-Cabinets/-Racks und Server-Cabinets/-Racks werden leicht verwechselt, aber Router, Switches und Patchpanels sind normalerweise flacher als Server und erzeugen auch weniger Abwärme
  • Wer Server-Hardware unterbringen will, kann bei Netzwerk-Cabinets schnell an Grenzen bei Tiefe und Belüftung stoßen; Modelle mit Glastür können bei der Wärmeabfuhr nachteilig sein
  • Bei der Wahl von Cabinet oder Rack sollte zuerst die Installationsumgebung betrachtet werden
    • Bei großen und schweren Servern ist die Stabilität eines Cabinets oder 4-Post-Racks wichtig
    • Wenn häufiger Zugriff auf Seiten- oder Rückseite nötig ist, sind Open Racks oder Cabinets mit abnehmbaren Seitenteilen im Vorteil
    • Geräte mit zusätzlichem Kühlbedarf erfordern in geschlossenen Cabinets eine besonders gute Belüftungsplanung
    • In staubigen Räumen schützt ein Cabinet die Hardware besser
    • In Bereichen wie dem Wohnzimmer, in denen Gäste ein- und ausgehen, kann ein abschließbares Cabinet ordentlicher wirken
    • Wenn Zugangsbeschränkung oder Sicherheit wichtig sind, ist ein Cabinet mit Schloss geeignet

Empfohlene Hardware und Auswahlkriterien

  • Die Produktpreise basieren auf den aktuellen Amazon-Preisen und können sich ändern; einige Amazon-Links sind Affiliate-Links

  • ISP-Kabelmodem

    • Einsteiger können mit Home-Networking-Experimenten schon beginnen, indem sie zunächst nur das vom ISP bereitgestellte Modem ersetzen, statt sofort ein komplettes Rack aufzubauen
    • Viele ISPs in den USA verlangen eine monatliche Modemmiete, daher kann sich ein eigener Kauf finanziell lohnen
    • Die vom ISP gelieferte Modem-/Router-Kombination kann qualitativ schwach oder gebraucht sein und nur wenige Funktionen bieten; bei neuen Schwachstellen ist man zudem oft auf Firmware-Updates des ISP angewiesen
    • Wer einen guten ISP und ausreichende Hardware hat, kann diese weiterverwenden; Gründe für einen Austausch sind zusätzliche Netzwerkfunktionen und eine bessere Experimentierumgebung für das Home Lab
    • Beispiele für Kabelinternet sind Motorola MB7621 32×8 und Motorola MB8611 als DOCSIS-3.1-Modelle
    • Bei Glasfaser lässt sich je nach Anbieter das ONT manchmal direkt ersetzen, in vielen Setups wird das ONT jedoch vom ISP verwaltet und der Nutzer kontrolliert erst ab dem Router
    • Kabelmodems erzeugen viel Wärme und sollten daher oben im Rack platziert werden oder genug Freiraum für Luftstrom nach oben und unten haben

  • Rack

    • Eine Rack Unit U oder RU entspricht 1 3⁄4 Zoll bzw. 44,45 mm und bezeichnet bei 19-Zoll- und 23-Zoll-Racks die Höheneinheit von Geräten
    • Ein typisches Full-Size-Rack ist 42U hoch
    • Beispielgeräte:
    • Beim Messen von Rack-Hardware sollte nicht die Innenbreite des Racks, sondern die Breite des Rack-Bodens mit der Gerätebreite verglichen werden

  • UPS

    • In einer Umgebung mit Propan-Notstromgenerator und rund einer Minute Umschaltzeit war eine UPS nötig, die bei 100W bis 200W Last einige Minuten überbrücken kann
    • Die CyberPower OR500LCDRM1U UPS ist ein 1U-Rackmount-Modell mit 500VA/300W, 6 Steckdosen, AVR und einem Gewicht von etwa 20 lbs
    • Diese UPS erreichte bei etwa 50 % Batterienutzung mit zwei PoE-APs und einem 27-Zoll-Monitor etwas mehr als 30 Minuten Laufzeit
    • Eine UPS für sehr lange Laufzeiten wird schnell teuer; realistischer ist eine Auslegung, die essenziellen Geräten mit niedriger Leistungsaufnahme genug Zeit für ein sicheres Herunterfahren gibt
    • PoE-APs benötigen jeweils maximal etwa 9W und helfen so, die UPS-Last im Bereich von 20 bis 30 % zu halten

  • Regalböden und Strom

    • Fehlt bei einer 1U-UPS die Rackmontage, kann sie zwar auf andere Geräte gestellt werden, doch ein belüfteter 1U-Regalboden ist besser, um die Batterie kühl zu halten und Wärmestau zu reduzieren
    • AC Infinity Vented Cantilever 1U Universal Rack Shelf ist in Tiefen von 6 bis 16 Zoll erhältlich; Lüftungsöffnungen und Schlitze helfen bei Kühlung und Kabelmanagement
    • Die CyberPower-UPS besitzt 6 Steckdosen, davon 4 mit Batterie-Backup und Überspannungsschutz sowie 2 nur mit Überspannungsschutz
    • ADJ Products AC POWER STRIP PC-100A kann direkt an die 1U-CyberPower-UPS angeschlossen werden und erleichtert das Ein- und Ausschalten einzelner Geräte
    • Outlet Saver und 1U-Blindpanels helfen bei der besseren Stromnutzung und beim Luftstrom im Rack

Kühlung, Netzwerk, Kabel und Server-Konfiguration

  • Kühlung

    • Die Einhaltung geeigneter Temperaturen für Rack-Geräte ist wichtig, um Überhitzung zu vermeiden, eine konstante Leistung zu sichern und die Lebensdauer zu verlängern
    • AC Infinity CLOUDPLATE T7-N 2U Intake war etwa vier Jahre im Einsatz und kühlte das Rack selbst bei niedriger Lüfterdrehzahl gut
    • Durch Staubansammlung begannen nach etwa zwei Jahren erste Lüfterausfälle; im dritten Jahr waren 3 von 4 Lüftern defekt
    • Wegen interner 3-Pin-Wafer-Steckverbinder, die mit Heißkleber auf der Platine befestigt waren, war ein Lüftertausch schwierig
    • Im April 2025 wurde das Gerät entfernt und auf passive Kühlung mit einem belüfteten 1U-Panel umgestellt, was seitdem problemlos funktioniert
    • In einer klimatisierten und staubarmen Umgebung sind aktive Kühllüfter womöglich nicht nötig; falls doch, sollte man sie alle paar Monate mit Druckluft reinigen, um eher eine Lebensdauer von 2 bis 3 Jahren zu erreichen

  • Router und Switches

    • Die Anforderungen an Routing und Switching lassen sich nach Einschätzung des Autors meist mit Hardware von Cisco, Ubiquiti und TP-Link abdecken
    • Dieses Setup ähnelt eher einer Small-Business-Umgebung als einem typischen Homeoffice und ist auf spätere Funktionserweiterungen ausgelegt
    • Beispiele für Router:
    • Beispiele für Switches:
    • Weitere Optionen wie Netgear, pfSense, OPNsense und IPFire sind ebenfalls möglich; nicht jede empfohlene Hardware passt zu jedem Anforderungsprofil, daher ist eigene Recherche nötig

  • Patchpanel und Kabel

    • Es wurde ein 16-Port-Patchpanel gewählt, rückblickend wäre ein 24-Port-Patchpanel aber die bessere Entscheidung gewesen
    • Trotzdem ist 16 Port selbst nach sechs Jahren gerade noch ausreichend
    • Der schnellste Tarif des ISP bietet 160 Mbps Download und 30 Mbps Upload, daher wurden im Home Lab weder CAT8 noch CAT7 benötigt
    • Da die 1000-Mbps-Grenze ausreichte, wurden eine 250-Fuß-CAT6-Rolle und mehrere CAT6-Kabel in verschiedenen Längen gekauft
    • Für flüssigeren Netzwerkverkehr kann CAT6a oder höher sinnvoll sein; wenn RJ45-Stecker und Patchpanel das jedoch nicht unterstützen, sind CAT7- oder CAT6a-Kabel vergeudetes Geld
    • Da beim ersten Aufbau etwa 3 Fuß Koaxialkabel fehlten, ist es sinnvoll, Kabel mit etwas Reserve einzuplanen

  • Server

    • Die Anforderungen an Server unterscheiden sich stark je nachdem, ob NAS, VMs, Webserver, Backup-Server, Mailserver oder Werbeblocker gehostet werden sollen; deshalb wird kein bestimmtes Modell empfohlen
    • In der realen Konfiguration kommen ein gebraucht bei eBay gekaufter ThinkCentre M73 und ein ThinkCentre M715q zum Einsatz
    • Beide Geräte arbeiten leise und kühl und führen Ubuntu Server sowie Windows 10 aus
    • Als klassische Server kommen Produkte von Dell, HP, Cisco und Lenovo infrage; im Home-Lab-Bereich wird häufig gebraucht über Craigslist oder eBay gekauft

Einfaches Beispiel für eine hausweite VPN-Konfiguration

  • Ein für einen Freund aufgebautes hausweites VPN lief an einer 700VA-UPS mit weniger als 40W Verbrauch und zeigt damit, dass ein Home Lab nicht zwingend komplex oder stromhungrig sein muss
  • Die Komponenten waren:
    • StarTech.com 6U Wall Mount Network Equipment Rack
    • AC Infinity Vented Cantilever 1U Universal Rack Shelf
    • C2G 12-Port Patch Panel
    • VCE CAT6 RJ45 Keystone Jack Inline Couplers
    • Raspberry Pi 4 2GB Basic Kit mit Unifi Controller
    • Brume GL-MV1000 mit Edge Gateway und WireGuard VPN
    • Edgeswitch 10xp
    • StarTech.com 8 Outlet Horizontal 1U Rack Mount PDU Power Strip
    • CyberPower SL700U Standby UPS System, 700VA/370W

Sechs Jahre Entwicklung und Fazit

  • Das Home Lab begann 2020 mit einem 12U-Wandrack, einem Kabelmodem und einem EdgeRouter
  • Sechs Jahre später wurde es auf 10G-Uplink, eine pfSense-Firewall und 2.5G-LAN aufgerüstet; das Monitoring wechselte von Zabbix zu Checkmk RAW
  • Wichtige Veränderungen waren:
    • März 2020: erster Build abgeschlossen
    • April 2020: 4G-Failover, VLANs, Blindpanels und Zabbix-Monitoring hinzugefügt
    • Mai 2020: Raspberry Pi und Monitor für das Zabbix-Dashboard ergänzt
    • Juni 2020: Tastatur ergänzt, Mesh-Abdeckung durch getöntes Plexiglas ersetzt
    • 2022–2023: Umzug in ein neues Haus, EdgeRouter durch Peplink Balance 20x ersetzt, UPS aufgerüstet
    • Seit 2025: Upgrade auf 10G-Uplink und 2.5G-LAN, pfSense-Firewall, Wechsel von Zabbix zu Checkmk RAW, Umstellung auf passive Kühlung
  • Das wichtigste Betriebsprinzip ist, klein anzufangen und auf Wachstum vorbereitet zu sein
  • Man braucht nicht vom ersten Tag an Rack, Cabinet, Patchpanel und alle Geräte; ein sinnvoller Start kann schon mit dem Austausch des ISP-Modems und einem passenden Router erfolgen
  • Bei der Geräteauswahl sollte der Stromverbrauch von Anfang an berücksichtigt werden, damit die Stromkosten nicht unnötig stark steigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-09
Hacker-News-Kommentare

  • Der Artikel ist gut, aber Umfang und Größenordnung können leicht einschüchternd wirken. Mit einem Homelab kann man schon mit einem einzigen NUC auf dem Schreibtisch ausreichend gut anfangen, und mit 64 GB RAM lässt sich wirklich viel betreiben.
    Ein NUC ist für den 24/7-Betrieb sehr effizient, wird aber laut, wenn die CPU-Last länger anhält. In so einem Fall ist es sinnvoll, auf eBay mit einem OptiPlex oder Precision Tower SFF zu erweitern, möglichst mit einem Modell, das ECC unterstützt. Dell-SFF-Geräte sind klein, aber es sind vollwertige Desktop-/Server-Systeme mit leisen Lüftern; sie nehmen auch 10G Mellanox 3-Karten für 40 Dollar von eBay auf und lassen sich gut horizontal stapeln. OptiPlex-Modelle vor CPUs der 12. Generation sollte man eher meiden, weil Stromverbrauch und Platzbedarf zum Problem werden können; gebrauchte i5-12500 sind inzwischen schon ziemlich günstig. Mit LGA1700 kann man bei Bedarf auch einen i9-14900 non-K einsetzen.

    • Man muss ein Rack nicht zu ernsthaft als Pflichtbestandteil betrachten. Racks sind cool, und ein Homelab-Rack sieht gut aus, aber wenn es um Nutzbarkeit und Lernen geht, sollte man einfach verwenden, was einem gefällt.
      Persönlich habe ich vier Kisten in einer Ecke gestapelt und nutze ein Fake-Rack, bei dem zwei Rack-Seitenwände hinter der Werkbank verschraubt sind und Komponenten daran festgeschraubt werden. Ein NAS auf einem Regal und mehrere Raspberry Pis sind ebenfalls angeschlossen; mir gefällt dieses Chaos, und ich habe viel dabei gelernt. Man kann mit dem anfangen, was man hat, und bei Bedarf erweitern. Ein Rack ist dann cool, wenn man tiefer ins Hobby einsteigt und einem Stilpunkte wichtig werden.
    • Intel NUCs sind für Homelab-Nutzer absurd gut. Ich habe kürzlich ein paar gekauft, und besonders der Stromverbrauch ist hervorragend.
      An einem tasmota-basierten Smart Plug gemessen lag der Idle-Verbrauch ungefähr bei 6 W. Ich optimiere zwar immer über BIOS-Einstellungen und tuned-Profile auf niedrigen Stromverbrauch, aber generell kommen NUCs nur selten über 30 W. Das ist etwa die Hälfte einer alten Glühbirne.
    • Mein erstes Homelab war ein Laptop mit kaputtem Monitor. Ubuntu Server darauf aufzusetzen war nicht besonders schwierig, er hatte einen eingebauten Gigabit-Ethernet-Port und auch USB 3.0, sodass sich mit Festplatten leicht brauchbare Geschwindigkeiten für ein NAS erreichen ließen.
      Alte gebrauchte Laptops, besonders solche mit kaputtem Display, bekommt man fast geschenkt, und wenn man schon einen hat oder jemand aus dem Bekanntenkreis einen abgibt, ist er wirklich kostenlos. Wenn das Ziel etwa Plex ist, funktioniert das gut, und der Stromverbrauch eines Laptops liegt besonders im Idle nicht viel höher als bei einem NUC. Heute nutze ich einen richtigen Rackmount-Server, weil es cool aussieht, aber für die meisten reicht meiner Meinung nach ein alter Laptop völlig aus.
    • Für die meisten Einsteiger ist es viel sinnvoller, mit einem billigen wiederverwerteten Desktop oder einem Raspberry Pi Dinge wie PiHole zu betreiben und von dort aus zu erweitern. Mein Homelab[0] begann ebenfalls mit einem einzelnen Pi für PiHole und ist inzwischen auf eine Vier-Geräte-Konfiguration gewachsen, die alles betreibt, was ich brauche: Jellyfin, Calibre, DNS usw.
      Später, als ich auf Rackmount umgestiegen bin und einen Teil der Hardware aufgerüstet habe, war dieser „Einsteiger“-Guide allerdings wirklich hilfreich.
      [0] https://blog.janissary.xyz/posts/homelab-0
    • Mein „Homelab“ besteht ebenfalls aus mehreren kleinen Computern, die entweder komplett versteckt oder dort untergebracht sind, wo sie einen Zweck erfüllen. Ein alter Celeron-NUC läuft unter dem Sofa mit Pi-Hole, Syncthing und Diagnose-Tools; die Auswirkungen auf die Stromrechnung sind vernachlässigbar.
      Ein Lenovo-Mini-PC hinter dem Fernseher dient zugleich als Syncthing-Node und HTPC. Es ist nicht die ausgefeilteste Konfiguration der Welt, aber sie funktioniert gut, ist sehr günstig und passt in eine Wohnung.

  • Ein kleiner Exkurs, aber für Heimserver möchte ich Proxmox wirklich sehr loben. Ich habe 25 Jahre lang zu Hause in irgendeiner Form Linux-Server betrieben und immer ein einzelnes System wie Ubuntu von Hand verwaltet – das war unglaublich lästig.
    Proxmox macht es einfach, auf einer einzigen Hardware mehrere Container und virtuelle Maschinen zu betreiben. Anfangs habe ich damit begonnen, ein großes Ubuntu-System zu virtualisieren, aber schon das bringt Vorteile wie Backups und Hochverfügbarkeit. Inzwischen habe ich angefangen, die Dienste jeweils in eigene Container aufzuteilen, und das ist viel sauberer.

    • Proxmox ist großartig. Ich habe aus zwei ungenutzten Maschinen – einer fast zehn Jahre alten und einer vergleichsweise aktuellen mit einem 5950X – einen Cluster gebaut, und jetzt muss ich mir keine Sorgen mehr machen, dass eine Debian-Box mit allen Diensten ausfällt und alles weg ist.
      Virtuelle Maschinen an sich sind schon nützlich, aber die Migration zwischen Maschinen sowie die zentralen Backup-/Recovery-Tools, die Proxmox bietet, fühlen sich wirklich befreiend an. Kürzlich habe ich einer Windows-VM PCIe-GPU-Passthrough gegeben und streame mit Moonlight/Sunshine Spiele auf schwächere Maschinen im Haus; das funktioniert so gut, dass der eigentliche Gaming-PC nur noch in der Ecke Staub ansetzt. Meine einzige Beschwerde ist, dass ich mir eine günstigere kostenpflichtige Lizenz wünschen würde. Ich würde den Gegenwert gern honorieren, aber über 100 US-Dollar pro CPU und Jahr sind für ein Hobby zu teuer. Ich bin dankbar, dass der kostenlose Tier überhaupt nicht nervt, aber eine Zwischenstufe wäre schön.
    • Proxmox ist besonders für Homelab-Einsteiger, die mit Linux vertraut sind, enorm hilfreich. Man kann beim Lernen sehr einfach verschiedene Umgebungen erstellen und wieder löschen.
      Allerdings ist Storage insgesamt nicht einfach. Es ist schwer, die Konsequenzen der verschiedenen Optionen richtig zu verstehen, und wenn man mit zfs, lvm, lvm-thin, Repartitionierung usw. nicht ziemlich vertraut ist, ist es schwierig, die Grundlage für ein NAS sauber einzurichten.
    • Ich stecke noch immer in der technischen Schuld eines monolithischen Heimservers fest und denke ebenfalls über eine Migration nach. Der Punkt, der mich immer beschäftigt, ist Storage. Dieser Server ist auch ein NAS, das Dateien per SMB bereitstellt und Medien per Plex ausliefert.
      Ich habe gehört, dass manche Leute das Daten-Array[1] direkt in Proxmox mounten und nur die Dinge oberhalb der Storage-Schicht wie Plex virtualisieren, während andere einen HBA[2] per PCI-Passthrough an eine NAS-VM durchreichen. Der Vorteil der ersten Variante dürfte sein, dass man statt Loopback-SMB/NFS/9p direkt in LXC-Container bind-mounten kann. Wieder andere nutzen TrueNAS oder Unraid als Bare-Metal-Basis und lassen sie sowohl Storage als auch Hypervisor übernehmen, was ebenfalls Sinn ergibt. Die Linux-Version von TrueNAS hatte inzwischen auch Zeit, auszureifen; vielleicht sollte ich sie ausprobieren. Ich nutze außerdem Hardware-Transcoding über Quicksync im Intel-Prozessor und frage mich, ob es Probleme gibt, das durch eine VM hindurch zu verwenden. Wahrscheinlich müsste ich auf das lokale Proxmox-TTY verzichten.
      [1] Gemeint ist ein Array mit echten Dateien, nicht VHDs. Ich halte das ohnehin lieber getrennt, und es ist auch nötig, weil ich mir nicht leisten kann, alle Daten auf SSDs zu legen, und es nicht ertrage, den OS-Root auf HDDs zu haben. Alternativ wäre vielleicht ein einzelnes Master-ZFS-Array ideal, mit einem Dataset für Dateien und einem zvol oder NFS für VM-Roots.
      [2] Ich habe gehört, dass das zuverlässiger ist als Passthrough einzelner SATA-Geräte, aber den Nachteil hat, gröber gebündelt zu sein. Das heißt, die VM kontrolliert exklusiv alle Ports, sodass man dort keine Platten anschließen kann, die nicht Teil des Arrays sind.
    • Natürlich kann man auf einem Ubuntu-System auch einfach Container laufen lassen, und Backups sind ebenfalls nicht ausgeschlossen. Trotzdem ist es bei einem neuen Server besser, von Anfang an mit einem Hypervisor zu starten.
      Das erhöht die Flexibilität, weil man auch andere Distributionen oder Nicht-Linux-Systeme mischen kann. Ich betreibe zum Beispiel einen OPNsense-Router. Statt Proxmox nutze ich xcp-ng.
    • Ich frage mich, wie genau das Betreiben von VMs in Proxmox eigentlich Hochverfügbarkeit schafft.

  • Ich weiß, dass das zum neuen „I use Arch btw“-Meme wird, aber wenn man diesen Weg geht, würde ich als Distribution Nix sehr empfehlen. Idealerweise bringt man es einmal zum Laufen und lässt es dann einfach eingeschaltet; mit Nix ist der gesamte Systemzustand in git festgehalten
    Kein „Wie hatte ich das vor 6 Monaten noch mal repariert?“ mehr und kein manuelles Wiederzusammenbauen des Systems, nachdem ein Ubuntu-Distributions-Upgrade explodiert ist. Alles, was man geändert hat, alle installierten Pakete und gesetzten Einstellungen stehen im git-Log. Ich schaue auch oft ins git-Repository, um nachzusehen, was installiert ist und wie das System konfiguriert ist

    • I use nix btw. Stimme voll zu. Nix und NixOS sind oft schmerzhaft, aber sobald man es zum Laufen gebracht hat, ist es wirklich herrlich
      System-/Benutzer-/Anwendungseinstellungen schnell und einfach über mehrere Geräte zu synchronisieren, ist erstaunlich. Der deklarative Ansatz belohnt die harte Arbeit, bis es funktioniert, und wenn man es einmal herausgefunden hat, muss man dieselbe Sache nie wiederholen. Weil es deklarativ ist, bleiben dokumentierte Beispiele für funktionierende Konfigurationen übrig, auf denen man aufbauen kann. Gerade baue ich mit Nix „Linux from Scratch“, um die Nix-Entwicklungsumgebung zu lernen; es geht langsam, aber jeder Erfolg wird zu einem reproduzierbaren Zustand verfestigt. LLMs helfen definitiv dabei, die verstreute und dürftige Dokumentation zusammenzufassen, aber man braucht trotzdem ziemlich viel Durchhaltevermögen. Insgesamt habe ich sehr viel Spaß mit Nix und möchte es in meinem Homelab stärker nutzen
    • Ich wünschte, die Lernkurve von Nix wäre flacher. Oder ich wäre klüger. Es steht auf meiner Liste der Dinge, mit denen ich irgendwann herumspielen will, aber diese Liste ist lang, und ich bin noch nicht über die Hürde gekommen
      Die Konzepte verstehe ich, aber wenn ich ein neues Paket oder eine neue App ausprobieren will, komme ich mit docker-compose und VMs schneller ans Ziel, als mich erst durch den Nix-Weg zu verknoten
    • Zur Einordnung: Ich nutze Arch in meinem Homelab und erreiche trotzdem cattle not pets. Das Arch-Installationsmedium enthält cloud-init, also lege ich eine cloud-config mit Modulen, die den Server von Grund auf erstellen, auf einen separaten USB-Stick, stecke ihn zusammen mit dem Installationsmedium und einem Laufwerk mit dem Label cidata ein und schalte ein
      Vielleicht wäre Nix einfacher gewesen, aber cloud-init lässt einen einfach Skripte ausführen, die jemand, der so etwas macht, wahrscheinlich ohnehin schon schreiben kann; dafür braucht es keine separate DSL. Manche werden sagen: „Ich hasse YAML“, aber wer sich für Homelabs interessiert, verwaltet wahrscheinlich auch im Job mehrere Server und kommt um cloud-init, Ansible, Kubernetes oder irgendetwas, das ohne Wahlmöglichkeit YAML verwendet, nicht herum. Wenn der Zweck eines Homelabs darin besteht, Dinge aus der Arbeit zu üben, ohne Gefahr zu laufen, die Sachen anderer Leute kaputtzumachen, ist es besser, sich mit den Tools vertraut zu machen, die man sowieso verwenden muss, und die Umgebung zu Hause nicht zu stark von der im Job abweichen zu lassen. Natürlich meinen viele Leute auf Hacker News mit „Homelab“ im Gegensatz zu mir eher Selfhosting von Medienservern, Chat, Foto-Sharing usw. für Familie und Freunde, nicht ein Mini-Rechenzentrum zum Üben eines echten Rechenzentrums
    • Ich hatte anfangs auch mehrere RasPis mit unterschiedlichen Raspbian-Versionen laufen und war irgendwann von Configuration Drift genervt, also habe ich alles auf Nix umgestellt. Eine einzige Nix Flake zu schreiben und damit deklarative SD-Karten-Installationsimages für alle Geräte bauen zu können, macht das Verwalten mehrerer Maschinen wirklich traumhaft einfach
      Falls es dich interessiert: Das Tutorial ist hier[0]. Das einzige Problem ist die Remote-Verteilung der Nix-Konfiguration. Das einzige First-Party-Tool, nixops, ist faktisch verwaist und nicht mehr unterstützt. Community-Tools wie morph oder deploy-rs sehen vielversprechend aus, aber Flakes-Support sowie Aktivität/langfristige Tragfähigkeit sind sehr unterschiedlich
      [0] https://blog.janissary.xyz/posts/nixos-install-custom-image
    • Das Wiederzusammenbauen des Systems nach einem kaputten Ubuntu-Distributions-Upgrade vermeide ich, indem ich auf meinen Linux-Maschinen Gentoo Linux laufen lasse. Ich habe gehört, dass Arch auch gut sein soll, habe es aber nie benutzt
      Ubuntu ist einfach nicht gut. Ich habe früher einige Jahre Ubuntu verwendet und war wirklich froh, endlich eine stabile und leicht zu bedienende Linux-Distribution für Nichtfachleute empfehlen zu können. Aber nachdem zwei oder drei In-Place-Upgrades hintereinander das System beschädigt hatten und man Gentoo’s gut dokumentierten Installationsprozess plus jahrelang mühsam erworbenes Sysadmin-Wissen brauchte, um es zu reparieren, war für mich Schluss. Lasst eure Freunde kein Ubuntu benutzen

  • Ich hatte meine Ausrüstung jahrelang in einem IKEA FRIHETEN Sofa untergebracht. Die Vorteile: leicht zugänglich, bis auf ein Stromkabel + eine Glasfaser-WAN-Leitung + ein Ethernet-LAN-Kabel völlig unsichtbar, und die Konstruktion macht es einfach, Kabel nach außen zu führen sowie innen zu platzieren/zu verkabeln
    Geräuschdämpfung gibt es gratis dazu, und im Winter bleibt der Hintern beim Sitzen garantiert warm. Der Ehepartner sieht keine blinkenden Lichter, was schön ist, und hat nicht bemerkt, dass ich eine UPS und Disk-Bays gekauft hatte. Nachteile: Innen daran zu arbeiten ist etwas unbequem; beim Sitzen oder Öffnen/Schließen gibt es Vibrationen, die rotierende Festplatten womöglich nicht mögen; die Wärme war überraschend unproblematisch, jedenfalls nicht schlimmer als in einem Schrank. Es besteht das Risiko, Flüssigkeit zu verschütten, aber konstruktionsbedingt läuft sie eher außen herum als hinein; im schlimmsten Fall stellt man etwas unter die Hardware. Man sollte etwas Kabellänge als Reserve lassen, falls der Ehepartner beim Putzen die Möbel verschiebt und an den Kabeln zieht
    † https://www.ikea.com/us/en/images/products/friheten-sleeper-...
    †† Nachdem es durch die hintere Ecke geführt und bis zur nächsten Steckdose in der Wand versteckt war, war es tatsächlich nicht zu sehen

    • Beim IKEA KIVIK Sofa, der Nicht-Bett-Version, hatte ich eine ähnliche Idee. Die breiten, kantigen Armlehnen sind nach unten offen, sodass man kleine SFF-PC-Tower oder Rackmount-Geräte seitlich hineinschieben könnte, und unter den Sitzen ist ebenfalls Platz für Rackmount-Geräte
      Einer der Gründe, warum ich es am Ende nicht gemacht habe, war, dass ich keinen Brand wollte, bei dem direkt über und um die Geräte herum Sofa-Brennstoff liegt. Mehr als um die Server selbst machte ich mir etwas Sorgen um die UPS. Wenn man den Bereich mit Blech auskleidet und, falls der UPS-Akkutyp gasen kann, gut belüftet, wäre ich etwas beruhigter, aber das wäre dann zu viel Aufwand. Also landeten die Geräte am Ende in einem Rack/Regal, weg von Stoffmaterialien, und so, dass ich sie im Blick behalten kann
    • Wirklich großartig. Ich frage mich, ob es echte Fotos davon gibt, wie die Server darin untergebracht sind
      Belüftung, Wärme und Brandgefahr würden mir ziemliche Sorgen machen. Erinnert mich an den lack rack
      https://archive.is/Uf2k3

  • Die ganze Home-Lab-Welt ist großartig. Jede Person hat andere Ziele – niedriger Stromverbrauch, interessante Prozessoren, Datenhoheit, Hochverfügbarkeit, UPS/USV fürs ganze Haus – und spannend ist, dass der gemeinsame Schnittpunkt dieser überlappenden Interessen und der Software das Zuhause ist.
    Auch die Bandbreite der Leute ist interessant, von Branchenprofis, die damit als Hobby herumspielen, bis hin zu Menschen außerhalb der Branche, die davon angezogen werden. Ich bin selbst richtig hineingezogen worden, und zumindest für mich bringt es ein Stück des magischen Gefühls des frühen Internets zurück.

    • Die Community ist wirklich hervorragend. Auf Reddit und Lemmy ist sie sehr aktiv, und die Leute finden immer schnell Lösungen und geben Ratschläge, wie man Dinge als Best Practices einrichtet. Wenn einen das Lernen solcher Dinge interessiert, ist das ein echter Schatz.

  • Aus einer anderen Perspektive sieht mein Home Lab so aus: Es steht auf einem Regal in meinem Büro im Keller, die Belüftung ist in Ordnung, und das WLAN ist okay, aber nicht besonders gut.
    Die Hardware ist ein alter PC, den ich auf einer lokalen Tauschbörse aufgetrieben habe; ich habe RAM aus einem anderen alten PC ergänzt und Festplatten sowie eine WLAN-Karte gekauft. Als Software laufen Debian stable und podman/podman-compose. Jeder nützliche Dienst ist ein Ordner mit einer Compose-Datei, die ich mit podman-compose in eine systemd-Unit umwandle. Wenn dir die im Artikel beschriebene Konfiguration gefällt, ist das super – mach ruhig. Aber man muss das nicht so machen, und schon gar nicht von Anfang an. Auf diesem alten, fast kostenlosen PC laufen mehrere Dienste, die meine Familie täglich nutzt; dabei wird nicht einmal die Hälfte der 16 GB RAM verwendet, und die CPU-Auslastung steigt nicht über 5 %.

    • Mein liebster Home-Lab-Aufbau war ein alter Laptop, ursprünglich mit XP, später auf Ubuntu umgestellt, zusammen mit ein paar USB-Laufwerken, die ich in die oberste Schublade eines Aktenschranks gelegt hatte.
      Hinten hatte ich ein Loch für die Kabel gebohrt, und die Wärmeentwicklung war gering genug, dass die Luftzirkulation nie ein Problem war. Darauf hostete ich meine persönliche Website und eine Aquarium-Webcam, verband ihn mit der Türklingel und nutzte ihn außerdem für XMPP und als Dokumentenspeicher. Wenn ich einen Server brauchte, kam einfach alles dort drauf. Nach einem Umzug nutzte ich dann einen alten Mac Mini als NAS, und danach hatte ich kaum noch Zeit, daran herumzubasteln.
    • Ähnlich ist mein Home Lab ein alter Gaming-Rechner, der in eine Ecke geschoben wurde und über systemd mehrere docker compose-Dienste ausführt.
    • Das könnte fast meine Geschichte sein. Der Unterschied ist, dass mein „Server“ ein aus dem Leasing zurückgegebener Dell Micro PC ist, den ich mit maximalem RAM bestückt habe und auf dem ProxMox läuft; mehrere VMs und die auf einem Synology NAS gespeicherten Daten stehen alle in einem Schrank im Kellerbüro.
      Für den Fernzugriff habe ich außerdem tailscale eingerichtet.

  • Mit der Zeit ist ein ziemlich großes Homelab entstanden, in das viel Arbeit geflossen ist, und das gut funktioniert – ich mag es sehr. Das eigentliche Problem ist aber Disaster Recovery. Alles zu replizieren würde gefühlt ewig dauern, und ich bin mir nicht sicher, ob ich mich überhaupt an alles erinnern könnte.
    Router-Konfiguration, Switch-Konfiguration, NAS, Docker-Container, die über mehrere VLANs verteilt sind usw. – das Netzwerk hatte ich anfangs zwar skizziert, aber im Laufe der Zeit nicht aktuell gehalten. Ich frage mich, ob es gute Tools gibt, um Infrastrukturdiagramme zu erstellen, zu dokumentieren und aktuell zu halten. Backups und Upgrades sind ebenfalls ein Dauerthema. Oft erstelle ich einen Container und weiß sechs Monate später überhaupt nicht mehr, was ich gemacht habe. Dutzende Container sind über mehrere Maschinen verteilt – NUC, NAS, Desktop, Server –, und bei jedem Dienst fühlen sich die Orte für Bind Mounts, der ausführende Benutzer und die Konventionen für Berechtigungen anders an. Das kann ich nicht alles im Kopf behalten, erst recht nicht nach längerer Zeit. Es wäre schön, wenn man in einer zentralen Oberfläche einfach Backup, Restore und Upgrade anklicken könnte. Ich vermisse die frühere Zeit, als man mit VM-Clones/Snapshots alles eher wie Cattle betrieben hat. Auf der Proxmox-Maschine habe ich noch ein paar VMs, daher ist es dort ein Stück weit ähnlich, aber für das gesamte Homelab gibt es so etwas nicht. Theoretisch möchte ich an den Punkt kommen, an dem ich selbst nach einem Hausbrand die gesamte Konfiguration vollständig wiederherstellen kann. Es muss doch einen einfacheren Weg geben, als für die Verwaltung der Heim-Umgebung gleich bis Kubernetes zu gehen; mich würde interessieren, was andere verwenden.

    • Das Kernproblem scheint fehlende Konsistenz zu sein. Ich würde damit anfangen, die Anzahl der Gerätetypen, Deployment-Methoden usw. zu reduzieren.
      Für ein oder zwei Personen ist es sehr schwer, in die Breite zu skalieren; wenn man aber einen Stack in die Tiefe beherrscht, kennt man ihn gut, und wenn alles exakt auf dieselbe Weise funktioniert, ist man eher in einem Zustand, in dem entweder alles funktioniert oder alles nicht funktioniert. Am Ende entsteht eine Struktur, in der alles zuverlässig funktionieren muss.
    • Letztes Jahr habe ich versehentlich ein Server-Laufwerk gelöscht, aber dank meiner Konfiguration war es nicht ganz so schlimm. Meine Strategie ist, in jedem Projektordner ein deploy.ps1-Skript zu haben.
      Zu 80 % geht es nur darum, eine VM zu erstellen, Dateien mit rclone zu kopieren und bei Bedarf Dienste zu installieren/zu starten; mit eigenen Befehlen sind das ungefähr drei Zeilen. Wenn die VM läuft, dauert das Deployment etwa 100 ms. Manchmal wird das Skript komplexer, aber die Grundidee ist: Egal welches System intern verwendet wird, deploy.ps1 ausführen, und es soll ohne Internet, ohne Abhängigkeiten und bis zum Wärmetod des Universums funktionieren. Nachdem ich alles verloren hatte, habe ich deploy erneut ausgeführt und die Projekte in einer Liste gebündelt, um alles wiederherzustellen. Dass die Routing-Konfiguration nicht zu 100 % dokumentiert ist, kann ich nachvollziehen. Meine Router-/Switch-Konfiguration ist ehrlich gesagt auch viel zu komplex und sollte reduziert werden.
    • Es wäre schön, wenn Firmen wie Framework oder System76 einen reproduzierbaren Fertigungsprozess anbieten würden, der Hardware als Code behandelt, ähnlich wie Nix/Guix Builds verwaltet. Disaster Recovery würde dadurch viel einfacher.
      Super Micro Computer kann das vielleicht schon, aber deren Zielgruppe sind Rechenzentren. Davon kann man nur träumen.
    • Da die Komplexität der Infrastruktur offenbar nicht hilft, würde ich zuerst damit anfangen, sie zu reduzieren. Ich nutze einen einzelnen Server, Fujitsu D3417-B, Xeon 1225v5, 64 GB ECC, WD SN850x 2 TB NVMe mit Proxmox, sowie einen OpenWRT-Router Banana Pi BPI-R3.
      Proxmox verbraucht im Leerlauf etwa 12 W, OpenWRT etwa 4,5 W, und über NodeJS kann ich auf OpenWRT MeshCommander für Remote-Management laufen lassen. Da ich die native Verschlüsselung von ZFS nutze, mache ich vollständige Backups auf eine externe Festplatte so:
      # create backup pool on external drive
      zpool create -f rpoolbak /dev/sdb
      # create snapshot on proxmox NVMe
      zfs snapshot -r "rpool@backup-2024-01-19"
      # recursively send the snapshot to the external drive (initial backup)
      # pv only is there to monitor the transfer speed
      zfs send -R --raw rpool@backup-2024-01-19 | pv | zfs recv -Fdu rpoolbak
      Für inkrementelle Backups reicht die Option -I plus zwei Snapshots, die Start und Ende markieren.
      # create new snapshot
      zfs snapshot -r "rpool@backup-2024-01-20"
      # only send everything between 2024-01-19 and 2024-01-20
      zfs send -RI --raw rpool@backup-2024-01-19 rpool@backup-2024-01-20 | pv | zfs recv -Fdu rpoolbak
      Es ist einfach, schnell und ziemlich zuverlässig. Mit zfs-auto-snapshot kann man das Dateisystem in 15-Minuten-Schritten zurückdrehen. Auch zum Zurücksetzen virtueller Maschinen ist das ziemlich nützlich[1]. Kürzlich ist eine NVMe, eine Samsung 980 Pro, ausgefallen; ich habe dann mit zfs das Backup in die Gegenrichtung wiederhergestellt, von rpoolbak nach rpool, per Shell-Befehl. Für 700 GB dauerte das etwa 2 Stunden, und der Server war wieder online. Mir ist klar, dass ZFS insbesondere bei Verschlüsselung in manchen Fällen als „experimentell“ gilt, aber mit dem Ergebnis war ich ziemlich zufrieden.
      1: https://pilabor.com/series/proxmox/restore-virtual-machine-v...
    • Ich wollte mein Homelab neu bootstrappen, bin aber in eine Sackgasse geraten, weil ich wusste, dass ich Dinge sicher vergessen würde oder in einen Zustand käme, in dem ich „nicht alles im Kopf behalten kann“.
      Deshalb investiere ich viel Zeit in Dokumentation und versuche, es möglichst einfach, nah am Standard und mit Community-Support aufzubauen. Das Ergebnis ist: Ich habe immer noch kein Homelab – und auch kein „homeprod“, wie es hier jemand genannt hat. Ich habe auch einen Freund gefunden, den ich von derselben Problemstellung zu überzeugen versuche; vielleicht spiegeln wir unsere Homelab-Dokumentation und -Prozesse gegenseitig, damit der Bus-Faktor nicht 1 ist.

  • Seit letztem Jahr richte und betreibe ich ein Homelab, und es ist wirklich erstaunlich. Ich habe enorm viel über Container, virtuelle Maschinen und Networking gelernt.
    Einige Self-Hosting-Anwendungen wie paperless-ngx [1] und immich [2] sind beim Funktionsumfang proprietären Cloud-Lösungen weit überlegen. Mit einem VPN-Dienst wie tailscale [3] kann ich jetzt von überall auf der Welt auf mein Homelab zugreifen. Es fehlt nur noch, eine stromsparende Maschine wie einen NUC oder Mini-PC anzuschaffen, die rund um die Uhr benötigten Dienste dorthin umzuziehen und die Stromkosten zu senken. Wenn man es warten kann und am Wochenende regelmäßig Energie für Checks und Upgrades hat, empfehle ich zu 100 %, sich ein eigenes Homelab aufzubauen.
    [1] https://docs.paperless-ngx.com/
    [2] https://immich.app/
    [3] https://tailscale.com/

    • In einen Mini-PC sollte man unbedingt investieren. Ich habe einen leistungsstarken HP elitedesk gekauft, der im Leerlauf nur 7 W zieht und 38 Container ausführt.

  • Wenn Homelab-Geräte im Wohnbereich eines nichttechnischen Nerds stehen, sollte man auch an Lärm, Beleuchtung/Displays und Unauffälligkeit denken. Ich wohne in einer Wohnung und hatte sie lange in einem Schrank stehen; nach dem Umzug ins Wohnzimmer habe ich ein paar Lösungen genutzt.
    Für Unauffälligkeit habe ich einen IKEA-CORRAS-Schrank genommen, der zu den anderen Möbeln passt. Früher hatte ich Rackmount-Pfosten eingebaut, aber die standen hervor, also habe ich sie wieder entfernt. Beim Lärm habe ich fanless Geräte gewählt oder solche, die sich mit wenigen Noctua-Lüftern kühlen lassen; auch den Lüfter eines 1U-PSU durch Noctua zu ersetzen erfordert etwas Löten und Fluchen. Am Ende nutze ich in einer Nicht-Rechenzentrums-Umgebung häufig Atom-Server, die abgesehen vom PSU fanless laufen können. Der einzige aktuell nicht leise 3090-GPU-Server wird nur bei Bedarf eingeschaltet. Ich führe vom Laptop aus einen Wake-on-LAN-Befehl aus, aber möglich wären auch IPMI, PDU- oder IoT-Steckdosen-Tricks, das Anhalten der 3090 und der Lüfter per Software, Kubernetes-Automatisierung usw. Zu helle Status-LEDs lassen sich gut mit weißem Etikettendruckerband abdecken, und es sieht besser aus als gedacht. Für Lichter, die man nicht sehen muss, nehme ich schwarzes Etikettendruckerband. Bei Konsolen mag ich besonders unauffällige ausziehbare Rack-Konsolen, etwa eine alte IBM mit TrackPoint-Tastatur. Wenn ich im Wohnzimmer ein Monitoring-Display hätte, würde ich zumindest die Tastatur in eine ausziehbare Schublade legen. Nicht benötigte Geräte entsorge ich auch. Sonst braucht man mehr als doppelt so viel Rack-Platz wie aktuell, und es wird schwierig, das Ganze im Wohnzimmer wie Audiophile-Equipment wirken zu lassen. Wenn man in einer Wohnung jetzt nicht auch noch den Router anfassen will und nur Server möchte, ist auch ein Kunststoff-OpenWRT-Router eine Überlegung wert. Er kann ein paar Rack Units aus Router, Switch und Patchpanel ersetzen, und eventuell braucht man weder einen externen WiFi-AP noch Verkabelung.

    • Ich bin Mathe-Doktorand und möchte auch mit LLMs herumprobieren, daher denke ich wegen des Budgets an eine 3060 oder 3090. Allerdings nutze ich ein MacBook Pro von 2011, was für solche Arbeiten nicht besonders angenehm ist.
      Mich würde interessieren, welches Mindestbudget bzw. welche Ausgaben ich angesichts meiner „Anforderungen“ ungefähr einplanen sollte. Oder ob ihr meint, dass Seiten wie vast.ai dafür ausreichen.

  • Da ich über 30 bin, nenne ich es einfach ein Heimnetzwerk und einen Zustand mit mehr als einem Computer. Warum ich ein Heimnetzwerk habe: weil ich, wie viele hier, Netzwerkanwendungen entwickle.
    Ich bin kein Netzwerktechniker, aber es ist wirklich nützlich zu verstehen, wie verschiedene Bausteine des Internets wie TCP/IP und DNS tatsächlich funktionieren, und das hebt einen von vielen Entwicklern ab. Außerdem gefällt mir die Flexibilität, mein eigenes Netzwerk selbst zu kontrollieren und damit machen zu können, was ich will. Warum mehrere Computer? Heutzutage ist Virtualisierung ziemlich gut, deshalb ist das Herumspielen mit verschiedenen OS nicht der Hauptgrund. In der Praxis geht es eher um den Standort der Geräte. Festplatten sind ziemlich laut, deshalb möchte ich sie in einem Schrank haben, Bildschirm und Tastatur aber auf dem Schreibtisch. Also steht im Schrank ein NAS, auf dem Schreibtisch ein leiser PC und im Wohnzimmer ein lautloses Media Center plus weitere Geräte. Eines möchte ich sagen: Erliegt nicht der Versuchung von Rackmount-Server-Hardware. Sie sieht cool aus und ist gebraucht billig zu bekommen, ist aber für zu Hause nicht geeignet. Stattdessen sollte man besser Desktop-PC-Gehäuse mit großen Lüftern verwenden. Rackmount-Netzwerkgeräte sind ziemlich in Ordnung.

    • Es hängt vom Server ab. Super Micro baut Rackmount-Server, die flach genug für Netzwerkschränke oder Wandracks sind und wenig Strom verbrauchen.
      Sie haben auch ein echtes OOB-Managementsystem, was ziemlich hilfreich ist. https://www.supermicro.com/en/products/system/iot/1u/sys-510...
      Ich stimme zu, dass man von typischen tiefen Rackmount-Servern im Homelab im Verhältnis zum Aufwand wenig hat.
    • Mein Heimserver besteht aus einem 4RU-Gehäuse, das mit Desktop-Komponenten bestückt ist. Zum Glück ist 4RU hoch genug für große Lüfter, daher ist er ziemlich leise.
      Wenn man aber auch nur im Entferntesten darüber nachdenkt, sich echtes Rackmount-Equipment nach Hause zu holen, empfehle ich dringend, sich vorher irgendwie diesen schrecklichen Lärm anzuhören. Es ist schwer vorstellbar, damit zu leben.
    • Rackmount-Equipment kann okay sein, je nachdem, wo es als „Rack“ untergebracht wird. In manchen Klimazonen kann man es in die Garage oder den Keller stellen.
      Wenn man allerdings kein echtes Rack hat, wird es ziemlich lästig. Am Ende stapelt man es wie einen rackähnlichen Turm auf anderer Hardware, und wenn man an ein Gerät heranwill, an dem man arbeiten möchte, muss man alles auseinandernehmen. Wenn man auf aus Leasingrückläufern stammende Rack-Hardware setzt, sollte man es richtig machen und auch Rack und Rails kaufen. Rails können etwas teuer sein, daher sollte man auf Angebote achten, bei denen sie enthalten sind. Rails bleiben oft deutlich länger kompatibel als Server; große Firmen, die Leasingrückläufer in großen Mengen abstoßen, legen sie deshalb normalerweise nicht bei, kleinere Verkäufer dagegen oft schon.