切换的过程中在设计上有很重要一点考虑，不能同时有两个Active，所以要成为新Active NameNode，要把原来的Active NameNode停止掉。先会很友好地停止，什么是友好呢？就是发一个RPC，如果成功了就是友好的，如果失败了，atv，就会ssh过去，把原来active namenode进程kill掉，这就是Active NameNode异常退的原因。

当这个原因了解了之后，其实要解决这个问题也非常简单。

第一点要把editlog与fsimage保存的本地目录分离配置，这种分离是磁盘上的分离，物理分离。

第二是checkpoint之后fsimage回传限速。把editlog与fsimage两个磁盘分离，fsimage回传的io压力不会对客户端请求造成影响，另外，回传限速后，也能限制io压力。这是比较棘手的问题。原因看起来很简单，但是从现象找到原因，这个过程并没有那么容易。

第二个案例也是一样，Active NN又出现异常退出，产生HA切换。这次和网络连接数有关，这张图是Active NameNode的所在机器的网络连接数，平时都挺正常，20000到30000之间，忽然有一个点一下打到60000多，然后就打平了，最后降下来，降下来的原因很明显，是服务进程退了。

为什么会出现这个情况呢？在后续分析的过程中我们发现了一个线索，在NameNode日志里报了一个空指针的异常。就顺藤摸瓜发现了一个JDK1.7的BUG，参见上面图片所示，在java select库函数调度路径过程中最终会调用这个函数（setUpdateEvents），大家可以看到，如果fd的个数超过了MAX_UPDATE_ARRAY_SIZE（65535）这个数的话，将会走到else路径，这个路径在if进行不等表达式判断时，j2直播，将会出发空指针异常。

接下来的问题是，为什么会产生这么多的链接呢？经过分析我们发现，在问题出现的时候，存在一次大目录的DU操作，而DU会锁住整个namespace，这样就导致后续的写请求被阻塞，最终导致请求的堆积，请求的堆积导致了连接数大量堆积，连接数堆积到一定程度就触发JDK1.7的这个BUG。这个问题的解决，从两个方面看，首先我们先把JDK升级到1.8。其次，调整参数dfs.content-summary.limit，限制du操作的持锁时间。该参数默认参数是0。我们现在是设成10000了，大家可以参考。这是第二个非常棘手的问题。

第三个案例关于YARN主节点的，有一天中午，我们收到报警，发现Active RM异常进程退出，触发HA的切换，然而切换后一会新的Active RM节点也会异常退出，这就比较悲剧，我们先进行了恢复。

之后我们从当时的日志中发现了原因：一个用户写了一万个文件到分布式缓存里，分布式缓存里数据会同步到ZK上，RM持久化作业状态到ZK时超过Znode单节点最大上限，抛出异常，最终导致ResourceManager进程的异常退出。其实问题的解决方法也非常简单，我们增加了限制逻辑，对于序列化数据量大于Znode节点大小的Job，直接抛异常触发Job的失败。另外我们还适当提升Znode节点大小。

以上是在稳定性方面的一些工作，这三个案例跟大家分享一下，如果有类似的问题建议大家可以尝试一下，这些方案是被我们验证OK的。

　　平台治理

接下来介绍一下平台治理这块。包含几个问题，其中第一问题是关于数据的，一方面，就是大家开发了数据之后，经常找不到，要靠喊，比如说在群里喊一下什么数据在哪，谁能告诉我一下，这个效率很低下。另外一方面是之前的管理数据是共享的，不安全，任何人都可以访问其他人的数据。

第二个问题是关于资源，之前是“大锅饭”模式，大家共享计算资源，相互竞争，这样“能吃的“肯定是挤兑”不能吃的“，经常出现核心任务不能按时按点完成，老板看不到数据，这点很可怕。还有是整个集群资源使用情况没有感知，这样根本不知道资源要怎么分配，是否够用。

第三个问题是关于作业的，开发人员开发大量的作业之后，这些作业要怎么管理，实际上他们可能都不知道。还有就是关于作业之间依赖，经常一个指标计算出来要经历多个作业，作业之间依赖是怎么考虑的，单纯靠时间上的依赖是非常脆弱的，如果前期的job延迟产生了，后续的job必然失败。最后一个问题是数据开发人员的效率不高，所需要做的步骤过多。