Команда запускает Proxmox-ноду под внутренние VM: когда нужен dedicated server и что проверить до установки

Многие команды начинают с нескольких VPS у разных провайдеров: один сервер под staging, второй под мониторинг, третий под тестовую базу, четвёртый под VPN, пятый под внутренние сервисы. В какой-то момент такая схема становится неудобной: доступы разбросаны, расходы растут, ресурсов не хватает, а управлять окружениями вручную уже тяжело.

Логичный следующий шаг — взять dedicated server и поднять на нём Proxmox VE для внутренних виртуальных машин. Это нормальная схема для команды, которой нужны dev/stage-окружения, тестовые стенды, мониторинг, CI/CD runners, VPN, bastion host, внутренние панели, базы для разработки и служебные сервисы.

Но Proxmox-нода на dedicated server — это уже не “просто один сервер”. Это маленькая внутренняя платформа. Если неправильно выбрать CPU/RAM, не понять сетевую схему, ошибиться с routed subnet или не иметь доступа к консоли, команда быстро получит инфраструктуру, которую сложно поддерживать и опасно перезагружать.

Когда Proxmox-нода на dedicated server действительно имеет смысл

Dedicated server с Proxmox подходит, если команде нужно регулярно создавать и удалять внутренние VM, быстро поднимать тестовые окружения, изолировать сервисы друг от друга и не покупать отдельный VPS под каждую мелкую задачу.

• Нужно несколько внутренних VM под dev, stage, QA, monitoring, VPN, bastion, backup, CI/CD runners.
• Команда хочет управлять ресурсами централизованно: CPU, RAM, диск, сеть, snapshots, шаблоны ОС.
• Нужно больше гибкости, чем даёт обычный VPS.
• Нужно быстро создавать временные окружения под разработку и тестирование.
• Нужно держать служебные сервисы отдельно, а не смешивать всё на одном Linux-сервере.
• Нужны публичные IPv4 для части VM и приватная сеть для внутренних сервисов.
• Нужен аварийный доступ через IPMI/KVM, если сеть или firewall настроены неправильно.

Если у команды всего один сайт, одна база данных и нет потребности в отдельных VM, Proxmox может быть лишним слоем. В таком случае проще взять обычный dedicated server или VPS/VDS и не усложнять архитектуру.

Главная ошибка: считать только количество VM

Нельзя выбирать сервер по принципу “нам нужно 10 VM, значит хватит любого dedicated”. Важнее понять, какие именно VM будут работать и что они будут делать.

Одна маленькая VM под bastion почти не потребляет ресурсов. А одна VM под CI/CD runner, Elasticsearch, ClickHouse, PostgreSQL или сборку Docker-образов может съесть больше CPU и I/O, чем пять обычных служебных машин.

Перед заказом dedicated server нужно выписать роли будущих VM:

• dev-серверы;
• stage-окружения;
• QA-стенды;
• мониторинг;
• логирование;
• VPN или bastion;
• GitLab runner или другой CI/CD runner;
• тестовые базы данных;
• внутренние панели;
• backup-сервисы;
• экспериментальные окружения.

После этого можно считать CPU, RAM, диск и сеть. Иначе команда почти гарантированно купит либо слабый сервер, либо слишком дорогую конфигурацию без понятной загрузки.

Как оценить CPU для Proxmox-ноды

Для внутренней Proxmox-ноды важны не только количество ядер, но и характер нагрузки. Dev/stage-серверы часто простаивают, а CI/CD, базы данных и аналитика дают резкие пики.

Если основная нагрузка — веб-сервисы, панели, тестовые окружения и небольшие базы, можно закладывать умеренный overselling CPU. Это нормально для внутренних VM, потому что не все они нагружены одновременно.

Если на ноде будут сборки, контейнеры, базы данных, индексация, обработка логов или тяжёлые тесты, запас по CPU нужен больше. Внутренний Proxmox не должен превращаться в место, где один CI runner тормозит все stage-сервисы.

Практичный подход:

• не выдавать каждой VM много vCPU “на всякий случай”;
• начинать с минимально разумного числа vCPU и увеличивать по метрикам;
• отдельно учитывать CI/CD и базы данных;
• не смешивать тяжёлые сборки и критичные внутренние сервисы без лимитов;
• следить за load average, CPU wait, steal внутри VM и загрузкой хоста;
• не забывать, что Proxmox тоже требует ресурсы для работы.

