rsync.net: ZFS到云的复制终于来了——而且它是快

8月中旬，第一个商业可用的ZFS云复制目标在rsync.net上可用。谁在乎呢，对吧?正如服务本身所述，“如果你不确定这意味着什么，我们的产品不适合你。”

当然，这个产品是为某些人准备的——对那些潜在的用户来说，这是真的将的事。充分欣赏新事物rsync.net(剧透:这是相当令人印象深刻的!)意味着首先要掌握基本的数据传输技术。虽然ZFS复制技术在今天蓬勃发展，但实际上必须从研究ZFS正在慢慢取代的技术开始。

与rsync的爱情

重温任何一种初恋都是一场浪漫的回忆之旅，这就是重温rsync-就像在“rsync.net”-对我来说。很难写一篇文章，最终不可避免地抛弃这个工具，因为我已经疯狂地爱上它超过15年了。Andrew Tridgell(因Samba而闻名)在1996年6月首次公开宣布了rsync。三年后，他在他的博士论文中使用了三章，大约在我发现并开始热情地使用它的时候。无论如何，我专业参与主要开源工具的最早记录——至少是我发现的——是我在21世纪初rsync邮件列表上的活动．

Rsync是一个将文件夹和/或文件从一个位置同步到另一个位置的工具。坚持真正的Unix设计理念，这是一个简单的使用的工具。没有GUI，没有向导，您可以使用它来完成最基本的任务，而不受其界面的阻碍。但在我的经验中，rsync在任何工具中都很少见，它也非常优雅。它使得一项任务是人类直观的似乎尽管客观上很复杂，但很简单。通常情况下，rsync是这样的:

root@test:~# rsync -ha——progress /source/folder /target/

调用此命令将确保一旦结束，将有一个/目标/文件夹，它将包含与原始文件相同的所有文件源/文件夹包含。简单,是吧?因为我们调用了论证——一个(对于存档)，同步将是递归的，所涉及的文件和文件夹的时间戳、所有权、权限和所有其他属性将在目标中保持不变，就像它们在源上一样。因为我们调用了- h，我们将得到人类可读的单位(如G、M和K，而不是原始字节)。进步意味着我们将得到一个漂亮的每个文件进度条，显示传输的速度。

到目前为止，这只是一个不错的拷贝版本。但有趣的是时间/目标/文件夹已经存在。在这种情况下，rsync将比较其中的每个文件源/文件夹与其对应的/目标/文件夹，并且只有在源发生更改时才会更新后者。这使目标中的所有内容都以最少的必要抖动进行更新。这比对所有内容进行蛮力复制要干净得多，不管是否更改!

当你rsync到远程机器时，它会变得更好:

root@test:~# rsync -ha——progress /source/folder user@targetmachine:/target/

当进行远程rsync时，rsync仍然会查看源和目标位置中的文件列表，并且该工具只会处理已更改的文件。rsync还对两端更改的文件进行标记，然后交换标记以确定哪些块在文件已经更改。然后Rsync只在网络中移动这些单独的块。(神圣的带宽节省，蝙蝠侠!)

您可以在“rsync可以做什么”这个兔子洞里走得越来越远。内联压缩以节省更多带宽?检查。服务器端的守护进程是否只公开某些目录或文件、要求身份验证、只允许某些ip访问，或者允许对一个组进行只读访问而对另一个组进行写访问?你说对了。运行不带任何参数的“rsync”会得到一个包含有效命令行参数的“小抄”，有好几页长。

对于那些只使用windows操作系统的管理员来说，rsync“有点像机器复制”，就像你看到光剑时会认为它“有点像剑”一样。

如果rsync这么好，为什么ZFS复制甚至是一个事情?

这真的是一个非常重要的问题。我不想承认这一点，但在我意识到答案之前，我自己已经使用ZFS大约四年了。为了演示每种技术的有效性，让我们看看数字。我使用rsync.net新的ZFS复制服务在目标端和aLinode VM源端。我还将使用我自己的开源编配工具syncoid为了大大简化otherwise-tedious过程ZFS复制。

第一个测试:如果我们将1GB的原始数据从Linode复制到rsync.net会怎样?首先，让我们尝试一下rsync:

root@rsyncnettest:~# time rsync -ha——progress /test/linodetest/ root@myzfs.rsync.net:/mnt/test/linodetest/ sending增量文件列表./ 1G.bin 1.07G 100% 6.60MB/s 0:02:35 (xfr#1, to-chk=0/2) real 2m36.636s user 0m22.744s sys 0m3.616s

