ZFS发送/接收的最佳压缩

我通过点对点的T1线路发送增量式ZFS快照,我们希望在下一次备份开始之前,一天的快照几乎不能通过networking。 我们的send / recv命令是:

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

我有足够的CPU周期来备用。 有没有更好的压缩algorithm或替代方法,我可以用来推送更less的数据在线?

这听起来像你已经尝试了所有最好的压缩机制,并仍然受到线速度的限制。 假设运行更快的线路是不可能的,你是否考虑过less运行备份,以便有更多的时间运行?

简而言之,是否有某种方法来降低正在写入的数据量? 不知道你的应用程序堆栈很难说如何,但只是做一些事情,如确保应用程序覆盖现有的文件,而不是创build新的可能会有所帮助。 并确保你没有保存你不需要的临时/caching文件的备份。

这是我所学到的,正在做同样的事情。 我build议使用mbuffer。 在我的环境中进行testing时,它只能在接收端得到帮助,如果没有这个function,发送速度就会减慢,而接收端就会收到。

一些例子: http : //everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

主页有选项和语法http://www.maier-komor.de/mbuffer.html

从我的复制脚本发送命令:zfs send -i tank / pool @ oldsnap tank / pool @ newsnap | ssh -c arcfour remotehostip“mbuffer -s 128k -m 1G | zfs receive -F tank / pool”

这将在远程主机上运行mbuffer作为接收缓冲区,以便发送尽可能快。 我运行一个20mbit的线,发现发送端的mbuffer也没有帮助,而且我的主要的zfs盒子使用了所有的ram作为caching,所以即使是1g到mbuffer也需要我减less一些caching大小。

另外,这不是我真正的专业领域,我认为最好是让ssh进行压缩。 在你的例子中,我认为你使用的是bzip,然后使用默认使用压缩的ssh。 所以SSH正试图压缩一个压缩的stream。 我最终使用arcfour作为密码,因为它是最小的cpu密集,这对我很重要。 你可能有更好的结果与另一个密码,但我肯定会build议让SSH做压缩(或closuresssh压缩,如果你真的想使用它不支持的东西)

真正有趣的是,在localhost上发送和接收时使用mbuffer也可以加快速度:zfs send tank / pool @ snapshot | mbuffer -s 128k -m 4G -o – | zfs接收-F tank2 / pool

我发现本地主机传输4g似乎是我的甜点。 它只是表明zfs发送/接收并不真正喜欢延迟或任何其他暂停在stream中最好的工作。

只是我的经验,希望这有助于。 我花了一段时间才弄明白这一切。

这是你的具体问题的答案:

您可以尝试使用rzip ,但是它的工作方式与compress / bzip / gzip有些不同:

rzip希望能够读取整个文件,所以它不能在pipe道中运行。 这将大大增加您的本地存储需求,您将无法运行备份并通过一根pipe道的线路发送备份。 也就是说,所得到的文件,至less根据这个testing,是相当小的。

如果你的资源约束是你的pipe道,那么你将会无论如何全天候运行备份,所以你需要不断地复制快照,并希望你保持不变。

你的新命令是:

 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 

你会想要更好的纠错,你会想考虑使用像rsync的东西来传输压缩的文件,所以如果传输失败的中间,你可以拿起你离开的地方。

我假设你根本不能增加你的网站的原始带宽…

您可能会看到不在主机上使用压缩的好处。

如果你使用了像优化器这样的东西,那么如果你在发送文件之前没有压缩文件的话,它将能够更好地优化传输,也就是说,你只是在做你正在做的事情,但是从pipe道中删除bzip2。 经过一段时间的备份后,wan优化器将caching大部分在传输中看到的内容,并且您将看到传输速度的巨大提升。

如果您处于有限的预算范围内, 可以使用rsync和rsyncing 解压缩的快照来看到类似的改进,即:

 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' 

这会更快,因为rsync只会传输昨天快照和今天之间的差异。 根据快照过程的工作原理,即使两者不是完全相同的文件,两者之间仍然会有很多冗余。

万优化器是解决这个问题的更可能的方式(好吧,以太网是解决这个问题的可能的方法,但是我们将把它从表中解决)。 在写入光纤或河床安装的大检查之前,rsync只是在黑暗中进行testing(本地; rsync会告诉你在本地数据上节省了多less时间)。

