SDN VMware NSX网络原理与实践-SDN 与网络虚拟化的起源与现状【1.1】

1.2 认识 SDN

        介绍完为什么需要 SDN 和 SDN 的起源后，是时候介绍 SDN 到底是什么了。理解 SDN架构，对于理解 VMware NSX 网络虚拟化解决方案的三个平面架构以及其逻辑网络、物理网络解耦的设计，是非常重要的—SDN 的核心思想是控制平面与转发平面的分离，这与NSX 中管理平面、控制平面和数据平面的设计如出一辙。
        SDN 其实直到现在也没有清晰的定义，但是其核心理念已逐渐被人们接受。本章将下来会讨论 SDN 的理念、架构，以及它如何面对当前的 IT 难题。

1.2.1 SDN 是什么

        SDN 是 Software Defined Network 的缩写。正如业内很难回答“云计算”的定义是什么一样，业内也很难回答 SDN 的定义。但是 SDN 在经历了几年的发展后，业内也对其概念达成了一个基本的共识。前文已经介绍了 SDN 的历史，在这里我们介绍一下 SDN 的模糊定义。SDN 其实并不是一种技术，也不是一种协议，它只是一个体系框架，一种设计理念。
        这种框架或理念要求网络系统中的控制平面和转发平面必须是分离的。在转发平面，它可能希望与协议无关，管理员的意志最重要。管理员可以通过软件来执行自己的意志，控制转发行为，并驱动整个网络。
        除此之外， SDN 的理念还希望控制器与转发平面的接口标准化，我们把这样的接口称为南向接口。因为如果软件想要真正控制转发行为，就应该尽量不依赖特定的硬件。除了硬件设备，该控制器也可以对网络中的应用程序进行集中控制，一般来说这是通过硬件提供一些可编程的特性来实现的。控制应用程序的接口称之为北向接口。
当前业内比较认可的 SDN 的特征属性如下：
 控制平面与转发平面分离；
 开放的可编程接口；
 集中化的网络控制；
 网络业务的自动化应用过程控制。
        其中前两点是 SDN 的核心。如果一个网络系统具备了这两点特征，那么就可以宽泛地认为这是一个 SDN 架构。
        OpenFlow 作为目前主流的南向接口协议，这个名词当然被炒得火热，有人认为 SDN就是 OpenFlow。这是不正确的。因为 SDN 是一种框架，一种理念，而 OpenFlow 只是实现这个框架的一种协议。
        如今， VMware 公司、 Cisco 公司和 Microsoft 公司都在大力宣传自己的网络虚拟化（Network Virtualization）技术。有人认为网络虚拟化也是 SDN，这种观点是不完全正确的。早期的网络虚拟化雏形（如早期的 Cisco Nexus 1000v 和 VMware 内嵌在 vSphere 里的虚拟交换机），指的是在服务器虚拟化平台中加一层虚拟交换机，用于与虚拟机连接，细分虚拟机的接口策略，而不是在服务器网卡上用一个 Trunk 把所有 VLAN 封装并连接上行链路。而现在，网络虚拟化特指实现方式是基于一种叫做 Overlay 技术（现在还没有很好的中文翻译，我们姑且先把它叫做“叠加网络”技术）的网络虚拟化。有了这种技术，用户可以突破一个网络系统中的 VLAN 数量、 MAC 地址容量等的限制，轻松跨越三层网络打通二层隧道，对于超大规模数据中心、多租户数据中心、双活/灾备数据中心来说，这种技术相当合适。 Overlay 可以由物理网络搭建，也可以通过服务器的 hypervisor 来搭建。通过物理网络搭建的 Overlay 并没有真正实现控制平面和转发平面的分离，不符合 SDN 特征。通过服务器的 hypervisor 搭建的 Overlay， 即基于主机的 Overlay，现在一般会有集中的管理平面和控制平面，以及分离的转发平面。因此，网络虚拟化是 SDN 发展到一定阶段的必然趋势，可能是 SDN 的一个分支，但不是 SDN 本身。因此，有人把基于主机的 Overlay 称为新一代SDN，因为它和第一代 SDN 有很大区别。本书的重点—VMware NSX 网络虚拟化解决方案正是基于 SDN 思想的网络虚拟化的绝佳解决方案，是新一代 SDN，后文会详细阐述。

        一些运营商和软件厂商现今正在推广自己的网络功能虚拟化（ Network Function
