> 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/lab.md).

# 实验：探索架构

## 实验概览

在本实验中，你将探索 **VergeOS Terraform Playground** ——一个使用 Terraform 部署虚拟 VergeOS 系统的开源项目。通过阅读代码和文档，你将巩固本模块涵盖的架构概念：核心 fabric 网络、vSAN 存储层、集群组织，以及 HCI 与 UCI 拓扑。

### 你将完成的内容

* **第 1 部分** ——阅读 playground 的架构文档和 Terraform 代码，了解 VergeOS 概念如何映射到基础设施即代码
* **第 2 部分** ——根据客户场景，推荐并绘制部署拓扑图
* **第 3 部分** ——比较四个示例部署配置并分析它们的差异

### 前置条件

* GitHub 账户（用于克隆仓库）
* 工作站上已安装 Git
* 文本编辑器或 IDE（推荐 VS Code）
* 无需访问 VergeOS 系统——本实验是阅读与设计练习

### 预计时间

**30 分钟**

***

## 第 1 部分：探索架构

在本节中，你将克隆 Terraform playground 仓库，并跟踪 VergeOS 架构概念如何以基础设施即代码的形式表达出来。

1. **克隆仓库**

   ```bash
   git clone https://github.com/verge-io/vergeos-terraform-playground.git
   cd vergeos-terraform-playground
   ```
2. **阅读架构文档**

   打开 `docs/architecture.md` 并通读整个文档。在阅读时，找出以下问题的答案：

   * 什么是 **四种部署场景** ，由 playground 支持？

   * 什么是 **安装种子文件** ，以及它如何实现无人值守安装？

   * 什么是 **最小部署** 规模？

   > **提示：** 四种场景列在 `docs/deployment-scenarios.md` 中，并附有拓扑图。最小部署是由两个控制器节点组成的单个 HCI 集群。
3. **查看部署场景图**

   打开 `docs/deployment-scenarios.md` 并研究每种场景的 Mermaid 拓扑图。对于每个场景，请注意：

   * 有多少 **节点** 参与其中
   * 有多少 **会创建集群** 哪些
   * 节点类型 **出现（控制器、横向扩展、存储、计算）** 出现（控制器、横向扩展、存储、计算）
   * 所有节点如何连接到 **core fabric** 以及 **外部网络**
4. **在 Terraform 中追踪 core fabric**

   打开 `main.tf` （根模块）并找到两个 core fabric 网络资源。回答以下问题：

   * 这些资源的名称是什么？（`core_fabric_1` 以及 `core_fabric_2`)
   * 什么 **MTU** 配置了什么？（9142——用于 vSAN 复制的巨型帧）
   * 这些网络启用了 DHCP 吗？（否—— `dhcp_enabled = false`)
   * 什么 `ipaddress_type` 被设置为（`无` ——这些是第 2 层传输）

   ```hcl
   # 你应该在 main.tf 中找到类似这样的资源：
   resource "vergeio_network" "core_fabric_1" {
     name           = "${var.system_name}-core-fabric-1"
     enabled        = true
     dhcp_enabled   = false
     on_power_loss  = "power_on"
     mtu            = 9142
     ipaddress_type = "none"
   }
   ```
5. **查看 Node 1 与 Node 2 的差异**

   打开 `modules/controllers/main.tf` 并比较 `verge_node_1` 以及 `verge_node_2`。需要识别的关键差异：

   * **Cloud-init 模板** —— Node 1 使用 `user-data-node1.yaml` （创建一个新系统，使用 `YC_VSAN_NEW=1`）。Node 2 使用 `user-data-node2.yaml` （加入现有系统，使用 `YC_VSAN_NEW=0`).
   * **安装后 API 设置** ——Node 1 的 cloud-init 包含一个脚本，用于配置更新源、启用 SSH，并可选择通过 VergeOS API 创建存储/计算集群。Node 2 没有安装后脚本。
   * **依赖链** ——Node 2 有一个 `depends_on` 对 Node 1 的引用，确保在第二个控制器尝试加入之前系统已完全初始化。

   两个节点共享相同的 VM 结构：Linux 操作系统系列，启用嵌套虚拟化，三个 virtio 网卡（external、core fabric 1、core fabric 2），带有 VergeOS ISO 的 CD-ROM，以及 cloud-init nocloud 数据源。
