Mit CM3588-projekt — 4-NVMe ARM64 hjemme-NAS på 10 W tomgang

TL;DR — FriendlyElec CM3588 NAS Kit er et RK3588-baseret compute-modul på en carrier-board med fire M.2 NVMe-pladser (PCIe 3.0 x1 hver), 2,5 GbE, 2× HDMI ud, USB 3.0 og en 8-kernet ARMv8-CPU (4× Cortex-A76 + 4× Cortex-A55). Fuldt lastet med fire NVMe-drev går den i tomgang på ca. 10 W, peaker omkring 20 W under tung I/O, og læser/skriver en NVMe på ca. 1 GB/s (bus-grænsen, ikke drevet). Min egen kører Debian på mainline-kernel, med ZFS på root, fire 2 TB NVMe-drev i en raidz2-pool, Samba til LAN-shares og Tailscale til adgang uden for LAN. Den har erstattet en tower-PC med TrueNAS og skåret NAS-strømforbruget med ca. 60 W.

Hvorfor netop dette board

Jeg havde kørt en tower-PC som hjemme-NAS i årevis: en brugt desktop, seks 3,5“-harddiske og en støjende blæser. Det virkede, men den trak 70–80 W tomgang og stod i et skab, der skulle have aktiv udluftning. Harddiskene var højlydte nok til, at jeg havde flyttet dem til det fjerneste hjørne af huset.

Tre ting, jeg ville have af en afløser:

1. Kun NVMe. Roterende harddiske er billigere pr. terabyte, men støjen, vibrationen og varmen er ikke værd for et hjemme-NAS på nogle få terabyte. 4× 2 TB NVMe er rigeligt.
2. ARM, for strømforbrugets skyld. Et x86-board med 4× PCIe-pladser forbundet til NVMe ville trække 30–40 W tomgang. ARM kan klare det på 10.
3. Mainline Linux, ikke en leverandør-fork. Jeg vil have apt-get dist-upgrade til at virke, zfs til at bygge fra DKMS mod en nyere kernel og ingen tre år gammel vendor-BSP.

CM3588 NAS Kit rammer alle tre.

Hardware

• SoC: Rockchip RK3588 (4× Cortex-A76 @ 2,4 GHz + 4× Cortex-A55 @ 1,8 GHz, Mali-G610 GPU, 6 TOPS NPU). ARMv8.2-A.
• RAM: 8 GB LPDDR4X på det modul, jeg købte. 16 GB- og 32 GB-varianter findes.
• Lagring: 64 GB eMMC on-module til OS + 4× M.2 Key-M 2280-pladser, hver PCIe Gen 3 x1 (altså ~1 GB/s pr. plads, ikke x4).
• Netværk: 1× 2,5 GbE (Realtek RTL8125B).
• USB: 2× USB 3.0 Type-A, 1× USB 3.0 Type-C (DisplayPort alt-mode), 1× USB 2.0.
• Video: 2× HDMI ud, 1× HDMI ind (RK3588’s capture-blok).
• Strøm: 12 V barrel-jack. Et 60 W-strømforsyning er mere end nok.

Boardet er lille — ca. 10 × 10 cm — og passivt over SoC’en plus en lille blæser, der blæser hen over NVMe-drevene. Mit står fladt på en hylde uden kabinet.

NVMe-kompatibilitetsadvarsel

Den ene ting, der er værd at vide: CM3588 NAS Kit er ikke kompatibelt med visse WD Blue SN580- og WD Black SN850-drev — linket flapper ved boot. Jeg bruger Samsung 990 EVO og Crucial P3 Plus; begge virker fint. Tjek FriendlyElecs wiki-kompatibilitetsliste før du køber NVMe-drev.

OS og filsystem

Jeg kører Debian 13 (trixie) med mainline-kernel — RK3588-understøttelse er god nok fra 6.8 og frem til headless-brug. FriendlyElecs Debian-image virker ud af boksen, men jeg geninstallerer ovenpå for at få et rent Debian i stedet for deres BSP.

• Root-filsystem: ext4 på eMMC.
• Datapool: zfs raidz2 på tværs af de fire NVMe-drev. Med 4× 2 TB giver raidz2 ~3,5 TB brugbart med to-disks-redundans. Ja, raidz2 på fire drev er konservativt; det betyder også, at et dobbelt-svigt ikke spiser poolen, og på NVMe er rebuilden hurtig nok til, at jeg ikke mister nattesøvn over det.
• ZFS-modul: DKMS mod den kørende kernel. Bygger automatisk ved kernel-opgraderinger. Har virket uden manuel indgriben på tværs af tre kernel-bumps.
• ARC-tuning: Loftet ved 2 GB. Det giver headroom på et 8 GB-system.

Gennemløbet er flaskehals-begrænset af 2,5 GbE til netværks-I/O (~280 MB/s vedholdende), længe før ZFS eller NVMe-drevene kommer på arbejde. Lokale operationer på poolen når omkring 2 GB/s samlet sekventiel læsning.

Tjenester

Bevidst holdt simpelt:

