基于AWS DataSync 迁移 NetApp NAS上云

摘要

AWS DataSync 是亚马逊云科技一款原生的数据迁移工具，可以方便快捷地迁移数据中心的 NAS 数据到 Amazon端。在 Amazon 端，DataSync 可以直接将数据存放到 Amazon Simple Storage Service (Amazon S3)， Amazon Elastic File System (Amazon EFS)，和 Amazon FSx中。DataSync 同时也可以和 Amazon CloudWatch、 AWS CloudTrail 集成，实现对于迁移任务的记录、监控和告警。本文通过真实场景的案例，阐述通过 DataSync 迁移云下环境中的 NetApp NAS 数据到 Amazon FSx for NetApp ONTAP。

背景

对于 NetApp NAS 的迁移，DataSync 支持存量和增量数据同步，在同步完成后会自动进行源端和目的端的数据一致性校验。本文介绍的 NetApp迁移基于以下典型案例，读者可以参考此案例来搭建迁移环境来进行数据上云。

假设客户在本地 IDC 环境有 NetApp 集群，有若干应用分别通过 NFS 或者 SMB CIFS 方式来访问这些集群。客户的应用存在海量小文件读写的情况：同一个数据卷存在上千万级别的小文件，每天还有大量新增数据。同时有一根 1G 的 Direct Connect 专线可以专门用来做数据同步。

客户需求是把 NetApp 集群里所有卷的数据都迁移到 Amazon FSx for NetApp，并希望尽量缩短迁移过程，更重要的是要确保文件属性和权限的一致性。同时在业务正式切割之前还需要有能做定期增量同步的能力。

迁移环境部署

迁移的整体架构图如下；在客户的云下环境，我们需要至少一台机器作为 Agent 来处理数据的传输（Agent 距离迁移原始端越近传输效率越高）。同时建议再获取一台可以挂载 NetApp NAS 的跳板机来探查 NetApp 的文件数据结构。线下环境和云上通过专线打通，云上以 DataSync Endpoint 的方式来和线下通信。Endpoint 安全组需要打开 TCP 入向的 1024-1064 端口（流量控制）以及 443 端口（数据传输）。详细网络配置可参考附录文档^[1]

云上目的端要提前创建好 Amazon FSx for NetApp，建议使用跨可用区部署；安全组和路由配置要使得和 DataSync 服务通信正常。详细创建流程可参考附录文档^[2] 。

注意：截止博客发表日。AWS DataSync 支持 NFS v3、NFS v4.0、NFS v4.1 以及 SMB 2.1 、SMB 3。低版本的协议建议升级后再使用 DataSync 进行迁移操作。

DataSync 任务配置

AWS DataSync 的任务配置可以直接基于 Amazon 控制台进行图形界面操作，包括 Agent 激活、迁移原始端和目的端创建、任务创建执行等流程。下面展示了任务创建执行的全流程。

DataSync Agent 激活

（1）选择对应的线下环境镜像包，本文对应的环境是 VMware。这里选择 VMware 镜像包进行线下 Agent 机器的安装。

（2）安装成功后登陆系统按照以下步骤获取激活码。系统登陆默认用户名密码（用户名：admin，密码：password）。

填好以上信息后，点击回车即可获取激活码。

（3）在 DataSync 控制台激活 Agent。

Online 状态表示当前 Agent 的状态正常，可以进行下一步任务配置。

DataSync location创建（源端和目的端）

（1）创建源 location（使用上面激活的Agent，协议使用 SMB；两端协议需要一致）

注意: 当使用SMB协议的时候，可以在源端和目的端使用不同的Windows AD账号；但源和目的需要是同一个AD或AD之间有信任关系。

（2）创建目的 location（目的端是 Amazon FSx for NetApp）。

DataSync 任务配置

参考以下流程，使用上面创建的源和目的 location来进行任务配置。

带宽大小会影响原始端的性能，开始建议可以限制小一点。我们这里限制到 20MiB/s。

