Proxmox VE для виртуальных машин и контейнеров

Что такое Proxmox VE

Proxmox Virtual Environment — открытая платформа виртуализации, устанавливаемая на физический сервер. Она объединяет KVM/QEMU для виртуальных машин, LXC для Linux-контейнеров, web-интерфейс, API, кластер, сеть, storage, backup и high availability.

ISO содержит Debian GNU/Linux, Proxmox kernel и управляющие пакеты. Платформа занимает весь выбранный системный диск, поэтому установку планируют как развёртывание гипервизора, а не как обычное приложение на рабочем сервере.

Виртуальные машины и контейнеры

Виртуальная машина получает виртуальные CPU, память, диски, сеть и собственную гостевую ОС. Она подходит для Windows, Linux, appliance-образов и нагрузок, которым нужна изоляция отдельного ядра. Templates и clones ускоряют повторное развёртывание.

LXC-контейнер использует ядро узла и создаёт меньшие накладные расходы. Он подходит совместимым Linux-сервисам, но не заменяет VM для другой ОС или сильной границы доверия. Privileged containers и проброс устройств требуют отдельной оценки безопасности.

Узлы и кластер

Каждый физический сервер является узлом с собственными вычислительными ресурсами, сетями и локальными дисками. Кластер объединяет узлы в общий Datacenter: конфигурация реплицируется через pmxcfs, а администратор подключается к web-интерфейсу любого участника.

Кластер сам по себе не делает нагрузку отказоустойчивой. Он даёт централизованное управление и миграцию. Для HA нужны quorum, доступная копия дисков гостя, резерв CPU и памяти на оставшихся узлах, fencing и корректно настроенная HA-группа.

Quorum и границы двух узлов

Corosync принимает решения большинством голосов. При потере quorum cluster filesystem переходит в режим, защищающий от расходящихся изменений и split-brain. Для надёжного HA производитель рекомендует минимум три голоса и стабильную сеть с низкой задержкой.

В двухузловом кластере QDevice может дать третий голос, но не запускает VM, не хранит их диски и не заменяет третий вычислительный узел. Отказоустойчивость считают отдельно для управления, compute, storage, network и внешних зависимостей.

Сеть

Linux bridges подключают гостей к физическим интерфейсам, VLAN разделяют сегменты, bonds добавляют резервирование, а SDN централизует zones, VNets и subnets. Отдельно проектируют management, Corosync, migration, storage и guest traffic, если нагрузка и требования это оправдывают.

Изменение сетевой конфигурации гипервизора может одновременно отрезать управление и десятки гостей. Поэтому предусматривают out-of-band access, резервные интерфейсы, порядок применения и тестовый узел.

Хранилища

Proxmox VE работает с local directory, LVM-thin, ZFS, NFS, SMB/CIFS, iSCSI, Ceph и другими поддерживаемыми storage. Тип контента и возможности — snapshots, clones, shared access — зависят от backend.

Локальный ZFS даёт checksums, snapshots и replication, но диски остаются привязаны к узлу. Shared SAN/NAS упрощает migration, но становится общей зависимостью. Ceph распределяет данные между узлами и требует достаточного числа дисков, сети, памяти и эксплуатационной компетенции. ZFS и Ceph не размещают поверх аппаратного RAID-контроллера.

Как рассчитываются ресурсы

Официальный минимум для служб Proxmox VE в production — 2 ГБ RAM сверх памяти гостей. Для ZFS или Ceph приводится дополнительный ориентир около 1 ГБ на используемый ТБ. Это не профиль готового сервера: CPU, RAM, capacity, IOPS и network складываются из рабочих нагрузок.

Кластер рассчитывают по сценарию отказа. Если после потери одного узла остальные должны принять его VM, на них заранее оставляют CPU, RAM, storage и сетевой запас. Overcommit допустим только после измерения реального пика и понимания, какие гости могут конкурировать.

Резервные копии и восстановление

Встроенный vzdump создаёт backup VM и контейнеров по расписанию. Режим snapshot уменьшает простой при поддерживаемом storage и guest agent, но согласованность приложений внутри гостя всё равно проверяют. Копии не должны храниться только на тех же дисках или в том же кластере.

Proxmox Backup Server добавляет инкрементальную передачу, дедупликацию, verification, шифрование со стороны клиента и sync jobs. Это отдельный продукт и отдельный сервер, а не скрытый модуль Proxmox VE. Восстановление регулярно проверяют на изолированной сети.

