Migrar servidor NFS (Linux)

Question

Contamos con un servidor NFS (Linux) que almacena archivos en una matriz de discos iSCSI. Este servidor está en producción. El servidor y la matriz son muy viejos y deben ser reemplazados pronto (la matriz ya tiene serios problemas).

Tengo el servidor y la matriz de reemplazo listos en una red diferente.

He estado pensando en sincronizar los recursos compartidos y luego hacerlo nuevamente para sincronizar los datos. No sé si eso podría causar inconsistencias en los datos... Dado que los recursos compartidos están montados sobre un lvm, ¿tal vez podría hacer una instantánea primero?

PREGUNTA:

¿Cuál es el mejor enfoque para migrar todos los datos? ¿Tienes algún consejo?

Answer 1

Su enfoque está bien si planea deshabilitar la escritura en la matriz antes del segundo rsync. Eso (debería) conducir a una copia limpia.

Dependiendo de las circunstancias, para minimizar el tiempo de inactividad, realice una sincronización triple:

1. rsync los sistemas de archivos mientras el servidor de origen se ejecuta tal cual. Esto llevará algún tiempo y le dará una copia preliminar, posiblemente con muchas inconsistencias.
2. (opcional) Si el punto 1 tarda mucho tiempo y tiene muchas escrituras mientras tanto, sincronícelo nuevamente con el servidor de origen aún ejecutándose tal como está. Este paso llevará menos tiempo y obtendrá una copia mucho mejor (se realizaron menos escrituras mientras se estaba ejecutando).
3. Deje de escribir en el nodo de origen. La mejor manera es montarlo como de solo lectura, como sugiere Stoned. Pero cerrar los servicios o utilizar el modo de usuario único también podría ser una buena opción.
4. rsync por última vez. Esta vez debería ser bastante rápido. No debería haber muchas inconsistencias (el paso 2 es mucho más corto que el 1), por lo que no hay mucho que sincronizar.
5. Haga sus comprobaciones e inicie el nuevo servidor en lugar del anterior.

Sin embargo, hay varias cosas a tener en cuenta:

• Si tiene muchos archivos pequeños (millones), cada rsync llevará algún tiempo de todos modos. (Lo mismo ocurre con las líneas lentas, los almacenamientos lentos/degradados, etc.)
• Si su almacenamiento de origen ya tiene problemas (unidades fallidas o cualquier otra cosa que pueda hacer que el volumen se vuelva ilegible), simplemente comience en el punto 3. Obtendrá un tiempo de inactividad prolongado, pero minimizará el riesgo de que falle a mitad de la transferencia.
• Se me ocurrió la loca idea de sincronizar todo el dispositivo, en el que reside el sistema de archivos. Lo cual podría funcionar si el objetivo es mayor que la fuente. Pero no lo recomiendo porque no lo he probado yo mismo.

Answer 2

Rsync+rsync o snapshot+rsync realmente no harán mucha diferencia; rsync tal vez sea más útil, ya que eventualmente podrá comprimir/cifrar datos durante la transferencia sin la molestia de tener que usar comandos adicionales. En ambos casos, siempre intentará ponerse al día con lo que sus usuarios podrían haber copiado en el recurso compartido desde la última rsync, incluido el archivo parcial que aún está en tránsito. Sinceramente lo que te recomendaría es hacer una primera copia con rsync en un periodo de poco uso. Luego, advierta a sus usuarios que habrá una pequeña interrupción debido al mantenimiento necesario. Detenga la escritura de servicios en el disco. Vuelva a montar el recurso compartido antiguo en modo de solo lectura, realice una sincronización final y luego reemplace completamente el recurso compartido nfs anterior por el nuevo. Si lo desea o puede, puede otorgar a los clientes acceso de solo lectura durante ese período. La disponibilidad del 100% es un puro sueño, y es mejor detener a sus clientes durante 1 hora que perseguir posibles quejas interminables sobre datos perdidos/corruptos y fallas de aplicaciones.