Project Overview A large corporate which is a state-owned air cargo insurance company, it mainly responsible for fuels procurement, transportation, storage, testing and sales, it covers both domestic and overseas businesses. The group has invested a lot of effort in the IT business infrastructure to ensure sustainable development, stability and reliability of the multinational business. […]

HyperBDR is a cloud-native migration and disaster recovery product that utilizes the concept of cloud-native storage. Its core business scenario involves synchronizing the source data to cloud-native storage in a block-level differential manner. Currently, it supports both block storage and object storage. It also leverages Boot-in-Cloud patented technology to restore business systems to a usable […]

HyperBDR是一款基于云原生理念的迁移和容灾产品，核心的业务场景是将源端以块级别差量方式同步至云原生存储中，目前已经实现对块存储和对象存储支持，最后再利用Boot-in-Cloud专利技术将业务系统一键式恢复至可用状态，真正做到了对云原生编排能力的充分利用，满足迁移和灾备等业务场景的不同需求。 HyperBDR目前已经支持的源端操作系统大版本就将近10个(Windows/CentOS/Redhat/Ubuntu/SUSE/国产化操作系统)，小版本更是超过几百个，而在目标目标云平台也陆续支持了将近40个(公有云、专有云、私有云、超融合、虚拟化等)，并且数量还在增加。假设我们将源端的操作系统到全部云平台进行一次覆盖性测试，组合的测试用例可能超过10000个。 这么大规模的情况下想做到测试覆盖，单纯依靠人力显然不现实，必须引入自动化测试手段对核心业务场景进行测试，这样不仅可以满足自动化测试的需要，也可以在日常开发过程中及时让开发人员在新开发功能中对核心流程的影响，进一步提升产品的稳定性和可靠性。 痛点分析 我们先来看一下手工测试情况下，HyperBDR产品测试的几个痛点： 痛点一、测试用例多，人力资源不足 在上述源端和目标端的规模情况下，即使做一些基本冒烟，一次完整的测试的场景用例也依然有一百多种。例如： 源端(19种)：CentOS(6/7/8)、Redhat(6/7/8)、SUSE(11/12)、Ubuntu(14.04/16.04/18.04/20.04)、Windows(2003/2008/2012/2016/2019)、Oracle Linux、国产化操作系统 目标端(9种)：OpenStack、AWS、阿里云、腾讯云、华为云、移动云、ZStack、超融合产品、超融合产品 如此计算下来，一次测试的场景是171种。可能有的同学会说，这些用例也不是很多呀，跑一次也用不了多久，所以接下来让我们看一下HyperBDR在测试过程中第二个痛点：测试周期问题。 痛点二、测试周期长 不同于业务测试，HyperBDR单一场景的测试是非常耗时的，我们先忽略前期资源准备时间和各种配置时间，单纯就数据同步和启动过程进行一下分析： 数据同步：简单来说数据同步的过程就是将源端操作系统内的有效数据(不是分配容量)，以块级别方式读出，写入到目标的云原生存储中。其中，第一次为全量，后续为永久增量。以Windows为例，假设有效数据为500G，如果按照千兆局域网带宽80%利用率计算，传输速度大概在800 Mbps，大约为80 MB/s，耗时约为1小时8分钟。 主机启动：根据不同的云原生存储类型，启动时间有很大的差异性，例如华为云的块存储，由于快照机制以及可以支持交换系统盘，所以启动时间与容量基本没有关系，基本可以控制在5分钟之内。但是对于国内的大多数云平台来说，并没有这样的能力，像阿里云在有快照生成卷时，底层限速为40 MB/s，这样一下子就拉长了恢复实践。我们以对象存储为例，假设我们从内网(Internal网络)将对象存储数据恢复至块存储，一个500G有效数据磁盘的恢复时间大约在40分钟左右。 所以我们在处理单一主机的一次测试，耗时至少在2个小时之内。按照上面假设的场景，一天测试下来，可能连一朵云的完整测试都无法完成。可能这里又有同学说了，你为什么不并发呀？这又引出了我们第三个痛点问题：成本。 痛点三、测试成本 之所以无法完全采用并发的原因，是受限于网络带宽因素。在内部研发环境中，我们的外网带宽只有40Mbps，在上述测试场景中，500G的数据在带宽充分利用的前提下，全量数据传输的时间在35小时左右。这无疑进一步扩大了一次测试的周期。 另外一点，源端这么多环境，如果再加上不同场景，需要占用的源端的计算和存储资源是海量的。随着产品不停地迭代，资源占用会越来越多。所以为了解决这一问题，我们决定采用部分公有云环境，来解决本地资源不足的问题。根据资源使用的特点，主要采用按量计费方式，实现成本最优。在实际测试过程中，主要产生的云资源包括：计算、块存储、对象存储、网络等。在自动化测试中，尽可能缩短资源周期，避免浪费，及时清理资源。另外，还需要对资源账单情况进行监控，避免资源残留。 需求分析 基本原则：不要重复制造轮子 进行自动化测试开发工作，并没有增加新的开发人员。开发工作主要由研发团队负责，测试团队作为使用方。但是由于开发团队有自身产品研发任务，所以为了避免对产品研发造成影响，制定的第一个原则就是不要重复制造轮子，尽可能复用现有技术积累和第三方组件，灵活的实现自动化测试的目标。 需求一、源端自动化创建与销毁 首先要解决的就是源端资源的灵活创建，而这方面最简单的就是利用Terraform，结合不同的模板实现源端资源创建和销毁能力。这样，我们至少拥有了阿里云、华为云、AWS、OpenStack、VMware五大云作为源端的能力。 第二个要解决的是代理方式自动化注册问题。源端主机需要进行Agent安装和注册后，才能被HyperBDR识别进行后续流程。根据操作系统不同，又分为Linux和Windows系统。Linux系统中，可以使用SSH登录系统后执行安装，而Windows则是利用WinRM方式进行Agent安装。 第三，可扩展性满足更多场景化需求。虽然Terraform本身提供了remote执行方式，但是为了后续的可扩展性，可以结合Ansible实现相关功能。未来的测试场景可能还包含对源端各种应用数据完整性的测试，此时在准备源端时还需要额外的准备应用和数据，使用Terraform结合Ansible，可以实现最大的灵活性。 需求二、测试场景与测试工具解耦，满足扩展性需求 简单来说，自动化测试程度越高，开发成本越高，后期维护的成本会更高。因此在规划自动化测试时，要降低测试场景和测试工具之间的耦合性。这样才能最大程度满足测试场景的可扩展性。换言之，测试场景是由测试工具进行灵活组合实现的，而二者之间的差距是通过各种配置文件进行融会贯通。 具体到HyperBDR的自动化测试规划中，我们将场景定义为： 为了验证主线流程的稳定性，我们设计了这样的场景：阿里云的一台CentOS 7操作系统主机，容灾到阿里云对象存储中，利用该数据，主机可以正常启动，系统启动后，可以正常ping通IP地址，可以正常SSH到系统内部，写入一个文件 为了验证华为云驱动的稳定性，我们设计的场景如下：将阿里云的N台主机(包含各个版本的操作系统)，容灾到华为云的对象存储或块存储中，再将主机在华为云进行启动，启动后，利用ping通IP地址，可以正常登录系统，写入一个文件 为了验证增量数据，我们设计的场景如下：将阿里云的N台主机安装数据库，并且构建一定量数据进行记录，容灾到华为云对象存储中，再将主机在华为云进行启动，启动后，除了常规验证外，还要对数据库是否可以访问以及数据记录条数进行比对 而测试工具提供的能力上，我们进行了这样的定义： 源端创建/删除资源：完全由Terraform实现，但是为了后续程序更好的衔接，在产生主机后，自动产生一个conf文件，作为后续命令的输入，而主机内不同的应用则通过编写Ansible模板实现 目标平台配置/数据同步/启动主机/清理资源：这几部分主要通过调用HyperBDR SDK实现，而具体的配置则在配置文件中进行修改，如果是不同场景时，只需要不同的配置文件即可实现 以上全部的步骤，均是可以单独执行的，而每一步完成后，写入统一的CSV文件，这样步骤在连接时可以通过该文件形成统一性。后续可以将该CSV文件直接推送到数据可视化工具中，形成趋势展现的效果。 需求三、实现场景自动化，测试失败及时通知 在实际应用中，几乎从研发到交付的整个过程中都需要使用该工具。比如研发同学在提交代码前，至少需要对基本流程进行一次测试；交付同事在搭建一些演示环境时，也可以利用该脚本提高效率；而测试同事更是对这个工具有强烈的需求。 那么真正的不同场景自动化工作，则是由Jenkins任务完成串联，并且在测试失败后，可以及时通知大家，尽快进行修改。例如：每个小时，做一次小的冒烟测试，确保主线流程是否稳定；每天凌晨，做一次基本冒烟，确保已经支持云平台的稳定性；每周做一次大冒烟，确保主要的操作系统版本的稳定性。这样不仅节约了人力资源，也能第一时间发现版本中的不稳定因素。 实现方式 整体架构 根据上面的需求，完整的工具包含两部分： Terraform：主要包含了源端创建使用的模板以及ansible playbooks，Terraform在每次执行后，会自动产生源端主机列表，用于AutoTest工具的命令行输入参数 AutoTest工具：使用Python语言开发，主要通过对HyperBDR SDK调用控制HyperBDR实现自动化流程调度，各个阶段都是通过独立命令行进行控制，所有的可变部分在配置文件进行修改 AutoTest配置文件包含以下三部分配置： 基本配置：HyperBDR SDK鉴权信息，以及平台整体配置 目标云平台配置：目标云平台鉴权信息，配置参数等，根据不同的存储类型分为块存储和对象存储 […]