6. **回答理解问题**

   请回答以下问题（或与你的培训伙伴讨论）：

   | # | 问题                                                 | 预期答案                                               |
   | - | -------------------------------------------------- | -------------------------------------------------- |
   | 1 | 为什么 core fabric 使用两个独立交换机？                         | 冗余——如果一个交换机或路径失效，另一个可维持节点间连接                       |
   | 2 | 为什么在 core fabric 网络上禁用 DHCP？                       | Core fabric 使用静态 IP 地址；VergeOS 安装程序通过安装种子配置地址      |
   | 3 | 为什么 Node 2 必须等 Node 1 完成后才能开始？                     | Node 1 创建 VergeOS 系统；Node 2 需要加入一个已存在的系统           |
   | 4 | 哪些流量类型会通过 core fabric？                             | vSAN 复制、集群协调、VM 热迁移、控制平面通信                         |
   | 5 | 为什么 `quantity_tier_1_disks` 在启用存储节点时，为什么控制器被设置为 0？ | 在 UCI 模式下，专用存储节点提供全部 tier-1 容量；控制器只需要 tier-0 用于元数据 |

***

## 第 2 部分：设计练习

现在应用你所学到的内容。给定客户场景，推荐一个部署拓扑并说明你的决策理由。

### 客户场景

> **Midwest Manufacturing Co.** 正在从一个拥有 3 台 ESXi 主机的 VMware vSphere 环境迁移。他们当前运行 50 台 VM（Windows 和 Linux 混合），有约 10 TB 可用存储，并预计在未来 2 年内适度增长。他们有一个小型 IT 团队（2 人），并希望尽量降低运维复杂性。预算有限。

1. **选择 HCI 或 UCI**

   根据客户画像，你推荐哪种部署模型？请考虑：

   * **团队规模** — 2 人 IT 团队更偏向简单性

   * **增长模式** — “适度增长”意味着计算/存储按均衡方式扩展

   * **预算** — 在相同容量下，HCI 所需的总节点数少于 UCI

   * **现有环境** — 3 台 ESXi 主机很适合映射为一个小型 HCI 集群

   > **推荐答案：** **HCI** 是更合适的选择。小团队可受益于更简单的架构（单一集群类型），均衡扩展与他们适度增长的需求相匹配，更少的节点可降低成本，而且 HCI 与他们现有的 VMware 集群模型非常相似。
2. **确定节点数量和布局**

   画出或描述你 प्रस्ताव的拓扑：

   * 有多少 **控制器节点**？（HA 至少需要 2 个）
   * 你是否需要 **横向扩展节点**？（请考虑：2 个节点承载 50 台 VM 可能较紧张；2 个横向扩展节点可提供余量）
   * 有多少 **会创建集群**？（HCI 需要 1 个）
   * 那么 **存储容量**？（10 TB 可用容量意味着在节点间复制后约需 20 TB 原始容量）

   一个合理的设计：

   ```mermaid
   graph TB
       subgraph "Cluster 1（HCI）"
           N1["节点 1 — 控制器<br/>存储 + 计算"]
           N2["节点 2 — 控制器<br/>存储 + 计算"]
           N3["节点 3 — 横向扩展<br/>存储 + 计算"]
           N4["节点 4 — 横向扩展<br/>存储 + 计算"]
       end
       CF["核心 fabric（双交换机）"]
       EXT["外部网络"]
       N1 --- CF
       N2 --- CF
       N3 --- CF
       N4 --- CF
       N1 --- EXT
       N2 --- EXT
       N3 --- EXT
       N4 --- EXT
   ```
3. **对应到一个 playground 示例**

   哪个 Terraform playground 示例文件与你的设计最相符？

   > **答案：** **`examples/4-node-hci.tfvars`** ——2 个控制器 + 2 个横向扩展节点，组成单个 HCI 集群。这与推荐的 4 节点 HCI 设计相匹配，可实现计算和存储的均衡扩展。

***

## 第 3 部分：拓扑比较

比较全部四个示例 `.tfvars` 来自 `examples/` 目录中的文件。请填写下面的比较表。

### 说明

打开每个文件并找出配置值。使用表格记录你的发现。

{% tabs %}
{% tab title="2-node-hci.tfvars" %}
**文件：** `examples/2-node-hci.tfvars`

* **场景：** 2 节点 HCI（单集群）
* **总节点数：** 2
* **集群：** 1
* **节点类型：** 2 个控制器（存储 + 计算）
* **开关变量：** 无（全部为默认值）
* **控制器上的 tier-1 磁盘：** 是（2 × 1000 GB）
* **适用于：** 基础测试、评估、最小可行部署
  {% endtab %}

{% tab title="4-node-hci.tfvars" %}
**文件：** `examples/4-node-hci.tfvars`

