После изменений в экосистеме VMware и усложнения доступа к привычным корпоративным платформам виртуализации российские компании все чаще рассматривают альтернативные варианты для локальной инфраструктуры. В предыдущих материалах уже разбирались возможные замены VMware, сравнение гипервизоров и общий порядок перехода на Proxmox VE. Следующий вопрос - как превратить выбранную платформу в рабочую серверную среду, пригодную для корпоративной эксплуатации.
Proxmox VE интересен не только как гипервизор с открытым исходным кодом. В одной платформе объединяются виртуальные машины на базе KVM, контейнеры LXC, браузерное управление, кластеризация, резервное копирование и интеграция с программно определяемым хранилищем Ceph. За счет этого Proxmox VE можно использовать не только для одиночных серверов, но и для построения гиперконвергентной инфраструктуры, где вычислительные ресурсы и хранилище работают на одних и тех же узлах.
Ниже рассматривается прикладной сценарий развертывания Proxmox VE как гиперконвергентного решения: от базовых требований к серверу и установочного образа до создания кластера, настройки Ceph, подключения RBD-хранилища и запуска виртуальной машины. Такой подход помогает оценить Proxmox VE не как лабораторную альтернативу, а как зрелую инженерную платформу для бизнеса, где важны управляемость, отказоустойчивость и прогнозируемая стоимость владения.

Что такое Proxmox Virtual Environment
Proxmox Virtual Environment (VE) - гиперконвергентная платформа с открытым исходным кодом для программно определяемого управления корпоративной виртуализацией и контейнерными средами. На базе Linux KVM и LXC Proxmox VE объединяет вычислительные ресурсы, сетевые функции и хранилища в устойчивую инфраструктурную платформу.
Как и другие решения для создания гиперконвергентной среды, Proxmox VE предоставляет браузерный интерфейс для мониторинга и управления виртуальными машинами и контейнерами. В платформу также встроены средства отказоустойчивости, резервного копирования и аварийного восстановления, что упрощает эксплуатацию кластеров из нескольких серверов.
Proxmox VE объединяет виртуализацию и контейнеризацию в одной платформе. Такой подход помогает рациональнее использовать существующие серверные ресурсы и снижать избыточность инфраструктуры в гиперконвергентных сценариях.
Ресурсоемкие Linux- и Windows-нагрузки могут размещаться в виртуальных машинах, а Linux-сервисы - в контейнерах. При этом хранилище можно масштабировать постепенно за счет проверенных программно определяемых решений, включая Ceph.

