Идея моего домашнего self-hosted окружения - хочу критику и советы

2. Сервера cамохостят
, , , ,
21

Всем привет!

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

Обкатал тестовый стенд и решил делать по-взрослому. Хочу собрать фидбек, пока ещё можно всё поправить без боли.

Глобально подход к развертыванию такой - сервисы, которые не живут вне ВМ, развертываем как VM.
Всё остальное разворачиваем как LXC. Portainer оставляем как песочницу чисто за удобство, но не для пользования.

Железо

Aoostar WTR Pro

  • Ryzen 7 5825U
  • 32 Gb DDR4-3200
  • M.2 NVMe 1 Tb — под систему
  • 4 × WD Blue 1 Tb — под данные

:one: Хранение

M.2 NVMe (1 Tb)

Просто стандартная разбивка local / local-lvm.
Не знаю, зачем мне 100 Gb local, которые создаются по умолчанию.
Может есть советы как поступить?

HDD (4×1 Tb) → ZFS RAIDZ1 — данные и бэкапы

ZFS pool: data

Папки

data/backups      → PBS datastore (локальные бэкапы)
data/shared       → общие данные для нескольких LXC
data/services     → данные сервисов (внутри папки по именам хостов)

Storage в Proxmox

  • local-lvm — VM / LXC rootfs (NVMe)
  • backup-data
    • Тип: Directory
    • Путь: /data/backups
  • shared-data
    • Тип: Directory
    • Путь: /data/shared
    • используется для bind mount
  • shared-services
    • Тип: Directory
    • Путь: /data/services
    • используется для создания папок под файлы

:two: Сеть и доступ

  • Доступ извне только через VPN
  • Из-под VPN открыт только Nginx Proxy Manager (443)
  • Все сервисы доступны только через NPM
  • Защищено Let’s Encrypt wildcard сертификатом
  • В LAN ничего не режу
  • Аварийный доступ:
    • на Keenetic есть ручной доступ к PVE (8006) через приложение

image
image909×771 123 KB

:three: Управление и мониторинг

  • ProxMan (лучшее, на мой взгляд, мобильное приложение для iOS. Может есть другие варианты?)
  • WebGUI Proxmox
  • Планирую:
    • уведомления (Telegram / почта)
    • SMART + ZFS alerts
    • уведомления о фейле бэкапов

:four: Бэкапы

Основной механизм — Proxmox Backup Server

  • PBS развёрнут в виде отдельной VM на этом же Proxmox VE
  • Datastore PBS:
    • HDD
    • ZFS dataset data/backups
  • Бэкапятся:
    • VM
    • LXC
    • их конфигурации
  • Datastore PBS не публикуется наружу

Offsite-копии

  • Для хранения вне сервера используются Kopia / Duplicati
  • Они выгружают копии PBS-datastore:
    • во внешнее облако WebDAV (диск)
    • с клиентским шифрованием

Для внимательных читателей - сейчас можно на 1 год получить бесплатно 1 Тб хранилища Сбера (надеюсь @admin не будет ругаться, Сбер мне не платит):

  1. Переходим по ссылке Диск
  2. Авторизуемся по Сбер ID
  3. Введите промокод JINGLEBYTES
  4. профит

Схема:

VM / LXC
   ↓
Proxmox Backup Server
   ↓
ZFS (data/backups)
   ↓
Kopia / Duplicati
   ↓
WebDAV (encrypted)

Бэкап Proxmox VE

  • Бэкап /etc/pve
  • Хранится:
    • в PBS
    • уходит во внешнее облако через Kopia / Duplicati

:five: Shared storage между LXC

  • Используется bind mount (через GUI не работает, только через CLI, так?)
  • Общий dataset data/shared
  • Проброс в несколько LXC через mp0
  • UID/GID синхронизированы между контейнерами
  • SMB не используется (один хост, нет Windows-клиентов). как будто TrueNAS это сильное усложнение, но если хочется делать бэкапы Mac наверное придется и его развернуть или есть какая-то шара попроще)

Сценарии отказов (закладываю заранее)

Рассматриваю следующие ситуации:

  • Отказ NVMe (M.2)
    Proxmox VE и local-lvm недоступны, данные сервисов остаются на HDD.
    План: чистая установка PVE → восстановление конфигурации → подключение данных.
  • Отказ одного HDD в RAIDZ1
    Пул остаётся доступен, замена диска и resilver.
  • Полный отказ сервера
    Восстановление на новом железе из PBS + offsite-копий.
  • Временная недоступность облака
    Локальные бэкапы в PBS продолжают выполняться, offsite догоняет позже.

Интересует, есть ли в этой схеме слабые места или неочевидные точки отказа.

