> 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/mo-kuai-1-jia-gou-ji-chu/02-hci-vs-uci.md).

# HCI 与 UCI：部署模型

## 部署 VergeOS 的两种方式

VergeOS 在基础设施平台中独树一帜，因为它支持 **两种不同的部署模型** 并且都来自同一套软件安装：

* **HCI（超融合基础设施）** -- 计算和存储都运行在每个节点上。资源一起扩展。
* **UCI（超统一基础设施）** -- 计算和存储运行在专用、独立的节点类型上。资源可独立扩展。

大多数竞争平台（VMware vSAN、Nutanix）只支持 HCI。VergeOS 同时提供两种选项——而且你甚至可以在一个系统内将它们组合使用。

{% hint style="info" %}
**系统 vs. 集群**

* **系统** — 整个 VergeOS 部署，由一个或多个作为单一整体管理的集群组成。
* **集群** — 一组硬件匹配的节点，共享计算和高可用性边界。vSAN 存储层跨越系统中的所有集群，因此尽管计算和 HA 是按集群范围划分，存储仍在整个系统范围内共享。
  {% endhint %}

## HCI：超融合基础设施

在 HCI 部署中，集群中的每个节点都会贡献 **计算和存储** 存储容量和计算资源。当你需要更多任意一种资源时，只需再添加一个节点——它会同时增加两者。

### 工作方式

最常见的起点是一个 2 节点 HCI 集群。两个控制器节点组成一个集群，负责存储（vSAN）和计算（VM 工作负载）。两个节点都将 Tier 0 和工作负载层磁盘贡献到共享存储池中，并且两个节点都运行虚拟机。

要扩展，只需添加 **横向扩展节点** 到同一个集群中。每个扩展节点都会通过网络自动发现加入，并立即贡献额外的存储和计算容量。

