企业官网建设流程全解析

VMware 最近的变动把不少运维团队的计划都打乱了。很多企业本来已经用 vSphere 用了七八年，虚拟机数量从几十台涨到几百台，原来的架构虽然贵一点但胜在稳定。结果这几年授权模式一调整，续保和扩容的成本逻辑直接变了，老板开始问“有没有可能换一套”。这不是个别公司的困惑，我今年以来已经接触了好几拨客户，聊的都是同一件事：如果要从 VMware 迁到国内超融合平台，到底应该怎么选。

我把这个话题拆开写一篇完整的东西。不是给你列市场份额榜单，而是从实际替代的角度去对比，因为超融合软件选型这件事，最后拼的一定不是谁家卖得多，而是搬虚拟机的时候顺不顺利、搬完之后跑得稳不稳、以后运维要不要重新学一遍。这篇文章主要适合正在做 VMware 基础设施替代规划的技术负责人、虚拟化运维工程师，以及所有被老板问过“能不能换”的 IT 人。

1. 为什么 VMware 替代会首选超融合，而不是单纯换虚拟化

先说一个我在交流中经常遇到的现象。很多人一听到 VMware 要替代，第一反应是“换个虚拟化软件不就行了”。这个思路不能说错，但只看问题的一半。你现在的 VMware 环境里，真正跑业务的是虚拟机，但虚拟机依赖的不仅仅是 hypervisor，还有集中式存储、网络策略、vCenter 管理面、备份和容灾工具这一整套东西。只把虚拟机从 VMware 迁到一个新的虚拟化平台，存储还是原来的存储、网络还是原来的网络，那整个迁移的工程量依然不小，而且迁完之后你可能同时要维护两套平台的使用习惯。

超融合之所以会成为替代 VMware 的讨论焦点，核心原因是它把问题收敛了。超融合的架构从一开始就是把计算虚拟化、分布式存储和管理平台作为一个整体交付。当你选择一套国内超融合软件时，实际上是在搭建一个能接替 vSphere + vSAN + vCenter 组合的基础设施底座。虚拟化、存储、管理三个层面都有对应的能力，迁移路径相对清晰，这也是为什么替代 VMware 的讨论里，超融合几乎总是排在前面。

1.1 超融合和纯虚拟化替代的差别在哪里

纯虚拟化替代的意思是，你用 Proxmox VE 或者其它开源虚拟化方案去替换 VMware 的 ESXi，把虚拟机跑在 KVM 或 Xen 上面。这个方案不是不行，很多技术能力强的团队也确实在用，但它有一个前提：你需要自己打理分布式存储的方案。如果没有存储，那还是得把虚拟机放到共享存储上，无论是集中式 SAN 还是自己搭的分布式文件系统，都得有人持续维护。

超融合解决的是这个配套问题。拿国内主流超融合产品来说，它们通常自带分布式存储组件，管理界面上创建虚拟机、配置存储策略、做快照和备份，操作是在同一个平台内完成的。对整个运维团队而言，这意味着你不需要自己拼凑虚拟化、存储、备份三套系统，出了问题也不用在多个厂商之间来回扯皮。所以我在给客户做建议时，一般会强调：你考虑的不应该是“换个虚拟化”，而是“换一个基础设施底座”，超融合是落地这个底座最省力的载体。

1.2 VMware 替代的真正对标对象是整个 vSphere 组合

不少人在选型对标时容易犯一个错误：只拿 vSphere 的虚拟化功能去找国产平台对比，比如看谁家的热迁移更流畅、谁能支持的虚拟机数量更多。热迁移确实重要，但 VMware 环境里真正让团队产生依赖的往往不只是热迁移。

举几个实际场景。你们的虚拟机模板、资源池、权限分级，是不是都在 vCenter 里管理？现有的备份任务，是不是接入了 vCenter 的 API？网络层面是不是启用了分布式交换机，安全策略是不是挂在虚拟机上？这些才是迁移时真正要面对的问题。因此好的国内超融合厂商，做替代设计时都会把对标对象拉宽，要求自家的管理平台能覆盖虚拟化、存储、备份、容灾、网络策略这些模块。所以我也建议你，在做选型清单的时候，别只列“能不能跑 VM”，要把你目前在 vCenter 上所有日常运维动作全部过一遍，每一条都拿到演示环境里去验证。

