🥇كيفية نقل حاوية OpenVZ 6 إلى خادم KVM دون صداع

أي شخص يحتاج إلى نقل حاوية OpenVZ إلى خادم مزود بمحاكاة KVM الافتراضية الكاملة مرة واحدة على الأقل في حياته واجه بعض المشكلات:

معظم المعلومات قديمة ببساطة وكانت ذات صلة بأنظمة التشغيل التي اجتازت دورة موسوعة الحياة لفترة طويلة
يتم دائمًا توفير معلومات مختلفة لأنظمة التشغيل المختلفة، ولا يتم أخذ الأخطاء المحتملة أثناء الترحيل في الاعتبار أبدًا
في بعض الأحيان يتعين عليك التعامل مع التكوينات التي لا ترغب في العمل بين الحين والآخر بعد الترحيل

عند نقل خادم واحد، يمكنك دائمًا إصلاح شيء ما بسرعة، ولكن عند نقل مجموعة بأكملها؟

سأحاول في هذه المقالة إخبارك بكيفية ترحيل حاوية OpenVZ بشكل صحيح إلى KVM بأقل وقت توقف وحل سريع لجميع المشكلات.

برنامج تعليمي صغير: ما هو OpenVZ وما هو KVM؟

ولن نتعمق في المصطلحات، بل سنقول بعبارات عامة:

أوبن في زي — المحاكاة الافتراضية على مستوى نظام التشغيل، يمكنك أيضًا نشرها على الميكروويف، نظرًا لعدم الحاجة إلى تعليمات وحدة المعالجة المركزية وتقنيات المحاكاة الافتراضية على الجهاز المضيف.

KVM - محاكاة افتراضية كاملة، باستخدام كل قوة وحدة المعالجة المركزية وقادرة على محاكاة أي شيء بأي شكل من الأشكال، وتقطيعه بالطول والعرض.

خلافاً للاعتقاد السائد، في البيئة مزودي خدمات الاستضافة يُبالغ في تقدير قيمة OpenVZ، بينما لا يُبالغ في تقدير قيمة KVM. ولحسن حظ KVM، فقد أصبح يُبالغ في تقدير قيمته تمامًا مثل OpenVZ.

ماذا سنحمل؟

كان لا بد من استخدام جميع أنظمة التشغيل المتاحة على OpenVZ كعناصر اختبار لعملية النقل: CentOS (الإصداران 6 و7)، Ubuntu (14 و16 و18 لترًا)، 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. على سبيل المثال، إذا كان CTID يعمل Ubuntu 14، ثم ستحتاج إلى تثبيته على جهاز افتراضي أيضًا Ubuntu 14. النسخ الثانوية ليست مهمة واختلافها ليس بالغ الأهمية، ولكن يجب أن تكون النسخ الرئيسية متطابقة.

بعد إنشاء 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

Debian, Ubuntu:

# 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/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 التوزيعات. قد يتعطل نظام التشغيل هذا ويؤدي إلى إعادة تشغيل دائمة مع ظهور خطأ

حلقات سريعة جدًا. خنق التنفيذ قليلا

غير سارة، ولكن يمكن إصلاحها بسهولة، اعتمادًا على إصدار نظام التشغيل.

في 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

نقوم بإعادة تشغيل الجهاز الظاهري، والتحقق في VNC من كيفية تقدم عملية التحميل، ومن الناحية المثالية، سيتم تحميل كل شيء دون مشاكل. على الرغم من أنه من الممكن أن تظهر بعض المشكلات المحددة بعد الترحيل، إلا أنها تقع خارج نطاق هذه المقالة وسيتم تصحيحها عند ظهورها.

آمل أن تكون هذه المعلومات مفيدة! 🙂

المصدر: www.habr.com