超級基站心跳機制的設計與應用實現*

王 朋， 王園園

（1.重慶郵電大學通信與信息工程學院，重慶 400065；2.移動計算與新型終端北京市重點實驗室，北京 100190）

0 引 言

集中式接入網架構是未來蜂窩移動通信網絡架構發展的重要方向之一。超級基站是中科院計算所提出的一種基于資源池化的集中式架構新型基站平臺，通過對集中部署的處理資源的池化和按需分配，可以有效應對大量傳統基站的占地問題、能耗問題、運維開銷大的問題以及潮汐效應問題。超級基站在物理上表現為一組通過高速交換機互聯互通的網絡節點，在邏輯上表現為很多多制式虛擬機站組成的網絡[1-3]。

心跳機制是對網絡通路健康狀況監測的一種重要手段。所謂的心跳機制是指網絡節點定時輪詢地發送心跳包給服務端，告訴自己還“活著”。當服務端在超時時限內收到了網絡節點發來的心跳包，則會回應一個確認心跳包；若沒有收到，則視為該節點網絡斷開或故障[4]。目前，心跳機制在即時通信、集群網絡監測、雙機熱備和工業網絡安全監測中都得到了廣泛應用[5-8]。在傳統的心跳機制應用設計中，在給定的超時時限下，心跳間隔往往設置成超時時限的1/3～1/2[9]。這樣設置雖然可以排除網絡延遲或丟包造成的誤判問題，但是心跳間隔較小，心跳包的發送過于頻繁，再加上超級基站的節點較多，無疑增加了監測服務端的網絡負擔。另外，超級基站有軟固件更新自動重啟功能。對于任務量較少的節點，通過資源整合，任務遷移到一個節點上，下電其他節點來達到節能和提高資源使用率的效果。然而，超級基站的重啟和下電會丟失節點的心跳。傳統的心跳機制對于誤判問題僅考慮了網絡延遲，而沒有考慮節點的重啟和下電也會帶來誤判。一旦產生誤判將會帶來不必要的任務切換，增加其他節點的任務負載，導致被誤判節點的資源得不到有效利用。

1 改進心跳機制的設計

針對以上提出的問題，本文設計提出了一種改進的心跳機制。該心跳機制分為兩個階段，分別是最優心跳間隔決策階段和心跳監測判決階段。從交互流程上分為節點端和監測服務端。

系統初始啟動時，便開始進入最優心跳間隔查找階段。此階段發送標志位為“Test”的心跳包。在初始給定的超時時限、最優心跳間隔的查找范圍和心跳間隔閾值下，通過使用二分法[10-11]不斷分割并縮小最優心跳間隔所在的區間長度，保證監測服務器端能夠在超時時限內收到被監測端的心跳包的同時，使心跳間隔盡可能大。當被分割的心跳區間的長度小于或等于心跳間隔閾值時，則不再查找，決策出最優心跳間隔，進入穩定工作模式。

當最優心跳間隔已確定進入穩定工作模式后，節點端將保持最優心跳間隔發送標志位為“Keep”的心跳包，進入心跳監測判決階段。在此階段，監測服務端每隔Timeout時間都會對接收到的各節點心跳包進行判決。為了避免節點重啟或下電造成的心跳丟失帶來的誤判，在節點需要重啟或下電前，節點端將會發送一條標志位為“Restarting”或“PowerOff”的心跳包告知監測服務端該節點將要重啟或下電。監測服務端將節點的通路狀態分為“Normal”“Fault”“Restarting”和“PowerOff”4個狀態。根據收到的心跳包的標志位，將網絡通路狀態改為“Normal”或“Restarting”或“PowerOff”。當判定網絡故障時，將該節點的網絡通路狀態改為“Fault”。網絡通路狀態的改變規則如表1所示。當某節點心跳丟失時，監測服務端通過判斷該節點的網絡通路狀態，決定網絡通路是否真的出現故障。

表1 網絡通路狀態改變規則

1.1 最優心跳間隔決策階段二分法詳細設計

該階段，網絡節點端發送標志位為“Test”類型的心跳包。監測服務端若連續3次收到該類型的心跳包，則給予ACK回復；否則，給予NACK回復。網絡節點端根據監測服務端回復的是ACK包還是NACK包，決策分割最優心跳間隔所在的區間。在節點端和監測服務端的交互流程圖，如圖1所示。

變量說明：Topt為最優心跳間隔；ρ為心跳間隔閾值；Timeout為超時時限；Tcurr為當前心跳間隔；hb_count為記錄接收到的心跳包的次數；[A,B]為初始給定最優心跳間隔查找的范圍，0＜A＜B≤Timeout；t1、t2為臨時變量。

二分法算法步驟如下：

（1）給區間[A,B]，心跳間隔閾值ρ和超時時限Timeout賦初值，然后令t1=A，t2=B。

