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也停止了。

当前集群状态如下图：

以下引自新浪 sunny的博客

原文链接：http://delxu.blog.51cto.com/975660/717516

delxu原创

HA的工作原理

想写一篇关于VMware HA的博客由来已久，曾经做了些功课，查了不少资料，写了点笔记，但是终于因为各种原因没有成文。随着vSphere 5的发布，HA机制作出了不少调整，很有必要写一些了。本文（或许我可能还会就ESX4的HA机制和 *** 作写上几篇，凑成一个系列）就是我的一点读书笔记整理而成。

【什么是HA】

HA的英文是High Availability，高可用性。从字面上的意思就是一种让服务中断尽可能少的技术。VMware的HA和微软的MSCS(Win2008以后改称Failover Clustering)类似，都是将多台主机组建成一个故障转移集群(Cluster)，运行在集群上的服务(或VM)不会因为单台主机的故障而停止。

用一个图来简单说明HA的工作原理：图中橙色的主机ESXi01宕机了，其上的2台虚拟机VM1和VM2就根据HA的调度被ESXi-02和ESXi-03这2台主机接管，并重启运行起来。

注：本文图片均截取自《VMware vSphere 5 Clustering Technical Deepdive》

但是要注意的是，HA(无论是VMware的HA还是MSCS)不是通常意义上的完全不中断服务的高可用性，HA只是一种自动的故障切换机制，当某一主机发生故障时，服务或VM（就配置了MSCS的Hyper-V来看，VM其实也被看作是一个服务）自动到另外的可用的主机上重启。这其实是一个中断然后重启的过程。就VM来说，看上去就好像是一台服务器突然被拔掉了电源线，然后又重新加电开机。这个故障然后重启的过程其实是比较长的，根据不同的VM而不同，少则1-2分钟，多的则可能达到5-6分钟。如果运行在一台缺乏资源的的主机上，这个时间可能更长。

【创建一个VMware HA】

创建一个VMware Cluster并启用HA的方法很简单。谷歌百度一下很容易找到一堆。这里不再赘述，过几天有空了我另外截些图单独写一篇Cluster创建图解的blog。

这里我想重点讲的是HA的原理。

【创建HA的前提】

一个通用的HA的集群通常有这么几个必要的条件组成：

* 2台或者更多台主机

* 这些主机共享一个外部存储

* VM是运行在共享存储上的

* 主机上至少有2个以上的网卡，其中一个需要负责传递“心跳”信号。

上面这些条件是大多数高可用性集群都需要的一致的。

此外，要成功配置VMware HA，还必须具备这么几个必要条件：

* 必须有vCenter Server（虽然没有vCenter HA也能发挥作用，但是创建Cluster的时候必须有vCenter的参与）

* 所有Host都必须有相同的vSwitch配置

特别要注意的是，对于ESX 4.x或之前版本，DNS是建立HA必要前提，所有Host都必须能够正确的解析其他node的DNS名字，将主机加入到一个集群也必须用其FQDN名。但是从vSphere 5开始，这已经不是必要的了，IP地址被直接用作HA集群的通信，这样减少了HA的依赖性，加快了HA的响应速度。

但是，因为VMware vSphere 5的其他一些服务和组件仍然需要DNS，使用FQDN虽然仍然是推荐做法。

【HA的组成部分】

vSphere 5的HA的组件有以下三个：

FDM

hostd

vCenter

FDM是Fault Domain Manager的缩写，它的前身在ESX4叫作AAM，是用来管理HA的最重要的一个组件。它负责cluster的心跳、主机之间的通信，和vCenter的通信、协调虚拟机的位置、调度虚拟机的重启、记录日志等等。

hostd负责监控直接和虚拟机打交道，例如让虚拟机开机、监控虚拟机的状态等。FDM需要hostd的帮助来完成对虚拟机的 *** 作（例如开机）。简而言之，FDM依赖hostd，如果hostd失效了，FDM也会暂停工作。

vCenter是企业中虚拟架构的集中管理平台，HA虽然不依赖它运转，但是在组建HA cluster的时候必须通过vCenter来发起。它的主要作用是，在主机上安装HA的Agent（指FDM和hostd agent），在Cluster配置更改的时候通知各主机。

【Master和Slave】

ESX4的时候，节点分成Primary和Secondary，最先加入cluster的5个节点成为Primary，并各自存有一份AAM Database。

vSphere 5对此进行了简化。现在不再有Primary和Secondary的概念了，取而代之的是Master和Slave。一个Cluster中只有一台Master，其余都是Slave。

Master的作用是管理整个集群，作为集群的主要管理者，它监控虚拟机的运行状态，判断某一个主机是否宕机，它监控每个VM的位置，并判断VM是否需要在其他主机上重启。对于一个集群来说，Master是其上所有虚拟机的“主人”。

在哪里可以看出主机是否Master？参见下图

没有Master的集群就会群龙无首，群龙无首的集群就fail了。

当Master失效时怎么办？集群不能没有Master，因此Master的选举会马上被触发。

【Master的选举】

选举会在以下情况被触发：

HA创建时；

Master宕机；

Master处于isolated或者集群出现了partitioned状态；

Master被置于维护状态或Standby状态；

集群被重新配置时；

Master和vCenter失去了联系；

选举需要15秒时间。选举通过UDP协议（端口8182）进行。

选举的规则是：拥有最多的datastore的主机当选。如果主机拥有的datastore一样多，那么Managed Objective ID号最大的那台主机当选。

(注：这里的最大不是数值最大，而是从左向右比较依次比较每一位上的数字的大小，例如99就比100大，因为第一位的数字首先比较，9大于1）

【Master伸张其主权】

当选后，新的master会伸张其主人的权力，试图接管所有datastore。

Q: 如何接管？（或者说怎样才算接管了datastore）

A: 通过锁定(lock)一个文件的方式，这个文件存在每个datastore上，名字叫“protectedlist”

该文件的位置是：

//.vSphere-HA//protectedlist

这个文件里面存放的是受HA保护的VM列表。

若Master坏掉，则其lock会过期，新当选的master就可以接管这个文件，并重新上锁。

Master还负责监控Slave的状态，如果发现slave不响应其心跳，则会判断是否要重启slave上的虚拟机。

Slave之间是不相互通信的，除了选举Master的时候。

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

---