2. 选型先别按市场份额排序，先做功能矩阵对照

市场份额这个东西很有趣。它反映出的是厂商过往的销售能力和渠道覆盖，不代表它一定适合你的既有环境。我见过好几家单位，选了业内排名第一第二的厂商，但原因只是“别人都选它”，结果搬了一批业务虚拟机之后发现，原来是源端 VMware 上一个很容易使用的功能，到了目标平台要绕很多路。所以这篇盘点里，我建议你用一个最笨但最有效的办法：把自己的需求列成矩阵，让每一个候选平台都拿这个矩阵去过一遍。

2.1 管理面功能：vCenter 的习惯迁移比虚拟机迁移更难

为什么先说管理面？因为迁移项目结束之后，日常维护是你长期要面对的事情。团队之前习惯用 vCenter 管理虚拟机全生命周期，迁移到新的超融合平台之后，管理员的日常操作会完全切换到新界面。这个切换如果做得顺，团队很快就上手；如果做得不顺，大家就会抗拒，觉得新平台“这也缺那也缺”。

具体看什么功能点？我列几个比较关键的。第一个是权限模型，原 VMware 环境里如果有多个管理员分管不同集群或资源池，新平台能不能做到类似分级授权；第二个是告警和事件日志的细粒度，vCenter 的告警规则虽然不算漂亮，但可自定义空间较大，新平台能否提供可配置的阈值告警；第三个是模板和镜像管理，日常开虚拟机用的模板机制，新平台是否支持从模板批量部署；第四个是自定义属性、标签这样的元数据管理，很多时候虚拟机一多，团队靠标签做分类，如果替代平台不支持类似的能力，迁完之后管理会变得混乱。这些功能看起来都不起眼，但任何一个缺失都会在投入使用后的第一周被运维同事投诉。

2.2 数据可靠性能力：HA、DRS、快照与容灾机制的差异

虚拟化平台最核心的职责是保证业务虚拟机不中断。VMware 提供的 HA 功能，能在物理主机宕机后自动在其它宿主机上把虚拟机拉起，DRS 则负责根据资源负载做动态调度。国内超融合平台在这些能力上都有对应实现，但实现的机制和效果需要仔细确认。

比如 HA 方面，超融合平台通常基于分布式存储的高可用特性，虚拟机数据至少有两份副本。当一台物理节点宕机后，控制节点会在其它健康节点上重启虚拟机，这个过程依赖存储副本的实时性和健康检查逻辑。你需要问厂商一个问题：物理节点宕机后，虚拟机恢复时间大概是多少？这个时间在不同厂商之间差异还挺大，有的能做到分钟级，有的可能要更久。另一个是快照能力。VMware 的快照我们用得很频繁，但很多国产超融合原先在设计快照时更偏向“备份前辅助功能”，而不是高频日常操作。如果你的业务经常需要打快照做变更回退，要特别关注快照链的深度、合并速度以及大内存虚拟机的快照兼容性。

容灾层面要确认的是跨站点能力。部分项目要求生产中心和灾备中心使用同一种超融合平台，通过存储层复制做容灾，这个模式在国内超融合里已经比较常见。如果你有跨机房容灾规划，应该把两站点之间的同构部署、复制带宽要求、RPO 可选项作为对比项写清楚。

2.3 迁移工具链：能不能把你的存量虚拟机弄过来才是关键

这是一条很容易被忽视的选型标准。厂商产品演示时通常会用新建虚拟机跑一个业务来展示性能，但真正开始替换时，几百台存量虚拟机的搬迁才是消耗时间最多的环节。如果厂商没有成熟的 VMware 迁移工具，你的团队就面临为每一台虚拟机重新安装操作系统、重新配置应用的风险，工作量会大得吓人。

在选型阶段建议直接问厂商三个问题。第一，是否支持从 VMware vSphere 做无代理批量迁移，也就是说不需要在虚拟机内部安装代理，只通过 vCenter API 读取虚拟机信息就能完成转换；第二，是否支持增量同步，第一次全量复制完成之后，是否能在短暂停机窗口内只同步增量数据，这决定了每一批虚拟机的割接时间；第三，迁移后的虚拟机是否保留原来的网卡配置、磁盘控制器类型和静态 IP，如果迁移之后要求逐台手工改网络配置，几百台 VM 的维护成本会很难接受。迁移工具好不好用，应该放在 PoC 阶段做重点验证，而不是看着 PPT 上的功能列表打勾。

