☰

Как перенести выделенный физический сервер в виртуальную машину?

tag-icon • tag-icon backup replication tar file-transfer dd
Как перенести выделенный физический сервер в виртуальную машину?

У меня следующая проблема: у нас есть выделенный (голый) аппаратный сервер (Debian 10), к которому у нас нет прямого физического доступа. Теперь я хочу перенести все данные и приложения, которые находятся на этом сервере, на виртуальную машину и запустить ее на хосте KVM.

Почему я не устанавливаю приложение прямо в VM? Установка этого приложения (Perl-вещи с веб-сервером Apache, работающим на одном сервере около 10 лет) настолько сложна, что вы бы предпочли что-нибудь сломать. Поэтому никто не осмеливается это сделать. Но теперь нам нужно переехать, и по этой причине нам нужен какой-то умный обходной путь.

Я думал отключить все службы Perl и Apache и перенести жесткий диск по ddсети, но проблема в том, что на целевом хосте KVM меньше места, чем sdaна физическом сервере (в итоге он использует меньше места, чем доступно, sdaпросто слишком большой).

Второй вариант — установить те же пакеты на KVM с точно такими же номерами версий (согласно dpkg --list), отключить все службы на сервере bare metal (чтобы данные были согласованы) и поместить /etc, /var/, /usrи все остальное, что важно с сервера bare metal, в tarball и просто распаковать его на KVM. Конечно, я мог бы сделать это и через rsync, но принцип более или менее тот же.

Что вы думаете о последней идее?

У тебя есть другие идеи?

Как бы вы выполнили такую ​​задачу?

решение1

Какбеспокойствопопросили меня сделать это, я сам отвечу на свой вопрос :) Мое решение было не таким уж и сложнымбеспокойство's, но я все равно хотел бы поделиться этим с вами.

На самом деле я сначала проверил размеры инодов и блоков в обеих файловых системах, чтобы убедиться, что они идентичны друг другу (используя tune2fs).

Затем я отключил все службы, кроме экзистенциальных, таких как SSHd.

После этого я решил использовать apt-clone, а не копировать пакеты и двоичные файлы с одной машины на другую:

# on the physical machine:
apt-get install apt-clone
apt-clone clone packages
# on the virtual machine:
apt-get install apt-clone
apt-clone clone packages.apt-clone.tar.gz
# check on the VM:
vimdiff <(dpkg --list) physical_mchine_packages.txt

Далее я синхронизировал данные с помощью rsync. Каталоги, которые я синхронизировал:

  • /root
  • /etc(Я исключил такие файлы, как hostname, fstab, /default/grub, /network/interfacesи множество других каталогов, связанных с kernel/initram/lvm)
  • /usr(не все, зависит от используемого вами программного обеспечения)
  • /var(не все, зависит от используемого вами программного обеспечения)

Последним шагом была проверка того, указано ли имя хоста или IP-адрес старой физической машины в некоторых файлах конфигурации:

find . ! \( -path "*proc*" -o -path "*sys*" -o -path "*var/mail*" -o -path "*var/spool/mqueue*" -o -path "*var/log*" \) -type f -exec grep -iH -- "x.x.x.x" {} \;

Вот и все. Теперь все работает в VM. Надеюсь, я смог кому-нибудь помочь :)

решение2

(В этом ответе обсуждаетсяуровень блочного устройстваальтернатива, это наиболее подходящий вариант, если вы хотите сохранить нетронутыми конфигурацию разделов и менеджера загрузки при миграции на виртуальную машину)

Проблема, которую вы описываете, не обязательно возникает на практике. Яслучайнонедавно избегал этого:

но проблема в том, что целевой хост KVM имеет меньше места, чем sda с сервера bare metal

Вполне допустимо создавать, монтировать и редактировать разделы вредкийфайл, который (даже существенно) больше, чем файловая система хоста, — до тех пор, пока вы не сделаете ничего, что фактически запишет данные в пропущенные области файла.

То, что я сделал, было примерно fstrim / && systemctl stop appserver && mount -o remount,ro / && sync && dd bs=64k if=/dev/nvme0n1 | ssh vmhost dd bs=64k conv=sparse of=... Затем на хосте vm с помощью losetupя сделал изображение доступным для fdiskи resize2fsдля изменения его (виртуального) размера. Поскольку изображение уже содержало только нули в большей части своего конца, мои операции над ним не сильно увеличили его фактический размер.

В худшем случае потребность в пространстве для этого самого простого подхода будет в 3 раза больше содержимого данных старого сервера. Один раз для копирования разреженного образа, один раз для изменения размера (т. е. для перемещения всего его содержимого в начало без проделывания новых дыр в конце), а затем еще раз для преобразования необработанного образа диска в формат (или для перемещения тогдашнего образа на основе файла в его собственный логический том), используемый управлением виртуальной машины.

Некоторые моменты, на которые следует обратить внимание:

  • Способ выполнения этой операции должен зависеть от программного обеспечения/настроек планируемой виртуализации (например, если ваша текущая система загружается через EFI, но ваша виртуализация не поддерживает это, какой смысл делатькопия дискакогда вам вообще придется переделывать вещи, связанные с загрузчиком?)
  • fstrim (особенно в сочетании с плохими SSD или RAID) может быть опасным с точки зрения потери данных. Если вы не уверены, что это безопасная операция для вашей конфигурации, выполнитезапись огромного файла, содержащего только нулевые байтыальтернатива - нас интересует только возможность обнаружения неиспользуемых областей (обнуление), а не то, знает ли об этом диск.
  • Простое указание root readly выполняет работу, но дает результаткак будто сервер вышел из строя до перезапуска на виртуальной машине. Если вы копируете изображение после остановки приложений, это может бытьдостаточно хорошо: в конце концов вы ожидаете, что ваш сервер сможет продолжить работу после сбоя.

Связанный контент