VERITAS容灾系统中奇怪问题。

kindy

环境描述：
    B2000  两台，每台接一个SCSI2的盘阵。操作系统为solaris 8   patch打至年初的部分，按照系统要求，不能再打新的PATCH了。
    使用veritas volume manage , vcs , vvr ,gcm等远程双机软件，应用系统安装的是SYBASE数据库。

问题描述：
    从七月份开始，这两台机器在VCS的日志中总在每过一两天都会报对资源监控TIMEOUT的信息。
    而后，客户反应，系统有时候在屏保之后无法唤醒，系统整个停留在黑屏状态，延续十分钟左右，而且从别的系统能够PING通系统，但是无法TELNET，挂在TELNET部分，十分钟左右后，系统恢复正常，此时检查系统日志，MESSAGE中什么信息都不报，只有在VCS中发现有某些（不定）资源的监控TIMEOUT的警告信息。

各位兄弟，有谁见过这中情况，能否提示一下，谢谢。环境描述：
    B2000  两台，每台接一个SCSI2的盘阵。操作系统为solaris 8   patch打至年初的部分，按照系统要求，不能再打新的PATCH了。
    使用veritas volume manage , vcs , vvr ,gcm等远程双机软件，应用系统安装的是SYBASE数据库。

问题描述：
    从七月份开始，这两台机器在VCS的日志中总在每过一两天都会报对资源监控TIMEOUT的信息。
    而后，客户反应，系统有时候在屏保之后无法唤醒，系统整个停留在黑屏状态，延续十分钟左右，而且从别的系统能够PING通系统，但是无法TELNET，挂在TELNET部分，十分钟左右后，系统恢复正常，此时检查系统日志，MESSAGE中什么信息都不报，只有在VCS中发现有某些（不定）资源的监控TIMEOUT的警告信息。

各位兄弟，有谁见过这中情况，能否提示一下，谢谢。

netbackup

能否贴出你的日志（vcs）？另外你的OS中是否有有关SCSI的错误信息？是两台服务器都无法登录还是只有一台无法登录？不能登陆的是你的主服务器吗？

kindy

不好意思，白天在机房，不能上网，晚上才可以。

如下是VCS  APPLICATION监控日志：
TAG_B 2004/11/24 09:37:30 Thread(19) VCS:13027:Resource(EMSApp) - monitor procedure did not complete within the expected time.
TAG_B 2004/11/24 09:37:30 Thread(31) VCS:13027:Resource(SSApp) - monitor procedure did not complete within the expected time.
TAG_B 2004/11/24 09:37:30 Thread(29) VCS:13027:Resource(MDPApp) - monitor procedure did not complete within the expected time.
TAG_B 2004/11/24 09:37:30 Thread(2 VCS:13027:Resource(TopoApp) - monitor procedure did not complete within the expected time.
然后对网卡NIC_A资源也是类似于上述的日志告警。

OS中有些SCSI的写入错误，但是时间一般都是发生在重启的过程中，在系统发生错误的是后并没有SCSI的写入错误，这部分SUN工程师正在确认问题。

是两台，但不是同时，两台发生的时候并没有任何逻辑关系，而且都是无规律的。

两台都有这种情况发生。
并不在于是否为主或者备。

顺： 时间一般都是无规律的一至三天发生一次，上述日志只是那个时间的，其他时候的和其类似，不过很奇怪的是最近四天好像没发生，我正在现场观察，郁闷呀。

mmmmn

可怜的孩子。。。
都是TAG_B的错误
如果偶没记错，应该是代表VCS本身的BUG。。。。
你要是没打过patch就打patch吧，没看见你写打VCS的patch了

kindy

大哥，的确是没有打VCS的PATCH。 我们用的是VCS3.5,没有打过任何PATCH。 但是和这个相同的配置在很多别的地方也用过，好像未发生过这种情况。 而且现场情况VCS的PATCH的情况也和V的北京支持中心介绍过，但他们没提出和VCS的BUG有关？

顺： TAG_B是什么东东。 谢谢老大指点。

netbackup

从现象看你的SCSI似乎还是有一些问题，也许你需要SUN确认一下你的SCSI是否存在问题。我曾经遇到过SCSI背板的问题造成系统出现你现在类似的现象。
如果可能，你最好还是安装VCS的patch和Storage Foundation的patch，这样便于你查找问题；
BTW，同样的环境别的地方没问题，不代表在你现在的环境中就没问题；人有时候很容易被这种现象所迷惑。希望你能早日解决这个问题。Good luck for you!

kindy

对于POWER.CONF文件修改的时候出现过下边一些问题。

我们对显示器屏保想过将电源管理屏蔽掉，但是当我们修改完/etc/power.conf文件，然后使用/etc/rc2.d/S88power 重新启动的时候，出现如下错误在/var/adm/message文件：
Nov 29 16:33:22 Primary syslog: [ID 198345 daemon.notice] /usr/sbin/pmconfig：/etc/power.conf 第(2)行转换安装点 /dev/vx/dsk/rootvol 到 prom 名称失败


这个是电源管理的BUG吗？安装点/dev/vx/dsk/rootvol是被封装过的根盘卷。

kindy

谢谢NETBACUP老大，  SCSI我们也一直在测试，我们对SCSI盘阵建了一个卷，一直在对其写入操作，并且抓日志，没看到错误。

PATCH的问题还得和相关人员协商。

netbackup

原帖由 "kindy" 发表：
谢谢NETBACUP老大，  SCSI我们也一直在测试，我们对SCSI盘阵建了一个卷，一直在对其写入操作，并且抓日志，没看到错误。

PATCH的问题还得和相关人员协商。

你是用SunVTS这个工具进行的检测还是仅仅使用写入数据的方式？如果使用SunVTS，不要对这个工具期望太高。
另外还是仔细检查一下你的系统的patch和应用软件的patch之类的东西。
timeout的原因我觉得和你的系统中设备通讯的问题有关联，这也是我建议你确认SCSI通道是否存在问题的原因。另外，测试SCSI通道使用大数据进行测试，这样可能会有一些效果。

kindy

没有用SUNVTS， 这个东西的确不太有效。
我用的是在盘阵上建了一个2G的卷，然后挂到UFS文件系统，写了一个小教本，重复的先MKFILE 400M的是个文件，然后再删除，再建立。

PATCH 不敢随便打，现网，而且上述的测试也只是测了一个下午，没出现异常。