自进入2010之后，云计算开始逐步取代传统基础架构，成为信息化系统的全新底座。2020年十月我曾撰写过一篇《云原生趋势下的迁移与容灾思考》(https://sunqi.site/posts/cloud-migration-dr-on-cloud-native/)详细分析了在全新基础架构下，对于用户至关重要的数据保护将发生那些改变。本文是在此基础上，结合最近两年在行业内的实践及近期国内热点事件进行更深入的分析和总结。 云平台——姓“国”还是姓“资” 就在本周(2022年7月12日)，一记重磅消息在云计算圈炸翻了天。微信公众号——“国资小新”发布重磅消息《国资委召开中央企业深化专业化整合工作推进会》。 与云计算领域相关内容引人关注： 会议指出，近年来中央企业深入实施行业领域更广、参与层面更宽、精细程度更高的专业化整合，在服务国家战略、优化国有经济布局、促进实现高质量发展等方面取得显著成效。 中国电信引入多家中央企业战略投资者打造国家云公司，统筹开展科技创新、设施建设和安全防护体系部署，加快构建推动云原创技术生态。 其中中国电信的具体举措为 中国电信聚焦云改数转发展战略，以专业化整合为抓手，打造“一云两翼”业务集群。其中，围绕数字社会发展，引入中国电子、中国电科、中国诚通和中国国新等中央企业战略投资者，组建股权多元化的天翼云科技有限公司，积极推动中央企业云计算资源整合。通过强化与中国电子等中央企业、清华大学等知名高校联合研发，构建完整的、自主可控的云原创技术生态。整合内部资源，天翼云公司下设31省分公司，建立起健全云网一体化运营体系。目前，天翼云是全球最大的电信运营商云、国内最大的混合云，作为国家云的框架基本成型。 通过企业信息查询软件，天翼云科技有限公司仍由中国电信百分之百控股，尚未完成变更，但相信在大方向明确的情况下，一切将加速进行。 “国家云”的确定似乎也让去年沸沸扬扬的”国资云”传闻也有了某种定论。就在去年(2021年)8月12日，天津国资委《关于加快推进国企上云工作完善国资云体系建设的实施方案》第三部分重点任务第二点明确指出： 各企业已经部署在第三方公有云平台（如：”华为云“、”阿里云“、”腾讯云“、”沃云“、”天翼云“、”移动云“等）的信息系统，租约到期日起2个月内全部迁移至国资云，原则上最迟应于2022年9月30日前全部迁移至国资云。即日起，各企业不得再与第三方公有云平台新签、续签云资源租用合同。 目前距离9月30日只有不到短短的2个月时间，不知道该政策的执行的具体情况到底如何？而国家云明确后，会不会对之前的执行有影响？会不会出现重复迁移呢？具体情况，对于外界来说都是未知数。 引发这一切变化的原因之一是在2021年初，某互联网公司悄然在海外违规强制上市，并提供大量重要民生数据。同年6月10日第十三届全国人民代表大会常务委员会第二十九次会议通过《中华人民共和国数据安全法》(http://www.npc.gov.cn/npc/c30834/202106/7c9af12f51334a73b56d7938f99a788a.shtml)，其中明确： 第十四条　国家实施大数据战略，推进数据基础设施建设，鼓励和支持数据在各行业、各领域的创新应用。省级以上人民政府应当将数字经济发展纳入本级国民经济和社会发展规划，并根据需要制定数字经济发展规划。 众所周知，国有企业是关乎国计民生的重要支柱，也是各家”云商“必争之地。国家云的落地，似乎给姓”国“还是姓”资“的不确定性下了定论，中国的云计算势必会走出一条具有鲜明特色的发展道路。但是这会是中国云计算的终点吗？显然不是，政策的制定往往具有滞后性，随着技术的发展，最终形态一定还会随之变化，所以对于企业用户来说唯一不变的就是变化。为了应对这种变化，让对用户最重要的新”国有资产“——”数据“自由的流转起来，使用户更好的拥抱发展的不确定性。 混合云——保护既有投资，拥抱变化 面对变化，混合云显然是符合中国发展的一条道路。从发展的角度来看，由于过去10年间云计算的蓬勃发展，各种公有云、私有云厂商不断涌现，据不完全统计，目前正在运营的公有云至少在20朵以上，私有云的品牌数量更多。从保护企业既有投资的角度来看，企业历史对于云计算、基础架构的投资不可能随意放弃，所以混合云才是符合企业利益和国家战略的综合性基础架构。 从技术角度看，任何底座平台都无法在一夜之间被取代，要遵从系统建设规律，循序渐进。上文提到，数据流转能够让用户更加游刃有余的应对云底座的变化，那么数据在混合云之间的流动，更能有效防止新的云时代的”数据孤岛“的形成。 混合云管理的演进——从平台到工具集 2018年，Gartner曾在一篇文章中(https://blogs.gartner.com/marco-meinardi/2018/01/22/upcoming-research-cloud-management-platforms/)提及云管平台(Cloud Management Platforms)的十大模块。其中将Cloud Migration and DR作为独立的模块存在，这也是十大模块中与用户数据流转最紧密的模块之一。但是从实际项目建设中来看，由于用户早期云上数据量不大，数据流转需求不突出，所有很少能够有云管平台能够提供这样的专业服务模块。仅有少量具有前瞻性的用户看到了这一潜在的需求进行了相关实践，例如在上海证券交易所《交易技术前沿》总第四十期(2020年9月)一篇《海通证券混合金融云平台生态体系建设之云原生迁移服务》中提及了此类最佳实践，这也为其他券商在实践混合云数据流转时提供了参考。 为什么这么重要的服务，在云管平台中却不能直接提供呢？我认为有两点原因：数据量与技术门槛。先来说数据量问题，上文提到，早期的云平台由于数据量少，对于数据流转靠”人拉肩扛“的体力劳动就解决了，但是随着应用数量增多，数据量呈现爆发式增长，传统的”堆人“已经无法满足云上用户数据流转服务化的需求了。而技术门槛才是制约云管平台提供相关服务的最大障碍，众所周知，Cloud Migration和DR的技术底座一部分来源于传统的容灾技术，而另外一部分则是与云原生资源和编排技术组成。换言之，这是一个跨领域的技术结合和创新，其难度不亚于做一个云管平台，而项目交付的压力也让云管平台厂商很难有余力再进行创新。 这一点我们也从2022年4月Gartner的报告《Market Guide for Cloud Management Tooling》得到了印证(https://www.gartner.com/doc/reprints?id=1-29PBZLL4&ct=220413&st=sb&elqTrackId=adedc2cde73f4497b990cb119e448714&elqaid=7083&elqat=2)。首先一个非常显著的变化是对于云管的称谓，原来我们习惯性的将其成为Cloud Management Platform，但是在报告中将云管平台重新定义为Cloud Management Tooling，简单理解就是云管理工具集。Gartnar认为随着云管理服务的深入，一些专业的厂商致力于将服务抽象为自动化工具。在报告中我们发现，第三方专业云管理工具和原有云管平台成为平行模块，共同为MSP提供多云管理能力。同时Gartner在在Cloud Migration and DR模块中增加了Backup，也让我们所定义的“数据流转”的场景化应用得到了统一。 什么是数据流转？——广义云迁移与云容灾的底座 云迁移是一次性的业务吗？很多人都问过我这个问题，包括合作伙伴、投资机构等。我先抛出我的观点：“云迁移”按照应用目的不同分为狭义云迁移和广义云迁移。狭义的云迁移是指：上云、下云或换云等在项目中解决的问题；而广义的云迁移则是数据流转的应用模式之一，后续的衍生场景包括了云容灾、备份、东数西算等。所以从混合云发展趋势来看，云迁移绝不是一次性的需求，而是云的标准服务之一。 狭义的云迁移——基于项目需求的应用场景 先来看狭义的云迁移，在上云高峰期(2010年前)，云迁移是解决“高速公路没有车跑”的最佳方式，能快速刺激底层基础架构扩容，从而弥补厂商在先期项目的损失。 但是随着时间的发展，逐步出现了各种换云的需求，这里列举一些常见的场景： 场景一，原有平台无人运维。早期云平台方案或厂商很不成熟，很多产品都是摸着石头过河，到了后期由于种种原因平台无人维护，业务裸奔，所以必须通过换云方式将业务转移。 场景二，厂商之间的竞争。这种操作，与技术无关，更多的是商业利益的考量，既然从传统客户“拉新”成本过高，那我就从其他友商拉云上的客户。当然还有一种情况，是用户本想体验“免费”的开源，但是试水后发现越来越把控不住或者性能满足不了需求，只好转为商业化方案，这种情况在云平台、云底层存储都有案例。 场景三，平台自身无法升级。这里最典型的就是OpenStack跨版本升级问题，虽然OpenStack在后期提供了升级能力，但奈何厂商版本的OpenStack大量无法提交到upstream的功能，导致根本没有办法实现升级。用户想使用新版本时，只能通过云迁移来进行原有平台替代，再将原有硬件加入资源池方式完成升级。这个问题并不是孤立的，一些商业化版本的云平台中也存在同样的问题。 下云是相对上云来说的，本质上也是换云的一种，但是通常指的是从公有云到私有云的场景，所以特别独立出来讲。公有云确实能帮助对时间属性有强烈要求的厂商加速创新，把握商机，但是随着企业发展，财报的压力势必让野蛮生长转向精细化管理，此时企业必须要考虑公有云和自建哪个便宜的问题。 在狭义的云迁移中，云迁移更像是一种被动行为，只是作为解决方案的一个环节，在这种情况下确实不具备可重复性。 广义的云迁移——基于数据流转的应用场景 广义的云迁移是以数据流转为核心，提供租户级别数据编排的云原生服务。正如Gartner定义的一样，在混合云环境中，通过数据流转能力让数据在不同平台流动，为上层提供各种应用场景，包括但不限于迁移、容灾、备份等服务。 在传统物理环境下，虽然数据也存在这样的流动的可能性，但是由于相对平台比较单一，且上层结合数据的应用较少，所以流动性意义不大。但是进入云原生时代，服务种类丰富，为用户基于数据的业务创新提供了条件。 数据流转能力要合理使用云原生存储资源，向上提供以算力或存储编排为主的应用场景。以算力编排层为例，可以在任意平台上将资源进行恢复，从而满足迁移、容灾、仿真等多种不同的应用场景。而存储编排层则为用户基于数据创新提供了通道，结合自身的各种存储接口，为上层的容器、大数据、AI平台提供数据源。 正如我在之前文章提到的，由于云原生架构的特点，数据被分散存储于各个云原生服务之中，所以数据流转平台要能够适配各种云原生服务，例如：主机、RDS、容器等。同时，合理的利用好云原生存储的特点，实现成本最优。 […]