Virtualization， NFV）技术。 NFV 也不是 SDN，它的目标是利用当前的一些虚拟化技术，在标准的硬件设备上运行各种执行网络功能的软件来虚拟出多种网络设备。由于这些虚拟的网络设备（如虚拟交换机、虚拟路由器、虚拟防火墙、虚拟负载均衡设备）可能会有统一的控制平面，因此 NFV 和 SDN 是一种互补的关系。 VMware NSX 具备 NFV 的属性—NSX 使用 x86 服务器的软件来实现各种网络功能，但由于 NSX 中的 Overlay 属性过于明显，因此VMware 更愿意将 NSX 解决方案称为一种网络虚拟化解决方案，而不是 NFV 解决方案。
        另外，近来一些热门词汇如 Openstack、 Cloudstack、 OVS 等，与 SDN 都没有任何直接的关系。其中 Openstack 和 Cloudstack 是云管理平台，而 OVS 之前已经提到过了，是 SDN鼻祖 Nicira 公司开发的一款虚拟交换机，现在已经开源。这些新技术和 SDN 也是一种互补的关系，可以共同实现融合解决方案。

1.2.2 SDN 架构

        图 1.6 所示为 SDN 架构中的各个层面，它直观地阐述了 SDN 架构，我们具体解释一下图中的各个层面。

 基础设施层： 该层主要是网络设备，可以将这一层理解为“转发平面”。这些工作在“转发平面”的网络设备可以是路由器、物理交换机，也可以是虚拟交换机。所有的转发表项都贮存在网络设备中，用户数据报文在这里被处理和转发。网络设备通过南向接口接受控制层发来的指令，产生转发表项，并可以通过南向接口主动将一些实时事件上报给控制层。
 南向接口： 南向接口是负责控制器与网络设备通信的接口，也就是控制层和基础设施层之间的接口。在 SDN 的世界里，人们希望南向接口标准化（这只是一个理想，还未成为现实，但 OpenFlow 协议是目前主流的南向接口协议，未来能否成为标准协议也有待观察）。只有这样， SDN 技术才能摆脱硬件的束缚，否则 SDN 技术永远只能是特定的软件用于特定的硬件上。
 控制层： 该层就是前文所说的“控制平面”，该平面内的 SDN 控制器可能有一个，也可能有多个；可能是一个厂家的控制器，也可能是多个厂家的控制器协同工作。一个控制器可以控制多台设备，甚至可以控制其他厂家的控制器；而一个设备也可能被多个控制器同时控制。一个控制器可以是一台专门的物理设备（如NEC 的SDN 控制器），也可以运行在专门的一台（或多台［成集群工作］）物理服务器上（如 Cisco 的 APIC），也可以通过虚拟机的方式部署在虚拟化环境中（如 VMware NSX Controller）。
 北向接口： 北向接口指的是控制层和应用之间的接口。在 SDN 的理念中，人们希望控制器可以控制最终的应用程序，只有这样才能针对应用的使用，合理调度网络、服务器、存储等资源，以适应应用的变化。目前北向接口尚未标准化，也没有类似 OpenFlow 这样的主流接口协议。一些组织和公司希望将其标化，但是非常困难—它和南向接口的标准化相比，显得异常复杂，因为转发平面毕竟万变不离其宗，容易抽象出通用接口，而应用的变数则太多了。
 应用层： 该层主要是企业的最终应用程序，通过北向接口与控制层通信。该层也可能包括一些服务，如负载均衡、安全、网络监控等，这些服务都是通过应用程序表现的。它可以与控制器运行在同一台服务器上，也可以运行在其他服务器上，并与控制器通信。该层的应用和服务往往通过 SDN 控制器实现自动化。前文所说的一些时段应用以及服务需求量的激增和激退，在 SDN 的环境里应当自动完成。对于这种自动化，英文资料中经常使用一个叫 Orchestration 的名词，该词的原意是“管弦乐”、“乐曲编排”、“和谐演奏”，在这里可以引申为将各种技术糅合在一起，实现数据中心的自动化，最终达到为应用提供最好的服务效果。

