ProHoster > Blog > Pentadbiran > Bagaimana untuk memindahkan bekas OpenVZ 6 ke pelayan KVM tanpa sakit kepala

Bagaimana untuk memindahkan bekas OpenVZ 6 ke pelayan KVM tanpa sakit kepala

Sesiapa sahaja yang perlu memindahkan bekas OpenVZ ke pelayan dengan maya KVM penuh sekurang-kurangnya sekali dalam hidup mereka telah menghadapi beberapa masalah:

  • Kebanyakan maklumat itu sudah lapuk dan relevan untuk OS yang telah lama melepasi kitaran EOL
  • Maklumat yang berbeza sentiasa disediakan untuk sistem pengendalian yang berbeza, dan kemungkinan ralat semasa penghijrahan tidak pernah dipertimbangkan
  • Kadang-kadang anda perlu berurusan dengan konfigurasi yang sekali-sekala tidak mahu berfungsi selepas penghijrahan

Apabila anda memindahkan 1 pelayan, anda sentiasa boleh membetulkan sesuatu dengan cepat, tetapi apabila anda memindahkan keseluruhan kluster?

Dalam artikel ini saya akan cuba memberitahu anda cara memindahkan bekas OpenVZ ke KVM dengan betul dengan masa henti yang minimum dan penyelesaian pantas kepada semua masalah.

Program pendidikan kecil: apakah OpenVZ dan apakah KVM?

Kami tidak akan mendalami istilah, tetapi akan mengatakan secara umum:

OpenVZ β€” virtualisasi pada peringkat sistem pengendalian, anda juga boleh menggunakan ia pada gelombang mikro, kerana tidak ada keperluan untuk arahan CPU dan teknologi virtualisasi pada mesin hos.

KVM - virtualisasi sepenuhnya, menggunakan semua kuasa CPU dan mampu memayakan apa sahaja, dalam apa cara sekalipun, memotongnya secara memanjang dan bersilang.

Bertentangan dengan kepercayaan popular bahawa dalam kalangan penyedia pengehosan OpenVZ akan menjadi terlebih jual, tetapi KVM tidak akan - nasib baik untuk yang terakhir, KVM kini terlebih jual tidak lebih buruk daripada saudaranya.

Apa yang akan kami bawa?

Sebagai subjek ujian untuk pemindahan, kami terpaksa menggunakan seluruh hutan sistem pengendalian yang tersedia pada OpenVZ: CentOS (versi 6 dan 7), Ubuntu (14, 16 dan 18 LTS), Debian 7.

Diandaikan bahawa kebanyakan bekas OpenVZ telah menjalankan beberapa jenis LAMP, dan ada juga yang mempunyai beberapa perisian yang sangat khusus. Selalunya, ini adalah konfigurasi dengan ISPmanager, panel kawalan VestaCP (dan selalunya, tidak dikemas kini selama bertahun-tahun). Permintaan pemindahan mereka juga mesti diambil kira.

Penghijrahan dilakukan sambil mengekalkan alamat IP bekas yang dipindahkan; kami akan menganggap bahawa IP yang dimiliki oleh bekas itu disimpan pada VM dan akan berfungsi tanpa masalah.

Sebelum memindahkan, mari pastikan bahawa kami mempunyai segala-galanya di tangan:

  • Pelayan OpenVZ, akses root penuh ke mesin hos, keupayaan untuk menghentikan/melekap/memulakan/memadam bekas
  • Pelayan KVM, akses root penuh ke mesin hos, dengan semua yang tersirat. Diandaikan bahawa semuanya telah dikonfigurasikan dan sedia untuk digunakan.

Mari mulakan pemindahan

Sebelum kami memulakan pemindahan, mari tentukan istilah yang akan membantu anda mengelakkan kekeliruan:

KVM_NODE - Mesin hos KVM
VZ_NODE - Mesin hos OpenVZ
CTID - Bekas OpenVZ
VM - pelayan maya KVM

Bersedia untuk penghijrahan dan mencipta mesin maya.

Langkah 1

Memandangkan kita perlu mengalihkan bekas itu ke suatu tempat, kita akan buat VM dengan konfigurasi yang serupa dengan KVM_NODE.
Penting! Anda perlu mencipta VM pada sistem pengendalian yang sedang berjalan pada CTID. Contohnya, jika Ubuntu 14 dipasang pada CTID, maka Ubuntu 14 mesti dipasang pada VM. Versi minor tidak penting dan percanggahannya tidak begitu kritikal, tetapi versi utama harus sama.

