一次Hadoop集群宕机事故总结

10月27日下午，机房中心交换机坏掉，导致HDFS集群和MR（YARN）集群宕掉。
当时的日志现在已查不到，只能推断整个集群宕掉的原因。


HDFS和YARN的集群，都是master/slave模式，其中处于master角色的组件有：NameNode，ResourceManager。某种角度，只要master没有挂掉，可以认为集群没有挂掉。
同时，我们的HDFS集群和YARN集群都配置了HA，所以master角色可以认为还包括standby NN和standby RMs。
在HDFS HA集群中，JournalNodes也是很重要的角色，因为JN group一旦挂掉或仅仅无法与NNs通信，NNs都不能正常工作。HDFS HA和YARN HA也都依赖Zookeeper集群。


10月27日下午，交换机坏掉后，active NN与其他所有机器都不能通信，包括JNs，这导致active NN shutdown。因为之前standby NN是stop的状态，所以无法进行HA切换。实际上，即使能切换，standby NN所在的机器与其他集群不能通信。所以，这导致HDFS集群整个挂掉。
一个相关的issue：https://issues.apache.org/jira/browse/HDFS-8298。


因为YARN集群配置了HA（实际之前ops没有配置完整，仅仅是相当于打开了RM HA的开关，其他必要的与RM Restart相关的配置都没有），当天下午交换机坏掉后，active RM与ZK失联，自动切换到standby RM，但由于配置不完善（这个很致命），同时standby RM与ZK也是失联的，导致没有RM可以正常工作，YARN集群整个挂掉。
这是当时ops收到的一条报警：Info:Critical! Yarn ResourceManager host 192.168.146.64 status have problem, status is ACTIVE! Time: Tue+Oct+27+19:06:41+CST+201。


当天下午交换机临时回复后，我们对Hadoop集群依次进行了以下操作：
1、启动active NN
2、启动DataNodes
3、启动active RM
4、启动standby NN


第一步active NN正常启动，但由于standby NN已经停了两个多月，active NN在启动时，对fsimage和edits进行checkpoint耗时过多，导致active NN启动时间过长。
第二步没有问题。
第三步基本没有问题，但由于没有配置RM Restart，导致所有未完成的jobs需要重新提交和执行。
第四步也是正常启动，但也由于standby NN已经停了两个多月，JNs上需要checkpoint的edits过多，导致启动时间超长，而且checkpoint占用大量时间。