趙利芳
(集寧師范學院,內蒙古 集寧 012000)
現階段,國內互聯網業務蓬勃發展,以互聯網為基礎的平臺建設實現了在各行各業的全面滲透。以教學資源共享和在線教育為目標的校園IT平臺逐漸成為校園教學建設的重要組成部分之一[1]。與其他行業相比,校園IT平臺中不僅包含的數據資源規模較大,同時信息的更新頻率也相對較高,同時資源的價值具有長期價值,因此,如何實現對平臺信息的完整存儲成了需要重點關注的問題[2]。為此,將平臺進行云端遷移成了首選,通過將平臺中的信息資源遷移到云端,可以實現對其完整備份,且避免了平臺攻擊條件下的信息安全問題。不僅如此,還可以降低平臺的運行負載,提高工作效率。其中,彭軍等[3]研究了一種以快速深度Q學習為基礎的車載系統云遷移方法,提高了遷移的完整性,但在遷移過程中的停機時間較長;李坤妃[4]對鐵路檢測系統的云遷移方案進行研究,改善了遷移過程中的內存開銷,但遷移的穩定性存在一定提升空間。
在平臺的實際遷移過程中,穩定性的高低關系到遷移過程中信息的安全性,為此,本文就遷移過程中停機時間這一問題展開了關于校園IT平臺向云端遷移的研究,并通過實驗驗證了所提遷移方法的有效性。通過本文的研究,以期為校園IT平臺的業務聯動以及平臺大數據分析帶去幫助。
為減少遷移過程中云計算中心運行節點的數量,以最小的成本完成平臺向云端的遷移,本文首先對節點的負載率遷出閾值進行設置,以待遷移校園IT平臺的規模為依據,設計節點的負載率閾值,以此為基礎的節點選擇流程如圖1所示。
從圖1中可以看出,負載過低節點上的全部虛擬機是待遷移平臺虛擬機的來源。由這些虛擬機共同構成平臺的遷移列表。通過對云計算中心處于運行狀態的節點進行遍歷,對各個節點的負載率進行計算,其計算方式如下:
圖1 遷移節點選擇流程
其中,P表示節點的負載率,λ表示節點的傳輸系數,a和b分別表示節點傳輸隊列的大小以及已經完成的傳輸隊列大小,l表示單個待傳輸信息的長度。
再以設定的負載率遷出閾值為判斷標準,假設云遷移的負載率閾值為Pmax,當存在P≤Pmax時,則經該節點劃分為欠載節點,否則為正常負載節點,通過這樣的方式,選擇欠載節點進行平臺的云端遷移。
在確定遷移的節點后,即可開展平臺的遷移工作,為此,需要建立待遷平臺虛擬機與遷移節點之間的匹配關系,通過這樣的方式確保遷移過程中節點的負載不會出現異常,減少停機狀態出現的時間。
本文首先確定平臺遷移的最佳節點,以平臺虛擬機請求資源與節點剩余負載資源的一致性關系作為選擇標準,對遷移過程中的每個節點進行選擇。由于平臺虛擬機的遷移請求中涉及多種資源,為此,本文對不同資源的單項遷移成本進行計算,對不同表示方式的資源遷移需求歸一化處理,方式如下:
其中,x表示平臺的某個單項資源,S(*)表示歸一化后的表示形式,L(*)表示對應x資源的遷移需求,節點上的剩余負載,R(*)表示平臺虛擬機請求遷移的資源,T(*)表示節點上現有的資源量。
以此為基礎,對平臺資源與遷移節點進行匹配,匹配的目標是節點利用率最大化,同時遷移過程中經過的節點數量最小化。本文按照平臺虛擬機云遷移所需總時間的長短,以升序的方式對所有待遷移的平臺虛擬機進行排序,將遷移時間轉化為平臺虛擬機 RAM和CPU資源與遷移帶寬之間的比值關系,以最小值作為遷移的實施路徑,以此實現平臺的云端遷移。
將本文提出的平臺云遷移方法應用于實際的環結構中,為此,本文在Linux 環境下搭建了OpenStack私有云環境作為遷移目標,以此為基礎開展測試。
校園IT平臺虛擬機的操作系統為SUSE LINUX Enterprise Server Service Pack 3 64bit,設置有雙核的CPU,64G的運行內存用于適應信息訪問請求的兼容,硬盤大小為1T,用于存儲平臺用戶的信息以及平臺運行的基本邏輯編碼。
在上述基礎上,本文首先通過搭建OpenStack云平臺實現對校園IT平臺虛擬化服務的管理,使用KVMQEMU架構為下層的平臺虛擬域提供基本的虛擬化服務,libtpms提供平臺的完整功能數據基礎。并在其中3臺計算機上搭建OpenStack平臺,一臺作為OpenStack云平臺控制節點,兩臺為計算節點,為了確保計算效率,為其搭載了TPM2.0芯片。除此之外的第四臺計算機作為共享存儲服務器,以平臺存儲后端的形式存在,各設備節點之間的連接是通過交換機實現的。
以此為基礎,在OpenStack 的計算節點添加libtpms,通過這樣的方式為QEMU提供完整的調用資源,并修改OpenStack 的代碼,確保平臺支持OpenStack對平臺界面的管理。為了保證平臺源節點虛擬機和云環境節點狀態在動態遷移中的一致性,對平臺進行了一次時間為0.1m的停機遷移,使二者的內存狀態、CPU狀態以及硬件設備狀態實現同步。在此基礎上,對同樣資源的校園IT平臺進行10次遷移,并將彭軍等[3]和李坤妃[4]方法作為對照組,在相同環境下進行遷移。
本文分別統計了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,表明本文提出的云遷移方法可以實現可靠的平臺遷移處理。
目前平臺的云端遷移問題已經成為確保數據信息安全,實現平臺信息完成備份處理的重要方式之一,其不僅可以大大降低平臺載體的運轉負荷,提高使用壽命,也可以在某種程度上保證平臺功能執行的穩定性。一般情況下,遷移方案主要是以特定遷移場景為目標設計的,不具有普遍適用性。本文就平臺云遷移過程中的停機時間過程這一問題展開研究,并最終實現了對停機時間的有效控制。通過本文的研究,以期為提高平臺云遷移的效率提供借鑒價值。