Hadoop集群硬盘故障分析与自动化修复

小雪崩

　　Hadoop集群硬盘故障分析与自动化修复
　　摘要：
　　硬盘在服务器中起着至关重要的作用，因为硬盘里面存储的是数据，随着制造业技术的提高，硬盘的类型也在逐渐的改变。对于硬盘的管理是IAAS部门的责任，但作为业务运维也需要懂得相关的技术。
　　有的公司采用LVM来管理硬盘，这样做方便扩缩容，也有的公司直接用裸盘来存数据，这样做的好处是不会因LVM而损失掉一部分硬盘I/O速度。需要根据不同的场景采用不同的方式来管理。
　　Hadoop集群中跑Datanode服务的节点不建议做LVM，因为没有必要，你想想，Hadoop的HDFS就是做分布式大数据的，用Hadoop的公司肯定是有大量的数据，所以对于HDFS基本原则是硬盘有多少空间就用多少空间，不够用的话再加机器或者加硬盘。
　　硬盘故障在服务器硬件故障中所占的比例是最高的，下面我给出Ebay的故障报告中的硬件部件和对应故障率状态图：

　　从图中可以很明显的看到硬盘故障率最高，达到了84%，所以对于运维来说，如果能统计出平时工作中的故障案例，并把它们写成自动化修复脚本，那将有很重大的意义。
　　如果你的眼光还能看得更远一点的话，可以想一想：能不能做出一套硬件故障检测与修复的系统呢？（需要硬件厂商的合作），我这里只做抛砖引玉，如果你能想到这些，说明你已经走在了自动化运维的路上了。
　　这里先介绍一例最典型的硬盘故障案例，然后会给出硬盘故障的常规处理步骤，最后我会附上硬盘自动化修复脚本的链接。
　　环境：
　　这台服务器是hadoop集群里的一台slavenode ，上面跑的有datanode和nodemanager服务，总共有12块数据盘和一块系统盘，每块数据盘都只做了一个partition，文件系统用的是ext4，没有做LVM。
　　故障发现：
　　某天我们的监控系统报出了一条告警，说一个用户的一个Job跑失败了，因为这个用户是很重要的用户，所以他的每个Job跑的成功与否，跑了多长时间我们都是有监控的，废话不多说。

　　先查看Job>　　考虑到公司安全，以上主机名和文件名都是假设的，大家明白就好。登录出现问题的那台机器，“df -h”先查看下硬盘情况：
　　#df -h
　　Filesystem           Size  Used Avail Use% Mounted on
　　/dev/sda2            451G   20G  408G   5% /
　　tmpfs                 36G     0   36G   0% /dev/shm
　　/dev/sdb1            1.9T  1.5T  354G  81% /hadoop/1
　　/dev/sdc1            1.9T  1.5T  357G  81% /hadoop/2
　　/dev/sdd1            1.9T  1.5T  351G  81% /hadoop/3
　　/dev/sde1            1.9T  1.4T  402G  79% /hadoop/4
　　/dev/sdf1            1.9T  1.5T  371G  80% /hadoop/5
　　/dev/sdg1            1.9T  1.5T  375G  80% /hadoop/6
　　/dev/sdh1            1.9T  1.5T  388G  79% /hadoop/7
　　/dev/sdi1            1.9T  1.5T  383G  80% /hadoop/8
　　/dev/sdj1            1.9T  1.5T  394G  79% /hadoop/9
　　/dev/sdl1            1.9T  1.5T  377G  80% /hadoop/11
　　/dev/sdm1            1.9T  1.5T  386G  79% /hadoop/12
　　仔细观察会发现/hadoop/10没有，对应的应该是/dev/sdk1，那这块硬盘到哪去了呢？
　　故障分析：
　　用fdisk查看：
　　#fdisk -l /dev/sdk
　　发现这块盘是GPT table的，这里穿插下分区表的小知识，分区表最常用的是MBR，GPT是比较新的一种，比较少用。
　　因为其它硬盘都是MBR分区表，所以这块硬盘也应该是MBR的。
　　再查看/var/log/messages，发现有一些I/O错误信息：
　　Jul 17 00:50:00 xxxxxxxxxxxxxx kernel:[8385006.016524] Buffer I/O error on device sdk1, logical block 1415594116
　　估计是硬盘出现逻辑坏道了。
　　故障解决：
　　思路是删除/dev/sdk上的所有数据，然后重新分区，格式化。
　　这里不用担心数据丢失，因为Hadoop设置默认会有三份block信息保存在不同的节点上。
　　- 用fdisk删除原有分区表信息，创建一个新的partition：
　　#fdisk /dev/sdk
　　#    d
　　#    n
　　#    p
　　#    w
　　- 用parted工具,把partition1的分区表转化为MBR的：
　　#parted /dev/sdk1
　　#mklabel msdos
　　#quit
　　- 删除保留的百分之五的磁盘空间：
　　#tune2fs -m 1 /dev/sdk1
　　- 用ext4格式化partition:
　　#mkfs.ext4 /dev/sdk1
　　- 查看磁盘信息：
　　#fdisk -l /dev/sdk
　　Disk /dev/sdk: 2000.4 GB, 2000398934016bytes
　　255 heads, 63 sectors/track, 243201cylinders
　　Units = cylinders of 16065 * 512 = 8225280bytes

