SDN 系统方法 | 1. 概述(下）-阿里云开发者社区

1.2.2 控制平面: 中心化 vs 分布式

在解耦控制平面和数据平面之后，接下来要考虑的是如何实现控制平面。一种选择是在交换机上运行实现控制面的软件。这样做意味着每个交换机都作为自治设备运行，与整个网络中的对等交换机通信，以构建本地路由表。为了方便起见，已经存在一组可用于此目的的协议: BGP、OSPF、RIP 等。这正是过去 30 多年来互联网一直采用的分布式控制平面。

这种场景自有其价值。由于解耦带来了使用商用硅交换芯片构建低成本裸金属交换机的可能性，网络运营商可以从裸金属交换机供应商购买硬件，然后从其他供应商购买适当的控制平面软件，甚至可能使用这些软件的开源版本。这样做可能会降低成本和复杂性(因为只需要将所需的控制模块加载到设备上)，但不一定能实现 SDN 所承诺的创新速度。因为运营商仍然停留在缓慢的标准化过程中，这是今天的标准化协议所暗示的，也没能实现 SDN 先驱们所设想的新的网络抽象(例如 Shenker 在上面的演讲中提到的)。

另一种选择是控制平面完全独立于数据平面，并在逻辑上集中管理，这是 SDN 的第二个设计原则。这意味着控制平面是部署在交换机之外的，例如可以在云上运行控制器。为了完整起见，我们注意到也可以采用混合方法，在云托管的控制器中，一些控制功能运行在交换机上，一些运行在交换机之外。

我们说逻辑集中是因为收集状态的控制器需要维护全局数据结构(相对于在每个交换机上维护路由表)，这个数据结构的实现仍然可以分布在多个服务器上，通过云的最佳实践，实现服务的水平扩展，这对于可伸缩性和可用性都很重要，其中关键是这两个平面是独立配置和扩展的。如果需要增加数据平面容量，可以增加裸金属交换机。如果控制平面需要更多容量，可以添加计算服务器(或者更可能的是虚拟机)。

图 6. 网络操作系统(NOS)托管一组控制应用程序，并为底层网络数据平面提供逻辑上集中的控制点。

图 6 描述了与分布式数据平面相关联的集中式控制平面，但是更进一步，还引入了这种方法所隐含的关键组件: 网络操作系统(Network Operating System, NOS)。服务器操作系统(如 Linux, iOS、Android、Windows)提供了一组高级抽象，可以更容易实现应用程序(例如,用户可以读取和写入文件，而不是直接访问磁盘驱动器)，NOS 与此类似，可以更容易实现网络控制功能，也称为控制应用程序(Control Apps)。

NOS 背后的思想是抽象交换机细节，并向应用开发人员提供网络分布(Network Map) 抽象。NOS 检测底层网络变化(例如，交换机、端口和连接的可用状态)，而控制应用只是在这个抽象上实现想要的行为。这意味着 NOS 承担了收集网络状态的负担(分布式算法中最困难的部分，例如链路状态和距离向量路由协议等)，而应用可以免费使用相关抽象，并在图上运行简单的最短路径算法，并将构建的流规则加载到底层交换机。下面是关于链路状态(Link-State)和距离矢量路由算法(Distance-Vector routing algorithms)的在线介绍。

延伸阅读:Routing. Computer Networks: A Systems Approach, 2020.

通过集中化相关逻辑，可以实现以前在分布式网络中不可能实现的事情: 计算全局优化解决方案。正如在后面章节中讨论的那样，已经公布的来自云供应商的证据证实了这种优势。多年来大家都很清楚，互联网完全分布式的方法并不适合全局优化，但直到 SDN，还没有真正可行的替代方案。SDN 使这种可能性成为现实，这就是提供集中式网络抽象的力量。

"收集网络状态"的想法是 SDN 和 NOS 所扮演角色的核心。我们不讨论收集网络遥测数据的所有使用方式，例如解决配置错误或做长期规划，但我们会谈论可能需要控制平面立即做出反应的精确控制，一个明显的例子是每个端口上发送和接收的字节/数据包的数量。像 OpenFlow 这样的协议定义了向 NOS 报告此类统计报告的方法，此外还为 NOS 提供了基于其收集的信息配置新流规则的方法。

中心化控制平面还有一个相关好处，随着我们讨论 SDN 用例，这个好处将变得更加清晰。逻辑集中的控制平面提供了单一的网络公开 API。将可编程 API 放在单个交换机和路由器上的想法已经出现了几十年，但没有产生多大影响，相比之下，对于整个交换机或路由器集合的中心 API 可以支持各种各样新用例。其中包括网络虚拟化、网络自动化和网络验证。以自动化为例，将 BGP 配置这样的事情自动化是相当困难的，因为很难推断当一组 BGP 节点开始彼此交互时如何回应。但是，如果中央控制平面公开了 API，可以通过 API 实现"创建一个连接以下端点集的隔离网络"，那么将该请求作为自动化配置系统的一部分就相当合理了。这正是许多现代云中的情况，其中网络资源和策略的供应可以与所有其他类型的操作(如绑定虚拟机或容器)一起自动化。

回到集中式控制平面与分布式控制平面的最初问题，后者的支持者往往基于互联网首先采用分布式路由协议的历史原因: 规模化和容错。需要注意的是，任何集中式解决方案都会导致瓶颈，也就是单点故障。在服务器集群上分布式部署集中化控制平面可以缓解这两个问题，因为基于分布式系统开发的技术可以确保此类集群的高可用性和可伸缩性。

关于控制平面集中化的第二个问题是，由于控制平面是远程的(即在交换机之外)，两个平面之间的链接增加了脆弱的攻击面。相反的观点是，非 SDN 网络已经有(并依赖)带外管理网络，所以这种攻击面由来已久。控制器可以使用这些管理网络，就像其他管理软件一样。还有一种观点认为，少量的集中式控制器比大量的分布式控制器所呈现的攻击面更小。可以这么说，虽然意见不同，但肯定有很多人支持中心化方法。

控制域(Domain of Control)

本节的"集中式 vs 分布式"框架旨在描述 SDN 设计空间的一个维度，而不是表明网络运营商面临非此即彼的情况。有许多因素会影响给定运营商在这个问题上的决定，但首先要确定 SDN 应用的域的范围。我们将在第 2 章中讨论示例用例，但是网络的自然发展突出了这个思考过程。

从历史上看，每个交换机都有一个控制平面实例，它们在同一个机器上运行。当简单的路由器发展为机架式路由器时，M 个线卡通常对应有 N 个控制平面实例，在独立的硬件上运行，并通过管理网络相互通信。随着机架式路由器从普通交换机发展为多机架结构，SDN 提出了一种设计，将转发元素集中在一个可以运行在任何地方的控制平面下，并构建一个分布式系统。这样一个系统的优势在于可以使用现代技术来进行状态分发和管理，而不用受制于标准，关键是找到能够有可能使用集中式逻辑控制平面优化性能的域。本书介绍了 SDN 可以提供提供价值的几个这样的领域。

1.2.3 数据平面: 可编程与固定功能

设计空间的最后一个维度是考虑数据平面交换机是可编程的还是固定功能的，我们需要多说一点交换机的实现，从而理解这意味着什么。

前面我们用一个简单模型讨论交换机，交换机的主要处理逻辑是从输入端口接收数据包，查找目的地址的 FIB(或者使用 OpenFlow 的术语流表)，然后根据匹配的表项将数据包输出到端口或端口组，这是低端交换机的合理实现策略(通用处理器上可以通过软件实现这一主处理循环)，但高性能交换机采用基于硬件的转发流水线。

我们将在第 4 章深入介绍处理流水线，但目前重要的特征是，该流水线是否仅限于匹配数据包报头中的固定字段集(例如图 4 所示字段)，并执行固定的操作，或者是否将匹配的位模式和要执行的动作动态编程到交换机中。前者被称为固定功能流水线(fixed-function pipelines)，后者被称为可编程流水线(programmable pipelines)。但首先我们必须回答这个问题: "转发流水线到底是什么?"

一种方式是考虑转发流水线而不是单个流表，就像前一节介绍的那样，交换机实际上实现了一系列流表，每个表项关注一个头字段的子集，也许跟某一个流规则相关联(例如，一个表项匹配 MAC 头，一个匹配 IP 报头，等等)，给定数据包被多个流表按顺序处理，这就是流水线，并最终决定如何转发。图 7 基于 OpenFlow 规范给出了这种流表流水线的一般示意图。其思想是，在数据包流经流水线时收集一组操作，并在最后阶段作执行。

图 7. OpenFlow 转发流水线简单示意图。

乍一看似乎并不重要，因为如图 4 所示的头字段都是众所周知的，交换机很容易对每个包计算偏移量(例如，表 0 匹配 MAC 头字段，表 1 尝试匹配 IP 字段，等等)。在这一点上，SDN 的最初想法是有意不涉及数据平面，并完全专注于可编程开放控制平面，但早期实施 SDN 控制器的经验暴露出两个问题。

第一个问题是，随着 SDN 从研究实验阶段逐渐成熟，成为传统专有交换机的可行替代品，性能变得越来越重要。虽然流规则足以说明控制器想要编程到交换机中的转发行为，但交换机不一定有能力以有效方式实现该功能。为了确保高转发性能，流表使用高度优化的数据结构来实现，这些数据结构需要专门的内存，比如三元内容寻址内存(TCAM, Ternary Content Addressable Memory)。结果是只支持有限数量的条目，这意味着控制器必须谨慎使用。

简而言之，控制器必须知道流水线的详细信息，以便配置一组交换机可以映射到硬件的流规则。因此，许多控制应用程序隐式的绑定到特定的转发流水线。这类似于编写只能在 x86 处理器上运行的 Java 或 Python 程序，并且不容易移植到 ARM 处理器上。事实证明，对转发流水线有更多的控制是必要的，因为我们不想将自己限制在单个供应商的流水线上，还需要抽象方法来指定流水线的行为，从而可以映射到任何给定交换机的物理流水线上。

第二个问题是协议栈以意想不到的方式发生了变化，这意味着可能需要匹配的所有报头字段都是公开的这一假设是有缺陷的。例如，虽然 OpenFlow(以及早期的转发流水线)正确的包含了对 VLAN 标记的支持，这是在企业网络中创建虚拟网络的基础，但 4096 个可能的 VLAN 不足以支撑云可能承载的所有租户。

为了解决这个问题，IETF 引入了一种新的封装，称为虚拟可扩展 LAN(VXLAN, Virtual Extensible LAN)。与之前的方法(将虚拟以太网帧封装在另一个以太网帧中)不同，VXLAN 将虚拟以太网帧封装在 UDP 包中。图 8 显示了 VXLAN 报头，以及交换机为了做出转发决定可能必须处理的所有包报头。

图 8. VXLAN 报头封装在 UDP/IP 报文中。

向 OpenFlow 添加对 VXLAN 的支持已经足够困难了，因为标准的批准需要时间，但是向固定功能的转发流水线添加对 VXLAN 的支持则是更为耗时: 需要改变硬件！ 有人可能会说，有了 VXLAN，我们现在就完成了协议栈的变更，但这是不可能的。例如，当与 HTTP 一起使用时，QUIC 正逐渐成为 TCP 的替代方案。另一个即将出现的例子是 MPLS vs SRv6。甚至 VXLAN 在某些情况下也被一种称为 GENEVE 的更灵活的新封装所取代。

可编程转发流水线，加上可用于对流水线进行编程的高级语言，是对这两个问题的一个可行应对。这两者都是在最近几年出现的，以协议独立交换体系架构(PISA, Protocol Independent Switching Architecture) 和 P4 编程语言的形式出现。我们将在第 4 章中更详细讨论这两个问题，但目前最大的收获是，SDN 已经超越了其作为控制平面编程手段的最初目标。今天，SDN 还囊括了可编程数据平面的可能性。