Миграция на serverplus

serverplus построен на OpenStack, поэтому перенести на него можно практически что угодно: виртуальные машины с других облаков и VPS, серверы из собственной серверной, отдельные сайты и базы данных. Ниже — как спланировать переезд, три рабочих способа и как свести простой к минимуму.

С чего начать: инвентаризация

Перед переездом составьте список того, что переносите, — это половина успеха.

• Серверы: ОС и версия, размер дисков, объём данных, установленное ПО.
• Зависимости: какие сервисы с кем общаются (веб → база → кэш), внешние интеграции, адреса и порты.
• Данные: где лежат файлы и базы, их объём — от него зависит время переноса.
• Домены и DNS: какие записи указывают на старые адреса; заранее снизьте TTL.
• Окно простоя: когда переключение будет наименее болезненным.

Три способа миграции

Выбор зависит от того, что переносите и насколько важно сохранить систему «как есть».

Способ 1. Перенос данных на новый сервер (чаще всего)

Поднимаете чистый сервер в serverplus, ставите ПО и переносите только данные. Дольше в настройке, но вы получаете свежую систему без накопленного «мусора» и старых проблем. Подходит для большинства сайтов и приложений.

Способ 2. Перенос образа диска (lift-and-shift)

Снимаете образ старого сервера целиком, загружаете его в serverplus и запускаете как есть. Быстро и без пересборки, но образ должен «уметь» работать в OpenStack: поддержка virtio-драйверов и, желательно, cloud-init. Подходит, когда систему проще перенести, чем настроить заново.

Способ 3. Перенос отдельных дисков и томов

Если нужно перенести только диск с данными (например, том базы данных), его можно загрузить как отдельный том и подключить к серверу в serverplus. Часто комбинируется со способом 1.

Перенос файлов и баз данных

Файлы — через rsync (можно повторять, докачивая только изменения):

rsync -aAXz --info=progress2 -e ssh /var/www/  user@<new-IP>:/var/www/

PostgreSQL:

# on the old server
pg_dump -Fc mydb > mydb.dump
scp mydb.dump user@<new-IP>:~

# on the new server
pg_restore -d mydb mydb.dump

MySQL / MariaDB:

mysqldump mydb | gzip > mydb.sql.gz
scp mydb.sql.gz user@<new-IP>:~

gunzip < mydb.sql.gz | mysql mydb

Для больших объёмов удобно временно сложить данные в объектное S3-хранилище serverplus и скачать уже на новом сервере — это быстрее и надёжнее прямого копирования между машинами.

Загрузка образа диска в serverplus

Если выбрали lift-and-shift: снимите образ диска, при необходимости сконвертируйте в qcow2 и загрузите в образы (Glance).

# convert (if the source is raw/vmdk)
qemu-img convert -O qcow2 disk.raw disk.qcow2

# upload the image to serverplus
openstack image create --disk-format qcow2 --container-format bare --file disk.qcow2 my-migrated-image

# launch a server from the uploaded image
openstack server create --image my-migrated-image --flavor m1.small --network private --key-name my-key migrated-vm

Чтобы образ загрузился и заработал. В системе заранее должны быть virtio-драйверы (диск и сеть), включён cloud-init или заранее заданы доступ по SSH-ключу и сетевые настройки, а загрузчик (GRUB) не привязан к старым именам дисков. Иначе сервер поднимется, но не будет виден по сети или не загрузится.

Особый случай: Windows и Hyper-V

Windows-серверы (в том числе из Hyper-V) переносятся тем же lift-and-shift, но требуют подготовки — иначе Windows не загрузится в OpenStack. Ключевое: заранее поставить VirtIO-драйверы и cloudbase-init.

Подготовка Windows (до переноса)

• VirtIO-драйверы. На работающей Windows установите драйверы диска (viostor) и сети (netkvm) из пакета virtio-win. Без них после переезда будет синий экран 0x7B (INACCESSIBLE_BOOT_DEVICE) или пропадёт сеть.
• cloudbase-init — аналог cloud-init для Windows. Задаёт пароль администратора, имя хоста и сеть при первом старте. Установите заранее.
• Удалённый доступ. Включите RDP и правило файрвола на порт 3389 (лучше — через cloudbase-init).
• Лицензия. Заранее согласуйте с serverplus вопрос лицензирования Windows (своя лицензия или предоставляется провайдером).

Экспорт и конвертация из Hyper-V

