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

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

• По-голямата част от информацията просто е остаряла и е подходяща за операционни системи, които отдавна са преминали цикъла EOL
• За различните операционни системи винаги се предоставя различна информация и никога не се вземат предвид възможните грешки по време на миграцията
• Понякога трябва да се справяте с конфигурации, които от време на време не искат да работят след миграцията

Когато прехвърляш 1 сървър винаги можеш да оправиш нещо в движение, а когато прехвърляш цял клъстер?

В тази статия ще се опитам да ви кажа как правилно да мигрирате OpenVZ контейнер към KVM с минимално време на престой и бързо решение на всички проблеми.

Малка образователна програма: какво е OpenVZ и какво е KVM?

Няма да навлизаме в терминологията, а ще кажем най-общо:

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

KVM - пълноценна виртуализация, използваща цялата мощност на процесора и способна да виртуализира каквото и да е, разрязвайки го надлъж и напречно.

Противно на общоприетото схващане, че сред хостинг доставчиците OpenVZ ще стане свръхпродаден, но KVM няма - за щастие на последния, KVM сега е свръхпродаден не по-лошо от брат си.

Какво ще пренесем?

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

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

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

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

• OpenVZ сървър, пълен root достъп до хост машината, възможност за спиране/монтиране/стартиране/изтриване на контейнери
• KVM сървър, пълен root достъп до хост машината, с всичко, което предполага. Предполага се, че всичко вече е конфигурирано и готово за работа.

Да започнем прехвърлянето

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

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

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

Стъпка 1

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

След като създадем VM, ние ще актуализираме пакетите на CTID и на VM (да не се бърка с актуализирането на OS - ние не го актуализираме, ние само актуализираме пакетите и, ако пристигне, версията на OS в рамките на основния версия).

За 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 .

Под root създайте файл /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

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

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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

На сървъри CentOS 6 и CentOS 7 Не забравяйте да инсталирате ново ядро:

yum install kernel-$(uname -r)

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

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

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

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

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passede[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & permse[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. Тази операционна система може да се срине при вечно зареждане с грешка

зацикля твърде бързо. забавяне на изпълнението малко

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

На Debian 9 корекцията изглежда така:

изпълняваме

dbus-uuidgen

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

/usr/local/lib/libdbus-1.so.3: версия `LIBDBUS_PRIVATE_1.10.8` не е намерена

проверете наличието на 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

Ако не помогне, опитайте втората опция.

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

Ние изпълняваме

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

И за 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 как напредва зареждането и в идеалния случай всичко ще се зареди без проблеми. Въпреки че е възможно някои специфични проблеми да се появят след миграцията, те са извън обхвата на тази статия и ще бъдат коригирани, когато възникнат.

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

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