Як перанесці OpenVZ 6 кантэйнер на KVM сервер без галаўнога болю

Кожны, каму спатрэбілася хаця б раз у жыцці перанесці OpenVZ кантэйнер на сервер з паўнавартаснай віртуалізацыяй KVM, сутыкаўся з некаторымі праблемамі:

• Большасць інфармацыі, банальна састарэла і было актуальна для ўжо даўно якія прайшлі EOL цыкл АС
• Па розных АС заўсёды падаецца розная інфармацыя, і ніколі не разглядаюцца магчымыя памылкі пры міграцыі
• Часам даводзіцца мець справу з канфігурацыямі, якія раз-пораз не жадаюць працаваць пасля міграцыі.

Калі пераносіш 1 сервер заўсёды можна нешта выправіць на хаду, а калі пераносіш цэлы кластар?

У гэтым артыкуле я пастараюся распавесці, як правільна міграваць 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.
Важна! Ствараць VM трэба менавіта на той аперацыйнай сістэме, якая зараз круціцца на 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 .

Пад чрутам ствараем файл /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 выканае перанос, спадзяемся, што ключы зразумелыя - перанос ажыццяўляецца з захаваннем сімлінкаў, правоў доступу, уладальнікаў і груп і адключана шыфраванне для большай хуткасці (можна было выкарыстоўваць які-небудзь хутчэйшы cipher, але гэта не так прынцыпова ў рамках дадзенай задачы) , таксама як адключана і сціск.

Пасля завяршэння выканання 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 дыстрыбутываў. Гэтая АС можа зваліцца ў вечны бут з памылкай

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