Cách chuyển container OpenVZ 6 sang máy chủ KVM mà không đau đầu

Bất kỳ ai cần chuyển vùng chứa OpenVZ sang máy chủ có ảo hóa KVM hoàn chỉnh ít nhất một lần trong đời đều gặp phải một số vấn đề:

• Hầu hết thông tin đều lỗi thời và có liên quan đến các hệ điều hành đã vượt qua chu kỳ EOL từ lâu
• Thông tin khác nhau luôn được cung cấp cho các hệ điều hành khác nhau và các lỗi có thể xảy ra trong quá trình di chuyển không bao giờ được xem xét
• Đôi khi bạn phải xử lý các cấu hình mà thỉnh thoảng bạn không muốn hoạt động sau khi di chuyển

Khi bạn chuyển 1 máy chủ, bạn luôn có thể sửa chữa một cái gì đó một cách nhanh chóng, nhưng khi bạn chuyển toàn bộ cụm thì sao?

Trong bài viết này, tôi sẽ cố gắng cho bạn biết cách di chuyển chính xác vùng chứa OpenVZ sang KVM với thời gian ngừng hoạt động tối thiểu và giải pháp nhanh chóng cho mọi vấn đề.

Một chương trình giáo dục nhỏ: OpenVZ và KVM là gì?

Chúng tôi sẽ không đi sâu vào thuật ngữ mà sẽ nói một cách tổng quát:

OpenVZ — ảo hóa ở cấp hệ điều hành, bạn thậm chí có thể triển khai nó trên lò vi sóng vì không cần hướng dẫn CPU và công nghệ ảo hóa trên máy chủ.

KVM - ảo hóa hoàn toàn, sử dụng toàn bộ sức mạnh của CPU và có khả năng ảo hóa mọi thứ, theo bất kỳ cách nào, cắt theo chiều dọc và chiều ngang.

Trái ngược với niềm tin phổ biến rằng trong số các nhà cung cấp dịch vụ lưu trữ, OpenVZ sẽ bị bán quá mức, nhưng KVM thì không - may mắn thay cho những nhà cung cấp dịch vụ sau, KVM hiện đang bị bán quá mức không tệ hơn người anh em của nó.

Chúng ta sẽ mang theo những gì?

Là đối tượng thử nghiệm cho quá trình chuyển giao, chúng tôi phải sử dụng toàn bộ hệ điều hành có sẵn trên OpenVZ: CentOS (phiên bản 6 và 7), Ubuntu (14, 16 và 18 LTS), Debian 7.

Người ta cho rằng hầu hết các vùng chứa OpenVZ đã chạy một loại LAMP nào đó và một số thậm chí còn có một số phần mềm rất cụ thể. Thông thường, đây là các cấu hình với bảng điều khiển ISPmanager, VestaCP (và thường xuyên nhất là không được cập nhật trong nhiều năm). Yêu cầu chuyển nhượng của họ cũng phải được tính đến.

Quá trình di chuyển được thực hiện trong khi vẫn giữ nguyên địa chỉ IP của vùng chứa được chuyển; chúng tôi sẽ giả định rằng IP mà vùng chứa đã được lưu trên VM và sẽ hoạt động mà không gặp sự cố.

Trước khi chuyển, hãy đảm bảo rằng chúng tôi có sẵn mọi thứ:

• Máy chủ OpenVZ, quyền truy cập root đầy đủ vào máy chủ, khả năng dừng/gắn/bắt đầu/xóa vùng chứa
• Máy chủ KVM, quyền truy cập root đầy đủ vào máy chủ, với tất cả những gì nó ngụ ý. Giả định rằng mọi thứ đã được cấu hình và sẵn sàng hoạt động.

Hãy bắt đầu chuyển

Trước khi chúng ta bắt đầu chuyển, hãy xác định các thuật ngữ sẽ giúp bạn tránh nhầm lẫn:

KVM_NODE - Máy chủ KVM
VZ_NODE - Máy chủ OpenVZ
CTID - Thùng chứa OpenVZ
VM - Máy chủ ảo KVM

Chuẩn bị di chuyển và tạo máy ảo.

Bước 1

Vì chúng ta cần di chuyển container đi đâu đó nên chúng ta sẽ tạo VM có cấu hình tương tự KVM_NODE.
Quan trọng! Bạn cần tạo VM trên hệ điều hành hiện đang chạy trên CTID. Ví dụ: nếu Ubuntu 14 được cài đặt trên CTID thì Ubuntu 14 phải được cài đặt trên VM. Các phiên bản nhỏ không quan trọng và sự khác biệt của chúng không quá nghiêm trọng, nhưng các phiên bản chính phải giống nhau.

Sau khi tạo VM, chúng tôi sẽ cập nhật các gói trên CTID và trên VM (đừng nhầm với việc cập nhật HĐH - chúng tôi không cập nhật nó, chúng tôi chỉ cập nhật các gói và, nếu có, phiên bản HĐH trong gói chính phiên bản).

