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。
