Pull to refresh

Comments 55

круто! но было бы круто рассказать, зачем нужен UNRAID, я так навскидку не особо понял.

Про это было во второй части. Тащить ещё и сюда… Ну, кратенькое описание можно сделать.

PS. Добавил абзац в начале.

Лучше сделать ссылки на предыдущие части в начале статьи.

Они до ката есть, а выше картинки поднимать не хочу.

Сериалы на скрине как на подбор -- аж олдскулы сводит. Я уж и забыл, когда их смотрел :).

Что есть. Я сериалы вообще не особо люблю, потому современное вообще не смотрю, а старое откапываю иногда, когда ностальгия нападает на тему «вот в детстве смотрел».
Есть ещё всякого старья, но оно большей частью так валяется, за пределами плекса. Может сейчас хоть руки дойдут проиндексировать.

А вы уверены что использование ФС xfs и btrfs - хороший выбор? Сам автор btrfs вроде засомневался в надежности, по крайне мере аналога raid5 - точно

А вы уверены что использование ФС xfs и btrfs - хороший выбор? 

а что лучше - ext4fs? Отрицая - предлагай. Вообще с xfs опыт на серверах позитивный. С btrfs - на серверах не гонял, скорее zfs. Но вроде бы должна была уже стабилизироваться.

а как насчет варианта btrfs + mdadm или это масло масляное?

В общем лучше уж сразу ZFS.

наверное (развожу руками).

а как насчет варианта btrfs + mdadm или это масло масляное?

Ну, я бы не стал такие выстрелы в ногу делать на каких-то важных данных. Если что-то пойдет не так то проще будет все снести, чем пытаться разрулить кто виноват и почему.

Опять же возникает вопрос как будет себя вести copy-on-write файловая система в связке с mdadm в плане производительности, я таких экспериментов не проводил. От checksumming/auto-repair тоже толку не будет, ну скажет он что данные битые, а не битой то копии в данной ситуации нет.

xfs — дубовая ОС времён чуть ли не ext2, если в ней какие-то баги и были, они давно уже сдохли от старости. И умолчальная ОС для массива именно она.
А btfs тут (по-умолчанию) используется только для кэширующих дисков, причём из её фишек только возможность создать зеркало применяется.
Так что если есть какие-то проблемы с raid5, то здесь их возникать не должно.

К сожалению на reddit'е неоднократно всплывали мольбы о помощи после проблем с btrfs и даже не в raid5 в основном массе после перевода Synology на эту ФС

xfs - субъективно, мне не нравится. Особых преимуществ перед ext4 нет и да я консерватор-пессимист все что связано с хранением данных. Для сервера с таким объемом хранилища и разнотипными дисками возможно имело бы смысл разбивать их на разделы по 900гб и из них собирать массив ZFS. Так делала к примеру Synology до DSM6 точно, сейчас не знаю

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

В своем опыте "домашнего серверостроения" перебрал очень много вариантов и не всегда последовательно:

HP Microserver Gen7 (hyper-v, xensever, omv4(5), proxmox, freenas, esxi)

DELL T20 (proxmox, truenas, hyper-v)

Самосбор на базе node 604, xeon-2136 (6 core) (truenas)

Массивы обычно до 6 дисков и максимум 20Тб и всегда память ТОЛЬКО ECC

Самое неприятное ощущение оставила hyper-v, максимальный позитив от решения в связке на хосте proxmox+omv (zfs), была очень хорошая статья на хабре

Финальный вариант - k3s в oracle cloud free tier и перешитый wd my cloud home под debian11 &OMV6 (для бекапов и автоматизации облака oracle)

В столе лежат 4 диска по 4tb - зачем они мне пока не решил, но собирать еще раз домашнюю хранилку не буду, тем самым избавил себя от синдрома Плюшкина.

Для лабы теперь только облака, фото и видео не болею, варез давно наскучил и пиратским софтом не пользуюсь из принципа.

мольбы о помощи после проблем с btrfs

Думаю, что потому её и не используют в основном массиве. А на дисках кэша к сохранности информации отношение проще. Можно так же reiserfs использовать, если вы любитель этого дела.
xfs — субъективно, мне не нравится. Особых преимуществ перед ext4 нет

