Проектирование
Считаем ресурсы под список сервисов, планируем разделение на виртуальные машины, схему хранилищ и сетей. Решаем, нужен один узел или кластер, и что делать при отказе оборудования.
План фиксируем до закупки, а не по ходу монтажа.
Разворачиваем платформу виртуализации, разделяем сервисы компании по виртуальным машинам и настраиваем резервное копирование с проверкой восстановления. За сам гипервизор платить не нужно — расходы только на оборудование и работы.
Когда 1С, файловое хранилище, домен, мониторинг и резервное копирование живут в одной операционной системе, любое обновление становится риском для всей компании, а разбор сбоя — расследованием: непонятно, какой из сервисов виноват.
Proxmox разделяет их на отдельные виртуальные машины на том же самом железе. Каждый сервис можно перезапустить, откатить на снапшот, перенести на другой сервер или восстановить из копии отдельно от остальных. Это не про экономию на оборудовании — это про управляемость.
Считаем ресурсы под список сервисов, планируем разделение на виртуальные машины, схему хранилищ и сетей. Решаем, нужен один узел или кластер, и что делать при отказе оборудования.
План фиксируем до закупки, а не по ходу монтажа.
Устанавливаем Proxmox VE, настраиваем дисковые пулы, RAID или ZFS, сетевые мосты и VLAN, доступ к веб-интерфейсу и репозитории обновлений.
Управляющий интерфейс выносим в отдельный сегмент сети.
Создаём машины под каждую роль: сервер 1С, файловый сервер, домен, мониторинг, терминальные сеансы. Лёгкие сервисы выносим в LXC-контейнеры, чтобы не тратить ресурсы впустую.
Шаблоны машин — чтобы новые сервисы разворачивались за минуты.
Объединяем узлы в кластер с общим хранилищем, настраиваем живую миграцию и автоматический перезапуск машин при отказе узла.
Обслуживать сервер можно днём: машины переезжают без остановки.
Разворачиваем отдельный сервер резервного копирования с дедупликацией, инкрементальными копиями и хранением на второй площадке. Настраиваем расписание и уведомления об ошибках.
Регулярно поднимаем копию и проверяем, что она восстанавливается.
Переносим виртуальные машины с VMware, Hyper-V и физических серверов. Конвертируем диски, ставим драйверы, проверяем работу сервисов до переключения.
Старая площадка остаётся доступной до подтверждения работоспособности.
Укажите, сколько виртуальных машин планируется и какой у них характер нагрузки — соберём ориентир по ресурсам. Точный состав уточняем по списку сервисов.
Считаем роли: 1С, файлы, домен, мониторинг, копии, тестовая среда. Лёгкие сервисы можно объединить в контейнеры.
Лёгкие — мониторинг, шлюзы, вспомогательные службы. Смешанная — типичный офис. Тяжёлая — активная работа с базами.
Ориентир по суммарным ресурсам узла. Точную конфигурацию и смету зафиксируем после разбора списка сервисов — бесплатно.
Мы не считаем, что Proxmox подходит всем и всегда. Вот как мы выбираем платформу под конкретную ситуацию.
| Платформа | Когда выбираем | О чём предупреждаем |
|---|---|---|
| Proxmox VE | Большинство проектов среднего бизнеса: нет платы за гипервизор, есть кластер, снапшоты, контейнеры и собственный сервер резервного копирования | Администрирование ближе к Linux: без документации и сопровождения обслуживать сложнее, чем привычные графические панели |
| Hyper-V | Инфраструктура целиком на Windows Server, есть лицензии и администратор, привыкший к экосистеме Microsoft | Стоимость лицензий и зависимость от поставок Microsoft |
| Российские платформы | Есть требования регулятора, реестр отечественного ПО или отраслевые нормы | Состав и стоимость сильно зависят от вендора — подбираем под конкретные требования |
| Без виртуализации | Один-единственный сервис на сервере, и он же единственный на всю компанию | Даже в этом случае снапшоты перед обновлением обычно окупают виртуализацию |
Proxmox разворачивается по-разному: одному узлу не нужен кластер, а трём узлам нужен кворум. Ниже три размера и то, что меняется при переходе между ними.
Для небольшой компании достаточно одного узла: на нём поднимаются виртуальные машины под роли, а данные лежат на локальных дисках в зеркале. Кластер здесь не нужен — он усложнит эксплуатацию, ничего не дав взамен.
Один узел Proxmox VE
├─ ВМ файлов
├─ ВМ базы 1С
└─ ВМ служб
│
Локальные диски в зеркале
│
Proxmox Backup Server
Второй узел появляется, когда обслуживание первого нельзя делать по ночам. Машины переносятся на живой узел, обновления идут по одному. Кворум для двух узлов обеспечивается отдельным голосующим устройством.
Узел 1 Узел 2
└───── общая сеть ─────┘
│
Устройство кворума
│
Proxmox Backup Server
│
Мониторинг узлов
От трёх узлов кластер получает кворум сам и может переживать отказ узла автоматически. Хранилище выносится общим, чтобы машина стартовала на любом узле. Это уже полноценная отказоустойчивость, а не просто удобство.
Кластер Proxmox (3 узла)
├─ Узел 1 ├─ Узел 2 ├─ Узел 3
│
Общее хранилище (Ceph или SAN)
│
Сервер резервных копий
│
Мониторинг и оповещения
Proxmox Backup Server, хранение копии вне площадки и проверка восстановления.
Подробнее →
Отдельная виртуальная машина под 1С и базу с правильной дисковой подсистемой.
Подробнее →
Серверы Supermicro, диски, ИБП и шкафы под кластер виртуализации.
Подробнее →Сама платформа распространяется свободно, лицензионных платежей за гипервизор нет. Платная подписка даёт доступ к стабильному репозиторию обновлений и технической поддержке вендора — она желательна для критичной инфраструктуры, но не обязательна. Расходы проекта складываются из оборудования и работ по внедрению.
Да. Диски конвертируются в подходящий формат, в гостевые системы устанавливаются нужные драйверы, после чего машина запускается в Proxmox. Windows-машины требуют дополнительного внимания к дисковому контроллеру. Порядок стандартный: переносим, проверяем работу сервиса, и только потом гасим старую площадку.
Ограничение задаёт не гипервизор, а ресурсы: ядра, память и скорость дисков. Десяток лёгких служебных машин спокойно живёт на одном узле среднего уровня, а две активные базы 1С могут занять его целиком. Поэтому конфигурацию считаем по списку сервисов, а не по числу машин.
Риск повреждения данных есть всегда, поэтому мы настраиваем ИБП с корректным завершением работы виртуальных машин при длительном отключении питания. Без этого никакая виртуализация не спасёт: базы данных особенно чувствительны к внезапному пропаданию света.
Да, это частый запрос. Проводим ревизию: смотрим хранилища, сеть, права доступа, состояние копий и обновлений, находим узкие места и предлагаем план исправления. Иногда достаточно донастройки, иногда честнее развернуть заново — скажем прямо, какой вариант дешевле в вашем случае.
Расскажите, какие сервисы должны работать и что есть сейчас. Предложим архитектуру и посчитаем работы.
Proxmox устанавливается за полчаса — и именно поэтому его часто ставят «на попробовать», а потом эта установка становится рабочей. Через год выясняется, что хранилище выбрано неудачно, сеть плоская, копии никто не проверял, а расширить кластер нельзя без переустановки. Ниже — решения, которые стоит принять осознанно на старте.
Тип хранилища определяет, что вы сможете делать дальше: снапшоты, тонкие тома, живая миграция между узлами. ZFS даёт снапшоты, контроль целостности данных и удобную репликацию между узлами, но требователен к оперативной памяти. Аппаратный RAID с LVM-Thin проще и предсказуемее, но лишает части возможностей ZFS. Общее хранилище нужно, если планируется кластер с автоматическим перезапуском машин. Поменять решение потом — это фактически переезд, поэтому мы обсуждаем его до закупки дисков.
Веб-интерфейс Proxmox — это полный контроль над всеми виртуальными машинами компании. Если он доступен из той же сети, где работают пользователи, любая заражённая рабочая станция получает шанс дотянуться до гипервизора. Мы выносим управление в отдельный сегмент, доступный только администраторам через VPN, и настраиваем разграничение прав внутри самого Proxmox. Сегментация сети — часть работ по сетевой инфраструктуре.
Снапшот живёт на том же хранилище, что и виртуальная машина. Он отлично спасает при неудачном обновлении: откатились за минуту и работаете дальше. Но при отказе дискового массива снапшоты исчезают вместе с машинами. Поэтому рядом всегда разворачивается Proxmox Backup Server с отдельным хранилищем, а одна копия уезжает на вторую площадку. Подробнее — на странице резервного копирования.
Автоматический перезапуск машин при отказе узла работает через кворум: узлы должны договориться, кто из них жив. В кластере из двух узлов кворум теряется при отказе любого из них, поэтому нужен третий голос — полноценный узел или лёгкий арбитр. Об этом лучше знать до покупки второго сервера, а не после.
Proxmox прощает меньше, чем коммерческие платформы с их графическими мастерами: часть операций делается из командной строки, а обновления требуют внимания к порядку действий. Поэтому мы всегда оставляем документацию — схему кластера, разбивку по машинам, порядок обновления и восстановления. Дальше либо ваш администратор работает по ней, либо мы берём платформу на сопровождение с мониторингом состояния узлов и свободного места.