分布式健康檢查：實現OpenStack計算節點高可用

一、問題的背景

所謂計算節點高可用，是指在計算節點發生硬件故障，如磁盤損壞、CPU溫度過高導致宕機、物理網絡故障時，自動將該節點關閉，并讓其上的虛擬機在剩下的健康節點上重啟，如果可能，最好執行動態遷移。本文是在 今年OpenStack東京峰會上 分享的計算節點高可用話題的整理。

OpenStack最初定位面向公有云，沒有考慮計算節點的高可用問題。理想情況下，在公有云上運行的應用有自己的集群和負載均衡，能在一定程度上容忍計算節點宕機帶來的不可用，并能自動遷移負載。隨著OpenStack的成熟，越來越多的企業客戶開始在自己的私有云里采用OpenStack，將企業部署在虛擬化平臺上的應用遷移到私有云中，計算節點高可用的特性需求越發迫切。但社區只提供了一些配合外部監控服務一起工作的機制，并沒有提供完整的解決方案。因此廠家都可以根據自己的客戶特點設計和部署自己的高可用方案。

在中國的虛擬化市場上，主流虛擬化平臺都提供計算節點的高可用功能，以保證計算節點不可用時，虛擬機能遷移到其他計算節點。很多企業應用因此十分依賴于計算節點的高可用，缺乏計算節點高可用已經成為企業實施OpenStack的一個障礙。

二、社區的狀態

OpenStack社區也意識到了這個問題，但是計算節點高可用的具體機制和策略與客戶的IT基礎設施環境、需求高度相關，所以社區并沒有在OpenStack本身提供計算節點高可用。按照社區的構想，計算節點高可用由一個外部的系統實現，可以是Pacemaker或者Zookeeper。在Liberty中，OpenStack實現、改進了Nova的API，以便更好的配合外部高可用系統實現對Nova服務狀態的改變和對虛擬機的漂移。

我們考察了Pacemaker和Zookeeper，這兩個項目都是成熟的集群編排軟件。其中紅帽的RDO提供了基于Pacemaker-remote實現的高可用方案。社區里也有基于Zookeeper實現的Nova-compute的服務狀態監控。但通過研究我們認為這兩個項目都不適用于計算節點高可用的實現。

我們先來看一個典型的OpenStack部署架構。

在上面的OpenStack集群中，包含3個控制節點，3個計算節點，同時還部署了Ceph分布式存儲作為Cinder的后端存儲。控制節點和計算節點之間使用管理網互聯，虛擬機全部從Cinder Volume啟動，運行在Ceph存儲上。虛擬機訪問Ceph存儲時，使用存儲網。虛擬機之間通信，使用租戶網。虛擬機和外網通信，先使用租戶網連接到控制節點，控制節點再NAT到外網。

首先無論是Pacemaker-remote還是Zookeeper，監控計算節點狀態時，使用的是服務器和計算節點之間互傳心跳的方式。而默認的心跳網只有一個，通常部署在管理網上。這會導致兩個問題，首先管理網斷網會影響到Nova的控制面。用戶無法再在有問題的節點上開啟、關閉虛擬機，但虛擬機的存儲、業務網依然完好。但Pacemaker在節點心跳網失效的默認動作是遠程關閉物理機電源，這反而會導致虛擬機的業務中斷。再者，如果心跳只運行在管理網上，那么存儲網或者租戶網故障時，通常檢查不到，會錯失遷移的良機。雖然可以在Pacemaker里配制多個心跳網絡，但是多個心跳網絡的狀態并不能暴露給上層的監控服務使用。在Zookeeper里雖然可以通過變通的方式加多個心跳網，但是Zookeeper并沒有內置對計算節點其他業務的檢測和監控的支持，需要用戶自己實現。對于這兩個項目，也都存在一些擴展性問題。一般Pacemaker和Zookeeper的服務器的數量是3～5個，但是OpenStack集群中計算節點的數量可能是非常多的，計算節點的心跳會匯聚在少數幾臺服務器上。

三、分布式健康檢查

我們基于 Consul 提出了一套分布式的健康檢查的方案。Consul是一個在容器和微服務技術圈子里比較有名的項目，主要的功能是提供服務注冊和發現、配制變更。但是Consul不僅可以做這些，它還提供了一個分布式的鍵值存儲服務，支持分布式鎖和領導節點的選舉，并提供了事件的觸發和訂閱功能。Consul比較有趣的是其管理的集群規模可達數千個節點。Consul的集群拓撲結構如下圖。

通常一個Consul集群會部署3～5個服務節點，其上的Consul Agent使用服務器模式運行，被管節點上的Consul Agent以普通模式運行。Consul的服務節點之間，使用Raft協議，實現一個強一致的集群，并實現了一個鍵值數據庫。在一個Consul服務節點上成功存儲的數據，馬上可以從其他的Consul節點上讀出來。在節點間維護狀態強一致的成本比較高，因此Consul的服務節點數不會很多。

