VCF 9.1 进阶实践：将【VCF 网络运维工具 (VON)】部署至非管理网络全流程详解

在 VMware Cloud Foundation（简称 VCF）9.1 版本的升级与落地场景中，越来越多企业出于网络安全隔离、业务流量分区、运维权限划分等需求，不再愿意将所有平台组件统一部署在默认的管理网络中。此前已有成熟方案可将【VCF 管理服务 (VCFMS)】与【VCF 自动化 (VCFA)】部署到非管理网络，相关内容可参考原文中的【HERE】、【HERE】两篇往期博客。受同事 Abdullah 的实践启发，他借鉴上述两套部署思路，成功完成了VCF Operations for Networks（简称 VON，VCF 网络运维工具）在非管理网络环境下的部署工作。结合本次实操经验，本文将完整讲解配套自动化脚本、API 调用逻辑、配置参数以及全流程验证步骤，为广大云计算运维从业者提供可落地的参考方案，补齐 VCF 9.1 主流 Day-N 组件跨网络部署的技术体系。

一、背景概述：VON 默认部署规则与改造需求

作为 VCF 生态中核心的网络运维组件，【VCF 网络运维工具 (VON)】主要依托 VCF Operations 平台内的Fleet 生命周期管理（Fleet LCM）工作流完成部署，这也是 VCF 9.1 版本统一管理各类后置组件的标准入口。按照软件出厂的默认配置，VON 包含两大核心节点 —— 平台节点（Platform）与采集器节点（Collector），这两类节点在通过 Fleet LCM 可视化界面部署时，会被强制分配至 VCF 集群的管理网络中。

对于中小型测试环境或者架构简单的私有云平台而言，组件与管理网络共用网段不会产生明显问题。但在中大型生产数据中心、多租户云平台、等保合规要求严格的企业环境里，这种部署方式存在诸多隐患：一方面，网络运维组件产生的海量流量会挤占管理网络带宽，影响 VCF 核心管控服务的稳定性；另一方面，管理网络通常权限等级最高，将网络诊断、流量分析类组件部署于此，会扩大安全攻击面，不符合网络分层隔离的运维规范。

正因如此，打破默认部署限制、将 VON 迁移至独立的非管理专属网络，成为企业生产环境的刚需。而 VCF 官方并未在 Fleet LCM 图形化界面中提供网络自定义选择功能，不过平台开放了完整的 Fleet LCM API 接口，我们可以借助 API 改写部署规则，实现 VON 向非管理网络的定向部署，这也是本次方案的核心实现思路。

二、前置部署选项与硬件资源要求

在正式讲解 API 与脚本操作前，我们先梳理 VON 在 VCF 9.1 中基础部署选项、版本规则与硬件资源门槛，这是保障后续跨网络部署成功的基础条件。

当我们在 VCF Operations 中发起 VON 部署任务时，系统会提供两种部署模式供选择：第一种是全新部署，第二种是导入现有 6.14.x 版本的 Aria Operations for Networks 虚拟设备。本文的跨网络部署方案主要针对全新部署场景设计。

本次实操使用的软件版本为9.1.0.0，部署规格选择了官方定义的小型（Small）模式，该规格对应的硬性资源需求为 4 核虚拟 CPU、6GB 运行内存，同时预留 4GB 额外内存空间。运维人员在执行部署前，务必提前检查目标 vSphere 集群的资源余量，避免因 CPU、内存资源不足导致部署任务中断。

三、核心工具：自定义 PowerShell 脚本功能与基础用法

为简化 API 调用流程、降低手动编写接口请求的门槛，本次配套开发了专属 PowerShell 脚本【fleet_lcm_deploy_vcf_operations_for_networks_to_different_network.ps1】。该脚本深度适配 Fleet LCM 接口能力，同时延续了 VCFMS、VCFA 跨网络部署脚本的设计逻辑，兼顾易用性与灵活性。

3.1 脚本支持的输入参数

该脚本能够兼容 Fleet LCM 可视化界面中的全部常规输入项，运维人员可根据自身环境填写关键信息，主要参数包含：VON 目标部署版本、平台节点 IP 地址、采集器节点 IP 地址、组件管理员账号与密码。

结合 VON 的架构特性补充说明：和 VCFMS、VCFA 依托平台内置服务运行的模式不同，VON 始终沿用传统 OVA 虚拟设备的部署形态，并不嵌入 VCFMS 服务体系。因此在 API 规范层面，本次部署必须采用OvaComponentSpec（OVA 组件规范）类型，这一点也已经在脚本内部完成适配。而想要指定非管理网络，仅依靠基础参数远远不够，还需要额外补充 vSphere 分布式端口组名称、子网掩码、网关、DNS 服务器、NTP 时间服务器等全套网络配置信息，所有网络参数均可直接在脚本内进行编辑。