Типовые задачи, для которых подходит Proxmox VE
Proxmox VE подходит для разных корпоративных, образовательных и исследовательских ИТ-сред. При запуске в ИТ-инфраструктуре эта гиперконвергентная платформа позволяет сочетать надежность, производительность, масштабируемость и контролируемую стоимость владения.
Малый и средний бизнес
Для организаций, которым требуется функциональная платформа виртуализации с минимальной лицензионной нагрузкой, Proxmox VE может стать экономически оправданным вариантом. В одной среде доступны гипервизор, управление хранилищами, поддержка контейнеров, резервное копирование и единый интерфейс администрирования.
Образовательные и научно-исследовательские организации
Proxmox VE подходит для обучения, разработки и тестовых сред, где требуется быстро создавать виртуальные машины и контейнеры. Модель с открытым исходным кодом удобна для организаций с ограниченным бюджетом, которым нужны расширенные функции без жесткой привязки к закрытой экосистеме.
Компании, ориентированные на решения с открытым исходным кодом
Для организаций с собственной Linux-экспертизой или стратегией развития на базе решений с открытым исходным кодом Proxmox VE хорошо вписывается в ИТ-архитектуру. Платформа дает больше гибкости при проектировании виртуальной инфраструктуры и выборе серверного оборудования.
Ключевые преимущества Proxmox VE
Использование Proxmox Virtual Environment на корпоративных серверах класса Dell PowerEdge или Lenovo ThinkSystem может повысить отдачу от инфраструктурных вложений за счет консолидации ресурсов, гибкого масштабирования и выбора подходящей модели поддержки.
Экономическая эффективность. Для малого и среднего бизнеса важно контролировать стоимость инфраструктуры. Proxmox VE позволяет начать с платформы с открытым исходным кодом и полным набором базовых возможностей, а расширенные функции корпоративного уровня доступны во всех редакциях.
Виртуализация. Proxmox VE поддерживает два подхода к размещению рабочих нагрузок - полноценные виртуальные машины на базе KVM и контейнерные среды Linux Containers. Это позволяет выбирать формат запуска под конкретную задачу, требования к изоляции, производительности и администрированию.
KVM применяется для полной виртуализации и обеспечивает близкую к аппаратной производительность на современных серверах x86 архитектуры. На его базе можно создавать виртуальные экземпляры Windows и Linux, где каждая виртуальная машина получает собственный набор виртуализированных ресурсов - процессор, память, сеть, диски и графический адаптер. Такой подход позволяет запускать несколько прикладных нагрузок на одном физическом сервере.
Linux Containers - более легкий вариант виртуализации на уровне операционной системы. В контейнер включаются необходимые для приложения библиотеки и зависимости, а запуск выполняется поверх общего ядра Linux-хоста. Контейнеры изолированы друг от друга, при этом администратор может отдельно управлять базовой системой и прикладными нагрузками.
Программно определяемое хранилище с Ceph. Помимо традиционных типов систем хранения, в инфраструктуру Proxmox VE можно интегрировать Ceph - распределенное хранилище с открытым исходным кодом для объектных, блочных и файловых сценариев. В Proxmox VE Ceph используется для построения программно определяемой инфраструктуры и может управляться из единой среды администрирования.
Программно определяемые хранилища на базе Ceph можно разворачивать на стандартных корпоративных серверах x86_64. Такие конфигурации ориентированы на программно определяемые хранилища для озер данных ИИ, резервного копирования, архивного хранения и сервисов данных в гибридных облачных средах. Proxmox VE упрощает настройку и администрирование CephFS, поддерживает масштабирование до экзабайтного уровня и использует механизмы самовосстановления данных.
Кластеризация. Proxmox VE позволяет начать с одного узла и затем развить инфраструктуру до полноценного кластера без установки отдельной платформы управления. Такой подход поддерживает оперативную миграцию виртуальных машин между узлами и помогает проводить обслуживание с минимальным влиянием на пользователей и прикладные сервисы.
Многоузловая модель управления упрощает эксплуатацию: административные задачи можно выполнять с любого узла кластера. Через графический интерфейс Proxmox VE доступны виртуальные машины, контейнеры, хранилища и параметры кластера.
Централизованное управление. Proxmox VE предоставляет веб-интерфейс для управления виртуальной инфраструктурой, а также командную строку и REST API для автоматизации задач. Управление может выполняться через браузерный интерфейс, мобильный доступ или инструменты командной строки.
Для опытных администраторов командная строка позволяет выполнять те же базовые операции, что и графический интерфейс, а также создавать сценарии для повторяемых задач. Стандартизированный REST API дает возможность интегрировать Proxmox VE со сторонними системами управления и автоматизации.
Надежность, доступность и безопасность. Proxmox VE подходит для построения программно определяемого центра обработки данных благодаря встроенным средствам межсетевого экрана, резервного копирования, восстановления и высокой доступности. Эти функции помогают централизованно управлять защитой, обслуживанием и отказоустойчивостью виртуальных машин и контейнеров.
Краткое сравнение ключевых HCI-платформ с точки зрения эксплуатации
Ниже в таблице сопоставлены базовые возможности гиперконвергентной инфраструктуры в актуальных версиях Proxmox, VMware и Nutanix.
Proxmox VE закрывает основные задачи HCI - высокую доступность вычислительных ресурсов, оперативную миграцию виртуальных машин, отказоустойчивое хранилище на базе Ceph, встроенное резервное копирование и программно определяемые сетевые контуры.
VMware vCenter/vSAN и Nutanix Prism/AOS при этом предлагают более глубокую автоматизацию - распределение нагрузки, централизованное управление жизненным циклом, обновление микропрограммного обеспечения и расширенную микросегментацию.
Для многих инфраструктур Proxmox VE может обеспечить практически сопоставимый уровень стандартных HCI-возможностей при меньших затратах на программное обеспечение. Компромисс заключается в большем объеме инженерной настройки и эксплуатационной ответственности, но взамен платформа дает открытую архитектуру и гибкость адаптации под конкретную инфраструктуру.
|
Возможность
|
Proxmox VE 8.2
|
VMware vSAN
|
Nutanix Prism/AOS
|
|
Вычисления / высокая доступность
|
KVM/QEMU, оперативная миграция, HA Manager
|
vMotion, HA, DRS
|
Оперативная миграция, HA, автономное размещение нагрузок
|
|
Хранилище
|
Ceph RBD - RF/EC, CRUSH; CephFS для общих файловых ресурсов
|
vSAN - SPBM, дедупликация, сжатие, EC
|
AOS - RF2/RF3, EC-X, сокращение объема данных
|
|
Жизненный цикл
|
Обновления PVE и Ceph через графический интерфейс; репозиторная модель
|
vLCM для ESXi, драйверов и микропрограммного обеспечения
|
LCM в один клик - гипервизор, микропрограммное обеспечение, хранилище
|
|
Сеть / SDN
|
VLAN, VXLAN/EVPN; интеграция с межсетевым экраном
|
NSX - наложенные сети, микросегментация, сервисы
|
Flow - микросегментация, политики
|
|
Резервное копирование / аварийное восстановление
|
Proxmox Backup Server + репликация виртуальных машин
|
vSphere Replication / SRM; развитая экосистема
|
Снимки, репликация; Leap DR
|
|
GPU / vGPU
|
SR-IOV, mdev, NVIDIA vGPU - больше ручной настройки
|
Зрелая поддержка vGPU; vMotion с vGPU - zero-copy
|
Поддержка AHV vGPU - NVIDIA
|
Перед началом внедрения Proxmox VE
Для запуска Proxmox VE инфраструктура должна соответствовать базовым аппаратным и функциональным требованиям.
Функциональные требования к серверу
Для успешного развертывания Proxmox VE рекомендуется рассматривать корпоративные типы серверных платформ, такие как HPE Proliant или Supermicro.
Базовые требования к серверу:
-
процессор Intel 64 или AMD64 с поддержкой аппаратной виртуализации Intel VT / AMD-V;
-
минимум 2 ГБ оперативной памяти для самой ОС и сервисов Proxmox VE, плюс отдельный объем памяти под виртуальные машины и контейнеры;
-
при использовании ZFS или Ceph требуется дополнительная память - ориентировочно около 1 ГБ RAM на каждый 1 ТБ используемого хранилища;
-
быстрые и отказоустойчивые накопители, предпочтительно SSD/NVMe;
-
для системного диска - аппаратный RAID с защищенным кэшем записи BBU либо вариант без аппаратного RAID при использовании ZFS;
-
для хранения виртуальных машин - аппаратный RAID с BBU либо конфигурация без аппаратного RAID для ZFS;
-
для ZFS и Ceph аппаратный RAID-контроллер использовать не рекомендуется: Proxmox прямо указывает, что ни ZFS, ни Ceph не совместимы с аппаратным RAID-контроллером;
-
резервированные сетевые интерфейсы от 1 Гбит/с, а для кластеров, Ceph и интенсивных нагрузок - дополнительные интерфейсы, включая 10 Гбит/с и выше;
-
для PCIe passthrough требуется процессор с поддержкой VT-d у Intel или AMD-d у AMD.
Пример конфигурации сервера:
-
Процессор: 1 × AMD EPYC 9334, 32 ядра, 210 Вт, 2,7 ГГц.
-
Оперативная память: 192 ГБ: 6 × 32 ГБ DDR5 4800 МГц RDIMM.
-
Сетевой адаптер: 1 × Intel E810-DA4, 10/25GbE SFP28, 4 порта, OCP Ethernet.
-
Накопители: 16 × E1.S 7,68 ТБ, Read Intensive NVMe PCIe 4.0 x4, SSD с горячей заменой.
Примеры серверов Lenovo ThinkSystem, которые официально заявлены в матрице совместимости Lenovo с Proxmox VE:
|
Форм-фактор / сокеты
|
Процессор
|
Модель сервера Lenovo
|
Аналоги серверов от HPE и Dell*
|
|
Стоечный 1U, 1 сокет
|
4th Gen EPYC
|
ThinkSystem SR635 V3
|
-
ProLiant DL325 Gen11
-
PowerEdge R6615
|
|
Стоечный 1U, 2 сокета
|
5th Gen Xeon
|
ThinkSystem SR630 V3
|
-
ProLiant DL360 Gen11
-
PowerEdge R660
|
|
Стоечный 1U, 2 сокета
|
4th Gen EPYC
|
ThinkSystem SR645 V3
|
-
ProLiant DL365 Gen11
-
PowerEdge R6625
|
|
Стоечный 2U, 1 сокет
|
4th Gen EPYC
|
ThinkSystem SR655 V3
|
-
ProLiant DL345 Gen11
-
PowerEdge R7615
|
|
Стоечный 2U, 2 сокета
|
5th Gen Xeon
|
ThinkSystem SR650 V3
|
-
ProLiant DL380 Gen11
-
PowerEdge R760
|
|
Стоечный 2U, 2 сокета
|
4th Gen EPYC
|
ThinkSystem SR665 V3
|
-
ProLiant DL385 Gen11
-
PowerEdge R7625
|
|
Стоечный 2U, 4 сокета
|
4th Gen Xeon
|
ThinkSystem SR850 V3
|
-
ProLiant DL560 Gen11
-
PowerEdge R860
|
|
Стоечный 3U, 2 сокета
|
4th Gen EPYC
|
ThinkSystem SR675 V3 (GPU/AI)
|
|
|
Стоечный 4U, 4 сокета
|
4th Gen Xeon
|
ThinkSystem SR860 V3
|
-
ProLiant DL560 Gen11
-
PowerEdge R860
|
|
Стоечный 8U, 8 сокетов
|
4th Gen Xeon
|
ThinkSystem SR950 V3
|
|
(*) В ИТ-сообществе России экосистема продуктов Proxmox все чаще обсуждается не как нишевый эксперимент, а как рабочая платформа для корпоративной виртуализации на стандартных x86_64-серверах. При этом важно разделять два уровня совместимости: сам Proxmox VE опирается на типовую серверную архитектуру с аппаратной виртуализацией, а реальная пригодность решения зависит от конкретной конфигурации - контроллеров хранения, сетевых адаптеров, NVMe-накопителей, прошивок, режима RAID или HBA, а также выбранной схемы ZFS или Ceph. У Lenovo связка с Proxmox выглядит наиболее формализованной для актуальных серверов V3, у Dell Proxmox заметнее проявляется в отдельных инфраструктурных сценариях и инструментах управления, а для HPE и Supermicro чаще требуется проектная проверка совместимости. Поэтому в корпоративном внедрении Proxmox VE правильнее говорить не о «универсальной сертификации под любой сервер», а о тщательно подобранной и протестированной связке оборудования, гипервизора, хранилища и регламентов поддержки.
Требования к оперативной памяти
Для операционной системы Proxmox VE и ее служебных компонентов требуется минимум 2 ГБ оперативной памяти. Дополнительный объем RAM рассчитывается отдельно для гостевых виртуальных машин и контейнеров - с учетом операционной системы, прикладной нагрузки и требуемого запаса производительности.
Для легких сервисов можно ориентироваться на минимальные значения, но для более ресурсоемких рабочих нагрузок обычно закладывают больший объем памяти - например, 4-8 ГБ и выше на отдельную виртуальную машину или контейнер. Если на серверах Lenovo используются ZFS или Ceph, необходимо предусмотреть дополнительную память для подсистемы хранения - ориентировочно 1 ГБ RAM на каждый 1 ТБ используемого хранилища.
Конфигурация хранилища
Proxmox VE поддерживает разные варианты хранения данных на серверах: локальные диски DAS, аппаратный RAID, а также программно определяемые хранилища на базе ZFS или Ceph. Для установки операционной системы можно использовать SATA/SAS SSD, однако для размещения данных виртуальных машин предпочтительны NVMe SSD - они лучше подходят для высоких требований к задержкам и скорости ввода-вывода.
Также возможно подключение внешних all-flash СХД, таких как Lenovo ThinkSystem DE, Dell PowerVault или HPE MSA. Такие массивы подходят для смешанных нагрузок и требовательных задач, включая аналитику, высокопроизводительные вычисления и искусственный интеллект, а также ориентированы на критичные к производительности приложения - Oracle, Microsoft SQL Server, MongoDB, VDI, серверную виртуализацию, а также ресурсоемкие AI-сценарии, включая обучение, донастройку, инференс и RAG.
Для загрузки Proxmox VE можно использовать отдельный загрузочный модуль с двумя M.2 SSD, объединенными в RAID 1. Такая схема отделяет системный том гипервизора от основной дисковой подсистемы, сохраняет фронтальные отсеки и NVMe/SAS/SATA-накопители для данных виртуальных машин, а также обеспечивает базовую отказоустойчивость загрузочного раздела.
У разных производителей такие решения называются по-разному: у Lenovo - ThinkSystem M.2 RAID / M.2 SATA-NVMe Enablement Kit, у Dell - Boot Optimized Storage Solution (BOSS-S2 или BOSS-N1), у HPE - NS204i-u / NS204i-u V2 Boot Optimized Storage Device. Конкретный вариант подбирается по модели сервера, поколению платформы, поддерживаемому типу M.2 SSD, требованиям к горячей замене и режиму RAID.
Если в качестве подсистемы хранения используются ZFS или CephFS, дискам данных требуется прямой доступ без аппаратного RAID. В таких конфигурациях накопители настраиваются в режиме JBOD или через HBA. В качестве примера 2U-платформы для таких нагрузок можно использовать обзор Dell PowerEdge R7725.
Ниже для дисков виртуальных машин и контейнеров используется Ceph RBD - блочное хранилище со снимками и клонами. CephFS применяется для общих файловых ресурсов - ISO-образов, шаблонов и целей резервного копирования.
Настройки UEFI
Особенности Secure Boot
Начиная с Proxmox VE 8.1 платформа штатно поддерживает Secure Boot. В производственной среде этот режим рекомендуется оставлять включенным, если нет отдельных технических причин для его отключения.
Отключение Secure Boot оправдано только в осознанных сценариях - например, при использовании неподписанных DKMS-модулей, отказе от их подписи или при временной диагностике редких проблем с прошивкой и ключами загрузки.
Для типовой установки Proxmox VE 8.1 и новее предпочтительный вариант - Enabled, если конфигурация сервера, драйверы и модули ядра не требуют другого режима.
Проверка настроек виртуализации
Для корректной работы passthrough необходимо проверить, что IOMMU включен в настройках UEFI.
Обычно IOMMU включен по умолчанию, однако перед развертыванием Proxmox VE стоит убедиться, что настройка не была изменена.
Рекомендации по производительности
Для максимальной производительности рекомендуется проверить режим работы сервера в соответствующем разделе контроллера управления сервером, например, в Lenovo XClarity Controller этот параметр находится в разделе System Settings > Operating Modes, в iLO 7 нужно работать с разделами Power Regulator и Workload Profile, а в iDRAC10 - System Profile Settings
Для HCI-сценариев на Proxmox VE предпочтителен профиль, предполагающий максимальную производительность. Он снижает влияние динамических механизмов энергосбережения, таких как C-states и P-states, и отдает приоритет пропускной способности, задержкам и предсказуемой реакции процессора под нагрузкой.
Для кластера Proxmox VE и Ceph такие настройки особенно важны, поскольку они помогают:
-
ускорить операции записи Ceph OSD, восстановление и балансировку PG;
-
повысить отзывчивость SCSI-подсистемы хоста;
-
снизить джиттер при запуске виртуальных машин и контейнеров;
-
сделать выделение памяти более предсказуемым;
-
стабилизировать реакцию CPU под нагрузкой;
-
ускорить реакцию кластера при fencing, изменении кворума и выборах мониторов.
Известные ограничения и особенности
Поддержка драйверов.
Proxmox VE использует собственное ядро Linux на базе Debian, которое обычно включает драйверы для распространенных сетевых адаптеров и контроллеров хранения, включая Broadcom NetXtreme и Intel I350. Однако для новых серверных конфигураций, особенно с современными NVMe-контроллерами и сетевыми адаптерами, совместимость нужно проверять заранее. Если нужный драйвер еще не входит в используемую версию ядра Proxmox VE, может потребоваться обновление ядра, прошивки или ручная настройка драйвера.
Контроль состояния оборудования.
Обычно контроллер удаленного управления сервером передает данные о состоянии сервера через IPMI и Redfish, включая сведения о температуре, вентиляторах и аппаратных событиях. В Proxmox VE нет отдельного встроенного агента для такого мониторинга, поэтому для расширенного контроля обычно требуется дополнительная интеграция - например, через ipmitool, Redfish-запросы, систему мониторинга или пользовательские сценарии.
Горячая замена NVMe.
NVMe-корзины серверов могут поддерживать физическую горячую замену накопителей. В Proxmox VE ядро Linux обычно определяет подключение и извлечение NVMe-устройств автоматически, но в отдельных случаях новый диск может не появиться сразу. Тогда требуется повторное сканирование контроллера NVMe и пространства имен, например через команды rescan_controller и nvme ns-rescan.
Инасталляция Proxmox VE
Установочный ISO-образ Proxmox VE включает:
-
полноценную 64-битную операционную систему Debian GNU/Linux;
-
установщик Proxmox VE, который размечает локальные диски в ext4, XFS, BTRFS в режиме предварительной поддержки или ZFS и устанавливает операционную систему;
-
ядро Linux Proxmox VE с поддержкой KVM и LXC;
-
набор инструментов для администрирования виртуальных машин, контейнеров, хост-системы, кластеров и связанных ресурсов;
-
браузерный интерфейс управления.
Подготовка к развертыванию
Загрузка ISO-образа Proxmox.
Для установки необходимо скачать ISO-образ Proxmox Virtual Environment с официального сайта Proxmox.
Версия 9.х - наиболее свежая на момент публикации пока проходит свой обычный цикл устранения ошибок и не рекомендуется к использованию в продуктивных средах. Ближе к середине 2026 года можно будет рассматривать вопросы миграции, а пока ниже используется наиболее стабильная на момент публикации версия Proxmox Virtual Environment 8.3.
Подключение загрузочного ISO к удаленной консоли.
ISO-образ Proxmox VE можно подключить как виртуальный носитель через удаленную консоль управления сервером. Для этого используется функция виртуального носителя, которая позволяет смонтировать локальный ISO-файл как загрузочный диск и выполнить установку Proxmox VE без физического доступа к серверу.
Загрузка с установочного носителя.
После загрузки сервера с подключенного ISO-образа откроется установочное меню Proxmox VE.
В установочном меню доступны следующие варианты:
-
Установить Proxmox VE в графическом режиме - запускает стандартную графическую установку.
-
Установить Proxmox VE в текстовом интерфейсе - запускает мастер установки в текстовом режиме.
-
Установить Proxmox VE в текстовом интерфейсе через последовательную консоль - запускает текстовую установку с использованием последовательной консоли.
Для наглядности выбран вариант установки Proxmox VE в графическом режиме. После запуска установки необходимо принять лицензионное соглашение конечного пользователя.
Далее нужно выбрать целевой накопитель, на который будет установлен Proxmox VE.
После выбора страны, часового пояса и раскладки клавиатуры задайте пароль root и укажите адрес электронной почты для системных уведомлений.
Далее настройка сетевых параметров - выбор статический IP-адрес или автоматическое получение адреса по DHCP.
Совет: на этапе установки Proxmox VE рекомендуется подключить только один сетевой порт. Остальные сетевые интерфейсы можно настроить позже - для резервирования, разделения трафика или выделенных сетей между узлами.
Далее система предложит внимательно проверить все выбранные параметры и можно запустить установку. Процесс может занять несколько минут. После завершения установки система предложит извлечь установочный носитель и перезагрузить сервер.
Настройка Proxmox VE как гиперконвергентной инфраструктуры
Цель настройки - создать гиперконвергентную среду, которая по архитектурной логике близка к программно определяемым хранилищам Nutanix и VMware vSAN. В такой схеме вычислительные ресурсы и распределенное хранилище работают на одних серверных узлах без участия внешней системы хранения.
Порядок настройки:
-
создать и проверить кластер Proxmox VE;
-
инициализировать Ceph и создать службы мониторинга Ceph для управления средой хранения;
-
подготовить накопители и создать службы хранения Ceph (OSD) для размещения данных;
-
создать хранилища Ceph для виртуальных машин;
-
интегрировать Ceph с Proxmox VE, чтобы платформа могла использовать Ceph для виртуальных машин и контейнеров.
Первичная настройка выполняется через командную строку, после чего отдельные действия можно завершить в графическом интерфейсе. Предполагается, что серверные узлы уже установлены, обновлены, а сетевая конфигурация заранее подготовлена.
Создание кластера Proxmox VE через командную строку
Настройка начинается с создания и проверки кластера через командную строку. Для создания кластера используется команда:
pvecm create <cluster name>
В данном примере кластер получает имя ProxC1. После завершения операции необходимо проверить его состояние командой:
pvecm status
В результате должен появиться вывод, подтверждающий создание кластера и текущее состояние его узлов.
Далее необходимо добавить остальные узлы в кластер и снова проверить его состояние. На каждом узле, который планируется включить в кластер, выполните команду:
pvecm add <IP address>
В качестве <IP address> указывается IP-адрес уже созданного узла кластера. В примере ниже дополнительный узел был успешно добавлен.
Для проверки состояния кластера с одного из его узлов используется команда:
pvecm status
, которая показывает, что в кластер включены все три узла, а его состояние является штатным.
Настройка Ceph через командную строку
В Proxmox VE 8.2 для новых установок обычно используется Ceph Reef 18.2, при этом Ceph Quincy 17.2 может применяться в существующих или специально выбранных конфигурациях. Ниже используется Quincy.
Сначала необходимо установить пакеты Ceph на каждом узле кластера. Если подписка Proxmox отсутствует, нужно использовать не корпоративный репозиторий, а репозиторий no-subscription. После изменения настроек репозиториев выполните команду:
pveceph install --repository no-subscription
Далее на первом узле кластера необходимо инициализировать Ceph. Эта операция создаст начальную конфигурацию кластера Ceph, а также службы мониторинга и управления.
Инициализация выполняется с указанием подсети, которая будет использоваться Ceph:
pveceph init --network 172.21.1.0/24
На остальных узлах необходимо создать службы мониторинга Ceph, чтобы сформировать распределенный механизм контроля состояния кластера и кворума в пределах заданной подсети.
Для этого выполняется команда:
pveceph createmon
Проверить состояние кластера Ceph можно с помощью команд:
ceph -s
ceph mon dump
Вывод должен подтвердить, что кластер Ceph работает штатно, а службы мониторинга созданы и доступны. Результат должен быть сопоставим с примером ниже.
Перед созданием службы хранения Ceph необходимо очистить выбранные накопители от прежней разметки и данных. Затем на каждом узле создается OSD с помощью команды:
pveceph createosd <device>
Например, для второго NVMe-накопителя команда может выглядеть так:
pveceph createosd /dev/nvme1n1
Перед выполнением команды необходимо убедиться, что указан правильный накопитель, так как очистка и создание OSD удалят существующие данные на этом устройстве.
После завершения этих шагов конфигурацию можно проверить с помощью команд:
ceph osd tree
ceph -s
ceph mon dump
Вывод должен подтвердить, что состояние кластера - OK, все три службы мониторинга Ceph доступны, служба управления активна, а на каждом узле настроена своя служба хранения Ceph (OSD).
В качестве финальной проверки необходимо проверить состояние служб хранения Ceph с помощью команды:
ceph osd status
Эти шаги можно повторить для каждого накопителя на каждом узле, где планируется создать службу хранения Ceph (OSD). Чтобы посмотреть список доступных дисков, выполните команду:
lsblk -o NAME,SIZE,MODEL,TYPE,MOUNTPOINT
Накопители без разделов потенциально могут использоваться для OSD, если это соответствует выбранной схеме хранения. Перед настройкой необходимо убедиться, что выбранный диск не содержит нужных данных и действительно предназначен для Ceph.
После настройки нужных OSD необходимо снова проверить дерево служб хранения Ceph. Далее создаются группы размещения данных - PG.
В этом сценарии используется 512 PG, так как такое значение практично для конфигурации с 24 OSD. Общий ориентир для расчета можно представить так:
целевое число PG = количество OSD × 100 / коэффициент репликации
В данном примере коэффициент репликации равен 3. Формально расчет дает около 800 PG, но большее число PG увеличивает количество фоновых процессов и может повлиять на производительность. Поэтому для небольшого кластера допустимо начинать с меньшего значения и затем корректировать конфигурацию по мере роста нагрузки и объема данных.
Если кластер рассчитан на высокую параллельность, интенсивный ввод-вывод и быстрые накопители, например NVMe, более высокое число PG может быть оправдано.
Для создания пула на узле с активной службой управления Ceph выполняется команда:
ceph osd pool create <pool name> 512 512
В данном примере пул называется vmstore:
ceph osd pool create vmstore 512 512
После выполнения команда должна вернуть сообщение об успешном создании пула.
Альтернативный подход - не фиксировать число PG вручную, а включить автоматический подбор PG в Ceph. В этом случае Ceph будет корректировать количество групп размещения с учетом размера кластера и ожидаемой доли данных в каждом пуле. Для нескольких пулов можно задать target_size_ratio, чтобы Ceph понимал, как распределять PG между ними.
Далее необходимо указать назначение пула. Это нужно Ceph для внутренних проверок, оптимизации и контроля совместимости. Для пула vmstore, который будет использоваться как блочное хранилище RBD, выполняется команда:
ceph osd pool application enable vmstore rbd
Далее необходимо зарегистрировать пул RBD в Proxmox VE как хранилище для виртуальных машин. Для этого выполняется команда:
pvesh create /storage --storage vmstore --type rbd --content images --monhost "172.21.1.19;172.21.1.20;172.21.1.21" --pool vmstore --krbd 1
Ключевые параметры команды:
-
--type rbd - указывает, что используется блочное устройство RADOS;
-
--content images - задает тип содержимого: диски виртуальных машин;
-
--pool vmstore - связывает Proxmox VE с ранее созданным пулом Ceph;
-
--krbd 1 - включает использование RBD-драйвера ядра Linux.
Проверить добавленное хранилище можно командами:
pvesh get /storage
pvesh get /storage/vmstore
Создание виртуальной машины через командную строку
После создания кластера Proxmox VE и подключения Ceph-хранилища как хранилища образов виртуальных машин можно создать тестовую виртуальную машину.
Ниже создается виртуальная машина с идентификатором 1001, именем ceph-test-vm, виртуальным диском 20 ГБ в пуле Ceph RBD vmstore, 1 ГБ оперативной памяти, 2 ядрами процессора и контроллером хранения virtio-scsi для эффективной работы операций ввода-вывода.
Для создания виртуальной машины выполняется команда:
qm create 1001 --name ceph-test-vm --memory 1024 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --scsi0 vmstore:20
Проверить наличие образа виртуального диска можно командой:
rbd ls -p vmstore
Далее необходимо подключить к виртуальной машине ISO-образ операционной системы командой:
qm set 1001 --ide2 local:iso/ubuntu-22.04.5-live-server-amd64.iso --boot 'order=ide2;scsi0' --bootdisk scsi0
Эта команда подключает ISO-образ к виртуальной машине с идентификатором 1001 и задает порядок загрузки: сначала с ISO-образа, затем с диска scsi0.
На этом этапе виртуальную машину можно запустить командой:
qm start 1001
Настройка кластера через графический интерфейс Proxmox VE
На этом этапе HCI-схема на базе Proxmox VE настраивается через графические инструменты платформы. Для доступа к веб-консоли используется порт 8006, например:
http://172.21.1.19:8006
В данном примере работа продолжается под учетной записью root. В промышленной среде рекомендуется использовать отдельные роли и учетные записи для администрирования Proxmox VE и Ceph.
После входа в систему открывается представление Datacenter для выбранного узла. На начальном этапе оно отображается без выполненной настройки, как показано на примере ниже.
При переходе в раздел Datacenter -> Cluster выбирается Create Cluster. Откроется окно, в котором необходимо указать имя кластера.
Если в конфигурации предусмотрено несколько сетевых подключений для резервирования, их можно добавить до нажатия Create. В данном примере используется уже настроенный сетевой мост vmbr0.
После создания кластера появится краткий вывод с перечнем выполненных действий и статусом операции. Перед переходом к остальным узлам необходимо нажать кнопку Join Information и скопировать данные для присоединения кластера.
На каждом дополнительном узле необходимо открыть веб-интерфейс Proxmox VE и перейти в раздел: Datacenter -> Cluster -> Join Cluster
В появившемся окне нужно ввести данные для присоединения к кластеру, полученные на первом узле. Перед подтверждением операции необходимо внимательно проверить каждое поле.
Подключение новой ноды к новому кластеру в Proxmox VE
Настройка Ceph через браузерный интерфейс Proxmox VE
Далее Ceph настраивается повторно, но уже через браузерный интерфейс Proxmox VE. В разделе Datacenter -> Ceph система предложит установить Ceph, после чего откроется экран выбора версии Ceph и репозитория пакетов.
Как и в варианте настройки через командную строку, в поле репозитория выбирается No Subscription. Версия Ceph остается прежней - Ceph 17.2 Quincy.
Откроется окно командной строки, в котором необходимо подтвердить установку пакетов.
После завершения установки пакетов инсталляция переходит к экрану настройки.
В поле Public Network в выпадающем списке должна отображаться сеть, уже назначенная узлу в конфигурации кластера Proxmox VE. Если нужная сеть не подставилась автоматически, ее необходимо указать вручную.
Если требуется задать отдельное количество копий данных, в нижней части окна нужно включить параметр Advanced и указать нужные значения в соответствии с выбранной схемой хранения.
После завершения настройки появится служебное сообщение с дальнейшими действиями. Процесс установки и настройки Ceph необходимо повторить на оставшихся узлах кластера.
Чтобы настроить дополнительные узлы для работы служб мониторинга и управления Ceph, необходимо выбрать нужный узел в представлении Datacenter и перейти в раздел Ceph:
В обоих разделах нужно добавить выбранный узел через кнопку Create. Это действие необходимо повторить для каждого узла кластера. После завершения настройки все узлы кластера должны отображаться в списках Monitor и Manager.
В разделе OSD нужно выбрать Create в верхней части окна. Перед этим необходимо очистить отдельные накопители, которые будут использоваться для создания OSD.
Откроется экран, похожий на пример ниже. В выпадающем списке Disk будут показаны неразмеченные накопители, доступные на выбранном узле. Эту операцию необходимо повторить для каждого накопителя, который планируется использовать для создания OSD в пуле Ceph.
Разметка накопителей в Ceph через графическую панель Proxmox VE
По мере создания OSD можно обновлять список, чтобы видеть актуальное состояние.
После настройки выбранных накопителей как OSD можно вернуться в раздел Datacenter -> Ceph и проверить общее состояние пула хранения.
Теперь необходимо создать пул хранения на базе настроенных OSD. Для этого в интерфейсе Proxmox VE перейдите по пути: <любой узел кластера> -> Ceph -> Pools.
На этом этапе параметры по умолчанию остаются без изменений, но для целевого размера задается значение 50 GiB.
Далее необходимо настроить RBD-хранилище для виртуальных машин. Для этого в интерфейсе Proxmox VE перейдите в раздел: Datacenter -> Storage и выбрать: Add -> RBD.
На следующем экране задается идентификатор хранилища в соответствии с принятой схемой именования. Этот шаг связывает пул хранения Ceph с логическим уровнем хранения Proxmox VE - по смыслу аналогично хранилищу datastore в ESXi или контейнеру хранения в Nutanix Prism.
На завершающем этапе создается виртуальная машина на новом RBD-хранилище. В правом верхнем углу браузерного интерфейса Proxmox VE доступны варианты создания виртуальной машины или контейнера. В данном случае выбрано создание виртуальной машины.
Далее мастер создания виртуальной машины проходит через несколько экранов настройки с сетевым загрузочным образом Ubuntu 22.04.5. На этапе выбора хранилища из списка выбирается пул RBD, в котором будет размещен диск виртуальной машины.
Далее необходимо перейти на узел Prox3, на котором была создана виртуальная машина, и запустить ее.
На этом этапе должна быть доступна консоль виртуальной машины, после чего можно начать работу с гостевой операционной системой.
Заключение
Главный вывод - Proxmox VE требует инженерного подхода. Перед внедрением необходимо проверить совместимость серверной платформы, сетевых адаптеров, накопителей, контроллеров, прошивок и выбранной схемы хранения. Для ZFS и Ceph особенно важно заранее определить режим доступа к дискам, объем оперативной памяти, выделенные сетевые контуры и правила обслуживания кластера. Без такой подготовки открытая платформа может дать не снижение рисков, а новую зону эксплуатационной неопределенности.
В сравнении с VMware vSAN и Nutanix Proxmox VE может закрыть стандартные задачи гиперконвергентной инфраструктуры - высокая доступность, миграция виртуальных машин, распределенное хранилище, резервное копирование и централизованное управление. Но более глубокая автоматизация, управление жизненным циклом и отдельные корпоративные функции потребуют дополнительной настройки, внешних инструментов или более строгих регламентов. Поэтому Proxmox VE стоит рассматривать не как универсальную замену «один в один», а как практичную альтернативу для организаций, готовых осознанно проектировать инфраструктуру.
Отдельного внимания заслуживает и развитие инструментов централизованного управления Proxmox. Если в этой статье основное внимание уделено построению кластера Proxmox VE с Ceph, то следующий уровень эксплуатации связан с управлением несколькими кластерами, узлами и серверами резервного копирования из единой панели. Подробнее этот подход разобран в материале о Proxmox Datacenter Manager 1.0.
Для российских компаний, которые пересматривают стратегию виртуализации после VMware, Proxmox VE становится одним из наиболее заметных направлений. Он особенно уместен там, где есть внутренняя Linux-экспертиза, потребность в контроле затрат, интерес к открытым технологиям и готовность заранее протестировать связку оборудования, хранилища и гипервизора. В таком формате Proxmox VE может стать основой устойчивой локальной инфраструктуры на корпоративных серверах Dell, HPE, Lenovo, Supermicro и других x86-платформах.
Оцените статью и добавьте комментарий — будьте первым
Спасибо!
Комментарий успешно отправлен на модерацию! После модерации комментарий будет опубликован в ближайшее время!