1. 前言

1.1 项目背景

近年来，互联网技术、云计算技术在不断地发展，各种云在各自领域内大行其道，金融云作为新的基础设施开始被行业认同。在金融云的环境下，传统网络技术架构受到了挑战。一方面是虚拟化的出现，使得传统网络技术已不足以适配云环境下产生的新场景，如虚拟机的出现要求网络颗粒度从物理机细化到了虚拟机级别；另一方面是互联网金融创新业务的快速发展，对网络的性能、弹性等提出更高的要求。

软件定义网络（SDN）技术通过分布式架构理念，将网络控制与网络转发的功能分离，这种方式使网络控制可编程，可以更加灵活的控制网络流量。具体地，SDN是将每台设备里的控制平面剥离出来，放到一个控制器中，由这个控制器通过统一的指令来集中管理转发路径上的所有设备。这个控制器知晓整个网络的拓扑，知晓转发过程中所有的必需信息，而且上层应用程序也可以通过控制器提供的API以可编程的方式进行控制，这样可以消除大量手工配置。

SDN的特点和云环境下的网络发展趋势相吻合，为金融云网络服务提供了有效的支撑。网络方案能够落地必须要完成与现有云平台的对接。目前openstack云平台在私有运中得到广泛运用，本文也就SDN与OpenStack云平台的对接进行讨论。

1.2 项目需求

在传统的网络下，网络连接以及配置是强依赖物理交换机的端口的，当系统的负载都绑定在一些固定的机器中时，这个模型可以很好的工作。但在虚拟化环境下，一个物理机可能有几十个虚拟机，而且虚拟化的特点决定了虚拟机与物理机的对应关系是经常发生变化的，当虚拟机进行漂移后，底层的网络也要随之变化。在这种场景下，传统的物理网络就显得有些捉襟见肘了。

只有网络资源、存储资源、和计算资源协同工作，才能保证数据的高效运转，但不同类型的设备之间采用完全不同的协议标准，对于云平台来说，如何统一管理，是一个巨大的挑战。仅网络部分就包含交换、路由、安全、负载均衡各种网络设备，这些设备可能是物理的，也可能是虚拟的，如何被云平台统一按需调度，就需要有个得力的助手——SDN控制器。

复杂的事情全部交给SDN控制器，由SDN控制器进行统一管理，然后抽象给云平台一个标准开放的API接口，这样云平台就可以很轻松地完成各种网络资源的调用。与此同时，存储的、计算的、安全的资源，都可以有各自的Controller，通过提供标准开放API的方式，减轻云平台的压力，让云平台专心做策略的制定工作。

下表是SDN网络和传统网络的对比：

结合金融行业的业务及数据的特点，选择的SDN网络方案要满足的需求应该包括：较高的性能、较强的稳定性和可扩展性。

首先是性能，性能是一个SDN方案最重要的特性，性能的好坏决定了网络数据处理的速度。其次是稳定性，对于金融行业内着重关注的稳定性，SDN也必须能够解决。最后是扩展性，为应对业务流量的突发式增长，方案在支撑资源的可扩展性上也要有相关考虑。

2. 技术路线

SDN方案分为硬件和软件两大类。硬件SDN是采用专用的硬件交换设备与控制器来实现相关的网络功能，控制器对硬件设备进行策略以及流表的下发，来实现网络相关的功能。它的优点是性能强，比较稳定，缺点是不灵活且组网成本很高。硬件SDN方案大多数是商用的，比如华为的Agile Controller以及思科的ACI Controller。

而在软件SDN的解决方案中，网络的功能是通过软件层面的Linux协议栈以及相关的虚拟交换机技术实现的。它的优点可以避免对硬件网络设备的过度依赖，同时降低了组网的成本，但是软件方案的缺点也比较明显，主要表现在网络的稳定性、性能和可扩展性不如硬件方案。目前使用较多的是开源控制器OpenDayLight（下文简称ODL）。

硬件SDN方案很好很强大，也省心（厂商支持），就是价格贵；当前开源SDN方案虽然性能稳定性不比商用，但是胜在便宜。在选择技术方案时，需要考虑企业技术实力以及具体的应用场景。

当面对一些特殊需求需要对相关功能进行定制化开发，而且要足够快速和灵活，这就要求对技术方案具备自主可控能力，此时适合采用软件方案，测试/实验环境也可采用软件方案。如果对稳定性/性能要求很高（如金融行业的重要区域），或者没有相关自己的SDN团队，建议选用商用的SDN方案。

3. 与OpenStack对接的难点分析

SDN和云平台对接并不是一件易事，就拿目前最常用的OpenStack来说，在和SDN对接时存在很多难点：首先每半年一次的OpenStack的release，给对接及后续升级带来了很大的困难；此外，OpenStack与SDN之间的数据同步，都是在落地SDN的过程中企业需要考虑的东西。

