هر کسی که حداقل یک بار در زندگی خود نیاز به انتقال یک کانتینر OpenVZ به سروری با مجازی سازی کامل KVM داشته باشد، با مشکلاتی روبرو شده است:
- بیشتر اطلاعات صرفاً قدیمی هستند و برای سیستم‌عامل‌هایی که مدت‌ها چرخه EOL را پشت سر گذاشته بودند، مرتبط بودند
- همیشه اطلاعات متفاوتی برای سیستم عامل های مختلف ارائه می شود و خطاهای احتمالی در حین مهاجرت هرگز در نظر گرفته نمی شود
- گاهی اوقات باید با تنظیماتی دست و پنجه نرم کنید که هر از چند گاهی پس از مهاجرت نمی خواهند کار کنند
هنگامی که 1 سرور را انتقال می دهید، همیشه می توانید چیزی را در لحظه تعمیر کنید، اما وقتی یک خوشه کامل را انتقال می دهید؟
در این مقاله سعی خواهم کرد به شما بگویم که چگونه به درستی یک کانتینر OpenVZ را به KVM با حداقل زمان خرابی و یک راه حل سریع برای همه مشکلات انتقال دهید.
یک برنامه آموزشی کوچک: OpenVZ چیست و KVM چیست؟
ما عمیقاً وارد اصطلاحات نمی شویم، اما به طور کلی خواهیم گفت:
OpenVZ - مجازی سازی در سطح سیستم عامل، حتی می توانید آن را روی مایکروویو مستقر کنید، زیرا نیازی به دستورالعمل های CPU و فناوری های مجازی سازی در دستگاه میزبان نیست.
KVM - مجازی سازی تمام عیار، با استفاده از تمام توان CPU و قابلیت مجازی سازی هر چیزی، به هر شکل، برش طولی و متقاطع.
برخلاف تصور رایج که در میان ارائه دهندگان میزبانی OpenVZ بیش از حد فروش می شود، اما KVM نمی شود - خوشبختانه برای دومی، KVM اکنون بیش از برادرش بیش از حد فروخته می شود.
چه چیزی را حمل خواهیم کرد؟
به عنوان سوژه های آزمایشی برای انتقال، ما مجبور شدیم از کل جنگل سیستم عامل های موجود در OpenVZ استفاده کنیم: CentOS (نسخه های 6 و 7)، اوبونتو (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 اجرا می شود، یک VM ایجاد کنید. به عنوان مثال اگر اوبونتو 14 روی CTID نصب شده باشد، اوبونتو 14 باید روی ماشین مجازی نصب شود.
پس از ایجاد VM، بسته ها را در CTID و VM به روز می کنیم (با به روز رسانی سیستم عامل اشتباه نگیریم - ما آن را به روز نمی کنیم، فقط بسته ها را به روز می کنیم و اگر رسید، نسخه سیستم عامل را در سیستم اصلی به روز می کنیم. نسخه).
برای CentOS این فرآیند بی ضرر به نظر می رسد:
# yum clean all
# yum update -yو برای اوبونتو و دبیان کم ضرر نیست:
# apt-get update
# apt-get upgradeمرحله 2
نصب کنید CTID, VZ_NODE и VM ابزار rsync:
لینوکس:
# 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 راه اندازی کنیم.
در سرورهای با 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; }در تمام سرورها، اگر mod_fcgid برای آپاچی نصب شده بود، یک اصلاح کوچک با حقوق انجام می دهیم، در غیر این صورت سایت هایی که از mod_fcgid استفاده می کنند با خطای 500 خراب می شوند:
chmod +s `which suexec` && apachectl restartو آخرین مورد برای توزیع های اوبونتو و دبیان مفید است. این سیستم عامل ممکن است با یک خطا به یک بوت ابدی سقوط کند
حلقه زدن خیلی سریع اجرای کمی خفه کننده
بسته به نسخه سیستم عامل ناخوشایند است، اما به راحتی برطرف می شود.
بر دبیان 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و برای اوبونتو 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 آمده بود و در بارگذاری بسیاری از ماژول‌های هسته تداخل داشت، حذف کردیم.
مرحله 6
ما ماشین مجازی را راه اندازی مجدد می کنیم، در VNC بررسی می کنیم که بارگذاری چگونه پیش می رود و در حالت ایده آل، همه چیز بدون مشکل بارگذاری می شود. اگرچه ممکن است مشکلات خاصی پس از مهاجرت به وجود بیاید، اما از حوصله این مقاله خارج است و در صورت بروز اصلاح خواهد شد.
امیدوارم این اطلاعات مفید باشد! 🙂
منبع: www.habr.com