Ausgangslage

Ich bin Informatiker und IT ist meine Leidenschaft – beruflich und privat. Darum werkelt in meinem „Homelab“ kein einzelner Server mehr, sondern ein Proxmox Cluster mit 3 Knoten. Dieser stellt virtuelle Maschinen und Linux Container (LXC) für Home-Assistant, Nextcloud und andere Anwendungen zur Verfügung.

Zwei der Server (ernie & bert) wurden mit einem „Konvolut“ aus vorhandener Hardware realisiert (ASUS Prime A320I-K Mini-ITX Mainboard mit AMD Ryzen 3 3200G APU), der dritte (grobi) verwendet ein ASUS Prime N100I-D D4 Mainboard mit Intel N100 CPU on-board.

Alle Rechner verwenden ein 19“ 1,5HE Gehäuse mit Netzteil von Inter-Tech. Als Boot-Medium kommt eine NVMe SSD zum Einsatz, die Nutzdaten liegen in einem ZFS-Mirror mit 4 TB Kapazität.

Zielsetzung

Für das Upgrade wurde der Fokus nun auf folgende Punkte gesetzt:

• moderater Zuwachs an Leistung
• stabiler oder sinkender Energiebdarf
• hohe Weiterverwendung vorhandener Komponenten
• angemessener Preis

Bzgl. des angestrebten Preis- / Leistungsverhältnisses sei erwähnt, dass es sich um ein Hobby-Projekt handelt und aktuell keine Enterprise-Hardware zum Einsatz kommt. Kein Server-Mainboard, kein ECC-RAM, keine Enterprise SSD oder HDD.

Neues Mainboard: CWWK CW-TGL-NAS

Nach einiger Recherche wählte ich ein Mainboard des chinesischen Anbieters ChangWang Technology (CWWK) aus, konkret das 11th Generation Core i5-1135G7 Six-Bay NAS Board.

Unverändert keine echte Server-Hardware, aber dennoch ein Upgrade zum IST-Stand, wie folgende Tabelle zeigt:

Die i3-1115G4-Variante kam wegen 2C/4T nicht infrage. Auf die noch potentere i7-1165G7-Version habe ich verzichtet, da mein Setup von einem noch höherem Takt und einer besseren Grafikeinheit (Intel Iris Xe) nicht profitiert.

Das Board in der i5-1135G7-Barebone-Version kostete direkt bei CWWK ca. 244 EUR (271 USD), der Transport aus China dauerte ca. 8 Tage und war lückenlos nachvollziehbar.

Der Versand erfolgt in minimaler Verpackung, auch der Inhalt ist auf das Nötigste reduziert: Board, I/O-Blende und Schrauben. Die Intel CPU ist mit einer massiven Kupferplatte belegt, die später den Kontakt zum Kühlkörper mit Lüfter (s.u.) herstellt.

Speicher, Kühler und weiteres Zubehör für das CW-TGL-NAS

Etwa der gleiche Betrag wie für das eigentliche Mainboard fiel für die notwendigen Komponenten an:

• Noctua NH-L9i „low-profile“ CPU-Kühler (wg. des 1,5 HE Gehäuses)
• 32GB DDR4 3200 SODIMM RAM (Kit)
• SFF8643-zu-SATA-Kabel

Wegen der bizarren Preise auch für DDR4 RAM habe ich (zunächst) auf 64GB „Vollausbau“ verzichtet. Gehäuse und Netzteil, sowie NVMe (Crucial P3) und SATA-HDDs (WD RED) konnten übernommen werden.

Umbau

Der Umbau gestaltete sich äußerst einfach, da die mechanischen Rahmenbedingungen unverändert blieben: Mini-ITX mit ATX-Netzteil.

NVMe-SSD und die SATA-HDDs konnten entsprechend beim Zusammenbau der neuen Mainboards übernommen werden, dann RAM einsetzen und Lüfter montieren – fertig.

Tatsächlich kam es hier zur einzigen Herausforderung mit dem CWWK-Mainboard: Auf einem der insgesamt drei Mainboards war an einem der jeweils zwei M.2 Steckplätze, die Halteschraube dermaßen fest gezogen, dass sie nur mit einer Zange gelöst werden konnte.

Nach dem Ausbau der „alten“ Mainboards und Tausch der I/O-Blende konnte der Einbau des CW-TGL-NAS vorgenommen werden. Auch das Anschließen war problemlos, da alle Pfostenleisten beschriftet und gut zu erreichen sind. Die Belegung des Front-Panel-Headers folgt dem Standard, so dass auch ohne Handbuch Power- und HDD-LED, sowie Power- und Reset-Taster auf Anhieb korrekt angeschlossen wurden.

