OpenStack是一個旨在為公共及私有云的建設與管理提供軟體的開源專案。它的社群擁有超過130家企業及1350位開發者，這些機構與個人都將OpenStack作為基礎設施即服務（IaaS）資源的通用前端。OpenStack專案的首要任務是簡化雲的部署過程併為其帶來良好的可擴充套件性。做為雲端計算IAAS層事實標準，OpenStack廣泛的應用與各行各業。到目前為止OpenStack社群並沒有一個完整的虛擬機器HA解決方案。起初社群認為虛擬機器的HA不是雲平臺層次的特性，不應該在雲平臺層面來實現，虛擬機器的HA應該通過應用層面的HA來實現。但是很多應用不是預設做了應用層面的HA，OpenStack又缺少這樣一個重要的特性。所以很多公司針對虛擬機器的HA提出了自己的解決方案。最近社群也開始關注虛擬機器的HA的是實現。這篇文章針對OpenStack中的虛擬機器HA的進展和幾個公司的虛擬機器HA實現進行介紹。最後在結合各種方案的優點的基礎上，介紹了一個虛擬機器的HA的實現方案。

一、OpenStack中虛擬機器HA的歷史和現狀

OpenStack中虛擬機器的HA的最初討論可以見這篇文章, 作為Nova專案的重要貢獻者，他的文章對虛擬機器的HA的實現有著廣泛的影響。這篇文章也給出了虛擬機器HA實現的基本思路，解決這個問題需要一些關鍵的部件：

監控(Monitoring)- 系統檢測到虛擬化層的故障

隔離(或是圍欄，Fencing) - 系統隔離故障計算節點

恢復(Recovery) - 從故障的虛擬化上恢復虛擬機器

下邊是OpenStack中針對虛擬機器HA的一些解決方案；

1.      Nova中的支援

Nova已經具備了一些HA的功能。

1)  在nova中提供了Evacuate命令來實現，將VM從失敗的Compute節點在目標節點上rebuild。這一功能的實現需要依賴源節點和目標節點間有共享儲存。

2)  在VM的HA當中，對於Compute節點是否故障的判斷需要非常的精細，目前在Openstack中每個nova-compute服務啟動時都會啟動一個定時器，定期的將心跳寫入到資料庫中，這樣可以從控制節點方便的知道Compute節點的狀態。

但是Openstack僅僅擁有這些功能還不足以完成對VM HA功能的完美支援。

1)  只是通過nova-compute服務來確定Compute節點的狀態時不可靠的，例如僅僅是nova-compute服務失效，或者網路閃斷時，也會造成心跳的過期，從而對是否進行HA不能進行準確的判斷。因此需要通過其他方式來確保準確獲得節點的狀態。最主要是OpenStack的最佳實踐部署，通常是管理、業務和儲存網段是單獨的網段，這時Nova Service的服務狀態只能反映出管理網段的狀態，不能反映出儲存和業務網段的nova-compute節點的狀態。

2)  Openstack沒有對VM進行加鎖，因此在進行Evacuate命令時，會出現腦裂（同一個disk啟動多個VM的情況）。

3)  對於需要保護的虛擬機器需要提供一個列表，用來表明哪些VM是用來保護的。目前的Evacuate命令會獎失敗主機上的所有虛擬機器無差別進行rebuild這樣的實現也是不太合理的。

2.      neutron+VRRP

為了防止防止arp欺騙，Neutron是不允許一個port上邊繫結多個IP地址的。Neutron在Havana Release增加了一個 “Allowed-Address-Pairs”的功能，允許虛擬機器的一個port繫結附加的IP作為浮動IP。這樣在虛擬機器中可以安裝VRRP實現軟體，比Keepalived等，浮動IP配置為額外增加的IP，多個虛擬機器繫結的port都繫結這個額外的浮動IP，兩個虛擬機器通過VRRP可以選出一個主對外提供服務。

這個方案首先配置複雜，需要在Neutron中為需要參與HA的port繫結額外的IP，還要在虛擬機器中配置VRRP支援軟體，配置複雜。這個方案不能算是一個完整的方案，相當於為應用層的HA實現方案做了一個Neutron中的支援功能。具體參考這篇文章。

3.  Heat Restarter

Heat的HA特性是OpenStack多模組配合實現的，其中涉及到Nova，Ceilometer，Heat-cfn-api，Heat-cloudwatch，Heat-cfntools等。

Nova->提供虛擬機器

Ceilometer->傳送告警

Heat-cfntools->監控虛擬機器狀態

當虛擬機器上的應用程序down了，首先通過重啟應用程序嘗試解決，如果解決不了，重啟或者重建虛擬機器，如果還是解決不了，重建整個stack。從這一點上來看Heat HA的功能要比單純的虛擬機器HA的功能強大很多。

但是對於普通的Web無狀態應用，通過OS::Heat::HARestarter刪除原有虛擬機器，然後重新建立也許適合的，但是如果是資料庫之類的有狀態應用呢？怎麼保證原有資料庫中資料的不丟失，後端卷虛擬機器？那又怎麼保證使用原來的fixed-ip？

正式由於HARestarter是通過刪除原有虛擬機器的方式和虛擬機器的一些依賴資源，Openstack社群已經在Kilo版本廢棄了HARestarter。

4.      OpenStack中的虛擬機器HA方案的設想

二、各大公司的實現方案

1.      Masakari

