बिना सिरदर्द के OpenVZ 6 कंटेनर को KVM सर्वर पर कैसे स्थानांतरित करें

जिस किसी को भी कभी OpenVZ कंटेनर को पूर्ण-विकसित KVM वर्चुअलाइजेशन वाले सर्वर पर ले जाने की आवश्यकता हुई है, उसे कुछ समस्याओं का सामना करना पड़ा है:

• अधिकांश जानकारी पुरानी हो चुकी है और उन ऑपरेटिंग सिस्टम के लिए प्रासंगिक थी जो लंबे समय से EOL चक्र से गुजर चुके हैं
• विभिन्न ऑपरेटिंग सिस्टम हमेशा अलग-अलग जानकारी प्रदान करते हैं और कभी भी संभावित माइग्रेशन त्रुटियों पर विचार नहीं करते हैं
• कभी-कभी आपको ऐसे कॉन्फ़िगरेशन से निपटना पड़ता है जो माइग्रेशन के बाद काम नहीं करना चाहते।

जब आप एक सर्वर को माइग्रेट करते हैं, तो आप तुरंत कुछ न कुछ ठीक कर सकते हैं, लेकिन जब आप संपूर्ण क्लस्टर को माइग्रेट करते हैं, तो क्या होगा?

इस लेख में मैं आपको यह बताने का प्रयास करूंगा कि न्यूनतम डाउनटाइम के साथ OpenVZ कंटेनर को KVM में कैसे स्थानांतरित किया जाए तथा सभी समस्याओं का त्वरित समाधान कैसे किया जाए।

एक त्वरित परिचय: OpenVZ क्या है और KVM क्या है?

आइए शब्दावली में न जाकर सामान्य शब्दों में कहें:

OpenVZ - ऑपरेटिंग सिस्टम स्तर पर वर्चुअलाइजेशन को माइक्रोवेव ओवन पर भी तैनात किया जा सकता है, क्योंकि होस्ट मशीन पर सीपीयू निर्देशों और वर्चुअलाइजेशन तकनीकों की कोई आवश्यकता नहीं होती है।

केवीएम - पूर्ण वर्चुअलाइजेशन, सीपीयू की पूरी शक्ति का उपयोग करना और किसी भी चीज को, किसी भी तरह से, लंबाई और चौड़ाई में काटकर वर्चुअलाइज करने में सक्षम होना।

आम धारणा के विपरीत, पर्यावरण में होस्टिंग प्रदाता OpenVZ की ज़रूरत से ज़्यादा चर्चा हो रही है, लेकिन KVM की नहीं। सौभाग्य से, KVM की भी अब उतनी ही ज़रूरत से ज़्यादा चर्चा हो रही है जितनी उसके भाई की।

हम क्या स्थानांतरित करने जा रहे हैं?

स्थानांतरण के लिए परीक्षण विषयों के रूप में ओपनवीजेड पर उपलब्ध ऑपरेटिंग सिस्टम के पूरे जंगल का उपयोग करना पड़ा: CentOS (6 और 7 संस्करण), Ubuntu (14, 16 और 18 एलटीएस), Debian 7.

यह मान लिया गया था कि अधिकांश OpenVZ कंटेनरों में पहले से ही किसी प्रकार का LAMP चल रहा था, और कुछ में तो कुछ विशिष्ट सॉफ्टवेयर भी थे। अधिकतर, ये ISPmanager, VestaCP नियंत्रण पैनल के साथ कॉन्फ़िगरेशन थे (और अधिकतर, वर्षों तक अपडेट नहीं किए गए थे)। उनके स्थानांतरण अनुरोधों पर भी ध्यान दिया जाना चाहिए।

प्रवास संरक्षण के साथ किया जाता है आईपी ​​पते पोर्टेबल कंटेनर के लिए, हम यह मानेंगे कि कंटेनर का आईपी पता वीएम पर सुरक्षित है और बिना किसी समस्या के काम करेगा।

स्थानांतरण से पहले, आइए सुनिश्चित करें कि हमारे पास सब कुछ मौजूद है:

• ओपनवीज़ेड सर्वर, होस्ट मशीन तक पूर्ण रूट एक्सेस, कंटेनरों को रोकने/माउंट करने/शुरू करने/हटाने की क्षमता
• केवीएम सर्वर, होस्ट मशीन तक पूर्ण रूट पहुंच, तथा अन्य सभी सुविधाएं। यह माना जाता है कि सब कुछ पहले से ही कॉन्फ़िगर है और काम करने के लिए तैयार है।

