集群正常工作时，所有节点都在一个分区内（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也停止了。
当前集群状态如下图：
hadoop-yarn的主节点resourceManager相当于yarn集群的中央管理器，负责整个集群资源的调度分配工作。那么当主节点down机期间，已发布的应用以及从节点nodeManager是否还可有条不紊的继续工作呢？resourceManager挂掉，又重启后，整个yarn集群又会发生什么样的变化。
http://hadoop.apache.org/docs/stable2/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html
官方文档对于主节点resourcemanager挂掉后，工作恢复的流程分为两个阶段。
阶段一：
对于早期hadoop-2.4.0版本的yarn，主节点挂掉后，从节点和已发布应用均可正常工作。通过hdfs或zk可实现主节点的状态保存，当主节点重启后，会尝试从hdfs或zk上获取之前保存的集群信息，然后进行恢复。不过有一点比较坑爹的是，主节点重启后会像nodeManager和已发布应用也即appMaster发送一条re-sync命令，nodeManager接受到这个命令后会杀死由本身启动的所有container，appMaster接受到这条命令后会结束自身进程，rm收集完状态信息后会重启appMaster。
阶段二：
之后的yarn在此做了优化，rm重启后，不会要求kill掉appMaster，nm收到rm发送的re-sync命令后也不会kill掉已经启动的container。
笔者使用hdfs来保存rm运行时状态用于重启恢复
实验：
将运行中的yarn集群主节点down掉，查看后台nm日志输出
nm在不断的做与rm的重连 *** 作。这时我们将主节点重启，整个集群没有收到任何影响。也就是说yarn主节点短时间挂掉对应用用户是透明无影响的。随机重启即可。
但是，如果时间长不重启rm，nm会停止，随即appMaster也会停止。
这个时间限制可通过设置 yarn.resourcemanager.connect.max-wait.ms 来控制。
如果希望nm不断尝试连接rm，可以将这个值设置为-1.这样就是rm挂掉后，不会对集群和已发布应用产生任何影响，发现不可调度新任务时，重启即可。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）