> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/03-customer-scoping.md).

# 客户范围界定

一个范围界定清晰的 VergeOS 部署，早在第一台节点上架之前就已开始。本页提供了一套结构化方法，用于收集客户需求、将工作负载转换为 VergeOS 资源估算、规划租户节点配置以及选择合适的部署拓扑。到这个流程结束时，你应当拥有一整套文档交付物，任何 VergeOS 工程师都可以据此执行安装。

## 需求收集清单

每次范围界定工作都应先从客户处收集以下信息。在发现会议期间将此清单作为对话指南。

### 当前工作负载清单

| 数据项                    | 重要性                                    |
| ---------------------- | -------------------------------------- |
| **VM 总数**              | 确定部署规模并影响架构选择                          |
| **每个 VM 的 CPU 核心数**    | 决定计算集群的规模，并识别 CPU 密集型异常值               |
| **每个 VM 的 RAM 分配**     | RAM 通常是限制性资源；决定节点数量                    |
| **每个 VM 的存储（已分配和已使用）** | 区分精简配置容量与实际消耗                          |
| **存储 IOPS / 延迟要求**     | 识别需要 NVMe 的工作负载与可接受 SAS/SATA SSD 的工作负载 |
| **GPU 或专用硬件需求**        | 确定计算集群是否需要直通设备                         |
| **操作系统组合**             | Windows、Linux、BSD——会影响驱动和集成规划          |

### 增长预测

* **6 个月、12 个月和 24 个月的预测** 用于 VM 数量、CPU、RAM 和存储。
* **增长模式：** 计算增长是否快于存储，还是同比例增长？这会直接影响 HCI、HCI + Compute 和 UCI 的决策。
* **季节性或突发模式** —— 具有峰值时段的工作负载可能需要稳态指标无法显示的余量。

### 性能要求

* **IOPS 目标** 按工作负载层级（数据库、应用、文件服务）。
* **延迟要求** —— 数据库需要亚毫秒级，而文件服务器则可接受通用级别。
* **吞吐量** —— 用于备份、媒体或分析工作负载的顺序读/写带宽。

### 可用性与灾难恢复要求

* **RPO（恢复点目标）：** 可接受的数据丢失量是多少？决定快照频率和站点同步计划。
* **RTO（恢复时间目标）：** 服务必须多快恢复？影响租户是否需要多节点 HA 还是单节点自动故障切换。
* **N+1 预期：** 集群能否在所有工作负载持续运行的情况下承受一次完整节点故障？这与下面提到的 [RAM 保留决策](#ram-reservation-decision) 直接相关。
* **DR 站点要求：** 客户是否需要站点同步复制到第二个位置？

### 网络拓扑与约束

* **现有交换基础设施：** 品牌、型号、能力（MLAG、LACP、BGP）。
* **每个节点可用的 NIC：** 2 块还是 4 块以上决定网络设计模型。
* **VLAN 要求：** 需要多少个隔离网络？租户使用共享 VLAN 还是专用 VLAN？
* **物理约束：** 所有硬件都在同一个机架吗？多个机架？多个站点？
* **核心 Fabric 延迟：** 所有节点必须位于同一交换 Fabric 上，且零交换跳数。

### 预算与时间表

* **硬件预算：** 影响服务器厂商选择和节点数量。
* **许可模式：** 按节点计费——会影响成本优化策略。
* **安装时间表：** 标准部署还是分阶段上线。

***

## 工作负载到资源的转换

一旦你拿到客户的工作负载清单，就将其转换为 VergeOS 资源需求。VergeOS 的开销明显 **更低** ，与传统平台不同——没有 Controller VM（CVM）、没有 vCenter 设备，也没有单独的管理平面来消耗资源。

### 步骤 1：汇总工作负载总量

汇总客户的工作负载需求：

```
总 vCPU 核心数  = Σ（每个 VM 的核心数）
总 RAM（GB）    = Σ（每个 VM 的 RAM）
总存储（TB） = Σ（每个 VM 的已分配存储）
```

### 步骤 2：添加 VergeOS 系统开销

VergeOS 的开销很小，但必须计入：

| 资源                      | 开销                                      |
| ----------------------- | --------------------------------------- |
| **每个 vSAN 节点的 RAM**     | VergeOS 需要 16 GB + 每 1 TB 原始存储 1 GB（最低） |
| **每个 vSAN 节点的 RAM（推荐）** | 16 GB + 每 1 TB 原始存储 1.5 GB              |
| **每个存储节点的 CPU**         | 每块磁盘 1 个核心（推荐）                          |
| **Tier 0 存储**           | 每 1 TB 可用容量 5–10 GB（仅控制器节点）             |
| **仅计算节点**               | 仅需要 16 GB 给 VergeOS；没有存储开销              |

{% hint style="success" %}
**租户节点 RAM：无需额外的主机层开销**

当你为租户节点分配 RAM 时， **全部分配量** 就是主机保留的量——你不需要 **不** 为该租户额外添加主机层开销。不过，在租户内部，其嵌套的 VergeOS 实例会先从该分配中消耗标准开销（16 GB + 每 1 TB 存储 1 GB），然后租户的来宾 VM 才能获得内存。

所以有两个不同的层面：在 **host**，在主机层面，将租户节点大小设为你希望租户拥有的 RAM。在 **租户**，按（分配的 RAM − 16 GB − 1 GB/TB）来规划其来宾工作负载。
{% endhint %}

### 步骤 3：考虑 HA 余量

如果客户要求 N+1 可用性（集群在所有 VM 运行的情况下可以承受一个节点故障），你必须确保 **其余节点** 拥有足够的 CPU 和 RAM 总量来承载故障节点的工作负载。

**经验法则：** 对于 N 节点集群，每个节点的使用量不应超过 `(N-1)/N` 的总资源。例如，在 4 节点集群中，每个节点的目标利用率应为 75%。

### 步骤 4：计算节点数量

将总资源需求（包括开销和 HA 余量）除以每节点容量，以确定最少节点数。始终向上取整，并根据参考架构验证结果。下面的节点数量区间只是粗略经验法则——HCI 适用于较小的部署（通常为 2--12 个节点），而当计算和存储增长出现分化或需要专用硬件时，则采用 UCI：

* **2–6 个节点 → HCI**
* **6–10 个节点 → HCI + 专用计算**
* **10+ 个节点 → UCI**

```mermaid
flowchart TD
    A["汇总工作负载<br/>CPU + RAM + 存储"] --> B["添加 VergeOS 开销<br/>每节点 16GB + 1GB/TB"]
    B --> C["应用 HA 余量<br/>(N-1)/N 利用率目标"]
    C --> D["除以每节点容量"]
    D --> E{"节点数量？"}
    E -->|"2-6"| HCI["建议采用 HCI"]
    E -->|"6-10"| HCC["建议采用 HCI + 计算"]
    E -->|"10+"| UCI["建议采用 UCI"]

    style HCI fill:#d1fae5,stroke:#059669
    style HCC fill:#fef3c7,stroke:#d97706
    style UCI fill:#e0e7ff,stroke:#4f46e5
```

***

## 租户节点规划

对于多租户部署（CSP、MSP 或内部部门隔离），每个租户都运行在一个虚拟数据中心（VDC）中，该虚拟数据中心由一个或多个 **租户节点**. 租户节点是充当租户嵌套 VergeOS 实例计算节点的虚拟机；存储通过主机存储层配额提供，网络则通过租户的虚拟网络提供。

### 单节点租户与多节点租户

**单节点租户** 是默认且首选的起点：

* 通过自动故障切换提供冗余——如果物理主机故障，租户节点会自动在另一台主机上重启。
* 管理更简单，也更易于合理配置规模。
* 可以纵向扩展（增加核心/RAM）而不会中断。
* 随着租户增长，后续还可以非中断地添加更多节点。

**多节点租户** 在以下情况下需要：

1. **资源需求超过集群上限** —— `每台机器的最大 RAM` 以及 `每台机器的最大核心数` 集群设置限制了单个租户节点的大小。
2. **集群应用程序** 需要工作负载运行在不同的物理主机上（例如，为实现 HA，将数据库主副本放在不同节点上）。
3. **混合硬件能力** —— 租户既需要标准计算节点，又需要带 GPU 的节点，而这些节点位于不同的物理集群中。
4. **合规要求** 要求不同工作负载类型之间进行硬件隔离。

### 合理配置规模策略

VergeOS 租户支持 **无中断扩展** —— 你可以在不中断正在运行的工作负载的情况下，为现有节点添加资源或添加全新的节点。推荐做法：

1. **按当前或近期开销进行配置** —— 不要为了推测性的未来增长而过度分配。
2. **逐步扩展** —— 随着需求显现，再增加租户节点资源。
3. **在添加新节点之前先将现有节点用满** —— 将一个节点从 32 GB 提升到 64 GB，比再添加第二个 32 GB 节点更高效，除非应用 HA 需要物理隔离。

### 配置示例

### 小型单节点

**场景：** 3 个 VM，无特殊要求，集群允许的最大值为 64 GB / 16 核。

**配置：** 1 个租户节点——16 GB RAM、8 核。

**扩展路径：** 先增加现有节点的 RAM/核心数（最高 64 GB / 16 核），必要时再添加第二个节点。

### 中型 HA

**场景：** 包含 4 台 Web 服务器 + 2 台数据库服务器、需要物理主机隔离的 Web 农场。

**配置：** 2 个租户节点——每个 64 GB RAM、12 核。HA 组通过反亲和策略确保 Web/数据库实例运行在不同的物理主机上。

**扩展路径：** 增加节点资源，或添加第三个节点以进一步分散工作负载。

### 混合工作负载带 GPU

**场景：** 标准 VM + 在不同硬件集群上进行 GPU 加速的视频渲染。

**配置：** 4 个租户节点——标准集群上 2 个（每个 64 GB），vGPU 集群上 1 个（64 GB），高性能集群上 1 个（48 GB）。

**扩展路径：** 根据各集群的能力和工作负载需求，独立扩展每个节点。

### 企业级分布式

**场景：** 分布式分析平台，需要 3 台应用服务器位于不同的物理主机上 + 数据处理节点。

**配置：** 4 个租户节点——3 × 64 GB / 12 核（每个节点上的应用 + 数据库，使用 HA 组反亲和）+ 1 × 32 GB / 8 核（数据处理）。

**扩展路径：** 向现有节点添加资源，或添加节点以实现进一步的物理隔离。

***

## 拓扑选择决策框架

在收集完工作负载需求并完成资源转换后，请使用以下标准来给出架构建议：

| 决策标准       | HCI          | HCI + 计算         | UCI                |
| ---------- | ------------ | ---------------- | ------------------ |
| **节点数量**   | 2–6          | 6–10             | 10+                |
| **增长模式**   | 成比例（计算 ≈ 存储） | 计算 > 存储          | 任一（完全独立）           |
| **专用化**    | 不需要          | 部分需要（计算集群中有 GPU） | 完全需要（GPU、高内存、存储密集） |
| **复杂度容忍度** | 极少的 IT 人员    | 中等               | 专门的基础设施团队          |
| **预算**     | 最具成本效益       | 中等               | 最高（但在规模化时最有效率）     |
| **性能隔离**   | 可接受的争用       | 计算与存储 I/O 隔离     | 最大化——每个角色都在专用硬件上   |

### 决策检查清单

1. **节点数量少于 6 个吗？** → 除非有明确理由要分离计算，否则先从 HCI 开始。
2. **计算增长是否快于存储？** → HCI + 计算允许你添加廉价的纯计算节点。
3. **是否有 GPU、高内存或其他专用硬件需求？** → UCI 允许按硬件类型设置专用计算集群。
4. **客户是否需要独立扩展存储？** → 只有 UCI 模型具有专用存储集群。
5. **运维简洁性是否是首要优先级？** → HCI 的管理开销最低。
6. **环境能否随着时间演进？** → 当然可以。VergeOS 支持通过向现有系统添加集群，从 HCI → HCI + 计算 → UCI 逐步过渡。

***

## RAM 保留决策

在安装过程中，工程师必须决定 RAM 保留偏好。这是在以下之间的权衡： **可用内存** 以及 **N+1 HA 强制保障**:

| 选项                  | 行为                                             | 最适合                                  |
| ------------------- | ---------------------------------------------- | ------------------------------------ |
| **更多可用内存**          | 系统允许 VM 使用更多可用 RAM，从而减少为故障切换余量自动保留的内存          | 在这些环境中，最大化每节点工作负载密度比保证 N+1 故障切换能力更重要 |
| **更强的 N+1 HA 强制保障** | 系统保留更多 RAM，以确保当某个节点故障时，其余节点有保证的容量来承载所有迁移出的工作负载 | 具有严格正常运行时间 SLA、且保证故障切换不可妥协的生产环境      |

{% hint style="warning" %}
这个决定应在 **之前** 安装当天做出。在范围界定期间与客户讨论这种权衡，并在安装计划中记录所选偏好。
{% endhint %}

***

## 文档交付物

完整的范围界定工作应生成以下文档包，供安装工程师直接使用：

### 1. 网络设计文档

* **二层设计图** —— 物理交换机、VLAN、端口分配、MLAG/堆叠配置。
* **三层设计图** —— 子网、网关、路由（如适用则为 BGP/OSPF）、DNS 服务器。
* **A-B 电缆图** —— 从每个节点到每台交换机的每一根电缆，都标注端口标识。
* **核心 Fabric 配置** —— Core 1 和 Core 2 的专用 VLAN、MTU 9216+ 确认、零交换跳数验证。

### 2. 机架立面图

* 每个节点、交换机、PDU 和线缆管理的物理摆放。
* 电源回路分配与冗余映射。

### 3. IP 分配计划

| 网络     | 地址               | 用途                                                  |
| ------ | ---------------- | --------------------------------------------------- |
| 管理/UI  | `10.x.x.2/24`    | VergeOS Web 界面和 API                                 |
| 网关     | `10.x.x.1`       | 外部流量的默认网关                                           |
| 核心织构 1 | VLAN 900         | 在交换机上创建未打标签的接入 VLAN；节点 IP 由 VergeOS 自动分配。节点间存储和控制流量 |
| 核心织构 2 | VLAN 901         | 在交换机上创建未打标签的接入 VLAN；节点 IP 由 VergeOS 自动分配。冗余节点间流量    |
| IPMI   | `192.168.x.0/24` | 带外管理                                                |
| 租户网络   | 按租户分配            | 客户专属子网                                              |

### 4. 硬件物料清单

* 每个节点的服务器型号、CPU、RAM、磁盘配置。
* NIC 类型和速率。
* 交换机型号和端口数量。
* 0 级 NVMe 规格（DWPD、每 TB 可用存储容量）。

### 5. 安装计划

* 选定的参考架构（HCI、HCI + Compute 或 UCI）。
* 每个节点的磁盘层分配。
* RAM 保留偏好（可用内存 vs. N+1 保障）。
* 加密决策（是否启用静态加密、密钥存储方案）。
* NTP 服务器配置。
* 管理员凭据方案（密码库引用）。

***

{% hint style="info" %}
**来自 VMware 或 Nutanix？**

VergeOS 的范围界定只需一次容量规划：每个节点固定 16 GB 的操作系统开销，外加每 TB 原始存储 1 GB。没有 CVM，没有单独的管理设备，也无需按功能单独许可——计算、存储、网络和多租户作为一个平台一起进行容量规划。
{% endhint %}

***

## 摘要

| 阶段         | 输出                                   |
| ---------- | ------------------------------------ |
| **需求收集**   | 已完成的清单，包含工作负载清单、增长预测、性能目标和网络约束       |
| **资源转换**   | 应用 VergeOS 开销和 HA 余量后的 CPU、RAM 和存储总量 |
| **租户规划**   | 每个租户的单节点与多节点决策，并附示例配置                |
| **拓扑选择**   | HCI、HCI + 计算或 UCI 的建议及其理由            |
| **RAM 保留** | 已记录的偏好——可用内存 vs. N+1 保障              |
| **文档包**    | 网络图、机架立面图、IP 规划、BOM 和安装计划            |

## 下一步

* [**硬件要求**](/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/01-hardware-requirements.md) —— 请根据最低和推荐要求核对你的节点规格。
* [**参考架构**](/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/02-reference-architectures.md) —— 请查看所选架构的详细拓扑图。
* [**模块 3：安装**](/learn-the-platform/zh/mo-kuai-3-an-zhuang/03-installation.md) —— 进入安装准备与执行。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/03-customer-scoping.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.