（1）版本问题

OpenStack社区版本更新频繁，SDN如何实现与OpenStack云平台实现无缝升级、修复。从某种程度来说，Openstack最本质要求是为了满足生产的需求。对于测试环境，我们可以频繁进行版本更新，体验新版本带来的新功能、新特性，但对于已投产的现有Openstack平台，由于Openstack大多是非常重要的IT基础设施，与新功能相比，平台的稳定性往往更加重要。因此，Openstack并不推荐跟随每个版本进行升级，而是关注版本的发布内容，选择合适时机进行升级。为了确保平台可升级性，Openstack在二次开发阶段尽量保持后端核心代码的与社区版本的一致性，避免进行大量的代码修改。

对于商用SDN厂商来说，它们也会发布对应openstack的SDN插件，用于SDN与Openstack的对接。

（2）SDN与Openstack配置一致性问题

Openstack与SDN的配置信息都保存在本地数据库中，正常情况下，两者信息应保持一致。如果出现某些异常情况，如Openstack配置下发给SDN，Openstack信息入库，但SDN在将配置下发至网络异常。SDN控制器与网络设备往往有比较强的配置一致性措施保证，SDN与Openstack之间的配置一致性将需要重点考虑，为了解决这问题，可采用事务确认的方式。

4. 方案设计

4.1 Neutron架构

Neutron作为OpenStack的核心组件之一，它只有一个主要的服务进程neutron-server，它运行在网络节点上，提供RESTful API作为访问Neutron的入口，neutron-server接收到用户HTTP请求，最终由遍布于计算节点上和网络节点上的各种Agent来完成。

Neutron提供的众多API资源，总体可以分为核心资源和扩展资源两类。其中L2层的抽象network/subnet/port属于核心资源，其他层次的抽象，包括router以及众多的高层次服务则是扩展资源。Neutron利用Plugin的方式组织代码，每一个Plugin支持一组API资源并完成特定的操作，这些操作最终由Plugin通过RPC调用相应的Agent来完成。这些Plugin又做了一些区分，提供基于二层虚拟网络支持的Plugin称为Core Plugin，其他的Plugin则被称为Service Plugin，比如提供防火墙服务的Firewall Plugin。Agent一般专属于某个功能，用于使用物理网络设备或一些虚拟化技术完成某些实际的操作。

Neutron的完整架构图如下图所示：

4.2 对接方案设计

SDN对接OpenStack云平台采用在Neutron Server中安装SDN控制器插件的方式，接管OpenStack网络控制。OpenStack插件类似于一个硬件driver，以网络组件Neutron为例，Neutron本身实现抽象的虚拟网络功能，Neutron先调用插件把网络配置下发到控制器，然后由控制器下发到具体的设备上。

SDN 控制器实现了上述插件的功能，在插件里通过REST API把Neutron的配置传递给控制器，控制器进行网络业务编排通过Netconf、OVSDB等手段下发到硬件交换机上，以实现相应的网络功能。

根据SDN实现方式的不同，对接方案可以分为软件方案和硬件方案两种。

（1）软件SDN对接方案

以使用开源技术框架为例，核心控制层采用开源控制器ODL，上层编排仍使用OpenStack的Neutron，Neutron与ODL之间使用ML2 plugin进行对接；底层数据层使用OpenvSwitch（下文简称OVS）进行网流转发交换，并通过OVSDB与Openflow协议与控制器对接，其中OVSDB负责对OVS进行配置，Openflow则负责实现所有的数据转发功能现。整体框架图如下：

（2）硬件SDN对接方案

思科的ACI，华为的AC，华三的VCFC都是硬件的SDN解决方案，在性能方面相比软件SDN要好很多。本方案以华为的AC和OpenStack对接为例。

AC控制器作为华为敏捷数据中心网络解决方案在SDN领域落地的标识部件，基于ODL开源平台设计，具备对外提供标准接口实现与云平台、计算管理平台、第三方控制器、第三方OSS等部件的对接能力。这里重点介绍云开源OpenStack平台对接的方案。

AC北向提供标准的Neutron REST API的接口，通过在云平台Neutron组件中插入Agent或使用Driver的方式，实现从用户业务到Fabric配置的逻辑抽象与协同下发。

另外，AC控制器还提供接口，具备对接第三方SDN控制器的能力。对于对接第三方SDN控制器接口，需由第三方或者华为公司定制开发。

4.3 SDN控制器高可用方案

一旦SDN在生产落地，那么作为整个网络的大脑，SDN控制器就成了整个数据中心的重中之重，自然其高可用能力是容不得半点马虎的。高可用的实现主要是两个重点：一是能够快速识别出故障并切换到备用节点；二是保持数据的统一性。

