买球平台(股份有限公司)-官方网站

　　摘要：随着5G通信技术、“互联网+”和物联网的快速发展，云计算作为基于互联网的虚拟资源管理和分布式计算的技术模式，以动态按需和可度量的方式为用户提供服务，将业务平台迁移至云计算平台可实现快速部署业务，有效节约了业务创新及运营成本。所提方案在研究基于云计算平台的业务迁移技术的基础上，以中国移动基于OpenStack的云计算架构为例，对离线迁移、基于平台功能在线迁移、基于块级别在线业务迁移和基于文件级别在线业务迁移等主流业务迁移方案的技术原理和关键点进行分析，同时给出了通用业务迁移流程和方法，最后通过实际平台对3类在线业务迁移方案进行实验验证，分析各方案的技术优势及适用场景，从而指导未来业务迁移的生产实践。

　　基金项目：教育部中国移动科研基金资助项目（No.MCM20170205）；工业和信息化部通信软科学研究项目（No.2019-R-26）；江苏省“六大人才高峰”资助项目（No.DZXX-008）；南京邮电大学科研基金资助项目（No.NY217146，No.NY220028）

　　云计算（cloudcomputing）在全球的迅速兴起，为我国信息技术产业实现创新突破和跨越式发展提供了良好的战略机遇。云计算是一种通过网络统一组织和灵活调用各种信息与通信技术（ICT，informationandcommunicationtechnology）资源，实现大规模计算的信息处理方式[1]。云计算利用分布式计算和虚拟资源管理等技术，通过网络将分散的ICT资源（包括计算与存储、应用运行平台、软件等）集中起来形成共享的资源池，并以动态按需和可度量的方式为用户提供服务。

　　美国制定了“云敏捷”战略，致力于推行云解决方案，为联邦政府信息服务提供有力的技术支撑；加拿大政府发布了更新后的“云优先采用”策略，明确了政府部门优先选择公有云服务；智利政府发布“云优先”行政命令，推行政务迁移上云服务，从而降本增效，提高信息化服务水平；此外，新西兰、阿根廷、菲律宾等国家也纷纷发布相关政策，要求政府ICT基础设施优先应用和部署云服务。2018年8月，我国发布《推动企业上云实施指南（2018—2020年）》，从总体要求、科学制定部署模式、按需合理选择云服务、稳妥有序实施上云、提升支撑服务能力、强化政策保障等方面提出了推动企业上云的工作要求和实施建议[2]。

　　基于云计算的开放平台给传统行业（如政务、教育、金融等）创新提供了强大助力，特别是中/小型企业、个人开发者等都不需要搭设云平台以及维护自身互联网数据中心（IDC，Internetdatacenter）机房，在便于开发和后期维护管理的基础上，大幅度节约了业务创新及运营成本。通过将业务迁移至云平台，实现业务能力开放化、互联网化；在演进模式方面，以“平台+核心产品”聚集客户，形成示范应用，然后共享客户，推广更丰富的服务。以阿里云推出的“智能秒停系统”为例，该系统将停车物联网服务迁移部署于云计算平台，是利用阿里云的基础资源和集成的业务能力共同打造的典型示范案例。在阿里云计算开发服务架构中采用物联网开发套件（支持LoRa2.0和NB-IoT技术等）进行车位硬件节点开发，打通了与高德地图和支付宝的接口，融合云计算、物联网、人工智能（AI，artificialintelligence）、大数据、无感支付等技术，上线了非现场执法、全域停车调度、信用停车3类典型服务，可在50s内向车主反馈违停短信，并同时推荐最佳停车位。

　　云计算平台的开源化和虚拟化对信息化系统的部署和服务支撑带来了便捷，如何对存量业务进行同步迁移[3-4]是一个重要研究方向。本文首先介绍了基于OpenStack的云计算架构，然后对4种主流业务同步的工作原理进行介绍，最后搭建了测试环境，通过迁移实测对主流业务同步迁移方案进行对比，评估各方案的优缺点及适用场景，对未来业务上云方案的实施具有指导意义和参考价值。

