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：
在生產環境中，建議至少部署三台控制節點，其余可做計算節點、網絡節點或存儲節點。采用Haproxy + KeepAlived方式，代理數據庫服務和OpenStack服務，對外暴露VIP提供API訪問。
網絡節點HA：
網絡節點上運行的Neutron服務包括很多的組件，比如 L3 Agent，openvswitch Agent，LBaas，VPNaas，FWaas，Metadata Agent 等，其中部分組件提供了原生的HA 支持。
存儲節點HA：
存儲節點的HA，主要是針對cinder-volume、cinder-backup服務做HA，最簡便的方法就是部署多個存儲節點，某一節點上的服務掛了，不至於影響到全局。
計算節點：
監控、隔離、恢復
MySQL數據庫HA：
外部訪問通過Haproxy的active + backend方式代理
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。