本系列會分析OpenStack 的高可用性（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。
HA 将服務分為兩類：
有狀态服務：後續對服務的請求依賴于之前對服務的請求。
無狀态服務：對服務的請求之間沒有依賴關系，是完全獨立的。
HA 需要使用備援的伺服器組成叢集來運作負載，包括應用和服務。這種備援性也可以将 HA 分為兩類：
Active/Passive HA：叢集隻包括兩個節點簡稱主備。在這種配置下，系統采用主和備用機器來提供服務，系統隻在主裝置上提供服務。在主裝置故障時，備裝置上的服務被啟動來替代主裝置提供的服務。典型地，可以采用 CRM 軟體比如 Pacemaker 來控制主備裝置之間的切換，并提供一個虛機 IP 來提供服務。
Active/Active HA：叢集隻包括兩個節點時簡稱雙活，包括多節點時成為多主（Multi-master）。在這種配置下，系統在叢集内所有伺服器上運作同樣的負載。以資料庫為例，對一個執行個體的更新，會被同步到所有執行個體上。這種配置下往往采用負載均衡軟體比如 HAProxy 來提供服務的虛拟 IP。
雲環境包括一個廣泛的系統，包括硬體基礎設施、IaaS層、虛機和應用。以 OpenStack 雲為例：
雲環境的 HA 将包括：
應用的 HA
虛機的 HA
雲控制服務的 HA
實體IT層：包括網絡裝置比如交換機和路由器，儲存設備等
基礎設施，比如電力、空調和防火設施等
本文的重點是讨論 OpenStack 作為 IaaS 的 HA。
幾個概念：
災難（Disaster）是由于人為或自然的原因，造成一個資料中心内的資訊系統運作嚴重故障或癱瘓，使資訊系統支援的業務功能停頓或服務水準不可接受、達到特定的時間的突發性事件，通常導緻資訊系統需要切換到備用場地運作。
災難恢複（Diaster Recovery）是指當災難破壞生産中心時在不同地點的資料中心内恢複資料、應用或者業務的能力。
容災是指，除了生産站點以外，使用者另外建立的備援站點，當災難發生，生産站點受到破壞時，備援站點可以接管使用者正常的業務，達到業務不間斷的目的。為了達到更高的可用性，許多使用者甚至建立多個備援站點。
衡量容災系統有兩個主要名額：RPO（Recovery Point Objective）和 RTO（Recovery Time Object），其中 RPO代表 了當災難發生時允許丢失的資料量，而 RTO 則代表了系統恢複的時間。RPO 與 RTO 越小，系統的可用性就越高，當然使用者需要的投資也越大。
大體上講，容災可以分為3個級别：資料級别、應用級别以及業務級别。
級别
定義
RTO
CTO
資料級
指通過建立異地容災中心，做資料的遠端備份，在災難發生之後要確定原有的資料不會丢失或者遭到破壞。但在資料級容災這個級别，發生災難時應用是會中斷的。
在資料級容災方式下，所建立的異地容災中心可以簡單地把它了解成一個遠端的資料備份中心。資料級容災的恢複時間比較長，但是相比其他容災級别來講它的費用比較低，而且建構實施也相對簡單。
但是，“資料源是一切關鍵性業務系統的生命源泉”，是以資料級容災必不可少。
RTO 最長(若幹天) ，因為災難發生時，需要重新部署機器，利用備份資料恢複業務。
最低
應用級
在資料級容災的基礎之上，在備份站點同樣建構一套相同的應用系統，通過同步或異步複制技術，這樣可以保證關鍵應用在允許的時間範圍内恢複運作，盡可能減少災難帶來的損失，讓使用者基本感受不到災難的發生，這樣就使系統所提供的服務是完整的、可靠的和安全的。
RTO 中等（若幹小時）
中等。異地可以搭建一樣的系統，或者小些的系統。
業務級
全業務的災備，除了必要的 IT 相關技術，還要求具備全部的基礎設施。其大部分内容是非IT系統（如電話、辦公地點等），當大災難發生後，原有的辦公場所都會受到破壞，除了資料和應用的恢複，更需要一個備份的工作場所能夠正常的開展業務。
RTO 最小（若幹分鐘或者秒）
最高
兩者互相關聯，互相補充，互有交叉，同時又有顯著的差別：
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 是保證資料可靠的基礎上的業務可用。
Master SQL Server 發生故障時，切換到 Standby SQL Server，繼續提供資料庫服務：
在主機房中心發生災難時，切換到備份機房（總公司機房中心）上，恢複應用和服務：
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。
雲控制節點上運作的服務中，API 服務和内部工作元件都是無狀态的，是以很容易就可以實作 A/A HA；這樣就要求 Mysql 和 RabbitMQ 也實作 A/A HA，而它們各自都有 A/A 方案。但是，Mysql Gelera 方案要求三台伺服器。如果隻想用兩台伺服器的話，則隻能實作 A/P HA，或者引入一個 Arbiter 來做 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 服務來看：
（1）根據該文章中的一個調查，被調查的 220 多個使用者中，200 個在用 Mysql Galera，20 多個在用單 Mysql，隻有一個用 PostgreSQL。
（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 服務無縫整合在一起
該 HA 方案的問題是：
主備切換需要較長的時間
隻有主提供服務，在使用兩個節點的情況下不能做負載均衡
DRBD 腦裂會導緻資料丢失的風險。A/P 模式的 Mysql 的可靠性沒有 Mysql Galera 高。
是以，可以看到實際部署中，這種方案用得較少，隻看到 Oracel 在使用這種方案。
Neutron 包括很多的元件，比如 L3 Agent，L2 Agent，LBaas，VPNaas，FWaas，Metadata Agent 等 Neutron 元件，其中部分元件提供了原生的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）
（c）Juno 引入的 DVR
（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
使用 Pacemaker + Corosync 搭建兩節點（或者多節點） A/P 叢集。在主節點上，由 Pacemaker 啟動 Neutron 的各種服務。
從上面可以看出，除了 DHCP Agent 天生就通過配置可以實作 A/A HA 以及 L3 HA 以外，其它的元件的 HA 都是 A/P 的，而且實作的技術可以是原生的，也可以使用 Pacemaker，也可以結合起來使用。比如 RDO 的方案：
這裡隻讨論 cinder-volume。
（1）在使用非共享存儲時，cinder-volume 程序受 Pacemaker 監控，在其停止的時候重新開機。這種方案下，存儲控制節點當機的話，上面的所有卷都會損失掉。是以，在生産環境中，必須使用下一種方案。
在測試環境中，我們常常将虛機建立在本地磁盤上，那麼，在機器當機的話，這些虛機将永遠也回不來了。是以，在生産環境中，需要将虛機部署在 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）
部署方式如下：
使用 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 會依次：
運作 'nova service-disable'
将該節點關機
等待 nova 發現該節點失效了
将該節點開機
如果節點啟動成功，執行 'nova service-enable'
如果節點啟動失敗，則執行 ‘nova evacuate’ 把該節點上的虛機移到别的可用計算節點上。
其中：
步驟（1）和 （5）是可選的，其主要目的是防止 nova-scheduler 将新的虛機配置設定到該節點。
步驟（2）保證機器肯定會關機。
其餘一些前提條件：
虛機必須部署在 cinder-volume 或者共享的臨時存儲比如 RBD 或者 NFS 上，這樣虛機 evaculation 将不會造成資料丢失。
如果虛機不使用共享存儲，則必須周期性地建立虛機的快照并儲存到 Glance 中。在虛機損壞後，可以從 Glance 快照上恢複。但是，這可能會導緻狀态或者資料丢失。
控制和計算節點需要安裝 RHEL 7.1+
計算節點需要有防護機制，比如 IPMI，硬體狗 等
小結： OpenStack 雲/網絡/存儲 控制節點 HA 叢集
該配置最少需要五台機器：
一台（實體或者虛拟）伺服器部署 nfs server，dhcp，dns
一台實體伺服器來作為計算節點
三台實體伺服器組成 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
RabbitMQ
App cluster / service config
HAProxy
Keepalived
MongoDB
App cluster （ceilometer 和 heat 會使用）
Memcached
Service configuration
Keystone
openstack-keystone
Glance
openstack-glance-api
openstack-glance-registry
HAProxy （向 glance-api 提供 REST API）
Nova
openstack-nova-api
openstack-nova-cert
openstack-nova-compute
參見 2.4 部分描述
openstack-nova-scheduler
openstack-nova-conductor
openstack-nova-novncproxy
Cinder
openstack-cinder-api
openstack-cinder-scheduler
openstack-cinder-volume
A/P
openstack-cinder-backup
Neutron
neutron-server
neutron-dhcp-agent
Multiple DHCP agents
neutron-l3-agent
L3 HA
neutron-metadata-agent
neutron-lbaas-agent
目前的設計不允許 A/A
neutron-openvswitch-agent
neutron-metering-agent
Horizon
httpd
Ceilometer
openstack-ceilometer-api
openstack-ceilometer-central
Workload partitioning: tooz + Redis
openstack-ceilometer-compute
openstack-ceilometer-alarm-notifier
openstack-ceilometer-evaluator
openstack-ceilometer-notification
Heat
openstack-heat-api
關于 MariaDB：
它是資料庫管理系統 MySQL 的一個分支，主要由開源社群在維護，采用 GPL 授權許可。開發這個分支的原因之一是：甲骨文公司收購了 MySQL 後，有将 MySQL 閉源的潛在風險，是以社群采用分支的方式來避開這個風險。
不由得贊一下 RDO 的文檔！想起來之前去拜訪一個 OpenStack 初創公司，CTO 說他們基本上是參考 RDO 做方案，看起來是很有道理的。
Mirantis 推薦在生産環境中使用帶至少三個控制節點的 HA：
其中：
使用 Pacemaker 控制 Neutron Agent，實作 A/P HA
API 服務運作在多個節點上，使用 HAProxy 實作負載均衡，提供 VIP
RabbitMQ A/A
Mysql A/A
各 HA 元件之間的關系：
各元件被調用的方式：
點評：與 RDO 方案一樣，該 HA 也是一個徹底的 HA 方案，消除了整個系統的 SPOF。但是，與 RDO 相比分散式控制節點相比，Mirantis 的集中式控制節點上運作的服務較多，可能會影響其性能，但是在小規模雲環境中節省了硬體成本。
系統組成：（兩節點 HAProxy + Keepalived 叢集） + 第三個控制節點 +（RabbitMQ Cluster + Queue 鏡像）+（Galera + Mysql）
OpenStack 用戶端通過 VIP:8774 通路 nova-api
HAProxy 将請求轉到 controller 0 上的 nova-api
nova-api 通過 VIP：3306 通路 Mysql DB
HAProxy 将請求轉到 controller 1 上的 Mysql 執行個體
點評：HP 的 A/A 方案是不徹底的，甚至是有些怪異（為什麼不三個控制節點做一個A/A 叢集呢？），因為至少 Horizon、 Ceilomter 和 Neutron Agents 沒有實作 HA，它隻實作了 API，DB 和 MQ 的 HA。
特征：
系統組成：Pacemaker, Corosync, HAProxy, Galera + IBM 硬體比如 Storwize V7000
使用三階段叢集 A/A 叢集
提供 99.99% 的服務可靠性
沒看到虛機 HA
使用硬體負載均衡 F5
使用商業 SDN
使用 Monit 監控和重新開機各服務
使用 Pacemaker
用在生成系統，優化進行中
CRM：Oracel Clusterware（Oracle Grid Infrastructure Release 12c Release 1 or later）
組成：兩個控制節點 + 兩個網絡節點組成的叢集。除了網絡節點上的元件外，别的元件都部署在控制節點上。
結論：該方案比不上前面幾個公司的方案，因為：
隻提供兩節點 A/P 方案，可靠性和 CTO 比不上三節點方案
需要使用共享存儲比如 NFS 來實作 A/P HA 模式的 DB 和 MQ，容易腦裂
不使用免費的 Pacemaker，部署成本增加。
使用 keepalived 管理的 HAProxy
控制節點應該是 A/A HA 方案
沒有看到計算節點和網絡控制節點的 HA 方案，似乎沒有用 neutron，而是用 nova-network
高可用 RabbitMQ 叢集和主備 MySQL，以及 memcache 叢集是額外部署的
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 一些更新：
這些方案之間的對比：
選擇樹：
狀态：
目前沒有詳細的方案，隻有一個概要設計，還處于 Gap 識别和補齊階段。
具體的實作主要集中在cinder 側中繼資料（Juno IBM 實作了部分的 Volume Replication 功能）、業務資料同步相關，但是目前進展不樂觀。
參考連結和文檔：
deepdiveintohighlyavailableopenstackarchitecture-openstacksummitvancouver2015-150520154718-lva1-app6891.pdf
RDO 官網
OpenStack 官網
Mirantis-OpenStack-6.0-ReferenceArchitecture (1).pdf
本文轉自SammyLiu部落格園部落格，原文連結：http://www.cnblogs.com/sammyliu/p/4741967.html，如需轉載請自行聯系原作者