理解 OpenStack 高可用（HA）（1）：OpenStack 高可用和災備方案 [OpenStack HA and DR]

本系列會分析OpenStack 的高可用性（HA）概念和解決方案：

（1）OpenStack 高可用方案概述

（2）Neutron L3 Agent HA - VRRP （虛擬路由冗余協議）

（3）Neutron L3 Agent HA - DVR （分布式虛機路由器）

（4）Pacemaker 和 OpenStack Resource Agent （RA）

（5）RabbitMQ HA

（6）MySQL HA

 

1. 基礎知識

1.1 高可用 （High Availability，簡稱 HA）

    高可用性是指提供在本地系統單個組件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬件的故障。最好的可用性， 就是你的一台機器宕機了，但是使用你的服務的用戶完全感覺不到。你的機器宕機了，在該機器上運行的服務肯定得做故障切換（failover），切換有兩個維度的成本：RTO （Recovery Time Objective）和 RPO（Recovery Point Objective）。RTO 是服務恢復的時間，最佳的情況是 0，這意味着服務立即恢復；最壞是無窮大意味着服務永遠恢復不了；RPO 是切換時向前恢復的數據的時間長度，0 意味着使用同步的數據，大於 0 意味着有數據丟失，比如 ” RPO = 1 天“ 意味着恢復時使用一天前的數據，那么一天之內的數據就丟失了。因此，恢復的最佳結果是 RTO = RPO = 0，但是這個太理想，或者要實現的話成本太高，全球估計 Visa 等少數幾個公司能實現，或者幾乎實現。

    對 HA 來說，往往使用共享存儲，這樣的話，RPO =0 ；同時往往使用 Active/Active （雙活集群） HA 模式來使得 RTO 幾乎0，如果使用 Active/Passive 模式的 HA 的話，則需要將 RTO 減少到最小限度。HA 的計算公式是[ 1 - (宕機時間)/（宕機時間 + 運行時間）]，我們常常用幾個 9 表示可用性：

• 2 個9：99% = 1% * 365 = 3.65 * 24 小時/年 = 87.6 小時/年的宕機時間
• 4 個9: 99.99% = 0.01% * 365 * 24 * 60 = 52.56 分鍾/年
• 5 個9：99.999% = 0.001% * 365 = 5.265 分鍾/年的宕機時間，也就意味着每次停機時間在一到兩分鍾。
• 11 個 9：幾乎就是幾年才宕機幾分鍾。 據說 AWS S3 的設計高可用性就是 11 個 9。

1.1.1 服務的分類

HA 將服務分為兩類：

• 有狀態服務：后續對服務的請求依賴於之前對服務的請求。
• 無狀態服務：對服務的請求之間沒有依賴關系，是完全獨立的。

1.1.2 HA 的種類

HA 需要使用冗余的服務器組成集群來運行負載，包括應用和服務。這種冗余性也可以將 HA 分為兩類：

• Active/Passive HA：集群只包括兩個節點簡稱主備。在這種配置下，系統采用主和備用機器來提供服務，系統只在主設備上提供服務。在主設備故障時，備設備上的服務被啟動來替代主設備提供的服務。典型地，可以采用 CRM 軟件比如 Pacemaker 來控制主備設備之間的切換，並提供一個虛機 IP 來提供服務。
• Active/Active HA：集群只包括兩個節點時簡稱雙活，包括多節點時成為多主（Multi-master）。在這種配置下，系統在集群內所有服務器上運行同樣的負載。以數據庫為例，對一個實例的更新，會被同步到所有實例上。這種配置下往往采用負載均衡軟件比如 HAProxy 來提供服務的虛擬 IP。

1.1.3 雲環境的 HA

    雲環境包括一個廣泛的系統，包括硬件基礎設施、IaaS層、虛機和應用。以 OpenStack 雲為例：

雲環境的 HA 將包括：

• 應用的 HA
• 虛機的 HA
• 雲控制服務的 HA
• 物理IT層：包括網絡設備比如交換機和路由器，存儲設備等
• 基礎設施，比如電力、空調和防火設施等

本文的重點是討論 OpenStack 作為 IaaS 的 HA。 

1.2 災難恢復 （Disaster Recovery）

幾個概念：

