【连载-4】数据中心网络虚拟化 配置管理技术

在构建虚拟网络时，管理员需要进行大量的配置工作，例如端口的ip地址和VXLAN配置等等。显然，没有人愿意在系统每次启动时都将繁琐的配置工作重复一遍，所以将配置信息持久化是必然选择。然而在配置信息持久化之后，如何读取、写入和更新配置信息则是系统设计师需要仔细考虑的问题。简单来说，网络配置与管理协议的本质为远程过程调用，即RPC（remote procedure call）。通信双方通过交互<rpc>和<rpc-reply>消息完成这一过程。本节我们将针对一些常见协议进行讨论，包括OVSDB管理协议、NETCONF协议、OF-CONFIG协议和RESTCONF协议。

1

OVSDB

如图1所示，Open vSwitch的数据库为ovsdb（Open vSwitch Database），该数据库由两个主要部分构成，即ovsdb-server和ovsdb-client。Ovsdb-server是OVS的数据库服务器端，位于Open vSwitch本地。Ovsdb-client则为OVS数据库客户端，其通过OVSDB 管理协议（Open vSwitch Database Management Protocol）[1]向ovsdb-server端发送数据库配置和查询的命令，即ovs-vsctl命令。因此，ovs-client又被称为管理者。ovsdb-client通常运行在Open vSwitch 本地，即管理员可以在OVS本地以命令行方式输入数据库配置和查询命令。另外，ovsdb-client也可以部署在远端，从而实现对ovsdb-server的远程配置。本专题第二期讨论的Nicra公司的NVP平台正是采用此种方式来实现中央控制器对网络边缘层的配置。目前在Opendaylight控制器中也有一个单独的子项目实现此管理协议，即OVSDB[2]。

图 1. 控制器通过OVSDB管理协议与OVS交互示例[1]

网络配置与管理协议目的是要实现网络设备的远程配置，因而其核心即为远程过程调用，例如XML-RPC、JSON-RPC和JAVA-RPC。OVSDB使用JSON [RFC4627] 作为其数据库存储格式，并且使用轻量级的JSON-RPC 1.0作为配置和管理协议。

基于JSON-RPC协议，每个请求格式如下：

{"method": "sayHello", "params": ["Hello JSON-RPC"], "id": 1}

其中，每个参数的含义为：

✔ method： 调用的方法名

✔ params： 方法传入的参数，若无参数则传入[]

✔ id ： 调用标识符，用于标示一次远程调用过程

服务器收到请求之后，调用消息中指定的“method”方法，并将参数“params”传入，最后在方法执行完毕后，利用下面的消息格式将结果返回给调用者。响应的“id”与请求的“id”必须相同，从而标识同一次RPC调用。

{

"result": "Hello JSON-RPC",

"error": null,

"id": 1

}

在OVSDB中定义了多个RPC方法，包括：

1)list_dbs：获取网络设备中的所有数据库名称

2)get_schema：获取数据库模式

3)transact：使数据库服务器在指定的数据库上按一定顺序执行相应操作

4)cancel：要求数据库服务器要么立即完成一个transact，要么将该transact取消

5)monitor：使客户端可以监控数据库某些表的某些关键列的值，当指定表的某些行的这些列发生了变化时，例如修改和删除等，则发送通知给客户端

6)update notification：当数据库的表发生更新时，由数据库服务器发给远程客户端

7)monitor cancellation：取消之前的某个监控请求

8)lock：为防止多个客户端同时对一个数据库操作而产生错误，可以将数据库锁定。

实现远程配置管理最主要的方法是transact，其用于指导数据库服务器以一定顺序执行某些指定的操作，参数如下所示：

"method": "transact"

"params": [<数据库id>, <操作>*]

"id": 一个非空值

我们可以发现，在transact方法的参数中首先需要指明数据库名称，然后跟一个或多个数据库操作，其中每个操作为一个JSON对象。此方法之所以称为transact是因为这些操作是作为一个事务来执行的，即当且仅当该方法的所有操作都成功执行，该方法才能提交。在transact方法中定义了如下操作：

1)Insert操作，其用来在数据库中插入一行。具体格式如下：

✔ "op": "insert"

✔ "table":<table>（指该表的id）

✔ "row":<row>（为一个JSON对象，成员为列的名称和值构成的对）

✔ "uuid-name":<id>其中，“row”指定插入行的各列对应的值（未被指定的列使用缺省值）。rpc-reply中返回uuid。

2)Select操作：选择满足请求中给定条件的那些行，在rpc-reply中返回选择的那些行。

3)Update操作：更新满足请求条件的那些行，rpc-reply返回满足条件的行的数量。

4)Mutate操作：与update相似，但区别是update用请求中指定的一个新的行更新满足条件的所有行，而mutate则在请求中指定了一组行，用来依次变新满足条件的行。

5)Delete：删除满足条件的那些行。

6)Wait操作：等待操作,此操作有2个成功退出的可能,即预设的条件被满足或者timeout。

7)Commit操作：该操作有一个叫做“durable”（持久化）的参数，若该参数设置为真，如果整个事务要提交（commit），则在给客户端发送响应消息前，将整个事务写入磁盘之中。若“durable”设置为假，则此处实为空操作。

8)Abort操作：让整个事务中止（abort），在测试时有用。

9)Comment操作：为数据库管理员提供一个事务的目的（作用）等说明信息。

10）Assert操作：其有一个参数“lock：<id>”,若客户端没有指定名为id的锁，则整个事务中止。

2

NETCONF

NETCONF[3]由W3C提出，是一种基于XML的网络配置管理协议，因此使得其可以表达复杂的层次化数据。NETCONF为一个层次化协议，从下到上共四层分别是：

安全传输层，NETCONF是面向连接的，它要求通信端口之间建立永久性的连接，而且这种连接必须提供可靠的、按序的数据传输。在传输层，NETCONF制定了RFC4742、RFC4743 和RFC4744，其分别给出了向传输协议SSH、SOAP和BEEP映射的实现方案。这些安全协议通过加密和认证等方法来保证网络连接的安全性。

消息层，NETCONF使用<rpc>和<rpc-reply>元素实现独立于传输层协议的NETCONF请求和响应。

操作层，NETCONF在RPC消息层之上定义了一组操作，用于操作数据库。

内容层，指具体的配置、通知、状态数据。

NETCONF操作层定义了如下操作：

✔ 1)<get-config>操作：获取配置数据。包含两个参数，<source>和<filter>， source用来指定get-config操作对应的配置数据库，filter用来指定需要获取哪部分的配置数据。

✔ 2)<get>操作：获取配置数据和状态数据。

✔ 3)<edit-config>操作：加载一个指定的全部或部分配置到目标数据库。其中，指定的配置有三种存在方式，包括本地文件，远程文件和内联的方式。如果目标配置数据库不存在，则会被<edit-config>创建。在<edit-config>中最主要的参数是<target>和<config>，target指定目标配置数据库，<config>中指定配置数据。在<config>中可指定“operation”属性,例如合并（merge）、替换（replace）、创建（create）、删除（delete）和去除（remove）。其中，create是在目标数据库上添加指定的配置部分，当且仅当目标数据库中本来不存在这一部分，否则，就会返回<rpc-error>。delete和remove的唯一区别在于，当目标配置数据库上没有要求的数据，delete会返回一个<rpc-error>消息，而remove则不作任何处理。可以看到，NETCONF的<edit-config>操作通过支持以远程文件或内联方式可以远程操作数据库。

✔ 4)<copy-config>操作：用一个完整的数据库替换现在的数据库。有两个参数，<target>和<source>，分别指目标数据库和源数据库。

下面通过一个例子来看看NETCONF是如何工作的。首先<rpc>消息中指明该请求为<edit-config>操作。按照上面的介绍，<edit-config>操作包括两个重要参数<target>和<config>。下例中的<target>指明本次操作的目标是所有运行中的数据库。而<config>参数则告诉我们这次操作的类型是replace，而修改的目标配置信息，例如mtu和网络地址，则以内联的方式提供。待数据库完成操作后，返回<rpc-reply>消息，并且通知请求方操作已成功执行。为了唯一标识rpc请求，返回消息与请求消息的id应该相同，例如本例中的id均为101。

<rpc message-id="101" XMLns="urn:ietf:params:XML:ns:netconf:base:1.0">

<edit-config>

<target>

<running/>

</target>

<config XMLns:xc="urn:ietf:params:XML:ns:netconf:base:1.0">

<top XMLns="http://example.com/schema/1.2/config">

<interface xc:operation="replace">

<name>Ethernet0/0</name>

<mtu>1500</mtu>

<address>

<name>192.0.2.4</name>

<prefix-length>24</prefix-length>

</address>

</interface>

</top>

</config>

</edit-config>

</rpc>

<rpc-reply message-id="101" XMLns="urn:ietf:params:XML:ns:netconf: base:1.0">

<ok/>

</rpc-reply>

3OF-CONFIG

OF-CONFIG协议全称OpenFlow Configuration Protocol[4]，由ONF（Open Networking Foundation）提出，其作用是提供一个开放接口用于实现对OpenFlow交换机远程管理，例如在OpenFlow交换机内配置控制器IP地址、以及对交换机的各个端口进行enable/disable操作。OF-CONFIG协议基于NETCONF协议实现，依赖于NETCONF的操作和传输标准，区别在于OF-CONFIG关注于OpenFlow设备配置，其在NETCONF的内容层中定义了OpenFlow数据元素（XML element），例如OpenFlow控制器，OpenFlow端口，OpenFlow队列。换句话说，OF-CONFIG定义了消息中包含的用于OpenFlow配置的XML元素的格式。

图2所示，OF-CONFIG中用来配置交换机的应用称为OpenFlow配置点（OpenFlow Configuration Point）。OpenFlow配置点操作的对象称为OpenFlow Capable Switch，它包含多个OpenFlow Logical Switch。如果以Open vSwitch来解释这两者的关系，OpenFlow Capable Switch就是Open vSwitch，而OpenFlow Logical Switch就是Open vSwitch上的每一个bridge或叫datapath（此处虽称为网桥但其本质是Switch）。

