Benchmark: đo IOPS thực tế các gói Cloud Server trước khi ký

Cùng cấu hình 4 vCPU, 16GB RAM, 150GB SSD — nhưng website chạy mượt trên nhà cung cấp A mà ì ạch trên nhà cung cấp B. Thủ phạm thường nằm ở thứ ít được quảng cáo nhất: hiệu năng ổ đĩa. Trước khi ký hợp đồng Cloud Server, việc benchmark IOPS Cloud Server bằng chính tay bạn là cách duy nhất để biết hiệu năng thực tế, thay vì tin vào con số marketing.

Bài viết này hướng dẫn phương pháp đo chuẩn bằng công cụ miễn phí (fio, hdparm, ioping), cách đọc kết quả đúng và quy trình so sánh công bằng giữa các gói.

Benchmark iops cloud server: vì sao phải benchmark IOPS trước khi ký?

IOPS (Input/Output Operations Per Second) đo số thao tác đọc/ghi ổ đĩa xử lý được mỗi giây. Với database MySQL, website WordPress nhiều truy vấn hay shop online, IOPS thường là nút thắt cổ chai — CPU còn nhàn mà website vẫn chậm vì ổ đĩa không "kịp" phục vụ.

Trên Cloud Server, ổ đĩa bạn dùng là ổ đĩa ảo chia sẻ trên hạ tầng vật lý của nhà cung cấp. Hiệu năng thực tế phụ thuộc vào loại ổ cứng vật lý, công nghệ lưu trữ, mức độ "chia sẻ" với khách hàng khác (noisy neighbor) và chính sách giới hạn IOPS theo từng gói.

Không có cách nào biết những điều này từ trang báo giá. Hai gói cùng ghi "150GB SSD" có thể cho IOPS chênh lệch nhiều lần. Benchmark trước khi ký giúp bạn xác minh hiệu năng có đúng như tư vấn không, so sánh công bằng giữa các nhà cung cấp, và phát hiện noisy neighbor ngay từ giai đoạn dùng thử.

Hầu hết nhà cung cấp cloud Việt Nam đều có dùng thử miễn phí (SunCloud cho dùng thử Cloud Server 10 ngày) — đó chính là "phòng lab" để bạn chạy benchmark mà không tốn một đồng nào.

Benchmark iops cloud server: iOPS, throughput, latency: hiểu đúng 3 chỉ số

Người mới benchmark thường chỉ nhìn vào một con số IOPS duy nhất — đó là sai lầm. Hiệu năng ổ đĩa được mô tả bằng ba chỉ số liên quan mật thiết:

IOPS — số thao tác đọc/ghi mỗi giây. Quan trọng nhất với workload nhiều file nhỏ, truy vấn ngẫu nhiên: database OLTP, mail server, hệ thống nhiều user đồng thời.

Throughput — lượng dữ liệu đọc/ghi mỗi giây (MB/s). Quan trọng với workload file lớn, đọc/ghi tuần tự: backup, streaming, xử lý batch.

Latency — thời gian trung bình cho một thao tác, tính bằng ms. Latency thấp và ổn định quan trọng hơn IOPS đỉnh cao: hệ thống IOPS cao nhưng latency "nhảy múa" khiến ứng dụng phản hồi thất thường.

Ba chỉ số liên hệ qua kích thước block: IOPS đo bằng block 4KB không thể so với IOPS đo bằng block 64KB. Vì vậy khi đọc kết quả benchmark, luôn xem cả ba chỉ số cùng nhau và ghi nhận kích thước block của bài test.

Benchmark iops cloud server: chuẩn bị môi trường test công bằng

Kết quả benchmark chỉ có ý nghĩa khi các bài test chạy trong điều kiện tương đương:

1. Test trên workload của bạn. Nếu ứng dụng là MySQL với 70% đọc ngẫu nhiên, hãy ưu tiên kịch bản random read 4KB — đó mới là con số quyết định trải nghiệm thực tế.

