La mejor compresión para ZFS enviar / recibir

Estoy enviando instantáneas incrementales de ZFS a través de una línea T1 punto a punto y estamos en un punto donde el valor de un día de instantáneas apenas puede pasar por el cable antes de que comience la próxima copia de seguridad. Nuestro comando enviar / recv es:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

Tengo muchos ciclos de CPU de sobra. ¿Existe un mejor algoritmo de compresión o un método alternativo que pueda usar para enviar menos datos a la línea?

Parece que ha probado todos los mejores mecanismos de compresión y todavía está limitado por la velocidad de la línea. Suponiendo que ejecutar una línea más rápida está fuera de discusión, ¿ha considerado simplemente ejecutar las copias de seguridad con menos frecuencia para que tengan más tiempo para ejecutarse?

Aparte de eso, ¿hay algún tipo de forma de reducir la cantidad de datos que se escriben? Sin conocer la pila de su aplicación, es difícil decir cómo, pero hacer cosas como asegurarse de que las aplicaciones sobrescriban los archivos existentes en lugar de crear archivos nuevos podría ayudar. Y asegurándose de no guardar las copias de seguridad de los archivos temporales / de caché que no necesitará.

Esto es lo que aprendí haciendo exactamente lo mismo que tú. Sugiero usar mbuffer. Al realizar pruebas en mi entorno, solo ayudó en el extremo receptor, sin nada en absoluto, el envío se ralentizaría mientras el receptor se ponía al día.

Algunos ejemplos: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Página de inicio con opciones y sintaxis http://www.maier-komor.de/mbuffer.html

El comando enviar de mi script de replicación:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

esto ejecuta mbuffer en el host remoto como un búfer de recepción para que el envío se ejecute lo más rápido posible. Ejecuté una línea de 20mbit y descubrí que tener mbuffer en el lado de envío tampoco ayudó, también mi caja zfs principal está usando todo su ram como caché, por lo que dar incluso 1g a mbuffer requeriría que reduzca algunos tamaños de caché.

Además, y esta no es realmente mi área de especialización, creo que es mejor dejar que ssh haga la compresión. En su ejemplo, creo que está usando bzip y luego usa ssh, que por defecto usa compresión, por lo que SSH está tratando de comprimir una secuencia comprimida. Terminé usando arcfour como cifrado, ya que es el que menos CPU consume y eso fue importante para mí. Es posible que tenga mejores resultados con otro cifrado, pero definitivamente sugeriría dejar que SSH haga la compresión (o desactive la compresión ssh si realmente desea usar algo que no admite).

Lo que es realmente interesante es que usar mbuffer al enviar y recibir en localhost también acelera las cosas:

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

Descubrí que 4g para transferencias localeshost parece ser el punto dulce para mí. Simplemente muestra que zfs enviar / recibir realmente no le gusta la latencia o cualquier otra pausa en la transmisión para que funcione mejor.

Solo mi experiencia, espero que esto ayude. Me tomó un tiempo entender todo esto.

Esta es una respuesta a su pregunta específica:

Puede probar rzip , pero funciona de maneras que son un poco diferentes de comprimir / bzip / gzip:

rzip espera poder leer todo el archivo, por lo que no se puede ejecutar en una tubería. Esto aumentará en gran medida sus requisitos de almacenamiento local y no podrá ejecutar una copia de seguridad y enviar la copia de seguridad a través del cable en una sola tubería. Dicho esto, los archivos resultantes, al menos según esta prueba, son bastante más pequeños.

Si su restricción de recursos es su canalización, estará ejecutando copias de seguridad las 24 horas del día, los 7 días de la semana, de todos modos, por lo que solo tendrá que copiar instantáneas constantemente y esperar que continúe de todos modos.

Su nuevo comando sería:

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

Deberá poner una mejor corrección de errores y considerar usar algo como rsync para transferir los archivos comprimidos, de modo que si la transferencia falla en el medio, puede continuar donde lo dejó.

