Создание домашней файлопомойки
Network Attached Storage
NAS - файлопомойка, на которой аноним может хранить терабайты полезной нагрузки. Можно сделать из говна и палок, и плакать когда (не если, а когда) рейд бесповоротно сдохнет, или можно попробовать сделать его отказоустойчивым, насколько это возможно. Для этого тебе навряд ли хватит этой вики, но как отправная точка она пойдёт.
100% гарантий сохранности данных он не обеспечит в любом случае, поэтому важное всегда нужно бэкапить на отдельный носитель, например, внешний хард, флешку, оптический диск; запаковать в зашифрованный архив с большим ключом или LUKS/VeraCrypt криптоконтейнер, и залить на бесплатное облако. А лучше бекапить важное сразу в несколько разных мест. Вытащить данные со сдохшего рейда практически невозможно. А ещё все здесь написанное - опыт рандомного хуя, и он может в чём-то ошибиться.
Тебя предупредили.
С другой стороны, хорошо сделанный NAS будет всяко понадежней и пообъемней твоего харда. Он продолжит работать даже когда сдохнут два или более диска в нем (зависит от конфига рейда), и кроме как файлопомойка, доступная с любого устройства в твоей локалке, может долгие годы служить твоим домашним сервером, с которого ты сможешь стримить аниму на телевизор/телефон/планшет, качать и круглосуточно раздавать торренты, добавляя их хоть с телефона; на нем ты сможешь поднять свою парашу, сделать хранилище доступным из интернета, защитить данные от шифровальщиков, поднять почтовик со спаморезалкой, jabber-сервер, и т.д. Его возможности ограничены только бюджетом, железом, твоими навыками, упорством и воображением.
Хранилище, как и любой другой пека, состоит из железа, софта и периферии:
Готовые NAS либо стоят слишком дорого, либо слишком немощные. Оптимальнее собрать самому.
Железо
Корпус
Корпус хранилища должен вмещать все комплектующие, в том числе и все харды. Харды должны охлаждаться ниже 40C в работе. Остальное - дело вкуса, вариантов много. Можно и нужно брать б/у.
Хорошо, если в нем есть корзина для хардов с доступом снаружи для быстрой замены, но домашний NAS пойдет и без этого, ведь всегда можно его выключить, разобрать и обслужить. За удобство придется доплатить, бюджет можно потратить на детали поважнее.
Некоторые корпуса, например, Node304, имеют внутренние корзины с виброподвесами, чтобы харды не так шумели. Вместо этого вполне можно заюзать резиновые проставки под болты, крепящие харды к корпусу. Блоки питания, поставляемые вкупе с корпусами, обычно откровенно хуёвые, и их придется заменить, поэтому тоже нахуй. Про БП чуть дальше.
На али и ебее продаются внутренние корзины для хардов (HDD Cage Rack), которые можно закрепить внутри системника, и на которые можно повесить кулер. Например, такая хуйня: 
Учти, что размер корпуса ограничит выбор матерей по их форм-фактору. Я вот, например, заебался искать mini-itx мамку с поддержкой ecc оперативки для корпуса node304, но результат того стоил. Разумнее все же будет купить корпус хотя бы под microATX.
Харды
Вообще могут использоваться любые носители, не ограничиваясь хардами, но по цене за гигабайт харды в 2019 году лидируют.
На хардах лучше не экономить и брать новые.
Для файлопомойки подойдут “зеленые” серии на <6k rpm (rotations per minute), они тише, меньше греются и меньше вибрируют, чем >6k rpm. Но вообще похуй, смотри по бюджету, отзывам и здравому смыслу. Шум важен не всем, NAS можно поставить в дальний угол халупы, и пусть он себе шумит там.
По статистике и по опыту одного хуя (меня) меньше всего подводят харды HGST и Toshiba. WD купили HGST, поэтому я бы смотрел на старые модели, которые выпускались именно под брендом HGST. А лучше Toshiba.
Seagate однозначно идет лесом, лично видел больше десяти дохлых на работе, в том числе и в своем системнике. WD не использовал, говорят что у них проблемы с парковкой головок и что они тоже сыпятся. Кто-то рекомендует, хуй знает. Все харды сыпятся рано или поздно.
Для своего NAS брал шесть 3ТБ Toshiba HDWD130UZSVA, проблем за полгода ещё не было. В своих системниках тоже юзаю Toshiba и раньше юзал HGST, проблем не было, менял только когда места не хватало. Но это может быть ошибкой выжившего, думай своей головой.
Если собираешься собирать RAID, лучше закажи диски одного объема из разных партий. Например, модель одна и та же, а партии разные. Так меньше вероятность нарваться на одновременный отказ сразу нескольких дисков. Попроси об этом в комментарии к заказу или вообще закажи по телефону.
Размер 3.5" харда: 101.6 x 26.1 x 147 мм ШxВxД
Ёмкими дисками потребительского класса лучше не увлекаться, т.к. у них по спецификации допустимый Unrecoverable error rate == 1 per 10E14 bits read, то бишь один бит на каждые прочтённые 11.3687 ТБайт. Фактический рейт может быть ещё выше. Это аукнется при ребилде рейда, когда вместо полезной инфы из блока четности восстановится мусор и появится тихое повреждение данных, а то и ребилд зафейлится, и есть риск потерять весь рейд целиком при повреждении блока с метаданными.
Цитата: > Пусть у нас есть RAID 5 из пяти 3Т-дисков, в котором один из дисков отказал. Массив надо перестраивать, при этом придется прочитать 4 диска × 3T = 12Т =1,2·10^13 байт = 0,96·10^14 бит информации, причем независимо от степени заполнения массива — ведь на уровне RAID о файлах ничего неизвестно. Исправные диски пользовательского класса имеют законное право дать один сбой в среднем на 1·10^14 бит (см. напр. спецификации WD Red). То есть с очень большой вероятностью мы получим сбой реконструкции просто по спецификации диска.
Диски корпоративного класса имеют URE 1*10^15, то бишь один бит на 113.6868 прочтенных ТБайт. Это круто, но такие диски стоят слишком дохуя для домашнего NAS. Выходом может быть использование файловых систем с контрольными суммами блоков ZFS и избыточное резервирование на уровне RAID. Например, использовать зеркала raid1, или отдать под четность два харда из массива в raid6 или даже целых три в raid7.
Мать
Можно попробовать взять б/у, предварительно хорошо протестировав линпаком, мемтестом с заведомо рабочими планками оперативы, и другими стресс-тестами час-другой, но лучше все же не рисковать. На мамке, бывает, вздуваются конденсаторы и летят цепи питания, отваливаются разъемы на задней панели. Может наебнуться сокет если какой-нибудь сильный долбоеб неправильно вставлял в него процессор, или ещё что-нибудь. Я в мамках не спец, поэтому не рисковал и брал “типа новую” с авиты ASRock Rack E3C226D2I под LGA1150 сокет, т.к. был доступен такой процессор.
Хорошо, если на мамке есть много sata-разъемов, штук так от шести. Отлично, если мамка поддерживает ECC-оперативку (ZFS без неё поднимать себе дороже). Охуительно, если в NAS используется мать серверного класса, например, штеуд или asrock rack; обычно на таких мамках нет аудиоразъемов, зато есть годные цепи питания, сетевые адаптеры и чипсеты, плюс BMC бонусом, который есть KVM over IP с возможностью смонтировать iso-образ по сети как диск в приводе.
Выбор мамки ограничивается форм-фактором корпуса, сокетами доступных процессоров и типом памяти.
Я вот напоролся, когда решил сэкономить и взял сначала относительно дешевый xeon под 1155, а потом судорожно искал mini-itx мамку с поддержкой ECC памяти под него. Нашёл в ДС только одно объявление, да и то там intel-мамка оказалась нерабочей. Пришлось возвращать камушек продавцу, хорошо хоть он говниться не стал.
Blacklist: - Мамки Pegatron сразу нахуй, ибо китайское говно, в котором даже в bios не зайти - ASRock Rack C2750D4I/C2550D4I mass die-off (C2x50D4I boards) - Intel C2000 mass die-off, Intel’s C2000 SoCs manufactured up to early 2017 were prone to degrade
Процессор
Можно брать б/у, потестировав у продавца минут 20 линпаком. Хули ему будет-то, камушку?
Камушек обязан поддерживать ECC-оперативку, если собираешься использовать ZFS. У штеуда это все ветки Xeon, и, внезапно, все i3-камушки. У амуде ECC-память поддерживают все камушки. Но это не точно, на слово мне не верь, лучше сам посмотри даташиты на их сайтах.
Для простой файлопомойки под ZFS хватит и двуядерного i3. Хочешь вдобавок перекодировать видео на лету или крутить пару легких виртуалок? Бери хотя бы младший Xeon. И т.д, ну ты понял. Про AMD не знаю, не использовал. Себе поставил e3-1231v3.
У i5 и i7 есть проблемы с перегревом под разгоном из-за говнопасты под крышкой вместо нормального припоя. Если уж припёрло гнать, гугли скальпирование и жидкий металл с герметиком. Есть риск расколоть камень кривыми руками. Я не гнал, ибо нахуй нужно на NAS? i5, i7 и atom не поддерживают ECC память. По производительности Ivy Bridge не сильно уступает Haswell’у, судя по бенчам; стоит значительно дешевле, но и мамку под него найти труднее. Mini-ITX мамок с поддержкой ECC под 1155 и вовсе не найти в ДС в 2019 году.
Оперативная память
Можно брать б/у, если memtest не нашёл ошибок за ночь, или хотя бы за полчаса-час.
ОСТОРОЖНО, НЕ ОБЪЕБИСЬ! Если собрался брать ECC-память, проверь что и мамка, и процессор поддерживают такой тип памяти. ECC бывает нескольких видов: небуферизированная (unbuffered, UDIMM) и регистровая буферизированная (RDIMM, FB-DIMM, LR-DIMM). См. вики: Registered memory
Буферизированная память поддерживается камнями xeon класса e5-* и выше. Такая память стоит дешевле, т.к. её просто дохуя на рынке, но процессор и мать под неё стоят дороже. Хотя есть и недорогие варианты с али, поддерживающие буферизированную память.
e3-* и i3-* поддерживают только unbuffered ECC (UDIMM). Её меньше на рынке, и она стоит дороже буферизированной. С трудом нашёл и взял сильно б/у 2x8GB UDIMM DDR3, вытащенную из какой-то циски.
Блок питания
На БП экономить себе дороже. Хороший БП не греется и не шумит, т.к. имеет высокий КПД, выдает стабильное напряжение и ток; а в случае проблем в электросети или из-за старости подохнет сам, и не потянет за собой остальное, и без того недешёвое железо. Такой БП без проблем поддерживает перепады входного напряжения от 110 до 230 вольт. Лучше брать новый, со временем они приходят в негодность: высыхают/вздуваются конденсаторы, изнашивается кулер.
Хорошими БП считаются те, которые имеют сертификат 80+Gold и выше. Ну или хотя бы 80+Silver. Но лучше Gold+. Выбирал по расфасованному списку БП, которым поделился аноним из /hw/. Брал Chieftec GPM-550S.
Для расчета мощности БП можно использовать какой-нибудь калькулятор, вроде такого. При этом ты посчитаешь предельную мощность БП. Он прослужит тебе дольше, если будет использоваться не в предельном-стрессовом режиме, а на ~30-50% номинальной мощности. Поэтому стоит умножить получившийся результат на 1.25.
Вручную посчитать минимальную мощь БП по 12-вольтовой линии можно так: - 35 Вт для каждого харда - ~6 Вт на каждую планку оперативки - ~10 Вт на HBA SAS-контроллер - TDP процессора - ~15-30 Вт на кулер - Ваттаж мамки - Сложить цифры выше и умножить это все на 1.25
Также стоит учесть, что харды при запуске потребляют на раскрутку около 2.1 Ампер на каждый. Умножь 2.1 на число хардов и убедись, что выбранный тобой БП обеспечивает в номинальном режиме такой ток по 12В линии.
БП можно смело брать мощнее, чем расчитал, и потерями на тепло при хорошем КПД (80+Gold) можно принебречь. Он не сожрет больше энергии, чем подключенные к нему комплектующие, а проживет дольше, чем БП, постоянно работающий у предела номинальной мощности.
Лично видел, как БП на 750Вт стоил на 1к дешевле, чем БП на 550Вт из той же линейки в одном и том же магазине.
Хорошо, если твой БП позволит запитать все комплектующие, в т.ч. и все харды, штатными коннекторами. Если нет, есть Y-образные разветвители, про них смотри дальше.
Охлаждение
Можно взять б/у кулер, если он не раздолбан. Учти, что они изнашиваются. Радиатор (медно-аллюминивая теплоотводящая ебала́, на которую вешается кулер) на процессор можно и нужно брать б/у, главное чтобы крепления были в порядке.
Кроме процессора тебе понадобится охладить и корзину с хардами до <40C. Выбирай исходя из мест под кулеры в корпусе. Большие кулеры крутятся медленнее и шумят меньше, чем кулеры поменьше.
Шум при воздушном охлаждении образуется от подшипников кулеров и потоков воздуха, проходящего через радиаторы и отверстия в корпусе.
Краткий ликбез по подшипникам в кулерах. Для себя решил, что гидродинамические самые оптимальные по соотношению цена/качество.
SAS-контроллер
Если в мамке недостаточно sata-разъемов, придется докупить SAS-контроллер в PCI или PCIe. Можно брать б/у после проверки. Рекомендуют LSI, Avago, Broadcom. В один разъем такого контроллера можно воткнуть Y-образный кабель на четыре SATA. Разъемов может быть несколько. Обычно количество портов с прямым подключением пишется прямо в спеке (спецификации) контроллера. Можешь ещё воспользоваться SAS-expander’ом, который делит полосу между несколькими девайсами и позволяет подключить ещё больше носителей.
SAS-разъемы обратно совместимы с SATA-девайсами, не наоборот. Использовать рекомендуют только SAS-2+.
Wiki: > SAS-1: 3.0 Gbit/s, introduced in 2004 (говно мамонта, может глючить с современным железом, ограничивает max. размер диска до 2.2ТБ) > SAS-2: 6.0 Gbit/s, available since February 2009 (лучший кандидат для дома по цене/качеству) > SAS-3: 12.0 Gbit/s, available since March 2013 > SAS-4: 22.5 Gbit/s called “24G”, standard completed in 2017
От контроллера тебе нахуй не нужен встроенный RAID, т.к. для дома лучше использовать рейд программный, а с ним контроллер нужно выставить в режим тупого HBA (host bus adapter).
Отлично, если в контроллере есть батарейка, суперконденсатор или буферная флешка. Это поможет дописать информацию из буфера контроллера на диски при сбое питания, и рейд не наебнется по этой причине. Если такого нет, то ты рискуешь проебать рейд.
SATA контроллеры дешевле, но все поголовно обрезанное говно, в лучшем случае ограничивающие пропускную способность интерфейса, а обычно и вовсе неработающие. SATA port multiplier’ы туда же. Говорят, они хреново поддерживаются фряхой. Но дело твое, рискуй и плачь.
В серверных мамках обычно достаточно sata разъемов: 4, 6 или больше.
Кабели
Кроме обычных кабелей от БП, в NAS есть особенность с питанием и датой хардов.
Питание носителям обычно приходит по molex- и sata- кабелям. Molex выглядит как прямоугольный четырёхпиновый разъем с круглыми гнездами и скошенными углами на одной из длинных сторон. Sata-питание же выглядит как широкий и плоский коннектор, не ошибешься.
Molex-коннекторы спроектированы для больших токов, до 11А. Напомню, что харды при раскрутке при запуске потребляют по 2.1 Ампера на каждый, поэтому на один кабель с molex не стоит вешать больше 3-4 хардов при помощи Y-образного разветвителя.
SATA-коннекторы спроектированы для токов до 4.5А, на них разветвители лучше не вешать.
Если в мамке есть достаточно SATA-data разъемов, все просто и стандартно. Если используешь SAS-контроллер, к нему возможно придется найти и докупить подходящий Y-образный кабель, который одним SFF-коннектором вставляется в контроллер, а четырьмя или больше другими SAS-концами - в SATA-харды. Ну или в SAS-харды, если ты у мамы мажор.
Есть ещё вариант, когда в корзине используется бекплейн (backplane). Это задняя плата корзины, куда подключаются сразу несколько хардов. Бэкплейны обычно подключаются single-path SFF-кабелями (неразветвленные, по одному SFF-коннектору на каждом конце).
Софт
RAID
Есть несколько возможных конфигураций носителей. Можно использовать каждый диск по отдельности в разных точках монтирования в ОС, можно объединить все носители в один JBOD, который система видит как один диск, либо объединить носители в RAID - Redundant Array of Independent Disks. - Отдельные диски:
Плюсы:
- Нет избыточности - значит доступно всё полезное пространство на дисках. - Диски умирают по отдельности, при этом данные с остальных дисков остаются в порядке, пока не сдохнут и они. Минусы: - Нет общего массива дисков, данные приходится распределять вручную по каждому из них. - JBOD (just bunch of disks):
Плюсы: - Диски объединены в один массив, который системой видится как один носитель. - Нет избыточности - доступно все пространство дисков в массиве.
Минусы:
- Нет избыточности - один подохший диск в массиве тянет за собой в могилу данные с остальных дисков. - RAID: Плюсы: - Есть избыточность! RAID может пережить потерю нескольких дисков в массиве, зависит от конфига рейда. При этом достаточно заменить погибший диск, выполнить rebuild массива - и данные снова в порядке. - Массив дисков видится системой как один носитель. - Можно дополнить массив еще одним-двумя hotspare дисками, которые начинают использоваться для ребилда сразу, как только какой-то диск вышел из строя. Минусы: - Есть избыточность… Для обеспечения отказоустойчивости придется отдать часть полезного объема дисков под избыточные данные: блоки четности, либо зеркала. - Данные на массив распределяются хитрым образом, это негативно влияет на производительность в R5+. В домашнем NAS не очень-то и заметно. - Восстановить данные с окончательно подохшего рейда практически невозможно или очень дорого. - При построении RAID на каждом диске используется объем самого меньшего диска в массиве, поэтому делать рейд стоит из дисков одинакового размера. - Когда RAID работает в degraded режиме (какой-то диск вышел из строя), катастрофически снижается скорость записи и чтения на массив (в R5+), оставшиеся диски читаются гораздо интенсивней и, следовательно, увеличивается вероятность выхода из строя ещё какого-нибудь носителя.
Конфиги RAID (циферки)
Смотри WIKI. Если кратко по распространенным конфигам: - RAID 0 (распараллеливание):
Ненадежный, для NAS не подходит. Нет избыточности.
Данные распределяются по каждому диску в массиве параллельно. Из-за этого повышается скорость чтения и записи на массив. При поломке одного диска невозвратно подыхает весь массив. - RAID 1 (зеркалирование):
Диски объединяются в зеркало, данные пишутся на них одновременно, а читаются распараллеленно почти в два раза быстрее. Обычно объединяются два диска в одно зеркало, и несколько зеркал в один логический носитель на уровне ОС. При выходе из строя одного из дисков в зеркале, на живом остается полная копия данных, можно продолжать работать.
Если сдохли оба диска в одном зеркале в составе логического носителя, подыхает весь логический носитель. Под резервирование отдается ровно половина полезного объема дисков. С другой стороны, если даже во всех зеркалах умерло по одному диску, массив продолжит работать и его легко восстановить (если, конечно, во время ребилда не сдохнет хотя бы одно зеркало целиком). - RAID 5 (отдается объем одного диска из массива под блоки четности):
Для дома не подходит. И вообще нигде не подходит, его время ушло туда же, куда и диски <1ТБ.
Данные распределяются параллельно на весь массив дисков страйпами, плюс к каждому страйпу пишется один блок четности. См. вики. Массив теоретически может пережить поломку одного диска, а практически при использовании дисков >1TБ при ребилде неминуемо встретится невосстановимая ошибка чтения, из-за чего рейд сдохнет окончательно.
Также, при ребилде читается весь объем всех дисков, что повышает износ и вероятность поломки ещё одного диска, что также доломает рейд. - RAID 6 (два объема дисков под избыточность):
Принцип такой же, как и в R5, но вместо одного блока четности в массив пишется два. Это позволяет пережить поломку двух любых дисков из массива. С другой стороны, за это придется заплатить полезным объемом двух дисков. Производительность чуть меньше, чем у R5. - RAID 7 (три объема под избыточность):
См. R5 и R6. Пишется три блока четности на каждый страйп, можно пережить поломку трех дисков в массиве, под избыточность выделяется объем трех дисков.
В итоге нет идеального решения, за все приходится платить и идти на компромиссы. Такие дела. Я для себя выбрал R6 под ZFS (RAIDZ2), т.к. ему похуй какие два диска выйдут из строя, а производительность на запись и чтение для меня не критичны (да и хватает, запись по NFS4 на шару - 90-110 МБайт/сек через гигабитную локалку). Тебе же может подойти любой другой вариант, думай сам. Судя по интернетам, в 2019 году для домашних NAS выбирают из массива зеркал R1 и R6.
Кто-то топит за массив R1, т.к. там износ дисков в массиве при ребилде значительно меньше, т.к. для ребилда читается только один диск из пары, да и тот последовательно, а не интенсивно сразу все диски массива, как в R5+. Но, опять же, если сдохнет пара, то сдохнет и весь массив. И отдается половина объема всех дисков под избыточность.
Почему программный RAID?
Даже у одного производителя разные модели контроллеров могут считать блоки четности и писать страйпы по-разному, не говоря уж о совместимости между разными производителями. Если пизданется твой контроллер, то скорее всего придется искать такой же чтобы RAID прочитать. Это же относится и к “raid-контроллерам”, встроенным в дешевые материнки (которые, кстати, без батареек на дешевых чипсетах с хуем памяти и без хорошего охлаждения). Энтерпрайзу это не мешает, у них там долгоживующие и дорогущие линейки контроллеров, с большими запасами у вендоров.
Поэтому для дома остается вариант с программными RAID-контроллерами, которые найти и поставить проще простого. Да, они чуть менее производительны, чем аппаратные, отжирают немного оперативы и процессора (точных цифр не знаю), но дома это не так-то уж и заметно.
Мне известны следующие варианты программных RAID-контроллеров: - Оригинальный ZFS на FreeBSD, портированный с соляры; - ZFS on Linux (ZoL), который сейчас находится в активной разработке. Кто-то его уже использует. Фряха тоже будет переходить на эту реализацию. - mdadm на Linux; - Какая-то хуйня от microsoft
Дыра по записи на RAID 5+
Цитата: > RAID 5 (6 и др.) подвержен серьезной проблеме. При записи в массив одновременно должны быть записаны данные и блоки четности. Но запись на несколько дисков не есть атомарная операция. Если в процессе записи возникнет проблема (отключение питания, сбой диска и т.п.), то возможна ситуация, когда данные и блоки четности не будут соответствовать друг другу. Если неправильно записаны данные, то они во многих случаях могут быть исправлены или хотя бы обнаружены при обслуживании файловой системы, расположенной поверх RAID (chkdsk, fsck…). А вот неверные блоки четности в худшем случае могут остаться незамеченными до момента, когда по ним будет восстанавливаться массив. И вместо данных будет восстановлен мусор. Мало того, мусор будет записан безо всяких о том предупреждений. > Промышленные RAID-контроллеры решают проблему за счет использования BBU, «батарейки». После сбоя даже при отключенном питании контроллер помнит, какие данные должны были быть записаны. И при появлении возможности записывает эти данные в массив.
Про вероятность успешного ребилда
Либо большая вероятность восстановления и малый объем массива, либо наоборот. Либо стоимость массива увеличивается до космической с энтерпрайзными хардами. Есть оптимальные варианты с RAID6 и 7, и с массивами зеркал RAID1.
Прикинуть вероятность успешного восстановления с разными конфигами рейдов можно калькулятором. Например, этим.
TLER
??? Не понял, дополните кто-нибудь про это и таймауты в рейдах.
Операционная система и прикладной софт
Дело вкуса. Как говорил Генри Форд: “Цвет автомобиля может быть любым, при условии, что он черный”. Не вижу смысла поднимать NAS на ворованной винде, т.к. с его задачами прекрасно справляются никсы. Под никсы меньше зловредов и ботов с автоэксплойтами, чем под форточки. Никсы можешь настроить как твоей душе угодно, кастомизируется вообще всё. А если чего-то не хватает, можешь допилить если навык есть, ведь исходники всегда доступны. И т.к. исходники открыты, в их софте, полагаю, меньше закладок и недекларированных возможностей, чем в проприетарном кале.
Выбор огромен: - Зборочки для NAS с вебгуём для домохозяек: - FreeNAS(Сейчас trueNAS и требует 8гб оперативы, но предупреждение можно проигнорировать) - Open Media Vault - Nas4Free - … тысячи их - Вручную настроить под себя: - FreeBSD - требователен к железу, на котором будет работать, но стабильный, унифицированный, с jail’ами и охуенной документацией, даже на русском! - Linux, у которого очень много дистров на любой вкус и цвет
Перед установкой на NAS можно потыкать каждый интересный дистр палочкой в виртуалке, например, в VirtualBox или Qemu/KVM.
Про настройку софта писать не буду, тут одной статьи не хватит. Скажу только, что на NAS хорошо бы поднять: - Файрвол! - Уведомления по email: - О нештатном состоянии дисков из SMART - О перегреве - Об окончании дискового пространства - Об окончании электричества при переходе ИБП на батарею - Автовыключение при заряде ИБП < 60% - Регулярные scrub по крону каждые две недели (если используешь ZFS) - Сжатие LZ4 для ZFS. Оно почти прозрачно по производительности, а место экономит. Цифры приводить я, конечно, не буду.
Ещё, например, можно поднять безголовую торрентокачалку в контейнере/jail’е, и подключаться к ней удаленным клиентом (так умеет transmission и deluge). Можно настроить доступ по Samba, NFS, FTP, или поднять DLNA-сервер, и т.д, ну ты понял.
В дистрибутивах для домохозяек можно поставить нужный софт и настроить его прямо через веб-интерфейс.
ZFS
ZFS требует минимум 8 GB RAM. Лучше 16+GB. И минимум два x64 ядра. ZFS умеет в дедупликацию (дедуп жрет RAM как не в себя, дома не нужно).
ZFS защищает помогает защититься от дыры по записи.
К ней обязательно нужен power loss protection (PLP) на всех кешах и буферах, если они есть (батарейки на контроллерах и SLOG, либо кеши на запись отключить, что приводит к снижению быстродействия). А ещё обязательно нужна ECC RAM. Контрольные суммы - это заебись, но это не спасет, если при очередном scrub будут “восстановлены” поврежденные данные из-за flipped bits in RAM due to “cosmic rays”.
ZFS умеет делать copy-on-write снапшоты, которые весят пару килобайт. Можно делать их хоть на все датасеты ежедневно по крону, и таким образом защититься от шифровальщиков. Данные из снапшотов всегда доступны read-only из каталога /path/to/dataset/.zfs/snapshotname/. На снапшоты можно откатиться если что.
ZFS хреново растет. Растить ZPool можно только добавлением новых VDev. Ну или поочередной заменой всех носителей из VDev с ребилдом на каждый замененный. Уменьшать размер нельзя.
Пространство ZPool делится между всеми датасетами на нём. Можно настроить квоты и резервы. Квота - максимально доступный объем для датасета. Резерв - гарантированно доступное пространство для датасета. Это удобно, т.к. не надо резать массив на разделы, и можно использовать под каждый датасет ровно столько места, сколько нужно. Датасетов может быть сколько угодно в ZPool. Например, можно на каждый чих выделять по датасету: под файлопомойку, под каждый Jail, под бекапы, под торренты, и т.д.
ZFS по слоям от железа к ФС:
- VDev: - VDev is a group of disk drives that are allocated together and intended to work together as a single virtual device to store data. - VDev are allocated in RAIDZ formats (for R5 and R6 or Mirror for R0) - If VDev can’t provide 100% of its data using checksums or mirrors, the VDev will fail. - If any VDev in ZPool failed then entire ZPool is failed and can not be restored - ZPool: [vdev, vdev, …] (ZPool - same as Volume) - If ANY VDev in ZPool is failed then ENTIRE ZPool is corrupted and can not be restored! - It’s possible to add new VDevs to existing ZPool - Dataset: - ZFS File System is called a Dataset. It is layered above ZPool. - Может хранить непосредственно файлы - Может быть блочным устройством со всеми фичами нижележащих слоёв ZFS
- Отдельно ZIL: (ZFS Intent Log, дома нахуй не нужно)
- used for speeding up sync write (perhaps I don’t need it for home NAS)
- is a non-volatile write cache for zpool
- Write speed matters. SSD is recommended for it.
- SLOG - Separate SSD allocated for ZIL
Периферия
Источник бесперебойного питания
Смотри по отзывам и бюджету. Он необходим для NAS, если не хочешь наебнуть свой RAID.
Поддерживаемой им мощности потребителей должно быть с запасом относительно фактически подключенных к нему компонентов.
Нормальные упсы могут по usb сообщать компу о переходе питания с сети на батарею, когда электричество кончается. Рекомендую автоматически выключать NAS, когда батареи остается 40-60%, тогда тот успеет нормально сбросить кэши на диски и выключиться штатно, и не наебнет рейд.
Источники
NAS для дома своими руками: https://www.ixbt.com/storage/nas-howto-part2.shtml
Ограничения ZFS и введение: https://www.ixsystems.com/community/threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/
FreeBSD handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
