…а также Armbian, OpenMediaVault и все-все-все.

Не сторонник пускать работающее устройство на разборку, но, блин…

Уже весьма давно приобрел “NAS за 10$” – Packard Bell NetStore 3500, о чем когда-то писал еще на Juick. Какое-то время он у меня служил в штатном виде, с каким-то старым HDD на 3.5 дюйма – складывал на него бэкапы, под что даже написал в свое время скрипт (см. внизу). Из программных интерфейсов на NAS’е – только FTP и SMB; пользовался только FTP, как идеологически более верным, да и скорость он подразумевал бОльшую. Правда, скорость эта была даже в таком варианте на уровне 3,5 МБ/сек, но для заливки бэкапов раз в сутки хватало.

Потом был какой-то период, когда этот NAS был отложен на полку. Несколько лет назад достал его обратно и ради фана сделал популярную переделку – поставил туда IDE-SATA-мост и подключил один из свободных 2.5-дюймовых дисков на 1 ТБ:

Попутно сменил DC-разъем на более удобный, ибо родной БП еще задолго до того пустил на что-то более важное. Сюда же при переделке встроил DC-DC 12->5V, а наружу вывел обычный разъем в стиле 5.5×2.1, чтобы можно было запитывать от любого удобного БП на 12В.

Думал, что в итоге все это сподвигнет меня применить бездействующую железку в чем-то полезном, но… NAS снова надолго отправился на полку.

Однако в последнее время сделал себе пометку в TODO-листе – организовать какое-то независимое от основных серверов хранилище, ибо сейчас сохраняемые бэкапы просто пишутся на соседний сервер. Лучше, чем ничего, но все же слишком как-то близко одно к другому. Снова вспомнил про NAS, достал с полки, начал вспоминать, как этим всем пользоваться. Тот иногда вел себя странно, но в целом работал. Попутно вспомнил про написанный скрипт и морально был готов вернуться к этому всему. Все эти дни NAS простоял на комоде в спальне, подключенный к ваттметру, так что можно было пронаблюдать, в каких режимах он сколько потребляет.

А дальше один диалог со знакомым подтолкнул мысли в более правильном направлении. Речь зашла про одноплатники, которые у меня в избытке валялись на соседней от того NAS’а полке – пара Cubieboard-2, пара малинок первого поколения, одна Raspberry Pi Zero. За те дни, что ваттметр NAS’а торчал перед глазами, успел заметить следующее:

• Потребление при остановленном HDD и отключенном сетевом кабеле – 3.7W
• При подключенном – 4.4W
• При раскрученном жестком диске, но без обращения к нему – 5.2W

А дальше вспомнилось, что я когда-то уже мерял потребление Куби-2. 1.12 Вт в режиме простоя. Ок, с подключенной электроникой жесткого диска пусть будет чуть больше. И это двухядерная машина, с полноценным SATA, со 100 Мбит’ной сетью, где можно развернуть все, что угодно и без мороки с FTP и скриптами.

Достал с полки Кубиборду, развернул свежий Armbian, сделал более актуальные тесты. Уже тогда возникла мысль – а чего, собственно, мелочиться? Есть USB, пусть не 3.0, но гигабитная USB-карта, подключенная через USB 2.0 даст явно более высокую скорость, чем набортная. В общем, тесты дальше делал с лежащей без дела USB сетевушкой. Вышло 3.8-3.9W с работающим HDD или 2.7W с остановленным HDD. Т.е., более, чем полуторакратная разница в пользу системы, где полет фантазии ничем не ограничен.

Проверил диск:

root@cubieboard2:~# hdparm --direct -tT /dev/sda

/dev/sda:
Timing O_DIRECT cached reads: 392 MB in 2.00 seconds = 195.55 MB/sec
Timing O_DIRECT disk reads: 320 MB in 3.00 seconds = 106.53 MB/sec

Проверил скорость сети:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 392 MBytes 329 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 391 MBytes 327 Mbits/sec receiver

40 МБайт/секунду. Разница на порядок с теми 3,5 МБ/с через неудобный FTP.

Да, для истории: тред на Харьков форум, а оттуда, как выяснилось, NAS – копия некоего Vantec NexStar LX. И таки да, сходство заметно:

