🥇Како да се мигрира контејнерот 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-адресата на контејнерот е задржана на виртуелната машина и ќе работи без проблеми.

Пред да се префрлиме, да се увериме дека имаме сè при рака:

OpenVZ сервер, целосен root пристап до машината домаќин, можност за запирање/монтирање/стартување/бришење контејнери
KVM сервер, целосен root пристап до машината домаќин, со сето она што го подразбира. Се претпоставува дека сè е веќе конфигурирано и подготвено за работа.

Да почнеме да пренесуваме

Пред да започнеме со преносот, да ги дефинираме термините што ќе ви помогнат да избегнете забуна:

KVM_NODE - Машина за домаќин на KVM
VZ_NODE - Машина за домаќин на OpenVZ
CTID - Контејнер OpenVZ
VM - KVM виртуелен сервер

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

Чекор 1

Бидејќи треба да го преместиме контејнерот некаде, ќе создадеме VM со слична конфигурација на KVM_NODE.
Важно! Треба да креирате виртуелна машина на истиот оперативен систем што моментално работи на CTID. На пример, ако CTID работи Ubuntu 14, тогаш треба да го инсталирате и на виртуелната машина 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 .

Под коренот, креирајте датотека /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/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 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