Как оценить RAM

RAM обычно заканчивается быстрее, чем кажется. Особенно если команда создаёт VM “временно”, а потом забывает их удалить.

Плохая практика — выдать каждой VM по 8–16 GB RAM без понимания реального потребления. Через месяц сервер будет выглядеть заполненным, хотя половина машин почти ничего не делает.

Нормальная схема:

• маленькие служебные VM: 1–2 GB RAM;
• обычные dev/stage веб-сервисы: 2–4 GB RAM;
• тестовые базы данных: 4–16 GB RAM в зависимости от объёма;
• CI/CD runners: 4–16 GB RAM в зависимости от сборок;
• мониторинг и логирование: считать отдельно, потому что они растут вместе с инфраструктурой;
• оставить резерв RAM под сам Proxmox и будущие VM.

Для внутренней ноды лучше иметь запас RAM, чем постоянно бороться с swap. Если VM начинают активно использовать swap, вся платформа становится медленной и непредсказуемой.

NVMe и storage: почему диск важнее, чем кажется

На Proxmox-ноду часто смотрят как на CPU/RAM-сервер, но storage не менее важен. Несколько VM одновременно пишут логи, обновляют пакеты, работают с базами, собирают проекты, делают snapshots и читают образы. Если диск слабый, вся нода будет ощущаться медленной.

Для внутренних VM лучше использовать NVMe. Если данные важные, нужно думать о зеркале, backup и восстановлении. Один быстрый диск без резервного копирования — это не инфраструктура, а отложенная авария.

Что учитывать:

• достаточный объём NVMe под VM, ISO, templates и snapshots;
• резерв по свободному месту, особенно если используются snapshots;
• мониторинг состояния дисков;
• backup важных VM на отдельное хранилище;
• разделение временных тестовых VM и критичных внутренних сервисов;
• понимание, что snapshots не заменяют backup.

Routed subnet: зачем она нужна для VM

Если части внутренних VM нужны публичные IPv4, удобнее использовать routed subnet или отдельный routed IP-пул. В такой схеме подсеть маршрутизируется на dedicated server, а Proxmox дальше отдаёт адреса виртуальным машинам.

Это часто лучше, чем пытаться вручную навешивать отдельные IP без понятной схемы. Но routed subnet требует аккуратной настройки: маршруты, bridge, forwarding, firewall и правила выдачи IP должны быть понятны до запуска VM.

Перед заказом сервера нужно уточнить:

• будет ли подсеть routed на сервер;
• какой gateway используется;
• какая netmask должна быть внутри VM;
• нужны ли дополнительные MAC-адреса;
• разрешён ли bridge-сценарий;
• как настраивается rDNS;
• есть ли фильтрация по MAC/IP;
• можно ли использовать приватную сеть между VM;
• как будет работать доступ к Proxmox-панели;
• есть ли IPMI/KVM для аварийного доступа.

Нельзя переносить конфиг сети с одного провайдера на другой вслепую. У разных дата-центров разные схемы: где-то IP выдаются как routed, где-то как on-link, где-то нужна привязка MAC, где-то запрещён простой bridge без дополнительных настроек.

Публичная и приватная сеть: лучше разделять сразу

Даже если все VM внутренние, не все они должны быть доступны из интернета. Хорошая схема — публичные IPv4 только там, где они действительно нужны, а остальные сервисы держать в приватной сети.

Например:

• bastion или VPN имеет публичный IPv4;
• Proxmox-панель закрыта по firewall и доступна только с доверенных IP или через VPN;
• dev/stage-сервисы доступны через VPN, reverse proxy или allowlist;
• базы данных не имеют публичного доступа;
• monitoring и logging доступны только внутри приватной сети;
• backup-сервисы не торчат наружу.

Это уменьшает площадь атаки. Внутренняя Proxmox-нода часто содержит ключи, тестовые данные, конфиги, токены и временные сервисы. Если всё открыть в интернет, проблема безопасности станет вопросом времени.

Консоль и IPMI/KVM: не дополнительная опция, а страховка

Для Proxmox-ноды аварийная консоль обязательна. Если команда ошиблась в network config, firewall, bridge или маршрутах, SSH и веб-панель могут стать недоступны. Без IPMI/KVM придётся ждать поддержки дата-центра или переустановки.

IPMI/KVM нужен для ситуаций, когда:

• сломалась сетевая конфигурация Proxmox;
• не поднимается основной интерфейс;
• ошибочно применён firewall;
• после обновления сервер не загрузился;
• нужно проверить boot screen;
• нужно подключить ISO или rescue-образ;
• нужно восстановить доступ без рабочей сети.

Если сервер используется как внутренняя платформа для команды, экономить на консоли нельзя. Один неправильный `ifreload -a` или reboot после сетевой правки может оставить команду без всех внутренних VM.

Минимальная схема Proxmox-ноды для команды

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

• dedicated server с достаточным CPU и RAM;
• NVMe storage с резервом по месту;
• Proxmox VE как гипервизор;
• публичный IP для хоста или отдельного management-доступа;
• routed subnet для VM, которым нужны публичные IPv4;
• приватная сеть для внутренних сервисов;
• VPN или bastion для доступа команды;
• firewall на уровне Proxmox и внутри VM;
• шаблоны Debian, Ubuntu, AlmaLinux;
• QEMU Guest Agent внутри VM;
• backup важных VM на отдельное хранилище;
• мониторинг хоста, VM, дисков и сети;
• IPMI/KVM для аварийного доступа.

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

Что нельзя размещать на одной внутренней Proxmox-ноде

Одна Proxmox-нода — это единая точка отказа. Если сервер выключится, обновление пойдёт неудачно или сломается storage, все VM на этой ноде будут недоступны.

Поэтому на одиночной ноде не стоит держать без резервного плана:

• единственный production database server;
• единственный backup server без внешней копии;
• единственный monitoring, который должен сообщать о падении этой же ноды;
• единственный VPN, через который команда может попасть на сервер;
• единственный DNS без вторичного сервера;
• критичные production-сервисы без понятного RTO/RPO;
• данные, для которых нет проверенного восстановления.

Для dev/stage и внутренних сервисов одиночная нода может быть нормальным решением. Для критичного production нужно либо строить кластер и внешние backup, либо размещать важные роли отдельно.

Как подготовить сервер перед установкой Proxmox

До установки Proxmox проверьте базовые вещи. Не нужно начинать с создания VM, пока непонятно, в каком состоянии железо и сеть.

lscpu
free -h
lsblk
ip a
ip r
ethtool eth0
smartctl -a /dev/nvme0n1

Проверьте, что включена аппаратная виртуализация:

egrep -c '(vmx|svm)' /proc/cpuinfo

Если команда возвращает 0, аппаратная виртуализация недоступна или отключена в BIOS/UEFI. Для Proxmox VE это критично.

Проверьте сеть:

ping -c 4 1.1.1.1
curl -4 ifconfig.me
traceroute 1.1.1.1

Если базовая сеть нестабильна до установки Proxmox, после настройки bridge/routed subnet проблема станет только сложнее.

Что проверить после установки Proxmox

После установки не спешите переносить все сервисы. Сначала проверьте хост, сеть, доступы и тестовую VM.

pveversion -v
systemctl --failed
ip a
ip r
journalctl -p err -n 100
df -h
free -h

Проверьте доступ к веб-панели Proxmox только с доверенных IP или через VPN. Не оставляйте панель открытой для всего интернета без ограничений.

Создайте одну тестовую VM и проверьте:

• получила ли VM нужный IPv4;
• работает ли default route;
• есть ли доступ в интернет;
• доступна ли VM снаружи, если это публичная VM;
• работает ли приватная сеть;
• работает ли QEMU Guest Agent;
• корректно ли выполняется shutdown/reboot из панели Proxmox;
• не ломается ли сеть после reboot VM и хоста.

Базовые команды проверки VM

Внутри Linux VM проверьте сеть:

ip a
ip r
ping -c 4 1.1.1.1
curl -4 ifconfig.me
resolvectl status

Проверьте QEMU Guest Agent:

systemctl status qemu-guest-agent

Для Debian и Ubuntu установка обычно выглядит так:

apt update
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

Для AlmaLinux:

dnf install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

После этого включите Guest Agent в настройках VM в Proxmox и перезагрузите VM, если это требуется.

Backup: что нужно решить до запуска VM

Snapshots удобны, но они не заменяют backup. Snapshot помогает быстро откатить изменение, но если умрёт диск, файловая система или вся нода, локальный snapshot не спасёт.

Для внутренней Proxmox-ноды нужен простой и понятный план:

• какие VM нужно бэкапить;
• как часто делать backup;
• где хранить backup;
• сколько дней хранить копии;
• кто отвечает за восстановление;
• как часто проверяется restore;
• какие VM можно пересоздать из шаблона и не бэкапить.

