传统IT 向云迁移的实践指南
发布日期:2021-07-01 03:44:09 浏览次数:3 分类:技术文章

本文共 2276 字,大约阅读时间需要 7 分钟。

企业IT系统拥抱云往往始于云迁移,或基于云原生的构建。如今对于企业用户,仍有很多应用部属在本地数据中心,且属于业务关键型系统,比如SAP HANA。因此,确保安全平滑稳定迁移到公有云,对于这类客户至关重要。今天我们邀请微软资深云解决方案架构师,为您带来传统IT 向云迁移的实践指南

云迁移项目实施流程通常为:1)需求调研 2)迁移方案详细设计 3)技术验证 4)实施及切割 5)迁移结果验证及验收。每个公有云厂商会沉淀出自己的迁移方法论,微软的方法论云采用框架(CAF)看着的是理论联系实际,同时结合优化结构框架(WAF),侧重上云细节设计以及实际操作。详情可以参考参考我们之前发布的内容:云基础架构采用者避坑指南:拥抱“云”,更懂“云”。本篇我们会重点介绍项目实施过程的前三步。

需求调研:明确迁移目标

迁移项目始于客户的迁移动机,根据客户的迁移动机来指定迁移目标,这个目标是衡量迁移项目是否成功的基准。所以风险分析第一步就是明确客户迁移目标,结合客户的现有IT环境来综合评估客户的目标是否可以完成。

也许在客户IT环境调研时发现各种复杂的技术问题,企业级客户系统繁多,并且复杂,来自不同时期上线的,使用了异构的技术架构。这些需要进行评估能否靠一些技术方案解决。如果是绕不过去的硬伤,要及时跟客户提出来与客户讨论解决方法。

客户调研阶段,我们需要对客户的IT信息尽量做细致的了解,以提早发现可能导致迁移失败的风险点。针对客户每个系统,提出相关问题及拓扑图逻辑图信息。

迁移方案设计:风险最小化

了解了客户IT信息后,开始考虑迁移方案。通常迁移方法有很多种,比如下图中看到的Rehost,Refactor,Rearchitect,Rebuild,Replace (重新托管,重构,重新架构,重建,替换)等。这些方法从左到右,迁移后对系统的革新程度(现代化或数字化转型)越来越显著,也越来越多利用到云的特性,但需要实施周期通常也会更长,且可能带来更大的实施风险。所以对于大型云迁移项目中,考虑最小的风险,最适合的方式是Rehost(即Lift&Shift):通过镜像迁移的方式将系统迁移上云,从云上的基础架构上看基本与客户本地数据中心保持一致。这种迁移最简单,花费的时间通常也是最短。如某些系统无法通过Rehost方式迁移的话,可以考虑Refactor等方式。

所以,总体来说,建议优先考虑Rehost。迁移实施结束后,客户可以基于云的使用阶段继续按照下图所示架构,在云上进行优化。

确定了迁移方法,开始考虑使用的迁移工具,从下图列出了一些相关工具种类,目前针对不同的迁移方法会有多种迁移工具来选择,公有云第一方或第三方工具,功能上各有特色。选择的原则是:使用适合自己的工具,无论第一方或第三方。

技术验证:修正迁移方案

确定了迁移方案后,需要对迁移系统做一个迁移的技术验证(PoC),建议使用客户IDC的真实环境(或客户测试环境),基于有代表性同时对业务影响小的系统环境做迁移测试,通常Rehost方式也可以基于技术类验证,并非整个系统。在验证中可以暴露出方案中没有考虑到或着隐性的一些坑,通过验证结果能及时修改迁移方案。

每一个批次的应用切割切割通常需要8-48小时完成,关键注意事项可以在文末经验总结中查看。

云迁移项目经验总结

 针对不同的客户场景,遇到的技术问题不尽相同,最后,我们针对Azure实际迁移项目过程的实践经验,总结云迁移关键点供大家参考:

OS及迁移工具

1.确认客户使用的OS在Azure是否支持,精确到小版本,如有不支持的OS,找到替代方案,升级或更换替代的OS。

2.确认OS软件许可授权,比如Windows及有软件许可费用的 Linux等,确认合规性。

3.掌握迁移工具的迁移原理及迁移架构,在迁移的两端(客户IDC及Azure)上所需的资源比如计算资源、网络、存储空间等 。

4.迁移工具的使用限制,没有万能的工具 。

5.评估哪些应用可以镜像迁移、哪些需要云上重构、哪些需要架构优化。

网络

1.确认客户现有的、迁移期间、迁移之后的网络环境及带宽。

2.计算数据传输时间和带宽。

3.网络切割方案,深入了解细节。

4.准备客户网络环境与Azure网络服务的差异,找到替代方案。

5.深入了解Azure网络限制(ER,VPN,VNet,IP,NSG etc.)。

6.确保使用合规和安全的网络协议,例如:SSH,SFTP,HTTPS等。

7.不直接使用internet传输数据,数据传输使用VPN over internet,或专线。

存储

1.调研客户存储细节信息:类型、容量、IOPS、业务场景、当前问题、未来容量。

2.Azure存储的SLA和限制。

3.存储类型转变及优化(例如:IDC VM上自建的文件共享服务器迁移到Azure文件存储)。

4.提醒客户为迁移实施过程准备足够的存储空间供迁移工具使用。

切割过程

1.永远制定备选方案Plan B。

2.网络环境、Azure资源状况再次检查。

3.提前安排多方相关的人员在切割窗口时间备岗。

安全及资源申流程

1.迁移过程需要用到多个账户及客户现有系统的口令、密码、证书等安全信息,以合规的方式申请、以合规的方式使用。

2.申请客户的某些权限需要客户内部流程审批,为保证项目如期完成,提前了解审批周期,通常需要2-7天时间。

以上的一些基于风险评估考虑的一些信息希望能够给实施迁移项目的架构师或工程师有所帮助,后续我会继续从不同的一些方面总结迁移的方案和经验。

转载地址:https://microsoftchina.blog.csdn.net/article/details/109195198 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:云基础架构采用者避坑指南:拥抱“云”,更懂“云”
下一篇:服务器宕机,我为什么一点也不慌?

发表评论

最新留言

不错!
[***.144.177.141]2024年04月26日 00时54分44秒