高校网络管理运维中实体命名系统设计与实践

2018-04-11昝风彪

实验室研究与探索 2018年1期

叶　涛,　昝风彪

(青海民族大学计算机学院，西宁 810007)

0　引　言

随信息化建设的不断深入，高校网络基础设施规模不断扩大，设备的类型、数量日益增多，管理策略也日趋复杂。通信链路、网络设备等网络各元素因缺少科学规范命名方式致使网络实体命名混乱，为网络管理员快速定位设备和故障排查增大了难度，给学校资产管理和设备日常运维带来诸多不便[1-4]。

网络实体名字是网络日常维护和故障排查的重要信息。网络实体元素规范、正确命名是确保资产管理工作顺利开展的基础，也是提高网络运维和综合管控的有效手段。因此设计一套命名系统来实现网络设备的规范统一标识是高校设备信息化智能管理的重要工作[5-6]。

1　高校网络设备原有命名方式存在的问题

高校网络基础设施种类繁多，分布广泛，其监管机构权限各异、直接责任人随时更换等管控现状，导致原有网络实体命名方式存在诸多问题。

(1) 由于对名字在设备管理中的重要性认识不足，高校往往没有明确指定的具体职能部门负责建制网络元素全局统一命名标准，确定名字分配权限。网络设施中每个实体的命名取决于各建设单位或历任网络管理员的主观意识判断，表述形式各异。如一物多名，“电脑”“计算机”“微机”均指同一机器[7]。

(2) 名字空间缺少科学的描述手段，命名规则包含关系混乱，不能有效验证每个名字的合法性。如将计算机的标签错误贴在的交换机上，用户也无法及时验证标签的正确性。

(3) 现场设备的标签名字与网络工程建设的技术文档中的标识不一致。如综合布线中链路标识不清，没指明对端连接位置，后期维护异常困难。

(4) 语义解析不准确，名字不能正确反映设备相关属性，易造成误解。如进口设备直接借用英文缩写名称含义不清。

(5) 命名规则不灵活，管理手段落后。当设备相关属性发生变化时，无法做到实时、有效的更新系统数据和现场标识。

2　名字空间研究内容与现状

名字(或称标识)是标识事物的符号，伴有记录和传递信息的功能。为了对一个系统中的实体进行区分、访问和引用，有必要给其中的每个实体分配一个名字。系统中任一实体在概念范畴内可以被分配的名字集合[8]构成该系统的名字空间，概念范畴相关的约束条件称为命名规则，名字符号所含信息的概念和意义称为语义。随着信息化智能管理系统的发展，名字的内涵得到进一步扩展，实体名字既要便于人们阅读理解，也要能够被机器识别。

名字空间具有 3个重要的属性[8]:名字特征，名字分配，名字解析。

名字空间特征包括名字有效范围、名字空间内部结构和名字长度。根据名字的有效范围，名字空间可分为全局名字空间和局部名字空间，全局名字空间是指系统内所有实体都从一个名字空间中获取唯一的名字，局部名字空间是指将全局名字空间划分为不同区域来对应系统的子系统以便实现分布式命名，各子系统之间关系对应了名字空间内部结构；根据名字空间内部结构，名字空间又可以分为扁平名字空间、分级名字空间和组合名字空间[9]；根据名字长度是否固定，名字空间分为定长名字空间和可变长名字空间。

名字分配是指系统的管理机构为实体分配名字的方法和权限，系统中实体名字可以由一个唯一权威机构统一分配，也可以由多个机构根据权限分级分布式分配；既可根据名字分配时效进行永久性分配或动态分配，还可根据实体和名字之间对应关系进行一对一的唯一性分配或一对多的非唯一性分配。

名字的解析是指把名字空间中的名字符号解析为对应的实体。名字解析可以是全局统一的，也可以是局部相关的。全局统一的名字解析是指解析操作在一个全局唯一的机构上进行，局部相关的名字解析是从对应关系的局部机构上获得解析结果。

