Linux HA 集群原理和配置-02

本文介绍在Linux HA集群中的仲裁和分区概念。

集群正常工作时，所有节点都在一个分区内（partition），分区内的所有节点将选举出一个仲裁节点，这个仲裁节点负责向其他节点发送集群控制命令。当网络发生故障时，集群中的节点发现无法和仲裁节点通信，则会在可通信的范围内重新选举一个新的仲裁节点。此时集群内可能出现多个仲裁节点，每个仲裁节点的管理范围为一个分区。

下文中将通过防火墙策略的设置模拟集群网络中通信出现异常的各种情况，如：

通过防火墙策略可以精准控制两两节点之间的连通性，使我们能更准确的了解在网络连通性发生变化对集群的影响。

在所有节点上启动防火墙，并添加策略对整个管理网络192.168.56.0/24放通。

保存上述策略，之后在实验过程会使用iptables命名加入新策略模拟网络通信异常效果，如果需要恢复网络通信正常状态，直接不保存策略重启firewalld服务即可。

通过pcs status查看集群状态：

上述结果显示当前集群只有一个分区，分区内的节点包括全部3台主机，仲裁节点是ha-host3，这表示集群间的通信是完好的。下图显示当前集群状态：

在ha-host1上添加以下策略：

该策略将使得ha-host1和ha-host3之间的通信中断，在所有节点上查看集群状态：

上面的结果显示，ha-host1失去和当前仲裁节点ha-host3的联系之后，和ha-host2一起组成新的分区并选举出ha-host2作为新的仲裁节点。有趣的是ha-host2和ha-host3的通信并未中断，但是他被“优先级较高的ha-host1抢走并推举为老大”，剩下ha-host3独自留在其自身所在的分区。此时ha-host3所在的分区提示了“partition WITHOUT quorum”，表示该分区中的节点数目不超过一半。

下图显示当前集群状态：

在ha-host1上再添加策略：

使其和当前的仲裁节点ha-host2的通信中断，集群状态变为：

发现ha-host2和ha-host3一起组成了新的分区，由于ha-host1所在分区节点数不足一半，无法启动资源，虚拟ip资源vip被切换到了ha-host2上。下图显示当前集群状态：

如果再把ha-host2和ha-host3直接的通信中断，此时3个节点间两两均无法通信。每个节点都是一个分区，每个分区的主机数均不过半，因此无法启动任何资源，原先运行在ha-host2上的vip也停止了。

当前集群状态如下图：

Oracle集群

Oracle集群，最早称作OPS(Oracle Parallel Server)出现在Oracle 7版本中，从Oracle 9i开始正式改称为Oracle RAC，RAC即Real Application Clusters的简写，译为“真正应用集群”；RAC 是Oracle新版数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。 10g以前的OPS或者RAC都依赖于第三方集群软件(Vendor Clusterware)方能正常工作，在10g版本中Oracle推出了Oracle Clusterware集群软件以及ASM自动存储管理技术，换而言之10g以后版本的RAC不再依赖于第三方的集群软件(譬如IBM的HACMP,Veritas的VCS等)，但必须安装Oracle自己的Clusterware集群软件。 Oracle RAC主要支持Oracle9i、10g、11g版本，可以可以支持24 x 7 有效的数据库应用 系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。 在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。 参考编辑本段Oracle集群参考文档

Oracle RAC一般也可构建于大型SMP主机，IBM的AIX系列服务器往往是其中高端平台，Intel Linux往往作为其低端平台。当AIX UNIX用来运行Oracle RAC作为大型数据库系统平台时，其集群系统构建、实施、运维、高可用设置，有其平台特点。可以参照《Oracle大型数据库系统在AIX/UNIX上的实战详解》，该书以AIX UNIX平台为主线，以其他UNIX系统为参照，描述了数据库系统Oracle 10g、Oracle 11g的RAC的构架方法和过程。在Linux平台，则《大话OracleRAC集群、高可用性、备份与恢复》有着很好的论述。

本文介绍在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设备？

---