本篇介绍了SDN的两种实现方式即OpenFlow完全控制的网络架构和部分厂商推出的设备可编程的架构,分析了两种方式的优劣,并且结合产业链的博弈对SDN的应用场景进行了剖析,最后着重介绍了数据中心SDN的应用价值.作者从技术的角度对SDN从定义到实现进行了辩证性的分
本篇介绍了SDN的两种实现方式即OpenFlow完全控制的网络架构和部分厂商推出的设备可编程的架构，分析了两种方式的优劣，并且结合产业链的博弈对SDN的应用场景进行了剖析，最后着重介绍了数据中心SDN的应用价值。作者从技术的角度对SDN从定义到实现进行了辩证性的分析，不容错过。
ONF成立两年之际，SDN开始得到业界的广泛认同，尤其是从IT真正走入了CT，而CT的网络类型五花八门，这使得SDN的应用场景急剧增长，大有无所不能之势。
业界目前所推的SDN无非两种，方式一是原生的斯坦福/ONF推崇的OpenFlow完全控制的网络架构，方式二是部分厂商推出的设备可编程的架构，两者的核心区别在于后者设备的本地控制面仍然要运行传统的协议，可编程是附加的能力，当应用崩溃后，原有设备/网络仍然可以继续正常运行。这一架构的优点看起来很明显，避免了控制面本身故障的问题，但是问题也同样明显，首先设备本身的复杂度实际上是增加了，门槛继续加高，不利于新兴的设备厂商的参与；其次既然部分由传统控制面控制，部分由应用程序控制就需要额外的控制仲裁规则，比如基于OpenFlow Hybrid模式下端口的划分、路由器RIB的合成规则或者增加额外的流分类器等等，这使得可编程性受到限制，客户未必能够操纵所有的转发面状态，使得其实际上更适合于特定的应用优化；
而方式二其优点是转发面可以彻底简单化，受控转发，在全局的控制面控制下可以做到完全自动化部署、配置和维护，缺点也有很多：1）目前的硬件不能很好地支持OF1.1+的抽象模型，只能由控制面适配ASIC本身的能力，业务支持受限于特定硬件，所以Nicira选择在vSwitch上支持OpenFlow。2）集中控制面的问题，控制面本身的可靠性可以通过分布式技术解决，主要是控制平面本身的时延、可靠性问题，时延随距离增加线性增加，而可靠性则下降更为迅速，关键设备必须要通过双网双平面的方式保证，这使得控制本身的成本大大增加。我们有理由相信Pure OpenFlow的方式更适合于地理上相对较近的网络，比如企业网、数据中心和运营商接入网络。地理跨度更大的网络往往用基于网管接口的方式更加合适。
我们再考察转发设备芯片，目前速度最快的ASIC到NP、FPGA、多核以及纯软转发的x86均有，其处理单元组织可以分为Pipeline和SMP/NUMA两种形式，pipeline结构分工明确、可以按Pipeline环节的功能设计进行优化，同样的芯片面积可以做到更高的转发速度，问题是需要分解转发逻辑到相应的流水线上，灵活度受限；SMP方式编程简单、灵活，但开销稍高。说到底，灵活和成本是互换的。对于Switch ASIC这样的流水线长度、键值类型和操作都固化特定的芯片而言，控制面很难统一控制不同的设备，比如说我按业务分解到查目的MAC表打上MPLS标签，但是ASIC MAC表只支持打VLAN标签，那么就玩不转了。比较理想的模式是转发面Match和Action最好都是可以由控制面定义的，比如在数据中心中，主要是端口分类表、MAC转发表、L3交换表和L3前缀表，那么我就初始化成4个Flowtable，三个HASH的，一个BST或TCAM的即可(此处为说明简化成4张表)，那么在运营商网络可能需要增加MPLS、IPv6等表，而这些表对Action的支持是均质的，那么控制器软件就不需要分别和多家多种设备做两两互通测试，真正做到产业链的开放。在这种芯片结构下，大的TCAM不是必须的，除非应用要求进行大量通配表查找，比如大量包含通配的流调度。Nick Mckeown ONS 2013上演讲所提的芯片就是此种类型，其声称增加芯片面积、功耗不到15%,如果属实，那么其一旦商用，将对产业产生真正的颠覆作用，所谓SDN将转发设备简化、开放化的愿景主要依赖于此种芯片。
其实可编程和可配置之间的界限是比较模糊的，如果采用NetFlow统计流量，用NetConf、命令行下配置策略实现流量工程到底是叫配置还是编程？我个人认为这一点区别并不重要，关键是转发面正常运行是否依赖于外部实体的实时响应，如果是，则外部实体(控制面）的可靠性就是和设备处于同一标准，可以称之为控制面，否则就是网管。在完全控制和部分可编程之间也不存在绝对的界限，比如可以将传统控制面路由协议全部关闭，外部由应用控制RIB，当然这和pure OpenFlow方案相比多花了一些冤枉钱。
集中控制还是分散控制(De-Centralized）是分布式系统设计中的一个关键的取舍，取决于你追求的是可伸缩性还是全局解的优化，全局最优解需要集中的控制点收集决策所需的完全信息，对于网络而言，无法对拓扑相关信息垂直划分为完全不相关的子集，因此你不可能在两个维度上都达到最优。在Internet的规模上，必须是分散控制的。另外互联网从来就不是一个整体，而是由多个不同地域的商业主体运营的，而互联网业务是全球化的，任何端到端的网络解决方案落地都极其困难，首先要解决投资和收益主体匹配的问题，而端到端的解决方案不是一蹴而就的，后投资的能够更快地获得投资回报，先花钱的有点为人做嫁衣的感觉，因此也抑制了所谓的端到端解决方案的落地，类似的例子不胜枚举。比如NGN时代端到端的QoS方案；又比如LISP协议来解决路由扩展性问题，投资主体是接入的ISP，而收益者是Tier 1/2的ISP，没有人愿意花自己的钱解决别人的问题。
SDN本身就是一个局部的网络技术革命，放大到全网的演进就得面临经济、技术上的双重挑战，个人理解对于一个分散控制的互联网，引入SDN不过是将分布式系统的节点规模做得更大，如果你想扩大它的内涵，引入更广泛的SDN控制，那么你要想想为什么互联网要分自治域，为什么是IGP+BGP,BGP还要分iBGP、eBGP，还要引入路由反射器，为什么不是一个OSPF的单一区域。也许SDN+BGP，替代IGP是有技术可行性的，但是全网的演进总是比预期的更为缓慢。
回到SDN擅长的领域：数据中心。数据中心由来已久，Internet商用化后就存在，只不过在计算模式经由MainFrame、C/S架构、P2P再回到中心化的云计算时代，数据中心规模呈爆炸式增长，在虚拟化、分布式计算技术解决了计算本身的部署、规模问题后，网络问题变得特别突出。前几年的数据中心网络问题研究很多人拿虚拟机迁移说事，但是虚拟机迁移实际上是个小众应用，毕竟虚拟机迁移需要大量的状态复制，跨存储集群迁移时还要进行持久存储的复制，这是个投入产出比较低的活儿，尤其是跨WAN进行迁移，简直拿资本家的钱不当钱。
我个人认为数据中心SDN带来的价值主要有3点：
1、网络的自动化部署和运维、故障诊断。依赖于SDN的集中控制、集中拓扑探测，网络设备完全可以做到即插即用，除了部署之外，网络故障设备的更换变为简单的硬件更换。对于故障诊断，则依赖于控制器具有完全的转发表项，应用可以根据故障申告的业务报文做端到端的报文路径静态检查，也可以通过工具生成自动化的测试用例，在控制面进行灌包测试(与专门的测试仪表相比，不受位置限制)，并且可以评估测试的覆盖率，就如同软件的代码、分支覆盖率一样；最后可以在控制面应用上生成故障申告业务相同的报文头部通过SDN控制器的报文上送、下发机制进行单步的检测，检测到软故障具体的流水线节拍。
2、虚拟机的按需部署，这在公有云、混合云的环境下尤其有用。今天大家已经比较习惯于在电信运营商营业窗口、自服务页面上办理业务后，立刻收到短信通知业务已经开通，但是在早年，这些业务开通涉及到营业、计费、后台、网管中心、LMT等系统，需要工单的流转才能开通，是以天计的。那么在今天绝大多数的数据中心中只要涉及到IP地址的分配问题，仍然需要工单的流转，这对于以虚拟机作为单位的主机托管数据中心，显然是低效的，尤其是虚拟私有云、混合云，从业需求来看需要允许客户自己规划、配置子网和虚机的IP地址，并支持按需启动/停用虚拟机和按使用计费，从数据中心运营效率来看，需要能够自动发现负载更轻的物理机器加载虚机，这就要求网络的地址是可以浮动的，并且可以根据客户的指令实时生效。前几年大家推大二层的解决方案，大二层需要辅以802.1Qbg才是一个完整的解决方案，而Overlay+IP组网无需升级硬件，无疑性价比更高。如果要升级，则不如升级到SDN更为彻底，你可以得到第1条所述的所有好处，另外你也不知道明天还会有哪些需求，SDN提供了未来不升级硬件的承诺(当然这些承诺也是靠不住的，你不因为功能升级，但更可能要因为性能而升级)。保底地，可以实现基于SDN的Overlay。
3、动态业务插入，比如虚拟防火墙、虚拟VPN网关等设备以VM形式动态插入到转发路径上，并且可以根据业务流量的变化动态增加/停用Virtual Appliance.这其实是在第二点的基础上实现的，只不过增加了应用去感知、控制业务逻辑实体。
vSwitch的性能很多人怀疑，但是自从Intel推出DPDK后，这个问题质疑的声音要少一些了，但是报文经过vSwitch到VM引起的上下文切换开销还是比较难以解决，尤其是小报文为主的业务，将来应该以智能网卡+SR-IOV为解决思路，vSwitch退化为本地控制面。
至于流量可视化，没有SDN你能够做到，有了SDN也不见得会实现更加容易。租户数量问题，和SDN也没有太大关系，关键是转发面封装格式中表达租户数量的标签是多少位以及转发设备据此生成的转发规则。
需要谨慎考虑、评估的好处包括：
1、虚拟机迁移，除了前面讲的虚机迁移本身的成本外，虚拟机迁移本身的SDN实现也是一个比较困难的问题。当集群规模较小，VM通信对端较少的时候，一切都不是问题；当虚机集群规模较大，比如Hadoop集群节点，one hop DHT节点、分布式文件系统节点，数据库节点等(当然不一定建议这些节点用虚拟机，性能也是问题)，迁移时需要迁移VM所在节点的转发表，还需要更新与之有通信关系的虚拟机所在边缘交换机的转发表，这个问题的痛苦之处在于需要更新转发表的节点数量是不可预知的。我们在移动网络网络中往往不去更新对端的转发表，而是在迁移终端所在的迁出网络设备和迁入网络设备之间建立一条中转隧道用于流量的转发，但问题是移动网络中的每一个会话周期都是短暂的，因此这种中转通道的生命周期是短暂的，不会给设备带来太大的负担；而服务器集群中的通信会话周期是不可预知的，并且中转带来的迂回流量开销可能也是惊人的。因此这是一个很难控制的过程，尤其是在集群规模较大、业务繁忙的时刻。
2、细颗粒度的流量控制。理论上我们可以做到，并且OpenFlow一开始就被误解为基于流的转发控制。颗粒度越细，需要消耗更多的转发面和控制面资源，更为糟糕的是在转发面和控制面之间需要同步的信息就越多。在移动核心网的PCC架构下，理论上是按照业务流进行QoS的控制的，需要和转发面能力相匹配的本地控制面能力，需要海量的TCAM来存储通配流表，付出的代价就是高1-2个数量级的成本，所幸的是移动网络的无线接入是瓶颈，流量有限，如果在数据中心中应用，最好还是进行粗颗粒度的流统计或者只对少数已经预先识别的流进行控制。
从远期来看，DataCenter本身的效率和管理复杂度问题可能逐步成为解决方案的重点，可能由松散的系统逐步走向计算、存储、网络统一控制的紧耦合体，更加注重对不同计算实体调度的优化处理，这是所谓的DataCenter As A Computer理念，这其中，裸CPU+Main Memory、存储都可以通过融合网络直接连接起来，构成一台类NUMA(此处是针对外存而言)的超级计算机，而SDN控制下的网络充当其CPU和外设的交换矩阵。出于成本的考虑，这一交换矩阵可能很难做到完全无阻塞的，因此它需要一定的实时监测和路径重指派能力。这时候，SDN已经完全融入到DataCenter的管理控制系统之中，和计算、存储的调度完全融为一体。
转载自：russell的博客
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