चलिए स्थानांतरण शुरू करते हैं

स्थानांतरण शुरू करने से पहले, आइए कुछ शब्दों को परिभाषित करें जो भ्रम से बचने में मदद करेंगे:

केवीएम_नोड — KVM होस्ट मशीन
VZ_नोड - OpenVZ होस्ट मशीन
सीटीआईडी — ओपनवीज़ेड कंटेनर
VM — केवीएम वर्चुअल सर्वर

माइग्रेशन की तैयारी करना और वर्चुअल मशीन बनाना।

1 कदम

चूँकि हमें कंटेनर को कहीं और ले जाना है, इसलिए हम बनाएंगे VM इसी तरह के विन्यास के साथ केवीएम_नोड.
महत्वपूर्ण! आपको उसी ऑपरेटिंग सिस्टम पर एक वर्चुअल मशीन (VM) बनानी होगी जो वर्तमान में CTID पर चल रहा है। उदाहरण के लिए, यदि CTID चल रहा है Ubuntu 14, फिर आपको इसे वर्चुअल मशीन पर भी इंस्टॉल करना होगा। Ubuntu 14. मामूली संस्करण महत्वपूर्ण नहीं हैं और उनमें विसंगति इतनी गंभीर नहीं है, लेकिन प्रमुख संस्करण समान होने चाहिए।

VM बनाने के बाद, हम CTID और VM पर पैकेजों को अद्यतन करेंगे (OS को अद्यतन करने के साथ भ्रमित न हों - हम इसे अद्यतन नहीं करते हैं, हम केवल पैकेजों को अद्यतन करते हैं और यदि आवश्यक हो, तो मुख्य संस्करण के भीतर OS संस्करण को अद्यतन करते हैं)।

के लिए CentOS यह प्रक्रिया हानिरहित प्रतीत होती है:

# yum clean all
# yum update -y

और यह उतना ही हानिरहित है Ubuntu, Debian:

# apt-get update
# apt-get upgrade

2 कदम

हम स्थापित करते हैं सीटीआईडी, VZ_नोड и VM उपयोगिता rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

हम यहां या वहां कुछ भी स्थापित नहीं करते हैं।

3 कदम

हम रुक रहे हैं सीटीआईडी पर VZ_नोड टीम

vzctl stop CTID

छवि को माउंट करना सीटीआईडी:

vzctl mount CTID

/vz/root/ फ़ोल्डर पर जाएँसीटीआईडी और हम इसे पूरा करते हैं

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

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

आइए जुड़ें केवीएम_नोड और हमारा प्रक्षेपण 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 से माइग्रेट करने के बाद VM को लॉन्च करने में मदद करेंगी।
सर्वर पर 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; }

सभी सर्वरों पर, यदि Apache के लिए mod_fcgid स्थापित किया गया था, तो हम अधिकारों के साथ एक छोटा सा सुधार करेंगे, अन्यथा mod_fcgid का उपयोग करने वाली साइटें त्रुटि 500 ​​के साथ क्रैश हो जाएंगी:

chmod +s `which suexec` && apachectl restart

और अंत में, यह इसके लिए उपयोगी होगा Ubuntu, Debian वितरण। यह ऑपरेटिंग सिस्टम त्रुटि के साथ स्थायी बूट में क्रैश हो सकता है।

बहुत तेजी से लूपिंग. क्रियान्वयन को थोड़ा धीमा करना

अप्रिय, लेकिन ओएस संस्करण के आधार पर आसानी से ठीक किया जा सकता है।

पर 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 

हमने क्या किया? हमने मैसेजबस को बहाल किया, जो स्टार्टअप के लिए अनुपस्थित था। Debian/Ubuntu और modules_dep को हटा दिया गया, जो OpenVZ से आया था और कई कर्नेल मॉड्यूल को लोड होने से रोक रहा था।

6 कदम

हम VM को रीबूट करते हैं, VNC में जांचते हैं कि लोडिंग कैसे हो रही है और आदर्श रूप से सब कुछ बिना किसी समस्या के लोड हो जाएगा। यद्यपि माइग्रेशन के बाद कुछ विशिष्ट समस्याएं हो सकती हैं, लेकिन वे इस लेख के दायरे से बाहर हैं और जैसे ही वे उत्पन्न होंगी, उन्हें ठीक कर दिया जाएगा।

मुझे आशा है कि यह जानकारी उपयोगी होगी! 🙂

स्रोत: www.habr.com