根据RightScale的《2018 年云状况调查报告》96%的企业使用云,公有云采用从2017年的89%增加到2018年的92%,2018年私有云采用率从2017年的72%上升到75%。新业务可以直接在云上开展,旧业务如何迁移到云上,一直是一个难点,目前还大多停留在重人工阶段。
1
云迁移的难点有哪些?
上云的难点是云迁移,这是业界的共识。云迁移是将组织内部服务器上托管的应用程序,数据和其他组件移动到基于云的基础架构的过程。云迁移为什么难,因为云迁移是一个非常复杂的过程,在云迁移过程中要考虑的因素非常多,包括以下因素:
保持业务稳定:将业务迁移到云上,并稳定运行,业务上云了,可用性更低,这肯定是不能接受的;
弹性:性能满足业务需求,并实现弹性,弹性是云的最大好处之一,业务上云,就是为了获得云的敏捷特性;
安全:因为环境发生变化了,安全需要重新评估和评审,比如像ISO27000和等保这样的安全资质要求,如果环境发生变化,都要重新进行评审;
技术:业务迁移在云上,或多或少都要重新配置和调整,比如如果使用了RDS服务,业务的代码都要调整,这些对技术上都是挑战。
组织和人:业务迁移到云,相关的组织架构要调整,流程要优化,人的技能要重新再培训。
那么,如何才能做好云迁移呢,云迁移正在经历从重人工向工具化和自动化演讲的过程。
2
云迁移,从重人工向工具化和自动化演进
云迁移方式
从迁移方式来看,Gartner将云迁移划分为五种方式:
Rehost:即IaaS层的迁移,应用程序代码不需要修改。
Reflatform:平台层面的迁移,使用云服务,比如是云上的负载均衡,使用RDS数据库,需要部分代码修改。
Refacor/Reengineering:以云供应商的服务为主,对应用进行重构,比如使用云供应商的PaaS服务重构应用。
Retire/Repurchase:转换为购买SaaS服务的模式。
Retain:不迁移,保留在现有环境下。
云迁移的阶段
从迁移阶段来看,可以划分为三个大的阶段
迁移准备:
信息收集,从硬件的配置信息,到操作系统的版本,软件的授权,应用的配置信息等。
确认上下游的依赖关系,这项工作非常重要,决定了迁移的先后顺序
业务规划,根据信息和业务依赖关系,制定迁移方案
迁移及验证:
云的建设或采购
测试环境验证
小范围验证
应用迁移和验证
数据迁移和验证
逐步迁移,并且验证,持续不断的循环,直到完成迁移。
持续改进:
迁移完成不是终点,要充分挖掘云的好处,必须持续不断的优化,持续改进
不断的提升自动化水平
不断的提升数字化水平
传统云迁移需要人工重度参与
如前面的描述,上云迁移是非常复杂的一个过程,要保障业务稳定的迁移到云上,必须对熟悉业务的人来实施,并且制定周密的上云迁移流程和方案,整个迁移过程还需要不断的协调沟通,云迁移在传统上是一个重人工的过程。但是人工方式将迁移的风险都“赌”到了人身上,带来了相对较高的误配风险,同时迁移效率也无法有效提升。而工具和自动化,逐渐成为新方向。
云迁移走向工具化和自动化
早在虚拟化时代,就有一些工具帮助完成物理机到虚拟机,或者虚拟机到虚拟机的迁移,比如VMware的converter工具。随着云时代的到了,迁移到云,每个云厂商也推出了自己的一些工具,可以方便的把客户的物理机或者虚拟机迁移到自己的云上,也有数据层面的迁移工具。但是这些工具一般都只支持自己的云,不支持别的云厂商。通过这些工具,在一定程度上也能提升自动化水平。
此外,除了公有云提供通用工具,面向所有云平台的中立第三方工具,也正在成为新选择。
3
几种云迁移方案对比
公有云迁移方案
每家公有云都有自己的迁移方案,以AWS为例,AWS迁移相关的有好几款工具:
AWS Application Discovery Service:收集有关企业客户的本地数据中心的信息,从而帮助企业规划迁移项目。
AWS Database Migration Service: 可帮助将数据库迁移至AWS。源数据库能够在迁移过程中全面保持运行,该服务支持在不同数据库平台之间的异构迁移(例如从 Oracle 迁移到 Amazon Aurora 或从 Microsoft SQL Server 迁移到 MySQL)。
AWS Server Migration Service (SMS): 是一种无代理服务,可以将本地工作负载迁移到AWS。借助 AWS SMS,可以自动执行实时服务器卷的增量复制、对其制定计划以及进行跟踪,从而能够更轻松地协调大规模服务器迁移。
AWS Snow 系列:使用物理设备将数据传入和传出AWS
特别介绍下AWS Snowmobile,AWS Snowmobile是一个 45 英尺长的坚固集装箱,可迁移高达 100PB 的数据。
公有云迁移解决方案往往都有相应的镜像和数据迁移工具,甚至像AWS这样,有大容量数据的物理迁移方案,但是公有云迁移方案一般只支持自己的云,提供的是标准化的服务,具体实施还需要用户自助,不能根据用户制定周密的迁移方案。
用户自己迁移到云上
用户制定自己的迁移计划,然后逐步迁移到云上,这种方案虽然比较灵活,用户对自己的业务也最熟悉,但是往往因为缺乏迁移经验,会走不少弯路,大多数情况下会造成迁移失败。
借助Cloud MSP完成迁移
Cloud MSP是云和用户之间的桥梁,云迁移是Cloud MSP的基本功(关于Cloud MSP是什么及能做什么,请阅读《云时代,Cloud MSP时代!》)。借助Cloud MSP可以帮助完成以下方面的迁移:
支持迁移到多个公有云,并且支持跨云迁移;
支持迁移到私有云,并且支持公有云迁移到私有云;
结合用户业务情况,制定周密的迁移计划;
团队拥有丰富的云迁移经验;
如何衡量Cloud MSP的云迁移能力,有以下三项指标:
是否拥有自己的迁移工具:迁移工具是衡量Cloud MSP迁移能力的重要标志,强大的工具,代表的是Cloud MSP对云迁移的理解和不断实践的积累,也是迁移自动化水平的保障。
是否有完善的迁移方案:云迁移是一个复杂的过程,Cloud MSP的迁移方案要能根据用户的实际情况定制,并且考虑到相关的推进进度和流程。
是否拥有云迁移的经验:团队是否完成过云迁移的操作。
所以,借助Cloud MSP来完成云迁移才是保证云迁移顺利达到目标的正确方案。在Cloud MSP中,也有很多玩家,我们在上篇 《云时代,Cloud MSP时代!》中有所介绍。其中,ChinaMSP的迁移方案在工具化和自动化方向上走的更远,并且已经在运营商和互联网金融用户处实施,效果显著,下面详细介绍。
4
ChinaMSP的迁移方案解析
ChinaMSP有自己的迁移工具MigFlash,该方案由3类组件构成:控制器、复制器、转换器,控制器用于人机交互、对复制器发出控制指令等,复制器用于将虚拟机、物理机数据由源端加密、压缩后发送到目的端,转换器将机器的文件格式转变为目标平台格式。
MigFlash具有如下关键特性,能够帮助用户实现稳定、快速的云迁移:
-
源端无代理,源端环境无侵入风险
迁移基于磁盘的块复制技术,⽆无需在源操作系统部署agent,避免源端引入异常风险
-
支持增量复制
基于增量复制,可以大大降低迁移数据传输对网络的要求,提升业务迁移速度
-
传输带宽限制
通过多源端和目的端的带宽限制,避免迁移数据和正常业务的带宽争抢,迁移过程不会影响业务
-
数据压缩加密传输
迁移数据中,源端和目的端是压缩加密传输的,降低了带宽要求,并且保证数据的安全性
-
迁移速度线性增长
支持部署多对传输组件,虚拟机并行迁移,迁移速度线性增长,减少迁移时间
-
应用感知的数据保护
支持应用感知,在迁移过程中,内存中的交易数据全部写⼊入磁盘,保证应用事务级别的数据一致性
-
自动化截屏验证
虚拟机⾃自动截屏,⾃自动化验证迁移后虚拟机的可用性,减少人为操作
-
不限次迁移演练
迁移中目标端不限次恢复演练,保证迁移的可靠性,演练对源端⽆无影响,源端业务正常运行
-
全自动化
整个应用迁移全自动化,手工干预少,避免迁移手工操作的⼈人为错误,大幅提升效率