本發(fā)明屬于計(jì)算機(jī)技術(shù)領(lǐng)域，更具體地說，尤其涉及一種虛擬機(jī)磁盤數(shù)據(jù)塊同步方法。

背景技術(shù)：

隨著基于標(biāo)準(zhǔn)x86平臺的虛擬化應(yīng)用廣泛普及，對于虛擬化的高可用(HA)方案的需求強(qiáng)烈，當(dāng)前主流的解決方案是基于傳統(tǒng)的共享存儲方案而來，如采用存儲區(qū)域網(wǎng)絡(luò)(SAN)、網(wǎng)絡(luò)附加存儲(NAS)、分布式文件存儲系統(tǒng)等。然而對于中小企業(yè)或一般性能要求的關(guān)鍵應(yīng)用場合，這種方案存在明顯不足。具體問題如下：

1.SAN/NAS存儲系統(tǒng)成本太高、關(guān)鍵設(shè)備如光纖交換機(jī)、HBA板卡完全依賴進(jìn)口。系統(tǒng)安裝調(diào)試與日常維護(hù)復(fù)雜。

2.分布式文件系統(tǒng)從概念邏輯上就非常復(fù)雜，不同的分布式文件系統(tǒng)概念、算法、架構(gòu)都有所不同，僅有少數(shù)的專業(yè)技術(shù)人才才能掌握；優(yōu)點(diǎn)是擴(kuò)展非常容易，成本低，適合互聯(lián)網(wǎng)領(lǐng)域、大型企業(yè)、政府等大規(guī)模數(shù)據(jù)中心等應(yīng)用場合。缺點(diǎn)系統(tǒng)結(jié)構(gòu)復(fù)雜、物理部署拓?fù)浣Y(jié)構(gòu)復(fù)雜、需要更多的主機(jī)、交換機(jī)、專用網(wǎng)絡(luò)。系統(tǒng)異常難以排查，維護(hù)工程師要求非常專業(yè)，由于開源的分布式存儲軟件系統(tǒng)達(dá)不到商業(yè)應(yīng)用的穩(wěn)定性,因此需要一定的定制開發(fā)才能滿足企業(yè)需求，不適合中小企業(yè)關(guān)鍵應(yīng)用場合。

基于當(dāng)前市場上常見的共享存儲系統(tǒng)和分布式存儲系統(tǒng)的應(yīng)用局限性，本發(fā)明提供一種基于虛擬化(Hypervisor)平臺的虛擬機(jī)磁盤數(shù)據(jù)塊同步方法(簡稱“虛擬數(shù)據(jù)塊同步vBlockSync”)，特別適合于中小企業(yè)的關(guān)鍵應(yīng)用場合。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的是為了解決現(xiàn)有技術(shù)中存在的缺點(diǎn)，而提出的一種虛擬機(jī)磁盤數(shù)據(jù)塊同步方法。

為實(shí)現(xiàn)上述目的，本發(fā)明提供如下技術(shù)方案：

一種虛擬機(jī)磁盤數(shù)據(jù)塊同步方法，包括如下具體步驟：

S1、虛擬機(jī)被定義為高可用模式時(shí)，虛擬化管理平臺會在不同主機(jī)上生成兩個(gè)配置完全一致的虛擬機(jī)，其中一臺為primary，一臺為secondary；虛擬機(jī)在啟動(dòng)過程中，標(biāo)識為primary的虛擬機(jī)處于running狀態(tài)，標(biāo)識為secondary的虛擬機(jī)處于paused狀態(tài)，等待數(shù)據(jù)同步；

S2、心跳系統(tǒng)網(wǎng)絡(luò)偵測隸屬在不同主機(jī)上的虛擬機(jī)運(yùn)行狀態(tài)，若primary失效，通知虛擬化管理平臺及時(shí)將primary降級為secondary，并啟用secondary為primary繼續(xù)對外提供服務(wù)；

S3、虛擬化管理平臺啟動(dòng)虛擬機(jī)時(shí)，首先運(yùn)行SyncSuit同步組件，SyncSuit同步組件在虛擬機(jī)整個(gè)運(yùn)行周期中處于運(yùn)行狀態(tài)。

S4、經(jīng)過SyncSuit同步組件的靜態(tài)同步模塊、delta同步模塊、動(dòng)態(tài)同步模塊同步后，虛擬化磁盤數(shù)據(jù)完全一致。

優(yōu)選的，所述SyncSuit同步組件，包括：

