🥇Come trasferire un contenitore OpenVZ 6 su un server KVM senza stress

Chiunque abbia mai avuto bisogno di trasferire un container OpenVZ su un server con virtualizzazione completa KVM si è trovato ad affrontare alcuni problemi:

Gran parte delle informazioni è semplicemente obsoleta e risale a cicli EOL di sistemi operativi già da tempo superati.
A seconda dei sistemi operativi, vengono fornite informazioni diverse e non vengono mai considerate le possibili errori nella migrazione.
A volte ci si deve confrontare con configurazioni che continuano a non funzionare dopo la migrazione.

Quando trasferisci un server puoi sempre apportare delle correzioni al volo, ma cosa succede quando trasferisci un intero cluster?

In questo articolo cercherò di spiegare come migrari correttamente un container OpenVZ su KVM con il minimo downtime e una rapida risoluzione di tutti i problemi.

Una piccola introduzione: cos'è OpenVZ e cos'è KVM?

Non approfondiremo la terminologia, ma diremo in generale:

OpenVZ — virtualizzazione a livello di sistema operativo, è possibile implementarla anche su un microonde, poiché non è necessario avere istruzioni CPU e tecnologie di virtualizzazione sulla macchina host.

KVM — virtualizzazione completa, che utilizza tutta la potenza della CPU e in grado di virtualizzare qualsiasi cosa, come si vuole, tagliando in lungo e in largo.

Contrariamente a quanto si crede comunemente, nel contesto di fornitori di hosting OpenVZ si verifica un overselling, mentre KVM no — fortunatamente per quest'ultimo, KVM attualmente si vende in modo altrettanto eccessivo come il suo fratello.

Cosa dobbiamo trasferire?

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

Si presume che sulla maggior parte dei container OpenVZ sia già in esecuzione un LAMP, e alcuni hanno anche software molto specifico. Spesso, si trattava di configurazioni con il pannello di controllo ISPmanager, VestaCP (e spesso, non aggiornate da anni). È necessario tenere conto anche delle loro esigenze in merito al trasferimento.

La migrazione viene eseguita mantenendo Indirizzi IP il container trasferito, consideriamo che l'IP del container venga mantenuto sulla VM e funzioni senza problemi.

Prima del trasferimento assicuriamoci di avere tutto a disposizione:

Server OpenVZ, accesso root completo alla macchina host, capacità di fermare/montare/avviare/rimuovere i container.
Server KVM, accesso root completo alla macchina host, con tutte le implicazioni. Si presume che tutto sia già configurato e pronto per l'operatività.

Iniziamo il trasferimento

Prima di iniziare il trasferimento, definiamo alcuni termini per non confonderci:

KVM_NODE — macchina host KVM
VZ_NODE — macchina host OpenVZ
CTID — contenitore OpenVZ
VM — server virtuale KVM

Preparazione per il trasferimento e creazione di macchine virtuali.

Passo 1

Dato che dobbiamo trasferire il contenitore, creiamo VM con una configurazione simile su KVM_NODE.
Importante! Le VM devono essere create proprio sul sistema operativo che è attualmente in esecuzione su CTID. Ad esempio, se su CTID è installato Ubuntu 14, allora anche sulla VM dovresti installare Ubuntu 14. Le versioni minori non sono importanti e la loro non corrispondenza non è così critica, mentre quelle maggiori devono essere identiche.

Dopo aver creato la VM, eseguiamo l'aggiornamento dei pacchetti su CTID e su VM (non confondere con l'aggiornamento del sistema operativo — non aggiorniamo il sistema operativo, aggiorniamo solo i pacchetti e, se disponibile, la versione del sistema operativo all'interno della versione principale).

Per CentOS, questo processo appare innocuo:

# yum clean all
# yum update -y

E altrettanto innocuo per Ubuntu e Debian:

# apt-get update
# apt-get upgrade

Passo 2

Installiamo su CTID, VZ_NODE e VM utilità rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Non installiamo altro né lì né altrove.

Passo 3

Effettuiamo l'arresto CTID in VZ_NODE comando

vzctl stop CTID

Montiamo l'immagine CTID:

vzctl mount CTID

Passiamo alla cartella /vz/root/CTID e eseguiamo

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

All'interno del chroot, creiamo il file /root/exclude.txt — conterrà un elenco di eccezioni che non verranno trasferite sul 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 connettiamo a KVM_NODE e avviamo il nostro VM, affinché funzioni e sia accessibile in rete.

Ora tutto è pronto per il trasferimento. Partiamo!

Passo 4

Essendo ancora nel chroot, eseguiamo

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 opzioni siano chiare — il trasferimento viene effettuato mantenendo i symlink, i permessi, i proprietari e i gruppi, ed è disabilitata la crittografia per una maggiore velocità (avremmo potuto utilizzare un algoritmo di crittografia più veloce, ma non è così cruciale per questo compito), così come la compressione è disabilitata.

Dopo aver completato l'esecuzione di rsync, usciamo dal chroot (premendo ctrl+d) e eseguiamo

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

Passaggio 5

Effettuiamo alcune azioni che ci aiuteranno ad avviare la VM dopo il trasferimento da OpenVZ.
Su server con Systemd eseguiamo il comando che ci aiuterà a collegarci nella console normale, ad esempio, tramite VNC sullo schermo del server

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

Su server CentOS 6 e CentOS 7 installeremo sicuramente un nuovo kernel:

yum install kernel-$(uname -r)

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

Sul server CentOS 7 è necessario applicare una piccola correzione per PolkitD, altrimenti il server andrà in boot infinito:

getent group polkitd >/dev/null && echo -e "e[1;32mIl gruppo polkitd esiste giàe[0m" || { groupadd -r polkitd && echo -e "e[1;33mGruppo polkitd mancante aggiuntoe[0m" || echo -e "e[1;31mAggiunta gruppo polkitd FALLITAe[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mL'utente polkitd esiste giàe[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Utente per polkitd" polkitd && echo -e "e[1;33mUtente polkitd mancante aggiuntoe[0m" || echo -e "e[1;31mAggiunta utente polkitd FALLITAe[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVerifica rpm di polkit* superatae[0m" || { echo -e "e[1;33mRipristino della proprietà utente/gruppo e dei permessi di polkit*e[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 sui permessi, altrimenti i siti che utilizzano mod_fcgid genereranno un errore 500:

chmod +s `which suexec` && apachectl restart

E infine, questo sarà utile per le distribuzioni Ubuntu e Debian. Questo sistema operativo può andare in boot infinito con l'errore

looping too fast. throttling execution a little

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

A Debian 9 la correzione si presenta così:

eseguiamo

dbus-uuidgen

se riceviamo un errore

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

controlliamo 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 <-- questo è necessario
libdbus-1.so.3.14.16

se tutto va bene, eseguiamo

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 funziona — proviamo la seconda opzione.

Seconda opzione per risolvere il problema con throttling execution a little è praticamente adatta per tutte le distribuzioni Ubuntu e Debian.

Eseguiamo

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

Allowed Logout URLs 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 l'avvio di Debian/Ubuntu e rimosso modules_dep, che proveniva da OpenVZ e interferiva con il caricamento di molti moduli del kernel.

Passaggio 6

Riavviamo la VM, verifichiamo in VNC come va il caricamento e idealmente — tutto si caricherà senza problemi. Anche se potrebbero sorgere alcuni problemi specifici dopo la migrazione — ma questi vanno oltre il tema di questo articolo e vengono risolti man mano che si presentano.

Spero che queste informazioni siano utili! 🙂

Fonte: habr.com