Masakari 是日本NTT公司提供的一套虛擬HA方案。 Masakari支援虛擬機器程序，虛擬化程序和計算節點程序的監控。通過shell指令碼監控虛擬機器程序，Nova-compute服務和計算節點狀態。

虛擬機器程序掛了->通過虛擬機器的API關閉和啟動虛擬機器。

虛擬化程序掛了->通過Nova-compute API設定Nova-compute服務為down狀態。

Nova-compute程序掛了->疏散計算節點上的虛擬機器。

Masakari的架構：

masakari-controller :  這個HA服務的控制器。

masakari-instancemonitor : 檢測虛擬機器程序是否掛掉了。

masakari-processmonitor : 檢測Nova-compute是否掛了。

masakari-hostmonitor : 檢測計算節點是否掛了。

該方案可取之處在於：對於虛擬機器HA的解決方案中考慮了三個不同層次的故障。但是沒有考慮虛擬機器腦裂和計算節點的隔離，對於通常的OpenStack部署，都會存在管理、業務和儲存三個網段的狀態，簡單的通過一個網段去監控計算節點的狀態是不夠的。

2.      Redhat 方案

部署方式如下：

使用 Pacemaker 叢集作為控制平面

將計算節點做為 Partial members 加入到 Pacemaker 叢集中，受其管理和監控。這時候，其數目不受 Corosync 叢集內節點總數的限制。

HA 實現細節：

Pacemaker通過pacemaker_remote按照順序（neutron-ovs-agent -> ceilometer-compute ->nova-compute) 來啟動計算節點上的各種服務。前面的服務啟動失敗，後面的服務不會被啟動。

Pacemaker 監控和每個計算節點上的 pacemaker_remote 的連線，來檢查該節點是否處於活動狀態。發現它不可以連線的話，啟動恢復（recovery）過程。

Pacemaker 監控每個服務的狀態，如果狀態失效，該服務會被重啟。重啟失敗則觸發防護行為（fencing action）；當所有服務都被啟動後，虛機的網路會被恢復，因此，網路只會短時間受影響。

當一個節點失效時，恢復（recovery）過程會被觸發，Pacemaker 會依次：

1)  執行nova service-disable

2)  將該節點關機

3)  等待 nova 發現該節點失效了

4)  將該節點開機

5)  如果節點啟動成功，執行novaservice-enable

6)  如果節點啟動失敗，則執行 novaevacuate把該節點上的虛機移到別的可用計算節點上。

其中：

l 步驟（1）和 （5）是可選的，其主要目的是防止 nova-scheduler 將新的虛機分配到該節點。

l 步驟（2）保證機器肯定會關機。

l 步驟（3）中目前 nova 需要等待一段較長的超時時間才能判斷節點 down 了。Liberty 中有個 Blueprint 來新增一個 Nova API 將節點狀態直接設定為 down。

l 其餘一些前提條件：

l 虛機必須部署在 cinder-volume 或者共享的臨時儲存比如 RBD 或者 NFS 上，這樣虛機evaculation 將不會造成資料丟失。

l 如果虛機不使用共享儲存，則必須週期性地建立虛機的快照並儲存到 Glance 中。在虛機損壞後，可以從 Glance 快照上恢復。但是，這可能會導致狀態或者資料丟失。

l 控制和計算節點需要安裝 RHEL7.1+ 

l 計算節點需要有防護機制，比如 IPMI，硬體狗等

具體參考這裡。

3.      海雲捷迅的方案

海雲捷迅的分散式健康檢查方案是我比較認同的一種監控計算節點是否掛掉的方案，考慮了管理、業務和儲存三個網段的監控。同時支援應用層的自定義監控方式。具體參考這裡。

該方案引入了consul監控工具，通過consul叢集在管理、業務和儲存三個網段監控計算節點的狀態，根據不同的組合情況，做出不同的處理方式。我認為是對虛擬機器HA方案中的監控部分的深入和精細的控制，可以做到虛擬機器的精準恢復，有效的防止虛擬機器腦裂情況。

四、總結

鑑於各個公司都在為OpenStack做虛擬機器的HA方案，社群也開始考慮實現虛擬機器的HA方案，可以參考這裡。

整合各家方案的優點，儘可能的處理各種虛擬機器的異常情況，保證雲上應用的高可用。構想的如下的虛擬機器HA方案，

服務框架：借鑑https://github.com/gryf/mistral-evacuate這個工作的思想，虛擬機器HA的服務框架應該是一個相對通用的框架，用來處理各種使用者的不同應用場景。一個通用框架，要能處理不同的使用者場景，服務框架還是要有一定的抽象和通用性。這裡是HA服務的服務處理流程。

由於隔離和恢復部分基本沒有太多的選擇，各個公司的虛擬機器HA方案中基本差異都在於監控部分，如何做到精細的監控計算節點的狀態。鑑於OpenStack環境基本都是管理、業務和儲存網三網分開的部署方式，所以我覺得上邊海雲捷迅的分散式健康檢查方式是比較實用的一種監控方式，再加上Ovirt 中的虛擬機器磁碟加鎖機制。我認為可以比較好的解決虛擬機器HA的問題。參考下圖：

虛擬機器HA看似一個簡單的需求，但是從上邊的各種實現方式來看，都有著各自的有點和缺點。所以這個問題其實還是挺複雜。歡迎大家就這個問題和我交流。

三、參考文件

Openstack相關技術交流請加群：314889201