面向OpenStack/Ceph的虛擬機備份系統研究①

楊皓森,胡曉勤,黃傳波

1(四川大學 計算機學院,成都 610065)

2(成都云祺科技有限公司,成都 610041)

近年來,虛擬化與云計算的浪潮席卷了整個IT行業,引領了IT基礎設施的發展以及產業的革新.OpenStack[1]是目前使用最為廣泛的開源云計算平臺,可幫助企業實現構建自己的云基礎架構服務.OpenStack可利用多種虛擬化平臺提供虛擬機服務,如Vmware、KVM[2]等,虛擬機在OpenStack中會作為云主機展示給用戶.

Ceph[3]是一種性能優秀、服務穩定且可擴展的開源分布式存儲系統,作為軟件定義存儲(SDS)[4]領域的代表,可以整合多種傳統存儲方式并進行統一配置管理,與OpenStack形成了良好的搭配,也是其目前使用最普遍的塊存儲方式.

根據2017年4月的OpenStack用戶調查報告顯示,擁有的虛擬機數量100臺以上的環境比例高達74%[5].由于用戶大量的數據和業務運行在虛擬機之上,保障虛擬機的數據安全成為了OpenStack面臨的迫切問題[6].

虛擬機備份與簡單的快照不同,它要求能保存虛擬機任意快照點的數據和狀態,可在本地或異地存儲這些數據,在生產環境發生災難或者人工操作失誤時,能夠利用原數據進行恢復,降低損失.其它大型虛擬化廠商,如 Vmware、Redhat、XenServer等,市面上都有針對自身產品的虛擬機備份方案,而OpenStack由于其作為云計算平臺的復雜性,并且沒有完善相應的接口,因此在虛擬機備份功能上一直進展緩慢,其快照備份功能,對于有具體環境備份需求的用戶來說,功能過于單一,且時間和存儲空間開銷較大,因此在實際部署中并不適用.

為此,本文提出一種面向OpenStack/Ceph的虛擬機備份系統,基于Ceph存儲快照,計算出虛擬機磁盤對象的有效數據或變化數據區域,讀取磁盤數據并按快照點的順序保存至備份服務器,同時保存原虛擬機的硬件配置、元數據等信息; 在恢復時,創建一個配置相同的新虛擬機并將所選快照點的數據恢復到新的磁盤.實驗結果表明,該系統比OpenStack的虛擬機快照備份功能,可有效降低備份時間,節省備份數據存儲空間,可以實現后者不具有的增量備份[7]等功能,同時滿足對虛擬機根磁盤、臨時磁盤、掛載云硬盤的數據備份.該方法不需修改OpenStack原生內容,不會對用戶的生產環境造成影響.

1 相關研究

1.1 OpenStack現有備份功能

OpenStack是基于多個模塊協同工作的云計算平臺,其內部接口參照亞馬遜AWS[8].OpenStack虛擬機的磁盤數據保存于根磁盤(Root Disk)、臨時磁盤(Ephemeral Disk)和掛載的云硬盤(Volumes).

OpenStack現有的的虛擬機快照備份功能是對虛擬機根磁盤進行轉換和拷貝,不支持增量備份,備份時間長,冗余數據多,虛擬機的臨時磁盤、掛載的云硬盤無法得到有效備份.新的虛擬機只能利用上傳的根磁盤鏡像創建,一旦出現災難或者人工失誤操作,容易造成大量數據丟失.而OpenStack提供的Cinder-backup服務目前只能實現對云硬盤的備份且有諸多限制條件,也無法滿足對虛擬機整機的有效保護.

1.2 Ceph RBD快照

Ceph是一個多節點的分布式系統,提供統一的存儲訪問接口.Ceph的節點可分為Monitor節點與OSD節點,OSD節點用于存儲和查詢對象,Monitor節點用于維護集群成員的狀態.

按照模塊劃分,Ceph最底層模塊是RADOS (Reliable,Autonomic Distributed Object Store),通過CRUSH算法[9]保證數據均衡存儲于各個OSD節點.在RADOS之上有多個模塊對其功能進行了封裝與拓展,其中OpenStack主要使用到的模塊為Ceph RBD(Reliable Block Device),即Ceph的塊存儲服務[3].

以Ceph為塊存儲后端的OpenStack環境,每個磁盤均對應一個RBD對象,磁盤格式采用RAW[10],RAW格式磁盤在Ceph中只保存已劃分空間部分,節省了存儲空間.Ceph RBD支持對塊設備生成快照[11],采用COW (Copy-On-Write)機制,即寫時拷貝,可在任意時間點以秒級速度創建快照,不對塊設備的使用造成影響,使每個快照點的數據都能保存并且不會復制冗余數據,其功能類似于QCOW2磁盤的快照功能[12].

