4. AWS迁移核心服务与工具链
在AWS迁移项目中，真正决定交付效率的往往不是“能不能上云”，而是“用什么工具把发现、评估、转换、复制、割接串成一条可重复的流水线”。AWS围绕迁移场景提供了一组职责清晰的服务：Migration Hub负责全局跟踪，Application Discovery Service负责摸清家底，DMS负责数据库迁移，SCT负责数据库Schema转换，MGN负责服务器级复制与割接，DataSync负责文件与对象数据同步，Snow Family负责离线批量搬运。理解它们各自解决哪一段问题、彼此如何衔接，比单独记住每个服务的功能更重要。
一、先建立工具链的分层视角
这七个服务可以按迁移阶段分为四层：发现与评估层（Application Discovery Service、Migration Hub）、数据库迁移层（DMS、SCT）、服务器迁移层（MGN）、数据搬运层（DataSync、Snow Family）。Migration Hub本身不执行迁移，它是“迁移进度的控制塔”，把来自DMS、MGN、SMS等工具的迁移任务状态汇聚到一个仪表盘，按应用分组展示“已发现、已评估、已迁移、已割接”的进度。
一个常见的误区是：把DMS和SCT混为一谈。SCT（Schema Conversion Tool）做的是“结构翻译”——把Oracle、SQL Server、Teradata等异构数据库的Schema、存储过程、函数、触发器转换成Amazon RDS/Aurora兼容的DDL；DMS做的是“数据搬运”——把源库的全量和增量数据持续复制到目标库。两者配合的典型顺序是：先用SCT评估转换难度并生成目标Schema，再用DMS做数据同步，最后用SCT的数据抽取代理或DMS完成数据校验。
二、Application Discovery Service：把“未知”变成“清单”
迁移项目最怕的不是技术难，而是不知道自己有什么。Application Discovery Service（ADS）提供两种采集方式：Agentless Discovery Connector部署在VMware vCenter环境中，通过vCenter API采集虚拟机清单、CPU/内存/磁盘配置和性能利用率；Discovery Agent安装在每台服务器上，采集更细粒度的进程、网络连接、端口和依赖关系。采集结果写入ADS的数据存储，并可在Migration Hub中按“服务器”或“应用”查看。
实操中，Agentless适合快速铺开、覆盖VMware集群；Agent适合关键业务系统，用于识别“这台Web服务器调用了哪台数据库的哪个端口”。例如，某制造企业有约320台VMware虚拟机，先用Connector在2小时内完成全量清单采集，再对其中48台核心ERP相关服务器安装Agent，采集到“应用A → 10.20.3.15:1521 Oracle”这样的依赖边，从而把服务器分组为可迁移的应用单元。这些数据是后续MGN复制分组和割接批次划分的直接依据。
三、DMS与SCT：数据库迁移的“结构+数据”双轨
SCT的工作方式是：连接源库，读取Schema元数据，生成转换评估报告，标出“自动转换”“需要手工修改”“无法转换”三类对象。以Oracle到Aurora PostgreSQL为例，SCT会把NUMBER(10)映射为NUMERIC(10)，把VARCHAR2映射为VARCHAR，把序列转换为IDENTITY或序列对象；但PL/SQL存储过程、DBMS_LOB包调用、Oracle特有Hint通常需要改写。SCT会给出“转换复杂度”百分比，帮助判断是直接转换还是重构。
DMS则负责数据面。创建复制实例（如dms.r6i.xlarge）、配置源端点和目标端点、创建复制任务，选择“全量加载+持续复制（CDC）”。DMS通过读取源库日志（Oracle Redo Log、MySQL Binlog、SQL Server Transaction Log）捕获增量。一个典型参数是TargetTablePrepMode：DROP_AND_CREATE会清空目标表重建，TRUNCATE_BEFORE_LOAD只清数据，DO_NOTHING用于目标表已由SCT建好的场景。割接前用DMS的“数据校验”任务对比源目行数与校验和，确认无差异后再切换应用连接串。
四、MGN：服务器级复制与割接
MGN（Application Migration Service）取代了早期的SMS。它的核心机制是：在源服务器安装复制Agent，Agent把磁盘块级变化持续发送到AWS的Staging Area（暂存区），在暂存区维护一份持续更新的副本。需要测试时，从暂存区启动Test Instance，验证应用能否正常启动、依赖是否连通；确认无误后执行Cutover，从暂存区启动正式实例并切换DNS或负载均衡。
MGN的关键优势是“复制与割接解耦”：复制可以持续数天甚至数周，割接窗口只需几分钟。对于一台运行Oracle数据库的Linux服务器，MGN复制的是块设备，因此文件系统、数据库文件、配置都原样保留，不需要重新安装。需要注意的是，MGN要求源服务器与AWS之间网络可达（VPN/Direct Connect或公网+加密），且暂存区EBS会产生持续费用。
五、DataSync与Snow Family：数据搬运的在线与离线选择
DataSync用于在线数据同步，支持NFS、SMB、HDFS、S3、EFS、FSx等源和目标。它按“任务”运行，可设置增量同步、带宽限制、验证方式。例如，把本地NFS共享的12TB文件同步到S3，首次全量可能受带宽限制，后续增量只传变化部分。DataSync适合“带宽可接受、数据量在几十TB以内、需要持续同步”的场景。
当数据量达到数百TB、带宽不足或时效要求紧时，Snow Family更合适。Snowcone（8TB/14TB）适合边缘小批量，Snowball Edge Storage Optimized（80TB）适合机房批量导出，Snowmobile（100PB）用于超大规模数据中心整体搬迁。离线设备的核心逻辑是：把数据写入设备→寄回AWS→AWS导入S3→在云端继续处理。选择依据可以用一个简单判断：若“数据量 ÷ 可用带宽”得到的天数超过可接受窗口，就应考虑Snow。
LAST_ERROR，常见原因是源库归档日志被删除、目标表主键冲突或LOB字段过大；MGN复制停滞检查Agent状态和Staging Area的EBS容量；SCT转换报错优先处理“无法自动转换”的存储过程和包；DataSync任务慢检查是否触发了带宽限流或小文件过多。
把这七个服务放在一条链路上看，迁移就不再是“一台台搬服务器”，而是一条可观测、可回滚、可分批次推进的工程流水线。工具的选择取决于数据形态、停机窗口和团队能力，而Migration Hub的价值在于让所有工具的输出汇聚成一个可向项目干系人汇报的进度视图。