（2）判斷t2-t1＜ρ成否成立，若否，則執行（3）；若成立，最優心跳間隔確定為Topt=t1，進入穩定工作模式。

（3）將當前心跳間隔設為Tcurr=(t1+t2)/2。

（4）以心跳間隔Tcurr向監測服務器端發送標志位為“Test”的心跳包。

（5）當收到監測服務器端ACK回復時，說明心跳間隔較小，在右半區間查找，令t1=Tcurr，執行（2）。

（6）當收到監測服務器端NACK回復時，說明心跳間隔過大，在左半區間找，令t2=Tcurr,執行（2）。

使用該二分法通過節點端和監測服務端不斷交互測試獲取的心跳間隔，比傳統方法獲取的心跳間隔大而優，在保證心跳機制可靠性的前提下，減少了心跳包發送的頻繁度，從而減少了監測服務端的網絡負擔。

圖1 二分法節點端和服務端交互的流程

1.2 心跳監測判決階段的詳細設計

該階段節點端和監測服務端的交互流程，如 圖2所示。監測服務端每收到的一個心跳包，都會保存發包的節點ID、心跳次數記錄hb_count加1以及判斷心跳包的標志位決定是否對節點的通路狀態進行更改。每當定時器時間超過Timeout時，則會對每個節點的心跳次數進行判決。判決完后，將各節點的心跳記錄清零，繼續接收心跳包。

判決方法為：

（1）當節點的心跳次數hb_count都大于0時，則網絡通路正常。

（2）當節點的心跳次數hb_count為0時，說明該節點的心跳丟失，然后對該節點的網絡通路狀態進行判斷。

（3）若節點的通路狀態為“Fault”，則說明節點的網絡通路已經故障，需進行網絡通路故障上報；否則執行（4）。

（4）若通路狀態為“Normal”，說明不是節點的重啟或下電造成，考慮可能是網絡延遲導致，則再連續接收2次，若收到了節點的心跳包，則說明存在網絡延遲，否則上報節點網絡通路故障，并將該節點的網絡通路狀態改為“Fault”，否則執行（5）。

（5）若通路狀態為“Restarting”，說明節點重啟導致，判斷5 min內是否收到節點的心跳包（經多次試驗節點的重啟時間一般在2 min左右），若否，上報重啟后節點網絡通路故障，并將該節點的通路狀態置為“Fault”;否則執行（6）。

（6）若通路狀態為“PowerOff”，說明節點下電導致，不進行網絡故障上報，否則執行（7）。

（7）節點的狀態為初始狀態，則上報節點初始啟動時網絡通路故障，并將該節點的網絡通路狀態改為“Fault”。

在此階段，綜合考慮了網絡時延、節點重啟和節點下電因素可能使心跳機制產生的誤判，并給出了相應的判決方法，提高了心跳機制的可靠性，保證了超級基站穩定可靠的運行。

圖2 心跳監測判決階段節點端和監測服務端的交互流程

2 心跳包組包方式的選擇方案

為了保證超級基站的負載均衡，為是否進行虛擬基站的遷移提供決策依據，監測服務端還需對超級基站各節點的系統資源使用率進行實時監測[12]。因此，超級基站各節點不僅需要定時發送心跳包，還需要定時發送系統資源使用率監測包。在心跳包發送心跳間隔最優且一定的情況下，為了最大限度地減少心跳包給監測服務端帶來的網絡負擔，針對心跳包的組包方式對產生的網絡流量影響進行分析。節點端發送心跳包的組包方式可分為兩種： （1）心跳包和系統資源監測包獨立發送；（2）將心跳包和資源監測包合并為一個心跳包發送。下面針對兩種不同心跳包的組包方式產生的網絡流量進行建模分析。

假設消息頭的大小為a字節，心跳包的主機標識信息大小為b字節，系統資源監測包的數據域的大小為c字節。集群節點的數量為n個，每個節點發送資源監測包的時間間隔為T1秒，發送心跳包的時間間隔為T2秒，一個小時內n個節點定時發送心跳包和資源監測包產生的網絡流量為F。

方式1：心跳包和資源監測包獨立發送

心跳包和資源監測包的數據格式如圖3（a）和圖3（b）所示，節點在一個小時內發送的心跳包和資源監測包產生的網絡流量F1為：

化簡，得到：

方式2：將心跳包和資源監測包合并為一個心跳包發送

將資源監測包的數據域添加到心跳包尾部的數據格式，如圖3（c）所示。節點以這種方式發送心跳包一個小時產生的網絡流量F2為：

式（2）減去式（3），得到：

圖3 數據包格式