　　当前，云计算处于快速发展阶段，技术产业创新不断涌现，企业上云成为趋势，云管理服务、智能云和边缘云等市场开始兴起[5]。AWS（Amazonwebservices）为其云数据迁移定义了6类迁移模式，主要包括保留（retain）、停用（retire）、更换主机（rehost）、重新购买（repurchase）、更换平台（replatform）和重构/重新架构（refactor/rearchitect）。在上述迁移模式中，有的业务强相关，如更换平台和重构/重新架构等：有的生产不可用，如保留和停用。其中，业务无关且生产可用主要通过业务重新部署（重新购买）和迁移承载业务的操作系统（更换主机）两种方式来进行业务迁移，其中，通过更换主机方式进行业务在线迁移是本文描述的重点。

　　业务重新部署主要是指在保证源平台业务可用的情况下，在目标平台上重新部署一套业务，在部署完成后，将源平台的存量业务资源迁移至目标平台，最终达到业务迁移的目的[3，6]。这是一种最容易想到的方法，也是资源投入最大的业务迁移方式。考虑投入产出比，这种方式一般不推荐使用。此外，该方式严重依赖于应用提供方，不同的应用对应的业务迁移方式完全不同，本文不做重点阐述。

　　通过迁移承载业务的操作系统的业务迁移方式即基于系统的业务迁移[7-8]，主要关注两个方面：系统的源平台和目标平台。源平台的种类较多，常见的源平台包括传统物理机、VMware平台、Xen虚拟化平台、Hyper-V平台和基于KVM的各种国产云平台；目标平台的种类比较少，主要包括基于KVM的虚拟化平台和基于ESXI的VMware平台等[9-11]。

　　基于系统的业务迁移有多种分类方式[12-13]，其中，根据承载业务的服务器是否需要停机分类可分为在线迁移和离线迁移；根据业务是否支持增量迁移分类，可分为增量迁移和全量迁移；根据是否需要在源服务器中安装代理分类，可分为基于代理的迁移和非代理迁移。上述分类的标准尺度不同，但都能说明相关迁移方案的特征[14]。

　　基于系统的业务迁移方案属于生产级别的实施方案，对于政企客户和第三方开发者来说是首选方案。本文将以业务迁移的实现方式对基于系统的业务迁移进行归类，主要分为离线迁移、基于平台功能在线迁移、基于块级别在线业务迁移、基于文件级别在线种迁移方案的原理、特点进行具体介绍，分析各种迁移方案的实施原理，从而指导未来业务迁移的生产实践。各种迁移方案的特点对比如表1所示，各种迁移方法的适用场景如表2所示。

　　基于文件级别在线业务迁移 源端为物理机或其他虚拟化平台，且此工具支持磁盘缩容

　　云计算系统的底层是虚拟化层，为了实现云计算的低成本目标，云计算系统大多采用x86服务器，并通过虚拟化提高服务器资源的利用率。虚拟化层的上一层是服务层，该层主要提供资源管理、租户管理、各类服务等。顶层是资源池管理平台和私有云管理平台。基于OpenStack的云计算系统架构如图2所示。

　　云计算内部处理逻辑框架如图3所示，由图3可以看出，云计算是将存储、计算、网络、镜像和编排等服务标准化，在获得鉴权通过的情况下可快速开放给第三方，同时提供监控和告警等服务。

　　虚拟化逐渐成为服务器操作系统的一项标准配置，Linux标准内核包括KVM虚拟化模块，微软Windows 2008自带Hyper-V等。同时，x86虚拟化技术的开源趋势越来越明显，开源KVM等虚拟化技术得到了正规买球的网站RedHat、IBM等服务器厂商的支持，应用越来越广泛。目前，以x86架构为代表的服务器是云计算解决方案的主流。由于对节能、智能等应用的需求，集成ARM（advanced RISC machine）、MIPS （million instructions per second）等RISC（reduced instruction set computing）架构的低功耗服务器将是未来主要的发展方向。

　　业务迁移上云是指将物理机或虚拟化服务器上承载的业务迁移到云计算系统平台上，业务的使用者可以按需使用计算、存储、网络资源，不需要对基础设施进行维护[15-16]。

　　下面主要介绍基于系统的业务上云的实现原理，并在说明各种迁移方法原理的基础上进行场景分析。在开始迁移前，服务器的有效数据量即服务器中的实际数据量；在迁移过程中，由于应用还在运行，因此，在迁移过程中还会产生业务数据，即增量数据。对于政企客户和第三方开发者来说，生产级别的业务迁移方案为首选，而非生产级别的迁移方法、业务强相关的迁移方法本文不做研究。

　　离线迁移是指在业务迁移过程中关闭源服务器，将数据导出并修改数据格式，然后在目标平台启动。关闭源服务器意味着业务需要停服，这种迁移方式对业务的影响程度较大。

