Миграция с VMware на Proxmox: как перенести инфраструктуру

После ухода VMware с российского рынка вопрос обновлений и поддержки решается сам собой: их нет. Компании переезжают на Proxmox VE — открытую платформу с активным развитием и без лицензионных ограничений. Разберём, как проходит такой переезд и где обычно спотыкаются.

Почему уезжают

Причины у всех примерно одинаковые:

  • нельзя купить и продлить лицензии, обновления безопасности недоступны;
  • официальной поддержки нет, а инфраструктура виртуализации — это то, что нельзя оставить без сопровождения;
  • смена модели лицензирования у вендора сделала продление дороже даже там, где оно возможно;
  • требования к импортозамещению и хранению данных в России.

Proxmox VE закрывает те же задачи: виртуальные машины, кластер, живая миграция, отказоустойчивость, резервное копирование, единый веб-интерфейс. Отличия есть, и о них ниже.

Что придётся принять как данность

Честно о различиях, чтобы переезд не стал неожиданностью:

  • Хранилище устроено иначе. Привычных томов VMFS нет; вместо них ZFS, LVM-thin, NFS или Ceph. Схему выбирают заново, а не переносят один в один.
  • Распределение нагрузки между узлами не автоматическое. Машины балансирует администратор, а не планировщик кластера.
  • Экосистема плагинов беднее. Часть смежных продуктов резервного копирования и мониторинга с Proxmox не работает — им находят замену.
  • Больше работы руками. Часть операций делается в консоли; веб-интерфейс закрывает повседневное, но не всё.

Взамен: отсутствие лицензионных платежей за сами возможности, открытые форматы дисков, снимки и репликация на уровне файловой системы, встроенный сервер резервного копирования.

Шаг 1. Инвентаризация

До первого переноса нужно составить список того, что вообще едет:

  • все виртуальные машины: операционная система, число ядер, память, диски и их реальная занятость;
  • сети и VLAN, к которым машины подключены, статические адреса и правила межсетевого экрана;
  • что критично, а что можно останавливать в рабочее время — от этого зависит порядок и окна;
  • привязки лицензий к оборудованию — это отдельная и самая неприятная тема;
  • чем сейчас делаются резервные копии и куда.

Здесь же честно оценивают, что переносить не нужно: в любой инфраструктуре, живущей несколько лет, находятся машины, которые давно никому не нужны. Переезд — хороший повод их не тащить.

Шаг 2. Подготовка целевой площадки

Новые узлы Proxmox настраиваются и проверяются до того, как на них поедет что-то боевое: схема дисков, сеть с нужными VLAN, хранилище, резервное копирование, доступы и мониторинг. Порядок действий — в статье про настройку Proxmox, а выбор дисковой схемы — в разборе файловой системы ZFS.

Отдельно считается место: на время переезда данные какое-то время существуют в двух экземплярах, и запаса «впритык» не хватит.

Шаг 3. Перенос машин

Способов несколько, выбирают по ситуации:

  • Встроенный импорт. Свежие версии Proxmox умеют подключаться к источнику и забирать машины сами — самый удобный путь, когда обе стороны доступны по сети.
  • Через файл образа. Машина выгружается в переносимый формат и импортируется на новый узел. Дольше, зато работает всегда и не зависит от связи между платформами.
  • Установка начисто и перенос данных. Для серверов приложений и баз это часто самый быстрый и чистый путь: новая система нужной версии, поверх — данные и настройки. Заодно избавляет от накопленного за годы мусора.
  • Средствами резервного копирования. Если копии делаются на уровне гостевой системы, машину можно просто восстановить в новую среду.

Шаг 4. Что сделать после переноса каждой машины

Именно здесь возникают почти все проблемы переезда:

  • Убрать гостевые дополнения прежней платформы и поставить драйверы VirtIO и гостевой агент. На Windows драйверы удобнее подложить до переноса — иначе система может не увидеть диск и не загрузиться.
  • Проверить режим загрузки: BIOS или UEFI на новой машине должен совпадать с тем, как система была установлена.
  • Починить сеть. Сетевой адаптер новый — в Linux имя интерфейса меняется, в Windows настройки уезжают в «скрытый» адаптер. Статические адреса прописываются заново.
  • Активация Windows и привязанные лицензии. Смена «железа» часто требует повторной активации; прикладное ПО с привязкой к оборудованию — тоже.
  • Аппаратные ключи 1С. Если использовались USB-ключи, планируют проброс или переход на программные лицензии — с получением новых пин-кодов у поставщика.
  • Проверить работу прикладной части, а не только факт загрузки: подключение к базам, печать, обмены, интеграции.

Шаг 5. Окно переключения и откат

Хороший план переезда всегда содержит ответ на вопрос «что делаем, если не взлетело». Практика такая:

  • исходные машины на прежней платформе не удаляются, а выключаются — до тех пор, пока новая среда не отработает штатно хотя бы неделю;
  • резервная копия снимается непосредственно перед переносом;
  • сначала едет что-то некритичное — на нём проверяют весь порядок действий;
  • боевые машины переносятся по одной, в согласованное окно, с проверкой сразу после запуска;
  • откат — это включение исходной машины обратно, и он должен занимать минуты.

Сколько длится окно, зависит в основном от объёма дисков и скорости сети между платформами. Файловый сервер на несколько терабайт и сервер 1С на сотню гигабайт — это принципиально разные сроки, поэтому оценивают каждую машину, а не «инфраструктуру целиком».

Частые ошибки переезда

  • переносить всё разом в одну ночь — при первой же неожиданности не остаётся времени ни на разбор, ни на откат;
  • не подложить драйверы VirtIO Windows заранее и получить синий экран при первом запуске;
  • забыть про лицензии, привязанные к оборудованию, и обнаружить это в понедельник утром;
  • не проверить работу прикладных систем, ограничившись «машина загрузилась»;
  • удалить исходные машины сразу после переноса;
  • не настроить резервное копирование на новой площадке в первый же день — самый опасный период как раз сразу после переезда;
  • оставить старую схему хранения «как было», не пересчитав нагрузку под новую файловую систему.

Что с 1С после переезда

Отдельный узел внимания, потому что 1С чувствительна к дисковой подсистеме и настройкам виртуальной машины. После переноса стоит проверить: не выдано ли машине избыточное число виртуальных ядер, какой у неё диск и как настроена файловая система под базы, работает ли сервер СУБД с прежними параметрами. Если после переезда «стало медленнее» — обычно причина именно здесь; типовые виновники разобраны в статье почему 1С тормозит на сервере.

Как мы это делаем

Мы проводим переезд целиком: обследуем текущую инфраструктуру, собираем и настраиваем узлы Proxmox, переносим машины по согласованному плану с окнами и возможностью отката, приводим в порядок сеть, лицензии и резервное копирование, проверяем работу прикладных систем вместе с вашими сотрудниками. Дальше — сопровождение кластера: обновления, инциденты, контроль копий и места.

Стоимость считаем после обследования — она зависит от числа машин, объёма данных и того, сколько всего придётся переделывать по дороге. Начать можно с оценки: настройка и сопровождение кластера Proxmox, телефон +7 495 780-66-50.

Добавить комментарий
Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *
Сайт использует cookie-файлы и обезличенный счётчик посещаемости Яндекс Метрики. Запись действий на страницах (Вебвизор, карта кликов) включается только после нажатия «Принять»; «Только обязательные» — сайт работает без записи действий. Подробнее — в политике использования cookies.
ПринятьТолько обязательные