כיצד להעביר קונטיינר OpenVZ 6 לשרת KVM ללא כאבי ראש

כל מי שאי פעם היה צריך להעביר קונטיינר OpenVZ לשרת עם וירטואליזציה מלאה של KVM נתקל במספר בעיות:

• רוב המידע פשוט מיושן והיה רלוונטי עבור מערכות הפעלה שכבר סיימו את מחזור ה-EOL מזמן.
• מערכות הפעלה שונות תמיד מספקות מידע שונה, ושגיאות אפשריות במהלך ההעברה לעולם אינן נלקחות בחשבון.
• לפעמים צריך להתמודד עם תצורות שלא עובדות לאחר ההגירה.

כשאתה מעביר שרת אחד, תמיד תוכל לתקן משהו תוך כדי תנועה, אבל מה לגבי מעביר אשכול שלם?

במאמר זה, אסביר כיצד להעביר בצורה נכונה מכולה של OpenVZ ל-KVM עם זמן השבתה מינימלי ופתרון מהיר לכל הבעיות.

מבוא מהיר: מה זה OpenVZ ומהו KVM?

בואו לא ניכנס לפרטים על הטרמינולוגיה, אלא ניתן סקירה כללית:

OpenVZ — וירטואליזציה ברמת מערכת ההפעלה, ניתנת לפרוס אפילו על תנור מיקרוגל, מכיוון שאין צורך בהוראות CPU וטכנולוגיות וירטואליזציה במחשב המארח.

KVM — וירטואליזציה מלאה, המשתמשת במלוא עוצמת המעבד ומסוגלת לבצע וירטואליזציה של כל דבר, בכל דרך שתרצו, לחתוך אותו לאורכו ולרוחבו.

בניגוד לאמונה הרווחת, בסביבה ספקי אירוח OpenVZ נמכר ביתר, אבל KVM לא. למרבה המזל עבור האחרון, KVM נמכר כעת ביתר בדיוק כמו אחיו.

מה אנחנו הולכים להעביר?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

ההנחה הייתה שרוב קונטיינרים של OpenVZ כבר מריצים סוג כלשהו של LAMP, ולחלקם אף הייתה תוכנה ספציפית מאוד. לרוב, אלה היו תצורות עם ISPmanager או לוח הבקרה של VestaCP (ולעתים קרובות, הן לא עודכנו במשך שנים). היה צורך לקחת בחשבון גם את דרישות ההגירה שלהן.

הגירה מתבצעת תוך שימור כתובות IP עבור מכולה ניידת, נניח שכתובת ה-IP של המכולה נשמרת על המכונה הווירטואלית ותפעל ללא בעיות.

לפני ההעברה, בואו נוודא שיש לנו הכל בהישג יד:

• שרת OpenVZ, גישת root מלאה למחשב המארח, יכולת לעצור/להרכיב/להפעיל/להסיר קונטיינרים
• שרת KVM עם גישת root מלאה למחשב המארח, על כל המשתמע מכך. הנחה זו היא שהכל כבר מוגדר ומוכן לפעולה.

בואו נתחיל את ההעברה

לפני שנתחיל בהעברה, נגדיר כמה מונחים כדי למנוע בלבול:

KVM_NODE — מכונת מארח KVM
VZ_NODE - מכונת מארח OpenVZ
CTID — מיכל OpenVZ
VM — שרת וירטואלי KVM

הכנה למעבר ויצירת מכונות וירטואליות.

שלב 1

מכיוון שאנחנו צריכים להעביר את המכולה למקום כלשהו, ​​ניצור VM עם תצורה דומה על KVM_NODE.
חשוב! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

לאחר יצירת המכונה הווירטואלית, אנו מעדכנים את החבילות ב-CTID ובמכונה הווירטואלית (אין להתבלבל עם עדכון מערכת ההפעלה - איננו מעדכנים את מערכת ההפעלה, אנו מעדכנים רק את החבילות, ובמידת הצורך, את גרסת מערכת ההפעלה בתוך הגרסה הראשית).

עבור 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

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 .

תחת 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.
בשרתים עם 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 הותקן עבור 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 

Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.

שלב 6

אתחל את המכונה הווירטואלית, בדוק את תהליך האתחול ב-VNC, ובאופן אידיאלי, הכל יאתחל ללא תקלות. למרות שבעיות ספציפיות עשויות להתעורר לאחר ההעברה, הן חורגות מתחום מאמר זה ויטופלו ככל שיעלו.

אני מקווה שהמידע הזה שימושי! 🙂

מקור: www.habr.com