现在，用ZFS发送/接收，由syncoid：

root@rsyncnettest:~# time syncoid——compress=none test/linodetest root@myzfs.rsync.net:test/linodetest INFO:发送旧的完整快照测试/linodetest@1G-clean (~ 1.0 GB)到新的目标文件系统:1GB 0:02:32 [6.54MB/s] [=================================================>] 100% INFO:更新新的目标文件系统与增量测试/linodetest@1G-clean…syncoid_rsyncnettest_2015-09-18:17:15:53 (~ 4 KB): 1.52 KB 0:00:00 [67.1 KB / s ] [===================> ] 38%真实的2 0 m0.244s sys 0 m2.548s m36.685s用户

就时间而言，确实没什么可看的。无论哪种方式，我们在2分36秒内传输1GB的数据并进行更改。有趣的是，rsync占用了26秒的CPU时间，而ZFS复制只使用了不到3秒，但是，这种竞争仍然是一种小睡。

让事情变得更有趣。现在我们有1GB的数据在那里，如果我们改变它到足以强制重新同步会发生什么?为了这样做，我们将触摸该文件除了将其时间戳更改为当前时间外什么也不做。

就像之前一样，我们将从rsync开始:

root@rsyncnettest:/test# touch /test/linodetest/1G.bin root@rsyncnettest:/test# time rsync -ha——progress /test/linodetest/ root@myzfs.rsync.net:/mnt/test/linodetest sending增量文件列表1G.bin 1.07G 100% 160.47MB/s 0:00:06 (xfr#1, to-chk=0/2) real 0m13.248s user 0m6.100s sys 0m0.296s .bin

现在让我们试试ZFS:

root@rsyncnettest:/test# touch /test/linodetest/1G.bin root@rsyncnettest:/test# time syncoid——compress=none test/linodetest root@myzfs.rsync.net:test/linodetest INFO: Sending incremental test/linodetest@syncoid_rsyncnettest_2015-09-18:16:07:06…syncoid_rsyncnettest_2015-09-18:16:07:10 (~ 4 KB): 6.73 KB 0:00:00 [277 KB / s ] [==================================================] 149%的实际0 0 m0.068s sys 0 m0.076s m1.740s用户

现在事情开始变得真实。Rsync需要13秒才能完成任务，而ZFS只需要不到2秒。这个问题也是有规模的。对于一个被触摸的8GB文件，rsync将花费111.9秒来重新同步，而ZFS仍然只需要1.7。

碰触还不是最坏的情况。如果我们把一个文件从一个地方移动到另一个地方，或者只是重命名它所在的文件夹，会怎么样呢?对于这个测试，我们有包含8GB数据的同步文件夹/测试/ linodetest / 1．一旦我们完成了，我们就重命名/测试/ linodetest / 1来/测试/ linodetest / 2和重新同步。Rsync先起:

root@rsyncnettest:/test# mv /test/linodetest/1 /test/linodetest/2 root@rsyncnettest:/test# time rsync -ha——progress——delete /test/linodetest/ root@myzfs.rsync.net:/mnt/test/linodetest/ sending增量文件列表deleting 1/ ./ 2/ 8g .bin deleting 1/ ./ 2/ 8g .bin 8.59G 100% 5.56MB/s 0:24:34 (xfr#1, to-chk=0/3) real 24m39.267s user 3m15.944s sys 0m30.056s

哎哟．这本质上是一个微妙的变化，需要近半小时的实时时间和近4分钟的CPU时间。但是使用ZFS…

root@rsyncnettest:/test# mv /test/linodetest/1 /test/linodetest/2 root@rsyncnettest:/test# time syncoid——compress=none test/linodetest root@myzfs.rsync.net:test/linodetest INFO: Sending incremental test/linodetest@syncoid_rsyncnettest_2015-09-18:16:17:29…syncoid_rsyncnettest_2015-09-18:16:19:06 (~ 4 KB): 9.41 KB 0:00:00 [407 KB / s ] [==================================================] 209%的实际0 0 m0.072s sys 0 m0.024s m1.707s用户

是的——ZFS重新同步需要同样的1.7秒，无论我们是触摸1GB文件，还是8GB文件，甚至是移动一个8GB的文件从一个地方到另一个地方。在最后一个测试中，这几乎比rsync快了整整三个数量级:1.7秒对1479.3秒。可怜的rsync根本没有机会。