Cách xác định nhu cầu server theo số người dùng và ứng dụng

CDC Technologies khi triển khai các bài toán hạ tầng thường ưu tiên cách làm theo dữ liệu thực tế: khảo sát, đo tải, mô phỏng nhu cầu rồi mới sizing server. Cách tiếp cận này giúp doanh nghiệp chọn đúng cấu hình, dễ mở rộng về sau và tránh phát sinh chi phí không cần thiết.

Nhiều doanh nghiệp khi mua server thường bắt đầu bằng một câu hỏi rất quen thuộc: “Công ty có bao nhiêu người dùng?”. Sau đó, cấu hình server được chọn khá nhanh theo cảm tính hoặc theo kinh nghiệm truyền miệng. Cách làm này dễ dẫn đến hai tình huống: hoặc đầu tư quá nhiều gây lãng phí, hoặc đầu tư chưa đủ khiến hệ thống chậm, dễ nghẽn khi đi vào vận hành thực tế.

Trên thực tế, số lượng người dùng chỉ là một phần của bài toán. Điều quan trọng hơn là doanh nghiệp đang chạy ứng dụng gì, có bao nhiêu người dùng cùng lúc vào giờ cao điểm, mức độ quan trọng của hệ thống ra sao, và kế hoạch mở rộng trong tương lai như thế nào.

Vì sao chỉ nhìn số user rồi chọn server thường không chính xác?

Hai doanh nghiệp cùng có 200 nhân sự nhưng nhu cầu server có thể khác nhau hoàn toàn:

Có doanh nghiệp chỉ dùng các dịch vụ cơ bản như quản lý người dùng nội bộ, lưu file, phần mềm kế toán nhẹ. Loại tải này thường khá ổn định, không quá nặng.
Nhưng cũng có doanh nghiệp chạy ERP, cơ sở dữ liệu, báo cáo BI, nhiều chi nhánh cùng truy cập một lúc. Khi đó, hệ thống sẽ chịu tải cao hơn nhiều, đặc biệt vào giờ chốt sổ hoặc giờ lên báo cáo.

Một ví dụ khác là có doanh nghiệp chỉ làm việc trực tiếp tại văn phòng, nhưng cũng có đơn vị dùng Remote Desktop hoặc VDI. Với mô hình này, tài nguyên CPU và RAM sẽ tăng mạnh theo số phiên đăng nhập đồng thời.

Vì vậy, thay vì chỉ hỏi “Có bao nhiêu user?”, doanh nghiệp nên hỏi đúng hơn: “Có bao nhiêu người dùng cùng lúc trên từng ứng dụng, vào thời điểm nào, và mức độ quan trọng của các ứng dụng đó ra sao?”

Cách xác định nhu cầu server theo số người dùng và ứng dụng

Bước 1: Liệt kê các ứng dụng đang dùng và mức độ quan trọng của từng ứng dụng

Trước khi chọn server, doanh nghiệp nên lập một bản đồ hệ thống đơn giản. Danh sách này có thể gồm các nhóm như: dịch vụ quản lý người dùng nội bộ, lưu file, in ấn, ERP, CRM, database, email, website nội bộ, hệ thống camera, Remote Desktop hoặc VDI.

Với mỗi ứng dụng, nên ghi rõ:

Có bao nhiêu người dùng liên quan
Ứng dụng đó quan trọng đến mức nào
Nếu dừng 1 giờ hoặc 1 ngày thì ảnh hưởng ra sao
Tải sử dụng có đều hay chỉ tăng mạnh vào một số thời điểm
Ứng dụng đó có phụ thuộc vào hệ thống nào khác hay không

Mục tiêu của bước này là chia hệ thống thành từng nhóm công việc rõ ràng, thay vì gom tất cả vào một con số tổng chung chung.

Bước 2: Xác định số người dùng đồng thời và giờ cao điểm

Ví dụ, công ty có 300 người nhưng số người thực sự truy cập vào phần mềm kế toán cùng lúc có thể chỉ là 20–30 người. Ngược lại, một hệ thống file server có thể có rất nhiều người mở file cùng lúc vào đầu giờ sáng hoặc cuối ngày.

Doanh nghiệp nên xác định các khung giờ nóng như:

9h đến 11h sáng
14h đến 16h chiều
Giờ chốt sổ
Giờ chạy báo cáo
Giờ đồng bộ dữ liệu hoặc backup

Sau đó, với từng ứng dụng, cần ước lượng:

Có bao nhiêu người dùng đồng thời
Giờ cao điểm xuất hiện bao lâu
Tần suất lặp lại như thế nào
Dự kiến tăng trưởng trong 12–24 tháng tới ra sao

Làm được bước này, doanh nghiệp sẽ có cái nhìn thực tế hơn rất nhiều khi chọn cấu hình server.