2 系統設計

鑒于虛擬機備份對OpenStack環境的安全有著重要的作用,而其快照備份方法不能滿足備份的需要,本文提出一種面向OpenStack/Ceph的虛擬機備份系統.系統分為服務端和代理端,包含6個模塊: 磁盤處理模塊、通信模塊、備份模塊、恢復模塊、數據存儲模塊、虛擬機管理模塊,如圖1所示,備份模塊和恢復模塊通過調用虛擬機管理模塊獲取原虛擬機配置信息、創建新虛擬機等,通過通信模塊與磁盤處理模塊通信,傳輸磁盤有效數據或增量數據,然后調用數據存儲模塊寫入或讀取備份數據.其中代理端安裝在環境里每個計算節點,服務端安裝在單獨的備份服務器上.

圖1 系統模塊圖

本文備份系統涉及到OpenStack環境的存儲、管理、公開三種網絡,如圖2所示.管理網絡用于服務端與OpenStack控制節點通信,管理控制OpenStack環境,管理網絡還用于獲取虛擬機信息、傳輸備份恢復數據; 存儲網絡用于代理端讀取、寫入、查詢存儲在Ceph環境中的磁盤數據; 公開網絡使用戶可以從外部訪問備份服務器,控制備份和恢復任務.

3 系統實現

3.1 備份模塊

備份模塊通過調用其它基礎模塊,控制備份任務的流程.當OpenStack環境加入到備份系統時,會首先通過虛擬機管理模塊獲取所有虛擬機的狀態列表,用戶可以選擇某臺或多臺虛擬機創建備份任務,備份任務可以分為全量備份、增量備份兩種方式,備份模塊有不同的處理方式.

任務創建完成后,后續流程均由備份模塊控制,用戶不需要再操作,備份的具體步驟如下.

1) 根據任務類型和狀態,如果是全量備份任務,則直接執行全量備份; 如果是增量備份任務,第一個備份點也是全量備份,后續增量備份點均依賴于前一個備份點執行;

2) 通過虛擬機管理模塊獲取虛擬機的詳細配置以及磁盤列表,包括根磁盤、臨時磁盤以及掛載的云硬盤,獲取所有磁盤的存儲路徑;

3) 對于磁盤列表中的每一個磁盤,根據磁盤路徑,調用磁盤處理模塊創建當前時間點Tn的快照,記錄快照的ID等信息;

圖2 系統網絡拓撲

4) 通過磁盤處理模塊,如果是全量備份點,根據Tn時刻的快照計算每個磁盤的全量數據Bitmap,如果是增量備份點,結合Tn–1和Tn時刻的快照計算每個磁盤的增量數據Bitmap;

5) 根據備份任務類型,選擇不同的Bitmap用于數據備份,調用通信模塊進行傳輸,調用數據存儲模塊保存磁盤數據;

6) 等待所有磁盤數據備份完成,將虛擬機的配置信息保存至數據庫或文件;

7) 如果是全量備份任務,刪除Tn時刻的快照; 如果是增量備份任務,刪除Tn–1時刻的快照,保留Tn時刻的快照,備份任務完成.

3.2 恢復模塊

與備份模塊相似,恢復模塊也是通過調用其它模塊,控制恢復的流程.主要包含創建虛擬機、寫磁盤數據兩部分.新虛擬機名、可用域和網絡等設置為可選項.通過創建相同配置的新虛擬機并將備份數據寫入覆蓋到新虛擬機的磁盤,可以實現整機數據恢復.數據恢復過程中虛擬機需要是關機狀態,整個恢復的步驟如下.

1) 用戶選擇需要恢復哪臺虛擬機以及哪個時間點;

2) 通過虛擬機管理模塊獲取可恢復到的環境和租戶,驗證用戶在該租戶內是否有權限;

3) 獲取所選租戶內可選網絡和可用域,允許用戶配置新虛擬機的名稱、網絡和可用域等選項;

4) 根據保存的原機云主機類型和云硬盤掛載信息,調用虛擬機管理模塊創建與原虛擬機硬件配置相同的新虛擬機,保證與原機磁盤數量、大小、掛載順序一致,然后獲取新虛擬機的磁盤列表和路徑信息;

5) 按照磁盤列表,將新虛擬機與原虛擬機的磁盤一一對應,針對每一對磁盤,從數據存儲模塊,根據所選時間點原磁盤的Bitmap信息依次讀取有效數據塊,再調用磁盤處理模塊寫入覆蓋新磁盤相同的偏移位置;

6) 等待所有磁盤數據恢復完成,任務成功.

3.3 通信模塊

