总体来说，OpenStack服务提供无状态服务并且通过提供冗余实例、使其负载均衡将其管理成为有状态的服务。但是，由于涉及到服务需求的复杂动作管理这些服务是困难的。本章中我们将基于主备配置使有状态服务高可用。
主备配置意味着当其他资源失败时需要启动额外的资源上线。不管任何时候必要时，Pacemaker或者是Corosync应用被用来启动备份资源重新上线。通过一系列譬如Pacemaker和Corosync的组件将会获得高可用特性。
除了Pacemaker集群的配置、集群资源以及他们的代理，我们将同样会涵盖启动顺序、故障切换与恢复、以及隔离机制。
本章中，我们将会涵盖以下主题：
- 安装Corosync和Pacemaker
- 高可用MySQL负载均衡
- 依托AMQP的高可用RabbitMQ
安装Corosync和Pacemaker 在安装之前，我们应当了解这种实验性安装的前提条件。
- 实验性安装的要求
在这个实验当中，我们将会建立两个都安装有Ubuntu 12.04 LTS操作系统节点集群。创建完成这两个节点后，分别以controller_1和controller_2命名并分别给他们分配IP地址192.168.56.101和192.168.56.102。接着分配第三个IP地址192.168.1.32作为虚拟IP地址。
- SSH的安装
我们可以安装SSH通过秘钥交换来访问其他所有节点，使得节点上的主机文件看起来如下所示。
|sudo nano /etc/hosts
打开host文件后，按照下面的终端截图做出修改。
- 安装Corosync包文件
为了使任意一个主机节点成为pacemaker集群的一部分，我们需要通过Corossync建立集群通信，涉及以下包文件的安装：
|sudo apt-get install pacemaker corosync crmsh -y
下图表明Pacemaker的安装是成功的。
- 共用和生成Corosync秘钥
作为初始的安装步骤，Corosync秘钥必须要生成并且在集群中其他所有的节点上共用。有必要登陆每一个Corosync节点，然后安全的集群通信就以一种加密的方式完成了。接着这个秘钥就会被分发到集群当中的各个节点。
|corosync –keygen
现在将秘钥共享至node2(controller_2):
rsync -a /etc/corosync/authkey controller_2:/etc/corosync/
- 创建配置文件
现在我们需要为Corosync创建配置文件，该文件位于/etc/corosync/corosync.cong。使用Ubuntu操作系统中的任意一个编辑器(vi,nano或者是gedit等等)来编辑该配置文件。
sudo nano /etc/corosync/corosync.conf
根据我们的安装步骤按照下图对集群的名称和IP地址进行修改。
- 启动Corosync
为了确保corosync的可连接性，我们有一对工具corosycn-ctgtool和corosync-objctl。corosycn-ctgtool工具可以用来检查集群的健康，像启动一个普通的系统服务来启动corosync服务，如下所示：
|sudo /etc/init.d/corosync start
corosync-objctl工具将会按如下所示，列出成员列表
corosync-objctl runtime.totem.pg.mrp.srp.members
- 启动Pacemaker
Corosync启动后，必须建立通信来检查集群通信是否正常，添加Pacemaker到Corosync的目的是处理集群中节点的故障切换。用下面的命令启动Pacemaker：
sudo nano /etc/init.d/pacemaker start
Pacemaker服务成功启动后，它将会默认地创建一个空的集群配置。这个集群没有任何资源，我们在终端上使用crm工具来检查这个集群的状态：
|crm_mon
- 设置集群属性
借助crm shell需要为pacemaker集群设置基础的集群属性，使用配置命令来更改配置文件。如以下是一些集群属性：
·no-quorum-policy=”ignore”:当我们正在使用一个两节点的集群时，这个属性值设置为忽略，如果我们设置这个值，两个节点都会保持在线而且两者之间会失去通信。当我们在集群中使用三个及以上的节点时这个值将会被设置。
·pe-warn-series-max=”1000″,pe-input-series-max=”1000″和pe-error-series-max=”1000″：设置这些值成1000向Pacemaker发送请求维持一长段由集群处理过的输入历史。
·cluster-recheck-interval=”5min”:设置这个值来处理集群状态需要一种事件驱动的方法，它用来使Pacemaker动作在自定义的间隔发生。我们可以根据集群需求改变这个值或者间隔，就像下面的截图那样：
|crm-configure
- 高可用MySQL负载均衡
许多OpenStack服务使用MySQL作为默认的数据库服务器，当任何一个节点负荷过载或者因为某些原因失败时，负载均衡是必要的。为了管理这种故障切换，我们需要部署一种如下所述被称为高可用的解决方案。为了使得这种MySQL数据库服务器高可用，它需要配置DRB服务（分布式复制块服务）如在接下来章节解释的那样。
- DRBD复制存储
通过DRDB完成磁盘间的数据复制，在我们的案列中，磁盘/dev/sdb存在于controller_1和controller_2上。我们需要使用以下命令编辑DRDB配置文件。
sudo gedit /etc/drbd.conf
配置文件看起来像下面所示：
C协议用来在设备间创建连接，并且它被用作为是复制协议。此后，我们要为复制初始化输入一些DRBD命令里，列举如下：
drbdam create-md mysql
一旦执行了前面的命令，我们将会得到初始设备创建。
然后，我们需要用下面的命令开始任一节点上的复制，在controller_1或者controller_2上：
drbdam- –force primary mysql
现在复制已经开始了。然后，我们需要如下命令来检查复制的状态
cat /proc/drbd
- 安装MySQL
用以下命令两个节点（controller_1和controller_2）上完成安装：
sudo apt-get install mysql-server
接着，我们将会把虚拟IP添加到my.cnf中，示例如下：
sudo gedit /etc/my.cnf
bind-address = 192.168.1.32
上面的更改需要在mysql bind-address中完成来监听Pacemaker.所以它能够明白MySQL用来和Pacemaker通信的IP地址是什么。
因此,MySQL的地址将会被绑定到提到的地址。
添加MySQL资源到Pacemaker。
此后，我们将会为MySQL资源添加Pacemaker配置到集群中。使用crm配置，连接Pacemaker集群并添加以下集群资源。
primitive p_ip_mysql ocf:heartbeat:IPaddr2 \
params ip=”192.168.1.32″ cidr_netmask=”24″ \
op monitor interval=”30s”
primitive p_drbd_mysql ocf:linbit:drbd \
params drbd_resource=”mysql” \
op start timeout=”90s” \
op stop timeout=”180s” \
op promote timeout=”180s” \
op demote timeout=”180s” \
op monitor interval=”30s” role=”Slave” \
op monitor interval=”29s” role=”Master”
primitive p_fs_mysql ocf:heartbeat:Filesystem \
params device=”/dev/drbd/by-res/mysql” \
directory=”/var/lib/mysql” \
fstype=”xfs” \
options=”relatime” \
op start timeout=”60s” \
op stop timeout=”180s” \
op monitor interval=”60s” timeout=”60s”
primitive p_mysql ocf:heartbeat:mysql \
params additional_parameters=”–bind-address=192.168.42.101″ \
config=”/etc/mysql/my.cnf” \
pid=”/var/run/mysqld/mysqld.pid” \
socket=”/var/run/mysqld/mysqld.sock” \
log=”/var/log/mysql/mysqld.log” \
op monitor interval=”20s” timeout=”10s” \
op start timeout=”120s” \
op stop timeout=”120s”
group g_mysql p_ip_mysql p_fs_mysql p_mysql
ms ms_drbd_mysql p_drbd_mysql \
meta notify=”true” clone-max=”2″
colocation c_mysql_on_drbd inf: g_mysql ms_drbd_mysql:Master
order o_drbd_before_mysql inf: ms_drbd_mysql:promote g_mysql:start
添加集群细节到mysql中之后，我们将会得到如下所示的状态。
一旦配置已经被执行，集群将会启动资源，如果正常运行，你应该会有MySQL运行在其中一个节点上，可以用过虚拟IP地址来访问。如果集群中任何一个激活的节点的通信丢失发生，那个节点将会被从集群中移除或者隔离开。通过隔离机制，被隔离开的节点将会完全从集群孤立出来。
为了检查集群的状态，输入以下命令：
|crm_mon -1
- 依托AMQP的高可用RabbitMQ
AMQP服务器通过RabbitMQ被用作许多的OpenStack服务的默认的服务器。通过配置DRDB设备，使得服务高可用。
- 配置DRDB
DRDB的配置包括以下几点：
- RabbitMQ可以使用已配置的DRDB设备
- 属于本RabbitMQ设备的数据路径可以被这种配置所使用
- 在集群节点间虚拟IP以自由的方式选择和分配浮动IP
使用以下命令来完成RabbitMQ DRDB资源配置
sado nano /etc/drbd.d/rabbit.res
rabbitmq路径为基于Pacemaker的rabbirmq服务器从DRDB资源加载，rabbirmq服务器资源的配置示例如下：
前文提到的在集群节点controller_1和controller_2的资源使用一个叫做/dev/data/rabbitmq的备份设备。我们将会在之前指定的目录下使用下列命令创建一个初始化设备，将初始元数据集写入rabiimq设备：
drbdadm create-ms rabbitmq
- 创建文件系统
一旦成功运行DRDB资源就需要文件系统就绪，需要为在RabbitMQ中可获取的数据创建文件系统。将这个步骤看成是文件系统创建过程的一个基础步骤：
mkfs -t xfs /dev/drbd1
既然资源的名称是自解释的，我们可以通过以下命令为一个初始化的DRDB使用备选的设备路径：
mkfs -t xfs /dev/drbd/by-res/rabbitmq
为了使设备返回集群中第二个正在运行的进程，使用以下命令：
drbdadm secondary rabbitmq
- 为Pacemaker的高可用特性准备RabbitMQ
为确保Pacemaker的监听功能，我们需要检查controller_1和controller_2上的erlang.cookie文件是一致的。所以，erlang.cookie文件从controller_1节点拷贝到controller_2节点、拷贝到RabbitMQ数据目录和DRDB文件系统，示例如下：
erlang.cookie文件需要从一个节点拷贝到另一个节点：
scp -p /var/lib/rabbitmq/.erlang.cookie controller_2:/var/lib/rabbitmq
使用以下命令来加载一个rabbitmq目录：
mount /dev/drbd/by-res/rabbitmq /mnt
拷贝erlang.cookie使它能够在一个新的设备上被加载，使用以下命令：
sudo cp -a /var/lib/rabbitmq/.erlang.cookie /mnt
最后，卸载一个添加了的目录，示例如下：
sudo unmount /mnt
- 添加RabbitMQ资源到Pacemaker
现在我们添加Pacemaker配置到RabbitMQ资源，使用crm工具来配置和添加以下几行到集群资源，示例如下：
|crm configure
在这些代码之后，在终端输入之前的命令：
primitive p_ip_rabbitmq ocf:heartbeat:IPaddr2 \
params ip=”192.168.1.32″ cidr_netmask=”24″ \
op monitor interval=”10s”
primitive p_drbd_rabbitmq ocf:linbit:drbd \
params drbd_resource=”rabbitmq” \
op start timeout=”90s” \
op stop timeout=”180s” \
op promote timeout=”180s” \
op demote timeout=”180s” \
op monitor interval=”30s” role=”Slave” \
op monitor interval=”29s” role=”Master”
primitive p_fs_rabbitmq ocf:heartbeat:Filesystem \
params device=”/dev/drbd/by-res/rabbitmq” \
directory=”/var/lib/rabbitmq” \
fstype=”xfs” options=”relatime” \
op start timeout=”60s” \
op stop timeout=”180s” \
op monitor interval=”60s” timeout=”60s”
primitive p_rabbitmq ocf:rabbitmq:rabbitmq-server \
params nodename=”rabbit@localhost” \
mnesia_base=”/var/lib/rabbitmq” \
op monitor interval=”20s” timeout=”10s”
group g_rabbitmq p_ip_rabbitmq p_fs_rabbitmq p_rabbitmq
ms ms_drbd_rabbitmq p_drbd_rabbitmq \
meta notify=”true” master-max=”1″ clone-max=”2″
colocation c_rabbitmq_on_drbd inf: g_rabbitmq ms_drbd_rabbitmq:Master
order o_drbd_before_rabbitmq inf: ms_drbd_rabbitmq:promote g_rabbitmq:start
前述的配置文件在集群中产生了以下重要的更改：
- p_ip_rabbitmq:通过这个参数，RabbitMQ将会使用虚拟IP地址
- p_fs_rabbitmq:通过这个参数，RabbitMQ当前正在运行的节点文件系统将会被加载
- ms_drbd_rabbitmq:通过这个参数，rabbitmq DRDB服务会被主/从集所管理。
使用其他的限制比如服务组、顺序和排列来保证每个节点上的所有的资源以正常的序列正常启动。
|crm configure
在使用crm配置工具做出所有的修改，我们通过输入提交命令来提交配置：
|commit
- 为高可用RabbitMQ配置OpenStack服务
现在OpenStack提供的所有服务指向RabbitMQ配置，其高可用性是借助于虚拟IP地址取代了物理IP地址而实现的，。
例如，OpenStack image服务指向虚拟IP地址（在glance-api文件中更改rabbit_host指向虚拟IP）。OpenStack配置服务不再需要其他更改。所以，如果任何作为RabbitMQ的主机节点，因为一些网络问题遇到任何服务故障切换问题，服务可以没有任何中断继续运行。总结本章中，我们学到了OpenStack中的一些服务仍然不是完全无状态的，因此它们需要典型的集群方法，比如Pacemaker。我们深入分析了一个服务集群的构建，它们的资源代理以及依赖。
我们同样学会了高可用MySQL和借助于AMQP的RabbitMQ高可用的负载均衡的一步步设置和配置。
在下一章，我们将会对OpenStack服务在无状态模式下如何互相协同工作来提供一个可伸缩性的云架构有个更加深入的理解。