> 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/vi/mo-dun-1-kien-thuc-co-ban-ve-kien-truc/lab.md).
# Thực hành: Khám phá kiến trúc
## Tổng quan bài thực hành
Trong bài thực hành này, bạn sẽ khám phá **VergeOS Terraform Playground** — một dự án mã nguồn mở triển khai các hệ thống VergeOS ảo bằng Terraform. Bằng cách đọc mã nguồn và tài liệu, bạn sẽ củng cố các khái niệm kiến trúc được đề cập trong mô-đun này: mạng core fabric, các tầng lưu trữ vSAN, tổ chức cụm, và các kiến trúc HCI so với UCI.
### Bạn sẽ thực hiện gì
* **Phần 1** — Đọc tài liệu kiến trúc của playground và mã Terraform để xác định cách các khái niệm VergeOS được ánh xạ sang hạ tầng dưới dạng mã
* **Phần 2** — Dựa trên một kịch bản khách hàng, hãy đề xuất và vẽ sơ đồ một kiến trúc triển khai
* **Phần 3** — So sánh bốn cấu hình triển khai ví dụ và phân tích sự khác nhau của chúng
### Yêu cầu tiên quyết
* Một tài khoản GitHub (để clone kho lưu trữ)
* Git đã được cài đặt trên máy trạm của bạn
* Một trình soạn thảo văn bản hoặc IDE (khuyến nghị VS Code)
* Không cần quyền truy cập hệ thống VergeOS — bài thực hành này là một bài tập đọc hiểu và thiết kế
### Thời gian ước tính
**30 phút**
***
## Phần 1: Khám phá kiến trúc
Trong phần này, bạn sẽ clone kho lưu trữ playground Terraform và lần theo cách các khái niệm kiến trúc VergeOS được thể hiện trong hạ tầng dưới dạng mã.
1. **Clone kho lưu trữ**
```bash
git clone https://github.com/verge-io/vergeos-terraform-playground.git
cd vergeos-terraform-playground
```
2. **Đọc tài liệu kiến trúc**
Mở `docs/architecture.md` và đọc toàn bộ tài liệu. Khi đọc, hãy xác định câu trả lời cho các câu hỏi sau:
* Các **bốn kịch bản triển khai** được playground hỗ trợ?
* Một **tệp seed cài đặt** và nó cho phép cài đặt tự động không giám sát như thế nào?
* Cái **triển khai tối thiểu** kích thước?
> **Gợi ý:** Bốn kịch bản được liệt kê trong `docs/deployment-scenarios.md` kèm sơ đồ kiến trúc. Triển khai tối thiểu là hai node bộ điều khiển tạo thành một cụm HCI duy nhất.
3. **Xem các sơ đồ kịch bản triển khai**
Mở `docs/deployment-scenarios.md` và nghiên cứu các sơ đồ kiến trúc Mermaid cho từng kịch bản. Với mỗi kịch bản, hãy ghi lại:
* Có bao nhiêu **node** tham gia
* Có bao nhiêu **cụm** được tạo
* Những **loại node** xuất hiện (controller, scale-out, storage, compute)
* Cách tất cả các node kết nối với **core fabric** và **mạng ngoài**
4. **Lần theo core fabric trong Terraform**
Mở `main.tf` (module gốc) và tìm hai tài nguyên mạng core fabric. Trả lời các câu hỏi sau:
* Các tài nguyên được đặt tên là gì? (`core_fabric_1` và `core_fabric_2`)
* Cái gì **MTU** được cấu hình? (9142 — khung jumbo cho sao chép vSAN)
* DHCP có được bật trên các mạng này không? (Không — `dhcp_enabled = false`)
* Cái gì `loại địa chỉ IP` được đặt? (`không có` — đây là các đường truyền Layer 2)
```hcl
# Bạn sẽ tìm thấy các tài nguyên như sau trong 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. **Xem Node 1 khác Node 2 như thế nào**
Mở `modules/controllers/main.tf` và so sánh `verge_node_1` và `verge_node_2`. Các khác biệt chính cần xác định:
* **Mẫu Cloud-init** — Node 1 sử dụng `user-data-node1.yaml` (tạo một hệ thống mới với `YC_VSAN_NEW=1`). Node 2 sử dụng `user-data-node2.yaml` (tham gia vào hệ thống hiện có với `YC_VSAN_NEW=0`).
* **Thiết lập API sau cài đặt** — cloud-init của Node 1 bao gồm một script cấu hình nguồn cập nhật, bật SSH, và tùy chọn tạo các cụm lưu trữ/tính toán qua API VergeOS. Node 2 không có script sau cài đặt.
* **Chuỗi phụ thuộc** — Node 2 có một `depends_on` tham chiếu tới Node 1, đảm bảo hệ thống được khởi tạo đầy đủ trước khi bộ điều khiển thứ hai cố gắng tham gia.
Cả hai node dùng chung cùng một cấu trúc VM: họ Linux OS, bật ảo hóa lồng nhau, ba NIC virtio (external, core fabric 1, core fabric 2), CD-ROM chứa ISO VergeOS, và một datasource cloud-init nocloud.
6. **Trả lời các câu hỏi hiểu bài**
Hãy viết câu trả lời cho các câu sau (hoặc thảo luận với bạn học của bạn):
| # | Câu hỏi | Câu trả lời mong đợi |
| - | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| 1 | Tại sao core fabric sử dụng hai switch riêng biệt? | Dự phòng — nếu một switch hoặc một đường truyền bị lỗi, đường còn lại vẫn duy trì kết nối giữa các node |
| 2 | Tại sao DHCP bị tắt trên các mạng core fabric? | Core fabric sử dụng địa chỉ IP tĩnh; trình cài đặt VergeOS cấu hình địa chỉ thông qua install seed |
| 3 | Tại sao Node 2 phải đợi Node 1 hoàn tất trước khi bắt đầu? | Node 1 tạo ra hệ thống VergeOS; Node 2 cần một hệ thống hiện có để tham gia |
| 4 | Những loại lưu lượng nào đi qua core fabric? | sao chép vSAN, điều phối cụm, di chuyển nóng VM, giao tiếp control plane |
| 5 | Tại sao `quantity_tier_1_disks` được đặt thành 0 cho các controller khi các node lưu trữ được bật? | Ở chế độ UCI, các node lưu trữ chuyên dụng cung cấp toàn bộ dung lượng tầng 1; các controller chỉ cần tầng 0 cho metadata |
***
## Phần 2: Bài tập thiết kế
Bây giờ hãy áp dụng những gì bạn đã học. Dựa trên một kịch bản khách hàng, hãy đề xuất một kiến trúc triển khai và biện minh cho quyết định của bạn.
### Kịch bản khách hàng
> **Midwest Manufacturing Co.** đang chuyển đổi từ môi trường VMware vSphere với 3 host ESXi. Hiện họ chạy 50 VM (kết hợp Windows và Linux), có khoảng 10 TB dung lượng lưu trữ khả dụng, và dự kiến tăng trưởng ở mức vừa phải trong 2 năm tới. Họ có một đội IT nhỏ (2 người) và muốn giảm thiểu độ phức tạp vận hành. Ngân sách bị hạn chế.
1. **Chọn HCI hoặc UCI**
Dựa trên hồ sơ khách hàng, bạn khuyến nghị mô hình triển khai nào? Hãy cân nhắc:
* **Quy mô đội ngũ** — Một đội IT 2 người ưu tiên sự đơn giản
* **Mẫu tăng trưởng** — "Tăng trưởng vừa phải" gợi ý khả năng mở rộng cân bằng giữa compute/lưu trữ
* **Ngân sách** — HCI cần ít node tổng cộng hơn UCI cho cùng dung lượng
* **Môi trường hiện tại** — 3 host ESXi phù hợp với một cụm HCI nhỏ
> **Câu trả lời đề xuất:** **HCI** là lựa chọn phù hợp hơn. Đội ngũ nhỏ được hưởng lợi từ kiến trúc đơn giản hơn (một loại cụm duy nhất), khả năng mở rộng cân bằng phù hợp với tăng trưởng vừa phải của họ, ít node hơn giúp giảm chi phí, và HCI gần giống với mô hình cụm VMware hiện có của họ.
2. **Xác định số lượng node và bố cục**
Phác thảo hoặc mô tả kiến trúc đề xuất của bạn:
* Có bao nhiêu **nút điều khiển**? (Tối thiểu 2 cho HA)
* Bạn có cần **các nút mở rộng ngang**? (Xem xét: 50 VM trên 2 node có thể khá chật; 2 node scale-out sẽ tạo thêm dư địa)
* Có bao nhiêu **cụm**? (1 cho HCI)
* Còn về **dung lượng lưu trữ**? (10 TB khả dụng nghĩa là khoảng 20 TB thô với sao chép giữa các node)
Một thiết kế hợp lý:
```mermaid
graph TB
subgraph "Cụm 1 (HCI)"
N1["Node 1 — Bộ điều khiển
Lưu trữ + Tính toán"]
N2["Node 2 — Bộ điều khiển
Lưu trữ + Tính toán"]
N3["Node 3 — Scale-out
Lưu trữ + Tính toán"]
N4["Node 4 — Scale-out
Lưu trữ + Tính toán"]
end
CF["Core Fabric (hai switch)"]
EXT["Mạng ngoài"]
N1 --- CF
N2 --- CF
N3 --- CF
N4 --- CF
N1 --- EXT
N2 --- EXT
N3 --- EXT
N4 --- EXT
```
3. **Ánh xạ sang một ví dụ của playground**
Tệp ví dụ nào của playground Terraform khớp nhất với thiết kế của bạn?
> **Trả lời:** **`examples/4-node-hci.tfvars`** — 2 bộ điều khiển + 2 node scale-out trong một cụm HCI duy nhất. Điều này khớp với thiết kế HCI 4 node được khuyến nghị cho việc mở rộng compute và lưu trữ cân bằng.
***
## Phần 3: So sánh kiến trúc
So sánh cả bốn `.tfvars` tệp từ `examples/` thư mục. Điền vào bảng so sánh bên dưới.
### Hướng dẫn
Mở từng tệp và xác định các giá trị cấu hình. Dùng bảng để ghi lại kết quả.
{% tabs %}
{% tab title="2-node-hci.tfvars" %}
**Tệp:** `examples/2-node-hci.tfvars`
* **Tình huống:** HCI 2 node (Một cụm)
* **Tổng số node:** 2
* **Cụm:** 1
* **Loại node:** 2 bộ điều khiển (lưu trữ + tính toán)
* **Biến bật/tắt:** Không có (tất cả mặc định)
* **Đĩa tầng 1 trên controller:** Có (mỗi cái 2 × 1000 GB)
* **Phù hợp nhất cho:** Kiểm thử cơ bản, đánh giá, triển khai nhỏ nhất có thể
{% endtab %}
{% tab title="4-node-hci.tfvars" %}
**Tệp:** `examples/4-node-hci.tfvars`
* **Tình huống:** HCI + Scale-Out (Một cụm)
* **Tổng số node:** 4
* **Cụm:** 1
* **Loại node:** 2 bộ điều khiển + 2 scale-out
* **Biến bật/tắt:** `create_scale_out_nodes = true`
* **Đĩa tầng 1 trên controller:** Có (mỗi cái 2 × 1000 GB)
* **Phù hợp nhất cho:** Các cụm HCI lớn hơn, thử nghiệm hành vi scale-out, tăng trưởng cân bằng
{% endtab %}
{% tab title="4-node-hybrid.tfvars" %}
**Tệp:** `examples/4-node-hybrid-hci-2-cluster.tfvars`
* **Tình huống:** HCI lai (2 cụm)
* **Tổng số node:** 4
* **Cụm:** 2
* **Loại node:** 2 bộ điều khiển (lưu trữ + tính toán) + 2 chỉ tính toán
* **Biến bật/tắt:** `create_compute_nodes = true`
* **Đĩa tầng 1 trên controller:** Có (controller cung cấp toàn bộ lưu trữ)
* **Phù hợp nhất cho:** Tách mở rộng compute khỏi lưu trữ, bổ sung năng lực tăng đột biến cho compute
{% endtab %}
{% tab title="6-node-uci.tfvars" %}
**Tệp:** `examples/6-node-uci-3-cluster.tfvars`
* **Tình huống:** UCI (3 cụm)
* **Tổng số node:** 6
* **Cụm:** 3
* **Loại node:** 2 bộ điều khiển + 2 chỉ lưu trữ + 2 chỉ tính toán
* **Biến bật/tắt:** `create_storage_nodes = true`, `create_compute_nodes = true`
* **Đĩa tầng 1 trên controller:** Không (các node lưu trữ cung cấp toàn bộ dung lượng tầng 1)
* **Phù hợp nhất cho:** UCI giống môi trường sản xuất, mở rộng độc lập storage và compute, môi trường lớn hơn
{% endtab %}
{% endtabs %}
### Bảng tóm tắt so sánh
Hoàn thành bảng này khi bạn xem từng tệp:
| Thuộc tính | HCI 2 nút | HCI 4 node | Lai 2 cụm | UCI 3 cụm |
| ----------------------------------- | -------------- | ------------------ | ------------------ | --------------------- |
| **Tổng số node** | 2 | 4 | 4 | 6 |
| **Cụm** | 1 | 1 | 2 | 3 |
| **Các nút điều khiển** | 2 | 2 | 2 | 2 |
| **Node scale-out** | 0 | 2 | 0 | 0 |
| **Node chỉ lưu trữ** | 0 | 0 | 0 | 2 |
| **Node chỉ tính toán** | 0 | 0 | 2 | 2 |
| **Controller có đĩa tầng 1 không?** | Có | Có | Có | Không |
| **Mở rộng lưu trữ** | Thêm node HCI | Thêm node HCI | Thêm bộ điều khiển | Thêm node lưu trữ |
| **Mở rộng compute** | Thêm node HCI | Thêm node HCI | Thêm node compute | Thêm node compute |
| **Độ phức tạp** | Thấp | Thấp | Trung bình | Cao |
| **Trường hợp sử dụng lý tưởng** | Nhỏ / đánh giá | Cỡ trung, cân bằng | Bùng nổ compute | Lớn / mở rộng độc lập |
### Câu hỏi phân tích
Sau khi hoàn thành bảng, hãy xem xét các câu hỏi sau:
1. **Tại sao các controller trong kịch bản UCI lại có 0 đĩa tầng 1?**
> Trong UCI, các node lưu trữ chuyên dụng cung cấp toàn bộ lưu trữ cho khối lượng công việc. Các controller chỉ cần đĩa tầng 0 cho metadata vSAN. Điều này thể hiện trong `main.tf` nơi `quantity_tier_1_disks` được đặt có điều kiện thành 0 khi `create_storage_nodes = true`.
2. **Chuỗi phụ thuộc là gì khi cả node lưu trữ và node compute đều được bật?**
> Controller → Node lưu trữ → Node compute. Mô-đun compute có một `depends_on` tham chiếu rõ ràng tới mô-đun lưu trữ, đảm bảo cụm lưu trữ tồn tại trước khi các node compute cố gắng tham gia. Điều này phản ánh cách VergeOS tạo cụm hoạt động: phải có lưu trữ sẵn trước khi khối lượng công việc compute có thể chạy.
3. **Bạn sẽ sửa ví dụ HCI 4 node như thế nào để hỗ trợ 6 node HCI?**
> Đổi `quantity_scale_out_nodes` từ `2` thành `4`. Mô-đun Terraform tạo thêm các node scale-out tuần tự, mỗi node tham gia cùng một cụm HCI. Không cần thêm biến bật/tắt nào khác.
***
## Điểm chính
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
* ✅ Điều hướng playground Terraform VergeOS và hiểu cấu trúc của nó
* ✅ Xác định cách các mạng core fabric, các tầng lưu trữ vSAN và các loại node được biểu diễn trong Terraform
* ✅ Giải thích sự khác nhau giữa bốn kịch bản triển khai (HCI 2 node, HCI 4 node, lai 2 cụm, UCI 3 cụm)
* ✅ Đề xuất một kiến trúc VergeOS phù hợp cho một kịch bản khách hàng cụ thể
* ✅ Lần theo chuỗi phụ thuộc từ controllers qua các loại node tùy chọn
## Các bước tiếp theo
Chuyển đến [**Mô-đun 2: Định cỡ & Thiết kế**](/learn-the-platform/vi/mo-dun-2-dinh-co-and-thiet-ke/02-sizing-design.md) để học cách chuyển đổi yêu cầu khách hàng thành các cấu hình phần cứng và kế hoạch triển khai cụ thể.
---
# 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/vi/mo-dun-1-kien-thuc-co-ban-ve-kien-truc/lab.md?ask=&goal=
```
`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.