Ինչպես փոխանցել 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 սերվեր, ամբողջական արմատային մուտք դեպի հյուրընկալող մեքենա, բեռնարկղերը կանգնեցնելու/մոնտաժելու/գործարկելու/ջնջելու հնարավորություն
• KVM սերվեր, ամբողջական արմատային մուտք դեպի հյուրընկալող մեքենա, այն ամենով, ինչ դա ենթադրում է: Ենթադրվում է, որ ամեն ինչ արդեն կազմաձևված է և պատրաստ է գնալու:

Սկսենք փոխանցել

Նախքան փոխանցումը սկսելը, եկեք սահմանենք տերմիններ, որոնք կօգնեն ձեզ խուսափել շփոթությունից.

KVM_NODE - KVM հյուրընկալող մեքենա
VZ_NODE - OpenVZ հյուրընկալող մեքենա
CTID - OpenVZ կոնտեյներ
VM - KVM վիրտուալ սերվեր

Միգրացիայի նախապատրաստում և վիրտուալ մեքենաների ստեղծում:

Քայլ 1

Քանի որ մենք պետք է տեղափոխենք կոնտեյները ինչ-որ տեղ, մենք կստեղծենք VM նման կոնֆիգուրացիայով KVM_NODE.
Կարեւոր! Դուք պետք է ստեղծեք վիրտուալ մեքենա նույն օպերացիոն համակարգում, որն այժմ աշխատում է CTID-ի վրա։ Օրինակ, եթե CTID-ն աշխատում է Ubuntu 14, ապա այն պետք է տեղադրեք նաև վիրտուալ մեքենայի վրա Ubuntu 14. Երկրորդական տարբերակները կարևոր չեն, և դրանց անհամապատասխանությունը այդքան էլ կարևոր չէ, բայց հիմնական տարբերակները պետք է նույնը լինեն։

VM-ն ստեղծելուց հետո մենք կթարմացնենք փաթեթները CTID-ի և VM-ի վրա (չշփոթել ՕՀ-ի թարմացման հետ. մենք այն չենք թարմացնում, մենք միայն թարմացնում ենք փաթեթները և, եթե այն հասնի, OS-ի տարբերակը հիմնականի ներսում: տարբերակ):

Համար 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 բաշխումներ։ Այս օպերացիոն համակարգը կարող է խափանվել մշտական ​​բեռնման ժամանակ՝ սխալի պատճառով։

շատ արագ պտտվում է: մի փոքր խեղդող կատարում

տհաճ, բայց հեշտությամբ ամրագրված՝ կախված ՕՀ-ի տարբերակից:

On 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-ում, թե ինչպես է բեռնումը զարգանում և, իդեալական, ամեն ինչ կբեռնվի առանց խնդիրների: Թեև հնարավոր է, որ միգրացիայից հետո որոշակի խնդիրներ ի հայտ գան, սակայն դրանք դուրս են այս հոդվածի շրջանակներից և առաջանալուն պես կշտկվեն։

Հուսով եմ, որ այս տեղեկատվությունը օգտակար է: 🙂

Source: www.habr.com