Hola,
Estoy utilizando un script que hace uso de rsync para mover entre 1-2 millones de ficheros entre 2 máquinas, dividido en 2 fases:
1) Una primera ejecución para migrar el grueso de los datos, se copiarán los 1-2 millones de ficheros y se asume que el proceso durará entre 3-4 horas aprox.
2) Segunda ejecución del script, donde se sincronizaran las diferencias desde la primera ejecución.
El problema de este escenario es que rsync se tira entre 15 y 20 minutos construyendo el listado de ficheros a sincronizar (proceso "building file list"), un tiempo que me gustaría reducir al máximo posible al menos en la fase 2) del script, la del 1) no me importa :)
El motivo es que desde que lanzo el primer rsync hasta que se lanza el segundo, apenas se han modificado/creado/borrado 1000-2000 ficheros y es
¿Conoceís alguna alternativa a rsync para este escenario? Algo que haga uso de FAM, inotify, kqueue, etc. para determinar de "forma inteligente" aquellos ficheros a sincronizar en lugar de tener que volver a generar nuevamente el listado?
Saludos,
- Una primera ejecución para migrar el grueso de los datos, se copiarán
los 1-2 millones de ficheros y se asume que el proceso durará entre 3-4 horas aprox.
- Segunda ejecución del script, donde se sincronizaran las diferencias
desde la primera ejecución.
El problema de este escenario es que rsync se tira entre 15 y 20 minutos construyendo el listado de ficheros a sincronizar (proceso "building file list"), un tiempo que me gustaría reducir al máximo posible al menos en la fase 2) del script, la del 1) no me importa :)
El motivo es que desde que lanzo el primer rsync hasta que se lanza el segundo, apenas se han modificado/creado/borrado 1000-2000 ficheros y es
Hola Santi
técnicamente la primera ejecución SÍ de demorará pero la segunda ya debe ser muy rápida.
Tenemos un caso de un cliente que tiene unos 50millones de archivos (es un servidor de mail con maildiry se les ocurrió tener un respaldo al lado con esto). y no demora más de 5 min sincronizar esos 50millones de archivos (por supuesto los cambios son mínimos).
Ahora, otra variante sería que uses drbd quizá con ocfs2 o con gfs2 en activo-activo.. o como creas más conveniente!.
saludos! epe
El 04/05/10 19:58, "Ing. Ernesto Pérez Estévez" escribió:
El problema de este escenario es que rsync se tira entre 15 y 20 minutos construyendo el listado de ficheros a sincronizar (proceso "building file list"), un tiempo que me gustaría reducir al máximo posible
(..)
Hola Santi
técnicamente la primera ejecución SÍ de demorará pero la segunda ya debe ser muy rápida.
Hola Ernesto!
En todas las ejecuciones el tiempo necesario para construir el listado de ficheros a sincronizar es prácticamente el mismo, unos 15-20 minutos aprox; Lógicamente la primera ejecución debe mover el grueso de los datos = varias horas, en la segunda pasada de rsync se moverán muy pocos datos y será mucho más rápido = tiempo prácticamente despreciable.
Pero en ambos casos, el tiempo necesario para construir el listado de ficheros es el mismo. Por eso comento que, lo interesante para este tipo de escenarios es hacer uso de FAM, inotify, kqueue, etc. para tener un listado de la información que ha cambiado entre las 2 ejecuciones de rsyncs, evitando realizar el calculo con todos los ficheros, esto es lo realmente interesante :)
Ahora, otra variante sería que uses drbd quizá con ocfs2 o con gfs2 en activo-activo.. o como creas más conveniente!.
Cualquier solución NAS, SAN o DRBD como comentas queda descartada: lo estamos utilizando para migrar virtuales basados en OpenVZ entre 2 cabinas diferentes; además el contenido a migrar no se corresponde con una partición completa, volumen, etc. tan solo es parte de la estructura de un directorio (por eso las soluciones que comentas están descartadas).
He podido "rascar" algunos minutos a dicho proceso compilando la última versión de rsync (v3.0.7), cambiando el cifrado de SSH por uno mas ligero -blowfish- (se hace rsync sobre SSH, por si no lo había comentado) y quitando las opciones de verbose, estadísticas, etc.. del propio rsync; En cualquier caso, sigue siendo necesario cerca de ~15 mins para generar el listado :-(
Voy a echarle un ojo a la alternativa Unison, aunque estoy casi seguro que pecará de lo mismo.. al final tendré que jugar con las opciones de suspender/reanudar de la virtualización + inotify :)
En cualquier caso, cualquier sugerencia será muy bien recibida, gracias!
Saludos,
2010/5/6 Santi Saez santisaez@woop.es:
El 04/05/10 19:58, "Ing. Ernesto Pérez Estévez" escribió:
El problema de este escenario es que rsync se tira entre 15 y 20 minutos construyendo el listado de ficheros a sincronizar (proceso "building file list"), un tiempo que me gustaría reducir al máximo posible
La demora es la misma, con y sin compresión?
En todas las ejecuciones el tiempo necesario para construir el listado de ficheros a sincronizar es prácticamente el mismo, unos 15-20 minutos aprox; Lógicamente la primera ejecución debe mover el grueso de los datos = varias horas, en la segunda pasada de rsync se moverán muy pocos datos y será mucho más rápido = tiempo prácticamente despreciable.
Pero en ambos casos, el tiempo necesario para construir el listado de ficheros es el mismo. Por eso comento que, lo interesante para este tipo de escenarios es hacer uso de FAM, inotify, kqueue, etc. para tener un listado de la información que ha cambiado entre las 2 ejecuciones de rsyncs, evitando realizar el calculo con todos los ficheros, esto es lo realmente interesante :)
No me queda claro exactamente por qué quieres reducir este tiempo, calculo que es porque tienes el sistema detenido mientras haces la copia, por razones de consistencia. Si es así, vale enmascarar el problema en lugar de solucionarlo? Me refiero a si puedes tomar un snapshot con LVM y transferir tus archivos desde allí. El sistema podría seguir funcionando mientras tanto.
El 06/05/10 13:41, Eduardo Grosclaude escribió:
Hola Eduardo!
El 04/05/10 19:58, "Ing. Ernesto Pérez Estévez" escribió:
El problema de este escenario es que rsync se tira entre 15 y 20 minutos construyendo el listado de ficheros a sincronizar (proceso "building file list"), un tiempo que me gustaría reducir al máximo posible
La demora es la misma, con y sin compresión?
No he hecho pruebas con la compresión de rsync, aunque entiendo que eso afecataría a la transferencia de los datos y no a la parte de generar el listado de ficheros a sincronizar:
-z, --compress compress file data during the transfer
No me queda claro exactamente por qué quieres reducir este tiempo, calculo que es porque tienes el sistema detenido mientras haces la copia, por razones de consistencia. Si es así, vale enmascarar el problema en lugar de solucionarlo? Me refiero a si puedes tomar un snapshot con LVM y transferir tus archivos desde allí. El sistema podría seguir funcionando mientras tanto.
Exacto, se debe reducir ese tiempo al mínimo ya que supone corte de servicios, como decía, se trata de un script que se encarga de migrar virtuales basados en OpenVZ entre hosts que estén conectados a 2 almacenamientos diferentes; Los tiros van por algo como los snapshots de LVM como comentas, aunque en este escenario tampoco es aplicable :(
Googleando he dado con un post en Server Fault [1], donde se hace referencia a lsyncd [2] y sersync[3] -entre otros- que hacen uso de inotify + rsync para sincronizar únicamente aquellos ficheros que han sido modificados, tendré que echarles un ojo :)
Saludos,
[1] http://tinyurl.com/35z6ev3 [2] http://code.google.com/p/lsyncd/ [3] http://code.google.com/p/sersync/
-
"Ing. Ernesto Pérez Estévez" -
Eduardo Grosclaude -
Santi Saez