1.2.3 SDN 如何应对当前 IT 环境

        介绍完 SDN 的几个工作层面，接下来讨论 SDN 究竟如何应对前文提到的 IT 行业架构遇到的问题。 SDN 解决这些问题的核心思想是改变传统网络中控制数据流的方式。在传统网络中，报文从源转发到目的的过程中，转发行为是逐条控制并独立进行配置的，这种控制也不是统一的。而 SDN 是将每台设备里的控制平面剥离出来，放到一个控制器中，由这个控制器通过统一的指令来集中管理转发路径上的所有设备。这个控制器知晓整网的拓扑，知晓转发过程中所有的必需信息，而且上层应用程序也可以通过控制器提供的 API 以可编程的方式进行控制，这样可以消除大量手工配置（无需管理员登录到每一台设备上进行配置），从而大大增加了网络灵活性和可视性，提高了部署和维护效率。
        我们来解析一个 SDN 的应用案例：一个对外提供服务的托管数据中心，需要增加一个租户，并为这个租户增加一台新的虚拟机。在 SDN 环境中，只要管理员将其属性定义好，管理平台就可以自动按照其所需资源进行配置—申请多少内存，申请多大容量的存储空间，虚拟网络和物理网络的路由策略、安全策略、负载均衡策略，都是自动完成的。而这一切的配置都可以通过 SDN 控制器自动发布到各个设备中。这样一来，一个业务上线的时间，可能由 10 小时缩短为 10 分钟—如果没有 SDN，网络管理员、服务器管理员和存储管理员必须通力合作，在不同的网络设备、服务器虚拟化软件、存储设备上进行逐步配置和资源分配，而且中间还可能会产生错误配置。这也解决了我们之前提到的网络资源无法实现按需自助式服务的问题。
        此外， SDN 还可以更细颗粒度地进行流量优化。 Nicira 创始人、 SDN 的提出者卡萨多先生曾经用一个生动的比喻形容数据中心内部的流量：小股数据流构成的突发流量称为“老鼠流”，持久且负载较高的稳定流量则称为“大象流”。对于数据中心中大多数流量的性能问题，我们都可以将其视为大象踩着老鼠前进的状况，而从用户的角度看，就是持久稳定的流量挤占了小股突发流量的资源。而在 SDN 的帮助下，系统可以对流量进行智能识别。换句话说，基于 SDN 的网络系统会辨认出其是否属于大象流，并对这些流量加以优化、标记、识别，确保它不会踩着老鼠前进，这样就达到了大象流和老鼠流的共存。这是因为在SDN 架构中，控制器可以知晓全网的拓扑和健康状况。
        SDN 的引入还能防止厂商锁定。只要设备支持 SDN，支持可编程，那么系统管理员就可以通过南向接口和北向接口，通过控制器对设备进行控制，改变转发行为。这也是 Google、Facebook 在其内部数据中心大力推进 SDN 的原因之一。厂商锁定问题不仅带来成本问题（尤其是大型数据中心网络），还会受其创新能力、私有协议的限制，带来扩展性和维护方面的问题。而有了 SDN 后，网络管理员需要学习的知识大大减少—异构设备、私有协议等都大大减少了，只要 SDN 控制器的界面足够友好和美观即可。就算 SDN 控制器的界面操作性一般，如果网络管理员的编程能力强，部署和运维也就不是问题。当然，真正解决了厂商锁定的问题之后，可能会导致白牌交换机大行其道，这显然是网络硬件厂商不愿意看到的。理论上，越是复杂的网络越适用 SDN 架构。在当前的大型复杂数据中心中，如果现有网络问题到了非解决不可的时候，也就是 SDN 发挥其用武之地的时候。

1.2.4 SDN 相关的组织以及厂商对 SDN 的态度

        由于各个设备和软件厂家、各个大专院校和研究机构对一项技术有不同的理解，这就需要成立一个组织去推动这项技术的发展，如推动网络协议标准制定的 IEEE 和 IETF。按常理来说，一项技术只应由一个标准组织去推动，这样才可以集中力量将其标准化， 但是事与愿违—不同的厂家和科研机构有不同的见解和利益关系，这就产生了分歧，导致出现了多个组织去推动某一项技术的发展， SDN 也不例外。
        此外，各大 IT 厂商由于在产品线、功能和特性上的差异，因此它们看待 SDN 的角度也不尽相同，应对 SDN 浪潮的手段也不同。
        目前， SDN 领域最具影响力的组织就是 ONF（Open Networking Foundation）了。它由
