Migrar imagen de disco sin formato a través de LAN

8

Aquí está mi situación:

  • Dos servidores dedicados en el mismo centro de datos con ethernet gigabit entre ellos.
  • Ambos servidores dedicados arrancaron en un entorno de rescate basado en Debian Squeeze con herramientas y utilidades adicionales agregadas. También mucho espacio tmp (32 GB de RAM en ambas cajas) para descargar software, instalar paquetes y / o compilar según sea necesario.
  • Ambos servidores dedicados tienen aproximadamente 3 TB de espacio utilizable.
  • El servidor "fuente" tiene 4 discos de 1.5TB en Hardware RAID-10 con un controlador Adaptec de 4 puertos.
  • El servidor "destino" tiene 2 discos de 3TB en hardware RAID-1 con un controlador de puerto Adaptec 2, la misma generación que el otro, pero con un número diferente de puertos.
  • El número de bloques utilizables /dev/sdadifiere en menos de 10 MB, pero la matriz del servidor de destino es, por alguna razón, un poco más pequeña.
  • Ambas matrices RAID están configuradas para usar toda la superficie del disco de todos los discos constituyentes para crear un único volumen RAID.
  • El sistema operativo arranca en modo MBR; no se usa el arranque UEFI.

Lo que quiero hacer:

  • Copie, en la capa de bloques, toda la imagen del sistema operativo (esto solo consiste en el cargador de arranque GRUB2 en la tabla de partición GPT, / partición de arranque y / partición) desde el servidor "fuente" al servidor "destino".
  • Si es posible , la copia debe realizarse "en vivo": esto significa que no tengo suficiente espacio para almacenar un archivo adecuado de la imagen del disco en el lado de destino, a menos que esté desempacando la imagen del disco en el disco duro como copia que está teniendo lugar . La conexión de ethernet gigabit entre los servidores es lo suficientemente confiable como para que me sienta cómodo con esto y, por supuesto, ejecutaré fscken ambos extremos (origen y destino) para verificar que el sistema de archivos esté bien antes y después de la transferencia.
  • Si es posible , no transfiera bloques a través de la red, que no son utilizados por los sistemas de archivos constituyentes en cada partición (todas las particiones están formateadas como ext4). Esto se debe a que más del 50% del disco "fuente" es espacio libre en la /partición.
  • Ajuste el tamaño de la /partición para que, cuando se copie, se redimensione para ajustarse al tamaño apenas más pequeño del disco de destino.
  • Una vez que la copia se realiza correctamente, monte cada volumen y arregle las referencias a IP estáticas para reflejar las IP del nuevo servidor. (Puede hacer esto bien sin ninguna otra ayuda)

Mis preguntas:

  • ¿Debería calcular primero la diferencia (en bytes) entre el tamaño de /dev/sdacada servidor y luego usar e2resizepara reducir de forma no destructiva el tamaño de la /partición en el lado de origen para que se ajuste al espacio del lado de destino?
  • ¿Debo ejecutar dden el dispositivo de bloque sin formato, /dev/sdadesde el origen hasta el destino (finalizado ssh), o debería crear un diseño de partición equivalente en el destino y ejecutarlo dden cada partición ? Tenga en cuenta que el manejo de una partición a la vez me deja el problema del gestor de arranque, pero si no lo hago una partición a la vez, dddebe saber dejar de transferir datos una vez que ha escrito tantos bytes como puede contener el destino (que con suerte "cerrará" el final de la /partición en el último bloque, que está lógicamente "a la derecha de" todas las otras particiones en el diseño de la partición de la fuente).

Unos cuantos misceláneos. detalles específicos:

  • El sistema operativo host en el cuadro de origen es Ubuntu Server 12.04 que ejecuta varios invitados OpenVZ
  • Dado que ambos cuadros se inician en rescate, el acceso directo al disco es posible sin esperar ningún cambio en los datos subyacentes por parte del sistema operativo en ejecución.
allquixotic
fuente
¿Necesita exactamente copiar los bloques usados ​​de los dispositivos, o solo los sistemas de archivos del sistema operativo?
Andrew

Respuestas:

6

Esto es desordenado, pero factible.

