Proxmox VE ставится за двадцать минут, а вот настраивается правильно — за несколько часов. Разница между «работает» и «работает надёжно» прячется в деталях: разметке дисков, репозиториях, сети и резервном копировании. Разберём порядок, в котором мы поднимаем узлы у клиентов.
Что решить до установки
Три вопроса, ответы на которые потом изменить трудно:
- Схема дисков. Proxmox умеет ставиться на ZFS прямо из установщика — это даёт снимки, контрольные суммы и репликацию между узлами. Менять схему после установки означает переустановку, поэтому решайте сразу. Подробно про варианты — в статье про файловую систему ZFS.
- Один узел или кластер. Даже если сейчас узел один, стоит заранее продумать имена, адресацию и сеть: добавить узел в кластер позже проще, чем переименовывать существующий.
- Куда складывать резервные копии. Копии на том же сервере, где живут виртуальные машины, — это не резервные копии. Нужен отдельный диск, сетевое хранилище или отдельный сервер.
По железу: процессор с поддержкой аппаратной виртуализации (она должна быть включена в BIOS), память с запасом — ZFS забирает часть под кэш, диски желательно одинаковые. Аппаратные RAID-контроллеры для ZFS не нужны и вредны: файловой системе нужен прямой доступ к дискам, контроллер переводится в режим HBA.
Установка и разметка
Установщик Proxmox VE предлагает выбрать файловую систему. Практические ориентиры:
- ZFS RAID1 на двух дисках — базовый вариант для узла: система переживает отказ одного диска, доступны снимки и репликация.
- ZFS RAIDZ на трёх и более дисках — когда важнее объём, чем скорость случайной записи.
- ext4 или xfs на аппаратном RAID — если инфраструктура уже построена вокруг контроллера и менять её не планируете; тогда снимки будут только на уровне LVM-thin.
Отдельно задайте разумный размер системного раздела и оставьте место под будущее. На этом же шаге указывается имя узла — оно попадёт в конфигурацию кластера, менять его потом болезненно.
Первое, что делать после установки
Свежий узел из коробки настроен не для продакшена. Порядок действий:
- Репозитории. По умолчанию подключён enterprise-репозиторий, который требует подписки, и обновления не ставятся. Без подписки подключается репозиторий no-subscription. Это единственная причина ошибки при первом же обновлении, и она пугает новичков.
- Обновление системы. Полное обновление и перезагрузка до того, как на узле появятся рабочие машины.
- Время. Синхронизация времени обязательна: кластер и резервное копирование к ней чувствительны.
- Уведомления. Настроить отправку почты, иначе об ошибках резервного копирования вы узнаете от бухгалтерии, а не от сервера.
- Доступ. Отдельные учётные записи вместо общего root, двухфакторная аутентификация для администраторов, ограничение доступа к веб-интерфейсу по сети.
- Сертификат. Замена самоподписанного сертификата, чтобы браузер не ругался и никто не привыкал жать «продолжить».
Сеть: мосты и VLAN
Сетевая модель Proxmox проста: физический интерфейс включается в мост, к мосту подключаются виртуальные машины. Дальше начинаются варианты:
- Один мост без VLAN — все машины в одной сети. Подходит для маленькой инфраструктуры.
- Мост с поддержкой VLAN — машины раскладываются по сегментам, номер VLAN указывается в настройках сетевого адаптера машины. Так делается разделение на серверную сеть, пользовательскую и гостевую.
- Отдельные интерфейсы под задачи. В кластере трафик синхронизации и репликации лучше увести в отдельную сеть, чтобы он не конкурировал с пользовательским.
- Объединение интерфейсов — для отказоустойчивости или полосы, если коммутатор это поддерживает.
Проверяйте настройки сети до того, как узел уедет в стойку: ошибка в конфигурации моста лишает доступа к веб-интерфейсу, и лечится это уже консолью.
Хранилища
Proxmox различает типы хранилищ по назначению: под диски виртуальных машин, под образы, под резервные копии, под шаблоны контейнеров. Один и тот же ZFS-пул может обслуживать несколько ролей, но копии стоит держать отдельно.
Что учесть:
- для дисков машин на ZFS используются наборы данных — снимки делаются мгновенно;
- сетевые хранилища (NFS, SMB) удобны для образов и копий, но чувствительны к качеству сети;
- если планируется живая миграция машин между узлами без остановки, нужно общее хранилище — Ceph или внешний массив;
- место под копии считайте с запасом на глубину хранения, а не на одну копию.
Виртуальные машины и контейнеры
В Proxmox есть два способа запускать нагрузку. Виртуальные машины (KVM) — полноценная виртуализация с собственным ядром, подходит для Windows и любых систем. Контейнеры (LXC) — легковесные, делят ядро с узлом, стартуют мгновенно и экономят память, но только для Linux.
Практические мелочи, которые экономят потом часы:
- для дисков и сети выбирайте VirtIO — это заметно быстрее эмуляции устаревших устройств;
- для Windows заранее подготовьте образ с драйверами VirtIO, иначе установщик не увидит диск;
- ставьте гостевой агент — он даёт корректное выключение, синхронизацию времени и согласованные снимки;
- не выдавайте машинам больше ядер, чем реально нужно: избыточное число виртуальных процессоров замедляет работу, а не ускоряет;
- шаблоны и клоны экономят время, если однотипных машин много.
Резервное копирование
Встроенный механизм умеет делать копии по расписанию прямо из веб-интерфейса. Для небольшой инфраструктуры этого достаточно. Когда машин становится много, лучше отдельный Proxmox Backup Server: он дедуплицирует данные, поэтому хранить историю копий выходит дешевле, и умеет проверять их целостность.
Правила, которые мы закладываем в любой проект:
- копии лежат не на том же массиве, что и рабочие машины;
- есть копия на другой площадке — от пожара и шифровальщика;
- расписание не пересекается с пиковой нагрузкой;
- уведомления об ошибках приходят человеку, а не в пустоту;
- раз в месяц копия разворачивается и проверяется.
Кластер: когда он нужен
Кластер из нескольких узлов даёт общее управление, миграцию машин между узлами и автоматический перезапуск при отказе оборудования. Но за это платят сложностью: нужен кворум, отдельная сеть для синхронизации и понимание, что произойдёт при обрыве связи между узлами.
Для автоматического переключения нужно нечётное число голосов: три узла либо два узла и арбитр. На двух узлах без арбитра доступны репликация и ручное переключение — дешевле, но решение принимает человек.
Подробнее про режимы отказоустойчивости и то, чем репликация отличается от общего хранилища, — на странице услуги настройка и сопровождение кластера Proxmox.
Частые ошибки первых настроек
- оставлен enterprise-репозиторий — система не обновляется месяцами;
- ZFS на аппаратном RAID — теряются контрольные суммы и самовосстановление;
- памяти выделено под завязку, без запаса на кэш ZFS;
- резервные копии на том же пуле, где машины;
- нет уведомлений — об отказе диска узнают, когда встаёт второй;
- всё под root без второго фактора и с открытым в интернет интерфейсом;
- снимки используются как замена копиям: снимок живёт на том же диске и гибнет вместе с ним.
Если делать самому некогда
Мы проектируем и настраиваем кластеры Proxmox под задачу: подбираем схему дисков, собираем сеть и хранилище, переносим машины с VMware или Hyper-V, поднимаем резервное копирование и мониторинг, а дальше сопровождаем — обновления, инциденты, проверки копий. Работаем и на оборудовании клиента, и на своей площадке.
Стоимость считаем под задачу, обследование и оценку делаем до начала работ. Начать можно с аудита того, что уже собрано: настройка и сопровождение кластера Proxmox, телефон +7 495 780-66-50.