3.2 两种运行模式：仅验证模式 & 正式部署模式

为了规避参数填写错误、网络不通、权限异常等问题，脚本划分了预验证和正式部署两种运行模式，推荐运维人员严格按照 “先验证、后部署” 的顺序执行。

1. 仅验证模式（默认模式）脚本默认状态下，变量$ValidateOnly设置为true，此时脚本只会调用 Fleet LCM 的验证类 API，对所有输入参数、网络连通性、权限、资源配置进行全面校验，不会执行实际的组件部署操作。 验证成功后，终端会输出清晰的日志信息：系统会生成唯一的任务 ID，并实时展示任务状态从 “运行中（RUNNING）” 变更为 “执行成功（SUCCEEDED）”。只有当验证任务完全通过，才能证明当前所有配置参数、网络环境、权限均符合部署要求。 参考日志示例：

   [06-09-2026_04:50:38] ### 仅验证模式 ### [06-09-2026_04:50:38] 开始执行 VCF 网络运维工具部署验证 [06-09-2026_04:50:38] 验证通过。任务 ID: 019eaecb-97c7-7092-9d0e-494ae4ea5e21，初始状态: RUNNING [06-09-2026_04:50:49] 任务 019eaecb-97c7-7092-9d0e-494ae4ea5e21 状态: SUCCEEDED [06-09-2026_04:50:49] 验证任务执行完成，最终状态: SUCCEEDED

2. 正式部署模式当预验证流程 100% 通过后，我们只需修改脚本内的核心变量，将$ValidateOnly由true改为false，再次运行脚本即可启动正式部署流程。正式部署阶段依然会先自动执行一轮全量验证，确认环境无异常后，再调用部署 API 完成 VON 两大节点的创建与配置。 部署成功后，接口会返回202状态码（请求已接受并开始处理），同时返回对应的工作流名称【INSTALL_COMPONENTS_WORKFLOW】，代表组件安装工作流已正常启动并执行完毕。 参考日志示例：

   [06-09-2026_04:51:29] 开始执行 VCF 网络运维工具部署验证 [06-09-2026_04:51:29] 验证通过。任务 ID: 019eaecc-5f0d-779e-8f8e-17d5874eded3，初始状态: RUNNING [06-09-2026_04:51:55] 验证任务执行完成，最终状态: SUCCEEDED [06-09-2026_04:51:29] 开始将 VCF 网络运维工具部署至目标非管理网络 任务 019eaecc-5f0d-779e-8f8e-17d5874eded3 状态: RUNNING 任务 019eaecc-5f0d-779e-8f8e-17d5874eded3 状态: SUCCEEDED

四、完整 JSON 请求载荷详解（非管理网络部署核心配置）

脚本本质是对 Fleet LCM API 请求的封装，为方便深度定制、二次开发或者手动调用 API 的场景，下文将对可直接投入生产使用的完整 JSON 请求载荷进行逐字段拆解，所有示例参数均为实验室环境配置，运维人员可根据自身数据中心的网络架构、IP 规划、端口组名称灵活修改。

整体结构概述

整个 JSON 配置以componentSpecs（组件配置集合）为顶层节点，内部定义单套 VON 组件的部署规则，包含组件类型、部署规范、SDDC LCM 标识、双节点详细配置以及全局管理员密码五大模块，完整适配 OVA 形态组件的跨网络部署要求。

逐字段解析与配置说明

{ "componentSpecs": [ { "componentType": "OPS_NETWORKS", "deploymentType": "OvaComponentSpec", "sddcLcmId": "34cf98e3-4a59-413f-8ff3-d1294aad8a7e", "nodeSpecs": [ // 第一部分：平台节点（Platform）配置 { "nodeType": "PLATFORM", "version": "9.1.0.0.25318550", "deploymentSpec": { "fqdn": "vcf-net02.vcf.lab", "deploymentOption": "small", "password": "VMware1!VMware1!", "networkName": "DVPG_FOR_FLEET_MANAGEMENT", "ipv4Settings": { "address": "172.30.70.150", "netmask": "255.255.255.0", "addressType": "Static", "gateway": "172.30.70.1" }, "dnsServers": "192.168.30.29", "dnsSuffix": "vcf.lab", "ntpServers": "96.19.94.82" } }, // 第二部分：采集器节点（Collector）配置 { "nodeType": "COLLECTOR", "version": "9.1.0.0.25318550", "deploymentSpec": { "fqdn": "vcf-netc02.vcf.lab", "deploymentOption": "small", "password": "VMware1!VMware1!", "networkName": "DVPG_FOR_FLEET_MANAGEMENT", "ipv4Settings": { "address": "172.30.70.151", "netmask": "255.255.255.0", "addressType": "Static", "gateway": "172.30.70.1" }, "dnsServers": "192.168.30.29", "dnsSuffix": "vcf.lab", "ntpServers": "96.19.94.82" } } ], "configSpec": { "adminPassword": "VMware1!VMware1!" } } ] }

1. 基础组件标识字段

   • componentType: "OPS_NETWORKS"：固定标识，代表当前部署的组件为【VCF 网络运维工具 (VON)】，不可修改；
   • deploymentType: "OvaComponentSpec"：明确部署形态为 OVA 虚拟设备，适配 VON 的架构属性，是区别于 VCFMS、VCFA 的核心标识；
   • sddcLcmId：SDDC 生命周期管理服务的唯一 ID，每一套 VCF 集群拥有独立 ID，需要从本地 VCF 环境中查询获取。

2. 节点通用配置（双节点共用规则）VON 由平台节点与采集器节点组成，两个节点的软件版本、部署规格、网络端口组、DNS、NTP 等配置建议保持统一，便于后期运维管理。

   • version：VON 完整版本号，需与 VCF 9.1 兼容版本保持一致；
   • deploymentOption: "small"：部署规格，此处为小型模式，可根据业务负载切换为中、大型规格；
   • networkName：核心自定义字段，填写目标非管理网络对应的 vSphere 分布式端口组名称，这是实现跨网络部署的关键，必须保证端口组已提前创建并划分至独立网段。

3. IPv4 网络配置（静态 IP 模式）本次方案统一采用静态 IP 分配（addressType: "Static"），也是生产环境的标准选择，不推荐 DHCP 动态分配：

   • address：节点静态 IP 地址，需归属到目标非管理网段；
   • netmask：子网掩码，根据网段规划填写；
   • gateway：非管理网络的网关地址，保障节点跨网段通信。

4. 域名与时间服务配置

   • fqdn：节点完整域名，需提前在 DNS 服务器中完成解析；
   • dnsServers、dnsSuffix：DNS 服务器地址与域名后缀，保障 VCF 集群内域名互通；
   • ntpServers：时间服务器地址，VCF 全组件必须保证时间同步，否则会出现认证失效、日志错乱等问题。

5. 账号密码配置配置分为节点本地密码与组件管理员密码两类，示例密码为实验室测试密码，生产环境务必设置复杂度更高的密码，并做好密码保密管理。

五、方案总结与运维延伸建议

5.1 方案核心价值梳理

本次基于 Fleet LCM API 与 PowerShell 脚本实现 VON 部署至非管理网络的方案，延续了 VCF 9.1 中 VCFMS、VCFA 的跨网络部署技术体系，实现了三大核心价值。首先，彻底打破官方图形化界面的部署限制，满足企业网络分层、安全隔离的合规需求；其次，将网络运维专属组件独立划分网段，分离业务流量与管理流量，提升 VCF 整体平台的运行稳定性；最后，标准化的脚本与 JSON 配置文件可复用，便于在多套 VCF 集群、同架构数据中心批量落地，大幅提升部署效率。

同时需要再次强调架构差异：VON 采用传统 OVA 虚拟设备部署，和内嵌式的 VCFMS 架构完全不同，因此在 API 规范上必须使用OvaComponentSpec类型，这也是部署过程中最容易出错的细节，运维人员需要重点留意。

5.2 实操运维补充建议

1. 部署前环境核验除了资源与参数校验，需提前测试新非管理端口组与 VCF 管理节点、vCenter 服务器之间的网络连通性，放行通信端口，避免部署完成后组件无法被 Fleet LCM 纳管。
2. 优先使用验证模式无论经验是否丰富，每次修改脚本或 JSON 参数后，都必须先启用$ValidateOnly=true执行预验证，排查参数错误、权限缺失等问题，降低正式部署的故障概率。
3. 配置文件备份完成部署后，建议将最终版 PowerShell 脚本、JSON 载荷文件统一归档备份，后续重装、扩容、迁移 VON 节点时可直接复用。
4. 配套运维联动VON 作为网络诊断组件，部署至非管理网络后，需同步调整监控、日志收集策略，确保运维平台能够正常采集 VON 的运行数据，保障故障排查链路完整。

5.3 技术拓展方向

对于有二次开发需求的团队，可基于本文的 JSON 载荷与 API 接口，将 VON 跨网络部署功能集成至自动化运维平台，实现全流程无人值守部署；也可结合 VCF 9.1 的其他 Day-N 组件部署方案，搭建一套完整的 “管理网络 + 多业务独立网络” 的分层架构体系，充分发挥 VCF 私有云平台的灵活性与扩展性。