Consul的普通Agent在每臺計算節點上運行，可以在每個Agent上添加一些健康檢查的動作，Agent會周期性的運行這些動作。用戶可以添加腳本或者請求一個URL鏈接。一旦有健康檢查報告失敗，Agent就把這個事件上報給服務器節點。用戶可以在服務器節點上訂閱健康檢查事件，并處理這些報錯消息。

在所有的Consul Agent之間（包括服務器模式和普通模式）運行著Gossip協議。服務器節點和普通Agent都會加入這個Gossip集群，收發Gossip消息。每隔一段時間，每個節點都會隨機選擇幾個節點發送Gossip消息，其他節點會再次隨機選擇其他幾個節點接力發送消息。這樣一段時間過后，整個集群都能收到這條消息。示意圖如下。

乍看上去覺得這種發送方式的效率很低，但在數學上已有論文論證過其可行性，并且Gossip協議已經是P2P網絡中比較成熟的協議了。大家可以查看 Gossip的介紹 ，里面有一個模擬器，可以告訴你消息在集群里傳播需要的時間和帶寬。Gossip協議的最大的好處是，即使集群節點的數量增加，每個節點的負載也不會增加很多，幾乎是恒定的。這就允許Consul管理的集群規模能橫向擴展到數千個節點。

Consul的每個Agent會利用Gossip協議互相檢查在線狀態，本質上是節點之間互Ping，分擔了服務器節點的心跳壓力。如果有節點掉線，不用服務器節點檢查，其他普通節點會發現，然后用Gossip廣播給整個集群。具體的機制可以 參考這里 。

四、監控服務

利用Consul的這些特性，我們設計的分布式健康檢查的架構如下圖。

我們分別在管理、存儲、租戶網絡上運行三個獨立的Consul集群。所有的節點都運行三個Consul Agent，分別接入管理、存儲、租戶網的集群。控制節點的Consul Agent運行于服務器模式，計算節點的Consul Agent運行于普通模式。

由于分布式Ping機制的存在，Consul服務器節點上幾乎沒有什么負載，但是我們可以隨時從任何一臺服務器節點上的三個Consul Agent上分別取出每個計算節點在每個服務網絡上的在線信息，并匯總。

我們在所有控制節點上都運行著一個監控服務，三個監控服務的實例使用Consul提供的分布式鎖機制選舉出一個領導。被選舉成領導的監控服務實例實際執行高可用事件的處理，其他的監控服務實例熱備待機。這樣我們保證任意一臺控制節點宕機，不會影響監控服務的運行。同時，我們的監控服務還監視本控制節點在每個業務網上的在線狀態。假如某個控制節點的存儲網掉線，從這個控制節點的存儲網Agent得到的信息將是所有其他節點在存儲網掉線，集群成員只剩自己。這個結果顯然是不可信的。在這種情況下，監控服務會主動釋放出集群鎖，讓領導角色漂移到其他節點上。

對檢測到的每個計算節點的在線狀態和健康檢查指標，我們的監控服務會檢查一個矩陣，矩陣綜合考慮了各個指標綜合作用下，異常情況的處理辦法。示例矩陣如下圖。

根據示例矩陣的第一行，如果某計算節點只有管理網掉線，只需要向管理員發送郵件，不應該對虛擬機做操作，否則會影響用戶的應用。

矩陣的第二行的意思是，如果某計算節點存儲網掉線，即使其他網絡狀態健康，我們運行在Ceph之上的虛擬機可能已經崩潰，并且該計算節點也不可能再成功運行新的虛擬機。這時我們應該做的是把計算節點隔離出集群、關機，并將其上的虛擬機“驅散”到其他健康的計算節點上。

對于不同的OpenStack部署模式和用戶的需求，這個矩陣的內容可以是不同的，我們需要針對每個具體的OpenStack環境配置這個矩陣。

五、對Nova的改進

在Nova方面，Liberty版本引入一個新的API “os-services/force-down”。Nova默認的服務監控狀態只監控管理網，并且監控的周期比較長。引入這個API后，外部監控服務通過其他的方式（譬如分布式Ping）監控到計算節點異常后，可以直接調用這個API，將計算節點的服務狀態標記為“forced_down: true”。這樣的好處是，不用等Nova發現自己的計算節點服務掉線，就可以直接“驅散”虛擬機。

另外，Liberty之前，調用Evacuate API時需要指定一個目的主機，作為“驅散”虛擬機的目的計算節點。對于外部的監控服務來說，指定一個目的主機很不方便，無從得知所有計算節點的資源使用情況，而且也可能違反Nova的調度策略。因此在Liberty中，對Nova的這個API進行了改進，可以不指定目的主機，而是由Nova的調度器自行決定應該將虛擬機“驅散”到哪些計算節點上。