Bài 14 — File Storage — EFS, Filestore, Azure Files

Mở đầu — vì sao bài này quan trọng

Hãy hình dung bạn đang vận hành một hệ thống có 5 máy chủ web cùng phục vụ một website tin tức. Người dùng tải ảnh lên, và cả 5 máy chủ đều phải "nhìn thấy" tấm ảnh đó ngay lập tức, bất kể ảnh được upload qua máy nào. Nếu mỗi máy giữ file riêng trên ổ đĩa của mình, bạn sẽ rơi vào cảnh: máy A có ảnh, máy B thì không, người dùng lúc thấy lúc không thấy — một cơn ác mộng.

Đây chính là bài toán mà File Storage (lưu trữ dạng tệp qua mạng) sinh ra để giải quyết. Ở hai bài trước, chúng ta đã học Object Storage (S3) — nơi bạn thao tác qua API HTTP, và Block Storage (EBS) — ổ đĩa gắn cứng vào đúng một máy. File Storage là mảnh ghép còn lại: một hệ thống tệp (file system) đúng nghĩa, có thư mục, có quyền POSIX, nhưng nằm trên mạng và nhiều máy có thể gắn (mount) vào cùng lúc.

Tại sao bạn phải nắm vững nó? Vì rất nhiều ứng dụng "đời thực" — đặc biệt là các phần mềm cũ (legacy), CMS như WordPress, hệ thống xử lý media, hay các cụm tính toán khoa học — được viết với giả định rằng chúng đang ghi vào một thư mục cục bộ bình thường. Bạn không thể sửa hết code để chúng gọi API S3. File Storage cho phép bạn "lừa" ứng dụng rằng nó đang ghi vào ổ đĩa local, trong khi thực chất dữ liệu nằm chung ở một nơi mà cả cụm máy chủ đều truy cập được. Hiểu đúng công cụ này giúp bạn kiến trúc hệ thống co giãn (scale-out) mà không phải viết lại phần mềm.

Khái niệm cốt lõi

File Storage là gì và khác gì Block/Object?

File Storage cung cấp cho bạn một file system chia sẻ qua mạng. Thay vì bạn phải tự format ổ đĩa rồi tạo thư mục (như Block Storage), nhà cung cấp cloud đã dựng sẵn một hệ thống tệp và cho bạn "cắm" vào qua giao thức mạng. Điểm mấu chốt để phân biệt ba loại:

• Block Storage (EBS, Persistent Disk): một ổ đĩa thô, gắn vào đúng một máy ảo. Giống như bạn cắm một ổ SSD vào một chiếc laptop.
• Object Storage (S3, Blob): kho lưu đối tượng, truy cập qua API HTTP (PUT/GET), không có khái niệm thư mục thật, không mount như ổ đĩa được. Giống như gửi/nhận bưu kiện qua bưu điện.
• File Storage (EFS, Filestore, Azure Files): file system chia sẻ, nhiều máy mount cùng lúc, thao tác như thư mục thường (cp, ls, open()). Giống như một ổ đĩa mạng dùng chung trong văn phòng.

Hai giao thức nền tảng: NFS và SMB

File Storage đứng trên hai giao thức mạng kinh điển:

• NFS (Network File System): chuẩn của thế giới Linux/Unix. Đây là giao thức mà AWS EFS và GCP Filestore dùng. Bạn mount bằng lệnh dạng mount -t nfs ... và thư mục hiện ra như một phần của cây thư mục Linux.
• SMB/CIFS (Server Message Block): chuẩn của thế giới Windows (ổ đĩa mạng \\server\share). Azure Files hỗ trợ cả SMB lẫn NFS, nên đặc biệt hợp với các workload Windows như IIS, .NET, hoặc file server doanh nghiệp chuyển từ on-premise lên.

POSIX-compliant nghĩa là gì?

"POSIX-compliant" nghĩa là file system này tuân thủ chuẩn hệ điều hành Unix: có quyền đọc/ghi/thực thi (chmod), có chủ sở hữu (chown), có hard link, symbolic link, khóa file (file locking)... Điều này quan trọng vì ứng dụng cũ của bạn khi gọi các lệnh hệ thống như open(), write(), fsync(), flock() sẽ hoạt động y hệt như trên ổ đĩa local. Object Storage không làm được điều này — đó là lý do bạn không thể chạy một database hay một WordPress plugin ghi file trực tiếp lên S3 mà không có lớp trung gian.

Multi-mount và "shared media"

