HDFS datanode心跳与运维中的实际案例

分布式系统的节点之间常采用心跳来维护节点的健康状态，如yarn的rm与nm之间，hdfs的nn与dn之间。
DataNode会定期（dfs.heartbeat.interval配置项配置，默认是3秒）向namenode发送心跳，
如果Namenode长时间没有接受到datanode发送的心跳，我们在50070的nn管理界面上就会看到它的lastcontact
字段越来越大，至到最后变为dead,namenode就会认为该DataNode失效。

ClientProtocol.sendHeartBeat方法就是用于心跳汇报的接口，除了携带标识DataNode身份的DataNodeRegistration
对象外，还包含数据节点上所有存储的状态，缓存的状态，正在写文件数据的连接数，读写数据使用的线程数等。
sendHeartBeat会返回一个heartBeatResponse对象，这个对象包含了Namenode向DataNode发送的名字节点指令，以及当前NameNode
的HA状态，即它是Active的还是standBy的，需要特别注意的是，在开启了HA的HDFS集群中，DataNode是需要同时向ACTIVE和standby的
NN发送心跳的，不过只有Active的NN才能向DN下发名字节点指令。

DataNode的启动过程
DataNode进程启动后与NN的交互包含三个部分，握手，注册与块汇报与缓存汇报。
DN启动时会首先通过datanodeProtocol.versionRequest获取NN的版本号以及存储信息等，然后DN会对NN的当前软件版本号和DN的当前软件版本号进行
比较，确保他们是一致的。当软件升级和NN格式化之后，这种比对一般是通不过的。
成功完成握手后，DN会通过DatanodeProtocol.register方法向NN注册，NN接收到注册请求后，会判断当前DN的配置是否属于集群，NN有白名单或黑名单与安全
配置，再确认他们之间的版本号是否一致。
注册成功后，DN就需要将本地的数据块以及缓存的数据块向上报到到NN，NN会利用这些信息重新建立内存中数据块与DN之间的对应关系。
DN启动成功后，通过心跳与NN交互,NN知道DN的活动状态以给其派发任务。NN会在DN的心跳信息中携带名字节点指令，指导DN进行数据块的复制，删除与恢复等操作。
当DN成功地添加了一个新的数据块或删除一个已有的数据块时，需要通过DatanodeProtocol.blockReeivedAndDeleted方法向NN汇报，NN接收到汇报之后，
会更新NN内存中数据块与数据节点之间的对应关系。

运维中遇到一个问题，版本CDH4，HA切换比较频繁，而且ZK检查到ACTIVE NN没有响应后，完成切换，但成为ACTIVE的NN又没有响应，又切换。
同时伴随的一个问题时，有部分DN节点启动后心跳信息一直收不到，LASTCONCAT一直变大，最后变为dead,经过查看DN的日志信息，发现
DN在scandatapool的时候卡在那里，根据我们上面的理解，是它在启动后扫描本地的数据块的时候时间过长，可能是因为内存不足，因为数据块扫描需要递归进行，
需要建立一个大的存储，然后调整Xmx内存为原来的两倍后问题解决。同时HA的频繁节换的问题也消失。

这个问题的原因是因为在一开始DN的机器维护的数据块少，消耗的内存不多，随着数据块的增多，DN需要的内存也在增加，如果内存给不到位，就容易卡死。

同样类似的问题，我们之前维护的时候发现NN切换并且NN启动的过程卡死，最后发现原因都是因为内存问题，不过NN是因为小文件过多，一亿多的inodes,造成加载过程过慢。

而且原来给的内存不够所致。这一点情况在维护的过程中一定要特别注意。