วิธีถ่ายโอนคอนเทนเนอร์ OpenVZ 6 ไปยังเซิร์ฟเวอร์ KVM โดยไม่ต้องปวดหัว

ใครก็ตามที่จำเป็นต้องถ่ายโอนคอนเทนเนอร์ 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

เพิ่มความคิดเห็น