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

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?

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.

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é:

• La página 211 de la Guía del administrador de Oracle Solaris ZFS (o la versión web aquí ) comienza a hablar sobre esto.

• También encontré una publicación de blog que daba un ejemplo simple de esto. Este blog también mostró cómo canalizar el flujo de bits a través de bzip2 y enviarlo.

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 .

¿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.

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.

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%)