记一次上千节点Hadoop集群升级过程

后经过多次抓取jstack，发现导致NameNode卡顿的堆栈的位置点如下：

没错，是addBlock，也就是写数据的写锁会阻塞所有的查询。按照以往的经验，我们认为是上图中的锁引起的，故我们进行了去锁操作。

由于NameNode主备切换的问题已经解决，所以我们可以在生产系统通过热切的方式来验证我们的问题。去锁后的结果非常遗憾，卡顿现象不但没有减少，相反变得更严重，整台NameNode的负载不但没有降低，反而直接飙升到全满。

没办法，我们只好继续排查原因，仔细分析该类的相关实现，最终发现如下问题：

结合上面的原因，我们稍微改了下代码实现。

经分析发现进行一次addBlock的请求，这里就有一次循环，这是一个机架上的所有机器。这意味着每调用一次addBlock方法，NameNode就要对一个机架内的设备进行一次循环，集群设备上千台，就是循环上千次，那这CPU使用率还了得！之前加锁状态，因为有锁的限制，只是会导致写入慢，查询还算可用。现在把锁去掉了，干脆CPU飚满，更是查不动了。然后jstack发现卡顿的地方变了，如下图所示：

我们临时调整NameNode的日志级别，调整为DEBUG级别，看到了如下的输出，更是进一步的验证了我们的想法。

同时我们对比了下Hadoop2.8.5版本的源码，发现这个地方的逻辑在Hadoop3.2.1中做了较大的变更。存在设计不当的问题，这种循环方式会耗费很多CPU。设计的本意是随机抽取节点，却要遍历一个机架下的所有节点，挨个加一遍锁。为了一次addBlock，平白无故加了几百次锁，哪能这样设计呢？我们仿照2.8.5的一些写法，重新修正了一下，针对这里的随机方式进行了重新改造。

改动完毕后，再继续抓jstack，崩溃的是，这块的逻辑确实抓不到了，但又在别的地方出现了，一样有个类似的循环。详细看代码发现Hadoop3.2.1的这个类里面，这样的循环太多了，在生产系统上改不起，也不敢改了。只能转变思路来解决，如果是因为这个循环的问题导致的NameNode卡顿，为何不是一直卡顿，而是间歇性卡顿，理清楚这个思路，也许就打开了一扇窗。

1. SSD机器的Xreceiver引发的血案

我们分析了循环里的IP列表（DataNode的IP），并且结合现场日志的设备，发现了一个规律，这些循环里面的IP，均是SSD设备的IP，并非是SATA设备的IP。现场设备分为六组，每组一个机架，SATA和SSD各占一半。从IP的规律上来看，这些IP均是SSD设备。进一步分析，什么情况下这些DN会被加入到这个循环里面，从日志和源码分析，我们最终定位在Exclude上，也就是说Hadoop认为这些设备是坏了的，是应该被排除掉的设备。

难道是我们的SSD设备全都宕机了，或者他们的网络有问题？但经过排查，我们排除了这些问题。问题又回归到了源码层面，经过了大约1天的追踪定位，发现如下逻辑：

Hadoop在选择写入的DN的时候，会考虑到DN的负载情况，如果DN负载比较高，它会将这个节点加入到Execude里面，排除掉这个节点。而判断一个DN负载高低的就是Xreceiver的链接数量。默认情况下，只要Xreceiver的链接数量超过了整个集群连接数量的2倍，就会排除掉这个节点。而LSQL本身采用了异构的特性，意味着我们会优先从SSD盘读取数据，而SSD盘设备的性能好，数量又相对较少，导致这些SSD设备的机器连接数远高于SATA盘的链接数。SATA盘冷数据偏多，几乎很少有人去查询。针对这一情况，就会出现在一瞬间，因为连接数的问题，导致所有的或大多数的SSD设备被排除掉的情形。

我们的Hadoop集群有一部分数据的写入是采用ONE_SSD的模式，也就是一份数据存储在SATA设备上，另一份数据会存储在SSD设备上。而Hadoop3.2.1的特性，会随机在SSD设备里抽取一个节点，如果它没有在排除的execlude列表里，则会写入到这个设备里。而如果该设备被排除了，那么Hadoop就会再次尝试，再随机抽取其他节点，如此反复循环。但是我们的SSD设备因为Xreceiver负载的关系，绝大多数或全部都被排除掉了，直接导致了不断的循环，甚至上百次，最终还有可能发现一个SSD设备都不可用。日志里会提示2个副本1个SATA的写入成功了，还缺少一个副本没写成功，如下图所示：

上述问题中，直接导致大数据集群的两个致命性问题为：第一，NameNode CPU飚高，产生严重的间歇性卡顿；第二，SSD设备间歇性的被排除掉，只写成功了一个SATA副本，如果SATA设备突然损坏一个盘，那么数据就会丢失。

针对SSD的Xreceiver修复方法很简单，禁用该功能，或者调大倍数，如下图所示：

调整完毕后，我们非常明显的感受到了NameNode负载的下降，同时业务的所有查询，响应速度回归正常。

2. 机架分配策略不合理导致的同样问题

在我们验证上述问题的过程中，虽然NameNode的负载明显下降，但是上面所说的循环情况依然存在，查看DEBUG日志，令我们非常惊讶的是，这次循环的设备不是SSD设备，变成了SATA设备，这是什么情况？说不通啊。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!