> 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/02-reference-architectures.md).

# 参考架构

VergeOS 支持同一软件安装中的三种部署架构。选择合适的架构取决于节点数量、增长模式以及工作负载专用化需求。本页将逐一介绍每种模型，提供决策框架，并涵盖两个常见的真实场景：边缘部署和云服务提供商（CSP）多租户环境。

## 架构决策树

使用以下框架来指导您的建议。下方的节点数量区间只是粗略经验法则：HCI 适合较小的部署（通常 2--12 个节点），而当计算与存储增长出现分化或需要专用硬件时，则适用 UCI。

```mermaid
flowchart TD
    A["部署将有<br/>多少个节点？"] --> B{"2 -- 6 个节点"}
    A --> C{"6 -- 10 个节点"}
    A --> D{"10+ 个节点"}

    B --> E{"计算和存储会<br/>按比例增长吗？"}
    E -->|"是"| F["HCI"]
    E -->|"否 -- 计算增长更快"| G["HCI + 专用计算<br/>(混合 2 集群 UCI)"]
    E -->|"不确定"| H{"需要专用硬件<br/>吗？（GPU，高内存）"}

    C --> H
    D --> I["UCI（Canonical 3 集群）"]

    H -->|"是"| I
    H -->|"否"| G
    H -->|"未来可能需要"| G

    style F fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#f0f4ff,stroke:#336
```

**快速经验法则：**

1. **从 HCI 开始** ，除非你有不采用它的明确理由。
2. **考虑 HCI + 计算** 当计算需求的增长超过存储增长时（6--10 个节点）。
3. **选择 UCI** 用于 10+ 节点环境、专用硬件或最高性能隔离。
4. 你可以 **演进** ，随着环境增长从 HCI 过渡到 HCI + 计算，再到 UCI——同一套 VergeOS 安装支持三者。

***

## 模型 1：HCI（超融合基础设施）

**节点范围：** 2--6 个节点 | **集群：** 1

在 HCI 部署中，每个节点都贡献 **计算和存储** 。两个控制器节点承载 Tier 0（vSAN 元数据）和 Tier 1（工作负载）存储，并运行虚拟机。横向扩展节点向同一集群添加 Tier 1 存储和计算能力。

```mermaid
graph TB
    subgraph cluster1["集群 1 -- HCI"]
        N1["节点 1 -- 控制器<br/>Tier 0 + Tier 1<br/>存储 + 计算"]
        N2["节点 2 -- 控制器<br/>Tier 0 + Tier 1<br/>存储 + 计算"]
        S1["节点 3 -- 横向扩展<br/>Tier 1<br/>存储 + 计算"]
        S2["节点 4 -- 横向扩展<br/>Tier 1<br/>存储 + 计算"]
    end
    subgraph fabric["核心 Fabric"]
        CF["核心 1 + 核心 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF

    style cluster1 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#f0f4ff,stroke:#336
```

### 优势

* **操作简单** -- 单一集群、单一硬件规格、统一管理。
* **可预测的扩展** -- 每个节点都会按比例同时增加存储和计算。
* **最低入门门槛** -- 2 节点集群是可能的最小 VergeOS 部署。
* **单一硬件规格** 简化采购和备件库存。

### 限制

* 无法独立扩展计算或存储（反之亦然）。
* 硬件专用化有限——所有节点都承担相同角色。
* 在考虑第二个集群之前，建议最大约 6 个节点。
* 同时运行元数据操作和虚拟机工作负载的控制器节点可能出现资源争用。

### 理想用例

| 场景                | 为什么 HCI 适用            |
| ----------------- | --------------------- |
| 小型/中型部署（2--6 个节点） | 复杂度最低，每个节点身兼两职        |
| 均衡型工作负载           | 存储和计算以大致相同的速度增长       |
| 边缘 / 远程站点         | 2 节点集群，具备完整 HA，且占用空间小 |
| 评估和测试             | 构建可运行 VergeOS 系统的最快途径 |

***

## 模型 2：HCI + 专用计算（混合 2 集群 UCI）

**节点范围：** 6--10 个节点 | **集群：** 2

这是 UCI 的混合 2 集群变体：控制器和存储角色仍收敛在一个 HCI 集群中，而计算则拆分到独立集群。HCI 集群（集群 1）通过其控制器和可选的横向扩展节点提供全部存储。计算集群（集群 2）运行虚拟机工作负载，不提供任何磁盘。