• 災難（Disaster）是由於人為或自然的原因，造成一個數據中心內的信息系統運行嚴重故障或癱瘓，使信息系統支持的業務功能停頓或服務水平不可接受、達到特定的時間的突發性事件，通常導致信息系統需要切換到備用場地運行。
• 災難恢復（Diaster Recovery）是指當災難破壞生產中心時在不同地點的數據中心內恢復數據、應用或者業務的能力。
• 容災是指，除了生產站點以外，用戶另外建立的冗余站點，當災難發生，生產站點受到破壞時，冗余站點可以接管用戶正常的業務，達到業務不間斷的目的。為了達到更高的可用性，許多用戶甚至建立多個冗余站點。 
• 衡量容災系統有兩個主要指標：RPO（Recovery Point Objective）和 RTO（Recovery Time Object），其中 RPO代表 了當災難發生時允許丟失的數據量，而 RTO 則代表了系統恢復的時間。RPO 與 RTO 越小，系統的可用性就越高，當然用戶需要的投資也越大。

    大體上講，容災可以分為3個級別：數據級別、應用級別以及業務級別。

級別	定義	RTO	CTO
數據級	指通過建立異地容災中心，做數據的遠程備份，在災難發生之后要確保原有的數據不會丟失或者遭到破壞。但在數據級容災這個級別，發生災難時應用是會中斷的。 在數據級容災方式下，所建立的異地容災中心可以簡單地把它理解成一個遠程的數據備份中心。數據級容災的恢復時間比較長，但是相比其他容災級別來講它的費用比較低，而且構建實施也相對簡單。 但是，“數據源是一切關鍵性業務系統的生命源泉”，因此數據級容災必不可少。	RTO 最長(若干天) ，因為災難發生時，需要重新部署機器，利用備份數據恢復業務。	最低
應用級	在數據級容災的基礎之上，在備份站點同樣構建一套相同的應用系統，通過同步或異步復制技術，這樣可以保證關鍵應用在允許的時間范圍內恢復運行，盡可能減少災難帶來的損失，讓用戶基本感受不到災難的發生，這樣就使系統所提供的服務是完整的、可靠的和安全的。	RTO 中等（若干小時）	中等。異地可以搭建一樣的系統，或者小些的系統。
業務級	全業務的災備，除了必要的 IT 相關技術，還要求具備全部的基礎設施。其大部分內容是非IT系統（如電話、辦公地點等），當大災難發生后，原有的辦公場所都會受到破壞，除了數據和應用的恢復，更需要一個備份的工作場所能夠正常的開展業務。	RTO 最小（若干分鍾或者秒）	最高

 

1.3 HA 和 DR 的關系

    兩者相互關聯，互相補充，互有交叉，同時又有顯著的區別：

• HA 往往指本地的高可用系統，表示在多個服務器運行一個或多種應用的情況下，應確保任意服務器出現任何故障時，其運行的應用不能中斷，應用程序和系統應能迅速切換到其它服務器上運行，即本地系統集群和熱備份。HA 往往是用共享存儲，因此往往不會有數據丟失（RPO = 0），更多的是切換時間長度考慮即 RTO。
• DR 是指異地（同城或者異地）的高可用系統，表示在災害發生時，數據、應用以及業務的恢復能力。異地災備的數據災備部分是使用數據復制，根據使用的不同數據復制技術（同步、異步、Strectched Cluster 等），數據往往有損失導致 RPO >0；而異地的應用切換往往需要更長的時間，這樣 RT0 >0。 因此，需要結合特定的業務需求，來定制所需要的 RTO 和 RPO，以實現最優的 CTO。

也可以從別的角度上看待兩者的區別： 

• 從故障角度，HA 主要處理單組件的故障導致負載在集群內的服務器之間的切換，DR 則是應對大規模的故障導致負載在數據中心之間做切換。
• 從網絡角度，LAN 尺度的任務是 HA 的范疇，WAN 尺度的任務是 DR 的范圍。
• 從雲的角度看，HA 是一個雲環境內保障業務持續性的機制，DR 是多個雲環境間保障業務持續性的機制。
• 從目標角度，HA 主要是保證業務高可用，DR 是保證數據可靠的基礎上的業務可用。 

一個異地容災系統，往往包括本地的 HA 集群和異地的 DR 數據中心。一個示例如下（來源：百度文庫）：

Master SQL Server 發生故障時，切換到 Standby SQL Server，繼續提供數據庫服務：

