Nâng cấp NAS: RAM, cache NVMe, ổ cứng hay mạng trước?

Bốn hướng nâng cấp, bốn bài toán khác nhau

NAS ì ạch, phản xạ của đa số người dùng là "chắc phải gắn thêm SSD cache cho nó nhanh lên". Bỏ vài triệu mua NVMe, cắm vào, hồi hộp chờ... và chẳng thấy gì đổi khác. Vì sao? Vì cache NVMe chỉ giải quyết đúng một loại vấn đề, còn NAS chậm có thể vì bốn lý do hoàn toàn khác nhau: thiếu RAM, tải I/O ngẫu nhiên cần cache, mạng nghẽn, hoặc ổ đĩa không đủ IOPS.

Bốn hướng này không thay thế được cho nhau. Gia đình xem phim, backup ảnh, copy file lớn qua mạng — thứ họ cần gần như chắc chắn không phải cache. Người chạy Docker, Plex transcode, vài VM cùng lúc mà máy hay đơ, treo, swap liên tục — RAM mới là nút thắt. Freelancer dựng phim copy file dự án hàng chục GB mỗi ngày mà tốc độ cứ dừng lại quanh 110MB/s dù RAID bên trong thừa sức chạy nhanh hơn — mạng 1GbE mới là thủ phạm. Còn cache NVMe thật sự đáng tiền chỉ trong trường hợp khá hẹp: home lab chạy database hoặc nhiều VM ghi ngẫu nhiên liên tục lên pool HDD.

Bài này không dạy bạn cài gì — mà dạy cách tìm đúng cổ chai (bottleneck) trước khi rút ví. Tiền đổ nhầm chỗ, ở NAS hay ở đâu, cũng xót y như nhau.

Bước 1: Chẩn đoán trước, đừng đoán mò

Trước khi rút ví, mở resource monitor lên xem NAS đang nghẽn ở đâu đúng lúc nó ì ạch nhất — quan sát 5-10 phút là đủ biết. Mỗi nền tảng có công cụ sẵn, khỏi cần cài thêm gì:

• DSM (Synology): Control Panel > System > Resource Monitor, xem CPU, RAM, network, disk theo thời gian thực.
• QTS (QNAP): Control Panel > System > Resource Monitor > Processes, lọc theo CPU/Memory để biết tiến trình nào đang ngốn tài nguyên.
• UGOS (UGREEN NASync): Dashboard hệ thống có biểu đồ CPU/RAM/network/disk tương tự, theo dõi ngay lúc tải cao.
• TrueNAS/ZFS: tab Reporting/Dashboard, hoặc dùng CLI cho chi tiết hơn — arc_summary xem tỷ lệ hit của ARC, zpool iostat -v 1 xem I/O từng ổ theo từng giây.
• Unraid: tab Dashboard, hoặc terminal chạy htop/iotop.

Muốn tách bạch lỗi mạng khỏi lỗi ổ đĩa, chạy iperf3 giữa client và NAS (server chạy iperf3 -s trên NAS, client chạy iperf3 -c ). Nếu kết quả đã kịch trần ~110-125MB/s trên mạng 1GbE thì đừng mất công nâng RAM hay cache — mạng mới là thứ cần đổi trước.

Đọc dấu hiệu: CPU liên tục cao khi nhiều app/Docker chạy cùng lúc → cần thêm CPU hoặc RAM để giảm tải. Disk I/O wait cao kèm pattern truy cập ngẫu nhiên (nhiều tiến trình đọc/ghi file nhỏ cùng lúc) → cân nhắc cache. Network đã bão hòa gần giới hạn lý thuyết → nâng cấp mạng.

RAM: rẻ, an toàn, ROI cao nhất — nhưng có điểm dừng

RAM là nâng cấp ít rủi ro nhất trong bốn hướng. Cắm thanh RAM, khởi động lại, xong — không đụng đến cấu trúc RAID hay pool, không cần backup trước như lúc đổi ổ. Trên hệ thống chạy ZFS, RAM rảnh mặc định được dùng làm ARC (Adaptive Replacement Cache) — cache đọc thông minh giúp giảm truy cập ổ đĩa vật lý. Trên Linux, ZFS ARC mặc định chiếm khoảng phân nửa RAM hệ thống, và các bản OpenZFS mới có xu hướng lấy gần hết RAM rảnh còn lại. TrueNAS khuyến nghị tối thiểu 8GB RAM cho một hệ thống cơ bản — càng chạy nhiều Docker, VM, hay nhiều user SMB đồng thời, càng cần nhiều RAM hơn để tránh swap.

