> 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-2-dinh-co-and-thiet-ke/03-customer-scoping.md).

# Xác định phạm vi khách hàng

Một triển khai VergeOS được xác định phạm vi tốt bắt đầu từ rất lâu trước khi node đầu tiên được lắp vào rack. Trang này cung cấp một phương pháp có cấu trúc để thu thập yêu cầu của khách hàng, chuyển các workload thành ước tính tài nguyên VergeOS, lập kế hoạch cấu hình node của tenant và chọn topology triển khai phù hợp. Đến cuối quy trình này, bạn sẽ có một bộ tài liệu bàn giao hoàn chỉnh mà bất kỳ kỹ sư VergeOS nào cũng có thể dùng để thực hiện cài đặt.

## Danh sách kiểm tra thu thập yêu cầu

Mọi đợt xác định phạm vi nên bắt đầu bằng việc thu thập thông tin sau từ khách hàng. Hãy dùng danh sách này làm hướng dẫn trao đổi trong các buổi khám phá.

### Kiểm kê workload hiện tại

| Điểm dữ liệu                                  | Vì sao điều này quan trọng                                                    |
| --------------------------------------------- | ----------------------------------------------------------------------------- |
| **Tổng số VM**                                | Xác định quy mô của triển khai và ảnh hưởng đến việc chọn kiến trúc           |
| **Số lõi CPU mỗi VM**                         | Dẫn dắt việc xác định quy mô cụm tính toán và nhận diện các ngoại lệ ngốn CPU |
| **Phân bổ RAM mỗi VM**                        | RAM thường là tài nguyên giới hạn; quyết định số node                         |
| **Lưu trữ mỗi VM (được cấp phát và đã dùng)** | Phân biệt giữa dung lượng cấp phát mỏng và mức tiêu thụ thực tế               |
| **Yêu cầu IOPS/độ trễ lưu trữ**               | Nhận diện các workload cần NVMe so với những workload chấp nhận SAS/SATA SSD  |
| **Nhu cầu GPU hoặc phần cứng chuyên dụng**    | Xác định liệu các cụm tính toán có cần thiết bị passthrough hay không         |
| **Hỗn hợp hệ điều hành**                      | Windows, Linux, BSD — ảnh hưởng đến việc lập kế hoạch driver và tích hợp      |

### Dự báo tăng trưởng

* **Dự báo 6 tháng, 12 tháng và 24 tháng** cho số VM, CPU, RAM và lưu trữ.
* **Mô hình tăng trưởng:** Compute tăng nhanh hơn storage hay tăng tương ứng? Điều này ảnh hưởng trực tiếp đến quyết định HCI so với HCI + Compute so với UCI.
* **Mẫu theo mùa hoặc theo đợt bùng nổ** — các workload có giai đoạn cao điểm có thể cần khoảng dự phòng mà các chỉ số trạng thái ổn định không thể hiện ra.

### Yêu cầu hiệu năng

* **Mục tiêu IOPS** cho từng tầng workload (cơ sở dữ liệu, ứng dụng, dịch vụ tệp).
* **Yêu cầu độ trễ** — dưới mili giây cho cơ sở dữ liệu so với mục đích chung cho máy chủ tệp.
* **Thông lượng** — băng thông đọc/ghi tuần tự cho workload sao lưu, media hoặc phân tích.

### Yêu cầu về tính sẵn sàng & DR

