OpenStack實際上是由眾多服務組合而成，它們之間的關聯或多或少，而且具有一定的層次關係，每個服務就像積木塊一樣，你可以根據實際需要進行取捨並組合搭建，因此良好的運營架構整合能力是應用OpenStack的前提。

任何一個IaaS的雲平臺最核心的主要是這三部分：計算、網路、儲存，OpenStack也不例外。在OpenStack裡面這三者分別對應的是Nova，Neutron，Cinder這幾個服務。從社群給出的OpenStack各個服務的應用統計來看，也是這幾個服務接受程度最高，也相對最成熟，另外，從目前OpenStack生態去看，Swift的接受程度並不高，一個重要原因是Ceph在雲端計算領域的開疆拓土，一定程度上擠佔了Swift的市場。相比Swift而言，Ceph是一個大一統的儲存解決方案，在物件儲存、塊儲存、檔案儲存三大方向都能夠由Ceph底層的Rados，雖然Ceph Rados不具備資料排重等高階功能，在落地儲存上也沒有自己很核心的技術，但是在整個架構的Scaling和HA處理方面是做得相當不錯，其設計理念比程式碼實現要超前。統一起來相當方便，而這三者恰恰是任何一個通用雲端計算平臺所需要的。

對任何一個分散式系統，高可用HA都是最核心的設計目標之一。而OpenStack這樣一個複雜系統，高可用更涉及到多個層面，只要有一個層面做不到高可用，那麼整個OpenStack都沒法高可用。

可以看一下一個經典的OpenStack物理架構如下所示：

所以OpenStack的高可用可以從兩個維度去劃分，從功能服務維度劃分：

1、基礎服務（mysql，rabbitmq）

2、計算（nova）

3、網路（neutron）

4、儲存（cinder）

從物理部署層面劃分：

1、控制節點（主要部署基礎服務+其他服務的接入、排程模組）

2、網路節點（主要部署Neutron的L2/L3/DHCP Agent，DHCP,Virtual Router）

3、計算節點（NovaComputeAgent，Neutron L2Agent，虛擬機器）

不管從那個維度去劃分，都需要確保在每個層面上的高可用，並且在各個層面之間進行有效銜接。

在HA設計中，一般來說無狀態的模組處理是比較簡單的，基本思路是並行執行多個節點或者服務模組且對它們進行負載均衡。典型例子是一個網站的Web伺服器叢集，往往採用前端加LVS或者Nginx之類的LoadBanlace伺服器解決HA問題（LVS和Nginx的高可用又是如何做呢？主要是利用Keepalived，Heartbeat等基於路由冗餘協議VRRP或心跳仲裁機制來解決）。

而對於有狀態的模組，主要有兩種方式來實現HA，一種是多節點基於分散式一致性協議（比如Paxos，Raft協議等）維護相同的狀態，典型的代表有Zookeeper，Rabbitmq；一種是基於主從模式的同步或非同步複製來維護相同的狀態，比如Mysql，Redis。這兩種方式前者較複雜，在一些場景下效能會很低，後者在資料一致性和伸縮性方面有所不足。

如前面提到OpenStack的情況會比較複雜，實際實踐中這兩種都會糅合使用，另外有兩點我們可以姑且不考慮：

1、計算節點，主要涉及到虛擬機器的可用性，而虛擬機器的可用性實際上是跟上層應用密切相關的（要做到一個虛擬機器嚴格的熱備是很困難的，儲存容易做到，但是CPU和記憶體就難了，所以主要還是靠上層應用處理），而且對於上層應用來說可能並不需要，應用可能有基於業務邏輯的容錯設計。

2、儲存方面，Cinder雖然是OpenStack的儲存服務，但是跟Swift不同，打個比喻，Cinder只是一個儲存管理器而不是存資料的“硬碟”，真正的“硬碟”是底層的LVM、Ceph、GlusterFS以及其他軟體或硬體構成的儲存系統等，所以OpenStack在儲存方面的高可用更多的是指Cinder這個管理器的高可用性，而資料儲存的高可用性已經由底層的儲存系統來解決了（比如Ceph）。

綜合上述分析OpenStack的高可用，主要是確保控制節點和網路節點的高可用，對映到功能服務維度上，就是確保基礎服務（Mysql和Rabbitmq）高可用，Nova，Neutron和Cinder的接入與排程高可用，以及Neutron所建立的DHCP和Virtual Router等虛擬網路設施的高可用。下面逐一進行探討。

二、OpenStack各層次的HA設計

a) 基礎服務Mysql和RabbitMQ

Mysql作為開源DBMS已經是相當成熟了，功能也非常全面，支援多種資料庫表引擎，生態完善，但是如果從分散式資料庫系統的角度去看，其實還不是很成熟。目前大家用得最多還是基於binlog複製的Master-Slave模式進行資料複製，並基於此做高可用和讀寫分離等設計。比較好用的方案有MHA。在一主多備的情況下，能夠在最少的資料丟失的基礎上實現一定的分散式容錯與計算。MHA的典型架構如下：

