Linux HA 集群原理和配置-03

本文介绍在Linux HA集群中的stonith模块功能。

Stonith，全称Shoot The Other Node In The Head，用于防止集群出现脑裂现象。简单来说，一旦集群中的节点相互之间失去了通信，无法知道其他节点的状态，此时集群中的每个节点将尝试fence（隔离或“射杀”）失去通信的节点，确保这些节点不再抢夺资源，然后才继续启动服务资源，对外提供服务。

在3台集群主机上安装fence-agents软件包。

安装完毕后可查看到系统支持的stonith设备类型：

以上输出中的每个Fence agent都是一种Stonith设备，从名字的后缀可以看出，这些Agent有以下几类：

前两种都属于电源类型的Stonith设备，而第三种和电源无关，之所以要这样划分，是因为：

以下以fence_scsi为例进行实验。

安装 《在CentOS7上配置iSCSI》 中的方法，通过一台专用的存储节点ha-disks为集群中的3个主机提供共享存储（即在ha-disks上创建iscsi硬盘，然后将其映射到3个集群主机上）。

在iscsi-disks上创建3个100M的硬盘fen1，fen2，fen3，挂载到主机上后设备名称分别为sdb,sdc,sdd

测试一下这些硬盘是否支持PR Key：

首先使用一个fence盘/dev/sdb来进行实验：

使用sg_persist -s参数获取/dev/sdb上的所有信息：

可以看到，3个节点使用不同的PR Key在这个磁盘上进行了注册(register)，并且ha-host1保留(reservation)成功，类型为“Write Exclusive, registrants only”。表明此时只有ha-host1对该磁盘进行写 *** 作。

此时如果断开其中两个节点的的链接，如ha-host1和ha-host3：

可以看到，经过协商后，ha-host3退出集群，并且也删除在fencing磁盘中的注册信息。由于stonith资源运行在ha-host2上，所以在ha-host2的日志中可以看到ha-host3被fence的过程：

ha-host3被fence之后，必须重启才能重新注册PR Key，否则即使网络恢复，其也无法运行需要stonith支持的资源。

问题：仲裁机制保证了必须有超过半数的节点的partition才能启动资源，拿为什么还需要stonith设备？

存储NAS 文件 *** 作

df -h查看空间使用情况

警惕超大 nohup.out

任务提交

任务提交前

qhost--查看集群负载状态

qsub / qsub-sge.pl--提交任务

qstat--查看任务状态

qdel / qmod--任务控制

任务查看

qhost -j---列出所有用户在每个节点上的任务

qhost -q---列出每个节点上每个队列的任务数

qhost -u username---列出某个用户在每个节点上的任务

提交命令

qsub -cwd -q queue.q test.sh

qsub-sge.pl --maxproc 50 --resource vf=5G --queue queue.q test.sh

任务查看2

qstat -u username---查看某个用户的任务

qstat -u *,---查看所有用户的任务

qstat –j jobs_ID---查看某个任务的详细信息

查看.e和.o文件

.e：错误信息

.o：标准输出

任务控制

qdel jobID---删除某个任务

qdel -u username---删除某个用户的所有任务

qmod -s jobID--挂起某个任务

qmod -us jobID---继续运行某个挂起的任务

按任务占用内存大小选择相应的队列

查看队列 qstat -g c

QUEUE

PE.q--并行

cloud.q--云平台

general.q--96G节点

middle.q--96G节点

great.q--大内存节点

plus.q--大内存节点

single.q--Trinity组装

single._p.q---Trinity组装（占用内存较大）

TOP监视

编辑于 2017-04-21

---