前几天,在与一些用户的讨论中,我清楚地认识到,他们不明白在什么情况下,Stratus VSeries系统会就网络适配器打电话回家。这个误解导致系统失去了网络连接。如果他们不明白,我相信还有其他人也不明白,所以这篇博客将试图解释系统在什么情况下会因为网络适配器而打道回府。
简单的答案是,当系统检测到网络适配器出现故障时,系统就会打电话回家。灰色地带是什么叫失败。如果适配器坏了或者被系统弄坏了,系统会运行一组诊断程序,如果适配器通过了,就会重新投入使用。如果它在太短的时间间隔内坏了太多次,适配器就会超过MTBF(平均故障间隔时间)阈值,并继续停止服务。如果发生这种情况,系统将就该适配器打电话回家。如果诊断程序运行并失败,则适配器仍将停止服务,系统将致电首页。
如果活动和备用网络适配器伙伴之间传递的sdlmux测试消息未能被伙伴适配器接收,系统将破坏备用卡,对其进行测试并使其重新投入使用。如果任何阻挡测试消息的原因没有解决,这种模式将重复进行,直到网卡超过MTBF阈值,系统将把它叫回家。这里要注意,问题可能不是适配器,而是网络。
如果一条链路掉线,导致一个适配器不再连接到网络,系统将根据需要对网络适配器进行故障转移,而不会做任何其他事情。它不会打电话回家。原因是链路掉线的原因太多,几乎都是适配器的外部原因。二十二年前在VOS 8.0版本中,最初的Stratus 以太网实现确实会在链路丢失时打电话回家。这导致了许多问题被打开,当我们给他们回电话时,这只是惹恼了人们,因为他们知道他们已经重新启动了交换机或移除了电缆。当时决定,丢失链接不视为故障。请注意,除非两个适配器都有网络链接,否则前一段提到的sdlmux测试信息不会发送。
那么,开篇提到的用户怎么了?大约一个月前,他们失去了与一个适配器的链接。他们没有意识到这一点,因为系统没有连接问题。然后几天前,他们失去了另一个链接,此时他们已经脱离了网络。这种情况说明了为什么要监控系统上的适配器,以确认它们是否连接到网络。定期监控会及时发现第一个适配器的链路问题,在第二个适配器的链路问题发生之前及时纠正。
命令宏 monitor_sdlmux_adapter_status(图1)将定期监控所有sdlmux的伙伴适配器。它将向选定的用户发送第25行消息,并在syserr_log中添加一个条目。syserr_log条目是在链接首次丢失时产生的,但monitor_sdlmux_adapter_status宏会在每次检查时增加一个条目,使其更容易被看到(图2)。这个宏应该作为启动的进程运行,并将-privileged设置为yes,因为它调用analyze_system来获取sdlmux设备的列表。
宏还会检查其中一个适配器是否"DOWN",并会以报告掉线的方式报告。系统应该打电话回家,但很容易添加检查,我想,额外的通知不会有什么伤害。
第25行和syserr_log信息是指运行monitor_sdlmux_adapter_status宏的人的主目录下的check_adapters文件,该文件由对系统中的每一个sdlmux伙伴运行的dlmux_admin sdlmux_status命令的输出组成(图3)。该文件由dlmux_admin sdlmux_status命令对系统中的每一个sdlmux伙伴运行的输出组成(图3)。你需要查看该文件以确定有问题的特定适配器。
该宏只查看已与sdlmux合作的适配器。未配对的适配器的问题会立即显现,因此不需要额外的监控。请注意,Stratus ,建议所有的网络适配器都与sdlmux结成伙伴关系。
& monitor_sdlmux_adapter_status begins here |
图1 - monitor_sdlmux_adapter_status命令宏
d >system>syserr_log.10-05-24 -match check_adapters %phx_vos#m16_mas>system>syserr_log.10-05-24 10-05-25 08:27:29 mst . . . . . . . . . |
图2 - syserr_log信息
d check_adapters
%phx_vos#m16_mas>SysAdmin>Noah_Davids>check_adapters 10-05-24 19:57:43 mst
************************************************** --------------- 10-05-24.19:56:47 ---------------- **************************************************
************************************************** Group Name: #sdlmuxA.m16.10-5-0.11-5-0 Device Name: %phx_vos#enetA.m16.11-5-0 Adapter State: ACTIVE UP Partner: %phx_vos#enetA.m16.10-5-0 Partner State: UP (network connection lost)
************************************************** Group Name: #sdlmuxA.m16.10-5-1.11-5-1 Device Name: %phx_vos#enetA.m16.10-5-1 Adapter State: ACTIVE UP Partner: %phx_vos#enetA.m16.11-5-1 Partner State: UP
************************************************** Group Name: #sdlmux.m16.11-2 Device Name: %phx_vos#enet.m16.11.11-2 Adapter State: ACTIVE UP Partner: %phx_vos#enet.m16.10.11-2 Partner State: UP
************************************************** Group Name: #sdlmux.m16.11-3 Device Name: %phx_vos#enet.m16.10.11-3 Adapter State: ACTIVE UP Partner: %phx_vos#enet.m16.11.11-3 Partner State: UP
ready 19:57:43 |
图3 - check_adapters文件的输出显示#enetA.m16.10-5-0已经失去了链接。