Hadoop集群运维
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、配置环境变量。
根据新机器的硬件配置及原始配置，参考集群其他机器环境配置，设置新机器的最大进程数、打开文件句柄数等。（hadoop集群普通节点配置： 96G内存、12*6T硬盘、24核CPU）
[[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启动成功。
- 之后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任务可用性不受故障磁盘影响。
- 如果是spark任务的executor所在服务器磁盘故障，该executor进程若用到故障磁盘，日志会输出报错信息，但其他正常节点executor能正常执行，spark任务执行整体不受影响。
1.3 NodeManager进程故障对Spark任务的影响
- application master所在nm进程故障：spark任务进程一定会down！需立即重启spark任务。
- executor所在NM进程故障：该NM进程所在节点的executor进程down，其他NM节点executor进程正常执行！超过120秒没有响应，被ResourceManager和AM进程确认 Slave lost 和 Lost executor；10分钟后在健康的NM节点上启动新的Executor进程；不影响spark实时任务正常工作。
场景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
：http://liqifei.com/