Bước 3: Thu thập tải thực tế nếu đã có hệ thống, hoặc chạy thử nếu là dự án mới

Nếu doanh nghiệp đang có hệ thống cũ, cách tốt nhất là đo số liệu thực tế thay vì đoán. Những thông tin nên theo dõi gồm:

CPU đang dùng bao nhiêu % vào lúc bình thường và lúc cao điểm
RAM dùng thực tế là bao nhiêu
Có hiện tượng thiếu RAM hay phải dùng bộ nhớ ảo không
Dung lượng lưu trữ tăng theo tháng như thế nào
Ổ đĩa có bị chậm vào giờ cao điểm không
Mạng có bị nghẽn theo chi nhánh hoặc VPN không

Nếu là dự án mới, chưa có hệ thống để đo, doanh nghiệp nên làm pilot hoặc POC với một nhóm người dùng đại diện. Chạy thử trong một khoảng thời gian đủ để thấy chu kỳ làm việc thực tế, sau đó mới nhân rộng lên.

Đây là bước rất quan trọng, đặc biệt với các hệ thống như ERP, database hoặc VDI. Những workload này không nên ước lượng theo cảm tính vì rất dễ sai.

Bước 4: Quy đổi nhu cầu thực tế thành cấu hình server

CPU: không chỉ cần đủ chạy, mà còn phải đủ cho giờ cao điểm

Khi chọn CPU cho server, không nên chỉ nhìn số core. Điều quan trọng là hệ thống có đáp ứng được lúc tải cao hay không.

Nếu doanh nghiệp thường xuyên chạy báo cáo, import dữ liệu, đồng bộ dữ liệu hoặc có nhiều người dùng truy cập cùng lúc, CPU cần có đủ khoảng trống để xử lý mà không chạm ngưỡng quá sớm.

Hiểu đơn giản, CPU nên được chọn theo nhu cầu giờ cao điểm, nhưng vẫn phải chừa thêm dư địa để xử lý các tình huống phát sinh.

RAM: càng quan trọng hơn khi doanh nghiệp chạy database hoặc ảo hóa

Nhiều hệ thống chậm không hẳn vì CPU yếu, mà vì thiếu RAM. RAM ảnh hưởng lớn đến độ mượt của hệ thống, đặc biệt trong các trường hợp:

Chạy cơ sở dữ liệu
Chạy nhiều máy ảo
Có nhiều người dùng đăng nhập cùng lúc
Cần cache dữ liệu để giảm tải cho ổ đĩa

Khi tính RAM, nên chia thành 3 phần:

RAM cho hệ điều hành
RAM cho ứng dụng
RAM dự phòng cho tăng trưởng hoặc tải đột biến

Cách tính này sẽ an toàn hơn so với việc chỉ nhìn nhu cầu hiện tại.

Storage: không chỉ tính dung lượng, mà phải tính cả tốc độ xử lý

Đây là chỗ nhiều doanh nghiệp dễ nhầm nhất. Có những hệ thống dung lượng vẫn còn rất nhiều nhưng người dùng vẫn thấy chậm. Lý do nằm ở hiệu năng lưu trữ, không phải ở chỗ “hết chỗ chứa”.

Khi tính storage, cần xem đồng thời 3 yếu tố:

Dung lượng hiện tại và mức tăng trưởng dữ liệu
Tốc độ đọc ghi vào giờ cao điểm
Mức độ an toàn dữ liệu như RAID, thay nóng, dự phòng

Nếu doanh nghiệp chạy database, camera tập trung, VDI hoặc các ứng dụng có nhiều truy xuất dữ liệu, storage gần như là phần phải tính rất kỹ ngay từ đầu.

Network: server mạnh đến đâu cũng có thể chậm nếu đường truyền nghẽn

Doanh nghiệp nên làm rõ:

Có bao nhiêu luồng truy cập cùng lúc
Backup hoặc replication chạy vào thời điểm nào
Có ảnh hưởng đến giờ làm việc hay không
Có cần tách luồng quản trị, máy ảo, lưu trữ hay không

Đặc biệt với mô hình nhiều chi nhánh hoặc kết nối VPN, yếu tố mạng không thể bỏ qua.

Bước 5: Chọn kiến trúc phù hợp: server vật lý, ảo hóa hay cần HA

Sau khi đã biết cần bao nhiêu CPU, RAM, lưu trữ và mạng, doanh nghiệp mới nên quyết định mô hình triển khai.

Nếu hệ thống nhỏ, ít ứng dụng, downtime bảo trì vẫn chấp nhận được → server vật lý có thể là phương án phù hợp.
Nếu doanh nghiệp muốn linh hoạt hơn, dễ tách từng dịch vụ riêng, dễ backup và mở rộng → mô hình ảo hóa sẽ hợp lý hơn.
Nếu downtime ảnh hưởng lớn đến vận hành → doanh nghiệp nên nghĩ đến mô hình cluster hoặc HA để khi bảo trì hoặc có sự cố, dịch vụ vẫn duy trì được.

