OpenStack高可用性指南（2）——主从方案实现高可用（未完结）

英文文档http://docs.openstack.org/high-availability-guide/content/ha-using-active-passive.html

Pacemaker集群栈

OpenStack基础设施的高可用性依赖于Pacemaker集群堆栈,Pacemaker是 Linux平台上 先进的 高可用性和负载平衡 堆栈，Packmaker和存储与应用无关。

Pacemaker依赖于可靠的集群通信Corosync消息层。Corosync实现Totem协议（The Totem Single-Ring Ordering and MembershipProtocol，了解http://blog.csdn.net/zuokong/article/details/7548152）。并为Pacemaker提供了UDP和基于InfiniBand的消息，仲裁，群集成员。

Pacemaker和应用程序通过资源代理（RAs）来交互 ，它支持超过70个本地RAs，还可以方便地使用第三方的RAs。一个OpenStack的高可用性配置使用原生Pacemaker的RAS （如管理MySQL数据库或虚拟IP地址），现有的第三方RAs（如RabbitMQ的） ，和原生OpenStack的RAs（如管理OpenStack的身份和镜像服务）。

安装软件包

为了把任何主机都作为Pacemaker集群的一部分，您必须先通过消息传递层建立Corosync集群通信。这包括安装以下软件包（和它们的依赖，包管理器通常会自动安装）：

• pacemaker
• corosync
• cluster-glue
• fence-agents (Fedora only; all other distributions use fencing agents from cluster-glue)
• resource-agents

配置Corosync

除了安装corosync包的，你还必须创建一个配置文件，存放在/ etc / corosync / corosync.conf。多数示例配置文件（ corosync.conf.example ） ，作为和corosync包捆绑在一起的文档的一部分。一个Corosync配置文件例子如下图所示：

Corosync configuration file (corosync.conf). 

totem {
        version: 2

        # Time (in ms) to wait for a token  
        token: 10000

        # How many token retransmits before forming a new
        # configuration
        token_retransmits_before_loss_const: 10

        # Turn off the virtual synchrony filter
        vsftype: none

        # Enable encryption  
        secauth: on

        # How many threads to use for encryption/decryption
        threads: 0

        # This specifies the redundant ring protocol, which may be
        # none, active, or passive.  
        rrp_mode: active

        # The following is a two-ring multicast configuration.  
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.42.0
                mcastaddr: 239.255.42.1
                mcastport: 5405
        }
        interface {
                ringnumber: 1
                bindnetaddr: 10.0.42.0
                mcastaddr: 239.255.42.2
                mcastport: 5405
        }
}

amf {
        mode: disabled
}

service {
        # Load the Pacemaker Cluster Resource Manager  
        ver:       1
        name:      pacemaker
}

aisexec {
        user:   root
        group:  root
}

logging {
        fileline: off
        to_stderr: yes
        to_logfile: no
        to_syslog: yes
        syslog_facility: daemon
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
                tags: enter|leave|trace1|trace2|trace3|trace4|trace6
        }
}

1、令牌值指定时间，以毫秒为单位，在这期间Corosync令牌预计将围绕环传输。当时间到期，令牌被宣布丢失。在失去了令牌之后（token_retransmits_before_loss_const），不响应的处理器（群集节点）被宣告死亡。换言之，token_retransmits_before_loss_const代表允许一个节点不响应群集消息被视为“死”之前的最大时间。令牌的默认值是1000（1秒） ，允许有4个重传。这些默认值是为了最大限度地减少故障切换时间，但在短暂的网络中断的情况下，可能会导致频繁的“误报”和意想不到的故障转移。这里使用的值是安全的，尽管故障转移时间略有延长。

2、启用secauth，Corosync节点使用一个128字节的共享存储在/ etc / corosync / authkey来相互验证，这个key由corosync-keygen生成。当使用secauth ，集群通信也被加密。

3、在Corosync配置中，使用冗余的网络（具有多个接口），你必须选择一个冗余环网协议（RRP）模式。

