一、 研究背景情况

(一) 问题和挑战

银联基于 OpenStack开源技术的金融云平台已运行 5年，目前已达数千台级物理服务器规模，银联互联网、移动支付等关键业务，特别是提供多样化支付服务的全渠道系统均已运行在云平台之上，有效支撑了银联业务创新，在支付产业日益开放和用户体验互联网化的趋势下，银联也在积极探索更加开放和灵活的技术体系，探索云平台在服务内部需要的同时，兼顾未来向外部开放，向金融行业提供开放的、共享的云服务。软件定义网络（Software-defined networking ,即SDN）是这一演进过程中必须的技术组成。

然而SDN现阶段还处在发展和变革中，新兴的“软件定义”提供商主动开创却缺乏历史积累，传统的“硬件设备”提供商顺应变革却局限于历史包袱，都在给SDN的技术选择上提出了挑战。特别是在金融机构，SDN演进战略缺乏顶层指导、选型体系缺乏统一标准以及技术数据缺乏中立来源三大问题影响了现阶段的技术决策。

因此在银联云平台面临下一代基于SDN的云平台升级之时，在金融行业数据中心架构向开放、高效演进变革之际，银联依托国内金融行业首个电子商务与电子支付国家工程实验室的研究资源，构建了一个基于SDN的下一代云平台的准生产级创新研究实验环境，致力于为各金融与非金机构的合作伙伴提供安全高效的前瞻性技术服务，为包括银联在内的金融行业未来生产环境中SDN以及其他关键技术升级做好技术验证。

(二)软件定义网络研究成果

我们构建了一个42个物理节点规模的基于SDN的新一代云平台，实现了以下应用和技术成果：

应用成果

完成银联创新研究实验环境基础设施即服务（IaaS）建设，基于Openstack L版定制，支持了生物识别、区块链等金融创新研究应用。

技术成果

1.异构兼容能力，实现多SDN技术模式不同网络区域的统一管理，硬件与软件SDN方案混合，商业与开源方案并存；

2.高可用能力，基于商业SDN高可用组的自动编排，基于容错x86服务器的纯开源SDN控制器高可用优化，目标设计值5个9（需要长时间运行后确认），故障切换时间优化至5-10秒（还在向1秒内优化中）；

自动化能力，Overlay逻辑虚拟网络元素的拖拽自动生成，实现网络资源组的一键开通，包括虚拟路由、负载均衡、防火墙、VPN以及相关网络安全配置参数等；

3.运维能力，网络可视化和拓扑自动发现，基于性能考虑的与SR-IOV等底层技术的集成。

(三)技术应用指导思想

网络的本质是实现节点到节点之间的数据流转发，传统业务网络流量模型相对简单固定，因此可通过有效的区域规划实现以南北向流量为主的网络运维；云数据中心面临“互联网+”新业务流量模型，其中尤其多租户的云服务模式，使网络东西流量大幅增加，传统网络区域规划管理模式受到挑战。

因此下一代云平台的SDN技术应用需要的是可以任意管理控制网络数据流转发与大小的网络技术，在注重安全的金融数据中心中传统“区域隔离安全网络模型”将转向“应用隔离安全网络模型”的运维管理模式，将秉承弹性、透明、积木化的三大云计算技术理念。

弹性

面向应用隔离安全网络模型的运维管理模式中，是以应用为中心的网络资源服务提供方式，云数据中心的应用是弹性变化的，因此网络资源的开通与回收需要紧密跟随应用的运行状态进行弹性变更，相应的安全控制模式也需要动态调整。

透明

SDN网络技术是控制与数据分离的网络技术，因此SDN网络控制技术应能屏蔽不同网络数据传输设备的差异性，在满足业务性能需求前提下，网络业务的部署与运行应无需关心具体底层网络技术的实现。

积木化

在云网络规模不断增长，功能不断完善的情况下，通过定义良好的接口和协议，实现服务模块标准化后的“即插即用”，从而以模块组装的方式提升网络规模，加强网络服务能力。

二、软件定义网络的技术理解

我们认为在传统金融企业数据中心，上层多租户和多应用的网络资源需求，使SDN实践落地时必须考虑基础SDN网络技术，以及NFV(Network Function Virtualized，非电信级)技术，基础SDN网络技术是指2～3层的协议和其控制器，NFV技术是指4～7层的网络功能虚拟化，此外云平台网络资源编排定制化也是SDN用户友好性的关键工作。

我们将软件定义网络分为三大层次，并由此进一步细分为相应的五层模型：

1.云平台消费层(Cloud Consumption)：云平台是推动和促进SDN演进的主要驱动力之一，SDN的功能解耦和资源调度很大一部分是为了适应上层云平台的多租户和按需调度需要。云平台消费层的选择很大程度上会制约底层其他技术的选型范围，OpenStack作为银联核心技术选型，也意味着银联选择了开源自主、开放式的技术路线。

2.控制平面（Control Plane）：SDN控制平面又分为管理编排（Manage & Orchestration）层和控制驱动（Control & Driver）层。

(1)管理编排（Manage & Orchestration）层：主要面向上层消费层的控制理解，着重针对应用（Application）和租户（Tenant）的策略理解，实现跨多个VNF的调度和协同。

(2)控制驱动（Controller & Driver）层：主要面向下层VNF（Virtualized Network Function）以及实体网络设备的控制执行，着重针对网络2～7层网络元素的指令分发和驱动，实现单个VNF的功能指令下发和功能驱动。

3.数据平面（Data Plane）：数据层面主要是关于数据承载的网络功能实现，具体又可以大致分为由2～3层组网方式和4～7层组网方式：

(1)2～3层组网方式（Layer 2～3 Network Function）：主要针对二层交换层和三层路由层的数据承载网络功能的实现方式，在一个 SDN中，2～3层往往是必要的组件。

(2)4～7层组网方式（Layer 4～7 Network Function）：主要针对四到七层的数据承载网络功能的实现方式，包括防火墙功能、负载均衡功能（4层或者7层）、VPN功能等功能实现，在一个 SDN中，4～7层往往是可选的组件。

在实际的构建过程中，每一层次又存在多种构建方式，下图列出了相关层次的不同分类方式，并列出了一些主流选择。

构建这样决策树能够辅助在众多SDN选项中梳理出一个决策脉络，我们可以看到，根据现有的技术组合，选择可能性比较多，因此我们在创新研究实验环境中在一套OpenStack集中云平台管理架构中搭建了多种SDN技术组合进行验证比较。

三、 基于软件定义网络的下一代金融云架构

(一)部署架构

在部署上我们借助OpenStack多区域的部署方式, 构建了多种SDN网络共存的环境，不同的SDN环境的保持了独立性，并优化实现了多区域的异构SDN环境的互通。

基于当前研究资源以及相应SDN技术模式的落地可行性，我们近期围绕如下几种方案进行实验：

Region 1（方案A）基于和OpenStack项目里的原生套件实现，云平台管理员通过原生的OpenStack Horizon界面进行管理， 我们通过独立的专用X86服务器承载网络服务，Horizon调用Neutron进行对VNF的控制，通过OVS L2实现分布式交换机和VXLAN封装，通过Linux namespace实现Router功能，通过Iptables实现防火墙服务，引入了开源项目Strongswan和Octavia实现了VPN和负载均衡功能。这一方案对交换机无特殊要求，交换机在方案A中的功能只负责转发。

Region 2（方案B）云平台管理员也是通过原生的OpenStack Horizon界面进行管理， 本次测试中二层和方案A一样，通过OVS L2实现分布式交换机和VXLAN封装。但是更多三层以上的VNF通过商业软件定义网络套件实现，主要包含负载均衡（提供4层和7层两种模式）、软件路由、软件防火墙和VPN四大功能，所有VNF实现和方案A有所不同，并不是在宿主机上启动一个进程来模拟，而是生产独立的虚拟机方式来承载VNF，这些VNF虚拟机的调度通过Neutron来实现。

Region 3（方案B’）所用到的软件套件和方案B是一样的，但是方案B的一个劣势是为了适应和Neutron的自动化编排集成，牺牲了商业VNF软件的很多特性，因此我们通过Heat／Nova直接调度预先制作的VNF镜像方式实现，这一过程需要自己修改相应网络资源编排程序，包括对VNF虚拟机的调度、网络链接配置等。

这样设计的另外一个好处是，我们通过和Neutron的松耦合，可以开放对VNF的商业配置工具和界面，比如可以实现支持更高SLA的软路由的高可用模式。

