警惕SCSI设备冲突:设备 /Device/Scsi/*** 没有在传输等

 外插SCSI卡后处理良好 例：

   刚到客户那里，就被客户的网管员小刘一把拽进了机房。原来，客户是当地一家较有规模的外资连锁超市，一直依赖这套后台系统进行买卖记账和结算。某天早上，业务人员突然说终端结账系统无法使用，小刘发现是服务器端数据库无法访问，于是被迫启用一套备用服务器支撑业务。

    但是备用服务器性能远远不能满足数据频繁读取的负荷需求，在超市业务最繁忙的时候，也是服务器当机重起最频繁的时候，而且新产生的数据都需要财务加班，手工输入到原有的系统中才能完成当日和当月的结算。所有的业务人员都对小刘怨声载道，连一向和蔼可亲的经理这两天一见到小刘脸色就阴沉下来。

    听过了小刘的诉苦，我详细察看了用户的环境。超市使用了2台IA架构的服务器挂接一台SCSI的磁盘阵列做双机系统。主机采用Windows2000 advanced server操作系统，使用一套超市专用的帐务系统，后台是SQLServer2000。

   两台服务器采用了Windows系统自带的MSCS工作在Active－Passive的主从模式下工作，MSCS检测、管理、切换双机的资源组，以保证SQL服务一直能正常运行。由于超市营业时间较长，服务器白天从8:30开业后一直处于运行状态，提供所有数据库等软件服务，对数据进行存取；晚上20:00客户端关闭，停止服务请求；22:00利用SQL内置的管理工具对主机数据进行备份，把服务器上的数据备份到磁盘上。

    当数据库不可访问的故障发生后，小刘先启动了一套备用的服务器作为帐务系统，然后查看主机的事件查看器，发现主机和备机都有ID2、5、14的报错，时间为前一天晚上22:01（开始备份的时间）。网管员重新启动磁盘阵列，数据库又可被重新访问了。本来小刘把业务系统切换回来以为没事了，但是第二天发生同样的故障，重启磁盘阵列后，数据库又可重新被访问。随后连续的几天内都发生同样的故障。

    经过初步判断，我认为问题应该出在数据连接上，于是采用排除法，先后更换服务器到阵列的内外部线缆、SCSI终结器、磁盘阵列控制器以及整套磁盘阵列，但是问题仍然存在，最后改用了外插SCSI卡，状况良好。我总算可以回北京跟Boss交差了。

   测试，问题的根源在哪里？

    问题应该是告一个段落了，但是回北京的路途上我却始终没想明白，为什么把内置SCSI换成外置SCSI就解决了问题呢？现在看来，当时的判断更像是凭着直觉做出来的。

    回到北京后，我在实验室中模拟用户了真实环境，在Disk Array上划分了4个Slice分别映射到了LUN1、LUN2、LUN3、LUN4，并配置好SQL SERVER2000。
    1、 服务切换，大数据（约2GB）在不同的分区之间、通过网上邻居共享文件夹中拷贝。
    2、 通过对各分区运行IOmeter 24小时。
    3、 采用强制手段禁用Private net，Public net使用的是混合通讯，在对外服务的同时也发送心跳信号。
    4、 如果强制将Server1的SCSI线缆拔出，相连服务器基本瘫痪，集群切换服务正常。

---------------------------------------------------------------------------------------------------------
驱动程序在 /Device/Scsi/adpu160m2 上检测到控制器错误。
数据:
0000: 0f 00 10 00 01 00 6a 00   ......j.
0008: 00 00 00 00 0b 00 04 c0   .......À
0010: 50 50 00 c1 00 00 00 00   PP.Á....
0018: 49 00 00 00 00 00 00 00   I.......
0020: 00 00 00 00 00 00 00 00   ........
0028: 00 00 00 00 00 00 00 00   ........
0030: 02 00 00 00 06 00 00 00   ........
事件类型: 警告
事件来源: Disk
事件种类: 无
事件 ID: 51
日期:   ××××-××-××
时间:   ××:××:××
用户:   N/A
计算机: NT2
描述:
传呼期间在设备 /Device/Harddisk3/DR3 上检测到一个错误。
数据:
0000: 04 00 22 00 01 00 72 00   .."...r.
0008: 00 00 00 00 33 00 04 80   ....3..
0010: 2d 01 00 00 00 00 00 00   -.......
0018: 00 00 00 00 00 00 00 00   ........        
---------------------------------------------------------------------------------------------------------

    设备 /Device/Scsi/adpu160m2 没有在传输等待时间内响应。驱动程序在 /Device/Scsi/adpu160m2 上检测到控制器错误。这两个信息表示从windows中发出的请求命令没有到达指定的外接磁盘中，同时由于连接中断，windows系统开始出现没有响应。

   结果分析，警惕SCSI设备冲突
    测试的结果判定服务器和磁盘阵列都没有问题，问题集中在服务器到磁盘阵列的连接线路上。这和我当初在现场的判断完全一致。

    那么连接线路到底出了什么问题呢？

    从SCSI总线原理上分析，SCSI 物理层传送SCSI信号并帮助保护其不受干扰。物理层包含终端器、线缆、增强的适配卡和主板走线、连接器，和其他一些规定如信号导体的阻抗值，连接器的空间，线缆长度等。

    随着各个系统开机或SCSI总线复位, 收到信号的SCSI总线开始更新。同时所有收到信号的SCSI总线始发者开始定位并分别与所有处于SCSI总线上SCSI的目标设备协商。这些协商为执行随后的数据传输建立了精确的机制。总线终结器能告诉SCSI主控制器整条总线在何处终结，并发出一个反射信号给控制器，必须在两个物理终端作一个终结信号才能使用SCSI总线。

    物理总线终结器是一种硬件接头，又分为主动型和被动型两种，主动型使用电压调整器来进行操作，被动型利用总线上的能源信号来操作，被动型比主动型更为精确；自终结电缆可以代替物理总线终结器，也是一种硬件，常用于两个主机连接同一个物理设备。绝大部份 SCSI 设备內置终端器﹐并用一跳线控制ON/OFF 。

    终端器看似很简单﹐但在实际运用过程中问题多出于此。虽然被动式的终端器可以使用在SCSI-I及SCSI-II的规格，但在 SCSI-II以前，由于它的资料传输速率并不是非常的快 (5Mbytes/sec以下) ，因此您可能会经历到在某些情况下，不装Terminator 好像也没有事发生。不过在Fast SCSI 之后 ，随着它的资料传输速率快速增长，在SCSI bus的两端，都必须特别注意Terminator 的设定，而且必须使用主动式Terminator。否则轻者资料传输错误，重者连 SCSI Device 都无法为 Initiator 所辨认出来( 也 就 是 找 不 到 SCSI device)。在我们的实际使用经验中，很多SCSI 硬盘无法顺利安装完成，并不是硬盘本身问题，而是排线品质不好，或是Terminator定位有误差，而产生的讯号不正确所引起的。

    通过检查SCSI ID和总线终结器，我们可以找出大多数冲突现象的解决方法，这是SCSI设备用户必须重视的一点。

    我们看见在SCSI总线上，驱动程序、接口、线缆任何一点都可以导致问题。该客户的服务过程中，已更换过线缆、终结、盘阵主机，板载控制器，除非主板厂家推荐，不宜用在挂接外置磁盘设备的集群环境中，因为它集成为主板各组件的一部分，受其它部件的影响，难免会有所侧重或牺牲，导致在此环境下SCSI总线的不稳定。也因此，当SCSI接口改为外置后就解决了用户的SCSI设备冲突的问题。