物有所值。 我不会直接发送| 压缩| 解压缩| 如果接收方收到此消息,可能会导致传输线路故障,并且在接收期间池会长时间处于脱机状态。 我们发送到本地文件然后gzip快照和传输使用rsync(与河床),然后我们从文件接收。 河床没有优化交通,但是如果交通出现问题,需要重新启动,河床加速重新启动。

我们考虑过不使用Rsync压缩来压缩增量快照,也不使用河床以外的压缩。 很难说什么是最好的,但是当我们使用rsync压缩从oracle传输归档日志时,传输速率大约是普通文件和河床(RSync)的两倍。

如果你有一个河床,那么使用rsync而不是ssh,因为河床了解rsync,并会尝试优化它,并将数据添加到caching(见上面,重新启动传输)。

我的经验是,尽pipe比以下压缩步骤快得多(平均), zfs send仍然非常突然。 我的备份在zfs send之后插入了相当多的缓冲区,在gzip之后更多:

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

在我的情况下,输出设备是USB(不是networking)连接,但缓冲也很重要,原因相似:当USB驱动器保持100%忙时,整体备份时间更快。 你可能不会发送更less的字节(按你的要求),但你仍然可以更快完成。 缓冲保持CPU绑定的压缩步骤不受IO限制。

通过WAN发送时,我一直使用pbzip2 (并行bzip2)。 由于它是线程化的,你可以指定与-p选项一起使用的线程数。 首先在发送和接收主机上安装pbzip2,安装说明在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" 

主要关键是要频繁地创build快照(~10分钟),以使您的快照尺寸更小,然后发送每个快照。 ssh不会从一个损坏的快照stream中恢复,所以如果你有一个巨大的快照发送,pipestream到pbzip2,然后拆分成可pipe理的大小的块,然后rsync拆分文件到接收主机,然后pipe到zfs recv连接的pbzip2文件。

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

这将产生以500MB块命名的文件:

 /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到多次接收主机(甚至可以在zfs发送完成之前rsync,或者一旦你看到一个完整的500MB块),按ctrl + c随时取消:

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

zfs接收:

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

用户freind提到:什么是值得的。 我不会直接发送| 压缩| 解压缩| 如果接收方收到此消息,可能会导致传输线路故障,并且在接收期间池会长时间处于脱机状态。 – 如果正在进行的发送/接收被networking丢弃中断,但是没有超出池的范围,我在接收主机中遇到了以前的zfs版本<28的问题。 那很有意思。 只有在接收端退出“zfs recv”时才重新发送快照。 如果需要,手动杀死“zfs recv”。 现在在FreeBSD或Linux中zfs send / recv已经有了很大改进。

你可以select一个更快的密码ssh,也许blowfish-cbc,也可以尝试-123456789开关

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

“最好的”压缩algorithm取决于你有什么types的数据 – 如果你推MP3收集压缩可能会减缓进程,而文本/日志文件可以显着压缩与gzip -9

你每天要推送多less数据?

你将需要testing你的数据。 只要将它发送到一个文件,并用每种方法压缩它。

对我们来说,gzip做出了巨大的改变,我们通过这一切来运行所有的东西,但gzip和bzip或7z之间甚至没有1%的差异。

如果你使用的是较慢的T1,则需要将其存储到一个文件中,并将其同步到rsync上。

对于那些受限于CPU而不是带宽的人(不是你)来说,就像lstvan所说的那样,arcfour128这种不同的encryption技术可以加快速度。 我们在内部移动时使用它。

尝试打开与-D发送的zfs的重复数据删除。 当然,节省取决于您的数据有多less重复。

你有没有考虑调整你的TCP / IP协议栈,这样你的TCP缓冲区和窗口大小有点大? 您可以在Solaris上使用此ndd工具或Linux / BSD / Mac OSX上的sysctl工具。 在Solaris上,您正在查找/dev/tcp tcp_max_buf/dev/tcp tcp_cwnd_max值,而在Linux sysctl上,您正在寻找net.ipv4.tcp_memnet.ipv4.tcp_rmemnet.ipv4.tcp.wmem值。

另外,这些链接可能还有一些额外的帮助:

Solaris TCP性能调整

这个页面底部有一组链接,它将解释如何为Linux / BSD / OSX做同样的事情。