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设备？
本文介绍在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也停止了。
当前集群状态如下图：
转自：集群故障转移的仲裁
Windows服务器故障转移集群（Windows Server Failover Cluster，简称WSFC）使用仲裁投票（Quorum Voting）决定集群的健康状况，或使故障自动转移，或使集群离线。 当集群中的结点发生故障时，会由其他结点接手继续提供服务 ，不过， 当结点之间通信出现问题，或大多数结点发生故障时，集群就会停止服务，可是集群可以容忍多少个结点发生故障呢？ 这要由仲裁配置（Quorum Configuration）决定，仲裁配置采用少数服从多数（Majority）原则，只要集群中健康运行的结点数量达到仲裁规定的数量（多数结点投赞成票），集群就会继续提供服务，否则集群就停止提供服务。在停止提供服务期间，正常结点持续监控故障结点是否恢复正常，一旦正常结点的数量恢复到仲裁规定的数量，集群就恢复正常，继续提供服务。仲裁投票默认是启用的（Cluster Manged Voting：Enable）。
一，仲裁模式
仲裁模式是在WSFC 集群级别配置的，规定仲裁投票的方法，默认情况下，故障转移集群管理器会基于集群结点的数量，自动推荐一个仲裁模式。仲裁配置影响集群的可用性，在集群中，重组的集群结点必须在线，否则集群将由于仲裁不足而必须停止服务。
1，术语解释
仲裁（Quorum）：法定数量，预先规定具有投票权的结点或见证（Witness）的数量；
仲裁投票（Quorum Voting）指法定数量的结点和见证进行投票，如果多数投赞成票，那么判断集群处于健康状态；
投票节点（Voting Node）：在集群中，拥有投票权的结点称作投票结点，如果投票结点投赞成票，代表该结点认为集群是健康的；但是，单个结点不能决定集群整体的健康状态。
投票见证（Voting Witness）：除了投票结点能够进行投票之外，共享的 File 和 Disk 也能投票，称作投票见证， 共享的File 投票见证，称作文件共享见证（File Share Witness）；共享的Disk 投票见证，称作硬盘见证（Disk Witness） ；
仲裁结点集合（Quorum Node Set）：拥有投票的结点和Witness统称仲裁结点集合；由仲裁结点集合的投票结果决定集群整体的健康状态。
2，仲裁模式
仲裁模式多数原则 是指所有投票结点进行投票，如果赞成票占比在50%以上，那么WSFC认为集群处于健康状态，执行故障转移，继续提供服务，否则，WSFC认为集群出现严重故障，WSFC使集群离线，停止提供服务。根据仲裁结点集合的组成类型，将仲裁模式分为以下四种类型：
结点多数 （Node Majority）：在集群中，投票结点都是集群的结点服务器，如果一半以上的投票结点（Voting Node）投赞成票，那么WSFC判定集群是健康的；
结点和文件共享多数 （Node and File Share Majority）：和Node Majority模式相似，除了将远程文件共享配置为一个投票见证（Voting Witness）之外，该共享文件称作仲裁文件，或见证文件。使用仲裁文件，远程文件拥有投票权，如果其他结点能够连接到该共享文件，那么认为该文件投一个赞成票。如果投票结点和文件共享投的赞成票占一半以上，那么WSFC判定集群是健康的。作为一个最佳实践，文件共享见证（File Share Witness）不要存储在集群中的任何一个结点服务器上，并且设置任何一个结点服务器都有权限访问。
结点和硬盘多数 （Node and Disk Majority）：和Node Majority模式相似，除了将共享硬盘配置为一个投票见证（Voting Witness）之外，该共享硬盘称作仲裁硬盘，或见证硬盘。仲裁硬盘需要共享存储，集群中各个结点都需要挂载同一个共享硬盘。
只硬盘（Disk Only） ：没有多数，仅仅把一个共享的硬盘作为唯一见证，集群中的任何一个结点能够访问该共享硬盘，这意味着，一旦仲裁硬盘脱机，集群就会停止提供服务。
常见的仲裁模式是结点多数（Node Majority） 和 结点和文件共享多数（Node and File Share Majority） ，如果集群结点数量是 奇数 ，那么使用结点多数仲裁模式；如果集群结点数量是 偶数 ，那么使用结点和文件共享多数仲裁模式，该模式需要配置一个共享文件夹，集群中的各个结点都有权限访问该共享文件夹，并且该共享文件夹不能创建是集群的结点上。
打开故障转移管理器（Failover Cluster Manager），右击集群结点，在上下文菜单中点击“More Actions”，在扩展菜单中选择“Configure Cluster Quorum Settings”，打开仲裁配置向导（Wizard），为该集群配置仲裁。
在任何时刻，从每一个的结点的角度来看，其他结点可能处于离线状态，或正在进行故障转移，或由于网络连接失败而处于不响应状态，仲裁投票的关键在于确定所有投票结点的真实状态。除了“Disk Only”仲裁模式之外，其他仲裁模式都依赖于投票结点之间周期性的心跳信号通信，一旦某个结点因为网络通信故障，系统宕机，硬件损坏，机房停电等异常而无法回应心跳信号，那么剩余的结点就认为该结点出现异常，把该结点从当前集群排除。WSFC统计所有投票结点的仲裁结果，决定集群的健康状态。
如果集群的结点位于不同的子网（Subnet）中，当一个结点在子网1中被认为是故障结点时，实际上，该结点可能是由于网络通信故障而不能被子网1的结点感知，但是该结点在子网2中是在线的，健康的 。如果投票结点在不同的子网中能够建立多个投票仲裁，那么将产生脑裂场景。在该场景中，位于不同仲裁的结点有不同的表现，使仲裁产生冲突，WSFC不能正确的执行故障转移，可能产生数据不同步。脑裂场景只可能在系统管理员手动执行强制仲裁(Forced Quorum) *** 作时发生。
WSFC在集群的结点之间进行健康检测和仲裁投票，每一个结点通过周期性地发送心跳信号，检测其他其他结点的健康状态，并和其他结点共享健康数据，无法响应心跳信号的结点被认为处于异常状态，集群的所有健康结点都会很快知道该结点出现故障。
仲裁结点集合是投票结点和见证结点（Witness）结合，仲裁结果由多数（Majority）结点决定，集群整体的健康状态是由周期性的仲裁投票的结果决定的，WSFC根据仲裁投票的结果，执行自动故障转移或者使集群离线：如果仲裁结点集合（Quorum Node Set)的投票结果表明大多数结点是健康的，那么集群将进行故障转移，继续提供服务；如果投票结果是少数结点，那么集群将处于离线状态。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）