计算机工程
COMPUTER ENGINEERING
1999年  第25卷 第7期 Vol.25 No.5 1999



Windows NT环境下远程诊断系统的实现
魏小勇 张根度
摘要 详细阐述了NT下SNMP的工作原理,并讨论了基于SNMP的远程诊断系统在Windows NT环境下的构造方法,包括NT对远程访问的支持、NT的SNMP实现框架等内容。
关键词 远程诊断 简单网络管理协议 MIB 远程访问服务 Windwos NT
The Implementation of Remote diagnostic System under Windows NT
Wei Xiaoyong Zhang Gendu
Network Center of Fudan University Shanghai 200433
Abstract：This paper discusses the implementation of a remote diagnostic system based on SNMP.It is comprised of the topic on NT's support of remote access and the main frame of SNMP implementation under the Windows NT environment.
Key words：Remote diagnosis;SNMP;MIB;RAS;Windows Nt
1　远程诊断的提出
　　在应用软件市场竞争日益激烈的今天，售后服务和技术支持逐渐成为衡量软件产品质量的重要标准之一。软件厂商为了提高自己产品的竞争力，往往需要投入大量资金和人力用于技术支持人员的培训和提供迅捷的服务响应。为了提高服务效率，降低技术支持成本，有必要对应用系统运行中的故障加以分类，并对不同类别的问题施以不同的解决对策。
　　应用系统投入现场运行后，用户可能提出的问题很多，其诱发原因大体上可分为以下3类：①用户对软件的使用不熟练，不知道如何操作以完成所需功能；②软件参数配置不当或外部的软/硬件故障；③软件内部逻辑错误。
　　第一类问题可以通过加强用户培训，编写清晰详尽的用户手册来解决；第三类问题只能通过开发人员的查错纠错来解决。在应用系统经过实践考验，逐步趋于稳定运行之后，第二类问题就成为系统故障的主体。对这类问题，如果事先由应用软件自身的状态判断出故障原因，然后根据具体问题制订相应的解决对策(如远程修改参数配置、指导用户自行解决、派出技术人员现场处理等)，无疑能够大幅度提高服务响应速度，减少技术支持人员派遣的盲目性。远程诊断就是用于这一目的。应用系统分布的地理范围越广，越能够体现远程诊断在整个技术支持体系中的重要性。
2　基于SNMP的远程诊断
2.1　远程诊断与SNMP
　　远程诊断的关键在于，诊断主机能够取得被诊断系统的实时运行状态。诊断主机与被诊断系统之间的信息交换涉及到诊断信息结构、诊断信息传输协议和底层通信等几个方面。简单网络管理协议SNMP为这几个方面制订了统一的标准。使用SNMP开发诊断系统能够降低系统复杂性，并为诊断系统在不同硬件/操作系统上互操作提供了有利条件。
2.2　SNMP管理模型
　　SNMP是基于TCP/IP的网络管理协议，由以下4部分组成：①被管理节点；②管理机；③管理信息；④管理协议。
　　被管理节点可以是主机、路由器、网桥、网络打印机或其他有能力与外界交换状态信息的网络设备。在远程诊断中，被管理节点主要指运行被诊断系统进程的主机。为了能够直接被SNMP管理，被管理节点必须运行一个SNMP管理进程，又称为SNMP代理(Agent)。代理维护一个描述本机状态变量的数据库。管理工作由管理机完成。在远程诊断中，管理机就是运行专用诊断软件的通用计算机。为了保证代理的简单性，并使得代理对宿主设备的性能影响最小化，所有的管理智能都集中在管理机上。被管理节点只需要准确报告自己的运行状态，如何通过这些状态信息确定系统故障原因是管理机的责任。
　　每个被管理设备维护一个或多个变量用于描述自身状态。在SNMP术语中，这些变量被称为"对象"。网络上可能存在的对象在管理信息库MIB(Management Information Base)中定义。管理机使用SNMP协议与代理进行交互，询问代理维护的对象状态，或在必要时修改它们的值。代理也可以在非常事件发生时主动向管理机报告，这种报告称为SNMP陷井(Trap)。
　　SNMP模型的核心是一组由代理维护，并由管理机读写的对象。为了便于不同厂商产品的交互，这些对象必须用一种独立于厂商的标准来定义。另一方面，网络传输也需要一种标准对所传数据进行编码。SNMP使用OSI的ASN.1(Abstract Syntax Notation)作为对象定义和编码的标准。ASN.1并非完美的数据表示方法，它的编码规则以减少网络传输量为优化基准，却忽视了传输双方CPU为编码和解码所付出的高昂代价。
2.3　SNMP实现的难点
　　从以上叙述可以看出，要实现基于SNMP的远程诊断系统，必须完成以下工作：①诊断主机与被诊断系统之间的TCP/IP通信支持；②被诊断系统的SNMP代理；③ASN.1的编码与解码；④被诊断系统MIB模块的定义及其对象的维护；⑤综合管理信息判断系统故障原因。
　　其中，前3项工作对于任何一个SNMP系统都是相同的，只有最后两项因不同的SNMP应用而异。目前，国内大部分工矿企业还不具备联入Internet的条件，中心诊断主机与分布在不同地区的远程被诊断系统之间的通信还是通过公用电话网(PSTN)实现的，如果没有完善的系统软件支持，单单完成第一项工作对软件开发人员来说也是相当费力的。另外，由于SNMP与ASN.1本身所固有的复杂性，使得在缺乏系统软件支持的PC上，前3项工作可占去整个系统开发工作量的80～90%，然而只有最后两项才被认为是系统的目标。这样的工作量比例使技术决策人员难以下决心来使用SNMP作为构造个人计算机应用系统远程诊断的基石，即使SNMP有诸多理论上的优点。
　　令人欣慰的是，Windows NT 4.0对基于PSTN的TCP/IP和SNMP的支持使这种局面得到了彻底改观。现在，软件开发人员只要集中精力在最后两项工作，也是一个诊断系统的实质性工作上，就能够建造一个简洁、高效、具有SNMP所有优点的远程诊断系统。下面讨论如何在Windows NT下具体实现一个远程诊断系统。
3　NT下基于SNMP远程诊断系统的实现
3.1　中心诊断主机与远程被诊断系统之间的TCP/IP通信
　　Windows NT支持远程访问服务RAS(Remote Access Service)。RAS使远程计算机能够像直接连在局域网上一样使用网络资源。RAS以PSTN作为物理信道，向上层提供数据链路层服务。RAS支持多路复用，能将多条物理电话连接复用至一条逻辑RAS连接，从而获得较高的信道速率。在RAS基础上，NT可以将TCP/IP协议同时绑定到常规网卡和Modem上去。Windows NT 4.0的自动拨号特性(AutoDial Feature)使得常规网卡与Modem的区别对上层TCP/IP用户完全透明。
　　假设有一套远程诊断系统。中心诊断主机与各被诊断系统都通过Modem连接在公用电话网上。定时器触发诊断主机A向被诊断主机B查询状态信息。诊断进程向IP层发送目标地址为B的IP报文。由于A、B不连接在同一局域网上，所以发送操作会因目标地址不可达而失败，于是自动拨号机制启动。自动拨号在主机A与B之间建立RAS连接，RAS连接成功后，主机A上的Modem变成一块具有IP地址的虚拟网卡，使主机A在逻辑上同时连接两个局域网，无论这两个局域网在地理位置上相差多么遥远。对TCP/IP以上的应用程序，整个从IP到RAS的映射过程是透明的，也就是说，在NT 4.0上开发SNMP远程诊断系统，对开发者而言，完全可以将"远程"两字抛至脑后，远程与本地的差距将由操作系统来弥补。
3.2　Windows NT环境下SNMP的实现框架
　　NT对SNMP的支持主要实现在以下几个系统模块中：
　　(1) SNMP.EXE：它以NT Service的形式存在，是可扩展的SNMP代理。它处理代理方的ASN.1的编码与解码，并将管理机发出的GET、GETNEXT、SET命令映射成SNMP扩展动态库中的相应函数调用。
　　(2) MGMTAPI.DLL：它是一个动态连接库，处理管理方的ASN.1的编码与解码，并将SNMP的GET、GETNEXT、SET命令包装成函数调用形式供管理程序开发者使用。
　　(3) SNMPTRAP.EXE：它以NT Service的形式存在，处理被管理节点发出的SNMP陷井。它运行在管理机上，与MGMTAPI.DLL配合为管理程序开发者提供服务。
　　(4) SNMPAPI.DLL：它是SNMP的外围动态库，提供了一组工具函数，以期简化扩展代理库及管理程序的开发。这些工具函数包括内存管理、对象标识符管理、变量链表管理等。
　　在用户开发的远程诊断系统中，为了支持自定义的MIB，必须为该MIB编写一个动态连接库，然后将此动态库联入SNMP服务。一个SNMP扩展动态库可以同时支持ASN.1对象命名树中的多棵子树。以下假设用户编写了一个支持ASN.1对象命名树中根为 .1.3.6.1.4.1.12 的子树的SNMP扩展动态库，动态库名为USERMIB.DLL。下面说明NT下SNMP的工作机制。
　　图1示出了一个简单的SNMP诊断系统的框架。为了使示意图简洁，在此略去了与SNMP工作机制无关的SNMPAPI.DLL。图中，若模块A位于模块B上方，则表明A使用B提供的服务，或A调用了B提供的函数。椭圆形表示NT提供的系统模块，矩形表示需要用户自己开发的模块。

