Для тех, кому лень читать предыдущие части — я переходил с HP Microserver Gen8/Windows Server на самосборный сервер с Unraid в качестве базовой ОС. Unraid — это коммерческая ОС для NAS/домашнего сервера на базе ядра Linux. Основные возможности — гибкое управление массивом дисков, удобная установка докер-контейнеров из своего каталога и возможность запуска виртуальных машин. Почему выбрал именно unraid — написано во второй части.

Я не буду здесь расписывать установку и настройку unraid. Это делается элементарно — просто закидываются файлы на флэшку, флэшка вставляется в сервер — можно пользоваться. Всё понятно расписано у них на сайте, плюс много полезной информации есть на youtube-канале Spaceinvader One. Какие-то ранние вещи там уже устарели, потому, если видите несколько видео на одну тему, выбирайте более свежее. Ещё понятные доки на эту тему у ibracorp, есть и youtube-канал, если буквы не любите.



А я лучше просто опишу, как выглядят теперь перечисленные во второй части сервисы.

• Мой новый домашний сервер, часть 3: немного о сборке
• Мой новый домашний сервер, часть 2: выбор софта
• Мой новый домашний сервер, часть 1: выбор железа

Файлопомойка

Тут всё стандартно — samba. Я потерял возможность руления правами доступа на папки-файлы — из коробки тут только правами на шары можно управлять. То есть если раньше у меня была шара «пользователи», а в ней были папки «пользователь1», «пользователь2» и т.п. с разными владельцами, то теперь вместо этого надо создать шары «пользователь1», «пользователь2»…

Впрочем, это вполне обычно для самбы, ACL редко какой из дистрибутивов по-умолчанию включает и делает полноценную поддержку. Для дома это терпимо, у меня пользователей человек пять, так что можно просто шар добавить, не запутаемся.

Чисто теоретически, и тут можно попытаться включить ACL, но я читал на форумах про проблемы, с этим связанные. Большинство людей наоборот, отключают ACL и удаляют их хвосты, чтобы исправить проблемы с правами доступа. Но, как уже сказал — переживу и привыкну. Можно сказать, что почти ничего не изменилось. Было десять шар, станет двадцать. Не смертельно.



Не в тему: Truenas Scale у меня с полпинка вошел в виндовый домен и позволил раздавать права на файлы, используя доменных пользователей и группы. В своё время в OMV подобное потребовало гораздо больше телодвижений и общения с консолью.

Объединение дисков и отказоустойчивость

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

Я знаю три решения, которые всё перечисленное позволяют без серьёзных танцев с бубнами:

1. Windows + Drivepool (и аналоги). Это и использовал на старом сервере.
2. Unraid. Это я начал использовать на новом сервере.
3. Linux + aufs/mhddfs/… + snapraid. Это чисто теоретическое знание, но когда дойдут руки — хочу попробовать собрать такой массив на базе OMV и поиграть с ним.

Всё остальное либо позволяет только менять диски на такие же, либо только увеличивать массив, добавляя диски. А вот уменьшить массив с сохранением информации — это функция очень редкая.

Объединение дисков и эффективная ёмкость

На микросервере у меня было 4 диска общей ёмкостью 3+5+6+8=22 терабайта. Учитывая дублирование папок (около 5 терабайт), эффективная ёмкость была 22-5=17 терабайт. На новом сервере я (пока) смог добавить ещё два диска — 3 и 8, но при этом одна восьмёрка ушла под диск для контрольных сумм (парити-диск), то есть эффективная ёмкость стала 3+3+5+6+8+8-8=25 терабайт.

В drivepool я бы получил на этих же шести дисках 28 терабайт (учитывая дублирование папок). Но восьмитерабайтный диск в unraid у меня защищает весь массив, а не конкретные папки на нём. Плюс, если я в драйвпуле захочу защитить не пять терабайт, а десять, то эффективная ёмкость массива станет 23 терабайта (так как 10 уйдёт на дублирование). А на unraid ничего не изменится. Потому я не особо страдаю от того, что целый диск отдаётся под контрольные суммы (точнее, сперва было страдал, потом посчитал и успокоился).

Кстати, к вопросу об использовании SMR-дисков: массив вида JBOD — в отличие от разных RAID'ов — позволяет спокойно использовать любые диски с учётом их технологии. Просто не надо ставить SMR под активную запись — и все будут довольны. К примеру, у меня сигейты на 6ТБ и 8ТБ — SMR. И можно посмотреть по количеству READS и WRITES, как активность на массиве устроена. С SMR практически только чтение идёт, запись минимальна. А вот Toshiba 8ТБ — это CMR-диск, потому и стоит под парити. Потому что туда только запись идёт, чтение бывает только во время проверки массива или ребилда диска.