Не все VM одинаково важны. Временный dev-стенд можно удалить и пересоздать. База с тестовыми, но нужными данными, GitLab runner cache, monitoring history или внутренняя панель могут потребовать регулярного backup.

Мониторинг Proxmox-ноды

Минимальный мониторинг должен показывать не только “сервер жив”, а реальные риски.

• CPU load на хосте;
• RAM usage и swap;
• занятое место на storage;
• I/O wait;
• состояние NVMe/SSD;
• сетевой трафик;
• доступность Proxmox API или веб-панели;
• статус важных VM;
• ошибки systemd;
• ошибки backup;
• температуры и аппаратные события, если доступны.

Плохой мониторинг — это узнать о проблеме от разработчика, который не может зайти на stage. Нормальный мониторинг должен предупредить раньше: заканчивается диск, растёт I/O wait, backup падает, одна VM начала забивать CPU, диск показывает ошибки.

Частые ошибки при запуске Proxmox-ноды

• Ставят Proxmox без IPMI/KVM и теряют доступ после сетевой ошибки.
• Открывают панель Proxmox в интернет без firewall и allowlist.
• Не уточняют у провайдера, routed subnet или on-link схема используется для дополнительных IP.
• Копируют чужой `/etc/network/interfaces` без понимания gateway, bridge и маршрутов.
• Выдают VM слишком много CPU/RAM и быстро забивают сервер.
• Держат production и временные dev VM на одной ноде без приоритетов.
• Считают snapshots полноценным backup.
• Не ставят QEMU Guest Agent в VM.
• Не проверяют восстановление из backup.
• Не оставляют резерв IP и RAM под рост.
• Не документируют, какая VM за что отвечает.
• Не ограничивают доступ к внутренним сервисам через VPN или allowlist.

Как быстро починить типовые проблемы

Если после изменения сети пропал доступ к Proxmox, не делайте десятки правок вслепую. Используйте IPMI/KVM, откройте консоль и проверьте конфигурацию:

ip a
ip r
cat /etc/network/interfaces
systemctl status networking
journalctl -u networking -n 100

Если VM не выходит в интернет, проверьте маршрут внутри VM:

ip a
ip r
ping -c 4 gateway_ip
ping -c 4 1.1.1.1

Если gateway пингуется, но интернет не работает, проверьте DNS и маршрутизацию. Если gateway не пингуется, смотрите bridge, routed config, firewall и правильность IP/netmask.

Если Proxmox показывает VM, но не видит IP-адрес внутри гостевой системы, проверьте QEMU Guest Agent:

systemctl status qemu-guest-agent

Если VM медленно работает, проверьте хост:

top
free -h
iostat -xz 1 10
df -h
qm list

Если закончилось место, не удаляйте случайные файлы в storage вручную. Сначала посмотрите, что занимает место: backups, ISO, templates, snapshots или диски VM.

Как HSTQ может помочь

HSTQ может подобрать dedicated server под Proxmox-ноду для внутренней инфраструктуры команды: с подходящим CPU, достаточным объёмом RAM, NVMe-дисками, IPMI/KVM для аварийного доступа и routed subnet для виртуальных машин.

Если части VM нужны публичные IPv4, лучше заранее обсудить сетевую схему: сколько IP нужно на старте, будет ли routed subnet, какие VM должны быть публичными, какие останутся во внутренней сети, нужен ли rDNS и как команда будет получать доступ к Proxmox-панели.

Для команд, которые запускают dev/stage, monitoring, VPN, CI/CD runners и служебные VM, правильнее брать сервер не “по минимальной цене”, а с запасом по RAM, NVMe и консольному доступу. Дешёвая конфигурация без IPMI/KVM и нормального storage может стоить дороже уже при первой аварии.

Перед заказом можно написать в Telegram @hstq_hosting или открыть тикет и описать задачу: сколько VM планируется, какие роли у VM, сколько нужно публичных IPv4, нужна ли приватная сеть, какой объём RAM и диска ожидается, будет ли Proxmox использоваться только для внутренних сервисов или также для клиентских VPS.

Хорошая Proxmox-нода начинается не с установки панели, а с правильного выбора сервера, сетевой схемы, доступа к консоли, правил backup и понимания, какие сервисы можно держать на одной ноде, а какие лучше вынести отдельно.