Comment transférer le conteneur OpenVZ 6 vers le serveur KVM sans soucis

Quiconque a eu besoin de transférer un conteneur OpenVZ vers un serveur avec virtualisation KVM complète au moins une fois dans sa vie a rencontré quelques problèmes :

• La plupart des informations sont tout simplement obsolètes et étaient pertinentes pour les systèmes d'exploitation qui avaient dépassé depuis longtemps le cycle EOL.
• Différentes informations sont toujours fournies pour différents systèmes d'exploitation et les erreurs possibles lors de la migration ne sont jamais prises en compte.
• Parfois, vous devez faire face à des configurations qui, de temps en temps, ne veulent pas fonctionner après la migration

Lorsque vous transférez 1 serveur, vous pouvez toujours réparer quelque chose à la volée, mais lorsque vous transférez un cluster entier ?

Dans cet article, je vais essayer de vous expliquer comment migrer correctement un conteneur OpenVZ vers KVM avec un temps d'arrêt minimal et une solution rapide à tous les problèmes.

Un petit programme pédagogique : qu'est-ce qu'OpenVZ et qu'est-ce que KVM ?

Nous n'entrerons pas dans les détails de la terminologie, mais dirons en termes généraux :

OpenVZ — virtualisation au niveau du système d'exploitation, vous pouvez même la déployer sur un micro-ondes, puisqu'il n'y a pas besoin d'instructions CPU ni de technologies de virtualisation sur la machine hôte.

KVM - une virtualisation à part entière, utilisant toute la puissance du CPU et capable de virtualiser n'importe quoi, n'importe quelle manière, en le coupant dans le sens de la longueur et de la largeur.

Contrairement à la croyance populaire, dans l'environnement fournisseurs d'hébergement OpenVZ est survendu, contrairement à KVM. Heureusement pour ce dernier, KVM est désormais tout aussi survendu que son homologue.

Qu'allons-nous conserver ?

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

On supposait que la plupart des conteneurs OpenVZ exécutaient déjà une sorte de LAMP, et que certains disposaient même d'un logiciel très spécifique. Le plus souvent, il s'agissait de configurations avec le panneau de contrôle ISPmanager, VestaCP (et le plus souvent, non mises à jour depuis des années). Leurs demandes de transfert doivent également être prises en compte.

La migration s'effectue avec préservation Adresses IP Pour un conteneur portable, nous supposerons que l'adresse IP du conteneur est conservée sur la machine virtuelle et fonctionnera sans problème.

Avant de procéder au transfert, assurons-nous d’avoir tout sous la main :

• Serveur OpenVZ, accès root complet à la machine hôte, possibilité d'arrêter/monter/démarrer/supprimer des conteneurs
• Serveur KVM, accès root complet à la machine hôte, avec tout ce que cela implique. On suppose que tout est déjà configuré et prêt à fonctionner.

Commençons le transfert

Avant de commencer le transfert, définissons les termes qui vous aideront à éviter toute confusion :

KVM_NODE -Machine hôte KVM
VZ_NODE - Machine hôte OpenVZ
CTID - Conteneur OpenVZ
VM - Serveur virtuel KVM

Préparation de la migration et création de machines virtuelles.

Étape 1

Puisque nous devons déplacer le conteneur quelque part, nous allons créer VM avec une configuration similaire à KVM_NODE.
Important! Создавать VM нужно именно на той операционной системе, которая сейчас крутится на CTID. Например, если на CTID установлена Ubuntu 14, то и на VM нужно ставить Ubuntu 14. Минорные версии не важны и их несовпадение не столь критично, а вот мажорные — должны быть одинаковыми.

Après avoir créé la VM, nous mettrons à jour les packages sur le CTID et sur la VM (à ne pas confondre avec la mise à jour du système d'exploitation - nous ne le mettons pas à jour, nous mettons uniquement à jour les packages et, s'il arrive, la version du système d'exploitation dans le fichier principal version).

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

# yum clean all
# yum update -y

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

# apt-get update
# apt-get upgrade

Étape 2

Installer sur CTID, VZ_NODE и VM utilitaire rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nous n'installons rien d'autre ni là ni là.

Étape 3

Nous faisons un arrêt CTID sur VZ_NODE l'équipe

vzctl stop CTID

Montage de l'image CTID:

vzctl mount CTID

Allez dans le dossier /vz/root/CTID et exécuter

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

Sous la racine, créez un fichier /root/exclude.txt - il contiendra une liste d'exceptions qui ne parviendront pas au nouveau serveur

/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

Nous nous connectons à KVM_NODE et lancer notre VMpour qu'il fonctionne et soit accessible sur le réseau.

Maintenant, tout est prêt pour le transfert. Aller!

Étape 4

Toujours sous le charme, nous performons

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

La commande rsync effectuera le transfert, nous espérons que les clés sont claires - le transfert est effectué avec la préservation des liens symboliques, des droits d'accès, des propriétaires et des groupes, et le cryptage est désactivé pour une plus grande vitesse (vous pouvez utiliser un chiffrement plus rapide, mais ce n'est pas si important pour cette tâche) , et la compression est également désactivée.

Après avoir terminé rsync, quittez le chroot (en appuyant sur ctrl+d) et exécutez

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

Étape 5

Effectuons plusieurs étapes qui nous aideront à lancer la VM après le transfert depuis OpenVZ.
Sur les serveurs avec Systemd exécutons une commande qui nous aidera à nous connecter à une console classique, par exemple, via l'écran d'un serveur VNC

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

Sur les serveurs CentOS 6 и CentOS 7 Assurez-vous d'installer un nouveau noyau :

yum install kernel-$(uname -r)

Le serveur peut être chargé à partir de celui-ci, mais après le transfert, il peut cesser de fonctionner ou être supprimé.

Sur le serveur CentOS 7 vous devez appliquer un petit correctif pour PolkitD, sinon le serveur plantera pour toujours :

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

Sur tous les serveurs, si mod_fcgid pour Apache a été installé, nous effectuerons un petit correctif avec droits, sinon les sites utilisant mod_fcgid planteront avec l'erreur 500 :

chmod +s `which suexec` && apachectl restart

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

boucle trop rapide. limitation un peu de l'exécution

désagréable, mais facile à corriger, selon la version du système d'exploitation.

Sur Debian 9 le correctif ressemble à ceci :

nous effectuons

dbus-uuidgen

si nous obtenons une erreur

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

vérifier la présence de 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

si tout est en ordre, nous le faisons

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

Si cela ne résout pas le problème, essayez la deuxième option.

La deuxième solution au problème de limitation un peu de l'exécution подходит практически для всех Ubuntu и Debian дистрибутивов.

Nous réalisons

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

Et pour Ubuntu 14, Debian 7 De plus, nous effectuons :

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 и мешал загрузки многих модулей ядра.

Étape 6

Nous redémarrons la VM, vérifions dans VNC la progression du chargement et, idéalement, tout se chargera sans problème. Bien qu'il soit possible que certains problèmes spécifiques apparaissent après la migration, ils sortent du cadre de cet article et seront corrigés au fur et à mesure de leur apparition.

J'espère que cette information est utile! 🙂

Source: habr.com