2. Cùng hệ điều hành và cấu hình. Các gói so sánh nên cài cùng distro, cùng kernel, cùng filesystem. Tắt dịch vụ không cần thiết để tránh nhiễu.

3. Test nhiều thời điểm. Hiệu năng cloud có thể dao động theo giờ. Chạy test vào ít nhất 3 khung giờ (sáng, chiều, đêm) và lấy trung bình.

4. Ghi chép đầy đủ. Gói nào, lệnh gì, tham số nào, thời điểm nào. Không có nhật ký test, bạn không thể tái hiện hay đối chiếu với nhà cung cấp khi tranh chấp SLA.

Lưu ý: benchmark tạo tải nặng lên ổ đĩa. Hãy chạy trên gói dùng thử hoặc ngoài giờ cao điểm, và đừng chạy test ghi trên ổ đĩa chứa dữ liệu quan trọng nếu chưa backup.

Đo bằng fio: 4 kịch bản test chuẩn

fio (Flexible I/O Tester) là công cụ benchmark ổ đĩa chuẩn mực trong giới sysadmin — miễn phí, mã nguồn mở. Cài đặt: apt install fio (Ubuntu/Debian) hoặc yum install fio (RHEL/CentOS).

Bốn kịch bản cốt lõi, mỗi kịch bản chạy khoảng 60 giây:

1. Random read 4KB (mô phỏng database đọc):

fio --name=randread --ioengine=libaio --rw=randread \
  --bs=4k --size=4G --numjobs=4 --runtime=60 --group_reporting

Kịch bản quan trọng nhất với đa số ứng dụng web.

2. Random write 4KB (mô phỏng database ghi, log):

fio --name=randwrite --ioengine=libaio --rw=randwrite \
  --bs=4k --size=4G --numjobs=4 --runtime=60 --group_reporting

Thường thấp hơn đọc đáng kể — điểm yếu của nhiều hệ thống lưu trữ.

3. Sequential read 1MB (mô phỏng đọc file lớn, backup):

fio --name=seqread --ioengine=libaio --rw=read \
  --bs=1M --size=4G --numjobs=1 --runtime=60 --group_reporting

4. Mixed 70/30 (mô phỏng workload thực tế):

fio --name=mixed --ioengine=libaio --rw=randrw --rwmixread=70 \
  --bs=4k --size=4G --numjobs=4 --runtime=60 --group_reporting

70% đọc + 30% ghi ngẫu nhiên — gần nhất với pattern web app + database thông thường.

Thêm --direct=1 (bypass cache) để đo hiệu năng ổ đĩa thực, không phải tốc độ RAM cache.

Đo nhanh bằng hdparm, dd và ioping

hdparm — đo tốc độ đọc trong 10 giây:

hdparm -tT /dev/vda

Dòng buffered disk read cho tốc độ đọc thực từ ổ đĩa (bỏ qua dòng cached read). Phù hợp kiểm tra nhanh "ổ đĩa có vấn đề gì không" — nhưng không đo được IOPS ngẫu nhiên.

dd — đo tốc độ ghi tuần tự:

dd if=/dev/zero of=testfile bs=1M count=1024 conv=fdatasync

Tham số conv=fdatasync đảm bảo dữ liệu thực sự ghi xuống ổ đĩa chứ không nằm trong cache. Đơn giản nhưng chỉ đo một chiều — đừng dùng kết quả này để suy ra IOPS.

ioping — đo latency:

ioping -c 100 /dev/vda

Gửi 100 request đọc nhỏ và báo latency trung bình, tối thiểu, tối đa. Tuyệt vời để phát hiện latency "nhảy múa" — nếu tối đa gấp hàng chục lần trung bình, đó là dấu hiệu noisy neighbor hoặc hạ tầng lưu trữ quá tải.

