关于 十一月, 2014 的文章

Hadoop运维笔记 之 Snappy创建libhadoop.so导致datanode报错

为了解决上一篇文章中提到的Bug,我们将线上的CDH5升级到了目前最新的CDH5.2.0,但升级之后,有一部分服务器的datanode不能正常启动,报错如下:

2014-11-20 19:54:52,071 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Unexpected exception in block pool Block pool <registering> (Datanode Uuid unassigned) service to idc1-server1/10.100.1.100:8020
com.google.common.util.concurrent.ExecutionError: java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO.link0(Ljava/lang/String;Ljava/lang/String;)V
	at com.google.common.util.concurrent.Futures.wrapAndThrowExceptionOrError(Futures.java:1126)
	at com.google.common.util.concurrent.Futures.get(Futures.java:1048)
	at org.apache.hadoop.hdfs.server.datanode.DataStorage.linkBlocks(DataStorage.java:870)
	at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.linkAllBlocks (BlockPoolSliceStorage.java:570)
	at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.doUpgrade (BlockPoolSliceStorage.java:379)
	at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.doTransition (BlockPoolSliceStorage.java:313)
	at org.apache.hadoop.hdfs.server.datanode.BlockPoolSliceStorage.recoverTransitionRead (BlockPoolSliceStorage.java:187)
	at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead (DataStorage.java:309)
	at org.apache.hadoop.hdfs.server.datanode.DataNode.initStorage(DataNode.java:1109)
	at org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1080)
	at org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo (BPOfferService.java:320)
	at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake (BPServiceActor.java:220)
	at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:824)
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO.link0 (Ljava/lang/String;Ljava/lang/String;)V
	at org.apache.hadoop.io.nativeio.NativeIO.link0(Native Method)
	at org.apache.hadoop.io.nativeio.NativeIO.link(NativeIO.java:838)
	at org.apache.hadoop.hdfs.server.datanode.DataStorage$2.call(DataStorage.java:862)
	at org.apache.hadoop.hdfs.server.datanode.DataStorage$2.call(DataStorage.java:855)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	... 1 more
2014-11-20 19:54:52,073 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Ending block pool service for: Block pool <registering> (Datanode Uuid unassigned) service to idc1-server1/10.100.1.100:8020

但搜遍了Google也未能找到匹配的信息,唯一沾点边的都是一些在Windows平台上因为缺少lib导致的问题。
而在我们的环境中,只有一部分的服务器有以上问题,对比了所有Hadoop相关的软件包之后都没法发现有什么不同,这给我们分析问题带来了很大的干扰。

最后,我们尝试通过strace来跟踪datanode的进程。
yum install strace
strace -f -F -o /tmp/strace.output.txt /etc/init.d/hadoop-hdfs-datanode start
lsof | grep libhadoop.so

java 18527 hdfs mem REG 253,0 122832 270200 /usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so

发现它读取了一个lib文件:/usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so,而其它正常的服务器的datanode进程则是读取的/usr/lib/hadoop/lib/native/libhadoop.so。
经过验证发现/usr/java/jdk1.7.0_45/jre/lib/amd64/libhadoop.so是在安装Snappy软件包时创建的,在移走了它之后,datanode终于正常启动了。

看来,虽然datanode在启动时指定了 -Djava.library.path=/usr/lib/hadoop/lib/native,但jre中的lib被载入的优先级还是要高一些。

,

No Comments

Hadoop运维笔记 之 Namenode异常停止后无法正常启动

背景:
公司在线上使用了CDH5 HA模式,有两个Namenode节点,结果其中的Standby节点因为一些关于edits文件的报错异常停止了,并且在启动的过程中一直报告找不到各种文件。

刚开始怀疑问题可能只发生在Standby本身,因此尝试了bootstrapStandby来重新初始化Standby节点,但问题依旧。
而后来因为我尝试重启ZKFC(Zookeeper Failover)服务器,导致了Active节点进行自动切换,在切换失败后打算切换回去时,也无法启动服务了,报错跟Standby节点一模一样,于是整个Hadoop集群就挂了。

