大家好，我是两年砍柴。
本文内容来自朋友李工访谈和口述，文章以甲方视角展开，行文逻辑和内容编排由两年砍柴整理。
特别感谢李工的无私分享。
最近这几年被VMware替换这件事搞得焦头烂额。自从博通收购VMware后，授权政策的变动加上信创要求的推进，我们不得不开始认真考虑虚拟化平台的替代方案。
作为一家中型银行的IT基础架构负责人，我深知这个消息意味着什么。
我们现有的200多台虚拟机，承载着从核心交易到外围系统的全部业务，几乎全部运行在VMware虚拟化平台上。
更棘手的是，信创的要求越来越明确，留给我们的时间不多了。
在考虑替换方案的过程中，我和团队经历了无数次的技术讨论、方案对比和风险评估。
今天，我想通过两年砍柴的公众号说说我的一些感受和心得。
1
一、国产虚拟化产品到底靠不靠谱？
这是我最关心的问题。
为了获得第一手资料，我带着团队走访了几家已经实施替换的同业机构。
在某城商行，我们看到了成功的案例——他们用国产虚拟化平台成功承载了80%的业务系统，成本降低了40%。但在另一家券商，技术负责人却向我们吐槽：迁移过程中遇到了各种奇葩问题，有个业务系统因为驱动兼容性问题，整整折腾了两周才解决。
这些实地调研让我们意识到，替换成功的关键不在于技术本身，而在于是否做好了充分的准备和风险评估。每个企业的业务特点和技术积累不同，适合别人的方案未必适合我们。
在近期的评估中，我们也发现到国产虚拟化产品确实取得了很大的进步。某知名国产虚拟化厂商的技术人员向我们展示的产品功能令人印象深刻——异构集群管理、跨集群迁移、快照备份、集群高可用等核心功能一应俱全。
但当我们深入测试时，发现了一些令人担忧的细节。
比如：CPU超卖比例的限制让我们的资源利用率计算完全被打乱。
原来在VMware环境下，我们能够实现1：8甚至更高的超卖比，而国产产品普遍只能在1：2到1：3之间徘徊。这意味着同样规模的业务，我们需要投入更多的硬件资源。
针对这个事情，我们在前期项目申报材料中做了多次的方案论证和计算，最终发现这就是当下国产产品与VMware vSphere产品之间的差距，短期内没有改进的可能性，我们只能选择接受。
其次，性能不稳定性让我们深感忧虑。
在某国产平台的测试中，Oracle数据库的IOPS性能竟然比VMware高出15%，但在SQL Server场景下却落后20%。
为此，我们测试团队还自行针对某厂家的产品重新做了测试，两次测试物理环境一样，但测试情况居然相差极大，厂家最终也没有给出一个令人新服的解释。
类似这种性能表现的不稳定性让我们作为系统的管理运维部门深感忧虑。
还有，内存管理机制也让令人头疼。
很多虚拟化厂家宣称内存可以超分，但是到了项目规划环节根本就不敢这么做，他们会编出一堆的理由告诉你不建议超分。
这并非孤例，市面上很多的国产虚拟化产品都缺乏内存超分功能，一旦分配就被完全占用。这对于我们这种运行着大量内存申请远大于实际使用需求的Java应用的环境来说，简直是灾难性的。
更让我担心的是系统和数据备份的恢复体系。
现有的基于快照的备份方案在效率和资源占用方面都与VMware生态系统存在明显的差距。我们的运维团队反馈，国产产品的备份方案还不够成熟，恢复时间和成功率都达不到现有水平。更让人头疼的是第三方软硬件的兼容性。某品牌存储阵列的API集成在国产平台上存在严重bug，导致备份任务频繁失败。
2
二、信创合规路上的“坑”有多少？
就在我们为技术选型纠结时，总行信创办下达了硬指标：核心系统信创比例必须达到50%。这意味着我们不仅要替换虚拟化平台，还要同步完成操作系统、数据库、中间件的国产化改造。
在信创合规方面，我们遇到的挑战更多更复杂。
指令集兼容性：当我们考虑采用ARM架构的国产服务器时，部分应用需要重新编译适配，甚至有些老旧系统源码丢失，根本无法迁移。最终权衡利弊后，我们选择分别建设C86和ARM两个集群，对业务进行分类处理。
全栈适配的复杂性：全栈国产化的要求让我们的替换工作变得异常复杂。不仅仅是虚拟化层，底层的操作系统、数据库、中间件都需要同步替换。我记得公司有一个核心业务系统，涉及到18个软硬件组件、56个接口协议、超过200个配置项。对于这种业务应用，任何一个环节的适配失败都可能导致整个迁移计划搁浅。类似这种“牵一发而动全身”的改造，让项目复杂度呈指数级增长。
安全合规挑战：等保2.0三级要求下的安全配置项就达到127个，而国产平台的安全审计功能尚不完善，这给合规验收带来巨大风险。国产虚拟化产品需要提供完善的安全审计、访问控制机制，这些功能的成熟度直接关系到我们能否通过监管要求。
3
三、新产品长期运行稳定性是否有保障？
作为基础设施负责人，系统稳定性是我最关心的问题。
国产虚拟化产品在短期测试中表现良好，但长期运行的稳定性如何？这个问题至今都没有人能给我一个确切的答案。
国产产品功能很多，参数非常丰富，看得人眼花缭乱。但是正儿八经经常使用的并不多。在性能层面，国产产品经过调优或许在性能上也可以做到很好，但是作为承载核心业务应用的底座系统而言，稳定性是最最重要的。
在厂家那里我没有找到想要的答案，我们又选择去调研了几家已经实施国产化替换的同业单位，调研完毕后，得到的反馈褒贬不一。
有单位反映产品运行稳定，基本达到了预期；也有单位遇到了各种莫名其妙的问题，甚至出现了业务中断的情况。
产品和方案在售后服务支持上的差距同样令人担忧。
VMware（曾经）拥有完善的全球支持体系，而国产厂商的服务能力是参差不齐的。很多厂家其实不是原厂做服务，而是代理商提供后续的技术支持，甚至有些驻场工程师表面上是原厂编制，实则是代理商招聘的。
代理商工程师，以及外包驻场工程师的技术能力相较于原厂，差距还是蛮大的。尤其是在深度技术问题处理上就会有明显的感受，我们作为甲方，特别担心能否得到及时有效的产品技术支持。
4
四、替换策略：循序渐进还是大刀阔斧？
在制定替换策略时，我们面临着另一个关键决策：是采用全栈信创替换，还是仅仅替换虚拟化层？我们团队内部产生了激烈讨论。
业务系统全栈替换的方案虽然彻底，但风险巨大。我们需要协调多个供应商，进行大量的适配测试，任何一个环节出问题都可能导致业务中断。
分层逐步替换的方案相对稳妥，但可能存在兼容性隐患。仅仅替换虚拟化层，虽然技术难度降低，但长期来看可能还需要进行上层应用的改造。
经过多方论证，我们最终决定采用“分步走”策略：
对于新上的业务系统，直接采用全栈信创架构；
对于现有系统，则根据业务重要性和改造难度，制定分阶段替换计划。
先选择非核心业务系统进行试点，积累经验后再逐步推广到核心系统。同时，我们为每个系统制定了详细的回退方案，确保在出现问题时能够快速恢复。
提前进行兼容性测试至关重要。我们搭建了完整的测试环境，对现有业务系统进行了全面评估，提前发现了大量兼容性问题。在实际迁移过程中，我们总结出了非常多的宝贵经验，并有意识的建立了知识库。
记得在一次业务迁移测试时，原本预计4小时的迁移窗口，最终用了快12个小时才完成。最终发现问题是出在存储兼容性上，国产虚拟化平台对某些高级存储特性的支持还不够完善。
在整个产品替换的过程中，供应商的配合程度直接决定项目成败。在做迁移测试的过程中，可以非常有效的探出厂商的合作意愿和解决问题的能力。因此，在选择合作伙伴时，我们将技术支持能力作为重要考核指标。
当然了，团队技能转型也是不可忽视的环节。我们的运维团队对VMware平台非常熟悉，虽然算是有一定的基础，但是毕竟是新产品，所以转向国产平台还是需要重新学习。
我们在预测试环节就提前安排了培训计划，确保团队能够快速掌握新平台的运维技。并且通过团队成员的实操，我们还广泛的收集了大家的使用评价和建议，为后续产品选型也提供了很好的参考依据。
5
写在最后
VMware替换之路充满挑战，但也是我们技术体系转型升级的契机。
在这个过程中，我们深刻体会到，没有完美的产品，只有适合自己的方案。
作为技术负责人，我认为关键是要保持开放心态，做好充分准备。既要积极拥抱新技术，又要谨慎评估风险。只有这样，我们才能在技术变革的大潮中稳步前行。
如果你也在经历类似的替换过程，欢迎交流分享经验。毕竟，在这个充满不确定性的时代，同行之间的经验分享显得尤为珍贵。
以上，希望对你有所启发！
本篇文章转自公众号“两年砍柴”，大家多多关注！
---（正文完）
