pacemaker+drbd+mysql

pacemaker是一个管理软件，可以管理很多服务，最大的优点是可以有效的避免脑裂问题。既然是集群管理软件，就要知道集群内节点的存活状态，他结合corosync通过心跳来进行判断。
pacemaker的配置文件是xml格式的，所以直接配置起来不是很友好，需要借助crmsh进行管理配置。

接下来以drbd+mysql实现mysql高可用为例
pacemaker+corosync+drbd+mysql

一、环境
系统 Ubuntu 16.04.3 LTS

服务器
192.168.1.10 node1
192.168.1.11 node2

vip
192.168.1.12

说明
‘#’开头的为系统提示符
‘###’开头的为注释说明
‘crm(live)’开头的为crm提示符

二、安装
1.pacemaker+corosync
# apt-get install pacemaker corosync
由于包的依赖会自动安装crmsh，如果为安装，需要手动安装

2.drbd 略
可以理解为通过网络实现的raid1
ubuntu系统通过apt安装，需要执行
# echo "deb trusty main" >> /etc/apt/sources.list

3.mysql 略
注意要将mysql的数据目录配置到drbd资源上
以上安装需要node1和node2全部执行

三、配置
1.环境
保证各节点间的时间同步，参考ntp服务
编辑/etc/hosts文件，保证主机名与ip的关系正确

2.corosync
# vi /etc/default/corosync
START=yes

# vi /etc/corosync/corosync.conf 

bindnetaddr: 192.168.1.0 

### 将地址修改成用于组建集群ip的网络地址，这样只要这个网段内安装了corosync服务的机器，且 cluster_name 相同的会自动成为一个集群
### 如果你的ip是公网或是考虑到安全的问题，请设置 crypto_cipher crypto_hash 项（必须同时设置），然后运行 corosync-keygen 命令，以便生成秘钥 /etc/corosync/authkey（权限为 400）
### 将集群内所有机器的文件 corosync.conf authkey 保持相同
### 据说将以下内容添加至配置文件后，pacemaker的服务会随着corosync自动启动，实验没能实现
service{
    ver:    0
    name:   pacemaker
}

2.pacemaker
自身不需要做任何配置，启动 pacemaker+corosync 服务后，可通过如下命令验证集群节点的状态

# crm status
### 节点处于online状态为正常，offline 请排查防火墙或selinux等

i.配置集群的虚拟ip 192.168.1.12
pacemaker把所有需要管理的服务都称为资源，通过crmsh或pcs进行管理
首先，先将stonith关闭，这是专门给stonith设备使用的，如果没有该类设备，pacemaker会报错误

# crm configure property stonith-enabled="false"

# crm configure primitive vip ocf:heartbeat:IPaddr2 params ip="192.168.1.12" cidr_netmask=24 op monitor interval=20s timeout=10s on-fail=restart

### 命令分解
### crm 调用crmsh
### configure 进入配置模式
### primitive 创建一个资源，后面是参数及选项
### 创建一个名称为“vip”的资源，该资源使用“ocf:heartbeat:IPaddr2”作为资源代理，该资源是一个ip地址“192.168.1.12/24”，每隔20秒对该资源进行一次检查，超过10秒则认为该资源timeout，如果资源失效，则进行重启该资源
### 每创建一个资源，必须定义一个资源名称，每个资源必须使用一个资源代理，资源代理对相应的资源进行管理，如：停止、启动等

### crmsh是个外壳，可以通过crm命令进入到交互界面，使用help命令进行帮助查看

# crm configure verify
### 检查配置是否正确


# crm configure commit
### 保存配置

### PS：资源代理
### 如何查看系统内有哪些可用的资源代理？
# crm ra classes


### 会列出可用的资源代理类型，可以使用如下命令进一步查看具体的资源代理，例如查看 lsb类型
# crm ra list lsb

### 或是 ofc类型
# crm ra list ocf heartbeat 

### 仔细阅读每个资源代理的说明及可用参数，如：上面建立vip时，除了cidr_netmask外，还有那些可用参数
# crm ra info  ocf:heartbeat:IPaddr2

