ZFS Sync sobre WAN lenta y poco confiable. ¿Replicación de ZFS o rsync?

10

Me encargaron hacer que una copia de seguridad fuera del sitio funcione a través de la WAN. Ambas cajas de almacenamiento son cajas NAS basadas en FreeBSD que ejecutan ZFS.

Una o dos veces por semana, se envían de 15 a 60 gigas de datos de fotografía al NAS de la oficina. Mi trabajo es descubrir cómo obtener estos datos fuera del sitio de la manera más confiable posible utilizando la conexión DSL MUY LENTA (~ 700Kb / s de carga). La caja receptora está en una forma mucho mejor, a 30Mb / s hacia abajo, 5Mb / s hacia arriba.

Lo sé, llevar un disco duro fuera del sitio movería los datos mucho más rápido, pero no es una opción en este caso.

Mis opciones parecen ser:

  • Envío incremental de ZFS sobre ssh
  • Rsync

rsync es una solución tradicional y tiene la capacidad fundamental de reanudar un envío si algo se interrumpe. Tiene la desventaja de iterar sobre muchos archivos y no saber sobre dedup.

El envío de instantáneas de ZFS puede transferir un poco menos de datos (sabe mucho más sobre el sistema de archivos, puede deduplicar, puede empaquetar los cambios de metadatos de manera más eficiente que rsync) y tiene la ventaja de duplicar adecuadamente el estado del sistema de archivos, en lugar de simplemente copiar archivos individualmente (que es más intensivo en disco).

Me preocupa el rendimiento de replicación de ZFS [1] (aunque ese artículo tiene un año). También me preocupa poder reiniciar la transferencia si algo falla, la capacidad de la instantánea no parece incluir eso. Todo el sistema debe ser completamente independiente.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Usando cualquiera de las opciones, debería ser capaz de eliminar la prioridad del tráfico al enrutarlo a través de un puerto específico y luego usar la QOS en los enrutadores. Necesito evitar un impacto negativo importante en los usuarios de ambos sitios durante cada transferencia, ya que tomará varios días.

Entonces ... ese es mi pensamiento sobre el tema. ¿Me he perdido alguna buena opción? ¿Alguien más ha configurado algo similar?

Paul McMillan
fuente
Considera Unison .
sampablokuper

Respuestas:

8
  1. Si puede transferir un máximo de 6 GB por día (suponiendo cero sobrecarga y cero tráfico de la competencia) y necesita mover "15-60 conciertos" con una frecuencia de "una o dos veces por semana", eso equivale a 15-120 GB por semana, o de 2 a 17 GB por día. Debido a que es necesario planificar la demanda máxima, y ​​17 GB es mucho más que incluso su máximo teórico de 6 GB, es probable que tenga un problema de ancho de banda muy grave. ¿Qué se necesitará para actualizar la conexión? Si es imposible actualizar la conexión, considere la opción de enviar medios físicos por correo de forma programada (por ejemplo, semanalmente).

  2. Suponiendo que pueda obtener las matemáticas de ancho de banda para que tenga un poco más de sentido, es probable que rsync sea ​​la mejor opción. La conciencia de deduplicación sería enormemente valiosa al replicar datos altamente redundantes (por ejemplo, imágenes de máquinas virtuales), pero debería tener poco o ningún beneficio cuando se trata de contenido digital único (audio, video, fotos) ... a menos, por supuesto, que los usuarios sean almacenar inadvertidamente copias duplicadas de archivos idénticos.

Skyhawk
fuente
Me imagino que puedo usar el ancho de banda disponible, y la mayoría de los volcados de datos tienden hacia el extremo más pequeño del rango. Prácticamente, será alrededor de 2-3 conciertos por día en promedio, a juzgar por un mes pasado de datos. No necesito la replicación de inmediato.
Paul McMillan
Y sí, el envío de medios físicos es mucho mejor ... Ojalá fuera una opción.
Paul McMillan
Buen punto sobre dedup. La mayor parte de lo que se copia no se duplicará: los usuarios no son tan densos.
Paul McMillan
1
Lo único que agregaría es quizás no usar rsync. También experimenté la lentitud de rsync porque lo estaba usando como un proceso de transferencia, no como un proceso de sincronización. Luego me di cuenta de que la mayoría de mis datos existentes no cambiaron y que solo era necesario copiar nuevos datos, para mí, usé cp solo en los archivos nuevos y fue mucho más rápido. Si tuviera archivos que cambiaron (o solo partes de archivos), usaría rsync. Así que sugiero separar los archivos nuevos y elegir un método de transferencia reanudable. Además, la compresión sería una compensación de CPU y RAM / ancho de banda (en ambos extremos).
Scott McClenning
Hmm ... He leído que con la configuración adecuada, se puede hacer que rsync vaya relativamente rápido. ¿Cuánta optimización intentaste?
Paul McMillan
13

