基于FCSAN心跳的電力云平臺虛擬機HA實現

田富強 佘文魁 胡波

摘? 要：隨著業務系統上云規模的不斷擴大，云平臺對虛擬機可用性要求越來越高。為了進一步提升虛擬機的可用性，減少業務停機時間，平臺需要在短時間內將虛擬機及業務恢復運行，同時必須防止因判定條件不充分導致虛擬機腦裂。這依賴于HA（High Availability）對資源池中眾多計算節點的狀態進行實時準確的判定。針對電力云平臺虛擬機HA，本文全新提出通過FCSAN的邏輯卷心跳信號來增強對主機狀態感知的方案。經測試，該方案相比僅通過以太網絡來確認主機心跳信號的方式要更可靠。

關鍵詞：基礎設施及服務? 高可用? 虛擬機? 心跳? 光纖存儲

中圖分類號：TP302 ? ? ? ? ? 文獻標識碼：A 文章編號：1674-098X（2020）07（a）-0117-04

Abstract： With the continuous expansion of cloud scale on business systems， cloud platforms have increasingly higher requirements on the availability of virtual machines. In order to further improve the availability of virtual machines and reduce business downtime， the platform needs to resume the virtual machines and services within a short period of time. At the same time， it must prevent the virtual machine from being split due to insufficient judgment conditions. This relies on HA （High Availability） to accurately determine the state of many computing nodes in the resource pool in real time. For the power cloud platform virtual machine HA， this paper proposes a new solution to enhance the host state awareness through the FCSAN logical volume heartbeat signal. After testing， this scheme is more reliable than the way to confirm the host heartbeat signal only through the Ethernet network.

Key Words： Infrastructure and services; High availability; Virtual machines; Heartbeat; Fiber storage

在大型云平臺中，往往以數千臺設備來承載數萬個虛擬機運行，任意一臺物理設備和環境的故障都可能導致多個虛擬機承載業務的中斷。虛擬機HA的任務是在短時間內將所有故障虛擬機恢復運行。目前，各種云平臺虛擬機HA的方案大同小異，主要還是采用心跳機制，IPMI在本場景上僅可用于識別物理機電源狀態，信息不充分。多數云平臺采用分布式存儲，其節點間通信方式為以太網，當以太網絡不穩定時缺少第三方的判定依據，容易對虛擬機誤操作導致腦裂。VMware的HA方案借助其vmfs，通過虛擬機文件鎖來避免腦裂，但VMware需要較高的購買費用。

在電力云平臺資源池的架構中，物理服務器被劃分為多個集群，一個機房通常會配備一臺或多臺FCSAN來存放虛擬機磁盤鏡像。云平臺中一般存在一個或多個控制中心用于資源池的整體調控。計算節點是分散在不同的機架甚至可能在不同機房中，這些物理服務器節點通常通過以太網絡來進行通信。HA的實現首先需要依賴控制中心對每個服務器節點的狀態進行實時精準的感知，而基于以太網絡的通信則是用于感知節點狀態的主要途徑。為了安全，物理機不能通過業務網絡通信，管理網絡將作為唯一的通信通道。管理網故障時，虛擬機可能仍然正常運行，而控制中心卻無法感知虛擬機及其宿主機的任何信號，HA的調度將變得兩難。在判定不充分的情況下，很容易導致虛擬機腦裂。實際情況更復雜，可能出現網絡間歇性閃斷，服務器還可能自動重啟、死機等情況，這些都不是單一的以太網感知方式能夠有效應對的。本文將介紹通過FCSAN的信號補償機來提升虛擬機HA的可靠性的整體方案。

1? HA方案概述

本方案包括心跳保持、HA遷移觸發、FCSAN心跳機制、多機房HA結構、調度模塊設計5個部分。

如圖1，電力云平臺采用無固定中心結構部署，基于“控制中心/代理”模式架構，控制中心采用pacemaker集群方式部署，數據庫采用雙節點相互實時同步，避免出現單點故障。FCSAN存儲和管理網均采用雙鏈路冗余部署。承載虛擬機網絡的業務網與管理網絡是隔離的，此處不能用于HA管理通信。

控制中心需要實時感知計算節點是否處于“可聯系”狀態，當控制中心在一定時間內無法通過任何途徑感知計算節點時，控制中心將虛擬機調度到其它可用的計算節點上運行。計算節點需要不斷檢查本節點是否處于“失聯”的狀態，計算節點檢測到自己“失聯”時，會從本機移除虛擬機運行權，以避免腦裂。

