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

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

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

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

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

एक छोटा शैक्षिक कार्यक्रम: OpenVZ क्या है और KVM क्या है?

हम शब्दावली में गहराई से नहीं जाएंगे, लेकिन सामान्य शब्दों में कहेंगे:

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

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

आम धारणा के विपरीत कि होस्टिंग प्रदाताओं के बीच ओपनवीजेड ओवरसोल्ड हो जाएगा, लेकिन केवीएम नहीं - सौभाग्य से बाद के लिए, केवीएम अब अपने भाई से भी बदतर नहीं है।

हम क्या लेकर जायेंगे?

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

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

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

स्थानांतरित करने से पहले, आइए सुनिश्चित करें कि हमारे पास सब कुछ उपलब्ध है:

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

आइए स्थानांतरण शुरू करें

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

KVM_NODE - केवीएम होस्ट मशीन
VZ_NODE - ओपनवीजेड होस्ट मशीन
सीटीआईडी - ओपनवीजेड कंटेनर
VM - केवीएम वर्चुअल सर्वर

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

1 कदम

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

वीएम बनाने के बाद, हम सीटीआईडी ​​और वीएम पर पैकेजों को अपडेट करेंगे (ओएस को अपडेट करने में भ्रमित न हों - हम इसे अपडेट नहीं करते हैं, हम केवल पैकेज अपडेट करते हैं और, यदि यह आता है, तो मुख्य के भीतर ओएस संस्करण संस्करण)।

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

# yum clean all
# yum update -y

और उबंटू और डेबियन के लिए कोई कम हानिरहित नहीं:

# apt-get update
# apt-get upgrade

2 कदम

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

CentOS:

# yum install rsync -y

डेबियन, उबंटू:

# apt-get install rsync -y

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

3 कदम

हम रुकते हैं सीटीआईडी पर VZ_NODE टीम

vzctl stop CTID

छवि स्थापित करना सीटीआईडी:

vzctl mount CTID

/vz/root/ फ़ोल्डर पर जाएँसीटीआईडी और निष्पादित करें

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 कदम

आइए कई चरण निष्पादित करें जो हमें OpenVZ से स्थानांतरित करने के बाद VM लॉन्च करने में मदद करेंगे।
के साथ सर्वर पर systemd आइए एक कमांड निष्पादित करें जो हमें नियमित कंसोल में लॉग इन करने में मदद करेगी, उदाहरण के लिए, वीएनसी सर्वर स्क्रीन के माध्यम से

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

सर्वर पर 6 CentOS и 7 CentOS ताज़ा कर्नेल स्थापित करना सुनिश्चित करें:

yum install kernel-$(uname -r)

सर्वर को इससे लोड किया जा सकता है, लेकिन ट्रांसफर के बाद यह काम करना बंद कर सकता है या डिलीट हो सकता है।

सर्वर पर 7 CentOS आपको 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 स्थापित किया गया था, तो हम अधिकारों के साथ एक छोटा सा सुधार करेंगे, अन्यथा mod_fcgid का उपयोग करने वाली साइटें त्रुटि 500 ​​के साथ क्रैश हो जाएंगी:

chmod +s `which suexec` && apachectl restart

और आखिरी बात उबंटू और डेबियन वितरण के लिए उपयोगी है। यह OS किसी त्रुटि के साथ शाश्वत बूट में क्रैश हो सकता है

बहुत तेजी से लूपिंग. निष्पादन को थोड़ा दबाना

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

पर डेबियन 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

यदि यह मदद नहीं करता है, तो दूसरा विकल्प आज़माएँ।

समस्या का दूसरा समाधान निष्पादन को थोड़ा दबाना लगभग सभी उबंटू और डेबियन वितरण के लिए उपयुक्त।

हम निभाते हैं

bash -x /var/lib/dpkg/info/dbus.postinst configure

और के लिए Ubuntu के 14, डेबियन 7 इसके अतिरिक्त हम कार्य करते हैं:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh 

हमने क्या किया है? हमने मैसेजबस को पुनर्स्थापित किया, जो डेबियन/उबंटू को चलाने के लिए गायब था, और मॉड्यूल_डीपी को हटा दिया, जो ओपनवीजेड से आया था और कई कर्नेल मॉड्यूल की लोडिंग में हस्तक्षेप करता था।

6 कदम

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

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

स्रोत: www.habr.com