yuanruxu
作者yuanruxu2018-05-14 15:09
系统运维工程师, 中国银联

基于金融云的开源软件SDN网络方案项目需求分析实践分享

字数 6995阅读 6854评论 2赞 11

简介

近年来,随着金融数据中心云化的加速,金融云作为最新的基础设施形态开始被行业认同并接纳。但在金融云环境下,传统网络技术架构受到了挑战:一方面虚拟化思想的出现,颠覆了原有的数据中心网络模型,使得传统网络技术已不足以适配云环境下产生的新场景,如虚拟机的出现要求网络颗粒度从物理机细化到了虚拟机级别;另一方面面向互联网的金融创新业务的快速发展,也会对网络的性能、弹性等特性提出更高的要求。所以未来金融数据中心网络技术必将进行变革式的创新发展。

软件定义网络(SDN)技术通过分布式架构理念,将网络中数据平面与控制平面相分离,从而实现了网络流量的灵活控制,为核心网络及应用的创新提供了良好的平台,其与金融云网络发展趋势相契合,是实现金融云网络服务的有效支撑技术。

项目背景

中国银联自2014年启动软件定义网络(SDN)技术在金融云环境下的应用研究,长期跟踪SDN技术在国内外金融行业的研究进展,并积极推动SDN技术在银联生产环境的应用以及与银行金融机构的合作研究。2017年,银联对SDN软硬方案的研究测试工作均已完成,两套方案全部落地生产。

银联私有生产云采用华为SDN整体硬件方案,银联生产托管云则采用Neutron+OpenvSwitch的软件SDN方案。当前实现了网络二/三层、负载均衡、防火墙等多网络资源服务,承载了近期银联与相关合作金融机构的关键应用,有效支撑了银联业务创新。

当前,公司结合当前生产现状与行业技术发展趋势,开展下一代金融SDN相关技术研究工作。本项目主要针对公司当前应用的基于Neutron的软件SDN网络方案所存在的不足进行进一步地研究优化,从而满足下一代金融云的网络要求。

项目范围

SDN技术的应用颠覆式地改变了金融数据中心网络架构,因此基于对网络发展趋势与具体需求的分析,在云环境下构建新一代的SDN网络需进行针对性的设计。据此提出了金融云数据中心整体网络架构,具体如下图所示。
1.png

1.png

图1 金融数据中心整体网络架构

首先,根据数据中心网络构成,将整体网络分成了三个部分,具体如下:

1.区域网络,也就是我们常说的一个云平台Region的网络,业务系统就运行在该区域内。其网络方案可分为硬件方案和软件方案。网络设备包括区域交换机、区域内控制器、负载均衡;

2.核心网,核心网就是连通各个区域的网络,主要设备包括核心交换机;

3.数据中心网络,其实称为数据中心外联网络可能更准确一些,负责数据中心与外部网络的连通,其与外部骨干网连接,主要设备包括边缘路由器。

网络分区确定后,随后就根据各个分区的能力边界构建各自的网络资源池,并对各个资源池能力进行标准的API接口化实现。

最后,在顶层设计一个统一的网络能力编排系统,将各个资源池的能力通过API对接的方式进行上收,随后根据权限配置将不同网络区域的能力下放至相应的管理员与应用系统。

本次项目范围属于图片中的红色区域,即对一个云区域内的网络方案研究,采用软件SDN进行方案设计以及相关技术储备。

问题与挑战

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

而在软件SDN的解决方案中,网络的功能是通过软件层面的Linux协议栈以及相关的虚拟交换机技术实现的。它的优点可以避免对硬件网络设备的过度依赖,同时降低了组网的成本,但是软件方案的缺点也比较明显,主要表现在网络的稳定性、性能和可扩展性不如硬件方案。
当前公司生产环境中使用了基于Neutron的软件SDN方案,来支撑相应的业务运行。但随着公司业务的快速发展,云平台规模的不断增加,当前方案在性能、稳定性以及可扩展性上的短板会逐渐地显露,从而导致业务的连续性受到影响。

因此本项目主要针对上述问题,对当前公司数据中心应用的软件SDN方案进行优化完善,研究出更新一代的金融云软件SDN网络方案并进行实现,最终完成在公司研究云环境下的落地。

项目需求与规划

首先在对方案的能力设计上,我们结合了当前金融数据中心针对软件SDN方案的需求来进行规划,主要围绕上文中提到的三点问题。具体如下。

1.性能增强

