OpenStack是目前基于开源的，一个非常流行的云管理平台项目。这个项目由几个主要的组件组合起来完成一些具体的工作。因此它的集群比较复杂，也有多种选择方式。OpenStack 作为一个类似于 Amazon EC2 和 S3 的云基础架构服务(Infrastructure as a Service, IaaS)，现在越来越多的企业正在搭建OpenStack平台来提高IT运行效率和降低IT成本。本文希望帮助大家快速了解OpenStack集群，并以此结合相关软件的官方文档来搭建一个高可用性的云管理平台。

1. OpenStack高可用性相关概念 

1.1 高可用性系统

高可用系统至少关注以下两个问题:

系统宕机时间―系统服务无法访问的时间总和。

数据丢失―意外删除或破坏数据。

高可用性的一个关键方面是消除单点故障(SPOFs)。SPOF是单个的设备或软件故障将导致系统停机时间或数据丢失。为了消除单点故障，必须存在如下必要的冗余:

网络组件，如交换机和路由器

应用程序和自动服务迁移

存储组件

设施服务，如电力、空调、消防

高可用性系统通常达到99.99%或更多的正常运行时间，这大约相当于每年累计停机不到一个小时。为了实现这一目标，应保持高可用性系统发生故障后恢复时间约一到两分钟，有时更少。

对于基础设施服务来说，如果实现了必要的冗余，OpenStack目前能满足这样的可用性需求，这意味着OpenStack提供的各项服务的正常运行时间的99.99%是可用的。 然而，OpenStack并不能保证运行于基础设施上的个人的虚拟机实例99.99%的可用性。

1.2 无状态和有状态服务

无状态的服务是提供一个你的响应请求后，不需要进一步关注。无状态服务的高可用性，您需要提供冗余实例和负载均衡。 OpenStack无状态的服务包括nova-api，nova-conductor，glance-api，keystone-api，neutron-api nova-scheduler。

一个有状态的服务，后续请求将依赖于第一个请求的结果。有状态的服务管理更困难，因为一个行动通常涉及多个请求，所以只是提供额外的实例和负载均衡不会解决这个问题。例如Horizon 服务，如果用户界面重置了，后续任务被引导去了一个新服务器，它是没有用的。OpenStack有状态的服务包括OpenStack数据库和消息队列。

1.3 主动/被动

在一个主动/被动配置里，需要安装一个备用机，备用机通常处于待机状态，当主机宕机后，备用机启动提供服务。额外的应用需要安装(如: Pacemaker 或 Corosync)来监控这些服务，并必要时启动备用机来提供服务。

1.4 主动/主动

在主动/主动模式下，系统也需要备用机，但将同时管理主机和冗余系统。 这样，如果有一个失败了，用户不太可能注意到。 因为备份系统已经上线。 通常对于一个无状态的服务来说，使用一个虚拟IP地址和HAProxy等负载均衡器来达到负载均衡。 对于一个有状态的服务来说，需要保证包括冗余服务所有实例都有一个相同的状态。例如，更新数据库的一个实例也会更新所有其他实例。

2. 使用主动/被动，主动/主动混合模式实现集群

这只是一个实例来实现这些高可用性架构，但他们绝不是唯一的方法。首先做一下环境的假设，如图1所示一共有四个服务器，两个云控制器节点组成一个集群，两个网络节点组成一个集群，图中列出了一些主要的OpenStack组件。本例中没有列出计算结点，因为计算结点不需要配置集群。集群中的每一个OpenStack服务可以采用不同的模式，本例部分采用主动/主动模式，部分采用主动/被动模式。

图1  集群示例图

2.1 采用主动/主动的组件

2.1.1 使用Galera实现MySQL的集群

Galera是一个MySQL(也支持MariaDB，Percona)的同步多主集群软件。主要功能有:同步复制，并行复制，所有节点可以同时读写数据库，新节点加入数据自动复制， 失效节点自动被清除， 可以直接连接集群，使用感受上与MySQL完全一致。

你可以安装带有wsrep(Write Set REPlication)补丁的MySQL版本。从如下地址可以下载到 https://launchpad.net/codership-mysql/0.7。由于Wsrep API支持同步复制，很适合用于配置OpenStack里MySQL高可用性。首先你可以启动一个实例来创建集群，然后其它的MySQL实例连接到这个集群。因为Galera mysql用到了领导机选举机制quorum，所以对于这个service来说至少需要三个控制结点。

2.1.2 RabbitMQ

RabbitMQ是默认的AMQP服务器，被许多OpenStack服务所使用。使RabbitMQ服务高可用性包括三个步骤: 安装RabbitMQ ，为HA队列配置RabbitMQ ，使用Rabbit HA队列配置OpenStack服务。

