Hadoop集群运维

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故障如何恢复

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

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

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

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

1. 申请新服务器，新服务器仍使用原服务器域名。
2. 基础环境搭建。参考active的namenode环境，安装jdk、配置环境变量。
3. 将存活的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

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/

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

场景3：datanode故障问题。

3.1 磁盘故障导致datanode进程down

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

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

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

日后正常维护：

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

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

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

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

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

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任务的影响：

1. spark ApplicationMaster进程可能会受到磁盘故障影响而出现进程异常，此时resourcemanager会自动重启一个新的applicationmaster进程来继续提供服务。所以spark的am服务不受影响。本次磁盘故障，spark一个实时任务的am进程在该服务器上，未受到影响，目前服务正常。
2. 如果是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