目前越来越多的金融机构开始核心业务系统及互联网业务系统的信创国产化改造。其中，将基于VMware虚拟化的应用平稳过渡至信创云成为了许多金融机构关注的重点。目前VMware信创改造可选择虚拟化平替、超融合架构、IaaS云平台、云原生等多种替换路线。每种路线都有其特点和适用场景。例如，虚拟化平替适合对现有系统改动较小的场景，超融合架构则适合需要高性能和高可靠性的环境，IaaS云平台适合对资源管理有较高要求的业务，而云原生则适合需要快速迭代和部署新应用的场景。本文探讨了基于信创改造进程，中小银行VMware替换路线的选择存在的难点与应对方法，内容来自金融同行及云专家的一次热烈探讨，本文对交流中的分析和分享进行了汇总整理，希望能为金融行业的IT决策者提供更加清晰的选择决策逻辑和经验参考。
同行共识参与协作人员：
r00tadmin 贵州金控 系统运维工程师
Robot9527 某城商行 系统架构师
nkj2021 某证券企业 系统架构师
van 某城商行 云架构师
努力搬砖 股份制银行 系统运维工程师
Sander007 某大型金融 系统架构师
(以上均为社区ID)
关于中小银行VMware替换路线选择难点及应对的共识- 如何制定一个既符合当前业务需求又具有前瞻性和灵活性的迁移策略？
- 如何明确业务需求并深入分析？这是制定有效迁移计划的基础。
- 如何进行POC测试以降低选型风险，并确保所选平台能满足所有业务需求？
- 如何制定详细的迁移计划,以报正业务连续性和数据安全性？
- 根据自身实际情况选择最合适的云平台架构，而不是盲目追求最新或最先进的技术。
- 关注IaaS层的功能，如果银行的PaaS能力较强，则可以选择轻量级的IaaS平台。
- 上云过程中，采用直接特招申请从云厂家调人的方式，各方先至少一个人配合驻场服务，把团队搭建起来。
- 通过培训、交流、测试环境实践等方式逐步把团队带起来，避免出现影响平台运维的情况。
- 金融行业的集中化设计会对原有的安全纵深防护带来冲击。
- 当云的集中化设计涉及到非安全网络区（互联网、第三方）或单独建设云独立出口时涉及到非安全网络区时，需要重新评估单独的上云体系上的云公共服务（如云安全）。
具体探讨内容如下：
难点1：中小银行VMware替换选择不同的迁移路径时，应该如何平衡短期投资与长期收益？
中小银行在替换VMware时，平衡短期投资与长期收益的关键在于制定一个既符合当前业务需求又具有前瞻性和灵活性的迁移策略。以下是一些具体的建议：1.明确业务需求。中小银行需要深入分析自身的业务需求，包括关键应用的运行环境、性能要求、数据安全和合规性要求等。这有助于确定替换过程中哪些应用需要优先迁移，以及选择何种架构（如ARM或X86）和虚拟化平台（如开源、商用、超融合架构、IaaS云平台等）。2.进行POC测试。在选型前，进行严格的POC测试是必要的。通过搭建测试验证环境，对候选产品的功能点进行全面测试，确保其能满足所有业务需求。这有助于降低选型风险，确保迁移后的系统能够稳定运行。3.制定详细的迁移计划。根据业务需求和选型结果，制定详细的迁移计划，包括迁移的顺序、时间表、资源分配等。在迁移过程中，需要密切关注业务连续性和数据安全性，确保迁移过程平稳无阻。4.考虑长期收益。在平衡短期投资与长期收益时，中小银行需要关注新平台的扩展性、灵活性和未来发展趋势。选择一个能够适应未来业务增长和技术发展的平台，将有助于降低长期的运维成本和升级难度。1.平衡短期投资，选择建设替换VMware的时机比较重要，例如银行进行新核心建设、机房搬迁、XC改造等节点进行替换，本身相关建设就会投入不少资金进行基础实施建设。2.在长期收益方面，替换VMware的三种主流方式各有利弊：1）国产虚拟化路线。需要行内投入人力物力和厂家一起成长。2）上云。使用主流的云平台其实投入都不少，资金投入可能比使用虚拟化多，但可能带来运维体系的改变，整体运维能力的提升。3）容器平台。容器平台投入比云小，但对应用改造投入多，比较适合架构比较简单一点的小银行和新成立的银行。首先，需要评估当前迁移系统的稳定性和可靠性，并确定是否需要立即升级以避免潜在的风险和损失。如：目前有某产品建设服务年限满五年，维保到期，厂商已经停止技术支持，急需替换。其次，需要评估不同迁移路径的成本和效益，包括硬件、软件、人力等方面的投入和产出。1.保留现有系统：VMware替代不是一蹴而就，保留适当的资源作为备用资源进行回退，VMware环境建设比较早的服务器当前已不支持升级，可以选择保留部分现有环境并进行必要的维护和更新，以降低短期投资成本。2.迁移至容器：将应用程序迁移到容器上，可以获得更高的灵活性和可扩展性，同时还可以节省硬件和运维成本。但是需要注意的是，迁移至容器可能需要额外的投资，如产品研发、购买新的硬件设备建设容器环境、网络带宽、数据传输等费用。
3.替换虚拟化环境：长远看虚拟化环境资源需求在逐步减少，容器化成为主流，可以将虚拟机运行在容器上作为备选技术路线。VMware作为存量的算力资源池，面临XC替换虽然是主要推力，但仍建议以企业实际痛点与发展需求出发来选择替换路径。如果仅看虚拟机层面，面临的选择主要两类：私有云、虚拟化&超融合产品；或是结合应用架构的迭代，可以选择容器资源池来逐渐替换掉VMware，但绕不过是否选择上私有云这个问题。整个Iaas市场的发展，私有云与虚拟化、超融合产品仍将保持差异化发展的趋势，是否选择私有云的关键问题是:1.资源池规模是否足够大：规模超过单中心200个节点时，私有云才逐渐从规模效应中获得收益；2.是否能投入组建云计算团队及具备对应的运维能力。上私有云具备一定的学习成本，并且融入原有的运维体系需要持续投入对接、改造成本。结论建议：如果长期来看超过使用私有云的成本规模，建议提前规划上云。坚持选择另一种虚拟化&超融合方案，特别是在规模逐步扩大的资源环境中，未来仍将面临替换问题。
难点2：在业务系统没有重建需求的前提条件下，想实现从VMware迁移到信创云，有什么比较好的方案？
【问题说明】VMware迁移到信创云从实质上来看，只是应用系统的基础运行环境发生了变化，业务功能并没有太大改变，但这种迁移实质上是从硬件、操作系统，到中间件甚至数据库都会发生变化，所以也是项大工程，需要进行全流程测试。但业务同事不会有太大的动力，基础设施的改变，对他们来说是无感的，怎样才能让业务同事也认同这个事情，并投入资源参与到项目当中呢。或者说有没有技术方案能够实现“无感平移”，减少业务同事的介入呢？以我们的实践而言，相对比较的“无感平移”其实就是选择海光+麒麟的XC路线，海光CPU各种资料显示脱胎于早期AMD技术，麒麟的X86版本高度兼容红帽；只需要着重关注性能问题，尤其是数据库类的应用，同时逐步储备XC操作系统运维能力。只能说基本无感，但个人预计很多行都是两条腿走路，开始尽量无感，一边部分系统新建和改造时考量鲲鹏+欧拉。避免路线单一风险和政策变化风险。1.平台迁移：涉及VMware、hyper-v迁移至信创，目前的信创云平台，各大信创厂商都提供VMware迁移工具，具备跨平台迁移及管理能力。2.操作系统迁移：主要由操作系统厂商提供迁移工具，提供原机升级及扩容迁移两种路线。根据源系统版本提供对应的信创操作系统目标版本。整体看因为Linux软件包非标化，迁移有概率失败，迁移成功也可能会出现奇奇怪怪的问题，还是建议做好应用系统信创适配重新部署比较好。方案优点是可以将现有操作系统无感迁移到信创环境，其上程序不做变化。缺点就是非100%信创。VMware迁移现在厂商都有提供专门的迁移工具，只要前期做好迁移方案，后期业务就是迁移完成后做好验证就行。1.在云上测试海光或者ARM芯片，确保应用能够运行在云上环境。2.在云上申请对多活应用节点，保留云下环境的情况下，通过GTM层面转发流量到云上LTM集群（云上云下的应用不建议做成一个负载均衡集群）。3.运行一段时间后下线VMware上的LTM集群及对应服务器，完成应用上云。4.单独评估数据库上云替换的问题，最终实现应用系统整体上云。VMware迁移到信创云，虽然从实质上看只是应用系统的基础运行环境发生了变化，业务功能并没有太大改变，但这种迁移涉及到全面变更，需要进行全流程测试。要让业务同事认同并投入资源参与到项目中，可以采取以下策略：1.明确迁移价值。向业务同事清晰地阐述迁移到信创云的价值，包括提高信息安全、促进国产化替代、降低长期成本等。强调这是国家战略的一部分，对企业未来发展至关重要。2.提供技术方案。介绍可行的技术方案，如采用自动化热迁移工具方式整机热迁移，无需安装agent，可以在不停机的情况下完成迁移，保障业务连续性。这种“无感平移”技术可以减少业务同事对迁移过程中可能出现问题的担忧。3.参与迁移过程。邀请业务同事参与迁移过程的某些环节，如需求分析、测试验证等，让他们亲身体验迁移带来的变化和好处。通过参与，业务同事可以更好地理解迁移的必要性和重要性。4.沟通与协作。加强与业务同事的沟通与协作，及时解答他们的疑问和顾虑，确保他们在整个迁移过程中都保持积极的态度和合作精神。5.制定详细计划。制定详细的迁移计划，包括时间表、任务分配、风险评估等，确保迁移过程有序进行，减少对业务的影响。
难点3：中小银行基于信创改造进程建设大云体系，技术路线如何选择？
【问题描述】基于信创改造进程，若考虑建设大云体系，IaaS和PaaS路线组合怎样选择，对于弹性扩展需求不高的情况下是否有建设容器的必要？若考虑建设，容器在裸金属和在虚拟化之上该如何选择？如何在多技术路线组合架构下实现高效运维？1.IaaS和PaaS路线的选择需要根据银行的实际情况而定，IaaS一般由数据中心来运维，而PaaS一般由开发中心来使用，因为应用代码需要对PaaS做适配，因此需要根据银行应用云原生化的程度以及应用架构的特点来决定是否引入PaaS。常见的情况是存量包袱比较重的银行可以考虑IaaS先行，在对云平台有一定理解和使用经验后，二期再考虑建设PaaS，如果银行存量包袱较小，需要同时建设基础设施和应用系统的时候，可以考虑IaaS和PaaS同时建设。2.容器的价值并不仅仅是弹性扩展，还具备了轻量级、开发部署效率高的特点，针对敏态类的应用系统考虑云原生的，那还是建议使用容器技术，容器本身也是云原生的三驾马车之一，但如果应用架构相对紧耦合，属于稳态应用，短时间内也不会考虑云原生化的，这种情况可以不考虑容器。3.若考虑使用容器，容器部署在物理机和虚拟机上各有优劣势，部署在物理机上的主要优势是系统资源占用低，而部署在虚拟机上的主要优势是灵活。在实际案例中，如果已经有IaaS云了，建议容器部署在虚拟机上，毕竟当前硬件的算力相对充沛，虚拟机hypervisor占用的资源几乎可以不计。如果没有IaaS云，且使用容器的话，建议容器部署在物理机上，避免引入虚拟机，带来额外的成本和消耗。选择IaaS和PaaS路线组合：根据实际需求和预算情况，可以选择采用IaaS和PaaS相结合的方式。IAaaS可以提供基础的计算、存储、网络等资源，而PaaS则可以在这些基础上构建更高级别的应用和服务。考虑容器的需求：如果对弹性扩展需求不高，可以不必过多关注容器的选择。但如果需要更高的灵活性和可移植性，建议使用容器来部署应用程序。容器的选择：容器可以在裸金属或虚拟化之上运行。裸金属容器具有更好的性能和安全性，但需要更多的硬件支持；虚拟化容器则更加灵活，可以在不同的平台上运行，但是会额外损耗一部分资源，在选择容器时，需要根据实际情况进行权衡。大规模部署优先考虑裸金属，小规模可以在虚拟化上运行。总之，中小银行在选择大云体系技术路线时，需要综合考虑自身的需求、预算和技术实力等因素，并结合实际场景进行选择。如果项目主要需要管理底层基础设施（像计算、存储和网络），并且团队具备相关的技术栈和运维能力，可以选择IaaS。若更关注应用的开发和部署效率，以及希望快速实现业务价值，PaaS会是更合适的选择，因为它减少了基础设施管理的负担。容器化在微服务架构下非常有用，即使弹性扩展需求不高，容器也能提供一致性、便携性以及快速的开发与交付。如果未来计划实现更高的自动化和持续交付，开发和测试环境一致性等，容器化是非常有必要的。容器在裸金属还是在虚拟化，各有优势：裸金属适合对性能要求极高的应用，能够获得更好的性能，较低的延迟，且减少了虚拟化带来的资源开销。如果业务场景中有计算密集型任务或对资源使用最大化有需求，裸金属可能是更好的选择。虚拟化则更灵活，能够快速部署多个环境，便于资源管理和调度。如果需要频繁地变更资源配置或在多租户环境中提供服务，虚拟化将更有优势。多技术路线组合架构下实现高效运维，可以从统一的管理平台、自动化运维工具、完善的监控和日志管理、构建流畅的持续集成和持续交付（CI/CD）管道、根据业务需求自动调整资源配置等方面来优化实现。IaaS和PaaS的选择需根据业务来选择，如果有自己的开发团队，那就可以选择搭建PaaS，如果研发都是外包，那就可以考虑先做IaaS。开发不管是不是外包，应用都要部署，建议部署在容器上，相对比较灵活，对于故障的承受力更好。我行目前大部分应用都已经部署在容器上，运维相对会更加高效。
欢迎点击文末阅读原文到社区阅读和讨论交流，发表您的看法觉得本文有用，请转发或点击在看，让更多同行看到
欢迎关注社区以下 “虚拟化”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/23
下载 twt 社区客户端 APP
![]()
![]()
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场
