🥇 Cómo transferir un contenedor OpenVZ 6 a un servidor KVM sin complicaciones

Cualquiera que haya tenido que transferir un contenedor OpenVZ a un servidor con virtualización completa KVM se ha encontrado con algunos problemas.

La mayoría de la información está desactualizada y era relevante para ciclos de EOL de sistemas operativos que ya han pasado.
Dependiendo del sistema operativo, se proporciona información variada, y nunca se consideran los posibles errores durante la migración.
A veces se trata con configuraciones que de repente no quieren funcionar después de la migración.

Cuando trasladamos un servidor siempre se puede corregir algo en el camino, ¿pero qué pasa cuando movemos todo un clúster?

En este artículo, intentaré explicar cómo migrar correctamente un contenedor OpenVZ a KVM con un tiempo de inactividad mínimo y una rápida resolución de todos los problemas.

Un pequeño repaso: ¿qué es OpenVZ y qué es KVM?

No profundizaremos en la terminología, pero de manera general:

OpenVZ — virtualización a nivel de sistema operativo, se puede implementar incluso en un microondas, ya que no se requieren instrucciones de CPU y tecnologías de virtualización en la máquina anfitriona.

KVM — virtualización completa que utiliza toda la potencia de la CPU y puede virtualizar cualquier cosa, de cualquier manera, cortando a través y a lo ancho.

A pesar de la creencia común de que en el entorno de los proveedores de alojamiento OpenVZ se sobreasigna, mientras que KVM no lo hace; afortunadamente para los últimos, KVM actualmente se sobreasigna tan bien como su hermano.

¿Qué vamos a trasladar?

Para la migración se utilizó toda la gama de sistemas operativos disponibles en OpenVZ: CentOS (versiones 6 y 7), Ubuntu (14, 16 y 18 LTS), Debian 7.

Se suponía que en la mayoría de los contenedores OpenVZ ya estaba funcionando algún tipo de LAMP, y algunos incluso tenían software muy específico. Con mayor frecuencia, eran configuraciones con panel de control ISPmanager, VestaCP (y la mayoría de las veces, sin actualizar durante años). También es necesario considerar sus requerimientos para la migración.

La migración se lleva a cabo manteniendo IP el contenedor transferible, supongamos que la IP que tenía el contenedor se conserva en la VM y funcionará sin problemas.

Antes de la migración, asegurémonos de tener todo en orden:

Servidor OpenVZ, acceso root completo a la máquina anfitriona, capacidad para detener/montar/iniciar/eliminar contenedores.
Servidor KVM, con acceso root completo a la máquina host y todas las implicaciones. Se asume que todo ya está configurado y listo para funcionar.

Empezamos la migración

Antes de comenzar la migración, definamos los términos que nos ayudarán a no confundirnos:

KVM_NODE — máquina host KVM
VZ_NODE — máquina host OpenVZ
CTID — contenedor OpenVZ
VM — servidor virtual KVM

Preparativos para la migración y creación de máquinas virtuales.

Compra una suscripción

Dado que necesitamos migrar contenedores, vamos a crear VM con una configuración similar en KVM_NODE.
¡Importante! Las VM deben crearse exactamente en el mismo sistema operativo que está funcionando en el CTID. Por ejemplo, si el CTID tiene Ubuntu 14, también se debe instalar Ubuntu 14 en la VM. Las versiones menores no son críticas y su desajuste no es tan importante, pero las principales deben ser idénticas.

Después de crear la VM, actualizaremos los paquetes en el CTID y en la VM (no confundir con la actualización del SO: no actualizamos el SO, solo los paquetes y, si es necesario, la versión del SO dentro de la versión principal).

Para CentOS, este proceso parece inocente:

# yum clean all
# yum update -y

Igualmente inocente para Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Paso 2

Instalamos en CTID, VZ_NODE y VM herramienta rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

No instalamos nada más ni allí ni aquí.

Paso 3

Detenemos CTID en VZ_NODE con el comando

vzctl stop CTID

Montamos la imagen CTID:

vzctl mount CTID

Entramos en la carpeta /vz/root/CTID y ejecutamos

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

Bajo chroot creamos el archivo /root/exclude.txt — contendrá la lista de excepciones que no se transferirán al nuevo servidor.

/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

Nos conectamos a KVM_NODE y activamos nuestro VM, para que funcione y sea accesible a través de la red.

Ahora todo está listo para la migración. ¡Vamos!

Paso 4

Aún bajo chroot, ejecutamos

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

El comando rsync realizará la transferencia, esperamos que las claves sean claras: la transferencia se lleva a cabo conservando los enlaces simbólicos, los permisos, los propietarios y los grupos, y se desactiva el cifrado para mayor velocidad (se pudo haber utilizado algún cifrado más rápido, pero eso no es tan esencial en esta tarea), así como la compresión también está desactivada.

Al finalizar el rsync, salimos del chroot (presionando ctrl+d) y ejecutamos

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

Paso 5

Realizaremos algunas acciones que nos ayudarán a iniciar la VM después de la migración desde OpenVZ.
En servidores con Systemd ejecutaremos un comando que nos ayudará a iniciar sesión en la consola normal, digamos, a través de la pantalla VNC del servidor

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

En los servidores CentOS 6 y CentOS 7 deberemos instalar un núcleo nuevo:

yum install kernel-$(uname -r)

El servidor puede arrancar desde él, pero después de la transferencia puede dejar de funcionar o ser eliminado.

En el servidor CentOS 7 es necesario aplicar una pequeña solución para PolkitD, de lo contrario el servidor caerá en un bucle infinito:

getent group polkitd >/dev/null && echo -e "e[1;32mEl grupo polkitd ya existee[0m" || { groupadd -r polkitd && echo -e "e[1;33mGrupo polkitd añadidoe[0m" || echo -e "e[1;31mError al añadir el grupo polkitd e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mEl usuario polkitd ya existee[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Usuario para polkitd" polkitd && echo -e "e[1;33mUsuario polkitd añadidoe[0m" || echo -e "e[1;31mError al añadir el usuario polkitd e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVerificación de rpm polkit* completadae[0m" || { echo -e "e[1;33mRestableciendo la propiedad de usuario/grupo y permisos de rpm polkit*e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

En todos los servidores, si se ha instalado mod_fcgid para Apache, realizaremos una pequeña solución con permisos, de lo contrario, los sitios que utilizan mod_fcgid fallarán con un error 500:

chmod +s `which suexec` && apachectl restart

Y por último, será útil para distribuciones de Ubuntu y Debian. Este SO puede caer en un bucle infinito con un error

looping too fast. throttling execution a little

desagradable, pero fácil de arreglar, dependiendo de la versión del SO.

En Debian 9 la solución se ve así:

ejecutamos

dbus-uuidgen

si obtenemos un error

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

verificamos la presencia 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 <-- se necesita este
libdbus-1.so.3.14.16

si todo está bien, ejecutamos

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 no ayuda, probamos la segunda opción.

Segunda opción para resolver el problema con throttling execution a little funciona prácticamente para todas las distribuciones de Ubuntu y Debian.

Ejecutamos

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

Allowed Logout URLs Ubuntu 14, Debian 7 además realizamos:

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

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

¿Qué hicimos? Restauramos messagebus, que faltaba para iniciar Debian/Ubuntu y eliminamos modules_dep, que vino de OpenVZ y obstaculizaba la carga de muchos módulos del núcleo.

Paso 6

Reiniciamos la VM, verificamos a través de VNC cómo va el arranque y en ideal — todo se cargará sin problemas. Aunque, puede que aparezcan algunos problemas específicos después de la migración — pero estos están fuera del alcance de este artículo y se corrigen a medida que surgen.

¡Espero que esta información sea útil! 🙂

Fuente: habr.com