大家好，我来自恒丰银行的柳东，我为大家介绍一下恒丰银行基于OpenStack构建金融云的实践。我们先看一下恒丰银行的现状，从2015年下半年开始涉及和筹备建设恒丰银行的金融云，恒丰银行建设金融云的初始目标不仅仅建立恒丰银行自用的私有云，而是建立一个银行界的行业云，所以恒丰银行的金融云在建设初期的标准和多租户都是考虑之内的。我们当前优北京、烟台上海三地四个数据中心，目标建立三地六中心的架构，同时又隔离和业务，同时又生产测试环境，也有基础设施自用的实验测试环境。
同时我们是在2016年年中完成了恒丰银行的200多应用全部整体上云，当前的规模达到了500+计算节点，500多存储节点，两百多个应用等等。
恒丰银行在每个网络区域内都有一套独立的OpenStack的环境，一共当前是有八套OpenStack环境组成了恒丰银行整体的金融云。同时在主机层面使用超融合架构，计算存储融合，通过分布式存储提供整体的存储环境。Ceph集群使用纯SSD达到很高的性能，同时在网络方面集成思科的SDN控制器，拉动整体的租户网络，使所有服务器网络灵活控制。
我们看一下为什么恒丰银行在建设金融云的时候使用OpenStack，我们知道大部分金融行业使用最多虚拟化软件还是（英文），恒丰银行在这方面做了充分的考量，我们最终通过充分的讨论，在如下三个方面决定使用OpenStack加KBM的方式。首先OpenStack是一个纯开源的产品，社区有很多的厂商的贡献，然后有很多社区的开发者，这样的话我们对比的话就发现，OpenStack不是一个受厂商绑定的架构。
另外在架构方面，闭源产品往往以license为的形式出现，而在开源产品往往收取的是服务费，同时OpenStack社区集合全球的力量，未来延展性趋势上肯定会逐渐变好的。
OpenStack社区的成熟度当前有6万多的开发者，有600多个共提供支持，涉及到185个国家，OpenStack社区的各个项目代码整体超过了2千万。之后这是OpenStack的六个核心组件，我们知道OpenStack自从使用（英文），OpenStack分成六个核心项目和一个（英文）的项目，OpenStack六个核心项目计算存储网络认证和项目管理方面等等已经足够成熟，达到商用化的程度。
从架构方面来讲，OpenStack是一个分布式的架构，OpenStack各个项目之间是一个高集成的项目，与传统集中式架构相比它的扩张能力非常大，可以使用大环境的使用。作为非私有云而是作为行业云的目标来说，规模是我们追求的一个目标。如果我们使用集中式的东西，最终就会从规模上遇到瓶颈，只能从纵向层面上做一些扩展。OpenStack的架构充分可以支撑我们做行业云的大规模金融云的目标。
这是OpenStack厂商支持，OpenStack分成铂金会员，黄金会员，还有白银会员之类。铂金会员上来讲，有来自于运营商，来自于传统设备厂商，来自于操作系统厂商和一些IDC的厂商，这样我们证明OpenStack的生态是一个很充分的有多家合作的生态。最终我们使用OpenStack为基础构建恒丰银行的金融云。
当我们决定选择OpenStack去构建金融云的时候，就涉及到OpenStack部署的问题，OpenStack社区的版本，不是那么的稳定可靠的，我们要从架构设计层面去解决OpenStack产品的可靠性的问题。OpenStack部署的时候分为几种决策，一种计算节点，一种是控制节点，在控制节点有缓存服务，有DB和内容分发提供LB的节点。每一个控制节点可以做到高活可应用的，并且对金融云的实践实现理论上的无限扩展。同时计算节点上我们部署NOVA服务（英文），以及提供计算服务。整体部署架构上，分为业务网和隔离网。在业务网和隔离网有一个部署控制区，例如监控服务，还有认证服务。在每个机房和每个数据中心里边都分别由其他的控制服务和分布式存储等等。
在高可用方面，除了（英文）服务以外，其他的所有服务都是多活的架构，我们当前部署是三点服务，未来都是可以扩展成其他任意规模的。OpenStack部署完了看如何管理好OpenStack，经过一年生产实践之后，我们发现OpenStack部署只是前期很小的一步，我们向金融云向前走的第一步，后面的管理才是我们使用OpenStack，OpenStack提供好服务以及管理的关键。
为了减少OpenStack的故障，我们基于故障尽可能小的原则，从不同的层面对于OpenStack进行拆分。首先数据中心里面是有多套的OpenStack，多套的划分原则基于网络区划分，每个独立的故障不会影响其他的网络区。同时在一个数据中心内使用统一的认证体系，把（英文）抽离出来，在每个数据中心里边应用（英文）独立服务，并且都与这个做交互。
同时我们把每一套OpenStack里的分布式存储分布了两套，跨机房存储不会影响其他机房。因为（英文）对于OpenStack集群上面可用性来说是整体的故障，通过减少故障率的方式先OpenStack故障以后对整个金融云的影响。
然后是OpenStack的调度，OpenStack当前的开源版本里边，它只有一些基本的调度能力，它基于应用层面跨不同故障率非亲的调度是没有的，我们自研的一套算法，通过（英文）这两个对象的特性做到同一个应用的不同的部署实力，部署在不同的故障率内，让它们做到非亲和的能力，这样就能把一个应用依据从数据中心到网络区到集团模块到机桂到宿主机层面去做非亲和的部署，达到应用整体的高可用。
我们看一下OpenStack的运维，首先运维里面离不开第一项很重要的就是监控，我们OpenStack整体平台基于Zobbix做监控，还有服务的可能性。同时通过Smokeping工具从内部节点向其他节点做网状的网络连通性的探测，包括集群内所有的网络是可用的，而且能够及时发现它的网络终端节点对应故障的点做处理。同时还做了一些模拟应用，这个模拟应用主要目标就是对我整个存储集群和网络集群的可能性做探测，当我整体性出现故障，或者性能瓶颈的时候我可以及时知道，对故障和瓶颈做相应的处理，这样可以对整体的平台做到不放过任何可疑点的全面监控。
还有是云平台的基线管理，通过forman做整个安装，通过puppet做配置管理，通过git做整个金融云所有的平台管理代码基线管理，通过（英文）做整个安全可靠，这样使金融云所有节点是标准统一的节点。刚才所说的OpenStack作为分布式架构的东西，它和（英文）区别是它的可靠性没有它那么高，跟OpenStack相比就是（英文）有一个物理机出现故障后，同时恢复虚拟机的内存。我们对于上云的应用来说，应用本身是要做一些架构层面优化和改造，从应用层面看到高可用性，对于银行业有很多传统应用这些方面是很难解决的，所以我们同时推出虚拟机的服务提高对整个平台的应用型。我们虚拟机服务就是我们虚拟机服务的架构，（英文）各个厂商都有在做，这是他们推出他们产品一个必须的需求。我们这套东西其中有一个很重要的内容，就是我们引擎部分，OpenStack部署架构不一样，它的方式都会有一些稍微的差别，我们就使用自己部署方案的前提，通过我们的引擎库配置适合我们自己虚拟机的规则，这样保证我们HA准确可靠，不会因为HA误判断导致其他节点受到误操作的影响。
同时我们还做了虚拟机的快照和虚拟机的备份，来保证我们应用层面的高可用。另外是虚拟机热迁移，在我们OpenStack金融云一年多的经验以来发现，热迁移的操作几乎是每天每个变更日都要做的。因为我们知道传统X86服务器故障率达到十几次，可能二十次我们通过迁移不断调整整个集群的高可用，对设备做维护，或者对设备做操作系统的升级更新。然后通过热迁移操作就可以大家对应用业务影响敏感知的目标做整个层面基础设施层面的运维操作。
这是我们的目标里边的一个东西，我们参与了社区下面有一个mogan的项目，它对租户提供主机服务，它更使用我们裸机常用使用裸机服务它是和华为共同发起的项目，同时我们推动magan项目在社区里边落地。然后是自动化扩容，为了降低成本我们没有像其他的机构和厂家，一开始上线的时候我们规模都是很大的，我们OpenStack发展到500多个节点规模是逐步扩容上来的，这样我们就可以达到每季度都是一个重新计算成本的基线。然后我们的扩容是基于容量管理，基于监控高警容量预警，通过资源池管理里面，通过自动化装机工具，通过自动安装配置让所有节点能够很快速的扩容。
然后我们当前恒丰银行金融云里边还有一些待完善的服务，比如刚才说到X86裸机的服务，我们存储网络都是预配置的，目标在今年下半年我们会做到结合思科SDN的扩容器，结合我们自研存储的控制器，能够达到对裸机自动配置它的租户网络，自动配置它的存储使用的能力同时完善对小机自动化管理能力，完善对存储的备份服务，这样的话提高我们整体的运维效率，提高整体的服务可靠性。
然后我们会自动化异构我们X86裸机和小机和虚拟机的网络服务，使我们所有的应用可以真正做到对底层设备的类型是无感知的。同时，我们正在逐步完善我们的运维知识库，通过一些自动化的或者现在比较流行的机器学习这些东西，做到对我们的OpenStack集群尽量的自动化运维及可以做到一些基础故障，无人参与和感知的。之后还在完善的DB和容器服务，还有无限存储服务，谢谢。
热门专题