4、对推荐的接口配置有几件事情要注意：

• ringnumber必须和所有配置的接口不同，并且从0开始。
• bindnetaddr是接口绑定到的网络地址。该示例使用两个/ 24 IPv4子网的网络地址。
• 多播组（使用mcastaddr ）必须不能重复使用跨集群边界，换句话说，没有任何两个不同的集群应该永远使用相同的多播组。请务必选择多播地址兼容RFC 2365。
• 对于防火墙配置，注意Corosync只在UDP上通信，并使用mcastport进行（接收） mcastport-1进行的（发送） 。

5、声明Pacemaker服务的服务可以直接放置在的corosync.conf文件，或在其单独的文件，在/ etc / corosync / service.d /pacemaker。

一旦创建，必须在所有群集节点上同步corosync.conf文件（ 以及authkey文件如果启用secauth选项）。

启动Corosync

开启Corosync作为一项常规系统服务，根据你的分配，它可能以以下几种方式工作，但无论哪种方式，服务通常被命名为corosync ：

• /etc/init.d/corosync start (LSB)
• service corosync start (LSB, alternate)
• start corosync (upstart)
• systemctl start corosync (systemd)

现在你可以用两个工具检查corosync连通性。

corosync-cfgtool程序 ，当调用-s选项时，可以给出通信环的健康状况。

# corosync-cfgtool -s
Printing ring status.
Local node ID 435324542
RING ID 0
        id      = 192.168.42.82
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.0.42.100
        status  = ring 1 active with no faults

corosync-objctl程序 可以用于转储Corosync集群成员名单：

# corosync-objctl runtime.totem.pg.mrp.srp.members
runtime.totem.pg.mrp.srp.435324542.ip=r(0) ip(192.168.42.82) r(1) ip(10.0.42.100)
runtime.totem.pg.mrp.srp.435324542.join_count=1
runtime.totem.pg.mrp.srp.435324542.status=joined
runtime.totem.pg.mrp.srp.983895584.ip=r(0) ip(192.168.42.87) r(1) ip(10.0.42.254)
runtime.totem.pg.mrp.srp.983895584.join_count=1
runtime.totem.pg.mrp.srp.983895584.status=joined

你应当查看每个集群节点的条目 status=joined

启动Packmaker

Corosync服务一旦被启动，并且已经建立了正常的集群通信，启动pacemakerd是安全的，Packmaker主控制进程：

• /etc/init.d/pacemaker start (LSB)
• service pacemaker start (LSB, alternate)
• start pacemaker (upstart)
• systemctl start pacemaker (systemd)

一旦Packmaker服务已经开始，Packmaker将创建一个默认的 没有资源配置的空集群。您可以用 crm_mon的程序查看到Pacemaker的状态：

============
Last updated: Sun Oct  7 21:07:52 2012
Last change: Sun Oct  7 20:46:00 2012 via cibadmin on node2
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ node2 node1 ]

设置群集的基本属性

Pacemaker集群建立后，建议设置一些基本的集群属性。要做到这一点，启动crm shell通过输入配置进入配置菜单。另外，你可以通过shell提示键入crm配置直接跳入Pacemaker配置菜单

然后设置这些属性

property no-quorum-policy="ignore" \ #  
  pe-warn-series-max="1000" \        #  
  pe-input-series-max="1000" \
  pe-error-series-max="1000" \
  cluster-recheck-interval="5min"    #  

1. 当有两节点的Pacemaker集群，需要设置 no-quorum-policy="ignore" 有以下几点原因：假如法定人数仲裁被启动了，并且其中的两个节点失败了，那么剩下的节点不能建立所需的法定票数的多数运行服务，因此它无法接管任何资源。适当的解决方法是忽略集群中的仲裁丢失。只有在2个节点的集群，这是安全和必要的。不要将此属性设置在有两个以上的节点Pacemaker集群。
2. 设置pe-warn-series-max, pe-input-series-max and pe-error-series-max 到1000，让Pacemaker保持一个较长的输入处理和错误警告的历史，可以在集群故障排除的时候变的非常有用。
3. Pacemaker使用事件驱动的集群状态处理方法，然而，某些Pacemaker行为发生在一个可配置的时间间隔内，集群复检间隔，默认为15分钟。它通常谨慎地降低到一个较短的时间间隔，如5或3分钟。