Presumo aquí que /está encendido /dev/sda3y que /bootestá encendido /dev/sda1.

  1. Reduzca el sistema de archivos en el servidor anterior a su tamaño mínimo posible.

    oldserver # resize2fs -M /dev/sda3
    
  2. Particione el disco del nuevo servidor con un tamaño idéntico /boot, espacio de intercambio y una nueva /partición (y cualquier otra cosa que necesite).

    newserver # parted /dev/sda
    
  3. Copie los sistemas de archivos /y /boot.

    oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
    oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
    

    Debido a que la partición en el nuevo servidor será un poco más pequeña que la del servidor anterior, recibirá un No space left on devicemensaje espurio al final de este. Sin embargo, dado que redujo el sistema de archivos en el paso 1, esto no importa.

  4. Cambie el tamaño del sistema de archivos en el nuevo servidor al tamaño de la partición.

    newserver # resize2fs /dev/sda3
    
  5. Instale GRUB en el nuevo disco.

    newserver # mount /dev/sda3 /mnt
    newserver # mount /dev/sda1 /mnt/boot
    newserver # mount -o bind /dev /mnt/dev
    newserver # mount -o proc proc /mnt/proc
    newserver # chroot /mnt /bin/bash
    
    newserver(chroot) # grub-install /dev/sda
    newserver(chroot) # exit
    
  6. Termine el resto de sus reparaciones (dirección IP, etc.).

Probablemente pueda encontrar una manera de evitar copiar el espacio libre de la partición, pero probablemente le llevará más tiempo investigar que simplemente copiarlo todo ...

Michael Hampton
fuente
¡Increíble! Estoy de acuerdo con copiar el espacio libre de la partición porque estas instrucciones cumplen con todos mis otros criterios. Aunque, no sería simplemente cambiar el tamaño del sistema de archivos y la partición misma en oldservereliminar la necesidad de copiar todo el espacio libre? No me importa /bootporque es muy pequeño, pero /al menos podría hacerlo, ¿verdad? Simplemente configure el sector final de la partición para igualar a qué sector resize2fsestablece el final del sector FS. Bueno, sector, bloque ... probablemente bloque . Pero gracias por esto! ¡Esto es genial!
allquixotic
Sí, si también redujo el tamaño de la partición, evitaría muchas copias. Eso podría ahorrarte un par de horas ... Dejaría algo de holgura, solo en caso de que mis matemáticas no estuvieran bien.
Michael Hampton
Eso también eliminaría el espurio / aterrador "No queda espacio en el dispositivo", ya que se /dev/sda3reducirá a aproximadamente 1.3 TB y lo copiará en una partición en el destino que espera contener aproximadamente 2.9 TB.
allquixotic
Tomará un tiempo . Me di cuenta de que tengo un puerto gigabit con una asignación de 100 Mbit / s. Mierda.
allquixotic
5

Tenía mkfsnuevos sistemas de archivos en el nuevo servidor, luego rsynclos del servidor anterior. Eso es reiniciable, consistente y cada archivo es fácilmente verificable individualmente. Cuando descarta secciones no utilizadas del sistema de archivos (no una copia forense), no veo ninguna razón para no usar este método. Tendría que volver a ejecutar GRUB, pero eso no debería ser un desafío.

Explicar una copia en bruto que tenga en cuenta el sistema de archivos me llevaría un tiempo, por lo que, a menos que comente por qué mi solución rsync no funciona, me ahorraré el tipeo.

Jeff Ferland
fuente
Creo que partimagepuede hacer copias en bruto que son conscientes del sistema de archivos, pero no es compatible ext4. Entonces, eso es una opción ... rsyncse ve mejor como una opción, siempre que conserve todos los controles de acceso discrecionales (a la chmod) y pueda copiar limpiamente sobre enlaces simbólicos y archivos de dispositivo ...
allquixotic
Secundo la respuesta de Jeff. Puede transferir el diseño de la partición con sfdisk -d / dev / sda | destino ssh "sfdisk / dev / sdb". Cree sus sistemas de archivos y transfiéralos con 'rsync -a -e "ssh -c arcfour" / mnt / root @ destination: / mnt /'. A continuación, siga el paso 5 de la respuesta de Michael Hampton para hacer que el destino sea de arranque.
Tim Haegele
1

