ใครก็ตามที่จำเป็นต้องถ่ายโอนคอนเทนเนอร์ 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 ที่คอนเทนเนอร์มีบันทึกไว้ใน VM และจะทำงานได้โดยไม่มีปัญหา
ก่อนโอน โปรดตรวจสอบให้แน่ใจว่าเรามีทุกอย่างพร้อม:
- เซิร์ฟเวอร์ OpenVZ, การเข้าถึงรูทแบบเต็มไปยังเครื่องโฮสต์, ความสามารถในการหยุด/เมานต์/เริ่ม/ลบคอนเทนเนอร์
- เซิร์ฟเวอร์ KVM การเข้าถึงรูทแบบเต็มไปยังเครื่องโฮสต์ พร้อมคุณสมบัติทั้งหมดที่เกี่ยวข้อง ถือว่าทุกอย่างได้รับการกำหนดค่าแล้วและพร้อมใช้งาน
เริ่มโอนกันเลย
ก่อนที่เราจะเริ่มการโอน เรามากำหนดคำศัพท์ที่จะช่วยให้คุณหลีกเลี่ยงความสับสนกันดีกว่า:
KVM_NODE - เครื่องโฮสต์ KVM
VZ_NODE - เครื่องโฮสต์ OpenVZ
ซีทีไอดี - คอนเทนเนอร์ OpenVZ
VM - เซิร์ฟเวอร์เสมือน KVM
การเตรียมการสำหรับการย้ายและการสร้างเครื่องเสมือน
ขั้นตอนที่ 1
เนื่องจากเราจำเป็นต้องย้ายคอนเทนเนอร์ไปที่ไหนสักแห่ง เราจึงจะสร้าง VM ด้วยการกำหนดค่าที่คล้ายกันกับ KVM_NODE.
ที่สำคัญ! คุณต้องสร้าง VM บนระบบปฏิบัติการที่ทำงานบน 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
ติดตั้งบน ซีทีไอดี, VZ_NODE и VM ประโยชน์ rsync:
CentOS:
# yum install rsync -y
Debian, Ubuntu:
# apt-get install rsync -y
เราไม่ได้ติดตั้งสิ่งอื่นใดอีกทั้งที่นั่นหรือที่นั่น
ขั้นตอนที่ 3
เราทำการหยุด ซีทีไอดี บน VZ_NODE ทีม
vzctl stop CTID
การติดตั้งภาพ ซีทีไอดี:
vzctl mount CTID
ไปที่โฟลเดอร์ /vz/root/ซีทีไอดี และดำเนินการ
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]
บนเซิร์ฟเวอร์ 6 CentOS и 7 CentOS อย่าลืมติดตั้งเคอร์เนลใหม่:
yum install kernel-$(uname -r)
สามารถโหลดเซิร์ฟเวอร์ได้ แต่หลังจากการถ่ายโอนเซิร์ฟเวอร์อาจหยุดทำงานหรือถูกลบ
บนเซิร์ฟเวอร์ 7 CentOS คุณต้องใช้การแก้ไขเล็กน้อยสำหรับ 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
และสำหรับ อูบุนตู 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
เรารีบูต VM ตรวจสอบ VNC ว่าการโหลดคืบหน้าไปอย่างไรและโดยหลักการแล้วทุกอย่างจะโหลดได้โดยไม่มีปัญหา แม้ว่าอาจเป็นไปได้ว่าปัญหาเฉพาะบางอย่างจะปรากฏขึ้นหลังจากการโยกย้าย แต่ปัญหาเหล่านั้นอยู่นอกเหนือขอบเขตของบทความนี้และจะได้รับการแก้ไขทันทีที่เกิดขึ้น
ฉันหวังว่าข้อมูลนี้จะเป็นประโยชน์! 🙂
ที่มา: will.com