🥇Как да пренесете OpenVZ 6 контейнер на KVM сървър без главоболия

Все, кто хоть раз в жизни переносил OpenVZ контейнер на сервер с полноценной виртуализацией KVM, сталкивались с определёнными проблемами:

Большая часть информации уже устарела и была актуальна для давно завершившихся EOL циклов ОС.
Различные ОС предлагают различную информацию, и никогда не рассматриваются возможные ошибки при миграции.
Иногда приходится иметь дело с конфигурациями, которые не хотят работать после миграции.

Когда переносишь один сервер, всегда можно что-то исправить на ходу, а что делать, если переносишь целый кластер?

В этой статье я постараюсь объяснить, как правильно мигрировать OpenVZ контейнер на KVM с минимальным временем простоя и быстрым решением всех проблем.

Небольшой ликбез: что такое OpenVZ и что такое KVM?

Не будем углубляться в терминологию, ограничимся общими чертами:

OpenVZ — виртуализация на уровне операционной системы, которую можно развернуть даже на микроволновой печи, так как нет необходимости в инструкциях CPU и технологиях виртуализации на хост-машине.

KVM — полноценная виртуализация, использующая всю мощь CPU и способная виртуализировать что угодно, как угодно, в любых комбинациях.

Вопреки распространённому мнению, что в среде хостинг-провайдеров OpenVZ оверселлится, а KVM — нет, к счастью для последних, KVM теперь оверселлится ничуть не хуже своего собрата.

Что мы будем переносить?

В качестве подопытных для переноса использовались все операционные системы, доступные на OpenVZ: CentOS (версии 6 и 7), Ubuntu (14, 16 и 18 LTS), Debian 7.

Предполагалось, что на большинстве контейнеров OpenVZ уже работает какая-никакая LAMP, а некоторые даже содержат специфическое программное обеспечение. Чаще всего это были конфигурации с панелями управления ISPmanager, VestaCP (и чаще всего, не обновляемые годами). Необходимо учесть и их требования к переносу.

Миграция осуществляется с сохранением IP адреси переносимого контейнера, будем считать, что IP, который принадлежал контейнеру, остается на VM и будет работать без проблем.

Перед переносом убедимся, что у нас есть всё необходимое:

Сервер OpenVZ, полный рут-доступ к хост-машине, возможность останавливать/монтировать/запускать/удалять контейнеры.
KVM сървър, пълен рут-достъп до хост машината с всички произтичащи от него права. Предполага се, че всичко вече е настроено и готово за работа.

Да преминем към прехвърляне

Преди да започнем прехвърлянето, нека уточним термините, които ще ни помогнат да не се заплетем:

KVM_NODE — хост машина KVM
VZ_NODE — хост машина OpenVZ
CTID — контейнер OpenVZ
VM — виртуален сървър KVM

Подготовка за прехвърляне и създаване на виртуални машини.

Стъпка 1

Тъй като трябва да намерим място за прехвърляне на контейнера, ще създадем VM с аналогична конфигурация на KVM_NODE.
Важно! Виртуалната машина трябва да се създаде точно на тази операционна система, която в момента работи на CTID. Например, ако на CTID е инсталиран Ubuntu 14, то и на VM трябва да се инсталира Ubuntu 14. Минорните версии не са толкова важни и тяхното несъответствие не е толкова критично, но основните версии трябва да бъдат идентични.

След създаването на VM, ще актуализираме пакетите на CTID и на VM (да не се бърка с актуализация на ОС — не актуализираме нея, актуализираме само пакетите и, ако дойде, версията на ОС в рамките на основната версия).

За CentOS този процес изглежда безобиден:

# yum clean all
# yum update -y

И не по-малко безобиден за Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Стъпка 2

Инсталираме на CTID, VZ_NODE и VM утилита rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Не инсталираме нищо повече нито там, нито там.

Стъпка 3

Спираме CTID на VZ_NODE с командата

vzctl stop CTID

Монтиране на образ CTID:

vzctl mount CTID

Преминаваме в папката /vz/root/CTID и изпълняваме

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Под chroot създаваме файла /root/exclude.txt — той ще съдържа списък с изключения, които няма да бъдат прехвърлени на новия сървър.