Después de investigar un poco, creo que tienes razón al enviar instantáneas. El ZFS SENDy los RECEIVEcomandos se pueden canalizar a bzip2 y luego ese archivo se puede sincronizar a la otra máquina.

Aquí hay algunas fuentes que utilicé:

No había encontrado ninguna publicación con scripts de replicación publicados, pero sí encontré a alguien que publicó su script de respaldo . Dicho esto, no lo entendí, así que puede ser basura.

Muchos de los sitios web hablaron sobre la configuración de un trabajo cron para hacer esto con frecuencia. Si este es el caso, podría replicar / respaldar con menos impacto en el ancho de banda y los usuarios y ser una buena característica de recuperación ante desastres porque los datos externos están más actualizados. (Es decir, después de la porción inicial de datos al comenzar).

Nuevamente, creo que tuvo la idea correcta de enviar instantáneas, parece que hay muchas ventajas al usar SEND/ RECEIVE.

EDITAR: Acabo de ver un video1 video2 que puede ayudar a apoyar el uso de SEND/ RECEIVEy habla sobre rsync (comienza a las 3m49s). Ben Rockwood fue el orador y aquí hay un enlace a su blog .

Scott McClenning
fuente
1
Supongo que el uso de rsync está limitado a la funcionalidad de pausa / reanudar, en lugar de diferenciar el archivo real. Esto tiene sentido, ya que el sistema de archivos en sí (y los archivos de cambio que genera) sabe mejor que rsync lo que está sucediendo.
Paul McMillan
Como nota adicional: ZSTD, un reemplazo moderno y más rápido para gzip y bzip, admite múltiples hilos y más de 20 niveles de compresión. También tiene una característica opcional contribuida llamada 'compresión adaptativa'. Con este modo, el nivel de compresión se ajusta automáticamente hacia arriba y hacia abajo según sea necesario para mantener la tubería de red llena, mientras se realiza la mayor compresión posible para ahorrar tiempo. Esto evita que haga tanta compresión que se convierta en un cuello de botella, o se pierda la compresión que podría estar haciendo porque la red es demasiado lenta.
Allan Jude
2

¿Cuál es el propósito de las copias de seguridad y cómo será necesario acceder a ellas?

Si sus copias de seguridad son principalmente para recuperación ante desastres, las instantáneas de ZFS pueden ser preferibles, ya que podrá recuperar un sistema de archivos al estado exacto en el momento del último incremento.

Sin embargo, si se supone que sus copias de seguridad también brindan a los usuarios acceso a archivos que podrían haberse eliminado, dañado, etc., accidentalmente, entonces rsync podría ser una mejor opción. Es posible que los usuarios finales no entiendan el concepto de instantáneas o que su NAS no proporcione a los usuarios finales acceso a instantáneas anteriores. En cualquier caso, puede usar rsync para proporcionar una copia de seguridad que sea fácilmente accesible para el usuario a través del sistema de archivos.

Con rsync puede usar el indicador --backup para preservar las copias de seguridad de los archivos que han sido modificados, y con el indicador --suffix puede controlar cómo se renombran las versiones antiguas de los archivos. Esto facilita la creación de una copia de seguridad donde podría haber fechado versiones antiguas de archivos como

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Puede combinar esto fácilmente con un cronjob que contiene un comando de búsqueda para purgar los archivos antiguos según sea necesario.

Ambas soluciones deberían poder conservar suficiente metainformación sobre los archivos para funcionar como una copia de seguridad (rsync proporciona indicadores --perms, --owner, etc.). Utilizo rsync para hacer copias de seguridad de grandes cantidades de datos entre centros de datos y estoy muy contento con la configuración.

Alemán
fuente
2

ZFS debería recibir la función 'envío reanudable', que permitirá continuar una replicación interrumpida en algún momento alrededor de marzo de este año. La función ha sido completada por Matt Ahrens y algunas otras personas, y debería actualizarse pronto.

Allan Jude
fuente
Solo una nota de que el 'envío reanudable' ha estado en OpenZFS (en FreeBSD, Linux, MacOS, etc.) desde hace bastante tiempo. Ahora también hay una función de "envío comprimido", donde los datos permanecerán comprimidos tal como están en el disco, como parte de la secuencia de replicación.
Allan Jude
0

Tal vez el dispositivo de compresión WAN sería una solución ...? usamos Riverbed y estamos muy contentos con ellos (por ejemplo, NetApp SnapMirror está muy bien comprimido, hasta 80-90%)

toffitomek
fuente