我们可以建立一个RabbitMQ的集群来构造一个RabbitMQ broker。可以创建至少两个的RabbitMQ 服务器。为了构造一个broker，我们必须确保所有的结点有相同的Erlang cookie文件。你可以停止所有的RabbitMQ，然后从rabbit一台服务器复制cookie到其它服务器上。我们必须配置openstack组件使用至少两个RabbitMQ结点。

2.1.3 HAProxy结点

HAProxy是一个非常快速和可靠的高可用性解决方案、支持负载均衡，并为基于TCP和http的应用程序提供代理。它特别适合高负荷的web站点，足以支持数以万计的连接访问。

  你需要至少两个结点来运行HAProxy，可以分别运行于图1中的cloud controller node A和B上。你可以通过访问cluster的虚拟IP访问相关的openstack服务，虚拟IP和服务结点的关联就是通过HAProxy的配置文件实现的。 具体配置可参考官方文档。

2.1.4 API服务

所有OpenStack项目都有一个API服务用来控制云中的所有资源。 在主动/主动模式中，最常见的设置是扩展这些服务到至少两个节点上，并且使用负载平衡和虚拟IP(HAProxy & keepalived相关配置)。为了使我们的云高可用并且可扩展，我们必须确保:

当配置OpenStack Identity endpoints的时候，使用虚拟IP。

所有的OpenStack配置文件都会涉及到虚拟 IP。

2.1.5 调度程序

OpenStack调度器用于确定如何调度计算，网络和存储卷。最常见的设置是使用RabbitMQ作为消息系统。以下这些服务可连接到消息服务，请参考RabbitMQ配置方法进行配置:

nova-scheduler

nova-conductor

cinder-scheduler

neutron-server

ceilometer-collector

heat-engine 

2.1.6 Memcached

大多数OpenStack服务都会使用一个应用程序用于存储持久和临时数据(如令牌)。 Memcached就是其中一个， Memcached容易扩展并且不需要任何特殊的技巧。可参考官方文档进行安装和配置。

2.2 采用主动/被动的组件

2.2.1 安装和配置Pacemaker 集群管理软件

  主动/被动模式下，需要先安装和配置Pacemaker 集群管理软件。Pacemaker是Linux平台下的先进的高可用性和负载均衡管理软件。Pacemaker集群中的所有主机上，必须通过Corosync消息传递层建立集群通信。这涉及到安装以下软件包(以及和他们有依赖关系的软件包，通常你的包管理器会安装自动):

pacemaker

crmsh

corosync

cluster-glue

fence-agents(只适用于Fedora;所有其他发行版都使用cluster-glue)

resource-agents

安装完软件包之后，你需要设置Corosync，然后启动Corosync，最后启动Pacemaker。一旦Pacemaker服务已经开始，Pacemaker将创建一个默认空集群配置，没有资源。一旦你的Pacemaker集群已经创建，你就可以设置一些基本集群属性。具体配置可参考官方文档。

2.2.2 网络集群组件

a) Neutron L3 agent的高可用性

  Neutron L3 agent提供了L3/NAT 转发，确保租户能访问到他们的虚拟机。通过采用Pacemaker来实现高可用。你需要把neutron L3 agent 资源加入到Pacemaker 集群。

b) Neutron DHCP agent的高可用性

  Neutron DHCP agent通过dnsmasq来分发IP地址给虚拟机。你也需要把neutron DHCP agent 资源加入到Pacemaker集群。

c) Neutron metadata agent的高可用性

  Neutron metadata agent 允许租户网络上的虚拟机访问 Compute API 元数据。 你需要把neutron metadata agent 资源加入到Pacemaker集群。

2.2.3 管理网络资源

你现在可以增加一个组来管理所有的网络资源。可以通过crm configure 命令连接到Pacemaker集群来创建组。

3.小结

  采用主动/主动的服务通常通过建立HAProxy及设置虚拟IP来达到高可用的效果，而采用主动/被动的服务则通过创建Pacemaker集群来达到高可用的效果。采用主动/主动的服务通常支持负载均衡，集群中的服务器被充分利用。而如果采用主动/被动的服务，那么主机和备机之间的切换需要一定的时间。实际应用中可以尽可能的选择主动/主动服务。本例中只有网络部分选择的是主动/被动服务，原因是目前OpenStack还不支持主动/主动的网络服务。如果有的企业比较注重用电的开支，也可以适当选用主动/被动的服务。主动/被动模式下，备机通常可以处在关机待命状态下以节省用电量。