首先性能是软件SDN方案较硬件方案来说比较明显的短板,在性能上我们从两个层面上进行优化。一是要简化物理机内部的网流转发路径,如Neutron方案下物理机内部的网桥有三层,过多的网桥数量势必减缓对网络数据的处理速度,所以要简化;二是要优化物理机外部的网流转发路径,如Neutron方案下所有跨网段通信的流量全部要绕至专门的网络节点进行路由转发,给性能带来较大的影响。

2.稳定性增强

然后是金融行业着重关注的稳定性上,我们也有相关的能力设计考虑。一是由于节点数量的规模快速增长所导致的广播风暴会对网络造成极大的损伤,因此本方案中将会针对该问题进行解决;二是优化网流路径,精简网流数据的处理节点,进一步减少网流转发中存在的风险点,并且打破集中式的网络瓶颈,采用分布式架构实现。

3.可扩展性增强

最后是为应对业务流量的突发式增长,方案在支撑资源的可扩展性上也有相关考虑。主要是网络能够打通跨区域的计算资源,并且做到在多租户环境下实现跨区域资源的互通。

4.云平台对接问题

网络方案能够落地必须要完成与现有云平台的对接。当前生产云平台使用的是openstack方案,因此网络方案需完成与openstack云平台的对接。

上述是项目的能力设计需求,除此之外我们对项目在技术选型方面的需求也进行了思考与规划,具体如下:

首先整体方案的技术框架我们依然需要采用基于开源技术实现。一是因为金融行业的一些特殊需求需要对相关能力进行定制化开发,而且足够快速和灵活,这就要求我们对方案具备自主可控的能力,采用商业软件是做不到的;二是如果从头进行开发将会消耗大量的时间经历,基于开源技术则会达到快速实现的目的。

项目具体能力设计

(1)基于虚拟化的多租户支持

多租户虚拟化网络解决方案通过Overlay网络和SDN控制器的相互配合,可以使得逻辑网络与物理网络解耦、控制平面和转发平面分离,进而实现消除网络限制、虚机任意迁移、IP地址灵活分配的目的,从而充分满足用户随时随地接入、业务快速上线、虚机迁移及策略自动跟随的需求。

当前多租户已成为行业云的基本能力要求,但是在私有云中则会根据管理方式选择性部署。但是我们认为随着私有云规模的不断扩大,多租户也必将成为私有云的必需。一方面多租户技术允许网络资源重叠,能够缓解整体网络资源紧张的局面;另一方面多租户概念的引入将会使得不同应用之间的网络逻辑边界更加明显,在方便管理的同时也使得抽象的访问策略更加具象化,提升运维效率。

(2)跨区域互联能力

传统交换网络稳定有余但灵活、高效不足。各网络分区之间计算、存储、网络、机房物理环境等资源均为独享模式,不同分区之间计算宿主机无法共享资源,虚拟机不允许在不同分区宿主机间漂移,计算资源利用率下降。为打破传统分区,本方案将会对基于多租户模式下的跨区域资源互联进行实现,提高资源利用率与应用部署灵活性。

在具体能力实现中,项目采用与银联自研的区域互联系统(以下简称RI,RI具体实现方式请见文章《中国银联与上海银行基于SDN的下一代金融云网络联合研究与应用实践》)进行对接的方案,在数据平面通过Vlan的方式与防火墙进行连通。
2.png

2.png

(3)分布式网络功能

云的本质是分布式计算的一种形式,采用虚拟化技术将集中的物理资源进行切割,并通过网络将资源分散给不同用户。因此,为了更好的契合云计算分布式的本质,避免集中式的网络功能成为云的瓶颈,在进行下一代金融云网络能力设计中,我们将分布式的网络功能作为必备能力。

常用的云网络功能包括网关、DHCP、ARP响应、防火墙在本方案中,防火墙的能力通过硬件实现,所以在此不对其分布式实现进行讨论;DHCP主要作用只是在虚拟机网络发生变化时,向虚拟机下发主机名和IP地址,应用场景少、涉及流量小,并非云网络瓶颈,对其进行分布式实现意义也较小。

而相反,在软件云网络方案中,网关与ARP响应两组功能也全为软件实现,属于网络基础能力,应用频繁。网关是三层通信的流量转发点,不同网络之间的流量通信都必须经过网关进行路由;而ARP响应则是获取目的MAC地址的唯一途径,是二层通信中不可或缺的流程与手段,同时也是区域内正常通信下广播流量的主要来源。因此,对网关与ARP响应进行分布式实现将会较大幅度地提升云网络的效率与稳定性。

综上所述,本项目会对通过对分布式网关和分布式ARP响应能力的实现来提升方案的性能与稳定性。
3.png