图 2. OpenFlow网络中利用OF-CONIFG进行配置和管理示意图[4]

OF-CONFIG的操作包括：

✔ 1)为OpenFlow交换机分配对应控制器。

✔ 2)分配队列和端口。

✔ 3)远程改变端口的一些状态（比如up/down）。

✔ 4)为OpenFlow交换机与控制器的安全通信配置证书。

✔ 5)发现OpenFlow交换机的能力。

✔ 6)为交换机配置隧道（在交换机上表现为逻辑端口）如IP-in-GRE，NV-GRE，VXLAN等。

OF-CONFIG要求支持OF_CONFIG的设备必须实现NETCONF作为传输协议。此外，为了方便编码和解析，OF-CONFIG提供了本协议对应的YANG[5]模块。YANG是一个可扩展的NETCONF数据建模语言，为NETCONF协议、NETCONF RPC、NETCONF通知（notifications）操作的配置数据和状态数据进行建模。其基本结构包括：container, leaf, leaf-list, list。Container不含有值，含一个/多个子节点，只能实现一个实例。Leaf含有一个值，没有子节点，只能实现一个实例。Leaf-list有一个值，没有子节点，可构建多个实例。List没有值，含一个/多个子节点，可构建多个实例。

4RESTCONF

RESTCONF[6]是基于REST模式、用于网络配置与管理的协议，目的在于为WEB应用提供一个获取配置数据、状态数据、通知事件的标准机制。因此，其以HTTP作为传输协议，使用 YANG语言来定义数据结构，并使用NETCONF定义数据存储。其中，数据存储可以通过文件系统、数据库、Flash存储或者它们互相结合来实现。与NETCONF相比，RESTCONF提供的功能较简单，有一些功能它是不提供的，例如不提供对数据库的加锁操作，以及不支持数据库备份。因此，当应用需要使用复杂功能时，仍然需要使用NETCONF。图3提供了NETCONF和RESTCONF的对应关系：

图 3. RESTCONF和NETCONF对比

具体来说，与其他REST协议类似，一个RESTCONF操作是由HTTP方法和被请求资源的URI构成。RESTCONF消息被放置在HTTP消息体中，消息可以使用XML或JSON格式，在请求的Content-Type header处指明是XML格式还是JSON格式。如果消息是从client发出的，那么则必须要指明这个域（缺省是XML）。对于响应，其输出格式则是由请求消息中的accept header指定的（如果没有指定则与请求的编码格式保持一致）。两种消息格式分别对应YANG模块的XML-YANG和JSON-YANG。当数据库创建一个新资源时，会返回一个“Location”头，该头用于标识这个资源的路径。后续对该资源的所有操作，都需要通过这个路径来进行。除了PATCH方法可以操作多个数据存储外，RESTCONF的每个操作都只能限定一个对象。在RESTCONF协议中，操作的对象实际上是层次化的资源，每个资源都代表设备内的一个可管理部件。资源的最高层是API，其对应的URI为 "/restconf"。

RESTCONF的操作格式如图4所示，其中方法（method）为GET、PUT等HTTP方法名，入口（entry）为RESTCONF固定的"/restconf"，资源（resource）为标识资源的表达式，查询（query）为此RESTCONF消息携带的参数（以键值对的形式出现），最后一项“fragment”在RESTCONF中不使用。

图 4. RESTCONF消息格式

5总结

从各网络配置管理协议管理的设备类型对比：OVSDB管理协议针对广泛使用的特定开源虚拟交换机Open vSwitch进行管理和配置； OF-CONFIG协议可对所有支持OF-CONFIG的OpenFlow交换机（软件/硬件）进行配置和管理；NETCONF协议可对所有支持NETCONF协议的网络设备进行配置管理，RESTCONF面向支持该协议的设备。从编码格式上对比：OVSDB管理协议采用JSON交换格式、NETCONF及OF-CONFIG基于XML格式, RESTCONF以XML或JSON作为交换格式。OVSDB管理协议实现早于OF-CONFIG；OF-CONFIG目标是成为OpenFlow交换机配置和管理协议的标准该协议基于NETCONF协议；NETCONF协议是一个稳定的协议，它已经被标准化好几年了，在多种平台上都支持；RESTCONF协议则主要是为WEB应用提供一个标准的获取设备配置数据及状态数据的途径。

参考文献

[1]The Open vSwitch Database Management Protocol RFC7047

https://datatracker.ietf.org/doc/rfc7047/

[2]OVSDB Integration:Main

https://wiki.opendaylight.org/view/OVSDB_Integration:Main

[3]NETCONF Configuration Protocol RFC4741

https://datatracker.ietf.org/doc/rfc4741/

[4]OF-CONFIG 1.2 OpenFlow Management and Configuration Protocol

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1.2.pdf

[5]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) RFC6020

https://datatracker.ietf.org/doc/rfc6020/

[6]RESTCONF Protocol

https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/