Come trasferire il contenitore OpenVZ 6 sul server KVM senza grattacapi

Chiunque abbia avuto bisogno, almeno una volta nella vita, di trasferire un container OpenVZ su un server con virtualizzazione KVM completa, ha riscontrato alcuni problemi:

• La maggior parte delle informazioni sono semplicemente obsolete ed erano rilevanti per i sistemi operativi che avevano superato da tempo il ciclo EOL
• Vengono sempre fornite informazioni diverse per i diversi sistemi operativi e non vengono mai presi in considerazione eventuali errori durante la migrazione
• A volte bisogna fare i conti con configurazioni che ogni tanto non vogliono funzionare dopo la migrazione

Quando trasferisci 1 server, puoi sempre sistemare qualcosa al volo, ma quando trasferisci un intero cluster?

In questo articolo cercherò di dirti come migrare correttamente un contenitore OpenVZ su KVM con tempi di inattività minimi e una soluzione rapida a tutti i problemi.

Un piccolo programma didattico: cos'è OpenVZ e cos'è KVM?

Non approfondiremo la terminologia, ma diremo in termini generali:

OpenVZ — virtualizzazione a livello del sistema operativo, è possibile implementarla anche su un forno a microonde, poiché non sono necessarie istruzioni della CPU e tecnologie di virtualizzazione sulla macchina host.

KVM - virtualizzazione a tutti gli effetti, sfruttando tutta la potenza della CPU e capace di virtualizzare qualsiasi cosa, in qualsiasi modo, tagliandola longitudinalmente e trasversalmente.

Contrariamente alla credenza popolare secondo cui tra i provider di hosting OpenVZ diventerà ipervenduto, ma KVM no: fortunatamente per quest'ultimo, KVM ora è ipervenduto non peggio di suo fratello.

Cosa riporteremo?

Come soggetti di prova per il trasferimento abbiamo dovuto utilizzare l'intera foresta di sistemi operativi disponibili su OpenVZ: CentOS (versioni 6 e 7), Ubuntu (14, 16 e 18 LTS), Debian 7.

Si presumeva che la maggior parte dei contenitori OpenVZ eseguissero già una sorta di LAMP e alcuni avessero addirittura un software molto specifico. Molto spesso si trattava di configurazioni con il pannello di controllo ISPmanager e VestaCP (e molto spesso non aggiornate da anni). Anche le loro richieste di trasferimento devono essere prese in considerazione.

La migrazione viene effettuata preservando l'indirizzo IP del container trasferito; supponiamo che l'IP che aveva il container sia salvato sulla VM e funzionerà senza problemi.

Prima del trasferimento assicuriamoci di avere tutto a portata di mano:

• Server OpenVZ, accesso root completo al computer host, possibilità di arrestare/montare/avviare/eliminare contenitori
• Server KVM, accesso root completo alla macchina host, con tutto ciò che implica. Si presuppone che tutto sia già configurato e pronto per l'uso.

Iniziamo il trasferimento

Prima di iniziare il trasferimento, definiamo i termini che ti aiuteranno a evitare confusione:

KVM_NODO - Macchina host KVM
VZ_NODO - Macchina host OpenVZ
CTID - Contenitore OpenVZ
VM -Server virtuale KVM

Preparazione alla migrazione e creazione di macchine virtuali.

Passo 1

Dato che dobbiamo spostare il contenitore da qualche parte, creeremo VM con una configurazione simile a KVM_NODO.
Importante! È necessario creare una macchina virtuale nel sistema operativo attualmente in esecuzione su CTID. Ad esempio, se sul CTID è installato Ubuntu 14, sulla VM deve essere installato Ubuntu 14. Le versioni minori non sono importanti e la loro discrepanza non è così critica, ma le versioni principali dovrebbero essere le stesse.

Dopo aver creato la VM, aggiorneremo i pacchetti sul CTID e sulla VM (da non confondere con l'aggiornamento del sistema operativo - non lo aggiorniamo, aggiorniamo solo i pacchetti e, se arriva, la versione del sistema operativo all'interno del main versione).