这里根据实际情况，选择传输的配置项。（后续增量传输可以设置只传输增量数据）

DataSync 任务执行

任务创建好之后即可进行任务执行

在历史记录中查询任务的执行结果：

迁移结果分析

本文迁移实践进行了SMB 2.1，NFS 3协议的相关迁移实验，相关结果参见下表:

源端	目的端	协议	数据量 (GB)	文件数量 (万)	带宽限制 (MiB/s)	任务时间	源端 IOPS 峰值	代理机器配置	代理数量
线下 NetApp NAS	Amazon FSx for NetApp	SMB 2.1	1.4	2.3	10	5分48秒	无	m5.4xlarge 同规格VM	1
线下 NetApp NAS	Amazon FSx for NetApp	SMB 2.1	24	13.5	20	31分22秒	无	m5.4xlarge 同规格VM	1
AmazonFSx for NetApp	Amazon FSx for NetApp	NFS 3	205	210	无	3小时 10分5秒	5000+	m5.xlarge	4
Amazon FSx for NetApp	Amazon FSx for NetApp	NFS 3	300	110	无	1小时 39分36秒	7000+	m5.4xlarge	1
Amazon FSx for NetApp	Amazon FSx for NetApp	NFS 3	470	440	无	4小时 16分7秒	5000+	m5.xlarge	4
Amazon FSx for NetApp	Amazon FSx for NetApp	NFS 3	470	440	无	4小时 20分 15秒	5000+	m5.xlarge	1

任务用时分析

由实验结果对比推测，文件数量对于传输任务耗时的影响系数大于数据量大小。换句话说，在文件数量不变的情况下，数据量大小变化引起的总任务时间变化，较数据量大小不变而文件数量变化的总任务时间变化更少。这是因为传输过程任务在小文件场景下所花费准备阶段建立索引，验证阶段数据哈希验证的时间会变得更长。

带宽IOPS影响分析

在实验中，在不做带宽限制的前提下，同区域的DataSync任务峰值传输速度可以达到200 MiB/s以上，源端IOPS可以达到7000以上。对于商用NAS存储产品，数千IOPS并发压力是相对比较友好的。但在客户环境发起传输任务，需要注意根据客户环境的专线带宽设置传输速度带宽限制，避免过度抢占专线带宽资源。

代理数量及配置分析

由实验结果对比可以发现，在千万文件数量级场景下，单台m5.xlarge已可以很好的满足传输需求。同时，我们不推荐在千万级小文件以下场景使用多台代理，此时增加代理数量并不会明显增加任务传输速度，不同文件数量级采用的代理配置可以参考附录文档^[3]

增量传输任务配置分析

在应用实践中，传输任务可以被复用并配置为增量传输模式。在该模式下，准备阶段会扫描源端及目的端的所有文件并建立索引，并在传输阶段中仅传输差异部分数据。

成本分析

AWS DataSync 的计费方式比较简单，只有一个数据拷贝的费用。不同区域的费用略有差异，以本文作者所使用的新加坡区域为例，传输费用为：$0.0125/GB。上述案例中 205G 数据，DataSync 迁移完毕的总费用为 205 * 0.0125 = 3.125 美元。

同时在上述环境中，我们也使用了 DataSync Endpoint ，这部分会根据使用时长收费。

费用详细介绍可参考附录文档^[4]

常见问题

特殊类型文件报错

[ERROR] Deferred error: create(name=“/**/Thumbs.db”, hard=0, target=, mode=100644, dev=0, flags=241): Permission denied

解决方案：Thumbs.db为Windows文件系统缓存文件，无需同步。如下图所示

Windows 特殊文件类型可参考文档^[5]

元数据校验异常

