🥇Cara migrasi kontainer OpenVZ 6 ke server KVM tanpa pusing

Siapa pun yang perlu mentransfer wadah OpenVZ ke server dengan virtualisasi KVM penuh setidaknya sekali dalam hidup mereka mengalami beberapa masalah:

Sebagian besar informasi sudah ketinggalan zaman dan relevan untuk OS yang telah lama melewati siklus EOL
Informasi yang berbeda selalu diberikan untuk sistem operasi yang berbeda, dan kemungkinan kesalahan selama migrasi tidak pernah dipertimbangkan
Terkadang Anda harus berurusan dengan konfigurasi yang terkadang tidak berfungsi setelah migrasi

Saat Anda mentransfer 1 server, Anda selalu dapat memperbaiki sesuatu dengan cepat, tetapi saat Anda mentransfer seluruh cluster?

Pada artikel ini saya akan mencoba memberi tahu Anda cara memigrasikan container OpenVZ ke KVM dengan benar dengan waktu henti minimal dan solusi cepat untuk semua masalah.

Sebuah program pendidikan kecil: apa itu OpenVZ dan apa itu KVM?

Kami tidak akan membahas terminologi secara mendalam, tetapi akan mengatakan secara umum:

OpenVZ — virtualisasi pada tingkat sistem operasi, Anda bahkan dapat menerapkannya di microwave, karena tidak diperlukan instruksi CPU dan teknologi virtualisasi pada mesin host.

KVM - virtualisasi penuh, menggunakan semua kekuatan CPU dan mampu memvirtualisasikan apa pun, dengan cara apa pun, memotongnya memanjang dan melintang.

Bertentangan dengan kepercayaan umum, di lingkungan penyedia hosting OpenVZ terlalu dipromosikan, tetapi KVM tidak. Untungnya bagi KVM, kini KVM juga sama-sama dipromosikan secara berlebihan seperti saudaranya.

Apa yang akan kita bawa?

Seluruh ekosistem sistem operasi yang tersedia di OpenVZ harus digunakan sebagai subjek uji untuk transfer tersebut: CentOS (versi 6 dan 7), Ubuntu (14, 16 dan 18 LTS), Debian 7.

Diasumsikan bahwa sebagian besar container OpenVZ sudah menjalankan semacam LAMP, dan beberapa bahkan memiliki perangkat lunak yang sangat spesifik. Paling sering, ini adalah konfigurasi dengan ISPmanager, panel kontrol VestaCP (dan paling sering, tidak diperbarui selama bertahun-tahun). Permintaan transfer mereka juga harus diperhitungkan.

Migrasi dilakukan dengan menjaga kelestarian data. Alamat IP Untuk kontainer portabel, kita akan berasumsi bahwa alamat IP kontainer tetap tersimpan di VM dan akan berfungsi tanpa masalah.

Sebelum mentransfer, pastikan kita memiliki segalanya:

Server OpenVZ, akses root penuh ke mesin host, kemampuan untuk menghentikan/memasang/memulai/menghapus kontainer
Server KVM, akses root penuh ke mesin host, dengan segala konsekuensinya. Diasumsikan bahwa semuanya sudah dikonfigurasi dan siap digunakan.

Mari kita mulai mentransfer

Sebelum kita memulai transfer, mari kita tentukan istilah yang akan membantu Anda menghindari kebingungan:

KVM_NODE - Mesin host KVM
VZ_NODE - Mesin host OpenVZ
CTID - Wadah OpenVZ
VM - Server virtual KVM

Mempersiapkan migrasi dan membuat mesin virtual.

Langkah 1

Karena kita perlu memindahkan wadahnya ke suatu tempat, kita akan membuatnya VM dengan konfigurasi yang mirip dengan KVM_NODE.
Penting! Anda perlu membuat VM pada sistem operasi yang sama dengan yang saat ini berjalan di CTID. Misalnya, jika CTID sedang berjalan Ubuntu 14, lalu Anda perlu menginstalnya di VM juga. Ubuntu 14. Versi minor tidak penting dan perbedaannya tidak terlalu kritis, tetapi versi mayor harus sama.

Setelah membuat VM, kami akan memperbarui paket di CTID dan VM (jangan bingung dengan memperbarui OS - kami tidak memperbaruinya, kami hanya memperbarui paket dan, jika sudah tiba, versi OS di dalam utama Versi: kapan).

