摘要：

硬盘在服务器中起着至关重要的作用，因为硬盘里面存储的是数据，随着制造业技术的提高，硬盘的类型也在逐渐的改变。对于硬盘的管理是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 id ：job_1431213413583_799324，Failed的Job 在node：example.ebay.com上，对应的日志显示：“Error: java.io.FileNotFoundException…………”，再进一步查看日志，发现是没有找到/path/to/corrupt/file这个block ,我用hadoop fsck命令查看下对应的block所在的节点，发现是在corrupted.node.com上。

考虑到公司安全，以上主机名和文件名都是假设的，大家明白就好。登录出现问题的那台机器，“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 size (logical/physical): 512 bytes/ 512 bytes

I/O size (minimum/optimal): 512 bytes /512 bytes

Disk identifier: 0xea6649b8

?

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