Комментарии 53
Докер. Из коробки должен стоять докер и docker compose если он в вашем докере не встроенный. А остальные встроенные сервисы можно предустановить через него. Тогда кому надо - допилит сам. И не будет стоять вопрос "Использовать Emby из прошивки, но старый, или из докера, но новый ".
И не надо городить формочку для ввода параметров, как в Unraid. От неё вред один. Даже нубу проще объяснить "Возьми вот этот кусок текста и вставь вон туда после строки 50" чем заполнять эту форму. А уж опытному и подавно. Я бы просто в веб морде сделал текстовое поле для docker-compose.yml и 2 кнопки - применить и отмена. Кртк. - сест. тлнт.
Portainer имхо тоже overkill - никто не будет на ARM железочке поднимать много одинаковых образов и настраивать отношения между ними. Ещё раз утверждаю, что понять текстовый конфиг docker-compose.yml новичку будет проще, чем все эти веб-морды. А если не поймёт, может скачать готовый конфиг.
Гм, справедливо конечно. Использовать Portainer для того, что бы 3-4 контейнера мониторить - слишком масштабно. Может посоветуете тили с простым веб-интерфейсом, который позволит легко даже с телефона посмотреть состояние контейнера и рестартануть его, если нужно?
Как новичок в прошлом, могу сказать что портейнер в разы проще чем пляски с пробелами в yml файле, а compose в разы удобнее чем помнить что и где у тебя там на сервере раскидано.
Сам же докер уходит с 1 места лично для меня, после их активных действий против бесплатной версии приложения. Благо аналогов много.
И ещё подкину странную мысль. Поставьте у себя пропатченный SSH, который позволяет подключиться по нешифрованному тоннелю или с примитивным шифром. Дело в том, что SSHFS время от времени показывает себя лучше для клиентов Linux чем NFS и уж тем более Samba. И гораздо проще подключить. Но на слабой железке принудительное шифрование обычного современного SSH съест все 100% процессора. А при подключении в локалке шифрование обычно не нужно. Если поставите SSH, умеющий работать без шифрования, и напишете в инструкции, как к нему подключится (и что не надо к нему подключаться так через Интернет), это будет сильно полезно любителям иметь 5 установленных дистрибутивов и менять их раз в неделю. SSHFS в такой ситуации сильно проще, чем разбираться, как NFS глючит в каждом новом дистрибутиве.
Хм, я теперь понял почему скорость копирования файлов на rpi 4 через sshfs упирается в 50-60 мегабайт в секунду на гигабитном подключении Действительно из-за загрузки процессора на 100%. Но в принципе и 50 мегабайт - тоже норм.
Samba у меня не прижилась, на порядок медленнее работала.
Вопрос по охлаждению RPi4:
Какое у вас охлаждение проца?
Может быть проц просто тротлит при большой нагрузке, снижает частоту из-за чего его производительность резко падает.
Пассивный радиатор-корпус. В "покое" температура 57 градусов, при записи файла через sshfs — 65-68
Похоже процессору очень тепло. Даже в простое 57 это многовато. 65-68 - скорее всего потолок, за счет того, что процессор просто частоту понизил до самого минимума, чтобы температура больше не росла.
Можно попробовать его обдуть более интенсивно и посмотреть как изменится производительность системы под нагрузкой.
чем разбираться, как NFS глючит в каждом новом дистрибутиве.
простите что? если использовать стандартный ядерный NFS а не юзерспейсный всратый nfs-ganesha то глюков вы ни встретите примерно никогда, это одна из самых стабильных и шустрых штук в мире. правда очень требовательно к качеству соединения
Поставьте у себя пропатченный SSH, который позволяет подключиться по нешифрованному тоннелю или с примитивным шифром.
и который не будет поддерживаться ничем кроме одного клиента над сношением с которым вы потратите пару часов жизни..
NFS полон всратых сюрпризов. То банально заикается, теряя связь по Ethernet на домашнем роутере. То трансляция юзернеймов с сервера на клиент начинает чудить. Сама её необходимость - тоже привет из 90-х.
А вот ещё прикол. Смотрел дома фильм с сервера по NFS. Выключили свет. Комп с упсом, сервер с упсом. Роутер без упса. Упс. NFS повис на обоих концах намертво. И не давал отмонтировать реальные диски. umount просто вис. В результате при наличии двух упсов, выключать пришлось наживую.
NFS хорошая технология для рабочих условий. Для домашней файлопомойки он слишком неповоротливый.
Если у вас проблемы с роутером это не вина nfs
Да, nfs это привет из прошлого века, но в этом нет ничего плохого (тем более в домашних условиях где в отличии от сурового прода у вас максимум десяток юзеров, не обязателен lockd и не нужно придумывать как сделать репликацию того что не умеет быть реплицировано)
Nfs бы отвис через короткое время после оживания сети
Как можно называть неповоротоивым самый шустрый способ сетевого доступа к файлам? Он не универсальный это да, он не самый удобный факт, но точно не неповоротливый.
не люблю я omv и прочие поделки которые пытаются решить мои задачи своими всратыми методами, поэтому расскажу свой рецепт счастья: для начала выбираем дистрибутив который нам хорошо знаком и который имеет в репозиториях весь нужный софт (в моём случае это opensuse, из интересных могу посоветовать обратить внимание на gentoo и nix)
1) одноплатник плохой выбор для nas так как скорость доступа к дискам будет медленной (если это не pine64 с воткнутым в его полноценный pci-e разъём HBA, хотя это тоже в теории так как заполучить для тестов его я так и не смог)
2) btrfs (mdadm не гибкий, zfs слишком требовательный)
3) nextcloud > syncthing+stdiscosrv (для синхронизации файлов не обязательно ставить огромную вундервафлю)
4) gitlab > git-daemon (причина та же что и с облаком, для хранения и версионирования кода/конфигов/etc совершенно не обязательно ставить огромную вундервафлю с вебмордой и дополнительными сервисами требующую субд)
5) samba > sftp (не путать с ftps) и nfs (так и быстрее и удобнее и меньше ресурсов требует)
ну и зачем на домашнем nas нужен docker я как-то не очень понимаю. если есть необходимость ограничивать сервисам ресурсы и доступ к данным всё это делается силами systemd, ещё один демон и оверхед по дисковому пространству на рантайм контейнеров тут явно лишние (ну а если очень надо запустить что-то в рантайме другого дистриутива то я рекомендую lxd).
из этого списка претензий нет только к wg и hass, сколько я альтернатив для них не пробовал всё равно всегда возвращался.
По поводу первого пункта - мы же устройство специально разрабатываем как NAS. Это не стоковый одноплатник. Предварительные тесты на первых прототипах показали результат на уровне с х86 решением (можно глянуть в конце статьи https://habr.com/ru/companies/3rdman/articles/724730/).
Насчёт остальных пунктов спорить не стану. Тут дело вкуса.
Docker нужен, чтобы пользователь мог поставить что угодно, не сталкиваясь с проблемой "под этот дистрибутив пакета нет, ставь руками 88 зависимостей и учись кросс-компилировать из исходников". По сути Докер на домашнем сервере выполняет роль Flatpak. Сам Flatpak не годится - с АРМ там печально, серверного софта мало.
А уж с докером каждый сам решает, что ему ставить: большой сервер с мордой, маленький без морды и т.д. Причём инструкции с DockerHub подойдут, хотя там никто про этот NAS и не слышал ни разу. А lxd это пусть и лёгкая, но полноценная система, а значит юзеру надо учиться админить линукс.
под этот дистрибутив пакета нет, ставь руками 88 зависимостей и учись кросс-компилировать из исходников"
Вы сколько лет простите в заморозке провели?
Сам Flatpak не годится..
..по куче причин, тут если перечислять на целую статью потянет
А lxd это пусть и лёгкая, но полноценная система
Lxd прекрастно рулит и lxc контейнерами и qemu виртуалками, а lxc контейнеры могут быть как контейнерами ос так и контейнерами приложения (в отличии от докера который может быть только вторым)
юзеру надо учиться админить линукс.
В любом случае прийдётся
Pine64 уже старичок немного. При этом у него PCIe x4 реально есть в виде разъема, на который можно подцепить PCIe / SATA bridge на 4-6 дисков SATA.
У нас есть результаты тестов для сравнения этого решения с контроллером на основе x86. Есть небольшая зависимость от размера файлов, но в целом все упирается в пропускную способность сети.
Можно использовать ОС на базе Linux — например, Ubuntu или Debian. Но они слишком требовательны, в них много излишних служб и утилит, их придется долго настраивать под NAS.
Поэтому для NAS используют дистрибутивы — специализированные урезанные операционные системы с минимумом функциональности. Они не требовательны к железу, у них нет собственной графической среды, но есть веб-интерфейс администратора.
Есть несколько популярных версий дистрибутивов:
FreeNAS,
NAS4Free.
EasyNAS,
Rockstor,
OpenMediaVault,
Openfiler.
Хороший дистрибутив должен соответствовать нескольким требованиям:
легко разворачиваться,
устанавливаться не только на жесткий диск, но и на USB,
занимать мало места,
предоставлять доступ к файлам по большому списку протоколов,
предоставлять функции защиты данных.
Также важна хорошая документация, поддержка и возможность добавления расширений. Бонусом станут дополнительные полезные функции и удобство интерфейса как основного способа взаимодействия с дистрибутивом.
После прочтения комментов хочется устроить отдельное голосование на тему (никого не хочу обидеть, чисто попытка разобраться):
Нужен или нет докер в домашнем NAS?
Был опыт строительства NASa на RK-какой то (rock64 8гб памяти). Очень становился не стабильным при больших нагрузках CPU и дисках.
А почему Emby, а не более сводный Jellyfin?
Были мысли подобного проекта - собрать многофункциональный сервер на базе VPS (с доступом через VPN) и использовать его для организации совместной работы небольших команд.
Настроить хостинг git, запустить аналог GDocs и т.д. На сколько понимаю, тот же nextCloud может выступать базой для этого всего...
В идеале - чтобы это все запускалось на VPS с минимальными ресурсами...
Это у вас не "проект" получается, а пачка рецептов для Ansible. Которые уже давно все есть.
Идея была в том, чтобы разработчики могли относительно просто все это запустить и настроить. Например, сформировать в конструкторе docker-compose с нужными сервисами, скопировать результат и запустить его.
Т.е. далеко не профессиональные админы, а в лучшем случае энтузиасты, а в худшем - начинающие разработчики.
Я не сомневаюсь, что профессиональному администратору это задача на раз-два (тем более, если уже работал с нужным софтом). И пачка рецептов для Ansible, вероятно, найдется.
Но что-то мне подсказывает, что эта пачка рецептов будет далеко не столь дружелюбной для пользователя, как мне бы того хотелось.
P.S. если уже есть на примете подобные решения - поделитесь ссылкой.
Никакой. Один девайс, одна функция. Если делается NAS, то он должен максимально качественно выполнять свою основную функцию. Судя по предыдущим статьям, у вас уже получается не NAS, а мини-ПК с возможностью подключения SATA дисков. Как следствие пойдёт удорожание и будет сложнее конкурировать с узкоспециализированными устройствами.
Какое-то время назад искал недорогой одноплат на ARM с sata портами, чтобы подключить туда пачку 2.5" sata дисков и получить колхозный NAS. Специализированных плат не особо то нашёл (за разумные средства само собой), возможно даже нет специализированных ARM SoC под это дело. Лично мне как пользователю интересен не дорогой, компактный ARM-based NAS на 4-6 SATA портов под sata диски 2.5", 1GbE, 120/140 мм не шумный вентилятор, от силы пара USB портов про запас и охлаждение CPU/RAM/PWM через контакт с корпусом.
Фокус будет на функциональности NAS, безусловно. Особенно со стороны железа/механики. Мы не собираемся делать универсальный комбайн.
Но понимать возможности собственного девайса тоже хочется. Цель статьи - собрать информацию, что ещё интересно народу и в какую сторону стоит копать, если будут ресурсы.
Если это тот NAS, о котором идёт речь в ваших статьях, то это уже универсальный комбайн. Видеовыход, аудиовыход, GPIO, внутренние порты USB, питание дисков выведено на провода, а не подключается по средствам доп платы или sata разъёмов на основной плате, контроллер sata не распаян на плате, а устанавливается отдельно. Не забываем про радиаторы для микросхем, которые потребуются, чтобы в режиме 24/7 NAS не перегревался. Для обдува не должен использоваться маленький вентилятор воющий на полных оборотах, который попадался в некоторых статьях на фотографиях. Вот и получается одноплатник/девборда, которая будет конкурировать с десятками подобных устройств. Тут даже не критикую решение использовать SODIMM модуль, для прототипа допустимо, для серии нужно видеть цифры, чтобы понять в оправданности такого решения.
sdy Отвечу сразу про архитектуру. Да вы говорите всё верно, сделать базовый вариант, а дальше его расширять, но по фото из вашей статьи получается, что вы делаете наоборот, вначале расширенный вариант, а дальше будете его обрезать? Если же это и есть базовый вариант, то высок риск в итоге получить противоречие между "Универсальностью" + "Модернизацией" и "Доступностью".
Несущая плата сейчас активно разводится, при этом все основные разъемы для подключения кабелей и модулей уже расставлены:
Это начальный / базовый вариант того, что мы хотим сделать.
Если грамотно построить архитектуру, то далее на базе начального варианта можно при желании расширить функционал. Но для этого нужно представлять, что интересно и применяется, а что нет.
nextcloud на слабеньком arm? Ню-ню...
Плавали, знаем. Там даже вебморда управления тормозит, не говоря уже о файлах.
Уж лучше samba/nfs/sftp + syncthing, если надо синхронизацию. Оно, по-крайней мере, упрётся не в проц, а в канал или диск.
Что за слабенький ARM? Может он реально слабый был. Было бы полезно как референс некий использовать при тестировании.
Orange PI 3 LTS.
Хз, насколько он слабенький, но что в моём проекте пришлось отказаться от sqlite, так как нехватало процессора(!) на простой select с условиями с базой в /dev/shm чтобы nginx не ругался на окончание таймаута в 600 секунд, при этом тупое чтение всего текстового файла с теми же данными, но с usb-hdd (не ssd) с фильтрацией укладывалось в 10 секунд.
А если ещё и из-за перегрева снижалась частота процессора...
Вот официальное сравнение ARM vs x86 на nextcloud.com. На мой взгляд если есть проблемы с производительностью, то речь скорее идет о конкретном решении и с ним надо реально разбираться. При этом все ARM под одну гребенку грести неправильно.
Там сравнивалось с серверными ARM, а не с доступными для дома одноплатниками.
Ключевое слово тут "доступными", ибо даже RPi4 стоит дороже бу системного блока аналогичной или даже бОльшей производительности.
Новый Orange Pi 5 на Алике стоит с доставкой дешевле 10к. А малинки да, стоят совсем не социально.
Он не LTS, т.е. в случае чего - настраивать заново, а не купить и поставить, ибо железка через год не выпускается, а образы не особо совместимы между разным железом. То есть, железка побаловаться, бенчмарки поделать, а не поставить и быть уверенным, что в случае чего сумеешь быстро и надёжно восстановить.
А вообще, для хранилища за 10к можно взять б/у комп без извращений с армами, с возможностью апгрейдиться (да хотя бы память поставить), подключать больше пары дисков, причём практически любых, делать из них рейд и при этом ещё и иметь возможность запускать бОльший спектр ПО, а не только то, что соберётся под arm. Также с большой вероятностью процессор не будет перегреваться до зависания из-за высокой нагрузки на два ядра из 4-х (реальный случай с Orange PI, отчего был написан скрипт по имени thermald.sh). Из недостатков - скорее всего не будет wifi.
Какой у вас ARM был, с которым были проблемы производительности?
Orange PI 3 LTS. Покупался ещё до 4 LTS.
Там же не Rockchip был даже. Начиная с Orange Pi 4 ребята перешли на RK чипы и заметно в производительности прибавили.
Ну да. А что делать? Покупался давно, что было, то купил. Работает, но говорить, что любой arm достаточно быстрый, чтобы крутить docker - уже нельзя. Почему-то данный конкретный проц по производительности хуже, чем celeron n3350 на той же частоте (косвенно могу оценить от 10 до 2 раз в зависимости от того, что считается).
Впрочем, как хранилище и запускалка морды к библиотеке - отлично работает, а пхп мне там не крутить.
Не понимаю зачем все время обобщать и на основе старого Allwinner 6 делать вывод о том, что все доступные ARM работают плохо.
К тому же для того чтобы процессоры работали без снижения производительности их надо очень хорошо охлаждать. У x86 систем худо-бедно охлаждение почти всегда есть, а для одноплатников типа Orange Pi очень часто забывают про элементарное охлаждение. В результате процессор без нормального охлаждения просто начинает тротлить и его производительность снижается в разы, если не на порядок.
Если сравнить тот же Allwinner 6 c RK3588, то у меня получается разница в производительности минимум раз в 30. И это даже не мейнфрейм процессор.
Не надо обобщать и считать, что у всех есть лишние деньги на новый одноплатник только потому, что он новый. Тем более, это уже точно не "слабенький арм", с которого начался тред, да и всякие zero тоже вполне себе продаются, хоть памяти там не для докера, но php попробовать запустить можно.
За 10к рублей я вряд ли куплю голый одноплатник чисто поиграться и потом воткнуть куда попало лишь бы применить, как-то у меня не складывается со спонтанными покупками выше нескольких тысяч, если непонятно назначение - админ, не разработчик железок. Та апельсинка была куплена далеко не за десятку, если что.
[...тут были рассуждения на тему покупки для дела, т.е. в сервер. Кратко: пк в большинстве случаев обойдутся дешевле, особенно если учитывать эксплуатацию и расширяемость...]
Что касается перегрева - там проц не троттлится, там проц вешается, к сожалению. Троттлинг, вернее понижение частоты от температуры я себе прикручивал при помощи крона, шелла и какой-то матери. В принципе, если взять радиатор не в виде пластинки с прорезями, а от пк и может быть включить там вентилятор - можно было бы не понижать частоту, но в тех габаритах, куда это засунуто и при тех задачах, проще так.
С этим соглашусь, чисто поиграться браь одноплатник реально дорого, а тем более собирать на нем NAS, учитывая что недорогих материнок x86 в принципе есть какое то количество подходящих.
Но у нас цель другая - сделать повторяемый и масштабируемый продукт. Как мне кажется, для этого больше подходят решения на тех процах, которые доступны и весьма любимы эмбеддерами. Вот это те самые ARM (Arm) процессоры, на которых сейчас можно достаточно свободно заказать производство нужных модулей в Китае, да и в РФ, если уж совсем припрёт.
Еще от стоимости электричества зависит. При 40 центах за кВт*ч я че-т совсем не хочу крутить бу системник 24/7.
б/у нетбук потребляет десяток ватт, если батарея заряжена и на нетбук есть заметная нагрузка. Если требуется ме́ньшее потребление - это уже будет тот случай, когда я буду посматривать на arm, но, как минимум, Orange Pi 3 LTS кушает порядка 5Вт и выигрыш не особо велик, особенно, если к компу надо подключать что-то ещё, кроме сети (жесткие диски и т.п.).
Цель есть, пришло время подумать о том, какой софт поставить на NAS