В данной статье мы попробуем исследовать альтернативные варианты использования NAS.
Также мы попытаемся составить расширенный план тестирования на первых NAS, собранных на китайских процессорах RK3588 и на основе х86 архитектуры.
Мы уже приняли решение, что базовым софтом для нашего NAS будет OMV на Armbian. На этом стеке мы будем проводить тесты и замерять бенчмарки. Его мы будем оптимизировать под наше железо. Для него же в первую очередь будут составляться мануалы.
Но ресурсов нашего устройства хватит не только на организацию сетевого хранилища, но и на медиасервер, запускалку докеров, контроллер умного дома, VPN и прочее.
Медиасервер
Несмотря на относительно невысокую стоимость стриминговых сервисов и огромное количество сайтов с пиратским контентом, доступным онлайн, собственный медиасервер так и не потерял актуальность. Он позволяет не только смотреть кино и сериалы в 4К, комфортной озвучке и без рекламы, но и устраивать просмотр своего контента, хранящегося на NAS. Да и возможность сэкономить несколько сотен рублей в месяц на подписке - приятный бонус.
Мы планируем проверить работоспособность наиболее популярных бесплатных решений: Kodi, Plex, Emby. Особенно интересно, как подробная нагрузка отразится на целевых функциях нашего девайса, и сколько пользователей смогут одновременно пользоваться медиа-сервером.
Отдельной задачей стоит автоматическое перекодирование загруженного медиа (привет тем, кто высылает в Телеграмме двухминутные 4К ролики, размером в гигабайт).
Есть сервисы с уклоном в управление фотографиями, например PhotopPrism. Программа заботливо упакована в плагин для OMV. Но сложности могут возникнуть на этапе использования AI функций, вроде распознавания лиц и автоматической группировки фотографий по темам. Не ясно, будет ли эта функциональность работать на GPU "из коробки". Но приложение действительно интересное, и, в случае неполадок, нужно будет отдельно с ним поработать.
Своё облако
На мой взгляд, NextCloud или OwnCloud являются главными альтернативами OMV на нашем устройстве (хоть я и не очень понимаю текущий статус проекта OwnCloud). Это отличное решение как для дома, так и для небольшой организации. Оба продукта предлагают широкий набор инструментов не только для обмена файлами, но и для удобной совместной работы. Они предлагают почту, календарь, пакет офисных программ, чаты и звонки. Кроме этого есть приложения для Android и IOS.
Нас интересует в первую очередь два аспекта:
Запустится ли Cloud на нашем устройстве? Потребуется ли что-то портировать?
Какое количество пользователей смогут комфортно работать, без тормозов и падений?
По первому пункту мы не ожидаем серьезных сложностей, так как в списке устройств, которые предлагает NextCloud, есть устройства на ARM, есть проект NextCloudPi, гуглятся инструкции по запуску OwnCloud на Raspberry Pi и других одноплатниках.
Сложнее со вторым пунктом. Синтетические тесты дают искажённое представление о возможностях устройства. А реалистичные нагрузочные тесты - это непростая задача. Не хотелось бы пообещать комфортную работу команды из двадцати человек и сесть в лужу.
База знаний, таск трекер, хостинг кода
В продолжении идеи "NAS для малого бизнеса" мы бы хотели проверить и обкатать другие инструменты для организации работы небольшой команды. Интересно, получится ли поселить Gitlab или Gitea рядом с OMV. Будет ли это работать для команды хотя бы из пяти человек? Наша команда как раз использует Gitlab. Мы могли бы перевести один из наших внутренних проектов на тестовый прототип и через месяц-другой собрать реальные отзывы. Поставить эксперимент на живых людях, так сказать.
Но не обязательно ориентироваться на универсальный инструмент для работы команды. Я давно хочу завести себе self hosted записную книжку, вроде Evernote. Одно время пристально смотрел на Joplin, но руки так и не дошли. Заметных ресурсов он не потребляет, выглядит приятно, имеет приложения для Android и IPhone, синхронизацию можно настроить через WebDav.
Либо можно развернуть полноценную wiki. Какой конкретно инструмент взять для тестов пока что не ясно. Слишком прочно мы сидели на Confluence или Gitlab последнее время, и совершенно не в курсе, как сейчас носят системы хранения знаний. При быстром гуглении глаз зацепился за BookStack. С него и начнём.
Особое место в моём сердце занимает Draw.IO, который можно использовать не только в виде плагина для Confluence, но и развернуть на собственном сервере. Инструмент невероятно полезный, особенно в умелых руках. А ещё у сервиса есть интеграция с NextCloud.
Микросервер-запускалка докеров
Сегодня фраза "сервер на ARM" уже не звучит странно. Контейнеры позволяют избежать ада с зависимостями. И хотя вычислительные мощности NAS вряд ли сравнятся с HP Microserver, Raspberry Pi 4 заменить мы сможем. Но в этом пункте нас интересует не только возможность запускать Docker-контейнеры, но и наличие удобных инструментов для управления и мониторинга, а также возможность этих сервисов "уживаться" с OMV. Мой взгляд упал на Portainer, как на наиболее интересное, и при этом достаточно простое решение. Он не привязан к Kubernetes, как Gefyra, open source и довольно активно развивается. Хотя, признаться, я в управлении контейнерами не очень силён. Наверняка есть и более простые решения.
VPN
Выставить свою домашнюю инфраструктуру голыми портами в дикий Интернет - не самая разумная идея. Невозможно уследить за актуальным списком уязвимостей всех своих сервисов, регулярно менять пароли и мониторить открытые порты, если это не основная работа. Не говорю уже о высокой вероятности допустить ошибку. Проще и надёжнее сделать домашние сервисы доступными только внутри VPN. OpenVPN, и WireGuard легковесны и не должны заметно грузить систему. А решения вроде NetBird помогут упростить конфигурацию.
Поднимать VPN сервер на NAS кажется мне не очень оптимальной затеей. Разумнее запустить VPN на VPS, а подключение к VPN будет производить роутер. При корректной настройке маршрутизации все устройства в доме становятся доступны внутри приватной сети и не смотрят в Интернет напрямую. Это достаточно удобно и безопасно, но требует затраты на VPS и не самый простой роутер. VPN сервер на домашнем NAS обходится дешевле и может быть сильно проще в настройке при небольшом количестве девайсов дома. Именно для подобного использования мы собираемся произвести тесты и составить подробные инструкции с использованием наиболее популярного софта.
Контроллер умного дома
А почему бы и нет? NAS, с большой долей вероятности, работает 24/7. Там бежит Linux и есть свободные USB порты. Вероятнее всего устройство подключено через UPS (тем более что у нас есть что предложить). А большего от контроллера умного дома и не требуется. Осталось убедиться в работоспособности решения и изучить возможные побочки.
Tahoe
Этот вариант я упоминаю в последнюю очередь, но он отнюдь не последний по значению. Для нашей команды Tahoe является одной из наиболее интересных альтернатив OMV. Некоторые участники проекта согласились присоединиться только при условии работы с Tahoe. Поэтому адаптация и тестирование распределённого файлового хранилища на нашем устройстве будет идти практически параллельно с работами по OMV. В комментариях к нашим предыдущим статьям я сталкивался со следующим тезисом: "Некорректно называть собственный NAS заменой облачному хранилищу. Само устройство могут украсть, оно может сгореть при пожаре, утонуть при потопе, быть раздавленным при землетрясением и прочее. И никакой RAID от этого не спасет. Важные данные должны храниться и локально, и в облаке!". Так вот, с помощью Tahoe-LAFS можно восстановить потерянные файлы даже после потери своего устройства. Tahoe позволяет объединить несколько NAS в единую сеть. Каждый из участников сети дублирует данные других. Могут быть различные конфигурации построения сети: от простого зеркалирования до конфигурации схожей с RAID5/6. Tahoe это своего рода распределённый мета-RAID. При достаточном количестве участников сети мы кратно повышаем сохранность данных. Вторым, важным свойством Tahoe является то, что все данные всегда хранятся шифрованными. Это позволяет хранить любые данные в сети без опаски, что их могут скомпрометировать, подменить или изменить. Решение децентрализовано, а значит нет зависимости от конкретного вендора и его ценовой политики. Хотя заплатить за распределённость всё таки придётся. Но подробнее об этом мы расскажем в следующих статьях.
Итог
В конце хочется отметить, что мы ни в коем случае не собираемся распыляться и превращать NAS в универсальный комбайн, который плохо решает широкий спектр задач. Фокус всегда будет оставаться на хранении данных. Дополнительные сервисы неизбежно будут грузить железо, привносить новые уязвимости и конфликтовать с главной задачей нашего продукта. И использование NAS исключительно в качестве места для безопасного хранения данных кажется нам наиболее разумным решением.
Но не в последнюю очередь этот проект существует ради фана. А что может быть лучше, чем провести пару вечеров в попытках скрестить бульдога с носорогом, а затем заставить товарищей использовать получившегося франкенштейна "на благо общего дела"? А помимо удовольствия эта деятельность принесёт более чёткое видение продукта и расширит кругозор.
P. S.
Интересно было бы почитать про опыт использования перечисленного софта параллельно с OMV. Особенно на Raspberry Pi или Orange Pi.
P. P. S.
У нашего проекта NAS канал в Телеграмме: https://t.me/UberNasNews. Приходите!
Комментарии (48)
MountainGoat
10.04.2023 13:40+3И ещё подкину странную мысль. Поставьте у себя пропатченный SSH, который позволяет подключиться по нешифрованному тоннелю или с примитивным шифром. Дело в том, что SSHFS время от времени показывает себя лучше для клиентов Linux чем NFS и уж тем более Samba. И гораздо проще подключить. Но на слабой железке принудительное шифрование обычного современного SSH съест все 100% процессора. А при подключении в локалке шифрование обычно не нужно. Если поставите SSH, умеющий работать без шифрования, и напишете в инструкции, как к нему подключится (и что не надо к нему подключаться так через Интернет), это будет сильно полезно любителям иметь 5 установленных дистрибутивов и менять их раз в неделю. SSHFS в такой ситуации сильно проще, чем разбираться, как NFS глючит в каждом новом дистрибутиве.
lgorSL
10.04.2023 13:40Хм, я теперь понял почему скорость копирования файлов на rpi 4 через sshfs упирается в 50-60 мегабайт в секунду на гигабитном подключении Действительно из-за загрузки процессора на 100%. Но в принципе и 50 мегабайт - тоже норм.
Samba у меня не прижилась, на порядок медленнее работала.
sdy
10.04.2023 13:40+1Вопрос по охлаждению RPi4:
Какое у вас охлаждение проца?
Может быть проц просто тротлит при большой нагрузке, снижает частоту из-за чего его производительность резко падает.
lgorSL
10.04.2023 13:40Пассивный радиатор-корпус. В "покое" температура 57 градусов, при записи файла через sshfs — 65-68
sdy
10.04.2023 13:40+2Похоже процессору очень тепло. Даже в простое 57 это многовато. 65-68 - скорее всего потолок, за счет того, что процессор просто частоту понизил до самого минимума, чтобы температура больше не росла.
Можно попробовать его обдуть более интенсивно и посмотреть как изменится производительность системы под нагрузкой.
13werwolf13
10.04.2023 13:40+1чем разбираться, как NFS глючит в каждом новом дистрибутиве.
простите что? если использовать стандартный ядерный NFS а не юзерспейсный всратый nfs-ganesha то глюков вы ни встретите примерно никогда, это одна из самых стабильных и шустрых штук в мире. правда очень требовательно к качеству соединения
Поставьте у себя пропатченный SSH, который позволяет подключиться по нешифрованному тоннелю или с примитивным шифром.
и который не будет поддерживаться ничем кроме одного клиента над сношением с которым вы потратите пару часов жизни..
MountainGoat
10.04.2023 13:40NFS полон всратых сюрпризов. То банально заикается, теряя связь по Ethernet на домашнем роутере. То трансляция юзернеймов с сервера на клиент начинает чудить. Сама её необходимость - тоже привет из 90-х.
А вот ещё прикол. Смотрел дома фильм с сервера по NFS. Выключили свет. Комп с упсом, сервер с упсом. Роутер без упса. Упс. NFS повис на обоих концах намертво. И не давал отмонтировать реальные диски. umount просто вис. В результате при наличии двух упсов, выключать пришлось наживую.
NFS хорошая технология для рабочих условий. Для домашней файлопомойки он слишком неповоротливый.
13werwolf13
10.04.2023 13:40+1Если у вас проблемы с роутером это не вина nfs
Да, nfs это привет из прошлого века, но в этом нет ничего плохого (тем более в домашних условиях где в отличии от сурового прода у вас максимум десяток юзеров, не обязателен lockd и не нужно придумывать как сделать репликацию того что не умеет быть реплицировано)
Nfs бы отвис через короткое время после оживания сети
Как можно называть неповоротоивым самый шустрый способ сетевого доступа к файлам? Он не универсальный это да, он не самый удобный факт, но точно не неповоротливый.
13werwolf13
10.04.2023 13:40+3не люблю я 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, сколько я альтернатив для них не пробовал всё равно всегда возвращался.
innokenty_vyz Автор
10.04.2023 13:40+2По поводу первого пункта - мы же устройство специально разрабатываем как NAS. Это не стоковый одноплатник. Предварительные тесты на первых прототипах показали результат на уровне с х86 решением (можно глянуть в конце статьи https://habr.com/ru/companies/3rdman/articles/724730/).
Насчёт остальных пунктов спорить не стану. Тут дело вкуса.
MountainGoat
10.04.2023 13:40+1Docker нужен, чтобы пользователь мог поставить что угодно, не сталкиваясь с проблемой "под этот дистрибутив пакета нет, ставь руками 88 зависимостей и учись кросс-компилировать из исходников". По сути Докер на домашнем сервере выполняет роль Flatpak. Сам Flatpak не годится - с АРМ там печально, серверного софта мало.
А уж с докером каждый сам решает, что ему ставить: большой сервер с мордой, маленький без морды и т.д. Причём инструкции с DockerHub подойдут, хотя там никто про этот NAS и не слышал ни разу. А lxd это пусть и лёгкая, но полноценная система, а значит юзеру надо учиться админить линукс.
13werwolf13
10.04.2023 13:40под этот дистрибутив пакета нет, ставь руками 88 зависимостей и учись кросс-компилировать из исходников"
Вы сколько лет простите в заморозке провели?
Сам Flatpak не годится..
..по куче причин, тут если перечислять на целую статью потянет
А lxd это пусть и лёгкая, но полноценная система
Lxd прекрастно рулит и lxc контейнерами и qemu виртуалками, а lxc контейнеры могут быть как контейнерами ос так и контейнерами приложения (в отличии от докера который может быть только вторым)
юзеру надо учиться админить линукс.
В любом случае прийдётся
sdy
10.04.2023 13:40+2Pine64 уже старичок немного. При этом у него PCIe x4 реально есть в виде разъема, на который можно подцепить PCIe / SATA bridge на 4-6 дисков SATA.
У нас есть результаты тестов для сравнения этого решения с контроллером на основе x86. Есть небольшая зависимость от размера файлов, но в целом все упирается в пропускную способность сети.
GeorgiiIgnatev42
10.04.2023 13:40+2Можно использовать ОС на базе Linux — например, Ubuntu или Debian. Но они слишком требовательны, в них много излишних служб и утилит, их придется долго настраивать под NAS.
Поэтому для NAS используют дистрибутивы — специализированные урезанные операционные системы с минимумом функциональности. Они не требовательны к железу, у них нет собственной графической среды, но есть веб-интерфейс администратора.
Есть несколько популярных версий дистрибутивов:
FreeNAS,
NAS4Free.
EasyNAS,
Rockstor,
OpenMediaVault,
Openfiler.
Хороший дистрибутив должен соответствовать нескольким требованиям:
легко разворачиваться,
устанавливаться не только на жесткий диск, но и на USB,
занимать мало места,
предоставлять доступ к файлам по большому списку протоколов,
предоставлять функции защиты данных.
Также важна хорошая документация, поддержка и возможность добавления расширений. Бонусом станут дополнительные полезные функции и удобство интерфейса как основного способа взаимодействия с дистрибутивом.
sdy
10.04.2023 13:40+2устанавливаться не только на жесткий диск, но и на USB
По сути запуск с любого носителя, включая eMMC и SD, все так?
sdy
10.04.2023 13:40+1После прочтения комментов хочется устроить отдельное голосование на тему (никого не хочу обидеть, чисто попытка разобраться):
Нужен или нет докер в домашнем NAS?
Redwid
10.04.2023 13:40+1Был опыт строительства NASa на RK-какой то (rock64 8гб памяти). Очень становился не стабильным при больших нагрузках CPU и дисках.
А почему Emby, а не более сводный Jellyfin?
sdy
10.04.2023 13:40+1При больших нагрузках, процы начинает тротлить не по-детски. Для стабильной работы нужно хорошее охлаждение. Также некоторые контроллеры SATA очень чувствительны к температуре нагрева.
SabMakc
10.04.2023 13:40Были мысли подобного проекта - собрать многофункциональный сервер на базе VPS (с доступом через VPN) и использовать его для организации совместной работы небольших команд.
Настроить хостинг git, запустить аналог GDocs и т.д. На сколько понимаю, тот же nextCloud может выступать базой для этого всего...
В идеале - чтобы это все запускалось на VPS с минимальными ресурсами...MountainGoat
10.04.2023 13:40Это у вас не "проект" получается, а пачка рецептов для Ansible. Которые уже давно все есть.
SabMakc
10.04.2023 13:40+1Идея была в том, чтобы разработчики могли относительно просто все это запустить и настроить. Например, сформировать в конструкторе docker-compose с нужными сервисами, скопировать результат и запустить его.
Т.е. далеко не профессиональные админы, а в лучшем случае энтузиасты, а в худшем - начинающие разработчики.
Я не сомневаюсь, что профессиональному администратору это задача на раз-два (тем более, если уже работал с нужным софтом). И пачка рецептов для Ansible, вероятно, найдется.
Но что-то мне подсказывает, что эта пачка рецептов будет далеко не столь дружелюбной для пользователя, как мне бы того хотелось.
P.S. если уже есть на примете подобные решения - поделитесь ссылкой.
WicRus
10.04.2023 13:40+1Никакой. Один девайс, одна функция. Если делается 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 через контакт с корпусом.innokenty_vyz Автор
10.04.2023 13:40+2Фокус будет на функциональности NAS, безусловно. Особенно со стороны железа/механики. Мы не собираемся делать универсальный комбайн.
Но понимать возможности собственного девайса тоже хочется. Цель статьи - собрать информацию, что ещё интересно народу и в какую сторону стоит копать, если будут ресурсы.WicRus
10.04.2023 13:40+1Если это тот NAS, о котором идёт речь в ваших статьях, то это уже универсальный комбайн. Видеовыход, аудиовыход, GPIO, внутренние порты USB, питание дисков выведено на провода, а не подключается по средствам доп платы или sata разъёмов на основной плате, контроллер sata не распаян на плате, а устанавливается отдельно. Не забываем про радиаторы для микросхем, которые потребуются, чтобы в режиме 24/7 NAS не перегревался. Для обдува не должен использоваться маленький вентилятор воющий на полных оборотах, который попадался в некоторых статьях на фотографиях. Вот и получается одноплатник/девборда, которая будет конкурировать с десятками подобных устройств. Тут даже не критикую решение использовать SODIMM модуль, для прототипа допустимо, для серии нужно видеть цифры, чтобы понять в оправданности такого решения.
sdy Отвечу сразу про архитектуру. Да вы говорите всё верно, сделать базовый вариант, а дальше его расширять, но по фото из вашей статьи получается, что вы делаете наоборот, вначале расширенный вариант, а дальше будете его обрезать? Если же это и есть базовый вариант, то высок риск в итоге получить противоречие между "Универсальностью" + "Модернизацией" и "Доступностью".Выдержка из статьи ''Разработка NAS — цели и этапы''Несущая плата сейчас активно разводится, при этом все основные разъемы для подключения кабелей и модулей уже расставлены:
sdy
10.04.2023 13:40+1Еще раз хочу уточнить, что базовый вариант расчитан на подключение максимум 5 дисков. То фото, которое есть, это прототип, собранный исключительно для тестирования, большой корпус позволяет избежать проблем с доступностью и подходу к различным разъемам и узлам.
sdy
10.04.2023 13:40+2Это начальный / базовый вариант того, что мы хотим сделать.
Если грамотно построить архитектуру, то далее на базе начального варианта можно при желании расширить функционал. Но для этого нужно представлять, что интересно и применяется, а что нет.
Stanislavvv
10.04.2023 13:40+2nextcloud на слабеньком arm? Ню-ню...
Плавали, знаем. Там даже вебморда управления тормозит, не говоря уже о файлах.
Уж лучше samba/nfs/sftp + syncthing, если надо синхронизацию. Оно, по-крайней мере, упрётся не в проц, а в канал или диск.sdy
10.04.2023 13:40Что за слабенький ARM? Может он реально слабый был. Было бы полезно как референс некий использовать при тестировании.
Stanislavvv
10.04.2023 13:40Orange PI 3 LTS.
Хз, насколько он слабенький, но что в моём проекте пришлось отказаться от sqlite, так как нехватало процессора(!) на простой select с условиями с базой в /dev/shm чтобы nginx не ругался на окончание таймаута в 600 секунд, при этом тупое чтение всего текстового файла с теми же данными, но с usb-hdd (не ssd) с фильтрацией укладывалось в 10 секунд.
А если ещё и из-за перегрева снижалась частота процессора...
sdy
10.04.2023 13:40+1
Вот официальное сравнение ARM vs x86 на nextcloud.com. На мой взгляд если есть проблемы с производительностью, то речь скорее идет о конкретном решении и с ним надо реально разбираться. При этом все ARM под одну гребенку грести неправильно.
Stanislavvv
10.04.2023 13:40Там сравнивалось с серверными ARM, а не с доступными для дома одноплатниками.
Ключевое слово тут "доступными", ибо даже RPi4 стоит дороже бу системного блока аналогичной или даже бОльшей производительности.innokenty_vyz Автор
10.04.2023 13:40Новый Orange Pi 5 на Алике стоит с доставкой дешевле 10к. А малинки да, стоят совсем не социально.
Stanislavvv
10.04.2023 13:40+1Он не LTS, т.е. в случае чего - настраивать заново, а не купить и поставить, ибо железка через год не выпускается, а образы не особо совместимы между разным железом. То есть, железка побаловаться, бенчмарки поделать, а не поставить и быть уверенным, что в случае чего сумеешь быстро и надёжно восстановить.
А вообще, для хранилища за 10к можно взять б/у комп без извращений с армами, с возможностью апгрейдиться (да хотя бы память поставить), подключать больше пары дисков, причём практически любых, делать из них рейд и при этом ещё и иметь возможность запускать бОльший спектр ПО, а не только то, что соберётся под arm. Также с большой вероятностью процессор не будет перегреваться до зависания из-за высокой нагрузки на два ядра из 4-х (реальный случай с Orange PI, отчего был написан скрипт по имени thermald.sh). Из недостатков - скорее всего не будет wifi.
sdy
10.04.2023 13:40Какой у вас ARM был, с которым были проблемы производительности?
Stanislavvv
10.04.2023 13:40Orange PI 3 LTS. Покупался ещё до 4 LTS.
innokenty_vyz Автор
10.04.2023 13:40Там же не Rockchip был даже. Начиная с Orange Pi 4 ребята перешли на RK чипы и заметно в производительности прибавили.
Stanislavvv
10.04.2023 13:40+1Ну да. А что делать? Покупался давно, что было, то купил. Работает, но говорить, что любой arm достаточно быстрый, чтобы крутить docker - уже нельзя. Почему-то данный конкретный проц по производительности хуже, чем celeron n3350 на той же частоте (косвенно могу оценить от 10 до 2 раз в зависимости от того, что считается).
Впрочем, как хранилище и запускалка морды к библиотеке - отлично работает, а пхп мне там не крутить.sdy
10.04.2023 13:40+1Не понимаю зачем все время обобщать и на основе старого Allwinner 6 делать вывод о том, что все доступные ARM работают плохо.
К тому же для того чтобы процессоры работали без снижения производительности их надо очень хорошо охлаждать. У x86 систем худо-бедно охлаждение почти всегда есть, а для одноплатников типа Orange Pi очень часто забывают про элементарное охлаждение. В результате процессор без нормального охлаждения просто начинает тротлить и его производительность снижается в разы, если не на порядок.
Если сравнить тот же Allwinner 6 c RK3588, то у меня получается разница в производительности минимум раз в 30. И это даже не мейнфрейм процессор.
Stanislavvv
10.04.2023 13:40Не надо обобщать и считать, что у всех есть лишние деньги на новый одноплатник только потому, что он новый. Тем более, это уже точно не "слабенький арм", с которого начался тред, да и всякие zero тоже вполне себе продаются, хоть памяти там не для докера, но php попробовать запустить можно.
За 10к рублей я вряд ли куплю голый одноплатник чисто поиграться и потом воткнуть куда попало лишь бы применить, как-то у меня не складывается со спонтанными покупками выше нескольких тысяч, если непонятно назначение - админ, не разработчик железок. Та апельсинка была куплена далеко не за десятку, если что.
[...тут были рассуждения на тему покупки для дела, т.е. в сервер. Кратко: пк в большинстве случаев обойдутся дешевле, особенно если учитывать эксплуатацию и расширяемость...]
Что касается перегрева - там проц не троттлится, там проц вешается, к сожалению. Троттлинг, вернее понижение частоты от температуры я себе прикручивал при помощи крона, шелла и какой-то матери. В принципе, если взять радиатор не в виде пластинки с прорезями, а от пк и может быть включить там вентилятор - можно было бы не понижать частоту, но в тех габаритах, куда это засунуто и при тех задачах, проще так.
sdy
10.04.2023 13:40+1С этим соглашусь, чисто поиграться браь одноплатник реально дорого, а тем более собирать на нем NAS, учитывая что недорогих материнок x86 в принципе есть какое то количество подходящих.
Но у нас цель другая - сделать повторяемый и масштабируемый продукт. Как мне кажется, для этого больше подходят решения на тех процах, которые доступны и весьма любимы эмбеддерами. Вот это те самые ARM (Arm) процессоры, на которых сейчас можно достаточно свободно заказать производство нужных модулей в Китае, да и в РФ, если уж совсем припрёт.
MountainGoat
Докер. Из коробки должен стоять докер и docker compose если он в вашем докере не встроенный. А остальные встроенные сервисы можно предустановить через него. Тогда кому надо - допилит сам. И не будет стоять вопрос "Использовать Emby из прошивки, но старый, или из докера, но новый ".
И не надо городить формочку для ввода параметров, как в Unraid. От неё вред один. Даже нубу проще объяснить "Возьми вот этот кусок текста и вставь вон туда после строки 50" чем заполнять эту форму. А уж опытному и подавно. Я бы просто в веб морде сделал текстовое поле для docker-compose.yml и 2 кнопки - применить и отмена. Кртк. - сест. тлнт.
Portainer имхо тоже overkill - никто не будет на ARM железочке поднимать много одинаковых образов и настраивать отношения между ними. Ещё раз утверждаю, что понять текстовый конфиг docker-compose.yml новичку будет проще, чем все эти веб-морды. А если не поймёт, может скачать готовый конфиг.
innokenty_vyz Автор
Гм, справедливо конечно. Использовать Portainer для того, что бы 3-4 контейнера мониторить - слишком масштабно. Может посоветуете тили с простым веб-интерфейсом, который позволит легко даже с телефона посмотреть состояние контейнера и рестартануть его, если нужно?
MountainGoat
Увы, это не ко мне. Не одмин. У меня просто личный опыт греко-римской борьбы с докером в Unraid дома и куда более простого обращения с Docker на рабочей файлопомойке на Alma.
Tirarex
Как новичок в прошлом, могу сказать что портейнер в разы проще чем пляски с пробелами в yml файле, а compose в разы удобнее чем помнить что и где у тебя там на сервере раскидано.
Сам же докер уходит с 1 места лично для меня, после их активных действий против бесплатной версии приложения. Благо аналогов много.