一種多策略雙機熱備方法

，，，，

(南瑞集團有限公司(國網(wǎng)電力科學(xué)研究院有限公司)，南京 210003)

0 引言

在電網(wǎng)監(jiān)控系統(tǒng)中，隨著核心業(yè)務(wù)的不斷增加，系統(tǒng)對應(yīng)用服務(wù)的實時性和穩(wěn)定性都提出了嚴格要求[1]，既要保證服務(wù)的全天候執(zhí)行，也要保證內(nèi)存資源的高度一致，而物理鏈路、網(wǎng)絡(luò)故障、程序異常等都會導(dǎo)致服務(wù)中斷，甚至系統(tǒng)癱瘓，因此系統(tǒng)的高可用性或容錯性能一直作為監(jiān)控領(lǐng)域重要指標之一。高可用解決方案有多種，如高端容錯主機、集群(cluster)、雙機熱備(Hot standby)等。其中高端容錯主機完全基于硬件，成本極高，適用于對容錯有很高要求的應(yīng)用；集群技術(shù)是利用網(wǎng)絡(luò)將一組相互獨立的服務(wù)器互聯(lián)，并以單一系統(tǒng)的模式加以管理以提供系統(tǒng)高可用性的服務(wù)，集群技術(shù)偏重于解決負載均衡、并行計算等問題，部署相對復(fù)雜，且易造成內(nèi)存數(shù)據(jù)的不一致；雙機熱備系統(tǒng)作為高可用集群的最小單元，是將主服務(wù)器部署成互為備份的兩臺服務(wù)器，當其中運行著的一臺服務(wù)器出現(xiàn)故障無法啟動時，另一臺備份服務(wù)器會迅速的自動切換，接管服務(wù)，從而達到程序和數(shù)據(jù)的備份，系統(tǒng)投資小、部署簡單，適用于實時處理系統(tǒng)中?？梢婋p機熱備是電網(wǎng)監(jiān)控中保持系統(tǒng)實時性、穩(wěn)定性的優(yōu)選方案。

雙機熱備主要分為兩類：基于共享存儲的方式以及純軟件方式[2]，前者是利用磁盤陣列保障數(shù)據(jù)的連續(xù)完整，后者是利用鏡像軟件實現(xiàn)數(shù)據(jù)以及程序的復(fù)制備份從而保障系統(tǒng)安全，它們雖保證系統(tǒng)穩(wěn)定的方式不一樣，但故障判斷方式基本一致，通常采用心跳檢測。本文主要對目前熱備方案中的心跳以及切換機制存在的缺點進行研究，并給出優(yōu)化方案。采用服務(wù)間HeartBeat協(xié)議以及與數(shù)據(jù)庫時間同步相結(jié)合方法取代單一心跳所帶來的診斷不確定性，避免“裂腦”(split-brain)問題的出現(xiàn)[3]；利用IP校驗與布爾值權(quán)限標識取代虛擬IP(VIP)，完成服務(wù)接管。該方法無需配置任何系統(tǒng)參數(shù)，部署簡單，故障判斷準確，實現(xiàn)無縫切換。

1 傳統(tǒng)雙機熱備機制

