我在两个数据中心（一个在圣何塞，另一个在多伦多）之间建立了站点到站点的 vpn 连接。
我需要将一个 32GB 的文件从一个 dc 发送到另一个 dc - 尽可能快。
我找到了一个 shell 脚本，它将 32GB 的文件拼接成较小的文件，然后使用 scp 以并行方式进行传输。
问题是，我如何确定通过站点到站点的 vpn 连接发送各种小文件的最佳文件大小（我想尝试最大化带宽）。
显然，我在服务器上运行的 scp 进程越多，我猜该服务器上的负载就越大。
答案1
暂时忘记站点到站点，因为只要它是 ipsec 并且您的端点不是烤面包机，它本身就不太可能成为瓶颈，快速看一下 bbcp：
http://www.slac.stanford.edu/~abh/bbcp/
这是我们上次迁移时使用的 perl 脚本中的一行，它有和你相同的要求，即快速移动数据
sprintf('/usr/local/bin/bbcp -a -F -s 16 -P 10 -T "ssh -x -a -oFallBackToRsh=no %%I -l %%U %%H /usr/local/bin/bbcp" -d . -v %s %s:%s',
join(' ', @files_to_copy), $remote_host, $destination_dir);
尝试各种选项，尤其是线程数。
您希望得到解答的问题是：
- 链接的延迟是多少
- 数据包抖动可能是什么样的
- 我可以预期的最大总带宽是多少
- 我还会霸占整个链接，从而踩到谁/什么呢
使用正确的标志，bbcp 应该能够最大化任何链接，直到 CPU 成为瓶颈。祝你好运
答案2
我会查看 rsync 中是否存在那么大的内容。
就像是：
rsync -ave "ssh -c arcfour -o Compression=no -x" 源文件用户@目标:/path/to/dest
http://en.wikipedia.org/wiki/RC4
这样，如果部分复制由于任何原因中断，您将能够利用 rsync 的内部功能恢复上传。