Comment migrer un conteneur OpenVZ 6 vers un serveur KVM sans tracas

Quiconque a déjà eu besoin de migrer un conteneur OpenVZ vers un serveur avec une virtualisation complète KVM a rencontré certains problèmes.

• La plupart des informations sont simplement obsolètes et étaient pertinentes pour des cycles EOL de systèmes d'exploitation déjà dépassés.
• Selon les systèmes d'exploitation, des informations différentes sont fournies, et les erreurs potentielles lors de la migration ne sont jamais abordées.
• Il arrive parfois de devoir gérer des configurations qui refusent de fonctionner après la migration.

Lorsque vous migrez un serveur, il est toujours possible de corriger des choses en cours de route, mais que faire lors de la migration d'un cluster entier ?

Dans cet article, je vais essayer d'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 point de référence : qu'est-ce qu'OpenVZ et qu'est-ce que KVM ?

Sans entrer dans les détails techniques, disons-le en termes généraux :

OpenVZ — virtualisation au niveau du système d'exploitation, qui peut même être mise en place sur un micro-ondes, car il n'est pas nécessaire d'avoir des instructions CPU et des technologies de virtualisation sur l'hôte.

KVM — virtualisation complète, utilisant toute la puissance du CPU et capable de virtualiser tout ce que vous voulez, de la manière que vous voulez, sans limites.

Contrairement à l'opinion répandue selon laquelle dans l'environnement fournisseurs d'hébergement OpenVZ il y a une surcharge, tandis que KVM n'en a pas — heureusement pour ce dernier, KVM est désormais tout aussi sujet à une surcharge que son homologue.

Que allons-nous migrer ?

Pour cette migration, nous avons dû utiliser toute la gamme des 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 faisaient déjà tourner un LAMP quelconque, et certains avaient même des logiciels très spécifiques. Le plus souvent, il s'agissait de configurations avec les panneaux de contrôle ISPmanager, VestaCP (et souvent, non mis à jour depuis des années). Il est nécessaire de prendre en compte leurs demandes de migration.

La migration se fait avec la conservation du adresses IP conteneur transférable, nous allons supposer que l'IP du conteneur est maintenue sur la VM et fonctionnera sans problème.

Avant la migration, assurons-nous que nous avons tout en main :

• Un serveur OpenVZ, un accès root complet à la machine hôte, la possibilité d'arrêter/mounter/démarrer/supprimer des conteneurs.
• Un serveur KVM, un accès root complet à la machine hôte, avec toutes les implications. On suppose que tout est déjà configuré et prêt à l'emploi.

Nous allons commencer le transfert

Avant de commencer le transfert, définissons les termes pour éviter toute confusion :

KVM_NODE — machine hôte KVM
VZ_NODE — machine hôte OpenVZ
CTID — conteneur OpenVZ
VM — serveur virtuel KVM

Préparation au transfert et création de machines virtuelles.

Étape 1

Comme nous devons transférer le conteneur quelque part, nous allons en créer un VM avec une configuration similaire sur KVM_NODE.
Attention ! La VM doit être créée sur le même système d'exploitation qui tourne actuellement sur CTID. Par exemple, si CTID utilise Ubuntu 14, alors la VM doit également utiliser Ubuntu 14. Les versions mineures ne sont pas critiques, mais les versions majeures doivent être identiques.

Après la création de la VM, nous mettrons à jour les paquets sur CTID et sur la VM (ne pas confondre avec la mise à jour du système d'exploitation — nous ne mettons à jour que les paquets et, si disponible, la version de l'OS dans la limite de la version majeure).

Pour CentOS, ce processus semble inoffensif :

# yum clean all
# yum update -y

Et tout aussi inoffensif pour Ubuntu, Debian :

# apt-get update
# apt-get upgrade

Étape 2

Installer sur CTID, VZ_NODE et VM outil rsync:

CentOS :

# yum install rsync -y

Debian, Ubuntu :

# apt-get install rsync -y

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

Étape 3

Nous procédons à l'arrêt CTID sur VZ_NODE la commande