目前，雙機熱備作為一種提高系統(tǒng)高可用性方法，已擁有較多產(chǎn)品，根據(jù)不同應(yīng)用可劃分3種工作模式：雙機主從模式(active/standby)、雙機互備模式、雙機雙工模式(active/active)，雙機主從模式指主服務(wù)器處于服務(wù)狀態(tài)，而備服務(wù)器處于偵測準備狀態(tài)；雙機互備模式是指部分服務(wù)運行于主機，部分服務(wù)運行于備機；雙機雙工模式是指系統(tǒng)兩臺服務(wù)器同時運行，實現(xiàn)負載均衡。很多熱備開源軟件都是基于經(jīng)典熱備協(xié)議VRRP[4]、HSRP[5]進行開發(fā)，比如Linux-HA[6]。傳統(tǒng)雙機熱備是通過主備節(jié)點服務(wù)器間心跳機制(HeartBeat)檢測彼此狀態(tài)，若備節(jié)點服務(wù)器認定主節(jié)點異常，就會接管主節(jié)點全部功能并對外提供服務(wù)[7-8]。在熱備中，心跳協(xié)議以及相關(guān)算法一直是熱備研究的熱門領(lǐng)域，現(xiàn)已有較多研究成果以及應(yīng)用。在文獻[9]中，描述了利用心跳機制解決了異構(gòu)集群中節(jié)點超時設(shè)置的公平性，縮短了Hadoop實時處理系統(tǒng)在短作業(yè)下的容錯時間；在文獻[10-11]中，采用虛擬化心跳算法監(jiān)測網(wǎng)絡(luò)，實現(xiàn)了數(shù)據(jù)中心虛擬化系統(tǒng)的網(wǎng)絡(luò)狀態(tài)監(jiān)測；在文獻[12]中，采用心跳包實現(xiàn)了CAN工業(yè)總線的高可用。這些應(yīng)用表明目前心跳技術(shù)已趨于成熟，但也體現(xiàn)出絕大部分還停留在對協(xié)議本身的研究，沒有從運行架構(gòu)上對熱備方法進行優(yōu)化。

根據(jù)以上應(yīng)用分析，可以看出傳統(tǒng)的雙機熱備機制心跳鏈路單一，輸出結(jié)果可靠性較低，無法有效判斷是網(wǎng)絡(luò)故障還是服務(wù)故障，易出現(xiàn)服務(wù)競爭風(fēng)險。雖Fencing和Quorum機制可有效防止這一風(fēng)險，但是這兩種方法可能會引入新的節(jié)點故障問題，另外他們對網(wǎng)絡(luò)設(shè)備的雙機熱備不通用[3]。

2 多策略雙機熱備框架

為了解決傳統(tǒng)雙機熱備方案中潛在的“裂腦”問題以及保證主備服務(wù)切換準確無誤，多決策雙機熱備方法不再完全依賴于節(jié)點間單一心跳鏈路檢測，而是通過第三方?jīng)Q策介質(zhì)-數(shù)據(jù)庫，實現(xiàn)多重“心跳”判斷，交叉檢測，再利用IP雙向校驗實現(xiàn)服務(wù)接管，該方法可部署于電網(wǎng)監(jiān)控系統(tǒng)常用架構(gòu)中，不增加任何額外物理資源以及不使用任何第三方輔助軟件，由內(nèi)置的低耦合線程完成全部熱備服務(wù)流程。圖1為多策略熱備架構(gòu)圖，它由3個決策實體組成：主節(jié)點應(yīng)用服務(wù)器、備節(jié)點應(yīng)用服務(wù)器和數(shù)據(jù)庫。主備服務(wù)器采用Linux操作系統(tǒng)，數(shù)據(jù)庫采用ORACLE，程序?qū)Ψ?wù)器配置無依賴。

圖1 多策略熱備架構(gòu)圖

由圖可知，多策略熱備架構(gòu)中，同時部署運行2臺應(yīng)用服務(wù)器，工作于雙機主從模式，主備服務(wù)器之間建立心跳鏈路，根據(jù)心跳協(xié)議定時發(fā)送Heartbeat報文，與此同時，數(shù)據(jù)庫作為中間輔助介質(zhì)，默認主節(jié)點會按一定時間間隔向其同步相關(guān)信息，包括節(jié)點號、IP地址以及同步時間，內(nèi)部心跳故障后，備節(jié)點會主動查詢數(shù)據(jù)庫同步時間，該過程完成報文應(yīng)答和時間超時校驗的交叉檢測，即多策略心跳偵測機制。若主節(jié)點因某種原因宕機，備節(jié)點將主動獲得數(shù)據(jù)庫使用權(quán)，并更新數(shù)據(jù)庫時間，且根據(jù)布爾輸出值獲得本節(jié)點對外服務(wù)權(quán)，備節(jié)點無縫切換成“主”節(jié)點，該過程形成多策略IP接管機制。