Да и не должно быть, всё же xfs постарше будет. Это у ext4 преимущества могут быть перед xfs.
озможно имело бы смысл разбивать их на разделы по 900гб и из них собирать массив ZFS.

Ещё больше танцев с бубном при ещё меньшей возможности восстановить данные, если вдруг диски лететь начнут. zfs — это не панацея и нет смысла пытаться её присобачить к любой задаче.
интерфейс не радует.

Мне этим регулярно пользоваться, так что интерфейс должен радовать. Ну или, как минимум, не огорчать. Я могу на работе пользоваться неудобным инструментом — потому что у него какие-то другие достоинства есть с точки зрения бизнеса, но для себя я имею возможность выбирать то, что мне удобно.
память ТОЛЬКО ECC

По-моему, важность ЕСС тоже переоценена. Да, конечно, лучше, когда оно есть. Но снабжать ЕСС только сервер при том, что все клиенты работают с обычной памятью, да и надёжность каналов тоже может быть под вопросом, при этом мастер-копия рабочих данных хранится на клиенте… Смысла не вижу особого. Вот если данные с сервера не уходят или на рабочих станциях тоже о ЕСС позаботились — тогда да. Иначе же лучше будет взять больший объём памяти, к примеру.

Вот если данные с сервера не уходят

проблемы надо предупреждать, а не бороться с ними

По-моему, важность ЕСС тоже переоценена

отчасти - да. С другой стороны, есть же ситуации, когда биты в памяти флипаются, тем более под большой нагрузкой. Для хранилки достаточно высокие требования к надежности, в отличии от бытового ПК. Любая ошибка в кэше в памяти, учитывая DMA и прочие оптимизации... и у нас будет фарш, а не данные. Причем вне зависимости от ФС.

Но снабжать ЕСС только сервер при том, что все клиенты работают с обычной памятью, да и надёжность каналов тоже может быть под вопросом, при этом мастер-копия рабочих данных хранится на клиенте…

В памяти сервера информация может храниться до ребута: тот же кэш метаданных. Иногда это годы, в то время как на клиенте после совершения работы закешированный блок с высокой вероятностью будет вымыт.
Матожидание повреждения данных в ОЗУ на клиенте, соответственно, на порядки ниже.


Разными видами контроля ошибок снабжено буквально все: процессорные кэши, PCIE, SATA, Ethernet PHY, USB 3+.
Кроме ОЗУ клиента и мелких одноразовых буферов пересылки.


ZFS, кроме всего прочего, не просто пишет чексуммы. Она их еще и сверяет. При каждом чтении. Для метаданных и данных пользователя.
Учитывая, что современный десктопный накопитель нельзя прочитать без ошибок (BER не позволяет) — это крайне важная функция, если вы дорожите своими данными.

Добавлю. Как мне объяснял как-то корифей по Unix, который собирал хранилки для банков на zfs. Самое главное для zfs - достоверность метаданных в памяти, которая как раз обеспечивается ECC, иначе каша чанков гарантирована.

Каша на zfs гарантирована даже в том случае, если ЕСС-память стоит, но вы не гоняете регулярную проверку контрольных сумм. Тут недавно одни хипстеры попали на это — не настроили scrub по расписанию при сборке массива. И через год, когда заметили, что у них из разных vdev по паре дисков пропало, zfs не смогла сделать ребилд.
Хотя это был raidz2 и потерю двух дисков она должна была переносить нормально.

А вот это, как раз, bitrot.
Не смогла, скорее всего, потому что те два диска просто отвалились раньше, а гнили все одновременно.

У них там на сотни миллионов ошибок счёт шёл. Я сомневаюсь, что там всё настолько прогнило — это либо железо у них совсем кривое должно было быть, либо zfs настолько плохая файловая система, что без пересчёта контрольных сумм за год данные протухают.

Скорее, наложились друг на друга отсутствие проверок и отвал двух дисков. И испортились именно контрольные суммы, а не сами данные.

Контрольные суммы — это тоже данные, они принципиально от содержимого файла не отличаются. Scrub не пересчитывает записанные суммы, он их сверяет, так же, как и обычное чтение. только скраб делается для всех данных вообще, а не только для горячих.


К отвалу что-то должно было привести. Сами по себе диски не отваливаются, тем более пачками. Если парни поставили диски из одной партии (на практике мало кто заморачивается настолько, чтобы ставить диски разных партий или даже производителей — работало же раньше), то становится неудивительным групповой отказ. И очень вероятным то, что диски дохлые были все, изначально. Брак партии. UPD: в принципе, не только брак: нестабильность питания, кривой шлейф, неисправный HBA…
Просто некоторые сдохли раньше.


И в таких условиях никакой массив не обеспечит надежности при вменяемой избыточности.

Учитывая то, что у них там был массив из сотни дисков примерно, брать диски из разных партий было бы очень сложно. Физически у них сдохло вроде два диска, а остальные просто из массива вылетели, аппаратно же нормальные были.

А так вообще ребята те ещё любители ходить по граблям. Это сейчас у них архивный сервер посыпался, а несколько лет назад боевой развалился — «мы разобрали старый сервер бэкапов, собрали новый, начали заливать на него бэкап — и у нас сдох один из рейд-контроллеров на боевом сервере, а потом ещё и материнка добавила».

Справедливости ради, это касается любой ФС, но в случае zfs мы имеем еще и огромный ARC, который не управляется ядром (в Linux) — и большую вероятность ошибок.

Если бы всё было настолько страшно, то поддержка ЕСС давно была бы везде, во всех файловых системах и в любых процессорах.

Да, я не отрицаю, что такие проблемы могут возникнуть. Но вероятность не настолько велика, чтобы вкладываться в их решение вотпрямощаз. Да, со временем я планирую поставить ЕСС — когда память расширять буду. Но сегодня у меня выбор либо 32 гига обычной памяти, либо 16 ЕСС — и тут я выберу 32 гигабайта.

В процессорах и так L1/L2 со времен 462 сокета с ECC. Профессиональные видеокарты с ECC. DDR-5 обещали сделать с обязательным ECC. То есть, буквально все железо уже давно может быть с ECC, просто в консьюмерском сегменте это не так остро-актуально, так пока работает принцип неуловимого Джо.


Разумеется, флипнувшийся бит с хранилки наверняка придется на пользовательские данные — их тупо больше. Вероятность того, что ошибка придется на суперблок еще кратно ниже.
Но, собственно, именно потому что легаси-фс не обеспечивают контроль целостности, те же БД тащат его с собой.


Но если вы забэкапите ошибку в данных пользователя, не говоря уже о метаданных, — вам легче не станет. А обнаружить ее вы сумеете только когда попробуете восстановиться… вы же проверяете бэкапы?

хосте proxmox+omv (zfs)

Зачем множить сущности?

Proxmox у вас и тянет ZFS. Чтобы запилить к этому файлохранилище достаточно просто поднять контейнер с smb (ну и можно GUI Webmin прикрутить) и всё. В результате это будет работать устойчивее, жрать меньше памяти, обновляться и бэкапиться без подводных камней.

Чтобы точно ничего не пошло не так - на ZFS нужно запилить датасеты под нужные папки с нужными настройками.

Если что, то у самого домашний сервак на Dell T320 и proxmox.

All-In-One: Proxmox + OpenMediaVault или ещё одна идея для домашнего NAS / Хабр (habr.com)

И зачем?

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

Поэтому у меня один сервис - один контейнер. С ограниченным доступам к нужным датасетам, а в некоторых случаях и сетевым доступом к датасетам через виртуальный свич.

Ну и я уже писал про:

работать устойчивее, жрать меньше памяти, обновляться и бэкапиться без подводных камней

Пересборка пакетов OMV чтобы они встали на одну тачку с проксмоксом - ну такое себе.

То есть сделать то, конечно, можно. Но зачем? Какие проблемы это решит и за счёт чего?

Если прокинуть в контейнер датасет можно с помощью одной строчки в конфигурационном файле.

Я бросил глупую затею запихнуть OMV в контейнер (

Если у вас в nas только smb, то да, так проще и надежней. У меня задействованы абсолютно все варианты вплоть до tftp.

В остальных случаях NAS в домашних условиях проще управлять через web

Не надо пихать OMV в контейнер. Я этого и не предлагал.

Зато я предложил в качестве GUI использовать Webmin, а все остальные нужные сервисы поднять установкой пакетов.

Ну или если уж совсем секьюрно делать, то под каждый сервис поднять свой собственный контейнер и накатить в него Webmin, расплатившись за это более высоким оверхэдом (но при этом он будет меньше оверхеда OMV).

Причём в обоих вариантах мы получим более защищённое и легко обновляемое (и мигрируемое) решение.

И если уж на то пошло, то OMV пихается в виртуалку без проблем. В контейнер пихать нет смысла.

Кстати, у меня один из дисков с btrfs повадился уходить в рид-онли где-то раз в три дня.
syslog.1:Feb 17 03:04:41 Fractal kernel: BTRFS critical (device sdg1): corrupt leaf: root=2 block=265775857664 slot=18, unexpected item end, have 268451145 expect 15689
syslog.1:Feb 17 03:04:41 Fractal kernel: BTRFS info (device sdg1): leaf 265775857664 gen 124896 total ptrs 163 free space 6829 owner 2
syslog.1:Feb 17 03:04:41 Fractal kernel: BTRFS error (device sdg1): block=265775857664 write time tree block corruption detected
syslog.1:Feb 17 03:04:41 Fractal kernel: BTRFS: error (device sdg1) in btrfs_commit_transaction:2377: errno=-5 IO failure (Error while writing out transaction)
syslog.1:Feb 17 03:04:41 Fractal kernel: BTRFS info (device sdg1): forced readonly


Второй при этом работает нормально. Сам по себе диск вроде тоже нормальный — ссдшке меньше года. После ремаунта работал дня три, потом опять в RO.

Причину не понял. Прошелся записью по всему объёму, форматнул в xfs — пока неделю без ошибок. А второй диск с btrfs пашет нормально. Впрочем, там другой производитель и другие нагрузки.

А что получилось по производительности? Я вот очень сильно затыкаюсь в производительность samba-шары. Жена льёт равы сразу на сервер и оттуда обрабатывает, а это требует высокой скорости. И иногда приходится отключать qbittorent (хотя он и имеет nice 15 ionice idle) потому, что тот вызывает фризы в потоке. Коммуникация, очевидно, медный гигабит.

Сеть, конечно, является потенциально узким местом, но это не проблема unraid'a как такового. Тут больше вопрос организации процесса работы, чем технических ограничений.

Лично мне для комфортной работы с равами в лайтруме гигабита было мало (у меня тяжелые задачи — это массовая обработка), потому файлы у меня хранятся локально на десктопе, а на сервере только копия.

Два гигабитных порта в бонде снимают часть боли по поводу производительности сети. Не до уровня хороших SSD, но тем не менее.

Тут должна быть поддержка со стороны свитча плюс наличие свободных портов.

Ну это же домашняя лаборатория. Как же себе любимому отказать. Тем более очень важно - можно по сети работать)

P.s. У меня под нужды сервера сейчас отведено 4 порта по гигабиту и я периодически думаю или об их увеличении, или о переводе NAS на SFP+ 10Gb потому что производительность дисковой подсистемы у меня упирается в сеть, даже без кэшей.

У меня в домашней сети три свитча (если роутер считать), потому даже если я для сервера сделаю 2 гигабита, то с остальной сетью связь всё равно гигабитная будет. Конечно, после переезда можно будет и роутер поменять на десятипортовый, к примеру, но пока что смысла нет.

Так в целом, если запилить балансировку - может выйти в плюс. Потому что сервер в "головной роутер" сможет отдавать 2 гигабита, которые потом могут балансироваться по разные стороны.

Но вообще да, для творчества тут простор большой - позволяли бы выделенные на хобби финансы.

В любом случае бондинг в 2 гигабита мой массив забивает под горлышко. Правда там ZFS z-raid 2 8*4Тб SAS 7200 + 30Гбайт ARC.

В головном роутере у меня пять портов — два провайдера, один телевизор, один сервер, один пошел в остальную сеть. Допустим, выгоню телевизор и воткну второй кабель до сервера — на остальную сеть гигабитный линк. И от того, что серверу достанется два гигабита, остальным легче не станет.

Вы не поймите неправильно: в моём случае это был ответ на ваш вопрос про "скорость работы".

Но смотрите. У меня в головном роутере: ISP, 4 порта под сервер, 2 порта под беспроводные точки доступа (на самом деле излишне) и другие свичи.

К самому NAS цепляются только нотбуки и камера. Ноутбуки, в свою очередь, могут быть зацеплены как по проводу, так и по беспроводу. Учитывая 5GHz вафлю и гигабит, при одновременной максимальной нагрузке от ноутбуков, канал в 2 гигабита укладывается спокойно.

Телевизор: проводное подключение. Он тоже обращается к серверу, но через Plex, который висит на одном из двух свободных физических адаптеров. Всякие мониторинги сети тоже висят на свободном адаптере.

В итоге очередь сетевух под NAS ничем другим не забивается, а это может и будет негативно влиять на скорость.

Можете посоветовать?

Я поставил на слабый ПК q9400, ssd 128, ОЗУ 4гб. Убунту,.только ради того, чтобы печатать на канон 810. Есть готовый скрипт по установке cup's на этот принтер ,но только убунту.

Есть ли возможность, установить в убунту или вообще отельный НАС поставить с поддержкой печати?

Или настроить убунту как нас?

Обычная методика — поднимается виртуальная машина с нужной ОС и туда пробрасывается устройство. Я подобное делал с virtualbox'ом, но не вижу каких-то причин, по которым бы подобное нельзя было сделать в любой другой виртуалке, которая позволяет проброс usb.

Если же у вас готовая убунта уже есть и ничего трогать не хочется, то, думаю, можно на неё сверху поставить какой-нибудь cockpit и делать вид, что у вас готовый NAS.

Устанавливал на Винду вм варе 16, ставил убунту. После установки окно маленькое и вм тулс не устанавливается. Хотя до установки окно полного формата.

Решить проблему не смог в итоге.

Так сложно что-то диагностировать, но, обычно, когда guest tools не ставятся, то просто что-то делается не так. Они в линуксе из консоли ставятся, плюс, насколько помню, подкачивать ещё что-то хотят, типа компилятора.

Надо ставить dkms для сборки модулей ядра этих самых guet-tools, остальное он сам подтянет.

В случае если прийдёт шифровальщик, что будете делать?

Бэкапы восстанавливать.

Всё равно не понимаю зачем это всё нужно для дома? Какая практическая цель?

Сериалы можно и так посмотреть. В чём смысл? Сервер ради сервера?

Сериалы — это не основное. Основное — это то, что сервер — свой, а не дядин.
И меня на этом сервере не забанят, никакие сервисы не перестанут поддерживать, а тарифы на обслуживание только от меня зависят.

Не хочется звучать как сурвайвалист, но вот у нас в КЗ не было никакого интернета две недели примерно и без коллекции сериалов и фильмов накачанных в домашний Plex, было бы двольно грустно. Не зарекайся, как говорится.

Спасибо.
Но Openmediavault (OMV) хватает для всего. Открыто, удобно, умеет в zfs, soft raid, docker. Умеет и жить на флешке.
Хочется энтерпрайза без денег? Truenas Scale вам подойдет.
Надо что-то проще? Filebrowser, filestash, sftpgo в помощь.
Но Openmediavault (OMV) хватает для всего.

Как уже писал в предыдущих частях — как-то оно мне не очень в последних версиях. Совсем отказываться не планирую, но для дома хотелось чего-то более удобного.
умеет в zfs, soft raid, docker

Из этого два первых пункта мне не интересны, но в zfs умеет и unraid при сильном на то желании, есть плагин. Подозреваю, что и из коробки могут как-нибудь добавить, юзеры нередко просят.
Truenas Scale вам подойдет.

Мне он пока что кажется чистым NAS-решением. Впрочем, я его гоняю на таком калькуляторе, который и с zfs с трудом справляется, так что про дополнительные возможности ничего сказать не могу.

Urbackup - зачёт! Такого простого и интуитивно понятного решения еще не видел. И главное, что работает, поставил и на работе и дома.

Only those users with full accounts are able to leave comments. Log in, please.