Comments 65
круто! но было бы круто рассказать, зачем нужен UNRAID, я так навскидку не особо понял.
Сериалы на скрине как на подбор -- аж олдскулы сводит. Я уж и забыл, когда их смотрел :).
А вы уверены что использование ФС xfs и btrfs - хороший выбор? Сам автор btrfs вроде засомневался в надежности, по крайне мере аналога raid5 - точно
А вы уверены что использование ФС xfs и btrfs - хороший выбор?
а что лучше - ext4fs? Отрицая - предлагай. Вообще с xfs опыт на серверах позитивный. С btrfs - на серверах не гонял, скорее zfs. Но вроде бы должна была уже стабилизироваться.
https://btrfs.wiki.kernel.org/index.php/Status
RAID5/6 все еще unstable, по performance все еще есть вопросы. В общем лучше уж сразу ZFS.
а как насчет варианта btrfs + mdadm или это масло масляное?
В общем лучше уж сразу ZFS.
наверное (развожу руками).
а как насчет варианта btrfs + mdadm или это масло масляное?
Ну, я бы не стал такие выстрелы в ногу делать на каких-то важных данных. Если что-то пойдет не так то проще будет все снести, чем пытаться разрулить кто виноват и почему.
Опять же возникает вопрос как будет себя вести copy-on-write файловая система в связке с mdadm в плане производительности, я таких экспериментов не проводил. От checksumming/auto-repair тоже толку не будет, ну скажет он что данные битые, а не битой то копии в данной ситуации нет.
А 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, иначе каша чанков гарантирована.
Хотя это был raidz2 и потерю двух дисков она должна была переносить нормально.
А вот это, как раз, bitrot.
Не смогла, скорее всего, потому что те два диска просто отвалились раньше, а гнили все одновременно.
Скорее, наложились друг на друга отсутствие проверок и отвал двух дисков. И испортились именно контрольные суммы, а не сами данные.
Контрольные суммы — это тоже данные, они принципиально от содержимого файла не отличаются. 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 пихается в виртуалку без проблем. В контейнер пихать нет смысла.
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) потому, что тот вызывает фризы в потоке. Коммуникация, очевидно, медный гигабит.
Лично мне для комфортной работы с равами в лайтруме гигабита было мало (у меня тяжелые задачи — это массовая обработка), потому файлы у меня хранятся локально на десктопе, а на сервере только копия.
Два гигабитных порта в бонде снимают часть боли по поводу производительности сети. Не до уровня хороших SSD, но тем не менее.
Ну это же домашняя лаборатория. Как же себе любимому отказать. Тем более очень важно - можно по сети работать)
P.s. У меня под нужды сервера сейчас отведено 4 порта по гигабиту и я периодически думаю или об их увеличении, или о переводе NAS на SFP+ 10Gb потому что производительность дисковой подсистемы у меня упирается в сеть, даже без кэшей.
Так в целом, если запилить балансировку - может выйти в плюс. Потому что сервер в "головной роутер" сможет отдавать 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 на этот принтер ,но только убунту.
Есть ли возможность, установить в убунту или вообще отельный НАС поставить с поддержкой печати?
Или настроить убунту как нас?
Если же у вас готовая убунта уже есть и ничего трогать не хочется, то, думаю, можно на неё сверху поставить какой-нибудь cockpit и делать вид, что у вас готовый NAS.
Устанавливал на Винду вм варе 16, ставил убунту. После установки окно маленькое и вм тулс не устанавливается. Хотя до установки окно полного формата.
Решить проблему не смог в итоге.
В случае если прийдёт шифровальщик, что будете делать?
Лучше иметь возможность из снапшотов откатиться.
Удобнее. Но результат один.
А снапшоты стоят "дороже".
А снапшоты стоят "дороже".
O_o
Это вы так пошутили?
Да.
Бэкапы всё равно надо делать. То есть цена снапшотов идёт не вместо, а вместе с бэкапами.
Снапшоты делаются либо на специально обученной файловой системе, либо сторонними средствами. Во втором случае, по факту, получаем те же бэкапы. Ходовых файловых систем со снапшотами я знаю три — NTFS, btrfs и ZFS.
Первая для линукса не годится, вторая и третья мне не подходят. btrfs всё ещё пилят, а у zfs слишком много ограничений для моих требований к дисковому массиву и она мне обойдётся дороже и будет сложнее в обслуживании.
Сторонними средствами это куча компромиссов…
И NTFS не поддерживает снепшоты, вроде бы. Теневые копии это примерно то же, что делает LVM, только внутри ФС и для файла целиком.
у zfs слишком много ограничений для моих требований к дисковому массиву
Ну, это мы с вами уже обсуждали )
Теневые копии это примерно
И чем оно функционально от снапшота отличается? По факту у вас там получается доступ к файловой системе на определённый момент. Конечно, вы можете смотреть историю отдельного файла — но так же можно и смотреть "слепок" папки или просто открыть его. Моментального отката на конкретную точку не будет, правда — но это и не так уж часто нужно, в большинстве случаев отдельный файл достать требуется.
Ну, это мы с вами уже обсуждали )
Тогда вы мои требования должны помнить — возможность использовать диски разного размера и доставать-убирать их из массива произвольно, а не только менять на такие же либо большие.
Спасибо за статью, тоже давно пользуюсь unraid, но узнал много нового и полезного!
Я тоже статью писал) https://habr.com/ru/post/478924/
Всё равно не понимаю зачем это всё нужно для дома? Какая практическая цель?
Сериалы можно и так посмотреть. В чём смысл? Сервер ради сервера?
И меня на этом сервере не забанят, никакие сервисы не перестанут поддерживать, а тарифы на обслуживание только от меня зависят.
Не хочется звучать как сурвайвалист, но вот у нас в КЗ не было никакого интернета две недели примерно и без коллекции сериалов и фильмов накачанных в домашний 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 - зачёт! Такого простого и интуитивно понятного решения еще не видел. И главное, что работает, поставил и на работе и дома.
Не подскажете, может знаете..У меня диски все на NTFS. И есть один диск, где оочень много файлов с хардинками.. Т.к. с линуксом я на вы с мануалом по бумажке и не понимаю про файловые системы местные, то вопрос.. а как без дубликации этих данных скинуть их в UNRAID? Есть ли вообще средства, которым подсовываешь диск NTFS, а они его собирают в этот самый массив UNRAIDовый без повторного перекопирования? Ну или хотя бы с дедубликацией хардлинов NTFS?
И на скорую руку решений в голову не приходит, кроме как составить список файлов на диске и все, что являются хардлинками, удалить.
Есть ли вообще средства, которым подсовываешь диск NTFS, а они его собирают в этот самый массив UNRAIDовый без повторного перекопирования?
Подобное только с XFS провернуть можно при некоторых условиях.
С NTFS можно только при помощи плагина unassigned devices подмонтировать диск и потом скопировать нужные данные на массив unraid.
Файловые системы одна в другую не конвертируются, за очень редкими исключениями. Вам обязательно понадобится скопировать.
Вероятно (зависит от реализации работы с хардлинками в драйвере ntfs) можно скопировать файлы c помощью find -type f -exec …, а затем дописать линки find -type l -exec … но это потребует экспериента и хоть небольшого опыта с консолью.
Мой новый домашний сервер, часть 4: использование unraid