როგორ გადავიტანოთ OpenVZ 6 კონტეინერი KVM სერვერზე თავის ტკივილის გარეშე

ყველას, ვისაც ცხოვრებაში ერთხელ მაინც დასჭირდა OpenVZ კონტეინერის სერვერზე გადატანა სრული KVM ვირტუალიზებით, შეექმნა გარკვეული პრობლემები:

• ინფორმაციის უმეტესობა უბრალოდ მოძველებულია და აქტუალური იყო OS-ებისთვის, რომლებმაც დიდი ხნის განმავლობაში გაიარეს 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 სერვერი, სრული 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-ზე (არ უნდა აგვერიოს ოპერაციული სისტემის განახლებაში - ჩვენ არ ვაახლებთ მას, ვაახლებთ მხოლოდ პაკეტებს და, თუ ის ჩამოვა, 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

დებიანი, უბუნტუ:

# apt-get install rsync -y

სხვას არც იქ და არც იქ არ ვაინსტალირებთ.

ნაბიჯი 3

ჩვენ ვჩერდებით CTID on 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-ის ქვეშ შექმენით ფაილი /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

მოდით შევასრულოთ რამდენიმე ნაბიჯი, რომელიც დაგვეხმარება ვირტუალური ტექნიკის გაშვებაში 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 დისტრიბუციებისთვის. ეს ოპერაციული სისტემა შეიძლება შეცდომით მოხვდეს მარადიულ ჩატვირთვაში

მარყუჟი ძალიან სწრაფად. ოდნავ დამახინჯებული შესრულება

უსიამოვნო, მაგრამ ადვილად გამოსწორებული, დამოკიდებულია OS ვერსიაზე.

წლის 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-ში როგორ მიმდინარეობს დატვირთვა და, იდეალურ შემთხვევაში, ყველაფერი ჩაიტვირთება უპრობლემოდ. მიუხედავად იმისა, რომ შესაძლებელია მიგრაციის შემდეგ გაჩნდეს გარკვეული კონკრეტული პრობლემები, ისინი სცილდება ამ სტატიის ფარგლებს და გამოსწორდება მათი წარმოშობისთანავე.

იმედი მაქვს, რომ ეს ინფორმაცია სასარგებლოა! 🙂

წყარო: www.habr.com