Ngoài ra, với những hệ thống quan trọng, việc tách riêng database, ứng dụng và các dịch vụ nền cũng giúp hiệu năng ổn định hơn, đồng thời giảm rủi ro “một lỗi kéo theo cả hệ thống”.

Tóm lại, ở bước này doanh nghiệp cần trả lời rõ một câu hỏi: Đang ưu tiên tối ưu chi phí đầu tư hay đang ưu tiên giảm rủi ro downtime? Hai hướng này sẽ dẫn đến hai thiết kế rất khác nhau.

Bước 6: Chốt tiêu chí vận hành ngay từ đầu

Để tránh tình trạng lắp xong server mới bắt đầu tranh luận xem cấu hình như vậy đã đủ hay chưa, doanh nghiệp nên thống nhất tiêu chí ngay từ đầu. Ví dụ:

CPU và RAM ở giờ cao điểm không được chạm trần
Thời gian mở ứng dụng, đăng nhập hoặc xuất báo cáo phải nằm trong mức chấp nhận được
Có thể mở rộng thêm người dùng hoặc chi nhánh mà chưa cần thay mới toàn bộ hệ thống
Có phương án backup và khôi phục dữ liệu rõ ràng
Có công cụ theo dõi và cảnh báo để vận hành lâu dài

Khi đã có tiêu chí cụ thể, việc nghiệm thu sẽ rõ ràng hơn và đội IT nội bộ cũng dễ quản trị hơn về sau.

Ví dụ thực tế

Trường hợp 1: 120 người dùng, chỉ chạy file server và kế toán

Với mô hình này, doanh nghiệp cần quan tâm đến số người mở file cùng lúc, thời điểm kế toán tải nặng nhất, và mức tăng dung lượng dữ liệu mỗi tháng. Nếu làm tốt, hoàn toàn có thể triển khai theo hướng ảo hóa để tách từng dịch vụ riêng, vừa dễ backup vừa dễ mở rộng.

Trường hợp 2: 250 người dùng, chạy ERP và database

Đây là nhóm workload nặng hơn nhiều. Trọng tâm không còn nằm ở số lượng user đơn thuần mà nằm ở hiệu năng database, tốc độ lưu trữ và giờ cao điểm xử lý báo cáo. Với loại hệ thống này, nên ưu tiên số liệu đo thực tế hoặc khuyến nghị từ hãng phần mềm thay vì ước lượng.

Trường hợp 3: 180 người dùng Remote Desktop

Điểm quyết định ở đây là số phiên đăng nhập cùng lúc và loại công việc người dùng đang làm. Nếu chỉ dùng tác vụ văn phòng nhẹ thì khác hoàn toàn so với việc chạy phần mềm nặng. Cách làm an toàn nhất là pilot với một nhóm đại diện, đo tải thực tế rồi mới nhân lên.

7 câu hỏi nên trả lời trước khi chốt cấu hình server

Trước khi mua server, bộ phận IT hoặc mua hàng nên trả lời được 7 câu hỏi sau:

Ứng dụng nào là quan trọng nhất và downtime tối đa chấp nhận được là bao lâu?
Mỗi ứng dụng có bao nhiêu người dùng đồng thời vào giờ cao điểm?
Dữ liệu tăng trưởng theo tháng hoặc theo quý như thế nào?
Hệ thống đang nhạy với CPU, RAM hay lưu trữ?
Có cần ảo hóa, HA hoặc cluster không?
Kế hoạch backup và khôi phục dữ liệu tối thiểu là gì?
Trong 12–24 tháng tới, doanh nghiệp có tăng user, chi nhánh hoặc module phần mềm hay không?

Nếu trả lời rõ được 7 câu này, việc chọn server sẽ chính xác hơn nhiều và bớt phụ thuộc vào cảm tính.

Kết luận: Chọn server là bài toán vận hành, không chỉ là bài toán cấu hình

Cách xác định nhu cầu server theo số người dùng và ứng dụng sẽ hiệu quả hơn khi doanh nghiệp đi đúng quy trình: xác định ứng dụng đang chạy, tính số người dùng đồng thời, đo tải thực tế hoặc chạy thử, sau đó mới quy đổi sang CPU, RAM, lưu trữ và mạng, rồi chốt kiến trúc triển khai phù hợp. Làm đúng ngay từ đầu giúp doanh nghiệp tránh mua thừa, tránh thiếu hiệu năng, đồng thời có nền tảng ổn định để mở rộng trong tương lai.

CDC Technologies có thể hỗ trợ doanh nghiệp theo hướng thực tế và dễ triển khai hơn: