file - 将数据中心单个分区上的数十亿个文件迁移到 s3 的最佳方法？

Question

我们有一个带有 10G 直接连接到 AWS 的电路的数据中心。在数据中心，我们有一个 IBM XIV 存储基础架构，其 GPFS 文件系统在单个顶级目录中包含 15 亿个图像(每个大约 5 万个)。我们可以整天争论这有多愚蠢，但我宁愿为我的任务寻求建议，即将所有这些文件移动到一个 s3 存储桶中。

我不能使用任何物理传输解决方案，因为数据中心被物理锁定，并且获得本地物理许可需要 6 个月的时间。

进行此文件迁移的最佳方法是什么？

到目前为止，我最好的想法是在 AWS 中构建 EC2 linux 服务器，使用 s3fs-fuse ( https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon ) 作为 EC2 服务器上的文件系统安装 s3 目标存储桶，然后在数据中心之间运行一些 netcat + tar 命令持有 GPFS 挂载的服务器和 EC2 服务器。我在另一篇文章中找到了这个建议:
目标框:nc -l -p 2342 | tar -C/目标/目录 -xzf -
源码框:tar -cz/source/dir |数控 Target_Box 2342

在开始一项可能需要一个月的任务之前，我想看看这里是否有人有更好的方法来做到这一点？

Answer 1

如果你有一个月的时间，你正在考虑的可能会奏效......但沿着这条路有陷阱。

为了解释这些，我需要有点哲学。

当面对您想要优化的资源密集型工作时，通常最好找出几个有限资源中的哪一个最适合将其推到极限，然后确保所有其他资源都足够让这种情况发生。有时，您实际上最终将一种资源推向了人为且不必要的限制。

在 1 毫秒内，一条 10 Gbit/s 的链路可以传输 10 Mbits。您浪费的每一毫秒不传输数据都会使作业的运行时间增加更多。因此，您需要保持数据流动……而您的解决方案将无法做到这一点。

S3 每秒可以轻松处理 100 次上传，如果按顺序上传，则每 10 毫秒上传 1 次……而 s3fs 不太可能跟上这一速度，而且每 10 毫秒您就可以通过链接传输 100 Mbits。 ..但你没有。您只管理了 1 个 50k 对象，或者更少。虽然 s3fs 无疑非常酷——我在一个生产后端系统的应用程序中使用它——但它也是理论上最不正确的使用 S3 的方法，因为它试图将 S3 视为文件系统......并将其暴露给具有文件系统语义的操作系统......而 S3 是对象存储，而不是文件系统，并且两者之间存在“阻抗差距”。

这里的人工阻塞点将是 s3fs，它只允许 tar 在任何给定时刻提取一个文件。 tar 的输出将重复阻塞若干微秒或毫秒，等待每个对象上的 s3fs，这将阻塞 tar 从网络的输入，这将阻塞 TCP 连接，这将阻塞源 tar……意味着你实际上不会最大限度地利用您的任何实际资源，因为您达到了不必要的限制。

不要介意如果 s3fs 遇到错误会发生什么。根据错误的性质...

tar: broken pipe

哦。

你真正需要的是并发。将这些文件以 S3 接收它们的速度并行推送到 S3 中。

你最好的选择是在私有(private)数据中心运行代码。将文件列表分成几个 block 。生成多个独立进程(或线程)来处理一大块文件，从磁盘读取并上传到 S3。

如果我这样做(事实上我已经这样做了)，我会编写自己的代码。

但是，您可以使用 aws CLI 的 aws s3 cp 相当轻松地完成此操作。命令与 gnu parallel 结合使用, 可以配置为类似于 xargs -- aws s3 cp 的“n”个并行调用中的每一个被指示复制 parallel 的文件列表从标准输入构建并在命令行中传递。

未经测试，但在正确的轨道上... cd进入文件目录，然后:

  $ ls -1 -f | parallel --eta -m aws s3 cp {} s3://bucket-name

ls -1 -f列出目录中的文件，每行 1 个，仅名称，未排序，输出管道到 parallel .
--eta根据迄今为止的进度估计剩余运行时间。
-m表示替换 {}尽可能多的输入参数，同时不超过 shell 对命令行长度的限制

查看 gnu 的文档 parallel对于其他选项，例如日志文件、错误处理和控制要生成的并行进程的数量(这应该默认为您在运行它的机器中拥有的核心数量)。只要您有可用的处理器容量和内存，您可能希望运行 2 倍、3 倍、4 倍数量的并行作业，因为有内核，否则处理器将浪费大量时间等待网络 I/O。