Las cosas han cambiado en los años posteriores a la publicación de esta pregunta:

1: ZFS ahora admite la replicación comprimida, solo agregue el indicador -c al comando de envío zfs y bloquea lo que se comprimió en el disco permanecerá comprimido a medida que pasan a través de la tubería hacia el otro extremo. Todavía puede haber más compresión, ya que la compresión predeterminada en ZFS es lz4

2: El mejor compresor para usar en este caso es zstd (ZStandard), ahora tiene un modo 'adaptativo' que cambiará el nivel de compresión (entre los más de 19 niveles admitidos, más los nuevos niveles zstd-fast de mayor velocidad) basados ​​en la velocidad del enlace entre zfs send y zfs recv. Comprime tanto como puede mientras mantiene la cola de datos esperando para salir al mínimo. Si su enlace es rápido, no perderá tiempo comprimiendo más los datos, y si su enlace es lento, seguirá trabajando para comprimir más los datos y ahorrarle tiempo al final. También admite compresión roscada, por lo que puedo aprovechar múltiples núcleos, que gzip y bzip no, fuera de las versiones especiales como pigzip.

Supongo que simplemente no puede aumentar el ancho de banda bruto de su sitio ...

Es posible que vea beneficios al no utilizar la compresión en el host.

Si usa algo como un optimizador wan, podrá optimizar la transferencia mucho mejor si no comprime el archivo antes de enviarlo, es decir, hace exactamente lo que está haciendo pero elimina el bzip2 de la tubería. Después de un par de ejecuciones de su copia de seguridad, el optimizador wan habrá almacenado en caché una fracción muy grande de las cosas que ve en la transferencia y verá grandes mejoras en las velocidades de transferencia.

Si tiene un presupuesto limitado, puede ver una mejora similar al usar rsync y rsyncing de la instantánea sin comprimir , es decir:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

Esto sería más rápido porque rsync solo transferiría las diferencias entre la instantánea de ayer y la de hoy. Dependiendo de cómo funcione el proceso de instantáneas, puede haber mucha redundancia entre los dos, incluso si no son realmente el mismo archivo.

El optimizador wan es, con mucho, una forma más probable de solucionar este problema (bueno, metro ethernet es la forma más probable de resolver este problema, pero lo dejaremos fuera de la mesa). El rsync es solo un disparo salvaje en la oscuridad que vale la pena probar (localmente; rsync le dirá cuánto tiempo ahorró en una copia directa) en sus datos locales antes de escribir el cheque grande para fibra o una instalación de cauce de río.

Por lo que vale. No haría un envío directo | comprimir | descomprimir | recibir esto puede ocasionar problemas en el extremo receptor si la línea de transferencia se rompe y sus grupos estarán desconectados durante mucho tiempo durante la recepción. Enviamos a un archivo local, luego comprimimos la instantánea y la transferimos usando rsync (con riverbed), luego recibimos del archivo. El lecho del río no optimiza el tráfico PERO si hay un problema con la transferencia y necesita reiniciarse, el lecho del río acelera el reenvío.

Hemos visto no comprimir la instantánea incremental, usar la compresión Rsync y no usar ninguna compresión que no sea el cauce del río. Es difícil decir cuál es el mejor, pero cuando estamos transfiriendo registros de archivos de Oracle con compresión rsync, la velocidad de transferencia es aproximadamente el doble que la de los archivos sin formato y el lecho del río (con RSync).

Si tiene un cauce fluvial, use rsync no ssh ya que el cauce del río entiende rsync e intentará optimizarlo y agregará los datos a la memoria caché (ver arriba, reiniciar las transferencias).

Mi experiencia es zfs sendbastante explosiva a pesar de ser mucho más rápida (en promedio) que el siguiente paso de compresión. Mi copia de seguridad inserta un búfer considerable después zfs sendy más después gzip:

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