在上述架構(gòu)中，服務(wù)節(jié)點均以實體IP對外提供服務(wù)，優(yōu)化了傳統(tǒng)虛擬IP切換所帶來的對不同腳本的維護缺點。主備服務(wù)器中應(yīng)用程序同時運行，資源數(shù)據(jù)和性能數(shù)據(jù)互為備份，主備機具有相同的內(nèi)部資源交換以及接收外部服務(wù)、請求功能，但只有主機能夠?qū)ν馓峁┓?wù)，包括讀寫數(shù)據(jù)庫，向WEB端發(fā)送數(shù)據(jù)等。

3 關(guān)鍵技術(shù)

3.1 定時器設(shè)計

定時器作為一種時鐘裝置，對軟件中斷服務(wù)至關(guān)重要，衡量其性能的指標包括：啟停時間，處理Tick時間以及超時事件處理時間。對于少量定時器創(chuàng)建，一般操作系統(tǒng)能夠較好解決，但程序中有大量定時器創(chuàng)建、刪除時，系統(tǒng)定時器的可靠性將很難控制。傳統(tǒng)的定時器數(shù)據(jù)結(jié)構(gòu)通常采用鏈表方式，按照時間先后順序存儲相應(yīng)事件，時間復(fù)雜度為O(n)，算法執(zhí)行時間較長。多策略機制中的雙重心跳檢測以及接管服務(wù)狀態(tài)切換需要高性能的定時裝置，定時器的精度成為保證心跳報文定時發(fā)送以及狀態(tài)機跳轉(zhuǎn)的關(guān)鍵。為保證雙機熱備性能，提高時鐘管理效率，重點研究了一種提高定時精度的數(shù)據(jù)結(jié)構(gòu)，它由定時器信息塊、定時器資源池以及忙定時器三部分組成。

定時器信息塊(Timer Information Block，TMIB)存儲所創(chuàng)建的定時器信息，對應(yīng)數(shù)據(jù)結(jié)構(gòu)為：TMIB={use,arrived,type,que,pno,totoal_100m,timer_no, que10,que100,prev,next}，其中prev指向前一個定時器信息塊，next指向下一個定時器信息塊。

定時器資源池(Timer Resource Pool，TMRP)記錄所創(chuàng)建定時器數(shù)目，以及允許使用的定時器起始和終點，對應(yīng)數(shù)據(jù)結(jié)構(gòu)為：TMRP={total,head,end,tm[NUM]}，其中total記錄程序中可用定時器數(shù)目，初始值為NUM，隨著定時器不斷被創(chuàng)建，total不斷遞減，而隨著定時器到期，該值又不斷遞增；head記錄可使用定時器隊列的起始位置，這樣保證定時器始終在該值處開始創(chuàng)建；end為閑置定時器結(jié)束位置，當定時器到期釋放時，定時器信息塊為TMRP->tm[TMRP->end]，這樣可保證定時器資源池的循環(huán)使用；tm[NUM]存儲定時器信息，該信息塊是循環(huán)結(jié)構(gòu)，從TMRP->head開始，到TMRP->end結(jié)束，在這之間的所有定時器都可被分配使用。

忙定時器(Busy timer，BTM)是以隊列形式記錄正在使用的定時器，與定時器資源池結(jié)構(gòu)相類似，BTM結(jié)構(gòu)體中也包含haed、end成員，從而保證忙定時器資源的循序利用。圖2為定時器創(chuàng)建使用時，TMRP與TMIB成員以及數(shù)據(jù)對應(yīng)關(guān)系。

圖2 TMRP與TMIB對應(yīng)關(guān)系圖