　　离线迁移最常用的是RedHat的virt-p2v和virt-v2v。虽然，目前业务上云迁移主要以在线迁移为主，但上述两个工具仍然经常被使用。以virt-v2为例[17]，virt-v2实现原理如图4所示。离线迁移主要解决设备的驱动匹配和镜像磁盘格式转换等问题，具体如下。

　　1）设备的驱动：不同平台使用的磁盘、网络等设备驱动是不同的，常见的物理机主要使用SCSI驱动[18]，KVM使用virtio驱动[19]。在转换过程中，需要把驱动注入操作系统的镜像中，以保证迁移完成后，操作系统在目标平台正常启动。

　　2）镜像磁盘格式[20]：不同虚拟化平台使用不同的镜像磁盘格式，物理机的磁盘格式是raw格式，KVM常用的磁盘格式是qcow2，VMware常用的磁盘格式是vmdk。因此，在业务迁移过程中，需要完成磁盘镜像格式的适配[21]。

　　virt-p2v和virt-v2v主要基于libguestfs实现，实现方式类似于操作系统重新生成驱动文件，具体流程如下[22]。

　　2）主进程在运行过程中，会创建一个子程序。在子程序中，利用libvirt启动一个虚拟机。

　　3）在虚拟机初始化过程中，自启动一个后台进程即守护进程，守护进程能够实现和Linux内核及一系列用户空间的工具（如LVM、ext2等）交互完成特定的功能。

　　4）主程序中的客户机文件系统和虚拟机中的守护进程通过远程过程调用（RPC，remote procedure call）进行交互。

　　基于平台功能的在线迁移利用平台快照功能实现业务迁移[23-24]，其主要应用于源平台为VMware和Hyper-V平台的业务迁移中。在OpenStack同Ceph配合使用的场景下，也可以使用该方式[25]。下文将以VMware虚拟机迁移到基于KVM的OpenStack的虚拟化平台为例，说明其业务迁移的实现原理[26-27]，基于平台功能迁移工作原理如图5所示，迁移实现的具体过程如下。

　　2）调用VMware API生成ROW（reference）快照，并进行多次快照，将生成的增量快照同步助手虚拟机节点。

　　3）调用VMware API将多次生成快照，利用CBT（computer based training）技术追踪生成完整的镜像，然后完成驱动的注入和格式转换。

　　4）利用此镜像（系统盘和数据盘）调用OpenStack的接口完成目标虚拟机的创建，然后验证业务的可行性。

　　该方案特点包括：1）源端零干扰，VMware源环境的虚拟机不需要安装代理。2）系统不需要停机、业务分钟级中断，以块级保护方式为基础，在保证业务系统连续性的基础上完成迁移。3）目标端不需要操作，在目标云平台不需要提前预启动虚拟机以及安装配置系统。4）此方法只适合源端为VMware的虚拟化平台。

　　基于块级别在线所示，其在源端的云主机中安装代理，然后通过代理辅助进行块级别数据同步，将数据同步到目标节点。

　　该方案的核心原理为[28-30]：采用磁盘逻辑重建技术，首先通过代理分析源磁盘逻辑结构，根据源磁盘逻辑结构在目标端重建，重建后将源端的有效数据块写入目标端磁盘对应扇区，确保源端与目标端逻辑上完全一致；将逻辑重建过程中变化的数据块记录在BitMap中，目标重建完成后读取BitMap地址表，让代理寻址到相应扇区读取数据块并复制到目标对应扇区。软件中内置设备驱动库，目标端上线前将从驱动库中自动更新最佳驱动，保证迁移完成后目标系统可正常启动。

　　该方案的特点包括：1）源端安装代理，需要侵入系统；2）块级别数据同步，效率高；3）系统不停机；4）增量数据同步，分钟级业务停服。

　　基于文件级别在线业务迁移方案在源服务器中安装代理，在目标端通过中转虚拟机辅助生成磁盘镜像。该代理会通过rsync的增量数据同步能力，将文件同步到目标节点[31-33]。以中国移动的BC-SMS为例说明其技术实施框架，基于文件级别在线所示。处理逻辑主要分为3个阶段，具体如下。

　　2）SMS-agent首先调用操作系统（OS，operating system）接口，获取虚拟机的完整信息。通过调用OpenStack API创建中转虚拟机。在调用此接口时指定中转镜像，中转虚拟机创建完成后，中转虚拟机的中转镜像服务自动启动。

