Proxmox VE: Финальные Советы, Оптимизация и Идеи для Проектов (Часть 10)

Финал: десять советов, которые я выстрадал

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

Сразу скажу, почему я вообще взялся писать этот список. Когда я только ставил Proxmox, в интернете было полно статей «как установить», но почти нигде не было честных рассказов про то, что делать дальше и где поджидают грабли. Все советы ниже — не теория: каждый я проверял на своём железе, и половину из них — на собственных ошибках.

Шаг 32: 10 советов по оптимизации

1. VirtIO для всего. Диски и сеть виртуалок я ставлю строго на VirtIO-драйверах. Эмуляция старых устройств — это потери скорости и лишняя нагрузка на процессор. Разница видна глазом, особенно на сетевом трафике.
2. CPU type = host. При создании VM выбираю тип процессора host, чтобы гость видел настоящий процессор с его инструкциями. Иначе внутри виртуалки не заработают некоторые современные оптимизации, и всё будет заметно тупее.
3. Не жадничайте с памятью. Выделять виртуалке больше RAM, чем есть на хосте, — плохая идея. Переподписка работает, но когда все начнут есть одновременно, начнётся свистопляска. Я теперь выдаю только то, что реально нужно, и держу запас.
4. LXC вместо VM, где можно. Для лёгких сервисов — Pi-hole, базы данных, nginx — я использую контейнеры, а не виртуалки. Контейнер ест в разы меньше памяти и стартует за секунды. Виртуалки оставил только там, где нужна настоящая изоляция.
5. Не включайте дедупликацию ZFS. Это самый коварный совет: звучит красиво, но съедает оперативку (примерно гигабайт на терабайт данных). Я включил, полюбовался на цифры экономии и тут же выключил — выигрыш не стоит рисков для памяти.
6. QEMU Guest Agent обязателен. Ставлю агента в каждую VM ещё с третьей части курса. Без него нельзя нормально выключить или заморозить виртуалку, а при миграции он нужен позарез.
7. Memory Ballooning — с умом. Настройка, которая позволяет Proxmox забирать неиспользуемую память у одной виртуалки и отдавать другой. Включаю, но оставляю минимум, чтобы гость не умирал от голода.
8. Отдельная сеть для кластера. Если у вас кластер — служебный трафик (Corosync, миграции) я держу на отдельном интерфейсе. Так и меньше помех, и безопаснее.
9. Сжатие в бекапах. В задачах бэкапа включаю сжатие Zstd — бэкапы занимают заметно меньше места и качаются быстрее. Одна настройка, а приятно каждый раз.
10. Обновляйтесь. Прописная истина, но я ею пренебрегал, пока не поймал известную уязвимость. Теперь у меня стоит напоминание: раз в месяц обновить Proxmox и гостей, и ночью система сама делает снапшот перед этим.

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

Отдельно поясню про четвёртый пункт, потому что он чаще всего вызывает вопросы. Когда я впервые увидел, что можно ставить сервисы в контейнеры, я не поверил: думал, что это «то же самое, но без изоляции». На деле контейнеры в Proxmox — это полноценные маленькие системы, просто они делят ядро с хостом. Для Pi-hole, баз данных и веб-серверов этого достаточно, а памяти они едят на порядок меньше виртуалок. С тех пор правило простое: не нужна своя ядро и своя ОС — бери LXC, нужна — бери VM.

А по пятому пункту добавлю драматичную историю. Я включил дедупликацию на пуле с бэкапами, потому что цифры экономии были красивые: почти сорок процентов. Через неделю сервер начал «тормозить», и я с удивлением увидел, что оперативная память забита под завязку. Дедупликация держит таблицу указателей в RAM, и на терабайтах данных это начинает кушать память литрами. Выключил — и сервер снова дышит. С тех пор мой девиз: «если не знаешь зачем тебе дедуп — тебе он не нужен».

Шаг 33: что я запускаю на сервере

Раз уж курс закончился, расскажу, что реально живёт у меня на Proxmox — может, пригодится как идея.

• Plex — домашняя медиатека. Фильмы и сериалы доступны на телевизоре и телефоне, а трансляции идут прямо с сервера.
• Home Assistant — умный дом: свет, датчики, сценарии. Живёт в отдельной VM, чтобы не утянуть за собой остальное при экспериментах.
• Pi-hole — DNS-фильтр рекламы для всей домашней сети. Поставил в LXC, память почти не ест, а польза каждый день.
• OPNsense — шлюз и брандмауэр сети в отдельной VM. Проброс портов, сегментация — всё это теперь управляется виртуально.
• Nextcloud — файлы и фото, доступные откуда угодно. Плюс галерея и заметки.
• Docker + Portainer — десяток мелких сервисов в контейнерах: мониторинг, боты, всякие помощники. Portainer делает управление наглядным.

