2.4　自动化的关键？数据模型

如小节名所示，在数据模型驱动的管理中，最基本的部分是数据模型的集合。从数据模型推导出API。图2-2显示左侧的YANG数据模型（已授予，虽不完整但现在够用）和右侧用以管理各个资源的RESTCONF远程过程调用（GET、POST、PUT和DELETE）。注意RESTCONF操作是如何从YANG模块关键字构建的，其显示了如何从YANG模型生成API。

讨论数据模型如何生成API是再次强调信息模型和数据模型之间差异的一个很好的环节。如1.4.1节（RFC 3444）所述，信息模型的主要目的是在概念层面上对托管对象建模，而不依赖于传输数据的任何特定实现或协议。根据YANG模块图，一个额外的区别是数据模型生成API。这是一个关键信息：自动化是由API驱动的（而不是作为达到目的的手段的模型）。通常用统一建模语言（UML）表示的信息模型不会生成完整的API，因为它们缺少一些特定于实现和协议的详细信息（例如，解释如何将托管对象映射到较低级别协议结构的规则）。然而，从UML生成API是一个研究和实验领域。在作者看来，如果信息模型包含生成完整API的所有信息，那么该信息模型实际上是一个数据模型。

为了更具体地了解信息模型和数据模型之间的区别，我们来举个例子。UML信息模型可以声明图书对象应该具有标题、作者、ISBN、语言和价格属性。可以说标题应该是字符串，作者应该是对作者对象的引用，价格应该是数字类型。

要将UML信息模型转换为数据模型，你需要添加其他信息，例如ISBN需要遵守非常特殊的格式才能有效，作者关系是强制性的，而语言不是强制性的，或者书籍价格为零的情况下不符合销售条件。你还需要说明，需要有一个名为目录的书籍列表，并且该列表将按标题索引。只有在添加此类详细信息后模型才可用作API，即客户端和服务器之间的合约，其中，两个对等方都知道需要什么并实施什么。

2.4.1　YANG和运维人员的需求

YANG语言解决了“2002年IAB网络管理研讨会概述”（RFC 3535）中提出的许多问题，如“使用NETCONF和YANG的网络管理架构”（RFC 6244）中所述。根据RFC 6244，创建YANG语言是为了满足以下要求：

• 易于使用：YANG被设计为人性化、简洁、易读。由于问题领域的复杂性许多棘手的问题仍然存在，但YANG努力使这些问题更明显、更容易处理。
• 配置和状态数据：YANG明确区分配置数据与其他类型的数据。
• 生成增量：YANG模块提供足够的信息，以生成两个配置数据集合之间变化所需的增量。
• 文本友好：YANG模块对文本非常友好，正如它们定义的数据一样。
• 面向任务：YANG模块可以将特定任务定义为RPC操作。客户端可以选择调用RPC操作或直接访问任何基础数据。
• 完全覆盖：可以定义YANG模块使设备的所有原生功能完全覆盖。提供使用Expect[EXPECT[14]]等工具可避免求助于命令行界面（CLI）的访问。
• 及时性：YANG模块可与CLI操作相关联，可立即得到所有本地操作和数据。
• 实施难度：YANG的灵活性使模块更易于实施。添加“功能”并使用自然数据层次结构替换“第三范式”，可以降低复杂性。YANG将实现复杂性从客户端转移到服务器，而SNMP对于服务器来说是简单的。事务是客户端简化的关键。
• 简单的数据建模语言：YANG有足够的能力在其他情况下使用。具体而言，可以集成本地API和原生CLI以简化基础设施。
• 人类友好的语法：YANG的语法是为读者特别是审阅者而优化的，因为这是人类最常见的交互。
• 语义失配：更丰富、更具描述性的数据模型将减少语义不匹配的可能性。由于能够定义新的原语，YANG模块的内容将更加具体，允许更多的规则和约束的执行。
• 国际化：YANG使用UTF-8（RFC 3629）编码的Unicode字符。

2.4.2　良好数据模型的属性

设计良好的管理接口（或API合约）有许多方法，但设计糟糕接口（或API合约）的方法更多。就像在编写好合同时需要寻找某些属性一样，在设计界面时需要寻找某些东西。事实上这两种活动的好属性列表基本相同，如下面的项目列表所示。为了说明这一点，以下要点摘自法律网站www.ohiobar.org。这就像设计一种特定域的语言（DSL），包含动词、名词、形容词等，加上用于说明如何组合这些元素的语法规则。最有表现力的语言也是最有用的，通常只有相对较少的单词，但集中在如何将这些单词组合成几乎无限数量的不同信息。

• 准确：合同最重要的方面是准确，从而使另一方的反应可以预测。如果除了合同中提到的条款之外还有许多例外情况（如果、当……时和例外），合同就会失去价值。合同需要正确使用相关术语，准确，涵盖所有案例。
• 明确：除非所有各方在阅读合同时达成相同的理解，否则互操作性将不会发生。语言需要明确、内部一致，并且使用熟悉的术语。文档的结构必须以易于使用的方式构建。缺省使人们更清楚地知道，当一个简短的信息没有提到任何事情时，将会发生什么。一致性限制说明了如何构建有意义的消息。
• 效率：确保合同不被阅读的传统方法是使合同变得非常长。一个更可靠的方法是开始自我重复。当相同的冗长的措辞出现在章节后面，可读性和可维护性就会丢失。重复模式是伟大的，但只有当引用和重复使用，而不是重复的每一次。
• 简洁：虽然使用复杂的业内术语和语言很有诱惑力，但通常最好为更广泛的受众撰写，而这些受众可能不了解合同所涉及的主题。另一个重要的简单性方面是用最不惊讶的原则（又称：最不令人意外的原则）如果某种东西打破了一个既定的模式，要么重新设计，要么让它显得与众不同。
• 共振：确保合同紧扣主题。如果主题广泛，一个整体中的几个模块化合同可能使其更易于使用。合同应明确说明合理的违约，允许双方懒惰。合同需要考虑双方的需要和术语（如果超过两个，则考虑全部）。

虽然YANG具备上述属性，但此时你可能会疑惑，为什么是YANG而不是另一种模式语言—例如分布式管理任务组（DMTF）中指定的通用信息模型（CIM）？一个务实的答案是，YANG被定义为NETCONF协议的建模语言，尽管与其他建模语言相比YANG有利有弊，但IETF社区的设计人员选择了YANG。

2.4.3　不同类型的YANG模块

随着YANG作为一种建模语言的成功，业界正在创建许多YANG模型以简化自动化。YANG模块有三个不同的来源：

• 标准制定组织（SDO）
• 联盟、论坛和开源项目
• 原生/私有YANG模式

第6章详细介绍了YANG数据建模在行业中的发展，在本章中我们只介绍并比较前三个类别。本节的目标是从YANG模型的视角出发强调一些不同。

作为制定YANG语言的标准制定组织，IETF是最初制定YANG模块的SDO，首先是NETMOD工作组，然后是具有特定专业知识的不同工作组。不同的SDO遵循这一趋势，包括IEEE和ITU-T[15]。

此外，一些联合会、论坛和开源项目也为YANG模型的开发做出了贡献。仅举几个例子，OpenConfig[11], MEF[16], OpenDaylight[11], Broadband Forum[17]和OpenROADM[18]都做出了贡献。

SDO生成的YANG模块受到了最多的关注（至少对于IETF来说，本书作者参与其中），同时被许多人审查。这一审查过程的代价是花很长时间来完成规范。在围绕这些YANG模块开发应用程序时，必须了解它们包含一种共同点，而不是完全覆盖不同网络供应商提出的不同实验性或私有的功能。这些实验性和私有特性的扩展必须在标准YANG模型的基础上开发。