Vấn đề là lợi ích của RAM giảm dần khi nó đã đủ chứa "working set" — tức tập dữ liệu bạn hay dùng lặp đi lặp lại. Cắm thêm RAM khi RAM hiện tại đã dư dả chẳng khác gì mua thêm ổ khóa cho cửa đã khóa rồi.

Cạm bẫy hay gặp: trên NAS Synology, gắn RAM hãng thứ ba ngoài danh sách tương thích khiến DSM báo "non-Synology memory detected". Máy vẫn chạy bình thường, nhưng có thể ảnh hưởng đến hỗ trợ bảo hành chính hãng — cân nhắc trước khi ham rẻ mua RAM trôi nổi, nhất là với máy không dùng ECC RAM. Lỗi bộ nhớ trên hệ thống non-ECC có thể làm dữ liệu corrupt âm thầm mà không báo lỗi gì rõ ràng.

NVMe cache: đúng thuốc cho đúng bệnh, sai bệnh thì vô dụng

Đây là chỗ dễ vung tiền sai nhất. NVMe cache chỉ giải quyết I/O ngẫu nhiên độ trễ cao — disk ảo của VM, database, hoặc nhiều client cùng lúc mở/ghi các file nhỏ. Với tải tuần tự — xem phim, backup, copy file lớn, vốn chiếm phần lớn nhu cầu NAS gia đình — ổ cứng cơ vốn đã đủ nhanh để đọc tuần tự, cache gần như không tăng tốc thêm gì, mà đôi khi còn phản tác dụng.

Trên DSM 7, cache đọc-only chỉ cần 1 SSD chạy RAID 0, nhưng cache đọc-ghi bắt buộc tối thiểu 2 SSD cùng loại chạy RAID 1 — nhiều người set nhầm cấu hình đọc-only rồi thắc mắc sao ghi vẫn chậm. Synology còn có SSD Cache Advisor để phân tích 7-30 ngày trước khi khuyến nghị dung lượng cache phù hợp — đừng bỏ qua bước này, đoán mò dung lượng cache dễ vừa tốn tiền vừa không đạt hiệu quả. QNAP QTS 5.1.x cũng có yêu cầu tương tự cho Cache Acceleration.

Một lỗi tinh vi hơn: bật cache cho cả file lớn tuần tự (phim, ISO, file backup) khiến cache bị "ô nhiễm" (cache pollution) — dữ liệu ít dùng lại chiếm chỗ, đẩy dữ liệu hay dùng ra khỏi cache, còn SSD thì hao mòn vô ích vì ghi liên tục. Cách xử lý là set ngưỡng bỏ qua (skip threshold) cho file lớn trong cấu hình cache, để cache chỉ giữ lại các block I/O nhỏ, ngẫu nhiên — đúng việc nó sinh ra để làm.

Mạng: cổ chai bị bỏ quên nhiều nhất

Đây là phần hay bị ngó lơ nhất, vì "trong máy nhanh thì ra ngoài cũng phải nhanh" nghe có vẻ hợp lý — nhưng không phải vậy. Mạng 1GbE giới hạn cứng ở khoảng 105-125MB/s bất kể ổ đĩa hay SSD bên trong NAS nhanh cỡ nào. Một ổ cứng 7200rpm đơn lẻ đã đạt tối đa 180-220MB/s tuần tự — tức là chỉ với một ổ HDD, bạn đã bị 1GbE bóp cổ mất gần một nửa băng thông thực tế của ổ.

Nâng lên 2.5GbE (~280MB/s thực tế) là bước hợp lý cho đa số NAS gia đình: tận dụng được cáp Cat5e có sẵn trong nhà, không cần đi lại dây, chi phí thấp — switch 2.5GbE không quản lý khoảng $60-80, card PCIe 2.5GbE khoảng $25-35. Với pool toàn HDD, 2.5GbE gần như đủ dùng, không cần nhảy thẳng lên 10GbE vì ổ cơ không đẩy nổi tốc độ đó.

Ngược lại, nếu pool của bạn là NVMe (4 ổ trở lên có thể đẩy trên 3.000MB/s tuần tự), lúc đó 10GbE mới là điểm nghẽn tiếp theo cần giải quyết — switch 10GbE từ $200+, card 10GbE khoảng $150-180+. Còn 10GbE full mesh (switch + NIC + cáp Cat6a) chỉ thật sự cần khi dựng phim trực tiếp qua mạng hoặc pool toàn SSD/NVMe — bỏ tiền vào đây khi pool vẫn là HDD thì tiền nằm chơi không, chẳng khác gì mua siêu xe rồi chạy trong hẻm cụt.

Storage: nâng khi thiếu chỗ hoặc thiếu IOPS, không phải để "cho nhanh"