綜上所述，當資源監測數據包發送的時間間隔T1與心跳包發送的時間間隔T2的關系為時，F1＞F2，采用將資源監測包和心跳包組合成一個心跳包的方式發送產生的網絡流量更少；當資源監測數據包發送的時間間隔T1與心跳包發送的時間間隔T2的關系為時，F1≤F2，采用將資源監測包和心跳包相互獨立的方式發送產生的網絡流量更少。

3 測試分析

3.1 可靠性測試

該改進的心跳機制實現采用C語言編程，代碼按照圖1、圖2節點端和監測服務器端的交互流程圖編寫，通信協議采用TCP協議，監測服務器端采用IO多路復用接口函數epoll來監聽接收數據。在超級基站的3個節點上，對該改進的心跳機制進行了可靠性測試。設置監測服務器端的超時時限Timeout=10 s，最優心跳間隔的查找范圍為 [1 s,10 s]，心跳誤差ρ=10 ms，3個節點的Ip分別為10.21.101.172、10.21.3.97、10.21.2.125，分別編號為0號節點、1號節點和2號節點。測試分為對網絡延遲和網絡斷開測試、對節點重啟和關機測試。

3.1.1 網絡延遲和斷開場景測試

對網絡延遲測試和網絡斷開測試的方法為，在心跳機制正常工作的情況下，在監測服務端模擬網絡延遲測試，然后依次拔掉3個節點的網線，測試結果如圖4所示。初始3個節點與監測服務器端建立連接完成，然后進入最優心跳間隔測試階段。當最優心跳間隔查找完成后，監測服務器端開始正常接收“Keep”標志位的心跳包。在正常接收的1個周期后，2號節點的心跳包丟失。考慮到可能是網絡延遲導致，則繼續接收，在下一個超時時限內又收到了2號節點的心跳包，判定網絡存在延遲，而并沒有上報網絡通路故障。然后，依次斷開0號節點、1號節點和2號節點，監測服務器端都能夠正確判決出0號節點、1號節點和2節點的網絡出現了故障，驗證了該改進心跳機制對網絡延遲和網絡斷開的可靠性。

圖4 對網絡延遲和網絡斷開測試結果

在最優心跳間隔測試階段，使用二分法不斷分割最優心跳間隔所在區間，如圖5所示。當超時時限Timeout設置為10 s時，3個節點最終查找決策出的最優心跳間隔均為9 292 ms，約為9.3 s。和傳統的將心跳間隔設置為超時時限的1/3～1/2倍即設置為3.3～5 s相比，使用二分法獲取的心跳監測大而優，減少了心跳包發送的頻繁度，減少了監測服務端的網絡負擔。

圖5 二分法查找最優心跳間隔測試結果

3.1.2 節點重啟和下電場景測試

在心跳機制正常工作的情況下，先重啟所有節點，待節點都重啟后下電0號節點，測試結果如圖6所示。

圖6 對節點重啟和下電測試結果

系統初始啟動時，監測服務端與3個節點建立連接成功。在第一個超時時限內收到3個節點的心跳包，然后成功檢測出節點重啟。過一小段時間后，節點重啟成功，并在第一超時時限內收到了所有節點的心跳包，在下一超時時限內成功檢測出了0號節點下電和其他兩個節點正常，驗證了該改進心跳機制對節點重啟和下電的可靠性。

3.2 不同心跳包的組包方式產生網絡流量的對比

在Linux系統下，通過使用進程流量監控工具NetHogs，對監測服務端進程接收和發送的流量進行監控。在超級基站中，系統資源使用率數據包的采集頻率為T1=10 s，消息頭的大小a=8字節，心跳包的主機標識信息大小b=5字節，資源監測包的數據域的大小c=16字節。針對兩種不同的組包方式進行測試，分別采集了5 min、10 min、20 min、 30 min的流量進行對比，結果如圖7所示。

圖7 兩種組包方式產生的流量對比

從圖7的柱狀圖可以明顯看出，心跳包采用方式二的組包方式發包，產生的網絡流量更少，對監測服務端造成的網絡壓力更小。隨著時間的推移，兩種發包方式產生的網絡流量差距越來越大，說明隨著時間的增大，與方式一相比，采用方式二節省的網絡流量更多，性能更優。由式（4）可得，當，F1＞F2，也可以得出采用方式二的發包方式更節省流量。可見，此計算結果和測試結果一致，驗證了心跳包組包方案對于節省網絡流量的有效性。

4 結 語

本文設計了一種改進的心跳機制，使用二分法查找決策出最優心跳間隔，考慮了多種可能使心跳機制造成誤判的因素。另外，為了盡量減心跳包頻繁發送產生的網絡流量，減輕監測服務器端的網絡負擔，提出了一種心跳包組包方案。測試結果表明，該改進的心跳機制具有很高的可靠性，提出的心跳包組包方案能夠節省網絡流量，減輕監測服務器端的網絡負擔。