Յուրաքանչյուր ոք, ով կյանքում գոնե մեկ անգամ անհրաժեշտ է եղել փոխանցել 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 սերվեր, ամբողջական արմատային մուտք դեպի հյուրընկալող մեքենա, բեռնարկղերը կանգնեցնելու/մոնտաժելու/գործարկելու/ջնջելու հնարավորություն
- KVM սերվեր, ամբողջական արմատային մուտք դեպի հյուրընկալող մեքենա, այն ամենով, ինչ դա ենթադրում է: Ենթադրվում է, որ ամեն ինչ արդեն կազմաձևված է և պատրաստ է գնալու:
Սկսենք փոխանցել
Նախքան փոխանցումը սկսելը, եկեք սահմանենք տերմիններ, որոնք կօգնեն ձեզ խուսափել շփոթությունից.
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-ի վրա (չշփոթել ՕՀ-ի թարմացման հետ. մենք այն չենք թարմացնում, մենք միայն թարմացնում ենք փաթեթները և, եթե այն հասնի, 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/[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-ի բաշխումների համար։ Այս ՕՀ-ն կարող է սխալմամբ բախվել հավերժական բեռնախցիկին
շատ արագ պտտվում է: մի փոքր խեղդող կատարում
տհաճ, բայց հեշտությամբ ամրագրված՝ կախված ՕՀ-ի տարբերակից:
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