Tengo el siguiente problema: Tenemos un servidor de hardware dedicado (bare metal) (Debian 10) al que no tenemos acceso físico directo. Ahora quiero transferir todos los datos y aplicaciones que están en este servidor a una VM y ejecutarlos en un host KVM.
¿Por qué no instalo la aplicación directamente en la VM? La instalación de esta aplicación (cosas de Perl con el servidor web Apache, ejecutándose en el mismo servidor durante aproximadamente 10 años) es tan compleja que preferiría romper algo. Entonces nadie se atreve a hacerlo. Pero ahora tenemos que actuar y por esta razón necesitamos algún tipo de solución alternativa inteligente.
Pensé en apagar todos los servicios de Perl y Apache y transferir el disco duro a través ddde la red, pero el problema es que el host KVM de destino tiene menos espacio que el sdadel servidor bare metal (al final usa menos espacio que está disponible, sdaes simplemente de gran tamaño).
La segunda opción sería instalar los mismos paquetes en el KVM con exactamente los mismos números de versión (según dpkg --list), deshabilitar todos los servicios en el servidor básico (para mantener la coherencia de los datos) y poner /etc, /var/y /usrtodo lo demás que sea importante desde el servidor bare metal en un tarball y simplemente desempaquételo en el KVM. Por supuesto, también podría hacer esto mediante rsync, pero el principio es más o menos el mismo.
¿Qué opinas de la última idea?
¿Tienes alguna otra idea?
¿Cómo procederías con tal tarea?
Respuesta1
Comoansiedadme pidió que lo hiciera, responderé mi propia pregunta :) Mi solución no fue tan sofisticada yansiedad's, pero me gustaría compartirlo contigo de todos modos.
Lo que hice en realidad fue que primero verifiqué los tamaños de Inodo y Bloque en ambos sistemas de archivos para asegurarme de que sean idénticos entre sí (usando tune2fs).
Luego apagué todos los servicios, excepto los existenciales como SSHd.
Después de hacer eso, decidí usar apt-cloney no copiar los paquetes y binarios de una máquina a otra:
# on the physical machine:
apt-get install apt-clone
apt-clone clone packages
# on the virtual machine:
apt-get install apt-clone
apt-clone clone packages.apt-clone.tar.gz
# check on the VM:
vimdiff <(dpkg --list) physical_mchine_packages.txt
A continuación, sincronicé los datos usando rsync. Los directorios que sincronicé:
/root/etc(Excluí archivos comohostname,fstab,/default/gruby/network/interfacesmuchos otros directorios relacionados con kernel/initram/lvm)/usr(no todo, depende del software que utilices)/var(no todo, depende del software que utilices)
El último paso fue verificar si el nombre de host o la dirección IP de la máquina física anterior está incluido en algunos archivos de configuración:
find . ! \( -path "*proc*" -o -path "*sys*" -o -path "*var/mail*" -o -path "*var/spool/mqueue*" -o -path "*var/log*" \) -type f -exec grep -iH -- "x.x.x.x" {} \;
Eso es todo. Todo funciona en la VM ahora. Espero poder ayudar a alguien :)
Respuesta2
(Esta respuesta analiza lanivel de dispositivo de bloque(como alternativa, es más apropiado si desea mantener intactas las particiones y la configuración del administrador de arranque mientras migra a virtual)
El problema que usted describe no necesariamente ocurre en la práctica. Iaccidentalmenteevitó esto recientemente:
pero el problema es que el host KVM de destino tiene menos espacio que el sda del servidor básico
Es perfectamente válido crear, montar en bucle y editar particiones en unescasoarchivo que es (incluso sustancialmente) más grande que el sistema de archivos del host, siempre y cuando no haga nada escribiendo datos en las áreas omitidas del archivo.
Lo que hice fue aproximadamente fstrim / && systemctl stop appserver && mount -o remount,ro / && sync && dd bs=64k if=/dev/nvme0n1 | ssh vmhost dd bs=64k conv=sparse of=... Luego, en el host vm, losetuppuse la imagen a disposición fdisky resize2fscambié su tamaño (virtual). Dado que la imagen ya contenía solo ceros en la mayor parte de su extremo, mis operaciones en ella no aumentaron mucho su tamaño real.
El requisito de espacio en el peor de los casos para este enfoque tan simple sería 3 veces el contenido de datos del servidor anterior. Una vez para copiar la imagen dispersa, una vez para cambiar el tamaño (es decir, mover todo su contenido al principio sin perforar nuevos agujeros al final) y luego una vez más para convertir la imagen del disco sin formato al formato (o mover el archivo en ese momento). -imagen basada en su propio volumen lógico) utilizada por la administración de la máquina virtual.
Algunas cosas a tener en cuenta:
- La forma en que realiza esta operación debe depender del software/configuración de la virtualización planificada (por ejemplo, si su sistema actual arranca a través de EFI, pero su virtualización no lo prefiere, ¿cuál es el punto de hacer unacopia de disco¿Cuándo vas a tener que rehacer cosas relacionadas con el cargador de arranque de todos modos?)
- fstrim (especialmente cuando se combina con SSD o RAID defectuosos) puede ser peligroso a nivel de pérdida de datos. Si no está seguro de que sea una operación segura en su configuración, haga loescribir un archivo enorme que solo contiene bytes nulosalternativa: solo nos importa que las áreas no utilizadas sean detectables (puestas a cero), no si el disco lo reconoce.
- Simplemente colocando la raíz de solo lectura se hace el trabajo, pero se obtiene el resultado.como si el servidor fallara antes de reiniciarse en la máquina virtual. Si copia la imagen después de detener sus aplicaciones, esto podría sersuficientemente bueno: después de todo, usted espera que su servidor ya pueda continuar después de una falla.