Миграция на Proxmox VE

Перед переносом собирают гостевые ОС, диски, firmware, CPU flags, VLAN, IP, passthrough, RPO и допустимый простой. Тестовый импорт проверяет boot, drivers, сеть, время, application consistency и производительность до массовой волны.

Proxmox VE поддерживает импорт дисков и OVA, а также встроенные механизмы для отдельных источников. Способ переноса зависит от исходного гипервизора и storage. Старую VM не удаляют до приёмки приложения и проверенного rollback.

Миграция и обслуживание без простоя

Live migration переносит работающую VM между совместимыми узлами. Общий CPU model, доступ к сети и storage уменьшают ограничения. При локальных дисках добавляется storage migration; PCI passthrough, разные CPU features или высокая скорость записи могут потребовать остановки.

Обновления узлов выполняют по одному: переносят или останавливают гостей, проверяют quorum и резерв, обновляют пакеты, перезагружают новый kernel и возвращают узел после тестов. Нулевой простой достигается только там, где и приложение, и инфраструктура его поддерживают.

Доступ и безопасность

Права строятся из users, groups, roles и ACL на объектах. Доступ можно связать с LDAP или Active Directory, а административные учётные записи защищают MFA. API tokens выдают автоматизации с минимальной ролью и сроком жизни вместо пароля root.

Management UI не публикуют в интернет без защищённого контура. Используют доверенные сертификаты, VPN или bastion, firewall и отдельную сеть управления. Доступ к host shell сильнее доступа к одной VM и ограничивается соответственно.

Open Source, репозитории и подписка

Proxmox VE распространяется по GNU AGPLv3, и функции не делятся на бесплатные и платные. Enterprise Repository доступен по подписке и содержит лучше протестированные пакеты; производитель рекомендует его для production. Уровни подписки также различаются условиями поддержки.

pve-no-subscription не требует ключа, получает обновления раньше и предназначен для testing и non-production. Выбор этого репозитория на рабочем кластере — осознанный эксплуатационный риск, а не отдельная Community edition.

Обновления и эксплуатация

Узлы одной cluster-ветки держат на согласованных версиях. Перед major upgrade запускают официальный check tool, устраняют предупреждения, обновляют текущую ветку, читают known issues и проверяют backup. Ceph обновляется в поддерживаемом порядке отдельно от узлов.

Ежедневно контролируют alerts, task logs, SMART, ZFS or Ceph health, заполнение storage, backup jobs, quorum, replication и состояние HA. Мониторинг платформы выносят наружу, чтобы отказ web-интерфейса не скрывал событие.

Что даёт один узел

Один Proxmox VE host уже даёт web-управление, VM, LXC, storage, snapshots и backup. Он подходит для пилота, лаборатории и рабочих систем с документированным ручным восстановлением. Его проще сопровождать, но он остаётся единым доменом отказа.

Добавление второго узла облегчает migration и обслуживание, но не создаёт устойчивый quorum и не гарантирует HA. Переход к cluster меняет требования к сети, именам, времени, storage и подпискам, поэтому его проектируют до ввода критичных гостей.

Кому подходит Proxmox VE

• Команде нужна открытая платформа для Linux и Windows VM и Linux-контейнеров.

• Есть физические серверы и возможность спроектировать storage и сети под нагрузки.

• Нужны единое управление, migration, backup и постепенный переход к cluster или HA.

• Организация готова сопровождать Debian-based гипервизоры и регулярно проверять восстановление.

Из чего складывается стоимость

Лицензионной платы за функции нет. Стоимость формируют серверы, диски и сеть, запас на отказ, внешнее backup storage, подписки на каждый CPU socket узла, внедрение, migration, мониторинг и сопровождение. Дешёвый одиночный host и HA-кластер решают разные задачи и не сравниваются только по цене CPU и RAM.

Когда Proxmox VE не подходит

Платформа не превращает один сервер в отказоустойчивый кластер и не устраняет SPOF внешнего storage или сети. Она также не заменяет application-level clustering, план disaster recovery и владельцев данных.

Если workloads требуют сертифицированной экосистемы конкретного вендора, неподдерживаемого hardware passthrough, публичного облачного autoscaling или команда не готова сопровождать bare-metal узлы, ограничения проверяют до выбора платформы.