🥇Kā migrēt OpenVZ 6 konteineru uz KVM serveri bez galvassāpēm

Ikviens, kuram vismaz vienu reizi dzīvē ir bijis nepieciešams pārsūtīt OpenVZ konteineru uz serveri ar pilnu KVM virtualizāciju, ir saskārusies ar dažām problēmām:

Lielākā daļa informācijas ir vienkārši novecojusi un attiecas uz operētājsistēmām, kuras jau sen bija izturējušas EOL ciklu
Par dažādām operētājsistēmām vienmēr tiek sniegta atšķirīga informācija, un iespējamās kļūdas migrācijas laikā nekad netiek ņemtas vērā
Dažkārt nākas saskarties ar konfigurācijām, kuras ik pa brīdim pēc migrācijas nevēlas darboties

Pārsūtot 1 serveri, jūs vienmēr varat kaut ko labot lidojuma laikā, bet, pārsūtot visu klasteru?

Šajā rakstā es mēģināšu jums pastāstīt, kā pareizi migrēt OpenVZ konteineru uz KVM ar minimālu dīkstāvi un ātru visu problēmu risinājumu.

Neliela izglītības programma: kas ir OpenVZ un kas ir KVM?

Mēs neiedziļināsimies terminoloģijā, bet teiksim vispārīgi:

OpenVZ — virtualizācija operētājsistēmas līmenī, to var izvietot pat mikroviļņu krāsnī, jo resursdatorā nav nepieciešamas CPU instrukcijas un virtualizācijas tehnoloģijas.

KVM - pilnvērtīga virtualizācija, izmantojot visu CPU jaudu un spēj virtualizēt jebko, jebkurā veidā, griežot to gareniski un šķērsām.

Pretēji izplatītajam uzskatam, vidē mitināšanas pakalpojumu sniedzēji OpenVZ ir pārpārdots, bet KVM nav. Par laimi pēdējam, KVM tagad ir tikpat labi pārpārdots kā tā brālis.

Ko mēs pārvedīsim?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

Tika pieņemts, ka lielākajā daļā OpenVZ konteineru jau darbojas kāda veida LAMP, un dažiem pat bija ļoti specifiska programmatūra. Visbiežāk tās bija konfigurācijas ar ISPmanager, VestaCP vadības paneli (un visbiežāk tās nav atjauninātas gadiem ilgi). Jāņem vērā arī viņu pārcelšanas pieprasījumi.

Migrācija tiek veikta ar saglabāšanu IP adreses Pārnēsājama konteinera gadījumā mēs pieņemsim, ka konteinera IP adrese tiek saglabāta virtuālajā mašīnā un darbosies bez problēmām.

Pirms pārsūtīšanas pārliecināsimies, ka mums viss ir pa rokai:

OpenVZ serveris, pilna root piekļuve resursdatoram, iespēja apturēt/uzmontēt/sākt/dzēst konteinerus
KVM serveris, pilna root piekļuve resursdatoram ar visu, ko tas nozīmē. Tiek pieņemts, ka viss jau ir konfigurēts un gatavs darbam.

Sāksim pārsūtīšanu

Pirms sākam pārsūtīšanu, definēsim terminus, kas palīdzēs izvairīties no neskaidrībām:

KVM_NODE - KVM resursdatora mašīna
VZ_NODE - OpenVZ resursdatora mašīna
CTID - OpenVZ konteiners
VM - KVM virtuālais serveris

Sagatavošanās migrācijai un virtuālo mašīnu izveide.

Solis 1

Tā kā konteiners kaut kur jāpārvieto, mēs izveidosim VM ar līdzīgu konfigurāciju KVM_NODE.
Svarīgi! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Pēc virtuālās mašīnas izveidošanas mēs atjaunināsim pakotnes CTID un virtuālajā mašīnā (nejaukt ar OS atjaunināšanu - mēs to neatjauninām, mēs atjauninām tikai pakotnes un, ja tā pienāk, OS versiju galvenajā sistēmā. versija).