在主機房中心發生災難時，切換到備份機房（總公司機房中心）上，恢復應用和服務：

2. OpenStack HA

OpenStack 部署環境中，各節點可以分為幾類：

• Cloud Controller Node （雲控制節點）：安裝各種 API 服務和內部工作組件（worker process）。同時，往往將共享的 DB 和 MQ 安裝在該節點上。
• Neutron Controller Node （網絡控制節點）：安裝 Neutron L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 組件。
• Storage Controller Node （存儲控制節點）：安裝 Cinder volume 以及 Swift 組件。
• Compute node （計算節點）：安裝 Nova-compute 和 Neutron L2 Agent，在該節點上創建虛機。

要實現 OpenStack HA，一個最基本的要求是這些節點都是冗余的。根據每個節點上部署的軟件特點和要求，每個節點可以采用不同的 HA 模式。但是，選擇 HA 模式有個基本的原則：

• 能 A/A 盡量 A/A，不能的話則 A/P （RedHat 認為 A/P HA 是 No HA）
• 有原生（內在實現的）HA方案盡量選用原生方案，沒有的話則使用額外的HA 軟件比如 Pacemaker 等
• 需要考慮負載均衡
• 方案盡可能簡單，不要太復雜

OpenStack 官方認為，在滿足其 HA 要求的情況下，可以實現 IaaS 的 99.99% HA，但是，這不包括單個客戶機的 HA。

2.1 雲控制節點 HA

    雲控制節點上運行的服務中，API 服務和內部工作組件都是無狀態的，因此很容易就可以實現 A/A HA；這樣就要求 Mysql 和 RabbitMQ 也實現 A/A HA，而它們各自都有 A/A 方案。但是，Mysql Gelera 方案要求三台服務器。如果只想用兩台服務器的話，則只能實現 A/P HA，或者引入一個 Arbiter 來做 A/A HA。

2.1.1 雲控制節點的 A/A HA 方案

該方案至少需要三台服務器。以 RDO 提供的案例為例，它由三台機器搭建成一個 Pacemaker A/A集群，在該集群的每個節點上運行：

• API 服務：包括 *-api, neutron-server，glance-registry, nova-novncproxy，keystone，httpd 等。由 HAProxy 提供負載均衡，將請求按照一定的算法轉到某個節點上的 API 服務。由  Pacemaker 提供 VIP。
• 內部組件：包括 *-scheduler，nova-conductor，nova-cert 等。它們都是無狀態的，因此可以在多個節點上部署，它們會使用 HA 的 MQ 和 DB。
• RabbitMQ：跨三個節點部署 RabbitMQ 集群和鏡像消息隊列。可以使用 HAProxy 提供負載均衡，或者將 RabbitMQ host list 配置給 OpenStack 組件（使用 rabbit_hosts 和 rabbit_ha_queues 配置項）。
• MariaDB：跨三個階段部署 Gelera MariaDB 多主復制集群。由 HAProxy 提供負載均衡。
• HAProxy：向 API，RabbitMQ 和 MariaDB 多活服務提供負載均衡，其自身由 Pacemaker 實現 A/P HA，提供 VIP，某一時刻只由一個HAProxy提供服務。在部署中，也可以部署單獨的 HAProxy 集群。
• Memcached：它原生支持 A/A，只需要在 OpenStack 中配置它所有節點的名稱即可，比如，memcached_servers = controller1:11211,controller2:11211。當 controller1:11211 失效時，OpenStack 組件會自動使用controller2:11211。 

從每個 API 服務來看：

  

關於共享 DB 的幾個說明 （主要來自 這篇文章）：

（1）根據該文章中的一個調查，被調查的 220 多個用戶中，200 個在用 Mysql Galera，20 多個在用單 Mysql，只有一個用 PostgreSQL。

（2）以 Nova 為例，Mysql 使用 Write-intent locks 機制來保證多個連接同時訪問數據庫中的同一條記錄時的互斥。以給新建虛機分配 IP 地址為例，該鎖機制保證了一個 IP 不會分給兩個用戶。

（3）使用 Mysql Galera 時，所有節點都是 Master 節點，都可以接受服務，但是這里有個問題，Mysql Galera 不會復制 Write-intent locks。兩個用戶可以在不同節點上獲取到同一條記錄，但是只有一個能夠修改成功，另一個會得到一個 Deadlock 錯誤。對於這種情況，Nova 使用 retry_on_deadlock 機制來重試，比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默認都是重試 5 次。但是，這種機制效率不高，文章作者提供了一種新的機制。

 