问题严重,在搜遍了整个Google都找不到任何有用的信息之后,只能求助于老大。最后,老大想到一个思路,就是将fsimage(元数据)文件与edits(编辑日志)文件都反编译成文本,查看里面具体有什么内容,为什么加载edits文件时会报错。

结果,这个思路给我们带来了曙光,并最终修复了整个集群。

环境介绍:
idc2-server1: namenode, journalnode, zkfc
idc2-server2: namenode, journalnode, zkfc
idc2-server3: journalnode, resourcemanager

具体过程:
首先,是Standby Namenode上出现以下错误,然后自动异常关闭了进程:

2014-11-11 02:12:54,057 FATAL org.apache.hadoop.hdfs.server.namenode.ha.EditLogTailer: Unknown error encountered while tailing edits. Shutting down standby NN.
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015
       at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
       at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...

其中提到了"Unknown error encountered while tailing edits. Shutting down standby NN."

于是,我们尝试启动Standby Namenode服务,结果报告以下错误:

2014-11-12 04:26:28,860 INFO org.apache.hadoop.hdfs.server.namenode.EditLogInputStream: Fast-forwarding stream 'http://idc2-server10.heylinux.com:8480/getJournal?jid=idc2&segmentTxId=240823073&storageInfo=-55%3A1838233660%3A0%3ACID-d77ea84b-1b24-4bc2-ad27-7d2384d222d6' to transaction ID 240741256
2014-11-12 04:26:28,874 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp [length=0, inodeId=0, path=/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015, replication=3, mtime=1415671845582, atime=1415670522749, blockSize=134217728, blocks=[], permissions=oozie:hdfs:rw-r--r--, aclEntries=null, clientName=, clientMachine=, opCode=OP_CLOSE, txid=240823292]
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...
2014-11-12 04:26:32,641 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception loading fsimage
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)

说找不到"/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015"这个文件。
而事实上,这个文件是临时文件,不重要并且已经被删除了。
但在上面,却报告"ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp",可以看出是在加载edits文件,执行OP_CLOSE操作时提示找不到文件。

刚开始我们怀疑可能只是Standby上的fsimage文件或edits文件有问题,于是我们在Standby上执行了bootstrapStandby,改过程会自动从Active Namenode上获取最新的fsimage文件,并从Journalnode日志服务器上下载并执行新的edits文件。

sudo -u hdfs hadoop namenode -bootstrapStandby

但是,在初始化之后,加载edits时仍然遇到上面相同的报错。

而接下来,由于我尝试将ZKFC(Zookeeper Failover)服务重启,导致了Active Namenode自动切换到Standby,但由于Standby无法take over,所以Active Namenode切换回去的时候,也无法正常重启了,错误跟Standby启动时一样。

这样一来,整个Hadoop集群就挂了,在搜遍了整个Google都找不到任何有用的信息之后,我打电话给了老大,老大也通过上面的错误Google不到任何一条有用的信息。
于是老大尝试在edits文件中grep上面的路径,找到了一些相关的edits文件:

# cd /data1/dfs/nn/
# cp -rpa current current.backup.orig
# cd /data2/dfs/nn/
# cp -rpa current current.backup.orig
# cd /data1/dfs/nn/current
# grep attempt_1415171013961_37060_m_000015_0 *
Binary file edits_0000000000240687057-0000000000240698453 matches
Binary file edits_0000000000240823073-0000000000240838096 matches
Binary file edits_inprogress_0000000000244853266 matches

于是,我们思考能否从这些edits文件或fsimage文件中找到一些线索。
而下面的两篇文章中,提到了Hadoop自带的针对fsimage和edits文件的反编译工具:
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html

其中,关于edits文件的一些描述给我们带来了极大的希望:

In case there is some problem with hadoop cluster and the edits file is corrupted it is possible to save at least part of the edits file that is correct. This can be done by converting the binary edits to XML, edit it manually and then convert it back to binary.

通过以上描述,我们了解到edits文件可能会corrupted,而反编译之后手动修改,在编译回二进制格式进行替换,可以作为一种解决办法。
于是我们将上面找到的两个关联edits文件,将其复制出来并进行了反编译:

# mkdir /tmp2/
# cd /data1/dfs/nn
# cp edits_0000000000240687057-0000000000240698453 /tmp2/
# cp edits_0000000000240823073-0000000000240838096 /tmp2/
# cd /tmp2
# hdfs oev -i edits_0000000000240687057-0000000000240698453 -o edits_0000000000240687057-0000000000240698453.xml
# hdfs oev -i edits_0000000000240823073-0000000000240838096 -o edits_0000000000240823073-0000000000240838096.xml

反编译之后,生成了两个XML文件,我们在XML文件中搜索"/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015",找到了OP_CLOSE与OP_DELETE相关记录:

  <RECORD>
    <OPCODE>OP_DELETE</OPCODE>
    <DATA>
      <TXID>240818498</TXID>
      <LENGTH>0</LENGTH>
      <PATH>/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015</PATH>
      <TIMESTAMP>1415671972595</TIMESTAMP>
      <RPC_CLIENTID>4a38861d-3bee-40e6-abb6-d2b58f313781</RPC_CLIENTID>
      <RPC_CALLID>676</RPC_CALLID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_CLOSE</OPCODE>
    <DATA>
      <TXID>240823292</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>0</INODEID>
      <PATH>/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1415671845582</MTIME>
      <ATIME>1415670522749</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME></CLIENT_NAME>
      <CLIENT_MACHINE></CLIENT_MACHINE>
      <PERMISSION_STATUS>
        <USERNAME>oozie</USERNAME>
        <GROUPNAME>hdfs</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

可以看到,对于"/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000015_0/part-00015",OP_DELETE发生在了OP_CLOSE之前,因此执行OP_CLOSE时会提示"File does not exist"。

于是,我们尝试将OP_CLOSE这部分代码,替换成其它的内容,比如无关痛痒的修改一个现有文件的权限,并保留TXID 240823292以确保edits文件的完整性。

  <RECORD>
    <OPCODE>OP_SET_PERMISSIONS</OPCODE>
    <DATA>
      <TXID>240823292</TXID>
      <SRC>/user/oozie-heylinux/.staging/job_1415171013961_37194</SRC>
      <MODE>504</MODE>
    </DATA>
  </RECORD>

修改完成之后,再将XML文件反编译回binary格式。

# cd /tmp2/
# cp edits_0000000000240823073-0000000000240838096.xml edits_0000000000240823073-0000000000240838096.xml.orig
# vim edits_0000000000240823073-0000000000240838096.xml
# hdfs oev -i edits_0000000000240823073-0000000000240838096.xml -o edits_0000000000240823073-0000000000240838096 -p binary 

然后将binary文件同步到journalnode日志服务器中:

# cd /var/hadoop/data/dfs/jn/idc2prod/
# cp -rpa current current.backup.orig
# cd /tmp2/
# cp edits_0000000000240823073-0000000000240838096 /data1/dfs/nn/current/
# cp edits_0000000000240823073-0000000000240838096 /data2/dfs/nn/current/
# cp edits_0000000000240823073-0000000000240838096 /var/hadoop/data/dfs/jn/idc2prod/current/
# scp edits_0000000000240823073-0000000000240838096 root@idc2-server2:/var/hadoop/data/dfs/jn/idc2prod/current/
# scp edits_0000000000240823073-0000000000240838096 root@idc2-server3:/var/hadoop/data/dfs/jn/idc2prod/current/

然后启动namenode服务,可以发现,之间的错误已经不存在了,取而代之的已经变成了其它文件。

2014-11-12 08:57:13,053 INFO org.apache.hadoop.hdfs.server.namenode.EditLogInputStream: Fast-forwarding stream 'http://idc2-server1.heylinux.com:8480/getJournal?jid=idc2prod&segmentTxId=240823073&storageInfo=-55%3A1838233660%3A0%3ACID-d77ea84b-1b24-4bc2-ad27-7d2384d222d6' to transaction ID 240299210
2014-11-12 08:57:13,063 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation CloseOp [length=0, inodeId=0, path=/user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018, replication=3, mtime=1415671845675, atime=1415670519537, blockSize=134217728, blocks=[], permissions=oozie:hdfs:rw-r--r--, aclEntries=null, clientName=, clientMachine=, opCode=OP_CLOSE, txid=240823337]
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:55)
...

