¿Mover un volumen lógico directamente de un servidor a otro a través de la red?

Tengo una máquina host KVM con varias máquinas virtuales. Cada máquina virtual utiliza un volumen lógico en el host. Necesito copiar los LV a otra máquina host.

Normalmente, usaría algo como:

dd if=/the/logical-volume of=/some/path/machine.dd

Para convertir el LV en un archivo de imagen y usar SCP para moverlo. Luego use DD para copiar el archivo nuevamente a un nuevo LV en el nuevo host.

El problema con este método es que necesita el doble de espacio en disco que la VM ocupa en ambas máquinas. es decir. un LV de 5GB usa 5GB de espacio para el LV y la copia dd también usa 5GB de espacio adicional para la imagen. Esto está bien para LV pequeños, pero ¿qué pasa si (como es mi caso) tienes un LV de 500 GB para una VM grande? La nueva máquina host tiene un disco duro de 1TB, por lo que no puede contener un archivo de imagen dd de 500GB y tiene un volumen lógico de 500GB para copiar y tiene espacio para el sistema operativo host y espacio para otros huéspedes más pequeños.

Lo que me gustaría hacer es algo como:

dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv

En otras palabras, copie los datos directamente de un volumen lógico a otro a través de la red y omita el archivo de imagen intermedio.

es posible?

Claro, por supuesto que es posible.

dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv

Auge.

Sin embargo, hazte un favor y usa algo más grande que el tamaño de bloque predeterminado. Quizás agregue bs = 4M (lectura / escritura en fragmentos de 4 MB). Puedes ver que hay algunos detalles sobre los tamaños de bloque en los comentarios; Si esto es algo que te encuentras haciendo con bastante frecuencia, tómate un poco de tiempo para probarlo varias veces con diferentes tamaños de bloques y comprueba por ti mismo qué te ofrece las mejores tasas de transferencia.

Respondiendo una de las preguntas de los comentarios:

Puede canalizar la transferencia a través de pv para obtener estadísticas sobre la transferencia. Es mucho mejor que la salida que obtienes al enviar señales dd.

También diré que, aunque, por supuesto, usar netcat, o cualquier otra cosa que no imponga la sobrecarga del cifrado, será más eficiente, generalmente encuentro que la velocidad adicional tiene cierta pérdida de comodidad. A menos que me mueva por conjuntos de datos realmente grandes, generalmente me quedo con ssh a pesar de la sobrecarga porque en la mayoría de los casos todo ya está configurado para Just Work.

Aquí hay una versión optimizada, que muestra el progreso usando pvy usa BS para fragmentos más grandes y también usa gzippara reducir el tráfico de red.

Eso es perfecto cuando se mueven los datos entre conexiones lentas como servidores de Internet. Recomiendo ejecutar el comando dentro de una sesión de pantalla o tmux. De esa manera, la conexión ssh al host desde donde ejecuta el comando se puede desconectar sin problemas.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh [email protected] 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'

¿Qué tal si usas un viejo amigo para hacer esto? NetCat.

En el sistema que está perdiendo el tipo de volumen lógico

• $ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]

Luego en el sistema receptor. tipo

• $ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]

Traduciendo, orgin box dd este archivo y canalizarlo a nc (netcat) que escuchará de este puerto. En el sistema receptor, netcat esperará 10 segundos si no obtiene datos antes de cerrar a [ip o nombre] en [puerto] y luego canalizará esos datos a dd para escribirlos.

Primero tomaría una foto del lv:

lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>

Después de eso, debe crear un nuevo lv en el nuevo host (por ejemplo, usando lvcreate) con el mismo tamaño. Luego puede copiar directamente los datos al nuevo host. Aquí está mi ejemplo del comando copiar:

dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_host -C 'dd of=/dev/vg1/<created lv> bs=4096'

Utilicé el procedimiento para copiar una VM mantenida proxmox pve a otro host. El volumen lógico contenía varios LV adicionales que la propia VM mantenía.

Primero asegúrese de que el volumen lógico no esté montado. Si es así y desea hacer una "copia en caliente", cree primero una instantánea y úsela en su lugar: lvcreate --snapshot --name transfer_snap --size 1G

Tengo que transferir una gran cantidad de datos (7 TB) entre dos servidores conectados de 1 Gbit, por lo que necesitaba la forma más rápida posible de hacerlo.

¿Deberías usar SSH?

El uso de ssh está fuera de discusión, no por su encriptación (si tiene una CPU con soporte AES-NI, no duele tanto) sino por sus buffers de red. Esos no están escalando bien. Hay una versión de Ssh parcheada que soluciona este problema, pero como no hay paquetes precompilados, no es muy conveniente.

Usando Compresión

Al transferir imágenes de disco sin formato, siempre es recomendable usar compresión. Pero no desea que la compresión se convierta en un cuello de botella. La mayoría de las herramientas de compresión de Unix, como gzip, son de un solo subproceso, por lo que si la compresión satura una CPU, será un cuello de botella. Por esa razón, siempre uso pigz, una variante de gzip que usa todos los núcleos de CPU para la compresión. Y esto es necesario si desea subir y superar las velocidades de GBit.

Usando cifrado

Como se dijo antes, ssh es lento. Si tiene una CPU AES-NI, esto no debería ser un cuello de botella. Entonces, en lugar de usar ssh, podemos usar openssl directamente.

Velocidades

Para darle una idea del impacto de la velocidad de los componentes, aquí están mis resultados. Esas son las velocidades de transferencia entre dos sistemas de producción que leen y escriben en la memoria. ¡Sus resultados reales dependen de la velocidad de la red, la velocidad del disco duro y la velocidad de la CPU de origen! Estoy haciendo esto para mostrar que al menos no hay una gran caída en el rendimiento. Simple nc dd: 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s +pigz compression level 1 (speed gain depends on actual data): network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s +pigz compression level 5: network traffic: 2.43GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s +compression level 1 + openssl encryption: network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s Conclusión: el uso de la compresión proporciona una aceleración notable, ya que reduce mucho el tamaño de los datos. Esto es aún más importante si tiene velocidades de red más lentas. Cuando use la compresión, observe el uso de su CPU. si el uso se maximiza, puedes intentarlo sin él. Usar la compresión como solo un pequeño impacto en los sistemas AES-NI, en mi opinión solo porque roba entre un 30 y un 40% de CPU de la compresión.

Usando la pantalla

Si está transfiriendo una gran cantidad de datos como yo, no desea que se interrumpa por una desconexión de la red de su cliente ssh, por lo que es mejor comenzar con la pantalla en ambos lados. Esto es solo una nota, no escribiré un tutorial en pantalla aquí.

Permite copiar

Instale algunas dependencias (en origen y destino): apt install pigz pv netcat-openbsd

luego cree un volumen en el destino con el mismo tamaño que la fuente. Si no está seguro, use lvdisplay en la fuente para obtener el tamaño y crear el objetivo, es decir: lvcreate -n lvname vgname -L 50G

a continuación, prepare el destino para recibir los datos:

nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname

y cuando esté listo, comience la transferencia en la Fuente:

pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1

Nota: Si está transfiriendo los datos localmente o no le importa el cifrado, simplemente quite la parte Openssl de ambos lados. Si le importa, asdkjn2hb es la clave de cifrado, debe cambiarla.