ceph成功案例

导读：从实现多云迁移到实现对Apsara Stack自动化迁移的全面支持，万博智云为自己的产品开启了顶级流量入口，获取客户信任的时间更短。

作者 | 孙琦

ceph成功案例,(1)

前言

作者介绍：孙琦，万博智云CTO（万国数据 (NASDAQ:GDS) 合资子公司），阿里云解决方案领域MVP，Ceph中国社区联合创始人，AWS Certified DevOps Professional。曾先后就职亿阳信通、摩托罗拉、瞬联软件等国内外知名企业。2013年开始创业，从事私有云领域研发工作，2016年带领团队开发云原生迁移平台HyperMotion，该产品在江苏农信、国家电网等诸多项目得到广泛应用。在开源社区方面，2018年成功组织Ceph全球首次峰会，并帮助多家国内知名企业加入Linux Foundation旗下的Ceph基金会。

关于万博智云

万博智云信息科技（上海）有限公司成立于上海，是国内领先的云技术和数字化架构服务商。万博智云专注于为企业提供中立/专业的云咨询、云产品、云服务；致力成为企业 IT运营、数字化发展可信赖的云服务商。公司秉持以产品驱动服务，以科技提升企业商业价值的理念，持续提供丰富的云化产品、解决方案、专业咨询服务，并联合生态体系助力企业在数字化时代全速发展。

万博智云核心研发团队组建于2013年5月，2013年到2016年期间团队致力于开发基于OpenStack私有云产品，2016年后团队转型全力开发云市场细分领域产品——云迁移。2017年完成了沭阳农商行私有云平台建设及业务系统上云项目，该项目获得银监会四类科技成果奖，第二届优秀云计算开源案例二等奖；2018年完成江苏省农信联社专有云平台建设，同时利用云迁移产品完成1200多套业务系统批量上云，该项目获得银监会二类科技成果奖，第三届优秀云计算开源案例二等奖；同年，完成国家电网27个省近20000台VMware虚拟机批量上云迁移；2019年完成海通证券云管平台与云迁移产品整合，该项目也是国内首个将云管平台整合到云管平台提供自助式迁移服务的项目；2020年完成前海股权VMware虚拟机批量迁移至阿里云项目。

结缘云迁移

2011年开始，我一直从事OpenStack在企业私有云应用的研发工作。从2011年一直到2018年，是开源社区最为活跃的时间段，各个公司将自己的主要精力全部投入到OpenStack各个模块的优化中。当时建设私有云平台所提供的服务往往是全方位的，从系统集成、安装实施再到后面的运行维护和定制化开发，基本上就是一整套全栈式解决方案，甚至有时候云平台之上的业务系统出问题，客户也会来找你。这对于任何尚处于初创型规模的OpenStack公司往往是个巨大的挑战。

2016年的时候，我们为一家农商行客户建设私有云，经过反复的前期验证，最终在2016年底拿下了该项目。当时除了建设云平台的需求外，还有一项作为验收标准的需求是将用户原有运行在各种物理机的业务系统平稳的迁移到新的云平台上，迁移过程不能对现有业务产生任何影响。最后还要将旧的硬件进行必要升级后，重新加入到新的云平台。

回想起当时云平台的建设过程，架构上并不复杂，就是一个典型的OpenStack使用硬件存储再加上VLAN的简单模式。在实际的项目实施中，从硬件到货到上架安装，再到云平台部署完成，前前后后的时间大约在三周左右。但是由于用户对于热迁移和资源回收的需求，整个项目实际耗时竟然长达半年之久。当时客户所处的位置不直通高铁，我们的工程师从北京出发，要不就是坐一夜的绿皮火车，要不就先高铁到徐州再转长途车的方式。无论哪种方式，路上的时间至少要8个小时以上。从方案验证到最终实施完毕，团队内全体成员总共出差次数超过50次以上，最终的实施成本极高。当我们尝试复盘整个过程时，耗时最久的其实是解决各种迁移过程中产生的问题。

挫折中前行

这个客户的业务系统属于典型的老旧型业务系统，运行在物理机加上硬件存储阵列上，有少量的虚拟化环境，操作系统也是五花八门，最多的是SUSE 11，还有Windows 2003，CentOS等，数据库有DB2，Oracle，还有少量的MySQL。

由于是银行系统，所以对于业务连续性有非常强烈的诉求，在迁移上对我们提出了以下几点要求：

第一，风险控制。在任何行业中，稳定、可靠是当仁不让的第一原则，对于关乎民生的金融行业更是如此。所以在实际云平台建设过程中，原有业务系统上云时往往受到的阻力最大。究其原因就是在上云过程中没有一套完整的、科学的方法论及工具让用户打消对上云的顾虑。所以在向云迁移过程中，系统必须是可验证、可回退的。在正式切换到云平台之前，需要让业务系统在云平台之上得到充分的验证；在切换到云平台后，如果一旦发生失败，要马上能够回退到原有系统，继续提供服务。保障在云迁移过程中，风险降到最低。