另一方面，由联盟、论坛和开源项目生成的YANG模型大部分时间都是针对特定的用例的，因此提出了完整的解决方案。当以用例为中心时，少数提交者保持了不同YANG模型的一致性，从而保证了整个解决方案的一致性。根据经验，YANG模块的快速迭代当然会提高交付速度，但对于必须始终保持其开发与版本最新的实现者来说，这可能是一种负担。注意，在开源项目中，代码是在YANG模型之后提出的。在所有的开源项目中，Open-Config值得一提，因为它在业界获得了一些关注（第4章对此有更多介绍）。

最后一类是“原生YANG模型”，也被称为“私有YANG模型”。为了提供一些全覆盖的自动化（对于整个被支持的功能集），一些网络供应商基于其私有实现提出了YANG模型。大多数情况下，这些YANG模型是从内部数据库或CLI表示生成的，这意味着跨供应商的自动化是困难的。在生成的YANG模型的情况下，另一个潜在的问题是新的软件版本可以生成不向后兼容的YANG模块，从而映射内部向后不兼容。根据YANG规范，如果发布的模块有可能导致使用原始规范的客户端和使用更新规范的服务器之间的互操作性问题，则不允许对它们进行更改。换言之，如果有不向后兼容的更改，则需要新的模块名。然而，在实践中这一规则并不总是被遵守。因此，IETF正在讨论修改YANG模块更新过程（即，放宽有关记录非向后兼容更改的条件规则）。

业界已经开始在GitHub中[https://github.com/YangModels/yang]集中放置所有重要的YANG模块，还有图形界面YANG Catalog[https://yangcatalog.org/][19]。如果你不知道从哪里开始，这是两个很好的起点。

2.4.4　从MIB模块映射YANG对象

本节将讨论从基于管理信息（Management Information Based, MIB）的模块转换为YANG模块，在此之前，你应该注意到它引用了本章稍后部分和后面两章中介绍的一些技术概念。由于在本书后面没有其他合适的地方讨论从MIB模块映射YANG对象，建议你在掌握YANG和NETCONF之后重新阅读本节。

IETF开始建模工作时，SNMP协议中没有YANG模块（尽管MIB模块很多）。如前所述，许多MIB模块被广泛用于网络管理中的监控。因此，发明一种方法来利用SNMP的优点并将MIB模块转换为YANG模块是很自然的。

“将管理信息版本2（SMIv2）MIB模块的结构转换为YANG模块”（RFC 6643）描述了将SMIv2（RFC 2578、RFC 2579和RFC 2580）MIB模块转换为YANG模块，从而允许通过NETCONF对SMIv2 MIB模块中定义的SMIv2对象进行只读访问。虽然这种转换对于通过NETCONF访问MIB对象有很大帮助，但其作用仍然有限。

首先，将SMIv2 MIB模块转换为YANG模块的结果，即使SMIv2对象是读写或读创建的，由只读的YANG对象组成。一个原因是底层协议SNMP和NETCONF的持久性模型有很大的不同。使用SNMP，可写对象的持久性取决于对象定义本身（即DESCRIPTION子句中的文本）或其所属概念行的持久性属性，有时使用StorageType文本约定通过列对象进行控制。使用NETCONF，配置对象的持久性由底层数据存储的属性决定。此外，在RFC 6241中定义的NETCONF不提供修改操作状态的标准操作。<edit config>和<copy config>操作仅操作配置数据。你可能会说读-写或读-创建对象的映射是一个没有实际意义的问题，因为MIB模块中没有太多对象。这是正确的。请记住，MIB模块在监控方面做得很好，但并没有成为配置网络的标准。

其次，使用MIB转换的YANG模型和YANG定义的模型仍然会引起数据模型映射的一个基本问题，因为MIB和YANG中对概念对象的指定不同。“将管理信息版本2（SMIv2）MIB模块的结构转换为YANG模块”（RFC 6643）可能有助于创建YANG模块。在实践中，通常创建新的数据结构，而不是混合使用手动编辑（在MIB数据命名与YANG数据结构不一致，或是可写对象的情况下）和自动生成的YANG模块。例如，YANG接口管理（RFC 7223）采用了这种方法。