Este post es muy interesante, relacionado con respaldos con rsync, manejo de máquinas virtuales, paquetes de Linux, manejo de la red.
En este post vemos una breve introducción a OpenVZ y KVM para entrar de lleno al proceso de migración de un sistema de virtualización al otro.
OpenVZ es un sistema de virtualización de Sistema Operativo muy popular, similar a LXC que permite a un sistema operativo Linux correr múltiples instancias a las cuales popularmente se les conoce como VPS.
Este tipo de virtualización basada en sistema operativo tiene la característica de que todas las máquinas virtuales que en ella corren, lo hacen usando el mismo único kernel que el hospedero tiene.
Tiene algunas desventajas, entre ellas que, ante un fallo en el kernel, todas las VPS se verían afectadas y que si un cliente necesita una versión diferente del kernel esto no será posible.
Ahora, tiene cosas buenas como el hecho de que es más rápido el funcionamiento del kernel ya que todas usan el mismo kernel y además que la memoria que no usa un VPS será aprovechada por otro VPS.
¿Por qué migrar desde OpenVZ?
Ocurren ocasiones en que es necesario migrar una VPS en OpenVZ hacia un sistema con full virtualización; por ejemplo porque se necesita utilizar las características de aislamiento típicas de un sistema full virtualizado como KVM, por ejemplo porque se requiere un kernel específico.
O porque nuestro proveedor de VPS va a dejar de ofrecernos el servicio,
Otra razón, la más común, es que necesitamos un manejo más certero de recursos como RAM, necesitamos que la RAM que adquirimos para nuestra VPS nos esté garantizada para nuestra máquina virtual, esto debido a que muchos proveedores de OpenVZ hacen lo que se llama “overselling” que es ofrecer a los clientes recursos que no se tienen realmente. Por ejemplo, tienen un servidor con 128GB de RAM y venden a sus clientes 10 máquinas virtuales de 24GB cada una. Si multiplicamos 10*24G=240G, que es mucho mayor que los 128GB que tienen. Esto es posible ya que OpenVZ permite utilizar la memoria que un cliente no usa, puede que un ciente de sus 24GB de RAM “comprados”, realmente use 8GB, y el resto lo tenga libre y solamente lo use en picos en ciertas horas del día. Esto permite al proveedor aprovechar esos 16GB para que en el mismo servidor corran otras máquinas de otros clientes.
Esto usualmente no causa problemas ya que usualmente no todas las máquinas usan toda la memoria todo el tiempo, es posible que una máquina use toda la memoria ahora, pero dentro de 5 minutos ya use solamente el 20% de esta, y entonces otra máquina comience a usar toda la RAM pero luego de 15 minutos ya use solamente el 15%. Como podemos ver, se tiene la esperanza de que la memoria se pueda ir compartiendo: una vez se usa para un grupo de clientes, pero luego para otro, etc.
El problema radica en que si en un determinado momento varios clientes, por diversas razones, comienzan a utilizar toda la memoria que reservaron, el servidor se quedará sin memoria. Existen técnicas como el uso de la SWAP, pero eventualmente se agota además de ser lenta.
Debe tenerse mucho cuidado con los proveedores de VPS ya que muchos, en el afán de ganar dinero, sobrevenden bastante agresivamente sus servidores. Siempre es saludable pensar que si un VPS es muy muy barato para las características que ofrecen, es síntoma de que se está sobrevendiendo agresivamente (mucho).
Lo contrario ocurre con proveedores que ofrecen virtualización completa (full virtualization) basada en KVM, Xen, VMWare. Los sistemas de full virtualización sí permiten la sobreventa de ciertos recursos (usando KSM para la RAM por ejemplo). Pero típicamente cuando vemos nombres como KVM, Xen o VMWare, esto significa que los recursos que vamos a contratar estarán disponibles para nuestra VM.
¿Qué problema tenemos al migrar desde OpenVZ?
El problema principal al migrar desde OpenVZ es que sus VPS no tienen el paquete “kernel” instalado entonces, aunque logremos convertir su disco duro (que está en formato ploop) hacia, digamos, qcow2, este no arrancará en nuestro KVM pues no existe un kernel para arrancar.
Esto no es un defecto, es una característica de OpenVZ, recordemos que las VPS no contienen un kernel propio sino que usan el kernel del hospedero. Pero las máquinas virtuales full virtualizadas sí necesitan tener su kernel cada una.
Procedimiento para migrar
El procedimiento en sentido general es bien sencillo, pero lleva una serie de pasos que debemos seguir con mucho cuidado.
Digamos que tenemos una VPS en OpenVZ que por comodidad llamaré “Servidor anterior” y tendremos una VM en KVM hacia la que queremos migrar el servidor anterior. A esta VM le llamaré “Servidor nuevo”. Anota esto en algún ugar.
Los siguientes pasos en algunos casos pueden ser realizados en diferente orden, o de forma paralela. Pero bueno, sigamos en esta orden:
Servidor anterior:
- Ahorra espacio, borra todo lo que puedas borrar para agilitar la transferencia. Mientras más contenidos tengas, más tiempo demorará la transferencia.
- Si es posible, disminuye el tamaño de los logs:
journalctl --vacuum-size=10M- Actualiza el sistema operativo y reinicia la máquina para validar que todo funcione luego de actualizar. Es importante actualizar ya que es muy útil que ambos servidores, el anterior y el nuevo, estén en la misma versión, y la forma de garantizar esto es que ambos estén actualizados.
- Es importante reinciar ya que no queremos culpar a la migración por algo que falla desde antes. Ocurre que hay ocasiones en que luego de reiniciar no arranca algún servicio y es porque no estaba activado por defecto. En fin, es importante estar seguros que el servidor anterior funciona correctamente!
yum -y update && yum clean all && reboot- Anotemos la versión de Linux que corremos, pues esa misma versión debemos instalar en el nuevo servidor.
cat /etc/centos-release
AlmaLinux release 8.9 (Midnight Oncilla)En este caso, es un AlmaLinux versión 8.
El release (.9) lo logramos en ambos servidores haciendo yum update. Es importante manteer la misma versión y release ya que ahorraremos tiempo al copiar archivos y a que algunos archivos que no existen en el servidor viejo (el kernel por ejemplo) los tendremos en el nuevo, todo con la misma misma versión.
Servidor nuevo:
- Instalaremos la misma versión que en el server viejo. En mi ejemplo será AlmaLinux 8.
- Instalo el paquete rsync. Este es el comando que usaremos para sincronizar por lo que debe existir en ambos servidores:
yum -y install rsync- Una vez instalado, le procedo a actualizar, con esto le llevaré al mismo release del servidor viejo que ya teníamos actualizado.
cat /etc/redhat-release; yum -y update && reboot
AlmaLinux release 8.9 (Midnight Oncilla)Como podemos ver, tenemos la misma versión y release (8.9) que el servidor anterior. He reiniciado para estar seguro que el servidor arranca con el nuevo kernel, y que arranca correctamente.
Una vez más, reiniciamos para diferenciar si un futuro problema que tengamos con el reinicio, sea por la copia de los archivos y no de la actualización.
Copiamos los contenidos del archivo de configuración de red.
cat /etc/syscofig/network-scripts/ifcfg-eth0En mi caso mi archivo se llama ifcfg-eth0, en tu caso puede variar. Es importante anotar los contenidos de la configuración de la red ya que al sincronizar los archivos en el siguiente paso, el rsync borrará los archivos que no existan en el servidor viejo, y este es uno de ellos.
Servidor viejo:
Regresamos ahora al servidor viejo, vamos a copiar los contenidos del viejo al nuevo. Vamos a instalar rsync, apagar mysqld; o mariadb, o postgresql, el que tengas.
Apagaremos el servidor de mysql para que no queden transacciones inconsistentes. Al finalizar la transferencia le volvemos a encender. Aquí ves la importancia de haber borrado cualquier archivo o contenido que ya no uses, como te mencioné al inicio, esto es para que la transferencia no demore mucho ya que la BD estará apagada durante todo este tiempo.
yum -y install rsync
systemctl stop mysqld (o mariadb, o postgresql)
rsync --exclude=/etc/fstab --exclude=/boot --exclude=/proc --exclude=/lib/modules/ --exclude=/etc/udev --exclude=/lib/udev --exclude=/sys -e ssh --delete --numeric-ids -avpogtStlHz / root@IPDELSERVERNUEVO:/
systemctl start mysqldEste proceso tomará tanto tiempo como contenidos tengas que transferir del servidor viejo a la IP del servidor nuevo. Y de la velocidad de la red. Puede tomar algunos minutos, o algunas horas, toca esperar.
Tip!
Hay ocasiones en que no queremos tener la BD apagada tanto tiempo, esto es lo que yo hago!:
- Sincronizo con rsync, sin apagar la BD
- Cuando la sincronía acabe, luego de varios minutos, horas o días: apago la BD en ambos servidores, viejo y nuevo, y vuelvo a sincronizar.
- Como ya los contenidos estaban previamente sincronizados, el rsync solamente sincronizará los archivos que hayan cambiado, que serán infinitamente menos que la sincronía inicia.
Servidor nuevo:
Ya estamos finalizando! Ahora vamos a hacer unas tareas finales, que son las más importantes:
Borramos la configuracion de red del openvz ya que no nos sirve en el servidor nuevo. Y copiemos la configuraciónde ifcfg-eth0 que guardamos en los pasos anteriores. Al hacer rsync, este archivo fue borrado ya que no existe en el origen:
cd /etc/sysconfig/networ-scripts
rm ifcfg-venet*
vi ifcfg-eth0 (aqui copio los contenidos que guardé antes)Reiniciamos el servidor nuevo para ver que arranque correctamente:
rebootA mi siempre me arranca correctamente. La red me funciona, todo ok.
Procedo como paso final a instalar el paquete kernel. Este último paso es confuso para algunas personas porque, cómo es posible que el sistema ya arranque si no tiene el paquete kernel?
Lo que sucede es que el archivo del kernel sí existe, está, existe gracias a que instalamos la máquina nueva virtual con la misma versión y release. Estos archivos no fueron borrados porque al hacer rsync hicimos dos exclude importantes: el exclude de /boot y el exclude en /lib/modules que es donde se guardan el kernel y sus módulos.
El problema radica en que la BD de rpm /var/lib/rpm sí fue sobreescrita cuando se hizo el rsync, y recuerden que el viejo sistema no contiene el paquete kernel ya que OpenVZ no necesita este paquete. Es por eso que tenemos el kernel instalado, pero no tenemos el paquete en la BD.
Si no hacemos este último paso, el sistema funcionará maravillosamente, pero a la hora de actualizar los paquetes, al no existir evidencia en la BD de paquetes del kernel, no lo actualizará posiblemente. Por esto hagamos:
yum install kernelY para validar que nada haya cambiado, reiniciamos:
rebootResumen
Como podemos ver, el proceso es bastante sencillo, he tomado mi tiempo en describirlo completamente para que se comprenda el por qué de cada paso, pero si nos fijamos bien, son pocos pasos, quizá unos 15.