第二、保障业务连续性。农商行不同于传统的四大行或者城商行，在IT建设上往往有很大的自主权，除了核心交易系统外，其他的业务系统均运行在本地系统上，所以对本地运维能力提出比较高的要求。在迁移过程中，本地业务系统的连续性非常重要，一旦中断银行就无法开门做生意了。同时，根据银监会印发的相关规定：在业务服务时段导致业务无法正常开展达半个小时(含)以上，属于重大运营中断事件。所以基本上迁移的切换时间窗口，只能在晚间进行，但是晚上银行又会有数据下发、跑批等程序的运行，所以留给迁移的时间窗口非常有限，所以必须采用一种近似于热迁移的效果来满足客户的需求。

第三，减少人为干预，保障迁移的可靠性。由于很多系统属于服务厂商开发，部分应用时间久远，甚至很多服务厂商已经不存在了，所以迁移过程中尽量减少对应用厂商的依赖很关键，比如重装、重新配置都会导致应用无法运行。同时，在迁移过程中，由于步骤非常复杂，人为操作过多非常容易产生错误。

在这个过程中，我们走了非常多的弯路，比如从最早采用冷迁移方式的Clonezilla，耗时24个小时才能迁移完一台主机；再比如调研了各种开源的p2v和v2v工具，没有一个好用的；再比如为了解决UEFI启动的问题，修改nova代码，但是加载后发现一台服务器启动过程黑屏了半个小时之久，为了这一个系统我们往返于北京和客户多达五次。这些困难促使我们不得不停下来思考，为什么一个看似简单的迁移，最终却成为影响项目进度和成本的关键因素呢？

从项目中来，在项目中成长

为了解决在项目中遇到的问题，我们尝试了各种手段，最终我们发现灾备领域的数据读取技术加上云原生的方式是最佳的组合方案。使用灾备的块级别差量复制技术能够充分保障业务连续性，而最大程度利用云平台原生接口和资源能够实现“两点之间直线最短”的效果，保障迁移的可靠性，大幅度降低人为介入而带来的不确定性。最终二者叠加的效果满足了风险可控的终极目标。

通过2016和2017年近两年的磨练，一个面向OpenStack的热迁移产品具备了初步产品雏形。在紧接着到来的2018年我们迎来了又一次大考，这一次我们面对着是江苏省农信的专有云平台的大规模迁移，我们需要将该省内全部62家二级法人的业务系统迁移上云。很快我们中标的兴奋就淹没在新的困难面前。在之前的项目中，我们的所有迁移行为都是在本地数据中心完成的，至少所有的网络基本都是千兆的。但是在这个项目中，省端和各个二级法人之间的连接变成了以10Mbps的专线，并且这还是最好的情况，还有更糟糕的只有2Mbps。省端与二级法人的专线连接主要用于省端的数据下发，所以用于迁移的数据传输只能在特定时间段进行，同时不能将全部的带宽占满，以免影响业务。但是，每个二级法人的用户数据量很大，大约在30TB - 50TB。如果完全依赖网络传输，理论上需要一年多的时间。所以完全依赖于网络传输是不可能的，我们需要的是一种硬件加网络的组合方案：由硬件保存全量数据，通过运输方式到省端，将全量数据切换至云端后，再通过网络传输增量。这样形成的效果仍然是热迁移，但是迁移的速度明显提高。

在解决了大规模数据传输后，我们紧接着遇到的问题就是先迁哪个，后迁哪个。我们都知道应用系统存在一定的依赖关系，所以在迁移前必须要梳理清楚应用系统的拓扑结构。同时还要对迁移后的网络、应用配置等变更做出预先分析，保障万无一失。这个过程其实就是在众多迁移方法论中提到的调研分析阶段。在这个过程中，我们也在实践中积累了自己的迁移调研方法和实施方案，对我们后来的项目起到了很大的帮助作用。同时我们也意识到，迁移绝对不是一个工具就解决的问题，而是一个重度的咨询过程，迁移工具只不过解决了最后一公里的问题。

从2018年初开始，我们和用户方组成的江苏省农信业务专家组，深入每个地市，严格遵照调研、评审、实施、切换进行科学的上云。从基本的系统信息采集、整理到业务系统上下联分析，绘制拓扑图，安全性等进行全面评估，之后根据调研的结论整理实施方案、进度，实施方案中要将一切在迁移后的变更提前进行整理，确保迁移过程中万无一失。通过辅助物理设备进行全量数据拷贝，运输到省端后进行切换上云，最终在合适的时间点完成增量及业务切换过程。在2018年下半年，平均一周就可以有三家农商行的业务系统实现全面上云。

在这个项目中，我们的产品得到了极大的锤炼，经受了大规模迁移的考验。通过专有云的建设和业务系统迁移，3年共为江苏农信节省IT投资5.6亿元。截止2018年9月30日，总共完成54家二级法人共1200多套系统迁移。同时，云平台的从最初的15个节点增长到了130多个节点，存储从0.2PB增长至3PB。

从一朵云到一片云

