校园IT平台向云端迁移的策略研究

赵利芳

(集宁师范学院,内蒙古 集宁 012000)

0 引言

现阶段,国内互联网业务蓬勃发展,以互联网为基础的平台建设实现了在各行各业的全面渗透。以教学资源共享和在线教育为目标的校园IT平台逐渐成为校园教学建设的重要组成部分之一[1]。与其他行业相比,校园IT平台中不仅包含的数据资源规模较大,同时信息的更新频率也相对较高,同时资源的价值具有长期价值,因此,如何实现对平台信息的完整存储成了需要重点关注的问题[2]。为此,将平台进行云端迁移成了首选,通过将平台中的信息资源迁移到云端,可以实现对其完整备份,且避免了平台攻击条件下的信息安全问题。不仅如此,还可以降低平台的运行负载,提高工作效率。其中,彭军等[3]研究了一种以快速深度Q学习为基础的车载系统云迁移方法,提高了迁移的完整性,但在迁移过程中的停机时间较长；李坤妃[4]对铁路检测系统的云迁移方案进行研究,改善了迁移过程中的内存开销,但迁移的稳定性存在一定提升空间。

在平台的实际迁移过程中,稳定性的高低关系到迁移过程中信息的安全性,为此,本文就迁移过程中停机时间这一问题展开了关于校园IT平台向云端迁移的研究,并通过实验验证了所提迁移方法的有效性。通过本文的研究,以期为校园IT平台的业务联动以及平台大数据分析带去帮助。

1 校园IT平台云迁移方法

1.1 选择迁移节点

为减少迁移过程中云计算中心运行节点的数量,以最小的成本完成平台向云端的迁移,本文首先对节点的负载率迁出阈值进行设置,以待迁移校园IT平台的规模为依据,设计节点的负载率阈值,以此为基础的节点选择流程如图1所示。

从图1中可以看出,负载过低节点上的全部虚拟机是待迁移平台虚拟机的来源。由这些虚拟机共同构成平台的迁移列表。通过对云计算中心处于运行状态的节点进行遍历,对各个节点的负载率进行计算,其计算方式如下:

图1 迁移节点选择流程

其中,P表示节点的负载率,λ表示节点的传输系数,a和b分别表示节点传输队列的大小以及已经完成的传输队列大小,l表示单个待传输信息的长度。

再以设定的负载率迁出阈值为判断标准,假设云迁移的负载率阈值为Pmax,当存在P≤Pmax时,则经该节点划分为欠载节点,否则为正常负载节点,通过这样的方式,选择欠载节点进行平台的云端迁移。

1.2 平台迁移

在确定迁移的节点后,即可开展平台的迁移工作,为此,需要建立待迁平台虚拟机与迁移节点之间的匹配关系,通过这样的方式确保迁移过程中节点的负载不会出现异常,减少停机状态出现的时间。

本文首先确定平台迁移的最佳节点,以平台虚拟机请求资源与节点剩余负载资源的一致性关系作为选择标准,对迁移过程中的每个节点进行选择。由于平台虚拟机的迁移请求中涉及多种资源,为此,本文对不同资源的单项迁移成本进行计算,对不同表示方式的资源迁移需求归一化处理,方式如下:

其中,x表示平台的某个单项资源,S(*)表示归一化后的表示形式,L(*)表示对应x资源的迁移需求,节点上的剩余负载,R(*)表示平台虚拟机请求迁移的资源,T(*)表示节点上现有的资源量。

以此为基础,对平台资源与迁移节点进行匹配,匹配的目标是节点利用率最大化,同时迁移过程中经过的节点数量最小化。本文按照平台虚拟机云迁移所需总时间的长短,以升序的方式对所有待迁移的平台虚拟机进行排序,将迁移时间转化为平台虚拟机 RAM和CPU资源与迁移带宽之间的比值关系,以最小值作为迁移的实施路径,以此实现平台的云端迁移。

2 应用测试

将本文提出的平台云迁移方法应用于实际的环结构中,为此,本文在Linux 环境下搭建了OpenStack私有云环境作为迁移目标,以此为基础开展测试。

2.1 实验环境

校园IT平台虚拟机的操作系统为SUSE LINUX Enterprise Server Service Pack 3 64bit,设置有双核的CPU,64G的运行内存用于适应信息访问请求的兼容,硬盘大小为1T,用于存储平台用户的信息以及平台运行的基本逻辑编码。

2.2 云迁移搭建

在上述基础上,本文首先通过搭建OpenStack云平台实现对校园IT平台虚拟化服务的管理,使用KVMQEMU架构为下层的平台虚拟域提供基本的虚拟化服务,libtpms提供平台的完整功能数据基础。并在其中3台计算机上搭建OpenStack平台,一台作为OpenStack云平台控制节点,两台为计算节点,为了确保计算效率,为其搭载了TPM2.0芯片。除此之外的第四台计算机作为共享存储服务器,以平台存储后端的形式存在,各设备节点之间的连接是通过交换机实现的。

以此为基础,在OpenStack 的计算节点添加libtpms,通过这样的方式为QEMU提供完整的调用资源,并修改OpenStack 的代码,确保平台支持OpenStack对平台界面的管理。为了保证平台源节点虚拟机和云环境节点状态在动态迁移中的一致性,对平台进行了一次时间为0.1m的停机迁移,使二者的内存状态、CPU状态以及硬件设备状态实现同步。在此基础上,对同样资源的校园IT平台进行10次迁移,并将彭军等[3]和李坤妃[4]方法作为对照组,在相同环境下进行迁移。

2.3 试验结果

本文分别统计了3种方法迁移规程中出现的停机时间,其结果如表1所示。

表1 不同方法迁移过程中停机时间统计/ms

从表1中可以看出,在3种方法中,彭军等[3]方法的停机时间基本在20～25 ms,10次迁移的停机时间均值为22.48,相对较长；李坤妃[4]方法的停机时间波动较大,最短仅为12.69 ms,属于极为优秀的迁移,最长时间可达到26.41 ms,属于低质量迁移,10次迁移的平均停机时间为20.26 ms,基本与彭军等[3]方法持平,说明李坤妃[4]方法的稳定性较差；本文方法的停机时间始终稳定在10～13 ms阶段,最长停机时间也仅为12.31 ms,10次迁移的平均停机时间为11.20 ms,表明本文提出的云迁移方法可以实现可靠的平台迁移处理。

3 结语

目前平台的云端迁移问题已经成为确保数据信息安全,实现平台信息完成备份处理的重要方式之一,其不仅可以大大降低平台载体的运转负荷,提高使用寿命,也可以在某种程度上保证平台功能执行的稳定性。一般情况下,迁移方案主要是以特定迁移场景为目标设计的,不具有普遍适用性。本文就平台云迁移过程中的停机时间过程这一问题展开研究,并最终实现了对停机时间的有效控制。通过本文的研究,以期为提高平台云迁移的效率提供借鉴价值。