　　3）SMS-agent检查源端和中转虚拟机网络联通情况，数据的同步过程必须网络可达。

　　该方案特点包括：源端安装代理，需要侵入系统；文件级别数据同步，支持流量控制和磁盘缩容；系统不停机，业务分钟级停服。

　　生产环境的迁移必须保证迁移不会对现网业务产生大的影响，通过一套完善的流程和方法来保证迁移的成功率是非常必要的。在各个厂商迁移实践过程中，形成了各自特有的流程和方法，一部分厂商关注迁移预测试，预测试中关注迁移过程中的性能指标和兼容性指标收集；另一部分厂商更多地注重迁移调研，系统化分析待迁移的业务系统，根据调研情况指导迁移方案。虽然迁移流程各有特点，但是归纳起来主要包括4个阶段，分别为调研与咨询、方案制定、迁移实施和联调切换，迁移实施流程如图8所示。

　　迁移前期需要做需求调研，针对业务系统进行评估分析准备工作，包括评估分析范围的初步确定、确认评估分析方法并准备相关调研所需材料。采用现网环境梳理、现场实际环境评估及确认等对待迁移业务系统进行评估和分析，为迁移工作提供有力支撑。

　　业务迁移需要提前确认的内容主要包括物理机型号、操作系统类型、虚拟类型、集群情况、内存大小、内存平均率、CPU数量、CPU使用率、磁盘个数、实际数据/数据总大小和数据增长规律等[34]。在基础调研后，需要做基础架构的调研和评估，在物理基础架构信息收集和评估中，计算节点能力、存储容量和网络信息、相关的利用率和性能是重要的评估内容。在物理基础架构的评估中，应完成如下内容的评估。

　　1）在基础架构的CPU评估中，收集CPU的型号、主频、内核数和颗数，应评估CPU的使用率。

　　3）在基础架构的磁盘评估中，收集磁盘的数量、RAID（redundant arrays of independent disk）方式、文件系统类型、文件系统总容量和磁盘I/O性能等。

　　4）在基础架构的网络评估中，收集服务器的网卡容量、数量及网络性能，网络交换机的型号、网口数、数量以及基础架构的网络拓扑图等。

　　基础架构调研阶段完成后，需要进一步做应用系统调研与评估，在应用系统层面需针对不同维度进行评估。

　　1）应用系统维度；应用系统评估应包括操作系统类别、版本号（与内核号）、补丁版本、应用软件种类和版本等。

　　2）业务系统维度：完整的业务系统服务通常包括多个应用系统之间的关联关系，通过业务系统间的逻辑架构分析，从而判断各个应用系统间的依赖关系和逻辑关系。业务系统的逻辑架构可以为确定迁移依赖关系、迁移顺序和迁移后存储等提供参考。

　　在迁移方案中，针对云迁移进行详细方案设计，资源确认、迁移前后的各项资源描述、迁移工作顺序、迁移测试及实施计划表。针对迁移场景设计、资源使用、迁移顺序、测试和时间安排做好规划设计，为迁移后的应用系统做好支撑服务[35-36]。

　　在迁移方案制定时，依据源迁移对象、目标场所等因素设计迁移阶段的相关场景。

　　1）测试环境：主要完成迁移过程中应用系统功能、性能等方面的压力测试以及应用系统上线）正式环境：在迁移后的功能、性能压力测试与模拟确认无误后，即可将应用系统归至正式环境提供服务。

　　根据应用系统间的依赖关系及应用系统本身的特性，设计整个系统的迁移顺序。源应用系统可分为独立应用系统、被依赖应用系统、依赖应用系统和复杂应用系统。

　　独立应用系统：该主机上只有一个应用系统，并且与其他应用系统没有任何依赖关系。被依赖应用系统：该应用系统被其他应用系统所依赖，如消息队列系统等。依赖应用系统：该应用系统依赖于其他应用系统。复杂应用系统：该主机上有多个应用系统，这些应用系统间可能有依赖关系，也可能没有依赖关系。

　　在迁移实施时，按照由难到易、由复杂到简单的顺序，能更好地完成所有迁移工作。具体遵循以下迁移顺序：1）被依赖的应用系统优先，数据库等先进行迁移；2）依赖应用系统；3）独立应用系统；4）复杂应用系统。

