Tóm tắt nhanh
- CRS của Proxmox phân bổ tài nguyên HA; chế độ dynamic xét cả mức dùng CPU và RAM thực tế, thay vì chỉ đếm máy ảo hoặc nhìn định mức cấu hình.
- Tự động cân bằng là tùy chọn riêng và mặc định tắt. Bật HA không có nghĩa cụm máy sẽ tự san tải.
- TOPSIS đáng cân nhắc khi thiếu RAM, còn bruteforce là điểm khởi đầu hợp lý nếu CPU và bộ nhớ đều gây áp lực.
- Di chuyển container có thể làm dịch vụ dừng rồi khởi động lại; giảm lệch tải chưa chắc đáng đổi lấy một lần gián đoạn.
Một cụm Proxmox vẫn có thể phục hồi dịch vụ sau sự cố mà tiếp tục chạy lệch tải khi máy chủ đã trở lại. Với homelab ghép từ máy tính cũ và mini PC, điều đáng quan tâm không phải mỗi máy đang giữ bao nhiêu máy ảo, mà là máy nào còn đủ tài nguyên để chạy chúng ổn định.
Cluster Resource Scheduler, gọi tắt là CRS, giải quyết phần lựa chọn nơi chạy tài nguyên trong cụm. Cơ chế tự cân bằng tải trên Proxmox VE 9.2 bổ sung khả năng chủ động di chuyển tài nguyên HA khi cụm mất cân bằng. Giá trị của nó nằm ở việc giảm công quản trị sau những lần tải thay đổi, chứ không phải biến mọi cấu hình nhiều máy thành một hệ thống tự vận hành không cần theo dõi.
CRS phải nhìn tải thực tế, không chỉ đếm máy ảo
Chia đều số lượng máy ảo là thước đo quá thô cho một homelab có phần cứng khác nhau. Một máy ảo dùng ít CPU nhưng giữ nhiều RAM có thể tạo sức ép lớn hơn nhiều dịch vụ nhẹ cộng lại; đếm số khách đang chạy không phản ánh được khác biệt ấy. Ngay cả định mức CPU và RAM cấp trong cấu hình cũng chưa nói hết tài nguyên thực sự đang bị sử dụng.
Tài liệu Proxmox phân biệt ba chế độ lập lịch. Basic chỉ dựa vào số lượng dịch vụ, static xét CPU và bộ nhớ được cấu hình cho khách, còn dynamic kết hợp cấu hình với mức dùng CPU và RAM thực tế. Đây là cách hệ thống đánh giá các máy chủ và tài nguyên HA khi quyết định vị trí chạy, không phải ba tên gọi khác nhau của công tắc tự di chuyển.
Sự tách biệt này quan trọng vì tự động cân bằng còn có thể kết hợp với chế độ static. Khi đó, mục tiêu là cân đối theo định mức đã cấp, trong khi dynamic phản ứng theo mức sử dụng thực tế. Vì vậy, nói rằng chỉ chế độ dynamic mới có khả năng tự cân bằng là không chính xác. Người quản trị cần chọn cả thước đo lẫn việc có cho phép hệ thống chủ động chuyển tài nguyên hay không.
Chế độ dynamic cũng tính mức dùng tài nguyên của chính máy chủ, bao gồm phần phục vụ ZFS hoặc Ceph, thay vì chỉ cộng nhu cầu của các máy ảo thuộc HA. Với cụm vừa chạy khách vừa lo lưu trữ, đây là khác biệt đáng giá: tài nguyên tiêu cho lớp lưu trữ vẫn là tài nguyên mà dịch vụ không còn có thể sử dụng.
Phạm vi di chuyển lại hẹp hơn phạm vi quan sát. Hệ thống chọn từ các tài nguyên HA có thể di chuyển và những đích đến hợp lệ, chứ không tự tiếp quản mọi máy ảo trong cụm. Một dịch vụ không thuộc HA có thể góp phần làm máy chủ bận, nhưng không vì thế mà tự trở thành đối tượng được CRS chuyển sang máy khác.
Người dùng cũng không nên hiểu tự cân bằng là cam kết đưa khách về đúng máy chủ ban đầu. Thuật toán tìm phương án giảm mất cân bằng trong điều kiện hiện tại; vị trí hợp lý sau sự cố có thể khác vị trí trước đó. Nếu ứng dụng cần gắn với một máy chủ cụ thể, yêu cầu ấy phải được xử lý bằng chính sách HA phù hợp, thay vì trông chờ bộ cân bằng tải nhớ nơi chạy cũ.
Với homelab, cách nhìn này giúp tránh đầu tư sai chỗ. Khi một máy chủ còn nhàn mà máy khác đã chịu áp lực, tự phân bổ lại có thể tận dụng phần tài nguyên đang bỏ trống. Nhưng nếu cả cụm đều thiếu bộ nhớ, không thuật toán nào tạo thêm RAM; lúc ấy phải giảm nhu cầu của khách hoặc bổ sung phần cứng.
TOPSIS hợp cụm thiếu RAM, nhưng đừng bỏ qua ngưỡng di chuyển
TOPSIS đáng thử khi bộ nhớ là giới hạn thường xuyên, nhưng không có cơ sở để coi nó luôn tốt hơn bruteforce cho mọi homelab. Cụm chạy tác vụ nặng CPU và cụm chứa nhiều dịch vụ giữ bộ nhớ lâu có thể cần cách ưu tiên khác nhau, dù bề ngoài cùng dùng một tập hợp máy tính cũ.
Theo giải thích kỹ thuật của Proxmox, bruteforce hiện xem tải CPU trung bình và mức dùng RAM với trọng số ngang nhau khi chấm điểm phương án di chuyển. TOPSIS dành ưu tiên lớn hơn cho bộ nhớ. Lý do có thể hiểu ngay ở cấp vận hành: CPU chịu tải cao thường kéo dài thời gian xử lý, còn bộ nhớ là giới hạn dung lượng mà ứng dụng không thể bỏ qua.
Đó là lý do TOPSIS hợp để cân nhắc cho cụm thiếu RAM, chứ chưa phải bằng chứng về mức tăng hiệu năng. Không có kết quả đo so sánh đủ để khẳng định đổi thuật toán sẽ giúp ứng dụng nhanh hơn một tỷ lệ cụ thể. Quyết định nên dựa vào điểm nghẽn đã quan sát được và hành vi di chuyển sau khi bật, thay vì chọn theo tên thuật toán.
Quan trọng hơn, lựa chọn phương pháp chấm điểm chỉ là một phần của cấu hình. Theo tài liệu datacenter.cfg của Proxmox, ha-auto-rebalance mặc định bằng 0, nghĩa là tự động cân bằng đang tắt. Tùy chọn ha-rebalance-on-start lại phục vụ việc chọn nơi chạy khi tài nguyên HA chuyển từ trạng thái dừng sang khởi động, không thay thế cơ chế san tải tự động của cụm đang hoạt động.
Khi bật tự cân bằng, Proxmox mặc định dùng ngưỡng mất cân bằng 30%, yêu cầu ngưỡng bị vượt trong 3 vòng HA và chỉ chấp nhận phương án có mức cải thiện tương đối tối thiểu 10%. Phương pháp chấm điểm mặc định là bruteforce. Các con số này là tham số điều khiển quyết định di chuyển, không phải mức CPU hoặc RAM mà mỗi máy chủ bắt buộc phải đạt.
Đặc biệt, ngưỡng mất cân bằng 30% không có nghĩa cứ CPU vượt 30% là máy ảo bị chuyển đi. Mức mất cân bằng là chỉ số tổng hợp của cả cụm. Trong giải thích trên diễn đàn Proxmox, tải CPU và bộ nhớ của từng máy chủ được chuẩn hóa theo khả năng của chính máy đó trước khi tính mức phân tán tải giữa các máy.
Với phần cứng hỗn hợp, tỷ lệ sử dụng vì thế hữu ích hơn việc so trực tiếp dung lượng RAM đã dùng. Tuy nhiên, cùng một tỷ lệ CPU không có nghĩa hai bộ xử lý khác nhau sẽ hoàn thành cùng công việc nhanh như nhau. Cân bằng theo chỉ số tài nguyên vẫn cần được đối chiếu với độ đáp ứng của ứng dụng, nhất là khi ghép mini PC tiết kiệm điện với máy bàn có CPU khỏe hơn.
Khoảng chờ qua các vòng HA và yêu cầu cải thiện tối thiểu giúp tránh quyết định di chuyển chỉ vì một biến động ngắn. Hạ ngưỡng để cụm trông đều hơn trên bảng theo dõi có thể làm tăng số lần chuyển khách mà lợi ích sử dụng không tương xứng. Điểm khởi đầu hợp lý là giữ cấu hình mặc định, xác định áp lực thực sự nằm ở CPU hay RAM, rồi mới cân nhắc đổi phương pháp chấm điểm.
Homelab nên ưu tiên dịch vụ ổn định hơn biểu đồ đẹp
Không phải lần giảm lệch tải nào cũng đáng thực hiện nếu cái giá là làm gián đoạn dịch vụ đang dùng. Đây là phần người vận hành homelab cần đặt trước mục tiêu chia tài nguyên cho đều, nhất là khi cụm chứa container hoặc khách có cấu hình phần cứng đặc biệt.
Với LXC, việc di chuyển có thể kéo theo dừng và khởi động lại container trên máy đích. Proxmox xác nhận đặc điểm này trong thảo luận kỹ thuật về CRS. Vì vậy, không nên suy từ khả năng di chuyển máy ảo đang chạy sang kết luận rằng mọi loại khách đều được chuyển mà không ảnh hưởng ứng dụng.
Ngay cả với VM, chi phí di chuyển cũng không đồng nhất. Thảo luận trên diễn đàn Proxmox đề cập các máy ảo dùng vGPU có khoảng tạm dừng dài hơn khi chuyển trạng thái liên quan đến GPU. Không thể lấy một lần di chuyển thuận lợi của VM thông thường làm bảo đảm cho toàn bộ khách có thiết bị đặc thù, và càng không nên mặc định mọi cấu hình gắn thiết bị đều đủ điều kiện di chuyển.
Cách lựa chọn phương án cũng tạo ra một đánh đổi dễ bị bỏ qua. Cơ chế cân bằng ưu tiên giảm độ lệch giữa các máy chủ; chuyển một tài nguyên lớn có thể đạt mục tiêu nhanh hơn chuyển nhiều tài nguyên nhỏ. Nhưng một lần chuyển lớn gây ảnh hưởng rõ tới ứng dụng đôi khi lại kém phù hợp hơn việc chấp nhận cụm chưa cân bằng hoàn toàn.
Ở Việt Nam, người dùng homelab có thể dùng Proxmox VE và các chức năng HA mà không phải mua giấy phép tính năng. Dù vậy, tiết kiệm chi phí phần mềm không xóa được chi phí vận hành: cần đủ tài nguyên cho khách sau khi chuyển, lưu trữ phù hợp và đường truyền đáp ứng việc di chuyển. CRS là lớp tự động hóa phân bổ, không thay thế các điều kiện nền tảng ấy.
Trước khi bật trên cụm đang phục vụ nhu cầu hằng ngày, nên xác định tài nguyên nào thuộc HA, khách nào đủ điều kiện di chuyển và ứng dụng nào chấp nhận được một lần khởi động lại. Sau đó, thử với nhóm dịch vụ ít quan trọng để quan sát tần suất chuyển và tác động thực tế. Việc này có ý nghĩa hơn nhiều so với nhìn một lần vào mức dùng RAM rồi kết luận thuật toán đã phù hợp.
Cũng cần phân biệt Proxmox VE với Proxmox Datacenter Manager. Giao diện quản lý tổng hợp giúp nhìn nhiều hệ thống từ một nơi, nhưng nhìn thấy chúng trong cùng một bảng quản trị không có nghĩa tất cả đã trở thành một cụm HA có thể tự chuyển khách cho nhau. Phạm vi cần kiểm tra vẫn là cụm VE, các tài nguyên HA và đích di chuyển hợp lệ của chúng.
Với cụm thường lệch tải sau bảo trì hoặc sự cố, tự cân bằng có thể giảm đáng kể việc phải lựa chọn và chuyển khách thủ công. Còn nếu dịch vụ đang ổn định, tải ít thay đổi và container nhạy với gián đoạn, giữ quyền di chuyển trong tay người quản trị vẫn là lựa chọn hợp lý. Mục tiêu nên là giảm số lần phải xử lý sự cố, không phải làm mọi cột CPU và RAM trên màn hình cao bằng nhau.
Nguồn tham khảo: Tài liệu cấu hình Datacenter của Proxmox; Thảo luận kỹ thuật CRS trên Proxmox Support Forum; XDA Developers.