Đặc tính đắt giá nhất của File Storage là multi-mount: hàng chục, hàng trăm máy ảo cùng mount một volume và cùng đọc/ghi. Đây là nền tảng cho các use case như:

• Shared media / content: thư mục uploads/ của WordPress, ảnh sản phẩm của sàn thương mại điện tử, mà nhiều web server cùng phục vụ.
• Home directory dùng chung: trong môi trường tính toán (HPC), nhiều node cùng đọc dữ liệu đầu vào và ghi kết quả.
• CI/CD và build cache: nhiều runner cùng chia sẻ cache để build nhanh hơn.
• Lift-and-shift ứng dụng legacy: phần mềm cũ cần một thư mục chung mà không thể viết lại.

Ba "khuôn mặt" trên ba cloud lớn

• AWS EFS (Elastic File System): NFS, tự động co giãn dung lượng (không cần khai báo trước), tính tiền theo GB thực dùng. Có hai chế độ throughput: Bursting (tốc độ tăng theo dung lượng) và Elastic/Provisioned. Có lớp lưu trữ EFS-IA (Infrequent Access) rẻ hơn cho file ít truy cập.
• GCP Filestore: NFS, nhưng bạn phải chọn tier và khai báo dung lượng trước (ví dụ Basic HDD tối thiểu 1 TB, Zonal SSD cho hiệu năng cao). Tính tiền theo dung lượng cấp phát, không theo dung lượng dùng.
• Azure Files: hỗ trợ cả SMB và NFS, tích hợp sâu với Active Directory, và có tính năng Azure File Sync để đồng bộ file server on-premise với cloud — rất mạnh cho doanh nghiệp đang chuyển đổi.

Một lưu ý về hiệu năng và độ trễ

File qua mạng luôn có độ trễ (latency) cao hơn ổ đĩa cắm trực tiếp. Với hàng nghìn file nhỏ, hoặc thao tác metadata dày đặc (liệt kê thư mục khổng lồ), hiệu năng có thể tụt. Vì vậy File Storage tuyệt vời cho chia sẻ, nhưng không phải lựa chọn cho ổ đĩa của database ghi/đọc cường độ cao — trường hợp đó bạn dùng Block Storage.

Tình huống thực tế

Ví dụ 1: Sàn thương mại điện tử tại TP.HCM co giãn tầng web

Một công ty thương mại điện tử tại TP.HCM (giả định tên "ChợViệt") bắt đầu với một máy chủ duy nhất chạy WordPress + WooCommerce. Ảnh sản phẩm được lưu trong thư mục wp-content/uploads/. Khi lượng truy cập tăng vọt vào dịp lễ 30/4, một máy không tải nổi, đội kỹ thuật muốn nhân lên 4 máy web sau một load balancer.

Vấn đề nảy sinh ngay: nhân viên upload ảnh sản phẩm mới qua máy số 2, nhưng khách vào máy số 3 lại thấy ảnh vỡ. Lý do: mỗi máy giữ thư mục uploads/ riêng. Giải pháp của họ là tạo một AWS EFS, mount vào cả 4 máy tại đúng đường dẫn wp-content/uploads/. Từ đó, ảnh upload ở bất kỳ máy nào đều xuất hiện tức thì ở mọi máy.

Con số cụ thể: họ có khoảng 80 GB ảnh, chi phí EFS rơi vào khoảng 24 USD/tháng cho lớp Standard, và họ bật EFS-IA để đẩy ảnh cũ (sản phẩm ngừng bán) xuống lớp rẻ hơn, tiết kiệm thêm ~40% phần dung lượng ít truy cập.

Bài học rút ra: khi scale-out một ứng dụng có thư mục ghi chung, File Storage là cách nhanh nhất để "một dòng cấu hình mount" thay vì viết lại code để đẩy lên S3. Đây là lối đi thực dụng cho legacy.

Ví dụ 2: Studio dựng phim render trên cụm máy ảo

Một studio hậu kỳ ở Hà Nội cần render các cảnh 3D. Họ dựng một render farm gồm 20 máy ảo GPU trên GCP. Mỗi máy cần đọc cùng bộ asset (texture, model, cảnh dựng) nặng khoảng 600 GB, và cùng ghi các frame kết quả vào một thư mục chung để máy điều phối gom lại thành video.

