《OpenStack HA》第四章 集群、隔离以及主备服务

整体来讲，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服务在无状态模式下如何互相协同工做来提供一个可伸缩性的云架构有个更加深刻的理解。