Вопросы к сообществу

  1. Как вы бэкапите сам Proxmox VE?
    Достаточно ли /etc/pve или есть смысл бэкапить что-то ещё?
  2. PBS в виде VM на одном хосте — есть ли подводные камни?
  3. Локальные бэкапы VM на том же ZFS пуле — ок или плохая идея?
  4. Bind mount vs SMB для шаринга данных между LXC на одном Proxmox — есть ли кейсы, где SMB реально выигрывает?
  5. Как вы изолируете доступ?
    VPN / VLAN / jump host / вообще без доступа из LAN?
  6. Что бы вы изменили в этой схеме ДО выхода в прод, если бы собирали её сегодня?

P.S. Постарался проработать пост и написать свое видение четко, но лаконично, чтобы уважаемому читателю было комфортно.

Всех с наступющим НГ!

4 лайка
22

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

В классическом подходе гипервизоров их бэкапить не надо, но с PVE лучше бэкапить таки и тут у меня есть несколько вариантов

  1. Бэкапирование /etc/pve не только для быстрого восстановления, но и для отката
  2. Но, вместо этого лучше реализовать кластер, хотя бы из еще одного миника и малинки (для кворума)
  3. Изменения в хосте не напрямую, а при помощи Ansible и ему подобных, у меня есть соответствующий плейбук, который подготавивает PVE ноду к работе (там NFS шары, мониторинг, сетевые хранилища, и т.д.)

Лучше на разных, но у меня в виде LXC контейнера на ноде с NAS, в идеале и по производительности и по безопасности лучше держать отдельно, но чтобы не писать подобные посты можно пойти на компромис и поставить PBS в виде LXC контейнера на сервер с дисками

Не пробовал, но сомневаюсь, что SMB может иметь хоть какие-то преимущества кроме маппинга ID пользователей, т.к. я ссылку не буду прикладывать, но я тут расписывал как работает LXC и Docker и mp это прям минимальный оверхед, меньше 1%

Я тут расписывал в нескольких местах, но если кратко, то

  1. VLAN и бриджи на уровне PBS и фаерволом на роутере
  2. jump host на L7 уровне в ввиде Komodo periphery и Traefik
    И тут mp для LXC реально кааааайфовые, тащюсь от них, например, у меня PVE находится в SRV vlan c MTU 9000 и доступом к NFS шаре, а lxc контейнеры в эту сеть не ходят, в итоге qbt контейнер получает mp шару с медиафайлами, но доступа ни в локалку ни к NAS не имеет, по сети он может только в интернет ходить, и тут безопасность прям крутая, если рассматривать вариант с монтированием SMB шары внутри контейнера, то он должен иметь сетевой доступ к NAS

Та с этой схемой можно хоть сейчас в прод, на самом деле

Чтобы я еще добавил

  1. Добавил бы один миник и одноплатник для кворума и кластера, чтобы при падении основного сервера можно было запустить хотябы основные сервисы на втором минике + в этом случае нет смысла в бэкапировании /etc/pve т.к. оно размазывается по всем нодам кастера, вы берете голый PVE, вводите его в кластер и он поучает свою копию всех настроек
  2. TrueNAS в данной схеме не кажется уже оверинжинерингом, я про него писал тут, если кратко, то что можно получить с ним
    2.1. Все фишки ZFS + NVMEoF/iSCSI для проброса виртуалок по сети на другую ноду клстера
    2.2. Из коробки репликации, снепшоты + облачная синхронизация, т.е. буквально парок кликов /data/backups выгружаются в сберобако
    2.3. С добавлением узлов в кластер, а я рекомендую держать кластер, с ним проще будет шарить контент по сети, либо через /etc/pve/storage.cfg, либо у меня ansible роль раскатывает NFS шары по всем нодам
1 лайк
23

Роман, спасибо за обратную связь!

:rofl:

По PVE есть такой скрипт - годнота или так себе?
Ну мне отказоустойчивость не особо важна на текущем этапе - пока я не отказался от облачных сервисов и будет некий “переходный” период, когда я буду и тем и тем пользоваться и критичные вещи дублировать.
В будущем может возьму что-то попроще для полноценного кластера, но это пока дело не этого месяца, а может и года.
Ansible для меня пока что темный лес - не было нужды использовать на практике.

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

Тогда сразу возникает вопрос - пул ZFS будет создавать и управлять TrueNAS или мы создаем его в PVE, а TrueNAS только управляет?
СберОблако работает чисто через веб-морду, это скорее файлопомойка. В моем случае будет Я.Диск, т.к. у Mail есть приколы в работе WebDAV. Тогда Kopia/Duplicati отлетают (при условии, что шифруются данные). Про шифрование локальных дисков я пока забыл, т.к. по Вашим же словам никакой TPM нам не поможет в данном случае или я неправильно понял.

Спасибо за участие в моем словоблудии, но как мне кажется, лучше рассмотреть проблему со всех сторон до того, как начать делать, а потом переделывать. :grin:

24

@KRom, а в части железа можно попросить поделиться экспертизой?

Спасибо!

25

Его в ТГ группе обсуждали, если не ошибаюсь, то я делал беглый разбор и по его мотивам написал вот этот скрипт

В TrueNAS прокидываются диски и он создает пул, далее по NFS/SMB шарятся на PVE хост каталоги или по iSCSI/NVMEoF прокидываются блочные устройства

Ну тут есть смысл если будет несколько нод, для одного сервера однозначно проще и производительней будет использовать ZFS на хосте, тут сразу намного проще становится. В моем же случае У меня нет привязки пула к нодам и даже больше скажу: у меня N150 под TrueNAS/PBS/QBT/Jellyfin/Syncthing (ну этот просто мало потребляет), а остальные сервисы крутятся на других миниках, т.е. у меня NAS и самые дисконагруженные сервисы вместе, но не боллее

Обидно, что не умеет webdav, а то я бы взял, я сейчас на Я.Диск зеркалирую

Я про TPM ничего не писал, сам пока не заморачивался на эту тему

Даже не знаю, чем можно поделиться

26

Я скорее про то, что при использовании условного LUKS пароль надо вводить при старте (это Вы писали выше), а про TMP мои домыслы, исходя из моих знаний на данный момент.

Изначально он там был, но потом выпилили

27

C TPM это должно работать нормально, LUKS для системного диска да, надо вводить пароль при запуске, если шифровать другие диски, то вот короткая тема, суть в том, что ключ шифрования доп. дисков лежит в открытом виде на загрузочном диске + есть приколы всякие с настройкой, но работает

С другой стороны, ZFS тоже умеет шифрование пулов и датасетов

28

а для чего так усложнять доашнююю сеть, очень ценные данные?

29

А о каком усложнении Вы говорите?
Как бы Вы сделали?

30

Тут вопрос, пожалуй, не в ценности данных, но и в этом тоже, сложности компрометации системы.

У меня были ребята, которые не успевали развернуть проект на VPS как redis и co взламывали боты, а дальше запускался либо процесс майнинга, либо распространия внутрь системы.

Поэтому, есть общая практика выносить публичные сервисы в DMZ, так, чтобы в случае успешного брутфорса злоумышленник оставался в сервисе, а не получал открытого доступа к локальной сети, где очень часто есть незащищенные другие сервисы, всякие docker-compose часто публикуют во вешку СУБД и прочие стандартные сервисы или без аутенификации или с базовыми паролями.

Я недавно делал отладку одного сервиса, начал слушать порт у себя на компе и пытались проверить отправку запросов на него, так через полчаса мне начали приходить команды на скачивание и установку каких-то прошивок, выполнение команд. Сейчас сканируются весь интернет с завидным постоянством и если находится открытый порт, или веб интерфейс, то боты начинают ломиться по справочникам сервисов и уязвимостей

Поэтому, в плане безопасности нет такого уровня паранойи, который был бы выше реальной угрозы.

31

я верно понимаю, что если хост один, TrueNAS это VM, в которую мы пробрасываем физические диски, создаем ZFS, а его уже отдаем обратно в Proxmox как SMB?

32

Да, все так, с потерей производительности на сетевых протоколах

33

спасибо.
а есть ли смысл пробрасывать его напрямую по NFS в PBS минуя PVE?

34

Я пробрасывал как NFS шару в PBS vm, потом перешел на TrueNAS → PVE NFS → PBS MP и производительность выросла в разы, но некоторым не нравится это (тут должна быть ссылка на ТГ обсуждение)

VM
Плюсы:

  • Автономность, можно переносить между нодами без необходимости монтировать шару на хосте
  • Работает весь заявленный функционал
    Минусы?
  • Производительность

LXC
Плюсы:

  • Производительность
    Минусы:
  • Для идеала надо удалять ряд пакетов
  • На некоторых вкладках, например, настроек сети вылазит ошибка т.к. не весь функционал работает в непривилегированном контейнере

Альтернативные варианты

  1. Привилегированный контейнер, чтобы было меньше ошибок, но хуже безопасность
  2. VirtioFS в VM в теории работает очень хорошо, по тестам скорости приближаются к нативным

Но опять же, нужен ли TrueNAS в данной схеме? Если один сервер, то может быть хостить диски на самом хосте и пробрасывать в контейнеры и виртуалки

  1. это будет явно лучше в плане производительности
  2. не будет проблем с блочными устройствами для виртуалок
