god*_*god 2 copy file amazon-s3 s3fs
我们有一个数据中心,带有一个到AWS的10G直接连接电路.在数据中心,我们有一个IBM XIV存储基础架构,其GPFS文件系统在单个顶级目录中包含1.5亿个图像(每个约50k).我们可以整天争论这是多么愚蠢,但我宁愿为我的任务寻求建议,将所有这些文件转移到s3桶中.
我不能使用任何物理传输解决方案,因为数据中心被物理锁定并且获得本地物理清除是一个为期6个月的过程.
执行此文件迁移的最佳方法是什么？
我到目前为止最好的想法是在AWS中构建EC2 linux服务器,使用s3fs-fuse安装s3目标存储桶(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毫秒内,10 Gbit/s链路可以传输10 Mbits.您浪费的每毫秒不传输数据会使作业的运行时间增加更多.因此,您需要保持数据流动...而您的解决方案将无法实现这一目标.
S3可以轻松处理每秒100次上传,如果按顺序上传,则每10分钟上传一次...并且s3fs不太可能跟上它的步伐,并且每隔10ms就可以在链接上传输100 Mbits. ..但你没有.您只管理了1个50k或更少的对象.虽然s3fs无疑是非常酷的 - 我在一个用于生产后端系统的应用程序中使用它 - 它也是理论上最不正确的使用S3实际工作的方式,因为它试图将S3视为文件系统......并使用文件系统语义将其暴露给操作系统......而S3是一个对象存储,而不是文件系统,并且两者之间存在"阻抗差距".
这里的人工阻塞点是s3fs,它只允许tar在任何给定的瞬间提取一个文件.tar的输出将反复阻塞一些微秒或毫秒,等待每个对象上的s3fs,这将阻止来自网络的tar输入,这将阻止TCP连接,这将阻止源tar ...意味着你实际上并不是最大限度地利用你的任何真实资源,因为你达到了不必要的限制.
不要紧,如果s3fs遇到错误会发生什么.根据错误的性质......
tar: broken pipe
D'哦.
你真正需要的是并发性.将这些文件并行地推送到S3 ,就像S3一样快.
您最好的选择是在私有数据中心运行代码.将文件列表分成几个块.产生多个独立进程(或线程)来处理一块文件,从磁盘读取并上传到S3.
如果我这样做(事实上,我已经做过),我会编写自己的代码.
但是,您可以使用aws CLI的aws s3 cp命令结合gnu 轻松完成此操作,gnu parallel可以配置为以类似的方式运行xargs- 每个"n"并行调用aws s3 cp被指示复制parallel构建的文件列表来自stdin并在命令行中传入.
未经测试,但在正确的轨道上...... cd进入文件目录,然后:
$ ls -1 -f | parallel --eta -m aws s3 cp {} s3://bucket-name
ls -1 -f列出目录中的文件,每行1个,仅名称,未排序,输出管道parallel.
--eta 估计到目前为止基于进度的剩余运行时间
-m表示{}尽可能多地替换输入参数,同时不超过命令行长度的shell限制
有关parallel其他选项的信息,请参阅gnu的文档,例如日志文件,错误处理和控制要生成的并行进程数(默认情况下应该是运行它的计算机中的核心数).只要您有免费的处理器容量和内存,您可能希望运行2x,3x,4x并行作业的数量,因为处理器将浪费大量时间等待网络I/O.