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制定的游戏规则，另起炉灶。
不难看出，ONF站在网络用户的角度，希望彻底摆脱厂商锁定，希望所有的接口都能被标准化，而硬件也应当是标准化的硬件，可以由标准的OpenFlow协议去管理。但由设备厂商主导的ODL不同，它们希望部分接口被标准化，保证设备厂商的利益，防止白牌交换机侵蚀其市场。
此外，运营商和一些软件公司基于SDN的一些想法，提出NFV（前文有提到）。斯坦福大学、加州大学伯克利分校联合了一些IT公司，建立了开放网络研究中心（Open Networking 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解决方案。