> 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/02-reference-architectures.md). # Kiến trúc tham chiếu VergeOS hỗ trợ ba kiến trúc triển khai từ cùng một lần cài đặt phần mềm. Việc chọn kiến trúc phù hợp phụ thuộc vào số lượng node, mô hình tăng trưởng và yêu cầu chuyên biệt hóa khối lượng công việc. Trang này sẽ lần lượt trình bày từng mô hình, cung cấp khung ra quyết định và đề cập đến hai tình huống thực tế phổ biến: triển khai ở biên và môi trường đa thuê bao của nhà cung cấp dịch vụ đám mây (CSP). ## Cây quyết định kiến trúc Sử dụng khung sau để định hướng đề xuất của bạn. Các dải số lượng node bên dưới là quy tắc kinh nghiệm mang tính khái 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 không còn song hành hoặc khi cần phần cứng chuyên dụng. ```mermaid flowchart TD A["Triển khai sẽ có
bao nhiêu node?"] --> B{"2 -- 6 node"} A --> C{"6 -- 10 node"} A --> D{"10+ node"} B --> E{"Compute và storage
có tăng trưởng tương ứng không?"} E -->|"Có"| F["HCI"] E -->|"Không -- compute tăng nhanh hơn"| G["HCI + Compute chuyên dụng
(UCI lai 2 cluster)"] E -->|"Không chắc"| H{"Có cần phần cứng
chuyên dụng không? (GPU, RAM cao)"} C --> H D --> I["UCI (Canonical 3-Cluster)"] H -->|"Có"| I H -->|"Không"| G H -->|"Có thể trong tương lai"| G style F fill:#e8f5e9,stroke:#2e7d32 style G fill:#fff3e0,stroke:#e65100 style I fill:#f0f4ff,stroke:#336 ``` **Một vài quy tắc nhanh:** 1. **Hãy bắt đầu với HCI** trừ khi bạn có lý do cụ thể để không làm vậy. 2. **Cân nhắc HCI + Compute** khi nhu cầu compute tăng nhanh hơn tăng trưởng storage (6--10 node). 3. **Chọn UCI** cho môi trường 10+ node, phần cứng chuyên dụng, hoặc khi cần cô lập hiệu năng tối đa. 4. Bạn có thể **tiến hóa** từ HCI sang HCI + Compute rồi đến UCI khi môi trường phát triển -- cùng một bản cài đặt VergeOS hỗ trợ cả ba. *** ## Mô hình 1: HCI (Hạ tầng siêu hội tụ) **Dải node:** 2--6 node | **Cụm:** 1 Trong một triển khai HCI, mỗi node đều đóng góp **cả** compute và storage. Hai node controller đảm nhiệm storage Tier 0 (metadata vSAN) cùng Tier 1 (workload) và chạy VM. Các node scale-out bổ sung năng lực storage Tier 1 và compute cho cùng một cluster. ```mermaid graph TB subgraph cluster1["Cluster 1 -- HCI"] N1["Node 1 -- Controller
Tier 0 + Tier 1
Storage + Compute"] N2["Node 2 -- Controller
Tier 0 + Tier 1
Storage + Compute"] S1["Node 3 -- Scale-out
Tier 1
Storage + Compute"] S2["Node 4 -- Scale-out
Tier 1
Storage + Compute"] end subgraph fabric["Core Fabric"] CF["Core 1 + Core 2"] end N1 --- CF N2 --- CF S1 --- CF S2 --- CF style cluster1 fill:#e8f5e9,stroke:#2e7d32 style fabric fill:#f0f4ff,stroke:#336 ``` ### Ưu điểm * **Đơn giản trong vận hành** -- chỉ một cluster, một cấu hình phần cứng, quản lý hợp nhất. * **Mở rộng có thể dự đoán** -- mỗi node đều tăng storage và compute theo tỷ lệ tương ứng. * **Điểm khởi đầu thấp nhất** -- cluster 2 node là triển khai VergeOS nhỏ nhất có thể. * **Một cấu hình phần cứng duy nhất** giúp đơn giản hóa mua sắm và tồn kho phụ tùng. ### Hạn chế * Không thể mở rộng compute độc lập với storage (hoặc ngược lại). * Hạn chế chuyên biệt hóa phần cứng -- tất cả node chia sẻ cùng một vai trò. * Khuyến nghị tối đa khoảng 6 node trước khi cân nhắc cluster thứ hai. * Có thể xảy ra tranh chấp tài nguyên trên các node controller khi vừa chạy tác vụ metadata vừa chạy workload VM. ### Các trường hợp sử dụng lý tưởng | Tình huống | Vì sao HCI phù hợp | | ------------------------------------- | --------------------------------------------------------- | | Triển khai nhỏ/trung bình (2--6 node) | Tối giản độ phức tạp, mỗi node kiêm hai nhiệm vụ | | Workload cân bằng | Storage và compute tăng gần như cùng tốc độ | | Edge / site từ xa | Cluster 2 node với HA đầy đủ và footprint nhỏ | | Đánh giá và thử nghiệm | Con đường nhanh nhất để có một hệ thống VergeOS hoạt động | *** ## Mô hình 2: HCI + Compute chuyên dụng (UCI lai 2 cluster) **Dải node:** 6--10 node | **Cụm:** 2 Đây là biến thể UCI lai 2 cluster: vai trò controller và storage vẫn được gộp trong một cluster HCI, trong khi compute được tách sang cluster riêng. Cluster HCI (Cluster 1) cung cấp toàn bộ storage thông qua controller và các node scale-out tùy chọn. Cluster compute (Cluster 2) chạy các workload VM mà không đóng góp bất kỳ ổ đĩa nào. ```mermaid graph TB subgraph cluster1["Cluster 1 -- HCI (Storage + Compute)"] N1["Node 1 -- Controller
Tier 0 + Tier 1"] N2["Node 2 -- Controller
Tier 0 + Tier 1"] S1["Node 3 -- HCI
Tier 1 (tùy chọn)"] end subgraph cluster2["Cluster 2 -- Chỉ Compute"] C1["Node 4 -- Compute"] C2["Node 5 -- Compute"] C3["Node 6 -- Compute"] C4["Node 7+ -- Mở rộng"] end subgraph fabric["Core Fabric"] CF["Core 1 + Core 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 ``` ### Nguyên tắc thiết kế chính ### Cluster 1 -- HCI (Gộp) * Luôn bao gồm Node 1 & 2 với storage Tier 0 (controller). - Có thể thêm các node HCI scale-out để tăng storage và compute. - Một công tắc ở cấp cluster điều khiển việc cluster này có chạy workload VM hay không. - Tất cả các tầng storage đều tồn tại trong cluster này. ### Cluster 2 -- Chỉ Compute * Compute thuần túy -- CPU và RAM tối đa dành cho VM. - Mở rộng độc lập theo nhu cầu compute. - Hỗ trợ phần cứng linh hoạt, tối ưu cho workload (node GPU, node RAM lớn). - I/O storage từ các node compute đi qua core fabric đến Cluster 1. ### Ưu điểm * Mở rộng compute độc lập mà không phải mua thêm storage không cần thiết. * Giữ nguyên sự đơn giản trong vận hành của HCI cho tầng storage. * Hiệu quả về chi phí -- chỉ mở rộng tầng tài nguyên đang tăng trưởng. * Có lộ trình phát triển rõ ràng lên UCI canonical 3 cluster nếu nhu cầu tiếp tục thay đổi. ### Hạn chế * I/O storage từ các node compute đi qua mạng (băng thông core fabric đầy đủ là rất cần thiết). * Phức tạp hơn HCI thuần túy (phải quản lý hai cluster thay vì một). * Cần quyết định xem cluster HCI có nên đồng thời chạy workload hay không. ### Các trường hợp sử dụng lý tưởng | Tình huống | Vì sao HCI + Compute hoạt động tốt | | ------------------------------ | ----------------------------------------------------- | | Triển khai 6--10 node | Điểm cân bằng lý tưởng cho mô hình hai cluster | | Compute tăng nhanh hơn storage | Thêm CPU/RAM mà không mở rộng ổ đĩa | | GPU hoặc compute chuyên dụng | Cluster compute chuyên dụng với phần cứng passthrough | | Tối ưu chi phí | Chỉ mở rộng đúng phần bạn cần | *** ## Mô hình 3: UCI (Hạ tầng siêu hội tụ nâng cao) -- Canonical 3-Cluster **Dải node:** 10+ node | **Cụm:** 3+ Mô hình UCI canonical 3 cluster tách hoàn toàn controller, storage và compute thành các cluster chuyên dụng. Mỗi tầng tài nguyên đều có thể mở rộng độc lập và sử dụng phần cứng được tối ưu cho vai trò của nó. (UCI là thuật ngữ bao trùm cho mọi triển khai có khả năng mở rộng độc lập; Mô hình 2 ở trên là biến thể lai 2 cluster của nó.) ```mermaid graph TB subgraph cluster1["Cluster 1 -- Controller chuyên dụng"] N1["Node 1 -- Controller
Chỉ Tier 0 | RAM cao"] N2["Node 2 -- Controller
Chỉ Tier 0 | RAM cao"] end subgraph cluster2["Cluster 2 -- Storage chuyên dụng"] ST1["Node 3 -- Storage
NVMe mật độ cao | Tier 1"] ST2["Node 4 -- Storage
NVMe mật độ cao | Tier 1"] ST3["Node 5 -- Storage
NVMe mật độ cao | Tier 1"] end subgraph cluster3["Cluster 3+ -- Compute chuyên dụng"] Compute tiêu chuẩn Compute GPU RAM cao end subgraph fabric["Core Fabric"] CF["Core 1 + Core 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 ``` ### Chuyên biệt hóa cluster | Cluster | Vai trò | Tối ưu cho | | ---------------------------- | -------------------------------------- | ------------------------------------------------------------------------ | | **Cluster 1 -- Controllers** | Metadata Tier 0, quản lý cluster | RAM cao (ví dụ 768 GB trong Data-Science RA), NVMe độ bền cao cho Tier 0 | | **Cluster 2 -- Storage** | Toàn bộ storage cho workload (Tier 1+) | Mật độ ổ đĩa tối đa, NVMe hoặc SSD SAS/SATA | | **Cluster 3+ -- Compute** | Workload VM, phần cứng chuyên dụng | Loại node tiêu chuẩn, GPU, RAM cao hoặc tùy chỉnh | ### Ưu điểm * **Hiệu năng tối đa** -- không có tranh chấp tài nguyên giữa storage và compute. * **Mở rộng độc lập hoàn toàn** -- thêm storage mà không thêm compute (hoặc ngược lại). * **Chuyên biệt hóa phần cứng** -- chọn kích cỡ phần cứng phù hợp cho từng vai trò (NVMe mật độ cao cho storage, GPU cho compute). * **Cô lập workload** -- các cluster compute khác nhau cho các loại workload khác nhau. * **Tối ưu cho môi trường quy mô lớn và đa thuê bao.** ### Hạn chế * Độ phức tạp vận hành cao nhất trong cả ba kiến trúc. * Tối thiểu 6 node (suy ra từ mức tối thiểu 2 node mỗi cluster × 3 cluster: 2 controller + 2 storage + 2 compute). * Lập kế hoạch dung lượng phức tạp hơn trên ba loại cluster. * Yêu cầu băng thông core fabric cao hơn giữa các cluster. * Khuyến nghị sử dụng dịch vụ chuyên nghiệp cho triển khai ban đầu. ### Các trường hợp sử dụng lý tưởng | Tình huống | Vì sao UCI hoạt động tốt | | -------------------------------------------------- | ------------------------------------------------------------------ | | Triển khai doanh nghiệp 10+ node | Mở rộng độc lập giúp tránh cấp phát dư thừa | | Workload AI / HPC / GPU | Cluster compute GPU chuyên dụng, tách biệt khỏi storage | | Nhà cung cấp dịch vụ đám mây | Tối ưu chi phí phần cứng theo từng tầng tài nguyên trên các tenant | | Tăng trưởng thiên về storage hoặc thiên về compute | Chỉ mở rộng phần đang tăng trưởng | *** ## So sánh kiến trúc | Khía cạnh | HCI | HCI + Compute (UCI lai 2 cluster) | UCI (Canonical 3-Cluster) | | ---------------------------- | ------------------------ | --------------------------------- | ------------------------------------- | | **Số node tối thiểu** | 2 | 4 (2 HCI + 2 compute) | 6 (2+2+2) | | **Số cluster** | 1 | 2 | 3+ | | **Hiệu năng** | Tốt | Tốt hơn | Tối ưu | | **Tính linh hoạt phần cứng** | Thấp | Trung bình | Tối đa | | **Mở rộng độc lập** | Không | Một phần (chỉ compute) | Hoàn toàn | | **Chuyên biệt hóa** | Không có | Chỉ compute | Đầy đủ (controller, storage, compute) | | **Độ phức tạp** | Thấp | Trung bình | Cao | | **Hiệu quả tài nguyên** | Thay đổi theo tình huống | Tốt | Tối đa | | **Phù hợp nhất** | Nhỏ, cân bằng | Cỡ trung, thiên về compute | Lớn, chuyên biệt | *** ## Các tình huống triển khai ở biên Các cluster edge là những triển khai VergeOS 2 node gọn nhẹ, được thiết kế cho địa điểm từ xa hoặc chi nhánh. Chúng sử dụng phần cứng công suất thấp, kích thước nhỏ và được kết nối trực tiếp (không cần switch cho core fabric). ### Cấu hình edge điển hình * **2 node** kết nối trực tiếp qua dual NICs (core fabric). * Phần cứng kích thước nhỏ (Intel NUC, PC SFF 1L hoặc tương tự). * 2 TB NVMe cho workload + 4 TB SSD cho lưu trữ dung lượng lớn trên mỗi node. * HA và dự phòng đầy đủ dù footprint rất nhỏ. ```mermaid graph LR N1["Node 1
Controller + Storage + Compute"] <-->|"Core Fabric
(Kết nối trực tiếp)"| N2["Node 2
Controller + Storage + Compute"] N1 --- EXT["Mạng bên ngoài
(Uplink)"] N2 --- EXT style N1 fill:#e8f5e9,stroke:#2e7d32 style N2 fill:#e8f5e9,stroke:#2e7d32 ``` ### Mô hình quản lý Edge VergeOS hỗ trợ ba kịch bản quản lý edge với mức độ tinh vi tăng dần: 1. **Độc lập với quản lý tập trung** -- cluster 2 node tại mỗi site, được quản lý tập trung qua **Sites** dashboard. Catalog Repositories phân phối các mẫu VM từ cluster quản lý đến tất cả các site edge. 2. **Sao lưu tập trung và DR** -- Tương tự như trên, cộng thêm một hệ thống trung tâm tại data center chính cung cấp **Site Sync** sao chép, **ioGuardian** máy chủ sửa chữa và lưu trữ snapshot tập trung cho tất cả văn phòng chi nhánh. 3. **Nhiều tầng với archive** -- Thêm một cluster lưu trữ archive thứ cấp tại site DR để lưu trữ dài hạn bằng HDD dung lượng lớn, cung cấp chiến lược sao lưu 3-2-1 hoàn chỉnh. ### Khi nào nên đề xuất Edge * Hạn chế về không gian hoặc nguồn điện tại các site từ xa. * Các ứng dụng lưu trữ dữ liệu tập trung nhưng cần compute cục bộ. * Các tổ chức quản lý 5--100+ địa điểm phân tán. * Triển khai văn phòng chi nhánh nhạy cảm về chi phí. *** ## Tình huống CSP / đa thuê bao Nhà cung cấp dịch vụ đám mây tận dụng tính đa thuê bao của VergeOS để cung cấp IaaS từ hạ tầng dùng chung. Mỗi tenant hoạt động như một Virtual Data Center (VDC) cô lập với UI, mạng, storage và kiểm soát truy cập riêng. ### Cấu hình CSP điển hình * **Cluster HCI 6 node** tại các data center chính (máy chủ mật độ cao, RAM 768 GB+ mỗi node). * **Site Sync** giữa các data center cho DR. * **ioGuardian** máy chủ sửa chữa để tự động lấy block từ các site từ xa. * **Khử trùng lặp nội tuyến toàn cục** giảm mức tiêu thụ storage trên các snapshot được sao chép. * **Tenant Recipes** tự động hóa việc cung cấp đầy đủ môi trường khách hàng (tenant, mạng, quy tắc firewall, VM, storage). ### Lộ trình tăng trưởng của CSP | Giai đoạn | Triển khai | Node | | --------------- | ------------------------------------------------------------------------------------ | ------------------------ | | **Giai đoạn 1** | 2 site chính với DR qua Site Sync | 6 mỗi site | | **Giai đoạn 2** | Thêm các cluster edge 2 node ở các khu vực mới | 2 mỗi khu vực | | **Giai đoạn 3** | Mở rộng các site edge bằng cách thêm cluster (mang tính minh họa) | thay đổi theo từng site | | **Giai đoạn 4** | Thêm các cluster storage chuyên dụng cho tenant thiên về storage và các tầng archive | 2+ node storage mỗi site | ### Các tính năng VergeOS chính dành cho CSP * **Đa thuê bao** với sự cô lập hoàn toàn giữa các môi trường khách hàng. * **Quản lý tự phục vụ** thông qua giao diện web và API cho quản trị viên tenant. * **Catalog Repositories** để quản lý mẫu VM tập trung. * **Xác thực OpenID** tích hợp với các nhà cung cấp danh tính hiện có. * **Tenant Recipes** cho việc onboarding khách hàng tự động, lặp lại được. *** ## Tổng quan các mô hình thiết kế mạng Kiến trúc triển khai bạn chọn sẽ ảnh hưởng đến thiết kế mạng của bạn. VergeOS hỗ trợ nhiều topology mạng, được trình bày chi tiết trong [Module 4: Networking](/learn-the-platform/vi/module-4-networking/04-networking.md). Sau đây là tổng quan ngắn để hỗ trợ quyết định kiến trúc của bạn: | Mô hình | NIC mỗi node | Core Fabric | Mạng bên ngoài | Phù hợp nhất cho | | ------------------------------ | ------------ | --------------------------- | ------------------------------------ | ------------------------------------------ | | **L2 tĩnh + Core chuyên dụng** | 4 | 2 L2 chuyên dụng | L2 gộp (LACP) | Môi trường production, di chuyển từ VMware | | **L3 động + Core chuyên dụng** | 4 | 2 L2 chuyên dụng | được quảng bá qua BGP / OSPF / EIGRP | Quy mô lớn, phân đoạn nâng cao | | **L3 tĩnh + Core chuyên dụng** | 4 | 2 L2 chuyên dụng | L3 gộp (đường tĩnh) | Quy mô lớn, chuyển mạch Layer 3 | | **L2 tĩnh (2 NIC)** | 2 | 2 dùng chung (gắn thẻ VLAN) | Dùng chung với core (gắn thẻ VLAN) | Edge, PoC, triển khai nhỏ | **Các yêu cầu chính trên mọi mô hình:** * Mạng core fabric phải nằm trên **các phân đoạn Layer 2 chuyên dụng** (được cô lập với nhau). * Khung jumbo (**MTU 9216+**) trên tất cả các cổng chuyển mạch của core fabric. * **Không có bước nhảy qua switch** giữa các node trên core fabric -- tất cả các node phải kết nối vào cùng một fabric chuyển mạch. * STP bị tắt trên các cổng core fabric. *** {% hint style="info" %} **Cầu nối VMware** Đang chuyển từ VMware? VergeOS cho phép bạn mở rộng lưu trữ và tính toán độc lập trong một hệ thống — các cụm chỉ tính toán sử dụng vSAN dùng chung qua core fabric, không cần SAN/NAS bên ngoài và không có sản phẩm lưu trữ riêng để cấp phép. {% endhint %} {% hint style="info" %} **Cầu nối Nutanix** Đang chuyển từ Nutanix? VergeOS xây dựng các cụm lưu trữ thuần và các cụm tính toán thuần trong một hệ thống — lưu trữ chạy như một dịch vụ tích hợp của hệ điều hành, nên không có CVM tiêu tốn RAM/CPU trên bất kỳ loại node nào. {% endhint %} ## Tóm tắt | Khái niệm | Điểm chính | | ------------------- | ---------------------------------------------------------------------------------------------- | | **HCI** | Mỗi node làm tất cả mọi việc. Đơn giản, tiết kiệm chi phí ở quy mô nhỏ. Bắt đầu từ đây. | | **HCI + Tính toán** | UCI lai 2 cụm: controller+lưu trữ hợp nhất, mở rộng tính toán độc lập. | | **UCI** | UCI chuẩn 3 cụm: controller, lưu trữ và tính toán chuyên dụng. Linh hoạt tối đa. | | **Biên** | Các cụm 2 node kết nối trực tiếp cho các site từ xa, được quản lý tập trung. | | **CSP** | Các triển khai HCI đa thuê với Site Sync DR và tự động hóa công thức tenant. | | **Tiến hóa** | Cùng một bản cài đặt VergeOS hỗ trợ cả ba mô hình -- phát triển từ HCI lên UCI theo thời gian. | ## Các bước tiếp theo * [**Xác định phạm vi khách hàng**](/learn-the-platform/vi/mo-dun-2-dinh-co-and-thiet-ke/03-customer-scoping.md) -- Tìm hiểu phương pháp thu thập yêu cầu để chuyển nhu cầu khách hàng thành một khuyến nghị kiến trúc cụ thể. * [**Mạng**](/learn-the-platform/vi/module-4-networking/04-networking.md) -- Đi sâu vào các mô hình thiết kế mạng được đề cập ở trên. --- # 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/02-reference-architectures.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.