求救！高性能计算集群中共享盘阵使用后频繁无响应的问题！！

好好先生

呵呵，从硬件底层提高I/O性能是一劳永逸的办法。网络方面，我测试的结果是千M的网络足够了，而SCSI卡/HBA卡的I/O的限制是致命的，软件的调优能做的我基本上都做过了，当N多个客户机集中读写时，软件调优的效果不是很明显。下一步计划升级成光纤SAN。

devotion

目前还在大数据量测试中。。。不过有2点疑问还请高人们指点一下:

   通过目前多人诊断,大概得出3个观点:
   
   观点一:认为有可能是攻击引起的,证据:因为发现作业失败后收集的ARP表里MAC地址与IP地址对应关系全部丢失,所以有人

认为是由于攻击引起的,提出测试意见是跳开外网使用内网采用测试(不知道各位认为这个测试是否有足够依据?测试方法上是

否科学,能直接反映问题?)

   观点二:认为可能是交换机和网卡之间硬件兼容性问题引起,证据:因为在前期最小化测试中发现将单节点与IO点直接连接进

行运算,没有任何问题出现(而且是外网连通的情况下).但是看前面好好先生提出CLUSTER最小化测试无法兼顾IO问题,仔细考

虑后也只能把这种想法列为有可能性的一种...提出测试意见是更换交换机进行多节点大数据测试...

  观点三:认为NFS SERVER的IO问题,性能需要提升,提出使用高一级别的IOSERVER来做这个测试(目前仅仅也是猜测中...不

过看大家都趋向于这种猜测...)

    首先谢谢各位对本贴的关注以及热心的回答!
   
   请问以上3种诊断,哪种可能性比较大? 看坛子上大家趋向的方向应该是第3种,那么前2种猜测有没有可能~ 是否需要所有的

