同其它大部分分布式系统一样，OpenStack也分为控制节点和计算节点两种不同功能的节点。控制节点提供除nova-compute以外的服务。这些组件和服务都是可以独立安装的，可以选择组合。
（1）由于CotrolNode只有１个，且负责整个系统的管理和控制，因此当Cotrol Node不能提供正常服务时，怎么办？这就是常见的单节点故障（SPoF，single point of failure）问题。
高可用性基本上是没办法通过一台来达到目标的，更多的时候是设计方案确保在出问题的时候尽快接管故障机器，当然这要付出更大的成本。
对于单点问题，解决的方案一般是采用冗余设备或者热备，因为硬件的错误或者人为的原因，总是有可能造成单个或多个节点的失效，有时做节点的维护或者升级，也需要暂时停止某些节点，所以一个可靠的系统必须能承受单个或多个节点的停止。
常见的部署模式有：Active-passive主备模式，Active-active双主动模式，集群模式。
（2）那么如何构建冗余的控制节点？或者什么其它方法实现高可靠的控制？
很多人可能想到实现active-passive模式，使用心跳机制或者类似的方法进行备份，通过故障转移来实现高可靠性。Openstack是没有多个控制节点的，Pacemaker需要多种服务各自实现这种备份、监听和切换。
仔细分析控制节点提供的服务，主要就是nova-api、nova-network、nova-schedule、nova-volume，以及glance、keysonte和数据库mysql等，这些服务是分开提供的。nova-api、nova-network、glance等可以分别在每个计算节点上工作，RabbitMQ可以工作在主备模式，mysql可以使用冗余的高可用集群。
下面分别介绍：
1）nova-api和nova-scheduler的高可靠性每个计算节点可以运行自己的nova-api和nova-scheduler，提供负载均衡来保证这样正确工作。
这样当控制节点出现故障，计算节点的nova-api等服务都照常进行。2）nova-volume的高可靠性
对于nova-volume目前没有完善的HA（high availability）方法，还需要做很多工作。
不过，nova-volume由iSCSI驱动，这个协议与DRBD结合，或者基于iSCSI的高可靠的硬件解决方案，可以实现高可靠。
3） 网络服务nova-network的高可靠性
OpenStack的网络已经存在多种高可靠的方案，常用的你只需要使用 --multi_host 选项就可以让网络服务处于高可用模式（high availability mode），具体介绍见Existing High Availability Options for Networking。
方案1: Multi-host多主机。每个计算节点上配置nova-network。这样，每个计算节点都会实现NAT, DHCP和网关的功能，必然需要一定的开销，可以与hardware gateway方式结合，避免每个计算节点的网关功能。这样，每个计算节点都需要安装nova-compute外还要nova-network和nova-api，并且需要能连接外网。具体介绍见Nova Multi-host Mode against SPoF。
方案2: Failover故障转移。能够4秒转移到热备份上，详细介绍见https://lists.launchpad.net/openstack/msg02099.html。不足之处是，需要备份机，而且有4秒延迟。
多网卡技术。把VM桥接到多个网络，VM就拥有2种传出路由，实现故障时切换。但是这需要监听多个网络，也需要设计切换策略。
方案4: Hardware gateway硬件网关。需要配置外部网关。由于VLAN模式需要对每个网络有一个网关，而hardware gateway方式只能对所有实例使用一个网关，因此不能在VLAN模式下使用。
方案5： Quantum（OpenStack下一个版本Folsom中）
Quantum的目标是逐步实现功能完备的虚拟网络服务。它暂时会继续兼容旧的nova-network的功能如Flat、Flatdhcp等。但是实现了类似multi_host的功能，支持OpenStack工作在主备模式（active-backup这种高可用性模式）。
Quantum只需要一个nova-network的实例运行，因此不能与multi_host模式共同工作。
Quantum允许单个租户拥有多个私人专用L2网络，通过加强QoS，以后应该能使Hadoop集群很好的在nova节点上工作。
对于Quantum的安装使用，这篇文章Quantum Setup 有介绍。
