🥇Come migrare il contenitore OpenVZ 6 sul server KVM senza problemi

Chiunque abbia mai avuto bisogno di spostare un contenitore OpenVZ su un server con virtualizzazione KVM completa ha riscontrato alcuni problemi:

La maggior parte delle informazioni è semplicemente obsoleta ed era rilevante per i sistemi operativi che hanno da tempo superato il ciclo EOL
I diversi sistemi operativi forniscono sempre informazioni diverse e non prendono mai in considerazione possibili errori di migrazione
A volte è necessario gestire configurazioni che non vogliono funzionare dopo la migrazione.

Quando si migra un server, è sempre possibile correggere qualcosa al volo, ma cosa succede quando si migra un intero cluster?

In questo articolo cercherò di spiegarvi come migrare correttamente un contenitore OpenVZ su KVM riducendo al minimo i tempi di inattività e risolvendo rapidamente tutti i problemi.

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

Non entriamo nella terminologia, diciamo solo in termini generali:

OpenVZ - la virtualizzazione a livello di sistema operativo può essere implementata anche su un forno a microonde, poiché non sono necessarie istruzioni della CPU e tecnologie di virtualizzazione sulla macchina host.

KVM — virtualizzazione completa, che sfrutta tutta la potenza della CPU ed è in grado di virtualizzare qualsiasi cosa, in qualsiasi modo, tagliandola longitudinalmente e trasversalmente.

Contrariamente a quanto si crede, nell'ambiente fornitori di hosting OpenVZ è sopravvalutato, ma KVM no. Fortunatamente per quest'ultimo, KVM è ora sopravvalutato tanto quanto il suo fratello.

Cosa trasferiremo?

В качестве подопытных для переноса пришлось использовать весь лес операционных систем, которые доступны на OpenVZ: CentOS (6 и 7 версии), Ubuntu (14, 16 и 18 LTS), Debian 7.

Si presumeva che la maggior parte dei container OpenVZ avesse già un qualche tipo di LAMP in esecuzione, e alcuni addirittura un software molto specifico. Il più delle volte, si trattava di configurazioni con il pannello di controllo ISPmanager, VestaCP (e il più delle volte, non aggiornate da anni). È necessario tenere conto delle loro richieste di trasferimento.

La migrazione avviene con conservazione Indirizzi IP Per un contenitore portatile, daremo per scontato che l'indirizzo IP del contenitore venga mantenuto sulla VM e funzioni senza problemi.

Prima di procedere al trasferimento, assicuriamoci di avere tutto a portata di mano:

Server OpenVZ, accesso root completo alla macchina host, possibilità di arrestare/montare/avviare/rimuovere contenitori
Server KVM, accesso root completo alla macchina host, con tutto ciò che ne consegue. Si presume che tutto sia già configurato e pronto all'uso.

Iniziamo il trasferimento

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

KVM_NODE — Macchina host KVM
VZ_NODE - Macchina host OpenVZ
CTID — Contenitore OpenVZ
VM — Server virtuale KVM

Preparazione alla migrazione e creazione di macchine virtuali.

Passo 1

Poiché dobbiamo spostare il contenitore da qualche parte, creeremo VM con una configurazione simile su KVM_NODE.
Importante! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

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 necessario, la versione del sistema operativo all'interno della versione principale).

per CentOS этот процесс выглядит безобидно:

# yum clean all
# yum update -y

И не менее безобидно для Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Passo 2

Noi installiamo su CTID, VZ_NODE и VM utilità rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

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

Passo 3

Stiamo facendo una sosta CTID su VZ_NODE Il gruppo

vzctl stop CTID

Montaggio dell'immagine CTID:

vzctl mount CTID

Vai alla cartella /vz/root/CTID e lo realizziamo

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

In chroot, crea un file /root/exclude.txt: conterrà un elenco di eccezioni che non saranno incluse nel 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

Connettiamoci a KVM_NODE e lanciamo il nostro VMaffinché funzioni e sia accessibile tramite la rete.

Ora tutto è pronto per il trasferimento. Andiamo!

Passo 4

Ancora sotto l'effetto, 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 viene eseguito preservando i collegamenti simbolici, i diritti di accesso, i proprietari e i gruppi, e la crittografia è disabilitata per una maggiore velocità (era possibile utilizzare un cifrario più veloce, ma questo non è così importante nell'ambito di questo compito), così come la compressione è disabilitata.

Dopo aver completato rsync, uscire da chroot (premendo ctrl+d) ed eseguire

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

Passo 5

Eseguiamo diverse azioni che ci aiuteranno ad avviare la VM dopo la migrazione da OpenVZ.
Sui server con systemd eseguiamo un comando che ci aiuterà ad accedere a una console normale, ad esempio tramite una schermata del server VNC

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

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

yum install kernel-$(uname -r)

È possibile scaricare il server, ma dopo il trasferimento potrebbe smettere di funzionare o essere eliminato.

Sul server CentOS 7 è necessario applicare una piccola correzione per PolkitD, altrimenti il server cadrà in un avvio eterno:

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 mod_fcgid è stato installato per Apache, eseguiremo una piccola correzione con i diritti, altrimenti i siti che utilizzano mod_fcgid si bloccheranno con l'errore 500:

chmod +s `which suexec` && apachectl restart

И последнее, пригодится для Ubuntu, Debian дистрибутивов. Эта ОС может упасть в вечный бут с ошибкой

looping troppo veloce. esecuzione un po' limitata

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

Su Debian 9 la correzione appare così:

stiamo facendo

dbus-uuidgen

se riceviamo un errore

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

controlla 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 è ok, lo 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, prova la seconda opzione.

La seconda opzione per risolvere il problema con limitando un po' l'esecuzione подходит практически для всех Ubuntu и 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

Что мы сделали? Восстановили messagebus, которого не хватало для запуска Debian/Ubuntu и удалили modules_dep, который пришел от OpenVZ и мешал загрузки многих модулей ядра.

Passo 6

Riavviate la VM, verificate in VNC come procede il caricamento e, idealmente, tutto verrà caricato senza problemi. È possibile che si verifichino alcuni problemi specifici dopo la migrazione, ma vanno oltre lo scopo di questo articolo e verranno risolti non appena si presenteranno.

Spero che queste informazioni ti siano utili! 🙂

Fonte: habr.com