1.1 从SDN开始说起

在这几年的IT圈子中，最火的名词有云计算、大数据以及人工智能（AI）。在网络，特别是基础网络圈子里，最火的也许就是SDN与NFV了。我们在全球IT相关的大会中都可以看到它们的身影。在国内，网络厂商的技术交流会，以及互联网公司、运营商、企业的技术分享会都会提到SDN和NFV相关的解决方案。在网络运营与维护工程师聚集的论坛里也经常看到它们的主题。比如，NANOG（北美网络运维论坛https://www.nanog.org）也有SDN与NFV相关的内容。作为在网络行业中工作了近20年的网络工程师，笔者和很多在这个行业中的网络工程师们一样，对于SDN，也许一开始是拒绝的。但是随着SDN的声音越来越大，参与的人也越来越多，很多像笔者一样的网络工程师也开始关注和参与到这个领域。

那么SDN究竟和NetDevOps有什么关系或关联呢？正是SDN的出现和发展，推动了传统网络设备管理维护方式的变革：一方面，SDN让网络工程师不再只依赖CLI命令行（部分Web）方式对设备进行逐台的操作管理，毕竟逐台通过CLI的管理方式是一种非常低效且容易出错的运维方式；另一方面，SDN推动了传统网络设备厂商自身的变革，各厂商开放出更多的API接口，供用户侧进行自动化的编排和调用。自动化这几年的呼声越来越大，自动化上线、自动化部署、自动化运维、自动化修复，甚至还可以和业务进一步结合。实际上，NetDevOps追求的目标就是网络资源的接口化、自动化以及智能化。借助于NetDevOps，我们可以提高运维的工作效率，提升业务部署的准确性，提供网络资源的可编程性。

在正式进入NetDevOps之前，我们先来了解一下SDN的发展状况。无论是SDN具体的技术细节，还是SDN的建设思想，SDN对全球的学术研究机构、标准化组织以及设备厂商都已经产生了深远的影响。了解SDN技术的概貌及其相关的实现架构，有助于我们理解NetDevOps。

1.1.1 OpenFlow打开了新的一扇窗

对于OpenFlow，我想大家应该并不陌生。有人认为OpenFlow是SDN的“Hello World”，也有人觉得它给网络带来了新的活力。众所周知，Martin Casado在斯坦福大学读博士期间领导并开发了OpenFlow协议，当时他的博士导师是Nick McKeown。这个协议不仅定义了网络设备数据转发平面的内容，同时也定义了控制平面的内容。简单来说，通过OpenFlow，可以把控制平面从硬件中剥离出来，可以开发出更加智能、更加集中的控制中心。而转发平面把原来网络设备ASIC等芯片进行了更加高级的抽象化处理，让开发人员不用深入了解硬件底层的处理方式，就能够获得硬件带来的性能。《OF-CONFIG 1.2 ONF TS-0161》白皮书给出OpenFlow高度抽象的逻辑图（见图1-1）。从这个图中，我们可以清晰地看出：OpenFlow协议是OpenFlow控制器与OpenFlow交换机之间通信的协议，而交换机的其他操作使用了OF-Config这个接口协议。如果我们把这个结构映射到传统的路由器或者交换机中，OpenFlow协议可以类比为传统设备的RIB（Routing Information Base，路由信息表）与FIB（Forwarding Information Base，转发信息表）之间的协议。

对于传统的网络设备，这里的通信协议往往是私有的，并没有开放给普通的使用者；而OpenFlow协议则定义了这部分内容。除了OpenFlow协议，OF-Config定义的是如何管理和运维网络设备。OF-Config定义了机器与机器之间的交互方式。它和设备之间的通信使用NETCONF作为底层的通信协议，使用了大量的YANG模型对数据结构进行了定义，并且给出了UML（Unified Modeling Language，统一建模语言）的结构。

OpenFlow协议本身并不是一场变革，它所描述的方式、方法不是传统网络工程师所熟悉的领域，反而是软件工程师所熟悉的领域，它从另外一个视角来描述网络的管理与维护工作。它让传统的人机交互命令演变为控制器与机器之间的交互，从而可以实现集中化、统一化和程序化的网络管理维护方式。

NetDevOps的初衷也是希望通过机器与机器之间的交互来实现更加高效、更加准确的网络管理，而不只限于对网络设备的管理；另外，也希望通过对网络资源进行二次封装，从而为上层应用提供简单灵活的编程接口。

1.1.2 简单聊聊SDN控制器

接着前面谈到的OpenFlow相关的一些内容。OpenFlow自身并没有定义和解决控制平面的问题。在OpenFlow应用场景中，我们通过SDN控制器来保证运行OpenFlow的网络能正常地运作。SDN控制器完成的是控制平面的工作，它是通过软件来实现的。为了满足不同场景的应用需求，控制器的内容会更加抽象化，在表述控制器功能的时候也更加软件工程化。在SDN网络（包括OpenFlow网络）中，和智能相关的内容大部分由SDN控制器（OpenFlow网络对应的控制器通常称为OpenFlow控制器）完成和实现。“控制平面与转发平面分离”是SDN网络与传统网络的主要区别。转发平面常常被定义为毫无智能可言的“傻终端”，完全根据控制平面的指令来进行转发。

在开源的世界里，目前比较主流的SDN控制器如下：

❑ OpenDayLight（https://github.com/opendaylight）；

❑ ONOS（https://github.com/opennetworkinglab/onos）；

❑ Ryu（https://github.com/osrg/ryu）；

❑ Floodlight（https://github.com/floodlight/floodlight）。

SDN控制器软件有很多，上面列出的只是其中很少的一部分。SDN并不是本书的重点，因此也不会在这里详细的展开，有兴趣的读者可以找相关的书籍或者文章进行了解。

在这里，我们以OpenDayLight（简称ODL）为例子简单地看一下SDN控制器的框架设计图（https://www.opendaylight.org/odlboron网站提供了更加清晰的图片）。

从OpenDayLight硼版本框架结构图（见图1-2）中，可以清晰地看出以下几点。

首先，最下方是网络设备，既包括具备OpenFlow功能的设备，也包括Open vSwith这样纯软件的设备，还包括了一些其他的硬件物理设备。

其次，ODL的南向接口（即控制器与网元设备通信的接口）不单单只有OpenFlow与OF-Config，还包括NETCONF、BGP、PCEP、SNMP等多种接口。ODL实现了基于南向接口的网络服务抽象层和基于抽象服务的接口转换。通过这一层的转换，能够让网络设备提供的描述方式和能力转化为面向业务的描述方式及接口。这就方便了应用层的开发人员进行网络相关应用程序的开发，他们并不需要深入了解网络底层的内容。

最后，控制器提供了北向API接口（有RESTful、RESTCONF、NETCONF等接口类型），这是应用开发人员编程所使用的接口。其他更加上层的系统或者平台可以通过调用这些接口来完成其开发，完成应用对网络的调度和管理。ODL提供了GUI的开发框架，应用开发人员也可以基于这个开发框架来开发应用程序，并实现对网络的管理和调用。

总之，SDN控制器软件是应用开发人员和网络设备（无论是硬件的还是软件的）之间的桥梁。通过SDN控制器，应用开发人员可以更多地专注于业务逻辑，从而开发与网络相关的应用程序。因此，在SDN控制器设计的时候，无论是南向接口还是北向接口都会更加关注机器与机器之间的接口。这也许是很多的传统网络工程师感觉SDN控制器比较难学习和难以掌握的地方。正像前面提到的，网络工程师擅长的还是人与机器交互的界面，这也导致了网络工程师在接触SDN控制器时，通常也只是关注SDN控制器所提供的Web UI功能的原因。这样的思路需要转变，无论是SDN还是NetDevOps，都应该更加关注机器和机器之间的接口部分。

1.1.3 NFV

随着SDN（软件定义网络）的发展，NFV（Network Functions Virtualization，网络功能虚拟化）在SDN领域也越来越多地被提及。NFV是ETSI（European Telecommunications Standards Institute，欧洲电信标准协会）在2012年10月发布的白皮书中定义的。但是，NFV这样的产品形态并不是2012年后才有。例如，2006年春季推出的Vyatta OFR是一个软件的路由器，它可以运行在很多的虚拟化的平台上。又如，2009年，Cisco推出Nexux 1000v的虚拟交换机产品，它可以运行在VMware等虚拟化平台上，提供软件交换机的功能。另外，防火墙、负载均衡等领域都有虚拟化软件的产品，如Juniper的vSRX虚拟化和cSRX容器化的软件防火墙产品。ETSI除了概念化了NFV，还定义了NFVI（Network Functions Virtualization Infrastructure，网络功能虚拟化的基础设施）以及NFV-MANO （Network Functions Virtualization Management and Orchestration，网络功能虚拟化的管理与编排）等框架。这些框架为大规模、自动化地部署NFV提供了很好的指导思路与建议。

NFV让网络服务功能的形态发生了不小的变化。现在物理服务器的性能越来越好，单台物理服务器上的虚拟机或容器就可以组成一定规模的小型网络。根据现在服务器的性能及应用的要求，一台物理服务器通常可以虚拟化出10～100台虚拟机。而每台虚拟机又可以有10～100甚至更多的容器。这样，在一台物理服务器上就可以产生100～10000个服务节点。这个规模已经超过了很多小型园区网的规模。物理服务器内部的网络结构也正变得越来越复杂。

在NFV的环境中，为了让服务节点之间的网络更加灵活，引入了VxLAN（Virtual eXtensible Local Area Network）等技术。VxLAN通常应用在Overlay的网络环境中，即在原有的三层网络（IP网络）上又衍生出二层网络，类似传统网络中用GRE隧道方式组成的网络。这里我们不讨论GRE（或NVGRE）和VxLAN两者之间的区别，这并不是本书的重点。Overlay网络中存在着大量非状态的隧道，并且这些隧道的生命周期往往是非常短的。这是因为按需服务的理念使得服务节点虚拟机或容器的生命周期正变得越来越短。

网络功能的软件化与虚拟化使得网络功能部署更加灵活和快捷，这势必会促使NFV软件大规模发展和应用，软件网元数量将会大大超过现在物理网元设备。同时，业务需求的频繁调整和变化，将使得Overlay网络拓扑的生命周期越来越短。管理和维护由软件网元组成的网络将是一个很大的挑战。

1.1.4 云和SDN

“云”应该是大家再熟悉不过的概念了。现在有很多的公有云平台，如美国亚马逊的AWS云平台、微软的Azure云平台以及谷歌的云平台等；国内有阿里巴巴的阿里云平台、腾讯的云平台、百度的云平台以及青云等。另外，大量企业使用了OpenStack、VMware等搭建企业的私有云或公有云平台。在私有云和公有云之间又存在很多混合云的环境。从网络的视角来看，这些云的通信可以分为两大类：一类是云内部的通信。这通常是在一个DC （Data Center，数据中心）内部的通信。另一类是云与云之间的通信。这里有些是私有云之间的通信，有些是公有云平台之间的通信，有些是公有云与私有云之间的通信。这些云之间的通信有些是专门的线路互联，例如，亚马逊的AWS平台就提供直接网络互联的服务。有些是没有专门的链路进行连接的，它们之间通过现在的互联网进行互联。

当计算、存储等资源云化后，这些资源的弹性变大了。换个角度来看，这些资源池所提供的服务节点虚拟机的生命周期也变短了，需要时启用，不需要时释放。这些资源都是网络中的节点，云越多，可用的资源也会越多，并且所有这些资源都会愈加依赖网络进行通信。散布在各地的云资源需要通过网络进行动态的组合，这势必会迫使网络具备动态的调整能力。连接云节点与云节点之间的网络无论是通过底层的物理网络来实现，还是通过上层的软件网络来实现，都需要具有一个供机器管理调用的接口，才有可能实现对网络的监控、创建、修改以及撤销等操作功能。

