12月9日，以“新存储、新常态、新应用”为主题的2016中国存储峰会在北京悠唐皇冠假日酒店举行。
在当天下午举行的“软件定义技术”分论坛上，企事录联合创始人张广彬(狒哥)、紫光西部数据产品及解决方案副总裁胡晓雷、联想资深超融合业务拓展经理郭立、红帽软件资深架构师张家驹、XSKY产品总监张旭明、ZETTAKIT（泽塔云）技术副总裁（创始合伙人）黄扬、杉岩数据解决方案总监游长繁、OStorage（奥思数据）创始人&CTO李明宇等嘉宾分别发表演讲。
以下内容根据ZETTAKIT（泽塔云）技术副总裁（创始合伙人）黄扬题为《企业级SDN助力超融合架构》的演讲内容整理，供参考。
ZETTAKIT（泽塔云）技术副总裁（创始合伙人）黄扬。
黄扬：大家好，我是来自ZETTAKIT的黄扬，我是公司合伙人之一。
我本人是研发出身，参与了公司产品的前期研发工作。公司经过快速发展，产品在各行业有了很多实际应用案例，公司现在有很多的牛人，写代码就没我啥事了。我就深入用户那里，去了解项目，解决项目中遇到的实际问题，然后把这些实际问题反馈到我们架构设计当中去，不断改进我们的产品。
存储这一块，我们首先追求稳定，虽然有很多创新，但是架构方面其实可能没有太多可说的，我们有同事在其他分论坛介绍公司的存储产品，我在这里跟大家分享软件力量在超融合架构里面的决定性作用，从另外一个侧面说说我们怎么用软件的力量使得超融合架构更好更强。
今天，我跟大家分享的技术话题是《企业级SDN助力超融合架构》。
首先简单介绍一下我们公司，我们公司成立于2014年，还是个年轻的公司，但是发展特别快。ZETTAKIT是我们注册商标同时也是我们产品名，我们也有自己的ZETTAKIT一体机。寓意是能够处理ZETTA数量级的软件，泽塔是中文名。
公司致力于超融合云计算，软件定义数据中心相关领域的研究和产品开发。成立两年多，我们的超融合云计算产品已经在金融、证券、政府、企业和高等院校有很多用户。
下面我来分享一下我们公司在超融合架构上的认识，尤其是软件力量在云计算领域的重要作用。
传统硬件定义架构功能固定，不能灵活设定存储策略；并且不具有水平扩展能力，满足不了云计算数据中心规模自由伸缩的要求。
超融合架构让计算与存储功能充分融合，以软件的力量实现数据中心的自由伸缩，水平扩展。
那么超融合架构下网络应该是什么样？
计算与存储已经融合，软件发挥了决定性的力量。
我们应该更进一步，做到计算、存储、网络的全面融合，发挥软件的力量，使得网络随计算和数据而动。
传统网络架构的弊端在超融合架构中显现的尤为明显，不支持动态按需调配，导致资源无法被高效自动化供给，影响了整个云计算架构的快速部署、灵活调配。同时，在超融合架构当中实际去实施的过程当中有一个落地的问题，就是有一个传统数据中心向超融合云计算数据中心平滑演进的问题，但我们知道，传统网络架构的弊端在这种情况下显现的尤为明显。
所以我们可以很容易的想到超融合架构下的网络就应该有三大特征：软件定义架构，功能融合和快速部署、灵活调配。用一句简单话说超融合架构网络就需要SDN就需要软件定义网络。
我们再来看看细节。
在超融合架构中，网络将分散的计算和存储资源单元连结起来，构成计算资源池，存储资源池。
超融合架构有计算、存储、管理三张网络。其中存储网络是相比传统硬件定义架构增加的，或者说取代FC、sas等专用存储交换网络。这要求大带宽，低延迟。
虽然超融合存储可以通过调整副本分布策略减少网络压力，但网络资源仍然是瓶颈，尤其是大规模下或者对存储性能要求高时，比如金融行业中的高频交易系统应用场景下。
看这几个概念图，这个是逻辑上的三张网络划分，物理网络同样可以这么部署，但每个网的资源有限，导致性能受限。资源的共享程度越高，系统的资源利用率就越高，那么运行成本就越低或者性能就更好。
所以理想是这样的，将网络链路聚合起来，被三张网络共享使用。当然共享就有资源争用问题需要解决。这对网络资源的控制能力提出了更高要求。
大规模下，还有更多的资源瓶颈。
总结一下，超融合架构需要SDN，但也对SDN提出了一些新的要求。
软件定义架构，功能融合，快速部署、灵活调配，这三个是基本要求。
还有这些新要求：
第一个，低延迟很重要，这决定了性能扩展能力的上限。
第二个是自由伸缩，超融合架构的必备技能。这里包括构建的边际成本低，网络的控制平面和数据平面都要具有自由伸缩的能力。
第三个是易操作，这个是指整个系统操作简单，运维也简单。操作简单是指让用户容易掌握云计算系统的使用；随着数据中心规模的扩展，网络系统的复杂性提高，对于运维人员来说，任何故障都是难以捕捉的，运维简单要求网络的可视化和方便的故障检测机制。
第四个是资源占用低，显然功能融合下，网络、存储都会占用计算资源，这要求这部分资源占用尽可能低，将更多的CPU、内存资源留给计算。其实也是x86体系性能进步快才让超融合架构成为可能。否则计算都不够，就不可能融合存储和网络了。资源占用低永远是超融合架构应该追求的。
下面我来说说我们SDN在架构设计上怎么考虑这些新要求的。
我们的SDN产品是ZETTAKIT超融合云计算系统的一个组成部分。
我们的SDN设计的指导思想让软件发挥决定力量，不仅是计算网络，也将管理网络和存储网络纳入软件管理。
超融合架构首先让数据随计算流动，我们想进一步通过软件的力量，让网络随计算和数据而动。
众所周知，SDN有三大核心特征：一是数据平面与控制平面分离，二是集中控制，三是通过良好设计的编程接口控制网络行为。
我们在SDN架构设计上，将这三个核心特征进一步扩展，以适应超融合架构的新要求：
首先，在全系统的各个网络资源单元都实现了数据平面和控制平面的分离，让控制信息和状态信息更独立也更集中，尽力避免“自学习”型的数据交互方式（比如ARP这样的协议），这样让网络资源响应更快，控制粒度更细，也能减少因状态不一致引起的故障。
其次，实现计算、存储、网络资源的统一管控，也就是图中的ZETTAKIT云计算管理平台，这是更大范围的集中控制。
最后，计算、存储和网络资源全由软件定义。这样一来，在云计算管理平台，所有资源池化了，用户控制的是各种逻辑资源对象，比如虚拟机，虚拟磁盘，虚拟路由器，IP资源，带宽资源等。可以说这是一种对象化和实体化的编程接口，是对现实世界中各种IT资源实体的简化和增强，用户容易理解，只需关心业务层面的事情。可以说是应用驱动的SDN，这是易操作的基础。
除上述三大特征之外，我们的SDN架构还考虑了自由伸缩和功能融合两方面的要求：
1. 自由伸缩：控制平面和数据平面都具有比较强的伸缩性。虽然控制逻辑上是集中的，但物理上也集中必然导致扩展性不佳。我们设计上采用了分层的架构，状态数据库保存上层网络描述，是抽象的数据模型。每个控制器都独立运行，将此抽象数据模型转化为底层的控制描述。控制器也进一步分工，网络节点和计算节点上采用分布式控制器架构，单独的控制器集群对物理交换机网络进行控制。服务器是叶子节点，物理交换机网络是中间节点，叶子节点上的控制器逻辑很简单，只需要保证配置的最终一致性，不需处理环路、保序等复杂问题。控制物理交换机网络的SDN控制集群相对复杂，但因为被控制的对象（物理交换机）的对象相比服务器有数量级的减少，容易实现精细的控制。这样控制平面交互信息少。
同时，自由伸缩的另一面”高可用”上，也符合超融合架构的特点：控制器故障只会影响本节点，其他节点正常运行不受影响。
2. 功能融合：每个节点计算、存储、网络功能融合。不管从控制平面，还是数据平面来说都是如此。
数据平面架构。
接下来说说我们在数据平面的设计，这方面主要的考量是降低延迟和减少计算节点上的资源占用。
这里也来源于我们项目实际需求，现在有很多用户其实是一个传统硬件定义架构，他们的数据中心是传统型的，但是他想往超融合架构迁移。所以在数据平面架构当中去考虑这一点，我们采用了叠加网络方案，也就说我们会用隧道封装的办法，把业务流量封装起来。
这种方案对“现网影响很小”，它屏蔽物理设备差异，与现有网络标准兼容，能实现传统数据中心向云计算中心的平滑升级。其实这也是解决超融合落地的问题。这种方案允许同一个数据中心中，传统架构与超融合架构共存，然后发挥超融合架构按需扩展的优势，逐渐将传统架构的部分迁移并扩展为超融合的一部分。图中的物理服务器就是表达这种场景。
我们隧道封装标准选择VXLAN。
将硬件交换机作为VTEP，它负责VXLAN的封装和解封，这里虽然对硬件交换机有要求，但市场上满足这些要求的交换机越来越多，有传统交换机也有开放标准的交换机。并且只对TOR交换机有要求，能容易与现有网络对接。
之所以这么选择，是隧道封装和解封操作消耗CPU和内存资源，采用物理交换机硬件卸载的方式，能显著降低计算节点的CPU和内存占用，并且降低网络延迟。
在我们的某些解决方案里，管理网络和存储网络也采用这种叠加方案实现与现网融合，因为这种架构性能损耗很低。
正因为TOR的管控能力，在主机上，我们能充分利用硬件能力，进一步降低延迟和资源占用，比如图中的网络节点的负载均衡服务就可以使用SRIOV技术，因为上面有可控的物理交换机网络，并不会降低网络的控制力，仍然能实现细粒度的控制，关于主机网络的详细架构，后面有专门的一页ppt介绍。
注意我们架构中的网络节点主要是NFV，专注于4到7层的功能虚拟化，比如负载均衡、防火墙等。一般的3层功能是分布式的实现，下面会介绍，也就是分布式路由器。
这里我想说一个我们认为超融合架构它的性能能够水平扩展的技术原理，我们称之为资源的最短路径调配，形象的说就是资源随计算流动，或者说局部性原理。
这里我先用大家相对熟悉的超融合存储来阐述，看看数据是如何随着计算流动的：
存储系统优先保留一个完整副本在本节点上，也就是副本的本地亲和性。这时从理论上说，这个副本的IO路径最短，读延迟很低，写延迟也能有所优化，因为充分了利用本地存储资源，延迟低，带宽高。这里以两副本举例，另外一个副本分散在其他服务器。当这个虚拟机迁移之后，我们会异步的根据资源情况动态调度存储，就是说使用闲置的资源在本地把副本补足，所以说我们尽可能保证资源最短路径调配可能性，性能可以做到接近线性扩展的能力。当然存储数据迁移成本很高，所以受限于容量的因素，也不能100%确保本地有一个完整副本。但是这个原理我想已经跟大家呈现清楚了。
从网络角度来说，对这个原理的实现就更加自然了。因为网络在本质上，是各种设备中的内存操作。
首先从网络功能来说，对于二层三层这样功能，我们实现分布式处理，这就是我之前说的我们每个计算节点同时也是网络节点。
上半部表示的虚拟网络的拓扑关系，VM1和VM2是不同网络的虚拟机，这两个网络通过虚拟路由器A在三层互通。下面是物理网络，可以实现集中式的路由器，这样一来可以工作没有问题，网络路径变长，流量还要经过集中的节点，容易拥堵，不满足水平扩展特性，没法自由伸缩这种属性。
我们是怎么实现的？我们实现一个分布式路由器，也就是每个计算节点都有一个虚拟路由器分身，负责处理本节点的二三层通信，它能就近处理东西向转发，所以这里就做到了网络功能最短路径调配，同时扩展性很好。
再说网络路径这一块，这里展示的是计算网络的一次IP通信的过程。
当VM A想与VM G通信时，这两个虚拟机时是同一个网络的（不同网络的情况在上一张ppt已经描述，分布式路由器直接在本地处理完成），VM A首先发起ARP请求，询问VM G的mac地址，在ARP标准实现中是要在整个二层网络中广播，对于虚拟化场景来说就是广播到所有宿主机，这样开销和延迟都不可接受，而且也不具有扩展性。我们这里有一个ARP代理，它是由本地控制器直接管理维护的，所以ARP请求在本节点就被拦截并回复，这里也体现了网络中控制平面和数据平面的彻底分离。然后，VM A开始与VM G进行IP通信，不需要这时候再向管理平台询问VM G的位置，在创建虚拟机时，本地控制器就已经下发好转发规则，所以流量经隧道封装后，直接向host 4发出数据包。
也就是说，在逻辑上和物理上，网络路径都尽可能短。同时，尽可能避免了ARP这种“自学习”型协议的问题，不但降低了延迟，还提高了对网络的控制能力。
前面说的都是更上层的设计和实现，重点说的是物理机之外的SDN实现。
现在我们来看看主机内部的网络结构。这里我们的设计目标就是高性能（延迟和带宽）和低的资源占用。
我们的设计思想是全用户态实现，并充分利用硬件卸载特性。
全用户态软件栈一方面是更易维护，升级迭代更快；另一方面就是提升性能，可以进一步减少用户态和内核态的切换和内存数据拷贝次数。而充分利用硬件卸载特性能可以显著降低CPU和内存的资源占用，性能也更高。
我们详细来看：整个主机网络结构，我们以intel的DPDK为核心，DPDK是高性能的用户态网络库，使用了大页内存管理、无锁队列、快速流分类、轮询模式的用户态网卡驱动等技术，提供了强大的网络处理能力。
图中的virtio是半虚拟化IO框架，由虚拟机中的virtio前端和宿主机中的virtio后端组成，它们之间通过循环缓存区交互数据，现在基本成为了IO虚拟化的标准。
使用DPDK技术的虚拟交换机，数据平面的处理过程全部在用户态，virtio后端也在用户态实现，并且可以直接利用物理网卡的VMDq、流量镜像、虚拟网桥等硬件特性。这样其实数据平面的很多处理都卸载到物理网卡。
其中黑色实线箭头是控制平面，本地控制器预先配置好OVS的流表规则，红色虚线箭头代表了数据平面。
其中左边的虚拟机表示的是虚拟机里面也使用DPDK，这种是高性能NFV的实现方案，性能更出色，当然相关网络功能需要使用DPDK开发，我们正在将负载均衡服务向DPDK移植。右边的是业务虚拟机，代表的是提供给用户使用的虚拟机情况。
图中的SRIOV的数据平面因为不在本地控制器的控制范围，只能在TOR层面控制，所以目前我们只用于NFV中。
说了那么多，就说我们到底性能提升怎么样，这是我们一个评测，是在我们的标准一体机环境中测试的。
上面表格对比的是纯软件情况下VXLAN叠加网络和使用硬件交换机作为VTEP情况下的对比测试。这里的大包带宽测试，主机网络部分的优化对降低延迟有一定作用，对带宽影响小，这里主要是前面数据平面方案的性能提升。可以到带宽提升很明显，能达到接近于线速，延迟显著降低，资源占用也少。
下面表格是体现的主机网络优化的作用，在小包转发情况下对比明显。包转发速率从Linux原生方案的70万每秒提升到250万每秒。这说明Linux的网络协议栈并不高效，尤其是对于小包转发来说。而我们的全用户态网络方案对小包转发性能提升明显。CPU资源占用降低特别明显，从占满6个核（也就是物理机一半的CPU资源），降低为只占用一个核，其他核完全空闲。当然实际网络应用的性能提升不会这么明显，因为有不少需要CPU处理的业务逻辑。
前面说的都是我们在性能方面的优化，主要包括低延迟、自由伸缩、资源占用低三方面。现在说说易操作，重点是运维方便。
首先看链路连通性检测和诊断。举一个简单的例子，当2个虚拟机互通出现问题时，运维人员需要查询虚拟机位置、查询主机间网络拓扑、整理出流量拓扑、登录若干个设备，如果一切顺利的话，他可能定位到故障点。但是采用叠加网络之后，这些流量对传统的交换机不可见，很难定义虚拟机通信到底哪一点出现问题。更不用说大规模下，以及主机网络中的软件复杂性。
端到端监测将源、目的虚拟机报文流经的路径以图形化的形式展现，快速直观地展示端到端网络状态。这里的原理同traceroute，但采用的是本地控制器模拟虚拟机在虚拟网络中发送icmp报文。
还有一种更棘手的情况，就是发生了网络拥堵，因为流量是动态变化的，如果采用逐一检查每个网络节点的统计值，排查出网络拥堵点特别困难，尤其是在叠加网络情况下，流量被封装起来，定位特定业务流量的瓶颈，用传统方法根本不可行。
看图中的例子，左边的一个虚拟机向右边的发送数据，在左上的这个交换机上发生了拥堵，实际整个通信路径的有效带宽降低了。
网络瓶颈检测的原理很简单，控制器可以检测特定虚拟机在全部网络节点的流量统计值，在观察窗口内能找出特定流量在每个网络节点入口和出口的流量差距，定位网络瓶颈。
但实现上必须是物理交换机能“看到”隧道中的内部流量情况，按内部流量的mac值区分特定流量。在我们的数据平面方案中，TOR交换机均具有此项能力。
管理网络和存储网络更简单，在观察窗口内检测物理交换机这些中间网络节点就可以定位。
这个还能更进一步，我们下一步计划要做，就是反馈控制，依据检测的结果自动调整对网络的控制。
说了那么多，其实超融合架构下网络我们还有很多很多工作要做，这是我们对超融合架构网络的展望：
1. 我们认为SDN主战场是数据中心，超融合架构是主要应用场景；
2. 超融合架构中计算、存储、网络三网进一步融合。
3. 计算、存储、网络资源协同控制。
4. 最终目标实现指尖上的数据中心——软件定义数据中心，让我们系统能够协同控制计算、存储、网络各种资源。
我的分享就到这里，谢谢大家。
编注：中国存储峰会是每年一度、亚洲最具规模的存储产业年度大会，历时十二载，记录了存储产业的诸多变化。每年的存储峰会都吸引学术界、产业界和最终用户代表的积极参与。存储峰会对中国存储行业的发展做出了许多重大贡献。云计算、大数据对传统IT产业带来了许多变化，为IT系统提出了新的要求，存储作为IT系统中极为重要的一环也在迎接新的挑战，正在举行的2016中国存储峰紧抓热门需求，从技术、产业、产品角度，汇集了资深行业人士，呈现年度最权威的存储盛会。