Так или иначе, электронике Packard Bell’а пора на покой… А чтобы не пропадать зря корпусу – решил попробовать разместить там Кубиборду со всей обвязкой для решения исходной задачи.

Попробовал разные варианты, но в итоге получалось  удобно использовать только старое расположение HDD. DC-разъем оставался тот же. USB-сетевушку разобрал, она вполне неплохо вписывалась на место старого разъема. Однако в дальнейшем решил использовать ее в штатном корпусе, только чуть подпилить его – получалось больше точек для крепления и какая-никакая защита:

Кубиборду оставалось крепить только на свободном месте. В ход пошли 6-гранники и термосиликон. Много силикона. Высоту стоек подобрал так, что, с одной стороны, плата была чуть-чуть выше, чем жесткий диск, а с другой – разъемы были ниже уровня верхней крышки. Уместился впритык.

Чтобы сохранить кнопку включения на ее родном месте – выпилил болгаркой кусок оригинальной платы NAS’а. Да, теперь уже NetStore 3500 ушел безвозвратно.

Сетевушка вмещалась аккурат рядом с основной платой. В итоге не пришлось городить никаких переходников, она как раньше вставляется в USB-порт. Второй порт остается свободен. Вышло как-то так:

На проц прилепил на термопроводящий клей старый радиатор – для надежности. Стабилизатор в БП остался тот же, на базе KIS 3R33, перестроенный под 5В. Светодиоды на передней панели получилось использовать все! Общий провод светодиодов  (оранжевый) садится на +3,3В на плате (использовал точку на одном из светодиодов), зеленый (на желтом проводе) через резистор подключен к общему, а желтый (на зеленом проводе) и красный (на красном) распаяны на набортные светодиоды кубиборды. В итоге функции двух последних можно менять программно!

В качестве ОС использовал свежий срез Armbian’а. Для настройки светодиодов можно использовать следующие команды:

echo activity > /sys/class/leds/cubieboard2\:blue\:usr/trigger
echo disk-activity > /sys/class/leds/cubieboard2\:green\:usr/trigger

При выключении системы настройка сохраняется в файле /etc/armbian-leds.conf сервисом armbian-led-state.service и восстанавливается при следующей загрузке.

Дополнительно поставил hdparm и добавил в /etc/hdparm.conf следующее:

/dev/sda {
apm = 255
spindown_time = 120
}

Что отключает механизм энергосбережения диска, а также останавливает его через 10 минут неактивности – чего ему крутиться зря, если он нужен будет раз с сутки?

В принципе, на этом можно было бы и остановиться – система вполне бодро работала в том виде, в котором есть; оставалось поставить nfs-kernel-server, немного причесать и пользоваться. Но хотелось сделать уже “красиво” – законченное устройство с веб-интерфейсом.

Помню, что когда-то читал про дистр, заточенный для создания NAS’а и вроде даже на Debian. Нагуглил – OpenMediaVault. На скринах все выглядело более чем хорошо, пошел изучать. Основным предлагаемым вариантом было разворачивание подготовленного iso-образа на выделенную флешку, но образы были в основном под amd64 и подобные архитектуры. Был и вариант ручной установки на свою систему – им и воспользовался. Ставится все весьма просто, ругнулось только на ntp, но то мелочи. На последней команде – деплое systemd-networkd сеть отвалилась и больше не возвращалась. Пришлось спешно разбираться в том, что же поменялось и как теперь с этим жить. Проблемой оказался Netplan, нашел руководство в сети и кое-как составил свой конфиг. Как оказалось позже, в системе изначально был готовый конфиг для Netplan’а, с которым все работало, но OMV последней командой все удаляет и создает свой, нерабочий конфиг. Но это были цветочки… Дальше начался лютый треш.

Машину перезагрузил, поднял сеть. При загрузке системы сообщения о старте сервисов сначала бегут бодро, но чем ближе к концу загрузки – тем терминал начинает явно подтормаживать. Далее, OMV работает, хотя и весьма неспешно. На некоторые действия веб-интерфейс ощутимо задумывается, при этом в top’e процессы веб-интерфейса что-то активно перемалывают. Дальше – веселее. Смотрю – Самба не включена, но уже запущена. При старте системы активно грузит проц unattended-upgrades. Думаю, повыключаю лишнее, начнет шевелиться побыстрее. Тем более, зачем мне Самба?