在网络中传送的数据最终还是会落到物理连接上。因此，物理网络（有时候也把它称为传统网络）同样需要实现更多机器与机器的通信接口。正是像云业务这样上层应用的不断“推动”，才使得网络的接口和自动化能力需要不断提升，从而达到更高的业务敏捷性。同时，软件定义网络技术的发展“拉动”了网络自身的变革。我们可以清晰地看到，网络的变革体现在以下几个方面。

首先，网络管理接口数据结构化，这里比较有代表性的是NETCONF协议的定义以及YANG模型对网络设备的配置与信息输出结果的结构化定义。关于NETCONF协议与YANG模型这两部分的内容，在后续的章节中会进行比较详细的介绍。

其次，在SDN（软件定义网络）中强调转发与控制分离的架构。这种架构实际上是让硬件与软件进行了分离。软件部分的控制器在设计上提供了非常丰富的北向接口。而这些北向接口的定义，都是为了实现机器与机器（程序与程序）之间的通信。当网络设备的API越来越丰富时，在这样的环境中进行自动化运维就不是难事了。

大家也许注意到，刚才一直在说机器与机器通信的问题。正是类似像“云”这样的业务和SDN这样的技术促进了网络设备接口的升级。无论是商业公司的产品还是开源的项目，均提供了比以前更多的机器与机器交互的接口，而不再只是关注人与机器交互的接口。较典型的人与机器交互的接口是CLI（Command Line Interface，命令行）以及Web界面。而这样的接口是很难与另外一台机器进行交互的。只有让更多的机器参与到业务流程中，才能提供更快的效率。网络提供的服务在业务平台的下层，如果网络能够给上层业务应用提供更多的可供机器使用的接口，网络被使用的效率自然也会得到快速提高。

1.1.5 SD-WAN

SDN一直被认为缺少理想的应用场景。而自2014年开始出现的SD-WAN（Software Defined-WAN）正逐渐成为SDN最热门的一种应用场景。截至2017年，业界对SD-WAN的定义还存在着一些分歧，具体可以参考Wikipedia（https://en.wikipedia.org/wiki/SD-WAN）的内容。

在笔者看来，网络从功能、物理规模和特点方面来区分大致可以分为以下三大类。

1）广域网（Wide Area Network, WAN）。Wikipedia给出的定义如下：广域网是指连接不同地区局域网或城域网计算机通信的远程网。广域网通常跨接很大的物理范围，所覆盖的范围从几十千米到几千千米。由于长途链路的成本是这张网络的主要成本，因此这张网络的拓扑结构差异性会比较大。广域网存在链路按需使用的需求，例如早期的ISDN链路就是按时长进行计费的；也存在网络流量调度的需求，即合理地利用现有的链路。Google B4在这个领域做了很多的尝试。

2）园区网络（也称为局域网）。相对于广域网而言，它的覆盖范围通常会比较小，常常仅限于一幢或者几幢楼的内部，并且其带宽相对广域网往往会大很多。园区网的主要功能是提供大量的信息点并管理这些信息点接入的用户，这些信息点可以是一些传感器或者是人机交互的终端。其主要特点是要应对各种各样的接入方式以及安全接入的需求。园区网的网络拓扑相对比较固定，通常是双星形的拓扑结构。

3）数据中心网络（Data Center Network, DCN）。这个网络的物理范围一般会更小，只覆盖一个或数个较近的机房。这个网络的拓扑非常标准化，目前最为流行的设计是SPINE-LEAF的结构，设计完成后几乎不会有大的变动。其主要的特点是为服务器和服务器之间的通信提供高速的带宽，通常也称之为横向流量带宽。

而SD-WAN首先要解决广域网的互联互通，其次需要满足网络的快速开通与灵活部署，另外还要解决一些广域网优化的问题。SD-WAN会大量引入NFV, NFV的灵活性在1.1.3节中有介绍。如何快速部署业务、如何管理网络节点、如何检测广域网的通信质量、如何优化广域网的转发路径、如何运营广域网，这些都是SD-WAN需要解决的问题。作为软件定义的广域网，SD-WAN必然会使用很多编排系统，这些编排系统也必然会大量用到网络设备的API。对于这样的网络，采用DevOps的运维方式和业务部署将是一个不错的选择。