該 HA 方案具有以下優點：

• 多主，零切換，方便地實現負載均衡
• 將 API 服務和 DB, MQ 服務無縫整合在一起

由於這些優點，該方案被大量采用。具體配置請參考 OpenStack High Availability Guide。

2.1.2 雲控制節點的 A/P HA方案

    需要的話，可以使用 Pacemaker + Corosync 搭建兩節點集群實現 A/P HA 方案。由主服務器實際提供服務，在其故障時由 Pacemaker 將服務切換到被服務器。OpenStack 給其組件提供了各種Pacemaker RA。對 Mysql 和 RabbitMQ 來說，可以使用 Pacemaker + Corosync + DRBD 實現 A/P HA。具體請參考 理解 OpenStack 高可用（HA）（4）：RabbitMQ 和 Mysql HA。具體配置請參考 OpenStack High Availability Guide。

  該 HA 方案的問題是：

• 主備切換需要較長的時間
• 只有主提供服務，在使用兩個節點的情況下不能做負載均衡
• DRBD 腦裂會導致數據丟失的風險。A/P 模式的 Mysql 的可靠性沒有 Mysql Galera 高。
  

  因此，可以看到實際部署中，這種方案用得較少，只看到 Oracel 在使用這種方案。

2.2 Neutron HA

Neutron 包括很多的組件，比如 L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 組件，其中部分組件提供了原生的HA 支持。這些組件之間的聯系和區別：

2.2.1 原生 HA 方案

Neutron 提供了多種原生的 HA 方案：

（1）L2 Agent HA： L2 agent 只在所在的網絡或者計算節點上提供服務，因此它是不需要HA的。

（2）L3 Agent HA

    L3 Agent 比較特殊，因為它是所有 openstack （core）services 中唯一一個有狀態的，因此，不能使用傳統的在多個節點上部署多個實例使用LB來做HA。Neutron 本身的調度器（scheduler）支持在多個網絡節點上部署多個L3 Agent，但是，由 L3 Agent 管理的 Virtual Router 自身需要有HA的實現。它的HA的Neutron 原生實現包括如下幾種方式：

（a）Juno 中引入的 Automatic L3 Agent Failover （當 VR 所在的 L3 Agent 失效的時候，Neutron 自動將它 failover 到其它某個 L3 Agent 上）

    該方案增加了一個配置項 allow_automatic_l3agent_failover。當它的值為 True 時，L3 plugin 去周期性地檢查所有有管理 Virtual Router 的 L3 Agent 的狀態。如果某 L3 Agent 死了，受它管理的 Router 會重新被 schedule 到別的 L3 Agent 上。 Neutron L3 Plugin 通過判斷該 L3 Agent 是否在規定時間（agent_down_time）內有發回心跳消息來判斷它是否活着。存在多種 L3 Agent 未能及時上報心跳但是 router 依然在轉發網絡包的可能。因此這種實現可能會存在 L3 Agent 被認為死了但是其 router namespace 依然在轉發網絡包和響應 ARP 請求而導致的問題。如果網絡后端不阻止死掉了的 agent 使用 route 的 IP 地址，那新老 namespace 就可能存在沖突。這種沖突不會斷掉 E-W 網絡，因為新老 namespace 中的一個都可以承擔無狀態網絡包的轉發任務。然后，南-北網絡可能會受影響，因為 NAT 只存在於一個router 上。而且，reschedule 后，浮動 IP 也會無法工作，因為它們與 router 的 外部端口的綁定關系不會被設置到新的router 上。

   這種方案要求使用多個網絡控制節點，每個節點上運行一個 L3 Agent。在某個 Agent 死了時，Router 會被部署到別的 Agent 上。這種方案，除了上述的問題外，切換時間過長是其主要問題。

（b）Juno 中引入的 VRRP （Virtual Router Redundancy Protocol）方案 （由 VRRP/Keepalived 控制 VR 的 VIP 和 VMAC 的 failover）

    該方案使用多余一個的網絡控制節點，提供 A/P HA。具體請參考我的另一篇文章 理解 OpenStack 高可用（HA）（2）：Neutron L3 Agent HA 之 虛擬路由冗余協議（VRRP）。其主要特點為：

