هر کسی که حداقل یک بار در زندگی خود نیاز به انتقال یک کانتینر OpenVZ به سروری با مجازی سازی کامل KVM داشته باشد، با مشکلاتی روبرو شده است:
- بیشتر اطلاعات صرفاً قدیمی هستند و برای سیستمعاملهایی که مدتها چرخه EOL را پشت سر گذاشته بودند، مرتبط بودند
- همیشه اطلاعات متفاوتی برای سیستم عامل های مختلف ارائه می شود و خطاهای احتمالی در حین مهاجرت هرگز در نظر گرفته نمی شود
- گاهی اوقات باید با تنظیماتی دست و پنجه نرم کنید که هر از چند گاهی پس از مهاجرت نمی خواهند کار کنند
هنگامی که 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 را اجرا می کردند و برخی حتی دارای نرم افزار بسیار خاصی بودند. اغلب، این تنظیمات با ISPmanager، کنترل پنل VestaCP بودند (و اغلب، برای سالها به روز نشده بودند). درخواست انتقال آنها نیز باید در نظر گرفته شود.
مهاجرت با حفظ و نگهداری انجام میشود آدرس های IP برای یک کانتینر قابل حمل، فرض میکنیم که آدرس IP کانتینر در ماشین مجازی حفظ شده و بدون مشکل کار خواهد کرد.
قبل از انتقال، مطمئن شویم که همه چیز را در اختیار داریم:
- سرور OpenVZ، دسترسی روت کامل به دستگاه میزبان، قابلیت توقف/مونت/شروع/حذف کانتینرها
- سرور KVM، دسترسی روت کامل به ماشین میزبان، با تمام آنچه در آن دلالت دارد. فرض بر این است که همه چیز از قبل پیکربندی شده و آماده کار است.
انتقال را شروع کنیم
قبل از شروع انتقال، اجازه دهید اصطلاحاتی را تعریف کنیم که به شما در جلوگیری از سردرگمی کمک می کند:
KVM_NODE - دستگاه میزبان KVM
VZ_NODE - دستگاه میزبان OpenVZ
CTID - ظرف OpenVZ
VM - سرور مجازی KVM
آماده سازی برای مهاجرت و ایجاد ماشین های مجازی.
مرحله 1
از آنجایی که باید ظرف را به جایی منتقل کنیم، ایجاد می کنیم VM با پیکربندی مشابه به KVM_NODE.
مهم! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить 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 ابزار rsync:
CentOS:
# yum install rsync -yDebian, 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 راه اندازی کنیم.
در سرورهای با Systemd بیایید دستوری را اجرا کنیم که به ما کمک می کند تا به یک کنسول معمولی وارد شویم، به عنوان مثال، از طریق یک صفحه سرور 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 برای آپاچی نصب شده بود، یک اصلاح کوچک با حقوق انجام می دهیم، در غیر این صورت سایت هایی که از 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 Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.
مرحله 6
ما ماشین مجازی را راه اندازی مجدد می کنیم، در VNC بررسی می کنیم که بارگذاری چگونه پیش می رود و در حالت ایده آل، همه چیز بدون مشکل بارگذاری می شود. اگرچه ممکن است مشکلات خاصی پس از مهاجرت به وجود بیاید، اما از حوصله این مقاله خارج است و در صورت بروز اصلاح خواهد شد.
امیدوارم این اطلاعات مفید باشد! 🙂
منبع: www.habr.com
