《云数据中心网络与SDN：技术架构与实现》——2.3.4　设备配置可编程

2.3.4　设备配置可编程

1. CLI

这个话题可算是老生常谈了。CLI于网络非常重要，尤其是对于运维，很多时候都需要逐台设备地show，然后靠经验来定位问题。不过，如果敲CLI非要到设备前去插console口连，那实在是一件没有效率的事情，设备多了，人力的成本太高。最早的远程登录技术是Telnet，运维用自己本地的一台服务器就可以登录到远端的设备上去敲命令行。不过Telnet是明文传输，命令很容易被截获和篡改，后面为了安全提出了SSH。几乎所有的网络设备都支持Telnet和SSH，有了远程登录就可以写一些自动化的工具用于设备的集中式管理了。基于shell来写VLAN、ACL，可以说是网络运维的基础技能了。

远程登录只是个简单的通道，设备上有什么就只能用什么。而RPC（Remote Procedure Call，远程过程调用）可以使得这个远程通道上有一些自定义的能力，在远端可以任意地调用这些能力。相比于SSH+shell，RPC+高级编程语言能够描述更为复杂的运维逻辑，但是RPC需要对设备端的系统进行升级，传统的网络设备都不支持。随着云计算的发展，自动化变得越来越重要，Devops概念日渐盛行，数据中心的网络运维自然也要向更好的自动化方向发展。目前流行的Devops工具，包括基于RPC+Ruby的Puppet/Chef以及基于Python+SSH的Ansible，已经被广泛地用于云中，网络设备为了支持与云中其他资源的联合编排，也开始在设备中集成这些能力。

无论是传统的SSH+shell还是目前的Devops，只是CLI多穿了一件衣服，那么它们算不算是SDN呢？从严格的意义上来讲自然不是，大抵上只能归为自动化运维。不过，目前很多SDN控制器还在大量地使用CLI，这并不是因为SDN控制器的能力不行，而是由于厂商设备对其他接口协议的支持时至今日仍然不够成熟，很多情况下只有用CLI才能解决实际的问题。

CLI用在SDN中，最大的问题有两个：①不支持事务性配置，虽然可以通过RPC来包装一些状态机制，但是没有形成标准化；②机器的可读性很差，程序想要看设备的状态只能用show，返回来一大堆字符串根本不适合机器去做解析。为了在SDN中更好地对设备进行管理和配置，必须要解决CLI存在的这两个问题，目前以NETCONF为OVSDB最为常见。

2. NETCONF/YANG

NETCONF并不是什么新鲜的东西，Juniper从2003年开始提，2006年就出了RFC第一稿。从配置的角度来看，做网络实际上就是在配置一个分布式的数据库，网络的正常运行依赖于不同设备上数据间的配合，因此一个好的网络配置协议需要有良好的机制来维护这些数据的状态。SNMP已经被证明只适合做监测而不适合做大规模的配置，Puppet这些为IT编排而生的工具在网络领域也并不够专业，因此上述机制的实现需要新设计一套专用的、标准化的RPC。NETCONF就是为此而生的，NETCONF的RPC能够实现诸多良好的状态特性，比如配置的分阶段提交、分时生效、回滚、持久化，以及数据的加锁等。有了这些专用的RPC，网络配置的底层语法是做好了，但光有底层是不够的，还需要有合适的高层语言来对网络配置的语义进行统一的建模。相比于SNMP BER的人不可读性以及CLI 字符的机器不可读性，NETCONF在数据格式上选用了人类和机器均可读的XML，XML自身有建模语言XSD和DSDL，然而它们都是为静态文档设计的，不能有效地满足NETCONF对语意的要求，于是YANG被提出并成了NETCONF指定的数据建模语言。

NETCONF确实是个非常好的配置协议，良好的事务性设计使得NETCONF有能力集中式地把网络和业务给配起来的。再加上YANG提供的可扩展性，理论上只要厂商愿意做扩展，那么用NETCONF配置BGP路由表、MPLS标签转发表甚至OpenFlow流表都是可行的。不过由于XML解析的速度存在瓶颈，再加上支持事务性对于数据库的影响，因此NETCONF还是更适合实时性要求不高的配置类工作，而不适合对实时性要求较高的控制类工作。

不过，对于YANG实际上是存在很多争议的。YANG第一稿RFC的提出是在2010年，当时业界并没有引起什么轰动，只是知道这是为了NETCONF新设计的一个建模语言。YANG的全称是Yet Another Next Generation，可相比于SMI、XSD和UML，除了改变了语法并做了一些简化以外，在网络领域YANG似乎也没有表现出什么明显的技术优势。被OpenDaylight采纳用于MD-SAL APP的建模，成了YANG的一个重大转折。对于传统网工来说，YANG module和SNMP中的MIB路子类似，相比于OpenFlow中全新的资源模型来说要好接受一些，再加上OpenDaylight提供的YANG-TOOLs能够实现YANG module到Java的自动映射，进一步省去了网工们在编程语言上的学习成本。随着OpenDaylight的推广，YANG顺理成章地火了一把。

不过YANG在一个地方是有优势的，那就是它在IETF的网管专业有一个专门的工作组，负责提出标准的YANG模型来增强各个厂家的互操作性，以便未来对网络进行统一的建模。对于运营商和OTT来说，这自然是求之不得的，但大多数厂商对这件事其实是没有什么感觉的，虽然本质上设备里还是那么一套东西，但真要改造起来可是个巨大的工程。除非用户要求，否则既然之前没有开放给你，为什么现在要主动开放给你？不过，统一YANG模型这件事对于网络的用户来说意义重大，还是需要用户主动去推进，然后从市场层面来带动厂商。总体来说，这件事在大形势上是乐观的，但统一究竟要花上多长的时间，还要看各方的博弈。值得一提的是，OpenConfig作为一个由Google主导、致力于YANG标准化的开源项目，可以进行长期的关注。

NETCONF还有一个小兄弟叫RESTCONF，数据建模还是用的YANG，不过把NETCONF的RPC映射到了RESTful API。其好处是HTTP的通用性更强，缺点是RESTful的操作受限于CRUD，相比于RPC在灵活性上有很大差距，因此在映射RPC的过程中损失了NETCONF的一些优秀机制，如数据加锁等。RESTCONF的流行同样也是受OpenDaylight所提携，当然也得益于它自身操作上的简单性。

3. OVSDB

除了NETCONF/RESTCONF以外，OVSDB也是比较流行的配置协议。实际上这个说法是有一点问题的，OVSDB是OVS的数据库，它的管理协议在RFC中叫作“The Open vSwitch Database Management Protocol”，这里讨论的是后者，下面将其简称为OVSDB MgP。OVSDB是一个关系型的数据库，支持事务，具备ACID的特性，因此OVSDB MgP对于事务也有着良好的支持。OVSDB MgP相比于NETCONF，RPC方面是类似的，数据格式上用的是JSON解析的速度比XML还要快一些，由于OVSDB MgP是专门为了OVSDB设计的，而OVSDB中的表以及表间关系都是固定的，因此OVSDB MgP也没有绑定专用的数据建模语言。

对于OVSDB MgP，同样有几个常见的误解。

OVSDB MgP只能配虚拟交换机。很多白盒厂家都是基于OVS来做设备的OS的，因此白盒基本上都支持OVSDB MgP。一些传统厂商如Juniper、Arista的设备虽然不是基于OVS的，但也都支持OVSDB MgP，主要是为了和对接虚拟化环境做裸机的接入。

OVSDB MgP只能配端口、隧道这些，没有办法配流表或者转发表。RFC里面没有对数据模型做限定，通过扩展两端的OVSDB Server和Client，是可以通过OVSDB MgP交互任何信息的。

OVS就是OpenFlow交换机，OVSDB MgP必须配合OpenFlow使用。不连接控制器的时候，OVS可以当做一个传统的二层交换机来用，然后用OVSDB MgP进行统一配置端口、VLAN，不需要依赖于OpenFlow。而且根据上一条中所说，对OVSDB扩展后OVSDB MgP是可以配置流表的，很多SDN方案里面只有OVSDB MgP，而没有使用OpenFlow。

另外，OF-CONFIG和OVSDB MgP两者都可以用来配置OpenFlow交换机，因此也是比较容易混淆的。OF-CONFIG是ONF为OpenFlow配套提出的管理协议，OF-CONFIG用的是NETCONF的RPC，在上面做了自己的数据模型，和OpenFlow是强绑定的。OVSDB MgP是IETF中为OVS设计的管理协议，有自己的RPC，数据模型依赖于OVSDB，和OpenFlow没有强绑定关系。

关于设备配置可编程，最后再说一点。虽然提到网络配置通常是对交换机、路由器这些进行配置，但上述所提到的脚本、Devops、NETCONF/RESTCONF、OVSDB也是可以用来配置控制器的，数据模型建好了都是可以做的。但也千万不要被一些“NETCONF万能论”的说法搞晕了，真正做控制该用OpenFlow还用OpenFlow，该用BGP还用BGP。