Quy tắc: dùng hdparm/dd/ioping để sàng lọc nhanh, dùng fio để kết luận chính thức.

Cách đọc kết quả: IOPS "đỉnh" và IOPS "ổn định"

1. Nhìn phân bố, không chỉ nhìn trung bình. Hãy xem thêm độ lệch chuẩn và các phân vị. Hệ thống trung bình 10.000 IOPS (minh họa) nhưng 1% request chậm gấp 10 lần sẽ cho trải nghiệm tệ hơn hệ thống ổn định ở 8.000 IOPS (minh họa).

2. So sánh "táo với táo". Chỉ so sánh các kết quả chạy cùng lệnh, cùng tham số, cùng kích thước file test. Khi đọc báo cáo benchmark của nhà cung cấp, hãy hỏi: "test bằng công cụ gì, tham số nào?"

3. Chạy đủ lâu để qua "tuần trăng mật". Nhiều hệ thống lưu trữ có lớp cache/burst: 5 phút đầu IOPS rất cao, sau đó rớt xuống mức sustained. Với workload chạy 24/7, con số sustained mới là con số thật.

Đừng quên latency: trong báo cáo fio, cột clat cho biết độ trễ trung bình và phân vị 99% — latency p99 thấp và ổn định là dấu hiệu hạ tầng lưu trữ tốt.

So sánh nhiều gói: phương pháp test song song

Bước 1 — Lập danh sách rút gọn. Chọn 2–3 gói trong tầm giá, đăng ký dùng thử đồng thời. Đừng test lần lượt cách nhau cả tháng — điều kiện hạ tầng thay đổi theo thời gian.

Bước 2 — Chuẩn hóa môi trường. Cài cùng OS, cùng filesystem, cùng phiên bản fio trên mọi gói. Viết lệnh test thành script để chạy giống hệt nhau.

Bước 3 — Chạy bộ 4 kịch bản fio + ioping trên mỗi gói, mỗi kịch bản lặp 3 lần vào 3 khung giờ. Ghi vào bảng so sánh: IOPS đọc/ghi ngẫu nhiên, throughput tuần tự, latency trung bình và p99.

Bước 4 — Chấm điểm theo workload của bạn. Không có "gói thắng tuyệt đối" — chỉ có "gói phù hợp nhất". Database nặng đọc ngẫu nhiên thì ưu tiên random read IOPS và latency.

Bước 5 — Kiểm tra điều khoản SLA. Hỏi nhà cung cấp về chính sách IOPS: có giới hạn trần theo gói không, có cam kết IOPS tối thiểu không. Con số benchmark của bạn chính là "bằng chứng gốc" để đối chiếu sau này.

Checklist 10 bước trước khi ký hợp đồng Cloud Server

2–3 ngày dùng thử là đủ để hoàn thành checklist này — và đó là 2–3 ngày xứng đáng nhất trước một hợp đồng 12–24 tháng.

Dùng thử SunCloud 10 ngày để tự benchmark

Lý thuyết sẽ vô nghĩa nếu bạn không có nơi thực hành. SunCloud cho dùng thử Cloud Server miễn phí 10 ngày — đủ dài để chạy toàn bộ quy trình ở trên: đăng ký 1–2 gói trong tầm ngân sách, cài đặt môi trường chuẩn, chạy bộ test fio vào các khung giờ khác nhau.

Hạ tầng Cloud Server của SunCloud chạy trên nền tảng ảo hóa OpenStack/VMware với ổ SSD Enterprise, thiết kế dự phòng 2n+1 và cam kết uptime 99,98% — nhưng thay vì tin vào những dòng này, hãy dùng 10 ngày miễn phí để tự đo bằng fio và ioping. Số liệu do chính tay bạn đo trên workload của chính bạn mới là câu trả lời đáng tin nhất.