Расскажу подробнее про пару из них, потому что они дают больше всего удовольствия от эксплуатации. Plex, например, я сначала воспринимал как «ещё один плеер», а оказалось — целая медиатека с обложками, описаниями и историей просмотра на всех устройствах дома. А Home Assistant стал моим любимым конструктором: добавил датчик температуры — придумал сценарий для климата; повесил датчик движения — настроил свет в коридоре. Никакого «умного» облака от производителя, всё своё и всё локально.

Кстати, про Pi-hole: я боялся, что DNS-фильтр что-нибудь сломает в домашней сети, и долго откладывал. В итоге поставил за пятнадцать минут, и за неделю он отбил рекламу на всех устройствах — включая телевизор, который до этого пичкал меня рекламой при каждой заставке. Единственное, о чём жалею, — что не сделал это раньше.

Главное, чему я научился за весь курс: сервер нужен не ради сервера, а ради сервисов, которые он держит. Сначала определитесь, что вам нужно, а потом поднимайте виртуализацию под это.

Заметил закономерность: каждый новый сервис на сервере тянет за собой два-три сопутствующих. Поставил Pi-hole — захотелось посмотреть статистику запросов. Поднял мониторинг — захотелось алерты в мессенджер. Это нормально, сервер обрастает как дом мебелью. Главное — не превращать его в свалку: у меня заведено правило, что любой сервис, который не использовался месяц, — кандидат на удаление. Звучит жёстко, но это единственный способ не утонуть в своих же экспериментах.

И ещё про правило месяца: удалять — не страшно, если есть бэкап. Я всегда оставляю снапшот удалённого сервиса на пару недель: вдруг вспомню, что пользовался им чаще, чем казалось. Пока что ни разу не понадобилось, зато рука удалять набилась легко, и сервер остаётся лёгким и отзывчивым.

Прощание

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

Про virt-инфраструктуру можно говорить бесконечно — виртуализация, контейнеры, кластеры, автоматизация. Если захотите углубиться, у меня есть большой материал, где собраны ссылки на каждую часть этого курса и другие статьи про Proxmox: вот он.

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

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

Если захотите поделиться своим опытом или спросить совета — добро пожаловать в комментарии под любой частью курса, я стараюсь отвечать. А если захотите поддержать развитие блога и этого курса — буду признателен, но главное, чтобы вам было полезно. До встречи в следующих статьях!

Все части курса:

• Как я поставил Proxmox на старый системник и не пожалел (Часть 1)
• Настройка и запуск первой виртуальной машины (Часть 2)
• QEMU Guest Agent и продвинутая интеграция VM (Часть 3)
• Мгновенные сервисы с LXC-контейнерами (Часть 4)
• Настройка резервного копирования (VZDump) (Часть 5)
• Настройка брандмауэра для защиты VM и хоста (Часть 6)
• Мониторинг ресурсов и оповещения (Часть 7)
• ZFS — снимок, целостность и отказоустойчивость (Часть 8)
• Кластеризация и высокая доступность (HA) (Часть 9)
• Финальные советы, оптимизация и идеи (Часть 10)

Спасибо, что были со мной! Всё получится, и ваш сервер будет жить долго и счастливо.

Что я забрал с собой из всего курса

Перед тем как поставить точку, подведу короткий итог того, что реально изменилось в моей жизни после всех этих статей. Раньше я хранил файлы по компьютерам и облакам, боялся обновлять что-либо и молился, чтобы диск не умер. Теперь у меня есть единый дом для всех сервисов: медиатека, умный дом, файлы, мониторинг и почта живут под одной крышей, а данные защищены снапшотами и бэкапами. Я перестал бояться экспериментов: любой опыт откатывается за секунды, если рядом со снапшотом.

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

Перед прощанием — маленькая таблица «что для чего», которую я часто рекомендую новичкам. VM берите, когда нужна своя операционная система, полная изоляция и не страшно потратить гигабайты памяти. LXC — когда сервис лёгкий и вы хотите, чтобы он запускался за секунды и ел минимум. Общее хранилище — когда планируете миграции и кластер. ZFS — когда данные дороже железа. Запомнив эту простую раскладку, вы будете выбирать инструменты почти интуитивно, как я сейчас.

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