引言：银联作为金融行业云计算的首批探索者和使用者，在2009年正式启动了云计算的前瞻性研究，并于2012年投产了基于OpenStack Essex版本的国内金融行业第一朵生产金融云。随后的五年间，银联仍然不断探索和演进云计算在金融行业的实践之路，并于2017年实现了银联生产金融云2.0的正式投产，新版云平台引入了更多的新组件及技术，并将作为银联的核心支撑平台，承载更多的关键应用，让银联真正腾“云”翱翔。
首先小编将为大家带来银联金融云的相关背景知识的介绍，以及简要介绍银联金融云的物理部署架构，随后将从“五高”，即高性能、高可靠性、高扩展性、高安全性、高可管理性五个方面分别阐述银联金融云的架构。
其中：
高性能方面，将着重阐述DPDK相关的研究工作；
高可靠性方面，将着重阐述计算节点高可靠和虚拟机高可靠的内容；
高扩展性方面，将着重阐述计算资源池横向扩容的内容；
高安全性方面，将着重阐述Keystone与银联已有的Single Sign On（SSO）系统结合的工作原理；
高可管理性方面，将着重阐述银联如何基于网络组策略来快速实现网络资源和网络策略就绪。
下面为大家带来了《银联基于OpenStack的“五高”生产金融云》的技术白皮书，将为大家逐步揭开银联金融云的神秘面纱。
- 概述
银联金融云简介
基于OpenStack构建，于2012年投产使用，是国内金融行业第一朵OpenStack私有云，随后的五年间，我们不断探索和演进OpenStack在金融行业的实践之路，有序开展技术迭代和业务迁移。目前，银联金融云已具有一定的规模，承载了银联的大量应用和业务，为银联业务发展提供了强有力的支撑。
什么是“五高”？
“五高”，即高性能、高可靠性、高扩展性、高安全性、高可管理性，是金融行业IT架构最为突出的强烈需求和基本要求，银联金融云在规划与实施方面，不断强化“五高”能力，形成了金融行业通用的、可借鉴的技术能力与运营经验，OpenStack在银联的规模化应用，也将成为金融行业的典型案例，发挥积极的标杆与示范作用。
- 银联简介
银联成立于2002年3月，是经国务院同意，中国人民银行批准设立的中国银行卡联合组织。作为中国的银行卡联合组织，银联处于中国银行卡产业的核心和枢纽地位，对银行卡产业发展发挥着基础性作用，各银行通过银联跨行交易清算系统，实现了系统间的互联互通，进而使银行卡得以跨银行、跨地区和跨境使用。在建设和运营银联跨行交易清算系统、实现银行卡联网通用的基础上，银联积极联合商业银行等产业各方推广统一的银联卡标准规范，创建银行卡自主品牌；推动银行卡的发展和应用；维护银行卡受理市场秩序，防范银行卡风险。
银联作为一个家喻户晓的银行卡组织，在国内享有极高的品牌知名度。据权威调查组织A.C Nelson的调查显示，中国国内对于银联品牌的认知程度高达100%，远远超过了其他的银行卡品牌。截止2016年底，银联已经在全球范围内累计发卡达60亿张，银联网络2016年总体年交易量笔数和金额分别约为271.0亿笔和72.9万亿元人民币。
银联的品牌不仅在本国已得到充分认可和信赖，在国际上同样具有极强的影响力和竞争力。截至2017年6月，银联网络遍布中国城乡，并已延伸至亚洲、欧洲、美洲、大洋洲、非洲等境外160多个国家和地区，境外累计开通商户突破2100万户，ATM终端超149万台。中国人钱包里的那再平凡不过的62开头银联卡，已经真正成为了全球发卡量第一、交易量第一的最大银行卡品牌。
银联如此迅猛的发展得益于银联强大的技术创新能力，同时银联也一直影响着亚洲乃至国际的金融IT技术的发展，目前，银联是国内众多金融标准的制定者和推广者，在国际领域，银联的支付IT系统能力已输出到老挝、泰国等地区。
- 银联的OpenStack的部署
互联网时代的金融行业需要更强大的云计算IT架构的支撑，银联预判未来金融云计算技术将更广泛地基于开源技术，其中OpenStack凭借其开源、可扩展性、灵活性、良好的社区生态运作等优势，已经成为事实上的开源标准，也是银联生产金融云的最优选择。
银联作为金融行业OpenStack的首批探索者和使用者，于2012年投产了基于OpenStack Essex版本的国内金融行业第一朵生产金融云，已在生产上稳定运行1500多天。经过五年的研发与运营历程，银联积累了大量的实践经验，组建了一支多达50人的OpenStack专业团队，从事银联金融云的方案架构规划、设计、研发、落地实施、运行维护等工作。此外，银联也积极参与社区工作，由银联提出的组建金融工作组的请求已由OpenStack用户委员会批准通过；同时，银联也参加了Large Contributing OpenStack Operators (LCOO)工作组的相关工作，向社区做出更多的贡献。
银联金融云为银联的业务发展提供了强大的动力，一方面在IT资源上资金的投入大幅减少，另一方面，银联金融云也为银联高速增长的交易量、用户数、商户数提供了强大的计算处理能力支撑。为了提供更强大、更便捷的云资源管理能力，银联于2016年启动了云平台的升级计划，已于2017年下半年完成了银联金融云2.0平台（基于OpenStack Liberty版）的投产。新平台进一步引入了Neutron,实现网络虚拟化；Ironic实现物理机管理；Ceilometer实现平台监控等。同时，该平台也具备了Vxlan模式组网、NAS和Ceph混合部署、域间硬件防火墙纳管、硬件负载均衡器纳管、云平台与SDN网络对接等特点。
银联长期以来与众多金融机构有着非常紧密的合作，特别是在新技术的选型及创新上，持续开展探索与研讨。目前，银联已与上海银行、东方航空等著名企业就OpenStack金融云建设进行合作，联合开展云计算在金融领域中的实施与应用。同时，由银联牵头，联合上海银行、复旦大学等四家单位共同发布了《金融SDN技术能力评测标准》草案，为SDN在金融行业更好的落地生产提供标准的解决方案参考。
- 物理拓扑
银联金融云的物理网络层面采用硬件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协议发送和学习远端网段路由。
5. 高性能
对系统高性能的要求通常是指充分发挥硬件的处理能力，提升平台整体处理性能。例如：系统本身应当是并发处理的，系统内部不应有单点的性能瓶颈、使用异步调用代替同步调用、将需要频繁访问的参数或配置数据等信息一次性加载到内存中、利用负载均衡技术提升系统的并发处理能力等。
。
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的数据处理，提高网络包吞吐量，以此提升整体网络性能，避免性能瓶颈。
6.高可靠性
系统高可靠性要求通常是指系统应具有在各种故障发生时的自动处置能力，尽可能降低故障对业务处理的影响性，系统具备长时间稳定运行的能力。例如:系统中各个层面的设备均不存在单点、单台设备内部各部件需实现冗余、系统具有较强的故障检测和主被动隔离机制、系统具有故障自动恢复能力等。下面分别从硬件高可靠、软件高可靠、计算节点高可靠、虚拟机高可靠、业务高可靠几个方面进行阐述。
(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级别的高可用性，同时对镜像拷贝做了缓存优化，保证虚机的快速创建。
7. 高扩展性
系统高扩展性的要求通常是指系统应具有通过增加硬件资源来获取更高处理能力的能力，系统应具有对业务变化的灵活适应能力，尽可能降低业务变化对系统架构的影响。例如:横向扩展性、纵向扩展性、支持在线增加节点、采用基于接口的低耦合方式进行系统设计等，下面着重阐述计算资源池的扩展性。
(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和内存，以满足业务系统对资源的纵向扩展要求。
8. 高安全性
对系统高安全性的要求通常是指系统应具有抵抗外部各种刻意或非刻意攻击的能力。例如:系统管理操作应区分安全级别、系统应具备一定的防止来自内部与互联网攻击的能力、系统应具备一定的审计功能、系统中的数据应使用安全有效的备份恢复策略来加以保护等。
下面首先介绍网络平面的划分以及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验证了。
原理如图所示，具体如下：
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登录页面重新认证。
9. 高可管理性
对系统高可管理性的要求通常是指系统应具有能够接受各种管理和维护操作的能力，尽可能降低管理操作对系统架构和业务处理的影响。例如:系统应提供清晰简洁的管理界面、系统具备主动进行故障示警能力、具有导入导出报表等管理类功能、系统提供管理命令接口和监控数据接口。下面着重从网络策略组的角度具体阐述。
(1)清晰简洁的界面
银联金融云提供了统一的清晰、简洁的管理界面，管理员可以方便地在平台上对计算资源、存储资源、网络资源、资源编排、管理、全局管理、权限管理等方面进行相应的操作，同时平台也提供了Multi-Region环境下的多个Region概况的统一展示。
(2)网络策略组
银联金融云在虚拟机的网络控制方面采用基于组的网络策略的方式，很好地实现了银联对于虚拟机的网络控制要求，管理员可以在平台上方便地将具有相同网络属性的多台虚拟机归并成组，并指定多个组之间的网络访问规则，这些规则进而会应用到组内的所有虚拟机上。如上图所示，主体功能主要由网络容器、子网、网络组、组间规则等模块共同合作完成。
管理员具体的实施步骤如下：
a) 在网络容器中新建路由域，该路由域与其他路由域默认隔离。
b) 在网络容器中的路由域下新建广播域，即指示平台分配相应的二层隔离的VLAN号。
c) 在广播域下规划和创建子网，其中包括网段信息、DHCP信息等。
d) 新建网络组，并绑定网络组和相应子网。
e) 在组件规则功能中，新建网络组到网络组之间的具体访问规则，其中必要元素包括协议、端口等信息。
到这里，网络规则已经完成，随后在虚拟机创建环节，只需要将虚拟机放入相应的网络组中，该虚拟机即被赋予该网络组具备的网络规则属性，进而方便地实现了虚拟机与虚拟机之间的访问规则控制。
至此，以上就是银联基于OpenStack构建的金融云的基本情况介绍，自2012年投产以来，银联金融云一直稳定运行，有力地支撑了银联众多应用和业务，同时也节约了大量的IT成本，进一步提高了创新能力。
银联深化OpenStack应用满足自身需求的同时，也将五年多来一线运营积累的能力与经验，与上海银行等诸多金融合作伙伴分享，持续扩大OpenStack在金融行业的影响力。
随着OpenStack社区技术的演进，银联与众多合作伙伴共同协作，不断拓展银联金融云的服务功能，更好地为用户、商户、金融机构等伙伴服务。此外，银联也积极参与OpenStack社区工作，为社区发展贡献了一份自己的力量。
版权声明：
除非另有说明，在此白皮书中的所有资料，包括注册商标，设计，文字，图片以及其他的信息的版权均归属于中国银联股份有限公司所有。此白皮书未经过版权所有者允许，不得用于商业用途。
注：文章来源“银联技术”公众号。