本文来自：http://url.cn/5KIoV3g
1物理拓扑
银联金融云的物理网络层面采用硬件SDN方案，基于Vxlan组网，通过与硬件SDN网络进行对接，实现云网联动，大大提升了数据中心的资源交付效率。将云与硬件SDN网络进行对接并成功投入生产用于关键业务的案例，在中国的金融行业中尚属首例。
在银联金融云的物理设备层面，共分为x86服务器、接入交换机、核心交换机、边界交换机、边缘设备等多种角色，其中接入交换机（以下简称server leaf）主要用于x86服务器的接入，核心交换机（以下简称spine）用于连接所有其他交换机，并专门负责高性能的数据转发，边界交换机（以下简称border leaf）主要用于接入边缘设备，同时边界交换机也是该SDN网络与其他外部网络区域互联的出口。
如上图所示：
a)server leaf通过2个40GE接口组成堆叠、通过4*40GE接口交叉上联到spine、通过10GE接口下联到x86服务器。
b)spine通过4*40GE接口交叉连接server leaf以及border leaf。
c)border leaf通过2个40GE接口组成堆叠，通过4*40GE接口交叉下联到spine，通过2*10GE多模连接硬件防火墙，通过4*10GE多模连接F5。
d)x86服务器双网卡绑定，采用Link Aggregation Control Protocol (LACP)模式。
e)全网采用硬件SDN分布式Vxlan方式组网。border leaf、spine、server leaf的underlay路由采用动态路由协议Open Shortest Path First (OSPF)，overlay主机路由通过EVPN协议进行扩散，border leaf通过BGP协议发送和学习远端网段路由。
2高性能
对系统高性能的要求通常是指充分发挥硬件的处理能力，提升平台整体处理性能。例如：系统本身应当是并发处理的，系统内部不应有单点的性能瓶颈、使用异步调用代替同步调用、将需要频繁访问的参数或配置数据等信息一次性加载到内存中、利用负载均衡技术提升系统的并发处理能力等。
2.1 硬件
选用10G接口下联，40G接口上联的接入交换机，充分保证了业务带宽；同时选用硬件防火墙、硬件负载均衡器以充分利用硬件达到更快的处理速度；x86服务器中采用10G网卡，并对双网卡进行绑定以增加带宽和冗余度。
2.2 软件
为了稳定地支持更大规模的集群，银联金融云将节点按不同角色分开部署，分别部署在单独的物理服务器中，在提升了整体平台处理能力的同时，也方便了运维管理。银联金融云的控制区域共由5种角色的服务器组成，如下：
|
类型 |
描述 |
|
控制节点 |
主要运行Portal以及OpenStack各组件的API服务 |
|
网络节点 |
主要运行DHCP服务以及Metadata服务 |
|
MySQL节点 |
主要运行数据库服务 |
|
RabbitMQ节点 |
主要运行消息队列服务 |
|
计算节点 |
主要承载虚拟机 |
2.3 DPDK（数据平面开发套件）
银联在满足生产业务系统运营要求的同时，也在不断地研究、探索很多前沿技术，不断追求更高的性能。
(1)概述
DPDK是Intel公司发布的数据平面开发套装，用于快速数据包处理的函数库与驱动集合，可以极大提高数据处理性能和吞吐量，提高数据平面应用程序的工作效率。银联将其与Open vSwitch（以下简称OVS）结合，加快OVS的数据处理，提高网络包吞吐量，以此提升整体网络性能，避免性能瓶颈。
为了能更好地探究和证实OVS和DPDK结合后的加速结果和性能，银联在多个隔离的区域部署了不同的SDN环境来模拟不同的试验场景，测试环境的总体架构如下所示：
测试环境的总体架构
在开源解决方案的场景中，OpenStack（L版）+ OpenDaylight（以下简称ODL）+ OVS软件定义方案的总体架构如下所示：
控制节点的Neutron Server接收请求-->ML2 Plugin处理请求-->ODL驱动将请求送至ODL控制器-->ODL控制器产生相应的流表项-->并将其送至各个计算节点的OVS；
由于Neutron模块的二层交换，三层路由以及LBaaS功能都由OVS的流表实现，计算节点上的OVS采用了 DPDK技术，OVS与DPDK的结合能够加速OVS的数据处理并提高整体性能。
在进行OVS和DPDK结合后的加速结果和性能实验之前，首先就无DPDK技术的实验环境进行测试，来证实引入DPDK技术的必要性，分别在四个区域中各自部署一套三层交换场景来测试经过VLAN模式的三层交换后的虚拟机的IPERF性能，四组实验分别采用OpenStack社区版的L3 vRouter路由器，商业路由器及硬件交换机来做性能的对比实验。
实验主要的配置如下所示：
其中，硬件配置为：
1. CPU Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
2. Network adapter Intel 82599ES；Memory 128G
软件配置为：
1. CentOS7
2. OpenStack Liberty
3. OVS 2.4.0
4. Libvirt 1.2.16
5. QEMU 2.1
上图为对比实验的结果，从表中数据可见，基于纯x86开源解决方案（方案1）的性能与硬件解决方案之间有一定的差距，方案2（商业纯软方案）在性能上有一定的提高。这个性能瓶颈主要是由于OVS开源模块在二层交换时造成的。因此，我们需要改变物理网络的网卡模型并引入DPDK技术。
随后，在实验环境中引入DPDK技术，进一步探索DPDK技术引入后的性能变化。我们需要构建两个新的实验区域，在一个区域内是采用普通的OVS，另一个区域内是采用了DPDK技术的OVS交换机（以下简称DPDK OVS交换机），并采用Qemu技术启动虚拟机来测试虚拟机间的IPERF性能，实验场景分为普通OVS + vLAN、普通OVS + VxLAN、DPDK OVS + vLAN、DPDK OVS + VxLAN四种。
其中，新环境中的软件和硬件配置为：
硬件环境：
1. CPU Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz
2. Network adapter Intel X710 for 10GbE
3. Memory 160G
软件环境：
1. CentOS 7
2. DPDK 16.0
3. QEMU 2.5.1.1
4. OVS master(CommitID:cd8747c542544fcbfcc91dfb983915812922b4c4);
(2)DPDK PktGen性能测试
在服务器1上安装PktGen软件，在服务器2上安装普通的OVS或是采用DPDK技术的OVS；服务器1通过PktGen软件发送数据包，该数据包经过服务器2后返回服务器1的另一个端口，随后统计两台OVS间的带宽。
实验架构图如图所示，用来测试DPDK数据层转发的基本性能,本次实验的测试的数据包长度为64字节和128字节。
DPDK PKtGen的性能测试结果如下表所示，从中可以看出DPDK OVS在小数据包的情况下有明显的优势（可达10Mpps每秒包数），而普通的OVS有明显的性能瓶颈，最高的吞吐量仅在1.5Mpps。
|
配置 |
吞吐量(Gbps) |
|
普通 OVS 64字节长度数据包 |
0.877 |
|
普通 OVS 128字节长度数据包 |
1.531 |
|
DPDK OVS 64字节长度数据包 |
5.403 |
|
DPDK OVS 128字节长度数据包 |
9.716 |
(3)虚拟机网络性能测试
在两台物理机上安装普通或是采用DPDK技术的OVS交换机，将物理网卡绑定DPDK，启动OVS，添加网桥（隧道VxLAN模式），随后采用Qemu来启动虚拟机，将他们连接到OVS，并通过IPERF指令来测试性能。
实验架构图如图：
用于在两个虚拟网络环境（vLAN/VxLAN）中测试DPDK OVS的转发性能，并与普通的OVS作对比。在实验中，采用IPERF工具测试分别在vLAN和VxLAN网络下的TCP带宽，采用ping和top命令来记录延迟和CPU利用率。
实验的数据总结如下表所示：
虚拟机网络性能实验结果
|
一对虚拟机间的吞吐量（Gbps） |
一对虚机间的延迟(ms) |
最大吞吐量情况下可以支持的虚拟对数 |
总吞吐量 (Gbps) |
平均延迟(ms) |
|
|
VLAN+OVS |
9.27 |
1.334 |
1 |
9.27 |
1.334 |
|
VLAN+DPDK-OVS |
7.49 |
0.168 |
2 |
9.32 |
0.330 |
|
VxLAN+OVS |
3.53 |
1.802 |
未进行三对虚拟机测试 |
未进行第三对虚拟机测试，两对虚拟机的总吞吐量为7.69 |
1.627 |
|
VxLAN+DPDK-OVS |
4.93 |
0.061 |
2 |
8.55 |
0.097 |
通过实验数据的对比，可以发现：
（1）DPDK OVS在传输延迟上有显著的优化，相比于普通的OVS，可以降低10%的延迟，
（2）关于一对虚拟机的带宽情况；普通的OVS在TSO和GRO默认开启的情况下，在VLAN模式下吞吐量接近于线性。DPDK OVS的带宽为7.5G，GRO在DPDK OVS的代码中默认关闭。由此可知，TSO和GRO对于性能有显著的影响。在VXLAN的模式中，DPSK OVS的带宽相比于普通的OVS交换机提高了近40%，
（3）两对虚拟机的带宽情况；普通OVS和DPDK OVS在VLAN的模式下都接近于线性，在VXLAN的模式下，DPDK OVS的带宽要略高于普通的OVS。
(4)总结
DPDK OVS相比于普通OVS在传输延迟上有很大的提高，同样也在VxLAN场景中对性能也有很大的提升。银联将其与OVS结合，加快OVS的数据处理，提高网络包吞吐量，以此提升整体网络性能，避免性能瓶颈。
3高可靠性
系统高可靠性要求通常是指系统应具有在各种故障发生时的自动处置能力，尽可能降低故障对业务处理的影响性，系统具备长时间稳定运行的能力。例如:系统中各个层面的设备均不存在单点、单台设备内部各部件需实现冗余、系统具有较强的故障检测和主被动隔离机制、系统具有故障自动恢复能力等。下面分别从硬件高可靠、软件高可靠、计算节点高可靠、虚拟机高可靠、业务高可靠几个方面进行阐述。
(1)硬件高可靠
如上图所示：
1. 服务器双网卡绑定双归接入，负载分担，如果服务器接入链路故障，业务会自动切换到备份链路，业务不受影响，
2. Server leaf采用双机堆叠，如果其中一台发生故障，业务自动切换到另一台server leaf上，业务不受影响，
3. Server leaf与spine之间有多条链路实现ECMP，如果上行链路故障，自动切换到冗余链路上，业务不受影响，
4. Spine与server leaf形成ECMP，如果其中spine设备发生故障，流量从另外一台汇聚设备上行，业务不受影响，
5. 堆叠的链路实现双主检测，如果链路故障，双主检测可以避免设备双主，系统会down掉备份设备的业务端口，避免网络环路，
6. 如果F5和防火墙互联发生故障，F5和防火墙双主检测可以避免发生主备切换。
(2)软件高可靠
1. 控制节点上的无状态服务，例如nova-api，neutron-api, cinder-api, ironic-api, manila-api, keystone-api, glance-api, ceilometer-api等，通过前置HAProxy的方式实现高可靠，当某台控制节点发生故障时，由于HAProxy有多个后端，因此云平台不受影响，
2. 5台控制节点上的有状态服务，例如HAProxy自身，使用Pacemaker + Corosync通过VIP的方式保证其高可用，当VIP所在节点不可用时，Pacemaker + Corosync会将VIP迁移至其他节点，继续提供服务，
3. 3台MySQL节点，采用MySQL + Galera的方式自行组成cluster，三个节点的数据保持强一致性,当其中一台节点不可用时，不影响MySQL整体功能，
4. RabbitMQ节点，采用RabbitMQ自身的机制，组成cluster，并启用Mirror Queue机制，复制消息队列到不同节点。当其中一台节点不可用时，不影响QabbitMQ整体功能。
(3)计算节点高可靠
通过在控制节点上部署Host-HA后台进程，定期探测计算节点意外宕机的情况，可以避免意外宕机而影响业务的情况。
具体原理为：
Host-HA进程每隔10秒钟（可自定义检查间隔时间）检查本Availability Zone（AZ）内所有计算节点状态，检测方法包括通过IPMI获取计算节点电源状态、Ping计算节点控制网IP、存储网IP测试网络连通性、SSH登录到计算节点检测业务网对应的网卡状态。若检测到电源状态为关闭，则判断计算节点故障；若计算节点控制网IP、存储网IP长时间Ping不通或者业务网卡Down，则判断计算节点的控制网、存储网、业务网故障，将上述几种检测结果排列组合得到不同的故障场景。
针对不同的故障场景，通过预定的策略对运行在该计算节点的虚拟机在相同AZ内进行Migrate或者Evacuate，将其迁移到正常节点。迁移完成后，可在平台上看到虚拟机的迁移轨迹。当故障节点恢复后，管理员可以方便的通过平台激活该计算节点。
(4)虚拟机高可靠
有些业务并不能通过集群等手段实现高可用，需要对这些类型的单个虚拟机进行监控，当出现如虚拟机内部Crash、意外关机等故障时，根据预先设定策略，采取措施恢复虚拟机，即实现虚拟机的高可用。
具体原理为：
在计算节点上运行VM-HA后台进程，执行定时任务，调用OpenStack接口查询运行在本计算节点上的运行或关闭状态虚拟机，通过调用Libvirt获取虚拟机状态，检索虚拟机日志等方法，检测虚拟机是否发生异常，若发生异常则根据配置策略，对虚拟机执行相应动作，恢复虚拟机正常运行。
(5)业务高可靠
为了避免商业NAS存储的整体性单点故障，银联采用了多Availability Zone（AZ）分散部署业务系统的方案。数据中心部署了多套独立的商业NAS存储，以及Ceph分布式存储，每个存储系统与AZ一一对应，当操作人员批量创建虚拟机时，Portal层将多个虚拟机自动分散至不同的AZ中。
由于所有的业务虚拟机多个实例作为后端统一挂接到前端负载均衡器之后，即使单个NAS存储系统损坏，也不影响业务系统的整体可用性，从而实现了云平台在AZ级别的高可用性，同时对镜像拷贝做了缓存优化，保证虚机的快速创建。
4高扩展性
系统高扩展性的要求通常是指系统应具有通过增加硬件资源来获取更高处理能力的能力，系统应具有对业务变化的灵活适应能力，尽可能降低业务变化对系统架构的影响。例如:横向扩展性、纵向扩展性、支持在线增加节点、采用基于接口的低耦合方式进行系统设计等，下面着重阐述计算资源池的扩展性。
(1)计算资源横向扩容
随着业务的不断发展，如果当前计算资源不足以容纳业务需求时，需对现有计算资源池进行快速扩容，其中包括操作系统的安装、主机名设置、IP地址设置、软件的安装与配置、宿主机安全加固、加入到资源池等内容。由于扩容动作不允许影响生产已有的环境，我们选择通过线下临时交换机二层互联的方式进行批量安装与配置，然后接入到生产中。
扩容的具体步骤如下：
1. 新计算服务器采购到货。
2. 新计算服务器机房上架、连接电源。
3. 逐台设置IPMI地址、IPMI用户名、IPMI密码。
4. 服务器接入到临时交换机、对交换机进行配置保证网络二层互通。
5. 提前收集线上已有计算资源的相关信息，例如IP网段等。
6. 将装有Cobbler并已配置好的操作机接入到临时交换机。
7. 通过ipmitool命令批量重启新计算服务器，从网络方式启动，以使其正确地从Cobbler中自动安装操作系统。
8. 在操作机上执行事先已编写完成的ansible playbook，开始执行主机名设置、IP地址修改、相关OpenStack组件的安装与配置、宿主机安全加固、启动服务等步骤。
9. 切换临时网络到生产网络，新计算资源自动被发现。
至此，扩容工作已完成。
(2)虚拟机热升级
热升级操作界面
金融行业的核心业务系统追求可靠与稳定，当业务虚拟机有纵向扩容需求时，需要尽可能地减少停机时间，甚至不停机。由于OpenStack Nova默认不支持虚拟机不停机在线扩容，银联金融云通过扩展Nova API实现了该功能，可以将一台的虚拟机在不停机的情况下升级CPU和内存，以满足业务系统对资源的纵向扩展要求。
5高安全性
对系统高安全性的要求通常是指系统应具有抵抗外部各种刻意或非刻意攻击的能力。例如:系统管理操作应区分安全级别、系统应具备一定的防止来自内部与互联网攻击的能力、系统应具备一定的审计功能、系统中的数据应使用安全有效的备份恢复策略来加以保护等。
下面首先介绍网络平面的划分以及QoS策略，随后重点阐述Keystone与银联已有的Single Sign On（SSO）系统结合。
(1)网络平面划分
在整体网络Fabric中，运行着各种不同类型的网络流量，为了更好地区分这些流量，根据网络流量的不同类型将网络划分成多个不同的数据平面进行有效的隔离，其中包括管理网，控制网、存储网、业务网、IPMI网，不同网络平面的用途规划见下表所示：
|
网络平面名称 |
描述 |
|
管理网 |
主要用于管理员SSH管理流量以及外围设备的控制信令流量。 |
|
控制网 |
主要用于OpenStack各组件的Rest API调用流量以及组件间的RabbitMQ消息流量。 |
|
存储网 |
主要用于虚拟机访问存储的流量。 |
|
业务网 |
主要用于虚拟机的业务流量。 |
|
IPMI网 |
主要用于IPMI带外管理。 |
(2)Qos限制
针对不同网络平面相应的特点，云平台设置了不同的QoS策略，充分保障了不同类型网络平面不会互相挤占带宽。根据银联多年的运营经验以及银联业务的实际情况，管理网、控制网、存储网、业务网分别设置QoS带宽为1Gb、1Gb、8Gb、10Gb（由于采用万兆堆叠，所以单服务器总带宽为20Gb）。
云平台上也支持针对单台虚拟机设置特定的QoS策略。为了管理员在管理虚拟机时不影响业务流量，平台约定每台虚拟机带有2张虚拟网卡，即虚拟机业务网卡、虚拟机管理网卡，分别用于虚拟机的业务流量和管理流量。
(3)Keystone与SSO
在很多成熟的企业中，通常会存在已经建设好的用户认证体系，例如Single Sign On（SSO）系统，银联也不例外。当企业部署OpenStack时，Keystone与现有SSO系统的集成是必须要面临的问题，银联金融云通过分析现状和定制开发，完成了Keystone与已有SSO系统的对接。
Keystone默认提供的认证机制采用通过颁发Token进行身份验证，用户通过用户名和密码验证登录之后，会从Keystone获取到Token，随后资源请求的HTTP报文Header中将携带Token ID，接收到请求的组件将转到Keystone验证用户Token的合法性并获取到用户的角色进行鉴权。
Keystone是集认证和授权于一体的组件，如果要与SSO认证集成，就需要把Keystone原有的Token验证工作转交给SSO进行处理，接收到验证返回结果之后才能判断Token的有效性，这样会导致OpenStack平台的每一次资源请求操作都将去SSO进行验证。为了避免给SSO带来过大的压力，我们需要在OpenStack平台保持原有的Keystone Token认证机制，用户可以使用TGT来获取Token替代之前通过用户名和密码获取Token的过程，之后便可以使用Token在OpenStack平台上进行资源请求和Keystone Token验证了。
Keystone与SSO对接原理图
原理如图所示，具体如下：
a) 当请求到达Portal时，如果请求中未携带TGT，则重定向用户浏览器到SSO登录页面（step 1，2），经SSO认证通过后，将返回一个TGT给客户端浏览器（step 3，4），同时页面会重定向到原始URL，当请求再次到达Portal时已携带了ticket和TGT，ticket将不再做本地认证使用，Portal将TGT发送给Keystone以获取Token，Keystone进而将TGT发送给SSO进行校验，校验通过后Keystone会返回Token，
b) 携带了TGT的请求到达Portal时，直接向Keystone请求获取Token。 Keystone将TGT转发到SSO进行认证（step *2，*3），认证通过会返回Token给Portal，
c) Keystone集成SSO认证，使用TGT验证通过之后，就会给用户颁发Token，随后用户就可以使用Token进一步操作OpenStack平台资源，直到Token过期，Token过期之后将会使用TGT重新获取Token，如果TGT过期，将会跳转到SSO登录页面重新认证。
6高可管理性
对系统高可管理性的要求通常是指系统应具有能够接受各种管理和维护操作的能力，尽可能降低管理操作对系统架构和业务处理的影响。例如:系统应提供清晰简洁的管理界面、系统具备主动进行故障示警能力、具有导入导出报表等管理类功能、系统提供管理命令接口和监控数据接口。下面着重从网络策略组的角度具体阐述。
(1)清晰简洁的界面
银联金融云提供了统一的清晰、简洁的管理界面，管理员可以方便地在平台上对计算资源、存储资源、网络资源、资源编排、管理、全局管理、权限管理等方面进行相应的操作，同时平台也提供了Multi-Region环境下的多个Region概况的统一展示。
(2)网络策略组
银联金融云在虚拟机的网络控制方面采用基于组的网络策略的方式，很好地实现了银联对于虚拟机的网络控制要求，管理员可以在平台上方便地将具有相同网络属性的多台虚拟机归并成组，并指定多个组之间的网络访问规则，这些规则进而会应用到组内的所有虚拟机上。如上图所示，主体功能主要由网络容器、子网、网络组、组间规则等模块共同合作完成。
管理员具体的实施步骤如下：
a) 在网络容器中新建路由域，该路由域与其他路由域默认隔离。
b) 在网络容器中的路由域下新建广播域，即指示平台分配相应的二层隔离的VLAN号。
c) 在广播域下规划和创建子网，其中包括网段信息、DHCP信息等。
d) 新建网络组，并绑定网络组和相应子网。
e) 在组件规则功能中，新建网络组到网络组之间的具体访问规则，其中必要元素包括协议、端口等信息。
到这里，网络规则已经完成，随后在虚拟机创建环节，只需要将虚拟机放入相应的网络组中，该虚拟机即被赋予该网络组具备的网络规则属性，进而方便地实现了虚拟机与虚拟机之间的访问规则控制。
至此，以上就是银联基于OpenStack构建的金融云的基本情况介绍，自2012年投产以来，银联金融云一直稳定运行，有力地支撑了银联众多应用和业务，同时也节约了大量的IT成本，进一步提高了创新能力。
银联深化OpenStack应用满足自身需求的同时，也将五年多来一线运营积累的能力与经验，与上海银行等诸多金融合作伙伴分享，持续扩大OpenStack在金融行业的影响力。
随着OpenStack社区技术的演进，银联与众多合作伙伴共同协作，不断拓展银联金融云的服务功能，更好地为用户、商户、金融机构等伙伴服务。此外，银联也积极参与OpenStack社区工作，为社区发展贡献了一份自己的力量。
欢迎各界合作伙伴与银联共同探讨，让OpenStack更成熟地应用于金融行业、乃至各行业的生产环境中，创造出更大的价值。
浙公网安备 33010602011771号