Khi đã có kết quả ưng ý và quyết định gắn bó lâu dài, đội ngũ kỹ thuật SunCloud hỗ trợ migrate và tư vấn chọn gói đúng với workload thực tế. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để đăng ký dùng thử.

Kết luận

Benchmark IOPS Cloud Server trước khi ký không phải việc của dân chuyên sâu — với fio, hdparm và ioping đều miễn phí cùng vài giờ thực hành, bất kỳ admin nào cũng tự đo được hiệu năng thực tế của gói cloud định mua. Quy trình gói gọn trong 5 chữ: chuẩn hóa môi trường, đo đủ 3 chỉ số, lặp lại nhiều khung giờ, so sánh sustained thay vì burst, và chấm điểm theo workload của chính bạn.

Đừng ký hợp đồng 12 tháng dựa trên hai chữ "SSD" trong bảng báo giá. Hãy dùng thời gian dùng thử miễn phí để đo — vì trên cloud, hiệu năng bạn đo được hôm nay gần như chính là hiệu năng bạn sẽ sống cùng trong suốt hợp đồng.

Nếu bạn cần môi trường dùng thử 10 ngày miễn phí để chạy benchmark theo đúng quy trình trong bài, đội ngũ SunCloud sẵn sàng hỗ trợ. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn.

Câu hỏi thường gặp

IOPS bao nhiêu là đủ cho website WordPress?

Không có con số chung — phụ thuộc lượng truy cập đồng thời, số plugin và cách tối ưu database. Thay vì săn con số tuyệt đối trên mạng, hãy benchmark gói hiện tại khi website chạy ổn định để lấy "baseline", rồi yêu cầu gói mới đạt ít nhất bằng baseline đó trên cùng kịch bản test.

Có thể tin vào số IOPS nhà cung cấp công bố không?

Hãy xem đó là thông tin tham khảo, trừ khi con số được ghi rõ trong SLA kèm điều kiện đo cụ thể (công cụ, block size, pattern đọc/ghi). Số liệu marketing thường đo trong điều kiện lý tưởng (block lớn, đọc tuần tự, burst cache). Con số đáng tin nhất là do chính bạn đo bằng fio trên gói dùng thử.

Test ghi có làm mất dữ liệu không?

Có thể, nếu chạy test ghi lên partition đang chứa dữ liệu — fio sẽ ghi đè lên vùng dữ liệu trong phạm vi file test. Quy tắc an toàn: luôn chạy test ghi trên file/partition test riêng, và backup đầy đủ trước khi benchmark hệ thống production. Trên gói dùng thử mới tinh thì không phải lo điều này.

Vì sao kết quả benchmark lúc nhanh lúc chậm?

Nguyên nhân phổ biến nhất trên cloud là noisy neighbor — các máy ảo "hàng xóm" tranh chấp tài nguyên vào giờ cao điểm. Nguyên nhân khác: cơ chế burst của gói (nhanh lúc đầu, chậm dần), hoặc cache chưa "ấm". Đó chính là lý do cần test ở nhiều khung giờ và so sánh con số sustained.

Nên dùng ext4 hay xfs khi benchmark để so sánh?

Cái nào cũng được, miễn là giống nhau trên mọi gói so sánh. ext4 và xfs cho kết quả chênh lệch vài phần trăm trong cùng điều kiện — đủ để làm nhiễu phép so sánh nếu mỗi gói dùng một loại. Hãy chọn một filesystem, dùng thống nhất và ghi rõ trong nhật ký test.

Bao lâu nên benchmark lại sau khi đã ký hợp đồng?

Nên benchmark định kỳ mỗi quý bằng cùng bộ test ban đầu, và so với "bằng chứng gốc" lúc dùng thử. Nếu hiệu năng sụt giảm đáng kể không rõ nguyên nhân, đó là cơ sở để làm việc với nhà cung cấp về SLA. Hãy benchmark lại sau mỗi lần bảo trì lớn hoặc khi nâng/hạ gói.