Вместо введения: когда привычное решение перестаёт работать
Один из наших клиентов долгое время использовал инфраструктуру на базе VMware vSphere 7.0. Всё работало стабильно, пока внешние обстоятельства не разрушили привычный уклад. Введённые санкции привели к тому, что:
- Доступ к обновлениям VMware по подписке был заблокирован.
- Veeam Backup, используемый для резервного копирования, тоже перестал обновляться – по тем же причинам.
- Жёсткий HCL VMware (список совместимого оборудования) не позволял использовать некоторые устаревшие аппаратные компоненты – а без обновлений невозможно было перейти на свежие версии гипервизора.
- Особенно болезненной оказалась невозможность использовать программный RAID для NVMe-дисков – VMware просто не поддерживает эту функцию.
Клиент оказался в тупике: инфраструктура стареет, обновления недоступны, а требования к надёжности и производительности только растут.
Решение пришло со стороны открытого ПО – Proxmox.
Почему Proxmox?
Proxmox Virtual Environment (PVE) – это не просто альтернатива VMware. Это зрелая платформа виртуализации на основе Debian, которая предлагает:
- Полное отсутствие лицензионных ограничений и привязки к вендору.
- Работу с широким спектром оборудования (никакого жёсткого HCL).
- Встроенные инструменты для кластеризации, отказоустойчивости и резервного копирования.
- Мощную файловую систему ZFS с поддержкой программного RAID, сжатия и снимков.
- Нативную утилиту импорта виртуальных машин из ESXi.
В паре с Proxmox Backup Server (PBS) 4.1 клиент получал эффективную дедуплицированную систему бэкапов с инкрементным резервированием.
Что было до миграции
Текущая инфраструктура клиента насчитывала три физических сервера:
| Сервер | CPU | RAM | Диски | Роль |
| HP DL360 Gen9 | 2 x E5-2696v4 | 512Gb | 2 x 500 ГБ SSD + 1 x 4 ТБ NVM | Узлы кластера VMware |
| HP DL360 Gen9 | 2 x E5-2696v4 | 256Gb | 2 x 500 ГБ SSD + 1 x 4 ТБ NVM | Узлы кластера VMware |
| HP DL380 Gen9 | 2 x E5-2650v3 | 64Gb | 2 x 500 ГБ SSD + 3 x 18 ТБ HDD | Сервер резервного копирования (Veeam) |
Первые два сервера были объединены в кластер VMware под управлением vCenter. Третий выступал в роли бэкап-сервера. На кластере работало около 40 виртуальных машин с разнородной нагрузкой – от служебных сервисов до Windows RDP-серверов.
Главная ошибка, которую мы предотвратили
Изначально клиент хотел просто скопировать текущую конфигурацию на новые серверы: две машины в кластер и отдельный сервер резервного копирования. Мы объяснили, почему это приведёт к проблемам:
- Для работы кластера PVE нужен кворум (большинство нод).
- Кворум достигается при минимум трёх серверах – а если в кластере всего две ноды, при отказе одной из них кластер полностью теряет работоспособность.
- При двух нодах любая плановая остановка (например, для замены диска) останавливает все ВМ.
Кроме того, клиент не учитывал отказоустойчивость на уровне сети – один коммутатор становился единой точкой отказа.
Наше решение: отказоустойчивый кластер с запасом прочности
Мы предложили архитектуру, которая выдерживает потерю как минимум одной ноды и одного коммутатора без остановки сервисов.
Сетевая часть
- Два коммутатора Cisco Nexus N5K-5548-UP, объединённые в домен vPC (Virtual Port Channel). Это позволяет серверам подключаться к обоим коммутаторам одновременно, агрегировать каналы и не терять связь при отказе одного коммутатора.
- На каждом сервере настроен LACP с балансировкой Layer2+3.
Серверное железо (подобрано с учётом бюджета и оптимального соотношения цена/возможности)
| Роль | Модель | CPU | RAM | Системные диски | Диски данных |
| Ноды кластера PVE (4 шт.) | HP DL360 Gen9 | 2 x E5-2696v4 | 256Gb | 2 x 1 ТБ (HP Hardware RAID, зеркало) | 2 x 4 ТБ NVMe (зеркало ZFS) |
| Сервер резервного копирования PBS | HP DL360 Gen9 | 2 x E5-2640v4 | 32Gb | 2 x 1 ТБ (HP Hardware RAID, зеркало) | 2 x 8 ТБ SSD (зеркало ZFS, хранилище бэкапов) |
Почему 4 ноды, а не 2?
С четырьмя серверами кластер сохраняет кворум даже при выводе одной ноды на обслуживание или при её внезапном отказе. Мы также можем проводить live-миграцию ВМ без остановки. Клиент перешёл с двух узлов VMware на четыре узла Proxmox – это кардинальное повышение отказоустойчивости.
Уровни отказоустойчивости, которые мы заложили
- Сеть: два коммутатора Nexus с vPC и двойные подключения серверов.
- Хранение: HP Hardware RAID для системных дисков (проверенная надёжность) + ZFS mirror для NVMe-дисков данных – программный RAID, который VMware не поддерживает. ZFS даёт снимки, сжатие и защиту от «тихой» порчи данных.
- Кластер: четыре ноды – выход одной из строя не теряет кворум и не останавливает ВМ (благодаря live-миграции).
Спецификация прошла внутреннее согласование с клиентом, оборудование собрано и смонтировано в стойку.
Процесс развёртывания: от железа до готового кластера
Дальше началась «рутина» – но именно в таких рутинных операциях и проявляется наша экспертиза:
- Установка Proxmox VE 9.1 на все четыре сервера.
- Настройка vPC на коммутаторах Cisco Nexus.
- Формирование LACP-агрегатов на каждом сервере и проброс необходимых клиенту VLAN.
- Настройка HP Hardware RAID для системных дисков.
- Создание ZFS-пулов в конфигурации mirror для NVMe-дисков (обеспечивает отказоустойчивость на уровне хранилища данных).
- Объединение четырёх нод в кластер PVE.
- Установка и настройка Proxmox Backup Server 4.1 на выделенном сервере.
- Интеграция PBS в кластер в качестве бэкап-хранилища.
На выходе клиент получил полностью готовый, сбалансированный кластер с резервированием на всех уровнях.
Миграция виртуальных машин из VMware
Самый интересный этап – перенос 40 ВМ со старой среды на новую. И здесь Proxmox преподносит приятный сюрприз: встроенный инструмент импорта из ESXi.
Возможности импорта:
- Подключение к существующему ESXi-хосту или vCenter.
- Автоматическое преобразование дисков (VMDK → QCOW2 или raw).
- Перенос сетевых настроек (адаптеры, VLAN).
- Создание конфигурации ВМ в PVE практически «один в один».
Миграция выполняется прямо из веб-интерфейса PVE без дополнительных платных утилит. Клиент проведёт её собственными силами – от нас лишь консультационная поддержка.
Хотите, чтобы мы взяли миграцию на себя? Никаких проблем. Мы выполняем полный цикл «под ключ» – от оценки нагрузок до переключения трафика и тестирования.
Какие выгоды получил клиент
- Независимость от вендора – больше никаких санкционных блокировок и недоступных обновлений.
- Работа с современными NVMe-накопителями через программный RAID (ZFS mirror).
- Надёжность выше, чем раньше – четыре ноды вместо двух, резервирование сети и хранилища.
- Эффективное резервное копирование – PBS обеспечивает дедупликацию, сжатие и инкрементность, занимая меньше места, чем Veeam.
- Отсутствие дополнительных лицензий – Proxmox полностью open source, платить нужно только за поддержку (по желанию).
Заключение: доверьте миграцию профессионалам
Этот кейс – яркий пример того, как грамотный подход к выбору архитектуры и оборудования превращает вынужденный переход в возможность модернизировать инфраструктуру. Мы не просто заменили VMware на Proxmox – мы сделали кластер более отказоустойчивым, производительным и перспективным, чем он был.
Если ваш кластер VMware попал в санкционную ловушку – не ждите, пока оборудование устареет окончательно. Обращайтесь к нам:
- Проведём аудит текущей инфраструктуры.
- Подберём оптимальное железо и архитектуру.
- Развернём кластер Proxmox с нуля или поможем мигрировать.
- Настроим резервное копирование на PBS.
- Обучим вашу команду.
Готовы обсудить ваш проект? Свяжитесь с нами – мы предложим решение, которое впишется в бюджет и решит проблемы на годы вперёд.
Статья подготовлена на основе реального проекта миграции. Имена и некоторые детали изменены по просьбе клиента.