Cómo transferir el contenedor OpenVZ 6 al servidor KVM sin dolores de cabeza

Cualquiera que haya necesitado al menos una vez en su vida transferir un contenedor OpenVZ a un servidor con virtualización KVM completa se ha encontrado con algunos problemas:

• La mayor parte de la información simplemente está desactualizada y era relevante para los sistemas operativos que ya habían superado el ciclo EOL.
• Siempre se proporciona información diferente para diferentes sistemas operativos y nunca se consideran posibles errores durante la migración.
• A veces tienes que lidiar con configuraciones que de vez en cuando no quieren funcionar después de la migración.

Cuando transfieres 1 servidor, siempre puedes arreglar algo sobre la marcha, pero ¿cuando transfieres un clúster completo?

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

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

No profundizaremos en la terminología, pero diremos en términos generales:

OpenVZ — virtualización a nivel del sistema operativo, incluso puede implementarla en un microondas, ya que no hay necesidad de instrucciones de CPU ni tecnologías de virtualización en la máquina host.

KVM - virtualización completa, que utiliza toda la potencia de la CPU y es capaz de virtualizar cualquier cosa, de cualquier forma, cortándola a lo largo y a lo ancho.

Contrariamente a la creencia popular de que entre los proveedores de alojamiento OpenVZ estará sobrevendido, pero KVM no; afortunadamente para este último, KVM ahora no está sobrevendido peor que su hermano.

¿Qué llevaremos?

Como sujetos de prueba para la transferencia tuvimos que utilizar todo el bosque de sistemas operativos disponibles en OpenVZ: CentOS (versiones 6 y 7), Ubuntu (14, 16 y 18 LTS), Debian 7.

Se suponía que la mayoría de los contenedores OpenVZ ya ejecutaban algún tipo de LAMP, y algunos incluso tenían algún software muy específico. En la mayoría de los casos, se trataba de configuraciones con el ISPmanager, el panel de control VestaCP (y la mayoría de las veces, no se actualizaban desde hacía años). También hay que tener en cuenta sus solicitudes de transferencia.

La migración se realiza conservando la dirección IP del contenedor transferido, asumiremos que la IP que tenía el contenedor está guardada en la VM y funcionará sin problemas.

Antes de realizar la transferencia, asegurémonos de tener todo a mano:

• Servidor OpenVZ, acceso raíz completo a la máquina host, capacidad de detener/montar/iniciar/eliminar contenedores
• Servidor KVM, acceso root completo a la máquina host, con todo lo que ello implica. Se supone que todo ya está configurado y listo para funcionar.

Empecemos a transferir

Antes de comenzar la transferencia, definamos términos que le ayudarán a evitar confusiones:

KVM_NODE - Máquina anfitriona KVM
VZ_NODE - Máquina anfitriona OpenVZ
CTID - Contenedor OpenVZ
VM - Servidor virtual KVM

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

Paso 1

Como necesitamos mover el contenedor a algún lugar, crearemos VM con una configuración similar a KVM_NODE.
¡Importante! Debe crear una máquina virtual en el sistema operativo que se esté ejecutando actualmente en CTID. Por ejemplo, si en el CTID está instalado Ubuntu 14, entonces en la VM se debe instalar Ubuntu 14. Las versiones menores no son importantes y su discrepancia no es tan crítica, pero las versiones principales deberían ser las mismas.

Después de crear la VM, actualizaremos los paquetes en el CTID y en la VM (no debe confundirse con actualizar el sistema operativo; no lo actualizamos, solo actualizamos los paquetes y, si llega, la versión del sistema operativo dentro del directorio principal). versión).

Para CentOS, este proceso parece inofensivo:

# yum clean all
# yum update -y

Y no menos inofensivo para Ubuntu y Debian:

# apt-get update
# apt-get upgrade

Paso 2

Instalar en CTID, VZ_NODE и VM utilidad rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

No estamos instalando nada más ni allí ni allí.

Paso 3

hacemos una parada CTID en VZ_NODE el equipo

vzctl stop CTID

Montando la imagen CTID:

vzctl mount CTID

Vaya a la carpeta /vz/root/CTID y ejecutar

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

En la raíz, cree un archivo /root/exclude.txt; contendrá una lista de excepciones que no llegará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

Conectar a KVM_NODE y lanzar nuestro VMpara que funcione y sea accesible a través de la red.

Ahora todo está listo para la transferencia. ¡Ir!

Paso 4

Aún bajo el hechizo, realizamos

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 estén claras: la transferencia se realiza manteniendo los enlaces simbólicos, los derechos de acceso, los propietarios y los grupos, y el cifrado está deshabilitado para una mayor velocidad (podría usar algún cifrado más rápido, pero esto no es tan importante para esta tarea) y la compresión está desactivada.

Después de completar rsync, salga de chroot (presionando ctrl+d) y ejecute

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

Paso 5

Realicemos varios pasos que nos ayudarán a iniciar la VM después de la transferencia desde OpenVZ.
En servidores con Systemd ejecutemos un comando que nos ayudará a iniciar sesión en una consola normal, por ejemplo, a través de la pantalla de un servidor VNC

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

en servidores 6 CentOS и 7 CentOS Asegúrese de instalar un kernel nuevo:

yum install kernel-$(uname -r)

El servidor se puede cargar desde allí, pero después de la transferencia puede dejar de funcionar o eliminarse.

en el servidor 7 CentOS debe aplicar una pequeña solución para PolkitD; de lo contrario, el servidor fallará para siempre:

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

En todos los servidores, si se instaló mod_fcgid para Apache, realizaremos una pequeña corrección con los derechos; de lo contrario, los sitios que utilicen mod_fcgid fallarán con el error 500:

chmod +s `which suexec` && apachectl restart

Y lo último es útil para las distribuciones Ubuntu y Debian. Este sistema operativo puede fallar en un arranque eterno con un error

haciendo un bucle demasiado rápido. estrangulando un poco la ejecución

desagradable, pero se soluciona fácilmente, dependiendo de la versión del sistema operativo.

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

llevamos a cabo

dbus-uuidgen

si recibimos un error

/usr/local/lib/libdbus-1.so.3: versión `LIBDBUS_PRIVATE_1.10.8′ no encontrada

comprobar 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 <-- нужен этот
libdbus-1.so.3.14.16

si todo está en orden lo hacemos

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, pruebe la segunda opción.

La segunda solución al problema con estrangulando un poco la ejecución Apto para casi todas las distribuciones de Ubuntu y Debian.

realizamos

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

Y para Ubuntu 14, Debian 7 Adicionalmente realizamos:

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

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

¿Qué hemos hecho? Restauramos el bus de mensajes, que faltaba para ejecutar Debian/Ubuntu, y eliminamos module_dep, que provenía de OpenVZ e interfería con la carga de muchos módulos del kernel.

Paso 6

Reiniciamos la VM, comprobamos en VNC cómo va la carga y lo ideal es que todo cargue sin problemas. Aunque es posible que aparezcan algunos problemas específicos después de la migración, están fuera del alcance de este artículo y se corregirán a medida que surjan.

Espero que esta información sea útil! 🙂

Fuente: habr.com