3.png

(4)防火墙并联方式接入

防火墙用于提供四到七层网络安全服务,实现逻辑区域之间的安全隔离。

金融云网架构模型中,可将硬件防火墙资源进行池化部署,并按需进行调度,通过云控制平台实现防火墙统一管理。除此之外,金融数据中在防火墙接入形态上采用物理并联、逻辑串联的方式,在防火墙故障的情况下仍能保证业务的正常运行,提升了业务的稳定性。在项目中也将实现该效果。
4.png

4.png

(5)最终能力实现效果

以上能力全部实现后,最终的效果图如下所示。

5.png

5.png

优势与必要性

本次项目目标要求研究下一代基于软件SDN的金融云网络方案,新方案要在性能、稳定性与可扩展性上都要强于当前生产中基于Neutron的方案,且最终能够与openstack云平台进行集成对接。本次项目最终采用开源的软件OpenDaylight(以下简称ODL)作为核心组件,来对整体方案的能力要求进行实现。
6.png

6.png

ODL作为整体SDN架构中的核心控制器在本项目中使用,具备以下优势:

 OSGi体系结构:采用OSGi体系结构,做到了功能的隔离,解决了可扩展性、热部署等等问题;

 SAL(Service Abstract Layer):整个架构中引入了业务抽象层(思科的贡献),使得上层(北向)和下层(南向)之间的调用相互隔离,这个设计模式中的Dependence Inversion Principle 原则一致;

 MD(Model Drive):使用Yang工具,使用业务模型驱动来设计接口、实现业务功能,根据yang文件,Yang工具直接生成业务管理的“骨架”,使开发者真正专注于具体业务。项目实施的预期应用效果;

 丰富的南向接口协议:如OpenFlow、NETCONF、OVSDB、BGP、PCEP等,可集成多厂商多类型的南向设备;

 开放的可扩展北向API(Open Extensible Northbound API):提供可扩展的应用API,通过REST或者函数调用方式。两者提供的功能要一致。

 支持多租户、切片(Support for Multitenancy/Slicing):允许网络在逻辑上(或物理上)划分成不同的切片或租户。控制器的部分功能和模块可以管理指定切片。控制器根据所管理的分片来呈现不同的控制观测面。

 一致性聚合(Consistent Clustering):提供细粒度复制的聚合和确保网络一致性的横向扩展(scale-out)。

ODL已经在很多行业进行部署应用,具有一定的开源SDN控制器市场占有率,在各行各业都扮演着关键的因素。

项目实施的预期应用效果

通过此次项目研究与实施,最终实现金融云的下一代软件SDN方案,并在公司研究云落地应用。相比之前的方案,在整体架构设计与能力实现上都有增强。特别是项目完成之后,网络的性能、稳定性将会有大幅地提升,可扩展性上也会进一步加强。

业务价值

当前金融业务发展迅速,且互联网化的趋势明显。网络作为基础设施的一部分,承载了所有金融业务的运行。因此网络服务的质量将会对金融业务带来最直接的影响。所以网络技术的更新换代将会给金融业务带来积极的影响,比如:

 高安全,金融业务的特殊性对承载网络的第一要求即为保证数据的安全性,因此本项目方案能够抵御系统外部攻击,保证数据完备性与私密性的能力;

 高敏捷,实现业务快速上线,面对应用的变化达到资源的按需变更,通过新技术应用打破因重安全而舍效率的困局,在云计算新环境下安全与高效并重;

 高性能,面对秒杀等新业务场景等的极限服务能力,实现时延和带宽等关键指标的跨越式提升,同时注重资源的高效利用,用尽可能少的资源实现最大的性能服务。

 高可用,网络架构持续稳定影响金融数据中心全局服务能力,项目方案基于稳定可靠的技术构建,使网络服务具备7*24小时业务连续性服务的能力。

企业IT系统价值

项目方案选型全部基于开源软件,因此不存在额外的License费用。而且整体项目属于基础设施层面的技术研究,因此项目系统在公司内将作为基础支撑系统来应用,重要程度较高,且该系统的应用部署不会影响到上层业务应用系统。

运维人员价值

上文中提到,项目采用开源软件作为框架来进行开发完成。相对于传统的有厂商支持的闭源系统来说,开源软件的运维对管理员的技能要求高,需要运维人员不仅能够掌握相关Linux操作系统的操作技能,具备简单的脚本编写能力,而且更需要运维人员能够进行故障定位与排查。