2014-11-12 08:57:16,847 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception loading fsimage
java.io.FileNotFoundException: File does not exist: /user/dong/data/dpp/classification/gender/vw-output-train/2014-10-30-research-with-confict-fix-bug-rerun/_temporary/1/_temporary/attempt_1415171013961_37060_m_000018_0/part-00018
        at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:65)
...

那么,接下来,就是重复以上动作,其中有时候能找到一部分规律,可以批量将同一个目录下反复报错的文件的OP_CLOSE都替换掉。但更多的时候则是随机的文件,需要一次次修改XML文件,然后编译成binary,再启动namenode,进行针对性的修改,一直反复的进行下去,直到Namenode能够成功启动为止。

我们在具体的操作过程中,还遇到过关于OP_ADD_BLOCK的错误,造成问题的原因是由于最后一个edits文件在反编译回binary文件时出现一些关于OP_UPDATE_BLOCK的错误。
我将报错的部分通过以上方式进行了替换,才成功的将edits文件反编译回binary文件。
具体的解决办法,就是根据"Encountered exception on operation AddBlockOp"定位到OP_ADD_BLOCK相关配置并替换即可。

2014-11-12 18:07:39,070 ERROR org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader: Encountered exception on operation AddBlockOp [path=/user/dong/data/dpp/classification/gender/vw-input/2014-10-30-research-with-no-confict-fix-bug-rerun/all_labelled/_temporary/1/_temporary/attempt_1415171013961_42350_m_001474_0/part-m-01474, penultimateBlock=NULL, lastBlock=blk_1109647729_35920089, RpcClientId=, RpcCallId=-2]
java.lang.IllegalStateException

最后,在Namenode启动成功后,会报告很多Block丢失,解决办法是通过fsck删除这些错误的Block。

# hadoop fsck / -files -blocks -locations | tee -a fsck.out

然后在fsck.out中获取所有Block的信息,执行"hadoop fsck / -move"加Block路径进行删除。

最后,退出safemode,生活再次变得美好起来。

# hadoop dfsadmin -safemode leave

PS: 在后来,上面的问题又再次出现了,通过分析我们发现是由于Hadoop的一个Bug导致的,从2.10-beta就开始存在了:
https://issues.apache.org/jira/browse/HDFS-6527
https://issues.apache.org/jira/browse/HDFS-6647
想要彻底避免这类问题的再次发生,必须将Hadoop升级到2.5以上版本,而对应的CDH版本则是5.2.0。

,

1 Comment

Hadoop运维笔记 之 Balancer难以在快速增长的集群上平衡大量的数据

背景:
公司在线上使用了CDH5集群,一开始由于疏忽,忘记了在计划任务中定期执行Balancer来平衡各节点的数据。
后来,在引入大量的Job之后,数据增长非常迅猛,有很多节点开始出现利用率超过99.9%的情况,部分Job甚至开始Failed。

于是我们便执行Balancer来清理数据,结果发现有26T的数据需要平衡,而Balancer每次只移动50G的数据,并且耗时30分钟,而集群每个小时新写入的数据会导致又有40-60G的数据需要平衡。这样一来,Balancer就根本无法胜任了。

14/10/14 20:31:11 INFO balancer.Balancer: Need to move 26.49 TB to make the cluster balanced.
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.10:50010 to 10.100.1.60:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.20:50010 to 10.100.1.70:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.30:50010 to 10.100.1.80:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.40:50010 to 10.100.1.90:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.50:50010 to 10.100.1.100:50010
14/10/14 20:31:11 INFO balancer.Balancer: Will move 50 GB in this iteration
...

解决办法:
1. 增加Balancer可操作的带宽
我们思考,是否是因为Balancer的默认带宽太小,所以效率低下,于是我们尝试将Balancer的带宽扩容到了500M/s:

hadoop dfsadmin -setBalancerBandwidth 524288000

但问题并没有得到太大的改善。

2. 强行对节点进行Decommission
我们发现,当对一些节点进行Decommission操作时,上面的数据虽然有10-30T甚至更多,但总能在1天内全部Copy到其它的节点上,这里面由于默认集群副本数为3的原因,应该只有1/3的数据被复制了,但数据是完整的,并且被复制出去的数据也是平均分配到各个节点上的。那么我们何不使用它来作为一个类似Balancer的功能来解决一些磁盘用量超过99.9%的节点呢?
事实证明,这个方法非常可行,我们针对线上8个节点进行了Decommission操作(注意要尽量一台一台进行),在完成下线之后再立刻格式化数据磁盘,并重新添加回集群,新的数据也会非常快的平衡过来。比较完美的解决了之前头疼的问题,并且只花费了不到4天的时间。