Họ dùng GCP Filestore tier Zonal (SSD) cấp phát 2,5 TB, mount qua NFS vào cả 20 node. Nhờ vậy, khi bổ sung một node mới vào giờ cao điểm, node đó chỉ cần mount là truy cập ngay toàn bộ asset — không cần copy 600 GB dữ liệu về từng máy (việc này sẽ tốn hàng giờ và lãng phí băng thông).

Điểm họ phải cân nhắc: Filestore tính tiền theo dung lượng cấp phát chứ không phải dùng thực, và tier SSD đắt hơn HDD đáng kể. Họ chọn bật cụm chỉ trong đợt render rồi xóa để không trả tiền lúc rảnh.

Bài học rút ra: với workload nhiều máy cùng đọc một tập dữ liệu lớn, File Storage tránh được việc nhân bản dữ liệu tốn kém. Nhưng hãy nhớ mô hình tính tiền: Filestore trả theo dung lượng đặt trước, nên phải quản lý vòng đời (bật/tắt) để tối ưu chi phí.

Ví dụ 3: Doanh nghiệp chuyển file server Windows lên cloud

Một công ty dịch vụ kế toán ở Đà Nẵng có một file server Windows nội bộ, nơi nhân viên lưu tài liệu qua ổ mạng \\fileserver\ketoan. Máy chủ vật lý này già cỗi, hay hỏng, và không truy cập được khi nhân viên làm việc từ xa.

Họ di chuyển sang Azure Files dùng giao thức SMB, tích hợp với Azure Active Directory để giữ nguyên phân quyền theo phòng ban. Nhân viên vẫn ánh xạ ổ mạng như cũ, gần như không cần đào tạo lại. Thêm nữa, họ dùng Azure File Sync để giữ một bản cache nóng ngay tại văn phòng cho tốc độ truy cập nhanh, còn bản gốc nằm an toàn trên cloud với sao lưu tự động.

Bài học rút ra: Azure Files là lựa chọn tự nhiên cho hệ sinh thái Windows và các doanh nghiệp muốn "lift-and-shift" file server nội bộ mà không phá vỡ thói quen người dùng. Giao thức SMB + tích hợp AD là yếu tố quyết định ở đây.

Hướng dẫn từng bước

Dưới đây là quy trình tổng quát để tạo và dùng một File Storage, minh họa bằng AWS EFS (các cloud khác tương tự về tư duy):

• Xác định nhu cầu: bạn cần chia sẻ file giữa mấy máy? Workload là Linux (NFS) hay Windows (SMB)? Lượng file nhỏ hay lớn, đọc nhiều hay ghi nhiều? Câu trả lời quyết định chọn EFS/Filestore (Linux) hay Azure Files (Windows).

• Tạo file system: trong AWS Console hoặc CLI, tạo một EFS. Với EFS bạn không cần khai báo dung lượng; với Filestore bạn phải chọn tier và nhập dung lượng trước.

• Cấu hình mạng và bảo mật: đặt EFS trong cùng VPC với các máy ảo. Tạo các mount target ở từng Availability Zone. Gắn Security Group cho phép cổng NFS (2049) từ các máy được phép — bước này cực kỳ hay bị bỏ sót.

• Mount trên máy ảo: trên mỗi máy Linux, cài nfs-utils (hoặc amazon-efs-utils) rồi chạy lệnh mount, ví dụ mount EFS vào /mnt/shared. Kiểm tra bằng df -h để thấy volume đã gắn.

• Ghi mount vào /etc/fstab: để volume tự động mount lại sau khi máy khởi động lại. Bỏ qua bước này là lỗi kinh điển khiến ứng dụng "mất thư mục" sau mỗi lần reboot.

• Trỏ ứng dụng vào thư mục chia sẻ: ví dụ tạo symlink từ wp-content/uploads sang /mnt/shared/uploads, hoặc cấu hình đường dẫn dữ liệu của ứng dụng về thư mục đã mount.

• Kiểm thử tính đồng nhất: tạo một file trên máy A, kiểm tra máy B nhìn thấy ngay. Đây là bài test xác nhận multi-mount hoạt động.

• Bật sao lưu và giám sát: kích hoạt AWS Backup cho EFS, đặt cảnh báo về throughput và độ trễ để phát hiện nghẽn cổ chai sớm.

Lỗi thường gặp & mẹo

• Quên mở cổng NFS (2049) trong Security Group: triệu chứng là lệnh mount treo mãi rồi timeout. Luôn kiểm tra Security Group của mount target trước tiên.

• Không có mount target ở đúng AZ: EFS cần một mount target trong Availability Zone của máy ảo. Máy ở AZ chưa có mount target sẽ không mount được.