一旦你做出这些变化，你可能提交更新后 的配置

云控制器集群栈

云控制器建立在管理网络上，需要和其他所有服务交互。

Mysql高可用

MySQL是给OpenStack的服务使用的默认的数据库服务器。 MySQL服务高可用涉及：

• 为Mysql配置DRBD设备。
• 为Mysql在DRBD设备上配置一块数据目录。
• 选择和分配一个虚拟IP地址（ VIP ） ，可以在群集节点之间自由浮动。
• 配置MySQL监听该IP地址。
• 用Pacemaker集群管理器管理所有资源，包括MySQL守护进程本身。

注意

MySQL/Galera是高可用性配置MySQL一种替代方法，这很可能成为首选的方法实现MySQL高可用性，一旦它足够成熟。然而，现在，Pacemaker/ DRBD技术为基础的方法仍然是推荐的方法。

配置 DRBD

基于MySQL服务器的Pacemaker需要DRBD资源从它挂载的var/lib/mysql 目录下，在这个例子中， DRBD资源简单的命名为mysql ：

mysql DRBD resource configuration (/etc/drbd.d/mysql.res). 

resource mysql {
  device    minor 0;
  disk      "/dev/data/mysql";
  meta-disk internal;
  on node1 {
    address ipv4 10.0.42.100:7700;
  }
  on node2 {
    address ipv4 10.0.42.254:7700;
  }
}

此资源使用名字为/dev/data/mysql 本地硬盘（DRBD术语，  a  backing device）在两个集群的节点上，节点1和节点2。通常情况下，这将是为此目的划分出来的LVM逻辑卷。DRBD元磁盘是内部的，这意味着DRBD元数据被存储在磁盘设备本身的末尾。该设备被配置与IPV4为10.0.42.100 到 10.0.42.254的地址进行通信，使用TCP端口7700。一旦启用，它会映射到一个本地的设备编号为0的 DRBD块设备，也就是/ dev/drbd0 。

如何启用DRBD资源在DRBD用户指南中有详细的解释。简单的说，正确的命令顺序是这样的：

drbdadm create-md mysql  
drbdadm up mysql  
drbdadm -- --force primary mysql  

 DRBD元数据的初始化和将元数据的初始设置写入 /dev/data/mysql，必须两个节点上都完成

创建/ dev/drbd0设备节点，将DRBD设备与本地存储设备相连，必须在两个节点上都完成

使初始设备同步，让设备成为主要的角色（可写和可读）。查看DRBD资源的主要角色和次要角色更详细的说明请参考DRBD用户指南。只能完成一个节点，就是你将继续创建文件系统的那个节点

创建文件系统

一旦DRBD资源运行并且是主要角色，你可以继续为Mysql数据创建文件系统。XFS是普遍推荐的文件系统：

mkfs -t xfs /dev/drbd1

您也可以使用DRBD设备的备用设备路径，这可能更容易记住，因为它包含了不言自明的资源名称：

mkfs -t xfs /dev/drbd/by-res/mysql

一旦完成，你可以安全地让该设备返回次要角色。任何正在进行同步的 设备将在后台继续：

drbdadm secondary mysql

为pacemaker高可用准备Mysql

为了让Pacemaker正常监测，你必须确保MySQL的数据库文件驻留在DRBD设备。如果你已经有一个MySQL数据库，最简单的办法就是将/var/lib/mysql 目录下的内容移动到新创建的在DRDB设备中的文件系统上。

	警告
	在你完成下一步是必须关闭Mysql数据库服务器

node1:# mount /dev/drbd/by-res/mysql /mnt
node1:# mv /var/lib/mysql/* /mnt
node1:# umount /mnt