Nâng cấp ổ đĩa hợp lý khi: hết dung lượng, cần thêm lớp bảo vệ dữ liệu (redundancy), hoặc cần tăng IOPS bằng cách thêm số ổ chạy song song trong pool — nhiều ổ hơn đồng nghĩa nhiều thao tác đọc/ghi chạy đồng thời hơn. "Đổi ổ là nhanh hơn" chỉ đúng khi bottleneck thực sự nằm ở storage — nếu vấn đề là RAM thiếu hay mạng nghẽn, đổi ổ mới toanh cũng không giải quyết được gì.

So sánh nhanh 4 hướng nâng cấp

Nâng theo kịch bản: không có công thức chung cho tất cả

Gia đình xem phim, backup ảnh, 4-bay: giật khi nhiều thiết bị stream cùng lúc thường là do mạng hoặc CPU transcode, hiếm khi do ổ đĩa. Chẩn đoán resource monitor trước — nếu network đã sát trần 1GbE, nâng lên 2.5GbE trước tiên; nếu CPU cao khi transcode nhiều luồng, thêm RAM hoặc giảm số luồng transcode cùng lúc.

Docker/Plex transcode + vài VM (home lab): hay treo, swap — gần như chắc chắn là RAM. Nâng RAM trước, theo dõi Resource Monitor sau khi nâng để xem còn swap không. NVMe cache chỉ cân nhắc thêm nếu VM disk là điểm nghẽn I/O thực sự.

Dựng phim, sáng tạo nội dung: copy file dự án hàng chục GB mỗi ngày qua mạng nội bộ, RAID bên trong đã đủ nhanh nhưng tốc độ dừng ở ~110MB/s — đây là trường hợp kinh điển của cổ chai mạng. Ưu tiên 2.5GbE hoặc 10GbE (nếu pool là SSD/NVMe) trước khi nghĩ đến bất cứ thứ gì khác.

Văn phòng nhỏ nhiều user đồng thời: nhiều người truy cập file cùng lúc tạo ra tải ngẫu nhiên thật sự — đây là một trong số ít trường hợp NVMe cache đáng cân nhắc, kết hợp thêm RAM để tăng cache hit rate. Nếu số user tiếp tục tăng, tính đến thêm ổ để tăng IOPS song song.

Chọn ổ NAS-grade nếu bạn quyết định nâng storage

Nếu chẩn đoán cho thấy bạn thực sự cần thêm ổ, chọn theo số khay và mức tải chứ không theo thương hiệu quen tay. Cả ba hãng lớn đều có dòng CMR tiêu chuẩn cho NAS gia đình và dòng 7200rpm hiệu năng cao cho tải nặng — lưu ý là cùng một dòng sản phẩm đôi khi có cả model CMR lẫn SMR, nên tra mã model trên datasheet trước khi chốt đơn.

Dòng Plus/IronWolf/N300 phù hợp NAS gia đình phổ thông; lên Pro (WD Red Pro, IronWolf Pro) khi số khay nhiều hơn hoặc tải nặng hơn — đây là nâng cấp theo nhu cầu, không phải "sửa sai" cho lựa chọn trước đó.

Tùy chọn nâng cao, không phải ai cũng cần

• Tinh chỉnh tỷ lệ ARC hoặc bỏ giới hạn ARC mặc định trên TrueNAS — chỉ đáng làm khi chạy nhiều VM nặng cùng lúc và đã xác nhận RAM là nút thắt qua arc_summary.
• L2ARC (mở rộng ARC bằng NVMe) trên TrueNAS/Unraid — chỉ đáng làm khi working set vượt xa RAM hiện có. Overhead ước tính khoảng 1GB RAM cho mỗi 50GB dung lượng L2ARC, nên thêm L2ARC lúc RAM còn dư thừa thì chẳng khác gì tự làm khó mình.

Vài điều cần nhớ trước khi bắt tay vào

Nâng storage hay thêm redundancy không thay thế cho backup 3-2-1 — RAID chỉ chống hỏng ổ, không chống được xóa nhầm, ransomware hay cháy nhà ngập nước. Lúc thêm/đổi ổ, cắm UPS trước khi bắt đầu rebuild pool, vì rủi ro mất dữ liệu cao nhất chính là lúc mất điện giữa chừng khi pool đang rebuild.

Cuối cùng, đừng để cảm giác "mình vừa nâng cấp cái gì đó" đánh lừa bạn. Nâng đúng chỗ, máy chạy êm re, không ai để ý. Nâng sai chỗ, tiền mất mà máy vẫn ì y như cũ — chỉ có ví là nhẹ hơn thấy rõ.