Защита информации

При потере одного диска в drivepool я теряю информацию только с этого диска, за исключением дублированных папок — их копии остаются на других дисках массива.
При потере двух дисков теряется информация с двух дисков. С дублированием — как повезёт, смотря где именно были продублированы файлы. Но если боитесь вылета двух-трёх и более дисков — можно настроить хранение любимых файлов хоть на всех дисках массива. Но тогда они займут во столько же раз больше места.
Понятия «ребилд» у drivepool нет, так что потерять ещё один диск от повышения нагрузки на остальные шансы невелики.

В unraid защита работает не на конкретные папки, а вообще на весь массив. И при потере одного диска никакая информация не теряется.

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

Понятие «ребилд» тут имеется. Может ребилдится либо парити-диск, либо подменный диск взамен пропавшего из массива. Так что шансы потерять второй диск от повышения нагрузки имеются, как и на классических рейдах. Но на остальных дисках данные уцелеют.

Хотя всё это не повод полагаться на средства защиты разных видов массивов и не делать бэкапы. Бэкапы наше всё! Делайте бэкапы — и ваши файлы будут мягкими и шелковистыми.



Это была реклама бэкапов, за которую мне заплатили производители бэкапов.

Изменение массива

Добавление диска

В drivepool, чтобы добавить диск, вы вставляете в компьютер новый диск, нажимаете кнопку «добавить» и диск в массиве. Через некоторое время на него переедет часть информации с других дисков согласно правил балансировки. Если на диске была какая-то информация, то она там и останется. Просто будет «за пределами» массива и с ней можно будет работать прямым обращением к диску.

В unraid добавление диска — это деструктивное действие. При добавлении диск забивается нулями — чтобы не пересчитывать контрольные суммы и не терять.



Время, занимаемое на добавление диска, зависит от скорости записи на диск. Обычно примерно полтерабайта в час, то есть терабайтник будет добавляться около двух часов, десятитерабайтник — около 20. SMR-диски, наверное, будут добавляться дольше, но я таким способом ещё не пробовал их добавлять.

Потому что есть второй способ, который позволяет не чистить добавляемый диск. Надо подключить диск к системе, при помощи плагина Unassigned Devices отформатировать диск в файловую систему вашего массива (у меня — xfs), затем:

1. Остановить массив, извлечь парити, запустить массив.
2. Остановить массив, добавить новый диск, запустить массив.
3. Остановить массив, вернуть парити, запустить массив, дождаться ребилда.

Это звучит страшно, но на деле делается довольно быстро — за исключением последнего пункта. Потому что ребилд парити тоже идёт со скоростью примерно полтерабайта в час. И при больших дисках занимает много времени, у меня на восьмитерабайтнике — от 16 до 18 часов.

Активность дисков в начале процесса ребилда парити-диска:


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

Отчёт о завершении:

Notice [FRACTAL] — Parity sync / Data rebuild finished (0 errors)
Duration: 18 hours, 32 minutes, 31 seconds. Average speed: 119.9 MB/s

На время ребилда у вас массив остаётся без защиты. И на все диски идёт нагрузка на чтение, потому пользоваться сервером в этом время затруднительно. Я пробовал копировать в этом время файлы с массива на ssd — получалось 200-300 килобайт в секунду.

Но я так делал из-за того, что, во-первых, мне не хотелось мучать SMR-диски полной записью. А под парити у меня стоит CMR, он это всё проще переносит. Во-вторых, я переливал информацию со старого сервера через эти SMR-диски. То есть сперва их цеплял вне массива, форматировал в xfs, потом по сети туда перекачивал файлы и уже заполненный диск втыкал в массив.

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

Но наличие парити-дисков в массиве не обязательно, он вполне может только и из data-дисков состоять:


Будет только напоминать о том, что нет парити, но при этом будет спокойно работать:

Удаление диска

В drivepool диск удалялся нажатием кнопки «удалить диск». После этого информация автоматом переносилась на другие диски и диск удалялся из массива. Время зависело от объёма информации. Можно было сэкономить, не перенося дублированные файлы (потому что вторая копия оставалась на других дисках и потом во время прохода балансировщика дублирование восстановилось бы). Либо можно было принудительно извлечь диск, вообще ничего не перенося — если ждать не хотелось. Иногда были вопросы с открытыми в приложениях файлами, надо было их закрыть и повторно запустить извлечение диска.