3. Hadoop对LVM磁盘卷的支持问题
在解决Balancer的问题时,我们还发现,Hadoop对LVM磁盘卷的支持不是很好,表现在如果在一块磁盘上创建了逻辑卷/根分区等,再创建了逻辑卷/data1分区,Hadoop会一直将/data1写到100%,然后导致一些Job提示没有空间写入。我们猜想Hadoop应该是物理卷为单位来控制用量的。因此,我们不得不将这些包含了逻辑卷数据磁盘的主机重新安装,并分配单独的物理卷,如/dev/sda3作为/data1挂载,便再也没有以上问题。

,

No Comments

启用服务器的远程IPMI Console功能

参考资料:
http://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool

背景介绍:
IPMI是智能型平台管理接口(Intelligent Platform Management Interface)的缩写,是管理基于 Intel结构的企业系统中所使用的外围设备采用的一种工业标准,该标准由Intel,HP,DELL和SuperMicro等公司制定。用户可以利用IPMI监视服务器的物理健康特征,如温度、电压、风扇工作状态、电源状态等。

在我们生产环境的物理服务器中,绝大部分都采用了DELL与SuperMicro,都选购了 “DRAC 远程控制卡” 来支持IPMI,并分配了特定的网络段IP给每台服务器。这样,平时我们远程修改BIOS启动项,重启服务器,连接本地终端等操作就都可以通过IPMI来实现了。

以下,是我们生产环境中的实际应用场景:

环境介绍:
机器类型:DELL/SuperMicro
IPMI支持:已安装 “DRAC 远程控制卡” 并已通过BIOS配置好IP地址
机器列表:
管理机 idc1-admin1
服务器 idc1-server1, DRAC远程地址 idc1-server1-remote
OS: CentOS 6.6 x86_64 Minimal

具体配置:
1. 配置管理主机idc1-admin1
[root@idc1-admin1 ~]# yum install OpenIPMI ipmitool
[root@idc1-admin1 ~]# /etc/init.d/ipmi start
[root@idc1-admin1 ~]# lsmod | grep ipmi_devintf || insmod /lib/modules/`uname -r`/kernel/drivers/char/ipmi/ipmi_devintf.ko
[root@idc1-admin1 ~]# /etc/init.d/ipmi restart

2. IPMI功能 之 远程修改BIOS启动项为网络启动
[root@idc1-admin1 ~]# ipmitool -I lanplus -H idc1-server1-remote -U ADMIN -P ADMIN chassis bootdev pxe

Set Boot Device to pxe

3. IPMI功能 之 远程重启服务器
[root@idc1-admin1 ~]# ipmitool -I lanplus -H idc1-server1-remote -U ADMIN -P ADMIN power reset

Chassis Power Control: Reset

[root@idc1-admin1 ~]# ipmitool -I lanplus -H idc1-server1-remote -U ADMIN -P ADMIN power status

Chassis Power is on

4. 通过Cobbler网络自动好安装服务器idc1-server1

5. 登陆刚刚安装完成的服务器idc1-server1,启用IPMI Console支持
5.1. 安装所需软件
[root@idc1-server1 ~]# yum install OpenIPMI ipmitool
[root@idc1-server1 ~]# /etc/init.d/ipmi start
[root@idc1-server1 ~]# lsmod | grep ipmi_devintf || insmod /lib/modules/`uname -r`/kernel/drivers/char/ipmi/ipmi_devintf.ko
[root@idc1-server1 ~]# /etc/init.d/ipmi restart

5.2 配置grub启动参数
[root@idc1-server1 ~]# vi /boot/grub/grub.conf

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/mylvm-root
#          initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=1 --speed=115200
terminal --timeout=2 console
title CentOS (2.6.32-504.el6.x86_64)
       root (hd0,0)
       kernel /vmlinuz-2.6.32-504.el6.x86_64 ro root=/dev/mapper/mylvm-root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 rd_LVM_LV=mylvm/root  KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet rd_NO_DM rd_LVM_LV=mylvm/swap rhgb quiet console=tty1 console=ttyS1,115200
       initrd /initramfs-2.6.32-504.el6.x86_64.img