不同於MHA這種上層的HA方案（主要是受限於Mysql基於binlog的replication機制的侷限性，在效能和可靠性方面有衝突），在Mysql的MariaDB和Percona分支上，使用相容innodb的XtraDB引擎，基於Galera叢集方式的分散式方案也是越來越收到追捧。雖然複雜度更高，但是分散式實時資料一致性的優勢還是非常吸引人的。當然，這種方案有一些功能上的侷限性，另外在寫少讀多的情況下其實相對1-Master-N-Slave架構沒有多少優勢。基於Galera叢集的方案如下：

Rabbitmq，在開源的分散式訊息佇列裡面，Rabbitmq算是以穩定可靠而著稱，雖然在吞吐量上與Kafka族系的訊息佇列有一些差距，但是經過調優後還是在同一個數量級。另外Rabbitmq是完全實現AMQP且有一定擴充套件的，這一點比很多MQ就強不少了，生態系統完善。Rabbitmq基於Erlang構建，後者雖然很小眾，但也正因為如此才更顯示Rabbitmq的過人之處。

Rabbitmq內建有Cluster叢集功能，同一個Cluster的節點會共享topic，exchange，binding和queue等元資訊，但是對於真正的queue訊息資料是要依賴於Mirror Queue機制來實現訊息的HA的，而且組成Cluster建議至少3個節點，否則網路分割槽發生的時候也不好做決策。所以Cluster+Mirror Queue基本是實現Rabbitmq高可用的最佳方案（在Rabbitmq官網上還介紹了另外一種採取PaceMaker+DRBD的HA方案，但是這種相對來說太麻煩了。Mirror Queue下的訊息效能不會太高，畢竟所有分散式一致性協議的效能都不會太高，而且由於訊息複製的原因，節點之間的流量會增加不少）

b) Nova、Neutron、Cinder接入與控制服務

解決了基礎服務後，對於OpenStack核心的Keystone、Nova-API、Nova-Conductor、Nova-Scheduler、Neutron-Server、Cinder-API、Cinder-Scheduler等，其實都是無狀態的，只要多起兩個，並且能夠做到負載均衡，那麼也就基本達成了HA的目標了（這裡要注意Nova的排程和Cinder的排程需要進行同步互斥）。考慮到OpenStack的對外API基本是HTTP-RESTful的，所以常見的採用Nginx（或HAProxy）+keepalived（或PaceMaker）來實現這一層次的HA接入。如下圖所示：

c) 網路服務

在OpenStack中，網路處理佔據了相當大的一塊，而且由於網路的特殊性與複雜性，一般要獨立部署網路節點。網路節點上最核心的就是L3Agent、DHCPAgent以及由它們所管理的DHCP server和Virtual Router服務（先不討論LBaas，截至OpenStack KILO版本，LBaas其實都還不算很成熟，基於HAproxy的參考實現目前也還沒包含內建的HA機制）。

首先看DHCP，由於這個比較簡單，就猶如DNS天然是支援多DNS的，所以可以在多個網路節點上部署DHCP Agent來達到多DHCP server並行，且把使用者私有網路的DHCP分佈在上面就可以了。

對於Router服務，由於涉及到到路由和外網接入，所以這裡不能同時執行多個一樣的Router服務（地址與路由衝突問題），目前簡單的是採取A/P模式來部署。由控制節點上的L3 Router Plugin去對網路節點上的L3 Agent週期性做心跳探測，從而實現L3 Agent的failover機制，當出現故障時遷移Router到新的網路節點上。 這是一種較為保守且簡單的方案，但是這種方案會有網路分割槽的問題，所以仍然還是有可能出現兩個L3 Agent同時服務的現象，所以需要人工干預。

從OpenStack Juno版本開始引入了分散式虛擬路由DVR，核心思想是把原來網路節點上的Router服務分佈到各個計算節點上去了，只把DHCP和SNAT留在網路節點上。這樣就大大增強了Router的容災能力，而且大大增強了整個叢集的東西、南北向通訊能力（突破了網路節點的瓶頸）。OpenStack另外一個孵化專案DragonFlow也實現了類似DVR的功能，只是實現的方式不一樣，更符合Neutron本身的外掛架構，更具有SDN的味道。無論是DVR還是DragonFlow目前都還不夠成熟。綜合上面的分析，目前網路服務這塊，一個簡單穩定的部署方案還是以網路節點的A/P容災模式以failover方式的網路服務的HA機制。

三、總結

總而言之，OpenStack在整體架構上是可以整合出一套行之有效的HA方案的，較弱的應該是網路上，目前社群也有相當多的努力在進行優化改進，隨著後續新版本不斷完善，OpenStack的高可用性將不斷增強。我們以OpenStack為基礎，已經整合構建了具有較高可用性的彈性計算、分散式塊儲存和虛擬私有網路等IaaS核心功能，後續也將在HA方面不斷嘗試新的技術，進一步提升服務質量。