1.1 心跳保持

在資源池中主要將“虛擬機”和“物理機”作為關注點，系統通過實時保持計算節點和控制中心的心跳信號來確認它們的正常運行狀態。正常情況下，計算節點將不間斷地通過管理網向控制中心發送心跳信號，控制中心被動接收心跳信號。計算節點基于TCP/IP發送正常心跳，控制中心對計算節點的TCP心跳請求進行響應，響應內容包含控制中心的實時信息，因為控制中心節點在集群中也是動態變化的（見圖2）。

當正常心跳不能保持并達到超時時間，HA將進入心跳異常處理，心跳異常處理也將直到正常心跳的恢復或異常處理完畢為止。心跳雙方的異常處理策略如下。

（1）控制中心異常心跳策略。

當控制中心無法接收到計算節點的正常心跳，且達到超時時間，將采取以下方式和順序主動獲取計算節點的信號，直到條件成立。如果條件不成立或超時則進行下一步驟。①搜集計算節點所有有效IP地址，并發地發起ICMP請求直到響應或超時為止。②主動多次嘗試通過計算集群代理節點獲取計算節點向FCSAN中寫入的心跳信號，直到取得信號變化或超時為止。③通過對所有網卡旁路監聽，直到獲取到來自目標的信號或超時為止。

（2）計算節點心跳策略。

當計算節點無法向控制中心發送成功正常心跳信號，且達到超時時間，將采取以下方式和順序向控制中心或本集群的FCSAN持續地發送心跳信號，直到條件成立。如果條件不成立或超時則進行下一步驟。①檢查本機所有網卡，找到狀態正常的網卡或超時為止。②搜集控制中心所有有效IP地址，并發地發起ICMP請求直到響應或超時為止。③向本集群的FCSAN發送心跳信號，直到信號發送成功或超時為止。

心跳策略必須要求控制中心和計算節點雙方在同一時間執行才能確保策略的有效性。在正常心跳下，是由策略雙方共同完成一次成功心跳，一旦正常心跳出現中斷，雙方將在同一時間點被心跳雙方感知到。但是控制中心很可能因故障的發生（如網絡中斷時無法讀寫數據庫）不能正常完成策略的處理。

為了防止心跳策略雙方執行時間不對等問題，我們引入“HA故障檢測時段”，它的時間的定義范圍是從最后一次正常心跳的時間開始到數分鐘后為止。故障的判定和相關處理只在該時間階段進行，過時則不再處理。否則可能出現信號不對稱導致錯誤感知，使計算節點正常運行情況下又將虛擬機啟動到其它計算節點。這種情況下，存儲中的同一份虛擬機磁盤鏡像將被兩個實例同時讀寫，這就形成虛擬機腦裂。腦裂發生后，虛擬機關鍵數據很可能損壞，造成較大損失。

1.2 HA遷移觸發

當控制中心依次嘗試完所有途徑均無法檢測到來自計算節點的信號時，會將該計算節點上的虛擬機遷移到其它可用計算節點上。虛擬機遷移分為帶內存遷移和不帶內存遷移兩種情況。

（1）帶內存遷移。

當因計算節點所有網絡均發生故障，而存儲可訪問時，虛擬機將無法與外界通信，服務也就中斷了。如果需要帶內存恢復服務，可將虛擬機的內存保存先在FCSAN存儲中，然后再從其它計算節點通讀取存儲中的內存進行恢復。具體做法（見圖3）：可在存儲上為虛擬機專門創建一個LV（Logical Volume）來臨時保存內存，LV通過文件系統格式化后掛載到虛擬機的宿主機，然后通過宿主機將內存寫入文件系統（KVM等虛擬機均支持將內存轉存到文件），內存保存完成后，虛擬機運行實例將被銷毀，在FCSAN上進行標記，控制中心就可以在其它計算節點上將虛擬機內存文件系統先掛載，然后直接從內存文件恢復虛擬機。

（2）不帶內存遷移。

當因計算節點宕機導致的故障，虛擬機內存直接丟失掉了，這種情形將由控制中心為虛擬機在集群內尋找另一個可用的計算節點重新啟動虛擬機。當計算節點的以太網絡和FCSAN通道均無法通信時，計算節點將虛擬機運行實例直接銷毀。

