Hadoop集群运维

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

1.1 Hadoop HA 的namenode状态切换

模拟线上环境测试，namenode进程down掉一个后，active和standby状态名称节点切换正常。
namenode状态切换命令：

hdfs haadmin -transitionToActive -forcemanual nn1 操作说明：当active节点正常时，使用hdfs haadmin -transitionToActive命令对两个namenode节点切换都不起作用.
hdfs haadmin -transitionToStandby -forcemanual nn1 操作说明：当active节点正常时，执行可以将active的namenode节点转换成standby状态。
hdfs  haadmin -failover --forcefence --forceactive  nn1  nn2 操作说明：该命令在配置故障自动切换（dfs.ha.automatic-failover.enabled=true）之后，无法手动进行。可将该参数更改为false(不需要重启进程)后，重新执行该命令即可。hdfs  haadmin -failover --forcefence --forceactive  nn1  nn2

1.2 namenode故障如何恢复

如果是存放namenode元数据的硬盘损坏：
联系sa更换新的磁盘，从另一台namenode机器上将${hadoop.tmp.dir}/dfs/name文件压缩成tar包，scp到新磁盘上并解压，该文件夹内存放的是集群操作日志EditLog和集群block元数据Fsimage，然后启动namenode进程完成故障恢复。
namenode启动后的数据同步： 新的namenode进程启动后，会通过zk进行active、standby状态选举，正常的那台namenode节点事务id最新所以会被继续选为active。另一台新加入namenode为standby状态，并从JournalNode中同步最新的fsimage和editlog数据到自己的内存和磁盘文件中，最终使active nameonde和standby namenode元数据保持一致。
普通故障故障或cpu等其他硬件故障问题导致namenode进程故障：
联系sa更换损坏硬件，然后重启namenode节点上的进程namenode、zkfc、nodemanager、datanode。
如果是服务器严重故障，需更换机器：
新机器尽量保留原域名，进行namenode迁移。（namenode迁移请参见下方场景2 ）

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

namenode迁移流程：

申请新服务器，新服务器仍使用原服务器主机名。
基础环境搭建。参考active的namenode环境，安装jdk、配置环境变量。

[[email protected] ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 。
file size               (blocks, -f) unlimited
pending signals                 (-i) 385261
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 655350
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 65535
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

将存活的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/

修改新机器的主机名为原namnode主机名，关机原机器或更换原机器主机名。
启动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进程死亡。
集群在10分30秒后确认datanode进程dead之后，会将该dead节点上的block切换为missing状态，集群的容错机制将开始把missing的block在其他datanode上重新生成。

总结： datanode重启操作尽量在10分钟内完成，这样对hadoop集群的影响会最小，实际单台datanode节点从启动到在namenode上注册成功并开始提供服务这个过程一般都在一分钟内。

datanode启动流程简介：

加载并格式化hdfs的存储目录。
启动DirectoryScanner等线程，扫描各存储目录下Block元数据。
向namonode注册。

之后datanode开始向namenode上报block元数据信息，namenode校验后如果跟自身内存中该datanode所属的block元数据有出入则发布容错指令，datanode根据namenode指令执行容错操作（新建、删除block等）。

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

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

山森海子