3. 国内主流超融合代表性方案的优缺点盘点

前面讲了选型思路，现在进入正题，聊国内主流的几类超融合方案。为了不写成厂商软文，我会从实际替代场景出发，按平台的能力特点和交付模式来分梯队讨论。每一类我都会说清楚它适合谁、不适合作什么，优缺点都放到台面上。

3.1 为什么盘点的分类不按市场份额，而按交付模式和场景

国内超融合市场这几年分化的趋势很明显。大厂擅长软硬一体打包交付，渠道广、售后网络覆盖深；专业超融合厂商则更强调软件标准化，在存储内核和管理体验上投入较多；还有一些厂商因为安全产品线做得比较早，顺带把超融合做成了业务入口。这三类厂商的定位不同，决定了它们对 VMware 替代场景的回应方式也不同。

如果你是一个 IT 团队只有三五个人、希望尽可能省事的企业，可能更适合选择软硬一体的整套方案，出问题一个电话就能解决。如果你有较强的技术团队，希望平台可控性更高、不希望绑定特定硬件设备，软件交付为主的方案会更灵活。至于安全厂商系超融合，它在需要安全组件或桌面虚拟化场景里天然有优势，但如果你只是要一个纯虚拟化底座，这些附带的安全能力未必用得上。我下面按这三类，分别讲讲它们的优缺点。

3.2 第一类：ICT 大厂的软硬一体方案，强在服务体系

华为 FusionCube、浪潮 InCloud Rail、新华三 UIS 这几套属于典型的大厂软硬一体超融合方案。它们的共同点是均有自己的服务器、网络和存储产品线，超融合不是单一软件产品，而是与硬件深度适配的一体机交付。在替代 VMware 的场景里，这类方案最大的优势是稳定性和售后责任边界清晰。你现在跑数据中心的虚拟化，如果换来换去最后发现某台服务器上的网卡驱动不兼容，压力很大；选择大厂软硬一体，硬件和软件都是同一家出，兼容性矩阵可信度高，出了问题他们绕不开。

这类方案的缺点在于，硬件绑定性比较强，扩容时基本得买同一家的节点，有时候硬件价格会比白牌服务器加软件授权的组合贵不少。另外，大厂的超融合产品线往往横跨多种芯片架构，纯软件功能细节上会有历史包袱。举个例子，某些功能模块在上代产品里成熟，但在新平台里可能要等待版本完善。我的建议是，如果你本身就在用这家厂商的服务器或者网络设备，选择同品牌超融合会减少很多兼容性验证工作；如果现网是纯 VMware 加第三方标准的 x86 服务器，大厂软硬一体会让替换成本变高，因为可能连硬件都要一并换掉。

3.3 第二类：专业超融合厂商的软件标准交付，胜在架构与工具

这里要重点说的是 SmartX 超融合这类专业厂商。它们的产品通常以软件授权的方式交付，可以运行在标准 x86 服务器上，也可以配合厂商指定的硬件选型使用。从技术看，专业厂商在分布式存储领域的积累往往比大厂更专注。比如 SmartX 的 ZBS 存储是自研内核，对外提供块存储服务，对虚拟化的 IO 路径做了较多优化。在实际替代 VMware 时，这种存储能力直接关系到数据库这类 IO 敏感型业务能否顺利跑起来。

专业厂商另一个强项是迁移工具链和对 VMware 的兼容体验。这个逻辑也不难理解：它们的主要客户很多都是从 VMware 环境迁移来的，所以厂商在迁移工具上投入得多，对 vSphere 的功能模拟也更细致。比如管理平台里，有一些布局逻辑就是照着原来 VMware 运维习惯设计的，管理员切换之后学习成本相对低。缺点也同样明显，专业厂商的品牌知名度不如大厂，如果企业采购流程看重品牌排名，在内部审批时会遇到挑战；另外，它们的生态伙伴数量少于大厂，后续如果要对接特定的备份软件、监控平台，可能需要产品经理介入支持。

3.4 第三类：安全厂商生态里的超融合，适合场景化落地