Hyper-V хранит диски в формате VHD/VHDX. Перед конвертацией объедините контрольные точки (checkpoints), чтобы остался один файл без разностных дисков (AVHDX).

# PowerShell on the Hyper-V host: stop cleanly and merge checkpoints
Stop-VM -Name "MyWinVM"
Get-VMSnapshot -VMName "MyWinVM" | Remove-VMSnapshot   # merges into the base VHDX

Затем сконвертируйте диск в qcow2 (qemu-img умеет читать VHDX):

qemu-img convert -p -O qcow2 MyWinVM.vhdx windows.qcow2

Загрузка образа с нужными свойствами

При создании образа задайте свойства, чтобы Windows увидел диск и сеть, а для Gen2 — UEFI:

openstack image create --disk-format qcow2 --container-format bare \
  --property os_type=windows \
  --property hw_disk_bus=virtio \
  --property hw_vif_model=virtio \
  --property hw_qemu_guest_agent=yes \
  --file windows.qcow2 win-server-2022

# for Hyper-V Generation 2 (UEFI) add:
#   --property hw_firmware_type=uefi

Поколение имеет значение. Hyper-V Gen1 — это BIOS, Gen2 — UEFI. Свойство hw_firmware_type=uefi нужно только для Gen2. Уточните в панели или поддержке serverplus, поддерживается ли UEFI-загрузка; если нет — переносите Gen1-диск (BIOS).

Первый запуск

• Откройте в security group порт 3389 (RDP) и выдайте серверу floating IP.
• После старта загрузятся VirtIO-драйверы, cloudbase-init задаст пароль администратора — подключайтесь по RDP на внешний адрес.
• Проверьте диспетчер устройств (нет «неизвестных устройств»), сеть и активацию Windows.

Сеть и переключение DNS

Пока старый сервер ещё работает, подготовьте в serverplus сеть, floating IP и security groups (откройте только нужные порты). Затем переключите трафик:

• Заранее (за сутки-двое) снизьте TTL DNS-записей до 300 секунд — чтобы переключение прошло быстро.
• В момент переезда поменяйте A-записи на новый floating IP.
• Старый сервер не удаляйте — держите его до полной проверки, чтобы был быстрый откат.

Как свести простой к минимуму

Не переносите всё в одно окно. Сделайте предварительную синхронизацию заранее (основной объём данных), а в короткое окно простоя — только финальную досинхронизацию изменений и переключение DNS.

# beforehand — full pass
rsync -aAXz /var/www/  user@<new-IP>:/var/www/

# during the downtime window — only changes, plus deletions
rsync -aAXz --delete /var/www/  user@<new-IP>:/var/www/

Проверка после переключения

• Сайт/приложение открывается по новому адресу, формы и логин работают.
• База отвечает, данные на месте и актуальны.
• Внешние интеграции (платежи, почта, API) работают с новых адресов.
• SSL-сертификат валиден (перенесите или перевыпустите под новый сервер).

Частые вопросы

Загруженный образ не грузится или не виден по сети. Почти всегда это отсутствие virtio-драйверов или cloud-init в образе. Проще собрать чистый сервер (способ 1) и перенести данные, чем чинить чужой образ.

На новом сервере нет интернета. Сеть должна иметь роутер с внешним шлюзом, а серверу нужен floating IP.

Перенос идёт слишком медленно. Гоните большой объём через объектное хранилище S3, сжимайте данные (rsync -z), а для БД используйте дампы.

Windows: синий экран 0x7B при загрузке. Не установлен VirtIO-драйвер диска (viostor) до конвертации. Поставьте virtio-win на исходной Windows и повторите; либо временно загрузите с шиной SATA/IDE, установите драйвер и переключитесь на virtio.

Windows: после переноса нет сети. Нет драйвера netkvm или образ создан без hw_vif_model=virtio.

Windows: не удаётся войти. Используйте cloudbase-init, чтобы задать пароль администратора при первом старте.

Не хочу заниматься этим сам. У serverplus есть услуга переноса инфраструктуры — можно обратиться в поддержку за сопровождением миграции.

Чеклист миграции

• Сделан бэкап данных на старой стороне (до начала переезда).
• Подготовлены сеть, floating IP и security groups в serverplus.
• TTL DNS снижен заранее.
• Данные перенесены и проверены; сделана финальная досинхронизация.
• DNS переключён, приложение и SSL проверены.
• Старый сервер сохранён до подтверждения, что всё работает.