1.4 数据模型是自动化的关键
本节探讨使用不同的协议和数据模型管理网络所面临的挑战。
深入研究数据模型之前,了解信息模型和数据模型之间的差异很重要。
1.4.1 信息模型与数据模型的差异
以下内容来自RFC 3444:
信息模型的主要目标是在概念层面上对被管理对象进行建模,独立于任何具体的实现或用于传输数据的协议。信息模型中定义抽象的具体化(或详细)程度取决于其设计者的建模需求。为了使总体设计尽可能明确,信息模型应隐藏所有协议和实现细节。信息模型的另一个重要特征是它定义了管理对象之间的关系。
反之,数据模型是在较低的抽象层次上定义的,包括许多细节。信息模型和数据模型是为实施者准备的,包括特定协议的结构。
信息模型(IM)与数据模型(DM)之间的关系如上图所示。由于概念模型可以用不同的方式实现,因此可以从单个信息模型推导出多个数据模型。
IM的主要作用是让设计者描述被管理的环境、让操作者理解被建模的对象、让实施者指导必须在DM中描述和编码的功能。文献中经常使用的术语“概念模型”和“抽象模型”与IM有关。IM能够以不同的方式实现并映射在不同的协议上。IM是协议中立的。
信息模型的一个重要特征是它们可以(通常应该)指定对象之间的关系。组织可以使用信息模型的内容来划分可包含在DM中的功能。
信息模型可以使用自然语言(例如英语)以非正式的方式定义。或者可以使用正式语言或半正式的结构化语言来定义信息模型。正式指定信息模型的一种可能性是使用统一建模语言(UML[33])的类图。UML类图的一个重要优点是以标准图形方式表示对象及其之间的关系。基于这种图形化的表示方式,设计者和操作者可能会发现理解对基础管理模式的概述更容易。
与信息模型相比,数据模型在较低的抽象级别定义托管对象,包括特定于实施和协议的详细信息(例如,解释如何将托管对象映射到较低级协议架构的规则)。
大多数标准化的管理模式都是数据模型。包括如下例子:
- 管理信息库(MIB)模块,使用SMI指定。
- 通用信息模型(CIM)模式,在分布式管理任务组(DMTF)内制定。DMTF以图形和文本两种形式发布。图形形式使用UML类图,没有标准化(图形不能表示全部细节)。
- 考虑到数据模型和信息模型的定义,作者认为IPFIX信息模型(RFC 7102)应称为“数据模型”。
运维工程师需要将网络作为一个整体进行管理,独立于用例或管理协议。这里有一个问题:不同的协议会产生不同的数据模型,以及不同的方法来模拟相同类型的信息。
1.4.2 用不同的数据模型管理网络的挑战
作为本节其余部分使用的一个示例,我们通过不同的协议和数据模型以及NMS面临的挑战,来查看简单“接口”概念的管理。
ifIndex定义来自接口组MIB(RFC 2863)
“每个接口的唯一值都大于零。建议从1开始连续分配值。每个接口子层的值至少从网络管理系统的首次初始化到下一次重新初始化之间须保持恒定。”
图1-8描述了RFC 2863中的Interfaces MIB模块中的interfaceIndex,图1-9显示了ifEnter,图1-10显示了ifTable,图1-11显示了ifAdminStatus,图1-12显示了ifOperStatus。
图1-8 接口组MIB模块中的接口索引
图1-9 接口组MIB模块中的条目
接口管理状态使用ifAdminStatus对象设置,而相应的操作状态使用ifOperStatus对象读取,具有相同的ifIndex值,如图1-10所示。
图1-10 接口组MIB模块中的ifTable
图1-11 ifAdminStatus在接口组MIB模块中的应用
图1-12 ifOperStatus接口组MIB模块
请注意,只有ifOperStatus英文说明是两个重要对象之间存在连接的地方:用于配置接口状态的ifAdminStatus和用于监视有效接口状态的ifOperStatus。这凸显了SNMP的另一个重要缺点:工具不会自动推断预期状态和应用状态之间的映射。仔细检查描述条款会发现该信息,但这需要对MIB内容有广泛的了解。反过来,此映射必须在基于SNMP的NMS中进行硬编码。
并非受管设备上的所有接口计数器都可通过MIB模块调用。例如,接口负载不可用,如示例1-5所示。
示例1-5 接口负载
在这种情况下,运维工程师必须轮询多个对象以推断出负载,如以下代码片段所示:
utilization = (ifInOctets + ifOutOctets) * 800 / hour / ifSpeed
另一种方法是使用show interfaces命令对值进行“抓屏”,但要实现全部“抓屏”则困难重重。
在其他情况下“抓屏”是唯一的解决方案。例如,Cisco ASR1000设备在ASIC级别提供了一些Cisco QuantumFlow处理器(QFP)计数器:这些计数器不能供MIB模块使用。因此,在SNMP上NMS需要“抓屏”。
现在,假设相同的NMS必须将SNMP信息与syslog消息相关联,这不是一件容易的事!如本章前面“syslog:限制”部分所述,纯文本格式的syslog消息基本上是freeform格式的文本。为了方便用户使用,在与接口相关的syslog消息中使用了与ifIndex相反的接口名称,如示例1-6所示。
示例1-6 接口关闭syslog消息
NMS必须首先从syslog消息中提取接口名称——这同样不容易,因为在业界并没有为接口命名的惯例。syslog消息可能包含“GigabitEthernet0/1”或“GigE0/1”“GigEth 0/1”或其他任何变体,这使得正则表达式搜索变得复杂化。一旦完成后,NMS必须将接口名称与另一个代表接口名称的MIB对象ifName关联起来。当且仅当受管设备对ifName和syslog消息保持相同的命名约定(不是给定的),此操作正常。当从MIB、CLI和syslog消息开始处理不同的协议和数据模型时,NMS会变得很复杂。
假设同一个NMS要结合流量相关用例,必须集成NetFlow或IPFIX流量信息。该NMS应用需要映射一个不同的数据模型,即NetFlow/IPFIX。在指定IPFIX信息元素的同时,设计者仔细地将IPFIX的定义与ifIndex MIB的ifIndex值对齐。但是,接口组MIB模块未将方向的概念指定为接口属性。相反,ifTable中的八位字节计数器会将单播和非单播数据包的八位字节计数汇总为每个方向(接收/发送)的单个八位字节计数器。另一方面,IPFIX需要有接口方向的概念:在入口或出口接口上能观察到流记录吗?与SNMP世界中唯一的ifIndex对象相反,接口定义中的语义略有不同,导致产生了两个不同的IPFIX信息元素。IANA注册表[34]中指定的两个IPFIX信息元素是ingressInterface和egressInterface,如示例1-7所示。
示例1-7 ingressInterface和egressInterface IPFIX定义
NMS使用MIB对象映射IPFIX流记录,必须对该MIB-object-versus-IPFIX-information-elements映射进行硬编码。
现在在AAA(授权、认证和计费)世界中,该接口的建模方式也有所不同,端口代表用户尝试进行身份验证的接口。在RADIUS(远程身份验证拨入用户服务)协议(RFC 2865)中,接口概念被指定为“NAS端口”[35],如示例1-8所示。
示例1-8 RADIUS NAS端口接口定义
在TACACS+(终端访问控制器访问控制系统Plus)中[36],接口再次以不同的方式建模,如示例1-9所示。
示例1-9 TACACS+端口和port_len接口定义
要与MIB和IPFIX世界集成身份验证、授权和计费的NMS,必须对数据模型映射和语义映射进行硬编码。
NMS必须集成MIB模块、CLI、syslog消息、NetFlow和IPFIX以及AAA协议(例如RADIUS和TACACS+)的信息,此示例显示了处理不同数据模型的一些困难,这些数据模型显然不使用相同的语法和语义。一个基本的“接口”概念从信息模型的角度来说即使非常清楚,也会给NMS的实现带来很大的复杂性。图1-13是此示例中使用不同数据模型的接口定义摘要,不包括CLI,CLI可能没有数据模型。
图1-13 接口对象信息模型及相关数据模型
从不同的趋势可以看到CLI不再是标准的分支。软件定义的网络和DevOps需要具有众所周知的语义,以及清晰的具有一致语法的API。这导致数据模型驱动的管理时代的到来。事实上,如果没有一致的数据模型,基于意图的网络即便不是不切实际且不可能,也是极端困难的。再往前走一步,机器学习是未来几年的另一个重要趋势,如果没有数据模型提供一致的信息,包括一致的语法和语义信息——那么机器学习就会没有合适的输入。