ii.配置集群的mysql
crm(live)configure# primitive my_mysql ocf:heartbeat:mysql params binary="/usr/bin/mysqld_safe" config="/etc/mysql/my.cnf" datadir="/srv/data" socket="/tmp/mysql.sock"

### 这次创建的mysql资源，是进入了crm系统后操作的，所以提示符变成了crm的提示符，并且是在配置模式下。
### 资源代理依然用了heartbeat，也可以使用lsb，注意不同的资源代理，可能有不同的参数。

iii.配置集群的drbd
crm(live)configure# primitive drbd ocf:linbit:drbd \
        params drbd_resource=test \
        op monitor role=Master interval=30s timeout=20s \
        op monitor role=Slave interval=60s timeout=20s \
        op start timeout=240s interval=10 \
        op stop timeout=100s interval=10

### drbd_resource=test ，test是在drbd服务内定义的一个资源实例

vi.配置集群的drbd文件系统
primitive fs_drbd Filesystem \
        params device="/dev/drbd1" directory="/mnt" fstype=ext4 statusfile_prefix="/monitor" \
        op monitor on-fail=standby timeout=20s interval=60s OCF_CHECK_LEVEL=20 \
        meta migration-threshold=1 failure-timeout=3600s is-managed=true

### 检测一下是否配置正确
crm(live)configure# verify

### 没有错误，可以保存配置
crm(live)configure# commit

### 查看一下各个资源的运行状态
crm(live)configure# cd
crm(live)# status

### 发现各个资源分布于不同的2台设备上，这个不符合预期（所有的资源应该同时出现在同一台机器上），因为：mysql的数据目录设置在drbd的挂载分区上，
而该分区只能同时在一台drbd机器上挂载（即：角色为主的drbd），vip则是mysql对外提供的接口，应该同mysql在一起出现。

### 一个关键问题是如何判断当前drbd的角色？只需要将资源设置成主从模式即可
crm(live)configure# ms ms_drbd drbd meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=True 

### ms 设置资源为主从模式的命令关键字
### ms_drbd 是自定义的主从资源的名字
### 后面的一次是将drbd资源设置为主从模式，最多有多少份克隆资源可以被定义成主资源（ master-max=1）；每个节点上最多有多少份克隆资源可以被提升为主资源（master-node-max=1）
### 在集群中最多能运行2份资源（clone-max=2），因为当前有2个drbd的节点，默认是当前节点的数量；每个节点上最多能运行1份克隆资源（clone-node-max=1）。

### 让所有的资源运行在集群内同一个节点上
crm(live)configure# colocation all inf: fs_drbd ( my_mysql ms_drbd:Master )
crm(live)configure# commit

### colocation 是命令关键字
### all 是定义规则的名字
### inf表示无穷大，也可以用数字表示。默认值为0：由集群选择资源如何运行；正数：资源集中在一起运行；负数：资源不集中在一起运行。-inf表示负无穷
### 后面的是需要在同一节点的资源名称，如本例 fs_drbd   my_mysql ms_drbd ，如果资源超过2个，从第二个起至最后一个资源名称需要用‘（）’括起来
### 当drbd资源被设置成主从资源ms_drbd后，再使用资源时，所用的名称应该使用ms_drbd
### ms_drbd:Master 表示drbd的为master，即：fs_drbd mysql 资源与drbd的主资源一同运行

### 第二个关键问题是服务的启动顺序：只用drbd为master后，才能进行对分区的挂载，之后才能启动mysql，如果顺序错误，则服务启动失败
crm(live)configure# order order_all inf: ms_drbd:promote ( fs_drbd:start my_mysql )
crm(live)configure# commit

### order为名利关键字
### order_all为一个自定义名称
### inf同colocation的解释
### ms_drbd:promote ( fs_drbd:start web )，依次将drbd的角色提升为主，启动fs_drbd资源（挂载drbd分区）成功后，再启用my_mysql资源（mysql）
### 资源定义的格式是：资源名称:[action],action 有 promote（提升角色）、demote（降级角色）、start、stop