但是在对运维人员有高要求的同时,其在网络管理上也给运维人员带来了许多方便,具体如下:

 物理机内部的虚拟网桥简化,减少了故障定位与排查的难度;

 分布式的网络架构摒除了集中网络节点,降低了整网故障的发生率;

 项目提供可视化的网络拓扑界面,能够帮助运维人员更直观的对云网络架构进行认识和熟悉;

 项目提供丰富的网络运维配置接口,运维人员可以更灵活、快速地对云网络进行配置操作。

风险管理

网络方案作为数据中心的基础技术,若无风险管理机制,一旦出现问题将会直接影响到云平台甚至上层业务系统的运行。因此,在项目中对相关的风险问题进行了规划与准备。

面临的风险

根据实际情况,将项目中可能面临的风险分为以下几类,具体如下。

(1)技术选型风险

项目方案全部采用开源方式实现,在降低成本的同时,也增加了代码漏洞分线与问题出现后的处理难度;同时项目涉及到不同开源软件之间的集成对接,一旦涉及到对接的情况,一般都会有比较多的问题产生。

(2)功能实现风险

本项目的需求面较广,要求较高,其中甚至对云平台网络的应用场景进行了丰富。在这里不得不考虑由于场景的增加而对相关的能力实现机制所带来的影响,极有可能造成相关能力实现机制的修改,增加了项目难度。

(3)时间期限风险

对于经过批准的或者是已经在开发中的项目,其风险点通常落在项目是否能在预算内、按期、高质量地交付,能否及时完成落地,不会因为本项目的延后而导致其它业务系统不能准时上线。

(4)运维风险

项目落地使用后,由于运维人员操作不当而造成的系统故障以及相关网络服务与资源的异常。

风险定级

针对可能的风险,在项目的初始阶段可以定义出风险的级别,便于分析和启动应对措施,避免风险的发生,将问题尽快解决。本项目采用1-3级的方式,对风险进行划分,具体如下:

高风险:方案能力实现不完善,造成严重的系统异常,导致网络不问题,影响业务正常访问,造成严重系统异常;

中风险:系统异常,不影响存量业务使用,但对新增业务不能提供网络服务;

低风险:系统轻微异常,未对业务造成影响。

7.png

7.png

应对措施

针对各类风险所产生的原因不同,项目前期也制订了相关的应对措施,具体如下。
8.png

8.png

9.png
9.png

预算评估

成本分类

软件开发费用
系统维护费用

设备构成

项目工作为方案制订和软件开发,且采用开源软件,因此费用中无设备构成。

成本估算

软件开发费用:40万
系统维护费用:10万

运营成本

项目没有涉及到业务类系统,且为公司内部使用,因此不需要运营费用。

时机选择

在公司研究云扩容完成后,方案会在新增云区域内进行部署

关键技术路线选型

技术选型

本次方案研究中,我们依然采用开源技术框架来进行实现。核心控制层采用开源控制器OpenDayLight(下文简称ODL),上层编排仍使用OpenStack的Neutron,Neutron与ODL之间使用ML2 plugin进行对接;底层数据层使用OpenvSwitch(下文简称OVS)进行网流转发交换,并通过OVSDB与Openflow协议与控制器对接,其中OVSDB负责对OVS进行配置,Openflow则负责实现所有的数据转发功能现。整体框架图如下。
10.png

10.png

选型标准

平台基于OpenStack、OVS、ODL、Centos等开源软件进行研发,相应软件版本情况如下表所示。
11.png

11.png

相关软件版本的选型依据都是对标当前公司研究云现有环境的软件版本来新进选型。

结束语

以上内容对项目背景进行了介绍,主要描述了项目具体的需求以及相关的规划,并对项目的预期效果与价值进行了评估。整体总结下来可以看出,本项目的目标是研究下一代基于软件SDN的金融云网络方案,其中需要实现的需求较多,难度也较大,因此我们对本项目的一些风险点也进行了预估。最后对阐述了项目的整体技术路线,大概介绍了项目所涉及软件的选型标准,让大家从技术层面对项目有了一个初步的了解。

后续我们会从实践的角度,将项目中的更加技术性、更细节的内容呈现给大家,如有问题也请各位多多指正。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

11

添加新评论2 条评论

wuwenpinwuwenpin软件开发工程师, 南京
2018-05-15 20:44
学习了
wanggengwanggeng系统运维工程师, 某银行
2018-05-14 18:06
请教下:软硬两种方案是分别验证?还是整合在一个环境中验证的?

yuanruxu@wanggeng 软硬SDN两种方案在一套环境中是不能同时共存的,所以需要分别验证。

2018-05-15 20:25
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广