Добрый день. Сейчас сижу на Хренолоджи на довольно неплохом железе, выполняются задачи получения бэкапов с удаленных серверов по протоколу webdav, крутится вирт машина с HAOS, а так же медиасервер для квартиры + куча всякой мелочи (торренты и тд), но есть несколько проблем (от обновлений хрени до неправильного корпуса). Заказал новое железо буду переезжать на него.
Почти все что нужно приехало и время собирать сервак. Конфигурация такая: Мать ASROCK B550M PRO4, камень AMD Ryzen 5-3600, 128 гб Памяти, 4 диска по 16 + 4 диска по 8, есть еще видяшка ее тоже в него воткну. В материнке 2 слота под М2 ssd у меня их есть целый набор от 512 до 2 тб.
Первым делом нужно перевести на новый сервер ночной поток бэкапов (webdav) и виртуалку с HAOS, далее все к чему привык - это докер (vaultwarden, torrserve, jellyfin и тд). ОС планирую proxmox 9 (9ка нужна потому что я сразу не смогу поставить все 4 диска по 16 и создать пул, 2 диска стоят в хренолоджи и на них данные, которые я не готов терять, и диски будут переезжать в новый сервер последовательно после переноса данных). Так же буду ставить immich для домашних фото. Вопрос как правильно его ставить при условии проброса к нему видяшки.
Нужны советы и мнения на все мной заявленное, Выбор железа конечно не обсуждается, его мне не поменять. Но вот правильно ли я выбираю ОС(может нужен Truenas), каким образом распорядится портами М2? Нужен ли кэш М2? На какой диск ставить ос и тд.
На вкус и цвет все фломастеры разные, как говорится, но вот мое мелкое ИМХО
- Принципиально разницы между 8 и 9 PVE нет, но если добавлять диски и диски же “приземлять” в самом PVE, то да есть смысл взять 9ку, но это будет ОЧЕНЬ ОПАСНЫЙ переезд, в идеале перенести данные на внешнее хранилище и пересоздать рейд с нуля, а не по одному диску
- В идеале поднять на виртуалке стенд и выполнить на нем все операции т.к. есть шанс на проде что-то сделать не так и потерять все данные
- В целом, можно диски закинуть в пул Proxmox, но мне нравится идея с поднятием в proxmox виртуалки с truenas, причем, можно в 1 порт m2 воткнуть m2 → sata переходник (например, типа такого) и пробросить его как PCI устройство в truenas и в нем уже собрать пул, а в truenas рашить по NFS и iSCSI. Просто в truenas много функционала по работе с ZFS и шарами вынесено в веб интерфейс, в PVE я не уверен, что можно добавить special vdev без консоли.
- Ну и еще раз подумать над вариантом сбора рейда в truenas или proxmox, судя по описанной схеме Вам проще будет 2 вариант, но с шарингом хранилища между виртуалками могут быть проблемы и надо будет ковырять ручками, например, если поднять jellyfin для библиотеки и отдельно контейнер в qbittorrent и чтобы они работали с одним датасетом
- По поводу вариантов проброса видеокарты я писал тут, но сейчас с этим вообще нет проблем, если использовать LXC, то новый синтаксис позволяет вообще черз веб морду пробросить устройство
- ПО поводу m.2 кеша я сейчас сам в процессе изучения вопроса и подбора железа, но он может дать хорошие результаты, но надо добавлять special vdev в ZFS, а оно имеет несколько особенностей
5.1. Добавить можно, удалить потом уже нельзя
5.2. Потеря special vdev приводит к потере всех данных, надо ставить как минимум 2 ssd в зеркало, например, можно либо в 2 м2 вставить по nvme или в один оставшийся m.2 вставить sata переходник и в него уже SATA диски в зеркало
5.3. Размер надо сразу расчитывать, мне gpt написал скрипт для подсчета размера этого диска - OS можно поставить куда угодно, можно и на рейд, но с развалившимся рейдом не получится стартануть proxmox, но тут хватит и SATA SSD на 64ГБ за 1000р т.к. нагрузка на него минимальная, ну или 2 по 64 в зеркале для железобетонной надежности, а потом уже после установки PVE подключить диски и собрать отдельный пул под виртуалки и данные
- С учетом jellyfin и immich, я бы ставил драйвера видеокарты на хост, jelyfin и immich ставил в контейнеры и пробрасывал видеокарту в них
Они должны быть в одном контейнере? Или в разные контейнеры можно видяшку прокидывать?
Правильно ли я понимаю? На чистую машину ставлю proxmox, создаю виртуалку nruenas, отдаю ему 4х16 диски.
m2 → sata пока не нужен есть 6 sata порта
У статье про LLM расписывал, если это не серверная nvidia, которую можно драйверами “нарезать” на виртуальные GPU, то в контейнеры можно сколько угодно раз пробрасывать видюху, а в виртуалку пробрасываеься только 1 раз эксклюзивно, после чего, она даже из хоста пропадает
Соответственно, либо поднимать одну виртуалку и в нее пробрасывать видюху и весь софт по работе с ней или можно в несколько независимых контейнеров
Да,
Но надо понимать, что в такой схеме производительную нарботу LXC контейнеров на TrueNAS у меня не получилось запустить.
Я не претендую на истину в первой инстанции, но вижу 2 варианта реализации
У меня кластер из 1 мощного мини ПК, 2х средних и 2х овощей (последний чисто для кворума и что-то по мелочи, он был как сервер печати, но поставил туда pve для единого управления и кластера)
Вариант 1
- Вставить NVME на 512-2TB и поставить туда систему, обычно под саму систему выделяет proxmox до 100ГБ, но у меня есть и 64ГБ, по сути, больше и не надо
- Остальное место на NVME после системы выделить под виртуалки и контейнеры
Вот у меня 2ТБ - 100ГБ под local, но тут 200ГБ фоток, которые планирую вынести на внешнее хранилище, на этой ноде у меня 50 контейнеров и виртуалок
2.1. NVME для виртуалок прям хорошо, если их крутить на общем HDD рейде, то IOPS будет бутылочным горлышком, особенно при десятке виртуалок
2.2. Сами по себе сервисы занимают мало место, особенно если поднимать их в alpine - Добавить виртуалку с TrueNAS и пробросить туда 4 диска, собрать рейд
- Опционально воткнуть SSD и тоже проброить их в truenas и добавить их как ZFS special vdev
- Создать в truenas датасеты
5.1. для фоток
5.2. для медиабиблиотеки
5.3. для HA backups
5.4. Для файлов PVE (типа distrib с iso образами и т.д.)
5.5. Для proxmox backup server
5.5. что-то для себя - В truenas настроить пользователей и SAMBA шары для доступа к файлам + NFS шары для доступа из виртуалок + снепшоты, для защиты от случайного удаления файлов, например, у меня фотки, документы и прочее каждые сутки создаются снепшоты и хранятся неделю
- Подключить ручные NFS шары из proxmox в PVE вида
/mnt/truenas/photos(через редактирование/etc/fstab) - Подключить NFS шары в PVE через datacenter (у меня это
tuenas-data)
- Поднять контейнеры для immich, jellyfin, qbittorrent и т.д.
9.1. Вот тут у меня 20 ГБ под систему, реально занято 6
9.2. Проброшено 2 каталога из хоста в контейнер, а в госте они подключены на 7 шаге
9.3. Проброшена видеокарта для кодирования - Поднять sftpgo или в контейнера PVE или в виде приложения truenas (у меня пока 2 вариант), подключить в него шару из пункта 5.3. и включить webdav
- Поднять виртуалку с HA и настроить бекапирование на пункт 10
- Поднять вируалку с PBS и внутри добавить NFS шару из пункта 5.5. и настроить бекапирование виртуалок и контейнеров в PBS
- Опционально через proxmox-backup-client настроить бекапирование файлов в PBS
Вот тут у меня сервер аудиокниг сами книги хранит на truenas, делает бекап в файл в 0:00 а в 2:07 этот бэкап заливается в PBS
services:
audiobookshelf:
image: ghcr.io/advplyr/audiobookshelf:latest
ports:
- 13378:80
environment:
- TZ=Europe/Moscow
volumes:
- /mnt/audiobooks:/audiobooks
- ./metadata:/metadata
- ./config:/config
restart: unless-stopped
proxmox-backup-client:
image: fdrake/proxmox-backup-client:latest
env_file: .env
environment:
- BACKUP_TARGETS=backups.pxar:/mnt/backups
- CRON_SCHEDULE=07 2 * * *
- CUSTOM_HOST=abs --ns apps
- TZ=Europe/Moscow
tmpfs: /tmp
volumes:
- ./metadata/backups/:/mnt/backups
restart: unless-stopped
Плюсы
- Быстрые виртуалки, но относительно медленные файловые хранилища
- За счет разделения на софт и данные IOPS HDD рейда не будет терятся на системные операции, а только на доступ к файлам (фотки, видео и т.д.)
- Многослойная и масштабируемая система, можно легко добавить еще ноды в PVE кластер
Минусы
- Относительная сложность реализации
- Потенциально можно потерять виртуалкуи на NVME накопителе, но у вас остается 2 вида бекапов на PBS и при желании можно легко развернуть
Вариант 2
- Воткнуть NVME и поставить туда PVE по аналогии с вариантом 1
- Воткнуть диски и собрать рейд из ZFS
- Я тут расписывал пошагово работу с ZFS в PVE
3.1. Создаете в рейде виртуалки или контейнеры для сервисов
3.2. Создаете в рейде руками датасеты и используете их по аналогии с 7 пунктом из 1 варианта, т.е. прокидываете датасет в фильмами в 2 контейнера: immich и qbt - Поднимаете виртуалку или контейнер для SMB шары, чтобы по сети иметь доступ и по пункту 3.2 настраиваете доступ, т.е. получается, что вы на хосте создаетев консоли датасет, его прокидываете в SMB шару и шарите по сети и его же прокидываете в jellyfin контейнер для доступа к файлам через медиаплеер
Далее по аналогии в вариантом 1
Плюсы
- Нет доп прослойти в виде TrueNAS, а это точка отказа
- Выше производительность рейда в контейнерах т.к. нет NFS прослойки
- Может проще настраивать
Минусы
- Часть фуннкций по работе с ZFS надо будет делать в консоли т.к. Proxmox дает только базовый функционал, например, создание общих датасетов для доступа их нескольких вируалок, снепшоты, SSD кеширование
- Из коробки нет SAMBA и NFS шары, тут надо или поднимать отдельный контейнер или в каждом сервисе настраивать свою шару, например, ставите в контейнер с jellyfon samba + cockpit и настраиваете доступ к медиахранилищу по SAMBA
- Все еще можно потерять виртуалки при потере NVME диска
Вариант 3
- Сразу ставите диски в сервер и устанавливаете PVE на этот рейд
- Далее, по аналогии с вариантом 2 все настраиваете
- Упираетесь в IOPS рейда и вставляете 2 NVME диска в сервер и добавляете их как mirror special vdev в ZFS
Плюсы
- Максимальная надежность т.к. все всегда в рейде
- Самое простое решение, не надо заморачиваться с разными типами хранилища т.к. все в рамках одного пула
Минусы
- Самая низкая производительность виртуалок т.к. упираемся в IOPS рейда
Вариант 4
- Ставите все в сервер
- Устанавливаете туда TrueNAS
- Ставите jellyfin, vaultwarden из магазина приложений
- Ставите HA в виртуалку в TrueNAS
- Ставите webdav приложение в TrueNAS и указываете его в HA в качестве системы для бекапов
Плюсы
- Максимальная простота
- В теории самая высокая производительность за счет самого близкого доступа к данным
Минусы
- У Вас не будет PVE и PBS
- Может быть будут проблемы с гибкостью настройки приложений и виртуалок
- Не сильно отличается от Xpenology в плане подхода, но при этом без штатного софта
Очень подробно. Аплодирую стоя.
Данных у меня 17тб. Видится мне очень сложным скопировать их на временный носитель.
Я хочу попытаться сделать так. Собираю систему, ставлю все по вашему совету - proxmox на ssd, truenas на виртуалку. У меня в системе 2 диска по 16 тб, их я отдаю трунасу, под ним создаю zfs raid с 1 избыточным диском, получаю 16тб свободного места и начинаю копировать (не переносить) данные. Далее я могу выдернуть из хренолоджи еще один 16тб диск (при этом хренолоджи будет ругаться все статусы будут красными, но данные будут доступны) поставить в новый сервер отформатировать и отдать трунасу для добавления в пул в итоге я получу уже 32тб места на трунасе. Далее уже можно переносить (не копировать) остатки данных и убедившись в том что все перенеслось и работает на новом месте можно разбирать хренолоджи и добить пул до 48 тб.
План выглядит немного рисковым и ненадежным, но уже были моменты когда выходил из строя диск на хренолоджи, и в красных статусах я жил пару недель - все сохранилось и работало. Возможно стоит дополнить план сохранением самых критичных данных (где то у меня в закромах есть 8тб диск)
Я лучше от truenas откажусь.
Нравится пока 1 и второй вариант. Но отдавать диски напрямую трунасу. Правильно ли это? В заявленных мной необходимых задачах именно бэкапы через webdav. И здесь трунас как будто нужен только для того чтобы установить из под него приложение.
Что я понял? SSD кэш мне не нужен (Если потеряю содержимое кэша, развалится и пул).
Я думаю, что им стоит доверять
- Есть Cache vdev, там можно потерять его в любой момент, но проблема в том, что он хорошо работает если у вас много данных, но работаете с малым количеством, у меня, например, во время проверки бекапа, который больше, чем размер кеша, из HDD на SSD переносился весь бекап, т.е. читает его с HDD, отдает PBS файлы и записывает их на SSD для дальнейшего чтения, потом на SSD место заканчивается и он перезаписывает старые данные новыми, по факту, из SSD кеша данные не читаются, а только пишутся.
- В сценарии, например, если есть архив ISO образов всех виртуалок, но устанавливаете систему только из нескольких образов, то эти образы будут в SSD кеше и профит будет + GPT говорит, что SSD кеш рекомендуется только если количество оперативки больше 32ГБ
- Если SSD используется в качестве special vdev, т.е. хранит только метаданные и маленькие файлы, то при наличии большого количества файлов вы получаете просто афигенный прирост скорости работы с массивом, вот видео, но при потере SSD диска рейд на выброс, поэтому настоятельно рекомендуют SSDшники ставить в зеркало, чтобы при выходе из строя одного система продолжила работать на втором и хватило времени на замену вышедшего из строя
Если только бекапы и по-мелочи, то в вашем случае нет смысла в truenas, просто у меня вот так выглядят датасеты
У меня сейчас 9 SAMBA шар, 21 NFS шары, 1 iSCSI таргет и 3 датасета подключены к приложениям внутри truenas.
Поэтому выбирайте между 2 вариантом как самым производительным и 3 как самым надежным
А можно ссылку на статью про LLM?
Нужно учитывать, что на не-ентерпрайз видеокартах до 3000 серии нвидии можно нарезать только рендер-компонент
Cuda и ускорители 264 и 265 будут работать только в хосте (а в большинстве случаев вообще отключатся, как на моей 1080ti).
Минимальная карта, на которой можно нарезать cuda и кодеки - Tesla M60
Про серию 4-5 не в курсе.
Я бы ставил SSD кэш в zfs только если есть возможность взять новые SSD Intel optane.
2шт optane в mirror между собой, потом этот mirror добавлять как кеш девайс.
В pve 8 это только в консоли делается, в 9 не смотрел.
На 1 Гбит сети какой-либо разницы в работе не увидите.
Главное - настройте уведомления на ошибки smart и zfs на почту или в телегу - спасет от головной боли, проверено лично
jellyfin у меня привилегированный, но я давно еще пробовал разные варианты, ковырял довольно таки долго чтобы запустилось. LXC контейнер с ubuntu и подключением репозиториев с jellyfin + ffmpeg их.
Может по свободе попробую сменить решим, но помню, что там выключается он легко, а выключается правильно через бекапирование и разворачивание в новом режиме, иначе, начинаются проблемы с правами на системные файлы.
Immich непривилегированный сразу запустился вообще без проблем, он у меня в докере работает и по инструкции все завелось
Вот еще вышло видео с пошаговыми инструкциями по разворачиванию truenas внутри PVE при использовании HBA контроллера. Может кому-то пригодится.