将 400G 文件从 ec2 弹性块存储卷复制到 s3 的最快方法是什么？

Question

我必须将 400G 的文件从弹性块存储卷复制到 s3 存储桶...这些大约 300k 个文件约为 1Mb

我试过s3cmd和s3fuse，两个都是真的，真的很慢..对一个完整的一天s3cmd然表示，完成复制，而当我检查了水桶，若无其事（我想，出事了，但至少s3cmd 从未抱怨过任何事情）

S3Fuse 又工作了一整天，复制了不到 10% 的文件......

有没有更好的解决方案？

我当然在运行 Linux (ubuntu 12.04)

Answer 1

有几个关键因素决定了从 EC2 到 S3 的吞吐量：

• 文件大小 - 较小的文件需要更多的请求和更多的开销并且传输速度较慢。对于大于 256kB 的文件，文件大小的增益（当源自 EC2 时）可以忽略不计。（而从具有更高延迟的远程位置传输，往往会继续显示可观的改进，直到 1MiB 和 2MiB 之间）。
• 并行线程的数量 - 单个上传线程通常具有相当低的吞吐量 - 通常低于 5MiB/s。吞吐量随着并发线程数的增加而增加，并且趋于在 64 到 128 个线程之间达到峰值。应该注意的是，较大的实例能够处理更多的并发线程。
• 实例大小 - 根据实例规格，较大的实例具有更多的专用资源，包括更大（且可变性更小）的网络带宽分配（以及一般的 I/O - 包括从临时/EBS 磁盘读取 - 网络连接。典型）每个类别的数字值为：
  • 非常高：理论值：10Gbps = 1250MB/s；现实：8.8Gbps = 1100MB/s
  • 高：理论值：1Gbps = 125MB/s；现实：750Mbps = 95MB/s
  • 中等：理论：250Mbps；现实：80Mbps = 10MB/s
  • 低：理论：100Mbps；现实：10-15Mbps = 1-2MB/s

在传输大量数据的情况下，使用集群计算实例可能更经济实用，因为吞吐量的有效增益 (>10x) 大于成本差异 (2-3x)。

虽然上述想法相当合乎逻辑（尽管每个线程的上限可能不是），但很容易找到支持它们的基准。一个特别详细的可以在这里找到。

使用 1MB 对象的 64 到 128 个并行（同时）上传应该使 m1.xlarge 拥有的 1Gbps 上行链路饱和，甚至应该使集群计算 (cc1.4xlarge) 实例的 10Gbps 上行链路饱和。

虽然更改实例大小相当容易，但其他两个因素可能更难管理。

• 文件大小通常是固定的——我们不能在 EC2 上将文件连接在一起，并在 S3 上将它们分开（因此，我们对小文件无能为力）。然而，大文件，我们可以在 EC2 端拆分并在 S3 端重新组装（使用 S3 的分段上传）。通常，这对于大于 100MB 的文件是有利的。
• 并行线程有点难以迎合。最简单的方法归结为为一些现有的上传脚本编写一个包装器，该脚本将同时运行它的多个副本。更好的方法是直接使用 API 来完成类似的事情。记住关键是并行请求，不难定位几个潜在的脚本，例如：
  • s3cmd-modification - s3cmd早期版本的一个分支，它添加了这个功能，但已经好几年没有更新了。
  • s3-parallel-put - 相当新的 Python 脚本，运行良好

Answer 2

因此，经过大量测试后s3-parallel-put 非常成功。如果您需要将大量文件上传到 S3，显然是解决方案。感谢cyberx86的评论。