Region 4（方案C）从这一方案开始，软件定义和硬件设备开始有了紧密的关联，我们将会通过SDN控制器对交换机硬件进行配置下发和控制， C方案通过ODL的部署可以不局限在具体交换机品牌，只需要遵循OpenFlow协议。这一方案中，Neutron并没有直接去控制OVS，而是通过ODL，驱动由ODL来控制OVS以及硬件交换机。

下图展现的是在方案中对物理拓扑的自动发现和流表下发等功能：

下图可以提供丰富的流量的监控功能，这一功能目前在开源版上定制或采用商业版的ODL：

Region 5（方案D）采用了非OpenFlow商业交换机产品的SDN解决方案，由于该解决方案基于该厂商交换机的基础API能力进行SDN能力封装，只可以管理该厂商N系列交换机，集成方式上直接采用插件通过OpenStack Neutron管理。在具体部署上通过一组特定的服务器承载商业控制器，Neutron调用ML2的商业控制器驱动进行通信，商业控制器再通过其商业交换机的标准API进行硬件交换机配置下发，由于其控制器只支持交换机设备的管理，其次其三层以上的VNF，可使用 Neutron的FWaaS/VPNaaS/LBaaS的驱动或商业其他解决方案。OVS依然需要，但是OVS L2 Agent 的分布式交换机功能已经下放到硬件交换机层面实现。

Region 6（方案E）采用了商业交换机产品的SDN解决方案，但该方案中控制器通过企业特定的协议操作交换机，比起方案D，这一方案对交换机的限制更为严格，需要是C厂商N系列方案中的最新型号。比起后面的F方案，这一方案和OpenStack的集成更加紧密，部署上启用Neutron里的商业产品的Plugin来驱动设备，其中L4-L7的服务还是可以和方案D一样的方式搭建。

Region 7（方案E’）为了完全展现方案E中商业产品功能，和OpenStack是一种松散的组成模式，更多是通过C厂商提供的APIC直接进行控制。这一方案的特色是特有的EPG方式，由OpenStack GBP模块进行集成，GBP在OpenStack社区还处于发展中，因此集成有一定门槛，同时需要做更多的UI定制，如业务组管理、合同策略等，与此同时由于与商业控制器强耦合，相应的L4-L7服务，必须是符合C厂商的OPFlex协议，才能够接受商业控制器进行集中控制。

(二)不同架构的优劣初探

(三) 软硬件参数

软件配置

1.OpenStack控制操作系统：CentOS 7

2.OVS 2.4.0

3.Libvirt 1.2.16

4.Mariadb 5.5.47

5.RabbitMQ 3.5.4

6.Iptables 1.4.21

7.Openswan 2.6.38

8.QEMU 2.1

四、问题和挑战总结

上面对比表中已经对各种方案的优劣进行了对比，这里主要对一些共性主要问题做总结有以下几个方面。

(一)和云平台自动化编排集成带来的功能损耗

不管是商业方案还是纯粹开源的方案，我们都尝试尽量能够和OpenStack集成，但是我们观察到这种集成是一种双刃剑，一方面带来更好的编排自动化，另外一方面则带来功能上的损耗。这种不足需要对驱动、调用代码和配置方式进行二次改造去弥补，这对我们都带来了一定技术能力上的挑战。下表是我们针对商业VNF 在紧密集成和松散集成两种方式下的功能对比，B方案（紧密 集成，通过Neutron驱动L3~L7的VNF）基本上和原生的A方案功能差不多，和Neutron集成紧密，带来了更好的自动化，但是和B’方案却缺失了商业VNF70%的功能，这种功能损耗并不是由于厂商的接口不开放导致的，而是由于OpenStack本身Neutron模块功能不够成熟而导致的，因此在实际的落地过程中，如通过需要通过OpenStack享受自动化同时又能够充分发挥商业SDN厂商的软件功能，需要一定的二次集成。

［注1］:需要一定的VNF模版定制化工作才能够实现自动化

(二)软件模拟硬件功能带来的性能降低

软件定义网络是对软件功能和硬件设备的解耦，通过基于X86方式模拟硬件功能会造成性能的降低。下面这一实验是对硬件、三层路由性能测试试验。

软件测试：iperf/Ping 

测试场景： 

1、2和3测试场景基于同一X86服务器进行测试，避免硬件差异造成的性能差异

测试准备：

1.仿真位于不同网段的VM1 与 VM2 的端口，进行发包，确保报文一致且能够收到

2.模拟UDP、TCP两种协议，输入不同的负载和不同大小的网络包，输出带宽、时延和丢包率等数据

