कसरी टाउको दुखाइ बिना KVM सर्भरमा OpenVZ 6 कन्टेनर सार्ने

आफ्नो जीवनमा कम्तिमा एक पटक पूर्ण KVM भर्चुअलाइजेसनको साथ सर्भरमा OpenVZ कन्टेनर स्थानान्तरण गर्न आवश्यक पर्ने जो कोहीले केही समस्याहरूको सामना गरेका छन्:

• धेरै जसो जानकारी पुरानो छ र EOL चक्र लामो समय बितिसकेका OS को लागि सान्दर्भिक थियो।
• बिभिन्न अपरेटिङ सिस्टमहरूको लागि सधैं फरक जानकारी प्रदान गरिन्छ, र माइग्रेसनको क्रममा सम्भावित त्रुटिहरूलाई कहिल्यै मानिने छैन
• कहिलेकाहीँ तपाईले कन्फिगरेसनहरूसँग व्यवहार गर्नुपर्नेछ जुन माइग्रेसन पछि काम गर्न चाहँदैनन्

जब तपाइँ 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 चलाउँदै थिए, र केहिसँग केहि धेरै विशिष्ट सफ्टवेयर पनि थिए। प्रायः, यी ISP प्रबन्धक, VestaCP नियन्त्रण प्यानल (र प्रायः, वर्षको लागि अद्यावधिक नगरिएको) संग कन्फिगरेसनहरू थिए। तिनीहरूको स्थानान्तरण अनुरोधहरूलाई पनि ध्यानमा राख्नुपर्छ।

स्थानान्तरण गरिएको कन्टेनरको आईपी ठेगाना सुरक्षित गर्दा माइग्रेसन गरिन्छ; हामी कन्टेनरमा भएको आईपी VM मा बचत गरिएको छ र समस्या बिना काम गर्नेछ भन्ने मान्छौं।

स्थानान्तरण गर्नु अघि, हामीसँग सबै कुरा हातमा छ भनेर सुनिश्चित गरौं:

• OpenVZ सर्भर, होस्ट मेसिनमा पूर्ण रूट पहुँच, कन्टेनरहरू रोक्न/माउन्ट/स्टार्ट/मेट्ने क्षमता
• KVM सर्भर, होस्ट मेसिनमा पूर्ण रूट पहुँच, यसले समावेश गर्दछ। यो मानिन्छ कि सबै कुरा पहिले नै कन्फिगर गरिएको छ र जानको लागि तयार छ।

स्थानान्तरण सुरु गरौं

हामीले स्थानान्तरण सुरु गर्नु अघि, सर्तहरू परिभाषित गरौं जसले तपाईंलाई भ्रमबाट बच्न मद्दत गर्नेछ:

KVM_NODE - KVM होस्ट मेसिन
VZ_NODE - OpenVZ होस्ट मेसिन
CTID - OpenVZ कन्टेनर
VM - KVM भर्चुअल सर्भर

माइग्रेसनको लागि तयारी गर्दै र भर्चुअल मेसिनहरू सिर्जना गर्दै।

1 कदम

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

VM सिर्जना गरेपछि, हामी प्याकेजहरू CTID र VM मा अद्यावधिक गर्नेछौं (OS अपडेट गर्न भ्रममा नपर्नुहोस् - हामी यसलाई अपडेट गर्दैनौं, हामी प्याकेजहरू मात्र अपडेट गर्छौं र, यदि यो आइपुग्यो भने, 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 मा 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 कदम

OpenVZ बाट स्थानान्तरण पछि VM सुरु गर्न मद्दत गर्ने धेरै चरणहरू गरौं।
संग सर्भर मा 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; }

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

chmod +s `which suexec` && apachectl restart

र अन्तिम कुरा Ubuntu र Debian वितरण को लागी उपयोगी छ। यो 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

यदि यसले मद्दत गर्दैन भने, दोस्रो विकल्प प्रयास गर्नुहोस्।

समस्याको दोस्रो समाधान थ्रोटलिंग कार्यान्वयन थोरै लगभग सबै Ubuntu र Debian वितरण को लागी उपयुक्त।

हामी बोक्छौं

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 

हामीले के गरेका छौं? हामीले मेसेजबसलाई पुनर्स्थापित गर्यौं, जुन डेबियन/उबुन्टु चलाउन हराइरहेको थियो, र मोड्युल_डेप हटायौं, जुन OpenVZ बाट आएको थियो र धेरै कर्नेल मोड्युलहरूको लोडिङमा हस्तक्षेप गर्‍यो।

6 कदम

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

मलाई आशा छ कि यो जानकारी उपयोगी छ! 🙂

स्रोत: www.habr.com