明确建设范围

ZCF 环境由已部署的基础设施与统一管理平面共同构成。ZCF 管理平面包含统一门户、统一身份认证、云联邦、可观测运维组件、安装部署和生命周期管理等能力。

已有 ZStack Cloud 环境可在保留既有云主机及其关联资源的基础上接入 ZCF，逐步获得统一入口、单点登录、统一资产视图和可观测运维能力。接入前仍需确认版本兼容性、网络连通性、可用资源和变更窗口。

说明术语边界

为避免混淆，本章按下表区分基础设施环境、基础设施组件和资源：

形成实施方案

环境方案应至少明确以下内容：

• 明确单节点部署或三节点高可用部署的选型，以及管理服务中断的可接受范围。
• ZCF 服务节点和可观测运维组件的承载位置、资源预算及故障后的资源余量。
• 节点地址、ZCF 服务 VIP（稳定服务入口）、认证入口和基础设施组件接入端点的访问关系。
• 指标与日志的采集范围、日增量、保留周期和存储容量。
• 安装、故障处理和升级依赖的外部服务、变更窗口及责任人。

规划说明与使用边界

本章中的前提表示部署前必须具备的条件，建议表示面向生产环境的设计选择，现场测算表示应结合实际负载确定的参数。参考配置和容量演算用于说明规划方法，不构成性能保证或容量上限。

规划节点角色

节点角色用于明确部署责任，不代表必须新增物理服务器。Installer 节点与 ZCF 服务节点的具体部署关系，以及可观测运维是否使用独立节点，均应以目标版本的安装方案为准。

选择部署形态

• 单节点部署：
  • 将 ZCF 服务集中在一个节点上，适用于体验、测试、演示及管理服务中断处于可接受范围内的非关键环境。
  • 指标写入、日志检索和管理请求可能共享计算及磁盘资源。
  • 节点维护或故障时，应预先明确恢复方式和维护窗口。
• 三节点高可用部署：
  • 由 3 个 ZCF 服务节点构成高可用部署单元，并提供 ZCF 管理服务 VIP，适用于生产环境。
  • 服务节点应分散物理故障域，检查地址冲突、网络可达性和故障切换条件，并为故障恢复和维护保留资源余量。
  • ZCF 管理平面的高可用应与 ZStack Cloud 及其他基础设施组件自身的高可用分别进行规划。

确定可观测运维承载方式

ZCF 可观测运维能力默认由 ZCF 服务节点提供，可与服务节点共同部署；但当指标与日志采集、历史查询或报表等负载增长，或需要分别满足资源隔离、数据保护与可用性要求时，可按目标版本安装方案规划独立节点。

• 与 ZCF 服务节点共同部署：
  • 初始数据量较小，采集、查询和管理负载可在同一资源预算内运行。
  • 节点较少；需关注日志和指标负载对管理服务的竞争。
• 使用独立节点：
  • 数据写入、历史查询或报表负载较高，需进行独立资源规划。
  • 增加节点、连接和维护工作；数据保护和可用性需按目标版本方案确认。

选择部署入口

ZCF 提供 Installer 和 ZStack Cloud 应用市场两种部署入口，可根据现有基础环境和目标部署形态选择。

• Installer：适用于已准备目标服务节点、需要由向导配置节点与部署关系的场景。
• ZStack Cloud 应用市场：适用于已有可用 ZStack Cloud、计划以云主机承载 ZCF 的场景。

两种入口均应在实施前准备匹配架构的介质、节点和 ZStack Cloud 管理连接信息，并在目标版本安装文档中确认参数和步骤。

规划实施路径

实施路径应根据基础环境的建设状态确定。

• 新建环境：建设 ZStack Cloud → 按需准备其他基础设施组件 → 部署 ZCF → 完成组件连接与认证配置 → 验证资产同步和观测数据。
• 已有 ZStack Cloud 环境：确认 ZStack Cloud 可用并准备部署资源 → 通过应用市场安装 ZCF → 完成组件接入与统一认证配置 → 验证资产同步和观测数据。

收集规划输入

ZCF 的管理负载与已接入的基础设施组件规模及其纳管资源数量有关，也受到采集粒度、日志速率、历史查询范围和使用人数的共同影响。规划时应至少收集以下信息：

• 基础设施组件与版本：ZStack Cloud、ZStack ZStone 等基础设施组合、目标版本和接入范围。
• 纳管规模：已接入的基础设施组件、云主机及其他纳管资源的数量，以及同时操作用户数。
• 可观测运维负载：指标范围和采样间隔、日志平均及峰值增量、历史查询范围、并发查询方式和计划报表。
• 服务目标与增长预期：数据保留要求、可用性要求和规划周期内的增长预期。

确定初始规模

可按云主机数量和同时操作用户数进行初步分档：

编制节点规格表

最终配置应以逐节点方式记录，并至少包含以下字段：

验证生产规格

生产规格宜通过代表性负载验证确定，验证内容包括：

• 验证场景：正常采集、日志高峰、多个用户同时查询和计划报表执行。
• 记录指标：CPU、内存、磁盘吞吐和响应情况。
• 高可用验证：在约定环境中验证节点故障后的负载分布。

当压力主要来自历史查询和日志写入时，增加数据处理和存储资源通常比单纯增加管理节点更有针对性。最终方案应明确每个节点承担的角色、资源预算和扩容触发条件。

梳理访问关系

网络方案应覆盖管理员访问、安装部署、节点间通信、基础设施组件接入、观测数据和公共基础服务。小规模环境可复用物理网络；生产环境宜按访问对象和流量特征配置隔离和带宽预算，避免批量日志传输挤占关键管理通信。

规划地址与服务入口

每个 ZCF 服务节点应有稳定可识别的管理地址。节点 IP 用于节点连接和维护，服务 VIP 用于稳定访问入口，两者应分别记录。使用 FQDN 时，应从管理员终端、Installer 和服务节点分别验证名称解析和路由。

高可用部署应在实施前确认 VIP 所在网段、承载接口、地址预留和网络设备对切换的支持条件。统一身份认证入口和基础设施组件访问地址应保持一致、稳定；统一身份认证不等同于跨组件角色或权限模型自动映射。

形成访问清单

该清单用于形成访问规划框架，不构成完整的防火墙放行清单。最终放行清单应补齐组件端口、协议、方向和来源网段，并以目标版本安装文档为准。

核算带宽与基础服务

观测数据带宽应按峰值传输量估算，并计入协议开销、可能的重传和并发查询。管理页面可访问仅表明其中一条路径可用，不足以判定所有部署和采集路径均已满足要求。

所有参与管理和采集的节点宜使用一致、可靠的时间源。使用域名和加密访问时，应检查证书名称匹配、信任链、有效期和续期责任；如部署外部代理，还应确认其是否为目标版本支持的访问方式。

分开核算系统与数据空间

• 磁盘预算范围：ZCF 的磁盘预算应包含操作系统、组件运行数据、安装和升级介质、指标、日志，以及运行和维护预留。
• 共同部署影响：可观测运维与其他管理组件共同部署时，应特别关注这些负载是否争用同一磁盘。
• 存储性能验证：容量充足并不代表写入延迟和查询吞吐满足要求，存储介质和 I/O 能力也应结合实际负载验证。

估算指标与日志容量

• 指标容量：主要由活跃时间序列数、采样间隔、保留时间和实际存储开销决定。每日样本数可按活跃时间序列数 × 86,400 ÷ 采样间隔（秒）估算，再结合代表性环境中每个样本的实际存储开销、索引和运行空间估算磁盘需求。
• 日志容量：应优先使用启用实际采集范围后的存储增量估算。不同基础设施组件的日志类型和采集覆盖应逐项核对，不应假定组件接入后其全部系统和业务日志均自动进入日志中心。
• 稳态数据空间：对于已明确有效保留周期的数据，可按指标日存储增量 × 指标保留天数 + 日志日存储增量 × 日志保留天数估算。测量值是否包含索引及副本应在估算表中注明；已经进入稳态的磁盘净增量不应直接作为每日写入量。

换算物理容量并持续复核

• 物理容量换算：在计算结果上应增加系统空间、升级临时空间、数据整理空间和安全余量，再依据实际存储布局换算节点和底层存储容量。三节点高可用不代表全部历史数据自动形成三副本，也不代表全部磁盘容量均可用于存储唯一数据。
• 持续复核与扩容：上线后应持续观察数据新增量、磁盘空闲、写入延迟和查询表现。新增基础设施组件、调整采集范围或提高采样频率后，应重新测量日增量并更新预测，在可用空间耗尽前安排扩容。备份与在线保留承担不同职责，不可相互替代。

明确环境边界与运维责任

• 环境隔离：生产、验证和演示环境宜分别管理访问入口、认证配置、基础设施组件连接和数据保留要求。验证环境应能重现关键基础设施组件版本与连接方式，用于安装、升级、认证和采集联调，避免将试验操作直接施加到生产环境。
• 规划范围与生命周期：本节以单套 ZCF 环境及已支持的基础设施组件接入范围为规划边界。多个环境可分别制定节点和网络方案；跨站点统一接入、跨站点高可用和灾备切换应在确认支持边界后另行设计。ZCF 管理组件的生命周期由 ZCF 管理，ZStack Cloud、ZStack ZStone、ZStack Zaku 和 ZStack ZNS 仍按各自支持的流程维护和升级。

完成部署前检查

Installer 预检有助于发现连接、资源和配置问题；生产容量、故障域和恢复目标仍需按环境方案验证。

准备分层验收

• 验收范围：验收应覆盖安装结果、管理入口、身份认证、基础设施组件连接、观测数据、告警与展示、可用性和运维交接。
• 验收依据：资产视图中的历史记录不代表当前采集正常；应以本次已接入组件和实际启用的数据范围为单位完成验证。

交付时应提供最终节点表、网络表、容量表、版本记录和恢复方案。完成这些准备后，交付团队可通过预检和分层验收完成可维护 ZCF 环境的交付准备。