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