Proxmox удобен для VPS, staging, лабораторий и внутренней виртуализации. Ноду нужно выбирать по сумме VM, а не по одному самому крупному гостю. Эта статья нужна не для выбора “самого большого” тарифа, а для подготовки заказа: какие компоненты разнести, какие метрики снять до оплаты и что проверить перед переносом production.
Когда подходит
- Proxmox-нода для нескольких VPS
- тестовые и production VM на одной платформе
- реселлерский или внутренний виртуализационный стек
Практическая схема
- Соберите схему вокруг сценария: Proxmox-нода для нескольких VPS, тестовые и production VM на одной платформе, реселлерский или внутренний виртуализационный стек. Отдельно опишите публичную точку входа, данные, фоновые задачи, backup и доступ администратора.
- Для Proxmox/реселлинга заранее разнесите management-доступ, клиентские VM, backup storage и IP-план. Management не должен висеть на тех же правилах, что клиентские сервисы.
- Сразу решите, как будут выдаваться IPv4: по одному адресу на VM, отдельные адреса под панели/NS/RDNS или подсеть под BGP.
- Не держите единственный backup на том же диске и в той же учетной записи, где работает основной сервис. Минимум: отдельный backup-путь, отдельный ключ доступа и понятный retention.
- Разделите доступы: публичные порты, SSH/VPN, панель управления, приватные сервисы и мониторинг. Все, что не должно быть доступно клиентам, закрывайте firewall до переноса.
Как выбрать ресурсы
- Начните с проверки: overcommit CPU и RAM; RAID/ZFS и скорость NVMe; сколько IPv4 нужно на старте и через 3 месяца.
- Для ноды считайте RAM с учетом overcommit и реального профиля VM. Оставляйте резерв под host OS, ZFS/RAID, snapshots, backup jobs и emergency migration.
- NVMe выбирайте по latency и write endurance: snapshots и backup создают пиковую запись даже тогда, когда VM выглядят спокойными.
- CPU выбирайте по пиковому сценарию, а не по среднему idle. Для web/API смотрите RPS и worker count, для баз данных - slow queries и CPU wait, для игр - single-thread и tickrate.
- RAM считайте по рабочему набору: ОС, приложение, база/cache, панели, фоновые jobs и запас под пик. Если swap уже используется постоянно, тариф мал.
- Диск выбирайте по двум параметрам: объем через 3-6 месяцев и задержка/IOPS. Для БД, search, CI и backup важна не только емкость, но и скорость записи/чтения.
- Сеть считайте отдельно: месячный трафик, пиковый Mbit/s или Gbit/s, география пользователей, CDN/cache и требования к дополнительным IPv4.
Что выбрать в заказе
- OS - для обычного Linux-стека выбирайте актуальные Debian/Ubuntu; для панели проверьте совместимость панели с версией ОС; для нестандартного образа выбирайте Custom ISO и указывайте ссылку/требования в тикете.
- Локация - для VPS без GPU выбирайте NL, DE, RU, UK, USA или SG по latency и аудитории. Для GPU VPS локация фиксирована тарифом, для dedicated требования к региону лучше написать в тикет.
- IPv4 - дополнительные адреса или подсеть нужны для отдельных сервисов, RDNS, virtualization, reseller hosting, BGP или изоляции клиентов. Если заказываете подсеть под BGP, заполните ASN.
- Панель - cPanel/Plesk/Virtualizor добавляйте только если она реально нужна для управления клиентами, сайтами или виртуализацией. Для простого VPS часто достаточно SSH и автоматизации.
- Для Proxmox выбирайте Proxmox VE в OS, указывайте нужный IP-план и заранее пишите, нужен ли BGP/ASN, RDNS и отдельный management address.
Проверка перед переносом
- Поднимите сервис на новом сервере как staging: та же ОС, версии runtime, база, расширения, панель и firewall-правила.
- Сначала создайте тестовую VM, проверьте bridge/network, IPv4 assignment, RDNS, firewall, backup job и restore одной VM.
- Сделайте backup до миграции, проверьте restore на тесте и заранее зафиксируйте rollback: DNS назад, старая база, остановка фоновых jobs или временная read-only пауза.
- Перед переносом снизьте DNS TTL, проверьте RDNS/hostname, SSL, cron, очереди, SMTP/webhook callbacks, monitoring alerts и доступ по аварийному каналу.
- Переключайте production только после проверки сети, диска, backup restore и основного пользовательского сценария: вход, заказ/оплата/API-запрос, запись в базу и уведомления.
Ошибки, которые ломают запуск
- выдавать клиентам адреса без RDNS-плана и учета abuse/изоляции
- строить VPS-хостинг без проверенного restore VM и без резерва RAM/NVMe под snapshots
- выбирать тариф только по цене, не считая CPU, RAM, disk latency, backup, трафик и рост нагрузки
- переносить production без staging, backup restore и rollback-плана
- оставлять открытыми лишние порты или переносить старые firewall-правила без проверки
- забывать про DNS TTL, RDNS, SSL, cron, SMTP, webhooks, очереди, мониторинг и уведомления
- открывать тикет без версии ОС, панели, стека, IP/ASN требований, окна работ и ожидаемой даты запуска
Что написать в тикет
- план по VM
- нужен ли Proxmox VE в выборе OS
- требования к подсети, VLAN и резервным копиям