При попытке обычного systemctl disable smbd система через время уходила в жесткий ребут. То же самое происходило и при выключении других сервисов. И при вызове armbian-config – который изначально работал.

Пронаблюдал питание, оно в порядке.

Поставил memtester, протестировал 800 МБ памяти. Не вся, но хоть что-то. Все ок.

На проц было сложно грешить, ибо система не перезагружалась при том, что процессы активно насиловали проц и LA рос куда-то в район 20-ки. Проверил в разных режимах – все ок. Но стоило лишь попробовать выключить сервис – фактически, удалить файлик на диске – как шел ребут.

Проверил флешку. Достал другую (попутно заказал себе еще пачку, ибо пришлось брать уже из камер), сделал там копию системы – то же самое.

Ок, ставим все заново, проверяем пошагово. Чистый Armbian – все летает. armbian-config выполняется, сервисы выключаются и т.п. Ставлю OMV – до ребута еще можно управлять сервисами и запускать armbian-config. Да и тормозов нет, ибо еще ничего толком не запущено. После ребута – снова треш.

Плюнул, был готов уже использовать голую систему. Или поставить какой-нибудь webmin. Погуглил, попался на глаза Cockpit. Выглядел интересно, решил попробовать. Оказалось, он есть в меню armbian-config – т.е., поставить все можно было вообще без усилий. Поставил – и таки да, оно. Базовые возможности уже можно было выполнить через веб-интерфейс. Шевелилось все вполне быстро, меня устраивало. Но хотелось еще управление NFS-шарами. Это тоже нашлось – поставил внешний плагин. К дефолтному списку плагинов добавил также cockpit-pcp (расширенные графики) и cockpit-packagekit (управление пакетами). Протестировал – совершенно все теперь можно было делать в браузере. Подключил диск, смонтировал, создал шару.

Подключил шару на ноуте, закинул несколько тестовых файлов. Да, лилось на тех же 40 МБ/сек, что и показывал iperf поначалу. Затея себя полностью оправдала.

Для удобства перевесил Cockpit на 80/443-й порты. Делается это в файлике /etc/systemd/system/cockpit.socket.d/listen.conf, приводим к такому виду:

[Socket]
ListenStream=80
ListenStream=443

За время настройки несколько раз ловил ошибки ввода/вывода с microsd-карточкой. Куби и раньше у меня была в этом плане капризная – вплоть до того, что на microsd был только /boot, а вся остальная система – на USB-флешке. Еще в теории был внутренний eMMC, но, как оказалось, его поддержку выкинули :(. Жаль, можно было бы заменить дефолтно прошитый Андроид на свою систему. Решил хоть как-то поднять надежность системы и минимизировать запись. Помню, что видел в armbian-config что-то насчет read only файловой системы.

В общем, открыл для себя overlayroot. Пакет / система, позволяющая держать корень в RO, а изменения писать в другое место. Например, в tmpfs – и выкидывать их при перезагрузке. Супер, как раз пригодилось бы на майнинг-ригах вместо того, что я там делал вручную.

Правда, поначалу установка overlayroot ни к чему не привела. Несколько раз пробовал разные параметры, перезагружал систему – без толку. Нашел тред. По-большей части срач, разведенный на пустом месте, но зерно истины нашел: надо доставить busybox-static, после этого все заработало как надо – только пришлось отключить рекурсивную работу с помощью overlayroot="tmpfs:recurse=0", ибо оно и расшариваемый диск пыталось в RO перевести.

Что в итоге? NAS – двухядерная машина с гигом памяти и способная принимать и отдавать контент на скорости до 40 МБ/с – когда все загрузилось и с работающим диском потребляет около 4,5 Вт от сети. Когда диск “засыпает” – то 3,5 Вт. Т.е., где-то 0.6W падает на БП в любом из режимов. Занятно, кстати – под рукой был другой БП на 12В (вроде от сканера), там потребление от сети было 1,4 Вт даже без подключения к нагрузке. Думаю, от таких БП стоит избавляться.