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

გადაცემამდე დავრწმუნდეთ, რომ ყველაფერი ხელთ გვაქვს:

• OpenVZ სერვერი, სრული root წვდომა მასპინძელ მანქანაზე, კონტეინერების შეჩერების/დამონტაჟების/დაწყების/წაშლის შესაძლებლობა
• KVM სერვერი, სრული root წვდომა მასპინძელ მანქანაზე, ყველაფერთან ერთად, რაც გულისხმობს. ვარაუდობენ, რომ ყველაფერი უკვე კონფიგურირებულია და მზად არის წასასვლელად.

დავიწყოთ გადატანა

სანამ გადატანას დავიწყებთ, მოდით განვსაზღვროთ ტერმინები, რომლებიც დაგეხმარებათ თავიდან აიცილოთ დაბნეულობა:

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

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

უსიამოვნო, მაგრამ ადვილად გამოსწორებული, დამოკიდებულია 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