圖2中展示了定時器被創(chuàng)建過程(灰色表示忙定時器，白色表示空閑定時器)。定時器初始化時，NUM全為可用定時器，隨著定時器的創(chuàng)建和使用，head成員不斷改變指向位置，但始終指向空閑定時控制隊列頭，同時total成員的數(shù)量逐步遞減，圖中創(chuàng)建了m個定時器后(m

圖3展示了定時器繼續(xù)被創(chuàng)建以及有定時器被釋放過程。若繼續(xù)創(chuàng)建了兩個定時器，他們啟用TMRP[tm[m]]和TMRP[tm[m+1]]兩個閑置定時器位置，此時，TMRP中的head成員將指向定時器資源池的tm數(shù)組第m+2個定時器信息塊位置。與此同時，若有兩個定時器到到期后需退出，假設(shè)釋放出TMIB[1]和TMIB[3]兩個定時器控制塊。那么，資源池將接管這兩個控制塊使用權(quán)，即從TMRP->end位置開始，將這兩個已閑置的信息塊保存到TMRP的 tm數(shù)組成員中。如圖所示，TMIB[1]和TMIB[3]將插入到TMRP[tm[0]]和TMRP[tm[1]]的隊列中，并將TMRP->end的位置往后移兩位?？梢?，無論TMIB中的定時器如何改變， TMRP結(jié)構(gòu)體中將始終保持閑置的定時器控制隊列(白色部分)和已經(jīng)被使用定時控制隊列(灰色部分)兩個區(qū)域連續(xù)。

圖3 定時器創(chuàng)建與釋放示意圖

以上數(shù)據(jù)結(jié)構(gòu)使定時器的精度、數(shù)目變得靈活，可滿足同步延時、相對定時、以及絕對定時等定時器的需要，提高了定時服務(wù)性能，為多策略雙機熱備程序中鏈路心跳、時間同步以及狀態(tài)定時跳轉(zhuǎn)提供了精準的時鐘管理服務(wù)。

3.2 雙重心跳機制

在雙機熱備中，故障檢測是軟件程序的基本功能，其檢測點的多少直接關(guān)系到熱備的性能，對于實時應(yīng)用系統(tǒng)的熱備需求，用戶需要一種性能穩(wěn)定可靠，部署簡單且廉價的方案，而傳統(tǒng)雙機熱備，通常采用單一心跳檢測作為判斷服務(wù)故障狀態(tài)依據(jù)，在實際應(yīng)用中容易出現(xiàn)服務(wù)競爭，造成“裂腦問題”，進而使數(shù)據(jù)庫產(chǎn)生大量垃圾數(shù)據(jù)，甚至導(dǎo)致數(shù)據(jù)的嚴重不一致，這在電網(wǎng)系統(tǒng)中是絕對避免的。雙重心跳機制優(yōu)化了單一心跳缺點，采用多點交叉檢測，檢測邏輯強相關(guān)，與應(yīng)用程序耦合性低，避免了“裂腦”發(fā)生，實現(xiàn)故障的精準自判斷。圖4為雙重心跳邏輯示意圖。

圖4 雙重心跳邏輯示意圖

如圖4所示，2臺應(yīng)用服務(wù)器間采用HeartBeat協(xié)議，備節(jié)點主動發(fā)送hello心跳報包到主節(jié)點，每5秒發(fā)送一次，若連續(xù)20次沒收到主節(jié)點響應(yīng)，則可確定主備之間心跳鏈路異常，以此作為第一次心跳檢測，此時無法判斷主節(jié)點服務(wù)確切狀態(tài)，服務(wù)此時未發(fā)生切換。隨后，備節(jié)點檢查數(shù)據(jù)庫，進入第二次“心跳”檢測即時間同步機制。

在oracle數(shù)據(jù)庫中建立tb_main_node(node,ip_addr,latest_update_time)服務(wù)節(jié)點表，如下表所示。

表1 服務(wù)節(jié)點表

其中node為主備節(jié)點標識(邏輯標識，代表不同IP地址)，這在主備程序配置文件中人為定義，ip_addr為節(jié)點ip地址，node與ip_addr一一對應(yīng)，latest_update_time為節(jié)點與數(shù)據(jù)庫的同步時間，格式為“年-月-日 時:分”。主節(jié)點應(yīng)用程序每分鐘調(diào)用OCI接口更新服務(wù)節(jié)點表中的索引latest_update_time值，實現(xiàn)應(yīng)用程序節(jié)點時間與數(shù)據(jù)庫的同步。當?shù)谝淮涡奶鴻z測異常后，備節(jié)點開始查詢tb_main_node中的latest_update_time 值，若檢測到latest_update_time 延時于備機時間60 s，則可以確切判斷主機節(jié)點服務(wù)宕機，輸出布爾結(jié)果值；反之，則主備節(jié)點服務(wù)正常，只是心跳鏈路異常。主服務(wù)宕機后，備節(jié)點用自身信息更新服務(wù)節(jié)點表，進入服務(wù)接管流程。以上可以看出，服務(wù)節(jié)點表只會保留“主”節(jié)點信息。