测试都做呢?

   顺便补充一下机器环境,网络方面确实已经是千M网络~ 测试用交换机使用的是HP 革新系列交换机~ 原购买的是华维交换机S5600啥的... 盘阵方面U1(也就是IO1节点控制的盘阵)是采用SCSI接口控制~~~而U2,U3(IO0节点控制的盘阵)数据是采用光纤进行读写.请高人结合以上情况 分析可能出现的新问题~~~ 拜谢先~~~

   同时感谢NNTP的建议 目前资料查阅中`~~~

[ 本帖最后由 devotion 于 2007-7-12 14:21 编辑 ]

straw

HPCC最容易碰到的问题之一就是IO问题。
你可以尝试重新规划一下你的集群应用和集群内部的网络。
应该留有足够的带宽给NFS，充分利用网络资源，把NFS和高性能计算分别通过不同的网络走。
在可能的情况下有下面几种建议：
1,采用更高级的网络架构，增加nfs服务器的带宽（使用更加可靠的网卡，有时候网卡的瑕疵在这种压力下很可能会出线问题）
2,修改你的应用，减少计算对于网络的依赖
3,如果不是大量小文件的化，可以考虑采用其他文件系统，否则只有修改应用才是比较合理的选择

devotion

网络测试的结果另人失望。尝试更换了HP的“革新系列”交换机，测试网络，问题依旧：210

数据网络依然出现瘫痪状况，至此交换机硬件兼容性问题可以排除了。

  而且在测试中将10段外网断开进行210段内网的单独测试。问题依旧，再次排除了网络中的

ARP攻击问题。

  而至于NFS问题是一个反复的性能调优问题。需要花费很长时间去做。通过一系列的测试：

更改缓存，更换NFS协议等等。。。结果并没有明显改善。（不能说没有一点改善，至少瘫痪

时间和频率都有所缓解，但只是相对而言，实际上仍然频繁，不过可以看出当初的NFS

SERVER在性能优化上确实存在很多问题）。

    终于在反复的调试以及摸索中终于可以确定磁盘I/O问题可以排除了。

   有些同事非常奇怪，因为大多数人都认为是磁盘或者硬件IO问题引起的。我们先返回到

问题的开头，问题我就不在罗嗦一遍了，可以看CASE1的第一节。大致可以归纳为计算节点

通过网络对共享盘阵进行大数据量读写的时候，会造成IO节点假死的情况。按照这个情况，依

次通过各个节点，单独或者并行的发送大数据量读写操作，以验证IO问题。

   多次实验后发现，使用数据网络（210网段的网络）进行传输的时候，才会出现这种情况，

而单独断开数据网络，使用外网（10网段的网络）进行数据计算时，却没有这种情况。对此，

基本定性为硬件问题。

   翻阅大量资料后终于发现参考资料（来源于HP英文支持文档库）：

  

CUSTOMER ADVISORY
Document ID: EU050629_CW01
Version: 1
Advisory: Primary Port of Integrated NC7782 Gigabit Server Adapters with NFS protocol with Certain Firmware Versions Stops Transmitting under Linux, Resulting in Lost Network Connectivity


NOTICE: The information in this document, including products and software versions, is current as of the Release Date. This document is subject to change without notice.


Release Date: 2005-10-06


--------------------------------------------------------------------------------


description



An Integrated NC7782 Gigabit Dual-Port PCI-X Server Adapter with a firmware version earlier than Version 1.6 (and containing an IPMI code earlier than Version 2.36) will stop transmitting on a ProLiant servers running the NFS protocol is in use on this device.  Total loss of network connectivity occurs, even though the link is maintained.  When using the ifconfig command to view the status, the receive packets will continue to increment but the transmit packets will not increment.  Performing a service network restart or ifdown/ifup will restore connectivity temporarily.      

This will only occur on the first port of the NC7782 Gigabit Dual-Port PCI-X Server Adapter and does not occur on any other integrated NIC port.  The Intelligent Platform Management Interface (IPMI) is enabled by default on the first port of the Integrated NC7782 Gigabit Dual Port PCI-X Server Adapter.

scope



Any ProLiant server with an Integrated NC7782 Gigabit Dual-Port PCI-X Server Adapter with a firmware version earlier than Version 1.6 (that contains IPMI code earlier than Version 2.36).

Note:  The following servers have the Integrated NC7782 Gigabit Dual Port PCI-X Server Adapter:

ProLiant BL25p server
ProLiant DL320 G3 server
ProLiant DL360 G4 server
ProLiant DL360 G4p server
ProLiant DL380 G4 server
ProLiant DL380 G4p server
ProLiant DL385 server
ProLiant DL580 G3 server
ProLiant DL585 server
ProLiant ML350 G4 server
ProLiant ML570 G3 server

在DESCRIPTION中描述的症状基本和我们现在的问题所吻合。在电询了

HP之后同时也确定了芯片的型号，和相关硬件信息。按照HP所提出的解

决问题的办法有以下三种：

1.Update the firmware using the HP ProLiant NC10XX/67XX/77XX/150X/320X Gigabit Server Adapter Firmware Upgrade Utility for MS-DOS that contains IPMI code Version 2.36.

（大意指升级网卡的firmware）在这里给大家一个FIRMWARE的最新版本的连接（20070720）：

http://h18023.www1.hp.com/suppor ... us/locate/8455.html

2.Move the NFS protocol to the second port of the Integrated NC7782 Gigabit Dual-Port PCI-X Server Adapter.

（将NFS SERVER控制网络移至第2网口，换句话说就是将数据网络和管理[冗余网络]进行对

调。这句话仔细体会后才明白其意思，结合前面DESCRIPTION中所描述的情况得出：数据网

络不要放在IPMI服务所在的网络即可。换句话说，IPMI才是问题真正的罪魁祸首，不~某种

意义上硬件供货商和HP所谓2流的技术支持才是导致这次问题的所在。绝对的出离愤怒，花

费近7周解决的问题，竟然是HP自带的内核服务引起的。而且这个问题早在05年10月 也就是

我们当初购买机器的时候，已经提出解决方案，而作为硬件商，多次因为此问题协调无效后

竟然表示无能为力。愤怒，太愤怒了。）

     3.
Disable IPMI on NIC 1 using the Q57 DOS Diagnostics utility (Q57.EXE) packaged in the HP ProLiant Network Server Adapters and Upgrade Modules Software.  The latest version of the HP ProLiant Network Server Adapters and Upgrade Modules Software is located at the following URL:

http://h18000.www1.hp.com/suppor ... us/locate/6745.html
After the download, extract the files.  The Q57 diagnostic utility is located in the \apps\diags\q57 folder.


Run the following command to disable IPMI on the first port of integrated NIC:

q57diag.exe -c 0 -asf 0


Verify that IPMI has been disabled by running the following command :

q57diag -findref

This will display information similar to the following:

An "A" under the configuration header indications IPMI is enabled (on).  The "A" will not be displayed if IPMI has been disabled as shown below:  
IPMI On :

C Brd:Rv    Bus   PCI Spd Base Irq EEP     MAC          Fmw     Configuration
- ------- ------- --- --- ---- -- ---- ------------ ----------- --------------
0 7782SB0 03:01:0 X64 133 FDEF  5  64k 000F20F63D2F 5704-v3.26  WA,auto  
1 7782PB0 03:01:1 X64 133 FDEE  5  64k 000F20F63D2E 5704-v3.26  W,auto  


IPMI Off :

C Brd:Rv    Bus   PCI Spd Base Irq EEP     MAC          Fmw     Configuration
- ------- ------- --- --- ---- -- ---- ------------ ----------- --------------
0 7782SB0 03:01:0 X64 133 FDEF  5  64k 000F20F63D2F 5704-v3.26  W,auto  
1 7782PB0 03:01:1 X64 133 FDEE  5  64k 000F20F63D2E 5704-v3.26  W,auto

（大意是关闭IPMI服务的详细过程，请原谅到这里已经没有任何心情再去翻译，就关

闭IPMI服务这一步，大家有不清楚的地方可以跟贴，我来回答）


至此，这场耗时近3个月的问题，终于水落石出。但遗憾的是，问题竟然是这样的结

果，未免让人有些失落...尽管在这个CASE中确实学到了很多东西。