Google、 Facebook、 Microsoft 等公司共同发起（这些发起者都不是网络设备制造商），成立于 2011 年，是最早着手定义并希望推动 SDN 标准化的非盈利组织，其科研和活动经费来自于会员公司的赞助和年费。该组织成立至今已有近 5 年时间，其主要工作成果就是制定了 OpenFlow、 OF-Config 版本的标准。该组织也是全球范围内各个厂商间 SDN 互通互联测
试的组织人和协调人，并定期组织学术研讨会。
        在 SDN 被提出后的很长一段时间， ONF 都是唯一的标准化组织，但是 2013 年 4 月，18 家 IT 厂商联合推动了 ODL（Open DayLight）的成立。这 18 家厂商是 Brocade、 Cisco、Citrix、 Ericsson、 IBM、 Juniper、 Red Hat、 Microsoft、 NEC、 VMware、 Arista Networks、Fujitsu、 HP、 Intel、 PlumGrid、 Nuage Networks、 Dell 与 Big Switch（后退出）。这 18 家公
司绝大部分是 IT 行业内的巨头，多为网络设备制造商，它们不满 ONF 制定的游戏规则，另起炉灶。
表 1.1 比较了 ONF 和 ODL 这两个组织的异同。

        不难看出， ONF 站在网络用户的角度，希望彻底摆脱厂商锁定，希望所有的接口都能被标
准化，而硬件也应当是标准化的硬件，可以由标准的 OpenFlow 协议去管理。但由设备厂商主导
的 ODL 不同，它们希望部分接口被标准化，保证设备厂商的利益，防止白牌交换机侵蚀其市场。此外，运营商和一些软件公司基于 SDN 的一些想法，提出 NFV（前文有提到）。斯坦福大学、加州大学伯克利分校联合了一些 IT 公司，建立了开放网络研究中心（ OpenNetworking Reserch Center， ONRC）。 IEEE、 IETF 这两个网络界的龙头组织也有一些想法，由于不是本书重点，在这里不多赘述。
        尽管网络设备制造商联合发起了 ODL 组织，但是它们并没有抛弃 ONF。换句话说，由于 OpenFlow 巨大的影响力，网络设备厂商还没有牛到能完全另起炉灶的程度。 Google、
Facebook 旗帜鲜明地站在 ONF 这边，没有加入 ODL。 Amazon 是个特例，它既没加入 ONF，
也没加入 ODL，而是封闭式地发展自己的 AWS（Amazon Web Service）。而那些耳熟能详
的网络设备制造商或软件公司，如 Brocade、 Cisco、 Citrix、 Juniper、 IBM、 NEC、 VMware、
        Arista Networks、 Dell、 Alcatel-Lucent、 H3C、华为，都既是 ONF 会员，也是 ODL 的黄金白银会员。这些厂商都开放了自己物理或虚拟网络设备的接口，可以将自己的设备交给SDN控制器管理。然而，这些 IT 厂商也都会在自己的交换机中加入有自己特色的东西，否则自己的设备岂不是任由其他厂家摆布，任由别人的控制器来定义了吗？因此，这些 IT 巨头们有些靠自己研发，有些靠并购，希望在 SDN 浪潮下不至于被竞争对手落下。它们大多使用Hybrid 模式，而非纯 OpenFlow 的方法来实现 SDN。对于自己设备的可编程接口，除了支持 OpenFlow 外，还加入了 JSON API、 XMPP、 Phyton API 等。在芯片方面，它们有些使用商用芯片，有些混合使用商用芯片和自研芯片。而这些内部研发和并购中，又以 VMware收购 Nicira 和 Cisco 收购 Insieme 最为重磅—VMware 收购 Nicira 后推出的 NSX 解决方案、 Cisco 收购 Insieme 后推出的 ACI 解决方案，都是将 SDN 和近年兴起的网络虚拟化技术完美融合在了一起。而 Microsoft 作为史上最成功的 IT 公司之一，自然不甘落后，Hyper-V 在 Windows Server 2012 版本中也增加了基于其自主研发的 NVGRE 协议的网络虚拟化功能。但 Microsoft 并没有特别强调 SDN，且刻意淡化 OpenFlow（虽然它们是 ONF的发起者和核心会员，且加入了 ODL）。此外， Juniper 收购 SDN 初创公司 Contrail 后也推出了同名的 Contrail 解决方案。这些不同厂商之间的解决方案的比较，会在下一章详细分析。