組件初始化層，負(fù)責(zé)設(shè)置SyncSuit同步組件的初始化所需參數(shù)設(shè)置、緩存區(qū)建立、初始化各功能模塊，若虛擬機(jī)為Primary，則建立tcp偵聽端口，若為secondary則建立到Primary的同步tcp鏈接；

同步策略層，根據(jù)secondary虛擬機(jī)的虛擬化磁盤狀態(tài)調(diào)用不同的功能模塊執(zhí)行對應(yīng)同步功能模塊；

功能模塊層，所述功能模塊層包括靜態(tài)同步模塊、delta同步模塊、動(dòng)態(tài)同步模塊、讀同步模塊；

網(wǎng)絡(luò)傳輸層，負(fù)責(zé)數(shù)據(jù)的網(wǎng)絡(luò)傳輸，同時(shí)提中斷檢測、中斷重連，使用tcp協(xié)議。

優(yōu)選的，所述靜態(tài)同步模塊在虛擬機(jī)啟動(dòng)前，基于虛擬機(jī)配置文件，使用rsync同步所有虛擬化磁盤，同步虛擬化磁盤時(shí)rsync軟件需要啟用checksum參數(shù)檢查。

優(yōu)選的，所述delta同步模塊在模塊初始時(shí)為每個(gè)虛擬化磁盤生成bitmap數(shù)據(jù)文件，每個(gè)bit表示512Byte磁盤塊，初始所有bit位值為’0’,若有’write’操作則置’1’；考慮效率問題，建議支持單塊虛擬化磁盤容量不超過2T。

優(yōu)選的，所述動(dòng)態(tài)同步模塊為primary虛擬機(jī)在寫數(shù)據(jù)到磁盤時(shí)，Hypervisor同步插件先將數(shù)據(jù)塊寫入本地并更新bitmap文件數(shù)據(jù)，再發(fā)送給secondary虛擬機(jī)；若secondary寫入失敗，則意味著磁盤數(shù)據(jù)不一致，同步策略層須執(zhí)行delta同步模塊。

優(yōu)選的，所述讀同步模塊：primary在讀磁盤數(shù)據(jù)時(shí)，SyncSuit同步組件先讀取primary數(shù)據(jù)并生成checksum，SyncSuit同步插件獲取secondary的對應(yīng)數(shù)據(jù)塊的checksum，若不匹配，則需要執(zhí)行靜態(tài)同步模塊后再執(zhí)行動(dòng)態(tài)同步模塊。

本發(fā)明的技術(shù)效果和優(yōu)點(diǎn)：本發(fā)明具有如下優(yōu)點(diǎn)：

1、僅須修改虛擬化(Hypervisor)平臺的block層；

2、能夠支持所有虛擬化(Hypervisor)平臺支持的操作系統(tǒng)；

3、配置、維護(hù)簡單。

本發(fā)明須修改Hypervisor(qemu)的Block層，加入SyncSuit同步組件；本發(fā)明須使用開源的rsync軟件(配置為daemon模式)作為靜態(tài)虛擬化磁盤同步工具。

附圖說明

圖1為本發(fā)明的虛擬化管理平臺拓?fù)浣Y(jié)構(gòu)圖；

圖2為本發(fā)明的SyncSuit同步組件架構(gòu)圖；

圖3為本發(fā)明的靜態(tài)磁盤同步流程圖；

圖4為本發(fā)明的虛擬化磁盤的bitmap圖

圖5為本發(fā)明的動(dòng)態(tài)同步流程圖；

圖6為本發(fā)明的delta同步流程圖；

圖7為本發(fā)明的讀同步流程圖；

具體實(shí)施方式

