Proxmox VE позволяет запускать виртуальные машины и контейнеры на одном физическом сервере. Но производительность виртуальной инфраструктуры зависит не столько от самого гипервизора, сколько от правильно подобранного оборудования. Сервер с большим количеством ядер может упираться в диски, а быстрые NVMe не спасут ситуацию при нехватке оперативной памяти. Разбираем, какое железо выбрать для Proxmox, как рассчитать ресурсы под виртуальные машины и когда стоит задуматься о кластере.
Proxmox Virtual Environment (Proxmox VE) — платформа виртуализации с открытым исходным кодом на базе Debian Linux. Для виртуальных машин используется KVM, для контейнеров — LXC. Управлять инфраструктурой можно через веб-интерфейс, командную строку и API.
На одном сервере Proxmox можно разместить несколько независимых рабочих нагрузок:
Для небольшой компании Proxmox может работать на одном физическом сервере. Для инфраструктуры с высокими требованиями к доступности используют несколько узлов, общее или распределённое хранилище и механизмы кластеризации.
Главная ошибка при подборе оборудования — считать только количество виртуальных машин. Десять небольших Linux-серверов и десять виртуальных машин с Windows Server, SQL Server и RDS создают совершенно разную нагрузку.
Перед закупкой оборудования нужно определить:
Если виртуальные машины уже работают на другой платформе, лучше использовать реальные показатели потребления CPU, памяти и дисковых операций. Они дадут более точную картину, чем расчёт только по выделенным ресурсам.
Proxmox VE работает на 64-битных процессорах x86 с поддержкой аппаратной виртуализации Intel VT-x или AMD-V. Для корпоративного сервера обычно рассматривают Intel Xeon и AMD EPYC: эти платформы поддерживают ECC-память, большое количество линий PCIe и конфигурации с высокой вычислительной плотностью.
При выборе процессора важны не только физические ядра, но и производительность каждого ядра. Для большого количества небольших виртуальных машин полезна многопоточность, а для отдельных тяжёлых приложений критична скорость выполнения одного потока.
| Количество физических ядер | Типичный сценарий | Что учитывать |
|---|---|---|
| 8–12 | Небольшая виртуальная инфраструктура | Умеренная нагрузка, ограниченное число активных VM |
| 16–24 | Корпоративный сервер виртуализации | Несколько бизнес-систем, запас на рост |
| 32–48 | Плотная консолидация VM | Большое число одновременно активных нагрузок |
| 64 и более | Высоконагруженные узлы | NUMA, лицензирование гостевых ОС, память и охлаждение |
Диапазоны в таблице — ориентиры, а не ограничения Proxmox. Для небольшой инфраструктуры может хватить и менее мощного CPU, а одна ресурсоёмкая виртуальная машина способна занять большую часть 24-ядерного сервера.
В Proxmox виртуальной машине назначают vCPU, но это не означает постоянное резервирование отдельного физического ядра под каждый виртуальный процессор. Гипервизор распределяет процессорное время между гостевыми системами.
Поэтому суммарное количество vCPU может превышать число физических ядер. Такой подход называется CPU overcommit. Он допустим, когда виртуальные машины не используют процессор на полную мощность одновременно.
Универсального безопасного соотношения vCPU к физическим ядрам нет. Оно зависит от нагрузки, SMT, требований к задержкам и поведения виртуальных машин. После запуска инфраструктуры необходимо отслеживать загрузку CPU и признаки конкуренции за процессорное время.
При консолидации виртуальных машин оперативная память часто заканчивается раньше вычислительных ресурсов. Каждой VM требуется RAM для гостевой операционной системы и приложений, а самому Proxmox — память для гипервизора, служб и файлового кэша.
Для корпоративного сервера предпочтительна ECC-память. Она помогает обнаруживать и исправлять определённые ошибки памяти, что особенно важно для систем, работающих круглосуточно.
| Объём RAM | Для каких задач |
|---|---|
| 64 ГБ ECC | Небольшая инфраструктура с несколькими VM и умеренным потреблением памяти |
| 128 ГБ ECC | Корпоративные сервисы, Windows Server, Linux и бизнес-приложения |
| 256 ГБ ECC | Большое количество VM, базы данных, RDS и запас на расширение |
| 512 ГБ и более | Плотная консолидация, крупные базы данных и высоконагруженные узлы |
При расчёте памяти суммируйте потребности виртуальных машин, добавляйте ресурсы для самого хоста и резерв на пиковые нагрузки. Если используется ZFS, необходимо учитывать память для ARC и других структур файловой системы.
Proxmox поддерживает механизмы управления памятью, включая ballooning для совместимых гостевых систем. Однако рассчитывать на постоянное высвобождение RAM нельзя: критичным приложениям лучше выделять достаточный объём без агрессивной переподписки.
Для виртуализации важна не только ёмкость дисков, но и способность обслуживать большое количество одновременных операций. Когда десятки виртуальных машин обращаются к одному хранилищу, задержки дисковой подсистемы становятся критичными.
Для рабочих VM обычно выбирают серверные SSD или NVMe. HDD могут использоваться для архивов, резервных копий и других нагрузок, где скорость случайных операций не является приоритетом.
| Вариант | Преимущества | Когда использовать |
|---|---|---|
| Enterprise SATA SSD | Доступная стоимость, хорошая производительность | Небольшие и средние нагрузки |
| Enterprise SAS SSD | Серверные интерфейсы и характеристики надёжности | Корпоративные серверы и СХД |
| Enterprise NVMe | Высокие IOPS и низкие задержки | Плотная виртуализация и интенсивные базы данных |
| HDD | Большой объём за меньшую стоимость | Архивы и отдельные хранилища резервных копий |
Proxmox VE поддерживает несколько вариантов хранения, включая ZFS, LVM, LVM-thin и внешние сетевые хранилища. Выбор зависит от требований к производительности, снимкам состояния, резервированию и удобству администрирования.
При использовании ZFS рекомендуется предоставлять системе прямой доступ к физическим дискам через HBA или подходящий режим контроллера. Размещать ZFS поверх аппаратного RAID обычно не рекомендуется: это ограничивает возможности файловой системы по контролю состояния отдельных накопителей.
Для активной виртуализации часто рассматривают зеркальные пары SSD или NVMe. RAIDZ может быть эффективнее по полезному объёму, но его характеристики случайной записи необходимо оценивать под конкретную нагрузку.
Для одного сервера с небольшим количеством виртуальных машин гигабитная сеть может быть достаточной. Но при использовании сетевого хранилища, миграции VM между узлами и интенсивном резервном копировании пропускная способность сети становится существенным ограничением.
| Скорость сети | Применение |
|---|---|
| 1 GbE | Небольшие автономные серверы и управление |
| 10 GbE | Корпоративная виртуализация, миграция VM, сетевые хранилища |
| 25 GbE и выше | Крупные кластеры, интенсивное распределённое хранение и высокая плотность VM |
Для кластера желательно разделять трафик управления, виртуальных машин, миграции и хранения данных логически или физически. Это снижает конкуренцию за пропускную способность и упрощает диагностику.
Ниже приведены три ориентировочные конфигурации для разных масштабов виртуализации. Количество VM указано только как пример для смешанной нагрузки: фактическая плотность размещения зависит от выделенных ресурсов и активности гостевых систем.
| Параметр | Малый сервер | Корпоративный сервер | Высокая плотность VM |
|---|---|---|---|
| CPU | 8–12 ядер | 16–24 ядра | 32–64 ядра |
| RAM | 64–128 ГБ ECC | 128–256 ГБ ECC | 512 ГБ и более |
| Диски VM | 2 × Enterprise SSD | 4 × Enterprise SSD/NVMe | 4–8 × Enterprise NVMe |
| Хранилище | ZFS mirror | ZFS mirrors / LVM-thin | ZFS / внешняя СХД / Ceph |
| Сеть | 1/10 GbE | 10 GbE | 10/25 GbE |
| Ориентир по VM | 5–10 лёгких VM | 10–25 смешанных VM | 25+ VM при расчёте нагрузки |
Для установки самого Proxmox также нужно предусмотреть системный накопитель, желательно с резервированием. В конфигурациях с ZFS можно использовать отдельный зеркальный системный пул или продуманную схему совместного размещения системы и данных.
Один мощный сервер может быть достаточным для небольшой компании, но он остаётся единой точкой отказа. Если оборудование выйдет из строя, все размещённые на нём виртуальные машины станут недоступны до восстановления.
Кластер Proxmox позволяет объединить несколько узлов для централизованного управления и организации миграции виртуальных машин. При корректно настроенной инфраструктуре можно использовать механизмы высокой доступности (HA).
Для стандартной конфигурации с кворумом часто используют три узла. Возможны и двухузловые схемы с дополнительным устройством голосования QDevice, но они требуют отдельного проектирования.
Само создание кластера не делает виртуальные машины отказоустойчивыми. Для автоматического восстановления после отказа узла нужны корректная HA-конфигурация, доступность дисков виртуальных машин и достаточный запас ресурсов на оставшихся серверах.
Ceph — распределённая система хранения, которую можно интегрировать с Proxmox. Она позволяет хранить данные с избыточностью на нескольких узлах без обязательного использования отдельной централизованной СХД.
Но Ceph предъявляет дополнительные требования к оборудованию: быстрым накопителям, сети, памяти и вычислительным ресурсам. Для небольшого одиночного сервера такая архитектура обычно избыточна.
Если планируется кластер с Ceph, требования к сети и дисковой подсистеме нужно рассчитывать отдельно. Для производственных конфигураций часто рассматривают 10 GbE как отправную точку, а при интенсивной нагрузке — 25 GbE и выше.
Для Proxmox можно использовать как новые серверы, так и восстановленное корпоративное оборудование. Гипервизор не требует исключительно новейшего поколения процессоров, поэтому серверы предыдущих поколений нередко остаются экономически оправданными.
При выборе восстановленного оборудования нужно учитывать не только цену, но и энергопотребление, уровень шума, состояние накопителей, доступность комплектующих, обновления прошивок и совместимость с актуальной версией Proxmox VE.
Для виртуализации часто рассматривают серверы Dell PowerEdge, HPE ProLiant, Huawei и Inspur. Конкретная модель должна поддерживать нужный объём памяти, количество накопителей и сетевых адаптеров.
Независимо от того, используется один сервер или кластер, резервное копирование необходимо организовать отдельно. RAID, ZFS mirror и репликация не заменяют резервные копии: они защищают от отдельных аппаратных отказов, но не от удаления данных или ошибок администратора.
Для Proxmox можно использовать встроенные механизмы резервного копирования и Proxmox Backup Server (PBS). PBS поддерживает инкрементальные резервные копии, дедупликацию и проверку целостности данных.
Резервные копии желательно хранить на отдельном физическом оборудовании или в другом расположении. Также важно регулярно проверять возможность восстановления виртуальных машин, а не только успешность выполнения задания резервного копирования.
При выборе сервера для Proxmox важно учитывать всю инфраструктуру, а не только число виртуальных машин. Процессор определяет вычислительные возможности, RAM ограничивает плотность размещения VM, а дисковая подсистема влияет на скорость работы всех гостевых систем. Для небольших задач может быть достаточно 8–12 ядер и 64–128 ГБ памяти. Для корпоративной виртуализации чаще рассматривают 16–24 ядра, 128–256 ГБ RAM и серверные SSD или NVMe.
Если требуется высокая доступность, необходимо заранее проектировать кластер, хранение данных, сеть и резервное копирование. Правильно подобранное оборудование позволяет избежать переплаты за неиспользуемые ресурсы и снизить риск проблем при росте нагрузки.
Подбираете сервер для Proxmox VE? Свяжитесь с нами — поможем выбрать оборудование под количество виртуальных машин, нагрузку и бюджет. Новые и восстановленные серверы представлены на shiyapov.ru.