OpenStack高可用核心架構分析

【編者按】本文從OpenStack架構入手，剖析了IaaS的云平臺最核心的主要是這三部分：計算、網絡、存儲，作者指出OpenStack這 樣一個復雜系統，高可用更涉及到多個層面，只要有一個層面做不到高可用，那么整個OpenStack都沒法高可用，隨后他從基礎服務Mysql和 RabbitMQ，Nova、Neutron、Cinder接入與控制服務，網絡服務三塊探討了OpenStack各層次的HA設計。

以下為原文：

一、 OpenStack架構與HA分析

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、 計算節點 （Nova ComputeAgent，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方面不斷嘗試新的技術，進一步提升服務質量。

綠星云科技CTO及聯合創始人，曾任騰訊基礎架構部云平臺研發總監，擁有超過十年的大型分布式系統架構、設計與開發經驗。2012年后專注云計算 領域，對亞馬遜公有云AWS、開源云計算平臺OpenStack和虛擬化技術LXC、Docker等有較深入的研究。同時對關系數據庫、網絡應用與優化等 方面也有嘗試，并帶領研發團隊服務于騰訊云后臺架構獲得豐富的實戰經驗。（責編/魏偉）