一种云平台中基于虚机和订单元信息的跨租户数据迁移实现统一纳管的方法

一、发明名称

二、技术领域

云计算数据迁移统一纳管

三、现有技术的技术方案

现如今，计算机应用已深入到生活和生产的各个角落，其中，云计算应用作为一种网络计算模式而备受关注。云计算的服务模式有 SPI(即 SaaS、PaaS 和 IaaS)这三个大类或层次。IaaS(Infrastructure_as_a_Service，基础设施即服务)是指消费者通过 Internet 可以从完善的计算基础设施获得服务。IaaS 提供给消费者的服务是对所有计算基础设施的利用，用户能够部署和运行任意软件，包括操作系统和应用程序。面对越来越多不同租户下的计算基础设施，管理者如何进行统一的管理和计费成为一个新的需求，既需要对不同租户下的计算资源进行迁移达到统一纳管，同时不影响各个租户计算资源上的业务，还需要和平台侧对接实现对计算资源的计费。
目前很多在线迁移的技术一般采用内存复制的方式或是上传镜像的方式，内存复制的在线迁移技术是将源虚机的内存拷贝到目标虚机，这一过程需要重复地对发生改变的内存进行拷贝，直到两边内存一致；上传镜像的方式存在某些镜像较大，迁移耗时较长的缺点。且两种虚机的在线迁移技术只是底层对于资源层面的迁移，没有针对不同租户和对接应用平台进行纳管，在实际应用中对于实际的需求还是有一定的不足。
基于虚机和订单元信息的跨租户数据迁移实现统一纳管是一种综合有效的实战方法，通过对源虚机的 volume(源虚机的系统盘和挂载的盘)做 snapshot 快照，并以此快照生产新的 volume 卷，将此 volume 卷转送（几秒完成）给统一纳管的租户，整个迁移过程源虚机不停机，业务正常继续运行，无须重复对虚机内存进行拷贝，在统一纳管的租户对 volume 卷进行接收后，即可利用此卷启动与源虚机相同配置的虚机，生成目的主机，整个底层虚机的迁移时间较短即可完成，而且不影响源虚机上业务的运行，同时可以把原先不同租户下的所有虚机全部迁移至统一纳管的租户下，为平台通过订单元数据同已创虚机做对接准备，平台侧通过已有的代码实现，通过数据库脚本统一对数据库里源虚机的元数据、源虚机的权限数据和虚机订单关联数据进行更新，即可完成在平台侧统一纳管所有迁移完成的虚机，并关联到订单完成计费。

四、现有技术的缺点及本申请提案要解决的技术问题

内存复制的方法，具体地，在不同的物理服务器上启动一个一模一样的虚机（OS+ 应用），然后将源虚机的内存拷贝到目标虚机，在此过程中源虚机的内存发生了改变，云管理平台持续重复地对发生改变的内存进行拷贝，直到两边内存一致，完成迁移。这种方法存在以下缺陷：1）这种方法是靠内存收敛即拷贝内容越来越少最终达到两边内存完全相同，这显然就需要做很多次的内存比较和拷贝，尤其在有些时候应用持续不断地接收到外部数据或者某些计算需要很长时间，内存很难收敛，内存比较和拷贝的次数更多，这必然会对云管理平台的性能带来影响和压力。本发明并不是在迁移之初就创建目的虚机，而是利用源虚机传送过来的 volume 直接进行创建目的虚机，也直接将源虚机上已部署的业务一并迁移到的目的虚机上，省去重新部署业务的重复劳动。
上传镜像的方式将制作好的云主机直接作为镜像上传至 IaaS 云平台，在IaaS 云平台上直接基于镜像创建云主机。该迁移方案存在的问题是低效，主要在于：1)云镜像上云前没有压缩，会使迁移时间大幅拉长，镜像越大，耗时越长；本发明中无需对虚机镜像进行操作，通过快照生产的 volume 进行传送，几秒即可完成。2)基于上述的大镜像创建云主机，IaaS 云平台通常需要先将镜像下载到本地，进一步将迁移时间拉长，镜像越大，耗时越长。本发明直接使用接收的
volume 卷进行目的虚机的创建，无须进行镜像的上传下载。
此外以上两个已有的迁移并没有对虚机统一纳管和虚机对接平台计费进行解决，同时无法满足跨租户间的虚机迁移，因为平台侧对接底层虚机正常的业务逻辑是一个平台到底层 openstack 的正向同步的业务，同步业务中包括平台侧通过加密算法生成加密密码同步给底层 openstack，对于已在底层创建虚机的租户来说，无法用已有的底层密码（不是从平台侧同步）反向登录平台，所以无法实现登录平台纳管虚机，而且全部虚机还是处于 Iaas 云平台上处理，在实际需求中无法满足客户的需求。
本文基于虚机和订单元信息的跨租户数据迁移实现统一纳管是一种通过对源虚机做新的 volume 卷，并传送到新的纳管租户下创建目的虚机，更加灵活便捷，单台虚机的迁移过程时间短，不影响源虚机的业务正常运行。同时可以把原先不同租户下的所有虚机全部迁移至统一纳管的租户下，这样统一纳管租户通过登录平台就可以在平台侧管理这些迁移的虚机，解决平台里反向跨租户的问题；同时在平台侧通过订单元数据同已创虚机做对接准备，平台侧利用已有的代码实现，通过数据库脚本统一对数据库里相关数据进行更新，后续在开发通过订单生成话单对接外部账务或计费系统解决客户相关的计费需求；开发添加轮询逻辑，不断的从平台侧对底层虚机的信息进行轮询同步获取，实现在平台上管理的虚机的信息和底层完全一致；这样便可完成在平台侧统一纳管所有迁移完成的虚机，并通过订单关联计费以及实现信息同步一致准确。