目前大部分的开源 SDN controller 都支持 HA（如：ODL、Flooldlight），商用的SDN也都有各自的HA方案。哪怕我们开发设计一个 HA 模式也不是一件代价很大的事情。HA 模式确实可以解决 SDN 控制器的单点故障，但是无法解决SDN控制器的首包处理的单点性能瓶颈。

首先了解一下 SDN controller 的高可用实现原理：

OpenFlow（>= 1.2）协议本身就支持对交换机的角色管理。对于交换机，SDN控制器有Master、Slave两种角色，并且在同一时间只有一个Master。不同的角色有不同的权限，当然这个可以通过 SDN 控制器修订。简要说 Master 角色可以接收首包、推送流表、监听交换机的信息等等，而Slava角色只能监听交换机的信息。SDN控制器可以通过OpenFlow协议要求交换机更换角色SDN 控制器的高可用就是基于这样的规则下实现的。假设其中一个 SDN控制器出现故障，另外的SDN控制器马上要求交换机切换角色即可。

下面是SDN控制器主/备设计模型：

这就是 SDN 控制器的HA 模型。当Master控制器出现故障，Slave控制器通过心跳线感知，马上要求vSwitch切换角色。Slave 控制器变成Master。等故障的控制器重启，角色变回Slave即可。

但是这个方案有一个明显的缺点，同一时间只有一个 SDN控制器在工作，这样整体的网络规模受限于单个SDN控制器的首包处理性能。Slave控制器 的存在无法分担首包的压力，这样的工作模式不太好。

下面是SDN控制器主/主设计模型：

这是HA模型的演进版，SDN控制器1既是交换机1、交换机2的Master，又是交换机3、交换机4的Slave。SDN控制器2既是交换机3、交换机4的 Master，又是交换机3、交换机4的Slave。假设SDN控制器1出现故障，SDN控制器2会接管交换机1和交换机2。这样的设计有效地分摊了SDN控制器的首包压力。

硬件SDN控制器往往采用主/主设计模型，以华为Agile Controller为例，其采用分布式集群方式部署，集群具备北向负载均衡能力，接受云平台API主动请求或Web访问时，会将请求发送到不同的集群成员节点上。集群具备南向负载均衡能力，全数据中心网络设备被均匀分配，由不同的集群成员节点负责管理。其中一个成员节点发生故障时，它所管理的网络设备可平滑迁移到其他正常运行成员节点上，保证管理业务不中断。

5. 实施运维经验

传统网络由具有集成控制和数据转发平面的设备组成，因此每个设备都需要独立配置和管理。SDN架构中控制和数据平面的分离使控制能够从设备中抽象出来并集中化，以便网络管理员可以集中控制管理底层复杂的基础设施。因此，SDN给传统运维带来了翻天覆地的变化。

（1）极大的减小网络配置工作量

SDN对接openstack后，操作人员通过openstack平台执行各项操作，SDN控制器自动下发相关配置至网络设备，完成网络开通，期间无需人工干预，大大减小运维人员工作量，这也是云环境下多租户、租户自助化实现的基础。

（2）增加故障排查的复杂性

在传统网络下，运维人员具备网络技能，即可独立进行网络故障排查。但在SDN环境下，从openstack图形界面到AC控制器，并最终到网络设备配置下发，中间环节较多，一旦出现问题，需要调集openstack管理员、SDN管理员、网络设备管理员一起排查。在人员技能不充分情况下，虽然操作便利性得到大大提升，但对于异常情况下的故障排查，则增大了复杂性。

（3）郑重选择技术路线

在选择SDN技术路线方面，不同厂商的SDN技术方案互不兼容，一旦选择了某一家技术路线，从兼容性、稳定性考虑，后续扩容也将继续采用同一路线。因此，在选型之初，需充分评估SDN厂商的实力、企业自身SDN团队人员能力。如果厂商支持力度/产品力不够、SDN团队能力不足，将可能在后续运维中面临极大的挑战，甚至难以应对。

因此，虽然采用SDN对生产运维带来挑战，但考虑到SDN发挥的巨大作用，采用SDN仍是今后的技术发展之路。

6. 总结

以上内容对项目背景进行了介绍，同时描述了项目具体的需求。然后介绍了技术路线，包括软件和硬件两种，并对这两种技术进行了简单的对比。接下来阐述了SDN和OpenStack平台对接面临的几个技术难点，主要包含三类：版本问题、多环境问题和一致性问题。在技术方案部分，同样从软件和硬件SDN两方面详细介绍了和OpenStack对接的技术细节。最后简单介绍了SDN给三个运维阶段带来的变化，对比传统的网络结构，SDN能在很大程度上简化网络运维人员的工作复杂度。