研究界围绕着名字空间开展了大量的研究[10-14]，分析了名字空间属性特征，提出了一系列的命名规则，其成果多用于互联网域名系统，对高校网络设备名字空间研究少有介绍。由此，本文提出一种基于文法描述、规则匹配推导的命名系统。

3　文法描述和规则匹配的命名系统设计

3.1　设计原则

(1) 唯一性和可验证性相结合。指在同一名字空间中，根据一个名字提供的信息能够找到惟一一个对应实体；反之，根据一个实体的真实、完整信息可以编码出唯一一个对应名字，并根据规则可验证名字编码的合法性。

(2) 统一性和相关性相结合。考虑一个系统内实体对应管理组织或个人职能权限差异或关注信息内容的不同，按系统管理组织结构，采用全局名字空间和局部名字空间相结合，顶层组织建制并使用全局名字空间命名规则，下层组织权限范围内使用局部名字空间命名规则。

(3) 永久性与灵活性相结合。针对实体信息固定不变的属性建立持久性名字空间，针对系统中如实体内容可能会更新、存放位置可能会变化，持有者可能会更换等相关属性建立灵活局部名字空间。

(4) 通用性和便捷性相结合。针对系统内任何类型实体，编码管理员可以快速使用统一的命名规则来对其进行命名，审核实体属性描述的规范性；用户无需背熟系统命名规则就能快速识别实体名字包含相关信息，查找关注的实体属性组合。

3.2　文法描述和规则匹配的命名模型

名字是具有层次结构的符号串，其本质是人和机器能阅读分析的一种语言。系统的名字空间模型设计就是描述名字空间属性特征，制定命名规则，以此规定名字的符号串和层次结构。文法是描述语言现象词汇间的并列关系与嵌套关系的有效工具[15]，上下文无关文法作为系统名字空间描述工具，具有科学规范，精准易懂等优点，便于根据命名规则高效构造实体名字并分拆验证其合法性，结合语义描述能较好地适合人类理解和机器语法制导翻译。

基于规则匹配的名字空间设计的基本思想是从代表系统全部实体属性标识出发，不断进行规则配匹替换，最终推导出概念范畴内的一个字符串名字，规则匹配是代表实体某些属性的标识组合被另外一些属性标识组合替换过程。

定义名字空间G是能够标识命名系统内任一实体的一个四元组G= (N，T，S，P)，其中：

N为系统内任一实体相关属性的有限集合；

T为系统内构成实体名字所有符号或符号串有限集合，它与N不相交，N∩T=Φ；

S为系统实体全部属性的特殊符号，系统内任一实体名字由该符号推导，S∈N；

P为形如A→α的命名规则的有限集合，其中A∈N，α∈V﹡，V=T∪N，特殊情况下允许如A→ε空产生式存在。

4　文法名字空间在高校网络设备管理中的应用实践

4.1　网络设备管理结构

我校网络相关设备数量累计上万台件，分布于网络信息中心、计算机学院实验室和其他各院系部门，遍及全校各楼各屋，承载着各类办公、教学、科研、实验业务应用系统和诸多公网业务，校内用户近1.5万人。

学校网络设施管理结构如图1所示，由校实验设备中心负责设备采购，质量监督，资产登记，设备分配与归口，运行效率监管；院系部门负责提出网络建设，设备采购申请，组织工程建设，指派责任人，监管运行过程；责任人负责设备的管理和运维，记录设备运行状态、使用效率，提出维修和报废申请。

图1青海民族大学实验设备管理结构图

根据学校设备管理组织结构，确立全局名字空间由校实验设备中心建设并编制规则文件，部份局部名字空间由网络建设单位设计或使用设备生产商产品标识。

4.2　基于文法的高校网络设备命名系统

设高校网络设备全局名字空间G有命名规则：

(1) 〈设备实体标识〉→〈通信链路标识〉|〈网络设备标识〉…

