2023年桌面管理规范ＤＭＩ分析.docx

桌面管理标准ＤＭＩ分析 概述 随着联网技术的飞速开展，企业联网势在必行。研究说明，随着联网PC种类、数量的不断上升，一年内维护和运行一台PC的开销——总保有本钱TCO将急骤上升。为了有效地控制TCO，近年来，业界提出了不少新的网络管理标准。例如Intel的WfM2.0、Microsoft的WMI、DMTF（DesktopManagementTaskForce，Inc.）的CIM等。新的网管标准通过提高企业网的远程监控、远程安装、远程配置等能力，将系统使用与系统维护工作分开，有效地提高了用户的工作效率、减少了TCO。 作为企业级网络管理标准的一个根底，桌面管理标准（DesktopManagementInterfaceSpecificationVersion2.0，简称DMI）为实现台式机、效劳器、便携机的资产管理、远程监控、远程访问提供了标准的接口。由于DMI具有不依赖特定的操作系统和硬件；不依赖特定的网管协议；具有统一的编程接口，易于被厂家采纳；可提供本地、远程访问接口；能将DMI信息映射至已有的网管协议（如CMIP、SNMP）等特点，近年来获得了业界的广泛支持。 DMI的组成和结构 以往的管理应用程序在访问系统软、硬件信息时要直接同操作系统、硬件驱动程序打交道。由于不同的操作系统、硬件提供不同的编程接口（API），这极大地限制了管理应用程序访问不同系统、部件的能力。为了便于管理应用程序访问底层软、硬件信息，DMI2.0通过在管理应用程序与硬件驱动程序之间增加一个抽象层（DMIServiceProvider）实现对底层信息的一致访问。因此，结构上，DMI由效劳层（ServiceProvider）、管理接口（ManagementInterface）、组件接口（ComponentInterface）三局部组成，如图1所示。 1．DMI效劳层 DMI效劳层（以下简称DMISP）是一个常驻内存的应用程序。它负责管理DMI的MIF库，执行管理应用程序的部件安装、删除命令；响应管理应用程序（ManagementApplication）、部件测试工具（Componentinstrumentation）发出的DMI请求（request）；支持事件/报警（Event/Indication）的预定（Subscription）和过滤（Filtering）机制。 这里，管理应用程序指能发出DMI命令的应用程序。它可能是一个具有图形用户界面的应用程序，也可能是一个没有用户界面的将SNMP、CMIP请求转换成DMI请求的网管协议代理。部件测试工具是专门用于管理某特定部件可管理属性的代码程序，通常是一个DLL或EXE文件。DMI视计算机内一个物理上（或逻辑上）的实体（包括软件和硬件）为一个部件（Component）。 图1DMI的结构 2．管理接口 DMISP与管理应用程序的接口称为管理接口（ManagementInterface，简称MI）。管理接口主要由DmiGet、DmiSet和DmiList三类命令组成。其中，DmiGet、DmiSet分别用于读取、设置DMI组属性。DmiList用于查询MIF库信息。由于DmiList不返回属性值，管理应用程序发送DmiList请求时，DMISP不调用部件测试工具。另外，由于多个应用程序可能同时访问一个DMISP，为了区分不同的管理应用程序发出的DMI请求，DMI规定：管理应用程序在请求DMISP效劳前，首先要向DMISP注册并获得一个合法的管理句柄（Handle）。随后，管理应用程序可以利用得到的句柄发送DMI请求。最后，为了便于DMI数据库操作，管理接口还包含DmiAdd、DmiDelete等多条命令。 DMI1.0效劳层只提供本地调用接口。DMI2.0在1.0的根底上增加了一个远程过程调用（RemoteProcedureCall,简称RPC）支持层（supportlayer）。借助RPC（DEC/RPC、ONC/RPC或TI/RPC）机制，DMI隐藏了远程过程调用的复杂性，为管理应用程序访问本地和远程桌面管理信息提供了一致性方法。 3．部件接口 DMISP与组件测试工具的接口称为部件接口（ComponentInterface，简称CI）。DMI2.0标准规定，组件测试工具可以有两种实现方式： （1）直接接口程序（Directinterfaceprograms） 直接接口程序是一个内存常驻程序。系统启动后，它能自动运行并向DMISP注册自己。由于直接接口程序能随时响应来自管理程序的DMI请求，因此，它可用于实时监测。 （2）运行时覆盖程序（Runtimeoverlayprograms） 运行时覆盖程序平时不占用内存。只有当管理应用程序发出DMI请求时，DMISP才加载、运行该程序。 为了查询某个部件的属性值，管理应用程序可以主动发出DMI查询请求。为了监视某个部件的工作状态，DMISP可以接受Componentinstrumentation发出的DMIIndication（DMI报警）。DMISP采用客户机/效劳器模式。当管理应用程序发出DMI请求时，管理应用程序充当客户机，DMISP充当效劳器。这时，管理应用程序请求DMISP效劳，DMISP响应执行。反之，当管理应用程序接收来自DMISP的Indication时，DMISP充当客户机，管理应用程序充当效劳器。 DMI管理信息格式（MIF）及标准组定义 1．管理信息格式（MIF） 管理信息格式（ManagementInformationFormat）是DMTF定义的用于描述部件可管理特性的一种语言。部件可管理特性的描述必须严格遵守MIF的语法并写入一个文本文件（textfile）。原那么上，每一个部件都有一个MIF文件和一个部件测试工具（.DLL或.EXE文件）。其中，MIF文件描述部件的可管理属性（如部件名称、制造厂家、型号、产品序列号、驱动程序文件名、安装时间等）。部件测试工具负责读取部件的属性值。当一个可管理部件首次被安装到系统上时，如果DMISP处于活动状态，其MIF文件会被自动添加到DMISP的数据库——MIF库中。卸载一个部件时，DMISP自动从MIF库中删除该部件的MIF文件。由于DMI没有规定MIF数据库的具体实现方式，MIF库通常是不可读的。 MIF文件可以选用ISO8859-1或Unicode1.1作为其编码字符集。采用Unicode1.1编码的MIF文件，其第一个八位组必须是0xFE（16进制）。采用ISO8859-1编码的MIF文件，其第一个八位组必须是0xFF（16进制）。除双引号括起的字符串外，MIF文件中的字符是大小写敏感的。 在MIF文件中，部件说明总是以STARTCOMPONENT（组件说明开始）起头，ENDCOMPONENT（组件说明结束）结尾。如图2，部件的可管理属性（Attribute）依据其逻辑关系被组织到假设干个组（GROUP）中。因此，一个系统可能有假设干个部件，一个部件可能有假设干个组，一个组可能有假设干个属性。类似于部件说明，组和属性的说明分别以STARTGROUP、STARTATTRIBUTE开头，ENDGROUP、ENDATTRIBUTE结尾。每一个部件、组或属性都有一个名称（NAME）和编号（ID）。但是，DMI是按组（而不是按部件）组织属性的，因此，管理程序访问一个属性的依据是组类串（classstrin）名及属性ID（或属性名）。 2．DMI标准组定义 为便于管理，DMTF为一些常用部件提供了标准组定义。主要包括部件标准组、事件标准组和DMISP标准组定义。 （1）部件标准组 部件标准组（ComponentStandardGroup）的类串名是DMTF|ComponentID|001。在这里，DMTF是定义该组的机构名称，ComponentID是组名，001表示组定义的版本号。作为部件说明的第一个组，部件标准组是每一个部件必须提供的。它由PRODUCT、MANUFACTURER、INSTALLATION、VERIFY等6个属性组成，提供了诸如部件名称、生产厂家、安装时间、当前状态等与部件相关的最根本信息。 （2）事件标准组 DMI规定，系统软、硬件状态的变化（如打印机缺纸、CPU温度升高）将直接导致事件的产生，从而直接或间接地导致DMISP产生响应。事件标准组为管理应用程序跟踪系统部件的状态提供了一种有效的监控机制。利用监控机制跟踪系统中某一部件的状态，不会过多占用管理控制台CPU时间和网络带宽。 事件标准组（EventStandardGroup）可分为事件产生组（EventGenerationGroup）和事件状态组（EventStateGroup）两种类型。事件状态组的所有属性可被管理应用程序直接访问。事件产生组那么不同，除第五个属性（AssociatedGroup）外，管理应用程序一般不直接访问组内的属性。通常，由事件产生组定义的事件通过indication数据结构给管理程序传递数据。 事件既可传给本地也可传给远程控制台程序。当需要远程监控时，为节省带宽，需要将一些不重要的事件滤掉。因此，DMI定义了事件的预定（Subscription）和过滤（Filtering）机制。 （3）DMISP标准组 DMI将DMISP视为系统内一个部件，通常DMISP都是系统的第一个部件。为此，DMTF为DMISP定义了几个标准组。除部件标准组以外，DMISP标准组主要还包括SPIndicationSubscription、SPFilterInformation、DMIPolicyTable、DMIAuthenticationProtocolsTable等标准组。这里，SPIndicationSubscription、SPFilterInformation用于实现事件的预定和过滤机制。DMIPolicyTable、DMIAuthenticationProtocolsTable用于配置DMI平安特性。ServiceProviderCharacteristics用于翻开（或关闭）本地MI、CI的访问控制。DMILoggingTable可以使DMI事件直接记录在本地。 DMI实现及技术支持 1．DMI实现 目前，为DMI2.0标准提供软件支持的公司有SmartTechnologyEnablers，Inc（简称TheEnablers公司）。该公司已开发的系统软件主要有SmartDMISecureServiceProviderSDK、SmartDMIManagedObjectsToolKit、SmartDMItoSNMPMapper。其中，SmartDMISecureServiceProviderSDK是DMI2.0s（平安DMI）的一个实现。它提供的MI、CI编程接口（API）可供管理应用程序开发者调用。SmartDMIManagedObjectsToolKit是一个高级管理应用程序开发工具。利用它提供的一些ActiveX控件，开发者可以迅速组建自己的管理应用程序，无需了解DMI标准的细节。SmartDMItoSNMPMapper是一个DMI到SNMP的映射工具。SNMP主要用于网络设备的管理，由于制定时间早，目前已获得了广泛的应用。DMI2.0主要用于台式机的管理，由于它能适应不同的软硬件平台，因而技术上有较大的优势。尽管DMI和SNMP在功能与概念上有许多相似之处，两者之间却没有天然的互操作性。这主要缘于两个标准出自不同的标准化组织。为使SNMP管理软件能够管理、访问DMI系统（安装了DMISP软件的系统），DMTF制订了一个DMI到SNMP的映射标准——DMItoSNMPMappingStandard。SmartDMItoSNMPMapper是这个映射标准的一个实现。 2．技术支持 目前支持DMI的大型网管软件主要有：Intel的LANDeskManagementSuite（LANDesk管理套件）、Micros