ProHoster > Блог > адміністрування > Як перенести OpenVZ 6 контейнер на KVM сервер без головного болю

Як перенести 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]

На серверах 6 CentOS и 7 CentOS обов'язково встановимо свіже ядро:

yum install kernel-$(uname -r)

Сервер може бути завантажений, але після перенесення воно може перестати працювати або буде видалено.

На сервері 7 CentOS необхідно застосувати невеликий фікс для 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

Додати коментар або відгук