أي شخص يحتاج إلى نقل حاوية OpenVZ إلى خادم مزود بمحاكاة KVM الافتراضية الكاملة مرة واحدة على الأقل في حياته واجه بعض المشكلات:
- معظم المعلومات قديمة ببساطة وكانت ذات صلة بأنظمة التشغيل التي اجتازت دورة موسوعة الحياة لفترة طويلة
- يتم دائمًا توفير معلومات مختلفة لأنظمة التشغيل المختلفة، ولا يتم أخذ الأخطاء المحتملة أثناء الترحيل في الاعتبار أبدًا
- في بعض الأحيان يتعين عليك التعامل مع التكوينات التي لا ترغب في العمل بين الحين والآخر بعد الترحيل
عند نقل خادم واحد، يمكنك دائمًا إصلاح شيء ما بسرعة، ولكن عند نقل مجموعة بأكملها؟
سأحاول في هذه المقالة إخبارك بكيفية ترحيل حاوية OpenVZ بشكل صحيح إلى KVM بأقل وقت توقف وحل سريع لجميع المشكلات.
برنامج تعليمي صغير: ما هو OpenVZ وما هو KVM؟
ولن نتعمق في المصطلحات، بل سنقول بعبارات عامة:
أوبن في زي — المحاكاة الافتراضية على مستوى نظام التشغيل، يمكنك أيضًا نشرها على الميكروويف، نظرًا لعدم الحاجة إلى تعليمات وحدة المعالجة المركزية وتقنيات المحاكاة الافتراضية على الجهاز المضيف.
KVM - محاكاة افتراضية كاملة، باستخدام كل قوة وحدة المعالجة المركزية وقادرة على محاكاة أي شيء بأي شكل من الأشكال، وتقطيعه بالطول والعرض.
على عكس الاعتقاد السائد، من بين موفري الاستضافة، سوف يصبح OpenVZ في ذروة البيع، لكن KVM لن يحدث ذلك - لحسن الحظ بالنسبة للأخيرة، فإن KVM الآن ليس أسوأ من أخيه.
ماذا سنحمل؟
كمواضيع اختبار للنقل، كان علينا استخدام مجموعة كاملة من أنظمة التشغيل المتوفرة على OpenVZ: CentOS (الإصداران 6 و7)، Ubuntu (14، 16 و18 LTS)، Debian 7.
كان من المفترض أن معظم حاويات OpenVZ كانت تستخدم بالفعل نوعًا ما من LAMP، وكان لدى بعضها بعض البرامج المحددة جدًا. في أغلب الأحيان، كانت هذه تكوينات باستخدام ISPmanager ولوحة التحكم VestaCP (وفي أغلب الأحيان، لم يتم تحديثها لسنوات). ويجب أيضًا أن تؤخذ طلبات النقل الخاصة بهم بعين الاعتبار.
يتم الترحيل مع الحفاظ على عنوان IP الخاص بالحاوية المنقولة، وسنفترض أن عنوان IP الخاص بالحاوية محفوظ على الجهاز الافتراضي وسيعمل دون مشاكل.
قبل النقل، دعونا نتأكد من أن لدينا كل شيء في متناول اليد:
- خادم OpenVZ، ووصول كامل للجذر إلى الجهاز المضيف، والقدرة على إيقاف/تركيب/بدء/حذف الحاويات
- خادم KVM، وصول كامل للجذر إلى الجهاز المضيف، مع كل ما يتضمنه ذلك. من المفترض أن كل شيء تم تكوينه بالفعل وجاهز للاستخدام.
لنبدأ بالنقل
قبل أن نبدأ عملية النقل، دعنا نحدد المصطلحات التي ستساعدك على تجنب الالتباس:
KVM_NODE - الجهاز المضيف KVM
VZ_NODE - الجهاز المضيف OpenVZ
CTID - حاوية OpenVZ
VM - خادم افتراضي KVM
التحضير للهجرة وإنشاء الأجهزة الافتراضية.
الخطوة 1
وبما أننا بحاجة إلى نقل الحاوية إلى مكان ما، فسوف نقوم بإنشائها VM مع تكوين مماثل ل KVM_NODE.
المهم! تحتاج إلى إنشاء جهاز افتراضي على نظام التشغيل الذي يعمل حاليًا على CTID. على سبيل المثال، إذا تم تثبيت Ubuntu 14 على CTID، فيجب تثبيت Ubuntu 14 على VM. الإصدارات الثانوية ليست مهمة والتناقض بينها ليس بالغ الأهمية، ولكن الإصدارات الرئيسية يجب أن تكون هي نفسها.
بعد إنشاء VM، سنقوم بتحديث الحزم على CTID وعلى VM (يجب عدم الخلط بينه وبين تحديث نظام التشغيل - فنحن لا نقوم بتحديثه، بل نقوم فقط بتحديث الحزم، وفي حالة وصولها، إصدار نظام التشغيل ضمن النظام الرئيسي إصدار).
بالنسبة إلى CentOS، تبدو هذه العملية غير ضارة:
# yum clean all
# yum update -yولا يقل ضررًا على Ubuntu وDebian:
# apt-get update
# apt-get upgradeالخطوة 2
تثبيت على CTID, VZ_NODE и VM جدوى رسينك:
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
لنقم بتنفيذ العديد من الخطوات التي ستساعدنا في تشغيل VM بعد النقل من OpenVZ.
على خوادم مع سيستم دي لننفذ أمرًا سيساعدنا على تسجيل الدخول إلى وحدة تحكم عادية، على سبيل المثال، من خلال شاشة خادم 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. قد يتعطل نظام التشغيل هذا في التمهيد الأبدي بسبب وجود خطأ
حلقات سريعة جدًا. خنق التنفيذ قليلا
غير سارة، ولكن يمكن إصلاحها بسهولة، اعتمادًا على إصدار نظام التشغيل.
في ديبيان 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ومن أجل أوبونتو 14, ديبيان 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 وتداخل مع تحميل العديد من وحدات kernel.
الخطوة 6
نقوم بإعادة تشغيل الجهاز الظاهري، والتحقق في VNC من كيفية تقدم عملية التحميل، ومن الناحية المثالية، سيتم تحميل كل شيء دون مشاكل. على الرغم من أنه من الممكن أن تظهر بعض المشكلات المحددة بعد الترحيل، إلا أنها تقع خارج نطاق هذه المقالة وسيتم تصحيحها عند ظهورها.
آمل أن تكون هذه المعلومات مفيدة! 🙂
المصدر: www.habr.com