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 selon laquelle parmi les fournisseurs d'hébergement, OpenVZ deviendra survendu, mais pas KVM - heureusement pour ce dernier, KVM n'est désormais pas pire que son frère.

Qu'allons-nous conserver ?

Comme sujets de test pour le transfert, nous avons dû utiliser toute la forêt de systèmes d'exploitation disponibles sur OpenVZ : CentOS (versions 6 et 7), Ubuntu (14, 16 et 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 en préservant l'adresse IP du conteneur transféré ; nous supposerons que l'IP que possédait le conteneur est enregistrée sur la VM 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! Vous devez créer une VM sur le système d'exploitation qui s'exécute actuellement sur CTID. Par exemple, si Ubuntu 14 est installé sur le CTID, alors Ubuntu 14 doit être installé sur la machine virtuelle. Les versions mineures ne sont pas importantes et leur divergence n'est pas si critique, mais les versions majeures devraient être les mêmes.

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, ce processus semble inoffensif :

# yum clean all
# yum update -y

Et non moins inoffensif pour Ubuntu et 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Sur les serveurs 6 CentOS и 7 CentOS 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 7 CentOS 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

Et la dernière chose est utile pour les distributions Ubuntu et Debian. Ce système d'exploitation peut planter lors d'un démarrage éternel avec une erreur

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 Convient à presque toutes les distributions Ubuntu et 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 

Qu'avons-nous fait? Nous avons restauré messagebus, qui manquait pour exécuter Debian/Ubuntu, et supprimé modules_dep, qui provenait d'OpenVZ et interférait avec le chargement de nombreux modules du noyau.

É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