🥇Cách di chuyển container OpenVZ 6 sang máy chủ KVM mà không gặp rắc rối

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 quan niệm phổ biến, trong môi trường nhà cung cấp dịch vụ lưu trữ OpenVZ đang bị thổi phồng quá mức, nhưng KVM thì không. May mắn thay cho KVM, hiện tại nó cũng đang bị thổi phồng quá mức giống như người anh em của nó.

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

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 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.

Di cư được thực hiện với mục đích bảo tồn. Các địa chỉ IP Đối với container di động, chúng ta sẽ giả định rằng địa chỉ IP của container được giữ nguyên trên máy ảo 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! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

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).

vì CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, 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/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

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

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

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 подходит практически для всех Ubuntu и 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

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

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