35

TrueNAS подкупает 3 вещами:

  1. удобством работы с шарами (SMB, NFS)
  2. возможностью сразу “из коробки” клонироваться в удаленный WebDAV, давая возможность удаленных копий
  3. управлением ZFS пулом

но схема с TrueNAS в PVE создает накладные расходы, которые хочется урезать.
в моей голове было так, что LXC с PBS ходить в VM с TrueNAS гораздо быстрее напрямую, чем через PVE…

тут, если я понял, все равно будет быстрее, т.к., по сути, трафик не делает петлю через роутер, а потом уже и через vmbr0, а идет сразу по bridge?

в целом интересует вопрос проброса пула из TrueNAS в контейнеры и VM. вроде как NFS закрывает все вопросы, но всё же..

36

Трафик и так и так не ходил через роутер а замыкался на бридже.
Тут рекомендуется почитать вот эту тему, особенно последние комментарии по cgroups

LXC
Если кратко, то петля TrueNAS → PVE NFS → PBS MP на самом деле не является петлей.

С точки зрения процессора и операционной системы NFS шара на PVE хосте становится доступной PBS практически без каких-либо накладных расходов, для нее просто предоставляется доступ процессам внутри PBS без виртуализации и прочих вещей т.к. процесс LXC контейнера работает на хосте PVE, а устройства внутри LXC контейнера являются устройствами хоста

При этом мы используем общий файловый кеш на уровне хоста, общий драйвер NFS на уровне ядра ОС и на минимальном уровне изоляции ЦП

VM
Когда мы говорим про TrueNAS → PBS VM → NFS, то вроде бы петли нет, но…
Мы имеем петлю на уровне гипервизора т.к. NFS шару все равно обслуживает процессор хоста, но внутри виртуального окружения, модули ядра PBS все равно находятся на определенном уровне изоляции ЦП, путь это и не так критично в последнее время за счет использования паравиртуализации

При этом, файловый кеш тоже виртуализируется, без балунинга использование оперативной памяти и кэша становится не столь эффективным

А обработчик работы с сетью находится внутри планировщика виртуалки, которая внутри планировщика хоста, получается этакая матрешка

Условно
Можно представить оперативную память и файловый кеш в виде футбольного поля и футболилстов

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

В случае с виртуалкой и выключеным балунингом мы получаем футбольное поле, где игроки могут двигаться строго в отведенных для них участках, например, как в настольном футболе. Пока одни игроки отдуваются по полной другие будут ходить в своей зоне и ждать мяча. Например, выделили 2ГБ для PBS и он пытается тасовать там чанки резервных копий в то время, как Helper Scripts Local со своими 2ГБ оперативки загрузил все скрипты в свой файловый кеш и тако ждет когда же вы откроете его страницу для установки очередного сервиса и будет держать у себя этот файловый кеш все доступное ему время и его вообще не волнуют проблемы других виртуалок.

Но как можно понять из этой многоходовочки: VM дает пусть и худшие результаты, зато предсказуемые т.к. если для виртуалки были выделены ресурсы, то она сама распоряжается ими и когда понадобится выполнить запрос в БД этот запрос выполнится за предсказуемое время т.к. данные загружены в оперативную память. С LXC/OpenVZ может оказаться так, что платим мы за 2 ядра 2 гига, а по факту, другой контейнер выгрузил нашу БД из памяти и пытается съесть весть процессор.

Собственно, поэтому раньше OpenVZ виртуалки были дешевые, а KVM/Xen раза в 1.5/2 дороже, но потом все хостинги перешли на KVM именно по причине нормальной изоляции и гарантированных ресурсов без падений (надо понимать, что оверсеинг ресурсов имеет место быть, но с процессором это легче и решается “тротлингом”, а с оперативкой получаем уже не тормоза а OOM ошибки и негатив от клиентов)

Фух, что-то я разогнался…

2 лайка
37

Роман, это и ценно.
Мы же все тут делимся идеями, опытом и знаниями.
Так что спасибо за подробный рассказ.

Сервак уже едет, жду не дождусь когда все раскатаю. Пока на тестовом оттачиваю конфиги и думаю о том, как заменить все сервисы своими.

38

при тестах выяснилось, что файлы больше 1 Гб не проходят и отдается 413 ошибка.
есть фикс, но он временный.

разбираюсь

39

Это Cloud Sync Tasks на community?
Я на mail.ru пока не покупал место, в яндекс лил 5ГБ файлы нормально

40

Оно самое

image
image1468×424 26.3 KB

image
image892×716 21.6 KB

сейчас попробую на Яндексе