Per CentOS questo processo sembra innocuo:

# yum clean all
# yum update -y

E non meno innocuo per Ubuntu e Debian:

# apt-get update
# apt-get upgrade

Passo 2

Installa su CTID, VZ_NODO и VM utilità rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Non stiamo installando nient'altro né lì né lì.

Passo 3

Facciamo una sosta CTID su VZ_NODO Il gruppo

vzctl stop CTID

Montaggio dell'immagine CTID:

vzctl mount CTID

Vai alla cartella /vz/root/CTID ed eseguire

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

Sotto root, crea un file /root/exclude.txt: conterrà un elenco di eccezioni che non arriveranno al nuovo server

/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

Ci colleghiamo a KVM_NODO e lancia il nostro VMin modo che funzioni e sia accessibile tramite la rete.

Adesso è tutto pronto per il trasferimento. Andare!

Passo 4

Ancora sotto l'incantesimo, ci esibiamo

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

Il comando rsync eseguirà il trasferimento, speriamo che le chiavi siano chiare: il trasferimento viene effettuato preservando i collegamenti simbolici, i diritti di accesso, i proprietari e i gruppi e la crittografia è disabilitata per una maggiore velocità (potresti usare una cifratura più veloce, ma questo non è così importante per questa attività), così come la compressione è disabilitata.

Dopo aver completato rsync, esci da chroot (premendo ctrl+d) ed esegui

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

Passo 5

Eseguiamo diversi passaggi che ci aiuteranno ad avviare la VM dopo il trasferimento da OpenVZ.
Sui server con systemd eseguiamo un comando che ci aiuterà ad accedere a una normale console, ad esempio, attraverso la schermata di un server VNC

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

Sui server 6 CentOS и 7 CentOS Assicurati di installare un nuovo kernel:

yum install kernel-$(uname -r)

Il server può essere caricato da esso, ma dopo il trasferimento potrebbe smettere di funzionare o essere eliminato.

Sul server 7 CentOS devi applicare una piccola correzione per PolkitD, altrimenti il ​​server si bloccherà per sempre:

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

Su tutti i server, se è stato installato mod_fcgid per Apache, eseguiremo una piccola correzione con diritti, altrimenti i siti che utilizzano mod_fcgid si bloccheranno con errore 500:

chmod +s `which suexec` && apachectl restart

E l'ultima cosa è utile per le distribuzioni Ubuntu e Debian. Questo sistema operativo potrebbe bloccarsi in un avvio eterno con un errore

looping troppo veloce. limitando leggermente l'esecuzione

spiacevole, ma facilmente risolvibile, a seconda della versione del sistema operativo.

Su Debian 9 la correzione è simile a questa:

eseguiamo

dbus-uuidgen

se riceviamo un errore

/usr/local/lib/libdbus-1.so.3: versione `LIBDBUS_PRIVATE_1.10.8′ non trovata

verificare la presenza di 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

se tutto è in ordine, lo facciamo

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

Se non aiuta, prova la seconda opzione.

La seconda soluzione al problema con limitando leggermente l'esecuzione Adatto a quasi tutte le distribuzioni Ubuntu e Debian.

Effettuiamo

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

E per Ubuntu 14, Debian 7 Inoltre eseguiamo:

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

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

Cosa abbiamo fatto? Abbiamo ripristinato messagebus, che mancava per eseguire Debian/Ubuntu, e rimosso moduli_dep, che proveniva da OpenVZ e interferiva con il caricamento di molti moduli del kernel.

Passo 6

Riavviamo la VM, controlliamo in VNC come sta procedendo il caricamento e, idealmente, tutto verrà caricato senza problemi. Sebbene sia possibile che si verifichino alcuni problemi specifici dopo la migrazione, essi esulano dall'ambito di questo articolo e verranno corretti non appena si presentano.

Spero che questa informazione sia utile! 🙂

Fonte: habr.com