• Dùng File Storage cho database: đây là sai lầm về kiến trúc. Database ghi/đọc ngẫu nhiên cường độ cao và cần độ trễ thấp — hãy dùng Block Storage. File Storage tối ưu cho chia sẻ, không cho IOPS ngẫu nhiên khắc nghiệt.

• Hiệu năng tệ với hàng triệu file nhỏ: thao tác metadata (liệt kê thư mục, stat từng file) trên NFS chậm hơn nhiều so với ổ local. Nếu bạn có thư mục chứa hàng trăm nghìn file, hãy chia nhỏ theo cấu trúc thư mục con để giảm tải liệt kê.

• Quên /etc/fstab: sau reboot mất mount, ứng dụng tưởng thư mục trống và có thể ghi đè dữ liệu vào ổ local. Luôn cấu hình tự động mount.

• Ngộ nhận về chi phí: EFS tính theo GB thực dùng (co giãn), nhưng Filestore tính theo dung lượng cấp phát. Đừng đem tư duy tính tiền của cloud này áp cho cloud kia.

• Mẹo tối ưu chi phí: dùng lifecycle policy để đẩy file ít truy cập xuống lớp Infrequent Access (EFS-IA) hoặc tier rẻ hơn. Với workload có thời hạn (render, build), bật/tắt hoặc xóa file system khi không dùng.

• Mẹo bảo mật: bật mã hóa at-rest và in-transit (TLS cho NFS), và dùng access point (EFS Access Point) để giới hạn từng ứng dụng chỉ thấy đúng thư mục con của nó với đúng quyền POSIX.

Bài tập thực hành

• So sánh ba loại lưu trữ: vẽ một bảng ba cột (Block / Object / File) và điền vào: giao thức truy cập, số máy mount đồng thời, có POSIX không, và một use case tiêu biểu. Mục tiêu là bạn giải thích được vì sao chọn loại này chứ không phải loại kia.

• Chọn công cụ theo tình huống: với mỗi tình huống sau, chọn EFS, Filestore, hay Azure Files và giải thích: (a) một cụm 10 web server Linux chạy Drupal cần chia sẻ thư mục sites/default/files; (b) một file server phòng nhân sự dùng Windows với phân quyền theo Active Directory; (c) một render farm 15 node Linux đọc chung 1 TB texture.

• Thiết kế mount thử nghiệm (trên giấy hoặc thật): phác thảo các bước để tạo một EFS và mount vào hai máy ảo Linux trong cùng VPC. Liệt kê rõ: Security Group cần mở cổng nào, mount target đặt ở đâu, dòng thêm vào /etc/fstab, và cách bạn test tính đồng nhất giữa hai máy.

• Phân tích chi phí: giả sử bạn có 200 GB dữ liệu, trong đó 60 GB được truy cập hằng ngày và 140 GB gần như không đụng tới. Hãy đề xuất cách bố trí lớp Standard và Infrequent Access để tiết kiệm chi phí, và ước lượng bạn tiết kiệm được bao nhiêu phần trăm cho phần ít truy cập.

Tóm tắt

File Storage là hệ thống tệp chia sẻ qua mạng, đứng trên hai giao thức NFS (Linux) và SMB (Windows), cho phép nhiều máy ảo mount đồng thời vào cùng một volume và thao tác như thư mục thường (POSIX-compliant). Nó lấp đầy khoảng trống giữa Block Storage (một ổ cho một máy) và Object Storage (kho qua API HTTP).

Ba đại diện lớn: AWS EFS (NFS, tự co giãn, trả theo dung lượng dùng), GCP Filestore (NFS, cấp phát dung lượng trước theo tier), và Azure Files (SMB/NFS, mạnh cho hệ sinh thái Windows và tích hợp Active Directory). Use case kinh điển là chia sẻ media/content giữa cụm web server, home directory dùng chung trong tính toán, và lift-and-shift phần mềm legacy hoặc file server doanh nghiệp.

Hãy nhớ ba nguyên tắc thực chiến: chọn File Storage khi cần chia sẻ file giữa nhiều máy (không dùng cho database ghi/đọc cường độ cao); luôn kiểm tra Security Group, mount target và /etc/fstab khi mount; và nắm rõ mô hình tính tiền của từng cloud để tối ưu chi phí. Khi bạn hiểu đúng ba loại lưu trữ và biết khi nào dùng loại nào, bạn đã có nền tảng vững để thiết kế những hệ thống cloud co giãn và bền bỉ.