深信服超融合是这类方案的代表，它把超融合和自身的安全产品能力做了深度整合。对正在考虑 VMware 替代的企业来说，深信服方案的优点是管理界面非常友好，几乎把 vCenter 里那些让新手头疼的概念都做了简化。同时深信服在企业市场尤其是分支机构和桌面云场景有很强的渠道和交付能力，如果你要替换的 VMware 环境主要用于虚拟桌面或者中小型业务系统，这类方案的上手速度会非常快。

但也要说清楚，针对大型核心生产环境，安全系超融合产品在存储的底层能力和大规模集群支撑方面，和前面说的专业存储厂商超融合是存在差异的。这本身不是谁差谁好的问题，而是产品设计逻辑不同。安全厂商做超融合，天然想的是“基础设施加安全能力一起卖”，你的真实需求如果只是构建一个稳定的虚拟化底座，平台里附带的安全增值模块就成了锦上添花但不是重点。建议这类方案的 PoC 重点放在你最高负载的业务虚拟机迁移上，测一测存储延迟和长时间运行的稳定性，再决定是否规模化。

下面是这几类方案在替代 VMware 场景里的简要比较，方便你建立直观认识：

如果你在替代 VMware 时对接的是国产化硬件平台，华为和 SmartX 在 arm 和 x86 混合环境的支持经验相对多，但一定以官方兼容性列表为准。我觉得在 PoC 之前，你要从自己的业务规模倒推，不要先看品牌海报。规模越小越看重交付和售后覆盖，规模越大越应该看重存储内核和迁移工具这些“硬底板”。

4. 替代上线的核心步骤和实操拆解

选型敲定之后，真正的挑战才开始。我接触过不少团队，一开始觉得超融合替换 VMware 应该不会太难，结果第一步盘点环境就被打懵了。为了让后面的人少踩坑，我把替代过程里比较重要的几个动作拆出来逐一说明，每一步都是从实操一线总结过来的。

4.1 第一步：把现有 VMware 环境彻底盘清楚再动手

替代工作最忌讳“大概知道有多少台虚拟机”就开始建集群。真实情况往往是，环境里存在大量长期不用的僵尸虚拟机，或者某些应用依赖特定的虚拟硬件版本、特定网卡类型，到了新平台可能无法正常启动。所以在项目启动初期，务必要对 VMware 环境做一次完整的信息采集。

具体采集维度包括：所有 VM 数量、操作系统类型及版本、CPU 和内存配置、磁盘容量及已使用空间、虚拟机所在的主机集群、启用了哪些 VMware 高级特性、网络端口组和 VLAN 划分、是否为静态 IP、对备份和监控系统的依赖、对 GPU 直通或 SR-IOV 的支持情况。采集完成之后，把它们整理成一张总的迁移清单表。这张表不仅能用来评估迁移工作量，也能帮助规划目标平台的容量需求。很多超融合厂商在 PoC 阶段会提供配置建议工具，但如果你的数据不准，工具给出来的容量规划也无法落实。这一步是替代项目的地基，所有后续动作都建在上面，务必认真对待。

4.2 第二步：规划迁移批次，谨慎对待停机窗口

没有一家公司可以做到一次性把所有业务虚拟机全部切过去，正常的做法是分批迁移。分批的原则是什么？我的经验是先迁移低风险非核心的虚拟机，比如测试环境、开发环境、域控之外的辅助系统，跑上一到两周，让运维团队熟悉新平台的日常操作，同时观察平台稳定性。等第一批跑顺后，再逐步迁办公系统、一般业务系统，最后才碰核心数据库和关键生产应用。

每一批迁移前都要单独评估停机窗口。如果你选择的迁移工具支持增量同步，通常可以分两个阶段操作：先做全量复制，这个过程业务无感知，虚拟机照常在源 VMware 环境运行；到了约定的割接时间点，手动把源虚拟机停机或挂起，再同步增量数据，然后启动目标平台上的虚拟机。停机窗口实际上是增量同步时间加启动验证时间，比传统重新安装的方法要短得多。如果平台不支持增量同步，那就只能预留完整的停机时间做离线复制，这种方式的代价会随时间推移成倍增加。因此，在选型阶段确认迁移工具是否支持增量同步，是整个项目推进速度的关键。

