Netgear ReadyNAS-OS auf normaler PC-Hardware

Am Von In Allgemein

Netgear verkauft seit Ende des Jahres 2021 keine NAS-Systeme mehr.
Das ist schade, da ich mit meinem ReadyNAS RN204 sehr zufrieden war und bin. Seit 2015 tuckert es völlig unauffällig als allnächtliches Backup-Ziel vor sich hin.
Die Weboberfläche ist funktional und übersichtlich, darunter werkelt btrfs samt Snapshots, Quotas und Kompression auf einem mdadm-Raid. Es werden alle gebräuchlichen Protokolle unterstützt, fancy Gimmicks gibt’s (zum Glück) keine.
ReadyNAS-OS basiert auf Debian 8(!), das jedoch von Netgear großflächig aktualisiert wurde und – Stand Februar 2024 – weiterhin wird. Außerdem hat man hat root-Zugang und kann Debian-Pakete installieren.

Zum Glück läuft ReadyNAS-OS auch auf echter, normaler PC-Hardware:

Netgear bietet ReadyNAS-OS zur Installation in VirtualBox an (https://github.com/ReadyNAS/sdk/wiki/Setup-ReadyNAS-OS-on-VirtualBox). Gedacht ist das für Entwickler, die Apps für ReadyNAS-OS entwickeln wollen. Das System ist bis auf’s letzte Bit komplett identisch zum ReadyNAS-OS auf den echten NAS-Geräten – und wird deswegen ebenso mit Updates versorgt.

Wer’s nachprüfen will: Die normalen Firmwareupdates von Netgear sind TAR-Archive mit einem 16384 Byte langen Header, den man vor dem Entpacken entfernen muss. Nach dem Entpacken erhält man das Root-Dateisystem (wieder als tar-Archiv), die initrd und den Kernel. Das VirtualBox-VMDK-Image enthält die identischen Dateien wie ein Firmwareupdate mit der selben Versionsnummer, nur zusätzlich noch einen Syslinux-Bootloader.

Unterstützte Hardware

Die Hardwareunterstützung von ReadyNAS-OS ist etwas eingeschränkt. Der Kernel bringt folgende Treiber mit für Netzwerk und SATA/SAS:

== NIC: ==
kernel/drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko
kernel/drivers/net/ethernet/intel/e1000/e1000.ko
kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
kernel/drivers/net/ethernet/intel/i40e/i40e.ko
kernel/drivers/net/ethernet/intel/igb/igb.ko
kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
kernel/drivers/net/ethernet/marvell/sk98lin/sk98lin.ko
== NIC USB: ==
kernel/drivers/net/usb/asix.ko
kernel/drivers/net/usb/ax88179_178a.ko 
kernel/drivers/net/usb/lan78xx.ko
kernel/drivers/net/usb/pegasus.ko 
kernel/drivers/net/usb/r8152.ko
kernel/drivers/net/usb/rtl8150.ko
== SATA/SAS: ==
kernel/drivers/ata/libata.ko
kernel/drivers/ata/ahci.ko
kernel/drivers/ata/libahci.ko
kernel/drivers/ata/sata_sil24.ko
kernel/drivers/scsi/mpt3sas/mpt3sas.ko

Im Wesentlichen werden also Intel-Netzwerkchips von 1 GBit/s bis 10 GBit/s unterstützt, sowie Broadcom NetXtreme- und Marvell-Chips. Ebenso funktionieren USB-Netzwerkadapter mit Chips von ASIX, Microchip, und von Realtek mit RTL8150 und RTL8152/RTL8153. Wer ReadyNAS-OS in einer VM betreiben möchte, wird sich über Unterstützung für die VirtIO-„Netzwerkkarte“ freuen.

Wer will kann zusätzlich einen USB-WLAN-Stick anstöpseln. ReadyNAS-OS unterstützt jedoch ausschließlich 802.11n-WLAN-Sticks mit den Chipsätzen Realtek RTL8188CU, RTL8188CUS und RTL8192CU. Eine Liste mit passenden USB-WLAN-Sticks gibt’s bei WikiDevi.

Für SATA/SAS funktionieren praktisch alle Chips (bis auf historische ohne AHCI), plus die älteren Silicon Image 3124, 3132 und 3531, sowie die im Firmenumfeld beliebten Broadcom/LSI SAS-Controller, die seit Jahren unter diversen Marken vertrieben werden.

Außerdem muss der Rechner im BIOS-Modus booten können. UEFI wird nicht unterstützt.

Installation

Bootmedium vorbereiten

Zum Booten kann entweder eine SD/CF/??-Karte in einem USB-Kartenleser benutzt werden, oder ein USB-Stick.

Zuerst von Netgear das VMDK-Disk-Image herunterladen und in’s RAW-Format konvertieren:
qemu-img convert -f vmdk -O raw ReadyNASOS-6.6.0-x86_64.vmdk ReadyNASOS-6.6.0-x86_64.img

Anschließend ReadyNASOS-6.6.0-x86_64.img als Image auf den USB-Stick oder die Speicherkarte schreiben:
dd if=ReadyNASOS-6.6.0-x86_64.img of=/dev/sdX (Das „X“ anpassen je nachdem welches Device USB-Stick/Speicherkarte eben hat)

Falls ein USB-Stick benutzt wird muss dieser noch bootfähig gemacht werden – bei Speicherkarte-in-USB-Kartenleser ist das nicht nötig:

  1. syslinux -i /dev/sdX1
  2. dd conv=notrunc bs=440 count=1 if=/usr/lib/SYSLINUX/mbr.bin of=/dev/sdX

Booten

Dann vom USB-Stick (oder Speicherkarte) im BIOS-Modus booten.

Keine Panik: Der Bildschirm bleibt schwarz, es gibt keinerlei Ausgaben – das passt schon so! Gelegentlich blinkt das Festplattenlämpchen und die Platten klackern, aber das war’s dann auch. Bei echten Netgear-NAS-Geräten würde der Fortschritt des Startvorgangs in dem kleinen LC-Display angezeigt werden. Wer neugierig ist kann die Bootmeldungen per serieller Konsole auf ttyS0 mitverfolgen.

Nach ein paar Minuten Warten ist ReadyNAS-OS über die Weboberfläche zu erreichen (Benutzername: admin Password: password) und kann ganz normal eingerichtet werden. Um die IP-Adresse herauszufinden einfach in der Fritzbox oder den Logs des DHCP-Servers nachschauen, je nachdem was man eben hat.
Noch während des Einrichtens wird ein Update auf die aktuelle ReadyNAS-OS-Version angeboten, das man problemlos durchführen kann.

Der USB-Stick bzw. die Speicherkarte wird auch nach der Installation zum Booten benötigt! Also nicht abstecken.

SATA Hot-Swap und Stromsparen

Der SATA-Standard sieht Hot-Swap vor, d.h. SATA-Platten können im Betrieb getauscht werden. Damit das funktioniert, müssen in manchen BIOSen die SATA-Schnittstellen als „eSATA“ oder „Hot Swap“ eingestellt werden. Ansonsten merkt der Rechner zwar, dass eine Platte entfernt wurde, erkennt eine neu hinzugefügte Platte aber erst nach einem Reboot.

Für den Fall dass der Stromverbrauch noch mit Powertop oder entsprechenden udev-Regeln optimiert werden soll:
Vorsicht beim „SATA link power management“ und für die SATA-Controller vom „Runtime PM“: Wenn hier stromsparende Einstellungen gesetzt werden, funktioniert SATA Hot-Swap nicht mehr und man muss nach einem Plattentausch neu booten. So zumindest die offizielle Dokumentation. Je nach eingesetzter Hardware kann’s trotzdem funktionieren. Bei mir tut’s!
Und: Wer Wert auf zuverlässiges Netzwerk legt und/oder Wake-On-LAN nutzen will, sollte zumindest bei Intel-Netzwerkchips keine Stromsparoptionen bei den Netzwerkchips aktivieren.

Hier meine Stromspar-udev-Regeln (Datei /etc/udev/rules.d/99-strom-sparen.rules):

##### SATA Link Power Management #####
# Bei manchen SATA-Chips kein funktionierendes Hotplug mit "medium_power" oder "min_power"
# Von "min_power" wird heftig abgeraten!
# Bei mir funktioniert Hotplug mit "medium_power"
SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="medium_power"

##### I2C #####
ACTION=="add",SUBSYSTEM=="i2c", TEST=="power/control", ATTR{power/control}="auto"

##### PCI Runtime PM #####
# Vendor- und Device-PCI-IDs werden mit "lspci -nn" angezeigt
## Intel-Netzwerkkarten überspringen, verlieren bei aktiviertem Runtime PM gelegentlich den Link
ACTION=="add",SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x15b7", ATTR{power/control}="on", GOTO="pci_pm_end"
ACTION=="add",SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x1533", ATTR{power/control}="on", GOTO="pci_pm_end"

## SATA-Hotplug geht oft bei aktiviertem Runtime PM nicht - bei mir schon
# Intel Onboard SATA
#ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0xa102", ATTR{power/control}="on", GOTO="pci_pm_end"
# ASMedia PCIe-Karte
#ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b21", ATTR{device}=="0x1166", ATTR{power/control}="on", GOTO="pci_pm_end"

ACTION=="add", SUBSYSTEM=="pci", TEST=="power/control", ATTR{power/control}="auto"
LABEL="pci_pm_end"

##### USB #####
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"

##### Enable power save mode for Intel HDA #####
ACTION=="add", SUBSYSTEM=="module", DEVPATH=="/module/snd_hda_intel", \
   RUN="/bin/sh -c 'cd /sys/module/snd_hda_intel/parameters; echo 1 > power_save; echo Y > power_save_controller'"

Zu viel Zeit sollte man hier nicht investieren: Den einzigen am Strommessgerät sichtbaren Unterschied macht die „SATA Link Power Management“-Regel ganz oben.

Fazit

Funktioniert schnell und stabil. Selbst das zeitgesteuerte Ein- und Ausschalten funktioniert. Topp!

Ich hab’s hier am Laufen auf einem Fujitsu D3346-ATX-Mainboard, einem Xeon E3-1225 v5 und 16 GByte DDR4-ECC-RAM. Irgendein alter Celeron oder Athlon und 2 GByte RAM müssten jedoch auch reichen.
Mein Mainboard hat zwei Intel-1 GBits/s-Netzwerkanschlüsse. Diese können in ReadyNAS-OS per Link Aggregation zusammengeschaltet werden. Da das Mainboard nur sechs SATA-Anschlüsse hat, hab ich noch weitere SATA-Anschlüsse mit einer billigen PCIe-Karte nachgerüstet (ASM1166-Chip, 6 SATA-Ports).
Das Ganze steckt in einem Silverstone SST-CS380 V2-Gehäuse. Das Gehäuse ist sehr windig, hat aber acht praktische Hot-Swap-Einschübe für 3,5″-SATA/SAS-Platten. In den beiden 5 1/4-Zoll-Plätzen lassen sich noch zwei weitere Festplatten unterbringen, so dass in Summe zehn Platten verwendet werden können.

Was nicht funktioniert

Lüfterdrehzahl sowie CPU- und Systemtemperatur werden nicht in der Weboberfläche angezeigt.

Stromverbrauch (mit zehn 4-TByte-Platten)

  • 180 Watt beim Hochfahren der Platten
  • 90 Watt bei Benutzung
  • 68 Watt im Leerlauf
  • 25 Watt im Leerlauf mit Platten im Standby

Vergleichbare NAS-Systeme bewegen sich in ähnlichem Rahmen.

Optimierungen

Desktop-Platten im RAID

Falls es bei einem Sektor Leseprobleme gibt, versuchen Desktop-Platten den störrischen Sektor ziemlich lange einzulesen bevor sie aufgeben. NAS-Platten geben ihre Leseversuche dagegen ziemlich schnell auf – die Daten liegen ja eh für gewöhnlich redundant im RAID. Laut Quelle „Internet“ sind Platten während dieser Leseversuche nicht empfänglich für Kommandos von außen, was dazu führen kann, dass Desktop-Platten als vermeintlich „kaputt“ komplett aus dem RAID geworfen werden anstatt dass nur der eine Sektor als defekt markiert wird.

Bei den meisten Desktop-Platten lässt sich aber einstellen, dass sie sich wie NAS-Platten verhalten sollen und so früher aufgeben. Dazu einfach eine Datei /etc/udev/rules.d/99-hdd-scterc.rules mit diesem Inhalt anlegen und einen Reboot durchführen:

SUBSYSTEM!="block|machinecheck", GOTO="md_timeouts_end" 
ENV{DEVTYPE}!="partition", GOTO="md_timeouts_end" 
IMPORT{program}="/sbin/mdadm --examine --export $devnode" 
ACTION=="add|change", \ 
  ENV{ID_FS_TYPE}=="linux_raid_member", \ 
  ENV{MD_LEVEL}=="raid[1-9]*", \ 
  TEST=="/sys/block/$parent/device/timeout", \ 
  TEST=="/usr/sbin/smartctl", \ 
  PROGRAM!="/bin/sh -c '/usr/sbin/smartctl -l scterc,70,70 /dev/$parent && exit 0 || exit 1'", \ 
  RUN+="/bin/sh -c 'echo 180 > /sys/block/$parent/device/timeout'" 
LABEL="md_timeouts_end"

Netzwerk tot: „Detected Hardware Unit Hang“

Nach ein paar Wochen Laufzeit ging plötzlich das Netzwerk nicht mehr. Im Syslog stand was von „Detected Hardware Unit Hang“. Das Problem scheint mit Intel-Netzwerkchips häufiger aufzutreten. Im Internet finden sich einige Berichte dazu – und auch die Lösung: Die Datei /etc/udev/rules.d/99-disable-offloading.rules mit folgendem Inhalt anlegen und einen Reboot durchführen:

SUBSYSTEM=="net", ACTION=="add", KERNEL=="eth*" \
        RUN+="/sbin/ethtool -K %k tso off gso off"

In der Tat: Das Problem ist auch nach mehren Monaten Uptime nicht mehr aufgetreten.

Borg-Backup

Netgear liefert leider keine aktuelle Version von borg mit. Um hier auf aktuellstem Stand zu sein, einfach von https://github.com/borgbackup/borg/releases borg-linuxold64 herunterladen, nach /usr/local/bin/borg umbenennen und mit chmod +x /usr/local/bin/borg ausführbar machen.

ssh-Update

Ich habe openssh 7.4 aus Debian 9 zurückportiert. Zum Installieren: 

echo "deb [trusted=yes] http://www.geierb.de/debian-packages/readynas/backports/ ./" >> /etc/apt/sources.list

apt-get update

apt-get install openssh-client=1:7.4p1-10+deb9u7~readynas1 openssh-server=1:7.4p1-10+deb9u7~readynas1 openssh-sftp-server=1:7.4p1-10+deb9u7~readynas1