通信模塊基于TCP/IP協議,提供備份服務器與計算節點的通信基礎,負責備份服務器與不同計算節點之間通信數據包的轉發和分配,該模塊提供對三種數據的傳輸,分別是虛擬化平臺的命令和返回信息、磁盤操作的處理和回饋、備份恢復數據的請求和傳輸.

為滿足不同的消息請求,可以通過構造自定義的多級包頭加以區分,比如操作消息可以通過在包頭定義操作碼,備份服務端和代理端再通過分析操作碼對數據部分做不同的操作.在傳輸時要保證數據傳輸的正確性,可以構造待發送的數據包隊列,平衡處理各節點間的通信任務.

3.4 虛擬機管理模塊

虛擬機管理模塊用于處理與OpenStack云計算平臺的連接、驗證權限,獲取云計算平臺的相關信息,創建、刪除虛擬機,獲取虛擬機配置,磁盤列表和路徑等.該模塊是系統與OpenStack環境通信的基礎.

OpenStack包含有Keystone,Cinder,Nova,Glance等各種組件,每個組件提供不同的服務,占用不同的端口[13].要與這些服務通信,需要先獲取權限,OpenStack將用戶劃分為不同的權限級別,且用戶與租戶相關,需選擇一個具有Admin權限的用戶并通過Keystone服務認證.

完成認證后,可通過Nova等服務獲取所有虛擬機的詳細信息,包括虛擬機的硬件配置以及運行狀況,磁盤列表和路徑,用于備份和恢復任務.創建新虛擬機時需保證與原機的配置相同,結合用戶可選的虛擬機名稱、網絡等信息,再通過Nova和Cinder服務創建完成.

3.5 磁盤處理模塊

磁盤處理模塊位于每一個計算節點,用于管理與Ceph環境的連接、生成快照、計算快照點Bitmap、讀取和寫入磁盤數據等.

本系統邏輯上將磁盤劃分為固定大小的數據塊,對每個磁盤生成一個Bitmap,每一個bit對應一個數據塊.Ceph提供了返回單個快照點內全部有效數據段或兩個快照點間變化數據段的接口,可計算出全量數據Bitmap或增量數據Bitmap,前者描述完整磁盤的有效數據,后者描述磁盤兩個快照點之間的變化數據.

本系統在計算Bitmap時將磁盤劃分為多個較長的數據段,一個數據段包含若干數據塊,通過Ceph獲取每個數據段內的有效數據或變化數據信息,再計算生成每個數據段的Bitmap,最終合并出磁盤的完整Bitmap.數據段的長度可采用Ceph的分段上限.計算數據段的Bitmap方法如圖3所示.

以某個數據段f為例,其在文件中的偏移為offset,長度為length,對應n個數據塊,數據塊編號從0到n–1,則分塊長度為length/n.對于某一段有效數據,假設其偏移和長度分別為S和L,對于第i個數據塊,如果存在:

則說明數據塊內包含該段有效數據,將Bitmap內第i個bit置為1.計算完成所有數據段之后,即可合并出整個磁盤快照點的Bitmap.備份時,只需對其中bit為1的數據塊,計算出其在磁盤文件中的偏移,再從Ceph中按塊的偏移和長度讀取即可,避免了對無效數據區的備份,節約了備份時間和空間,采用增量數據Bimtap傳輸數據可以實現增量備份的效果.

3.6 數據存儲模塊

數據存儲模塊負責保存虛擬機磁盤快照點的備份數據,保存數據的方式采用固定的結構和方法.存儲結構上,需按照存儲根目錄、虛擬機、快照時間點和磁盤的層次,快照時間點和磁盤通過生成ID的方式加以區分.每一個快照點內保存有所有磁盤的存儲數據文件、索引文件、元數據等信息.目錄結構如圖4所示.

圖4 存儲目錄結構

存儲數據文件保存全量備份點的有效數據塊,或增量快照點的變化數據塊,所有數據塊擁有同樣的塊大小,按順序寫入存儲數據文件中.元數據保存了磁盤ID、依賴快照點ID等信息.索引文件是根據磁盤快照點計算的Bitmap生成的,每一行的格式為”bit|offset”,bit是指該數據塊是否為磁盤當前快照點的有效數據塊或增量數據塊,與Bitmap里的值相同,offset指數據塊在存儲數據文件中的偏移,如果當前沒有保存該塊,則偏移為0.

當進行備份時,需要寫入數據.首先按照目錄結構創建正確的路徑; 針對每一個磁盤,通過磁盤處理模塊計算該快照點的全量或增量Bitmap; 循環處理每一個bit位,如果bit為1,則傳輸對應的數據塊,按順序寫入存儲數據文件,如果bit為0,則不需要傳輸,同時應記錄該bit的值和數據塊在存儲數據文件中的偏移,并保存至索引文件,不需傳輸的塊偏移置為0; 最后,記錄磁盤的依賴快照點、磁盤大小等元數據信息.