4.3 第三步：网络与硬件配置不到位，性能会直接打折

很多人在超融合平台 PoC 阶段发现性能不错，但生产上线后却出现了明显的性能回落，其中一个常见原因是网络配置没有按照要求做。超融合的数据读写会经过分布式存储网络，如果存储网络只跑在千兆环境里，或者没有单独划分存储 VLAN，大流量业务一跑起来就会产生严重瓶颈，进而拖慢所有虚拟机的响应速度。

这里给出几点在部署前要和厂商对齐的硬件网络配置要求。管理网络、业务网络和存储网络最好分离，至少存储网络要使用独立的物理网卡或足够带宽的 VLAN。如果采用 25GbE 或 RoCE 网络，需要确认交换机是否开启 PFC 等流控功能，以及网卡驱动参数是否已在厂商的操作系统镜像里调好。服务器本地磁盘选择上，尽量选择 SSD 或 NVMe 作为缓存层和容量层，具体配置按存储性能需求来定。物理节点之间建议做双上联冗余，避免某一台交换机故障导致节点间心跳中断。网络是超融合最容易出问题也最容易被忽略的地方，动手部署前可以要求厂商提供一份网络配置清单，逐条打钩确认。别嫌麻烦，你在这一步省下的功夫，后面都会以故障的形式还回来。

4.4 第四步：试点验证与回退预案缺一不可

完成前面三步后，还需要选定一个包含典型业务负载的试点集做演示。建议挑选两到三台不同类型的虚拟机，比如一台 Linux 应用服务器、一台 Windows 文件服务器、一台开发数据库，通过迁移工具从 VMware 环境迁到目标超融合平台。重点观察几个指标：迁移后虚拟机能否正常启动、系统内服务和原有监控平台是否能连通、磁盘性能是否满足日常要求、CPU 使用率和内存占用是否正常。

试点验证通过后也不要立刻大批量上线。务必保留源 VMware 平台至少一个完整的业务周期，并制定一份回退预案。也就是说，如果新平台在运行一段时间后出现无法解决的问题，能临时切换回 VMware 环境的能力必须保留。比如维持 VMware 集群的 vCenter 许可不过早注销，保留相关网络配置不动。实际项目中，很多团队一旦把虚拟机迁走，就急着回收源端资源，结果新平台出问题时完全失去了退路。给自己留一条后路，不是对新技术没信心，而是成熟的运维管理本来就应该具备风险控制意识。

5. 常见问题与排查技巧实录

替代 VMware 的项目做多了，你会碰到很多共性问题。这些问题单独看都不大，但组合起来会让实施团队非常疲惫。这一节我从常见问题里挑几个记录，附带排查思路和解决办法，希望对正在规划或已经实施的同学有帮助。

5.1 Windows 虚拟机迁到新平台后激活失效或直接蓝屏

这是迁移场景里出现频率最高的问题，特别是 Windows Server 虚拟机。原因主要有两类：一类是 Windows 的授权与硬件信息绑定，迁移后主板、CPU、硬盘控制器信息都变了，激活状态自然失效；另一类是虚拟机内部加载的驱动程序不兼容，尤其是存储控制器驱动。VMware 虚拟机的默认 SCSI 控制器是 LSI Logic，迁移到 KVM 内核的国产平台后，可能出现引导时找不到磁盘的蓝屏错误。

解决办法有两条路径。迁移前在源虚拟机的操作系统内部预先安装目标平台对应的 virtio 驱动，这是最稳妥的方式。如果虚拟机已经做了迁移且无法启动，可以尝试把目标虚拟机的磁盘控制器类型改成兼容性更好的模式，比如 IDE 或 SATA，先让系统引导起来，再进入系统安装完整驱动后切回 virtio。激活问题建议在迁移前联系操作系统厂商或微软客服，说明迁移场景，提前准备好重新激活流程。这类问题在 PoC 阶段就应该测一次，不要等到生产割接时才处理。

5.2 迁移后应用性能不如原来 VMware 环境，怎么定位