（c）Juno 引入的 DVR

    該方案將 NAT 和 L3 Agent 部署到虛機所在的計算節點，在網絡控制節點上只部署 DHCP 和 SNAT。該方案解決了 L3 Agent 和 Metadata Agent 的 H/A 問題。目前，將 DHCP Agent 改成分布式，VPNaas 以及 FWaas 的修改工作已經在進行中。用戶需要使用第三方軟件提供 SNAT 的 HA 方案。可以參考 理解 OpenStack 高可用（HA）（3）：Neutron 分布式虛擬路由（Neutron Distributed Virtual Routing）。

（3）DHCP Agent 的 HA

    DHCP 協議自身就支持多個 DHCP 服務器，因此，只需要在多個網卡控制節點上，通過修改配置，為每個租戶網絡創建多個 DHCP Agent，就能實現 DHCP 的 HA 了。

（4）Metadata agent 和 proxy 的 HA

跟 metadata service 相關的組件包括：

• neutron-ns-metadata-proxy：作為一個獨立的進程運行在 master virtual router 的 network namespace 中。它接受由 qrouter 通過 iptables 控制轉交的 instance 訪問 metadata service 的 request。
• neutron-metadata-agent：Neutorn 的組件之一，運行在Neutorn 網絡節點上，通過本地 socket 和 neutron-ns-metadata-proxy 進程通信，其配置文件是 /etc/neutron/metadata_agent.ini；它會通過 http(s) 和 Nova metadata service 通信；它通過 RPC 和 neutron-server 通信。你還可以通過配置 metadata_workers 的值來運行多個獨立的進程。
• nova metadata api：這個和 nova api 類似，是 nova 的 API 的一部分，通常使用的端口是 8775。它接收neutron-metadata-agent 的request。

從 HA 角度來講：

• neutron-ns-metadata-proxy 的 HA 不需要單獨考慮，因為它受 Virtual router 控制。
• neutron-metadata-agent：需要和 neutron-ns-metadata-proxy 通過soket 通信，因此，簡單地，可以在所有 neutron network 節點上都運行該 agent，只有 virtual router 所在的L3 Agent 上的 neutron-metadata-agent 才起作用，別的都standby。你可以在多個網絡節點上啟用該服務。
• nova metadata api：同 nova api 一樣是無狀態服務，可以部署在那個階段上，使用 HAProxy 做 A/A HA。

 

（http://techbackground.blogspot.com/2013/06/metadata-via-quantum-router.html）

（注意，因為虛機在啟動過程中需要訪問 qrouter，這也就是說，要求虛機所在的子網必須已經添加到了一個 Virtual router 上，否則，它是無法通過 qrouter 走的，除非走 qdhcp）

或者更詳細地看出完整的路徑（圖中紅色線條，從VM開始，到 NOVA-API Metadata 結束）：

（https://www.hastexo.com/system/files/neutron_packet_flows-notes-handout.pdf）

（5）LBaas Agent HA

    目前 Neutron LBaaS 代理服務是無法通過其自帶的 HAProxy 插件 實現高可用的。實現 HAProxy 高可用常見的方案是使用 VRRP (Virtual Router Redundancy Protocol ，虛擬路由冗余協議)，不過 LBaaS HAProxy 插件目前還不支持該協議。因此，只能使用 Pacemaker + 共享存儲（放置 /var/lib/neutron/lbaas/ 目錄） 的方式來部署 A/P 方式的 LBaas Agent HA，具體請參考 這篇文章 中描述的方法。

2.2.2 使用 Pacemaker 實現 A/P HA

  使用 Pacemaker + Corosync 搭建兩節點（或者多節點） A/P 集群。在主節點上，由 Pacemaker 啟動 Neutron 的各種服務。 

2.2.3 小結

    從上面可以看出，除了 DHCP Agent 天生就通過配置可以實現 A/A HA 以及 L3 HA 以外，其它的組件的 HA 都是 A/P 的，而且實現的技術可以是原生的，也可以使用 Pacemaker，也可以結合起來使用。比如 RDO 的方案：

2.3 存儲控制節點 HA

 這里只討論 cinder-volume。

（1）在使用非共享存儲時，cinder-volume 進程受 Pacemaker 監控，在其停止的時候重啟。這種方案下，存儲控制節點宕機的話，上面的所有卷都會損失掉。因此，在生產環境中，必須使用下一種方案。