Đối với CentOS, quá trình này có vẻ vô hại:

# yum clean all
# yum update -y

Và không kém phần vô hại đối với Ubuntu và Debian:

# apt-get update
# apt-get upgrade

Bước 2

Cài đặt trên CTID, VZ_NODE и VM tính thiết thực rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Chúng tôi không cài đặt bất cứ thứ gì khác ở đó hoặc ở đó.

Bước 3

Chúng tôi dừng lại CTID trên VZ_NODE đội

vzctl stop CTID

Gắn hình ảnh CTID:

vzctl mount CTID

Chuyển đến thư mục /vz/root/CTID và thực hiện

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Trong thư mục gốc, tạo một tệp /root/exclude.txt - nó sẽ chứa danh sách các ngoại lệ sẽ không đến được máy chủ mới

/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

Chúng tôi kết nối với KVM_NODE và khởi động VMđể nó hoạt động và có thể truy cập được qua mạng.

Bây giờ mọi thứ đã sẵn sàng để chuyển giao. Đi!

Bước 4

Vẫn còn bị phù phép, chúng tôi biểu diễn

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

Lệnh rsync sẽ thực hiện quá trình truyền, chúng tôi hy vọng rằng các khóa rõ ràng - quá trình truyền được thực hiện với việc bảo toàn các liên kết tượng trưng, ​​​​quyền truy cập, chủ sở hữu và nhóm và mã hóa bị vô hiệu hóa để có tốc độ cao hơn (bạn có thể sử dụng một số mật mã nhanh hơn, nhưng điều này không quá quan trọng đối với tác vụ này), cũng như tính năng nén bị tắt.

Sau khi hoàn thành rsync, thoát khỏi chroot (bằng cách nhấn ctrl+d) và thực thi

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Bước 5

Hãy thực hiện một số bước sẽ giúp chúng ta khởi chạy VM sau khi chuyển từ OpenVZ.
Trên các máy chủ có Systemd hãy thực thi một lệnh sẽ giúp chúng ta đăng nhập vào bảng điều khiển thông thường, chẳng hạn như thông qua màn hình máy chủ VNC

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Trên máy chủ CentOS 6 и CentOS 7 Đảm bảo cài đặt kernel mới:

yum install kernel-$(uname -r)

Máy chủ có thể được tải từ nó, nhưng sau khi chuyển, nó có thể ngừng hoạt động hoặc bị xóa.

Trên máy chủ CentOS 7 bạn cần áp dụng một sửa lỗi nhỏ cho PolkitD, nếu không máy chủ sẽ bị sập vĩnh viễn:

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; }

Trên tất cả các máy chủ, nếu mod_fcgid cho Apache đã được cài đặt, chúng tôi sẽ thực hiện một sửa chữa nhỏ về quyền, nếu không các trang web sử dụng mod_fcgid sẽ bị lỗi với lỗi 500:

chmod +s `which suexec` && apachectl restart

Và điều cuối cùng hữu ích cho các bản phân phối Ubuntu và Debian. Hệ điều hành này có thể gặp lỗi khi khởi động vĩnh viễn

vòng lặp quá nhanh. điều chỉnh thực hiện một chút

khó chịu, nhưng dễ dàng sửa chữa, tùy thuộc vào phiên bản hệ điều hành.

Trên Debian 9 bản sửa lỗi trông như thế này:

chúng tôi thực hiện

dbus-uuidgen

nếu chúng tôi gặp lỗi

/usr/local/lib/libdbus-1.so.3: không tìm thấy phiên bản `LIBDBUS_PRIVATE_1.10.8′

kiểm tra sự hiện diện của 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

nếu mọi thứ đều ổn, chúng tôi sẽ làm điều đó

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15  libdbus-1.so.3

Nếu nó không có ích, hãy thử tùy chọn thứ hai.

Giải pháp thứ hai cho vấn đề với điều chỉnh thực hiện một chút Thích hợp cho hầu hết các bản phân phối Ubuntu và Debian.

Chúng tôi thực hiện

bash -x /var/lib/dpkg/info/dbus.postinst configure

Và cho Ubuntu 14, Debian 7 Ngoài ra chúng tôi thực hiện:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh 

Chúng ta đã làm gì? Chúng tôi đã khôi phục messagebus bị thiếu để chạy Debian/Ubuntu và xóa module_dep đến từ OpenVZ và cản trở việc tải nhiều mô-đun hạt nhân.

Bước 6

Chúng tôi khởi động lại VM, kiểm tra VNC xem quá trình tải đang diễn ra như thế nào và lý tưởng nhất là mọi thứ sẽ tải mà không gặp vấn đề gì. Mặc dù có thể một số vấn đề cụ thể sẽ xuất hiện sau khi di chuyển nhưng chúng nằm ngoài phạm vi của bài viết này và sẽ được khắc phục khi chúng phát sinh.

Tôi hy vọng thông tin này hữu ích! 🙂

Nguồn: www.habr.com