1. 首页 > Hadoop教程 > 正文

大数据教程FG178-Hadoop断电/宕机故障模拟实战

本文详细介绍Hadoop断电/宕机故障模拟实战,包括故障预防、故障模拟、故障恢复、验证检查等内容,适合大数据运维工程师使用。学习交流加群风哥微信: itpux-com

Part01-基础概念与理论知识

1.1 断电/宕机概述

断电/宕机是指服务器由于电源故障、硬件故障或操作系统故障导致突然停止运行。更多视频教程www.fgedu.net.cn

常见原因:

  • 电源故障
  • 硬件故障
  • 操作系统崩溃
  • 人为误操作
  • 网络故障

1.2 故障影响分析

故障影响:

# 故障影响
1. NameNode宕机
– HDFS不可用
– 无法读写数据
– 业务中断
– 影响范围:全集群

2. DataNode宕机
– 部分数据不可用
– 副本自动恢复
– 影响范围:部分数据

3. ResourceManager宕机
– YARN不可用
– 无法提交任务
– 业务中断
– 影响范围:全集群

4. NodeManager宕机
– 该节点任务失败
– 任务自动重试
– 影响范围:单个节点

5. 全集群宕机
– 所有服务不可用
– 业务完全中断
– 影响范围:全集群

1.3 恢复原理

恢复原理:

风哥提示:Hadoop设计时就考虑了故障恢复,通过多副本、EditLog、WAL等机制保障数据安全。更多学习教程公众号风哥教程itpux_com

Part02-生产环境规划与建议

2.1 故障预防

故障预防:

# 故障预防
1. 电源预防
– UPS不间断电源
– 双路电源
– 发电机备份
– 定期检查电源

2. 硬件预防
– 服务器冗余
– 磁盘RAID
– ECC内存
– 硬件监控

3. 软件预防
– 系统补丁
– 软件更新
– 配置优化
– 定期巡检

4. 运维预防
– 标准化操作
– 变更管理
– 权限控制
– 培训考核

2.2 监控告警

监控告警:

监控指标:

  • 电源:电源状态、UPS状态
  • 硬件:温度、风扇、磁盘
  • 系统:CPU、内存、磁盘IO
  • 服务:进程状态、端口监听

from bigdata视频:www.itpux.com

2.3 应急预案

应急预案:

# 应急预案
1. 应急组织
– 总指挥
– 技术组
– 业务组
– 沟通组

2. 应急流程
– 故障发现
– 故障上报
– 故障评估
– 故障处理
– 故障验证
– 故障总结

3. 联系方式
– 内部联系
– 厂商联系
– 业务联系

4. 回滚方案
– 回滚条件
– 回滚步骤
– 回滚验证

Part03-生产环境项目实施方案

3.1 故障模拟

3.1.1 进程Kill模拟

# 故障模拟 – 进程Kill
# 警告:仅在测试环境执行,生产环境谨慎操作!

# 1. 模拟NameNode宕机
jps | grep NameNode
kill -9 $(jps | grep NameNode | awk ‘{print $1}’)
sleep 10
jps

# 2. 模拟DataNode宕机
jps | grep DataNode
kill -9 $(jps | grep DataNode | awk ‘{print $1}’)
sleep 10
jps

# 3. 模拟ResourceManager宕机
jps | grep ResourceManager
kill -9 $(jps | grep ResourceManager | awk ‘{print $1}’)
sleep 10
jps

# 4. 模拟NodeManager宕机
jps | grep NodeManager
kill -9 $(jps | grep NodeManager | awk ‘{print $1}’)
sleep 10
jps

3.1.2 系统重启模拟

# 故障模拟 – 系统重启
# 警告:仅在测试环境执行!

# 1. 重启单个节点
# 先停止服务
stop-all.sh

# 重启系统
reboot

# 2. 重启后检查
# 系统启动后
ssh fgedu-nn
uptime
dmesg | tail -100

# 3. 启动服务
start-all.sh
sleep 60

# 4. 验证
jps
hdfs dfsadmin -report
yarn node -list

3.2 故障恢复

3.2.1 NameNode恢复

# NameNode恢复
# 1. 检查HA状态
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 2. 如果有Standby,自动故障转移
# ZKFC会自动处理

# 3. 手动故障转移(如果需要)
hdfs haadmin -failover nn1 nn2

# 4. 恢复故障的NameNode
# 检查日志
tail -n 200 /bigdata/app/hadoop/logs/hadoop-hdfs-namenode-*.log

# 启动NameNode
hdfs –daemon start namenode
sleep 30

# 检查状态
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 5. 验证
hdfs dfs -ls /
hdfs dfsadmin -report

3.2.2 DataNode恢复

# DataNode恢复
# 1. 检查DataNode
jps
hdfs dfsadmin -report

# 2. 启动DataNode
hdfs –daemon start datanode
sleep 60

# 3. 检查状态
jps
hdfs dfsadmin -report

# 4. 检查块恢复
# 观察日志
tail -f /bigdata/app/hadoop/logs/hadoop-hdfs-datanode-*.log

# 5. 验证
hdfs fsck /

3.3 验证检查

3.3.1 验证清单

# 验证清单
## 服务验证
– [ ] NameNode运行正常
– [ ] 所有DataNode运行正常
– [ ] ResourceManager运行正常
– [ ] 所有NodeManager运行正常
– [ ] 其他组件运行正常

## 数据验证
– [ ] HDFS可正常读写
– [ ] 数据块完整
– [ ] 副本数量正常
– [ ] Hive表可查询
– [ ] HBase表可访问

## 功能验证
– [ ] 可提交MapReduce任务
– [ ] 可提交Spark任务
– [ ] 业务功能正常

## 性能验证
– [ ] 读写性能正常
– [ ] 资源使用正常
– [ ] 响应时间正常

风哥提示:故障恢复后要进行全面验证,确保系统和数据都正常。不要只检查进程,还要验证功能和数据。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 NameNode宕机恢复

4.1.1 实战案例

# NameNode宕机恢复实战
# 场景:Active NameNode宕机

# 1. 发现故障
# 监控告警
# 业务反馈HDFS不可用

# 2. 检查状态
echo “=== Checking NameNode Status ===”
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 输出示例:
# nn1: standby
# nn2: active (如果自动故障转移成功)
# 或者
# nn1: unknown
# nn2: standby

# 3. 检查ZKFC
jps | grep DFSZKFailoverController

# 4. 如果自动故障转移没成功,手动执行
if [ “$(hdfs haadmin -getServiceState nn2)” != “active” ]; then
echo “Manual failover…”
hdfs haadmin -failover nn1 nn2
fi

# 5. 验证
echo “=== Verifying HDFS ===”
hdfs dfs -ls /
hdfs dfsadmin -report

# 6. 恢复原NameNode
echo “=== Recovering nn1 ===”
# 检查日志
tail -n 100 /bigdata/app/hadoop/logs/hadoop-hdfs-namenode-fgedu-nn01.log

# 启动
ssh fgedu-nn01 “hdfs –daemon start namenode”
sleep 30

# 检查状态
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 7. 最终验证
echo “=== Final Verification ===”
hadoop jar /bigdata/app/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar pi 2 100

4.2 DataNode宕机恢复

4.2.1 实战案例

# DataNode宕机恢复实战
# 场景:一个DataNode宕机

# 1. 发现故障
hdfs dfsadmin -report

# 输出示例:
# Live datanodes (2):
# …
# Dead datanodes (1):
# fgedu-dn01

# 2. 检查节点
ssh fgedu-dn01
uptime
jps

# 3. 启动DataNode
echo “Starting DataNode…”
hdfs –daemon start datanode
sleep 60

# 4. 检查
jps
hdfs dfsadmin -report

# 5. 观察块恢复
echo “Checking block recovery…”
hdfs fsck /