图1 简单SNMP诊断系统的框架
　　用户开发的USERMIB.DLL必须遵循NT-SNMP扩展动态库的规范，为了理解方便，有必要对此规范及MGMTAPI中的服务函数做简单介绍。SNMP扩展动态库是Win32的动态连接库，因此，它必须遵循Win32 DLL的开发规范[3]。除此而外，SNMP扩展动态库还应该为以下函数提供实现代码：
　　(1) SnmpExtensionInit：当SNMP服务启动时，可扩展代理   (SNMP.EXE)会调用扩展动态库的SnmpExtensionInit函数，以完成代理与扩展库之间的双边初始化工作。扩展库通过此函数通知代理自己所支持的视图(ASN.1对象命名树中某子树的根节点)，并返回一个陷井事件句柄。
　　(2) SnmpExtensionQuery：当可扩展代理收到管理机发出的GET、GETNEXT或SET请求时，它将根据各扩展库所支持的视图来选择适当的扩展库，然后调用该扩展库的SnmpExtensionQuery函数。扩展库在此函数中完成对象的查询或设置，再将结果返回给可扩展代理。
　　(3) SnmpExtensionTrap：可扩展代理一旦检测到某扩展库的陷井事件句柄上有信号(Signal)，就调用该扩展库的SnmpExtensionTrap函数来收集它所产生的一系列陷井。
　　MGMTAPI.DLL为管理方提供了一组函数，用于完成SNMP管理操作。
　　(1) SnmpMgrOpen：初始化通信套接字及相关数据结构，开始与指定代理之间的SNMP会话。
　　(2) SnmpMgrRequest：在指定代理上执行一次SNMP Get、GetNext或Set操作，并返回操作结果。
　　(3) SnmpMgrClose：关闭通信套接字，释放相关系统资源，结束SNMP会话。
　　(4) SnmpMgrTrapListen：管理进程调用此函数来表明自己接收SNMPTRAP的愿望。
　　(5) SnmpMgrGetTrap：当Trap发生时，管理进程调用此函数取得具体的Trap信息。
　　下面举例说明诊断主机A与被诊断主机B使用SNMP通信的具体过程。
　　通常情况下，诊断进程由定时器触发，启动一次诊断会话。主机A的诊断进程调用SnmpMgpOpen连接到被诊断主机B上，然后用SnmpMgrRequest查询名为 .1.3.6.1.4.1.12.2.1 的对象状态。主机B上的可扩展代理收到相应的SNMP请求，发现被操作对象包含在USERMIB.DLL所支持的视图中，于是调用USERMIB.DLL的SnmpExtensionQuery函数来获取相应的对象状态，再将结果返回给诊断主机A。主机A格式化返回结果，作为SnmpMgrRequest的返回值传送给诊断进程。状态信息收集完成后，诊断进程调用SnmpMgrClose结束本次SNMP会话。状态信息交换过程所涉及的ASN.1的编码与解码在诊断主机上由MGMTAPI.DLL完成，在被诊断主机上由可扩展代理SNMP.EXE完成。
　　主机B上的被诊断进程若发现自身故障，也可使用SNMP Trap主动向诊断主机报告。被诊断进程设置USERMIB.DLL中的陷井事件句柄为有信号状态，可扩展代理检测到该信号，就会向诊断主机发送UDP报文。主机A上的SNMP Trap Service收到UDP报文后，将诊断进程通过SnmpMgrTrapListen传送给MGMTAPI.DLL的陷井监听事件句柄设置为有信号状态。该信号触发诊断进程的一系列SnmpMgrGetRrap调用，这些调用导致被诊断主机上可扩展代理对USERMIB.DLL中SnmpExtensionTrap的函数调用。被诊断进程在SnmpExtensionTrap中将发生的具体陷井信息返回给可扩展代理，再由代理经诊断主机的MGMTAPI.DLL传送给诊断进程。
4　结束语
　　目前，Microsoft Windows系列对SNMP的支持仅限于NT4.0，而一般的应用系统既包含运行NT的高档服务器，也包含运行Windows 95和Windows  3.x的中低档计算机。如何将这些中低档计算机纳入NT的SNMP管理范围，仍是一个值得探索的问题。
　　总而言之，NT4.0对RAS与SNMP的全面支持使远程诊断系统的开发变得规范、易行，在此基础上开发标准化的远程诊断系统是一件很有意义的工作，它将使基于个人计算机的应用软件的技术支持走上一个新台阶。
作者简介：魏小勇 男，24岁，研究生，主研方向：计算机网络与分布式系统
作者单位：复旦大学网络信息中心 上海 200433
参考文献
1　Tanenbaum A S.Computer  Networks.3rd Edition,Prentice Hall，1996
2　Microsoft Platform SDK Documentation.Microsoft  Corporation,1997
收稿日期：1998-08-31