```mermaid
graph TB
    subgraph cluster1["集群 1（HCI）"]
        N1["节点 1 — 控制器<br/>存储 + 计算"]
        N2["节点 2 — 控制器<br/>存储 + 计算"]
        S1["扩展节点 3<br/>存储 + 计算"]
        S2["扩展节点 4<br/>存储 + 计算"]
    end
    subgraph fabric["核心 Fabric（共享 L2）"]
        CF["核心 Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF
    EXT["外部网络"] --- N1
    EXT --- N2
    EXT --- S1
    EXT --- S2

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

### 何时选择 HCI

| 场景                  | 为什么 HCI 适用             |
| ------------------- | ---------------------- |
| **小型部署** （2--8 个节点） | 复杂度最低，每个节点身兼两职         |
| **均衡型工作负载**         | 当存储和计算需求大致以相同速度增长时     |
| **边缘 / 远程站点**       | 具有完整 HA 且物理占用小的 2 节点集群 |
| **评估和测试**           | 构建可运行 VergeOS 系统的最快途径  |
| **注重预算**            | 小到中型工作负载所需的总节点更少       |

### 主要特性

* **最少**: 2 个节点（控制器对）
* **扩展**: 向同一集群添加扩展节点
* **节点角色**: 所有节点都运行存储 **以及** 计算
* **集群数量**: 1
* **简洁性**: 最易部署和管理

## UCI：超统一基础设施

UCI 是任何部署的总称，其中存储和计算在 **专用节点类型**上独立扩展。规范形式使用三个集群（控制器、存储、计算）；一种流行的混合变体将控制器 + 存储合并为两个集群。无论哪种方式，你都可以独立扩展每个资源层——在需要更多容量时添加存储节点，或在需要更多 CPU 和 RAM 时添加计算节点，而无需两者都购买。

### 工作方式

UCI 部署同样从一对 2 节点控制器开始，但控制器负责管理系统，而不运行生产工作负载或存储用户数据。专用 **存储节点** 组成第二个集群，提供全部 vSAN 容量。专用 **计算节点** 组成第三个集群，运行所有 VM 工作负载。

```mermaid
graph TB
    subgraph cluster1["集群 1（控制器）"]
        N1["节点 1 — 控制器"]
        N2["节点 2 — 控制器"]
    end
    subgraph cluster2["集群 2（存储）"]
        ST1["存储节点 1"]
        ST2["存储节点 2"]
    end
    subgraph cluster3["集群 3（计算）"]
        C1["计算节点 1"]
        C2["计算节点 2"]
    end
    subgraph fabric["核心 Fabric（共享 L2）"]
        CF["核心 Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["外部网络"] --- N1
    EXT --- N2
    EXT --- ST1
    EXT --- ST2
    EXT --- C1
    EXT --- C2

    style cluster1 fill:#f0f4ff,stroke:#336
    style cluster2 fill:#fff3e0,stroke:#e65100
    style cluster3 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#fce4ec,stroke:#c62828
```

### 何时选择 UCI

| 场景                    | 为什么 UCI 有效                        |
| --------------------- | --------------------------------- |
| **大型环境** （10+ 个节点）    | 独立扩展可避免过度配置                       |
| **存储密集型工作负载**         | 在不购买你不需要的计算资源的情况下添加存储容量           |
| **计算密集型工作负载**         | 在不购买你不需要的存储资源的情况下添加 GPU 或高 CPU 节点 |
| **AI / HPC / GPU 集群** | 带 GPU 直通的专用计算集群，与存储分离             |
| **云服务提供商**            | 在多个租户之间按资源层优化硬件支出                 |
| **可预测、不均衡增长**         | 存储和计算需求以不同的速度增长                   |

### 主要特性

* **最少**：6 个节点（2 个控制器 + 2 个存储 + 2 个计算）
* **扩展**：独立向各个集群添加节点
* **节点角色**：每个节点只有单一角色（控制器、存储或计算）
* **集群数量**：规范形式为 3 个（控制器、存储、计算）；混合变体为 2 个
* **灵活性**：按角色为硬件精确配比（存储用高密度 NVMe，计算用 GPU 配置）

## 混合 UCI：双集群变体

VergeOS 还支持 **混合 UCI** 模型——一种双集群 UCI 变体，将控制器和存储角色合并到一个集群中。控制器节点提供 vSAN 存储和系统管理；它们不运行生产 VM 工作负载。一个由专用计算节点组成的独立集群负责所有 VM 执行。

这是一种很受欢迎的部署模型，因为它让控制器/存储层保持精简且专用，而计算则通过自己的集群独立扩展。控制器通过核心 Fabric 向计算节点提供 vSAN 存储。

{% hint style="success" %}
**控制器节点不必运行 VM**

在混合部署中，控制器节点通常仅作为存储和管理节点使用——其上不运行生产 VM。这减少了控制器上的资源争用，并简化了容量规划：通过向控制器集群添加节点来扩展存储，通过向计算集群添加节点来扩展计算。
{% endhint %}

```mermaid
graph TB
    subgraph cluster1["集群 1（控制器 — 仅存储）"]
        N1["节点 1 — 控制器<br/>存储 + 管理"]
        N2["节点 2 — 控制器<br/>存储 + 管理"]
    end
    subgraph cluster2["集群 2（仅计算）"]
        C1["计算节点 1"]
        C2["计算节点 2"]
    end
    subgraph fabric["核心 Fabric（共享 L2）"]
        CF["核心 Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["外部网络"] --- N1
    EXT --- N2
    EXT --- C1
    EXT --- C2

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

或者，控制器 **可以** 在需要时与存储一起运行 VM——这在较小的环境中很有用，因为仅为存储预留两台节点会显得浪费。混合模型很灵活：控制器可以只提供存储，或者提供存储 + 计算，具体取决于你的需求。

## HCI vs UCI 对比

| 方面        | HCI      | UCI              |
| --------- | -------- | ---------------- |
| **最少节点数** | 2        | 6                |
| **集群数量**  | 1        | 3                |
| **节点类型**  | 所有节点相同   | 控制器、存储、计算        |
| **存储扩展**  | 与计算绑定    | 独立               |
| **计算扩展**  | 与存储绑定    | 独立               |
| **硬件统一性** | 所有节点规格相同 | 按角色优化节点          |
| **部署复杂度** | 更低       | 更高               |
| **小规模成本** | 更低（节点更少） | 更高（最少 6 个节点）     |
| **大规模成本** | 可能过度配置   | 各层级支出最优化         |
| **最适合**   | 小到中型、均衡  | 大规模、不均衡增长、专用工作负载 |

## 决策框架

使用此流程图来指导你的部署模型建议：

```mermaid
flowchart TD
    A["部署需要多少个节点<br/>？"] --> B{"少于 6 个？"}
    B -->|是| C["✅ HCI<br/>UCI 至少需要 6 个节点"]
    B -->|否| D{"存储和计算<br/>是否以相同速度增长？"}
    D -->|"是 — 均衡增长"| E["✅ HCI<br/>更易管理，<br/>无资源浪费"]
    D -->|"否 — 不均衡增长"| F{"需要专用硬件<br/>吗？（GPU、NVMe 密集型）"}
    F -->|是| G["✅ UCI<br/>按角色合理配置硬件"]
    F -->|否| H{"大规模下的成本优化<br/>是否优先？"}
    H -->|是| I["✅ UCI<br/>避免过度配置"]
    H -->|否| J["✅ HCI<br/>越简单越好"]

    style C fill:#e8f5e9,stroke:#2e7d32
    style E fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#fff3e0,stroke:#e65100
    style J fill:#e8f5e9,stroke:#2e7d32
```

### 快速经验法则

1. **从 HCI 开始** 除非你有特定理由采用 UCI
2. **考虑 UCI** 当你需要 10+ 个节点或有专用硬件需求时
3. **混合 UCI** （双集群）是一个很好的过渡方案——先从 HCI 开始，然后将计算拆分到其自己的集群上
4. 你可以 **演进** 随着环境增长，从 HCI 到混合 UCI 再到完整 UCI

## Terraform Playground 示例

VergeOS Terraform Playground 为每种部署模型都提供了示例配置，便于测试各个拓扑：

| 模型             | 示例文件                                          | 节点 | 集群 |
| -------------- | --------------------------------------------- | -- | -- |
| **2 节点 HCI**   | `examples/2-node-hci.tfvars`                  | 2  | 1  |
| **HCI + 横向扩展** | `examples/4-node-hci.tfvars`                  | 4  | 1  |
| **混合 UCI**     | `examples/4-node-hybrid-hci-2-cluster.tfvars` | 4  | 2  |
| **完整 UCI**     | `examples/6-node-uci-3-cluster.tfvars`        | 6  | 3  |

每个示例都是一个 `.tfvars` 文件，你将其复制到 `terraform.tfvars` 并根据你的环境设置进行自定义。部署模型由布尔切换变量控制：

* **HCI**：无需切换（默认）
* **HCI + 横向扩展**: `create_scale_out_nodes = true`
* **混合 UCI**: `create_compute_nodes = true`
* **UCI**: `create_storage_nodes = true` 以及 `create_compute_nodes = true`

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

来自 vSAN？VergeOS 可从同一安装同时支持 HCI 和 UCI 部署——分解式存储无需单独的产品层或许可证。仅存储和仅计算节点类型都是一等部署选项，全部由同一个 UI 管理。
{% endhint %}

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

来自 Nutanix？VergeOS 将存储作为集成的 OS 服务运行——没有需要按每个节点进行容量规划、打补丁或排障的 CVM。仅存储和仅计算节点类型让你可以在单一系统内按角色专门分配硬件。
{% endhint %}

## 单节点部署

虽然 VergeOS 旨在用于多节点集群， **单节点部署** 也有合理的使用场景：

* **裸机替代** — 用单个运行多个 VM 的 VergeOS 节点替代传统物理服务器，在不需要第二个节点的情况下获得虚拟化的好处（快照、资源管理、轻松备份）
* **边缘站点** — 位于远程位置的单个节点，且数据在本地并不关键（例如瘦客户端主机、本地缓存、标牌），必要时可从中心站点复制
* **开发 / 实验室** — 用于测试和开发的独立系统

单节点部署仍然具有 **磁盘级冗余** — vSAN 在节点内跨驱动器使用双副本镜像（可用容量约为 50%），以防止单个磁盘故障。不过， **没有节点级冗余** — 如果节点本身发生故障，工作负载会中断，直到它恢复。强烈建议使用快照和异地复制。

## 摘要

| 概念              | 核心要点                           |
| --------------- | ------------------------------ |
| **HCI**         | 每个节点都做所有事情。简单，且在小规模下具有成本效益。    |
| **UCI**         | 每个节点都有专用角色。在大规模下灵活且更具成本优化。     |
| **混合 UCI**      | 控制器负责存储/管理；计算可独立扩展。双集群 UCI 变体。 |
| **VergeOS 的优势** | 同一平台支持这三种模型——无需产品变更。           |

## 下一步

现在你已经了解 HCI 和 UCI 部署模型，接下来的主题将介绍支撑二者的存储层： [**vSAN / VergeFS →**](/learn-the-platform/zh/mo-kuai-1-jia-gou-ji-chu/03-vsan-vergefs.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/mo-kuai-1-jia-gou-ji-chu/02-hci-vs-uci.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.