　　Sector>
　　I/O>
　　Disk>　　Device Boot     Start         End      Blocks  Id  System
　　/dev/sdk1              1      243201  1953512001   83 Linux
　　- 一切正常，查看/etc/fstab：
　　.......
　　LABEL=/hadoop09 /hadoop/9 ext4defaults,noatime,nodiratime,noauto 0 2
　　LABEL=/hadoop10 /hadoop/10 ext4defaults,noatime,nodiratime,noauto 0 2
　　........
　　- 注意"noauto"选项，如果你用"mount -a"的话系统不会自动识别文件系统类型，不会自动挂载目录。
　　所以这里就不能用"mount -a"，而应该手动mount:
　　#mount LABEL=/hadoop10 /hadoop/10 -o defaults,noatime,nodiratime,noauto -t ext4
　　- 再用fdisk查看：
　　#df -h
　　......
　　/dev/sdk1            1.8T  1.9G  1.8T   1% /hadoop/10
　　到这里这个硬盘故障就算彻底解决了。
　　新硬盘到可用所需要的步骤（无需交互，可写成脚本）：
　　1 在/dev/sda1删除partition1:
　　#parted --script -- /dev/sda1 rm 1
　　2 在/dev/sda1上创建msdos类型的分区表:
　　#parted --script /dev/sda1 mklabel msdos
　　3 在/dev/sda1创建partition1：
　　#parted --script -- /dev/sda1 mkpart primary 1 -1
　　4 用ext4文件系统格式化/dev/sda1:
　　#mkfs.ext4 -L $label -N 61050880 -m 1 -O sparse_super /dev/sda1
　　"-N"表示inode的数量，这个数值如果不指定的话，系统会默认把它设的尽量小，如果硬盘中小文件较多的话，有可能会造成inode不够用的情况。HDFS/Hadoop设计的目的是处理大文件的，默认块的大小是64MB，是Linux文件系统默认值（4KB）的16384倍，又考虑到一块硬盘中不可能全部是HDFS 文件，还会有很多日志文件等，所以在设置inode 数量的时候最好根据经验来判断，或者保险点你可以采取以下公式计算得出：
　　Inode数量 = （硬盘大小  /4KB ）* 10
　　"-m 1"表示保留百分之一的硬盘空间，默认保留百分之五，保留的空间可在硬盘被用完的情况下，root用户任然有操作硬盘的机会；
　　"-O sparse_super"表示使用更少的superblock backup copies，来节约硬盘空间。
　　5 在/dev/sda1上禁止e2fsck文件系统在开机时自检：
　　#tune2fs -c 0 -i 0 /dev/sda1
　　"-c 0"表示无论这块硬盘被mount多少次，系统都不会调用e2fsck扫描硬盘。
　　硬盘若长期不自检是不好的，可能会造成数据丢失。对于HDFS而言，默认会保留3份blocks文件，所以就算丢失了一份数据，还有2份数据呢，当blocks的保存数不足3份时，HDFS会重新找一台新的服务器来做备份，从而维持3份数据的目的，所以在HDFS里面数据是相对安全的，硬盘扫描就不那么重要了。
　　最后我分享一个自动化修复硬盘的perl脚本：
　　https://github.com/zhanghaohao/DiskFormat
　　大家如果有疑问或有更好的建议，请留言，谢谢！