VERITAS容灾系统中奇怪问题。

mmmmn

主要还是打PATCH
不知道call center是谁回答的你的问题，竟然没提patch的事情？

看你上面的反馈信息是说的这个意思：
你用的应该是application类型的资源，用户使用自己的监控程序来监视资源状态
但是现在是在设定的时间内监控程序没有返回任何数值（正确还是错误，110或100）所以导致VCS无法正常判断应用状态

你可以检查配置信息，然后自己手动运行该监视脚本看看出什么问题
暂时应该和SCSI无关，但你可以把系统里面的错误信息贴出来看看

另外TAG_B应该是和syslog里的err等类似，是记录错误级别的。我印象中TAG_A和B都代表VCS软件本身问题

netbackup

如果有application资源，那可以先disable这个资源，看看是否和自己创建的application资源存在关系。

老邱

原帖由 "kindy" 发表：
不好意思，白天在机房，不能上网，晚上才可以。

如下是VCS  APPLICATION监控日志：
TAG_B 2004/11/24 09:37:30 Thread(19) VCS:13027:Resource(EMSApp) - monitor procedure did not complete within the expect..........

上面报的timeout是你自己的application类型的resource，所以要看你自己的monitor脚本里是怎么写的。当VCS通过你的monitor脚本对资源进行监控时，有一个timeout时间（可设置，好像叫OnlineTimeout），当timeout时间到了而monitor程序还没反馈时，VCS就认为这个resource发生了fault。

从你描述的情况看，有时候屏保10分钟才能恢复，还有telnet 10分钟才好，可能是系统因为某种原因非常繁忙，CPU无法处理任何请求。这时，VCS的monitor程序也无法得到响应，所以timeout。

所以，因该去查系统繁忙的根本原因。例如，用prstat或其它方法隔1分钟监控一次，输出到文件，下次再发生timeout的话，可以发现到底哪个进程造成系统繁忙。

kindy

原帖由 "老邱" 发表：


上面报的timeout是你自己的application类型的resource，所以要看你自己的monitor脚本里是怎么写的。当VCS通过你的monitor脚本对资源进行监控时，有一个timeout时间（可设置，好像叫OnlineTimeout），当timeout时?.........

我比较倾向于老邱提的这种意见，现在在做prstat每5分钟做一次，不敢每一分种做一次，因为现网系统跑在上边。
而且并不只是只有这几个资源才TIMEOUT，NIC网卡资源的监控也会TIMEOUT掉。我得业务资源监控教本其实很简单，就只是PS检查某个进程在不在，个人感觉可能会出现资源耗尽时发生PS命令无响应的情况，所以业务资源TIMEOUT了。
但是为什么NIC也会出现这种情况，VCS中对NIC时如何做监控的？

kindy

原帖由 "mmmmn" 发表：
主要还是打PATCH
不知道call center是谁回答的你的问题，竟然没提patch的事情？

看你上面的反馈信息是说的这个意思：
你用的应该是application类型的资源，用户使用自己的监控程序来监视资源状态
但是现在是在..........

监控脚本就是一个ps检查某个进程是否在的情况。
TAG_B是报错级别。 这下知道了，再检查检查问题，但是我找了VCS MP3的一些所能解决问题的内容，没有发现相关部分。
而且客户对于打PATCH比较警惕， 呵呵，他们的要求是只有在确定了是PATCH的缘故的话才能打PATCH。

老邱

VCS对NIC的监控原理，bundled agent guide里有讲。简单来说，NIC agent里有一个NetworkHosts参数，如果设了，NIC agent对这个hots进行ping以确定NIC是否好；如果没设，NIC agent对这个NIC的broadcast地址进行ping。

NIC资源也timeout，肯定连ping指令也得不到响应。还是应该对为什么机器如此繁忙来查。解决了机器忙的问题，VCS自然不会timeout。那个可能才是根本原因。

netbackup

Hi, Kindy ,how about your problem?