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

还好，经过几天时间研读Hadoop源码，初步了解了这部分逻辑，我们打开Hadoop的DEBUG日志，观察到如下日志：

我们发现，一个机架下允许写入的块数超了，而别的机架没有可用的存储策略写入时，就会出现上述的循环。我们看下，一个机架下允许写入多少个数据块，又是怎么决定的？如下图所示：

我们分了6个机架，3个SATA，3个SSD，从日志看，我们一个数据块要写入24个副本，这24个副本均要写入到SATA设备上。每个机架Rack上最多可以写入5个副本，3个SATA机架可以写入15个，另外的9个写入失败。Hadoop3.2.1在计算机架策略的时候并未考虑到这种情况，另外的SSD设备无法写入SATA存储策略的数据，导致了Hadoop在这种情况下将SATA设备循环几百遍，CPU飙升。

由于后续的9个副本，一直没有地方写入，Hadoop就会又像之前那样，将所有的SATA的设备循环上几百遍。这也会导致CPU的飙升。

我们实际生产环境中，写入24个副本的情况是极少的，只存在更新的一些场景，由于带更新的数据，需要被每个节点读取（有点类似Hadoop的DistirbuteCache），如果2副本，会造成个别DataNode的压力过大，故我们增大了副本数。

这一情况也跟之前业务提出，只要一执行更新，就会明显感受到业务查询的卡顿的现象对应上。

针对这个问题，我们认为应该对机架分配策略进行调整，不允许单独的SSD与SATA在各自不同的机架上，一个机架上必须即有SSD设备，也要有SATA设备。这样这个问题就可以规避了。但我们担心一旦更改了此时的机架策略，会造成Hadoop的副本大量迁移（为了满足新的机架策略的需要），我们的集群规模太大了，我们最终还是选择了修改NameNode的源码。从源码层面解决这个问题，如下图所示：

四、 总结

1. Hadoop Router针对NameNode的failover没有进行重试处理，在主备切换期间，服务报错，整体不可用。

2. Hadoop addBlock 在3.2.1版本的设计思路上会因为机架策略的问题，进行循环处理，导致CPU占用很高，加锁频率很高。

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

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