# 6. 验证
hdfs dfs -ls /
hdfs dfs -put /etc/hosts /test/
hdfs dfs -cat /test/hosts

4.3 集群宕机恢复

4.3.1 实战案例

# 集群宕机恢复实战
# 场景:全集群宕机

# 1. 检查服务器状态
# 逐个检查服务器
for host in fgedu-nn01 fgedu-nn02 fgedu-dn01 fgedu-dn02 fgedu-dn03; do
echo “=== Checking $host ===”
ssh $host “uptime; jps”
done

# 2. 启动ZooKeeper
echo “=== Starting ZooKeeper ===”
for host in fgedu-zk01 fgedu-zk02 fgedu-zk03; do
ssh $host “/bigdata/app/zookeeper/bin/zkServer.sh start”
done
sleep 30

# 检查ZK
/bigdata/app/zookeeper/bin/zkServer.sh status

# 3. 启动JournalNode
echo “=== Starting JournalNode ===”
for host in fgedu-jn01 fgedu-jn02 fgedu-jn03; do
ssh $host “hdfs –daemon start journalnode”
done
sleep 10

# 4. 启动NameNode
echo “=== Starting NameNode ===”
ssh fgedu-nn01 “hdfs –daemon start namenode”
ssh fgedu-nn02 “hdfs –daemon start namenode”
sleep 30

# 检查NN
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 5. 启动DataNode
echo “=== Starting DataNode ===”
for host in fgedu-dn01 fgedu-dn02 fgedu-dn03; do
ssh $host “hdfs –daemon start datanode”
done
sleep 60

# 6. 启动ResourceManager
echo “=== Starting ResourceManager ===”
ssh fgedu-rm01 “yarn –daemon start resourcemanager”
ssh fgedu-rm02 “yarn –daemon start resourcemanager”
sleep 30

# 7. 启动NodeManager
echo “=== Starting NodeManager ===”
for host in fgedu-dn01 fgedu-dn02 fgedu-dn03; do
ssh $host “yarn –daemon start nodemanager”
done
sleep 30

# 8. 启动其他组件
# Hive、HBase等

# 9. 验证
echo “=== Verifying Cluster ===”
jps
hdfs dfsadmin -report
yarn node -list
hdfs dfs -ls /
hadoop jar /bigdata/app/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar pi 2 100

生产环境建议:全集群宕机恢复要按顺序启动,先ZK、再JN、再NN、再DN。启动后充分验证。更多视频教程www.fgedu.net.cn

Part05-风哥经验总结与分享

5.1 最佳实践

最佳实践:

  • 高可用:所有关键组件配置HA
  • 监控:全面监控,及时告警
  • 备份:定期备份,验证备份
  • 演练:定期演练,熟悉流程
  • 文档:完善文档,便于操作

5.2 经验教训

# 经验教训
1. 不要忽视UPS
– 教训:断电导致集群宕机
– 改进:配置UPS

2. 监控要全面
– 教训:故障发现晚
– 改进:完善监控

3. 演练很重要
– 教训:故障时手忙脚乱
– 改进:定期演练

4. 文档要详细
– 教训:恢复时找不到步骤
– 改进:完善文档

5.3 检查清单

# 检查清单
## 日常检查
– [ ] UPS状态正常
– [ ] 服务器电源正常
– [ ] 磁盘空间充足
– [ ] 服务运行正常

## 恢复检查
– [ ] 服务器启动正常
– [ ] 服务按顺序启动
– [ ] 所有服务运行正常
– [ ] 数据验证通过
– [ ] 功能验证通过
– [ ] 性能验证通过

风哥提示:断电/宕机虽然不常见,但一旦发生影响很大。要做好预防、监控、预案、演练,确保关键时刻能够快速恢复。学习交流加群风哥微信: itpux-com

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

联系我们

在线咨询:点击这里给我发消息

微信号:itpux-com

工作日:9:30-18:30,节假日休息