一.HA服務分類
HA將服務分為兩類：
- 有狀態服務：后續對服務的請求依賴之前對服務的請求，OpenStack中有狀態的服務包括MySQL數據庫和AMQP消息隊列。對於有狀態類服務的HA，如neutron-l3-agent，neutron-metadata-agent、nova-compute，cinder-volume等服務，最簡單的方法就是多節點部署。比如某一節點的nova-compute服務掛了，也並不會影響整個雲平台不能創建虛擬機，或者所在節點的虛擬機無法使用。（比如ssh等）
- 無狀態服務：對服務的請求之間沒有依賴關系，是完全對立的。基於冗余實例和負載均衡實現HA，OpenStack中無狀態的服務包括nova-api，nova-conductor，glance-api，keystone-api，neutron-api，nova-scheduler等。由於API服務，屬於無狀態類服務，天然支持Active/Active HA模式。因此，一般使用keepalived +HAProxy方案來做。
二.HA的類型
HA的類型：
HA需要使用冗余的服務器組成集群來運行負載，包括應用和服務，這種冗余性也可以將HA分為兩類：
- Active/Passive HA：即主備HA，在這種配置下，系統采用主和備用機器來提供服務。系統只在主設備上提供服務，在主設備故障時，備設備上的服務被啟動來替代主設備提供的服務。典型的可以采用CRM軟件比如Pacemaker來控制主備設備之間的切換，並提供一個虛擬機IP來提供服務。
- Avtive/Active HA：即主主HA，包括多節點時成為多主，在這種配置下，系統在集群內所有服務器上運行同樣的負載，以數據庫為例，對於一個實例的更新，會被同步到所有實例上，這種配置下往往采用負載均衡軟件，比如HAProxy來提供服務的虛擬IP
三.OpenStack雲環境的高可用（HA）
雲環境時一個廣泛的系統，包括了基礎設施層，OpenStack雲平台服務層，虛擬機和最終用戶應用層。
雲環境的HA包括：
- 用於應用的HA
- 虛擬機的HA
- OpenStack雲平台服務的HA
- 基礎設施層的HA：電力，空調和防火設施，網絡設備（如交換機、路由器）、服務器設備和存儲設備等。
OpenStack HA架構：
如果從部署層面來划分，OpenStack高可用的內容包括：
- 控制節點（RabbitMQ、Mariadb、Keystone、Nova-API等）
- 網絡節點（neutron_dhcp_agent、neutron_l3_agent、neutron_openvswitch_agent等）
- 計算節點（nova-compute、neutron_openvswitch_agent、虛擬機等）
- 存儲節點 (cinder-volume、swift等)
- 控制節點HA：
在生產環境中，建議至少部署三台控制節點，其余可做計算節點、網絡節點、或存儲節點。采用HAProxy + KeepAlived的方式，代理數據庫服務和OpenStack服務，對外包括VIP提供API訪問。
- RabbitMQ消息隊列HA：
RabbitMQ采用原生Cluster集群方案，所有節點同步鏡像隊列。小規模環境中，三台物理機，其中2個Mem節點主要提供服務，1個Disk節點用於持久化消息，客戶端根據需求分別配置主從策略。據說使用ZeroMQ代替默認的RabbitMQ有助於提升集群消息隊列性能。
- OpenStack API服務HA：
OpenStack控制節點上運行的基本上是API 無狀態類服務，如nova-api、neutron-server、glance-registry、nova-novncproxy、keystone等。因此，可以由 HAProxy 提供負載均衡，將請求按照一定的算法轉到某個節點上的 API 服務，並由KeepAlived提供 VIP。
- 網絡節點HA：
網絡節點上運行的Neutron服務包括很多的組件，比如 L3 Agent，openvswitch Agent，LBaas，VPNaas，FWaas，Metadata Agent 等，其中部分組件提供了原生的HA 支持。
• Openvswitch Agent HA： openvswitch agent 只在所在的網絡或者計算節點上提供服務，因此它是不需要HA的
• L3 Agent HA：成熟主流的有VRRP 和DVR兩種方案
• DHCP Agent HA：在多個網絡節點上部署DHCP Agent，實現HA
• LBaas Agent HA：Pacemaker + 共享存儲（放置 /var/lib/neutron/lbaas/ 目錄） 的方式來部署 A/P 方式的 LBaas Agent HA
- 存儲節點HA
存儲節點的HA，主要是針對cinder-volume、cinder-backup服務做HA，最簡便的方法就是部署多個存儲節點，某一節點上的服務掛了，不至於影響到全局。
- 計算節點和虛擬機 HA
計算節點和虛擬機的HA，社區從2016年9月開始一直致力於一個虛擬機HA的統一方案，但目前仍然沒有一個成熟的方案。實現計算節點和虛擬機HA，要做的事情基本有三件，即。
① 監控
監控主要做兩個事情，一個是監控計算節點的硬件和軟件故障。第二個是觸發故障的處理事件，也就是隔離和恢復。
OpenStack 計算節點高可用，可以用pacemaker和pacemaker_remote來做。使用pacemaker_remote后，我們可以把所有的計算節點都加入到這個集群中，計算節點只需要安裝pacemaker_remote即可。pacemaker集群會監控計算節點上的pacemaker_remote是否 “活着”，你可以定義什么是“活着”。比如在計算節點上監控nova-compute、neutron-ovs-agent、libvirt等進程，從而確定計算節點是否活着，亦或者租戶網絡和其他網絡斷了等。如果監控到某個pacemaker_remote有問題，可以馬上觸發之后的隔離和恢復事件。
② 隔離
隔離最主要的任務是將不能正常工作的計算節點從OpenStack集群環境中移除，nova-scheduler就不會在把create_instance的message發給該計算節點。
Pacemaker 已經集成了fence這個功能，因此我們可以使用fence_ipmilan來關閉計算節點。Pacemaker集群中fence_compute 會一直監控這個計算節點是否down了，因為nova只能在計算節點down了之后才可以執行host-evacuate來遷移虛擬機，期間等待的時間稍長。這里有個更好的辦法，就是調用nova service-force-down 命令，直接把計算節點標記為down，方便更快的遷移虛擬機。
③ 恢復
恢復就是將狀態為down的計算節點上的虛擬機遷移到其他計算節點上。Pacemaker集群會調用host-evacuate API將所有虛擬機遷移。host-evacuate最后是使用rebuild來遷移虛擬機，每個虛擬機都會通過scheduler調度在不同的計算節點上啟動。
當然，還可以使用分布式健康檢查服務Consul等。