Si REALMENTE desea transferir datos a un nivel de dispositivo de bloque, puedo pensar en un truco bastante útil que estaba usando para migrar servidores con un tiempo de inactividad mínimo involucrado.

La cuestión es que puede crear un espejo degradado en el servidor de origen con su partición de datos como la única mitad activa del espejo, luego exportar la partición de destino desde el segundo servidor a través de AOE (supongo que ambos servidores están en el mismo dominio de transmisión). En el servidor de origen, luego conecta el dispositivo de bloqueo de red a su espejo degradado para que comience la reconstrucción. Espere hasta que se complete la reconstrucción, detenga su espejo, retire el dispositivo exportado AOE y estará bien.

Siguen un poco más de detalles (intentaré mantenerlo breve).

Componentes:

  • mdadmcon su modo de construcción (espejo ad-hoc sin metadatos);
  • vblade para exportar dispositivo de bloque como dispositivo de red AOE;
  • aoe-tools para importar un dispositivo de bloqueo de red AOE.

Debe crear una tabla de particiones en su servidor de destino, luego reducir la partición de origen para que se ajuste al destino. Puede instalar GRUB fácilmente en su nuevo MBR; sincronizar solo particiones sobre una tabla de particiones recién creada es un poco menos propenso a errores.

En el lado receptor, debe exportar su partición con la vbladeherramienta, en el servidor de origen puede ver los dispositivos exportados después de la instalación aoe-tools(ejecute aoe-discovery busque /dev/ether/dispositivos).

Luego, debe compilar el dispositivo raid1 en el servidor de origen con su unidad de origen :

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

Después de esto, puede examinar el espejo recién construido:

mdadm --detail /dev/md0
cat /proc/mdstat

En este punto, puede adjuntar de forma segura la partición de destino exportada a este espejo:

mdadm /dev/md0 --add /dev/ether/eX.Y

Luego solo vigila el progreso de la sincronización:

watch -n5 cat /proc/mdstat

Una vez realizada la sincronización, simplemente detenga el espejo: mdadm --stop /dev/md0en el servidor de origen, finalice el vbladeproceso en el servidor de destino, instale GRUB en el segundo servidor, cambie sus direcciones IP, etc.

En realidad, con este truco es posible mover el servidor entre cajas casi en vivo, con tiempo de inactividad solo para reiniciar cajas sincronizadas.


Por razones de rendimiento, también le sugiero que aumente la MTU de su enlace (o configure una VLAN separada con marcos jumbo habilitados, si es posible).

Tenga en cuenta que también puede usar algo como nbd-server/ nbd-client(o incluso iSCSI, si lo desea) como una alternativa a AOE, pero AOE ( vblade+ aoe-tools) tiene una interfaz muy simple y un gran rendimiento (sin sobrecarga de TCP / IP),

artyom
fuente
También agregaría que la sincronización a nivel de dispositivo de bloque a veces puede ser REALMENTE más rápida que ir de archivo en archivo con rsync, especialmente cuando tiene millones (literalmente) de archivos relativamente pequeños en el sistema de archivos.
artyom
mdadm? Estoy usando hardware RAID. Y no tengo idea de qué es AOE, y nunca he usado iSCSI. No creo que mis servidores estén en el mismo dominio de transmisión, solo en el mismo centro de datos. Hay al menos uno o dos conmutadores entre los servidores.
allquixotic
¡Creo que esta es una excelente idea! Pero, ¿cómo lidia con los diferentes tamaños de discos?
Tim Haegele
@allquixotic, sin embargo, puede probar el siguiente esquema reemplazando AOE con nbd (dispositivo de bloqueo de red, proporcionado por nbd-servery nbd-clientpaquetes). mdadmse usa solo para sincronizar dos dispositivos de bloque, no se escriben metadatos en buildmodo, por lo que puede usarlo encima de cualquier dispositivo de bloque (primero debe desmontarse). La cuestión es que, por lo general, configuro un sistema nuevo en un mdadm raid1 degradado, incluso si tengo un raid de hardware subyacente, de esta manera puedo aplicar la técnica descrita sin tener que desmontar las particiones, reduciendo el tiempo de inactividad de la migración al tiempo de reinicio único.
artyom