Selepas mencipta VM, kami akan mengemas kini pakej pada CTID dan pada VM (jangan dikelirukan dengan mengemas kini OS - kami tidak mengemas kininya, kami hanya mengemas kini pakej dan, jika ia tiba, versi OS dalam bahagian utama versi).

Untuk CentOS proses ini kelihatan tidak berbahaya:

# yum clean all
# yum update -y

Dan tidak kurang berbahaya untuk Ubuntu dan Debian:

# apt-get update
# apt-get upgrade

Langkah 2

Pasang pada CTID, VZ_NODE ΠΈ VM utiliti rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Kami tidak memasang apa-apa lagi sama ada di sana atau di sana.

Langkah 3

Kami berhenti CTID pada VZ_NODE pasukan

vzctl stop CTID

Memasang imej CTID:

vzctl mount CTID

Pergi ke folder /vz/root/CTID dan laksanakan

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

Di bawah akar, buat fail /root/exclude.txt - ia akan mengandungi senarai pengecualian yang tidak akan sampai ke pelayan baharu

/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

Sambung ke KVM_NODE dan melancarkan kami VMsupaya ia berfungsi dan boleh diakses melalui rangkaian.

Sekarang semuanya sedia untuk dipindahkan. Pergi!

Langkah 4

Masih di bawah mantra, kami membuat persembahan

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

Perintah rsync akan melakukan pemindahan, kami berharap kekuncinya jelas - pemindahan dijalankan dengan pemeliharaan pautan sym, hak akses, pemilik dan kumpulan, dan penyulitan dilumpuhkan untuk kelajuan yang lebih tinggi (anda boleh menggunakan sifir yang lebih cepat, tetapi ini tidak begitu penting untuk tugas ini), serta pemampatan dilumpuhkan.

Selepas menyelesaikan rsync, keluar dari chroot (dengan menekan ctrl+d) dan laksanakan

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

Langkah 5

Mari lakukan beberapa langkah yang akan membantu kami melancarkan VM selepas memindahkan daripada OpenVZ.
Pada pelayan dengan Systemd mari kita laksanakan arahan yang akan membantu kita log masuk ke konsol biasa, contohnya, melalui skrin pelayan VNC

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

Pada pelayan CentOS 6 ΠΈ CentOS 7 Pastikan anda memasang kernel baru:

yum install kernel-$(uname -r)

Pelayan boleh dimuatkan daripadanya, tetapi selepas pemindahan ia mungkin berhenti berfungsi atau dipadamkan.

Pada pelayan CentOS 7 anda perlu menggunakan pembetulan kecil untuk PolkitD, jika tidak pelayan akan ranap selama-lamanya:

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

Pada semua pelayan, jika mod_fcgid untuk Apache telah dipasang, kami akan melakukan pembetulan kecil dengan hak, jika tidak, tapak yang menggunakan mod_fcgid akan ranap dengan ralat 500:

chmod +s `which suexec` && apachectl restart

Dan perkara terakhir berguna untuk pengedaran Ubuntu dan Debian. OS ini mungkin terhempas ke dalam but kekal dengan ralat

gelung terlalu cepat. perlaksanaan pendikit sedikit

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

Pada Debian 9 pembetulan kelihatan seperti ini:

kita laksanakan

dbus-uuidgen

jika kita mendapat ralat

/usr/local/lib/libdbus-1.so.3: versi `LIBDBUS_PRIVATE_1.10.8β€² tidak ditemui

semak kehadiran 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 teratur, kita lakukannya

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 ia tidak membantu, cuba pilihan kedua.

Penyelesaian kedua untuk masalah dengan perlaksanaan pendikit sedikit Sesuai untuk hampir semua pengedaran Ubuntu dan Debian.

Kami laksanakan

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

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

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 tiada untuk menjalankan Debian/Ubuntu, dan mengalih keluar modules_dep, yang datang daripada OpenVZ dan mengganggu pemuatan banyak modul kernel.

Langkah 6

Kami but semula VM, semak dalam VNC bagaimana pemuatan sedang berjalan dan, idealnya, semuanya akan dimuatkan tanpa masalah. Walaupun ada kemungkinan bahawa beberapa masalah khusus akan muncul selepas penghijrahan, ia berada di luar skop artikel ini dan akan diperbetulkan apabila ia timbul.

Saya harap maklumat ini berguna! πŸ™‚

Sumber: www.habr.com

Tambah komen