/boot
/proc
/sys
/tmp
/dev
/var/lock
/etc/fstab
/etc/mtab
/etc/resolv.conf
/etc/conf.d/net
/etc/network/interfaces
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/lib/modules
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
/etc/ips
/etc/ipaddrpool
/etc/ips.dnsmaster
/etc/resolv.conf
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-ens3

Свързваме се с KVM_NODE и стартираме нашия VM, за да работи и да бъде достъпен по мрежата.

Сега всичко е готово за прехвърляне. Поехме!

Стъпка 4

Все още под chroot изпълняваме

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

Командата rsync ще извърши прехвърлянето, надяваме се, че ключовете са ясни — прехвърлянето се извършва с запазване на символични линкове, права на достъп, собственици и групи и е деактивирано шифрирането за по-висока скорост (можеше да се използва някакъв по-бърз шифър, но това не е толкова принципно в рамките на тази задача), както е деактивирано и компресията.

След завършване на изпълнението на rsync, излизаме от chroot (чрез ctrl+d) и изпълняваме

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Стъпка 5

Ще извършим няколко действия, които ще ни помогнат да стартираме VM след прехвърлянето от OpenVZ.
На сървъри с Systemd ще изпълним команда, която ще ни помогне да се логнем в стандартната конзола, примерно, през VNC екрана на сървъра.

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

На сървърите CentOS 6 и CentOS 7 задължително ще инсталираме свежо ядро:

yum install kernel-$(uname -r)

Сървърът може да бъде зареден от него, но след преместване може да спре да работи или да бъде изтрит.

На сървъра CentOS 7 е необходимо да приложим малък фикс за PolkitD, в противен случай сървърът ще изпадне в вечен бут:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already exists e[0m" || { groupadd -r polkitd && echo -e "e[1;33mAdded missing polkitd group e[0m" || echo -e "e[1;31mAdding polkitd group FAILED e[0m"; }

getent passwd polkitd >/dev/null
&& echo -e "e[1;32mpolkitd user already exists e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd && echo -e "e[1;33mAdded missing polkitd user e[0m" || echo -e "e[1;31mAdding polkitd user FAILED e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passed e[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & perms e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

На всички сървъри, ако е инсталиран mod_fcgid за Apache, ще изпълним малък фикс с правата, в противен случай сайтовете, използващи mod_fcgid, ще падат с грешка 500:

chmod +s `which suexec` && apachectl restart

И накрая, полезно е за дистрибуции Ubuntu и Debian. Тази ОС може да изпадне в вечен бут с грешка

looping too fast. throttling execution a little

неприятно, но лесно се фиксира, в зависимост от версията на ОС.

На Debian 9 фиксът изглежда така:

изпълняваме

dbus-uuidgen

ако получим грешка

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

проверяваме наличието на LIBDBUS

ls -la /lib/x86_64-linux-gnu | grep dbus
libdbus-1.so.3 -> libdbus-1.so.3.14.15 
libdbus-1.so.3.14.15 <-- нужен този
libdbus-1.so.3.14.16

ако всичко е наред, изпълняваме

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15 libdbus-1.so.3

Ако не помогне — пробваме втория вариант.

Вторият вариант за решение на проблема с throttling execution a little подходящ е практически за всички дистрибуции на Ubuntu и Debian.

Изпълняваме

bash -x /var/lib/dpkg/info/dbus.postinst configure

Allowed Logout URLs Ubuntu 14, Debian 7 допълнително изпълняваме:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh

Какво направихме? Възстановихме messagebus, който липсваше за стартиране на Debian/Ubuntu и изтрихме modules_dep, който дойде от OpenVZ и пречеше на зареждането на много модули на ядрото.

Стъпка 6

Рестартираме VM, проверяваме в VNC как протича зареждането и в идеалния случай — всичко ще се зареди без проблеми. Въпреки това, е възможно да се появят някои специфични проблеми след миграцията — но те излизат извън обхвата на тази статия и ще се поправят при появата им.

Надявам се, че тази информация ще бъде полезна! 🙂

Източник: habr.com