Return to site

企业上云如何做好迁移计划?

当前的市场环境瞬息万变,为保持自身的发展,企业的业务也需不断随着市场做出调整。想要支撑良性的转变,敏捷性、创新等因素至关重要,在这些方面,云计算可谓起到了极其关键性的助力作用。

当企业使用AWS,可以实现按需高效、安全地运行资源,只需短短几小时,就能使企业以远胜从前的效率,敏捷地实现创新,再无需等待数月时间。那企业上云,想更快更好地将原有服务做迁移,制定迁移计划需要注意哪些问题?本篇文章将与你系统探讨AWS迁移模式。

迁移计划阶段的评估因素

在企业计划迁移阶段,需要系统评估多方因素,其中包含业务因素、合规因素、安全因素、平台因素及人员因素等,这些是迁移的基础考量。

  • 业务因素需要考量所有主要利益相关方,是否都支持业务案例和对迁移的承诺,并且是否有资金可以投入迁移工作;

  • 合规因素需要看企业是否有符合合规标准的应用程序;

  • 安全因素需要考虑到企业在数据保密性方面的主要挑战,并且采取了哪些控制措施;

  • 平台因素需要确定一系列试点应用程序,并且得到工作负载所有者的承诺;

  • 人员因素需要验证企业的技能和能力,是否定义了运营的角色和责任。

AWS迁移模式:6R理论详解

在确定评估因素后,我们展开讨论计划阶段最重要的迁移模式问题,这对企业而言至关重要。对此,AWS系统总结了6R迁移理论提供参考,包括:保留 (Retain)、停用 (Retire)、更换主机 (Rehost)、重新购买 (Repurchase)、更换平台 (Replatform)、重构/重新架构 (Refactor/Rearchitect),这将会对你有所借鉴意义。

R1:保留 (Retain)

  1. 客户将在自己的源环境中运行主机/应用程序

  2. 最小限度地分析/验证范围和应用程序依赖关系

  3. 依赖于服务管理的集成

示例:

  1. 待解决的物理依赖关系

  2. 主机/AS400

  3. 非 x86 UNIX 应用程序

R2:停用 (Retire)

  1. 停用源环境中的应用程序和主机

  2. 不迁移到目标

示例:

  1. 现有的停用计划范围

  2. UNIX、AIX、SCO

  3. 用于 DR 的集群主机、替代 HA 主机

R3:更换主机 (Rehost)

  1. 同类应用程序迁移到目标云

  2. 使应用程序在目标云基础设施上工作的最小工作量 (应用程序布局更改程度最小)

  3. 需要进行存储迁移 (无需转换)

  4. UAT – 某种程度的应用程序测试

示例:

  1. 简单到中等 V2V、P2V

  2. 存储:DASD 本地

  3. RHEL 6 以上

  4. Win 2008 以上

R4:重新购买 (Repurchase)

  1. 应用程序将被替换,可能替换成新的云原生应用程序或SaaS平台

  2. 可能需要存储迁移

示例:

  1. 无基础设施迁移

  2. CRM 至 Salesforce.com,HRMS 至 Workday

  3. 存储:云本地

R5:更换平台 (Replatform)

  1. 在目标云上安装更新版本的操作系统和/或数据库

  2. 需要进行存储迁移 (无需转换)

  3. 某种程度的应用程序变更

  4. 在目标上重新安装应用程序

  5. 强烈建议进行 UAT

示例:

  1. W2K3 到 Win 2012;Win 2008 以

  2. RHEL 6 以下;Oracle 8 到 11;所有数据库

  3. 新应用程序版本

  4. 所有集群 (MS 集群、DR)

  5. MS SQL 相同技术 (RDS)

R6:重构/重新架构 (Refactor/Rearchitect)

  1. 操作系统和/或数据库移植

  2. 中间件和应用程序变成云服务产品

  3. 数据转换;数据库转换到 MySQL、Aurora 等

  4. 变更应用程序架构可能还需要进行版本升级或移植

  5. 需要进行 UAT;HPC 网格,无 ITIL

示例:

  1. AIX 到 Linux

  2. Oracle 到 SQL;SQL 到 Aurora 中间件

  3. IBM 产品

  4. 定制/复杂的应用程序变更

即使在一个应用程序堆栈中,企业也可能会遇到2~3个“R”。例如,企业可以更换Web前端的主机,将应用程序层解耦 (重新架构),并将DB的平台更换为AWS (RDS),以便它们不会相互排斥。在实际迁移时,我们通常会看到大约50%的主机更换(Rehost)、25%的平台更换(Replatform),15%的重构/重新架构(Refactor/Rearchitect),其余工作则分散在停用(Retire)、保留(Retain)和重新购买(Repurchase)中。

6R迁移模式的背后

上图显示了迁移策略与时间、成本和敏捷性之间的关系,可以得出一些有趣的反向关系,例如迁移时间和成本与运营成本之间的关系,以及应用程序迁移后的敏捷性。可以从中间看到,更换主机是非常均衡的选择,具有一些即时价值和运营/敏捷性优势,而重构具有最低的潜在运营成本,并提供了大量敏捷性,但可能需要花大量时间才能到这一阶段,因此如果选择了这个路线,最好确保相应的应用程序值得投入大量精力。

在AWS云的经验中,70%的应用程序属于主机更换、平台更换,10%进行了重构,部分Clough和ANZ的其他客户已经显示了这种模式。同时我们发现客户停用30%的现有足迹,因为意识到自身业务包含了不再需要的应用程序等。

云敞科技如何助力寰通实现云迁移

基于AWS的迁移模式,云敞科技为众多企业提供了迁移方面的支持。渠道数据管理服务、供应链管理整体解决方案供应商寰通就曾面临云迁移的需求。随着公司业务量的增加,寰通原物理IDC机房的系统无法满足业务灵活性需求,同时系统安全性较低,服务器普遍能与公网相连,并且还需实现Oracle上云。

针对寰通面临的实际情况,云敞制定了以下的迁移计划,平滑地实现云迁移。

1.综合分析网络情况,去除不必要的公网IP

2.充分使用AWS的安全组、VPC、子网等网络服务

3.根据客户数据对 AWS Oracle的参数进行了相关调整和修正

4.尽可能最大限度保留原来Windows+Linux架构,确保SaaS服务成功部署

5.完善了Oracle的监控和运维管理

客户上线AWS,在迁移、使用云服务中,往往需要投入大量的人员精力,云敞科技则从咨询服务开始,包括选云咨询、架构设计、环境搭建;到包含系统迁移、公/私有云、混合云方案在内的迁移服务;并且最终提供运维服务,支持系统审计、性能优化、7*24小时运维、安全加固,节约客户成本投入并提高效率。

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly