一. 问题描述
今天早上到公司,突然收到CDH集群某个节点的存储量的告警,如下图所示:
从图中可以看出,每个节点的HDFS空间是相同的,大多节点HDFS使用量在40%左右,而出问题的这个节点居然直逼80%,鉴于之前问题出现过多次,且每次都是利用空余时间使用HDFS的rebalance进行解决的,此处需要找出具体问题,规避此类问题。
二. 解决方案
2.1 查看节点安装的组件
2.2 排查HDFS配置
初步排查了一下各个节点的HDFS配置,暂未发现问题,且各个节点HDFS的配置是通过 Cloudera Manager进行配置的,配置也相同,不存在某个节点的HDFS相关配置出现问题,进而出现个别节点资源使用率高的情况。
2.3 排查Yarn配置
2.3.1 首先查看下nodemanager的日志
对比出问题的节点和正常的节点,从审计日志量来看,出问题的节点审计日志明显比正常节点多。
审计日志内容均是申请AM的,现在的问题是为什么cdh10节点的AM比其他节点多那么多?
2.3.2 查看container分配情况
正在运行container:
从下面截图来看,未发现啥异常情况。
从历史分配情况来看:
对比了cdh10和cdh7,发现近7天分配的container是均匀的。
2.3.3 查看调度机制
那么此时可以这么理解,当集群处于空闲时,突然来了一个任务,那么此时因为所有container的优先级相同,优先选择的就是本节点的container,而第一个container 用于启动作业的AM进程,这也就对应了之前的,chd10节点申请AM会比其他节点多很多。
我们知道AM用于协调,并不直接参与预算,真正参与运算的是container,而HDFS一般是计算节点优先写一份数据导datanode,然后再写其他副本。但是从上一步的分配情况来看,container分布是均匀的,
2.3.4 查看集群任务情况
从 job history上来看,可以看到,集群内小任务比较多,而因为是CDH集群,调度采用的是 Fair Scheduler(公平调度器),没有给小任务预留一部分集群资源。
2.3.5 集群负载情况
从集群的负载情况来看,集群存在明显的业务高峰期和空闲期。
2.3.6 resourcemanager与nodemanager是否可以混合部署
搜索到某个大佬给得说法:
一般是建议分开进行部署。
2.4 初步判断
初步判断,由于cdh10节点,既包含resourcemanager又包含nodemanager,且对于优先级相同的 Containers,优选选择满足本地性的 Container,参与计算的Container会优先写一份到本地的HDFS,故cdh10节点写HDFS会比较多。
于是建议运维先进行 HDFS rebalance,然后将cdh10节点nodemanager进行删除。
2.5 最终结论
近期比较忙,没让运维的处理,然后又有flume消费Kafka的数据实时同步到HDFS,因为之前缺失一部分数据,然后某几个节点在补录数据,刚好补录历史数据的进程出现了问题,就把这部分数据从HDFS上删除了,打算重新补录。
删除后发现,cdh10和cdh3的HDFS使用量突然降下来了,问题最终浮出水面。
cdh10和cdh3上刚好就是补录数据,而HDFS的写流程,第一个副本客户端优先,此例中flume节点所在的节点就是客户端。