設(shè)計中，心跳協(xié)議以及同步時間可根據(jù)用戶需要進行靈活配置，用戶只需在配置文件錄入性能指標具體值即可，定時裝置可滿足毫秒級偵測要求。

3.3 IP接管機制

在電網(wǎng)監(jiān)控領(lǐng)域，通常為保證內(nèi)存實時數(shù)據(jù)以及性能資源的一致性，需同時啟動2臺主備應(yīng)用程序，只是僅有主節(jié)點才有權(quán)限向數(shù)據(jù)庫或WEB端寫入數(shù)據(jù)。本文設(shè)計中，采用內(nèi)嵌到應(yīng)用程序的輕量級軟件服務(wù)實現(xiàn)IP接管，利用實體IP校驗以及布爾權(quán)限標志取代傳統(tǒng)虛擬IP切換，無需運行IP切換腳本，以及不考慮任何服務(wù)器參數(shù)。根據(jù)程序接管流程給出如下定義：

定義1：節(jié)點邏輯號(module)：用于區(qū)分主備IP地址，在程序配置文件中設(shè)置，與服務(wù)節(jié)點表node類似。

定義2：布爾權(quán)限標識(g_MainNode)：用以識別主備節(jié)點服務(wù)狀態(tài)，取值為：TRUE/FALSE。TRUE表明程序處于全激活狀態(tài)，可對外提供服務(wù)，F(xiàn)ALSE表明程序只能內(nèi)部交互，對外服務(wù)關(guān)閉。

IP接管同樣借助服務(wù)節(jié)點表實現(xiàn)。雙節(jié)點服務(wù)初次啟動后，默認的主節(jié)點會自動將信息更新到表中，隨后在每次同步時間之前，會查詢節(jié)點表中的node值是否與自身節(jié)點邏輯號一致，若相同，則表明此時節(jié)點對應(yīng)的IP為主節(jié)點，否則說明該服務(wù)器已變成備節(jié)點。在查詢中，為了防止服務(wù)節(jié)點表同時被主備節(jié)點訪問，設(shè)計中，利用存儲過程訪問數(shù)據(jù)，先select for update進行鎖住，然后再進行查詢，從而保證事務(wù)的一致性。

故障發(fā)生后，IP校驗以及切換具體流程為：

步驟一：利用ORACLE調(diào)用接口(OCI)訪問數(shù)據(jù)庫，查詢tb_main_node的node值；

步驟二：判斷node與module不等，用自身(備)信息更新tb_main_node內(nèi)容，g_MainNode此時為FALSE；

步驟三：tb_main_node進入時間同步流程，并進入步驟一；

步驟四：判斷node與module相同，g_MainNode值變?yōu)門RUE。

