Xác định phạm vi khách hàng
Phương pháp thu thập yêu cầu, chuyển đổi workload sang tài nguyên, lập kế hoạch tenant node, khung lựa chọn topology và các sản phẩm tài liệu cho triển khai VergeOS.
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
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 đượ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:
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:
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ữ
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).
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
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 tenantnode 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:
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áyvàSố lõi tối đa mỗi máycác thiết lập của cụm giới hạn kích thước của một node tenant đơn.Ứ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).
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.
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ị:
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.
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.
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:
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
Số node có dưới 6 không? → Bắt đầu với HCI trừ khi có lý do cụ thể để tách compute.
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.
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.
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.
Đơ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.
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:
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
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.
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
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).
Tóm tắt
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 — 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 — 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 — Tiến hành chuẩn bị và triển khai cài đặt.
Cập nhật lần cuối
Nội dung này có hữu ích không?