В unraid, чтобы извлечь диск из массива, нужно: остановить массив, создать новый массив без извлекаемого диска (на забыв поставить галочку «сохранить настройки»), дождаться ребилда парити. Информация при этом остаётся на вынимаемом диске, потому, если он нужна, надо её куда-то перенести руками или специально обученными плагинами (unbalance, например).
Есть второй вариант, который позволяет извлечь диск без ребилда, но он требует зачистки извлекаемого диска и я его не пробовал. Описывается в вики на сайте.

Замена диска

В drivepool понятия замены диска нет, это решается через удаление старого диска и добавление нового. Можно наоборот, так быстрее будет. Учитывая простоту добавления-удаления, отсутствие «замены» проблемой не является. Объём дисков значения не имеет.

В unraid именно заменить диск можно только на такой же или больший по объёму. Замена на меньший — только через удаление старого и добавление нового.

1. Остановить все сервисы, которые пишут на массив напрямую, отключить автозапуск докеров и виртуальных машин, если они живут на массиве, отключить автозапуск массива (не обязательно, но лучше перебдеть).
2. Остановить массив, извлечь диск из массива, запустить массив — чтобы он понял, что диска у него нет.
3. Выключить компьютер, заменить диск физически, включить компьютер (если у вас нет поддержки замены дисков на лету). После включения массив должен быть в состоянии «остановлен», если автозапуск не забыли отключить.
4. Добавить диск в массив вместо вынутого, запустить массив, дождаться ребилда диска. Если диск больше по размеру, то файловая система будет автоматом растянута.

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

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

---

Качалка торрентов

Как уже писал, раньше у меня был Vuze. Мне вообще много не надо от торрентов сегодня — закинуть торрент-файл в папку и получить скачанное через некоторое время. Желательно ещё с алертом «скачалось». Это любой торрент-клиент умеет. Конкретно Vuze я выбрал из-за того, что у него есть плагин для поддержки нескольких пользователей, у остальных клиентов подобное поведение сложнее реализовывалось.

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


Пока два, себе привычный deluge, не себе — красивый qbittorrent с упрощённой темой.

---

Медиасервер

Plex был, Plex остался. Запустил контейнер, подсунул ему базу со старого сервера, указал новые пути к библиотекам — и всё заработало по старому. Полёт нормальный. Транскодинг видеокартой не проверял, потому что нет её у меня пока что. Процессором транскодит не хуже, чем было раньше.

---

Виртуальные машины

Насколько я понял, в качестве движка виртуализации тут используется KVM. Вроде раньше был XEN, но некоторое время назад поменяли. Вообще, управление виртуалками — это не самое сильное место unraid, и если для вас это основное требование к домашнему серверу — то лучше глянуть на специализированный гипервизор.

А в unraid нет снапшотов, нет встроенных бэкапов, нет кластеров и т.п. Автоматизированные бэкапы можно организовать при помощи плагина, но он при создании копии останавливает машину. Снапшоты, в принципе, тоже можно скриптами сделать (или virt-manager прикрутив), но всё же это костыли, которые при регулярном использовании системы в качестве гипервизора смогут достать.

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

Тестовая виртуалка с десятой виндой работает без вопросов, линукс тоже без проблем запустился. Видеокарту пока же не пробрасывал за отсутствием таковой, но SATA-контроллер пробросился без проблем вместе со всеми дисками. А вот с пробросом usb-флэшки были вопросы, она не отображалась в списке доступных устройств — пришлось прокидывать её не как usb-устройство, а как raw-диск, прописыванием прямого пути в /dev/disk/.

Короче говоря, тут не всё так безмятежно, как хотелось бы, но вполне приемлемо, на мой взгляд. Эта задача для сервера тяжелая (частично из-за неё и был затеян апгрейд), но лично для меня не основная, потому возможностей unraid мне хватит.

---

Сервер бэкапов

Тут я попробовал перейти с veeam на urbackup. Мне давно хотелось централизованно видеть состояние бэкапов на разных своих компьютерах, а с бесплатным veeam этого было не увидеть. Пока мнения нет, пробую ещё.

