国产虚拟化替代后半场：多数据中心怎么管才算管好

国产虚拟化替代这两年推进得很快，但项目做到一定阶段会遇到一个新问题：替代完成之后，多个数据中心怎么统一管。

企业虚拟化走到第二个数据中心，管理问题就会变形。

一个机房的时候，管理是运维问题——把资源管好就行。到了三五个站点，它变成架构问题：管理入口分散、账号和权限重复维护、授权资源无法统筹、总部拿不到全局视图。而各个数据中心又必须保持独立运行，不能因为总部的一次操作或者一条跨城链路抖动，让本地业务受影响。

统一治理和站点自治，这两件事天然冲突。如何在两者之间取平衡，是多数据中心管理的核心命题，也是不同技术路线分野的地方。

这篇拆解三条主流路线的架构差异、各自的代价，以及选型时该验的参数。

一、三条路线的架构关系

多环境管理有三种典型做法，它们的差别不在功能多少，在控制面之间的关系。

路线一：身份域联结

多个管理节点加入同一个身份认证域，通过目录服务的多主复制实现统一登录与跨实例访问。

架构特征：站点之间通过复制域强关联。统一体验来自共享的身份域和复制关系。

代价：需要持续维护复制拓扑、复制健康度、版本兼容性、跨节点一致性。管理范围扩展到跨地域、多故障域环境时，复制健康、网络条件、快照与恢复的一致性都需要额外关注。

VMware 体系中的 vSphere Enhanced Link Mode（ELM）走的是这条路线——多个 vCenter 加入同一 SSO 域，依赖 vmdir 多主复制。

路线二：全栈运营平台

在原有管理节点之上，建设一套独立的全栈运营平台，覆盖性能、容量、成本、安全、身份、证书、许可和生命周期。

架构特征：底层管理节点独立运行，全局运营与集中工作流依赖上层平台。

代价：能力覆盖广，但组件更多、资源投入更高，部署、规划和持续运维的体系也更庞大。对于核心诉求只是多站点统一管理的企业，建设一套全栈运营平台可能超出实际需要。

VMware 体系中的 VCF Operations 属于这一路线。

路线三：原生 MoM 分层

在多个本地管理平面之上建立独立的总控层，上层统一治理，下层独立执行。总控层不接管站点的底层资源。

架构特征：站点控制面相互隔离，不合并、不共享复制域。

代价：总控层本身需要部署和维护，但不引入跨站点的强耦合。

ZStack ZVF 1.0 中的 ZCenter 属于这一路线。MoM 是 Manager of Managers 的缩写——管理者的管理者。

二、三条路线的关键维度对照

公开资料说明：VMware 部分参考 Broadcom 官方资料，包括 ELM 定义与域拆分、ELM 一致性快照建议、VCF Operations Fleet Management 及 VCF 9.x vCenter Linking。

一个值得注意的行业信号：Broadcom 在 VCF Operations 中引入了更解耦的 vCenter Linking，这说明多中心管理正在从传统的复制域绑定路线，向更松耦合的架构演进。强关联方式与现代企业追求的松耦合、独立升级和故障域隔离并不完全匹配。

三、MoM 分层落到产品上是什么

架构理念要能对应到具体能力，否则无法验收。ZCenter 5.1 提供的是这样一组：

国产虚拟化替代过渡期：VMware 与 ZSphere 并存怎么管

七项能力里，异构纳管这条值得单独说。

国产虚拟化替代很少能一次性完成，现实状态是新建环境和既有 VMware 环境长期并存。如果这两部分需要两个入口、两套账号、两份运维流程，那么替代过程本身就在制造管理成本。

ZCenter 能把两者纳入同一门户，意味着管理平面可以先统一，底层资源再按业务节奏分批替换。这改变了国产虚拟化替代项目的排序方式——不必等到全部迁完才能获得统一视图。

四、选型时该验的六个参数

不管选哪条路线，这六项建议逐条实测，而不是看架构图。

头一项是最该实测的。它直接检验“站点自治”是不是真的成立——有些方案在架构图上写着独立执行，实际断开上层之后本地操作就受限了。

