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也停止了。
当前集群状态如下图:
在Linux上安装Hadoop之前,需要先安装两个程序:1. JDK 1.6或更高版本
2. SSH(安全外壳协议),推荐安装OpenSSH。
下面简述一下安装这两个程序的原因:
1. Hadoop是用Java开发的,Hadoop的编译及MapReduce的运行都需要使用JDK。
2. Hadoop需要通过SSH来启动salve列表中各台主机的守护进程,因此SSH也是必须安装的,即使是安装伪分布式版本(因为Hadoop并没有区分集群式和伪分布式)。对于伪分布式,Hadoop会采用与集群相同的处理方式,即依次序启动文件conf/slaves中记载的主机上的进程,只不过伪分布式中salve为localhost(即为自身),所以对于伪分布式Hadoop,SSH一样是必须的。
(2)配置环境变量
输入命令:
sudo gedit /etc/profile
输入密码,打开profile文件。
在文件的最下面输入如下内容:
#set Java Environment
export JAVA_HOME= (你的JDK安装位置,一般为/usr/lib/jvm/java-6-sun)
export CLASSPATH=".:$JAVA_HOME/lib:$CLASSPATH"
export PATH="$JAVA_HOME/:$PATH"
这一步的意义是配置环境变量,使你的系统可以找到JDK。
(3)验证JDK是否安装成功
输入命令:
java -version
查看信息:
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)