Como transferir o contenedor OpenVZ 6 ao servidor KVM sen dores de cabeza

Calquera persoa que necesitase transferir un contedor OpenVZ a un servidor con virtualización KVM completa polo menos unha vez na súa vida atopou algúns problemas:

• A maior parte da información está simplemente desactualizada e era relevante para os sistemas operativos que pasaran moito tempo o ciclo EOL
• Sempre se proporciona información diferente para diferentes sistemas operativos e nunca se consideran posibles erros durante a migración
• Ás veces tes que tratar con configuracións que de cando en vez non queren funcionar despois da migración

Cando transfire 1 servidor, sempre pode arranxar algo sobre a marcha, pero cando transfire un clúster enteiro?

Neste artigo intentarei dicirche como migrar correctamente un contedor OpenVZ a KVM cun tempo de inactividade mínimo e unha solución rápida a todos os problemas.

Un pequeno programa educativo: que é OpenVZ e que é KVM?

Non afondaremos na terminoloxía, senón que diremos en termos xerais:

OpenVZ — virtualización a nivel de sistema operativo, incluso pode implementala nun microondas, xa que non hai necesidade de instrucións da CPU e tecnoloxías de virtualización na máquina host.

KVM - Virtualización total, utilizando toda a potencia da CPU e capaz de virtualizar calquera cousa, de calquera forma, cortándoa lonxitudinalmente e transversalmente.

Ao contrario da crenza popular de que entre os provedores de hospedaxe, OpenVZ se sobrevenderá, pero KVM non, afortunadamente para este último, agora KVM non está peor que o seu irmán.

Que levaremos?

Como suxeitos de proba para a transferencia, tivemos que utilizar todo o bosque de sistemas operativos que están dispoñibles en OpenVZ: CentOS (versións 6 e 7), Ubuntu (14, 16 e 18 LTS), Debian 7.

Supoñíase que a maioría dos contedores OpenVZ xa estaban executando algún tipo de LAMP, e algúns incluso tiñan algún software moi específico. Na maioría das veces, estas eran configuracións co ISPmanager, o panel de control de VestaCP (e a maioría das veces, non se actualizaron durante anos). Tamén hai que ter en conta as súas solicitudes de traslado.

A migración realízase conservando o enderezo IP do contedor transferido; asumiremos que a IP que tiña o contenedor está gardada na máquina virtual e funcionará sen problemas.

Antes de transferir, asegúrese de que temos todo a man:

• Servidor OpenVZ, acceso root completo á máquina host, capacidade de deter/montar/iniciar/eliminar contedores
• Servidor KVM, acceso root completo á máquina host, con todo o que iso implica. Suponse que xa está todo configurado e listo para funcionar.

Imos comezar a transferir

Antes de comezar a transferencia, imos definir os termos que che axudarán a evitar confusións:

KVM_NODE - Máquina host KVM
VZ_NODE - Máquina host OpenVZ
CTID - Contedor OpenVZ
VM - Servidor virtual KVM

Preparación para a migración e creación de máquinas virtuais.

Paso 1

Xa que necesitamos mover o contedor a algún lugar, imos crear VM cunha configuración similar á KVM_NODE.
Importante! Debe crear unha máquina virtual no sistema operativo que se está a executar actualmente en CTID. Por exemplo, se Ubuntu 14 está instalado no CTID, entón debe instalarse Ubuntu 14 na máquina virtual. As versións menores non son importantes e a súa discrepancia non é tan crítica, pero as versións principais deberían ser as mesmas.

Despois de crear a VM, actualizaremos os paquetes no CTID e na VM (non debe confundirse coa actualización do SO: non o actualizamos, só actualizamos os paquetes e, se chega, a versión do SO dentro do sistema principal). versión).

Para CentOS, este proceso parece inofensivo:

# yum clean all
# yum update -y

E non menos inofensivo para Ubuntu e Debian:

# apt-get update
# apt-get upgrade

Paso 2

Instalar en CTID, VZ_NODE и VM utilidade rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Non estamos instalando nada máis nin alí nin alí.

Paso 3

Facemos unha parada CTID en VZ_NODE o equipo

vzctl stop CTID

Montaxe da imaxe CTID:

vzctl mount CTID

Vaia ao cartafol /vz/root/CTID e executar

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

Baixo a raíz, crea un ficheiro /root/exclude.txt: conterá unha lista de excepcións que non chegarán ao novo 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 e lanzar o noso VMpara que funcione e sexa accesible a través da rede.

Agora todo está listo para a transferencia. Vaia!

Paso 4

Aínda baixo o feitizo, actuamos

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

O comando rsync realizará a transferencia, esperamos que as claves estean claras: a transferencia realízase coa conservación de ligazóns simbólicas, dereitos de acceso, propietarios e grupos, e o cifrado está desactivado para unha maior velocidade (podería usar algún cifrado máis rápido, pero isto non é tan importante para esta tarefa) , así como a compresión está desactivada.

Despois de completar rsync, saia de chroot (premendo ctrl+d) e executa

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

Paso 5

Imos realizar varios pasos que nos axudarán a lanzar a máquina virtual despois de transferir desde OpenVZ.
En servidores con Systemd imos executar un comando que nos axudará a iniciar sesión nunha consola normal, por exemplo, a través dunha pantalla de servidor VNC

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

Nos servidores CentOS 6 и CentOS 7 Asegúrese de instalar un núcleo novo:

yum install kernel-$(uname -r)

O servidor pódese cargar desde el, pero despois da transferencia pode deixar de funcionar ou eliminarse.

No servidor CentOS 7 cómpre aplicar unha pequena corrección para PolkitD, se non, o servidor fallará para sempre:

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 os servidores, se se instalou mod_fcgid para Apache, realizaremos unha pequena corrección con dereitos, se non, os sitios que usan mod_fcgid fallarán co erro 500:

chmod +s `which suexec` && apachectl restart

E o último é útil para as distribucións Ubuntu e Debian. Este sistema operativo pode fallar nun arranque eterno cun erro

bucle demasiado rápido. estrangulando un pouco a execución

desagradable, pero facilmente solucionable, dependendo da versión do SO.

En Debian 9 a corrección é así:

levamos a cabo

dbus-uuidgen

se recibimos un erro

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

comprobar a presenza 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

se todo está en orde, facémolo

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

Se non axuda, proba a segunda opción.

A segunda solución ao problema con estrangulando un pouco a execución Adecuado para case todas as distribucións de Ubuntu e Debian.

Realizamos

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

E para Ubuntu 14, Debian 7 Ademais realizamos:

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

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

Que fixemos? Restauramos messagebus, que faltaba para executar Debian/Ubuntu, e eliminamos modules_dep, que viña de OpenVZ e interfería coa carga de moitos módulos do núcleo.

Paso 6

Reiniciamos a VM, comprobamos en VNC como avanza a carga e, idealmente, todo se cargará sen problemas. Aínda que é posible que aparezan algúns problemas específicos despois da migración, están fóra do alcance deste artigo e iranse corrixindo a medida que xurdan.

Espero que esta información sexa útil! 🙂

Fonte: www.habr.com