（2）在使用共享存儲時，考慮到目前代碼中存在的資源競爭（參考這里），該服務只能實現為 A/P HA 方式，也就是說在某個時刻，只有主節點上的 cinder-volume 在運行。RedHat 這個 ticket 中有具體的分析。目前，cinder-volume 還沒有內在的 HA 實現，只能借助第三方軟件比如 Pacemaker。A/A 的實現在 Liberty 中正在進行，請 參見 和 這個。

2.4 計算節點和虛機 HA

    在測試環境中，我們常常將虛機創建在本地磁盤上，那么，在機器宕機的話，這些虛機將永遠也回不來了。因此，在生產環境中，需要將虛機部署在 cinder-volume 或者共享的存儲比如 RDB 或者 NFS 上。這樣的話，在虛機損壞時，可以從共享存儲上將其恢復（使用 nova evacuate 功能）。 使用 Pacemaker 部署 A/P 方案（類似 2.3 中 cinder-volume A/P HA）的話，生產環境中計算節點的數據往往遠遠超過 Corosync 集群中節點數目的限制。

  業界有幾個解決方案：

（1）Controller 節點通過管理網 Ping 所有 Compute 節點，Controller 節點檢查nova service-list，對出問題的節點 Evacuate

特征：太簡單粗暴，容易引起誤殺和數據損壞

（2）Pacemaker-remote： 突破Corosync的集群規模限制，

特征：啟用多個心跳網時，處理策略單一，引起用戶業務不必要的中斷

（3）集中式檢查

（4）分布式健康檢查

（以上資料來自 基於Fuel的超融合一體機 by 周征晟 / 2015-06-27）

OpenStack 的各提供商中，就該需求，RadHat 使用的是上述的第二種方案，具體方案在 計算節點HA 方案：

   部署方式如下：

• 使用 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. 如果節點啟動成功，執行 'nova service-enable'
6. 如果節點啟動失敗，則執行 ‘nova evacuate’ 把該節點上的虛機移到別的可用計算節點上。

  其中：

• 步驟（1）和 （5）是可選的，其主要目的是防止 nova-scheduler 將新的虛機分配到該節點。
• 步驟（2）保證機器肯定會關機。
• 步驟（3）中目前 nova 需要等待一段較長的超時時間才能判斷節點 down 了。Liberty 中有個 Blueprint 來添加一個 Nova API 將節點狀態直接設置為 down。

  其余一些前提條件：

• 虛機必須部署在 cinder-volume 或者共享的臨時存儲比如 RBD 或者 NFS 上，這樣虛機 evaculation 將不會造成數據丟失。
• 如果虛機不使用共享存儲，則必須周期性地創建虛機的快照並保存到 Glance 中。在虛機損壞后，可以從 Glance 快照上恢復。但是，這可能會導致狀態或者數據丟失。
• 控制和計算節點需要安裝 RHEL 7.1+ 
• 計算節點需要有防護機制，比如 IPMI，硬件狗 等

小結： OpenStack 雲/網絡/存儲 控制節點 HA 集群

3. 部分 OpenStack 方案提供者的 HA 方案

3.1 RDO HA 

這里 有完整的 RDO HA 部署方案：

 

 

該配置最少需要五台機器：

1. 一台（物理或者虛擬）服務器部署 nfs server，dhcp，dns
2. 一台物理服務器來作為計算節點
3. 三台物理服務器組成 pacemaker 集群，創建多個虛機，安裝各種應用 

 特征：

• 每個集群使用三個節點，全部采用 A/A 模式，除了 cinder-volume 和 LBaas。RedHat 不認為 A/P 模式是真正的 HA。
• 提供使用 Pacemaker 或者 Keepalived 兩套方案。
• 將 API 和內部無狀態組件按功能組分布到各個專有集群，而不是放在一個集群上。
• Cinder 這里標識為 A/A HA，但是不包括 cinder-volume。
• 計算節點 HA 使用 2.4 部分描述的 HA 方式。