* **RPO (Recovery Point Objective):** Chấp nhận mất bao nhiêu dữ liệu? Ảnh hưởng đến tần suất snapshot và lịch đồng bộ site.
* **RTO (Recovery Time Objective):** Dịch vụ phải được khôi phục nhanh đến mức nào? Ảnh hưởng đến việc tenant cần HA đa node hay đơn node với tự động failover.
* **Kỳ vọng N+1:** Cụm có thể sống sót khi một node đầy đủ bị lỗi mà tất cả workload vẫn chạy không? Điều này liên quan trực tiếp đến quyết định [dự trữ RAM](#ram-reservation-decision) được đề cập sau trên trang này.
* **Yêu cầu site DR:** Khách hàng có cần sao chép đồng bộ site sang một vị trí thứ cấp không?

### Topology mạng & ràng buộc

* **Hạ tầng chuyển mạch hiện có:** Hãng, model, khả năng (MLAG, LACP, BGP).
* **Số NIC khả dụng mỗi node:** 2 so với 4+ sẽ quyết định mô hình thiết kế mạng.
* **Yêu cầu VLAN:** Cần bao nhiêu mạng tách biệt? Các tenant dùng VLAN dùng chung hay riêng?
* **Ràng buộc vật lý:** Toàn bộ phần cứng nằm trong một rack hay nhiều rack? Nhiều site?
* **Độ trễ fabric lõi:** Tất cả node phải nằm trên cùng một switching fabric với số hop switch bằng 0.

### Ngân sách & thời gian

* **Ngân sách phần cứng:** Ảnh hưởng đến việc chọn nhà cung cấp server và số node.
* **Mô hình cấp phép:** Theo node — ảnh hưởng đến chiến lược tối ưu chi phí.
* **Thời gian cài đặt:** Triển khai tiêu chuẩn hay triển khai theo giai đoạn.

***

## Chuyển đổi workload sang tài nguyên

Khi bạn đã có kiểm kê workload của khách hàng, hãy chuyển nó thành yêu cầu tài nguyên VergeOS. VergeOS có **ít overhead hơn** so với các nền tảng truyền thống — không có Controller VM (CVM), không có appliance vCenter và không có mặt phẳng quản trị riêng tiêu tốn tài nguyên.

### Bước 1: Tổng hợp tổng workload

Cộng các yêu cầu workload của khách hàng:

```
Tổng số lõi vCPU  = Σ (lõi mỗi VM)
Tổng RAM (GB)    = Σ (RAM mỗi VM)
Tổng lưu trữ (TB) = Σ (lưu trữ được cấp phát mỗi VM)
```

### Bước 2: Thêm overhead hệ thống VergeOS

Overhead của VergeOS là tối thiểu nhưng vẫn phải được tính đến:

| Tài nguyên                          | Overhead                                                                      |
| ----------------------------------- | ----------------------------------------------------------------------------- |
| **RAM mỗi node vSAN**               | 16 GB cho VergeOS + 1 GB cho mỗi 1 TB dung lượng thô trên node đó (tối thiểu) |
| **RAM mỗi node vSAN (khuyến nghị)** | 16 GB + 1,5 GB cho mỗi 1 TB dung lượng thô                                    |
| **CPU mỗi node lưu trữ**            | 1 lõi cho mỗi đĩa (khuyến nghị)                                               |
| **lưu trữ Tier 0**                  | 5–10 GB cho mỗi 1 TB dung lượng khả dụng (chỉ các node controller)            |
| **Node chỉ tính toán**              | Chỉ 16 GB cho VergeOS; không có overhead lưu trữ                              |

{% hint style="success" %}
**RAM node tenant: không có overhead bổ sung ở lớp host**

Khi bạn gán RAM cho một node tenant, **toàn bộ dung lượng đó** là phần host giữ lại — bạn không **không** cộng overhead riêng ở lớp host cho tenant. Tuy nhiên, bên trong tenant, chính phiên bản VergeOS lồng nhau của nó sẽ tiêu thụ overhead tiêu chuẩn (16 GB + 1 GB cho mỗi 1 TB dung lượng lưu trữ) từ phần cấp phát đó trước khi các VM khách của tenant nhận bộ nhớ.

Vì vậy có hai lớp riêng biệt: ở **host**, hãy đặt kích thước node tenant = lượng RAM bạn muốn tenant có. Bên trong **thuê bao**, hãy lập kế hoạch workload khách dựa trên (RAM được cấp − 16 GB − 1 GB/TB).
{% endhint %}

### Bước 3: Tính khoảng dự phòng HA

Nếu khách hàng yêu cầu tính sẵn sàng N+1 (cụm có thể sống sót khi một node bị lỗi mà tất cả VM vẫn chạy), bạn phải đảm bảo rằng **các node còn lại** có đủ tổng CPU và RAM để hấp thụ workload của node bị lỗi.

**Nguyên tắc kinh nghiệm:** Với cụm N node, mỗi node nên được cấp phát để sử dụng không quá `(N-1)/N` tổng tài nguyên của nó. Ví dụ, trong cụm 4 node, hãy đặt mục tiêu sử dụng 75% mỗi node.

### Bước 4: Tính số node

Chia tổng yêu cầu tài nguyên (bao gồm overhead và khoảng dự phòng HA) cho dung lượng mỗi node để xác định số node tối thiểu. Luôn làm tròn lên và xác thực kết quả với các kiến trúc tham chiếu. Các dải số node dưới đây chỉ là quy tắc kinh nghiệm tổng quát — HCI phù hợp với các triển khai nhỏ hơn (thường 2–12 node), còn UCI áp dụng khi tăng trưởng compute và storage phân kỳ hoặc cần phần cứng chuyên dụng:

* **2–6 node → HCI**
* **6–10 node → HCI + Compute chuyên dụng**
* **10+ node → UCI**

```mermaid
flowchart TD
    A["Tổng hợp workload<br/>CPU + RAM + lưu trữ"] --> B["Thêm overhead VergeOS<br/>16GB + 1GB/TB mỗi node"]
    B --> C["Áp dụng khoảng dự phòng HA<br/>Mục tiêu sử dụng (N-1)/N"]
    C --> D["Chia cho dung lượng mỗi node"]
    D --> E{"Số node?"}
    E -->|"2-6"| HCI["Đề xuất HCI"]
    E -->|"6-10"| HCC["Đề xuất HCI + Compute"]
    E -->|"10+"| UCI["Đề xuất UCI"]

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

***

## Lập kế hoạch node tenant

Đối với các triển khai đa tenant (CSP, MSP hoặc cô lập theo phòng ban nội bộ), mỗi tenant chạy bên trong một Virtual Data Center (VDC) được hỗ trợ bởi một hoặc nhiều **nút tenant**node tenant. Các node tenant là các máy ảo đóng vai trò như node tính toán của phiên bản VergeOS lồng nhau của tenant; lưu trữ được cấp phát từ hạn ngạch tầng lưu trữ của host và mạng thông qua các mạng ảo của tenant.

### Tenant đơn node so với đa node

**tenant đơn node** là điểm khởi đầu mặc định và được ưu tiên:

* Cung cấp dự phòng thông qua tự động failover — nếu host vật lý bị lỗi, node tenant sẽ tự động khởi động lại trên host khác.
* Dễ quản lý và cân chỉnh kích thước hơn.
* Có thể mở rộng theo chiều dọc (thêm core/RAM) mà không gián đoạn.
* Có thể thêm node sau này, không gián đoạn, khi tenant phát triển.

**tenant đa node** được cần đến khi:

1. **Yêu cầu tài nguyên vượt quá giới hạn tối đa của cụm** — `RAM tối đa mỗi máy` và `Số lõi tối đa mỗi máy` các thiết lập của cụm giới hạn kích thước của một node tenant đơn.
2. **Ứng dụng theo cụm** cần workload nằm trên các host vật lý khác nhau (ví dụ: primary/replica cơ sở dữ liệu trên các node riêng để HA).
3. **Khả năng phần cứng hỗn hợp** — tenant cần cả compute tiêu chuẩn và các node có GPU, vốn nằm trên các cụm vật lý khác nhau.
4. **Yêu cầu pháp lý** bắt buộc tách biệt phần cứng giữa các loại workload.

### Chiến lược phân bổ đúng quy mô

Tenant VergeOS hỗ trợ **mở rộng không gián đoạn** — bạn có thể thêm tài nguyên vào các node hiện có hoặc thêm node hoàn toàn mới mà không làm gián đoạn workload đang chạy. Cách tiếp cận được khuyến nghị:

1. **Cấp phát cho nhu cầu hiện tại hoặc gần hạn** — không cấp phát quá mức cho tăng trưởng tương lai mang tính suy đoán.
2. **Mở rộng một cách tự nhiên** — tăng tài nguyên node tenant khi nhu cầu xuất hiện.
3. **Tận dụng tối đa các node hiện có trước khi thêm node mới** — sẽ hiệu quả hơn khi nâng một node từ 32 GB lên 64 GB so với việc thêm một node 32 GB thứ hai, trừ khi HA của ứng dụng yêu cầu tách biệt vật lý.

### Cấu hình ví dụ

### Đơn node nhỏ

**Tình huống:** 3 VM, không có yêu cầu đặc biệt, cụm cho phép tối đa 64 GB / 16 core.

**Cấu hình:** 1 node tenant — 16 GB RAM, 8 core.

**Lộ trình mở rộng:** Thêm RAM/core vào node hiện có (tối đa 64 GB / 16 core), sau đó thêm node thứ hai nếu cần.

### HA cỡ trung

**Tình huống:** Farm web với 4 web server + 2 database server yêu cầu tách biệt host vật lý.

**Cấu hình:** 2 node tenant — mỗi node 64 GB RAM, 12 core. Nhóm HA thực thi anti-affinity để các instance web/database chạy trên các host vật lý khác nhau.

**Lộ trình mở rộng:** Tăng tài nguyên node hoặc thêm node thứ ba để phân phối workload thêm nữa.

### Workload hỗn hợp với GPU

**Tình huống:** VM tiêu chuẩn + render video tăng tốc bằng GPU trên các cụm phần cứng khác nhau.

**Cấu hình:** 4 node tenant — 2 trên cụm tiêu chuẩn (mỗi node 64 GB), 1 trên cụm vGPU (64 GB), 1 trên cụm hiệu năng cao (48 GB).

**Lộ trình mở rộng:** Mở rộng từng node độc lập dựa trên khả năng của cụm và nhu cầu workload.

### Phân tán doanh nghiệp

**Tình huống:** Nền tảng phân tích phân tán yêu cầu 3 server ứng dụng trên các host vật lý riêng biệt + các node xử lý dữ liệu.

**Cấu hình:** 4 node tenant — 3 × 64 GB / 12 core (ứng dụng + cơ sở dữ liệu mỗi node với anti-affinity của Group HA) + 1 × 32 GB / 8 core (xử lý dữ liệu).

**Lộ trình mở rộng:** Thêm tài nguyên vào các node hiện có hoặc thêm node để tách biệt vật lý thêm nữa.

***

## Khung ra quyết định chọn topology

Sau khi đã thu thập yêu cầu workload và chuyển đổi tài nguyên xong, hãy dùng các tiêu chí sau để đưa ra khuyến nghị kiến trúc:

| Tiêu chí quyết định           | HCI                                 | HCI + Tính toán                    | UCI                                             |
| ----------------------------- | ----------------------------------- | ---------------------------------- | ----------------------------------------------- |
| **Số lượng nút**              | 2–6                                 | 6–10                               | 10+                                             |
| **Mẫu tăng trưởng**           | Tỷ lệ tương ứng (compute ≈ storage) | Compute > storage                  | Cả hai (hoàn toàn độc lập)                      |
| **Chuyên biệt hóa**           | Không cần                           | Một phần (GPU trong cụm compute)   | Toàn phần (GPU, nhiều RAM, lưu trữ dày đặc)     |
| **Mức chấp nhận độ phức tạp** | Nhân sự IT tối thiểu                | Trung bình                         | Đội hạ tầng chuyên trách                        |
| **Ngân sách**                 | Tiết kiệm chi phí nhất              | Trung bình                         | Cao nhất (nhưng hiệu quả nhất ở quy mô lớn)     |
| **Cô lập hiệu năng**          | Chấp nhận tranh chấp tài nguyên     | Compute tách biệt khỏi I/O lưu trữ | Tối đa — mỗi vai trò trên phần cứng chuyên dụng |

### Danh sách kiểm tra ra quyết định

1. **Số node có dưới 6 không?** → Bắt đầu với HCI trừ khi có lý do cụ thể để tách compute.
2. **Compute tăng nhanh hơn storage không?** → HCI + Compute cho phép bạn thêm các node chỉ compute với chi phí thấp.
3. **Có nhu cầu GPU, nhiều RAM, hoặc phần cứng chuyên dụng khác không?** → UCI cho phép có các cụm compute chuyên dụng theo từng loại phần cứng.
4. **Khách hàng có cần mở rộng storage độc lập không?** → UCI là mô hình duy nhất có cụm storage chuyên dụng.
5. **Đơn giản vận hành có phải ưu tiên hàng đầu không?** → HCI có overhead quản trị thấp nhất.
6. **Môi trường có thể tiến hóa theo thời gian không?** → Luôn có. VergeOS hỗ trợ chuyển từ HCI → HCI + Compute → UCI bằng cách thêm cụm vào hệ thống hiện có.

***

## Quyết định dự trữ RAM

Trong quá trình cài đặt, kỹ sư phải quyết định ưu tiên dự trữ RAM. Đây là sự đánh đổi giữa **bộ nhớ sử dụng được** và **thực thi HA N+1**:

| Tùy chọn                      | Hành vi                                                                                                                                               | Phù hợp nhất cho                                                                                                              |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Nhiều bộ nhớ khả dụng hơn** | Hệ thống cho phép VM sử dụng nhiều hơn RAM khả dụng, giảm phần dự trữ tự động cho khoảng dự phòng failover                                            | Các môi trường mà việc tối đa hóa mật độ workload trên mỗi node quan trọng hơn dung lượng failover N+1 được bảo đảm           |
| **Thực thi HA N+1 nhiều hơn** | Hệ thống giữ lại nhiều RAM hơn để đảm bảo rằng nếu một node bị lỗi, các node còn lại có dung lượng được đảm bảo để hấp thụ toàn bộ workload bị dời đi | Các môi trường sản xuất có SLA thời gian hoạt động nghiêm ngặt, trong đó failover được bảo đảm là điều không thể thương lượng |

{% hint style="warning" %}
Quyết định này nên được đưa ra **trước khi** vào ngày cài đặt. Hãy thảo luận sự đánh đổi với khách hàng trong giai đoạn xác định phạm vi và ghi lại ưu tiên đã chọn trong kế hoạch cài đặt.
{% endhint %}

***

## Các tài liệu bàn giao

Một đợt xác định phạm vi hoàn chỉnh nên tạo ra bộ tài liệu sau, sẵn sàng cho kỹ sư cài đặt:

### 1. Tài liệu thiết kế mạng

* **Sơ đồ thiết kế Layer 2** — switch vật lý, VLAN, gán cổng, cấu hình MLAG/stacking.
* **Sơ đồ thiết kế Layer 3** — subnet, gateway, định tuyến (BGP/OSPF nếu áp dụng), server DNS.
* **Sơ đồ cáp A-B** — mọi sợi cáp từ mọi node đến mọi switch, được gắn nhãn bằng định danh cổng.
* **Cấu hình core fabric** — VLAN dành riêng cho Core 1 và Core 2, xác nhận MTU 9216+, xác minh không có switch hop nào.

### 2. Bố trí rack

* Vị trí vật lý của từng node, switch, PDU và quản lý cáp.
* Phân bổ mạch điện và bản đồ dự phòng.

### 3. Kế hoạch phân bổ IP

| Mạng                         | Địa chỉ             | Mục đích                                                                                                                              |
| ---------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Quản lý/Giao diện người dùng | `10.x.x.2/24`       | Giao diện web và API của VergeOS                                                                                                      |
| Cổng                         | `10.x.x.1`          | Gateway mặc định cho lưu lượng bên ngoài                                                                                              |
| Fabric lõi 1                 | VLAN 900            | VLAN truy cập không gắn thẻ được tạo trên switch; IP của node được VergeOS tự động gán. Lưu lượng lưu trữ và điều khiển giữa các node |
| Fabric lõi 2                 | VLAN 901            | VLAN truy cập không gắn thẻ được tạo trên switch; IP của node được VergeOS tự động gán. Lưu lượng dự phòng giữa các node              |
| IPMI                         | `192.168.x.0/24`    | Quản trị ngoài băng                                                                                                                   |
| Mạng tenant                  | Phân bổ theo tenant | Các subnet dành riêng cho khách hàng                                                                                                  |

### 4. Danh mục vật tư phần cứng

* Model server, CPU, RAM, cấu hình đĩa cho mỗi node.
* Loại NIC và tốc độ.
* Model switch và số lượng cổng.
* Thông số NVMe Tier 0 (DWPD, dung lượng trên mỗi TB lưu trữ khả dụng).

### 5. Kế hoạch cài đặt

* Kiến trúc tham chiếu đã chọn (HCI, HCI + Compute, hoặc UCI).
* Phân bổ tầng đĩa cho mỗi node.
* Ưu tiên dự trữ RAM (bộ nhớ sử dụng được so với thực thi N+1).
* Quyết định mã hóa (mã hóa khi lưu trữ có/không, kế hoạch lưu trữ khóa).
* Cấu hình server NTP.
* Kế hoạch thông tin đăng nhập quản trị (tham chiếu kho mật khẩu).

***

{% hint style="info" %}
**Bạn đang chuyển từ VMware hay Nutanix?**

Xác định phạm vi VergeOS là một lần xác định kích thước duy nhất: overhead hệ điều hành cố định 16 GB mỗi node cộng 1 GB cho mỗi TB dung lượng thô. Không có CVM, không có appliance quản trị riêng và không có bài toán cấp phép theo từng tính năng — compute, storage, mạng và đa tenant đều được tính kích thước cùng nhau như một nền tảng duy nhất.
{% endhint %}

***

## Tóm tắt

| Giai đoạn                 | Đầu ra                                                                                                        |
| ------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Thu thập yêu cầu**      | Danh sách kiểm tra đã hoàn tất với kiểm kê workload, dự báo tăng trưởng, mục tiêu hiệu năng và ràng buộc mạng |
| **Chuyển đổi tài nguyên** | Tổng CPU, RAM và lưu trữ với overhead VergeOS và khoảng dự phòng HA đã áp dụng                                |
| **Lập kế hoạch tenant**   | Quyết định đơn node so với đa node cho từng tenant với các cấu hình ví dụ                                     |
| **Chọn topology**         | Khuyến nghị HCI, HCI + Compute, hoặc UCI cùng với lý do                                                       |
| **Dự trữ RAM**            | Ưu tiên đã được ghi nhận — bộ nhớ sử dụng được so với thực thi N+1                                            |
| **Bộ tài liệu**           | Sơ đồ mạng, bố trí rack, kế hoạch IP, BOM và kế hoạch cài đặt                                                 |

## Các bước tiếp theo

* [**Yêu cầu phần cứng**](/learn-the-platform/vi/mo-dun-2-dinh-co-and-thiet-ke/01-hardware-requirements.md) — Xác minh thông số node của bạn so với yêu cầu tối thiểu và khuyến nghị.
* [**Kiến trúc tham chiếu**](/learn-the-platform/vi/mo-dun-2-dinh-co-and-thiet-ke/02-reference-architectures.md) — Xem lại các sơ đồ topology chi tiết cho kiến trúc bạn đã chọn.
* [**Mô-đun 3: Cài đặt**](/learn-the-platform/vi/mo-dun-3-cai-dat/03-installation.md) — Tiến hành chuẩn bị và triển khai cài đặt.


---

# 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-2-dinh-co-and-thiet-ke/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.