从公司离职有几天了，今天回去看同事，想一起吃饭，没成想摊上大事了。说下午hadoop集群的机房停电了，然后集群就启动不了了，几个人从下午4点多折腾到8点多还没搞定，有几台服务器找不到硬盘，还有内网ping不通的。反正是有10来台服务器起不来datanode和tasktracker了。于是在原公司蹭了个饭，花了20分钟解决了一下。


由于这几台服务器挂机，namenode没有达到有效数据块的阀值所以一直处于safemode。


然后逐个解决，同事反馈比较多的情况是硬盘设备在/dev找不到，看了一下，/dev下设备存在，但是没有分区，OPS偷懒，只是把硬盘挂上了，没有fdisk就直接mkfs.ext3了。所以/dev下的设备都是sdb,sdc...而正确的话应该是sdb1,sdc1这样的。所以同事以为硬盘找不到了，就一直没有处理。发现这个问题以后，直接把/dev/sdb挂载到/data1,/data2...。该故障恢复。


还有一类故障是硬盘挂上了，但是datanode无法启动，启动后报Cannot lock storage /data3/... The directory is already locked。看了一下，路径权限没问题，也没有进程占用该路径。怀疑是硬盘出错。mount看了一下，硬盘处于rw状态，应该是没啥问题，但是还是启动不了，于是将该硬盘umount掉，然后重新mount，还是不行，于是做了个测试，直接把该硬盘mkfs.ext3。再重新挂载，然后创建相应的文件夹，赋予权限。再启动datanode，这时候理论上应该是正常并负载均衡数据块，但datanode还是挂了，报了一个DiskChecker volsFailed故障，于是判断该硬盘有物理损坏，格式化都不好使了。直接从hadoop配置文件里摘除，重启datanode正常。


最后一个故障是某一台服务器，内网网卡无法ping通同网段内的服务器。外网可以连接，看了一下ifconfig，IP信息，MAC信息都正确无误，于是怀疑是路由或者网卡问题，但一般来说，网卡不太会出问题，先从路由看起，果不其然被蒙对了。ip route命令看了一下linux的路由表。发现里面的内网地址192.168网段被转发到了一个错误的10.8的××× tunnel上面。将该路由记录从路由表删除后，立刻就通了，相当的爽，20分钟解决全部战斗。


完了以后跟他们开玩笑说，你们以后可以管我叫观世音了。然后说，干脆公司把我返聘回来当顾问得了，或者把hadoop集群的运维业务外包给我得了，出了问题你们都回家，我来加班帮你们搞定。


这个事情我总结了如下几点：


一、大公司不应该为了图便宜去找廉价机房，停电真是受不了，尽管我之前的公司并不在意数据这事，但是发生大规模宕机终归不是什么好事，带来的后续问题太多。抠门也得抠的是地方，该花的钱不能省。


二、大规模分布式集群运维的人才问题将成为瓶颈，鉴于分布式系统的复杂程度，要求运维人员的水平相对比网站运维要高得多。随着技术的发展，用工具把hadoop搭起来不是问题，但是在大规模集群下的维护将成为大问题，要面对各种各样可能发生的奇怪的故障，综合知识要求非常高。不光要精通linux，还要精通网络，还要精通自动化运维方式，还要精通编程，让传统运维去维护hadoop是mission impossible的事。map/reduce开发其实很简单，只要掌握了开发的思想，一天时间包教包会。运维很可能是最终阻碍hadoop落地的障碍，分布式系统太复杂了，水很深，坑很多。需要比较长时间的积累，然后需要知识面很广，思路很活跃才行。像我们这种互联网公司搞hadoop运维都会遇到种种困难，何况是其他人了。


三、没事别回以前的公司。