### 查看资源是否全部在一个节点运行
crm(live)# status

### 可以登录到主节点检查服务是否可用

### PS：location可以定义资源在某个节点上运行的倾向性
crm(live)configure# location location_1 my_mysql 100:node1
crm(live)configure# location location_1 my_mysql 200:node2

### 如果node2节点没有问题，my_mysql资源将更倾向于运行在node2上

crm(live)configure# location location_2 my_mysql -inf:node1

### my_mysql资源将永远不会运行在node2上

三、测试

### 将主节点进行断网、关机或是standby资源没有转移到从节点。因为集群内的节点只有2个，pacemaker在选举新的master时，会根据一半以上的票数来决定，
因此主节点宕机后，从节点只有1票，因此不具有法定票数从而无法被选举为主，资源也就无法进行转移。可以设置忽略投票

# crm configure property no-quorum-policy=ignore

### 再次关闭主节点，资源已经转移到从节点

### 如果将主节点上的mysql服务关闭，会发现资源并没有进行转移

crm(live)resource# meta my_mysql show migration-threshold

### 默认的结果是无穷大，migration-threshold决定了资源在失败多少次后进行转移

crm(live)resource# meta my_mysql set migration-threshold 1

### 再关闭mysql时，资源已经转移到了从节点上，这个参数对于其他资源一样适用，也可在创建资源时就设置，如上面在创建drbd文件系统时

四、恢复

1.节点恢复后如何处理，是抢占回master还是不抢占？
crm(live)configure# rsc_defaults resource-stickiness=

### rsc_defaults用来设置资源的默认属性
### resource-stickiness称为资源的黏性，黏性值决定节点在恢复后如何处理
### 可以是：infinity或正数（不抢占）、-infinity或负数（抢占）、0：由集群决定

2.节点及服务恢复后为何在集群内的状态依旧为standby或stop？
crm(live)resource# meta my_mysql show failure-timeout

### 该结果决定了资源在恢复后，多长时间内资源不能使用该节点，可以适当的调整
crm(live)resource# meta my_mysql set failure-timeout 3600s

### 或是手动调整，例node1恢复后，将失败计数清零
crm(live)resource# failcount my_mysql set node1 0

### 也可以
crm(live)resource# cleanup my_mysql

五、其他

关于投票
如上设置忽略了投票，虽然可以实现资源转移，但是容易出现脑裂现象。对此可以进一步改进

1.添加节点node3
只使用node3进行投票选举，而不允许运行资源。在node3上安装corosync+pacemaker后

crm(live)configure# location location_3 所有的资源名称 -inf:node3

2.使用ping资源
# crm configure primitive pnode ocf:pacemaker:ping params host_list=192.168.1.1 multiplier=100 op monitor interval=10s timeout=60s op start timeout=60s
# crm configure clone cl_pnode pnode
# crm configure location score_on_ping my_mysql rule -inf: not_defined pingd or pingd number:lte 0

### 192.168.1.1是网关地址或可以ping通的其他节点，可以有多个，使用空格分隔。
### 而multiplier表示如果集群中的节点可以ping通，那么那个节点的分数就会乘以这个参数指定的值，来进行累加，比如node1，ping通一次就是1*100，ping通两次2*100，依次类推。

### 对ping资源进行克隆，以便让每个节点都运行该资源

### 如果由ping node得出的分数小于等于0 或者某个节点没有定义域ping node 相关的属性的话，那么就对my_mysql资源进行转移，因为上面已经将mysql及drbd等资源进行了约束性限制，
### 因此一旦mysql进行了转移，其他资源也会转移，并且遵循order中设置的顺序。

### 集群的操作，只需要在一个节点上操作即可！

3.drbd的优化
# cat /etc/drbd.d/global_common.conf 
 disk {
                on-io-error detach;
                disk-flushes no;
        }
        net {
                max-buffers 8000; #增大缓存区为8000
                max-epoch-size 8000;
                sndbuf-size 0; #是sendbuffer自动调整
        }
        syncer {
        rate 1000M; #现在基本都是千兆网络
        al-extents 256; #增大活动日志区为256个
        }