3.测试前确保场景构建完毕，不同租户网络中的VM1 与 VM2可以互通

测试架构图 ：

测试结果

从测结果可以看到，基于X86的开源方案（方案1）性能上相对硬件有较大的性能差距，方案2（商业）在性能上有一定改进，主要原因还是由于二层还是通过了OVS开源模块造成的瓶颈。我们的改进方案是混合模式（方案3），通过 SR-IOV模式，让承载虚拟路由的虚拟机环境直接访问网卡硬件，将软件方案提升，在延时上已经接近硬件的性能，甚至在T003、T004、T005三个测试项中，在测试数据超过了实际带宽的时候，混合模式（方案3）表现出了比硬件模式（方案4）更低的丢包率。后期我们将继续测试通过调整CPU／内存参数，再加入Intel DPDK来提高加速效果，同时引入更加专业的测试仪器进行测试。

(三) 驱动和插件的滞后

我们在集成的过程中，也发现SDN设备一些不成熟的地方：

1.插件功能缺失与功能不全：一是没有OpenStack的高版本插件，如我们这次的L版，而是插件中某些功能不支持以及存在bug

2.硬件加速的配套软件滞后：如DPDK（最新版本为2.2.0）加速功能对相关软件包的要求是OVS 2.5以上/QEMU 2.1以上/libvirt 1.2.1.5以上， 需要手动更新操作系统相应的软件包之后才能够发挥这些功能

3.开源框架之间集成不成熟： OpenStack和OVS集成的比较紧密，和ODL控制器集成则还有待完善。我们需要进一步完善OpenStack和ODL Controller的集成，发挥各自的长处，并且在一个统一的界面上展现给使用者。

(四) 定制优化

我们在实践过程中也对一些SDN特性，根据自身业务需求做了改进，主要包含：

1.纯开源路由的高可用改进：我们通过和底层容错技术结合，改进了Neutron L3的高可用模式，把原来的 AS(Active-Standby)的切换速度从5分钟级别，改进到了5-10秒以内。

2.网络资源编排自动化改进： 通过和Heat/Murano结合实现包含网络资源的应用模版的一键生成， 实现了通过拖拽虚拟防火墙、虚拟路由、虚拟VPN、虚拟LB即可生成虚拟机资源的功能。

1.Overlay逻辑网络拓扑自动发现：我们改进了虚拟网络，能够实现多个异构的SDN方案共存并展现，并根据金融行业DMZ区与APP区的隔离特性要求，使两区域的网络技术方案异构部署，后期我们还将实现同一租户的跨区域（Region）拓扑统一展现。

2.驱动和插件的源码级别改进：主要包含对商业软件路由驱动的源码改进，使之能和OpenStack Neutron集成，后期还将对硬件负载均衡驱动、防火墙的改进使之能够实现对租户的流量限定和控制。

五、 实践总结

截止目前，在银联创新研究实验环境中已完成了基于软件定义网络的下一代云平台基础设施即服务的能力建设，该平台基于OpenStack L版以及分布式存储等技术，并通过相应业务应用的部署初步验证了平台对外服务能力。

通过前期研究实践，我们认为纯软方式的软件定义网络技术在对已购买的普通交换硬件设备（尤其是千兆网络）的利旧场景中的应用是切实可行的，同时也可以满足云数据中心快速增长且动态变化的L4-L7网络服务需求，但其极端场景的性能还有待优化，在新设备采购的网络区域决策中，我们认为当前软件定义网络技术还处于“成熟和创新并存”、“商业和开放博弈”、“软件和硬件拉锯”的快速发展期，可实际应用生产的硬件设备方式目前存在厂商锁定问题，软件方式则还面临传统数据中心运维模式整合调整以及相应人员培养的问题。

未来我们将基于现有研究基础，在国家工程实验室的平台下与银行等机构进行联合研究，推进如下工作：

1.定义金融行业软件定义网络的技术标准架构以及统一的上层金融数据中心网络应用需求，形成基于SDN的以应用为中心云管理原型参考实现。

2.定义金融行业软件定义网络统一评测标准以及推出面向产业的基于OpenStack开源云计算平台联测服务。

3.完成金融行业基于软件定义网络的云平台最佳实践，通过国家工程实验室平台开放架构设计实现，发布与各合作伙伴研发源码，公开技术评测数据。