ProHoster > блог > Администрација > Како да префрлите OpenVZ 6 контејнер на серверот KVM без главоболки

Како да префрлите 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. Малите верзии не се важни и нивното несовпаѓање не е толку критично, но главните верзии треба да бидат исти.

По креирањето на 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

Дебиан, Убунту:

# 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/[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

И за Убунту 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

Додадете коментар