```mermaid
graph TB
    subgraph cluster1["集群 1 -- HCI（存储 + 计算）"]
        N1["节点 1 -- 控制器<br/>Tier 0 + Tier 1"]
        N2["节点 2 -- 控制器<br/>Tier 0 + Tier 1"]
        S1["节点 3 -- HCI<br/>Tier 1（可选）"]
    end
    subgraph cluster2["集群 2 -- 仅计算"]
        C1["节点 4 -- 计算"]
        C2["节点 5 -- 计算"]
        C3["节点 6 -- 计算"]
        C4["节点 7+ -- 扩展"]
    end
    subgraph fabric["核心 Fabric"]
        CF["核心 1 + 核心 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF
    C4 --- CF

    style cluster1 fill:#fff3e0,stroke:#e65100
    style cluster2 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### 关键设计原则

### 集群 1 -- HCI（合并）

* 始终包含节点 1 和 2 以及 Tier 0 存储（控制器）。- 可包含额外的 HCI 横向扩展节点，以增加存储和计算。- 通过集群级开关控制该集群是否同时运行虚拟机工作负载。- 所有存储层都位于此集群中。

### 集群 2 -- 仅计算

* 纯计算——为虚拟机提供最大可用 CPU 和 RAM。- 可根据计算需求独立扩展。- 支持灵活、针对工作负载优化的硬件（GPU 节点、高内存节点）。- 来自计算节点的存储 I/O 通过核心 fabric 传输到集群 1。

### 优势

* 无需购买不需要的存储即可独立扩展计算。
* 保持存储层的 HCI 操作简单性。
* 成本更高效——只扩展正在增长的资源层。
* 当需求进一步演变时，可清晰过渡到标准的 3 集群 UCI。

### 限制

* 来自计算节点的存储 I/O 会跨越网络（因此核心 fabric 带宽必须充足）。
* 比纯 HCI 更复杂（需要管理两个集群而不是一个）。
* 需要决定 HCI 集群是否也应运行工作负载。

### 理想用例

| 场景         | 为什么 HCI + 计算有效     |
| ---------- | ------------------ |
| 6--10 节点部署 | 两集群模型的最佳区间         |
| 计算增长快于存储   | 无需扩展磁盘即可增加 CPU/RAM |
| GPU 或专用计算  | 带直通硬件的专用计算集群       |
| 成本优化       | 只扩展你需要的部分          |

***

## 模型 3：UCI（超融合基础设施）-- 标准 3 集群

**节点范围：** 10+ 个节点 | **集群：** 3+

标准的 3 集群 UCI 将控制器、存储和计算完全分离到专用集群中。每个资源层都可独立扩展，并使用针对其角色优化的硬件。（UCI 是任何独立扩展部署的统称；上面的模型 2 是其混合 2 集群变体。）

```mermaid
graph TB
    subgraph cluster1["集群 1 -- 专用控制器"]
        N1["节点 1 -- 控制器<br/>仅 Tier 0 | 高内存"]
        N2["节点 2 -- 控制器<br/>仅 Tier 0 | 高内存"]
    end
    subgraph cluster2["集群 2 -- 专用存储"]
        ST1["节点 3 -- 存储<br/>高密度 NVMe | Tier 1"]
        ST2["节点 4 -- 存储<br/>高密度 NVMe | Tier 1"]
        ST3["节点 5 -- 存储<br/>高密度 NVMe | Tier 1"]
    end
    subgraph cluster3["集群 3+ -- 专用计算"]
        标准计算
        GPU 计算
        高内存
    end
    subgraph fabric["核心 Fabric"]
        CF["核心 1 + 核心 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    ST3 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF

    style cluster1 fill:#f3e5f5,stroke:#6a1b9a
    style cluster2 fill:#e8f5e9,stroke:#2e7d32
    style cluster3 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### 集群专用化

| 集群              | 角色                | 优化目标                                                   |
| --------------- | ----------------- | ------------------------------------------------------ |
| **集群 1 -- 控制器** | Tier 0 元数据，集群管理   | 高内存（例如 Data-Science RA 中的 768 GB），用于 Tier 0 的高耐久性 NVMe |
| **集群 2 -- 存储**  | 所有工作负载存储（Tier 1+） | 最高磁盘密度，NVMe 或 SAS/SATA SSD                             |
| **集群 3+ -- 计算** | 虚拟机工作负载，专用硬件      | 标准、GPU、高内存或自定义节点类型                                     |

### 优势

* **最高性能** -- 存储和计算之间没有资源争用。
* **完全独立扩展** -- 可增加存储而不增加计算（反之亦然）。
* **硬件专用化** -- 按角色精确配置硬件（存储采用高密度 NVMe，计算采用 GPU 装备）。
* **工作负载隔离** -- 为不同工作负载类型提供不同的计算集群。
* **适用于大规模和多租户环境。**

### 限制

* 三种架构中操作复杂度最高。
* 最少 6 个节点（由每集群最少 2 节点 × 3 个集群得出：2 个控制器 + 2 个存储 + 2 个计算）。
* 跨三种集群类型的容量规划更复杂。
* 集群之间对核心 fabric 带宽的要求更高。
* 建议初始部署时使用专业服务。

### 理想用例

| 场景                  | 为什么 UCI 有效        |
| ------------------- | ----------------- |
| 10+ 节点企业部署          | 独立扩展可避免过度配置       |
| AI / HPC / GPU 工作负载 | 专用 GPU 计算集群，与存储分离 |
| 云服务提供商              | 在多租户之间按资源层优化硬件支出  |
| 存储密集或计算密集型增长        | 只扩展正在增长的部分        |

***

## 架构对比

| 方面        | HCI   | HCI + 计算（混合 2 集群 UCI） | UCI（标准 3 集群）  |
| --------- | ----- | --------------------- | ------------- |
| **最少节点数** | 2     | 4（2 个 HCI + 2 个计算）    | 6 (2+2+2)     |
| **集群数量**  | 1     | 2                     | 3+            |
| **性能**    | 良好    | 更好                    | 最佳            |
| **硬件灵活性** | 低     | 中                     | 最高            |
| **独立扩展**  | 否     | 部分（仅计算）               | 完全            |
| **专用化**   | 无     | 仅计算                   | 完整（控制器、存储、计算） |
| **复杂度**   | 低     | 中                     | 高             |
| **资源效率**  | 可变    | 良好                    | 最高            |
| **最适合**   | 小型、均衡 | 中型、计算密集               | 大型、专用化        |

***

## 边缘部署场景

边缘集群是紧凑的 2 节点 VergeOS 部署，专为远程或分支办公室位置设计。它们使用低功耗、小型外形规格硬件，并直接连接（核心 fabric 不需要交换机）。

### 典型边缘配置

* **2 个节点** 通过双 NIC 直接连接（核心 fabric）。
* 小型外形规格硬件（Intel NUC、SFF 1L PC 或类似设备）。
* 每个节点 2 TB NVMe 用于工作负载 + 4 TB SSD 用于大容量存储。
* 尽管占用空间极小，仍具备完整 HA 和冗余。

```mermaid
graph LR
    N1["节点 1<br/>控制器 + 存储 + 计算"] <-->|"核心 Fabric<br/>(直接连接)"| N2["节点 2<br/>控制器 + 存储 + 计算"]
    N1 --- EXT["外部网络<br/>(上行链路)"]
    N2 --- EXT

    style N1 fill:#e8f5e9,stroke:#2e7d32
    style N2 fill:#e8f5e9,stroke:#2e7d32
```

### 边缘管理模型

VergeOS 支持三种复杂度递增的边缘管理场景：

1. **独立部署并集中管理** -- 每个站点采用 2 节点集群，通过 **Sites** 仪表板集中管理。目录仓库将虚拟机模板从管理集群分发到所有边缘站点。
2. **集中备份和灾难恢复** -- 与上面相同，外加主数据中心的中央系统提供 **Site Sync** 复制， **ioGuardian** 修复服务器，以及为所有分支办公室提供集中快照存储。
3. **多层次归档** -- 在 DR 站点增加一个二级归档集群，使用大容量 HDD 进行长期保留，提供完整的 3-2-1 备份策略。

### 何时推荐边缘

* 远程站点存在空间或电力限制。
* 数据集中存储但需要本地计算的应用。
* 管理 5--100+ 个分布式位置的组织。
* 对成本敏感的分支办公室部署。

***

## CSP / 多租户场景

云服务提供商利用 VergeOS 多租户能力，从共享基础设施提供 IaaS。每个租户都作为一个隔离的虚拟数据中心（VDC）运行，拥有自己的 UI、网络、存储和访问控制。

### 典型 CSP 配置

* **主数据中心中的 6 节点 HCI 集群** （高密度服务器，每节点 768 GB+ 内存）。
* **Site Sync** 用于数据中心之间的 DR。
* **ioGuardian** 用于从远程站点自动检索块数据的修复服务器。
* **全局行内去重** 减少复制快照的存储消耗。
* **租户模板** 自动提供完整的客户环境（租户、网络、防火墙规则、虚拟机、存储）。

### CSP 增长路径

| 阶段       | 部署                        | 节点数           |
| -------- | ------------------------- | ------------- |
| **阶段 1** | 2 个主站点，通过 Site Sync 实现 DR | 每个站点 6 个      |
| **阶段 2** | 在新地区添加 2 节点边缘集群           | 每个区域 2 个      |
| **阶段 3** | 通过添加集群来横向扩展边缘站点（示意）       | 每个站点不同        |
| **阶段 4** | 为存储密集型租户和归档层添加专用存储集群      | 每个站点 2+ 个存储节点 |

### CSP 的关键 VergeOS 功能

* **多租户** 客户环境之间完全隔离。
* **自助式管理** 租户管理员可通过 Web UI 和 API 进行管理。
* **目录仓库** 用于集中管理虚拟机模板。
* **OpenID 身份验证** 与现有身份提供方集成。
* **租户模板** 用于自动化、可重复的客户入驻。

***

## 网络设计模型概览

您选择的部署架构会影响网络设计。VergeOS 支持多种网络拓扑，详细内容见 [模块 4：网络](/learn-the-platform/zh/mo-kuai-4-wang-luo/04-networking.md)。以下是帮助您做出架构决策的简要概述：

| 模型               | 每节点 NIC 数 | 核心 Fabric      | 外部网络                     | 最适合            |
| ---------------- | --------- | -------------- | ------------------------ | -------------- |
| **L2 静态 + 专用核心** | 4         | 2 个专用 L2       | 绑定 L2（LACP）              | 生产环境、VMware 迁移 |
| **L3 动态 + 专用核心** | 4         | 2 个专用 L2       | 通过 BGP / OSPF / EIGRP 广播 | 大规模、先进分段       |
| **L3 静态 + 专用核心** | 4         | 2 个专用 L2       | 绑定 L3（静态路由）              | 大规模、三层交换       |
| **L2 静态（2 NIC）** | 2         | 2 个共享（VLAN 标记） | 与核心共享（VLAN 标记）           | 边缘、PoC、小型部署    |

**所有模型的关键要求：**

* 核心 fabric 网络必须位于 **专用二层网段** （彼此隔离）。
* 巨型帧（**MTU 9216+**）适用于所有核心网络交换机端口。
* **零交换跳数** 在核心网络中的节点之间——所有节点必须连接到同一交换网络。
* 核心网络端口上禁用 STP。

***

{% hint style="info" %}
**VMware 桥接**

来自 VMware？VergeOS 允许你在一个系统内独立扩展存储和计算——仅计算集群通过核心网络消耗共享 vSAN，且无需外部 SAN/NAS，也无需单独许可存储产品。
{% endhint %}

{% hint style="info" %}
**Nutanix 桥接**

来自 Nutanix？VergeOS 在一个系统中构建纯存储集群和纯计算集群——存储作为集成的 OS 服务运行，因此任何节点类型上都不会有消耗 RAM/CPU 的 CVM。
{% endhint %}

## 摘要

| 概念           | 核心要点                                     |
| ------------ | ---------------------------------------- |
| **HCI**      | 每个节点都做所有事情。简单、在小规模下具有成本效益。从这里开始。         |
| **HCI + 计算** | 混合型双集群 UCI：控制器+存储合并，计算可独立扩展。             |
| **UCI**      | 标准三集群：专用控制器、存储和计算。灵活性最大。                 |
| **边缘**       | 用于远程站点的双节点直连集群，集中管理。                     |
| **CSP**      | 支持站点同步 DR 和租户配方自动化的多租户 HCI 部署。           |
| **演进**       | 同一 VergeOS 安装支持这三种模式——可随时间从 HCI 演进到 UCI。 |

## 下一步

* [**客户范围界定**](/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/03-customer-scoping.md) ——学习需求收集方法论，将客户需求转化为具体的架构建议。
* [**网络**](/learn-the-platform/zh/mo-kuai-4-wang-luo/04-networking.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/02-reference-architectures.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.