Zeitaufwand pro Rechner: Ca. 20min.

Inbetriebnahme

Beim allerersten Start des Mainboards (bzw. nach einem CMOS-Reset) dauert es mehrere Sekunden, bis sich das BIOS meldet. Darauf wird seitens CWWK auch hingewiesen.

Glücklicherweise liegt das Video-Signal auch am USB-C-Port des Boards an, so dass ich lediglich Strom und das USB-C-Kabel meines Samsung S27A600UUU anschließen musste.

Welche BIOS-Einstellungen wurden geändert?

Das BIOS des Boards ist unglaublich umfangreich, tatsächlich kann ich mit den wenigsten Einstellungen etwas anfangen. Daher habe ich mich auf folgende Punkte beschränkt:

1. Unter Advanced -> ACPI Settings -> „Enable ACPI Auto-Configuration“ wähle ich [Enabled]
2. unter Chipset wird der automatische Start nach Anlage bzw. Rückkehr von Netzstrom durch Setzen von „State After G3“ auf „[S0 State]“ aktiviert
3. da der diskrete JBM585-Chip für den SAS-Port sich leider weder deaktivieren lässt, noch Stromspar-Modi unterstützt, wird nur er via SFF-8643-Adapter (s.o.) verwendet. Die onboard-SATA-Ports werden unter Chipset -> SATA And RST Configuration -> „SATA Controller(s)“ via „[Disabled]“ deaktiviert
4. die für den Betrieb als „headless“-Server nicht-genutzte Audio-Komponente wurde unter Chipset -> HD Audio Configuration -> „HD Audio“ ebenfalls „[Disabled]“

An dieser Stelle ein kurzer Hinweis bzgl. des Supports durch CWWK: Ich hatte auf Anhieb nicht die Einstellung für den automatischen Start nach Stromausfall gefunden und eine entsprechende Frage über den Chat auf der CWWK-Homepage gestellt. Ca. 6 Stunden später wurde meine Frage beantwortet, mit einem eigens angefertigten Video zur Navigation durch das BIOS zur entsprechenden Option.

Bemerkenswert!

Debian Linux / Proxmox

Ebenso reibungslos wie der Umbau ging die Inbetriebnahme der Server vonstatten. Trotz Wechsel der Plattform (AMD zu Intel) booteten sowohl Proxmox, als auch alle virtuellen Maschinen und LXC ad hoc.

Nur bei grobi war eine Änderung des Netzwerk-Interface-Namens notwendig (enp5s0), bei den anderen Knoten nicht.

Da ich jeweils nur einen Server zu einer Zeit umgebaut habe, blieb der Cluster zu jeder Zeit intakt und es gab keine Service-Unterbrechung.

Fazit

Das Mainboard CW-TGL-NAS von CWWK erfüllt meine Anforderungen vollumfänglich und hat noch Reserven für weitere Upgrades. Es arbeitet zuverlässig und unaufällig unter Proxmox VE 9 bzw. der technischen Basis Debian Linux 13 mit Linux Kernel 7.0.

Nach dem Upgrade aller Knoten bietet nun jeder Knoten eine sparsame 4C/8T APU, sowie – unverändert – 32GB RAM und 8TB HDD Storage (4TB ZFS-Mirror). Dabei hat sich der Energiebedarf des gesamten Racks (mit Modem, Router, PoE-Switches, etc.) von rund 170 Watt auf 165 Watt reduziert.

Die Steigerung der Netzwerk-Interfaces von jeweils 1x GbE auf 4x 2,5 GbE wird für dedizierte Netzwerke für ZFS-Replikation und Cluster-Kommunikation (Corosync) genutzt. Hier kam es zuletzt zu Timeout-Problemen, wenn Zugriffe, Replikation und (externer) Backup gleichzeitig stattfanden.

Der Bestellprozess und die Interaktion mit CWWK waren einwandfrei und schnell. Wer 8-10 Tage warten kann, spart durch die Bestellung beim Hersteller gegenüber bereits importierten Boards auf Amazon oder Ebay circa 60 EUR pro Stück.

Die bisherige Hardware ist unverändert brauchbar und wird seinen Weg zu Ebay finden. Dank der aktuellen, absurden Hardware-Preise komme ich evtl. sogar kostenneutral aus der Sache. Die Versteigerung des Asus N100-Boards hat jedenfalls 50% mehr als der Neupreis(!) aus 2025 ergeben.

