了解 OpenStack 高可用（1）：OpenStack 高可用和災備方案（上）

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 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。其主要特點為：

（c）Juno 引入的 DVR

該方案将 NAT 和 L3 Agent 部署到虛機所在的計算節點，在網絡控制節點上隻部署 DHCP 和 SNAT。該方案解決了 L3 Agent 和 Metadata Agent 的 H/A 問題。目前，将 DHCP Agent 改成分布式，VPNaas 以及 FWaas 的修改工作已經在進行中。使用者需要使用第三方軟體提供 SNAT 的 HA 方案。

（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。

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

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

（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）分布式健康檢查

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 叢集

作者資訊：劉世民（Sammy Liu），IBM 雲架構師，十餘年IT行業從業經曆，在電信、企業軟體、存儲以及雲計算等領域做過研發、管理和架構設計等工作。從 2012 年開始學習 OpenStack，對其核心子產品有較深入的了解；帶領過團隊開發OpenStack子產品。

責編：陳晨 聯系請添加微信：violace95 備注公司 職位 姓名。尋求報道或投稿，請請發送至郵箱：[email protected]