银行上私有云基于开源和商业路线选型分析

1、 银行私有云基于开源和商业路线选型分析 银行上私有云，是用基于 OpenStack 的开源技术路线，还是基于 VMware 的商用路线？ 银行上私有云，是用基于OpenStack的开源技术路线，还是用基于VMware 的商用路线？，各有什么优缺点？（问题来自vidc 某商业银行 系统架构师）asdf-asdf cloudstone研究学者：银行应做专业的事情放贷，OpenStack让华为做就ok了，对标VMware进行价格打拼。华为的OpenStack和VMware比，目前技术水平还是有些差距，需继续努力开发。容器目前都是外围系统使用，类似静态网页。金融行业用容器还没看到关键业务上线！日后开发

2、和运维能力提升后，可能用容器或者一步到位用 serverless。崔增顺民生银行 系统运维工程师：建议现在开始考虑容器、微服务、DevOps。得未来者得天下。技术的研究要先于技术的推广。LLWWGG 浪潮商用机器企业云创新中心 系统工程师：1、个人感觉这么区分不是太贴切。基于开源架构OpenStack也有商业解决方案。这与Linux有点类似，Linux本身是开源的，但RedHat却是商业版的Linux。至于说到银行私有云，目前业界应该说都有用到这两种架构，不是互斥的关系，而应该是融合的关系。2、容器本身而言，也是一种资源的调度方式。是否上容器云，银行本身应根据业务特点进行合适的架构选择。作为I

3、T架构而言，是应该要考虑到支持容器相关技术的。light_hu86 浙江农信 系统工程师：对于银行来说，如果自身技术力量不足的话，采用开源的技术路线来自行研发，投入比较巨大，遇到的坑也会比较多。对于采用openstack技术的公司（比如有人提到的华为、华三等公司）还是采用vmware商用的(vRA)来说，看银行自身实际情况进行出发。说白点就是我的需求你能做吗，出的钱你能接受吗。对于vmware这种外商来说，定制化成本比较高。如果还需要同自身第三方系统对接的话，这方面投入会比较大。而对于容器来说，使用的面没有虚机那么广，一般不用在生产系统里，建议还是在观察研究。he7yong Canway 研发

4、工程师：大银行，不用想多了，采用国内比较成熟的私有云产品，如腾讯私有云产品，不仅仅是Openstack和Vmware这一个参考点，更多的需要关注在业务需求，关注在分布式数据库等等；私有云是否考虑上容器云，从业务需求出发，把厂商拉过去交流几次，可能领导就清楚了。lxk21531395 城市商业银行系统工程师：我们也在考虑这个事情，不知道该怎么选择！不过选择openstack首先要评估自身运维定制开发能力头疼的事左右左右 咨询专家：VM在PaaS以上都欠缺。OpenStack生态比较好，但是IaaS层如果只跟VM比的话是要败下阵来的。另外云一定要有支持，因为上面云管啊什么的每家都不一样，自己搞不定

5、，要么选择基于OpenStack的商业版本比如说华为，要么选择直接上vm（规模不大的话）。林锋林锋 浪潮商用机器企业云创新中心系统架构师：各种虚拟化和云化技术有着不同的商业模式、成熟度、灵活性、可靠性，总体而言，应根据业务的特点进行平台架构的选择。未来的方向预计是走向融合的云交付方式，通过高级云管平台实现统一管理+按业务场景选择合适的软硬件云化架构。例如，对于数据库和关键业务系统，选择Power LPAR逻辑分区级PowerVM虚拟化做整合是目前业界比较好的实践，有众多金融政企案例；对于非关键的众多外围企业应用，目前VMware平台仍是比较成熟的选择；对于开发、管理类业务，可以更多考虑KVM、

6、Xen等平台；另外新兴的Docker等容器化技术平台对于无状态应用、Devops敏捷开发非常友好，发展也非常快。对于银行上私有云的关键一环，数据库和关键应用云化需要重点考虑对平台安全性、合规、性能、可靠性、服务的全面要求，通常VMWare及开源虚拟化都无法全面满足，因此众多银行用户选择Power的云化资源池技术，已经有从大中型银行到农信城商行的众多案例：flycat 某银行 系统架构师：VMware的易用性、稳定性已经得到验证，大都用于核心的、集中式业务环境；openstack开源路线在银行应用中也普遍采用商用版本，运维上一般需要第三方厂商的支持，主要用于分布式、弹性扩展的业务环境。关键还是需

7、要根据不同应用场景，形成标准化的资源选型规范，形成与之匹配的云服务能力。eximbank 某金融企业 系统架构师：1）一定要分清楚基础底层架构、中间工具层和平台的关系；若单独说开源还是商业路线，就不具备显示出来的开源的内容和商业的意义；2）必须确定基础底层架构上将会运营什么业务-应用服务，从业务-应用服务的角度来判断这个基础底层架构适应性；抛开这个判断标准，建起来的开源也好、商业也罢一定是不切实际；要么浪费资金、要么浪费人力和时间，所以这个业务-应用标准是首要条件；3）掌控这个基础底层架构团队/人力资源情况自我剖析，如果有技术能力，有驾驭底层技术实力，至少可以先进行点尝试、某一类业务-应用尝试

8、、到某一业务-应用服务层面试点、最后全业务-应用服务应用；如果没有这个基础底层架构驾驭能力，要么付钱给第三方做开源的服务厂商来服务你，要么你付钱买商业版本；4）关于成本，多说一句，开源大家都想用，但是开源的坑也不少，这是其一，其二就是如果企业是持续成长，不是短期内的环境，那未来势必会有多种版本、各种服务网络及其它差异的存在，这些现存、新建和未来规划使用的内容势必也是需要考虑成本，最后一点就是运维投入的合格人力，这部分适合做这种运维的人力资源也是不小的成本；5）最后说一下产出，就是业务-应用服务所产生的价值，如果业务-应用服务产生的价值足以支撑 IT 资源建设、运维投入，那什么技术路线都可以使用；说道根上其实，还是银行能否盈利？盈利，自建技术实力强悍的团队开源、商业无所畏惧；不盈利，使用开源，找一些小公司协助运营和运维。6）关于人力资源技术培养的问题，也是跟技术路线选择的问题。选择什么技术路线，招聘什么样的人才，培养什么样技术团队，都是息息相关的。yulibin 常州瑞声光电科技 系统运维工程师：针对银行这种要求应用可靠性级别非常高的行业，建议上Vmware这种商用成熟度比较高的产品；openstack可以用于开发或测试环境，出问题影响范围较小，容易控