Par CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Solis 2

Instalējiet uz CTID, VZ_NODE и VM lietderība rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Mēs neko citu neinstalējam ne tur, ne tur.

Solis 3

Mēs apstājamies CTID par VZ_NODE komanda

vzctl stop CTID

Attēla uzstādīšana CTID:

vzctl mount CTID

Dodieties uz mapi /vz/root/CTID un izpildīt

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Zem saknes izveidojiet failu /root/exclude.txt — tajā būs saraksts ar izņēmumiem, kuri nenokļūs jaunajā serverī.

/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

Pievienot KVM_NODE un palaidiet mūsu VMlai tas darbotos un būtu pieejams tīklā.

Tagad viss ir gatavs pārsūtīšanai. Aiziet!

Solis 4

Joprojām burvībā mēs uzstājamies

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

Komanda rsync veiks pārsūtīšanu, ceram, ka atslēgas ir skaidras - pārsūtīšana tiek veikta, saglabājot simboliskās saites, piekļuves tiesības, īpašniekus un grupas, un šifrēšana ir atspējota, lai nodrošinātu lielāku ātrumu (varētu izmantot kādu ātrāku šifru, bet šim uzdevumam tas nav tik svarīgi), kā arī ir atspējota saspiešana.

Pēc rsync pabeigšanas izejiet no chroot (nospiežot ctrl+d) un izpildiet

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Solis 5

Veiksim vairākas darbības, kas mums palīdzēs palaist virtuālo mašīnu pēc pārsūtīšanas no OpenVZ.
Uz serveriem ar Systemd izpildīsim komandu, kas palīdzēs mums pieteikties parastajā konsolē, piemēram, caur VNC servera ekrānu

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

Uz serveriem CentOS 6 и CentOS 7 Noteikti instalējiet jaunu kodolu:

yum install kernel-$(uname -r)

No tā serveri var ielādēt, taču pēc pārsūtīšanas tas var pārstāt darboties vai tikt izdzēsts.

Uz servera CentOS 7 jums ir jāpiemēro neliels PolkitD labojums, pretējā gadījumā serveris uz visiem laikiem avarēs:

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; }

Visos serveros, ja mod_fcgid for Apache tika instalēts, mēs veiksim nelielu labojumu ar tiesībām, pretējā gadījumā vietnes, kas izmanto mod_fcgid, avarēs ar kļūdu 500:

chmod +s `which suexec` && apachectl restart

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

cilpa pārāk ātri. nedaudz ierobežojot izpildi

nepatīkams, bet viegli labojams, atkarībā no OS versijas.

uz Debian 9 labojums izskatās šādi:

mēs veicam

dbus-uuidgen

ja mēs saņemam kļūdu

/usr/local/lib/libdbus-1.so.3: versija `LIBDBUS_PRIVATE_1.10.8′ nav atrasta

pārbaudiet LIBDBUS klātbūtni

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

ja viss ir kārtībā, mēs to darām

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15  libdbus-1.so.3

Ja tas nepalīdz, izmēģiniet otro iespēju.

Otrs problēmas risinājums ar nedaudz ierobežojot izpildi подходит практически для всех Ubuntu и Debian дистрибутивов.

Mēs veicam

bash -x /var/lib/dpkg/info/dbus.postinst configure

Un par Ubuntu 14, Debian 7 Papildus veicam:

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 и мешал загрузки многих модулей ядра.

Solis 6

Mēs pārstartējam VM, pārbaudām VNC, kā notiek ielāde, un ideālā gadījumā viss tiks ielādēts bez problēmām. Lai gan ir iespējams, ka pēc migrācijas parādīsies dažas īpašas problēmas, tās neietilpst šī raksta darbības jomā un tiks labotas, tiklīdz tās radīsies.

Es ceru, ka šī informācija ir noderīga! 🙂

Avots: www.habr.com