Hadoop集群运维

场景1：namenode节点故障，active namenode节点状态切换？如何恢复？

1.1 Hadoop HA 的namenode状态切换

模拟线上环境测试，namenode进程down掉一个后，active和standby状态名称节点切换正常。
测试步骤：在测试集群把standby namenode进程kill掉，active节点服务正常，不影响hadoop集群服务，数据存储正常。集群恢复正常后再把active namenode进程kill掉，standby状态节点会被切换为active状态namenode，集群服务正常，数据正常。

1.2 namenode故障如何恢复

如果是存放namenode元数据的硬盘损坏：
联系sa更换新的磁盘，从另一台namenode机器上将${hadoop.tmp.dir}/dfs/name文件压缩成tar包，scp到新磁盘上并解压，该文件夹内存放的是集群操作日志EditLog和集群block元数据Fsimage，然后启动namenode进程完成故障恢复。
普通故障故障或cpu等其他硬件故障问题导致namenode进程故障：
联系sa更换损坏硬件，然后重启namenode节点上的进程namenode、zkfc、nodemanager、datanode。
如果是服务器严重故障，需更换机器：
新机器尽量保留原域名，进行namenode迁移。（namenode迁移请参见下方场景2 ）

场景2：namenode节点切换，namenode迁移？

故障假设：namennode服务器故障，需要更换namenode服务器。

测试环境下模拟集群正常服务不关停情况下namenode迁移流程：

申请新服务器，新服务器仍使用原服务器域名。
基础环境搭建。参考active的namenode环境，安装jdk、配置环境变量。
将存活的namenode节点上hadoop软件打成压缩包，传到新的服务器。

tar -zcf hadoop-2.6.4.tar.gz ./hadoop-2.6.4
scp hadoop-2.6.4.tar.gz vm-dc002.ali.momo.com:/home/dc/datacenter/soft/hadoop/
tar -zxf hadoop-2.6.4.tar.gz -C ./
ln -s hadoop-2.6.4 default

找到core-site.xml配置文件中的hadoop.tmp.dir目录，将存活namenode服务器上的${hadoop.tmp.dir}/dfs/name文件压缩成tar包，传送到新的namenode服务器并解压，该文件与另一台namenode的目录结构保持一致。其他hdfs、yarn、mapreduce相关目录会在相关进程启动后自行建立。

tar -zcf ${hadoop.tmp.dir}/dfs/name.tar.gz ${hadoop.tmp.dir}/dfs/name
mkdir -p ${hadoop.tmp.dir}/dfs 在新机器上创建目录
scp ${hadoop.tmp.dir}/dfs/name.tar.gz 新机器：${hadoop.tmp.dir}/dfs
tar -zxf ${hadoop.tmp.dir}/dfs/name.tar.gz -C ${hadoop.tmp.dir}/dfs/

启动namenode进程：hadoop-daemon.sh start namenode
启动zkfc进程：hadoop-daemon.sh start zkfc 。
zkfc启动后会触发active namenode选举,新namenode节点会被选为standby。
检查两台namenode的状态和namenode进程日志。
hdfs haadmin -getServiceState nn1 #检查namenode节点状态命令
hdfs haadmin -getServiceState nn2 #检查namenode节点状态命令
此时应留意两台机器namenode日志和zkfc日志，看是否正常，进程是否正常。如果nn1和nn2一个active一个standby，日志正常无报错，集群block块数量和数据正常查看均无异常，则namenode迁移完成。
如果上面运行有datanode和nodemanager，启动相关进程：
hadoop-daemon.sh start datanode
yarn-daemon.sh start nodemanager

场景3：datanode故障问题。

3.1 磁盘故障导致datanode进程down

本次（2019-05-29日）采取措施：

修改hadoop集群配置，增加datanode进程对磁盘的容错能力，磁盘容错数量设置为3.（默认配置为0）
增加磁盘健康状态监控脚本（sa目前磁盘监控不完善容易漏报）。

总结： 这样既能及时发现磁盘故障，也能将磁盘故障对hadoop集群的影响降至最低。

日后正常维护：
磁盘故障报警后联系sa更换磁盘，更换完记得调整磁盘权限，然后重启datanode进程。

3.2、datanode down后，hadoop集群的容错处理

模拟datanode进程down故障，观察hadoop集群的容错处理：

首先hadoop集群不会马上认定datanode已经dead，会在10分钟30秒后如果仍然没有datanode心跳，才会认为该datannode进程死亡。
集群确认datanode进程dead五分钟后会将该dead节点上的block切换为missing状态，集群的容错机制将开始把missing的block在其他datanode上重新生成。

总结： datanode重启操作尽量在10分钟内完成，这样对hadoop集群的影响会最小。

Block信息汇报
datanode隔6小时会向namenode汇报一次节点block信息。线上集群未配置采用默认值。

官网配置	默认值	说明
dfs.datanode.directoryscan.interval	21600	Interval in seconds for Datanode to scan data directories and reconcile the difference between blocks in memory and on the disk.
dfs.blockreport.intervalMsec	21600000	Determines block reporting interval in milliseconds.

DataNode健康状态检测：
hadoop datanode 节点超时时间设置：https://www.jianshu.com/p/1680bab38f06
测试机测试：datanode停掉10分钟30秒后，集群把datanode状态切换为dead。
超时时长的计算公式为：timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。

场景4：nodemanager节点故障，对sparkstreaming影响。

注：这部分请参考spark on yarn故障运维https://blog.csdn.net/qq_35488412/article/details/91041983

1.1 磁盘故障对yarn nodemanager的影响。

目前nodemanager默认容错因子是0.25，不超过五分之一的磁盘故障不会影响nm进程启动新的正常container。正在运行的container如果用到故障磁盘，则container上的任务会报错抛出异常。

1.2 磁盘故障对spark任务的影响：

spark ApplicationMaster进程可能会受到磁盘故障影响而出现进程异常，此时resourcemanager会自动重启一个新的applicationmaster进程来继续提供服务。所以spark的am服务不受影响。本次磁盘故障，spark一个实时任务的am进程在该服务器上，未受到影响，目前服务正常。
如果是spark任务的executor所在服务器磁盘故障，该executor进程会报错，但其他正常节点executor能正常执行，spark任务整体不受影响。

1.3 NodeManager进程故障对Spark任务的影响

在测试服务器模拟NodeManager进程down，该机器的excutor挂掉，十分钟后启动新的executor进程。

场景4部分：具体细节请参见：spark on yarn故障运维：https://blog.csdn.net/qq_35488412/article/details/91041983