為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下結(jié)合具體實(shí)施例，對本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明?；诒景l(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他實(shí)施例，都屬于本發(fā)明保護(hù)的范圍。

本發(fā)明提供如圖1所示的一種虛擬機(jī)磁盤數(shù)據(jù)塊同步方法，包括如下具體步驟：

S1、虛擬機(jī)被定義為高可用模式時(shí)，虛擬化管理平臺會在不同主機(jī)上生成兩個(gè)配置完全一致的虛擬機(jī)，其中一臺為primary，一臺為secondary；虛擬機(jī)在啟動(dòng)過程中，標(biāo)識為primary的虛擬機(jī)處于running狀態(tài)，標(biāo)識為secondary的虛擬機(jī)處于paused狀態(tài)，等待數(shù)據(jù)同步；

S2、心跳系統(tǒng)網(wǎng)絡(luò)偵測隸屬在不同主機(jī)上的虛擬機(jī)運(yùn)行狀態(tài)，若primary失效，通知虛擬化管理平臺及時(shí)將primary降級為secondary，并啟用secondary為primary繼續(xù)對外提供服務(wù)；

S3、虛擬化管理平臺啟動(dòng)虛擬機(jī)時(shí)，首先運(yùn)行SyncSuit同步組件，SyncSuit同步組件在虛擬機(jī)整個(gè)運(yùn)行周期中處于運(yùn)行狀態(tài)。

S4、經(jīng)過SyncSuit同步組件的靜態(tài)同步模塊、delta同步模塊、動(dòng)態(tài)同步模塊同步后，虛擬化磁盤數(shù)據(jù)完全一致。

本發(fā)明提供如圖2所示的同步組件架構(gòu)圖，所述SyncSuit同步組件包括：

組件初始化層，負(fù)責(zé)設(shè)置SyncSuit同步組件的初始化所需參數(shù)設(shè)置、緩存區(qū)建立、初始化各功能模塊，若虛擬機(jī)為Primary，則建立tcp偵聽端口，若為secondary則建立到Primary的同步tcp鏈接；

同步策略層，根據(jù)secondary虛擬機(jī)的虛擬化磁盤狀態(tài)調(diào)用不同的功能模塊執(zhí)行對應(yīng)同步功能模塊；

功能模塊層，所述功能模塊層包括靜態(tài)同步模塊、delta同步模塊、動(dòng)態(tài)同步模塊、讀同步模塊；

網(wǎng)絡(luò)傳輸層，負(fù)責(zé)數(shù)據(jù)的網(wǎng)絡(luò)傳輸，同時(shí)提供中斷檢測、中斷重連，使用tcp協(xié)議。

如圖3所示，所述靜態(tài)同步模塊在虛擬機(jī)啟動(dòng)前，基于虛擬機(jī)配置文件，使用rsync同步所有虛擬化磁盤，同步虛擬化磁盤時(shí)rsync軟件需要啟用checksum參數(shù)檢查。

如圖4-5所示，所述delta同步模塊在模塊初始時(shí)為每個(gè)虛擬化磁盤生成bitmap數(shù)據(jù)文件，每個(gè)bit表示512Byte磁盤塊，初始所有bit位值為’0’,若有’write’操作則置’1’；考慮效率問題，建議支持單塊虛擬化磁盤容量不超過2T。

Bitmap數(shù)據(jù)文件格式說明如表1所示

表1為字段說明

1)在secondary計(jì)算機(jī)節(jié)點(diǎn)掉線或者宕機(jī)、崩潰后重新上線，加入primary/secondary模式時(shí)，比對bitmap文件，若bitmap文件為同一次運(yùn)行，則虛擬機(jī)僅同步primary/secondary的bitmap對應(yīng)磁盤數(shù)據(jù)塊的差異部分，而無需同步全盤。

2)若secondary同步時(shí)bitmap與primary不是同一次運(yùn)行；

(1)重置bitmap。

(2)執(zhí)行靜態(tài)同步模塊。

(3)同步bitmap的對應(yīng)的數(shù)據(jù)。

如圖6所示，所述動(dòng)態(tài)同步模塊為primary虛擬機(jī)在寫數(shù)據(jù)到磁盤時(shí)，Hypervisor同步插件先將數(shù)據(jù)塊寫入本地并更新bitmap文件數(shù)據(jù)，再發(fā)送給secondary虛擬機(jī)；若secondary寫入失敗，則意味著磁盤數(shù)據(jù)不一致，同步策略層須執(zhí)行delta同步模塊。

如圖7所示，所述讀同步模塊：primary在讀磁盤數(shù)據(jù)時(shí)，SyncSuit同步組件先讀取primary數(shù)據(jù)并生成checksum，SyncSuit同步插件獲取secondary的對應(yīng)數(shù)據(jù)塊的checksum，若不匹配，則需要執(zhí)行靜態(tài)同步模塊后再執(zhí)行動(dòng)態(tài)同步模塊。

最后應(yīng)說明的是：以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，盡管參照前述實(shí)施例對本發(fā)明進(jìn)行了詳細(xì)的說明，對于本領(lǐng)域的技術(shù)人員來說，其依然可以對前述各實(shí)施例所記載的技術(shù)方案進(jìn)行修改，或者對其中部分技術(shù)特征進(jìn)行等同替換,凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。