ProHoster > blog > administrasi > Cara mentransfer container OpenVZ 6 ke server KVM tanpa pusing

Cara mentransfer container 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 anggapan umum bahwa di antara penyedia hosting OpenVZ akan mengalami oversold, namun KVM tidak akan melakukannya - untungnya bagi penyedia hosting tersebut, KVM kini mengalami oversold tidak lebih buruk dari saudaranya.

Apa yang akan kita bawa?

Sebagai subjek uji untuk transfer, kami harus menggunakan seluruh sistem operasi yang tersedia di OpenVZ: 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 tetap mempertahankan alamat IP kontainer yang ditransfer; kami berasumsi bahwa IP yang dimiliki kontainer disimpan 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 sedang berjalan di CTID. Misalnya, jika Ubuntu 14 diinstal pada CTID, maka Ubuntu 14 harus diinstal pada VM.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 terlihat tidak berbahaya:

# yum clean all
# yum update -y

Dan yang tidak kalah berbahayanya untuk Ubuntu dan 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Di server 6 CentOS ΠΈ 7 CentOS Pastikan untuk menginstal kernel baru:

yum install kernel-$(uname -r)

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

Di server 7 CentOS 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 yang terakhir berguna untuk distribusi Ubuntu dan Debian. OS ini mungkin mengalami crash pada boot abadi karena 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 distribusi Ubuntu dan Debian.

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 telah kita lakukan? Kami memulihkan messagebus, yang hilang untuk menjalankan Debian/Ubuntu, dan menghapus module_dep, yang berasal dari OpenVZ dan mengganggu pemuatan banyak modul kernel.

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

Tambah komentar