ProHoster > Bloc > Administració > Com transferir el contenidor OpenVZ 6 al servidor KVM sense maldecaps

Com transferir el contenidor OpenVZ 6 al servidor KVM sense maldecaps

Qualsevol persona que hagi necessitat transferir un contenidor OpenVZ a un servidor amb virtualització KVM completa almenys una vegada a la seva vida ha trobat alguns problemes:

  • La major part de la informació està simplement obsoleta i era rellevant per als sistemes operatius que havien passat durant molt de temps el cicle EOL
  • Sempre es proporciona informació diferent per a diferents sistemes operatius i mai es tenen en compte els possibles errors durant la migració
  • De vegades heu de fer front a configuracions que de tant en tant no volen funcionar després de la migració

Quan transferiu 1 servidor, sempre podeu arreglar alguna cosa sobre la marxa, però quan transferiu un clúster sencer?

En aquest article intentaré explicar-vos com migrar correctament un contenidor OpenVZ a KVM amb un temps d'inactivitat mínim i una solució ràpida a tots els problemes.

Un petit programa educatiu: què és OpenVZ i què és KVM?

No aprofundirem en la terminologia, sinó que direm en termes generals:

OpenVZ — virtualització a nivell de sistema operatiu, fins i tot podeu implementar-la en un microones, ja que no calen instruccions de CPU ni tecnologies de virtualització a la màquina host.

KVM - Virtualització en tota regla, utilitzant tota la potència de la CPU i capaç de virtualitzar qualsevol cosa, de qualsevol manera, tallant-la longitudinalment i transversalment.

Contràriament a la creença popular que entre els proveïdors d'allotjament OpenVZ es sobrevendrà, però KVM no ho farà, afortunadament per a aquest últim, ara KVM no està en sobrevenda pitjor que el seu germà.

Què ens portarem?

Com a subjectes de prova per a la transferència, vam haver d'utilitzar tot el bosc de sistemes operatius que hi ha disponibles a OpenVZ: CentOS (versions 6 i 7), Ubuntu (14, 16 i 18 LTS), Debian 7.

Es va suposar que la majoria dels contenidors OpenVZ ja estaven executant algun tipus de LAMP, i alguns fins i tot tenien algun programari molt específic. Molt sovint, es tractava de configuracions amb l'ISPmanager, el tauler de control de VestaCP (i sovint, no s'actualitzaven durant anys). També s'han de tenir en compte les seves peticions de trasllat.

La migració es realitza conservant l'adreça IP del contenidor transferit; assumirem que la IP que tenia el contenidor està desada a la VM i funcionarà sense problemes.

Abans de transferir, assegurem-nos que ho tenim tot a mà:

  • Servidor OpenVZ, accés complet a l'arrel a la màquina host, possibilitat d'aturar/muntar/iniciar/suprimir contenidors
  • Servidor KVM, accés root complet a la màquina host, amb tot el que implica. Se suposa que tot ja està configurat i llest per funcionar.

Comencem a transferir

Abans de començar la transferència, definim termes que us ajudaran a evitar confusions:

KVM_NODE - Màquina host KVM
VZ_NODE - Màquina host OpenVZ
CTID - Contenidor OpenVZ
VM - Servidor virtual KVM

Preparació per a la migració i creació de màquines virtuals.

Pas 1

Com que hem de moure el contenidor a algun lloc, crearem VM amb una configuració semblant a KVM_NODE.
¡Important! Heu de crear una màquina virtual al sistema operatiu que s'està executant actualment a CTID. Per exemple, si Ubuntu 14 està instal·lat al CTID, llavors Ubuntu 14 s'ha d'instal·lar a la VM. Les versions menors no són importants i la seva discrepància no és tan crítica, però les versions principals haurien de ser les mateixes.

Després de crear la VM, actualitzarem els paquets al CTID i a la VM (no s'ha de confondre amb l'actualització del SO: no l'actualitzem, només actualitzem els paquets i, si arriba, la versió del SO dins de la versió).

Per a CentOS, aquest procés sembla inofensiu:

# yum clean all
# yum update -y

I no menys inofensiu per a Ubuntu i Debian:

# apt-get update
# apt-get upgrade

Pas 2

Instal·la a CTID, VZ_NODE и VM utilitat rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

No instal·lem res més ni allà ni allà.

Pas 3

Fem una parada CTID en VZ_NODE equip

vzctl stop CTID

Muntatge de la imatge CTID:

vzctl mount CTID

Aneu a la carpeta /vz/root/CTID i executar

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

Sota l'arrel, creeu un fitxer /root/exclude.txt: contindrà una llista d'excepcions que no arribaran al nou 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

Ens connectem a KVM_NODE i llançar el nostre VMperquè funcioni i sigui accessible a través de la xarxa.

Ara tot està preparat per a la transferència. Va!

Pas 4

Encara sota l'encanteri, actuem

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

L'ordre rsync realitzarà la transferència, esperem que les claus estiguin clares: la transferència es porta a terme amb la preservació d'enllaços simbòlics, drets d'accés, propietaris i grups, i el xifratge està desactivat per a una major velocitat (podeu utilitzar un xifrat més ràpid, però això no és tan important per a aquesta tasca), així com la compressió està desactivada.

Després de completar rsync, sortiu de chroot (prement ctrl+d) i executeu

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

Pas 5

Realitzem diversos passos que ens ajudaran a llançar la VM després de transferir-nos des de l'OpenVZ.
En servidors amb Systemd executem una ordre que ens ajudarà a iniciar sessió en una consola normal, per exemple, a través d'una pantalla de servidor VNC

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

Als servidors CentOS 6 и CentOS 7 Assegureu-vos d'instal·lar un nucli nou:

yum install kernel-$(uname -r)

El servidor es pot carregar des d'ell, però després de la transferència pot deixar de funcionar o esborrar.

Al servidor CentOS 7 heu d'aplicar una petita correcció per a PolkitD, en cas contrari, el servidor es bloquejarà per 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 tots els servidors, si s'ha instal·lat mod_fcgid per a Apache, realitzarem una petita correcció amb drets, en cas contrari, els llocs que utilitzen mod_fcgid es bloquejaran amb l'error 500:

chmod +s `which suexec` && apachectl restart

I l'últim és útil per a les distribucions Ubuntu i Debian. Aquest sistema operatiu pot estavellar-se en una arrencada eterna amb un error

bucle massa ràpid. limitant una mica l'execució

desagradable, però fàcil de solucionar, depenent de la versió del sistema operatiu.

En Debian 9 la correcció es veu així:

duem a terme

dbus-uuidgen

si tenim un error

/usr/local/lib/libdbus-1.so.3: no s'ha trobat la versió `LIBDBUS_PRIVATE_1.10.8'

comproveu la presència 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 tot està en ordre, ho fem

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 ajuda, proveu la segona opció.

La segona solució al problema amb limitant una mica l'execució Apte per a gairebé totes les distribucions Ubuntu i Debian.

Realitzem

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

I per a Ubuntu 14, Debian 7 A més realitzem:

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

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

Què hem fet? Vam restaurar messagebus, que faltava per executar Debian/Ubuntu, i vam eliminar modules_dep, que venia d'OpenVZ i interferia amb la càrrega de molts mòduls del nucli.

Pas 6

Reiniciem la VM, comprovem a VNC com avança la càrrega i, idealment, tot es carregarà sense problemes. Tot i que és possible que després de la migració apareguin alguns problemes concrets, queden fora de l'abast d'aquest article i es corregiran a mesura que sorgeixin.

Espero que aquesta informació sigui útil! 🙂

Font: www.habr.com

Afegeix comentari