迁移上云就两个问题

可能是北方的客户相对谨慎一些吧,最近经手的上云迁移项目才开始多了起来,要知道早在两三年前,南方的很多企业和组织已经开始轰轰烈烈的迁移上云了。其实总结起来,上云迁移就是要解决两个问题:

  • 应用系统及相关运行环境的上云问题。
  • 数据的迁移上云问题。

应用系统环境的迁移

应用系统及运行环境的迁移主要的难点是应用系统的运行环境纷繁复杂,有些细节只有当初的系统开发商清楚,针对这种情况,有以下解决方案:

  • 使用迁云工具,将应用系统所在的服务器整体打包上云。迁云工具的使用相对比较简单,但这个方案的问题是迁云工具不一定支持所有的操作系统,有些较老的系统迁云工具目前并未提供支持。
  • 使用镜像转换工具,将现有应用系统制作成镜像后导入上云。迁云工具不支持的操作系统,自行做成镜像导入上云后大概率也是无法启动的,此外镜像的制作过程中也要安装和部署相关的工具和驱动,对实施人员有一定的技能要求。
  • 找到当初的软件开发商,让开发商在云端重新部署。
  • 假如可以协调到软件开发商来协助,并且应用是基于Java开发的,就可以考虑使用EDAS的应用托管服务,将应用软件包托管在EDAS的应用容器中,免去维护应用中间件的烦恼。
  • 更进一步,假如应用是基于Spring Cloud 或者Dubbo 开发的分布式应用,就可以在不修改业务代码的情况下将分布式应用服务接入到EDAS,从而解决限流降级、流量管理、健康检查等这些困扰分布式系统稳定性的难题,以及实现服务拓扑、调用链查询等分布式服务管理功能。

数据的迁移上云

客户在迁移上云的咨询阶段最常问的问题就是:需不需要停机?
应用环境的迁移通常都不涉及停机,与这个问题相关的就是数据的迁移上云问题。而回答这个问题往往需要考虑不同的应用场景,一个繁忙的ERP系统和一个只用于新闻发布的门户网站都能实现用户无感知的数据迁移和系统切换,但要付出的代价完全不同。
数据的迁移上云主要包括结构化数据的迁移上云和非结构化数据的迁移上云。
非结构化数据的迁移上云可以用一些数据同步工具如rsync实现,假如访问非结构化数据的代码部分可以做出一定的调整,就可以使用OSS来存储非结构化数据,从而实现近乎无限的容量扩展和99.9999999999%的数据可靠性,数据迁移到OSS有现成工具可用,可实现在线数据迁移。
结构化数据的迁移有一个神器叫做DTS,可以实现几乎所有主流数据库之间同构迁移,甚至还能实现部分不同数据库之间的异构迁移。DTS可以实现在线数据迁移,在迁移的过程中不需要生产数据库停机。
结构化数据的迁移有一个绕过去的话题就是Oracle数据库在云端的部署问题,面对这个问题有两个流派:

  • 剑宗、在云上服务器直接部署Oracle,单机环境比较容易,但集群环境的搭建和运维就需要独孤九剑加持。
  • 气宗、云上有像PPAS、PolarDB for Oracle这样的与Oracle 90%+ 兼容的云数据库,再结合ADAM这样的迁移辅助工具在这两三年里也迁移了大量的核心关键系统上云。就像气宗一样,刚开始可能困难一些,可一旦迁移完成,日常的运行和维护成本对比Oracle可以忽略不计。

剑宗和气宗,迁移上云,两个问题和两个流派。

上一篇:云服务应该有生命周期


下一篇:POLARDB for Oracle初步体验报告