注:在上面的配置文件中,新增了以下配置用于支持IPMI Console:
第14行:serial --unit=1 --speed=115200
第15行:terminal --timeout=2 console
第18行末尾:console=tty1 console=ttyS1,115200

5.3. 重启服务器使参数生效
[root@idc1-server1 ~]# reboot

6. 待服务器启动成功后,在管理机上调用IPMI console
[root@idc1-admin1 ~]# ipmitool -I lanplus -H idc1-server1-remote -U ADMIN -P ADMIN sol activate

Use ~~. to exit from console
[SOL Session operational.  Use ~? for help]
CentOS release 6.6 (Final)
Kernel 2.6.32-504.el6.x86_64 on an x86_64

idc1-server1 login:

在这个界面上,就可以登陆并操作本地终端了,我们通常在无法通过SSH登陆服务器时使用。

7. 厂商通常还提供了一套Web界面来支持IPMI的相关操作,登陆URL为http://idc1-server1-remote。
如下图所示的SuperMicro:
ipmi_web_01
ipmi_web_02

8. 通过本机的ipmitool命令还可以对IPMI模块的IP等进行一些配置,如下:
8.1 修改IPMI模块IP:
[root@idc1-admin1 ~]# ipmitool lan set 1 ipsrc static
[root@idc1-admin1 ~]# ipmitool lan set 1 ipaddr 10.100.1.123

Setting LAN IP Address to 10.100.1.123

[root@idc1-admin1 ~]# ipmitool lan set 1 netmask 255.255.255.0

Setting LAN Subnet Mask to 255.255.255.0

[root@idc1-admin1 ~]# ipmitool lan set 1 defgw ipaddr 10.100.1.1

Setting LAN Default Gateway IP to 10.100.1.1

[root@idc1-admin1 ~]# ipmitool lan set 1 defgw macaddr 00:0e:0c:aa:8e:13

Setting LAN Default Gateway MAC to 00:0e:0c:aa:8e:13

[root@idc1-admin1 ~]# ipmitool lan set 1 arp respond on

Enabling BMC-generated ARP responses

[root@idc1-admin1 ~]# ipmitool lan set 1 auth ADMIN MD5
[root@idc1-admin1 ~]# ipmitool lan set 1 access on

8.2 显示IPMI模块网络配置:
[root@idc1-admin1 ~]# ipmitool lan print 1

Set in Progress         : Set Complete
Auth Type Support       : NONE MD5 PASSWORD 
Auth Type Enable        : Callback : 
                        : User     : 
                        : Operator : 
                        : Admin    : MD5 
                        : OEM      : 
IP Address Source       : Static Address
IP Address              : 10.100.1.123
Subnet Mask             : 255.255.255.0
MAC Address             : 00:0e:0c:ea:92:a2
SNMP Community String   : 
IP Header               : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl   : 2.0 seconds
Default Gateway IP      : 10.100.1.1
Default Gateway MAC     : 00:0e:0c:aa:8e:13
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
RMCP+ Cipher Suites     : None
Cipher Suite Priv Max   : XXXXXXXXXXXXXXX
                        :     X=Cipher Suite Unused
                        :     c=CALLBACK
                        :     u=USER
                        :     o=OPERATOR
                        :     a=ADMIN
                        :     O=OEM

8.3 配置IPMI模块管理用户:
[root@idc1-admin1 ~]# ipmitool user set name 2 ADMIN
[root@idc1-admin1 ~]# ipmitool user set password 2

Password for user 2: 
Password for user 2: 

[root@idc1-admin1 ~]# ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4
[root@idc1-admin1 ~]# ipmitool user enable 2

8.4 重启IPMI模块:
[root@idc1-admin1 ~]# ipmitool mc reset cold

9. IPMI还提供了丰富的功能可用于对硬件进行监控,如风扇转速,硬盘等,以后我会对这方面的内容再进行一些总结。

No Comments