不帶內存遷移可確保虛擬機更快地恢復運行，帶內存遷移將需要耗費較長的時間，因此在設定虛擬機恢復級別時需要根據實際業務需要來確定。

1.3 FCSAN心跳機制

針對每個物理機計算集群，需要從FCSAN上劃分一個LUN，并通過LVM的方式管理。HA將為集群中的每一個計算節點創建一個LV。下文將該LV稱之為“光纖心跳塊”，它將以物理機ID號作為命名依據。計算節點采用向光纖心跳塊寫數據的方式發送心跳。控制中心從對應光纖心跳塊中讀取光纖心跳信號。由于腦裂本身是因兩個虛擬機實例對FCSAN中的虛擬機磁盤產生了雙寫造成的，因此從避免腦裂的角度來看，以FCSAN的信號作為計算節點可用性判定依據比其它條件更充分。

光纖心跳信號設計。

取0-N的正整數，每一次心跳信號將順序地將這些數值通過二進制形式寫入到光纖心跳塊的起始位置，達到最大值后又從0開始遞增。使得信號寫入期間，控制中心能夠從光纖心跳塊上讀取到在0-N間變化的數值。

1.4 多機房HA結構

當需要將多個機房中的設備納入同一個資源池管理時，控制集群只會部署在其中一個機房。而不同機房往往是配備的獨立的FCSAN存儲，不同機房間存儲鏈路不互通。

如圖4，這種情況下，控制中心無法直接訪問機房二中的光纖心跳塊。針對這種情況，控制中心將選舉一個代理節點來讀取光纖塊心跳。下文稱該節點為“HA檢測代理”。控制中心每一次讀取光纖心跳信號時，均需要從集群2中動態選舉一個可用的計算節點作為“HA檢測代理”。HA檢測代理實時監聽來自控制中心的信號讀取請求，并將讀取結果返回給控制中心。

1.5 調度模塊設計

為了確保HA調度過程中，每一個環節互不影響，同時也不受某一臺物理機環境故障的影響，我們將HA的每個環節設計為獨立的模塊（見表1）。HA調度模塊如下：

T指的是輪循任務，確保動作的持續性。L指的是事件監聽器，L負責多線程處理T發起的事件請求，采用消息和事件監聽模式實現，確保故障可以被大規模持續處理。

2? 驗證測試

我們針對云平臺中常見的網絡故障場景，分別采用某個基于openstack架構的云平臺軟件（因涉及商業問題不便公開，下文稱為X方案）與采用本方案的云平臺軟件進行對比測試。X方案主要采用以太網絡心跳和IPMI作為故障感知方式。

測試環境準備：先后分別采用相同的5臺物理機搭建云平臺，通過相同的5臺虛擬機鏡像克隆20臺虛擬機，每臺物理機運行4臺虛擬機，分別按相同順序對每個測試場景進行3組操作，操作過程中對虛擬機進行ping操作，記錄每一次中斷時間。測試結果見表2。

3? 結語

相比僅采用以太網絡心跳和IPMI作為故障感知方式的云平臺HA方案，本方案在網絡故障場景下能較好地避免對虛擬機進行誤操作，云平臺虛擬機的可用性更高。在一定條件下，采用帶內存遷移來恢復故障虛擬機可更快地恢復業務。采用全異步方式進行HA調度可在同時出現大量故障的場景中更快地完成虛擬機恢復。

參考文獻

[1] VMware，Inc.Patent Issued for VM Availability during Management and VM Network Failures in Host Computing Systems （USPTO 9465704）[J].Computer Weekly News，2016.

[2] 佘文魁，袁亮，田富強，等.基于KVM虛擬化平臺的輕量級HA機制研究[J].電子世界，2018（12）：45-46.

[3] 陳天翼.FCSAN為智能化騰飛插上翅膀[J].中國公共安全，2019（Z1）：107-108.

[4] 白偉華.面向云計算的小粒度應用容器模型研究與應用[D].廣州：華南理工大學，2017.

[5] 郭煜.可信云體系結構與關鍵技術研究[D].北京：北京交通大學，2017.

[6] 杜威科.基于Kubemetes的大數據流式計算Spark平臺設計與實現[D].南京：南京郵電大學，2017.