五、本申请提案的技术方案的详细阐述

本发明公开了一种云平台中基于虚机和订单元信息的跨租户数据迁移实现统一纳管的方法。该方法包括跨租户虚机迁移部分和平台统一纳管关联订单部分。
跨租户虚机迁移部分通过对源虚机的 volume(源虚机的系统盘和挂载的盘)做 snapshot 快照，并以此快照生产新的 volume 卷，将此 volume 卷转送（几秒完成）给统一纳管的租户，在统一纳管的租户对 volume 卷进行接收后，即可利用此卷启动与源虚机相同配置的虚机，生成目的虚机，整个底层虚机的迁移在较短时间即可完成，而且不影响源虚机上业务的运行；平台统一纳管关联订单部分通过改进的代码实现，通过数据库脚本统一对数据库里源虚机的元数据、源虚机的权限数据和虚机订单关联数据进行同步更新，即可完成在平台侧统一纳管所有迁移完成的虚机，并关联到订单完成计费。整个流程灵活高效，不影响已有部业务。
具体步骤包括如下：
步骤 1：对源虚机的 volume（源虚机的系统盘和挂载盘）进行创建快照操作，注意创建快照时不能填写描述，否则会导致快照一直处于创建中状态。
步骤 2：利用新创建的快照作为源创建新的 volume 卷（这个新生成的卷包括源虚机上的业务和数据等参数），为了保证源虚机业务在整个迁移过程中继续提供服务，源虚机不停机，这会造成最终迁移完成的目的主机上丢失部分迁移间断时间的数据，但是考虑到源虚机上业务已部署完成，丢失的数据大部分是日志信息，在业务不出问题情况下，日志信息几乎不需要查看，且整个迁移时间较短，所以这部分间断时间丢失的数据可以忽略，同时由于考虑到项目中迁移虚机数较
多，在同时多次创建新的 volume 卷时，需要区分不同 volume 属于的子系统，常规方法是在快照中的描述栏加入具体描述，但是加入描述后会导致 volume 卷一直处于创建中，无法完成创建，本方案遇到该问题时，发现是字符编码问题，于是在现有的业务代码中引入了可对现有字符进行编码的代码段，然后通过调整后的业务代码解决了不支持中文字符的问题，并在解决了该问题后，实现了在快照中的描述栏加入具体描述时，不会导致 volume 卷一直处于创建中，从而可以完成新的 volume 的创建，此外，由于在快照的描述栏中加入了具体描述，用于标识该 volume 卷对应的子系统，因此，在整个迁移过程中，可以通过具体描述来方便地区分不同子系统的虚机，提高整个迁移的效率，引入了可对现有字符进行编码的代码段为增加判断编码逻辑和转义逻辑，对无中文字符的描述进行放行，而对描述中出现中文字符的描述会把其中的中文字符摘出，通过引入的字符转义对其进行英文转义，转义成功后继续放回到原描述中的原位置。
步骤 3：把新生成的 volume 卷通过底层 Iaas 平台的创建传送功能进行传递，通过新增存储卷迁移传递给统一纳管的租户，这将 volume 卷的所有权能够从一个项目转移到另一个项目，系统平台内部自动实现 cinder transfer-create 操作，转移过程中会生成转移 id 和认证秘钥，这个转移 id 和认证秘钥在平台内部存储，随时为其他接收者提供接收验证的准备，这将作为接受者接收 volume 卷的凭证。
步骤 4：在系统平台侧接收租户下接收以上存储卷的传递过程，当系统平台者收到存储卷转移请求后，租户只需完成允许操作，系统平台根据数据库里的转移 id 和认证秘钥完成校验，校验通过后实现存储卷的传递过程。
步骤 5：在统一纳管的租户下利用接收的新生成的 volume 卷作为一个实例发起启动请求，该请求发送给 nova，nova 会请求 cinder 创建镜像卷，创建完成后，cinder 请求 glance 下载镜像至镜像卷创建成功后，nova 执行虚拟机创建流程，volume 卷通过 openstack 内部机制即可生成一个和源虚机配置完全一致的目的虚机，这里目的虚机的虚机 id 将作为对接平台计费的元数据。
步骤 6：平台根据目的虚机的 id，通过数据库脚本对数据库里源虚机资源表的虚机 id 和源虚机的权限表里的虚机 id 进行同步更新，这样在平台侧控制台中通过代码实现根据更新后的虚机 id 实时对底层接口进行调用，以获取底层最新的虚机信息，同时权限表里的虚机 id 更新后该虚机权限放开，实现在平台侧控制台对新生成目的虚机进行纳管，虚机的各种状态和配置值，实时更新展现在平台侧。
步骤 7：根据已完成的订单数据，针对项目具体的需求，生成的订单数据中的虚机规格，虚机类型，虚机价格，付费类型均和目的虚机一致，生成订单模块为平台侧代码实现，为实现订单与资源的关联，在代码层面实现订单模块和资源模块的解耦，数据库侧通过订单资源表的虚机 id 进行关联。通过数据库脚本对数据库里订单资源关联表的资源 id 进行更新，这样在平台控制台侧通过以上纳管目的虚机资源里查看订单即可以查看到该目的虚机具体的订单信息（价格、付费类型、虚机规格等信息），至此实现平台侧订单和目的虚机的关联，完成订单侧可对目的虚机资源的操作和计费。
步骤 8：为实现云计算运营管理平台资源与 OpenStack 系统中资源数据实时一致，平台侧通过开发实现对底层资源（虚机、硬盘等）信息的轮询，原有技术方案都是从平台侧正向订购虚机资源—下订单—虚机资源开通成功—回调通知订单至开通成功，而本方案中虚机资源已经在底层开通成功，在此情况下，本方案将虚机迁移至统一纳管的租户和生成订单元数据以及将订单和迁移的虚机关联等操作后，还需要对虚机相关联的资源数据进行获取，而这一部分的资源关联数据底层平台从底层 openstack 中获取是最为准确的，所以平台侧通过异步线程技术的使用完成相关轮询逻辑的开发，在完成统一纳管租户鉴权成功后，不断通过虚机 id 等信息重复调用 openstack 项目接口，并根据获取的虚机资源数据作出相应的逻辑判断，通过这种信息同步的设计同步更新平台侧的页面，解决迁移过程中存在的数据不一致的问题，在平台侧可以为客户展示最实时准确的资源状态和信息，包括虚机关联的子网、网卡、挂载的存储等资源信息。至此完成平台侧订单到资源到信息的同步更新，从平台侧完成基于虚机和订单源信息的跨租户的虚机迁移。
本发明和现有的技术方案相比较，在虚机迁移过程中无须事先创建目的虚机，反复复制拷贝内存数据，而是将源虚机新生成的 volume 卷传送给统一纳管租户，统一纳管租户接收并利用这个 volume 卷创建目的虚机，大大提高了迁移过程中的效率，更加灵活。利用数据库脚本统一更新虚机 id 元数据和订单元数据完成对新生成额目的虚机的关联和计费，操作上简洁快速，从运营层面满足客户需求。最后通过异步线程的相关逻辑开发解决迁移过程中平台侧和底层资源信
息的不一致性，相比于从底层导数据再导入平台侧（表的数量巨大以及表的关联关系较为复杂）更加迅速和方便，出错率也较低，更加智动化的完成。

图 1：一种云平台中基于虚机和订单元信息的跨租户数据迁移实现统一纳管的方法流程图

六、本申请提案的关键点和欲保护点

基于虚机和订单元信息的跨租户数据迁移：利用源虚机的生成的快照生产新的 volume，生成目的虚机，更加灵活便捷，单台虚机的迁移过程时间短，不影响源虚机的业务正常运行；为了满足生产环境需求，利用虚机 id 源信息和订单元信息通过更新数据库完成对目的虚机的纳管和计费，从运营层面满足客户需求。同时通过轮询机制解决迁移过程中的数据不一致问题，方便快捷，且出错率较低，把通常流程中表数据的导入导出转化为更加智能的方式。

七、与第三条中最接近的现有技术相比，本申请提案有何技术优点

本发明和现有的迁移技术相比较，更加灵活地解决了虚机迁移过程耗时较久和内存需要反复复制的问题，而且不影响源虚机继续对外提供服务，一次迁移即可将源虚机上原部署的业务一并同步到目的虚机，同时解决了跨租户纳管的问题，在运营平台侧通过订单源信息和虚机源信息可将不同租户下的虚机同步纳管到一起，并完成计费，且解决数据不一致的满足生产过程中客户的需求，具有很大的实用价值。