En mi caso, el dispositivo de salida está conectado a USB (no a la red), pero el almacenamiento en búfer es importante por una razón similar: el tiempo de respaldo general es más rápido cuando la unidad USB se mantiene 100% ocupada. Es posible que no envíe menos bytes en general (según lo solicite), pero aún puede terminar antes. El almacenamiento en búfer evita que el paso de compresión vinculado a la CPU se convierta en un enlace IO.

Uso pbzip2 todo el tiempo (paralelo bzip2) cuando envío WAN. Como está enhebrado, puede especificar el número de subprocesos que se usarán con la opción -p. Instale pbzip2 primero en los hosts de envío y recepción, las instrucciones de instalación están en http://compression.ca/pbzip2/ .

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

La clave principal es crear instantáneas a intervalos frecuentes (~ 10 minutos) para reducir el tamaño de la instantánea y luego enviar cada instantánea. ssh no se reanudará desde una secuencia de instantánea rota, por lo que si tiene una gran instantánea para enviar, canalice la secuencia a pbzip2, luego divídala en trozos de tamaño manejable, luego rsync divida los archivos en el host receptor, luego canalice a zfs recv los archivos pbzip2 concatenados.

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

esto producirá archivos nombrados en fragmentos de 500 MB:

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

rsync para recibir el host varias veces (puede rsync incluso antes de que se complete el envío de zfs o tan pronto como vea un fragmento completo de 500MB), presione ctrl + c en cualquier momento para cancelar:

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs recibe:

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

Usuario amigo mencionado: Por lo que vale. No haría un envío directo | comprimir | descomprimir | recibir esto puede ocasionar problemas en el extremo receptor si la línea de transferencia se rompe y sus grupos estarán desconectados durante mucho tiempo durante la recepción. - He encontrado problemas antes con versiones anteriores de zfs <28 en el host receptor si un envío / recv en curso se ve interrumpido por caídas de la red, pero no en la medida en que los grupos están desconectados. Eso es interesante. Vuelva a enviar la instantánea solo si "zfs recv" ha salido en el extremo receptor. Mata el "zfs recv" manualmente si es necesario. zfs send / recv se ha mejorado mucho ahora en FreeBSD o Linux.

Puede elegir un cifrado más rápido para ssh quizás blowfish-cbc, también pruebe los interruptores -123456789

-1 (or --fast) to -9 (or -best)

Tendrá que probar con sus datos. Simplemente envíelo a un archivo y comprímalo con cada método.

Para nosotros, gzip hizo una gran diferencia y corremos todo a través de eso, pero ni siquiera hubo una diferencia del 1% entre gzip y bzip o 7z.

Si está en un T1 lento, necesitará almacenarlo en un archivo y sincronizarlo nuevamente.

Para aquellos (no usted) que están limitados un poco más por la CPU que el ancho de banda, como lstvan dijo que un cifrado diferente como arcfour128 acelera las cosas. Usamos eso internamente cuando movemos las cosas.

Experimente con activar dedup para zfs enviar con -D. El ahorro depende de cuánta duplicación haya en sus datos, por supuesto.

El "mejor" algoritmo de compresión depende del tipo de datos que tenga: si está presionando una compresión de colección de MP3, probablemente disminuirá la velocidad del proceso, mientras que los archivos de texto / log pueden comprimirse significativamente gzip -9.

¿Cuántos datos estás empujando cada día?

¿Ha considerado ajustar su pila TCP / IP para que su búfer TCP y los tamaños de ventana sean un poco más grandes? puede usar la nddherramienta en Solaris para esto o la sysctlherramienta en Linux / BSD / Mac OSX. En Solaris está buscando el /dev/tcp tcp_max_bufy /dev/tcp tcp_cwnd_maxvalores, y en sysctl Linux, que está buscando net.ipv4.tcp_mem, net.ipv4.tcp_rmemy net.ipv4.tcp.wmemvalores.

Además, estos enlaces pueden ser de alguna ayuda adicional:

Ajuste de rendimiento TCP de Solaris

Hay un conjunto de enlaces en la parte inferior de esa página que explicará cómo hacer lo mismo para Linux / BSD / OSX también.