* **场景：** HCI + 横向扩展（单集群）
* **总节点数：** 4
* **集群：** 1
* **节点类型：** 2 个控制器 + 2 个横向扩展节点
* **开关变量：** `create_scale_out_nodes = true`
* **控制器上的 tier-1 磁盘：** 是（2 × 1000 GB）
* **适用于：** 更大的 HCI 集群、测试横向扩展行为、均衡增长
  {% endtab %}

{% tab title="4-node-hybrid.tfvars" %}
**文件：** `examples/4-node-hybrid-hci-2-cluster.tfvars`

* **场景：** 混合 HCI（2 个集群）
* **总节点数：** 4
* **集群：** 2
* **节点类型：** 2 个控制器（存储 + 计算）+ 2 个仅计算节点
* **开关变量：** `create_compute_nodes = true`
* **控制器上的 tier-1 磁盘：** 是（控制器提供全部存储）
* **适用于：** 将计算扩展与存储分离，增加计算突发容量
  {% endtab %}

{% tab title="6-node-uci.tfvars" %}
**文件：** `examples/6-node-uci-3-cluster.tfvars`

* **场景：** UCI（3 个集群）
* **总节点数：** 6
* **集群：** 3
* **节点类型：** 2 个控制器 + 2 个仅存储节点 + 2 个仅计算节点
* **开关变量：** `create_storage_nodes = true`, `create_compute_nodes = true`
* **控制器上的 tier-1 磁盘：** 否（存储节点提供全部 tier-1 容量）
* **适用于：** 类生产环境的 UCI、存储和计算独立扩展、更大的环境
  {% endtab %}
  {% endtabs %}

### 比较汇总表

在查看每个文件时完成此表：

| 属性                    | 2 节点 HCI  | 4 节点 HCI  | 混合 2 集群 | UCI 3 集群  |
| --------------------- | --------- | --------- | ------- | --------- |
| **总节点数**              | 2         | 4         | 4       | 6         |
| **集群**                | 1         | 1         | 2       | 3         |
| **控制器节点**             | 2         | 2         | 2       | 2         |
| **横向扩展节点**            | 0         | 2         | 0       | 0         |
| **仅存储节点**             | 0         | 0         | 0       | 2         |
| **仅计算节点**             | 0         | 0         | 2       | 2         |
| **控制器是否有 tier-1 磁盘？** | 是         | 是         | 是       | 否         |
| **存储扩展**              | 添加 HCI 节点 | 添加 HCI 节点 | 添加控制器   | 添加存储节点    |
| **计算扩展**              | 添加 HCI 节点 | 添加 HCI 节点 | 添加计算节点  | 添加计算节点    |
| **复杂度**               | 低         | 低         | 中       | 高         |
| **理想使用场景**            | 小型 / 评估   | 中等规模、均衡   | 计算突发    | 大型 / 独立扩展 |

### 分析问题

完成表格后，请思考以下问题：

1. **为什么 UCI 场景中的控制器没有 tier-1 磁盘？**

   > 在 UCI 中，专用存储节点提供所有工作负载存储。控制器只需要 tier-0 磁盘用于 vSAN 元数据。这在 `main.tf` 其中 `quantity_tier_1_disks` 在……时会有条件地设置为 0 `create_storage_nodes = true`.
2. **当存储和计算节点都启用时，依赖链是什么？**

   > 控制器 → 存储节点 → 计算节点。计算模块具有显式的 `depends_on` 对存储模块的依赖，确保在计算节点尝试加入之前存储集群已存在。这反映了 VergeOS 集群创建的工作方式：在计算工作负载运行之前，必须先提供存储。
3. **你会如何修改 4 节点 HCI 示例以支持 6 个 HCI 节点？**

   > 将 `quantity_scale_out_nodes` 从 `2` 更改为 `4`。Terraform 模块会按顺序创建额外的横向扩展节点，每个节点加入同一个 HCI 集群。无需额外的开关变量。

***

## 要点总结

完成本实验后，你应能够：

* ✅ 浏览 VergeOS Terraform playground 并理解其结构
* ✅ 识别 core fabric 网络、vSAN 存储层和节点类型如何在 Terraform 中表达
* ✅ 解释四种部署场景之间的差异（2 节点 HCI、4 节点 HCI、混合 2 集群、UCI 3 集群）
* ✅ 针对给定客户场景推荐合适的 VergeOS 拓扑
* ✅ 跟踪从控制器到可选节点类型的依赖链

## 下一步

继续到 [**第 2 模块：容量规划与设计**](/learn-the-platform/zh/di-2-mo-kuai-rong-liang-gui-hua-yu-she-ji/02-sizing-design.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/lab.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.