有一类反馈很有意思，业务虚拟机迁过去之后，应用没有报错，但前端访问延迟变高，数据库操作偶尔变慢。遇到这种情况，先别急着给新平台下结论，要从几个常见角度排查。第一步是看存储网络是否达到预期带宽，超融合里最容易成为瓶颈的就是存储网络，如果有丢包或流控未开启，存储 IO 延迟会显著上升。第二步是看虚拟机内部是否安装了对应的 virtio 驱动，如果系统还在用默认的模拟设备，CPU 中断开销会很大，网络吞吐和磁盘 IO 都受影响。第三步是看目标虚拟机的 CPU 和内存配置是否一致，超分比设置是否合理。

建议在迁移前后都做一次统一的性能基线测试，保持测试工具、测试参数一致。很多团队最初 VMware 环境就是从物理机迁移来的，虚拟机资源本身就偏小，迁移到新平台后又沿用旧配置，性能自然上不去。此时应该借机重新评估资源规格，把数据库或高负载应用的内存适当调大。新平台的性能问题绝大部分都可以通过驱动安装和网络优化解决，直接定性为“产品不行”往往会让排查方向走偏。

5.3 存储性能测试结果和厂商宣传差异大，要反思测试方法

选型阶段厂商都会给出自己的存储性能数据，比如随机读写 IOPS 多少万。但到了客户现场实测，数据往往缩水。这不一定是虚假宣传，更多时候是测试方法不对。超融合平台的性能表现依赖集群节点数量、副本策略、磁盘类型、网络带宽和测试负载模型。如果你只部署了三节点集群，却按厂商几十节点规模化测试的数据来对比，结果自然差异很大。

做对比测试时建议至少遵守三个约束：第一，所有候选平台使用同样配置的服务器，尽量放在相同的网络环境里；第二，测试负载要贴近真实业务，数据库类和文件共享类的 IO 特征完全不同，不能只跑一种测试工具；第三，要有复位条件的说明。超融合有缓存机制，测试时间短、数据集小时，性能数据会虚高，建议测试时长至少在 30 分钟以上并观察稳态性能。比较不同平台时，把测试环境、工具版本、负载模型原样记录下来，才能得到有效的参考结论。

5.4 迁移后期老平台资产回收要谨慎，哪些可以回收哪些要保留

项目收尾阶段很容易出现两种极端。一种是不敢动原平台，VMware 环境一直留着，双平台同时运行，运维压力没有减少反而增加了。另一种是迁移验证刚结束就立刻关停老集群，等到新平台出现问题时才发现虚拟机没有完整备份，或者某个冷门虚拟机被漏迁了。我的建议是按节奏推进，不要一刀切。初期保持双平台并行，以月为单位观察新平台监控指标和故障率；至少一个季度后，确认核心业务稳定运行，再逐步缩容老平台。而在关停之前，把老平台里所有虚拟机列表导出来，一件件确认迁移清单里是否有明显遗漏。对于已经确认不需要迁移的僵尸 VM，也建议在 vCenter 里保留一段时间再彻底删除，防止事后才发现某个应用的数据只在老环境里。

做替代项目不是新平台上线就算成功了，真正的成功是旧平台可以安心下电。如果你在迁移后的稳定运行期能不看老平台监控页面，那就说明替代项目通过了最终考验。

6. 替代项目收官前的一些个人建议

写了这么多，最后想补充几条踩过坑才总结出来的体会，不一定适合每个团队，但大概率能让你的替代之路平滑一些。

第一个建议是，做技术选型时别只看公司规模和产品知名度。我见过一些团队采购了头部厂商方案，结果发现厂商对客户需求的响应并不积极，问题可能要等版本迭代才能解决；也见过选择相对低调的专业厂商，反而在迁移过程中得到了贴身支持，问题当天就能升级到研发确认。对替代项目来说，最怕的不是产品有缺陷，而是出了问题没人对你负责。

第二个建议是，PoC 阶段各家厂商用的环境配置要尽量统一，最好直接拿你的真实业务虚拟机来做迁移演练。让每家候选平台都从你现网的 VMware 环境里迁一批测试虚拟机过去，看它迁移工具怎么做增量同步、迁移后虚拟机是否能正常启动、网络策略怎么转换。这套流程走下来，你基本就能判断哪家平台最适合你们的环境。PPT 上讲得再好的功能，最后都得在真实负载下见真章。在持续几周的 PoC 过程中，你还能顺便观察厂商技术支持团队的响应速度和专业水平，这比任何市场排名都更能帮你做出最终决策。