时间到了2019年，我们产品的云原生的理念逐步得到了更多客户的认可，同时这种基于云原生构建的高度自动化的效果正好填补了云迁移这个市场空白。甚至某些老牌的灾备厂商把我们当成迁移竞争对手，直接在软文中进行“诋毁”，不过这一切恰好证明了我们产品所蕴含的巨大价值。

但是只能支持单云的迁移已经无法满足市场上越来越多的云迁移需求，所以在2019年上半年，我们准备全面支持更多的公有云和专有云平台。我们首先选择了国内的最大的公有云提供商——阿里云。阿里云在最近10年已经成长为中国云计算领域的标杆，拥有极高的市场占有率，同时提供了最广泛的API接口支持，为合作伙伴提供最大程度的赋能。由于阿里云与OpenStack在一些机制上存在差异，我们通过近3个月的调研和开发，终于突破了阿里云的热迁移。接下来，我们对云平台的支持范围不断扩大，又用了四个月左右时间，覆盖了国内绝大多数的公有云、专有云和私有云平台，实现了名副其实的多云迁移。

打造极致的用户体验

很多企业级产品留给人的第一印象就是专业且复杂，不培训你两天你都不会用。在云迁移领域也是如此，很多云迁移产品都是由传统灾备厂商对原有灾备软件进行简单改造后的产物。界面复杂不说，操作还极其繁琐，迁移一台主机下来，十几个、二十几个步骤那是基本配置。所以在我们对产品进行迭代时，希望用To C的思维打造To B的产品。

在初始阶段，用户只要根据向导配置源端和目标端的信息后，就可以进入迁移流程。我们将迁移流程分成了三个简单的步骤：选择主机、同步数据和开始迁移。通过高度自动化的流程和对云原生API及资源的巧妙利用，初级的Linux工程师基本上几分钟就能完全上手。同时由于自动化程度高，在批量迁移时优势非常明显。

ceph成功案例,(2)

由于之前一直从事的是私有云领域的产品研发，我们的研发团队在产品开发中存在一种惯性。为了满足私有化部署的需要，我们往往需要将安装包做成无网络依赖的ISO格式。这直接导致的后果就是用户在试用我们的产品时往往需要先花很长一段时间去下载我们的安装介质，之后是安装，最后才能试用。这个一来一回的过程，往往一天的时间就被浪费了。这一点在公有云迁移时，会让人觉得更加繁琐。所以在2019年下半年，我们决定将我们的产品SaaS化，让用户更快速的体验我们的产品而非将时间浪费在安装的环节上。由于人力资源的限制，研发团队和运维团队都受到了极大的挑战。研发团队需要开发新的模块以支持运营、多租户等SaaS需求，同时还要对原有的通讯模式进行改造，避免双向通讯的发生；而实施团队需要兼顾私有项目和线上运维，这就要求平台稳定、高可靠、易运维，所以对云原生的应用就变得尤为关键。我们利用阿里云的Kubernetes容器服务和各种云原生组件完成了SaaS化的改造，在没有增加任何人力的情况下，在2020年初完成SaaS的全面上线。

在巨人肩膀上一起成长

2019年初，AWS斥资2.5亿美金收购了以色列灾备初创公司CloudEndure，虽然这家公司以灾备公司名义被收购，但主要业务却是提供向AWS的迁移服务。我们的产品在设计理念和用户体验上与CloudEndure非常相似，同时我们的产品可以支持国内众多的不同的云厂商。

AWS对CloudEndure的收购给了我们非常大的信心，让我们坚定了走云原生迁移、灾备产品的思路。我们发现这个市场在国内基本上属于空白阶段，虽然传统灾备厂商的工具可以靠堆人解决项目上的问题，但是真正让用户自助式的迁移平台才能让用户自主分配在云端的负载，让云资源得到更快速的消耗，最终让云厂商获益。

于是一个大胆的想法在脑海中形成，能不能把我们的迁移软件以云原生服务的方式集成在公有云平台中呢？经过几番周折，我们开始与阿里云进行接触。非常感谢阿里云的陈绪博士帮我打开了和阿里云团队的合作大门，在2019年与阿里云对接完成后，我们首先迎来了就是阿里云ECS团队的考验，在对产品充分测试后，我们在杭州与阿里云生态合作伙伴团队、投资部门进行了会面，这次会面彻底打开了我们与阿里云的合作大门。

2019年底，我被评为阿里云解决方案领域MVP，进一步促进了我们与阿里云之间的合作。2020年初，阿里云控制台上的应用工具市场吸引了我的目光。这种与阿里云深度整合的方式，对于云原生迁移、灾备是绝佳的栖息之地。通过阿里云MVP运营团队的引荐，我们成功的和阿里云应用工具市场团队进行了对接，同时在2月底决定上架阿里云应用工具市场。

ceph成功案例,(3)

上架阿里云应用工具市场的过程绝非一帆风顺，阿里云对此有严格的安全性要求，上线前必须要通过阿里云安全部门的严格审查。为此，我们做了一些架构上的调整和安全性的加固。最终经过近3个月的努力，终于将我们的平台于2020年7月10日晚8点正式上线。上架后的迁移平台，与阿里云的用户体验保持完全一致，用户使用时毫无违和感。

ceph成功案例,(4)