當進行恢復時,針對每一個磁盤,根據元數據信息獲取完整的快照鏈關系,然后合并所有索引文件的Bitmap信息,合并方式為某數據塊如果在任意時間點的bit為1,那么合并后該數據塊bit也置為1.根據合并后的Bitmap,對bit為1的數據塊,從最近時間點開始讀取,如果該時間點未保存有該數據塊,即索引文件的偏移為0,則向前一個時間點繼續讀取,以此類推.最終可得到完整的磁盤數據.

以一個磁盤的增量快照鏈為例,如圖5所示,增量點T2依賴于增量點T1,增量點T1依賴于全量點T0,每個快照點保存有索引文件、元數據、存儲數據文件.按照從左到右的順序編號,有數據塊0到15.備份時,根據T2時刻計算出的增量數據Bitmap,數據塊5、10、11的數據有變化,所以當前只需要備份這三個數據塊,將數據寫入到有效數據文件,并記錄偏移offset.

圖5 備份數據存儲方式

恢復時,首先根據快照鏈關系,合并T0、T1、T2的Bitmap,得到T2時刻磁盤的完整數據Bitmap,即數據塊2、5、8、10、11、15的bit都為1,再根據完整數據Bitmap從存儲數據文件讀取數據塊,優先從最近時間點開始讀,如果沒有查詢到該數據塊,則從依賴快照點中讀,以此類推.圖5例中,首先會從增量點T2讀取數據塊5、10、11,然后從增量點T1讀取數據塊15、從全量點T0讀取數據塊2、8,最終即可得到T2時刻磁盤的完整數據.

4 實驗分析

4.1 數據存儲模塊

實驗環境參照圖2的網絡拓撲,OpenStack版本號為Mitaka,虛擬機磁盤格式為RAW; 備份服務端安裝在獨立主機上,代理端安裝于OpenStack所有計算節點上.實驗采用OpenStack虛擬機快照備份功能作為對比方法,實驗對象選用云環境內不同操作系統、不同系統配置的虛擬機,配置包含單磁盤、多磁盤等多種方式,本文系統分塊大小為2 MB.

4.2 實驗結果分析

為測試備份系統虛擬機的增量數據備份,創建一臺擁有10 GB根磁盤的虛擬機,操作系統為最小化安裝的Centos7.3,先用dd命令寫入5.1 GB非0數據擴充根磁盤大小,在T0時刻做一次全量備份,由于都是提取的有效數據,兩種方法全量備份的效果相同,然后自T1時刻起向根磁盤連續寫入測試數據并做增量備份,如表1所示.測試數據采用不同版本的Linux內核tar.gz壓縮文件,版本號依次為Linux-2.6.39.2、Linux-3.6.9、Linux-3.8.2、Linux-3.12.69、Linux-4.6.3、Linux-4.9.88.

實驗結果表明,本文提出的備份系統可針對變化數據使用增量備份,而OpenStack快照備份只能對根磁盤做全量備份,故備份大小約等于根磁盤已分配大小.根磁盤增量數據備份傳輸的大小和時間對比如圖6所示,無論是節省備份時間還是存儲空間,本文系統均優于OpenStack的快照備份方式,實驗中本文系統平均節約了88.72%的備份時間和97.14%的備份存儲空間,在變化數據相對于磁盤已分配空間較小時,本文系統的優勢更加明顯.

表1 根磁盤增量數據備份

圖6 根磁盤增量備份對比

為測試多磁盤的備份情況,創建一臺擁有10 GB根磁盤、10 GB臨時磁盤、10 GB云硬盤的虛擬機,對比OpenStack快照備份方法,實驗全量備份、增量備份任務,實驗結果表明,本文提出的備份系統可針對多磁盤虛擬機實現有效保護,對臨時磁盤、云硬盤均可實現全量和增量備份,備份效果與根磁盤相同.與OpenStack快照備份的功能對比如表2所示,在恢復測試中,每個時間點所有磁盤的數據均能正確恢復到新虛擬機.

表2 多磁盤備份功能對比

5 結語

本文針對以Ceph RBD作為后端塊存儲方法的OpenStack環境,設計并實現了一種利用Ceph快照特點的虛擬機備份系統,實驗結果表明,相比于OpenStack的虛擬機快照功能,本系統可以實現后者不具有的虛擬機整機的數據保護功能,包括對虛擬機配置信息的保存、多磁盤數據的備份,可以實現跨用戶、跨租戶的恢復,通過計算變化數據可以實現增量備份,有效節約了備份時間和存儲空間.但本系統的增量備份會保留一個快照,備份速度和增量計算精度與分塊大小相關,備份數據也可以通過存儲網絡傳輸,后續可以做進一步優化和改進.