Синхронизацию отдельных папок с декстопов-ноутов на сервер решил попробовать настроить на syncthing для единообразия, особенно в плане ноутов полезно, которые не обязательно дома могут быть, а настраивать-включать vpn и т.п. не всегда хочется. Я syncthing когда-то пользовался, но у меня тогда как-то его работа совпала с запиливанием диска на сервере, на котором у него папки хранились (несколько тысяч бэдов довольно быстро возникло), потому я от него отказался. Может и не он виноват был, но вот совпало.

Из непонятных вещей, которые сами прошли — сперва я unraid в ожидании заказанной материнки гонял на Athlon X4 940/A320/8GB. И там скорость передачи файлов по локалке через syncthing была заметно меньше 100 мегабит на гигабитной сети. При этом особенно загрузки процессора не наблюдалось. Потом я к вопросу вернулся уже после того, как закончил все железные разборки — и скорость стала приемлемой, в районе 800 мегабит. Но с того времени и дисков в массиве добавилось, и ссд под кэш появились, и материнка сменилась, и процессор трижды… Так что я не могу сказать, что конкретно это было.

В облако (onedrive) по прежнему бэкаплюсь duplicati — разве что поменял настройки времени хранения бэкапов (раньше просто стояло «последние Х версий», сейчас поставил правило «за неделю хранить ежедневные бэкапы, месяц — недельные, год — месячные, вечно — ежегодные». Но, конечно, это зависит от частоты изменения в файлах и всё строго индивидуально. Плюс у меня десятки заданий бэкапов (а не все терабайты одним заданием), так что где данные изменяются почаще, можно и другие правила поставить.

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

Плюс размер файла бэкапа увеличил с умолчальных 50 мегабайт до 300 мегабайт, хотя, конечно, это тоже зависит от того, что именно бэкапишь. У меня основное содержимое — это фото в RAW'ах размером в районе 20 мегабайт. Так что в одном архиве получается 10-15 фото, вместо двух.

Из тонкостей касательно именно докера/unraid — duplicati сперва делает архивы в /tmp, затем только их качает. И, если при небольших файлах проблемы незаметны, то вот при более крупных у меня быстро забился docker.img. Пришлось прокинуть из хоста папочку для /tmp

Duplicati пока что перекачивает бэкапы в облако, потому стабильно кушает процессор на упаковку-шифрование (я отвёл четыре ядра) и будет кушать ещё неделю, не меньше. Закончит — успокоится.



Плюс прикрутил через rclone свой терабайт на mail.ru и решил с ним синхронизировать некоторые вещи, к которым иногда хочется иметь доступ, не «компрометируя» домашний сервер. Музыка, книги, может какое-то видео… Расшаривать оттуда какие-то файлы, подцеплять через О: Драйв и т.п. Ну и лишняя копия не помешает, учитывая то, что эти данные не относятся к тому, что я регулярно бэкаплю.

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

---

Удалённое рабочее место

Поскольку больше работать непосредственно на сервере не могу, придётся завести себе личную виртуалку для этой задачи, как и товарищу раньше, благо ресурсов теперь побольше стало. Как вариант — можно настроить guacamole для доступа к рабочим столам через веб, без vpn или проброса портов.

---

Хостинг

Здесь будет много изменений. Если раньше был просто прокинут порт на вебсервер в виртуалке, то теперь прокинутых портов будет много. Хотя про много проброшенных портов — это я загнул, вполне хватит 80/443 и nginx proxy manager'а. Но вот поднять дома несколько сервисов, типа bitwarden для паролей и т.п. я давно собирался. Теперь это всё делается гораздо проще, чем под виндой. Технически можно было и там, но тут всё же проще.

---

Заключение

Тут я думал было написать что-то про используемые плагины unraid, планы на добавление сервисов (всякие там автокачалки, конвертилки и т.п.), но решил, что смысла нет — это опять бы превратило пост в очередную инструкцию, чего мне не хочется. Взгрустнётся — напишу отдельно, как окончательно всё оформлю.

Так что просто кратенько подведу итог — я доволен получившимся решением. Конечно, у него есть и недостатки — куда без этого. Но, в комплексе, unraid меня полностью устраивает.

Основное, что «мешает» в сравнении со старым — это изменившаяся идеология использования, но тут ничего не поделаешь — я всё это знал, так что остаётся только привыкать и изучать. Тот же докер мне не только дома пригодится, по работе тоже не помешает. Слишком долго откладывал. Хотя, конечно, без опыта работы с докером ставить готовые контейнеры из библиотеки unraid гораздо проще, чем в консоли пытаться понять, каким концом надо воткнуть apache в php, чтобы оно потом заработало с mysql.