Untuk CentOS Proses ini tampak tidak berbahaya:

# yum clean all
# yum update -y

Dan tidak kurang tidak berbahaya karena Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Langkah 2

Instal pada CTID, VZ_NODE и VM utilitas rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Kami tidak memasang apa pun di sana atau di sana.

Langkah 3

Kami berhenti CTID pada VZ_NODE tim

vzctl stop CTID

Memasang gambar CTID:

vzctl mount CTID

Buka folder /vz/root/CTID dan mengeksekusi

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

Di bawah root, buat file /root/exclude.txt - itu akan berisi daftar pengecualian yang tidak akan sampai ke server baru

/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

Terhubung ke KVM_NODE dan luncurkan milik kami VMsehingga berfungsi dan dapat diakses melalui jaringan.

Sekarang semuanya siap untuk ditransfer. Pergi!

Langkah 4

Masih di bawah pengaruh mantra, kami tampil

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

Perintah rsync akan melakukan transfer, kami berharap kuncinya jelas - transfer dilakukan dengan pelestarian symlink, hak akses, pemilik dan grup, dan enkripsi dinonaktifkan untuk kecepatan yang lebih tinggi (Anda dapat menggunakan beberapa sandi yang lebih cepat, tetapi ini tidak begitu penting untuk tugas ini), serta kompresi dinonaktifkan.

Setelah menyelesaikan rsync, keluar dari chroot (dengan menekan ctrl+d) dan jalankan

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

Langkah 5

Mari lakukan beberapa langkah yang akan membantu kita meluncurkan VM setelah mentransfer dari OpenVZ.
Di server dengan Systemd mari kita jalankan perintah yang akan membantu kita masuk ke konsol biasa, misalnya melalui layar server VNC

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

Di server CentOS 6 и CentOS 7 Pastikan untuk menginstal kernel baru:

yum install kernel-$(uname -r)

Server dapat dimuat darinya, tetapi setelah transfer mungkin berhenti berfungsi atau dihapus.

Di server CentOS 7 Anda perlu menerapkan perbaikan kecil untuk PolkitD, jika tidak, server akan mogok selamanya:

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

Di semua server, jika mod_fcgid untuk Apache diinstal, kami akan melakukan perbaikan kecil dengan hak, jika tidak, situs yang menggunakan mod_fcgid akan mogok dengan kesalahan 500:

chmod +s `which suexec` && apachectl restart

Dan terakhir, ini akan bermanfaat bagi Ubuntu, Debian distribusi. Sistem operasi ini dapat mengalami crash dan masuk ke mode boot permanen dengan kesalahan.

perulangan terlalu cepat. sedikit membatasi eksekusi

tidak menyenangkan, tetapi mudah diperbaiki, tergantung pada versi OS.

Pada Debian 9 perbaikannya terlihat seperti ini:

kami melaksanakan

dbus-uuidgen

jika kita mendapatkan kesalahan

/usr/local/lib/libdbus-1.so.3: versi `LIBDBUS_PRIVATE_1.10.8′ tidak ditemukan

periksa keberadaan 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

jika semuanya beres, kami melakukannya

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

Jika tidak membantu, coba opsi kedua.

Solusi kedua untuk masalah dengan sedikit membatasi eksekusi cocok untuk hampir semua orang Ubuntu и Debian distribusi.

Kami melaksanakan

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

Dan untuk Ubuntu 14, Debian 7 Selain itu kami melakukan:

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

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

Apa yang kami lakukan? Kami memulihkan messagebus, yang hilang saat startup. Debian/Ubuntu dan menghapus modules_dep, yang berasal dari OpenVZ dan mencegah banyak modul kernel dimuat.

Langkah 6

Kami me-reboot VM, memeriksa di VNC bagaimana kemajuan pemuatan dan, idealnya, semuanya akan dimuat tanpa masalah. Meskipun ada kemungkinan bahwa beberapa masalah tertentu akan muncul setelah migrasi, masalah tersebut berada di luar cakupan artikel ini dan akan diperbaiki jika masalah tersebut muncul.

Saya harap informasi ini bermanfaat! 🙂

Sumber: www.habr.com