(2) 〈通信链路标识〉→〈起始标志#L〉〈链路类型〉〈上行端标识〉〈下行端标识〉

(3) 〈链路类型〉→〈光纤O〉|〈双绞线E〉…

(4) 〈上行端标识〉→〈起始标志⊕〉〈位置〉〈端口标识〉|ε

(5) 〈下行端标识〉→〈起始标志⊙〉〈位置〉〈端口标识〉|〈起始标志⊙〉〈计算机P〉〈两位数字〉|ε

(6) 〈位置〉→〈楼号〉〈楼层号〉〈房间号〉|ε

(7) 〈楼号〉→〈起始标志B〉〈两位数字〉|ε

(8) 〈楼层号〉→〈起始标志F〉〈两位数字〉|ε

(9) 〈房间号〉→〈起始标志R〉〈两位数字〉|ε

(10) 〈端口标识〉→〈配线架号〉〈端口号〉|〈信息点〉〈端口号〉

(11) 〈配线架号〉→〈起始标志D〉〈两位数字〉|ε

(12) 〈端口号〉→〈起始标志K〉〈两位数字〉|ε

(13) 〈信息点〉→〈起始标志T〉〈两位数字〉|ε

(14) 〈网络设备标识〉→〈起始标志#S〉〈设备类型〉〈厂商编码〉〈所属部门〉〈责任人标识〉〈部署位置〉

(15) 〈设备类型〉→〈计算机P〉|〈交换机S〉|〈路由器R〉……

(16) 〈厂商编码〉→〈变长名字起始标志[〉〈厂商名标识〉〈产品型号〉〈变长名字结束标志]〉

(17) 〈所属部门〉→〈起始标志∈〉〈不超过8位部门名称拼音首字母大写〉|ε

(18) 〈责任人标识〉→〈起始标志@〉〈不超过15位责任人名字全拼小写〉|ε

(19) 〈部署位置〉→〈起始标志&〉〈位置〉|ε

名字空间G中，全部规则构成分层结构的全局名字空间，每一个规则可看作一个局部名字空间。如规则(1)将高校网络设备分为通信链路标识、网络设备两大类型，对应两个局部名字空间，还可根据实际应用类型进一步扩展。规则(16)中设备生产厂商编码是按厂商产品命名规则设置为变长局部名字空间，使用变长名字起始标志‘[’、变长名字标识结束标志‘]’进行定界。

4.3　高校网络设备名字空间语义描述

(1) 通信链路名字空间语义描述。如表1所示，通信链路标识是永久性名字空间，由网络信息中心建设和维护，为便于其他部门应用，在综合布线文档中定义、引用通信链路标识时应使用完整名字。

如：#LO⊕B06F03R03D02K11⊙B01F02R02D02K24。通过⊕B⊙B判定是楼间链路类型。

表1　通信链路语义描述表

通信链路按综合布线标准从建筑群子系统到工作间子系统的顺序，将链路两端分成上行端、下行端。在现场链路一端贴标签时，只需本端粘贴对端端口标识，以便现场维护。

如：上行端贴#LO⊙B01F02R02D02K24，下行端贴#LO⊕B06F03R03D02K11。

(2) 网络设备名字空间语义描述。如表2所示，网络设备名字空间采用分层命名结构，它的完整名字包含厂商产品型号是永久性局部名字空间。校实验设备中心设备登记、分配、监管过程中使用全局名字是：

#SS[H3C S3600-28-EI]∈JSJXY⊕yetao&B10F02R42

表2　网络设备名字空间语义描述表

在网络工程建设技术文档中不关注设备所属部门和责任人，在定义、引用网络设备名字时可只使用设备的永久名部份。如：#SS[H3C S3600-28-EI]。

在重要设备现场贴标签时，分成4个独立标签连贴，当所属部门、责任人、部署位置发生变化时便于立即更换相应标签。

