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

Все, которые някога са се нуждали да пренесат OpenVZcontainer на сървър с пълна виртуализация KVM, са се сблъсквали с определени проблеми:

Повечето информация е остаряла и е била актуална за ОС, които отдавна са достигнали EOL циклите.
Различните ОС предоставят различна информация и рядко се разглеждат възможни грешки при миграцията.
Понякога се налага да се справяте с конфигурации, които не желаят да работят след миграцията.

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

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

Небольшо обучение: какво е 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, пълен root достъп до хост машината, възможност за спиране/монтиране/стартиране/изтриване на контейнери.
Сървър KVM, пълен root достъп до хост машината, с всички произтичащи последствия. Предполага се, че всичко вече е настроено и готово за работа.

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

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

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

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

Стъпка 1

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

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

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

Извършваме няколко действия, които ще ни помогнат в стартирането на виртуалната машина след прехвърлянето от 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 групата вече съществуе[0m" || { groupadd -r polkitd && echo -e "e[1;33mДобавена липсваща група polkitd[0m" || echo -e "e[1;31mДобавянето на група polkitd се провали[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd потребителят вече съществуе[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Потребител за polkitd" polkitd && echo -e "e[1;33mДобавен липсващ потребител polkitd[0m" || echo -e "e[1;31mДобавянето на потребител polkitd се провали[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* проверката на rpm премина успешно[0m" || { echo -e "e[1;33mНулиране на собствеността и разрешенията на полкит* rpm[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

А за 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