步驟五：備機成為新的主節(jié)點，以tb_main_node中的ip_addr實體地址對外提供服務(wù)。

多策略雙機熱備方案在故障點檢測和服務(wù)接管兩方面邏輯依賴性強，不增加新的節(jié)點故障，與其他業(yè)務(wù)功能耦合性低，程序設(shè)計中，根據(jù)功能特點獨立出可裁剪、可配置的線程進行部署，圖5為多策略雙機熱備軟件流程圖。

圖5 多策略雙機熱備軟件流程圖

4 測試與應(yīng)用

要測試多策略雙機熱備方法是否可靠，須驗證系統(tǒng)故障后，服務(wù)能否及時接管，以及是否存在主備節(jié)點同時爭奪對外提供服務(wù)的情況，即備節(jié)點試圖接管服務(wù)時，主節(jié)點是否還繼續(xù)提供服務(wù)；如果存在爭奪服務(wù)的情況，那么就可以判定該方法存在 “裂腦”問題。測試中，監(jiān)控系統(tǒng)由4臺服務(wù)器組成，如圖6所示，其中192.168.91.100為數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器，用于向主備應(yīng)用服務(wù)器轉(zhuǎn)發(fā)實時數(shù)據(jù)；192.168.91.101、192.168.91.102為主備應(yīng)用服務(wù)器，用于處理實時數(shù)據(jù)和資源信息，并向數(shù)據(jù)庫寫歷史數(shù)據(jù)以及與WEB前臺交互；192.168.91.103服務(wù)器中部署WEB以及ORACLE服務(wù)，101、102、103為熱備決策實體。系統(tǒng)運行時，ORACLE中tb_main_node默認值為{‘1’, ‘192.168.91.101’, ‘'2018-1-6 10:51'’}，則101服務(wù)器為主節(jié)點，系統(tǒng)服務(wù)正常，隨后將101中的處理進程強制關(guān)閉或主服務(wù)器關(guān)機，2分鐘后， tb_main_node值自動更新為{‘2’, ‘192.168.91.102’, ‘'2018-1-6 10:53'’}，102成為新的主節(jié)點，接管101對外一切服務(wù)， WEB前臺和數(shù)據(jù)庫數(shù)據(jù)連續(xù)更新，系統(tǒng)無縫切換，系統(tǒng)平穩(wěn)運行。

圖6 應(yīng)用服務(wù)測試部署圖

目前，多策略雙機熱備方法已在機房綜合監(jiān)控系統(tǒng)得到應(yīng)用，并部署到了江蘇、福建、青海等省公司用于處理全省機房數(shù)據(jù)，以提高通信機房無人值守能力。以某省為例，在系統(tǒng)全面上線后，主節(jié)點應(yīng)用服務(wù)器先后出現(xiàn)過因內(nèi)存溢出、服務(wù)器宕機、進程啟動不了等故障，雙機熱備程序均及時做出判斷，并及時(小于2分鐘)無縫切換到備機，而且備節(jié)點內(nèi)存中的性能信息以及實時數(shù)據(jù)與宕機主機保持完全一致。系統(tǒng)中實時處理服務(wù)在熱備方案的支持下健壯運行，該機制經(jīng)過了專家論證和現(xiàn)場考驗，得到了用戶肯定。

5 結(jié)論

本文通過對傳統(tǒng)雙機熱備方案進行優(yōu)化，設(shè)計了一種多策略雙機熱備方法，該方法通過一種精準定時裝置實現(xiàn)心跳發(fā)送和時間同步，以此完成交叉心跳偵測，保證故障判斷的準確性，并借助數(shù)據(jù)庫實現(xiàn)主備節(jié)點的IP雙向校驗，以較少代碼量實現(xiàn)了服務(wù)無縫切換，保證了服務(wù)的高可用性以及內(nèi)存資源的一致性。目前已經(jīng)在多個省份的實時監(jiān)控系統(tǒng)得到應(yīng)用，運行平穩(wěn)。