场景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
3
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、配置环境变量。
根据新机器的硬件配置及原始配置，参考集群其他机器环境配置，设置新机器的最大进程数、打开文件句柄数等。（hadoop集群普通节点配置： 96G内存、12*6T硬盘、24核CPU）
[dc@game-spark001.dx.momo.com ~]$ 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
将存活的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
1
2
3
4
找到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/
1
2
3
4
修改新机器的主机名为原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 nodemanage
场景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启动成功。
之后datanode开始向namenode上报block元数据信息，namenode校验后如果跟自身内存中该datanode所属的block元数据有出入则发布容错指令，datanode根据namenode指令执行容错操作（新建、删除block等）。
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.
参数备注：
directoryscan.interval 是扫描节点上的block信息，更新到内存中。6小时扫描一次
blockreport.intervalMsec 将内存中的block元数据上报namenode，这时候如果上报的block元数据跟namenode存储的该节点元数据不符，则namenode会下发容错指令（删除，新建block等）给datanode执行。
注：这两个线程都是各自以6小时为周期，两个线程间没有固定时间间隔，各自工作。
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
相关资料参考:
NameNode内存模型：https://blog.csdn.net/baiye_xing/article/details/76273495
源码之HDFS之DataNode：启动过程：https://www.jianshu.com/p/1b7fea129368
---------------------
作者：山森海子
来源：CSDN
原文：https://blog.csdn.net/qq_35488412/article/details/91042033
版权声明：本文为博主原创文章，转载请附上博文链接！