4.4　名字编码与合法性验证

假设新采购H3C网络设备S3600交换机，分配给计算机学院使用，设备部署在10号楼2楼42号房间，指派叶涛负责管理，给出该设备的名字编码。

〈高校网络实体标识〉=>〈网络设备标识〉规则(1)替换

=>〈起始标志#S〉〈设备类型〉〈厂商编码〉〈所属部门〉〈责任人标识〉〈存放位置〉

使用规则(14)替换

=>#S〈交换机S〉〈变长名字起始标志[〉〈厂商名标识〉〈产品型号〉〈变长名字结束标志]〉〈所属部门〉〈责任人标识〉〈存放位置〉

规则(16)替换

=>#SS[H3C S3600-28-EI]〈起始标志∈〉〈不超过15位部门名称拼音首字母大学〉〈起始标志@〉〈不超过15位责任人名字全拼小写〉〈起始标志&〉〈位置〉

使用厂商编码及规则(17)(18)(19)替换

=>#SS[H3C S3600-28-EI]∈JSJXY@yetao&B10F02R42

使用设备分配部署信息编码

通过匹配推导完成了名字编码，同时验证了该名字的合法性。

5　命名系统应用实践成效

(1) 名字空间引入文法描述、规则匹配的科学手段，便于信息抽取、检索、机器翻译，加强信息化智能管理水平，提高了实验设备管理部门资产管理能力。

(2) 名字空间应用实践过程中明确指定职能部门负责学校网络设施管理名字空间建设，形成了全局统一命令标准，明确了名字分配机构和权限，规范名字分配流程，提升了网络设备管理工作的规范化水平。

(3) 名字中携带了设备责任人和地址信息，便于第一时间定位网络故障，提高网络运维和综合管控工作效率。

(4) 名字空间采用分层内部结构设计，永久分配与动态分配结合，增加了系统实体命名的灵活性、扩展性和兼容性。

6　结　语

本文分析了高校网络设备管理中命名方式存在的问题，自主设计了一套基于文法描述、规则匹配的设备命名系统。该系统设计科学严谨，规范合理，灵活易于扩展，有效解决了传统网络设备命名方法导致的各类问题，通过学校资产管理和网络建设运维证明了所设命名系统规范、实用。网络实体命名系统建设是一个长期工作，完善名字空间规则和扩展服务类实体名字空间是下阶段研究的主要内容。

参考文献(References)：

[1]刘舒野.基层央行网络设备命名及配置描述探讨[J].金融科技时代,2016(9):50-52.

[2]谢枰飞.浅谈高校实验室固定资产管理中存在的问题及调整策略[J].经营管理者,2013 (3) :267-268.

[3]曾爱华,刘捷,冼进,等.高校实验室资产管理方法的改进与实现[J].实验技术与管理,2011,28(3):198-201．

[4]刘福泉.信息中心网络的理想命名规则研究[J]. 计算机时代,2015(6) :23-25.

[5]孙胜春,濮怀宇,苏雪峰,等.加强体系结构建设提高实验室管理水平[J].实验室研究与探索,2011,30( 9) :349-352．

[6]吴良,邹志宏,吴文华，等．智能实验室管理系统的开发与实践[J].实验室研究与探索,2012，31(5) : 169-172．

[7]王明学,戚亮新,王波.对设备规范命名的几点建议[J]. 中国设备工程,2004(4):13.

[8]李丹,吴建平,崔勇,等. 互联网名字空间结构及其解析服务研究[J].软件学报, 2005,16(8):1445-1456.

[9]Sollins K R. Recursively invoking linnaeus: A taxonomy for naming systems[J]. Identification, 2002(3)：1-12.

[10]曹锐,吴建平,徐明伟.互联网命名问题研究 [J].软件学报, 2009(2):363-374.

[11]Winoto WA. The design and implementation of an intentional naming system[J]. Operating Systems Review, 1999,34(5):186-201.