[NOTICE] /***/**pture.PNG srcMeta: type=R mode=0755 uid=65534 gid=65534 size=21825 atime=1579610388/259577000 mtime=1579610207/773981000 extAttrsHash=1516301661
[NOTICE] srcHash: f1bcb3297909d11cd1b45b4cda37ff9ee367aec43c1f698d2427966041919f82
[NOTICE] /***/**pture.PNG dstMeta: type=R mode=0755 uid=65534 gid=65534 size=21825 atime=1579610388/259577000 mtime=1579610207/773981000 extAttrsHash=4004291957
[NOTICE] dstHash: f1bcb3297909d11cd1b45b4cda37ff9ee367aec43c1f698d2427966041919f82

解决方案：在实验中，我们发现存在极少数数据校验一致的图片文件的元数据属性校验异常，表现为 extAttrsHash 不一致。为探究原因，我们以测试卷中test.png文件为例，挂载源端、目的端卷至Windows服务器的X，Y盘，通过PowerShell中如下命令查看其元数据内容:

Get-acl ‘X:\**\test.png' | format-list

通过比较，我们可以发现元数据的校验异常原因为SDDL语句差异。SDDL语言又名安全描述定义语言，是用于描述Windows域文件访问权限、审计权限及相关权限继承的特定语言。

在此例中，SDDL语言内容差异主要体现在描述符ARAI与AI上。经查阅，AR、AI是继承权限设置描述语言，其释义如下^[6]

描述符	释义
AR	设置SE_DACL_AUTO_INHERIT_REQ标志。
AI	设置SE_DACL_AUTO_INHERITED标志。

在PowerShell环境中，使用ConvertFrom-SddlString命令解析源端和目的端的SDDL^[7]；结果如下：

# Source: 
DiscretionaryAcl : {Everyone: AccessAllowed Inherited (ChangePermissions, CreateLink, CreateSubKey, Delete, DeleteSubdirectoriesAndFiles, EnumerateSubKeys, ExecuteKey, FullControl,
FullControl, FullControl, FullControl, FullControl, GenericAll, GenericExecute, GenericRead, GenericWrite, Modify, Notify, QueryValues, Read, ReadAndExecute,
ReadAttributes, ReadPermissions, SetValue, Synchronize, TakeOwnership, Write, WriteAttributes, WriteKey)}

# Destiantin: 
DiscretionaryAcl : {Everyone: AccessAllowed Inherited (ChangePermissions, CreateLink, CreateSubKey, Delete, DeleteSubdirectoriesAndFiles, EnumerateSubKeys, ExecuteKey, FullControl,
FullControl, FullControl, FullControl, FullControl, GenericAll, GenericExecute, GenericRead, GenericWrite, Modify, Notify, QueryValues, Read, ReadAndExecute,
ReadAttributes, ReadPermissions, SetValue, Synchronize, TakeOwnership, Write, WriteAttributes, WriteKey)}

通过解析我们可以看出源端和目的端的权限是一致的，因此这个 [NOTICE] 类型的异常可以忽略。

同步异常

[ERROR] Failed to open source file /*** /FTP***_**38: No such file or directory

解决方案：这是因为文件在同步过程中被应用程序修改或删除，可以忽略。如果要求源和目的端强一致，则需要在业务停写的情况下，重新进行增量同步。

常见问题总结

如果DataSync执行失败，请从以下几个方面去排错

数据校验码是否一致（如果一致，证明数据同步没有问题）
属性校验码是否一致（如果不一致，证明属性存在差异）
CloudWatch报错是info或者notice级别还是error级别（一般来说不是error级别的日志都可以忽略）
是否拷贝了不应该拷贝的Windows缓存信息（参照上文报错处理，可以使用Filter功能去掉不需要同步的文件）
文件的DACL和SACL对业务的影响程度

总结

DataSync在本次数据迁移实测场景中的表现非常优秀，单台Agent就可以把1G专线带宽跑满，尤其是在海量小文件的场景里，性能表现非常优异。DataSync通过CloudWatch监控和日志的记录，对于迁移过程分析带来了很大的便利，方便对任务进度和细节进行把控。总之，我们认为在NAS迁移的场景中，DataSync作为亚马逊云科技的原生服务，可以为客户带来很大的成本和速度的优势，成为迁移不可或缺的利器。