对于一个新的没有现成数据的Mysql，你也可以运行mysql_install_db的命令：

node1:# mount /dev/drbd/by-res/mysql /mnt
node1:# mysql_install_db --datadir=/mnt
node1:# umount /mnt

不管使用哪种方法，这里列出的步骤必须只能在一个群节点上完成。

将Mysql的资源加入Pacemaker

现在你可以为Mysql资源添加Pacemaker配置。用crm配置连接Pacemaker集群，并添加以下集群资源：

primitive p_ip_mysql ocf:heartbeat:IPaddr2 \
  params ip="192.168.42.101" 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=50.56.179.138"
    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

这个配置创建了：

• p_ip_mysql, Mysql使用的虚拟ip地址(192.168.42.101),
• p_fs_mysql, 无论那个节点正在运行Mysql服务，Packmaker将文件系统挂载到/var/lib/mysql 。
• ms_drbd_mysql,master/slave set 管理mysql DRBD资源。
• 一个服务的组别、顺序、场地约束可以确保资源在正确的节点，以正确的顺序开始。

CRM配置支持批量输入，所以你可以复制和粘贴以上到您的Pacemaker配置，然后根据需要进行更改。例如，您可能 进入CRM配置菜单编辑p_ip_mysql的和编辑资源，以配合您的首选的虚拟IP地址。

一旦完成后，提交您的配置更改。然后Pacemaker将启动MySQL服务，及其相关的资源，在你的一个节点上。

为高可用Mysql配置Openstack服务

现在，你的的OpenStack的服务必须指向MySQL配置高可用，虚拟群集IP地址 - 而不是像往常一样的MySQL服务器的物理IP地址。

对于Openstack镜像，例如，如果你的Mysql服务的ip地址是192.168.42.101。你将会用到以下几行在OpenStack镜像注册配置文件中(glance-registry.conf):

sql_connection = mysql://glancedbadmin:<password>@192.168.42.101/glance

没有其他的变化在你的Openstack配置中。如果当前 承载你的数据库的节点遇到问题，需要进行故障服务转移。您的Openstack可能会遇到一个简短的Mysql中断。因为他们会在一个网络事件短暂的停顿，然后继续正常运行。

RabbitMQ高可用

RabbitMQ是许多OpenStack服务默认使用AMQP服务器。 RabbitMQ的高可用涉及：

• 为RabbitMQ配置DRBD设备
• 使用一个数据目录来配置RabbitMQ使其驻在DRBD设备上
• 选择和分配一个可以在集群节点之间自由浮动的虚拟IP地址（ VIP ）
  
• 配置RabbitMQ侦听该IP地址
• 管理所有资源，包括RabbitMQ的守护进程本身

	Note
	RabbitMQ的高可用性配置的一种替代方法。这种方法被称为active-active mirrored queues, 恰好是一个RabbitMQ的开发人员的首选 — 但是它在Openstack集群中的一致性和可靠性都不理想。因此，在写作的时候，Pacemaker/DRBD为基础的技术仍然为Openstack环境推荐技术，虽然不久的将来这种情况会改变，因为RabbitMQactive-active mirrored queues会变得成熟

配置DRBD

基于RabbitMQ服务器的Pacemaker需要一个DRBD资源挂载在/ var / lib / RabbitMQ的目录中。DRBD资源简单地命名为RabbitMQ

rabbitmq DRBD 资源配置 (/etc/drbd.d/rabbitmq.res). 

resource rabbitmq {
  device    minor 1;
  disk      "/dev/data/rabbitmq";
  meta-disk internal;
  on node1 {
    address ipv4 10.0.42.100:7701;
  }
  on node2 {
    address ipv4 10.0.42.254:7701;
  }
}

此资源使用一个名为/dev/data/rabbitmq 本地磁盘（ DRBD技术术语，a backing device）在两个集群节点上，节点1和节点2。通常情况下，这将是为此目的划分出来的LVM逻辑卷。DRBD元磁盘是内部的，这意味着DRBD元数据被存储在磁盘设备本身的末尾。该设备被配置与IPV4为10.0.42.100和10.0.42.254的地址进行通信，使用TCP端口7701。一旦启用，它会映射到一个本地的设备编号为1的DRBD块设备，也就是/ dev/drbd1 。

