我们有一个数据中心，它有一个到AWS的10G直接连接电路。在数据中心，我们有一个IBM XIV存储基础架构，其中GPFS文件系统在单个顶级目录中包含15亿个映像(每个映像约5万个(。我们可以整天争论这有多愚蠢，但我宁愿为我的任务寻求建议，即将所有这些文件移动到s3存储桶中。
我不能使用任何物理传输解决方案，因为数据中心被物理锁定，获得内部物理许可需要6个月的时间。
执行此文件迁移的最佳方法是什么？
到目前为止，我的最佳想法是在AWS中构建一个EC2-linux服务器，使用s3fs-fuse安装s3目标bucket(https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon)作为EC2服务器上的文件系统，然后在持有GPFS装载的数据中心服务器和EC2服务器之间运行一些netcat+tar命令。我在另一篇帖子中发现了这个建议：目标框：nc-l-p 2342|tar-C/target/dir-xzf-源框：tar-cz/Source/dir|nc Target_box 2342
在我开始一项可能需要一个月时间的任务之前，我想看看这里是否有人有更好的方法来做这件事？
如果你一个月过得很好，你所考虑的可能会奏效。。。但在这条道路上也有陷阱。
为了解释这些，我需要有一点哲学。
当面对你想要优化的资源密集型工作时，通常最好弄清楚几个有限的资源中哪一个将是最好的，然后确保所有其他资源都足以实现这一点。有时，你实际上把一种资源推到了人为的、不必要的极限。
在1毫秒内，10Gbit/s的链路可以传输10Mbits。传输数据时浪费而不是的每一毫秒都会使作业的运行时间增加更多。因此，您需要保持数据的流动性。。。而您的解决方案无法实现这一点。
S3可以轻松地处理每秒100次上传，如果按顺序上传，则每10ms上传1次。。。s3fs不太可能跟上这一步伐，每10毫秒你就可以在链路上传输100兆比特。。。但你没有。您只管理了1个50k或更少的对象。尽管s3fs无疑非常酷——我在生产后端系统的一个应用程序中使用它——但它也是理论上最不正确的使用S3的方式，因为它试图将S3视为文件系统。。。并使用文件系统语义将其公开给操作系统。。。而S3是一个对象存储，而不是文件系统，两者之间存在"阻抗间隙"。
这里的人为瓶颈将是s3fs，它只允许tar在任何给定的时刻提取一个文件。tar的输出将在每个对象上重复阻塞一定数量的微或毫秒，等待s3fs，这将阻止tar从网络的输入，这将阻塞TCP连接，这将阻断源tar。。。这意味着你实际上不会最大限度地利用你的任何实际资源，因为你达到了不必要的极限。
别管s3fs遇到错误会发生什么。根据错误的性质。。。
tar: broken pipe
哦。
您真正需要的是并发性。将这些文件并行推送到S3中，速度与S3接收它们的速度一样快。
你最好的选择是在私人数据中心运行代码。将文件列表分成若干块。产生多个独立的进程(或线程(来处理一块文件，从磁盘读取并上传到S3。
如果我这样做(事实上我已经这样做了(，我会写自己的代码。
然而，使用aws CLI的aws s3 cp命令和gnu parallel可以很容易地实现这一点，后者可以被配置为以类似于xargs的方式运行——aws s3 cp的"n"个并行调用中的每一个都被定向为复制parallel从stdin构建并在命令行上传递的文件列表。
未经测试，但在正确的轨道上。。。cd进入文件目录，然后：
$ ls -1 -f | parallel --eta -m aws s3 cp {} s3://bucket-name
ls -1 -f列出目录中的文件，每行1个，仅限名称，未排序，输出管道连接到parallel。
--eta根据迄今为止的进展估计剩余运行时间。
-m意味着用尽可能多的输入参数替换{}，同时不超过命令行长度的外壳限制
有关其他选项，请参阅gnu parallel的文档，如日志文件、错误处理和控制要生成的并行进程的数量(默认为运行该程序的机器中的内核数量(。只要你有可用的处理器容量和内存，你可能想运行2倍、3倍、4倍于核心的并行作业数量，因为否则处理器会浪费大量时间等待网络I/O。
或者，您可以获得一个具有50TB存储空间的Snowball设备，通过UPS送货车上传数据。http://aws.amazon.com/importexport/