背景
我在公司用过很多服务商的对象存储或者云存储功能,阿里云的OSS,七牛云的Kodo,网宿的WCS,金山云的KS3,小米云平台的FDS,亚马逊的S3等等。之所以用过这么多存储服务,是因为公司有大文件下载的业务需求,为了向遍布全球很多国家的设备提供稳定、优质的下载加速,具备突发性超大流量承载能力。在海外主要设备集中地架构了20多个节点,所以用到了不同服务商的存储服务,来做镜像回源。
首先会将大文件上传到国内阿里云的OSS上,当海外设备来请求对应资源时,会先向最近的节点存储服务上获取资源,若没有,节点存储服务会直接向国内阿里云的OSS拉取对应资源并返回,等下一次其它设备再来该节点请求同样资源时,该节点会直接返回资源。
但是因为存储了很多之前的资源文件,不可能建立新节点后,每次都让新节点来拉取资源,这样也会造成巨大的流量费用,所以在每次建立资源节点时,会先将已有的资源提前同步到资源节点上,再有新增的才会走镜像回源拉取。因此一个对象存储的迁移工具必不可少,这里我使用的是 migration-tool,它支持迁移 fds/oss/s3/ks3 等对象存储。
使用
第三方对象存储引擎迁移的命令行工具。工具下载地址:migration-tool.tar.gz
将它上传到服务器解压后,进入 bin 目录,运行 sh migration-tool.sh
这里举例说明将 阿里云OSS 的对象存储资源迁移到小米云平台的 FDS 上,命令如下:
sh migration-tool.sh
-st oss
-se http://oss-cn-hangzhou.aliyuncs.com(OSS的endpoint)
-sak OSS的accessKey
-ssk OSS的secretKey
-sb OSS的bucket
-de FDS的endpoint
-dak FDS的accessKey
-dsk FDS的secretKey
-db FDS的bucket
参数说明
参数 | 可选值 | 含义 | 例子 |
---|---|---|---|
-st | fds或oss(必填) | 迁移源端的对象存储名称 fds/oss/s3/ks3 | sh migration-tool.sh -st oss |
-se | 必填 | 源端对象存储系统的endpoint | sh migration-tool.sh -se http://oss-cn-beijing.aliyuncs.com |
-sak | 必填 | 源端对象存储的accessKey | |
-ssk | 必填 | 源端对象存储的secretKey | |
-sb | 必填 | 源端对象存储的bucket | |
-de | 必填 | 目标fds的endpoint | sh migration-tool.sh -de cnbj1-fds.api.xiaomi.net |
-dak | 必填 | 目标fds的accessKey | |
-dsk | 必填 | 目标fds的secretKey | |
-db | 必填 | 目标fds的bucket | |
-bw | 可选 | 每个线程最大带宽,单位MB,默认10MB | |
-ps | 可选 | 迁移的线程数, 默认是10 | |
-nsle | 可选 | 不跳过已存在的object,即覆盖已存在的文件 | sh migration-tool.sh -nsle |
-sm | 可选 | 指定起始的object(指定后包含该object),默认为null,即从头开始 | |
-em | 可选 | 指定结束的object(指定后不包含该object),默认为null,即到bucket的最后 | |
-p | 可选 | 指定要迁移的object前缀,默认为null,即bucket下的所有object | |
-fp | 可选 | 指定objects列表的文件路径 |
注意事项
迁移过程中,可能出现迁移失败的 object。
它会自动在你的文件夹中生成 log 文件,在 log 中,每分钟会打印一次迁移统计的 log,copiedBad 是指拷贝了,但是损坏了的文件数(迁移工具会自动删掉),copiedFailed 是指迁移失败的文件数,可以通过在log中搜关键词 “Copied bad” 和 “Failed to copy object” 找到对应的object名。
迁移时间过长可以加个 nohup 让它在后台运行。
注意服务器的内存大小,当时我就只在 1核1G 的容器里,执行该脚本,过一段时间会被Kill掉,就是因为内存给的不够。
评论