AWS之迁移与传输服务

发布于：2025-06-02 ⋅ 阅读:(21) ⋅ 点赞:(0)

目录

一、迁移管理与规划类

二、应用程序迁移类

1. MGN的迁移范围（能替代的场景）

✅ 自动包含以下数据：

🔹 适用场景举例：

2. 仍需DMS或DataSync的场景（不可替代）

❌ DMS仍必要的情况：

❌ DataSync仍必要的情况：

3. 技术原理对比

MGN的数据迁移机制：

DMS/DataSync的迁移机制：

4. 决策流程图

5. 典型案例

案例1：仅用MGN

案例2：MGN+DMS

案例3：MGN+DataSync

三、数据库迁移类

四、在线数据传输类

Datasync和Transfer Family区别

1. 协议与访问方式

2. 使用场景

3. 数据处理与元数据

4. 集成与架构

总结：如何选择？

五、离线数据传输类

关键区别总结

典型场景匹配

以下是AWS各迁移与传输服务的区别总结，从功能、适用场景、迁移对象等维度分类对比：

一、迁移管理与规划类

服务名称	功能特点	适用场景
AWS Migration Hub	集中跟踪迁移活动，统一管理多任务进度，提供迁移状态可视化。	企业级多项目迁移管理，需监控跨服务迁移进度（如同时迁移应用和数据库）。
AWS Application Discovery Service	自动发现本地应用及其依赖关系、资源配置，生成迁移清单。	迁移前的应用调研，梳理本地资产（如服务器、应用、网络拓扑），为迁移规划提供数据。
Migration Evaluator（原TSO Logic）	分析迁移的业务价值（成本节省、性能提升等），创建迁移业务案例。	决策阶段，评估“是否迁移”及“迁移ROI”，为管理层提供数据支持。

二、应用程序迁移类

服务名称	功能特点	适用场景
AWS Application Migration Service (MGN)	迁移物理/虚拟/云环境的应用到AWS，自动转换基础设施（如将VM转换为EC2实例），支持应用现代化（如优化架构）。	通用应用迁移（如企业ERP、Web应用），需跨基础设施迁移并改进应用性能。
AWS Mainframe Modernization	专门针对大型机（Mainframe）工作负载，迁移到AWS并现代化（如转换为云原生架构），支持大型机应用的迁移、操作和运行。	遗留大型机系统迁移（如银行核心系统、政府 legacy 系统），需处理大型机特定的兼容性和性能需求。

AWS Application Migration Service (MGN) 确实可以迁移服务器上的所有数据（包括自建数据库和挂载存储），但是否完全替代DMS或DataSync取决于具体场景。以下是关键分析：

1. MGN的迁移范围（能替代的场景）

✅ 自动包含以下数据：

自建数据库数据
- 如服务器内运行的MySQL/MongoDB/PostgreSQL实例的数据文件（/var/lib/mysql等目录）
- 效果：迁移后数据与原服务器完全一致，但数据库引擎和架构无变化
挂载存储数据
- 包括本地磁盘（如/data）、网络挂载的NFS/SMB共享卷
- 效果：块级复制保留所有文件属性和权限

🔹 适用场景举例：

开发测试环境中的WordPress服务器（含MySQL）整体迁移
本地文件服务器（含NAS挂载）原样搬迁到EC2

2. 仍需DMS或DataSync的场景（不可替代）

❌ DMS仍必要的情况：

需求	MGN局限性	DMS解决方案
数据库引擎升级	只能原样迁移	支持Oracle→Aurora等转换
单机→高可用集群	迁移后仍是单点	可输出到RDS Multi-AZ部署
实时同步生产库	仅一次性迁移	支持持续CDC同步

❌ DataSync仍必要的情况：

需求	MGN局限性	DataSync解决方案
仅迁移部分目录	必须迁移整个服务器	可选择性同步/data/images等
源为独立存储设备	无法直接迁移SAN/NAS设备	支持NFS/SMB协议直连
跨云/混合云持续同步	仅支持AWS作为目标	支持双向同步