Service	Process	Mode	HA stragegy
Support services	MariaDB - Galera	A/A	HAProxy / app cluster
Support services	RabbitMQ	A/A	App cluster / service config
Support services	HAProxy	A/A	Keepalived
Support services	MongoDB	A/A	App cluster （ceilometer 和 heat 會使用）
Support services	Memcached	A/A	Service configuration
Keystone	openstack-keystone	A/A	HAProxy
Glance	openstack-glance-api	A/A	HAProxy
Glance	openstack-glance-registry	A/A	HAProxy （向 glance-api 提供 REST API）
Nova	openstack-nova-api	A/A	HAProxy
Nova	openstack-nova-cert	A/A
Nova	openstack-nova-compute	A/A	參見 2.4 部分描述
Nova	openstack-nova-scheduler	A/A
Nova	openstack-nova-conductor	A/A
Nova	openstack-nova-novncproxy	A/A	HAProxy
Cinder	openstack-cinder-api	A/A	HAProxy
Cinder	openstack-cinder-scheduler	A/A
Cinder	openstack-cinder-volume	A/P	No HA （RH 不把 A/P HA 當作HA！）。參考這里
Cinder	openstack-cinder-backup	A/A
Neutron	neutron-server	A/A	HAProxy
Neutron	neutron-dhcp-agent	A/A	Multiple DHCP agents
Neutron	neutron-l3-agent	A/A	L3 HA
Neutron	neutron-metadata-agent	A/A
Neutron	neutron-lbaas-agent	A/P	目前的設計不允許 A/A
Neutron	neutron-openvswitch-agent	A/A
Neutron	neutron-metering-agent	A/A
Horizon	httpd	A/A	HAProxy
Ceilometer	openstack-ceilometer-api	A/A	HAProxy
Ceilometer	openstack-ceilometer-central	A/A	Workload partitioning: tooz + Redis
Ceilometer	openstack-ceilometer-compute	A/A
Ceilometer	openstack-ceilometer-alarm-notifier	A/A
Ceilometer	openstack-ceilometer-evaluator	A/A
Ceilometer	openstack-ceilometer-notification	A/A
Heat	openstack-heat-api	A/A	HAProxy

 

關於 MariaDB：

• 它是數據庫管理系統 MySQL 的一個分支，主要由開源社區在維護，采用 GPL 授權許可。開發這個分支的原因之一是：甲骨文公司收購了 MySQL 后，有將 MySQL 閉源的潛在風險，因此社區采用分支的方式來避開這個風險。
• MariaDB 的目的是完全兼容MySQL，包括 API 和命令行，使之能輕松成為 MySQL 的代替品。除了作為一個Mysql的“向下替代品”，MariaDB包括的一些新特性使它優於MySQL。這篇文章 有 Mysql 和 MariaDB 對比分析。

不由得贊一下 RDO 的文檔！想起來之前去拜訪一個 OpenStack 初創公司，CTO 說他們基本上是參考 RDO 做方案，看起來是很有道理的。

3.2 Mirantis OpenStack 6.0 HA 方案：A/A 方案

Mirantis 推薦在生產環境中使用帶至少三個控制節點的 HA：

其中：

• 使用 Pacemaker 控制 Neutron Agent，實現 A/P HA
• API 服務運行在多個節點上，使用 HAProxy 實現負載均衡，提供 VIP
• RabbitMQ A/A
• Mysql A/A

各 HA 組件之間的關系：

各組件被調用的方式：

（來源：Mirantis 官網）

點評：與 RDO 方案一樣，該 HA 也是一個徹底的 HA 方案，消除了整個系統的 SPOF。但是，與 RDO 相比分散式控制節點相比，Mirantis 的集中式控制節點上運行的服務較多，可能會影響其性能，但是在小規模雲環境中節省了硬件成本。

3.3 HP Helion 的 HA 方案：A/A方案

系統組成：（兩節點 HAProxy + Keepalived 集群） +  第三個控制節點 +（RabbitMQ Cluster + Queue 鏡像）+（Galera + Mysql） 

1. OpenStack 客戶端通過 VIP:8774 訪問 nova-api
2. HAProxy 將請求轉到 controller 0 上的 nova-api
3. nova-api 通過 VIP：3306 訪問 Mysql DB
4. HAProxy 將請求轉到 controller 1 上的 Mysql 實例

點評：HP 的 A/A 方案是不徹底的，甚至是有些怪異（為什么不三個控制節點做一個A/A 集群呢？），因為至少 Horizon、 Ceilomter 和 Neutron Agents 沒有實現 HA，它只實現了 API，DB 和 MQ 的 HA。

3.4 TCP Cloud OpenStack HA

 

特征：

• 系統組成：Pacemaker, Corosync, HAProxy, Galera + IBM 硬件比如 Storwize V7000
• 使用三階段集群 A/A 集群
• 提供 99.99% 的服務可靠性
• 沒看到虛機 HA

來源：TCP 官網

3.5 Paypal OpenStack 生產系統 HA

（來源及高清大圖）

特征：

• 使用硬件負載均衡 F5
• 使用商業 SDN
• 使用 Monit 監控和重啟各服務
• 使用 Pacemaker
• 用在生成系統，優化進行中

3.6 Oracel OpenStack HA：A/P HA

CRM：Oracel Clusterware（Oracle Grid Infrastructure Release 12c Release 1 or later）

組成：兩個控制節點 + 兩個網絡節點組成的集群。除了網絡節點上的組件外，別的組件都部署在控制節點上。

（來源）

結論：該方案比不上前面幾個公司的方案，因為：

• 只提供兩節點 A/P 方案，可靠性和 CTO 比不上三節點方案
• 需要使用共享存儲比如 NFS 來實現 A/P HA 模式的 DB 和 MQ，容易腦裂
• 不使用免費的 Pacemaker，部署成本增加。

3.7 網易 OpenStack 雲的 HA 方案

好不容易找到一個國內公司的方案，來源在 這里：

特征：

• 使用 keepalived 管理的 HAProxy
• 控制節點應該是 A/A HA 方案
• 沒有看到計算節點和網絡控制節點的 HA 方案，似乎沒有用 neutron，而是用 nova-network
• 高可用 RabbitMQ 集群和主備 MySQL，以及 memcache 集群是額外部署的

 3.5 小結

• RDO > Mirantis > HP >> Oracel
• HA 是生產環境中的部署必須有的
• HA 模式方面，A/A HA 方案為主流
• 數據庫方面，Mysql Galera 為主流
• MQ 方面，RabbitMQ 集群 + 鏡像消息隊列為主流
• CRM 方面，Pacemaker 三節點集群是主流
• 負載均衡方面，HAProxy 是主流
• 網絡方面，Neutron 新的 HA 方案包括 VRRP 和 DVR 還未成熟，尚未真正進入生產環境 （2016/10： RedHat OpenStack platform 從Kilo版本就已經正式支持 VRRP，這意味着它已經成熟；但是DVR依然處於 tech preview 狀態）
• 存儲方面，OpenStack 需要解決 cinder-volume 的 A/A 實現
• 計算方面，OpenStack 需要原生的虛機 HA 實現

2016/10/23 一些更新：

1. 社區成立了HA Community：http://docs.openstack.org/ha-guide/ha-community.html
2. 社區已經將虛機的HA作為高優先級工作，相關實現會基於目前已有的各種實現而展開。具體可參考 http://docs.openstack.org/ha-guide/instance-ha.html
3. cinder-volume 的 A/A 模式的工作還在進行中，內容和進度可以參考 https://blueprints.launchpad.net/cinder/+spec/cinder-volume-active-active-support
4. 虛機 HA 有個總結：http://aspiers.github.io/openstack-summit-2016-austin-compute-ha/
5. 目前不同廠商有些可用虛機HA方案：a mistral-based auto-recovery workflow, by Intel,

   masakari, by NTT, 

   OCF RAs, as used by Red Hat and SUSE

這些方案之間的對比：

選擇樹：

4. OpenStack DR

目前，OpenStack 上沒有實現 DR。 IBM 和 RedHat 聯合發起的 DRaas 提議:

狀態：

• 目前沒有詳細的方案，只有一個概要設計，還處於 Gap 識別和補齊階段。
• 具體的實現主要集中在cinder 側元數據（Juno IBM 實現了部分的 Volume Replication 功能）、業務數據同步相關，但是目前進展不樂觀。

可以參考 RedHat 的更多文檔，包括 Preparing for the Worst Case Scenario: A Vision for OpenStack Disaster Recovery 和 Disaster Recovery Enablement in OpenStack。

 

參考鏈接和文檔：

• deepdiveintohighlyavailableopenstackarchitecture-openstacksummitvancouver2015-150520154718-lva1-app6891.pdf
• RDO 官網
• OpenStack 官網
• Mirantis-OpenStack-6.0-ReferenceArchitecture (1).pdf

歡迎大家關注我的個人公眾號：