vzctl stop CTID

Monter l'image CTID:

vzctl mount CTID

Nous accédons au dossier /vz/root/CTID et exécutons

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

Sous chroot, nous créons le fichier /root/exclude.txt — il contiendra la liste des exclusions qui ne seront pas transférées sur le 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 lançons notre VM, afin qu'il fonctionne et soit accessible sur le réseau.

Tout est maintenant prêt pour le transfert. Allons-y !

Étape 4

Toujours sous chroot, nous exécutons

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, espérons que les options sont claires — le transfert se fait en préservant les symlinks, les autorisations, les propriétaires et les groupes, et le chiffrement est désactivé pour une vitesse accrue (un algorithme de chiffrement plus rapide aurait pu être utilisé, mais ce n'est pas si crucial dans le cadre de cette tâche), tout comme la compression est désactivée.

Après l'achèvement de rsync, nous sortons de chroot (en appuyant sur ctrl+d) et exécutons

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

Étape 5

Nous allons effectuer quelques actions qui nous aideront à démarrer la VM après le transfert depuis OpenVZ.
Sur les serveurs avec Systemd , nous exécutons la commande qui nous aidera à nous connecter à la console normale, disons via l'écran VNC du serveur.

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

Sur les serveurs CentOS 6 et CentOS 7 , nous devons absolument installer un nouveau noyau :

yum install kernel-$(uname -r)

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

Sur le serveur CentOS 7 il est nécessaire d'appliquer un petit correctif pour PolkitD, sinon le serveur sera bloqué dans un boot infini :

getent group polkitd >/dev/null && echo -e "e[1;32mLe groupe polkitd existe déjàe[0m" || { groupadd -r polkitd && echo -e "e[1;33mGroupe polkitd manquant ajoutée[0m" || echo -e "e[1;31mÉchec de l'ajout du groupe polkitde[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mL'utilisateur polkitd existe déjàe[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Utilisateur pour polkitd" polkitd && echo -e "e[1;33mUtilisateur polkitd manquant ajoutée[0m" || echo -e "e[1;31mÉchec de l'ajout de l'utilisateur polkitde[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVérification des rpm polkit* réussiee[0m" || { echo -e "e[1;33mRéinitialisation de la propriété utilisateur / groupe des rpm polkit* et des permissionse[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Sur tous les serveurs, si mod_fcgid a été installé pour Apache, nous allons effectuer un petit correctif concernant les droits, sinon les sites utilisant mod_fcgid rencontreront une erreur 500 :

chmod +s `which suexec` && apachectl restart

Et enfin, ça sera utile pour les distributions Ubuntu et Debian. Ce système d'exploitation peut rencontrer un boot infini avec une erreur

looping too fast. throttling execution a little

c'est désagréable, mais ça se corrige facilement, selon la version du système d'exploitation.

Sur Debian 9 le correctif est le suivant :

on exécute

dbus-uuidgen

si nous recevons une erreur

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

nous vérifions 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 <-- c'est celui qu'il nous faut
libdbus-1.so.3.14.16

si tout est en ordre, nous exécutons

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 fonctionne pas — nous essayons la seconde option.

La seconde option pour résoudre le problème de throttling execution a little convient pratiquement à toutes les distributions Ubuntu et Debian.

Nous exécutons

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

Allowed Logout URLs Ubuntu 14, Debian 7 en plus, nous exécutons :

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

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

Que faisons-nous ? Nous avons restauré messagebus, qui manquait au démarrage de Debian/Ubuntu et avons supprimé modules_dep, qui venait d'OpenVZ et gênait le chargement de nombreux modules du noyau.

Étape 6

Nous redémarrons la VM, vérifions dans VNC comment se passe le démarrage et idéalement — tout devrait démarrer sans problème. Bien que, certaines problèmes spécifiques puissent apparaître après la migration — mais cela dépasse le cadre de cet article et se corrigent au fur et à mesure de leur survenue.

J'espère que ces informations seront utiles ! 🙂

Source : habr.com