Danke, KI!

Der Beitrag CWWK CW-TGL-NAS: Ideales Mainboard für Proxmox im Homelab? erschien zuerst auf dahlen.org.

Corona hat mich erwischt, mit mäßigen Auswirkungen. Und die M2 SSD in meinem Server ist „geplatzt“, mit deutlichen Auswirkungen. Und eine der beiden HDDs im RAID1 sagt ihren nahenden Tod via S.M.A.R.T.-Warnung voraus – zumindest das soll ohne Auswirkungen bleiben.

Eine unwillkommene Gelegenheit also dem RAID 1 zu unverminderter Stabilität (und einer Verdoppelung der Kapazität) durch den Tausch beider Festplatten gegen neue zu verhelfen. Und da dies nicht das erste Mal ist und sicher auch nicht das letzte Mal sein wird, diesmal mit Mitschrift.

Ausgangsituation

Mein Heim-Server verwendet (aktuell) Ubuntu 22.04 Server als Betriebssystem. Die beiden 2,5″ Seagate Barracuda Festplatten sind als /dev/sda und /dev/sdb eingebunden. Sie wurden aus dem inzwischen verkauften ASRock Desk Mini in den neuen 19″-Server übernommen.

Via Linux Software RAID wird ein RAID 1 /dev/md0 über die beiden Platten realisiert. Das ASUS A320I Mainboard unterstützt hot-plug, d.h. die Platten können im laufenden Betrieb abgezogen oder angesteckt werden.

Der Wechsel der Festplatten wird im laufenden Betrieb stattfinden. Ich beuge Datenverlusten durch regelmäßige, ausgelagerte und geprüfte Backups mit Borgmatic vor.

Warnung

Die im folgenden beschriebenen Schritte sind auf meine Hard- und Software-Konstellation ausgerichtet und haben dort fehlerfrei funktioniert. Dennoch kann selbst bei korrekter Ausführung das Risiko des Datenverlusts niemals ganz ausgeschlossen werden.

Das Nachvollziehen der hier beschriebenen Schritte geschieht auf eigene Gefahr!

Festplatte aus RAID entfernen

Zunächst gilt es eine der beiden Festplatten zu entfernen (hier: /dev/sda). Da diese vom RAID aktuell verwendet wird, muss sie zunächst als fehlerhaft markiert werden (es sei denn, sie ist es bereits):

$ sudo mdadm --manage /dev/md0 --fail /dev/sda

Im nächsten Schritt wird die fehlerhafte bzw. als fehlerhaft markierte Festplatte aus dem RAID entfernt:

$ sudo mdadm --manage /dev/md0 --remove /dev/sda

Um das Entfernen der Platte vorzubereiten und die Identifizierung zu erleichtern, wird als nächstes die Platte in den Sleep-Modus geschickt. Bei SSDs ist dieser Schritt natürlich nicht notwendig:

$ sudo hdparm -Y /dev/sda

Und schließlich (aus reiner Vorsicht) melden wir die Platte noch im Kernel ab. Damit sollte das Entfernen nun sicher sein:

$ echo 1 | sudo tee /sys/block/sda/device/delete

Nun steht der physikalische Tausch der Platten an, den ich an dieser Stelle natürlich nicht im Detail beschreiben möchte. Ist die neue Platte eingebaut und wieder online, beginnt man mit der Anmeldung am RAID.

Festplatte in RAID aufnehmen

Da die neue Platte (3,5″ 4TB WD RED Plus) fabrikfrisch und ohne Initialisierung daherkam, musste zunächst eine Partitionstabelle angelegt werden, auch wenn die gesamte Platte ohne dedizierte Partitionen verwendet wird:

$ sudo cfdisk -z /dev/sda

Ist auch dies geschehen, kann die Platte – wie gesagt, als Ganzes – am RAID angemeldet werden:

$ sudo mdadm --manage /dev/md0 --add /dev/sda

Die Linux RAID-Software beginnt nun mit der Synchronisierung der 2. Platte, d.h. im Wesentlichen werden die Informationen der verbliebenen „alten“ Platte (/dev/sdb) auf die neue (/dev/sda) übertragen.

Das nimmt einige Zeit in Anspruch und während dieser Zeit ist das RAID recht „empfindlich“, da bis zum Abschluß der Synchronisierung logisch nur eine Platte für das RAID zur Verfügung steht. Bei höheren RAID-Leveln (5,6) sieht das natürlich anders aus und bei RAID 0 ist mit dem Ausfall einer Platte eh „Schicht im Schacht“.

Über den Fortschritt der Synchronisierung kann (und muß) man sich immer wieder informieren. Ein Tausch der verbliebenen, „alten“ Platte /dev/sdb ist erst nach vollständiger Synchronisierung möglich und erfolgt dann analog zu den obigen Schritten.

Der Möglichkeiten zur Analyse lauten:

$ sudo mdadm --detail /dev/md0

bzw.

$ cat /proc/mdstat

Die Ausgaben zum ersten Befehl ist umfangreich, aber eher zusammenfassend, der relevante Wert befindet sich in „Rebuild Status“:

/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
     Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent
     Intent Bitmap : Internal
       Update Time : Wed Nov 30 19:10:58 2022
             State : active, degraded, recovering
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 1
Consistency Policy : bitmap
    Rebuild Status : 32% complete
              Name : example:0  (local to host example)
              UUID : a3738222:357f6cb8:b4014413:62be2f37
            Events : 109210
    Number   Major   Minor   RaidDevice State
       2       8       16        0      active sync   /dev/sdb
       3       8        0        1      spare rebuilding   /dev/sda

Der zweite Befehl führt zu einer kürzeren, aber detaillierteren Anzeige. Die Ausgabe sollte der folgenden ähneln, natürlich mit unterschiedlichen (und bei mehrfachem Aufruf ansteigenden) Angaben zum Fortschritt:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb[2] sda[1]
      1953382464 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (5148736/1953382464) finish=398.8min speed=81402K/sec
      bitmap: 5/15 pages [20KB], 65536KB chunk
unused devices: <none>

Nun heißt es Geduld zu haben, bis das Recovery abgeschlossen ist und der Wechsel der verbleibenen Platte nach dem gleichen Muster vollzogen werden kann.

RAID und Filesystem vergrößern

In meinem Falle wurden 2x2TB Platten gegen 2x4TB Platten getauscht. Entsprechend vergrößerte sich der für RAID1 zur Verfügung stehende Platz von 2TB auf 4TB. Dieses Mehr an Platz wird aber nicht automatisch genutzt. Fragt man den genutzten Speicher mittels mdadm ab, so werden nur 2TB berichtet.

$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 1953382464 (1862.89 GiB 2000.26 GB)

Der folgende Befehl dehnt das RAID nun auf den gesamten, zur Verfügung stehenden Platz aus:

$ sudo mdadm --grow /dev/md0 --size max

Ein erneuter Aufruf von mdadm bestätigt die neue Größe:

$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Fri Apr  1 17:19:01 2022
        Raid Level : raid1
        Array Size : 3906886488 (3.64 TiB 4.00 TB)
[...]

Nur – so wie das RAID nicht unmittelbar den gesamten, verfügbaren Platz auf den Datenträgern verwendet hat, so nutzt auch das Filesystem auf dem RAID nicht ohne weiteren Eingriff den verfügbaren Platz, wie mittels df festgestellt werden kann:

$ df -h /srv
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        1.8T  271G  1.5T  16% /srv

Aber auch das lässt sich beheben, mit dem entsprechenden Werkzeug des Filesystems. Da ich ext4 verwende, ist resize2fs das Mittel der Wahl:

$ sudo resize2fs /dev/md0
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/md0 is mounted on /srv; on-line resizing required
old_desc_blocks = 233, new_desc_blocks = 466
The filesystem on /dev/md0 is now 976721622 (4k) blocks long.

Nochmal das Ergebnis mit df prüfen und fertig:

$ df -h /srv
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        3.6T  271G  3.2T   8% /srv

Postskriptum

Im Nachhinein hat sich herausgestellt, dass der nahende Tod der installierten 2,5″ 2TB Seagate Barracuda-Platten ein Fehlalarm war, verursacht durch die tatsächlich endgültig zerstörte WD Green. Auf letzterer war leider das Betriebssystem installiert (non-raid). Fairerweise sei darauf hingewiesen, dass die WD Green Serie ausdrücklich nicht auf Dauerbetrieb ausgelegt ist. Grundsätzlich setze ich gerne auf Western Digitial und so wird als Ersatz in Kürze eine WD Red SA500 eingebaut.

Nach dem Ersetzen der SSD, dem Neuaufsetzen des OS und dem Einspielen des Backups waren auch die S.M.A.R.T.-Werte der „alten“ Platten wieder einwandfrei. Aber die Neuen waren halt schon geliefert, was will man machen …

Der Beitrag Linux Software RAID – Festplatte(n) tauschen erschien zuerst auf dahlen.org.