　　迁移实施主要包括迁移环境准备和迁移执行。迁移环境准备是迁移前最重要的工作，包括人员、网络环境、迁移技术手段、迁移工具等内容的准备。应用系统迁移前，相关人员应准备就绪，包括业务单位信息化负责人、云平台建设运维服务方、迁移服务商等；确认云平台具有足够的CPU、内存、存储和网络资源，以满足被迁移系统的需求。在迁移前，对重要的数据和应用系统进行备份，以防止迁移过程中发生意外情况，必要的系统于迁移前做好压力测试及操作系统重启工作。在迁移执行阶段，需遵守已制定的迁移方案并且严格执行迁移流程。

　　应用系统在联调切换前需进行充分测试与验证，为业务上线做好准备工作，测试方案包括于迁移方案中。测试迁移后的应用系统是否具有与原系统相同的功能，对应用系统进行功能性测试、性能测试、稳定性测试，并对有问题的地方进行优化调整，最后进行应用系统验证，保证服务能够顺利上线。

　　以断开对外网络的方式中止源应用系统对外服务，停止数据访问，保持数据的完整性。若迁移后的虚拟机无法正常使用，可在最短时间内启用源应用系统。

　　将源应用系统磁盘内的数据进行最终的增量数据同步，以维持源端与目标端数据的一致性。

　　在迁移工具中触发业务切换，将迁移后的应用系统在目标云平台启动并开始对外提供服务。

　　由于应用系统联调切换后，有可能导致少数迁移主机无法顺利提供服务。针对此类突发情况，需要在联调切换前拟定应变方案。各类源系统在迁移之前需要进行至少一次备份，备份数据需要包含操作系统、应用以及数据等，以保证数据完整可用。在迁移过程中，由于其他原因导致迁移失败则可利用尚未移除的源主机恢复服务或通过备份系统进行有效恢复，保障业务的连续性。

　　当目标云平台上的应用系统上线后，需要持续对迁移后的业务系统运作进行监控观察。在观察期内，当遇到运行不稳定的服务时要及时进行问题排除及优化；若问题无法排除，则需启动回退机制，将应用系统回退至源平台/源主机运行提供服务。

　　根据上述迁移原理和迁移流程，在我国移动网络环境下进行业务迁移测试，本次测试围绕基于系统的业务迁移方法展开。其他非基于系统的业务迁移如应用重新部署、应用的基于特定平台深度改造、数据库的迁移等，这些方式都和具体的应用强相关，需要结合具体的应用进行讨论，本文不做具体论述。另外，由于离线迁移在业务的迁移过程中需要关闭源服务器且关停服务，导致对用户的影响较大，生产环境中一般不优先采用，因此，业务迁移实验不将其纳入对比测试。迁移测试主要对基于平台功能的迁移、基于块级别在线业务迁移、基于文件级别在线种在线迁移方案进行对比测试，给出各个迁移方法的特点和适合场景。该3种方案都是基于系统的业务迁移，具体应用的部署方式（单机或集群）和类型对研究迁移方法的特点和适合场景无影响。为了广泛获取迁移方式的特点，分别采用Windows Server2012 R2、CentOS7.2和SUSE12等3款主流操作系统进行对比测试。

　　迁移测试环境的源端为VMware平台，目标平台为OpenStack。在VMware环境中安装6台测试虚拟机，分别为CRM01、CRM02、CRM03、CRM04、CRM05和CRM06，且每台虚拟机都部署客户资源管理（CRM，customer relationship management）系统应用。迁移测试业务系统配置场景如表3所示，为了尽可能模拟现网环境的迁移并减少对现网业务的影响，整体迁移在限速情况下进行。由于基于平台功能在线迁移方案不支持对各个虚拟机限速，因此，将整体限速设为60 MB/s。对于基于块级别在线业务迁移方案和基于文件级别在线业务迁移方案，每台虚拟机限速为10 MB/s，整体限速为60 MB/s。

　　为了保证迁移对比的效果，3种迁移方案关于待迁移虚拟机数量、迁移平台、虚拟化系统、硬件配置、磁盘以及实际数据量的配置均保持一致，是同一批虚拟机。其中，实际数据量的一致性保障是通过VMware的快照恢复功能完成的，即在迁移前做虚拟机的快照，在迁移结束后，用迁移前的快照进行恢复。

　　第一次测试基于Windows Server2012 R2系统进行，第二次测试基于CentOS7.2进行，第三次测试基于SUSE12进行。对每一次测试，按照如下迁移测试操作步骤进行操作。