• Samba til SMB-shares til Mac’erne og Windows-boksen på LAN’et.
• rsync + cron til natlige backups fra tre andre maskiner.
• ZFS-snapshots hver time, opbevares en uge. zfs send piper datasættet ugentligt til en offsite B2-bucket via zfs-autobackup + rclone.
• Tailscale til adgang uden for LAN. Ingen port-forwarding, ingen dyndns, ingen VPN-koncentrator. SSH og Samba rider begge på Tailscale-interfacet, når jeg er væk.
• Cockpit til det lejlighedsvise “hvorfor larmer blæseren” dashboard-øjeblik.

Det er alt. Ingen Docker swarm, ingen Kubernetes, ingen dusin sidecar-containere. Boardet har ét job — serve filer på LAN’et og lade mig trække backups offsite — og det gør det i stilhed.

Strøm og støj

• Tomgang (alle fire NVMe opspundne, ingen trafik): ~10 W ved stikkontakten.
• Travlt (NVMe-læsning mætter 2,5 GbE, ZFS-ARC varm): ~18–20 W.
• Peak (scrub af hele poolen, alle kerner varme): ~25 W.

Sammenlignet med den 70–80 W-tower, den afløste, er strøm-ROI’en alene omkring 500 kWh/år, eller cirka 1.500 kr/år ved danske privat-takster. Boardet betalte sig selv tilbage på ca. et år.

Støj: i praksis uhørlig fra mere end en meters afstand. Blæseren er lille, og 80 % af tiden kører den knap nok.

Hvad virkede ikke, eller tog arbejde

• Vendor-kernel. FriendlyElecs leverede kernel er deres fork af 6.1 med RK-specifikke patches. Det virker til deres nøglefærdige NAS-image, men DKMS-ZFS-builds er bøvlede mod den. Skiftet til mainline løste det.
• HDMI-capture. RK3588 har en hardware HDMI-input-blok. I mainline er den stadig eksperimentel. Jeg har en vag brugscase for den (trække signal fra en gammel enhed til arkivering), men har ikke fået det til at virke end-to-end. Parkeret indtil videre.
• NPU. De 6 TOPS NPU er underudnyttet. Mainline har basal RKNPU-understøttelse, men til noget praktisk skal du stadig bruge FriendlyElecs rknn-toolkit2. Ikke et problem for et NAS.

Ofte stillede spørgsmål

Hvorfor ikke x86?

En x86-mini-PC med 4× NVMe er ~2× tomgangsstrømmen og ~2× købsprisen (når du tæller kabinet, PSU og CPU med). Til et hjemme-NAS, hvor arbejdsbyrden er “serve filer” snarere end “kør 40 containere”, vinder ARM.

Hvorfor ikke Raspberry Pi 5?

Pi 5 har én PCIe 2.0 x1-lane eksponeret via en HAT — du kan bolte en NVMe på, men kun én, med loft ved ~500 MB/s. CM3588 har fire lanes ved PCIe 3.0 direkte forbundet. En anden klasse af board.

Hvorfor ikke OpenMediaVault eller TrueNAS?

Begge ville virke. Jeg foretrækker rent Debian + Samba + ZFS, fordi opgraderingsstien for Debian er velkendt for mig, og OMV/TrueNAS er et lag, jeg skulle lære på ny. Det afhænger af dig.

Hvorfor raidz2 på fire drev og ikke mirror + mirror?

Overvejet. mirror + mirror giver hurtigere skriv og lettere udvidelse, men kun 4 TB brugbart fra 4× 2 TB — det samme som raidz2. Med raidz2 kan to vilkårlige drev svigte; med stripede mirrors kan du miste to drev, men kun hvis de er i forskellige mirror-par. På fire drev er kapaciteten identisk, og raidz2 har den stærkere fejltolerance.

Kan den køre Plex / Jellyfin?

Ja, og RK3588’s hardware H.265/VP9/AV1-decode-blok klarer det tunge arbejde. Jellyfin med rkmpp-accelereret decoding håndterer 4K HEVC-transcodes på omkring 3× realtid. Jeg kører ingen af delene på denne boks — min Plex bor et andet sted — men det er realistisk.

Går den i suspend?

Ikke pålideligt. Lad den stå tændt; tomgang er alligevel 10 W.

Hvad med støj og varme om sommeren?

Passivt køleplade plus en lille blæser. I en dansk sommer (20–25 °C i rummet) topper den omkring 55 °C die-temperatur under en ZFS-scrub. Ingen throttling målt.

Dom

Hvis du vil have et lydsvagt, strømbesparende, ren-NVMe-hjemme-NAS med nok PCIe til at betyde noget og er villig til at bruge en aften på Debian + ZFS, er CM3588 NAS Kit den bedste mulighed, jeg har fundet. Det er ikke det billigste — en brugt Optiplex er billigere på forhånd — men på tre års TCO inkl. strøm betaler det sig tydeligt tilbage.

RK3588 i sig selv er en overraskende kapabel SoC til homelab-arbejdsbyrder. Da mainline-kernel-understøttelsen landede, holdt jeg op med at behandle den som “en ARM-kuriositet” og begyndte at behandle den som default-svar på små altid-tændte servere.

To år inde er min blevet genstartet to gange (en gang for en kernel-opgradering, en gang fordi jeg flyttede hylden). Jeg ville købe den igen.