Storage-Cluster - der Plan

Wer regelmäßig mit Virtualisierung, Containern und Selfhosting arbeitet, kennt das Problem: der Storage wächst einem über den Kopf. Auch bei mir sind die bisherigen Nodes inzwischen so stark ausgelastet, dass für größere Storage-Aufgaben schlicht kein Platz mehr ist. Zeit also für den nächsten Ausbauschritt in meinem Homelab – ein (weitestgehend) dedizierter, energieeffizienter und möglichst robuster Storage-Cluster.

Das Ziel

Wie auch in größeren IT-Projekten üblich, beginnt alles mit der Zielsetzung bzw. der Erfassung der Anforderungen.

Ich brauche einerseits Storage, der schnell ist und den Ausfall einer von drei geplanten Nodes verkraftet, andererseits Massenspeicher für z.B. Medien, LXC-Templates, ISOs und co, der nicht hochverfügbar sein muss und auch nicht die selben Geschwindigkeiten erreichen muss. Auf dem schnellen Speicher sollen wichtige VMs/LXCs liegen (bspw. DNS und HomeAssistant), daneben soll dieser Bereich auch als Speicher für Docker Swarm dienen.

Am liebsten hätte ich hier natürlich vollständige Hochverfügbarkeit, also keinen einzelnen Single-Point-of-Failure (redundantes Netzwerk, redundante Stromversorgung, …). Das ist für Zuhause aber einerseits overkill und andererseits weder finanziell noch energetisch sinnvoll. Daher möchte ich eine möglichst gute Verfügbarkeit erreichen, ohne dabei komplett in den Enterprise-Bereich vorzudringen.

Die bisherigen Nodes sind mit ihren eigentlichen Aufgaben zu stark ausgelastet, um hier sinnvoll auch noch Storage machen zu können. Das ist so gerade zwar im Einsatz, ich merke allerdings, dass ich mich damit zu nahe an der Grenze bewege.

Der Plan

Ich habe über die letzten Wochen einen Plan erarbeitet, PoCs aufgesetzt und vieles ausprobiert. Bisher ist der Cluster noch nicht aufgebaut, aber ich denke, dass ich mit der Auswahl an Hardware und Software mein Ziel erreiche.

Hardware. Natürlich Thin-Clients

Die Hardwarebasis bilden drei Fujitsu Futro S740 Thin Clients. Dass ich die Dinger mag, ist bekannt. Die Wahl fiel auf dieses Modell, da es günstig ist, sehr energieeffizient läuft und genügend Erweiterungsmöglichkeiten bietet. Der Plan ist hierbei, in der ersten Ausbaustufe den WiFi-Slot für einen SATA-Controller zu nutzen. Später soll der SATA-Controller dann in den SSD-Slot (der laut Internet neben SATA auch PCIe-Anbindung hat) wandern und der WiFi-Slot für eine 2,5 GBit/s Netzwerkkarte genutzt werden.

Geplanter Ausbau pro Node:

• 4 GB RAM
• 1x 16/32GB für das OS (meistens dabei)
• 1× 480 GB SSD (für Ceph)
• 1× 1 TB HDD (für SaunaFS oder Alternativen)
• SATA-Controller über den WiFi-Slot (Adapterlösung)
• Später Upgrade auf 2,5 Gbit/s LAN

Das Netzwerk wird anfangs über meine bestehende 1 GBit/s-Infrastruktur gelöst, später ist hier ein zusätzlicher 2,5 GBit/s Switch geplant. Ich rechne ohne Datenträger mit Kosten von ca 75 € pro Knoten, was ich für nicht viel halte. Ohne Datenträger bekomme ich damit für etwas über 200 € einen weitestgehend redundanten Storage-Cluster.

Software

Für den Storage-Cluster sollen zwei Software-Lösungen zum Einsatz kommen. Ceph wird für den schnellen Speicher genutzt, der Massenspeicher wird nach aktuellem Stand auf SaunaFS aufbauen. Ceph habe ich ausgesucht, da es von Proxmox nativ unterstützt wird und dort sogar gut integriert ist. Neben Blockspeicher kann ich dort über CephFS auch Freigaben auf Dateiebene erzeugen, was ich für Docker Swarm benötige. Es ist zudem performant und im Enterprise-Bereich stark vertreten. Für den langsameren Speicher habe ich lange überlegt, was ich nutzen möchte. Erst hatte ich GlusterFS vorgesehen. Mittlerweile habe ich mich hier aber umentschieden und möchte SaunaFS einsetzen. Das ist ein Fork von LizardFS, was wiederum ein Fork von MooseFS ist. Es ist für verteilten Massenspeicher ausgelegt, hat eher wenig Overhead und bietet sogar die Option, die Anzahl der Replikas pro Ordner festzulegen.

Auf jedem der Futros wird dementsprechend Proxmox VE installiert und die Nodes in den bisherigen Cluster eingefügt. Die SSDs werden als OSDs für Ceph genutzt, die zusätzlichen Datenträger dann als Mountpoints an einen LXC pro Node angebunden. Dort wird dann SaunaFS installiert. SaunaFS kann ich aufgrund der Voraussetzung von Ubuntu als OS leider nicht direkt auf den Knoten installieren, die Variante mit SaunaFS habe ich jetzt aber auch schon eine Weile im Haupt-Cluster im Testbetrieb erfolgreich genutzt.

Das SaunaFS-Volume wird dann von einem Knoten via Samba und NFS freigegeben. Das hat den Hintergrund, dass es mit vielen Dingen kompatibel ist und sich so z.B. auch in Proxmox als Speicher für Templates und ISOs gut einbinden lässt.

Weitere Ideen und mögliche Dienste

Wenn die Performance passt, sollen auf dem Storage-Cluster später auch leichte Dienste laufen und damit die bestehenden Nodes etwas entlastet werden. Kandidaten dafür sind Dinge wie der Proxmox Backup Server oder auch Komponenten von meinem Monitoring-Stack.

Ob das mit 4 GB RAM pro Node praktikabel ist, wird sich erst zeigen - mehr RAM kaufen ist aber aufgrund der Lage am Markt gerade keine Option.

Nächste Schritte

Ich habe Hardware bestellt, um einen Futro mal mit einem SATA-Controller auszustatten und damit schonmal als Storage (ohne Ceph oder Replikation oder so) einzusetzen. Das dient als erster Test. Wenn das so funktioniert, wie ich mir das vorstelle, werden weitere Futro S740er gekauft und der Cluster aufgebaut.

Ich nehme dafür den Futro, den ich eigentlich für den 3D-Drucker gekauft hatte. Dort kommt einfach wieder der S520 hin. Das bietet sich an, da ich für den 3D-Drucker wenig Leistung brauche, der Futro S520 eh nichts zu tun hat und ich so gut etwas Geld sparen kann.