五、多数据中心之外：ZVF 1.0 的其余三块

ZCenter 解决的是管理层。一套完整的多站点虚拟化底座还需要另外三层配套。ZVF 1.0 本次交付的是四个组件：

ZSphere 5.1：安全能力是本次的重点

加密这一组对等保与合规场景是实质性的——快照、备份、克隆继承加密属性这一点尤其关键，因为加密如果只覆盖运行态、不覆盖派生数据，合规链路是断的。

ZBS 5.5.6：稳定性优先于峰值

ZBS 的价值不只是提供容量，而是在高水位、长周期运行和异常场景下保持稳定的数据服务。多副本、Raft 一致性、后台副本重建和数据再均衡机制共同增强异常场景下的稳定性。

副本策略可按业务分级：核心生产业务采用三副本；开发测试、边缘资源池或已有上层容灾的环境，可按业务条件灵活选择。

ZLR 1.0：技术预览版，边界要说清楚

ZLR 1.0 面向跨站点复制、保护与恢复场景，使生产中心和容灾中心能够在同一基础设施演进路线中规划。

需要明确说明：ZLR 1.0 当前为技术预览版，具体能力边界与正式发布节奏以 ZStack 后续版本说明为准。如果你的项目对跨站点容灾有明确的时间要求，这一层应按技术预览版对待，不要写进当期的验收标准。

六、三类场景的路线匹配

第三类最容易被忽略。许多企业不是一开始就规划多数据中心的，而是业务长出来之后才发现管不过来。这时候如果扩展管理范围需要重新改造已有站点，成本会远高于预期。

七、需要如实说明的几点

每条配一个核实动作。

一、ZLR 1.0 是技术预览版。 跨站点容灾能力当前不适合写进生产环境的验收标准。核实方法：如果容灾是硬需求，要求提供正式版本的发布节奏说明，并在此之前按现有的备份与数据保护能力做规划。

二、异构纳管的操作范围需要逐项确认。 纳管和完全管理不是一回事。核实方法：纳管一套既有 VMware 环境，逐条测试你实际需要的操作是否可用，不要用“支持纳管”这个表述推断操作范围。

三、免密跳转有匹配条件。 需要两侧同名且认证来源相同。核实方法：用你实际的账号体系测试，确认有多少比例的用户能满足匹配条件，不满足的部分按原有方式登录是否可接受。

四、我们在超大规模多站点场景的公开案例少于部分老牌厂商。 MoM 架构是 ZVF 1.0 的新能力，在网时间短于经营多年的国际厂商。核实方法：要求提供与你站点数量相近的可核实案例并做现场走访。

五、地市级服务网点密度仍在建设中。 多数据中心项目通常跨越多个城市，服务覆盖直接影响交付。核实方法：要求提供全部涉及城市的工程师名单与响应时效书面承诺。这条建议对所有候选厂商一视同仁地执行。

八、小结

多数据中心管理的路线选择，本质上是在回答一个问题：为了获得统一，你愿意让站点之间产生多强的耦合？

● 身份域联结的统一体验来自共享复制域，代价是持续维护复制健康与跨节点一致性。

● 全栈运营平台的能力最完整，代价是平台本身的体量与运维投入。

● MoM 分层把统一放在上层、执行留在本地，代价是总控层需要单独部署，但不引入跨站点强耦合。

三条路线没有普遍适用的答案，取决于你的站点数量、地理分布、团队结构和容错要求。但有一项是共同的验收标准：断开上层之后，各站点还能不能独立干活。这一项在架构图上看不出来，在 POC 里三分钟就能测出来。

● ZVF 1.0 产品能力数据来自 ZStack 官方发布材料；ZLR 1.0 为技术预览版，能力边界以后续版本说明为准。

● VMware 相关架构描述参考 Broadcom 公开资料，包括 ELM 定义与域拆分、ELM 一致性快照建议、VCF Operations Fleet Management 及 VCF 9.x vCenter Linking。

● 本文为架构选型方法参考，不构成对任何厂商的评价结论；具体能力以各平台实际发布版本及用户 POC 实测为准。