Введение
Мой первый опыт на Хабре получился не очень положительным, и, признаюсь, до сих пор смотря на комментарии и оценки, мне стыдно и больно где-то внутри.
Потому в имя исправления ошибок молодости решил написать серию статей о том, как дома собрать свою "идеальную" хранилку, или сервак, или мини облако. Поделюсь опытом, своими знаниями и пониманием, а также мыслями, которые могут помочь выполняя похожую задачу для себя.
Душная теория
Начну с программного обеспечения, и того, что есть два пути для решения задачи про свою домашнюю лабу:
Взять готовое коробочное opensources решение (примеры TrueNas, ESXi Free/ProxMox, OpenMediaVault, etc.) и строить свой проект на нем
Или взять голую OS (от FreeBSD до Alma/Rocky в наше время), и собрать из пакетов и opensource приложений что-то свое
Второй пункт это взято из цитаты коллеги, который так, в общем-то, и сказал. В тот момент моих знаний и опыта было недостаточно, потому я понял его слова как взять условный питон и написать свой гуй сам. В тот момент я думал, что программировать могут только боги.
Как правило, второй путь не будет иметь готового и красивого "ГУЯ" для того, чтобы через кнопочки решать все задачи и настройки, и, опять таки как правило:
Первый раз решение будет через гугл + терминальные команды
Второй раз повторяя шаги из пункта один, захочется их превратить в скрипт, чтобы не повторять команды (или вспоминать)
Третий раз, с учетом, что могут быть разные параметры и переменные, скрипты станут интерактивными, считай терминальный интерфейс своего самосбора
И четвертый, если повезет, со временем появится или найдется готовый контейнер или пакет, который в себе будет содержать все нужное для управления своим самосбором
Ну и не стоит забывать, что все опенсорсные "коробки" или даже коммерческие, это по сути также собранный линукс, с каким-то набором открытых пакетов, где из пропиетарного есть только и написанный ГУЙ для решения. Ну и ладно, набор настроик и оптимизаций, чтобы "коробка" работала лучше того же Линукса с теми же пакетами.
Далее немного базовой теории и истории для понимания того, как должно было бы выглядеть итоговое решение со стороны оборудования или железа, если бы мы были Ютуб блоггером или ИТ-энтузиаст с большим количеством "бесполезных денег".
Давайте рассмотрим схему сверху. Она полностью написана мной на основе того, что наблюдал на практике. Важно отметить, что он поверхостная, то есть без деталей и нюансов. Ну и, конечно же, если мы строим полноценное облако, то схемы будут явно другими. Здесь у нас собраны почти все уровни для своего датацентра:
сетевое оборудование для подключения всего между собой в отказоустойчивом формате
два активных сервера для вычисления (ВМ) с третьим, который будет резервным на случай падения одного из двух активных
два сервера хранения, в формате актив-пассив, где один собирает на себе данные, а потом реплицирует их на второй для сохранности
Почему так?
Ну с сетевым оборудованием понятно, если ломается один, все продолжает работать потому что есть второй. А сломанный на замену, по гарантии или нет.
Вычислительный слой, или Compute Server-а, всегда нужно будет наращивать по мере роста потребностей/бизнеса, потому тут стоит следовать схеме 2+1: два активных на один резервный, таким образом вычислительная мощь размазывается между двумя серверами для производительности и имеет место куда переехать, если оперативе или другому компоненту одного сервера стало плохо (не полностью упал, а частично недоступен).
Оборудование для хранения мы также вынесем в отдельный слой, чтобы не нагружать компьют часть нагрузкой по хранилищу, ну и "не держать все яйца в одной дорргой корзине". 1 к 1 у нас для того, чтобы у нас была полноценная реплика наших данных, потому что если, условно, нас посетят меньше клиентов, пока один из компьютов хостов сломан, - заработаем меньше, но бизнес будет жить. То если мы потеряем все данные, то, можно считать, что нет бизнеса (сюда же впишем ситуацию по пересбору данных при выпадении одного из дисков, массив будет работать явно медленнее, что скажется на бизнесе так или иначе).
Зачем нам такая "душная" теория? Опыт попытки построить дома свою самодостаточную инфру, привели меня от домашнего NAS-а на Celeron, до по сути такой же схемы на "минималках".
Выглядит она так:
Поговорим немного и о ней, и почему так сложилось:
Ранее на месте router-а у меня стоял Mikrotik hap_ac2. По мере роста того, что я кручу дома, то этой простой версии предназначенной для того, чтобы просто маршрутизировать и раздавать WiFi, уже стало не хватать.
Также, Mikrotik выполнял роль CapsMan, который управляет двумя точками доступа (APs), что создавало свою доп. нагрузку
Ну и Микрот был и своего рода свичем в свое время, что тоже не давало ему жить спокойно
В это схеме роль микрота будет выполнять Мини ПК с Алишки с 4 сетевыми интерфейсами. На нем развернем software firewall/router. Рядом на ВМ также Mikrotik CHR для CapsMan. Upstream кабель в оператора, и еще один кабель до POE Switch.
POE Switch у нас будет питать две точки доступа сразу (раньше это делалось через микрот адаптеры, и выглядит очень убого на самом деле, хоть и спрятано в шкафу).
По красиво проложенным в квартире кабелям питание пойдет до точек доступа и от одной кабель на балкон, где стоят основные "машины"
Гигабитный свич для передачи "интернета" по кабелю всем устройствам на балконе: Тандерболт док, игровой ПК, мини-ПК компьют, сервер хранения
10-Гигабитный свич будет жить отдельной сетью (VLAN-ом) только для стораджа для: МиниПК, игрового компа и самого сервера хранения.
То, к чему мы придем в последней главе этого рассказа, будет выглядеть примерно так как на второй схеме.
Посмотрев на нее, и убрав там локальные приколы, можно увидеть, что схема двух свичей с разнесенной нагрузкой (инет трафик и хранение), по отдельной машине на каждый уровень нас приблежают к идеальной схеме около-корп локального датацентра.
Часть первая. От NAS-а к первому домашнему серверу
О том, что такое NAS я узнал на первом месте своей работы. Там бизнес строился вокруг решения по бэкапу как корпоративной инфраструктуры (базы данных, ВМ, настройки гиперов), так и решений бэкапа ПК (по сути физические лица, или далее консьюмеры).
Ну и очевидно, что у второй категории пользователей как хранилище своих данных использовались NAS-ы от разных производителей, типа Synology, D-Link (тут если не ошибаюсь), условный Apple AirCapsule и другие.
К нам на работу тогда вышел человек, которого явно заразили лихорадкой Hyper-V от Microsoft, и он рассказал, как на старом железе (от одного из старых ПК) смог собрать Hyper-V сервер с кучей дисков, которые он отдал ВМ Xpenology (хакнутый Synology) и как это все дело круто.
Если оставить наркоманию с Hyper-V, то тогда мысль о своем домашнем хранилище показалась довольно соблазнительной:
на тот момент у меня был только свой мак ноут и игровой ПК
архив фото, видео и другого важного контента типа документов был внутри этого ПК на отдельном жирном диске, и если что-то с ОС этого ПК произошло бы (вирусы, популярные в то время шифровщики), то по сути прощай прошлое.
игровой комп как единственное оборудование с открытыми доступами для меня еще были и всякого рода Playground для первого знакомства с Linux, попыток установить MacOS на обычный ПК и прочее
ну и явно примеры проблем, это то, что я испытал, когда в поте лица пытался восстановить 4 ТБ диск с кучей фото моих маленьких брата и сестры всякими Recovery тулзами после неудачного опыта с линуксом
Идея во мне начала томится и выстрелила после того, как я вышел на новую работу (где у меня была ЗП х2 от прошлой), что мне дало возможность потратить немного денег на новый игровой комп (только с ССД) и отдельно на Мини ПК для хранилки.
Почему именно МиниПК, а не готовое решение от Synology? Ну во первых была инфа, что Synology можно запустить на чем угодно, и, соответственно, подготовить машину сильнее, чем продавалась самая топовая Synology в магазе.
Далее конечно же цена: такой же проц, но с х2 оперативной памятью, 1 ССД для ОС и новым 4 ТБ диском (для зеркала имеющегося) вышло дешевле, среднего готового устройства.
По сути сумма деталей вышла в 22300, тогда как аналог Synology (без диска и рама) был примерно 18-20 тысяч.
С железом определились, но наверное нужно, что то пометить:
по корпусу все ясно-понятно, купил самое дешевое + с БП и главное чтобы вместил 1 диск на 2 с половой, и 2 диска на 3 с половой
оперативная память тоже, от хорошего производителя но самая дешевая. По скорости и размеру самый максимум, что процессор сможет переварить.
С диском понятно, 4ТБ для зеркала уже бывшего у меня 4ТБ.
250 ССД для ОС, не просто так. Логика, что для ОС типа Линукс достаточно 64, 128 хватит с запасом. Но 250 было выбрано не просто так, и дальше станет понятно почему.
Ну и материнка с интегрированным процом. Во первых всякие Целероны для сборок поставляются только так, а именно эта мать и проц выбраны: Процессор на тот момент самый топовый целерон на рынке с поддержкой 4к через интегрированую видеокарту. У нее было 4-6 слотов для Сата, что было ок для расширений. И маленький PCI разъем для второй сетевой карты до 2.5 гига (но тогда это было просто космосом)
Почему я так легко согласился на такой масштаб бедствия?
Даже не смотря на наличие Нетфликса и Амазона, проблема с контентом в РФ все же была. Если мы и могли посмотреть сериалы кабельного американского ТВ на условном Нетфликсе, это происходило спустя полгода-год после начала нового сезона (по факту его завершения). Также у нас никогда не было нормального доступа до Disney +, а там только начал выходить хороший контент.
У меня какая-то автоматическая неприязнь к пиратским онлайн кинотеатрам, а особенно сгораю с неожиданной рекламы в середине серии, после которой обязательно нужно идти менять трусы, или же неделю в голове играет "ставки на спорт". Если по делу, качество и стабильность видео плееров на этих кинотеатрах, и тот стораджовый бек, что у них есть, не вывозят для получения качественного контента на своем 4k ТВ или iPhone-е.
Тут я узнал про "знак свыше" именуемый Plex (Plex Media Server), который позволял сделать свой, условный, Netflix для самого же себя из всего контента, что у тебя есть на диске (скачанный или купленный). Но такое решение хостить на своем компе было бы избыточно, а все NAS-ы Synology и остальных даже имели официальное серверное приложение.
Ну и конечно же, тк игровой комп у меня был полностью на SSD, качать торренты на него было не вариантом, соответственно отдельный мини ПК с приложением для скачки торрентов и обычными дисками было бы очень круто.
Итого:
скачивание контента и торрентов
трансляция контента со своего оборудования на свое же устройство (дома и вне)
хранения архивов и важных данных
ну и просто пространство для сохранения бекапов ПК перед разными тестами
Вот эти 4 причины заставили меня заказать перечисленное ранее оборудование в онлайн магазине. Далее была задача придумать, что же делать с ПО частью нового решения.
Так как моя первая работа была сильно связана с клиентскими VMware ESXi, то я не видел решения лучше, чем развернуть его на моем компике. Почему гипервизор? У XPenology были какие-то проблемы с выбранным мною оборудованием, потому решать проблему можно было только через гипер. Почему XPenology? Рассказы от коллеги на работе, ну и опыт того, что слышал от клиентов.
хотя уже в тот момент было решение получше, к которому мы с Вами придем в итоге
Ну и довольно богатая библиотека приложений для iOS: чат, медиа, фото и тд и тп
Итак план софта на новую железку:
Разворачиваем ESXi на диск в 250 ГБ и там же создаем датастор для нашей единственной ВМ
Разворачиваем ВМ из образа XPenology для VMware
Через скрипты PhotonOS настраиваем прямой линк "виртуального диска" Вари на физический диск
Настраиваем DSM, включаем торренты, плексы, смб и загружаем данные
Что, в общем-то и сделал.
Что было дальше?
Эксплуатация решения в начале была довольно скучной:
Активация фирменных приложений с нелицензионным сервером требовало усилий, но были инструкции
Запуск и установка левых приложений (например VMware Tools для DSM), также требовало танцев, но все было решаемо
Там же первый раз попробовал Плекс, но было ощущение, что, что-то не так
И тут случается ужасное: просто так во время копирования файла зеркало Synology разваливается. Я, как неопытный инженер, сразу начал смотреть в кошелек и на сайтах, где можно выгодно купить новый диск, но все же попробовав "пересобрать" сломанный массив, операция пошла и показывала, что все ок.
Нормально ответа на вопрос "почему", я не нашел, потому стал сам придумывать дыры или нюансы своего решения, чтобы найти им "улучшайзинг". И тут случайно я вспоминаю, что когда я баловался с Линуксом и ВМ с виндой на нем, была такая тема как Passthrough, когда ты не мапишь одно устройство на другое, а именно пробрасываешь целое PCI устройство внутрь OS ВМ.
Погуглив узнал, что у меня на 4 Сата порта два Сата контроллера, и один можно смело использовать для того, чтобы "железно" отдать диски Xpenology VM. Только после такого финта ушами, производительность стала еще хуже.
Вернув все взад, я принял решение пока не перегружать свою машинку и спокойно жил дальше.
Я слукавил, сказав, что только бытовые причины стали началом моего пути в домашнюю лабу. Главной причиной, как сейчас уже кажется, было желание быть таким как мой кумир на тот момент Linus из LinusTechTips, чьи видео в тот момент через раз и были о том, как собрать свой NAS из подручных средств.
Посмотрев очередную порцию Linus-а, я узнал о существовании ZFS, OpenZFS в вариации для всех Линукс платформ. И с учетом, что это был готовый пакет и решение для управления дисками и ФС внутри ОС (а именно непонимание mdadm-а в тот момент не позволяли мне сразу садится на Линукс и строить сторадж своими руками) я принял решение "мигрировать" с Xpenology/Synology на ZFS.
В тот момент из коробочных решений был только FreeNAS, который был мне в тот момент, не сильно понятен, так еще и на FreeBSD, о котором я только знал, что нужно "пропатчить KDE под FreeBSD" (и вообще не понимая, что тут каждое слово значит). У меня к моменту уже была хорошая практика с CentOS, а с Ubuntu я был знаком еще со времен тестов на своем компе.
Решено было создать вторую ВМ на моем мини ПК на базе Убунту. Перенести данные на временное хранилище, пересобрать ЗФС внутри Убунты и уже туда залить данные. Первую попытку я сделал вместе пробросом ПСИ устройства.
Оставить ESXi хотелось, чтобы было пространство создать какую-то временную ВМ для лажового теста, и не убивать свой "игровой ПК"
Но ровно как и с XPenology, проявлялись проблемы с производительностью "проброса", а также ГПУ-шка не была доступна для ВМ.
Прелесть была в том, с таким пробросом и без мапинга вирт. диска на железный, у меня была возможность просто установить Убунту вместо ESXi и импортировать мое хранилище.
Что я и сделал.
Plex установил из репы разработчика, нашел cockpit, некоторый GUI управления Линуксом. Далее к cockpit-у поставил набор плагинов для управления ZFS и просто дисками (типа SMART), спасибо 45Drives. Transmission прямо из Репы Canonical.
Далее возникла проблема, что мне приходилось подписывать на ТГ группы онлайн кинотеатров, и по уведомлениям отслеживать выходны новых серий сериалов, и руками через браузер добавлять в торрент трекер на скачку. А потому уже и руками все чистить. Ужас.
Немного гугла меня познакомило с решениями команды Servarr: Lidarr, Sonarr, Radarr, - каждый из контейнеров отвечает за свой типа контента (музыка, сериалы и кино). В него можно добавлять интересующие Вас произведения или группы, а приложение само потом отпарсит торрент трекеры, найдет нужную загрузку (можно указать максимальное качество, озвучку и прочее) и добавит ее в торрент клиент. А потом, когда захочется избавиться от просмотренного, удалит с ЖД.
Установка решений выглядела жестко, а вот альтернативная установка через Docker контейнер показалась довольно простой и удобной. Bash скрипт с серий docker run-ов и маунтов в пару минут построили для меня целое решение автоматизации получения контента. Далее, случайно, я узнал, что и Plex и Transmission также можно крутить в Docker, и тем самым описав идеальный софт запускать при переезде. Перенес и их.
Для Работы Servarr-ов надо было еще пару контейнеров (сам парсер торрент трекеров, который передавал данные, решение всяких челленджей и прочие сервисные контейнеры).
В этот момент я еще не знал, что Plex использовал интегрированную ГПУ для проигрывания 4к контента. И когда он был пакетом в Линуксе имел прямой доступ, а для контейнера через докер, нужно было делать маунт устройства и прочего. С этой частью я очень поздно познакомился. Делаю на этом акцент, потому что это будет одна из причин апгрейда.
И по сути началась жизнь, когда сторадж работал полностью сам в контексте загрузки контента в Плекс. СМБ шара доступная из локальной сети использовался для заливки архивов и бекапов. Всякие новые приколы и хотелки искались на докер хабе и добавлялись в монструозный на тот момент баш скрипт.
Да, да, о docker-compose я позжу узнаю сам
Но переход почти всех производителей контента на 4К, начало не позволять мне все смотреть без "прогрузок", а также свободного места со временем стало становится заметно меньше и меньше (а мы помним, что корпус вмещал ДО двух дисков 3,5).
