Homelab

In der IT-Branche ist es keine Seltenheit, ein Homelab zu betreiben. Die Beweggründe mögen hier differenzieren: manche hosten gerne ihre Inhalte selbst, manch anderer strebt Zertifizierungen an und möchte gerne die dafür notwendige Infrastruktur vorhalten.

Ich persönlich hege ein großes Interesse an hardwarenahen Themen. Auf der anderen Seite bilde ich mich fachlich stetig weiter und lerne am Besten, wenn ich Systeme von Grund auf aufbaue und – zur Not – hardwarenahes Troubleshooting betreibe. Darüber hinaus hoste ich einige extern genutzte Applikationen im Homelab.

Highlevel-Übersicht

Highlevel-Übersicht

Derzeit besteht das Homelab aus:

  • einem selbstgebauten 2-Node vSphere-Cluster mit aktiviertem vSAN
  • einem HP ProLiant Microserver-NAS mit 12 TB
  • einem Backup-DAS mit 12 TB
  • einem Gigabit Ethernet/10G-Switch als zentrale Netzwerkkomponente
  • einer APU.1D-Appliance basierend auf IPFire zur Netzseparation
  • einer FRITZ!Box meines Internet-Anbieters
  • einer APC Smart-UPS 750 USV zur Verhinderung von Datenverlust durch Stromausfälle
  • und verschiedenen NETIOs zur Steuerung des Stromverbrauchs

Doch wozu das Ganze? Anbei ein paar Erklärungen und typische Fragen, die sich vielleicht dadurch ergeben.

vSphere Cluster

Rack meines Homelabs, 2017

Rack meines Homelabs, 2017

Herz meines Homelabs stellt ein vSphere Cluster, bestehend aus zwei ESXi-Hosts, dar. Auf diesem betreibe ich sämtliche Workloads.

Die ESXi-Hosts verfügen derzeit über jeweils:

  • eine Intel Xeon D-1518 CPU (8×2.2 GHz, 8M Cache, 35W TDP)
  • 128 GB ECC DDR4 Arbeitsspeicher
  • 250 GB vSAN Cache-Layer (NVMe)
  • 480 GB vSAN Capacity-Layer (SATA)
  • 10G-Interconnect für vMotion und NFS bzw. iSCSI

Nähere Details zu der Hardware gibt es im entsprechenden Artikel.

Hauptsächlich dient mir dieser Cluster zum Erlernen und Evaluieren von verschiedenen Tools und Produkten, u.a.:

Software-Stacks des Homelabs

Software-Stacks des Homelabs

  • Betriebsysteme
    • CentOS / Red Hat Enterprise Linux
    • SUSE Linux Enterprise
    • VMware Photon OS / Docker
  • Management-/Infrastruktur-Tools
    • Red Hat Satellite / Foreman / Katello
    • Red Hat Identity Management / FreeIPA
    • OMD / Icinga / Icinga2 / Grafana
  • Entwicklungstools
    • GitLab / GitLab CI
  • VMware-Produkte
    • vSphere
    • vCenter Server Appliance
    • vRealize Suite
    • NSX
Warum besuchst Du nicht einfach Schulungen oder nutzt Online Training-Labs?

Tue ich! Aber ich habe in den letzten Jahren auch gemerkt, dass mein Lernerfolg größer ist, wenn ich die Tools, die ich erlerne, auch selbst nutze. 🙂

NAS & DAS

HP ProLiant MicroServer Gen8

HP ProLiant MicroServer Gen8

Als zentraler Speicher für Benutzerdaten und virtuelle Maschinen dient mir ein HP ProLiant MicroServer Gen8 mit folgenden Eckdaten:

  • Intel Xeon E3-1220Lv2 Prozessor (4×2.3 GHz, 3M Cache, 17W TDP)
  • 16 GB ECC DDR3 Arbeitsspeicher
  • 4×4 TB Enterprise SATA-Festplatten (HGST Ultrastar 7K6000) im RAID-5 Verbund
  • 10G-Anbindung für den vSphere-Cluster

Standardmäßig verfügt der Server über eine Intel Celeron G1610T CPU (2×2.3 GHz, 1M Cache, 35W TDP) – diese verfügt aber leider nicht über die Intel AES New Instructions (AES-NI) Erweiterung, welche für hardwarebeschleunigtes Ver-/Entschlüsseln benötigt wird. Dieses benötige ich in meinem Setup zum Schutz meiner vertraulichen Daten via LUKS (Linux Unified Key Setup). Da der MicroServer Gen8 schon einige Jahre alt ist, ist es nicht sehr einfach, noch passende CPUs mit dieser Funktionalität für den angestaubten Sockel 1155 zu finden. Meine Wahl fiel letztendlich auf den Xeon E3-1220Lv2, da dieser ein perfektes Verhältnis zwischen Leistung und Effizienz bietet.

NAS-Netzwerke

NAS-Netzwerke

Der Datenaustausch zwischen den Clients erfolgt über Samba, der vSphere-Cluster nutzt NFS bzw. iSCSI über ein dediziertes 10G-Netzwerk. Dieses ist notwendig, um den IO-Anforderungen der VMs gerecht zu werden – ein konventionelles Gigabit Ethernet-Netzwerk reicht hier nicht aus. Übertragungen von verschlüsselten Daten sind dank der CPU mit dem Maximum des 1G-Netzwerks von ca. 125 MB/s möglich. Datenübertragungen zwischen dem NAS und dem vSphere-Cluster innerhalb des 10G-Netzwerks erreichen Geschwindigkeiten um die 800 MB/s:

vMotion via 10G

Einige Gedanken zum Festplattenkauf habe ich in einem Artikel dokumentiert.

Als Betriebssystem kommt auf dem NAS CentOS 7 zum Einsatz, welches ich auch für alle anderen Linux-Workloads im Homelab einsetze. Über ein DAS (Lian-Li EX-503) mit ebenfalls 12 TB im RAID-5 Verbund werden die Daten wöchentlich gesichert. Eine Offsite-Sicherung über eine externe Festplatte erfolgt in sporadischen Abständen.

Wer zur Hölle braucht 12 TB Speicher? Und spiegelt diesen auch noch?

Ich mag es viele Backups anzulegen – und tonnenweise Bilder und Fotos (beginnend von meiner Kindheit) zu speichern. Ich lösche nicht so gerne. 🙂

Netzwerk

Switching

Als ich angefangen habe, mich mit VMware vSAN zu beschäftigen, stellte sich schnell heraus, dass das Netzwerk einen limitierenden Faktor darstellte. Zu diesem Zeitpunkt besaß ich noch einen Cisco SG300-Switch, mit welchem ich sehr zufrieden war. Allerdings ergaben meine Recherchen, dass das nächstgrößere Modell mit 4 SFP+-Ports (ein gebrauchter SG500-28X) das geplante Budget bei weitem überschritt. Daher fiel die Wahl schlussendlich auf einen D-Link DGS-1510-28X, welcher vergleichbare Ergebnisse liefert, aber bedeutend weniger kostet (weitere Details finden sich im oben verlinkten Artikel).

Warum keine Verbindung der beiden vSphere-Knoten via SFP+ Direct Attach Copper Cable (DAC)?

Primärspeicher meines vSphere-Cluster ist vSAN, das ich mir regelmäßig mit Experimenten zerschieße. Daher benötige ich einen Fallback-Speicher: NFS über 10G – das erfordert einen dritten Teilnehmer im dedizierten Netzwerk. Außerdem wollte ich mir die Option eines dritten vSphere-Knotens freihalten.

Routing

AX206-Display mit lcd4linux

AX206-Display mit lcd4linux

Seit ich Homelabs pflege, setze ich IPCop bzw. IPFire ein. Nachdem ich lange Jahre auf eine ALIX.2D13-Appliance mit IPCop 1.x/2.x gesetzt habe, war 2016 neue Hardware fällig. Hier fiel die Wahl auf eine APU.1D-Appliance, die mit IPFire betankt wurde.

Meine Appliance übernimmt die folgenden Netzwerkfunktionen:

  • Kapseln einer DMZ für öffentliche Workloads
  • Remote-Einwahl via OpenVPN
  • WLAN-Accesspoint
  • Anzeigen eines Dashboards über aktuelle Netzwerk-Events via USB
Warum dafür dedizierte Hardware kaufen? Neue FRITZ!Box-Geräte unterstützen auch DMZ-Konstrukte.

Das mag sein, aber ich habe gerne ein vollwertiges Linux-System, auf dem ich selbst die Stellschrauben ändern kann, ohne, dass hierdurch direkt die Garantie erlischt. Außerdem kann ich für IPFire selbst Erweiterungen erstellen – für eine FRITZ!Box nicht. 😉

Netzwerk-Übersicht

Netzwerk-Übersicht

Von meinem DSL-Anbieter habe ich eine FRITZ!Box erhalten, an die lediglich der IPFire angeschlossen ist und externen Zugriff über einige Ports erhält.

Facility

Sämtliche Server und Appliances finden in einem mehr oder weniger halbwegs geordneten Server-Rack ihren Platz. Um Datenverlusten bei Stromausfällen entgegen zu wirken, setze ich eine kleine APC Smart-UPS 750 USV ein. Diese versorgt die angeschlossenen Gerätschaften bis zu 20 Minuten mit Strom – was genügt, um alles kontrolliert herunterzufahren.

Gelegentlich benutzte Geräte sind an über das Netzwerk fernsteuerbare Steckdosenleisten angeschlossen – so können diese auch von Fern ausgeschaltet werden, um Strom zu sparen. Hier setze ich auf die Produkte NETIO 230A und 230B des tschechischen Herstellers Koukaam. Zugegebenermaßen sind diese Geräte schon etwas angestaubt – aber sie erfüllen ihren Zweck und ich habe mit einem Nagios-/Icinga-Plugin und einer experimentellen Android App einige Zeit investiert, die mich aus persönlichen Gründen noch einige Zeit an diese Produkt binden. 😉

Grafana Facility-Dashboard

Grafana Facility-Dashboard

Braucht man privat wirklich eine USV?

Das ist natürlich vor allem davon abhängig, wo man wohnt, bzw. wie gut der örtliche Stromversorger seinen Job macht. Ich war schon ein paar Mal sehr froh darüber, sie zu besitzen. 🙂

Ausblick

Das geht schneller...

Das geht schneller…

Ein Homelab ist natürlich eine lebende Infrastruktur – in den letzten Jahren habe ich meine Hosts regelmäßig erweitert und ersetzt. Spontan fallen mir einige Dinge ein, die man noch optimieren könnte:

  • größere und schnellere (SAS statt SATA) Capacity-SSDs für den vSphere-Cluster
  • ein dritter vSphere-Knoten, falls Ressourcen erschöpft sind
  • Implementation von vSphere Replication zur Sicherung der kritischen VMs auf einem Standalone ESXi-Host
  • Netzwerkvirtualisierung mittels NSX
  • SSD-Caching auf dem NAS

Die Liste ließe sich beliebig weiterführen – es gibt viel Optimierungspotential. Es bleibt also spannend.. 😉

2 Kommentare Schreibe einen Kommentar

  1. Hallo Christian,

    ein sehr ausführlicher und interessanter Artikel. Weiter so! Ich habe Dich gerade bei Xing gesucht und gefunden.
    Aktuell bin ich auch dabei ein Homelab mit OpenStack 12 aufzubauen.

Schreibe einen Kommentar