如何启用DRBD资源在DRBD用户指南中有详细的解释。简单的说，正确的命令顺序是这样的

drbdadm create-md mysql  
drbdadm up mysql  
drbdadm -- --force primary mysql  

 DRBD元数据的初始化和将元数据的初始设置写入  /dev/data/rabbitmq，必须两个节点上都完成

创建/ dev/drbd1设备节点，将DRBD设备与本地存储设备相连，必须在两个节点上都完成

使初始设备同步，让设备成为主要的角色（可写和可读）。查看DRBD资源的主要角色和次要角色更详细的说明请参考DRBD用户指南。只能完成一个节点，就是你将继续创建文件系统的那个节点

创建一个文件系统

DRBD资源一旦运行并担任主要角色，您可以继续创建文件系统RabbitMQ的数据。 XFS是普遍推荐的文件系统：

mkfs -t xfs /dev/drbd1

您也可以使用DRBD设备的备用设备路径，这可能是更容易记住，因为它包含了不言自明的资源名称：

mkfs -t xfs /dev/drbd/by-res/rabbitmq

一旦完成，你可以安全地让该设备返回次要角色。任何正在进行同步的设备将在后台继续：

drbdadm secondary rabbitmq

为pacemaker高可用准备RabbitMQ

为了让Pacemaker正常监测，你必须确保RabbitMQ’s .erlang.cookie 在所有节点上是相同的，无论DRBD是否安装。最简单的方法是采取一个节点上现有的  .erlang.cookie，将其复制到在RabbitMQ的数据目录的其他节点上，也复制到的DRBD技术支持的文件系统上。

node1:# scp -a /var/lib/rabbitmq/.erlang.cookie node2:/var/lib/rabbitmq/
node1:# mount /dev/drbd/by-res/rabbitmq /mnt
node1:# cp -a /var/lib/rabbitmq/.erlang.cookie /mnt
node1:# umount /mnt

将RabbitMQ的资源加入Pacemaker

现在你可以为RabbitMQ资源添加Pacemaker配置。用crm配置连接Pacemaker集群，并添加以下集群资源：

primitive p_ip_rabbitmp ocf:heartbeat:IPaddr2 \
  params ip="192.168.42.100" 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地址(192.168.42.100),
• p_fs_rabbitmq, 无论那个节点正在运行RabbitMQ服务，Packmaker将文件系统挂载到/var/lib/RabbitMQ 。
• ms_drbd_rabbitmq,master/slave set 管理RabbitMQ DRBD资源。
• 一个服务的组别、顺序、场地约束可以确保资源在正确的节点，以正确的顺序开始。

CRM配置支持批量输入，所以你可以复制和粘贴以上到您的Pacemaker配置，然后根据需要进行更改。例如，您可能 进入CRM配置菜单编辑p_ip_rabbitmq的和编辑资源，以配合您的首选的虚拟IP地址。

一旦完成后，提交您的配置更改。然后Pacemaker将启动RabbitMQ服务，及其相关的资源，在你的一个节点上。

为高可用RabbitMQ配置Openstack服务

现在你的的OpenStack的服务必须指向RabbitMQ的配置，高可用性，虚拟集群的IP地址 - 而不是像往常一样一个RabbitMQ服务器的物理IP地址。

对于Openstack镜像，例如，如果你的RabbitMQ服务的ip地址是192.168.42.100。你将会用到以下几行在OpenStack镜像注册配置文件中(glance-registry.conf):

rabbit_host = 192.168.42.100

没有其他的变化在你的Openstack配置中。如果当前承载你的RabbitMQ的节点遇到问题，需要进行故障服务转移。您的Openstack可能会遇到一个简短的RabbitMQ中断。因为他们会在一个网络事件短暂的停顿，然后继续正常运行。

未完待续。。。