🥇Come migrare 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 KVM si è trovato di fronte a diverse problematiche:

La maggior parte delle informazioni è semplicemente obsoleta e si riferisce a cicli EOL di sistemi operativi ormai superati.
Le informazioni variano a seconda dei sistemi operativi e non vengono mai considerate le possibili problematiche durante la migrazione.
A volte ci si imbatte in configurazioni che non funzionano dopo la migrazione.

Quando trasferisci un singolo server puoi sempre correggere qualcosa, ma quando trasferisci un intero cluster?

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

Un breve chiarimento: che cos'è OpenVZ e che cos'è KVM?

Non approfondiamo la terminologia, ma diremo in termini generali:

OpenVZ — virtualizzazione a livello di sistema operativo, può essere implementata anche su un microonde, poiché non è necessaria la presenza di istruzioni CPU e tecnologie di virtualizzazione sulla macchina host.

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

Contrariamente a quanto si possa pensare nel settore hosting provider OpenVZ è oversold mentre KVM no — fortunatamente per i secondi, KVM oggi è oversold non meno del suo simile.

Cosa dobbiamo trasferire?

Come cavie per il trasferimento, sono state utilizzate tutte le distribuzioni 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 container OpenVZ avesse già installato qualche LAMP, e alcuni avessero persino software molto specifico. Nella maggior parte dei casi, si trattava di configurazioni con il pannello di controllo ISPmanager, VestaCP (e spesso non aggiornate da anni). È importante considerare anche le loro esigenze di trasferimento.

La migrazione avviene con la preservazione Indirizzi IP del container trasferito, supponiamo che l'IP che aveva il container venga mantenuto sulla VM e funzioni senza problemi.

Prima del trasferimento, assicuriamoci di avere tutto a disposizione:

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

Iniziamo il trasferimento

Prima di iniziare il trasferimento, definiamo i termini che ci aiuteranno a non confonderci:

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

Preparazione al trasferimento e creazione di macchine virtuali.

Passo 1

Poiché abbiamo bisogno di trasferire il contenitore, creiamo VM con configurazione simile su KVM_NODE.
Attenzione! La VM deve essere creata sullo stesso sistema operativo attualmente in esecuzione su CTID. Ad esempio, se su CTID è installato Ubuntu 14, anche sulla VM deve essere installato Ubuntu 14. Le versioni minori non sono così importanti e la loro mancata corrispondenza non è così critica, ma quelle maggiori devono essere identiche.

Dopo la creazione della VM, eseguiamo l'aggiornamento dei pacchetti su CTID e su VM (non confondere con l'aggiornamento del sistema operativo — non lo aggiorniamo, aggiornando 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, Debian:

# apt-get update
# apt-get upgrade

Passo 2

Installiamo su CTID, VZ_NODE e VM un'utility rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Non installiamo nient'altro né lì né là.

Passo 3

Procediamo con l'arresto CTID con VZ_NODE comando

vzctl stop CTID

Montiamo l'immagine CTID:

vzctl mount CTID

Accediamo 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à l'elenco delle 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

Colleghiamoci a KVM_NODE e avviamo il nostro VM, affinché funzioni e sia accessibile in rete.

Adesso tutto è pronto per il trasferimento. Andiamo!

Passo 4

Rimanendo ancora all'interno del 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 chiavi siano chiare — il trasferimento avverrà mantenendo i symlink, i permessi, i proprietari e i gruppi, ed è disabilitata la crittografia per una maggiore velocità (si sarebbe potuto usare un cifrario più veloce, ma non è così fondamentale in questo contesto), così come è disabilitata anche la compressione.

Dopo che rsync ha terminato l'esecuzione, usciamo dal chroot (premendo ctrl+d) e eseguiamo

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

Passo 5

Eseguiremo alcune operazioni che ci aiuteranno ad avviare la VM dopo il trasferimento da OpenVZ.
Su server con Systemd Eseguiremo un comando che ci aiuterà ad accedere alla console normale, ad esempio, tramite VNC dello schermo del server.

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

Sui server CentOS 6 e CentOS 7 è necessario installare un nuovo kernel:

yum install kernel-$(uname -r)

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

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

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already exists e[0m" || { groupadd -r polkitd && echo -e "e[1;33mAggiunto il gruppo polkitd mancante e[0m" || echo -e "e[1;31mAggiunta del gruppo polkitd FALLITA e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd user already exists e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Utente per polkitd" polkitd && echo -e "e[1;33mAggiunto l'utente polkitd mancante e[0m" || echo -e "e[1;31mAggiunta dell'utente polkitd FALLITA e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* verifica rpm superata e[0m" || { echo -e "e[1;33mRipristino della proprietà/permessi utente/gruppo polkit* e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Su tutti i server, se mod_fcgid per Apache è stato installato, eseguiamo una piccola correzione dei permessi, altrimenti i siti che utilizzano mod_fcgid subiranno errori 500:

chmod +s `which suexec` && apachectl restart

E infine, utile per le distribuzioni Ubuntu e Debian. Questo sistema operativo può incorrere in un boot loop permanente con un errore

looping too fast. rallentando un po' l'esecuzione

scomodo, ma si risolve facilmente, a seconda della versione del sistema operativo.

Su Debian 9 la soluzione appare così:

eseguiamo

dbus-uuidgen

se otteniamo 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 che serve
libdbus-1.so.3.14.16

se tutto è a posto, 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.

La seconda opzione per risolvere il problema con throttling execution a little funziona praticamente per tutte le distribuzioni Ubuntu e Debian.

Eseguiamo

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

E per Ubuntu 14, Debian 7 eseguiamo anche:

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

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

Cosa abbiamo fatto? Abbiamo ripristinato il messagebus, mancante per il funzionamento di Debian/Ubuntu e rimosso modules_dep, che proveniva da OpenVZ e ostacolava il caricamento di molti moduli del kernel.

Passo 6

Riavviamo la VM, verifichiamo in VNC come procede il caricamento e, idealmente, tutto si avvierà senza problemi. Anche se potrebbero emergere alcune problematiche specifiche dopo la migrazione, queste esulano da questo articolo e vengono risolte man mano che si presentano.

Spero che queste informazioni siano utili! 🙂

Fonte: habr.com